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.thomp...@linaro.org> > Signed-off-by: Grant Likely <grant.lik...@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 > 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 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 files > + in 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 mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
