Hello,
I’m new to doing pinmux configurations.
My goal: use an Orin NX 16GB SOM on a Seeed studio Xavier NX carrier board. After looking at numerous posts online, my current approach is:
- Use Nvidia’s Migration Guide document for Orin NX and Xavier NX to identify which pins are not compatible (these seem to be all pins in Table 12: Connector Pin Function Differences)
- Make edits in the Orin pinmux Excel spreadsheet.
- Follow these steps for
.dtsi and .cfg files.
- Build kernel and flash.
I am stuck on step 2, the pinmux sheet.
For the I/O that are the same between Xavier and Orin, I imagine nothing needs to be changed in the sheet. For the I/O that differ, am I to change the ‘customer usage’ entry of all those pins to the ‘unused’ option in the pinmux dropdown? For example:
How do I know what to change the other columns to?
Lastly, there are 4 possible sheets : +DP or +HDMI, and for each, A01 or A03. Which do I use?
Thanks!
1 Like
Check your BSP directory. There is a p3509+p3767 board config.
Use that to flash your board.
We only provide pinmux cfg file for XNX devkit. We don’t know about custom carrier board.
You should contact vendor to check if they already have a update pinmux for Orin NX too.
I see, thank you we will use that.
Assuming we are using Orin NX SOM with the Xavier NX dev kit, is my approach correct for “turning off” the pins that differ between Orin and Xavier?
Actually you don’t need to do that… we already provided a pinmux file that is ready for Xavier NX devkit. You don’t need to start from the pinmux spreadsheet again.
1 Like
Thank you! I will do this for the Orin SoM on Xavier NX dev kit.
Now for 3rd party carrier boards - One vendor that produces a Xavier NX carrier board does not have a pinmux yet for the Orin SoM. I need to make my own via the spreadsheet. Is the approach I listed above generally correct?
Do I configure a pin to be “unused” when it’s available on Orin SoM but not Xavier SoM?
Hi,
Actually you should let the board vendor provide. They have the board schematic but you don’t have it. Your method to modify pinmux will never be precise.
Even if you try to do what you want to do now, the board may still have problem.
1 Like
To clarify, what do I do with that p3509+p3767 board config file?
To reference the .conf file when flashing to NVME, I am running:
$ sudo ./tools/kernel_flash/l4t_initrd_flash.sh --external-device nvme0n1p1 -c tools/kernel_flash/flash_l4t_external.xml -p "-c bootloader/t186ref/cfg/flash_t234_qspi.xml" --showlogs --network usb0 p3509-a02+p3767-0000 external
My p3509-a02+p3767-0000.conf file seems to point to the right PINMUX_CONFIG, PMC_CONFIG, and DTB_FILE variables.
Prior to flashing, I have installed the flashing prerequisites successfully:
sudo ./tools/l4t_flash_prerequisites.sh
sudo ./apply_binaries.sh
At the very end, on host device, I get this output:
**Step 3: Start the flashing process**
Waiting for target to boot-up...
Waiting for target to boot-up...
Waiting for target to boot-up...
...
...
Waiting for target to boot-up...
Waiting for target to boot-up...
Timeout
Cleaning up...
I am attaching my serial debug UART log output too. Any ideas what may be going wrong?
uart_logs.txt (28.6 KB)
Default BSP cannot flash custom board.
I can help you bypass current error. But you may still hit next problem again and again.
Just let me highlight the point again. Go to get the customized BSP from the board vendor. Do not try this by yourself.
Sorry - to clarify, this error is when flashing Orin on the Xavier NX devkit board. Not a custom board. For this project I am proceeding with the XNX devkit only.
Could you list out how many boards you have on your side?
I don’t think your xavier NX devkit is in normal state.
Do you have xavier nx module can boot up and dump me some info? It will be better using jp4 to dump the info I need.
Sure, tomorrow when I have access again to the Xavier SoM,
I’ll post the logs that result from booting-up Xavier SoM on Xavier carrier.
Could you flip back your xavier nx devkit and take some photos of it too?
Here are the photos:
I would be quite surprised if physical damage to the devkit is the issue (unless plugging in the Orin SoM did some damage), as I’ve been using this devkit unit with Xavier SoM for ~6 months without issue.
Also, here is the latest flash error I get (host side) with the Orin plugged in:
[ 5.6712 ] tegrahost_v2 --chip 0x23 0 --align mem_rcm_aligned.bct
[ 5.6727 ] tegrahost_v2 --chip 0x23 0 --magicid MEM0 --ratchet_blob ratchet_blob.bin --appendsigheader mem_rcm_aligned.bct zerosbk
[ 5.6735 ] adding BCH for mem_rcm_aligned.bct
[ 5.6843 ] tegrasign_v3.py --key None --list mem_rcm_aligned_sigheader.bct_list.xml --pubkeyhash pub_key.key --sha sha512
[ 5.6845 ] Assuming zero filled SBK key
[ 5.6862 ] Warning: pub_key.key is not found
[ 5.6790 ] tegrahost_v2 --chip 0x23 0 --updatesigheader mem_rcm_aligned_sigheader.bct.encrypt mem_rcm_aligned_sigheader.bct.hash zerosbk
[ 5.6805 ] Copying signatures
[ 5.6813 ] tegrahost_v2 --chip 0x23 0 --partitionlayout flash.xml.bin --updatesig images_list_signed.xml
[ 5.6829 ] tegraparser_v2 --generategpt --pt flash.xml.bin
[ 5.6837 ] End sector for APP, expected at: 943718337, actual: 0
Error: Return value 4
Command tegraparser_v2 --generategpt --pt flash.xml.bin
Error: /home/shaantam/nvidia/nvidia_sdk/JetPack_5.1.1_Linux_JETSON_XAVIER_NX_TARGETS/Linux_for_Tegra/bootloader/signed/flash.idx is not found
Error: failed to relocate images to /home/shaantam/nvidia/nvidia_sdk/JetPack_5.1.1_Linux_JETSON_XAVIER_NX_TARGETS/Linux_for_Tegra/tools/kernel_flash/images
Cleaning up...
Does this devkit have any “NVIDIA” name on it? In the back or the front side. Label or stickers… something like that.
Let me go straight about this.
I don’t think your board is devkit. No matter who sold this to you. I guess he/she might tell you “this is devkit”.
But according to the log and the photos, it seems not a devkit.
The log says it cannot find the eeprom on the carrier board. But a NV devkit must have this. This is a very common situation on custom board.
That was why I said you cannot run sdkm on custom board.
We will double check the manufacture and supplier who sold to us. Thank you Wayne. To my knowledge we were told this was an Nvidia devkit but clearly it’s not
A more precise way is to use rel-32 + xavier nx module to boot up. The log will tell if this is p3509 board.
or I can share the command to directly dump eeprom after boot into kernel.
