Imx8mp Portainer and recovery mode

Technical Support
, , ,
1

I have a Verdin IMX8MP on a Dahlia carrier board. I had initially installed the base OS via the EasyInstaller picking the one with the sample containers. Everything was working fine and I could get to the Portainer container to manage the example containers.

I then removed the example containers, leaving the Portainer one and now when I reboot the device, linux starts as does the Portainer container. I can SSH into the board and see the container running, but when I try to go to the Portainer web page, my host browser can’t connect.

Connecting a keyboard and display directly to the Dahlia board, I can see the device boot, but it goes to a dark purple screen and the Portainer logon screen does not show. I can still SSH into the board, but that is it.

I tried to put the board into recover mode multiple times, in the hope of running EasyInstaller again but I get an error running the recover script as follows:

Downloading Toradex Easy Installer...
[sudo] password for parallels: 
./recovery/uuu: 1: Syntax error: "|" unexpected

Downloading Toradex Easy Installer failed...

Not sure what to do at this point to get the board back up and running.

UPDATE: It looks like I removed the wrong container… Looking at another board that is working, the running container is portainer/portainer-ce. On the board that is giving me problems, the container is torizon/weston-vivante. So the real question then is… can I reinstall and run the Portainer container to the board without having to reflash it with the EasyInstaller?

UPDATE 2: I found where the docker-compose.yml file exists in /var/sota/storage/docker-compse and tried running docker-compose up --build but I get the following errors:

