On 6/2/2026 3:50 pm, Sune Brian wrote:
[CAUTION: This email is from outside your organization. Unless you trust the
sender, do not click on links or open attachments as it may be a fraudulent
email attempting to steal your information and/or compromise your computer.]
On Fri, Feb 6, 2026 at 11:33 AM Yuslaimi, Alif Zakuan
<[email protected]> wrote:
On 6/2/2026 3:17 am, Sune Brian wrote:
[CAUTION: This email is from outside your organization. Unless you trust the
sender, do not click on links or open attachments as it may be a fraudulent
email attempting to steal your information and/or compromise your computer.]
On Tue, Jan 27, 2026 at 4:03 PM Chee, Tien Fong
<[email protected]> wrote:
On 16/12/2025 4:46 pm, [email protected] wrote:
From: Alif Zakuan Yuslaimi <[email protected]>
Add DRAM size checking compare between size from device tree and actual
hardware.
Trigger hang if DRAM size from device tree is greater than actual hardware.
Display warning message if DRAM size mismatch between device tree and
actual hardware.
get_ram_size() uses size from device tree. So, it has consistency with
other device families.
Signed-off-by: Alif Zakuan Yuslaimi <[email protected]>
---
drivers/ddr/altera/sdram_gen5.c | 20 +++++++++++++++++++-
1 file changed, 19 insertions(+), 1 deletion(-)
diff --git a/drivers/ddr/altera/sdram_gen5.c b/drivers/ddr/altera/sdram_gen5.c
index 7a0a043557b..d5892850da7 100644
--- a/drivers/ddr/altera/sdram_gen5.c
+++ b/drivers/ddr/altera/sdram_gen5.c
@@ -6,6 +6,7 @@
#include <dm.h>
#include <errno.h>
#include <div64.h>
+#include <hang.h>
#include <init.h>
#include <log.h>
#include <ram.h>
@@ -615,6 +616,22 @@ static int altera_gen5_sdram_probe(struct udevice *dev)
sdram_size = sdram_calculate_size(sdr_ctrl);
debug("SDRAM: %ld MiB\n", sdram_size >> 20);
+ /* setup the dram info within bd */
+ dram_init_banksize();
+
+ if (sdram_size != gd->bd->bi_dram[0].size) {
+ printf("DDR: Warning: DRAM size from device tree (%d MiB)\n",
+ (u32)(gd->bd->bi_dram[0].size >> 20));
+ printf(" mismatch with hardware (%d MiB).\n",
+ (u32)(sdram_size >> 20));
+ }
+
+ if (gd->bd->bi_dram[0].size > sdram_size) {
+ printf("DDR: Error: DRAM size from device tree is greater\n");
+ printf(" than hardware size.\n");
+ hang();
+ }
+
if (sdram_is_ecc_enabled(sdr_ctrl)) {
/* Must set USEECCASDATA to 0 if ECC is enabled */
clrbits_le32(&sdr_ctrl->static_cfg,
@@ -623,7 +640,8 @@ static int altera_gen5_sdram_probe(struct udevice *dev)
}
/* Sanity check ensure correct SDRAM size specified */
- if (get_ram_size(0, sdram_size) != sdram_size) {
+ if (get_ram_size(0, gd->bd->bi_dram[0].size) !=
+ gd->bd->bi_dram[0].size) {
puts("SDRAM size check failed!\n");
goto failed;
}
Reviewed-by: Tien Fong Chee <[email protected]>
Hi T.F. and Alif,
I know you reviewed the code.
But I am not sure on 2GB w/o ECC run it will pass SPL stage.
However when applied to the patch 2GB w/ ECC it does not pass SPL.
I would like to confirm that ARM GDB cannot be used to test ECC or not?
As I do see it involved D-Cache on
"drivers/ddr/altera/sdram_soc32.c"
Thanks,
Brian
Hi Brian,
The code has been tested with RAM boot via ARM debugger on our Cyclone V
SOC Development Board with ECC enabled, we are able to boot up to Linux
successfully.
Our board specs can be found here -
https://www.rocketboards.org/foswiki/Documentation/AlteraSoCDevelopmentBoard
You can also refer our documentation here on running U-Boot with ARM
debugger -
https://altera-fpga.github.io/rel-25.1/embedded-designs/cyclone-v/sx/soc/boot-examples/ug-linux-boot-cve-soc/#appendix-2-run-u-boot-with-the-debugger-from-command-line
Hi Alif,
Yes, if you use DS5 to run this patch series it will properly boot on
a 2GB case.
Our side changed to use openocd with GDB.
In that case it will simply be stuck on the "DDRCAL: Scrubbing ECC RAM".
Thanks,
Brian
Under DS5 boot message shows ECC init passed.
U-Boot SPL 2026.04-rc1-00154-gb5213bbfdcb1-dirty (Feb 06 2026 - 15:43:21 +0800)
DDRCAL: Scrubbing ECC RAM (2048 MiB).
DDRCAL: SDRAM-ECC initialized success with 1051 ms
U-Boot 2026.04-rc1-00154-gb5213bbfdcb1-dirty (Feb 06 2026 - 15:43:21 +0800)
CPU: Altera SoCFPGA Platform
FPGA: Altera Cyclone V, SE/A6 or SX/C6 or ST/D6, version 0x0
BOOT: QSPI Flash (3.0V)
DRAM: 2 GiB
Core: 32 devices, 17 uclasses, devicetree: separate
MMC: dwmmc0@ff704000: 0
Loading Environment from MMC... Card did not respond to voltage select! : -110
*** Warning - No block device, using default environment
In: serial
Out: serial
Err: serial
Model: Cyclone V-5CSXF6C6U23
Net: Could not get PHY for ethernet@ff702000: addr -1
No ethernet found.
Hit any key to stop autoboot: 0
Thanks for sharing your test case, Brian.
I now see delta between our test cases.
This is most likely because OpenOCD reads DDR before ECC is fully
initialized, which will cause DDR controller to return error, and
causing the hang in during DDR init.
Another extra complication is added as dcache is enabled during DDR init
for performance. As the CPU writes to cache only, DDR is not updated,
and ECC is not generated yet. As OpenOCD tries to bypass the cache and
reads the stale DDR directly with the invalid ECC, it will throw error
and cause the hang.
Arm DS avoids reading unitialized memory and does not poll the DDR
constantly, hence this is why the issue is not observed on ARM DS.
You can try to boot without ECC enabled in the hardware, but still keep
dcache enabled with OpenOCD to confirm that this is not a software issue.
Thanks,
Alif
Thanks,
Alif
Best regards,
Tien Fong
