Главная страница
Контакты

    Басты бет


В. В. Казимир, П. В. Тарасенко, В. А. Кулешов создание модификации ос linux для встраиваемых систем на базе процессоров семейства r3000

жүктеу 133.2 Kb.



жүктеу 133.2 Kb.
Дата14.03.2019
өлшемі133.2 Kb.

В. В. Казимир, П. В. Тарасенко, В. А. Кулешов создание модификации ос linux для встраиваемых систем на базе процессоров семейства r3000




ПРОГРАМНО-ТЕХНІЧНІ КОМПЛЕКСИ
УДК 004.518

В.В. КАЗИМИР, П.В. ТАРАСЕНКО, В.А. КУЛЕШОВ



СОЗДАНИЕ МОДИФИКАЦИИ ОС LINUX ДЛЯ ВСТРАИВАЕМЫХ СИСТЕМ НА БАЗЕ ПРОЦЕССОРОВ СЕМЕЙСТВА R3000

Введение

В настоящее время значительно увеличился интерес к операционной системе Linux. Это обусловлено рядом преимуществ, среди которых главным есть то, что Linux является полномасштабной операционной системой с большим числом приложений. Также следует отметить и то, что она бесплатна и поставляется вместе с исходными кодами самой операционной системы и исходными кодами большинства ее приложений. Это позволяет развивать и модифицировать операционную систему, и, в частности, переносить ее на другие аппаратные платформы для использования во встроенных системах. В настоящее время наметилась тенденция переноса операционной сиcтемы Linux на такие аппаратные платформы, как MIPS, ARM, Motorola, Intel i960 и другие микропроцессорные ряды [1]. Эта тенденция обусловлена постоянно увеличивающимся спросом на компактные (встроенные) системы; при этом сложность решаемых ими задач постоянно растет и наилучшим выходом есть использование в качестве базы одной из существующих операционных систем - Linux. Поэтому задача переноса операционной системы Linux на другие аппаратные платформы является актуальной.


1. Постановка задачи
В данной статье рассматривается задача переноса операционной системы Linux на заданную аппаратную платформу. Для конкретизации последней примем платформу на базе процессора семейства R3000 [2] с архитектурой построения MIPS [3].

Исходя из особенностей этой платформы, требуется переработать ядро Linux с учетом следующих аппаратных ограничений:



  1. аппаратная платформа на базе процессора семейства R3000 без MMU (Memory Management Unit) [4];

  2. объем ОЗУ 8Mb, из которого операционная система Linux может использовать не более 4Mb;

  3. объем ПЗУ 2Mb, из которого операционная система Linux может использовать не более 1,5Mb;

  4. обеспечить поддержку USB [5].

2

Рис. 1. Общая архитектура операционной системы Linux


. Технология модификации Linux

Как известно, общая архитектура операционной системы Linux включает ядро, набор системных утилит и пользовательские программы (рис. 1). Набор системных утилит и программы пользователя компилируются с помощью библиотеки LibC [6], реализация которой зависит от аппаратных особенностей используемого процессора (в основном это зависит от способа обращения задачи к ядру). Главная цель библиотеки LibC - это соответствие спецификации POSIX [7], что должно обеспечить совместимость программ для операционной системы Linux на уровне исходных кодов на языках С/C++.

Спецификация POSIX – это набор стандартов [8], описывающих операционные системы семейства UNIX [9] (к которому принадлежит и операционная система Linux). Базовая версия спецификации POSIX состоит из следующих технических стандартов:


  1. основные понятия (XBD);

  2. оболочка и утилиты (XCU);

  3. системные интерфейсы (XHS);

  4. практические рекомендации (Informative).

