Linux для встраиваемых систем с чего начать
Создание с нуля дистрибутива Linux для встраиваемых устройств
В этом руководстве рассказывается о том, как собрать специализированный дистрибутив Linux® для использования во встраиваемых системах, в данном случае для работы одноплатного компьютера Technologic Systems TS-7800. Обсуждаются кросс-компиляция, загрузчик, файловые системы, корневая файловая система, образы дисков и процесс загрузки. Все это рассматривается через призму конкретных решений, принимаемых по мере построения системы и создания дистрибутива.
Re: Создание с нуля дистрибутива Linux для встраиваемых устройств
Re: Создание с нуля дистрибутива Linux для встраиваемых устройств
«В дистрибутивах ядра Linux есть некоторая поддержка для создания подходящих образов initrd, но подробная информация об этом конкретном образе не имеет решающего значения для понимания процесса сборки нашего дистрибутива.» (с) IBM EE/A
«Промптом» переводили? Или чем ещё?
Re: Создание с нуля дистрибутива Linux для встраиваемых устройств
> «Промптом» переводили? Или чем ещё?
Re: Создание с нуля дистрибутива Linux для встраиваемых устройств
Re: Создание с нуля дистрибутива Linux для встраиваемых устройств
> «В дистрибутивах ядра Linux есть некоторая поддержка для создания подходящих образов initrd, но подробная информация об этом конкретном образе не имеет решающего значения для понимания процесса сборки нашего дистрибутива.» (с) IBM EE/A
> «Промптом» переводили? Или чем ещё?
Предложение построено достаточно корректно, вряд ли промт смог бы так. Но вот всю глубину мысли мне постичь не удалось 🙂
Re: Создание с нуля дистрибутива Linux для встраиваемых устройств
Поддержки некоторой дистрибутивы образов initrd обладают, но Йода мастер подробной не владеет информацией для понимания процесса значения решающего имеющей. Силу используй энергии ментальной, медиахлорианами рожденной, понимания бреда для.
Re: Создание с нуля дистрибутива Linux для встраиваемых устройств
> В этом руководстве рассказывается о том, как собрать специализированный дистрибутив Linux® для использования во встраиваемых системах
А это так сложно что ли, что нужно об этом писать целую статью?
Re: Создание с нуля дистрибутива Linux для встраиваемых устройств
Re: Создание с нуля дистрибутива Linux для встраиваемых устройств
Re: Создание с нуля дистрибутива Linux для встраиваемых устройств
>А это так сложно что ли, что нужно об этом писать целую статью?
Несложно если проделать это успешно хотя бы раз. Для начинающих статья в самый раз, много разрозненной информации собрано воедино, по крайней мере объясняется в каком направлении копать если что-то непонятно.
Впрочем желающим потрындеть на тему статья конечно ненужна.
Re: Создание с нуля дистрибутива Linux для встраиваемых устройств
Чем способ сборки, что описан в статье, лучше чем применение OpenEmbedded?
Re: Создание с нуля дистрибутива Linux для встраиваемых устройств
ОМГ! А ведь он только недавно учил shell scripting! Во как быстро чувак растет!
Re: Создание с нуля дистрибутива Linux для встраиваемых устройств
imho, ничем не лучше. хоть и более наглядно, чем bitbake gpe-image 😉
Embedded Linux в двух словах. Первое
В этой небольшой серии статей я попытаюсь пролить свет на тему построения Embedded Linux устройств, начиная от сборки загрузчика и до написания драйвера под отдельно разработанный внешний модуль с автоматизацией всех промежуточных процессов.
Платформой послужит плата BeagleBone Black с процессором производства Техасских Инструментов AM3358 и ядром Arm Cortex-A8, и, чтобы не плодить мигающие светодиодами мануалы, основной задачей устройства будет отправка смайлов в топовый чат, широко известного в узких кругах, сайта, в соответствии с командами от смайл-пульта. Впрочем, без мигания светодиодами тоже не обошлось.
Топовые чаты, пульты и светодиоды будут позже, а сейчас на плату подается питание и плата отвечает 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
Перед скачиванием U-Boot, стоит сходить в репозиторий и найти тег последней версии, далее
U-Boot содержит больше тысячи конфигураций, в том числе нужную:
Это конфигурация платы AM335x evaluation module, этот модуль лежит в основе других плат, в том числе BeagleBone Black, что можно видеть, к примеру, по Device Tree, но о нем позже. Настраивается и собирается U-Boot с помощью Kconfig, то же, что используется и при сборке ядра Linux.
Установка нужного конфига:
Можно, к примеру, убрать, установленную по умолчанию, 2-х секундную задержку при загрузке платы с U-Boot
В вышеуказанных командах, используется компилятор по умолчанию, если таковой в системе установлен, и, скорее всего, он не подходит для ARM процессоров, и здесь пора упомянуть о кросскомпиляции.
ARM Toolchain
Один из видов кросскомпиляции это сборка на одной архитектуре, как правило x86-64, именуемой HOST, исходного кода для другой, именуемой TARGET. Например, для TARGET архитектуры ARMv7-A, ядра ARM CortexA-8 процессора AM3358, платы BeagleBone Black. К слову, чтобы не запутаться в ARM’ах, даже есть свой справочник, так их много и разных.
Теперь для успешной сборки U-Boot, нужно указать в переменных ARCH и CROSS_COMPILE требуемые архитектуру и путь к кросскомпилятору соответственно, например так
После сборки 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 не создает файлы с дополнительными командами, делать это нужно самостоятельно.
Ядро Linux
Прежде чем приступать к любым действиям с ядром, стоит заглянуть сюда и убедится в наличии необходимых пакетов. Следующим шагом нужно определиться с тем, какую версию ядра использовать. Здесь я использую версию 5.4.92 и вот по каким соображениям. Одной из основных причин того, что не стоит брать просто последнюю версию ядра, доступную на данный момент, наряду с наличием драйверов, является невозможность быстро протестировать это ядро на всем разнообразии платформ поддерживаемых Linux, а значит можно потратить кучу сил и времени на исправление неполадок, если что-то пойдет не так, и не факт что это вообще получится сделать. BeagleBone Black имеет официальный репозиторий, где можно найти версию ядра, протестированную на данной платформе, и long term версия 5.4.92 была последней на тот момент.
Сам конфиг пока остается без изменений, поэтому можно просто его установить и запустить компиляцию ядра(zImage), модулей(modules) и дерева устройств(dtbs)
Проходит некоторое время.
Результат сборки, в виде zImage, находится в /arch/arm/boot, там же в папке /dts находится скомпилированное дерево устройств am335x-boneblack.dtb, оба отправляются на SD карту к файлам загрузчика. На этом FAT раздел SD карты можно считать скомплектованным. Итого, там присутствуют:
Еще при сборке ядра заказывались модули ядра, но они уже относятся к корневой файловой системе.
Корневая файловая система. BusyBox
Ядро получает корневую файловую систему путем монтирования блочного устройства, заданного в, переданном при запуске ядра, аргументе root=, и далее, первым делом, исполняет оттуда программу под названием init.
Если запустить BeagleBone Black, имея только вышеуказанные файлы для FAT раздела, то ядро будет паниковать по причине отсутствия init и, в целом, по причине пустой rootfs, т.е. корневой файловой системы.
Можно шаг за шагом создать все минимально необходимые компоненты корневой файловой системы, такие как оболочка, различные демоны запускаемые init, сам init, конфигурационные файлы, узлы устройств, псевдофайловые системы /proc и /sys и просто системные приложения. Для желающих совершать подобные подвиги, существует проект Linux From Scratch, здесь же я воспользуюсь швейцарским ножом встроенных систем с Linux, утилитой BusyBox.
Скачивание последней, на тот момент, версии:
Настройка конфигурации по умолчанию:
Чтобы не думать сейчас о разделяемых библиотеках, стоит установить статическую сборку BusyBox:
Установка в папку по умолчанию _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 процессорами, построение системы может сильно отличаться. Например, на малинке, вообще сначала стартует графический процессор, который затем запускает все остальное.
По поводу же заявленных в начале драйверов, взаимодействия с внешними устройствами, автоматизации сборки и некоторого полезного функционала, пойдет рассказ в следующей статье.
Развёртывание встраиваемой системы на базе Windows и Linux
В процессе разработки устройств, имеющих графический человеко-машинный интерфейс, рано или поздно возникает задача не только создания самого интерфейса, но и выбора платформы, на базе которой он должен работать. В качестве такой платформы может быть либо одноплатный компьютер с операционной системой, либо микроконтроллер с экраном и набором соответствующих библиотек, либо какое-то иное оригинальное решение.
Часто бывает, что на верхнем уровне системы управления, на котором работает интерфейс, выполняются также задачи связи с внешним миром и взаимодействие с широким набором периферийных устройств. Более того, интерфейс сам по себе может быть довольно требователен к графическим ресурсам. Учитывая это и в целях экономии трудозатрат можно взять за основу именно одноплатный компьютер и установить на него готовую операционную систему. Разработка программ в этом случае может сильно упроститься за счет использования современных фреймворков с хорошей документацией и набором примеров.
Требования к интерфейсу
С точки зрения пользователя интерфейс должен удовлетворять следующим требованиям:
Другими словами, полное ограничение действий пользователя, устойчивость и масштабируемость.
Что касается операционной системы для одноплатного компьютера, то рассмотрим сразу два варианта, один на базе Windows, другой на базе Linux, и сравним их между собой.
Для примера создадим интерфейс киоска с сенсорным экраном. А в качестве приложения возьмем один из учебных примеров Qt Quick и реализуем его с некоторыми изменениями. Фреймворк Qt доступен для обоих операционных систем.
Чтобы не углубляться в нюансы установки Windows и Linux на ARM платформы, систему можно легко собрать на базе какого-нибудь x86-совместимого процессора. В данном случае для экспериментов была использована одна из множества доступных плат на платформе Intel Bay Trail.
Пакет всех программ и скриптов доступен на GitHub.
Путь Windows
В свое время для создания встраиваемых систем была представлена Windows Embedded от Microsoft. Еще в ранней версии Windows Embedded XP разработчикам предоставлялся набор инструментов для сборки максимально урезанных, но оснащенных нужными драйверами образов. Эти сборки требовали минимум оперативной памяти и прекрасно работали даже на слабых процессорах. Технология получила свое развитие в версии Windows Embedded Standard 7, где процесс создания собственных сборок был доведен до ума. В Windows Embedded применялась идеология открытого каталога модулей, и любой желающий мог оснастить свою систему только необходимым набором компонентов. Последняя версия, в которой был доступен такой подход, хотя уже в урезанном виде, это Windows Embedded Standard 8.1.
Современная Windows 10 IoT позиционируется как альтернатива Windows Embedded, но сильно отличается от своих предшественников. Открытый каталог компонентов более недоступен. Пропала возможность собирать лёгкие образы из конструктора и делать из них собственные установочные диски. Специальные опции именно встраиваемой системы, такие как фильтр записи, брендирование загрузчика, клавиатурный фильтр и прочее, теперь настраиваются уже в предварительно установленной системе. Причем, поддержка этих функций доступна только в составе тяжелой версий Windows 10 Enterprise.
Однако, несмотря на высокие системные требования, особенно к объему оперативной памяти, использование даже тяжёлых версий во встраиваемых решениях не вызывает особых проблем, в первую очередь за счет доступности аппаратных комплектующих. Тем более, не стоит забывать, что в последнее время становится сложнее купить лицензию на старые продукты от Microsoft.
Быстрое решение
При первом рассмотрении выясняется, что в даже в обычной Windows 10 есть уже встроенная функция «Assigned Access» (рис. 1), которая выглядит, как готовое решение поставленной задачи.
Рис. 1. Функция «Assigned Access»
Программа, которую можно использовать в этом случае в качестве интерфейса, должна быть изначально разработана как приложение Universal Windows Platform. Эти приложения в формате appx устанавливаются, например, на Windows Phone. Простое полноэкранное приложение, конечно, можно преобразовать в appx и подписать необходимыми сертификатами, а после этого установить. Оно может работать как интерфейс, но без должной защиты. К сожалению, в штатном режиме «Assigned access» для пользователя всё равно остается открытым доступ к некоторым системным настройкам и горячим клавишам. Получить в результате интерфейс, соответствующий всем изложенным выше требованиям, с помощью такого подхода не получится. Система должна быть настроена вручную, иным способом.
Правильное решение
1. Первичная установка
Итак, в первую очередь нам необходим дистрибутив Windows 10 Enterprise LTSB. Можно взять оригинальный образ Microsoft, можно какой-нибудь облегчённый или сделать свой, с помощью сторонних инструментов. Для экспериментальной платы была выбрана одна из готовых сборок (облегчённая 32-битная версия).
Устанавливаем систему из дистрибутива на целевую плату. При установке разбиваем диск на два раздела, C: — для системы, D: — для основного приложения, служебных программ и журналов. Такая разбивка пригодится в дальнейшем для фильтра записи. После установки дожидаемся появления меню настойки параметров, либо меню с настройками сети и дальше не продолжаем.
Перезагружаемся в служебный режим через Ctrl+Shift+F3.
Если в процессе установки не было ошибок, то после перезагрузки система сама зайдет в служебный аккаунт администратора и на экране появится окно SysPrep (рис. 2). Его надо закрыть, запускать SysPrep мы будем иначе, используя специальный файл ответов, который еще предстоит создать.
Рис. 2. Служебный режим.
2. Конфигурация системы
Для дальнейших действий понадобится Deployment Tools из комплекта Windows 10 Assessment and Deployment Kit.
Из диска с установленным на плату дистрибутивом Windows нужно извлечь файл образа install.wim. Бывает, что в некоторых сборках этот файл может храниться в сжатом виде с расширением esd. В этом случае его сначала нужно распаковать. Для этого используется утилита dism.
Выясним порядковый номер нужной версии внутри контейнера (SourceIndex).
Затем, извлечём файл образа (в данном случае, первый в контейнере).
Теперь нужно открыть образ в Windows System Image Manager (из комплекта Deployment Tools) и сгенерировать каталог.
Стоит отметить, что работать с образами в Windows System Image Manager можно только в том случае, если разрядность образа совпадает с разрядностью хоста. То есть, нельзя в 64-битной системе редактировать образ 32-битной версии. Тут, как говорится, без комментариев.
Когда каталог создан, отредактируем файл ответов для утилиты SysPrep. Введем данные о владельце, добавим нужных пользователей и настроим первый автологин (рис. 3).
Рис. 3. Создание файла ответов.
Все параметры перечислять смысла нет, с содержимым файла ответов можно ознакомится в репозитории. Главное, не забыть выставить параметры CopyProfile в true, SkipReam в 1 и включить автологин администратора. Свой ключ продукта можно вписать в разделе 4 specialize — Microsoft-Windows-Shell-Setup — ProductKey.
3. Установка программ
Далее понадобится собственно файл образа install.wim, поэтому его нужно положить рядом с файлом ответов customize.xml, в котором после сохранения нужно вручную заменить путь к образу. В конце файла строка должна выглядеть так:
Для получения демонстрационного интерфейса «KioskShell» нужно собрать версию для Windows из исходников. Советы по сборке есть в репозитории.
Копируем Файлы на плату и получаем следующую структуру файлов и каталогов:
4. Ручная настройка системы
Когда система находится в служебном режиме можно перезагружаться сколько угодно раз, система будет возвращаться в него автоматически. При длительном простое до настройки питания, однако, экран может заблокироваться и обратно уже будет не зайти, поможет только перезагрузка. Так как в каждом конкретном проекте могут быть свои особенности по настройке, ее лучше делать вручную, но можно воспользоваться и скриптами автоматизации.
Установим нужные компоненты встраиваемой системы и отключим контроль учетных записей (см. AfterSetup.bat из репозитория)
Установим все драйвера, настроим железо (IP сетевой карты, разрешение и ориентацию экрана, порты внешних устройств и прочее), отключим залипание клавиш и все специальные возможности.
Так как в будущем хотелось бы иметь возможность удаленного администрирования, включим доступ по RDP. Срок действия пароля администратора будет убран на этапе автоматической настройки.
Далее, нужно отключить обновление системы в Local Group Policy Editor (в разделе Computer Configuration — Administrative Templates — Windows Components — Windows Update нужно установить Configured Automatic Updates значение Disabled). Помимо этого, нужно ещё отключить автоматическое сканирование Центра обновления Windows (в планировщике заданий в разделе Microsoft — Windows — UpdateOrchestrator нужно отключить все задачи), иначе каждый раз при загрузке будет всплывать чёрное окно, а при подключении к Интернету Windows может внезапно начать обновляться.
Далее, настроим параметры питания. Для этого нужно сначала в разделе Advanced Power Settings сделать видимыми все настройки питания (для этого в реестре в каждом подразделе в HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Power\PowerSettings\238C9FA8-0AAD-41ED-83F4-97BE242C8F20 при наличии параметра Attributes нужно присвоить ему значение 2). Теперь, когда все настройки доступны, отключаем спящий режим, режим отсутствия, убираем действие по кнопке питания (если, конечно, не нужно иное) и отключаем таймер авторизации при простое. Далее, убираем режим ожидания с подключением (в разделе HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Power нужно присвоить параметру CsEnabled значение 0). При необходимости, выключаем адаптивную регулировку яркости экрана.
Когда все настройки системы выполнены, у нас есть последняя возможность внести какие либо правки, так как второй запуск скрипта AfterSetup.bat запустит механизм автоматической настройки с помощью SysPrep, остановить который будет нельзя. Систему ещё надо не забыть активировать (с вариантами активации корпоративных версий Windows предлагается ознакомиться самостоятельно). Ещё на этом этапе можно сделать резервную копию всего диска и зафиксировать предварительное состояние образа на случай каких-либо изменений в будущем.
По окончании работы SysPrep не перезагрузит, а выключит компьютер — на этом моменте можно создать уже рабочий образ, готовый для портирования на серию.
5. Финальная автоматическая настройка системы
После первой загрузки рабочего образа (см. FirstLogon.bat из репозитория) произойдёт настройка защищённого интерфейса, автологин будет перенастроен на учетную запись User и будут отключены сочетания клавиш, которыми можно сломать систему. Далее, будет настроен и активирован Unified Write Filter. В данном случае, фильтр настроен на защиту всех разделов, кроме папок Service и Logs, и использует своп размером 256 Мб. Система перезагрузится несколько раз и, если всё сделано правильно, то при очередной загрузке появится защищённый интерфейс, запущенный от имени учетной записи User.
Для обслуживания системы на месте есть возможность попасть на экран входа в систему и, например, зайти в учетную запись администратора. В Windows 10 для этого предусмотрен штатный способ, нужно 5 раз подряд нажать клавишу «Win».
Путь Linux
Единого стандартного способа создания встраиваемых систем с графическим интерфейсом на базе Linux не существует. Как не существует и единого общего дистрибутива, всё таки, это семейство систем, которое создано на совершенно иных принципах. Наиболее близким по тематике может показаться проект Yocto Linux. Однако в нем достаточно сложно собирать образы, насыщенные приложениями, драйверами и сторонними библиотеками. Для решения поставленной задачи проще взять готовый, хорошо поддерживаемый дистрибутив и настроить его вручную.
Простое решение
1. Первичная установка
Итак, в первую очередь нам необходим сам дистрибутив, например Debian. Можно взять и другой, можно сделать свой. Главное, чтобы в дистрибутиве не было системы автоматического обновления. Для экспериментальной платы был выбран Debian Linux 9 (64-битная версия, ядро 4.9).
Устанавливаем систему традиционным способом. При установке разбиваем диск на два раздела, sda1 — / для системы, sda2 — /var/log для системных и программных логов. Такая разбивка пригодится в дальнейшем для фильтра записи. Устанавливаем штатный графический интерфейс xfce и сервер ssh. Добавляем в процессе установки пользователя administrator и задаем пароль.
После установки первым делом из аккаунта root добавляем пользователя administrator в группу sudo.
Заходим в систему под логином administrator и добавляем нового пользователя user.
Для удобства можно убрать для него пароль совсем, так как доступ для этого аккаунта будет всё равно везде закрыт.
2. Конфигурация системы
Устанавливаем драйверы, пакеты прошивок, дополнительные программы по желанию.
Для возможности удаленного администрирования в будущем, при необходимости, можно установить и настроить сервер vnc. Однако, в данном случае в этом нет смысла, так как все задачи администрирования можно легко выполнить через консоль, а для этого достаточно только доступа по ssh.
В Linux есть возможность использовать разные оконные менеджеры для разных пользователей. Для работы интерфейса пользователя установим минималистский менеджер с возможностью тонкой настройки. А для конфигурации понадобится ещё несколько приложений.
С помощью arandr можно изменить разрешение и ориентацию экрана, если это необходимо, а затем сохранить конфигурацию как скрипт (рис. 4).
Рис. 4. Настройка экрана.
Далее необходимо один раз зайти в систему под учетной записью user, предварительно выбрав в качестве оконного менеджера установленный ранее fluxbox, а затем обратно выйти. Это нужно для того, чтобы fluxbox при первом запуске создал все файлы настроек и был выбран в качестве стандартного менеджера для аккаунта user (см. файл .dmrc в домашнем каталоге пользователя).
Теперь нужно настроить fluxbox на соответствие требованиям к интерфейсу, описанным выше. Для этого в /home/user/.fluxbox/init выключим панель session.screen0.toolbar.visible: false, в /home/user/.fluxbox/keys закомментируем все сочетания клавиш кроме кнопок громкости, а в /home/user/.fluxbox/startup добавим запуск скрипта настройки экрана, отключение энергосберегающих функций монитора и автозапуск полноэкранного приложения. Скрипт будет перезапускать приложение в случае неожиданного сбоя.
Выберем стиль анимации загрузки.
И окончательно зафиксируем все изменения.
3. Установка программ
Для получения демонстрационного интерфейса «KioskShell» нужно собрать версию для Linux из исходников. Советы по сборке есть в репозитории.
Копируем файлы на плату и получаем следующую структуру файлов и каталогов:
4. Финальная настройка системы
На этом этапе можно сделать резервную копию всего диска и зафиксировать предварительное состояние образа на случай каких-либо изменений в будущем.
Настроим автоматический вход в систему под учетной записью user, для этого в /etc/lightdm/lightdm.conf установим autologin-user=user.
Теперь установим защиту от записи.
При установке выбираем dynamic fake device map.
Отредактируем файл настроек /etc/bilibop/bilibop.conf. Активируем модуль параметром BILIBOP_LOCKFS=«true» и добавим раздел с логами в исключения BILIBOP_LOCKFS_WHITELIST=»/var/log». Разрешим возможность временного отключения защиты при необходимости BILIBOP_LOCKFS_POLICY=«soft». И так как в системе нет шифрования, нужно установить BILIBOP_LOCKFS_SWAP_POLICY=«soft».
Перезагружаем систему и, если всё сделано правильно, появится защищенный интерфейс, запущенный от имени учетной записи user.
Последний этап может быть легко автоматизирован для получения системы с автоматической настройкой при первом запуске. Это позволит создать дистрибутив для масштабирования на несколько устройств (данный механизм предлагается реализовать самостоятельно).
Для обслуживания системы на месте есть возможность попасть на экран входа в систему и зайти в учетную запись администратора. В Linux для этого нужно сначала попасть в консоль через Ctrl+Alt+F1. После входа в аккаунт администратора принудительно вывести пользователя user из системы.
Затем вернуться в графический режим через Ctrl+Alt+F7 и ещё раз зайти под администратором.
Выводы
Независимо от того, какой из путей был выбран, в конечном итоге получится один и тот же результат. При правильной настройке пользовательский интерфейс будет соответствовать всем требованиям, описанным выше. Возможны лишь визуальные различия, связанные, как правило, с особенностями отрисовки графических элементов с использованием аппаратного ускорения на разных платформах.
Рис. 5. Интерфейс в рабочем режиме.
Так как основой системы является одноплатный компьютер, не составит проблем установить любой сенсорный экран или другие органы управления. При наличии соответствующего приложения, на данной базе можно создать не только консоль управления прибора или интерактивную панель мониторинга, но так же и другие устройства, например, информационные или торговые терминалы.
Проблема выбора
Существует мнение, что Linux очень сложен в настройке и обслуживании, но при этом бесплатен, а Windows проста и удобна, но при этом стоит денег. Это, пожалуй, верно, но только на бытовом уровне. Когда дело касается создания встраиваемых систем стоит принимать во внимание иные обстоятельства. Например, тонкая настройка Windows, особенно в части управления питанием и другими низкоуровневыми элементами, уже не кажется простой и удобной. Причем, не стоит забывать, что Windows 10 довольно требовательна к ресурсам. В данном примере удалось измерить несколько раз потребление памяти чистой системы, и оно составляло около 400 Мб в состоянии простоя. Для сравнения, Linux Debian со всеми дополнениями занимал в памяти около 200 Мб. Конечно, при наличии нескольких гигабайт оперативной памяти это не проблема, но всё же, при использовании Windows и высоконагруженных клиентских приложений приходится брать более мощные одноплатные компьютеры. Linux менее требователен к ресурсам, но действительно сложен в настройке и требует аккуратного подхода, особенно при работе с загрузчиком. Более того, при разработке и внедрении в систему некоторых элементов иногда бывает необходима сборка собственного ядра с особыми параметрами. Это эффективно, но требует соответствующего уровня квалификации.
В рамках создания защищенного интерфейса однозначный выбор сделать сложно. Трудоемкость развёртывания систем оказывается примерно одинаковой. Затраты на приобретение лицензий на Windows для серии приборов могут сравняться с затратами на обслуживание систем на Linux. Какую систему выбрать, решать вам.
Различные человеко-машинные интерфейсы, созданные на базе описанных примеров, были внедрены автором в электронные приборы для самых разных применений и доказали свою работоспособность в реальном мире.