[Arlleex 131]

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

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

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

[Metallist64 0]

1 hour ago, Arlleex said:

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

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

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

[dxp 33]

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 взяты).

 

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

• про систему прерываний: https://github.com/harryzhurov/fsbl/wiki/Interrupts
• про горбатый Xilinx'овый QSPI: https://github.com/harryzhurov/fsbl/wiki/Quad-SPI

 

 

[dxp 33]

9 минут назад, Metallist64 сказал:

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

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

[khach 33]

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

 

 

[aaarrr 63]

7 minutes ago, khach said:

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

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

[haker_fox 60]

2 hours ago, Arlleex said:

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

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

[Arlleex 131]

4 минуты назад, haker_fox сказал:

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

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

[yes 5]

9 hours ago, haker_fox said:

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

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

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

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

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

 

 

[haker_fox 60]

4 minutes ago, Arlleex said:

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

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

[yes 5]

6 hours ago, Metallist64 said:

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

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

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

 

[gosha-z 2]

4 hours ago, Arlleex said:

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

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

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

[Arlleex 131]

20 минут назад, gosha-z сказал:

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

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

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

Изменено 11 января, 2019 пользователем Arlleex

[gosha-z 2]

11 minutes ago, Arlleex said:

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

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