On 7/16/24 22:01, Tom Rini wrote:
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.
The relevant term in the GPL 2.0 license is "work based on the Program".
According to the GPL a "work based on the Program" is "a work containing
the Program or a portion of it".
If you build a binary via binman that contains U-Boot and another
binary, the resulting binary could be considered "a work containing the
Program or a portion of it".
The GPL 2.0 requires:
"But when you distribute the same sections as part of a whole which is a
work based on the Program, the distribution of the whole must be on the
terms of this License, whose permissions for other licensees extend to
the entire whole, and thus to each and every part regardless of who
wrote it."
Best regards
Heinrich
