[coreboot] Add coreboot storage driver

[Aaron Durbin]

On Tue, Feb 14, 2017 at 1:06 PM, Nico Huber <nico.h at gmx.de> wrote:
> On 14.02.2017 18:56, ron minnich wrote:
>> 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.
>
> Agreed. I wouldn't call it a kernel, but it really seems to grow very
> ugly. Every time I think about this, I scarcely find anything that needs
> to be done in ramstage. I believe even most payloads could live without
> it with some more initialization done in romstage.
>
> Some things that I recall, what ramstage does:
>
>   o MP init => maybe can be done earlier, does it need RAM generally???

You need a stack and vector for the SIPI to be somewhere.

>
>   o PCI resource allocation => can be done offline
>     Just add the resources to the devicetree. If you want to boot
>     from a plugged card, that isn't in the devicetree, the payload
>     would have to handle it though.

This largely works with static allocation, but the question is if you
want to handle different SKUs of devices that have different hardware
behind root bridges. You need to recalculate the IO windows. You could
produce a signature of devices and leverage that for picking the right
static allocation. Doable, but gets kinda funky needing to run the
allocation pass for each configuration and ensuring its updated
properly.
>
>   o Those small PCI device "drivers" => I doubt they need RAM

That's how their initialization code is currently scheduled. May not
need RAM, but I'm not sure that's what makes them distinctive nor why
you bring this up? Just a regular pci device doesn't need anything in
practice. It's the workarounds and things that need to be done for
power optimization, etc is where the complexity arises. Using pci
device "drivers" as a proxy for all pci devices isn't representative.

>
>   o Table generation => Not that dynamic after all
>     I suppose much is done with static (compile time) information.

Sure, if you go and analyze devicetree.cb to know all the options.
Tables have quite a few things that change based on runtime attributes
aside from that. For example, a single firmware build can support a
different number SoC models that have largely different numbers of
CPUs, etc or support different feature sets that require different
table generation.

>
>   o Sometimes gfx modesetting => do it in the payload
>
> Nico