работа с PCI в embedded, нужен совет Опции

[_Vladimir_]

Есть Linux машина с PCI-66 интерфейсом на FPGA.
Загрузка ядра обнаружила устройство и в /proc созданы соответствующие PCI файлы и директории.
Из приложения (использовал как пример pciutils) читаю конфиг space.
Но не могу понять как мне работать с данными?
На PCI target создал 2 bar-а в memory - небольшой регистровый пул и окно для потокового чтения.
Ядро мапировало оба бара как задано и PCI настроило с method как proc
Как мне из userspace получить read/write в нужный бар?
Очевидно нужно писать еще один уровень драйвера?
Посколько в коде ядра нашел функции оперирующие с bars:
void __iomem *pci_iomap(struct pci_dev *dev, int bar, unsigned long max)
iomap можно вызвать из userspace или он может быть только в модуле ядра или
модуль можно будет подгрузить через insmod ?
Все мои пробы кончались segmentation fault.
После чтения доков только окончательно запутался, поскольку нет понимания- как вообще правильно работать с устройствами из userspase.
Вижу что через файлы. Это понятно.
Насторожило что в pciutils КАЖДОЕ обращение закрывает/открывает дескриптор.
Это что так надо? или просто так сделано? Будут ли потери эффективности при потоковом обращении через файл таким способом?
После загрузки в proc на PCI уже имелся fd = 4. Полагаю открытый значит.
Или это "чужой", а надо заводить свой?
В общем одни вопросы, поскольку начинающий.
Подскажите кто-нибудь, или ссылку на литературу.
Как писать драйверы описано достаточно подробно, но далее у меня нет ясности, привык к хорошо документированым API, а тут полная каша, плюс еще большая часть доков а-ля 1999 год - а в OS принципиальные изменения.

[Harbour]

