[Binman] Question regarding SPL symbol offsets generation
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.
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
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?
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-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
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
Hi Lukasz,
On Thu, Aug 8, 2024 at 6:07 AM 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 assume you fixed the problem with this change: https://patchwork.ozlabs.org/project/uboot/patch/20240815080948.457524-1-luk...
Hi Fabio,
Hi Lukasz,
On Thu, Aug 8, 2024 at 6:07 AM 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 assume you fixed the problem with this change: https://patchwork.ozlabs.org/project/uboot/patch/20240815080948.457524-1-luk...
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)
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
Hi Lukasz,
On Thu, Aug 15, 2024 at 5:14 PM Lukasz Majewski lukma@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.
Hi,
On Tue, 27 Aug 2024 at 12:47, Fabio Estevam festevam@gmail.com wrote:
Hi Lukasz,
On Thu, Aug 15, 2024 at 5:14 PM Lukasz Majewski lukma@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.
Regards, Simon
[1] https://patchwork.ozlabs.org/project/uboot/list/?series=421010
Hi Simon,
Hi,
On Tue, 27 Aug 2024 at 12:47, Fabio Estevam festevam@gmail.com wrote:
Hi Lukasz,
On Thu, Aug 15, 2024 at 5:14 PM Lukasz Majewski lukma@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.
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@denx.de
On Wed, Aug 28, 2024 at 3:04 AM Lukasz Majewski lukma@denx.de wrote:
Hi Simon,
Hi,
On Tue, 27 Aug 2024 at 12:47, Fabio Estevam festevam@gmail.com wrote:
Hi Lukasz,
On Thu, Aug 15, 2024 at 5:14 PM Lukasz Majewski lukma@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.
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@denx.de
Hi Adam,
On Wed, Aug 28, 2024 at 3:04 AM Lukasz Majewski lukma@denx.de wrote:
Hi Simon,
Hi,
On Tue, 27 Aug 2024 at 12:47, Fabio Estevam festevam@gmail.com wrote:
Hi Lukasz,
On Thu, Aug 15, 2024 at 5:14 PM Lukasz Majewski lukma@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.
I've applied: https://patchwork.ozlabs.org/project/uboot/cover/20240826191143.426387-1-sjg...
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@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@denx.de
Hi Lukasz,
On Thu, 5 Sept 2024 at 07:54, Lukasz Majewski lukma@denx.de wrote:
Hi Adam,
On Wed, Aug 28, 2024 at 3:04 AM Lukasz Majewski lukma@denx.de wrote:
Hi Simon,
Hi,
On Tue, 27 Aug 2024 at 12:47, Fabio Estevam festevam@gmail.com wrote:
Hi Lukasz,
On Thu, Aug 15, 2024 at 5:14 PM Lukasz Majewski lukma@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.
I've applied: https://patchwork.ozlabs.org/project/uboot/cover/20240826191143.426387-1-sjg...
on top of mainline: SHA1: 1630ff26cc960439b5949b80cfc604a2c8aa47dd
Adding symbols-base = <0>; to imx8mm-u-boot.dtsi did not help.
Can you please point me to the tree? I suspect that the symbols-base is already 0, so setting it to 0 has no effect. I'm not sure though,
Regards, Simon
Hi Simon,
Hi Lukasz,
On Thu, 5 Sept 2024 at 07:54, Lukasz Majewski lukma@denx.de wrote:
Hi Adam,
On Wed, Aug 28, 2024 at 3:04 AM Lukasz Majewski lukma@denx.de wrote:
Hi Simon,
Hi,
On Tue, 27 Aug 2024 at 12:47, Fabio Estevam festevam@gmail.com wrote:
Hi Lukasz,
On Thu, Aug 15, 2024 at 5:14 PM Lukasz Majewski lukma@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.
I've applied: https://patchwork.ozlabs.org/project/uboot/cover/20240826191143.426387-1-sjg...
on top of mainline: SHA1: 1630ff26cc960439b5949b80cfc604a2c8aa47dd
Adding symbols-base = <0>; to imx8mm-u-boot.dtsi did not help.
Can you please point me to the tree?
https://github.com/lmajewski/u-boot/commits/imx8mm-test-qspi-boot-binman-pat...
I suspect that the symbols-base is already 0, so setting it to 0 has no effect. I'm not sure though,
Ach... I see.
Please correct me if I'm wrong, but isn't the "symbols-base" an absolute address?
This is my impression from the descripion.
However, in my case - I would need the "relative" modification - please see the required "hack": https://github.com/lmajewski/u-boot/commit/07c0057fcfd242fa791767aaf0ac752d3...
Regards, Simon
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
Hi ,
On Fri, 6 Sept 2024 at 01:55, Lukasz Majewski lukma@denx.de wrote:
Hi Simon,
Hi Lukasz,
On Thu, 5 Sept 2024 at 07:54, Lukasz Majewski lukma@denx.de wrote:
Hi Adam,
On Wed, Aug 28, 2024 at 3:04 AM Lukasz Majewski lukma@denx.de wrote:
Hi Simon,
Hi,
On Tue, 27 Aug 2024 at 12:47, Fabio Estevam festevam@gmail.com wrote: > > Hi Lukasz, > > On Thu, Aug 15, 2024 at 5:14 PM Lukasz Majewski > lukma@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.
I've applied: https://patchwork.ozlabs.org/project/uboot/cover/20240826191143.426387-1-sjg...
on top of mainline: SHA1: 1630ff26cc960439b5949b80cfc604a2c8aa47dd
Adding symbols-base = <0>; to imx8mm-u-boot.dtsi did not help.
Can you please point me to the tree?
https://github.com/lmajewski/u-boot/commits/imx8mm-test-qspi-boot-binman-pat...
I suspect that the symbols-base is already 0, so setting it to 0 has no effect. I'm not sure though,
Ach... I see.
Please correct me if I'm wrong, but isn't the "symbols-base" an absolute address?
This is my impression from the descripion.
However, in my case - I would need the "relative" modification - please see the required "hack": https://github.com/lmajewski/u-boot/commit/07c0057fcfd242fa791767aaf0ac752d3...
From the mailing list it seems you found a solution?
Regards, Simon
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
Regards, Simon
Hi Simon,
Hi ,
On Fri, 6 Sept 2024 at 01:55, Lukasz Majewski lukma@denx.de wrote:
Hi Simon,
Hi Lukasz,
On Thu, 5 Sept 2024 at 07:54, Lukasz Majewski lukma@denx.de wrote:
Hi Adam,
On Wed, Aug 28, 2024 at 3:04 AM Lukasz Majewski lukma@denx.de wrote:
Hi Simon,
> Hi, > > On Tue, 27 Aug 2024 at 12:47, Fabio Estevam > festevam@gmail.com wrote: > > > > Hi Lukasz, > > > > On Thu, Aug 15, 2024 at 5:14 PM Lukasz Majewski > > lukma@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.
I've applied: https://patchwork.ozlabs.org/project/uboot/cover/20240826191143.426387-1-sjg...
on top of mainline: SHA1: 1630ff26cc960439b5949b80cfc604a2c8aa47dd
Adding symbols-base = <0>; to imx8mm-u-boot.dtsi did not help.
Can you please point me to the tree?
https://github.com/lmajewski/u-boot/commits/imx8mm-test-qspi-boot-binman-pat...
I suspect that the symbols-base is already 0, so setting it to 0 has no effect. I'm not sure though,
Ach... I see.
Please correct me if I'm wrong, but isn't the "symbols-base" an absolute address?
This is my impression from the descripion.
However, in my case - I would need the "relative" modification - please see the required "hack": https://github.com/lmajewski/u-boot/commit/07c0057fcfd242fa791767aaf0ac752d3...
From the mailing list it seems you found a solution?
Nope, the "hack" is not for upstreaming...
It just shows that some symbols were misplaced and shall be _properly_ fixed by altering either imx8mm-u-boot.dtsi or binman itself.
Regards, Simon
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
Regards, Simon
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
On Thu, Sep 5, 2024 at 8:54 AM Lukasz Majewski lukma@denx.de wrote:
Hi Adam,
On Wed, Aug 28, 2024 at 3:04 AM Lukasz Majewski lukma@denx.de wrote:
Hi Simon,
Hi,
On Tue, 27 Aug 2024 at 12:47, Fabio Estevam festevam@gmail.com wrote:
Hi Lukasz,
On Thu, Aug 15, 2024 at 5:14 PM Lukasz Majewski lukma@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.
adam
I've applied: https://patchwork.ozlabs.org/project/uboot/cover/20240826191143.426387-1-sjg...
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@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@denx.de
On Sun, Nov 3, 2024 at 7:41 PM Adam Ford aford173@gmail.com wrote:
On Thu, Sep 5, 2024 at 8:54 AM Lukasz Majewski lukma@denx.de wrote:
Hi Adam,
On Wed, Aug 28, 2024 at 3:04 AM Lukasz Majewski lukma@denx.de wrote:
Hi Simon,
Hi,
On Tue, 27 Aug 2024 at 12:47, Fabio Estevam festevam@gmail.com wrote:
Hi Lukasz,
On Thu, Aug 15, 2024 at 5:14 PM Lukasz Majewski lukma@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@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.
adam
adam
I've applied: https://patchwork.ozlabs.org/project/uboot/cover/20240826191143.426387-1-sjg...
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@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@denx.de
On Sun, Nov 3, 2024 at 8:00 PM Adam Ford aford173@gmail.com wrote:
On Sun, Nov 3, 2024 at 7:41 PM Adam Ford aford173@gmail.com wrote:
On Thu, Sep 5, 2024 at 8:54 AM Lukasz Majewski lukma@denx.de wrote:
Hi Adam,
On Wed, Aug 28, 2024 at 3:04 AM Lukasz Majewski lukma@denx.de wrote:
Hi Simon,
Hi,
On Tue, 27 Aug 2024 at 12:47, Fabio Estevam festevam@gmail.com wrote: > > Hi Lukasz, > > On Thu, Aug 15, 2024 at 5:14 PM Lukasz Majewski lukma@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@denx.de Date: Fri Apr 26 01:00:37 2024 +0200
ARM: dts: imx: Convert i.MX8M flash.bin image generation to binmanI am guessing the binman isn't prepending the header stuff. I'll try to investigate it this week.
Despite being tired (and having a little wine), I couldn't put this down.
The working version appears to have a sequence that starts at 0x1000:
00001000 d1 00 20 41 00 20 91 00 00 00 00 00 00 00 00 00
The same sequence on the non-working version has the same sequence at a different offset: 000005c0 d1 00 20 41 00 20 91 00 00 00 00 00 00 00 00 00
I think the offset needs to be fixed. I tried the following patch, but I am now getting some i2c clock failures, so I need to investigate further:
diff --git a/arch/arm/dts/imx8mn-u-boot.dtsi b/arch/arm/dts/imx8mn-u-boot.dtsi index 6875c6d44f..91fc67099c 100644 --- a/arch/arm/dts/imx8mn-u-boot.dtsi +++ b/arch/arm/dts/imx8mn-u-boot.dtsi @@ -117,7 +117,9 @@ nxp,rom-version = <2>; nxp,loader-address = <CONFIG_SPL_TEXT_BASE>; args; /* Needed by mkimage etype superclass */ - +#ifdef CONFIG_FSPI_CONF_HEADER + offset = <0x1000>; +#endif section { filename = "u-boot-spl-ddr.bin"; pad-byte = <0xff>;
Wtih the above patch, SPL tries to execute:
U-Boot SPL 2025.01-rc1-g6ebfafe8c532-dirty (Nov 03 2024 - 21:23:04 -0600) Failed to get i2c clk
Once I can figure out the i2c clk issue, I can further test and/or submit a patch with a fixes-tag.
adam
adam
adam
I've applied: https://patchwork.ozlabs.org/project/uboot/cover/20240826191143.426387-1-sjg...
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@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@denx.de
Hi Adam,
On Sun, Nov 3, 2024 at 7:41 PM Adam Ford aford173@gmail.com wrote:
On Thu, Sep 5, 2024 at 8:54 AM Lukasz Majewski lukma@denx.de wrote:
Hi Adam,
On Wed, Aug 28, 2024 at 3:04 AM Lukasz Majewski lukma@denx.de wrote:
Hi Simon,
Hi,
On Tue, 27 Aug 2024 at 12:47, Fabio Estevam festevam@gmail.com wrote: > > Hi Lukasz, > > On Thu, Aug 15, 2024 at 5:14 PM Lukasz Majewski > lukma@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@denx.de Date: Fri Apr 26 01:00:37 2024 +0200
ARM: dts: imx: Convert i.MX8M flash.bin image generation to binmanI 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.
adam
adam
I've applied: https://patchwork.ozlabs.org/project/uboot/cover/20240826191143.426387-1-sjg...
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@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@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@denx.de
On Mon, Nov 4, 2024 at 2:14 AM Lukasz Majewski lukma@denx.de wrote:
Hi Adam,
On Sun, Nov 3, 2024 at 7:41 PM Adam Ford aford173@gmail.com wrote:
On Thu, Sep 5, 2024 at 8:54 AM Lukasz Majewski lukma@denx.de wrote:
Hi Adam,
On Wed, Aug 28, 2024 at 3:04 AM Lukasz Majewski lukma@denx.de wrote:
Hi Simon,
> Hi, > > On Tue, 27 Aug 2024 at 12:47, Fabio Estevam > festevam@gmail.com wrote: > > > > Hi Lukasz, > > > > On Thu, Aug 15, 2024 at 5:14 PM Lukasz Majewski > > lukma@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@denx.de Date: Fri Apr 26 01:00:37 2024 +0200
ARM: dts: imx: Convert i.MX8M flash.bin image generation to binmanI 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...
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@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@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@denx.de
On Fri, Nov 8, 2024 at 7:04 PM Adam Ford aford173@gmail.com wrote:
On Mon, Nov 4, 2024 at 2:14 AM Lukasz Majewski lukma@denx.de wrote:
Hi Adam,
On Sun, Nov 3, 2024 at 7:41 PM Adam Ford aford173@gmail.com wrote:
On Thu, Sep 5, 2024 at 8:54 AM Lukasz Majewski lukma@denx.de wrote:
Hi Adam,
On Wed, Aug 28, 2024 at 3:04 AM Lukasz Majewski lukma@denx.de wrote: > > Hi Simon, > > > Hi, > > > > On Tue, 27 Aug 2024 at 12:47, Fabio Estevam > > festevam@gmail.com wrote: > > > > > > Hi Lukasz, > > > > > > On Thu, Aug 15, 2024 at 5:14 PM Lukasz Majewski > > > lukma@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@denx.de Date: Fri Apr 26 01:00:37 2024 +0200
ARM: dts: imx: Convert i.MX8M flash.bin image generation to binmanI 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.
I think I have a fix for the Nano. I want to get my hands on a Mini again to test it. My solution creates two files, a flash.bin for booting SD/eMMC and a second file which adds the FSPI header at 0x400 with the whole standard image starting at 0x1000. I have been able to boot both the SD and eMMC's with one config option which can allow me to remove the FSPI config file and consolidate both configs into one. Once I can verify it works on Mini, I'll post my proposed fix.
adam
adam
adam
adam
I've applied: https://patchwork.ozlabs.org/project/uboot/cover/20240826191143.426387-1-sjg...
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@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@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@denx.de
On Fri, Nov 8, 2024 at 11:12 PM Adam Ford aford173@gmail.com wrote:
I think I have a fix for the Nano. I want to get my hands on a Mini again to test it. My solution creates two files, a flash.bin for booting SD/eMMC and a second file which adds the FSPI header at 0x400 with the whole standard image starting at 0x1000. I have been able to boot both the SD and eMMC's with one config option which can allow me to remove the FSPI config file and consolidate both configs into one. Once I can verify it works on Mini, I'll post my proposed fix.
Thanks, Adam. Appreciate your effort!
On Fri, Nov 8, 2024 at 8:16 PM Fabio Estevam festevam@gmail.com wrote:
On Fri, Nov 8, 2024 at 11:12 PM Adam Ford aford173@gmail.com wrote:
I think I have a fix for the Nano. I want to get my hands on a Mini again to test it. My solution creates two files, a flash.bin for booting SD/eMMC and a second file which adds the FSPI header at 0x400 with the whole standard image starting at 0x1000. I have been able to boot both the SD and eMMC's with one config option which can allow me to remove the FSPI config file and consolidate both configs into one. Once I can verify it works on Mini, I'll post my proposed fix.
Thanks, Adam. Appreciate your effort!
No problem. I managed to get my hands on a Mini, and I just sent a patch series which restored FSPI booting on both the im8mn-beacon and imx8mm-beacon boards.
If/when I get some more time, I might try to port the stuff I did for Nano to the Plus since I think the boot ROM is similar between them.
adam
Hi Fabio,
Hi Lukasz,
On Thu, Aug 15, 2024 at 5:14 PM Lukasz Majewski lukma@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?
With newest mainline - yes.
Please consult (this works on polis): https://github.com/lmajewski/u-boot/commits/phycore-imx8mm-qspi-nvme
The spl symbols after binman generation are off by 0x1000 (by the inserted on the beginning QSPI header)
I am adding Adam and Mamta who have tested QSPI booting on imx8mm_beacon and imx8mm_evk, respectively.
Ok. Good.
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
participants (4)
-
Adam Ford -
Fabio Estevam -
Lukasz Majewski -
Simon Glass