RAM Issue After Upgrading Verdin iMX8MP from V1.1A to V1.1B

Hello Toradex Community,

We recently upgraded our Verdin iMX8MP module from V1.1A to V1.1B, and since then we are experiencing a RAM issue: the system now shows 2GB of RAM instead of 4GB.

We are currently using the image:
torizon-core-docker-verdin-imx8mp-Tezi_5.7.2+build.20.

I have seen in a similar thread (Verdin IMX8M-Plus production fails with 1.1B but passes with 1.1A - #6 by Fide) that upgrading to Torizon version 5.7.4 or higher is recommended to resolve this issue. However, I am unable to find this version and need assistance on how to obtain or upgrade to it.

Could someone please guide me on the proper way to upgrade the image or provide support for this RAM issue on the Verdin iMX8MP V1.1B?

Thank you very much for your help!

1 Like

Hi, I’m the Toradex AI Assistant.

I might make mistakes or occasionally get you wrong. Our support team will step in if needed.


I can help you resolve this RAM issue with your Verdin iMX8M Plus V1.1B module(1)(2).

Root Cause

Your issue is directly related to the hardware changes between V1.1A and V1.1B revisions. The V1.1B revision includes a new RAM part (Micron MT53E1G32D2FW-046 IT:B) that has a different geometry compared to the old RAM part (Micron MT53E1G32D2FW-046 IT:A) used in V1.1A(1)(2).

Solution: Software Version Requirements

The V1.1B hardware revision requires specific software versions to function properly. According to the Product Change Notifications:

Torizon OS Support

  • The Replacement Product is supported in Torizon OS 6 from the 6.2.0 Quarterly Release onwards(1)(2)
  • The Replacement Product is supported in Torizon OS 5 from the 5.7.4 Maintenance Release onwards(1)(2)
  • When using the Replacement Product with any older Torizon OS release, the product will not function properly(1)(2)

Your current image (torizon-core-docker-verdin-imx8mp-Tezi_5.7.2+build.20) is older than the required 5.7.4 version, which explains why you’re only seeing 2GB instead of 4GB RAM.

How to Upgrade

Option 1: Download Compatible Image

You need to download a Torizon OS image version 5.7.4 or higher, or preferably Torizon OS 6.2.0 or higher. You can find these images on the Download Links page(3).

Option 2: Use OTA Updates

If your device is connected to the internet, you can use Torizon’s Over-The-Air update system to upgrade to a compatible version(4)(5).

Additional Benefits

When using the V1.1B hardware with a supporting Torizon OS version, the PCB temperature sensor (TMP1075DSGR) will also be available for use(1)(2).

Important Notes

  • The End of Life Product (V1.1A) remains supported in Torizon OS 5 and 6 releases(1)(2)
  • Make sure to match your Torizon OS version to your hardware revision to avoid compatibility issues
  • The V1.1B revision also includes other improvements beyond the RAM geometry fix(6)

Best regards, Toradex AI Assistant.


Did you like my answer? :+1: :-1:

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

Greetings @Samir1,

There never was a 5.7.4 release for Torizon. If you want Torizon software that supports the newer version of the module you have, you would need to go to at least Torizon 6.

If you can’t move versions, then you need to do a custom build. The following commits were done in U-Boot to support this version of the module:

Unfortunately, Torizon 5.7.2 is an old unsupported version now. So, we are unable to provide more in-depth support than this.

Best Regards,
Jeremias

Hello Jeremias, and thank you for your quick reply,

I installed the version 6.2.0 (and even version 6.8.5), and I am able to correctly see my 4GB of RAM.
However, as soon as I add the device trees into my tcbuild.yml like this:
Note: I already had this configuration on the older version and it had no impact.

input:
  easy-installer:
    local: images/torizon-core-docker-verdin-imx8mp-Tezi_6.8.5+build.41.tar

customization:
  #filesystem:
    #- changes/
  device-tree:
    include-dirs:
      - linux/include/
    custom: linux/arch/arm64/boot/dts/freescale/imx8mp-verdin-nonwifi-yavia.dts
    overlays:
      add:
        - device-trees/overlays/verdin-imx8mp_spidev_overlay.dts


output:
  easy-installer:
    local: torizon-core-docker-verdin.CUSTOM
    accept-licence: true
    autoinstall: true
    autoreboot: true

My DTS files

imx8mp.dtsi (73.6 KB)

imx8mp-verdin.dtsi (38.3 KB)

imx8mp-verdin-nonwifi-yavia.dts (400 Bytes)

The device trees were modified to add SPI interfaces and to free some pins due to a lack of available pins.

The Yavia board goes into error and sometimes reboots in a loop, so, I can’t have access using ssh.
I’m wondering why I didn’t have this issue before, and I think I cannot take the risk of modifying my device trees since this is a critical part that I do not fully master.

Regarding the second solution you suggested, I am not sure how to test it.
I pulled from u-boot-toradex.git
I switched to the branch: toradex_imx_v2020.04_5.4.70_2.3.0
and then ran:

make distclean
make verdin-imx8mp_defconfig
make ARCH=arm CROSS_COMPILE=aarch64-linux-gnu- -j$(nproc)

This results in:

  OBJCOPY lib/efi_loader/helloworld.efi
  LD      lib/built-in.o
  LD      common/built-in.o
  LD      u-boot
  OBJCOPY u-boot.srec
  OBJCOPY u-boot-nodtb.bin
  SYM     u-boot.sym
start=$(aarch64-linux-gnu-nm u-boot | grep __rel_dyn_start | cut -f 1 -d ' '); end=$(aarch64-linux-gnu-nm u-boot | grep __rel_dyn_end | cut -f 1 -d ' '); tools/relocate-rela u-boot-nodtb.bin 0x40200000 $start $end
  CAT     u-boot-dtb.bin
  MKIMAGE u-boot.img
  MKIMAGE u-boot-dtb.img
  COPY    u-boot.bin
  LD      u-boot.elf
  CC      spl/common/spl/spl.o
WARNING 'lpddr4_pmu_train_1d_imem_201904.bin' not found, resulting binary is not-functional
  CC      spl/arch/arm/cpu/armv8/fwcall.o
  CC      spl/common/fdt_support.o
  CC      spl/lib/display_options.o
  LD      spl/arch/arm/cpu/armv8/built-in.o
  LD      spl/common/spl/built-in.o
  LD      spl/lib/built-in.o
  LD      spl/common/built-in.o
  LD      spl/u-boot-spl
  OBJCOPY spl/u-boot-spl-nodtb.bin
  COPY    spl/u-boot-spl.bin
WARNING 'lpddr4_pmu_train_1d_imem_201904.bin' not found, resulting binary is not-functional
make[1]: Nothing to be done for 'SPL'.
  CFGCHK  u-boot.cfg

I have this build issue and I do not know how to fix it. I also do not know what to do next. Which .bin file should I use and where should I place it?

I tried using the imx-boot.bin from the 6.8.5 reference image inside the 5.7.2 reference image, but it does not work.

I would really appreciate your help, and I am open to other possible solutions.

Best regards,

The Yavia board goes into error and sometimes reboots in a loop, so, I can’t have access using ssh.
I’m wondering why I didn’t have this issue before, and I think I cannot take the risk of modifying my device trees since this is a critical part that I do not fully master.

I’m assuming you used the exact same device trees and overlays that were used in Torizon 5.X?

Please do note that you are on a different major version of the OS now. This means the Linux kernel version is completely different. You can’t just use the old device tree and overlays on the new version. You have to use the matching version, otherwise you get strange behavior like this.

For Torizon 6.X, the correct branch from linux-toradex is toradex_5.15-2.2.x-imx. You would need to rebase your code changes on top of this version.

Regarding the second solution you suggested, I am not sure how to test it.

Please refer to the article for building U-Boot back in 5.X: Build U-Boot and Linux Kernel from Source Code | Toradex Developer Center

Applying the U-Boot changes as patches in a Yocto build is another option, if you have the knowledge with Yocto.

Best Regards,
Jeremias

Hello again !

I successfully built the imx-boot and tested it on my iMX8MP v1.1b board, and it now correctly shows 4Gb of RAM.
There were no changes to my DTS configuration.
Note:
This link: https://source.codeaurora.org/external/imx/imx-mkimage/ does not work for me.

Alternative: https://github.com/nxp-imx/imx-mkimage.git

Thank you for your help.

Glad I was able to help.

Best Regards,
Jeremias

1 Like