[coreboot] Add coreboot storage driver

[Zoran Stojsavljevic]

> Where do we go from here?

As I said (and I'll repeat, many times, if required - I do NOT care what
all INTEL [all their 13000+ managers] think):

*I have another idea for INTEL SoCs/CPUs, as HW architecture improvement.
Why your top-notch HW guys do NOT implement MRC as part of MCU. Some HW
thread inside CPU/SoC should execute MCU, shouldn't it? MRCs should be few
K in size, and they can perfectly fit in there, thus MRC should be (my take
on this) part of internal CPU architecture.*

*Today's INTEL COREs and ATOMs have at least/minimum 100M gates, why not to
add couple of dozen K more? Lot of problems solved, don't they? ;-)*
*[1] BOOT stage to be much shorter (no anything such as CAR phase);*
*[2] ROM stage does not exist;*
*[3] IP preserved in HW, so the whole INTEL FSP is actually (imagine the
Beauty) Open Source...*

With INTEL. Here we go! Where no one has gone before! ;-)

Zoran

On Tue, Feb 14, 2017 at 6:56 PM, ron minnich <rminnich at gmail.com> wrote:

> 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
>
> --
> 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/20170214/f28b31a6/attachment.html>