написать драйвер для своего устройства

структурированные костыли и подпорки! :)

Начни с реализации своего конфигспейса и помигай светодиодами тогда, ну и читай доку/примеры на свой IP блок о том как заставить это хозяйство басмастерить.

Да в PCI квирков не меньше, особенно про embedded хосты и размеры окон. Хосты - это вообще адок.

MMIO это значит каждый байт/word/dword будет записываться под контролем CPU?

Да.

Если я выделил в BAR3 диапазон 16 мегабайт, разве нет пути заставить компьютер осуществить непрерывную запись по этому диапазону N байт без участия CPU?

Нет.

А чтение например 8 мегабайт начиная с определенного адреса разве невозможно без участия CPU не реализуя ничего особенного на стороне ПЛИС?

Нет.

Может я буду выгружать что-то из FIFO и отправлять с каждым пакетом чтения всё новые данные из FIFO.

Простой вопрос - _куда_ ты будешь их отправлять? Откуда ты возьмешь адрес?

я надеялся что раз у меня есть диапазон адресов, то компьютер может работать с ним как с куском памяти и читать его без CPU, а на стороне ПЛИС это будет просто ряд TLP MrD запросов по определенным адресам...

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

выяснив что устройство хочет диапазон 4K - выделяет его в общем адресном пространстве и это значение адреса попадает например в BAR0

В адресном пространстве, да, но это не адрес памяти. Это шинный адрес: http://lxr.free-electrons.com/source/Documentation/io-mapping.txt

Вижу примеры для ПЛИСины по части PCI-E+SG-DMA, но там есть и другой пример, который чисто на проверку пропускной способности... и там PCI-E БЕЗ DMA на стороне ПЛИС. Там чисто чтение и запись по инициативе хоста (драйвера).

Оборотной стороной этого является полная загрузка одного ядра.

Хочу чтобы когда нужные данные накопятся (например, если это изображение, то несколько строк) - я формирую прерывание (Message Signaled Interrupt, корка поддерживает) из ПЛИС и драйвер считывает новые данные САМ

Разумная стратегия для начала, но, по опыту, это 5МБайт/сек при 100% загрузке процессора.

Отлаживаюсь через UART :)

#define mypci_readl(mmio, reg) readl(mmio + reg)
#define mypci_writel(mmio, reg, value) writel((value), mmio + reg)

Запись

mypci_writel(mmio, 0xABC, 0x78563412);

78 56 34 12 bc fa 9f fe 0f 00 00 00 01 00 00 40

Вопрос: а как записать сразу 100 байт? Чтобы сформировался один очень длинный TLP пакет. В какой главе LDD это описано?

Чтобы сформировался один очень длинный TLP пакет.

Очень длинный --проблематично. Я делал так:

http://www.intel.com/content/dam/www/public/us/en/documents/white-papers/pcie...

Получил около гига в секунду при 100% занятости одного ядра. Чтоб быстрее, ПЛИС сам должен просить данные.

Этот способ лишь для x86-архитектуры? Нет универсального способа сделать пакет, допустим, длиной 10-ть DW? Нет так нет, буду знать :) Значит DMA впереди, не знаю осилю ли, но попытаюсь.

Про другие архетиктуры я не знаю. С DMA ничего сложного нет. У меня правда основной поток из ПЛИСа в хост. Драйвер туп как грабли: mmapит BAR в и пиннит память по ioctl. Все остальное вне ядра. ПЛИС по мере надобности вычитывает список адресов прибитых страниц и тупо льёт туда данные. Даже прерываний ненужно.

#define mypci_readl(mmio, reg) readl(mmio + reg)

Смысл? Обычно делают, чтобы макрос в неявном виде использовал контекст устройства для базового адреса. Например, во всех функциях у тебя будет локальная переменная dev. И будет

#define mypci_readl(reg) readl(dev->mmio + reg)

Лучше всего басмастерить. Есть еще PCI burst + pio, но по моему мнению его эффективность сомнительна. Лучше сразу бысмастерить и burst'ить PCIe-м.

