Altera Remote Ststem Update Опции

[doom13]

Добрый день.
В проекте присутствует ядро Remote update, всё управление происходит с помощью Nios II. Есть две конфигурации: factory и application.
Factory заливается по адресам 0x0, application - 0xd00000. Включается питание запускается factory конфигурация, которая через Remote Update загружает конфигурацию application.
Алгоритм работы для factory следующий:

Код

rd_data = rsu_controller_rd_reconf_src_condition((void *)RSU_CONTROLLER_BASE);
if((rd_data == RECONF_SOURCE_POR) || (rd_data == RECONF_SOURCE_EXTERNAL_RST) || (rd_data == RECONF_SOURCE_LOGIC_TRIGGERED))
{
    rsu_controller_wr_config_mode((void *)RSU_CONTROLLER_BASE, CONFIG_MODE_APPLICATION);
    rsu_controller_wr_wdt_timeout((void *)RSU_CONTROLLER_BASE, RSU_WDT_TIMEOUT_VALUE);
    rsu_controller_write_param((void *)RSU_CONTROLLER_BASE, PARAM_WDT_ENABLE, 1);
    rsu_controller_write_param((void *)RSU_CONTROLLER_BASE, PARAM_PAGE_SELECT, APPLICATION_PAGE_START_ADDRESS);
    rsu_controller_reconfig((void *)RSU_CONTROLLER_BASE);
}

Алгоритм работы для application:

Код

rd_data = rsu_controller_rd_config_mode((void *)RSU_CONTROLLER_BASE);
if(rd_data == CONFIG_MODE_APPLICATION)
{
    rd_data = rsu_controller_read_param((void *)RSU_CONTROLLER_BASE, PARAM_WDT_ENABLE);
    if(rd_data)
    {
         rsu_controller_reset_timer((void *)RSU_CONTROLLER_BASE, 1); // сигнал разрешения сброса wdt, разрешает подачу меандра на вход reset_timer ядра Remote Update
    }
}

Для удобства перепрошивки довавлена функция реконфигурации, алгоритм которой:

Код

#if __REMOTE_SYSTEM_UPDATE_CONFIGURATION_MODE == CONFIG_MODE_FACTORY
    rsu_controller_wr_config_mode((void *)RSU_CONTROLLER_BASE, CONFIG_MODE_FACTORY);
    rsu_controller_write_param((void *)RSU_CONTROLLER_BASE, PARAM_WDT_ENABLE, 0);
    rsu_controller_wr_wdt_timeout((void *)RSU_CONTROLLER_BASE, 0);
    rsu_controller_write_param((void *)RSU_CONTROLLER_BASE, PARAM_PAGE_SELECT, FACTORY_PAGE_START_ADDRESS);
    rsu_controller_reconfig((void *)RSU_CONTROLLER_BASE);
#elif __REMOTE_SYSTEM_UPDATE_CONFIGURATION_MODE == CONFIG_MODE_APPLICATION
    rsu_controller_reconfig((void *)RSU_CONTROLLER_BASE);
#endif

Вопросы в следующем:
1) Заливаем factory, application, переключаем питание - всё работает, даём команду Reconfig - всё перезапускается.
2) Залит только factory. По включению питания запустилось, дали команду Reconfig - всё ок.
3) Проблемная ситуация 1: Находимся в режиме application и перезаливаем прошивку для application. Что-то легло - прошивка залилась неправильно/частично, даём команду Reconfig и FPGA уже не стартует (а должна была остаться конфигурация factory).
Сбрасываем питание, запускается factory и Reconfig для него уже работает.
4) Проблемная ситуация 2: Включаем питание. Для application залита какая-то ерунда - загружается конфигурация factory. Factory перезаливает прошивку для application, делаем Reconfig и всё опять дохнет (а должна была стартануть конфигурация application). По сбросу питания опять всё запускается, переходит в режим application и нормально работает.

[vadimuzzz]

посмотрел у себя в коде, все аналогично. возникли вопросы: 1) почему в factory не рассматривается как источник сброса wdt, 2) почему wdt отключен в функции реконфигурации?

[doom13]

посмотрел у себя в коде, все аналогично. возникли вопросы: 1) почему в factory не рассматривается как источник сброса wdt?

