Hi list, On Mon, Dec 6, 2021 at 7:37 AM Jianjun Wang <jianjun.w...@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 <patr...@coreboot.org> > > wrote: > > > 1. Dezember 2021 12:06, "Paul Menzel" <pmen...@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 _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
