Request for hosting a boot-firmware repository in u-boot git (denx and GitHub)

Request for hosting a boot-firmware repository in u-boot git (denx and GitHub)

[Nishanth Menon]

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?

[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

Re: Request for hosting a boot-firmware repository in u-boot git (denx and GitHub)

[Peter Robinson]

Hi Nishanth,

Thanks for starting this conversation.

> 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.

Yes, it's been painful for some time, and often the distribution is
unclear because often the binaries are copies around between SBC
makers often without the other bits such as licenses etc so it's a
case of "who knows ¯\_(ツ)_/¯" even if it's the same for all devices of
a particular SoC.

Having a process around licensing and redistribution requirements is useful.

> 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

I don't believe this makes sense. linux-firmware is designed for
firmware that is loaded by linunx drivers, these are not, they're
generally used a part of early boot firmware prior to the linux kernel
even booting, and could in fact be any other OS. As it is
linux-firmware is 2Gb+ in size, as a maintainer of that package in
Fedora having to determine which of 1000s of firmware is used by linux
or something else or if we need to ship it is hard enough already
without throwing a whole raft of other FW into the mix. I think a
separate repo is the right way to go here please.

> 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

my understanding is the policy is that it's firmware required by linux drivers.

>   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?

Not sure that makes sense, if a FW is needed by a device to boot it
doesn't make sense to exclude it based on some arbitrary size

> * 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

* needs to come from the vendor (there's been issues with
linux-firmware where people try and post firmware that might not be
redistributable)
* need to be freely redistributable
* needs something similar to the liniux-firmware whence file etc.
* The new linux-firmware PR automation etc is quite good

> If we agree to have boot firmware under the stewardship of u-boot, we
> should also set other rules, which is excellent to discuss.

I think that's a good start, I think we should be open to expansion.

> Thoughts?
>
> [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

Re: Request for hosting a boot-firmware repository in u-boot git (denx and GitHub)

[Bryan Brattlof]

On June 20, 2024 thus sayeth Peter Robinson:
> Hi Nishanth,
> 
> Thanks for starting this conversation.
> 
> > 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.
> 
> Yes, it's been painful for some time, and often the distribution is
> unclear because often the binaries are copies around between SBC
> makers often without the other bits such as licenses etc so it's a
> case of "who knows ¯\_(ツ)_/¯" even if it's the same for all devices of
> a particular SoC.
> 
> Having a process around licensing and redistribution requirements is useful.
> 
> > 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
> 
> I don't believe this makes sense. linux-firmware is designed for
> firmware that is loaded by linunx drivers, these are not, they're
> generally used a part of early boot firmware prior to the linux kernel
> even booting, and could in fact be any other OS. As it is
> linux-firmware is 2Gb+ in size, as a maintainer of that package in
> Fedora having to determine which of 1000s of firmware is used by linux
> or something else or if we need to ship it is hard enough already
> without throwing a whole raft of other FW into the mix. I think a
> separate repo is the right way to go here please.
> 
>

Agree! While consolidating all of these binaries together under denx.de
or linux-firmware is needed, it doesn't make much sense to put this in a 
linux-firmware like repo. Unlike linux-firmware we don't need all of 
these binaries on the board (another side-effect of putting these u-boot 
binaries in linux-firmware), only the tiniest of subsets will be used
for a specific board build.

My hope was we could use some type of distribution mirroring system like 
most distributions use for their binaries today with some central 
routing for all the build machines consuming these blobs. This has the 
benefit of allowing vendors to help out with hosting and bandwidth if 
that's a problem and gives denx.de the ability to secure the software 
supply chain.

Using a system like this does add to the complexity of an already 
complex setup/build system for u-boot. But we can do much better than a 
signed git repo

~Bryan


> > 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
> 
> my understanding is the policy is that it's firmware required by linux drivers.
> 
> >   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?
> 
> Not sure that makes sense, if a FW is needed by a device to boot it
> doesn't make sense to exclude it based on some arbitrary size
> 
> > * 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
> 
> * needs to come from the vendor (there's been issues with
> linux-firmware where people try and post firmware that might not be
> redistributable)
> * need to be freely redistributable
> * needs something similar to the liniux-firmware whence file etc.
> * The new linux-firmware PR automation etc is quite good
> 
> > If we agree to have boot firmware under the stewardship of u-boot, we
> > should also set other rules, which is excellent to discuss.
> 
> I think that's a good start, I think we should be open to expansion.
> 
> > Thoughts?
> >
> > [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

Re: Request for hosting a boot-firmware repository in u-boot git (denx and GitHub)

[Quentin Schulz]

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),
  - 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.
  - 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.

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).

Cheers,
Quentin

Re: Request for hosting a boot-firmware repository in u-boot git (denx and GitHub)

[Peter Robinson]

On Thu, 20 Jun 2024 at 23:22, Quentin Schulz <quentin.schulz@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.

Re: Request for hosting a boot-firmware repository in u-boot git (denx and GitHub)

[Quentin Schulz]

Hi Peter,

On 6/21/24 12:29 AM, Peter Robinson wrote:
> On Thu, 20 Jun 2024 at 23:22, Quentin Schulz <quentin.schulz@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.
> 

If the BL31 blob doesn't go into boot-firmware, I don't see the benefit 
of boot-firmware for Rockchip platforms to be honest. Instead of telling 
people to get their firmware from github.com/rockchip-linux/rkbin we'll 
tell them to get one from rkbin and the other from boot-firmware. And I 
have a feeling that if that's how it'll go that the vendor will just not 
care about boot-firmware as they would anyway need to keep updating 
rkbin as well.

It doesn't matter whose fault it is for not being upstreamed earlier, 
the fact is, we still don't have a **merged** open-source BL31 for 
RK3588 2 and half years after the Rock5B from Radxa was announced. So in 
that whole timeframe, we have to work with blobs (or maintain your own 
forked TF-A whenever patches are posted and hope it works well enough).

[...]

>> 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.

Mostly != fully. The console doesn't break consistently so I assume that 
if it even prints a tiny bit of info it would still be able to break 
stuff. I assume we could have binman run some logic to replace the uart 
controller, mux and baudrate. Not sure we want that but we could.

Also, the DDR bin is passing the console info to the BL31 binary through 
ATAGS, so if you don't fix the DDR bin baudrate, controller and mux, the 
BL31 will also not be fixed.

Cheers,
Quentin

Re: Request for hosting a boot-firmware repository in u-boot git (denx and GitHub)

[Peter Robinson]

> > 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.
> >
>
> If the BL31 blob doesn't go into boot-firmware, I don't see the benefit
> of boot-firmware for Rockchip platforms to be honest. Instead of telling
> people to get their firmware from github.com/rockchip-linux/rkbin we'll
> tell them to get one from rkbin and the other from boot-firmware. And I
> have a feeling that if that's how it'll go that the vendor will just not
> care about boot-firmware as they would anyway need to keep updating
> rkbin as well.

Well it could go there, but I currently build ATF for all Rockchip
platforms we support.

> It doesn't matter whose fault it is for not being upstreamed earlier,

I agree. There's also  no reason something can't be included and then
dropped at a later time when things land upstream in appropriate
places.

> the fact is, we still don't have a **merged** open-source BL31 for
> RK3588 2 and half years after the Rock5B from Radxa was announced. So in
> that whole timeframe, we have to work with blobs (or maintain your own
> forked TF-A whenever patches are posted and hope it works well enough).

Agreed, the rk356x has *finally* been merged[1], it was sent as a PR
around 2 years before. I have highlighted this to Linaro/arm in the
past that this delay really isn't good enough.

[1] https://github.com/ARM-software/arm-trusted-firmware/tree/master/plat/rockchip/rk3568

The point I was trying to make, and I clearly didn't was. In the case
where there's open source code do we want to include vendor binaries?

> >> 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.
>
> Mostly != fully. The console doesn't break consistently so I assume that
> if it even prints a tiny bit of info it would still be able to break
> stuff. I assume we could have binman run some logic to replace the uart
> controller, mux and baudrate. Not sure we want that but we could.

Adjusting binaries on the fly sounds problematic to me. Is the process
open or something that's NDA between rockchip and their customers?

> Also, the DDR bin is passing the console info to the BL31 binary through
> ATAGS, so if you don't fix the DDR bin baudrate, controller and mux, the
> BL31 will also not be fixed.

Ultimately we should work with the vendor to fix those so they're
consistent? Why do you're products have issues, are they using
baudrate that is different to all the other rockchip devices?

Re: Request for hosting a boot-firmware repository in u-boot git (denx and GitHub)

[Peter Robinson]

On Fri, 21 Jun 2024 at 09:56, Peter Robinson <pbrobinson@gmail.com> wrote:
>
> > > 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.
> > >
> >
> > If the BL31 blob doesn't go into boot-firmware, I don't see the benefit
> > of boot-firmware for Rockchip platforms to be honest. Instead of telling
> > people to get their firmware from github.com/rockchip-linux/rkbin we'll
> > tell them to get one from rkbin and the other from boot-firmware. And I
> > have a feeling that if that's how it'll go that the vendor will just not
> > care about boot-firmware as they would anyway need to keep updating
> > rkbin as well.
>
> Well it could go there, but I currently build ATF for all Rockchip
> platforms we support.
>
> > It doesn't matter whose fault it is for not being upstreamed earlier,
>
> I agree. There's also  no reason something can't be included and then
> dropped at a later time when things land upstream in appropriate
> places.
>
> > the fact is, we still don't have a **merged** open-source BL31 for
> > RK3588 2 and half years after the Rock5B from Radxa was announced. So in
> > that whole timeframe, we have to work with blobs (or maintain your own
> > forked TF-A whenever patches are posted and hope it works well enough).
>
> Agreed, the rk356x has *finally* been merged[1], it was sent as a PR
> around 2 years before. I have highlighted this to Linaro/arm in the
> past that this delay really isn't good enough.

Also I don't believe this repository should be used as a band-aid for
other problems.

> [1] https://github.com/ARM-software/arm-trusted-firmware/tree/master/plat/rockchip/rk3568
>
> The point I was trying to make, and I clearly didn't was. In the case
> where there's open source code do we want to include vendor binaries?
>
> > >> 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.
> >
> > Mostly != fully. The console doesn't break consistently so I assume that
> > if it even prints a tiny bit of info it would still be able to break
> > stuff. I assume we could have binman run some logic to replace the uart
> > controller, mux and baudrate. Not sure we want that but we could.
>
> Adjusting binaries on the fly sounds problematic to me. Is the process
> open or something that's NDA between rockchip and their customers?
>
> > Also, the DDR bin is passing the console info to the BL31 binary through
> > ATAGS, so if you don't fix the DDR bin baudrate, controller and mux, the
> > BL31 will also not be fixed.
>
> Ultimately we should work with the vendor to fix those so they're
> consistent? Why do you're products have issues, are they using
> baudrate that is different to all the other rockchip devices?

Re: Request for hosting a boot-firmware repository in u-boot git (denx and GitHub)

[Quentin Schulz]

Hi Peter,

On 6/21/24 10:56 AM, Peter Robinson wrote:
>>> 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.
>>>
>>
>> If the BL31 blob doesn't go into boot-firmware, I don't see the benefit
>> of boot-firmware for Rockchip platforms to be honest. Instead of telling
>> people to get their firmware from github.com/rockchip-linux/rkbin we'll
>> tell them to get one from rkbin and the other from boot-firmware. And I
>> have a feeling that if that's how it'll go that the vendor will just not
>> care about boot-firmware as they would anyway need to keep updating
>> rkbin as well.
> 
> Well it could go there, but I currently build ATF for all Rockchip
> platforms we support.
> 

That's nice to hear :)

>> It doesn't matter whose fault it is for not being upstreamed earlier,
> 
> I agree. There's also  no reason something can't be included and then
> dropped at a later time when things land upstream in appropriate
> places.
> 

True BUT every now and then we get someone who wants to keep using the 
blobs for some reason. It's up to us to allow this or not though but 
wanted to let you know that this happens sometimes. (not our clients, 
people from the community).

Also, it's nice to be able to debug stuff by comparing the blob and 
open-source implementation behaviors. And sometimes even if there's an 
OSS implementation it isn't necessarily featureful, c.f. crypto support 
on the current patch series for RK3588 TF-A.

Also, I am not sure it brings any benefit to remove binaries once they 
are in the git history to be honest, maybe in terms of checkout size if 
you don't bring the history (shallow clone I think it's called?).

