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