Hi Pali, On Wed, Jan 11, 2023 at 12:04 AM Pali Rohár <p...@kernel.org> wrote: > > On Tuesday 10 January 2023 21:07:45 Tony Dinh wrote: > > Hi Pali, > > > > On Mon, Jan 9, 2023 at 5:44 PM Tony Dinh <mibo...@gmail.com> wrote: > > > > > > On Mon, Jan 9, 2023 at 5:38 PM Pali Rohár <p...@kernel.org> wrote: > > > > > > > > On Monday 09 January 2023 17:35:24 Tony Dinh wrote: > > > > > Hi Pali, > > > > > > > > > > On Mon, Jan 9, 2023 at 5:02 PM Pali Rohár <p...@kernel.org> wrote: > > > > > > > > > > > > On Monday 09 January 2023 16:55:56 Tony Dinh wrote: > > > > > > > Hi Pali, > > > > > > > > > > > > > > On Wed, Jan 4, 2023 at 1:04 PM Tony Dinh <mibo...@gmail.com> > > > > > > > wrote: > > > > > > > > > > > > > > > > Hello, > > > > > > > > > > > > > > > > On Wed, Jan 4, 2023 at 9:44 AM Pali Rohár <p...@kernel.org> > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > On Wednesday 04 January 2023 23:41:05 Chris Packham wrote: > > > > > > > > > > On Wed, 4 Jan 2023, 8:52 PM Pali Rohár, <p...@kernel.org> > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > On Wednesday 04 January 2023 08:50:28 Pali Rohár wrote: > > > > > > > > > > > > Hello! > > > > > > > > > > > > > > > > > > > > > > > > On Tuesday 03 January 2023 17:55:41 Tony Dinh wrote: > > > > > > > > > > > > > Hi Pali, > > > > > > > > > > > > > > > > > > > > > > > > > > I'm building a new u-boot for the Thecus N2350 board > > > > > > > > > > > > > (Armada 385 > > > > > > > > > > > > > dual-core 1Ghz 1GB DDR4). The trouble with this board > > > > > > > > > > > > > is DDR4, which > > > > > > > > > > > > > is not currently supported in u-boot (also cc this to > > > > > > > > > > > > > Chris for > > > > > > > > > > > > > commenting about Marvell DDR4 training driver). > > > > > > > > > > > > > > > > > > > > > > > > Yes, ddr4 training code is not in u-boot yet. > > > > > > > > > > > > > > > > > > > > > > > > A38x u-boot ddr driver is in this directory: > > > > > > > > > > > > > > > > > > > > > > > https://source.denx.de/u-boot/u-boot/-/tree/master/drivers/ddr/marvell/a38x > > > > > > > > > > > > > > > > > > > > > > > > And it is copied from the original marvell driver by > > > > > > > > > > > > stripping non-a38x > > > > > > > > > > > > code and removal of the ddr4 code from the master > > > > > > > > > > > > branch: > > > > > > > > > > > > https://github.com/MarvellEmbeddedProcessors/mv-ddr-marvell > > > > > > > > > > > > > > > > > > > > > > > > So you can try to copy code again without stripping > > > > > > > > > > > > ddr4 parts > > > > > > > > > > > > (run git log drivers/ddr/marvell/a38x in u-boot) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://source.denx.de/u-boot/u-boot/-/commit/107c3391b95bcc2ba09a876da4fa0c31b6c1e460 > > > > > > > > > > > > > > > > > > > > > > > And adjust u-boot board code for ddr4. > > > > > > > > > > > > > > > > > > > > > > > > I guess it could work but it would be needed to play > > > > > > > > > > > > with it. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Last time I looked the MarvellEmbeddedProcessors stuff was > > > > > > > > > > a long way > > > > > > > > > > behind what Marvell are releasing to customers. That was > > > > > > > > > > for the newer SoCs > > > > > > > > > > so maybe the A385 stuff is current. > > > > > > > > > > > > > > > > > > About half year ago, MarvellEmbeddedProcessors mv-ddr-marvell > > > > > > > > > and > > > > > > > > > A3700-utils-marvell were up-to-date and same as the version > > > > > > > > > distributed > > > > > > > > > to the Marvell customers. I was cooperating with Marvell to > > > > > > > > > release all > > > > > > > > > patches from Marvell Extranet portal to github as opensource > > > > > > > > > and also to > > > > > > > > > incorporate github patches from community to their Extranet > > > > > > > > > version. > > > > > > > > > Also I was synchronizing u-boot drivers/ddr/marvell/a38x > > > > > > > > > directory with > > > > > > > > > MarvellEmbeddedProcessors version. I do not think that > > > > > > > > > Marvell released > > > > > > > > > something super new in these repositories in last half of > > > > > > > > > year, so I > > > > > > > > > think that the code on MarvellEmbeddedProcessors (for those > > > > > > > > > two > > > > > > > > > repositories) is still up-to-date. > > > > > > > > > > > > > > > > Thanks all for commenting. As Pali has suggested, I will try > > > > > > > > copying > > > > > > > > the latest Marvell Github DDR drivers. > > > > > > > > > > > > > > I've tried to bring in the latest Marvell DDR drivers, but failed > > > > > > > miserably after many hours playing :) I used your DDR3 commit > > > > > > > info as > > > > > > > a guide as how to strip out other parts, and only kept DDR3 and > > > > > > > DDR4 > > > > > > > for a38x: > > > > > > > > > > > > > > https://source.denx.de/u-boot/u-boot/-/commit/107c3391b95bcc2ba09a876da4fa0c31b6c1e460 > > > > > > > > > > > > > > The current code has DDR4 interspersed in DDR3 with if-defs > > > > > > > CONFIG_DDR4. And there are some minor dependencies on ATF types, > > > > > > > quite difficult for me to get it to build cleanly. I guess I > > > > > > > threw in > > > > > > > the towel for now :) If you ever find some free time, please give > > > > > > > it a > > > > > > > shot. > > > > > > > > > > > > > > Thanks, > > > > > > > Tony > > > > > > > > > > > > Hello! And what is the issue? DDR training is failing? Or SPL does > > > > > > not > > > > > > boot? Or it do not compile? > > > > > > > > > > Each of the code files was compiled (after some includes adjustments). > > > > > But the build failed to link due to some errors such as > > > > > /usr/src/u-boot-master/drivers/ddr/marvell/a38x/mv_ddr_plat.c:558: > > > > > undefined reference to `mv_ddr_freq_get' > > > > > > > > > > It should have been seen by the linker (since that code was compiled), > > > > > I could not see why. I feel I have spent too much time fighting the > > > > > if-defs :) > > > > > > > > > > Thanks, > > > > > Tony > > > > > > > > Send the whole error message and also ideally push your changes to some > > > > git repository. So I can look at the stage at which you are. > > > > > > OK thanks! > > > > I got burned for being lazy :) it turned out that the mix of #ifdef > > and #if defined was the problem. Just stepped away and came back for a > > few minutes and I can see that I just need to define the CONFIG_DDR4 > > properly in arch/arm/mach-mvebu/Kconfig and build it to pass the > > CONFIG_DDR4 stuff. > > > > One more small hurdle after that was CONFIG_USE_PRIVATE_LIBGCC must be > > undefined for it to build (so I am using > > /usr/lib/gcc/arm-linux-gnueabi/10/libgcc.a, and not using > > arch/arm/lib/lib.a) > > Hello! It is normally a good idea to unset CONFIG_USE_PRIVATE_LIBGCC > unless you have compiled gcc for target CPU.
CONFIG_USE_PRIVATE_LIBGCC was set as a default for ARM target, since u-boot has arch/arm/lib/lib.a. But using arch/arm/lib/lib.a I got several build errors like these: ld.bfd: drivers/ddr/marvell/a38x/mv_ddr4_training_calibration.o: in function `mv_ddr4_copt_get': /usr/src/u-boot/drivers/ddr/marvell/a38x/mv_ddr4_training_calibration.c:809: undefined reference to `__aeabi_i2d' ld.bfd: /usr/src/u-boot/drivers/ddr/marvell/a38x/mv_ddr4_training_calibration.c:809: undefined reference to `__aeabi_dmul' ld.bfd: /usr/src/u-boot/drivers/ddr/marvell/a38x/mv_ddr4_training_calibration.c:809: undefined reference to `__aeabi_d2uiz' Perhaps this is something that needs to be looked at. > > > But Marvell DDR4 is working fine! Please see the log. > > Nice! So you can send patches for that board to list. Sure I will for the N2350 board. How will we be handling the Marvell DDR code resync? Thanks, Tony > > > <BEGIN LOG> > > > > kwboot version 2023.01-tld-1-00048-g19e15f9081-dirty > > Patching image boot signature to UART > > Aligning image header to Xmodem block size > > Sending boot message. Please reboot the target.../ > > Sending boot image header (122112 bytes)... > > 0 % > > [......................................................................] > > 7 % > > [......................................................................] > > 14 % > > [......................................................................] > > <snip> > > 80 % > > [......................................................................] > > 88 % > > [......................................................................] > > 95 % [............................................ > > ] > > Done > > > > U-Boot SPL 2023.01-tld-1-10204-g7b84c973b9-dirty (Jan 10 2023 - 20:39:38 > > -0800) > > High speed PHY - Version: 2.0 > > Detected Device ID 6820 > > board SerDes lanes topology details: > > | Lane # | Speed | Type | > > -------------------------------- > > | 0 | 0 | SGMII0 | > > | 1 | 3 | SATA0 | > > | 2 | 3 | SATA1 | > > | 4 | 5 | USB3 HOST0 | > > | 5 | 5 | USB3 HOST1 | > > -------------------------------- > > High speed PHY - Ended Successfully > > DDR4 Training Sequence - Switching XBAR Window to FastPath Window > > mv_ddr: completed successfully > > Trying to boot from BOOTROM > > Returning to BootROM (return address 0xffff05c4)... > > > > Sending boot image data (471968 bytes)... > > 0 % > > [......................................................................] > > 1 % > > [......................................................................] > > <snip> > > 94 % > > [......................................................................] > > 96 % > > [......................................................................] > > 98 % [................................................ > > ] > > Done > > Finishing transfer > > [Type Ctrl-\ + c to quit] > > > > > > U-Boot 2023.01-tld-1-10204-g7b84c973b9-dirty (Jan 10 2023 - 20:39:38 -0800) > > Thecus N2350 > > > > SoC: MV88F6820-A0 at 1066 MHz > > DRAM: 1 GiB (533 MHz, 32-bit, ECC not enabled) > > Core: 61 devices, 22 uclasses, devicetree: separate > > MMC: > > Loading Environment from SPIFlash... SF: Detected mx25l3205d with page > > size 256 Bytes, erase size 4 KiB, total 4 MiB > > *** Warning - bad CRC, using default environment > > > > Model: Thecus N2350 > > Board: Thecus N2350 > > Net: > > Warning: ethernet@70000 (eth0) using random MAC address - d6:25:74:23:2c:21 > > eth0: ethernet@70000 > > Hit any key to stop autoboot: 0 > > > > <END LOG> > > > > Thanks, > > Tony > > > > > Tony > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > All the best, > > > > > > > > Tony > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > So I'm building with binary.0 in the > > > > > > > > > > > > > ./board/thecus/n2350/. This > > > > > > > > > > > > > binary.0 is a copy of the Marvell bin_hdr for SPI in > > > > > > > > > > > > > the GPL source > > > > > > > > > > > > > for this board (provided by Thecus). My > > > > > > > > > > > > > ./board/thecus/n2350/kwbimage.cfg.in file looks like > > > > > > > > > > > > > this > > > > > > > > > > > > > > > > > > > > > > > > > > # Armada 38x uses version 1 image format > > > > > > > > > > > > > VERSION 1 > > > > > > > > > > > > > # Boot Media configurations > > > > > > > > > > > > > BOOT_FROM spi > > > > > > > > > > > > > # Binary Header (bin_hdr) with DDR4 training code > > > > > > > > > > > > > BINARY board/thecus/n2350/binary.0 0000005b 00000068 > > > > > > > > > > > > > > > > > > > > > > > > > > When I kwboot the u-boot.kwb image (using kwboot > > > > > > > > > > > > > binary built with > > > > > > > > > > > > > 2023.01-rc4), the header was transferred > > > > > > > > > > > > > successfully, but then the > > > > > > > > > > > > > BootROM jumped to SPI u-boot, instead of loading the > > > > > > > > > > > > > u-boot payload > > > > > > > > > > > > > from UART. Please see the log below. > > > > > > > > > > > > > <BEGIN LOG> > > > > > > > > > > > > > # ./kwboot -t -p -B 115200 /dev/ttyUSB0 -b uboot.kwb > > > > > > > > > > > > > > > > > > > > > > > > > > kwboot version 2023.01-tld-1-00048-g19e15f9081-dirty > > > > > > > > > > > > > Patching image boot signature to UART > > > > > > > > > > > > > Aligning image header to Xmodem block size > > > > > > > > > > > > > Sending boot message. Please reboot the target.../ > > > > > > > > > > > > > Sending boot image header (97792 bytes)... > > > > > > > > > > > > > 0 % > > > > > > > > > > > [......................................................................] > > > > > > > > > > > > > 9 % > > > > > > > > > > > [......................................................................] > > > > > > > > > > > > > <snip> > > > > > > > > > > > > > 82 % > > > > > > > > > > > [......................................................................] > > > > > > > > > > > > > 91 % > > > > > > > > > > > [................................................................ > > > > > > > > > > > ] > > > > > > > > > > > > > Done > > > > > > > > > > > > > > > > > > > > > > > > > > BootROM - 1.73 > > > > > > > > > > > > > Booting from SPI flash > > > > > > > > > > > > > > > > > > > > > > > > This indicates reset of the board. BootROM started > > > > > > > > > > > > execution of the > > > > > > > > > > > > image from the primary location. > > > > > > > > > > > > > > > > > > > > > > > > > <snip> > > > > > > > > > > > > > U-Boot 2013.01 (Nov 12 2018 - 20:56:19) Marvell > > > > > > > > > > > > > version: > > > > > > > > > > > 2015_T1.0p18-tld-4 > > > > > > > > > > > > > <END LOG> > > > > > > > > > > > > > > > > > > > > > > > > > > It seems kwboot patched the image, but the BOOT_FROM > > > > > > > > > > > > > indicator was > > > > > > > > > > > > > still recognized as from SPI. So the BootROM loaded > > > > > > > > > > > > > the stock u-boot > > > > > > > > > > > > > image from SPI and executed it. Since I am booting > > > > > > > > > > > > > with bin_hdr, I'm > > > > > > > > > > > > > not sure if there is something inside this blob that > > > > > > > > > > > > > has forced this > > > > > > > > > > > > > indicator to SPI. > > > > > > > > > > > > > > > > > > > > > > > > No, blob cannot force BootROM to switch boot location. > > > > > > > > > > > > This really > > > > > > > > > > > > indicates crash of the blob or crash of the payload > > > > > > > > > > > > which results in the > > > > > > > > > > > > board reset. > > > > > > > > > > > > > > > > > > > > > > > > > I'm attaching the u-boot.kwb image to this email, in > > > > > > > > > > > > > case you are > > > > > > > > > > > > > interested in taking a look at the structure. > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > Tony > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
