| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-Id: <D49C397D-1ABD-4882-B3F5-94F359D7552B@gmail.com> Date: Tue, 29 Apr 2014 09:36:30 -0700 From: Joel Fernandes <agnel.joel@...il.com> To: Dave Martin <Dave.Martin@....com> Cc: Joel Fernandes <joelf@...com>, Nishanth Menon <nm@...com>, Russell King <linux@....linux.org.uk>, Tony Lindgren <tony@...mide.com>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, Santosh Shilimkar <santosh.shilimkar@...com>, Linux OMAP List <linux-omap@...r.kernel.org>, Linux ARM Kernel List <linux-arm-kernel@...ts.infradead.org> Subject: Re: [PATCH] ARM: OMAP5: Switch to THUMB mode if needed on secondary CPU > On Apr 29, 2014, at 2:17 AM, Dave Martin <Dave.Martin@....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.shilimkar@...com> >>>>> Cc: Russell King <linux@....linux.org.uk> >>>>> Cc: Nishanth Menon <nm@...com> >>>>> Cc: Tony Lindgren <tony@...mide.com> >>>>> Signed-off-by: Joel Fernandes <joelf@...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.shilimkar@...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-kernel@...ts.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 majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists