Hi Lukasz,
On Thu, 8 Aug 2024 at 03:06, Lukasz Majewski <lu...@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?
Or are you using u-boot-spl-mkimage.signed.bin (i.e. without the 4KB
header) in the first section.
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.
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?
There is a 'skip-at-start' property which might be useful here, so
long as I understand the above correctly.
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: lu...@denx.de
