Approach to change some values in an intree kernel module

Hello everyone
What is the right approach to change some values in an intree kernel module or better: in the kernel module sources?

In Torizon CoreBuilder I can add modules and change device trees, add overlays.
In Yocto I can add intree modules via config. And much more.
Where can I find the sources that are compiled there?
Can I use a TorizonCore image as a basis in Yocto and then change the sources there?

Software summary
Bootloader:               U-Boot
Kernel version:           5.15.77-6.2.0+git.aa0ff7e3554e #1-TorizonCore SMP PREEMPT Wed Mar 29 15:33:40 UTC 2023
Kernel command line:      pci=nomsi root=LABEL=otaroot rootfstype=ext4 quiet logo.nologo vt.global_cursor_default=0 plymouth.ignore-serial-consoles splash fbcon=map:3 ostree=/ostree/boot.1/torizon/655dd71c0fb1c4888d18ca99a1a844f578673ac82a4e518c01703c92396a4cfe/0
Distro name:              NAME="TorizonCore"
Distro version:           VERSION_ID=6.2.0-build.2
Hostname:                 apalis-imx8-07202014

Hardware info
HW model:                 Toradex Apalis iMX8QM V1.1 on Apalis Ixora V1.2 Carrier Board
Toradex version:          0037 V1.1E
Serial number:            07202014
Processor arch:           aarch64

Best Regards,

Hi @gerko !

Currently, to deal with intree kernel modules (e.g. modify its source code), you need to use Yocto and build your customized TorizonCore from there.

But do you really need to change the source code? Isn’t it possible to use device tree bindings to the driver you need to use? Or maybe use the driver arguments? Reference: Passing Command Line Arguments to a Module

Best regards,

Hello @henrique.tx !

Yes that would be nice.
In my particular case, I don’t have that option.
Or do you see a way to temporarily change these values?:

TC 5.7 (LTS):

I need to send byte arrays larger than 2048 bytes.

My hope is that I can achieve that with the change.
But I have other cases:
For example, I would like to have more printf output from the kernel module during the development phase.

Best Regards …

Hi @gerko !

Could you please elaborate on how you are using the virtio_rpmsg_bus driver?

AFAIK, you should develop a driver “on top of that” for your use. You can check the examples in the same folder as virtio_rpmsg_bus.c. For example:

You can see from those examples how they send messages.

Best regards,

Hello @henrique.tx ,
I will test it with the original versions. Or better: the tty driver.
I can’t get the chardevice driver to run.
I’m currently running a modified PingPong module that gives me the following message in dmesg

 [  171.855222] es_rpmsg_device virtio3.rpmsg-openamp-demo-channel-1.-1.31: message is too big (2100)

Best regards,

Here is the result of the test with the TTY approach:
If I send a random array of digits from Linux side (length > 1500 bytes)
Out of the box I get in the M4 ‘PRINTF’s’

At some point the data stream is chopped up.

I tried to adjust the values in the NXP SDK example in the file:

The value RL_BUFFER_PAYLOAD_SIZE has no effect and if I reduce the value RL_BUFFER_COUNT the M4 firmware no longer starts correctly, or better: ‘virtio_rpmsg_bus virtio3: creating channel rpmsg-virtual-tty-channel-1 addr 0x1f’ no longer appears in the dmesg printout.

I don’t see any interfaces there to change the buffer size. You?

Best regards,

Hi @gerko !

I just found this thread on NXP forums:

Could you please try it as explained there?

Best regards,

Thank you,

Nice. ‘Swiss2’ confirms my experience exactly.
There I read again that the buffer sizes are compiled fix into the kernel.
It’s a shame because the RPMSG interface works very well. But only up to 256 bytes / transfer.
I would have to reassemble the split stream.
But that’s not a nice solution.

I’m afraid the only solution is in here:
Customize the Kernel

If there is no better solution, I have to live with it.

Best regards,

To bring this thread to an end

Based on this article I have a question:

Generally asked:
I edit the kernel driver source and recompile as above.
I integrate this kernel into a Linux package in Toradex Easy Installer format.

for example this one:

Can I then edit this further with the TorizonCore tools?
Specifically: TorizonCoreBuilder, VisualStudioCode extensions?

Best Regards

Hi @gerko!

The question here is how are you doing this? Are you using TorizonCore Builder to integrate it?

You can indeed use TorizonCore Builder to customize a ready-to-use TorizonCore image that you downloaded from Toradex or you built yourself using Yocto.

You can read more about TorizonCore Builder here:

Here is an idea of what you could do if you want to avoid using Yocto:

You can build your kernel module with the modification in the source file as you need and integrate the result into your image using TorizonCore Builder.

You must be aware of building the module in a way that is compatible with the kernel of the image. This is helpful here: Cross compiling a kernel module | embear GmbH

Best regards,

Exactly, that’s what I did.
Now i need help on how to insert this result in an TCB image.We are already working on this topic in a parallel thread.

best …

Hi @gerko !

The thread be this one?

Best regards,

Best regards

Gerald, if you need to use the “pci=nomsi” boot parameter, can you please report it to so we can try to fix future kernels to they don’t require that parameter? Please include the complete dmesg log and output of “sudo lspci -vv”.

Hi @bjorn_helgaas ,
My main concern is to adjust these variables.

or here

I can imagine why these values are fixed. But that’s another topic

Sorry, I confused things by asking a question unrelated to your original post. I can’t offer any help about the rpmsg driver variables.

My question is about the kernel command line shown in your original post:
Kernel command line: pci=nomsi ...

In general people should not have to use the “pci=nomsi” parameter, so I’m wondering why it’s needed in your case. If we can figure out why it’s needed, we may be able to change the kernel to do that automatically so the parameter is not needed any more.