> On Apr 29, 2014, at 2:17 AM, Dave Martin <dave.mar...@arm.com> 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 <santosh.shilim...@ti.com> >>>>> Cc: Russell King <li...@arm.linux.org.uk> >>>>> Cc: Nishanth Menon <n...@ti.com> >>>>> Cc: Tony Lindgren <t...@atomide.com> >>>>> Signed-off-by: Joel Fernandes <jo...@ti.com> >>>>> --- >>>>> 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 <santosh.shilim...@ti.com> >>>>> @@ -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 > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