1. читать LDD (http://www.xml.com/ldd/chapter/book/ch15.html)
2. читать linux/Documentation/pci.txt
3. изучить любой драйвер pci устройства, начать можно с drivers/char/*.c

В ОС никакой каши быть не может - каша обычно у человека в голове. Весь api и способ его применения четко описан в вышеприведенных источниках.

pciutils никогда не был примером написания драйверов - это утилита для low-level pci management.

Есть разные варианты работы с устройствами из UP - shared memory/ioctl/proc-файлы/какой-нить kernel thread/ и даже в некоторых случаях /dev/mem - выбирают исходя из задачи.

pci api принципиально не менялся в линуксе начиная с 2.0.x ядер (1994 год)

P.S. Если с чтением доков совсем плохо - можно посмотреть в сторону uio интерфейса, присутствует в последних 2.6 ядрах

P.P.S. Для совсем ленивых уже год как можно бесплатно заказать написание любого linux драйвера для любой железяки в мире (USB/PCI/и т.д.) см. нпример http://kerneltrap.org/node/7636

[_Vladimir_]

Harbour, спасибо.

1. читать LDD (http://www.xml.com/ldd/chapter/book/ch15.html)
2. читать linux/Documentation/pci.txt
3. изучить любой драйвер pci устройства, начать можно с drivers/char/*.c

Читал и читаю. существеней не ch15 а ch9 и ch12.

В ОС никакой каши быть не может - каша обычно у человека в голове. Весь api и способ его применения четко описан в вышеприведенных источниках.

Я и говорю что запутался. Вот насчет четкости как раз и спорно.
Если для гуру многое кажется очевидным и предельно простым, но из мира Windows
это ещ надо привыкнуть.

pciutils никогда не был примером написания драйверов - это утилита для low-level pci management.

Понял, Только почему пример написания драйверов?
Я спрашивал о примере АРИ.

Есть разные варианты работы с устройствами из UP - shared memory/ioctl/proc-файлы/какой-нить kernel thread/ и даже в некоторых случаях /dev/mem - выбирают исходя из задачи.
pci api принципиально не менялся в линуксе начиная с 2.0.x ядер (1994 год)

Вот это часто так в Линуксе. Ответ только говорит о том что отвечающий владеет вопросом.
Но что бы понять этот ответ нужно столько узнать,что уже и нет необходимости в вопросе :-)
По моему, Ваши слова подверждают что я выбрал корректный путь:
Тем или иным способом вытаскиваю адреса PCI BARs (поскольку система "фиксирована", можно самым простым способом).
pci_mem_fd = open ("/dev/mem", 2); ..R/W
далее-
hsc_data_mem = mmap(NULL, 0x100000, PROT_READ | PROT_WRITE, MAP_SHARED , pci_mem_fd, 0x9FF00000);
где 0x9FF00000 - адрес бара из /proc/bus.....
затем уже
reg_data = ioread32(hsc_data_mem); или ioread32_rep и iowrite32(reg_data, hsc_data_mem);
- "по мере необходимости".
Поскольку больше ничего не требуется (на шине сидит только одно устройство),
НЕ ОБЯЗЯТЕЛЬНО писать полнофункциональный драйвер устройства?
Конечно драйвер шины в системе есть.

корректно ли
u32 *hsc_data_mem;
reg_data = ioread32(hsc_data_mem)
hsc_data_mem++; // !!!
reg_data = ioread32(hsc_data_mem)

Это будет работать?
Пока мне не ясно что нужно делать в ситуации, как говорят маны:
" It is unspecified whether changes made to the file after the mmap() call are
visible in the mapped region" - это для MAP_PRIVATE
и " The file may not actually be updated until msync(2) or munmap(2) is called." для MAP_SHARED.

P.S. Если с чтением доков совсем плохо - можно посмотреть в сторону uio интерфейса, присутствует в последних 2.6 ядрах

???
А что для uio все на поверхности?

P.P.S. Для совсем ленивых уже год как можно бесплатно заказать написание любого linux драйвера для любой железяки в мире (USB/PCI/и т.д.) см. нпример http://kerneltrap.org/node/7636

???

[Harbour]

Ужасть Неужели так практически необратимо влияет на сознание людей попытка написания pci драйвера под вынь ?

Быстрый ответ: написать драйвер в UIO парадигме.

Длинный one:

1. Видно, что непрочитаны указанные доки, включая примеры любого драйвера [ до конца ].
2. Можно конечно юзать pci строго из US, но это муторно, как быть с прерываниями, проблемы с секьюрити и т.д. Обычно задача разбивается на kernel driver и US прогу, в драйвере пишут detect/init/low level service рутины, в US проге реализуют саму задачу с тонким интерфейсом к слою драйвера.

[_Vladimir_]

Ужасть Неужели так практически необратимо влияет на сознание людей попытка написания pci драйвера под вынь ?

Не стоит об этом, никто не говорил о написании под Windows.

Быстрый ответ: написать драйвер в UIO парадигме.

Длинный one:

1. Видно, что непрочитаны указанные доки, включая примеры любого драйвера [ до конца ].
2. Можно конечно юзать pci строго из US, но это муторно, как быть с прерываниями, проблемы с секьюрити и т.д. Обычно задача разбивается на kernel driver и US прогу, в драйвере пишут detect/init/low level service рутины, в US проге реализуют саму задачу с тонким интерфейсом к слою драйвера.

Если нет конкретных ответов на конкретные вопросы - не стоит утруждаться.
За это время уже нашел ответы на все свои вопросы.
Насчет прерываний, это не десктоп система, а ембедед, и не x86, несколько другое построение работы с прерываниями, не должно мешать.
А с секьюрити посмотрим, пока не мешает.
Тему можно закрыть.
Спасибо, с рождеством!

[Harbour]

Рад, что ничем не смог помочь

[Damon]

Если нет конкретных ответов на конкретные вопросы - не стоит утруждаться.

Как-то в "Системном администраторе" была статейка на тему работы с PCI в пингвине:
"Реализация низкоуровневой поддержки шины PCI в ядре Linux" -- _http://www.opennet.ru/base/dev/pci_linux_kernel.txt.html

Это, конечно, не API, и не все исчерпывающая дока, тем неменее, вдруг пригодиться...

[_Vladimir_]

Как-то в "Системном администраторе" была статейка на тему работы с PCI в пингвине:
"Реализация низкоуровневой поддержки шины PCI в ядре Linux" -- _http://www.opennet.ru/base/dev/pci_linux_kernel.txt.html

Это, конечно, не API, и не все исчерпывающая дока, тем неменее, вдруг пригодиться...

Спасибо, ее я смотрел одну из первых.
На данный момент, в целом интерфейс работает.
Читает/пишет. По ходу подчищаю код FPGA.
Позже возможно придется вернутся, если жизнь заставит все-таки делать драйвер устройства, а пока для отладки PCI канала в FPGA, достаточно.