Ap2110 unpro - #957
Open
filipleple wants to merge 1240 commits into
Open
Conversation
Upstream-Status: Inappropriate [Dasharo downstream] Signed-off-by: Mateusz Maciejewski <mateusz.maciejewski@3mdeb.com>
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>
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>
Member
Author
|
Trying to mark as ready, but the functionality seems down at the moment: 
|
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>
Upstream-Status: Inappropriate [Dasharo downstream] Signed-off-by: Filip Lewiński <filip.lewinski@3mdeb.com>
filipleple
force-pushed
the
ap2110_unpro
branch
from
August 18, 2026 07:59
7b81a10 to
347b21a
Compare
filipleple
marked this pull request as ready for review
August 18, 2026 07:59
SergiiDmytruk
left a comment
SergiiDmytruk
left a comment
Member
There was a problem hiding this comment.
The PR needs to be resend (but probably not rebased after reaching RC3), providing review here for now.
| CONFIG_SBOM_IPXE=y | ||
| CONFIG_VENDOR_PROTECTLI=y | ||
| CONFIG_VBOOT=y | ||
| CONFIG_FMDFILE="src/mainboard/$(CONFIG_MAINBOARD_DIR)/vboot-rwa.fmd" |
Member
There was a problem hiding this comment.
Did you intend to keep CONFIG_SBOM_VBOOT?
| SI_ME | ||
| } | ||
| SI_BIOS@0x500000 0xb00000 { | ||
| SMMSTORE(PRESERVE) 256K |
Member
There was a problem hiding this comment.
Do we want to allocate 512K for SMMSTORE to not have to grow it later as was on other platforms?
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.