>> the fact is, we still don't have a **merged** open-source BL31 for
>> RK3588 2 and half years after the Rock5B from Radxa was announced. So in
>> that whole timeframe, we have to work with blobs (or maintain your own
>> forked TF-A whenever patches are posted and hope it works well enough).
> 
> Agreed, the rk356x has *finally* been merged[1], it was sent as a PR
> around 2 years before. I have highlighted this to Linaro/arm in the
> past that this delay really isn't good enough.
> 
> [1] https://github.com/ARM-software/arm-trusted-firmware/tree/master/plat/rockchip/rk3568
> 

Thanks, I agree this isn't really a nice situation. We cannot complain 
the vendors aren't doing their job of mainlining stuff if we take too 
long when they do (baring normal review process highlighting mistakes, 
errors, etc...).

> The point I was trying to make, and I clearly didn't was. In the case
> where there's open source code do we want to include vendor binaries?
> 

Then I guess we had the same problem in failing to expose our point 
since I had the same one, would those open-source based blobs be allowed 
in that repo?

I would suggest the following limitations:
- blobs from vanilla/unpatched upstreamed open-source projects aren't 
allowed
- blobs based on open-source projects with permissive licensing that 
allow those blobs to be shared as blobs without sources,

>>>> 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.
>>
>> Mostly != fully. The console doesn't break consistently so I assume that
>> if it even prints a tiny bit of info it would still be able to break
>> stuff. I assume we could have binman run some logic to replace the uart
>> controller, mux and baudrate. Not sure we want that but we could.
> 
> Adjusting binaries on the fly sounds problematic to me. Is the process
> open or something that's NDA between rockchip and their customers?
> 

