On Thursday 12 January 2023 23:00:04 Tony Dinh wrote: > Hi Stefan, > > On Thu, Jan 12, 2023 at 10:13 PM Stefan Roese <s...@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 <p...@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 <p...@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 > >
