Headless Setup, booting from serial console

Autonomous Machines Jetson & Embedded Systems Jetson Nano
1

I’ve downloaded and flashed nv-jetson-nano-sd-card-image-r32.3.1.zip to an SD card and then tried to boot my Jetson Nano from this image with a cable connected to TX, RX and GND on the 6 pin header (J44) and the 40 pin header (J41). I’ve also tried using the microUSB port (J28). That would be ttyS0, ttyTHS1, and ttyGS0. On ttyS0 I can see the boot up console output. On the others I sometimes see nothing and sometimes get a log in prompt.

At the end of the console boot up output I see the following message:

Please complete system configuration setup on the serial port provided by Jetson's USB device mode connection. e.g. /dev/ttyACMx where x can 0, 1, 2 etc.

How exactly am I supposed to complete the system configuration when I can’t log in?

Also, sometimes I get this message again and again when I connected, and sometimes I don’t:

cu: Got hangup signal

Disconnected.

This hangup signal occurs on all 3 of the tty serial ports.

Here is an example:

administratoraccount@Terjes-New-MacBook-Pro-750m ~ % sudo cu -s 115200 -l /dev/cu.usbmodem14225190414253
Connected.
cu: Got hangup signal

Disconnected.
administratoraccount@Terjes-New-MacBook-Pro-750m ~ %

I have a jumper on J48, and am using the J25 Power Jack for power.

2

I haven’t used “cu” for this, but try instead gtkterm (“sudo apt-get install gtkterm”…assuming the host PC sees this as “/dev/ttyS0”):

gtkterm -b 8 -t 1 -s 115200 -p /dev/ttyS0

Note that only a Jetson would see a name of the format “/dev/ttyTHS1”. I am assuming you have the serial program running on a host PC, and only a Jetson has a driver which would report a “ttyTH1” syntax (“Tegra High Speed” driver…useful only on Tegra hardware). The “/dev/ttyS0” is uniformly available on most any Linux system, and is the standard name format (except if udev decides to rename it for some reason, but the rename would never result in a “ttyTHS” format).

3

Jeeze, how is using dtkterm going to make any difference? You expect me to install that crap on my MacBook? Why? cu is a perfectly fine serial port program that’s already there without installing anything.

Also, there is no /dev/ttyS0, /dev/ttyTHS1, or /dev/ttyGS0 on my MacBook. Those are the ports on the Jetson Nano which I am connecting to. There’s nothing coming out of any of those ports that resembles a setup program.

The port on my MacBook (as you can see on my cu command) is /dev/cu.usbmodem14225190414253 when I try to use a USB cable to log in. And it’s /dev/cu.usbserial-1410 on my MacBook when I use a serial to USB adapter. Since there is no /dev/ttyS0 on my MacBook, there’s no way your gtkterm command could ever work, so why would you even suggest such a thing to try? That makes absolutely no sense.

The problem has nothing to do with which serial program I use to communicate with the serial port. gtkterm, cu, Minicom, whatever. It makes absolutely no difference. There is nothing that resembles a setup menu or anything. When I connect to /dev/ttyS0 on boot up I can see all the boot up console output. On the other serial ports there is absolutely nothing. If I boot off the same SD card a few times, eventually I’ll start to see a login prompt on those ports. So I know the serial ports are working and my cu command is working and my serial to USB adapter and my USB cable are all working. What’s not working is the Jetson boot up program that’s supposed to display a configuration menu on those ports so I can configure this thing.

Also, if I boot from an SD card that I’ve already set up using a USB keyboard and mouse together with an HDMI monitor I can log in through any one of those serial ports. There’s nothing wrong with any of those ports or cu. Trying an other serial program is a waste of time because it won’t work. What would work is telling me why this thing is not displaying the setup menu. Why do I have to use an HDMI monitor and USB keyboard and mouse? Why do I need monitor at all or any of the programs or drivers involved in using a monitor and running a GUI? I’m not using this thing as a desktop and have no desire whatsoever to. I just want it to boot up and connect to my network so I can SSH into it or connect to it through a TCP/IP socket to access the server.

