Re: [PATCH v2 0/1] meson: Demonstration of using binman to produce the image
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
On 31/08/2023 05:37, Simon Glass wrote: Hi Ferass, On Wed, 30 Aug 2023 at 11:53, Ferass El Hafidi 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
Hi Ferass, On Wed, 30 Aug 2023 at 11:53, Ferass El Hafidi 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
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
Hi Da, On Fri, 7 Apr 2023 at 21:34, Da Xue wrote: > > On Wed, Apr 5, 2023 at 2:39 PM Simon Glass wrote: > > > > Hi Christian, > > > > On Mon, 3 Apr 2023 at 20:10, Christian Hewitt > > wrote: > > > > > > > On 2 Apr 2023, at 6:41 am, Simon Glass wrote: > > > > > > > > Hi Mark, > > > > > > > > On Sun, 2 Apr 2023 at 09:28, Mark Kettenis > > > > wrote: > > > > > > > > > > > From: Simon Glass > > > > > > 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
On Wed, Apr 5, 2023 at 2:39 PM Simon Glass wrote: > > Hi Christian, > > On Mon, 3 Apr 2023 at 20:10, Christian Hewitt > wrote: > > > > > On 2 Apr 2023, at 6:41 am, Simon Glass wrote: > > > > > > Hi Mark, > > > > > > On Sun, 2 Apr 2023 at 09:28, Mark Kettenis > > > wrote: > > > > > > > > > From: Simon Glass > > > > > 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-amlo...@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
Hi Christian, On Mon, 3 Apr 2023 at 20:10, Christian Hewitt wrote: > > > On 2 Apr 2023, at 6:41 am, Simon Glass wrote: > > > > Hi Mark, > > > > On Sun, 2 Apr 2023 at 09:28, Mark Kettenis wrote: > > > > > > > From: Simon Glass > > > > 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
> On 2 Apr 2023, at 6:41 am, Simon Glass wrote: > > Hi Mark, > > On Sun, 2 Apr 2023 at 09:28, Mark Kettenis wrote: > > > > > From: Simon Glass > > > 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
Hi Mark, On Sun, 2 Apr 2023 at 09:28, Mark Kettenis wrote: > > > From: Simon Glass > > 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
> From: Simon Glass > 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
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
[PATCH v2 0/1] meson: Demonstration of using binman to produce the image
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