Add NovaCustom V540TU and V560TU boards #1846
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
@mkopec Do we plan to add here the rest of the variants as well? |
|
@macpijan sure, after one starts working I'll do the rest too |
2 tasks
|
@mkopec this comment might be helpful #1835 (comment) |
|
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? |
|
I read that 6.12 will be next Lts but that is only speculation. edit: We choose 6.11.9 for all novacustom boards? @mkopec did serial console passed per coreboot config to kernel gave you more info? |
|
@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]). |
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.) |
|
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
force-pushed
the
add_novacustom_v540tu
branch
from
f33526c to
aeb7fc7
Compare
4 tasks
mkopec
force-pushed
the
add_novacustom_v540tu
branch
from
aeb7fc7 to
005c519
Compare
|
@tlaurion rebased |
mkopec
force-pushed
the
add_novacustom_v540tu
branch
from
005c519 to
6964713
Compare
|
@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 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?) |
tlaurion
reviewed
Nov 29, 2024
modules/coreboot
Outdated
| @@ -93,8 +93,7 @@ $(eval $(call coreboot_module,purism,24.02.01)) | |||
|
|
|||
| # MSI and Nitropad NV41 / NS50 boards are based on Dasharo coreboot port | |||
| coreboot-dasharo_repo := https://github.com/dasharo/coreboot | |||
| coreboot-dasharo_commit_hash := 3a9aa3a4692f3dd49732f5b4e3ec54be385f0969 | |||
| coreboot-dasharo_patch_version := unreleased | |||
| coreboot-dasharo_commit_hash := db1d9cd59d0d7d5b708bbdf8670780914061410c | |||
There was a problem hiding this comment.
It's not regression tested yet, will report here with results
tlaurion
reviewed
Nov 29, 2024
| @@ -34,6 +34,9 @@ linux_hash := 40f014d53e81f204f6d2a364aae4201ae07970dd1b70dc602d7c66c1a140f558 | |||
| else ifeq "$(CONFIG_LINUX_VERSION)" "6.1.8" | |||
| linux_version := 6.1.8 | |||
| linux_hash := b60bb53ab8ba370a270454b11e93d41af29126fc72bd6ede517673e2e57b816d | |||
| else ifeq "$(CONFIG_LINUX_VERSION)" "6.11.9" | |||
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
reviewed
Nov 29, 2024
There was a problem hiding this comment.
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
reviewed
Nov 29, 2024
8 tasks
|
@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.
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
reviewed
Nov 29, 2024
| @@ -91,7 +91,8 @@ coreboot-purism_repo := https://source.puri.sm/firmware/coreboot.git | |||
| coreboot-purism_commit_hash := bea9947a1279be7d4a72b38a601d0288d10d1cb8 | |||
| $(eval $(call coreboot_module,purism,24.02.01)) | |||
|
|
|||
| # MSI and Nitropad NV41 / NS50 boards are based on Dasharo coreboot port | |||
| # MSI and NovaCustom NV4xPZ, NS5xPU, V540TU, V560TU boards are based on Dasharo | |||
| # coreboot fork, based on upstream coreboot version 24.02 | |||
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Added $(eval $(call coreboot_module,dasahro,24.02.01)) to allow reusing environment in CI, in commit 0cdba41
Currently coreboot sets it for us. Verified by checking Current Operation Mode field in ME device, it's currently 2 (Debug mode / HAP) I'll check your changes and report back with results |
Ok so Edit: still no joy from boot. |
tlaurion
added a commit
to tlaurion/heads
that referenced
this pull request
Dec 11, 2024
…be applied by IFDTOOL to linuxboot#1846 Signed-off-by: Thierry Laurion <[email protected]>
Signed-off-by: Michał Kopeć <[email protected]>
Co-authored-by: Thierry Laurion <[email protected]> Signed-off-by: Michał Kopeć <[email protected]>
|
@mkopec we are looping here, seems like we have communication issues. This PR still doesn't build under CI for v560tu, meaning we won't be able to use the same rom on both our machines to make sure we talk about the same thing, with same flashing technique /regions therefore SPI content. It would be nice if we optimized our collaboration so this is done before christmas. Commit fixing CI is tlaurion@30951a7 (provided 19 hours ago) I opened a thread under Matrix. Please poke me there. I suggested fixes that are still not picked up, nv4x_adl/ns50 config changes are not there alongside a bunch of already provided fixes in code. If changes suggested are not evaluted and some things are picked up while others are missed, we won't do it before christmas. Live communication is needed otherwise we are loosing both our precious time. |
Redoing diffs already proposed under linuxboot#1871 but not taken yet.... Signed-off-by: Thierry Laurion <[email protected]>
…inuxboot#1871 for linuxboot#1846 Signed-off-by: Thierry Laurion <[email protected]>
…linuxboot#1871 but not yet taken under linuxboot#1846 BOOTSPLASH section missing, as well as ME still enabled... Signed-off-by: Thierry Laurion <[email protected]>
… region, document S3/S01x/Hibernation limitation which is lackking from linuxboot#1846 Signed-off-by: Thierry Laurion <[email protected]>
…be applied by IFDTOOL to linuxboot#1846 Signed-off-by: Thierry Laurion <[email protected]>
…fig helper Signed-off-by: Thierry Laurion <[email protected]>
…e to reuse 24.02.01 coreboot buildstack, no point waiting for novacustom_nv4x_adl to be built. Gonna clear cache for next run and build clean Signed-off-by: Thierry Laurion <[email protected]>
Signed-off-by: Michał Kopeć <[email protected]>
|
@mkopec v560tu/v540tu fails per CI, log to error pointed to CI build log line at https://app.circleci.com/pipelines/github/Dasharo/heads/164/workflows/8b24a3e8-be7f-48e7-951e-5b55bd596d21/jobs/3553?invite=true#step-106-89158_135 :
the logic under of Heads is to use coreboot dependency resolving for submodules retrieval, as can be seen under modules/coreboot. Initially reported at #1876 (comment) EDIT: CircleCI cache system notes, if either global Makefile, modules/coreboot or patches/* modules hashes don't match what CircleCI has cache for, then that coreboot cache layer is not used and that subdir is rebuilded clean. |
|
As per log trace https://app.circleci.com/pipelines/github/Dasharo/heads/164/workflows/8b24a3e8-be7f-48e7-951e-5b55bd596d21/jobs/3553?invite=true#step-106-0_169 |
|
Simple notes that this time, muslc-cross-make layer is used per last build cache https://app.circleci.com/pipelines/github/Dasharo/heads/165/workflows/5f87da24-b62a-4197-a13b-dd0f32c1066f/jobs/3583/parallel-runs/0/steps/0-107 Everything coreboot and other modules artifacts will be built from source, since modules/coreboot changed and therefore layer 2 cache cannot be reused (coreboot buildstack) nor layer 3 can be used (modules/* local artifacts). This should be representative of a clean build, minus musl-cross make (which isn't touched here). |
|
@mkopec same repro local |
Signed-off-by: Michał Kopeć <[email protected]>
mkopec
force-pushed
the
add_novacustom_v540tu
branch
from
fc572e2 to
3f8a0df
Compare
|
@mkopec 3f8a0df is booting into heads for me!!!! Booting to Heads from power button press to Heads takes 35 seconds for you too mkopec? Logs gathered, will try to see why powering up to load payload - > selfboot jump takes 33 seconds (and why kernel log (dmesg) says 3 seconds which is heads part before being finalizing loading usb controllers drivers...) v650tu-cbmem_c_me-excerpt.txt Installing QubesOS. |
|
it's not usually taking long for me, but sometimes I run into boot issues (long boot time) when a usb-c dock with monitors is connected. Seems to happen before the bootsplash is drawn, so I'm not sure if it's the same as your issue |
No all the 30 seconds happens when bootsplash is there, so pre raminit. Will dig logs. As if ram was always trained? Insight is that there is no MRC cache in config or something |
|
Bootsplash is drawn after RAM is already up, training ends at
This may happen if you don't have CMOS battery connected |
EDIT: well analysis from my side, cmos battery connected (time ok). From v650tu-cbmem_t.txt This is memory init as you said? So on my side, most of wait is on memory init, then loading payload from SPI. |
|
@mkopec this is my cbmem -t after having set alt century bit =n (so that system clock = build time (#1854 related for unification after we figure out what's going on) v650tu-cbmem_t_after_setting_time_and_mem_training_coldboot.txt As can be seen here: user spends 30 seconds under bootsplash :( @krystian-hebel said under matrix thread
Which is why we should test latest commit 3f8a0df build artifacts at https://app.circleci.com/pipelines/github/Dasharo/heads/166/workflows/6c361516-8363-4773-a8b1-c2570648121c/jobs/3659/artifacts otherwise we compare apples and oranges! @mkopec tlaurion@72b8a44 needed (and most probably to all other coreboot configs linked to dasharo fork, so nv4x/ns50/v540tu/v560tu so that CMOS reverts to build time and change time picks up and asks user/oem to set clock through GUI after initial flash (and disconnecting/reconnecting CMOS battery). |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Add NovaCustom V540TU board (14" V54 Series, Meteor Lake, Integrated graphics)