Исходя из всего вышеперечисленного, становится очевидной главная цель, которую необходимо достигнуть при переносе операционной системы Linux с одной аппаратной платформы на другую, – это максимальное соответствие спецификации POSIX. Поэтому особое внимание следует определить библиотеке LibC, которая должна соответствовать стандарту системных интерфейсов для операционных систем семейства UNIX (XHS).

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



  1. выбор базового ядра;

  2. анализ структуры ядра и определение архитектурно зависимых частей требующих модификации;

  3. определение ограничений ядра в связи с отсутствием MMU;

  4. модификация ядра;

  5. модификация библиотеки программиста LibC;

  6. модификация системных утилит.

2.1. Выбор базового ядра ОС Linux для модификации


В настоящее время существует версия ОС Linux и для аппаратных платформ на базе процессора R3000. Однако эти решения предусматривают использование аппаратного решения для преобразования виртуальных адресов памяти в реальные – Memory Management Unit. Однако существует ряд решений, позволяющих перестроить операционную систему Linux так, что необходимость в MMU отпадет. Среди всех этих решений следует отметить как базовые решения для таких аппаратных платформ: Motorola M68EZ328, Motorola M68328, Motorola M68EN322, ARM7TDMI, ETRAX, Intel i960, Atari 68k [10]. Как правило, каждое из таких решений включает следующие компоненты:

  1. ядро операционной системы Linux;

  2. набор системных и файловых утилит, базовый набор программ;

  3. библиотека программиста LibC;

  4. вспомогательные утилиты (например, создание образа диска, сжатие бинарного образа ядра и линкование к нему загрузчика и т.д.);

  5. компиляторы C и ассемблеры, линковщики для целевой аппаратной платформы.

Все эти решения отличаются от базовой версии операционной системы Linux следующими изменениями в ее структуре исходных кодов:

  1. добавлены новые правила для программ компилятора и линковщика;

  2. в программу конфигурации ядра добавлены опции выбора новой аппаратной платформы и ее доступной конфигурации;

  3. добавлены файлы с исходным кодом для аппаратно зависимых компонентов ядра, расположенных в виде отдельного дерева каталогов в подкаталоге исходных кодов операционной системы Linux ./arch;

  4. часть архитектурно независимого кода на языке С, в которую вносятся изменения, располагается в дополнительных каталогах (например, ./mm_nommu);

  5. библиотека программиста представляется в виде отдельной версии;

  6. бинарные утилиты представляются в виде отдельной версии.

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

Среди всех существующих версий ядра операционной системы Linux, модифицированных для работы без MMU, наиболее развита версия под названием uClinux [11]. К преимуществам этой версии следует отнести:



  1. наличие исходного кода для процессоров семейства R3000;

  2. реализацию ядра для работы без MMU;

  3. большое количество свободно доступных версий ядра, библиотек и утилит;

  4. реализацию последней версии ядра 2.4.

Исходя из необходимости поддержки USB, наилучшим решением будет выбор версии uClinux 2.4, поскольку она базируется на наиболее новой на сегодняшний день версии ядра операционной системы Linux - 2.4.

2.2. Анализ внутренней архитектуры ядра uCLinux 2.4


В

Рис. 2. Внутренняя архитектура ядра

операционной системы uCLinux 2.4
связи со все возрастающим интересом к операционной системе Linux, в частности, к архитектуре ее ядра, есть работы [12], ориентированные на описание структуры ядра операционной системы Linux, а также принципов работы и взаимодействия всех ее компонентов. В большинстве источников внутренняя архитектура ядра операционной системы Linux представляется четырьмя главными компонентами: менеджер задач, менеджер памяти, файловая система и подсистема взаимодействия между процессами. Все эти компоненты взаимосвязаны друг с другом, и каждая из компонент выполняет свой круг задач. Ядро ядра операционной системы uCLinux 2.4 имеет такую же структуру (рис. 2.).

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


2.2.1. Менеджер задач


