[fedora-arm] ARM and shipping of various binary firmware / boot bits

[Tom Callaway]

On 03/08/2012 12:09 PM, Chris Tyler wrote:
> - Many of the platforms have open source bootloaders. They're a complete
> pain to build, but it it possible to build them. On some platforms these
> bootloaders run from NOR/NAND flash, and we can just inherit whatever is
> preinstalled on the system, just like we use a flashable BIOS on a PC
> without worrying about providing it (e.g., kirkwood plug computers).
> However, on other platforms, the loader is pulled in from removable
> media (SD, HD), so if we're going to produce a bootable image, we need
> those files. *** In these cases, I think we should do the hard work and
> build the bootloaders from source.

I agree.

> - There are some cases where the bootloader is not open source but is
> required for the device to operate (e.g., aboot). So here we can't build
> it, and we can't run without it. *** I'm not sure what approach we
> should take here. We could ask for an exemption to the existing rules,
> or we could say that the device is not supported until the code is
> released and poke the manufacturer with a stick until they do so.
> (Individual users could still hack up a solution in the interim).

I also agree. Either ask the Board for an exception here, or adjust the
tooling to download the bootloader from a third party when writing the
bootable image out to the removable media. (Or don't bother.)

> - There are other cases where the CPU is loaded by a separate device.
> Let me use the Raspberry Pi as an example here: there is a set of
> firmware that is loaded by the GPU which (a) sets up the GPU to provide
> a framebuffer, OpenGL interface, etc. to the ARM CPU, and (b) instructs
> the GPU to load the kernel, map the ARM processor's memory to physical
> memory in the 2nd level mapping unit, release the SD hardware so the ARM
> CPU can grab it, and then bring the ARM CPU out of reset to start
> booting. The source for the GPU code has not been released, but even the
> instruction set architecture for the GPU is unknown, so we couldn't
> compile the source if we had it. (We may have similar situations for
> CPUs with supervisory cores running a proprietary stack). *** In these
> cases, I think we can make the argument that the firmware blob is no
> different from a GPU or wireless firmware blob -- it's running on a
> device which is not the main CPU running the kernel and the device won't
> work without the blob.

I think I agree here as well. If there is a driver in the Linux kernel
that loads in this firmware to make the GPU work, then I think we're on
the same page. This seems equivalent to the Intel/AMD CPU firmware
updates which are already deemed to be acceptable.

~tom

==
Fedora Project