Установка PASM на четвёртое ядро Beaglebone
Всем привет. Скажите пожалуйста, можно ли установить PASM на Beaglebone с четвёртым ядром (Linux beaglebone 4.19.94-ti-r42)? Если да, то как? Я находил в интернете гайд только под третье ядро.
BONKooff
24.04.22 23:56:30 MSK
- Ответить на это сообщение
- Ссылка

Что установить? Активную подвеску Porsche? Ассемблер? Зачем их ставить на ядро и как?
shalom_ ★★
( 25.04.22 22:29:24 MSK )
- Ответить на это сообщение
- Показать ответ
- Ссылка
Ответ на: комментарий от shalom_ 25.04.22 22:29:24 MSK
Какая подвеска? Какое порше? Вы о чем? Есть биглбон. Видел для него есть PASM,что позволяет писать проги на ассемблере. Вот и спрашиваю. Уточнил какое у меня ядро стоит (kernal 4.x), так как гайд по установке pasm на бигл есть только для 3-его
BONKooff
( 29.04.22 16:09:51 MSK ) автор топика
- Ответить на это сообщение
- Показать ответ
- Ссылка
Ответ на: комментарий от BONKooff 29.04.22 16:09:51 MSK
Видел для него есть PASM,что позволяет писать проги на ассемблере.
Для какого именно ядра: ARM или PRU? Линукс ядро на ARM крутится. А PASM для PRU ядра. Но поддержка PASM истекла 6 лет назад. Новый ассемблер CLPRU появился 8 лет назад. PRU porting pasm to clpru.
gag ★★★★★
( 29.04.22 16:42:55 MSK )
- Ответить на это сообщение
- Ссылка
BeagleBone Black (BBONE-BLACK-4G)
![]()
BeagleBone Black (BBONE-BLACK-4G) — доступная платформа с большим потенциалом и не дорогим процессором A8 Sitara ™ AM3358 ARM® Cortex ™ от компании Texas Instruments.
BBONE-BLACK-4G поставляется с предустановленным Ångström Linux, который записан в 4Gb FLASH-память на плате. Так же плата поддерживает многие другие операционные системы Linux, такие как Ubuntu, Android и Fedora.
Как и предшественники, BeagleBone Black разработан, в первую очередь, для сообщества Open Source, а так же для всех кто хочет испытать недорогой процессор ARM® Cortex™ A8. Плата включает минимальный набор функций, что позволяет пользователю оценить производительность процессора, а так же обеспечивается доступ ко многим интерфейсам, для использования платы расширения и реализации различных функций, так же пользователь может разработать свою собственную плату расширения.
BeagleBone Black оснащен микропроцессором TI Sitara™ AM3358AZCZ100, основанным на базе ядра ARM®Cortex™-A8 с улучшенным выводом изображения, обработкой графики, работой с периферийными и промышленными интерфейсами, такими как EtherCAT и PROFIBUS. Плата оснащена 512 Мб оперативной памяти DDR3L, 32КБ EEPROM и 4 Гб встроенной MMC (EMMC) памятью, которая является источником для загрузки ПО по умолчанию. Так же на плате расположен слот для карт памяти MicroSD, которая может использоваться в качестве вторичного источника загрузи. BeagleBone Black поддерживает четыре режима загрузки со встроенной EMMC, с карты памяти MicroSD, через последовательный интерфейс и USB. Предусмотрен переключатель для выбора режима загрузки.
В отличии от оригинального BeagleBone, модель BeagleBone Black имеет встроенный HDMI интерфейс для подключения к телевизору или монитору. Так же на плате установлен 10/100 Ethernet, последовательный порт отладки, хост-порт USB 2.0, кнопка сброса, кнопка питания и пять синих светодиодов индикации. На BeagleBone Black можно установить до четырех плат расширения, которые могут быть установлены в разъемы расширения. Большинство плат расширения, предназначенных для BeagleBone, будут работать и на BeagleBone Black.
Официальный сайт beagleboard
Начало работы с BeagleBone
Процессор: TI Sitara AM3358AZCZ100, 1GHz, 2000 MIPS Архитектура: ARM®Cortex™-A8, программируемый блок Subsystem в режиме реального времени GPU: SGX530 Graphics Engine Память: 512Mb RAM ОС: загружается с 4Gb eMMC установленной на плате или карты памяти формата MicroSD Размеры: 90x55x20мм Питание: 5В/1А, miniUSB или DC jack. Пользовательские интерфейсы ввода/вывода: кнопка сброса, кнопка загрузки, кнопка питания, светодиод индикатор питания, 4 конфиг. пользователем светодиода Интерфейсы: miniUSB 2.0 Client port, USB 2.0 Host port (500мА), Seriai Port UART 6pin 3.3В TTL, Ethernet 10/100, microHDMI, LCD interface, audio через HDMI, MicroSD card slot. Интерфейсы расширения: LCD, UART, eMMC, ADC, I2C, SPI, PWM
Руководство пользователя [EN] (1818795_0.pdf, 5,598 Kb) [Скачать]
Документация MPU AM335x ARM Cotrex-A8 [EN] (ti.datasheet.pdf, 2,871 Kb) [Скачать]
Embedded Linux в двух словах. Первое
В этой небольшой серии статей я попытаюсь пролить свет на тему построения Embedded Linux устройств, начиная от сборки загрузчика и до написания драйвера под отдельно разработанный внешний модуль с автоматизацией всех промежуточных процессов.
Платформой послужит плата BeagleBone Black с процессором производства Техасских Инструментов AM3358 и ядром Arm Cortex-A8, и, чтобы не плодить мигающие светодиодами мануалы, основной задачей устройства будет отправка смайлов в топовый чат, широко известного в узких кругах, сайта, в соответствии с командами от смайл-пульта. Впрочем, без мигания светодиодами тоже не обошлось.
Итак, на столе лежит чистая, т.е. без каких-либо предустановленных дистрибутивов, плата BeagleBone Black, блок питания, переходник USB-UART. Для общения с платой, переходник нужно подключить к 6-ти выводному разъему, где первый вывод обозначен точкой — это GND, выводы 4/5 — RX/TX соответственно. После установки скорости в какой-либо терминальной программе, например putty, на 115200, можно взаимодействовать с платой, о подключении подробнее и с картинками здесь.
Топовые чаты, пульты и светодиоды будут позже, а сейчас на плату подается питание и плата отвечает CCCCCCCCCCC

