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.)
Actually, not about FSP runtime effects, but I've just started
to document problems with its integration and why FSP-S causes
more trouble than it solves: CB:36328. Feel free to add boot
times as an incentive for more open source.
3) yes, it is about doing less in generalI like systems that do as little as possible. If we can remove work, I think we should.
From an esthetic standpoint, on systems I know will boot 64-bit linux kernels in flash (i.e. what Google and facebook are rolling into their data centers today -- 64-bit linux kernels in flash) running the coreboot allocator no longer seems needed. The kernel nowadays has its own preferences about how to configure PCI, and it doesn't make a lot of sense for coreboot to do a bunch of work the kernel either will undo or would like to undo.
So that's it. I would guess there are more reasons, but these are the ones that I think answer your questions.
Thanks for the elaboration, actually didn't ask for reasons,
but it's also very useful information :)
This discussion then splits into 2 questions:1) do we ever see coreboot allowing this kind of change? On this answer hinges the future use of coreboot by those using it now. I.e., they might well decided they need to use something else.
I'd say, yes, of course!
2) If the change in this CL is not acceptable, what change can we make that mostly eliminates coreboot PCI scanning? Is the alternative Kyosti mentioned acceptable, for example? If not, what is?
I didn't follow Kyösti's suggestions in every details, but it
seems he has the right idea.
PCI scanning and resource allocation are two separate problems. It
is very hard to keep compatibility with the current per-platform
code and get rid of the former. Resource allocation, OTOH, is only
needed if coreboot itself uses the resources. Which is hard to say
for SoC integrated devices (FSP blackbox issues) unless the code
is open-source. It is quite possible, for instance, that if you
don't assign resources to the SATA device, that FSP fails to set
correct drive-strengths on the PHYs. Things like this won't be
noticed without intensive testing (or reading vendor code...). So
I don't think this is a problem that should be trialed-by-error.
For the resource problem, this might also be a point to start
experimenting: Stub out pci_dev_read_resources() for the devices
that shouldn't have resources assigned. It's still a little unclear
to me which devices would need that and why, though (what can
coreboot do that Linux can't undo?).
To view, visit change 36221. To unsubscribe, or for help writing mail filters, visit settings.