• Embox — операционная система реального времени, ориентированная на применение во встроенных системах.

• Embox — кросс-платформенная ОС. Архитектурно-зависимые части вынесены в отдельные модули, что упрощает процесс портирования на новые платформы. Embox поддерживает следующие процессорные архитектуры: x86, ARM, MIPS, SPARC, PPC, Microblaze, E2k.

• Embox является многозадачной ОС и поддерживает различные уровни приоритета задач, вытесняющую многозадачность, защиту от инверсии приоритета и различные способы синхронизации.

• Embox предоставляет слой POSIX-совместимости, который позволяет использовать большое количество готового ПО разработанного под Linux. Примерами являются библиотека Qt, клиент и сервер SSH — Dropbear, проект по созданию SIP-телефонов на основе популярной библиотеки PJSIP.

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

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

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

• Embox хорошо подходит для устройств интернета вещей (IoT). Поскольку имеет развитый сетевой стек и богатый набор прикладных приложений и библиотек, но вместе с тем имеет низкие требования к аппаратным ресурсам.

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

Ознакомление с Embox лучше начать с запуска на эмуляторе qemu поддерживающего различные процессорные архитектуры.

Клонируем мастер:

    $ git clone https://github.com/embox/embox

Либо скачиваем архивом из https://github.com/embox/embox/releases

Все описания сделаны для Linux. Для сборки и работы под Windows и MacOS лучше использовать Docker в котором уже настроено все необходимое окружение для начальной работы. Для этого:

• Установите docker для вашей ОС.
• Убедитесь, что docker установлен правильно с помощью команд:

        $ docker-machine ls
        $ docker-machine start default

• Перейдите в консоли в корневую папку с исходниками Embox.
• Запустите докер выполнив скрипт

        $ ./scripts/docker/docker_start.sh

• Для упрощения работы выполните скрипт командой

        $. ./scripts/docker/docker_rc.sh

Данный скрипт позволит писать команду dr вместо docker run

Далее перед каждой командой необходимо вставлять dr. Например,

    $ dr make confload-x86/qemu
    $ dr make
    $ dr ./scripts/qemu/auto_qemu

Для конфигурации сборки и запуска базового темплейта.

После установки и проверки работоспособности, можно пропустить раздел настройка окружения и перейти сразу к разделу “Сборка и запуск на QEMU”

Необходимые пакеты: make, gcc (кросс-компилятор под выбранную архитектуру, см. “Установка кросс-компилятора”). Дополнительные пакеты (рекомендуется установить сразу): build-essential gcc-multilib curl libmpc-dev python Пример установки для Debian:

    $ sudo apt-get install make gcc \
        build-essential gcc-multilib \
        curl libmpc-dev python

Пример установка для Arch:

    $ sudo pacman -S make gcc-multilib cpio qemu

     $ sudo apt-get install gcc

Обычно уже установленный пакет. Вам потребуется другой компилятор, если Вы настраиваете окружение самостоятельно для Windows или MacOS.

     $ sudo apt install arm-none-eabi-gcc

Или для Debian

    $ sudo apt install gcc-arm-none-eabi

Либо скачать архив с тулчейном с сайта https://launchpad.net/gcc-arm-embedded. Распаковать архив и сделать export тулчейна:

   $ export PATH=$PATH:<путь к тулчейну>/gcc-arm-none-eabi-<version>/bin

Для этих архитектур можно воспользоваться нашим проектом по сборке crosstool https://github.com/embox/crosstool.

Можно скачать последнюю версию уже собранного архива в требуемым кросс-компилятором отсюда https://github.com/embox/crosstool/releases.

Или собрать его выкачав скрипты из репозитория с помощью команды

    $ ./crosstool.sh ARCH

После этого должен появиться архив с тулчейном — ARCH-elf-toolchain.tar.bz2. Далее, его нужно распаковать и добавить в переменную окружения PATH как показано выше для ARM.

Поддерживаемые архитектуры: x86, ARM, MIPS, Sparc, PPC, Microblaze.

Необходимые пакеты: qemu (под выбранную архитектуру)

    $ sudo apt-get install qemu-system-<ARCH> 

