On Thu, 20 Jun 2024 at 23:22, Quentin Schulz <quentin.sch...@cherry.de> wrote: > > Hi Nishanth Menon, > > +Cc Kever from Rockchip as maintainer of the arch in U-Boot > +Cc Heiko as maintainer of many things Rockchip in many projects > > On 6/20/24 11:35 PM, 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) > > FYI, on Rockchip, there are currently three blobs **we** use on Aarch64 > (i have only worked with RK3399, PX30 and RK3588, so they may be more :) ): > - DDR bin/TPL no clue what this actually is under the hood. I think > most SoCs do not get an open-source DDR init in U-Boot sadly, therefore > mandatory until it isn't, > - BL31, mandatory on Aarch64, a blob that is an old TF-A (v2.2/2.3 I > don't remember anymore). I don't know the state for all SoCs, but I can > say the RK3399, PX30 and RK3568 have an open one, RK3588 is one the way > (but considering the RK3568 and RK3588 were released years ago, BL31 > blob is mandatory for a while),
rk3568 is now upstream, there was a PR upstream for this for some time, similar to rk3588, albeit not as long as rk56x. In some cases the issue here is the speed of review of upstream ATF. I don't think that means it should go into something like this. > - BL32, OP-TEE. I don't think we support it upstream for Aarch64 (I > think there was some issue around the binary format being different than > the upstream OP-TEE?). Don't know the state for Aarch32 SoCs though. These are generally optional, at least for rockchip > - I vaguely remember something about a miniloader but have no clue > what is its use as I've never had to use it, mentioning it anyway. I rarely use this, it's generally needed for maskrom and recovery of devices. I don't think they need to go into this sort of repo as they're generally not needed for core booting of the rockchips devices. > So, BL31 and BL32 are blobs but based on open-source projects with > "weak" licensing requirements. This means "Limit binaries only to those > that do not have an opensource project" is maybe not the correct wording > (or it is and then we can only have the DDR bin there, which isn't > necessarily a win since we would have to fetch the binaries from some > other places as well). > > FYI, the DDR bin is printing stuff on the console, so we had to modify > it (with a tool from Rockchip) to remove the gibberish breaking the > terminal by setting the appropriate controller, mux and baudrate (for > our products, there's no one size fits all :) ). The question is how to > handle this since we cannot realistically store every possible > permutation of that binary for each UART controller, mux of UART > controller and baudrate (the only parameters **we** modify, but there > are tons of others). I think those sort of things should be mostly quiet TBH.
