is apply-binaries-sh.txt a full log of what is shown in terminal after you run sudo ./apply_binaries.sh? It should install way more packages than what your log gives. Did you delete the original folder and have a freshly downloaded-extracted BSP?
Can you show us what is inside your Linux_for_Tegra/rootfs/lib/modules/5.10.104-tegra/kernel/drivers folder?
The apply-binaries-sh.txt was indeed the full log.
I have downloaded both packages again from: https://developer.nvidia.com/downloads/embedded/l4t/r35_release_v3.1/release/jetson_linux_r35.3.1_aarch64.tbz2/
Following your suggestion to ls -al Linux_for_Tegra/rootfs/lib/modules/5.10.104-tegra/kernel/drivers we indeed found something unexpected - namely that:
supergrobi@OS:~/nvidia$ ls -al Linux_for_Tegra/rootfs/lib/modules/5.10.104-tegra/kernel/drivers
ls: cannot access 'Linux_for_Tegra/rootfs/lib/modules/5.10.104-tegra/kernel/drivers': No such file or directory
supergrobi@OS:~/nvidia$ ls Linux_for_Tegra/rootfs/lib/modules
ls: cannot access 'Linux_for_Tegra/rootfs/lib/modules': No such file or directory
Could this be a hint to what is going wrong in here?
Further - permissions are okay like that:
That is really weird…
Absence of the lib/modules means your system is no more than a pure Ubuntu, with no NVIDIA stuff in it.
Are you sure sudo ./apply_binaries.sh end correctly without any errors? Also try if this post helps.
If downloading and extracting the BSP package does not solve the issue, can you please try to use a different host PC?
@m.j.kurz What is the host system? It seems NVMe flashing is just broken out of the box for Ubuntu 20. I faced yet another failure mode flashing to NVMe.
A friend has successfully flashed with Ubuntu 18 but we need to repeat it on another machine to be sure if the OS is truly the issue.
Fails in the same manner I have seen in SDKM, citing permissions issues with RTELink. Why is this so broken on Ubuntu 20? It seems Ubuntu 18 works fine:
Looks like the flashing process was interrupted as your device entered the UEFI Shell.
Make sure UEFI Shell is not in the first place in boot order, and unplug all peripherals (keyboard, mouse, USB flash drive, etc.) from your device and flash again.
The flash seems to succeed and seems to provide an open ssh connection.
The IP is not requested from the DHCP server (that I have configured on my Notebook) - but set static from a previous flash (192.168.0.1).
ssh root@192.168.0.1
…does not respond.
Restarting the device and showing the logs over the serial monitor: 230523_serial.log (30.2 KB)
…shows me again, that the normal boot is interrupted by UEFI. As I try to manually exchange the boot order in the UEFI-menu (haahaa), I see, that the NVMe should be the first to boot, then comes IPv4, then IPv6 and so on.
What seems miraculous in that context is, that even though I flashed the device now multiple times - the boot-loader remains the UEFI with the previously set configurations.
I don’t quite get it with this part, and can you please elaborate it more?
You should be able to ssh into 192.168.55.1 if you connect the device to your host PC with a micro USB cable.
Thanks for asking these questions - I got it wrong before and tried to establish a connection through Ethernet-SSH.
Unfortunately it seems, that my Host-PC is not getting the CDC_USB up. One issue I figured out already was, that I didn’t have TPM2 activated on my host. After activating I still get:
usb usb2-port1: config error
…when dmesg --follow and plugging in the Jetson USB.
Regarding the UEFI shell - yes - I could change the boot-order:
Did dmesg give you things in addition to this when the connection failed?
Have you tried with a different USB cable/port?
dmesg --follow-new gives the same error (and only that): usb usb2-portX: config error
…on all USB-ports.
I’d suggest you use UART or real Ethernet to log into your device if the USB method is temporarily unavailable.
UART works fine. The main issue - that even after flashing the devices NVMe, it does not boot, but just opens the promp to press either ESC, F11 or Enter to either [go into boot-menu], [continue normal boot], [open UEFI-shell] - persists.
The IP is not requested from the DHCP server (that I have configured on my Notebook) - but set static from a previous flash (192.168.0.1).
I don’t quite get it with this part, and can you please elaborate it more?
To elaborate further on that: In one of my previous efforts I have set the IP in the UEFI-boot-menu to 192.168.0.1.
After that - I have made a series of attempts to flash the devices NVMe with the, in the previous comments mentioned methods. Further I have set up a DHCP-server on my host - so when connecting the physical Ethernet cable - the Jetson should request an IP from the DHCP.
In practice, this does not happen - and the IP remains 192.168.0.1 (its possible to ping) - and trying to connect with ssh root@192.168.0.1 fails.
Hi, sorry that I just noticed the flashing process was not complete.
It booted into initrd kernel, and rootfs was to be flashed via SSH, which should be established with the USB cable.
Did you get anything after
Waiting for device to expose ssh …RTNETLINK answers: File exists
RTNETLINK answers: File exists
Waiting for device to expose ssh …Run command: flash on fc00:1:1:0::2
SSH ready
, or you thought it had completed so you removed the cable?
sorry for the late discovery, but I just noticed that you said you want to flash the NVMe SSD on the title of this post, but you used mmcblk1p1 instead of nvme0n1p1 in the flashing command…