Notes on bumping kernels and coreboot to newer versions (or how to keep xx30-flash and legacy boards alive)

[tlaurion]

Should be under heads-wiki PR, but just wanted to dump it here first to empty my mind of the process I've been through recently.

Upgrading kernel/coreboot versions is somewhat a hassle. That is, when bumping one kernel version to another, just hoping that kept in tree saveddefconfig file under config/linux-board.config will just magically produce a small, minimal kernel simply doesn't work. In fact, the savedefconfig (defconfig) file kept in tree is just the deviation to the normal defconfig for a specific version. Each time a new coreboot/kernel version sees the light, it also comes with its own defconfig.

In the case of kernel defconfig, this means new settings being activated as modules and added in kernel by default.

So here is a couple of tricks I came with in the last years to facilitate others to also do this task, taking by example the actual 4.14 kernel used currently that is wished to be bumped to 5.10.4 for a while. For the community boards, that means two kernel configs to update: linux-x230.config (shared across all boards) and linux-x230-flash.config (being aimed at being really small, used in xx30-flash boards to accomplish internal flashing of their normal legacy roms counterpart which needs to have coreboot+kernel+modules fit under 4Mb SPI flash).

So basic steps, taking the x230-flash board as an example, taking for granted heads was cloned into ~/, so ~/heads and we are by default under ~/heads:

• Build for old version already in tree: make BOARD=x230-flash
• We will do a hardlinked copy (playable backup at no cost) of the linux build into another directory we want to experiment in: cp -rl ~/heads/build/linux-4.14.62/ ~/heads/build/linux-4.14.62-rl
• We copy the actual defconfig linux-x230-flash.config over hardlinked linux build directory: cp ~/heads/config/linux-x230-flash.config ~/heads/build/linux-4.14.62-rl/.config
• We go inside of the hardlinked linux build directory: cd ~/heads/build/linux-4.14.62-rl/
• We expend the configuration file so that we finally know what the deviation to default means for that kernel version: make menuconfig
• We save the changes there. Exit and save. We now have the full config file under ~/heads/build/linux-4.14.62-rl/.config
• We change the kernel version under the board config board/x230-flash/x230-flash.config being 4.14.62 to 5.10.4
• We rebuild x230-flash so that the new kernel is downloaded, patched and extracted: cd ~/heads/ && make BOARD=x230-flash
• We do a hardlinked copy of the newly extracted build directory so that we can play with it without touching the real linux build dir: cp -rl ~/heads/build/linux-5.10.4 ~/heads/build/linux-5.10.4-hl
• We copy the expended config of old kernel config over : cp ~/heads/build/linux-4.14.62-rl/.config ~/heads/build/linux-5.10.4-hl/.config
• We go inside that new kernel build directory: cd ~/heads/build/linux-5.10.4-hl/
• We generate a new complete configuration based on 4.14.62 full kernel config: make menuconfig. Exit and save.
• We take a copy of that "ported" 4.14.64 to 5.10.4 config to keep track of what we tuned: cp ~/heads/build/linux-5.10.4-hl/.config ~/heads/build/linux-5.10.4-hl/.config_ported_from_4.14.64
• We can now compare all the new stuff between the old and new kernel added defaults: meld/diff/whatever ~/heads/build/linux-4.14.62-rl/.config ~/heads/build/linux-5.10.4-hl/.config
• If we change the settings manually under ~/heads/build/linux-5.10.4-hl/.config,We make sure those are kept by a make menuconfig under that directory, and we review the changes. It is important to understand dependencies between Kconfig options. This website helps a lot: https://www.kernelconfig.io
• We compare the changes we enforced did since the beginning of the tuning effort: diff/meld/whatever ~/heads/build/linux-5.10.4-hl/.config ~/heads/build/linux-5.10.4-hl/.config_ported_from_4.14.64
• We keep track of interesting changes we were able to be kept saved after a make menuconfig: cp ~/heads/build/linux-5.10.4-hl/.config ~/heads/build/linux-5.10.4-hl/.config_removed_networking-debug_symbols-unused_crypto_digests
• When we are ready to test the changes, we copy over the working copy of .config file to what the build system expects to use for a board build: cp ~/heads/build/linux-5.10.4-hl/.config ~/heads/config/linux-x230-flash.config
• We rebuild the board: cd ~/heads && make BOARD=x230-flash and we cross fingers that all the build process will succeed into creating a small enough kernel to fit for the xx30-flash board config.
• When we are successful and the new board produced ROM boots (HURRAY!) we go back to our hardlinked linux build dir: cd ~/heads/build/linux-5.10.4-hl/
• We create a defconfig: make savedefconfig
• We copy it over where heads build system feeds on it: cp ~/heads/build/linux-5.10.4-hl/defconfig ~/heads/config/linux-x230-flash.config
• Then we redo the process for linux-x230.config!
• When all is good, we create a PR taking all the files we touched (includes all the board configs, linux-x230-flash.config, linux-x230.config, maybe modules/linux changes)
• We ask for review, and we debate what is really needed and what is not, since everything constantly changes in coreboot/kernel configs.

As a sidenote, I might start soon to redistribute full linux configurations as opposed to defconfig versions, as it once was under Heads repo, at least for linux configurations. This is way more clear, IMOH to see what we do not want (for the eyes) to make sure everything else in the same category in full config changes would need to be deactivated as well. Otherwise it is so easy to have AMD related Kconfig options on Intel based systems, have Network interface support included in the kernel boosting its size etc.

[tlaurion]

As a sidenote, I might start soon to redistribute full linux configurations as opposed to defconfig versions, as it once was under Heads repo, at least for linux configurations. This is way more clear, IMOH to see what we do not want (for the eyes) to make sure everything else in the same category in full config changes would need to be deactivated as well. Otherwise it is so easy to have AMD related Kconfig options on Intel based systems, have Network interface support included in the kernel boosting its size etc.

https://github.com/osresearch/heads/pull/1184 is first iteration of that in the goal of easily kernel bumping versions in the future, without the changes being opaque to anyone anymore.