On June 21, 2024 thus sayeth Simon Glass:
Hi Peter,
On Fri, 21 Jun 2024 at 01:35, Peter Robinson pbrobinson@gmail.com wrote:
On Fri, 21 Jun 2024 at 00:05, Simon Glass sjg@chromium.org wrote:
Hi Nishanth,
On Thu, 20 Jun 2024 at 15:35, Nishanth Menon nm@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.
- 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:
- 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:
- 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.
This is a solving a different problem IMO. Also most distros build in constrained environments so pulling FW randomly with a tool in the build process won't work. Also most users won't want to pull the latest each time they build, most vendors will choose a static set of versions and only bump to deal with bugs, CVEs or explicit features they need rather than having a series of moving targets.
Yes of course. This is actually how 'binman tool' works - unless you explicitly fetch something it uses what you have. I am certainly not suggesting that binman fetch things as part of the build itself, but that it provide a way to programmatically obtain the required bobs, e.g. fetching from a defined (or public) repo or building from source. We would need to support different versions of the same file, dealing with files which are common across SoCs, etc.
Well the whole point of the repo is to remove the guesswork, it would be a set of firmware that is expected to work in a single location.
I don't believe a repo is sufficient. The instructions for building images are becoming complex enough that it is a non-trivial job for anyone to work through the steps and figure out what to do. If you are deeply into a particular SoC it is worth the effort, I suppose. But I favour a comprehensive image description (as provided by Binman) and a programmatic method.
I'm not sure of the best way to 'uprev' blobs, but wherever they are stored, I suppose the image description would be changed to select the new version.
IMO the actual repo is not the ultimate goal here. Building and testing should be the ultimate goal.
I disagree, the repo would assist working and tested firmware because there could be a review/test process as part of it to ensure things work and are tested to give users a good experience rather than having to search the web and forum posts to attempt to find pieces that work together.
I believe we are saying the same thing here, albeit that I feel a repo is not enough.
So long as we can keep the 'binman blob' a separate step. I agree that we can do much better than a signed git repo and we should at the very least try this out before we go down the linux-firmware route. But many build systems (like buildroot) have different download, build, and install phases and people get upset when we mix them (python, rust)
~Bryan
Regards, Simon
[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... [5] https://git.ti.com/cgit/processor-firmware/ti-linux-firmware/tree/ti-dm?h=ti... [6] https://docs.kernel.org/next/driver-api/firmware/firmware-usage-guidelines.h... -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D