Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Recommend usage of partition type GUIDs to find firmware #106

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Recommend usage of partition type GUIDs to find firmware #106

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 7 additions & 0 deletions source/chapter4-firmware-media.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -117,6 +117,13 @@ non-protective partitions).
There are no requirements on the contents or layout of the firmware
protective partition.

Devices should use the partition type GUID to identify the partition with
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit-picking: I think I would prefer "platforms" or even "SoCs" instead of "devices".

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree that a renaming would clear it up.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Call of May 22: replace "devices" by "boot firmware" (boot rom or e.g. u-boot spl or later stage) and replace "firmware" by "next boot stage".

the firmware to load. This is preferable over fixed sector or partition
numbers as it imposes the least restrictions on the partitioning scheme.

Firmware partition type GUIDs should be unique for a board type. This
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit-picking: to address #106 (comment) I wonder if we could rather link the GUID to the firmware "type" or "family" instead.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The target is to be able to create an image that can boot multiple boards. If we use a single GUID, e.g. for U-Boot SPL, this is not possible. Instead the GUID must be specific to the board or SoC specific flavor of the boot stage.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So "board type" means one GUID by each supported board reference ?

For example today in TF-A, we are using the same FIP GUID for all boards ussing a STM32MP SoC
(STM32MP15x and STM32MP13x)
=> the recommandation to have a different type GUID by board reference ?

in plat/st/common/include/stm32mp_efi.h

#define STM32MP_FIP_GUID
EFI_GUID(0x19d5df83U, 0x11b0U, 0x457bU,
0xbeU, 0x2cU, 0x75U, 0x59U, 0xc1U, 0x31U, 0x42U, 0xa5U)

the supported board are:
STM32MP157F-DK2
STM32MP157F-DK1
STM32MP157F-EV1
STM32MP135F-DK
.....

=> "creating media that can be booted on a multitude of boards"

For me it is possible only if TF-A BL2 is not board specific
and if the associated FIP not located in the same media than this TF-A BL2
(for example TF-A BL2 in NOR and external media as SD-Card)

as normally the ROM code load the next boot stage = TF-A BL2 on a fixed location (offset or partition) on this media.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@patrickdelaunay for the EV, you should place your FIP into the eMMC boot partition after the TF-A, so you can use the exact same image on eMMC user area across boards. For the DKs, where boot is from SD-Card exclusively, there's no way with current TF-A to use the same TF-A BL2 across all boards (e.g. memory parameters are hardcoded). For those, you need a different image per board anyway, so using different GUIDs for SSBL serves no purpose IMO.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To help defining such a boot image GUID, maybe UUID namespace could help. EBBR would define a GUID namespace and platform to derive their compatible platform string names in that name space.

allows creating media that can be booted on a multitude of boards.

Placing GPT data structures away from firmware images can be accomplished by
adjusting the GUID Partition Entry array location
(adjusting the values of `PartitionEntryLBA` and `NumberOfPartitionEntries`,
Expand Down