где это i386, arm, sparc, mips, ppc или misc (для microblaze) Примечание: Все пакеты qemu можно установить единым пакетом —

    $ sudo apt-get install qemu-system

Загружаем конфигурацию по умолчанию для выбранной архитектуры:

   $ make confload-<ARCH>/qemu

, где : x86, arm, mips, ppc, sparc, microblaze. Пример под x86:

    $ make confload-x86/qemu

Собираем Embox:

    $ make

или запускаем параллельную сборку:

    $ make (-jN)

Пример:

    $ make -j4

Запускаем:

    $ ./scripts/qemu/auto_qemu

Пример вывода в консоль:

Embox kernel start
    unit: initializing embox.kernel.task.task_resource: done
    unit: initializing embox.mem.vmem_alloc: done
    ...

Если все unit тесты прошли успешно и система загружена, появиться консоль в которой можно выполнять команды. Начать можно с команды 'help' которая выведет список доступных команд для вашей конфигурации. Для выхода из эмулятора qemu нажмите последовательно ctrl+’A’ затем ‘x’.

Embox - модульная и конфигурируемая система. Для этих целей был разработан декларативный язык описания Mybuild. Он позволяет описывать как отдельные единицы системы (модули) так и всю систему в целом.

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

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

Текущая конфигурация располагается в папке conf/. Может быть выбрана с помощью команды

    $ make confload-<CONF_NAME>

Например, для задания демонстрационной конфигурации для запуска на qemu-system-arm необходимо выполнить

    $ make confload-arm/qemu

Для просмотра готовых конфигураций можно выполнить

    $ make confload

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

    include <PACKAGE_NAME><MODULE_NAME>

Пример, для добавления в конфигурацию команды 'help' нужно добавить строчку

    include embox.cmd.help

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

Разберем простейшее приложение “hello world”.

• Создадим папку hello_world в src/cmds:

    $ mkdir src/cmds/hello_world

• Создадим файл с исходным кодом приложения src/cmds/hello_world/hello_world.c со следующим содержанием:

        #include <stdio.h>

        int main(int argc, char **argv) {
            printf("Hello, world!\n");
        }

• Создадим файл описания модуля src/cmds/hello_world/Mybuild следующего содержания:

        package embox.cmd

        @AutoCmd
        @Cmd(name = "hello_world", help=”First Embox application”)
        module hello_world {
            source "hello_world.c"
        }

• Добавим в файл конфигурации системы conf/mods.conf строчку с подключением нового модуля:

        include embox.cmd.hello_world

• Компилируем:

        $ make

• Запускаем:

        $ ./scripts/qemu/auto_qemu

В появившейся консоли убедимся, что если набрать команду 'help' то в списке будет новая команда. Выполним команду набрав ее в консоли hello_world Должно появиться наше сообщение выведенное с помощью функции printf() :

        root@embox:/#hello_world 
        Hello, world!
        root@embox:/#

Разберем немного подробнее файл описания модуля.

        package embox.cmd

        @AutoCmd
        @Cmd(name = "hello_world", help=”First Embox application”)
        module hello_world {
            source "hello_world.c"
        }

В первой строке идет указание имени пакета package embox.cmd. В Embox все модули распределены по пакетам, для удобства именования. Полное имя модуля будет состоять из имени пакета и имени модуля. Имя модуля в нашем случае находиться в строке module hello_world.

Строка source "hello_world.c" указывает файлы с исходным кодом необходимые для корректной сборки модуля.

В строке @Cmd(name = "hello_world", help=”First Embox application”) задается атрибут для модуля. Во первых модуль будет представлять из себя приложение, во вторых задает имя с помощью которого это приложение можно вызвать. И наконец, задается строка, которая будет отображаться для этого приложения при вызове команды 'help'. Строка @AutoCmd указывает, что в приложении есть стандартная функция входа в приложение main(), которая будет заменена на другой символ в процессе сборки.

Mybuild - это система автоматизации сборки и конфигурирования для модульных приложений.

Mybuild реализован поверх GNU Make, тем самым поддерживая все возможности инкрементальной и параллельной сборки последнего. Кроме того, это позволяет встроить Mybuild в уже существующую инфраструктуру сборки, использующую Make. В то же время, несмотря на использование Make, Mybuild использует собственный синтаксис, лишенный недостатков языка Makefile'ов.

