Embedded Linux System Design and Development
Based upon the authors’ experience in designing and deploying an embedded Linux system with a variety of applications, Embedded Linux System Design and Development contains a full embedded Linux system development roadmap for systems architects and software programmers. Explaining the issues that arise out of the use of Linux in embedded systems, the book facilitates movement to embedded Linux from traditional real-time operating systems, and describes the system design model containing embedded Linux.
This book delivers practical solutions for writing, debugging, and profiling applications and drivers in embedded Linux, and for understanding Linux BSP architecture. It enables you to understand: various drivers such as serial, I2C and USB gadgets; uClinux architecture and its programming model; and the embedded Linux graphics subsystem. The text also promotes learning of methods to reduce system boot time, optimize memory and storage, and find memory leaks and corruption in applications.
This volume benefits IT managers in planning to choose an embedded Linux distribution and in creating a roadmap for OS transition. It also describes the application of the Linux licensing model in commercial products.
Table of Contents
Introduction. Getting Started. Board Support Package. Embedded Storage. Embedded Drivers. Porting Applications. Real-Time Linux. Building and Debugging. Embedded Graphics. uClinux.
Глава 2, Начало работы
Эта глава делится на три части. Первая часть описывает разные архитектуры встраиваемых ОС и сравнивает их с архитектурой Linux. Затем дан краткий обзор ядра и пользовательского пространства Linux. Вторая часть главы объясняет последовательность запуска Linux. Последняя часть рассказывает об инструментах для кросс-разработки.
2.1 Архитектура встраиваемого Linux
ОС Linux является монолитной. Обычно операционные системы поставляются в трёх вариантах: в режиме исполнения реального времени, монолитные и микроядра. В основе такой классификации лежит то, как ОС использует аппаратные средства для защиты.
2.1.1 Выполнение в режиме реального времени
Традиционные ОС исполнения в режиме реального времени предназначены для процессоров без MMU. На этих операционных системах всё адресное пространство плоское или линейное, без защиты памяти между ядром и приложениями, как показано на Рисунке 2.1. Рисунок 2.1 Архитектура традиционной RTOS. На Рисунке 2.1 показана архитектура выполнения реального времени, где основное ядро, подсистемы ядра и приложения совместно используют одно и то же адресное пространство. Эти операционные системы используют немного памяти и имеют небольшой размер, так как ОС и приложения сгруппированы в единый образ. Как следует из названия, они по своей природе работают в режиме реального времени, потому что нет накладных расходов системных вызовов, передачи сообщений или копирования данных. Однако, поскольку ОС не обеспечивает защиты, всё программное обеспечение, работающее в системе, должно быть надёжным. Добавление нового программного обеспечения становится не очень приятным действием, потому что оно должно быть тщательно протестировано, чтобы не обрушить всю систему. Кроме того, очень трудно добавлять приложения или модули ядра динамически, так как система должна быть выключена. Под эту категорию подпадают большинство патентованных и коммерческих RTOS. В течение последнего десятилетия встраиваемые системы были свидетелями сдвига
| Глава 2, Начало работы | 2 |
парадигмы по отношению к архитектуре.Традиционная модель встраиваемой системы основана на жёстко контролируемом программном обеспечении, работающем на платах устройств; стоимость памяти и размер запоминающего устройства больше ограничивались количеством программ, которые могли быть запущены в данной системе. Надёжность работы в режиме реального времени, использующей плоскую модель памяти, достигалась за счёт процесса тщательного тестирования. Однако, так как цены на оперативную и флеш память упали, а вычислительная мощность стала дешевле, встраиваемые системы начали иметь всё больше и больше программного обеспечения. И многое из этого программного обеспечения было не только системным программным обеспечением (таким как драйверы или сетевой стек), но и приложениями. Так программное обеспечение тоже начало становиться фактором, влияющим на продажи встроенных систем, которые традиционно оценивались главным образом по аппаратным возможностям. Работа в режиме реального времени не подходит для крупномасштабных интеграций программного обеспечения; поэтому были серьёзно рассмотрены альтернативные модели с целью получения большего количества программного обеспечения, работающего в системе. Двумя такими моделями для операционных систем являются монолитные и микроядерные модели. Это подходит для процессоров с MMU. Заметим, что если сам процессор не имеет MMU, то ОС не имеет альтернативы, кроме как обеспечить плоскую модель адресации. (uClinux, происходящий от Linux, работает на процессорах без MMU и обеспечивает плоское адресное пространство.)
2.1.2 Монолитные ядра
Монолитные ядра имеют разграничение между пространством пользователя и пространством ядра. Когда программное обеспечение работает в пространстве пользователя, оно обычно не может получить доступ к системному оборудованию и не может выполнять привилегированные инструкции. Используя специальные точки входа (предоставляемые оборудованием), приложение может войти из пользовательского пространства в режим ядра. Программы пространства пользователя работают с виртуальными адресами, так что они не могут повредить память другого приложения или ядра. Тем не менее, компоненты ядра используют общее адресное пространство, так что плохо написанный драйвер или модуль может привести к падению системы. На Рисунке 2.2 показана архитектура монолитных ядер, где ядро и его подмодули используют общее адресное пространство, и где приложения имеют свои обособленные адресные пространства.
3 Разработка и внедрение системы на встраиваемом Linux Рисунок 2.2 Архитектура монолитного ядра. Монолитные ядра могут поддерживать большой набор программного обеспечения. Любая ошибка в приложении вызовет только то, что это приложение будет плохо себя вести, не вызывая краха системы. Кроме того, приложения могут быть добавлены в работающую систему без выключения этой системы. Большинство операционных систем UNIX являются монолитными.
2.1.3 Микроядра
Такие ядра подвергались многочисленным исследованиям, особенно в конце 1980-х, и считались наилучшими по отношению к принципам разработки ОС. Тем не менее, переход от теории к практике привёл к слишком большому числу узких мест; очень немногие из таких ядер были успешными на рынке. Микроядро использует небольшую ОС, которая предоставляет только основной сервис (планирование, обработка прерываний, передача сообщений), а остальная часть ядра (файловая система, драйверы устройств, сетевой стек) работает в качестве приложений. По отношению к использованию MMU, ядра реального времени формируют одну крайность, работая без использования MMU, в то время как микроядра находятся на другом конце, предоставляя подсистемам ядра индивидуальное адресное пространство. Ключевым принципом микроядра является придумать чётко определённые интерфейсы для взаимодействия с ОС, а также надёжные схемы передачи сообщений. Рисунок 2.3 показывает архитектуру микроядра, где подсистемы ядра, такие как сетевой стек и файловые системы, имеют отдельное адресное пространство, аналогично приложениям. Микроядра требуют надёжных схем передачи сообщений. Работа в режиме реального времени и модульность обеспечиваются только в случае передачи сообщений должным образом. Микроядра активно обсуждались, особенно по отношению к монолитным ядрам. Одна из таких широко известных дискуссий была между создателем Linux, Линусом Торвальдсом и Эндрю Танненбаумом, который был создателем Minix ОС (микроядро). Дискуссия, возможно, не представляет очень большого интереса для читателя, который хочет разобраться во встраиваемом Linux.