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