All I can say is that I asked this tool to be open-sourced to Rockchip, 
it's currently an x86_64-only blob here: 
https://github.com/rockchip-linux/rkbin/blob/master/tools/ddrbin_tool

Mark Kettenis has written something to change the baudrate: 
https://github.com/openbsd/ports/blob/master/sysutils/u-boot/rk3588/files/rkbinpatch.c

>> Also, the DDR bin is passing the console info to the BL31 binary through
>> ATAGS, so if you don't fix the DDR bin baudrate, controller and mux, the
>> BL31 will also not be fixed.
> 
> Ultimately we should work with the vendor to fix those so they're
> consistent? Why do you're products have issues, are they using

Consistent in which way? I didn't get what you were suggesting.

> baudrate that is different to all the other rockchip devices?

Rockchip binaries default to 1.5MBaud while Theobroma boards are all 
115.2KBaud so we are consistent across all our product base.

As for the controller and mux, each controller has like 2 to 4 muxes and 
there are ten controllers on RK3588 for example. Rockchip provides a 
reference design for each SoC but nothing prevents you from using a 
different controller/mux than the one in the reference design. Which is 
what our HW department has done for the three devices I've brought up in 
the last two years. I assume because we wanted to use the functions 
exposed on the controller+mux used in the reference design and you only 
have so many permutations possible.

