Версии linux для встраиваемых систем

Linux для встраиваемых систем?

Русский перевод статьи Давида Клейдермачера, вышедшей летом в COTS Journal.

Претензий как к качеству перевода, так и к оригиналу можно найти много, но стоит учесть малый формат журнальной статьи.

Можно также предположить ангажированность автора (Green Hills — второй на рынке встраиваемых систем, да и русский перевод от продавца QNX), но за некоторыми оговорками можно признать неутешительную для Linux аргументацию справедливой, особенно интересно почитать о ценовой политике поставщиков встраиваемых Linux.

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

Re: Linux для встраиваемых систем?

Re: Linux для встраиваемых систем?

Re: Linux для встраиваемых систем?

Горячая любовь к линуксу со стороны этой компании давно ни для кого не секрет 🙂

Re: Linux для встраиваемых систем?

Хня полная
Автор похоже слабо представляет что твориться на рынке embedded, либо предопочитает не замечать

Re: Linux для встраиваемых систем?

Вот приду сегодня домой, да и расскажу своему DSL-500T, об прочитанном.

Re: Linux для встраиваемых систем?

Хех, не далее как сегодня на http://www.lrn.ru пробежала ссылка на сообщение о том, что Green Hills гордится тем, что сумела запустить Линукс в User Mode, под управлением себя, любимой. Что-то, сдается мне, что парить себе мозги поддержкой заведомо убитой платформы никто не станет 🙂

Re: Re: Linux для встраиваемых систем?

> Вот приду сегодня домой, да и расскажу своему DSL-500T, об прочитанном.

DSL-500T не hard-real-time система. Всё рассуждения в данной статье применимы только для hard-real-time. А такие тербывания важны в весьма определенном, но при этом и весьма жирном сегменте рынка. ДСЛ маршрутизаторы к такому сегменту не относятся.

Re: Linux для встраиваемых систем?

пока автор рассуждает об экономике, он во многом прав. коммерческая ос под готовую железяку (именно в том плане что вот контроллер, вот к нему RTOS), для которой требуется лишь реализовать прикладную задачу безусловно дешевле.

но вот если шаг вправо-влево с железом. тут уж всё равно ядерщика на работе придется держать.

ну а рассуждения про портирование кода для hard realtime embedded это шедевр. так и представляются армии бедных девелоперов, которые с утра доночи озабочены перетягиванием кода между ОС, а с ночи до утра — между железяками 🙂

Re: Re: Re: Linux для встраиваемых систем?

>DSL-500T не hard-real-time система. Всё рассуждения в данной статье
>применимы только для hard-real-time.

Дастаточно того, что в нем стоит ядро от MontaVista Linux, который с real-time,
покрайней мере у них это так заявленно. Хотя могу согласиться, что RT
таким устройствам не особо нужен.

Re: Re: Re: Re: Linux для встраиваемых систем?

В Montavista такой real-time — это что-то (проще всего об этом где-нибудь на LWN.net почитать). Ещё бы RTLinux припомнили. А зачем статья написана — непонятно, понятно, что Linux сделать RTOS — это проект века (не в смысле важности, а в смысле длительности!) и хлеб у QNX он явно не отнимет

Re: Re: Linux для встраиваемых систем?

во-первых шаги вправо-влево не так уж и часты, готорых решений на рынке очень много

во вторых даже если железо отчасти свое, зачем нужен ядерщик? драйвер может писать человек который в принципах той ОС для которой драйвер пишется ни бум-бум

насчет портирования. вот завтра к таким бедным девелоперам поеду. о-о-опс, уже сегодня 😉

Re: Re: Re: Re: Re: Linux для встраиваемых систем?

2Generic_Guest: скажем так — пытается отнимать, по крайней мере у GHS, например тот же DSL-500T, который отличается легендарной глючностью даже для D-Linka. )

Re: Re: Re: Re: Re: Re: Linux для встраиваемых систем?

хм. а руки выровнять тебе религия запрещает? 🙂 уже некошерно, да? :))))

Re: Re: Re: Re: Re: Re: Linux для встраиваемых систем?

Irsi отличаеться поистине легендарной глючностью, даже для виндовозника.

Re: Re: Re: Re: Re: Re: Linux для встраиваемых систем?

>например тот же DSL-500T, который отличается легендарной глючностью
>даже для D-Linka. )

