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

[Peter Robinson]

On Thu, 20 Jun 2024 at 23:22, Quentin Schulz <quentin.schulz at cherry.de> wrote:
>
> Hi Nishanth Menon,
>
> +Cc Kever from Rockchip as maintainer of the arch in U-Boot
> +Cc Heiko as maintainer of many things Rockchip in many projects
>
> On 6/20/24 11:35 PM, Nishanth Menon 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)
>
> FYI, on Rockchip, there are currently three blobs **we** use on Aarch64
> (i have only worked with RK3399, PX30 and RK3588, so they may be more :) ):
>   - DDR bin/TPL no clue what this actually is under the hood. I think
> most SoCs do not get an open-source DDR init in U-Boot sadly, therefore
> mandatory until it isn't,
>   - BL31, mandatory on Aarch64, a blob that is an old TF-A (v2.2/2.3 I
> don't remember anymore). I don't know the state for all SoCs, but I can
> say the RK3399, PX30 and RK3568 have an open one, RK3588 is one the way
> (but considering the RK3568 and RK3588 were released years ago, BL31
> blob is mandatory for a while),

rk3568 is now upstream, there was a PR upstream for this for some
time, similar to rk3588, albeit not as long as rk56x. In some cases
the issue here is the speed of review of upstream ATF. I don't think
that means it should go into something like this.

>   - BL32, OP-TEE. I don't think we support it upstream for Aarch64 (I
> think there was some issue around the binary format being different than
> the upstream OP-TEE?). Don't know the state for Aarch32 SoCs though.

These are generally optional, at least for rockchip

>   - I vaguely remember something about a miniloader but have no clue
> what is its use as I've never had to use it, mentioning it anyway.

I rarely use this, it's generally needed for maskrom and recovery of
devices. I don't think they need to go into this sort of repo as
they're generally not needed for core booting of the rockchips
devices.

> So, BL31 and BL32 are blobs but based on open-source projects with
> "weak" licensing requirements. This means "Limit binaries only to those
> that do not have an opensource project" is maybe not the correct wording
> (or it is and then we can only have the DDR bin there, which isn't
> necessarily a win since we would have to fetch the binaries from some
> other places as well).
>
> FYI, the DDR bin is printing stuff on the console, so we had to modify
> it (with a tool from Rockchip) to remove the gibberish breaking the
> terminal by setting the appropriate controller, mux and baudrate (for
> our products, there's no one size fits all :) ). The question is how to
> handle this since we cannot realistically store every possible
> permutation of that binary for each UART controller, mux of UART
> controller and baudrate (the only parameters **we** modify, but there
> are tons of others).

I think those sort of things should be mostly quiet TBH.