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?
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