Re: [RFC] imx8mm-evk: Generate a bootable flash.bin again

2021-08-18 Thread Marcel Ziswiler
On Wed, 2021-08-18 at 08:47 +0200, Frieder Schrempf wrote:
> > > 
> > > > Prior to 2021.07: only flash.bin was required. Yocto recipe, for
> > > > example, will no longer produce a bootable image
> > > > after the upgrade to 2021.07. This is the breakage I would like to 
> > > > avoid.
> > > 
> > > I vote for renaming flash.bin (in SPL case) to spl.bin. It seems to
> > > me there are many imx8*-u-boot.dtsi file now which use this part:
> > 
> > Yes, I think we should introduce a common dtsi file with a binman 
> > configuration that uses spl.bin for the
> > SPL image and flash.bin for the final image. Then we could switch all 
> > boards to use this config step by
> > step afterwards.
> 
> Actually this would require changing the SPL image name for all boards, or if 
> that's possible with binman,
> rename the flash.bin SPL image to spl.bin, before building the final image.

I agree with this probably being the best way forward.


Re: [RFC] imx8mm-evk: Generate a bootable flash.bin again

2021-08-18 Thread Frieder Schrempf
On 18.08.21 08:36, Frieder Schrempf wrote:
> On 18.08.21 07:19, Heiko Schocher wrote:
>> Hello Fabio,
>>
>> On 18.08.21 03:44, Fabio Estevam wrote:
>>> Hi Heiko,
>>>
>>> On Tue, Aug 17, 2021 at 12:56 AM Heiko Schocher  wrote:
>>>
 I am unsure here, if it makes sense to overwrite flash.bin with the
 binary which contains SPL and u-boot.itb. May others want to use
 them (as I currently use them for signing them)
>>>
>>> I thought about that too. Frieder suggested I use a different name for
>>> the SPL file, such as spl.bin.
>>>
>>> I am concerned that renaming flash.bin to spl.bin may break i.MX8MM
>>> targets that do not use binman, such as the verdin-imx8mm board.
>>
>> Hmm... okay, but I do not understand why spl code is named flash.bin
>> than?
>>
>> spl.bin seems better to me.
>>
 Why not imx-boot as image name as in NXP sources?