Типичный сценарий разработки проекта, использующего Mybuild, включает две группы людей:

В действительности, есть еще разработчики самого Mybuild, но их мы пока что не рассматриваем. Таким образом, существует два типа файлов для сборки: My-файлы и Config-файлы

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

module HelloWorld {
   source "hello.c"
}

My-файлы именуются Mybuild либо *.my.

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

configuration Main {
    include HelloWorld
}

Конфигурационные файлы имеют расширение .config.

Оба типа файлов являются обычными текстовыми файлами (не XML!), которые можно редактировать в любом текстовом редакторе.

После того как необходимые my- и config-файлы готовы, проект можно собрать командой make. На основе предоставленных сборочных файлов Mybuild решит, что именно и в каком порядке необходимо собрать.

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

Процесс сборки с помощью системы Mybuild можно представить следующим образом:

Mybuild написана на расширении языка Make, поэтому, сначала требуется преобразовать код написанный на расширении языка Make в классические Make-файлы. Для ускорения этой процедуры используется кэширование: преобразуются только измененные с предыдущего запуска файлы.

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

Обработка Mybuild файлов (файлов описание модулей) разбивается на фазы:

• Нахождение Myfile в дереве с исходным кодом.
• Для каждого файла:
  • Чтение файла.
  • Синтаксический разбор, создание объекта (mk/mybuild/myfile-model.mk) на каждую разобранную синтаксическую конструкцию.
  • Сохранение полученной после разбора модели файла для использования последующими стадиями (путь по умолчанию: mk/.cache/mybuild/files/).
• Создание набора моделей, представляющего полное описание графа модулей, разрешение ссылок между моделями в наборе.
• Проведение различных проверок, относящихся к графу модулей (соответствие типов опций и инициализирующих их значений, циклическое наследование, и т.д)
• Кэширование полученного набора моделей.

Для описания модели системы так же используется специализированный язык описания. Поэтому, для обработки файлов конфигурации проводятся фазы, аналогичные фазам 1-5 обработки файлов описания модулей. Затем, происходит создание Build-модели (mk/mybuild/build-model.mk), в нее входит модули, их файлы, опции модулей, опции компиляции. Для этого используются модели конфигурации и Mybuild.

На этом этапе проводится сборка полученной на предыдущем этапе Build-модели.

• Генерируется исходник на языке Си, содержащий run-time представление Build-модели.
• Для модулей генерируются заголовочные файлы с опциями и экспортированными из модуля заголовочными файлами.
• Для файлов с исходным кодом генерируются командные файлы, содержащие параметры командной строки компилятора.
• Генерируется Make-правила для сборки целевого образа и промежуточных объектных файлов.

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

Система сборки целиком написана на языке GNU Make и состоит из набора скриптов. Следует различать три основных типа Makefile’ов, используемых для реализации:

• Классические Makefile’ы, в которых задаются правила для выполнения тех или иных целей, их зависимости и т.д. В основном к ним относятся скрипты верхнего уровня, определяющие последовательность запуска остальных скриптов.
• Библиотеки функций, в которых определяются функции и классы. Большая часть логики Mybuild реализована именно в таких скриптах. Основная часть кода (за исключением сравнительно небольшого блока раскрутки), написана с использованием расширенного синтаксиса языка Make.
• Скрипты, результатом выполнения которых является текстовый файл.

Для выполнения любой внешней цели (которую вызывает пользователь) сперва читается корневой Makefile. Его можно рассматривать как обертку для запуска самой системы сборки. В этом скрипте происходит проверка версии Make и необходимых флагов, задаются значения по умолчанию для директорий сборки и т.д. Далее управление передается в mk/main.mk. mk/main.mk

Этот скрипт - фасад системы. В нем определяются все доступные для выполнения цели, а также документация для этих целей, которую можно увидеть, выполнив “make help” или “make help-'<'goal'>'”. Можно различать два вида целей: Цели, которые можно выполнить “на месте” (загрузка конфигурации, clean, вывод справки по целям и т.п.). Цели, для выполнения которых требуется чтение всех my-файлов и построения модели сборки (собственно, сборка проекта). В этом случае управление передается специальному загрузочному скрипту mk/load.mk mk/load.mk

