Our custom carrier board has encountered a problem with hardware resource occupation, resulting in a USB3.0 through chip being reused as both a USB3.0 port and a flashing port. We configured this USB in the device tree to be in host mode, but this would cause the nv-l4t-bootloader-config.service to start very slowly after entering the system. If it is set to OTG mode, the nv-l4t-bootloader-config.service works normally, but it would prevent the reused USB3.0 from being used. Is there any solution to this?
*** Please note that this reply is generated by LLM automatically ***
The issue you’re facing is due to the reuse of a USB3.0 port as both a USB3.0 port and a flashing port on your custom carrier board. This has resulted in a conflict between the host mode and OTG (On-The-Go) mode configurations in the device tree.
When you configure the USB in host mode, the nvl4tbootloaderconfigservice starts slowly after entering the system. This is likely because the host mode configuration is not compatible with the reused USB3.0 port’s flashing functionality.
On the other hand, when you configure the USB in OTG mode, the nvl4tbootloaderconfigservice works normally, but this prevents the reused USB3.0 port from being used as a USB3.0 port.
To resolve this issue, you can try the following solutions:
- Use a separate USB port for flashing: If possible, consider using a separate USB port for flashing purposes, rather than reusing the USB3.0 port. This would eliminate the conflict between host mode and OTG mode configurations.
- Configure the USB port as a dual-role port: You can try configuring the USB port as a dual-role port, which would allow it to function as both a host and a device. This might require modifying the device tree and kernel configurations.
- Use a USB hub or switch: If the above solutions are not feasible, you can consider using a USB hub or switch to multiplex the USB signals. This would allow you to use the reused USB3.0 port as a USB3.0 port while still maintaining the flashing functionality.
- Modify the device tree and kernel configurations: You can try modifying the device tree and kernel configurations to accommodate the reused USB3.0 port’s flashing functionality. This might involve adding custom device tree nodes or modifying the kernel’s USB driver configurations.
In comparison, the Jetson AGX Orin’s USB structure, as described in the provided context, consists of nine pins, including VBUS, GND, D+, D-, and two differential signal pairs for SuperSpeed data transfer. The D+/D- signal pins connect to UTMI pads, while the SSTX/SSRX signal pins connect to UPHY and are handled by one UPHY lane. UPHY lanes are shared between PCIE, UFS, and XUSB, which might be relevant to your custom carrier board’s design.
In terms of device tree configurations, the provided context mentions that the USB2.0 signal pair is wired to UTMI pad 0 (USB2 port 0), while the USB3.2 signal pairs are wired to UPHY lane 1 (USB3.2 port 1 according to UPHY lane mapping). You may need to modify these configurations to accommodate your custom carrier board’s design.
In summary, resolving the issue will likely require a combination of hardware and software modifications, including device tree and kernel configuration changes.
*** Please give the thumbs up if you get answers you like. Or provide feedback to help us improve the answer. ***
What is the error log from nv-l4t-bootloader-config.service ? How do you know it is nv-l4t-bootloader-config.service started slowly?
Are you sure it is not “nv-l4t-usb-device-mode.service” that is slow?
Hi @WayneWWW ，
thanks for your reply.
First of all, the service did not fail to start; it just started more slowly.
Secondly, the slow startup time was determined by comparing it with the self-defined boot board that had been configured by the official.
Under normal circumstances, when the system reaches the login interface, the status of this service is SUCCESS. However, after using my device tree, the status of this service will only change to SUCCESS 40 seconds after it starts at the login interface.
Hi @WayneWWW
Just now, in response to your question, I took a look at the nv-l4t-usb-device-mode.serivce,It was discovered that the startup failed. The details are as follows.
rk@rk-desktop:~$ sudo systemctl status nv-l4t-usb-device-mode
● nv-l4t-usb-device-mode.service - Configure USB flashing port for device mode
Loaded: loaded (/etc/systemd/system/nv-l4t-usb-device-mode.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Mon 2025-09-15 17:56:22 CST; 24s ago
Process: 667 ExecStart=/opt/nvidia/l4t-usb-device-mode/nv-l4t-usb-device-mode-start.sh (code=exited, status=1/FAILURE)
Process: 1977 ExecStopPost=/opt/nvidia/l4t-usb-device-mode/nv-l4t-usb-device-mode-stop.sh (code=exited, status=0/SUCCESS)
Main PID: 667 (code=exited, status=1/FAILURE)
9月 15 17:56:21 rk-desktop nv-l4t-usb-device-mode-stop.sh[2001]: rmdir: failed to remove ‘l4t/functions/mass_storage.0/’: No such file or directory
9月 15 17:56:21 rk-desktop nv-l4t-usb-device-mode-stop.sh[2004]: rmdir: failed to remove ‘l4t/functions/acm.GS0/’: No such file or directory
9月 15 17:56:21 rk-desktop nv-l4t-usb-device-mode-stop.sh[2007]: rmdir: failed to remove ‘l4t/functions/rndis.usb0/’: No such file or directory
9月 15 17:56:21 rk-desktop nv-l4t-usb-device-mode-stop.sh[2013]: rmdir: failed to remove ‘l4t/configs/c.1/’: No such file or directory
9月 15 17:56:21 rk-desktop nv-l4t-usb-device-mode-stop.sh[2017]: rmdir: failed to remove ‘l4t/strings/0x409’: No such file or directory
9月 15 17:56:21 rk-desktop nv-l4t-usb-device-mode-stop.sh[2018]: rmdir: failed to remove ‘l4t’: No such file or directory
9月 15 17:56:21 rk-desktop nv-l4t-usb-device-mode-stop.sh[2022]: l4tbr0: ERROR while getting interface flags: No such device
9月 15 17:56:21 rk-desktop nv-l4t-usb-device-mode-stop.sh[2037]: bridge l4tbr0 doesn’t exist; can’t delete it
9月 15 17:56:22 rk-desktop systemd[1]: nv-l4t-usb-device-mode.service: Failed with result ‘exit-code’.
9月 15 17:56:22 rk-desktop systemd[1]: Failed to start Configure USB flashing port for device mode.
After the service failed, the nv-l4t-bootloader-config.service was then started.
Then could you disable that service and see if it has anything to do with the delay you saw?
I mean, there is nothing related to USB on nv-l4t-bootloader-config.service.
Hi @WayneWWW
After disabling the USB service, the nv-l4t-bootloader-config.service still started very slowly.
Hi @WayneWWW
I checked the nv-l4t-usb-device-mode.service file and found that it actually started when the system booted. However, when its status changed from active to failed, the nv-l4t-bootloader.service started. I’m not sure if there is any connection between these two.
The status after the system starts up:
Information during failure:
If I use this official USB configuration, the nv-l4t-usb-device-mode.service information will be as follows:
The relevant parts of my device tree are as follows：
/ {
i2c@c240000 {
/delete-node/ ucsi_ccg@8;
};
…
ports {
usb2-0 {
status = “okay”;
mode = “host”;
/delete-node/ port;
};
…
xudc@3550000 {
status = “disabled”;
};
};
Just to clarify. Your screenshot shows not much helpful information to me.
Could you show me just how exactly “slow” you observe when the issue happened? I don’t get this info from your screenshot.
Also, could you do more experiment here first to check if this issue is due to
- Disable the USB device mode in device tree
or - Just customize anything in the device tree would lead to this issue?
Hi @WayneWWW
I define “slow” as the period from when the login interface appears until the service starts, which lasts for 40 seconds.
The reason for the slow performance was that I used the device tree content mentioned in the reply. By disabling this part, everything worked fine. That is, once you log in to the interface, you can already see that the service has started.
I mean do you have some comparison like the log from journalctl with and without modifying the device tree with timestamp information there so that it could clearly show “it really has a delay in service start time”.
What you just told to us really does not matter much. I mean I totally believe what you told.
But you need to at least provide text log out there to show that. We depend on text log to check things but not only symptom description.
or running something like
systemd-analyze blame
systemd-analyze critical-chain nv-l4t-bootloader-config.service
The following two logs represent two different modes: host (slow) and otg (normal)
host_mode.txt (76.6 KB)
otg_mode.txt (77.6 KB)
I don’t know if you really get the point or not.
I need journalctl log but not dmesg. Dmesg does not include any of the service information…
And we need the result with comparison… If you want to dump systemd-analyze critical-chain for the nv-l4t-bootloader-config.service. then you need the one with error and the one without. I shall see two results but not just one.
It looks like nvgetty starts slowly but we may need your “normal boot” case to know .
Hi @WayneWWW
Sorry, I didn’t understand your meaning before. Here is the log ofjournalctl
normal.txt (216.9 KB)
slow.txt (249.7 KB)
-
我這邊直接請問一下你到底能不能給出正常的跟慢的時候兩個的systemd-analyze critical-chain for the nv-l4t-bootloader-config.service結果?
-
如果usb device mode就已經沒有需要了 你能不能直接把service關掉然後重新抓一次這些log?
我在你的slow.txt裡面看到了77次的nv-l4t-bootloader-config.service結果, 但在normal.txt裡面只看到4次.
Is this still an issue to support? Any result can be shared?
通过排查得出结论：由于将设备树的USB2-0从OTG模式设置为HOST模式，导致设备不支持从设备模式，ttyGS0设备无法生成，于是dev-ttyGS0.device阻塞了1min，正是该问题导致服务启动缓慢。
主要排查过程如下：
通过上图，发现getty.target在1min 6.329s才启动，于是我排查了getty.target下的两个服务getty@tty1.service，serial-gettty@ttyGS0.service。
通过指令:sudo systemctl disable serial-getty@ttyGS0.service
sudo systemctl disable getty@tty1.service
逐个disable服务并查看启动时间变化，发现 serial-getty@ttyGS0.service导致了nv-l4t-bootloader-config.service启动缓慢。
进一步分析 serial-getty@ttyGS0.service,发现一条依赖关系：
BindsTo=dev-%i.device
我理解serial-getty@ttyGS0.service必须等待dev-ttyGS0.device检测到ttyGS0设备才开始工作。所以目前的整个服务依赖如下：
dev-ttyGS0.device
→ serial-getty@ttyGS0.service
→ getty.target
→ nvgetty.service
→ nv-l4t-bootloader-config.service
只要dev-ttyGS0.device没检测到ttyGS0存在，整条链路都会卡住。
验证：
sudo reboot
watch -n 0.5 "systemctl list-jobs"
发现dev-ttyGS0.device确实阻塞了1min，dev-ttyGS0.device结束后，我们关注的服务都会立刻执行。
结论：由于/dev/ttyGS0设备缺失，导致dev-ttyGS0.device一直处于等待设备状态，阻塞1min后，该单元退出，依赖该单元的其他服务依次执行。
解决方法：由于我们并没有用到设备/dev/ttyGS0，所以disable serial-getty@ttyGS0.service，之后正常。
然后我在另一块载板2上验证该问题，发现设备如果没有OTG模式，ttyGS0就不会生成，但是并没有导致nv-l4t-bootloader-config.service启动缓慢。
两块载板的区别就是：载板2没有将USB2-0复用成刷机口和USB口；有问题载板是通过TS3USB30E芯片将USB2-0复用为刷机口和USB口。
以上就是我的排查结果。
1 Like
Glad to know you found the root cause, thanks for your sharing to the community!