> Message: 1 > Date: Thu, 5 May 2016 13:45:57 +0200 > From: Marcin Juszkiewicz <marcin.juszkiew...@linaro.org> > To: linaro-...@lists.linaro.org > Cc: cross-distro@lists.linaro.org > Subject: Let's talk about boot loaders > Message-ID: <89cb7539-fbea-e9d6-10a7-2ea4333dc...@linaro.org> > Content-Type: text/plain; charset=utf-8; format=flowed > > 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?
Unfortunately, SoC vendors don't give a crap; as long as *their* SDK works, anyone else can take a hike up a tree. If it wasn't for JCM pushing against this, aarch64 servers would be in the same state, and they'd never ever gain traction against Intel. John. _______________________________________________ cross-distro mailing list cross-distro@lists.linaro.org https://lists.linaro.org/mailman/listinfo/cross-distro
