On Fri, 2021-01-22 at 12:04 +0100, Fabian Vogt wrote: > 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.
They are loosely coupled, so we should be fine with that.
> 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.
Thanks, that sounds like a good strategy.
Regards,
Nicolas
signature.asc
Description: This is a digitally signed message part
