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

[Stefan Eichenberger]

Hi Stefan,

On 09/11/2015 05:02 PM, Stefan Eichenberger wrote:
> Hi Stefan,
>
> On 09/11/2015 04:24 PM, Stefan Roese wrote:
>> 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?
>
> Sorry that was unclear. I can load the Linux kernel from USB into RAM 
> and jump to the load address but then Linux crashes. The SD-card 
> access seems totally broken.

If I disable the SDMA then the SD-card access works correctly without 
U-Boot crash, no idea what causes the trouble with SDMA enabled.

>
>>
>>> ## 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"?
>
> 2 GB are correct unfortuantely the mem=2G option did not help. It 
> seems that the Linux kernel searches the devicetree at 0x3fb47020 
> (0x7fb47020 before MMU enabled?) but there are only zeros. U-Boot 
> seems to load the Devicetree correctly so I will try to debug Linux. 
> Perhaps it clears this region for some reasons.
>
> Thanks,
> Stefan
>

I found the reason why the kernel did not boot. Unfortunately U-Boot was 
still loading the default env from the SDK where fdt_high was not set to 
0x10000000 and therefore the kernel did not find the devicetree. Sorry 
for that!

Regards,
Stefan