В переводе с бутлоадерского это означает, что первичному загрузчику, зашитому в ROM процессора, нечего загружать. Ситуацию проясняет Reference Manual, где на странице 5025 в разделе 26.1.5 описана процедура начальной загрузки. Процедура такая: первичный загрузчик проводит некоторую инициализацию: тактирование процессора, необходимой периферии, того же UART, и, в зависимости от логических уровней на выводах SYSBOOT, строит приоритетный список источников где можно взять следующий загрузчик, т.е. посмотреть сначала на MMC карте, SPI-EEPROM или сразу ждать данных по Ethernet.
Я использую способ загрузки с помощью SD карты, вот что говорит об этом раздел RM 26.1.8.5.5 на странице 5057: первичный загрузчик сначала проверяет несколько адресов 0x0/ 0x20000/ 0x40000/ 0x60000 на наличие так называемой TOC структуры, по которой он может определить загрузочный код, если так код не найти, то первичный загрузчик, предполагая на SD карте наличие файловой системы FAT, будет искать там файл с названием MLO, как это расшифровывается в RM не сказано, но многие склоняются что Master LOader. Возникает резонный вопрос, где же взять этот MLO?
Das U-Boot
Das U-Boot или просто U-Boot — Universal Boot Loader, один из самых, если не самый, распространенный загрузчик для встроенных систем, именно с его помощью можно создать требуемый вторичный загрузчик (MLO), который будет загружать третичный загрузчик (сам U-Boot), который будет загружать ядро Linux.
Перед скачиванием U-Boot, стоит сходить в репозиторий и найти тег последней версии, далее
git clone -b v2021.01 https://gitlab.denx.de/u-boot/u-boot --depth=1
U-Boot содержит больше тысячи конфигураций, в том числе нужную:
Это конфигурация платы AM335x evaluation module, этот модуль лежит в основе других плат, в том числе BeagleBone Black, что можно видеть, к примеру, по Device Tree, но о нем позже. Настраивается и собирается U-Boot с помощью Kconfig, то же, что используется и при сборке ядра Linux.
Установка нужного конфига:
make am335x_defconfig
make menuconfig
Можно, к примеру, убрать, установленную по умолчанию, 2-х секундную задержку при загрузке платы с U-Boot
Boot options —> Autoboot options —> (0) delay in seconds before automatically booting
В вышеуказанных командах, используется компилятор по умолчанию, если таковой в системе установлен, и, скорее всего, он не подходит для ARM процессоров, и здесь пора упомянуть о кросскомпиляции.
ARM Toolchain
Один из видов кросскомпиляции это сборка на одной архитектуре, как правило x86-64, именуемой HOST, исходного кода для другой, именуемой TARGET. Например, для TARGET архитектуры ARMv7-A, ядра ARM CortexA-8 процессора AM3358, платы BeagleBone Black. К слову, чтобы не запутаться в ARM’ах, даже есть свой справочник, так их много и разных.
Сама сборка осуществляется набором инструментов — компилятор, компоновщик, runtime библиотеки, заголовочные файлы ядра; так называемый Toolchain. Toolchain можно собрать самостоятельно либо с помощью crosstool-NG, а можно взять готовый от компании Linaro, или самой ARM. Здесь я буду использовать Toolchain от ARM “GNU Toolchain for the A-profile Architecture Version 10.2-2020.11, x86_64 Linux hosted cross compilers, AArch32 target with hard float (arm-linux-none-gnueabihf)», если не вдаваться в излишние подробности, то это все означает, что набор инструментов будет работать на десктопной машине с Linux и собирать программы для 32-х битной ARM платформы с аппаратной поддержкой операций с плавающей запятой.
Теперь для успешной сборки U-Boot, нужно указать в переменных ARCH и CROSS_COMPILE требуемые архитектуру и путь к кросскомпилятору соответственно, например так
make ARCH=arm CROSS_COMPILE=~/toolchain/bin/arm-none-linux-gnueabihf- am335x_evm_defconfig
make ARCH=arm CROSS_COMPILE=~/toolchain/bin/arm-none-linux-gnueabihf- menuconfig
make ARCH=arm CROSS_COMPILE=~/toolchain/bin/arm-none-linux-gnueabihf-
Либо использовать export ARCH/CROSS_COMPILE , чтобы каждый раз не набирать все это. Я, для наглядности, буду каждый раз набирать все это.
После сборки U-Boot, в папке появятся необходимые файлы, а именно
- MLO — вторичный загрузчик (напомню, первичный зашит в самом процессоре)
- u-boot.img — третичный загрузчик, собственно U-Boot
Для успешной загрузки с SD карты, нужно ее некоторым образом разметить. Карта должна содержать минимум два раздела, первый, отмеченный как BOOT, с файловой системой FAT, второй раздел с ext4. Разметить карту можно, к примеру, программой fdisk.
Теперь нужно просто скопировать результаты сборки U-Boot в FAT раздел, вставить карту в BeagleBone Black и в терминале наблюдать уже более осознанный ответ платы

