.elf file explained?

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.

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.

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?

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

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

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

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.

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.