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