Re: ARM and shipping of various binary firmware / boot bits

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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.


Fedora Project
arm mailing list

[Index of Archives]     [Linux ARM (Vger)]     [Linux ARM]     [ARM Kernel]     [Fedora User Discussion]     [Older Fedora Users Discussion]     [Fedora Advisory Board]     [Fedora Security]     [Fedora Maintainers]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Mentors]     [Fedora Package Announce]     [Fedora Package Review]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Coolkey]     [Yum Users]     [Tux]     [Yosemite News]     [Yosemite Photos]     [Linux Apps]     [KDE Users]     [Fedora Tools]     [Fedora Art]     [Fedora Docs]     [Asterisk PBX]

Powered by Linux