1. Разработка встраиваемой операционной системы на базе
микроядерной архитектуры GNU/Mach.
В.А. Сартаков, И.О. Атовмян
В первой части работы представлен обзор современных архитектур
операционных систем и области их применения. Вторая часть работы
посвящена процессу создания встраиваемой системой.
Введение
Операционная система является неотъемлемой частью вычислительной
системы. Современное развитие электроники приводит к существенному
уменьшению размеров вычислительной системы, что в свою очередь привело
к появлению мобильных и встраиваемых устройств. Из-за высокой
сложности этих устройств, а так же развивающихся подходов к разработке
подобных систем, была разработана идеология встраиваемых операционных
систем. Данные системы строились на основе операционных систем общего
назначения, в которые вносились изменения, в соответствии с особенностями
использования. В качестве примера можно привести операционную систему
общего назначения Linux, которая была переработана для мобильных
решений и называлась uCLinux. Основным различием этих систем является
отсутствие методов работы с виртуальной памятью в uCLinux, так как
большинство поддерживаемых этой ОС платформ не имели MMU (memory
management unit, устройство управления памятью).
Появление большого количества различных встраиваемых архитектур,
привело к появлению большого количества разнообразных встраиваемых
операционных систем. В процессе их развития были отмечены две
тенденции. Первая тенденция осуществляла развитие системы «снизу вверх»
– когда система развивалась посредством усложнения более простой
системы, например eCos. Данная операционная система изначально была
предназначена для работы на медленных и очень простых микропроцессорах.
Вторая тенденция – «сверху вниз» – uCLinux, которая создавалась из
полноценной ОС посредством ее упрощения и уменьшения функционала. К
сожалению, системы, разрабатываемые в соответствии с первым подходом,
не позволяют в полной мере использовать существующее готовое

2. программное обеспечение (с открытым исходным кодом), так как в
большинстве своем не соответствуют стандартам POSIX. В свою же очередь
основным недостатком систем созданных в соответствии со вторым
подходом, является использование устаревающих архитектур ОС. Для
разработки встраиваемых ОС необходимо использовать современные
подходы, так как мобильные устройства более критичны к качеству их
программного обеспечения.
Существует несколько типов архитектур ОС: монолитная, монолитно-
модульная, и микроядерная. Микроядерная архитектура является наиболее
защищенной и отказоустойчивой, по сравнению с монолитной и монолитно-
модульной архитектурами. В процессе развития операционных систем,
микроядерная архитектура не получила большого распространения,
поскольку в момент ее появления проигрывала по производительности
обычным Unix системам, и в настоящее время либо не развивается, либо
существует в виде коммерческих проектов. Монолитно-модульная
операционная система Linux, например, являющаяся свободно
распространяемой, развивается и переносится на мобильные платформы.
Наличие существенных недостатков у популярных открытых
монолитно-модульных встраиваемых операционных систем (низкий уровень
надежности и отказоустойчивости) провело к потребности разработки новой
открытой микроядерной операционной системы для применения в
мобильных устройствах. Нами была предпринята такая попытка.
В основу разработки операционной системы положена микроядерная
архитектура GNU/Mach. Микроядро Mach было разработано в университете
Carnegie Mellon в начале девяностых годов. На основе этого микроядра
существует микроядерная операционная система общего назначения – Hurd,
доступная только для архитектуры x86, то есть, не применяемая в мобильных
устройствах. В качестве мобильной аппаратной платформы выбрана
архитектура ARM9.
-2-

