Can you get a serial console log of the entire boot and attach that to the forum? The attached image is useful, but an actual log would be far more useful. More on that below.
I see the host PC filesystem is ok and not an issue. Having ext4 filesystem type and sufficient space is what I was looking for. Also, you are getting tar errors. I don’t know what WSL2 is doing to trigger this. It seems tar checkpoints are a customization, and there isn’t much of a way to tell what the checkpoint test was. It might be as simple as just an echo of the checkpoint being reached. This is rather rare to see, and it was possible the host PC filesystem was at fault, but most likely it is the tar file itself. There is also a chance that system RAM is at fault, but I’d consider that a tiny chance unless WSL2 is limiting something.
This might not matter, but there was an earlier error of not finding Python. Just for reference, which release is shown from each of these?
python --versionpython2 --versionpython3 --version
(Someone from NVIDIA might know if using just the “python” command is required to be version 2.x or 3.x python; if not, then it might still be useful to know which version is present with each command)
When you say “latest” version of SDK Manager, do you mean the version tied to L4T R36.x developer preview? If you go to your “Linux_for_Tegra/rootfs/etc/” you can run command “head -n 1 nv_tegra_release” to see the L4T release being flashed. The reason I ask is that you are using Ubuntu 22.04, and L4T 6.x is possible with this, but L4T R5.x is not. L4T R6.x is considered a developer preview, whereas 5.x is considered the stable release.
Incidentally, it looks like preparation for flash was successful, but there was no recognition of the Jetson being present in recovery mode. If you ignore the tar checkpoint errors, you still get to the point where everything is set for flash, and then the start of flash does not occur because a recovery mode Jetson is not seen. Almost all cases of this when using a VM is the VM setup being incorrect and not passing the recovery mode Jetson through to the Ubuntu o/s. During a flash the Jetson has a disconnect and reconnect, and sometimes (A) the first connect does not occur because of the VM setup, or sometimes (B) the initial connect works, but the reconnect fails. It looks like the former case in your log, that the Jetson was never visible to the VM.
Just for the record, if the recovery pin is held low (shorted to ground) while either of these occur, and then the pin is unshorted (there is no delay required), the Jetson should be in recovery mode:
Once the recovery mode Jetson is present the Linux host will see Jetson devices. The command to see any Jetson would be “lsusb -d '0955:'”. That lists all NVIDIA USB devices. The Orin should be the product ID 7023, so if you wanted to limit this to Orin you would use “lsusb -d 0955:7023”. Before flashing, if your Jetson is in recovery mode, does the WSL2 see this device via “lsusb -d '0955:'”?
Incidentally, although I suspect something in WSL2, your screenshot shows that the Jetson booted. Possibly the QSPI memory failed to flash something which supports the release on any SD card (or other media). I saw a note of initrd flash, but I’ve not seen a mention of whether you are using external media, e.g., an SSD or NVMe. Is this purely an SD card flash, or is there other media involved?
In the case of the image the error I see is in exception level 0 (that’s the el0_). This is user space, and so it isn’t a driver causing that, it is something in user land. Previous to this there is a note about missing init. This is absolutely not something that can succeed, it implies that the kernel loaded and began its first task (init is in fact process ID 1, whereas the kernel is PID 0; init is a symbolic link in Ubuntu to systemd…this is the source of all processes, whereas the kernel services the system calls to the processes). In other words, whatever your root filesystem was specified as, the kernel loaded as it should, but the filesystem was missing the most important program there is (the first user space process).
If you performed some ordinary flash on an SD card model of Orin dev kit, then it would be flashing QSPI and be set up to find that filesystem (and init) on the SD card. The QSPI content would have to be the same major release as that of the SD card. A JetPack 5/L4T R35.x QSPI flash can’t be used with a JetPack 6/L4T R36.x L4T SD card; the reverse is also true, you can’t flash JP5/L4T R36.x to QSPI and use it with a JP 5/L4T R35.x SD card. Being that the host PC is Ubuntu 22.04 (if WSL2 is working), then I would expect all content must be JP 6, including both the QSPI flash and the SD card.
If you are using external media and not purely SD card, then you would have to flash using different methods. This is why an initrd flash is used. That initrd flash acts as an adapter of sorts between a normal QSPI+SD flash to allow the rootfs to be on other media. If something were mixed in there which was not consistent on whether this was set up for external media, then I could see minimal content existing which would find and load the kernel, but then try to pivot to the external media filesystem and fail to find init. That’s just guessing, but it seems likely that the issues revolve around flash procedure for external media (if you are using external media) and/or something WSL2 is failing.
Can you provide a detailed description of your external media, if it exists? Are you certain your Jetson is in recovery mode as evidenced by “lsusb -d '0955:'” prior to flash?
