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