Using Windows OS Laptop with WSL2 for Jetson AGX Orin Development

[yahya.girgin]

Hello NVIDIA Developer Community,

I am currently working on a master’s thesis project that involves transitioning critical software from Qualcomm QNX to NVIDIA Jetson AGX Orin. My development environment consists of adapting radar system processing to leverage the power of NVIDIA GPUs using the Jetson AGX Orin kit.

Due to certain constraints, I am primarily using a Windows operating system laptop. I understand that Jetson AGX Orin typically works with native Ubuntu OS, but I would like to explore the feasibility of using Windows Subsystem for Linux 2 (WSL2) for my development tasks.

Here are the specifics of my situation and my requirements:

Project Context:

Transitioning software from QNX to Jetson AGX Orin.
Adapting radar processing algorithms to use CUDA and TensorRT on NVIDIA GPUs.
Need to compile and build source code using the NVIDIA compiler locally on my PC.
Current Setup:

Windows 10 laptop with WSL2 installed.
Ubuntu 20.04 running on WSL2.
Challenges and Questions:

Compatibility: Can the Jetson SDK and other required tools for cross-compilation be effectively run on WSL2?
Performance: Are there any known performance issues or limitations when using WSL2 for CUDA development and cross-compilation?
Networking: Since my Jetson AGX Orin is connected to an Ubuntu computer in the office, can I reliably connect to it via SSH from WSL2 for development and deployment purposes?
Best Practices: Are there recommended practices or configurations for setting up a development environment on WSL2 that can interact seamlessly with Jetson AGX Orin?
Docker: Can I run the JetPack Cross Compilation container on WSL2, and if so, are there any special configurations required?

[DaveYYY]

I think it should be fine if you just need cross compilation.
Flashing your Jetson devices needs more trick.

[linuxdev]

This isn’t directly your question, but what follows might be useful in understanding what is going on.

When a Jetson flashed in recovery mode it becomes a custom USB device. This means a custom driver is required to access a Jetson in recovery mode. This is basically what the flash software is. The part of the flash software which actually performs the flash is the “driver package”, while JetPack is a GUI front end, and SDK Manager is a network layer on top of JetPack. The driver itself is a Linux desktop PC architecture binary executable. So recovery mode requires running that Linux executable, but this is not used in cross compiling.

During flash there are some additional Linux services used to create filesystems, including a feature known as “loopback” which Windows does not have. I guess older Windows WSL did not have loopback, and so anyone using this had to know how to custom compile and install a new Linux kernel into WSL. I have not used it, but WSL2 seems to have added loopback. Even so, during flash the Jetson will disconnect and reconnect the USB, and so if WSL2 is not correctly configured, then flash will fail when Windows fails to pick up the reconnect (being connected at the start of flash is necessary, but insufficient).

If you cross compile bare metal, then your environment simply needs the correct compiler. This includes the Linux kernel and boot chain.

If you cross compile user space, then you need the correct cross tools, which expands to include a cross linker and a sysroot to link against.

The sysroot is everything in user space the user space software takes advantage of as it runs. One possibility is to set up a Jetson to natively be able to compile your software, including dev header libraries, and then to clone that and loopback mount it on the host PC (which original WSL will fail on, but WSL2 probably will work). Using the clone implies all of the libraries and related files will match what they go to if and only if you could compile natively on the Jetson the clone is from.

You could also set up the Jetson for build, clone it, and then copy a subset of the clone for your sysroot.

In all cases make sure the filesystem your WSL2 uses is type ext4. If you use a Windows filesystem type then you’ll have a large number of strange errors.