Kyösti Mälkki has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/36221 )
Change subject: WIP: Add configurable ramstage support for minimal PCI scanning ......................................................................
Patch Set 12:
Patch Set 12:
(1 comment)
Patch Set 11:
(1 comment)
for the read_resources approach, could I do this; in the standard read_resources, if CONFIG_MINIMAL_PCI_SCANNING is set, I just return and then add a new function read_resources_always which does not test CONFIG_MINIMAL_PCI_SCANNING?
It would be nice to do this without changing the whole tree, at least until we know if it works.
I would want to see a solution that does not break when payload is other than kernel or TianoCore. That means a complete PCI tree enumeration and only leaving the problematic resources unassigned. To maintain the boot diversity and leave a choice of payload to the 'user', I would hate to see SoC vendors telling their platforms now require MINIMAL_PCI_SCANNING=y to boot at all.
Those problematic resources can often be classified as PREFMEM and >= 64MiB in size. Often, they would also be graphics, so they might not be boot-critical for common payloads like SeaBIOS and GRUB. Does it matter when payload screen does not appear on 4 screens?
Currently, there should be few of these problematic resources within integrated PCI devices. The number of drivers where .read_resources needs to change is small, maybe even limited to that USB4/ThunderBolt. But Jeremy investigated even that could have generic solution by checking for some PCIe capability blocks? To handle all this ill-resource detection in pci_dev_read_resources() would take care of anonymous add-on PCIe cards too.