If you are using a secondary bootloader, running from RAM, to load another piece of code into the same RAM, there are a few issues that need resolution.
1.) The first issue is how you want your memory map to look when you finally branch to the new (real) code? You obviously can't overwrite the secondary bootloader with the real code because at the point of branch, both need to exist. You'll probably have to partition your RAM so that 2ndary bootloader and real code have their own isolated sections, with the bootloader section clearly being much smaller. You may even be able to fit your 2ndary bootloader in on-chip RAM, which will make this problem a lot simpler as you wont have to worry about booting code from the EPCS at all since M4K memories in Cyclone parts are initializable with the FGPA configuration stream.
2.) I imagine the real code will be in the form of an .elf file created by Nios II IDE correct? For the secondary bootloader to get this .elf into RAM, it will need to stored on the host as some kind of boot record, meaning something that the bootloader can easliy translate into a series of "copy this data to address X" operations. Typically, you'll start by converting the .elf to an .srec using nios2-elf-objcopy. From there you can create a boot record. There is a bootcopier example posted on this forum that uses this kind of boot record. Check out "EPCS boot loader" under the "Post your own IP" downloads.
3.) Lastly, once the real code (including all data sections) is in place, you simply have to branch to it's starting address. If the code was built using Nios II IDE, all the system initialization will taken care of including stack pointer, heap, and the like.