From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefan Eichenberger Date: Fri, 4 Sep 2015 18:15:17 +0200 Subject: [U-Boot] arm: mvebu: u-boot does not start on db-88f6820-gp In-Reply-To: <55E9B568.30808@denx.de> References: <55E9AE3C.2080801@netmodule.com> <55E9B568.30808@denx.de> Message-ID: <55E9C395.5090402@netmodule.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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=, way_shift=, num_ways=, num_sets=, level=) 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=, way_shift=, num_ways=, num_sets=, level=) at arch/arm/cpu/armv7/cache_v7.c:62 #1 v7_maint_dcache_level_setway (operation=, 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