linaro-pkg team mailing list archive
-
linaro-pkg team
-
Mailing list archive
-
Message #01188
[Bug 918412] Re: OMAP Panda does not boot on Linux-linaro 3.2 branch
** Changed in: linaro-landing-team-ti
Status: New => Won't Fix
--
You received this bug notification because you are a member of Linaro
Maintainers, which is the registrant for Linaro Linux.
https://bugs.launchpad.net/bugs/918412
Title:
OMAP Panda does not boot on Linux-linaro 3.2 branch
Status in Linaro Texas Instruments Landing Team:
Won't Fix
Status in Linaro Linux:
Fix Released
Bug description:
Reported by Andy Green:
Quite early in boot, it blows a new BUG() in the code around
iotable_init(), I added some debug and see it's blowing up when trying
to define io memory in omap_barriers_init(). A bunch of earlier
machine-defined iotable_inits go OK.
[ 0.000000] iotable_init: adding addr=DA000000 size=02000000
phys_addr=9A000000
[ 0.000000] iotable_init: adding addr=F8000000 size=00100000
phys_addr=44000000
[ 0.000000] iotable_init: adding addr=FC000000 size=00400000
phys_addr=4A000000
[ 0.000000] iotable_init: adding addr=F9000000 size=00100000
phys_addr=50000000
[ 0.000000] iotable_init: adding addr=FD100000 size=00100000
phys_addr=4C000000
[ 0.000000] iotable_init: adding addr=FD200000 size=00100000
phys_addr=4D000000
[ 0.000000] iotable_init: adding addr=FD300000 size=00100000
phys_addr=4E000000
[ 0.000000] iotable_init: adding addr=FA000000 size=00400000
phys_addr=48000000
[ 0.000000] iotable_init: adding addr=FE800000 size=00800000
phys_addr=54000000
...
[ 0.538024] omap_barriers_init: calling iotable_init
[ 0.543243] iotable_init: adding addr=FE600000 size=00100000
phys_addr=AF600000
[ 0.550872] ------------[ cut here ]------------
[ 0.555725] Kernel BUG at c087c74c [verbose debug info unavailable]
[ 0.562255] Internal error: Oops - undefined instruction: 0 [#1] PREEMPT SMP
[ 0.569610] Modules linked in:
[ 0.572845] CPU: 1 Tainted: G W
(3.2.0-panda_tracking-topic-syslink-k3u+ #6)
[ 0.581451] PC is at vm_area_add_early+0x20/0x84
[ 0.586303] LR is at iotable_init+0xa8/0xbc
[ 0.590698] pc : [<c087c74c>] lr : [<c086cd48>] psr: 20000113
[ 0.590698] sp : ef78ff54 ip : ef78fe10 fp : 00000000
[ 0.602691] r10: c086cca0 r9 : 00000000 r8 : 40000001
[ 0.608154] r7 : ef7ffee0 r6 : ef78ff90 r5 : ef7ffec0 r4 : 00000001
[ 0.614959] r3 : 00000001 r2 : 00000000 r1 : 00000001 r0 : ef7ffec0
[ 0.621765] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM
Segment kernel
[ 0.629394] Control: 10c5387d Table: 8000404a DAC: 00000015
[ 0.635406] Process swapper/0 (pid: 1, stack limit = 0xef78e2f8)
[ 0.641662] Stack: (0xef78ff54 to 0xef790000)
[ 0.646240] ff40: 00000001 00000000 af600000
[ 0.654754] ff60: c09299e0 ef78e000 00000000 00000000 c0870f8c
c0871070 c08d7f9c c08a7bf8
[ 0.663269] ff80: fe600000 000af600 00100000 0000000e c08a7bfc
c0008870 0000009f c009f590
[ 0.671783] ffa0: 0000009f c0870f8c c0014640 00393531 00000000
c0150000 00000000 c08e5604
[ 0.680297] ffc0: 0000019a c08a7bfc c08a842c c0014640 00000013
00000000 00000000 00000000
[ 0.688812] ffe0: 00000000 c08668bc 00000000 00000000 c0866830
c0014640 55555555 45515555
[ 0.697326] [<c087c74c>] (vm_area_add_early+0x20/0x84) from
[<00000000>] ( (null))
[ 0.705322] Code: 059f3068 01a0c003 05933000 0a000010 (e7f001f2)
[ 0.711700] ---[ end trace 1b75b31a2719ed1d ]---
[ 0.716552] Kernel panic - not syncing: Attempted to kill init!
[ 0.722747] CPU0: stopping
[ 0.725646] [<c001a930>] (unwind_backtrace+0x0/0xf8) from
[<c0018cf8>] (handle_IPI+0x114/0x140)
[ 0.734710] [<c0018cf8>] (handle_IPI+0x114/0x140) from [<c00086c0>]
(gic_handle_irq+0x88/0xac)
[ 0.743682] [<c00086c0>] (gic_handle_irq+0x88/0xac) from
[<c05fa0c0>] (__irq_svc+0x40/0x70)
[ 0.752380] Exception stack(0xc08adf70 to 0xc08adfb8)
[ 0.757659] df60: ffffffed
00000000 c08adfb8 00000000
[ 0.766174] df80: c08ac000 c0929aa8 c0603f50 c08c9bd8 c08c9d98
412fc09a 00000000 00000000
[ 0.774688] dfa0: 00000000 c08adfb8 c00146bc c00146c0 60000013 ffffffff
[ 0.781616] [<c05fa0c0>] (__irq_svc+0x40/0x70) from [<c00146c0>]
(default_idle+0x24/0x28)
[ 0.790130] [<c00146c0>] (default_idle+0x24/0x28) from [<c001493c>]
(cpu_idle+0xfc/0x11c)
[ 0.798645] [<c001493c>] (cpu_idle+0xfc/0x11c) from [<c08667e0>]
(start_kernel+0x260/0x2b0)
[ 0.807342] [<c08667e0>] (start_kernel+0x260/0x2b0) from
[<80008044>] (0x80008044)
You can see what's going on in omap_barriers_init() here:
http://git.linaro.org/gitweb?p=landing-
teams/working/ti/kernel.git;a=blob;f=arch/arm/mach-
omap2/omap4-common.c;h=ad8c30d610736dde454bfe81f764f4a98b902dbf;hb=refs/heads/temp#l97
From Andrey K.:
I haven't dig deep into that, but the rmk's commit 716a3dc20084 description says that
"Several platforms are now using the memblock_alloc+memblock_free+
memblock_remove trick to obtain memory which won't be mapped in the
kernel's page tables. Most platforms do this (correctly) in the
->reserve callback. However, OMAP has started to call these functions
outside of this callback, and this is extremely unsafe - memory will
not be unmapped, and could well be given out after memblock is no
longer responsible for its management."
Vanilla v3.2 kernel patched with "ARM: OMAP4: Fix errata i688 with MPU interconnect barriers" passes omap_barriers_init() ok (but crashes later in my setup). But "v3.2 merged with rmk's devel-stable" kernel encounters a BUG() inside the introduced omap_barriers_init()
(the log is in the original message below). Looks like the "ARM: OMAP4: Fix errata i688 with MPU interconnect barriers" needs to be fixed anyway, but probably there is something in the rmk's devel-stable
tree that makes this issue to the problem with calling the memblock_alloc+memblock_free+memblock_remove functions outside of ->reserve callback to reveal.
To manage notifications about this bug go to:
https://bugs.launchpad.net/linaro-landing-team-ti/+bug/918412/+subscriptions
