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 < [email protected]> 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 <[email protected]> > 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: [email protected] > https://www.coreboot.org/mailman/listinfo/coreboot > >
-- coreboot mailing list: [email protected] https://www.coreboot.org/mailman/listinfo/coreboot
