Accessing PCIe endpoint BAR on NXP iMX8MM

[davidfenger-ivl]

I'm trying to build for a system that's using the NXP iMX8MM PCIe port in endpoint mode. To make my life a little easier, I'm letting Linux do the heavy lifting of getting the PCIe endpoint up and running. It can see and access the BAR registers, and I have a driver on the host PC that can read and write them, and sees the same values as the linux-side endpoint function writes.

However, I need to access these registers (and mostly manage DMA) with the lower latency jailhouse and zephyr offers. So I need to figure out how to talk to the BAR. Yes, this is something of a hack, but I don't see any drivers for the PCIe IP NXP is using. If they exist somewhere, a pointer to how to set it up would be very helpful.

I can use device_map to access the PCIe device registers at 0x33800000, and I can see how the iATU has been configured. It looks like it's pointing at 0x18000000, which is marked as PCIe address space in the reference manual and Linux device tree. But when I try to map that, it does not work - trying to read from it causes the host PC (other end of the PCIe link) to bluescreen due to a DMA violation.

Obviously I need to either access different memory or map it in a different way. Any advice or pointers on how to do this would be most welcome.

[Zhiqiang-Hou]

Hi David,

My understanding is it works well when running Linux on imx8mm and PCIe working in EP mode, then you try to replace the Linux with Zephyr on imx8mm to drive PCIe EP, right?

For the host PC access to the imx8mm PCIe EP's Config space, it uses ID addressing, so it does not depend on the mapping on imx8mm. but you need to do some setup in EP side, before host PC to enumerate the PCIe buses. Please refer to the Linux imx pcie driver.

[davidfenger-ivl]

It's a little more complex than that - we're running jailhouse, with Linux on one side, and Zephyr in the inmate. I'm letting the Linux code handle the initialization, then trying to figure out just what it ended up doing. Reading the registers can be easier then trying to understand the code.

I've sorted out the issue. The 0x18000000 address range is for outgoing messages to the host - in practice, it's only used to send MSI interrupts. Once I figured out that I needed to look at the configuration of the iATU inbound registers to locate the BAR memory, I was able to successfully talk to the BAR. It gets mapped to a consistent physical memory location from run to run, so I was able to set jailhouse permissions so that zephyr can access it (by reading the relevant iATU register to get the memory address, then mapping it).

[Zhiqiang-Hou]

Okay, it's clear now, you leverage the Linux PCIe endpoint driver to initialize the controller and implement the endpoint logic in jailhouse inmate Zephyr. It's interesting but some kind of hack.

[davidfenger-ivl]

If you know of a zephyr driver that can do the same for the Freescale PCIe endpoint on an NXP iMX chip, I'd be happy to use that instead. I don't see any sign of one in the code, though. So direct register access it is...