Mirrors/u-boot
1
0
Fork 0
mirror of https://source.denx.de/u-boot/u-boot.git synced 2026-06-13 15:03:58 +03:00
Code Issues Packages Projects Releases Wiki Activity

binman: efi: Correct entry docs

Browse Source 
Somehow the class documentation has got out of sync with the generated
entries.rst file. Regenerating it causes errors, so correct these and
regenerate the entries.rst file.

Signed-off-by: Simon Glass <sjg@chromium.org>
Fixes: 809f28e721 ("binman: capsule: Use dumped capsule header...")
This commit is contained in:
Simon Glass
2024-06-23 11:55:02 -06:00
parent 4f02196558
commit e344f836fe
3 changed files with 61 additions and 59 deletions
Download Patch File Download Diff File Expand all files Collapse all files

58
tools/binman/entries.rst
View File

@@ -470,11 +470,11 @@ updating the EC on startup via software sync.
.. _etype_efi_capsule:
Entry: capsule: Entry for generating EFI Capsule files
------------------------------------------------------
Entry: efi-capsule: Generate EFI capsules
-----------------------------------------
The parameters needed for generation of the capsules can be provided
as properties in the entry.
The parameters needed for generation of the capsules can
be provided as properties in the entry.
Properties / Entry arguments:
- image-index: Unique number for identifying corresponding
@@ -495,9 +495,9 @@ Properties / Entry arguments:
file. Mandatory property for generating signed capsules.
- oem-flags - OEM flags to be passed through capsule header.
Since this is a subclass of Entry_section, all properties of the parent
class also apply here. Except for the properties stated as mandatory, the
rest of the properties are optional.
Since this is a subclass of Entry_section, all properties of the parent
class also apply here. Except for the properties stated as mandatory, the
rest of the properties are optional.
For more details on the description of the capsule format, and the capsule
update functionality, refer Section 8.5 and Chapter 23 in the `UEFI
@@ -510,17 +510,17 @@ provided as a subnode of the capsule entry.
A typical capsule entry node would then look something like this::
capsule {
type = "efi-capsule";
image-index = <0x1>;
/* Image GUID for testing capsule update */
image-guid = SANDBOX_UBOOT_IMAGE_GUID;
hardware-instance = <0x0>;
private-key = "path/to/the/private/key";
public-key-cert = "path/to/the/public-key-cert";
oem-flags = <0x8000>;
type = "efi-capsule";
image-index = <0x1>;
/* Image GUID for testing capsule update */
image-guid = SANDBOX_UBOOT_IMAGE_GUID;
hardware-instance = <0x0>;
private-key = "path/to/the/private/key";
public-key-cert = "path/to/the/public-key-cert";
oem-flags = <0x8000>;
u-boot {
};
u-boot {
};
};
In the above example, the capsule payload is the U-Boot image. The
@@ -534,8 +534,8 @@ payload using the blob-ext subnode.
.. _etype_efi_empty_capsule:
Entry: efi-empty-capsule: Entry for generating EFI Empty Capsule files
----------------------------------------------------------------------
Entry: efi-empty-capsule: Generate EFI empty capsules
-----------------------------------------------------
The parameters needed for generation of the empty capsules can
be provided as properties in the entry.
@@ -551,22 +551,22 @@ update functionality, refer Section 8.5 and Chapter 23 in the `UEFI
specification`_. For more information on the empty capsule, refer the
sections 2.3.2 and 2.3.3 in the `Dependable Boot specification`_.
A typical accept empty capsule entry node would then look something
like this::
A typical accept empty capsule entry node would then look something like
this::
empty-capsule {
type = "efi-empty-capsule";
/* GUID of the image being accepted */
image-type-id = SANDBOX_UBOOT_IMAGE_GUID;
capsule-type = "accept";
type = "efi-empty-capsule";
/* GUID of image being accepted */
image-type-id = SANDBOX_UBOOT_IMAGE_GUID;
capsule-type = "accept";
};
A typical revert empty capsule entry node would then look something
like this::
A typical revert empty capsule entry node would then look something like
this::
empty-capsule {
type = "efi-empty-capsule";
capsule-type = "revert";
type = "efi-empty-capsule";
capsule-type = "revert";
};
The empty capsules do not have any input payload image.

40
tools/binman/etype/efi_capsule.py
View File

@@ -36,23 +36,23 @@ class Entry_efi_capsule(Entry_section):
be provided as properties in the entry.
Properties / Entry arguments:
- image-index: Unique number for identifying corresponding
payload image. Number between 1 and descriptor count, i.e.
the total number of firmware images that can be updated. Mandatory
property.
- image-guid: Image GUID which will be used for identifying the
updatable image on the board. Mandatory property.
- hardware-instance: Optional number for identifying unique
hardware instance of a device in the system. Default value of 0
for images where value is not to be used.
- fw-version: Value of image version that can be put on the capsule
through the Firmware Management Protocol(FMP) header.
- monotonic-count: Count used when signing an image.
- private-key: Path to PEM formatted .key private key file. Mandatory
property for generating signed capsules.
- public-key-cert: Path to PEM formatted .crt public key certificate
file. Mandatory property for generating signed capsules.
- oem-flags - OEM flags to be passed through capsule header.
- image-index: Unique number for identifying corresponding
payload image. Number between 1 and descriptor count, i.e.
the total number of firmware images that can be updated. Mandatory
property.
- image-guid: Image GUID which will be used for identifying the
updatable image on the board. Mandatory property.
- hardware-instance: Optional number for identifying unique
hardware instance of a device in the system. Default value of 0
for images where value is not to be used.
- fw-version: Value of image version that can be put on the capsule
through the Firmware Management Protocol(FMP) header.
- monotonic-count: Count used when signing an image.
- private-key: Path to PEM formatted .key private key file. Mandatory
property for generating signed capsules.
- public-key-cert: Path to PEM formatted .crt public key certificate
file. Mandatory property for generating signed capsules.
- oem-flags - OEM flags to be passed through capsule header.
Since this is a subclass of Entry_section, all properties of the parent
class also apply here. Except for the properties stated as mandatory, the
@@ -66,9 +66,9 @@ class Entry_efi_capsule(Entry_section):
properties in the entry. The payload to be used in the capsule is to be
provided as a subnode of the capsule entry.
A typical capsule entry node would then look something like this
A typical capsule entry node would then look something like this::
capsule {
capsule {
type = "efi-capsule";
image-index = <0x1>;
/* Image GUID for testing capsule update */
@@ -80,7 +80,7 @@ class Entry_efi_capsule(Entry_section):
u-boot {
};
};
};
In the above example, the capsule payload is the U-Boot image. The
capsule entry would read the contents of the payload and put them

22
tools/binman/etype/efi_empty_capsule.py
View File

@@ -19,31 +19,33 @@ class Entry_efi_empty_capsule(Entry_section):
be provided as properties in the entry.
Properties / Entry arguments:
- image-guid: Image GUID which will be used for identifying the
updatable image on the board. Mandatory for accept capsule.
- capsule-type - String to indicate type of capsule to generate. Valid
values are 'accept' and 'revert'.
- image-guid: Image GUID which will be used for identifying the
updatable image on the board. Mandatory for accept capsule.
- capsule-type - String to indicate type of capsule to generate. Valid
values are 'accept' and 'revert'.
For more details on the description of the capsule format, and the capsule
update functionality, refer Section 8.5 and Chapter 23 in the `UEFI
specification`_. For more information on the empty capsule, refer the
sections 2.3.2 and 2.3.3 in the `Dependable Boot specification`_.
A typical accept empty capsule entry node would then look something like this
A typical accept empty capsule entry node would then look something like
this::
empty-capsule {
empty-capsule {
type = "efi-empty-capsule";
/* GUID of image being accepted */
image-type-id = SANDBOX_UBOOT_IMAGE_GUID;
capsule-type = "accept";
};
};
A typical revert empty capsule entry node would then look something like this
A typical revert empty capsule entry node would then look something like
this::
empty-capsule {
empty-capsule {
type = "efi-empty-capsule";
capsule-type = "revert";
};
};
The empty capsules do not have any input payload image.