Hi all,
I was just wondering if its possible to use M.2 Wi-Fi module of Jetson Xavier NX Dev Kit on Jetson Nano. When I plug it in, Jetson Nano recognizes it as RealTek Semiconductor Inc. but under the Wi-Fi Networks, it doesn’t show any available networks to connect and says “device not ready”.
Is there any chance or workaround to use this M.2 module on Jetson Nano Dev Kit or Jetson AGX Xavier Dev Kit?
I don’t know anything about the specific hardware, but if you see USB announce the device, then it implies the m.2 slot (or USB for USB devices) has done its job. What happens next is that a driver must take ownership of the device. If the driver is not present, or if some sort of customization by the manufacturer causes the device to not be recognized by drivers otherwise capable of using this device, then nothing more happens and the device will be there without function.
Due to RF compliance it isn’t unusual for firmware to also be required for WiFi devices. Any driver would require the device to be set up by its firmware before it can load without error. Your WiFi may not require extra firmware, but this could also cause failure.
Someone else may be able to answer for your specific case, but you’ll need to include the log of “dmesg” first.
3rdparty vendor driver is probably needed for M.2 wifi card. For example, Intel driver is required for ac8265 wifi card.
Your card may need that driver and firmware too. Some cards are lucky enough that don’t need to install extra drivers because our kernel has installed them already.
Thanks for the explanation. I think that two below lines are relevant with the new Wi-Fi module:
[ 5.631556] rtk_btusb: fw name is rtl8822cu_fw
[ 5.638667] rtk_btusb: This is not 8723a, use new patch style!
And also here is the full dmesg output.
dmesg_out.log (62.8 KB)
Yeah I agree that Jetson Nano also needs to have the same drivers with Jetson Xavier NX Dev Kit in order to be able utilize the same Wi-Fi module. I just thought that JetPack 4.4 for Jetson Nano would have the driver so I just upgraded my JetPack from 4.3 to 4.4 on the Jetson Nano but no luck.
Hi,
According to your log, looks like not a driver issue but some smmu problem.
Could you remove below lines in tegra210-porg-pcie.dts?
/delete-property/ iommus;
/delete-property/ iommu-map;
/delete-property/ iommu-map-mask;Sorry for the inconvenience but I can’t find the exact tegra210-porg-pcie.dts file neither within my filesystem nor sdkm directory on the host PC. But when I check the log file, there is a line as follows: DTS File Name: /dvs/git/dirty/git-master_linux/kernel/kernel-4.9/arch/arm64/boot/dts/../../../../../../hardware/nvidia/platform/t210/porg/kernel-dts/tegra210-p3448-0000-p3449-0000-b00.dts
Should I make the change within this file? Thanks.
Hi,
Because it is in the kernel source tarball. Please download it from download center and follow the guidance in l4t development guide to rebuild a new dtb and reflash it to your device.
Could we use the AW-CB375NF(SDIO3.0 interface) on Xavier NX? Thanks.
Hi chen.arby,
Please help to open a new topic for your issue. Thanks
Hi, I can confirm that the previously mentioned DTB patch fixes the issue and the Wifi card works without a glitch (I ran iperf over half an hour on it without a single lost packet).
Is there a reason why is the IOMMU configured like this on Nano? Could the three lines be deleted in the default distribution’s DTB so that everyone can swap cards between NX and Nano without this kind of hassle?
@WayneWWW The DTB patch does not do it for me. I did everything exactly by the book. Maybe I am getting the order of steps wrong? Maybe It does not work with recent source, release and rootfs packages? See my log for details: jetson_wlan.md (1.9 KB)
Help appreciated. Thank you :)
You can check the device tree on your device under the node /proc/device-tree.
What we are doing is remove that 3 lines in pcie@1003000. Thus, please check pcie@1003000 in /proc/device-tree and see if iommus/iommu-map and iommu-map-mask appear or not.
If they are not there, it means your update in device tree does not succeed.
There is also one check point in your step to make sure the change is really taking effect.
You can use dtc tool to convert your dtb in Linux_for_Tegra/kernel/dtb/ back to dts and check if iommu is really enabled.
However, what I am not sure about is you use “jetson-disk-image-creator.sh” to create sdcard image here. Actually, I usually use flash.sh at that step but not directly create sdcard image.
Thank you for the quick reply.
Did ls /proc/device-tree/pcie@1003000, no files called iommu*. As expected.
Which blobfile in <release>/kernel/dtb should I unravel? There is so many of them and none has the terms porg or pcie as part of their names (looking for relations to the source file). Or do I need to unravel all of them?
I figured that there is a nested chain of _ddot_ directories living in the <release>/kernel/dtb directory. Kinda smelly - is this expected?
I am going to investigate jetson-disk-image-creator.sh as soon as I find out, if the fix was actually applied through kernel building or not (by deblobbing the necessary file in <release>/kernel/dtb). It looks pretty harmless on first sight though, just calls flash.sh with “sugar on top”.
Maybe you could provide a step-by-step logfile (similar to mine) on how you achieved to apply the fix. This gives me more room to discover the faulty bits. Thank you!
Use command “dmesg |grep dts” and you will find out the device tree name.
Modify the corresponding dtb file as you find out from (1).
As for “step-by-step” guide you want, I am not sure if you can understand because many users on jetson nano only work with sdcard image and don’t know how to use flash.sh.
You can just put the dtb to Linux_for_Tegra/kernel/dtb and run the command
sudo ./flash.sh -r -k DTB < board _ name > mmcblk0p1
As for the “board_name” here, you can check the quick start guide.
I used dtc -I dtb -O dts tegra210-p3448-0000-p3449-0000-b00.dtb to read the device tree derived from kernel compilation. It says
...
pcie@1003000 {
...
iommus = <0x30 0x0>;
iommu-map = <0x0 0x30 0x0 0x1000>;
iommu-map-mask = <0x0>;
I guess this means iommu is enabled in the dtb file. Which leads to the assumption, that the image creator ignores it. I will now flash according to your suggestion. Be back with results in a bit.