2017-01-19 22 views
1

У меня есть вопрос для тех, кто знаком с Xilinx Zynq и связанные с ними инструменты проектирования ....голый металл программа сборки на Zynq без Vivado/SDK

  1. Можно скомпилировать и запустить код C для Zynq 7010 (Zybo dev board), БЕЗ использования инструментальной цепочки Xilinx (Vivado/SDK)?
  2. Можно ли собрать и запустить ARM код сборки (Thumb2) на Zynq, без использования Xilinx набор инструментов (Vivado/SDK)? Под этим я имею в виду писать программу, которая НЕ использует ни одну из библиотек драйверов Xilinx или самогенерированный код инициализации (т. Е. Построение вашей собственной простой векторной таблицы, предоставление определений для разных обработчиков исключений и т. Д.)
  3. Если нет, возможно ли это по крайней мере, собрать и связать код сборки ARM с SDK?

Я помогаю переносить вводный встроенный системный курс с STM32F4 (плата ARM M3 dev) на Zynq, а первые несколько недель - это введение в сборку. Обычно мы вручную делаем все из командной строки, используя инструментальную цепочку arm-none-eabi, поэтому мне было бы интересно сохранить эту структуру, а не сразу переходить в среду Xilinx Vivado/SDK. Однако я не смог найти никаких ресурсов при программировании устройства без инструмента Xilinx, который я считаю нечетным. Я не могу представить, чтобы это было невозможно, поэтому любая информация была бы весьма признательна.

Спасибо!

ответ

2

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

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


кажется, что вы можете избежать часть Vivado SDK и IDE, то Zynq 7000 Software Developer guide в Приложении А описывает использование 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 Technical Reference Manual подробно описывает формат заголовка BootROM.
Он также объясняет различные аппаратные компоненты и принятые архитектурные решения, включая процесс загрузки и различные варианты голого металла.
Так что вы можете даже избавиться от bootgen и сделать свой собственный инструмент.

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


Я не знакомы с SDK, но я уверен, что если вы шпионить вокруг папки SDK бен вы найдете много обычных GNU инструментов для ARM набора инструментов (в значительной степени как это происходит для Android NDK).
XILINX утверждает, что в одном из своих документов (увы, я не помню, какой) они использовали стандартные инструменты GNU с небольшими дополнениями.

Как для избежания архивов XILINX вы можете попытаться прочитать их источник если имеющийся или дизассемблировать их двоичные файлы.
С помощью Технического справочника вы должны быть в состоянии избежать их в первую очередь.


XILINX делает большую работу, описывающую ее совет по двум документам, связанных (а shorter one is here), чтение и объяснит много вещей происходит под капотом.

Обычно продавцы повторно используют существующие инструменты, поэтому, если XILINX не разработал свои собственные, вы должны найти инструменты командной строки, используемые знакомой средой.
И вы можете даже полюбить Vivado SDK, зная, как он работает в глубине!

+0

Большое спасибо за информацию. Я очень хорошо выкопал оба этих документа, и он отлично справляется с архитектурой и «чем», но у них мало информации о том, «как» (в частности, «как» получить бинарный на darn вещь), чтобы делать что-либо вне среды SDK. – Brett

+0

не могли бы вы прояснить, что вы подразумеваете под «no C runtime» в своем заявлении: «Таким образом, вы можете использовать GCC для генерации ARM ELF, а не bootgen, чтобы сделать загрузочный образ (конечно, не C Runtime)». – Brett

+0

@ В то время как среда выполнения C (например, 'printf' и др.) Привязана к определенной архитектуре. Если у вас нет C lib для ZyBo, вы не можете их использовать. –

2

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

+0

Хорошо, это именно то, что я подозревал. К счастью, меня даже не интересует какое-либо взаимодействие с логикой FPGA прямо сейчас, я просто хочу иметь возможность собирать, связывать и выполнять простой битовый язык компоновки на одном из процессоров. Это было бы тривиальной задачей, скажем, cortex-M3, но я изо всех сил пытаюсь разобраться с тем, как бороться с гораздо более обширным воссозданием, требуемым zynq. – Brett

+0

Несомненно, что Xilinx «интегрировал» набор инструментов, так что выход их инструмента «без видимости» интегрируется в загрузку изображений fpga или что-то еще. Я слышал, но не исследовал платформу zynq, но не думал больше о том, почему вы не могли реализовать someting в fpga, что позволяет вам вытолкнуть программу в ram, а затем сбросить сброс на руке. в основном, поскольку вы понимаете на каком-то mcu cortex-m, что чип-компания уже построила интерфейс или несколько для загрузки программ во флэш-память –

+0

, без сомнения, у xilinx есть что-то здесь, но в их песочнице. поэтому вы должны увидеть, можете ли вы определить их песочницу и заменить выход компонента или создать свой собственный интерфейс на руку и использовать это. если повезет, возможно, у вас есть прямой доступ к SWD-сигналам, тогда вы можете использовать stlink или все, что легко получить от поддерживаемого openocd отладчика. –

 Смежные вопросы

  • Нет связанных вопросов^_^