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.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
_______________________________________________
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org
