the usb hub is not working and when i saw the kernel messages the the below message was shown.
[ 33.917419] vdd-fan: disabling
[ 33.917464] vdd-usb-vbus: disabling
[ 33.917497] vdd-usb-vbus2: disabling
[ 33.917603] vddio-sdmmc3-ap: disabling
[ 33.918313] avdd-io-edp-1v05: disabling
[ 33.918345] vdd-usb-hub-en: disabling
Mostly that sounds like the device tree is incorrect. Was there any kind of update before this happened? It could still be a hardware problem, and it wouldn’t be unusual for an SD card to fail, but probably you’ll end up being advised to flash again. You did not say if this is a developer’s kit or if it is a commercial module on a third party manufacturer’s carrier board, but if it is a dev kit, then it won’t have eMMC, and you could try to flash with the same release (the SD card could be a new one, and you do need to flash the QSPI on a dev kit model with the same release as intended for the SD card content).
Incidentally, always report your L4T release (see “head -n 1 /etc/nv_tegra_release”) and exact model you have (changing between a dev kit module without eMMC and a commercial module with eMMC is a big difference, and changing to a third party carrier board is very important to know since it uses different firmware). Any update has a possibility of changing the device tree.
I’m using a developer kit. I tried changing the sdcard with a fresh installation of the os but still no hopes…
There wasn’t any update prior to the issue. It stopped working randomly and never worked even once after that.
The display works fine and the login screen appears as normal. Even the ssh connect works as intended. It’s just the usb ports and the fan.
~$ head -n 1 /etc/nv_tegra_release
the current release in my jetson nano
Reinstalling to an SD card does not actually reinstall everything, so if for example the device tree is in QSPI memory (everything except the o/s goes there on dev kits without eMMC) does not match the release you’ve installed to the SD card, then you will find the SD card fails (but it won’t really be the SD card’s fault). Was the release with the failing SD card also R32.7.5? If it was, then I’d say the next step is to leave out the SD card and flash the QSPI.
Considering so much of the system works, it is possible that the USB has had some sort of failure. You could attempt to flash the QSPI with the SD card removed and see if that helps. Also, you need to remove any occurrence of “quiet” in “/boot/extlinux/extlinux.conf” and then get a full serial console log. You should attach that log to the forum. There is a need to follow logs during boot to see what power regulators do, and what messages there are related to device trees. That information begins before Linux ever starts, often within boot stages (which happen to be in QSPI software, not the SD card for dev kits, in early parts of boot).
I’ve attached the kernel debug message($dmesg) and the UART debug message(msg output at the uart pins of the Jetson Nano using the UART pins under the jetson nano board).
DebugMsg.txt (21.7 KB)
KernelDmesg.txt (53.0 KB)
Summary at the end. Not for NVIDIA about EEPROM in the middle, noted with boldface font.
The logs were the correct ones. Technically, the “DebugMsg.txt” would also include what is in the “dmesg” output.
I saw a note about a failing EEPROM access. Can you tell me if this is truly a developer’s kit, versus a third party carrier board with an NVIDIA module in it? If it is a developer’s kit, then the SD card slot will be on the bottom of the module itself, and not on the carrier board; if this is a third party carrier board with an added NVIDIA module, then the SD card slot would be on the carrier board, and not under the module. You can also add a copy of this file’s content:
/etc/nv_boot_control.conf
Someone from NVIDIA might be able to better answer if the EEPROM might fail read on dev kits as “normal”, but I’m fairly certain that on a third party carrier board (which uses the eMMC version of the module) that any EEPROM failure would be an issue. Some log lines for reference from the serial console boot log “DebugMsg.txt”:
[0002.695] Find /i2c@7000c000's alias i2c0
[0002.699] get eeprom at 1-a0, size 256, type 0
[0002.709] Find /i2c@7000c500's alias i2c2
[0002.713] get eeprom at 3-a0, size 256, type 0
[0002.717] get eeprom at 3-ae, size 256, type 0
[0002.722] pm_ids_update: Updating 1,a0, size 256, type 0
[0002.727] I2C slave not started
[0002.730] I2C write failed
[0002.732] Writing offset failed
[0002.735] eeprom_init: EEPROM read failed
[0002.739] pm_ids_update: eeprom init failed
(I can’t say if this is really an error or not, I don’t have the knowledge; certainly parts of the system won’t exist on the dev kit which do exist on the commercial module, so it will be important to know the exact hardware…the carrier board model which should show in the nv_boot_control.conf; an actual EEPROM issue would cause a lot of problems, but as the saying goes, “I might be barking up the wrong tree” if this is just a result of a particular model of hardware rather than being a true error)
Also, is it correct that there is no display attached during the boot which produced the boot logs? If not, then it would be an indication that some i2c setup is incorrect (which would in turn probably be from an incorrect device tree). Knowing if the monitor was not attached when producing the logs would reduce the amount of output messages that are relevant.
For reference of anyone reading, from the log:
[0004.218] Cmdline: tegraid=21.1.2.0.0 ddr_die=4096M@2048M section=512M memtype=0 vpr_resize usb_port_owner_info=0 lane_owner_info=0 emc_max_dvfs=0 touch_id=0@63 video=tegrafb no_console_suspend=1 console=ttyS0,115200
n8 debug_uartport=lsport,4 earlyprintk=uart8250-32bit,0x70006000 maxcpus=4 usbcore.old_scheme_first=1 lp0_vec=0x1000@0xff780000 core_edp_mv=1125 core_edp_ma=4000 gpt
[0004.253] DTB cmdline: earlycon=uart8250,mmio32,0x70006000
[0004.258] boot image cmdline: root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4 console=ttyS0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0
Once the kernel actually starts the log is very short (unusually so). The imx219 error is expected since you won’t have that camera (if you do have that camera, which most people don’t, then add a note here).
I do see a log which might indicate the word “quiet” exists in file “/boot/extlinux/extlinux.conf”, which you’d want to delete that word (it is a set of “tokens” separated by spaces; just delete the word, and if you want, keep it separated by a single space from anything to the left or right; this can be done in serial console). The serial console boot log was fairly verbose, so it seems like quiet did not reduce messages, but it would be safer to not have the reduced logging of quiet just to be safe.
The summary:
/etc/nv_boot_control.conf”.This is the jetson nano i have with me.
While taking the log the monitor was not attached. i will also send a log with the monitor connected. the Rx and Tx pin on the carrier was connected to the minicom of the host computer using USB to ttl converter.
While recording the debugmsg no usb was connected to the usb hub. But even after connecting there was no power to the usb hub
DebugMsg_WithDisplayConnected.txt (33.6 KB)
soundarya@soundarya:~/Desktop$ cat copy_nv_boot_control.conf
TNSPEC 3448-402-0000-K.0-1-0-jetson-nano-qspi-sd-mmcblk0p1
COMPATIBLE_SPEC 3448-300-0000–1–jetson-nano-devkit-
TEGRA_CHIPID 0x21
TEGRA_OTA_BOOT_DEVICE /dev/mtdblock0
TEGRA_OTA_GPT_DEVICE /dev/mtdblock0
The copy of /etc/nv_boot_control.config
I see a mention of ttyUSB0. Assuming this log is on the Jetson side, then it implies an FTDI chipset USB serial UART is connected to the Jetson. Is that correct? The log line making me interested in this is:
[0004.811] "pmu-board" doesn't exist, creating 2.8 | VT102 | Offline | ttyUSB0
With multiple USB items plugged in, preferably to include the keyboard and mouse (or at least the keyboard), run the command “lsusb -tv” in the serial console. See what that output shows up as. Please describe exactly what is connected to the USB, including if a HUB is used. If needed, then try to connect just a keyboard directly to the USB port without the HUB, and run the “lsusb -tv” command again. Any output from that command is useful to know if we also know what is plugged in; it is more useful to know about any change in output depending on whether a HUB is used or not.
FYI, this is a “dev kit”. The o/s goes on the SD card, but much of the boot and perhaps firmware goes on the QSPI memory of the Jetson itself. It is likely that one step will be to reflash the Jetson’s QSPI memory from L4T R32.7.5 flash software (the L4T release of the QSPI must mach the L4T release on the SD card; earlier information shows the SD card is R32.7.5).
can you provoide me with the steps in flashing the QSPI memory from the first step. I tried flashing the QSPI memory using the CLI but the process doesn’t do forward after the message in the attached file.
DebugMsg.txt (259.0 KB). I even tried with the SDK manager but it didnot work for jetson nano since there was no Jetpack version for jetson nano(as it was mentioned in the sdk manager).
Additionally i tried running the "lsusb -tv " command but no devices were detected. "soundarya@soundarya:~$ lsusb -tv
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=tegra-xusb/4p, 5000M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=tegra-xusb/5p, 480M
".
I am using Ubuntu 22.04LTS.
Are you using strictly the SD card and not other external storage? This will change the answer.
Something in general to know about: Go to your flash software’s Linux_for_Tegra/ directory. Examine the output of this:
ls -l *.conf
You’ll find that the more common human names/aliases are symbolic links to other files. Those files name a combination of carrier board and module specifications. Flash targets happen to be those names without the “.conf” extension when flashing on command line. For example, you might see file “jetson-nano-qspi-sd.conf”, which means there is a target “jetson-nano-qspi-sd”.
I’m not positive about whether there is a risk of flashing the SD card too with this, but I think only QSPI would be flashed (you can either use a different SD card, or maybe no SD card? not sure if a card has to be present) something like this if the Nano is in recovery mode with the correct USB cable connected:
sudo ./flash.sh -r jetson-nano-qspi-sd mmcblk1p1
Can someone comment on whether this would be the correct way to flash the Nano dev kit QSPI without touching the SD card? Note though that a full normal flash also updates QSPI, but it might modify the SD card.
Note that you get the output from your “lsusb -tv” command, and when it shows the root HUBs present, then at least part of the system is working. What remains is that it likely is not routing lanes to the root HUB (which is device tree/firmware, and most of this resides in QSPI).
Another thing to test or note: Plug different devices, e.g., keyboard or mouse, into different ports while monitoring “dmesg --follow” in serial console or ssh. See if the plug-in event is visible in the logs. If no event is visible, then it is either hardware failure or firmware not routing lanes correctly. If there is in fact a log generated, then the USB has done its job and the next step is to associate a driver to the device. Logs would show how far it gets in that, so do paste any information you get if you watch “dmesg --follow” while plugging in to one of the ports (avoid the external HUB for now, but FYI, plugging in a HUB would also be visible in logs; just don’t have the HUB plugged in during boot, you are looking for the hot plug event from plugin of a running system).
I haven’t plugged any usb hub to the jetson nano. And I’m using only the sd card and not any other storage option.
When usb is plugged in no kernel message is logged.
If there is any documentation on flashing the qspi memory please do provide the same
I tried fresh install of os but still my usb is not working. I can’t even set-up my the new os without the usb hub working to connect it with a keyboard and a mouse.
I tried flashing the qspi and was done but still the usb ports is getting disabled.
I don’t know if it matters or not the temperature of thermal_zone4 is constant at 50 degree but the temperature of other zone varies on turning on or off the cooling. I was not able to find which area the thermal_zone4 corresponds to.
If you perform that flash on command line, can you log it and attach the log to the forum thread? Example of logging:
sudo ./flash.sh -r jetson-nano-qspi-sd mmcblk1p1 2>&1 | tee log_flash.txt
This would produce file “log_flash.txt”. Also, from your flash software on the host PC side (at the “Linux_for_Tegra/” location), show the output of:
head -n 1 rootfs/etc/nv_tegra_release
I don’t know if this would be possible, but if you have serial console set up and working normally for the Jetson, then during the flash you can log the serial console as well. You’d just make sure logging has started with no history, and the Jetson is in recovery mode and attached to the host PC, but flashing has not started. When you run that flash command you should start seeing activity on the Jetson as well. Assuming the serial console is set up for logging, that means that the log will be produced from both the Jetson side (serial console) and from the host PC side (the “2>&1 | tee log_flash.txt” would produce the flash side log).
I am leaning towards something might be wrong in the USB hardware, but it is so rare that this is a problem rather than firmware. You definitely have an actual dev kit, and so the software you are using is correct (do be certain the flash software is the same release as the software on the SD card). So let’s find out if the flash itself says something is wrong.
log_flash.txt (284.4 KB)
Was the flash command from above used? The flash looks entirely successful. Can you also look at your host PC, within the flash software. Go to your “Linux_for_Tegra/” flash location, then from there:
cd rootfs/etc
# Show the output of:
cat nv_boot_control.conf
head -n 1 nv_tegra_release
Now we compare it to the SD card you are booting to. You can mount the SD card on the host PC, or use examine through ssh or serial console. Go to the “/etc” of your SD card that you are booting to. Show the same content as above, but for the SD card instead of the content of the flash software (at the “/etc” of the SD card instead of the from the “Linux_for_Tegra/etc/” of the host):
cat nv_boot_control.conf
head -n 1 nv_tegra_release
We are comparing in part the QSPI and the SD card releases. This also gives an idea of what the flash software thinks the device is.
I am able to boot, even the micro usb interface is working fine but my proble is that the usb type A ports are not working. in the kernel message it is showing that it is getting disabled. i just need a way to enable it for me to use usb mouse, keyboard etc.
jetson@jetson:/etc$ cat nv_boot_control.conf
TNSPEC 3448-402-0000-K.0-1-0-jetson-nano-qspi-sd-mmcblk0p1
COMPATIBLE_SPEC 3448-300-0000–1–jetson-nano-devkit-
TEGRA_CHIPID 0x21
TEGRA_OTA_BOOT_DEVICE /dev/mtdblock0
TEGRA_OTA_GPT_DEVICE /dev/mtdblock0
jetson@jetson:/etc$ head -n 1 nv_tegra_release
jetson@jetson:/etc$
Or else please provide me a replacement board for the same…
This seems as if it is probably an actual USB hardware failure. Maybe @WayneWWW or @KevinFFF can provide instructions or verification. You’ll be interested in this information on warranty:
https://developer.nvidia.com/embedded/faq#rma-process