В ответе платы есть такие строки
Failed to load ‘boot.scr’
Failed to load ‘uEnv.txt’
U-Boot, во время загрузки, смотрит наличие дополнительных команд, сначала в файле boot.scr, при его наличии, затем, если boot.scr не нашлось, в uEnv.txt. Эти файлы, помимо очередности при поиске, отличаются тем, что в файле uEnv.txt, дополнительные команды представлены в текстовом виде, т.е. он проще для восприятия и редактирования. U-Boot не создает файлы с дополнительными командами, делать это нужно самостоятельно.
bootpart=0:1 devtype=mmc bootdir= bootfile=zImage bootpartition=mmcblk0p2 console=ttyS0,115200n8 loadaddr=0x82000000 fdtaddr=0x88000000 set_mmc1=if test $board_name = A33515BB; then setenv bootpartition mmcblk1p2; fi set_bootargs=setenv bootargs console=$ root=/dev/$ rw rootfstype=ext4 rootwait uenvcmd=run set_mmc1; run set_bootargs;run loadimage;run loadfdt;printenv bootargs;bootz $ - $
Здесь происходят некоторые манипуляции в результате которых U-Boot загружает из SD карты в RAM по адресу [loadaddr] — образ ядра [zImage], и по адресу [fdtaddr] — дерево устройств [Flattened Device Tree]. Формируются аргументы, передаваемые ядру Linux, это параметры консоли, к которой подключен переходник USB-UART [console=ttyS0,115200n8], место размещения корневой файловой системы [bootpartition=mmcblk0p2], параметры разрешения на чтение/запись корневой файловой системы [rw], ее тип [ext4] и ожидание появления корневой файловой системы [rootwait]. Чтобы раскрутить всю цепочку действий U-Boot, можно, после того как U-Boot прекратит попытки найти что бы загрузить и выдаст приглашение на работу в виде =>, ввести команду printenv , она покажет значения всех переменных, которыми располагает U-Boot.

