Hi list,
On Mon, Dec 6, 2021 at 7:37 AM Jianjun Wang jianjun.wang@mediatek.com wrote:
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]?
Paul, coreboot would "stay minimal" if that PCI code was moved into depthcharge as-is, but the 100ms delay would still be there and other payloads would be missing PCI init. I'm pretty sure this isn't what you want, though.
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).
I don't think any of the PCI code belongs into depthcharge. I'm pretty sure it can be integrated better to leverage the existing coreboot infrastructure, e.g. the resource allocator and the devicetree.
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.
As I understand the spec, 100ms is the *minimum* delay before PERST# de-assertion, so it's possible to use a longer delay while doing something else in the meantime. One way to implement this would be to assert PERST# early and do some other initialisation in the meantime, e.g. memory init. To ensure that at least 100ms have elapsed, a stopwatch from `src/include/timer.h` is very convenient.
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.
I don't know what this "early init" consists of, but it sounds like something that should be done in coreboot. It could possibly be done in a passthrough/chainloaded payload (which would do late ramstage init), but it wouldn't really make much of a difference. The idea is to start abstracting the hardware so that regular (non-passthrough) payloads don't need to know hardware-specific details.
Best regards, Angel