[U-Boot] arm: mvebu: u-boot does not start on db-88f6820-gp

[Stefan Roese]

Hi Stefan,

On 11.09.2015 15:50, Stefan Eichenberger wrote:
> On 09/04/2015 06:44 PM, Stefan Roese wrote:
>
>>> Unfortunately u-boot now hangs if I try to load an image from the
>>> SD-Card:
>>> e.g. if I run the following command u-boot hangs:
>>> ext4load mmc 0:2 0x2000000 /boot/kernel.bin
>>>
>>> I don't see why exactly it crashes, it seems for me that it's always at
>>> a different position.
>>>
>>> Here are two backtraces, always at a different positions:
>>>
>>> Here u-boot stopped automatically:
>>> Program received signal SIGTRAP, Trace/breakpoint trap.
>>> 0x7ff65d84 in ?? ()
>>> (gdb) backtrace
>>> #0  0x7ff65d84 in ?? ()
>>> #1  0x803663d0 in ?? ()
>>> #2  0x803663d0 in ?? ()
>>> Backtrace stopped: previous frame identical to this frame (corrupt
>>> stack?)
>>>
>>> And here I've got perhaps some more information?
>>> Program received signal SIGSTOP, Stopped (signal).
>>> v7_inval_dcache_level_setway (log2_line_len=<optimized out>,
>>> way_shift=<optimized out>, num_ways=<optimized out>,
>>>      num_sets=<optimized out>, level=<optimized out>) at
>>> arch/arm/cpu/armv7/cache_v7.c:62
>>> 62                      for (set = num_sets - 1; set >= 0; set--) {
>>> (gdb) backtrace
>>> #0  v7_inval_dcache_level_setway (log2_line_len=<optimized out>,
>>> way_shift=<optimized out>,
>>>      num_ways=<optimized out>, num_sets=<optimized out>,
>>> level=<optimized out>) at arch/arm/cpu/armv7/cache_v7.c:62
>>> #1  v7_maint_dcache_level_setway (operation=<optimized out>, level=9) at
>>> arch/arm/cpu/armv7/cache_v7.c:129
>>> #2  v7_maint_dcache_all (operation=2146852864) at
>>> arch/arm/cpu/armv7/cache_v7.c:147
>>> #3  0xfffffbe2 in ?? ()
>>> #4  0xfffffbe2 in ?? ()
>>>
>>> Could it be that there is something wrong with cache/dram setup?
>>
>> Maybe. Hard to tell. Why don't you use "dcache off" before you start
>> the command. If this works, then we still have a problem with cache
>> (L1 / L2)...
>
> I now did some tests, it seems that the kernel only crashes if I access
> the SD-Card, I'm able to load the kernel from an USB-Device. I tried to
> disable the dcache but the problem still remains.
>
> Another problem I have is that if I try to start a mainline kernel, it
> will crash with the following trace, I think it doesn't find the
> devicetree for some reasons:

Didn't you mention above, that booting Linux does work when booted via 
USB? Is this crash below a caused by accessing the SD-card?

