Инициализация ram на Rockchip rk356x, теперь opensource

Добавил в избранное.

Если будет время потестирую на паре плат на RK3568.

Только просьба не использовать merge с основным деревом. А держать как патч-сет. Можно даже с периодическим rebase как делают тут https://gitlab.collabora.com/hardware-enablement/rockchip-3588

Или пачкой веток. Каждая из которых будет версионным патч-сетом (аля 2026.07.01-rc1-rockchip-rkinit-v0.1-dev).

Главное, что бы можно было всегда взять и создать набор патчей для Buildroot/Yocto только из верхних коммитов.

И это будет полезно, в случае интереса к отправке патчей в Mainline U-Boot.

Немного оффтопный вопрос: а почему инициализация контроллера вообще целых 50кб занимает? Там же должно быть прописывание каких-то чисел в его регистры по списку и всё, разве нет? С ним же не надо потом работать никак.

Отправить в upstream интересно, только надо сначала понять что оно работает. В идеале ещё добавить DDR4, но для этого надо сесть и посчитать тайминги, да поотлаживаться. Не уверен что сходу заработает.

Патчсет практически ничего не трогает кроме clock controller (вырезал вообще всё управление clock’ами из TPL, по скольку SDRAM всего 59,5Кб на всё про всё), да добавил пару syscon. Вообще, можно было ограничиться только кодом в drivers/ram/rockchip, как сделано в инициализаторе для rv1126, но в итоге всё равно придётся завязываться на dts, чтобы сделать выбор разных частот для rk3568 и rk3566. По другому никак, по скольку конфиг u-boot ничего про rk3566 как чип не знает.

Ну, не совсем. Для начала надо определить что за оперативка к тебе подоткнута. У неё могут быть разные конфигурации по размеру и по количеству рангов.

Дальше история в том что там есть DFS. То есть, динамическое управление частотой памяти. Условно, когда не смотришь видео в 4к, частоту можно и подзанизить чтобы поберечь батарейку.

Ещё современную оперативку нужно тренировать. По скольку частоты высокие, длинна дорог до чипа имеет значение. А каждый инженер может на своей плате развести дороги по-своему. Ну и на заводе где-то поднакосячить могут.

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

Правда, opesource поддержки DFS нету. Она должна быть в ARM trusted firmware. Но там (наверное) уже как раз проще: всё на тренировано на 4 частоты, просто щёлкай между ними когда тебя попросят.

Не забываем ещё про размер указателя в 64 бита, который ужирняет бинарь.

Поскольку «Рокчип» как-то не торопился открывать исходники бинаря для инициализации контроллера оперативной памяти на rk356x, я, потратив прилично времени на реверс, сделал это за них.

А техническое описание микропроцессора «рокчиповцы» не дают по запросу? Если прочитать техописание самого микропроцессора, то по описанию его регистров, отвечающих за взаимодействие с оперативной памятью, можно же самому написать заново начальную настройку и калибровку оперативной памяти и не заниматься дизассемблированием чужого исполняемого файла.

Полагаю что увы.

Чтобы правильно рассчитать задержки нужно иметь полную документацию на DDR PHY. Думаю, Innosilicon даёт её только тем кто купил у них эту PHY. А в описании «рокчиповцов» только сухие регисты.

Вот ты звапустил тренировку write leveling для опреативки, оно дало тебе какие-то значения в регистрах. А как правильно это дело пересчитать c учётом текущей частоты и остальных задержек знает только «рокчип» да Innosilicon.

Не говоря уже об особенностях взаимодействия контроллера DDR с DDR PHY.

Вот ты звапустил тренировку write leveling для опреативки, оно дало тебе какие-то значения в регистрах. А как правильно это дело пересчитать c учётом текущей частоты и остальных задержек знает только «рокчип» да Innosilicon.

Если поставить себя на место производителя микропроцессоров «Рокчипа» и принять твои слова за текущее положение дел, то кто по-твоему будет покупать микросхемы у «Рокчипа»? Разработчики электронной аппаратуры изготовят свои устройства на процессорах «Рокчипа», а откалибровать микросхемы оперативной памяти не смогут?

Обычно данные для калибровки оперативной памяти выдаёт производитель микропроцессоров, чтобы его микросхемы хоть кто-то купил. Если производитель микросхем не выдаёт эти технические документы по запросу радиолюбителя, то эти документы вполне можно получить у оптового продавца микросхем в твоей местности. То есть всего-то нужно узнать кто именно является рукопожатным продавцом микросхем «Рокчипа» в нашей стране и обратиться к этому продавцу за документацией.

Что-то там дизассемблировать это несерьёзно же. Гораздо лучше работать с документами производителя электронных компонентов - так ошибок будет гораздо меньше.

Разработчики электронной аппаратуры изготовят свои устройства на процессорах «Рокчипа», а откалибровать микросхемы оперативной памяти не смогут?

Дела обстоят так, что «Рокчип» выдаёт список поддерживаемых микросхем оперативной памяти, и бинарный файл который умеет эти поддерживаемые микросхемы калибровать.

И действительно, если микросхема заявлена как поддерживаемая, но при этом не калибруется бинарным файлом, то можно написать в «Рокчип», и они исправят проблему в этом бинаром файле.

