> The measurements are with me. Linux, properly configured, is a very fast bootloader. UEFI has always been nothing but slow. And
> that's still true; I've seen recent systems with "stripped down" UEFI and they are still appallingly slow, slower than linuxbios was in
> 2000 on slow CPUs. I still can't see the point of UEFI (well, I can: Intel has been telling me for 16 years that UEFI is a way to
> ensure they can distribute binary blobs for firmware and not reveal "core IP" to their BIOS ecosystem). Linux on ARM for auto
> computers hit the 800ms boot time goal 10 years ago. I have seen UEFI systems that get booted in seconds, but not much closer
> and getting them there is a huge amount of work. What's the point?

I am not talking about small/tiny systems. If you consider consumers electronics, my proposal is out of any picture. I am talking about laptops, notebooks, DT, WS, and also about servers. Yes, with systems with SSDs (SSD is set to win this futile fight between HDDs and SSDs). And SSDs are bloody fast (they'll be much faster).

What's the point? Here are my points:
[1] Much easier and much more layered control. I can, while in boot-loader (CMOS BIOS), to inspect TRUE fs: /boot/efi FAT32 system and see what I have exactly there, apart from BIOS booting page;
[2] Even if eODMs and/or vendors disable EFI BIOS shell, it is possible to break into it (I am able to do this for every system) and see exact state of affairs (others will be as well);
[3] Very soon HDDs and SSDs with capacities of > 2TB will be out (price wise), and MBR (as far as I know it) does NOT support such kind of capacities. And MBR is related with classical boot, as my best understanding goes;
[4] Since all the SoCs are now, and will in The Future support 64b architecture, my take on this is that boot-loaders should go this route, and be soon 64b as well (all UEFI BIOSes are already 64b, pleonasm).

Again, for IOT as it is defined, my proposal is No Go. I agree with you for IOT case. I am advertising Coreboot (and U-Boot also) to compete with BIOSes and BIOS Vendors. We see/read (in this Coreboot @ thread) that over 90% of versatile people port Coreboot to Lenovo 410, 420, 520W, Nehalem laptops... INTEL and AMD based Laptops/Notebooks... ;-)

My two cent opinion,
Zoran

On Sun, Nov 27, 2016 at 11:37 PM, ron minnich <rminnich@gmail.com> wrote:


On Sun, Nov 27, 2016 at 1:03 AM Zoran Stojsavljevic <zoran.stojsavljevic@gmail.com> wrote:

I'll again repeat what I always believe in, and always advertise(d) here, and anywhere else: Coreboot is one excellent absolute minimum required for booting HW platform to the next step: OS boot loader, and I like Coreboot as it is. But having U-boot, or Tiano core as payloads, or minimal Linux, to get to again to boot to the real Linux... Nope (too much overhead)! Not my understanding of how things should work. 

I very much like UEFI concept, to have a fs (file system) formatted in the boot-loader (and get rid of legacy MBR), but with the absolute minimal overhead - good to go. And this is why I tried to advertise micro part of Tiano Core - ONLY fs FAT32 with /boot/efi (/dev/sda2) part. Since SEC and PEI part (BIOS equivalence) is Coreboot itself, and then DXE whole shaman of probably 2M lines of code... Forget it - Mont Everest burden!

Every time I put linux in flash and used it as a bootloader, it was faster than Tiano or UEFI. Every. Single.Time. 

Plus, I could for the most part read the code. Tiano code makes my eyes hurt.

Linux as payload was always far faster than etherboot/gpxe/ipxe for any reasonable use of a network, since the  linux network stack has very good performance. I could boot linux from flash and boot linux over a network in seconds. And, as we got to really fast networks, like 10G infiniband, the advantage for linux only grew. And, of course, linux can use multiple nics concurrently; no pxe ever could. I'm not even sure the spec allows for it.

Fun measurement: back in 2001, we showed at Los Alamos that linuxbios (i.e. linux payload) could boot a 1000 (one thousand) node cluster faster than ipxe could figure out which NIC to use for DHCP on one single node. This includes some heavy lifting: configure the myrinet network (non trivial), load a new kernel, kexec a new kernel, and ... configure the myrinet network AGAIN. It was always funny to have booted 1000 nodes on Linux, twice, before iPXE got around to finding the one configured NIC on an equivalent node. 

The measurements are with me. Linux, properly configured, is a very fast bootloader. UEFI has always been nothing but slow. And that's still true; I've seen recent systems with "stripped down" UEFI and they are still appallingly slow, slower than linuxbios was in 2000 on slow CPUs. I still can't see the point of UEFI (well, I can: Intel has been telling me for 16 years that UEFI is a way to ensure they can distribute binary blobs for firmware and not reveal "core IP" to their BIOS ecosystem). Linux on ARM for auto computers hit the 800ms boot time goal 10 years ago. I have seen UEFI systems that get booted in seconds, but not much closer and getting them there is a huge amount of work. What's the point? 

Also, your proposal above, while interesting, assumes a local disk. Many systems don't use a local disk *for booting* (they may have a local cache of data files -- just not a local root file system). So your idea would not work for many systems out there. 

thanks for the note! I always enjoy reading what you have to say even when I disagree :-)

ron