On Fri, May 6, 2016 at 12:15 PM, Alexander Graf <ag...@suse.de> wrote: > > > On 06.05.16 13:03, Grant Likely wrote: >> On Fri, May 6, 2016 at 2:10 AM, Tom Rini <tr...@konsulko.com> wrote: >>> On Thu, May 05, 2016 at 10:21:25PM +0200, Alexander Graf wrote: >>>> So what's the goal here? Are we trying to force GPT on systems whose >>>> vendors never intended them to run with GPT? >>>> >>>> It really shouldn't matter at the end of the day whether we use GPT or >>>> MBR. All uEFI firmware implementations I'm aware of support both. So if >>>> you have a device whose bootloader collides with the GPT, just use MBR. >>>> >>>> As for the "protection" mechanism, I don't think it's a problem either. >>>> IIRC parted starts to create partitions with a sensible alignment (1 or >>>> 2MB). Most boot loaders fit perfectly fine within that gap. >>>> >>>> So this really boils down to >>>> >>>> - use GPT for systems that were designed for it or >>>> - use MBR with alignment gap to first partition >>>> >>>> end of story. There shouldn't be any middle ground. At least I haven't >>>> seen any so far :). >> >> That is a good point. MBR is a pain to deal with, but I don't think >> there is anything that it is absolutely required for in UEFI land. >> >>> This, for many use cases is also true. A reason that various SoCs pick >>> a magic location that is MBR compatible and not strictly GPT compatible >>> is that they don't see a use case for GPT-not-MBR being used. >>> By-and-large saying your SD card shall have an MBR and shall leave a gap >>> that is also well aligned for the card anyhow is enough for (enough) >>> firmware to reside in the magic locations. >> >> I think the key issue is how do the tools know what they are allowed >> to do. If (for example) the system is booted into a recovery/install >> image and needs to repartition and install onto the eMMC, can we get > > We really only have 2 cases: eMMC and SD. In both cases, I would expect > that there is some workable partition label on the target installation > medium. > >> away from the tools requiring board specific knowledge? A generic >> partitioning/install tool needs to know: >> - Is an MBR required (ie. SoC reads MBR to find firmware) >> - Is FW location at a fixed offset? >> - Is GPT supported? > > So none of these matter. If we can guarantee that > > * labels don't get recreated, only partitions change and > * partitions start earliest at 2MB > > then we have it all covered, because ... > >> >> If the tools can get that information, then it can make good decisions >> when reimaging a device, and it will make Marcin happier I'm sure. :-) >> >> I /don't/ think the general tools should need to know how to install >> the firmware itself. That is still a nasty board-specific problem.... >> (although even here we could make things better if we had a spec for >> managing the SoC's FW partition. I would like to see separate steps >> for FW provisioning, and OS install. ie. A board-specific tool to prep >> an SD card with the bare minimum for FW, and then generic tools to >> complete partitioning and install. > > ... as you mention here, the installation path on such a system would > involve a specialized image as your "installer image" which includes FW > at whereever it has to be plus the installer binaries. That installer > would usually load itself into RAM, use a server on the internet as > installation source and simply repartition the SD card / eMMC. > > So while it's repartitioning, we need to make sure that we don't remove > the RPi FAT partition for example. But that's easy - mark it as MBR EFI > partition (Label type 0xef) and fix any issues in your installer if it > thinks it wants to remove it. I think today the RPi firmware doesn't > boot from 0xef labels, but I'm sure we can talk to them to fix that. > > For all hard coded offset firmware, just make sure that your > repartitioning doesn't touch the first 2MB and your firmware will stay > alive from the days when your SD card contained the installer.
Yes, that makes sense. One tweak I'd make, is I'd still create a partition table entry to cover the fixed-address region. Then the information is explicitly there. > >> For on-board devices (eMMC), FW provisioning should only be needed once >> For removable devices (SD), FW provisioning is only needed when FW >> must be on SD. (ie. no-onboard eMMC, or for FW recovery/upgrade) > > So that only leaves the "install from SD to eMMC" case. And that is > simply an installation issue, there's nothing we can do generically to > fix that. If you want to support that case, put the respective logic to > dump firmware to the eMMC into your installer. Or into some pre-stage on > the SD card. Or create a separate SD image that "upgrades firmware" on > the system. Agreed. Okay, that simplifies things quite a bit. It still needs to be documented, and I'd like to get some of this discussion into the UEFI spec. I'll draft something. BTW, I've looked into the limitations on MBR vs. GPT. From the UEFI spec: The following list outlines the advantages of using the GPT disk layout over the legacy Master Boot Record (MBR) disk layout: • Logical Block Addresses (LBAs) are 64 bits (rather than 32 bits). • Supports many partitions (rather than just four primary partitions). • Provides both a primary and backup partition table for redundancy. • Uses version number and size fields for future expansion. • Uses CRC32 fields for improved data integrity. • Defines a GUID for uniquely identifying each partition. • Uses a GUID and attributes to define partition content type. • Each partition contains a 36 character human readable name. GPT does have better data integrity and redundancy, and a larger maximum size.... but I haven't seen many >2TB eMMC or SD devices around. :-) None of these are show stoppers. As long as the provisioning tool does initial setup correctly, including choosing MBR vs GPT, then the OS install step doesn't need to do anything special. g. _______________________________________________ cross-distro mailing list cross-distro@lists.linaro.org https://lists.linaro.org/mailman/listinfo/cross-distro
