Конфігурація камер плати

Блок board каталогу описує, як плату налаштовано для камер MIPI: яка це плата, які оверлеї застосовує U-Boot, які сенсори камер описує завантажене дерево пристроїв і які сенсори можуть описувати встановлені оверлеї. Кожна налаштована камера вказує камеру camera.mipi, яка є її сенсором, тож клієнт може знайти compatible камери, а в supported_sensors — оверлеї, які її налаштовують. Як і записи пристроїв, блок повідомляє лише факти й ніколи не змінює конфігурацію.

Блок зчитується під час кожного сканування, після провайдерів, тому camera_id завжди посилається на devices того самого каталогу, а revision змінюється, коли змінюється блок. Він відсутній лише до завершення першого сканування, а API повертає HTTP 503, як і раніше, якщо виявлення вимкнено.

Поля

Поле	Наявність	Значення
`model`	якщо є в дереві пристроїв	`/sys/firmware/devicetree/base/model` до першого символу NUL і без пробілів на початку та в кінці, наприклад `SiMa.ai Modalix SoM 16Gig Board`
`overlays`	після того як `fw_printenv -n dtbos` хоча б раз виконався успішно	Записи змінної U-Boot `dtbos`, що закінчуються на `.dtbo`, у їхньому порядку: усі оверлеї, які застосовує U-Boot, а не лише оверлеї камер (оверлеї PCIe, безпечного завантаження та флеш-пам’яті використовують ту саму змінну). Sentinel не вказує, який запис налаштовує камеру; `supported_sensors` перелічує оверлеї, які налаштовують сенсор. Якщо наступний запуск завершується невдало, зберігається список останнього успішного запуску, а про збій повідомляється
`configured_cameras`	завжди	Сенсори MIPI CSI-2 на I2C в активному дереві пристроїв; може бути порожнім
`supported_sensors`	завжди	Сенсори, які налаштовують файли оверлеїв у `/boot`; може бути порожнім

Кожен запис configured_cameras:

Поле	Значення
`compatible`	Перший рядок `compatible` вузла, наприклад `sony,imx477`
`dt_node`	Шлях вузла від кореня дерева пристроїв, наприклад `/i2cmux@0/i2c@0/imx477@1a`
`i2c_device`	Пристрій I2C, `<bus>-<address>` так, як його називає sysfs, наприклад `5-001a`
`data_lanes`	Кількість комірок у `data-lanes` кінцевої точки сенсора
`camera_id`	`id` камери `camera.mipi`, яка є цим сенсором; відсутнє, якщо в каталозі немає такої камери

Кожен запис supported_sensors має compatible і overlays — відсортовані імена файлів оверлеїв, які його налаштовують. Записи відсортовано за compatible. Список об’єднує /boot і всі каталоги слотів у ньому, тому він може містити оверлеї, встановлені лише в слоті, з якого систему не завантажено.

Звідки береться кожен факт

Активне дерево пристроїв — це те, з чим завантажилося ядро, після того як U-Boot застосував оверлеї. Це чинна конфігурація, тому модель і налаштовані камери беруться з нього, а не з файлів оверлеїв.
Посилання I2C of_node — це спосіб, у який знаходять і зіставляють налаштовану камеру. Кожен клієнт I2C у /sys/bus/i2c/devices (з іменем <bus>-<address>; адаптери з іменами i2c-N пропускаються), чиє посилання of_node вказує всередину активного дерева пристроїв, є кандидатом. Він є налаштованою камерою, якщо його вузол має compatible, а вузол endpoint під ним (не всередині вузла іншого пристрою) має data-lanes, що позначає джерело MIPI CSI-2. V4L2 називає субпристрій сенсора I2C <driver> <bus>-<address>, іноді з ще одним словом після цього (ccs 5-0010 pixel_array), тому цим сенсором є камера, чиє camera_name містить <i2c_device> як окреме слово, відокремлене пробілами. Так зіставляється саме той пристрій, без порівняння імен виробника чи сенсора.
Список оверлеїв — це власний запис платформи, що зберігається в середовищі U-Boot. fw_printenv знає, де це середовище зберігається на платі, тому Sentinel запитує його, а не читає флеш-пам’ять самостійно. Значення — це список, який U-Boot застосує під час наступного завантаження; він збігається зі списком завантаженої системи, якщо його не змінили після завантаження. Це єдина частина виявлення, яка запускає програму, а не читає інтерфейси ядра. fw_printenv працює від root і ніколи не змінює середовище, але бере його блокування: libubootenv, яку постачає DevKit, створює /var/lock/fw_printenv.lock і чекає на ексклюзивний flock на ньому, тож fw_setenv, запущений одночасно, може затримати сканування до тайм-ауту.
Файли оверлеїв — це оверлеї, які постачає платформа. Кожен файл *.dtbo безпосередньо в /boot, куди їх встановлює Platform 3.0, або в каталозі, що лежить безпосередньо в ньому, як у слотах A/B /boot/boot-0/ і /boot/boot-1/ у Platform 2.1, аналізується. Сенсор — це вузол із compatible і кінцевою точкою CSI-2, як описано вище, який оверлей додає до шини I2C: під вузлом, ім’я якого починається з i2c, або у фрагменті, ціллю якого є такий вузол, — через target-path або через мітку в __fixups__, на яку посилається його target. Ім’я файлу, знайдене в кількох із цих каталогів, наводиться один раз.

