[PATCH v3 00/19] Migration to using binman for bootloader

[Christian Gmeiner]

Hi

>
> On 04/05/23 14:08, Christian Gmeiner wrote:
> > Hi
> >
> >>
> >> This series aims to eliminate the use of additional custom repositories
> >> such as k3-image-gen (K3 Image Generation) repo and core-secdev-k3 (K3
> >> Security Development Tools) that was plumbed into the U-Boot build flow
> >> to generate boot images for TI K3 platform devices. And instead, we move
> >> towards using binman that aligns better with the community standard build
> >> flow.
> >>
> >> This series uses binman for all K3 platforms supported on U-Boot currently;
> >> both HS (High Security, both SE and FS) and GP (General Purpose) devices.
> >>
> >> Background on using k3-image-gen:
> >>          * TI K3 devices require a SYSFW (System Firmware) image consisting
> >>          of a signed system firmware image and board configuration binaries,
> >>          this is needed to bring up system firmware during U-Boot R5 SPL
> >>          startup.
> >>          * Board configuration data contain board-specific information
> >>          such as resource management, power management and security.
> >>
> >> Background on using core-secdev-k3:
> >>          * Contains resources to sign x509 certificates for HS devices
> >>
> >> Series intends to use binman to take over the packaging and signing for
> >> the R5 bootloader images tiboot3.bin (and sysfw.itb, for non-combined
> >> boot flow) instead of k3-image-gen.
> >>
> >> Series also packages the A72/A53 bootloader images (tispl.bin and
> >> u-boot.img) using ATF, OPTEE and DM (Device Manager)
> >
> > This simplifies building U-Boot with sysfw alot - thanks for your
> > work! I have tested this series on
> > an am642 based design. One thing is missing for my HSM use case. I
> > want to build an unsigned
> > Image and need to sign it with binman in the context of the HSM.
> > Therefore we need repacking
> > support. Are you working on that too?
> >
>
> So the idea of signing using binman in the HSM flow was discussed
> earlier [1] and the final call was to leave the boot artifacts that
> could be re-signed. So repacking support is not part of this series
> right now, you can use the tools mentioned in the thread [1] to do that
> for simple enough FIT images. However complex images like tiboot3.bin
> and tispl.bin might be a future action. I am not completely sure of the
> HSM flow though, pinging Andrew to comment further on this.
>
> [1] https://lore.kernel.org/all/0b2a8709-eb49-b866-5733-21bee021dbfe@ti.com/

Okay.. I will spend some days next week getting the U-Boot signed. With your
patch series it should be easy to use 'developer' key material to do
everything locally.
For the HSM case I think I need to play with the secdev scripts.

Will keep you updated.

greets
--
Christian Gmeiner, MSc

https://christian-gmeiner.info/privacypolicy