On 29/06/2018 22:49, Rob Herring wrote:
On Fri, Jun 29, 2018 at 11:03 AM Grant Likely grant.likely@arm.com wrote:
+Some shared media provides dedicate boot regions, but in many cases
dedicated
perhaps an "(e.g. eMMC)"
fixed
+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.
s/when/only when/ ? Though perhaps the rest below is strong enough.
I think the extra word is worth it for clarity
+.. warning::
- MBR partitioning is deprecated and only included for legacy support.
- All new platforms are expected to use either GPT or device-native
- partitioning.
- GPT partitioning supports a much larger number of partitions, and
- has build in redundancy by storing two copies of the partition table.
built in
fixed.
- A future issue of this specification will remove the MBR allowance.
+All firmware images and data stored in normal media should be contained +in a regular partition,
Only 1 allowed?
Reworded to "... in regular partitions, which can be either dedicated firmware partitions, or the UEFI System Partition (ESP)"
+Any pre-installed partition table must strictly conform to the UEFI +specification and include a protective MBR authored exactly as +described in UEFI specification (hybrid partitioning schemes are not +permitted).
Section number?
fixed
+Pre-installed protective partitions must have the Platform Required +Attribute Flag set.
+It is recommended that automatic system disk partitioning utilities +preserve Platform Required partitions as is, and that manual disk +partitioning utilities provide warnings and/or other safe guards to +reduce risk of accidental removal.
+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.- TBD 2 EBBR compliant dedicated
firmware partition- C12A7328-F81F-11D2-BA4B-00A0C93EC93B 3 UEFI System Partition
as defined inUEFI ยง 5.3.3- ==================================== ======== ========================
+.. 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.
+Firmware Partition Filesystem +=============================
Do we need to clarify what firmware this is? Do we want or care if say WiFi firmware is here.
Good question. I'm not sure. The spec is definitely focused on firmware needed to boot the system, but that could be any number of files. I suppose that these rules are applicable even when talking about device firmware blobs, or non-essential firmware. We don't want them stored at random offsets into the block device. If only used by the OS, then they could be put in just about any filesystem. Only the stuff required for boot needs to be put into a firmware partition or ESP.
Can you suggest a more nuanced wording?
+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
s/file/files/
fixed
+Vendors may choose their own subdirectory name under ``/FIRMWARE``, +but must choose names the do not conflict with other vendors. +Normally the vendor name will be the name of the SoC vendor, because the +firmware directory name will be hard coded in the SoC's boot ROM. +Vendors are recommended to use their Devicetree vendor prefix as their
s/Devicetree/DeviceTree/
Perhaps the whole doc needs a consistency check. I'll check if I don't get distracted...
In the dt spec and in this document the "Devicetree" form is used throughout.
+vendor subdirectory name.
+Vendors are free to decide how to structure subdirectories under their +own vendor directory, but they must use a naming convention that allows +multiple SoCs to be supported in the same filesystem.
+For example, a vendor named Acme with two SoCs, ACME100 & AM300, could +choose to use the SoC part number as a subdirectory in the firmware path::
- /FIRMWARE
- /ACME
I guess originally vendor prefixes were upper case ticker symbols, but these days most are lower case. So is this the vendor prefix as-is or converted to uppercase.
I lifted the example from the UEFI spec which shows uppercase names for everything; mostly to account for the FAT naming legacy I think. I'll take another look and make sure the usage here matches the UEFI spec usage.
I suspect the answer will be to use the vendor prefix as-is, but the 8.3 compatible FAT naming will convert it to all uppercase automatically. Vendor prefixes longer than 8 characters may be a problem. It depends on whether firmware is expected to do extended filename lookups, or depend on the 8.3 names.
/ACME100fw.img/ACME300fw.img+It is also recommended for dedicated firmware partitions to use the +``/FIRMWARE`` file hierarchy.
Including the FIRMWARE part or just below it?
Including the firmware part. An EBBR firmware partition and an ESP should look identical as far as firmware is concerned. Suggestions on working to make this clear?
+Operating systems must not use the dedicated firmware partition,
What does 'use' mean? Installing f/w updates would be using.
+but shall instead create a normal ESP for installing the EFI applications +including the OS loader.
To clarify, I'd rearrange like this:
Operating systems must not use the dedicated firmware partition for installing the EFI applications including the OS loader or OS specific files, but shall instead create a normal ESP.
How about this:
Operating systems must not use the dedicated firmware partition for installing EFI applications including, but not limited to, the OS loader and OS specific files. Instead, a normal ESP should be created. OS partitioning tools must take care not to modify or delete dedicated firmware partitions.
kjj>> +On removable media, firmware should be stored in the ESP under the
+``/FIRMWARE`` directory structure as described above.
Perhaps an anchor and reference instead of "above".
done
+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.
Do we really care if it is a .zip file vs. some other archive format? I guess it is a case of if we don't specify it, we'll get to deal with all the possibilities needlessly.
That's kind of what I was thinking. I started with specific, but it can be relaxed if need be.
Doesn't this also apply for fixed shared storage for firmware updates (or does capsule update define something already)?
It certainly could; but any of these "unzip this file to update" is a coarse grained solution to firmware updates. I think we want to specify this as a recovery/provisioning mechanism, but not as the normal update process.
At some point we need to think about A/B update schemes, which the "unzip this file here" scheme doesn't really address.
g.