Hi, On 5 May 2016 at 05:45, 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... > > Even 96boards CE specification totally ignored that fact while it could be a > way of showing how to make popular board. Instead it became > yet-another-board-to-laugh (EE spec did not improve much). > > Is there a way to get it improved? At least for new designs?
This has bugged me for a long time. I see that Rockchip stores its boot information 64 blocks into the device, allowing room for the GPT. This seems like the lowest common denominator for the case you raise. Perhaps ARM could create a set of guidelines here? I don't think the media type is the problem. Obviously different manufacturers are going to choose media depending on their preferences, cost, etc. But it shouldn't be too hard to describe the boot architecture of a machine in some sort of simple human-readable file, and provide a software library to deal with it. Regards, Simon _______________________________________________ cross-distro mailing list cross-distro@lists.linaro.org https://lists.linaro.org/mailman/listinfo/cross-distro
