Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Altera_Forum
Honored Contributor I
1,696 Views

.elf file explained?

Hello! 

 

I have just watched the ALTERA Embedded Design Flow video tutorial and at some point at the end it is explained how the user can program a flash memory with: 

 

- A boot loader 

- The FPGA .sof image 

- The .elf file 

 

and I was wondering what is the structure of a sof file (less important for me) and most important what is the structure of an .elf file. 

 

I mean after the compilation there are stack, heap, code and data segments? And what does each of them represent? Also Is the elf file directly copied as is into the flash or is it restructured before saved to flash (in other words does Nios execute the actual elf file as it is?)?
0 Kudos
22 Replies
Altera_Forum
Honored Contributor I
63 Views

ELF stands for Executable and Linkable Format 

If you google, you should be able to find lots of information about this file format.
Altera_Forum
Honored Contributor I
63 Views

Yes I know that but I am not sure if it applies also for the Nios processor. Is there any dump command indise the EDS to handle/see/dump elf files?

Altera_Forum
Honored Contributor I
63 Views

For your other question, .ELF is converted to .flash (Motorola S-Record). 

 

The .POF (Programming Object File) is special from Altera to their FPGA. You might not find information about the structure.  

But altera give tools to create a .pof with the .sof(to configure fpga), and flash (with special boot loader). That is in the tutorial you are reading. 

You download the .POF to an EPCS serial memory. So it will be size-limited (the size is not a constant because of an eventual "compression"). 

 

Nios can execute the .ELF as is. This is what you do when you "Ran as hardware" from Eclipse NIOS II SBT. It executes from RAM directly. 

 

When the program is in FLASH, the boot loader tells NIOS to first copy the content to RAM and then Nios executes from the RAM.
Altera_Forum
Honored Contributor I
63 Views

Hey thank you!! 

 

So in my Qsys system I only need to insert an external SDRAM interface module as far as the memories are concerned. I shouldnt insert an on chip ram for the heap and stack as they will be included inside the same external SDRAM. 

 

The copying of the program from the flash to the RAM (boot loader) is done by Nios? If so should I include an EEPROM memory interface inside the Qsys system? (I am using the DE0-Nano board so I have a 32MB external SDRAM, an external 2KB I2C EEPROM and a non-accessible from user code 16MB EPCS EEPROM)
Altera_Forum
Honored Contributor I
63 Views

The simple altera examples use a single memory block for code, data, heap and stack. 

Probably because this is the easiest one to explain and demostrate in any training. 

Depending on what you actually intend doing, a lot of these examples aren't (IMHO) especially useful.
Altera_Forum
Honored Contributor I
63 Views

Haha I liked the IMHO (In My Humble Opinion), never heard it before!! 

 

Basically my application is not very demanding. I just need to have everything (.SOF, .ELF running only in SDRAM plus heap stack also in SDRAM) stored in the EPCS and on-power on the FPGA gets configured and the Nios starts reading instructions from the SDRAM. 

 

If this operation involves a boot loader that is created automatically and does not need me to incorporate the EEPROM interface so as to copy the elf to SDRAM then it fits me well. 

 

Is this process automatic?
Altera_Forum
Honored Contributor I
63 Views

AFAIK (As Far As I Know :-D) the Boot Loader is executed by NIOS. So you need to incorporate a EPCS (on which you want to store FPGA config, ELF or equivalant for programm, and special boot loader) interface. I saw this interface in Altera QSYS components, but never tried. 

 

I saw a few examples that do that. There is a "default" boot loader from Nios II SBT. 

 

Look at http://www.alterawiki.com/wiki/epcs_bootloaders 

 

AFAIK, IMHO, BTW..... and RTFM (= "Read The F°ck1ng Manual !" :-D)
Altera_Forum
Honored Contributor I
63 Views

Wow.... 

 

I need an interface for the EEPROM (EPCS). The thing is that I have a DE0 Nano and the EPCS is not available for user code (only for initial FPGA configuration). 

 

I am also a RTFM guy but the problem is that there is such a plethora of tutorials, applications notes, manuals, userguides etc etc etc .....and videos that don't get me wrong here but most of them only scratch the surface in between the marketing power point bullet lists (ssshhhhhh....). 

 

So there is also an altera wiki site. Thats good.
Altera_Forum
Honored Contributor I
63 Views

After initial FPGA configuration, the EPCS can be accessed through the EPCS serial flash controller. 

The Qsys ECPS serial flash controller will also contain the bootloader code required to copy the data from the flash to the SDRAM.
Altera_Forum
Honored Contributor I
63 Views

Hey thanks for the answer. But what are the pins that DE0 Nano gives the user to access the EPCS? I didn't see any in the manual...

Altera_Forum
Honored Contributor I
63 Views

