Дополнительные возможности ОС

Разработка BSP для новой модификации платы

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

• Программа начальной загрузки (bootloader)
• Уровень адаптации OEM (OAL)
• Драйверы устройств, специфические для платы

Процесс создания BSP включает следующие задачи:

• Разработку программы начальной загрузки
• Разработку OAL
• Создание драйверов устройств
• Модификацию конфигурационных файлов образа времени выполнения

Если BSP отсутствует, то можно создать новый пакет или клонировать существующий начальный BSP, который спроектирован для аналогичного оборудования. Таблица 10.1 показывает элементы, которые обычно содержатся в пакете поддержки платы (BSP).

Разработка начального загрузчика для нового устройства

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

Рис. 10.2. Последовательность начального запуска для CE

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

1. Начальный загрузчик ( Bootloader ) инициализирует оборудование, переходит к базе exe для oal.exe (StartUp)
2. Oal.exe::Startup вызывает KernelInitialize с OEMAddressTable, если потребуется ( nkldr.lib )
3. Oal.exe::KernelInitialize задает MMU, и т.д., переходит к точке входа kernel.dll
4. Kernel.dll вызывает oal.exe:: OEMInitGlobals (oemmain.lib)
5. Oal.exe::OEMInitGlobals изменяет указатели на глобальные структуры
6. Kernel.dll обращается к точке входа kitl.dll (KitlDllMain в kitlcore.lib), чтобы изменить указатели на глобальные структуры для KITL

Начальный загрузчик может получить образ времени выполнения несколькими различными способами, включая загрузку его через кабельное соединение, такое как Ethernet, универсальную последовательную шину (USB), или последовательное соединение. Начальный загрузчик может также загружать ОС из локального устройства памяти, такого как флэш-устройство, или жесткий диск. Начальный загрузчик может сохранять образ времени выполнения для будущего использования в RAM (ОЗУ) или в энергонезависимой памяти, такой как флэш-память, электрически стираемая программируемая память только для чтения (EEPROM), или некоторое другое устройство памяти.

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

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

Хотя каждый начальный загрузчик отличается выполняемыми задачами, и способом их выполнения, наиболее общий начальный загрузчик загружает образ времени выполнения через Ethernet в RAM на целевом устройстве. Несколько примеров имеется в документации ОС и примерах кода.

Модификация адаптации уровня OEM

Уровень адаптации (OAL) Производителя оригинального оборудования (OEM) операционной системы создается для изоляции и минимизации изменений операционной системы необходимых для переноса ОС на каждую новую аппаратную платформу. Как видно на рисунке 10.3, OAL содержит самый нижний уровень процедур, которые взаимодействуют непосредственно с оборудованием системы.

Ядро использует процедуры OAL для общения с оборудованием. Транспортный Уровень Интерфейса Ядра (Kernel Interface Transport Layer - KITL) используется системой разработки для коммуникации с целевым устройством. Уровень адаптации OEM (OAL) является уровнем кода, который логически располагается между ядром CE и оборудованием целевого устройства. Физически OAL соединяется с библиотеками ядра для создания исполняемого файла ядра.

Рис. 10.3. Перенос CE на новое целевое устройство требует изменений в процедурах OAL

Средства коммуникации OAL между операционной системой (ОС) и целевым устройством включают код для обработки прерываний, таймеров, управления питанием, абстрагирования шины, базового кода управлением В/В (IOCTL), и т.д.

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

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

Уровень адаптации OEM (OAL) производственного качества, доступный в CE, упрощает и сокращает процесс разработки OAL. Он предоставляет улучшенный уровень разбиения на компоненты через библиотеки кода, структуры каталогов, которые поддерживают повторное использование кода, централизованные конфигурационные файлы, и согласованную архитектуру на семействах процессоров и аппаратных платформах.

Инфраструктура процессора и аппаратной платформы, предоставляемая OAL производственного качества, позволяет разработать минимальное базовое ядро CE, образ Tiny Kernel, за счет небольших усилий по разработке.

OAL производственного качества предоставляет следующие усовершенствования относительно предыдущей модели OAL:

• Обычное множество специфических для процессора компонентов
• Программные компоненты OAL
• Стандартную структуру каталогов
• Соглашения для разработки BSP

В CE можно клонировать существующий BSP. Однако каталог BSP ..\WINCE600\Platform\<Название аппаратной платформы > содержит файлы минимального кода, и они являются в основном конфигурационными файлами. Большая часть файлов кода BSP находится в каталоге ..\WINCE600\ Platform\Common и не должна модифицироваться, если только реализация аппаратной платформы не отличается существенно от реализации CE. Мы теперь ссылаемся на программные компоненты, как на библиотеки.

Библиотеки OAL являются совокупностью функциональных, статических библиотек, которые можно собирать по модульному принципу для создания OAL или начального загрузчика. Отдельные библиотеки соответствуют множеству API, общему для всех архитектур ЦП. Аппаратная библиотека организована и реализована согласованным образом, в соответствии с аппаратной архитектурой, номером компонента, и функциональным уровнем, чтобы помочь определить уровень требуемой аппаратной поддержки, и для создания самодокументированной структуры каталогов.

OAL производственного качества позволяет использовать согласованное оборудование на семействе процессоров. Для выполнения этого аппаратная библиотека реализует базовые функции для OAL, которые взаимодействуют на уровне микросхемы. Операции на уровне платы, такие как маршрутизация IRQ или взаимодействия связующей логики, остаются в каталоге ..\WINCE600\Platform\<Hardware Platform Name>, но они упрощаются и абстрагируются на всех архитектурах, где возможно.

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

Рисунок 10.4 показывает, как OAL, начальный загрузчик, драйверы, и конфигурационные файлы образа времени выполнения взаимосвязаны с BSP и стандартной платой разработки (SDB) или аппаратной платформой.

Рис. 10.4. Структура BSP