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

[Stefan Roese]

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.

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.

Thanks,
Stefan