[coreboot] Add coreboot storage driver

[ron minnich]

Just a reminder about times past. This discussion has been ongoing since
2000. In my view the questions come down to how much the ramstage does, how
that impacts code complexity and performance, and when the ramstage gets so
much capability that it ought to be a kernel.

In the earliest iteration, there was no ramstage per se. What we now call
the ramstage was a Linux kernel.

We had lots of discussions in the early days with LNXI and others about
what would boot fastest, a dedicated boot loader like etherboot or a
general purpose kernel like Linux. In all the cases we measured at Los
Alamos, Linux always won, easily: yes, slower to load than etherboot, more
startup overhead, but once started Linux support for concurrency and
parallelism always won the day. Loaders like etherboot (and its descendant,
iPXE) spend most of their time doing nothing (as measured at the time). It
was fun to boot 1000 nodes in the time it took PXE on one node to find a
connected NIC.

The arguments over payload ended when the FLASH sockets changed to QFP and
maxed at 256K and Linux could no longer fit.

But if your goal is fast boot, in fact if your goal is 800 miliseconds, we
know this can work on slow ARMs with Linux, as was shown in 2006.

The very first ramstage was created because Linux could not correctly
configure a PCI bus in 2000. The core of the ramstage as we know it was the
PCI config.

We wanted to have ramstage only do PCI setup. We initially put SMP startup
in Linux, which worked on all but K7, at which point ramstage took on SMP
startup too. And ramstage started to grow. The growth has never stopped.

At what point is ramstage a kernel? I think at the point we add file
systems or preemptive scheduling. We're getting dangerously close. If we
really start to cross that boundary, it's time to rethink the ramstage in
my view. It's not a good foundation for a kernel.

I've experimented with kernel-as-ramstage with harvey on the riscv and it
worked. In this case, I manually removed the ramstage from coreboot.rom and
replaced it with a kernel. It would be interesting, to me at least, to have
a Kconfig option whereby we can replace the ramstage with some other ELF
file, to aid such exploration.

I also wonder if we're not at a fork in the road in some ways. There are
open systems, like RISCV, in which we have full control and can really get
flexibility in how we boot. We can influence the RISCV vendors not to
implement hardware designs that have negative impact on firmware and boot
time performance. And then there are closed systems, like x86, in which
many opportunities for optimization are lost, and we have little
opportunity to impact hardware design. We also can't get very smart on x86
because the FSP boulder blocks the road.

Where do we go from here?

ron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20170214/00913faa/attachment.html>