How do I add driver support for a DWA-131 USB WiFi Adapter?

[octonout]

Yocto version: dunfell
meta-tegra: Linux4Tegra release: R32.4.3 and JetPack release: 4.4.

Hey there. I have built a Boot2Qt image for Jetson Nano. I have a D-Link DWA-131 USB WiFi Adapter which I want to use to connect the Nano to WiFi. Currently, the adapter is detected on the Nano, but the driver isn't loaded automatically. The driver (rtlxxxu) is actually present and I can load it with modprobe, but that doesn't make the adapter work. It doesn't show up as an interface in the ifconfig output. Here is the dmesg output: pastebin

The same WiFi adapter works flawlessly on my laptop which runs Ubuntu 20.04 with 5.11.0-25-generic kernel.
Snippets from dmesg output on laptop:

usb 1-2: This Realtek USB WiFi dongle (0x2001:0x3319) is untested!
usb 1-2: rtl8xxxu: Loading firmware rtlwifi/rtl8192eu_nic.bin
usbcore: registered new interface driver rtl8xxxu

From the above snippet we get the Vendor ID: 2001 and Product ID: 3319. The driver is rtl8xxxu.
More from dmesg for reference: pastebin

The Boot2Qt image packs in the 4.9.140-l4t-r32.4 kernel. So I figured the kernel didn't have support for DWA-131. The rtl8xxxu_core.c in the kernel has the list of supported devices in an array. Comparing the source code for both kernels, the 5.11 kernel has the Vendor ID and Product ID listed in the dev_table[] array

{USB_DEVICE_AND_INTERFACE_INFO(0x2001, 0x3319, 0xff, 0xff, 0xff),
	.driver_info = (unsigned long)&rtl8192eu_fops},

Link to 5.11 kernel source for rtl8xxxu_core.c

I checked whether the same was present in the kernel source derived from the L4T BSP. It isn't present there. This seems like the source of the problem. Link to 4.9 kernel source for rtl8xxxu_core.c.

Now, I have built the linux kernel a couple of times in the past, but I haven't customized any drivers in the kernel. I have done a couple of builds with Yocto for development, but still consider myself a beginner. I was hoping you guys could point me in the right direction.
What would be the correct approach to try and add support for the adapter? Also, If I do end up changing the kernel source, how should I test whether the customizations work well and don't break any functionality? I plan to use systemd networkd and wpa_supplicant to set up the WiFi connection.

Any input is appreciated. Thanks for reading!

[madisongh]

This is potentially a big and complicated topic: adding support for a device not already supported in the kernel you have can be a lot of work. Wi-Fi is particularly troublesome, in my experience, particularly if you're building it into a product that you'll have to certify for regulatory compliance. (An already-certified USB module should make that part a bit easier, though.)

If you can't change out the part for one that already has support in the kernel we have in the BSP, you should start by trawling through the kernel sources to look for patches to back-port. In this particular case, there's this commit, which should at least get you started, and doesn't look too difficult to port. I see some other, more recent commits around the rtl8xxxu (some of which have already been back-ported to the linux-stable 4.9 branch, but aren't in the version we get from NVIDIA) and the rtl8192eu in particular; it will be up to you to determine whether you need them or not. Assuming that one patch is enough to get the device recognized, then start testing that it actually works (at a basic level), test the features you need, and then stress-test them. If everything you need works well enough for your purposes, you're probably good to go.

If, on the other hand, you need features that aren't present, a fuller backport might help. See here for general information on the Linux Backports project (which was originally implemented specifically for wireless drivers, because they've been such a problem). The tools there should help with the task.

[octonout]

Hey. Thanks for the detailed reply. I have noted the things you have mentioned about using a device that is already supported by the 4.9 kernel we get from NVIDIA. Also, certifying for regulatory compliance. Will look into it.

Currently for development purposes I need to get this USB adapter to work. As far as back-porting this commit goes, I am a bit confused about how to approach this.

There is this guide that shows the cherry picking method.
And there was this documentation from Yocto about Using Traditional Kernel Development to Patch the Kernel.

So what I did was, I cloned the patches-l4t-r32.4 branch from github.com/OE4T/linux-tegra-4.9.git,
Used,

$ git remote add linux_kernel https://github.com/torvalds/linux.git
$ git fetch linux_kernel

so that I could cherry-pick this commit

Then I continued with the following commands:

