Программа сборки голого металла на Zynq без Vivado/SDK
У меня есть вопрос к тем, кто знаком с Xilinx Zynq и связанными с ним инструментами проектирования....
- Можно ли скомпилировать и запустить C-код для Zynq 7010 ( плата разработчика Zybo), БЕЗ использования цепочки инструментов Xilinx (Vivado / SDK)?
- Можно ли собрать и запустить код сборки ARM (Thumb2) на Zynq, БЕЗ использования цепочки инструментов Xilinx (Vivado / SDK)? Под этим я подразумеваю написание программы, которая НЕ использует какие-либо библиотеки драйверов Xilinx или автоматически сгенерированный код инициализации (т. Е. Создает собственную простую векторную таблицу, дает определения различным обработчикам исключений и т. Д.)
- Если нет, возможно ли хотя бы собрать и связать код сборки ARM из SDK?
Я помогаю портировать вводный курс по встраиваемым системам с STM32F4 (платы разработки ARM M3) на Zynq, и первые несколько недель - это всегда введение в сборку. Обычно мы делаем все вручную из командной строки, используя набор инструментов arm-none-eabi, поэтому мне было бы интересно сохранить эту структуру, а не сразу переходить в среду Xilinx Vivado/SDK. Однако я не смог найти никаких ресурсов по программированию устройства без набора инструментов Xilinx, что я нахожу странным. Я не могу представить, что это невозможно, поэтому любая информация будет принята с благодарностью.
Спасибо!
3 ответа
У меня нет непосредственного опыта работы с ZyBo, однако мне приходилось сталкиваться с подобной ситуацией несколько раз, и я узнал, как собирать информацию из Интернета (даже до Интернета) и заполнять пробелы с помощью небольшого количества обратного инжиниринга. методом проб и ошибок.
Я собрал то, что считаю полезной информацией, но у меня никогда не было ZyBo, так что возьмите это с крошкой соли.
Кроме того, найдите время, чтобы прочитать связанный документ, если вы не понимаете терминологию.
Похоже, что вы можете избежать части Vivado SDK и IDE, руководство разработчика программного обеспечения Zynq 7000 в Приложении A описывает использование bootgen а также BIF файлы для создания загрузочного образа.
В терминологии Zybo загрузочный образ содержит заголовок BootROM и загрузчик первого этапа (этап 1 этапа процесса начальной загрузки, он также содержит код пользователя).
Обратите внимание, что сам BootROM недоступен для записи, поэтому вы не можете изменить стадию 0, если не найдете способ ее взломать (хотя это не очень хорошая идея, хотя стадия 0 выполняет минимальное количество работы и делает плату пригодной для использования).
Пример взят из этого руководства
// A simple BIF file example.
the_ROM_image:
{
[init]init_data.int
[bootloader]myDesign.elf
Partition1.bit
Partition1.rbt
Partition2.elf
}
И в руководстве явно сказано, что ELF - это поддерживаемый формат файла (по крайней мере, я надеюсь, что это ELF).
Таким образом, вы могли бы использовать GCC для создания ARM ELF и чем bootgen сделать загрузочный образ (конечно же нет C Runtime).
Также поддерживаются двоичные файлы, поэтому подойдет любой ассемблер ARM.
Это должно избежать любого кода инициализации SDK, оставляя только этап 0 выполняемым перед вашим кодом.
Техническое справочное руководство Zynq 7000 подробно описывает формат заголовка BootROM.
В нем также объясняются различные аппаратные компоненты и принятые архитектурные решения, в том числе процесс загрузки и различные варианты "голого железа".
Так что вы даже можете избавиться от bootgen и сделай свой собственный инструмент.
Заголовок BootROM, по-видимому, имеет поле для определения таблицы прерываний в режиме XIP, однако, как уже говорилось, именно BootROM исполняется первым кодом, поэтому вы не начинаете с вектора сброса ARM.
Я не знаком с SDK, но я уверен, что если вы покопаетесь в папке bin SDK, вы найдете множество обычных инструментов GNU для цепочки инструментов ARM (почти так же, как это происходит с Android NDK).
XILINX заявляет в одном из своих документов (увы, я не помню, какой именно), что они использовали стандартные инструменты GNU с небольшими дополнениями.
Что касается избегания библиотек XILINX, вы можете попробовать прочитать их исходные коды, если они есть, или разобрать их двоичные файлы.
С помощью Технического справочного руководства вы сможете избежать их в первую очередь.
XILINX проделал большую работу, описав свою доску на двух связанных документах (более короткий здесь), чтение обоих объяснит многое из того, что происходит под капотом.
Обычно поставщики повторно используют существующие инструменты, поэтому, если XILINX не разработал свои собственные, вы должны найти знакомые инструменты командной строки, используемые в IDE.
И вы даже можете начать любить Vivado SDK, узнав, как он работает в глубине!
Когда я искал способ разработки программного обеспечения без использования Xilinx SDK, я нашел этот репозиторий. Автор написал код в ассемблере для инициализации SoC Zynq 7000, чтобы на нем можно было запускать скомпилированный C-код. Однако автор все еще использовал набор инструментов из Xilinx SDK.
Я создал новый репозиторий на основе его разработки и избавился от зависимости Xilinx SDK в пользу arm-none-eabi-gcc и arm-none-eabi-newlib. OpenOCD используется для запуска программного обеспечения на этом устройстве. Вот git-репозиторий с инструкциями по запуску примера на Digilent Zybo Z7-10 без Xilinx SDK: https://github.com/3ap/zybo-z7-baremetal
В общем да, абсолютно. Но это зависит прежде всего от доступной документации для части. Нет никаких причин, по которым вы не можете использовать, скажем, gnu или llvm tools для создания бинарных файлов, заменяя sdks необходимую информацию о том, с чем вы разговариваете. Если это просто ядро, обернутое вашей логикой, то вам все еще нужны их инструменты, чтобы сделать логику наиболее вероятной и поместить ее в часть (и вы контролируете, какой адрес и периферийные устройства, чтобы вы могли писать код для взаимодействия с вашей собственной логикой, так что вы документируете для себя), но двоичный файл arm, теоретически вы можете сделать с помощью любых инструментов, и, надеюсь, их инструменты не мешают вам использовать эти двоичные файлы.