Change board name from nitropad-nv41 -> novacustom_nv4x_adl

[tlaurion]

See commit log 0b8f7e5 to make sure the changes are compatible.

• board name OK?
• board name under board config OK?
• strings in coreboot config OK? edit: waiting approval of Change board name from nitropad-nv41 -> novacustom_nv4x_adl #1793 (comment) analysis and dmidecode provided output @pietrushnic
• rebranding process clear enough? edit: notes taken Change board name from nitropad-nv41 -> novacustom_nv4x_adl #1793 (comment), issue opened for docs Improve rebranding docs at https://osresearch.net/Distributions/#branding heads-wiki#166
• Oppositions? Suggestions?
• merge

This is a follow up on agreed board name change from #1662 (comment) discussions.

NS50 not sold by Novacustom: only applies to nitropad-nv41 renaming. Suggestions welcome.

---

Notes:

• @miczyg1 Nitrokey boards coreboot version bump to match Dasharo+Heads heads+ coreboot version used in their v0.9.0 - 2024-02-29 BOM #1662 (comment) still bad default for CONFIG_TPM_PIRQ=0x0
• @pietrushnic Nitrokey boards coreboot version bump to match Dasharo+Heads heads+ coreboot version used in their v0.9.0 - 2024-02-29 BOM #1662 (comment) needs to be confirmed ok in this PR changes (board names, final strings in coreboot rom etc for firmware updates and whatnot compatibilities)
• @pietrushnic Nitrokey boards coreboot version bump to match Dasharo+Heads heads+ coreboot version used in their v0.9.0 - 2024-02-29 BOM #1662 (comment) : are the branding relationships fixed politically? code rebanding example at 7c0833f applied on top of Nitrokey boards coreboot version bump to match Dasharo+Heads heads+ coreboot version used in their v0.9.0 - 2024-02-29 BOM #1662 is all that is needed for now.
• @Wessel confirmed ok to change name at Nitrokey boards coreboot version bump to match Dasharo+Heads heads+ coreboot version used in their v0.9.0 - 2024-02-29 BOM #1662 (comment)
• @jans23 questioned future approach of maintainership of (Heads) at Nitrokey boards coreboot version bump to match Dasharo+Heads heads+ coreboot version used in their v0.9.0 - 2024-02-29 BOM #1662 (comment). As of now I own a nv41 given by Novacustom, and I test the changes on it, where Dasharo maintains the coreboot port and where Novacustom+Dasharo+Heads has revenue sharing agreement.
  • From my understanding, Nitropad maintainership of Heads is now limited into applying a similar patch to what they applied when they do releases 7c0833f
    • Note that https://github.com/Nitrokey/heads/tree/nitropad-release-v2.5.0 is one commit ahead of the fork of Heads used for that release; this means rebranding of PR Nitrokey boards coreboot version bump to match Dasharo+Heads heads+ coreboot version used in their v0.9.0 - 2024-02-29 BOM #1662 with above commit. To be honest, rebranding, IMHO can be improved, but is already pretty straightforward and as stated in previous discussion points, nv41 being branded to Novacustom is logical.

Last comment on which this PR acts upon: #1662 (comment) on which I clarified this PR being needed at #1662 (comment) without any answer.

--

This historical situation will be used in my QubesOS mini-summit last talk (discussion): https://cfp.3mdeb.com/qubes-os-summit-2024/talk/HL9MSV/ as the main example of upstream/downstream versioning, cooperation/collaboration to better the process for the future and clarify expectations of all parties.

Points:

• Heads is rolling release. The more bug opened upstream, the more fixes are done early.
  • If Heads upstream results in early beta tests downstream (from users wanting new Heads features, pushing downstream for releases), those would result in more issues opened upstreamed and less bugs when downstream do releases on top of a Heads commit they select in their release automated testing.
  • Those beta releases should result in more upstream rolling releases (downloadable and flashable through traditional internal flashing from Heads users) in PR, more eyes, more bugs found, more fixes and better UX in downstream forks and releases.

Thoughts welcome here. No issue raised, no fixes. Then users complaining downstream.

---

Ideal process would be (my proposition).

Actual board offerings (sold downstream):