$ git cherry-pick -x 66dfa26ebca8de9764190fed6ef509cd2b514c74
$ git config merge.renameLimit 10000
$ git add drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
$ git cherry-pick --continue

Had to increase the merge.renameLimit because I got this warning.

Then I created a patch file $ git format-patch -1, moved it to a custom layer and created a linux-tegra_4.9.bbappend, appended the patch file to the SRC_URI. After which, cleaning and rebuilding the image led to this error ERROR: linux-tegra-4.9.140+gitAUTOINC+166b394331-r0 do_compile_kernelmodules: oe_runmake failed

I am sure there are mistakes in this method I used. Should I clone the patches-l4t-r32.4 branch from github.com/OE4T/linux-tegra-4.9.git and manually make changes to the source code? Will doing this allow me to write a recipe to compile the kernel from this local repo? Is there a better way for back-porting?

[madisongh]

Either patching or forking is an OK approach. You can easily change the repo, SRCREV, etc. for the kernel recipe by modifying variables in your bbappend, if you take the forking approach.

But the patch should have worked, too -- assuming you resolved any conflicts in the cherry-pick correctly.

[octonout]

The cherry-pick didn't work because I didn't remove the conflict markers and resolve the conflict. My first time using cherry-pick 😅. Before I realized this, I manually added the code from the commit and created a patch. The image got built successfully. I tested the adapter on the new image. The device was recognized, the driver was loaded automatically and I could set up WiFi with wpa_supplicant and systemd networkd. Although, speed while downloading files with wget was inconsistent. Even though the adapter was within a couple meters of the WiFi router, the signal strength was only ~-80dBm.

For now I have cross compiled the 8192eu.ko module from this repo by Mange. For anyone who ends up reading this post in future, you will need the full kernel source to build the module. And not just any kernel source, I had to use the kernel source from the linux-tegra WORKDIR.
Path-

${BUILDDIR}/tmp/work/jetson_nano_qspi_sd-poky-linux/linux-tegra/4.9.140+gitAUTOINC+166b394331-r0/linux-jetson_nano_qspi_sd-standard-build/

And for cross compilation I used the Yocto built SDK for the Jetson Nano.
Path-

${PATH_TO_SDK_DIR}/sysroots/x86_64-pokysdk-linux/usr/bin/aarch64-poky-linux/aarch64-poky-linux-

Edit the Makefile in repo. This is the git diff of the changes I made:

-CONFIG_PLATFORM_ARM_AARCH64 = n
-CONFIG_PLATFORM_I386_PC = y
+CONFIG_PLATFORM_ARM_AARCH64 = y
+CONFIG_PLATFORM_I386_PC = n

Command used to compile the source code from the repo-

make ARCH=arm64 CROSS_COMPILE=<PATH_TO_SDK_DIR>/sysroots/x86_64-pokysdk-linux/usr/bin/aarch64-poky-linux/aarch64-poky-linux- KSRC=<BUILDDIR>/tmp/work/jetson_nano_qspi_sd-poky-linux/linux-tegra/4.9.140+gitAUTOINC+166b394331-r0/linux-jetson_nano_qspi_sd-standard-build/

You might find this post helpful.

Once the module is built, you can just scp the module to the Nano and modprobe cfg80211 which is a dependency for the 8192eu.ko module, insmod the 8192eu.ko module. This should insert the module, confirm with lsmod. Connecting the adapter now should make the new interface show up in ifconfig output.

Use wpa_supplicant to connect to your WiFi router. Follow the archwiki guide for wpa_supplicant if its your first time using it.
This is the command I used: wpa_supplicant -B -i wlan0 -c /etc/wpa_supplicant.conf. Make sure you change the interface name if yours isn't wlan0. Also, make sure you have edited the wpa_supplicant.conf as needed with your ssid and psk. After you run this command, wpa_supplicant should connect your Nano to your WiFi router. I have configured systemd networkd to get me a dynamic ip from the router.

For systemd networkd help, watch these: video 1 and video 2.

Edit: Inserting this out of tree module will taint the kernel. But, now I get expected speeds and Signal strength for the adapter is ~-45dBm.

@madisongh Thanks for the help.

Cheers.

P.S.: The Backports Project is really interesting.

[madisongh]

Glad you got something working, and thanks for sharing the info.

You can also write a recipe to build out-of-tree drivers like this one. Documentation is in the Yocto Project manuals.

[lfdmn]

