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

[Jon Masters]

On 03/08/2012 10:06 AM, Tom Callaway wrote:

> Okay, so I'm admittedly a bit lost here, because we don't normally ship
> BIOS code for any other platform (apart from qemu). Why is ARM different
> in that regard? Why don't the vendors deliver BIOS (or equivalent)?

(on the phone, so excuse brevity...but I want to say something quickly
before this thread goes on too long)

I think it's worth pointing out here why this is the case. For reasons
of cost reduction/inexpensive hardware, most of the modern SoCs contain
a tiny amount of boot code/logic on-chip that is able to read U-Boot
(x-loader is a simplified U-Boot able to load U-Boot proper, required
due to e.g. limited running from cache early in bringup) in from an SD
card or similar. On x86, it would be in some flash chip, but on a $25
board, that adds to the BOM (Bill Of Materials) cost in a material way
so if a chip is able to load U-Boot without that flash, it is preferred.

Anyway. All this means that on ARM, in some cases (won't be true on
servers), especially inexpensive dev boards, we become the distributor
of the U-Boot bits if we want to ship whole SD Card images (which we
think we do - otherwise installation on Panda or Pi becomes harder, on
servers and other systems we'll do x86-like Anaconda and PXE later). I
think we could build U-Boot ourselves, especially in the case of boards
where we can't brick them just by having a bad build. Generally, I don't
want to distribute "BIOS" code in the longer term beyond those cases
where we need to shove something on an SD Card image by nature of the
way that the cards boot. In other cases, I prefer we don't build or ship
something, e.g. for U-Boot where it is shipped in flash on the board or
in cases where we might be able to brick a board.

I'll send more later...this is a holding email to add some explanation
mid-thread before this runs away :)

Jon.