This is long since it covers a few different topics, and it jumps around, so please bear with this…
Assuming the Nano still boots, what do you see from “
lsblk -f”? I’m betting “
/dev/mmcblk0p1” (which is eMMC; it could be “
/dev/mmcblk1p1” if it is an SD card model, which it is not) is mounted on “
/”. I need to verify this is an eMMC model, and that command will answer this.
If you wish to clone (you might not care): Cloning should work regardless of carrier board so long as the device mode USB wiring is present (that’s the micro-OTG USB connector). However, any software used for actual flash likely has to come from Seeed for that particular carrier board/module combination (there are exceptions, and you might have such an exception). Furthermore, if Seeed says to use the NVIDIA SDK Manager, then it implies the firmware and carrier board layout match the dev kit; this simplifies things, but if they are not matches, then this can cause a lot of frustrating problems. Incidentally, adding an SD card slot to the carrier board, with all else being a match to the dev kit, means everything would work except for the SD card until the firmware (device tree) is set up for this.
WSL is very problematic. VMs in general tend to fail USB during a flash since they don’t handle USB correctly unless the user has manually set this up. There is also an issue with “loopback”, which I’ll describe since it might or might not matter. Note that the original WSL (the original WSL, not WSL2) stands no chance at being adjusted for loopback, but WSL2 does (though it probably is quite a learning curve). eMMC models don’t have pre-built o/s partitions, and require loopback to build. Just to emphasize, WSL2 has the ability to modify the kernel, and thus can get loopback, but by default I don’t think it does. Doing so is not trivial.
Each Jetson has a lot of software which is pre-built, and is used during boot. These are all binary images, and flash neither understands what is in that data, nor does it need to understand. There is also the root filesystem, or rootfs (partition label “
APP”, it is Linux), which is not normally just a binary image (flash treats it that way, but generating the rootfs/operating system is not just binary data). Some Nanos are “SD card” models, and Linux goes on the SD card, but some are an eMMC model, whereby the solid state memory is on the module itself, and not on an SD card. The two work the same, but have different driver setup and firmware (device trees). When flashing, one has to correctly pick what to flash (for an SD card model or an eMMC model; this is in addition to other modifications if this is a third party carrier board, so it isn’t just third party versus NVIDIA, it is also eMMC versus SD card models).
Assuming your Nano uses NVIDIA’s flash software, which sounds like this is the case, your flash target would be for the eMMC model. This would make everything functional except for the SD card (this is because the SD card is present on the carrier board, and not on the module; NVIDIA’s device tree does not know this). One would either edit the device tree or add a device tree overlay (which is in essence an edit) to make the SD card visible. When visible you could monitor “
dmesg --follow” and see log lines as you insert an SD card (assuming the SD card itself is not defective, which happens; it is good to see if the SD works on other computers). Note that an overlay does not require flash. In some cases a device tree edit does not need flash either.
Getting back to loopback, consider that if this were an SD card model (and likely it is not), then you could use a pre-built image. For eMMC, this image is built by the flash software prior to upload to eMMC. This requires loopback, and WSL (the original) cannot do this. WSL2 can only do this if you are able to install a new Linux kernel to it (and perhaps you might also have to configure and build that kernel yourself, I don’t know).
Assuming we can confirm this is an eMMC model, then you can either add the overlay, or else you can flash with a loopback-enabled Ubuntu. The easiest thing you can do is to get the overlay to work. Next to that, installing a dual boot Ubuntu 18.04 would be the easiest (you’d have to partition your existing disk with enough space for Linux, then you pick Linux or Windows at the boot prompt). The most difficult path would be to make sure you have WSL2 (not the original WSL), and get instructions on installing a kernel with loopback capability (followed by correct VM setup for USB, which I can’t help with).