Other than for CONFIG_LOCALVERSION this is a bad idea (I edit CONFIG_LOCALVERSION with vi). Start with the configuration of a stock running system via the “/proc/config.gz” file. Then use something like “make menuconfig” or “make nconfig”. The trouble seems to be that you enabled something with dependencies, and did not enable the dependencies (the editing tools would know about dependencies and add this for you).
linuxdev, hi,
let me first thank you for your patience and support.
Following is the step by step that I have applied to make the SATA driver a module:
- cd /usr/src/kernel/kernel-4.4/arch/arm64/configs/
- sudo gedit tegra18_defconfig modify manually the following lines:
- CONFIG_ATA=y
- CONFIG_SATA_AHCI=m
- CONFIG_SATA_AHCI_TEGRA=m
- cd /usr/src/kernel/kernel-4.4
- sudo make tegra18_defconfig
- cd /home/nvidia/buildjetsontx2kernel the following line compiles the kernel and stores the image in boot:
- sudo ./makeKernel.sh
- sudo modprobe ahci_tegra
The last line has failed with the symbols issue.
Regards.
I have not checked if those individual config items are allowed as module format. If those items are indeed allowed as a module, then there is still one hole it the procedure: Using a menu style editor would have enabled other dependencies needed for each feature…using gedit implies that any other required dependencies will not be added, and this will result in missing symbols.
The second fault is that unless you set CONFIG_LOCALVERSION to match the running kernel, then your module will be expected to be in a different location for a different kernel.
A third problem is that if CONFIG_ATA was just added (and probably this is not an issue, I’m just pointing out a concept), then the whole kernel has just changed and you should probably rebuild all of the modules (rather than just the one). I have not checked if this was already “y”, though I can’t imagine it isn’t.
As mentioned earlier, I have not studied what is in “makeKernel.sh”. I’ve seen lots of people use it, and it seems to have helped simplify life for many people (this is something which is needed, but I’ve never used it). On the other hand, the various releases have changed a lot and I don’t know if something might invalidate that on a recent release.
If you were to install a new kernel, and not just add a module, then I recommend against using tegra18_defconfig. I would recommend on an unmodified system getting a copy of “/proc/config.gz”. Save this, archive it, protect it. Make all your modifications from that (gunzip it and rename it “.config”, then put it in the build location root directory). “tegra18_defconfig” might or might not be the same as what you already have. In the early days this is what Jetsons shipped with…the “_defconfig”. This seems to have changed, although I have not verified it on every platform and release. Using the “/proc/config.gz” is an absolute guarantee of starting with a matching system. If there is a single “y” entry which differs between the two configs you are likely to have problems (not always, but chances go up significantly…it depends on dependencies).
The bottom line is that the module has a dependency for certain features. The existing kernel and module combination is missing one or more feature…think of “missing symbols” as “features needed but not implemented”. Get rid of gedit. Even if you use tegra18_defconfig you should make your changes with something like “make nconfig” or “make menuconfig”. And it is possible that when you make the one module you’ll see it enabled other modules…and in that case you’d need those modules to also be present.
Can you share the code of makeKernel.sh? Do you understand what does it do?
As I said previously, I guess this script only re-builds the kernel image… It doesn’t generate a new kernel module (ahci-tegra).
Even if it generates, you didn’t copy any new kernel module to your target device, did you?
Hi,
The makeKernel.sh compiles an image which is then copied manually to the boot directory. I was under the impression that the driver is linked within the image and on the modprobe invocation the driver is loaded into memory and linked dynamically to the kernel.
The kernel compilation is implemented on the target.
Regards.
makeKernel.sh.txt (1.35 KB)
Per checked the makeKernel.sh, it indeed rebuilt the image and modules.
However, those modules are not linked with your image. For example, pci driver on tegra is being built as modules, so only image update would not take any effect to pcie driver.
nvidia@tegra-ubuntu:/lib/modules/4.4.38-tegra/kernel/drivers/pci/host$ ls
pci-tegra.ko
nvidia@tegra-ubuntu:/lib/modules/4.4.38-tegra/kernel/drivers/pci/host$ lsmod
Module Size Used by
fuse 82192 3
ipt_MASQUERADE 2115 1
nf_nat_masquerade_ipv4 2931 1 ipt_MASQUERADE
iptable_nat 2285 1
nf_nat_ipv4 6554 1 iptable_nat
xt_addrtype 3298 2
iptable_filter 2119 1
ip_tables 18195 2 iptable_filter,iptable_nat
xt_conntrack 3423 1
nf_nat 16543 2 nf_nat_ipv4,nf_nat_masquerade_ipv4
br_netfilter 13413 0
overlay 33387 0
<b>pci_tegra 60038 0</b>
bluedroid_pm 11195 0
If I rmmod it…
nvidia@tegra-ubuntu:/lib/modules/4.4.38-tegra/kernel/drivers/pci/host$ lsmod
Module Size Used by
fuse 82192 3
ipt_MASQUERADE 2115 1
nf_nat_masquerade_ipv4 2931 1 ipt_MASQUERADE
iptable_nat 2285 1
nf_nat_ipv4 6554 1 iptable_nat
xt_addrtype 3298 2
iptable_filter 2119 1
ip_tables 18195 2 iptable_filter,iptable_nat
xt_conntrack 3423 1
nf_nat 16543 2 nf_nat_ipv4,nf_nat_masquerade_ipv4
br_netfilter 13413 0
overlay 33387 0
bluedroid_pm 11195 0
After rmmod, if I move this .ko file away…
nvidia@tegra-ubuntu:/lib/modules/4.4.38-tegra/kernel/drivers/pci/host$ sudo mv pci-tegra.ko ~/
nvidia@tegra-ubuntu:/lib/modules/4.4.38-tegra/kernel/drivers/pci/host$ ll
total 8
drwxrwxr-x 2 root root 4096 Jan 15 07:27 ./
drwxrwxr-x 3 root root 4096 Dec 13 06:33 ../
nvidia@tegra-ubuntu:/lib/modules/4.4.38-tegra/kernel/drivers/pci/host$ sudo modprobe pci_tegra
modprobe: ERROR: could not insert 'pci_tegra': Unknown symbol in module, or unknown parameter (see dmesg)
And if I move it back
nvidia@tegra-ubuntu:/lib/modules/4.4.38-tegra/kernel/drivers/pci/host$ sudo cp ~/pci-tegra.ko .
nvidia@tegra-ubuntu:/lib/modules/4.4.38-tegra/kernel/drivers/pci/host$ ll
total 784
drwxrwxr-x 2 root root 4096 Jan 15 07:28 ./
drwxrwxr-x 3 root root 4096 Dec 13 06:33 ../
-rw-r--r-- 1 root root 792958 Jan 15 07:28 pci-tegra.ko
nvidia@tegra-ubuntu:/lib/modules/4.4.38-tegra/kernel/drivers/pci/host$ sudo modprobe pci_tegra
nvidia@tegra-ubuntu:/lib/modules/4.4.38-tegra/kernel/drivers/pci/host$ lsmod
Module Size Used by
<b>pci_tegra 60038 0</b>
fuse 82192 3
ipt_MASQUERADE 2115 1
nf_nat_masquerade_ipv4 2931 1 ipt_MASQUERADE
iptable_nat 2285 1
nf_nat_ipv4 6554 1 iptable_nat
xt_addrtype 3298 2
iptable_filter 2119 1
ip_tables 18195 2 iptable_filter,iptable_nat
xt_conntrack 3423 1
nf_nat 16543 2 nf_nat_ipv4,nf_nat_masquerade_ipv4
br_netfilter 13413 0
overlay 33387 0
bluedroid_pm 11195 0
You have to make sure your driver is put under correct path of /lib/modules/
hi WayneWWW,
I have verified that the ACHI driver via the GUI interface per linuxdev’s proposal:
cd /usr/src/kernel/kernel-4.4
sudo make xconfig
The I compiled the system and saw the following, is it normal?:
INSTALL drivers/ata/ahci.ko
INSTALL drivers/ata/libahci.ko
INSTALL drivers/ata/libahci_platform.ko
INSTALL drivers/ata/tegra/ahci_tegra.ko
Once completed rebooted the system and yet I did not see the driver in the list lsmod
when tried to install the module
sudo modprobe ahci_tegra
I got the following indication:
dmesg: libahci: exports duplicate symbol ahci_check_ready (owned by kernel)
terminal: modprobe: ERROR: could not insert ‘ahci_tegra’: Exec format error
What am I doing wrong?
It looks like your kernel still has libahci and you built out another libahci.ko.
I am not sure the behavior of using menuconfig. Could you check the config files and share what is built as module and what is built as kernel image?
WayneWWW, hi,
The following files are in the /usr/src/kernel/kernel-4.4/arch/arm64/configs directory:
- defconfig
- tegra18_android_defconfig
- tegra18_defconfig
- tegra21_android_defconfig
- tegra21_defconfig
- tegra21_min_defconfig
- tegra_t186ref_gnu_linux_defconfig
- tegra_t186ref_gnu_linux_early_boot_defconfig
- tegra_t210ref_gnu_linux_defconfig
I have modified: tegra18_defconfig.
I uploaded the following:
- defconfig
- tegra18_defconfig
- tegra_t186ref_gnu_linux_defconfig
defconfig.txt (5.08 KB)
tegra18_defconfig.txt (15.2 KB)
tegra_t186ref_gnu_linux_defconfig.txt (15.3 KB)
tegra18_defconfig is the one that kernel image is using.
I see you’ve modified it to modules. Not sure why it does not work. I’ll try it on my side.
Are you sure you use the correct kernel image?
CONFIG_ATA=y
CONFIG_SATA_AHCI=m
CONFIG_SATA_AHCI_TEGRA=m
The image file under the boot directory is from today so I guess this is the file that was copied recently after compilation.
Hi igal.kroyter,
Please reference below steps and build again:
$ TEGRA_KERNEL_OUT=<outdir>
$ export CROSS_COMPILE=<crossbin>
$ cd /public_release/kernel/kernel-4.4
$ make ARCH=arm64 O=$TEGRA_KERNEL_OUT tegra18_defconfig
$ make ARCH=arm64 O=$TEGRA_KERNEL_OUT -j4
$ sudo make ARCH=arm64 O=$TEGRA_KERNEL_OUT modules_install INSTALL_MOD_PATH=Linux_for_Tegra/rootfs/
$ cd /<outdir>/Linux_for_Tegra/rootfs/
$ tar --owner root --group root -cjf kernel_supplements.tbz2 lib/modules
$ Replace kernel_supplements.tbz2 to Linux_for_Tegra/kernel/kernel_supplements.tbz2
$ Replace Image
$ Run "apply_binaries.sh"
$ Flash Image on TX2
After bootup, run $ sudo modprobe ahci_tegra and check lsmod.
carolyuu, hi,
thanks for the reply.
I understand that your solution is for compiling the kernel on an external machine, while I am using the target to compile the kernel. Is there a way to apply your way of compiling on a target machine or I have to use an external one?
WayneWWW, hi,
sorry for the inconvenience but the correct image was not in the boot directory. Now the correct image is in the boot directory and I can see the following modules when I lsmod:
...
ahci_tegra 17953 0
libahci_platform 9074 1 ahci_tegra
libahci 28515 2 libahci_platform,ahci_tegra
...
When I try to remove the module
sudo rmmod ahci_tegra
the terminal hangs.
Moreover during power sequence I see the following in dmesg:
[ 7.281355] tegra-ahci 3507000.ahci-sata: AHCI 0001.0301 32 slots 2 ports 3 Gbps 0x1 impl platform mode
[ 7.281361] tegra-ahci 3507000.ahci-sata: flags: 64bit ncq sntf pm led pmp pio slum part deso sadm apst
[ 7.283129] sdhci-tegra 3400000.sdhci: wakeup init done, cd_irq: 257
[ 7.283217] sdhci-tegra 3400000.sdhci: Client registration for eMC Successful
[ 7.283320] scsi host0: tegra_ahci
[ 7.293949] scsi host1: tegra_ahci
Any suggestions?
WayneWWW, hi,
any news on the issue?
Regards.
FYI, if you build natively on the Jetson, then this line would be edited:
sudo make ARCH=arm64 O=$TEGRA_KERNEL_OUT modules_install INSTALL_MOD_PATH=Linux_for_Tegra/rootfs/
It would instead become:
sudo make O=$TEGRA_KERNEL_OUT modules_install
(leave out install path and arch)
However, this will assume the “uname -r” does not change from the previous kernel (CONFIG_LOCALVERSION). The modules go to here, where the “uname -r” is determined from your build, but the installed kernel needs the same “uname -r” if you are going to reuse the original kernel:
/lib/modules/$(uname -r)/
Restated: Your kernel won’t see those modules if you don’t set up for the new kernel to have the same “uname -r”.
I think you could just modify the rules of modprobe to skip auto loading of your driver.
After that you could load the driver manually.
This should not be an issue specific to tegra. I think some external websites for linux may also have tutorial.
WayneWWW, hi,
I could not find the rules file for AHCI or SATA could you please point me to the correct rules file?