Короче почитай вот это, дя затравки, http://xillybus.com/tutorials/pci-express-tlp-pcie-primer-tutorial-guide-1

Но мн кажется, что должна быть дока значительно лучше на твою FPGA и твой IP блок. Нету там ничего сложного реально. Единственное - если юзаешь embedded хост (не PC) лучше если дебажный комп это не то же устройство, в которое карточку вставляешь. При определенной кривизне рук можно записать немного не туда, и понять что было не так будет очень сложно. Если процессора DMA/реквестов и scatterlist не реализованы в IP блоке, советую добавить какой-нить недопроцессор туда. Ну это зависит от мироощущений, некоторые к этому относятся с яростной ненавистью, но мне проще так было делать, чем возиться с состояниями. И базовая идея, что ты заводишь регистры в конфигспейсе (или в BARx) в которых или просто адрес, длина или ссылка на дескриптор, где массив этих данных лежит в памяти, и ты по биту «давай» в регистре делаешь трансфер согласно доке на IP блок. Минус бас-мастера - он должен выполняться максимально быстро, то есть никаких ожиданий готовности и тп, только передача из подготовленного буфера в подготовленный буфер. Да, и как закончишь, генеришь прерывание.

Смысл?

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

Посмотрите на любой драйвер в /drivers/media/pci

Да, там эти три статьи у Xillibus по PCI-E отличные! Спасибо за эти ссылки. С помощью информации по ссылке я наконец сделал обработку чтения из устройства (ответный пакет с правильным Tag высылаю) - драйвер считывает правильные значения!

Теперь буду постигать DMA. Тот же драйвер от Xillibus http://lxr.free-electrons.com/source/drivers/char/xillybus/ весьма интересен, там видимо DMA используется и кода очень мало.

MRd
MRd
MRd
MRd

Вы чего меня поминаете всуе, ась?

Це буде 2 МБ за секунду, хлопчик. Але епоху юних не спинити, так що працюй над пдп.

tailgunner Извините, снова я беспокою :)

Теперь встал вопрос непосредственно с SG-DMA. Кажется я понял суть этого метода, в LDD3 это хорошо описано. В документации есть такие строки:

int i, count = dma_map_sg(dev, sglist, nents, direction);
struct scatterlist *sg;

for_each_sg(sglist, sg, count, i) {
    hw_address[i] = sg_dma_address(sg);
    hw_len[i] = sg_dma_len(sg);
}

    int n_sg = 10;
    struct scatterlist sg[10];
    n_sg = dma_map_sg(&dev, sg, n_sg, DMA_FROM_DEVICE);
    for(i = 0; i < n_sg; i++)
    {
	printk(KERN_INFO "mypci: SG %d -> %d @ %d\n", i, sg_dma_address(&sg[i]), sg_dma_len(&sg[i]));
    }
    dma_unmap_sg(&dev, sg, n_sg, DMA_FROM_DEVICE);

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

irqreturn_t mypci_isr(int irq, void *data)
{
    printk(KERN_INFO "mypci: interrupt!\n");
    return IRQ_HANDLED;
}
EXPORT_SYMBOL(mypci_isr);
...
    pci_set_master(dev);
    pci_enable_msi(dev);
    devm_request_irq(&dev->dev, dev->irq, mypci_isr, 0, "mypci", NULL);

Пишут что надо заполнить эти структуры struct page *page; unsigned int length; unsigned int offset; перед тем как что-то выделять. А я то всё нулевое подаю, это и есть ошибка.

Допустим я заполню так: offset = i*4096; а length у каждого элемента будет 4096 (хотя лучше потом узнать размер страницы памяти в системе, что мельчить если страница будет 64К?).

Одно непонятно: struct page как заполнять? Судорожно ищу примеры в драйверах, пока не нашел.

Теперь встал вопрос непосредственно с SG-DMA

Но возникает вопрос - а что это за sglist? В документации выше он абсолютно не описан, он берется из космоса?

Documentation/DMA-mapping.txt

Documentation/DMA-API-HOWTO.txt

