Hi again,
First of all I want to highlight a curiosity at the official NVidia documentation pages as found here:
Windows Subsystem for Linux :: NVIDIA SDK Manager Documentation
Because NVidia wrote that page, it suggests that WSL should work without any issues to have the sdk-manager working for several devices such as Jetson.
I have been pulling out all my hairs during my struggles why it did not work, so I am a bald guy now… unfortunately.
Anyway, maybe NVidia should indicate there what kernel of WSL2 they used. Just like I posted my complete config in the first part of this thread. WSL2 is really awesome to my opinion but things are progressing and it is not always clear what features are working and what not.
Besides that, this forum is flooded with post like “do not try WSL2 and use native host only” without any further solution directions for guys like me that just want to understand why and just want to fix it.
Now a description of the path that I walked to get it all fixed.
-
It started with not being able to build the images initially on my WSL2 which at the end were caused by an issue that the qemu-system package was not completely available on binfmts, something which is essential to get chroot working during the build and packaging process of rootfs. My fix for that issue was posted here:
Orin nano installation fails; chroot: failed to run command ‘dpkg’: Exec format error - Jetson & Embedded Systems / Jetson Orin Nano - NVIDIA Developer Forums -
After fixing that hurdle I crashed in the flashing process with the SDK manager. I switched to the commandline part of the install but that breaked at the same points (although the messages are much more clear than from the sdk-manager, which seems to hide a lot of details). I carefully watched the USB device enumeration in WSL2 in a separate Powershell window, the one where I initially did a bind --force and an auto-attach of the NVidia APX device descriptor which pops up if you put the device in factory recovery mode. During the preparation and flashing process (i believe some of the bootloader stages get activated there, correct me if I am wrong) somewhere at the main flashing stage the USB port enumerates as a different device descriptor. In fact it enumerates as a “Remote NDIS Compatible Device #2, USB Mass Storage Device”. Of course, usbpid does not have any knowledge of this new device descriptor and it is at this point not bounded yet in case you never did the bind --force for this descriptor. I suppose that many of us get stuck there. Anyway, just bind that one too once and you are done for every next auto-attach to WSL2.
-
At this point I got stuck again with the “waiting for boot” or something which looks like that message during the flash procedure, simply because the tools expects that an rndis device becomes active on the USB port, including your USB mass memory (the NVMe disk partition). For the ones who don’t understand the importance here; the flashing tool is waiting here for an Ethernet over USB connection (usbnet) to continue the flashing process over that ethernet connection (on an ipv6 address). Unfortunately the kernel that I use and described at my first post in this thread does not have all the options enabled to get an rndis capable USB connection working. My initial assumption that this was the latest kernel from MS and the fact that NVidia has posted a nice documentation page which suggests that WSL2 works ok with the SDK manager was the cause for a lot of confusion. I have been playing with more than one kernel config setting and I can just say that I needed quite some features before I achieved white smoke.
Please find attached my config.gz for my latest modified 5.15.90.1 WSL2 kernel.
Hope that this post clarifies a lot and I hope that a lot of clutter messages get removed from this forum by NVidia
config.gz (25.3 KB)
Regards
Henk