Secondary Bootloader Plan

[Altera_Forum]

I am considering a design where the boot from flash always loads the NiosII configuration followed by a small firmware app that is a secondary bootloader. This secondary bootloader communicates with the outside world and can handle tasks such as receiving a firmware download and writing it to flash as well as loading a specified application image from flash and executing it. 

 For this to work, I need to build the real application so that it can execute in a different section of sram than the secondary bootloader since they both will be in ram at the same time when the secondary bootloader passes control to the real application.  One problem I am having is how to generate an elf file for the real application so that it is located starting at some specific address in ram. I have used the --change-addresses option in nios2-elf-objcopy but the resulting elf file doesn't execute (I think because the .exception section is relocated even though the SOPC exception vector is at its original address).  I tried using the -Ttext <addr> in the linker and that relocates everything and executes properly; however, it doesn't relocate the .exception section (which is why it probably works).   Will things work if the secondary loader and the real application have their .exception sections located at the same address? When the loader is loading the application image into ram it will overlay its own .exception section. That doesn't seem good.  Does anyone have any ideas how to get this to work?

[Altera_Forum]

Did you serach the altera website ? I think the EPCS controller + RSU megafunction do waht you want. 

 I've build such a system myself, although without Nios, and it works fine.

[Altera_Forum]

My requirements don't really fit into what remote update can do. I need to support multiple images on flash with the ability to boot a selected image. In addition, I have to support a non-standard communication system and command structure to handle firmware updates. 

 From what I have found via more searching, it looks like if you don't use interrupts during the booting part of the operation, then there will be no problem in writing over the .exceptions section of the secondary bootloader with the new application image.