Проверка изменений device tree с помощью ИИ: от журнала загрузки до реальной периферии

ОтLIU, ZHUOHUI

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

Пример TMP102 ниже использует гипотетическую плату и специально составленные фрагменты в стиле генерации. Выполнение ИИ, загрузка платы и измерение датчика не заявляются. Исправленный фрагмент намеренно неполон и не является готовым описанием платы.

1. Передайте помощнику фактические данные платы

Укажите точные ревизии платы и сборки, SoC, коммит ядра, патчи производителя, существующую цепочку включений DTS/DTSI и механизм выбора загрузчика. Приложите страницы схемы с шиной, перемычками адреса, питанием, подтяжками и возможным прерыванием. Передайте binding и драйвер из действительно собираемого дерева ядра. Документация upstream полезна, но ядро производителя может отличаться.

Для учебного примера примем, что TMP102 подключен к контроллеру с меткой i2c2, его 7-битный адрес установлен в 0x48, питание связано с именованным источником, а ALERT не подключен. Проверенная начальная частота шины — 100 кГц. Это явные исходные условия сценария, а не свойства, выведенные из существующей платы Obeita.

Запросите минимальный патч файла платы, пояснение каждого добавленного свойства, список зависимостей и план проверки. Запретите выдуманные группы pinctrl, номера GPIO и строки compatible. Если включаемое дерево SoC уже задает тактирование или сброс контроллера, черновик должен сохранить это устройство, а не копировать его заново из чужого примера.

Цепочка свидетельств от схемы и binding ядра через установленный DTB и активное дерево до измерений периферии.
Каждая ступень отвечает на отдельный вопрос; успешная сборка не доказывает электрическое поведение.

2. Определите, почему правдоподобный черновик неверен

/* Deliberately flawed draft for an illustrative board. */
&i2c2 {
    status = "okay";
    clock-frequency = <1000000>;
    sensor@90 {
        compatible = "ti,tmp102";
        reg = <0x90>;
        interrupt-parent = <&gpio1>;
        interrupts = <7 2>;
    };
};

Адрес — классическая ошибка представления: 0x90 соответствует байту адреса записи для 7-битного адреса 0x48, тогда как reg дочернего узла должен использовать представление, требуемое binding шины. Копирование байта транзакции из даташита незаметно описывает другой адрес. Unit address и reg согласованы между собой, поэтому одной такой согласованности недостаточно.

Частота 1 МГц не подтверждается входными данными проекта. Свойства прерывания угаданы, хотя ALERT не подключен. Числовые флаги прерывания скрывают смысл и могут относиться к binding другого контроллера. Отсутствие pinctrl и питания столь же существенно, хотя некоторые платы законно наследуют настройки из других мест. Прежде чем объявлять свойство обязательным всегда, проверьте цепочку включений.

Upstream-binding TMP102 дает конкретную основу для compatible, reg, необязательного прерывания, label и vcc-supply. Он не определяет разводку этой платы. Такое разделение не позволяет превратить синтаксически аккуратный ответ ИИ в выдуманную схему.

3. Проверьте минимальное исправление

/* Partial teaching patch. Labels must exist in the board tree. */
&i2c2 {
    pinctrl-names = "default";
    pinctrl-0 = <&i2c2_board_pins>;
    clock-frequency = <100000>;
    status = "okay";

    temperature-sensor@48 {
        compatible = "ti,tmp102";
        reg = <0x48>;
        vcc-supply = <&sensor_vcc>;
        label = "board-ambient";
    };
};

Фрагмент следует условиям сценария: 7-битный адрес, явно выбранная начальная скорость, ссылка на питание и отсутствие вымышленного прерывания. Метки pinctrl и регулятора обозначают существующие проверенные определения платы. Перед использованием подтвердите напряжение, принадлежность ресурсов, полярность включения и последовательность питания. Если определений нет, их добавление требует отдельного изменения с аппаратным обоснованием.

Исправление может быть меньше этого фрагмента. Если include платы уже задает правильный pinctrl или clock-frequency, лучше сохранить их. Избегайте сгенерированной ИИ «чистки», которая ради одного датчика перестраивает посторонние контроллеры, меняет общее питание или вводит overlays. Узкий diff помогает установить причинно-следственную связь.

4. Проверьте выбранное ядро, затем загружаемый артефакт

