Sorry for troubling, we are looking for NVMe ssd storage extension on Jetson Nano, we used external convertor(M.2 Key E to Key M) to connect the SSD, and tried to copy root files to SSD.
The problem is that we succeed with Samsumg EVO 970, but failed other types like Toshiba RC100/RC500：
Could you kindly help to check the possible issue? thanks!
I probably can’t answer, but you’ll need to include debug messages. For example, anything from “dmesg” related to this, or any errors you may get on command line (for example, lack of the “
The booting procedure is take quite long time, and after system boots, I checked the log, it showing PCIe and NVMe error as below screen shots.
Serial console would be a good way to get a boot log (which logs even prior to Linux). You’d need a 3.3V serial UART.
I uploaded the boot log from the serial port as below, please kindly help check the possible reason.
As I mentioned, we used a convertor from Key E to Key M, and Key E only suppoort 2 lane PCIe, while Key M supports 4 lanes, could this be the reason that it only works for typical type of SSD linke EVO970 not others?
jetson_nano_startup.log (12.3 KB) jetson_nano_startup1.log (51.7 KB)
It seems nothing to do with “mount rootfs” to ssd, but just an issue that your SSD is not readable. These two are different kinds of issue so I need to clarify it first.
Please disable the “quiet” keyword in Linux_for_Tegra/rootfs/boot/extlinux/extlinux.conf and re-flash your board.
This would dump more log during boot up.
Also, your log does not match your picture anymore. It seems either hang or cpu crash.
Yes, the purpose is to mount rootfs and boot from SSD, but with some types of SSD, the SSD is not correctly identified and sometimes even the entire system is not booting up.
The picture is taken in the scenario: the system is booting up, but SSD is not identified.
The printed log is taken in the scenario: the system cannot boot up.
With the EVO970 ssd I completed the entire operation and the system is boot perfectly from SSD.
Thanks for your suggestion, I will try to modify the extlinux config without the SSD and try to boot again.
Below is the detailed log without quiet, could you kindly help to check the possible reason?
jetson_nano_startup_no_quiet.log (328.2 KB)
I’m just wondering if this is something to do with ASPM states of the device being enabled and causing the issue.
Could you please add ‘pcie_aspm=off’ to the kernel command line?
One way to do this is to edit the ‘APPEND’ line in “/boot/extlinux/extlinux.conf” file with ‘pcie_aspm=off’ and rebooting.
Also, please attach the output of ‘sudo lspci -vvvv’ with Toshiba’s NVMe card (problematic card) connected to the system
I tried to modify the extlinux.conf config by adding pcie_aspm=off, it takes really long time to boot(around 15 mins), however the system boots up successfully, and after the system was up, the external SSD(from Lexar, also failed previously) can be located under /dev, also can be identified as a storage device under “other location” in file explorer.
During the long booting sequence
Also, I attached the log with “lspci -vvv” below, please kindly help to check the possible reason.lspci.log (14.3 KB)
One thing to bring up again, that we are using an external convert from M.2 Key E to Key E(adding additional 15 cm long cable) to connect the SSD to the existing M.2 connect on developer kit carrier board, could this be the root cause?
As additional information following, I tried to reboot the system for several times, this is not stable that the system occasionally cannot boot up successfully, just showing NVIDIA start-up image from time to time.
With the latest log (i.e. lspci.log), what exactly is the issue? to me, things look fine actually.
You also mentioned that the booting of the system is not stable. Can you please attach the log when it doesn’t boot properly?
Yes, the lspci.log is captured after a successful boot up, below I attached the log from the serial port during a long time/ failed booting scenario.
boot_failed.log (30.3 KB)
Please kindly help double-check, thanks!
As a short summary, trying to boot with the SSD(from Lexar), could lead to three situations:
- System cannot boot, NVIDIA start up screen kept showing from time to time, log from serial port as below:boot_failed.log (30.3 KB)
- System boot successfully after long time, but SSD(nvme0n1) was not identified under /dev, lspci -vvv log as below:
lspci_bootOK_no_device_under_dev.log (14.2 KB)
- System boot successfully after long time and SSD(nvme0n1) was identified under /dev, can be formated and mounted under /media. lspci -vvv log as below:
lspci.log (14.3 KB)
Can you please share the full log (dmesg log) of case-2 above?
Case-3 log shows there is some issue with display. I’ll pull-in folks to help you with that.
Sorry, for Case 2, it happened really seldom, I will try to reproduce, once I got the full log, I’ll post here.