Is Expansion ROM feature broken on PCIe2, PCIe3, and PCIe4?

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Is Expansion ROM feature broken on PCIe2, PCIe3, and PCIe4?

863 Views
asierra
Contributor I

I have two T1042-based devices that each use two PCIe controllers in endpoint mode:

  1. uses the PCIe1 and PCIe3 controllers
  2. uses the PCIe1 and PCIe2 controllers

Both devices exhibit the same issue.

I have tried to take advantage of the advertised Expansion ROM feature on both of the PCIe controllers for each device (simultaneously and individually) with only limited success. I have found that address translation through the Expansion ROM BAR works as expected when used with the PCIe1 controller. However, attempting to do the same with PCIe2 or PCIe3 seems to suggest that address translation is somehow nonfunctional.

For example, configuring the PCIe2 or PCIe3 inbound expansion ROM ATMU window registers (PEXx_PEXEPROMITAR and PEXx_PEXEPROMIWAR) identically to PCIe1 results in:

  • a correctly sized Expansion ROM BAR when viewed from the root complex
  • the first read request to the Expansion ROM BAR locks up the PCIe controller from the root complex

I have tested mapping the Expansion ROM BAR to RAM and to parallel NOR flash. The configurations below work as expected with PCIe1, but not with PCIe2 or PCIe3.

Example configuration mapping to RAM

My device has 8 GiB of RAM mapped from physical address 0x0_00000000 to 0x1_ffffffff. I attempt to map 64 KiB at 0x1_fffc0000:

  • PEXx_PEXEPROMITAR = 0x001fffc0
  • PEXx_PEXEPROMIWAR = 0xa0f5500f

Example configuration mapping to NOR

My device has 256 MiB of NOR mapped from physical address 0xf_f0000000 to 0xf_ffffffff. I attempt to map 64 KiB at 0xf_f0060000:

  • PEXx_PEXEPROMITAR = 0x00ff0060
  • PEXx_PEXEPROMIWAR = 0x80f4400f
Labels (1)
0 Kudos
3 Replies

646 Views
asierra
Contributor I

I am glad to hear that the IP is identical. That is what the reference manual lead me to believe. However, I am still at a loss to explain the behavior that I observe. I have attached the following:

  1. U-Boot POST log from our device using PCIe1 and PCIe3 as endpoints (uboot-post.log)
  2. Raw inbound ATMU dumps for PCIe1 and PCIe3 (pcieN-in-atmu-raw.log)
  3. Raw PCI config type 0 dump for PCIe1 and PCIe3 from external host (pcieN-raw-config0.log)
  4. Decoded PCI config space for PCIe1 and PCIe from external host (pcieN-lspci.log)
0 Kudos

646 Views
ufedor
NXP Employee
NXP Employee

The issue could be complicated and it is more convenient to investigate it as a Technical Case:

https://community.nxp.com/thread/381898 

0 Kudos

646 Views
ufedor
NXP Employee
NXP Employee

The T1040/42 PEx IPs are identical.

Possible explanation of the issue is a misconfiguration.

Please provide as attachments:

1) U-Boot booting log (as text file)

2) raw memory dumps of the PEx Inbound ATMUs CCSR areas for all involved PEx controllers

3) Type 0 configuration headers registers for all involved PEx controllers

0 Kudos