Mity CPU Platforms » MitySOM-5CSX Altera Cyclone V

Hi Davide,

Are you enabling or changing the configuration of the FPGA to SDRAM (fpga2sdram) or HPS AXI crossbars in the HPS configuration or enabling additional peripherals in the HPS subsystem?

If you are, then you will need to generate a new preloader image and program it into the micro-SD card. The preloader configures the multiplexed pin interface between the FPGA fabric and the HPS subsystem (including the SDRAM bridges). If the preloader configuration doesn't match what the FPGA (or the kernel) is expecting, the result can be that the bus will hang. I have seen this multiple times. The flow to build the preloader is described here and the instructions for updating the preloader can be found here.

The symptoms you are describing sound like that is the problem -- I have had this happen to me more than once!

-Mike

Hi Mike,

in the "final" Quartus program I will indeed need to change the configurations you mentioned, but for a start I decided to use a very simple Quartus project, which does not touch the HPS subsystem (a basic bdf that turns a differential clock into a single ended one and reduces its speed with a PLL). However, also in this case the problems I previously described do manifest.

I generated a new preloader anyway, as you suggested, carefully following the instructions in the link. I verified that I need to check the SDRAM_SCRUBBING box in the bsp-editor: however, after having updated the preloader and the uboot environment, the SD card does not boot at all. I also tried enabling the boot FAT support (assigning the partition #3), but that didn't help.

This behaviour persists regardless of the u-boot being updated or not. The problem thus seems indeed to lie in the preloader, but evidently I'm doing something wrong when rebuilding it. Perhaps there's an option I need to check/uncheck in the bsp-editor that I'm not thinking to?

Regards,

Davide

So, I tried all the methods listed in https://rocketboards.org/foswiki/view/Documentation/GSRD131ProgrammingFPGA, but none is working. In particular:

• I'm not successful in configuring the FPGA from the Preloader because I'm not being able to write the preloader, FPGA and U-boot image to the QSPI: when I try to do it using fatload, I get a "U-boot error: * Unrecognized filesystem type *" message. Changing the fylesistem type of the partition of the SD card explicitly to ext3 or ext4 did not solve the problem.
• I had already tried to configure the FPGA from U-boot or Linux, but (as described in my first post) that does not work.
• According to the instructions, stopping the U-boot after warm reset and issuing the run mmcload and run mmcboot commands should make the system boot, without configuring the FPGA, so that the cat /sys/class/fpga/fpga0/status command should result in "configuration phase". However, when I try to do so, the FPGA still gets programmed: the yellow led shuts off and the status of fpga0 is "user mode".

Isn't there any way to force the system NOT to reboot when I program the FPGA via JTAG?

Can attach a copy of your reference project? Is it based off of the one on our support site?

-Mike

I attach the simple block diagram-based Quartus project that takes in input a 100 MHz differential clock and outputs a single-ended 25 MHz clock. It makes not use of Qsys and it isn't changing the HPS subsystem, but nonetheless I'm facing the problems aforementioned. I also tried to program the FPGA with the dev_5csx_h6_42a.qpf project (both with the .sof via JTAG or the .rbf from Linux) and the exact same problems manifest.

In the past I used the DE1-SoC from Altera and programming via JTAG worked just fine (the Linux system did not reboot), so I'm quite puzzled about the difficulty of doing the same thing here. Hope you can help.

Best regards,

Davide

Dear colleagues,

Are there any solutions of issue with "hot" JTAG FPGA programming? This feature very useful for me, as FPGA developer.

I faced with exactly the same issue: when I start loading FPGA, HPS will stucked. No matter how I do it: through JTAG or HPS fpga manager. No matter the bridges status.
In other hand, I have a few Altera evaluation boards (de0, de10, socrates) and there are no problem with FPGA loading on-fly for each of them.

PS. I've used the same version: MitySOM-5CSX-H6-42A with additional DDR for FPGA. And I tried different designs: first - default version of project, and second version - just pure HPS with exactly the same periphery & sdram settings.

Thanks.

Hello,

In your design do you have kernel drivers that are accessing FPGA cores using the HPS to FPGA lightweight bridge? If so then you will need to have these drivers built as kernel modules and unload them before you try to reprogram the FPGA. For example, the reference designs for our SOMs use soft PIO cores that use drivers that are built into the kernel, the kernel would need to be updated to build the Intel PIO driver as a module instead.

Dan

Hello Daniel,

Yes, I have. Ok, I'll try to do your recommendation, thanks.

Confirmed. After rebuilding Kernel (tested on 3.16 and 4.9.78 versions) and disabling gpio_altera modules FPGA programming is able without HPS stucking.

Thanks.