I have a custom board with Jetson NX 16GB and I want to split pcie c7 and c9.
In jetpack 35, I managed to do it by changing tegra234-p3768-0000-a0-pcie.dtsi. However, in jetpack 36.3 this file doesn’t exist anymore.
I found a file called tegra234-p3768-0000+p3767-xxxx-nv-common.dtsi, but changing it didn’t work.
What changes do I need to apply in jetpack 36.3 in order to get the c7 and c9 split?
The change is still similar.
Make sure which dts your board is using first and then doing the similar modification as you did in rel-35.
I guess most likely it is just the dtb you modified is not what your board is using.
If I’m building with p3509-a02-p3767-0000, which file do I change?
Like I said, I tried changing tegra234-p3768-0000+p3767-xxxx-nv-common.dtsi. I even saw the changes being applied (for example, I changed “num-lanes” and saw that it was indeed changed when I read the device tree on my machine).
But C7 and C9 still don’t work. I get “Phy link never came up” everytime.
I have a wifi module connected to the pcie and it works when I use jetpack 35, but not when I use jetpack 36.
Did you remember to modify the pinmux and odmdata?
If C7 and C9 controller are already appeared in the dmesg, then it means the controller is already enabled. If you cannot tell it, you could share the dmesg here so that I can help you tell.
This is my ODMDATA:
“gbe-uphy-config-9,hsstp-lane-map-3,hsio-uphy-config-0”
what do I need to change in the pinmux?
Here is the dmesg:
dmesg.txt (34.8 KB)
I saw the C7 and C9 are already enabled. You could use /proc/device-tree to make sure if everything is as your expectation.
Actually pinmux change happened on rel-35 too, but only did that for Orin AGX C0/C7.
You could refer to above Example change: PCIe x1 (C0) and PCIe x8 (C7) in Root Port mode
Make sure similar changes are made for C7 and C9 rst and clkreq pins. (be aware that above link is just for Orin AGX C0/C7).
My pinmux file already works when using jetpack 35. Doesn’t that mean that it already has the necessary changes?
Also, I noticed that if I don’t add “num-lanes” for C7 and C9, then the final values don’t match those of the device tree in the working version. In the working version num-lanes of C7 is 8 and for C9 it’s 2. Can you confirm that?
You can just set the num-lanes to 1 for both C7 and C9. That should work even in your working version.
Did you mean your whole rel-36 pinmux is copied from your rel-35 BSP?
Yes. It is.
How many PCIe cards that can be tested on your board? I mean how many kinds?
Also, are we talking about only PCIe C9 cannot work or both of them cannot work?
Have you tried to flash default BSP and test if C7 is working? Orin Nano devkit by default already enabled C7 and we guarantee that software is correct.
If your C7 is not even able to work on your board in that situation, then we need to configure checking the debug tips mentioned here.
The debug logic here is if any PCIe card can get detected on the controller while some other devices cannot, then no need to dig into the configuration in the controller. Need to check above debug tips.
C7 is connected to wifi module. C9 is currently not connected to anything.
When using jetpack 35, C7 works.
When using jetpack 36.3, C7 doesn’t work.
I don’t know if C9 works or not because I don’t have anything connected to it.
We have more PCIe connections that do work in 36.3. For example, our nvme is connected to C1.
Are you sure num-lanes can be 1?
Yes, and theoretically it should be 1 as there is actually only one lane in use.
That things actually do not matter much. The correctness of “phys” is more important to that.
Any other ideas?
I am not sure what is your purpose to ask any other ideas while you didn’t reply all my questions yet…
Have you tried to flash default BSP and test if C7 is working? Orin Nano devkit by default already enabled C7 and we guarantee that software is correct.
If your C7 is not even able to work on your board in that situation, then we need to configure checking the debug tips mentioned here.
Also, if C9 is not connected anything, then why enable it?
Hi,
What do you mean by “default BSP”? I already told you that I have a version that works that’s from jetpack 35. That means that C7 is working.
As for enabling C9 - The board containing the jetson was developed by a third-party. The pinmux file and the working software was provided by them. It’s according to their instructions that we create the C7 and C9 split. Do you want me to completely erase C9 from the devtree?
If this board is from specific vendor but not from you, please directly report this issue to them and let them come to contact me.
Default image means the image directly from sdkmanager which runs for NV devkit. We guarantee the software for it is correct for C7.
Ideally it shall work for their board too.
Hi,
I will contact the vendor.
In addition, I have extracted the device tree of both the working version and the 36.3 version. There are some differences but I’m not sure if they are relevant. I would appreciate it if you could take a look:
extracted_dts_r36.txt (326.1 KB)
extracted_dts_original.txt (425.5 KB)
The “original” is the device tree of the Linux I received from the vendor. The wifi works there.
The “r36” is the device tree of a Linux I created myself using yocto + meta-tegra, and with the pinmux that the vendor provided. The wifi doesn’t work.
Just another clarification. I already posted the debug tips in previous comment.
I don’t know if you read it or not. There is one point mentioned there and it is common for a WIFI card situation.
Wifi card has wl-disable pin on the design and sometimes the Jetson GPIO state will affect it. For example, we have seen lots of wifi card cannot get detected because such pin affected it.
And such pin state may not show in the kernel device tree. It is related to pinmux/ gpio state.
It is actually pointless to keep comparing your rel-36 device tree with vendor’s rel-35.
Actually, if your vendor didn’t upgrade their BSP version, you should push them for it.
NVIDIA side does not know much about their board design as we don’t have their board schematic.
As I already told, our default device tree from sdkmanger already supported C7 and it would work. Which means the software on it is correct.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.