We are developing a product using the Verdin IMX8m mini module. We want to use torizon core as it would help us to manage the application environment using containers and in future support the OTA.
We have multiple peripherals which we require for the target application. Most of the peripherals are already supported in the current nightly builds of the torizon or included as module. There are some others which are not.
For these module we would like to compile the Linux modules separately and load them on the device initially for testing.
For the first, as the vermagic changes I am unable to use the module. I tried fixing the local_version to get same vermagic but this seems to be risky and results in kernel hangs.
For the second way it fails to compile with following errors
WARNING: You are running bitbake under WSLv2, this works properly but you should optimize your VHDX file eventually to avoid running out of storage space
ERROR: /home/gaurav/complete/build/conf/../../layers/meta-toradex-torizon/recipes-images/images/torizon-core-podman.bb: No IMAGE_CMD defined for IMAGE_FSTYPES entry 'teziimg-distro' - possibly invalid type name or missing support class
ERROR: /home/gaurav/complete/build/conf/../../layers/meta-toradex-torizon/recipes-images/images/torizon-core-lite.bb: No IMAGE_CMD defined for IMAGE_FSTYPES entry 'teziimg-distro' - possibly invalid type name or missing support class
ERROR: /home/gaurav/complete/build/conf/../../layers/meta-toradex-torizon/recipes-images/images/torizon-core-docker.bb: No IMAGE_CMD defined for IMAGE_FSTYPES entry 'teziimg-distro' - possibly invalid type name or missing support class
ERROR: Failed to parse recipe: /home/gaurav/complete/build/conf/../../layers/meta-toradex-torizon/recipes-images/images/torizon-core-podman.bb
Summary: There was 1 WARNING message shown.
Summary: There were 4 ERROR messages shown, returning a non-zero exit code.
Now I have following questions:
Which one of these is the best way to include the additional modules?
For the first case how can I make sure to use the same kernel and configuration for compilation?
Does the commit id in the kernel version good enough?
Is it okay to get the /proc/config.gz and additional modules to this?
Please help with the error for second if you think that is a better choice.
First let me comment that including additional kernel modules via Yocto is the preferred way. As this is more reproducible and ensures that all versions of everything in the final image match up properly. I mean you can do the first method but you gotta match exact kernel commits and even then it can be messy.
Secondly, what are the additional kernel modules/configs you are trying to include? Are these available in tree in the linux kernel? Or are these your own companies kernel modules that are out of tree? The reason I ask is because if they are in tree modules we can review and possibly just include them into our default builds as long as there are no conflicts. We’ve done this for other customers before.
Now finally about your Yocto error. Hmm I see that you’re building this on a Windows machine in WSL2 correct? I will say I don’t think anyone here in Toradex has tried building our images in such an environment. Not saying that it won’t work but we’ve never verified or tested it. That all being said according to our recent tests builds internally none of them are failing in such a way as you are seeing here.
First of all when you repo init/synced the source layers did you do this based off of the dunfell-5.x.y branch with the default.xml? Or did you base it off some other branch/manifest? Next is this build a un-modified build or did you already perform some modifications to the layers here?
I faced a similar requirement to enable some kernel modules that were in the tree but not built by default. I solved it in my own meta-layer with a recipe like this:
In recipes-kernel/linux/linux-toradex_5.%.bbappend:
then in recipes-kernel/linux/files/fpga.cfg I added kernel config to enable the modules I needed:
# For RPMSG traffic to the M-4 cores
CONFIG_RPMSG_CHAR=m
This does require establishing the whole Yocto / torizon-core build environment and infrastructure, which is a bit of an effort and a fair learning curve, but seems well worth it for long-term stability, reproducibility and the reliability of ensuring kernel and module versions exactly match.
Thanks for the quick response and all the information.
First let me comment that including additional kernel modules via Yocto is the preferred way.
Thanks I was having the same feeling but just the concern was time for compilation.
Secondly, what are the additional
kernel modules/configs you are trying
to include? Are these available in
tree in the Linux kernel? Or are these
your own companies kernel modules that
are out of tree?
The device support is not available in the existing kernel and only get introduced in kernel v5.7. So I am compiling the publicly available Linux kernel.
Hmm I see that you’re building this on
a Windows machine in WSL2 correct?
Yes, but I will today try on Ubuntu directly.
First of all when you repo init/synced
the source layers did you do this
based off of the dunfell-5.x.y branch
with the default.xml? Or did you base
it off some other branch/manifest?
Next is this build a un-modified build
or did you already perform some
modifications to the layers here?
Yes I follow the steps in the document without any modifications anywhere.
Huh that’s odd, the default.xml should be based off of our November monthly release which should be a stable build. Did it fail in the same way as before? As for the PPP support for Network Manager I don’t think this has been brought up before but I can definitely inquire the team on your behalf.
The issue with the default.xml is same as in my initial post.
But with intergration.xml it fails due to some other reason which I feel could be due to filesystem.
@jeremias.tx Please check with the team and let me know if adding PPP support is possible. We don’t want to deviate from the base image a lot.
The issues you are seeing are really strange, we aren’t seeing any such issues on any of our test builds. What kind of environment do you have for your build machine?
With regards to PPP support, the team will review the request during the start of their next sprint. Though depending on the effort and other tasks it may not be worked on immediatley. Therefore for development purposes I’d suggest working on your own PPP integration for the time being. Also please correct me if I’m wrong I’m not too familiar with PPP, but would it suffice to just install this package in a Debian container and use it from there? Or is this something you need on the base OS itself?
Initially I was using windows wslv2 with Ubuntu 20.04.
The Network manager is already part of the base os. I want to use the network manager manage an modem which provides only serial interface over USB. The existing network manager does not seem to have the PPP plug-in enabled so I can’t use the network interface.
This should only be a bit off the current tip of the branch. This specific commit was used to build our November monthly so if this doesn’t work, then there’s something off about your environment or setup.
