From: "Ivan A. Melnikov" <iv@altlinux.org>
To: "Мишаня Бессонов" <heliumium1997@gmail.com>
Cc: devel-kernel@lists.altlinux.org
Subject: Re: [d-kernel] [PATCH] arm64: dts: rockchip: fix compatible string for Repka Pi 5
Date: Tue, 18 Aug 2026 00:01:44 +0400
Message-ID: <aoNenls-K_RsN_wY@iv-work> (raw)
In-Reply-To: <CAD5ZN+0b7e3uZKR7UwLjYS30RiGGEnnXagPtwp+4g1TE=RZ-zQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 5367 bytes --]
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.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 870 bytes --]
next prev parent reply other threads:[~2026-08-17 20:01 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-17 10:59 Мишаня Бессонов
2026-08-17 11:28 ` Ivan A. Melnikov
2026-08-17 11:39 ` Мишаня Бессонов
2026-08-17 20:01 ` Ivan A. Melnikov [this message]
2026-08-19 9:45 ` Мишаня Бессонов
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aoNenls-K_RsN_wY@iv-work \
--to=iv@altlinux.org \
--cc=devel-kernel@lists.altlinux.org \
--cc=heliumium1997@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
ALT Linux kernel packages development
This inbox may be cloned and mirrored by anyone:
git clone --mirror http://lore.altlinux.org/devel-kernel/0 devel-kernel/git/0.git
# If you have public-inbox 1.1+ installed, you may
# initialize and index your mirror using the following commands:
public-inbox-init -V2 devel-kernel devel-kernel/ http://lore.altlinux.org/devel-kernel \
devel-kernel@altlinux.org devel-kernel@altlinux.ru devel-kernel@altlinux.com
public-inbox-index devel-kernel
Example config snippet for mirrors.
Newsgroup available over NNTP:
nntp://lore.altlinux.org/org.altlinux.lists.devel-kernel
AGPL code for this site: git clone https://public-inbox.org/public-inbox.git