EC capsules - #310
Open
SergiiDmytruk wants to merge 9 commits into
Open
Conversation
filipleple
approved these changes
Jun 18, 2026
This is to have some visual indication of what is being updated. Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
* Report when an invalid capsule is ignored in InitCapsulePtr(). * Add missing newline to DoResetSystem(). Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
It's optional and similarly comes from coreboot. Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
…ules() call Delay reboot requested during the first call until the second one. Otherwise, the system hangs on displaying update report as console hasn't been initialized yet. Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Based on the corresponding driver in coreboot and FmpDeviceSmmLib. The differences from coreboot are: - not ignoring failures of EC commands - postponing EC reset until firmware initiates a reboot - reporting progress Flash chip's size is passed by coreboot via PCD. Expected firmware image is provided by coreboot table in CBMEM. Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
* Add CAPSULE_EC_FW_GUID macro which, when non-empty, indicates that EC capsule is to be built. * Confine the use of FmpDeviceSmmLib to FmpDxe of the main firmware. * Specify FILE_GUID for CapsuleSplashDxe of the main firmware to be able to be build it separately for EC. * Build FmpDxe and CapsuleSplashDxe for EC firmware with FmpDeviceEcLib and gDasharoPayloadPkgTokenSpaceGuid.PcdEcFirmware set to TRUE respectively. * FILE_GUID for CapsuleSplashDxe can't be the same as for FmpDxe, so the values are hard-coded. Build system is fine with identical GUIDs and mostly works, but at least list of module-specific PCDs gets messed up (because it's likely to be associated with a GUID). Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
We're not making use of it and it can overwrite ESRT with its own version that doesn't match what we want to present. It wasn't noticeable with system firmware capsules because this DXE relies on EFI variables to store its version of ESRT and the variables it tried to create didn't get into the update firmware. This DXE is useful for storing last attempted version and last update status in ESRT, but we use it and a simple attempt to make it work had no effect, so maybe some other time if we'll ever need this functionality. Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Move all non-system capsules to be beginning of the capsule list as updating system firmware disables EFI variables services which breaks LoadImage() and prevents processing any other capsule with embedded drivers (other things are likely to break too). Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
SergiiDmytruk
force-pushed
the
ec-capsules
branch
from
August 23, 2026 21:54
0dec533 to
00a34ad
Compare
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
2 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.
This adds implementation for updating EC in EDK. One file in there is very much like https://github.com/Dasharo/edk2/blob/dasharo/DasharoPayloadPkg/Library/FmpDeviceSmmLib/FmpDeviceSmmLib.c and another one is derived from https://github.com/Dasharo/coreboot/blob/dasharo/src/ec/dasharo/ec/dasharo_ec.c, so it may be easier to review by comparing the new files against those two.
The driver fixes made in coreboot are applied here as well, so makes sense to review them there where diffs are smaller. One change added here is failing if EC didn't reach a state it should be in (coreboot just continues after hitting a timeout), which should be an improvement unless that was a conscious decision when writing coreboot driver. There is also buffer size parameter when reading board name/version and deduplication of two functions.
The splash screen for the update mentions "EC" at the top. No smooth progress or recovery applied here: there are already 3 attempts at flashing and amount of data is small enough for the progress to be OK as is (this also allowed to keep the code close to coreboot).
In addition to a few troubles on coreboot side, there were these:
EsrtDxemessing up ESRT.Update report dialog always reports main firmware's version, maybe that needs to be updated too at some point.
coreboot PR: Dasharo/coreboot#922
issue: Dasharo/dasharo-issues#1758
ref: ncm-2276