<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Sun, Nov 27, 2016 at 1:03 AM Zoran Stojsavljevic <<a href="mailto:zoran.stojsavljevic@gmail.com">zoran.stojsavljevic@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">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. </div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">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!</div></div></blockquote><div><br></div><div>Every time I put linux in flash and used it as a bootloader, it was faster than Tiano or UEFI. Every. Single.Time. </div><div><br></div><div>Plus, I could for the most part read the code. Tiano code makes my eyes hurt.</div><div><br></div><div>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.<br></div><div><br></div><div>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. </div><div><br></div><div>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? </div><div><br></div><div>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. </div><div><br></div><div>thanks for the note! I always enjoy reading what you have to say even when I disagree :-)</div><div><br></div><div>ron </div></div></div>