Hi Caleb, On Wed, 29 May 2024 at 08:49, Caleb Connolly <caleb.conno...@linaro.org> wrote: > > As more boards adopt support for the EFI CapsuleUpdate mechanism, there > is a growing issue of being able to target updates to them properly. The > current mechanism of hardcoding UUIDs for each board at compile time is > unsustainable, and maintaining lists of GUIDs is similarly cumbersome. > > In this series, I propose that we adopt v5 GUIDs, these are generated > by using a well-known salt GUID as well as board specific information > (like the model/revision), these are hashed together and the result is > truncated to form a new UUID. > > The well-known salt GUID can be specific to the architecture (SoC > vendor), or OEM. It is defined in the board defconfig so that vendors > can easily bring their own. > > Specifically, the following fields are used to generate a GUID for a > particular fw_image: > > * namespace salt > * board compatible (usually the first entry in the dt root compatible > array). > * fw_image name (the string identifying the specific image, especially > relevant for board that can update multiple images). > > == Usage == > > Boards can integrate dynamic UUID support as follows: > > 1. Adjust Kconfig to depend on EFI_CAPSULE_DYNAMIC_UUIDS if > EFI_HAVE_CAPSULE_SUPPORT. > 2. Skip setting the fw_images image_type_id property. > 3. Generate a UUID and set CONFIG_EFI_CAPSULE_NAMESPACE_UUID in your > defconfig. > > == Limitations == > > * Changing GUIDs > > The primary limitation with this approach is that if any of the source > fields change, so will the GUID for the board. It is therefore pretty > important to ensure that GUID changes are caught during development. > > * Supporting multiple boards with a single image > > This now requires having an entry with the GUID for every board which > might lead to larger UpdateCapsule images. > > == Tooling == > > This series introduces a new tool: genguid. This can be used to generate > the same GUIDs that the board would at runtime. > > This series follows a related discussion started by Ilias: > https://lore.kernel.org/u-boot/cac_iwjjnha4gmf897mqyzndbgjfg8k4kwgstxwuy72wkyli...@mail.gmail.com/ > > To: Tom Rini <tr...@konsulko.com> > To: Heinrich Schuchardt <xypron.g...@gmx.de> > To: Ilias Apalodimas <ilias.apalodi...@linaro.org> > To: Simon Glass <s...@chromium.org> > To: Mario Six <mario....@gdsys.cc> > To: Alper Nebi Yasak <alpernebiya...@gmail.com> > To: Abdellatif El Khlifi <abdellatif.elkhl...@arm.com> > Cc: Richard Hughes <hughsi...@gmail.com> > Cc: u-boot@lists.denx.de > > Changes in v2: > - Move namespace UUID to be defined in defconfig > - Add tests and tooling > - Only use the first board compatible to generate UUID. > - Link to v1: > https://lore.kernel.org/r/20240426-b4-dynamic-uuid-v1-0-e8154e00e...@linaro.org > > --- > Caleb Connolly (7): > lib: uuid: add UUID v5 support > efi: add a helper to generate dynamic UUIDs > doc: uefi: document dynamic UUID generation > sandbox: switch to dynamic UUIDs > lib: uuid: supporting building as part of host tools > tools: add genguid tool > test: lib/uuid: add unit tests for dynamic UUIDs > > arch/Kconfig | 1 + > board/sandbox/sandbox.c | 16 --- > configs/sandbox_defconfig | 1 + > configs/sandbox_flattree_defconfig | 1 + > doc/develop/uefi/uefi.rst | 31 +++++ > include/sandbox_efi_capsule.h | 6 +- > include/uuid.h | 21 ++- > lib/Kconfig | 8 ++ > lib/efi_loader/Kconfig | 23 +++ > lib/efi_loader/efi_capsule.c | 1 + > lib/efi_loader/efi_firmware.c | 66 +++++++++ > lib/uuid.c | 81 +++++++++-- > test/lib/uuid.c | 90 ++++++++++++ > .../test_efi_capsule/test_capsule_firmware_fit.py | 2 +- > .../test_efi_capsule/test_capsule_firmware_raw.py | 8 +- > .../test_capsule_firmware_signed_fit.py | 2 +- > .../test_capsule_firmware_signed_raw.py | 4 +- > test/py/tests/test_efi_capsule/version.dts | 6 +- > tools/Makefile | 3 + > tools/binman/etype/efi_capsule.py | 2 +- > tools/binman/ftest.py | 2 +- > tools/genguid.c | 154 > +++++++++++++++++++++ > 22 files changed, 481 insertions(+), 48 deletions(-) > --- > change-id: 20240422-b4-dynamic-uuid-1a5ab1486c27 > base-commit: 2e682a4a406fc81ef32e05c28542cc8067f1e15f >
How about using the compatible string, instead of a GUID? Is that possible? Regards, Simon