Процесс есть однократное выполнение процедуры. Это значит, что каждый процесс живет лишь временно; есть момент, когда он «рождается», и есть момент, когда он «гибнет», завершив свою работу. В каждой современной операционной системе есть понятие процесса или задачи [13]. Необходимость в этом понятии возникает всякий раз, когда система должна отвечать на определенные запросы через определенные промежутки времени. Время ответа может быть различным – от нескольких секунд до нескольких миллисекунд при регистрации данных или при управлении процессом. Поскольку момент поступления этих запросов не предсказуем и не управляем системой, нельзя сказать, что последовательность операций определяется только самой системой.

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

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

П


Рис. 3. Внутренняя архитектура менеджера задач


ри этом возникает необходимость в управлении процессами. Так, требуется разделять время процессора (или нескольких процессоров в многопроцессорной системе) между процессами и управлять их состояниями. Все эти функции в операционной системе Linux выполняет менеджер задач (рис. 3.).

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



  1. передача управления процессу с наивысшим приоритетом;

  2. создание нового процесса;

  3. гибель процесса;

  4. изменение приоритетов процессов.

В операционной системе Linux есть понятие контекста процесса. Под контекстом процесса следует понимать всю совокупность данных, относящихся к процессу, таких как значения регистров процессора, стека, области памяти процесса, используемых ресурсов системы, а также специальной информации о процессе. Контекст процесса хранится в специальной структуре task_struct [12]. Передача управления от одного процесса к следующему осуществляется переключением контекста процесса; при этом указатель на текущий процесс current будет указывать на контекст текущего процесса.

Исходя из вышесказанного, перечислим компоненты в менеджере задач, которые содержат аппаратно зависимые участки программного кода, а, значит, требуют изменения при переносе Linux на другую аппаратную платформу:



  1. Порождение нового процесса. При этом требуется установить контекст процесса в начальное состояние. Также возникает родственная задача загрузки программы в память - функция exec(). В этом случае требуется создать загрузчик программы в формате ELF [14] (и других форматов, если это требуется), реализация которого большей частью определяется аппаратной архитектурой выбранной платформы.

  2. Переключение контекста задачи. Эта функция выполняется в функции scheduler(), которая содержит аппаратно зависимый участок кода для переключения контекста процесса в виде макроса на ассемблере switch_to().

  3. Инициализация нулевой задачи idle(). Требуется установить контекст процесса в начальное состояние.

  4. Изменение структуры контекста процесса (а также последовательности его сохранения и восстановления) с учетом аппаратной архитектуры.

2.2.2. Подсистема взаимодействия между процессами

П


Рис. 4. Внутренняя архитектура подсистемы взаимодействия между процессами


одсистема взаимодействия между процессами (IPC – Inter Process Communication) предназначена для решения следующего круга задач:

  1. синхронизация процесса выполнения задач, реализованная с помощью семафоров;

  2. обмен данными между задачами, реализованный с помощью сообщений.

Внутренняя архитектура подсистемы взаимодействия между процессами представлена на рис. 4.

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

В

Рис. 5. Внутренняя архитектура менеджера памяти


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

2.2.3. Менеджер памяти


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

  1. изменение уровня страничной адресации для работы с реальными адресами (без MMU);

  2. изменение уровня областей памяти, поскольку при реальной адресации памяти область памяти следует выделять из страниц, которые непрерывно следуют друг за другом;

  3. удаление функции brk(), поскольку нет возможности менять размер области памяти после ее выделения (так как область памяти должна состоять из непрерывно следующих друг за другом страниц).

2.2.4. Файловая система


А

Рис. 6. Внутренняя архитектура файловой системы


рхитектура файловой системы представлена на рис. 6. Традиционно для операционных систем класса
Unix файловая система состоит из Виртуальной файловой системы (VSF) и из множества драйверов для всех типов поддерживаемых файловых систем. Виртуальная файловая система предоставляет единообразный доступ ко всем ресурсам системы (все ресурсы системы представляются в виде иерархического дерева с началом root, которое содержит файлы устройств, виртуальные файлы системной статистики – каталог /proc и файлы, и каталоги присоединенных файловых систем (mount)). Виртуальная файловая система есть универсальный и аппаратно независимый механизм.

