[sonycman 1]

dxp

Спасибо за столь развёрнутый ответ, было очень познавательно :beer:

 

Сам я пока тоже дальше простого Bare Metal приложения из под MPL загрузчика не забирался, но, если воспринимать SoC систему как большой микроконтроллер с программируемой логикой - выглядит весьма увлекательно, пусть для меня это просто хобби и занятие для души :)

 

Zynq весьма популярная SoC, имеет кучу обучающих роликов на ютубе и море различных отладочных плат, вот и тянет порой "пощупать" железяку :)

Но что в них раздражает - закрытость Xilinx для России, заставляющая людей плодить темы "Помогите скачать" и т.п.

 

ЗЫ: HDMI видео выход, как я понял, вообще без проблем организовать на ксайлинксе, даже без микросхемы-драйвера, что практически невозможно на альтере.

[dxp 65]

Zynq весьма популярная SoC, имеет кучу обучающих роликов на ютубе и море различных отладочных плат, вот и тянет порой "пощупать" железяку :)

А вы доку (ug585) скачайте и полистайте. :)

 

Но что в них раздражает - закрытость Xilinx для России, заставляющая людей плодить темы "Помогите скачать" и т.п.

Ну, я бы не сказал, что это закрытость. У любого вендора есть закрытые места. Вот что лучше по альтере в РФ, так это дистриьюторы (ЭФО, Гамма), что заметно даже по нашему форуму. Ну, и киты на CV разнообразнее и дешевле - Терасику зачёт. Например, Zedboard стоит "там" $495. Есть более младший вариант Zybo - $189, но на этом и всё. Фирменные от Xilinx - от 800+ зелёных рублей. В то же время Arrow SoCKit мы брали за $350, а он более нашпигованный, чем та же zedboard.

[dxp 65]

В общем, "если гора не идёт к Магомеду..."...

 

На основе официального мануала ug585-Zynq-7000-TRM.pdf создан набор заголовочных файлов с описаниями memory-mapped registers (MMRs). Регистры и описания их битовых полей распределены по файлам на основе модулей. Zynq7000 содержит 31 тип модулей, соответственно создан 31 файл с описаниями регистров. Плюс к этому добавлены ещё два файла: один просто включает в себя для удобства все остальные (ps7mmrs.h), и один содержит адреса модулей (ps7modmap.h), он используется в других файлах.

 

Взять можно тут.

 

Подробности.

 

Набор файлов не один, а три - в разных стилях, на основе :

• констант (const int, const uintptr);
• перечислений (enum);
• макросов (#define), это традиционный стиль.

Тут уж кому что больше нравится.

 

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

 

Вообще, в pdf'нике описание сделано по единому формату - зачёт редактору документа, но вот описания модулей делались, очевидно, разными людьми, тут полный разнобой и по стилям, по объёму информации, и по именованию регистров/полей, и т.д. и т.п. Из-за этого пришлось поредактировать.

 

Итого:

• Все имена приведены к единому стилю - в верхнем регистре с символами подчёркивания в качестве разделителей.
• Имена регистров выполнены по формату <MODULE_NAME>_<REGISTER_NAME>_REG. Исключение составляют регистры контроллера прерываний - GIC, там именование достаточно традиционное, почти все имена заканчиваются на R, что означает "регистр", поэтому суффикса _REG к ним не добавлено.
• Если модуль имеет два или более экземпляров, то после суффикса _REG в имени регистра следует ещё суффикс экземпляра модуля - например, регистры управления UART'ов имеют вид UART_CTRL_REG0 и UART_CTRL_REG1.
• Для каждого битового поля введены два макроса в формате <BITFIELD_NAME>_MASK (маска) <BITFIELD_NAME>_BPOS (позиция битового поля).
• Исходные имена, которые были в CaMeL стиле приведены к виду CA_ME_L.
• Немало было мест, где имена регистров и особенно битовых полей были идентичными.
• У некоторых битовых полей имён вообще не было, пришлось добавить.
• Отдельные имена регистров были очень длинными - фактически состояли из строки, описывающей все поля регистра, - заменены более короткими.
• В именах регистров и их полей общеупотребительные CONTROL, STATUS, INTERRUPT заменены на более короткие CTRL, STS, INT соответственно.
• Ну, и ещё кое-что по мелочи.

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

 

В общем, пока "первый блин". Но компилятор не ругается, т.е. синтаксически всё нормально и конфликта имён тоже нету.

 

Надеюсь, ещё кому-нибудь будет полезно. Замечания приветствуются.

 

Статистика ( Per Mod - количество регистров в модуле, Total - всего регистров в модулях данного типа, Bit Fields - количество битовых полей в регистрах модуля, внизу сумма):

--------------------------------------------------------------------------------
#   Module          Per Mod    Total     Bit Fields
--------------------------------------------------------------------------------
1   AXI_HP           10          40          35
2   CAN              33          66          179
3   DDRC             113         113         343
4   CTI              55          220         71
5   CORTEXA9_PMU     21          42          21
6   PTM              77          154         186
7   DAP              28          28          63
8   ETB              37          37          72
9   FTM              43          43          72
10   FUNNEL          26          26          57
11   ITM             62          62          79
12   TPIU            39          39          100
13   DEVCFG          20          20          172
14   DMAC            92          184         390
15   GEM             97          194         366
16   GPIO            52          52          61
17   QOS301          9           27          19
18   GPV_TRUSTZONE   2           2           2
19   I2C             11          22          69
20   L2CACHE         47          47          198
21   MPCORE          125         125         335
22   OCM             4           4           17
23   QSPI            19          19          92
24   SDIO            25          50          191
25   SLCR            162         162         1237
26   SMCC            27          27          170
27   SPI             13          26          59
28   SWDT            4           4           13
29   TTC             33          66          81
30   UART            16          32          119
31   USB             51          102         273
--------------------------------------------------------------------------------
Summary:           1353        2035        5142
********************************************************************************

 

 

 

 

[:-) 0]

