Рисунок 1. Образ ОС, с которым работает начальный загрузчик
Общая информация о создании полнофункциональных встраиваемых систем
Введение в построение встраиваемых систем:
В этой главе описывается общий процесс создания полнофункциональной встраиваемой системы под управлением ЗОСРВ «Нейтрино» c указанием ссылок на главы, которые посвящены его конкретным этапам.
Сначала мы рассмотрим процесс запуска ЗОСРВ «Нейтрино», затем — компоненты и принципы их работы, а в конце кратко познакомимся с процедурой их модификации.
С точки зрения программного обеспечения процесс запуска системы выглядит следующим образом:
После того, как мы подробнее познакомимся с аспектами работы программного обеспечения, мы рассмотрим роль оборудования в процессе запуска системы.
Первой задачей программного обеспечения является загрузка образа операционной системы. Ее выполняет программа, которая называется начальным загрузчиком (Initial Program Loader, IPL).
IPL осуществляет необходимый минимум действий по настройке оборудования и создает среду, в которой выполняется сначала модуль startup-*, а затем микроядро ЗОСРВ «Нейтрино»:
Начальный загрузчик IPL подробно описан в главе Руководство по разработке начального загрузчика (IPL).
Существуют два типа IPL, один из которых предназначен для горячего запуска системы, а другой ― для холодного. IPL горячего запуска обычно вызывается ROM-монитором или BIOS после первичной настройки оборудования и процессора, а IPL холодного запуска — непосредственно после сброса, когда процессор и оборудование системы еще не настроены. Таким образом, IPL горячего запуска выполняет часть работы начального загрузчика холодного запуска.
Мы начнем рассматривать функции IPL с конца: сначала опишем состояние, в которое система должна перейти перед запуском первого компонента образа, а затем познакомимся с процессом его достижения.
Содержание этого процесса в значительной степени зависит от особенностей целевой системы. Если вы работаете со стандартной платформой с ROM-монитором или BIOS, в которой все нижеперечисленные этапы уже выполнены при горячей загрузке с диска или по сети, никакие дополнительные действия не требуются. В нестандартной встраиваемой системе, где отсутствует микропрограмма, а образ хранится на специальном устройстве, IPL выполняет значительный объем работы.
Конечное состояние системы (которое предшествует запуску первого компонента образа) должно соответствовать следующим условиям:
Передача образа в линейно адресуемую память осуществляется IPL, ROM-монитором или BIOS. Чтобы IPL или ROM-монитор мог определить, в какой области памяти разместить образ и по какому адресу передать управление по окончании его загрузки, необходимо собирать образ ОС в подходящем формате.
Например, в IBM PC BIOS обычно загружает образ в необработанном двоичном виде и передает управление по его начальному адресу. Некоторые системы работают с образами в формате ELF и считывают место размещения и начальный адрес образа из его заголовка. Сведения о форматах образа, которые поддерживаются IPL, см. в сопроводительной документации целевой системы.
После того, как IPL обнаруживает образ и целиком размещает его в линейно адресуемой памяти, управление передается модулю startup-*. На этом IPL завершает работу и больше не используется.
На втором этапе программное обеспечение настраивает процессор и аппаратные компоненты, обнаруживает имеющиеся ресурсы и запускает операционную систему. Эти задачи выполняются модулем startup-* (подробнее см. в главе Руководство по разработке модуля startup).
IPL осуществляет минимально необходимую настройку системы и подготавливает ее к выполнению модуля startup-*, который завершает процесс настройки. Если IPL осуществляет поиск системных ресурсов, он передает информацию о них модулю startup-*, чтобы он не выполнял их поиск повторно.
С помощью модуля startup-* можно гибко настраивать ЗОСРВ «Нейтрино»: программировать базовые таймеры, контроллеры прерываний, кеш-памяти и др. В модуль startup-* также можно включать callout-ы ядра — фрагменты кода, которые вызываются ядром для выполнения специфических аппаратных функций. Например, при генерации прерывания устройством один фрагмент кода должен обнаруживать источник прерывания, а другой — очищать его.
Следует иметь в виду, что модуль startup-* не настраивает скорость передачи последовательных портов и другие аналогичные параметры, а также не инициализирует стандартные периферийные устройства, такие как контроллеры Ethernet и EIDE; эти действия выполняют драйверы, которые запускаются позже.
По окончании инициализации системы и размещения информации о ней на системной странице (особой области памяти, с которой впоследствии работает ядро), код запуска передает управление ядру ЗОСРВ «Нейтрино» и менеджеру процессов, которые завершают этап загрузки.
Рассмотрим функции и процесс выполнения кода запуска:
Код запуска копирует образ в целевую область ОЗУ, если он не был помещен в нее ранее. Если образ сжат, код запуска автоматически распаковывает его. Сжимать файл образа не обязательно; если он не сжат, код запуска не пытается распаковывать его.
Основная задача кода запуска на этом этапе — выполнить минимально необходимую настройку для определения конфигурации системы (а затем настраивать систему).
Конкретное содержание процедуры настройки зависит от особенностей оборудования.
В зависимости от особенностей встраиваемой системы ее конфигурация может динамически определяться при запуске либо быть строго фиксированной.
В любом случае код запуска должен сохранять настройки системы в четко определенных структурах данных, которые считываются операционной системой после ее запуска. В совокупности они называются системной страницей и содержат следующую информацию:
Для обеспечения максимальной переносимости ядра ЗОСРВ «Нейтрино» между процессорами и их различными конфигурациями код запуска должен включать в себя ряд callout-ов ядра. Необходимость писать программный код всех callout-ов отсутствует, поскольку многие из них реализованы в библиотеке, которая входит в состав ЗОСРВ «Нейтрино».
callout-ы ядра ЗОСРВ «Нейтрино» делятся на следующие классы:
callout-ы подробно описаны в главе Руководство по разработке модуля startup.
Последнее действие, которое выполняет код запуска — передача управления операционной системе.
Написание кода запуска — трудоемкая задача, однако мы предоставляем исходный код типовых модулей startup-* и библиотеку libstartup, в которой реализованы многие из вышеупомянутых функций.
Если вы работаете с одной из многочисленных платформ, которые поддерживаются ЗОСРВ «Нейтрино», вам не нужно прилагать усилия к решению перечисленных задач — мы уже сделали для вас всю необходимую работу.
Чтобы узнать, какие процессоры и платы поддерживаются на текущий момент, обратитесь к следующим источникам:
boards каталога BSP/src/hardware/startup/. Чтобы реализовать необходимые функции в нестандартной встраиваемой системе, можно найти исходный код для максимально схожей с ней системы и «клонировать» примеры, которые содержатся в нем.
Этот вопрос подробно рассматривается в главе Руководство по разработке модуля startup.
На третьем этапе запускаются все необходимые программы. Операционная система считывает и обрабатывает сценарий запуска (startup script) — последовательность команд, которая хранится в загрузочном образе. Формат startup script и файл построения загрузочного образа, в состав которого он входит, подробно описан в нескольких статьях настоящего руководства:
Операционная система обрабатывает startup script, который напоминает сценарий командного интерпретатора. В нем указывается список запускаемых программ с командно-строковыми параметрами и другая информация.
С точки зрения оборудования система включает в себя следующие компоненты:
ЗОСРВ «Нейтрино» поддерживает многие семейства процессоров (см. Системные требования и лимиты :: Ограничения, связанные с платформой), включая:
В общем случае процесс запуска системы слабо зависит от выбранного процессора и его архитектуры.
После запуска или перезапуска системы процессор должен иметь возможность выполнять команды. Эти команды хранятся в постоянном запоминающем устройстве, на которое указывает вектор сброса процессора. В качестве поставщика IPL могут выступать:
Как правило, чем меньше объем работы, тем легче разработать встраиваемую систему. Стандартные поддерживаемые аппаратные платформы почти полностью готовы к запуску, и вы можете концентрировать усилия на разработке целевых программ.
Если вы используете BIOS или ROM-монитор сторонней компании, вам необходимо написать программу, которая запускает операционную систему. Фактически вы выполняете «горячий запуск» системы (см. далее в этой статье), поскольку ее компоненты уже настроены и инициализированы.
При написании собственного IPL вы выполняете «холодный запуск» системы (см. далее в этой статье) и все действия по инициализации и настройке ее аппаратуры.
После выбора способа загрузки встраиваемой системы необходимо определить конфигурацию ее запоминающих устройств:
Если после запуска в системе не используются дополнительные запоминающие устройства для доступа к файлам, нет необходимости выбирать файловые системы.
Если системе требуется только считывать файлы, ЗОСРВ «Нейтрино» обеспечивает все необходимые функции. Чтобы считывать и запускать файлы, достаточно поместить их непосредственно в образ, поскольку операционная система имеет доступ к его содержимому (см. Создание загрузочного образа).
ЗОСРВ «Нейтрино» позволяет записывать временные файлы, журналы и другую информацию, которую не требуется сохранять при перезагрузке системы, на диск в ОЗУ без написания дополнительного кода и использования драйверов. Диск в ОЗУ обслуживается менеджером процессов, и пользователю достаточно создать ссылку на него с помощью команды ln.
Например, чтобы смонтировать каталог /tmp в качестве диска в ОЗУ, следует ввести команду:
ln -Ps /dev/shmem /tmp
или поместить в файл построения загрузочного образа (который рассматривается в следующих статьях настоящего руководства) команду:
[type=link] /tmp=/dev/shmem
Эти команды указывают менеджеру процессов принимать запросы ко всем файлам, которые находятся в каталоге /tmp, и перенаправлять их подсистеме общей памяти. Например, путь /tmp/AAA4533.tmp соответствует файлу /dev/shmem/AAA4533.tmp.
 | Для минимизации объема кода файловой системы в ОЗУ менеджер процессов не поддерживает функции «больших» файловых систем, такие как блокирование файлов и создание каталогов.
