![](https://electronix.ru/forum/uploads/set_resources_23/84c1e40ea0e759e3f1505eb1788ddf3c_pattern.png)
![](https://electronix.ru/forum/uploads/set_resources_23/84c1e40ea0e759e3f1505eb1788ddf3c_default_photo.png)
BSACPLD
Свой-
Постов
912 -
Зарегистрирован
-
Посещение
-
Победитель дней
5
Весь контент BSACPLD
-
Armbian проблема с linux-headers
BSACPLD ответил BSACPLD тема в Программирование
Я его не собирал. Взял готовый образ: https://www.armbian.com/rock-5b/ -
Armbian проблема с linux-headers
BSACPLD ответил BSACPLD тема в Программирование
у меня в linux-headers нет скриптов необходимых для сборки драйверов, и при попытке собрать их через sudo make modules_prepare появляется приведенная выше ошибка. sudo apt install linux-headers-$(uname -r) На armbian так делать нельзя - версия будет не соответствовать текущему ядру. linux-headers и linux-kernel нужно ставить через утилиту armbian-config, иначе будут расхождения в версиях. По этим граблям я уже прошелся 😞 -
Armbian проблема с linux-headers
BSACPLD опубликовал тема в Программирование
Коллеги, я тут пытаюсь установить linux-headers на дистрибутив Armbian 23.02.2 под плату Rock 5 model B. При выполнении sudo make modules_prepare возникает такая ошибка: @rock-5b:/usr/src/linux-headers-5.10.110-rockchip-rk3588$ sudo make modules_prepare UPD include/config/kernel.release UPD include/generated/utsrelease.h CC scripts/mod/empty.o HOSTCC scripts/mod/mk_elfconfig MKELF scripts/mod/elfconfig.h HOSTCC scripts/mod/modpost.o CC scripts/mod/devicetable-offsets.s HOSTCC scripts/mod/file2alias.o HOSTCC scripts/mod/sumversion.o HOSTLD scripts/mod/modpost scripts/Makefile.build:423: предупреждение: переопределение способа для цели «modules.order» Makefile:1518: предупреждение: старый способ для цели «modules.order» игнорируются make[1]: *** Нет правила для сборки цели «arch/arm64/kernel/vdso/vdso.lds», требуемой для «arch/arm64/kernel/vdso/vdso.so.dbg». Останов. make: *** [arch/arm64/Makefile:194: vdso_prepare] Ошибка 2 Что я делаю не так? Все package обновлены до самой последеней версии, пробовал и предыдущую версию Armbian 22.11.2, там такая же ошибка... -
dma_mmap_coherent
BSACPLD ответил BSACPLD тема в Программирование
Ещё один вопрос возник. Как корректно маппить регистры BAR PCIe устройства чтобы это работало и на x86 и на ARM? Вот такой код: if(remap_pfn_range(vma, vma->vm_start, PHYS_PFN(dma_dev_dev_ptr->regs_pa[0]), vma->vm_end - vma->vm_start, vma->vm_page_prot)) { printk(KERN_ALERT "dma_dev: reg map BAR0_REGS_BASE_ADDR error!"); return -EAGAIN; } работает только на x86 😞 -
dma_mmap_coherent
BSACPLD ответил BSACPLD тема в Программирование
На практике у меня получилось обратное. На x86 dma_mmap_coherent некорректно отрабатывает. Приходится использовать remap_pfn_range для x86 ветки. UPD. Вы были правы. Если вместо (void*)(vma->vm_start) передавать виртуальный адрес от dma_alloc_coherent, то dma_mmap_coherent работает и на x86 тоже 🙂 -
dma_mmap_coherent
BSACPLD ответил BSACPLD тема в Программирование
Разобрался. Надо было физический адрес не из виртуального через virt_to_phys получать, а брать тот что возвращает dma_alloc_coherent. Ну и ещё момент. Если делать универсально ARM/x86, для для x86 ветки нужно использовать remap_pfn_range. vm_pgoff_old = vma->vm_pgoff; #if defined(__aarch64__) || defined(__arm__) vma->vm_pgoff = 0; if(dma_mmap_coherent(&(dma_dev_dev_ptr->pci_dev->dev), vma, (void*)(vma->vm_start), dma_dev_dev_ptr->tx_dma_buffers[index_tx_buffer].base_ba, (size_t)(vma->vm_end - vma->vm_start))) #else if(remap_pfn_range(vma, vma->vm_start, page_to_pfn(virt_to_page(dma_dev_dev_ptr->tx_dma_buffers[index_tx_buffer].base_va)), vma->vm_end - vma->vm_start, vma->vm_page_prot)) #endif { printk(KERN_ALERT "dma_dev: tx_dma_buffers map error!"); return -EAGAIN; } vma->vm_pgoff = vm_pgoff_old; -
dma_mmap_coherent
BSACPLD опубликовал тема в Программирование
Народ, подскажите, пожалуйста, как правильно использовать dma_mmap_coherent на ARM (RK3588). Пытаюсь маппить из kernel в userspace следующим образом: static int dma_dev_remap_mmap(struct file *filp, struct vm_area_struct *vma) { dma_dev_dev_t* dma_dev_dev_ptr = 0; dma_dev_dev_ptr = (dma_dev_dev_t*)filp->private_data; #ifdef VM_RESERVED vma->vm_flags |= (VM_PFNMAP | VM_SHARED | VM_RESERVED); #else vma->vm_flags |= (VM_PFNMAP | VM_SHARED | (VM_DONTEXPAND | VM_DONTDUMP) ); #endif .......... vma->vm_pgoff = 0; if(dma_mmap_coherent(&(dma_dev_dev_ptr->pci_dev->dev), vma, (void*)(vma->vm_start), virt_to_phys(dma_dev_dev_ptr->tx_dma_buffers[index_tx_buffer].base_va), (size_t)(vma->vm_end - vma->vm_start))) { printk(KERN_ALERT "dma_dev: tx_dma_buffers map error!"); return -EAGAIN; } vma->vm_ops = &dma_dev_remap_vm_ops; .......... } Но в userspace получаю какой-то левый указатель. В драйвере при создании буфера я забиваю его магическими числами 0xEB, а из userspace читается 0x00. Что я делаю не так? -
Так может Вам написать свой собственный захватчик видео вместо Gstreamer? Я так делал в своем проекте - получилось и просто и сложно одновременно. Просто - прошивка для ПЛИС и софт на компьютере получились очень простые. Сложно - свой собственный драйвер пока удалось запустить только на x86 и Jetson...
-
Китайские ПЛИС
BSACPLD ответил МАСТЕР LO тема в Работаем с ПЛИС, области применения, выбор
Если не париться со сборкой, то только BMTI - там вообще патчи не нужны. У K325 Fudan такой же геморрой со сборкой как и у JFMK50T4 - в инструкции по сборке те же самые пункты что и для 50. Ну и опять же смотря что собирать. Если без GTP/PCIe, то и у Fudan нет особых проблем со сборкой. А вот если они нужны, тогда да. -
Китайские ПЛИС
BSACPLD ответил МАСТЕР LO тема в Работаем с ПЛИС, области применения, выбор
1. В Procise есть jfm7a200t4, но мне пока не удалось получить информацию о возможности их поставки ни от Эпсилон, ни от Феникс Электроникс. 2. Да. Нужна лицензия на Procise. И придется извращатся с EDIF перегоняя нетлист из Vivado в Procise. -
Китайские ПЛИС
BSACPLD ответил МАСТЕР LO тема в Работаем с ПЛИС, области применения, выбор
Тут главный вопрос как автоматизировать переписывание констрейнов для IP из Vivado... У Procise и Vivado мягко говоря разный формат констрейнов. -
Китайские ПЛИС
BSACPLD ответил МАСТЕР LO тема в Работаем с ПЛИС, области применения, выбор
Procise как-то не очень дружит с командной строкой. Либо я не нашел как его правильно запускать через командную строку... К тому же он под Windows, поэтому живёт у меня в виртуалке, а Vivado с остальным софтом под Linux на основной системе. -
Китайские ПЛИС
BSACPLD ответил МАСТЕР LO тема в Работаем с ПЛИС, области применения, выбор
Да. Но только по кривому маршруту. Vivado+патч+переписывание констрейнов для IP блока PCIe+Procise. Сначала в Vivado собираем EDIF под xc7k325t попутно не забывая вручную вызывать ряд команд, т.к. автоматический патч правит далеко не все, потом транслируем его в EDIF для Procise фирменным конвертером от Fudan, руками переписываем xdc для IP PCIe под формат констрейнов для Fudan, потом всем это дело собираем в Procise. В общем куча ручной работы для каждой сборки. Нормально отлаживаться в таком режиме не реально. Только если тащить из Vivado отдельные IP либо прототип отлаживать на Xilinx, а в серию уже ставить Fudan. Добиться от Fudan чтобы они починили свой патч и не приходилось использовать Procise если нужен PCIe пока не удалось. -
Китайские ПЛИС
BSACPLD ответил МАСТЕР LO тема в Работаем с ПЛИС, области применения, выбор
Коллеги, тут мне поступило предложение изготовить разработанную мной отладочную плату на Fudan на продажу, но одну штуку нашей компании делать не выгодно. Если есть ещё желающие - пишите в личку. Если наберётся хотя бы 10 шт., сможем запустить в производство. User Manual с описанием что это за зверь чуть позже приложу. Пока вот Вам фото 🙂 -
UPD3. Пока изыскания следующие: Чтобы начать отправку пакета, после того как данные готовы, нужно изменить состояние конечной точки: USB30_IN_set(ENDP_1, ENABLE, ACK, DEF_ENDP1_IN_BURST_LEVEL, 1024); USB30_send_ERDY(ENDP_1 | IN, DEF_ENDP1_IN_BURST_LEVEL); После этого начинает вызываться EP1_IN_Callback(). Когда данные закончились, нужно поменять состояние конечной точки на NRDY: USB30_IN_set(ENDP_1, ENABLE, NRDY, DEF_ENDP1_IN_BURST_LEVEL, 1024); USB30_send_ERDY(ENDP_1 | IN, DEF_ENDP1_IN_BURST_LEVEL); И вот тут как раз и возникает проблема как определить момент, когда данные уже отправлены... Я пробовал отслеживать изменение nump: nump = USB30_IN_nump(ENDP_1); //nump: number of remaining packets to be sent status = ACK; if(prev_nump != nump) { status = NRDY; } prev_nump = nump; Но при таком подходе у меня успевает отправиться несколько пакетов прежде чем изменится nump...
-
UPD2. Взял библиотеку USB 3.0 от HYDRAUSB и создал проект с нуля. В направлении "ПК->Устройство" все ОК. В направлении "Устройство->ПК" как только я вызываю libusb_bulk_transfer устройство тут же возвращает мне пакет данных. Насколько я понял, в библиотеке реализована мгновенная отправка данные по запросу от ПК даже если передавать нечего. А мне нужно сделать как на CYUSB3014 с бесконечным ожиданием по вызову libusb_bulk_transfer пока не появятся данные для отправки. Опыта с USB на столь низком уровне у меня не много - буду признателен если кто-нибудь поможет допилить библиотеку для CH569 для отправки пакета по наличию данных для отправки. Проект прилагается. ch569w_fw.7z
-
UPD. Попробовал HYDRAUSB - не запускается отладка по UART. Пробовал и через printf и через UART1_SendString - в приемной консоли тишина. При этом через OpenWCH printf работает без проблем.
-
Либо там нерабочая библиотека, либо я в упор не понимаю, что я делаю не так. Сделал loopback. В EP1_OUT_Callback подтверждаю запись текущего пакета и инициирую обратную передачу. void EP1_OUT_Callback(void) { PRINT("EP1_OUT_Callback\n"); UINT16 rx_len, i; UINT8 nump; UINT8 status; USB30_OUT_Status(ENDP_1, &nump, &rx_len, &status); for(int i=0 ; i<rx_len ; i++) { PRINT("endp1RTbuff[%u] = %x\n", i, endp1RTbuff[i]); } USB30_OUT_ClearIT(ENDP_1); USBSS->UEP1_RX_DMA = (UINT32)(UINT8 *)endp1RTbuff; USB30_IN_Set(ENDP_1, DISABLE, ACK, 1, 1024); PRINT("USB30_Send_ERDY(ENDP_1 | IN, 1)\n"); USB30_Send_ERDY(ENDP_1 | IN, 1); USB30_OUT_Set(ENDP_1, ACK, 1); PRINT("USB30_Send_ERDY(ENDP_1 | OUT, 1)\n"); USB30_Send_ERDY(ENDP_1 | OUT, 1); } В EP1_IN_Callback обрабатываю передачу ответного пакета. void EP1_IN_Callback(void) { PRINT("EP1_IN_Callback\n"); UINT8 nump; nump = USB30_IN_Nump(ENDP_1); //nump: 剩余待发送包数量 for(int i=0 ; i<8 ; i++) { PRINT("endp1RTbuff[%u] = %x\n", i, endp1RTbuff[i]); } PRINT("nump = %u\n", nump); USBSS->UEP1_TX_DMA = (UINT32)(UINT8 *)endp1RTbuff; USB30_IN_ClearIT(ENDP_1); USB30_IN_Set(ENDP_1, ENABLE, ACK, 1, 1024); PRINT("USB30_Send_ERDY(ENDP_1 | IN, 1)\n"); USB30_Send_ERDY(ENDP_1 | IN, 1); } Пакет действительно отправляется обратно, но это происходит бесконечно вместо однократной отправки. Что я делаю не так? Может кто-нибудь поделиться рабочим примером для отправки пакетов в направлении "устройство->ПК"?
-
Ещё Fudan и BMTI. Купить их всяко легче чем Lattice - обратитесь к Эпсилон или Феникс Электроникс. Fudan частичные клоны Xilinx, BMTI полные клоны.
-
Уже нашел. В проекте почему-то был неправильно прописан путь к папке в которой лежит libCH56x_usb30.a. Но теперь другая проблема. Проект собрался, но не получается прошить ch569 из под Linux. Прошивальщик упорно не видит устройство, хотя в /dev оно есть. Запускал естественно от sudo по инструкции. Ещё меня смутило, что в документации устройство названо /dev/ch37x, а по факту появляется устройство /dev/ch37x1. Из под Windows плата прошивается без проблем, но хотелось бы прошивать сразу из под Linux.
-
При попытке собрать пример вылезает куча ошибок типа такой: Description Resource Path Location Type /home/sergey/Work/WCH/ch569/EVT/EXAM/USBSS/USBD/CH372Device/obj/../USB30/CH56x_usb30.c:528: undefined reference to `USB30_OUT_Set' CH372Device C/C++ Problem Причем изначально вообще была ругань на отсутствие некоторых include - китайцы накосячили с верхним/нижним регистром в именах файлов. Я это поправил, но не знаю как победить выше описанную ошибку. Как будто среда не находит libCH56x_usb30.a в котором и должны быть данные функции.
-
На USB2.0 есть описание регистров, а на USB3.0 описание отсутствует. В разделе про USB3.0 написано "используйте нашу библиотеку", а где её брать неизвестно.
-
Да. Сложилось впечатление, что это пример очень далёкий от реального применения. В купе с отсутствием документации на USB3.0 периферию данный пример весьма проблематично применить в реальном проекте.
-
Народ, а кто-нибудь пробовал реализовать на CH569W мост USB-FIFO по типу CYUSB3014? Или может быть есть у кого-нибудь грамотный пример приёма и отправки пакетов по USB3.0 на CH569W?
-
Китайские ПЛИС
BSACPLD ответил МАСТЕР LO тема в Работаем с ПЛИС, области применения, выбор
UPD 2. Есть проблема с переносом констрейнов для IP корок из Vivado в Procise. Кто-нибудь уже разобрался как это правильно делать? Просто перенести констрейны из xdc недостаточно... И где почитать про констрейны доступные в Procise? Например, можно ли сделать автоматическую генерацию клоков для PLL чтобы руками не прописывать все клоки с PLL.