Hi Simon, On Thu, 25 Nov 2021 at 17:49, Simon Glass <s...@chromium.org> wrote:
> Hi François, > > On Thu, 25 Nov 2021 at 08:11, François Ozog <francois.o...@linaro.org> > wrote: > > > > Hi Simon, > > > > > > > > > > On Thu, 25 Nov 2021 at 15:47, Ilias Apalodimas < > ilias.apalodi...@linaro.org> wrote: > >> > >> +cc Sandrine > >> > >> On Thu, 25 Nov 2021 at 11:42, Ilias Apalodimas > >> <ilias.apalodi...@linaro.org> wrote: > >> > > >> > Hi Simon, > >> > > >> > > >> > On Wed, 24 Nov 2021 at 06:09, Simon Glass <s...@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-...@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@Siemens has in the overall process? > Regards, > Simon > -- François-Frédéric Ozog | *Director Business Development* T: +33.67221.6485 francois.o...@linaro.org | Skype: ffozog
