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 thread. Thank you, Zoran On Sun, Nov 27, 2016 at 1:23 AM, ron minnich <rminn...@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 <zao...@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 <rminn...@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@coreboot.org > https://www.coreboot.org/mailman/listinfo/coreboot >
-- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
