SSH connection break during installation of Debian With Weston Wayland Compositor docker container

I’m trying to install Debian With Weston Wayland Compositor as Docker container on Toradex Colibri iMX8QXP v1.0B SoM, following instructions from official web site.

I’m able to connect with system using SSH where TorizonCore 5.2.0-devel-202103+build.9 is installed (with Docker engine). When I ran command docker pull torizon/weston-vivante:$CT_TAG_WESTON_VIVANTE following instructions from the official web site downloading and installing Debian starts but after a while system suddenly reboot.

It is not possible to install Debian Weston as a Docker container.
Are you familiar with the problem or do you know what we are doing wrong?
How can we install Debian Weston as a Docker container on TorizonCore 5.2.0?

Greetings @kristian,

Could you please provide more details.

What is the output on the device after running docker pull torizon/weston-vivante:$CT_TAG_WESTON_VIVANTE?

Is there any output or anything on the device when the “sudden reboot” occurs?

Also why did you share a screenshot of Visual Studio Code? Is there some relevant information here?

Best Regards,

The output is informations about downloading something (suppose Debian Weston image). You can see in attached screenshot the output at the beginning of processing docker pull torizon/weston-vivante:$CT_TAG_WESTON_VIVANTE command.

I’m sharing screenshot of VS Code where I’m using Torizon extension to connect and communicate with iMX8QXP module. Connection is made through SSH and you can see terminal output of TorizonCore in VS Code.

The same thing happens when I connect to TorizonCore using system terminal emulator (linux/terminal or windows/putty) or even when I run docker pull command directly on TorizonCore (when display and keyboard is connected to the development board where iMX8QXP module is plugged).

How reliably can you reproduce this issue?

I just used my Colibri i.MX8QXP 1.0B with the same TorizonCore version, and I can’t reproduce this. I connect to the system with putty and run the same docker pull command and it just works for me.

Can you try other versions of TorizonCore? Like 5.1 or 5.3, I’m curious if this issue is tied to software version. Furthermore do you have other Colibri i.MX8QXP modules? If you do does the issue happen on those as well?

I’ll investigate further and see if anyone has seen this before please keep me updated with any new info you find out.

Best Regards,

It happens every time!
I tried with newer TorizonCore version (TorizonCore 5.3.0-devel-202106+build.14) and it’s the same.
Unfortunatelly, I only have one iMX8QXP module.

@jeremias.tx the end goal is to run .NET GUI (using .Net Core and Avalonia UI cross platform framework or .Net/Mono + Gtk#) application on i.MX8QXP 1.0B module.

If I understood everything correctly Toradex prefered way is to use TorizonCore operating system with Docker engine installed and then install suitable operating system as Docker container.

So we would like to try with Debian/Weston as Docker container and run our .Net/Avalonia app inside.

Now we are stuck on very first step… installing Debian/Weston container as I described. I will contact other colleges to test with other copies of i.MX8QXP 1.0B to see if only mine have described problems.

@jeremias.tx is idea of this application stack correct (TorizonCore → Weston as Docker container → .Net/Avalonia GUI app)?

Do you have idea what might cause the issue I described?

I have a theory of what the issue here could be. On the 1.0B version of the Colibri i.MX8X there can be possible issues with writing to the eMMC, which docker pull can cause. But first let’s test if this theory is actually true.

First on your module interrupt the boot process with a key press over serial console. This will give you access to the console prompt for U-Boot.

On the U-Boot console run this command: fuse read 0 765

If this returns all 0’s and only if it returns all 0’s run this command: (If you don’t get all 0’s from the above command let me know).

fuse prog 0 765 00983e91

After this try again, does this resolve your issue?

Best Regards,

For your use case overall this sounds fine, other customers have done similar application stacks. However I must suggest to not use Avalonia. We personally have done tests with Avalonia in the past and have found the performance on our hardware to be quite poor.

An alternative framework that we’ve been exploring and seems to perform better is Uno:

We’re working on further testing/documenting this but for now I give you this suggestion.

Best Regards,