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

k000858

Участник
 Профиль  Обзор контента

  • Постов

    322

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

  • Посещение

 Тип контента 

Сообщения, опубликованные k000858

  1. Опубликовано · Пожаловаться

    А есть у когонибудь опыт по отладке ядерной части ПО? Например драйверы и тд.

    Что нужно сделать что бы можно было по тому же gdb отлаживать, скажем, драйвер в ядре на уже загруженной системе? (про отладку загрузки того же драйвера пока молчу)

  2. Опубликовано · Пожаловаться

    On 9/3/2020 at 9:44 PM, Almaz1988 said:

    Добрый день.

    Имеется железка.

    photo_2020-09-02_18-58-11.thumb.jpg.931460fe5db1769d0e77b75d77c51924.jpg

    На борту процессор IMX6ULL и вай-фай чип WF200C. Драйвера для WF200C также есть в открытом доступе. Работать предстоит удаленно. У вас будет доступ к COM-порту (консольный вывод) и Ethernet (обновление прошивки утилитой sysupgrade).

    Необходимо добавить поддержку данного чипа в Openwrt образ для данного процессора. Доступ к исходникам будет предоставлен. WiFi чип должен работать одновременно и как STA, так и AP.

    Критерии приемки:

    • В ОС присутствует беспроводной сетевой интерфейс, который реализует доступ к сети по WiFi;
    • Реализована точка доступа, которая "светит" постоянно, подключившись к которой, можно открыть простенькую web-страницу и задать точку доступа и пароль, к которой и будет происходить подключение устройства для доступа к сети интернет по WiFi;
    • Все изменения в исходном коде закоммичены в отдельную ветку в репозитории с исходниками;

    Стоимость - 25к.

    Полная оплата после того, как продемонстрируете работу первых двух пунктов. После полной оплаты выгружаете исходники в репу. 

    Отклики присылайте на [email protected]

    Проект активно развивается. В последующем будет множество работы.

    Просьба откликаться, только если у вас есть достаточный опыт работы с OpenWrt, только если вас устраивают условия работы.

    такое стоит не 25к.

    25к - это половина месячной з/п самого дешевого джуна, который не сможет интегрировать драйвер wifi в сборку openwrt (говорю по опыту работы с кучей джунов как на удаленке так и нет). 

    прокачанный системный программист может сделать это и за день, если супер-повезет и драйвер в исходном состоянии совместим с версией ядра linux в вашей сборке openwrt, а это ни так 99.999%

     

    Так же стоит учитывать, что если ваш драйвер не умеет работать со старндартным /etc/config/wireless то веб-интерфейс OpenWrt придется значительно дорабатывать. а это еще вся работа x2

  4. Опубликовано · Пожаловаться

    5 hours ago, Tarbal said:

    Я просто сказал, что ядро Линукса использует виртуальные адреса и привел доказательства в ответ на ваше предположение, что в ядре виртуальные адреса не используются. Ни больше ни меньше. Остальное вы домыслили сами.

    По поводу Кейла или ИАРа для отладки Линукса:

    Считаю задачу неоправдано сложной. Тем более, что все давно пользуются GDB. Мне только однажды понадобился JTAG отладчик, когда я чинил еxception  в загрузчике. Да и чаще пользуются printk и debugfs, но о них еще до меня было сказано. я отладил немало драйверов, не пользуясь GDB.

    Для отладки ядра Линукса никакие отладчики с JTAG не нужны. В упоминавшейся выше книге

    Embedded Linux Primer - A Practical, Real-World Approach (2006)

    изложены методы отладки ядра.

    Для графики в GDB используйте DDD или Еклипс.
     

    Таким образом по отладке с использованием Кейл или ИАР я не смогу помочь. Если есть вопросы по стандартным методам, то постараюсь ответить.

    А не могли бы вы в 2х словах описать процесс отладки ядра/драйверов с помощью GDB на примере OpenWrt или обычного SDK-подобного дистрибутива?

    Для этого весь дистрибутив (исходники ядра, тулчейн и тд) необходимо закинуть в эклипс? Вот скажем есть openwrt (собранный бинарник ядра) с включенным в него GDB сервером, устройство прошито, ОС запущена. Какие дальнейшие шаги?

     

  5. Опубликовано · Пожаловаться

    окей, поставлю вопрос по-другому: как программно обойти эти заморочки? Простой рефакторинг вариант, но довольно время-затратный (драйвер состоит из более чем 700 файлов исходного кода).

    Если просто вложить драйвер в предкомпилированном виде в код ядра?

  6. Опубликовано · Изменено пользователем k000858 · Пожаловаться

    Есть дистрибутив, который необходимо выкладывать в открытый доступ, и который включает драйвер, скачанный из интернета (считай сворованный).

    Необходимо чтобы все компилировалось, но исходники проприетарного драйвера светить нельзя.

    Очевидный выход - завернуть исходники в блобы (предкомпилированный бинарник).

     

    Это нарушит лицензию? Что если автору проприетарного драйвера это не понравится, что он может от меня потребовать? Как обойти эти заморочки с лицензиями?

  8. Опубликовано · Пожаловаться

    В модели NAPI есть такой важный параметр как счётчик числа сетевых пакетов, при приёме меньше которого драйвер возвращается из режима программного пулинга и переходимт в режим ожидания прерываний. Поиграйтесь с этим параметром.

     

    P.S. Может подскажет какую мелочь, из об ласти сетевых драйверов или модулей фильтров сетевых протоколов вот этот текст: Практикум по Linux Kernel.

    Ну и Сетевое программирование в Linux - здесь о стыке сокетных буферов в ядре с сокетами простанства пользователя.

    благодарю за пинок в возможно верном направлении :smile3046:

  11. Опубликовано · Пожаловаться

    ничего не знаю про тест openwrt, но сомневаюсь что он может показать в каком слое стека застревают пакеты.

    самый банальный тест пропускной способности с помощью iperf (v3.13), трафик из Lan'а в Wan (хардварного NAT'а нет).

    При этом родной драйвер пропускает ~ гигабит, но загружает ЦПУ на 80%, мой драйвер пропускает лишь ~300Мбит/с, упираясь в 100% загрузку ЦПУ. очевидно что он выдал бы гигабит, если б хватило производительность ЦПУ.

    Думаю сокет тут непричем, сам драйвер менее производительный. Возможно какая то его настройка (считай - дефайн или ключ компиляции) так влияет.

     

    Повторюсь, драйвер работает по можели napi. Может есть мысли на что может тратиться процессорное время?

  12. Опубликовано · Пожаловаться

    почему вы думаете драйвер нагружает а не сокет например?

     

    При этом родной драйвер openWRT выжимает гигабит, нагрузка на проц ~80% (хардварный нат не активирован)

     

    тест проводится 1 в 1 с родным драйвером openwrt и мной интегрированным

  13. Опубликовано · Пожаловаться

    В общем драйвер успешно интегрирован, Lan'ы работают, Wan работает, трафик по мосту бежит.

    Однако вылезла новая проблема: при тесте пропускной способности портов (трафик Wan -> Lan для использования NAT'а) драйвер нагружает систему до 99%, при этом скорость всего ~300Mbt/s (порты гигабитные). При этом родной драйвер openWRT выжимает гигабит, нагрузка на проц ~80% (хардварный нат не активирован). С чем может быть связан такой эффект?

  14. Опубликовано · Пожаловаться

    В общем победил настройки встроенного в SoC свитча и 802.1Q vlan тэггирование: wan работает, lan'ы работают, даже мост более менее работает. но с лагами - похоже на потери.

     

    По видимому причина в netif_receive_skb = -1

     

    В каких случаях может такое происходить? Какому флагу соответствует -1 (1 = NET_RX_DROP).

  15. Опубликовано · Пожаловаться

    По делу есть кое какие продвижения: счетчик Rx уже щёлкает. Проблема была в отсутствии vlan тэгирования трафика. Теперь каждый полученный пакет тэгируется, за счет этого попадает в интерфейс. правда пока не тот. судя по всему пакеты, полученные по wlan'у, попадают в eth0.1 вместо eth0.2.

  17. Опубликовано · Пожаловаться

    распарсив sk_buff полученного пакета и сравнив его с аналогичным в родном драйвере openWRT, выяснил следующее:

    - интегрируемый драйвер отправляет в ядро sk_buff без mac и ip заголовках, то есть skb->data начинается с UDP заголовка (при получении ответа DHCP). В родном драйвере skb->data начинается с протокола (0x0800 IP) и ip заголовка. Осталось научить драйвер дорисовывать ip заголовок с протоколом

  18. Опубликовано · Пожаловаться

    сбрасывать пакеты сетевое устройство может по причине отсутствия свободных дескрипторов.

    попробуйте изменить кол-во дескрипторов, например

    #define DEF_RXDESC_NUM (100 вместо 4 если память позволяет..)

    если все пакеты теряются на нижнем уровне то это должно помочь.

    попробую увеличить. правда вряд ли это поможет, большая часть пакетов все же удачно принимается, однако счетчик Rx0 = 0.

     

    При том само устройство тоже отправляет пакеты (запрос DHCP), и этот запрос я вижу в программе DHCP сервер (мак точно устройства), но счетчик полученных пакетов на ПК 0. Как так??? ПО верхнего уровня пакет получает (DHCP запрос) а в свойствах сетевого соединения количество полученных пакетов не растет...

     

    добавлено:

     

    поправка - счетчик Rx на устройство растет в cat /proc/net/dev но не растет в ifconfig

    Rx на ПК от устройства так же работает, вижу пакеты и в сниффере, но счетчик пакетов в винде не растет.

     

    то есть у этих 2х эффектов одна причина.

     

    пакеты - DHCP: запросы от устройства к ПК, затем ответ от ПК устройству и последующий повторный запрос (так по кругу) потому что ответ от ПК попал в систему устройства (netif_receive_skb NET_RX_SUCCESS) но система этот пакет не переварила.

  19. Опубликовано · Пожаловаться

    В моем случае вместо netif_rx выполняется netif_receive_skb (т.к. используется метод NAPI), функция возвращает в части случаев NET_RX_SUCCESS, в части случаев NET_RX_DROP, что говорит о том, что половина пакетов дропается.

     

    При этом счетчик принятых пакетов в свойствах соединения растет. Так же растет и счетчик отправленных пакетов, однако входящих пакетов на ПК от устройства нет (соединение с ПК прямое).

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

  20. Опубликовано · Пожаловаться

    А как они поступают в ОС, в драйвере нужно вызвать netif_rx(skb) кажется?

    Кстати, что у вас возвращает ф-ция netif_rx?

    Я с NAPI моделью не работал, но думаю, что логика должна быть похожа:

    При возникновении rx прерывания создаем skb из принятых данных:

    skb = netdev_alloc_skb(net_dev, len);

    и далее что-то типа этого:

    data = skb_put(skb, len);
memcpy_fromio(data, addr, len);
netif_rx(skb);

    да, что то вроде того. все верно описали вы.

    в моем случае почему то не доходит до netif_rx, в драйвере куча ветвлений логики и препроцессора (#if)

     

    разбираюсь.

  21. Опубликовано · Пожаловаться

    Тогда выложите куда-нибудь посмотреть вашу ф-цию probe() из драйвера интегрируемого сетевого устройства (т.е. ф-цию инициализации драйвера).

    Если есть подозрения на нерабочие прерывания, нужно посмотреть как они задаются на этапе инициализации - printk куда-нибудь поставить...

    (если я конечно правильно понимаю проблему)

    Проблема с прерываниями уже решена.

     

    Что сделал:

    - подсмотрел номера нужных мне прерываний через cat /proc/interrupts в ОС при работающем родном драйвере openWRT (который я пытаюсь заменить на интегрируемый).

    - заменил номера прерываний на подсмотренные в дефайнах интегрируемого драйвера

     

    Родной openwrt инициализируется через module_platform_driver, номера прерываний задаются в device tree и передаются в драйвер через MODULE_DEVICE_TABLE (если я все верно понимаю). В интегрируемом мной драйвере же номера прерываний заданы в дефайнах. Почему они отличаются..не понимаю. К слову, мое сетевое устройство это встроенный в SoC свитч, MT7621 SoC.

     

    Прерывания на изменение линка и получение данных заработали. Так же заработала поллинг-функция. Дальше пакеты (в ОС) почему то не поступают, разбираюсь дальше.

     

     

  22. Опубликовано · Пожаловаться

    А как ваше интегрируемое сетевое устройство описано в Device tree? Как там сейчас задается прерывание?

     

     

     

    cat /proc/interrupts ?

    Вроде как никак не описано. Сам драйвер вызывается

     

    module_init(ra2882eth_init);
module_exit(ra2882eth_cleanup_module);

     

     

  23. Опубликовано · Пожаловаться

    почему старый драйвер не хочет работать с другим ядром я не могу предположить, но есть вероятно другие драйвера для нового ядра и можно посмотреть в чем отличия..,(изменился номер прерывания, не так регистрируется обработчик, не конфликтует ли с другим устройством т.к. общее прерывание)

     

    кажется была у linux возможность посмотреть на каких устройствах какие номера обработчиков зарегистрированы..

    сравниваю интегрируемый драйвер с имеющимися под новое ядро:

    - в старом интегрируемом драйвере номер прерывания задан дифайном 

    #define IRQ_ENET0    3     /* hardware interrupt #3, defined in ...

    - в новом драйвере номер прерывания выбирается вызовом функции platform_get_irq

     

    может тут какое то несоответствие? мне этот момент не очень понятен..

  24. Опубликовано · Пожаловаться

    непроинициализировано (неправвильно или неисправно) сетевое устройство, как бы самое простое предположение..

    что могло так смениться в версиях ядра? сам драйвер прекрасно работает в 3.10.*

    все подозрения на неработающее прерывание (нет реакции на изменение линка)

     

    в начале работы драйвер даже не компилировался, например изза отсутствия в ядре IRQF_DISABLED (удален с 4.12.5 ядра).

     

     

  25. Опубликовано · Пожаловаться

    я вообще не специалист по сетевому стеку, но насколько я понимаю сетевое устройство дергает хардверным прерыванием

    далее начинает работать драйвер сетевого ус-ва и для начала я бы посмотрел обрабатываются ли прерывания и что на входе у драйвера.

    Полинг (если я не ошибаюсь запускают софтверные прерывания когда в кольцевом буфере появляются данные от сетевого устройства).

    Вставить в код printf там где вызываются обработчики.

    Простите если не въехал в "тему" я просто пытаюсь сказать как бы я действовал на вашем месте.

    Вы все верно описали - мой драйвер работает по NAPI модели:

     

    1. Драйвер включает NAPI, но изначально тот находится в неактивном состоянии.
2. Прибывает пакет, и сетевая карта напрямую отправляет его в память.
3. Сетевая карта генерирует IRQ посредством запуска обработчика прерываний в драйвере.
4. Драйвер будит подсистему NAPI с помощью SoftIRQ (подробнее об этом — ниже). Та начинает собирать пакеты, вызывая в отдельном треде исполнения (thread of execution) зарегистрированную драйвером функцию poll.
5. Драйвер должен отключить последующие генерирования прерываний сетевой картой. Это нужно для того, чтобы позволить подсистеме NAPI обрабатывать пакеты без помех со стороны устройства.
6. Когда вся работа выполнена, подсистема NAPI отключается, а генерирование прерываний устройством включается снова.
7. Цикл повторяется, начиная с пункта 2.

     

    Прерываний нет (не только по прибытию входящих пакетов но и на изменение линка).

×
×
  • Создать...