Скрипт используется для раскрутки остальных скриптов системы сборки, загрузки my-файлов и создания модели сборки. Разделен на два файла:

• load-mk.inc.mk, который занимается раскруткой скриптов (библиотеки функций),
• load-mybuild.inc.mk, который вызывает скрипты для разбора my-файлов, их линковки, сериализации и построения модели сборки.

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

Структурно модули организованы в иерархические группы (пространства имен), составленные по функциональной принадлежности. Данный механизм позволяет избежать коллизий в именах модулей, сохраняя их короткими. Как правило, имя пакета совпадает в путем в файловой системе, что облегчает поиск файлов модуля в дереве исходного кода.

Пример задания имени пакета:

package embox.arch

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

Пример задания абстрактного модуля:

package embox.arch

//...

abstract module interrupt { }
//...

Для указания наследования используется ключевое слово extends.

Пример наследования от абстрактного модуля:

    module interrupt_stub extends embox.arch.interrupt {
    //...
    }

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

Каждый модуль может указывать список файлов, которые необходимо скомпилировать и включить в итоговый образ в случае включения данного модуля в сборку. Список файлов указывается в атрибуте source модуля. Помимо “обычных” файлов на языке Си или ассемблера, можно также добавлять заголовочные файлы и дополнительные линкер-скрипты. Тип файлов различается по расширению:

• .c/.S - исходные коды на языке Си или ассемблера. При сборке компилируются и включаются в итоговый образ системы. Во время компиляции есть возможность получить значения опций модуля, к которому относятся эти файлы исходного кода.
• .h - заголовочные файлы, содержащие объявления и определения, необходимые для реализации модулем какого-либо интерфейса. При сборке для каждого включенного модуля генерируется специальный заголовочный файл, включающий все перечисленные .h-файлы данного модуля, а также модулей, расширяющих данный. Это позволяет использовать различные реализации того или иного интерфейса без изменения исходного кода модулей, которые его используют. Такой способ абстракции необходим, поскольку различные реализации могут определять ту или иную структуру по разному, в то время как структура может использоваться другими модулями без знания деталей реализации. То же самое относится и к макросам, inline-функциям и константам.
• .lds.S - линкер-скрипты, позволяющие влиять на процесс компоновки модулей в итоговый образ. Типичное использование таких скриптов - это добавление новых секций.

Пример задания заголовочного файла с реализацией абстрактного модуля:

    module interrupt_stub extends embox.arch.interrupt {
        source "interrupt_stub.h"
}

Пример задания файла с линкер скриптом и файла с исходным кодом:

    module static_heap extends heap_place {
        // ...
        source "heap.lds.S"
        source "static_heap.c"
        // ...
    }

Опции позволяют определить на этапе конфигурирования числовые, логические или строковые параметры, которые могут влиять способ сборки, инициализацию или работу модуля. Опции также могут иметь или не иметь значение по умолчанию. В последнем случае значение должно быть указано во время конфигурирования, в первом - это не обязательно, тогда будет использоваться значение по умолчанию. Опции разделяются на три типа в зависимости от типа задаваемого значения. Тип опции задается после ключевого слова option перед именем опции:

• string - строковые опции
• number - целочисленные данные
• boolean - булевое значение - true или false

Чтобы получить значение опции при компиляции исходного кода используются специальные макросы:

• OPTION_STRING_GET - для получения значения строковых опций
• OPTION_NUMBER_GET - для числовых опций
• OPTION_BOOLEAN_GET - для булевых опций

Аргументом макроса выступает имя опции, определенное в my-файле.

Зависимости являются способом указать системе сборки, что корректное функционирование данного модуля невозможно без некоторых других модулей. Список зависимостей может включать интерфейсы, при этом это означает, что в сборку должен быть включен ровно один модуль, реализующий требуемый интерфейс. Межмодульные зависимости указываются через атрибут depends. В значении атрибута можно перечислять как модули, так и интерфейсы. Система сборки гарантирует, что при включении данного модуля, будут добавлены и все его зависимости. В случае зависимости от интерфейса используется одна из его реализаций. Знание о межмодульных зависимостях используется как для получения списка модулей для сборки, так и в момент загрузки системы (см. далее). В некоторых случаях требуется просто включить нужный модуль вместе с данным, без изменения порядка загрузки, например, для использования таких глобальных модулей (аспектов), как поддержка многопроцессорности, логгирование или отладочные утверждения (assert). Поскольку у таких модулей нет как такового состояния (загружен или не загружен), для указания их в качестве зависимости атрибут depends дополняется аннотацией @NoRuntime. В этом случае зависимость будет использоваться во время сборки, но не будет определять порядок загрузки модулей относительно друг друга.

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

