Nios® V/II Embedded Design Suite (EDS)
Support for Embedded Development Tools, Processors (SoCs and Nios® V/II processor), Embedded Development Suites (EDSs), Boot and Configuration, Operating Systems, C and C++
12600 Discussions

DE1-SoC - Cyclone V HPS fallback boot from FPGA

Altera_Forum
Honored Contributor II
1,809 Views

We are currently using DE1-SoC boards at a university in our teaching modules - one module dealing with the FPGA side and the other is dealing with bare-metal programming on the HPS. 

 

During the last couple of years that we have run the bare-metal ARM HPS module, we have been relying on a bit of a dirty hack of using debugging scripts to force load a uboot-spl (preloader) and a bare metal program into memory using the debugger within DS-5. This has allowed us to get the students running code and debugging it, albeit somewhat messily. The main issue is whenever the chip resets (one of the things we show is using the watchdog timer for example) it clears away the program and preloader and so it doesn't boot back up - the debugger has to be disconnected and re-launched to get the software back in to place. 

 

There are ways around this, such as placing the application and preloader onto an SD card and booting from that, however this is not an approach which will work for us logistically - it would require buying 100+ SD card readers and microSD cards (which will inevitably get lost or misplaced), and that's not to mention the IT headache of getting the readers and software set up to write to them. Alternatively we could put a preloader on a microSD card that is left permanently in the boards, and have that boot the bare metal application from QSPI flash memory which can be programmed, albeit slowly, using JTAG. However I don't like these approaches. 

 

What I have come to try and do is get booting from the FPGA side set up. We have build our own customised version of the DE1-SoC Computer (actually it was built from scratch with much of the flaky university program IP replaced with stuff that works properly, but anyway, I digress), so adding 64k on-chip RAM at the base address of the HPS to FPGA bridge is not an issue. After much fiddling around over the last few days trying to setup a BSP and compiler the uboot spl over the last couple of days, I finally managed to get the HPS to boot my preloader in the FPGA. I still need to modify the preloader to jump to RAM containing the bare metal application uploaded through DS-5, but that should be fairly trivial (I hope!). 

 

The biggest issue with all of this is the fact that Terasic in their infinite wisdom cheaped out and didn't solder on a DIP switch for controlling CSEL and BSEL to the board - there is a footprint, but rather than soldering a 20p switch they instead hardwired CSEL to 0x0 and BSEL to 0x5 using resistors. This means that the boards as is without modification are permanently set to boot from an SD card. In order to get the board to boot from FPGA I had to do some soldering on one of the DE1-SoC boards to change BSEL to 0x1. I have no desire to do this to 100+ DE1-SoC boards. 

 

Having looked further at the documentation, I see that it should be possible to have the BootROM failback to loading a preloader in the FPGA if it fails to find a valid image in the location that BSEL specifies. My hope was that I could leave BSEL as 0x5 (SD Card), and simply not install an SD card. This would of course mean there is no valid image, and so if set up correctly should failback to booting the preloader in my FPGA image. However, this doesn't seem to work. 

 

I've correctly got the preloader set up in the image, and have adjusted the FPGA design to ensure that the f2h_boot_from_fpga_on_failure signal is tied to 1 (so it should boot from FPGA on failure). Despite this when I try with a board that I haven't changed BSEL on (still 0x5), the board doesn't boot the preloader. Connecting with the debugger I see that the HPS is sat in an infinite loop at ~0x0274 if I recall correctly (I can double check) which isn't in the FPGA, it's probably the BootROM code but without delving deep into the disassembly it's not immediately obvious where it is stuck. 

 

Has anybody been successful with failback boot from FPGA? 

 

Alternatively are there any suggestions as to what might be going wrong here? 

 

I wonder if it is possible that because there is no uSD card present it simply crashes trying to initialise a card that isn't there. I am awaiting a uSD card - once I get it I will try to see if just installing a blank SD card is enough to get it to failback. In the meantime I figured I'd post a query.
0 Kudos
4 Replies
Altera_Forum
Honored Contributor II
623 Views

You can take a look at https://rocketboards.org/foswiki/documentation/bootfromfpga151 

I recalled there is a tie off signal for boot from FPGA on failure
0 Kudos
Altera_Forum
Honored Contributor II
623 Views

 

--- Quote Start ---  

You can take a look at https://rocketboards.org/foswiki/documentation/bootfromfpga151 

I recalled there is a tie off signal for boot from FPGA on failure 

--- Quote End ---  

 

 

Thanks for the reply. But I'm already aware of the signal - f2h_boot_from_fpga_on_failure - and have it tied that to 1 as well as the f2h_boot_from_fpga_ready signal.
0 Kudos
Altera_Forum
Honored Contributor II
623 Views

Never mind. Plugged in a uSD card to the DE1-SoC board - completely blank with nothing on it - and low and behold it correctly falls back to the FPGA and boots my preloader. 

 

Having gone through the area of the disassembly where it gets stuck, it seems the boot rom code is sat in an infinite loop waiting for an interrupt from the SD card. If there is no card, it sits there forever instead of falling back. Seems like bad design to me.
0 Kudos
DPavl3
Beginner
623 Views

To the OP, do you have a working image for the DE1-SoC board? I'm been trying to get one working (using that "flaky" Uni IP catalog) and can't seem to get it working. My goal was to have a Linux installation where I could program the onboard ADC using C-code (HAL - Hardware Abstraction Layer).

0 Kudos
Reply