We have TX1 in our lab someone has changed the password on. unfortunately I have no way of knowing who changed it nor what it was changed to. This of course means I can’t flash the latest software etc.

I did a bit research and it appears that the easiest thing to do is to Clone the boot drive onto MTV host PC, Loop mount the imag, edit the password file and flash the image back onto the TX1.

I began following the instructions here
But unfortunately the script terminates prematurely as below

As this is the first thing I’ve tried to do with the TX1 and I haven’t seriously used Linux for 20 years, I’d much appreciate some help to get this thing going.

Many thanks


peter@peter-VirtualBox:~/Tegra_dev/64_TX1/Linux_for_Tegra_64_tx1/bootloader$ sudo ./ --bl cboot.bin --applet nvtboot_recovery.bin --chip 0x21 --cmd “read APP my_backup_image_APP.img”
Welcome to Tegra Flash
version 1.0.0
Type ? or help for help and q or quit to exit
Use ! to execute system commands

[ 0.0081 ] Generating RCM messages
[ 0.0149 ] tegrarcm --listrcm rcm_list.xml --chip 0x21 --download rcm nvtboot_recovery.bin 0 0
[ 0.0165 ] RCM 0 is saved as rcm_0.rcm
[ 0.0257 ] RCM 1 is saved as rcm_1.rcm
[ 0.0292 ] List of rcm files are saved in rcm_list.xml
[ 0.0307 ]
[ 0.0307 ] Signing RCM messages
[ 0.0323 ] tegrasign --key None --list rcm_list.xml --pubkeyhash pub_key.key
[ 0.0440 ] Assuming zero filled SBK key
[ 0.0686 ]
[ 0.0687 ] Copying signature to RCM mesages
[ 0.0703 ] tegrarcm --chip 0x21 --updatesig rcm_list_signed.xml
[ 0.0891 ]
[ 0.0892 ] Boot Rom communication
[ 0.0908 ] tegrarcm --chip 0x21 --rcm rcm_list_signed.xml
[ 0.0965 ] BR_CID: 0x321010015c6600022000000017fe8540
[ 0.1213 ] RCM version 0X210001
[ 0.1254 ] Boot Rom communication completed
[ 1.1686 ]
[ 1.1688 ] Retrieving storage infomation
[ 1.1738 ] tegrarcm --oem platformdetails storage storage_info.bin
[ 1.1814 ] Applet version 00.01.0000
[ 1.2819 ] Saved platform info in storage_info.bin
[ 1.4255 ]
[ 1.4256 ] Reading BCT from device for further operations
[ 1.4257 ] Sending bootloader and pre-requisite binaries
[ 1.4273 ] tegrarcm --download ebt cboot.bin 0 0
[ 1.4312 ] Applet version 00.01.0000
[ 1.5402 ] File cboot.bin open failed
[ 1.5404 ] File cboot.bin open failed
[ 1.5448 ]
Error: Return value 19
Command tegrarcm --download ebt cboot.bin 0 0

It looks like you are using a VM…this causes a very high failure rate for the USB communications. I don’t know the particular method of configuring your VM, but you might try forcing the USB port to USB2 mode, and to also increase buffer size to the USB port.

A general comment on passwords: The default password is standardized, and if the Jetson goes on any network where the device is visible to the outside world you can bet anyone malicious will do something you don’t want.

Cloning should work as a way to edit the password and re-install the “otherwise unchanged” system. If you look at the sample rootfs you’ll find the versions of password-related files the system has by default. The “passwd” and “shadow” files could be copied over (I’m not sure but perhaps “passwd-” and “shadow-” are needed too…I’ve never tested), then re-flash with the “-r” option to restore the updated clone to the Jetson. Once restored, if you do not intend to give everyone on the network access, I’d change the password for users “nvidia” and “ubuntu”.

Thanks for the comments, I’ve finally found time to come back to this and have managed to fix this problem, so I’ll detail it here in case anyone else runs into the same thing. I setup a real Ubuntu system rather than a VM and the problem was exactly same, it has nothing to do with the uSB speed setting.

I had to delve into what the script was actually doing. I believe the error occurs when it tries to load the cboot.bin file on to the TX1, the file it is looking for is on the host. A bit of poking around revealed that there is a cboot.bin file in the t210ref sub-directory. I copied this into the bootloader directory, reran the script and it all worked.

Normally that file should be automatically copied from the t210ref subdirectory into the bootloader directory…possibly with NULL bytes padded onto the end to make it a specific size. If this did not occur automatically it is curious…perhaps a case of file permissions? I don’t know, but it would be nice to know why it didn’t occur.

Thanks a lot, you saved my day. Had the same problem and was able to solve it, based on your information, by means of a symlink.

(And I am not using a VM.)

Had the same problem, it looks like the “” script is what does the copying of cboot.bin into the bootloader folder. So if you download and install jetpack, but don’t flash the board, those files don’t get copied. Hence the issue.

On another note, if you symbolic link cboot.bin and try to run it will complain that cboot.bin is already there and fail.

I would rather look into “connect in recovery mode to Host PC with usb recovery cable” then mount disk device and chroot to it. I haven’t tried yet, but I am just wondering why obstacles could prevent from resetting password that way.

Are you talking about loopback mounting a clone on the host and doing the chroot there? It might work if things like SElinux don’t get in the way.

To mount a raw [clone] image seems rather straightforward.

losetup --partscan --find --show disk.img
mount /dev/loop0p1 /mnt

as well as unmount

losetup -d /dev/loop0

example from source
another example.

No what I thought about was to mount and chroot to Jetson disk via USB cable connection between Jetson and Host. In that case host can see the Jetson as file storage, as far as I remember. That gives a hope that chroot operation can be done, somehow.

Just tried, unfortunately host PC only can see somewhat 16Mb storage when Jetson connected.
By experiment, it doesn’t appear to see the entire disc over USB.

The “On the Go” (OTG) connector accepts a type-A cable (when acting as a host…keyboards/mice and so on work) or a type-B cable (when acting as a device instead of a host).

This latter device mode (which is what recovery mode does) is custom programmed on every device, it isn’t defined. Many device choose to act as bulk storage, but the Jetsons do not. I’m very surprised you had any success at all trying to mount any component of the recovery mode Jetson. You can extract the partition through the driver package program (Jetsons are a custom device in recovery mode…not a standard mass storage device), so were you trying to clone parts in recovery mode and then mount?

Or was this while the Jetson was running (not in recovery mode)? I’ve done this, but I had to do custom “gadget” framework setup.

I think once I have had the storage of Jetson seen at Host PC while Jetson connected with type-B cable. As for the recent experiment I approached both “running” and “recovery mode” states of Jetson device.

The times when I used mass storage I had specifically set it up as such, and the Jetson was running normally. Recovery mode is where I’ve never seen any ability to access the eMMC without the flash software itself.

Found some reference regarding the gadget:
I am just wondering if to apply it will enable the mass storage mode for USA type-A connection.

Type-A ports can never provide devices…this is wired only for a host looking for other devices. The OTG port is special in that it can detect which type A or B is connected. However, there is also an ID pin, and if that pin is not programmed to switch mode when a different cable type is plugged in, then you would have to manually make that switch each time you change the cable. Device mode by itself won’t help either unless you’ve done one of these device mode setups.

It seems Type-B cable should be used approaching getting mass storage function of Jetson accessible at Host PC.

Yes, the micro-B (which is what comes with the Jetson for flashing) is the correct cable. There are other things though needed on top of this most of the time (at least for a Jetson…something like a smart phone is usually set up/customized to appear as a mass storage device).