Recovery Port not working after flashing custom board with pinmux changes

I have encountered an issue after flashing a custom jetson orin nano 4gb board with pinmux change. In the pinmux change we have turned usb3 to usb2 and disabled hdmi for example. We have downloaded the excel sheet for pinmux changed and have copied the generated dtsi files by following PINMUX Changes. We have created another board.config by copying it jetson-orin-nano-devkit.conf and replace pinmux and voltage dtsi files. We flash the board with Jetson Orin Nano Developer Kit (NVMe) with the board.conf. The flash was running successfully. After booting up again I couldn’t see the board on the host os. It wasn’t showing up in lsusb neither mounting. I had to use the UART port to login to the device. The recovery port isn’t working anymore after the updated pinmux. The usb changes on the device are correct. Have I overlooked a step? How can I figure out what is going wrong on the recovery port? Do I need to recompile dtb? The custom board is working with the default device tree but the usbs are not detected. We are running on Jetson 35.5.0 and on host ubuntu 20.04.

I can’t answer the change requirements, but I want to point out some thoughts on how it might work differently than you think it works.

When the Jetson is in recovery mode it becomes a custom USB device. There is no device tree change capable of breaking this. When a Jetson fully boots, then one port which supports device mode can have some content in “/opt/nvidia/l4t-usb-device-mode/” detect device mode and provide virtual USB device services (the virtual wired ethernet). lsusb would not distinguish between device mode caused by being in recovery mode versus becoming a virtual wired network device, but plug-n-play information published does cause the type of hardware to be distinguished differently between those two mode. For recovery mode to work nothing has to be done other than using recovery mode jumper/button (depending on model), and this cannot be prevented from working; conversely, virtual USB devices cannot function if the USB device mode itself is not available and properly set up. This latter is likely what failed.

What you really need to answer this is to post a full serial console boot log to know what USB was doing, including power rails associated with it. This can get more complicated with newer USB 3 versus older devices using only USB 2 or slower on a given connector. Every time there was a new standard with higher speed added to USB from 1.0 to 2.0 (including 1.1) a new chip was created which had all modes and was backwards compatible with older standards. USB 3 and higher changes this theme: The controller is dedicated to just that mode. If older standards are detected, then lanes must route to a legacy controller; if newer standards are detected, then lanes must route to the newer controller. It seems likely either (A) your lanes don’t have proper wiring/routing (which includes device tree), or (B) a power rail is incorrect for at least one of the modes/controllers (which is also device tree).

I can’t tell you details of the device tree so I cannot answer, but you do need a full serial console boot log so the issue can be differentiated between power rails, legacy setup, or newer controller setup.

Thanks for you answer. I will try to review full serial console boot log again but as far as I remember I couldn’t see a difference to the booting on the devboard.

What is strange to me is that if we equip the dev board with the ssd of the custom carrier board then the recovery port is working. And we can put the normal dev board ssd on the custom carrier board and then it is also working. It’s that our modifications in the DTSI don’t seem to work on our board.

A serial console boot log with and without your device tree modification on your carrier board might help. Also, you are mentioning DTSI, the “include” file from kernel builds. This is greatly dependent upon configuration. If there is any difference in kernel config between the kernel which works and the kernel which fails (even if you think it is the DTSI file difference), then this is very likely related to it. Perhaps this is a kernel issue and not a device tree issue? Or a kernel install difference?

The following is a output of the custom board after flashing it. I’m not sure why but I can’t connect to the board through usb c (192.168.55.1). Only serial connection over UART is possible.
no_usb_custom_board.txt (69.1 KB)

I think the point here is you should tell what is changed on your “custom board”

Adaptation is required if your hardware is different. As for what is needed, that depends on your chagne…

On the host PC, if you monitor “dmesg --follow”, what new log lines do you see from plugging in the fully booted Jetson’s USB? The Jetson only provides a virtual wired USB router when fully booted, and it is up to the host PC to accept or deny the new network device. The log message should provide clues whether it is the Jetson or the host which is rejecting this. I didn’t see anything notable on the log for “no_usb_custom_board.txt”.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.