On Sat, 2021-12-04 at 20:53 +0800, Hung-Te Lin wrote:
On Wed, Dec 1, 2021 at 10:08 PM Patrick Georgi patrick@coreboot.org wrote:
- Dezember 2021 12:06, "Paul Menzel" pmenzel@molgen.mpg.de
schrieb:
If I remember correctly, coreboot’s goal to only do minimal hardware initialization originally meant, that the payload/OS does PCI initialization.
The original idea was to boot into Linux (hence LinuxBIOS, back in the day). coreboot is very different from this scheme, see the presence of payloads that aren't Linux.
Should PCI support be added to coreboot for ARM, so it’s aligned with x86? Should coreboot stay minimal on ARM, for example PCI code adds 100 ms delay [4]?
Need to check with MTK folks, but I'd assume the 100ms will be eliminated in the end, or re-implemented as early-init (and do the rest in depthcharge).
Agree, this 100ms is defined by the PCI specification, remove it directly will cause some compatibility issues, but I think we can put this flow in the early stage to reduce its impact.
PCI drivers then have to be added to the payloads, which could be a minimal Linux kernel, so that booting from drives connected over PCI is possible?
The only option I see for getting rid of PCI support on ARM is to remodel the relationships between coreboot, the payload and the OS. Reminds me that I wanted to build a proof-of-concept for chainloaded payloads, a concept that might help with such a redesign because we could move things out of coreboot to "elsewhere" (wherever that might be) piece by piece.
But as is, if there are PCI(e) devices that need early init, coreboot is the place to put these drivers.
Agree with Patrick - many eMMC devices do need early init, so in the end we still have to put some eMMC code in Coreboot, and I'd assume that will be the same situation for PCI-e (NVMe) and UFS.