Open tlaurion opened 2 years ago
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.
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
:make BOARD=x230-flash
cp -rl ~/heads/build/linux-4.14.62/ ~/heads/build/linux-4.14.62-rl
cp ~/heads/config/linux-x230-flash.config ~/heads/build/linux-4.14.62-rl/.config
cd ~/heads/build/linux-4.14.62-rl/
make menuconfig
~/heads/build/linux-4.14.62-rl/.config
4.14.62
to5.10.4
cd ~/heads/ && make BOARD=x230-flash
cp -rl ~/heads/build/linux-5.10.4 ~/heads/build/linux-5.10.4-hl
cp ~/heads/build/linux-4.14.62-rl/.config ~/heads/build/linux-5.10.4-hl/.config
cd ~/heads/build/linux-5.10.4-hl/
make menuconfig
. Exit and save.cp ~/heads/build/linux-5.10.4-hl/.config ~/heads/build/linux-5.10.4-hl/.config_ported_from_4.14.64
meld/diff/whatever ~/heads/build/linux-4.14.62-rl/.config ~/heads/build/linux-5.10.4-hl/.config
~/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.iodiff/meld/whatever ~/heads/build/linux-5.10.4-hl/.config ~/heads/build/linux-5.10.4-hl/.config_ported_from_4.14.64
cp ~/heads/build/linux-5.10.4-hl/.config ~/heads/build/linux-5.10.4-hl/.config_removed_networking-debug_symbols-unused_crypto_digests
cp ~/heads/build/linux-5.10.4-hl/.config ~/heads/config/linux-x230-flash.config
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.cd ~/heads/build/linux-5.10.4-hl/
make savedefconfig
cp ~/heads/build/linux-5.10.4-hl/defconfig ~/heads/config/linux-x230-flash.config
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.