Перейти к содержанию

    

Cortex A7, программирование и отладка.

Только что, AlexandrY сказал:

Лучше расскажите почему не осилили линукс на нем и застряли на достаточно убогой FreeRTOS.
Почему уже двое здесь не могут осилить линукс на Zynq.
Что там с ним не так? 

Мы и не пытались туда линуксы прикручивать. Вы наши задачи знаете? Не GUI на экранчиках рисовать, все-таки.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
1 hour ago, Arlleex said:

Из камня торчит полноценный JTAG - цепляемся к нему и вперед. Насчет SRAM ошибаетесь - внутри чипа есть накристальная память OCM. Другое дело, что ее достаточно мало.

У нас рядом стоит QSPI-Flash, с которой грузится SoC, ровно как на многих других подобных камнях (всякие FPGA, например).

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
3 часа назад, Metallist64 сказал:

Поделитесь пожалуйста каким софтом и железом пользовались?

Компилятор gcc-none-eabi, возился с Zedboard.

 

3 часа назад, Metallist64 сказал:

Интрересует, как в случае с А9 выглядит клацанье портами и к примеру, работа с Ethernet.

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

3 часа назад, Metallist64 сказал:

И самый страшный вопрос: как запускается/записывается и отлажывается программа ? В этих процах нет же встроенной флэши и SRAM ...

Тоже всё обычно - через JTAG. В каждом случае свой адаптер для подключения, да и софт тоже часто разный. У меня был опыт с Cyclone V SoC (Altera), тут адаптер штатный USB Blaster, из софта - DS-5 Studio, и Zynq7000 - там был какой-то от Digilent, а на Zedboard он в составе самой платы, софт - SDK из состава Vivado (это среда проектирования от Xilinx). Обе оболочки сделаны на основе Eclipse, подход похож, хотя есть какие-то мелкие отличия в настройках. 

 

3 часа назад, Metallist64 сказал:

Очень интересно.

У меня была цель: получить наименее ресурсоёмкое решение в плане габаритов, энергопотребления и наилучшее в плане реалтаймовости - нам нужна была замена устаревшей связке внешний процессор + ПЛИС. Планировалось  одно ядро запускать в bare-metal, а второе, если будет надо - под линух (это если потребуются всякие свистелки и/или какие-то решения, которые уже есть в готовом виде под линух) - в общем, на вырост. Но в той конфигурации нужно было просто однокристальное решение на современной элементной базе.

 

На борту этой СнК есть 256 кбайт ОЗУ (на уровне L2) - OCM, и по замыслу вся программа должна была туда помещаться - это минимизирует латентность доступа со стороны процессорных ядер, что положительно сказывается на реалтаймовости. Эта память используется загрузчиком (а иначе просто никак - ведь должен же он где-то жить, - собственно ОСМ для него и предназначена по замыслу вендора), который после того, как отработал, уже больше не нужен, поэтому схема работы предполагалась такой: при старте запускается загрузчик, который инициализирует всю аппаратуру на низком уровне, далее переконфигурирует OCM в монолитное адресное пространство в старших адресах (при подаче питания 192 кбайта отмаплены на младшие адреса, а 64 - на старшие, т.е. ОСМ не монолитна), заливает туда программу и передаёт ей управление. Таким образом, после запуска прикладной программы загрузчика уже и нет, т.е. он не потребляет ресурсов совсем, и пользовательской программе доступны все 256 кбайт.

 

Проект я не доделал до конца - дошёл до загрузки прикладной программы. Но собственно сам загрузчик по сути и является bare-metal приложением, и все основные операции там сделаны: начальная инициализация аппаратуры, стартап, необходимый для C/C++ программы, переход на main, где уже полноценная работа с периферией (QSPI, GPIO), система прерываний (GIC) и т.д.

 

Это сам проект приложения bare-metal.

Для его работы нужны заголовочные файлы с описанием периферии, их вендор не поставляет, пришлось делать: https://github.com/emb-lib/zynq7000

Есть некоторое количество кода, который предполагался быть общим для разных проектов (там пока немного - поддержка QSPI и прерываний, предполагалось постепенно развивать это, дополнять) вынесено в либу: https://github.com/emb-lib/z7lib

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

Возможно, самое для вас интересное: подробное описание действий низкоуровневого кода - от самого старта проца и до сишного уровня:

https://github.com/harryzhurov/zynq_fsbl/wiki/Конспект-операций,-выполняемых-первичным-загрузчиком
 

Начало на этой странице, дальше идите по ссылкам, там в принципе понятно, что делается. Код этот взят от вендора, который его слепил по рекомендациям ARM (сниппеты прямо из Programming Manual взяты).

 

Ну, и до кучи несколько заметок:

 


 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
9 минут назад, Metallist64 сказал:

куда отладчиком  программа загружается? ОЗУ, как вы говорите, очень небольшое.

"Прошивка" отладчиком загружается туда, куда указано в линкерном скрипте (пример) - программные секции в сегмент программ, секции данных - в сегмент данных, это всё как обычно. А отладчик просто грузит это. Встроенное ОЗУ 256 кбайт, не так уж и мало для bare-metal приложения. На старте 192 кбайта встроенного ОЗУ (ОСМ) размещатся по адресу 0, от относительно этого адреса всё и грузится.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Существуют ли ultralight версии линуха для эмбеддед применений? Ну например для Zynq  когда надо только поднять сетевые протоколы и желательно иметь текстовую консоль и все. Желательно с RTOS вариантами обслуживания прерываний, системными таймерами  и ДМА. При использовании LAN наличие операционки обязательно, API лучше линух-совместимое, т.к программиста найти проще и дешевле, чем под экзотику типа vxworks.

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
7 minutes ago, khach said:

