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

Это здорово, когда мы хотим обновить алгоритмы, повысить производительность или исправить ошибку; однако что произойдет, если в удаленном обновлении что-то пойдет не так?

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

При использовании Zynq есть три варианта MultiBoot:

  • Поиск золотого образа — если загрузочный заголовок не найден в нижней части флэш-памяти, BootROM будет искать допустимый загрузочный заголовок со смещением 32 КБ.
  • BootROM MultiBoot — Работает под управлением FSBL. Это позволяет FSBL загружать приложение, а затем следовать за приложением. Это полезно, если вы хотите запустить приложение самопроверки перед выполнением основного приложения.
  • Fallback MultiBoot — если во время загрузки приложения возникает ошибка, FSBL делает резерв и позволяет BootROM загрузить следующий хороший образ.

В этом блоге мы собираемся изучить резервную MultiBoot и ее реализацию.

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

В этом посте мы нацелимся на плату MicroZed.

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

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

Оба проекта будут основаны на одном и том же оборудовании — в данном случае на простой системе Zynq Processing без каких-либо PL.

Каждое приложение будет состоять из:

  • Золотое / Обновляемое приложение для изображений
  • Пакет поддержки Golden / Updaable Image Application Board (BSP)
  • Золотой / обновляемый образ загрузчика первого этапа
  • Золотой/обновляемый образ загрузчика первой стадии BSP

Чтобы обеспечить видимость того, что происходит в процессе загрузки, мы можем установить символ FSBL_DEBUG_INFO на обновляемом образе FSBL.

Затем мы можем использовать эти файлы для создания двух файлов bin, одного золотого и одного обновляемого.

Чтобы прошить эти bin-файлы в QSPI, мы будем использовать диспетчер оборудования Vivado.

Первое, что нам нужно сделать, это добавить память конфигурации. Для платы MicroZed выберите s25fl128s-3.3v-qspi-x4-single.

Для исходного обновляемого образа, записанного по смещению 0 в памяти, мы должны стереть все устройство, а затем загрузить обновляемый файл boot.bin.

Для загрузки золотого образа мы используем следующие настройки. Это запишет золотой образ в желаемое резервное местоположение (0x80_0000).

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

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

Чтобы имитировать сбой в образе обновления, мы собираемся внести изменения в обновляемый FSBL. В main() в main.c мы собираемся закомментировать передачу FSBL и реализовать запасной вариант.

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

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

При отключении питания наблюдение за выводом на терминале очень четко покажет, что происходит откат.

Что завершается загрузкой золотого образа FSBL и приложения.

Это шаблон, которому мы следуем, когда работаем с устройством Zynq.

Если у нас есть чистое решение на основе FPGA, мы все равно можем использовать резервное решение. Я расскажу об этом в будущем блоге.

ПОЛУЧИЛОСЬ

  1. Обратите внимание на тип сброса — SW2 RST на MicroZed будет выполнять программный сброс, а не сброс при включении питания, поэтому адрес передачи обслуживания уже будет установлен для резервного золотого образа.
  2. Планируя размещение файлов BIN в QSPI, убедитесь, что вы размещаете их достаточно, чтобы предотвратить случайное повреждение одного изображения другим.
  3. При планировании схемы памяти QSPI оставьте достаточно места между изображениями, чтобы обеспечить возможность расширения приложения.
  4. Убедитесь, что резервный образ расположен на границе адреса 32 КБ.

Я загрузил проект в свой репозиторий GitHub.

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

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

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