Запуск заказной Linux-платы: от линий питания до приложения

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

Это руководство описывает поэтапный план запуска встраиваемых Linux-плат с деревом устройств, прежде всего ARM и AArch64. Подробную последовательность определяют конкретные загрузочная ROM SoC, микросхема управления питанием, пакет инициализации DDR и BSP производителя. Приведённые испытания — предлагаемые инженерные проверки, а не измеренные результаты конкретного изделия.

1. Подготовьте исходные данные и путь восстановления

До подачи питания соберите схемы, ревизию сборки, замены в спецификации компонентов, сведения о дереве питания, топологии DDR, настройках выбора загрузки и распиновке разъёмов. Сопоставьте собранную плату с эталонным проектом, не предполагая электрическую эквивалентность разводки. Уточните, какие отладочные выводы действительно доступны после сборки.

Подготовьте подходящий источник питания с ограничением тока, приборы с соответствующими пределами напряжения, проверенный последовательный адаптер и поддерживаемый производителем способ восстановления. TTL UART должен соответствовать домену напряжения платы; адаптер RS232 не является взаимозаменяемым. Отключите неконтролируемые нагрузки и проверьте непреднамеренные пути питания через USB или отладочные разъёмы.

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

2. Проверьте питание, сброс и тактирование

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

При неожиданном потреблении тока остановитесь и выясните причину, прежде чем повторять загрузки. Если последовательного вывода нет, проверьте уровни напряжения, предположения о мультиплексировании выводов, скорость передачи и выбранный источник загрузки. Некоторые загрузочные ROM вообще не выводят приветствие. Используйте документированное обнаружение устройства в режиме восстановления или другие признаки производителя, чтобы различать «ROM работает» и «UART молчит».

Не обходите электрическую проблему произвольными программными задержками. Задержка может помочь локализовать нарушение последовательности, но итоговое требование должно назвать реальную зависимость и допустимое время её выполнения.

3. Подтвердите работу первого загрузчика, DDR и загрузочного накопителя

Определите все исполняемые этапы цепочки загрузки. В зависимости от платформы ROM может загрузить SPL, фирменный инициализатор DDR, защищённую прошивку и затем U-Boot. Запишите их версии и смещения в пакете. Плата может выглядеть как имеющая проблему Linux, хотя в образ включён неверный компонент обучения DDR.

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

Для eMMC, SD и других накопителей проверьте обнаружение, ёмкость, настройки шины и карту разделов. Сравните считанные обратно данные с записанным образом документированным неразрушающим способом. Если отказы появляются только в более быстром режиме шины, исследуйте целостность сигналов, переключение напряжения, временные настройки и поддержку драйвера, прежде чем считать постоянное снижение скорости решением.

4. Передайте Linux правильное описание аппаратуры

Дерево устройств описывает топологию аппаратуры и ресурсы; оно не создаёт отсутствующий драйвер и не исправляет неверные соединения. Согласуйте тактирование, регуляторы, линии сброса, прерывания и конфигурацию выводов с собранной платой. Модель использования дерева устройств Linux объясняет его роль в идентификации, настройке времени выполнения и создании представлений устройств.

Храните ядро, DTB, модули и файлы прошивок в одном версионируемом комплекте выпуска. DTB, оставшийся от эталонной платы, может позволить загрузку, незаметно описывая неверный источник питания или прерывание. Выполните проверки схем, доступных в выбранном дереве исходников. Документация ядра по привязкам объясняет разницу между проверкой схем и проверкой данных DT.

# Run in the configured kernel source tree with its required tooling.
make dt_binding_check
make dtbs_check

Эти проверки находят структурные ошибки и проблемы привязок, но не доказывают соответствия соединений платы описанию. Ядра производителей могут содержать старые схемы или недокументированные расширения. Фиксируйте такие отличия вместо устранения предупреждений без понимания причин.

Для AArch64 передача управления загрузчиком также подчиняется архитектурным требованиям к размещению образа, дереву устройств и состоянию процессора. Используйте протокол загрузки AArch64 выбранного ядра вместо переноса адресов загрузки с посторонней платы.

5. Отделяйте готовность ядра от готовности корневой файловой системы

Если ядро запускается, но не монтирует корневую файловую систему, проверьте идентификатор корня, доступность драйвера накопителя, поддержку файловой системы и предпосылки initramfs. Драйвер, собранный только как модуль, не может помочь смонтировать файловую систему с этим модулем, если его не загрузит более ранний этап пользовательского пространства. Сохраняйте первое сообщение об ошибке, а не только завершающую панику.

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

6. Запускайте по одному периферийному тракту

Составьте таблицу интерфейсов, связывающую подписи разъёмов с именами устройств Linux, именами драйверов и ролями в приложении. Для каждого устройства проверяйте обнаружение, базовую работу, ожидаемую нагрузку, поведение при отключении, где оно поддерживается, и перезапуск. Дисплею нужны временные параметры панели и управление подсветкой; сенсорному контроллеру — собственная проверка прерывания и координат. Работа одной части не подтверждает другую.

Если драйвер не может инициализировать устройство, исследуйте первую ошибку зависимости: отсутствие регулятора, тактирования, сброса или прошивки способно создать последующие симптомы, похожие на дефект драйвера. Используйте целевой отладочный вывод вместо включения всех сообщений. Динамическая отладка Linux позволяет выбирать поддерживаемые точки отладочного вывода по модулю, файлу или функции, если ядро настроено соответствующим образом.

7. Испытайте восстановление до передачи приложения

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

Если для сохранения аварийных журналов используется ramoops, зарезервируйте подходящую память и проверьте её сохранность при выбранном типе сброса. Ramoops не гарантирует сохранения данных при отключении питания; см. документацию ядра по ramoops. Доказательства приёмки должны указывать, что было сохранено и что осталось непроверенным.

Конкретный объём работ по запуску платы

Конфигурация проекта встраиваемого терминала RK3566 и адаптации BSP компании Obeita описывает терминал для конкретной панели с периферией, подключённой через FPC. Страница прямо различает разведённые интерфейсы и интерфейсы, для которых нужна новая ревизия платы. Это правильные границы плана запуска, в отличие от предположения, что каждая возможность SoC доступна в собранном изделии.

Для оценки в рамках диагностики прошивок и BSP предоставьте ревизию платы, схему, полный журнал холодной загрузки, манифест образа и самый ранний отказавший этап. Чёткая граница этапа обычно даёт более практичную отправную точку, чем «Linux не работает».