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