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. + +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. + + Options: + + - Require ESP and SFPs to be separate + - Should a common SFP GUID be defined so a single image can hold firmware + for multiple platforms? + - Don't have to repartition to add additional platforms. + - Yet repartitioning required to add the *first* platform + - Require FAT formatting? + - Probably also requires a vendor/soc/file pathname spec to avoid + conflicts. + - OS can mount the ESP without touching SFPs. This means firmware could + perform (mediated) operations on the SPF (ex. to update variables) + without unmounting the ESP. + - Downside: Requries at least two fixed sized partitions to boot the + platform: a SFP, and the ESP. A single combined SFP+ESP would be more + efficient on space. + - Allow ESP to be used as an SFP + - Downside: Partitioning/Install tools can't simply blank the ESP to reset + to scratch + - Upside: platform firmware can be added by simply dropping files + in the ESP + - Using the ESP filesystem is a more efficient use of space. + - Still need to define pathname spec to avoid conflicts + GPT partitioning ^^^^^^^^^^^^^^^^
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 ^^^^^^^^^^^^^^^^
On Sat, Jun 09, 2018 at 10:21:58AM +0200, Alexander Graf wrote:
- 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* platformThat'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.
On most of the existing 96Boards then, if their vendors implement EBBR, it would reside on internal eMMC/UFS storage. An SD image should not need to contain any system firmware partition to be bootable on platforms with internal storage.
Daniel.
On Fri, Jun 08, 2018 at 08:57:52PM +0100, 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 +^^^^^^^^^^^^^^^^^^^^^^^^^^
New title might be called for. I had to look twice at this to be sure it doesn't mean ESP (given what the F in EFI stands for).
+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.
I think this should be required, rather than strongly recommended.
+System boot ROM should obtain the system firmware partition location +by reading the partition table.
Similar, I think the "should" could be safely upgraded to "strongly recommended" too.
+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.
+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.
- 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- Require FAT formatting?- Probably also requires a vendor/soc/file pathname spec to avoidconflicts.- 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.- 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
I'm certainly in the habit of nuking the ESP during install testing to ensure it gets repopulated correctly. It's a manual act on my part but many GUI installers make it easy to do this.
If we permit a shared ESP is must be discoverable (marked as System Required?) and I think also needs a means to trigger a factory reset.
Likewise is worrying about file system corruption here merited? FAT failure modes can be rather nasty (although its a long time since I've seen one).
- 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 conflicts
Note that this still doesn't help RPi without a relaxation of partition ID for the ESP (which I'm not very comfortable about).
GPT partitioning ^^^^^^^^^^^^^^^^ -- 2.13.0
boot-architecture@lists.linaro.org
-
Alexander Graf -
Daniel Thompson -
Grant Likely