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
--
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot