Hi Richard, On Thu, 25 Apr 2024 at 15:28, Richard Hughes <hughsi...@gmail.com> wrote: > > Hi all! > > > Any ODM/OEM creating a board > > based on the original device must use his own > > GUIID to avoid confusion. If not we would end up with different > > devices reusing the same GUIDs and upgrading their firmware with a > > different one. > > Yes and no. Of course it's never okay for vendor A to use the same > GUID as vendor B -- but if vendor A has two models of hardware (for > instance model C and model D) they can have the same capsule GUID if > the update can use a DMI match on the product SMBIOS key to identify > the system.
In theory, yes but we don't have any of these check in u-boot and I'd rather avoid them and do it properly > Of course, it's much better if they have different GUIDs > in the ESRT to completely avoid the chance of the wrong firmware being > flashed on the wrong device. Exactly. > > > Richard, the following GUIDs should at least issue a warning in LVFS > > since they only work for QEMU & Sandbox internally. > > Sandbox SANDBOX_UBOOT_IMAGE_GUID 09d7cf52-0720-4710-91d1-08469b7fe9c8 > > Sandbox SANDBOX_UBOOT_ENV_IMAGE 5a7021f5-fef2-48b4-aaba-832e777418c0 > > Sandbox SANDBOX_FIT_IMAGE_GUID 3673b45d-6a7c-46f3-9e60-adabb03f7937 > > QEMU QEMU_ARM_UBOOT_IMAGE_GUID f885b085-99f8-45af-847d-d514107a4a2c > > QEMU QEMU_ARM64_UBOOT_IMAGE 058b7d83-50d5-4c47-a195-60d86ad341c4 > > Are these GUIDs that should be "never allow a firmware to be moved to > the stable remote if it uses this GUID" or more "a firmware also needs > a DMI restriction before being allowed near stable"? I'd err on the > former for these. TBH those are GUIDs that are used by virtual devices. It wouldn't hurt if someone reused those GUIDs but we can display a warning about it? > > > I've cc'ed all the people I could find in board specific MAINTAINER files. > > Can you respond to Richard with the proper company name & board name > > so we can bind the following GUIDs to a vendor properly? > > Richard any guidance on how this should be done properly is > > appreciated, since I am not too aware of LVFS internals. > > The LVFS doesn't need "pre-registration" of GUIDs so to speak; we have > have two deny lists of GUIDs -- one for "this is never valid" and one > for the "this needs a DMI match" Ok thanks for the info. Is there also a check of "I have duplicate GUIDs that aren't in the DMI list'? > > > STMicroelectronics STM32MP_FIP_IMAGE_GUID > > 19d5df83-11b0-457b-be2c-7559c13142a5 > > This seems to use the same GUID for multiple device variants. This > > needs to be fixed > > Is the DMI data different? e.g. you can see the Windows CHIDs (we use > the same DMI restriction scheme as Window 10) using > ComputerHardwareIds.exe or on Linux using `sudo fwupdtool hwids` I hope ST answers that, they are cc'ed > > I've created a spreadsheet of what we do now, please feel free to add > GUIDs (anybody!) to the correct column: > https://docs.google.com/spreadsheets/d/1uPQmUrGA1KKsDPzGeg4xb2XOQEfsjDBBP9SQjqh31Wc/edit?usp=sharing Thanks! /Ilias > > Thanks, > > Richard.