boards: Add Star Labs Heads targets

[Sean-StarLabs]

Add Heads support for the Star Labs target set, continuing the original StarLite Mk V PR as a patch-per-board series.

Scope

• Pin Star Labs coreboot 26.07.1.
• Add the shared Star Labs configuration and compact profiles.
• Keep StarLite Mk V / Lite ADL as the existing CI-covered seed target.
• Add one signed commit per additional board target:
  • starlabs_qemu
  • starlabs_starbook_mtl
  • starlabs_starbook_adl
  • starlabs_starbook_adl_n
  • starlabs_starbook_rpl
  • starlabs_starbook_tgl
  • starlabs_labtop_cml
  • starlabs_labtop_kbl analysis target
  • starlabs_adl_horizon
  • starlabs_byte_adl
  • starlabs_byte_twl
  • starlabs_byte_cezanne
  • starlabs_starbook_cezanne
  • starlabs_lite_glk analysis target
  • starlabs_lite_glkr analysis target
  • starlabs_starfighter_mtl
  • starlabs_starfighter_rpl
• Add the Cezanne AMD input verifier and fTPM/TPM-log coreboot patches needed by the Cezanne targets.

Initial installation and recovery require board-appropriate external recovery access. For StarLite Mk V, the current recovery reference remains:
https://support.starlabs.systems/hc/star-labs/articles/starlite-mk-v-installingrecovering-firmware-with-external-programmer

The related vendor, porting and flashing documentation is under review in linuxboot/heads-wiki#222. The flashing page remains unpublished until this port is merged and hardware-tested.

Validation

• All continuation commits are GPG signed and carry Signed-off-by: Sean Rhodes <sean@starlabs.systems>.
• make -s BOARD=<target> echo_modules passed for every Star Labs target in this PR, including starlabs_lite_adl.
• Non-patch-file whitespace check passed with git diff --check ... -- . ':(exclude)patches/**'.
• The raw coreboot patch payload files are excluded from that whitespace check because patch context lines intentionally contain tabs and patch trailers; the existing patch files in this PR have the same property.
• Existing StarLite Mk V CI coverage is retained; GitHub checks will rerun on this updated branch.

Lite ADL porting checklist

• Successful external flash of the CircleCI build, recording the programmer model and voltage.
• Boots successfully after flashing.
• Setting-clock prompt behaves correctly after the initial flash and CMOS battery disconnection.
• Clean boot is detected with no keyring or installed OS, and USB boot is offered.
• Boots from USB.
• OS installation and reboot.
• With no public key but an OS present, OEM Factory Reset is offered and completed with a hardware key.
• After re-ownership, a new HOTP/TOTP secret is generated.
• Wi-Fi works in the installed OS.
• PR0 validation:
  • flashprog -p internal reports the flash unlocked before lock_chip.
  • lock_chip applies PR0.
  • flashprog -p internal reports the flash locked afterwards.

[tlaurion]

~Addresses StarLabsLtd/firmware#104.

Thanks for your contribution @Sean-StarLabs
Could you upload your public key used to sign commits to github so the "unverified" commits warning vanishes?

Will try to review toroughly in next coming days but plate quite full right now. Looks good at first glance!

Meanwhile, would be nice if you added the checklist that can be found at https://github.com/linuxboot/heads-wiki/edit/master/Development/Porting.md and suggest changes there for things you see unfit.

[tlaurion]

Also think/suggest changes you would want to see at https://osresearch.net/Vendors/ (edit this page on github link at bottom of the page)

As well as documenting the same way under https://osresearch.net/Flashing-guides

I will collaborate in those PR as we go!

[tlaurion]

@Sean-StarLabs Love your work here, LGTM.

Checklist needs completion, of course.

Also seen as part of work addressing #2159 that you pushed fixes coreboot side. Tracking with great interest.

You might want to take a look at #2165 and linuxboot/heads-wiki#221

Do you have a timeline for testing?

[tlaurion]

@Sean-StarLabs you might want to add your GPIO work under label https://review.coreboot.org/q/topic:%22intel_gpio_lock%22

[tlaurion]

@Sean-StarLabs you might want to add your GPIO work under label https://review.coreboot.org/q/topic:%22intel_gpio_lock%22

Meanwhile, you can add related unmerged patches needed for your port to be applied to coreboot fork (as you did under patches/coreboot-starlabs_2607) for TPM GPIO reset vuln, if merging upstream stalls and prevents you from going forward (or point modules/coreboot to commits confirmed working on your side).

[tlaurion]

@Sean-StarLabs You saw https://app.circleci.com/pipelines/github/linuxboot/heads/1394/workflows/0d81f5d0-83fb-4af2-9df5-56797eeb7fb8/jobs/52499 ?

