boot copier for SSRAM

If you have some method of getting the initialised code into SSRAM, you should just be able to point the nios's reset vector into SSRAM.

I'm not sure how you are going to manage to initialise the SSRAM though! Since it is unlikely to be initialised at power on, you'll need to keep the nios in soft-reset until the SSRAM contents are valid.

I agree with dsl in the fact SSRAM needs to be initialized and bootloaded, too.

So what's the point in loading code from SSRAM to onchip ram? You can directly load code into onchip ram.

Unless you have a particular boot method (i.e. a host processor loads code in a shared SSRAM and then Nios boots from there), you usually have a non-volatile memory (flash) to boot from.

If you intend to load specific code sections into onchipram, you can use the macro ALT_LOAD_SECTION_BY_NAME(onchipram) at the very beginning of main().

All functions defined with the attribute

__attribute__ ((section (".onchipram")))

will be then loaded from nv memory.

This is mandatory if onchipram is not defined as the the program memory .text section, because the standard booloader doesn't initialize these extra code sections.

Actually the code in alt_main() does sometimes copy sections from their physical address to the correct virtual address (at least it used to!).

The default linker script puts all the sections into contiguous memory in a single program section, and relies on code being generated to copy the sections to their correct virtual address (ie they are linked with physaddr != virtaddr). This might be what you want if you are loading from flash.

If you are loading from JTAG (for testing) then the JTAG loader will load all the program sections in your elf image to their own physical addresses. So you want a linker script which does just that.

I don't actually use the IDE or any of the altera supplied development tools. I build code with gcc (compiled from the sources altera have to make available to comply with the GPL), link with my own custom linker script that puts expected sections into their correct memeory areas (and errors any unexpected sections).

We then download through the PCIe slave interface and release the nios from soft reset. The code at the reset vector loads %sp and %gp and jumps to the C function that does all the work. I can't quite get rid of %sp and make it available as a general register!

--- Quote Start ---

If you have some method of getting the initialised code into SSRAM, you should just be able to point the nios's reset vector into SSRAM.

I'm not sure how you are going to manage to initialise the SSRAM though! Since it is unlikely to be initialised at power on, you'll need to keep the nios in soft-reset until the SSRAM contents are valid.

--- Quote End ---

I initialise the SSRAM when Nios in the reset. After initialise the SSRAM the host remove reset with Nios.

Now the project the following adjustments

for Nios

reset vector - ssram

exception vector - onchip_ram

in IDE

text – ssram;

rodata – onchip_ram;

rwdata – onchip_ram;

In this case the Nios carries out the program from SSRAM. The program of the processor is in memory, so?

For reception of the image of SSRAM which the host uses for initialise the SSRAM I use elf2flash.

Now I want to make so that the program of Nios loaded from SSRAM into onchipram.

if in IDE make text = onchip_ram when elf2flash require boot copier files. Where to take it file?

--- Quote Start ---

I agree with dsl in the fact SSRAM needs to be initialized and bootloaded, too.

So what's the point in loading code from SSRAM to onchip ram? You can directly load code into onchip ram.

Unless you have a particular boot method (i.e. a host processor loads code in a shared SSRAM and then Nios boots from there), you usually have a non-volatile memory (flash) to boot from.

If you intend to load specific code sections into onchipram, you can use the macro ALT_LOAD_SECTION_BY_NAME(onchipram) at the very beginning of main().

All functions defined with the attribute

__attribute__ ((section (".onchipram")))

will be then loaded from nv memory.

This is mandatory if onchipram is not defined as the the program memory .text section, because the standard booloader doesn't initialize these extra code sections.

--- Quote End ---

to Cris72.

you write "You can directly load code into onchip ram". You speak about that it is possible through Jtag directly load code into onchip ram or through host directly load code into onchip ram.

You can mark some functions with the __attribute__((section("foo")), these will get linked into a separate text area - so you could arrange to copy those critical functions into onchip memory.

You might need to stand back a little and consider exactly what you need where, and then adjust the build sequence to 'make it so'. You'll probbaly need to use your own linker script!

Internal M9K (etc) memory blocks can be initialised as part of the fpga image. So you can write your own boot code that loads from EPROM in any way you like. The EPCS loader is just some code like that written by Altera.