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

[Stefan Roese]

Hi Stefan,

On 04.09.2015 18:15, Stefan Eichenberger wrote:
>> On 04.09.2015 16:44, Stefan Eichenberger wrote:
>>> I have a problem with u-boot compiled from master and the db-88f6820-gp
>>> evaluation board from Marvell. The problem is the reconfiguration of the
>>> base register address (SOC_REGS_PHY_BASE) under u-boot on A38x. Some
>>> functions (e.g. mvebu_soc_family) try to access the new
>>> SOC_REGS_PHY_BASE address before this address is reconfigured which
>>> leads to an exception. U-Boot won't start in this case. I then set the
>>> SOC_REGS_PHY_BASE to 0xd0000000 (same as under SPL) and u-boot starts
>>> successfully. This was only to verify that this is the problem, with the
>>> modification I can't start Linux because Linux expects that the
>>> addresses are reconfigured.
>>>
>>> I have to mention, I try to start from a SD Card. So I have changed the
>>> boot configuration of the board with a pull down on DPR6.
>>>
>>> This is the output of the SPL when I don't add the modification, u-boot
>>> won't start:
>>> U-Boot SPL 2015.10-rc2-00308-g6679da9-dirty (Sep 04 2015 - 16:01:24)
>>> High speed PHY - Version: 2.0
>>>
>>> Initialize DB-GP board topology
>>> Detected Device ID 6828
>>> Lane 5 detection: USB3.0 Host Port 1
>>> Lane 1 detection: SATA0
>>> Lane 2 detection: SATA1
>>> board SerDes lanes topology details:
>>>   | Lane #  | Speed |  Type       |
>>>   --------------------------------
>>>   |   0    |  5   |  PCIe0       |
>>>   |   1    |  3   |  SATA0       |
>>>   |   2    |  3   |  SATA1       |
>>>   |   3    |  3   |  SATA3       |
>>>   |   4    |  3   |  SATA2       |
>>>   |   5    |  5   |  USB3 HOST1  |
>>>   --------------------------------
>>> PCIe, Idx 0: detected no link
>>> High speed PHY - Ended Successfully
>>> DDR3 Training Sequence - Ver TIP-1.29.0
>>> DDR3 Training Sequence - Switching XBAR Window to FastPath Window
>>> DDR3 Training Sequence - Ended Successfully
>>>  >>spl:board_init_r()
>>> spl_init()
>>> boot device - 1
>>> spl: mmc boot mode: raw
>>> read sector 1140, count=1
>>> spl: payload image: U-Bo load addr: 0x7fffc0 size: 336772
>>> read 292 sectors to 7fffc0
>>> Jumping to U-Boot
>>> loaded - jumping to U-Boot...image entry point: 0x800000
>>>
>>> After I changed SOC_REGS_PHY_BASE u-boot starts correctly:
>>> U-Boot 2015.10-rc2-00308-g6679da9-dirty (Sep 04 2015 - 16:19:09 +0200)
>>>
>>> SoC:   MV88F6828-A0
>>> I2C:   ready
>>> SPI:   ready
>>> DRAM:  2 GiB (ECC not enabled)
>>> MMC:   mv_sdh: 0
>>> SF: Detected M25P128 with page size 256 Bytes, erase size 256 KiB, total
>>> 16 MiB
>>> Board: Marvell DB-88F6820-GP
>>> SCSI:  MVEBU SATA INIT
>>> SATA link 0 timeout.
>>> SATA link 1 timeout.
>>> AHCI 0001.0000 32 slots 2 ports 6 Gbps 0x3 impl SATA mode
>>> flags: 64bit ncq led only pmp fbss pio slum part sxs
>>> Net:   neta0, neta1
>>> Hit any key to stop autoboot:  0
>>>
>>> So it seems that SOC_REGS_PHY_BASE should somehow be changeable during
>>> runtime but I don't think this works with the current design. Do you
>>> have an idea how this could be fixed?
>>
>> Yes, there are some problems with the current mainline version. Good
>> news though is, that I've already fixed this and posted some patches
>> for this. And more, e.g. support for DM / dts. I've just uploaded a
>> git branch for you to test "mvebu-dm-v2-2015-09-04":
>>
>> https://gitlab.denx.de/sr/u-boot-a38x/commits/mvebu-dm-v2-2015-09-04
>>
>> This branch should work just fine. Please give it a try and let me
>> know if this works or not.
>>
>> Thanks,
>> Stefan
>>
>
> Thanks for the fast response! I've tried this version an was able to run
> u-boot as expected.

Ufff! ;)

> 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)...

Thanks,
Stefan