remote update для NIOS, найти решение Опции

[Атмег]

Есть Циклон3 с Ниосом, грузится из EPCS. Необходимо сделать удаленную перепрошивку. Сделал загрузчик (т.е. factory boot image по альтеровской терминологии), он лежит по начальному адресу EPCS, при загрузке определяет наличие связи с программатором, если есть, грузит новую прошивку в EPCS по определенному смещению и реконфигурится, если нет - просто реконфигурируется старой прошивкой. В качестве тестовой прошивки сделал проект, который имеет проинициализированную внутреннюю onchip_ram и с нее же грузится. Прошивка в одном файле *.rbf, все грузится, все работает.
Но разработчик рабочего ПО не хочет делать проект с проинициализированной внутренней памятью. У него проект грузится из EPCS, и не во внутреннюю память, а во внешнюю SRAM. Насколько я понимаю, бутлоадер epcs_flash_controller'а способен работать только с единственным образом во флешке, и заставить штатный бутлоадер найти образ по смещению не получится? Есть какие-то еще варианты в данной ситуации, кроме переписывания бутлоадера (делать это не очень хочется и некогда)?

З.Ы.
Как вариант я пересобрал рабочее ПО для загрузки из внутренней RAM, оставив в ней только .text, остальные секции вынес во внешнюю RAM (иначе не помещается). Но этот путь оказался не таким уж простым, потому что одна версия ПО, собранная таким образом, работает, а другая - нет. Непонятно почему, при сборке ошибок не было во обоих случаях. Разработчик утвержает, что версии принципиально ничем не отличаются.

[Konst_777]

... В качестве тестовой прошивки сделал проект, который имеет проинициализированную внутреннюю onchip_ram и с нее же грузится. Прошивка в одном файле *.rbf, все грузится, все работает...

То есть, таким образом Вы упростили задачу создания бинарника для application image. В общем случае, для создания бинарника для application image нужно использовать Nios II Flash Programmer и, написанную кем-нибудь утилиту, которая преобразует файлы имя_проекта_epcs.flash (загрузка FPGA) и имя_проекта_epcs_1_.flash (ПО процессора Nios II) в бинарник для application image.
При таком (общем) подходе factory image и application image могут быть проектами у которых совершенно не совпадает ни архитектура ни программное обеспечение.