I am looking at debugging an existing device driver (toshiba,tc538743) as it doesn’t seem to be working properly (specifying data-lanes in device tree I think <4> works, but the documented <1 2 3 4> doesn’t.
I have made some custom changes, however this makes the driver loading unstable.
I am looking at a way of moving the drivers to a different location so they are not loaded at kernel boot time and I can manually load them at testing time from my alternative directory.
This is only while I debug and figure out what I am missing.
However, I am not sure if there is a yocto variable I can use that would allow me to essentially do the following in my bbappend file:
Since you are debugging a driver, I would like to suggest a different approach, if that is ok.
Involving Yocto in this debugging process might represent an unnecessary overhead on your workflow.
You could build the kernel and the kernel modules manually (Build From Source Code Documentation Overview | Toradex Developer Center) and replace them on the image you have already installed on the module. Of course, I recommend keeping them “close” to one another. For example: flash the Reference Multimedia Image from BSP 6.5.0 and build the kernel and modules from branch toradex_5.15-2.2.x-imx, which refers to BSP 6.5.0.
And, in your case, you can just move the related driver somewhere else, so it is not loaded by default.
After you figure out the modification that solves your issue, then you can build the complete image with the modification applied and the driver in the right place.
Let us know if this is helpful
Now, answering directly your question:
I am also not aware of such a variable to “misplace” a .ko file. If I ever need to do something like this, I would just move the file as you did.
What I am trying to achieve is not far off what you have proposed (I think).
However, I am using the yocto build so that I have an image that has the initial drivers built and moved to a different location, so they don’t automatically get loaded at boot time.
The image I build will also be deployed to a SoM that I don’t have direct access too and can only access via SSH. This SoM will also have a secure-boot implemented (so I am unable to change anything about the rootfs or u-boot once the device has been flashed).
After the image is deployed, I want to be able to apply my custom debug builds within a userfs and manually load them for testing (which will be built from the same source files on my local machine).
I guess what I am really looking for is “How does the deploy output path get generated?”. This would give me what I need to make the process more resilient.
At the moment the posted snippet appears to work, except for an error when creating the deploy image because the specified driver *.ko file does not exist (I assume because I am using the wrong path somewhere).
Hopefully that all makes sense.
I also have another layer I could use this same “dynamic path” for, if such a thing exists.
Also, my CI build environment uses a static string, which will break when version numbers and commit hashes change in the toradex-manifest repo.
As this build environment will need to run as long as possible without intervention, I was hoping for a more general solution.
Thanks for sharing more details about your use case.
To be honest, in order to debug something I usually try to not mix anything that is not essential: for example in your case secure boot, CI pipeline, Yocto…
If your goal is to debug the driver, putting all that stuff in the mix might make you invest quite some time on something that won’t help you to perform the task you need to perform.
I am saying this while keeping in mind that such debugging is a “one shot” task (although might take some time), which is not meant to be carried out from time to time. Right?
Being able to only access the module via SSH certainly slows you down when the goal is to debug kernel/drivers. But I understand that sometimes there is no other way.
This can for sure be done manually with no need to create an special image for it on Yocto.
You might want to consider getting help from some of Toradex partners, who might be able to unblock you regarding this driver. If you want, we can recommend you someone and make the introduction.
I understand that the setup is not ideal, but unfortunately that is not something within my power to change.
Sadly I don’t have the budget to get kitted out with SoM and Dev Kit and all the relevant proprietary components to have a local lab setup for me to test locally without the extra overhead.
However, I believe I have now found the information I need (after a fair amount of debugging).
For others that may stumble across this thread…
Each kernel module is actually packaged and looking at logs from do_rootfs tasks, it appears that kernel-module-tc358743-${KERNEL_VERSION} is the package name that gets “installed”.
You may also have noticed the use of ${KERNEL_VERSION}, which is the exact string I was looking for to identify where the kernel files are deployed.
The actual path they get put into is: ${nonarch_base_libdir}/modules/${KERNEL_VERSION}/kernel/.
I am now putting together a layer that can perform the relevant steps and testing to see if what I need to achieve will work.
At some point I may try to make it a generic layer, such that I can put on GitHub for others to use if needed.
