arm64 для raspberry pi 3

Одно из преимуществ: доступен AES-NI. Вместо 12 h/s будет аж 24 h/s!

Правильнее 32-битная. Потому что некоторый софт уже выпущен для armhf, но ещё не выпущен для aarch64. Кроме того, экономия памяти. Её, правда, дофига - целый гиг.

Raspbian пока недоступен, но есть любительская сборка 64-битного ядра.

В гентувики писали, что 64 битные сборки для RPi3 пока что нестабильные, без пояснений, почему. Может ситуация улучшилась с тех пор. Попробуй, нам расскажешь

В fedora это тоже первый релиз aarm64 который в принципе на rpi можно накатить. Так что это как раз нормально.

Я только не понимаю зачем она.

Ну то есть у меня есть гипотеза, что это для локального тестирования софта, в итоге предполагаемого для работы на каких-то «больших» arm. Тогда для работы с собственно RPi самой по себе это не нужно. Но может там какие-то отдельные бонусы ещё?

ну скорость в криптографических вычислениях, регистры больше, все дела

А по поводу попробовать, я тут уже неделю читаю про Device Tree.

И единственное, что могу сказать, это что C-программерам надо законодательно запретить изобретать YAML.

Это же компилируемый декларативный конфиг. Почему нельзя было сделать его исходники хоть немного читаемыми?!

Есть в планах gentoo arm64 для неё, но пока arm7 функционирует только формально.

В вике было что то вроде того, что 64-битный режим включается командой в конфиге загрузчика, после этого ему надо подсунуть 64-битное ядро и 64-битную систему. arm7 код он при этом исполнять перестанет, а реализация железа такова, что самые вкусные плюшки - виртуализация и ещё что то там работают с жуткими висаками из за долгого переключения режимов процессора. Короче обещают кактусы во все дыры даже без учёта того, что какой то софт не соберётся или будет глючить. Всё это если я правильно перевёл статью на английском.

Лучше бы осилили ilp32. Всё такое же, как на 32-битной системе, но инструкции 64-битные.

Похоже на x32 ABI.

А было бы здорово! Жалко что Electron752 оффлайн с марта. Он - чуть ли не единственный, кто развивал aarch64 в сборке ядра для Raspbian Linux.

А по поводу попробовать, я тут уже неделю читаю про Device Tree.

И единственное, что могу сказать, это что C-программерам надо законодательно запретить изобретать YAML.

Любителям YAML нужно запретить соваться в ядро. Хотя... лучше запретить им вообще всё.

Поздравляю, звание главного сноба ЛОРа за тобой.

А ты про Device Tree что-нибудь знаешь кроме того что оно тру в отличе от?

Собственно я вот чего не понимаю: как мне с этим Device Tree вообще понять, где я.

В том же Raspbian большинство библиотек для работы с gpio читает при старте /proc/cpuinfo где в строке Hardware написана точная модель платформы, а потом мапит его на захардкоженные таблицы. Но это в старом Raspbian. А в новом правильном ядре у меня написано «Hardware: Generic Device Tree» или что-то вроде того.

Тем не менее от модели конкретной raspberry pi зависит распиновка и доступность некоторых фич платформы. И как мне её выяснять?

Проверить compatible = b-model-3,* у верхней ноды? Проходить по всему дереву пересчитывая gpio pins? Вообще не лезть туда и проверять исключительно наличие /dev/gpiodev0?

Но если он в какой-то момент станет не goipdev0, а gpiodev42?

И если я например хочу найти тот один из двух pwm-compatible пинов на raspberry pi 3, который не связан одновременно с audio-выходом, то как мне его определить?

Проходить по всему дереву пересчитывая gpio pins? Вообще не лезть туда и проверять исключительно наличие /dev/gpiodev0?

Зачем вообще в DT соваться, можно количество пинов в /sys/class/gpio/gpiochipN-что-там посмотреть

И если я например хочу найти тот один из двух pwm-compatible пинов на raspberry pi 3, который не связан одновременно с audio-выходом, то как мне его определить?

Очевидно по принципиальной схеме платы RPi3 и распиновке

Во-первых /sys/class/gpio/ больше нет, это deprecated-интерфейс и мы его не используем. У нас есть только новый интерфейс: /dev/gpiochip0

Во-вторых эти все gpio-пины разные по функциям, и мне надо знать где какой, а не просто количество. И мне надо как-то смапить их номера на те циферки которые нарисованы снаружи на плате.

Ну и не в gpio только дело. Вот как мне разобраться с тем же i2c или pwm?

У меня должно быть их два, один нормальный, а другой включаемый если отрубить audio выход. Кто должен предоставлять инфу об этом? Device Tree, спеки raspberry pi 3 B+, которые надо отдельно в приложении хардкодить, броадкомовский драйвер, который этот pwm обслуживает?

ну то есть ты считаешь что device tree к этому отношения не имеет?