irqreturn_t mypci_isr(int irq, void *data)
{
printk(KERN_INFO «mypci: interrupt!\n»);
return IRQ_HANDLED;
}

В настоящих драйверах ISR обычно сбрасывает причину прерывания на устройстве.

devm_request_irq(&dev->dev, dev->irq, mypci_isr, 0, «mypci», NULL);

Для учебного примера, наверное, подойдет.

Тут я правильно сделал?

Сначала устанавливается обработчик прерывания, потом разрешается их генерация.

struct page как заполнять?

virt_to_page на адресе, возвращенном k{m,z}alloc, или get_user_pages, если у тебя DMA в юзерспейный буфер (обычно это не нужно). Это есть в LDD3.

Пользуйтесь LXR и смотрите, как этот вызов используется в драйверах, и что инициализируется для его использования.

http://lxr.free-electrons.com/ident?i=dma_map_sg

Для начала самый простой вариант с одним буфером:

int dma_size = 4 * 1024;
dma_addr_t dma_device;
void *dma_driver;

void test_dma(struct pci_dev *dev)
{
	int ret = 0, i;
	printk(KERN_INFO "----- test_dma\n");
	//ret = dma_set_mask(dev, 0xFFFF);
	//printk(KERN_INFO "mask= %d\n", ret);
	dma_driver = dma_alloc_coherent(dev, dma_size, &dma_device, GFP_DMA);
	printk(KERN_INFO "dma= %d %d\n", dma_driver, dma_device);
	//dma_free_coherent(dev, dma_size, dma_driver, dma_device);
}

Andrey_Utkin Пытаюсь разобраться. Пока безуспешно, самого простого понятного примера пока не нашел. Но обнаружил что перед dma_map_sg используется еще

void test_sgdma(struct pci_dev *dev)
{
	int ret = 0, i, count = 0;
	struct sg_table table;
	printk(KERN_INFO "----- test_sgdma\n");
	ret = sg_alloc_table(&table, 10, GFP_KERNEL);
	count = dma_map_sg(dev, table.sgl, table.nents, DMA_FROM_DEVICE);
	printk(KERN_INFO "alloc: %d -> %d/%d = %d\n", ret, table.nents, table.orig_nents, count);
	for(i = 0; i < count; i++)
	{
		printk(KERN_INFO "	SG %d -> %d / %d\n", i, sg_dma_address(&table.sgl[i]), sg_dma_len(&table.sgl[i]));
	}
}

Может ли это быть из за устройства?

Из-за того, что конструируемое тобой устройство что-то испортило? Да. Но, если у тебя валится именно вызов dma_alloc_coherent - покажи стектрейс.

dma_alloc_coherent(struct device *dev, size_t size,
			     dma_addr_t *dma_handle, gfp_t flag)

Как ты умудрился передать туда pci_dev? Компилятор должен был тебя предупредить.

Ох лол... Надо передавать dev->dev. Понял... Мне стыдно :)

dev->dev

Как будто конкурс по запутанному коду на Си.

http://xillybus.com

Недавно на лоре анонсировали свободный тв-приемник. У того человека, кстати, уже есть свободный код FPGA-PCIe: NetUP_Dual_Universal_CI-fpga. Так что ещё один пример.

Кстати, а планируешь написать обо всём этом заметку/статью на хабре или необязательно на нём? Уверен, народ был бы благодарен. Arduino, Raspi - это очень хорошо, но вот ещё бы FPGA сделать бы доступнее и популярнее.

О, хороший драйвер, всё очень аккуратно. Обязательно изучу, спасибо за эту ссылку.

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

Мне пока рано писать какую-либо статью, вряд ли то что я делаю на стороне ПЛИС является правильным и действительно будет работать везде (нужно обрабатывать не только 32-битные но и 64-битные обращения) и многие другие ньюансы.

Может, когда сделаю нормальное устройство (товарищ поможет развести плату, он СВЧ платы умеет и соображает) и оно заработает, то только тогда уже буду проповедовать учение о писиае :)

