Forum Discussion

AdzimZM_Altera's avatar
AdzimZM_Altera
Icon for Regular Contributor rankRegular Contributor
2 years ago

Hi Richard,


I've checked the memory density in EMIF IP and the device tree.

Both have been configured to use 1GB.


For the EMIF IP setting, you may change the tRFC value in Mem Timing tab to 260 because it's only use 4Gb.

If the density is changes to 8Gb and 16Gb, you need to change the tRFC value to 350.


I have a few questions that need your clarification: -

  1. Is there any change that has been done to sdram_arria10.c?
  2. Are you able to enter the u-boot space after the ddrcal?
  3. Do you know where the sdram_size_check get the information from?
  4. Have you tested the board with fabric EMIF IP design example to check the DDR4 status?
    1. If no, I suggest you test the board with fabric EMIF IP design example and check the calibration status of the DDR4 interface.
    2. You refer to this link for Arria 10 EMIF Design Example User Guide: https://www.intel.com/content/www/us/en/docs/programmable/683842/21-1-19-2-0/design-example-quick-start-guide-for.html



Regards,

Adzim


R_G's avatar
R_G
Icon for New Contributor rankNew Contributor
2 years ago

Hi Adzim,

Thanks for your response. I changed the tRFC value to 350ns (was 550ns) to match our 16Gb density. This did not fix the problem though. The verify error - read following write of a known value - is still there in the debugger log. I also tried changing the tRFC vaue to 260, but that did not help either. I have included the u-boot log (u-boot_log_tRFC350_CL26_CW16_tRC43_1_24MHz.txt) and debugger log (debugger_log_tRFC350_CL26_CW16_tRC43_1_24MHz.txt) from the Quartus build with the tRFC value set to 350ns. I have also uploaded the debugger script (run-u-boot-three-spl-pass.txt) that drives the U-boot load operation.

Here are the answers to your questions:

1) Is there any change that has been done to sdram_arria10.c?
We have added some debug printouts that are prefixed with "HD MRPS" that can be seen in the u-boot_log_tRFC350_CL26_CW16_tRC43_1_24MHz.txt file, but that's it.

2) Are you able to enter the u-boot space after the ddrcal?
No, the debugger tries to load u-boot image into the external DDR4 memory space that seems to pass U-boot checks, but fails out due to the verify error from the Arm Development Studio "restore" command that can be seen in the debugger script run-u-boot-three-spl-pass.txt file. The debugger log debugger_log_tRFC350_CL26_CW16_tRC43_1_24MHz.txt shows the "verify error" that results from the restore command of that debugger script. The verify error always occurs at address 0x0106C1B0 on different runs by the way.

3) Do you know where the sdram_size_check get the information from?
It looks like sdram_size_check() calls get_ram_size_hdmrps() - which is a duplicate of the U-boot default get_ram_size() function except for "HD MRPS" debug print statements that we added. This function tests the memory region defined by the passed in parameters of base address and size by writing and reading back known values in that region. This U-boot write/readback test passes though. It's the load of the U-boot image into the DDR4 RAM by the debugger "restore" command that fails on a write of the U=boot image block followed by a read back.

4) Have you tested the board with fabric EMIF IP design example to check the DDR4 status?
Yes, it passes calibration with the stand-alone EMIF IP design example. Also, the DDR4 calibration passes according to the U-boot log for our design.

Thanks,

Richard