Bump remaining 4.14 boards kernel to 5.10.5 (and coreboot to 4.19) #1381
Conversation
Kexec works without this patch on Legacy BIOS (I've tested this in QEMU with BIOS) but it won't work without this patch on UEFI-only system. |
|
@lankredotp41 I'm confused by your last comment
|
|
Maybe I'm confisung something myself since I still don't understand all internal workings. I've copied
If I use unpatched kexec 2.0.26 then system just reboots after executing unpatched kexec -d -l
If I use patched kexec 2.0.26 with ebda hack then I'm booting into Qubes OS 4.2 installer just fine: patched kexec -d -l
I've attached boot log of successful kexec into Qubes OS 4.2 installer with patched kexec. |
|
I've tested some more and found that kexec 2.0.26 works in QEMU with BIOS without ebda hack patch for multiboot2, but if I specify |
Moved boards to 5.10.5 kernel configs to not cause regression on crypto backend, both with cryptsetup and current gpg toolstack modules/linux added 5.10.178 but nothing migrated at this stage. modules/linux includes Android tethering modules to be packed when needed per board configs (maximized only) Kernel configs for x230 good to go. u-root module containing bases for using exp/tcz and wget (with only root ca module included) qemu kernel config includes changes needed to support CGROUPS and busybox upgraded and config changed to include adduser/addgroup/delgoup/deluser per determist/systems requirements, but still failing Makefile: adds packing of u-root under initrd if requested kexec patch still carries old multiboot patch. Not sure wasa good idea to remove since user could decide to use old default multiboot1 (default is now multiboot2 under kexec 2.0.26 under master) CircleCI changes revisioning to 4.19 (textual, not changing any behavior)
Moved boards to 5.10.5 kernel configs to not cause regression on crypto backend, both with cryptsetup and current gpg toolstack modules/linux added 5.10.178 but nothing migrated at this stage. modules/linux includes Android tethering modules to be packed when needed per board configs (maximized only) Kernel configs for x230 good to go. u-root module containing bases for using exp/tcz and wget (with only root ca module included) qemu kernel config includes changes needed to support CGROUPS and busybox upgraded and config changed to include adduser/addgroup/delgoup/deluser per determist/systems requirements, but still failing Makefile: adds packing of u-root under initrd if requested initrd/bin/tinycorePoC: requires manual activation of libraries under u-root module kexec patch still carries old multiboot patch. Not sure wasa good idea to remove since user could decide to use old default multiboot1 (default is now multiboot2 under kexec 2.0.26 under master) CircleCI changes revisioning to 4.19 (textual, not changing any behavior)
Moved boards to 5.10.5 kernel configs to not cause regression on crypto backend, both with cryptsetup and current gpg toolstack modules/linux added 5.10.178 but nothing migrated at this stage. modules/linux includes Android tethering modules to be packed when needed per board configs (maximized only) Kernel configs for x230 good to go. u-root module containing bases for using exp/tcz and wget (with only root ca module included) qemu kernel config includes changes needed to support CGROUPS and busybox upgraded and config changed to include adduser/addgroup/delgoup/deluser per determist/systems requirements, but still failing Makefile: adds packing of u-root under initrd if requested initrd/bin/tinycorePoC: requires manual activation of libraries under u-root module kexec patch still carries old multiboot patch. Not sure wasa good idea to remove since user could decide to use old default multiboot1 (default is now multiboot2 under kexec 2.0.26 under master) CircleCI changes revisioning to 4.19 (textual, not changing any behavior)
Moved boards to 5.10.5 kernel configs to not cause regression on crypto backend, both with cryptsetup and current gpg toolstack modules/linux added 5.10.178 but nothing migrated at this stage. modules/linux includes Android tethering modules to be packed when needed per board configs (maximized only) Kernel configs for x230 good to go. u-root module containing bases for using exp/tcz and wget (with only root ca module included) qemu kernel config includes changes needed to support CGROUPS and busybox upgraded and config changed to include adduser/addgroup/delgoup/deluser per determist/systems requirements, but still failing Makefile: adds packing of u-root under initrd if requested initrd/bin/tinycorePoC: requires manual activation of libraries under u-root module kexec patch still carries old multiboot patch. Not sure wasa good idea to remove since user could decide to use old default multiboot1 (default is now multiboot2 under kexec 2.0.26 under master) CircleCI changes revisioning to 4.19 (textual, not changing any behavior)
Moved boards to 5.10.5 kernel configs to not cause regression on crypto backend, both with cryptsetup and current gpg toolstack modules/linux added 5.10.178 but nothing migrated at this stage. modules/linux includes Android tethering modules to be packed when needed per board configs (maximized only) Kernel configs for x230 good to go. u-root module containing bases for using exp/tcz and wget (with only root ca module included) qemu kernel config includes changes needed to support CGROUPS and busybox upgraded and config changed to include adduser/addgroup/delgoup/deluser per determist/systems requirements, but still failing Makefile: adds packing of u-root under initrd if requested initrd/bin/tinycorePoC: requires manual activation of libraries under u-root module kexec patch still carries old multiboot patch. Not sure wasa good idea to remove since user could decide to use old default multiboot1 (default is now multiboot2 under kexec 2.0.26 under master) CircleCI changes revisioning to 4.19 (textual, not changing any behavior)
Moved boards to 5.10.5 kernel configs to not cause regression on crypto backend, both with cryptsetup and current gpg toolstack modules/linux added 5.10.178 but nothing migrated at this stage. modules/linux includes Android tethering modules to be packed when needed per board configs (maximized only) Kernel configs for x230 good to go. - Removed unneedead crypto support for ivy and sandy bridge (no AVX2, and AVX support needed only for AES (ctypestup is XTS-AES on most deployments) - removed CDROM support and SCSI support Note: those two commands are really useful to analyse in-kernel sizes. Summary, to dig down in directory reported as being biggest: user@heads-tests:~/heads/build/x86/linux-5.10.5/linux-x230-maximized$ for f in */built-in.a; do size -t $f | tail -1 | sed "s|(TOTALS)|$f|"; done | sort -nr Detailed view of biggest built-in components and objects linked: user@heads-tests:~/heads/build/x86/linux-5.10.5/linux-x230-maximized$ size -t $(find ./ -name built-in.a) | tail -n +2 | sort -n -r -k 4|less Then follow those amazing guides to axe/hammer kernel size: Axing: https://lwn.net/Articles/746780/ General: https://elinux.org/Kernel_Size_Tuning_Guide And analyse needs of each module/kernel config option: https://www.kernelconfig.io u-root module containing bases for using exp/tcz and wget (with only root ca module included) qemu kernel config includes changes needed to support CGROUPS and busybox upgraded and config changed to include adduser/addgroup/delgoup/deluser per determist/systems requirements, but still failing Makefile: adds packing of u-root under initrd if requested initrd/bin/tinycorePoC: requires manual activation of libraries under u-root module kexec patch still carries old multiboot patch. Not sure wasa good idea to remove since user could decide to use old default multiboot1 (default is now multiboot2 under kexec 2.0.26 under master) CircleCI changes revisioning to 4.19 (textual, not changing any behavior)
Moved boards to 5.10.5 kernel configs to not cause regression on crypto backend, both with cryptsetup and current gpg toolstack modules/linux added 5.10.178 but nothing migrated at this stage. modules/linux includes Android tethering modules to be packed when needed per board configs (maximized only) Kernel configs for x230 good to go. - Removed unneedead crypto support for ivy and sandy bridge (no AVX2, and AVX support needed only for AES (ctypestup is XTS-AES on most deployments) Note: those two commands are really useful to analyse in-kernel sizes. Summary, to dig down in directory reported as being biggest: user@heads-tests:~/heads/build/x86/linux-5.10.5/linux-x230-maximized$ for f in */built-in.a; do size -t $f | tail -1 | sed "s|(TOTALS)|$f|"; done | sort -nr Detailed view of biggest built-in components and objects linked: user@heads-tests:~/heads/build/x86/linux-5.10.5/linux-x230-maximized$ size -t $(find ./ -name built-in.a) | tail -n +2 | sort -n -r -k 4|less Then follow those amazing guides to axe/hammer kernel size: Axing: https://lwn.net/Articles/746780/ General: https://elinux.org/Kernel_Size_Tuning_Guide And analyse needs of each module/kernel config option: https://www.kernelconfig.io u-root module containing bases for using exp/tcz and wget (with only root ca module included) qemu kernel config includes changes needed to support CGROUPS and busybox upgraded and config changed to include adduser/addgroup/delgoup/deluser per determist/systems requirements, but still failing Makefile: adds packing of u-root under initrd if requested initrd/bin/tinycorePoC: requires manual activation of libraries under u-root module kexec patch still carries old multiboot patch. Not sure wasa good idea to remove since user could decide to use old default multiboot1 (default is now multiboot2 under kexec 2.0.26 under master) CircleCI changes revisioning to 4.19 (textual, not changing any behavior)
Moved boards to 5.10.5 kernel configs to not cause regression on crypto backend, both with cryptsetup and current gpg toolstack modules/linux added 5.10.178 but nothing migrated at this stage. modules/linux includes Android tethering modules to be packed when needed per board configs (maximized only) Kernel configs for x230 good to go. - Removed unneedead crypto support for ivy and sandy bridge (no AVX2, and AVX support needed only for AES (ctypestup is XTS-AES on most deployments) - Added required crypto hash HMAC Note: those two commands are really useful to analyse in-kernel sizes. Summary, to dig down in directory reported as being biggest: user@heads-tests:~/heads/build/x86/linux-5.10.5/linux-x230-maximized$ for f in */built-in.a; do size -t $f | tail -1 | sed "s|(TOTALS)|$f|"; done | sort -nr Detailed view of biggest built-in components and objects linked: user@heads-tests:~/heads/build/x86/linux-5.10.5/linux-x230-maximized$ size -t $(find ./ -name built-in.a) | tail -n +2 | sort -n -r -k 4|less Then follow those amazing guides to axe/hammer kernel size: Axing: https://lwn.net/Articles/746780/ General: https://elinux.org/Kernel_Size_Tuning_Guide And analyse needs of each module/kernel config option: https://www.kernelconfig.io u-root module containing bases for using exp/tcz and wget (with only root ca module included) qemu kernel config includes changes needed to support CGROUPS and busybox upgraded and config changed to include adduser/addgroup/delgoup/deluser per determist/systems requirements, but still failing Makefile: adds packing of u-root under initrd if requested initrd/bin/tinycorePoC: requires manual activation of libraries under u-root module kexec patch still carries old multiboot patch. Not sure wasa good idea to remove since user could decide to use old default multiboot1 (default is now multiboot2 under kexec 2.0.26 under master) CircleCI changes revisioning to 4.19 (textual, not changing any behavior)
Moved boards to 5.10.5 kernel configs to not cause regression on crypto backend, both with cryptsetup and current gpg toolstack modules/linux added 5.10.178 but nothing migrated at this stage. modules/linux includes Android tethering modules to be packed when needed per board configs (maximized only) Kernel configs for x230 good to go. - Removed unneedead crypto support for ivy and sandy bridge (no AVX2, and AVX support needed only for AES (ctypestup is XTS-AES on most deployments) - Added required crypto hash HMAC Note: those two commands are really useful to analyse in-kernel sizes. Summary, to dig down in directory reported as being biggest: user@heads-tests:~/heads/build/x86/linux-5.10.5/linux-x230-maximized$ for f in */built-in.a; do size -t $f | tail -1 | sed "s|(TOTALS)|$f|"; done | sort -nr Detailed view of biggest built-in components and objects linked: user@heads-tests:~/heads/build/x86/linux-5.10.5/linux-x230-maximized$ size -t $(find ./ -name built-in.a) | tail -n +2 | sort -n -r -k 4|less Then follow those amazing guides to axe/hammer kernel size: Axing: https://lwn.net/Articles/746780/ General: https://elinux.org/Kernel_Size_Tuning_Guide And analyse needs of each module/kernel config option: https://www.kernelconfig.io u-root module containing bases for using exp/tcz and wget (with only root ca module included) qemu kernel config includes changes needed to support CGROUPS and busybox upgraded and config changed to include adduser/addgroup/delgoup/deluser per determist/systems requirements, but still failing Makefile: adds packing of u-root under initrd if requested initrd/bin/tinycorePoC: requires manual activation of libraries under u-root module kexec patch still carries old multiboot patch. Not sure wasa good idea to remove since user could decide to use old default multiboot1 (default is now multiboot2 under kexec 2.0.26 under master) CircleCI changes revisioning to 4.19 (textual, not changing any behavior)
Moved boards to 5.10.5, staging for 5.10.178 (LTS) kernel configs to not cause regression on crypto backend, both with cryptsetup and current gpg toolstack modules/linux added 5.10.178 but nothing migrated at this stage. modules/linux includes Android tethering modules to be packed when needed per board configs (maximized only) Kernel configs for x230 good to go. - Removed unneedead crypto support for ivy and sandy bridge (no AVX2, and AVX support needed only for AES (ctypestup is XTS-AES on most deployments) - Added required crypto hash HMAC Note: those two commands are really useful to analyse in-kernel sizes. Summary, to dig down in directory reported as being biggest: user@heads-tests:~/heads/build/x86/linux-5.10.5/linux-x230-maximized$ for f in */built-in.a; do size -t $f | tail -1 | sed "s|(TOTALS)|$f|"; done | sort -nr Detailed view of biggest built-in components and objects linked: user@heads-tests:~/heads/build/x86/linux-5.10.5/linux-x230-maximized$ size -t $(find ./ -name built-in.a) | tail -n +2 | sort -n -r -k 4|less Then follow those amazing guides to axe/hammer kernel size: Axing: https://lwn.net/Articles/746780/ General: https://elinux.org/Kernel_Size_Tuning_Guide And analyse needs of each module/kernel config option: https://www.kernelconfig.io u-root module containing bases for using exp/tcz and wget (with only root ca module included) qemu kernel config includes changes needed to support CGROUPS and busybox upgraded and config changed to include adduser/addgroup/delgoup/deluser per determist/systems requirements, but still failing Makefile: adds packing of u-root under initrd if requested initrd/bin/tinycorePoC: requires manual activation of libraries under u-root module kexec patch still carries old multiboot patch. Not sure wasa good idea to remove since user could decide to use old default multiboot1 (default is now multiboot2 under kexec 2.0.26 under master) CircleCI changes revisioning to 4.19 (textual, not changing any behavior)
tlaurion
force-pushed
the
xx20_xx30_kernel_510_bump
branch
from
400f71d
to
5379bfd
Compare
|
x230-maximized-fhd_edp works on my 1440p X230 without any apparent issues. |
|
Comparing t520-hotp-maximized (know spi limited) build logs for this pr against current master's Master's: PR's: master empty - pr empty = cost of current config kernel version bump |
|
As per current config on xx30 as opposed to removing it: Add around 1 second of boot time. It takes around 6 seconds between coreboot loading the kernel and jumping into it, and then between 2 to 6 seconds depending of kernel config. Testing things. |
|
Well, I'm not convinced on local tests of this branch as-is for newcomers to the project. But the delay before having a working display under Heads alone is increasing over time (the more the payload is heavy, the more it takes time to be read from slow SPI, and the more kernel security features slow down the kernel boot time). The reality unfolds to the following:
This is ~10 seconds before reaching to the graphic framebuffer initialized by the kernel alone. I've been experimenting with libgfxinit, which is imperfect (bootsplash jpeg code is 14 years old and requires old framebuffer sizes as of now: eg 1024x768 instead of 1366x768 required for x230), where fbwhiptail requires It would have been amazing that FB_SIMPLE would have been enough to drive FBWHIPTAIL, since the chicken egg problem here would have been resolved:
But. Since FBWHIPTAIL requires VSYNC ioctl which returns ENOTTY, we still need drm+i915 for the moment until fbwhiptail is adapted for this more generalized use case across all boards. PoC still is interesting:
Teaser from work that happened in my personal branch : Thoughts? Short version of the debate:
The reasoning on this is that reading from SPI is slow. The more we take space in flash, the more it takes time to read from SPI (cbmem log above showing jump to payload after 7-8 seconds), and relaying solely on kernel drivers to obtain full-fledged accelerated and feature rich framebuffer leaves the user blind until that happens. |
|
If I915 driver is present in heads it will initialize framebuffer anyways, right? Why not enable legacy VGA text mode with libgfxinit? Then you could print some strings on the screen, like "heads payload is loading" |
|
As a comparison to current x230-maximized rom from this PR at commit 5379bfd:
All things compared, both jumps inside of a working Heads payload under 10 seconds. The difference is on size and being let in the dark doing so. This is not a blocker for this PR itself alone, but might be a consideration for the future. Without libgfxinit, the user is currently left in the dark until drm+gpu is inititalized by the kernel. Putting this PR ready for review |
Yeah, this is not great. We have similar problems with memory training delays, users just assume it is not booting without waiting long enough. That's a longer delay (30-60 seconds, not every boot thank goodness), but 10 seconds is still uncomfortable IMO. We have to put our foot down somewhere.
This could be changed pretty easily, just tolerate ENOTTY from that ioctl instead of giving up. Result is just screen tearing, which isn't that bad on fbwhiptail. You would still need libgfxinit, but I think this would solve everything else (no DRM stack in kernel, so kernel is smaller, no double GFX init, early splash, probably no kexec hacks).
It sounds like this is worse on your boards than mine (which would make sense). Is there any chance that maybe dual I/O is not enabled in your IFD? On the off chance it isn't, it should give you a significant speedup. There's also quad mode (even better), but it has to be hooked up on the board and assumes you do not have any hardware write protect switch/jumper (the /WP pin is repurposed as an I/O). |
@miczyg1 The question here, sorry if that was left unclear, is with or without ligfxinit (which means depending on gnat/ada or not). Meaning leaving user in the dark while everything becomes ready without libgfxinit, or enabling libgfxinit and then why not, include a bootsplash (as shown under #1381 (comment)). Sorry for the confusion there! And thanks for challenging this! Edit: showing text/splashscreen at this point is irrelevant. People would prefer graphics then text, of course. Which is what is shown above for what, maybe 50kb including jpg and additional code to do it. |
|
Testing request under #1398. |
|
linux-x230-legacy.config removes net_core net_dev but keeps generic CONFIG_NET, which is required by crypto backend. Could be revisited next round of #590, things are getting externalized at each linux kernel version!
EDIT: Houla. Same story as with 4.14.x. I unselected CONFIG_NET. saved config in oldconfig and see what is automatically deactivated: |
…_LEAK_PHYS_SMEM=y It was impossible to use directly 4.14 defconfig and apply it to 5.10. Saving 4.14 in oldconfig, then editing in 5.10 was necessary. - E1000E module (as kernel module support...) was lost in conversion and needed to be added back. Also tuned things up: - legacy-flash has no RETPOLINE, no security policy at all. Has expected usb controllers modules, exFAT and bare minimal support for flashrom. - IMPORTANT: CONFIG_X86_IOPL_IOPERM kernel option is required by flashrom - legacy adds sata, retpoline, additional modules (ethernet), security policy related material on top of legacy-flash config - maximized adds MMC card support, mousedev+synaptic (to report presence through oem-system-info-xx30), thin provisioning+snapshot support - tuned with linux.prompt_for_new_config_options_for_kernel_version_bump Current storage format is oldconfig from now on for proper analysis. If needed, once can save back in defconfig prior of bumping to newer version.
…E=y for basic qemu-coreboot board config advanced qemu-coreboot-*-tpm*-* boards enables virtio qemu/kvm through command line option. qemu-coreboot-* (whiptail or fbwhiptail) basic boards are using bochs gpu emulation, provided through qemu linux-qemu.config, if shared as of now, needs to provide both virtio (no need of FB_SIMPLE because DRM) and BOCHS+SIMPLE_FB
…ments - add additional kernel boot params for i915 where needed: - adds : drm_kms_helper.drm_leak_fbdev_smem=1 i915.enable_fbc=0 ( to permit kexec into vesa fb of kexec'ed kernel for i915 driven gpus without framebuffer compression, leaking smem fbdev address for kexec to pickup )
…modate additioaally added DRM+FB for testing
…n oldconfig/defconfig formats both linux/coreboot: - save_in_defconfig_format_in_place : takes whatever coreboot config file for a make BOARD=xyz statement and saves it in defconfig - save_in_oldefconfig_format_in_place : takes whatever coreboot config file for a make BOARD=xyz statement and saves it in oldefconfig linux: - linux.prompt_for_new_config_options_for_kernel_version_bump: - The most useful helper as of now when doing kernel version bump. - Requires to save current kernel config in oldconfig (make BOARD=xyz linux.save_in_oldefconfig_format_in_place) first, then bump kernel version in board config and then use that helper to review new options and save in tree.
… same kernel versions and across versions kgpe-d16 linux configs: converted to oldconfig as well TODO: talos-2
qemu-coreboot-*-tpm* boards are way more feature rich to test/develops Heads
CONFIG_MCORE2=y CONFIG_RANDOM_TRUST_CPU=y
… requirements Remove CONFIG_NO_GFX_INIT from configs having CONFIG_NORTHBRIDGE_INTEL_SANDYBRIDGE=y Add CONFIG_BOOTSPLASH_IMAGE from configs having CONFIG_NORTHBRIDGE_INTEL_SANDYBRIDGE=y Add CONFIG_LINEAR_FRAMEBUFFER from configs having CONFIG_NORTHBRIDGE_INTEL_SANDYBRIDGE=y Set BOOTSPLASH parameters to match bootsplash and jpeg requirements +CONFIG_LINEAR_FRAMEBUFFER_MAX_HEIGHT=768 +CONFIG_LINEAR_FRAMEBUFFER_MAX_WIDTH=1024 +CONFIG_BOOTSPLASH=y Others paramaters defined per board default setting with coreboot.save_oldconfig_in_place helper
… config to x230 + fix vbt path
…l and reorgagnize per coreboot ver add coreboot 4.19 builddir into save_cache
… keeping important board related perks CONFIG_PREEMPT_NONE=y: Remove preemptiveness for servers. Under heads, we are single tasking. No point having this big thing in kernel https://lwn.net/Articles/746780/ IO scheduler: only enable CONFIG_MQ_IOSCHED_DEADLINE=y since we want maximum throughput and do not have concurrent tasks CONFIG_CPU_ISOLATION=y : Enable CPU Isolation accross all boards: this permits to make sure that the kernel tasks running on a CPU are not distrurbed bu user tasks CONFIG_MULTIUSER not defined: Removing cluttering since we are single root user under Heads anyway CONFIG_IO_URING=y : limit number of copy operations between kernel and user space from apps CONFIG_ZONE_DMA not defined: relevant for older hardware (less then 32bit addressing space) CONFIG_X86_MPPARSE not defined: relevant for older smp systems CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is enabled and SCHEDUTIL is disabled: we want performance with CPU sched with deadline IO. CONFIG_PERF_EVENTS_INTEL_UNCORE and CONFIG_PERF_EVENTS_INTEL_CSTATE not defined: we want max perf on Heads CONFIG_X86_VSYSCALL_EMULATION not defined: no need for syscall emulation under Heads CONFIG_SECCOMP not defined : usefull if BPF is enabled and used. CONFIG_ACPI_SPCR_TABLE=y : usefull for serial redirection table and earlycon CONFIG_PCI_MMCONFIG CONFIG_MMCONF_FAM10H unset but for kgpe-d16 which is either fam10h of fam15h CONFIG_DM_SNAPSHOT=y CONFIG_DM_THIN_PROVISIONING=y so that recovery shell can provide LVM/DM functionality in later PR. CONFIG_EXFAT_FS=y so that exfat preformated thumb drives can work out of the box Adjust CONFIG_HW_RANDOM per platform, removing CONFIG_HW_RANDOM_TIMERIOMEM Only support processor family needed per board (AMD only AMD, Intel only Intel, removing CONFIG_CPU_SUP_HYGON CONFIG_CPU_SUP_HYGON CONFIG_CPU_SUP_CENTAUR CONFIG_CPU_SUP_ZHAOXIN CONFIG_CPU_SUP_ZHAOXIN everywhere qemu: support both AMD and INTEL as an exception for the above. Removed unused compiled modules unpacked under modules.cpio Removed not needed crypto modules compiled in or as modules, reviewed from linuxboot#1396 (comment) : CONFIG_CRYPTO=y CONFIG_CRYPTO_ALGAPI=y CONFIG_CRYPTO_ALGAPI2=y CONFIG_CRYPTO_AEAD=y CONFIG_CRYPTO_AEAD2=y CONFIG_CRYPTO_SKCIPHER=y CONFIG_CRYPTO_SKCIPHER2=y CONFIG_CRYPTO_HASH=y CONFIG_CRYPTO_HASH2=y CONFIG_CRYPTO_RNG=y CONFIG_CRYPTO_RNG2=y CONFIG_CRYPTO_AKCIPHER2=y CONFIG_CRYPTO_KPP2=y CONFIG_CRYPTO_ACOMP2=y CONFIG_CRYPTO_MANAGER=y CONFIG_CRYPTO_MANAGER2=y CONFIG_CRYPTO_USER=y CONFIG_CRYPTO_MANAGER_DISABLE_TESTS=y CONFIG_CRYPTO_NULL=y CONFIG_CRYPTO_NULL2=y CONFIG_CRYPTO_CRYPTD=y CONFIG_CRYPTO_AUTHENC=y CONFIG_CRYPTO_SIMD=y CONFIG_CRYPTO_GLUE_HELPER_X86=y CONFIG_CRYPTO_CBC=y CONFIG_CRYPTO_ECB=y CONFIG_CRYPTO_XTS=y CONFIG_CRYPTO_ESSIV=y CONFIG_CRYPTO_HMAC=y CONFIG_CRYPTO_CRC32C=y CONFIG_CRYPTO_CRC32C_INTEL=y CONFIG_CRYPTO_MD5=y CONFIG_CRYPTO_SHA1=y CONFIG_CRYPTO_SHA1_SSSE3=y CONFIG_CRYPTO_SHA256_SSSE3=y CONFIG_CRYPTO_SHA512_SSSE3=y CONFIG_CRYPTO_SHA256=y CONFIG_CRYPTO_SHA512=y CONFIG_CRYPTO_AES_NI_INTEL=y CONFIG_CRYPTO_USER_API=y CONFIG_CRYPTO_USER_API_HASH=y CONFIG_CRYPTO_USER_API_SKCIPHER=y CONFIG_CRYPTO_USER_API_RNG=y CONFIG_CRYPTO_USER_API_AEAD=y CONFIG_CRYPTO_HASH_INFO=y CONFIG_CRYPTO_LIB_AES=y CONFIG_CRYPTO_LIB_SHA256=y
…ocompletion still works removal of qemu-coreboot board made autocomplete apparition of modules helpers vanish
…ke sure none locks
…g CONFIG_NET active (crypto need) Since legacy boards do not have e1000e as opposed to maximized builds (no network), we also deactivate: +# CONFIG_INET is not set +# CONFIG_ETHTOOL_NETLINK is not set +# CONFIG_NETDEVICES is not set This makes gpg24 and newer flashrom bump possible
tlaurion
force-pushed
the
xx20_xx30_kernel_510_bump
branch
from
dbac454
to
6245339
Compare
|
Ok time for comparisons!!!! Master last commit includes sizes.txt report. We will use t520-hotp-maximized sizes output step to compare cost of PR addition here. The raw output is available here. which we will use with diff to see what changed. |
|
Some analysis on above data. Reminders:
So in short:
|
…without dynticks and isolcpus
|
Removed CPU_ISOLATION from discussions under #1398 (comment) |
This PR brings a lot of cleanup to linux configs after bumping configs from 4.14 to 5.10.5, unifying those to easy compare boards across each other. Detailed changes:
Modules:
Linux configs:
coreboot configs:
Here: all boards have coreboot config modified to pass proper kernel options to Heads kernel to expose fb address needed by kexec patch and a non compressed fb buffer (i915 specific).
Tested: