Flashing Jetpack 6.1 to Orin NX 16G on custom board stucks at "Waiting for target to boot-up..."

[cuong.pham]

Hello,

We’re making a custom board for Jetson Orin NX 16G based on the Holybro Jetson Baseboard. Currently we’re facing a problem with flashing Jetpack 6.1. The flash script got stuck at “Waiting for target to boot-up…” then timed out.

We’ve already done the EEPROM modification suggested here Jetson Orin NX and Nano Series — NVIDIA Jetson Linux Developer Guide 1 documentation

This is the flash command that we use

sudo ./tools/kernel_flash/l4t_initrd_flash.sh --flash-only --external-device nvme0n1p1 -c tools/kernel_flash/flash_l4t_t234_nvme.xml -p “-c bootloader/generic/cfg/flash_t234_qspi.xml” --showlogs --network usb0 p3768-0000-p3767-0000-a0 internal

These are Jetson serial console log and flash output log:

jetson_serial_1-3.3_0_20260601-103253.log (82.1 KB)

flash_1-3.3_0_20260601-103253.log (9.7 KB)

Please take a look and let us know what should we do to overcome this. Thank you very much.

Regards,

Pham

[KevinFFF]

Hi cuong.pham,

@cuong.pham

The flash script got stuck at “Waiting for target to boot-up…” then timed out.

This issue normally is caused from the boot issue of your device.

I’m not sure if the issue may be caused from the following errors.

E> Error in command_complete 18001 int_status
E> OCR failed, error = 39390706
E> STORAGE: Failed to open SDMMC: 3.
W> Ignoring init failure for device 0-3
I> Secondary storage device: SDMMC_USER instance: 3
E> Error in command_complete 18001 int_status
E> OCR failed, error = 39390706
E> STORAGE: Failed to open SDMMC: 3.
W> Ignoring init failure for device 1-3

Is the issue happening on specific board or all custom carrier board?
Have you tried switching another USB cable or host to clarify?

[nagesh_accord]

@cuong.pham

sudo ./tools/kernel_flash/l4t_initrd_flash.sh --flash-only --external-device nvme1p1 -c tools/kernel_flash_l4t_l4t_nvme.xml --p “-c bootloader/generic/cfg/flash_t234_qspi.xml” --showlogs --network

change nvme1p1 to nvme0n1p1 and try flashing.

Many times this is hardware related issue also…

[cuong.pham]

Thank you Nagesh. I think the flash script I mentioned is already nvme0n1p1

sudo ./tools/kernel_flash/l4t_initrd_flash.sh --flash-only --external-device nvme0n1p1 -c tools/kernel_flash/flash_l4t_t234_nvme.xml -p “-c bootloader/generic/cfg/flash_t234_qspi.xml” --showlogs --network usb0 p3768-0000-p3767-0000-a0 internal

I think it’s hardware related as well…

[nagesh_accord]

@cuong.pham

I think it’s hardware related as well…

Even we came across similar errors in some occasions and they turned out to be hardware issue.

Some scenarios which I remember…

1. The NVMe, if its behind a PCIe switch and if it has signal integrity/etc issues, then PCIe reset wont happen properly and we may get this timeout error…

2. The same NVMe if connected on a direct PCIe lane on custom carrier board, from the SOM module it might work

3. NVMe from a different OEM can also be tried some times to check if at makes any difference…

[cuong.pham]

Thank you Kevin,

This issue normally is caused from the boot issue of your device.

I’m not sure if the issue may be caused from the following errors.

It looks like a warning related to SD card slot. Does it affect the boot process?

Is the issue happening on specific board or all custom carrier board?
Have you tried switching another USB cable or host to clarify?

We have 2 other custom boards (Holybro Pixhawk Jetson Baseboard and reComputer industrial J4012), both flashed successfully.

I’ve also tried to switch host and USB cable, but still the same problem occured.

I think I need to discuss with my hardware team. Could you suggest some things that I can ask?

Thanks

[cuong.pham]

Wow, that’s a lot of useful information!

Maybe it’s NVME related. I’m gonna tell my hardware team about the things you just mentioned this information and hopefully they’ll have some ideas. Thanks, Nagesh

[KevinFFF]

@cuong.pham

Maybe it’s NVME related

It’s worth trying another NVMe SSD.

Waiting for target to boot-up...
Waiting for target to boot-up...
Waiting for target to boot-up...
Timeout
Device failed to boot to the initrd flash kernel. Please retrive the serial log during flashing to debug further.
Cleaning up...

Regarding the flashing timeout mentioned above, the issue is typically caused by the board itself.

[KevinFFF]

[ 7.983877] tegra-xudc 3550000.usb: EP 0 (type: ctrl, dir: out) enabled^M

We have noticed that your usb device mode got detected failed as this line only comes once.
Could you check the custom board design and also the usb device tree is correct?

[cuong.pham]

Hello Kevin,

Thanks for the suggestion. Modifying DTB makes it work.
This is our modification, though I’m not really sure all these changes are necessary.

diff --git a/tegra234-p3768-0000+p3767-0000-nv.dts b/custom_board.dts
index 49e8033..3300911 100644
--- a/tegra234-p3768-0000+p3767-0000-nv.dts
+++ b/custom_board.dts
@@ -3924,17 +3924,9 @@
 
                                usb2-0 {
                                        status = "okay";
-                                       mode = "otg";
-                                       vbus-supply = <0xf7>;
+                                       mode = "peripheral";
                                        usb-role-switch;
-
-                                       port {
-
-                                               endpoint {
-                                                       remote-endpoint = <0xf8>;
-                                                       phandle = <0x106>;
-                                               };
-                                       };
+                                       role-switch-default-mode = "peripheral";
                                };

We tried to change only mode = “otg” to mode = “peripheral” and flash was still successful, however we couldn’t get /dev/ttyACM* for the initial system setup.

Also our board use micro-USB port to flash instead of USB type-C. Does it affect the DTB?

Thanks

[WayneWWW]

The logic here is we give you a hardcoded method to let USB mode always to be in device mode when doing flash.

However, when kernel is up, your device tree needs to match your carrier board. This leads to 2 possible reasons that your USB device mode not work.

1. Your board design could be wrong.
2. Your device tree setting could be wrong.

For example, a fully functioning micro-USB port requires a ID and VBUS-DET pin. Not sure if they are present in your board design.
If they are present, then obviously you didn’t put them into device tree.

[fabian.munoz]

Hi Pham

Regarding your concerns, the /dev/ttyACM* may not appear for a couple of reasons, but I would recommend if the micro-USB port is only used as a device/flashing port, keep mode = "peripheral" and remove Type-C/OTG role-switch endpoint references that may not exist on the custom board. This also should work if there is no VBUS or ID detect signals:

usb2-0 {
status = “okay”;
mode = “peripheral”;
};

If the board has VBUS_DETECT, add a proper usb-b-connector node with vbus-gpio(replacing X and Y with the appropiate GPIO of the VBUS_DETECT signal).

usb2-0 {
status = “okay”;
mode = “peripheral”;

connector {
    compatible = "gpio-usb-b-connector", "usb-b-connector";
    label = "micro-USB";
    type = "micro";
    vbus-gpios = <&tegra_main_gpio TEGRA234_MAIN_GPIO(X, Y) GPIO_ACTIVE_HIGH>;
};

};

After boot, verify that nv-l4t-usb-device-mode is running, because /dev/ttyACM* depends on the USB gadget service, not only on flashing success. Check the service status and logs with:

sudo systemctl status nv-l4t-usb-device-mode

journalctl -u nv-l4t-usb-device-mode --no-pager

I hope this helps! If you have any questions, don’t hesitate on letting me know.

Best regards,

Fabian Munoz
Embedded SW Engineer at RidgeRun

Contact us: support@ridgerun.com
Developers wiki: https://developer.ridgerun.com/
Website: www.ridgerun.com

[cuong.pham]

Hello Munoz,

Wow, thank you so much for the detailed information. That’s really helpful.

Let me try the DTB modification and see what happens.

Besides, sometimes we also have a problem at the beginning of the flashing process:

[ 0.3173 ] Sending bct_mem
[ 0.3477 ] Sending blob
[ 0.4358 ] ERROR: might be timeout in USB write.
Error: Return value 3

We’ve noticed that it depends on the timing. If we run the flash command almost immediately after Jetson boots into recovery mode, this error won’t happen. However, if we wait for a while, the error will occur and flash script will stop.

Have you encountered this issue before?

Thanks & regards,

Pham

[WayneWWW]

Full log and UART side log might help clarify.

BTW, jetpack6.1 is quite old. Better using some newer version to prevent PCN update issue too.

[cuong.pham]

Hi Wayne,

In this case I only have flash log. Jetson UART is inaccessible.

flash_1-3_0_20260529-103601.log (3.5 KB)

Please take a look. Thanks

[WayneWWW]

Your error is different from previous one.

[   0.0344 ] tegrarcm_v2 --instance 1-3 --new_session --chip 0x23 0 --uid --download bct_br br_bct_BR.bct --download mb1 mb1_t234_prod_aligned_sigheader.bin.encrypt --download psc_bl1 psc_bl1_t234_prod_aligned_sigheader.bin.encrypt --download bct_mb1 mb1_bct_MB1_sigheader.bct.encrypt
[   0.0352 ] BR_CID: 0x80012344705DF6493C000000160002C0
[   0.0448 ] Sending bct_br
[   0.0539 ] ERROR: might be timeout in USB write.
Error: Return value 3
Command tegrarcm_v2 --instance 1-3 --new_session --chip 0x23 0 --uid --download bct_br br_bct_BR.bct --download mb1 mb1_t234_prod_aligned_sigheader.bin.encrypt --download psc_bl1 psc_bl1_t234_prod_aligned_sigheader.bin.encrypt --download bct_mb1 mb1_bct_MB1_sigheader.bct.encrypt
Cleaning up...

If you hit " Sending bct_br" + “ERROR: might be timeout in USB write”, then please refer to this

Jetson AGX Orin FAQ

Q: Sometimes noise screen is shown when rebooting or shutting down the device Please apply this solution: When enabling rt build in Jetpack6.2, white noise appears on the screen during restart - #13 by wichiu Q: How to apply PCN210100 overlay patch? PCN210100 is supported from Jetpack 5.1.3. If you are using 5.1.1 or 5.1.2, there are overlay packages in: Jetson Linux 35.3.1 | NVIDIA Developer Jetson Linux 35.4.1 | NVIDIA Developer If your device is AGX Orin 64GB, please also add the patch…

But please be aware that this method is only for this " Sending bct_br" + “ERROR: might be timeout in USB write” combination.
If your error is not this kind, then you are hitting different kind of errors.

[cuong.pham]

Thanks.

I’ve disabled USB autosuspend on my host PC, but the problem still occurs.

If your error is not this kind, then you are hitting different kind of errors.

" Sending bct_br" + “ERROR: might be timeout in USB write” is a different problem that we’ve encountered, but occasionally. The problem in the original post is related to our board design, and it has been fixed.

[WayneWWW]

@cuong.pham

I’ve disabled USB autosuspend on my host PC, but the problem still occurs.

You need to put the board back into recovery mode again and also hotplug the USB cable to make it work after you disable auto suspend.

[cuong.pham]

I did but it still failed.
I guess it’s better to make another topic since I found the solution for the original problem. Thanks