USB not detected in recovery mode

tomk148 · November 8, 2020, 8:01pm

I have a bunch of jetson TK1s that I’d like to flash and use, but I’m not able to get access to recovery mode. They all behave the same.

My monitors never detect a signal.

I’ve got a null modem attached and can see it cycle trying to boot from pxe (previous owners) and drop into local mode, but it doesn’t appear to be a full OS.

Tegra124 (Jetson TK1) # version

U-Boot 2014.10-rc2-g3127911 (Jun 07 2016 - 21:00:01)
arm-cortex_a9-linux-gnueabi-gcc (crosstool-NG hg_unknown@20110628.165246) 4.5.3
GNU ld (crosstool-NG hg_unknown@20110628.165246) 2.20.1.20100303

It seems like there is a ubuntu OS installed, I can poke around in ls, but not quite sure how to make it boot out of this barebones env otherwise.

Tegra124 (Jetson TK1) # ls mmc 0:1
<DIR>       4096 .
<DIR>       4096 ..
<DIR>      16384 lost+found
<DIR>       4096 boot
<DIR>       4096 bin
<DIR>       4096 dev
<DIR>      12288 etc
<DIR>       4096 home
<DIR>       4096 lib
<DIR>       4096 media
<DIR>       4096 mnt
<DIR>       4096 opt
<DIR>       4096 proc
              62 README.txt
<DIR>       4096 root
<DIR>       4096 run
<DIR>      12288 sbin
<DIR>       4096 srv
<DIR>       4096 sys
<DIR>       4096 tmp
<DIR>       4096 usr
<DIR>       4096 var

Whenever I use the physical keys or use 'enterrcm` to go into recovery mode, I no longer get feedback from the null modem cable nor do I ever see the 0955:7410 usb device show up in my ubuntu 20.04 host.

It’s possible that they are all defunct boards, but I have a mess of them and I would have expected that at some of them were still functional.

Is it expected that the data on null modem cable will go blank when in recovery?
Is it possible that there is some sort of “touch key to continue” button not displaying because my HDMI is not showing anything?
Are there any methods of getting around recovery mode being unavailable? Perhaps in this barebones OS?

Here is the help menu from the OS for helping me identify what it is? (what’s it called?)

Tegra124 (Jetson TK1) # ?
?       - alias for 'help'
base    - print or set address offset
bdinfo  - print Board Info structure
boot    - boot default, i.e., run 'bootcmd'
bootd   - boot default, i.e., run 'bootcmd'
bootelf - Boot from an ELF image in memory
bootm   - boot application image from memory
bootp   - boot image via network using BOOTP/TFTP protocol
bootvx  - Boot vxWorks from an ELF image
bootz   - boot Linux zImage image from memory
cmp     - memory compare
coninfo - print console devices and information
cp      - memory copy
crc32   - checksum calculation
dfu     - Device Firmware Upgrade
dhcp    - boot image via network using DHCP/TFTP protocol
dm      - Driver model low level access
echo    - echo args to console
editenv - edit environment variable
enterrcm- reset Tegra and enter USB Recovery Mode
env     - environment handling commands
exit    - exit script
ext2load- load binary file from a Ext2 filesystem
ext2ls  - list files in a directory (default /)
ext4load- load binary file from a Ext4 filesystem
ext4ls  - list files in a directory (default /)
ext4size- determine a file's size
false   - do nothing, unsuccessfully
fatinfo - print information about filesystem
fatload - load binary file from a dos filesystem
fatls   - list files in a directory (default /)
fatsize - determine a file's size
fdt     - flattened device tree utility commands
go      - start application at address 'addr'
gpio    - query and control gpio pins
help    - print command description/usage
i2c     - I2C sub-system
imxtract- extract a part of a multi-image
itest   - return true/false on integer compare
load    - load binary file from a filesystem
loadb   - load binary file over serial line (kermit mode)
loads   - load S-Record file over serial line
loadx   - load binary file over serial line (xmodem mode)
loady   - load binary file over serial line (ymodem mode)
loop    - infinite loop on address range
ls      - list files in a directory (default /)
md      - memory display
mii     - MII utility commands
mm      - memory modify (auto-incrementing address)
mmc     - MMC sub system
mmcinfo - display MMC info
mw      - memory write (fill)
nm      - memory modify (constant address)
part    - disk partition related commands
pci     - list and access PCI Configuration Space
ping    - send ICMP ECHO_REQUEST to network host
printenv- print environment variables
pxe     - commands to get and boot from pxe files
reset   - Perform RESET of the CPU
run     - run commands in an environment variable
saveenv - save environment variables to persistent storage
setenv  - set environment variables
sf      - SPI flash sub-system
showvar - print local hushshell variables
size    - determine a file's size
sleep   - delay execution for some time
source  - run script from memory
sspi    - SPI utility command
sysboot - command to get and boot from syslinux files
test    - minimal test like /bin/sh
tftpboot- boot image via network using TFTP protocol
true    - do nothing, successfully
ums     - Use the UMS [User Mass Storage]
usb     - USB sub-system
usbboot - boot from USB device
version - print monitor, compiler and linker version

