Hi guys, lately did a lot of archboot hacking and stumbled over our firmware package. It needs installed 750 MB, download size is 130 MB. I tried to get it smaller and uploaded the archboot-linux-firmware package for my purposes. Our linux kernel needs only 180 MB installed size, download size is about 37 MB. Wouldn't it make sense to provide for each kernel we ship, a separate firmware package? Just my 2 cwnts, greetings tpowa
On Mon, Sep 27, 2021 at 8:30 PM Tobias Powalowski via arch-dev-public < arch-dev-public@lists.archlinux.org> wrote:
Hi guys, lately did a lot of archboot hacking and stumbled over our firmware package. It needs installed 750 MB, download size is 130 MB. I tried to get it smaller and uploaded the archboot-linux-firmware package for my purposes. Our linux kernel needs only 180 MB installed size, download size is about 37 MB. Wouldn't it make sense to provide for each kernel we ship, a separate firmware package? Just my 2 cwnts, greetings tpowa
The method used there wouldn't produce a usable firmware package for me. For example, `modinfo -F firmware iwlwifi` lists `iwlwifi-Qu-c0-hr-b0-64.ucode` but linux-firmware does not contain that file. The driver will fall back to the next lower version, `iwlwifi-Qu-c0-hr-b0-63.ucode`, which is in linux-firmware but not in the modinfo output.
I think the best we can do is split some of the more obscure vendors that have large firmware sets, like Netronome, Qualcomm, Mellanox, Marvell, Cavium, QLogic and NXP.
On 27/09/2021 21:13, Jan Alexander Steffens (heftig) via arch-dev-public wrote:
On Mon, Sep 27, 2021 at 8:30 PM Tobias Powalowski via arch-dev-public < arch-dev-public@lists.archlinux.org> wrote:
Hi guys, lately did a lot of archboot hacking and stumbled over our firmware package. It needs installed 750 MB, download size is 130 MB. I tried to get it smaller and uploaded the archboot-linux-firmware package for my purposes. Our linux kernel needs only 180 MB installed size, download size is about 37 MB. Wouldn't it make sense to provide for each kernel we ship, a separate firmware package? Just my 2 cwnts, greetings tpowa
The method used there wouldn't produce a usable firmware package for me. For example, `modinfo -F firmware iwlwifi` lists `iwlwifi-Qu-c0-hr-b0-64.ucode` but linux-firmware does not contain that file. The driver will fall back to the next lower version, `iwlwifi-Qu-c0-hr-b0-63.ucode`, which is in linux-firmware but not in the modinfo output.
I think the best we can do is split some of the more obscure vendors that have large firmware sets, like Netronome, Qualcomm, Mellanox, Marvell, Cavium, QLogic and NXP.
I second this, the biggest firmware sizes are from these fancynetwork equipemnt folks such as netronome. An alternative is enabling xz compression for the firmware itself this should save space as well, but it depends on support in the LTS kernel.
Greetings,
Jelle van der Waa
Em setembro 27, 2021 16:46 Jelle van der Waa via arch-dev-public escreveu:
On 27/09/2021 21:13, Jan Alexander Steffens (heftig) via arch-dev-public wrote:
On Mon, Sep 27, 2021 at 8:30 PM Tobias Powalowski via arch-dev-public < arch-dev-public@lists.archlinux.org> wrote:
Hi guys, lately did a lot of archboot hacking and stumbled over our firmware package. It needs installed 750 MB, download size is 130 MB. I tried to get it smaller and uploaded the archboot-linux-firmware package for my purposes. Our linux kernel needs only 180 MB installed size, download size is about 37 MB. Wouldn't it make sense to provide for each kernel we ship, a separate firmware package? Just my 2 cwnts, greetings tpowa
The method used there wouldn't produce a usable firmware package for me. For example, `modinfo -F firmware iwlwifi` lists `iwlwifi-Qu-c0-hr-b0-64.ucode` but linux-firmware does not contain that file. The driver will fall back to the next lower version, `iwlwifi-Qu-c0-hr-b0-63.ucode`, which is in linux-firmware but not in the modinfo output.
I think the best we can do is split some of the more obscure vendors that have large firmware sets, like Netronome, Qualcomm, Mellanox, Marvell, Cavium, QLogic and NXP.
I second this, the biggest firmware sizes are from these fancynetwork equipemnt folks such as netronome. An alternative is enabling xz compression for the firmware itself this should save space as well, but it depends on support in the LTS kernel.
Can't we do both? Enable xz and split the larger firmwares? Or LTS don't have plans to support xz for firmware?
Regards, Giancarlo Razzolini
Hi, according to google in 5.3 the xz compression was introduced so all kernels we ship should support it. greetings tpowa
Am Mo., 27. Sept. 2021 um 21:54 Uhr schrieb Giancarlo Razzolini via arch-dev-public arch-dev-public@lists.archlinux.org:
Em setembro 27, 2021 16:46 Jelle van der Waa via arch-dev-public escreveu:
On 27/09/2021 21:13, Jan Alexander Steffens (heftig) via arch-dev-public wrote:
On Mon, Sep 27, 2021 at 8:30 PM Tobias Powalowski via arch-dev-public < arch-dev-public@lists.archlinux.org> wrote:
Hi guys, lately did a lot of archboot hacking and stumbled over our firmware package. It needs installed 750 MB, download size is 130 MB. I tried to get it smaller and uploaded the archboot-linux-firmware
package
for my purposes. Our linux kernel needs only 180 MB installed size, download size is
about
37 MB. Wouldn't it make sense to provide for each kernel we ship, a separate firmware package? Just my 2 cwnts, greetings tpowa
The method used there wouldn't produce a usable firmware package for me. For example, `modinfo -F firmware iwlwifi` lists `iwlwifi-Qu-c0-hr-b0-64.ucode` but linux-firmware does not contain that file. The driver will fall back to the next lower version, `iwlwifi-Qu-c0-hr-b0-63.ucode`, which is in linux-firmware but not in
the
modinfo output.
I think the best we can do is split some of the more obscure vendors
that
have large firmware sets, like Netronome, Qualcomm, Mellanox, Marvell, Cavium, QLogic and NXP.
I second this, the biggest firmware sizes are from these fancynetwork equipemnt folks such as netronome. An alternative is enabling xz compression for the firmware itself this should save space as well, but it depends on support in the LTS kernel.
Can't we do both? Enable xz and split the larger firmwares? Or LTS don't have plans to support xz for firmware?
Regards, Giancarlo Razzolini
Hi, short summarize from irc: https://fedoraproject.org/wiki/Changes/CompressKernelFirmware xz -C crc32 is the only supported mode
mkinitcpio needs to be patched: https://bugs.archlinux.org/task/72263
From my side unknown, if dracut and booster can handle compressed firmware
files.
greetings tpowa
Am Di., 28. Sept. 2021 um 06:55 Uhr schrieb Tobias Powalowski < tobias.powalowski@googlemail.com>:
Hi, according to google in 5.3 the xz compression was introduced so all kernels we ship should support it. greetings tpowa
Am Mo., 27. Sept. 2021 um 21:54 Uhr schrieb Giancarlo Razzolini via arch-dev-public arch-dev-public@lists.archlinux.org:
Em setembro 27, 2021 16:46 Jelle van der Waa via arch-dev-public escreveu:
On 27/09/2021 21:13, Jan Alexander Steffens (heftig) via
arch-dev-public
wrote:
On Mon, Sep 27, 2021 at 8:30 PM Tobias Powalowski via arch-dev-public < arch-dev-public@lists.archlinux.org> wrote:
Hi guys, lately did a lot of archboot hacking and stumbled over our firmware package. It needs installed 750 MB, download size is 130 MB. I tried to get it smaller and uploaded the archboot-linux-firmware
package
for my purposes. Our linux kernel needs only 180 MB installed size, download size is
about
37 MB. Wouldn't it make sense to provide for each kernel we ship, a separate firmware package? Just my 2 cwnts, greetings tpowa
The method used there wouldn't produce a usable firmware package for
me.
For example, `modinfo -F firmware iwlwifi` lists `iwlwifi-Qu-c0-hr-b0-64.ucode` but linux-firmware does not contain that file. The driver will fall back to the next lower version, `iwlwifi-Qu-c0-hr-b0-63.ucode`, which is in linux-firmware but not in
the
modinfo output.
I think the best we can do is split some of the more obscure vendors
that
have large firmware sets, like Netronome, Qualcomm, Mellanox, Marvell, Cavium, QLogic and NXP.
I second this, the biggest firmware sizes are from these fancynetwork equipemnt folks such as netronome. An alternative is enabling xz compression for the firmware itself this should save space as well, but it depends on support in the LTS kernel.
Can't we do both? Enable xz and split the larger firmwares? Or LTS don't have plans to support xz for firmware?
Regards, Giancarlo Razzolini
-- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org
On Tue, Sep 28, 2021 at 08:34:45AM +0200, Tobias Powalowski via arch-dev-public wrote:
Hi, short summarize from irc: https://fedoraproject.org/wiki/Changes/CompressKernelFirmware xz -C crc32 is the only supported mode
mkinitcpio needs to be patched: https://bugs.archlinux.org/task/72263
From my side unknown, if dracut and booster can handle compressed firmware files.
Namarrgon submitted a WIP patch for this in August as a side-note.
https://github.com/archlinux/mkinitcpio/pull/65
On 2021-09-28 08:34, Tobias Powalowski via arch-dev-public wrote:
From my side unknown, if dracut and booster can handle compressed firmware files.
For dracut this is supposed to work [1], though note that I haven't tested this myself on Arch.
Booster seems to read the name of the firmware file from the kernel module [2], then use that name to find the file in the firmware directory [3,4]. It seems as if the appendFirmwareFiles() function might need to get patched to look for `fwPath + ".xz"` in addition to `fwPath`, though I could be totally wrong here.
Best, Jonas
[1] https://github.com/dracutdevs/dracut/commit/999cfa84582ab4ce4cc602242cb71d0a... [2] https://github.com/anatol/booster/blob/d8caf32a34527085f85764f262151bcb2cc07... [3] https://github.com/anatol/booster/blob/d8caf32a34527085f85764f262151bcb2cc07... [4] https://github.com/anatol/booster/blob/8c3f6fee7604170229ed0dfb1fdba02f5944c...
arch-dev-public@lists.archlinux.org