The access is done through the same pins used for configuration. 

The FPGA has a special hardware block for that purpose. Usually, it doesn't involve any pin assignment. 

You just instantiate the EPCS serial flash controller core and it will automatically be connected to the EPCS.
Altera_Forum
Honored Contributor I
63 Views

Understood. But the bootloader is run by Nios and Nios needs to access the EPCS through the Qsys interface. In order for that to happen don't I need to export the EPCS interface wires to some pins? Or you sa that this gets done automatically without exporting the pins to the top level entity?

Altera_Forum
Honored Contributor I
63 Views

If you instanciate the EPCS boot code the pins are automatically assigned to a SPI hardware block assiciated with the EPCS boot code. 

 

It is all a PITA. 

The EPCS SPI block is only available attached to the boot code (I think this is so that the boot code can access it at a known offset from the program counter). So it you want to use the EPCS SPI interface (but not boot from it) you have to waste the memory block. 

I also did some quick ball-park calculations and think that a 100MHz nios cpu could directly bit-bang the EPCS memory almost as fast as it can be driven by the SPI block. Since the most likely reason for such accesses are writes, the speed of the transfers won't be the limiting factor. 

Even a factor of 2 or 4 slowdown in a read-verify wouldn't really matter. 

The direct bit-bang code would also be a lot smaller than the existing nested morass of code of the HAL EPCS functions.
Altera_Forum
Honored Contributor I
63 Views

Thats a lot of information! 

 

Where can I find some more information on the automatically created boot loader? Is there any dedicated tutorial on the flash or quartus programmer (whoever creates the boot loader)? 

 

Also I would like to know what happens when the Nios first gets configured as part of the FPGA. Does it start automatically to run the first instruiction from the base address?Is there any other action done before that?
Altera_Forum
Honored Contributor I
63 Views

 

--- Quote Start ---  

Understood. But the bootloader is run by Nios and Nios needs to access the EPCS through the Qsys interface. In order for that to happen don't I need to export the EPCS interface wires to some pins? Or you sa that this gets done automatically without exporting the pins to the top level entity? 

--- Quote End ---  

By default, it gets done automagically.You can do it manually, but there's no point unless you want to use a second EPCS device which isn't the one used for configuration.
Altera_Forum
Honored Contributor I
63 Views

 

--- Quote Start ---  

Thats a lot of information!Where can I find some more information on the automatically created boot loader? Is there any dedicated tutorial on the flash or quartus programmer (whoever creates the boot loader)? 

--- Quote End ---  

Check the Embedded Peripheral user guide.Also, check the link dsl provided before for alternative boot loader code. 

--- Quote Start ---  

Also I would like to know what happens when the Nios first gets configured as part of the FPGA. Does it start automatically to run the first instruiction from the base address?Is there any other action done before that? 

--- Quote End ---  

Yes, it starts running the instruction at the reset vector address. For it to boot from the EPCS, the reset vector address must point to the bootloader code in the EPCS controller memory block.
Altera_Forum
Honored Contributor I
63 Views

 

--- Quote Start ---  

The EPCS SPI block is only available attached to the boot code (I think this is so that the boot code can access it at a known offset from the program counter). So it you want to use the EPCS SPI interface (but not boot from it) you have to waste the memory block. 

--- Quote End ---  

If you want to save the memory block, you can build your own EPCS controller slave based on the ALTASMI_PARALLEL function. 

--- Quote Start ---  

I also did some quick ball-park calculations and think that a 100MHz nios cpu could directly bit-bang the EPCS memory almost as fast as it can be driven by the SPI block. Since the most likely reason for such accesses are writes, the speed of the transfers won't be the limiting factor.Even a factor of 2 or 4 slowdown in a read-verify wouldn't really matter.The direct bit-bang code would also be a lot smaller than the existing nested morass of code of the HAL EPCS functions. 

--- Quote End ---  

http://www.alterawiki.com/wiki/epcs_bootloaders has a 380 byte bootloader written in ASM with multiple image support.I doubt it's possible to write an equivalent bit-banged bootloader in much less code.
Altera_Forum
Honored Contributor I
63 Views

When I tried to build my own epcs 'controller', I failed to get the io pins marked as 'dual purpose' - all greyed out. 

 

There might be a 380 byte bootloader, but look at the size of the HAL functions for later access. 

In any case the bootloader has an entire memory block to play with - so it doesn't matter much provided it fits.
Altera_Forum
Honored Contributor I
63 Views

Were you using the ATLASMI_PARALLEL? Or were you trying to roll out your own serial logic?  

The former works. In fact, I think it's a building block for the EPCS flash controller core. 

I never tried the later.
Altera_Forum
Honored Contributor I
22 Views

Thanks a lot for the information!

Reply