Message: 1 Date: Thu, 5 May 2016 13:45:57 +0200 From: Marcin Juszkiewicz marcin.juszkiewicz@linaro.org To: linaro-dev@lists.linaro.org Cc: cross-distro@lists.linaro.org Subject: Let's talk about boot loaders Message-ID: 89cb7539-fbea-e9d6-10a7-2ea4333dc756@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.
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.
-
John Dulaney