Запуск камеры на RK3576 под Linux: от драйвера сенсора до первого кадра

RK3576 — eto protsessornyy chip, razrabotannyy kompaniey Rockchip dlya promyshlennogo zreniya, umnykh sistem bezopasnosti i terminalov iskusstvennogo intellekta v oblasti zreniya. V nego vstroen ISP V3.9 (protsessor obrabotki izobrazheniy), podderzhivayushchiy razresheniye do 16 MP, i tri priyomnykh modulya MIPI CSI-2 (dva modulya D-PHY V2.0 i odin modul C/D-PHY). Maksimal'naya skorost' peredachi na kazhduyu liniyu D-PHY sostavlyayet 4,5 Gbps, maksimal'naya skorost' na kazhduyu grupu trekh linii C-PHY — 2,5 Gsps, a kazhdyj port CSI podderzhivaet chetyre virtual'nye kanaly.

Resheniye dlya kamery RK3576 postroeno na osnove Linux Media framework i modeli podustroystv V4L2-subdev. Polnyy put' peredachi dannikh: datchik izobrazheniya → kontroller priyomnika MIPI CSI → blok videozakhvata VICAP → ISP V3.9. Datchik funktsioniruyet kak nezavisimoye podustroystvo i vzaimodeystvuyet s MIPI CSI, VICAP i ISP dlya formirovaniya polnoy truboprovodnoy sistemy sbora izobrazheniy.

Хотя RK3576 предоставляет три канала приёмника MIPI CSI, а VICAP может одновременно принимать несколько потоков изображений, аппаратный модуль ISP версии 3.9 является одноканальным и способен выполнять алгоритмическую обработку ISP только для одного потока изображений в каждый момент времени.

В ходе отладки проекта могут возникнуть такие проблемы, как аномальная работа шины I2C, нестабильное соединение по интерфейсу MIPI или сбой при создании конвейера Media, что в конечном итоге препятствует выводу первого кадра изображения. В данной статье представлен полный подход к отладке с инженерной точки зрения реализации и приведены рекомендации, применимые при отладке встраиваемых систем машинного зрения.

1. Подготовка аппаратного обеспечения и ядра: устранение низкоуровневых аппаратных проблем до начала отладки

При отладке драйвера большинство проблем, с которыми мы сталкиваемся, вызваны не самим кодом драйвера, а низкоуровневыми вопросами — например, неправильным подключением аппаратных компонентов, нарушением последовательности подачи питания или отсутствием необходимых параметров в конфигурации ядра. Поэтому перед началом разработки драйвера датчика необходимо в первую очередь проверить и подтвердить корректность базового аппаратного обеспечения и окружения ядра.

Ключевые аппаратные проверки включают цепи питания датчика, шину I2C, дифференциальные линии MIPI и GPIO-контакты для сброса и управления питанием.

Последовательность включения питания датчика — один из наиболее критичных этапов отладки. Несколько цепей питания, таких как AVDD, DOVDD и DVDD, должны строго соблюдать порядок включения, указанный в технической документации датчика. Превышение допустимых отклонений напряжения питания или нарушение временных параметров включения/выключения питания могут напрямую привести к сбоям связи по шине I2C и некорректной работе датчика.

Шина I2C: проверьте конфигурацию мультиплексирования выводов и адрес slave-устройства датчика, а также убедитесь, что резисторы подтяжки I2C установлены корректно.

MIPI: Подтвердите используемый аппаратным обеспечением канал CSI, количество линий MIPI и согласование импеданса на дифференциальных сигнальных линиях. Также убедитесь, что опорный тактовый сигнал датчика (XVCLK), выводимый микросхемой RK3576, работает корректно.

Управляющие выводы сброса/отключения питания: Определите логику активного уровня (активный высокий/активный низкий) и убедитесь, что конфигурация GPIO соответствует принципиальной схеме.

Конфигурация ядра: Проверьте параметры ядра для подсистемы Media, подустройств V4L2-subdev, контроллера и драйверов PHY интерфейса MIPI CSI, модуля VICAP и ISP версии 3.9. Если требуемый компонент не встроен в ядро или встроен как модуль, но не загружается корректно, конвейер Media не сможет распознать аппаратное обеспечение камеры. После сборки и прошивки ядра сначала проверьте статус загрузки каждого модуля драйвера. Изучите журнал dmesg и убедитесь, что отсутствуют ошибки, например, отсутствие модулей или сбои при инициализации.

2. Конфигурация дерева устройств (DTS): Установление соединений между устройствами

Дерево устройств камеры RK3576: описывает аппаратные ресурсы и использует узлы портов и конечных точек для привязки связей в конвейере обработки изображений между датчиком, интерфейсом MIPI CSI, модулем VICAP и процессором ISP.

Узел датчика подключён к соответствующему узлу шины I2C и определяет адрес ведомого устройства I2C, контакт сброса, контакт управления отключением питания и опорную тактовую частоту датчика. Свойства можно настроить так, чтобы инициализация датчика задерживалась до готовности аппаратной части PHY интерфейса CSI, что предотвращает гонки по времени, вызванные неготовностью PHY. Конечная точка внутри узла порта датчика указывает на вход MIPI CSI и задаёт количество линий передачи данных MIPI.

Узел контроллера MIPI CSI содержит два порта: вход подключён к датчику изображения, а выход — к модулю VICAP. Далее VICAP передаёт данные изображения в ISP V3.9. Обратите внимание: конечные точки должны ссылаться друг на друга двунаправленно, и свойства remote-endpoint на обоих концах должны соответствовать друг другу по принципу «один к одному». Если двунаправленная привязка не совпадает, фреймворк Media не сможет распознать полный путь передачи данных. После изменения, компиляции и прошивки DTS сначала проверьте журнал dmesg, чтобы убедиться, что все узлы устройств находятся в нормальном состоянии и отсутствуют ошибки отложенного опроса (deferred-probe). Повторяющиеся попытки отложенного опроса обычно указывают на неправильную конфигурацию GPIO, тактового сигнала или источника питания.

3. Разработка драйвера подустройства датчика: модель V4L2-subdev

Драйвер датчика платформы RK3576 разработан на основе фреймворка V4L2-subdev. Драйвер датчика не создаёт узел /dev/video; он существует исключительно как сущность медиа-подустройства. Его основные функции включают настройку регистров датчика, управление питанием и сбросом, конфигурацию формата изображения, а также управление запуском и остановкой потока.

Драйвер в основном состоит из пяти модулей: обнаружение по шине I2C, управление питанием и сбросом, таблицы регистров режимов, конфигурация формата pad и управление запуском и остановкой потока.

На этапе инициализации драйвера идентификатор чипа датчика считывается по шине I2C для проверки корректного распознавания чипа. Если чтение идентификатора завершается неудачно, диагностику можно сразу сфокусировать на аппаратных неисправностях, связанных с шиной I2C, питанием и сбросом. Функции питания/сброса реализуют полную последовательность включения и выключения питания датчика: при включении питания каждый источник напряжения включается последовательно, вывод сброса устанавливается в активное состояние на заданную задержку, затем сброс отменяется, и датчику предоставляется время для внутренней стабилизации. Последовательность выключения питания выполняет обратные операции.

Таблицы регистров режимов хранят полные конфигурации регистров датчика для различных разрешений, частот кадров и скоростей MIPI. При смене параметров захвата на верхнем уровне драйвер записывает соответствующий полный набор регистров. Интерфейс формата вывода (pad-format) настраивает формат изображения шины передачи данных (media-bus), который должен строго соответствовать формату Байера, выдаваемому датчиком (например, BGGR или RGGB). Неправильная настройка напрямую приводит к ошибкам цветопередачи изображения. Интерфейс управления потоком (stream-control) использует команду stream_on для записи команд в регистры, включающих MIPI-выход изображения датчика, а команда stream_off останавливает передачу изображения. После реализации драйвера в файлы конфигурации ядра Kconfig и Makefile добавляются опции сборки, позволяющие скомпилировать драйвер либо непосредственно в ядро, либо как загружаемый модуль ядра.

4. Поэтапная отладка: получение первого кадра пошагово

Не рекомендуется сразу пытаться захватывать изображения. Используйте многоуровневый подход к устранению неполадок в три этапа: подтвердите успешное обнаружение драйвера сенсора → проверьте полную связность конвейера Media → выполните захват «сырых» изображений с помощью V4L2.

Этап 1: Проверка успешного обнаружения драйвера сенсора

После загрузки системы просмотрите вывод команды dmesg и найдите сообщения журнала, выведенные драйвером сенсора. Используйте утилиту i2cdetect для сканирования соответствующей шины I2C и подтверждения обнаружения адреса ведомого устройства сенсора.

• Если ни одно устройство I2C не обнаружено: проверьте питание сенсора, логику сброса, пайку аппаратных компонентов шины I2C и мультиплексирование выводов.
• Если адрес I2C обнаруживается, но считанный идентификатор микросхемы (Chip ID) некорректен: аппаратный канал I2C работает исправно, а проблема, скорее всего, вызвана неверными адресами регистров или несоответствием модели сенсора.

Этап 2: Проверка конвейера Media Framework

Используйте media-ctl для просмотра списка сущностей медиаустройства. В нормальных условиях должны отображаться сущности подустройств, такие как sensor, mipi_csi, vicap и isp39, причём каждый порт pad должен быть корректно распознан.

• Если сущность sensor не отображается — сбой при инициализации драйвера сенсора.
• Если сущности присутствуют, но связь между ними отсутствует — в DTS некорректно задана двунаправленная парная привязка конечных точек (endpoints).

На этапе отладки media-ctl можно использовать для ручной настройки всего конвейера: установки связей между сущностями, а также задания формата изображения, разрешения и конфигурации линий (lane) для каждого этапа работы подустройства. Ошибки media-ctl обычно вызваны тем, что количество линий (lane count), формат media-bus или разрешение превышают аппаратные возможности сенсора. Успешная настройка media-ctl означает, что программный путь от сенсора до ISP успешно установлен.

Этап 3: захват изображения с помощью V4L2 и получение первого кадра в формате raw

VICAP/ISP создаёт узел /dev/video, который служит точкой входа в пространство пользователя для захвата изображений. Используйте v4l2-ctl для установки формата пикселей изображения, захвата одного кадра через mmap и сохранения данных сырых (Bayer RAW). Если размер полученного RAW-файла соответствует теоретически ожидаемому значению, первый кадр успешно захвачен. Далее RAW-файл можно открыть в профессиональном инструменте анализа изображений для просмотра исходного изображения в формате Bayer.

5. Распространённые методы устранения неисправностей

• при настройке связи media-ctl выдаёт ошибку: сначала проверьте двунаправленную привязку конечных точек в DTS, затем убедитесь в корректности параметров формата media-bus, разрешения и количества линий (lane count).
• Тайм-аут захвата кадра V4L2 без вывода данных изображения: убедитесь, что команда stream_on выполнена корректно внутри драйвера, что PHY интерфейса CSI достигла блокировки по тактовому сигналу (clock lock), а также что датчик действительно передаёт поток данных MIPI.
• Повреждённые изображения или полосатые помехи: Возможные причины включают неправильную тактовую частоту MIPI, неверное количество линий, несоответствие шаблона Байера или чрезмерные пульсации в источнике питания датчика.
• Прерывистый вывод изображения или случайная потеря кадров: Временные параметры включения питания/сброса датчика могут не соответствовать требованиям, либо аппаратный источник питания может быть недостаточно стабильным.

У нас имеется зрелое решение на базе RK3576 и профессиональные компетенции в области разработки под заказ, адаптации аппаратного обеспечения и внедрения серийного производства. Для различных датчиков изображения и требований к разрешению/частоте кадров мы можем предложить модификации аппаратного обеспечения, отладку драйверов и комплексную оптимизацию всей системы, чтобы эффективно поддерживать проекты по индивидуальному заказу в областях промышленного зрения, умной безопасности, терминалов ИИ-видения и других приложений. Свяжитесь с нами по адресу [email protected].