2 Nios II with autonomous peripherals !

In fact the software never boots up directly from the EPCS, it would be too slow. When you select the Nios II CPU reset vector to the EPCS controller, the CPU will in fact execute a bootloader that is present in the EPCS controller itself (i.e. in a ROM block in the FPGA). This bootloader will then access the EPCS flash, copy the data to RAM, and ask the CPU to jump to the start address in RAM. The CPU never execute the application directly from the EPCS. The process (and alternative methods) are described here: http://www.altera.com/support/examples/nios2/exm-alt-boot-methods.html (there is a link to a PDF document on the page).

What the Nios programmer do in fact is check how long the FPGA image is in the EPCS flash, and adds just after it data chunks taken from the .elf file that the bootloader can read and recopy to RAM.

Now if you want to have the software from both CPUs in the flash you need to do at least a part of this job yourself. There are several solutions:[list][*]if both CPUs are executing the application from external RAM, you need to copy both applications from the flash to the external RAM. Again there are two methods:[list][*]keep CPU2 in reset, have CPU1 load both applications to RAM from the EPCS, and then start CPU2[*]have both CPUs read from the EPCS, but CPU2 must wait for CPU1 to be finished, and it must know where to look in the EPCS for its application[/list][*]if CPU1 uses an external RAM and CPU2 internal RAM (on-chip memory), then you can have CPU1 boot as usual with the default bootloader, and convert the CPU2's application to the .hex format. This .hex file can then be used in the Quartus project to initialize the on-chip memory, and the CPU2 can directly start on it once the FPGA is configured[/list]