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

[Simon Glass]

Hi François,

On Sat, 4 Dec 2021 at 05:35, François Ozog  wrote:
>
> Hi Simon and Sandrine
>
> Le jeu. 2 déc. 2021 à 08:10, Sandrine Bailleux  a 
> écrit :
>>
>> Hi Simon,
>>
>> On 12/1/21 5:51 PM, Simon Glass wrote:
>> > Hi Sandrine,
>> >
>> > On Wed, 1 Dec 2021 at 03:32, Sandrine Bailleux
>> >  wrote:
>> >>
>> >> Hi everyone,
>> >>
>> >> I am Sandrine Bailleux, from the Trusted Firmware-A project. Ilias
>> >> Apalodimas CC'ed me on this thread.
>> >>
>> >> First of all, thanks for involving the TF-A developers in this thread
>> >> and my apologies for the delay in responding.
>> >
>> > Thank you for your response.
>> >
>> >>
>> >> On 11/25/21 6:01 PM, François Ozog wrote:
>> >>> Hi Simon,
>> >>>
>> >>> On Thu, 25 Nov 2021 at 17:49, Simon Glass > >>> > wrote:
>> >>>
>> >>> Hi François,
>> >>>
>> >>> On Thu, 25 Nov 2021 at 08:11, François Ozog
>> >>> mailto:francois.o...@linaro.org>> wrote:
>> >>> >
>> >>> > Hi Simon,
>> >>> >
>> >>> >
>> >>> >
>> >>> >
>> >>> > On Thu, 25 Nov 2021 at 15:47, Ilias Apalodimas
>> >>> mailto:ilias.apalodi...@linaro.org>>
>> >>> wrote:
>> >>> >>
>> >>> >> +cc Sandrine
>> >>> >>
>> >>> >> On Thu, 25 Nov 2021 at 11:42, Ilias Apalodimas
>> >>> >> > >>> > wrote:
>> >>> >> >
>> >>> >> > Hi Simon,
>> >>> >> >
>> >>> >> >
>> >>> >> > On Wed, 24 Nov 2021 at 06:09, Simon Glass > >>> > 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):
>> >>>
>> >>> 
>> >>> 

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

[François Ozog]

Hi Simon and Sandrine

Le jeu. 2 déc. 2021 à 08:10, Sandrine Bailleux 
a écrit :

> Hi Simon,
>
> On 12/1/21 5:51 PM, Simon Glass wrote:
> > Hi Sandrine,
> >
> > On Wed, 1 Dec 2021 at 03:32, Sandrine Bailleux
> >  wrote:
> >>
> >> Hi everyone,
> >>
> >> I am Sandrine Bailleux, from the Trusted Firmware-A project. Ilias
> >> Apalodimas CC'ed me on this thread.
> >>
> >> First of all, thanks for involving the TF-A developers in this thread
> >> and my apologies for the delay in responding.
> >
> > Thank you for your response.
> >
> >>
> >> On 11/25/21 6:01 PM, François Ozog wrote:
> >>> Hi Simon,
> >>>
> >>> On Thu, 25 Nov 2021 at 17:49, Simon Glass  >>> > wrote:
> >>>
> >>> Hi François,
> >>>
> >>> On Thu, 25 Nov 2021 at 08:11, François Ozog
> >>> mailto:francois.o...@linaro.org>>
> wrote:
> >>> >
> >>> > Hi Simon,
> >>> >
> >>> >
> >>> >
> >>> >
> >>> > On Thu, 25 Nov 2021 at 15:47, Ilias Apalodimas
> >>> mailto:ilias.apalodi...@linaro.org>>
> >>> wrote:
> >>> >>
> >>> >> +cc Sandrine
> >>> >>
> >>> >> On Thu, 25 Nov 2021 at 11:42, Ilias Apalodimas
> >>> >>  >>> > wrote:
> >>> >> >
> >>> >> > Hi Simon,
> >>> >> >
> >>> >> >
> >>> >> > On Wed, 24 Nov 2021 at 06:09, Simon Glass  >>> > 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.
> 

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

[Sandrine Bailleux]

Hi Simon,

