Pull to refresh
20
0

Систематический программист

Send message

Вот прям с языка сняли,

  • 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.

Мне, раз уж дискуссия есть, хотелось бы получить ваше мнение: полезна ли статья тем, кто вынужден работать с готовым легаси-кодом, например, с 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 у меня элементарно находится на первых местах.

Да и цитируя официальную документацию ядра

https://www.kernel.org/doc/html/latest/driver-api/gpio/using-gpio.html

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 подход к разработке драйверов, которые в новом драйвере (если кто-то решит по вашей статье написать дравер) - просто попросят поменять или сделать по-другому.

вы даете, безусловно, полезную информацию и комментарий очень по делу. Действительно ли присутствует необходимость делать это таким тоном, как будто я за последние три недели лично вам до смерти надоел, или это случайный огрех формулировки? :)

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

В качестве примера идеально подошёл бы универсальный 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
```

А прерывания можно и отдельно разобрать.

Вроде бы казалось сколько уже нажёвано по этой теме, но нет:

  1. Мы не используем sysfs для gpio для новых разработок (и нет это не вкусовщина):

  2. Никто не гарантирует, что нумерация в "/sys/class/gpio/export" останется неизменной даже если мы ничего не меняем в ядре (конифиг, новая версия):

    • банальный пример - воткнули FTDI конвертер (есть которые с gpio на борту), нумерация съёхала

  3. НЕОБХОДИМО упомянуть, что мы можем присваивать labels для gpiochips, gpiopins в device tree.

  4. Если уж взялись приводить примеры, приведите СОВРЕМEННЫЙ ПРИМЕР, а не раскапывайте легаси наподобии omap.

Любой из:

$ git whatchanged --diff-filter=A --pretty=short origin/master -- drivers/gpio/

commit c4f8457d17ce590c71aef53d75d49c313eb72cbc
Author: Jim Liu <JJLIU0@nuvoton.com>

    gpio: nuvoton: Add Nuvoton NPCM sgpio driver

:000000 100644 000000000000 d31788b43abc A      drivers/gpio/gpio-npcm-sgpio.c

commit eee636bff0dcb52c39300dd88ff7e8ecaff4492a
Author: Tzuyi Chang <tychang@realtek.com>

    gpio: rtd: Add support for Realtek DHC(Digital Home Center) RTD SoCs

:000000 100644 000000000000 a7939bd0aa56 A      drivers/gpio/gpio-rtd.c

commit 659ad5f7efece8f92213ca069c494a37507c8c67
Author: Okan Sahin <okan.sahin@analog.com>

    gpio: ds4520: Add ADI DS4520 GPIO Expander Support

:000000 100644 000000000000 1903deaef3e9 A      drivers/gpio/gpio-ds4520.c

commit cd33f216d241520385a5166ae73a0771197a9f0b
Author: Asmaa Mnebhi <asmaa@nvidia.com>

    gpio: mlxbf3: Add gpio driver support

:000000 100644 000000000000 e30cee108986 A      drivers/gpio/gpio-mlxbf3.c

commit 57e30e00bd5baacdf99450d69981ec9192592e3c
Author: Jerome Neanne <jneanne@baylibre.com>

    gpio: tps65219: add GPIO support for TPS65219 PMIC

:000000 100644 000000000000 7b38aa360112 A      drivers/gpio/gpio-tps65219.c

...

И т.д.

static struct platform_driver omap_gpio_driver

Сразу нет.

spin_lock_irqsave(&gpio_lock, flags);

Нет. Смотри cleanup.h

pr_warn("%s: invalid GPIO %ld\n", __func__, gpio);
return -EINVAL;

Нет, смотри dev_err_probe

И т.д.

Уже везде так, если не делать свой почтовый сервер, ну тогда b4 в помощь.

А обязательно именно с рабочей ? Можно:

  • с любой другой сохраняя FROM: рабочая почта

  • через веб бэкэнд - гляньте b4

Неверно, тут речь идет именно о "битности":

  • System (SYS) — группа процессорных ядер, принимающих всю нагрузку; на них запускается Linux, пользовательские приложения, они 64-битные. 

  • System Control Unit (SCU) — процессорное ядро, среди прочих функций которого — управление системой питания и загрузкой ОС. Оно 32-битное.

Архитектура у них одинаковая RISC-V. Есть AMP с одной разрядностью, но разным функционалом например Sifive Unmatched, там и разрядность одинаковая, но например на 0 харте отсутвует MMU, и они как раз эмулируются в размках одной машины QEMU.

следы этого решения даже просочились в BFM для open-source RISC-V проекта.

В какой именно если не секрет ?

Вот если бы вопрос был 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

Просто я пока не понимаю преимуществ NOR Flash, кроме явных недостатков.

  • 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), что вообще позволяет исполнять код прямо из флэшки.

Там надо ФС иметь соответствующие, типа jffs2, и прочие грабли и гемморои

Нет не нужно, для u-boot, kernel, initrd не нужно, там поиск и метка badblock's происходит при erase.

Для rootfs раздела - да нужно, если он не RO.

Information

Rating
5,063-rd
Location
Москва, Москва и Московская обл., Россия
Registered
Activity