| Message ID | 20230401185458.2280200-1-sjg@chromium.org |
|---|---|
| Headers | show |
| Series | meson: Demonstration of using binman to produce the image | expand |
> 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 > >
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
> 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
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
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
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