kwboot: UART booting with bin_hdr u-boot (Marvell Armada 385)

Pali Rohár pali at kernel.org
Wed Jan 11 09:03:59 CET 2023 

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 at gmail.com> wrote:
> >
> > On Mon, Jan 9, 2023 at 5:38 PM Pali Rohár <pali at 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 at 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 at gmail.com> wrote:
> > > > > > >
> > > > > > > Hello,
> > > > > > >
> > > > > > > On Wed, Jan 4, 2023 at 9:44 AM Pali Rohár <pali at 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 at 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.

> 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 at 70000 (eth0) using random MAC address - d6:25:74:23:2c:21
> eth0: ethernet at 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
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >

More information about the U-Boot mailing list