On 08.06.18 21:57, Grant Likely wrote:
Add some more detail on how to handle system firmware. I'm still undecided about this, so this patch is more of an RFC discussion than a serious patch. Please comment.
Cc: Daniel Thompson daniel.thompson@linaro.org Signed-off-by: Grant Likely grant.likely@arm.com
source/ebbr.rst | 58 ++++++++++++++++++++++++++++++++++++++++++++++++++++----- 1 file changed, 53 insertions(+), 5 deletions(-)
diff --git a/source/ebbr.rst b/source/ebbr.rst index 3998397..c24cef5 100644 --- a/source/ebbr.rst +++ b/source/ebbr.rst @@ -200,16 +200,64 @@ System Volume Format The system firmware must support all partitioning standards required by the UEFI specification. -On systems where the system firmware binaries reside on the System Volume then -the System Volume must be pre-configured with a partition table and include -protective partitions to reduce risk of accidental destruction of the system -firmware.
All pre-installed partition tables must use GPT partitioning unless some immutable feature of the platform (such as a mask programmed boot ROM) makes this impossible; on such platforms MBR partitioning may be used as an alternative. +System Firmware Partitions +^^^^^^^^^^^^^^^^^^^^^^^^^^ +On systems where the system firmware binaries reside on the System Volume then +the System Volume must be pre-configured with a partition table and system +firmware binaries.
+When system firmware is located at a fixed offset, It is strongly recommended +for the partition table to include protective partitions covering the location +of firmware to reduce risk of accidental destruction of the system firmware.
+System boot ROM should obtain the system firmware partition location +by reading the partition table. +Using a fixed offset into the storage media is deprecated and should +not be used for new SoC designs. +Future issues of this specification will disallow the use of fixed offsets.
Why should we bother? The only difference between a fixed offset and a partition location is that the protected firmware partition is non-movable. It's probably a good idea to assume it can't be moved in the first place though, since you may always run into bootrom limitations (like 2G barriers, etc).
I would much rather like to see a note here saying that fixed offsets are allowed at offset <after gpt>. If firmware wants to sit at 1MB and reserve a range up to 16MB and puts a reservation partition there, I don't see any big difference from an OS point of view over a partition that just happens to sit at 1MB and is 15MB big.
+A system firmware partition should not also be used as a EFI System +Partition (ESP). +Pre-installed system firmware partitions must not use the ESP GUID, +and OS installation tools should not install EFI executables in a system +firmware partition.
+.. todo::
- I'm not sure if this is a good idea. It might be that EBBR should define a
- common GUID for system firmware partitions. It also might be that I'm worrying
- too much and it is fine to use the ESP as a system firmware partition.
- This TODO note is a bit of a discussion of the options.
I personally don't mind to allow use of the ESP as system firmware partition. It can be very convenient on MBR based systems, as we're otherwise running out of primary partitions quite quickly.
- Options:
- Require ESP and SFPs to be separate
- Should a common SFP GUID be defined so a single image can hold firmwarefor multiple platforms?- Don't have to repartition to add additional platforms.- Yet repartitioning required to add the *first* platform
That's an interesting idea, yeah. I would love to have a single SD image for all 96boards. That in turn obviously clarifies why fixed offsets are a bad idea.
So we need to be smarter here. If we allow multiple system firmware partitions, they will have to follow a scheme that allows for 50 different ones to coexist - potentially even on MBR. So we need to have a requirement that the bootrom loops through all and has a unique identifier to find the relevant one.
- Require FAT formatting?
FAT of what? IMHO what I would do is allow either ESP+defined path for system firmare or separate partition with one partition per target device.
- Probably also requires a vendor/soc/file pathname spec to avoidconflicts.
Yes, that's definitely needed.
- OS can mount the ESP without touching SFPs. This means firmware couldperform (mediated) operations on the SPF (ex. to update variables)without unmounting the ESP.
If both are on the same block device that is still tricky, no?
Alex
- Downside: Requries at least two fixed sized partitions to boot theplatform: a SFP, and the ESP. A single combined SFP+ESP would be moreefficient on space.
- Allow ESP to be used as an SFP
- Downside: Partitioning/Install tools can't simply blank the ESP to resetto scratch- Upside: platform firmware can be added by simply dropping filesin the ESP- Using the ESP filesystem is a more efficient use of space.- Still need to define pathname spec to avoid conflictsGPT partitioning ^^^^^^^^^^^^^^^^