This is failing in user space, not kernel space. This means software running by a user is failing, and it isn’t directly the driver causing issue.
This is just a wild guess, but almost every wireless device has loadable firmware due to FCC regulations (or different authorities in different parts of the world). The gist is that if a wireless device goes to different countries with different laws, then you have to do one of the following:
Create different hardware for each region.
Create a method for the device to be programmed for correct behavior in that region (firmware).
No longer sell or distribute your product in those regions.
Pick a subset of behavior that is legal in all regions. Examples: Lower max power output, or using only radio frequencies available in all regions.
The firmware concept is a common practice. In the case of RF devices this is normally something that uploads into the device before it runs. This changes the API and/or ABI the software is using must comply with for user space to function correctly. I suspect that you also need the manufacturer’s firmware, but that is only speculation.
One interesting thing regarding firmware on wireless devices: Since this uploads into the device the firmware won’t care about the host computer’s o/s or architecture. If you find firmware for different platforms, then the result is the same for upload, and only the installation of where the software goes in order to be detected would differ. Research this exact device model at the manufacturer’s site, and find out if there is firmware. Any Linux firmware would work, and sometimes even firmware intended just for Windows will work on Linux if it can be made to upload to the device.
I think the kernel-building process I walked through could be wrong.
I’d like to make sure if the kernel building process is correct or not I’ve been through building the kernel driver.
Could you check the steps of how I build the kernel with me?
Basically, I followed this. (Obviously, the guide Nvidia offers is very well made but sometimes confusing for beginners like me)
Download public_sources.tbz2 file
Extract kernel_src.tbz2 file in the public_sources.tbz2 and use it as kernel source.
RT-patch with the command ./kernel-5.10/scripts/rt-patch.sh apply-patches
(I skipped the process for the cross-compiling because it is native compile for this time)
build the kernel source with the command ./nvbuild.sh -o $PWD/kernel_out
Copy the Sample root filesystem to rootfs directory of Driver Package.
Copy kernel_out/drivers/gpu/nvgpu/nvgpu.ko to Linux_for_Tegra/rootfs/usr/lib/modules/$(uname -r)/kernel/drivers/gpu/nvgpu/ in Driver Package.
Copy kernel_out/arch/arm64/boot/dts/nvidia/ to Linux_for_Tegra/kernel/dtb/ in Driver Package.
Copy kernel_out/arch/arm64/boot/Image to Linux_for_Tegra/kernel/Image in Driver Package.
Install the kernel modules (Which path should I execute this command on? and which path is proper for $TEGRA_KERNEL_OUT?) sudo make O=$TEGRA_KERNEL_OUT modules_install INSTALL_MOD_PATH=/Linux_for_Tegra/rootfs/
Copy kernel-5.10 directory and subdirectories in Kernel source to /usr/src/linux-headers-5.10.120-rt70/
Build the out-of-tree module. make -C /lib/modules/5.10.120-rt70/build M=/home/jetstream/Downloads/rtl8812au
These are my questions:
Is there anything wrong with the steps?
I saw the warning Module.symvers is missing. I found the Module.symvers file is in kernel/kernel_out which is output of nvbuild.sh and ./rootfs/usr/src/linux-headers-5.10.120-tegra-ubuntu20.04_aarch64/kernel-5.10/in the Driver Package. Should I copy one of them to kernel-5.10 or is there a different proper way?
Should I do tegra_defconfig or menuconfig before nvbuild.sh?
After the kernel building steps like above, Which directory should I use as -C for building out-of-tree driver? kernel-5.10 or kernel_out?
What L4T release are you using? Verify what the Jetson has via “head -n 1 /etc/nv_tegra_release”. L4T R35.x uses JetPack 5.x, and L4T 36.x uses JetPack 6.x (JetPack is just the front end to the flash software, but the release version of JP is tied to the L4T release; one can use the “sdkmanager --archived-versions” startup to pick earlier L4T releases on a newer JetPack). There are some major differences between L4T R35.x and 36.x.
Note that L4T R35.x is fairly standard over the years, and L4T R36.x is changed in how it works. R35.x needs the specific kernel source, whereas R36.x has the ability to work with other newer kernels (R36.x uses a mainline kernel). This doesn’t mean it isn’t useful to pick the exact same kernel source version before starting, but we need to know the L4T release before answering.
FYI, in R35.x and earlier one starts with build target “tegra_defconfig”. In R36.x I think this is dropped and the new target would be just “defconfig”. You would still have to deal with setting CONFIG_LOCALVERSION (which looks to me to be modified to be “-rt70”; this is ok, but it means you must build both kernel Image and modules).