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?
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
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.
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)
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’
I tried to adjust the values in the NXP SDK example in the file: ...SDK\boards\mekmimx8qm\multicore_examples\rpmsg_lite_str_echo_rtos\cm4_core1\rpmsg_config.h
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?
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.
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.
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.
Gerald, if you need to use the “pci=nomsi” boot parameter, can you please report it to linux-pci@vger.kernel.org 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”.
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.