• Issues should be raised upstream for a Heads commit ID (system information clear on this, less clear with downstream builds: mapping of downstream release hides Heads master used commit ID. Fix: point users into BOM, or me having clear mapping of commits from downstream BOM to upstream Heads commit ID. Not a problem but could be optimized process)
• Issues raised downstream should result in issues opened upstream and closed downstream. BOM releated Heads commit ID ideally should be referred in opened upstream issue opened from downstream issue closed.
• Collaboration should happen upstream, not downstream: a PR should close upstream issue, and downstream issue should show that upstream issue is closed, leading to downstream issue also be closed.
  • Issues closed upstream will result in testable PR artifacts, tested to fix issue.
• Issue closed upstream -> downstream means that PR fixed the issue, and should eventually result in a new beta build downstream, linking to closed upstream/downstream issues in BOM.

New board offering from downstream:

• Once coreboot+UEFI is functional, start collaboration for coreboot+heads upstream
  • Open WiP PR where collaboration can happen to make things testable, leading to rolling release testable builds from CircleCI, leading to issues opened/closed until satisfaction of rolling release
  • Once rolling release is satisfying, open beta builds to be testable by early adopters ddownstream
    • Same process as above for next steps.

[tlaurion]

@pietrushnic prioritize accordingly please.
Note presence of https://github.com/linuxboot/heads/labels/release%20cycle tag.

[tlaurion]

@macpijan ping :)
Even more important considering users think nv41 is valid for many gens, where Heads (and downstream forks) should be clear about this board to be Alder lake only (nv4x_adl).

Please comment on anything preventing this to go forward for so long in actionnable items. I cannot be clearer i'm afraid, then in OP.

[tlaurion]

@macpijan ping. Would be needed as base for newer novacustom port of Heads, including verification of strings and identification needed for dts/future fwupd compatibility.

[tlaurion]

Rebasing on master

[tlaurion]

@macpijan ping for checking BOARD_NAME and review coreboot string for board references prior of #1821
Refer to OP please.

[tlaurion]

ping @pietrushnic

[pietrushnic]

@tlaurion, what is my expected action? I am trying to understand why the naming convention is mixed with your Qubes OS Summit talk and your vision of the relationship between downstream and upstream. Maybe we should have separate threads for separate topics.

[tlaurion]

See commit log 0b8f7e5 to make sure the changes are compatible.

• board name OK?
• board name under board config OK?
• strings in coreboot config OK?
• rebranding process clear enough?
• Oppositions? Suggestions?

This is a follow up on agreed board name change from #1662 (comment) discussions.

NS50 not sold by Novacustom: only applies to nitropad-nv41 renaming. Suggestions welcome.

Actions items are check marks in OP @pietrushnic, quoted in this message.Rest is historical traces.

You answered off channel you would want nv41 to be novacustom-nv41_adl. That resolves the first checkmark. I will change board name accordingly.

[macpijan]

@mkopec Have you double checked that this is the same we have had in previous Dasharo + heads release?

[mkopec]

I missed it, no, it should be v2.1 as it was

[tlaurion]

@mkopec @macpijan :
Right. reference config https://github.com/Dasharo/coreboot/blob/3a9aa3a4692f3dd49732f5b4e3ec54be385f0969/configs/config.novacustom_nv4x_adl also changes LOCALVERSION to 1.7.2:

--- a/config/coreboot-novacustom_nv4x_adl.config
+++ b/config/coreboot-novacustom_nv4x_adl.config
@@ -7,7 +7,7 @@
 # General setup
 #
 CONFIG_COREBOOT_BUILD=y
-CONFIG_LOCALVERSION=""
+CONFIG_LOCALVERSION="v1.7.2"
 CONFIG_CBFS_PREFIX="fallback"
 CONFIG_COMPILER_GCC=y
 # CONFIG_COMPILER_LLVM_CLANG is not set
@@ -111,7 +111,7 @@ CONFIG_VENDOR_NOVACUSTOM=y
 # CONFIG_VENDOR_UP is not set
 CONFIG_MAINBOARD_FAMILY="Not Applicable"
 CONFIG_MAINBOARD_PART_NUMBER="nv40pz"
-CONFIG_MAINBOARD_VERSION="nv40pz"
+CONFIG_MAINBOARD_VERSION="v2.1"
 CONFIG_MAINBOARD_DIR="clevo/adl-p"
 CONFIG_DIMM_MAX=4
 CONFIG_DIMM_SPD_SIZE=512

