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.
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