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. > 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. Alex _______________________________________________ cross-distro mailing list cross-distro@lists.linaro.org https://lists.linaro.org/mailman/listinfo/cross-distro
