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/ Regards, Simon