Hi Nishanth, On Thu, 20 Jun 2024 at 15:35, Nishanth Menon <n...@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