docker-compose-kiosk-1      | [1:42:0821/174314.657476:ERROR:bus.cc(397)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
docker-compose-kiosk-1      | [1:42:0821/174314.657580:ERROR:bus.cc(397)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
docker-compose-kiosk-1      | [1:42:0821/174314.773134:ERROR:bus.cc(397)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
docker-compose-kiosk-1      | [1:42:0821/174314.773248:ERROR:bus.cc(397)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
docker-compose-kiosk-1      | [1:1:0821/174314.884502:ERROR:cursor_loader.cc(116)] Failed to load a platform cursor of type kNull
docker-compose-kiosk-1      | [1:97:0821/174315.091471:ERROR:object_proxy.cc(623)] Failed to call method: org.freedesktop.DBus.Properties.Get: object_path= /org/freedesktop/UPower: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.UPower was not provided by any .service files
docker-compose-kiosk-1      | [1:97:0821/174315.093521:ERROR:object_proxy.cc(623)] Failed to call method: org.freedesktop.UPower.GetDisplayDevice: object_path= /org/freedesktop/UPower: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.UPower was not provided by any .service files
docker-compose-kiosk-1      | [1:97:0821/174315.099424:ERROR:object_proxy.cc(623)] Failed to call method: org.freedesktop.UPower.EnumerateDevices: object_path= /org/freedesktop/UPower: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.UPower was not provided by any .service files

As you can tell, I don’t know what I am doing…LOL… but hoping I can get the containers rebuilt and the board back to running status.

2

Greetings @Glitch,

First of all let’s just re-flash your device and get it back into a known good state since it seems you’ve done a lot of things to this device.

I tried to put the board into recover mode multiple times, in the hope of running EasyInstaller again but I get an error running the recover script as follows:

You’re not running the right recovery script here. Please following the instructions on this article carefully, and make sure you execute the right recovery script for your host machine: Loading Toradex Easy Installer | Toradex Developer Center

Once you’ve done this and successfully re-flashed your device. I would suggest not doing things until you understand what you’re doing and the effect it will have. For example why were you trying to remove the example containers like this? What are you trying to achieve here?

Best Regards,
Jeremias

3

Thanks for the reply @jeremias.tx. So the document link you provided is the one I am using. I have the Verdin iMX8M Plus and the download is 5.7.4-devel-20230820+build.490. When expanding this zip, I have two recovery files, one for windows and one for linux. I am running the recovery-linux.sh. I repeated all the steps and I end up with the same error:

./recovery/uuu: 1: Syntax error: "|" unexpected

I have also tried the USB-stick route, but it’s not working really either. The documentation for that method seems to be missing steps.

I am running the above on Ubuntu 20.04 for ARM, so I am not sure if that might be an issue.

4

Ok, so I am pretty frustrated with these boards at the moment. Nothing seems to be behaving like the documents claim. I got the board to boot into the serial console following this guide…

This is the dump to the console:

U-Boot 2022.04-6.3.0+git.c71ae7141f30 (Jan 01 1970 - 00:00:00 +0000)

CPU:   i.MX8MP[8] rev1.1 1600 MHz (running at 1200 MHz)
CPU:   Industrial temperature grade (-40C to 105C) at 30C
Reset cause: POR
DRAM:  4 GiB
Core:  89 devices, 23 uclasses, devicetree: separate
WDT:   Started watchdog@30280000 with servicing (60s timeout)
MMC:   FSL_SDHC: 1, FSL_SDHC: 2
Loading Environment from MMC… OK
In:    serial@30880000
Out:   serial@30880000
Err:   serial@30880000
Model: Toradex 0058 Verdin iMX8M Plus Quad 4GB WB IT V1.1A
Serial#: 15006541
Carrier: Toradex Dahlia V1.1C, Serial# 11080110
SEC0:  RNG instantiated

 BuildInfo:
  - ATF 3c1583b

I stop the boot process as described and get to the # prompt and run the run bootcmd_usb0 as shown in the guide. What I get is this…

Verdin iMX8MP # run bootcmd_usb0
starting USB…
Bus usb@38100000: Register 2000140 NbrPorts 2
Starting the controller
USB XHCI 1.10
Bus usb@38200000: Register 2000140 NbrPorts 2
Starting the controller
USB XHCI 1.10
scanning bus usb@38100000 for devices… 1 USB Device(s) found
scanning bus usb@38200000 for devices… 1 USB Device(s) found
       scanning usb for storage devices… 0 Storage Device(s) found

Device 0: unknown device
Verdin iMX8MP # 

Device 0: unknown device
Verdin iMX8MP #

The USB drive I have is formatted FAT32 and has the expanded Verdin-iMX8MP_ToradexEasyInstaller_5.7.3+build.17 and I renamed the boot-tezi.scr file to boot.scr

There is no reason that this method should not work as shown in the guide, unless there is something different with my board.

5

I have the Verdin iMX8M Plus and the download is 5.7.4-devel-20230820+build.490. When expanding this zip, I have two recovery files, one for windows and one for linux. I am running the recovery-linux.sh. I repeated all the steps and I end up with the same error:

I just tried this on my Ubuntu 22.04 (not ARM however), and it worked for me. I checked the status of the ./recovery/uuu executable that gets called by the recovery script. It seems to be an 64-bit x86 based executable. If that is the case then perhaps that’s the issue here. Do you have another non-ARM PC you could run this on?

Ok, so I am pretty frustrated with these boards at the moment. Nothing seems to be behaving like the documents claim. I got the board to boot into the serial console following this guide…

That article you’re referencing does state:

This article describes an alternative method, not supported by Toradex officially, as we technically cannot guarantee that this works all the time and also across different versions.

So this not working isn’t unexpected, for this reason. I would recommend sticking with the officially supported recovery method, assuming you can get an x86 PC to execute the recovery script.

Best Regards,
Jeremias

6

@jeremias.tx thanks again for the response and the help. I think it’s most likely the ARM vs X86 issue. If I had known that literally non of the development tools supported ARM, I would not have made the decision to purchase the boards. I can’t even use the VSCODE plugins because of that. ARM has been around for a long time and why the industry is still depending on cross compiles is a mystery to me.

Anyway, from the USB stick perspective, the documents don’t mention that the stick needs to be inserted into the other USB-C port. Once I did that, I got the following:

scanning bus usb@38100000 for devices… 2 USB Device(s) found
scanning bus usb@38200000 for devices… 1 USB Device(s) found
       scanning usb for storage devices… 1 Storage Device(s) found

Device 0: Vendor:  USB Rev: 1.00 Prod:  SanDisk 3.2Gen1
            Type: Removable Hard Disk
            Capacity: 117348.0 MB = 114.5 GB (240328704 x 512)
… is now current device
Verdin iMX8MP #

but it did not boot from the stick… so I am not sure what is the issue there. Also, there may be something wrong with the board… when it does boot, I get the following message in the console…

Starting kernel …

[    1.023532] pca953x 3-0021: failed writing register
[    1.034327] clk: failed to reparent hsio_axi to sys_pll2_500m: -16
[    1.050793] clk: failed to reparent hsio_axi to sys_pll2_500m: -16
[    1.060326] clk: failed to reparent hsio_axi to sys_pll2_500m: -16
[    2.335106] +V3.3_SW: Underflow of regulator enable count
[    2.562584] [drm:drm_bridge_attach] *ERROR* failed to attach bridge /soc@0/bus@32c00000/mipi_dsi@32e60000 to encoder DSI-37: -517
[    2.574279] imx_sec_dsim_drv 32e60000.mipi_dsi: Failed to attach bridge: 32e60000.mipi_dsi
[    2.582548] imx_sec_dsim_drv 32e60000.mipi_dsi: failed to bind sec dsim bridge: -517
Starting version 250.5+
[    2.770498] [drm:drm_bridge_attach] *ERROR* failed to attach bridge /soc@0/bus@32c00000/mipi_dsi@32e60000 to encoder DSI-37: -517
[    2.782462] imx_sec_dsim_drv 32e60000.mipi_dsi: Failed to attach bridge: 32e60000.mipi_dsi
[    2.790762] imx_sec_dsim_drv 32e60000.mipi_dsi: failed to bind sec dsim bridge: -517
[    2.841108] [drm:drm_bridge_attach] *ERROR* failed to attach bridge /soc@0/bus@32c00000/mipi_dsi@32e60000 to encoder DSI-37: -517
[    2.852844] imx_sec_dsim_drv 32e60000.mipi_dsi: Failed to attach bridge: 32e60000.mipi_dsi
[    2.861156] imx_sec_dsim_drv 32e60000.mipi_dsi: failed to bind sec dsim bridge: -517
[    4.381804] [drm:drm_bridge_attach] *ERROR* failed to attach bridge /soc@0/bus@32c00000/mipi_dsi@32e60000 to encoder DSI-37: -517
[    4.394024] imx_sec_dsim_drv 32e60000.mipi_dsi: Failed to attach bridge: 32e60000.mipi_dsi
[    4.403137] imx_sec_dsim_drv 32e60000.mipi_dsi: failed to bind sec dsim bridge: -517
[    4.501848] [drm:drm_bridge_attach] *ERROR* failed to attach bridge /soc@0/bus@32c00000/mipi_dsi@32e60000 to encoder DSI-37: -517
[    4.524700] imx_sec_dsim_drv 32e60000.mipi_dsi: Failed to attach bridge: 32e60000.mipi_dsi
[    4.532996] imx_sec_dsim_drv 32e60000.mipi_dsi: failed to bind sec dsim bridge: -517
[    5.385900] [drm:drm_bridge_attach] *ERROR* failed to attach bridge /soc@0/bus@32c00000/mipi_dsi@32e60000 to encoder DSI-37: -517
[    5.397900] imx_sec_dsim_drv 32e60000.mipi_dsi: Failed to attach bridge: 32e60000.mipi_dsi
[    5.406676] imx_sec_dsim_drv 32e60000.mipi_dsi: failed to bind sec dsim bridge: -517
[    5.708691] [drm:drm_bridge_attach] *ERROR* failed to attach bridge /soc@0/bus@32c00000/mipi_dsi@32e60000 to encoder DSI-37: -517
[    5.724220] imx_sec_dsim_drv 32e60000.mipi_dsi: Failed to attach bridge: 32e60000.mipi_dsi
[    5.732524] imx_sec_dsim_drv 32e60000.mipi_dsi: failed to bind sec dsim bridge: -517
[    5.901136] [drm:drm_bridge_attach] *ERROR* failed to attach bridge /soc@0/bus@32c00000/mipi_dsi@32e60000 to encoder DSI-37: -517
[    5.914207] imx_sec_dsim_drv 32e60000.mipi_dsi: Failed to attach bridge: 32e60000.mipi_dsi
[    5.922527] imx_sec_dsim_drv 32e60000.mipi_dsi: failed to bind sec dsim bridge: -517
[    5.944734] [drm:drm_bridge_attach] *ERROR* failed to attach bridge /soc@0/bus@32c00000/mipi_dsi@32e60000 to encoder DSI-37: -517
[    5.944755] imx_sec_dsim_drv 32e60000.mipi_dsi: Failed to attach bridge: 32e60000.mipi_dsi
[    5.944761] imx_sec_dsim_drv 32e60000.mipi_dsi: failed to bind sec dsim bridge: -517
[    5.950051] [drm:drm_bridge_attach] *ERROR* failed to attach bridge /soc@0/bus@32c00000/mipi_dsi@32e60000 to encoder DSI-37: -517
[    5.950075] imx_sec_dsim_drv 32e60000.mipi_dsi: Failed to attach bridge: 32e60000.mipi_dsi
[    5.950081] imx_sec_dsim_drv 32e60000.mipi_dsi: failed to bind sec dsim bridge: -517

It’s showing an undercurrent. I am using the provided power supply. I will try the official method from an X86 PC and see what happens.

7

@jeremias.tx, thanks for the help. I did the recovery process from a windows X86 machine and it worked great, so I think the problem is the architecture. I did run into another problem, and that was with the board needing access to the Internet. I tried using the USB stick media method to allow EasyInstaller to find offline packages, but it did not work. The board kept throwing USB device errors. I finally fixed it by sharing my wifi connection with the internal network that the board is attached to and EasyInstaller was able to pull the content it needed from the Internet. So no back in business. I did no realize that the installed containers were dependent on each other. Will be more careful next time.

8

Glad you were able to recover your device back to a known good state.

I did run into another problem, and that was with the board needing access to the Internet.

Out of curiosity, did you not run into this issue the first time when you initially flashed the device?

Best Regards,
Jeremias

9

Well, when I first flashed the boards, I was doing it from a location where I could plug them directly into an internet connected cable modem. That network has no device security on it other than a standard firewall. So the boards just got an IP address via DHCP and everything just work.

This last board I had to configure in an office environment that does not allow devices to connect directly to an internet. Devices also have to be registered with the IT folks… so easy access to the Internet was not available.

10

I see, in any case glad you were able to get things back to a good state.