Предполагаю, что factory надёжная (рабочая) конфигурация, а в ней я могу просто отключать wdt (в application такой возможности нет - использую сброс).

2) почему wdt отключен в функции реконфигурации?

Это он отключён во втором варианте работы, где перезагрузка должна произойти с адресов factory. Изначально было так:

Код

#if __REMOTE_SYSTEM_UPDATE_CONFIGURATION_MODE == CONFIG_MODE_FACTORY
    rsu_controller_wr_config_mode((void *)RSU_CONTROLLER_BASE, CONFIG_MODE_APPLICATION);
    rsu_controller_wr_wdt_timeout((void *)RSU_CONTROLLER_BASE, RSU_WDT_TIMEOUT_VALUE);
    rsu_controller_write_param((void *)RSU_CONTROLLER_BASE, PARAM_WDT_ENABLE, 1);
    rsu_controller_write_param((void *)RSU_CONTROLLER_BASE, PARAM_PAGE_SELECT, APPLICATION_PAGE_START_ADDRESS);
    rsu_controller_reconfig((void *)RSU_CONTROLLER_BASE);
#elif __REMOTE_SYSTEM_UPDATE_CONFIGURATION_MODE == CONFIG_MODE_APPLICATION
    rsu_controller_reconfig((void *)RSU_CONTROLLER_BASE);
#endif

Но оба варианта не работают.

[vadimuzzz]

Предполагаю, что factory надёжная (рабочая) конфигурация, а в ней я могу просто отключать wdt (в application такой возможности нет - использую сброс).

но если app-прошивка сбойная, то wdt вернет к factory. если же вы не включите wdt, то после перехода в application со сбойной прошивкой, ПЛИС повиснет. вот мне и непоятно - откуда 2 варианта функции реконфигурации для factory?

[doom13]

С Ваших слов возникло предположение по поводу необходимости сброса wdt для factory. Счас буду пробовать.

но если app-прошивка сбойная, то wdt вернет к factory. если же вы не включите wdt, то после перехода в application со сбойной прошивкой, ПЛИС повиснет. вот мне и непоятно - откуда 2 варианта функции реконфигурации для factory?

По поводу вариантов реконфигурации. Сначала пробовал для factory перенаправлять на application, а потом ещё было предположение перезагружать сам factory который уже и будет стартовать application (эти переходы только если всё запустилось и даём команду на реконфигурацию - внешняя команда).

UPP:
Но как тогда работает пункт №2 (залит factory и кривой application)? Включаю питание, а он остаётся в режиме factory. Или после переполнения wdt он сбросит FPGA (в factory) и далее остановится? Ведь если он не остановится, то в данном случае должен быть постоянный реконфиг (factory не сбрасывает wdt).

[vadimuzzz]

UPP:
Но как тогда работает пункт №2 (залит factory и кривой application)? Включаю питание, а он остаётся в режиме factory. Или после переполнения wdt он сбросит FPGA (в factory) и далее остановится? Ведь если он не остановится, то в данном случае должен быть постоянный реконфиг (factory не сбрасывает wdt).

я так понимаю собственно в factory он не нужен: wdt включается только перед попыткой загрузки application. кстати, мне кажется, что переписывать factory не стоит в принципе. т.к. если что-то отвалится при обновлении, вернуться будет не к чему.

[doom13]

я так понимаю собственно в factory он не нужен: wdt включается только перед попыткой загрузки application. кстати, мне кажется, что переписывать factory не стоит в принципе. т.к. если что-то отвалится при обновлении, вернуться будет не к чему.

Так вот и получаем, что при переходе на application wdt всегда включен (код для factory - всё включено и делаем переход; функция реконфигурации (вариант с переходом на адреса application) - так же всё включено).
Переделал немного код. Старт программы:

Код

