x86_64 драйвер на arm

реверснуть
или
забить

можно попробовать поиграться с qemu-user

Мельком глянул, там вроде идёт работа без драйверов, через файл в /dev, через qemu пробовал?

Никогда таким не занимался. Можно немного подробнее, что именно мне проверить? Могу только сказать, что когда я подключаю свитч к pi, то новых файлов непосредственно в /dev не появляется

С поддержкой акронейма я уже пообщался, они мне любезно говорят: «не используйте orange pi, там usb стек вообще плохой», но я им не верю

И правильно, что не веришь - он не может сильно отличаться: там только 2 уровня абстракции - драйверный (xhci, ohci, uhci) и юзерспейс, за который отвечает libusb (я тут слегка вру, но либусб реально очень много умеет). У тебя есть несколько путей:

1) запуск в qemu

2) поставить сниффер на USB, посмотреть, какие команды когда идут. Взять их хедеры с их структурами данных, найти похожее и запилить это же на libusb. Если вопрос в скорости протокола не стоит, то libusb хватит. Если стоит, то копать потом в сторону xhci, ohci

3) Прямым текстом попросить техподдержку скомпилить нужную тебе либу с флагами CROSS_COMPILE, HOST, TARGET (значения глянь сам для armv7) и отправить тебе результат под твою ответственность (ну типа NO WARRANTY и остальное из gpl).

Если программеры там не самые рукожопые и код для 2 систем одинаковый, то есть немалый шанс, что библиотека протокола обмена соберется с полпинка.

P.S.: поиск по бинарным компиляторам из x86 в armv7 ничего не дал, но может clang сумеет декомпилировать бинари до своего байткода, а его уже можно собрать в чужую архитектуру.

че дает dmesg при подключении девайса?

Userspace QEMU вроде как умеет x86 отдельные бинари запускать на ARM, но я чето не уверен насчет общения с драйверами через этот чудо-костыль.

А в dmesg есть что?

Если уж и пытаться использовать чужие библиотеки, то хотя бы совпадающей разрядности. Т.е. не x86_64, а i686.

Тут проблема может быть в том, что запускать нечего: захочет человек автоматизировать свою работу и повесить все на orange pi, и получится, что все навороты можно выбросить нафиг и останется 1 библиотека с недоделанной оберткой.

Как бы не получилось так, что под armv7 придется линковаться с x86-либой, так как это невозможно.

Ок. Дрова есть. Пойдем глубже - что дает lsusb -v -d 24ff:0015 на обеих архитектурах при вставленном девайсе?

При установке девкита insmod/modprobe происходит? Если да, то у меня для тебя плохие новости.

Попробуй ExaGear Desktop. Платный. Можно попробовать сделать то же самое при помощи QEMU, бесплатно.

Попробуй ExaGear Desktop. Платный. Можно попробовать сделать то же самое при помощи QEMU, бесплатно.

ExaGear для апельсинки-зеро стоит в четыре раза дороже самой апельсинки - 40+ баксов. за эти деньги можно на авито купить недоубитый небук на атоме и юзать ненужное нативно

Прошу прощения за задержку. lsusb вот.
ARM

orangepi@orangepione:~$ lsusb -v -d 24ff:0015

Bus 003 Device 003: ID 24ff:0015
Couldn't open device, some information will be missing
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0        32
  idVendor           0x24ff
  idProduct          0x0015
  bcdDevice            1.03
  iManufacturer           2
  iProduct                3
  iSerial                 1
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           32
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0
    bmAttributes         0xc0
      Self Powered
    MaxPower              100mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass    136
      bInterfaceProtocol     16
      iInterface              4
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0020  1x 32 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0020  1x 32 bytes
        bInterval               0

Bus 001 Device 021: ID 24ff:0015  
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        32
  idVendor           0x24ff 
  idProduct          0x0015 
  bcdDevice            1.03
  iManufacturer           2 
  iProduct                3 
  iSerial                 1 
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           32
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0xc0
      Self Powered
    MaxPower              100mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass    136 
      bInterfaceProtocol     16 
      iInterface              4 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0020  1x 32 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0020  1x 32 bytes
        bInterval               0

devkit ставится через pip. Там внутри .so-шка и питоновские файлы. Если я не ошибаюсь insmod/modprobe pip не делает.

Доберусь до никсов - гляну, что в девките.

Если всё как ты описываешь и ты не сидишь под рутом (дополнительная гарантия, что установленный в home девкит не делает ничего с ядром и вообще с системой), то уже минус одной проблемой - оно точно общается с системой не посредством своих драйверов (драйвера у нее для USB 2.0), а только посредством библиотеки. Теперь вопрос - lddtree lib<yourlibrary>.so что выдает? есть линк с libusb?

Написать порт для той библиотеки будет несложно (но я бы отпинал их техподдержку вместо раскуривания манов)-оно содержит 1 интерфейс и 2 конечные точки в нем, с которыми идет общение сырыми данными в пакетах по 32 байта. Если вариантов, кроме портирования либы не остается и это не пугает, тогда посмотри примеры работы с libusb. Как разберешься с libusb - грепай по девкиту слова 'init', 'packet', 'data', 'status'. Чтобы запустить это устройство на любой платформе, в него надо записать какие-то 32 байта. На вопрос «какие 32 байта?» ответ должен быть в хедерах. Хотя если разрабы решили совсем анально огородиться и запихнули всё в библиотеку вместо хедеров (но зачем...), то придется сниффать.

А че за свитч и че он умеет?

Хотя смотрю я список изменений по твоей ссылке и вижу, что программеры там рукожопые:

Relay Class: setState -> setEnable (индусский английский)
USB Class: getHubState (removed) new API is getPortState (неверно выбранные структуры данных)

К сожалению, устанавливал под рутом, так как у меня в юзерспейсе на домашней машине как-то очень жестко прописался питон 3 от анаконды. Меня это ничуть не беспокоило, но вот этот пакет не хотел ставиться на тройку, а выполнить все под рутом было быстрее чем найти проблему(да-да, я рукожоп).

У него есть один выходной usb порт и 4 входных usb. Через контрольный usb порт управляется какой входной соединен с выходным. При этом само устройство, которое подсоединено к выходному, свич не видит, для него свич прозрачен. В быту от него толку немного, а вот в автоматическом тестировании полезен.

А управление-то и программирование в чем заключается? Нафига ему вообще команды нужны и свой интерфейс? Только таблицу перенаправлений создавать (usb-аналог iptables)? Если да, то там библиотека вообще небольшая должна быть и весь интерфейс заключается в 1-4 командах. Обычно делают по одному из двух сценариев (в зависимости от сложности устройства):

1) set_input_ports - команда, которая выбирает с каких входных портов сливать данные в выходной порт. самый простой вариант.

2) init_control, deinit_control, add_rule, rm_rule.

Каждая команда высылает пакет по примерно такому формату: <magic_constant><command><data:port_numbers, flags, etc..>.

Нафига ему вообще команды нужны и свой интерфейс?

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