Raspberry Pi 4 EEPROM bootloader package
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. 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
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
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
Hi Nicolas, On 22.01.21 11:35, Nicolas Saenz Julienne wrote:
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.
I really hate that rpi-foo naming. We do have raspberrypi-firmware naming for a long time, stemming from github.com/raspberrypi/firmware. Thus, having related source packages in OBS be called raspberrypi-foo rather than rpi-foo makes them easiest to find within a devel project. You can always add Provides to the spec file, to allow for installation via Raspbian-compatible package names. So put it this way, even if we don't have to name things differently, it may make sense to do it cleaner - in particular since our distro is for more than just one platform. That is obviously independent of whether we split or combine packages. Regards, Andreas -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer HRB 36809 (AG Nürnberg)
On Fri, 2021-01-22 at 12:25 +0100, Andreas Färber wrote:
Hi Nicolas,
On 22.01.21 11:35, Nicolas Saenz Julienne wrote:
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.
I really hate that rpi-foo naming.
+1
We do have raspberrypi-firmware naming for a long time, stemming from github.com/raspberrypi/firmware. Thus, having related source packages in OBS be called raspberrypi-foo rather than rpi-foo makes them easiest to find within a devel project. You can always add Provides to the spec file, to allow for installation via Raspbian-compatible package names.
In summary, we'll have a package called 'raspberrypi-eeprom', with 'Provides: rpi-eeprom' and two sub-packages 'raspberrypi-eeprom-firmware' and 'raspberrypi-eeprom-tools'. Regards, Nicolas
On Fri, 2021-01-22 at 11:35 +0100, Nicolas Saenz Julienne wrote:
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.
FYI following our discussion here's the package's first SR: https://build.opensuse.org/request/show/866120 Regards, Nicolas
participants (3)
-
Andreas Färber -
Fabian Vogt -
Nicolas Saenz Julienne