14.04.2017 в 08:10, dxp сказал:

Сами-то ядра те же самые - Cortex-A9, поэтому компляторы там одни и те же. Это либо ARM, либо GCC (arm-none-eabi). Для сборки оболочку (IDE) не использую, поэтому мне без разницы - DS-5 это, XSDK или что угодно другое. Оболочка мне нужна только как отладчик. DS-5 в этом контексте сделана очень хорошо, в том числе есть поддержка всех периферийных регистров - удобно наблюдать за их содержимым и/или вносить в них изменения. Ещё консоль команд по функциональности почти как у GDB, мощные возможности по скриптингу. XSDK, к сожалению, по всем перечисленным фичам сливает по полной. :(

 

Подскажите, а как вы собираете проекты xsdk вне этой оболочки? Создаёте ли заранее bsp в ней и потом используете? Или как-то по-другому? Аналогично с hw? 

Самого меня раздражает, что изменение состава используемых библиотек bsp приводит к сбросу части настроек. И приходится ручками по gui тыкать повторно.

И ещё неясно, что хранить в системе контроля версий: только ли свой проект, но тогда ещё надо бы описывать вот все шаги по настройке bsp. 

 

В общем - не подскажете, есть ли более удобный путь, чем тот, который по умолчанию навязан xilinx?..

[dxp 65]

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

 

Попробую вспомнить, если что напутаю, не обессудьте. BSP, который генерит Vivado, не использую. Беру от него только пару файлов: ps7_init.h, ps7_init.c. Без них тяжело будет ининить всю эту обширную периферию. Весь код стартапа и fsbl свой, хотя многое заимствовано (особенно начальный код на  асме, где инитятся кэши, MMU - это, собственно, и не Xilinx'овский код, это из референса ARM всё взято, что правильно). Этот начальный код вообще не меняется в зависимости от проекта, он приводит в корректное состояние "железо" процессора, а это там всегда одинаково (а если вдруг что-то надо делать иначе, то это можно позже перенастроить).

 

Вот тут некоторые подробности. Кратко: подход с BSP у них - это копирование кода из их репов (преимущественно embeddedsw) под конкретный проект. Подход по моему мнению полностью ущербный: плодить копии кода вместо того, чтобы использовать общую библиотеку (набор библиотек). Поэтому заморочился созданием заголовочных файлов периферии (по ссылке есть) и начал писать собственную библиотеку (пока там есть только поддержка QSPI и прерывания - то, что нужно для загрузчика), написание собственного компактного и эффективного кода по трудозатратам (для меня) соизмеримо с кувырками с их мутным репом, bsp и прочим, а результат качественно иной. Ну, а технически сборка осуществляется запуском команды scons (наподобие как make). Хоть из предпочитаемого редактора, хоть из командной строки. В файле SConstruct можно посмотреть все подробности (опции компилятора, пути к исходникам и библиотекам и т.д.).

 

[:-) 0]

Спасибо большое! Ваши ответы всегда очень интересно и познавательно читать.