[coreboot] Add coreboot storage driver

[Aaron Durbin]

On Mon, Feb 13, 2017 at 8:05 AM, Peter Stuge <peter at stuge.se> wrote:
> Andrey Petrov wrote:
>> We are considering adding early parallel code execution in coreboot.
>> We need to discuss how this can be done.
>
> No - first we need to duscuss *if* this should be done.
>
>
>> 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.
>
>
> 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.


There's an inherent sequence point between coreboot and the payload.
All of coreboot needs to complete prior to handing off execution to
the payload. Everyone's boot up process differs, but boot speed is
something Chrome OS cares about very much. That's one of the reason
coreboot has been enlisted for Chrome OS products. By maintaining that
delineation boot speed can very much suffer. Pushing work out to
another piece of software doesn't inherently reduce the total amount
of work to be done. That's the current dilemma. Do we just throw our
hands up and say things will continue to be slower? Or do we come up
to solutions to the current problems we're seeing?

>
>
>> 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?
>
>
>> scheduler
> ..
>> 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.
>
>
>> 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.
>
> This means that your scheduler lives in the payload. There is already
> precedent - SeaBIOS also already implements multitasking.
>
>
>> this is just a tip of iceberg
>
> That's exactly why it has no place within coreboot, but belongs in
> a payload.
>
>
> //Peter
>
> --
> coreboot mailing list: coreboot at coreboot.org
> https://www.coreboot.org/mailman/listinfo/coreboot