OMAP2430 SDP boot broken after Linus' rmk merge

Commit Message

Will Deacon July 27, 2013, 12:22 p.m. UTC

On Sat, Jul 27, 2013 at 05:10:56AM +0100, Paul Walmsley wrote:
> 
> Tonight I put on a Jon Hopkins album, in recollection of my UK ARM Linux 
> colleagues perhaps, and started testing, and eventually wound up with this 
> one:
> 
> commit 621a0147d5c921f4cc33636ccd0602ad5d7cbfbc
> Author: Will Deacon <[e-mail]>

Oh, great...

> Date:   Wed Jun 12 12:25:56 2013 +0100
> 
>     ARM: 7757/1: mm: don't flush icache in switch_mm with hardware broadcasting
>     
>     When scheduling an mm on a CPU where it hasn't previously been used, we
>     flush the icache on that CPU so that any code loaded previously on
>     a different core can be safely executed.
>     
>     For cores with hardware broadcasting of cache maintenance operations,
>     this is clearly unnecessary, since the inner-shareable invalidation in
>     __sync_icache_dcache will affect all CPUs.
>     
>     This patch conditionalises the icache flush in switch_mm based on
>     cache_ops_need_broadcast().
>     
>     Acked-by: Catalin Marinas <[e-mail]>
>     Reported-by: Albin Tonnerre <[e-mail]>
>     Signed-off-by: Will Deacon <[e-mail]>
>     Signed-off-by: Russell King <[e-mail]>
> 
> ...
> 
> v3.11-rc2 boots with it reverted.  What also works is v3.11-rc2 with the 
> below patch applied.

That's very odd -- I *suspect* your bootloader is up to no good (iirc, we've
had issues with the bootloader on this machine in the past, since it enters
the kernel in ABT mode or something).

> Would be pleased to boot-test anything you'd care to send my way, as long 
> as you can tolerate response latency jitter.

Can you try this quick hack please? It clobbers the I-cache as soon as we
enter the kernel, so it should tell us whether my theory is correct.

Cheers,

Will

--->8

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Comments

Paul Walmsley July 28, 2013, 5:38 a.m. UTC | #1

Hi Will,

On Sat, 27 Jul 2013, Will Deacon wrote:

> That's very odd -- I *suspect* your bootloader is up to no good (iirc, we've
> had issues with the bootloader on this machine in the past, since it enters
> the kernel in ABT mode or something).

Maybe you're thinking of the (2420-based) Nokia N800?  The 2430SDP here 
uses u-boot:

http://www.pwsan.com/omap/testlogs/test_v3.10-rc7/20130630191558/boot/2430sdp/

> Can you try this quick hack please? It clobbers the I-cache as soon as we
> enter the kernel, so it should tell us whether my theory is correct.

Tried it and still hangs.  Spent some time debugging - turns out it's due 
to the extended CP15 register read in cache_ops_need_broadcast().. the 
extended regs aren't present on ARM1136 r0* and trigger an undefined 
instruction abort :-(  Sorry about that, should have taken the time to 
send along an earlyprintk trace.  Patches in a few moments -


- Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Patch

diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S
index 9cf6063..d74c64c 100644
--- a/arch/arm/kernel/head.S
+++ b/arch/arm/kernel/head.S
@@ -83,6 +83,9 @@  ENTRY(stext)
  THUMB(        .thumb                  )       @ switch to Thumb now.
  THUMB(1:                      )
 
+       mov     r9, #0
+       mcr     p15, 0, r9, c7, c5, 0
+
 #ifdef CONFIG_ARM_VIRT_EXT
        bl      __hyp_stub_install
 #endif