С чего ему глючить то? У меня он почему-то не глючит и выполняет все, что
я от него хочу.

Re: Re: Re: Re: Re: Re: Re: Универсальный менеджер пакетов

Re: Linux для встраиваемых систем?

Самое интересное в этой статье, что непонятно с кем спорит автор. имхо — сам с собой. Лялих не проектировался как ОСРВ. это бред. а все патчи которые придумывают мантависта и иже с ними — или поделки «just for fun» или придумано для зарабатывания бабок (берем бесплатное, абрабатываем напильником, башляем немерянные бабки:). с софтом «ради прикола» (перевод вольный:) все и так понятно — нравится пользуйся, а не нравится — ищи другой. и с бабками — тоже вопросов нет 🙂 так что колхоз — дело добровольное! а все остальное содержимое статьи очень похоже на «факты» оффтопика — берем и притягиваем за уши, чтоб звучало покрасивше и лапши на уши больше навешивало.:))) кароче, моё имхо по поводу статьи — акулы капитализма почувствовали «учащенное дыхание в спину» со стороны опенсоурса и забеспокоились о своих бабках 🙂 а по такому поводу могу привести васказывание Ганди:

«с начала они не замечают вас

потом они смеются над вами

потом борются с вами

Re: Re: Re: Re: Re: Re: Re: Re: Универсальный менеджер пакетов

2lenin — чем? тем что обьясняет почему линукс не подходит для того, для чего не предназначается? может написать статью о том , что микрускопом забивать гвозди неудобней, чем молотком? знаменитым стану. в узком кругу своих знакомых :)))

Re: Re: Re: Re: Re: Re: Re: Универсальный менеджер пакетов

Огромное количество людей не понимают, что Linux — не RTOS, никогда ей не была и никакие патчи ей не помогут стать RTOS. Огромному количеству людей просверлили мозг Монта-Виста и другие мошенники. Огромное количество людей даже не имеют понятия, что такое РТ, зато имеют авторитет и очень громко кричат. Приходилось спорить с такими. Ужас. В статье ясно и доходчиво даются азы и поясняется, почему на Линукс нельзя строит РТ решения. Вот и всё. Подобного материала очень мало.

Re: Re: Re: Re: Re: Re: Re: Re: Универсальный менеджер пакетов

Сорри, забыл про человеческий фактор. 🙂 вопрос снят 🙂

Источник

Какой дистрибутив лучше использовать для вашей embedded системы?

Какой дистрибутив лучше использовать для embedded систем. Этот вопрос является актуальным на сегодняшний день.

Существует три актуальных подхода для решения этой задачи:

1. Использовать готовый дистрибутив для вашего одноплатного компьютера(Armbian, Openwrt и т.д.)
2. Собрать и настроить свой дистрибутив с помощью систем сборок(Buildroot/Yocto и т.д.).
3. Использовать свою связку bootloader (u-boot) + ядро(kernel) + rootfs (busybox).

Если кто знает еще, напишите пожалуйста в комментариях.
UPDATE.
Проект OpenWRT это и система сборки (это не buildroot), так и проект предоставляющий готовые собранные образы для вашей целевой платы.

Готовые дистрибутивы

Я считаю использовать готовый дистрибутив это самый простой и легкий путь. Вы можете скачать готовый образ или сбилдить свой. Сборка своего образа Armbain не всегда является гибкой, т.к вы не можете выбрать любую версия ядра Linux, а использовать только предоставленные.

Следует также ответить главное достоинство готовых дистрибутивов — это их стабильность.
Для начинающих, я бы рекомендовал данные дистрибутивы.

Armbian — это популярный дистрибутив Linux, доступный для самых разных устройств ARM: Orange Pi, Banana Pi, Odroid и т.д … Он основан на Ubuntu и/или Debian.

OpenWrt — встроенная операционная система, основанная на ядре Linux, и предназначенная, в первую очередь, для домашних маршрутизаторов. Основные компоненты включают в себя ядро Linux, util-linux, uClibc или musl и BusyBox. Размер всех компонентов оптимизирован в связи с тем, что в большинстве домашних маршрутизаторов сильно ограничен объём памяти.

От себя добавлю, хорошо подойдет для плат с wi-fi на борту (Например Orange Pi Zero).

Системы сборки