[tlaurion]

user@localhost:~/heads$ grep BIOS modules/coreboot
CONFIG_COREBOOT_SMBIOS_PRODUCT_NAME ?= $(BOARD)
	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; \

[jans23]

Board renaming is ok for me.

[pietrushnic]

@tlaurion I see nothing about the rebranding process, so it's hard to take action on that. Other things seem to be technical, which IIUC has already approved here by the 3mdeb team.

[tlaurion]

@tlaurion I see nothing about the rebranding process, so it's hard to take action on that. Other things seem to be technical, which IIUC has already approved here by the 3mdeb team.

@pietrushnic OP #1793 (comment):

• Note that https://github.com/Nitrokey/heads/tree/nitropad-release-v2.5.0 is one commit ahead of the fork of Heads used for that release; this means rebranding of PR Nitrokey boards coreboot version bump to match Dasharo+Heads heads+ coreboot version used in their v0.9.0 - 2024-02-29 BOM #1662 with above commit.

This master...Nitrokey:heads:nitropad-release-v2.5.0#diff-1aa063ec528a5753e685e3e8c0d35336015074f1746351e1a221b177e999f622 points to site-local/config which is example of rebranding process. Something missing/unclear?

[pietrushnic]

Something missing/unclear?

I expect documentation on how new OEMs can brand whatever Heads supported hardware today. I get a hash showing the application of branding-related configurations, IIUC. If it works, I'm very happy, but I cannot test it nor imagine the result of such branding and how it is exposed to users. Also, I need to find out how other brands are in the pipeline, what part of SMBIOS is preserved, and what is dropped. If there is a new OEM in the Heads ecosystem, we need a path to follow instead of just linking to an implementation commit from which it is hard to decode what is what if you are not the Heads developer. I'm not Heads developer, so I'm trying to understand that at the business level. Heads should welcome not only new users but also new OEMs.

[tlaurion]

Something missing/unclear?

I expect documentation on how new OEMs can brand whatever Heads supported hardware today. I get a hash showing the application of branding-related configurations, IIUC. If it works, I'm very happy, but I cannot test it nor imagine the result of such branding and how it is exposed to users. Also, I need to find out how other brands are in the pipeline, what part of SMBIOS is preserved, and what is dropped. If there is a new OEM in the Heads ecosystem, we need a path to follow instead of just linking to an implementation commit from which it is hard to decode what is what if you are not the Heads developer. I'm not Heads developer, so I'm trying to understand that at the business level. Heads should welcome not only new users but also new OEMs.

@pietrushnic

• Docs: https://osresearch.net/Distributions/#branding is where the documentatiion is now, without anyone having opened an issue. No issue, docs considered ok.
• SMBIOS:

user@localhost:~/heads$ grep BIOS modules/coreboot
CONFIG_COREBOOT_SMBIOS_PRODUCT_NAME ?= $(BOARD)
	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; \

Which is OP's

strings in coreboot config OK?

Which was asked elsewhere (in historical traces pointed...) without answers yet. If no issue was raised, no comment done when/where pinged, then I consider current implementation and overrides to be ok until an issue/pr is opened about it? I ping you when those changes happen: No answers to me means ok, until an issue opened means not ok.

[tlaurion]

@pietrushnic so per reference config in dasharo fork, this is one of the SMBIOS strings dasharo configured.

@macpijan please confirm valid.

[tlaurion]

user@localhost:~/heads$ grep BIOS modules/coreboot
CONFIG_COREBOOT_SMBIOS_PRODUCT_NAME ?= $(BOARD)
	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; \

[tlaurion]

@pietrushnic pretty sure you don't want the manufacturer to be Notebook, but you tell me.
Nitrokey overrided this to Nitrokey which this PR changes and is part of the string I asked numerous tims to review for the sake of DTS/DMIDECODE/FWUPD and other things depending of those strings, those strings changes that would break if we are not careful.

This come from Dasharo fork's reference config, and what coreboot fork's defconfig (vs oldconfig resulting of defconfig) results in Notebook as per that release: https://github.com/Dasharo/coreboot/blob/3a9aa3a4692f3dd49732f5b4e3ec54be385f0969/configs/config.novacustom_nv4x_adl

