On my custom carrier board, VDD_IN of the Orin NX is equal to 12V. POWER_EN’s control circuitry is completely referenced by ‘Jetson_Nano_Carrier_Board_Design_Files_B01_P3449’. Two seconds after VDD_IN is stable, the 5V voltage powers up. 500 milliseconds after the 5V power is stable, POWER_EN becomes high. SYS_RESET* is used as enable for carrier board supplies (3.3V and 1.8v).
I have changed the pinmux configuration and updated board configuration files by referring to MB1 Configuration Change.
When the flashing process reaches the stage described below , the problem arises.
Step 2: Boot the device with flash initrd image
…
…
…
[ 0.5398 ] BL: version 0.32.0.0-t234-54845784-57325615 last_boot_error: 0
[ 0.5617 ] Sending bct_mem
[ 0.5811 ] Sending blob
[ 0.7483 ] ERROR: might be timeout in USB write.
Error: Return value 3
Command tegrarcm_v2 --instance 3-2 --chip 0x23 0 --pollbl --download bct_mem mem_rcm_sigheader.bct.encrypt --download blob blob.bin
Cleaning up…
When the problem occurs, the final output of the serial console of SOM is as follows.The complete output of the serial console of SOM during the flashing process is shown in the attachment. orinnx-console.txt (19.4 KB)
At this point, the Orin NX SOM exits RCM and the host cannot discover the device through ‘lsusb’.
It seems the MB1 encountered an error while doing SOC rail configuration. But I did not modify the file of “tegra234-mb1-bct-pmic-p3767-0000-a02.dts”.
My custom carried board is a little different from Jetson Orin NX Carrier Board.
1.From GPIO00 to GPIO14, there are some usage differences. For example, GPIO04 is used as input.
2.I2C1 is connected with FXMA2102L8X.
3.UART1_TXD and UART1_RXD are connected with SN74AVC2T245RSWR.
4.UART1_RTS and UART1_CTS are connected with M.2 Key E (whose slot is empty).
On our custom carrier board, we used another Orin NX 16GB SOM that was successfully flashed with devkit. The new SOM is powered on our custom carrier board, and the fault appears at the same point.
Thank you. Ours HW team has reviewed the schematic several times with the design guide document. But because the Power Supply and Sequencing is different from the design guide, we don’t get more clues.
Now, MB1 can continue to run when flashing. But four pieces of debugging information appeared.
PMIC_CONFIG: Rail ID 7 not found in pmic rail config table.
PMIC_CONFIG: Rail ID 5 not found in pmic rail config table.
PMIC_CONFIG: Rail ID 6 not found in pmic rail config table.
PMIC_CONFIG: Rail ID 8 not found in pmic rail config table.
The new partial output of the serial console of SOM is as follows.
[0034.508] I> Task: Prod config init (0x50013ddd)
[0034.513] I> Task: Pad voltage init (0x50013a2d)
[0034.517] I> Task: Prod init (0x50013e21)
[0034.521] I> Task: Common rail init (0x50014575)
[0034.526] I> DONE: Thermal config
[0034.529] I> DONE: SOC rail config
[0034.533] D> PMIC_CONFIG: Rail ID 7 not found in pmic rail config table.
[0034.540] W> PMIC_CONFIG: Rail: MEMIO rail config not found in MB1 BCT.
[0034.546] I> DONE: MEMIO rail config
[0034.550] D> PMIC_CONFIG: Rail ID 5 not found in pmic rail config table.
[0034.557] W> PMIC_CONFIG: Rail: GPU rail info not found in MB1 BCT.
[0034.563] I> DONE: GPU rail info
[0034.567] D> PMIC_CONFIG: Rail ID 6 not found in pmic rail config table.
[0034.574] W> PMIC_CONFIG: Rail: CV rail info not found in MB1 BCT.
[0034.580] I> DONE: CV rail info
[0034.583] I> Task: Mem clock src (0x50011de9)
[0034.588] I> Task: Misc. board config (0x5001461d)
[0034.593] D> PMIC_CONFIG: Rail ID 8 not found in pmic rail config table.
[0034.600] W> PMIC_CONFIG: Platform config not found in MB1 BCT.
[0034.606] I> Task: SDRAM init (0x50011ded)
After testing, it was found that only the following configuration caused MB1 to stop at that position.
command@1 {
reg-addr = <0x28>;
mask = <0xFFFF>;
/* Format:
* PEC = CRC8()
*/
value = <0x3000>;
};
What 0x28 and 0x3000 mean?
Flashing the SOM still did not succeed, possibly because block protection of SPI flash was enabled, and clearing block protection was also unsuccessful. The new log of the serial console of SOM during the flashing process is shown in the attachment. orinnx-log0622.txt (107.2 KB)
After removing some warnings such as ‘USB over current condition’ by modifying the device tree, flashing the SOM succeeded. But there are still two obvious issues.
After Linux kernel is started, four CPUs are shut down.
[ 15.647589] using random self ethernet address
[ 15.654418] using random host ethernet address
[ 16.063656] using random self ethernet address
[ 16.068504] using random host ethernet address [ 17.747188] CPU4: shutdown [ 17.829864] CPU5: shutdown [ 17.927244] CPU6: shutdown
[ 18.018837] IRQ 117: no longer affine to CPU7 [ 18.024114] CPU7: shutdown
Ubuntu 20.04.5 LTS nvidia-desktop ttyTCU0
nvidia-desktop login: nvidia (automatic login)
MOD_SLEEP* is high normally.
Our circuit of MOD_SLEEP* almost entirely references P3509-A01 and P3768-A04 as follows. But R106 is DNI in P3509-A01 and P3768-A04.
So far, our custom carrier board has been running normally.
When MOD_SLEEP* was high normally, we again flashed the SOM. The error that occurred at the SOC rail configuration of MB1 has disappeared.
