Is there any other WIFI chips compatible with Jetson NANO except for Intel WIFI 8265?

I know the Intel 8265 is compatible with Jetson NANO. But what I need is to get the (CIS) channel state information from the WIFI card, and It’s hard to get the CIS form 8265 with existing CIS tools. I find some CIS tools for Intel WIFI 5300 or other cards. Therefore, I wonder if is there any other WIFI card compatible with Jetson NANO.

I cannot directly answer that. There are things you can check though which point more or less to different products.

The first thing to know is that every WiFi device needs a device driver, which runs in the kernel. This kernel is a 4.x series Linux kernel, and it is 64-bit ARM (arm64/aarch64). So in the end, the very first thing you need to know is if there is a kernel driver for the 4.x kernel of 64-bit ARM. There are a few ways this can happen.

There is a huge amount of support for the source code of various drivers in the actual public domain kernel source. It might be though that the support is too new to have existed in a 4.x series kernel. However, if you know the kernel configuration “symbol”, then you can easily find out. Usually the symbol is something close to the driver name. The driver name itself is often related to the chipset (different packagers and brands might share the same chipset). As an example, check this out for the key word “Intel” (case-insensitive grep -i):
zcat /proc/config.gz | grep -i 'intel'

More interesting, check symbols with “wifi” (case-insensitve filtering again, though the symbols are all upper case):
zcat /proc/config.gz | grep -i 'wifi'

Note that a lot of those are symbols named with “IWLWIFI”, which I think is an Intel chipset “thing”.

If the source is available in the existing 4.x series kernel (to see your exact kernel, look at the prefix from “uname -r”), then you will have a driver.

Sometimes the driver is not built in to the source, but it is available. It is a bit more troublesome, but if that source is available and compatible with a 4.x series kernel, then it is highly likely (but not guaranteed) that you can use that driver. Often you can build the driver without actually having the hardware, so you can test that before purchasing.

The reason building your own driver from source matters is that you can produce it in any architecture you want. Even if everyone else uses this with a desktop PC (amd64/x86_64) you just have to compile it and you have one too.

If the manufacturer makes that driver in binary format only, then all of these have to work:

  • Has to be arm64/aarch64 (64-bit ARM).
  • Must be compatible with your running kernel. Sometimes that means adding other features which is not usually a problem if those features are available through public source for that version.
  • Must be compatible with your exact kernel version (similar to the previous note, but not exactly the same…one is about configuration, the other is about kernel version…the two work together).

The final problem is that you might need user space programs or tools sometimes. I say this because I don’t know about CIS tools. Are these available via the “apt-get” method from Ubuntu 18.04? If they are, then there is no issue. Are those tools available for 64-bit ARM, either via apt or from the manufacturer? I know nothing about the tools you are asking about. You have to have the kernel features (driver or symbol) before the user space program can function, although you could download and install the software without the driver or hardware just to see if it exists (it wouldn’t function though until you install the rest). Be careful though since some network software might try to configure your network in some special way you don’t expect.

Thank you so much. I’ll try your method to check it.

I would like to share you with my progress. My purpose is to extract the CSI information from the wifi card and use Jetson Nano to process the information. Therefore, I have two prerequisites, the first is I need to find a wifi card that can expose its CSI information with a certain CSI tool and the second is the driver of the wifi card is compatible with Jetson Nano.

For the first prerequisite, I found a complete Atheros CSI tool that had been tested well on several Atheros wifi cards. This list shows the Atheros cards which support this tool.

AR9590 has been tested well in this list, so I choose AR9590 for my program.

For the second prerequisite, AR9590’s driver is ath9k. ath9k is 64-bit ARM. I used the command you taught me on Jetson Nano to check if the ath9k driver is indeed present and configured in Jetson Nano :

zcat /proc/config.gz | grep -i ‘ath9k’

And the result is as follows:


CONFIG_ATH9K_AHB is not set





I can’t understand all of the results, but I think it indicated that ath9k is present and configured in Jetson Nano so the AR9590 is compatible with Jetson Nano, right? Please correct me if I misunderstand it.

And I notice that ‘CONFIG_ATH9K_PCI=y’, so for ath9k, PCIe is not supported on Jetson nano? But based on my understanding, Jetson Nano just has PCIe instead of PCI. So is it a typo? I’m confused about this. Can you help me with this?

Thank you so much!

8Devices makes Black Bean based off Atheros QCA9377. It is M.2 key A&E. BLACK bean - 8devices. Will it work? I don’t know. I am using Blue Bean in my design whose Kernel module has to be built.

Apparently it uses the ath10k driver
BLACK bean | 8devices Wiki
WiFi - Atheros ath10k driver support? - Jetson & Embedded Systems / Jetson TK1 - NVIDIA Developer Forums

The Atheros devices are quite common, and many brands sell Wi-Fi cards with that chipset. There is more than one variant, and so there is more than one possible feature for a given Wi-Fi card. I am not surprised if any Atheros is supported “out of the box” without a kernel build. It doesn’t mean Atheros won’t have its own bugs, it might, but chances are any such bug has been seen and worked on before.

Regarding PCI, this driver also covers PCIe. The protocol is still PCI, and when you mention PCIe, it only describes the physical interface (the “PHY”), but the software protocol is the same regardless of PHY. It is the PCI bus software which needs a driver to support either the traditional PHY or the PCIe PHY, and this is already in place. Note though that some m.2 cards actually use USB since some key types in m.2 have both PCI and USB (in which case the Wi-Fi card just wires to the part it wants to use; there might be some setup in device tree at times related to this). Quite often the same physical connector is just referred to as PCI even if it is PCIe, but if you see PCIe, it is just more specific to say both protocol and PHY (if you mean old style PCI, then someone will probably state that or it will be obvious from the content).

To know for certain before purchasing, you could look up all kernel config requirements, but in my case, since some base features are most likely to do the job, I’d just buy one and try it out (in reality you have to try one out anyway to know if it really works). I would say the odds of it working out of the box are high; and if not out of the box, then customizing the existing kernel configuration improves the odds a lot.

The part where you must be most careful is that m.2 has more than one key. The key is the notch in the connector. Some have multiple keys because they can work on two different keys (in which case they use the content in common with both keys or have some detection scheme). This talks about keys:

I don’t remember which keys are available on the Nano, but it will be either key E or key M (or both).

I could not tell you if those cards will work. If they have the right m.2 slot, and if they are an Atheros chipset, then odds are quite high that they will work, but it isn’t a guarantee without testing.

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