Getting started with bare-metal application development with the Cyclone V

--- Quote Start ---

Thanks so much!

I'll probably need a bit to digest all of this and run through those tutorials. But I just wanted to pop on and say thank you!

--- Quote End ---

Easier way is to follow some example design walk through from the soc eds guide document. You will able to get more idea from there.

https://www.altera.com/literature/ug/ug_soc_eds.pdf

Here are some other bare-metal resources I found:

getting started with arm ds-5

http://ds.arm.com/developer-resources/tutorials/getting-started-with-arm-ds-5-development-studio/

Some good getting started info on DS-5, like licenses, creating a bare metal app from scratch. Goes thru building an output image, but not downloading to the board and running.

Goes into "Debugging the application on a Fixed Virtual Platform (FVP)".

launch and debug a bare metal application on the arrow sockit board

http://rocketboards.org/foswiki/view/projects/launchanddebugabaremetalapplicationonthearrowsockitboard

I sometimes had some odd problems in DS-5 with this process, like I was getting "Target Message: Count not determine target state."

building bare-metal applications in ds-5 using gcc compiler

http://ds.arm.com/debugging-bare-metal-applications-on-fvps-using-ds-5-and-gcc-compiler/

Uses GCC compiler but recommends ARM Compiler.

tutorial: altera cyclone5 soc baremetal from scratch, from sam skalicky

https://samskalicky.wordpress.com/2014/06/06/tutorial-altera-cyclone5-soc-baremetal-from-scratch/

May be a good procedure but includes no content for a C file. I added my own Hello World C file.

Attached is a process for launching and debugging a bare-metal app. I believe the document came from an Arrow/ARM workshop and I have modified it to make sense to me, and have removed those parts that I did not need. Also attached is a zip file with about 40 examples. The one used in the procedure is called "Altera-Cyclone-V_RAM," which runs a Hello World app from RAM on a dev board. This was intended for the Altera SoCkit board, but I believe you can easily adapt it to other dev boards. You will need ARM's DS-5 Altera Edition software, also known as Eclipse apparently. I don't know if straight DS-5, not Altera Edition, will work.

The zip file came from an Arrow/Altera FAE. Keep in mind, the process in the .docx shows you how to run the app in debug. I have not figured out how to run the app in Release mode, or how to cause the board to boot and run the code by itself, presumably from the QSPI flash. Please let me know if you know how to do that.

Ron

Hi there,

I am looking for the same.

Any updates/news here?

Thanks,

Marcelo.

--- Quote Start ---

Thanks so much!

I'll probably need a bit to digest all of this and run through those tutorials. But I just wanted to pop on and say thank you!

--- Quote End ---

Hi ttustudent,

Have you made any progress yet? Could you please share your experience with us?

I'm in a similar situation like you when you started this post.

Thanks

Thanks so much!

I'll probably need a bit to digest all of this and run through those tutorials. But I just wanted to pop on and say thank you!

--- Quote Start ---

Thanks again for replying so fast slacker man.

You're right U-Boot is bare metal code. I guess I'm just a bit overwhelmed with everything. I'm trying to look for something that will let me start playing with examples. Lets say you were just starting out with the Cyclone V, what would you do? Are there basic bare-metal tutorials in existence? They have to be really really basic as I've never coded in VHDL OR coded with an Arm Processor.

--- Quote End ---

Yes, the bare-metal tutorials are in the examples directory that I mentioned in my last post. They are documented. There is one hardware reference design called the GHRD or GSRD.

--- Quote Start ---

We have to certify all the code that goes on the ARM and Linux can never be certified so that's whey we can't use it. I'm really a hardware guy but I'm looking to get int SoC's.

What I don't know :

• How the ARM interfaces with the FPGA
  --- Quote End ---

There are several bridges going to or coming from the FPGA. From the "HPS" (ARM side), there's a lwh2f bridge and a "full weight" bridge. They are memory mapped into the HPS (ARM's) address space. One of the HWLib software examples "releases" the bridges and does some blinking of LEDs via FPGA connected LEDs.

--- Quote Start ---

• How to assign pins to VHDL code
  --- Quote End ---

Via the Quartus II GUI or, directly, in Quartus's .qsf file. There are plenty of examples of this.

--- Quote Start ---

• Running anything on my Eval Board
  --- Quote End ---

I think you're asking more about how the SoC boots than anything else here. On boot, the second cpu (CPU1) is always held in reset and will remain that way until the first cpu (CPU0) releases it from reset.

CPU0 runs the code hardcoded in the SoC's BootROM which reads the BSEL (and CSEL) pins to determine where to boot from and how the clocks are configured. For instance, if the BSEL pins are set to SD Card mode, the BootROM code instructs CPU0 to grab the Preloader (u-boot "SPL" for "secondary program loader") from the SD Card, load it into onchip RAM and execute it.

The Preloader is responsible for configuring the SDRAM and peripherals for operation (there are several steps here), optionally loading an FPGA image and then passing control onto the BootLoader (usually u-boot) or the user's application. The Preloader is where "handoff" must happen between Quartus II/Qsys (hardware tools) and the software that must eventually run.

--- Quote Start ---

I'm guessing there aren't too many folks working on this bare-metal problem or I would find more tutorials, walk-through, and documents on the subject. i would love love a 'hello world' program that would just help me getting a blinking led on my eval board.

--- Quote End ---

One of the examples does pretty much everything you want, though not in a "Hello, World!" format. Look for the FPGA HWLib example and debug it using DS-5. It should do most of what you want.

On the ARM processor front, they have 3 classes of cores: A, R, and M (clever right?). The "A" cores are intended to be "application" (think OS) processors. The "R" cores are intended to be "realtime" (think hardware lock-step and the like). The "M" cores are micro-controllers. While it's definitely possible to run any of these cores out of the space they were designed for, it's not what ARM recommends and (in some cases) it can be a pretty extreme uphill path.

Hope this helps!

Cheers!

slacker

People discount bare metal development, but anything that needs higher levels of certification won't be using Linux so far as I've been able to tell. Lot of cars and planes out there to casually dismiss the bare metal market... Not to mention medical devices, factory/robot automation controls, etc.

I'm somewhat in your position. I'm a software guy that needs to look into the FPGA end. I haven't seen anything special about ARM that would make it harder to do bare metal development than any other modern chip. Not simple but certainly doable. The software documented in C:\altera\13.1\embedded\altera\hps\altera_hps\doc would be a good place to start. Also look in the Altera EDS documentation.

The ARM interfaces to the FPGA over AXI 3. Altera provides IP which will can convert it to the Avalon bus used in Nios. I've decided to use Avalon because it looks simpler than AXI. See the Avalon bus specification for details. I'm planning to create a component in QSYS with a slave Avalon interface. I'm currently trying to write some Verilog code to talk to the ARM.

You assign pins to your FPGA with a sdc file. There are plenty of examples for that. Don't restrict yourself to looking at the Helios board only.

I've been writing my code and FPGA images to an SD card. The preloader programs the FPGA at power on, then runs my ARM code. Lots of examples on how to do this too.