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-boo...
[2] - https://source.denx.de/u-boot/u-boot/-/blob/master/drivers/ddr/imx/phy/helpe...
[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/helpe...
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