[PATCH v2 02/43] binman: efi: Correct entry docs
Simon Glass
sjg at chromium.org
Fri Jun 21 21:51:23 CEST 2024
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 at chromium.org>
Fixes: 809f28e7213 ("binman: capsule: Use dumped capsule header...")
---
(no changes since v1)
tools/binman/entries.rst | 58 ++++++++++++-------------
tools/binman/etype/efi_capsule.py | 40 ++++++++---------
tools/binman/etype/efi_empty_capsule.py | 22 +++++-----
3 files changed, 61 insertions(+), 59 deletions(-)
diff --git a/tools/binman/entries.rst b/tools/binman/entries.rst
index 86a3c02b485..531a92e2e0c 100644
--- a/tools/binman/entries.rst
+++ b/tools/binman/entries.rst
@@ -477,11 +477,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
@@ -502,9 +502,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
@@ -517,17 +517,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
@@ -541,8 +541,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.
@@ -558,22 +558,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.
diff --git a/tools/binman/etype/efi_capsule.py b/tools/binman/etype/efi_capsule.py
index e3203717822..751f654bf31 100644
--- a/tools/binman/etype/efi_capsule.py
+++ b/tools/binman/etype/efi_capsule.py
@@ -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
diff --git a/tools/binman/etype/efi_empty_capsule.py b/tools/binman/etype/efi_empty_capsule.py
index 064bf9a77f0..1d99fbfb3bb 100644
--- a/tools/binman/etype/efi_empty_capsule.py
+++ b/tools/binman/etype/efi_empty_capsule.py
@@ -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.
--
2.34.1
More information about the U-Boot
mailing list