Hi, Am Freitag, 22. Januar 2021, 11:35:36 CET schrieb Nicolas Saenz Julienne:
Hi All, I'd appreciate some advice on how to deal with packaging the RPi eeprom bootloader firmware and tools.
As opposed to previous boards RPi4 has two bootloaders, the first stage lives in an SPI EEPROM memory while the second stage is downloaded from media based on the first stage's configuration. The second stage is the one that's common across all RPis (see 'raspberrypi-firmware' package).
The first stage bootloader can be configured[1] and updated. We have some tools already in place to do so (see packages 'raspberrypi-firmware-eeprom' and 'rpi-eeprom-config') but they only support a limited subset of what the original tools can do, and are overall hard to work with if you don't know what you're doing.
I've been working with RPi engineers to address the underlying issues preventing us from using the tools to the full extent. A new driver was introduced upstream[2], tools are being adapted, etc... So we're at a stage were we can take everything as is an use in TW.
Now, here's the issue, the packages I mentioned above were designed based on the assumption we had to do things differently. It's not the case anymore and I'd like to limit the amount of divergence with debian/raspbian WRT packaging as well. I see two options:
- Obsolete 'raspberrypi-firmware-eeprom' and 'rpi-eeprom-config' to create a new package 'rpi-eeprom.' Which is a 1:1 copy of what the Debian package does.
- Upgrade 'raspberrypi-firmware-eeprom', 'rpi-eeprom-config' and introduce 'rpi-eeprom-update.' On top of that create a pattern 'rpi-eeprom' that installs everything. We'd avoid obsoleting anything, but IMO it'd be harder to maintain in the long run.
So, what do you advise I do? I personally like the first option better.
Are the eeprom contents and tools closely coupled, i.e. is a matching version required to work properly? If not, at least the firmware itself should be split from the contents to allow easier upgrades/downgrades. The firmware is also non-free, so should be in a separate (sub-)package with different license anyway IMO. I don't think a pattern or just multiple .spec files are needed, subpackages would be fine. I don't see a reason to split -config from -update. So I suggest rpi-eeprom.spec which has rpi-eeprom-firmware with the non-OSS license and rpi-eeprom-tools, which provides/obsoletes the old packages. rpi-eeprom-firmware could just have Requires: %{name}-tools >= %{version}, that way just installing rpi-eeprom-firmware also installs the tools, but not vice-versa. Cheers, Fabian
Regards, Nicolas
[1] config docs: https://www.raspberrypi.org/documentation/hardware/raspberrypi/bcm2711_bootl... code repo: https://github.com/raspberrypi/rpi-eeprom
[2] https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg2438246.html