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

[Stefan Eichenberger]

Hi Stefan,

On 09/04/2015 05:14 PM, Stefan Roese wrote:
> Hi Stefan,
>
> 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. 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?

I hope I can do some more tests next week.

Best regards,
Stefan