Ubuntu arm pcie driver doesn't load RM520 with R03 firmware

I’ve recently got a new RM520NGLAA-M20-SGASA with RM520NGLAAR03A03M4G
I put it in a Khadas VIM4.
The pcie driver does not load correctly - I only see 1 mhi_device
/dev/mhi_BHI
And no
/dev/mhi_LOOPBACK , /dev/mhi_DUN /dev/mhi_MBIM etc

When I replace the device with one running older firmware I see all the mhi_ devices.

I notice that dmesg contains this:

[ 43.907416] mhi_init Quectel_Linux_PCIE_MHI_Driver_V1.3.7
[ 43.908037] Failed to set up IOMMU for device 0000:01:00.0; retaining platform DMA ops
[ 43.908078] mhi_pci_probe pci_dev->name = 0000:01:00.0, domain=0, bus=1, slot=0, vendor=17CB, device=0308

Can you please tell me what the problem might be - I can go back to the board maker if needed…

I need to use the newer firmware to access e-sim features.

Here are some logs for r01 and r03 firmware…

r01dmesg.txt (6.2 KB)
r03dmesg.txt (5.0 KB)

Dear @steely-glint
Could you confirm the modem worked before? From log, mhi_power_up is abnomal.

@silvia

Hi,

The R01 modem works in both pcie mode and usb mode
The R03 modem only works in usb mode

2 different modems tested in the same hardware. (Khadas VIM4 running Ubuntu)

(We have several devices running the R01 firmware in pcie mode)

Hope that helps -

Thanks.

Tim.

Dear @steely-glint
So did you change module to PCIe mode? And use the latest version of driver?

@silvia Hi,
I’m using

Quectel_Linux_PCIE_MHI_Driver_V1.3.7

I think that is the latest driver.

I set

AT+QCFG=“data_interface”,1,0

Then power cycled - It sees the device with lspci - and creates /dev/mhi_BHI but not the other devices.

Are there any other tests I can do to help debug?

Thanks.

Tim.

Dear @Bean.Wang-Q
Please help to check.

I suggest you use an oscilloscope to capture the dial waveform of PCIE_RST and PCIE_WAIT.
Normally, if analysis is required, we need to get the debug port log of the module.

@Bean.Wang-Q I have looked at the board and layout and I do not think I can access the necessary PCIE lines with oscilloscope probes as they are on the bottom side of the connector so not exposed when the module is plugged in.

Are there logs (either device or driver side) I can capture that would help diagnose this problem?

If I have a diagnosis from you I can probably get the board maker to fix it!

Thanks!

Tim

P.s.

I have found that randomly delaying the driver load sometimes works - which does indicate this is a timing issue. However the former firmware works every time.