You should probably start a new topic in this forum. Briefly though, flash is purely over the micro-B USB cable in recovery mode. Networking is never involved until flash completes and the unit reboots. That particular IP address is for a virtual ethernet over the micro-B USB…flash and ethernet are mutually exclusive modes. You skip flashing over and over and just install packages at a later time if you uncheck/check the particular part to install or flash.
Start a new forum thread and include the flash log. Once you’ve posted, then if you hover your mouse over the quote mark in the upper right of your existing post, some other icons will show up. The paper clip icon is for attaching files.
I’m having issues using sdkmanager (0.9.12-4180) to install jetpac(4.1.1.1) for release 32.1 on a Jetson-TX2 board. After I get through all of the Host install, target flashing, and tools install on the target. (the sdkmanager finishs with no errors reported) The password for the default account (nvidia) set up during the flashing step no longer works and I can no longer ssh to the board or use sudo from the display usb keyboard connection. I resorted to repeating the install process and was very careful when I entered the account credentials. unfortunately I got the same results. It appears if I don’t do the tools install on the target I don’t have the issue. I have a couple of things to try before I give up, but was wondering if anyone has seen this issue?
Flash does erase the user accounts, and since the more recent releases, you have to add the account on first login after the flash completes (using a directly attached keyboard/monitor…otherwise there won’t be any accounts and you can’t continue). In previous releases there would be “ubuntu” and “nvidia” accounts by default, but this is no longer true.
Is this being added into Jetpack 4.2.1? I really don’t want to have to make custom HDMI and USB cables for my ConnectTech Elroy carrier boards just to set them up.
Also, you guys really should add these kinds of changes into a full-detailed change log that everybody can access (I can only find the release highlights on your page). I wasted 3 hours tonight trying to figure out why ssh wasn’t working after upgrading to 32.1.
Starting with release 32.1, NVIDIA no longer provides a default user name and password
for log-in. Follow the system prompts at first boot to create your own user credentials.
Yes, L4T 32.2 (included in JetPack 4.2.1) enables headless initial configuration for Jetson developer kits. Specifically, if no display is attached to the developer kit during first boot after flashing, the initial configuration will be “headless.” You can access the initial setup dialog from serial application on the Linux host computer (e.g., puTTY) connected to the same carrier board USB connector used for flashing.
More detail: From Jetson module perspective, the initial configuration process defaults to availability via ttyGS0. For Jetson developer kit carrier boards, that maps to the same USB connector used to flash Jetson. I don’t know if this will be the same for your ConnectTech carrier boards, but if you need the initial configuration process (also known as “oem-config”) to be accessible from a serial port other than ttyGS0, the L4T 32.2 Development Guide will have specific instructions. That document is also available at https://docs.nvidia.com/jetson/index.html.
Just upgraded to 4.2.1, and unfortunately I’m still unable to get my setup running in headless mode. My application requires all UARTs from the TX2 to connect to external UART devices. Thus, I need to disable the serial console before flashing, which then makes it impossible to run the oem-config tool in headless mode. And of course, the serial console enabling/disabling can only be configured before flashing, so I can’t change it after.
This oem-config tool is absolutely killing my project… I’ve been waiting for two months for 4.2.1 and now I’m still screwed.
I’m going to just make some cables to do a setup with a display. It’s going to take significantly longer now to configure all of the TX2’s since it can’t be done in an automated fashion.
It would be so much easier if the login username/password could be set before flashing in a config file or via the SDK manager.
I do appreciate NVIDIA’s hard work in making Jetpack/L4T better… but there was a serious lack of foresight when it came to getting rid of the default login and how that would effect the customers’ ability to get their boards setup without having a conniption.
You can install normally, and then flash a new device tree or bootloader later without flashing the rootfs.
Or the inverse, you could flash normally, set everything up, maybe even run updates and add extra packages…then clone, flash again with the modified “no serial console”, but with the modified bootloader/device tree combination, and “reuse” the rootfs…where the rootfs is the clone.
The first method is perhaps faster/easier since there is no clone time, but I’d personally prefer the second method (all of those updates would then be in place for every unit you ever want to flash again, and since the rootfs is being reused, then there wouldn’t be any flash.sh modification of the rootfs regarding GUI or console login).
Thanks for the pointer… I will try flashing just the device tree tonight.
I went ahead and made a custom HDMI cable last night, and wouldn’t you know it… the TX2 can’t detect that the display is connected even though the display is actually working. I can see the boot-time messages generated by the TX2 on the display. I get an error message at boot saying “dc_hdmi_hotplug_init: couldn’t get regulator vdd_hdmi_5v0, -517”, so I’m assuming the TX2 is not detecting the connected display somehow even though it is sending video through it.
So since the TX2 can’t detect that the display is connected, at initial boot I get stuck on “A start job is runnign for End-user configuration after initial OEM installation.” It’s waiting for configuration via serial console on /dev/ttyGS0.
I don’t know if this is just my luck or not, but it seems like every angle I try and take here is just not working.
macOS users struggeling with setting up a Xavier can find an automation of creating a guest VM for macOS using VirtualBox + Vagrant + Ansible to run the NVIDIA SDK manager including
a) automatically building a (custom) kernel and rootfs for Xaviers supporting Kubernetes
b) flashing the Xavier from the CLI
c) headless OEM setup of the Xavier after flashing