[PATCH v2 0/1] meson: Demonstration of using binman to produce the image

[PATCH v2 0/1] meson: Demonstration of using binman to produce the image

[Simon Glass]

The Odroid-C2 is quite a complicated image with many steps. It is an ideal
example for how Binman can be used.

Add a binman description and update the instructions accordingly.

Changes in v2:
- Rebase to -next

Simon Glass (1):
  RFC: Move Odroid-C2 to use binman to produce the image

 arch/arm/dts/meson-sm1-odroid-c4-u-boot.dtsi | 107 ++++++++++++++++
 arch/arm/mach-meson/Kconfig                  |   1 +
 doc/board/amlogic/odroid-c4.rst              | 127 +++++--------------
 tools/binman/etype/aml_encrypt.py            | 124 ++++++++++++++++++
 tools/binman/ftest.py                        |   3 +
 tools/binman/missing-blob-help               |   6 +
 tools/binman/test/213_aml_encrypt.dts        |  38 ++++++
 tools/binman/test/214_list_no_dtb.dts        |  23 ++++
 8 files changed, 337 insertions(+), 92 deletions(-)
 create mode 100644 tools/binman/etype/aml_encrypt.py
 create mode 100644 tools/binman/test/213_aml_encrypt.dts
 create mode 100644 tools/binman/test/214_list_no_dtb.dts

-- 
2.40.0.348.gf938b09366-goog

Re: [PATCH v2 0/1] meson: Demonstration of using binman to produce the image

[Ferass El Hafidi]

Hi Simon,

On Thu Aug 31, 2023 at 9:54 AM CEST, neil.armstrong wrote:
> > Thanks for your efforts on this. I look forward to seeing where it ends up.

I hope we can get it to at least boot!

> >> Honestly, in my opinion, including proprietary and poorly-written
> >> Amlogic utilities lacking a proper license, into U-Boot looks like a bad idea.
> >
> > With Binman, we don't really include them in U-Boot; we allow them to
> > be fetched easily so that a complete build can be produced.

Acknowledged.

> > I don't like it either, but for users it is better than doing the
> > build manually.
>
> I'll rather spend time and effort to have a fully-upstream TF-A boot chain
> for Amlogic SoC (when possible) that maintaining support for bulky closed-source
> x86-64 binary only tools. The tools aren't even officially distributed.

