heads
heads copied to clipboard
Nitrokey boards coreboot version bump to match Dasharo+Heads heads+ coreboot version used in their v0.9.0 - 2024-02-29 BOM
Based on #1640 + coreboot config changes, Makefile and modules/coreboot changes made downstream in Dasharo+heads branch in commit as can be seen in this snapshot made today: https://archive.is/zYFbU#selection-6978.0-6984.0
Cherry-picked (and resolved conflicts) from relevant commits from referred BOM's
- Head used commit https://github.com/Dasharo/heads/tree/ccf49703
- coreboot used commit https://github.com/Dasharo/coreboot/tree/3a9aa3a4
@daringer please don't let this bitrot and report from testing laptops:
- [x] nv41 (@tlaurion: no regression outside of smaller bootplash, not anymore resized and faster showing actually)
- [ ] ns50
Important changes to review here:
- coreboot configs
- module/coreboot version bump
- ~needed patches/ for nitrokey fork gone (need to be crafted again unless merged under dasharo's coreboot fork)~ EDIT: no more usage of nitrokey's coreboot fork nor patches. Actually the directory of clevo patches is gone under patches/*
Don't try https://github.com/linuxboot/heads/commit/4417b6e8c67333dbd652113f0b3fbcb654eeee41 I bricked the nv41
@miczyg1 I had to cherry-pick your commits, but also resolve conflicts. You see anything wrong with what I did? Co-signed.
@daringer @alex-nitrokey : tested fa7ec37 against nv41 and was no regression.
Note that this changes the size of the bootsplash to be left alone (not resized) as per rebranding. For heads default logo, its now being showed without seeing the refresh happening with GOP vs libgfxinit, the later exposing the fb when filled as opposed to GOP writing it to screen as it goes.
So here is the result: smaller, centered. I guess your bootplash will do the same per downstream heads config.
I also modified ns50 to have the same behavior (untested):
@miczyg1
Some diff present between coreboot configs of nv41/ns50:
user@heads-tests-deb12:~/heads$ diff -u config/coreboot-nitropad-ns50.config config/coreboot-nitropad-nv41.config
--- config/coreboot-nitropad-ns50.config 2024-05-05 12:13:14.099007563 -0400
+++ config/coreboot-nitropad-nv41.config 2024-05-05 12:12:06.386003933 -0400
@@ -110,7 +110,7 @@
# CONFIG_VENDOR_TI is not set
# CONFIG_VENDOR_UP is not set
CONFIG_MAINBOARD_FAMILY="Not Applicable"
-CONFIG_MAINBOARD_PART_NUMBER="ns50pu"
+CONFIG_MAINBOARD_PART_NUMBER="nv40pz"
CONFIG_MAINBOARD_VERSION="v2.1"
CONFIG_MAINBOARD_DIR="clevo/adl-p"
CONFIG_DIMM_MAX=4
@@ -128,7 +128,7 @@
CONFIG_DEVICETREE="devicetree.cb"
# CONFIG_VBOOT is not set
CONFIG_VBOOT_VBNV_OFFSET=0x28
-CONFIG_VARIANT_DIR="ns50pu"
+CONFIG_VARIANT_DIR="nv40pz"
CONFIG_OVERRIDE_DEVICETREE="variants/$(CONFIG_VARIANT_DIR)/overridetree.cb"
# CONFIG_VGA_BIOS is not set
CONFIG_MAINBOARD_SMBIOS_MANUFACTURER="Nitrokey"
@@ -139,11 +139,11 @@
CONFIG_CMOS_LAYOUT_FILE="src/mainboard/$(MAINBOARDDIR)/cmos.layout"
CONFIG_BOOT_DEVICE_SPI_FLASH_BUS=0
CONFIG_BOARD_CLEVO_ADLP_COMMON=y
-CONFIG_BOARD_CLEVO_NS50PU_BASE=y
-CONFIG_MAINBOARD_SMBIOS_PRODUCT_NAME="Nitropad NS51"
+CONFIG_BOARD_CLEVO_NV40PZ_BASE=y
+CONFIG_MAINBOARD_SMBIOS_PRODUCT_NAME="Nitropad NV41"
CONFIG_CONSOLE_POST=y
# CONFIG_USE_PM_ACPI_TIMER is not set
-CONFIG_TPM_PIRQ=0x27
+CONFIG_TPM_PIRQ=0x0
# CONFIG_SOC_INTEL_CSE_SEND_EOP_EARLY is not set
CONFIG_VBOOT_FWID_VERSION="$(CONFIG_LOCALVERSION)"
CONFIG_EC_SYSTEM76_EC_BAT_THRESHOLDS=y
@@ -158,8 +158,8 @@
CONFIG_HAVE_INTEL_FIRMWARE=y
CONFIG_MRC_SETTINGS_CACHE_SIZE=0x10000
CONFIG_DRIVERS_INTEL_WIFI=y
-CONFIG_IFD_BIN_PATH="3rdparty/dasharo-blobs/novacustom/ns5x_adl/descriptor.bin"
-CONFIG_ME_BIN_PATH="3rdparty/dasharo-blobs/novacustom/ns5x_adl/me.bin"
+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_VBT_DATA_SIZE_KB=9
CONFIG_CARDBUS_PLUGIN_SUPPORT=y
@@ -176,8 +176,8 @@
#
# Alder Lake P (2022)
#
-CONFIG_BOARD_NOVACUSTOM_NS5X_ADLP=y
-# CONFIG_BOARD_NOVACUSTOM_NV4X_ADLP is not set
+# CONFIG_BOARD_NOVACUSTOM_NS5X_ADLP is not set
+CONFIG_BOARD_NOVACUSTOM_NV4X_ADLP=y
#
# Tiger Lake U (2021)
@@ -503,6 +503,7 @@
#
CONFIG_EC_ACPI=y
CONFIG_EC_SYSTEM76_EC=y
+CONFIG_EC_SYSTEM76_EC_DGPU=y
#
# Intel Firmware
@@ -603,7 +604,7 @@
CONFIG_INTEL_GMA_ADD_VBT=y
# CONFIG_SOFTWARE_I2C is not set
CONFIG_I2C_TRANSFER_TIMEOUT_US=500000
-CONFIG_RESOURCE_ALLOCATION_TOP_DOWN=y
+# CONFIG_RESOURCE_ALLOCATION_TOP_DOWN is not set
# end of Devices
#
@@ -614,13 +615,10 @@
# CONFIG_ELOG is not set
CONFIG_CACHE_MRC_SETTINGS=y
CONFIG_MRC_SETTINGS_PROTECT=y
-CONFIG_SMMSTORE=y
-# CONFIG_SMMSTORE_V2 is not set
-CONFIG_SMMSTORE_SIZE=0x40000
+# CONFIG_SMMSTORE is not set
CONFIG_SPI_FLASH=y
CONFIG_BOOT_DEVICE_SPI_FLASH_RW_NOMMAP=y
CONFIG_BOOT_DEVICE_SPI_FLASH_RW_NOMMAP_EARLY=y
-CONFIG_SPI_FLASH_SMM=y
# CONFIG_SPI_FLASH_NO_FAST_READ is not set
CONFIG_TPM_INIT_RAMSTAGE=y
# CONFIG_TPM_PPI is not set
TODO:
- [ ] review that SMBIOS is good (important if we go fwupd path)
- [ ] make sure branding works as expected (local overrides can be seen on dasharo side, which cherry-picks neglected)
Flashed and works on nv41 https://github.com/linuxboot/heads/commit/5d7a66b40281d190aaad2d244c2bd0c2cc80ded4
@nestire @alex-nitrokey please test and approve. Note that this pr is based on prior pr + upstreaming novacustom coreboot release of Dasharo heads 0.9 of February.
Delay of upstreaming and syncing with novacustom is way too long.
@miczyg1 I had to cherry-pick your commits, but also resolve conflicts. You see anything wrong with what I did? Co-signed.
LGTM, hope I didn't mess up anything in these commits I made. Thank you for picking them up... It was supposed to go back to main repo...
-CONFIG_TPM_PIRQ=0x27 +CONFIG_TPM_PIRQ=0x0
This looks suspicious though.
@tlaurion
g5d7a66b is not working on ns50
I flashed it internally and externally
the laptop is turning on (green DEL + turning fan) but the screen remains black
@tlaurion
g5d7a66b is not working on ns50
I flashed it internally and externally
the laptop is turning on (green DEL + turning fan) but the screen remains black
@alexgithublab please review and test changes of 07dd373
-CONFIG_TPM_PIRQ=0x27 +CONFIG_TPM_PIRQ=0x0
This looks suspicious though.
@miczyg1 indeed. What should it be? And why is it that value from defconfig?
@miczyg1 I had to cherry-pick your commits, but also resolve conflicts. You see anything wrong with what I did? Co-signed.
@miczyg1 I do not know what would be the best process here. As discussed many times in the past, since you guys downstream apply changes, they should be in a branch and propose a PR upstream and when both succeed, merged and used in releases. Otherwise it creates a maintenance burden and a mess in the future, needing to fix cherry-picks, rebsasing and losing track of unique commits that should be the same. Those are all bad practices.
I am not sure of what is the best way now and forward for this, both technically and politically. This creates a really big mess under Heads/Novacustom/Nitrokey issues, user experience problems and created issues blaming either of the forks or upstream for things having been fixed upstream outside of the coreboot parts.
More collaboration is indeed needed.
@miczyg1 the branding part of code under modules/coreboot is two folded, and then exposed through SMBIOS:
CONFIG_COREBOOT_LOCALVERSION ?= "$(BRAND_NAME)-$(HEADS_GIT_VERSION)"
CONFIG_COREBOOT_SMBIOS_PRODUCT_NAME ?= $(BOARD)
Then
$(coreboot_module)_configure := \
mkdir -p "$(build)/$(coreboot_dir)"; \
$(call install_config,$(pwd)/$(CONFIG_COREBOOT_CONFIG),$(build)/$(coreboot_dir)/.config); \
sed -i '/^CONFIG_LOCALVERSION/d' $(build)/$(coreboot_dir)/.config; \
echo 'CONFIG_LOCALVERSION=$(CONFIG_COREBOOT_LOCALVERSION)' >> $(build)/$(coreboot_dir)/.config; \
sed -i '/^CONFIG_MAINBOARD_SMBIOS_PRODUCT_NAME/d' $(build)/$(coreboot_dir)/.config; \
echo 'CONFIG_MAINBOARD_SMBIOS_PRODUCT_NAME="$(CONFIG_COREBOOT_SMBIOS_PRODUCT_NAME)"' >> $(build)/$(coreboot_dir)/.config; \
if [ ! -z "$(CONFIG_COREBOOT_SMBIOS_MANUFACTURER)" ]; then \
sed -i '/^CONFIG_MAINBOARD_SMBIOS_MANUFACTURER/d' $(build)/$(coreboot_dir)/.config; \
echo 'CONFIG_MAINBOARD_SMBIOS_MANUFACTURER="$(CONFIG_COREBOOT_SMBIOS_MANUFACTURER)"' >> $(build)/$(coreboot_dir)/.config; \
fi; \
$(MAKE) olddefconfig \
-C "$(build)/$(coreboot_base_dir)" \
obj="$(build)/$(coreboot_dir)" \
DOTCONFIG="$(build)/$(coreboot_dir)/.config" \
BUILD_TIMELESS=1 \
CFLAGS_x86_32="$(EXTRA_FLAGS)" \
CFLAGS_x86_64="$(EXTRA_FLAGS)" \
Is that desired? If one goes through "Heads System Information" as of today (07dd373)for both Nitrokey and Novacustom boards, the result would be based on:
user@heads-tests-deb12:~/heads$ grep -Rn -e CONFIG_MAINBOARD_SMBIOS_MANUFACTURER -e LOCALVERSION build/x86/coreboot-dasharo/nitropad-nv41/.config
10:CONFIG_LOCALVERSION="Heads-v0.2.0-2104-g07dd373"
134:CONFIG_MAINBOARD_SMBIOS_MANUFACTURER="Nitrokey"
148:CONFIG_VBOOT_FWID_VERSION="$(CONFIG_LOCALVERSION)"
@tlaurion the idea behind these changes is to let site-local override the aforementioned SMBIOS fields.
If CONFIG_COREBOOT_LOCALVERSION and CONFIG_COREBOOT_SMBIOS_PRODUCT_NAME are not defined in the environment, the previous behavior is supposed to be preserved (?=
will set these variables if they do not exist)
Example of site-local override of these values: https://github.com/Dasharo/heads/blob/master/site-local/config
The sed commands are supposed to remove existing CONFIG_LOCALVERSION and CONFIG_MAINBOARD_SMBIOS_MANUFACTURER in the coreboot's config file and place the new entries accordingly when coreboot module is configured: https://github.com/Dasharo/heads/commit/4d0c7a12f3fafcae9dcb6cd1572a107983875676 It is done to ensure there are no duplicate CONFIG_* entries.
-CONFIG_TPM_PIRQ=0x27 +CONFIG_TPM_PIRQ=0x0
This looks suspicious though.
Ohh that may be our fault. There is no setting for nv4x: https://github.com/Dasharo/coreboot/blob/38215f5a2bb3ea8ead10bf9c481caeb07d3a19ad/src/mainboard/clevo/adl-p/Kconfig#L118
-CONFIG_TPM_PIRQ=0x27 +CONFIG_TPM_PIRQ=0x0
This looks suspicious though.
Ohh that may be our fault. There is no setting for nv4x: https://github.com/Dasharo/coreboot/blob/38215f5a2bb3ea8ead10bf9c481caeb07d3a19ad/src/mainboard/clevo/adl-p/Kconfig#L118
@miczyg1 will force that on both boards.
-CONFIG_TPM_PIRQ=0x27 +CONFIG_TPM_PIRQ=0x0
This looks suspicious though.
Ohh that may be our fault. There is no setting for nv4x: https://github.com/Dasharo/coreboot/blob/38215f5a2bb3ea8ead10bf9c481caeb07d3a19ad/src/mainboard/clevo/adl-p/Kconfig#L118
@miczyg1 will force that on both boards.
Thanks, the pin for TPM_PIRQ is the some for both boards, so it will be good.
-CONFIG_TPM_PIRQ=0x27 +CONFIG_TPM_PIRQ=0x0
This looks suspicious though.
Ohh that may be our fault. There is no setting for nv4x: https://github.com/Dasharo/coreboot/blob/38215f5a2bb3ea8ead10bf9c481caeb07d3a19ad/src/mainboard/clevo/adl-p/Kconfig#L118
@miczyg1 will force that on both boards.
Thanks, the pin for TPM_PIRQ is the some for both boards, so it will be good.
@miczyg1 dont forget to add it in Kconfig for defconfig
Rebasing on master which now contains #1640
@miczyg1 please check notes on https://github.com/linuxboot/heads/pull/1662/commits/81cc5263a0898c36777eb0572d7816096466f66b
@daringer @jan23 @wessel-novacustom @pietrushnic @miczyg1 : Let's make this the last time that commits cherry-picked cannot be used as is so that board upstream under Heads match releases closely.
Please review asap. Note this comment directed at @miczyg1 https://github.com/linuxboot/heads/pull/1661#issuecomment-2103626778 which will require more work, and I want this nix PR to be merged soon so the work done here cherry-picking+ resolving conflicts+ rebasing will need to be redone, hopefully one last time (we all love a consistent git history, don't we?)
I would also suggest that Heads upstream is novacustom boards and nitrokey rebrands them as opposed to the other way around as currently, so that things can be upstreamed properly without delays that we see here right now and are unacceptable for whatever reason there is.
If all forks depend on a Heads commit which then depends on coreboot forks that are outdated, we don't do the ecosystem any service and raised issues are duplicated all around, upstream and downstream. I never agreed to this mess. Let's work better all together.
Whoever can review this please do this and approve this ASAP if it works according to expectations for that February release and fix, post commits I can cherry-pick against this branch and let's merge this.
@pietrushnic let me address this pragmatically. Change or no change?
Neither will solve the root cause since it is not a code issue. First resolve branding relations otherwise your implementation will not be used. coreboot to some extent has it addressed it is registered and for example, 3mdeb has signed documentation that explains how we can use the coreboot name. Similar documents exist for Linux and probably many other projects.
@miczyg1 please check notes on 81cc526
https://github.com/Dasharo/coreboot/commit/b35dc4a4f25497acfbe159d6abd057d885661a02
Ok, will go reviewing in code depth so we are all at the same page. 3a72920 merged master into this branch now compiling with nix buildstack
https://app.circleci.com/pipelines/github/tlaurion/heads/2567/workflows/6d4fcbae-4f60-4904-ac18-76f7ee1a1f9d/jobs/46281?invite=true#step-102-9464732_134:
36cce76d745e2265b2a7628feb897a4da671297701d427a2eadd28d426bb2c12 build/x86/nitropad-nv41/heads-nitropad-nv41-v0.2.0-2162-g3a72920.rom
Local:
36cce76d745e2265b2a7628feb897a4da671297701d427a2eadd28d426bb2c12 /home/user/heads/build/x86/nitropad-nv41/heads-nitropad-nv41-v0.2.0-2162-g3a72920.rom
@pietrushnic @miczyg1 @daringer to give an example of how we should collaborate here under Heads until releases https://github.com/linuxboot/heads/pull/1662/commits/41d55bf2fcf9337da5dac240050b54c3583584a7
Showing clearly patches that need to be cherry-picked for next releases to obtain desired behavior, whatever they are.
In this particular example, the TPM IRQ sticks as expected
user@heads-tests-deb12-nix:~/heads$ docker run -e DISPLAY=$DISPLAY --network host --rm -ti -v $(pwd):$(pwd) -w $(pwd) linuxboot/heads:dev-env -- make BOARD=nitropad-nv41 coreboot.modify_and_save_oldconfig_in_place
----------------------------------------------------------------------
!!!!!! BUILD SYSTEM INFO !!!!!!
System CPUS: 12
System Available Memory: 10201 GB
System Load Average: 3.18
----------------------------------------------------------------------
Used **CPUS**: 12
Used **LOADAVG**: 18
Used **AVAILABLE_MEM_GB**: 10201 GB
----------------------------------------------------------------------
**MAKE_JOBS**: -j12 --load-average=18
Variables available for override (use 'make VAR_NAME=value'):
**CPUS** (default: number of processors, e.g., 'make CPUS=4')
**LOADAVG** (default: 1.5 times CPUS, e.g., 'make LOADAVG=54')
**AVAILABLE_MEM_GB** (default: memory available on the system in GB, e.g., 'make AVAILABLE_MEM_GB=4')
**MEM_PER_JOB_GB** (default: 1GB per job, e.g., 'make MEM_PER_JOB_GB=2')
----------------------------------------------------------------------
!!!!!! Build starts !!!!!!
mkdir -p "/home/user/heads/build/x86/coreboot-dasharo/nitropad-nv41" && \
make menuconfig \
-C "/home/user/heads/build/x86/coreboot-dasharo" \
obj="/home/user/heads/build/x86/coreboot-dasharo/nitropad-nv41" \
DOTCONFIG="/home/user/heads/config/coreboot-nitropad-nv41.config"
make[1]: Entering directory '/home/user/heads/build/x86/coreboot-dasharo'
*** End of the configuration.
*** Execute 'make' to start the build or try 'make help'.
make[1]: Leaving directory '/home/user/heads/build/x86/coreboot-dasharo'
user@heads-tests-deb12-nix:~/heads$ git status
On branch nitrokey_board_unification_clean-enable_htop_validated_autoboot-novacustom_coreboot_version_bump
nothing to commit, working tree clean
@miczyg1 @pietrushnic @jan23 Now.
What I meant about the branding issues, having talked with @jans23, is that since the coreboot port, and heads testing for a picked heads commit is done through Dasharo, then the board under Heads tree should not be nitrokey-nv41 nor nitropkey-ns50 but novacustom-xyz as 3mdeb sees fit. They will offer dasharo subscriptions for next models and will compensate me for my time resolving their political/economical choices resulting in unpaid maintenance and testing I never agreed to do for free. Dasharo 0,0.9 for dasharo+heads last released was released on 2024-02-29 and Heads master is still pointing to https://github.com/linuxboot/heads/blob/70b3272b32375c291b3f59403c07643744475ff0/modules/coreboot#L94 which means commit of december 2023 https://github.com/Dasharo/coreboot/commit/1bcb338682b612cfcca8bba02846f78139b2e0c8 including all bugs that were fixed in coreboot and EC since that moment. This creates duplicates bugs under Heads/Nitrokey repo which were resolved for Novacustom users. This doesn;t make any sense. We need to switch Heads depending on Nitrokey maintained fork to Dasharo coreboot and have Heads borads be Novacustom boards on which Nitrokey will apply their release policies and own timelines as they please while Heads stays upstream and maintained.
This way, the basic branding would be politically right (clevo coreboot port is Dasharo maintained and paid by Novacustom afterall), the rebranding would be done by Nitrokey for their own releases, and this part of overrides will be applied to local rebranding of nitrokey in their fork if they decide to maintain one (why?).
This is politic, and can be changed in code.
@pietrushnic as of now, following the changes in this PR, the coreboot fork is dasharo as per co-authored (and messy cherry-picked commits that needed to be modified because they was not applicable under Heads because they bitrot)
So @jans23 @pietrushnic @miczyg1 your input is needed under https://github.com/linuxboot/heads/pull/1662/files#r1597164563
The only areas of discussions, to me, in this PR are
- [ ] https://github.com/linuxboot/heads/pull/1662/files#diff-18936189b28399cf48703d0c1ec1df33e57c559de2a12f4438be00e6813bdb68R139-R148
- [ ] Make sure we are confortable with now https://github.com/linuxboot/heads/pull/1661/commits/c7f652bf897faf2e4110806efd28d15e8a37d53c equivalent (which does the same thing + making sure blobs use relative paths finding the blobs from the building dir, not from / which WILL be different between OSes user account and casued coreboot to be different because of config in cbfs which was merged as part of #1661 )
- [ ] Accept that Heads boards in tree would now be novacustom, not nitropad and that nitrokey will apply the branding overrides in their fork. This basically means forking Heads for a Nitropad release, and apply local overrides as desired in a release branch. That's it.
- [ ] @pietrushnic @miczyg1 a path forward to resolve all this rebasing/cherry-pick mess that noone of us love to do and is absolutely disastrous and totally unmaintainable for ANY open source project. This is its normally contributed upstream and then upstream merged downstream, so the commit histroy is kept intact. Otherwise mihaps happen, its not a question of if, but when and what will be the impacts for end users. As I said here, https://github.com/linuxboot/heads/pull/1662/commits/41d55bf2fcf9337da5dac240050b54c3583584a7 is a clear example of how things should work. Just drop all the patches to be cherry-picked in a downstream release in that folder to be tested. And if all is good, cherry-pick those commits on top of downstream, provide upstream commit to remove those patchs + point modules/coreboot to the new commit including all those tested patches cherry-picked and that's it. To me its clean, simple, effective and permit people to understand what the heck is going on between upstream and downstream. Otherwise its pure chaos for everyone, and I didn't consent to nor am compensated in proper code nor money. The burden is too big for me to continue like that.
--
TLDR: let's move on and have Heads povide dasharo+heads novacustom boards and nitropad rebrand. Agreed?
If Nitrokey was the first to offer heads flashed to their devices, they depend on dasharo coreboot and now dasharo+heads to provide their laptops bought from novacustom. So can just agree that those are novacustoms rebranded clevo boards and have Heads be transparent about it, which will simplify all our workflows and prepare ourselves correctly for fwupd support? Yes?
@alexgithublab @daringer : Can you confirm ns50 nv41 work for you please with this branch?