[U-Boot] Fwd: Debian platform firmware strategy?

[Stephen Warren]

On 07/02/2014 11:33 AM, Chris Moore wrote:
> Hi Paul,
> 
> I hope you don't mind my forwarding your message below to the U-Boot ML.
> I think U-Boot ML subscribers may be interested in this discussion.
> My apologies in advance if I am wrong.
> 
> Cheers,
> Chris
> 
> -------- Message original --------
> Sujet:     Debian platform firmware strategy?
> Date de renvoi :     Wed, 2 Jul 2014 02:24:53 +0000 (UTC)
> De (renvoi) :     debian-arm at lists.debian.org
> Date :     Wed, 2 Jul 2014 10:24:31 +0800
> De :     Paul Wise <pabs at debian.org>
> Pour :     debian-arm at lists.debian.org
> 
> 
> 
> Hi all,
> 
> Platform firmware is an odd beast in the world of software. It is
> mostly different per device. It is mostly proprietary and binary only.
> When it isn't proprietary, the code is probably not merged upstream.
> Sometimes it is very hard or impossible to update. It is very easy to
> brick a device with a firmware update. Some devices are unbrickable
> due to read-only secondary platform firmware chosen at boot time with
> a button or via USB. Updating/replacing the platform firmware could
> have unforeseen consequences (not being able to boot other OSes for
> eg).
> 
> On x86 we ignore the platform firmware, don't package any libre
> firmware (i.e. coreboot) and chainload our own bootloaders before
> starting an OS.
> 
> On ARM the platform firmware is way less standardised but is often
> u-boot. u-boot mainline is packaged and apparently has support for 6
> armel devices and 13 armhf devices. Other devices ship with either a
> locked proprietary bootloader (Android devices mostly), a forked
> u-boot or some other FOSS bootloader. Sometimes the device ships with
> older less capable versions of u-boot which complicate installation
> (extra boot partitions required etc).
> 
> What should Debian's strategy/policy wrt platform firmware be?

It depends partially on where the firmware resides on the device.

Some boards have a separate flash device just for the firmware. For
example, all Tegra boards supported by mainline would fall into this
category, I think. (even when they boot from eMMC, the bootloader is in
the eMMC boot HW partition, not the main user data partition)

I would assert that for these systems, the user should be fully
responsible for installing the firmware. Installing firmware first as a
separate step is a pre-requisite to being able to plug in a bootable
installer disk/SD-card/..., and it would be nice to support installing
to ARM devices the same way as happens on x86 PCs where the HW makes
this possible.

At least for Tegra I've put a lot of effort into making the process of
installing mainline U-Boot easy. I assume other vendors do the same, or
could...

Other boards require at least some of the firmware to exist in a
filesystem and that filesystem is typically the same filesystem that is
used for the root filesystem (or at least is a partition on the same
storage device). Things like the Raspberry Pi and I think BeagleBone
etc. fall into this category.

For those systems, the OS (installer, packages, etc.) obviously has to
manage getting that firmware onto the media during installation or image
generation (or at least not trash any pre-created partition that
contains the firmware during installation). Whether any auto-updates
happen after that is an interesting issue.

> Currently it seems to be just leave the platform firmware alone and
> leave it up to the user to research if they can install libre
> firmware.
> 
> I'm thinking we should promote using Free Software where possible and
> packaged versions of that Free Software where possible. Due to the
> possibility of unforeseeable circumstances, that promotion should
> probably only consist of a default-to-no suggestion to replace
> existing platform firmware if only intending to use Debian on the
> device.