On my DRA7 system, when the kernel is built in THUMB mode, the secondary CPU
(Cortex A15) fails to come up causing SMP boot on second CPU to timeout. This
seems to be because the CPU is in ARM mode once the ROM hands over control to
the kernel. Switch to THUMB mode if required once the kernel is control of
secondary CPU. On OMAP4 on the other hand, it appears to be in THUMB mode on
entry so this is not required and SMP boot works as is.
Cc: Santosh Shilimkar <[email protected]>
Cc: Russell King <[email protected]>
Cc: Nishanth Menon <[email protected]>
Cc: Tony Lindgren <[email protected]>
Signed-off-by: Joel Fernandes <[email protected]>
---
arch/arm/mach-omap2/omap-headsmp.S | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-headsmp.S b/arch/arm/mach-omap2/omap-headsmp.S
index 75e9295..1809dce 100644
--- a/arch/arm/mach-omap2/omap-headsmp.S
+++ b/arch/arm/mach-omap2/omap-headsmp.S
@@ -1,7 +1,7 @@
/*
* Secondary CPU startup routine source file.
*
- * Copyright (C) 2009 Texas Instruments, Inc.
+ * Copyright (C) 2014 Texas Instruments, Inc.
*
* Author:
* Santosh Shilimkar <[email protected]>
@@ -28,9 +28,13 @@
* code. This routine also provides a holding flag into which
* secondary core is held until we're ready for it to initialise.
* The primary core will update this flag using a hardware
-+ * register AuxCoreBoot0.
+ * register AuxCoreBoot0.
*/
ENTRY(omap5_secondary_startup)
+.arm
+THUMB( adr r9, BSYM(wait) ) @ CPU may be entered in ARM mode.
+THUMB( bx r9 ) @ If this is a Thumb-2 kernel,
+THUMB( .thumb ) @ switch to Thumb now.
wait: ldr r2, =AUX_CORE_BOOT0_PA @ read from AuxCoreBoot0
ldr r0, [r2]
mov r0, r0, lsr #5
--
1.7.9.5
On Tuesday 22 April 2014 02:31 PM, Joel Fernandes wrote:
> On my DRA7 system, when the kernel is built in THUMB mode, the secondary CPU
> (Cortex A15) fails to come up causing SMP boot on second CPU to timeout. This
> seems to be because the CPU is in ARM mode once the ROM hands over control to
> the kernel. Switch to THUMB mode if required once the kernel is control of
> secondary CPU. On OMAP4 on the other hand, it appears to be in THUMB mode on
> entry so this is not required and SMP boot works as is.
>
> Cc: Santosh Shilimkar <[email protected]>
> Cc: Russell King <[email protected]>
> Cc: Nishanth Menon <[email protected]>
> Cc: Tony Lindgren <[email protected]>
> Signed-off-by: Joel Fernandes <[email protected]>
> ---
> arch/arm/mach-omap2/omap-headsmp.S | 8 ++++++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
Looks fine to me ..
Acked-by: Santosh Shilimkar <[email protected]>
On Tue, Apr 22, 2014 at 1:31 PM, Joel Fernandes <[email protected]> wrote:
> On my DRA7 system, when the kernel is built in THUMB mode, the secondary CPU
Did you mean THUMB2? omap2plus_defconfig works today with
CONFIG_ARM_THUMB enabled..
> (Cortex A15) fails to come up causing SMP boot on second CPU to timeout. This
> seems to be because the CPU is in ARM mode once the ROM hands over control to
> the kernel. Switch to THUMB mode if required once the kernel is control of
> secondary CPU. On OMAP4 on the other hand, it appears to be in THUMB mode on
> entry so this is not required and SMP boot works as is.
>
> Cc: Santosh Shilimkar <[email protected]>
> Cc: Russell King <[email protected]>
> Cc: Nishanth Menon <[email protected]>
> Cc: Tony Lindgren <[email protected]>
> Signed-off-by: Joel Fernandes <[email protected]>
> ---
> arch/arm/mach-omap2/omap-headsmp.S | 8 ++++++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap-headsmp.S b/arch/arm/mach-omap2/omap-headsmp.S
> index 75e9295..1809dce 100644
> --- a/arch/arm/mach-omap2/omap-headsmp.S
> +++ b/arch/arm/mach-omap2/omap-headsmp.S
> @@ -1,7 +1,7 @@
> /*
> * Secondary CPU startup routine source file.
> *
> - * Copyright (C) 2009 Texas Instruments, Inc.
> + * Copyright (C) 2014 Texas Instruments, Inc.
2009-2014
> *
> * Author:
> * Santosh Shilimkar <[email protected]>
> @@ -28,9 +28,13 @@
> * code. This routine also provides a holding flag into which
> * secondary core is held until we're ready for it to initialise.
> * The primary core will update this flag using a hardware
> -+ * register AuxCoreBoot0.
> + * register AuxCoreBoot0.
spurious change?
> */
> ENTRY(omap5_secondary_startup)
> +.arm
> +THUMB( adr r9, BSYM(wait) ) @ CPU may be entered in ARM mode.
> +THUMB( bx r9 ) @ If this is a Thumb-2 kernel,
> +THUMB( .thumb ) @ switch to Thumb now.
> wait: ldr r2, =AUX_CORE_BOOT0_PA @ read from AuxCoreBoot0
> ldr r0, [r2]
> mov r0, r0, lsr #5
> --
> 1.7.9.5
On 04/22/2014 01:47 PM, Nishanth Menon wrote:
> On Tue, Apr 22, 2014 at 1:31 PM, Joel Fernandes <[email protected]> wrote:
>> On my DRA7 system, when the kernel is built in THUMB mode, the secondary CPU
> Did you mean THUMB2? omap2plus_defconfig works today with
> CONFIG_ARM_THUMB enabled..
ARM_THUMB is for user binaries though, not kernel. But yeah I should
reword the commit message to use Thumb-2. I'll do that.
>
>> (Cortex A15) fails to come up causing SMP boot on second CPU to timeout. This
>> seems to be because the CPU is in ARM mode once the ROM hands over control to
>> the kernel. Switch to THUMB mode if required once the kernel is control of
>> secondary CPU. On OMAP4 on the other hand, it appears to be in THUMB mode on
>> entry so this is not required and SMP boot works as is.
>>
>> Cc: Santosh Shilimkar <[email protected]>
>> Cc: Russell King <[email protected]>
>> Cc: Nishanth Menon <[email protected]>
>> Cc: Tony Lindgren <[email protected]>
>> Signed-off-by: Joel Fernandes <[email protected]>
>> ---
>> arch/arm/mach-omap2/omap-headsmp.S | 8 ++++++--
>> 1 file changed, 6 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/omap-headsmp.S b/arch/arm/mach-omap2/omap-headsmp.S
>> index 75e9295..1809dce 100644
>> --- a/arch/arm/mach-omap2/omap-headsmp.S
>> +++ b/arch/arm/mach-omap2/omap-headsmp.S
>> @@ -1,7 +1,7 @@
>> /*
>> * Secondary CPU startup routine source file.
>> *
>> - * Copyright (C) 2009 Texas Instruments, Inc.
>> + * Copyright (C) 2014 Texas Instruments, Inc.
> 2009-2014
Sure.
>
>> *
>> * Author:
>> * Santosh Shilimkar <[email protected]>
>> @@ -28,9 +28,13 @@
>> * code. This routine also provides a holding flag into which
>> * secondary core is held until we're ready for it to initialise.
>> * The primary core will update this flag using a hardware
>> -+ * register AuxCoreBoot0.
>> + * register AuxCoreBoot0.
>
> spurious change?
>
The "+" is spurious, I was trying to correct that. Will update commit
message in v2.
thanks,
-Joel
On Tue, Apr 22, 2014 at 01:31:46PM -0500, Joel Fernandes wrote:
> On my DRA7 system, when the kernel is built in THUMB mode, the secondary CPU
> (Cortex A15) fails to come up causing SMP boot on second CPU to timeout. This
> seems to be because the CPU is in ARM mode once the ROM hands over control to
> the kernel. Switch to THUMB mode if required once the kernel is control of
> secondary CPU. On OMAP4 on the other hand, it appears to be in THUMB mode on
> entry so this is not required and SMP boot works as is.
>
> Cc: Santosh Shilimkar <[email protected]>
> Cc: Russell King <[email protected]>
> Cc: Nishanth Menon <[email protected]>
> Cc: Tony Lindgren <[email protected]>
> Signed-off-by: Joel Fernandes <[email protected]>
> ---
> arch/arm/mach-omap2/omap-headsmp.S | 8 ++++++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap-headsmp.S b/arch/arm/mach-omap2/omap-headsmp.S
> index 75e9295..1809dce 100644
> --- a/arch/arm/mach-omap2/omap-headsmp.S
> +++ b/arch/arm/mach-omap2/omap-headsmp.S
> @@ -1,7 +1,7 @@
> /*
> * Secondary CPU startup routine source file.
> *
> - * Copyright (C) 2009 Texas Instruments, Inc.
> + * Copyright (C) 2014 Texas Instruments, Inc.
> *
> * Author:
> * Santosh Shilimkar <[email protected]>
> @@ -28,9 +28,13 @@
> * code. This routine also provides a holding flag into which
> * secondary core is held until we're ready for it to initialise.
> * The primary core will update this flag using a hardware
> -+ * register AuxCoreBoot0.
> + * register AuxCoreBoot0.
> */
> ENTRY(omap5_secondary_startup)
Are you sure this problem is not caused by the missing ENDPROC() for
omap5_secondary_startup?
You have END() instead (which may have been accidental).
Without ENDPROC(), the symbol is not marked as a function and so
the Thumb bit won't be set when taking a pointer -- so the kernel
is actually telling the firmware to enter in ARM state.
Try changing END() to ENDPROC() without this patch, and see if it
makes a difference.
If it still doesn't work, then the firmware either doesn't support
entering in ARM, or is buggy.
Cheers
---Dave
> +.arm
> +THUMB( adr r9, BSYM(wait) ) @ CPU may be entered in ARM mode.
> +THUMB( bx r9 ) @ If this is a Thumb-2 kernel,
> +THUMB( .thumb ) @ switch to Thumb now.
> wait: ldr r2, =AUX_CORE_BOOT0_PA @ read from AuxCoreBoot0
> ldr r0, [r2]
> mov r0, r0, lsr #5
> --
> 1.7.9.5
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> [email protected]
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On 04/28/2014 11:43 AM, Dave Martin wrote:
> On Tue, Apr 22, 2014 at 01:31:46PM -0500, Joel Fernandes wrote:
>> On my DRA7 system, when the kernel is built in THUMB mode, the secondary CPU
>> (Cortex A15) fails to come up causing SMP boot on second CPU to timeout. This
>> seems to be because the CPU is in ARM mode once the ROM hands over control to
>> the kernel. Switch to THUMB mode if required once the kernel is control of
>> secondary CPU. On OMAP4 on the other hand, it appears to be in THUMB mode on
>> entry so this is not required and SMP boot works as is.
>>
>> Cc: Santosh Shilimkar <[email protected]>
>> Cc: Russell King <[email protected]>
>> Cc: Nishanth Menon <[email protected]>
>> Cc: Tony Lindgren <[email protected]>
>> Signed-off-by: Joel Fernandes <[email protected]>
>> ---
>> arch/arm/mach-omap2/omap-headsmp.S | 8 ++++++--
>> 1 file changed, 6 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/omap-headsmp.S b/arch/arm/mach-omap2/omap-headsmp.S
>> index 75e9295..1809dce 100644
>> --- a/arch/arm/mach-omap2/omap-headsmp.S
>> +++ b/arch/arm/mach-omap2/omap-headsmp.S
>> @@ -1,7 +1,7 @@
>> /*
>> * Secondary CPU startup routine source file.
>> *
>> - * Copyright (C) 2009 Texas Instruments, Inc.
>> + * Copyright (C) 2014 Texas Instruments, Inc.
>> *
>> * Author:
>> * Santosh Shilimkar <[email protected]>
>> @@ -28,9 +28,13 @@
>> * code. This routine also provides a holding flag into which
>> * secondary core is held until we're ready for it to initialise.
>> * The primary core will update this flag using a hardware
>> -+ * register AuxCoreBoot0.
>> + * register AuxCoreBoot0.
>> */
>> ENTRY(omap5_secondary_startup)
>
> Are you sure this problem is not caused by the missing ENDPROC() for
> omap5_secondary_startup?
>
> You have END() instead (which may have been accidental).
>
> Without ENDPROC(), the symbol is not marked as a function and so
> the Thumb bit won't be set when taking a pointer -- so the kernel
> is actually telling the firmware to enter in ARM state.
>
>
> Try changing END() to ENDPROC() without this patch, and see if it
> makes a difference.
>
> If it still doesn't work, then the firmware either doesn't support
> entering in ARM, or is buggy.
Thanks for the suggestion. I'm guessing what you mean is with ENDPROC,
interworking code uses bx instead of bl to set thumb mode.
But ROM/firmware doesn't have access to symbol table, how would it know
the type of the symbol to be ARM or THUMB before it branches?
regards,
-Joel
On 04/28/2014 12:20 PM, Joel Fernandes wrote:
> On 04/28/2014 11:43 AM, Dave Martin wrote:
>> On Tue, Apr 22, 2014 at 01:31:46PM -0500, Joel Fernandes wrote:
>>> On my DRA7 system, when the kernel is built in THUMB mode, the secondary CPU
>>> (Cortex A15) fails to come up causing SMP boot on second CPU to timeout. This
>>> seems to be because the CPU is in ARM mode once the ROM hands over control to
>>> the kernel. Switch to THUMB mode if required once the kernel is control of
>>> secondary CPU. On OMAP4 on the other hand, it appears to be in THUMB mode on
>>> entry so this is not required and SMP boot works as is.
>>>
>>> Cc: Santosh Shilimkar <[email protected]>
>>> Cc: Russell King <[email protected]>
>>> Cc: Nishanth Menon <[email protected]>
>>> Cc: Tony Lindgren <[email protected]>
>>> Signed-off-by: Joel Fernandes <[email protected]>
>>> ---
>>> arch/arm/mach-omap2/omap-headsmp.S | 8 ++++++--
>>> 1 file changed, 6 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/arch/arm/mach-omap2/omap-headsmp.S b/arch/arm/mach-omap2/omap-headsmp.S
>>> index 75e9295..1809dce 100644
>>> --- a/arch/arm/mach-omap2/omap-headsmp.S
>>> +++ b/arch/arm/mach-omap2/omap-headsmp.S
>>> @@ -1,7 +1,7 @@
>>> /*
>>> * Secondary CPU startup routine source file.
>>> *
>>> - * Copyright (C) 2009 Texas Instruments, Inc.
>>> + * Copyright (C) 2014 Texas Instruments, Inc.
>>> *
>>> * Author:
>>> * Santosh Shilimkar <[email protected]>
>>> @@ -28,9 +28,13 @@
>>> * code. This routine also provides a holding flag into which
>>> * secondary core is held until we're ready for it to initialise.
>>> * The primary core will update this flag using a hardware
>>> -+ * register AuxCoreBoot0.
>>> + * register AuxCoreBoot0.
>>> */
>>> ENTRY(omap5_secondary_startup)
>>
>> Are you sure this problem is not caused by the missing ENDPROC() for
>> omap5_secondary_startup?
>>
>> You have END() instead (which may have been accidental).
>>
>> Without ENDPROC(), the symbol is not marked as a function and so
>> the Thumb bit won't be set when taking a pointer -- so the kernel
>> is actually telling the firmware to enter in ARM state.
>>
>>
>> Try changing END() to ENDPROC() without this patch, and see if it
>> makes a difference.
>>
>> If it still doesn't work, then the firmware either doesn't support
>> entering in ARM, or is buggy.
>
> Thanks for the suggestion. I'm guessing what you mean is with ENDPROC,
> interworking code uses bx instead of bl to set thumb mode.
>
> But ROM/firmware doesn't have access to symbol table, how would it know
> the type of the symbol to be ARM or THUMB before it branches?
>
Sorry what I meant is, say its of Type function. What tells the firmware
to switch to THUMB?
What's typically done is a boot address register is written by the
kernel, and the firmware jumps to it after WFE.
thanks,
-Joel
On Mon, Apr 28, 2014 at 06:21:49PM +0100, Joel Fernandes wrote:
> On 04/28/2014 12:20 PM, Joel Fernandes wrote:
> > On 04/28/2014 11:43 AM, Dave Martin wrote:
> >> On Tue, Apr 22, 2014 at 01:31:46PM -0500, Joel Fernandes wrote:
> >>> On my DRA7 system, when the kernel is built in THUMB mode, the secondary CPU
> >>> (Cortex A15) fails to come up causing SMP boot on second CPU to timeout. This
> >>> seems to be because the CPU is in ARM mode once the ROM hands over control to
> >>> the kernel. Switch to THUMB mode if required once the kernel is control of
> >>> secondary CPU. On OMAP4 on the other hand, it appears to be in THUMB mode on
> >>> entry so this is not required and SMP boot works as is.
> >>>
> >>> Cc: Santosh Shilimkar <[email protected]>
> >>> Cc: Russell King <[email protected]>
> >>> Cc: Nishanth Menon <[email protected]>
> >>> Cc: Tony Lindgren <[email protected]>
> >>> Signed-off-by: Joel Fernandes <[email protected]>
> >>> ---
> >>> arch/arm/mach-omap2/omap-headsmp.S | 8 ++++++--
> >>> 1 file changed, 6 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/arch/arm/mach-omap2/omap-headsmp.S b/arch/arm/mach-omap2/omap-headsmp.S
> >>> index 75e9295..1809dce 100644
> >>> --- a/arch/arm/mach-omap2/omap-headsmp.S
> >>> +++ b/arch/arm/mach-omap2/omap-headsmp.S
> >>> @@ -1,7 +1,7 @@
> >>> /*
> >>> * Secondary CPU startup routine source file.
> >>> *
> >>> - * Copyright (C) 2009 Texas Instruments, Inc.
> >>> + * Copyright (C) 2014 Texas Instruments, Inc.
> >>> *
> >>> * Author:
> >>> * Santosh Shilimkar <[email protected]>
> >>> @@ -28,9 +28,13 @@
> >>> * code. This routine also provides a holding flag into which
> >>> * secondary core is held until we're ready for it to initialise.
> >>> * The primary core will update this flag using a hardware
> >>> -+ * register AuxCoreBoot0.
> >>> + * register AuxCoreBoot0.
> >>> */
> >>> ENTRY(omap5_secondary_startup)
> >>
> >> Are you sure this problem is not caused by the missing ENDPROC() for
> >> omap5_secondary_startup?
> >>
> >> You have END() instead (which may have been accidental).
> >>
> >> Without ENDPROC(), the symbol is not marked as a function and so
> >> the Thumb bit won't be set when taking a pointer -- so the kernel
> >> is actually telling the firmware to enter in ARM state.
> >>
> >>
> >> Try changing END() to ENDPROC() without this patch, and see if it
> >> makes a difference.
> >>
> >> If it still doesn't work, then the firmware either doesn't support
> >> entering in ARM, or is buggy.
> >
> > Thanks for the suggestion. I'm guessing what you mean is with ENDPROC,
> > interworking code uses bx instead of bl to set thumb mode.
> >
> > But ROM/firmware doesn't have access to symbol table, how would it know
> > the type of the symbol to be ARM or THUMB before it branches?
> >
> Sorry what I meant is, say its of Type function. What tells the firmware
> to switch to THUMB?
>
> What's typically done is a boot address register is written by the
> kernel, and the firmware jumps to it after WFE.
Using ENTRY(x) ... ENDPROC(x) causes the symbol seen by the linker
for x to have the Thumb bit set if the code is Thumb.
This means that any reference the linker fixes up for that symbol
will have the Thumb bit set appropriately. This applies to any kind
of reference, so code in another file that takes the address of the
symbol and then passes that address to the firmware should result in the
firmware getting an address with the Thumb bit.
>From the firmware's point of view it just gets a raw address, but
the Thumb bit will now be set. The firmware still needs to handle
this correctly when jumping, but from the look of the code this may
already work on omap3/4. It would be interesting to know whether it
works on omap5.
Cheers
---Dave
> On Apr 29, 2014, at 2:17 AM, Dave Martin <[email protected]> wrote:
>
>> On Mon, Apr 28, 2014 at 06:21:49PM +0100, Joel Fernandes wrote:
>>> On 04/28/2014 12:20 PM, Joel Fernandes wrote:
>>>> On 04/28/2014 11:43 AM, Dave Martin wrote:
>>>>> On Tue, Apr 22, 2014 at 01:31:46PM -0500, Joel Fernandes wrote:
>>>>> On my DRA7 system, when the kernel is built in THUMB mode, the secondary CPU
>>>>> (Cortex A15) fails to come up causing SMP boot on second CPU to timeout. This
>>>>> seems to be because the CPU is in ARM mode once the ROM hands over control to
>>>>> the kernel. Switch to THUMB mode if required once the kernel is control of
>>>>> secondary CPU. On OMAP4 on the other hand, it appears to be in THUMB mode on
>>>>> entry so this is not required and SMP boot works as is.
>>>>>
>>>>> Cc: Santosh Shilimkar <[email protected]>
>>>>> Cc: Russell King <[email protected]>
>>>>> Cc: Nishanth Menon <[email protected]>
>>>>> Cc: Tony Lindgren <[email protected]>
>>>>> Signed-off-by: Joel Fernandes <[email protected]>
>>>>> ---
>>>>> arch/arm/mach-omap2/omap-headsmp.S | 8 ++++++--
>>>>> 1 file changed, 6 insertions(+), 2 deletions(-)
>>>>>
>>>>> diff --git a/arch/arm/mach-omap2/omap-headsmp.S b/arch/arm/mach-omap2/omap-headsmp.S
>>>>> index 75e9295..1809dce 100644
>>>>> --- a/arch/arm/mach-omap2/omap-headsmp.S
>>>>> +++ b/arch/arm/mach-omap2/omap-headsmp.S
>>>>> @@ -1,7 +1,7 @@
>>>>> /*
>>>>> * Secondary CPU startup routine source file.
>>>>> *
>>>>> - * Copyright (C) 2009 Texas Instruments, Inc.
>>>>> + * Copyright (C) 2014 Texas Instruments, Inc.
>>>>> *
>>>>> * Author:
>>>>> * Santosh Shilimkar <[email protected]>
>>>>> @@ -28,9 +28,13 @@
>>>>> * code. This routine also provides a holding flag into which
>>>>> * secondary core is held until we're ready for it to initialise.
>>>>> * The primary core will update this flag using a hardware
>>>>> -+ * register AuxCoreBoot0.
>>>>> + * register AuxCoreBoot0.
>>>>> */
>>>>> ENTRY(omap5_secondary_startup)
>>>>
>>>> Are you sure this problem is not caused by the missing ENDPROC() for
>>>> omap5_secondary_startup?
>>>>
>>>> You have END() instead (which may have been accidental).
>>>>
>>>> Without ENDPROC(), the symbol is not marked as a function and so
>>>> the Thumb bit won't be set when taking a pointer -- so the kernel
>>>> is actually telling the firmware to enter in ARM state.
>>>>
>>>>
>>>> Try changing END() to ENDPROC() without this patch, and see if it
>>>> makes a difference.
>>>>
>>>> If it still doesn't work, then the firmware either doesn't support
>>>> entering in ARM, or is buggy.
>>>
>>> Thanks for the suggestion. I'm guessing what you mean is with ENDPROC,
>>> interworking code uses bx instead of bl to set thumb mode.
>>>
>>> But ROM/firmware doesn't have access to symbol table, how would it know
>>> the type of the symbol to be ARM or THUMB before it branches?
>> Sorry what I meant is, say its of Type function. What tells the firmware
>> to switch to THUMB?
>>
>> What's typically done is a boot address register is written by the
>> kernel, and the firmware jumps to it after WFE.
>
> Using ENTRY(x) ... ENDPROC(x) causes the symbol seen by the linker
> for x to have the Thumb bit set if the code is Thumb.
>
> This means that any reference the linker fixes up for that symbol
> will have the Thumb bit set appropriately. This applies to any kind
> of reference, so code in another file that takes the address of the
> symbol and then passes that address to the firmware should result in the
> firmware getting an address with the Thumb bit.
>
> From the firmware's point of view it just gets a raw address, but
> the Thumb bit will now be set. The firmware still needs to handle
> this correctly when jumping, but from the look of the code this may
> already work on omap3/4. It would be interesting to know whether it
> works on omap5.
Thanks a lot for the explanation. That makes perfect sense. I will try it and let you know if it works on OMAP5.
Regards,
-Joel
>
> Cheers
> ---Dave
>
> _______________________________________________
> linux-arm-kernel mailing list
> [email protected]
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Tue, Apr 29, 2014 at 05:36:30PM +0100, Joel Fernandes wrote:
[...]
> >> Sorry what I meant is, say its of Type function. What tells the firmware
> >> to switch to THUMB?
> >>
> >> What's typically done is a boot address register is written by the
> >> kernel, and the firmware jumps to it after WFE.
> >
> > Using ENTRY(x) ... ENDPROC(x) causes the symbol seen by the linker
> > for x to have the Thumb bit set if the code is Thumb.
> >
> > This means that any reference the linker fixes up for that symbol
> > will have the Thumb bit set appropriately. This applies to any kind
> > of reference, so code in another file that takes the address of the
> > symbol and then passes that address to the firmware should result in the
> > firmware getting an address with the Thumb bit.
> >
> > From the firmware's point of view it just gets a raw address, but
> > the Thumb bit will now be set. The firmware still needs to handle
> > this correctly when jumping, but from the look of the code this may
> > already work on omap3/4. It would be interesting to know whether it
> > works on omap5.
>
> Thanks a lot for the explanation. That makes perfect sense. I will try it and let you know if it works on OMAP5.
ARM/thumb interworking making perfect sense? I'll have to frame that
and put it on the wall :)
objdump and nm conveniently mask off the Thumb bit from all function
addresses they print out, but if you show the symbols using readelf
instead you'll see addresses with bit 0 set for Thumb functions.
It's possible that the firmware still doesn't handle branching to Thumb
correctly, but if it does it would be nice to remove the requirement to
build an odd piece of a Thumb-2 kernel in ARM.
Cheers
---Dave
On 04/29/2014 01:31 PM, Dave Martin wrote:
> On Tue, Apr 29, 2014 at 05:36:30PM +0100, Joel Fernandes wrote:
>
> [...]
>
>>>> Sorry what I meant is, say its of Type function. What tells the firmware
>>>> to switch to THUMB?
>>>>
>>>> What's typically done is a boot address register is written by the
>>>> kernel, and the firmware jumps to it after WFE.
>>>
>>> Using ENTRY(x) ... ENDPROC(x) causes the symbol seen by the linker
>>> for x to have the Thumb bit set if the code is Thumb.
>>>
>>> This means that any reference the linker fixes up for that symbol
>>> will have the Thumb bit set appropriately. This applies to any kind
>>> of reference, so code in another file that takes the address of the
>>> symbol and then passes that address to the firmware should result in the
>>> firmware getting an address with the Thumb bit.
>>>
>>> From the firmware's point of view it just gets a raw address, but
>>> the Thumb bit will now be set. The firmware still needs to handle
>>> this correctly when jumping, but from the look of the code this may
>>> already work on omap3/4. It would be interesting to know whether it
>>> works on omap5.
>>
>> Thanks a lot for the explanation. That makes perfect sense. I will try it and let you know if it works on OMAP5.
>
> ARM/thumb interworking making perfect sense? I'll have to frame that
> and put it on the wall :)
>
> objdump and nm conveniently mask off the Thumb bit from all function
> addresses they print out, but if you show the symbols using readelf
> instead you'll see addresses with bit 0 set for Thumb functions.
>
> It's possible that the firmware still doesn't handle branching to Thumb
> correctly, but if it does it would be nice to remove the requirement to
> build an odd piece of a Thumb-2 kernel in ARM.
Sure, it works great! thanks, I sent out a patch that applies on top of
the first one. Thanks for spotting it.
Regards,
-Joel