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