On 12/1/21 5:51 PM, Simon Glass wrote:
> Hi Sandrine,
>
> On Wed, 1 Dec 2021 at 03:32, Sandrine Bailleux
>  wrote:
>>
>> Hi everyone,
>>
>> I am Sandrine Bailleux, from the Trusted Firmware-A project. Ilias
>> Apalodimas CC'ed me on this thread.
>>
>> First of all, thanks for involving the TF-A developers in this thread
>> and my apologies for the delay in responding.
>
> Thank you for your response.
>
>>
>> On 11/25/21 6:01 PM, François Ozog wrote:
>>> Hi Simon,
>>>
>>> On Thu, 25 Nov 2021 at 17:49, Simon Glass >> > wrote:
>>>
>>> Hi François,
>>>
>>> On Thu, 25 Nov 2021 at 08:11, François Ozog
>>> mailto:francois.o...@linaro.org>> wrote:
>>> >
>>> > Hi Simon,
>>> >
>>> >
>>> >
>>> >
>>> > On Thu, 25 Nov 2021 at 15:47, Ilias Apalodimas
>>> mailto:ilias.apalodi...@linaro.org>>
>>> wrote:
>>> >>
>>> >> +cc Sandrine
>>> >>
>>> >> On Thu, 25 Nov 2021 at 11:42, Ilias Apalodimas
>>> >> >> > wrote:
>>> >> >
>>> >> > Hi Simon,
>>> >> >
>>> >> >
>>> >> > On Wed, 24 Nov 2021 at 06:09, Simon Glass >> > 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?
>>
>> I am a bit confused by the ask here. What input would you like from TF-A
>> community? Are you asking for a code review or are you more interested
>> in getting an opinion about adding support for FIP files in binman?
>
> The latter.
>
>>
>> 

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

[Simon Glass]

Hi Sandrine,

On Wed, 1 Dec 2021 at 03:32, Sandrine Bailleux
 wrote:
>
> Hi everyone,
>
> I am Sandrine Bailleux, from the Trusted Firmware-A project. Ilias
> Apalodimas CC'ed me on this thread.
>
> First of all, thanks for involving the TF-A developers in this thread
> and my apologies for the delay in responding.

Thank you for your response.

>
> On 11/25/21 6:01 PM, François Ozog wrote:
> > Hi Simon,
> >
> > On Thu, 25 Nov 2021 at 17:49, Simon Glass  > > wrote:
> >
> > Hi François,
> >
> > On Thu, 25 Nov 2021 at 08:11, François Ozog
> > mailto:francois.o...@linaro.org>> wrote:
> > >
> > > Hi Simon,
> > >
> > >
> > >
> > >
> > > On Thu, 25 Nov 2021 at 15:47, Ilias Apalodimas
> > mailto:ilias.apalodi...@linaro.org>>
> > wrote:
> > >>
> > >> +cc Sandrine
> > >>
> > >> On Thu, 25 Nov 2021 at 11:42, Ilias Apalodimas
> > >>  > > wrote:
> > >> >
> > >> > Hi Simon,
> > >> >
> > >> >
> > >> > On Wed, 24 Nov 2021 at 06:09, Simon Glass  > > 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?
>
> I am a bit confused by the ask here. What input would you like from TF-A
> community? Are you asking for a code review or are you more interested
> in getting an opinion about adding support for FIP files in binman?

The latter.

>
> Regardless, I had a brief look at the patches and I have some early
> 

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

[Sandrine Bailleux]

Hi everyone,

I am Sandrine Bailleux, from the Trusted Firmware-A project. Ilias
Apalodimas CC'ed me on this thread.

First of all, thanks for involving the TF-A developers in this thread
and my apologies for the delay in responding.

On 11/25/21 6:01 PM, François Ozog wrote:
> Hi Simon,
>
> On Thu, 25 Nov 2021 at 17:49, Simon Glass  > wrote:
>
> Hi François,
>
> On Thu, 25 Nov 2021 at 08:11, François Ozog
> mailto:francois.o...@linaro.org>> wrote:
> >
> > Hi Simon,
> >
> >
> >
> >
> > On Thu, 25 Nov 2021 at 15:47, Ilias Apalodimas
> mailto:ilias.apalodi...@linaro.org>>
> wrote:
> >>
> >> +cc Sandrine
> >>
> >> On Thu, 25 Nov 2021 at 11:42, Ilias Apalodimas
> >>  > wrote:
> >> >
> >> > Hi Simon,
> >> >
> >> >
> >> > On Wed, 24 Nov 2021 at 06:09, Simon Glass  > 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?

