NanoPi A64

Решил я обновить парк домашних одноплатных компьютеров, попутно его унифицировав. Выбор мой пал на плату NanoPi A64. Нуачо? Ядром поддерживается чип? Да! Включая USB и Ethernet? Да! Device tree под неё есть? Да! Берём!) Но нет… Всё оказалось совсем не так просто!

Во-первых, device tree для данной платы, который идёт в составе ядер, вплоть до 4.19-rcN, ничего не знает о ethernet. И, кажется, напряжение регуляторов кривое прописано. Device tree из U-Boot’а полностью повторяет device tree из состава ядра. Пришлось править, добавив тот самый ethernet и, на мой взгляд, правильные значения для регуляторов.

Во-вторых, U-Boot нынче мало того, что компилится только с ARM Trusted Firmware, так ещё и разучился делать bootz. На arm64 он умеет только booti и «ARM64 Image format». Хуки для ядра пришлось переписать.

В-третьих, внезапно оказалось, что в пакете с ядром идущий файл vmlinuz, на самом деле, не vmlinuz, а vmlinux (vmlinuz — это vmlinux в gz). То есть ребята из Debian, отметив недоработки в U-Boot’е, тупо сменили формат ядра, без смены его названия. Кстати, ‘make deb-pkg’, ещё более внезапно, укладывает в пакет настоящий vmlinuz. И машина у тебя, после установки, встаёт колом с ошибкой «Bad Linux ARM64 Image magic!». И если бы случайно не посмотрел на /boot флешки в графике, то ещё не известно, сколько бы я думал о причинах появления данной ошибки…

В-четвёртых, A64 имеет ошибку в проектировании RTC. Насколько я понял из штудирования списка рассылки linux-sunxi, ошибка вызвана подбором задающего генератора. И, при ряде условий, вызовы к таймеру возвращают отрицательное значение. Что приводит к улёту часов на почти 100 лет вперёд. Мне исключительно повезло, что я был подписан на эту рассылку и запомнил, как приходило письмо «A64 timer unstable бла-бла-бла»… Это тоже ускорило поиск проблемы.

В-пятых, как оказалось, существует интерфейс хуков для различных системных вызовов. Это такой массив, в котором существуют вложенные массивы со ссылками на хуки и условия их вызова. Собственно это явное усложнение внесено ради обеспечения переносимости ядра. Ведь все эти чипсеты ARM’овые прямо таки нафаршированы ошибками. И раньше для каждого из них было своё ответвление ядра, часто отстающее от основной версии, часто содержащее критические и уродливые одновременно правки… Но это всё работало шустрей, чем сейчас. Привет тем, кто считает, что 2.6.32 было быстрей. Да, было. Конструктивно быстрей.

Ну и, в-шестых, оказалось, что недостаточно написать рабочий и лаконичный патч. Если производитель железки не считает нестабильное поведение реальной ошибкой и не открывает errata, то в Mainline твой патч для этой ошибки не попадёт. Потому что «А к чему это твой патч применим?».

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

× 9 = 18