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_bootloader_config.md
> code repo: https://github.com/raspberrypi/rpi-eeprom
>
> [2] https://www.mail-archive.com/[email protected]/msg2438246.html