3. 1. Краткий обзор современных архитектур операционных
систем и области их применения
1.1. Микроядерная архитектура
Ядро любой современной коммерческой версии UNIX представляет
собой набор очень большого количества функций, с запутанными
взаимосвязями и очень расплывчатыми границами между основными
подсистемами. В результате любая модификация организованной таким
образом системы приводит к появлению в новых версиях большого
количества ошибок. Кроме того, не во всех инсталляциях нужны все
компоненты ядра, а при монолитном его построении удаление ненужных
функций затруднено. Недостатки, присущие операционным системам с
большим монолитным ядром (а это в первую очередь различные версии
UNIX'а), породили интерес к системам, построенным на основе микроядра.
Микроядерный подход заключается в том, что базовые функции ядра
оформляются в виде отдельной небольшой компоненты, выполняемой в
привилегированном режиме, а остальные функции ОС выполняются в
пользовательском режиме с использованием примитивов микроядра. Ввиду
больших потенциальных преимуществ, которые сулит этот подход, можно
предположить, что в ближайшее время большинство новых операционных
систем будет строиться на основе микроядра. Наиболее известными
реализациями этого подхода являются микроядра Mach и Chorus.
Основной сложностью использования микроядерного подхода на
практике является замедление скорости выполнения системных вызовов при
передаче сообщений через микроядро по сравнению с классическим
подходом.
1.1.1. Основные концепции Mach
Микроядро Mach было разработано в качестве основы, на базе которой
можно эмулировать UNIX и другие ОС. Эта эмуляция осуществляется
программным уровнем, который работает вне ядра, в пользовательском
пространстве (рис. 1.1). Следует отметить, что несколько эмуляторов могут
-3-

4. работать одновременно, так что можно выполнять программы 4.3BSD,
System V и MS-DOS на одной машине в одно и то же время.
Ядро Mach, подобно другим микроядрам, обеспечивает управление
процессами, управление памятью, коммуникации и функции ввода-вывода.
Функции управления файлами, каталогами и другие традиционные для
операционных систем функции выполняются в пользовательском
пространстве. Идея построения ядра Mach состоит в обеспечении
механизмов, необходимых для работы системы, но стратегия использования
этих механизмов реализуется на уровне пользовательских процессов.
Ядро управляет пятью главными абстракциями:
• Процессами
• Потоками
• Объектами памяти
• Портами
• Сообщения
Рис. 1. Абстрактная модель эмуляции UNIX на основе Mach
Кроме этого, ядро работает и с некоторыми другими абстракциями, или
связанными с указанными, или менее важными.
Процесс – это адресное пространство, содержащее текст программы и
данные, и обычно один или более стеков. Процесс - это базисная единица для
-4-

5. распределения ресурсов. Например, коммуникационный канал всегда
принадлежит одному процессу.
Поток в Mach является единицей выполнения. Она имеет счетчик
команд и набор регистров, связанных с ней. Каждый поток является частью
точно одного процесса.
Концепцией Mach является введение понятия объект памяти (memory
object), представляющий собой структуру данных, которая может быть
отображена в адресное пространство процесса. Объекты памяти занимают
одну или несколько страниц и образуют основу для системы управления
виртуальной памятью Mach. Когда процесс ссылается на объект памяти,
который не представлен в физической памяти, это вызывает страничное
прерывание. Как и в других ОС, ядро перехватывает страничное прерывание.
Однако в отличие от других систем, ядро Mach для загрузки
от сут ствующей ст раницы посылает сообщение с ерверу
пользовательского режима, а не самостоятельно выполняет эту
операцию.
Межпроцессное взаимодействие в Mach основано на передаче
сообщений. Для того чтобы получить сообщение, пользовательский процесс
запрашивает у ядра «почтовый ящик», который называется порт. Порт
хранится внутри ядра и способен поддерживать очередь упорядоченного
списка сообщений. Очереди не имеют фиксированной длины, но в целях
управления потоком для каждого порта отдельно устанавливается пороговое
значение в n сообщений, так что всякий процесс, пытающийся послать еще
одно сообщение в очередь длины n, приостанавливается для того, чтобы дать
порту возможность очиститься.
Процесс может предоставить другому процессу возможность посылать
(или получать) сообщения в один из принадлежащих ему портов. Такая
возможность реализуется в виде мандата (capability), который включает не
только указатель на порт, но и список прав, которыми другой процесс
обладает по отношению к данному порту (например, право выполнить
-5-

6. операцию ПОСЛАТЬ - SEND). Все коммуникации в Mach используют
подобный механизм.
1.2. Особенности аппаратных платформ
Высокопроизводительные применения типа сотовых телефонов,
дисководов и модемов предъявляют к встраиваемым управляющим
контроллерам требования по обеспечению высокой производительности при
условии сохранении их низкой стоимости.
Современные CISC ядра приближаются к верхним пределам своей
производительности. Кроме того, следствием большого количества
транзисторов в CISC ядрах является большое потребление, большие по
площади кристаллы, сложности при их интеграции и, в результате, высокая
стоимость полной системы.
32-разрядные ядра RISC процессоров предлагают потенциальное
решение этих проблем. Однако применение ранних версий RISC процессоров
не позволяло в полной мере реализовать преимущества RISC архитектуры
перед CISC архитектурой, что в первую очередь связывалось с большим
объемом кодов, для которых требовалась память большого объема что, в свою
очередь приводило к высокой стоимости всей системы.
С начала 90-х годов активное развитие получила технология ASIC
(Applications Specific Integrated Circuit) и ASSP (Applications Specific Standard
Products). Развитие этих технологий и создание на их основе все новых
специализированных приборов было обусловлено ростом потребностей в
новых применениях, в появлении новых сегментов рынка. Это портативные
компьютеры, сотовые телефоны, навигаторы, средства коммуникации,
игровые и телевизионные приставки, бытовые и промышленные средства
управления процессами.
В обеспечение технологий ASIC и ASSP ряд фирм, как крупных,
располагающих собственными производственными мощностями, так и такие,
которые специализируются на разработке IP (интеллектуальной
собственности) начали активную разработку библиотек заранее
-6-

7. спроектированных модулей и периферийных устройств, позволяющих
оперативно создавать приборы с наперед заданными рынком возможностями.
Активную, и подкрепленную реальными достижениями, позицию в
данной области занимает фирма Advanced RISC Machines (ARM) -
специализирующаяся на разработке микропроцессоров и периферии к ним и
продающая лицензии на свою IP.
Кремниевыми партнерами ARM, то есть фирмами, использующими
разработки ARM при создании своих приборов, являются такие ведущие
производители, как Alcatel, Amtel, Asahi Kasei Microsystems, Cirrus Logic,
Digital, GEC Plessey, Hyinday, Lucent, Lucky GoldStar, NEC, OKI, Philips,
Rockwell, Rohm, Samsung, Sharp, Sony, Symbios, Texas Instruments, VLSI,
Yamaha. Некоторые из этих компаний используют разработанные ARM
процессоры для специальных применений, однако большинству они нужны
для мобильных телефонов, систем управления автомобильными двигателями,
лазерных принтеров PostScript и других устройств массового применения и
для всех этих устройств необходимы такие качества, как высокое
быстродействие, умеренная цена и низкое энергопотребление.
Процессоры ARM поддерживаются многими программными
продуктами как самой компании, так и других производителей. Эти продукты
образовали солидную инфраструктуру ПО и средств разработки. Среди них -
отладчики, компиляторы С++, внутрисхемные эмуляторы, таблицы
разработки, операционные системы реального времени, драйверы низкого
уровня, а также программные применения высокого уровня. Accelerated
Technology, Enea OSE Systems, ISI, JavaSoft, JMI, Microtec, Microsoft,
Perihelion, Psion, Wind River и другие компании обеспечивают совместимость
своих ОС и средств разработки с процессорами ARM.
Фирмой ARM разработан целый ряд 32-разрядных RISC процессоров с
различными возможностями и различной производительности а ее процессор
ARM7, разработанный еще в1994 году, используется до настоящего времени.
Сама фирма определяет процессор ARM9 как универсальное, с малым
потреблением, ядро 32-разрядного RISC микропроцессора, предназначенное
-7-

8. для использования в различных заказных и специальных ИС. Малые размеры
RISC ядра позволяют успешно интегрировать его в большие заказные схемы,
которые могут содержать RAM, ROM, DSP, дополнительную логику и другие
элементы.
К областям применения ядра ARM9 фирма относит:
Телекоммуникацию - контроллеры GSM терминалов
Обмен данными - средства преобразования протоколов
Портативные вычисления - Palmtop компьютеры
Портативные измерительные устройства - карманные устройства
сбора данных
Автомобильную технику - устройства управления двигателем
Информационные системы - Smart карты
Средства отображения - JPEG контроллеры
Растущие требования к производительности целевых пользовательских
систем побуждает изготовителей микроконтроллеров повышать их
производительность и функциональные возможности. Это достигается
прежде всего путем перехода на более мощные ядра ARM9/9E и, в частности,
следующие их разновидности: ARM920T, ARM926EJ-S, ARM946E-S.
-8-

9. 3. Вывод
Использование микроядерной архитектуры в мобильных системах
способствуют повышению устойчивости системы, так как ошибки в работе
системе приводят к отказу сервера, а не всей системы в целом, что
характерно для монолитных и монолитно-модульных ядрах. К сожалению, из
открытых микроядерных архитектур остался только Mach, разработанный в
начале 90ых годов. В областях встраиваемых систем нет вообще систем
микроядерной архитектуры с открытым исходным кодом. Сортирование
Mach на мобильные платформы создаст альтернативу монолитно-модульным
и монолитным ядрам, а открытый исходный код позволит большему
количеству людей вести его разработку и использование.
-9-

10. 2. Процесс создания встраиваемой операционной системы
на основе микроядерной архитектуры GNU/Mach
2.1 Последовательность разрабтки встраиваемой ОС
Для создания прототипа встраиваемой операционной системы на
основе микроядерной архитектуры GNU/Mach были решены следующие
задачи:
1. Разработаны механизмы компиляции и автоматической сборки ОС.
2. Создан драйвер Ethernet.
3. Создан модуль-сервера содержащнго в себе элементы TCP/IP.
В качестве аппаратной платформы была выбрана отладочная плата SK-
AT91SAM9XE5121 с процессором ARM9 Atmel AT91sam9260.
Работоспособность операционная система определялась по корректной
обработке ECHO Ping запроса при параллельно работающих микроядре и
модуль-сервере.
В настоящее время ядро Mach поддерживает только одну архитектуру –
i386. Таким образом, для использования этого микроядра в качестве
встраиваемого, необходимо расширить набор поддерживаемых архитектур и
аппаратных платформ. Процесс переноса ОС на новую архитектуру
называется портированием.
Операционная система логически разделяется на несколько частей,
пространств. Первая из них – пространство микроядра, представлена
микроядром GNU/Mach, вторая - пространство пользователя – которое
представлено набором прикладных программ и стандартной библиотекой
libc, третье - набор драйверов, четвертая представлена средствами
разработки и конфигурации. В каждой из этих частей необходимо произвести
существенные доработки, что бы позволить микроядру Mach работать на
новой аппаратной платформе:
1. Пространство микроядра операционной системы:
1 Выбор отладочной платы обусловлен высокой популярностью процессора Atmel AT91SAM9260 и
низкой стоимостью самой отладочной платы.
-10-

11. • Портирование ядра операционной системы на различные
аппаратные платформы, а именно – поддержка различных
микропроцессорных архитектур, и поддерживание
наиболее распространенных платформ.
• Оптимизация ядра для работы в встраиваемых системах.
2. Драйвера устройств. Необходим обязательный минимум
драйверов стандартных устройств. Так же, в этот пункт входят
интерфейсы «прослойки» между уже разработаным Linux/Unix
системным ПО и микроядром Mach. Например – нужно иметь
возможность заменить TCP/IP стек в случае перехода от
минимальной мобильной системы к полноценной серверной ОС.
3. Про странство пользователя – прикладное програмное
обеспечение пользовательского уровня. Стандартные библиотеки,
утилиты, графика.
4. Конфигуратор. Встраиваемая система должна иметь мощный
механизм настройки. Необходимо проработать структуру
исходного кода, а так же разработать прикладное ПО
конфигурирования системы, интуитивно понятное и обладающее
высокой функциональностью.
На основе выделенных областей, был разработан план работы. Его
основные шаги:
1. Перенос микроядра на архитектуру Arm9 . Так как микроядро
занимает всего 2 mb памяти, то серьезных ограничений по
запуску ядра на ARM9 со стороны ресурсов нет. И изучение
механизмов работы с самой ОС будет проходить в процессе
переноса. На выходе – грузящееся ядро с диагностическими
сообщениями в консоли.
-11-

12. 2. Разработка драйверов устройств для отладочной платы. На
выходе – пример операционной системы, с TCP/IP стеком,
отвечающая на ICMP запросы из сети.
3. Портирование прикладного ПО под архитектуру MACH и ARM9.
На выходе – запуск системы с тестами под Embedded Linux и
Mach, сравнение полученных результатов.
4. Разработка конфигуратора, доработка ядра. Итерационный
процесс, а именно: доработка ядра - внесение архитектурных
изменений в разработаные драйвера - доработка прикладного ПО.
Механизм переноса Mach на новую платформу сводится к следующему
– первым шагом производится сборка операционной системы под известную
платформу, на которой можно достоверно убедиться в работоспособности
ядра, а после этого в сконфигурированном исходном коде заменяются
аппаратнозависимые части одной платформы на другую. В нашем случае -
первоначальный запуск производится на i386, а перенос – на Arm9.
Важно заметить, что запуск микроядра в оперативной памяти
производится при помощи загрузчика uBoot. Этот механизм идентичен
процессу загрузки операционной системы Linux, что позволяет в любой
момент произвести сравнение нашей операционной системы с Linux. Вся
работа с исходным кодом Mach, сборка, отладка, тестирование в эмуляторе
так же происходит с использованием ОС Linux. ОС Windows используется
только для работы с средой IAR5.12, в которой производят отладку базовых
аппаратнозависимых частей ОС.
Данный алгоритм работы обладает серьезным преимуществом – работа
происходит сразу на платформе Arm, то есть система изначально
разрабатывается как Встраиваемая. Недостатки – нет возможности явно
разграничить фазы работы с наглядным представлением результатов.
2IAR 5.1 – среда разработки для ARM9. Подробнее об этой среде разработке рассказано в разделе
«4.2. Средства разработки и отладки»
-12-

13. Разработка конфигуратора происходит на поздней стадии, из-за этого могут
быть проблемы со структуризацией кода.
Шаг1: Перенос микроядра с i386 на ARM9
Представим подробнее этот процесс. В него входят:
1. Подготовка кросс-платформенных средств разработки (arm-eabi-
gcc arm9 и gcc x86 компиляторов и сопутствующих утилит)
2. Конфигурирование, сборка и запуск микроядра Mach в
виртуальной машине с архитектурой x86. Подготовка средств
быстрой загрузки и отладки микроядра.
3. Работа с аппаратной платформой в IAR 5.1 – Разработка
программы «Hello world», содержащий в себе аппаратно
зависимые функций работы с системным т аймером,
последовательным портом. Во время загрузки эта программа
должна о суще ствлять конфигурирование подсистемы
прерываний, блока управления частотой проце ссора,
конфигурирование системы ввода-вывода.
4. Перенос «Hello-world» программы из среды IAR5.1 в среду linux.
Сборка «Hello-world» компилятором arm-eabi-gcc 3, запуск ее на
отладочной плате.
5. Замена аппаратно-зависимых частей сконфигурированного для
i386 кода микроядра функциями заглушками. Компиляция
полученного кода arm-eabi-gcc компилятором.
6. Итерационная отладка перенесенного микроядра. Постепенно
происходит замена заглушек «полезным» кодом, что позволяет
микроядру осуществить полноценную загрузку на новой
архитектуре.
3 Версия бесплатного компилятора GCC для ARM9. Подроднее об этом в разделе «4.2. Средства
разработки и отладки»
-13-

14. 7. Подготовка модуля-сервера. В качестве основы для модуля-
сервера выступает используемая ранее программа Hello World,
скомпилированная arm-eabi-gcc.
8. Запуск модуля-сервера.
9. Активация системного т аймера. Отладка интерфейс а
взаимодействия между микроядром и модуль-сервером (RPC).
Создание и отладка системные вызовы. Создание основы для
стандартной библиотеки языка C, содержащую в себе системные
вызовы, а так же простейшие функции работы с памятью
(копирование, сравнение).
Первые четыре шага являют ся подготовительными перед
непосредственным переносом. После четвертого шага, программа Hello
World запускается абсолютно в тех же условиях, что и в будущем микроядро.
Это означает, что «Hello world», и микроядро, компилируются одними и теми
же инструментами, идентично загружаются на аппаратную платформу и на
ней исполняются. Более того, микроядро будет использовать все аппаратно-
зависимые части программы Hello World – механизмы ввода/вывода, работу с
таймером и прочие.
После отладки системных вызовов, модуль-сервер получает
возможность обмениваться данными с микроядром. На этом первая стадия
работы заканчивается. Вторая стадия работы подразумевала добавление
создание Ethernet, а так же добавление простейшего TCP/IP стека.
Шаг 2: Драйвер Ethernet и TCP/IP стек
Шаг 2 посвящен разработке модуля-сервера и драйвера устройства
Ethernet, при помощи которых будут извлекаться пакеты из сети и
обрабатываться. При этом модуль сервер работает параллельно с
микроядром. Процесс разработки этого модуля включает в себя:
1. Создание и отладка драйвера Ethernet в среде IAR 5.1. Драйвер
производит инициализацию MAC модуля, а так же осуществляет прием
и отправку пакетов в сеть.
-14-

15. 2. Создание анализатора пакетов сети Ethernet. Это не полноценный
TCP/IP стек, а минимальный анализатор пакетов, который извлекает их
из сети, изучает заголовки, и отвечает на ARP и ICMP Echo Ping4
запросы.
3. Перенос драйвера и стека в среду Mach.
Драйвер необходимо поместить в микроядро, а стек - в модуль-сервер.
По запросу, микроядро, используя драйвер Ethernet, извлекает пакеты из сети
и передает их через системный вызов в пространство пользователя – модуль-
сервер. В нем, TCP/IP стек должен производить анализ заголовков пакета, и
сформировать ответ, который так же через системный вызов необходимо
передать сначала в микроядро, затем в драйвер, а после этого в сеть.
Создание модуль-сервера, содержащего в себе элементы TCP/IP стека,
позволяет наглядно продемонстрировать работу модели операционной
системы. В самом деле – в этой модели присутствую основные элементы
полноценной встраиваемой операционной системы.
Параллельно работающие микроядро и модуль-сервер обмениваются
между собой сообщениями используя механизм системных вызовов, при этом
и микроядро, и модуль-сервер находятся в собственных адресных
пространствах.
4 Для создания ICMP Echo запросов используется утилита ping. ping — утилита для проверки
со единений в с етях на о снове TCP/IP. Она отправляет запро сы (ICMP Echo-Request)
протокола ICMP указанному узлу сети и фиксирует поступающие ответы (ICMP Echo-Reply)
-15-

16. 2.2 Описание аппаратной платформы и средств разработки
Архитектура ARM получила большое распространение в встраиваемых
и мобильных системах. Поэтому при выборе аппаратной платформы
рассматривлась отладочные платы только с процессорами этой архитектуры.
Из всего обьема доступных отладочных средств, была выделена плата SK-
AT91 на базе микроконтроллерa фирмы Atmel - AT91SAM9260. Выбор
именно этой отладочной платы обусловлен высокой популярностью
процессора Atmel AT91SAM9260, низкой стоимостью самой отладочной
платы, а так же отсутствием других более современных и качественных
отладочных плат.
Среди мобильных систем наибольшее распространение получил
архитектура ARM, благодаря низкому электропотреблению, 32х битной
разрядности и низкой стоимости кристалла. В качестве аппаратной
платформы при разработке ОС использована плата SK-AT91 на базе
микроконтроллерa фирмы Atmel - AT91SAM9260.
Рис. 2. Аппаратная платформа.
Отладочная плата содержит большое количество интерфейсов,
обеспечивающих удобную разработку системы. Ethernet позволяет загружать
образ системы в память с высокой скоростью, экономя время на
тестирование. Диагностические сообщения выводятся через Rs-232
интерфейс, а на портах ввода-вывода находятся светодиоды, отражающие
стадии загрузки системы. Подключенная периферия:
• 64MБайт (16Mx32) SDRAM.
-16-

17. • 256МБайт NAND flash.
• 4МБайт DataFlash AT45DB321.
• Ethernet 10/100M PHY - KS8721B, тип интерфейса - RMII.
• GSM модем, совмещенный с GPS приемником SIM508.
• Аудио стерео CODEC TLV320
• USB host (USB-A).
• USB client (USB-B).
• RS232 приемопередатчик.
• 37 линии I/O
Для работы с отладочной платы использовались следующие средства
отладки:
IAR 5.1 – среда разработки для ARM9. Это отладочная среда, которая
работает под управлением Windows. В нее входят компилятор с языка Си,
ассемблер, компоновщик, и отладчик, при этом возможно взаимодействие с
внешними программами. Встроенный редактор специально настроен на
синтаксис языка Си, а дополнительные утилиты и хорошая встроенная
система помощи дополнительно облегчают разработку программ.
MT-link. JTAG USB отладчик/программатор, аналог J-link,
совместимый с IAR средой разработки.
Segger J-link Commander – для отладки системы во время работы.
Персональный компьютер с ос Windows 7 и Linux – в Windows
происходила первоначальная отладка, и все что касается работы с платой, в
Linux происходила сборка и загрузка образа ядра в плату.
Minicom – программа терминал для доступа к отладочной плате по
последовательному порту.
USB-to-COM – контроллер COM на USB интерфейсе, имеющий TTL
выходы для последовательного порта.
ARM-EABI-GCC – версия бесплатного компилятора GCC для ARM9.
Debian GNU/Hurd – операционная система Debian построенная на ядре
GNU/Mach. Используется для
-17-

18. VMware Player — бесплатный (для личного некоммерческого
использования) программный продукт, предназначенный для создания и
запуска готовых виртуальных машин (созданных в VMware Workstation, либо
VMware Server).
MIG - Утилита, преобразующая исходный код микроядра для создания
интерфейсов взаимодействия между микроядром и модулями-серверами.
ОС Linux – бесплатная операционная система, использовалась для
разработки, сборки и отладки GNU/Mach.
ping — утилита для проверки соединений в сетях на основе TCP/IP.
2.3. Процесс разработки
Запуск ядра Mach для x86
Платформа Debian представляет загрузочный диск операционной
системы Hurd – операционной системы на основе микроядра Mach. Была
произведена установка операционной системы Hurd на виртуальную машину,
что бы иметь возможность оценить работоспособность системы при будущей
ее доработке. Был разработан механизм автоматической сборки и загрузки
операционной системы с новым ядром, что позволяет, в будущем,
производить автоматическое тестирование системы.
Сборка микроядра из исходного кода для X86
Ядро Mach представлено в глобальном репозитории на сайте
сообщества GNU: http://www.gnu.org/software/hurd/microkernel/mach.html
Так же для сборки ядра Mach необходим генератор интерфейсов – MIG.
И с ход н ы й код я д р а п р е д с т а в л я е т с о б о й а р х и в , с од е р ж а щ и й
конфигурационные скрипты autoconfigure, исходный код микроядра и
платформы i386. Для сборки ядра под архитектурой x86_64 были внесены
изменения, представленные в приложении.
Сборка тестового приложения Hello World
-18-

19. Среда разработки IAR предоставляет удобный интерфейс для работы,
но совершенно не пригодна для работы с исходным кодом операционной
системы. По этому в ней была сделана только тестовая программа Hello
World . Э т а п р о г р амма о суще ствляла п ри заг рузке н аст рой ку
последовательного порта, установку тактовой частоты процессора,
конфигурацию портов ввода-вывода, на которые были помещены светодиоды
для индикации работы. Помимо этого был сконфигурирован таймер,
генерирующий прерывания 10 раз в минуту.
Отладка обработчика прерывания производилось в IAR. Эта среда
разработки умеет работать с внутрисхемным отладчиком JTAG, благодаря
которому можно в произвольный момент остановить работу процессора и
считать содержимое любых регистров, что позволило в короткий срок
настроить работу системного таймера. Алгоритм работы с таймером
следующий:
1. Сохраняем необходимый период срабатывания прерывания в
регистр AT91C_PITC_PIMR, а так же выставляем флаг активации
таймера в этом же регистре.
2. Инициализируем источник прерывания (таймер) в регистре,
режим срабатывания, а так же сохраняем адрес необходимой
функции обработчика прерывания (соответственно регистры
AIC_IDCR, AIC_SMR, AIC_SVR). Эти действия производятся
при отключенных прерываниях.
3. Разрешаем прерывания от таймера (регистр AIC_IECR)
4. Запускаем таймер. (регистр PITC_PIMR)
Функция обработчик прерывания содержит в себе проверку на
источник прерывания, а так же подтверждает обработку прерывания
средством считывания регистра состояния.
-19-

20. Далее была сборка этого приложения используя компилятор arm-eabi-
gcc и собственные скрипты сборки. Образ firmware загружался в память
платформы, используя загрузчик U-boot, и стартовал, выводя сообщение
«Hello world», с периодичность 10 раз в секунду.
Сборка Mach компилятором arm-eabi-gcc
Следующим шагом происходит сборка микроядра компилятором arm-
e a b i - g c c . Д л я э т о г о б ы л и с д е л а н о м н о ж е с т в о з а гл у ш е к н а
платформозависимый код от i386. Все заглушки были помещены в файл os-
imp.c, который был добавлен к списку компилируемых файлов.
В процессе итерационных доработок заглушек, в первую очередь были
созданы механизмы инициализации, сохранения, загрузки и переключения
контекста. . Инициализация контекста подготавливает необходимую
структуру в области памяти, определенной как стек данного потока. Загрузка
контекста производит восстановление регистров из стека, что приводит к
выполнению нового потока. Процесс сохранения – перенос текущих
значений регистра в стек процесса, а переключение – объединяет в себе
сохранение и загрузку контекста.
Подготовка платформы к запуску модуль-сервера
Так как операционная система самостоятельно не загружает модуль-
сервера в память, а пользуется таблицей модулей полученных от загрузчика,
нам необходимо произвести размещение в памяти микроядра. Для этого нам
нужно осуществить его сборку, загрузку в устройство и копирование в
память. В качестве тестового модуля используется программа Hello World,
которая постоянно выводит в последовательный порт “Hello World”:
Int main()
{
Printf(“Hello wordn”);
}
-20-

21. Скомпилированный при помощи средств кросс-платформенной
разработки, модуль представляет собой файл в формате ELF (Executive
Linking Format), который, используя терминальный клиент, через
последовательный порт загружается в устройство.
Далее осуществляется загрузка сжатого образа ядра, После ее
распаковки и исполнения, микроядро Mach имеет доступ к структуре, в
которой находятся адреса и строки аргументов загруженных модулей. В
нашем случае, структура содержит в себе один модуль (Hello World), а так же
строку аргументов для него :
mod.mod_start=0x23000000;
mod.mod_end=0x2303b144;
mod.string="/hurd/pfinet $(task-create) $(task-resume)";
boot_info.flags=0x7ef;
boot_info.cmdline="/boot/zemach root=/ ";
boot_info.mods_count=1;
boot_info.mods_addr=&mod;
kernel_cmdline = (char*)phystokv(boot_info.cmdline);
Запуск модуль-сервера
Перед стартом модуля-сервера, в памяти находятся 4 потока –
idle_thread, reaper_thread, swapin_thread, sched_thread. Данные потоки
являются потоками ядра, инициализированы и готовы к выполнению. В
случае вызова системной функции thread_select, из списка будут
последовательно возвращены указатели на эти потоки. Так же в памяти
присутствует поток startup_thread, который непосредственно произведет
загрузку ядра, инициализацию устройств, а по завершению будет выполнять
функции потока пейджера страниц.
Точкой входа для загрузки модуль-сервера является функция
bootstrap_create. В ней происходит обработка строки аргументов полученных
с загрузчика, с формированием структуры аргументов для каждого модуля. В
-21-

22. процессе загрузки модуль-серверов, им будут переданы указатели на
соответствующие структуры. Далее создается процесс, привязанный к
пользовательскому пространству памяти. После получения таблицы
аргументов, происходит вызов функции boot_script_exec_cmd (void *hook,
task_t task, char *path, int argc, char **argv, char *strings, int stringlen), в
которой создается процесс. Инициализированный поток в своем контексте
имеет функцию user_bootstrap(), задачей которой является извлечение
исполнимого кода из ELF модуля модуль-сервера, формирование стека
аргументов, а так же запуск пользовательского потока.
Остановимся на последнем подробнее. В контексте потока
user_bootstrap PC регистр указывает на точку входа user_bootstrap. В процессе
выполнения этой функции вызывается exec_load, в котором помимо
копирования исполнимого кода ELF файла, происходит подмена контекста
исполняющегося потока на контекст, сформированный для выполнения
исполнимого кода полученного функцией exec_load. После формирования
стеков, происходит вызов потока, на который указывает active_stacks. Что
приводит к последовательному вызову каждого из четырех потоков,
выполнения полезного кода, блокировку с переключением на следующий
поток. После того как все четыре потока отработают, происходит вызов
пользовательского потока, что приводит к старту модуль-сервера.
Системный таймер
1. Точкой входа прерывания таймера в микроядре Mach является
функция hardclock(). Она вызывает функции перерасчета
системных квантов, а так же вызывает функцию softclock().
2. Потоки в ядре могут уходить в блокировку на определенное
время. При этом поток остается в очереди на обработку, но он
имеет в себе признак ожидания таймаута. Обработкой этих
таймаутов занимается функция softclock(), управление контрой
передается из hardclock(). Суть softclock() заключается в в
последовательном вызове всех обработчиков таймера из очереди.
-22-

23. 3. Подобным образом вызывается функция recomput_priorities(),
которая пересчитывает приоритеты потоков, а так же может
очистить флаг блокировки, при достижении необходимого
интервала времени. Поток с истекшим таймаут помечается
активным, и поступает на обработку (функция thread_setrun).
4. Если поток становится активным, то thread_Setrun устанавливает
флаг ast_on. Суть этого признака в том, необходимо ли менять
режим работы процессора после выхода из режима прерывания.
Фактически этот флаг определяет произойдет ли переключение
контекста после завершения обработки прерывания.
5. Система построена таким образом, что все внутренние потоки
ядра уходят в блокировки, и бОльшую часть времени находятся в
неактивном состоянии. Более того, переключение между потока
ядра осуществляется при помощи повторного запуска основной
функции. (continuation механизм). В том случае, если
прерывание сработало во время выполнения потока ядра,
следующий поток будет выполняется только когда первый (во
время которого произошло прерывание) уйдет в блокировку.
6. Е с л и п р е р ы ва н и е п р о и з о ш л о в о в р е м я в ы п ол н е н и я
пользовательского кода, то есть во время работы модуль-сервера,
то после завершения работы softclock() и активном флаге need_ast
производится вызов функции ast_from_interrupt. В задачи это
цепочки входит определение какой следующий поток
пространства пользователя будет выполнятся, а так же при
помощи функции thread_switch осуществляет замену активного
контекста на контекст функции, в который произойдет возврат
по сле окончания обработки прерывания. Фактиче ски,
переключение контекста происходит только в прерывании, и
подразумевает сохранение активного стека в контексте старого
-23-

24. потока, а стек нового переносится в активный стек, куда будет
передано управление при завершении прерывания.
Системные вызовы
Команда программного прерывания используется для входа в
защищенный режим (Supervisor), выполнение которой вызывает прерывание
работы программы и передачу управления в соответствующий обработчик,
при этом происходит смена режима работы ядра ARM9TDMI. В регистр PC
записывается определенное значение, соответствующее вектору обработчика
(0x08), а содержимое CPSR сохраняется в специальном регистре SPSR_svc.
Защита обработчика программного прерывания от возможности изменений
из основной программы или приложения (и контроллером внешней памяти)
позволяет построить на основе команды SWI полностью защищенную
операционную систему.
Так как перед передачей управления обработчику программного
прерывания содержимое регистра PC предварительное сохранено в R14_svc,
то для возможности правильного возврата из прерывания фактически в
R14_svc заносится адрес команды, сразу следующий за командой SWI. При
выполнении команды MOVS PC,R14_svc восстанавливается содержимое
CPSR и возвращается управление в основную прерванную программу.
Необходимо отметить, что этот способ входа и выхода из такого прерывания
не позволяет реализовывать вложенные прерывания, поэтому внутри этого
обработчика необходимо вручную сохранять адрес возврата (PC) и флаги
процессора (SPSR), а перед выходом из него вручную восстанавливать
указанные регистры.
Таким образом, из любой пользовательской программы системный
вызов осуществляется при помощи:
asm(" mov r0,#0x42");
asm(" swi 0x2");
Первая команда копирует в регистр r0 число 0x42. Это число будет
использовано в качестве аргумента в функции обработчика прерывания.
-24-

25. Вторая команда – осуществляет программное прерывание с аргументом 0x2.
В случае, если необходимо передать более одного аргумента, они заносятся в
регистры r1 и r2.
В свою очередь, в микроядре находится обработчик этих системных
вызовов. В архитектуре ARM, в младших 0x40 байтах находятся системные
вектора. В них входят – ресет вектор, вектор прерываний, вектор ошибки
данных, вектор исключений. Для корректной отработки программного
прерывания необходимо добавить обработчик в эту таблицу:
Эта команда означает, что при срабатывании программного прерывания
процессор переключится на код с меткой software_interrupt.
Далее сама метка:
.code 32
software_interrupt:
ldr r0, [lr, #-4]
b my_exception_handler
my_exception_hanlder содержит в себе обработчик прерывания,
исполнящию в ядре функции обработки системных вызовов.
Обьеденив все системные вызоые воедино, присвоив каждому имя в
соответствии с исполняемой функцией, мы получили базовую часть
стандартой библиотеки libc для нашей операционной системы. Далее,
добавив к системным вызовам простейшие функции работы со строками и
памятью, а так же ассемблерный код запуска модуля-сервера , получили
работоспособную библиотеку libc. Эта библиотека необходима нам для
компиляции модуль-серверов.
Ethernet в IAR
Используя среду разработки IAR была создана программа, которая
работала без операционной системы, настраивала MAC и PHY модули,
содержала в себе элементы TCP/IP стека, что позволяло осуществлять
обработку сообщений сети Echo PING запросы.
Эта программа состояла из нескольких частей. В первую очередь
проводилась конфигурация портов ввода-вывода и интерфейса MAC.
-25-

26. Настроенный модуль MAC предоставлял доступ к устройству PHY –
KS8721B, подключенного по интерфейсу – RMII. Активировав PHY,
программа переводила его в состояние Auto Negotiate. В этом режиме плата
автоматически определяла к какому интерфейсу Ethernet она подключена, его
скорость и механизм передачи данных. В случае успешного прохождения
Autonegotiate, программа начинала периодически опрашивать MAC модуль,
на предмет прихода новых сообщений из сети.
Все входящие пакеты попадают в очередь pRxBuffer. В процессе
работы, пакеты из этой очереди извлекаются и обрабатываются TCP/IP
стеком. Этот же стек формирует очередь на отправку – pTxBuffer. Эта очередь
связана напрямую с MAC модулем, при попадании в нее любой пакет
отправляется в сеть.
TCP/IP стек
Для демонстрации работы системы был разработан небольшой TCP/IP
стек. Этот стек производил обработку следующих типов пакетов из сети:
1. Ethernet
2. ARP
3. IP/ICMP
Когда пакет Ethernet поступает в стек, в первую очередь определялся
его тип. Тип пакета находится в заголовке пакета. В зависимости от типа
пакета, его в дальнейшем обрабатывал или ARP, или IP модуль.
ARP модуль проверяет кому предназначен ARP-запрос. Если он
предназначен для нашей платы, то формируется ответ, содержащий в себе
MAC и IP адрес устройства. В противном случае ответ не формируется.
IP модуль определяет тип пакета. В минимальном варианте
обрабатываются только ICMP запросы. При получении пакета ICMP Echo
Ping, производится проверка, совпадают ли IP и MAC адреса адресата и
платы. Если они совпадают, то формируется ответ – ICMP Echo Ping reply.
Для тестирования использовалась утилита ping. Она отправляет
запросы (ICMP Echo-Request) протокола ICMP указанному узлу сети и
-26-

27. фиксирует поступающие ответы (ICMP Echo-Reply). Время между отправкой
запроса и получением ответа (RTT, от англ. Round Trip Time) позволяет
определять двусторонние задержки (RTT) по маршруту и частоту потери
пакетов, то есть косвенно определять загруженность на каналах передачи
данных и промежуточных устройствах.
Модуль-сервер с TCP/IP стеком и драйвер Ethernet
Напомню, что в качестве оценки работоспособности полученной
системы, решено было создать модуль-сервер, содержащий в себе элементы
TCP/IP стека. Запустив на аппаратной платформе этот модуль-сервер
параллельно с микроядром, используя утилиту ping можно оценить
работоспособность модуль-сервера, а так же время обработки сообщений
Echo Ping Request.
В предыдущем параграфе мы разработали небольшую программу,
способную обрабатывать пакеты из сети Ethernet, так что теперь необходимо
разделить ее на две части – в одной из них будет драйвер Ethernet и она
помещается в микроядро, а другая, элемент стека – находится в модуле-
сервере.
Тестирование системы ICMP запросами
В качестве источников ICMP запросов используется утилита ping. Она
формирует в сети Ethernet ICMP сообщения, которые распространяются по
сети. Аппаратная платформа с тестируемой системой получает пакеты,
обрабатывает их и формирует ответ. Далее утилита ping вычисляет время,
которое прошло между отправкой запроса и получением ответа. Сравнение
этого времени на разных платформах обычно используется для оценки
производительности TCP/IP стека и механизмов взаимодействия ОС с
подсистемой Ethernet.
Созданная система прошла успешно тестирование ICMP запросами.
При этом не было потеряно ни одного сообщения, на консоли был
постоянный вывод диагностических сообщений от микроядра, а так же
сообщения анализа заголовков модуль-сервера. Было отправлено 50
сообщений с интервалом в 1 секунду.
-27-

28. Рис. 3. Гистограмма распределения времени ответов микроядероной ОС.
На гистограмме видно, что ответ формируется с разными интервалами
времени – 15 сообщений с временем ответа из интервала 0.2-0.3мс, и 20
сообщений в интервале 0.6-1.3мс. При этом есть пакеты с большим
временем формирования ответа – 2.2мс. Причиной этих длительных ответов
может быть наличие диагностических сообщений во время работы модуль-
сервера.
Для сравнения была проведены подобные тестирования без
использования операционной системы. Напомню, что изначально программа
работы с ICMP запросами разрабатывалась в среде IAR – т.е. без
использования операционной системы, а потом переносилась в модуль-
сервер. В случае отсутствия ОС у меня не будет тратиться время на
переключения контекста между микроядром и модуль-сервером, а так же не
будет диагностических сообщений микроядра. Для эксперимента
диагностические сообщения о заголовках TCP/IP отключены.
Распределение получилось следующим:
-28-

29. Рис. 4. Гистограмма распределения времени ответов системы без ОС.
На этой гистограмме четко видны 2 группы сообщений – быстрые с
временем ответа 0.5-0.25мс, и долгие – 0.8-0.9мс. Отсутствие переключений
контекста и диагностики лишь очистило распределение от промежуточных
значений. Это говорит о плохой проектировке механизмов работы TCP/IP
стека. Но, напомню, в задачу работы входило создание операционной
системы, и приведенные в этом параграфе тесты носят ознакомительный
характер.
В качестве эталона привожу распределение времени ответов для
операционной системы Linux:
Рис. 5. Гистограмма распределения времени ответов для ОС Linux.
-29-

30. На гистограмме распределения ясно видно, что большая часть пакетов
попадает в интервал 0.2-0.23мс.
Не смотря на различия во времени формирования пакетов,
тестирования было признано удавшимся – модель микроядерной
операционной системы, состоящая из микроядра и модуль-сервера,
продемонстрировала свою работоспособность.
-30-

31. Заключение
Данная работа посвящена актуальной теме разработке встраиваемой
микроядерной операционной системы для мобильных устройств.
Нами были выполнен перенос микроядра с архитектуры i386 на ARM9
и создан модуля-сервера, содержащий в себе драйвер Ethernet и элементы
TCP/IP стека. Система продемонстрировала корректную работу, верно
обработав из сети Ethernet запрос Echo Ping request.
Полученный программный комплекс, содержащий в себе параллельно
работающие микроядро и модуль-сервер, являются моделью операционной
системы, так как в ней отражены основные механизмы работы системы, но
предоставляемый ею функционал не полон. Например - в модели
присутствует модуль-сервер, передающий сообщения в микроядро при
помощи системных вызовов, но в модели модуль-сервер только один. Более
того, перенос модуль-сервера страничного обмена (пейджер), например,
требует серьезной доработки созданной библиотеки libc, а так же части
микроядра.
Важно заметить, что разработанный алгоритм, а так же сопутствующие
процессу разработки ОС программные материалы, позволяют с легкостью
произвести перенос микроядра GNU/Mach на другие популярные платформы
– например MIPS, PPC.
Исходный код разработанной операционной системы, а так же весь
сопутствующий материал, размещен в сети Internet по адресу http://
www.ksyslabs.org/projects/gnu-mach/sources.
Данная работа не претендует на всю полноту создания новой ОС.
Представляется необходимым доработка библиотеки Libc, самого микроядра
и средств конфигурации. Основой целью такой доработки должно быть
доведение текущей системы до уровня, позволяющего компилировать уже
существующие модули-сервера операционной системы Hurd.
-31-

32. Литература:
1. Олифер В.Г., Олифер Н.А., Сетевые Операционные системы
– / В.Г. Олифер, Н.А. Олифер / – СПб., Питер, 2005.
2. Редькин П.П. Микроконтроллеры ARM7. Семейство LPC2000.
Руководство пользователя – Додэка, 2007.
3. Таненбаум Э. Современные операционные системы – СПб., Питер,
2007.
4. J. Mark Stevenson, Daniel P. Julin. “Mach-US: UNIX On Generic OS
Object Servers” Usenix Technical Conference, Jan. 1995.
5. J. Mark Stevenson, Daniel P. Julin. “Client-Server Interactions in Multi-
Server Operating Systems: The Mach-US Approach” CMU Technical
Report: CMU-CS-94-191, Sep. 1994.
6. Daniel P. Julin. “The Mach 3.0 Multi-Server System Overview” July
1991.
7. Paulo Guedes, Daniel P. Julin. “Writing a Client-Server Application in C+
+” 1992.
8. Paulo Guedes, Daniel P. Julin. “Object-Oriented Interfaces in the Mach
3.0 Multi-Server System.” IEEE Workshop on Object Orientation in
Operation Systems 1991.
9. Daniel P. Julin. “Naming Facilities for Operating System Emulation in
Mach 3.0” August 1991.
10. Paulo Guedes. “Libus++ Reference Manual” November 1992.
11. Mary R. Thompson. “Installing and Running Mach-US.” July 1994.
12. Официальный сайт микроядра GNU/Mach: http://www.gnu.org/
software/hurd/microkernel/mach/gnumach.html
13. Официальный сайт операционной системы GNU/Hurd: http://
www.gnu.org/software/hurd/hurd.html
14. Официальный сайт операционной системы Debian GNU/Hurd: http://
www.debian.org/ports/hurd/
15. Официальный сайт бесплатного компилятора GCC: http://gcc.gnu.org/
16. Официальный сайт VMWare: http://www.vmware.com/ru/
17. Официальный сайт SEGGER: http://www.segger.com/cms/
18. Официальный сайт IAR: http://www.iar.com/website1/1.0.1.0/3/1/
-32-

33. 19. Официальный сайт операционной системы Fedora: http://
fedoraproject.org/
20. Официальный сайт STARTERKIT: http://starterkit.ru/html/index.php
21. Официальный сайт ARM: http://infocenter.arm.com/help/index.jsp?
topic=/com.arm.doc.set.architecture/index.html
22. Официальный сайт проекта Mach университета Conreg: http://
www.cs.cmu.edu/afs/cs.cmu.edu/project/mach/public/www/mach.html
-33-

34. Глоссарий
ARM - ARM Ltd. (название происходит от Advanced RISC Machines) —
британская корпорация, являющаяся одним из крупнейших разработчиков и
лицензиаров современной архитектуры 32-х разрядных RISC-процессоров,
специально ориентированных для использования в портативных и
мобильных устройствах (таких, как мобильные телефоны, персональные
органайзеры, пр.). ARM не является производителем микропроцессоров как
таковым, однако лицензирует собственную технологию третьим фирмам,
таким как Atmel, Cirrus Logic, Intel, Marvell, NXP, Samsung, Qualcomm,
Sony Ericsson, Texas Instruments которые, собственно, и воплощают её в
чипах.
ELF - (англ. Executable and Linkable Format — формат исполняемых и
компонуемых файлов) — формат файлов, используемый во многих UNIX-
подобных операционных системах. Каждый файл формата ELF имеет
специальный заголовок, в котором, в частности, указан адрес точки входа
(стартовый адрес) программы. Поля этого заголовка использует загрузчик
(ELF interpreter) для загрузки программы в оперативную память перед
исполнением.
Сервера – в контексте микроядерной архитектуры, является
синонимом слова модуль-сервера – самостоятельный исполнимый код,
реализующий определенный функционал. В микроядерной архитектуре,
некоторые части ядра, такие как свопинг и пейджинг, исполняются отдельно
от микроядра, и называются серверами.
Портирование - адаптация некоторой программы или её части, с тем
чтобы она работала в другой среде, отличающейся от той среды, под которую
она была изначально разработана. В случае ОС – изменение аппаратно
зависимых частей кода.
Конфигуратор – прикладная утилита, задача которой упорядочить
исходный код и подготовить его к компиляции, в соответствии с некоторой
конфигурацией. Так как ОС имеет большое количество вариантов сборки,
конфигуратор упрощает подготовку исходного кода.
-34-

35. Hurd — название операционной системы от проекта GNU,
использующей GNU Mach в качестве ядра.
Проект Debian — это ассоциация людей, общим делом которых
является создание свободной операционной системы. Созданая ими
операционная истема на ядре GNU/Linux называется Debian GNU/Linux, или
просто Debian. Так же ведётся работа по созданию систем Debian на других
ядрах,пример одной из них - the Hurd. Hurd - это набор серверов, которые
запускаются поверх микроядра (например, такого как Mach) и реализуют
разные возможности.
Виртуальная машина - эмулятор работы реального компьютера. На
виртуальную машину, так же как и на реальный компьютер, можно
устанавливать операционную систему, у виртуальной машины также
есть BIOS, оперативная память, жёсткий диск (выделенное место на жёстком
диске реального компьютера), могут эмулироваться периферийные
устройства. На одном компьютере может функционировать несколько
виртуальных машин.
L i b c - С т а н д а р т н о й б и бл и о т е ко й я з ы к а С и н а з ы в а е т с я
нестандартизованная коллекция заголовочных файлов и библиотек,
вызываемых как подпрограммы для реализации общих операций, таких как
обработка ввода/вывода и строк в языке программирования Си.
GNU - рекурсивный акроним от англ. GNU's Not UNIX — «GNU —
не UNIX») — свободная Unix-подобная операционная система,
разрабатываемая Проектом GNU.
Проект GNU — проект по разработке свободного программного
обеспечения (СПО). Проект был запущен известным программистом и
с т о р о н н и ко м С П О Р и ч а р д о м С т о л л м а н о м 2 7 с е н т я б р я 1 9 8 3
года в Массачусетском технологическом институте.
-35-

36. Приложения
В приложении представлены следующие материалы:
Приложение 1. Emach.c – Содержит в себе настройку таймера,
обработку прерываний, запуск микроядра. Существено доработанная
программа «Hello world» главы «3.2.1. Шаг1: Перенос микроядра с i386 на
ARM9» (пункт 3, 4). Компилируется в Linux………………………………… 45
Приложение 2. Makefile – makefile микроядра. Используется для
компиляции микроядра в Linux. Разработан в главе «3.2.1. Шаг1: Перенос
микроядра с i386 на ARM9» (пункт 1, 4)…………………………………… 48
Приложение 3. Os_imp.c – Содержит в себе все аппаратно-зависимые
части микроядра. Части этой программы используются в качетсве «Функций-
заглушек». Разработана в главе «3.2.1. Шаг1: Перенос микроядра с i386 на
ARM9» (пункт 1, 5)……………………………………………………………. 51
Приложение 4. Epfnet_link.S – Необходим для компиляции модуль-
сервера. Содержит в себе ассемблерный вызов функции main модуль-сервера.
Разработана в главе «3.2.1. Шаг1: Перенос микроядра с i386 на
ARM9» (пункт 7, 8)
………………………………………………………………………63
Приложение 5. Makefile epfnet – makefile модуль-сервера.
Используется для компиляции модуль-сервера в Linux. Разработан в главе
главе «3.2.1. Шаг1: Перенос микроядра с i386 на ARM9» (пункт 7, 8)…… 63
Приложение 6. Epfnet.c – Программа, разработаная в IAR,
используемая в качестве модуль-сервера. Содержит в себе элементы TCP/IP
стека, а так же драйвера MAC и PHY устройств. Компилируется и в IAR, и в
Linux. Разработана в главе «3.3.1. Шаг2: Драйвер Ethernet и TCP/IP
стек.» (пункт 1, 2)
…………………………………………………………………….. 63
Приложение 7. Tcp_ip.h – Заголовочный файл, содержащий в себе
описание структур заголовков TCP/IP пакетов. Разработана в главе «3.3.1.
Шаг2: Драйвер Ethernet и TCP/IP стек.» (пункт 2)…………………………. 106
Приложние 8. Алгоритм работы системного таймера GNU/Mach.
Схема работы была выявлена во время отладки механизма переключения
контекста………………………………………………………………………. 109
-36-

37. Приложение 9. Результаты тестирования ICMP Echo ping
запросами систем. Используется для проверки работоспособности системы
в главе «4.14. Тестирование системы ICMP запросами »……….............. 110
Приложение 10. Размеры emach и epfnet………………………....... 113
-37-