Working with Jetson Thor and Yocto build. We have developed a custom carrier card for Jetson Thor. Followed the steps to use the pin mux excel sheet and generated required device tree files. Able to build the core-image-minimal image and tried flashing the image by putting the board in recovery mode. It is observed that the flashing fails at BootRCM step where the APX device (seen on host) does not switch to “Tegra Device” for receiving the binaries for flashing. What other steps could be missing in this process.
Hi,
By default the device tree files in flashvar are for AGX Thor developer kit. If you use custom carrier board, please modify the flashvar to replace with your files.
have already modified the flashvar pointing to the device trees for custom carrier board. Also forcing to use the USB2.0 recovery mode and disabling the companion USB3.0. Would any other pins from the recovery mode connector (for e.g. VBUS_DET) play an role for make the switch from APX to Tegra Deivce?
This is a distant possibility; did you run
Linux_for_Tegra$ ./apply_binaries.sh --openrm
# You can check to see if the ./rootfs files below exist.
jp7.2/Linux_for_Tegra$ sudo find . -iname "nvidia-l4t-usb-service*"
./nv_tegra/l4t_deb_packages/nvidia-l4t-usb-service_39.2.0-20260601141651_arm64.deb
./rootfs/usr/share/doc/nvidia-l4t-usb-service
./rootfs/var/lib/dpkg/info/nvidia-l4t-usb-service.conffiles
./rootfs/var/lib/dpkg/info/nvidia-l4t-usb-service.md5sums
./rootfs/var/lib/dpkg/info/nvidia-l4t-usb-service.listrecovery mode is just pure hardware event. No matter what software you did there. It won’t affect whether the board is in recovery mode or not.
Whether you are using Yocto or L4T today won’t change the behavior in recovery mode.
You might need to elaborate the exact error you saw on your side first…
I feel you are talking about the USB device mode in initrd but not the recovery mode.
Sorry let us start all over again.
Problem: Unable to flash the binaries to the custom board using the USB recovery mode on Jetson Thor
Procedure:
- Using the yocto linux and adding custom machine to build the Linux.
- Able to add the custom layer and included the required device tree using the pinmux excel sheet provided.
- Able to build the core-image-minimal with the above set of files.
- Used the USB recovery mode to flash the binaries. The only difference on the custom board (compared with devkit) is using
USB2.0 port 0 (pin F12, and pin F13 on the connector) with USB3.0 port 0 (pin C34,C35 for Rx lane, and pin K32,K33 for Tx lane).
Modified the device tree to use this combination before building the binaries. - Connected the recovery connector to the host along with the debug connector to the host.
- Used initrd-flash as the utility to flash and used nv_tcu_demuxer as the utility to capture the debug logs into separate files.
- Execute the utility and when it fails stopped the process.
Observation:
Flash process fails as it could not find the required ADB device. The device is put into recovery mode by pressing the recovery
switch, and the lsusb command on the host sees APX device. During the RCM boot stage the USB device drops for few seconds and comes
back again as APX device (expected at this stage to be a Tegra Device). The nv_tcu_demuxer generates separate files for all the
debug ports but only BPMP, RAW, and TZ0 are populated (rest of the files are empty). Attaching the files here to understand the
failure.
Help Required:
Resolution to the above problem. Any documentation to debug this kind of failure.
BPMP.txt (33.4 KB)
RAW.txt (36.3 KB)
TZ0.txt (2.8 KB)
-
Are you sure your device tree change is ever validated on previous build like L4T or it is first time using it and directly tried it on Yocto?
-
Your flash log is still in a very early stage that device tree is still not playing any role… What is the log you saw on host side?
-
Is the “nv_tcu_demuxer” you are using here from the L4T BSP of jp7.2?
Hi,
Replying here as it is convenient and fast to do so,
-
This is my first time with Nvidia Jetson Thor and my first time using it on Yocto. Basically, chose this yocto path for two reasons; first one is it was suggested by Ilies CHERGUI (met him at Nvidia GTC 2026) and second because of the custom carrier board. But do let me know (or point me to some documentation which includes steps) to validate on L4T builds.
-
Attaching the log file here.
-
Yes, it is from L4T JP7.2
Thanks, and Regards
Nahoosh
(Attachment log.initrd-flash.2026-07-07-10.50.11 is missing)
Seems it rejected to upload the attachment in earlier email because of invalid file extension, renaming the file with txt extension and uploading.
(attachments)
wget https://developer.nvidia.com/downloads/embedded/L4T/r39_Release_v2.0/release/bringup_framework_R39.2.0_aarch64.tbz2
tar xf bringup_framework_R39.2.0_aarch64.tbz2
./nv_bringup.sh --print-dependency -b jetson-agx-thor-devkit #will report if any packages need to be install to run tests.
nv_bringup.sh - Use: nv_bringup.sh [--help|-h] [-m|--module "MODULE_NAME MODULE_NAME"] [-d|--print-dependency] <-b|--board> <BOARD_NAME>
This script validates common baseline functionality on a the host board
Options are:
--help|-h
show this help
--module|-m
space separated list of modules to test (i.e. \"pcie cpu gpu\")
--print-dependency|-d
list pre-req dependencies of tests
--board|-b
name of the target board to test (i.e. jetson-agx-thor-devkit)
---
Documentation:
https://docs.nvidia.com/jetson/archives/r39.2/DeveloperGuide/HR/JetsonModuleAdaptationAndBringUp/JetsonThorAdaptationBringUp.html#This issue has nothing to do with bring up framework.
Did you ever read this document before you changed something in the device tree for USB part?
As I don’t see any schematic + device tree for your custom board, I could not comment whether something is wrong or not.
Also, I still doubt if the log you shared is full log because the RAW.txt really stuck in a very early stage.
Hi Wayne,
Thanks for the reply. Please find below responses to your queries.
-
Yes, I did read the steps before modifying the device tree files (but maybe somewhere I did some mistake, not sure). The only difference between the devkit and the custom implementation is the USB3.0 port being used (but have taken care while writing the device tree). Thanks for pointing to the document / steps that way it validated my references.
-
Sorry for incomplete inputs, below is the block representation of the schematic from the CVM connector to the USB-C recovery connector. Have only depicted the signals which are of interest. The DRP controller operates in GPIO mode. Also providing the snippets of the device tree modification as per the step 1.
padctl@a808680000 {
status = “okay”;
pads {
usb2 {
lanes {
usb2-0 {
status = “okay”;
};
usb2-1 {
status = “okay”;
};
usb2-2 {
status = “okay”;
};
usb2-3 {
status = “okay”;
};
};
};
usb3 {
lanes {
usb3-0 {
status = “okay”;
};
usb3-1 {
status = “okay”;
};
usb3-2 {
status = “okay”;
};
};
};
};
ports {
/* USB-C X5 (also functions as a Jetson recovery port) /
usb2-0 {
mode = “otg”;
vbus-supply = <&vdd_5v_cvb>;
/ Delegate switching to HW (consider VBUS always on) */
usb-role-switch;
status = “okay”;
connector {
compatible = “gpio-usb-b-connector”, “usb-b-connector”;
label = “micro-USB”;
type = “micro”;
vbus-gpios = <&gpio_main TEGRA264_MAIN_GPIO(U, 1) GPIO_ACTIVE_LOW>;
id-gpios = <&gpio_main TEGRA264_MAIN_GPIO(Q, 2) GPIO_ACTIVE_HIGH>;
};
};
usb3-0 {
nvidia,usb2-companion = <0>;
status = “okay”;
};
usb2-1 {
mode = “host”;
status = “okay”;
};
usb3-1 {
nvidia,usb2-companion = <1>;
status = “okay”;
};
usb2-2 {
mode = “host”;
status = “okay”;
};
usb2-3 {
mode = “host”;
status = “okay”;
};
usb3-2 {
nvidia,usb2-companion = <3>;
status = “okay”;
};
};
};
usb@a808670000 {
phys = <&{/bus@0/padctl@a808680000/pads/usb2/lanes/usb2-0}>,
<&{/bus@0/padctl@a808680000/pads/usb3/lanes/usb3-0}>;
phy-names = “usb2-0”, “usb3-0”;
status = “okay”;
};
usb@a80aa10000 {
phys = <&{/bus@0/padctl@a808680000/pads/usb2/lanes/usb2-0}>,
<&{/bus@0/padctl@a808680000/pads/usb2/lanes/usb2-1}>,
<&{/bus@0/padctl@a808680000/pads/usb2/lanes/usb2-2}>,
<&{/bus@0/padctl@a808680000/pads/usb2/lanes/usb2-3}>,
<&{/bus@0/padctl@a808680000/pads/usb3/lanes/usb3-0}>,
<&{/bus@0/padctl@a808680000/pads/usb3/lanes/usb3-1}>,
<&{/bus@0/padctl@a808680000/pads/usb3/lanes/usb3-2}>;
phy-names = “usb2-0”, “usb2-1”, “usb2-2”, “usb2-3”, “usb3-0”, “usb3-1”, “usb3-2”;
status = “okay”;
};
-
I stopped the initrd-flash utility once it gave an error, apologize for that. Attaching the complete log till the initrd-flash completes its execution. I did ran lsusb and dmesg -w commands in separate shell the outputs for the same are as below
Every 0.5s: lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 004: ID 1604:10c0 Tascam Dell Integrated Hub
Bus 001 Device 003: ID 1604:10c0 Tascam Dell Integrated Hub
Bus 001 Device 002: ID 1604:10c0 Tascam Dell Integrated Hub
Bus 001 Device 090: ID 0955:7026 NVIDIA Corp. APX
Bus 001 Device 086: ID 0403:6015 Future Technology Devices International, Ltd Bridge(I2C/SPI/UART/FIFO)
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hubsudo dmesg -w
[615961.710317] usb 1-10: new full-speed USB device number 86 using xhci_hcd
[615961.843012] usb 1-10: New USB device found, idVendor=0403, idProduct=6015, bcdDevice=10.00
[615961.843028] usb 1-10: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[615961.843035] usb 1-10: Product: UMFT230XB
[615961.843040] usb 1-10: Manufacturer: FTDI
[615961.843045] usb 1-10: SerialNumber: FT74XWII
[615961.848191] ftdi_sio 1-10:1.0: FTDI USB Serial Device converter detected
[615961.848285] usb 1-10: Detected FT-X
[615961.849359] usb 1-10: FTDI USB Serial Device converter now attached to ttyUSB0
[615988.165007] usb 1-12: new high-speed USB device number 87 using xhci_hcd
[615988.292472] usb 1-12: New USB device found, idVendor=0955, idProduct=7026, bcdDevice= 4.01
[615988.292487] usb 1-12: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[615988.292494] usb 1-12: Product: APX [this appears when recovery mode is initiated]
[615988.292499] usb 1-12: Manufacturer: NVIDIA Corp.
[615988.292504] usb 1-12: SerialNumber: 0018EF91000000C0942ED38714621008
[616010.604870] usb 1-12: USB disconnect, device number 87
[616010.855875] usb 1-12: new high-speed USB device number 88 using xhci_hcd
[616010.983347] usb 1-12: New USB device found, idVendor=0955, idProduct=7026, bcdDevice= 4.01
[616010.983362] usb 1-12: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[616010.983369] usb 1-12: Product: APX [this appears when initrd-flash starts execution]
[616010.983374] usb 1-12: Manufacturer: NVIDIA Corp.
[616010.983379] usb 1-12: SerialNumber: 0018EF91000000C0942ED38714621008
[616063.962347] usb 1-12: USB disconnect, device number 88
[616064.213266] usb 1-12: new high-speed USB device number 89 using xhci_hcd
[616064.340776] usb 1-12: New USB device found, idVendor=0955, idProduct=7026, bcdDevice= 4.01
[616064.340791] usb 1-12: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[616064.340798] usb 1-12: Product: APX [this appears when RCM boot starts]
[616064.340803] usb 1-12: Manufacturer: NVIDIA Corp.
[616064.340808] usb 1-12: SerialNumber: 0018EF91000000C0942ED38714621008
[616070.661839] usb 1-12: USB disconnect, device number 89
[616071.829894] usb 1-12: new high-speed USB device number 90 using xhci_hcd
[616071.957362] usb 1-12: New USB device found, idVendor=0955, idProduct=7026, bcdDevice= 4.01
[616071.957377] usb 1-12: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[616071.957384] usb 1-12: Product: APX [this appears after few seconds when the log says Flashing-Images starting]
[616071.957389] usb 1-12: Manufacturer: NVIDIA Corp.
[616071.957394] usb 1-12: SerialNumber: 0018EF91000000C0942ED38714621008
[616502.135736] usb 1-12: USB disconnect, device number 90
Attaching the log file (complete log file this time), and the UART logs (which are similar to what I shared earlier). Please let me know if you need anything else or would like me to try and get back the observations to you.
Thanks, and Regards
Nahoosh
(attachments)
log.initrd-flash.2026-07-08-14.34.27.txt (261 KB)
BPMP.txt (33.4 KB)
RAW.txt (36.3 KB)
TZ0.txt (2.79 KB)
Is it possible to move to use L4T instead of using Yocto first to isolate the issue? Just for debug purpose.
Yocto is actually just supported since jp7.2 and only validated on NV devkit. I feel the need we need to isolate whether issue comes from custom board or Yocto itself.
For example, if even L4T would hit same issue, then custom board issue it might be.
Add some more explanation.
The current “adb device missing” error is actually not the true error you hit.
It is just “host expects a USB device to be here within a limited timeout”. However, the reason why that USB device does not appear could have lots of reasons.
The log you shared indicates that the device actually fails to boot up. It is stuck in bootloader where device tree of your kernel plays no role. Which means checking your USB device tree does not help. You may need to review the hardware. It is not a software problem.
I think flashing L4T would give you the same error too.