I agree with Neil here. I think having U-Boot SPL for Amlogic SoCs, along with 
a unified way to sign it across all SoCs, is more worth the effort than
trying to get poorly-written Amlogic utilities to work, along with a
fully proprietary "Trusted Firmware" (it's not that secure) boot chain.
I also forgot to point out that these tools are x86_64-only, so if you
wanted to compile U-Boot on any other architecture it wouldn't work at
all.

But this RFC patch does show how binman can be used for making all that
complex signing automatically. I appreciate the effort.

>
> Neil
>
> >
> >>
> >> [1]: https://git.vitali64.duckdns.org/misc/u-boot-kii-pro.git/log/?h=wip/spl
> >> [2]: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/plat/amlogic
> >>
> >> Cheers.
> >>
> >
> > Regards,
> > Simon

Cheers.

Re: [PATCH v2 0/1] meson: Demonstration of using binman to produce the image

[neil.armstrong]

On 31/08/2023 05:37, Simon Glass wrote:
> Hi Ferass,
> 
> On Wed, 30 Aug 2023 at 11:53, Ferass El Hafidi
> <vitali64pmemail@protonmail.com> wrote:
>>
>> Hi Simon,
>>
>>> So I wonder how best to move this forward so that we can build things
>>> using binman and everything works?
>>
>> It's still not ready yet, but I'm working on porting U-Boot SPL to some
>> Amlogic SoCs [1]. I'm currently working on Amlogic S905 boards, but
>> eventually I'll work on Amlogic S905X devices too. And speaking of
>> signing, Jonas Karlman wrote amlimage, and integrated it into mkimage,
>> and I applied his patch to my tree. There's a few things to be aware of
>> about Amlogic signing and binaries in general, however.
>>
>> amlimage was intended for use with U-Boot SPL, which obviously has
>> no support for Amlogic's FIP format and as such amlimage will only do as
>> little as possible to get the bootROM to load U-Boot SPL. Most of the
>> packaging format is handled by BL2. The fact that the signing process is
>> completly different across SoC generations makes it difficult to
>> implement them all into one single tool (and by which I mean all of it,
>> not just signing BL2 for the bootROM to run it, that's mostly the same
>> across SoCs). amlimage has been confirmed to work on GXBB (ODROID-C2 and
>> the KII Pro set-top box), GXL (librecomputer lepotato), and SM1 (ODROID-C4).
>>
>> My U-Boot SPL port is still rather incomplete. As of today, it still
>> can't boot anything from any storage device. The goal eventually is to
>> be able to load upstream TF-A BL31 and U-Boot+linux.
>>
>> While Amlogic distributes proprietary BL31 binaries upstream Trusted
>> Firmware-A has a port for some Amlogic SoCs [2], but as far as I know
>> SM1 (which is the SoC generation your ODROID-C4 is using) is still
>> unsupported. GXBB, GXL, AXG, and G12A are all supported however, but the
>> overall port still lacks some features the proprietary implementation
>> has.
>>
>> As for the SCP firmware (aka. BL30) I'm not aware of any
>> reverse-engineering efforts for that.
>>
> 
> Thanks for your efforts on this. I look forward to seeing where it ends up.
> 
>> Honestly, in my opinion, including proprietary and poorly-written
>> Amlogic utilities lacking a proper license, into U-Boot looks like a bad idea.
> 
> With Binman, we don't really include them in U-Boot; we allow them to
> be fetched easily so that a complete build can be produced.
> 
> I don't like it either, but for users it is better than doing the
> build manually.

I'll rather spend time and effort to have a fully-upstream TF-A boot chain
for Amlogic SoC (when possible) that maintaining support for bulky closed-source
x86-64 binary only tools. The tools aren't even officially distributed.

Neil

> 
>>
>> [1]: https://git.vitali64.duckdns.org/misc/u-boot-kii-pro.git/log/?h=wip/spl
>> [2]: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/plat/amlogic
>>
>> Cheers.
>>
> 
> Regards,
> Simon

Re: [PATCH v2 0/1] meson: Demonstration of using binman to produce the image

[Simon Glass]

Hi Ferass,

On Wed, 30 Aug 2023 at 11:53, Ferass El Hafidi
<vitali64pmemail@protonmail.com> wrote:
>
> Hi Simon,
>
> > So I wonder how best to move this forward so that we can build things
> > using binman and everything works?
>
> It's still not ready yet, but I'm working on porting U-Boot SPL to some
> Amlogic SoCs [1]. I'm currently working on Amlogic S905 boards, but
> eventually I'll work on Amlogic S905X devices too. And speaking of
> signing, Jonas Karlman wrote amlimage, and integrated it into mkimage,
> and I applied his patch to my tree. There's a few things to be aware of
> about Amlogic signing and binaries in general, however.
>
> amlimage was intended for use with U-Boot SPL, which obviously has
> no support for Amlogic's FIP format and as such amlimage will only do as
> little as possible to get the bootROM to load U-Boot SPL. Most of the
> packaging format is handled by BL2. The fact that the signing process is
> completly different across SoC generations makes it difficult to
> implement them all into one single tool (and by which I mean all of it,
> not just signing BL2 for the bootROM to run it, that's mostly the same
> across SoCs). amlimage has been confirmed to work on GXBB (ODROID-C2 and
> the KII Pro set-top box), GXL (librecomputer lepotato), and SM1 (ODROID-C4).
>
> My U-Boot SPL port is still rather incomplete. As of today, it still
> can't boot anything from any storage device. The goal eventually is to
> be able to load upstream TF-A BL31 and U-Boot+linux.
>
> While Amlogic distributes proprietary BL31 binaries upstream Trusted
> Firmware-A has a port for some Amlogic SoCs [2], but as far as I know
> SM1 (which is the SoC generation your ODROID-C4 is using) is still
> unsupported. GXBB, GXL, AXG, and G12A are all supported however, but the
> overall port still lacks some features the proprietary implementation
> has.
>
> As for the SCP firmware (aka. BL30) I'm not aware of any
> reverse-engineering efforts for that.
>

Thanks for your efforts on this. I look forward to seeing where it ends up.

> Honestly, in my opinion, including proprietary and poorly-written
> Amlogic utilities lacking a proper license, into U-Boot looks like a bad idea.

With Binman, we don't really include them in U-Boot; we allow them to
be fetched easily so that a complete build can be produced.

I don't like it either, but for users it is better than doing the
build manually.

>
> [1]: https://git.vitali64.duckdns.org/misc/u-boot-kii-pro.git/log/?h=wip/spl
> [2]: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/plat/amlogic
>
> Cheers.
>

Regards,
Simon

Re: [PATCH v2 0/1] meson: Demonstration of using binman to produce the image

[Ferass El Hafidi]

Hi Simon,

> So I wonder how best to move this forward so that we can build things
> using binman and everything works?

It's still not ready yet, but I'm working on porting U-Boot SPL to some
Amlogic SoCs [1]. I'm currently working on Amlogic S905 boards, but
eventually I'll work on Amlogic S905X devices too. And speaking of
signing, Jonas Karlman wrote amlimage, and integrated it into mkimage, 
and I applied his patch to my tree. There's a few things to be aware of 
about Amlogic signing and binaries in general, however.

amlimage was intended for use with U-Boot SPL, which obviously has 
no support for Amlogic's FIP format and as such amlimage will only do as 
little as possible to get the bootROM to load U-Boot SPL. Most of the 
packaging format is handled by BL2. The fact that the signing process is
completly different across SoC generations makes it difficult to
implement them all into one single tool (and by which I mean all of it,
not just signing BL2 for the bootROM to run it, that's mostly the same
across SoCs). amlimage has been confirmed to work on GXBB (ODROID-C2 and
the KII Pro set-top box), GXL (librecomputer lepotato), and SM1 (ODROID-C4).

My U-Boot SPL port is still rather incomplete. As of today, it still
can't boot anything from any storage device. The goal eventually is to
be able to load upstream TF-A BL31 and U-Boot+linux.

While Amlogic distributes proprietary BL31 binaries upstream Trusted 
Firmware-A has a port for some Amlogic SoCs [2], but as far as I know 
SM1 (which is the SoC generation your ODROID-C4 is using) is still
unsupported. GXBB, GXL, AXG, and G12A are all supported however, but the
overall port still lacks some features the proprietary implementation
has.

As for the SCP firmware (aka. BL30) I'm not aware of any
reverse-engineering efforts for that.

Honestly, in my opinion, including proprietary and poorly-written 
Amlogic utilities lacking a proper license, into U-Boot looks like a bad idea.

[1]: https://git.vitali64.duckdns.org/misc/u-boot-kii-pro.git/log/?h=wip/spl
[2]: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/plat/amlogic

Cheers.

Re: [PATCH v2 0/1] meson: Demonstration of using binman to produce the image

[Simon Glass]

Hi Da,

On Fri, 7 Apr 2023 at 21:34, Da Xue <da@lessconfused.com> wrote:
>
> On Wed, Apr 5, 2023 at 2:39 PM Simon Glass <sjg@chromium.org> wrote:
> >
> > Hi Christian,
> >
> > On Mon, 3 Apr 2023 at 20:10, Christian Hewitt
> > <christianshewitt@gmail.com> wrote:
> > >
> > > > On 2 Apr 2023, at 6:41 am, Simon Glass <sjg@chromium.org> wrote:
> > > >
> > > > Hi Mark,
> > > >
> > > > On Sun, 2 Apr 2023 at 09:28, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
> > > > >
> > > > > > From: Simon Glass <sjg@chromium.org>
> > > > > > Date: Sun,  2 Apr 2023 06:54:57 +1200
> > > > > >
> > > > > > The Odroid-C2 is quite a complicated image with many steps. It is an ideal
> > > > > > example for how Binman can be used.
> > > > >
> > > > > You say Odroid-C2, but the patches seem to address the Odroid-C4...
> > > >
> > > > Ah, yes. The difference seems to be an Amlogic S905 on the C2 and an S902X3 on the C4. I wonder if that affects the image makeup?
> > >
> > > There are currently four different signing recipes that depend on the
> > > board family that you are building for:
> > >
> > > - GXBB
> > > - GXL/GXM
> > > - G12A/SM1
> > > - G12B
> > >
> > > The G12A/SM1 and G12B recipes are identical except for a different
> > > signing binary used. The latest Amlogic boards (S905X4, T7, etc.)
> > > also have incremental changes, but none are currently supported in
> > > Linux or u-boot.
> > >
> > > One of the challenges for binman will be the signing tools. Currently
> > > this patchset depends upon Amlogic binaries. Apart from them being
> > > closed-source and thus undesirable, they are also x86_64 only and
> > > there are quite a few users (and at least one major distro) needing
> > > to build on arm64 hardware.
> > >
> > > There is an open-source tool called gxlimg which supports GXL and newer
> > > boards. IMHO it would make a lot of sense for u-boot to absorb the
> > > functionality of gxlimg (and extend support backwards to GXBB) as this
> > > would remove the dependency on Amlogic binaries and allow u-boot build
> > > and binman signing to be done anywhere.
> > >
> > > https://github.com/repk/gxlimg
>
> gxlimg also does not have the full featureset of the Amlogic signer.
> The most important to me being lz4 compression.
> I'm still trying to get support from Amlogic for open source ATF at
> least for GXX but that has numerous hurdles to overcome and more
> hurdles for future designs.

That's fine, but it doesn't need to be open source for binman to use it.

>
> >
> > Fair enough, but another option would be to allow 'binman tool -f
> > gxlimg' to work, which should be easy. Then we can make use of the
> > existing C code, using binary tools for the unsupported ones.
> >
> > >
> > > > The patch is for testing by Christian, who I hope can help get this landed for all the Amlogic boards.
> > >
> > > I will try to find the time to test this, but it’s not something I
> > > could do more with (as only supporting 1/4 of the board families
> > > that I need to build for, bu I do appreciate it’s a POC).
> >
> > Yes, it's a start.
> >
> > >
> > > In case you’re not aware, Makefile based signing is implemented in
> > > the amlogic-boot-fip repo that I’m currently tooled around:
> > >
> > > https://github.com/LibreELEC/amlogic-boot-fip
>
> The issue with the boot fips is that they control too many things (CPU
> freq, DDR freq, M3 control code, and more) to make it universal.

OK.

So I wonder how best to move this forward so that we can build things
using binman and everything works?


>
> > >
> > > This is the “competition” so to speak. It’s quite simple and widely
> > > used by most of the Amlogic supporting distros right now.
> >
> > Well at least that provides the recipes.
Regards,
Simon

Re: [PATCH v2 0/1] meson: Demonstration of using binman to produce the image

[Da Xue]

On Wed, Apr 5, 2023 at 2:39 PM Simon Glass <sjg@chromium.org> wrote:
>
> Hi Christian,
>
> On Mon, 3 Apr 2023 at 20:10, Christian Hewitt
> <christianshewitt@gmail.com> wrote:
> >
> > > On 2 Apr 2023, at 6:41 am, Simon Glass <sjg@chromium.org> wrote:
> > >
> > > Hi Mark,
> > >
> > > On Sun, 2 Apr 2023 at 09:28, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
> > > >
> > > > > From: Simon Glass <sjg@chromium.org>
> > > > > Date: Sun,  2 Apr 2023 06:54:57 +1200
> > > > >
> > > > > The Odroid-C2 is quite a complicated image with many steps. It is an ideal
> > > > > example for how Binman can be used.
> > > >
> > > > You say Odroid-C2, but the patches seem to address the Odroid-C4...
> > >
> > > Ah, yes. The difference seems to be an Amlogic S905 on the C2 and an S902X3 on the C4. I wonder if that affects the image makeup?
> >
> > There are currently four different signing recipes that depend on the
> > board family that you are building for:
> >
> > - GXBB
> > - GXL/GXM
> > - G12A/SM1
> > - G12B
> >
> > The G12A/SM1 and G12B recipes are identical except for a different
> > signing binary used. The latest Amlogic boards (S905X4, T7, etc.)
> > also have incremental changes, but none are currently supported in
> > Linux or u-boot.
> >
> > One of the challenges for binman will be the signing tools. Currently
> > this patchset depends upon Amlogic binaries. Apart from them being
> > closed-source and thus undesirable, they are also x86_64 only and
> > there are quite a few users (and at least one major distro) needing
> > to build on arm64 hardware.
> >
> > There is an open-source tool called gxlimg which supports GXL and newer
> > boards. IMHO it would make a lot of sense for u-boot to absorb the
> > functionality of gxlimg (and extend support backwards to GXBB) as this
> > would remove the dependency on Amlogic binaries and allow u-boot build
> > and binman signing to be done anywhere.
> >
> > https://github.com/repk/gxlimg

gxlimg also does not have the full featureset of the Amlogic signer.
The most important to me being lz4 compression.
I'm still trying to get support from Amlogic for open source ATF at
least for GXX but that has numerous hurdles to overcome and more
hurdles for future designs.

>
> Fair enough, but another option would be to allow 'binman tool -f
> gxlimg' to work, which should be easy. Then we can make use of the
> existing C code, using binary tools for the unsupported ones.
>
> >
> > > The patch is for testing by Christian, who I hope can help get this landed for all the Amlogic boards.
> >
> > I will try to find the time to test this, but it’s not something I
> > could do more with (as only supporting 1/4 of the board families
> > that I need to build for, bu I do appreciate it’s a POC).
>
> Yes, it's a start.
>
> >
> > In case you’re not aware, Makefile based signing is implemented in
> > the amlogic-boot-fip repo that I’m currently tooled around:
> >
> > https://github.com/LibreELEC/amlogic-boot-fip

The issue with the boot fips is that they control too many things (CPU
freq, DDR freq, M3 control code, and more) to make it universal.

> >
> > This is the “competition” so to speak. It’s quite simple and widely
> > used by most of the Amlogic supporting distros right now.
>
> Well at least that provides the recipes.
>
> Regards,
> Simon
>
> _______________________________________________
> linux-amlogic mailing list
> linux-amlogic@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-amlogic

Re: [PATCH v2 0/1] meson: Demonstration of using binman to produce the image

[Simon Glass]

Hi Christian,

On Mon, 3 Apr 2023 at 20:10, Christian Hewitt
<christianshewitt@gmail.com> wrote:
>
> > On 2 Apr 2023, at 6:41 am, Simon Glass <sjg@chromium.org> wrote:
> >
> > Hi Mark,
> >
> > On Sun, 2 Apr 2023 at 09:28, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
> > >
> > > > From: Simon Glass <sjg@chromium.org>
> > > > Date: Sun,  2 Apr 2023 06:54:57 +1200
> > > >
> > > > The Odroid-C2 is quite a complicated image with many steps. It is an ideal
> > > > example for how Binman can be used.
> > >
> > > You say Odroid-C2, but the patches seem to address the Odroid-C4...
> >
> > Ah, yes. The difference seems to be an Amlogic S905 on the C2 and an S902X3 on the C4. I wonder if that affects the image makeup?
>
> There are currently four different signing recipes that depend on the
> board family that you are building for:
>
> - GXBB
> - GXL/GXM
> - G12A/SM1
> - G12B
>
> The G12A/SM1 and G12B recipes are identical except for a different
> signing binary used. The latest Amlogic boards (S905X4, T7, etc.)
> also have incremental changes, but none are currently supported in
> Linux or u-boot.
>
> One of the challenges for binman will be the signing tools. Currently
> this patchset depends upon Amlogic binaries. Apart from them being
> closed-source and thus undesirable, they are also x86_64 only and
> there are quite a few users (and at least one major distro) needing
> to build on arm64 hardware.
>
> There is an open-source tool called gxlimg which supports GXL and newer
> boards. IMHO it would make a lot of sense for u-boot to absorb the
> functionality of gxlimg (and extend support backwards to GXBB) as this
> would remove the dependency on Amlogic binaries and allow u-boot build
> and binman signing to be done anywhere.
>
> https://github.com/repk/gxlimg

Fair enough, but another option would be to allow 'binman tool -f
gxlimg' to work, which should be easy. Then we can make use of the
existing C code, using binary tools for the unsupported ones.

>
> > The patch is for testing by Christian, who I hope can help get this landed for all the Amlogic boards.
>
> I will try to find the time to test this, but it’s not something I
> could do more with (as only supporting 1/4 of the board families
> that I need to build for, bu I do appreciate it’s a POC).

Yes, it's a start.

>
> In case you’re not aware, Makefile based signing is implemented in
> the amlogic-boot-fip repo that I’m currently tooled around:
>
> https://github.com/LibreELEC/amlogic-boot-fip
>
> This is the “competition” so to speak. It’s quite simple and widely
> used by most of the Amlogic supporting distros right now.

Well at least that provides the recipes.

Regards,
Simon

Re: [PATCH v2 0/1] meson: Demonstration of using binman to produce the image

[Christian Hewitt]

> On 2 Apr 2023, at 6:41 am, Simon Glass <sjg@chromium.org> wrote:
> 
> Hi Mark,
> 
> On Sun, 2 Apr 2023 at 09:28, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
> >
> > > From: Simon Glass <sjg@chromium.org>
> > > Date: Sun,  2 Apr 2023 06:54:57 +1200
> > >
> > > The Odroid-C2 is quite a complicated image with many steps. It is an ideal
> > > example for how Binman can be used.
> >
> > You say Odroid-C2, but the patches seem to address the Odroid-C4...
> 
> Ah, yes. The difference seems to be an Amlogic S905 on the C2 and an S902X3 on the C4. I wonder if that affects the image makeup?

There are currently four different signing recipes that depend on the
board family that you are building for:

- GXBB
- GXL/GXM
- G12A/SM1
- G12B

The G12A/SM1 and G12B recipes are identical except for a different
signing binary used. The latest Amlogic boards (S905X4, T7, etc.)
also have incremental changes, but none are currently supported in
Linux or u-boot.

One of the challenges for binman will be the signing tools. Currently
this patchset depends upon Amlogic binaries. Apart from them being
closed-source and thus undesirable, they are also x86_64 only and
there are quite a few users (and at least one major distro) needing
to build on arm64 hardware.

There is an open-source tool called gxlimg which supports GXL and newer
boards. IMHO it would make a lot of sense for u-boot to absorb the
functionality of gxlimg (and extend support backwards to GXBB) as this
would remove the dependency on Amlogic binaries and allow u-boot build
and binman signing to be done anywhere.

https://github.com/repk/gxlimg

> The patch is for testing by Christian, who I hope can help get this landed for all the Amlogic boards.

I will try to find the time to test this, but it’s not something I
could do more with (as only supporting 1/4 of the board families
that I need to build for, bu I do appreciate it’s a POC).

In case you’re not aware, Makefile based signing is implemented in
the amlogic-boot-fip repo that I’m currently tooled around:

https://github.com/LibreELEC/amlogic-boot-fip 

This is the “competition” so to speak. It’s quite simple and widely
used by most of the Amlogic supporting distros right now.

Christian

> >
> > > Add a binman description and update the instructions accordingly.
> > >
> > > Changes in v2:
> > > - Rebase to -next
> > >
> > > Simon Glass (1):
> > >   RFC: Move Odroid-C2 to use binman to produce the image
> > >
> > >  arch/arm/dts/meson-sm1-odroid-c4-u-boot.dtsi | 107 ++++++++++++++++
> > >  arch/arm/mach-meson/Kconfig                  |   1 +
> > >  doc/board/amlogic/odroid-c4.rst              | 127 +++++--------------
> > >  tools/binman/etype/aml_encrypt.py            | 124 ++++++++++++++++++
> > >  tools/binman/ftest.py                        |   3 +
> > >  tools/binman/missing-blob-help               |   6 +
> > >  tools/binman/test/213_aml_encrypt.dts        |  38 ++++++
> > >  tools/binman/test/214_list_no_dtb.dts        |  23 ++++
> > >  8 files changed, 337 insertions(+), 92 deletions(-)
> > >  create mode 100644 tools/binman/etype/aml_encrypt.py
> > >  create mode 100644 tools/binman/test/213_aml_encrypt.dts
> > >  create mode 100644 tools/binman/test/214_list_no_dtb.dts
> > >
> 
> Regards,
> SImon

Re: [PATCH v2 0/1] meson: Demonstration of using binman to produce the image

[Simon Glass]

Hi Mark,

On Sun, 2 Apr 2023 at 09:28, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
>
> > From: Simon Glass <sjg@chromium.org>
> > Date: Sun,  2 Apr 2023 06:54:57 +1200
> >
> > The Odroid-C2 is quite a complicated image with many steps. It is an
ideal
> > example for how Binman can be used.
>
> You say Odroid-C2, but the patches seem to address the Odroid-C4...

Ah, yes. The difference seems to be an Amlogic S905 on the C2 and an S902X3
on the C4. I wonder if that affects the image makeup?

The patch is for testing by Christian, who I hope can help get this landed
for all the Amlogic boards.

>
> > Add a binman description and update the instructions accordingly.
> >
> > Changes in v2:
> > - Rebase to -next
> >
> > Simon Glass (1):
> >   RFC: Move Odroid-C2 to use binman to produce the image
> >
> >  arch/arm/dts/meson-sm1-odroid-c4-u-boot.dtsi | 107 ++++++++++++++++
> >  arch/arm/mach-meson/Kconfig                  |   1 +
> >  doc/board/amlogic/odroid-c4.rst              | 127 +++++--------------
> >  tools/binman/etype/aml_encrypt.py            | 124 ++++++++++++++++++
> >  tools/binman/ftest.py                        |   3 +
> >  tools/binman/missing-blob-help               |   6 +
> >  tools/binman/test/213_aml_encrypt.dts        |  38 ++++++
> >  tools/binman/test/214_list_no_dtb.dts        |  23 ++++
> >  8 files changed, 337 insertions(+), 92 deletions(-)
> >  create mode 100644 tools/binman/etype/aml_encrypt.py
> >  create mode 100644 tools/binman/test/213_aml_encrypt.dts
> >  create mode 100644 tools/binman/test/214_list_no_dtb.dts
> >

Regards,
SImon

Re: [PATCH v2 0/1] meson: Demonstration of using binman to produce the image

[Mark Kettenis]

> From: Simon Glass <sjg@chromium.org>
> Date: Sun,  2 Apr 2023 06:54:57 +1200
> 
> The Odroid-C2 is quite a complicated image with many steps. It is an ideal
> example for how Binman can be used.

You say Odroid-C2, but the patches seem to address the Odroid-C4...

> Add a binman description and update the instructions accordingly.
> 
> Changes in v2:
> - Rebase to -next
> 
> Simon Glass (1):
>   RFC: Move Odroid-C2 to use binman to produce the image
> 
>  arch/arm/dts/meson-sm1-odroid-c4-u-boot.dtsi | 107 ++++++++++++++++
>  arch/arm/mach-meson/Kconfig                  |   1 +
>  doc/board/amlogic/odroid-c4.rst              | 127 +++++--------------
>  tools/binman/etype/aml_encrypt.py            | 124 ++++++++++++++++++
>  tools/binman/ftest.py                        |   3 +
>  tools/binman/missing-blob-help               |   6 +
>  tools/binman/test/213_aml_encrypt.dts        |  38 ++++++
>  tools/binman/test/214_list_no_dtb.dts        |  23 ++++
>  8 files changed, 337 insertions(+), 92 deletions(-)
>  create mode 100644 tools/binman/etype/aml_encrypt.py
>  create mode 100644 tools/binman/test/213_aml_encrypt.dts
>  create mode 100644 tools/binman/test/214_list_no_dtb.dts
> 
> -- 
> 2.40.0.348.gf938b09366-goog
> 
> 

[PATCH v2 0/1] meson: Demonstration of using binman to produce the image

[Simon Glass]

The Odroid-C2 is quite a complicated image with many steps. It is an ideal
example for how Binman can be used.

Add a binman description and update the instructions accordingly.

Changes in v2:
- Rebase to -next

Simon Glass (1):
  RFC: Move Odroid-C2 to use binman to produce the image

 arch/arm/dts/meson-sm1-odroid-c4-u-boot.dtsi | 107 ++++++++++++++++
 arch/arm/mach-meson/Kconfig                  |   1 +
 doc/board/amlogic/odroid-c4.rst              | 127 +++++--------------
 tools/binman/etype/aml_encrypt.py            | 124 ++++++++++++++++++
 tools/binman/ftest.py                        |   3 +
 tools/binman/missing-blob-help               |   6 +
 tools/binman/test/213_aml_encrypt.dts        |  38 ++++++
 tools/binman/test/214_list_no_dtb.dts        |  23 ++++
 8 files changed, 337 insertions(+), 92 deletions(-)
 create mode 100644 tools/binman/etype/aml_encrypt.py
 create mode 100644 tools/binman/test/213_aml_encrypt.dts
 create mode 100644 tools/binman/test/214_list_no_dtb.dts

-- 
2.40.0.348.gf938b09366-goog