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
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)
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.
Gerald, if you need to use the “pci=nomsi” boot parameter, can you please report it to firstname.lastname@example.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.