Гланым достоинством систем сборок является, то что вы можете собрать минимальный и гибкий Linux для встраиваемых (embedded) систем.

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

Что оно позволяет собрать buildroot для вашей системы:

• образ системы;
• данная система позволяет выбрать версию ядра — любую.
• можете добавить любые патчи и установить любые программы.
• гибкая конфигурация утилит ( например, busyBox, bash и т.д.)

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

Отличая такой сборки, например, от сборки Armbian:

• собирается дистрибутив не на основе (Debian или Ubuntu), а пользовательский гибко настроенный Linux.
• минимального размер сборки.
• выбор любой версии ядра.

3. Использование свой связки:

Для этого нам нужен:

• Cross compiler (Например, Linaro);
• Bootloader (Например, U-boot);
• Kernel;
• RootFs (Например, Busybox).

Итак поехали.
Так мы будем собирать локально на своей машине нам нужен кросс компилятор, например linaro. Кросс компилятор поможет на архитектуре x86, собрать наш дистрибутив под целевую платформу ARM.

Далее необходимо собрать bootloader.

Bootloader (U-Boot) — самый популярный bootloader для ARM, является U-boot. Главной задачей bootloader является загрузка ядра Linux Kernel. Так же вы можете использовать, например barebox или другой.

RootFs — это корневая файловая система которую примонтирует Kernel после загрузки. Рекомендую использовать Busybox.

Источник

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, стоит сходить в репозиторий и найти тег последней версии, далее

U-Boot содержит больше тысячи конфигураций, в том числе нужную:

Это конфигурация платы AM335x evaluation module, этот модуль лежит в основе других плат, в том числе BeagleBone Black, что можно видеть, к примеру, по Device Tree, но о нем позже. Настраивается и собирается U-Boot с помощью Kconfig, то же, что используется и при сборке ядра Linux.

Установка нужного конфига:

Можно, к примеру, убрать, установленную по умолчанию, 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 требуемые архитектуру и путь к кросскомпилятору соответственно, например так

Либо использовать 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 не создает файлы с дополнительными командами, делать это нужно самостоятельно.

Здесь происходят некоторые манипуляции в результате которых 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)

Проходит некоторое время.

Результат сборки, в виде 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.

Скачивание последней, на тот момент, версии:

Настройка конфигурации по умолчанию:

Чтобы не думать сейчас о разделяемых библиотеках, стоит установить статическую сборку BusyBox:

Settings —> Build static binary (no shared libs)

Установка в папку по умолчанию _install:

Теперь в папке _install можно видеть будущую корневую файловую систему, в которую нужно добавить некоторые вещи.

Папки, помимо созданных BusyBox:

Стартовый скрипт. Дело в том, что, запускаемая в первую очередь, программа init, делает много полезного, например, выводит в консоль приглашение, но до выдачи приглашения, init проверяет наличие стартового скрипта /etc/init.d/rcS, и, при наличии, запускает его.

Этот скрипт монтирует псевдофайловые системы proc и sysfs, и ничего не мешает ему запускать, к примеру, пользовательскую программу, отвечающую за функционал устройства, но лучше будет делать это в отдельных скриптах, скомпонованных по функциональному назначению.

Стоит сказать, что работа init, на самом деле, начинается с чтения конфигурационного файла /etc/inittab, но BusyBox’овская init включает таблицу inittab по умолчанию, если таковой не окажется в корневой файловой системе.

Теперь пора вспомнить про модули ядра. Их также нужно разместить в корневой файловой системе в /lib/modules/5.4.92/, но сейчас они разбросаны по всей папке в которой собиралось ядро. Чтобы собрать модули в кучу, нужно в папке с ядром выполнить

Где в INSTALL_MOD_PATH указать путь к папке с корневой файловой системой, кросскомпилятор указывать не нужно, т.к. здесь модули ядра просто копируются по месту назначения. В результате папка /lib корневой файловой системы пополнится разделом /lib/mudules/5.4.92/ содержащим модули ядра, полученные при компиляции ядра.

Осталось скопировать все содержимое папки _install во второй раздел SD карты, тот который с ext4, и поменять владельца всего содержимого на root.

После запуска BeagleBone Black с корневой файловой системой, через 1.910315 секунды после старта ядра, система предложит активировать консоль и начать работу.

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

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

Источник