Файловая система содержит драйверы файловых систем, которые тоже являются аппаратно независимыми.


2.3. Ограничения функциональности ядра операционной системы uCLinux 2.4


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

  1. нет защиты памяти, и процессы могут адресовать всю память, включая память ядра;

  2. неэффективное использование памяти, поскольку при выделении блока памяти требуется выделять последовательность страниц, непрерывно следующих друг за другом. Следовательно, память не будет использоваться полностью;

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

  4. отсутствие функции brk(). Поскольку область памяти выделяется как непрерывная последовательность страниц, нельзя изменить размер области памяти;

  5. замена функции fork() на vfork(). Нельзя создать копию процесса с теми же адресами (как в случае с виртуальной адресацией), поэтому при порождении потомка копируется только стек, но не программа и области данных.



2.4. Особенности переноса ядра операционной системы uCLinux 2.4

При переносе ядра операционной системы uClinux на платформу процессора R3000 возник ряд дополнительных задач, обусловленный изменениями в архитектуре ядра:



  1. Разработка загрузчика ELF файлов. Это обусловлено тем, что бинарный образ программы в памяти, ее стека, переменных окружения, способа передачи параметров, формата файлов программы определяется аппаратной платформой. Следовательно, загрузчик ELF файлов для платформы x86 будет отличаться от загрузчика для платформы R3000.

  2. Разработка библиотеки программиста LibC. Необходимость в разработке собственной версии библиотеки программиста вытекает из особенностей целевой аппаратной платформы: способ вызова ядра, способ передачи и получения параметров в/из ядра. Поэтому существует много версий библиотеки программиста LibC.

  3. Разработка интерпретатора команд (shell). Создание собственного интерпретатора команд обусловлено ограничениями в используемой памяти. Так, использование полноценного интерпретатора команд повлекло бы за собой необходимость в 500 Кбайтах памяти для каждого интерпретатора. Поэтому разработка упрощенного интерпретатора команд размером в 32 Кбайта позволяет более экономно использовать память системы.

  4. Разработка набора командных файлов и программ для инициализации системы (каталог /rc.d, init, login, и т.д.). Необходимость в разработке набора программ и командных файлов для инициализации системы определяется общим принципом старта операционной системы Linux:

    1. распаковывание сжатого бинарного образа ядра операционной системы Linux в память;

    2. передача управления разжатому бинарному образу ядра операционной системы Linux;

    3. инициализация аппаратуры;

    4. инициализация системы;

    5. запуск нулевого (idle) и первого процесса (init);

    6. первый процесс запускает программу init с корневого диска;

    7. программа init проводит инициализацию системы в соответствии с файлом inittab –запускаются программы login на указанные консоли, программы конфигурации, системные программы и т.д.


3. Полученные результаты

В результате проведенных исследований разработана операционная система Plinux. Операционная система Plinux включает следующие компоненты:



  1. загрузчик ядра (разжимает сжатое ядро и загружает его в память);

  2. ядро;

  3. библиотеку программиста LibC;

  4. набор системных утилит;

  5. упрощенную версию интерпретатора команд shell;

  6. набор тестовых программ и командных файлов для тестирования функциональности ядра;

  7. образ корневого диска с набором командных файлов и программ для инициализации;

  8. командные файлы, создающие бинарный файл с сжатым образом диска для файловых систем ROMFS и EXT2FS;

  9. командные файлы, создающие бинарный файл со сжатым ядром и дисками для ПЗУ.

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



  1. файловые системы RAMFS, ROMFS, EXT2FS, CRAMFS, DEVFS, PROCFS;

  2. драйверы устройств символьного доступа SERIAL, CONSOLE, PTY, TTY, MISC, RANDOM, RAW, WATCHDOG, PIPE;

  3. драйверы устройств блочного доступа RAMDISK, LOOP;

  4. форматы исполняемых фалов ELF no PIC, ELF PIC, SCRIPT;

  5. менеджер памяти, функционирующий без MMU;

  6. поддержка процессора семейства R3000;

  7. симуляция ряда команд процессора, не реализованных в нем аппаратно – RIS (Reserved Instruction Set) -умножения, деления, чтения / записи по невыровненному адресу.

    Разработанная операционная система имеет следующие параметры:



  8. версия прототипа ядра – Linux 2.4;

  9. размер сжатого ядра с сжатыми дисками в ПЗУ – 520 Кбайт;

  10. размер разжатого ядра после инициализации в ОЗУ – 1.5 Мбайт;

  11. количество свободной памяти для пользовательских задач – 6.5 Мбайт.

