На прошлой неделе «мы исследовали, как мы можем обновить дизайн Zynq в полевых условиях и использовать MultiBoot, чтобы обеспечить наличие золотого образа в случае сбоя обновления.

На этой неделе мы собираемся изучить, как мы можем сделать то же самое, используя стандартную ПЛИС. В этом примере мы будем использовать устройство Artix-A7 100T с дизайном MicroBlaze. Программа, выполняемая MicroBlaze, будет отличаться в зависимости от изображения.

Опять же, мы будем создавать два изображения — одно золотое изображение, к которому можно вернуться, и другое, которое можно перезаписать и обновить, если это необходимо в поле.

Включение золотого образа означает, что если обновление пойдет не так, мы не заблокируем систему. Однако, чтобы убедиться, что это работает правильно, нам нужно правильно настроить дизайн и особенно ограничения.

Итак, как это работает? При нормальной работе (без MultiBot) загружается битовый поток, расположенный по адресу 0x0 в памяти конфигурации. В подходе MultiBoot в устройстве памяти конфигурации есть два образа. Первый расположен по адресу 0x0 и является золотым образом, в то время как обычно загружаемый образ хранится по смещению в памяти конфигурации.

Важно отметить, что золотой образ содержит смещение адреса, где находится обычное/обновляемое изображение. Адрес этого нормального/обновленного образа считывается из золотого образа и сохраняется в золотом образе Начальный адрес для горячей загрузки (WBSTAR). Затем блок конфигурации в FPGA может перейти к этому адресу памяти с помощью IPROG или внутренне сгенерировать импульс, который инициирует переход к указанному адресу.

Если в обычном битовом потоке/обновлении будет обнаружена ошибка конфигурации, FPGA вернется к использованию золотого образа.

Два изображения, которые я создаю для этой демонстрации, будут печатать разные сообщения «hello world» в зависимости от того, загружено ли золотое изображение или изображение обновления.

Помимо разницы в содержимом программы MicroBlaze, основная разница между проектами в конфигурации MultiBoot заключается в файлах ограничений.

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

Я также включил сжатие изображения и установил ширину шины SPI на 1.

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

Когда у нас есть оба изображения (золото и обновление), мы можем создать комбинированный файл MCS, который содержит оба изображения — с золотым изображением по адресу 0 и обновленным изображением с указанным смещением. Примечание: в поле update потребуется, чтобы FPGA содержал метод конфигурации для записи двоичного или шестнадцатеричного файла в память конфигурации по адресу обновления.

Чтобы создать файл MCS, мы используем следующую команду:

write_cfgmem -format mcs -interface SPIX1 -size 16 -loadbit «up 0 golden.bit up 0x0400000 update.bit» image.mcs

После создания файла MCS вы увидите сгенерированный отчет, в котором показано содержимое созданного файла MCS.

Когда у нас есть файл MCS, мы готовы запрограммировать память QSPI, что мы можем сделать с помощью диспетчера оборудования Vivado.

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

Тем не менее, мы также хотим проверить, будет ли работать откат к золотому образу, если обновление образа обновления пойдет не так.

Чтобы проверить это, мы создадим новый файл MCS и включим в него поврежденный образ обновления.

Мы собираемся повредить образ обновления, открыв файл в шестнадцатеричном редакторе и изменив значение. Это приведет к сбою CRC и возврату устройства к золотому образу.

Когда поврежденный битовый файл готов, мы можем создать обновленный файл MCS и прошить его на устройстве QSPI.

Когда мы попытаемся загрузить образ обновления из флэш-памяти, мы увидим изображение золотого изображения, загруженное вместо изображения обновления из-за ошибки CRC.

Чтобы убедиться, что это произошло по указанным выше причинам, мы можем подключиться с помощью диспетчера оборудования Vivado через JTAG и проверить регистр состояния загрузки.

Глядя на регистр состояния загрузки, вы увидите сообщение об ошибке CRC для битового потока 1 и то, что был загружен резервный образ 0. Именно так, как мы хотим, чтобы это работало!

Вы можете получить проект, который я создал для этого на моей странице GitHub.

Посмотрите мои проекты FPGA/SoC:Адам Тейлор на Hackster.io

Получите код:ATaylorCEngFIET (Адам Тейлор)

Доступ к архивам MicroZed Chronicles с более чем 280 статьями о Zynq / Zynq MpSoC, которые еженедельно обновляются на MicroZed Chronicles.