2 Likes
4

I’m simply unfamiliar with cu since I do not have a Mac. If you’ve flashed before, then you’d have Linux, and so my hope was you could try that from the Linux PC (even a Mac running Linux would work for the alternate command). The reasoning is that I don’t know if it is the cu command or the serial part of the Jetson which is not working correctly, and knowing if this fails or works from a known command on Linux would answer that question. Do you have a Linux system available to try from? It sounds like the answer is “no”, but I need to ask since it simplifies debugging.

The presence of “ttyTHS1” on any non-Tegra device confused me since this implies the “Tegra High Speed” driver is running, and only Tegra hardware should be capable of running this. Those port names would never be used on the host PC unless that side was also a Jetson. Serial device naming and numbering differs across systems, including just due to order of seeing the serial connections, so I was hoping to verify which device was really the serial console. As long as you are looking at the serial name on the Mac it is ok, but I didn’t understand from the wording if you had the Mac’s device name.

Some serial console programs will have different defaults. Depending on the flow control settings (such as CTS/RTS flow control), this could cause a perfectly function system to fail to display any traffic. This is another reason I mentioned gtkterm…not because your other program cannot work, but because I know the given command for this does not default to flow control on.

I have no ability to answer why the flash setup was designed as is, but I can tell you it was designed to detect a monitor during the flash and set up for use of a monitor. Lacking a monitor during a flash tries to set up for headless operation. The pre-built SD card image assumes a monitor and keyboard. Regardless of whether or not there is a monitor, for security reasons, newer releases stopped adding default names and passwords; thus it is expected to add this information on first boot. There is a script here for people flashing, and this script adds the name/pass to the content before flash (requires a Linux system running Ubuntu to flash, but then you have no need for first boot login setup…the flash itself contains the information):
https://devtalk.nvidia.com/default/topic/1054926/jetson-nano/jetson-nano-all-usb-ports-suddenly-stopped-working/post/5356153/#5356153

So far as I know there is no pre-built image for the SD card for headless operation. The flash software itself has a Linux binary executable, so there is no way to actively flash (which that script uses) without the Ubuntu system to perform the flash. Some people use VMs, but VMs have their own issues.

Someone else may know more about creating SD card images without the flash software, but I suspect a Linux system could perhaps mount the SD card image in such a way that the account creation script would work on that without using flash software (there is no reason the script couldn’t edit logins on the SD card image instead of the content flash software operates on to create a flash image).

5

Using brew, you probably could, however cu is available on nearly all platforms, so you can do cu --help (or man cu) and figure out what options are appropriate for 115200n8.

You can also do a “man cu” scroll, down to the bottom for examples, and instead find:

However, it’s probably good enough, i agree, provided you can figure out the options you are supposed to use for that particular program.

Indeed. Device paths will differ from platform to platform, however the rest of the command should work if you install the suggested terminal emulator (or another).

I may be mistaken, but if you don’t do the setup on the first boot, I am not sure it will show up on subsequent boots. The idea is to flash and configure all in one go. I agree there could be failsafes in case the first boot fails, but it’s not the way the first boot scripts are designed. I would suggest trying the /dev/usbmodem… path with whatever terminal emulator you choose, getting something displaying on boot, then once it’s working, reflash and try first boot setup again. It’s what went wrong in the linked thread.

My recollection, and I may be mistaken, is that usb to serial adapters and the interface provided over micro-USB do not have the same settings. Please see the linked documentation above, and try again until you get a display on boot. Once you know it works, you can reflash and try the first boot setup via serial.

Well. There are other boards out there that do not use a GUI, but most that I am aware of still require an attended setup. Raspberry Pis come with a default user and default password, but ssh is disabled for security reasons because of this, so you still have to do the initial setup and raspi-config with a monitor and keyboard.