Выводы


Разработанная версия операционной системы Linux позволит упростить и ускорить разработку программного обеспечения для устройств на базе процессоров семейства R3000. Разработка программного обеспечения для операционной системы Plinux может осуществляться на языке программирования C, причем с учетом стандарта POSIX. Соблюдение стандарта POSIX в операционной системе Plinux позволяет вести разработку и отлаживать программы на любой операционной системе семейства Linux, а затем без изменений компилировать исходные коды на языке C совместно с разработанной библиотекой программиста LibC для использования в операционной системе Plinux.

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



СПИСОК ЛИТЕРАТУРЫ


  1. http://www.uclinux.org/ports - uClinux -- Embedded Linux/Microcontroller -- uClinux: Ports!.-2002.

  2. Farquhar E., Spatz M. The MIPS programmer’s hand book.- Morgan Kaufman Publisher Inc, 1994.

  3. http://www.mips.com/ /MIPS technologies home page.-2002.

  4. http://www.cknow.com/ckinfo/acro_m/mmu_1.shtml /MMU - Memory Management Unit.-2001.

  5. http://www.usb.org/ /USB (Universal Serial Bus) home page.-2002.

  6. http://www.gnu.org/software/libc/libc.html /GNU C Library.-2001.

  7. http://std.dkuug.dk/JTC1/SC22/WG15/ /The official home of JTC1/SC22/WG15 - POSIX!.-2002.

  8. http://www.unix-systems.org/version3/ /The Single UNIX Specification Version 3 - incorporating IEEE Std 1003.1-2001 and integrating the industry's Open Systems standards.-2001.

  9. http://www.unix.org/what_is_unix.html /The UNIX System.-2002.

  10. http://www.uclinux.org/description/ /uClinux is a derivative of Linux 2.0 kernel intended for microcontrollers without Memory Management Units (MMUs).-2002.

  11. http://uclinux.org/ /uCLinux - Embedded Linux/Microcontroller Project.-2002.

  12. Beck M., Bohme H., Kunitz U. Linux kernel internals (second edition).- Addisson-Wesley GmbH, 1999.

  13. Введение в операционные системы / И.Х. Зусман / Под ред. В.В. Мартынюк: Пер.на русский.-М.: Мир, 1975. Colin A.J.T. Introduction to operating systems.- MacDonald/American Elsevir Computer Monographs, 1971.

  14. http://www.cs.ucdavis.edu/~haungs/paper/node10.html - The Executable and Linking Format (ELF).-1998.




 Литвинов В.В., Казимир В.В., Дяченко В.В. 2002 45

ISSN 1028-9763. Математичні машини і системи, 2002, № 3




  • Введение
  • 2.1. Выбор базового ядра ОС Linux для модификации
  • 2.2. Анализ внутренней архитектуры ядра uCLinux 2.4
  • 2.2.1. Менеджер задач
  • 2.2.2. Подсистема взаимодействия между процессами
  • 2.2.3. Менеджер памяти
  • 2.2.4. Файловая система
  • 2.3. Ограничения функциональности ядра операционной системы uCLinux 2.4
  • Выводы
  • СПИСОК ЛИТЕРАТУРЫ

  • жүктеу 133.2 Kb.