Skip to content

Conversation

@SergiiDmytruk
Copy link
Member

@SergiiDmytruk SergiiDmytruk commented Jan 7, 2026

This makes it possible to disable ME via HMRFPO before applying an update, as on-disk capsules don't rely on preserving RAM's state across reboots.

As usual, better review commits in order.

This also enables publication of SMBIOS table necessary to determine whether a platform is fused on Hardkernel Odroid, where the changes were tested but hit an error because capsules thought the device has been fused.

First half of Dasharo/dasharo-issues#1438 (comment) could be used for context.

EDK PR: Dasharo/edk2#287
issue: Dasharo/dasharo-issues#1438
ref: dsh-1130

@mkopec
Copy link
Member

mkopec commented Jan 9, 2026

Code looks valid. I haven't tested it yet.

This deduplicates and simplifies bodies of several functions.

Upstream-Status: Inappropriate [Dasharo downstream]
Change-Id: I64beb41f8e103f7c7c7accf497e3cb36f0a914c9
Signed-off-by: Sergii Dmytruk <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
Upstream-Status: Inappropriate [Dasharo downstream]
Change-Id: I9007ac5040b984c51af2eda972210256f40e7059
Signed-off-by: Sergii Dmytruk <[email protected]>
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 <[email protected]>
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 <[email protected]>
Upstream-Status: Inappropriate [Dasharo downstream]
Change-Id: I12e79c2b6e3ace47f2d4883442b735740bb8723c
Signed-off-by: Sergii Dmytruk <[email protected]>
@mkopec mkopec force-pushed the capsules-me-auto-disable branch from 78ce46a to 8c3789c Compare January 9, 2026 07:59
@mkopec mkopec merged commit 8c3789c into dasharo Jan 9, 2026
38 of 39 checks passed
@mkopec mkopec deleted the capsules-me-auto-disable branch January 9, 2026 08:00
@mkopec
Copy link
Member

mkopec commented Jan 9, 2026

Tested, left comment in the edk2 PR: Dasharo/edk2#287 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants