Модуль тестирования 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. почему вы его не используете?