Skip to content

Known Issues

Issue Tracker

Please have a look at the issue tracker on our GitLab server for known bugs and issues affecting the BSP and also to report any issues you might encounter.

Yocto BSP Erratas

SPI-NAND uses defect flash areas

Date: 10th May 2022

Due to an error in the Linux Kernel SPI-NAND Framework, it is possible that flash blocks marked as defective in the SPI-NAND device are incorrectly used for data storage. This can lead to data corruption or loss of data on the affected modules.

Since the NAND flash memory can basically contain defective memory blocks due to the technology used and the amount of defective blocks will increases over time, the probability of this error also increases with the age of the device.

Affected Products

Affected are modules of the i.MX6 and STM32MP platforms that use the SPI-NAND memory. The Kontron i.mx8 platform is not affected as no SPI-NAND is used on this hardware.

Furthermore, assemblies that only use NOR or eMMC memory technologies are not affected by this problem.

Available fixes

As of the following Kontron Yocto BSP versions, the error has been corrected

  • Platform STM32MP: BSP STM32MP 2.0.0
  • Platform I.MX: BSP IMX 5.0.0

The following bug fixes are available for the kernel versions of the Kontron Yocto BSPs that resolve the error

Platform STM32MP1

Platform i.MX6

Starting with Linux kernel versions 5.10.94, 5.4.174 and 4.19.226, the bug has also been fixed in the mainline kernel sources.

It should be noted that when changing over to a corrected software version, the previously used defective memory blocks are no longer used. For devices which contain a critical bad block configuration and therefore are already affected by this problem, upgrading to a corrected software version can lead to data loss on the device!

NXP i.MX Chip Erratas

Other Known Issues

Library version mismatches while debugging

Occurence

While cross-debugging (e.g. with QtCreator) you might note messages like these: 

.dynamic section for "/opt/exceet/mx6sexceet/sysroots/cortexa9hf-vfp-neon-exceet-linux-gnueabi/usr/lib/libQt5Qml.so.5" is not at the expected address (wrong library or version mismatch?)

Reasons

The root cause of this is often that the library version in the toolchain, that is used differs from the one on the target.
Sometimes it can happen, that you use a new image and although nothing has changed in the library since the previous build of the toolchain, these messages occur. This is because sometimes paths relative to the build directory on the build host are compiled into the binaries. If this information changes, e.g. because the new image was build on an other machine, it might happen that the addresses in the library files are shifted and though the content of the library is essentially the same, its structure has slightly changed, what produces the messages in the debug log.

Measures

This problem has been approached in recent versions of Yocto by trying to strip all the absolute paths from the target binaries.
Check what caused the changes in the library and decide whether to build/install a new toolchain or not.

VMware Problems

No log-in possible after booting

Suspend your image. Then start your image again, click immediately into the window and press the left shift key. Now the boot process will stop and the Ubuntu boot menu is presented. Choose here to boot in recovery mode.
After the recovery mode is started, choose to resume normal booting. After a while you will be able to login into Ubuntu.
To fix the problem permanently open the file '/etc/gdm3/custom.conf' with the editor of your choice (sudo priviliges needed) and uncomment the line saying '#WaylandEnable=false'. With that fix you should be able to login again after normal booting.
(Copied from https://askubuntu.com/questions/1149957/unable-to-login-to-account-in-ubuntu-18-04-vmware-workstation-15-after-update)