S10 programming file conversion

[GMcCa2]

I'm attempting to update the flash on an S10 board (Terasic Apollo S10), but I am having issue with u-boot.

I'm creating my JIC file with:

quartus_pfg -c test.sof output.jic -o device=MT25QU01G -o flash_loader=1SX280HU2F50E1VG -o hps_path=u-boot-spl-dtb.hex -o mode=ASX4

The sof and u-boot hex files being used are those provided by Terasic.

If I run this command with Quartus 19.1 or 19.4 and load the jic to the board then it boots with no issue. First few messages are:

U-Boot SPL 2019.04-00236-gd9c510007b (Mar 25 2020 - 10:07:36 +0800)
MPU         1200000 kHz
L3 main     400000 kHz
Main VCO    2400000 kHz
Per VCO     2000000 kHz
EOSC1       25000 kHz
HPS MMC     50000 kHz
UART        100000 kHz
DDR: Warning: DRAM size from device tree mismatch with hardware.
DDR: 16384 MiB
SDRAM-ECC: Initialized success with 3679 ms
QSPI: Reference clock at 400000000 Hz
...

If I run the same conversion command with Quartus 22.1, 24.1, 24.2, or 24.3 and load the generated jic file to board then u-boot hangs indefinitely after these messages:

U-Boot SPL 2019.04-00236-gd9c510007b (Mar 25 2020 - 10:07:36 +0800)
MPU         1200000 kHz
L3 main     400000 kHz
Main VCO    2400000 kHz
Per VCO     2000000 kHz
EOSC1       25000 kHz
HPS MMC     50000 kHz
UART        100000 kHz

I have also tried running with a newer version of u-boot that I generate which fixes the DRAM size issue from those provided by Terasic and it boot properly when converted with 19.4:

U-Boot SPL 2024.07-36773-g0dad0a0a478-dirty (Mar 18 2025 - 15:06:18 -0400)
Reset state: Cold
MPU         1200000 kHz
L3 main     400000 kHz
Main VCO    2400000 kHz
Per VCO     2000000 kHz
EOSC1       25000 kHz
HPS MMC     50000 kHz
UART        100000 kHz
DDR: 32768 MiB
SDRAM-ECC: Initialized success with 7879 ms
QSPI: Reference clock at 400000 kHz
...

but it hangs at the same spot as the older u-boot when I create the jic file with Quartus 24.1.

I would just use 19.4 to convert all my files, but my design is compile with 24.1 and it gives me an error if I try to convert the sof generated by 24.1:

Error (19516): Detected Programming File Generator settings error: File test.sof is incompatible - Bitstream Assembler does not support feature "Power Management Page Command Payload" that required by SOF/PMSF/DMSF test.sof

 Anything I need to change with the command in newer Quartus version to get this to work?

[JingyangTeh]

Hi

It is recommended to use the combination of uboot and GHRD below:

Device Quartus Version ATF Branch U-Boot Branch Linux Branch

Stratix 10 SoC 24.1 Pro 2.10.0 2023.10 6.1.68-lts

Could you try with the combination above?

Regards

Jingyang, Teh

[GMcCa2]

I was able to try a few more Quartus version today and I am able to get the board to boot with a sof generated with 24.1 if I create the jic using 20.3.

Here a summary of what I've tried:

.sof compile version	quartus_pfg version	u-boot 2019.04 successful?	u-boot 2024.07 successful?
19.4	19.1	yes
19.4	19.4	yes	yes
19.4	20.3	yes	yes
19.4	21.1	no	no
19.4	22.1	no
19.4	24.1	no	no
19.4	24.2	no
19.4	24.3	no
20.3	20.3	yes	yes
20.3	24.1	no	no
21.1	20.3	yes
21.1	21.1	no
24.1	20.3	yes	yes
24.1	24.1	no	no
24.1	24.2	no
24.1	24.3	no

I should reiterate that this is not the S10 development board. The GHRD files I have from Terasic are from Quartus 19.4. The other sof versions in the table I compiled after updating from the 19.4 version.

The 2019.04 u-boot is the one provided by Terasic with the board. The 2024.07 u-boot is compiled from the altera-opensource/u-boot-socfpga github at QPDS24.2_REL_GSRD_PR tag, following the steps for the S10 development board, except using the device tree provided by Terasic.

This appears to be related to quartus_pfg version used, as the boot results are the same regardless of u-boot version. I would think that the generate jic file should function essentially the same regardless of the Quartus version used. Maybe newer version have changes to the SDM control timing that is causing this issue?

