[coreboot] Rettungsboot

ron minnich rminnich at gmail.com
Wed Nov 30 22:19:09 CET 2016

OK, then someone just asked me: how long does it take to rewrite that 128
MiB vs. the 512 byte sector on the floppy. :-)

On Wed, Nov 30, 2016 at 1:18 PM ron minnich <rminnich at gmail.com> wrote:

> amusement value:
> The 512 bytes used for MBR is about .04% of the 8" floppy disk that
> shipped with the original IBM PC. For 128 MB to be that fraction of a new
> disk, the disk would have to be 256 GiB. That's about $40 worth of disk.
> Geez.
> On Wed, Nov 30, 2016 at 11:00 AM Zoran Stojsavljevic <
> zoran.stojsavljevic at gmail.com> wrote:
>> > Or do you want to do the full EFI "let's waste 128MB of *every** disk*
>> on
>> > a special FAT32 partition" madness (which still requires bootloaders to
>> > include one specific FS driver they might otherwise not want)?
>> YES, you do. Accent on: "every disk" .
>> Zoran
>> On Tue, Nov 29, 2016 at 10:53 PM, Julius Werner <jwerner at chromium.org>
>> wrote:
>> > To sum it up, I want something that is lean and clean enough so it could
>> be added to any bootloader. Even if that boot loader is not of the
>> let's build a tiny OS type.
>> I don't really see how you could reach this goal with anything that
>> requires reading a file from the boot media? There are billions of
>> different file systems out there... do you want to require your
>> "minimal" bootloader to include drivers for all of them? (There are
>> bootloaders that don't contain any file system drivers at all, like
>> depthcharge.) Or do you want to do the full EFI "let's waste 128MB of
>> every disk on a special FAT32 partition" madness (which still requires
>> bootloaders to include one specific FS driver they might otherwise not
>> want)?
>> I think if you want to do anything truly minimal and compatible with
>> everything, you can't rely on files (and you should try to rely on
>> partitions as little as possible, e.g. no full GPT parsing). Which
>> probably means putting it in the first sector. And once you have that,
>> you can create some fancy text-based format (or Go source file /
>> node.js script / whatever the cool kids use these days) to describe
>> the target sector, load address etc. of the fallback kernel... but
>> you're really just exemplifying the XKCD Igor mentioned because you've
>> just reinvented the MBR. (And let's face it... no coreboot bootloader
>> has the pull to sufficiently promote adoption of some completely new
>> fallback boot descriptor format right now, even if it doesn't require
>> a Go compiler in your bootloader.)
>> So, really, I think what you want is just the MBR. It is the deadest
>> simple design possible (just load a sector and jump), it is as
>> infinitely flexible as code itself, and it coexists perfectly with all
>> partitioning schemes relevant today (MBR and GPT). Yes, it requires a
>> software interrupt BIOS interface, but if the recovery kernel code is
>> cleverly written you really only need the disk access part (and you
>> know your bootloader already has that driver because that's how it
>> loaded the MBR in the first place). And yes, on x86 it requires real
>> mode (for non-x86 I'd just make up an as equivalent as possible system
>> with your software interrupt solution of choice), but that's a small
>> price you pay with a few files worth of shim code in exchange for
>> automatic compatibility with 35 years worth of existing BIOSes. I'd
>> say that's a better deal than any new dead-on-arrival scheme you could
>> make up out of thin air.
>> (If you really can't stand the idea of BIOS interrupts and real mode,
>> I think your next best option would be to try to cram an
>> as-small-as-possible binary recovery descriptor and the real mode code
>> to parse/load/execute it together into the 446 bytes of MBR space you
>> have. This way, your new payloads can just find and parse/load/execute
>> the descriptor itself without having to provide any BIOS interface,
>> but the thing is still compatible with existing legacy BIOSes as
>> well.)
>> --
>> 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/20161130/b0570788/attachment.html>

More information about the coreboot mailing list