[coreboot] Add coreboot storage driver

[Andrey Petrov]

Hi,

On 02/13/2017 06:05 AM, Peter Stuge wrote:
> Andrey Petrov wrote:

>> Nowadays we see firmware getting more complicated.
>
> Sorry, but that's nonsense. Indeed MSFT is pushing more and more
> complicated requirements into the EFI/UEFI ecosystem, but that's
> their problem, not a universal one.

I wish it was only MSFT. Chrome systems do a lot of work early on that 
is CPU intensive, and there waiting on secure hardware as well. Then 
there is the IO problem that original patch tries to address.

> Your colleague wants to speed up boot time by moving storage driver
> code from the payload into coreboot proper, but in fact this goes
> directly against the design goals of coreboot, so here's a refresh:
>
> * coreboot has *minimal* platform (think buses, not peripherals)
>   initialization code
>
> * A payload does everything further.

This is nice and clean design, no doubt about it. However, it is serial.

Another design goal of coreboot is to be fast. Do "be fast" and "be 
parallel" conflict?

>> 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. Interestingly, great deal of tasks that needs to be
>> done are not even computation-bound. They are IO bound.
>
> How much of that time is spent in the FSP?

FSP is about 250ms grand total. However, that is not all that great if 
you compare to IO to load kernel over SHDCI (130ms) and initialize eMMC 
device itself (100-300ms). Not to mention other IO-bound tasks that can 
very well be started in parallel early.

>> how to create infrastructure to run code in parallel in such early stage
>
> I think you are going in completely the wrong direction.
>
> You want a scheduler, but that very clearly does not belong in coreboot.

Actually I am just interested in getting things to boot faster. It can 
be scheduling or parallel execution on secondary HW threads.

>> Shall we just add "run this (mini) stage on this core" concept?
>> Or shall we add tasklet/worklet structures
>
> Neither. The correct engineering solution is very simple - adapt FSP
> to fit into coreboot, instead of trying to do things the other way
> around.

FSP definitely needs a lot of love to be more usable, I couldn't agree 
more. But if hardware needs be waited on and your initialization process 
is serial, you will end up wasting time on polling while you could be 
doing something else.

> This means that your scheduler lives in the payload. There is already
> precedent - SeaBIOS also already implements multitasking.

Unfortunately it is way too late to even make a dent on overall boot time.

Andrey