Recovery port serial on custom linux install?

On the default rootfs, the recovery port acts as a serial port (and a few other things). How can I recreate this behavior on my own image which uses debian 11 instead of ubuntu? Currently, /dev/ doesn’t have ttyGS0 listed, which is what the default image uses as far as I can tell.

I’ve asked this question before for a non-systemd OS (alpine), and basically got told “don’t use a non-systemd OS”, so if this question looks like a duplicate, that’s why.

OS: Debian 11
Device: Jetson nano

I don’t have answer for this, may other developers help to share experiences.

If you are just looking to use this as a serial port, then make sure the driver for that UART chipset is present. I’m guessing it is either ACM or FTDI (the former is more likely, but I am unsure what is in the actual SoC…it is possibly also one of the NVIDIA custom drivers, but the naming convention ttyGS0 says probably not custom).

If you want this as a serial console, then that is where the systemd or other content might get complicated. I have not added a custom serial console, but I suspect that at some given runlevel (or systemd unit) there is a way to run a tty to the UART.

I do want to use it as a serial console, but I think I can figure that part out. As for the serial port, how would I figure out what driver it needs, and where would I get them? Looking through apt search ftdi and apt search acm doesn’t seem to find anything too useful.

(Just to make sure, this is about the recovery usb port, not the actual uart header, right?)

Edit: ignore this reply, /dev/ttyGS0 shows up on both debian and ubuntu, it’s just not getting recognized when I plug it into my host pc (or it’s own usb port)

Actually, I think I might be having two different issues (?). When using the default image, I have ttyGS0 (on the device), but when I plug it into my computer, /dev/serial (on my host) still doesn’t exist. It’s worked in the past with the default image (/dev/serial showed up) but that may have been on the devkit (with the sdcard) and these are the production units, so that might affect it.

Let’s back up a bit and make sure I am looking at the right situation. Because ttyGS0 exists on the Jetson it means there is a UART with a driver on the Jetson binding the device to the driver. This UART would technically be just a single UART, and the host side would need its own UART for it to have a tty of some sorts. If we are talking about the micro-B USB connector, then this does provide a UART to the outside world as well (but it is probably a ttyACM naming). If you are using a USB cable from the micro-OTG socket of the Jetson to the host PC, then even if there is no driver, then you would see a log at plug-in. If you run the command “dmesg --follow”, and monitor this as you plug in the USB cable, what do you see?

Note that a different device tree is used with eMMC models, and that USB could be routed incorrectly if the wrong device tree is used (and the carrier board changing also modifies the device tree, not just the module type). Third party carrier boards which differ from the dev kit carrier board would come with a different device tree, and that tree would also depend on the type of module used on the carrier board.

dmesg --follow gives me nothing when i plug in or unplug the usb cable (I am talking about the micro-otg socket), and there is no ttyACM*. I’m using a different carrier board (third-party) but I haven’t messed with device-tree at all since I’ve got no clue what it is.

The gist of device tree is that there are various pins on the Jetson (and most every computer) which can be optionally set up to different functions, and makes designing the circuit board much easier. However, the software looking to become a driver of hardware needs to know how to find that optional setup, and this is what the device tree does: It is a blueprint of how the lanes are routed, and arguments drivers need to talk on those lanes (e.g., a certain physical address talks to the hardware, or uses a particular speed setting). This is firmware, and although it is not part of the kernel, such firmware often ships with the kernel because the firmware in need of setup depends on which drivers are being compiled. The device tree for the developer board is configured at the same time a kernel build is configured, but it is limited to the developer board. Other boards require modification unless their lane routing is an exact match to the developer board.

The customization of device tree for what functions pins have typically is performed in the PINMUX spreadsheet (if you enable macros it allows altering various pin assignments and will generate a new device tree for that routing). See:
https://developer.nvidia.com/embedded/downloads#?search=PINMUX

When you build a kernel and use the default configuration of “make tegra_defconfig”, then you get the default configuration a Jetson ships with (well, Orin has a far different shipping versus default config, but it is a developer preview, and we are not talking about Orin). Build target “make dtbs”, if first configured with “make tegra_defconfig”, should make the same device tree as what a Jetson ships with, and should also match the default from the PINMUX spreadsheet. You would start there, and then develop changes for your carrier board (or if you purchase the carrier board from a third party, then they would provide the device tree).

Different operating systems might use a device tree differently, but if they use the Linux kernel, then there is a chance that the same drivers would use the same tree. You would have to find out if the alternate operating system handles device trees and firmware in the same way. If not, then you’d probably need to build the tree from scratch with knowledge of how it differs.

A device tree is installed in one of two places. If the security fuses are burned, then this content can only come from a signed partition, and other locations will be rejected. If security fuses are not burned, then you can also name the device tree via the “FDT” key/value pair in “/boot/extlinux/extlinux.conf”, and the content will be read instead from the file named there. Quite useful since it doesn’t require signing or flashing tools during development. A simple file copy works there, and one can keep the original boot entry and add a second boot entry (for selection via serial console during boot) to test with (if you destroy your only boot entry, then basically you need to flash again; an SD card model could have that content reverted from a second computer though).

If a device is present on a port which is in device mode (host mode accepts devices like a keyboard, while device mode provides a device such as a keyboard to other computers), then the other computer (running Linux in this case) should see something log related to detecting a device. A Jetson in recovery mode is always a custom device regardless of what is flashed on it, so this should never fail to show up on the other computer. Failure to show up as a device on the other computer means one of:

  • There is hardware failure.
    • That failure can be the USB cable, e.g., it isn’t a type-B at the Jetson end, or
    • That failure is that the Jetson is not in recovery mode, or
    • The Jetson itself has a hardware failure. This could technically be from an incorrect carrier board not properly routing the micro-B USB port, but this is unlikely in most cases (this assumes carrier boards known to be of a design with a valid micro-OTG port). This situation would have to be tested on a developer kit carrier board or other known working carrier board to guarantee if it is a carrier board issue version a Jetson module hardware failure.
  • The host port itself might be failed.

If the port you are using is not truly a micro-OTG port (which accepts type-A or type-B cables, but has an ID pin so the Jetson knows which type of cable is used), or if you are not using the type-B cable, then I would expect no log would occur. However, since this is so rare, do you have another carrier board you can test on? Recovery mode should work regardless of which carrier board it is, and regardless of what is currently flashed on it. If not, then you likely have hardware failure (but again, it is possibly the carrier board failing and not the Jetson module).

1 Like

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