Существуют ли ultralight версии линуха для эмбеддед применений?

Можно собрать свою в том же buildroot'е. Для ядра есть RT-патчи, но они, конечно, не превратят Linux в RTOS. Как вариант, можно запустить RTOS на отдельном ядре.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
2 hours ago, Arlleex said:

Мы и не пытались туда линуксы прикручивать. Вы наши задачи знаете? Не GUI на экранчиках рисовать, все-таки.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
4 минуты назад, haker_fox сказал:

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

Изделия - стенды для моделирования отраженных радиолокационных сигналов от наземных и воздушных целей, преобразователи видеопотоков Fibre Channel в VGA/DVI и т.д. Много чего интересного, на самом деле, только сильно тайно:biggrin::acute:

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
9 hours ago, haker_fox said:

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

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

например в i.mx-ах эти ядра называются (внезапно) sdma, то есть это risc процессоры со своей официально недокументированной, но хакнутой системой команд, и вполне доступно (по крайней мере, наши программисты писали для них) подулучшить какие-то специфические обмены, непредусмотренные в официальных дистрибутивах

и вроде бы никто не отметил проблему с документацией - то есть если хочешь как-то запустить такой процессор, то нужно разбирать код линукса, потому что в текстовой документации многое либо вообще отсутствует, либо малопонятно/плохо описано. и даже кода u-boot-а недостаточно, там много оставляют "на потом", когда уже будет грузится ядро

подозреваю, что у каких-нибудь олвинеров, медиатеков и т.п. с документацией еще хуже

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
4 minutes ago, Arlleex said:

Изделия - стенды для моделирования отраженных радиолокационных сигналов от наземных и воздушных целей, преобразователи видеопотоков Fibre Channel в VGA/DVI и т.д. Много чего интересного, на самом деле, только сильно тайно:biggrin::acute:

:angel::blum:Браво! Впечатлён!!!

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
6 hours ago, Metallist64 said:

И самый страшный вопрос: как запускается/записывается и отлажывается программа ? В этих процах нет же встроенной флэши и SRAM ...

там внутри в внутрикристальной ПЗУ-хе сидит достаточно громоздкий загрузчик, который при запуске читает всякие фузы, иногда внешние ножки и когда поймет, с какой памяти NAND, SD, QSPI и т.п. он будет грузится, то читает оттуда не программу, а некоторые таблицы конфигурации, которые используются для запуска SDRAM-а и программа/линукс (точнее его ю-бут) грузится уже в "развернутую" систему

когда я пытался что-то посмотреть отладчиком, то проблема была в том, что линукс использует MMU и виртуальную память, а ни J-Link-и ни OpenOCD-шные интерфейсы не позволяли транслировать адреса - это делало отладку полностью бессмысленной/невозможной - не знаю как сейчас, но смотрю, что наши программисты ICD под линухом не используют, но для всяких кортекс-м и иар-ов вовсю используют ICD

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
4 hours ago, Arlleex said:

Изделия - стенды для моделирования отраженных радиолокационных сигналов от наземных и воздушных целей, преобразователи видеопотоков Fibre Channel в VGA/DVI и т.д.

Странный выбор. Я бы для такой задачи сперва на 66AK2H смотрел...

Что касается линуха на цинке - вполне себе он там поднимается. Правда надо брать Xilinx'овский fork 4.14, ибо в Mainline не все драйвера занесены.  И не надо заниматься разработкой по принципу "Проблемы программистов схемотехников не волнуют". Сейчас вот воюю с ZynqMP, с его загрузкой в 5 этапов..

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
20 минут назад, gosha-z сказал:

Странный выбор. Я бы для такой задачи сперва на 66AK2H смотрел...

Есть и он у нас. Валяется на полке плата отладочная с ним. Я конечно понимаю, что четырехядерный Cortex-A15 + восемь ядер DSP это круто, и мы даже вроде как хотели его применить в одном грандиозном проекте, но... Вот только была бы шина памяти на это барахло не одна - а отдельная - цены не было бы такому монстру. В наших задачах нужна большая производительность памяти, кэшами тут не обойдешься. А одна шина на всех говорит о том, что задержки в работе ядер из-за дележки шины будут почти не предсказуемыми, что не допустимо.

Я не говорил, что линуха на Zynq не поднимается. Это было просто не нужно. Возможно и на нашей улице перевернется грузовик с линухо-задачами, и мы будем натягивать эту ОС на камни.

Изменено пользователем Arlleex

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
11 minutes ago, Arlleex said:

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

Тогда 6678 в чистом виде... Как минимум шина памяти в два раза шире... Но это уже offtopic

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Для публикации сообщений создайте учётную запись или авторизуйтесь

Вы должны быть пользователем, чтобы оставить комментарий

Создать учетную запись

Зарегистрируйте новую учётную запись в нашем сообществе. Это очень просто!

Регистрация нового пользователя

Войти

Уже есть аккаунт? Войти в систему.

Войти