I suspect that the other HW board vendors just want to limit the amount 
of work to do in SW and just follow as close as possible the reference 
design.

Cheers,
Quentin

Re: Request for hosting a boot-firmware repository in u-boot git (denx and GitHub)

[Peter Robinson]

> > Well it could go there, but I currently build ATF for all Rockchip
> > platforms we support.
> >
>
> That's nice to hear :)
>
> >> It doesn't matter whose fault it is for not being upstreamed earlier,
> >
> > I agree. There's also  no reason something can't be included and then
> > dropped at a later time when things land upstream in appropriate
> > places.
> >
>
> True BUT every now and then we get someone who wants to keep using the
> blobs for some reason. It's up to us to allow this or not though but
> wanted to let you know that this happens sometimes. (not our clients,
> people from the community).

It's in git, they can continue to use a specific commit, tag or
snapshot, removing them doesn't stop that.

> Also, it's nice to be able to debug stuff by comparing the blob and
> open-source implementation behaviors. And sometimes even if there's an
> OSS implementation it isn't necessarily featureful, c.f. crypto support
> on the current patch series for RK3588 TF-A.

Sure, there's all sorts of user cases, we can't cover everything here
and it shouldn't be a dumping ground.

> Also, I am not sure it brings any benefit to remove binaries once they
> are in the git history to be honest, maybe in terms of checkout size if
> you don't bring the history (shallow clone I think it's called?).

