I am trying to connect a USB Mediatec WiFi adapter to my Jetson TX2 board. Jetson identifies the USB adapter and “lsusb” throws this message.
Bus 001 Device 006: ID 148f:7601 Ralink Technology, Corp. MT7601U Wireless Adapter
I connect the WiFi adapter to a 3.0 USB hub connected to the onboard 2.0 USB port. But no kernel module is loaded as “lsmod | grep 7601” does not return anything. My kernel version as returned by “uname -r” is 4.4.197-tegra. I tried compiling the drivers from the following:
But none of them worked. The compilation breaks with the following message.
scripts/basic/fixdep: 1: scripts/basic/fixdep: Syntax error: “(” unexpected
I can comfortably use this same adapter when it is attached to my laptop. How can I go about loading the driver?
Is your kernel the default kernel, or have you changed this? I was expecting uname -r to show “4.9.140-tegra”, but I see “4.9.197-tegra”. Perhaps an upgrade? I have an R32.4.3 install, which should be the most recent, and it has 4.9.140-tegra. The reason this is important is because the module has to be compiled against the same version of source code, and that code must also be configured to match the running system.
FYI, you can look at the L4T version via one of these:
head -n 1 /etc/nv_tegra_release
dpkg -l | grep 'nvida-l4t-core'
I was able to build that module against correctly configured full source (not that different than building against headers which are properly configured), but if you are using the wrong source to build against, it won’t help.
My bad. The version is 4.4.197-tegra and not 4.9.197-tegra.
head -n 1 /etc/nv_tegra_release returns
R28 (release), REVISION: 4.0, GCID: 21880956, BOARD: t186ref, EABI: aarch64, DATE: Fri Jul 10 17:40:54 UTC 2020
dpkg -l | grep 'nvida-l4t-core' does not return anything.
You are using a much older release (R28.4). The default kernel of R28.4 is 4.4.38, and so it seems you are using a non-NVIDIA kernel. Can you say more about how the kernel was installed and where your kernel source is from?
For reference, this is the R28.4 URL:
https://developer.nvidia.com/embedded/linux-tegra-r284
I used JetPack 3.3 and JetPack 3.3.3 (possibly). Here are some information which might be of your help. The L4T info using $ head -n 1 /etc/nv_tegra_release returned the following.
R28 (release), REVISION: 4.0, GCID: 21880956, BOARD: t186ref, EABI: aarch64, DATE: Fri Jul 10 17:40:54 UTC 2020
The cuDNN version using $ cat /usr/include/cudnn.h | grep CUDNN_MAJOR -A 2 reveals I have cuDNN v7.1.5. That possibly means i have
JetPack 3.3 L4T R28.2.1 cuDNN v7.1.5 TensorRT 4.0 GA YES
The SDKManager version is 1.0.0-5517. AFAIK no update was performed. linux-headers-4.4.197-tegra and linux-headers-4.4.0-190-generic headers were already present but I could not find kernel source corresponding to 4.4.197-tegra installable using apt . The closest kernel source available for installation using apt was linux-source-4.4.0. So I went ahead and installed it and tried to compile against it. And that is where is where I got stuck.
Something seems wrong here since you said “uname -r” is 4.4.197-tegra. The kernel release which came with R28.4 is 4.4.38, not 4.4.197. The “-tegra” suffix suggests this was built for a Jetson, but the version is off. Are you positive the kernel was not upgraded? This would account for some cases of not being able to build against certain source or header releases…basically, it is possible the headers and the source have version differences resulting in a compile error. I hesitate to answer without knowing why the kernel seems to be incorrect, but is otherwise functioning.
Do you see any errors from this command (you don’t need to list the results unless there is a fail):
sha1sum -c /etc/nv_tegra_release
NOTE: The exact 4.4.38 is available, but won’t help if the kernel is 4.4.197.
sha1sum -c /etc/nv_tegra_release had all OK. I am not sure if it was updated after installation or if it is possible to install an updated Ubuntu. So what are my options. Should I re-install Ubuntu again? If I do re-install, is there anything I should be careful about like version, etc. Before re-installing using SDKManager is it possible to check the kernel version being installed?
If you flash again you will have the correct kernel unless it has been replaced inside the flash software on your host PC which performs the flash. I am still very curious about how the different kernel release changed. Most of the time this would be a very manual process and be obvious it is occurring. I hesitate to tell you to just flash again, which would provide the expected kernel, but I am wondering if there is something going on which I don’t know about which prompted the 4.4.197 kernel.
Do you have the full source code available of the 4.4.197 kernel which is installed? You could still try compiling against that with the right tools, but the kernel would not be a “stock” or “mainline” kernel…it would have to be one adapted for the Jetsons. If you don’t have the source to that kernel, then you will probably have to flash and get the original kernel back. If you are lucky, then the kernel is still in “/boot” and the modules are still in “/lib/modules/” (what do you see with “ls” in “ls /boot” and “ls -ld /lib/modules/*`”?).
You can clone before you do something potentially destructive to what you have completed. However, the clone command was changing around R28.4 so it might take a couple of attempts (and definitely a lot of disk space on the host PC). Let me know if you are interested in cloning.
Hi linuxdev,
I have info to share. I will document the things I did. I want to flash my Jetson TX2 (P3301) board with Ubuntu 16.04 Tegra. So I decided to install JetPack 3.3 and got it from https://developer.nvidia.com/embedded/jetpack-3_3. The system requirement on the page specifies the following:
System Requirements
Host Platform Requirements:
- JetPack L4T 3.3 supports Ubuntu Linux x64 v16.04 on your host PC.
So I installed a fresh copy of Ubuntu x64 16.04 on my laptop and got a copy of JetPack 3.3 on my laptop. The Jetson 3.3 Component Manager shows the following information of interest:
Target - Jetson TX2/TX2i → Linux for Tegra Host Side Image Setup
Description: Sample root file system derived from Ubuntu 14.04 and NVIDIA Tegra Linux Driver Package to support development for Jetson TX2/TX2i Developer Kit
File System and OS - Install version 28.2.1
Drivers - Install version 28.2.1
Now when I log into my Jetson TX2 Ubuntu, I find x64 Ubuntu 18.04 tegra installed, something I do not want. But then I went ahead out of curiosity and have the following information:
"$ lsusb" → Bus 001 Device 004: ID 148f:7601 Ralink Technology, Corp. MT7601U Wireless Adapter
"$ uname -r" → 4.9.140-tegra
“$ lsmod | grep 7601” →
mt7601u 96478 0
mac80211 719792 1 mt7601u
cfg80211 589351 3 bcmdhd,mac80211,mt7601u
"$ head -n 1 /etc/nv_tegra_release" →
R32 (release), REVISION: 4.3, GCID: 21589087, BOARD: t186ref, EABI: aarch64, DATE: Fri Jun 26 04:34:27 UTC 2020
$ dpkg -l | grep 'nvida-l4t-core' → ii nvidia-l4t-core 32.4.3-20200625213407 arm64 NVIDIA Core Package
BTW, the USB Mediatec WiFi adapter is working properly.
Glad it is working. Sounds like you don’t need more work for this task, but if you are interested, read what follows as you mentioned something which sounds strange (and interesting to me…this is an issue I have not seen before for JetPack/SDKM, but have seen many times with other unrelated software running on a PC).
Although “uname -r” of 4.9.140-tegra is correct for R32.4.3, and is very recent, you said you used JetPack3.3. I suppose it is possible JetPack3.3 somehow got hold of a JetPack/SDKM 4.4 repository.json file, which would imply that JetPack3.3 is using JetPack4.4 content (repository.json is a file which gets updated frequently at the NVIDIA server and names URLs and package names). This seems unlikely though. If you happen to have both JetPack3.3 and JetPack4.4 installed on your host PC (perhaps via SDK Manager for the latter), then I could see the possibility that you are really running JetPack4.4 when you think it is 3.3.
You definitely have R32.4.3 installed on the Jetson, and it is easy to work with this even if we ignore how you ended up with R32.4.3 from JetPack3.3. However, do know that if you install optional components such as CUDA from mixed releases, then this will fail (the operating system won’t fail, but the optional components should not be allowed to install…CUDA from JetPack3.3 is quite different from JetPack4.4, and the two cannot be mixed…there is a strong dependency on the o/s version). If you always use JetPack4.4/SDKM, then this will never be a problem, but if you somehow do execute JetPack3.3 to install optional packages to the Jetson, then you could have a problem with the optional packages.
Note that if you have two executable files installed, the one which is found first in the search path is used. Perhaps you have tow JetPack or SDKM files installed, and got the 4.4 version.
In some cases the file to execute has its version in the name, and a symbolic link to a “generic” non-versioned file is created to act as a “default”. If you only had JetPack3.3 installed, then you might have a file with 3.3 in its name, plus a symbolic link to the same name less “3.3”; if you then installed a 4.4 version, then you would have both a 4.4 executable and a 3.3 executable, plus a new symbolic link without a version name pointing at 4.4. Executing the generic unversioned name would execute 4.4 despite thinking it is 3.3. I really don’t know if this is what is going on, but you might want to be suspicious of which JetPack you are really using in the future if something seems a bit off.