CycloneV: Programming FPGA from U-Boot

@JanKonecny
Where in the install is the uboot source code?
I had used uboot-socfpga latest branch at

I am using the free lite version of the Quartus software and standard version of SOCEDS.

My Quartus version.txt

Version=19.1.0.670
[ACDS]
Version=19.1.0.670
Edition=lite

My SOCEDS version.txt

Version: 19.1, Build: 670

@JanKonecny
I also read the “official” Intel documentation here.
https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/ug/ug_soc_eds.pdf
This pointed me to here for directions on the Cyclone V boot flow

This appears to be an updated workflow from the link I posted earlier in this thread.
If you look at the boot logs for CycloneV vs Arria10, the Arria10 uboot log contains this line

FPGA: Start to program core bitstream …

While that from the CycloneV does not. Perhaps the CycloneV is not meant to be able to be programmed from u-boot in the new “official” flow?

Hello @jackfrye11,
well, the source code of U-Boot is part of Intel SoC EDS in a form of archive here:
“C:\intelFPGA\18.0\embedded\host_tools\altera\bootloaders\u-boot\uboot-socfpga.tar.gz” (of course, the path depends on Yours host OS, EDS version etc.).
However, the archive is of version 2013 (but this is not important) and is not meant to be extracted by You directly. It should be extracted with a tool called bsp-editor. This tool also adjusts the source code of U-Boot according to the hardware specialities of Your Quartus Prime project. You have to execute the bsp-editor tool from SoC EDS commad Shell.
I am sorry, I could not find the documents, where this is described.
Just do:

  1. Open SoC EDS Commnad Shell
  2. Type ‘bsp-editor &’
  3. Follow the instruction of 4th Chapter of Embedded Linux Beginners Guide
  4. Post generating source code with bsp-editor type ‘cd {folder of Yours Quartus Prime project}/software/spl_bsp/’
  5. Type ‘make’. The preloader will be compiled (it takes some tens of seconds), so a file preloader-mkpimage.bin will appear at the folder.
  6. Copy the preloader somewhere, e.g. to the root directory of the Quartus Prime project
  7. Type ‘make uboot’. The U-Boot wil be compiled (it takes some minutes), so a file ‘uboot.img’ will appear at the folder.
  8. Copy the U-Boot somewhere, too.
  9. The Preloader an U-Boot could be copied onto Your SD card now. You could use tool called alt-boot-disk-util form SoC EDS Command Shell. If You do not know ,how to use it, type ‘alt-boot-disk-util --help’.
    Hope this will help You a bit.
    Yours sincerelly Jan Konečný.

I guess I can use the v18.0 version of the tools. In the 19.1 version of the tools, when I follow your instructions and I get to step 5, after running $: make, I get

jfrye@jfrye-Inspiron-5547:~/Documents/FPGA/Intel/de1-soc_ref/Demonstrations/SOC_FPGA/hps_dma/software/spl_bsp$ make
Please visit Building Bootloader for Stratix 10 and Agilex | Documentation | RocketBoards.org for instructions on how to build the bootloader.

Hi @jackfrye11,

Did you manage to program the fpga?

I’m having the same issue using a cycloneV soc.

@RicardoSilva
Sorry, I haven’t had any luck. Perhaps next weekend I will perform a hardware build from scratch in Quartus 19.1 with HPS connected to GPIO in the FPGA then try to build the software around that and see if it works.

My current setup was to take the Terasic example designs ( https://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=205&No=836&PartNo=4
Under CD-ROM ) from the older versions of the tools, upgrade the IP, and rebuild. Perhaps there is some dependency that is broken in that process.

@RicardoSilva
Just did a Quartus 19.1 build from scratch following the HPS setup in this guide.

Section 9.3 SYSTEM DESIGN WITH QSYS – HPS
Rebuilt all software as from before. Same error.

Will try using Bitbake to build everything. The maintainer of this layer assures me that everything should work

Will let you know if I have any luck

I am neck deep in this issue right now. I really got stuck with the .dtb not working. I spent a day thinking there was something wrong with the kernel… but sopc2dtb does not work at all for me, not with a recent (5.4.x) kernel and 19.1 versions of Quartus standard.

I finally figured out I have to use the .dtsi files from the Kernel, and manually add in the information from my system --kind of a pain, would sure like to have a ‘process’.

I’m going to dig into the docs on DTS, and build myself a working .dtb. The final thing will be to try and load the fpga in u-boot.

I’ve seen 2 sets of code for u-boot. One seems to be an older version, and includes a boot.script file, that you compile into u-boot.scr. This file looks like this (example only)

echo -- Programming FPGA --
fatload mmc 0:1 $fpgadata soc_system.rbf;
fpga load 0 $fpgadata $filesize;
run bridge_enable_handoff;

echo -- Setting Env Variables --
setenv fdtimage soc_system.dtb;
setenv mmcroot /dev/mmcblk0p2;
setenv mmcload 'mmc rescan;${mmcloadcmd} mmc 0:${mmcloadpart} ${loadaddr} ${bootimage};${mmcloadcmd} mmc 0:${mmcloadpart} ${fdtaddr} ${fdtimage};';
setenv mmcboot 'setenv bootargs console=ttyS0,115200 root=${mmcroot} rw rootwait; bootz ${loadaddr} - ${fdtaddr}';

run mmcload;
run mmcboot;

After some digging into older (2013 ish) versions of u-boot source code, I found some code that creates environment variables in u-boot enviroment like fpgadata, and also a script for the bridge. Newer versions of u-boot source (git checkout a newer branch) do not populate those values, i.e. $fpgadata, and others. So, it seems as if it isn’t possible to do this programming.