А пока я не совсем понимаю как были настроены пины интерфейса кор-генератором, хотя допускаю что из ПЛИС выведено что-то самое первое что берется по дефолту генератором, и вообще раз корка для PCI-E то всё под нее настраивается само соответственно...

Вот когда будет что-то больше чем x1 (x4 например) на самодельной плате - тогда наверное статью напишу. Хотя видно что у Lattice, Xilinx и Ti XIO1100 похожие принципы работы с PCI-E, у Altera со стороны user-логики может быть сложнее чуток наверное.

Для тех кто следит за темой - удалось осуществить работу при помощи DMA :)

Выделяю при помощи dma_alloc_coherent, получившийся адрес из параметра сую в устройство через MMIO, когда устройство получает этот адрес то я шлю MWr на этот адрес длиннющий пакет и оно потом успешно читается в драйвере :)

заставить это хозяйство басмастерить

tailgunner Что ж, удалось заставить устройство писать 1404 байта в выделенный буфер при помощи 13 пакетов по 27 DW. Но возникли странности:

Я задаю payload length как 28 DW (0x1C), но оно упорно шлет лишь 27 DW, это я вижу по одиночному пакету, буфер заполняется лишь в 27-ми DW, остальное не тронуто. Любые попытки увеличить поле length или уменьшить или увеличить число данных на один DW приводит к отбрасыванию пакета вообще.

Лишь 13-ть пакетов (27 + 3 DW) можно отправить последовательно, делая паузу в один такт 125 МГц паузу между ними. Для 13 это срабатывает, большее число не лезет. При этом как только отсылается серия из уже 13 пакетов, lspci -v показывает вот что:

[  124.399217] mypci: max= 351 -> 13
[  124.436578] mypci: device removed
02:00.0 Non-VGA unclassified device: Adnaco Technology Inc. Device bbbb (rev ff) (prog-if ff)
        !!! Unknown header type 7f

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

Разобравшись как корка сигнализирует что она готова кушать данные, смог разогнаться вплотную до границы 4096 байт. И тут пришла мысль, что если есть фундаментальный запрет на передачу байтов в одном пакете, которые ложатся между разными страницами памяти?.. Очень очень похоже что так, не учел этого ранее.

Для примера, сделал DMA-буфер размером 256К (64 страницы по 4К). Когда сделал пакеты по 64 байта, что соответственно позволило не пересекать границы страниц памяти - стало успешно без сбоев передавать полный объем данных.

Проблема что последний DW не передавался тоже решилась. Невнимательно читал http://xillybus.com/tutorials/pci-express-tlp-pcie-primer-tutorial-guide-1 Там написано «The Last BE field must be zero when Length is unity, since the first DW and the last is the same one», но в примере то один DW передавался, только для этого случая было актуально LastBE=0, а когда так много данных в пакете - нужно 0xF.

Вижу странность вокруг функции request_mem_region - где-то в дровах проверяют что если эта функция вернула меньше нуля - значит ошибка (тут), где-то если не равна нулю - ошибка (тут), а где-то если равна нулю то ошибка (тут). Где-то вообще не смотрят возвращаемое значение - просто вызывают по несколько раз с разными параметрами, например.

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

Я пока сделал так:

	if(request_mem_region(pci_resource_start(dev, 0), pci_resource_len(dev, 0), "mypci") < 0)
	{
		ret = -EBUSY;
		printk(KERN_ERR "mypci: ERROR: mem region failed\n");
		goto failed_mem_region;
	}

Andrey_Utkin tailgunner

Вижу странность вокруг функции request_mem_region

Зачем она тебе вообще? Лично я не припомню, чтобы ее использовал.

Встретив неоднозначность, отбрось искушение угадать.

В случае nand/au1550, похоже, явная ошибка, в случае ralink (проверка на отрицательность) - плохой стиль. Можно уточнить у разрабов и послать патчики.

Я бы рекомендовал следующую, более простую как для написания, так и чтения форму, которая делает то же самое:

        err = pci_request_regions(pci_dev, dev->name);
        if (err) {
                dev_err(&dev->pci->dev, "Cannot request regions for MMIO\n");
                goto disable_pci;
        }

