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

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

[quote name='Атмег' post='1063628' date='May 30 2012, 01:49']Есть Циклон3 с Ниосом, грузится из EPCS. Необходимо сделать удаленную перепрошивку. Сделал загрузчик (т.е. factory boot image по альтеровской терминологии), он лежит по начальному адресу EPCS, при загрузке определяет наличие связи с программатором, если есть, грузит новую прошивку в EPCS по определенному смещению и реконфигурится, если нет - просто реконфигурируется старой прошивкой. В качестве тестовой прошивки сделал проект, который имеет проинициализированную внутреннюю onchip_ram и с нее же грузится. Прошивка в одном файле *.rbf, все грузится, все работает.
Но разработчик рабочего ПО не хочет делать проект с проинициализированной внутренней памятью. У него проект грузится из EPCS, и не во внутреннюю память, а во внешнюю SRAM. Насколько я понимаю, бутлоадер epcs_flash_controller'а способен работать только с единственным образом во флешке, и заставить штатный бутлоадер найти образ по смещению не получится? Есть какие-то еще варианты в данной ситуации, кроме переписывания бутлоадера (делать это не очень хочется и некогда)?


AN458 Alternative Nios II Boot читали, наверно? Тот код загрузчика Вам не подходит? А писать в EPCS не обязательно из загрузчика, можно и из основного ПО.

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

Да, не важно откуда писать, мне сейчас нужно просто заставить загрузчик грузиться по смещению. Пытаюсь загрузчик epcs_controller'а скомпилить и подсунуть при сборке sof'а, но пока не получается... Вы, насколько я понял, делали свой загрузчик, толькл у Вас cfi, а мне надо под epcs_controller..

Ну делал это громко сказано . Я просто добавил кое-что в стандартный. Но не важно. Так же не важно, на сколько знаю, и вид памяти. При компиляции программы загрузчика меняются только несколько функций. Ну и откуда начинать считывание. С EPCS это посложнее, чем в CFI. А что именно у Вас не получается? HEX-файл сгенерировали?

UPD. кстати о sof. А Вы саму конфигурацию в EPCS заливаете или только конфигурируете по jtag? Там дело в том, что с изменением размера конфигурации меняется и начальный адрес, с которого ложится тело программы. с этого адреса загрузчик начинает копирование

Размер sof для меня не важен, образ лежит по фиксированному смещению. Я вижу два пути решения задачи.

1. Структура памяти EPCS:


В этом случае надо модифицировать встроенный загрузчик epcs_flash_controller'а, чтобы он начал искать образ по смещению 0x200000. Взял исходники, собрала, но не знаю как заставить quartus подхватить hex при компиляции, выше писал как раз об этом.

2. Структура памяти EPCS:



Загрузка с внутренней памяти, загрузчик - advanced_boot_copier, он уже ищет по заданному смещению app elf и загружает. Этот вариант пока тоже не получается, т.к. не собирается проект с моим HW образом... Поменял в скриптах все дефайны на сови, но при сборке ошибка PERIPHERAL_SUBSYSTEM_SYS_CLK_TIMER_BASE undeclared... О_о Со скачанным примерров альтеровским все норм сообирается, но там свое железо, sdram и внешняя cfi.. В аппноте написано как собрать демо проект, а что менять при пересборке для своего - не сказано, может забы чего..

Наконец дошли руки, разобрался. Сделал вариант 2, все работает. Вдруг кому понадобится, пишу как:

Структура использования памяти EPCS


Загрузка происходит следующим образом:
- стандартным образом загружается factory HW образ и factory SW образ
- загрузчик (factory) проверяет наличие программатора в течение нескольких секунд,
если да, разрешает работу программатора и загрузку обновленных прошивок, после чего
запускает app HW; если программатор не обнаружен, сразу запускает app HW по адресу 0x00200000.
- app HW содержит внутреннюю память, проинициализированную копировщиком (boot copier), запускает его.
- boot copier загружает app SW по адресу 0x00400000, запускает целевое приложение.