On 20.05.20 18:39, Daniel Thompson wrote:
On Tue, May 19, 2020 at 03:29:01PM +0100, Grant Likely wrote:
On 11/03/2020 16:42, Daniel Thompson wrote:
On Wed, Mar 11, 2020 at 01:42:36PM +0100, Francois Ozog wrote:
We have the following cases:
- FW compatible with GPT (I mean firmware can be searched based on
GUID partition) Ok
- FW that uses offsets and can be positioned at LBA >= 33
Ok Need to define a protective partition >>
- FW that uses offsets and can be positioned such that space between LBA-2
and LBA-33 is used. Ok in theory as the header states where the partition entries location is specified in a GPT_HEADER "Starting LBA of array of partition entries". Linux kernel properly loads the partition entries if we push them after 16MB.
read_lba https://elixir.bootlin.com/linux/latest/ident/read_lba(state, le64_to_cpu https://elixir.bootlin.com/linux/latest/ident/le64_to_cpu(gpt->partition_entry_lba)
But I bet 2 is hardcoded in many tools...
Agree... but that's "just bugs" and I suspect we could get >90% test coverage for Linux systems just by checking util-linux (and the kernel itself). Maybe for extra style points also check on of the BSDs.
It is worth stepping back from the details to take a look at the intent. The purpose of this entire section of EBBR is to describe how firmware and the OS can co-exist on the same media device. In broad strokes it means if firmware is stored on the block device, then the OS must constrain how it uses the device.
On platforms with separate firmware storage (e.g., SPI flash or UFS boot partitions) this isn't an issue. The OS can blow away everything on the disk and recreate it.
But when it is an issue, the rules need to lay down what regions (offsets, partitions, or file paths) firmware is allowed to own and what the OS is and is not allowed to do. e.g., the OS is allowed to erase and recreate the OS partitions, but it is not allowed to write a blank GPT or erase the system partition.
I think the EBBR spec should focus on defining exactly what restrictions on the OS are, and how the restrictions are communicated. Then OS vendors have a fighting chance of supporting the restricted platforms well.
Ultimately though this is a guide and the OS could choose to ignore the restrictions... in which case it gets to keep the unbootable brick when it does. :-)
Agree with all above.
Also I think we can turn at least part of the original issue into a concrete question.
We have a SOC with some magic values hard coded into its boot ROM. The System Firmware author wants to ship it with the following GPT on the shared eMMC.
LBA0 Protective MBR LBA1 Primary GPT header LBA2..18001 Reserved, mixture of dead space and a system firmware loaded by Boot rom LBA18002 Start of partition arrray (Entry 1, 2, 3, 4) ... LBA18033 End of partition arrray LBA18034 Start of allocatable partition space LBA-33..-1 End of disk is labelled as normal
(or in a shorter GPT jargon form, a system where PartitionEntryLBA is 18002).
Is such a system EBBR compliant? If yes, should it be?
Where UEFI wants to restrict possible GPT header values it is mentioned explicitly in the spec, e.g. SizeOfPartitionEntry has to be a power of two and be at least 128. The UEFI 2.8 spec does not prescribe values for PartitionEntryLBA and NumberOfPartitionEntries.
Many tools default to PartitionEntryLBA = 2, SizeOfPartitionEntry = 128 and NumberOfPartitionEntries = 128 which is a sensible choice in many cases.
If a tool or operating system cannot work with PartitionEntryLBA > 2, SizeOfPartitionEntry > 128 or NumberOfPartitionEntries != 128, it is simply not UEFI compliant and should be fixed.
So you should be fine as long as the first GPT table resides in the first 2 TiB assuming an LBA size of 512 bytes.
The requirement to be written into the EBBR is that a firmware MUST be able to deal with GPTs with PartitionEntryLBA > 2, SizeOfPartitionEntry
128, and NumberOfPartitionEntries != 128 to be EBBR compliant.
U-Boot can use such GPTs. It does not yet support creating them via the 'gpt write' command. - But the creation of partition tables should not be in the scope of the EBBR.
Best regards
Heinrich
Daniel.
PS 18002 is arbitrary but I think the example is sufficient in this form and it was easier to diagram with a concrete number.