С последующим

        dev->mmio = pci_ioremap_bar(pci_dev, 0);
        if (!dev->mmio) {
                err = -EIO;
                dev_err(&dev->pci->dev, "can't ioremap() MMIO memory\n");
                goto release_mmio;
        }

ret = 0 - OK, ret < 0 - ошибка. Можно считать ошибкой любое ненулевое значение.

Где ты тут увидел что 0 - ошибка? http://lxr.free-electrons.com/source/drivers/scsi/aic7xxx/aic79xx_osm_pci.c#L293

Это просто проверка что ресурс не занят. на самом деле этот код мне почему-то кажется архаичным, кажется что была более специальная функция, которая сразу и request_mem_region() и ioremap() в одном флаконе. сейчас лень смотреть.

Это просто проверка что ресурс не занят.

Мне кажется, это проверка из времен ISA или с архитектур, где регионы памяти не привязаны к устройствам черз OF, dts или еще что-то.

Не, обычно ресурсы всё равно проверяются, но это обычно проще. Можно тут основную идею почитать http://haifux.org/lectures/323/haifux-devres.pdf И пользовать надо эти методы заместо прямой работы с ресурсами.

Полезная ссылка, но тема именно request_mem_region там не раскрыта. Более того, в вызове request_mem_region не указывается устройство-владелец, что противоречит изложенному по ссылке.

Ну поэтому я и говорю, что код архаичный.

Добрый вечер! Прошу прощения что кастую, возникла проблема, есть догадки. Сделал чтобы устройство отдавало 256К (=256 * 1024) байт в виде 64К 32-битных слов, каждое слово равно предыдущему значению плюс единица.

Когда драйвер только загружается, то первый блок 64К 32-битных слов может быть поврежден в 33 66 99 или 115-ти позициях, т.е. тупо 66 32-битных слов не являются инкрементом предыдущего. Перед тем как шлю пакет в ПЛИС чтобы оно начало накладывать данные - обнуляю весь буфер нулями, для надежности. Выгружаю и снова загружаю (insmod) - опять первый запрос будет с пробитостями.

Если драйвер уже был загружен перед запуском тестовой программы - все 64К слов всегда правильные (по ОДНОМУ блоку), и сколько бы я не запрашивал - счетчик корректно инкрементируется между этими запросами.

А вот как только тестовая программа запрашивает два блока по 64 DW - чудо: первый блок весь полностью корректен без ошибок, а в последующем может быть 33 66 99 или 115 ошибок, прям магические характерные числа. Может быть одна или несколько последовательных цепочек битых данных в рамках 64К DW.

У меня только догадка: может оно тупо не успевает записать данные? Может после отсылки из ПЛИС последнего TLP-пакета в блоке надо подождать и только после этого выкидывать прерывание? Если да, то сколько надо ждать тактов, должен же быть какой-то признак, независимый от скорости системы? Должно пройти время, пока данные упадут в память и запишутся, после чего их можно читать. Может даже пакеты не успевают долететь с данными.

tailgunner Andrey_Utkin slapin ebantrop

Телепатия не самая моя сильная сторона, но попробую. В PCIe прерывание это просто TLP пакет, поэтому если он отсылается после пачки пакетов с данными и ты его видишь, значит все предыдущие должны быть обработанны. Как ты делаешь проверку? Поинтер volatile? Какие там данные вместо счётчика: нули или мусор какой-то? Если нули, ты уверен что счётчик адреса работает правильно? В том смысле что все пакеты падают в твой буфер?

Решил инициализировать перед запросом блока не нулями, а например AAAAAAAA... и увидел что там где ошибки - всегда эти А. Ну ясно, всё теперь понятно - не успевает упасть в память, не долетают пакеты. А ведь я полагал точно так же, что раз TLP пакет с прерыванием высылается после последнего пакета с данными то всё должно быть окей.

