[coreboot] Rettungsboot

Zoran Stojsavljevic zoran.stojsavljevic at gmail.com
Sun Nov 27 10:02:59 CET 2016

Rettungs (German) - Ubersetzung/translate ist/is rescue. As much as I
know... Desperately trying to learn more Deutsche Sprache these days
(bloody tough - too old for it).

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!

UEFI BIOSes (64b - pleonasm) these days rule (Client and Server INTEL
CORE/ATOM platforms)... And Coreboot should (my subjective opinion -
pleonasm) add slim payload from described above: making just /boot/efi file
system... with CSM OFF, true UEFI environment.

Have no idea if GRUB2 as payload already does this (UEFI lookalike
/boot/efi)? This is the question I am asking Coreboot Community (if this is
the case, even better)! :-)

For Consumer Electronics, I completely agree with Ron and others in this

Thank you,

On Sun, Nov 27, 2016 at 1:23 AM, ron minnich <rminnich at gmail.com> wrote:

> And let's not forget John Lewis' excellent work on JELTKA for chromebooks,
> which is also Linux and kexec. I've used it and it's great.
> I have a replacement for petitboot which is an all-Go userland: u-root.
> Programs  in the root file system are Go source and are compiled on first
> use -- there's a full Go toolchain embedded in flash. There are only 5
> userland binaries on the root file system, four of which are Go toolchain,
> one is /init, and the rest is all Go source. I've got this working today on
> a KGPE-D16. I first tested it in Prague in 2014, and we've also had it
> working on the Gizmo II and a Chromebox. If you have 16 MiB flash, it just
> works -- really.
> So there's five efforts, working today, all based on linux and kexec, and
> at least one in commercial use.
> I think the lifeboat should come with a penguin painted on its side. It's
> known to work -- since 1999 :-) -- and it avoids recreating the full
> universe of drivers, protocols, file systems, and so on.
> ron
> On Sat, Nov 26, 2016 at 4:20 PM Zaolin <zaolin at das-labor.org> wrote:
>> In my opinion there are currently two payloads which are really
>> interesting and promising for end users:
>> * HEADS - https://github.com/osresearch/heads
>> * Petitboot - https://secure.raptorengineering.com/content/kb/1.html
>> I am currently working on the UI of Heads. So feel free to contribute ;)
>> Best Regards
>> Zaolin
>> On 11/26/2016 11:47 PM, ron minnich wrote:
>> Oh, my fingers type too much for me now.
>> The current set of (as you point out) not terrific options is a result of
>> linux growing too big for flash, and flash growing too SMALL for linux, ca.
>> 2002, when we adopted the payload model.
>> On Sat, Nov 26, 2016 at 3:46 PM ron minnich <rminnich at gmail.com> wrote:
>> coreboot today is linuxbios minus the linux. The original intent was
>> always that linux be our lifeboat. The current set of (as you point out)
>> not terrific options is a result of linux growing too big for flash, and
>> flash growing too big for linux, ca. 2002, when we adopted the payload
>> model. The original keyword in the config file was 'linux', not 'payload'.
>> The bootloaders we adopted (etherboot, filo, ...) were never (to me) a very
>> satisfactory replacement for linux. They always came with lots of
>> limitations.
>> But why linux? Why a full OS? Simple observation, here in my 35th year of
>> working with firmware and bootloaders.
>> Every bootloader starts simple, and becomes an OS. Every single one
>> starts with the intent of being small and compact and only supporting some
>> needed subset of file systems/devices/protocols and ends up implementing
>> everything. Because there was an attempt to start out simple, no matter how
>> good the intial design is, that design is overwhelmed by the continuous
>> addition of features, the result being a badly bloated, huge system with no
>> apparent design.
>> The exception, it has been argued, is EFI, which had some sort of design
>> in 1999. From my point of view, it skipped right past all the initial
>> stages and entered the world bloated and with no apparent design, or at
>> least not a very good one.
>> So you need to think, not in terms of lean and clean, but in terms of
>> what it looks like after a few years when everyone has attached their
>> favorite features to your lifeboat. I think it's a mistake to ever think
>> you are going to implement some limited-function, limited-footprint
>> bootloader, because people will jump on it and just add code. Just look at
>> what's happened with systemd.
>> Also worth considering is that the tinykernel configs have got linux down
>> to 400K. You can trim it down to that, and carefully add features back.
>> This comes with huge benefits I think. You get drivers that work, protocols
>> that work, all the file systems you want, and you can put nice interactive
>> boot UIs in user mode. Today's flash parts are more than large enough to do
>> a good environment -- tinycore linux could be used, for example, once it
>> was trimmed a bit. It's only about 12M today with a full X environment.
>> Power8 and Power9 systems use linux in flash as their bootloader. This
>> example has not been lost on other systems being developed today.
>> I think it's worth considering a tinykernel linux as bootloader before
>> you start with a new thing.
>> ron
> --
> coreboot mailing list: coreboot at coreboot.org
> https://www.coreboot.org/mailman/listinfo/coreboot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20161127/2f3fc805/attachment-0001.html>

More information about the coreboot mailing list