amusement value:
How long was the minimum time to cross USA from East Coast (NYC) to West Coast (SF) back then in 1880s (Vayat Erp and Dock Holiday time: by horse or carriage)?
And how long for the same distance Today/Present time (by plane or shuttle)?
Ron, technology advances... Doesn't it??? ;-)
Zoran
On Wed, Nov 30, 2016 at 10:18 PM, ron minnich rminnich@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@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@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@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
-
Zoran Stojsavljevic