MtHiker · November 9, 2020, 1:22am

You have TK1 devkits, don’t you?
To start at the force recovery mode, you should hold down RECOVERY button on your board.
During the recovery mode, no display on the display.
(refer Jeston_TK1_User_Guide.pdf)

Make sure you connect between micro-B usb on the TK1 devkit to the Linux host firstly.

tomk148 · November 9, 2020, 1:33am

Yes, I have TK1 devkits.

I have tried starting recovery mode as you’ve stated. It just never shows up in the lsusb list.

Good to know that I shouldn’t expect display during recovery mode! ty!

linuxdev · November 9, 2020, 6:30pm

An additional note on recovery mode: You hold the recovery button down while either turning on power or while resetting power…it is used like the “shift” key, but instead of getting a capital letter you get recovery mode. The recovery button does not need to be held down once you tap the power on key or the reset key.

There is a micro-B USB cable provided with a TK1 dev kit, and this will work well, but if you are using a charger cable, then I’d say maybe 3 out of 4 only work momentarily for data. You should still see output from “lsusb -d 0955:7140” whenever in recovery mode, and the ability to reach recovery mode should be 100% independent of anything flashed.

The output you are seeing looks like you are in the U-Boot command line, you never fully booted. Assuming you have whatever is needed for boot to succeed (you mention it was set up for PXE boot, so requirements are probably not met), then the command “boot” would continue on.

The monitor itself must be HDMI, and if you use a VGA adapter, this is guaranteed to fail. Even so, embedded systems don’t have a BIOS like a desktop system, so there is no early stage you can use a monitor with. Once in Linux itself there are a lot of simple configuration conditions which can cause video to not show up, and so you can never say the system did not boot just because video fails. Serial console itself is the way to go for this, and it looks like you do have output, although just to the bootloader. In the case of booting past this stage you will have far less output if someone has used the “quiet” argument to the kernel command line.

I would suggest double checking if recovery mode can or cannot be reached, and if your USB cable is a charger cable and not the supplied cable, then this is suspect.

tomk148 · November 10, 2020, 2:13am

Interesting. Sounds like cable is the most likely suspect given the information you two have shared.

I’ve followed similar instructions with the physical buttons and haven’t seen the results we expect.

Since my boards didn’t come with the full kit, I have been using random cables that I had in my possession. I tried a few, but maybe they are all bad for the task.

I found a relatively cheap full kit online and have ordered it. Hopefully it will allow me to make good use of these boards I have. I’ll let you all know what I find when it arrives.

Many thanks for the help that you’ve both offered so far!

tomk148 · November 13, 2020, 3:24am

Kit’s cable has done the trick with a couple of them (haven’t tried all the others yet, but cautiously optimistic). TY!

Curious what the difference in the cables is? Is it special or different? Or just higher quality?

linuxdev · November 13, 2020, 5:48pm

When you use a charger cable for charging there is no need for the data lines at all. The companies selling charger cables compete only on price for the most part. Typically you can expect (a) no shielding, and (b) the data lines will have at most about 4 tiny strands of copper, or less. A good cable has a reasonable amount of copper in the data lines, and probably also shielding. Thus charger cables are sold in large quantity where saving even the tiniest fraction of cost is done regardless of whether it affects data.

Phones don’t usually care because they can slow down and copy a picture (assuming the phone has a camera) or other content at reduced speeds, and even at the full speed they have bursts of working well (long term transfer implies noise from the real world has more chance to interfere). Statistically, if you lose a packet (not really a packet, but I’ll call it that) once in a given amount of time, then a transfer taking half a second is more likely to succeed versus a transfer which takes 15 minutes. Unlike a network TCP protocol the USB line tends to not “correct” issues.