Possibly silly question but does the device support MSI-X (or MSI)? Dmesg grep doesn’t see it. Is it disabled or completely missing and unsupported?
iMX8M integrates PCIe susbsystem which can be used as PCI Express root complex or as endpoint device. As I read the full manual, MSI/MSI-X is supported for both directions, i.e. PCIe device realized by iMX8M send MSI interrupt to the host or vice versa write to configured region generates interrupts on iMX8M processor.
But as I have studied hardware design and even kernel sources of Librem 5 in past, there is no device connected by PCIe so the whole PCIe SoC susbsystem is not enabled and all PCIe PHY pins/balls are left open… So there is no use for PCIe etc… Yes, it would be interesting when PCIe is routed as alt mode into USB-C connector (usable for docking station with PCIe GPU or something) or into modem or WiFi M.2 slot for some experiments. But reality is that PCIe is relatively power hungry so the problems with operation time on battery would be even worse… So decision to not use it is the most probably right choice.
Even USB to LTE modem is problematic from point of current consumption optimizations… Tightly integrated modems and WiFi into SoCs in Apple and other setups where chips are designed for given mobile set is big advantage. But without open source base-band and hypervisors firmware and usually zero public documentation none of such chips can be used for open-source solution nor allow any user audit of separation/no back door between DSPs and main processor memory with user data.
3 Likes
I think that’s the main reason. To get the separation, you can’t use a PCIe device (unless the device were “open”), so PCIe might as well be disabled at the host end.
That is interesting insight. If we disregard the power consumption and back door issue for a moment… Do you mean it’s unavailable permanently or can the pcie and MSI-X still be enabled in L5? I came across one of those “I wonder If I could get this to work here, though it’s not intended for it” experiments.
For what, if the PCIe signal are not connected anywhere and on the SoC all peripherals are tightly coupled on the local bus and go directly to Global Interrupt Controller (GIC) on RAM Cortex-A53 then ther is no use for PCIe and no speedup by MSI-X or equivalent needed. Yes, on x86 when you have peripherals on PCIe physical link or iterated onto central “processor” SoC then which to message signaled interrupts delivered by PCI write transaction into root complex provided memory is win compared to emulation of four discrete PCI interrupt wires routed through legacy 8259 nonsense… But there is no such bottleneck on ARM system for integrated peripherals…
Try to describe your idea for their use or what it could improve…
But there will be no use for MSI-X and even for PCIe at all on actual Librem 5 design… so that is dead end for discussion for real use…
As for vulnerabilities through PCIe, that is problem of bus master operations from devices but on modern PCIe root complex it can be prevented through IOMMU setup and maintained by drivers. But it is right complex and has additional cons when data transfers are setup.
1 Like
I have no idea of its usefulness. All I know it (MSI-X) seems to be a requirement for this one m.2 card to work at all. I’m not interested in changing the L5 current design in general, just if there is a workaround to enable it now (with reasonable effort).
But it has reason only for M.2 cards in the variants A, B, E and M when PCIe pins are used.
Librem 5 has only SDIO, USB 2.0 I2S and UART connected to BT WiFi M.2 slot (even that E-key allows PCIe) and other Key B slot for modem with only PCM, UM used for SIM, USB 2.0 and some GPIOs (in the fact I2C) for some modem specific control…
So no PCIe pin connect to any of there slots.
You can find my analysis of Librem 5 hardware and presentation there
more with recording but in Czech only sorry
3 Likes
Ah, that settles it, unfortunately. Won’t work. Too bad. Thanks for clearing that up!