> ## Booting kernel from Legacy Image at 02000000 ...
>     Image Name:
>     Image Type:   ARM Linux Kernel Image (uncompressed)
>     Data Size:    7258976 Bytes = 6.9 MiB
>     Load Address: 00008000
>     Entry Point:  00008000
>     Verifying Checksum ... OK
> ## Flattened Device Tree blob at 03000000
>     Booting using the fdt blob at 0x3000000
>     Loading Kernel Image ... OK
>     Loading Device Tree to 7fb49000, end 7fb4ee70 ... OK
>
> Starting kernel ...
>
> [    0.000000] Booting Linux on physical CPU 0x0
> [    0.000000] Linux version 4.2.0 (eichenberger at gruene) (gcc version
> 4.6.4 (Marvell GCC release 20150204-c4af733b 645
> [    0.000000] CPU: ARMv7 Processor [414fc091] revision 1 (ARMv7),
> cr=10c5387d
> [    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing
> instruction cache
> [    0.000000] Machine model: Marvell Armada 385 Development Board
> [    0.000000] bootconsole [earlycon0] enabled
> [    0.000000] Memory policy: Data cache writealloc
> [    0.000000] Unable to handle kernel paging request at virtual address
> 3fb49000
> [    0.000000] pgd = c0004000
> [    0.000000] [3fb49000] *pgd=00000000
> [    0.000000] Internal error: Oops: 5 [#1] SMP ARM
> [    0.000000] Modules linked in:
> [    0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 4.2.0 #67
> [    0.000000] Hardware name: Marvell Armada 380/385 (Device Tree)
> [    0.000000] task: c06bd528 ti: c06b8000 task.ti: c06b8000
> [    0.000000] PC is at fdt_check_header+0x0/0x78
> [    0.000000] LR is at __unflatten_device_tree+0x1c/0x12c
> [    0.000000] pc : [<c04d960c>]    lr : [<c039419c>] psr: 200001d3
> [    0.000000] sp : c06b9f38  ip : 00000000  fp : ef7fce40
> [    0.000000] r10: c071d2f0  r9 : c05c4d7c  r8 : 3fb49000
> [    0.000000] r7 : c069454c  r6 : c06be514  r5 : c0712f68  r4 : c069454c
> [    0.000000] r3 : c071d308  r2 : c069454c  r1 : c071d2f0  r0 : 3fb49000
> [    0.000000] Flags: nzCv  IRQs off  FIQs off  Mode SVC_32  ISA ARM
> Segment kernel
> [    0.000000] Control: 10c5387d  Table: 0000404a  DAC: 00000015
> [    0.000000] Process swapper (pid: 0, stack limit = 0xc06b8220)
> [    0.000000] Stack: (0xc06b9f38 to 0xc06ba000)
> [    0.000000]
> 9f20:                                                       ffffffff
> c0700000
> [    0.000000] 9f40: ffff1000 0002f7ff 00001000 00000007 c069e348
> c069454c c0712f68 c06be514
> [    0.000000] 9f60: c06c2dc0 c06be514 0000000c c069514c c069e348
> c0679448 ffffffff 10c5387d
> [    0.000000] 9f80: 414fc091 00000000 00000000 c005aa68 c05c38cc
> c06b9fb4 00000000 00000000
> [    0.000000] 9fa0: 00000001 ffffffff c06f4380 00000000 414fc091
> 00000000 00000000 c067693c
> [    0.000000] 9fc0: 00000000 00000000 00000000 00000000 00000000
> c06a9288 00000000 c06f4614
> [    0.000000] 9fe0: c06ba4c0 c06a9284 c06be624 0000406a 00000000
> 0000807c 00000000 00000000
> [    0.000000] [<c04d960c>] (fdt_check_header) from [<c039419c>]
> (__unflatten_device_tree+0x1c/0x12c)
> [    0.000000] [<c039419c>] (__unflatten_device_tree) from [<c069514c>]
> (unflatten_device_tree+0x1c/0x34)
> [    0.000000] [<c069514c>] (unflatten_device_tree) from [<c0679448>]
> (setup_arch+0x6e8/0x970)
> [    0.000000] [<c0679448>] (setup_arch) from [<c067693c>]
> (start_kernel+0x88/0x3c0)
> [    0.000000] [<c067693c>] (start_kernel) from [<0000807c>] (0x807c)
> [    0.000000] Code: e3e0300d eafbbec4 e3e0300d eafbbec9 (e5903000)
> [    0.000000] ---[ end trace cb88537fdc8fa200 ]---
> [    0.000000] Kernel panic - not syncing: Attempted to kill the idle task!
> [    0.000000] ---[ end Kernel panic - not syncing: Attempted to kill
> the idle task!
>
> Do you have an idea what I'm doing wrong here? With the SDK U-Boot
> everything works fine.

Not really. How much RAM is installed on the board? Does booting work 
with "mem=2G"?

Thanks,
Stefan