[PATCH v3 01/19] doc: uefi: capsules: Start Capsule Update porting section

[Ilias Apalodimas]

Thanks, Jonathan

We also plan on adding a Kconfig option that will autogenerate GUIDs
for such cases, but this is useful

On Fri, 19 Apr 2024 at 23:57, Jonathan Humphreys <j-humphreys at ti.com> wrote:
>
> Created a capsule update porting section in the documentation that outlines the
> steps a board developer must do when porting from an existing reference board
> implementation.
>
> In particular, added a big warning that new capsule GUID's need to be defined.
>
> Signed-off-by: Jonathan Humphreys <j-humphreys at ti.com>
> ---
>  doc/develop/uefi/uefi.rst | 12 ++++++++++++
>  1 file changed, 12 insertions(+)
>
> diff --git a/doc/develop/uefi/uefi.rst b/doc/develop/uefi/uefi.rst
> index 0389b269c01..36ac75278fa 100644
> --- a/doc/develop/uefi/uefi.rst
> +++ b/doc/develop/uefi/uefi.rst
> @@ -631,6 +631,18 @@ where version.dtso looks like::
>  The properties of image-type-id and image-index must match the value
>  defined in the efi_fw_image array as image_type_id and image_index.
>
> +Porting Capsule Updates to new boards
> +*************************************
> +
> +It is important, when using a reference board as a starting point for a custom
> +board, that certain steps are taken to properly support Capsule Updates.
> +
> +Capsule GUIDs need to be unique for each firmware and board. >That is, if two
> +firmwares are built from the same source but result in different binaries
> +because they are built for different boards, they should have different GUIDs.
> +Therefore it is important when creating support for a new board, new GUIDs are
> +defined in the board's header file.  *DO NOT* reuse capsule GUIDs.
> +
>  Executing the boot manager
>  ~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> --
> 2.34.1
>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas at linaro.org>