On Tuesday 10 January 2023 21:07:45 Tony Dinh wrote:
Hi Pali,
On Mon, Jan 9, 2023 at 5:44 PM Tony Dinh mibodhi@gmail.com wrote:
On Mon, Jan 9, 2023 at 5:38 PM Pali Rohár pali@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 pali@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 mibodhi@gmail.com wrote: > > Hello, > > On Wed, Jan 4, 2023 at 9:44 AM Pali Rohár pali@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, pali@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/107c3391b95bcc2ba09a876da4fa0c... > > > > > > > > > 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/107c3391b95bcc2ba09a876da4fa0c...
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.
But Marvell DDR4 is working fine! Please see the log.
Nice! So you can send patches for that board to list.
<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 > > > > > > > > > > > > > >