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