mx28evk does not boot with linux-next 20130207

mx28evk does not boot with linux-next 20130207

[Fabio Estevam]

Hi,

When booting linux-next 20130207 I get no kernel console output on a
mx28evk. After selecting earlyprintk and CONFIG_DEBUG_LL=y support I
get:

  LD      vmlinux
  SORTEX  vmlinux
sort done marker at 514bcc
  SYSMAP  System.map
  OBJCOPY arch/arm/boot/Image
  Kernel: arch/arm/boot/Image is ready
  GZIP    arch/arm/boot/compressed/piggy.gzip
  AS      arch/arm/boot/compressed/debug.o
arch/arm/boot/compressed/debug.S: Assembler messages:
arch/arm/boot/compressed/debug.S:6: Error: garbage following
instruction -- `ldr
r2,=IOMEM((0xf4000000+((((0x80000000+0x074000))&0x80000000)>>7)+((((0x80000000+0x074000))&0x000fffff))))'

Is this a known issue?

Regards,

Fabio Estevam

mx28evk does not boot with linux-next 20130207

[Shawn Guo]

On Thu, Feb 07, 2013 at 09:47:58AM -0200, Fabio Estevam wrote:
> Hi,
> 
> When booting linux-next 20130207 I get no kernel console output on a
> mx28evk. After selecting earlyprintk and CONFIG_DEBUG_LL=y support I
> get:
> 
>   LD      vmlinux
>   SORTEX  vmlinux
> sort done marker at 514bcc
>   SYSMAP  System.map
>   OBJCOPY arch/arm/boot/Image
>   Kernel: arch/arm/boot/Image is ready
>   GZIP    arch/arm/boot/compressed/piggy.gzip
>   AS      arch/arm/boot/compressed/debug.o
> arch/arm/boot/compressed/debug.S: Assembler messages:
> arch/arm/boot/compressed/debug.S:6: Error: garbage following
> instruction -- `ldr
> r2,=IOMEM((0xf4000000+((((0x80000000+0x074000))&0x80000000)>>7)+((((0x80000000+0x074000))&0x000fffff))))'
> 
> Is this a known issue?
> 
Yes.  The following change should fix the problem.

Shawn

diff --git a/arch/arm/boot/compressed/debug.S
b/arch/arm/boot/compressed/debug.S
index bdb0e25..6e8382d 100644
--- a/arch/arm/boot/compressed/debug.S
+++ b/arch/arm/boot/compressed/debug.S
@@ -1,4 +1,5 @@
 #include <linux/linkage.h>
+#include <asm/assembler.h>

 #include CONFIG_DEBUG_LL_INCLUDE

mx28evk does not boot with linux-next 20130207

[Fabio Estevam]

