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

[Altera_Forum]

First post! 

 Hello fellow FPGA enthusiasts. This is my first foray into the wide world of SoC development.  A bit of background. I'm pretty much fresh out from University and work for a consumer product development firm. I'm a fairly good C coder. I did mess around with Verilog in school on a Spartan-3E FPGA but it never got very complex and thats been a few years.  Anyway, I've been instructed to build familiarity with the Cyclone V. I was given the helio cyclone v soc evaluation board. My question is this, How do I get started? The quick start guide that comes with the device pretty much only tells me how to get started with Linux. I'm looking to start some tutorials that will help me blink some LED's or write 'Hello World' out a serial port. I've searched around and haven't found anything that useful. I've got Quartus installed but haven't been able to use it yet. Where can I get sample code to run?   This looks pretty overwhelming from where I sit.  Thank you so much for helping out a newb. I did try and search the site for questions of this nature and didn't have much luck.

[Altera_Forum]

First off, I would be spending lots of time on rocketboards.org if I were you (there's a getting started link for your board there). 

 Baremetal: I would recommend using u-boot as a basis for any "stand alone" baremetal coding. It is straightforward to modify and has a large user base. You might also be able to make use of the DS-5 examples here.  For production, I don't recommend using anything other than Linux on the ARM SoC. Yes, it is possible, but it is non-trivial.

[Altera_Forum]

--- Quote Start ---  First off, I would be spending lots of time on rocketboards.org if I were you (there's a getting started link for your board there).  Baremetal: I would recommend using u-boot as a basis for any "stand alone" baremetal coding. It is straightforward to modify and has a large user base. You might also be able to make use of the DS-5 examples here.  For production, I don't recommend using anything other than Linux on the ARM SoC. Yes, it is possible, but it is non-trivial.  --- Quote End ---     Thank you for your quick reply Mr. Slacker,  I started with rocketboards.com and the quick start guide pretty much tells me how to get Linux up and running on the Cyclone V. In our application we will not be using Linux at all. We pretty much can't, which is unfortunate. I have messed around with U-Boot with the i.MX6 and I don't see how that is going to help me learn the Cyclone V system. UBoot can be used to boot bare metal code but doesn't help learning how to write bare metal code.

[Altera_Forum]

u-boot is, itself, "baremetal" code. You can build on the example apps that are shipped with u-boot and/or extend the console UI to test what you'd like to test by adding your own "cmd_" files or adding to what's already there (hint: look at the "common" subdir for examples there).  

 You can also make use of the HWLibs examples that are shipped with Altera's SoCEDS (@ $SOCEDS_DEST_ROOT/examples/software/Altera-SoCFPGA-HardwareLib-16550-CV-GNU.tar.gz, for example) as a starting point. HWLibs are intended to provide a common abstraction for accessing all of the peripherals (browse the source to see what's supported at this point in time or post here with what you/you'll need.) There's a description of how to import these examples into the DS-5 IDE in the SoCEDS User's Guide.  You can make use of either HWLibs or u-boot as a starting point. u-boot supports more peripherals at this point in time, but may use too many of the "Linux or Linux-like" abstractions for your liking. HWLibs is designed to provide a portable, simple API to common peripherals on an SoC device. I would try both and see which you prefer.  Mind you that "baremetal" usage for these cores (or any Cortex-A series) is not recommended. Do you want to (for instance) split up the two cores and run separate baremetal (while 1()) applications on each? If so, then you are "by design" throwing away a fair amount of the advantages that come with a Cortex-A class processor.  I hope that helps a bit...and Good luck!  slacker

[Altera_Forum]

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.   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 
• How to assign pins to VHDL code  
• Running anything on my Eval Board 

  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. Then at the very least I would have a place to build from. As it is right now, there is no clear path.  Thanks again! :D :)

[Altera_Forum]

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.

[Altera_Forum]

Well, I can now at the very least blink an LED on my Helio board when I push a button. This tells me I have it hooked up correctly and have an extremely basic yet correct understanding of Quartus II! This is only using the FPGA but at the very least it is a start. :)

[Altera_Forum]

--- 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

[Altera_Forum]

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!

[Altera_Forum]

--- 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

[Altera_Forum]

Hi there, 

 I am looking for the same. Any updates/news here?  Thanks, Marcelo.

[Altera_Forum]

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

[Altera_Forum]

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.

[Altera_Forum]

--- 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

[ALTERA-INSUPPORT22]

Assistance Needed: Trouble Running Bare-Metal Code on Cyclone 5 HPS
I am working on intel cyclone 5 hps I have two cores in a processor Core 0 core 1, I want two code to run on two different cores core 0 and core 1 in bare metal .

When I run in jtag mode it works, for jtag i first debug using core 0 where i take core 1 out of reset it, than debug core 1 usign jtag it work

BUT, When i want to run both core usign qspi it only run core 0 not core 1

Here is the step i followed

Firsly, loading preloader
quartus_hps -c 1 -o P preloader-mkpimage.bin

I make an image from bin file of core 0 and place it to qspi

mkimage -A arm -O u-boot -T standalone -C none -a 0x00060000 -e 0 -n "baremetal image" -d core0.bin core0.img

quartus_hps -c 1 -o P -a 0x00060000 core0.img

I make an image from bin file of core 1 and place it to qspi
mkimage -A arm -O u-boot -T standalone -C none -a 0x00100000 -e 0 -n "baremetal image" -d core1.bin core1.img
quartus_hps -c 1 -o P -a 0x00100000 core1.bin

When i restart board only that code work which is in core 0, core 1 code not executing

I am setting cpu1startaddress 100000 apart from that in the code of core 0 also i am using alt_qspi function to to place bin file data in ddr, 

I want to run in smp mode so I also set required aux_control_register smp and fw bit as stated in tech ref manual  

alt_qspi_read((uint32_t *)BL_START/*ddr3 address*/, 0x100000/*qspi address*/, 0x40000);

In linker/scat file core 0 entry point is 0x60000 and

linker/scat file core 1 entry point is 0x100000