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

[Pali Rohár]

On Thursday 12 January 2023 23:00:04 Tony Dinh wrote:
> Hi Stefan,
> 
> On Thu, Jan 12, 2023 at 10:13 PM Stefan Roese <sr at denx.de> wrote:
> >
> > Hi Tony,
> >
> > (added Tom to Cc)
> >
> > On 1/13/23 02:40, Tony Dinh wrote:
> > > Hi Stefan,
> > >
> > > On Wed, Jan 11, 2023 at 12:56 PM Pali Rohár <pali at kernel.org> wrote:
> > >>
> > >> On Wednesday 11 January 2023 12:44:45 Tony Dinh wrote:
> > >>> Hi Pali,
> > >>>
> > >>> On Wed, Jan 11, 2023 at 12:04 AM Pali Rohár <pali at kernel.org> wrote:
> > >>>>
> > >>>> On Tuesday 10 January 2023 21:07:45 Tony Dinh wrote:
> > >>>>> Hi Pali,
> > >>>>>
> > >>>>> 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'
> > >>
> > >> This looks like a bug in that training code. I would need to see source
> > >> code, so I can figure out how to fix it.
> > >>
> > >>> 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?
> > >>
> > >> Send that DDR code resync in one patch... and saying e.g. adding support
> > >> for DDR4 from Marvell repo.
> > >
> > > The DDR4 patch is quite large, about 272K. Will it get rejected from
> > > ML because it is over the 100K limit?
> >
> > Usually Tom as the mailing list maintainer will get informed about such
> > mails and if he decides how to handle such huge mails. If this can't be
> > handled differently, which is probably the case with such a sync to a
> > repository, then the mail will get sent to the list when he "releases"
> > such mails.
> >
> > > # git format-patch -1 HEAD
> > > # wc 0001-ddr-marvell-a38x-Add-support-for-DDR4-from-Marvell-m.patch
> > >    7962  35309 277976
> > > 0001-ddr-marvell-a38x-Add-support-for-DDR4-from-Marvell-m.patch
> > >
> > > How would you like to receive the patch? Would you like 2 emails (1st
> > > go to the ML without the patch, 2nd with the patch but not to the ML)?
> >
> > As a normal mail / patch please.
> 
> Will do that!
> 
> >
> > Side note: Does your patch /sync only touch the currently not supported
> > DDR4 handling? If changes also include DDR3 then this should be tested
> > on the boards currently using this code very intensive. All A38x board
> > maintainers should be pointed to such new changes in this case.

I guess that new code only adds ifdefs for DDR4 which should not be
enabled nor compiled for existing boards. This should be safe.

> Yes, indeed. I plan to do at least a DDR3 regression test with the
> Synology DS116 board (Armada 385, DDR3). The existing A38x boards do
> not have CONFIG_DDR4 enabled, so the DDR3 code looks to be the same,
> AFAITC. The patch should be reviewed by Pali and Marek to confirm that
> on paper, at least. But preferably, all A38x board maintainers should
> be aware. I will grep for  the list of the A38x maintainers, and send
> directly to them (or if you already have such a list please let me
> know).
> 
> Thanks,
> Tony
> 
> 
> 
> >
> > Thanks,
> > Stefan
> >