[PATCH 0/2] binman: Add support for ATF Firmware Image Package (FIP)

[François Ozog]

Hi Simon,

On Thu, 25 Nov 2021 at 17:49, Simon Glass <sjg at chromium.org> wrote:

> Hi François,
>
> On Thu, 25 Nov 2021 at 08:11, François Ozog <francois.ozog at linaro.org>
> wrote:
> >
> > Hi Simon,
> >
> >
> >
> >
> > On Thu, 25 Nov 2021 at 15:47, Ilias Apalodimas <
> ilias.apalodimas at linaro.org> wrote:
> >>
> >> +cc Sandrine
> >>
> >> On Thu, 25 Nov 2021 at 11:42, Ilias Apalodimas
> >> <ilias.apalodimas at linaro.org> wrote:
> >> >
> >> > Hi Simon,
> >> >
> >> >
> >> > On Wed, 24 Nov 2021 at 06:09, Simon Glass <sjg at chromium.org> wrote:
> >> > >
> >> > >
> >> > > This series adds support for the FIP format as used by ARM Trusted
> >> > > Firmware (in particular TF-A).
> >> > >
> >
> > I will use a question you use often "what problem are you trying to
> solve?". If FIP format is used it means that TF-A/BL2 is going to parse it
> and verify the hashes/signatures according to TF-A scheme.
> >
> > The packager will embed in a FIP components like Secure Monitor, Secure
> hypervisor, Secure partitions code and manifests.
> >
> > All in all, U-Boot will be representing a small percentage of the
> functionality offered by secure firmware  as a whole and it feels odd to
> make another implementation that is more "accessory" rather than critical
> for the U-Boot community. It may be a good idea but I wish you could
> explain it.
>
> Here is a talk about Binman, its goals and how it works.
>
> https://www.youtube.com/watch?v=L84ujgUXBOQ
>
> Think of Binman as a separate tool that brings everything together. It
> has grown out of U-Boot, largely because U-Boot is the main firmware
> in most cases. Getting U-Boot to start up and boot successfully is the
> goal of this packaging process. There are lots of instructions in the
> tree and elsewhere about how to build an image comprising U-Boot and
> various binary blobs. Binman aims to provide documentation for that
> process and an image description that can be used to build an image
> reliably.
>
> We are slowly converting these text instructions into an in-tree image
> description.
>
> I believe that Binman can help bring order to the chaos that is
> otherwise only going to grow, with lots of shell scripts, manual
> instructions, obscure binary tools, etc. Binman brings everything
> together and makes it clear what is needing/missing to build an image.
>
> >
> >> > > This allows images to be created containing a FIP, which itself
> contains
> >> > > various binaries. With this, image creation can be handled from an
> in-tree
> >> > > image description instead of needing to perform a lot of manual
> steps or
> >> > > custom scripts to build the FIP.
> >> > >
> >
> > That's not my experience of building a fip.  Packaging even Linux as a
> BL33 (instead of U-Boot) is very simple.
>
> But not automatic. With Binman you don't need to worry about the
> packaging. It is done for you. You just need to find all the binary
> blobs that are needed.  This ability is quite important as firmware is
> fragmenting and getting very complicated these days.
>
> Binman runs twice...once in the U-Boot tree to do a build and again
> later to repackage, put in a final fdtmap, add signatures and any
> final pieces needed.
>
> See this patch for an example of complicated build instructions with
> Odroid-C2 (>10 binary blobs!) and how Binman can help (see the changes
> in the .rst file):
>
>
> https://patchwork.ozlabs.org/project/uboot/patch/20211124040954.699821-8-sjg@chromium.org/
>
> That's indeed complicated! I can't comment whether this build process is
"canonical" as per TF-A standards so I'll let TF-A community comment.
Have you factored in the signature issues that Jan at Siemens has in the
overall process?


> Regards,
> Simon
>


-- 
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog at linaro.org | Skype: ffozog