Jump to content

    

k000858

Участник
  • Content Count

    322
  • Joined

  • Last visited

Community Reputation

0 Обычный

About k000858

  • Rank
    Местный

Recent Profile Visitors

3369 profile views
  1. А есть у когонибудь опыт по отладке ядерной части ПО? Например драйверы и тд. Что нужно сделать что бы можно было по тому же gdb отлаживать, скажем, драйвер в ядре на уже загруженной системе? (про отладку загрузки того же драйвера пока молчу)
  2. такое стоит не 25к. 25к - это половина месячной з/п самого дешевого джуна, который не сможет интегрировать драйвер wifi в сборку openwrt (говорю по опыту работы с кучей джунов как на удаленке так и нет). прокачанный системный программист может сделать это и за день, если супер-повезет и драйвер в исходном состоянии совместим с версией ядра linux в вашей сборке openwrt, а это ни так 99.999% Так же стоит учитывать, что если ваш драйвер не умеет работать со старндартным /etc/config/wireless то веб-интерфейс OpenWrt придется значительно дорабатывать. а это еще вся работа x2
  3. окей, поставлю вопрос по-другому: как программно обойти эти заморочки? Простой рефакторинг вариант, но довольно время-затратный (драйвер состоит из более чем 700 файлов исходного кода). Если просто вложить драйвер в предкомпилированном виде в код ядра?
  4. Есть дистрибутив, который необходимо выкладывать в открытый доступ, и который включает драйвер, скачанный из интернета (считай сворованный). Необходимо чтобы все компилировалось, но исходники проприетарного драйвера светить нельзя. Очевидный выход - завернуть исходники в блобы (предкомпилированный бинарник). Это нарушит лицензию? Что если автору проприетарного драйвера это не понравится, что он может от меня потребовать? Как обойти эти заморочки с лицензиями?
  5. пффф с web технологиями в embedded не сталкивались?))
  6. благодарю за пинок в возможно верном направлении :smile3046:
  7. http://blog.qt.io/blog/2018/05/03/qt-microncontrollers-mcu/ Вот тут то и пригодятся суперпроизводительные F7/H7. На мой взгляд технология поперспективнее явы на STM32. Как считаете?
  8. Как в драйвере задать битовую маску CPU, которая после создания соединения прописывается в rps_cpus (/sys/class/net/<device>/queues/<rx-queue>/rps_cpus ) ???
  9. самый банальный тест пропускной способности с помощью iperf (v3.13), трафик из Lan'а в Wan (хардварного NAT'а нет). При этом родной драйвер пропускает ~ гигабит, но загружает ЦПУ на 80%, мой драйвер пропускает лишь ~300Мбит/с, упираясь в 100% загрузку ЦПУ. очевидно что он выдал бы гигабит, если б хватило производительность ЦПУ. Думаю сокет тут непричем, сам драйвер менее производительный. Возможно какая то его настройка (считай - дефайн или ключ компиляции) так влияет. Повторюсь, драйвер работает по можели napi. Может есть мысли на что может тратиться процессорное время?
  10. тест проводится 1 в 1 с родным драйвером openwrt и мной интегрированным
  11. В общем драйвер успешно интегрирован, Lan'ы работают, Wan работает, трафик по мосту бежит. Однако вылезла новая проблема: при тесте пропускной способности портов (трафик Wan -> Lan для использования NAT'а) драйвер нагружает систему до 99%, при этом скорость всего ~300Mbt/s (порты гигабитные). При этом родной драйвер openWRT выжимает гигабит, нагрузка на проц ~80% (хардварный нат не активирован). С чем может быть связан такой эффект?
  12. В общем победил настройки встроенного в SoC свитча и 802.1Q vlan тэггирование: wan работает, lan'ы работают, даже мост более менее работает. но с лагами - похоже на потери. По видимому причина в netif_receive_skb = -1 В каких случаях может такое происходить? Какому флагу соответствует -1 (1 = NET_RX_DROP).
  13. По делу есть кое какие продвижения: счетчик Rx уже щёлкает. Проблема была в отсутствии vlan тэгирования трафика. Теперь каждый полученный пакет тэгируется, за счет этого попадает в интерфейс. правда пока не тот. судя по всему пакеты, полученные по wlan'у, попадают в eth0.1 вместо eth0.2.