On a semi related topic, a significant issue exists in the absence of a one stop shop debug option that works universally on all x86 platforms. The lack of universality means that people can only realistically work on boards for which they can get a reliable debug output. That massively narrows the number of boards that can be worked on easily. Very few platforms these days support serial, and I think PCI will be gone soon enough. I'm mulling over a potential solution in the form of a coreboot specific POST card. The device would display and log POST codes from 0x80, but also log coreboot console via some other IO, (please feel free to make suggestions as to what that should be). Since I know PCIe has pin breakouts for JTAG, we might as well log that as well.
All of this to say, that I don't see any of this continuing to be an option if PCI drivers end up pulled out of coreboot. Although that depends on a few things that perhaps somebody can clarify.
1.) Do we actually need these drivers to access 0x80 via PCI / PCIe. Or is that handled as a kind of hardware pass through. like with JTAG?
2.) Also are we talking only about traditional PCI drivers here, or PCIe as well?
On 6/12/21 9:59 pm, Angel Pons wrote:
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 _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org