У меня есть двухъядерное встроенное системное устройство ARM, в котором работает RTOS/ядро, которое я написал. Я хочу написать инструмент/модуль внутренней диагностики для имитации ввода-вывода в ядро для целей тестирования. Очевидно, что это не полностью заменит тестирование в реальном мире, с физическими аппаратными интерфейсами и всеми. Я предполагаю, что это будет близко к гипервизору. Каковы методы/концепции для этого?
Модуль тестирования ARM-ядра
Ответ 1
Я использовал L4 microkernel, а аппаратные разрешения отображаются как страницы MMU; Опции ARM: 1k, 4k, 64k страниц и 1M секций. Кроме того, вы можете посмотреть отсроченный ввод-вывод Linux FB. Идея состоит в том, чтобы обеспечить набор psuedo-register с памятью. Затем вы можете использовать обработчик ошибок страницы с адресом ошибки, чтобы определить, какой psuedo-register. Возможно, вам придется посмотреть инструкции. Например, код может использовать обратную запись и другие обновления. Код Linux alignment handler, вероятно, очень поучительный.
Смотрите: ARM ARM - глава B3 Блок управления памятью.
ARM ARM - прерывание данных 2.6.5 (прерывание данных доступа к данным)
Вам также необходимо смоделировать прерывания. Используя таймер (с любым распространением, который вам нравится), ISR драйвера/ОС могут быть задействованы. Чтобы минимизировать использование таймера, колесики синхронизации могут использоваться для создания различных функций распределения вероятности прихода прерывания. Вы также можете поместить этот таймер как FIQ
, если это возможно. Это может позволить вашему тестовому устройству ISR получать обновления данных даже при регулярном IRQ
в масках. Вы также можете эмулировать DMA с помощью обработчика FIQ
при постоянном прерывании таймера. Конечно, это предполагает, что ваши тестовые драйверы не используют FIQ
, и у вас есть таймер FIQ
.
У многих драйверов ОС есть регистры-кэши, особенно если устройство является чипом только для записи. Взгляд на этот код также может быть полезен.
С L4 конкретная ячейка получает разрешение для фактического диапазона физических устройств. Это перемещается в виртуальном пространстве. Дополнительная проблема с гипервизором заключается в том, что у вас работает несколько ОС, и вам нужно переключить разрешение на включение/выключение различных аппаратных периферийных устройств. Я не считаю, что вам нужно это делать.
Cavets: Блокировка нескольких CPU может иметь проблемы с обработкой data fault
; ваши драйверы не должны обращаться к оборудованию через несколько процессоров. Обработчик может работать с прерываниями, заблокированными и на одном CPU, это решение будет работать. Я считаю, что если произойдет исключение, strex
вернется с набором кодов условий. Возможно, вы справитесь с этим в обработчике ошибок.
Я предложил решение выше из-за того, как вы сформулировали вопрос, и arm.
Как Pekka заметки, если вы решите использовать С++, это может быть полезно в дизайн для тестирования. Полезный шаблон - это чистый виртуальный интерфейс в драйвере, который обращается к аппаратным средствам. Когда вы тестируете, вы заменяете этот виртуальный интерфейс классом моделирования; выполнение этого в 'C' также возможно с помощью пучков указателей функций. Эти виды деятельности хорошо документированы, поэтому я их исключил. Тем не менее, вы можете подумать о том, чтобы уточнить вопрос и, возможно, повторно пометить, если это то решение, которое вы ищете.
Ответ 2
Вы можете применять следующие подходы в порядке увеличения точности (и усилий):
- Если у вас есть программный API для запланированного оборудования, то заглушка, которая отвечает имитируемыми результатами, обеспечит решение первого порядка.
- Если аппаратное обеспечение сопоставлено с памятью, создайте процесс моделирования/поток, который обновляет память, как если бы это было внешнее оборудование.
- Затем, если требуется больше верности, можно ввести подход бесхитростный шум с использованием ошибок страницы для устройств с отображением памяти, чтобы сделать симулятор прозрачным для реального API, и ввести синхронные обновления событий.
- Наконец, это может быть меньше усилий для создания аппаратного обеспечения (возможно, с большим количеством программного обеспечения), которое обеспечивает тот же интерфейс для приложения, чтобы дать аппаратное обеспечение в цикле моделирования вне системы. Это даст вам точный аппаратный интерфейс, но просто переместите сложность в тестовые леса.
Ответ 3
Если ваша RTOS имеет уровень абстракции аппаратного обеспечения (HAL) между ядром и оборудованием. Это может быть хорошим моментом для моделирования ввода-вывода.
Если у вас нет какого-либо слоя HAL, это может быть одной из причин его реализации. Есть много других веских причин для HAL (см. здесь). Google с "аппаратной абстракцией", чтобы получить дополнительную информацию.
Существуют также некоторые эмуляторы ARM (ARMware и аналогичные устройства) для имитации устройств ARM.
Ответ 4
Тестирование, которое вы хотите сделать, похоже на отправку виртуального запроса ввода-вывода в ядро. Я думаю, что концепция похожа на программную, паравиртуализацию.
Программный Hypervisor - это ваша тестовая программа; отправка виртуального ввода-вывода в ваше ядро, и ваше ядро содержит виртуальный драйвер ввода-вывода для приема этих запросов ввода-вывода.
После обработки виртуальный драйвер ввода-вывода также должен иметь возможность гиперкалировать гипервизор для предупреждения состояния виртуального сигнала ввода-вывода.
Ответ 5
Нет информации о вашем RTOS/ядре.... но я полагаю, что ваше RTOS/ядро должно иметь что-то вроде ioctl
. почему вы его не используете?