Forum Discussion
Occasional Contributor[Noob DE10-nano] Can I deploy a generic rbf from linux using Cyclone V SoC?
Okay I think I figured out how to deploy a generic hardware design to the FPGA. It doesn't really need device trees or configuring the Avalon bus, but it does need a specific linux image.
Here are the steps. First the hardware design:
- Create a simple FPGA only design in Quartus Prime. I used Quartus Prime Lite Edition 20.1. Here is my blinking LED:
module blink ( input clk, output led ); reg [27:0] counter; always @(posedge clk) begin counter <= counter + 1'b1; end assign led = counter[26]; endmodule - Assign the pins using the pin planner. I used `PIN_W15` with 3.3V LVTTL.
- Run the Assembler in Quartus. It will generate the sof in the output_files folder.
- Convert the sof to rbf using File > Convert Programming File. This will open a new window.
- Under 'Programming File Type', select 'Raw Binary (.rbf)'
- Under 'Mode', select 'Passive Parallel x16'.
- Name the output file `soc_system.rbf`.
- In the Input files section, click on SOF Data and click on 'Add File'. Select the sof file. In my case it was at `output_files/blink.sof`.
- Click Generate and close the window.
Here is a screenshot:
On the software side, to deploy this from the HPS, you need to use the console only version of Linux ("Linux Console (kernel 4.5)"). This can be downloaded from the Terasic website.
The reason you can't use the LXDE version is because it makes use of the HDMI output which is connected to the FPGA fabric and the hardware design should be able to work with it. It will still flash the rbf, but linux won't boot.
After writing the console version of the image to the SD card, copy the file soc_system.rbf into the fat partition (where the zImage file is also present).
Next, set the MSEL bits on the DE10-Nano all to on. This is needed for the "Passive Parallel x16" mode that we used.
Now when you insert the sd card and power it on, the design gets flashed and the FPGA fabric now implements your design.
To change the design from Linux, you can scp the new design to the de10-nano, mount the fat partition (which should be /mnt/mmcblk0p1) and replace the soc_system.rbf file there. After that reboot it and it should flash the new design.
This approach can be followed for more complex designs also which use the Avalon bus to interact between the HPS and the FPGA.
- Create a simple FPGA only design in Quartus Prime. I used Quartus Prime Lite Edition 20.1. Here is my blinking LED:
Occasional ContributorOkay I think I figured out how to deploy a generic hardware design to the FPGA. It doesn't really need device trees or configuring the Avalon bus, but it does need a specific linux image.
Here are the steps. First the hardware design:
- Create a simple FPGA only design in Quartus Prime. I used Quartus Prime Lite Edition 20.1. Here is my blinking LED:
module blink ( input clk, output led ); reg [27:0] counter; always @(posedge clk) begin counter <= counter + 1'b1; end assign led = counter[26]; endmodule - Assign the pins using the pin planner. I used `PIN_W15` with 3.3V LVTTL.
- Run the Assembler in Quartus. It will generate the sof in the output_files folder.
- Convert the sof to rbf using File > Convert Programming File. This will open a new window.
- Under 'Programming File Type', select 'Raw Binary (.rbf)'
- Under 'Mode', select 'Passive Parallel x16'.
- Name the output file `soc_system.rbf`.
- In the Input files section, click on SOF Data and click on 'Add File'. Select the sof file. In my case it was at `output_files/blink.sof`.
- Click Generate and close the window.
Here is a screenshot:
On the software side, to deploy this from the HPS, you need to use the console only version of Linux ("Linux Console (kernel 4.5)"). This can be downloaded from the Terasic website.
The reason you can't use the LXDE version is because it makes use of the HDMI output which is connected to the FPGA fabric and the hardware design should be able to work with it. It will still flash the rbf, but linux won't boot.
After writing the console version of the image to the SD card, copy the file soc_system.rbf into the fat partition (where the zImage file is also present).
Next, set the MSEL bits on the DE10-Nano all to on. This is needed for the "Passive Parallel x16" mode that we used.
Now when you insert the sd card and power it on, the design gets flashed and the FPGA fabric now implements your design.
To change the design from Linux, you can scp the new design to the de10-nano, mount the fat partition (which should be /mnt/mmcblk0p1) and replace the soc_system.rbf file there. After that reboot it and it should flash the new design.
This approach can be followed for more complex designs also which use the Avalon bus to interact between the HPS and the FPGA.
New ContributorHi,
First of all, thank you zangman for the tutorial you've built on the DE10-Nano, it has been helpful in my journey!
I am running the SD Card Image for Azure IoT (ubuntu 18.04 LXDE) taken from Terasic's website on my DE10-Nano.
(I'll explain my use case with this linux image, but I believe the same would apply for any linux image that runs a GUI, such as the other LXDE ones provided in Terasic's website)
While ubuntu LXDE is running in the DE10-Nano's HPS, I'm able to flash a new design on the FPGA via USB-Blaster II using Quartus programmer tool runnin on my laptop. When doing this, the DE10-Nano's HDMI output stops sending signal and the monitor screen connected to it goes blank (as expected, since the hardware design which I flashed the FPGA with does not have what is needed for the HDMI output coming from the HPS to work). However, the ubuntu system continues to work, as I can still use UART serial terminal (USB connected to my laptop) and navigate the system normally; I jost lose the GUI.
I understand that the SD Card Image for Azure IoT (as well any other LXDE image) has a .rbf file that is automatically flashed on the FPGA when the system boots, and that this .rbf file has what is needed for the HPS HDMI output to work and be able to see the LXDE GUI on a monitor.
I understand that if I want to flash a new hardware design on the FPGA using quartus and USB-Blaster II while LXDE is running on the HPS and not lose video signal, my hardware design would need to contain something specific for the HPS HDMI output to keep working.
I'm not able to figure out what is this "something specific" that my hardware design needs to have in order for the HPS HDMI output to work. The SD Card Image for Azure IoT does not come with the hardware design source, only in its binary form, so I can't study it to try to understand what HDL/Qsys module(s) enables the HDMI output to come from the HPS. The only hint I've found on the internet is that a Frame Buffer might be a part of the solution, but I can't figure out the rest.
Do you or anyone else have any ideas what the hardware design needs to have in order for the HDMI output from the HPS to work?
Thanks in advance, I don't know where else to find help and I'm trying to tackle this problem on my own for a long time now.
- zangman
@MateusSoares wrote:
I understand that if I want to flash a new hardware design on the FPGA using quartus and USB-Blaster II while LXDE is running on the HPS and not lose video signal, my hardware design would need to contain something specific for the HPS HDMI output to keep working.
This understanding is correct. My guess is the OS outputs to a frame buffer in memory which is then read by the HDMI core on the FPGA using either Avalon memory mapped or stream interface to display on the display.
It is non-trivial I feel and I couldn't find any reference design that shows how to do this probably because of IP reasons.
If you want to do this, I would guess the approach needed would be:
- Try to get a simple HDMI design working (without Linux). The de10 cdrom has one design that does this and you can also see this application note for the HDMI chip used on the de10 - AN-1270
- Next try to find out how the linux framebuffer works i.e. where exactly is the display data being dumped to. Which address in memory, what file descriptors etc.
- Develop a design that reads the framebuffer information from memory and passes it to the HDMI design.
I had briefly looked into this last year and gave up since it looked too daunting. All the best with it.
Separately, I maintain a beginner's guide to de10-nano on github at this link: https://github.com/zangman/de10-nano
Feel free to have a look, I do cover the basics of writing to SDRAM from the HPS which is read by the FPGA using Avalon MM interface.