I am a bit confused by the ask here. What input would you like from TF-A
community? Are you asking for a code review or are you more interested
in getting an opinion about adding support for FIP files in binman?

Regardless, I had a brief look at the patches and I have some early
questions/comments.

In the first patch, the commit message mentions that the tool parses the
TF-A source code to get a list of supported UUIDs. However,
tools/binman/fip_util.py seems to embed a hard-coded list of these
UUIDs. I think I might be missing something there... Does it just mean
that the said list was generated using some other script that parsed the

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

[Simon Glass]

Hi François,

On Thu, 25 Nov 2021 at 10:01, François Ozog  wrote:
>
> Hi Simon,
>
> On Thu, 25 Nov 2021 at 17:49, Simon Glass  wrote:
>>
>> Hi François,
>>
>> On Thu, 25 Nov 2021 at 08:11, François Ozog  wrote:
>> >
>> > Hi Simon,
>> >
>> >
>> >
>> >
>> > On Thu, 25 Nov 2021 at 15:47, Ilias Apalodimas 
>> >  wrote:
>> >>
>> >> +cc Sandrine
>> >>
>> >> On Thu, 25 Nov 2021 at 11:42, Ilias Apalodimas
>> >>  wrote:
>> >> >
>> >> > Hi Simon,
>> >> >
>> >> >
>> >> > On Wed, 24 Nov 2021 at 06:09, Simon Glass  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?

In Chrome OS we package up the material that needs to be signed and
send it to a signing server, then get back a key.

You can use 'binman extract' to get the signing data, although perhaps
we could add a special option for it.

You can use 'binman replace' to add the signature in when you get it
back. Again we could create a special path for this if needed.

Regards,
Simon

