WSL2 Flashing Jetpack 5.1.13 No Luck

Before I begin, yes I understand that I could do this with a native Ubuntu machine, but at this point the sunken cost fallacy wants me to get to the bottom of this.

So I have an Orin AGX Developer kit which was flashes 6.0 and is having some problems with bluetooth. I am attempting to roll this back to 5.1.13 or 5.1.12 utilizing WSL Ubuntu 18.04 (WSL2 on Windows 10 I have tried 22 20 and 18 with the best luck at 18).

From the following instruction page: Windows Subsystem for Linux (WSL) — sdk-manager 2.0.0 documentation I am able to setup a WSL environment and with the addition of upgrading and the info from this stack overflow about libnss3: linux - "Error while loading shared libraries: libnss3.so" while running Gtlab CI job to perform automated testing using webdriverio - Stack Overflow

(the documentation for the wsl-system should be updated, sdkmanager cannot run without installing these packages first and updating)

sudo apt install libnss3 libgconf-2-4 libatk1.0-0 libatk-bridge2.0-0 libgdk-pixbuf2.0-0 libgtk-3-0 libgbm-dev libnss3-dev libxss-dev

Then applying the fix from: Installation fails on WSL - #23 by michel30 I am able to get a build going ready to flash.

Now I am hit with yet another roadblock where:

23:11:35 INFO: Flash Jetson Linux - flash: [ 0.0483 ] File rcm_state open failed
23:11:35 ERROR: Flash Jetson Linux - flash: [ 0.0485 ] ERROR: failed to read rcm_state
23:11:36 ERROR: Flash Jetson Linux - flash: --- Error: Reading board information failed.
23:11:36 ERROR: Flash Jetson Linux - flash: [exec_command]: /bin/bash -c /tmp/tmp_NV_L4T_FLASH_JETSON_LINUX_COMP.calvin.sh; [error]: --- Error: Reading board information failed.
23:11:36 SUMMARY: Flash Jetson Linux - flash: First Error: Installation failed.

Where here I am stuck on what appears to be an issue of reading the board information. Where on WSL you cannot utilize the fix recommended in Jetson AGX Orin FAQ

This was addressed in a recent forum post: Unable to flash Jetson Orin Nano - #14 by salamander1 in which my ultimate take away was from @DaveYYY that “You won’t be able to flash the device with the default WSL2 setting even after the timeout issue is solved, so please consider finding a real Ubuntu PC instead unless you really cannot.”

I feel like I am really close. I want to believe that this is possible, I mean if not why is there even a documentation page for it?

I will attach the total logs incase it is useful.
(upload://x8seWSgoyVuV
sdkm-2024-03-05-22-45-01.log (616.7 KB)
RPXNGogjq8du4lD.zip) (162.8 KB)

23:03:39.580 - info: NV_L4T_FLASH_JETSON_LINUX_COMP@JETSON_AGX_ORIN_TARGETS: [ 0.1754 ] BR_CID: 0x80012344705DD5176C00000015FF8080
23:03:39.580 - info: NV_L4T_FLASH_JETSON_LINUX_COMP@JETSON_AGX_ORIN_TARGETS: [ 0.1832 ] Sending bct_br
23:03:44.586 - error: NV_L4T_FLASH_JETSON_LINUX_COMP@JETSON_AGX_ORIN_TARGETS: [ 0.1832 ] ERROR: might be timeout in USB write.

Check this:

Please note that WSL2 does not use loadble kernel modules, so you have to adjust this setting via kernel cmdline.
Google for the tutorial on kernel cmdline with WSL2.

I just found that I had already answered it in the topic you posted:

So I don’t know how kernel command line works and will look into it more tomorrow, but I thought that the following response in that thread attempted it with loading the following into a .wslconfig file

[wsl2]

kernelCommandLine= usbcore.autosuspend=-1

Which did not work because as you said “It’s not a loadable kernel modules so it’s expected it won’t appear there.”

This is where I am also looking to understand things. But from The kernel’s command-line parameters — The Linux Kernel documentation ‘usbcore.autosuspend’ is listed as a kernel parameter

Sorry that it’s not about kernel cmdline or loadable modules.
I just found that you should still get /sys/module/usbcore/parameters/ on WSL2, but just autosuspend is not there.
Maybe it’s related to the kernel config used by WSL2; I will study it more later.

Taking a look at GitHub - microsoft/WSL2-Linux-Kernel: The source for the Linux kernel used in Windows Subsystem for Linux 2 (WSL2) I see where the other parameters are being set which are in /sys/module/usbcore/parameters/ for example here: WSL2-Linux-Kernel/drivers/usb/core/devio.c at linux-msft-wsl-5.15.y · microsoft/WSL2-Linux-Kernel · GitHub

I am not familiar with kernel level code what so ever, so this might be a red herring but it seems like if the goal is to disable auto suspend it lives around here. Which then have to compile a custom kernel and utilize that.

Yeah, re-compiling kernel is definitely required.
See if specifying this value works:

@DaveYYY When building a new kernel following: Steps for compile Mainline Kernel Linux using WSL2 · GitHub there are a million options that can be selected are you aware of any that are required for the task of flashing a board? maybe there is documentation somewhere I did not see.

Edit. Following GitHub - microsoft/WSL2-Linux-Kernel: The source for the Linux kernel used in Windows Subsystem for Linux 2 (WSL2) documentation instead.

I attempted with no success to change the USB_AUTOSUSPEND_DELAY from it’s default of 2 to -1 as seen here: WSL2-Linux-Kernel/arch/x86/configs/config-wsl at linux-msft-wsl-5.15.y · microsoft/WSL2-Linux-Kernel · GitHub

After building and changing the kernel as shown here: Steps for compile Mainline Kernel Linux using WSL2 · GitHub

I tested to make sure that this change was in place by looking at the configs in /proc/config.gz which confirmed that my change was implemented.

I received the same result of ERROR: Flash Jetson Linux - flash: [ 0.0485 ] ERROR: failed to read rcm_state

Then please do find a native Ubuntu PC instead.
We haven’t verified the USB autosuspend issue on WSL2, and we don’t guarantee it’s working fine.

Adding the following

static int autosuspend = -1;
module_param(autosuspend, int, S_IRUGO | S_IWUSR);
MODULE_PARM_DESC(autosuspend, "the default autosuspend delay in seconds");

To WSL2-Linux-Kernel/drivers/usb/core/devio.c at linux-msft-wsl-5.15.y · microsoft/WSL2-Linux-Kernel · GitHub

and recompiling did add autosuspend as a configurable parameter which is set to -1 in /sys/moduel/usbcore/paramater/autosuspend. However, that also resulted in the same behavior.

Thus, here ends my journey for now on this. I would recommend adding some comment to the WSL page Windows Subsystem for Linux (WSL) — sdk-manager 2.0.0 documentation as it stands it only creates frustration and confusion for others. If we can leave it open incase someone more knowledgeable wants to pick this up at some later point in time.

@DaveYYY thanks for the help

1 Like

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.