On Wed, Mar 11, 2020 at 01:42:36PM +0100, Francois Ozog wrote: > On Wed, 11 Mar 2020 at 12:45, Daniel Thompson <[email protected]> > wrote: > > > On Wed, Mar 11, 2020 at 11:20:17AM +0100, Francois Ozog wrote: > > > On Wed, 11 Mar 2020 at 07:48, Heinrich Schuchardt <[email protected]> > > wrote: > > > > On 3/11/20 12:04 AM, Heinrich Schuchardt wrote: > > > > In the expert mode of gdisk there is command 'j' for moving the GPT > > > > Partition Entry Array to an arbitrary sector. This will protect the > > area > > > > between the GPT header and the GPT Partition Entry Array from being > > used > > > > for a partition. The same can be done with parameter -j of sgdisk. > > > > > > > > Furthermore gdisk supports creating a hybrid MBR. This allow to have > > > > GUID partition table and a MBR partion table at the same time where the > > > > MBR partition table mirrors up to three GPT partitions and the fourth > > > > MBR partition is used to protect the GUID partition table. > > > > > > > > So requiring GPT and having boards only supporting booting from an MBR > > > > partition (like the Raspberry) seems not to be exclusive. > > > > > > > > > > That sounds like a great solution! > > > > The last time we discussed this there was *very* strong opposition > > during meetings to hybrid partitioning and IIRC language was added to > > the spec to prohibit it. > > > > Hybrid partitioning is a problem because it imposes to difficult to meet > > constraints on partitioning tools provided by the operating system. > > > > In other words if we permit hybrid partitioning in order that boot code > > can find the firmware then the operating system would inherit a duty to > > not to screw up the firmware loading when it modifies the partition > > tables. It is hard to express how the OS should go about that. > > > > Hence the current approach where we accept that MBR partitioning > > offers an inferior feature set to GPT. > > > > > 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. > - FW that supposes LBA-1 (macchiatobin the firmware blob that contain TF-A > must be here) > In theory OK as Linux will detect bad signature and use the alternate GPT In the current spec this case isn't materially different to firmware whose boot ROM parses the MBR to load extra code (which wasn't listed above). In both cases the system would be expected to adopt MBR and create protective partitions for the firmware (and accept that the protective partition is vulnerable to damage by auto-partitioning installers). Having said is this really relevant for MacchiatoBin? Why put EBBR firmware onto shared media? I thought MacchiatoBin could boot from the 4MB SPI NOR. Daniel. _______________________________________________ boot-architecture mailing list [email protected] https://lists.linaro.org/mailman/listinfo/boot-architecture