В завершении своей работы U-Boot, командой bootz , вместе с вышеуказанными аргументами и адресом дерева устройств, передает управление ядру Linux.
Ядро Linux
Прежде чем приступать к любым действиям с ядром, стоит заглянуть сюда и убедится в наличии необходимых пакетов. Следующим шагом нужно определиться с тем, какую версию ядра использовать. Здесь я использую версию 5.4.92 и вот по каким соображениям. Одной из основных причин того, что не стоит брать просто последнюю версию ядра, доступную на данный момент, наряду с наличием драйверов, является невозможность быстро протестировать это ядро на всем разнообразии платформ поддерживаемых Linux, а значит можно потратить кучу сил и времени на исправление неполадок, если что-то пойдет не так, и не факт что это вообще получится сделать. BeagleBone Black имеет официальный репозиторий, где можно найти версию ядра, протестированную на данной платформе, и long term версия 5.4.92 была последней на тот момент.
Нужный конфиг, расположенный в /arch/arm/configs, называется omap2plus_defconfig, OMAP — это название линейки процессоров, продолжением которых является AM3358, впринципе, подойдет и более общий multi_v7_defconfig.
Сам конфиг пока остается без изменений, поэтому можно просто его установить и запустить компиляцию ядра(zImage), модулей(modules) и дерева устройств(dtbs)
make -j6 ARCH=arm CROSS_COMPILE=~/toolchain/bin/arm-none-linux-gnueabihf- omap2plus_defconfig
make -j6 ARCH=arm CROSS_COMPILE=~/toolchain/bin/arm-none-linux-gnueabihf- zImage modules dtbs

Проходит некоторое время.
Результат сборки, в виде zImage, находится в /arch/arm/boot, там же в папке /dts находится скомпилированное дерево устройств am335x-boneblack.dtb, оба отправляются на SD карту к файлам загрузчика. На этом FAT раздел SD карты можно считать скомплектованным. Итого, там присутствуют:
- MLO — вторичный загрузчик
- u-boot.img — третичный загрузчик
- uEnv.txt — дополнительные команды загрузчика
- zImage — образ ядра Linux
- am335x-boneblack.dtb — скомпилированное дерево устройств платы
Еще при сборке ядра заказывались модули ядра, но они уже относятся к корневой файловой системе.
Корневая файловая система. BusyBox
Ядро получает корневую файловую систему путем монтирования блочного устройства, заданного в, переданном при запуске ядра, аргументе root=, и далее, первым делом, исполняет оттуда программу под названием init.
Если запустить BeagleBone Black, имея только вышеуказанные файлы для FAT раздела, то ядро будет паниковать по причине отсутствия init и, в целом, по причине пустой rootfs, т.е. корневой файловой системы.

Можно шаг за шагом создать все минимально необходимые компоненты корневой файловой системы, такие как оболочка, различные демоны запускаемые init, сам init, конфигурационные файлы, узлы устройств, псевдофайловые системы /proc и /sys и просто системные приложения. Для желающих совершать подобные подвиги, существует проект Linux From Scratch, здесь же я воспользуюсь швейцарским ножом встроенных систем с Linux, утилитой BusyBox.

