Dear TI team,
we're currently trying to access the PRU-ICSS dual emac firmware directly from a x86 processor to which the AM65x is connected as a PCIe EP (x86 is RC).
For this we need to use the MCU NAVSS proxy to access a ring via the RA that is used in message mode.
Unfortunately the proxy generates an error when we're trying to access it from the x86 via PCIe.
We're using proxy #16 at base address 0x2a510000. The proxy is configured for tail access mode with an elment size of 0x8 (we need it to write 64-bit pointers to the RA).
With this configuration we need to write our data to address 0x2a5103f8...0x2a5103ff. Writing the last byte should trigger the proxy write to the destination. Write outside of that address range should generate an error.
When we write using a 64-bit write (or a 32-bit, or a 8-bit write) to 0x2a5103f8, we immediately see an error signaled in the PROXY_STATUS register @ 0x2a510004.
In order to debug this we've configured the firewall in front of the proxy to deny accesses via PCIe. This resulted in a firewall exception being logged that saw an access to address 0x00002A5103F0 with a length of 0x10. This is the same problem that we saw exactly a year ago when we tried to access the DRU via PCIe, see the referenced thread. Here's the full content of the firewall registers:
0x45b04000 01 71 00 66 00 00 00 00 00 00 00 00 00 00 00 00 0x45b04010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x45b04020 00 00 00 00 00 74 18 01 00 00 07 00 F0 03 51 2A 0x45b04030 00 00 00 00 B3 20 63 01 10 00 00 00 00 00 00 00
Back then we verified that the accesses on the PCIe bus appear with exactly the right properties (correct address, correct size, correct 1st/last byte enables).
We're sure that this is not an issue of any firewalls blocking the access, as we don't see any firewall exceptions being logged, except when we deliberately deny access via PCIe for debugging purposes.
To me it looks like the PCIe AXI2VBUSM bridge turning every transaction to an aligned 128-bit transaction (the documentation says the bridge is 128 bits wide), and that some peripherals (at least DRU and proxy) can't handle these transactions. I would consider that a bug ("undocumented constraint") in the hardware, unless there's some configuration option that I'm missing.
I just noticed that jian35385 came back on the original thread (which is locked without a solution) regarding the mapping to LP/HP ports. Not sure what exactly I should be looking for, but the VMAP_HP_CTRL_j and VMAP_LP_CTRL_j registers are all 0, i.e. the mapping is not enabled.