On Mon, May 7, 2018 at 12:17 PM, William Mills <[email protected]> wrote:
>
>
> 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?

I'll leave that to one of the OS folks.

> However, i would prefer N files in an EFI dir rather than tons of
> special partitions.  See below.

Yes, I certainly agree. I'd extend that to bootloader specific files
that are just containers of files and config: uImage, FIT image,
Android boot image, Android dtbo image

>>> 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?

Both.

It's certainly not that hard or much code size to do FAT read-only
filesystem support, but it's more that I think vendors would be
reluctant to add support. I get push back just on using filesystems in
2nd stage bootloaders on Android. I would love to see bootrom's more
standardized, but I'm doubtful.

> 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.

That's good to know. Is that opensource?

> 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 ... )

After some further reading on the details, I agree. In any case, I
think all the patents on long filenames have expired now anyway.

Rob
_______________________________________________
boot-architecture mailing list
[email protected]
https://lists.linaro.org/mailman/listinfo/boot-architecture

Reply via email to