Сбойные данные возникают последовательной пачкой, размер которой не кратен размеру TLP-пакетов (они по 64 байта payload, или по 16 DW). Сбои наблюдаются в в районе первой тысячи DW (всего 65 тысяч).

Я полагаю, что я должен добавить некоторую задержку после последнего пакета с данными, и лишь после этого высылать MSI (прерывание). Но какой же размер задержки? Как узнать когда хост всё прожевал? Не люблю костыли вроде задержек, времен i80386.

Поинтер volatile?

dma_addr_t dma_device;
void *dma_driver; // работаю с этим
...
unsigned int *dw;
dw = (unsigned int*) device->dma_driver;

Данные смотрю в device->dma_driver. Как volatile поможет?

Проверяю так:

static ssize_t mypci_read(struct file *f, char *buffer, size_t size, loff_t *offset)
{
        int i = 0, err = 0;
        unsigned int *dw;
        unsigned int prev = 0;

        int minor = iminor(f->f_inode), ret, sz = 0;
        struct mypci_device *device = NULL;

        if(minor >= mypci_used) return 0;
        if(f->f_flags & O_NONBLOCK) return 0;
        if(size == 0) return 0;

        device = &devices[minor];
        device->dma_finished = 0;
        dw = (unsigned int*) device->dma_driver;
        for(i = 0; i < (MYPCI_DMA_BLOCK / 4); i++) dw[i] = 0xAAAAAAAA;
        writel(device->dma_device & 0xFFFFFFFF, device->mmio);
        if(wait_event_interruptible(device->wait, device->dma_finished != 0)) return 0;

#if 1 // check counter data
        prev = dw[0];
        for(i = 1; i < (MYPCI_DMA_BLOCK / 4); i++)
        {
                if(dw[i] != (prev + 1))
                {
                        printk(KERN_ERR "mypci: 0x%08X -> %d @ %d\n", dw[i], err, i);
                        err++;
                }
                prev = dw[i];
        }
        if(err > 0) printk(KERN_ERR "mypci: read err %d\n", err);
        else printk(KERN_ERR "mypci: read no errors\n");
        printk(KERN_ERR "mypci: 0x%08X / 0x%08X\n", dw[0], dw[(MYPCI_DMA_BLOCK / 4) - 1]);
#endif

Так читаются 8 блоков: http://paste.org.ru/?7r2dk5

Сбойные данные возникают последовательной пачкой, размер которой не кратен размеру TLP-пакетов (они по 64 байта payload, или по 16 DW). Сбои наблюдаются в в районе первой тысячи DW (всего 65 тысяч).

Присмотрелся - всё же кратен. Как правило это ДВА смежных, иногда больше, пакета по 16 DW, итого 32 DW битых. Их начало в блоке выровнено по 16 DW. Раньше я не видел этой закономерности, ибо не очищал буфер, и там оставались старые данные, которые меня удивляли.

Буду думать какую задержку ставить между последним пакетом данных и MSI. Не хотелось бы колдовства.

Я полагаю, что я должен добавить некоторую задержку после последнего пакета с данными, и лишь после этого высылать MSI

Тебе нужна какая-то обратная связь с хостом. Задержка - это типичный говнокод.

Тебе нужна какая-то обратная связь с хостом. Задержка - это типичный говнокод.

Эта обратная связь есть уже, только что должно быть критерием «всё дошло» на стороне хоста? Как только я это (не знаю что) проверю - сообщу устройству через MMIO.

Я конечно понимаю что 15 минут это не опоздала, но у тебя между первым принтом и принтом с ошибкой проходят десятки миллисекунд. TLP уезжает за десятки-сотни нан. Спрашивается где они шлялись всю ночь?

Кроме того что слипы — говнокод, как правильно заметил tailgunner, сколько ты собираешься ждать сверх того что ты уже ждёшь?

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

На время можно не обращать внимания - сначала я принимаю пакет, а затем смотрю его, параллельно вывод в ttyS0. Я ничего не жду, просто в обработчике прерывания я пробуждаю wait_event_interruptible и проверяю счетчик в данных.

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