Linux x230 cleanup

[tlaurion]

Addtion:

• MMC card reader

Removal:

• AMD related stuff
• Many network cards that were supported in kernel since last kernel version bump.
• CPU governers not linked to PERFORMANCE
• Random number generators not being TPM/Intel HW support
• DEBUG stuff

Tested on x230 i5:

• External flash of https://4367-103208611-gh.circle-artifacts.com/0/build/x230-flash/heads-x230-flash-v5.0.1-99-g065cbfd-top.rom
• Internal flash of local built x230-hotp-verification and x230-hotp-maximized which share this linux-x230.config file
• GPG OEM factory reset presented on boot.
• Qubes 4.0.4 ISO boot with detached signature. Got to the screen where installation options are given (past previous error given for virtualization extensions not being present which was x230 legacy board has qubeos report HAP/SLAT/EPT/RVD as missing #1107
• Qubes 4.1 ISO boot with detached signature file.

BTW: https://www.kernelconfig.io/ is an awesome resource to understand from where certain config options are activated and to deactivate the root cause of it in make menuconfig.

Some gain stats: Will be edited to compare

• Latest master commit build space usage summary x230 board:

Never write a complete coreboot.rom without an IFD to your
printf "board's flash chip! You can use flashrom's IFD or layout\n"
board's flash chip! You can use flashrom's IFD or layout
printf "parameters to flash only to the BIOS region.\n\n"
parameters to flash only to the BIOS region.

rm x230/util/cbfstool/fmd_scanner.c x230/util/cbfstool/fmd_parser.c
make[1]: Leaving directory '/root/project/build/coreboot-4.13'
2022-02-18 13:22:45-05:00 DONE coreboot
touch /root/project/build/coreboot-4.13/x230/.build 
# Use coreboot.rom, because custom output files might not be processed by cbfstool
"/root/project/build/coreboot-4.13/x230/cbfstool" "/root/project/build/coreboot-4.13/x230/coreboot.rom" print
FMAP REGION: COREBOOT
Name                           Offset     Type           Size   Comp
cbfs master header             0x0        cbfs header        32 none
fallback/romstage              0x80       stage           85100 none
cpu_microcode_blob.bin         0x14d80    microcode       26624 none
fallback/ramstage              0x1b600    stage           97694 none
config                         0x33400    raw               550 none
revision                       0x33680    raw               689 none
fallback/dsdt.aml              0x33980    raw             14615 none
vbt.bin                        0x37300    raw              1433 LZMA (4281 decompressed)
cmos_layout.bin                0x37900    cmos_layout      1884 none
fallback/postcar               0x380c0    stage           25816 none
fallback/payload               0x3e600    simple elf    6851527 none
(empty)                        0x6c7200   null           101272 none
bootblock                      0x6dfdc0   bootblock       65536 none

• This build space usage summary for x230 board:

FMAP REGION: COREBOOT
Name                           Offset     Type           Size   Comp
cbfs master header             0x0        cbfs header        32 none
fallback/romstage              0x80       stage           85100 none
fallback/ramstage              0x14d80    stage           97667 none
config                         0x2cb40    raw               584 none
revision                       0x2cdc0    raw               690 none
fallback/dsdt.aml              0x2d0c0    raw             14615 none
vbt.bin                        0x30a40    raw              1433 LZMA (4281 decompressed)
cmos_layout.bin                0x31040    cmos_layout      1884 none
fallback/postcar               0x31800    stage           25816 none
fallback/payload               0x37d40    simple elf    6547911 none
(empty)                        0x676740   null           431704 none
bootblock                      0x6dfdc0   bootblock       65536 none
2022-02-18 16:11:09-05:00 INSTALL   build/coreboot-4.13/x230/coreboot.rom => build/x230/heads-x230-v5.0.1-101-g048bae8.rom

So we have a net gain of 431704 - 101272 : 330432 just by removing unneeded stuff from the kernel. (431704 free bytes, 421kB)

For x230-hotp-maximized board as a comparative, we are now having 4669592 free bytes, 4.45MB left to add more important stuff).