[mkopec]

Notebook is correct. Those are the strings in Insyde firmware, and they have to match in Dasharo so that Windows autoinstalls the drivers that Clevo uploaded to Windows Update :(

I suppose it's not a big concern for Heads but I think they should match the UEFI firmware variant. fwupd also includes this SMBIOS string when looking for updates

[pietrushnic]

I asked numerous tims to review

This part was not needed.

---

@tlaurion, as @mkopec said, Dasharo (coreboot+UEFI) is concerned because of drivers delivered by Windows Update. fwupd uses the same mechanics, but if Novacustom or Nitrokey register in LVFS or Dasharo Team starts its instance, we could leverage that for much simpler updates. We will cross that bridge when we get there. Premature optimization is the root of all evil, so I would treat it as a no-op now.

Only when we can describe to OEMs precisely how to set that up to leverage LVFS can we create rules around that; without these tests and documentation, we should leave it as close to upstream as possible. If OEMs need to adjust that for some reason, we should also give them that freedom unless we can explain the implications for integration, which has not existed so far.

The impact of DTS does not belong to this repository and to this issue, IMHO. @mkopec, can you create an issue for DTS and determine how BOARD will impact DTS by assigning the problem to someone from Zarhus Team? Ideally, deliverables would be guidelines for naming conventions that do not break the way DTS works. Maybe we should mimic NV41 Dasharo (coreboot+Heads) behavior. Please note that the goal is to support both Novacustom and Nitrokey devices in Dasharo (coreboot+Heads).

[tlaurion]

@pietrushnic so per reference config in dasharo fork, this is one of the SMBIOS strings dasharo configured.

@macpijan please confirm valid.

[tlaurion]

user@localhost:~/heads$ grep BIOS modules/coreboot
CONFIG_COREBOOT_SMBIOS_PRODUCT_NAME ?= $(BOARD)
	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; \

[tlaurion]

dmidecode provides Product Name: novacustom_nv4x_adl as per #1793 (comment)

[tlaurion]

Rebranding logic:

• Proper strings in coreboot config under Heads tree if no rebranding considered possible for those from Dasharo or
• BOARD name must be defined (board config) to match strings expected by downstream (fwupd requirements etc) BECAUSE
• Logic under modules/coreboot only overrides if NOT specified under .config put under coreboot build dir

---

Logic of all this was added a while ago, discussed a lot at multiple places, one example being #1662 (comment).

If defined under coreboot config, rebranding logic DOES NOT APPLY:

heads/modules/coreboot

Lines 115 to 119 in cd683b1

	# coreboot builds are specialized on a per-target basis.
	# The builds are done in a per-target subdirectory
	CONFIG_COREBOOT_CONFIG ?= config/coreboot-$(BOARD).config
	CONFIG_COREBOOT_LOCALVERSION ?= "$(BRAND_NAME)-$(HEADS_GIT_VERSION)"
	CONFIG_COREBOOT_SMBIOS_PRODUCT_NAME ?= $(BOARD)

heads/modules/coreboot

Lines 142 to 148 in cd683b1

	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; \

---

This is why I say its politic:

• if we say coreboot fork defines those strings: all good, rebranding DOES NOT affect SMBIOS strings and dmidecode etc
• if we say downstream should have impact on SMBIOS strings, then those MUST NOT BE DEFINED uder coreboot config so BOARD in board config overrides the strings.

Are we all clear?
Let me know what needs to change @macpijan @pietrushnic @mkopec

Edit: opened linuxboot/heads-wiki#166 so that what was still unclear today is part of rebranding doc there. Please comment there for docs and here for strings needing to change in this PR before merge. PR approved but not really... see #1793 (comment) which led to last commit pushed 6746058

[tlaurion]

So per latest commit of this PR 6746058

this is dmidecode output (qubes' dom0) on my nv41 flashed with it, analysis at end of this comment:

(1)$ sudo dmidecode 
# dmidecode 3.4
Getting SMBIOS data from sysfs.
SMBIOS 3.0 present.
20 structures occupying 1024 bytes.
Table at 0x76991040.

Handle 0x0000, DMI type 0, 26 bytes
BIOS Information
	Vendor: 3mdeb
	Version: Dasharo Heads-v0.2.0-2419-g9df69d9
	Release Date: 01/01/1970
	ROM Size: 32 MB
	Characteristics:
		PCI is supported
		PC Card (PCMCIA) is supported
		BIOS is upgradeable
		Selectable boot is supported
		ACPI is supported
		Targeted content distribution is supported
	BIOS Revision: 0.2
	Firmware Revision: 0.0

Handle 0x0001, DMI type 1, 27 bytes
System Information
	Manufacturer: Notebook
	Product Name: novacustom_nv4x_adl
	Version: v2.1
	Serial Number: 123456789
	UUID: Not Settable
	Wake-up Type: Power Switch
	SKU Number: Not Applicable
	Family: Not Applicable

Handle 0x0002, DMI type 2, 14 bytes
Base Board Information
	Manufacturer: Notebook
	Product Name: novacustom_nv4x_adl
	Version: v2.1
	Serial Number: 123456789
	Asset Tag: Not Specified
	Features: None
	Location In Chassis: Not Specified
	Chassis Handle: 0x0003
	Type: Motherboard

Handle 0x0003, DMI type 3, 22 bytes
Chassis Information
	Manufacturer: Notebook
	Type: Notebook
	Lock: Not Present
	Version: Not Specified
	Serial Number: Not Specified
	Asset Tag: Not Specified
	Boot-up State: Safe
	Power Supply State: Safe
	Thermal State: Safe
	Security Status: None
	OEM Information: 0x00000000
	Height: Unspecified
	Number Of Power Cords: 1
	Contained Elements: 0
	SKU Number: Not Specified

Handle 0x0004, DMI type 4, 48 bytes
Processor Information
	Socket Designation: CPU0
	Type: Central Processor
	Family: Pentium Pro
	Manufacturer: GenuineIntel
	ID: A3 06 09 00 FF FB EB BF
	Signature: Type 0, Family 6, Model 154, Stepping 3
	Flags:
		FPU (Floating-point unit on-chip)
		VME (Virtual mode extension)
		DE (Debugging extension)
		PSE (Page size extension)
		TSC (Time stamp counter)
		MSR (Model specific registers)
		PAE (Physical address extension)
		MCE (Machine check exception)
		CX8 (CMPXCHG8 instruction supported)
		APIC (On-chip APIC hardware supported)
		SEP (Fast system call)
		MTRR (Memory type range registers)
		PGE (Page global enable)
		MCA (Machine check architecture)
		CMOV (Conditional move instruction supported)
		PAT (Page attribute table)
		PSE-36 (36-bit page size extension)
		CLFSH (CLFLUSH instruction supported)
		DS (Debug store)
		ACPI (ACPI supported)
		MMX (MMX technology supported)
		FXSR (FXSAVE and FXSTOR instructions supported)
		SSE (Streaming SIMD extensions)
		SSE2 (Streaming SIMD extensions 2)
		SS (Self-snoop)
		HTT (Multi-threading)
		TM (Thermal monitor supported)
		PBE (Pending break enabled)
	Version: 12th Gen Intel(R) Core(TM) i7-1260P
	Voltage: 0.8 V
	External Clock: 100 MHz
	Max Speed: 4700 MHz
	Current Speed: 2500 MHz
	Status: Populated, Enabled
	Upgrade: <OUT OF SPEC>
	L1 Cache Handle: 0x0006
	L2 Cache Handle: 0x0007
	L3 Cache Handle: 0x0008
	Serial Number: Not Specified
	Asset Tag: Not Specified
	Part Number: Not Specified
	Core Count: 8
	Core Enabled: 8
	Thread Count: 16
	Characteristics:
		Hardware Thread
		Execute Protection
		Enhanced Virtualization

Handle 0x0005, DMI type 7, 27 bytes
Cache Information
	Socket Designation: CACHE1
	Configuration: Enabled, Not Socketed, Level 1
	Operational Mode: Unknown
	Location: Internal
	Installed Size: 384 kB
	Maximum Size: 384 kB
	Supported SRAM Types:
		Unknown
	Installed SRAM Type: Unknown
	Speed: Unknown
	Error Correction Type: Unknown
	System Type: Data
	Associativity: 12-way Set-associative

Handle 0x0006, DMI type 7, 27 bytes
Cache Information
	Socket Designation: CACHE1
	Configuration: Enabled, Not Socketed, Level 1
	Operational Mode: Unknown
	Location: Internal
	Installed Size: 256 kB
	Maximum Size: 256 kB
	Supported SRAM Types:
		Unknown
	Installed SRAM Type: Unknown
	Speed: Unknown
	Error Correction Type: Unknown
	System Type: Instruction
	Associativity: 8-way Set-associative

Handle 0x0007, DMI type 7, 27 bytes
Cache Information
	Socket Designation: CACHE2
	Configuration: Enabled, Not Socketed, Level 2
	Operational Mode: Unknown
	Location: Internal
	Installed Size: 2560 kB
	Maximum Size: 2560 kB
	Supported SRAM Types:
		Unknown
	Installed SRAM Type: Unknown
	Speed: Unknown
	Error Correction Type: Unknown
	System Type: Unified
	Associativity: Unknown

Handle 0x0008, DMI type 7, 27 bytes
Cache Information
	Socket Designation: CACHE3
	Configuration: Enabled, Not Socketed, Level 3
	Operational Mode: Unknown
	Location: Internal
	Installed Size: 18 MB
	Maximum Size: 18 MB
	Supported SRAM Types:
		Unknown
	Installed SRAM Type: Unknown
	Speed: Unknown
	Error Correction Type: Unknown
	System Type: Unified
	Associativity: 12-way Set-associative

Handle 0x0009, DMI type 11, 5 bytes
OEM Strings
	String 1: EC: open-source
	String 2: EC firmware version: 2023-12-08_2b2c17a

Handle 0x000A, DMI type 16, 23 bytes
Physical Memory Array
	Location: System Board Or Motherboard
	Use: System Memory
	Error Correction Type: None
	Maximum Capacity: 128 GB
	Error Information Handle: Not Provided
	Number Of Devices: 2

Handle 0x000B, DMI type 17, 40 bytes
Memory Device
	Array Handle: 0x000A
	Error Information Handle: Not Provided
	Total Width: 64 bits
	Data Width: 64 bits
	Size: 32 GB
	Form Factor: SODIMM
	Set: None
	Locator: Channel-0-DIMM-0
	Bank Locator: BANK 0
	Type: DDR4
	Type Detail: Unknown Synchronous
	Speed: 3200 MT/s
	Manufacturer: Kingston
	Serial Number: d9275738
	Asset Tag: Channel-0-DIMM-0-AssetTag
	Part Number: 9905744-111.A00G
	Rank: 2
	Configured Memory Speed: 3200 MT/s
	Minimum Voltage: 1.2 V
	Maximum Voltage: 1.2 V
	Configured Voltage: 1.2 V

Handle 0x000C, DMI type 17, 40 bytes
Memory Device
	Array Handle: 0x000A
	Error Information Handle: Not Provided
	Total Width: 64 bits
	Data Width: 64 bits
	Size: 32 GB
	Form Factor: SODIMM
	Set: None
	Locator: Channel-0-DIMM-0
	Bank Locator: BANK 0
	Type: DDR4
	Type Detail: Unknown Synchronous
	Speed: 3200 MT/s
	Manufacturer: Kingston
	Serial Number: d927571c
	Asset Tag: Channel-0-DIMM-0-AssetTag
	Part Number: 9905744-111.A00G
	Rank: 2
	Configured Memory Speed: 3200 MT/s
	Minimum Voltage: 1.2 V
	Maximum Voltage: 1.2 V
	Configured Voltage: 1.2 V

Handle 0x000D, DMI type 19, 31 bytes
Memory Array Mapped Address
	Starting Address: 0x00000000000
	Ending Address: 0x00FFFFFFFFF
	Range Size: 64 GB
	Physical Array Handle: 0x000A
	Partition Width: 2

Handle 0x000E, DMI type 20, 35 bytes
Memory Device Mapped Address
	Starting Address: 0x00000000000
	Ending Address: 0x007FFFFFFFF
	Range Size: 32 GB
	Physical Device Handle: 0x000B
	Memory Array Mapped Address Handle: 0x000D
	Partition Row Position: Unknown
	Interleave Position: Unknown
	Interleaved Data Depth: Unknown

Handle 0x000F, DMI type 20, 35 bytes
Memory Device Mapped Address
	Starting Address: 0x00800000000
	Ending Address: 0x00FFFFFFFFF
	Range Size: 32 GB
	Physical Device Handle: 0x000B
	Memory Array Mapped Address Handle: 0x000D
	Partition Row Position: Unknown
	Interleave Position: Unknown
	Interleaved Data Depth: Unknown

Handle 0x0010, DMI type 32, 11 bytes
System Boot Information
	Status: No errors detected

Handle 0x0011, DMI type 41, 11 bytes
Onboard Device
	Reference Designation: VGA compatible controller
	Type: Video
	Status: Enabled
	Type Instance: 0
	Bus Address: 0000:00:02.0

Handle 0x0012, DMI type 133, 5 bytes
OEM-specific Type
	Header and Data:
		85 05 12 00 01
	Strings:
		KHOIHGIUCCHHII

Handle 0x0013, DMI type 127, 4 bytes
End Of Table

Analysis:

• LOCALVERSION overriden by Heads to Version: Dasharo Heads-v0.2.0-2419-g9df69d9
• Manufacturer: Notebook
• Product Name: novacustom_nv4x_adl
• Version: v2.1
• Serial Number: 123456789

To my eyes, we have a merge unless opposition.

---

Please +1 this and this will resolve pending comments saying this output is as expected.
Op's checklist updated. This is how I work, suggestions to the process (not smooth enough) to be under new issues, not here.

@mkopec @macpijan @pietrushnic : awaiting +1 to this comment, resolving pending comments of review, and 1 review approval by stakeholder, and I merge.

[pietrushnic]

Dasharo Heads-v0.2.0-2419-g9df69d9

@mkopec @macpijan, I guess we will override it anyway for the release version we publish.

[pietrushnic]

Docs: https://osresearch.net/Distributions/#branding is where the documentatiion is now, without anyone having opened an issue. No issue, docs considered ok.

This is the first time I have seen it. It is short, very concrete, and doesn't seem to impact anything. I don't feel I can exercise that document right now, but we can do that whenever a new OEM appears and see how many problems they will have with customization and understanding the flow.

[tlaurion]

Dasharo Heads-v0.2.0-2419-g9df69d9

@mkopec @macpijan, I guess we will override it anyway for the release version we publish.

You can override LOCALVERSION and everything else referred above with Makefile parts responsible for it as described technically at #1793 (comment).

[tlaurion]

Merge @pietrushnic ?

Waiting for approval of dmidecode output at #1793 (comment)

[tlaurion]

Docs: https://osresearch.net/Distributions/#branding is where the documentatiion is now, without anyone having opened an issue. No issue, docs considered ok.

This is the first time I have seen it. It is short, very concrete, and doesn't seem to impact anything. I don't feel I can exercise that document right now, but we can do that whenever a new OEM appears and see how many problems they will have with customization and understanding the flow.

Exercising this document practically is this comment example of how Nitrokey override chosen Heads commit + rebranding at #1793 (comment) as long as those are not part of the coreboot config.

Purism do the same. Dowstream are examples of how this is accomplished in practice and yes, docs can improve with feedback/PR.

I would love to move this forward without saying more words, if that is possible. Waiting for approval for merge.

[pietrushnic]

Merge @pietrushnic ?

It has to be approved by @mkopec or @macpijan, if already provided approval is not enough.

[mkopec]

Product Name: novacustom_nv4x_adl

Looks different to what we have in UEFI:

Handle 0x0001, DMI type 1, 27 bytes
System Information
	Manufacturer: Notebook
	Product Name: NV4xPZ
	Version: v2.1
	Serial Number: 123456789
	UUID: Not Settable
	Wake-up Type: Power Switch
	SKU Number: Not Applicable
	Family: Not Applicable

but from what I understand from #1793 (comment) this is not an issue, so LGTM

[tlaurion]

So if changes needs to be made upstream for strings to be the same as UEFI, that's gonna be proposed in separate PR.

[tlaurion]

Reviewing other stuff makes me realize LOCALVERSION should be = brandname otherwise getting default, see
https://github.com/linuxboot/heads/pull/1522/files#diff-323e0d751cc3cd35f5604f3ee75de1cb96fe0370b03aeec4c69ad4b0919a2027R24

Edit: it is. Fixing for Talos-2 and linuxboot(unmaintained) under #1848 (unrelated)