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
signature.asc
Description: PGP signature