It would indicate they should no longer be used. It might be due to
bugs, CVEs or that the version is no longer supported by the vendor or
even U-Boot. Upstream linux-firmware removes things once the last
supported associated LTS is EOL. As you state, it's still in the git
history.

> >> the fact is, we still don't have a **merged** open-source BL31 for
> >> RK3588 2 and half years after the Rock5B from Radxa was announced. So in
> >> that whole timeframe, we have to work with blobs (or maintain your own
> >> forked TF-A whenever patches are posted and hope it works well enough).
> >
> > Agreed, the rk356x has *finally* been merged[1], it was sent as a PR
> > around 2 years before. I have highlighted this to Linaro/arm in the
> > past that this delay really isn't good enough.
> >
> > [1] https://github.com/ARM-software/arm-trusted-firmware/tree/master/plat/rockchip/rk3568
> >
>
> Thanks, I agree this isn't really a nice situation. We cannot complain
> the vendors aren't doing their job of mainlining stuff if we take too
> long when they do (baring normal review process highlighting mistakes,
> errors, etc...).
>
> > The point I was trying to make, and I clearly didn't was. In the case
> > where there's open source code do we want to include vendor binaries?
> >
>
> Then I guess we had the same problem in failing to expose our point
> since I had the same one, would those open-source based blobs be allowed
> in that repo?
>
> I would suggest the following limitations:
> - blobs from vanilla/unpatched upstreamed open-source projects aren't
> allowed
> - blobs based on open-source projects with permissive licensing that
> allow those blobs to be shared as blobs without sources,
>
> >>>> 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.
> >>
> >> Mostly != fully. The console doesn't break consistently so I assume that
> >> if it even prints a tiny bit of info it would still be able to break
> >> stuff. I assume we could have binman run some logic to replace the uart
> >> controller, mux and baudrate. Not sure we want that but we could.
> >
> > Adjusting binaries on the fly sounds problematic to me. Is the process
> > open or something that's NDA between rockchip and their customers?
> >
>
> All I can say is that I asked this tool to be open-sourced to Rockchip,
> it's currently an x86_64-only blob here:
> https://github.com/rockchip-linux/rkbin/blob/master/tools/ddrbin_tool
>
> Mark Kettenis has written something to change the baudrate:
> https://github.com/openbsd/ports/blob/master/sysutils/u-boot/rk3588/files/rkbinpatch.c
>
> >> Also, the DDR bin is passing the console info to the BL31 binary through
> >> ATAGS, so if you don't fix the DDR bin baudrate, controller and mux, the
> >> BL31 will also not be fixed.
> >
> > Ultimately we should work with the vendor to fix those so they're
> > consistent? Why do you're products have issues, are they using
>
> Consistent in which way? I didn't get what you were suggesting.
>
> > baudrate that is different to all the other rockchip devices?
>
> Rockchip binaries default to 1.5MBaud while Theobroma boards are all
> 115.2KBaud so we are consistent across all our product base.
>
> As for the controller and mux, each controller has like 2 to 4 muxes and
> there are ten controllers on RK3588 for example. Rockchip provides a
> reference design for each SoC but nothing prevents you from using a
> different controller/mux than the one in the reference design. Which is
> what our HW department has done for the three devices I've brought up in
> the last two years. I assume because we wanted to use the functions
> exposed on the controller+mux used in the reference design and you only
> have so many permutations possible.
>
> I suspect that the other HW board vendors just want to limit the amount
> of work to do in SW and just follow as close as possible the reference
> design.
>
> Cheers,
> Quentin

