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 _______________________________________________ arm mailing list arm@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/arm
