On 08.05.18 16:38, Daniel Thompson wrote: > On Fri, May 04, 2018 at 02:41:56PM -0400, William Mills wrote: >> >> On 05/04/2018 01:03 PM, Andreas Färber wrote: >>> Am 04.05.2018 um 18:50 schrieb Alexander Graf: >>>> On 05/04/2018 06:20 PM, William Mills wrote: >>>>> On 05/04/2018 11:45 AM, Alexander Graf wrote: >>>>> I am missing something. If there is only MBR and no GPT then there is >>>>> no GUID type for EFI Partition. So how does the firmware find the "EFI >>>>> Partition" and the default /efi/boot/boot*.efi file? Does it just use >>>>> the partition with boot flag? >>>> >>>> There is a special partition ID for the ESP (0xEF), but U-Boot currently >>>> just searches on every partition that's marked bootable. >>> >>> ... and falls back to the first partition if none on the device is >>> marked bootable. >>> >> >> Thanks guys, that makes sense. >> >> So the running summary in my head looks like this: >> >> Case #1: Platforms that have separate storage for firmware and OS >> >> OS storage is simple std GPT with no funny MBR stuff. >> One image may work on many boards.
GPT or MBR. The UEFI spec allows for either of them and so should we. >> >> Case #2: Platforms where firmware and OS share single storage >> >> Storage uses either GPT or MBR (but only one) based on board need. > > As in you want to require a pure protective MBR and prohibit any form of > hybriding? > > I'm OK with this... much simpler than requiring distros never to touch > the MBR of a GPT system! Yes :). Case 1 and 2 are bascially identical. > > >> Image is dedicated for one machine type (or closely related set). >> If raw mode is needed use MBR with 2MB reserved space >> OS should not touch reserved space in MBR > > I'd still prefer that EBBR compliant firmware (where firmware is loaded > from shared media) have a protective partition describing the first > 2MB at the point the firmware is installed to the shared media. The problem with a protective partition is that getting changes into partitioning tools is really hard - and there are many of those out there :). Also, I think we should only declare 1MB as reserved. If someone needs more space, they should really go the dedicated / separate partition route and use something like SPL to read from one of the options below. The reason 1MB is so convenient is that basically all partitioning tools today already give you a natural 1MB alignment. So there are no OS changes needed. > > >> If using GPT, firmware should place needed files in either: >> * Vendor registered dir in EFI partition >> * GUID identified partitions w/ attribute bit 0 set >> (can fallback to using names if GUID not found) No need to couple these to GPT. You can always have a vendor registered directory in the ESP with MBR as well. For GUID partitions a GPT is obviously necessary. >> >> Should we consider a future case #3? >> Case #3: New Platforms where firmware and OS share storage >> >> Storage uses std GPT with no exceptions. >> Image may work with N preknown boards that are unrelated. >> Firmware files are all in a vendor specified dir in the EFI partition > > Not sure about this. > > For eMMC we'd prefer the boot ROM just load the firmware from the boot > partition, > then the OS can do whatever it wants with the main media (which could ship > completely unpartitioned and leave it to the OS). > > For UFS, the case is similar, although with multi-layer partitioning the > terminology is hard. Either way we should rely on flash partitioning so > that the firmware can be entirely separated by hardware partition. Again > the flash partition to OS will be installed has not particular need to > be partitioned in any way at all. > > When booting from media without any hardware partitioning the case #3 > scheme looks good although even there I'm not sure about the need to > have an image work on unrelated boards though. To be useful it implies > that EBBR implementations from different vendors can be combined in > one disk image (i.e. that vendors will make EBBR implementations > available with a license to redistribute them). We probably don't want > to go there... even by implication! Well, with a fully U-Boot stack for example this should be easily achievable. I don't think it's a bad idea to suggest. Imagine a world where you could download a single image that just happens to run on all 96boards! Alex _______________________________________________ boot-architecture mailing list [email protected] https://lists.linaro.org/mailman/listinfo/boot-architecture
