TOR-3399 | Feature Request | Enable kernel config option for "LED Multicolor Class Support" | All supported modules | Kernel | |
Description: Enable support for LED Multicolor Class Support on Torizon OS 6 |
TOR-3397 | Feature Request | As a user, I want ModemManager to try to connect to cellular network in infinite loop, so my product is resilient to intermittent connection drops in the field | Not applicable | Open Embedded | |
Description: ModemManager only retry connections 4 times by default. This may be an issue for unattended devices.
Learn how to set the retry value to infite on Modem Support - Set Cellular Connection Retries |
6.6.0-devel-202402 monthly pre-release |
TOR-3349 | New Feature | Support the SIMCom SIM7600 cellular modem on Torizon OS | Not applicable | Kernel, Open Embedded | |
Description: Enable kernel config for the SIM7600 modem on Torizon OS 6. |
6.3.0-devel-202305 monthly release |
TOR-2975 | New Feature | Enable support for the Microchip KSZ8795/KSZ88X3 switch chips on TorizonCore 6 (upstream kernel) | Apalis iMX6, Colibri iMX6, Colibri iMX6ULL, Colibri iMX7 | Kernel | |
Description: Enable the Microchip KSZ8795/KSZ88X3 switch IC device driver as a module on TorizonCore 6, for the upstream kernel. |
6.1.0-devel-202212 monthly pre-release |
TOR-2384 | New Feature | As a Platform Services customer, I want the gateway certificate updated on all my devices, so I continue connected after 2030 | Not applicable | Aktualizr, Open Embedded | |
Description: The gateway to which devices connect to access the platform is being updated, and with it, the new gateway certificate is being updated on TorizonCore. This should be transparent to all users of the Torizon Platform Services, as long as they update their devices to TorizonCore 6 or newer until 2030. |
TOR-2985 | Known Issue | `skip_fdt_overlays` isn't working in TorizonCore 5.7.2 and up | Not applicable | Device Tree | Low |
Description: `skip_fdt_overlays` isn't working in TorizonCore 5.7.2 and up. It is not planned to be fixed, since this feature is meant to be used during the development phase, and TorizonCore 5.7.2 and newer are maintenance releases for customers with devices on the field, past development.
If you need this feature, either use the documented workaround or migrate to Torizon OS 6. Workaround: Instead of stopping on U-Boot and entering:
# setenv skip_fdt_overlays 1
# boot
just run these commands below. With them we're already skipping the overlay loading and we'll be resizing the fdt region:
# setenv devtype mmc; setenv devnum 0; ext4load ${devtype} ${devnum}:1 ${loadaddr} /boot/loader/uEnv.txt; env import -t ${loadaddr} ${filesize}
# run set_fdt_path
# setenv bootcmd_dtb "load ${devtype} ${devnum}:${otaroot} ${fdt_addr_r} ${fdt_path}; fdt addr ${fdt_addr_r}; fdt resize 0x20000"
# run bootcmd_run |
TOR-2654 | Known Issue | Add, remove, and then re-add a secondary lead to the error “At least one ecu in EcuIdentifier was already used and removed for DeviceId and cannot be reused" | Not applicable | Aktualizr, Automated testing | Low |
Description: In the TorizonCore update system, each updateable component - the OS, the application described by a Docker Compose file, the bootloader, and possibly other components in the future - is registered as a new ECU when introduced to a new TorizonCore release. The ECU naming comes from the automotive industry, and in our case it can be interpreted as a component that can be updated alone.
Due to how the updates are implemented in TorizonCore, you cannot automatically - that is, without manual intervention - update the OS to a version that has a new ECU, downgrade to a version that does not have it, and then update again to a version that has it. The system will see this as an attempt to add, remove, and re-add the ECU.
This is a rare scenario, and one example when this can happen is when Toradex introduced bootloader upgrades - which in practice introduced an ECU. If you update from TorizonCore 5.7.0 or older to 5.7.2 or newer, then downgrade to 5.7.0 or older, then update to 5.7.2 or newer, you will get the error “At least one ecu in EcuIdentifier was already used and removed for DeviceId and cannot be reused". Workaround: Run the following command on the affected device: "rm -rf /var/sota/storage/bootloader" |
TOR-2406 | Known Issue | HW Accelerated Chromium is not able to render SVG Images on Debian Bullseye container | Apalis iMX8, Colibri iMX8X, Verdin iMX8M Mini, Verdin iMX8M Plus | Debian Base Containers | Low |
Description: When running hardware-accelerated Chromium, SVG images are not rendered.
This is an issue in the upstream Chromium project, see the chromium-ozone-wayland 101 SVG issue, therefore the TorizonCore team will wait until there is a fix upstream.
Update: this issue only affects the Torizon container for Debian Bullseye (tag with major number equal to 2). The container for Debian Bookworm (tag with major number equal to 3) is not affected. Workaround: There are alternatives:
|
TOR-2129 | Feature Request | As a user, I would like a VPN that supports TCP | | Kernel, Open Embedded | |
Description: Wireguard requires UDP access to function. There are some use cases where a TCP-based solution is needed. Workaround: It is possible to run OpenVNP on TorizonCore. Read the article OpenVPN and Weston's VNC/RDP on TorizonCore
for more details. |
TOR-2082 | Feature Request | As a user, when I use U-Boot fw-utils without sudo, I want a more descriptive error message than "Configuration file wrong or corrupted" | Not applicable | Open Embedded | |
Description: When running U-Boot fw-utils commands as fw_setenv or fw_printenv as the torizon user, the command fails with the error message "Configuration file wrong or corrupted". Workaround: Either run the commands with sudo, or switch to the root user before running the commands. |
TOR-2022 | Known Issue | TorizonCore Real Time image reboots randomly on Apalis iMX8 | Apalis iMX8 | Kernel | Low |
Description: It has been reported by a customer that the PREEMPT_RT version of TorizonCore reboots spontaneously on Apalis iMX8. Internally, we were able to reproduce this bug on TorizonCore 5.7.0.
As of July 2022 - when 5.7.0 LTS has been released, the images with the PREEMPT_RT patch haven't been fully validated by Toradex. We have only run smoke tests and cyclictest to make sure that the system boots properly and the PREEMPT_RT patches are working on idle conditions.
In the TorizonCore Download Links we only list PREEMPT_RT images as monthly pre-releases, because they don't go through our validation steps to promote them to production-ready.
This bug is rejected because the customer who reported it didn't follow up on it and we suspect they may have been able to use the regular image without PREEMPT_RT, or another alternative. If you are waiting for this bug fix, please contact us so we can re-evaluate this decision and possibly resume our investigation. |
TOR-2002 | Known Issue | Qt5 with EGLFS/KMS backend not working on rare cases | Apalis iMX6 | Debian Base Containers | Low |
Description: Qt 5 with the EGLFS backend in some specific conditions does not work. While it was identified on BSP 5.3.0 and an Apalis iMX6Q 2GB IT V1.1C, the root cause remains unknown as even on other SoMs with the same configuration it does work. Workaround: Use the Weston backend. If you need EGLFS and Weston cannot meet your needs, please contact us. |
TOR-1878 | Feature Request | As a user, I want to completely quiet the serial console, so I can use the serial port for other purposes | Not applicable | Open Embedded | |
Description: Although we advise customers to keep the first UART dedicated to debugging purposes by default, in the end, it should be a customer decision (for example, it may make sense in scenarios where security concerns are high). Our investigations show that it isn't possible to keep an easy-to-use solution in TorizonCore Builder, therefore we may document our findings with documentation, but we won't provide this as a feature. Please have a look at the workaround below to find some documentation. Workaround: You can find some useful information in the article Configuring Serial Port Debug Console (Linux/U-Boot). |
TOR-1371 | Known Issue | Buggy behavior using openjdk with qemu-static binaries for armv7 and armv8 | All supported modules | Other | Low |
Description: Installing Java or the use of Java-dependent applications does not work during docker build Workaround: Do not use java directly on your Dockerfile which will use a distro based on ARM architecture. Create a multistage Dockerfile and use a x86-64 distro as a base to perform tasks that require java. |
TOR-319 | Known Issue | Colibri iMX6S gets very slow with Docker | Colibri iMX6 | Open Embedded | Low |
Description: Limited amount of memory on iMX6S prevents the system from running fast.
Update: Colibri iMX6S is not supported by TorizonCore anymore, since the low RAM leads to a poor user experience and limited use cases. |
TOR-3447 | Known Issue | Wi-Fi cannot connect to a Wi-Fi network with "Error: Connection activation failed: (53) The Wi-Fi network could not be found." on Verdin AM62 | | Open Embedded | Low |
Description: When trying to connect to a Wi-Fi network, the system throws "Error: Connection activation failed: (53) The Wi-Fi network could not be found."
This only happens after a cold boot. Workaround: It was observed Wi-Fi works given the following workarounds:
- Restart NetworkManager with the command "sudo systemctl restart NetworkManager"
- Toggle Wi-Fi off and on again with the commands "nmcli radio wifi off" and "nmcli radio wifi on"
Then try to connect again.
It was also observed that, without applying the above workaround, NetworkManager will successfully connect after about 10 minutes since the board is powered on, regardless of whether it is the first try to connect. |
TOR-3359 | Feature Request | Enable support for the TI LP5521 Three-Channel RGB and White LED Driver on Torizon OS | All supported modules | Kernel | |
Description: Enable the required kernel config for the TI LP5521 Three-Channel RGB and White LED Driver on Torizon OS. |
TOR-3129 | Known Issue | Chromium 3/Bookworm causes a Weston crash on Apalis iMX8 QuadPlus | Apalis iMX8, Verdin iMX8M Plus | Debian Base Containers | Low |
Description: Running Chromium 3 on TorizonCore 6 leads to a kernel panic. Workaround: Use Chromium 2, either on TorizonCore 5 or 6. |
TOR-3032 | Known Issue | Xwayland falls back to software rendering due to broken Glamor support on i.MX8-based SoMs | Apalis iMX8, Colibri iMX8X, Verdin iMX8M Mini, Verdin iMX8M Plus | Debian Packages | Low |
Description: Xwayland is being started with Glamor disabled, which leads it to fallback to software rendering without 2D graphics acceleration.
This is being fixed in the meta-freescale layer, in the issue xwayland: glamor support broken on iMX8, and once fixed we will leverage it to reintroduce graphics acceleration. |
TOR-2969 | Known Issue | Graphical applications fail to run on Verdin iMX8M Mini DualLite with error "ioctl(DRM_IOCTL_GEM_CLOSE) failed failed to initialize GBM" | Verdin iMX8M Mini | Automated testing, Debian Base Containers | |
Description: Under unknown circumstances, in rare occasions, the error "ioctl(DRM_IOCTL_GEM_CLOSE) failed failed to initialize GBM" is thrown when trying to run graphical applications (it was seen at least once when running the kmscube demo application). After extensively trying to reproduce this error, it was decided to not work on it anymore until a means to reproduce it is found. So far, there are no affected customers, therefore if you get this error, please contact us. |
TOR-2918 | Feature Request | As a user, I want to create a hotspot on TorizonCore with NetworkManager, so I can share internet to other devices | Not applicable | Open Embedded | |
Description: Support for hotspot, or in other words, AP mode with internet forward, will be added to TorizonCore. |
TOR-2802 | Known Issue | Error "Configuration file wrong or corrupted" in reading U-Boot environment variables with fw_printenv in greenboot scripts | Not applicable | Open Embedded | Low |
Description: Reading the U-Boot environment early in the boot stage with the “fw_printenv“ command may fail due to a missing symlink to “/dev/emmc-boot0“, which is created from a udev rule. It may happen, for example, from a Greenboot check script as documented on Update Checks and Rollbacks. Workaround: Either wait for the symlink to be created before running “fw_printenv“, or if you need to use the command in the early boot stages, change the fw-utils configuration to use the eMMC device directly instead of the symlink. |
TOR-2779 | Known Issue | Aktualizr has issues with handling the hashes of metadata files containing multi-byte unicode characters | Not applicable | Aktualizr | Low |
Description: Due to a mismatch between how the client and the server calculate the hashes of packages names and versions, updates of packages that contain multi-character bytes in their name or version fail. Workaround: Only use non-control ASCII characters in package name and version. |
TOR-2488 | Known Issue | Weston container remote desktop (VNC and RDP) causes graphics slow down | | Debian Base Containers | Low |
Description: A customer has reported that enabling VNC significantly affects the performance of their GUI. This is just having the feature enabled with no actual VNC connection present.
This behavior has been observed internally as well. The exact severity of the slowdown depends on the UI framework and how intensive the graphics are overall. But there always seems to be some kind of slowdown present.
This is also known in the upstream weston project, as reported on 11.0.0 Weston screen sharing in embedded environment is very laggy with 100% CPU usage. |
TOR-2357 | Feature Request | As a user, I want trailing whitespace to be automatically removed from my weston.ini config file | Not applicable | Debian Base Containers | |
Description: The weston.ini configuration file is strict with syntax errors, and it doesn't allow trailing whitespaces. Workaround: When applying any configuration described either on the official Weston documentation, or on our article Working with Weston on TorizonCore, make sure there are no trailing whitespace in your configuration file. |
TOR-2304 | Known Issue | Offline Updates: Short-lived containers get pruned from the system and can't be re-fetched | Not applicable | Aktualizr | Low |
Description: As described in the Torizon Remote Updates Overview, application updates pull containers, then check if Docker Compose starts them without errors and last prunes the system, thus removing unnecessary containers.
A side-effect is that, between starting containers with Docker Compose and pruning them, some containers may exit/finish their task, and thus get pruned. For offline updates, there is no way for the system to pull those containers back. Workaround: If your application includes oneshot/short-lived/ephemeral containers that exit shortly after they are started, you must add an artificial delay before the container exits, for example using the "sleep" command. |
TOR-2303 | Known Issue | Offline Updates: Strange "INTERNAL_ERROR" log during an application update | Not applicable | Aktualizr | Low |
Description: The log message with a result equal to INTERNAL_ERROR results from the online updates call chain and it does not affect offline updates. Post the Secure Offline Updates MVP we plan to support concomitant online + offline updates and then review this log message. Workaround: Just ignore the message. |
TOR-2302 | Known Issue | Offline Updates: Update doesn't proceed after temporary update lock expires | Not applicable | Aktualizr | Low |
Description: While it is possible to block updates locking a given file, the offline updates are never unblocked after the lock expires. Workaround: Two workarounds are possible. Either remove and re-attach the lockbox media to trigger another update, or restart the aktualizr service after releasing the lock. |