On Mon, Feb 13, 2017 at 8:05 AM, Peter Stuge peter@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@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot