Novacustom mtlh cmos reset - #958
Open
filipleple wants to merge 1241 commits into
Open
Conversation
This reverts commit f3dbe79. Signed-off-by: Thomas Clarke <tonux@riseup.net>
Signed-off-by: Thomas Clarke <tonux@riseup.net>
…etection feature Upstream-Status: Inappropriate [Dasharo downstream] Signed-off-by: Filip Lewiński <filip.lewinski@3mdeb.com>
Upstream-Status: Inappropriate [Dasharo downstream] Signed-off-by: Filip Lewiński <filip.lewinski@3mdeb.com>
Upstream-Status: Inappropriate [Dasharo downstream] Signed-off-by: Mateusz Maciejewski <mateusz.maciejewski@3mdeb.com>
…M on i226 ASPM has been reported to cause reduced performance when running iperf3 between two VP2440 DUTs. Disable ASPM to ensure full performance is available. Upstream-Status: Pending Change-Id: I6ef31a47aac64c871568a653f1cefb773f27f44a Signed-off-by: Michał Kopeć <michal.kopec@3mdeb.com>
Upstream-Status: Inappropriate [Dasharo downstream] Change-Id: I51d677dbec0b19b6a436d45c674848fcd2ebb521 Signed-off-by: Michał Kopeć <michal.kopec@3mdeb.com>
…, L1 for SSD Upstream-Status: Pending Change-Id: I1a04d4bc36b10df2fd3ea7687674142c8150d166 Signed-off-by: Michał Kopeć <michal.kopec@3mdeb.com>
Upstream-Status: Inappropriate [Dasharo downstream] Change-Id: If0d9c2689165047e6811d442f73648a81fa40ee6 Signed-off-by: Michał Kopeć <michal.kopec@3mdeb.com>
Upstream-Status: Inappropriate [Dasharo downstream] Change-Id: I3b7b630bcc817f290c6cb03e39e696525f407f04 Signed-off-by: Michał Kopeć <michal.kopec@3mdeb.com>
Upstream-Status: Inappropriate [Dasharo downstream] Change-Id: Ia52318806620413ad07dd52d6d6fbc29468dd0e6 Signed-off-by: Michał Kopeć <michal.kopec@3mdeb.com>
3rdparty/dasharo-blobs updated to 16.1.40 for ADL-P Upstream-Status: Inappropriate [Dasharo downstream] Signed-off-by: Mateusz Maciejewski <mateusz.maciejewski@3mdeb.com>
Upstream-Status: Inappropriate [Dasharo downstream] Signed-off-by: Mateusz Maciejewski <mateusz.maciejewski@3mdeb.com>
Upstream-Status: Inappropriate [Dasharo downstream] Signed-off-by: Filip Lewiński <filip.lewinski@3mdeb.com>
Upstream-Status: Pending Change-Id: I2218725ecf7a8787a70816660de237bed77b2b8f Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com> Signed-off-by: Michał Kopeć <michal.kopec@3mdeb.com>
Upstream-Status: Pending Change-Id: Id9375d1a883d485b14132f76dfa36aa3ae150b72 Signed-off-by: Michał Kopeć <michal.kopec@3mdeb.com>
Upstream-Status: Inappropriate [Dasharo downstream] Change-Id: If0d50df52e8eca52816d66d6d80bcdc2a617ef59 Signed-off-by: Michał Kopeć <michal.kopec@3mdeb.com>
Upstream-Status: Inappropriate [Dasharo downstream] Signed-off-by: Wiktor Mowinski <wiktor.mowinski@3mdeb.com>
Upstream-Status: Inappropriate [Dasharo downstream] Signed-off-by: Wiktor Mowinski <wiktor.mowinski@3mdeb.com>
Upstream-Status: Inappropriate [Dasharo downstream] Signed-off-by: Wiktor Mowinski <wiktor.mowinski@3mdeb.com>
Upstream-Status: Inappropriate [Dasharo downstream] Signed-off-by: Wiktor Mowinski <wiktor.mowinski@3mdeb.com>
Upstream-Status: Inappropriate [Dasharo downstream] Signed-off-by: Wiktor Mowinski <wiktor.mowinski@3mdeb.com>
This deduplicates and simplifies bodies of several functions. Upstream-Status: Inappropriate [Dasharo downstream] Change-Id: I64beb41f8e103f7c7c7accf497e3cb36f0a914c9 Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Changes: - add handling of Dasharo/"DiskCapsulesBoot" EFI variable which requests such a boot from coreboot (EDK sets it if OsIndications requests processing of on-disk capsules and at least one seems to be present) - permit HMRFPO during this boot as on-disk capsules are not affected by cold resets - act as if FUM is enabled during such a boot because capsules need it and this way there is no need to ensure several variables are in sync Upstream-Status: Inappropriate [Dasharo downstream] Change-Id: I6722fb5ebc5deaa4b2f383f076ee9e3126468ad5 Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Add a new CBMEM entry that informs payload about current boot. For now, this is only to indicate that "disk capsules" boot is active and is needed because in EDK's early stages can't check for EFI variables. However, it's also nice to have a confirmation from coreboot that it processed the request. Change-Id: I6894409542dece959480d7f11784f8c00f069ee7 Upstream-Status: Inappropriate [Dasharo downstream] Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
EDK requests this boot kind from coreboot in order to discover, load and process on-disk capsules. Upstream-Status: Inappropriate [Dasharo downstream] Change-Id: I2faed8e4f633bac9f475a480887aa2be526cb26d Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Upstream-Status: Inappropriate [Dasharo downstream] Change-Id: I9007ac5040b984c51af2eda972210256f40e7059 Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
This board supports both Intel Boot Guard and capsule updates, not providing this table results in capsules conservatively assuming the platform is fused when that's not actually the case. Change-Id: Ib7db31131c2642f7edeed5f561894ecf6cefd77e Upstream-Status: Pending Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
It permits submitting update capsules by putting them in `/EFI/UpdateCapsule/`, setting the third bit in `OsIndications` EFI variable and rebooting. Upstream-Status: Inappropriate [Dasharo downstream] Change-Id: I04edcd5b7d6944670267bb4dbb0ef4149ffd7bb3 Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Upstream-Status: Inappropriate [Dasharo downstream] Change-Id: I12e79c2b6e3ace47f2d4883442b735740bb8723c Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Add edk2-platforms to SBOM as well. Upstream-Status: Inappropriate [Dasharo downstream] Change-Id: I5fd189ad457b9766a7e5e25c09d89f8e71dbee8e Signed-off-by: Filip Lewiński <filip.lewinski@3mdeb.com>
Upstream-Status: Inappropriate [Dasharo downstream] Signed-off-by: Filip Lewiński <filip.lewinski@3mdeb.com>
Pulls the goswid change that records a SHA-256 file hash in the CoSWID payload, used by the src/sbom rules below to carry per-component integrity data. Changes .gitmodules to point to Dasharo fork containing the patch. Upstream-Status: Inappropriate [Dasharo downstream] Signed-off-by: Filip Lewiński <filip.lewinski@3mdeb.com>
An EU CRA check (sbom-tools --standard cra) on the embedded SBOM flagged two gaps: no component carried a cryptographic hash (Annex I integrity / vendor hash carry-through, an error), and only coreboot declared a license while the other components did not (Art. 13(5)). For every component whose binary is known at build time (Intel ME, IFD, FSP-S/M/T, microcode and the payload) sha256sum the blob and pass it to `goswid add-payload-file --sha256`, which stores it as the CoSWID payload file hash. Add a license link to the remaining tag templates: an SPDX id for the open-source components (edk2, iPXE, vboot) and the upstream license file for the proprietary Intel/Dasharo blobs. Upstream-Status: Pending Signed-off-by: Filip Lewiński <filip.lewinski@3mdeb.com>
Identify NovaCustom as the manufacturer of the NUC BOX — the entity that places the finished product on the market under its trademark, which is the manufacturer for CRA purposes (Art. 13(15)). Upstream-Status: Inappropriate [Dasharo downstream] Signed-off-by: Filip Lewiński <filip.lewinski@3mdeb.com>
Upstream-Status: Pending Signed-off-by: Filip Lewiński <filip.lewinski@3mdeb.com>
Extend the embedded SBOM to cover firmware components that were missing or underspecified, reusing the existing per-component pattern (SBOM_<X> / SBOM_<X>_GENERATE / SBOM_<X>_PATH + CoSWID template + Makefile rule). The _PATH option lets a vendor supply a full external SBOM JSON per blob; GENERATE emits a minimal hashed fallback. New components: - SBOM_VGA_BIOS / _SECOND / _DGPU: the VGA BIOS OptionROMs (VGA_BIOS_FILE and friends). GENERATE records the blob sha256 and the target PCI vendor:device ID from VGA_BIOS_ID. - SBOM_EDK2_GOP: the external Intel GOP driver (EDK2_GOP_FILE) compiled into the edk2 payload. - SBOM_EDK2_LAN_ROM: the external LAN Option ROM driver (EDK2_LAN_ROM_DRIVER) compiled into the edk2 payload. - SBOM_EDK2_PLATFORMS: the edk2-platforms source tree, previously absent from the SBOM. Records the commit and tree hash of the checkout at payloads/external/edk2/workspace/edk2-platforms. Intel FSP enrichment: - Capture the FSP release version, the BIOS build number ((NNNN_NN) -> colloquial-version) and the target (Edge/IoT/Client, derived from the FD path -> edition), plus the SoC package (-> product-family), instead of a single opaque version token. New CoSWID templates are added under src/sbom/ and the new options are documented in Documentation/sbom/sbom.md. All new options default to n, so existing boards' SBOMs are unchanged. Change tested with 'make sbom' on novacustom_nuc_box: FSP now reports edition=IoT, product-family=ArrowLake; edk2-platforms and a VGA BIOS entry (with matching sha256) merge into a valid uSWID when enabled. Upstream-Status: Pending Signed-off-by: Filip Lewiński <filip.lewinski@3mdeb.com>
Extract ME/TXE version from the firmware binary. Some versions
store it as an ASCII string like: "ME16.1.40.2765".
When the string is missing, try to extract it from the CSE Main program
(NFTP) partition manifest: the version is 4x2 byte LE fields, 8 bytes after
the $MN2 magic string.
How NFTP is located depends on the image layout:
1. When NEED_IFWI & CONFIG_IFWI_FILE_NAME,
=> located in the IFWI image, extract NFTP from CONFIG_IFWI_FILE_NAME with
ifwitool
2. CONFIG_SOC_INTEL_CSE_HAVE_SPEC_SUPPORT=y, image has BPDT, ME_SPEC versioned
=> placed at the last non-empty BPDT partition, extract with cse_serger
1. CONFIG_ME_SPEC >= 15 => version is 1.7
2. 15 > CONFIG_ME_SPEC >= 12 => version is 1.6
3. 12 > CONFIG_ME_SPEC => not possible in such case
CONFIG_SOC_INTEL_CSE_HAVE_SPEC_SUPPORT must be "=n"
3. CONFIG_SOC_INTEL_CSE_HAVE_SPEC_SUPPORT=n
=> ME_SPEC <= 11, no BPDT, use cse_fpt to extract NFTP
Upstream-Status: Pending
Co-authored-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Signed-off-by: Filip Gołaś <filip.golas@3mdeb.com>
Open source deps that would otherwise only have a commit hash and tree hash will now instead use `<date>_<hash>` as software-version so that this field is in any way human readable. It will at least give a general idea of how old/new a revision is. coloquial-version is supposed to be used as a string-only release name that groups multiple versions under common major version. Using the latest tag of the dependencies is a valid use and will inform about what upstream release the components base on. It will be the most important field for human readers. Decisions based on the RFC: https://datatracker.ietf.org/doc/rfc9393/ Upstream-Status: Pending Signed-off-by: Filip Gołaś <filip.golas@3mdeb.com>
…as edition Extracting FSP image revision from the binary is the only reliable source of the version number. The Bios version can only be received from commit messages. The SKU type can be extracted from a commit message or directory name, the latter being the more robust method as the commit messages are not guaranteed to contain anything. A well known GUID and offests from the spec are used to detect the FSP info header and extract the version number components. Header spec versions >=6 support extended image revisions and require appending some more bytes to minor and major version revision parts. Upstream-Status: Pending Signed-off-by: Filip Gołaś <filip.golas@3mdeb.com>
…s to them The two binaries were merged together because all microcode binaries used the same tag-id hardcoded in the json. By using goswid to generate the tag-id fields from filename we get deterministic ids for every ucode binary in a firmare. It won't change as cpuid doesn't change. cpuid output, revision and date of the ucode binary are added to oswid sbom for more details. Upstream-Status: Pending Signed-off-by: Filip Gołaś <filip.golas@3mdeb.com>
Pull the SHA hashing and early exit error fix Upstream-Status: Pending Signed-off-by: Filip Lewiński <filip.lewinski@3mdeb.com>
Set it to the author of the firmware covered by the SBOM, not the hardware distributor. Upstream-Status: Pending Signed-off-by: Filip Lewiński <filip.lewinski@3mdeb.com>
Guard parsing the revision with the SBOM_EDK2_PLATFORMS_GENERATE config switch. Upstream-Status: Pending Signed-off-by: Filip Lewiński <filip.lewinski@3mdeb.com>
It now correctly resolves to BIOS_VENDOR, i.e. 3mdeb Upstream-Status: Inappropriate [Dasharo downstream] Signed-off-by: Filip Lewiński <filip.lewinski@3mdeb.com>
Upstream-Status: Pending Signed-off-by: Filip Lewiński <filip.lewinski@3mdeb.com>
SATA port 1 shares PCH PCIe lane 12 with lane 0 of the M.2 M-key slot. The lane owner is picked at runtime from SATAPCIE1_DET (GPP_A12 as SATAXPCIE1); the flash descriptor already has combo port 1 set to "GPIO Polarity PCIe", so no descriptor change is needed. Since the lane is not assigned to the SATA controller at reset, the port must be marked hot-pluggable to be probed once it is. Add sata_ports_hotplug[1] and sata_salp_support, matching what hardkernel/odroid-h4 uses for the same PCH lane. Upstream-Status: Pending Signed-off-by: Filip Lewiński <filip.lewinski@3mdeb.com>
Upstream-Status: Inappropriate [Dasharo downstream] Signed-off-by: Filip Lewiński <filip.lewinski@3mdeb.com>
Upstream-Status: Inappropriate [Dasharo downstream] Signed-off-by: Filip Lewiński <filip.lewinski@3mdeb.com>
Commit e0813b3 converted most git-backed SBOM components to the human-readable `<date>_<hash>` software-version and a release tag as colloquial-version, but edk2-platforms and edk2-gop were missed and still emitted a bare commit hash with a tree hash as colloquial-version. openSIL likewise still recorded only a bare commit hash. Convert all three to follow suit: software-version now uses `<commit-date>_<hash>`, and where the template carries a colloquial-version field (edk2-platforms, edk2-gop) it now holds the latest release tag reachable from HEAD, selected the same way as the iPXE/vboot rules. openSIL has no colloquial-version field, so only its software-version changes. Decisions based on the RFC: https://datatracker.ietf.org/doc/rfc9393/ Upstream-Status: Pending Signed-off-by: Filip Lewiński <filip.lewinski@3mdeb.com>
Every git-backed SBOM component derived its two version fields by hand-rolling the same two git commands, spelled three different ways (`--git-dir <repo>/.git`, `-C <dir>`, implicit cwd), with inconsistent stderr redirection and safe.directory handling. The latest-release tag alone was open-coded at five call sites, so changing how it is obtained meant a five-place edit. Introduce three `$(call)` helpers in the established strip_quotes idiom - sbom-git-comm-hash, sbom-git-latest-rel and sbom-git-toplevel-of - and route all call sites through them, so each git operation has exactly one definition. safe.directory is now relaxed uniformly rather than only for openSIL; containerized builds need it everywhere. With the command in one place, replace the open-coded `tag --merged HEAD --sort=-creatordate | head -n1` with the equivalent `git describe --tags --abbrev=0`, as suggested in review. Two flags are load-bearing: --tags is required because some component repositories (iPXE) carry only lightweight tags, which git describe ignores by default, and `|| true` is required because git describe exits 128 on repositories with no tags at all (3rdparty/vboot, 3rdparty/blobs), which would abort the recipes running under `set -e`. Output was verified identical for every checked-out component repository. coreboot.json deliberately keeps its own `^NN.NN$` tag filter: forks carry their own release tags, and git describe would return those (e.g. novacustom_nuc_box_v0.9.2) instead of the coreboot release. The comment there now says so, so a later cleanup does not "fix" it. No SBOM output changes. Upstream-Status: Pending Signed-off-by: Filip Lewiński <filip.lewinski@3mdeb.com>
Match point-release tags (24.02.01, 4.20.1) so a fork based on a release branch reports its real base, and abort instead of emitting an empty colloquial-version when the checkout carries no release tag at all, as happens on a shallow or blobless clone made without --tags. Upstream-Status: Pending Signed-off-by: Filip Lewiński <filip.lewinski@3mdeb.com>
The colloquial-version comment claimed sbom-git-latest-rel "handles" the tagless third-party repositories. It does not: it looks tags up, and an absent tag is merely ignored via "|| true". State the coreboot-specific consequence instead, and name the actual causes of an unreachable release tag (shallow clone, --no-tags) rather than blobless clones, which fetch tags normally. Upstream-Status: Pending Signed-off-by: Filip Lewiński <filip.lewinski@3mdeb.com>
Add cmos_is_invalid() so code outside the RTC driver can tell whether the CMOS contents were lost, e.g. because the coin cell was removed. A __weak default checks the alternative century byte; platforms with a chipset-level indication override it. Both overrides deliberately combine the chipset indication with the CMOS RAM VRT bit so that the result is one-shot: - On Intel SoCs, GEN_PMCON_B.RTC_BATTERY_DEAD is sticky and is never cleared (only Elkhart Lake and Jasper Lake have a clear_rtc_failed()), so on its own it would keep reporting a failure on every boot after a single RTC well power loss. - On the legacy Intel southbridges the opposite applies: rtc_init() clears RTC_BATTERY_DEAD before calling cmos_init(), so rtc_failure() alone already reads false by the time a caller inside cmos_init() samples it. __cmos_init() re-arms the VRT bit during the same boot, which makes it the right latch for both cases. Ported from commit eb2aa28 ("pc80/mc146818rtc: Add API to get CMOS failure state") on the msi_new_options branch, with both overrides adjusted as described above. Upstream-Status: Pending Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com> Signed-off-by: Filip Lewiński <filip.lewinski@3mdeb.com>
Allow restoring default settings by resetting CMOS. When cmos_is_invalid() reports that the CMOS contents were lost, every option read falls back to its compiled-in default and the SMMSTORE option region is erased so that the payload repopulates it with defaults. Because the option readers are guarded rather than the storage, the fallback applies in every stage, including the romstage read of the ME state, so a setting that prevents the platform from booting can be recovered by removing and reinserting the coin cell. Differences from the ported commit: - read_u8_var() returns CB_ERR instead of CB_SUCCESS. All of its callers pre-initialise their variable and ignore the return value, and returning CB_SUCCESS without writing *var made read_bool_var() evaluate an uninitialized value. CB_ERR also extends the fallback to every read_bool_var() caller, which was missed before. - cmos_init() samples cmos_is_invalid() before __cmos_init() re-arms the VRT bit, and gates the reset on that sample rather than on the `invalid` parameter. On Intel SoCs that parameter comes from soc_get_rtc_failed(), i.e. the sticky RTC_BATTERY_DEAD bit, which would erase the options on every subsequent boot. The reset is also skipped on S3 resume, and its result is logged. Ported from commit c8630b0 ("efi/option: Restore and return defaults if CMOS is invalid") on the msi_new_options branch. Upstream-Status: Pending Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com> Signed-off-by: Filip Lewiński <filip.lewinski@3mdeb.com>
Removing the coin cell on a NovaCustom V56x did not reset the firmware settings. Two separate problems, both visible in the cbmem log: [WARN ] RTC: Clear requested zeroing cmos __cmos_init() prints " Clear requested" for its `invalid` argument and " Power Problem" for cmos_error(). Only the former appeared, so soc_get_rtc_failed() was true while cmos_error() was false. First, RTC register D's VRT bit is hardwired to 1 on this PCH. It reads back valid even immediately after the CMOS has been cleared, and __cmos_init()'s write-back of RTC_VRT is a no-op, so it cannot be used to corroborate the chipset indication. Second, and less obvious: the live GEN_PMCON_B.RTC_BATTERY_DEAD bit does not survive into ramstage. No coreboot code clears it on this SoC, yet it reads back zero by the time the PMC device is enabled and cmos_init() runs. This is why soc_get_rtc_failed() consults the chipset_power_state snapshot taken in romstage rather than reading the register, and why the only live users of vbnv_cmos_failed() are in bootblock and romstage. So take the erase decision from cmos_init()'s `invalid` argument, which is that snapshot, and make cmos_is_invalid() use the snapshot from ramstage onwards too, so that all stages agree for the whole boot. Also add a __weak cmos_invalid_ack(), overridden for Meteor Lake to clear RTC_BATTERY_DEAD, following the clear_rtc_failed() precedent in Elkhart Lake and Jasper Lake. On this platform the bit is evidently already clear by then, but the acknowledgement makes the one-shot property explicit instead of depending on that. It runs only after the option region has actually been erased, so a failed erase is retried on the next boot. Clearing the live register there is safe: soc_get_rtc_failed() and the ELOG_TYPE_RTC_RESET event both read the romstage snapshot. Upstream-Status: Pending Signed-off-by: Filip Lewiński <filip.lewinski@3mdeb.com>
Add RESET_OPTIONS_ON_CMOS_CLEAR, and enable it only for the MTL-H boards. It depends on DRIVERS_EFI_VARIABLE_STORE and SMMSTORE_V2, since both the erase and the reader fallbacks are meaningless without an option store to reset. The mainboard opts in by overriding the default rather than with a select, so that those dependencies keep applying to a configuration that turns the EFI variable store off. Upstream-Status: Pending Signed-off-by: Filip Lewiński <filip.lewinski@3mdeb.com>
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
10 participants
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.
No description provided.