Мне, раз уж дискуссия есть, хотелось бы получить ваше мнение: полезна ли статья тем, кто вынужден работать с готовым легаси-кодом, например, с SDK от того же allwinner? Или эту задачу она не решает?
В том то и дело, что на мой взгляд - нет. Как дергать ножки через sysfs написано не много, а ОЧЕНЬ много. К тому же есть куча библиотек, чтобы не заниматься этой этой галиматьёй в сотый раз:
найди эту ножку
экспортни ножку
выставь вход/выход
запиши/считай значение
сделай lseek
Brrrrr....
Можно понять тех кто сидит на старой версии ядра до 4.6-r1 (я даже сделал программу которая работает и с SYSFS и c GPIO UAPI v1, в том числе и одновременно). Но они уже для себя давно уже всё сделали и проблемы свои решили.
Вот статья как перестать "страдать" с sysfs gpio и начать "наслаждаться" UAPI gpio - на отдельно взятом SDK (и как прописать ножки в device tree) - вот это ДА (к тому же сейчас уже есть V2 GPIO UAPI) !
Список использованных материалов не был приведен, т.к. их особо, кроме исходников, и не использовалось. Сейчас, после дополнений, вероятно, стоит его написать.
Список материалов всегда нужен, так как это хлебные крошки, по которым может пойти человек в поисках решения своей проблемы.
я охотно принимаю замечания и не пытаюсь перейти на личности. просто аллергия на тональность "о госссподи, да все же знают, что...". Потому что "все знают", но мало кто этим знанием делится в понятной форме. А когда начинаешь копать условно с нуля - всей этой информации остро не хватает.
Может я конечно сижу в своём поисковом пузыре, но та самая перезентация Linus'a у меня элементарно находится на первых местах.
The userspace ABI is a character device for each GPIO hardware unit (GPIO chip). These devices will appear on the system as /dev/gpiochip0 thru /dev/gpiochipN. Examples of how to directly use the userspace ABI can be found in the kernel tree tools/gpio subdirectory.
For structured and managed applications, we recommend that you make use of the libgpiod library. This provides helper abstractions, command line utilities and arbitration for multiple simultaneous consumers on the same GPIO chip
Её может быть мало на русском языке, что безусловно плохо, но тогда мы должны обеспечить читалей лучшим и современным материалом !
безусловно, использование gpio из userspace - это в принципе не очень хорошая практика, независимо от способа доступа. GPIO должен быть завернут во что-то. gpio-keys, gpio-leds, что-то более другое.
Откуда такой странный вывод ? Вы ознакомились хотя бы с презентацией Linus'а, который является мантейнером подсистемы аж с 2012 года ? Не вводите пожалуйста людей в заблуждение.
Прямой доступ к GPIO может использоваться например для концевых датчиков (и между прочим UAPI даёт для такого события timestamp максимально близский к получению прерывания).
да, вероятно, брать старые железки со старыми ядрами - не самый оптимальный вариант, и современный код изучать правильнее. Спасибо за ссылки, это полезная информация. Тем не менее, есть множество массово производимых и разрабатываемых устройств, где используются ядра 4.x и 5.x, где используется вендорский sdk именно с таким кодом, или около того.
GPIO UAPI был уже c 4.6-r1, в stable пошло ядро 4.19, так насколько легаси нам нужно ?
Не совсем понял, что значит "сразу нет", применительно к процитированным участкам кода.
Ещё раз вы приводите LEGACY код и LEGACY подход к разработке драйверов, которые в новом драйвере (если кто-то решит по вашей статье написать дравер) - просто попросят поменять или сделать по-другому.
вы даете, безусловно, полезную информацию и комментарий очень по делу. Действительно ли присутствует необходимость делать это таким тоном, как будто я за последние три недели лично вам до смерти надоел, или это случайный огрех формулировки? :)
Только если вы не можете отделить себя от самой статьи, мой негатив направлен исключительно на вашу статью, а не на вас конкретно.
System (SYS) — группа процессорных ядер, принимающих всю нагрузку; на них запускается Linux, пользовательские приложения, они 64-битные.
System Control Unit (SCU) — процессорное ядро, среди прочих функций которого — управление системой питания и загрузкой ОС. Оно 32-битное.
Архитектура у них одинаковая RISC-V. Есть AMP с одной разрядностью, но разным функционалом например Sifive Unmatched, там и разрядность одинаковая, но например на 0 харте отсутвует MMU, и они как раз эмулируются в размках одной машины QEMU.
1) eMMC еще надо настроить (включить тактирование)
2) После включения доступна не вся память (основную еще надо настроить)
и т.д.
Это делает ZSBL (Zero-stage bootloader), который опять же надо откуда-то загрузить, а настроенной памяти может не хватать для всего функционала.
Тогда грузиться загручик следующего уровня (условно First stage bootloader) который настраивает память и допустим eMMC и т.д.
Получаеться, что SPI NOR настроить сильно проще это раз, во-вторых, как правило они обладают свойством XIP (Execute In Place), что вообще позволяет исполнять код прямо из флэшки.
Там надо ФС иметь соответствующие, типа jffs2, и прочие грабли и гемморои
Нет не нужно, для u-boot, kernel, initrd не нужно, там поиск и метка badblock's происходит при erase.
Вот прям с языка сняли,
3,5 млн файлов (для справки, ядро Linux содержит около 80 тыс. файлов, или 2% от этого количества).
Репозиторий на 300 ГБ (против Linux с ядром ~4,5 ГБ).
преподносится автором так, как будто это предмет для гордости.
Логика в том, что если ваша программа запрашивает несколько линий то ей за ними и следить, а 32 байта это 32 байта.
Да пожалуйста, выделяйте память и присваивайте метку в своей программе, никто ей ничего не запрещает.
Ну во-первых не жаль, а вполне логично. Во-вторых откуда информация, что это будет в v3 ?
Если речь именно о gpio-line-names, то из userspace никак - они задаются либо из драйвера, либо из dt (причем оно приоритетней драйверного списка).
Если же речь идет о том, чтобы их поименовать в принципе, то подойдет поле consumer:
https://elixir.bootlin.com/linux/v6.8-rc4/source/include/uapi/linux/gpio.h#L179
Единственное, для того, чтобы КАЖДАЯ линия имела уникальное значение consumer, придется запрашивать каждую линию отдельно.
Тут нет противоречий на мой взгляд, тот же самый I2C-GpioExpander точно не находится в процессоре, а PARISC SUPERIO это не gpio.
В том то и дело, что на мой взгляд - нет. Как дергать ножки через sysfs написано не много, а ОЧЕНЬ много. К тому же есть куча библиотек, чтобы не заниматься этой этой галиматьёй в сотый раз:
найди эту ножку
экспортни ножку
выставь вход/выход
запиши/считай значение
сделай lseek
Brrrrr....
Можно понять тех кто сидит на старой версии ядра до 4.6-r1 (я даже сделал программу которая работает и с SYSFS и c GPIO UAPI v1, в том числе и одновременно). Но они уже для себя давно уже всё сделали и проблемы свои решили.
Вот статья как перестать "страдать" с sysfs gpio и начать "наслаждаться" UAPI gpio - на отдельно взятом SDK (и как прописать ножки в device tree) - вот это ДА (к тому же сейчас уже есть V2 GPIO UAPI) !
Список материалов всегда нужен, так как это хлебные крошки, по которым может пойти человек в поисках решения своей проблемы.
Может я конечно сижу в своём поисковом пузыре, но та самая перезентация Linus'a у меня элементарно находится на первых местах.
Да и цитируя официальную документацию ядра
https://www.kernel.org/doc/html/latest/driver-api/gpio/using-gpio.html
Её может быть мало на русском языке, что безусловно плохо, но тогда мы должны обеспечить читалей лучшим и современным материалом !
У меня сложилось впечатление, что вы пытаетесь перевести обсуждение самой статьи в личностную плоскость, мне это не интересно.
Из рекомендаций могу еще добавить, что неплохо было бы, прикладывать список использованных материалов.
Откуда такой странный вывод ? Вы ознакомились хотя бы с презентацией Linus'а, который является мантейнером подсистемы аж с 2012 года ? Не вводите пожалуйста людей в заблуждение.
Прямой доступ к GPIO может использоваться например для концевых датчиков (и между прочим UAPI даёт для такого события timestamp максимально близский к получению прерывания).
GPIO UAPI был уже c 4.6-r1, в stable пошло ядро 4.19, так насколько легаси нам нужно ?
Ещё раз вы приводите LEGACY код и LEGACY подход к разработке драйверов, которые в новом драйвере (если кто-то решит по вашей статье написать дравер) - просто попросят поменять или сделать по-другому.
Только если вы не можете отделить себя от самой статьи, мой негатив направлен исключительно на вашу статью, а не на вас конкретно.
В качестве примера идеально подошёл бы универсальный https://elixir.bootlin.com/linux/v6.8-rc3/source/drivers/gpio/gpio-mmio.c, функционала которого хватает для большинства gpio драйверов:
```
$ grep -rwn linux/drivers/gpio/ -e bgpio_init | wc -l
56
```
А прерывания можно и отдельно разобрать.
Вроде бы казалось сколько уже нажёвано по этой теме, но нет:
Мы не используем sysfs для gpio для новых разработок (и нет это не вкусовщина):
https://elinux.org/images/9/9b/GPIO_for_Engineers_and_Makers.pdf
https://habr.com/ru/articles/351512/
Никто не гарантирует, что нумерация в "/sys/class/gpio/export" останется неизменной даже если мы ничего не меняем в ядре (конифиг, новая версия):
банальный пример - воткнули FTDI конвертер (есть которые с gpio на борту), нумерация съёхала
НЕОБХОДИМО упомянуть, что мы можем присваивать labels для gpiochips, gpiopins в device tree.
Если уж взялись приводить примеры, приведите СОВРЕМEННЫЙ ПРИМЕР, а не раскапывайте легаси наподобии omap.
Любой из:
И т.д.
Сразу нет.
Нет. Смотри cleanup.h
Нет, смотри dev_err_probe
И т.д.
Уже везде так, если не делать свой почтовый сервер, ну тогда b4 в помощь.
А обязательно именно с рабочей ? Можно:
с любой другой сохраняя FROM: рабочая почта
через веб бэкэнд - гляньте b4
Неверно, тут речь идет именно о "битности":
Архитектура у них одинаковая RISC-V. Есть AMP с одной разрядностью, но разным функционалом например Sifive Unmatched, там и разрядность одинаковая, но например на 0 харте отсутвует MMU, и они как раз эмулируются в размках одной машины QEMU.
В какой именно если не секрет ?
https://www.linuxfromscratch.org/lfs/
Вот если бы вопрос был NAND vs eMMC вот тогда я бы согласился с каждым тезисом, а так нет неправда.
Да ну ? :)
https://www.xilinx.com/products/intellectual-property/1-ii2qo3.html#productspecs
Как бы гляньте сколько места на кристалле съест, а если не на кристале, то опять же ножки и разводка тоже денег стоят.
Вот неплохая обзорная статья по верхам:
https://embeddedcomputing.com/technology/storage/a-comparison-of-flash-devices-for-embedded-system-booting
EOL (цикл жизни)
SPI NOR может быть реально быстрее eMMC
Как я уже говорил XIP
Сильно проще разводка на плате
Зависит от... eMMC контроллер стоит всего бакс, но бакс это бакс =) Так же и с памятью.
А еще вопрос ножек остро стоит, SPI условно 4ре ножки - а eMMC ?
Так что скорее не "старые", "современные", а hight-end, low-end, мне так кажется.
Тут вопрос сильно сложнее:
1) eMMC еще надо настроить (включить тактирование)
2) После включения доступна не вся память (основную еще надо настроить)
и т.д.
Это делает ZSBL (Zero-stage bootloader), который опять же надо откуда-то загрузить, а настроенной памяти может не хватать для всего функционала.
Тогда грузиться загручик следующего уровня (условно First stage bootloader) который настраивает память и допустим eMMC и т.д.
Получаеться, что SPI NOR настроить сильно проще это раз, во-вторых, как правило они обладают свойством XIP (Execute In Place), что вообще позволяет исполнять код прямо из флэшки.
Нет не нужно, для u-boot, kernel, initrd не нужно, там поиск и метка badblock's происходит при erase.
Для rootfs раздела - да нужно, если он не RO.