Hi all. Does anyone know if the SPL has support for loading an FPGA (.itb) file from an EXT4 filesystem?
I have modified the <u-boot_recipe>-u-boot.dtsi so that the SPL picks up my fit_spl_fpga.itb from the /boot partition of my rootfs located on partition 3, which is a EXT4 filesystem:
It seems to be able to program the peripheral fine, but once it tries to program the core it fails almost instantly, giving me a fs_devread %s read error - block
Does anyone have any experience with this? Is it possible?
It doesn’t seem like the SPL has support for reading from an EXT4 filesystem, whereas u-boot does.
Again, without any knowledge of Arria 10 devices, can you load it from u-boot instead using a script that can be modified based on which ext4 partition you want to load it to? i.e. instead of modifying the device tree, just change the u-boot script?
I’m not sure about itb files, but on Cyclone V you can load rbf files in u-boot from fat using something like:
For Arria 10, the FPGA is split into a peripheral and core section and the SPL must program at least the peripheral (DDR and IO initialization). It can also program the core (core FPGA design), or you can alternatively wait until u-boot to program the core using a script as you suggested.
However, ideally what I would like is to be able to have one .itb file (with core + peripheral) for each rootfs on an EXT4 partition. The SPL would then pick up the correct FPGA depending on which rootfs I’m booting into.
I could have one peripheral .itb file in a FAT partition that the SPL could load, and then in u-boot pick up the correct core from either rootfs BUT, the core and peripheral must be a matched pair i.e the one peripheral .itb file in the FAT partition would be out of sync with one or both of the core FPGA images on the ext4 partitions.
If you want to change the peripheral location without rebuilding the preloader, there appears to be some “secret” environment variables that might let you reference a different device /location (looking at fs_loader.c) if you remove them from the u-Boot device tree.
storage_interface=mmc
fw_dev_part=0:3
Using environment, you could let the uBoot TPL also use the same variables to force both SPL and u-Boot to reference the same partition…
I don’t make use of the TPL, just SPL → u-boot → Linux. Is there a benefit to having the TPL load the core instead of u-boot? I just don’t know much about the TPL as I haven’t had to use it.
Sorry, the terminology I have is the TPL (third program loader) is u-Boot running out of DRAM, the SPL (secondary program loader) is the what used to be called the “pre-loader”, running out of SRAM. u-Boot is much faster at accessing data for programming, so is desirable for CORE loading.
Yeah my knowledge/experience with the TPL is pretty much non-existent!
But, I do think what you are suggesting is what I am currently doing in u-boot. I am deferring the programming of the core until I am within u-boot i.e more suitable for faster programming (and can handle loading bigger files, such as the core .itb, from an EXT4 partition). The SPL doesn’t seem to be able to successfully load files any bigger than ~300-400KB from an EXT4 partition. This is not an issue if the SPL is loading bigger files from FAT, the support seems to be there. Hence the reason for this thread, just to see if anyone else had tried this.