On Tuesday 24 September 2013 01:08 PM, Will Deacon wrote: > Hi Santosh, > > On Tue, Aug 13, 2013 at 02:31:04PM +0100, Santosh Shilimkar wrote: >> On Tuesday 13 August 2013 07:19 AM, Will Deacon wrote: >>> On Mon, Aug 12, 2013 at 07:34:13PM +0100, Santosh Shilimkar wrote: >>>> On Friday 02 August 2013 11:48 AM, Will Deacon wrote: >>>>> I think this an A9-specific register, which reads as 0 on UP A9 and reads as >>>>> some form of PERIPH_BASE for SMP parts. The issue I have is when PERIPH_BASE >>>>> is zero. >>>>> >>>> What do we do here ? Should we document this in the code and proceed ? >>>> Mostly there is no platform with PERIPH_BASE = 0, so its should be fine but >>>> I am open for any other alternative. >>> >>> The only other alternative I can think of is forcing people to have >>> CONFIG_SMP=n, but that blows away single zImage for your platform. >>> >> Yep which surely we don't want considering after so much effort we >> have it working first place. How about going ahead with assumption >> that PERIPH_BASE = 0 case doesn't work. > > It's been over a month and I can't think of anything better than this > without jeopardising the single zImage effort. However, it also doesn't seem > fair if we rule out the possibility of single zImage for future SoCs which > use 0x0 as their PERIPH_BASE (I don't know of any at the moment). > > So how about we go ahead with this, but add a big fat comment to the code in > head.S saying that, if a future SoC *does* use 0x0 as the PERIPH_BASE, then > the check will need to be #ifdef'd or equivalent for the Aegis platform? > I agree. Updated patch end of the email. If you are fine with this version, will stick it into RMK's patch system. Regards, Santosh >From 05b1b43324f3e8d10a38f78dbcbf7632d4c3530c Mon Sep 17 00:00:00 2001 From: Vaibhav Bedia <vaibhav.bedia@xxxxxx> Date: Thu, 18 Jul 2013 13:01:53 -0400 Subject: [PATCH] ARM: Update SMP_ON_UP code to detect A9MPCore with 1 CPU devices The generic code is well equipped to differentiate between SMP and UP configurations.However, there are some devices which use Cortex-A9 MP core IP with 1 CPU as configuration. To let these SOCs to co-exist in a CONFIG_SMP=y build by leveraging the SMP_ON_UP support, we need to additionally check the number the cores in Cortex-A9 MPCore configuration. Without such a check in place, the startup code tries to execute ALT_SMP() set of instructions which lead to CPU faults. The issue was spotted on TI's Aegis device and this patch makes now the device work with omap2plus_defconfig which enables SMP by default. The change is kept limited to only Cortex-A9 MPCore detection code. Note that if any future SoC *does* use 0x0 as the PERIPH_BASE, then the SCU address check code needs to be #ifdef'd for for the Aegis platform. Cc: Will Deacon <will.deacon@xxxxxxx> Cc: Russell King <linux@xxxxxxxxxxxxxxxx> Acked-by: Sricharan R <r.sricharan@xxxxxx> Signed-off-by: Vaibhav Bedia <vaibhav.bedia@xxxxxx> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@xxxxxx> --- arch/arm/kernel/head.S | 21 ++++++++++++++++++++- 1 file changed, 20 insertions(+), 1 deletion(-) diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S index 2c7cc1e..476de57 100644 --- a/arch/arm/kernel/head.S +++ b/arch/arm/kernel/head.S @@ -487,7 +487,26 @@ __fixup_smp: mrc p15, 0, r0, c0, c0, 5 @ read MPIDR and r0, r0, #0xc0000000 @ multiprocessing extensions and teq r0, #0x80000000 @ not part of a uniprocessor system? - moveq pc, lr @ yes, assume SMP + bne __fixup_smp_on_up @ no, assume UP + + @ Core indicates it is SMP. Check for Aegis SOC where a single + @ Cortex-A9 CPU is present but SMP operations fault. + mov r4, #0x41000000 + orr r4, r4, #0x0000c000 + orr r4, r4, #0x00000090 + teq r3, r4 @ Check for ARM Cortex-A9 + movne pc, lr @ Not ARM Cortex-A9, + + @ If a future SoC *does* use 0x0 as the PERIPH_BASE, then the + @ below address check will need to be #ifdef'd or equivalent + @ for the Aegis platform. + mrc p15, 4, r0, c15, c0 @ get SCU base address + teq r0, #0x0 @ '0' on actual UP A9 hardware + beq __fixup_smp_on_up @ So its an A9 UP + ldr r0, [r0, #4] @ read SCU Config + and r0, r0, #0x3 @ number of CPUs + teq r0, #0x0 @ is 1? + movne pc, lr __fixup_smp_on_up: adr r0, 1f -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
