• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 2 answers
  • Subscribers 101 subscribers
  • Views 303 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM67A: Linux Kernel Header Files to Compile .ko Modules

Hasan Halil
Prodigy 100 points

Part Number: AM67A
Other Parts Discussed in Thread: J722SXH01EVM,

Development Board: J722SXH01EVM
"uname -r" : 6.12.17-ti-00773-gcdcaeac783e3-dirty
image: tisdk-edgeai-image-j722s-evm.wic.xz

 



Hello,

I am working with the J722SXH01EVM evaluation board. This board uses the same processor as a custom embedded board currently under development, and I am testing and comparing certain properties between the two platforms.

I am using the following SD card image on the EVM:

  • tisdk-edgeai-image-j722s-evm.wic.xz (~1.04 GB),
    from Processor SDK Linux for AM67A → SD card image with Edge AI stack

To test additional external/attachment modules on the board, I need to build some out-of-tree kernel modules (.ko).

I attempted to compile the module sources directly on the development board, but the Linux kernel headers are not present in the filesystem.

My questions are:

  1. What is the recommended way to obtain the correct Linux kernel headers or kernel source for this image in order to compile kernel modules?

  2. Is it mandatory to use the Yocto SDK for building kernel modules?

  3. Is there an alternative method to compile kernel modules without installing the full Yocto SDK, as its size is quite large?

Any guidance or best-practice recommendations would be appreciated.

Thank you.

