On Thursday, May 5, 2016 1:45:57 PM CDT Marcin Juszkiewicz 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.
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.
There is terribleness here as well. It was very fragile. dding the binaries into the correct offsets is much more reliable.
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).
vboot brings about many other issues here as well. its not a great setup if you want to run anything other than chromeos
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...
The locations are not really random, it is what is baked into the bootrom on the silicon and is SOC specific.
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...
This is why I did all the work to support extlinux.conf on arm, take away the magic, make it simple for users. but that does require that you have u-boot somewhere first.
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).
96 boards failed misserably in my eye when they did not mandate flash storage for the bootloader
Is there a way to get it improved? At least for new designs?
combine together as a community and refuse to support hardware that does not meet minimum requirements, battery backed RTC and flash for initial board startup at the least.
Take the tegra jetson TK1, update the bootloader to upstream u-boot, you get PXE install and boot support, if you dd a Fedora image to a sd card and put it in it just boots and gives a good user experience. same is true if you update the u-boot on the trimslice. Solid Run is doing a terrible job here all of there devices require that you put u-boot somewhere, sdcard, start of ssd etc.
Dennis