Not sure if this question belongs here or should be emailed to support but…
In easy installer there’s the choice for either TorizonCore or reference minimal/multimedia.
For TorizonCore, there’s a set of images based on Debian.
So is it possible to make something like a ‘reference debian’? Meaning the base debian like used in the docker image but being able to install it via easy installer (and without TorizonCore).
I tried exporting the image but then i’m missing the content of lib etc.
Greetings @Michielt,
Creating a Debian distribution that is tuned for our embedded devices, while technically possible, is not a simple task.
May I ask why you would like to run a Debian distribution? Is there something you’re seeking to do that can’t be done via Debian in a container?
Best Regards,
Jeremias
Oh, i thought there wasn’t much difference between knowing how to set up the container properly and building a ‘standalone’ setup, guess i was wrong.
Regarding the container vs no container, i’d like to keep things simpler. The minimal images are a boot partition a rootfs partition and that’s it. You know where the dts are kept and the kernel, so it’s easy to alter those. Network access is without any forwarding etc. Don’t get me wrong for a one-of version (build once and replicate) those reasons don’t apply, but in my use case where things change it does.
Now i’m not sure what to do with this thread, i got another one that turns out to ask the same thing (plus max14830 involvement).
I had Debian running fine till i started with that chip. Using the same kernel/modules (build with yocto using toradex git) work fine on a ‘reference image’ but not on Debian, so i must be doing something wrong and it’s probably a /lib issue given that the content is different. But i assumed all drivers etc were insides the built modules tar…
So didn’t have a clue where to start so given that a Toradex build Debian container exists, i assumed that i could start from that instead.
Maybe we can back up and discuss exactly what your objective/use-case here is.
I still don’t quite understand why you require a Debian based image here. Is there some requirement that only a pure non-container Debian can fulfill?
If it’s simplicity, then Torizon should also fulfill this need. Torizon is also essentially just a boot and rootfs partition with the dts and kernel in a known location (/boot/ostree/torizon-*/). The container is only where your application stack will live. Also if you don’t want to deal with the network forwarding of containers you can just run the container with the same network stack as the host (--net=host).
But if you really do desire a native Debian based image then you can still attempt this. Just keep in mind it will be difficult for us to support you on something that deviates so heavily from both Torizon and our references images.
Best Regards,
Jeremias
The use-case is a datalogger that can use up to 12 serial ports and will be mounted on a buoy at sea.
Containers are still new to me so i might be underestimating it. Haven’t been able to verify everything yet, because i couldn’t find the zImage (anywhere one /boot) to replace it with one that has the max310x driver enabled (the whole reason for this issue, got Debian working fine before).
Regarding the --net=host, I probably used the wrong searchterms because the best i could find was macvlan or something.
So i’ll check /boot again and read up on containers.
Just to clarify in Torizon the the Kernel binary isn’t named zImage. The binary will be named something like vmlinuz-* with the exact name depending on kernel version. Also in terms of modifying the kernel, simply replace the binary in the filesystem is not the most robust method and can be very error prone. While fine for quick tests the proper method would be to re-build the TorizonCore image with a custom kernel. More info on building TorizonCore here: Build TorizonCore from Source With Yocto Project/OpenEmbedded | Toradex Developer Center
Especially seeing as you’re looking to integrate a new Kernel module/driver.
Best Regards,
Jeremias
Ah, ok did find those files, but because u-boot was referring to zImage i thought that was something else…
But indeed, it’s just for testing.
Glad I was able to help clarify this.
