Building Bootloader CycloneV u-boot.scr

#1

Is there a way to get the bootloader to use u-boot.scr instead of extlinux.conf?

Using CycloneV and u-boot-socfpga source from:

git clone https://github.com/altera-opensource/u-boot-socfpga
git checkout -t -b test origin/socfpga_v2019.04

#2

Change files
include/config_distro_bootcmd.h

-#define CONFIG_BOOTCOMMAND "run distro_bootcmd"
+#define CONFIG_BOOTCOMMAND "run callscript; run distro_bootcmd"

include/configs/socfpga_common.h

#define CONFIG_EXTRA_ENV_SETTINGS \
	"fdtfile=" CONFIG_DEFAULT_FDT_FILE "\0" \
	"bootm_size=0xa000000\0" \
	"kernel_addr_r="__stringify(CONFIG_SYS_LOAD_ADDR)"\0" \
	"fdt_addr_r=0x02000000\0" \
	"scriptaddr=0x02100000\0" \
	"pxefile_addr_r=0x02200000\0" \
	"ramdisk_addr_r=0x02300000\0" \
	"socfpga_legacy_reset_compat=1\0" \
        "scriptfile=u-boot.scr" "\0" \
        "fpgadata=0x2000000" "\0" \
        "callscript=fatload mmc 0:1 $fpgadata $scriptfile;" \
        "source $fpgadata" "\0" \
	BOOTENV

I cannot seem to get my FPGA to load however.
See CycloneV: Programming FPGA from U-Boot for details

#3

Hi,

Thanks for the reply.

The following two lines in u-boot.txt (becomes .scr) work to load my fpga. soc_system.rbf is the fpga code.

fatload mmc 0:1 $fpgadata soc_system.rbf;
fpga load 0 $fpgadata $filesize;

I have the bootloader and u-boot booting all the way into Linux, but it then reboots after a bit and this behavior repeats. If you have any ideas about this, I would appreciate it.

#4

What board are you using? Any chance you can post your rbf? I have been trying to get the FPGA to load from u-boot for like a month. I will change my script to match yours exactly.
As far as the problem you are having now. At one point I was trying to write to /dev/mem to a GPIO and I had the kernel reboot on me. Still have no idea what was causing it. My best guess is that there is some errant FPGA2HPS interrupt, although whether it is caused by your hardware design or something in the kernel, I have no idea. I would begin by investigating irqs in the CycloneV manual and see if there is one that might cause a kernel reboot and what would trigger it.

#5

Hello @jmurray2817 and @jackfrye11,
repeated rebooting post changing FPGA design could be caused by that phenomenon, that the preloader is compiled according to pin selection of the original FPGA design while the pin selection of the already loaded FPGA design differs.
Look at the following example of Pintable at Qsys:

Qsys%20-%20HPS%20Peripherals
Qsys - HPS Peripherals.png1095×335 20.2 KB

If the original FPGA design uses GPIO 00 and the new FPGA design uses peripheral EMACS0, then the driver of ethernet EMAC0 at Linux will try to communicate via ethernet post loading new FPGA design. However, the pin matrix of the chip had been set with the preloader for the original FPGA design which uses GPIO 00 at the same pin. So, writing to TX_CLK port of EMAC0 will just toggle GPIO 00.
You can image much worse cases while the configuration of HPS changes in a more complicated way.
Due to this reason, reloading of FPGA design could not be absolutelly universal, it must respect the used preloader.
Is my explanation clear?
Hope it will help You a little.
Best wishes, Jan Konečný.