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. > > 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.
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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ cross-distro mailing list [email protected] https://lists.linaro.org/mailman/listinfo/cross-distro
