-
Notifications
You must be signed in to change notification settings - Fork 521
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
firmware: Enable firmware compression to conserve some disk space #3418
firmware: Enable firmware compression to conserve some disk space #3418
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there specific testing to be done for ARM? I remember that “self-decompressing” kernel images were only supported for x86_64, and for ARM images the kernel folks relied on the bootloader to decompress the image. I assume that decompressing the firmware is handled by the kernel and thus nothing special is needed. But it wouldn't hurt to confirm 😅
Firmware binary blobs can add up to quite a lot of disk space usage. With Bottlerocket we do aim to keep our images small, so enable the kernel's firmware loading infrastructure to handle compressed firmware files. Signed-off-by: Leonard Foerster <foersleo@amazon.com>
Firmware binary blobs can add up to quite a lot of disk space usage. With Bottlerocket we do aim to keep our images small, so enable the kernel's firmware loading infrastructure to handle compressed firmware files. Signed-off-by: Leonard Foerster <foersleo@amazon.com>
Firmware binary blobs can add up to quite a lot of disk space usage. With Bottlerocket we do aim to keep our images small, so enable the kernel's firmware loading infrastructure to handle compressed firmware files. Previous to linux kernel series 5.19 option `CONFIG_FW_LOADER_COMPRESS` was only supporting the XZ compression algorithm. Since then also ZSTD compression is available which makes additional options necessary to select the right algorithm. For now select the default XZ compression to align all our supported kernels on the same. Once we are only supporting kernels >=6.1 we may chose to switch compression algorithm. Signed-off-by: Leonard Foerster <foersleo@amazon.com>
Recoup some image size by enabling firmware compression, now that our kernels support it. None of the compressed firmware files has the execute bit set, so we can skip removing it when assembling the package. Signed-off-by: Leonard Foerster <foersleo@amazon.com>
1175a58
to
2e67d49
Compare
Great pointer @arnaldo2792! I have double checked that none of the config options comes with any dependency on architecture and the code under |
⬆️ force-push rebases on latest develop to accommodate conflicting changes introduced through #3419 (just contextual changes in the config files) and addressed Ben's comment on necessity of removing the execute bits. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice space savings!
Issue number:
Closes #3359
Description of changes:
When we introduced the linux-firmware package in #3296, we did not enable
compression as we had not have the necessary support in our kernels enabled. This PR fixes this by enabling the necessary
config options. Before linux kernel series 5.19 the firmware compression code only supported XZ compression, hence we do
not need (and cant) select a specific compression algorithm. With 6.1 we need to additionally select XZ compression.
This change saves about 4mb in the package size, and even 36 mb in unpacked form:
Testing done:
Proper testing for this is tricky, as we do not have access to any of the hardware this package includes.
Only the expected config changes are recorded for this patch:
Apart from that we can not really
Terms of contribution:
By submitting this pull request, I agree that this contribution is dual-licensed under the terms of both the Apache License, version 2.0, and the MIT license.