Перейти к содержанию
    

BSACPLD

Свой
  • Постов

    912
  • Зарегистрирован

  • Посещение

  • Победитель дней

    5

Весь контент BSACPLD


  1. Я его не собирал. Взял готовый образ: https://www.armbian.com/rock-5b/
  2. у меня в linux-headers нет скриптов необходимых для сборки драйверов, и при попытке собрать их через sudo make modules_prepare появляется приведенная выше ошибка. sudo apt install linux-headers-$(uname -r) На armbian так делать нельзя - версия будет не соответствовать текущему ядру. linux-headers и linux-kernel нужно ставить через утилиту armbian-config, иначе будут расхождения в версиях. По этим граблям я уже прошелся 😞
  3. Коллеги, я тут пытаюсь установить 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, там такая же ошибка...
  4. Ещё один вопрос возник. Как корректно маппить регистры 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 😞
  5. На практике у меня получилось обратное. На x86 dma_mmap_coherent некорректно отрабатывает. Приходится использовать remap_pfn_range для x86 ветки. UPD. Вы были правы. Если вместо (void*)(vma->vm_start) передавать виртуальный адрес от dma_alloc_coherent, то dma_mmap_coherent работает и на x86 тоже 🙂
  6. Разобрался. Надо было физический адрес не из виртуального через 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;
  7. dma_mmap_coherent

    Народ, подскажите, пожалуйста, как правильно использовать 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. Что я делаю не так?
  8. Так может Вам написать свой собственный захватчик видео вместо Gstreamer? Я так делал в своем проекте - получилось и просто и сложно одновременно. Просто - прошивка для ПЛИС и софт на компьютере получились очень простые. Сложно - свой собственный драйвер пока удалось запустить только на x86 и Jetson...
  9. Если не париться со сборкой, то только BMTI - там вообще патчи не нужны. У K325 Fudan такой же геморрой со сборкой как и у JFMK50T4 - в инструкции по сборке те же самые пункты что и для 50. Ну и опять же смотря что собирать. Если без GTP/PCIe, то и у Fudan нет особых проблем со сборкой. А вот если они нужны, тогда да.
  10. 1. В Procise есть jfm7a200t4, но мне пока не удалось получить информацию о возможности их поставки ни от Эпсилон, ни от Феникс Электроникс. 2. Да. Нужна лицензия на Procise. И придется извращатся с EDIF перегоняя нетлист из Vivado в Procise.
  11. Тут главный вопрос как автоматизировать переписывание констрейнов для IP из Vivado... У Procise и Vivado мягко говоря разный формат констрейнов.
  12. Procise как-то не очень дружит с командной строкой. Либо я не нашел как его правильно запускать через командную строку... К тому же он под Windows, поэтому живёт у меня в виртуалке, а Vivado с остальным софтом под Linux на основной системе.
  13. Да. Но только по кривому маршруту. Vivado+патч+переписывание констрейнов для IP блока PCIe+Procise. Сначала в Vivado собираем EDIF под xc7k325t попутно не забывая вручную вызывать ряд команд, т.к. автоматический патч правит далеко не все, потом транслируем его в EDIF для Procise фирменным конвертером от Fudan, руками переписываем xdc для IP PCIe под формат констрейнов для Fudan, потом всем это дело собираем в Procise. В общем куча ручной работы для каждой сборки. Нормально отлаживаться в таком режиме не реально. Только если тащить из Vivado отдельные IP либо прототип отлаживать на Xilinx, а в серию уже ставить Fudan. Добиться от Fudan чтобы они починили свой патч и не приходилось использовать Procise если нужен PCIe пока не удалось.
  14. Коллеги, тут мне поступило предложение изготовить разработанную мной отладочную плату на Fudan на продажу, но одну штуку нашей компании делать не выгодно. Если есть ещё желающие - пишите в личку. Если наберётся хотя бы 10 шт., сможем запустить в производство. User Manual с описанием что это за зверь чуть позже приложу. Пока вот Вам фото 🙂
  15. 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...
  16. UPD2. Взял библиотеку USB 3.0 от HYDRAUSB и создал проект с нуля. В направлении "ПК->Устройство" все ОК. В направлении "Устройство->ПК" как только я вызываю libusb_bulk_transfer устройство тут же возвращает мне пакет данных. Насколько я понял, в библиотеке реализована мгновенная отправка данные по запросу от ПК даже если передавать нечего. А мне нужно сделать как на CYUSB3014 с бесконечным ожиданием по вызову libusb_bulk_transfer пока не появятся данные для отправки. Опыта с USB на столь низком уровне у меня не много - буду признателен если кто-нибудь поможет допилить библиотеку для CH569 для отправки пакета по наличию данных для отправки. Проект прилагается. ch569w_fw.7z
  17. UPD. Попробовал HYDRAUSB - не запускается отладка по UART. Пробовал и через printf и через UART1_SendString - в приемной консоли тишина. При этом через OpenWCH printf работает без проблем.
  18. Либо там нерабочая библиотека, либо я в упор не понимаю, что я делаю не так. Сделал 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); } Пакет действительно отправляется обратно, но это происходит бесконечно вместо однократной отправки. Что я делаю не так? Может кто-нибудь поделиться рабочим примером для отправки пакетов в направлении "устройство->ПК"?
  19. Ещё Fudan и BMTI. Купить их всяко легче чем Lattice - обратитесь к Эпсилон или Феникс Электроникс. Fudan частичные клоны Xilinx, BMTI полные клоны.
  20. Уже нашел. В проекте почему-то был неправильно прописан путь к папке в которой лежит libCH56x_usb30.a. Но теперь другая проблема. Проект собрался, но не получается прошить ch569 из под Linux. Прошивальщик упорно не видит устройство, хотя в /dev оно есть. Запускал естественно от sudo по инструкции. Ещё меня смутило, что в документации устройство названо /dev/ch37x, а по факту появляется устройство /dev/ch37x1. Из под Windows плата прошивается без проблем, но хотелось бы прошивать сразу из под Linux.
  21. При попытке собрать пример вылезает куча ошибок типа такой: 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 в котором и должны быть данные функции.
  22. На USB2.0 есть описание регистров, а на USB3.0 описание отсутствует. В разделе про USB3.0 написано "используйте нашу библиотеку", а где её брать неизвестно.
  23. Да. Сложилось впечатление, что это пример очень далёкий от реального применения. В купе с отсутствием документации на USB3.0 периферию данный пример весьма проблематично применить в реальном проекте.
  24. Запуск USB на CH569/CH565

    Народ, а кто-нибудь пробовал реализовать на CH569W мост USB-FIFO по типу CYUSB3014? Или может быть есть у кого-нибудь грамотный пример приёма и отправки пакетов по USB3.0 на CH569W?
  25. UPD 2. Есть проблема с переносом констрейнов для IP корок из Vivado в Procise. Кто-нибудь уже разобрался как это правильно делать? Просто перенести констрейны из xdc недостаточно... И где почитать про констрейны доступные в Procise? Например, можно ли сделать автоматическую генерацию клоков для PLL чтобы руками не прописывать все клоки с PLL.
×
×
  • Создать...