А вот инструкций для самостоятельной инициализации оперативной памяти, полагаю, не существует. По крайней мере за 6 лет никто открытую реализацию не написал.

А техническое описание микропроцессора «рокчиповцы» не дают по запросу?

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

Интересно послушать про сам процесс исследования бинаря. Какой формат? Какие инструменты для декомпиляции/дизассемблер использовали? Как найти точку начала исполнения и т.п.

UPD: Но сама работа - огонь! Спасибо!

На удивление, там ничего сверхъестественного.

Начал с bootrom. Сдампить было довольно просто, bootrom доступен для чтения в u-boot SPL, так что написал код который выплёвывает его в hex на UART. На этом этапе мыслей лезть в бинарь с инициализацией оперативки ещё не возникало. Однако, в bootrom нашлась очень интересная деталь: на самом деле bootrom ищет дальнейшие стадии загрузки не по фиксированному смещению на флешке, а делает аж 5 попыток по разным. Ну, то есть, сначала смотрит 64й сектор флешки в поисках заголовка следующего загрузчика, и, если не находит, прибавляет 1024 сектора и смотрит на 1088й.

И тут я подумал: есть же замечательная инициатива прикрутить Verified Boot For Embedded к u-boot. Это про то как обновлять u-boot из Linux не задумываясь о том чтобы превратить устройство в кирпич. И в этом документе Simon пишет:

For SoCs with more SRAM (such as RK3588) it would be possible to put everything in one FIT. For SoCs with a lot less SRAM, probably the only option would be to init the SDRAM early in boot, living with the inability to safely update that code later.

Но почему бы тогда не воспользоваться механизмом поиска дальнейших загрузчиков в bootrom, и не сделать нормальное A/B обновление для инициализации оперативки в том числе? Алгоритм должен быть таким: первым делом запускаем VPL, тот смотрит какой слот нам надо горузить, A или B, сохраняет где-то то что он насмотрел. 60Кб SRAM должно хватить на драйвер для SD/eMMC и немного обвязки. Дальше VPL вываливается с ошибкой. Bootrom находит следующий валидный заголовок, из которого запускается инициализация оперативки. Инициализация оперативки смотрит на результат работы VPL, и, если понимает что должна отработать (слот A), то отрабатывает, если нет, то вываливается с ошибкой чтобы bootrom искал дальше то что должно быть в слоту B.

Но для того чтобы это работало нам нужен opensource код для инициализации оперативки, чтобы добавить туда проверку на результат работы VPL…

Бинарь с оперативкой на самом деле просто bare arm64. u-boot при сборке заботливо оборачивает его в заголовок который понимает bootrom. Так что заменить бинарь на собранный из исходников u-boot TPL проблем не составило. Куда в SRAM грузится бинарь стало понятно из bootrom. Ещё сильно помог код инициализации оперативки для RV1126. Там инкарнация той же PHY, только она сильно размазана по регистрам. Но CA Training там вообще не реализован. К слову, инициализацию для RV1126 выложил сам Rockchip как часть своего форка u-boot. Описание регистров контроллера и PHY в TRM для RK3568 сильно куцее, поэтому пришлось половину додумывать и угадывать. Но самое обидное что нормальное описание есть в TRM к RK3562, и наткнулся я на него только тогда когда инициализация оперативки заработала. Так что пришлось переименовывать все свои догадки в соответствие с нормальным описанием регистров.

Из инструментов – Ghidra.

Сходу нашел Rockchip_RK3568_TRM_Part1_V1.3-20220930P.pdf на 852 страницы и Rockchip_RV1126B_TRM_Part_1_V1.0_20250427_(public).pdf на 1365. Они?

Жаль только потестить не смогу - у меня только PinePhone Pro на RK3399S.

Про гидру какие-то страшилки слышал, но сам не пробовал. А почему кстати не Radare2, например? Удобнее или фичи какие в гидре есть?

UPD: Иииии я открыл для себя Паленый мед. Спасибо и за это!

Скорее RK3568 TRM Part 2, глава про DMC, начиная с 16й страницы, RV1109-RV1126 TRM Part 2, тоже про DMC, с 17й страницы, RK3562 TRM Part 1, опять про DMC, 760я страница (там регистров побольше чем у rk3566/8, чего-то нового досыпали, у rk3566/8 BYTE секции начинаются с 0x300), ну и на закуску примерное описание interconnect (memory scheduler) в RK3588 TRM Part 2, страница 16.

Про гидру какие-то страшилки слышал, но сам не пробовал.

Там в отличие от radre есть достаточно достойный декомпилятор.

Что-то там дизассемблировать это несерьёзно же. Гораздо лучше работать с документами производителя

Для дизассемблирования нужны одни навыки, для добывания документации абсолютно другие. Тут уж кто что умеет.

А bootrom - это стартовый код, который прошит на заводе где-то в сам чип, и запускается непосредственно после подачи питания (в доках ARM, насколько я помню, он называется BROM)? А откуда ты его читал, т.е. по каким адресам?

Он самый.

RK3568 TRM Part 1, стр. 13. Таблица 1-2 Address Remapping.

Так что 0xffff0000. Его там 32 килобайта. В конце после нулей некая ASCII последовательность. Видимо, версия bootrom. Мой заканчивается на 350A20210322V300

Спасибо