From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefan Roese Date: Fri, 4 Sep 2015 18:44:13 +0200 Subject: [U-Boot] arm: mvebu: u-boot does not start on db-88f6820-gp In-Reply-To: <55E9C395.5090402@netmodule.com> References: <55E9AE3C.2080801@netmodule.com> <55E9B568.30808@denx.de> <55E9C395.5090402@netmodule.com> Message-ID: <55E9CA5D.6040107@denx.de> 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 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=, > 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? 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