Jul 27 23:04:23 INFO: Applying patch file: patches/coreboot-starlabs_2607/0004-mainboard-starlabs-cezanne-enable-ftpm.patch
Checking patch build/x86/coreboot-starlabs_2607/src/mainboard/starlabs/cezanne/Kconfig...
Checking patch build/x86/coreboot-starlabs_2607/src/mainboard/starlabs/cezanne/board.fmd...
error: while searching for:
                RW_MRC_CACHE@0x20000    0x10000
                SMMSTORE@0x30000                0x80000
                CONSOLE@0xb0000         0x20000
                FMAP@0xd0000            0x1000
                COREBOOT(CBFS)
        }
}

error: patch failed: build/x86/coreboot-starlabs_2607/src/mainboard/starlabs/cezanne/board.fmd:5
Applied patch build/x86/coreboot-starlabs_2607/src/mainboard/starlabs/cezanne/Kconfig cleanly.
Applying patch build/x86/coreboot-starlabs_2607/src/mainboard/starlabs/cezanne/board.fmd with 1 reject...
Rejected hunk #1.
Jul 27 23:04:23 ERROR: Failed to apply patch: patches/coreboot-starlabs_2607/0004-mainboard-starlabs-cezanne-enable-ftpm.patch. Reversing and reapplying.
Checking patch build/x86/coreboot-starlabs_2607/src/mainboard/starlabs/cezanne/board.fmd...
error: while searching for:
                RW_MRC_CACHE@0x20000    0x10000
                SMMSTORE@0x30000                0x80000
                CONSOLE@0xb0000         0x20000
                PSP_NVRAM(PRESERVE)@0xd0000     0x20000
                FMAP@0xf0000            0x1000
                COREBOOT(CBFS)
        }
}

error: patch failed: build/x86/coreboot-starlabs_2607/src/mainboard/starlabs/cezanne/board.fmd:5
Checking patch build/x86/coreboot-starlabs_2607/src/mainboard/starlabs/cezanne/Kconfig...
Applying patch build/x86/coreboot-starlabs_2607/src/mainboard/starlabs/cezanne/board.fmd with 1 reject...
Rejected hunk #1.
Applied patch build/x86/coreboot-starlabs_2607/src/mainboard/starlabs/cezanne/Kconfig cleanly.
Checking patch build/x86/coreboot-starlabs_2607/src/mainboard/starlabs/cezanne/Kconfig...
Checking patch build/x86/coreboot-starlabs_2607/src/mainboard/starlabs/cezanne/board.fmd...
error: while searching for:
                RW_MRC_CACHE@0x20000    0x10000
                SMMSTORE@0x30000                0x80000
                CONSOLE@0xb0000         0x20000
                FMAP@0xd0000            0x1000
                COREBOOT(CBFS)
        }
}

error: patch failed: build/x86/coreboot-starlabs_2607/src/mainboard/starlabs/cezanne/board.fmd:5
Applied patch build/x86/coreboot-starlabs_2607/src/mainboard/starlabs/cezanne/Kconfig cleanly.
Applying patch build/x86/coreboot-starlabs_2607/src/mainboard/starlabs/cezanne/board.fmd with 1 reject...
Rejected hunk #1.
make: *** [Makefile:697: /root/heads/build/x86/coreboot-starlabs_2607/.canary] Error 1

[tlaurion]

@Sean-StarLabs anything needed on my side?

[tlaurion]

On 67cace7

Unless needed (msi platforms needed to have a punched hole to support recovery from proprietary tools), instead of using flashprog and read the whole spi to get cbfs content: it is advised to reduce cbfs region within the 16mb memory limit after which cbfs (flashtools/cbfs.c) would need some love to read as expected cbfs region> 16mb

Cc @Sean-StarLabs

[tlaurion]

On 67cace7

Unless needed (msi platforms needed to have a punched hole to support recovery from proprietary tools), instead of using flashprog and read the whole spi to get cbfs content: it is advised to reduce cbfs region within the 16mb memory limit after which cbfs (flashtools/cbfs.c) would need some love to read as expected cbfs region> 16mb

Cc @Sean-StarLabs

Otherwise issue to fix to keep >16mb cbfs region is osresearch/flashtools#10

Didn't prioritize this since msi platform is community port with few known users.

CC @Sean-StarLabs

If choosing to keep >16mb or not fix cbfs.c from pointed issue, you probably observed longer boot time since flashprog is slow at backup rom to extract cbfs from early cbfs-init.sh, which is a bug to be fixed, not to be used extensively in new boards:this is why I suggest reducing cbfs size in coreboot config.

3mdeb/dasharo+heads got dropped upstream for the msi platforms, workstations +dGPU didn't receive enough love to facilite proper UX with either oprom measure+extraction (borrowing seabios code), requiring both iGPU + dGPU so dual monitor setup as workaround, to say the least, subefficient.

Are you on matrix? Dm me if you will :)
We could do some synced work session.

Hope you enabled debug logging in local builds, so you can get the Debug + TRACE_FUNC output to get a quick grasp of what is happening under the hood and ease your porting process. Should not be hard since other platforms of same family exist, outside of coreboot upstream required fixes which you seem to have already grasped (either coreboot module pinned commit or patches/coreboot-* fork applied incrementally in alphanumeric order).

I see great ROI here, please contact.