On 03/07/2018 14:17, Daniel Thompson wrote:
On Fri, Jun 29, 2018 at 06:02:50PM +0100, Grant Likely wrote:
Special care is needed when storage is shared between firmware and the OS. Add a chapter that discusses the issues and puts down the requirements for using shared storage.
Resolves: #19
Cc: Daniel Thompson daniel.thompson@linaro.org Signed-off-by: Grant Likely grant.likely@arm.com
+Partitioning of Shared Storage +==============================
+Shared storage must use GPT partitioning unless the storage media provides +device-native partitioning [#UFSparts]_, +or if an immutable property of the platform (ex. the masked boot ROM) +is incompatible with the SoC boot ROM). +MBR partitioning shall be used when the platform is incompatible with GPT.
Would be good to include language about *pre-installed* partition tables here since the ideal case is that the firmware and OS are seperated enough for the main storage media to ship without a partition table.
I'll put language to that effect in the fixed-storage section. Talking about pre-installed partition tables only makes sense in that context.
[...]
+The system should locate firmware images by searching for partitions with +the following UUIDs in order:
+.. table::
- ==================================== ======== ========================
- UUID Priority Description
- ==================================== ======== ========================
- Vendor defined UUID 1 (Not recommended)
Proprietary vendordedicated firmwarepartition. Should onlybe used if firmwarecannot use a FATfilesystem.Needs to distinguish firmware (meaning boot ROM) from firmware (meaning implementation of EBBR).
s/firmware/boot rom/
Also suggest "does not" rather than "can not" (see below).
- TBD 2 EBBR compliant dedicated
firmware partition- C12A7328-F81F-11D2-BA4B-00A0C93EC93B 3 UEFI System Partition
as defined inUEFI ยง 5.3.3With the "priority" field above I think we are starting to make the spec very hard to read. Ultimately what an EBBR implementation must do to comply (level 0, support almost any extant boot ROM) and what we would aspire to have a boot ROM perform in the future (level 1 or more) are being horribly intermingled here.
I'll drop the table for now. It can be added back in later.
Ultimately if we want to include this kind of table in the spec I think it either needs to be an advisory addendum on future spec direction or we need to introduce the level 0 and level 1 concept to the text and we need a stronger distinction between mask programmed ROM and firmware. It is hard to read this and figure out how to write a level 0 compliant EBBR implementation.
Finally I find it rather confusing to have this material appear *before* the section on removeable shared shorage (since effectively the table above describes the implmementation of the feature).
- ==================================== ======== ========================
+.. note::
- Should the vendor defined UUID be included in this table at all?
+MBR partitioning +^^^^^^^^^^^^^^^^
+Pre-installed protective partitions should have a partition type of 0xF8 +unless some immutable feature of the platform makes this impossible.
+It is recommended that disk partitioning utilities treat such +partitions in the same manner as GPT partitions with the Platform +Required Attribute Flag set.
+It is recommended that pre-installed protective partitions that are not +type 0xF8 be located wholly within 1MB of the start of the disk.
+Automatic disk partitioning utilities shall not create partitions +within 1MB of the start of the disk. Manual disk partitioning +utilities should avoid recommending that partitions start within +1MB of the start of the disk.
+.. [#UFSParts] For example, Universal Flash Storage (UFS) provides
- device-native partitioning and does not require a discrete MBR or
- GPT partition table.
"does not require a discrete" -> "need not ship with a pre-authored"
... and which paragraph in the above text does this example seek to clarify.
Much of the above is reworked and cut out now that I understand UFS better.
+Firmware Partition Filesystem +=============================
+Where possible, firmware images and data should be stored in a filesystem. +Firmware can be stored either in a dedicated firmware partition, +or in certain circumstances in the UEFI System Partition (ESP). +Using a filesystem makes it simpler to manage multiple firmware file and +makes it possible for a single disk image to contain firmware for multiple +platforms.
+Dedicated firmware partitions are recommended to be formatted with a FAT +filesystem as defined by the UEFI specification. +However, dedicated firmware partition must not be used as an ESP.
Could be more assertive here (especially with the second second to back it up): "must not be used as" -> "is not"kkkjjjjjjj
Done
[...]
+On removable media, firmware should be stored in the ESP under the +``/FIRMWARE`` directory structure as described above. +Platform vendors should support their platform by providing a single +.zip file that places all the required firmware files in the correct +locations when extracted in the ESP ``/FIRMWARE`` directory. +For simplicity sake, it is expected the same .zip file will recover the +firmware files in a dedicated firmware partition.
No objections but as earlier this whole section feels like aspirational level 1 material that only impacts boot ROMs.
It is aspirational, but I want to get this language into the spec now to start setting expectations, and to get feedback on the structure from SoC vendors before a v1.0 of the spec is tagged. Using 'should' instead of 'shall' means it isn't manditory and allows it to be discussed.
I'll post v2 shortly. It's a bit shorter and simpler now.
Cheers, g.
diff --git a/source/index.rst b/source/index.rst index 5ddd19f..8099ac6 100644 --- a/source/index.rst +++ b/source/index.rst @@ -37,5 +37,6 @@ Creative Commons, PO Box 1866, Mountain View, CA 94042, USA. chapter1-about chapter2-uefi chapter3-secureworld
- chapter4-firmware-media appendix-a-uefi-features references
-- 2.13.0