#if __REMOTE_SYSTEM_UPDATE_CONFIGURATION_MODE == CONFIG_MODE_FACTORY

    rsu_controller_reset_timer((void *)RSU_CONTROLLER_BASE, 1); // разрешение периодического сброса wdt

    rd_data = rsu_controller_rd_reconf_src_condition((void *)RSU_CONTROLLER_BASE);
    if((rd_data == RECONF_SOURCE_POR) || (rd_data == RECONF_SOURCE_EXTERNAL_RST) || (rd_data == RECONF_SOURCE_LOGIC_TRIGGERED))
    {
        rsu_controller_wr_config_mode((void *)RSU_CONTROLLER_BASE, CONFIG_MODE_APPLICATION);
        rsu_controller_wr_wdt_timeout((void *)RSU_CONTROLLER_BASE, RSU_WDT_TIMEOUT_VALUE);
        rsu_controller_write_param((void *)RSU_CONTROLLER_BASE, PARAM_WDT_ENABLE, 1);
        rsu_controller_write_param((void *)RSU_CONTROLLER_BASE, PARAM_PAGE_SELECT, APPLICATION_PAGE_START_ADDRESS);
        rsu_controller_reconfig((void *)RSU_CONTROLLER_BASE);
    }

#elif __REMOTE_SYSTEM_UPDATE_CONFIGURATION_MODE == CONFIG_MODE_APPLICATION

    rsu_controller_reset_timer((void *)RSU_CONTROLLER_BASE, 1); // разрешение периодического сброса wdt

#endif

Функция реконфигурации:

Код

#if __REMOTE_SYSTEM_UPDATE_CONFIGURATION_MODE == CONFIG_MODE_FACTORY
    rsu_controller_wr_config_mode((void *)RSU_CONTROLLER_BASE, CONFIG_MODE_APPLICATION);
    rsu_controller_wr_wdt_timeout((void *)RSU_CONTROLLER_BASE, RSU_WDT_TIMEOUT_VALUE);
    rsu_controller_write_param((void *)RSU_CONTROLLER_BASE, PARAM_WDT_ENABLE, 1);
    rsu_controller_write_param((void *)RSU_CONTROLLER_BASE, PARAM_PAGE_SELECT, APPLICATION_PAGE_START_ADDRESS);
    rsu_controller_reconfig((void *)RSU_CONTROLLER_BASE);
#elif __REMOTE_SYSTEM_UPDATE_CONFIGURATION_MODE == CONFIG_MODE_APPLICATION
    rsu_controller_reconfig((void *)RSU_CONTROLLER_BASE);
#endif

Результат тот же. По включению питания работает всегда (не зависит от наличия и корректности application, т.е. либо загрузит application, либо останется в factory). Если был залит битый application, a factory перезаливает новый правильный application во флэш и пытается его стартануть, то всё виснет. Если всё стартануло, application пишет во флэш битый application а потом переходит на factory, чтобы перезапустить новую прошитую прошивку, - всё повиснет.

Ещё накопал вот это, но не могу понять относится оно или нет к моему случаю.

[vadimuzzz]

Ещё накопал вот это, но не могу понять относится оно или нет к моему случаю.

если это оно, должна дергаться нога nSTATUS

[doom13]

если это оно, должна дергаться нога nSTATUS

Для обоих ситуаций

Если был залит битый application, a factory перезаливает новый правильный application во флэш и пытается его стартануть, то всё виснет. Если всё стартануло, application пишет во флэш битый application а потом переходит на factory, чтобы перезапустить новую прошитую прошивку, - всё повиснет.

nSTATUS дёргается (после сброса питания всё восстанавливается). Что думать, что это их баг, пытаться задействовать pof checking? Но ситуация отлична от описанной в указанных доках, одинаково только поведение nSTATUS.

UPP: из их доки понял, что без pof checking вообще ничего работать не должно?!

[vadimuzzz]

nSTATUS дёргается (после сброса питания всё восстанавливается). Что думать, что это их баг, пытаться задействовать pof checking? Но ситуация отлична от описанной в указанных доках, одинаково только поведение nSTATUS.

хз, но проверить стоит

[doom13]

Нашёл ещё одну глючную ситуацию, работает application (работа начиналась с включения питания factory запускал application) и посылается новая прошивка для application (прошивка правильная). Прошивка записывается во флэш. После перепрошивки конфигурационной флэшки пытаюсь сделать RECONFIG, а оно опять дохнет. После переключения питания возобновляет работу. Т.е. получается, что RECONFIG не работает именно после перепрошивки конфигурационной флэшки (для описанных выше ситуаций везде присутствовала перезапись флэша!!!).
Если перезаписи флэша не было. Выполняем RECONFIG для factory с битым application, то работает правильно - остаётся в factory. Если выполнять RECONFIG для аpplication (без записи флэшки), так же работает - сбрасывается на factory, который опять же запустит application.
Очень похоже на какую-то проблему с интерфейсом конфигурационной флэшки. Для прошивки используется EPCS/EPCQx1 flash controller, может быть проблема в нём, что-то не могут поделить c Remote Update?

