CFI Flash + Stratix V DSP Development Kit

Altera_Forum · ‎03-07-2015

Hi,

I am working with a project which is built around a Stratix V DSP Development Kit. In the system design there is a Nios processor with which I have had problems with the on-chip memory holding its .text section becoming corrupted during reset. As such I am looking at placing the .text section in the CFI flash on the dev board and using the standard bootloader to copy it into the on-chip memory each time it is reset.

I believe this shouldn't be too difficult but I have some concerns about the Flash address map. There is a document that came with the kit which shows the address map (https://www.altera.com/en_us/pdfs/literature/ug/ug_svgs_dsp_dev_kit.pdf) of the CFI flash in the appendix at the end, along with instructions for generating flash programming files for the board update portal.

In the 2012 version of that document, it listed the following commands:

■ For Quartus II .sof files:

sof2flash --input=<yourfile>_hw.sof --output=<yourfile>_hw.flash --offset=0x020A0000

--pfl --optionbit=0x00030000 --programmingmode=PSr

■ For Nios II .elf files:

elf2flash --base=0x0 --end=0x0FFFFFFF --reset=0x071A0000 --input=<yourfile>_sw.elf

--output=<yourfile>_sw.flash

--boot=$SOPC_KIT_NIOS2/components/altera_nios2/boot_loader_cfi.srecr

However these did not match the table showing how the flash is organised, so in 2013 a new version was released which updated the commands to:

■ For Quartus II .sof files:

sof2flash --input=<yourfile>_hw.sof --output=<yourfile>_hw.flash --offset=0x020C0000

--pfl --optionbit=0x00030000 --programmingmode=PSr

■ For Nios II .elf files:

elf2flash --base=0x0 --end=0x0FFFFFFF --reset=0x071C0000 --input=<yourfile>_sw.elf

--output=<yourfile>_sw.flash

--boot=$SOPC_KIT_NIOS2/components/altera_nios2/boot_loader_cfi.srecr

Which does match the flash map.

However, and here is one of the sources of confusion I am having, when I use the latter command for the sof file (haven't got to testing the elf one yet), it the design doesn't get loaded or run properly. If on the other hand I use the command from the original version of the document (with the 'incorrect' address), the design is loaded correctly and runs fine.

So can someone tell me what the *actual* flash map is, because it seems to me that it was not the commands that were wrong in the initial version, but the map itself. Has anyone else had this problem?

Now on to the Nios side of things. Until now I have been using on-chip memory where the elf was converted to a hex file which was in turn embedded in the sof. In this scenario it has been working fine, except when I reset part of the system (I asked about this in another thread but got limited response). So now I want the elf file to be put in the flash and to use a bootloader.

But at this point there isn't any clear information on how to proceed. I've instantiated a generic tristate conduit controller which is connected to the CFI flash pins and mapped into Nios address space. Now I mapped the flash so that it takes address range 0x08000000 to 0x0FFFFFFF in the Nios address space, and have set the reset vector to point to an offset of 0x0 in that memory (i.e. a reset vector of 0x08000000).

But now when I come to try and run the command from the documentation, it says that the reset vector doesn't match the elf, and then sticks all of the code starting at 0x0000000 in the flash which is clearly not correct.

Sould I instead use an offset of 0x071C0000 for the reset vector (i.e. a reset vector of 0x0F1C0000), but then that wouldn't match either.

Or, do I have to move the addresses of all of my other components so that the flash is mapped into the Nios address space at 0x0000000 to 0x07FFFFFF. Then use an offset of 0x071C0000. That would mean the reset vectors do match, but is this actually correct?

There is another region of the flash map called 'user design reset vector' at address 0x0000000, so do I want a reset vector of 0x0000000? If so how do I specify that the application code should be at 0x071C0000, but the reset vector (and bootloader) should be at 0x0000000.

Given that with the sof2Flash commands I noticed that the incorrect address worked fine for the sof, so do I actually want a reset vector of 0x071a0000 like i the original command?

I also notice that the --end in that command is actually pointing to a point far outside the CFI address space - there is only 128MB of flash yet the specified range is 256MB. So why is the command using the --end value it is?

So now I am totally confused as to what numbers to use where.

So, to summarise:

(1) What is the correct address map of the flash on this dev kit? And if what is in the table is correct, why does my design not load when I use those numbers?

(2) How do I connect the flash to the Nios and correctly set up the location of the bootloader and data?

Altera_Forum · ‎03-07-2015

Well, I tried changing the NIOS reset vector in Qsys to have an offset 0x071c0000, a real address of 0x0F1C0000. Then if I run the following command:


elf2flash --base=0x08000000 --end=0x0FFFFFFF --reset=0x0F1C0000 --input=../software/PCIeUltrasound/PCIeUltrasound.elf --output=PCIeUltrasound_sw.flash --boot=$SOPC_KIT_NIOS2/components/altera_nios2/boot_loader_cfi.srec --verbose

It appears to create a flash file where all of the addresses are correct. So it appears that the 'base' value is subtracted from the 'reset' value by elf2flash when it is generating the file. Good to know. I will have to test this on Monday.

But then the question remains, what is the correct address? Do I go with what is in the latest version of the user guide, or do I go with what was in the original one, given that the original one works for the sof file.