It’s difficult to understand what might be happening in light of all the modifications your making to the GSRD Quartus project. A good place to start is to begin with the GSRD (unmodified) and go through all the procedures of generating the files yourself (RBF, bootloader, and DTB) from Quartus. First try with a stock GSRD and make sure your booting and everything is working. After that you can move towards pairing down the QSYS portion and not using the “early release mode” so you have a single RBF and not the pair (if this is what you want). Note that the RBF must be loaded in order to get the HPS DDR working in Arria 10. This was not the case with Cyclone V where the HPS could be used independently (i.e. FPGA not configured until after Linux is booted). The FPGA cannot currently be reloaded in A10 without using the device tree overlay strategy due to the DDR going down in the process. Therefore only a partial reconfiguration can be done after Linux is booted. Some would say they broke things in A10 from the way CV works.
Hope this helps:
You must build uboot on a Linux platform and I’ve only done it for A10 using the SocEDS 16.1 tools.
I’ve followed the procedure below on Ubuntu 16 and Centos 6.5.
Open a SoC EDS embedded_command_shell.sh
%//altera/16.1/embedded/embedded_command_shell.sh
cd <your_quartus_project> then open bsp-editor
% cd
% bsp-editor &
Create a new HPS BSP via the File Menu “New HPS BSP”
Using the dropdown menu labeled “Operating System” select “U-Boot Bootloader (Arria 10 HPS)”
Point to the software handoff directory (hps_isw_handoff) created from the Quartus Compile and click OK
Edit the RBF filename to match the one you created (usually contained in the output folder)
Note: specify the “.periph.rbf” for the GSRD
Note: You can set an option in Quartus to make an RBF at compile time
Manual method:
% cd /output
% quartus_cpf -c -o bitstream_compression=on your_project.sof your_project.rbf
Select the desired boot device (SD/MMC is default for an SD card), Click Generate then Exit
Navigate to the location of the created u-boot in your terminal
% cd <your_quartus_project>/software/uboot_bsp
Build it
% make
Output Files:
U-boot executable with device tree binary wrapped in mkpimage header (write this to SD card):
uboot_w_dtb-mkpimage.bin
Further Reading:
For SD Card - see page 30:
After 3:00pm EST today I’ll be away from the computer until Monday.
Good Luck!
If you cannot compile the stock GSRD then first try using the RBF’s supplied on the card.
When you pair down the GSRD do not change anything related to the EMIF or anything related to clocking or reset. First delete only the obvious non-system related items (like LED, VGA, whatever…).
The EMIF used to be in the HPS block for CV and now it’s required externally for the A10. You should not be changing anything there until moving to a new hardware platform (with different pinout, DDR timing, etc).
I followed your advice and regenerated the uboot_w_dtb-mkpimage.bin for the stock GSRD and installed it and it works well. This seems to indicate that the uboot generation process I am using is Ok and my problem is really in my project. I may have cut too much from the GSRD when I tried paring it down so I am restarting the pare-down and taking it slow. I’ll check at each removal (to the degree I am able to compile). I was intentionally keeping away from the memory but I must have stepped on a clock or reset somewhere and not noticed. this time through I will keep good notes of what connections were removed. I’ll let you know how it goes.
I was successful in getting a clean compile by turning off the display port module and removing its ip support files from the project. The GSRD compiles and creates an RBF as part of the project recipie so I got a new ghrd_10as066n2.rbf which I placed on partition 1 of my SD card and all boots well.
I see that when the GSRD compiled that it does not create an RBF or SOF for ghrd_10as066n2.periph.rbf or gsrd_10as066n2.core.rbf I am Ok with carrying these files along if that helps me be able to load my code into the FPGA but I would like to know how these are created. Earlier I had supposed that these are just part of the partial reconfiguration process but I see from your message that the Arria 10 does not work as I had expected, so maybe partial reconfiguration is not an option. I still would like to know how these files are generated and what I can do with them. I have only scratched the surface of the gsrd pare-down and have more to go so maybe I will find answers as I proceed. Thanks for your sage advice.
I found the Arria 10 CvP manual and see that this is the way to enable the CvP files in the Convert Programming Files dialog. I am going to use the stable (at least able to be compiled) gsrd version I have and make a CvP version that can generate the .periph and .core files. Once I can generate these, and create the uboot (which I have done Ok with so far) I believe I will be in control of creating FPGA code that I can load and execute. (getting pretty close now …)
Great! It sounds like you’re making good progress.
Do you need to load (or reload) the RBF after Linux is booted? The .periph and .core files are part of the “early io release” strategy which I believe is required for partial reconfiguration. You will only get one RBF if you do not have this enabled in Quartus. If you want to re-load the RBF after boot then I believe you must use the early io release strategy and partial reconfiguration. In order to do that with Linux you must use the Device Tree Overlays that Altera supplied and up-sourced in the 4.x kernel releases. You no longer can “dd” an RBF to the FPGA as was done in CV.
It been on my radar but I’ve not yet re-loaded an Arria10 from Linux using the device tree overlay method. So for that I will not be much help. Here are a couple links I previously saved to look at later when I got around to it.
They use the device tree overlay strategy in this workshop
No, I had no plans to reload the FPGA on the fly. I have an application to run and it just runs (and uses as much of the FPGA as needed so no partition fitting issues to deal with). I am only exploring the CvP because that is how I see the Arria 10 boot working (using the .periph and .core RBFs). The CvP doc implies that the reconfigurable part may or may not be used, so in that case my application would all fit into the .core file, and the .periph file describes the interfaces as it does now. This looks like a flat file to me, with an added peripheral description add-on. If there is a second method to accomplish the same I’ll check it out too.
For Arria10 I currently use a single RBF and not the early release pair of RBF’s but both methods will work with the SoCEDS generated bootloader. You just need to specify the RBF filename in the bsp-editor. The only reason I can see to use the early io release (.periph and .core) files is to load or reload the FPGA from Linux.
For your store of semi-worthless knowledge:
We reload Cyclone V’s all the time from Linux using the “dd” command to /dev/fpga0. With Arria10 we’ve decided to have uboot load the Kernel, DTB, and RBF from the Linux ext filesystem rather than the FAT partition. This way we can change which RBF is loaded by using a soft link rather than replacing (or renaming) files on the FAT partition. The only thing left on our FAT partition is a uboot script. Our products only run in one mode or another so this is not something that happens dynamically during normal operation (once at configuration only). One of these days I’ll get around to loading/reloading the RBF’s from Linux but I’ve just not needed to do it yet with our Arria10 product lineup. I understand the power of dynamically reloading a device tree (to match RBF design changes) but I’m also unhappy that they broke the ability to “dd” to /dev/fpga0.
After some work it looks like I circled back to near where I was before.
I have been following the uboot process as before so I beleive it is stable.
I worked backwards in steps from the gsrd to remove more unneeded parts (near to where I was when I saw load failures earlier) and the resulting RBF file loaded and operated (at least Linux was working) with the gsrd uboot in place (so ghrd_10as066n2.periph.rbf was specified in bsp-editor).
When I re-ran bsp-editor to specify the pared down gsrd RBF (which is named ghrd_10as066n2.rbf at present since I have not renamed things) it does not load and shows the same symptoms as reorted earlier. This makes it look like the early release method is preferable over a single part RBF file (which I would call a flat file). My previous assumption was that the earlier failure was because my conversion of the gsrd was somehow faulty, but now I question that.
I had set out to make a CvP (early release) uboot but got side tracked since the available documentation makes it look like you must have a PCIe IP component to get the CvP files (.periph and .core), but I think I can get there without that now. The older documentation for the Cyclone and Arria V FPGAs shows making some manual settings in a quartus.ini file in the project directory to allow the CvP files to be generated. The gsrd does partial reconfiguration with no PCIe component and no quartus.ini file that I can find so I believe I can set the CvP enable in the assignments - Device dialog and try the same test with a .periph and .core file.
I had no success with trying to create CvP configuration using the Quartus ‘Assignments -> Device -> Device and Pin Options’ settings due to errors at the assembler step (it is trying to set up for device EPCQL256 is one, and in other attempts where I changed different options I get pin conflicts - which seem to be irreversible so I have to start the project over again). This was heading in the wrong direction anyway since I really do not want a partial configuration, but i was attempting it just to get something that runs.
Since I was able to boot the trimmed down ghrd with the original ghrd uboot (which uses partial reconfiguration) I took another step at reducing portions of the ghrd and retrying. I was again able to boot and run Linux using the reduced ghrd project (I disabled elements in Qsys, then dropped the IP files in the Quartus project) I further reduced it and tested using the ghrd uboot again. It still boots and operates Linux, so I made another uboot (using bsp-editor) to boot my version of the ghrd_10as066n2.rbf file in anther try at getting a flat file to operate with an HPS. This failed again in the same way as all the past attempts (see below).
what I notice in the messages below is that the response after loading the ghrd_10as066n2.rbf file is that ‘Early Rleease Succeeded’ so it looks like the uboot is still configured for a partial reconfiguration, thugh I intended for a flat file. I was thinking that if I used the RBF that was the result of my project compilation tha t this would create a flat file uboot, but this does not seem to be the case. So there is some other missing step needed to create a uboot that is a flat file configuration. I havent run across it in Altera documentation yet, and I dont see any good indicators in menu options in Quartus or bsp-editor. It look s like I am at a standtill.
Still having same problem. Discovered that when I allow the .periph and .core RBFs to boot (so using ghrd uboot) with my ghrd_10as066n2.rbf it does not actually load my file. It is loading the ghrd program. Trying to load my RBF (by naming it in bsp-editor) does load it and start to run it but the re-boot cycle (shown above) resets and re-loads over and over.
If there is something else needed to make the single RF load work (if nameing it in bsp-editor is not enough) then I would like to hear about it. Otherwise I must have something wrong with my Qys setup. Any suggestions?
I thought I found something in the EMIF IP settings in QSys, where the checkbox for ‘Enable HPS Early Release Mode’ was checked. Since this appears to be related to the messages I have been seeing in boot failure I had hopes that a new run at it would show improvement. Unfortunately that doesn’t seem to have changed anything, still the same boot messages and repeat booting.
jhaberly,
I have moved ahead some in investigating the problems I have with flat design loading but not far enough to see success. So far I have been unable to get a flat design containing an HPS component to be loadable via the SDCard and am looking for any example of how that can be accomplished. I would be happy to send a link to my example design and the steps I take to make its device tree and uboot code. What I keep ending up with is a boot cycle that continually reboots after it has successfully loaded the RBF file (and I can see that the FPGA design has started to run because the LEDs I set start to operate before the board begins rebooting). If you have any insight into flat design use I would appreciate a tip to get me started.
I am pretty sure the board hardware is Ok because the GHRD project loads and runs without problems. At various points in the search I have been convinced that it is a uboot problem or an HPS or memory configuration problem but none has panned out for me so far.
If you have a loadable flat design example I would like to try it. Even if it doesn’t have an HPS at this point working on adding the HPS component to a working, loadable project is at least productive work for me.
Thanks,
Jambie
I do not have anything prepared that would work on the A10 Dev kit, I do have a simple flat design Quartus project for one of our test boards that I used to boot Linux. I could send you if you think it would help. There’s not much in it (an led interface, i2c, misc). Let me know how to get it to you if you want it.
Thanks, i would like to try it. I could learn some from it in any case though I would want to start by converting it to my Devkit. I am no longer sure where my problem lies so I am willing to try anything. I have a ticket open with Altera but so far no activity on it. I expect the project files will be too large to email. If so then do you have a Dropbox or some way to leave them somewhere and send me a link?.(If not I can give you my Dropbox password and you can leave it there.)
If I can get a flat HPD design to load I plan to post it for others. I can’t be the only person puzzling over this.
Let me know when you’ve downloaded it.
This dropbox link will only be good for today.
If you have more issue then I’ll see if I can quickly port it to the A10 dev kit.
Converted the project to Quartus v17.0.2 and updated A10 type to 10as066n3f40e2sge2. Picking my way thru assigning pins locations and trimming as little as possible (but I will not have I2C devices that will make sense to your code so I’ll at least have to turn that off).
I believe I have the problem solved. Thanks for the project help. I used the files and converted almost everything but got hung up an making new pin assignments for my devkit board (I may have had them right but I was being extra-cautious as I didn’t want to create conflicts that cause more problems). As I worked this I got a tip from a vendor to try a different version of GHRD to start since I would not have to modify (and insert new errors) and I would not be stuck because I don’t have the IP license to compile the GHRD. I am going to try to post my solution to a different thread since it really follows the ‘Flat Design’ issue more than the boot problem that the title of this thread is under. Thanks for your help.
