Quest to reduce firmware size #590
Labels
Comments
|
A few other ideas:
These may not be as high priority as other changes, but ones to certainly look at to help reduce firmware size, especially as the project grows. |
|
@SebastianMcMillan : Those are good cleanup ideas, but unfortunately, will not impact the initrd.cpio.xz (including heads.cpio and tools.cpio), those text files being highly compressed. The problem lies in binaries, not higly compressed under initrd.cpio.xz |
|
This article (or the series it comes from) may yield some inspiration: |
|
Solution lies in #307 |
Closed
|
@zaolin : Unfortunately, there is no smartcard support in sequoia-pgp ATM, on which Heads relies on for verified /boot integrity. |
|
@tlaurion ask them for support, they should have basic support for it. They are on IRC #sequoia at Freenode |
|
Here we go again, since
To troubleshoot: Output: |
tlaurion
added a commit
to tlaurion/heads
that referenced
this issue
May 3, 2020
…gawk error fixed upstream). Goal of this is to show that x230 board will die if we do not resolve linuxboot#590, or move along with linuxboot#703.
|
A public build showing that not moving along with this actual ticket or with #703 is breaking x230 support and 12Mb boards altogether, Heads having become too big. @flammit: This build will fail at coreboot integration of cpios (CBFS region not being big enough), but artifacts will include initird.cpio.xz, heads.cpio, tools.cpio and modules.cpio for others to see the limit and dead end we are now facing. Now what? |
|
@tlaurion is reducing the kernel size not an option, or simply too much effort? |
|
@MrChromebox : my reluctance in attacking Kernel size reduction comes with the conclusions of #453 where some 300k were obtained. Of course, those recommendations should be investigated. Will reread myself. I'll revisit gpg2 myself, in the goal of fixing #668 for #710 |
This was referenced May 4, 2020
|
@MrChromebox #668 and #710 being resolved, I've been looking at multiple source on kernel debloating to do some state of the art. It seems that be most interesting articles are... Runtime collection based optimizations: LTO:
Reading. |
|
Playing around with information found under this "Shrinking the kernel with an AXE" blog post to reduce kernel size prior of going the LTO way. Raw results Edit: |
This was referenced May 27, 2020
tlaurion
added a commit
to tlaurion/heads
that referenced
this issue
Aug 31, 2022
Adresses @easrentai suggestion to pass modules build optimization for space here: linuxboot#590 (comment) Limitations: - busybox don't seem to take Os into consideration when applied, no change to module yet. - kexec applies both O2 and Os, no change to module yet. - Kernel is already optimized for size (CONFIG_CC_OPTIMIZE_FOR_SIZE as Kconfig option), and kernel modules stripped prior of inserted in initrd, compressed with xz. Nothing else can be done here unless lto Next steps: - Go LTO for kernel and modules? But, I was not successful going that way in the past, maybe musl-cross-make has changed. - Not sure if I read correctly, but -Oz may have happened under GCC 12.1, but not sure if apple relative or FSS GCC. Opened an issue over musl-cross-make, but the project is conservative on used GCC version. Attempt to contribute to linuxboot#590 by reducing payload's footprint
tlaurion
added a commit
to tlaurion/heads
that referenced
this issue
Aug 31, 2022
Adresses @easrentai suggestion to pass modules build optimization for space here: linuxboot#590 (comment) Limitations: - busybox don't seem to take Os into consideration when applied, no change to module yet. - kexec applies both O2 and Os, no change to module yet. - Kernel is already optimized for size (CONFIG_CC_OPTIMIZE_FOR_SIZE as Kconfig option), and kernel modules stripped prior of inserted in initrd, compressed with xz. Nothing else can be done here unless lto Next steps: - Go LTO for kernel and modules? But, I was not successful going that way in the past, maybe musl-cross-make has changed. - Not sure if I read correctly, but -Oz may have happened under GCC 12.1, but not sure if apple relative or FSS GCC. Opened an issue over musl-cross-make, but the project is conservative on used GCC version. Attempt to contribute to linuxboot#590 by reducing payload's footprint
tlaurion
added a commit
to tlaurion/heads
that referenced
this issue
Aug 31, 2022
Adresses @easrentai suggestion to pass modules build optimization for space here: linuxboot#590 (comment) Unifying passage of $(CROSS_TOOLS) as environment variable to compare with linuxboot#1121 Limitations: - busybox don't seem to take Os into consideration when applied, no change to module yet. - kexec applies both O2 and Os, no change to module yet. - Kernel is already optimized for size (CONFIG_CC_OPTIMIZE_FOR_SIZE as Kconfig option), and kernel modules stripped prior of inserted in initrd, compressed with xz. Nothing else can be done here unless lto Next steps: - Go LTO for kernel and modules? But, I was not successful going that way in the past, maybe musl-cross-make has changed. - Not sure if I read correctly, but -Oz may have happened under GCC 12.1, but not sure if apple relative or FSS GCC. Opened an issue over musl-cross-make, but the project is conservative on used GCC version. Attempt to contribute to linuxboot#590 by reducing payload's footprint
tlaurion
added a commit
to tlaurion/heads
that referenced
this issue
Aug 31, 2022
Adresses @easrentai suggestion to pass modules build optimization for space here: linuxboot#590 (comment) Uniformized module's $(CROSS_TOOLS) being passed as environment variable, prior of ./configure call Limitations: - busybox don't seem to take Os into consideration when applied, no change to module yet. - kexec applies both O2 and Os, no change to module yet. - Kernel is already optimized for size (CONFIG_CC_OPTIMIZE_FOR_SIZE as Kconfig option), and kernel modules stripped prior of inserted in initrd, compressed with xz. Nothing else can be done here unless lto Next steps: - Go LTO for kernel and modules? But, I was not successful going that way in the past, maybe musl-cross-make has changed. - Not sure if I read correctly, but -Oz may have happened under GCC 12.1, but not sure if apple relative or FSS GCC. Opened an issue over musl-cross-make, but the project is conservative on used GCC version. Attempt to contribute to linuxboot#590 by reducing payload's footprint
tlaurion
added a commit
to tlaurion/heads
that referenced
this issue
Sep 26, 2022
Adresses @easrentai suggestion to pass modules build optimization for space here: linuxboot#590 (comment) Uniformized module's $(CROSS_TOOLS) being passed as environment variable, prior of ./configure call Limitations: - busybox don't seem to take Os into consideration when applied, no change to module yet. - kexec applies both O2 and Os, no change to module yet. - Kernel is already optimized for size (CONFIG_CC_OPTIMIZE_FOR_SIZE as Kconfig option), and kernel modules stripped prior of inserted in initrd, compressed with xz. Nothing else can be done here unless lto Next steps: - Go LTO for kernel and modules? But, I was not successful going that way in the past, maybe musl-cross-make has changed. - Not sure if I read correctly, but -Oz may have happened under GCC 12.1, but not sure if apple relative or FSS GCC. Opened an issue over musl-cross-make, but the project is conservative on used GCC version. Attempt to contribute to linuxboot#590 by reducing payload's footprint
tlaurion
added a commit
to tlaurion/heads
that referenced
this issue
Feb 18, 2023
Adresses @easrentai suggestion to pass modules build optimization for space here: linuxboot#590 (comment) Uniformized module's $(CROSS_TOOLS) being passed as environment variable, prior of ./configure call Limitations: - busybox don't seem to take Os into consideration when applied, no change to module yet. - kexec applies both O2 and Os, no change to module yet. - Kernel is already optimized for size (CONFIG_CC_OPTIMIZE_FOR_SIZE as Kconfig option), and kernel modules stripped prior of inserted in initrd, compressed with xz. Nothing else can be done here unless lto Next steps: - Go LTO for kernel and modules? But, I was not successful going that way in the past, maybe musl-cross-make has changed. - Not sure if I read correctly, but -Oz may have happened under GCC 12.1, but not sure if apple relative or FSS GCC. Opened an issue over musl-cross-make, but the project is conservative on used GCC version. Attempt to contribute to linuxboot#590 by reducing payload's footprint
tlaurion
added a commit
to tlaurion/heads
that referenced
this issue
Feb 21, 2023
Adresses @easrentai suggestion to pass modules build optimization for space here: linuxboot#590 (comment) Uniformized module's $(CROSS_TOOLS) being passed as environment variable, prior of ./configure call Limitations: - busybox don't seem to take Os into consideration when applied, no change to module yet. - kexec applies both O2 and Os, no change to module yet. - Kernel is already optimized for size (CONFIG_CC_OPTIMIZE_FOR_SIZE as Kconfig option), and kernel modules stripped prior of inserted in initrd, compressed with xz. Nothing else can be done here unless lto Next steps: - Go LTO for kernel and modules? But, I was not successful going that way in the past, maybe musl-cross-make has changed. - Not sure if I read correctly, but -Oz may have happened under GCC 12.1, but not sure if apple relative or FSS GCC. Opened an issue over musl-cross-make, but the project is conservative on used GCC version. Attempt to contribute to linuxboot#590 by reducing payload's footprint
tlaurion
added a commit
to tlaurion/heads
that referenced
this issue
Feb 22, 2023
Adresses @easrentai suggestion to pass modules build optimization for space here: linuxboot#590 (comment) Uniformized module's $(CROSS_TOOLS) being passed as environment variable, prior of ./configure call Limitations: - busybox don't seem to take Os into consideration when applied, no change to module yet. - kexec applies both O2 and Os, no change to module yet. - Kernel is already optimized for size (CONFIG_CC_OPTIMIZE_FOR_SIZE as Kconfig option), and kernel modules stripped prior of inserted in initrd, compressed with xz. Nothing else can be done here unless lto Next steps: - Go LTO for kernel and modules? But, I was not successful going that way in the past, maybe musl-cross-make has changed. - Not sure if I read correctly, but -Oz may have happened under GCC 12.1, but not sure if apple relative or FSS GCC. Opened an issue over musl-cross-make, but the project is conservative on used GCC version. Attempt to contribute to linuxboot#590 by reducing payload's footprint
tlaurion
added a commit
to tlaurion/heads
that referenced
this issue
Feb 22, 2023
Adresses @easrentai suggestion to pass modules build optimization for space here: linuxboot#590 (comment) Uniformized module's $(CROSS_TOOLS) being passed as environment variable, prior of ./configure call Limitations: - busybox don't seem to take Os into consideration when applied, no change to module yet. - kexec applies both O2 and Os, no change to module yet. - Kernel is already optimized for size (CONFIG_CC_OPTIMIZE_FOR_SIZE as Kconfig option), and kernel modules stripped prior of inserted in initrd, compressed with xz. Nothing else can be done here unless lto Next steps: - Go LTO for kernel and modules? But, I was not successful going that way in the past, maybe musl-cross-make has changed. - Not sure if I read correctly, but -Oz may have happened under GCC 12.1, but not sure if apple relative or FSS GCC. Opened an issue over musl-cross-make, but the project is conservative on used GCC version. Attempt to contribute to linuxboot#590 by reducing payload's footprint
tlaurion
added a commit
to tlaurion/heads
that referenced
this issue
Mar 1, 2023
Adresses @easrentai suggestion to pass modules build optimization for space here: linuxboot#590 (comment) - Uniformized module's $(CROSS_TOOLS) being passed as environment variable, prior of ./configure call - Includes linuxboot#1251 (should be rebased on top of it merged)
tlaurion
added a commit
to tlaurion/heads
that referenced
this issue
Mar 7, 2023
Adresses @easrentai suggestion to pass modules build optimization for space here: linuxboot#590 (comment) - Uniformized module's $(CROSS_TOOLS) being passed as environment variable, prior of ./configure call
tlaurion
added a commit
to tlaurion/heads
that referenced
this issue
Mar 7, 2023
Adresses @easrentai suggestion to pass modules build optimization for space here: linuxboot#590 (comment) - Uniformized module's $(CROSS_TOOLS) being passed as environment variable, prior of ./configure call
tlaurion
added a commit
to tlaurion/heads
that referenced
this issue
Mar 7, 2023
Adresses @easrentai suggestion to pass modules build optimization for space here: linuxboot#590 (comment) - Uniformized module's $(CROSS_TOOLS) being passed as environment variable, prior of ./configure call Doesn't work for: - busybox (HOSTCXXFLAGS="-Os" attempted prior of ./configure call) - zlib (CFLAGS="-Os" attempted prior of ./configure call) - npth (CFLAGS="-Os" attempted prior of ./configure call)
tlaurion
added a commit
to tlaurion/heads
that referenced
this issue
Mar 7, 2023
Adresses @easrentai suggestion to pass modules build optimization for space here: linuxboot#590 (comment) - Uniformized module's $(CROSS_TOOLS) being passed as environment variable, prior of ./configure call Doesn't work for: - busybox (HOSTCXXFLAGS="-Os" attempted prior of ./configure call) - zlib (CFLAGS="-Os" attempted prior of ./configure call) - npth (CFLAGS="-Os" attempted prior of ./configure call)
|
Some of these comments are fairly general but I think pertinent to the above discussion. I believe that on platforms with libgfxinit, you can reuse the framebuffer set up by Coreboot, then all you need is the kernel's simplefb and the Google Coreboot framebuffer firmware driver. This no longer requires a patch, it's upstream. This may or may not be an improvement over the current state, but if Linux is doing any graphics initialisation whatsoever currently, there may be a space saving. The only non-Intel example I can see which you support is the old and quirky KGPE-D16, no longer supported upstream. The suspiciously upbeat Libreboot documentation claims that native graphics initialisation works in text mode, but I've never seen any evidence of this working without a video BIOS on that board. Nonetheless I suggest that this is fiddling around the edges, the kernel is already pretty small. GPG seems to be the biggest component, and it is difficult to use. I'd personally include a couple of manpages and busybox man! |
|
@druimalban you are right on point with my current experiments with libgfxinit for GMA (Intel only supported in libgfxinit code for native graphic init) and my current status is that its "working" correctly with "simple" hack added into kexec patch for simplefb fb base address to be passed through kexec call. I have a lot of ongoing branches Problem there, still with simplefb, is that fbwhiptail won't work writing in single buffer and needs work under fbwhiptail. Whiptail (console based menus) works. And then kexec'ing into even tinycore14 for x86_64 works (only provides vesa and the console aquires the passed fb just fine). Situation is different for qemu q35 coreboot board. Bochs driver in coreboot initializes correctly, shows splashscreen (qemu -vga std) And then bochs DRM takes over the fb correctly. This requires the next kernel to provide bochs DRM as well for next kernel to take over console correctly. On qemu with bochs providing native init in coreboot, qemu -vga std, and simplefb driving the framebuffer, I'm currently stuck with the fb under qemu not refreshing unless I zoom in zoom out qemu window. This kexec's correctly into next kernel from vesa mode (tinycore14 iso boots fine) to bochs DRM if provided(Debian fedora etc) but still qemu doesn't refresh the window. Something is wrong there and needs proper troubleshooting to open bug report in either kernel/qemu. I will have to retest --32bit entry point in kexec call as linuxboot folks points out again, but haven't been successful fixing this in past tests but I might kiss something. When DRM drivers are removed from x230 kernel, namely i915 fb and DRM, there is a gain of 500kb of compressed firmware space freed under coreboot stitched rom for x230-maximized board in my tests. Kernel 5.14+ moved DRM into tiny DRM, and ecosystem is moving forward to remove fb support and replace it with kms DRM drivers compiled in kernel, and seems to be the way forward. Heads could he generalized in using simplefb with native init under coreboot, which most boards supports either through native gfx init or libgfxinit. Current situation with i915drm still works with hacks of kexec so that newer i915drm is passed as VLFB to next kernel call saying to kernel to leak the fb address. And libgfxinit enabled for all Intel based gfx and i915drm taking ownership of fb, the user at least gets a splashscreen where he waits for spi to read the payload and execute it (8-10 seconds). This seems to be the first step to bump to 5.10+ and leave 4.14 behind and have interesting new features, like extfat, android tethering, mmc reader support and other fancy things being possible to use. Also a lot of kernel options were reviewed and considered unnecessary in branch tested, including crypto back end requirements in kernel and performance gains from scheduler choices and selecting proper CPU and CPU extensions and optimizations there, also reducing kernel size. Other experiments would need to be conducted with having drivers compiled as modules, since those modules are stripped prior of being added to modules.cpio and compressed there. We could load them directly from init, specifying them in board config, which could also play a role at knowing which drivers would be needed and pave the requirements to be able to determine in advance PCR measurements to precalculate PCRs to strengthen auditing and even provide expected TCPA log, and also provide inception and external validation of a firmware backup/downloaded ROM, extending what hashes.txt can do today. Addibg back libgfxinit and bootsplash whike still deprdning in i915drm will probably be the next step, and then moving away of DRM drivers packed in kernel for heads and be replaced by simplefb with fbwhiptail fixed to be able to play with it nicely. But in the meantime, bumping kernel to at least 5.10 serie is needed for all boards and ideal would be to share the same kernel version so that builds also happen faster for all boards, and for kernel configurations to be properly optimized with more eyes understanding what is happening there in the goal of having only needed options, and board deriving for what is special about them. Thanks for you input. If you are interested into helping into this let me know! Are you under Matrix? See community page and ping me there, you seem to know a thing or two about what could be going wrong! |
There is dasharo kgpe-d16 coreboot fork. |
The Dasharo port of recent Coreboot to the board suffers from faulty automatic fan control, where fans go to full speed and PWM statistics about them become unavailable. The bug occurs approximately 1/3 of the time for me. There is no apparent way to turn it off and it's not clear how it interacts with (working) fan control via openBMC. The last stable Coreboot for the board is 4.11, which is effectively four years old, and has numerous quirks which shan't be fixed, and it isn't fair to bother Coreboot developers about bugs in such an old code-base. I have suspicions that if using the 3mdeb jumper, ground will be shorted to VCC, assuming that the board's WP pin is pulled to VCC. I do not know of any schematics, so this assumption could be wrong, and the adaptor may be safe to use. Thus I built my own adaptor which breaks out the pins albeit with WP not extending down to the board. |
@druimalban : WP is supposed to be pulled to GND per https://docs.dasharo.com/variants/asus_kgpe_d16/spi-wp/ which is what is implemented with jumper and sold at https://shop.3mdeb.com/shop/adapters/flash-chip-adapters/asus-kgpe-d16-flash-chip-adapter/ I would advise into creating a separate issue to track issues you have with kgpe-d16 on dasharo github issues https://github.com/Dasharo/dasharo-issues/issues. I had forgotten about your post here until I needed to come back to the issue at stake and read your post a while ago but since it was irrelevant to issue at stake here, I didn't reply immediately and then it got forgotten. |
|
Playing around with #1381 getting it to merge, I came up with another oneliner really useful to get to really know the size of everything being packed into the kernel. Some small notes: Heads builds linux/coreboot in subdirs corresponding to directory name of the linux config file of a board, not in the linux extracted dir. This is the right way, since everything for an arch being compiled as artifacts with musl-cross-make can then be reused in CircleCI to make other boards reuse compiled artifacts without the need fo make distclean or any other cleaning which would require to recompiled everything, not just what differs from one board config to the other through linux config files. I decided to take a look at current local state of tweaks and built the really now limited t520-maximized board: Yes... 879140 on the empty CBFS space means we have 0.8mb left of SPI space. Not so bad still when we consider that that board has 8mb SPI. Current experiments tweaking linux-x230-maximized.config used to build kernel 5.10.5, exerpt: |
2 tasks
17 tasks
|
So we got rid of i915drm and freed 500kb in kernel switching to efifb! What next can be reduced? |
|
Also note that each builds produce sizes.txt for easier comparison for a while now. So it's easy to test changes for size comparison across builds to help the continual quest for firmware footprint reduction |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hello guys/gals
There is tickets opened to:
CONFIG_LINUX_E1000E=nin board config liberates 295688 bytes. @merge : Is that enough?The priorities should be, see below for binaries/libraries footprints:
EDIT: one liner to decompress and differenciate builds space
To help in finding consumed space, here is what I do.
find . -type f -ls | sort -r -n -k7The text was updated successfully, but these errors were encountered: