[d-kernel] [PATCH] arm64: dts: rockchip: fix compatible string for Repka Pi 5

Ivan A. Melnikov iv на altlinux.org
Пн Авг 17 23:01:44 MSK 2026


On Mon, Aug 17, 2026 at 03:39:17PM +0400, Мишаня Бессонов wrote:
> 1. Как compatible влияет на загрузчик:
> Современные версии U-Boot (включая 2025.10) используют FIT-образ
> (Flattened Image Tree) для мультиплатформенных сборок. При старте загрузчик
> считывает строку compatible из системного дерева устройств платы
> (или DTB, вшитого в SPL) 

Именно из DTB, "вшитого" в u-boot. C тем, что прописано в DTB ядра
это никак не связано, на этом этапе DTB ядра ещё не прочитано
из файловой системы. SPL обычно даже не в курсе, что на свете
существуют файловые системы.

> и сопоставляет её со списком поддерживаемых
> конфигураций.

> Если строки не совпадают (например, загрузчик ищет "repka,repka-pi5",
> а в переданном ядром DTS 

Это загрузчик передаёт DTS ядру, а не наоборт.

> написано "repka,pi5"), механизм автоматического
> сопоставления FIT и валидации
> fdtfile может не отработать корректно без жесткого ручного
> переназначения переменных окружения.

Я буквально посмотрел в исходники вендорского U-Boot (а Вы?)
и не увидел там ничего такого. Однако я не могу быть на 100%
уверен, что это *те самые* исходники, и что я ничего не опустил.
Поэтому я вполне открыт к техническому диалогу.

Покажите код (например, из вендорского репозитория U-Boot)
или отрывки логов загрузки, которые убедительно
демонстрируют, что Вы правильно интерпретируете поведение
U-Boot. Написанные с помощью LLM общие слова не принимаются
в качестве аргумента в технической дискуссии.

Вы тестировали этот патч? Вы сравнивали логи U-Boot до и после?
Покажите разницу. Не описывайте, а покажите. Даже
включите её самую релевантную чать в commit message.

> 2. Откуда взялась строка:
> Признаю, что в первоначальном патчсете строка "repka,pi5" была указана
> мной ошибочно
> (в качестве заглушки при адаптации под mainline-интерфейсы 6.18).

Печально. Больше так не делайте.

> При финальном тестировании сборки официального загрузчика
> u-boot-2025-10 для Repka Pi 5 из
> репозитория производителя, анализ итогового бинарного артефакта
> u-boot-rockchip.bin с помощью
> утилиты strings показал, что загрузчик жестко завязан на токен
> "repka,repka-pi5":
> 
> $ strings u-boot-rockchip.bin | grep repka
> fdt-rockchip/rk3588-repka-pi5
> repka,repka-pi5
> rockchip/rk3588-repka-pi5.dt
> fdtfile=rockchip/rk3588-repka-pi5.dtb
> repka,repka-pi5

Естественно там будет "repka,repka-pi5", оно же прописано в собственном
DTB U-Boot'а.

> Данный токен генерируется на этапе сборки загрузчика из
> конфигурационных параметров дефконфига
> платы (параметры CONFIG_DEFAULT_DEVICE_TREE и CONFIG_OF_LIST).

Эти CONFIG'и задают имена файлов и никак не связаны
c compatible-строками.

> Предлагаемый патч устраняет это рассогласование между актуальным
> деревом устройств в
> ядре ALT и ожиданиями собираемого загрузчика, обеспечивая старт
> системы "из коробки". Что касается
> каноничности строки у производителя — в их текущих репозиториях ядра и
> загрузчика присутствует
> рассинхронизация префиксов, но данный патч приводит DTS ядра к
> фактическому общему
> знаменателю с их же бинарником U-Boot.

Если эта "рассинхронизация" не мешает работать вендрскому ядру,
то и нашему не должна мешать.

Какую проблему Вы пытаетесь решить?

-- 
  wbr,
    iv m.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 870 bytes
Desc: not available
URL: <http://lists.altlinux.org/pipermail/devel-kernel/attachments/20260818/f4a77efd/attachment-0001.bin>


Подробная информация о списке рассылки devel-kernel