Вопрос или проблема
Я переношу встроенное устройство Linux на mainline с ядра производителя. Я почти закончил, но есть одна проблема, от которой я не могу избавиться – это слишком медленная инициализация DRM.
Вот настройки:
SOC: imx8mp
Ядро: 6.12
ОС: Debian 12 bookworm
Графический процессор, кажется, инициализируется в разумное время:
[ 4.984644] etnaviv etnaviv: bound 38000000.gpu (ops gpu_ops [etnaviv])
[ 5.005189] etnaviv etnaviv: bound 38008000.gpu (ops gpu_ops [etnaviv])
[ 5.038057] etnaviv etnaviv: bound 38500000.npu (ops gpu_ops [etnaviv])
[ 5.048542] etnaviv-gpu 38000000.gpu: model: GC7000, revision: 6204
[ 5.060472] etnaviv-gpu 38008000.gpu: model: GC520, revision: 5341
[ 5.087467] etnaviv-gpu 38500000.npu: model: GC8000, revision: 8002
[ 5.101070] etnaviv-gpu 38500000.npu: etnaviv has been instantiated on a NPU, for which the UAPI is still experimental
[ 5.121842] [drm] Initialized etnaviv 1.4.0 for etnaviv on minor 0
systemd начинает работать примерно в это время:
[ 2.318927] systemd[1]: systemd 252.33-1~deb12u1 running in system mode (+PAM +AUDIT
+SELINUX +APPARMOR +IMA +SMACK +SECCOMP +GCRYPT -GNUTLS +OPENSSL +ACL +BLKID +CURL
+ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP +LIBFDISK +PCRE2 -PWQUALITY +P11KIT
+QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD -BPF_FRAMEWORK -XKBCOMMON +UTMP +SYSVINIT
default-hierarchy=unified)
Но затем идет второй этап инициализации DRM, который фактически включает поток вывода на дисплей:
[ 6.904837] imx-dwmac 30bf0000.ethernet end0: Register MEM_TYPE_PAGE_POOL RxQ-0
[ 6.971593] imx-dwmac 30bf0000.ethernet end0: PHY [stmmac-0:00] driver [SMSC LAN8710/LAN8720] (irq=147)
[ 6.987060] imx-dwmac 30bf0000.ethernet end0: No Safety Features support found
[ 6.994331] imx-dwmac 30bf0000.ethernet end0: IEEE 1588-2008 Advanced Timestamp supported
[ 7.002765] imx-dwmac 30bf0000.ethernet end0: registered PTP clock
[ 7.009583] imx-dwmac 30bf0000.ethernet end0: configuring for phy/rmii link mode
[ 8.601862] imx-dwmac 30bf0000.ethernet end0: Link is Up - 100Mbps/Full - flow control rx/tx
[ 15.334021] samsung-dsim 32e60000.dsi: supply vddcore not found, using dummy regulator
[ 15.343694] samsung-dsim 32e60000.dsi: supply vddio not found, using dummy regulator
[ 15.365379] samsung-dsim 32e60000.dsi: [drm:samsung_dsim_host_attach [samsung_dsim]] Attached sn65dsi83 device (lanes:4 bpp:24 mode-flags:0x2e3)
[ 15.380621] [drm] Initialized imx-lcdif 1.0.0 for 32e80000.display-controller on minor 1
[ 15.522131] Console: switching to colour frame buffer device 240x45
[ 15.555056] imx-lcdif 32e80000.display-controller: [drm] fb0: imx-lcdifdrmfb frame buffer device
[ 15.592315] dw100 32e30000.dwe: dw100 v4l2 m2m registered as /dev/video0
[ 15.601817] hantro-vpu 38300000.video-codec: registered nxp,imx8mm-vpu-g1-dec as /dev/video1
[ 15.611540] hantro-vpu 38310000.video-codec: registered nxp,imx8mq-vpu-g2-dec as /dev/video2
Между этими двумя этапами инициализации проходит случайный разрыв в 10 секунд, и я не понимаю почему.
systemd-analyze:
systemd-analyze
Startup finished in 2.034s (kernel) + 4.558s (userspace) = 6.592s
graphical.target reached after 4.450s in userspace.
Заранее спасибо за любую помощь!
Похоже, что у вас есть некоторые, но не все драйвера, доступные в ядре/initramfs. Момент, когда “systemd берет на себя” – это когда выполнение переключается с initramfs на основную корневую файловую систему (и начинает применять все udev правила) – так что первый этап в вашем примере загружает драйвера, которые либо встроены в ядро, либо доступны как модули (*.ko файлы) в initramfs или initrd, в то время как второй этап загружает все оставшиеся модули из основной rootfs.
Поэтому, если у вас есть initramfs, измените его процесс сборки, чтобы копировать больше модулей, которые необходимы для отображения – например, imx-lcdif “контроллер дисплея” кажется очень актуальным. Если у вас нет initramfs, сделайте то же самое с процессом компиляции ядра, переключив эти драйвера с “модуля” на “встроенный” (=y).
Используя этот совет, я смог отследить проблему до узла blk-ctrl. Он имел зависимость от подсистемы noc, которая не была включена в конфигурации ядра. Я не знаю, почему это вообще работает без этого драйвера, но да, это исправило проблему.
Ответ или решение
Поиск и устранение неисправностей, связанных с задержкой инициализации DRM (Digital Rights Management) в системе, может быть сложной задачей, особенно в контексте миграции устройства на встроенном Linux с ядра поставщика на основное ядро. Рассмотрим вашу ситуацию более подробно и обсудим возможные подходы к решению этой проблемы.
Теоретическая часть (Theory)
Инициализация DRM в рамках ядра Linux состоит из нескольких этапов, которые включают в себя загрузку и инициализацию различных графических драйверов и зависимых от них подсистем. Обычно процесс инициализации начинается с выполнения начальной настройки графического оборудования, например, GPU, и завершается включением дисплейного потока и передачи управления графической оболочке.
В вашем случае инициализация GPU происходит достаточно быстро, но затем следует значительная задержка, прежде чем поток дисплея действительно активируется. Это может случаться по ряд причин, включая:
-
Недостаточная загрузка модулей на ранних этапах инициализации: Отсутствие некоторых необходимых драйверов или компонентов внутри initramfs может вызывать зависимость инициализации от загрузки дополнительных модулей во время старта системы.
-
Отложенные зависимости драйверов: Например, если определенные модули, такие как
imx-lcdif, не интегрированы в initramfs, их инициализация будет отложена до загрузки основной файловой системы. -
Ошибки конфигурации ядра: Может иметь место отсутствие активации необходимых параметров и драйверов в конфигурации ядра, что препятствует своевременному прохождению инициализации.
-
Зависимости от подсистем: Есть вероятность, что некоторые компоненты зависят от других подсистем, которые могут инициализироваться позже due к отсутствию или неправильной настройке в конфигурации ядра.
Пример (Example)
В вашем случае проблема была идентифицирована через доскональную проверку загрузочного процесса и анализ зависимостей, как это было подробно описано в соответствующих источниках. Оказалось, что узел blk-ctrl имел зависимость от подсистемы noc, которая, в свою очередь, не была активирована в конфигурации ядра. После включения необходимого драйвера проблема была успешно решена.
Применение (Application)
Чтобы применить этот подход на практике, вы можете рассмотреть следующие шаги:
-
Анализ и настройка initramfs: Проверьте, что в процессе создания initramfs интегрируются все необходимые модули драйверов, связанные с инициализацией DRM. Это можно сделать с помощью инструментов, таких как
dracutилиupdate-initramfs, которые могут быть настроены для включения необходимых модулей. -
Конфигурация ядра: Обязательно пересмотрите конфигурацию ядра на предмет включения всех необходимых драйверов и компонентов, которые могут повлиять на графическую инициализацию. Это может быть достигнуто путем настройки конфигурационного файла
.configи перевода необходимых опций из состояния модуляmв встроенныеy. -
Проверка зависимостей подсистем: Подобно найденному вами решению, стоит уделить внимание подсистемам с отложенной инициализацией и их зависимостям. Полезно использовать лог загрузки и dmesg, чтобы находить соответствующие сообщения об ошибках и предупреждениях.
-
Узлы дерева устройств (Device Tree Nodes): Убедитесь, что в файле дерева устройств (Device Tree Source – DTS) правильно настроены все узлы, связанные с графическими компонентами. Это может включать корректное указание источников питания, частот работы и других аппаратных параметров.
-
Мониторинг процесса загрузки: Используйте
systemd-analyzeи другие отладочные средства для мониторинга времени загрузки и выявления узких мест. Это поможет сфокусироваться на критических участках, которые вызывают задержки.
Следуя этой подробной методологии можно оптимизировать процесс инициализации DRM и обеспечить более гладкую работу графического стека в вашей Linux системе на основе SOC IMX8MP.