Замена модуля Wi-Fi: проверка драйвера Linux и дерева устройств

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

Это руководство охватывает инженерную проверку встраиваемых Linux-изделий с устройствами Wi-Fi на SDIO, USB или PCIe. Оно не предполагает одинаковый беспроводной стек Linux или модель дерева устройств у всех модулей. Предлагаемые испытания — план приёмки, а не измеренная пропускная способность, регуляторное одобрение или заявление о прямой взаимозаменяемости.

1. Составьте матрицу замены до изменения ПО

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

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

Получите у поставщика модуля документы интеграции и условия распространения прошивки. Зафиксируйте файлы калибровки конкретной платы или энергонезависимой конфигурации и способ их привязки к собранной плате. Не используйте калибровочные данные другого изделия только из-за совпадения названия чипсета.

2. Установите исходную конфигурацию драйвера и прошивки

Выясните, находится ли нужный драйвер в выбранном дереве ядра, поставляется ли с BSP или поддерживается вне дерева. Зафиксируйте точный коммит и конфигурацию, поддерживаемые идентификаторы устройств и зависимости. Внешний модуль, собранный для другого ядра, может не работать из-за различий API, конфигурации или версий модулей; копирование бинарного файла не является стратегией портирования.

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

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

3. Меняйте только применимое описание аппаратуры

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

Устройства USB и PCIe обычно обнаруживаются своей шиной, хотя питание платы, сброс или ресурсы контроллера хоста всё равно могут нуждаться в описании. Не добавляйте произвольный узел Wi-Fi только ради принудительной загрузки USB-драйвера. Сначала определите, видит ли шина устройство и соответствуют ли его идентификаторы нужному драйверу.

Скомпилируйте и проверьте изменённое дерево устройств инструментами выбранного дерева исходников. Руководство по схемам привязок Linux описывает проверки вроде dtbs_check. Успешная проверка схем подтверждает структурное соответствие доступным привязкам, но не проверяет полярность сброса, напряжение или соединения печатной платы.

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

4. Диагностируйте по порядку: шина, инициализация драйвера, радио, сеть

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

После появления беспроводного интерфейса проверьте возможности и активное соединение. Для драйверов со стандартным интерфейсом nl80211 полезны следующие команды без изменения состояния; замените имя интерфейса фактическим. Некоторым драйверам производителей требуются собственные поддерживаемые инструменты.

uname -r
ip link show
iw dev
iw phy
# Example interface name only:
iw dev wlan0 link
iw reg get

Документация Linux Wireless по iw объясняет проверку возможностей и соединения. Наличие возможности в списке не доказывает, что собранная антенная система или приложение выполняет требования производительности.

Затем разделите ассоциацию, настройку адреса, маршрутизацию, DNS и соединение приложения. Рабочая радиосвязь может сочетаться с отказом DHCP. Успешный ping локального узла не доказывает доступность требуемого TLS-сервиса приложения или корректность времени для проверки сертификата.

5. Проверьте именно те роли, которые использует изделие

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

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

Если Bluetooth использует тот же модуль или антенну, включите требуемый сценарий одновременной работы. Прогон только Wi-Fi не подтверждает сосуществование. Не публикуйте значения пропускной способности или дальности без условий измерения и реальных доказательств.

6. Включите восстановление и негативные проверки

• Точка доступа исчезает: проверьте ограниченные повторы, тайм-ауты приложения и восстановление после возвращения AP.
• Неверные учётные данные: показывайте статус, позволяющий принять меры, без бесконечного частого переподключения и без раскрытия секрета в журналах.
• Нет службы адресации: отличайте радиоассоциацию от недоступности DHCP и проверяйте документированный резервный вариант изделия.
• Прошивка отсутствует: на расходном тестовом образе подтвердите, что стартовая диагностика называет отсутствующую зависимость.
• Сон и возобновление: проверьте каждый необходимый источник пробуждения и восстановление как интерфейса, так и приложения.
• Холодный и тёплый перезапуск: проверьте оба; модуль с сохраняющимся питанием может скрыть неполную последовательность холодного старта.

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

7. Рассматривайте регуляторную конфигурацию как отдельное требование

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

Доказательства приёмки для решения о замене

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

Конфигурация проекта сетевого Linux-шлюза RK3528 компании Obeita называет AP6275S как рассматриваемый вариант радиомодуля и указывает отдельные программные пути станции/AP и Bluetooth. Это полезный пример объёма работ, а не доказательство совместимости альтернативного модуля. Для оценки замены см. диагностику прошивок и BSP и предоставьте коды заказа обоих модулей, схему, версию ядра/BSP и необходимые беспроводные роли.