Джерело CSI-2, під яким є інше таке джерело, — це міст, наприклад мультиплексор I2C або десеріалізатор і серіалізатор GMSL; його пропущено в обох списках, тож показується лише сам сенсор.

Роздільна здатність і формати камери, як і раніше, надходять від ISP, у полі modes камери; оверлеї їх не описують.

Межі

Виявлення читає щонайбільше 1024 пристрої I2C; у піддереві кожного пристрою — 256 вузлів, 256 записів кожного вузла і 32 рівні вузлів, враховуючи вузол самого пристрою; 4096 записів у /boot і в кожному з його каталогів; а також 512 файлів оверлеїв розміром щонайбільше 1 МіБ кожен. Про список, обрізаний на одній із цих меж, повідомляється як про помилку його поля, а прочитане все одно публікується. Файли оверлеїв аналізуються один раз і повторно аналізуються лише тоді, коли змінюється їхній розмір, час модифікації, час зміни або inode; файл, який не вдалося прочитати, читається знову під час наступного сканування. fw_printenv примусово завершується через 2 секунди. Сканування чекає ще щонайбільше 0,5 секунди на його завершення, а потім залишає його для збирання у фоновому режимі. Доки він не завершиться, наступні сканування не запускають fw_printenv, а повідомляють про помилку й зберігають останній список. Читається щонайбільше 64 КіБ його виводу та 4 КіБ його виводу помилок.

Помилки

Кожна помилка називає поле, яке вона робить неповним: provider має значення board.model, board.overlays, board.configured_cameras або board.supported_sensors. Решта блоку все одно публікується.

Код	Коли
`io.open`	`model`, `/sys/bus/i2c/devices`, вузол пристрою, `/boot`, один із його каталогів або файл оверлею існує, але його неможливо прочитати
`io.permission_denied`	Те саме, але зі збоєм `EACCES`; або `fw_printenv` існує, але його неможливо запустити (`EACCES` або `EPERM`)
`peripherals.discovery_failed`	`fw_printenv` неможливо запустити з іншої причини, його вивід неможливо прочитати, очікування на нього завершується збоєм, він не завершується вчасно або завершується невдало з іншої причини, ніж те, що `dtbos` не встановлено (у причині наведено перший рядок, який він вивів у stderr); файл оверлею має неправильний формат або більший за 1 МіБ; список обрізано на одній із наведених вище меж

Про проблеми кожного списку повідомляється однією помилкою, з кодом і причиною першої проблеми та кількістю інших. Для supported_sensors непрочитний або обрізаний перелік /boot чи одного з його каталогів рахується разом із пропущеними файлами оверлеїв; для configured_cameras обрізаний перелік пристроїв I2C рахується разом із пристроями, які не вдалося прочитати або які було обрізано. Якщо fw_printenv відсутній або завершується невдало з повідомленням, що змінна not defined (як це робить u-boot-tools, коли dtbos не встановлено), overlays пропускається без помилки. libubootenv, яку постачає DevKit, виводить порожнє значення для змінної, яку не встановлено, тож тоді overlays — порожній список. Будь-який інший збій зберігає останній список і повідомляє про помилку; доки жоден запуск не був успішним, overlays пропускається. Плата без дерева пристроїв, пристроїв I2C або /boot повідомляє порожні списки без помилки.

Обмеження

Правило CSI-2 є структурним. Пристрій із власною кінцевою точкою CSI-2 і без сенсора під ним наводиться в списку, навіть якщо це не камера, наприклад міст HDMI–CSI-2 або десеріалізатор GMSL, сенсори якого не описано.
Оверлей, який додає сенсор до шини I2C, мітка або шлях якої не починається з i2c, не розпізнається.
data_lanes береться з першої кінцевої точки в порядку вузлів; сенсор із кількома кінцевими точками різної ширини повідомляє лише одну.
Сенсор, кінцева точка якого не має data-lanes, не розпізнається як джерело CSI-2, тому його немає в configured_cameras і supported_sensors.
Супутній чип із власною кінцевою точкою CSI-2 наводиться як налаштована камера, наприклад Metoak,xc9080 в оверлеї METOAK-DUAL. Жодна камера camera.mipi не є його сенсором, тому він ніколи не має camera_id.
Ніщо не стежить за /boot або середовищем U-Boot. Зміна, зроблена через fw_setenv, або встановлений чи видалений файл оверлею з’являється в наступному скануванні, яке запускається після події пристрою камери чи звуку або під час оновлення.

Приклад

IMX477 на Modalix DevKit, як у catalog-example.json. Модель, шлях у дереві пристроїв, пристрій I2C та ім’я оверлею переписано з DevKit, а не захоплено з Sentinel; блок покрито синтетичними тестовими фікстурами. Плата з більшою кількістю встановлених оверлеїв наводить більше з них у supported_sensors.

"board": {
  "model": "SiMa.ai Modalix SoM 16Gig Board",
  "overlays": ["modalix-som-waveshare-ARDU-IMX477-1CAM.dtbo"],
  "configured_cameras": [{
    "compatible": "sony,imx477",
    "dt_node": "/i2cmux@0/i2c@0/imx477@1a",
    "i2c_device": "5-001a",
    "data_lanes": 2,
    "camera_id": "camera:imx477 5-001a"
  }],
  "supported_sensors": [
    {"compatible": "sony,imx477",
     "overlays": ["modalix-som-waveshare-ARDU-IMX477-1CAM.dtbo"]}
  ]
}

Поля​

Звідки береться кожен факт​

Межі​

Помилки​

Обмеження​

Приклад​