И мне надо как-то смапить их номера на те циферки которые нарисованы снаружи на плате.

Нуу насколько помню, в /sys/class/gpio/ они были пронумерованы в соответствии с пинами броадкомовского чипа, соответствие номеров на плате надо смотреть по таблице. Относительно друг друга нумерация пинов может поменяться если только перепишут драйвер, иначе никак.

Вот https://pinout.xyz/#

У меня должно быть их два, один нормальный, а другой включаемый если отрубить audio выход.

Это всё хардкодится. Физически пины же не гуляют по плате

Во-первых /sys/class/gpio/ больше нет, это deprecated-интерфейс и мы его не используем. У нас есть только новый интерфейс: /dev/gpiochip0

А почему у меня в свежайшем ядре 4.14 он есть?

потому что у тебя CONFIG_GPIO_SYSFS=yes

этот интерфейс в 2020 году только окончательно удалят

пины не гуляют по плате, но они имеют до 6 альтернативных функций, между которыми можно переключаться.

и выбор этих функций именно что хардкодится в device tree:

https://github.com/torvalds/linux/blob/5924bbecd0267d87c24110cbe2041b5075173a...

То есть вот например чуть не каждому pin назначается функция

https://github.com/torvalds/linux/blob/9c323bff13f92832e03657cabdd70d731408d6...

В итоге за итоговую распиновку и возможности платы отвечает device tree а не спека платы.

В итоге за итоговую распиновку и возможности платы отвечает device tree а не спека платы.

Лол. За итоговую распиновку отвечает разработчик платы, который разводку спроектировал, и физически она не меняется. Функция пина может меняться программно, либо драйвером, либо броадкомовской фирмварью при старте. Я не в курсе, может ли драйвер в линуксе менять функцию пина в рантайме, но принципиально это ничего не меняет.

А device tree в сборке конкретного ядра и дистра может и не быть вообще

но скорей всего функция пина таки не захардкожена, если он как GPIO экспортируется в юзерспейс, если тебе он нужен не как GPIO, а как pwm или i2c, нужно использовать соответствующий драйвер, а не дёргать GPIO Напрямую

драйвер pwm для raspberry внезапно даже есть

#modprobe pwm-bcm2835

только что и где он создаёт, не видно, придётся тебе исходники читать :)

Поздравляю, звание главного сноба ЛОРа за тобой.

Я буду нести его с честью.

А ты про Device Tree что-нибудь знаешь кроме того что оно тру в отличе от?

Пользуюсь им лет 8, иногда правлю готовые.

Проверить compatible = b-model-3,* у верхней ноды? Проходить по всему дереву пересчитывая gpio pins?

Это путь, по которому ходят разве что писатели драйверов (и то у них есть способы получше).

Но если он в какой-то момент станет не goipdev0, а gpiodev42?

А piogdev666 оно стать не может?

И если я например хочу найти тот один из двух pwm-compatible пинов на raspberry pi 3, который не связан одновременно с audio-выходом, то как мне его определить?

Я бы спросил тебя, как эту задачу усложняет то, что device tree написано в Си-стиле, но просто процитирую тебя же:

alpha> библиотек для работы с gpio

Оставь библиотекам и драйверам разбираться с тем, какие устройства gpio есть в системе. А если ты сама пишешь библиотеки и драйверы, тебе придется читать документацию и искать атрибуты DT, к которым ты можешь прицепиться.

P.S. device tree compiler и libfdt давно уже написаны.

Придрался к словам.

Зачем мне физическая распиновка, мне важно что у меня сконфигурировано в данные момент, чтобы с этим работать. Хочешь - «виртуальной распиновкой» назови.

А device tree в сборке конкретного ядра и дистра может и не быть вообще

Не меня интересует только путь когда у нас все унифицировано, стандартизировано и device tree.

Оставь библиотекам и драйверам разбираться...

Я не вижу высокоуровневых библиотек для raspberry pi, которые бы умели работать с device tree. Они все ищут инфу о платформе в cpuinfo, а в моем случае её там нет.

А если ты сама пишешь библиотеки и драйверы, тебе придется читать документацию и искать атрибуты DT, к которым ты можешь прицепиться.

Я думаю о том как можно было бы написать такую библиотеку и пытаюсь понять к чему положено цепляться правильным библиотекам - к device tree или к драйверам, или к оба вместе.

Фишка в том, что цепляться к тому что у меня просто доступен /sys/class/pwm некрасиво, потому что это случайно может быть совсем другой pwm, который при неправильной работе с ним что-нибудь физически сломает.

То есть по-хорошему мне надо прицепиться к тому факту, что у меня есть /sys/class/pwmN, который соответствует такому-то пину в спецификации платы raspberry pi 3.

И непонятно, где в итоге брать авторитетный ответ о том что да, это оно.

Драйвер должен заниматься такими вещами? Но он же generic broadcom драйвер. Нашел pwm - заэкспортил. То что это был pwm от raspberry pi его не интересует.

