On 5/20/20 7:49 PM, François Ozog wrote: > > > On Wed, 20 May 2020 at 19:30, Daniel Thompson > <[email protected] <mailto:[email protected]>> wrote: > > On Wed, May 20, 2020 at 07:00:53PM +0200, François Ozog wrote: > > On Wed, 20 May 2020 at 18:39, Daniel Thompson > <[email protected] <mailto:[email protected]>> > > 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? > > > > > > I would say it is not EBBR compliant because it does not follow > EFI spec > > and we mandate it in EBBR. > > Sure, if there is language in the EFI spec that prohibits this then the > answer is a no brainer. > > Assuming you've found such language could you quote your references? ;-) > > Oups! I thought of GPT Header being at 18002..... > as you push the firstUsableLBA... it seems to be valid in that EFI > compliant and hence EBBR compliant ;-) > > That said to get the GPT Partition move, the spec patch to table 20 is > not impressive: > image.png > - set to 0x000001 (ie... > + the LBA to the GPT partition header
The position of the GPT *HEADER* in Daniel's example is LBA 1 and should not be changed to stay UEFI compliant. Daniel moved the first GPT *TABLE* whose position is defined in the GPT header and this is UEFI compliant. Best regards Heinrich > > > Daniel. > > > > Is the use case "valid"? I think it is valid because when you deal > with > > immutable BootROM you don't want complex code, GPT may evolve so > that you > > would have to evolve the BootROM... > > If we conclude this is a valid use case (and not creating ugly > legacy to > > deal with in the future), we need a clean reservation in EFI so > that GPT > > can start at an arbitrary LBA as 18002. > > enhancing the protective MBR semantics does not seem too complex to > > achieve. > > Can we list SoCs that have similar characteristic? > > > > > > > > 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. > > > > > > > > > -- > > François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group* > > T: +33.67221.6485 > > [email protected] <mailto:[email protected]> | > Skype: ffozog > > > > -- > > François-Frédéric Ozog | /Director Linaro Edge & Fog Computing Group/ > T: +33.67221.6485 > [email protected] <mailto:[email protected]> | Skype: ffozog > > _______________________________________________ boot-architecture mailing list [email protected] https://lists.linaro.org/mailman/listinfo/boot-architecture
