Created attachment 18128 [details] make-initrd bug-report На одноплатнике Orange Pi 5 (Rockchip RK3588S) make-initrd не добавляет модуль phy_rockchip_samsung_hdptx (/lib/modules/6.14.0-6.14-alt1/kernel/drivers/phy/rockchip/phy-rockchip-samsung-hdptx.ko.zs t). Samsung HDMI/eDP Transmitter Combo PHY Driver. Из-за этого HDMI в initrd не включается.
Created attachment 18129 [details] make-initrd -v
Он не нужен ни для рута ни для gpu-drm. В рамках какой фичи ты предполагаешь, что make-initrd должен был добавить его ?
(Ответ для Alexey Gladkov на комментарий #2) > Он не нужен ни для рута ни для gpu-drm. > > В рамках какой фичи ты предполагаешь, что make-initrd должен был добавить > его ? Полагаю, что gpu-drm. Но нужен он для plymouth. rockchipdrm бесполезен без этого модуля на RK3588.
Я пока не нашёл в sysfs связи между rockchipdrm и phy-rockchip-samsung-hdptx. Я очень поверхностно посмотрел код rockchipdrm и если я правильно понял, hdmi является опциональной зависимостью. Я не уверен, но кажется, что это задаётся в device tree. Если это так, то это очень печально. Я очень не хотел лезть в device tree.
У тебя на этой машинке стоит пакет dtc ? find /proc/device-tree/ -type f -exec head {} + > device-tree-from-proc Можешь приложить результат команды ?
Created attachment 18136 [details] device-tree-from-proc
(Ответ для Alexey Gladkov на комментарий #5) > У тебя на этой машинке стоит пакет dtc ? > да > find /proc/device-tree/ -type f -exec head {} + > device-tree-from-proc > > Можешь приложить результат команды ? приложил
(In reply to Антон Мидюков from comment #7) > > find /proc/device-tree/ -type f -exec head {} + > device-tree-from-proc > > > > Можешь приложить результат команды ? > > приложил блин, там та же информация, что и в /sys/firmware/devicetree/base ((( Я пока не знаю как испавить проблему. Если у вас там есть знающие люди, то буду рад советам.
Я ничего не знаю про одноплатники и dts, но посмотрел https://github.com/armbian/build . Насколько я вижу в большинстве конфигураций ядра делается CONFIG_PHY_ROCKCHIP_SAMSUNG_HDPTX=y . https://github.com/search?q=repo%3Aarmbian%2Fbuild%20hdptx&type=code
(Ответ для Alexey Gladkov на комментарий #9) > Я ничего не знаю про одноплатники и dts, но посмотрел > https://github.com/armbian/build . Насколько я вижу в большинстве > конфигураций ядра делается CONFIG_PHY_ROCKCHIP_SAMSUNG_HDPTX=y . > > https://github.com/search?q=repo%3Aarmbian%2Fbuild%20hdptx&type=code Armbiam под каждый SoC собирают своё ядро, поэтому все базовые модули встраивают. У Fedora, как модуль собирается: https://src.fedoraproject.org/rpms/kernel/blob/f41/f/kernel-aarch64-fedora.config#_6082 Но если другого выхода нет, то придётся встраивать. А нельзя все загруженные модули из drivers/phy/ включать в initrd?
(In reply to Антон Мидюков from comment #10) > (Ответ для Alexey Gladkov на комментарий #9) > > Я ничего не знаю про одноплатники и dts, но посмотрел > > https://github.com/armbian/build . Насколько я вижу в большинстве > > конфигураций ядра делается CONFIG_PHY_ROCKCHIP_SAMSUNG_HDPTX=y . > > > > https://github.com/search?q=repo%3Aarmbian%2Fbuild%20hdptx&type=code > > Armbiam под каждый SoC собирают своё ядро, поэтому все базовые модули > встраивают. Я к тому, что даже у них мне удалось найти способа детекта связи между модулями. > У Fedora, как модуль собирается: > https://src.fedoraproject.org/rpms/kernel/blob/f41/f/kernel-aarch64-fedora. > config#_6082 > > Но если другого выхода нет, то придётся встраивать. > > А нельзя все загруженные модули из drivers/phy/ включать в initrd? Также в случае fedora. В dracut нет способа его детектировать и они просто добавляют здоровый список директорий для определённых архитектур: https://github.com/dracutdevs/dracut/blob/master/modules.d/90kernel-modules/module-setup.sh#L82 У меня уже есть фича modules-sbc которая приносит примерно тот же список модулей. Ты думаешь стоит делать такой же guess как в dracut по архитектуре или можно просто добавлять modules-sbc для таких одноплатников ?
(Ответ для Alexey Gladkov на комментарий #11) > (In reply to Антон Мидюков from comment #10) > > (Ответ для Alexey Gladkov на комментарий #9) > > > Я ничего не знаю про одноплатники и dts, но посмотрел > > > https://github.com/armbian/build . Насколько я вижу в большинстве > > > конфигураций ядра делается CONFIG_PHY_ROCKCHIP_SAMSUNG_HDPTX=y . > > > > > > https://github.com/search?q=repo%3Aarmbian%2Fbuild%20hdptx&type=code > > > > Armbiam под каждый SoC собирают своё ядро, поэтому все базовые модули > > встраивают. > > Я к тому, что даже у них мне удалось найти способа детекта связи между > модулями. > > > У Fedora, как модуль собирается: > > https://src.fedoraproject.org/rpms/kernel/blob/f41/f/kernel-aarch64-fedora. > > config#_6082 > > > > Но если другого выхода нет, то придётся встраивать. > > > > А нельзя все загруженные модули из drivers/phy/ включать в initrd? > > Также в случае fedora. В dracut нет способа его детектировать и они просто > добавляют здоровый список директорий для определённых архитектур: > > https://github.com/dracutdevs/dracut/blob/master/modules.d/90kernel-modules/ > module-setup.sh#L82 > > У меня уже есть фича modules-sbc которая приносит примерно тот же список > модулей. > > Ты думаешь стоит делать такой же guess как в dracut по архитектуре или можно > просто добавлять modules-sbc для таких одноплатников ? Хотелось избежать большого initrd при эксплуатации. modules-sbc добавляет все каталоги с модулями в независимости от их использования. В результате initrd загрузится на любом одноплатнике. Включать эту фичу автоматически точно не стоит. Я предлагал добавлять только используемые модули из определённых каталогов. При использовании ACPI эти модули не используются. На aarch64 есть сервера с ACPI, которым такой initrd не нужен точно.
(In reply to Антон Мидюков from comment #12) > > Также в случае fedora. В dracut нет способа его детектировать и они просто > > добавляют здоровый список директорий для определённых архитектур: > > > > https://github.com/dracutdevs/dracut/blob/master/modules.d/90kernel-modules/ > > module-setup.sh#L82 > > > > У меня уже есть фича modules-sbc которая приносит примерно тот же список > > модулей. > > > > Ты думаешь стоит делать такой же guess как в dracut по архитектуре или можно > > просто добавлять modules-sbc для таких одноплатников ? > > Хотелось избежать большого initrd при эксплуатации. modules-sbc добавляет > все каталоги с модулями в независимости от их использования. В результате > initrd загрузится на любом одноплатнике. Включать эту фичу автоматически > точно не стоит. Просто ты привёл в пример fedora, а там логика эквивалент modules-sbc для архитектрур arm*, aarch64, riscv* . Я подумал, что твоё предложение было в том, чтобы сделать такой же угадав у нас. > Я предлагал добавлять только используемые модули из определённых каталогов. Просто смотреть на загруженные в данный момент модули ? > При использовании ACPI эти модули не используются. На aarch64 есть сервера с > ACPI, которым такой initrd не нужен точно.
(Ответ для Alexey Gladkov на комментарий #13) > (In reply to Антон Мидюков from comment #12) > > > Также в случае fedora. В dracut нет способа его детектировать и они просто > > > добавляют здоровый список директорий для определённых архитектур: > > > > > > https://github.com/dracutdevs/dracut/blob/master/modules.d/90kernel-modules/ > > > module-setup.sh#L82 > > > > > > У меня уже есть фича modules-sbc которая приносит примерно тот же список > > > модулей. > > > > > > Ты думаешь стоит делать такой же guess как в dracut по архитектуре или можно > > > просто добавлять modules-sbc для таких одноплатников ? > > > > Хотелось избежать большого initrd при эксплуатации. modules-sbc добавляет > > все каталоги с модулями в независимости от их использования. В результате > > initrd загрузится на любом одноплатнике. Включать эту фичу автоматически > > точно не стоит. > > Просто ты привёл в пример fedora, а там логика эквивалент modules-sbc для > архитектрур arm*, aarch64, riscv* . Я подумал, что твоё предложение было в > том, чтобы сделать такой же угадав у нас. > > > Я предлагал добавлять только используемые модули из определённых каталогов. > > Просто смотреть на загруженные в данный момент модули ? > Да. Но с учётом того, что у текущего они могут быть built-in, а у целевого в виде модулей.
(In reply to Антон Мидюков from comment #14) > Да. Но с учётом того, что у текущего они могут быть built-in, а у целевого в > виде модулей. У builtin модулей нет filename. У них есть только file (которого нет у загружаемых модулей). Их не получится просто grep'ать. Для фильтрации придётся конструировать filename в ручную. Плюс у в разных ядрах ещё и имена модулей могут различаться. Сейчас мы вообще не смотрим на загруженные модули. С builtin есть другая проблема. Наличие модуля такого модуля определяется не по ядру, а по файлу modules.builtin.modinfo. В этот сейчас файл не всё попадает. Мне как-то Глеб рассказывал, что кое-что пролетает мимо. Я всё никак не собирусь попробовать исправить. Но допустим я получил список загруженных и buildin модулей, какие модули модули фильтровать таким образом ?
(Ответ для Alexey Gladkov на комментарий #15) > (In reply to Антон Мидюков from comment #14) > > Да. Но с учётом того, что у текущего они могут быть built-in, а у целевого в > > виде модулей. > > У builtin модулей нет filename. У них есть только file (которого нет у > загружаемых модулей). Их не получится просто grep'ать. Для фильтрации > придётся конструировать filename в ручную. Плюс у в разных ядрах ещё и имена > модулей могут различаться. > > Сейчас мы вообще не смотрим на загруженные модули. > > С builtin есть другая проблема. Наличие модуля такого модуля определяется не > по ядру, а по файлу modules.builtin.modinfo. В этот сейчас файл не всё > попадает. Мне как-то Глеб рассказывал, что кое-что пролетает мимо. Я всё > никак не собирусь попробовать исправить. > > Но допустим я получил список загруженных и buildin модулей, какие модули > модули фильтровать таким образом ? Раз это столь сложно, то builtin в расчёт не стоит брать.
Я сделал вот такой набросок: https://github.com/osboot/make-initrd/commit/c89c2ae458f14efa1ca33ccd8539ea67b13b05aa такое подойдёт ?
Есть ещё одна мысль. Добавить udev правило для загрузки phy_rockchip_samsung_hdptx на такой плате. Тут обнаружилась бага в make-initrd, который не смотрит на `kmod load foo`. Но когда это будет исправлено, то можно будет пользоваться udev rules.
(In reply to Alexey Gladkov from comment #18) > Есть ещё одна мысль. Добавить udev правило для загрузки > phy_rockchip_samsung_hdptx на такой плате. Туплю. Нельзя этим пользоваться. Но бага с поиском модулей всё равно есть.
(Ответ для Alexey Gladkov на комментарий #17) > Я сделал вот такой набросок: > > https://github.com/osboot/make-initrd/commit/ > c89c2ae458f14efa1ca33ccd8539ea67b13b05aa > > такое подойдёт ? Не работает, потому что условие не выполняется: [ -s "/lib/modules/$cur_kver/modules.builtin.modinfo" ] || return 0 Поменял на -f и заработало. Вполне подойдёт.
