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 <[email protected]>
Signed-off-by: Grant Likely <[email protected]>
---
+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 vendor
+ dedicated firmware
+ partition. Should only
+ be used if firmware
+ cannot use a FAT
+ filesystem.
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 in
+ UEFI ยง 5.3.3
With 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
_______________________________________________
boot-architecture mailing list
[email protected]
https://lists.linaro.org/mailman/listinfo/boot-architecture
