| Message ID | 20230725085725.350917-9-sughosh.ganu@linaro.org |
|---|---|
| State | New |
| Headers | show |
| Series | Integrate EFI capsule tasks into u-boot's build flow | expand |
On 25.07.23 10:57, Sughosh Ganu wrote: > The UEFI capsule can now be generate by specifying the capsule > parameters through a config file. Additionally, the capsules can be > generated as part of u-boot build, through binman. Highlight these > changes in the documentation. > > Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org> > --- > Changes since V4: None > > doc/develop/uefi/uefi.rst | 84 +++++++++++++++++++++++++++++++++++++++ > 1 file changed, 84 insertions(+) > > diff --git a/doc/develop/uefi/uefi.rst b/doc/develop/uefi/uefi.rst > index b2854b52a6..29955d943e 100644 > --- a/doc/develop/uefi/uefi.rst > +++ b/doc/develop/uefi/uefi.rst > @@ -318,6 +318,79 @@ Run the following command > --guid <image GUID> \ > <capsule_file_name> > > +Alternatively, the capsules can be generated through a config > +file. When generating the capsules through a config file, the Kconfig > +symbol CONFIG_EFI_CAPSULE_CFG_FILE is to be used for specifying the > +path to the config file. > + > +The config file describes the parameters that are used for generating > +one or more capsules. The parameters for a given capsule file are > +specified within curly braces, in the form of "key:value" pairs. All > +the parameters that are currently supported by the mkeficapsule tool > +can be specified through the config file. > + > +The following are some example payload parameters specified through > +the config file. > + > +.. code-block:: none > + > + { > + image-guid: 02f4d760-cfd5-43bd-8e2d-a42acb33c660 > + hardware-instance: 0 > + monotonic-count: 1 > + payload: u-boot.bin > + image-index: 1 > + fw-version: 2 > + private-key: /path/to/priv/key > + pub-key-cert: /path/to/pub/key > + capsule: u-boot.capsule > + } > + { > + image-guid: 4ce292da-1dd8-428d-a1c2-77743ef8b96e > + hardware-instance: 0 > + payload: u-boot.itb > + image-index: 2 > + fw-version: 7 > + oemflags: 0x8000 > + capsule: fit.capsule > + } > + { > + capsule-type: accept > + image-guid: 4ce292da-1dd8-428d-a1c2-77743ef8b96e > + capsule: accept.capsule > + } > + { > + capsule-type: revert > + capsule: revert.capsule > + } This seems to be neither YAML nor JSON. Can't we use a standardized format? YAML is easily parsed in C with libfyaml (see https://www.wpsoftware.net/andrew/pages/libyaml.html). Best regards Heinrich > + > +The following are the keys that specify the capsule parameters > + > +..code-block:: none > + > + image-guid: Image GUID > + image-index: Image index value > + fw-version: Image version > + private-key: Path to the private key file used for capsule signing > + pub-key-cert: Path to the public key crt file used for capsule signing > + payload: Path to the capsule payload file > + capsule: Path to the output capsule file that is generated > + hardware-instance: Hardware Instance value > + monotonic-count: Monotonic count value > + capsule-type: Specifies capsule type. normal(default), accept or revert > + oemflags: 16bit Oemflags value to be used(populated in capsule header) > + > +When generating capsules through a config file, the command would look > +like > + > +.. code-block:: console > + > + $ mkeficapsule --cfg-file </path/to/the/config/file> > + > + > +Capsule with firmware version > +***************************** > + > The UEFI specification does not define the firmware versioning mechanism. > EDK II reference implementation inserts the FMP Payload Header right before > the payload. It coutains the fw_version and lowest supported version, > @@ -345,6 +418,17 @@ add --fw-version option in mkeficapsule tool. > If the --fw-version option is not set, FMP Payload Header is not inserted > and fw_version is set as 0. > > + > +Capsule Generation through binman > +********************************* > + > +Support has also been added to generate capsules during u-boot build > +through binman. This requires the platform's DTB to be populated with > +the capsule entry nodes for binman. The capsules then can be generated > +by specifying the capsule parameters either through a config file, or > +by specifying them as properties in the capsule entry node. > + > + > Performing the update > ********************* >
Hi, On Tue, 25 Jul 2023 at 10:18, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote: > > On 25.07.23 10:57, Sughosh Ganu wrote: > > The UEFI capsule can now be generate by specifying the capsule > > parameters through a config file. Additionally, the capsules can be > > generated as part of u-boot build, through binman. Highlight these > > changes in the documentation. > > > > Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org> > > --- > > Changes since V4: None > > > > doc/develop/uefi/uefi.rst | 84 +++++++++++++++++++++++++++++++++++++++ > > 1 file changed, 84 insertions(+) > > > > diff --git a/doc/develop/uefi/uefi.rst b/doc/develop/uefi/uefi.rst > > index b2854b52a6..29955d943e 100644 > > --- a/doc/develop/uefi/uefi.rst > > +++ b/doc/develop/uefi/uefi.rst > > @@ -318,6 +318,79 @@ Run the following command > > --guid <image GUID> \ > > <capsule_file_name> > > > > +Alternatively, the capsules can be generated through a config > > +file. When generating the capsules through a config file, the Kconfig > > +symbol CONFIG_EFI_CAPSULE_CFG_FILE is to be used for specifying the > > +path to the config file. > > + > > +The config file describes the parameters that are used for generating > > +one or more capsules. The parameters for a given capsule file are > > +specified within curly braces, in the form of "key:value" pairs. All > > +the parameters that are currently supported by the mkeficapsule tool > > +can be specified through the config file. > > + > > +The following are some example payload parameters specified through > > +the config file. > > + > > +.. code-block:: none > > + > > + { > > + image-guid: 02f4d760-cfd5-43bd-8e2d-a42acb33c660 > > + hardware-instance: 0 > > + monotonic-count: 1 > > + payload: u-boot.bin > > + image-index: 1 > > + fw-version: 2 > > + private-key: /path/to/priv/key > > + pub-key-cert: /path/to/pub/key > > + capsule: u-boot.capsule > > + } > > + { > > + image-guid: 4ce292da-1dd8-428d-a1c2-77743ef8b96e > > + hardware-instance: 0 > > + payload: u-boot.itb > > + image-index: 2 > > + fw-version: 7 > > + oemflags: 0x8000 > > + capsule: fit.capsule > > + } > > + { > > + capsule-type: accept > > + image-guid: 4ce292da-1dd8-428d-a1c2-77743ef8b96e > > + capsule: accept.capsule > > + } > > + { > > + capsule-type: revert > > + capsule: revert.capsule > > + } > > This seems to be neither YAML nor JSON. Can't we use a standardized > format? YAML is easily parsed in C with libfyaml (see > https://www.wpsoftware.net/andrew/pages/libyaml.html). Can we please get this series landed without the config file at first? If it useful we can add it later, but it is a complexity that is not necessary for an initial series. Regards, Simon
hi Simon, On Wed, 26 Jul 2023 at 04:24, Simon Glass <sjg@chromium.org> wrote: > > Hi, > > On Tue, 25 Jul 2023 at 10:18, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote: > > > > On 25.07.23 10:57, Sughosh Ganu wrote: > > > The UEFI capsule can now be generate by specifying the capsule > > > parameters through a config file. Additionally, the capsules can be > > > generated as part of u-boot build, through binman. Highlight these > > > changes in the documentation. > > > > > > Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org> > > > --- > > > Changes since V4: None > > > > > > doc/develop/uefi/uefi.rst | 84 +++++++++++++++++++++++++++++++++++++++ > > > 1 file changed, 84 insertions(+) > > > > > > diff --git a/doc/develop/uefi/uefi.rst b/doc/develop/uefi/uefi.rst > > > index b2854b52a6..29955d943e 100644 > > > --- a/doc/develop/uefi/uefi.rst > > > +++ b/doc/develop/uefi/uefi.rst > > > @@ -318,6 +318,79 @@ Run the following command > > > --guid <image GUID> \ > > > <capsule_file_name> > > > > > > +Alternatively, the capsules can be generated through a config > > > +file. When generating the capsules through a config file, the Kconfig > > > +symbol CONFIG_EFI_CAPSULE_CFG_FILE is to be used for specifying the > > > +path to the config file. > > > + > > > +The config file describes the parameters that are used for generating > > > +one or more capsules. The parameters for a given capsule file are > > > +specified within curly braces, in the form of "key:value" pairs. All > > > +the parameters that are currently supported by the mkeficapsule tool > > > +can be specified through the config file. > > > + > > > +The following are some example payload parameters specified through > > > +the config file. > > > + > > > +.. code-block:: none > > > + > > > + { > > > + image-guid: 02f4d760-cfd5-43bd-8e2d-a42acb33c660 > > > + hardware-instance: 0 > > > + monotonic-count: 1 > > > + payload: u-boot.bin > > > + image-index: 1 > > > + fw-version: 2 > > > + private-key: /path/to/priv/key > > > + pub-key-cert: /path/to/pub/key > > > + capsule: u-boot.capsule > > > + } > > > + { > > > + image-guid: 4ce292da-1dd8-428d-a1c2-77743ef8b96e > > > + hardware-instance: 0 > > > + payload: u-boot.itb > > > + image-index: 2 > > > + fw-version: 7 > > > + oemflags: 0x8000 > > > + capsule: fit.capsule > > > + } > > > + { > > > + capsule-type: accept > > > + image-guid: 4ce292da-1dd8-428d-a1c2-77743ef8b96e > > > + capsule: accept.capsule > > > + } > > > + { > > > + capsule-type: revert > > > + capsule: revert.capsule > > > + } > > > > This seems to be neither YAML nor JSON. Can't we use a standardized > > format? YAML is easily parsed in C with libfyaml (see > > https://www.wpsoftware.net/andrew/pages/libyaml.html). > > Can we please get this series landed without the config file at first? > If it useful we can add it later, but it is a complexity that is not > necessary for an initial series. We do need support for generation of capsules through the config file. There is another patchset [1] which will be leveraging generation of capsules through the config file. I believe AMD(Xilinx) too is looking for support of such functionality, whereby the capsule gets generated after reading the parameters from the config file. Not being able to generate capsules through the config file as part of the build would be a half baked support. In my earlier reply [2] to your concern about using relative paths for capsule generation, I had mentioned that if we cannot extend binman tests to use absolute paths, we can drop testing this scenario in the binman tests suite since this feature is actually getting tested as part of the larger EFI capsule update feature testing. Would that not be okay with you? Else we have the option of using absolute paths for the indir and outdir, instead of the runtime generated directories, only for this feature test of course. -sughosh [1] - https://lists.denx.de/pipermail/u-boot/2023-June/520407.html [2] - https://lists.denx.de/pipermail/u-boot/2023-July/523779.html
hi Heinrich, On Tue, 25 Jul 2023 at 21:42, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote: > > On 25.07.23 10:57, Sughosh Ganu wrote: > > The UEFI capsule can now be generate by specifying the capsule > > parameters through a config file. Additionally, the capsules can be > > generated as part of u-boot build, through binman. Highlight these > > changes in the documentation. > > > > Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org> > > --- > > Changes since V4: None > > > > doc/develop/uefi/uefi.rst | 84 +++++++++++++++++++++++++++++++++++++++ > > 1 file changed, 84 insertions(+) > > > > diff --git a/doc/develop/uefi/uefi.rst b/doc/develop/uefi/uefi.rst > > index b2854b52a6..29955d943e 100644 > > --- a/doc/develop/uefi/uefi.rst > > +++ b/doc/develop/uefi/uefi.rst > > @@ -318,6 +318,79 @@ Run the following command > > --guid <image GUID> \ > > <capsule_file_name> > > > > +Alternatively, the capsules can be generated through a config > > +file. When generating the capsules through a config file, the Kconfig > > +symbol CONFIG_EFI_CAPSULE_CFG_FILE is to be used for specifying the > > +path to the config file. > > + > > +The config file describes the parameters that are used for generating > > +one or more capsules. The parameters for a given capsule file are > > +specified within curly braces, in the form of "key:value" pairs. All > > +the parameters that are currently supported by the mkeficapsule tool > > +can be specified through the config file. > > + > > +The following are some example payload parameters specified through > > +the config file. > > + > > +.. code-block:: none > > + > > + { > > + image-guid: 02f4d760-cfd5-43bd-8e2d-a42acb33c660 > > + hardware-instance: 0 > > + monotonic-count: 1 > > + payload: u-boot.bin > > + image-index: 1 > > + fw-version: 2 > > + private-key: /path/to/priv/key > > + pub-key-cert: /path/to/pub/key > > + capsule: u-boot.capsule > > + } > > + { > > + image-guid: 4ce292da-1dd8-428d-a1c2-77743ef8b96e > > + hardware-instance: 0 > > + payload: u-boot.itb > > + image-index: 2 > > + fw-version: 7 > > + oemflags: 0x8000 > > + capsule: fit.capsule > > + } > > + { > > + capsule-type: accept > > + image-guid: 4ce292da-1dd8-428d-a1c2-77743ef8b96e > > + capsule: accept.capsule > > + } > > + { > > + capsule-type: revert > > + capsule: revert.capsule > > + } > > This seems to be neither YAML nor JSON. Can't we use a standardized > format? YAML is easily parsed in C with libfyaml (see > https://www.wpsoftware.net/andrew/pages/libyaml.html). I used this key:value format since I wanted to keep this as close to the one used in EDK2 as possible. EDK2 does use json files, but the format is very similar to what I have introduced here. I have attached a file for your reference. -sughosh > > Best regards > > Heinrich > > > + > > +The following are the keys that specify the capsule parameters > > + > > +..code-block:: none > > + > > + image-guid: Image GUID > > + image-index: Image index value > > + fw-version: Image version > > + private-key: Path to the private key file used for capsule signing > > + pub-key-cert: Path to the public key crt file used for capsule signing > > + payload: Path to the capsule payload file > > + capsule: Path to the output capsule file that is generated > > + hardware-instance: Hardware Instance value > > + monotonic-count: Monotonic count value > > + capsule-type: Specifies capsule type. normal(default), accept or revert > > + oemflags: 16bit Oemflags value to be used(populated in capsule header) > > + > > +When generating capsules through a config file, the command would look > > +like > > + > > +.. code-block:: console > > + > > + $ mkeficapsule --cfg-file </path/to/the/config/file> > > + > > + > > +Capsule with firmware version > > +***************************** > > + > > The UEFI specification does not define the firmware versioning mechanism. > > EDK II reference implementation inserts the FMP Payload Header right before > > the payload. It coutains the fw_version and lowest supported version, > > @@ -345,6 +418,17 @@ add --fw-version option in mkeficapsule tool. > > If the --fw-version option is not set, FMP Payload Header is not inserted > > and fw_version is set as 0. > > > > + > > +Capsule Generation through binman > > +********************************* > > + > > +Support has also been added to generate capsules during u-boot build > > +through binman. This requires the platform's DTB to be populated with > > +the capsule entry nodes for binman. The capsules then can be generated > > +by specifying the capsule parameters either through a config file, or > > +by specifying them as properties in the capsule entry node. > > + > > + > > Performing the update > > ********************* > > >
Hi Sughosh, On Wed, 26 Jul 2023 at 03:17, Sughosh Ganu <sughosh.ganu@linaro.org> wrote: > > hi Simon, > > On Wed, 26 Jul 2023 at 04:24, Simon Glass <sjg@chromium.org> wrote: > > > > Hi, > > > > On Tue, 25 Jul 2023 at 10:18, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote: > > > > > > On 25.07.23 10:57, Sughosh Ganu wrote: > > > > The UEFI capsule can now be generate by specifying the capsule > > > > parameters through a config file. Additionally, the capsules can be > > > > generated as part of u-boot build, through binman. Highlight these > > > > changes in the documentation. > > > > > > > > Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org> > > > > --- > > > > Changes since V4: None > > > > > > > > doc/develop/uefi/uefi.rst | 84 +++++++++++++++++++++++++++++++++++++++ > > > > 1 file changed, 84 insertions(+) > > > > > > > > diff --git a/doc/develop/uefi/uefi.rst b/doc/develop/uefi/uefi.rst > > > > index b2854b52a6..29955d943e 100644 > > > > --- a/doc/develop/uefi/uefi.rst > > > > +++ b/doc/develop/uefi/uefi.rst > > > > @@ -318,6 +318,79 @@ Run the following command > > > > --guid <image GUID> \ > > > > <capsule_file_name> > > > > > > > > +Alternatively, the capsules can be generated through a config > > > > +file. When generating the capsules through a config file, the Kconfig > > > > +symbol CONFIG_EFI_CAPSULE_CFG_FILE is to be used for specifying the > > > > +path to the config file. > > > > + > > > > +The config file describes the parameters that are used for generating > > > > +one or more capsules. The parameters for a given capsule file are > > > > +specified within curly braces, in the form of "key:value" pairs. All > > > > +the parameters that are currently supported by the mkeficapsule tool > > > > +can be specified through the config file. > > > > + > > > > +The following are some example payload parameters specified through > > > > +the config file. > > > > + > > > > +.. code-block:: none > > > > + > > > > + { > > > > + image-guid: 02f4d760-cfd5-43bd-8e2d-a42acb33c660 > > > > + hardware-instance: 0 > > > > + monotonic-count: 1 > > > > + payload: u-boot.bin > > > > + image-index: 1 > > > > + fw-version: 2 > > > > + private-key: /path/to/priv/key > > > > + pub-key-cert: /path/to/pub/key > > > > + capsule: u-boot.capsule > > > > + } > > > > + { > > > > + image-guid: 4ce292da-1dd8-428d-a1c2-77743ef8b96e > > > > + hardware-instance: 0 > > > > + payload: u-boot.itb > > > > + image-index: 2 > > > > + fw-version: 7 > > > > + oemflags: 0x8000 > > > > + capsule: fit.capsule > > > > + } > > > > + { > > > > + capsule-type: accept > > > > + image-guid: 4ce292da-1dd8-428d-a1c2-77743ef8b96e > > > > + capsule: accept.capsule > > > > + } > > > > + { > > > > + capsule-type: revert > > > > + capsule: revert.capsule > > > > + } > > > > > > This seems to be neither YAML nor JSON. Can't we use a standardized > > > format? YAML is easily parsed in C with libfyaml (see > > > https://www.wpsoftware.net/andrew/pages/libyaml.html). > > > > Can we please get this series landed without the config file at first? > > If it useful we can add it later, but it is a complexity that is not > > necessary for an initial series. > > We do need support for generation of capsules through the config file. > There is another patchset [1] which will be leveraging generation of > capsules through the config file. I believe AMD(Xilinx) too is looking > for support of such functionality, whereby the capsule gets generated > after reading the parameters from the config file. Not being able to > generate capsules through the config file as part of the build would > be a half baked support. Well let's drop it for now. It is creating a parallel description format when we are trying to have just one (binman). > > In my earlier reply [2] to your concern about using relative paths for > capsule generation, I had mentioned that if we cannot extend binman > tests to use absolute paths, we can drop testing this scenario in the > binman tests suite since this feature is actually getting tested as > part of the larger EFI capsule update feature testing. Would that not > be okay with you? Else we have the option of using absolute paths for > the indir and outdir, instead of the runtime generated directories, > only for this feature test of course. No, let's drop the config file for now. It is making everything too confusing. Regards, Simon > > -sughosh > > [1] - https://lists.denx.de/pipermail/u-boot/2023-June/520407.html > [2] - https://lists.denx.de/pipermail/u-boot/2023-July/523779.html
diff --git a/doc/develop/uefi/uefi.rst b/doc/develop/uefi/uefi.rst index b2854b52a6..29955d943e 100644 --- a/doc/develop/uefi/uefi.rst +++ b/doc/develop/uefi/uefi.rst @@ -318,6 +318,79 @@ Run the following command --guid <image GUID> \ <capsule_file_name> +Alternatively, the capsules can be generated through a config +file. When generating the capsules through a config file, the Kconfig +symbol CONFIG_EFI_CAPSULE_CFG_FILE is to be used for specifying the +path to the config file. + +The config file describes the parameters that are used for generating +one or more capsules. The parameters for a given capsule file are +specified within curly braces, in the form of "key:value" pairs. All +the parameters that are currently supported by the mkeficapsule tool +can be specified through the config file. + +The following are some example payload parameters specified through +the config file. + +.. code-block:: none + + { + image-guid: 02f4d760-cfd5-43bd-8e2d-a42acb33c660 + hardware-instance: 0 + monotonic-count: 1 + payload: u-boot.bin + image-index: 1 + fw-version: 2 + private-key: /path/to/priv/key + pub-key-cert: /path/to/pub/key + capsule: u-boot.capsule + } + { + image-guid: 4ce292da-1dd8-428d-a1c2-77743ef8b96e + hardware-instance: 0 + payload: u-boot.itb + image-index: 2 + fw-version: 7 + oemflags: 0x8000 + capsule: fit.capsule + } + { + capsule-type: accept + image-guid: 4ce292da-1dd8-428d-a1c2-77743ef8b96e + capsule: accept.capsule + } + { + capsule-type: revert + capsule: revert.capsule + } + +The following are the keys that specify the capsule parameters + +..code-block:: none + + image-guid: Image GUID + image-index: Image index value + fw-version: Image version + private-key: Path to the private key file used for capsule signing + pub-key-cert: Path to the public key crt file used for capsule signing + payload: Path to the capsule payload file + capsule: Path to the output capsule file that is generated + hardware-instance: Hardware Instance value + monotonic-count: Monotonic count value + capsule-type: Specifies capsule type. normal(default), accept or revert + oemflags: 16bit Oemflags value to be used(populated in capsule header) + +When generating capsules through a config file, the command would look +like + +.. code-block:: console + + $ mkeficapsule --cfg-file </path/to/the/config/file> + + +Capsule with firmware version +***************************** + The UEFI specification does not define the firmware versioning mechanism. EDK II reference implementation inserts the FMP Payload Header right before the payload. It coutains the fw_version and lowest supported version, @@ -345,6 +418,17 @@ add --fw-version option in mkeficapsule tool. If the --fw-version option is not set, FMP Payload Header is not inserted and fw_version is set as 0. + +Capsule Generation through binman +********************************* + +Support has also been added to generate capsules during u-boot build +through binman. This requires the platform's DTB to be populated with +the capsule entry nodes for binman. The capsules then can be generated +by specifying the capsule parameters either through a config file, or +by specifying them as properties in the capsule entry node. + + Performing the update *********************
The UEFI capsule can now be generate by specifying the capsule parameters through a config file. Additionally, the capsules can be generated as part of u-boot build, through binman. Highlight these changes in the documentation. Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org> --- Changes since V4: None doc/develop/uefi/uefi.rst | 84 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 84 insertions(+)