Jump to content

    

sasamy

Участник
  • Content Count

    816
  • Joined

  • Last visited

Everything posted by sasamy


  1. Потестировал у себя, если еще интересно. Чтение SLIP sl_read.c #include <stdlib.h> #include <stdio.h> #include <unistd.h> #include <string.h> #include <arpa/inet.h> #include <net/ethernet.h> #include <net/if.h> #include <linux/if_packet.h> #include <sys/ioctl.h> #include <sys/socket.h> #include <sys/time.h> int main(int argc, char *argv[]) { struct ifreq ifr = {0}; struct sockaddr_ll addr = {0}; char buf[4096]; ssize_t n; int fd = socket(AF_PACKET, SOCK_RAW, htons(ETH_P_ALL)); if (fd == -1) { perror("socket"); exit(1); } strncpy(ifr.ifr_name, "sl0", sizeof(ifr.ifr_name)); if (ioctl(fd, SIOCGIFINDEX, &ifr) == -1) { perror("ioctl"); exit(1); } addr.sll_family = AF_PACKET; addr.sll_ifindex = ifr.ifr_ifindex; addr.sll_protocol = htons(ETH_P_ALL); if (bind(fd, (struct sockaddr*)&addr, sizeof(addr)) == -1) { perror("bind"); exit(1); } while (1) { n = read(fd, buf, sizeof(buf) - 1); if (n == -1) { perror("read"); exit(1); } buf[n] = 0; printf("received %li bytes: %s\n", n, buf); } return 0; } Передача SLIP sl_write.c #include <stdlib.h> #include <stdio.h> #include <unistd.h> #include <string.h> #include <arpa/inet.h> #include <net/ethernet.h> #include <net/if.h> #include <linux/if_packet.h> #include <sys/ioctl.h> #include <sys/socket.h> #include <sys/time.h> int main(int argc, char *argv[]) { struct ifreq ifr = {0}; struct sockaddr_ll addr = {0}; char buf[4096]; ssize_t n; int fd = socket(AF_PACKET, SOCK_RAW, htons(ETH_P_ALL)); if (fd == -1) { perror("socket"); exit(1); } strncpy(ifr.ifr_name, "sl0", sizeof(ifr.ifr_name)); if (ioctl(fd, SIOCGIFINDEX, &ifr) == -1) { perror("ioctl"); exit(1); } addr.sll_family = AF_PACKET; addr.sll_ifindex = ifr.ifr_ifindex; addr.sll_protocol = htons(ETH_P_ALL); if (bind(fd, (struct sockaddr*)&addr, sizeof(addr)) == -1) { perror("bind"); exit(1); } n = read(STDIN_FILENO, buf, sizeof(buf)); if (n == -1) { perror("read"); exit(1); } if (write(fd, buf, n) == -1) { perror("write"); exit(1); } return 0; } Команды выполняются с правами root На стороне передачи пакетов - плата с imx8mm. В терминале настроил SLIP для uart-a ttymxc1 # slattach -p slip -s 115200 /dev/ttymxc1 & # ifconfig sl0 up Передавал данные такой командой # printf "123456" | sl_write На стороне приема пакетов - PC с преобразователем USB-serial Сначала чтение "сырых" данных напрямую с uarta # cat /dev/ttyUSB0 | xxd -g1 -c8 00000000: c0 31 32 33 34 35 36 c0 .123456. Потом настроил SLIP для uart-a ttyUSB0 # slattach -p slip -s 115200 /dev/ttyUSB0 & # ifconfig sl0 up Прием декапсулированных данных # sl_read received 6 bytes: 123456 received 6 bytes: 123456
  2. а вам это действительно нужно ? у меня сложилось впечатление что нет slattach зарегистрирует калбэк в драйвере tty выбранного уарта, например slattach -p slip -s 115200 /dev/ttyS0 & принятые данные этого уарта пойдут не в юзерспейс а в ф-цию slip_receive_buf https://elixir.bootlin.com/linux/v5.5.6/source/drivers/net/slip/slip.c#L682 эта ф-ция побайтно обработает принятый буфер https://elixir.bootlin.com/linux/v5.5.6/source/drivers/net/slip/slip.c#L711 отыщет начало и конец, заменит экранированные байты и в свой внутренний буфер попадет уже 12 34 56 78, когда найдет конец фрейма - скопирует свой внутренний буфер в буфер skb https://elixir.bootlin.com/linux/v5.5.6/source/drivers/net/slip/slip.c#L968 https://elixir.bootlin.com/linux/v5.5.6/source/drivers/net/slip/slip.c#L319 и этот буфер вы и получите при чтении из raw socketa при записи в raw socket буфер skb минует сетевой стек и попадёт на вход ф-ции sl_xmit без обработки https://elixir.bootlin.com/linux/v5.5.6/source/drivers/net/slip/slip.c#L499 https://elixir.bootlin.com/linux/v5.5.6/source/drivers/net/slip/slip.c#L520 https://elixir.bootlin.com/linux/v5.5.6/source/drivers/net/slip/slip.c#L375 тут непосредственно инкапсуляция в SLIP https://elixir.bootlin.com/linux/v5.5.6/source/drivers/net/slip/slip.c#L397 https://elixir.bootlin.com/linux/v5.5.6/source/drivers/net/slip/slip.c#L918 тут запись в в порт tty уже готового фрейма SLIP https://elixir.bootlin.com/linux/v5.5.6/source/drivers/net/slip/slip.c#L408 ключевой момент - надо биндить raw socket на конкретный сетевой интерфейс http://www.microhowto.info/howto/capture_ethernet_frames_using_an_af_packet_socket_in_c.html#idp61712 в примере в общем все что надо есть правда там не raw socket а packet socket называют
  3. а какая разница ? после slattach появится сетевой интерфейс sl0 - для него конечно будут особенности, надо пробовать, но в остальном интерфейс системы одинаковый для всех утсройств - ppp, slip, wlan, eth. Драйвер slip в ядре и есть только фреймер - он заполняет буфер skb декапсулированными данными, помечает что в буфере IP фрейм и отсылает в сетевой стек, когда вы получите этот буфер в неизменном виде - плевать что там доллжен быть IP фрейм - делайте с ним что вам нужно.
  4. гы, а зачем вы тогда тему создавали ? raw socket даст ровно то что вы спрашивали в самом начале - данные после фреймера SLIP и возможность обернуть произвольный буфер в фрейм SLIP, сомневаюсь что в винде есть что-то подобное готовое - Linux на голову выше винды и гибче.
  5. сырые данные это буфер который принимает драйвер в ядре - пофиг что там IP или нет, к вам этот буфер попадет минуя сетевой стек ядра, У вас же не IP вот и делайте с ним что хотите - судя по коду драйвер сразу выпиливает из буфера ESC последовательности и добавляет при отправке https://elixir.bootlin.com/linux/v5.5.6/source/drivers/net/slip/slip.c#L711
  6. а что еще проще сокетов бывает ? попробуйте создать raw socket и забиндить его на SLIP интерфейс который появляется после slattach (sl0) чтобы получать/отправлять сырые данные. Вот тут есть примеры для изернета http://www.microhowto.info/howto/capture_ethernet_frames_using_an_af_packet_socket_in_c.html
  7. IMX8M-mini: MIPI CSI и сопроцессор

    Сам порт можно и не трогать - в Linux есть драйвер а данные CSI бридж складывает в DDR через встроенный контроллер DMA. Для m4 доступны первые 2 гигабайта DDR - можно написать драйвер чтобы a53 сообщал адрес буфера, размер, формат данных и всё что нужно для обработки ядру m4 - есть драйверы и примеры для обмена данными между ядрами через rpmsg для Linux на a53 и FreeRTOS на m4. Вопрос зачем m4 с 400 МГц если там 4 ядра a53 есть с частотой больше гигагерца.
  8. MAC + PHY

    Так у вас судя по схеме не подключена линия запроса на прерывание от PHY к MAC - подключите и должно работать. Со встроенными MAC проще - там поллинг включается если явно не указана в DT линия IRQ, с USB MAC такое не прокатит скорей всего - драйвер MAC всегда регистрирует прерывание и ожидает его от PHY, хотя я не уверен https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/usb/lan78xx.c#n2974 посмотрите что пишет ядро когда интерфейс поднимается, например тут поллинг и есть ли в логах отклик от драйвера при отключении/включении кабеля наподобие этого
  9. MAC + PHY

    Если больше ничего в схеме не перепутано это по-моему единственное логическое объяснение. Можно попробовать разорвать линию RESETn, еше попробовать вручную сделать длитеьный сброс - вставить задержку на пару секунд перед вызовом phydev = phy_find_first(dev->mdiobus); и кратковременно проводком замкнуть на землю RESETn. Еще номиналы подтяжек на MDIO проверить - неизвестно что там реально запаяно.
  10. MAC + PHY

    потому что драйвер MAC его не видит на шине MDIO и все прекрасно поимает - если бы вы включили отладочные сообщения увидели бы сообщения драйвера об этом https://elixir.bootlin.com/linux/v4.19.96/source/drivers/net/usb/lan78xx.c#L2072 сейчас он молча предполагает что есть неуправляемый PHY с фиксированными параметрами - по умолчанию вывод ф-ций *_dbg отключен https://stackoverflow.com/questions/50504516/enable-linux-kernel-driver-dev-dbg-debug-messages а какие вы ешё можете предложить варианты в такой ситуации ? через DT максимум что можно изменить - MAC-адрес который и без этого легко меняется из юзерспейс и поведение лампочек
  11. MAC + PHY

    Адрес PHY устанавливается исключительно аппаратной конфигурацией - я вам даташит процитировал не может он скакать с 0 на 1 если CONFIG подключен к VSS
  12. MAC + PHY

    и вы бодро говорите что с подключением все ОК ?
  13. MAC + PHY

    почему 7800 если у вас 7801 с внешним PHY, да и сомневаюсь что прописав PHY в DT это что-то изменит - PHY должен автоматом определяться. Осцилом не пробовали смотреть обмен по mdio ? для начала отладочные сообщения включите в драйвере
  14. MAC + PHY

    Драйвер lan7801 не находит PHY и срабатывает ветка для fixed phy https://elixir.bootlin.com/linux/v4.19.96/source/drivers/net/usb/lan78xx.c#L2070 поэтому и ethtool показывает фиксированные параметры - что-то у вас не так со схемой подключения. Я бы начал проверку с VDDO_SEL pin https://www.marvell.com/documents/eoxwrbluvwybgxvagkkf/ потом RESETn, CONFIG - много мест где можно накосячить, маловероятно что софтовая проблема
  15. Работа с YOCTO

    yocto build qt sdk
  16. STM32MP1 - bare metal

    я пробовал с майнстримным ядром Linux и Mesa, собирал в buildroot - работает, где-то читал что разработчики embox запускали Quake3D для демонстрации работоспособности популярный готовый графический тулкит, для рендеринга может использовать 3D GPU, Просто я видел где-то пример того что вы делали - подобное на QML толковый дизайнер за пол-часа сделает лучше.
  17. Embedded Linux

    дело не в энтузиазме - это просто не нужно. Насчёт опенсорса у вас очень старые понятия - многие корпорации ведут разработку с отрытыми исходниками. IBM планировала вложить в разработку экосистемы Linux для своих процессоров Power 6 млрд долларов - энтузиазмом там давно не пахнет, это бизнес.
  18. STM32MP1 - bare metal

    Вспомнил один проект https://ru.wikipedia.org/wiki/Embox https://github.com/embox/embox там есть даже портированные драйверы из Linux i.mx6 и для 3D GPU, может пригодится. Лицензия BSD так что теоретически исходники открывать не нужно (правда я не не уверен в случае использования Qt со статической линковкой в один образ без коммерческой лицензии)
  19. STM32MP1 - bare metal

    тут есть тесты sdma, результаты как-то не впечатляют, даже теоретический максимум http://billauer.co.il/blog/2017/08/nxp-freescale-sdma-memory-map-throughput/ для сравнения CPU и IPU https://community.nxp.com/docs/DOC-95014 никакой засекреченности я там не заметил как и в описании IPU тоже. PXP намного проще IPU поэтому и предложил его.
  20. STM32MP1 - bare metal

    Это всё же сильно разные устройства - sdma это 16 битное микроконтроллерное ядро с rtos - оно для низкоскоростной периферии которой много и надо параллельно её обслуживать, PXP - хз что там внутри, но оптимизирован для обработки графики и данные он буферизует при копировании намного лучше, у того же SPI FIFO всего 64 слова кажется, у PXP блок 16х16 слов можно установить. PS насчет sdma я перепутал - там не rtos а Scheduler на блок-схеме :)
  21. STM32MP1 - bare metal

    Нет, но думаю sdma совсем не для графики задуман. Хотя и PXP если использовать для перекидывания данных - не особо ускоритель , а вот бработку типа CSC и scaling при выводе видео на arm9 он ускорял значительно .
  22. STM32MP1 - bare metal

    ну вы мануал на PXP почитайте внимательно, см 53.3.37 Clipping source images размеры выходного буфера при этом делаете равным обрезанному входному - вот вам и непрерывная область в которую скопируется нужный кусок экрана
  23. STM32MP1 - bare metal

    Нет, его (Data Co-Processor (DCP)) я не использовал. Вы просто не поняли как работает блит в PXP. На картинке выше два наложенных слоя: первый RGB буфер экрана Linux (framebuffer), второй YUV кадр видеопроигрываетеля, они накладываются и получается финальный выходной RGB буфер который отправляется в контроллер LCD, хотя это не обязательно - его можно подать на вход чтобы снова наложить еще что-то. Единственно что я снаскоку увидел - в imx233 можно было до 8 слоёв накладывать, в imx6 вижу только 2.
  24. STM32MP1 - bare metal

    странно, на imx233 он был :) перводначально я работал с ним напрямую с регистрами, потом переделал под стандартный линуксовый драйвер v4l2 out. Хотя про i.mx6 утверждать не буду - я там не пробовал, не было необходимости при наличии IPU и 2D GPU http://www.starterkit.ru/html/index.php?name=forum&amp;op=view&amp;id=7471&amp;num=3#7915 так оставляйте на входе и выходе один формат.
  25. если использовать на десктопных процессорах те же подходы что и на микроконтроллерах то артефакты на экране не самая большая беда.