Я планирую запустить RTOS, например Nuttx, как процесс другой RTOS, например FreeRTOS, чтобы задачи freertos и Nuttx, работающие как задача Freertos, сосуществовали.
Будет ли это осуществимой реализацией, учитывая, что базовое оборудование представляет собой одноядерный процессор ARM Cortex A8? Какие изменения могут потребоваться, если реализация не основана на концепции ВМ?
Вкратце, ваше требование - позволить ГОСТЕВОЙ ОСРВ полностью работать в рамках базовой ОСРВ. Первый ответ - использовать расширение виртуализации, но у процессора A8 этого нет, поэтому этот вариант будет исключен. Без расширений виртуализации вам придется прибегнуть к одному из следующих методов, что потребует значительных изменений кода.
Вариант 1. Перенос API вашей гостевой ОС
Возьмите все API вашей ОС GUEST и замените их реализацию, чтобы она имитировала требуемое поведение API, используя API HOST OS. Технически теперь ваша ОС GUEST не будет иметь планировщика и будет уменьшена до уровня переноса поверх ОС HOST. Этот метод используется компаниями, когда им нужно, чтобы их программные решения работали с несколькими ОСРВ. Они напишут свое программное решение на основе ОСРВ. Когда к ним приходит заказчик с требованием запустить программное обеспечение в своей ОСРВ, они просто переносят реализации API ОСРВ в ОСРВ заказчика.
Вариант 2 - паравиртуализация
Пользователь гостевой ОСРВ и пространство ядра должны работать внутри пользовательского пространства ОСРВ хоста. Разобьем задачу на несколько частей.
Обработка привилегированных инструкций
Когда ваша гостевая ОС при выполнении в «режиме ядра» пытается выполнить привилегированную инструкцию, это вызовет прерывание инструкции undef. Вы должны изменить обработчик прерывания инструкции undef вашего ядра хоста, чтобы перехватить / перехватить эти инструкции и действовать в соответствии с ними. Каждая привилегированная инструкция должна быть перехвачена / перехвачена и «смоделирована». Есть некоторые инструкции, которые не будут перехватываться, но должны быть обработаны путем изменения кода. Например. Если код вашего ядра читает CPSR для подтверждения режима выполнения, CPSR скажет, что это режим пользователя. (Эта инструкция не вызовет прерывания инструкции, поэтому вы не сможете следовать ловушке и моделировать модель. Единственный способ - идентифицировать, искать и заменять эти инструкции в кодовой базе вашей ОС GUEST.)
Блок управления памятью
Если произойдет нарушение привилегий, в ОС вашего хоста будет запущено прерывание данных. Он должен быть перенаправлен в вашу гостевую ОС.
Прерывания
Вам придется заменить драйвер контроллера прерывания вашей ОС GUEST фиктивными вызовами SVC, которые будут вызывать вашу ОС HOST для настройки прерываний.
Таймеры
Вам придется изменить драйвер таймера GUEST, чтобы учесть «потерянные» тики, когда вы выполняли задачи HOST OS.
Драйверы оборудования
Все остальные драйверы оборудования, используемые вашей ОС GUEST, должны быть изменены, чтобы разрешить совместное использование устройств между GUEST и HOST.
Планировщики
Планировщик ОС GUEST теперь работает внутри (и, следовательно, находится во власти) другого планировщика (Планировщик ОС HOST).
Это возможно. Вам необходимо разделить ресурсы: память, таймеры, IRQ и т. Д. Чтобы ОС «хоста» (FreeRTOS) даже не «знала» о ресурсах, используемых ОС «гостя» (Nuttx).
Для Cortex-A8 вы можете использовать IRQ для FreeRTOS и FIQ для GuestOS. Это позволит вам не перезаписывать контроллер IRQ (но, опять же, убедитесь, что Host не контролирует FIQ после запуска GuestOS).
И некоторые изменения могут потребоваться для переключения контекста: вам нужно различать переключение контекста Host-Host, Host-Guest (и Guest-Host) и переключение контекста Guest-Guest.
Хотя это не прямой ответ на ваш вопрос, решите эту проблему на уровне дизайна, разделите код, который зависит от оборудования (создайте API), и сделайте код уровня приложения независимым от базовой ОС или среды выполнения, т.е. скорее зависит от конкретной реализации, пусть он зависит от API.
при необходимости переносить аппаратно-зависимый код (ОС) в базовую ОС / среду выполнения