Before first boot there are no users, so ssh couldn’t work, and if it did, it probably wouldn’t be very secure. Perhaps some day Nvidia (or somebody) will make provisioning software that’ll do an unattended setup, setup users and install authorized keys, but that doesn’t currently exist, unless you roll something yourself. Nvidia does provide scripts to create a default user as mentioned by linuxdev.

6

Indeed, the first time I ran the first boot setup via serial, this is what I was doing wrong.

7

I agree. I’ve refreshed the SD card several times to make sure I was testing the first boot.

I already have a configured SD card (using a monitor, keyboard, and mouse) that I’ve used to test all the different serial ports on the Jetson Nano. So, unless the configuration of the serial ports change once the system is setup, I should have the proper settings already.

This is a valid point.

I’ll have to look into CTS/RTS, because I’m only using RX/TX. Unfortunately my USB to serial adapter doesn’t have pins for CTS/RTS, so I can’t try it. I believe it might possible to jumper RTS and CTS together to bypass hardware flow control. I’m looking into that now.

https://www.tldp.org/HOWTO/Serial-HOWTO-19.html

Does anyone know if the Jetson Nano defaults to hardware flow control on the initial setup boot?

8

Could someone tell me if the Jetson Nano boot image contained in nv-jetson-nano-sd-card-image-r32.3.1.zip is even meant to be configured from the serial ports? Am I wasting my time trying to get this to work? Or should I keep trying?

9

@oseberg
I have had success setting up the Jetson using a Macintosh. Here’s a short article and video of the basic steps (though on an Ubuntu host):

This method uses a data capable USB micro B to USB A cable. Connect the Jetson via the Micro USB B, and the USB A to the Mac. You will need to power the Jetson via the barrel jack. Don’t forget the J48 jumper.

I used the ‘screen’ utility on the Mac as a serial terminal interface. Depending on what the address is, your command would be something like:

$ screen /dev/tty.usbmodem148303 115200

where 148303 should be replaced with the actual number that you determine looking at /dev/tty.usbmodem*

The setup process needs to all happen in one go. If you happen to hit a carriage return or ‘ESC’ to ‘get things started’ on the terminal the Jetson believes that the initial setup has begun, and things tend to go poorly after that.

10

I can confirm it does work as I have tested the release specifically. You’re not wasting your time. Kangalow’s tutorial is a good one, and I’m surprised I didn’t link to it already.

11

@Kangalow, Thanks for the link. I actually found that already, but there’s no mention there of nv-jetson-nano-sd-card-image-r32.3.1.zip

From that article I followed this link: https://bit.ly/2ZmXJS1 and started reading and thought, “Dang, that’s a whole ton of work. It’d be way easier to just use nv-jetson-nano-sd-card-image-r32.3.1.zip than to compile and build my own install on my MacBook.”

Do I really need to follow those instructions or can I get this to work using nv-jetson-nano-sd-card-image-r32.3.1.zip?

@mdegans, When you say you’ve tested the release specifically, are you referring to, “nv-jetson-nano-sd-card-image-r32.3.1.zip”? Or do you mean you used JetPack 4.2.1 following the instructions found here: https://bit.ly/2ZmXJS1 ?

12

I am saying that I have sucessfully performed a first boot setup over the serial interface provided by micro-usb with the latest release (32.3.1). You shouldn’t need to change the image at all. Flash, insert the card, connect the cable, start the terminal emulator (screen /dev/whatever 115200), finally, apply power to the nano. Please see Kangalow’s article and video for full details. Sorry if I wasn’t clear enough earlier.

13

@mdegans, Thanks so much. That worked like a charm.

But one change. The device “/dev/whatever” doesn’t exist until after the Nano boots up, so you can’t connect to it until then.

I had the USB cable plugged in before powering up the Nano.

I had cu connected to J44 (the 6 pin header) to see the console output during boot up. The last message displayed on the serial console output is:

The command I used to connect to the USB serial port is:

I had to press before anything showed up.

14

Thank Kangalow. Glad you have it working!

Yeah, if the number isn’t predictable i’m not sure what to do about that. I know on linux it’s always the same tty# after plugged in, so you can connect to it immediatly, but I am not sure how Mac OS assigns it. If it’s repeatable, you can have the command ready and hit enter to run it as soon as you power up the device. You have at least a few seconds before it reaches the first boot scripts. Even if you miss it, I think you can just hit some keys to refresh the screen. Others might have better suggestions. Kangalow has tested your configuration.

Yup. As noted above, you can only run the first boot scripts from the serial interface provided over micro-usb. You might be able to change this if you read and modify nvidia’s boot scripts. Most of them and the units to run them can be found in /etc/systemd on the rootfs partition (familiary with systemd and bash would be required for this).

Yup. That should work for you over the micro-usb even if you miss it, but I would try the arrow keys first, just in case a cancellation option is selected and you can’t see it.

15

You can only run the first boot scripts from the serial interface provided over micro-usb

This is such a hidden piece of information.
But how does it work to have both power supply and tty connection? Did they not think about that?
I’m having a very frustrating getting started experience here.

16

I know there is the DC connector - but seriously, who has a fitting adapter for that? Where is it even documented what the polarity is, so that I can solder my cables to it?

17

@janoskut

You can just order these guys if you want to use your own power supply:

Or you can buy an AC adaptor. They’re like 10$ on Amazon. I use these ones with my Nanos. YMMV:

18

It is a bit of a pain, but the J48 jumper allows power through the barrel connector, and in theory it should be possible to use the host PC to provide power through the micro-B USB as well (rather than a dedicated 5V charger). Using data from the micro-B and still accepting power from the micro-B is basically how most USB devices work, e.g., a keyboard works with data and also receives power from the host PC.

FYI, I have adapters like what @mdegans shows, and they are very handy. I’ve been using one I got from Toradex many years ago, and it never goes out of style! I highly suggest getting something like that even if you don’t need it right now.

19

Thanks for the tips for the adapters. My expectation nowadays is just that when I receive such a developer board, that I can run the basic things out of the box. The coolness of such a product drops tremendously, if I have to wait another 2 days for the shipment of a power adapter, while there would be tons of other options, if they were just documented right.

The power rating of most USB ports are just 500mA. I did see power losses already on a 2A micro USB supply, so I’m not going down that hole.

I’m powering my board now through a lab supply through the J41 connector, which I read on some side note of some previous-revision document. However also there, when I connect the micro USB to the PC, the lab supply just turns off and the Jetson Nano is taking power exclusively through USB micro. The power paths seem connected which is really not ideal. Eventually, in case of power drops, I would backpower my PC/USB through the lab supply.

This really needs solid documentation, but I kind of suspect that the headless operation is something just not thought through by the designers. Which is really poor.

Anyways, I just went the path to connect a monitor, mouse and keyboard to get started.

20

@janoskut

I understand. The Nano can technically work in lower power mode over MicroUSB, but you cannot flash or use the headless setup this way. It’s also pretty picky about MicroUSB power supplies as you’ve noticed. I had to wait a couple days for a power adapter myself before using my Nano at full power.

Re: headless operation in general: I think the expectation is that most people will either use a script to set things up on the rootfs before first boot or do the initial setup with a monitor, after which SSH can be used exclusively. If you wish to try a script, I believe one is linked to from the FAQ.

Re: documentation, it could use improvenents in some places, but in others it’s excellent. You may wish to have a look over this:

https://docs.nvidia.com/jetson/l4t/index.html

It includes details about customizing your rootfs, kernel, etc, to your liking, however there is some asumption of arcane knowledge in places which may be confusing. If anything is unclear, it’d be of use to make note of it here on the forum so the docs can be updated. Feedback isn’t ignored. The headless setup in particular seems like it could use improvement given the frequency of threads about it.

1 Like