Configuring NIOS processor through AS interface

Hi, happy new year 2011, best wishes !

To download NIOS II program into flash, with a default scheme, you need JTAG connection. (This is the simpliest way).

I think there is a way to store a program in one portion of EPCS, but i am not sure if it is possible and if it is, it will not be obvious.

++

I am trying to avoid redesigning and rebuilding my PCB with a jtag header.

The solution I am working on right now is converting my .elf to a .hex and setting this .hex as the non-default initialization file for an onchip ram in SOPC builder.

The only other references I have found are using elf2flash and sof2flash but the flash programmer needs a jtag connection as well so I can't program the flash files.

from http://www.altera.com/literature/ug/ug_nios2_flash_programmer.pdf

--- Quote Start ---

nios2-flash-programmer --epcs --base=0x02100000 epcs_controller.flash

Programs an EPCS device based at address 0x02100000 with input file

epcs_controller.flash.

--- Quote End ---

You should make a service request on Altera web site.

You will have better answers.

--- Quote Start ---

the flash programmer is useless without a jtag interface

--- Quote End ---

Yes, this is true.

My bet is that you'll also have to modify the default bootloader for the EPCS controller in your Nios II SoPC Builder system. It must be changed to load/copy the software from a fixed location in the EPCS device in order for your strategy to work. The default bootloader expects the software to follow the hardware in the EPCS device.

Alternately, you could create a reasonably small onchip memory, point the reset address of your processor at it instead, and write your own simplified EPCS bootloader.

- I've attached some sample code that I have used for similar purposes in the past.

Best Regards,

-- slacker

[UPDATE: If not obvious, it is NOT possible to run code directly from an EPCS device.]

--- Quote Start ---

The default bootloader expects the software to follow the hardware in the EPCS device.

--- Quote End ---

So shouldn't there be a way to program both the .pof from Quartus and the .elf from Nios at the same time? I want them both to be stored in the EPCS and loaded from the EPCS.

--- Quote Start ---

So shouldn't there be a way to program both the .pof from Quartus and the .elf from Nios at the same time? I want them both to be stored in the EPCS and loaded from the EPCS.

--- Quote End ---

Yes... You add the SOF to a JIC file, create a HEX file from the ELF (at an offset determined by the bootloader you use) and add it to the JIC as well and then use the QII Programmer to program the JIC to the EPCS device. You can make use of elf2flash to create an SREC and then nios2-elf-objcopy to create and re-locate the HEX that you add to the JIC file.

I seem to recall a document describing this process....somewhere. I'll have a look and see if I can't dig something up.

The FPGA image (SOF) is loaded automagically from the EPCS and, once this is done, the Nios II processor starts trying to execute instructions from its Reset Address...which is where the bootloader needs to be. Basically, you have two options....either modify the existing EPCS bootloader (and keep the Reset Address pointed to the epcs_controller) or create your own small onchip memory and use the code that I attached previously. Regardless of which approach you choose, the Nios II processor copies your "real" program from the EPCS to (presumably) some sort of offchip memory.

Of course, all of this changes if your code is small enough to fit in an onchip memory. Then your code can become part of the FPGA image (SOF) that is initially programmed into the FPGA and the bootloader is not really necessary.

Long story short...it will be a gigantic pain in the butt to develop in this fashion. How hard would it be to dead bug some sort of JTAG connection onto your board?

Regards,

-- slacker

--- Quote Start ---

Yes... You add the SOF to a JIC file, create a HEX file from the ELF (at an offset determined by the bootloader you use) and add it to the JIC as well and then use the QII Programmer to program the JIC to the EPCS device. You can make use of elf2flash to create an SREC and then nios2-elf-objcopy to create and re-locate the HEX that you add to the JIC file.

I seem to recall a document describing this process....somewhere. I'll have a look and see if I can't dig something up.

The FPGA image (SOF) is loaded automagically from the EPCS and, once this is done, the Nios II processor starts trying to execute instructions from its Reset Address...which is where the bootloader needs to be. Basically, you have two options....either modify the existing EPCS bootloader (and keep the Reset Address pointed to the epcs_controller) or create your own small onchip memory and use the code that I attached previously. Regardless of which approach you choose, the Nios II processor copies your "real" program from the EPCS to (presumably) some sort of offchip memory.

Of course, all of this changes if your code is small enough to fit in an onchip memory. Then your code can become part of the FPGA image (SOF) that is initially programmed into the FPGA and the bootloader is not really necessary.

Long story short...it will be a gigantic pain in the butt to develop in this fashion. How hard would it be to dead bug some sort of JTAG connection onto your board?

Regards,

-- slacker

--- Quote End ---

It's good to know that I am on the right track. Unfortunately I misunderstood some very important concepts when I was doing researching and designing the board. I thought a 4Mb EPCS and a Cyclone II with 240k ram bits would be plenty for my design so I didn't include any offchip memory devices. It turns out the CII can only hold about 24k of onchip memory and this isn't enough for a printf in a Nios program.

I may have to drop the Nios all together and see if I can do everything in Quartus.

Thanks for all the help!

Try reducing your code size by using the alt_printf, etc. functions and you can generate some really small (few Kb) code. I wouldn't give up on the Nios II until you've tried your hand at some code optimization.

Also, though it may be obvious now...you should be pointing your Reset Address at an onchip RAM. Start with something simple (Hello, World or similar) and build. If your Nios II usage is fairly simple and doesn't involve too many code hogging drivers you should be able to make good use of 16Kbytes of onchip RAM.

Cheers and Good Luck,

-- slacker

Generate a NIOS cpu without the instruction or data caches, instead add tightly coupled instruction and data blocks.

You can add read/write access to the 'code' memory over the Avalon bus, if you link your program appropriately (put .rodata with .data, and don't use gcc4! - switch statement jump tables end up in the wrong segment) this isn't actually necessary though!

You need to avoid calling any code out of libc - it tends to pull in large tracts of unneeded stuff - in particular printf() pulls in all of stdio and malloc. The startup code supplied by altera also tends to pull in stdio.

For absolute minimalism, you only need to set two registers (sp & gp) before jumping to that start of any C function. I've done this from within the linker script in order to avoid an additional source file - which the linker script would have to know about anyway.