How to build realtek card reader driver in jetsion xavier AGX with jetpack 5.0.2?

I tryo to add below items on Linux_for_Tegra\source\kernel\kernel-5.10\arch\arm\configs\tegra_defconfig
and try to build the relatek card reader driver
CONFIG_MISC_RTSX_PCI=y
CONFIG_MISC_RTSX_USB=y
CONFIG_MMC_REALTEK_PCI=y

but in ./config file I get

CONFIG_MISC_RTSX_PCI is not set

CONFIG_MISC_RTSX_USB is not set

I want to know how to enable it to build
below is my build script:
//-----------------------------------
#!/usr/bin/env bash
DIR=“$( cd “$( dirname “$0” )” && pwd )”
echo current path is $DIR
tool_chain_path=~/l4t-gcc3/aarch64–glibc–stable-final
#echo tool_chain_path is $tool_chain_path

if [ -d $tool_chain_path ]; then
# 目錄 /path/to/dir 存在
echo tool_chain_path is $tool_chain_path
else
# 目錄 /path/to/dir 不存在
echo “Directory $tool_chain_path does not exists.”
echo “copy to ~/l4t-gcc3 and install…”
mkdir ~/l4t-gcc3
cp -r $DIR/tool_chain/aarch64–glibc–stable-final.tar.gz ~/l4t-gcc3
cd ~/l4t-gcc3
tar xpf aarch64–glibc–stable-final.tar.gz
cd $DIR
echo " install Toolchain done."
fi

export CROSS_COMPILE=~/l4t-gcc3/bin/aarch64-buildroot-linux-gnu-
export LOCALVERSION=-tegra
if [ -d $DIR/out ]; then
rm -rf $DIR/out
fi
if [ -d $DIR/release ]; then
rm -rf $DIR/release
fi

mkdir $DIR/out
mkdir $DIR/release

TEGRA_KERNEL_OUT=$DIR/out
export KERNEL_OVERLAYS=$DIR/source/kernel/nvgpu:$DIR/source/kernel/nvidia
echo KERNEL_OVERLAYS = $KERNEL_OVERLAYS
pwd
cd $DIR/source/kernel/kernel-5.10
pwd

make ARCH=arm64 O=$TEGRA_KERNEL_OUT tegra_defconfig
make mrproper
make ARCH=arm64 O=$TEGRA_KERNEL_OUT -j8
echo “build done”
cd …/…/…/

#cp ./out/drivers/gpu/nvgpu/nvgpu.ko ./release
cp ./out/arch/arm64/boot/Image ./release
cp ./out/arch/arm64/boot/dts/nvidia/tegra194-p2888-0001-p2822-0000.dtb ./release

Remove the delete the TEGRA_KERNEL_OUT and rebuild it again to check.

I delete the TEGRA_KERNEL_OUT (out) folder and re-build it still got the .config file with below setting

CONFIG_MISC_RTSX_PCI is not set

CONFIG_MISC_RTSX_USB is not set

OOPS looks like you modify wrong configuration file it should be below file.

kernel/kernel-5.10/arch/arm64/configs/tegra_defconfig

yes,you are right ,I add the
CONFIG_MISC_RTSX=m
CONFIG_MISC_RTSX_PCI=m
CONFIG_MISC_RTSX_USB=m
CONFIG_MMC_REALTEK_PCI=m
in kernel/kernel-5.10/arch/arm64 /configs/tegra_defconfig can build the driver
and could you teach me how to enable it on jetson agx target device?
should I insmod someting?

Just some info which might help, although it isn’t directly an answer to your question…

Every kernel has a lot of “built-in” features (integrated features, e.g., drivers). Many of those can also be built as a module, and loaded/unloaded on demand. You’ve built these as a module, and that implies you have a file for each feature. I don’t know the particular drivers, but for example, you probably have some file ending in “.ko” for “MISC_RTSX”, another for “MISC_RTSX_PCI”, so on.

A kernel is what replies to the command “uname -r”. The prefix is the base kernel version, and the suffix is from CONFIG_LOCALVERSION. The usual suffix (the CONFIG_LOCALVERSION) is normally “-tegra”. For example, if you used kernel 4.9.140, then “uname -r” would likely answer “4.9.140-tegra”. If not, then some configuration was changed before kernel compile.

A kernel looks for its modules somewhere in “/lib/modules/$(uname -r)/kernel”. If you were to look at a particular kernel feature in the source tree, then the subdirectory of the module location would mirror where it is in the source code. This is just a contrived example, but let’s say you were looking at the “fuse” filesystem, specifically the feature producing “fuse.ko”. In the kernel source it is at “fs/fuse/”, and compile prodcues “fs/fuse/fuse.ko”. In the module directory example this is merely a file copy to this location:
/lib/modules/4.9.140-tegra/kernel/fs/fuse/fuse.ko

If you were to manually install this driver, then it would be a copy of “fuse.ko” to “/lib/modules/4.9.140-tegra/kernel/fs/fuse/fuse.ko”. You might reboot or run “sudo depmod -a” (or both), and perhaps “sudo modprobe fuse” for this example. There is no “enable” step, it is just a case of putting the driver in place and letting the system know modules were updated.

Note that if you don’t start with a properly configured kernel source, then there is a strong chance that module load would be refused with some error. However, that’s ok to experiment with. You don’t need to use flash tools or do anything risky to install a file…just copy any related driver “.ko” module files to the right location, “sudo depmod -a”, and either reboot or “sudo modprobe <module name without the .ko>”.

FYI, if you’ve set an empty directory location as the module output location during a kernel build step for installing modules, then you would get a mirror of the exact copy location used. For example, if you had created empty directory “~/modules”, and had built the kernel module “fuse.ko”, followed by saying to install to the alternate location, then all of the modules would be cleanly put into a mirror of your location. Example with “~/modules” empty:

# ...previous kernel setup done...build complete...
# Install to alternate location, might need other changes if cross compiling:
export TEGRA_MODULES_OUT=~/modules
make INSTALL_MOD_PATH=$TEGRA_MODULES_OUT modules_install
cd ~/modules
# Use ls, explore, note it has ~/modules/lib/modules/4.9.140-tegra/kernel

I don’t know which modules are produced by your particular configuration. Do be sure you’ve correctly set CONFIG_LOCALVERSION (there is more than one way to do this), and adjust the kernel version for what your actual release is. Monitor “dmesg --follow” during the “sudo depmod -a” and “sudo modprobe <driver name>” steps to see if errors are reported.

1 Like

ok,thank you

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