we are currently facing issues with the Verdin iMX8M Plus Quad 4GB modules: The amout of DRAM is not detected correctly by u-boot, as shown in the u-boot output:
U-Boot SPL 2022.04-00102-g71f04b0e59d (Feb 17 2023 - 00:33:25 +0800)
DDRINFO: start DRAM init
DDRINFO: DRAM rate 4000MTS
DDRINFO:ddrphy calibration done
DDRINFO: ddrmix config done
SEC0: RNG instantiated
Normal Boot
WDT: Started watchdog@30280000 with servicing (60s timeout)
Trying to boot from BOOTROM
Boot Stage: Primary boot
Find img info 0x&48026400, size 888
Download 1000448, Total size 1001136
NOTICE: BL31: v2.6(release):android-13.0.0_1.0.0-rc3-0-g3c1583b-dirty
NOTICE: BL31: Built : 00:33:41, Feb 17 2023
U-Boot 2022.04-00102-g71f04b0e59d (Feb 17 2023 - 00:33:25 +0800)
CPU: i.MX8MP[8] rev1.1 1600 MHz (running at 1200 MHz)
CPU: Industrial temperature grade (-40C to 105C) at 42C
Reset cause: WDOG
DRAM: 2 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... *** Warning - bad CRC, using default environment
In: serial
Out: serial
Err: serial
Model: Toradex 0058 Verdin iMX8M Plus Quad 4GB WB IT V1.1B
u-boot detects 2GB but the module should have 4GB as seen in the model description (and on the label of the module itself). Linux/Android also shows only 2GB of RAM.
The u-boot was “U-Boot 2022.04-00102-g71f04b0e59d (Feb 17 2023 - 00:33:25 +0800)” from factory, as test I booted the easy installer via USB and installed a more recent version as seen in the output. The issue was the same.
The output was recorded on our own carrier, but I also tested with the Dahlia carrier board and got the same results.
What are we doing wrong?
I guess the amount of RAM should be auto-detected by the u-boot.
Hi, I’m the Toradex AI Assistant. I’m in early beta, and I would appreciate your feedback.
The Toradex Support team will follow up with you shortly!
Did you like my answer?
Hello Stephan,
The issue you’re encountering with the Verdin iMX8M Plus Quad 4GB modules not correctly detecting the full amount of DRAM in U-Boot is indeed unusual and can be due to several factors. Here are a few steps and considerations to help diagnose and potentially resolve the issue:
U-Boot Version Compatibility: Ensure that the U-Boot version you’re using is compatible with the Verdin iMX8M Plus modules. Although you’ve tried updating U-Boot, it’s crucial to verify that the version is specifically recommended for your module and its memory configuration.
Device Tree Configuration: The amount of RAM detected can sometimes be influenced by the device tree settings. Ensure that the device tree used by U-Boot correctly describes the memory layout for the 4GB configuration. You might need to review and adjust the device tree settings to ensure they accurately reflect the hardware.
Hardware Issues: Although less common, it’s possible that there could be a hardware issue with the DRAM itself or its connection to the main processor. Testing with multiple modules, as you’ve done, helps rule out a single defective module, but it’s still something to consider.
U-Boot Configuration Parameters: Check the U-Boot configuration parameters (environment variables) to ensure there’s nothing limiting the memory detection. Although auto-detection should ideally work out of the box, there might be settings that affect this process.
Software Updates: Verify that you’re using the latest firmware and software releases from Toradex for both U-Boot and the Torizon platform. Sometimes, issues like these are resolved in newer software versions.
Memory Initialization Code: In some cases, the memory initialization code in U-Boot might need adjustments to properly recognize all available memory, especially for specific DRAM configurations or speeds. This is more technical and might require support from Toradex if there’s a bug or compatibility issue with the initialization code.
Debugging U-Boot: If you’re comfortable with it, you can debug U-Boot to see where the memory detection is failing. This would involve looking at the source code and possibly adding debug messages to the DRAM initialization routines.
Given the steps you’ve already taken, it seems like a deeper investigation into the U-Boot configuration, device tree, and possibly the memory initialization code might be necessary. If the issue persists after reviewing these areas, it might indicate a more complex compatibility issue or a bug in the U-Boot
Please, also check if these links can help you solve your problem:
This is a known issue that was addressed starting with the 5.7.4 release. However, you’re using an older U-Boot version that doesn’t support dual-rank DDR RAM.
after installing the 5.7.4 release everything works as expected.
I just wonder, why is there an old, not working u-boot installed on the modules from factory? If the problem is already (and quite a while) known, why is this not fixed in production?
Sorry if I misunderstood, but is the U-Boot actually not working? From the thread here I understood that it is working, but without being able to recognize all the available RAM. Please correct me if I am wrong.
What is important to keep in mind is that the Toradex Easy Installer version shipped with the module is actually part of the product and changing this will generate a PCN and will impact everyone using this module. Specially those in volume, so it is a big deal. Nevertheless, you have a fair point.
I brought it up internally and will update this thread whenever possible.
Having in mind that Toradex Easy Installer is meant to be a OS installer, not being able to recognize the full RAM should have no impact to its functionality. So if you are able to install OSes with Toradex Easy Installer, it is working.
so I guess your understanding was right.