Запускайте валидацию схем в реальном дереве ядра. Руководство по проверке bindings различает dt_binding_check для схем и dtbs_check для деревьев и предупреждает, что dtbs_check может пропускать ошибочные схемы. Если binding меняется, проверяйте и его. Сохраняйте полные журналы, отделяя новые ошибки от старых.

# Proposed checks in the exact configured kernel source tree:
make ARCH=<target-arch> CROSS_COMPILE=<tool-prefix> dtbs_check   DT_SCHEMA_FILES=hwmon/ti,tmp102.yaml

# On a target that exposes its live tree, with appropriate access:
dtc -I fs -O dts /sys/firmware/devicetree/base > running.dts
# Review the actual controller path, compatible, reg and supply.
# Discover the matching hwmon device; do not assume hwmon0.

Команды являются предлагаемыми шагами, а не протоколом выполнения. Замените заполнители архитектуры и toolchain значениями проекта. Проверка, ограниченная одной схемой, полезна при ревью, но не охватывает все взаимодействия дерева платы. Дополните ее более широкими DT-проверками и требованиями сборки проекта. Сохраните конфигурацию ядра, включающую драйверы контроллера и датчика.

Запишите имя и хеш собранного DTB, шаг упаковки образа, настройки загрузчика и место установки. На целевой системе изучите нужные свойства активного дерева. Имя исходного файла не доказывает, что именно загрузилось; также не требуйте одинакового хеша активного дерева, если загрузчик правомерно изменяет свойства. Объясните ожидаемые изменения и сравните существенные аппаратные узлы.

5. По журналу загрузки найдите уровень отказа

До фильтрации соберите полный последовательный журнал загрузки. Подтвердите идентичность ядра и платы, регистрацию контроллера, наличие драйвера и ошибки регуляторов или pinctrl. Отложенный probe может означать неготовность поставщика ресурса, а не ошибочную compatible. Документация модели драйверов ядра описывает отложенный probe при недоступном обязательном ресурсе.

Не требуйте конкретного сообщения об успехе: исправный драйвер может молчать. Проверьте привязку устройства к драйверу и найдите нужный hwmon по имени и связи с устройством. Числовые индексы адаптера и hwmon могут меняться. Документация драйвера TMP102 перечисляет температурный вход и остальные экспортируемые атрибуты. Перед толкованием значений уточните единицы в применимой документации интерфейса.

6. Проверьте реальную периферию, включая отрицательные сценарии

  • Идентичность и путь: покажите, что активный узел, физическая шина и драйвер относятся к нужному датчику. Каталог в sysfs сам по себе не доказывает полезных измерений.
  • Контролируемое воздействие: сравните показания с подходящим независимым эталоном в стабильных условиях, затем безопасно и управляемо измените температуру. До испытания определите допуск и время установления по требованиям проекта и спецификации датчика.
  • Электрическое поведение: при отказе связи подходящими приборами проверьте питание, сброс или разрешение, где применимо, и сигналы шины. Логический захват должен подтвердить адрес, ACK и временные параметры; сам по себе он не доказывает точность измерения.
  • Жизненный цикл: запланируйте повторные холодные загрузки, теплые перезагрузки и поддерживаемые циклы suspend/resume. Отметьте стабильность обнаружения и восстановление за согласованное время.
  • Обработка ошибок: на безопасном стенде смоделируйте отсутствие питания или датчика. Для приемки нужны видимая ошибка и политика восстановления, а не правдоподобное значение из кэша, выдаваемое за свежее.

Не сканируйте неизвестную шину без разбора и не выполняйте сырые I2C-транзакции, конкурирующие с привязанным драйвером. Используйте предусмотренный интерфейс и контролируемую диагностику. До экспериментов с загрузкой подготовьте исходный DTB и документированный путь восстановления.

7. Что должно войти в окончательную проверку

Передайте небольшой DTS-diff, связь схемы со свойствами, точные входы сборки, журналы валидации, идентификатор установленного артефакта, полный boot log и свидетельства испытаний периферии. До фактического запуска отмечайте каждое предложенное испытание как ожидающее выполнения. Согласие двух черновиков ИИ не заменяет доказательств разводки и работы.

Сервис Obeita по диагностике прошивок и BSP подходит этому процессу запуска платы. Проект встраиваемого терминала RK3566 дает близкий контекст BSP и интеграции периферии, но не доказывает, что гипотетический патч TMP102 применялся в том проекте.

Похожие записи