<div dir="ltr"><span style="font-size:12.8px">> Or do you want to do the full EFI "let's waste 128MB of</span><span style="font-size:12.8px"> <b><i><u><font color="#ff0000">every</font></u></i></b></span><span style="font-size:12.8px"><b><i><u><font color="#ff0000"> disk</font></u></i></b> on</span><div><span style="font-size:12.8px">> a special FAT32 partition" madness (which still requires</span><span style="font-size:12.8px"> bootloaders to</span></div><div><span style="font-size:12.8px">> include one specific FS driver they might otherwise not </span><span style="font-size:12.8px">want)?</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">YES, you do. Accent on: </span><span style="font-size:12.8px"><font color="#ff0000" style="font-weight:bold;font-style:italic;text-decoration:underline">"every disk"</font><font color="#000000"> .</font></span></div><div><span style="font-size:12.8px"><b><i><u><font color="#ff0000"><br></font></u></i></b></span></div><div><span style="font-size:12.8px"><font color="#000000">Zoran</font></span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 29, 2016 at 10:53 PM, Julius Werner <span dir="ltr"><<a href="mailto:jwerner@chromium.org" target="_blank">jwerner@chromium.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> To sum it up, I want something that is lean and clean enough so it could<br>
be added to any bootloader. Even if that boot loader is not of the<br>
let's build a tiny OS type.<br>
<br>
</span>I don't really see how you could reach this goal with anything that<br>
requires reading a file from the boot media? There are billions of<br>
different file systems out there... do you want to require your<br>
"minimal" bootloader to include drivers for all of them? (There are<br>
bootloaders that don't contain any file system drivers at all, like<br>
depthcharge.) Or do you want to do the full EFI "let's waste 128MB of<br>
every disk on a special FAT32 partition" madness (which still requires<br>
bootloaders to include one specific FS driver they might otherwise not<br>
want)?<br>
<br>
I think if you want to do anything truly minimal and compatible with<br>
everything, you can't rely on files (and you should try to rely on<br>
partitions as little as possible, e.g. no full GPT parsing). Which<br>
probably means putting it in the first sector. And once you have that,<br>
you can create some fancy text-based format (or Go source file /<br>
node.js script / whatever the cool kids use these days) to describe<br>
the target sector, load address etc. of the fallback kernel... but<br>
you're really just exemplifying the XKCD Igor mentioned because you've<br>
just reinvented the MBR. (And let's face it... no coreboot bootloader<br>
has the pull to sufficiently promote adoption of some completely new<br>
fallback boot descriptor format right now, even if it doesn't require<br>
a Go compiler in your bootloader.)<br>
<br>
So, really, I think what you want is just the MBR. It is the deadest<br>
simple design possible (just load a sector and jump), it is as<br>
infinitely flexible as code itself, and it coexists perfectly with all<br>
partitioning schemes relevant today (MBR and GPT). Yes, it requires a<br>
software interrupt BIOS interface, but if the recovery kernel code is<br>
cleverly written you really only need the disk access part (and you<br>
know your bootloader already has that driver because that's how it<br>
loaded the MBR in the first place). And yes, on x86 it requires real<br>
mode (for non-x86 I'd just make up an as equivalent as possible system<br>
with your software interrupt solution of choice), but that's a small<br>
price you pay with a few files worth of shim code in exchange for<br>
automatic compatibility with 35 years worth of existing BIOSes. I'd<br>
say that's a better deal than any new dead-on-arrival scheme you could<br>
make up out of thin air.<br>
<br>
(If you really can't stand the idea of BIOS interrupts and real mode,<br>
I think your next best option would be to try to cram an<br>
as-small-as-possible binary recovery descriptor and the real mode code<br>
to parse/load/execute it together into the 446 bytes of MBR space you<br>
have. This way, your new payloads can just find and parse/load/execute<br>
the descriptor itself without having to provide any BIOS interface,<br>
but the thing is still compatible with existing legacy BIOSes as<br>
well.)<br>
<div class="HOEnZb"><div class="h5"><br>
--<br>
coreboot mailing list: <a href="mailto:coreboot@coreboot.org">coreboot@coreboot.org</a><br>
<a href="https://www.coreboot.org/mailman/listinfo/coreboot" rel="noreferrer" target="_blank">https://www.coreboot.org/<wbr>mailman/listinfo/coreboot</a><br>
</div></div></blockquote></div><br></div>