Сосуществование Linux и RTOS на единой аппаратной платформе

Dmitriy Gorokh, Promwad, Minsk, Belarus

LVEE 2012

During the last years Linux have finally been recognized as an established embedded OS. The reasons of embed Linux into various devices are obvious: Linux is free, it has tremendous amount of free and useful applications, it supports decent hardware, it is POSIX compliant and it has both community and commercial support. However, not every user application can be easily moved from RTOS to Linux.

С каждым годом ОС Linux набирает популярность как ОС для встраиваемых систем. Причины тому очевидны: обладая свободной лицензией, ядро Linux вкупе с многочисленными свободными приложениями и библиотеками обеспечивает поддержку широкого спектра аппаратуры (включая современные системы-на-кристалле), устоявшийся POSIX совместимый API и хорошую поддержку как со стороны сообщества, так и от коммерческих организаций. Однако не все приложения могут быть беспрепятственно перенесены с привычных систем реального времени (ОСРВ) на Linux. Помимо очевидных причин, таких как нехватка ОЗУ или ПЗУ для загрузки и полноценной работы Linux, можно отметить следующие причины:
1. От пользовательского приложения требуется работа в режиме жёсткого реального времени
2. Аппаратные прерывания должны обрабатываться с минимальной задержкой и джиттером
3. Система должна быть максимально предсказуемой и надёжной
4. Накладные расходы, связанные с работой ОС, должны быть минимальными
Один из возможных способов удовлетворить всем этим требованиям, при этом не отказываясь от использования Linux – использовать многоядерные процессоры для одновременного запуска ОСРВ и Linux. При этом критически важные пользовательские приложения будут работать под ОСРВ на основном ядре процессора, а второстепенные (такие, как пользовательский интерфейс или сетевой стек) – под Linux на дополнительном ядре. Такая архитектура особенно примечательна при использовании гетерогенных мультипроцессорных систем, в которых процессорные ядра существенно отличаются по сложности, вычислительной мощности и энергопотреблению (например ARM Cortex-A9 и ARM Cortex-M4). Имея полный контроль над системным ПО, запускаемым на каждом ядре, можно добиться близкой к максимальной энергоэффективности для заданной аппаратной флатформы.
При использовании ОСРВ и Linux на одном процессоре возникают две проблемы: разделение аппаратных ресурсов и межядерное взаимодействие.
fig1
Разграничивание устройств ввода-вывода между несколькими ОС является довольно сложной задачей, которая решается, например, введением в архитектуру гипервизора, виртуализирующего аппаратные ресурсы. Обычно в геторогенных системах аппаратные ресурсы жёстко закреплены за процессорными ядрами, поэтому как правило единственным разделяемым устройством является ОЗУ. Обе ОС необходимо сконфигурировать таким образом, чтобы они использовали разные регионы физической памяти.
Проблема межядерного взаимодействия на низком уровне решается в зависимости от предоставляемых аппаратных средств. В общем случае для этого выделяется небольшой регион разделяемой памяти. Для оповещения ядер обычно существует возможность генерации программного прерывания.
Multicore Assotiation (MCA) предлагает стандартизированный API для реализации интерфейсов высокого уровня: MCAPI. Его целью является унификация межпроцессорного взаимодействия между различными ОС, что позволяет максимально отвязать программную реализацию от аппаратуры и ОС-специфичных программных модулей.
fig2
MCAPI не предъявляет жёстких требований к аппаратуре и ОС, и спроектирован так, чтобы портирование было максимально простым и понятным. В настоящий момент существует референсная реализация MCAPI от Mentor Graphics, которая называется OpenMCAPI. OpenMCAPI может работать под Linux и Nucleus. Портирование под другие ОС не должно составить больших трудов.
Данная архитектура была проверена на Freescale SoC P1020, на базе которого разрабатывался индустриальный компьютер для контроля электрических подстанций.