>>>
>>> NXP U-Boot also generates the final binary called "flash.bin"
>>
>> What do you mean with "final binary"? The binary which contains
>> SPL and u-boot (and all other needed binaries)?
>>
>> If so, is this really called flash.bin? So *same* name as "SPL only"
>> code? I could not believe this...
>>
>> NXP code does this not for all imx8 derivates, see comment:
>>
>> https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FFreescale%2Fmeta-freescale%2Fblob%2Fmaster%2Frecipes-bsp%2Fu-boot%2Fu-boot-fslc_2021.07.bb%23L31data=04%7C01%7Cfrieder.schrempf%40kontron.de%7C16c905859c304ef28b2408d962128945%7C8c9d3c973fd941c8a2b1646f3942daf1%7C0%7C0%7C637648654014439808%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=ulgHHxm9VozahAL9AjXrX6bYLBatsBvPQIxh1xziaU8%3Dreserved=0
>>
>> But yes, the container is named "flash.bin"...
>>
>>> My main motivation for sending this RFC patch is to avoid imx8mm-evk
>>> breakage when people upgrade
>>> to U-Boor 2021.07.
>>
>> U-Boot 2021.07 is broken? Or do you mean 2021.10?
>>
>> Ah, *now* I got it commit "8996e6b7c6a1" introduced a SPL based "flash.bin"
>> through arch/arm/dts/imx8mm-evk-u-boot.dtsi:
>>
>> +   flash {
>> +   mkimage {
>> +   args = "-n spl/u-boot-spl.cfgout -T imx8mimage -e 
>> 0x7e1000";
>> +
>> +   blob {
>> +   filename = "u-boot-spl-ddr.bin";
>> +   };
>> +   };
>> +   };
>>
>> -> now we have a "flash.bin" with SPL only code and a "flash.bin"
>> Makefile target which produces "flash.bin" which is a container
>> of SPL, U-Boot, dtb, atf, ... and may much more binaries...
>>
>> :-(
> 
> 
> Exactly, that's the main problem.
> 
>>
>> Added Peng to cc, as he did this conversion for imx8mm-evk-u-boot.dtsi
>>
>>> Prior to 2021.07: only flash.bin was required. Yocto recipe, for
>>> example, will no longer produce a bootable image
>>> after the upgrade to 2021.07. This is the breakage I would like to avoid.
>>
>> I vote for renaming flash.bin (in SPL case) to spl.bin. It seems to
>> me there are many imx8*-u-boot.dtsi file now which use this part:
> 
> Yes, I think we should introduce a common dtsi file with a binman 
> configuration that uses spl.bin for the SPL image and flash.bin for the final 
> image. Then we could switch all boards to use this config step by step 
> afterwards.

Actually this would require changing the SPL image name for all boards, or if 
that's possible with binman, rename the flash.bin SPL image to spl.bin, before 
building the final image.


Re: [RFC] imx8mm-evk: Generate a bootable flash.bin again

2021-08-18 Thread Frieder Schrempf
On 18.08.21 07:19, Heiko Schocher wrote:
> Hello Fabio,
> 
> On 18.08.21 03:44, Fabio Estevam wrote:
>> Hi Heiko,
>>
>> On Tue, Aug 17, 2021 at 12:56 AM Heiko Schocher  wrote:
>>
>>> I am unsure here, if it makes sense to overwrite flash.bin with the
>>> binary which contains SPL and u-boot.itb. May others want to use
>>> them (as I currently use them for signing them)
>>
>> I thought about that too. Frieder suggested I use a different name for
>> the SPL file, such as spl.bin.
>>
>> I am concerned that renaming flash.bin to spl.bin may break i.MX8MM
>> targets that do not use binman, such as the verdin-imx8mm board.
> 
> Hmm... okay, but I do not understand why spl code is named flash.bin
> than?
> 
> spl.bin seems better to me.
> 
>>> Why not imx-boot as image name as in NXP sources?
>>
>> NXP U-Boot also generates the final binary called "flash.bin"
> 
> What do you mean with "final binary"? The binary which contains
> SPL and u-boot (and all other needed binaries)?
> 
> If so, is this really called flash.bin? So *same* name as "SPL only"
> code? I could not believe this...
> 
> NXP code does this not for all imx8 derivates, see comment:
> 
> https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FFreescale%2Fmeta-freescale%2Fblob%2Fmaster%2Frecipes-bsp%2Fu-boot%2Fu-boot-fslc_2021.07.bb%23L31data=04%7C01%7Cfrieder.schrempf%40kontron.de%7C5a0d20c6c27e4d5c38bc08d96207bf7f%7C8c9d3c973fd941c8a2b1646f3942daf1%7C0%7C0%7C637648607684078827%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=Cbq1Eenz7z8BySR12NwZi2T0s1krCFQmDP4jeBMJle8%3Dreserved=0
> 
> But yes, the container is named "flash.bin"...
> 
>> My main motivation for sending this RFC patch is to avoid imx8mm-evk
>> breakage when people upgrade
>> to U-Boor 2021.07.
> 
> U-Boot 2021.07 is broken? Or do you mean 2021.10?
> 
> Ah, *now* I got it commit "8996e6b7c6a1" introduced a SPL based "flash.bin"
> through arch/arm/dts/imx8mm-evk-u-boot.dtsi:
> 
> +   flash {
> +   mkimage {
> +   args = "-n spl/u-boot-spl.cfgout -T imx8mimage -e 
> 0x7e1000";
> +
> +   blob {
> +   filename = "u-boot-spl-ddr.bin";
> +   };
> +   };
> +   };
> 
> -> now we have a "flash.bin" with SPL only code and a "flash.bin"
> Makefile target which produces "flash.bin" which is a container
> of SPL, U-Boot, dtb, atf, ... and may much more binaries...
> 
> :-(


Exactly, that's the main problem.

> 
> Added Peng to cc, as he did this conversion for imx8mm-evk-u-boot.dtsi
> 
>> Prior to 2021.07: only flash.bin was required. Yocto recipe, for
>> example, will no longer produce a bootable image
>> after the upgrade to 2021.07. This is the breakage I would like to avoid.
> 
> I vote for renaming flash.bin (in SPL case) to spl.bin. It seems to
> me there are many imx8*-u-boot.dtsi file now which use this part:

Yes, I think we should introduce a common dtsi file with a binman configuration 
that uses spl.bin for the SPL image and flash.bin for the final image. Then we 
could switch all boards to use this config step by step afterwards.

> 
> +   flash {
> +   mkimage {
> +   args = "-n spl/u-boot-spl.cfgout -T imx8mimage -e 
> 0x7e1000";
> +
> +   blob {
> +   filename = "u-boot-spl-ddr.bin";
> +   };
> +   };
> +   };
> 
> But may this rename is no problem, as all boards use the "flash.bin" 
> container?
> 
> I don;t know...
> 
> bye,
> Heiko
> 


Re: [RFC] imx8mm-evk: Generate a bootable flash.bin again

2021-08-18 Thread Frieder Schrempf
Hi Fabio,

On 18.08.21 03:44, Fabio Estevam wrote:
> Hi Heiko,
> 
> On Tue, Aug 17, 2021 at 12:56 AM Heiko Schocher  wrote:
> 
>> I am unsure here, if it makes sense to overwrite flash.bin with the
>> binary which contains SPL and u-boot.itb. May others want to use
>> them (as I currently use them for signing them)
> 
> I thought about that too. Frieder suggested I use a different name for
> the SPL file, such as spl.bin.
> 
> I am concerned that renaming flash.bin to spl.bin may break i.MX8MM
> targets that do not use binman, such as the verdin-imx8mm board.
> 
>> Why not imx-boot as image name as in NXP sources?
> 
> NXP U-Boot also generates the final binary called "flash.bin"
> 
> My main motivation for sending this RFC patch is to avoid imx8mm-evk
> breakage when people upgrade
> to U-Boor 2021.07.
> 
> Prior to 2021.07: only flash.bin was required. Yocto recipe, for
> example, will no longer produce a bootable image
> after the upgrade to 2021.07. This is the breakage I would like to avoid.

On the other hand, for example I have already adapted my (downstream) Yocto 
environment to the binman setup in 2021.07 and changing it back to the original 
behavior in the next release will break my Yocto recipes again. The breaking 
change is already in the release, so the harm is already done. Should we really 
spend effort to revert to the old scheme or rather switch to proper and 
meaningful names for the images now that we already broke it. But I see your 
point that this probably would require to move all boards to binman first 
before doing so.

And as Heiko already said, overwriting the SPL image with the final image is 
not really an option in my opinion. We might need the SPL image for other 
purposes and we should definitely make sure that it's still around after the 
final image has been built.

Best regards
Frieder


Re: [RFC] imx8mm-evk: Generate a bootable flash.bin again

2021-08-17 Thread Heiko Schocher
Hello Fabio,

On 18.08.21 03:44, Fabio Estevam wrote:
> Hi Heiko,
> 
> On Tue, Aug 17, 2021 at 12:56 AM Heiko Schocher  wrote:
> 
>> I am unsure here, if it makes sense to overwrite flash.bin with the
>> binary which contains SPL and u-boot.itb. May others want to use
>> them (as I currently use them for signing them)
> 
> I thought about that too. Frieder suggested I use a different name for
> the SPL file, such as spl.bin.
> 
> I am concerned that renaming flash.bin to spl.bin may break i.MX8MM
> targets that do not use binman, such as the verdin-imx8mm board.

Hmm... okay, but I do not understand why spl code is named flash.bin
than?

spl.bin seems better to me.

>> Why not imx-boot as image name as in NXP sources?
> 
> NXP U-Boot also generates the final binary called "flash.bin"

What do you mean with "final binary"? The binary which contains
SPL and u-boot (and all other needed binaries)?

If so, is this really called flash.bin? So *same* name as "SPL only"
code? I could not believe this...

NXP code does this not for all imx8 derivates, see comment:

https://github.com/Freescale/meta-freescale/blob/master/recipes-bsp/u-boot/u-boot-fslc_2021.07.bb#L31

But yes, the container is named "flash.bin"...

> My main motivation for sending this RFC patch is to avoid imx8mm-evk
> breakage when people upgrade
> to U-Boor 2021.07.

U-Boot 2021.07 is broken? Or do you mean 2021.10?

Ah, *now* I got it commit "8996e6b7c6a1" introduced a SPL based "flash.bin"
through arch/arm/dts/imx8mm-evk-u-boot.dtsi:

+   flash {
+   mkimage {
+   args = "-n spl/u-boot-spl.cfgout -T imx8mimage -e 
0x7e1000";
+
+   blob {
+   filename = "u-boot-spl-ddr.bin";
+   };
+   };
+   };

-> now we have a "flash.bin" with SPL only code and a "flash.bin"
Makefile target which produces "flash.bin" which is a container
of SPL, U-Boot, dtb, atf, ... and may much more binaries...

:-(

Added Peng to cc, as he did this conversion for imx8mm-evk-u-boot.dtsi

> Prior to 2021.07: only flash.bin was required. Yocto recipe, for
> example, will no longer produce a bootable image
> after the upgrade to 2021.07. This is the breakage I would like to avoid.

I vote for renaming flash.bin (in SPL case) to spl.bin. It seems to
me there are many imx8*-u-boot.dtsi file now which use this part:

+   flash {
+   mkimage {
+   args = "-n spl/u-boot-spl.cfgout -T imx8mimage -e 
0x7e1000";
+
+   blob {
+   filename = "u-boot-spl-ddr.bin";
+   };
+   };
+   };

But may this rename is no problem, as all boards use the "flash.bin" container?

I don;t know...

bye,
Heiko
-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: h...@denx.de


Re: [RFC] imx8mm-evk: Generate a bootable flash.bin again

2021-08-17 Thread Fabio Estevam
Hi Heiko,

On Tue, Aug 17, 2021 at 12:56 AM Heiko Schocher  wrote:

> I am unsure here, if it makes sense to overwrite flash.bin with the
> binary which contains SPL and u-boot.itb. May others want to use
> them (as I currently use them for signing them)

I thought about that too. Frieder suggested I use a different name for
the SPL file, such as spl.bin.

I am concerned that renaming flash.bin to spl.bin may break i.MX8MM
targets that do not use binman, such as the verdin-imx8mm board.

> Why not imx-boot as image name as in NXP sources?

NXP U-Boot also generates the final binary called "flash.bin"

My main motivation for sending this RFC patch is to avoid imx8mm-evk
breakage when people upgrade
to U-Boor 2021.07.

Prior to 2021.07: only flash.bin was required. Yocto recipe, for
example, will no longer produce a bootable image
after the upgrade to 2021.07. This is the breakage I would like to avoid.

Thanks


Re: [RFC] imx8mm-evk: Generate a bootable flash.bin again

2021-08-17 Thread Heiko Schocher
Hello Heiko,

On 17.08.21 11:37, Heiko Thiery wrote:
> Hi,
> 
> Am Di., 17. Aug. 2021 um 05:56 Uhr schrieb Heiko Schocher :
>>
>> Hello Fabio,
>>
>> On 16.08.21 17:21, Fabio Estevam wrote:
>>> After the convesion to binman in commit 8996e6b7c6a1 ("imx8mm_evk: switch
>>> to use binman to pack images"), it is necessary to flash both flash.bin and
>>> u-boot.itb to get a bootable system. Prior to this commit, only flash.bin
>>> was needed.
>>>
>>> Such new requirement breaks existing distro mechanisms to generate the
>>> final image because the extra u-boot.itb is now required.
>>>
>>> Generate a final flash.bin image that can be used again as a single
>>> bootable image to keep the original behavior.
>>>
>>> Suggested-by: Heiko Schocher 
>>> Signed-off-by: Fabio Estevam 
>>> ---
>>>  arch/arm/dts/imx8mm-evk-u-boot.dtsi | 15 +++
>>>  1 file changed, 15 insertions(+)
>>>
>>> diff --git a/arch/arm/dts/imx8mm-evk-u-boot.dtsi 
>>> b/arch/arm/dts/imx8mm-evk-u-boot.dtsi
>>> index f200afac9f..ad3056c7c8 100644
>>> --- a/arch/arm/dts/imx8mm-evk-u-boot.dtsi
>>> +++ b/arch/arm/dts/imx8mm-evk-u-boot.dtsi
>>> @@ -217,4 +217,19 @@
>>>   };
>>>   };
>>>   };
>>> +
>>> + imx-boot {
>>> + filename = "flash.bin";
>>
>> I am unsure here, if it makes sense to overwrite flash.bin with the
>> binary which contains SPL and u-boot.itb. May others want to use
>> them (as I currently use them for signing them)
>>
>> Why not imx-boot as image name as in NXP sources?
>> (Thats why I named it so in my "fast example approach")
> 
> Is it right that in that case a new u-boot makefile target has to be
> set? Currently flash.bin works because it is already set in
> "arch/arm/mach-imx/Makefile"?

No, I think not, that is binman magic ... binman creates the targets
which are defined in your DTS in the binman node, see:

u-boot:/tools/binman/README.rst

bye,
Heiko
-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: h...@denx.de


Re: [RFC] imx8mm-evk: Generate a bootable flash.bin again

2021-08-17 Thread Heiko Thiery
Hi,

Am Di., 17. Aug. 2021 um 05:56 Uhr schrieb Heiko Schocher :
>
> Hello Fabio,
>
> On 16.08.21 17:21, Fabio Estevam wrote:
> > After the convesion to binman in commit 8996e6b7c6a1 ("imx8mm_evk: switch
> > to use binman to pack images"), it is necessary to flash both flash.bin and
> > u-boot.itb to get a bootable system. Prior to this commit, only flash.bin
> > was needed.
> >
> > Such new requirement breaks existing distro mechanisms to generate the
> > final image because the extra u-boot.itb is now required.
> >
> > Generate a final flash.bin image that can be used again as a single
> > bootable image to keep the original behavior.
> >
> > Suggested-by: Heiko Schocher 
> > Signed-off-by: Fabio Estevam 
> > ---
> >  arch/arm/dts/imx8mm-evk-u-boot.dtsi | 15 +++
> >  1 file changed, 15 insertions(+)
> >
> > diff --git a/arch/arm/dts/imx8mm-evk-u-boot.dtsi 
> > b/arch/arm/dts/imx8mm-evk-u-boot.dtsi
> > index f200afac9f..ad3056c7c8 100644
> > --- a/arch/arm/dts/imx8mm-evk-u-boot.dtsi
> > +++ b/arch/arm/dts/imx8mm-evk-u-boot.dtsi
> > @@ -217,4 +217,19 @@
> >   };
> >   };
> >   };
> > +
> > + imx-boot {
> > + filename = "flash.bin";
>
> I am unsure here, if it makes sense to overwrite flash.bin with the
> binary which contains SPL and u-boot.itb. May others want to use
> them (as I currently use them for signing them)
>
> Why not imx-boot as image name as in NXP sources?
> (Thats why I named it so in my "fast example approach")

Is it right that in that case a new u-boot makefile target has to be
set? Currently flash.bin works because it is already set in
"arch/arm/mach-imx/Makefile"?

-- 
Heiko


Re: [RFC] imx8mm-evk: Generate a bootable flash.bin again

2021-08-16 Thread Heiko Schocher
Hello Fabio,

On 16.08.21 17:21, Fabio Estevam wrote:
> After the convesion to binman in commit 8996e6b7c6a1 ("imx8mm_evk: switch
> to use binman to pack images"), it is necessary to flash both flash.bin and
> u-boot.itb to get a bootable system. Prior to this commit, only flash.bin
> was needed.
> 
> Such new requirement breaks existing distro mechanisms to generate the
> final image because the extra u-boot.itb is now required.
> 
> Generate a final flash.bin image that can be used again as a single
> bootable image to keep the original behavior.
> 
> Suggested-by: Heiko Schocher 
> Signed-off-by: Fabio Estevam 
> ---
>  arch/arm/dts/imx8mm-evk-u-boot.dtsi | 15 +++
>  1 file changed, 15 insertions(+)
> 
> diff --git a/arch/arm/dts/imx8mm-evk-u-boot.dtsi 
> b/arch/arm/dts/imx8mm-evk-u-boot.dtsi
> index f200afac9f..ad3056c7c8 100644
> --- a/arch/arm/dts/imx8mm-evk-u-boot.dtsi
> +++ b/arch/arm/dts/imx8mm-evk-u-boot.dtsi
> @@ -217,4 +217,19 @@
>   };
>   };
>   };
> +
> + imx-boot {
> + filename = "flash.bin";

I am unsure here, if it makes sense to overwrite flash.bin with the
binary which contains SPL and u-boot.itb. May others want to use
them (as I currently use them for signing them)

Why not imx-boot as image name as in NXP sources?
(Thats why I named it so in my "fast example approach")

> + pad-byte = <0x00>;
> +
> + spl: blob-ext@1 {
> + offset = <0x0>;
> + filename = "flash.bin";
> + };
> +
> + uboot: blob-ext@2 {
> + offset = <0x57c00>;
> + filename = "u-boot.itb";
> + };
> + };
>  };
> 