On top of the new Quartus version, I've also tried switching to HPS first booting (board GHRD is FPGA first). I'm doing this with the 24.1 sof and creating the jic/rbf with 24.1 as well (which always fails boot with FPGA first). Now when it boots, it sometimes resets itself where it was hanging with FPGA first and then boots successfully:

U-Boot SPL 2024.07-36773-g0dad0a0a478-dirty (Mar 18 2025 - 15:06:18 -0400)
Reset state: Cold
MPU         1200000 kHz
L3 main     400000 kHz
Main VCO    2400000 kHz
Per VCO     2000000 kHz
EOSC1       25000 kHz
HPS MMC     50000 kHz
UART        100000 kHz
<Sometimes hangs here indefinitely, sometime hangs here for a few seconds and continues to below>

U-Boot SPL 2024.07-36773-g0dad0a0a478-dirty (Mar 18 2025 - 15:06:18 -0400)
Reset state: Cold
MPU         1200000 kHz
L3 main     400000 kHz
Main VCO    2400000 kHz
Per VCO     2000000 kHz
EOSC1       25000 kHz
HPS MMC     50000 kHz
UART        100000 kHz
DDR: 32768 MiB
SDRAM-ECC: Initialized success with 7879 ms
QSPI: Reference clock at 400000 kHz
... <boots succesfully if it makes it to here>

It almost always hangs indefinitely when the board has been off for more than 30 seconds, and it resets itself and boots successfully about 70% of the time if I power cycle the board quickly.

If I do the HPS first booting and use 20.3 to create the jic/rbf then it boots normally (no restart of the SPL during boot). This seems to indicate the timing of the boot is different with jic files generated with newer Quartus versions. Maybe the SDM is loading faster and DDR4  is not ready or something like that. Is there a way to delay u-boot at power up?

[GMcCa2]

I've been messaging with Terasic support and they are also suspecting an SDM firmware update causing this issue.  From https://www.intel.com/content/www/us/en/docs/programmable/683762/23-1/updating-the-sdm-firmware.html it seems that you recommend always using the latest version of PFG, so I would like to follow that. Is there any information anywhere about what has changed in the SDM firmware over different Quartus releases that might help sort out my boot issue?

[JingyangTeh]

Hi

It is always recommended to use the recommended uboot version and quartus release combination recommended in the release note here:

https://www.rocketboards.org/foswiki/Documentation/IntelFPGAHPSEmbeddedSoftwareRelease

You could also find what are the bug fix or new features that was implemented.

Regards

Jingyang, Teh

[GMcCa2]

I have tried the latest combination of u-boot and quartus release listed in the link above. My problem is that this only works for this board if I use PFG from 20.3 to create the jic file.

The jic output from this command does not boot:

c:\intelFpga\24.3\quartus\quartus_pfg -c test.sof output.jic -o device=MT25QU01G -o flash_loader=1SX280HU2F50E1VG -o hps_path=u-boot-spl-dtb.hex -o mode=ASX4

 But the jic output from this command does boot:

c:\intelFpga\20.3\quartus\quartus_pfg -c test.sof output.jic -o device=MT25QU01G -o flash_loader=1SX280HU2F50E1VG -o hps_path=u-boot-spl-dtb.hex -o mode=ASX4

The link you provided lists fixes that were done to u-boot and the ghrd, but says nothing about quartus_pfg and what different version do differently when generating a jic from the exact same input files. This seem somewhat import considering the recommendation that we should be using the latest PFG version to convert files even if they are generated with older versions of Quartus (https://www.intel.com/content/www/us/en/docs/programmable/683762/23-1/updating-the-sdm-firmware.htm).

[WZ2]

Hi there,

Based on your tests and feedback, it appears that the boot failure issue is related to the firmware running in the SDM (which is introduced by quartus_pfg, or more precisely, by the Programmer tool).

Furthermore, from your firmware versions, I can see that the failures start occurring with firmware from Quartus 20.3 and onwards. I have two suggestions:

1. Remove the HPS portion from your project and use the Programmer from Quartus 20.3 (or any failing version) to load the SOF file. I expect the failure will still occur. For further debugging, please provide the error code from the SDM.
2. Try switching to HPS-first boot. I suspect this loading issue can be worked around via a reload(like toggle nconfig). That is, after HPS boots, reloading the FPGA from HPS may allow the system to function correctly.

Best ,

WZ