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

Simon Glass sjg at chromium.org
Tue Apr 18 18:49:54 PDT 2023


Hi Da,

On Fri, 7 Apr 2023 at 21:34, Da Xue <da at lessconfused.com> wrote:
>
> On Wed, Apr 5, 2023 at 2:39 PM Simon Glass <sjg at chromium.org> wrote:
> >
> > Hi Christian,
> >
> > On Mon, 3 Apr 2023 at 20:10, Christian Hewitt
> > <christianshewitt at gmail.com> wrote:
> > >
> > > > On 2 Apr 2023, at 6:41 am, Simon Glass <sjg at chromium.org> wrote:
> > > >
> > > > Hi Mark,
> > > >
> > > > On Sun, 2 Apr 2023 at 09:28, Mark Kettenis <mark.kettenis at xs4all.nl> wrote:
> > > > >
> > > > > > From: Simon Glass <sjg at 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



More information about the linux-amlogic mailing list