Add more detailed maintainer notes under README.md (oldconfig->defconfig->oldconfig)

[tlaurion]

Discussed off channel (again) :

As of today, both linux and coreboot configs under config/* are kept as oldconfigs.
Helpers were added under both modules/linux and modules/coreboot to switch from oldconfig<->defconfig.

Those helpers can be used through:

• make BOARD=BOARD (coreboot/linux).save_in_defconfig_format_in_place
• make BOARD=BOARD (coreboot/linux).modify_and_save_oldconfig_in_place

Why we currently keep configs as oldconfig:

• switching from oldconfig (in tree) to defconfig is currently helpful to spot the deviations against upstream used fork defconfig (the upstream default)
• doing a version bump and then using modify_and_save_oldconfig_in_place helper will show all configs changes through git diff

---

Real life example to show importance #1723 showed:

• Switching back to defconfig for nv41 currently used coreboot fork shows:

user@localhost:~/heads$ cat config/coreboot-nitropad-nv41.config 
CONFIG_USE_OPTION_TABLE=y
CONFIG_BOOTSPLASH_IMAGE=y
CONFIG_BOOTSPLASH_FILE="@BRAND_DIR@/bootsplash.jpg"
CONFIG_BOOTSPLASH_CONVERT=y
CONFIG_BOOTSPLASH_CONVERT_QUALITY=90
CONFIG_VENDOR_NOVACUSTOM=y
CONFIG_MAINBOARD_VERSION="v2.1"
CONFIG_CBFS_SIZE=0x1000000
# CONFIG_CONSOLE_SERIAL is not set
# CONFIG_POST_IO is not set
CONFIG_MAINBOARD_SMBIOS_MANUFACTURER="Nitrokey"
CONFIG_MAINBOARD_SMBIOS_PRODUCT_NAME="Nitropad NV41"
CONFIG_IFD_BIN_PATH="3rdparty/dasharo-blobs/novacustom/nv4x_adl/descriptor.bin"
CONFIG_ME_BIN_PATH="3rdparty/dasharo-blobs/novacustom/nv4x_adl/me.bin"
CONFIG_CONSOLE_CBMEM_BUFFER_SIZE=0x20000
CONFIG_HAVE_IFD_BIN=y
CONFIG_BOARD_NOVACUSTOM_NV4X_ADLP=y
CONFIG_TPM_MEASURED_BOOT=y
CONFIG_LINUX_COMMAND_LINE="quiet loglevel=2"
CONFIG_POWER_STATE_OFF_AFTER_FAILURE=y
CONFIG_IFDTOOL_DISABLE_ME=y
CONFIG_HAVE_ME_BIN=y
CONFIG_INTEL_ME_DISABLED_HAP=y
CONFIG_BOOTSPLASH=y
CONFIG_PCIEXP_HOTPLUG_PREFETCH_MEM_BELOW_4G=y
CONFIG_PCIEXP_HOTPLUG_IO=0x2000
# CONFIG_RESOURCE_ALLOCATION_TOP_DOWN is not set
CONFIG_PAYLOAD_LINUX=y
CONFIG_PAYLOAD_FILE="@BOARD_BUILD_DIR@/bzImage"
CONFIG_LINUX_INITRD="@BOARD_BUILD_DIR@/initrd.cpio.xz"

• As per xx20/xx30/qemu q35/xx4x : coreboot 4.22.01 -> 24.02.01 VERSION BUMP + defconfig unification to oldconfig #1723 unification attempt, it was thought that # CONFIG_RESOURCE_ALLOCATION_TOP_DOWN is not set should be enabled instead.
• Enabling with 49e37e1 cause my nv41 to brick.
• 49e37e1 reverted changes back to master.

This shows that coreboot changes in defconfigs

• should be thorrougly tested by coreboot/heads forks maintainers (not Heads job)
• changes in oldconfig from version bumps also need to be reviewed and thoroughly tested
• unification of changes as per xx20/xx30/qemu q35/xx4x : coreboot 4.22.01 -> 24.02.01 VERSION BUMP + defconfig unification to oldconfig #1723 attempt cannot happen without risks

[JonathonHall-Purism]

Every time I do a coreboot update, I do the following

• convert oldconfig to defconfig on the old coreboot version
• update coreboot
• convert defconfig back to oldconfig

My boards virtually always are best off reflecting changes to defaults in upstream. So storing oldconfigs here is really not helpful, it introduces possible errors (e.g. Mini v2 recently changed the SoC selected to support both CML v1 and v2, I knew to check for this change in Heads because I did the upstream change too).

Having oldconfigs in tree was originally intended to allow easy comparison of the actual config values used for different boards. We could possibly address that by emitting the full configs in CI logs, so you don't have to build all the boards to see the oldconfigs.

It's true though that in the case above, taking the new default from coreboot caused a brick (I'm not sure of the details, but I do see the RESOURCE_ALLOCATION_TOP_DOWN defaults flapping a bit in the history).

I think though that more often, we do want to take the defaults. In the same update, several other changes to configs were needed (https://github.com/linuxboot/heads/pull/1723/commits - see commit history) - I don't think anybody has checked whether those changes reflect the new defaults or not. In other words, would most of those commits have been unnecessary if we were storing defconfigs?

That's where I am on this. Next round of coreboot updates, I think we should try comparing both approaches.

[tlaurion]

Caused brick and build issues : removing Intel Wi-Fi support bricked dasharo coreboot fork nv41 and ns50 and needed urgent commit #1735

[tlaurion]

Some progress on this under #2039

we added yet another helper under modules/coreboot

coreboot.save_in_defconfig_format_backup target that runs savedefconfig
and saves the result as .config_defconfig alongside the original .config file