Re: [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  wrote:

> Hi François,
>
> On Thu, 25 Nov 2021 at 08:11, François Ozog 
> 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
> >>  wrote:
> >> >
> >> > Hi Simon,
> >> >
> >> >
> >> > On Wed, 24 Nov 2021 at 06:09, Simon Glass  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

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

[Simon Glass]

Hi François,

On Thu, 25 Nov 2021 at 08:11, François Ozog  wrote:
>
> Hi Simon,
>
>
>
>
> On Thu, 25 Nov 2021 at 15:47, Ilias Apalodimas  
> wrote:
>>
>> +cc Sandrine
>>
>> On Thu, 25 Nov 2021 at 11:42, Ilias Apalodimas
>>  wrote:
>> >
>> > Hi Simon,
>> >
>> >
>> > On Wed, 24 Nov 2021 at 06:09, Simon Glass  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

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

[François Ozog]

Hi Simon,




On Thu, 25 Nov 2021 at 15:47, Ilias Apalodimas 
wrote:

> +cc Sandrine
>
> On Thu, 25 Nov 2021 at 11:42, Ilias Apalodimas
>  wrote:
> >
> > Hi Simon,
> >
> >
> > On Wed, 24 Nov 2021 at 06:09, Simon Glass  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.

> > 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.

> > >
> > > Simon Glass (2):
> > >   binman: Add a utility module for ATF FIP
> > >   binman: Add support for ATF FIP
> > >
> > >  scripts/pylint.base  |   9 +-
> > >  tools/binman/entries.rst | 154 ++
> > >  tools/binman/etype/atf_fip.py| 273 ++
> > >  tools/binman/fip_util.py | 653 +++
> > >  tools/binman/fip_util_test.py| 405 ++
> > >  tools/binman/ftest.py| 217 
> > >  tools/binman/main.py |   4 +-
> > >  tools/binman/test/203_fip.dts|  21 +
> > >  tools/binman/test/204_fip_other.dts  |  22 +
> > >  tools/binman/test/205_fip_no_type.dts|  15 +
> > >  tools/binman/test/206_fip_uuid.dts   |  22 +
> > >  tools/binman/test/207_fip_ls.dts |  25 +
> > >  tools/binman/test/208_fip_replace.dts|  33 ++
> > >  tools/binman/test/209_fip_missing.dts|  19 +
> > >  tools/binman/test/210_fip_size.dts   |  19 +
> > >  tools/binman/test/211_fip_bad_align.dts  |  18 +
> > >  tools/binman/test/212_fip_collection.dts |  24 +
> > >  17 files changed, 1929 insertions(+), 4 deletions(-)
> > >  create mode 100644 tools/binman/etype/atf_fip.py
> > >  create mode 100755 tools/binman/fip_util.py
> > >  create mode 100755 tools/binman/fip_util_test.py
> > >  create mode 100644 tools/binman/test/203_fip.dts
> > >  create mode 100644 tools/binman/test/204_fip_other.dts
> > >  create mode 100644 tools/binman/test/205_fip_no_type.dts
> > >  create mode 100644 tools/binman/test/206_fip_uuid.dts
> > >  create mode 100644 tools/binman/test/207_fip_ls.dts
> > >  create mode 100644 tools/binman/test/208_fip_replace.dts
> > >  create mode 100644 tools/binman/test/209_fip_missing.dts
> > >  create mode 100644 tools/binman/test/210_fip_size.dts
> > >  create mode 100644 tools/binman/test/211_fip_bad_align.dts
> > >  create mode 100644 tools/binman/test/212_fip_collection.dts
> > >
> > > --
> > > 2.34.0.rc2.393.gf8c9666880-goog
> > >
> >
> > My python is mediocre at best.  I'll try having a look, but CC'ing
> > TF-A developers would be a good idea.
> >
> > Thanks
> > /Ilias
>


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

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

[Ilias Apalodimas]

+cc Sandrine

On Thu, 25 Nov 2021 at 11:42, Ilias Apalodimas
 wrote:
>
> Hi Simon,
>
>
> On Wed, 24 Nov 2021 at 06:09, Simon Glass  wrote:
> >
> >
> > This series adds support for the FIP format as used by ARM Trusted
> > Firmware (in particular TF-A).
> >
> > 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.
> >
> >
> > Simon Glass (2):
> >   binman: Add a utility module for ATF FIP
> >   binman: Add support for ATF FIP
> >
> >  scripts/pylint.base  |   9 +-
> >  tools/binman/entries.rst | 154 ++
> >  tools/binman/etype/atf_fip.py| 273 ++
> >  tools/binman/fip_util.py | 653 +++
> >  tools/binman/fip_util_test.py| 405 ++
> >  tools/binman/ftest.py| 217 
> >  tools/binman/main.py |   4 +-
> >  tools/binman/test/203_fip.dts|  21 +
> >  tools/binman/test/204_fip_other.dts  |  22 +
> >  tools/binman/test/205_fip_no_type.dts|  15 +
> >  tools/binman/test/206_fip_uuid.dts   |  22 +
> >  tools/binman/test/207_fip_ls.dts |  25 +
> >  tools/binman/test/208_fip_replace.dts|  33 ++
> >  tools/binman/test/209_fip_missing.dts|  19 +
> >  tools/binman/test/210_fip_size.dts   |  19 +
> >  tools/binman/test/211_fip_bad_align.dts  |  18 +
> >  tools/binman/test/212_fip_collection.dts |  24 +
> >  17 files changed, 1929 insertions(+), 4 deletions(-)
> >  create mode 100644 tools/binman/etype/atf_fip.py
> >  create mode 100755 tools/binman/fip_util.py
> >  create mode 100755 tools/binman/fip_util_test.py
> >  create mode 100644 tools/binman/test/203_fip.dts
> >  create mode 100644 tools/binman/test/204_fip_other.dts
> >  create mode 100644 tools/binman/test/205_fip_no_type.dts
> >  create mode 100644 tools/binman/test/206_fip_uuid.dts
> >  create mode 100644 tools/binman/test/207_fip_ls.dts
> >  create mode 100644 tools/binman/test/208_fip_replace.dts
> >  create mode 100644 tools/binman/test/209_fip_missing.dts
> >  create mode 100644 tools/binman/test/210_fip_size.dts
> >  create mode 100644 tools/binman/test/211_fip_bad_align.dts
> >  create mode 100644 tools/binman/test/212_fip_collection.dts
> >
> > --
> > 2.34.0.rc2.393.gf8c9666880-goog
> >
>
> My python is mediocre at best.  I'll try having a look, but CC'ing
> TF-A developers would be a good idea.
>
> Thanks
> /Ilias

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

[Ilias Apalodimas]

Hi Simon,


On Wed, 24 Nov 2021 at 06:09, Simon Glass  wrote:
>
>
> This series adds support for the FIP format as used by ARM Trusted
> Firmware (in particular TF-A).
>
> 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.
>
>
> Simon Glass (2):
>   binman: Add a utility module for ATF FIP
>   binman: Add support for ATF FIP
>
>  scripts/pylint.base  |   9 +-
>  tools/binman/entries.rst | 154 ++
>  tools/binman/etype/atf_fip.py| 273 ++
>  tools/binman/fip_util.py | 653 +++
>  tools/binman/fip_util_test.py| 405 ++
>  tools/binman/ftest.py| 217 
>  tools/binman/main.py |   4 +-
>  tools/binman/test/203_fip.dts|  21 +
>  tools/binman/test/204_fip_other.dts  |  22 +
>  tools/binman/test/205_fip_no_type.dts|  15 +
>  tools/binman/test/206_fip_uuid.dts   |  22 +
>  tools/binman/test/207_fip_ls.dts |  25 +
>  tools/binman/test/208_fip_replace.dts|  33 ++
>  tools/binman/test/209_fip_missing.dts|  19 +
>  tools/binman/test/210_fip_size.dts   |  19 +
>  tools/binman/test/211_fip_bad_align.dts  |  18 +
>  tools/binman/test/212_fip_collection.dts |  24 +
>  17 files changed, 1929 insertions(+), 4 deletions(-)
>  create mode 100644 tools/binman/etype/atf_fip.py
>  create mode 100755 tools/binman/fip_util.py
>  create mode 100755 tools/binman/fip_util_test.py
>  create mode 100644 tools/binman/test/203_fip.dts
>  create mode 100644 tools/binman/test/204_fip_other.dts
>  create mode 100644 tools/binman/test/205_fip_no_type.dts
>  create mode 100644 tools/binman/test/206_fip_uuid.dts
>  create mode 100644 tools/binman/test/207_fip_ls.dts
>  create mode 100644 tools/binman/test/208_fip_replace.dts
>  create mode 100644 tools/binman/test/209_fip_missing.dts
>  create mode 100644 tools/binman/test/210_fip_size.dts
>  create mode 100644 tools/binman/test/211_fip_bad_align.dts
>  create mode 100644 tools/binman/test/212_fip_collection.dts
>
> --
> 2.34.0.rc2.393.gf8c9666880-goog
>

My python is mediocre at best.  I'll try having a look, but CC'ing
TF-A developers would be a good idea.

Thanks
/Ilias

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

[Simon Glass]

This series adds support for the FIP format as used by ARM Trusted
Firmware (in particular TF-A).

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.


Simon Glass (2):
  binman: Add a utility module for ATF FIP
  binman: Add support for ATF FIP

 scripts/pylint.base  |   9 +-
 tools/binman/entries.rst | 154 ++
 tools/binman/etype/atf_fip.py| 273 ++
 tools/binman/fip_util.py | 653 +++
 tools/binman/fip_util_test.py| 405 ++
 tools/binman/ftest.py| 217 
 tools/binman/main.py |   4 +-
 tools/binman/test/203_fip.dts|  21 +
 tools/binman/test/204_fip_other.dts  |  22 +
 tools/binman/test/205_fip_no_type.dts|  15 +
 tools/binman/test/206_fip_uuid.dts   |  22 +
 tools/binman/test/207_fip_ls.dts |  25 +
 tools/binman/test/208_fip_replace.dts|  33 ++
 tools/binman/test/209_fip_missing.dts|  19 +
 tools/binman/test/210_fip_size.dts   |  19 +
 tools/binman/test/211_fip_bad_align.dts  |  18 +
 tools/binman/test/212_fip_collection.dts |  24 +
 17 files changed, 1929 insertions(+), 4 deletions(-)
 create mode 100644 tools/binman/etype/atf_fip.py
 create mode 100755 tools/binman/fip_util.py
 create mode 100755 tools/binman/fip_util_test.py
 create mode 100644 tools/binman/test/203_fip.dts
 create mode 100644 tools/binman/test/204_fip_other.dts
 create mode 100644 tools/binman/test/205_fip_no_type.dts
 create mode 100644 tools/binman/test/206_fip_uuid.dts
 create mode 100644 tools/binman/test/207_fip_ls.dts
 create mode 100644 tools/binman/test/208_fip_replace.dts
 create mode 100644 tools/binman/test/209_fip_missing.dts
 create mode 100644 tools/binman/test/210_fip_size.dts
 create mode 100644 tools/binman/test/211_fip_bad_align.dts
 create mode 100644 tools/binman/test/212_fip_collection.dts

-- 
2.34.0.rc2.393.gf8c9666880-goog