Скачивание последней, на тот момент, версии:
git clone -b 1_32_1 https://git.busybox.net/busybox
Настройка конфигурации по умолчанию:
make defconfig
Чтобы не думать сейчас о разделяемых библиотеках, стоит установить статическую сборку BusyBox:
make menuconfig
Settings —> Build static binary (no shared libs)
make -j6 ARCH=arm CROSS_COMPILE=~/toolchain/bin/arm-none-linux-gnueabihf-
Установка в папку по умолчанию _install:
make ARCH=arm CROSS_COMPILE=~/toolchain/bin/arm-none-linux-gnueabihf- install
Теперь в папке _install можно видеть будущую корневую файловую систему, в которую нужно добавить некоторые вещи.
Папки, помимо созданных BusyBox:
mkdir dev etc lib proc sys
Стартовый скрипт. Дело в том, что, запускаемая в первую очередь, программа init, делает много полезного, например, выводит в консоль приглашение, но до выдачи приглашения, init проверяет наличие стартового скрипта /etc/init.d/rcS, и, при наличии, запускает его.
mkdir ./etc/init.d touch ./etc/init.d/rcS chmod +x ./etc/init.d/rcS
#!/bin/sh mount -t proc proc /proc mount -t sysfs sysfs /sys
Этот скрипт монтирует псевдофайловые системы proc и sysfs, и ничего не мешает ему запускать, к примеру, пользовательскую программу, отвечающую за функционал устройства, но лучше будет делать это в отдельных скриптах, скомпонованных по функциональному назначению.
Стоит сказать, что работа init, на самом деле, начинается с чтения конфигурационного файла /etc/inittab, но BusyBox’овская init включает таблицу inittab по умолчанию, если таковой не окажется в корневой файловой системе.
Теперь пора вспомнить про модули ядра. Их также нужно разместить в корневой файловой системе в /lib/modules/5.4.92/, но сейчас они разбросаны по всей папке в которой собиралось ядро. Чтобы собрать модули в кучу, нужно в папке с ядром выполнить
make -j6 INSTALL_MOD_PATH=~/busybox/_install modules_install
Где в INSTALL_MOD_PATH указать путь к папке с корневой файловой системой, кросскомпилятор указывать не нужно, т.к. здесь модули ядра просто копируются по месту назначения. В результате папка /lib корневой файловой системы пополнится разделом /lib/mudules/5.4.92/ содержащим модули ядра, полученные при компиляции ядра.
Осталось скопировать все содержимое папки _install во второй раздел SD карты, тот который с ext4, и поменять владельца всего содержимого на root.
После запуска BeagleBone Black с корневой файловой системой, через 1.910315 секунды после старта ядра, система предложит активировать консоль и начать работу.

Но начать работу в такой системе, скорее всего не получится, т.к. в ней нет ничего кроме системных утилит BusyBox и моей небольшой программы, нарисовавшей приветствие, зато, эта система поможет получить общее представление о том, какая магия происходит внутри подобных устройств. Именно общее, т.к. в реальных устройствах, из-за необходимости минимизации времени загрузки, ограниченности ресурсов, заточенности под конкретную задачу, различий между ARM процессорами, построение системы может сильно отличаться. Например, на малинке, вообще сначала стартует графический процессор, который затем запускает все остальное.
По поводу же заявленных в начале драйверов, взаимодействия с внешними устройствами, автоматизации сборки и некоторого полезного функционала, пойдет рассказ в следующей статье.
- Настройка Linux
- Open source
- C
- DIY или Сделай сам
Real-time BeagleBone: использование высокоскоростных выводов