[vadimuzzz]

Очень похоже на какую-то проблему с интерфейсом конфигурационной флэшки. Для прошивки используется EPCS/EPCQx1 flash controller, может быть проблема в нём, что-то не могут поделить c Remote Update?

а сигналы с/на флешку идут, когда nSTATUS дергается?

[doom13]

а сигналы с/на флешку идут, когда nSTATUS дергается?

Да идут.

[Golikov A.]

может сократить пути и уменьшить число вариантов загрузок или задача решить именно в таком раскладе?

[doom13]

может сократить пути и уменьшить число вариантов загрузок или задача решить именно в таком раскладе?

Задача сделать две прошивки в конфигурационной флэшке (нестираемый или стираемый c запросом прав доступа factory и стираемый при обновлении ПО application).

[Golikov A.]

просто можно грузиться всегда через фактори и она принимает решения грузить апликайшен или нет (целостность, кнопка, специальный флаг, коды защиты)
фактори сделать не убиваемой и не стираемой

Обновление всегда через перезагрузку и остановкой в фактори для обновления апликейшена, и старт опять через перезагрузку.
Так вы получите всегда стандартное начало, которое не надо будет проверять на комбинации.

вот обновление фактори я обычно не делаю, и если уж прижмет делаю его жетагом или внешним программатором напрямую в память, слишком уж большой шанс если что не так кирпич на выходе получить... а у клиента всегда все не так идет...

[doom13]

просто можно грузиться всегда через фактори и она принимает решения грузить апликайшен или нет (целостность, кнопка, специальный флаг, коды защиты)
фактори сделать не убиваемой и не стираемой

Обновление всегда через перезагрузку и остановкой в фактори для обновления апликейшена, и старт опять через перезагрузку.
Так вы получите всегда стандартное начало, которое не надо будет проверять на комбинации.

вот обновление фактори я обычно не делаю, и если уж прижмет делаю его жетагом или внешним программатором напрямую в память, слишком уж большой шанс если что не так кирпич на выходе получить... а у клиента всегда все не так идет...

Всё так, только вот проблема в том, что после перепрошивки флэша не получается перезагрузить обновлённую конфигурацию программно (а должно работать). Стартанёт только после сброса питания. И перезапуск (программный) работает, если флэш на запись не трогать.

[Golikov A.]

а вочьдогом перегрузить?

[doom13]

а вочьдогом перегрузить?

Думаю, результат будет тот же, т.к. меняем только источник реконфигурации: была ножка ядра reconfig, а предлагаете wdt. Да и это попытка обойти то, что не работает, а не устранение самой причины проблемной ситуации. Reconfig прекрасно работает и для factory и для application, если флэшку не трогали. Вот в этом и хочу разобраться, каким образом работа EPCS/EPCQx1 Controller-a влияен на модуль Remote Update.

[doom13]

Почитал ещё параметры для Remote Update, после старта FPGA, получаю следующее.
1) Залит только factory. По включению питания он запускается настраивает WDT и пытается стартануть application (которого нет), как результат опять перезагружается factory.
Читаем Reconfiguration trigger conditions - получаем 02h (ожидалось 10h - сброс от wdt).
2) Залит factory и битый application (начало application). По включению питания запускается factory настраивает WDT и пытается стартануть application (который битый), как результат опять перезагружается factory. Читаем Reconfiguration trigger conditions - получаем 01h (ожидалось 10h - сброс от wdt).
3) Залит factory и application - тут всё понятно, при чтении Reconfiguration trigger conditions получаем 04h - сброс от логики.

Каким образом получаются такие значения Reconfiguration trigger conditions для случаев 1 и 2?

[doom13]

Как и предполагалось, есть какая-то ерунда при использовании EPCS/EPCQx1 Flash Controller-a вместе с Remote Update. Если для общения с EPCQ использовать ASMI, описанной выше проблемы не наблюдается - команда RECONFIG работает после записи флэша.