I’ve tried to manually set fpgadagta to 0x0200000, and some other values (just guessing there), and I’ll get fpga load to “work”, but the fpga won’t actually program, so not really working.

Anyway, I’m still looking for a way to do this, and maybe the newer versions of u-boot have a different technique? If so, I’d like to find the (any) documentation on it.

Hey @sharpertool . I was stuck on this for months. Take a look at some of the stuff here.

(I reopened this question like 3 times when the problem ended up being misconfigured dip switches on my board.) This post has a lot of the elements/details I used to get my system working.

My recommended plan of action would be the following:

  1. Replicate what I have done. Get the thing to boot with
    linux-socfpga/arch/arm/boot/dts/socfpga_cyclone5_socdk.dts at socfpga-5.5 · altera-opensource/linux-socfpga · GitHub

  2. Only once that is complete would I start playing with their device tree generator. I would compare to make sure that what it is generating has all the important hard stuff (MAC, etc) in the reference device tree. I also would not rely on it recognizing all of its own (proprietary Altera/Intel IP) peripherals. Even if it does, there is still the matter of ensuring that there is built-in kernel support and that you actually enable it when you build the kernel (I have not done this).

At this point, you will have to deal with your own peripherals. Are you doing custom IP in this design? I do not know if you are able to somehow integrate the Quartus IP development flow into their device tree generator tool. (Maybe you could fill me in on this one).

Obviously the tradeoff is

  1. How complicated the IP you are using is + driver support - how good the drivers actually are
    vs
  2. How quickly you can get something up and running.

For example I do not know if they have a PIO driver in their kernel, but I was trying to light some LEDs on my board. In that case, rather than going through device tree madness and driver kernel build config/platform device driver registration and figuring out how to use their software, I simply used /dev/mem and hit the registers manually. If it is something monstrously complicated like a soft MAC, maybe you go with their driver.

As you probably know, the benefit of loading at u-boot stage is that such kernel drivers can probe during kernel boot and set up/configure devices in the fabric.

hey : struck for a month and still struggling with loading FPGA configuration … from u-boot.scr , every time getting failed with error -6,

are you guys able to get over this problem…?.. what is the solution…?

Are you sure you have the right configuration of DIP switches for you board? I had to put mine in a special configuration to allow programming from u-boot. What board are you using?

You can find the meaning of failure code here if it helps

I am using cyclone V DE1 Soc ; quartus prime lite edition 20.1 with EDS 20.1 standard… set my MSEL as 01010

I am following [this tutorial]( rsyocto/7_customVersions.md at rsYocto-1.04 · robseb/rsyocto (github.com)). and getting error -6.

I also tried to generate sd card image. by following [this tutorial]( Building Bootloader | Documentation | RocketBoards.org). but nothing shows up in putty terminal.

I am trying to route spi peripheral through fpga…

are u aware of that robseb / yocto project…?

Try MSEL=00000

I made same mistake and was stuck for months. Look at DE1-SoC User Guide Table 3-2. The third option. FPPx16 is the on with U-Boot in the description and is MSEL=5’b00000.

Tried … but nothing appears in putty terminal.

I have few questions…!

  1. There are 3 files zimage , roofs##.tar.gz and dtb. : do i need to generate this file every time i generate the sd card image and copy it to vfat partition… or i can use these 3 files from any other source…? like i followed [this tutorial]( Building Bootloader | Documentation | RocketBoards.org) ans downloaded the zimage, rootfs.tar.gz and dtb from [here]( Index of /release/2020.07/gsrd/cv_gsrd (rocketboards.org)).

later i copied these files to fat partition. ? will it work can i do this…?

I think you can use those files. You may need to untar the rootfs. If you are seeing nothing in your terminal then my guess is that you are not putting the files on the sd card properly since those listed files should not effect u-boot, which will be the first thing to display stuff in your terminal. I will add post with the files I use to make the SD Card image

See the python file and shell script that calls it with the correct arguments here

This assumes same directory structure (with decompressed rootfs under rootfs directory, u-boot sfp file, and ext4linux under sdfs directory) in same structure of the guide for building bootloader to boot from SD.

Thanks for the files you provide…

I followed every steps. as describe in this Cyclone V SoC GSRD | Documentation | RocketBoards.org … (extracted the rootfs.tar.gz in the partition which i downloaded from []here](https://releases.rocketboards.org/release/2020.07/gsrd/cv_gsrd/) … and in the last i executed your sd_call.sh after giving proper permission to it…

but still i did not see anything in putty terminal…!
can you share your project files … ? i want to see if things really work…?

See sd_card_files.zip on Google Drive listed above. Should be able to directly load sdcard_cv.img onto your SD then boot. You can also see rootfs and the output files from my u-boot and kernel builds.

Thanks a lot Now everything works as the way i want… SPI is successfully routed through fpga and able to generate a sdcard image.

Thank you for your support. :grinning: :grinning: :grinning:

A bit late, but I was struggling with latest u-Boot and de1-soc. Same as posted here, nothing appear on UART.

Found out that the u-Boot de1-soc .dts is missing a critical line.

File: arch/arm/dts/socfpga_cyclone5_de1_soc.dts

Modify

&uart0 {
	u-boot,dm-pre-reloc;
};

for

&uart0 {
	clock-frequency = <100000000>;
	u-boot,dm-pre-reloc;
};

Then it worked.

Hi! Thanks @ehoffman for your fix, this worked for me and I upstreamed it into U-Boot here: socfpga: fix the serial console on DE1-SoC · u-boot/u-boot@a5e490f · GitHub