Request for hosting a boot-firmware repository in u-boot git (denx and GitHub)

[Simon Glass]

Hi Nishanth,

On Thu, 20 Jun 2024 at 15:35, Nishanth Menon <nm at ti.com> wrote:
>
> Hi Team,
>
> We have briefly discussed this topic on IRC[1]. I would like to
> propose a new boot-firmware repository similar to the Linux-firmware
> repository under the aegis of u-boot hosting.
>
> In addition to TI, it looks like some NXP[2] and Rockchip[3]
> platforms seem to require additional closed-source/open-source
> binaries to have a complete bootable image. Distribution rights and
> locations of these binaries are challenging, and there needs to be a
> standard for how and where they are hosted for end users.
>
> Further, looking ahead to future architectures:
> * IP firmware: More and more IP vendors are embedding their own
>   "specialized controllers" and require firmware for the operation
>   (similar to Rockchip's DDR controller, I guess),
> * boot stage firmware: Additional stages of the boot process involve
>   vendor intermediate firmware, such as power configuration.
> * Security enclave binaries: While I see a few folks trying to have an
>   open-source s/w architecture, many PKA and PQC systems still require
>   prop binaries for IP reasons.
>
> NOTE: I am not judging any company(including TI) for reasons why some
> firmware is proprietary, but I hate to have the end users and other
> system (distro) maintainers have to deal with hell trying to make the
> life of end users easy to live with.
>
> In the case of TI's K3 architecture devices, we have two binary blobs
> that are critical for the boot process.
>
> 1. TIFS Firmware / DMSC firmware[4]—This is the security enclave
>   firmware. It is often encrypted, and sources are not public (due to
>   various business/regulatory reasons).
> 2. DM Firmware[5] - There is a source in public in some cases and
>   binary only in others - essentially limited function binary to be
>   put up in the device management uC. In cases where the source is
>   available, the build procedure is, in my personal opinion, pretty
>   arcane, and even though in theory it is practical, in practice, not
>   friendly - efforts are going to simplify it, even probably integrate
>   it with a more opensource ecosystem, but that is talking "look at the
>   tea leaves" stuff.
> 3. Low Power Management (LPM) binaries: tifs stub: another encrypted
>   binary that gives the tifs system context restore logic before
>   retrieving tifs firmware and a corresponding DM restoration binary.
>
> All told, this is not unlike the situation that necessitated the
> creation of a Linux firmware repository.
>
> Options that I see:
>
> 1. Let the status quo be - SoC vendors maintain random locations and
>   random rules to maintain boot firmware.
> 2. Ask Linux-firmware to host the binaries in a single canonical
>   location
> 3. Host a boot-firmware repository - u-boot repo may be the more
>   logical location.
>
> * (1) isn't the correct answer.
>
> * (2) Though I haven't seen any policy from the Linux-firmware
>   community mandating anything of the form, the binaries we are talking
>   of may not belong to Linux-firmware as they aren't strictly speaking
>   something Linux kernel will load (since the bootloader has that
>   responsibility), and in some cases may not even directly talk to
>   (security enclave or DDR firmware stuff). I am adding Josh to this
>   mail to see if he has any opinions on the topic (but keeping
>   from cross posting on linux-firmware list, unless folks feel it is
>   OK).
>
> On (3):
> Proposal:
>
> * Create a boot firmware repository in Denx and/or GitHub (if
>   financials are a hurdle, I hope we can solve it as a community).
> * Limit binaries only to those consumed part of the u-boot scope.
>
> * Limit binaries only to those that do not have an opensource project
>   (Trusted Firmware-A/M, OP-TEE, etc..) or depend entirely on vendor
>   source or are binary only in nature (subject to licensing terms below)
> * Limit binaries to some pre-established size to prevent repository
>   explosion - say, 512Kib?
> * Follow the same rules of integration and licensing guidelines as
>   Linux-firmware[6].
> * Similar rules as Linux-firmware guidelines of ABI backward and
>   forward compatibility.
> * Set a workflow update flow and a compatibility requirements document
>
> If we agree to have boot firmware under the stewardship of u-boot, we
> should also set other rules, which is excellent to discuss.
>
> Thoughts?

I suggest:

4) Add a 'binman blob' subcommand which can fetch blobs, similarly to
how 'binman tool -f xxx' features a tool, using the image description
to know what is needed and some configuration for where to find it /
how to build it.

That way we can actually build working images and test them, without
user intervention / guesswork.

IMO the actual repo is not the ultimate goal here. Building and
testing should be the ultimate goal.

>
> [1] https://libera.irclog.whitequark.org/u-boot/2024-06-13#36498796;
> [2] https://docs.nxp.com/bundle/AN14093/page/topics/build_the_u-boot.html
> [3] https://bbs.t-firefly.com/forum.php?mod=viewthread&tid=2236
> [4] https://git.ti.com/cgit/processor-firmware/ti-linux-firmware/tree/ti-sysfw?h=ti-linux-firmware
> [5] https://git.ti.com/cgit/processor-firmware/ti-linux-firmware/tree/ti-dm?h=ti-linux-firmware
> [6] https://docs.kernel.org/next/driver-api/firmware/firmware-usage-guidelines.html
> --
> Regards,
> Nishanth Menon
> Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D

Regards,
SImon