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

Chris Tyler chris at tylers.info
Thu Mar 8 17:09:01 UTC 2012


On Thu, 2012-03-08 at 11:22 -0500, Tom Callaway wrote:
> I don't think we want to be packaging up system BIOSes (or their
> equivalent). Our firmware exception is intended _only_ to enable FOSS
> code that wouldn't work without it.
> 
> I realize that it would be easier to have these files packaged so that
> you could make easy images, but I just don't think this is in keeping
> with the Free Software goals of Fedora.
> 
> I think you're going to have to ask the Board whether they wish to
> extend the Firmware exception to explicitly include packaging of
> non-free BIOS files (or BIOS-like files). I'm not willing to make that
> call (and I'm not sure I support it).


I think we need to divide this out into three separate cases:

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

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

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

-Chris



More information about the arm mailing list