[Binman] Question regarding SPL symbol offsets generation

Sat Nov 9 02:04:00 CET 2024

On Mon, Nov 4, 2024 at 2:14 AM Lukasz Majewski <lukma at denx.de> wrote:
>
> Hi Adam,
>
> > On Sun, Nov 3, 2024 at 7:41 PM Adam Ford <aford173 at gmail.com> wrote:
> > >
> > > On Thu, Sep 5, 2024 at 8:54 AM Lukasz Majewski <lukma at denx.de>
> > > wrote:
> > > >
> > > > Hi Adam,
> > > >
> > > > > On Wed, Aug 28, 2024 at 3:04 AM Lukasz Majewski <lukma at denx.de>
> > > > > wrote:
> > > > > >
> > > > > > Hi Simon,
> > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > On Tue, 27 Aug 2024 at 12:47, Fabio Estevam
> > > > > > > <festevam at gmail.com> wrote:
> > > > > > > >
> > > > > > > > Hi Lukasz,
> > > > > > > >
> > > > > > > > On Thu, Aug 15, 2024 at 5:14 PM Lukasz Majewski
> > > > > > > > <lukma at denx.de> wrote:
> > > > > > > > > Unfortunately not - this change is only for properly
> > > > > > > > > setting start address of the u-boot.
> > > > > > > > >
> > > > > > > > > The _real_ problem here is the symbol placement
> > > > > > > > > generated by binman when we try to define the image as
> > > > > > > > > a single one.
> > > > > > > > >
> > > > > > > > > Moreover, this change follows other boards with imx8mm
> > > > > > > > > processor - ./configs/imx8mm_beacon_fspi_defconfig to be
> > > > > > > > > specific.
> > > > > > > > >
> > > > > > > > > The "fix" (for which I'd been now probably opt) for
> > > > > > > > > this issue would be to generate two images with binman
> > > > > > > > > - one for u-boot-spl-ddr.bin and the final flash.bin
> > > > > > > > > with the former one included (as it was before SHA1:
> > > > > > > > > 37e50627efacd8dae18b564e9d8886a033e181bc)
> > > > > > > >
> > > > > > > > Is QSPI boot broken on i.MX8MM?
> > > > > > > >
> > > > > > > > I am adding Adam and Mamta who have tested QSPI booting on
> > > > > > > > imx8mm_beacon and imx8mm_evk, respectively.
> > > > > > >
> > > > > > > Note also that I sent a series[1] which allows the
> > > > > > > symbols-base to be adjusted, if that helps.
> > > > > >
> > > > > > I've seen them - but not yet tested.
> > > > > >
> > > > > > Thanks Simon for the patch series.
> > > > >
> > > > > Is it still broken with this patch series?  I have been
> > > > > traveling and haven't had much time to test.
> > > >
> > > > Yes, I can confirm that it is still broken.
> > >
> > > Sorry for the delay.  I had to return my 8MM to Beacon, and I was
> > > waiting for a replacement.
> > >
> > > To not prolong it anymore, I decided to try it with an 8M Nano, and
> > > I got a boot failure on master. I was able to successfully boot
> > > 2024.01-rc5, but I haven't had time to bisect it yet.  I'll try to
> > > do that this week.  I think once we can bisect the error, it might
> > > become more apparent.
> >
> > Git bisect narrowed down the git which broke the build:
> >
> > commit 37e50627efacd8dae18b564e9d8886a033e181bc (HEAD)
> > Author: Marek Vasut <marex at denx.de>
> > Date:   Fri Apr 26 01:00:37 2024 +0200
> >
> >     ARM: dts: imx: Convert i.MX8M flash.bin image generation to binman
> >
> > I am guessing the binman isn't prepending the header stuff.  I'll try
> > to investigate it this week.
>
> This is the problem with adjustments.
>
> I've prepared following fixes for it (but are not upstreamable):
> https://github.com/lmajewski/u-boot/commits/phycore-imx8mm-qspi-nvme
>
> (problem is with wrong offsets assigned -> 0x1000 switch)
>
> Unfortunately, I don't have the HW any more at hand.

I think we should try to generate two binaries.  The original
flash.bin file with the references to the FSPI stuff removed and the
offsets left as if FSPI booting doesn't exist, then a second binary
which adds the FSPI header at 0x400 and append the original flash.bin
file (build for sd booting) moved to offset 0x1000.

I manually created a binary like this using DD and it worked, but
building the image with the various offsets in the device tree appears
to break both SPL and U-Boot phases.

I tried to create a second file node to do this, but I don't
understand the binman stuff enough to have been successful.  I have
only tried the Nano, but I will test a Mini as soon as I can get my
hands on one again.

adam
>
> >
> > adam
> >
> > >
> > > adam
> > >
> > > >
> > > > I've applied:
> > > > https://patchwork.ozlabs.org/project/uboot/cover/20240826191143.426387-1-sjg@chromium.org/
> > > >
> > > > on top of mainline:
> > > > SHA1: 1630ff26cc960439b5949b80cfc604a2c8aa47dd
> > > >
> > > > Adding symbols-base = <0>; to imx8mm-u-boot.dtsi did not help.
> > > >
> > > > >
> > > > > adam
> > > > > >
> > > > > > >
> > > > > > > Regards,
> > > > > > > Simon
> > > > > > >
> > > > > > > [1]
> > > > > > > https://patchwork.ozlabs.org/project/uboot/list/?series=421010
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > Best regards,
> > > > > >
> > > > > > Lukasz Majewski
> > > > > >
> > > > > > --
> > > > > >
> > > > > > DENX Software Engineering GmbH,      Managing Director: Erika
> > > > > > Unter HRB 165235 Munich, Office: Kirchenstr.5, D-82194
> > > > > > Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax:
> > > > > > (+49)-8142-66989-80 Email: lukma at denx.de
> > > >
> > > >
> > > >
> > > >
> > > > Best regards,
> > > >
> > > > Lukasz Majewski
> > > >
> > > > --
> > > >
> > > > DENX Software Engineering GmbH,      Managing Director: Erika
> > > > Unter HRB 165235 Munich, Office: Kirchenstr.5, D-82194
> > > > Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax:
> > > > (+49)-8142-66989-80 Email: lukma at denx.de
>
>
>
>
> Best regards,
>
> Lukasz Majewski
>
> --
>
> DENX Software Engineering GmbH,      Managing Director: Erika Unter
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma at denx.de