Здравствуйте, уважаемые хабравчане! Давно уже являюсь читателем Хабра, но до сих пор не мог найти достойной темы для публикации. И вот, наконец, хорошенько прошерстив Хабр и GT, удивился отсутствию публикаций, посвященных программируемой подсистеме реального времени ( PRU‐ICSS ) линейки процессоров Sitara TM фирмы TI .
Наиболее популярной и доступной отладочной платой с процессором AM335x является так называемый «одноплатник» BeagleBone Black (White,Green). И именно наличие PRU делает BeagleBone наиболее предпочтительным для использования в hardware-проектах по сравнению с другими бюджетными одноплатниками типа *Pi. Кроме того, в некоторых случаях BBB-PRU может достаточно эффективно заменить связку ПК — МК — ПЛИС .
В данной статье приведен краткий обзор подсистемы PRU и режимов работы высокоскоростных портов ввода/вывода, рассмотрен пошаговый пример инициализации высокоскоростных портов вывода (Enhanced GPIO) и произведена оценка их производительности.
Введение
Сразу оговорюсь, что не буду подробно останавливаться на характеристиках и настройках самого BeagleBone, так как данные темы достаточно хорошо освещены в интернете, просто в конце приведу наиболее полезные, на мой взгляд, ресурсы. А сконцентрируюсь непосредственно на подсистеме PRU‐ICSS .
Аналогичные PRU решения, из числа популярных, мною найдены только для Intel Edison(кстати, tutorial на эту тему). Но при схожей цене Edison уступает по производительности и характеристикам.
ВАЖНО! Не все описанные далее режимы работы PRU и не в полном объеме возможно реализовать с помощью BeagleBone из-за физических ограничений топологии платы.
Значительная часть приведенных в публикации материалов является переводом, адаптацией, модификацией или комбинацией ресурсов, приведенных в полезных источниках в конце статьи.
Итак, что же представляет собой подсистема реального времени?
Обзор PRU‐ICSS
PRU-ICSS состоит из двух 32-битных ядер, имеющих RISC -архитектуру и работающих на частоте 200МГц. Каждое ядро имеет свою область памяти, а также совместную с Linux область памяти, может использовать выводы общего назначения, расположенные на разъемах P8-P9, и формировать прерывания.
PRU является важным дополнением всей платформы BeagleBone, позволяющим обеспечивать поддержку для приложений с жесткими временными ограничениями. Но стоит отметить, что PRU не является аппаратным ускорителем, позволяющим повысить быстродействие Linux-приложений. На PRU можно возложить выполнение отдельных функций и задач, таких как реализация программных высокоскоростных протоколов передачи данных, в том числе и нестандартных, или цифровой обработки сигналов датчиков в режиме реально времени. Также можно просто реализовать дополнительную аппаратуру, например шестой UART ttyO6.
Архитектура PRU
Не буду углубляться в перевод мануалов, назову основные характеристики системы и прокомментирую некоторые слайды из презентаций и схемы из мануалов.

Основным преимуществом PRU является короткое время доступа к локальным памяти и периферии. В тактах опорной частоты оно даже ниже, чем у подсистемы ARM. Более подробное описание задержек записи/чтения приведено здесь.
Подсистема PRU включает в себя следующие блоки:

- Два ядра PRU, каждое включает в себя:
- 8KB памяти инструкций;
- 8KB памяти данных;
- Высокоскоростной интерфейс шины OCP для доступа к памяти и периферии ARM;
- Порты ввода/вывода ( eGPIO ) с поддержкой асинхронного захвата и последовательного вывода;
- Умножитель с возможностью накопления ( MAC );
- Быстродействующая временная память (Scratchpad memory):
- 3 блока, в каждом 30 32-битных регистров;
- Прямой доступ обеспечивает возможность быстрой синхронизации между ядрами PRU;
- Один контроллер прерываний (INTC):
- Прием до 64 внешних событий;
- 10 каналов прерываний;
- Аппаратная приоритизация событий;
- Один комплект периферии для промышленного Ethernet:
- Один таймер с 10 событиями захвата и 8 сравнения;
- Два сигнала синхронизации;
- Два 16-битных сторожевых таймера;
- Цифровые порты ввода/вывода;
- 12KB памяти общего назначения;
- Формирование 16 программных событий;
- Один двухпортовый модуль Ethernet MII;
- Один порт MDIO ;
- Один приемопередатчик UART c тактовой частотой 192МГц;
- Один модуль захвата ( ECAP );
- Поддержка гибкого управления питанием;
Теперь более подробно рассмотрим структуру быстродействующих портов ввода/вывода, что непосредственно является темой приведенного ниже урока и предметом исследования.
Управление портами ввода и вывода осуществляется с помощью регистров R31 и R30 соответствено. Примечательно, что регистр R31 также используется для формирования системных прерываний. Таким образом, запись в R31 генерирует прерывание, а чтение из регистра возвращает информацию о состоянии портов ввода (GPI) и контроллере прерываний (INTC).

Высокая скорость портов ввода/вывода обеспечивается прямым доступом PRU, в отличие от ядра ARM, у которого доступ к GPIO осуществляется через несколько уровней соединений.
Режимы работы GPIO
Режимы задаются путем установки соответствующих битов в конфигурационном регистре CFG. Прямое включение является режимом по-умолчанию и не требует дополнительных настроек.
Порты ввода (GPI — R31) имеют 4 режима работы: