Steps to modify the kernel for TorizonCore

Technical Support
, , , ,
1

Hey, I need to activate one of the kernel var. 's (CONF_DEBUG*) in the V6.2 BSP. We rarely need to do this, but I did this a while back with the Zeus branch for bare metal.

I need the complete steps to set the var., build the kernel, then deploy it to Torizon. I couldn’t find the complete steps to do that. I’ve already bitbaked the 6.2 image, and now need to set the var. Your docs are great, but I just couldn’t piece it together.

  • I’ve used - $ bitbake -c menuconfig virtual/kernel to set the var., but then not sure the next best steps
    for Torizon
  • is this something we can do with just TorizonCore Builder?
  • also, on some host machines I get the error ‘Terminal gnome is supported but did not start’’ when trying to run the menuconfig command. The few answers I did find didn’t fix it.

Thanks in advance,
Dave

2

Greetings @buchmeister,

If you know what changes you need to perform to the Linux kernel then you can create a patch and apply that in Yocto during build-time. We have generic example of this here: Custom meta layers, recipes and images in Yocto Project (hello-world examples) | Toradex Developer Center

is this something we can do with just TorizonCore Builder?

No, TorizonCore Builder is not for modifying the Linux kernel itself.

Could I ask exactly what kind of modification you are trying to make to the Linux kernel and why you are trying to do this?

Best Regards,
Jeremias

3

We’re trying to track down some memory leaks in the kernel and I want to enable the kernel flag ‘CONFIG_DEBUG_KMEMLEAK=y’.

That’s it. So I don’t want to add custom layers or recipes or anything like that. Thanks for the link, hopefully it has the details I need to do this relatively simple thing.

Dave

4

So just to verify, does this link have everything I need to set this variable?

Dave

5

So just to verify, does this link have everything I need to set this variable?

Well it doesn’t spell out this exact scenario. But the general steps are there on how to create a patch or config file for out kernel and build it in Yocto. For a more “real” example you can see the recipe for our kernel recipe here: https://git.toradex.com/cgit/meta-toradex-nxp.git/tree/recipes-kernel/linux/linux-toradex_5.15-2.1.x.bb?h=kirkstone-6.x.y

In this recipe we add some PREEMPT RT related kernel configurations via the *.scc files defined in SRC_URI*. Basically you just need to provide a kernel fragment to the relevant kernel recipe’s SRC_URI to apply those kernel config options at build time.

Basically just create a *.cfg file like this: https://git.toradex.com/cgit/meta-toradex-nxp.git/tree/recipes-kernel/linux/linux-toradex-5.15-2.1.x/preempt-rt.cfg?h=kirkstone-6.x.y

Except with the kernel configs you want. Then add the name of this file to the SRC_URI of the relevant linux-toradex* recipe in Yocto. Then just build the image and it should apply your kernel config options listed in the fragment file.

We’re trying to track down some memory leaks in the kernel

Now with that said, what kind of memory leaks are you observing. Is it something on our side or something on your side?

Best Regards,
Jeremias

6

I followed your steps a few ways and was able to flash the module each time. But when I checked it, the var’s weren’t set (from the new cfg file, set in SRC_URI in recipe ‘linux-toradex_5.15-2.1.x.bb’.) -

CONFIG_DEBUG_KMEMLEAK is not set

What am I missing?

Also, to answer your question from before, we’re working on a project that uses an Apalis with a particular camera and (originally) the V5.7 BSP. Our stack is a variety of docker containers in the app. I’m now trying V6.2 because of some bugs in the changelog that were fixed.

A while back, we noticed the module either reset, rebooted, or the camera wedged (1-2 hours) when running a stress test on it. Then when running it under normal load (or even at idle, stack running), it stills reboots after a longer period of time.

We noticed kernel memory climbing over time. Typical suspects are gstreamer, the v4l2 api, other aspects of the stack, but can’t pinpoint it.

The kernel variable would help if I can set it.

thanks,
Dave

7

How exactly did you do the change?

I just did a quick test following the steps and I was able to build a TorizonCore image with this kernel option enabled:

$ zcat /proc/config.gz | grep CONFIG_DEBUG_KMEMLEAK
CONFIG_DEBUG_KMEMLEAK=y
CONFIG_DEBUG_KMEMLEAK_MEM_POOL_SIZE=16000
# CONFIG_DEBUG_KMEMLEAK_TEST is not set
# CONFIG_DEBUG_KMEMLEAK_DEFAULT_OFF is not set
CONFIG_DEBUG_KMEMLEAK_AUTO_SCAN=y

Best Regards,
Jeremias

8
  1. created file kmem-rt.cfg in folder ‘~/repofolder/layers/meta-toradex-nxp/recipes-kernel/linux/linux-toradex-5.15-2.1.x/’
  2. added ‘CONFIG_DEBUG_KMEMLEAK=y’ to that file
  3. up one folder, added 'file://kmem-rt.cfg ' to the end of SRC_URI in ‘linux-toradex_5.15-2.1.x.bb’
  4. re-ran ‘bitbake torizon-core-docker’ from build folder

Even tried creating and adding a .scc file specifying the .cfg file
like the others but no luck.

9

How exactly did you modify the the bb file? There are 2 SRC_URI entries in that file, adding to the 2nd one won’t do anything in your situation. All I did was create the *.cfg file and add it to the first SRC_URI in the bb file.

Best Regards,
Jeremias

10

That was it…I missed the first reference in the recipe. It would be great if these exact steps were added to the main docs. But thanks again for making my job easier!

Dave

11

Glad I was able to help clear things up. I hope you’re able to find your memory leak/issue.

Best Regards,
Jeremias