Best practices for adding kernel-module recipes?

Technical Support
, , ,
1

There’s some long-winded background to this question, so here goes:

I’ve been preparing to integrate the Acontis EtherCAT stack in our Torizon builds. Naturally this seems to involve a kernel-module-atemsys recipe to provide a kernel-land shim to take over network interfaces, repurpose them for EtherCAT, and provide access for a userland EtherCAT stack.

My first try was to enable building the meta-toradex-bsp-common/recipes-kernel/kernel-module-atemsys/kernel-module-atemsys_1.3.08.bb recipe… but it fails to build. Turns out it’s trying to download a source .zip file from a software.acontis.com URL that now just forwards to their homepage. So that recipe should probably be reworked or removed.

Second try was to clone an Acontis-supplied metalayer from GitHub - acontis/meta-acontis: Yocto recipes for the atemsys kernel module. That supplies a single kernel-module-atemsys.bb recipe. If I rename it to a kernel-module-atemsys_1.4.33.bb, it builds, but… produces an error later:

ERROR: torizon-minimal-1.0-r0 do_rootfs: Unable to find package with name 'kernel-module-atemsys' in SPDX file /home/fschaefer/mc11-c1-linux/build/build-torizon-aquila-am69/deploy/spdx/by-hash/aquila_am69/sstate:kernel-module-atemsys:aquila_am69-tdx-linux:1.4.33:r0:aquila_am69:12:/kernel-module-atemsys-6.6.84-7.2.0-devel-g8bf00740f043.spdx.json

After some digging, I found that the build is actually producing two kernel-module-atemsys RPMs: one with the recipe version (but no file content), and another with an auto-generated version based on the kernel version and Torizon version (which contains the actual atemsys.ko). I’m guessing having two RPMs with the same package name confuses do_rootfs.

I’m pretty sure the first (empty) RPM is a byproduct of the recipe name itself, and the second one is a result of module.bbclass logic automatically splitting off .ko files into a separate kernel-module-… RPM. I’ve managed to move past this and get a working image build by simply renaming the kernel-module-atemsys_1.4.33.bb recipe to atemsys-mod_1.4.33.bb, but now I’m wondering what the recommended best practice is for this situation? Obviously the Acontis-supplied metalayer needs some modification.

2

Hi, I’m the Toradex AI Assistant.

I might make mistakes. Our support team will step in if needed. If I answered your question, please tick the “Solution” checkbox. For follow-up questions to me, please use @ToradexAI in your post.

Did you like my answer? :+1: :-1:

Hello! Thank you for your detailed explanation and for sharing your observations regarding the integration of the Acontis EtherCAT atemsys kernel module with Torizon. These are valuable insights, and I can help clarify the situation and suggest best practices for Yocto kernel module recipes, especially in the context of external modules like atemsys.

The Problem

What you observed is a typical artifact when integrating out-of-tree (external) kernel modules using Yocto/OpenEmbedded:

  • module.bbclass: This class splits the kernel modules into packages named kernel-module-<modulename>, where the version reflects the kernel version (e.g., kernel-module-atemsys-6.6.84-...).
  • Recipe Package: The recipe (kernel-module-atemsys_1.4.33.bb) defines a main package (kernel-module-atemsys), but unless you override do_install/do_compile logic, this main package might not include the module, resulting in an empty RPM. The real driver content ends up in the automatically split-off appropriately-versioned package.
  • do_rootfs confusion: With two similarly-named RPMs, OpenEmbedded’s rootfs logic can get confused if another package/image depends on the wrong variant (recipe-versioned instead of kernel-versioned package).

You observed that renaming the recipe (e.g., to atemsys-mod_1.4.33.bb) avoided this confusion, but that’s more of a workaround than a resolution.

Recommended Best Practice

  1. Use the Acontis meta-acontis Layer as a Base
    The acontis/meta-acontis layer is the preferred starting point, as you already found (How to Get Started).

  2. Leverage module.bbclass Packaging
    Accept that your main installable package will actually be named by Yocto as kernel-module-atemsys-<kernelver>-<machine>.

    • When adding the module to your image, depend on the versioned package, usually by using the variable ${KERNEL_MODULE_PACKAGE_NAME} in your IMAGE_INSTALL or via the list produced by module.bbclass.

  3. Avoid Double-Naming

    • You do not need (or want) to have your own primary package called kernel-module-atemsys. Let module.bbclass manage the packaging.
    • You can set ALLOW_EMPTY_${PN} = "1" or even make the main output package not installable if it’s not useful.

  4. Image Integration

    • In your image.bb file, include the kernel module by its versioned package name:
      IMAGE_INSTALL:append = " kernel-module-atemsys"
      or (if needing a specific version or machine),
      IMAGE_INSTALL:append = " kernel-module-atemsys-<kernelver>-<machinename>"
    • Typically, the kernel-module-<name> alias will suffice if machine/SDK versions align.

  5. Check your SPDX/package feeds

    • If your image build expects a specific package (e.g., kernel-module-atemsys), ensure your image recipe matches what Yocto emits for your recipe/kernel combo.
    • This sometimes requires inspecting the output of oe-pkgdata-util list-pkgs or checking the workdir for your module package name.

Additional Pointers

  • The now-obsolete Toradex recipe (for version 1.3.08) you first encountered should no longer be used, as you’ve identified (Acontis EtherCAT Demo).
  • For custom kernel modules, Toradex recommends following this documented pattern.

In Summary

  • Don’t rename the recipe to work around the double-package issue.
  • Use image dependency on the auto-generated kernel-module-atemsys package (or the precise version if needed).
  • Let Yocto handle the packages via module.bbclass.

You may need to tweak your recipes-kernel/kernel-module-atemsys_1.4.33.bb to ensure it plays well with the module.bbclass packaging, but sticking with standard kernel module recipe patterns ensures better long-term maintainability and compatibility.

References:

If you need an example recipe layout or more specifics for your .bb file, feel free to ask!

Best regards,
Toradex AI Assistant.

3

Hi @jarndraugr

It seems we have removed this recipe in newer versions of our layer. It’s obviously not enabled/tested by us in the current version so I’m not sure I would rely on it.

It seems your SPDX issue is already reported to the meta-acontis maintainers. The workaround listed there is to disable SPDX generation. Not ideal certainly, but it may get you past this.

It does not seem like the meta-acontis layer is terribly active and I don’t know anything about it or who maintains it. I don’t know why you would need to rename it unless you were explicitly trying to add it using the old name. But you are correct regarding the package naming related to kernel-modules.

What piece of meta-data is actually including this module? I would think that would need to be modified to match what the meta-acontis layer is providing.

Drew

4

Hi

Drew Moseley
Toradex

5

Hi Frank,

Just wanted to follow up here. Have you made any progress?

Drew

Drew Moseley
Toradex

6

Yes, I managed to get this to work (with SPDX generation) by renaming the recipe to atemsys-mod. So far it’s working fine with the Acontis EC master evaluation release.

7

For a newbie would you share some more details of your solution?
I understand about as far as the git clone meta-acontis
For Torizon Core Builder I guess I need to add something into the tcbuild.yaml to bring in the new kernel. Would that be under:
customization:
kernel:
modules:

Any help gratefully received