Just a hint: after initializing your yocto environment, you have a tool available called devtool Usage ``` devtool modify linux-tegra # make modifications in the temporary workspace and build with bitbake linux-tegra ``` It works for any recipe name you'd need to create patches for and you don't need to worry about manual cross compilation. Bitbake handles that for you.

…

On Tue, Aug 17, 2021, 20:53 octonout ***@***.***> wrote: The cherry-pick didn't work because I didn't remove the conflict markers and resolve the conflict. My first time using cherry-pick 😅. Before I realized this, I manually added the code from the commit and created a patch. The image got built successfully. I tested the adapter on the new image. The device was recognized, the driver was loaded automatically and I could set up WiFi with wpa_supplicant and systemd networkd. Although, speed while downloading files with wget was inconsistent. Even though the adapter was within a couple meters of the WiFi router, the signal strength was only ~-80dBm. For now I have cross compiled the 8192eu.ko module from this repo <https://github.com/Mange/rtl8192eu-linux-driver> by Mange. For anyone who ends up reading this post in future, you will need the full kernel source to build the module. And not just any kernel source, I had to use the kernel source from the linux-tegra WORKDIR. Path- ${BUILDDIR}/tmp/work/jetson_nano_qspi_sd-poky-linux/linux-tegra/4.9.140+gitAUTOINC+166b394331-r0/linux-jetson_nano_qspi_sd-standard-build/ And for cross compilation I used the Yocto built SDK for the Jetson Nano. Path- ${PATH_TO_SDK_DIR}/sysroots/x86_64-pokysdk-linux/usr/bin/aarch64-poky-linux/aarch64-poky-linux- Edit the Makefile in repo. This is the git diff of the changes I made: -CONFIG_PLATFORM_ARM_AARCH64 = n -CONFIG_PLATFORM_I386_PC = y +CONFIG_PLATFORM_ARM_AARCH64 = y +CONFIG_PLATFORM_I386_PC = n Command used to compile the source code from the repo- make ARCH=arm64 CROSS_COMPILE=<PATH_TO_SDK_DIR>/sysroots/x86_64-pokysdk-linux/usr/bin/aarch64-poky-linux/aarch64-poky-linux- KSRC=<BUILDDIR>/tmp/work/jetson_nano_qspi_sd-poky-linux/linux-tegra/4.9.140+gitAUTOINC+166b394331-r0/linux-jetson_nano_qspi_sd-standard-build/ You might find this post <Mange/rtl8192eu-linux-driver#49 (comment)> helpful. Once the module is built, you can just scp the module to the Nano and modprobe cfg80211 which is a dependency for the 8192eu.ko module, insmod the 8192eu.ko module. This should insert the module, confirm with lsmod. Connecting the adapter now should make the new interface show up in ifconfig output. Use wpa_supplicant to connect to your WiFi router. Follow the archwiki guide for wpa_supplicant if its your first time using it. This is the command I used: wpa_supplicant -B -i wlan0 -c /etc/wpa_supplicant.conf. Make sure you change the interface name if yours isn't wlan0. Also, make sure you have edited the wpa_supplicant.conf as needed with your ssid and psk. After you run this command, wpa_supplicant should connect your Nano to your WiFi router. I have configured systemd networkd to get me a dynamic ip from the router. For systemd networkd help, watch these: video 1 <https://www.youtube.com/watch?v=cmm0swqkCu8> and video 2 <https://www.youtube.com/watch?v=6VDgDzZ3WvY>. @madisongh <https://github.com/madisongh> Thanks for the help. Cheers. P.S.: The Backports Project is really interesting. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#778 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEDDM26LUO2LUFRDLY7KJ2TT5KO2BANCNFSM5CGDVJ4A> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email> .

[octonout]

Just a hint: after initializing your yocto environment, you have a tool available called devtool Usage devtool modify linux-tegra # make modifications in the temporary workspace and build with bitbake linux-tegra It works for any recipe name you'd need to create patches for

I have heard about devtool in a couple talks on YouTube as well as read a bit about it. Didn't know it could create patches for all recipes. Need to learn how to use it.

and you don't need to worry about manual cross compilation. Bitbake handles that for you.

I had come across this while I was trying to figure out how to cross-compile the module using Yocto. But the Makefile used along with the hello-mod_0.1.bb example is quite simple in comparison to the Makefile for compiling the adapter drive. Apart from a custom recipe, I couldn't figure out what kind of changes would be required to be done to the Makefile for bitbake to be able to cross-compile the module. So I manually cross-compiled it.