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

[Tom Rini]

On Tue, Jul 16, 2024 at 09:35:18PM +0200, Heinrich Schuchardt wrote:
> On 7/16/24 21:13, Tom Rini wrote:
> > On Thu, Jun 20, 2024 at 04:35:39PM -0500, 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)
> > > * 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 believe that fundamentally, this is a problem that exists beyond both
> > just "U-Boot needs some binaries" and "TI has some binaries that
> > bootloaders need". So a generic solution is appropriate, and some sort
> > of community-based hosting of these needs (with appropriate licensing
> > from the IP owners) makes sense. Looking around at the binaries I have
> > to keep locally to use NXP platforms, and TI platforms and Rockchip
> > platforms, it's far from ideal. Having one place to get them all from
> > would make life easier for a lot of developers and also frankly for a
> > lot of end customers of these chips.
> > 
> 
> Some thought needs to be given to the license implications of these binaries
> for operating system distributions.
> 
> A distro providing a combined binary consisting of U-Boot and closed source
> firmware might be interpreted as conflicting with U-Boot's GPL license.
> 
> Distributing the closed source binaries and U-Boot in separate packages
> according to their respective licenses and only assemble them on the target
> device via a post-installation script might be allowable.

For this project the question is making sure that the binaries are
licensed such that they could be externally redistributable.

I don't know why someone would suggest that ABI calls are suddenly
linkage as I thought that (as far as these matters go) that was already
settled, but I am not a lawyer.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20240716/a31edac9/attachment.sig>