We are aiming for using Docker version 20.10 and the apalis iMX8.
We have decided to try using TorizonCore for the project.
I checked the monthtly release of TorizonCore 6.1.0 which seems to have updated Docker to 20.10.12. But it does not seem that apalis iMX8 is supported for this release?
I tried using the images of the nightly builds 97 and 99 of TorizonCore 6.1.0, which states to support apalis iMX8.
When I reboot after using those builds this is the output I get no response from the serial console:
Is there any working combination that could get us Docker version 20.10 using TorizonCore prebuilt images and Apalis iMX8?
edit: removed wrong serial output. It was only remains.
Currently the state of the Apalis i.MX8 on our 6.X.Y software is very much a “work in progress”. The team is working on stabilizing things and hopes to have this hardware working by the next 6.1.0 quarterly release. Which is planned for the start of the next quarter.
All that said, we don’t currently have a working TorizonCore image with that version of Docker quite just yet.
Out of curiosity why are you seeking to use specifically Docker version 20.10?
The primary reason for requiring Docker 20.10 is that docker compose in earlier versions does not support all functionality that we need, especially when it comes to real time support.
I am not sure what Docker version would be the first to support it, but for certain version 19 does not.
Would there be any possibility that TorizonCore 5 can get a released image with updated Docker version?
support all functionality that we need, especially when it comes to real time support.
Interesting, specifically what kind of real-time functionality are you interested in? I assume you already checked and compared the functionality between Docker 20.10 and Docker 19 to determine whether it was supported.
Would there be any possibility that TorizonCore 5 can get a released image with updated Docker version?
Unfortunately this would be highly unlikely. TorizonCore 5 has already culminated in the 5.7.0 LTS release. Any future releases for this would only be bug fixes (i.e. 5.7.1, 5.7.2… etc). Updating the Docker version does not really count as a bug fix for these purposes.
At the moment the best options would be to wait for a stabilized TorizonCore 6 release for Apalis i.MX8. What does your timeline for your project look like here?
It is an end-customer requirement, so I actually not sure exactly what real-time functionality is required. I only know the requirement is that we need to include Docker 20.10 or later and docker compose 2.12.2 or later.
I played around and managed to build torizon with Docker 20.10 by only changing PREFERRRED_PROVIDER_virtual/docker from “docker-ce” to “docker-moby” in meta-toradex-torizon/conf/distro/include/torizon.inc and doing bitbake torizon-core-docker.
My main thought that I could just change this in a conf file in a custom layer, but I cannot get it to work. If I change to a soft setting in meta-toradex-torizon (i.e. PREFERRED_PROVIDER_virtual/docker ?! "docker-ce" , then I can make it work by setting it in my own layer (with PREFERRED_PROVIDER_virtual/docker = "docker-moby".
Is there any chance the meta-toradex-torizon can be patched to a soft setting?
Is there any chance the meta-toradex-torizon can be patched to a soft setting?
It’s unlikely we will do this in our 5.7 build, we set it to a hard assignment due to past issues/ambiguity. Most of the assignments in our Distro conf file are hard assignments as they’re not really meant to be changed in the context of building the Torizon distro. Changing these would basically be making a new distro.
You should be able to override this in local.conf, I believe that has a higher priority than distro configuration files. Alternatively, If it makes sense, you can create a new distro conf file and inherit the original distro conf file using “require” and then override stuff. Or, a brute force mechanism to override the complete conf file is to create a new conf file with the same name inside the custom layer, and setting the layer priority of the custom layer higher than the layer containing the original conf file.