Пример задания с помощью аннотации реализации абстрактного модуля по умолчанию:

    @DefaultImpl(embox.arch.generic.interrupt_stub)
    abstract module interrupt { }

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

Конфигурация образа происходит редактированием файлов конфигурации в каталоге conf/. Его содержимое следующее:

• lds.conf - Файл lds.conf содержит определение карты памяти, использующейся на конкретной аппаратной платформе.
• mods.config - Файл mods.config содержит названия и опции модулей, которые будут включены в образ ОС. Также, для каждого из перечисленного в этом файле модуля возможно указать новые значения опций.
• rootfs/ - Директория rootfs содержит файлы, которые будут включены в состав файловой системы, которая будет доступна на ранних этапах загрузки.

Использование модуля в образе ОС подразумевает его включение в конфигурацию ОС.

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

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

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

make confload-x86/qemu

Эта команда загружает в каталог conf подготовленную базовую конфигурацию под названием qemu для платформы x86. Список всех базовых конфигураций можно увидеть и выбрать среди них, набрав:

make confload

Список модулей для включения в конфигурацию находится в файле conf/mods.config, который имеет следующую структуру:

package genconfig

configuration conf {
    [список_модулей]
}

[список_модулей] определяет положение набора строк, каждая из которых определяет включение модуля. Добавьте новую строку к списку модулей следющего содержания:

    include pkg.new_package.empty

В итоге, файл conf/mods.config должен иметь следующее содержание:

package genconfig

configuration conf {
    [список_модулей]
include pkg.new_package.empty
}

После этого, модуль empty из пакета pkg.new_package будет включен сборку. Чтобы проверить непротиворечивость полученной сборки и, в случае успеха, произвести создание образа ОС, наберите

    make

В случае положительного результата будет выведено сообщение “Build complete”. Убедиться в том, что ОС содержит новый модуль можно запустив ОС на исполнение и выполнить команду lsmod c параметрами -n и empty, которая выведет список модулей, у которых в имени модуля присутствует подстрока “empty”.

lsmod -n empty

Результатом lsmod будет являться печать

    *  pkg.new_package.empty

Это означает, что модуль pkg.new_package.empty имеется в системе, а символ “*” обозначает, что в данный момент модуль загружен и работает.

Описание конфигурация представляет собой детальное задание требований к функциональности системы. Подробнее смотри раздел "Модульная структура Embox". Текущая конфигурация содержится в файлах расположенных папке 'conf/'.

Для задания желаемых свойств целевой системы необходимо создать описание в папке 'conf/'. Если существует описание конфигурации с близкими свойствами проще воспользоваться ими. И на основе уже существующей конфигурации создать свою.

Посмотреть существующие конфигурации можно с помощью команды:

    $ make confload

затем можно сделать выбранную конфигурацию рабочей с помощью команды:

    $ make confload-<template>

Пример:

    $ make confload
    List of available templates:
      ...
      platform/quake3/qemu
      ...
    Use 'make confload-<template>' to load one.

    $ make confload-platform/quake3/qemu

в нем выбирается имеющаяся в списке конфигурация platform/quake3/qemu

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

    $ make

для сборки образа. В случае успешного завершения появится надпись "Build complete", а также файл образа в формате ELF 'build/base/bin/embox'.

Например:

    text	   data	    bss	    dec	    hex	filename
    1259425	 248540	170593504	172101469	a420f5d	build/base/bin/embox
    Build complete

После выбора конфигурации ее требуется изменить. Текущая (рабочая) конфигурация находиться в папке conf/. Изменения файлов в этой папке изменяют характеристики конечной системы до желаемых. Важно: если сделать make confload-