Patch Set 9:

That's why I would like to hear from you, Ron, what is the goal
of this change? Is it about handing over control to the payload
with less resources assigned (what Jeremy asks for)? or is it
about scanning less to reduce boot times? or about doing less
in general? or something entirely else that I miss?

1) yes, it is about handing over control to the payload with less resources assigned. Why?

...

2) Yes, it is about reducing boot times.

Intel got some pretty good numbers by reducing what coreboot is doing. I can let them speak to that but the performance was compelling.

That's interesting. Though, I have to say, I've also seen numbers
from Intel folks and they never came from somebody with a view on
the whole firmware topic. What they suggest seems doable, though,
with an OS tailored to the firmware; i.e. ignoring common inter-
faces like ACPI that make PCs compatible to generic OS's.

Also, please, whenever somebody from Intel tells you about boot
times, remind them (not matter who and at least once per day)
that Intel chose to integrate very slow binary blobs into coreboot.
coreboot: 600ms to the payload, blobboot (on much faster CPUs): 1.2s
(Just random numbers from the top of my head, but I think it
reflects reality pretty well. Also biased in favor of blobboot: the
600ms on GM45 include some DRAM training, the 1.2s don't.)

Subrata, can you give an update about the experiments of completely bypassing postcar-stage on FSP2.0 platforms? From what I remember, it started with a claim of ~15ms (<1%) improvement on entry to payload. Then, after some MTRR fix in coreboot proper, the experiment ended up being a ~7ms regression. During that painful and long review period, FSP-S (?) blob was updated and it was now 100ms slower? Is my post-mortem of the situation honest and accurate? Was the speed regression finally fixed or explained?

View Change

To view, visit change 36221. To unsubscribe, or for help writing mail filters, visit settings.