Mity CPU Platforms » MitySOM-5CSX Altera Cyclone V

Hi Franz,

We do have a reference SD card for the 5CSX-H6-53B on our wiki page: https://support.criticallink.com/redmine/projects/mityarm-5cs/wiki#Variant-Specific

Here is a direct link to that SD card: https://support.criticallink.com/redmine/attachments/download/27162/sdcard_5csx_h6_53b_20201116.zip

Note: You will need to be signed into redmine in order to download it.

The preloader/u-boot images are different between the 1GB and the 2GB modules. The 2GB module needs to pin mux out an extra address line and configure the SDRAM controller to use the full 2GBs.

Dan

Hello Dan,

I have changed the hps row address width from 15 to 16 for the MitySOM 5CSX-H6-53B-RC and added package skew compensation, IO standard and output termination lines for the extra hps address in the qsf file which gets assigned PIN_F24 when built. The Verilog file also has the array for the hps address extended to [15:0]. Our qsys setup uses FPGA-to-HPS SDRAM interface instead of an SDRAM controller instance. Trying to boot the resulting image now shows the SDRAM at 2048 MiB but the boot stalls right after that when initializing SDRAM ECC (I have attached the boot output). Might there be something else missing?

Thanks,

Franz

Hi Franz,

This hang might be due to not enabling SDRAM_SCRUBBING in the bsp-editor, as described in our bootloader build instructions step 9 (https://support.criticallink.com/redmine/projects/mityarm-5cs/wiki/Building_uboot_181)

I would also recommend if you haven't to compare you HPS block in QSYS/Platform Designer for the 5CSX-H6-53B-RC module: https://support.criticallink.com/gitweb/?p=mitysom-5csx-ref.git;a=tree;f=dev_5csx_h6_53b;h=278526cd41234ffa3b8d312fb628efbca07ad546;hb=52a01fac53298c0e8142e1c54db6aae9061d1dc4

Dan

Hello Dan,

Unfortunately, the boot still stalls with SDRAM_SCRUBBING enabled. As for the HPS instance, the only differences are the added FPGA to HPS interface and a few different peripheral pins which are an added SPIM0 pin and no QSPI, USB1 or CAN0 pins. Could one of these be the issue? The MitySOM 5CSX-H6-42A works fine with the row address set to 15 and the only difference in the HPS instance between the MitySOM 5CSX-H6-42A and 5CSX-H6-53B from the repository samples is that row address width so I’m not quite sure why it’s not booting for the 5CSX-H6-53B, are one of those pins required for it?

Thanks,

Franz

Hi Franz,

I don't believe changing the pin mux like you have would cause the preloader to hang at initializing the DDR, this normally occurs if the row width wasn't adjusted to account for the extra size. Also you are right the row address should only be the change needed to go from the 1GB module to the 2GB module in Platform Designer/Qsys.

One more change to the project would me adding constraints fro the new address pin like the following:

set_instance_assignment -name IO_STANDARD "SSTL-135" -to HPS_DDR_A[15]
set_instance_assignment -name OUTPUT_TERMINATION "SERIES 34 OHM WITHOUT CALIBRATION" -to HPS_DDR_A[15]
set_instance_assignment -name PACKAGE_SKEW_COMPENSATION OFF -to HPS_DDR_A[15]

To further help I would need your .qsys and .qsf file if you're willing to post them.

Dan

Hello Dan,

I did already have those instances added to my .qsf. Before I share my .qsys and .qsf files I would like to verify if my device tree files had the correct changes, I have attached all the ones being used here. The changes between the two boards are in the soc_sys.dts file which are the expanded memory to 0x80000000 and the added &qspi similar to the one from the socfpga_mitysom5csx-h6-53b.dtsi file. The 42A-RC working board did not have this &qspi section. Are there any changes I should make or do you have any suggestions?

Thanks,

Franz

Hi Franz,

For the issue with the 53B SOM hanging at "Initializing SDRAM ECC" the device tree doesn't come into play, at this point the SOM would only care about the preloader. From a highlevel your soc_sys.dts looks ok.

Dan

Hello Dan,

I have attached the .qsys and .qsf files. These have the instances added as well as the row address width set to 16 so I'm not sure what other change is needed, maybe the clock needs to be changed for the 53B-RC?

Thanks,

Franz

Hi Franz,

One difference that stands out to me is the INPUT/OUTPUT TERMINATIONs used. Because the SOM uses a different RZQ value than the defaults that quartus use please change the HPS DDR INPUT_TERMINATION/OUTPUT_TERMINATION for the DDR to the following:

INPUT_TERMINATION: "PARALLEL 60 OHM WITH CALIBRATION"
OUTPUT_TERMINATION: "SERIES 34 OHM WITH CALIBRATION"

No clocks need to change between the 1GB and 2GB module.

I'll try to get a build using your qsf/qsys going so I can debug here, can you also send me your top level HDL file? Feel free to remove any custom/propriety logic.

Dan

Hello Dan,

I made the changes you suggested and the same issue is still there, at this point I don't think the issue is with the firmware files. You mentioned that the preloader/u-boot images would be different, are there any other changes related to u-boot for the 53B-RC that need to be made or something relating to u-boot that can be causing this?

Thanks,

Franz

Hi Franz,

Based off your boot log the board is stuck at the preloader, before getting into u-boot. The preloader/u-boot are built using outputs from the firmware build, the preloader get's it pinmux/DDR settings from the options you selected in qsys/platform designer.

As a sanity check I would recommend trying the prebuilt preloader for the 53B reference design and seeing if that will let you get further in the boot flow: https://support.criticallink.com/redmine/attachments/download/27155/fpga_bins_5csx_h6_53b_20201116.zip.

Another sanity check would be to rebuild our reference design (preloader/u-boot/rbf) and try that on the board.

Dan