Hi @cheesi, have you tried what Stefan mentions here? Qemu usage - Technical Support - Toradex Community It applies for Vybrid rather than the iMX6 (which, for instance, doesn’t feat a RAW NAND flash but an eMMC), but it could be a good place to start.
Hi @alvaro.tx ! Thanks for your fast response. I already saw that thread, but as I’ m not familiar with any other Toradex Products except the Colibri iMX6, I didn’t want to spend time on something, that might not be available at all for my system.
I will give it try, please let me know, if you got any new information about this topic.
Also, what you can try is to generate an image specifically for QEMU, rather than having the iMX6 image adapted for QEMU.
Since our images are generated with the YoctoProject environment, this offers the possibility of building the image for a range of QEMU compatible machine. It won’t be exactly the same, but overall it wouldn’t be a bad approximation (but some hardware specific components won’t be the same), but if you want to test some software, it may be enough. In your local.conf file, select the MACHINE for your QEMU version.
We have a very extent documentation in our dev page in how to build your own Embedded Linux images with YoctoProject. Take into account this usually takes many hours even in a high end development machine if it’s your first build.
Today I tried to compile our customized image with MACHINE set to qemuarm. Unfortunately, qtbase failed to build because of a opengl error. This might be, because we inherited from console-tdx-image and removed x11 and wayland from the distro features.
I should have mentioned, that we use a 3,5" EDT Display and our application is written in Qt and using the eglfs driver, and of course, it would also be nice, if I could see the display output of a emulated linux image.
I will try the tutorial provided by @stefan.tx , but it seems, this would be a huge mammut project. Not sure, how we will proceed.
There has been some work recently adding OpenGL support with virtualized systems: https://virgil3d.github.io/ I am not sure if that works for emulated systems, since we deal with different architecture…
In the end your emulated system will be using different drivers etc. hence quite far away from the real thing… With that your testing might test complete different code path and not really be a useful test for the real world use case.