I’m having a bit of trouble with the Colibri and would like some advice and had a few questions: Our goal is to run a Svelte webapp on a screen with backend access to the filesystem, UART, etc. The webapp will run on either Tauri or Electron (preferably Tauri) and we have demoed both on a Raspberry Pi and now we want more control over the OS and dependency management. Additionally, we would like to use the Cortex-M co-processor, which was one of the reasons to go with the iMX8 line.
The first attempt to solve this problem was building a Linux OS using Yocto. I was able to get a Yocto instance with Weston built and booted with NodeJS and Rust, but had trouble getting a Weston based browser or Webview up and running.
The second attempt will be in TorizonCore using docker containers. Is there advice or a write-up on how to configure a container within TorizonCore to use Tauri or Electron? Should the toradex/chromium image be used as a base and everything gets installed to that? How would Tauri or Electron invoke the browser or webview? Should the toradex/debian container be used and toradex/chromium container be invoked?
I would also hoping to get some advice on the Apalis vs. Colibri. The Yocto process on the Colibri felt very constrained with the older Dunfell recipes and build tools. The Colibri iMX8X DualX was primarily picked as a low to middle cost way to see how difficult porting from a Raspberry Pi would be, and we are in no way tied to it other than as a test platform. Would a Yocto build with a display and webapp be easier on the Apalis line with the Kirkstone build tools?
The Toradex documentation was great once I knew what to look for and the community has been very helpful in getting this far. Many thanks to all so far!
Greetings @amcelroy,
I’ll try and answer your questions as best as I can.
The second attempt will be in TorizonCore using docker containers. Is there advice or a write-up on how to configure a container within TorizonCore to use Tauri or Electron? Should the toradex/chromium image be used as a base and everything gets installed to that? How would Tauri or Electron invoke the browser or webview? Should the toradex/debian container be used and toradex/chromium container be invoked?
I can’t guide you on the specific technologies/frameworks you listed as we have very little in-depth experience with those. Though in general you should be able to build whatever software you want in a container. A container is simply a way to package and distribute software. If the container can provide everything your application needs to run then I see no reason it wouldn’t work on a basic level.
As an example you might have seen the Portainer Web App/UI that boots on the TorizonCore with evaluation containers image. This already is somewhat similar to what you’re trying to do. To demonstrate this is an example docker-compose file that describes a few containers needed to bring this up: https://github.com/toradex/torizon-samples/blob/bullseye/debian-container/demonstration/docker-compose.arm64.yml
First we have the Weston container that brings up the basic graphical foundation on the system. Then there’s the Portainer container that is the web app itself, it broadcasts it’s contents to a particular port. This can then be displayed locally using the Chromium container which runs a local web browser. This is just a general example that is somewhat similar to what you’re trying to do it sounds like.
That said, you’re welcome to approach this anyway that you want, or is more fitting for your situation. You can start with our containers, or build your own from scratch, it really depends on what you need or want.
Would a Yocto build with a display and webapp be easier on the Apalis line with the Kirkstone build tools?
I’m not sure how you think this would be “easier”. In the end you’d still be dealing with Yocto and the workflow would be exactly the same. The only difference is you’re building for a different target module, and with Kirkstone the versions of things are more updated/different. But the process itself is more or less the same.
With all that said, it seems as though you’re still a bit unsure of what type of OS to go with. Whether it be Yocto-built or TorizonCore. Are you familiar with the differences/advantages between these two approaches?
Best Regards,
Jeremias
Thanks I will take a look at the Docker compose file to see if that helps tomorrow. Electron and Tauri open their own instance of Chromium or a Webview to interact with the backend; in Electron it is a NodeJS instance that launches a Chromium browser and in Tauri it is a Rust program. This might still be possible with the Chromium container and I will share the results either way.
It seemed with Yocto Dunfell recipes were missing, had errors, or that the recipes depended on X11 and that is at odds with getting Wayland / Weston working. I’m very new to Yocto, tuning Linux, and building a distribution and could very well have missed configuration steps since it is like drinking from a firehose the first time through.
Our team is far more used to a desktop or headless Linux distributions and thought that the Yocto route might prove more familiar compared to Docker, which we are still coming up to speed on. The TorizonCore FAQ was helpful, however, I would still appreciate some discussion on the pros and cons of TorizonCore vs. Yocto.
Thank you,
Austin
It seemed with Yocto Dunfell recipes were missing, had errors, or that the recipes depended on X11 and that is at odds with getting Wayland / Weston working. I’m very new to Yocto, tuning Linux, and building a distribution and could very well have missed configuration steps since it is like drinking from a firehose the first time through.
That sounds strange the reference images we provide should use a Wayland backend in their Yocto configurations. Did you start creating an image from scratch or did you start with our open source references?
however, I would still appreciate some discussion on the pros and cons of TorizonCore vs. Yocto.
You’re always welcome to ask more questions and we can help clarify things where we can. Or we can organize a call for a more focused and prolonged discussion.
Best Regards,
Jeremias
