PCIe C5 Endpoint Register Access Issue in UEFI Shell

Editing to Clarify. Title also updated:
PCIe C5 is set to endpoint following the instructions here: Jetson AGX Orin Platform Adaptation and Bring-Up — Jetson Linux<br/>Developer Guide 34.1 documentation

I need to check link status and control registers. From what I can gather from the Orin Technical Reference Manual (TRM), this should be 0x141a0000 (and iATU offsets).

When attempting to access these registers in the UEFI shell with ‘mm’, the system crashes and reboots. Accessing the C4 and other registers works just fine.

How can I access these C5 registers while configured as an endpoint?

ORIGINAL: I am trying to read the values in the UEFI shell using mm, however when I input the desired address, the system crashes and reboots. I am clearly missing something here. I’ve never run into this issue on any other processors so I must be misreading or overlooking something in the datasheet.

I am using the Orin Technical Reference Manual as my reference for addresses.

For example, I wish to read PCIE_C5_CTL (0x141a0000). I enter mm 141a0000 and get an error and the system reboots. There must be an offset or base that I’m missing.
Any help would be great. Thank you.

If you want to check offset, please refer to Orin TRM document.

Thanks for the response. Yes I understand the offsets for the PCIe iATU registers. My issue is that 141a0000 just fails outright. I just tested with 14160000 and it works. Also, I have enabled C5 as an endpoint. the C4 addresses work just fine (eg: 14160000 and 36000000).

The issue is I need to check PCIe link values while the C5 is in endpoint mode.

@WayneWWW Can you please see my response and updated question. My question is not related to finding the correct addresses, it is about access to those registers. Thank you.

What is the purpose to access and check this in UEFI shell but not after entering the kernel?

We have always checked the link/pcie registers pre-boot. Historically, we have used u-boot so running form the UEFI shell is a bit new for me. What tool would you suggest to read the processor’s registers from ubuntu?

I would suggest check this after kernel is up with devmem… Honestly, we seldom check things in bootloader shell.

Thanks. I just tried and it shows all FFs for both 141a0000 and 14160000. Wouldn’t this not work anyway since I thought devmem wasn’t accessing the processors registers, just the system memory?
I found a tool called system-register-tools. It’s supposed to be similar to msr-tools but for ARM. I need to compile some stuff first before I try. Any other ideas?
The thing that seems the weirdest to me is that it’s only the C5 that doesn’t work when in endpoint mode. I don’t understand why that would occur.

Could you describe the whole steps you did to enable C5 as EP?

Sure thing. I followed the steps here: Jetson AGX Orin Platform Adaptation and Bring-Up — Jetson Linux<br/>Developer Guide 34.1 documentation
1.) Use SDKManager GUI to update to JetPack 5.0.2.
2.) Modify file p3701.conf.common. nvhs-uphy-config-0 to nvhs-uphy-config-1
3.) Use flash.sh to update the Orin.
4.) Connect a PCIe tx/rx swap cable with power line unconnected but with grounds connected. I did not add the recommended buffer circuitry.
5.) Follow the steps to set up the endpoint in linux
6.) Connect other end of swap cable to another Orin and boot that RP Orin.
7.) Followed steps to verify the root port could detect and write to the endpoint.
*I had trouble on the endpoint here. Using devmem as root to read the BAR of the endpoint failed with a permissions error. This was a bit weird to me, but I verified the data was written by rebooting the root port Orin and reading the mapped BAR of the endpoint again and the values were those that were written on the previous boot.

I have tried with the tx/rx swap cable connected and connected as well as with the RP Orin powered and unpowered, but the behavior of un-accessible registers behaves the same.


If the issue is “devmem hit permission problem”, then please add CONFIG_STRICT_DEVMEM=n to tegra_defconfig and rebuild kernel.

By default, this was not allowed due to some security setting. So need to disable it.

Yes I know how to fix the perms error, but that is not the main problem here. I only mentioned it in an effort to be very clear as part of your request for exact steps to set up the endpoint.

My main issue is that I am unable to read 0x141a0000 and check the link config registers. I only get the permission issues with devmem when trying to access the BAR address listed in the endpoint step “dmesg | grep pci_epf_nv_test”. I am unconcerned with this, however, so please ignore that issue.

Is it possible for someone to recreate my issue and confirm that it isn’t just me?


Actually, just couples of customers already validated the Orin Endpoint setup and it was working.

Could you share your current boot up log + dmesg here to check?

Sorry if there was a miscommunication. Yes, the endpoint functionality works correctly. The only issue is that I cannot read the registers while in endpoint mode. Reading from a running kernel with devmem shows all FFs and reading from UEFI shell causes reset. The addresses I am attempting to read are 0x141a0000 and 0x3a000000.

I was hoping that someone could try to access those registers on their devices to replicate my issue.

Thanks for you help


Are you trying to access the 0x141a0000 on EP or RP?

In the kernel, 0x141a0000’s value can read back when your EP is active, or the controller will enter power gating.

I am trying to read 0x141a0000 and 0x3a000000 on the EP. Doing so in the EUFI shell causes a reset and doing so in the kernel just reads 0xFFs. The problem is that I can not get any information from the registers at all while in EP mode. Either I am misunderstanding the TRM or something is not working correctly. Do you have an Orin that you can recreate my issue with?

From my understanding, I should be able to read the control registers from the UEFI shell both when in EP and RP mode. But reading in EP mode doesn’t work.



So is the kernel side problem resolving or not?
PCIe C5 EP is not initialized in UEFI, so it is normal not allowed to access it’s registers.

Thanks for the reply. That was the key. I had to set up the endpoint before running devmem. Thank you for all your hard work and patience with me.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.