P.S. device tree compiler и libfdt давно уже написаны.

Только decompiler не написан. Теоретически компилятор должен человеко-читаемый текст в машино-читаемый преобразовывать. А тут почему-то компилятор наполовину прожеванного текста в машинный есть, а человекочитаемый исходник забыли написать. Получился такой же yaml как у всех, но не для людей.

имею raspberry pi 3. из оффициальных - opensuse и fedora имеют сборки х64. остальное - неоффициально. raspbian 64bit на оффсайте не дают. armhfp - это не 64 бита. в итоге остановился на fedora 25. fedora 26 aarch64 офф образ - имеет какие-то там проблемы и не грузится, разбираться было лень, потому остался на 25.

И непонятно, где в итоге брать авторитетный ответ о том что да, это оно.

Я пока не понял даже вопроса, который ты задаешь. Если это вопрос «как мне определить, какие GPIO линии куда заведены?», то ответ на него зависит от фантазии разработчика железа.

P.S. device tree compiler и libfdt давно уже написаны.

Только decompiler не написан

Что ты называешь «decompiler» - перевод FDT (DTB) в DTS? Он написан. Является частью device tree compiler.

Получился такой же yaml как у всех, но не для людей.

Фейспалм. Ты можешь сказать, решение каких именно задач тебе облегчило бы представление DTS в YAML?

Фишка в том, что цепляться к тому что у меня просто доступен /sys/class/pwm некрасиво, потому что это случайно может быть совсем другой pwm, который при неправильной работе с ним что-нибудь физически сломает.

По-хорошему, разработчики железа должны исключать такие ситуации, чтобы программа могла сломать железо, но программер тоже должен осознавать, что он делает.

И непонятно, где в итоге брать авторитетный ответ о том что да, это оно.

Из принципиальной схемы платы.

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

Смотри:

$cat /sys/class/gpio/gpiochip0/label   
pinctrl-bcm2835

другого экземпляра pinctrl-bcm2835 физически в системе появиться не может

фантазия разработчика железа закреплена в доке

https://www.raspberrypi.org/documentation/hardware/raspberrypi/bcm2835/BCM283...

страница 102

Далее я гружусь в свою систему и вижу /sys/class/pwm/pwm0. Вопрос, этот pwm0 - это PWM0 или PWM1?

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

https://github.com/torvalds/linux/blob/f007cad159e99fa2acd3b2e9364fbb32ad28b9...

и каким-то образом выцепить номер пина соответствующий моему pwm0.

Точнее наоборот, я как user-space приложение хочу подать на pin40 некоторую частоту, поэтому я иду в device tree, разыскиваю какой pwm-девайс этому pin40 соответствует и тогда использую его. И вот этот поиск девайса по номеру pin-а получается надо на стороне библиотеки реализовать?

я как user-space приложение хочу подать на pin40 некоторую частоту, поэтому я иду в device tree, разыскиваю какой pwm-девайс этому pin40 соответствует и тогда использую его.

По-моему, ты скорее должна искать pwm-устройство, которое использует линию GPIO, и эта линия - то, что тебе надо.

И вот этот поиск девайса по номеру pin-а получается надо на стороне библиотеки реализовать?

Если он не реализован больше никем - да, конечно. Насколько я вижу, для описания GPIO-линий даже есть соглашения.

Чуваки, а для меня это — новость, что уже поперли 64-битные армы в попсу...

Есть device-tree overlays, но тсс, это запретное знание...

Я тебе страшный вещь скажу, мультиплекс может меняться в рантайме. Были GPIO, стали SPI, или NAND, Или ещё какая херня, просто потому что такой expansion card воткнули.

Только decompiler не написан.

4.2. Ещё пару лет назад я дампил dtb в dts. Другое дело, что без контекста читать сложно, поскольку секции выводятся без меток, только с физическими адресами.

Далее я гружусь в свою систему и вижу /sys/class/pwm/pwm0. Вопрос, этот pwm0 - это PWM0 или PWM1?

можно потыкать осциллографом и выяснить на практике

а ещё можно не париться и читать номер пина/устройства из конфига, в который юзер его запишет, и пусть он беспокоится о правильной нумерации

где я это отрицаю

вот тебе банальный десктопный пример, guvcview и вебкамеры, точнее, V4L2 устройства, программа не шарится по device tree, а просто даёт юзеру выбрать нужное устройство /dev/videoN путём выбора из комбобокса

Да это как раз тут вполне неплохо описано:

https://www.raspberrypi.org/documentation/configuration/device-tree.md

Я потому и подумала, что одной только проверкой compatible = raspberry-pi,3-model-b на верхнем уровне не обойдешься.

Да, как вариант для чайников подойдет. С gpiodev у меня примерно так и работает :)

А вот с PWM я попыталась найти где он у меня, и тут мне открылась бездна..