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. > _______________________________________________ boot-architecture mailing list [email protected] https://lists.linaro.org/mailman/listinfo/boot-architecture
