Re: [Binman] Question regarding SPL symbol offsets generation

[Lukasz Majewski <lukma@denx.de>]

[-- Attachment #1: Type: text/plain, Size: 4596 bytes --]

Hi Simon,

> Hi Lukasz,
> 
> On Thu, 8 Aug 2024 at 03:06, Lukasz Majewski <lukma@denx.de> wrote:
> >
> > Dear Community
> >
> > I'd like to ask about one issue with generation of symbol offsets in
> > binman [1].
> >
> > In my case the CONFIG_FSPI_CONF_HEADER is defined.
> >
> > Problem is with generated symbols [2] to point into
> > ddr-1d-imem-fw/ddr-1d-dmem-fw/ddr-2d-imem-fw/ddr-2d-dmem-fw.
> >
> > It looks like only symbols have extra offset of 0x1000 (the same as
> > the first section introduces) - binaries for training memory are
> > placed without this extra offset.
> >
> > On the other hand - before this change:
> > SHA1: 37e50627efacd8dae18b564e9d8886a033e181bc
> >
> > The u-boot-spl-ddr.bin was a separate binman "entry" (i.e. not
> > section)
> > - so e.g. ddr-1d-dmem-fw {} had proper offsets (as this binary was
> > also mangled into spl.bin with mkimage invocation).
> >
> >
> > Now the question - how to properly fix this issue?
> >
> > I've tried to add pad-before = <0x1000>; to ddr-1d-imem-fw property
> > hoping to "move" this binary itself by 0x1000. However with it the
> > symbol of ddr-1d-dmem-fw is moved up as well.
> >
> > Another option was to try alignment 'align-size' set to 0x1000 -
> > effect is the same as described above.
> >
> > In the documentation [3] - I've found that I could use
> > "ProcessEntryContents()" for tweaking, but this seems to be not
> > eligible (as all imx8mX boards, which are going to boot from fspi)
> > are affected.
> >
> > Maybe falling-back to 'multiple-images' [4] and generate the
> > u-boot-spl-ddr.bin in that way is a proper solution?
> >
> >
> > Last but not least - this problem is not present when one boots from
> > SD/eMMC as in this case the "fspi_conf_block" property is not
> > present and everything starts with 0x0 offset.
> >
> > Thanks in advance for your help.  
> 
> BTW we are waiting for tests for this etype...when those are in place
> it should provide a way to test the behaviour.
> 
> I see that Entry_nxp_imx8mimage.SetImagePos() adjusts the image-pos.
> Is that the symbol you are writing? Are you saying that the image_pos
> symbol that is written is incorrect?
> 

Yes, it is up by +0x1000 when compared to the real place where binaries
(like ddr_1d_imem_fw) are placed.

> Or are you using u-boot-spl-mkimage.signed.bin (i.e. without the 4KB
> header) in the first section.

No, HAB (signing) is disabled.

Instead I'm using the CONFIG_FSPI_CONF_HEADER from [1]. It adds FSPI
(QSPI) specific header with 0x1000 size.

> 
> The image_pos is an absolute image position, so it doesn't matter what
> sections are written out as files. The image_pos will be the same
> regardless.

To have the board booting again - I do need to perform:

 imem_start -= 0x1000;
 dmem_start -= 0x1000;

added at [5].

> 
> Why are u-boot-spl-mkimage.signed.bin and u-boot-fit.signed.bin
> written out? Aren't they just intermediate images, not useful for
> flashing to the board? If not, why is the FSPI conf block before them?
> 

As stated above - I'm not using HAB so those are not created.

The FSPI block is required to boot the device with QSPI - it holds meta
data to configure the memory itself.

> There is a 'skip-at-start' property which might be useful here, so
> long as I understand the above correctly.

Ok - I will try it.

Thanks for your help :-)

> 
> Regards,
> Simon
> 
> 
> >
> >
> > Links:
> >
> > [1] -
> >  https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/dts/imx8mm-u-boot.dtsi?ref_type=heads#L49
> >
> > [2] -
> > https://source.denx.de/u-boot/u-boot/-/blob/master/drivers/ddr/imx/phy/helper.c#L27
> >
> > [3] -
> > https://github.com/ARM-software/u-boot/blob/master/tools/binman/README#L526
> >
> > [4] -
> > https://github.com/ARM-software/u-boot/blob/master/tools/binman/README#L371
> >
> >
> > 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@denx.de  

Links:

[5] -
https://source.denx.de/u-boot/u-boot/-/blob/master/drivers/ddr/imx/phy/helper.c#L87


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@denx.de

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]