Nico Huber has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/36221 )
Change subject: Add configurable ramstage support for minimal PCI scanning ......................................................................
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?
- yes, it is about handing over control to the payload with less resources assigned. Why?
...
- 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.
- yes, it is about doing less in general
I 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:
- 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!
- 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?).