???

[vadimuzzz]

Как и предполагалось, есть какая-то ерунда при использовании EPCS/EPCQx1 Flash Controller-a вместе с Remote Update. Если для общения с EPCQ использовать ASMI, описанной выше проблемы не наблюдается - команда RECONFIG работает после записи флэша.

а какая версия квартуса? вроде в 13 или 13.1 был баг то ли программера, то ли бутлодера

[doom13]

а какая версия квартуса? вроде в 13 или 13.1 был баг то ли программера, то ли бутлодера

Версия Q14.0 и девайс 5cefa9. Там баг с Nios II Flash Programmer, он и в этой версии не работает, но какое он к данной проблеме может иметь отношение, я-то не им прошивку обновляю?

[vadimuzzz]

Там баг с Nios II Flash Programmer, он и в этой версии не работает, но какое он к данной проблеме может иметь отношение, я-то не им прошивку обновляю?

может баг не в нем (или не только в нем). ASMI от EPCQ только количеством проводов данных отличается?

[doom13]

может баг не в нем (или не только в нем). ASMI от EPCQ только количеством проводов данных отличается?

Не понял вопрос. EPCS/EPCQx1 Flash Controller под NIOS заточен (на Avalon-e висит и разрядность там 32, внутренности не смотрел), а ASMI (Active Serial Memory Interface) позволяет всё то же, но это чисто железный блок (данные 8-миразрядные), чтоб его к Nios прикрутить - свой контроллер набросал и драйвера для работы с ним.

Посмотрел на драйвера для EPCS/EPCQx1 Flash Controller, запись там по 8 бит реализована (обычный spi).

[vadimuzzz]

Не понял вопрос. EPCS/EPCQx1 Flash Controller под NIOS заточен (на Avalon-e висит и разрядность там 32, внутренности не смотрел), а ASMI (Active Serial Memory Interface) позволяет всё то же, но это чисто железный блок (данные 8-миразрядные), чтоб его к Nios прикрутить - свой контроллер набросал и драйвера для работы с ним.

контроллер EPCQ в ниосе поддерживает режим x4? ASMI-то его точно не поддерживает

[doom13]

контроллер EPCQ в ниосе поддерживает режим x4? ASMI-то его точно не поддерживает

Да нет, ASMI умеет работать в режиме х4 (выбирается тип флэша - epcq). Проверено осциллом - сигнал при прошивке ASMI есть на всех линиях данных DQ0, DQ1, DQ2, DQ3. А вот EPCS/EPCQx1 Flash Controller поддерживает, как понимаю, только режим х1 (судя по названию ядра). При прошивке флэша EPCS/EPCQx1 Flash Controller-ом сигнал есть только на DQ0 (serial data input) и DQ1 (serial data output)).

[vadimuzzz]

Да нет, ASMI умеет работать в режиме х4 (выбирается тип флэша - epcq). Проверено осциллом - сигнал при прошивке ASMI есть на всех линиях данных DQ0, DQ1, DQ2, DQ3. А вот EPCS/EPCQx1 Flash Controller поддерживает, как понимаю, только режим х1 (судя по названию ядра). При прошивке флэша EPCS/EPCQx1 Flash Controller-ом сигнал есть только на DQ0 (serial data input) и DQ1 (serial data output)).

а в момент, когда начинает reconfig глючить (когда nSTATUS дергается) какие/сколько линии данных(DQ) активны?

[doom13]

а в момент, когда начинает reconfig глючить (когда nSTATUS дергается) какие/сколько линии данных(DQ) активны?

Отличие только в DQ0. Для случая, когда RECONFIG работает - она '0' (не было перезаписи epcq), для случая - RECONFIG не работает она '1' (была запись epcq и DQ0 осталась в '1').

[Golikov A.]

а флешка не переконфигурируется на чтение по 1 или 4 линиям? может в каком-то режиме она всегда читается по одному, без переконфигурации?

[doom13]

а флешка не переконфигурируется на чтение по 1 или 4 линиям? может в каком-то режиме она всегда читается по одному, без переконфигурации?

Данная флэш-память может работать в обоих режимах, но делo не в самой памяти, проблема с её контроллером, а это уже IP-ядро от Altera.

[vadimuzzz]