Если разработчику требуется файловая POSIX-система в ОЗУ с расширенным набором функций, можно воспользоваться драйвером devf-ram или встроенным виртуальным диском в io-blk.so. |
Если требуется сохранять данные при сбоях питания и перезагрузках системы, следует использовать постоянное запоминающее устройство, которое управляется драйвером. ЗОСРВ «Нейтрино» включает в себя следующие виды файловых систем:
Все перечисленные файловые системы работают под управлением драйверов. Статья Примеры компоновки загрузочных образов содержит подробные примеры настройки драйверов файловых систем.
Драйвер флеш-памяти обеспечивает доступ к устройствам различных типов (обычным и с загрузочным блоком) с любыми сочетаниями ширины шины (8, 16, 32 бита) и коэффициента чередования (1, 2 и 4).
Чтобы узнать, какие устройства флеш-памяти поддерживаются на текущий момент, обратитесь к следующим источникам:
boards и mtd-flash каталога BSP/src/hardware/flash С помощью исходного кода можно при необходимости адаптировать наши файловые системы (например, devf-generic) к конкретной встраиваемой системе.
На текущий момент ЗОСРВ «Нейтрино» поддерживает ряд файловых систем, в том числе DOS, Linux, HFS и HFS+, Windows NT, QNX4, Power-Safe, Universal Disk Format (UDF) и др. Подробности см. в описаниях драйверов файловых систем fs-*.
Имеются драйверы для широкого спектра блочных устройств. Актуальную информацию см. в описаниях драйверов блочных устройств devb-*.
В процессе разработки и в распределенных системах сбора данных желательно иметь доступ к файлам, которые находятся на удаленных компьютерах. Такую возможность предоставляет сетевая файловая система.
ЗОСРВ «Нейтрино» не только включает в себя технологию прозрачной распределенной обработки Qnet, но и поддерживает сетевые файловые системы CIFS (SMB), NFSv2 и NFSv3.
Имеются драйверы для различных контроллеров Ethernet. Актуальную информацию см. в описаниях сетевых драйверов devn-* и devnp-*.
Встраиваемая система на основе ЗОСРВ «Нейтрино» взаимодействует с внешней средой с помощью следующих интерфейсов:
ЗОСРВ «Нейтрино» поддерживает различные стандартные последовательные порты (семейство 8250, Signetics и др.) Подробнее см. в описаниях драйверов символьных устройств devc-*.
Если не удается найти готовые драйверы для оборудования встраиваемой системы, необходимо разрабатывать их самостоятельно. Решение этой задачи описано в руководстве Разработка менеджеров ресурсов.
Трудоемкость разработки целевой системы в значительной степени зависит от ее специфики. Мы рекомендуем всегда начинать разработку на поддерживаемой отладочной плате, чтобы минимизировать объем начальной низкоуровневой работы и концентрироваться на системных задачах, а не на нюансах реализации.
Следует использовать отладочную плату, которая максимально схожа с целевой платформой; существует широкий спектр отладочных платформ, совместимых с ЗОСРВ «Нейтрино», от различных производителей.
После освоения комплекта разработчика и создания прототипа встраиваемой системы можно приступать к созданию нестандартных устройств, написанию IPL, кода запуска, драйверов и других компонентов.
С помощью прототипа необходимо получить ответы на следующие вопросы:
Полученная информация используется для планирования дальнейшей разработки.
Существуют различные подходы к разработке оборудования. Мы исследовали множество плат, которые применяются в полевых условиях, и опубликовали полученные результаты в статье Рекомендации по проектированию. Мы рекомендуем ознакомиться с этим приложением перед началом разработки для сокращения трудовых и финансовых затрат.
В идеале целевая система не отличается от отладочной, но в действительности разработчику обычно требуется вносить изменения в некоторые компоненты целевой системы.
Для этого мы предоставляем исходный код многих компонентов ЗОСРВ «Нейтрино». Структура каталогов с исходным кодом показана на следующей схеме.
Три основных ветви исходного кода ЗОСРВ «Нейтрино»:
BSP/ `--> src/ `--> hardware/ |--> ipl/ |--> startup/ `--> flash/
Исходный код разделён на три ветви: ipl, startup и flash. Каждая ветвь включает в себя подкаталоги. Полная структура каталогов ЗОСРВ «Нейтрино»:
BSP/ `--> src/ `--> hardware/ |--> ipl/ | |--> boards/ | | |--> xzynq/ | | `--> ... | | | `--> lib/ | |--> startup/ | |--> boards/ | | |--> xzynq/ | | `--> ... | | | `--> lib/ | `--> flash/ |--> boards/ | |--> qspi-xzynq/ | `--> ... | `--> mtd-flash/
В следующей таблице показано соответствие ветвей исходного кода и глав этой книги:
| Ветвь исходного кода | Статья |
|---|---|
ipl | Руководство по разработке начального загрузчика (IPL) |
startup | Руководство по разработке модуля startup |
Подробное описание формата файла Makefile, который присутствует в этих каталогах, см. в разделе Рекурсивная сборочная подсистема ЗОСРВ "Нейтрино".
Предыдущий раздел: перейти
