[coreboot] Rettungsboot

[Zoran Stojsavljevic]

> 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 at gmail.com> wrote:

>
>
> On Sun, Nov 27, 2016 at 1:03 AM Zoran Stojsavljevic <
> zoran.stojsavljevic at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20161128/5d3e7961/attachment-0001.html>