Данная флэш-память может работать в обоих режимах, но делo не в самой памяти, проблема с её контроллером, а это уже IP-ядро от Altera.

я это и имел в виду: м.б. при реконфиге через EPCQx1 плис пытается по 4-м линиям читать, а память по одной выдает?

[doom13]

я это и имел в виду: м.б. при реконфиге через EPCQx1 плис пытается по 4-м линиям читать, а память по одной выдает?

Если правильно понимаю, то режим загрузки (х4) задаётся прошивкой (в начале есть инфа, как настроить интерфейс загрузки). Если перекомпилить на х1, то бинарник отличается.

Вот это Вы не пропустили:

а в момент, когда начинает reconfig глючить (когда nSTATUS дергается) какие/сколько линии данных(DQ) активны?

Отличие только в DQ0. Для случая, когда RECONFIG работает - она '0' (не было перезаписи epcq), для случая - RECONFIG не работает она '1' (была запись epcq и DQ0 осталась в '1').

???
Или это - подтверждение.

[Golikov A.]

ну пока прошивку не считаешь, режим же не поймешь. Потому изначально флешка должна в каком-то одном виде отвечать в дефолтном. После обращения настраивается режим, какой-то конкретно заданный. И вот вопрос перенастривается ли - сбрасывается ли он перед обращением уже после обновления...

[vadimuzzz]

Или это - подтверждение.

не совсем: по линии dq0 во всех режимах передаются опкоды. что если ситуация примерно такая: контроллер дает опкод на чтение по 4-м линиям, а физически к корке подключена одна? и еще, в даташите на epcq есть раздел про "Non-Volatile Configuration Register", драйвер ничего с ним не делает?

[doom13]

не совсем: по линии dq0 во всех режимах передаются опкоды. что если ситуация примерно такая: контроллер дает опкод на чтение по 4-м линиям, а физически к корке подключена одна? и еще, в даташите на epcq есть раздел про "Non-Volatile Configuration Register", драйвер ничего с ним не делает?

Проблема есть с EPCS/EPCQx1 Controller-ом, про него и пишу: я использую только ф-ии alt_epcs_flash_init(), alt_epcs_flash_erase_block(), alt_epcs_flash_write_block() из папки с драйверами, а как они реализованы - не вникал. Явно никакие настройки для флэшки в этих функциях не задаются.

[doom13]

Default-mode для EPCQ256 (N25Q256) - это, как понимаю, х1. Т.е. при загрузке ПЛИС должна перевести её в х4, а потом грузится (по окончании загрузки вернуть режим в х1).
EPCS/EPCQx1 controller работает в режиме х1. Далее Remote Update задаёт реконфигурацию и загрузчик должен залить обновлённую прошивку перенастроив х1 в х4, но почему-то не может.

Стёр флэшку, при включении питания активны DQ0 (serial data input) и DQ1 (serial data output) - FPGA пробует считать прошивку. На DQ2, DQ3 - '1' (вижу высокий уровень). В случае обновления прошивки и выполнения RECONFIG все пины активны (FPGA читает в режиме х4).

Эскизы прикрепленных изображений

 

[vadimuzzz]

EPCS/EPCQx1 controller работает в режиме х1. Далее Remote Update задаёт реконфигурацию и загрузчик должен залить обновлённую прошивку перенастроив х1 в х4, но почему-то не может.

до загрузчика, я так понимаю, дело просто не доходит - он запускается уже в user-mode. а есть возможность все операции, включаяя загрузку sof, выполнить в режиме x1? если получится, значит действительно что-то с переключением режимов флешки

[doom13]

до загрузчика, я так понимаю, дело просто не доходит - он запускается уже в user-mode. а есть возможность все операции, включаяя загрузку sof, выполнить в режиме x1? если получится, значит действительно что-то с переключением режимов флешки

А вот с загрузкой прошивки сконвертированной для Active Serial есть какой-то баг, не стартует с ней FPGA.
Может быть это из-за того, что в настройках проекта (Device and Pin Options->Configuration->Configuration scheme) у меня выбран Active Serial x4, а сконвертить пытаюсь для Active Serial?
Или выбранный в настройках Active Serial x4 на генерацию sof влиять не должен?

[doom13]

Перекомпилил с настройкой Active Serial x1 - не запускается.