On 05/07/2018 11:49 AM, Rob Herring wrote: > On Fri, May 4, 2018 at 1:41 PM, William Mills <[email protected]> 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. >> >> Case #2: Platforms where firmware and OS share single storage >> >> Storage uses either GPT or MBR (but only one) based on board need. >> 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 >> 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) > > This is for all the other stuff vendors stick in custom partitions if > we're lucky or some fixed offset if we're not, right? >
Yes. Today people seem to be using a GPT partition for each of these low level objects and seem to be using the partition name to identify them. They are using very generic names like "boot". This means that the disk image will only work with one SOC or perhaps even one board. If people are going to use raw GPT partitions I think they should at least use a GUID GPT partition type to give certainty. Falling back to a name is OK and will help the casual user. Bit 0 of the GPT attributes table is listed as "Platform required". Do current installers leave these partitions alone? However, i would prefer N files in an EFI dir rather than tons of special partitions. See below. >> 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 > > Firmware includes the bootrom and the loaded firmware (UEFI or ATF) > itself. This would mean the bootrom has to read a FAT filesystem. I'm > assuming you didn't mean that, so we'd still have to allow for > partitions. Perhaps we tighten it up with specific GUIDs for specific > firmware. That would make firmware updates easier and generically > implementable. > I did actually mean that. Is your doubt based on code size / complexity or legal reasons? TI has put FAT in its ROMs for years (granted w/o long name support.) Sure early versions of that code had some quicks but the complexity is manageable. My understanding is that Microsoft has a special grant of its IP for EFI partitions so I would think people would be comfortable at least for the EFI FAT partition. ( IANAL ... ) So if you still disagree I can understand. The ROM could use a GPT partition but after that it should use EFI files. > That issue aside, case 3 could be handled by just marking what is the > recommended option in case 2. And recommended can be defined as going > to be required in the future. > > Rob > Yes and Thanks, Bill _______________________________________________ boot-architecture mailing list [email protected] https://lists.linaro.org/mailman/listinfo/boot-architecture