Next steps:

• I won't play the game of re-adding FBWHIPTAIL in legacy boards and other previously removed modules, but this is a first step toward Quest to reduce firmware size #590 and going there if people are interested into maintaining Legacy boards.
• Next step would be to pass -O2 (optimize for space instead of performance) in all modules, as a configuration option or as a build option override.

@MrChromebox this is ready for review.

[tlaurion]

@MrChromebox not quite yet. I see a lot of discrepencies between x230-flash and x230. Will remove draft when done.

[tlaurion]

I think its time that linux config are stored in their full oldconfig output instead of make savedefconfig output format.
Its the main reason why kernel version bumps are not happening and kernel config changes are not easily traceable: there is no easy way to compare what changed between versions.

By storing into oldconfig format (output of make nconfig/menuconfig) the config files stored in github would be bigger, but could be used as a base for the next version bump directly, where comparing output of old kernel config version vs new kernel version should mostly directly show what are the new default to keep/deactivate.

[paulmenzel]

I think its time that linux config are stored in their full oldconfig output instead of makesavedefconfig.
Its the main reason why kernel version bumps are not happening.

Reading all the comments in the thread, I do not understand the motivation for your comment. Can you please elaborate?

[tlaurion]

I think its time that linux config are stored in their full oldconfig output instead of makesavedefconfig.
Its the main reason why kernel version bumps are not happening.

Reading all the comments in the thread, I do not understand the motivation for your comment. Can you please elaborate?

@paulmenzel Thanks for following up!

This was a note for me to take into account when i'm going to rebase this PR on master later on.

As stated above, if ones takes a look into config/linux* files kept under Heads repo (same for coreboot config files), they were historically requiring the maintainer to do a make savedefconfig into build/kernel-version directory prior of moving the resulting defconfig back into config/linux-board.config.

That config/linux-board.config being the result of make savedefconfig output doesn't make it clear to the end user nor maintainer of what modules were built-in, activated as modules or deactivated, unless that config was manually expended to audit for the kernel version it is intended for.

When it comes to version bumps, the same logic applies, requiring maintainer to expend that config by copying config/linux-board.config into build/kernel-old-version/.config and doing a make menuconfig to save that config into .config, and then copying that config into the build/kernel-new-version/.config to see what new kernel defaults are actually activated and start tuning of that kernel config to remove new defaults, doing a diff between old-kernel and new-kernel .config files.

Someone just taking config/linux-board.config and copying it under build/kernel-new-version/.config would have a lot of config options enabled by default which should not be there. That is what currently happens if someone just bumps the kernel version under modules/kernel. And currently, doing so will just not build, for above mentioned reasons. The defconfig output being stored in tree just keeping the derivation from the default config instructs to basically include all past and new defaults of the new kernel version built, creating a kernel that will be bloated and unusable, where tuning that kernel config requires from the user to restart from scratch for each kernel version bump. On top of that, I think Heads should be more transparent about the actual whole kernel configuration that is used.,

The short version of this is that if the idea of not storing full configurations under github was to optimize for size of what is contained under tree, the maintenance cost to do version bumps is not justifying it.

As seen here, by hiding the defaults and saving only deviations from the default config, we are hiding a lot of things that should be removed, including, as pointed in OP here, uneeded CPU governors, AMD support on Intel and a lot of other device drivers which are becoming activating on newer kernel version and for which a defconfig being used as a base for kernel version bumpwould just use those features by default and consume precious SPI storage because not removed.

I think its more logical to have full linux configs in tree, while conserving coreboot in savedefconfig format (and here, this is not my opinion for coreboot, but the agreed direction amongst Heads maintainers). In the goal of tackling #590, I think this is the logical first step.

@paulmenzel : any guidance on that level?