[coreboot] Add coreboot storage driver

[Nico Huber]

On 13.02.2017 08:19, Andrey Petrov wrote:
> For example Apollolake is struggling to finish firmware boot with all
> the whistles and bells (vboot, tpm and our friendly, ever-vigilant TXE)
> under one second.
Can you provide exhaustive figures, which part of this system's boot
process takes how long? That would make it easier to reason about where
"parallelism" would provide a benefit.

> In order to address this problem we can do following things:
> 1. Add scheduler, early or not

Yes, but really doesn't fit into the coreboot idea, IMHO.

> 2. Add early MPinit code

No? um, at best very limited (by the number of threads the hardware sup-
ports).

> For [2] we have been working on prototype for Apollolake that does
> pre-memory MPinit. We've got to a stage where we can run C code on
> another core before DRAM is up (please do not try that at home, because
> you'd need custom experimental ucode). However, there are many questions
> what model to use and how to create infrastructure to run code in
> parallel in such early stage. Shall we just add "run this (mini) stage
> on this core" concept? Or shall we add tasklet/worklet structures that
> would allow code to live in run and when migration to DRAM happens have
> infrastructure take care of managing context and potentially resume it?
> One problem is that code running with CAR needs to stop by the time
> system is ready to tear down CAR and migrate to DRAM. We don't want to
> delay that by waiting on such task to complete. At the same time,
> certain task may have largely fluctuating run times so you would want to
> continue them. It is actually may be possible just to do that, if we use
> same address space for CAR and DRAM. But come to think of it, this is
> just a tip of iceberg and there are packs of other issues we would need
> to deal with.

Sounds very scary, as if it would never fit, not matter how strong you
push. If you really think, we should do something in parallel across
coreboot stages, it might be time to redesign the whole thing across
stages.

As long as there is a concept involving romstage/ramstage, we should
keep it to one thing in romstage: getting DRAM up. If this needs a
clumsy blob, then accept its time penalty.

> 
> Does any of that make sense? Perhaps somebody thought of this before?
> Let's see what may be other ways to deal with this challenge.

3. Design a driver architecture that doesn't suffer from io-waiting

This is something I kept in mind for payloads for some time now, but it
could also apply to later coreboot stages: Instead of busy waiting for
i/o, a driver could yield execution until it's called again. Obviously,
this only helps if there is more than one driver running in "parallel".
But it scales much better than one virtual core per driver...

Another idea just popped up: Performing "background" tasks in udelay()
/ mdelay() implementations ;)

I guess there are many more, maybe some viable, approaches to solve it
with only one thread of execution.

Anyway, I rather see this parallelism in payloads. Another thought: If
there is something in coreboot that really slows booting down, maybe
that could be moved into the payload?

Nico