Add NovaCustom V540TU board

[mkopec]

Add NovaCustom V540TU board (14" V54 Series, Meteor Lake, Integrated graphics)

[macpijan]

@mkopec Do we plan to add here the rest of the variants as well?

[mkopec]

@macpijan sure, after one starts working I'll do the rest too

[tlaurion]

@macpijan @mkopec similar commit needed for #1835

[tlaurion]

@mkopec this comment might be helpful #1835 (comment)

[tlaurion]

@mkopec

mkc: seems like kernel 6.7+ is bare minimal for meteor lake, with efifb fixes having landed under 6.8+?

Also, if you pass serial to kernel boot options under coreboot config, you should get logs of the kernel?

At https://matrix.to/#/!pAlHOfxQNPXOgFGTmo:matrix.org/$bVtsV3M_sz0MroFsDkXRGQ3ow7OhumKqtAllchkAyKs?via=matrix.org&via=nitro.chat&via=envs.net

[mkopec]

mkc: seems like kernel 6.7+ is bare minimal for meteor lake, with efifb fixes having landed under 6.8+?

possible, in Ubuntu and Fedora we found it best to have Linux 6.8 or newer (6.9 also has a fix for s0ix but that's irrelevant for Heads)

@tlaurion do you think you can help with updating the kernel?

[tlaurion]

I read that 6.12 will be next Lts but that is only speculation.

edit: We choose 6.11.9 for all novacustom boards?
I can give it a shot, yes, and leave traces in commit, taking this PR state as a base.

@mkopec did serial console passed per coreboot config to kernel gave you more info?
With debug as well. See qemu coreboot config, non-prod.

[tlaurion]

@mkopec there is a lot to tune under 6.11.9 kernel config which writes over shared linux config with other novacustom (config/linux-nitrokey-x.config, should probably renamed and all board configs point to new name as well).

See branch https://github.com/tlaurion/heads/tree/dasharo-add_novacustom_v540tu and feel free to steal adapt/change whatever. If you have questions, poke me where/if needed.

Note: compare config changes in commit 510bc6e to see all the new olddefconfig stuff applied silently when using defconfig. Ie, what happened with TRUST_CPU and so many other stuff to care about once you have something that boots.

See also that I changed your coreboot config to pass linux kernel options to be in debug, with probably wrong serial ttyS0, adapt accordingly and keep me posted. Small iterations in board porting has known good track history.

If you decided to tackle #1835 instead, I could help (if you guide me into how you get serial console output [even though this work wasn't planned nor in my plate up to now]).

[tlaurion]

• Switched x230 to use 6.11.9 with same process applied for quick testing: success (no brick bumped to 6.11.9).
• building all boards that were depending on linux-x230-maximized.config with kernel 6.11.9 at https://github.com/tlaurion/heads/tree/dasharo-add_novacustom_v540tu_regression-test-on-x230_success-build_test_for_all_x230_dependent_linux_config_from_CI (expecting sandy bridge based boards to fail because bzImage will be too big)

Edit:yep. Cannot bump Sandy to 6.11.9: as can be seen, all those do not have enough free spi space without another phase of #590 (not planned.)

[mkopec]

Thanks for the patches @tlaurion , I'm testing them now, i'm not getting a serial console yet, I suspect the LPSS UART driver is missing, will try to fix

[tlaurion]

@mkopec #1865 merged, please rebase

[tlaurion]

Thanks for the patches @tlaurion , I'm testing them now, i'm not getting a serial console yet, I suspect the LPSS UART driver is missing, will try to fix

@mkopec This needs updates, since reported off-channel to be all good :)

[mkopec]

@tlaurion rebased

[tlaurion]

@mkopec awesome!!!

---

Trying to dodge politic issues from #1818 (comment) and going practical and specific.

@macpijan @mkopec : Can https://review.coreboot.org/c/coreboot/+/85278 be added to Dasharo fork (which nv41/ns50/v540TU/v560TU should build upon (modules/coreboot dasharo pointed commit), tested against #1818 so that we can merge #1818 (which changes configs for nv41) and here changes needed for PR0 for v540TU/V560TU?

Makes sense? Otherwise patches need do be under patches/coreboot-dasahro-unreleased, which I do not want to maintain since we talk of a new coreboot release.

Also, MSI(#1753 should build from same coreboot Dasharo fork commit pointed under modules/coreboot without breaking (otherwise multiple coreboot Dasahro forks will be built under Heads???? Is that the plan because multiple forks for different boards under Dasharo?)

cc @pietrushnic @macpijan

[tlaurion]

@mkopec this is shared between MSI/nv41/ns50/v540Tu/v560TU: tested for oldconfig expension/run time regression? #1818 related patch inclusion?

[mkopec]

It's not regression tested yet, will report here with results

[tlaurion]

Was 6.11.9 verified needed for meteor lake as opposed to 6.1.8 which all other Heads boards depend on after serial console issue being fixed and ACPI related Kconfig addition under linux config added that was the cause of linux hang, maybe not efifb nor 6.1.8?

[mkopec]

The cause of hang was X2APIC not being enabled in kernel config, now with that sorted I think I can try 6.1 again to check if we need 6.11 after all

[tlaurion]

Some patches against linux were removed and not readded with adaptation as compared to 6.1.8. If 6.11.9 required for meteor lake, missing patches need to be brought back if still needed

[tlaurion]

@mkopec Review dropped :)

[tlaurion]

@mkopec "MSI/Novacustom n4x_adl / NS50 / V540TU /V560TU" ...

Meaning all those need to build(CI:ok) AND not have regression per commit below (at least no brick per this PR) and coreboot oldconfig changes for other boards when we do a coreboot bump to review changes across bump and do regression testing for boards affected per changes

MSI: still not merged under Heads (#1753) but affect nv4x_adl/ns50 and the new boards added per this coreboot commit support (coreboot version bump)

[tlaurion]

Also please note ~upstream coreboot base from which the fork is derived from (so that we can reuse coreboot buuildstack if possible to reduce CI build time).

[mkopec]

Right, comment updated.

[tlaurion]

@mkopec I decided to not do politics in words, but as code from now on. What is coreboot fork related will be coreboot fork related from now on.

#1818 was merged, if you rebase from/merge master in your PR, you will see that added PR0 patch under patches/coreboot-dasharo_unreleased don't apply as for nv4x_adl on master, where only ns50/n4x_adl were the only Heads master consumers of Dasharo forks, showing problem of having multiple forks for different platforms and delegating problem to whom it belongs, making sure patches/coreboot-dasharo_unreleased patches that were pending next downsteam fork release are picked up/adtapted in next downstream release, and for Heads to take for granted that coreboot base is working as expected for Heads to do its Heads stuff.

• modify build/x86/coreboot-dasharo/.canary to add random character in commit id there so that fork is pulled clean
• see patches/coreboot-dasahro_unreleased dir patches reapplied on fork
• see that PR0 patch fails applying until adapted.
• adapt patch to dasharo fork, modify modules/coreboot to point to new commit
• select needed changes from WiP: PR0 (SPI write prevention through chipset locking) for nv4x_adl, setting base for other platforms/downstream forks supporting >=Skylake+ #1818 for nv4x for v540TU (board config and coreboot config)
• test
• done

I will then participate/help adapting changes to coreboot configs/board configs if needed for Heads under #1868, which points to needed knowledge for Heads for PR0 to work as expected on skylake+, and will be used as base so coreboot upstream patch evolves to be useful for all and prevent OS persistent threat to be pushed to firmware (at least under Heads use case) leaving physical attack of tampering bootblock the only threat model to SPI flash for advanced users activating Heads Authenticated Heads, which I intend to push on next feature freeze (next downstream release).

[tlaurion]

Nice, which means we can reuse x230 24.02.01 buildstack (util/corssgcc built per coreboot fork base version, can be shared) as per prior lines, adapting:
$(eval $(call coreboot_module,dasahro,24.02.01))

(This means CI, passing cahce layers from prior build and persist workspaces, will reuse coreboot built buildstack, reducing precious build time. Note this is also why we love sharing same linux kernel versions where possible, not only to commpare configs between each other to guarantee some kind of baseline + needed platform requirements, but also have shared linux build dir, where module/(linux/coreboot) build artifacts is $BOARD_NAME. This permits to share build cache (somewhat equivalent of ccache) while having board specific modules for initrd and kernel bzimage outputed in board build dir.)

TLDR: those things save a lot of build time. This is more then desired, if not needed with forever added boards.
(If we do so, time is spent in downloading workpace caches (bandwidth doesn't count on credits) where compile time per board if modules/* hashes don't change is reused, resulting in build times of 10 minutes per board.