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@lists.debian.org Date : Wed, 2 Jul 2014 10:24:31 +0800 De : Paul Wise pabs@debian.org Pour : debian-arm@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.