Best regards,
Hasan Halil

  • +1
    TI__Mastermind 19046 points

    Hello Hasan,

    Please see the Linux SDK for this [1]. The SDK installation will include the Linux kernel, and this should be where you build your .KO's by default. I don't expect those KO's to be build-able on the target

    No, using Yocto should not be required for this purpose. That is needed for the additional libraries and user-level software, applicatoins, utilities that go into the SDK. 

    [1] www.ti.com/.../PROCESSOR-SDK-AM67A

  • 0 in reply to Reese Grimsley
    Prodigy 100 points

    Hello,

    I am using the TI Processor SDK to build an out-of-tree kernel module named smifb2. I first followed the steps described in reference [1], and then attempted to compile the module using the command below:

    make -C "$SDK_KDIR" M="$PWD" ARCH=arm64 CROSS_COMPILE="$CROSS_COMPILE_64" modules

    Some parts of the module compile successfully, but during the final stage of the build process (modpost), I encounter unresolved symbol errors. The full error log is shown below:

    ============== 

    user@gem-user:~/smifb2-main$ make -C "$SDK_KDIR" M="$PWD" ARCH=arm64 CROSS_COMPILE="$CROSS_COMPILE_64" modules
    make: Entering directory '/home/user/ti-processor-sdk-linux-edgeai-j722s-evm-11_00_00_08/board-support/ti-linux-kernel-6.12.17+git-ti'
      MODPOST /home/user/smifb2-main/Module.symvers
    ERROR: modpost: "pci_save_state" [/home/user/smifb2-main/smifb.ko] undefined!
    ERROR: modpost: "free_irq" [/home/user/smifb2-main/smifb.ko] undefined!
    ERROR: modpost: "simple_attr_open" [/home/user/smifb2-main/smifb.ko] undefined!
    ERROR: modpost: "debugfs_attr_write" [/home/user/smifb2-main/smifb.ko] undefined!
    ERROR: modpost: "pci_enable_device" [/home/user/smifb2-main/smifb.ko] undefined!
    ERROR: modpost: "dma_buf_vmap" [/home/user/smifb2-main/smifb.ko] undefined!
    ERROR: modpost: "snd_ctl_add" [/home/user/smifb2-main/smifb.ko] undefined!
    ERROR: modpost: "snd_pcm_new" [/home/user/smifb2-main/smifb.ko] undefined!
    ERROR: modpost: "snprintf" [/home/user/smifb2-main/smifb.ko] undefined!
    ERROR: modpost: "snd_card_register" [/home/user/smifb2-main/smifb.ko] undefined!
    WARNING: modpost: suppressed 67 unresolved symbol warnings because there were too many)
    make[2]: *** [scripts/Makefile.modpost:145: /home/user/smifb2-main/Module.symvers] Error 1
    make[1]: *** [/home/user/ti-processor-sdk-linux-edgeai-j722s-evm-11_00_00_08/board-support/ti-linux-kernel-6.12.17+git-ti/Makefile:1884: modpost] Error 2
    make: *** [Makefile:224: __sub-make] Error 2
    make: Leaving directory '/home/user/ti-processor-sdk-linux-edgeai-j722s-evm-11_00_00_08/board-support/ti-linux-kernel-6.12.17+git-ti'
    ===============

    From the errors, it appears that several core kernel, PCI, DMA-BUF, debugfs, and ALSA symbols are not being resolved during modpost.

    What is the correct way to resolve these missing symbols when building an out-of-tree module with the TI Processor SDK?
    Do I need to enable additional kernel configuration options, rebuild the kernel with specific subsystems enabled, or provide a matching Module.symvers file?

    Any guidance would be appreciated.

    Best regards,
    Hasan Halil

  • 0 in reply to Hasan Halil
    TI__Guru**** 179301 points

    Hi Hasan,

    Hasan Halil said:
    make -C "$SDK_KDIR" M="$PWD" ARCH=arm64 CROSS_COMPILE="$CROSS_COMPILE_64" modules

    At least prior running this command, you need to run command 'make linux' from the AM67A SDK top level directory. This command compiles the SDK kernel first, which is needed for compiling any off-tree kernel modules.

  • 0 in reply to Bin Liu
    Prodigy 100 points

    Hi,

    Below are the steps I followed before compiling the smifb2 kernel module. ( kernel related steps are from Processor SDK for J722S » 3. Foundational Components » 3.2. Kernel » 3.2.1. Users Guide)

    1) installed the required host dependencies.

    2) set the cross-compiler paths to the toolchains packaged with the Processor SDK.

    3) cleaned the kernel sources:
    make ARCH=arm64 CROSS_COMPILE="$CROSS_COMPILE_64" distclean

    4) applied the default kernel configuration:
    make ARCH=arm64 CROSS_COMPILE="$CROSS_COMPILE_64" defconfig ti_arm64_prune.config

    5) compiled the kernel image:
    make ARCH=arm64 CROSS_COMPILE="$CROSS_COMPILE_64" Image

    6) compiled the device tree binaries:
    make DTC_FLAGS=-@ ARCH=arm64 CROSS_COMPILE="$CROSS_COMPILE_64" ti/k3-j722s-evm.dtb

    7) compiled the kernel modules:
    make ARCH=arm64 CROSS_COMPILE="$CROSS_COMPILE_64" modules

    8) compiled the smifb2 out-of-tree kernel module:
    make -C "$SDK_KDIR" M="$PWD" ARCH=arm64 CROSS_COMPILE="$CROSS_COMPILE_64" modules

    The output is the same as in my previous message, showing unresolved symbols during modpost.

    Do I still need to run make linux, even though I have already completed all the steps above?

  • 0 in reply to Hasan Halil
    TI__Guru**** 179301 points

    Hi Hasan,

    Hasan Halil said:
    ERROR: modpost: "pci_save_state" [/home/user/smifb2-main/smifb.ko] undefined!

    Using this error message as an example,

    pci_save_state() is in drivers/pci/pci.c, which is controlled by CONFIG_PCI kernel config option as shown in drivers/pci/Makefile.

    Please check the kernel .config file to see if CONFIG_PCI is enabled. If not you would have to enable all the kernel config options which are required by your off-tree kernel modules.

  • 0 in reply to Bin Liu
    Prodigy 100 points

    Hi,

    I have attached my kernel .config file.
    Several symbols referenced by the enabled .config options remain unresolved during the build, resulting in a large number of unresolved symbol errors.

    Could this be related to a configuration or dependency binding issue during the compilation process?  
    I verified that PCI-related options (e.g., CONFIG_PCI) are enabled, but the errors persist.

    For reference, I have also shared the complete .config file.


    3583.config_file.txt

  • 0 in reply to Hasan Halil
    TI__Guru**** 179301 points
    Hasan Halil said:
    Several symbols referenced by the enabled .config options remain unresolved during the build, resulting in a large number of unresolved symbol errors.

    I need to see the build log to understand the description.

    Hasan Halil said:
    Could this be related to a configuration or dependency binding issue during the compilation process?  

    As long as the option CONFIG_PCI was enabled in 'make menuconfig', the dependencies should be automatically resolved in the newly generated .config.