Re: Request for hosting a boot-firmware repository in u-boot git (denx and GitHub)

[Mark Kettenis]

> Date: Fri, 21 Jun 2024 00:22:43 +0200
> From: Quentin Schulz <quentin.schulz@cherry.de>

Hi Quentin,

> 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).

To build the RK356x and RK3588 of the u-boot packages on OpenBSD I've
written a small program that changes the baudrate from 1500000 to
115200:

https://github.com/openbsd/ports/blob/master/sysutils/u-boot/rk356x/files/rkbinpatch.c
https://github.com/openbsd/ports/blob/master/sysutils/u-boot/rk3588/files/rkbinpatch.c

This just does the bare minimum and it might break with future changes
to the layout of the binaries.  But I don't think it would be
difficult to add a few more parameters.

Cheers,

Mark

Re: Request for hosting a boot-firmware repository in u-boot git (denx and GitHub)

[Simon Glass]

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.
>
> 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

Re: Request for hosting a boot-firmware repository in u-boot git (denx and GitHub)

[Peter Robinson]

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.
> >
> > 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.

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.

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.

> 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.

> >
> > [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

Re: Request for hosting a boot-firmware repository in u-boot git (denx and GitHub)

[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.
> > >
> > > 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.
>
> 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.

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=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

Re: Request for hosting a boot-firmware repository in u-boot git (denx and GitHub)

[Bryan Brattlof]

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.
> > > >
> > > > 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.
> >
> > 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=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

Re: Request for hosting a boot-firmware repository in u-boot git (denx and GitHub)

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 5137 bytes --]

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.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: Request for hosting a boot-firmware repository in u-boot git (denx and GitHub)

[Heinrich Schuchardt]

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.

Best regards

Heinrich

Re: Request for hosting a boot-firmware repository in u-boot git (denx and GitHub)

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 6499 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: Request for hosting a boot-firmware repository in u-boot git (denx and GitHub)

[Heinrich Schuchardt]

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

Re: Request for hosting a boot-firmware repository in u-boot git (denx and GitHub)

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 8412 bytes --]

On Tue, Jul 16, 2024 at 10:14:26PM +0200, Heinrich Schuchardt wrote:
> 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."

I'm not a lawyer and I don't pretend to be one on mailing lists, either.

In that my non-lawyer statements matter, I don't think binman
constitutes some new form of linking and I believe it falls in to the
same well known ABI exception.

But that's entirely unrelated to the question of hosting binaries (some
of which may be closed source) for use in firmware projects, some of
which will not be GPL. For example, I would assume that running
tianocore on i.MX8 requires the same assorted binaries that U-Boot does,
and that would not have a license conflict.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: Request for hosting a boot-firmware repository in u-boot git (denx and GitHub)

[Nishanth Menon]

On 15:36-20240716, Tom Rini wrote:
[...]

> > > > 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."
> 
> I'm not a lawyer and I don't pretend to be one on mailing lists, either.
> 
> In that my non-lawyer statements matter, I don't think binman
> constitutes some new form of linking and I believe it falls in to the
> same well known ABI exception.
> 
> But that's entirely unrelated to the question of hosting binaries (some
> of which may be closed source) for use in firmware projects, some of
> which will not be GPL. For example, I would assume that running
> tianocore on i.MX8 requires the same assorted binaries that U-Boot does,
> and that would not have a license conflict.

Usual disclaimers (not a lawyer, not representing corporate policy..  etc):
buildroot and yocto for example prebuild images for embedded systems and
they have had to deal with closed firmwares in the past as well.
Packaging binaries in a filesystem or some format (x509/fit) is
essentially the same thing - anyways.. interesting thought there.


PS: For folks interested: LPC accepted our proposal[1] in the
security/boot MC and if folks could join in person or virtually, it
would be great to lay this out and get the thoughts out and come to some
direction here.

[1] https://lpc.events/event/18/contributions/1815/


-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D