Dear Julius,
Am 06.12.21 um 23:42 schrieb Julius Werner:
If I remember correctly, coreboot’s goal to only do minimal hardware initialization originally meant, that the payload/OS does PCI initialization.
FWIW, coreboot does do device initialization for things that are only needed by the payload in other cases too: we've been doing display and USB initialization that way for years. This only works in those cases where you need to do a lot of very platform-specific stuff to turn something on, but then after that it presents a very simple generic API (like a framebuffer or standardized host controller interface), but I think PCI also falls in that area. I think it's useful so that payloads don't all need to implement that super SoC-specific stuff individually.
It’s hard to draw a clear line. But let’s keep in mind, that the Linux kernel has already working drivers.
In general, I don't think we should be too strict about what coreboot should or shouldn't be in cases where someone just wants to add an optional feature that doesn't introduce a huge maintenance burden on the core framework. If someone doesn't like it they can just disable the Kconfig and do PCI init in the payload / the kernel / via node.js or whatever instead. This has clearly been useful on x86 platforms for years, so I don't see why Arm platforms shouldn't be allowed to do it as well.
I do not want to block or forbid anything. Your point about making it configurable is very good. I think disabling PCI initialization is currently not possible for x86 with `make menuconfig`. It’d be great if it would be possible for ARM. The use case of having coreboot and the payload with all drivers (Linux kernel) in the flash ROM chip, so a build without PCI, graphics and USB init should be easily configurable.
But, currently, selecting Google Asurada in Kconfig (`make menuconfig`), display initialization cannot be disabled, and I do not see a way to disable USB init either.
Kind regards,
Paul