regarding the question, if we can make a generic file .. for example
on the imx8mp-phyboard-pollux-rdk u-boot is at offset 0x6 in
QSPI NOR ( for QSPI boot of course)

So, there should be something like this:

+   imx-boot {
+   filename = "imx-boot";
+   pad-byte = <0x00>;
+
+   qspiheader: blob-ext@2 {
+   offset = <0x400>;
+   filename = "qspiheader.bin";
+   };
+
+   spl: blob-ext@2 {
+   offset = <0x1000>;
+   filename = "flash.bin";
+   };
+
+   uboot: blob-ext@3 {
+   offset = <0x6>;
+   filename = "u-boot.itb";
+   };
+   };

On sd card boot it is without qspiheader and offsets -0x1000, so
may we make a imx-boot and imx-boot-qspi ?

+   imx-boot {
+   filename = "imx-boot";
+   pad-byte = <0x00>;
+
+   spl: blob-ext@1 {
+   offset = <0x0>;
+   filename = "flash.bin";
+   };
+
+   uboot: blob-ext@2 {
+   offset = <0x59000>;
+   filename = "u-boot.itb";
+   };
+   };

+   imx-boot-qspi {
+   filename = "imx-boot-qspi";
+   pad-byte = <0x00>;
+
+   qspiheader: blob-ext@2 {
+   offset = <0x400>;
+   filename = "qspiheader.bin";
+   };
+
+   imx-boot: blob-ext@2 {
+   offset = <0x1000>;
+   filename = "imx-boot";
+   };
+   };

And of course we must add a possibility to create qspi header. I have
here local some python script, but not sure how to integrate this to
binman.

And it would be very cool, to sign the image with binman!

bye,
Heiko
-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: h...@denx.de