On Thu, Feb 7, 2013 at 10:58 AM, Shawn Guo <shawn.guo@linaro.org> wrote:
> On Thu, Feb 07, 2013 at 09:47:58AM -0200, Fabio Estevam wrote:
>> Hi,
>>
>> When booting linux-next 20130207 I get no kernel console output on a
>> mx28evk. After selecting earlyprintk and CONFIG_DEBUG_LL=y support I
>> get:
>>
>>   LD      vmlinux
>>   SORTEX  vmlinux
>> sort done marker at 514bcc
>>   SYSMAP  System.map
>>   OBJCOPY arch/arm/boot/Image
>>   Kernel: arch/arm/boot/Image is ready
>>   GZIP    arch/arm/boot/compressed/piggy.gzip
>>   AS      arch/arm/boot/compressed/debug.o
>> arch/arm/boot/compressed/debug.S: Assembler messages:
>> arch/arm/boot/compressed/debug.S:6: Error: garbage following
>> instruction -- `ldr
>> r2,=IOMEM((0xf4000000+((((0x80000000+0x074000))&0x80000000)>>7)+((((0x80000000+0x074000))&0x000fffff))))'
>>
>> Is this a known issue?
>>
> Yes.  The following change should fix the problem.

Yes, it fixes the build issue and now I get:

Uncompressing Linux... done, booting the kernel.
[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 3.8.0-rc6-next-20130207-dirty
(fabio at fabio-Latitude-E6410) (gcc version 4.4.4 (4.4.4_09.06.2010) )
#1062
Thu Feb 7 16:00:51 BRST 2013
[    0.000000] CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177
[    0.000000] CPU: VIVT data cache, VIVT instruction cache
[    0.000000] Machine: Freescale i.MX28 (Device Tree), model:
Freescale i.MX28 Evaluation Kit
[    0.000000] bootconsole [earlycon0] enabled
[    0.000000] Memory policy: ECC disabled, Data cache writeback
[    0.000000] Internal error: Oops - undefined instruction: 0 [#1] ARM
[    0.000000] Modules linked in:
[    0.000000] CPU: 0    Not tainted  (3.8.0-rc6-next-20130207-dirty #1062)
[    0.000000] PC is at paging_init+0x63c/0x6fc
[    0.000000] LR is at paging_init+0x614/0x6fc
[    0.000000] pc : [<c04fc48c>]    lr : [<c04fc464>]    psr: 600000d3
[    0.000000] sp : c051df60  ip : 00100000  fp : 000000cf
[    0.000000] r10: 0000000f  r9 : 000001cf  r8 : 00000009
[    0.000000] r7 : c051df68  r6 : c0531f20  r5 : f5100000  r4 : 00000000
[    0.000000] r3 : 20000001  r2 : f5200000  r1 : f5100000  r0 : c7ffdfa0
[    0.000000] Flags: nZCv  IRQs off  FIQs off  Mode SVC_32  ISA ARM
Segment kernel
[    0.000000] Control: 0005317f  Table: 40004000  DAC: 00000017
[    0.000000] Process swapper (pid: 0, stack limit = 0xc051c1b8)
[    0.000000] Stack: (0xc051df60 to 0xc051e000)
[    0.000000] df60: 00000000 c0513270 ffff0000 00047fff 00001000
00000008 41069265 c0513270
[    0.000000] df80: c0558534 40008000 c05141e0 c051dfdc 41069265
4051323c 00000000 c04f9d34
[    0.000000] dfa0: 00000000 00053177 00000001 c052403c c05141dc
c05278bc 40004000 41069265
[    0.000000] dfc0: 4051323c c04f8630 00000000 00000000 00000000
00000000 00000000 c05141e0
[    0.000000] dfe0: 00000000 00053175 c052403c c05141dc c05278bc
40008040 00000000 00000000
[    0.000000] [<c04fc48c>] (paging_init+0x63c/0x6fc) from
[<c04f9d34>] (setup_arch+0x340/0x5b4)
[    0.000000] [<c04f9d34>] (setup_arch+0x340/0x5b4) from [<c04f8630>]
(start_kernel+0x74/0x298)
[    0.000000] [<c04f8630>] (start_kernel+0x74/0x298) from
[<40008040>] (0x40008040)
[    0.000000] Code: 1affffd9 ee074f9a ee084f16 ee084f15 (ee074fd5)
[    0.000000] ---[ end trace 1b75b31a2719ed1c ]---
[    0.000000] Kernel panic - not syncing: Attempted to kill the idle task!

mx28evk does not boot with linux-next 20130207

[Russell King - ARM Linux]

On Thu, Feb 07, 2013 at 04:04:58PM -0200, Fabio Estevam wrote:
> Yes, it fixes the build issue and now I get:

Hmm, interesting...

> Uncompressing Linux... done, booting the kernel.
> [    0.000000] Booting Linux on physical CPU 0x0
> [    0.000000] Linux version 3.8.0-rc6-next-20130207-dirty
> (fabio at fabio-Latitude-E6410) (gcc version 4.4.4 (4.4.4_09.06.2010) )
> #1062
> Thu Feb 7 16:00:51 BRST 2013
> [    0.000000] CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177

Ok, so this is an ARMv5 kernel.

> [    0.000000] CPU: 0    Not tainted  (3.8.0-rc6-next-20130207-dirty #1062)
> [    0.000000] PC is at paging_init+0x63c/0x6fc
> [    0.000000] LR is at paging_init+0x614/0x6fc
> [    0.000000] pc : [<c04fc48c>]    lr : [<c04fc464>]    psr: 600000d3
> [    0.000000] sp : c051df60  ip : 00100000  fp : 000000cf
> [    0.000000] r10: 0000000f  r9 : 000001cf  r8 : 00000009
> [    0.000000] r7 : c051df68  r6 : c0531f20  r5 : f5100000  r4 : 00000000
> [    0.000000] r3 : 20000001  r2 : f5200000  r1 : f5100000  r0 : c7ffdfa0
...
> [    0.000000] Code: 1affffd9 ee074f9a ee084f16 ee084f15 (ee074fd5)

And this is failing at:

   0:	1affffd9 	bne	0xffffff6c
   4:	ee074f9a 	mcr	15, 0, r4, cr7, cr10, {4}
   8:	ee084f16 	mcr	15, 0, r4, cr8, cr6, {0}
   c:	ee084f15 	mcr	15, 0, r4, cr8, cr5, {0}
  10:	ee074fd5 	mcr	15, 0, r4, cr7, cr5, {6}

which is local_flush_tlb_all().  The last instruction is the faulting
instruction - because ARM926 doesn't have it... and... that was introduced
by:

commit 5d9e3f9d7fcd7d09feb5d23974768a60bcea4094
Author: Will Deacon <will.deacon@arm.com>
Date:   Thu Jan 31 19:15:49 2013 +0100

    ARM: 7636/1: tlb: perform branch predictor maintenance for whole invalidation
    
    The ARM architecture requires explicit branch predictor maintenance
    when updating an instruction stream for a given virtual address. In
    reality, this isn't so much of a burden because the branch predictor
    is flushed during the cache maintenance required to make the new
    instructions visible to the I-side of the processor.
    
    One exception to this rule is when we flush the entire TLB for a CPU in
    response to something other than writing new instructions (for example,
    ASID rollover or switching to an identity mapping before disabling the
    MMU).
    
    This patch ensures that we flush the branch predictor as part of
    invalidating the entire TLB.
    
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

And this patch looking at it now, is obviously wrong.  Will, can you
take a look please?

Also note - we used to do BTB maintanence, but I dropped it in this
commit after discussing it with folk in ARM:

commit 4348810a241a330d3d143d62d7c988ec8b2e6629
Author: Russell King <rmk+kernel@arm.linux.org.uk>
Date:   Tue Jul 5 09:01:13 2011 +0100

    ARM: btc: avoid invalidating the branch target cache on kernel TLB maintanence
    
    Kernel space needs very little in the way of BTC maintanence as most
    mappings which are created and destroyed are non-executable, and so
    could never enter the instruction stream.
    
    The case which does warrant BTC maintanence is when a module is loaded.
    This creates a new executable mapping, but at that point the pages have
    not been initialized with code and data, so at that point they contain
    unpredictable information.  Invalidating the BTC at this stage serves
    little useful purpose.
    
    Before we execute module code, we call flush_icache_range(), which deals
    with the BTC maintanence requirements.  This ensures that we have a BTC
    maintanence operation before we execute code via the newly created
    mapping.
    
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

So, I think we can do away entirely with your patch.

mx28evk does not boot with linux-next 20130207

[Will Deacon]

On Fri, Feb 08, 2013 at 04:18:11PM +0000, Russell King - ARM Linux wrote:
> Ok, so this is an ARMv5 kernel.

[...]

> And this is failing at:
> 
>    0:	1affffd9 	bne	0xffffff6c
>    4:	ee074f9a 	mcr	15, 0, r4, cr7, cr10, {4}
>    8:	ee084f16 	mcr	15, 0, r4, cr8, cr6, {0}
>    c:	ee084f15 	mcr	15, 0, r4, cr8, cr5, {0}
>   10:	ee074fd5 	mcr	15, 0, r4, cr7, cr5, {6}
> 
> which is local_flush_tlb_all().  The last instruction is the faulting
> instruction - because ARM926 doesn't have it... and... that was introduced
> by:
> 
> commit 5d9e3f9d7fcd7d09feb5d23974768a60bcea4094
> Author: Will Deacon <will.deacon@arm.com>
> Date:   Thu Jan 31 19:15:49 2013 +0100
> 
>     ARM: 7636/1: tlb: perform branch predictor maintenance for whole invalidation

[...]

> And this patch looking at it now, is obviously wrong.  Will, can you
> take a look please?

Ah yes, this should be predicated on v6+. Sorry about that -- please see the
patch below.

> Also note - we used to do BTB maintanence, but I dropped it in this
> commit after discussing it with folk in ARM:
> 
> commit 4348810a241a330d3d143d62d7c988ec8b2e6629
> Author: Russell King <rmk+kernel@arm.linux.org.uk>
> Date:   Tue Jul 5 09:01:13 2011 +0100
> 
>     ARM: btc: avoid invalidating the branch target cache on kernel TLB maintanence
>     
>     Kernel space needs very little in the way of BTC maintanence as most
>     mappings which are created and destroyed are non-executable, and so
>     could never enter the instruction stream.
>     
>     The case which does warrant BTC maintanence is when a module is loaded.
>     This creates a new executable mapping, but at that point the pages have
>     not been initialized with code and data, so at that point they contain
>     unpredictable information.  Invalidating the BTC at this stage serves
>     little useful purpose.
>     
>     Before we execute module code, we call flush_icache_range(), which deals
>     with the BTC maintanence requirements.  This ensures that we have a BTC
>     maintanence operation before we execute code via the newly created
>     mapping.
>     
>     Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> 
> So, I think we can do away entirely with your patch.

Unfortunately, we do need to add the maintenance for things like changing to
the idmap and ASID rollover, which is what prompted me to write the patch in
the first place (after discussion with Richard).

It's worth noting that this is one area where the micro-architecture
typically makes life easy for software, and the invalidation may well
execute as a nop.

Will

--->8

>From dc381a5dff9663901a61fe0dd86c986add382281 Mon Sep 17 00:00:00 2001
From: Will Deacon <will.deacon@arm.com>
Date: Fri, 8 Feb 2013 16:41:19 +0000
Subject: [PATCH] ARM: tlb: fix branch predictor maintenance for ARMv6

The BPIALL operation is not available on all CPUs, so ensure that we
only execute it on processors implementing the instruction.

Reported-by: Fabio Estevam <festevam@gmail.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
 arch/arm/include/asm/tlbflush.h | 17 ++++++++++-------
 1 file changed, 10 insertions(+), 7 deletions(-)

diff --git a/arch/arm/include/asm/tlbflush.h b/arch/arm/include/asm/tlbflush.h
index 713ff32..e6bd71f 100644
--- a/arch/arm/include/asm/tlbflush.h
+++ b/arch/arm/include/asm/tlbflush.h
@@ -34,11 +34,13 @@
 #define TLB_V6_D_ASID	(1 << 17)
 #define TLB_V6_I_ASID	(1 << 18)
 
+#define TLB_V6_BP	(1 << 19)
+
 /* Unified Inner Shareable TLB operations (ARMv7 MP extensions) */
-#define TLB_V7_UIS_PAGE	(1 << 19)
-#define TLB_V7_UIS_FULL (1 << 20)
-#define TLB_V7_UIS_ASID (1 << 21)
-#define TLB_V7_UIS_BP	(1 << 22)
+#define TLB_V7_UIS_PAGE	(1 << 20)
+#define TLB_V7_UIS_FULL (1 << 21)
+#define TLB_V7_UIS_ASID (1 << 22)
+#define TLB_V7_UIS_BP	(1 << 23)
 
 #define TLB_BARRIER	(1 << 28)
 #define TLB_L2CLEAN_FR	(1 << 29)		/* Feroceon */
@@ -151,7 +153,8 @@
 #define v6wbi_tlb_flags (TLB_WB | TLB_DCLEAN | TLB_BARRIER | \
 			 TLB_V6_I_FULL | TLB_V6_D_FULL | \
 			 TLB_V6_I_PAGE | TLB_V6_D_PAGE | \
-			 TLB_V6_I_ASID | TLB_V6_D_ASID)
+			 TLB_V6_I_ASID | TLB_V6_D_ASID | \
+			 TLB_V6_BP)
 
 #ifdef CONFIG_CPU_TLB_V6
 # define v6wbi_possible_flags	v6wbi_tlb_flags
@@ -171,7 +174,7 @@
 				 TLB_V7_UIS_ASID | TLB_V7_UIS_BP)
 #define v7wbi_tlb_flags_up	(TLB_WB | TLB_DCLEAN | TLB_BARRIER | \
 				 TLB_V6_U_FULL | TLB_V6_U_PAGE | \
-				 TLB_V6_U_ASID)
+				 TLB_V6_U_ASID | TLB_V6_BP)
 
 #ifdef CONFIG_CPU_TLB_V7
 
@@ -335,7 +338,7 @@ static inline void local_flush_tlb_all(void)
 
 	if (tlb_flag(TLB_V7_UIS_BP))
 		asm("mcr p15, 0, %0, c7, c1, 6" : : "r" (zero));
-	else
+	else if (tlb_flag(TLB_V6_BP))
 		asm("mcr p15, 0, %0, c7, c5, 6" : : "r" (zero));
 
 	if (tlb_flag(TLB_BARRIER)) {
-- 
1.8.0

mx28evk does not boot with linux-next 20130207

[Fabio Estevam]

On Fri, Feb 8, 2013 at 2:48 PM, Will Deacon <will.deacon@arm.com> wrote:

> From dc381a5dff9663901a61fe0dd86c986add382281 Mon Sep 17 00:00:00 2001
> From: Will Deacon <will.deacon@arm.com>
> Date: Fri, 8 Feb 2013 16:41:19 +0000
> Subject: [PATCH] ARM: tlb: fix branch predictor maintenance for ARMv6
>
> The BPIALL operation is not available on all CPUs, so ensure that we
> only execute it on processors implementing the instruction.
>
> Reported-by: Fabio Estevam <festevam@gmail.com>
> Signed-off-by: Will Deacon <will.deacon@arm.com>

Thanks, Will.

This makes the kernel to boot again on my mx28evk, so:

Tested-by: Fabio Estevam <fabio.estevam@freescale.com>

There are still other issues, which seem to be unrelated to this fix though:

I can see the Linux logo and LED activity on my board, but no serial console.

Applying Shawn's patch:

diff --git a/arch/arm/boot/compressed/debug.S
b/arch/arm/boot/compressed/debug.S
index bdb0e25..6e8382d 100644
--- a/arch/arm/boot/compressed/debug.S
+++ b/arch/arm/boot/compressed/debug.S
@@ -1,4 +1,5 @@
 #include <linux/linkage.h>
+#include <asm/assembler.h>

 #include CONFIG_DEBUG_LL_INCLUDE

and turning on earlyprintk I see kernel booting and it stops at:

[    5.311281] TCP: cubic registered
[    5.315000] NET: Registered protocol family 17
[    5.320843] Key type dns_resolver registered
[    5.325750] turn off boot console earlycon0

Regards,

Fabio Estevam

mx28evk does not boot with linux-next 20130207

[Marek Vasut]

Dear Fabio Estevam,

> On Fri, Feb 8, 2013 at 2:48 PM, Will Deacon <will.deacon@arm.com> wrote:
> > From dc381a5dff9663901a61fe0dd86c986add382281 Mon Sep 17 00:00:00 2001
> > From: Will Deacon <will.deacon@arm.com>
> > Date: Fri, 8 Feb 2013 16:41:19 +0000
> > Subject: [PATCH] ARM: tlb: fix branch predictor maintenance for ARMv6
> > 
> > The BPIALL operation is not available on all CPUs, so ensure that we
> > only execute it on processors implementing the instruction.
> > 
> > Reported-by: Fabio Estevam <festevam@gmail.com>
> > Signed-off-by: Will Deacon <will.deacon@arm.com>
> 
> Thanks, Will.
> 
> This makes the kernel to boot again on my mx28evk, so:
> 
> Tested-by: Fabio Estevam <fabio.estevam@freescale.com>
> 
> There are still other issues, which seem to be unrelated to this fix
> though:
> 
> I can see the Linux logo and LED activity on my board, but no serial
> console.
> 
> Applying Shawn's patch:
> 
> diff --git a/arch/arm/boot/compressed/debug.S
> b/arch/arm/boot/compressed/debug.S
> index bdb0e25..6e8382d 100644
> --- a/arch/arm/boot/compressed/debug.S
> +++ b/arch/arm/boot/compressed/debug.S
> @@ -1,4 +1,5 @@
>  #include <linux/linkage.h>
> +#include <asm/assembler.h>
> 
>  #include CONFIG_DEBUG_LL_INCLUDE
> 
> and turning on earlyprintk I see kernel booting and it stops at:
> 
> [    5.311281] TCP: cubic registered
> [    5.315000] NET: Registered protocol family 17
> [    5.320843] Key type dns_resolver registered
> [    5.325750] turn off boot console earlycon0

Is the amba-pl011 driver maybe broken ?

So far, Wills' and Shawns' patches got me further too, thanks!

Best regards,
Marek Vasut

mx28evk does not boot with linux-next 20130207

[Fabio Estevam]

On Sun, Feb 10, 2013 at 1:28 AM, Marek Vasut <marex@denx.de> wrote:

> Is the amba-pl011 driver maybe broken ?

At least on mx28evk, ttyAMA0 is not getting registered when running linux-next.

I haven't had a chance to debug it though.

mx28evk does not boot with linux-next 20130207

[Fabio Estevam]

On Sun, Feb 10, 2013 at 1:28 AM, Marek Vasut <marex@denx.de> wrote:

> Is the amba-pl011 driver maybe broken ?

Running Linus' git I get:

[    0.189156] Serial: AMBA PL011 UART driver
[    0.191187] 80074000.serial: ttyAMA0 at MMIO 0x80074000 (irq = 221)
is a PL011 rev2
[    0.487625] console [ttyAMA0] enabled

,but when I run linux-next only the first line shows up.

mx28evk does not boot with linux-next 20130207

[Fabio Estevam]

Hi Will,

On Fri, Feb 8, 2013 at 3:14 PM, Fabio Estevam <festevam@gmail.com> wrote:
> On Fri, Feb 8, 2013 at 2:48 PM, Will Deacon <will.deacon@arm.com> wrote:
>
>> From dc381a5dff9663901a61fe0dd86c986add382281 Mon Sep 17 00:00:00 2001
>> From: Will Deacon <will.deacon@arm.com>
>> Date: Fri, 8 Feb 2013 16:41:19 +0000
>> Subject: [PATCH] ARM: tlb: fix branch predictor maintenance for ARMv6
>>
>> The BPIALL operation is not available on all CPUs, so ensure that we
>> only execute it on processors implementing the instruction.
>>
>> Reported-by: Fabio Estevam <festevam@gmail.com>
>> Signed-off-by: Will Deacon <will.deacon@arm.com>
>
> Thanks, Will.
>
> This makes the kernel to boot again on my mx28evk, so:
>
> Tested-by: Fabio Estevam <fabio.estevam@freescale.com>

Do you plan to submit this patch to Russell's patch system?

Thanks,

Fabio Estevam

mx28evk does not boot with linux-next 20130207

[Russell King - ARM Linux]

On Sat, Feb 16, 2013 at 03:41:53PM -0200, Fabio Estevam wrote:
> Hi Will,
> 
> On Fri, Feb 8, 2013 at 3:14 PM, Fabio Estevam <festevam@gmail.com> wrote:
> > On Fri, Feb 8, 2013 at 2:48 PM, Will Deacon <will.deacon@arm.com> wrote:
> >
> >> From dc381a5dff9663901a61fe0dd86c986add382281 Mon Sep 17 00:00:00 2001
> >> From: Will Deacon <will.deacon@arm.com>
> >> Date: Fri, 8 Feb 2013 16:41:19 +0000
> >> Subject: [PATCH] ARM: tlb: fix branch predictor maintenance for ARMv6
> >>
> >> The BPIALL operation is not available on all CPUs, so ensure that we
> >> only execute it on processors implementing the instruction.
> >>
> >> Reported-by: Fabio Estevam <festevam@gmail.com>
> >> Signed-off-by: Will Deacon <will.deacon@arm.com>
> >
> > Thanks, Will.
> >
> > This makes the kernel to boot again on my mx28evk, so:
> >
> > Tested-by: Fabio Estevam <fabio.estevam@freescale.com>
> 
> Do you plan to submit this patch to Russell's patch system?

No, I've suggested to Will that we deal with the branch predictor a
different way, because we actually rarely need to flush it.  Plus,
these patches are architecturally wrong (you're not allowed to branch
between the BP maintanence instruction and the following isb/dsb
instructions because the branches become "unpredictable".

Plus, we _used_ to flush the BP here, and I did an amount of work to
remove the flushing because it just wasn't necessary - all the paths
at that time just didn't require it.

What we have ended up with today is a couple of paths which do, both
of which are arch-specific code, and we should deal with that in an
arch specific way.  Will has been working on a patch to do that...

In the mean time, I'm dropping 5d9e3f9d7fcd7d09feb5d23974768a60bcea4094
which added the BP maintanence (I actually said to Will that I'd already
done this but it appears not.)

mx28evk does not boot with linux-next 20130207

[Shawn Guo]

On Sun, Feb 10, 2013 at 02:26:11PM -0200, Fabio Estevam wrote:
> On Sun, Feb 10, 2013 at 1:28 AM, Marek Vasut <marex@denx.de> wrote:
> 
> > Is the amba-pl011 driver maybe broken ?
> 
> At least on mx28evk, ttyAMA0 is not getting registered when running linux-next.
> 
> I haven't had a chance to debug it though.

Try reverting commit aac73f3 (of: use platform_device_add) and see if it
helps.

Shawn

mx28evk does not boot with linux-next 20130207

[Will Deacon]

On Sat, Feb 16, 2013 at 05:56:13PM +0000, Russell King - ARM Linux wrote:
> On Sat, Feb 16, 2013 at 03:41:53PM -0200, Fabio Estevam wrote:
> > Hi Will,

Hello,

> > On Fri, Feb 8, 2013 at 3:14 PM, Fabio Estevam <festevam@gmail.com> wrote:
> > Do you plan to submit this patch to Russell's patch system?
> 
> No, I've suggested to Will that we deal with the branch predictor a
> different way, because we actually rarely need to flush it.  Plus,
> these patches are architecturally wrong (you're not allowed to branch
> between the BP maintanence instruction and the following isb/dsb
> instructions because the branches become "unpredictable".

I think the branches are actually ok, because the code in question (that is,
the kernel code dispatching to and performing the flush) is mapped
identically before and after the page table switch.

> Plus, we _used_ to flush the BP here, and I did an amount of work to
> remove the flushing because it just wasn't necessary - all the paths
> at that time just didn't require it.

This is the killer argument. We don't need the maintenance except in a few,
tiny places. I've written some patches for that and I'll post them to the
list in due course, aiming for 3.10.

> What we have ended up with today is a couple of paths which do, both
> of which are arch-specific code, and we should deal with that in an
> arch specific way.  Will has been working on a patch to do that...

Yup. I've also been looking at TLB invalidation as a whole and some
optimisations we can do on ARMv7 where we don't *actually* need to use the
inner-shareable variants. Non-shareable often suffices and is a win in terms
of both performance and power (it makes the deferred flushing on ASID
rollover usable by v7 too). Again, I've been hacking in this area so I'll
post patches for review once I've got a coherent story.

> In the mean time, I'm dropping 5d9e3f9d7fcd7d09feb5d23974768a60bcea4094
> which added the BP maintanence (I actually said to Will that I'd already
> done this but it appears not.)

Thanks Russell.

Will