[Binman] Question regarding SPL symbol offsets generation

[Binman] Question regarding SPL symbol offsets generation

[Lukasz Majewski]

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

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-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

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

Re: [Binman] Question regarding SPL symbol offsets generation

[Simon Glass]

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-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

Re: [Binman] Question regarding SPL symbol offsets generation

[Lukasz Majewski]

[-- 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 --]

Re: [Binman] Question regarding SPL symbol offsets generation

[Fabio Estevam]

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

Re: [Binman] Question regarding SPL symbol offsets generation

[Lukasz Majewski]

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

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

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

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

Re: [Binman] Question regarding SPL symbol offsets generation

[Fabio Estevam]

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.

Re: [Binman] Question regarding SPL symbol offsets generation

[Simon Glass]

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

Re: [Binman] Question regarding SPL symbol offsets generation

[Lukasz Majewski]

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

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

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

Re: [Binman] Question regarding SPL symbol offsets generation

[Adam Ford]

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

Re: [Binman] Question regarding SPL symbol offsets generation

[Lukasz Majewski]

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

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@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@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

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

Re: [Binman] Question regarding SPL symbol offsets generation

[Simon Glass]

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@chromium.org/
>
> 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

Re: [Binman] Question regarding SPL symbol offsets generation

[Lukasz Majewski]

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

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@chromium.org/
> >
> > 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-patches

> 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/07c0057fcfd242fa791767aaf0ac752d3d0545f7


> 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

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

Re: [Binman] Question regarding SPL symbol offsets generation

[Simon Glass]

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@chromium.org/
> > >
> > > 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-patches
>
> > 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/07c0057fcfd242fa791767aaf0ac752d3d0545f7

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

Re: [Binman] Question regarding SPL symbol offsets generation

[Lukasz Majewski]

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

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@chromium.org/
> > > >
> > > > 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-patches
> >  
> > > 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/07c0057fcfd242fa791767aaf0ac752d3d0545f7
> >  
> 
> 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

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

Re: [Binman] Question regarding SPL symbol offsets generation

[Adam Ford]

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@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@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

Re: [Binman] Question regarding SPL symbol offsets generation

[Adam Ford]

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@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@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

Re: [Binman] Question regarding SPL symbol offsets generation

[Adam Ford]

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 binman
>
> I 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@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@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

Re: [Binman] Question regarding SPL symbol offsets generation

[Lukasz Majewski]

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

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 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.

> 
> 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@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

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

Re: [Binman] Question regarding SPL symbol offsets generation

[Adam Ford]

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 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@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

Re: [Binman] Question regarding SPL symbol offsets generation

[Adam Ford]

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 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.

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@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@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

Re: [Binman] Question regarding SPL symbol offsets generation

[Fabio Estevam]

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!

Re: [Binman] Question regarding SPL symbol offsets generation

[Adam Ford]

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

Re: [Binman] Question regarding SPL symbol offsets generation

[Lukasz Majewski]

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

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

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