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: >> On 05.05.16 17:21, Grant Likely wrote: >> > On Thu, May 5, 2016 at 12:45 PM, Marcin Juszkiewicz >> > <marcin.juszkiew...@linaro.org> wrote: >> >> Recently my angry post on Google+ [1] got so many comments that it was >> >> clear >> >> that it would be better to move to some mailing list with discussion. >> >> >> >> As it is about boot loaders and Linaro has engineers from most of SoC >> >> vendor >> >> companies I thought that this will be best one. >> >> >> >> 1. https://plus.google.com/u/0/+MarcinJuszkiewicz/posts/J79qhndV6FY >> >> >> >> >> >> All started when I got Pine64 board (based on Allwinner A64 SoC) and had >> >> same issue as on several boards in past - boot loader written in some >> >> random >> >> place on SD card. >> >> >> >> Days where people used Texas Instruments SoC chips were great - in-cpu >> >> boot >> >> loader knew how to read MBR partition table and was able to load 1st stage >> >> boot loader (called MLO) from it as long it was FAT filesystem. >> >> >> >> GPU used by Raspberry/Pi is able to read MBR, finds 1st partition and >> >> reads >> >> firmware files from there as long it is FAT. >> >> >> >> Chromebooks have some SPI flash to keep boot loaders and use GPT >> >> partitioning to find where from load kernel (or another boot loader). >> >> >> >> And then we have all those boards where vendors decided that SPI flash for >> >> boot loader is too expensive so it will be read from SD card instead. From >> >> any random place of course... >> >> >> >> >> >> Then we have distributions. And instead of generating bunch of images per >> >> board they want to make one clean image which will be able to handle as >> >> much >> >> as possible. >> >> >> >> If there are UEFI machines on a list of supported ones then GPT >> >> partitioning >> >> will be used, boot loader will be stored in "EFI system area" and it >> >> boots. >> >> This is how AArch64 SBSA/SBBR machines work. >> >> >> >> But there are also all those U-Boot (or fastboot/redboot/whateverboot) >> >> ones. >> >> They are usually handled by taking image from previous stage and adding >> >> boot >> >> loader(s) by separate script. And this is where "fun" starts... >> >> >> >> GPT takes first 17KB of storage media as it allow to store information >> >> about >> >> 128 partitions. Sure, no one is using so many on such devices but still >> >> space is reserved. >> >> >> >> But most of chips expects boot loader(s) to be stored: >> >> >> >> - right after MBR >> >> - from 1KB >> >> - from 8KB >> >> - any other random place >> >> >> >> So scripts start to be sets of magic written to handle all those SoCs... >> >> >> >> Solution for existing SoCs is usually adding 1MB of SPI flash during >> >> design >> >> phase of device and store boot loader(s) there. But it is so expensive >> >> someone would say when it is in 10-30 cents range... >> >> >> > >> > To try and summarize, what you're asking for is to define the usage >> > model for eMMC/SD when both the firmware* and OS are stored on the >> > same media. Some argue that these things should always be on separate >> > devices, but while the debate is interesting, it doesn't match the >> > reality of how hardware is being built. In which case, the derived >> > requirements are: >> > >> > 1) Co-exist with MBR partitioning >> > 2) Co-exist with GPT partitioning >> > 3) Be detectable --- partitioning tools must respect it >> > 4) Be speced. Write it down so that tool and SoC developers can see it >> > as a requirement >> > 5) Be usable regardless of firmware type (UEFI, U-Boot, Little Kernel, etc) >> > 6) Support some form of firmware non-volatile storage (variable storage) >> > >> > It would be really nice if we could also have: >> > 7) Support SoCs that hardcode boot code to specific locations >> > (after-MBR, 1K, 8K, random) >> > - May not be able to support all variants, but it is a worthy design >> > goal. >> > >> > Agreed? >> > >> > * I'm ignoring eMMC's separate boot area because that solution has >> > firmware and OS logically separated. Strong recommendation is for SoCs >> > to boot from boot area. Then normal GPT/MBR partitioning works just >> > fine. The rest of this discussion only applies If the SoC cannot do >> > that >> > >> > (For the following discussion, I refer to the UEFI spec because that >> > is where GPT is defined, but the expectation is that anything >> > described here can equally be used by non-UEFI platforms) >> > >> > I've just read through the UEFI GPT spec, and here are the constraints: >> > - MBR must be at the start of LBA0 (0 - 0.5k) >> > - Primary GPT must be at the start of LBA1 (0.5k to 4k, but may >> > collide with fw), >> > - It /seems/ like the GPT Header and GPT table can be separated by >> > some blocks. The GPT header has a PartitionEntryLBA field which >> > describes where the actual table of partitions starts. >> > - GPTHeader is only 92 bytes. >> > - It should be possible to have: GPTHeader @ start of LBA1 and >> > GPTPartitionTable @ an LBA that doesn't conflict with firmware. >> > >> > I think we have everything we need to work around the location of the >> > FW boot image without breaking the UEFI spec. The biggest problem is >> > making sure partitioning tools don't go stomping over required >> > firmware data and rendering systems unbootable. I *think* we can solve >> > that problem by extending the MBR definition to block out a required >> > region and then work around that. Tools can generically see the >> > special region in the MBR and work around it accordingly. >> >> 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 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? 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. 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) g. _______________________________________________ cross-distro mailing list cross-distro@lists.linaro.org https://lists.linaro.org/mailman/listinfo/cross-distro
