gosha-z 2 3 июля Опубликовано 3 июля · Жалоба 11 hours ago, kramolnic said: поделитесь прямой ссылкой на репозиторий с данным актуальным рокчиповым форком ядра версии 5.10.198 Пожалуйста Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
andreyvdovin 0 23 июля Опубликовано 23 июля · Жалоба В 01.11.2023 в 20:04, mitya1698 сказал: поделали программеры разного в итоге почти все хорошо, но почему-то в сети при передаче с рока редко, но пролезают STD пакеты вместо EXT Данные в них верные, просто STD ну и естественно ID не тот что нужно (нет старшей части) Пакет абсолютно нормально сформированный по правилам STD, все биты в норме. Отправки STD пакетов у нас не запрограммировано. Добрый день, Удалось ли вам решить данный вопрос? У нас происходит тоже самое. Драйвер сам работает нормально, но периодически проскакивают стандартные пакеты. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
mitya1698 18 23 июля Опубликовано 23 июля · Жалоба нет, это не решилось. Похоже это аппаратная проблема контроллера. И видимо нерешаемая. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
kramolnic 0 23 июля Опубликовано 23 июля · Жалоба On 7/3/2024 at 1:48 PM, gosha-z said: Пожалуйста Спасибо! К сожалению, последний коммит из данной ветки (https://github.com/rockchip-linux/kernel/tree/develop-5.10/drivers/net/can/rockchip) был внесен в указанную Вами ветку всего 8 месяцев назад (6 ноября 2023 года), хотя в ветке Armbian linux-rockchip существует с 9 июня 2021 года (https://github.com/armbian/linux-rockchip/commits/rk-6.1-rkr3/drivers/net/can/rockchip/rockchip_can.c). Я пробовал собирать драйвер rockchip_can почти самой свежей версии из ветки rk-6.1.-rkr3, но проблема по-прежнему сохранилась. При высокой загрузке шины контроллер CAN по-прежнему сбоит. Забавно, но в самой свежей версии ядра Linux (самая свежая, нестабильная девелоперская версия ядра) для Armbian данные драйверы были, похоже, исключены из конфигуратора ядра - модули ядра rockchip_can и rockchip_canfd вообще отсутствуют. В актуальной же версии ядра (5.10) сборка драйверов rockchip_can и rockchip_canfd была поломана - см. коммиты от марта и апреля 2024 года. На данный момент Armbian с ядром версии 5.10 вообще не собирается при включении в состав системы модулей rockchip_can / rockchip_canfd, хотя успешно собиралась в прошлом году. Проблему со сборкой драйверов последней версии решил следующим образом - на старый образ системы Armbian с ядром 5.10 собрал вручную драйверы rockchip_can и rockchip_canfd предыдущей (до 2024 года) ревизии - от 11 августа 2021 года (Change-Id: I985eb81f4e06c085be66d2db2cd5c879bda0dd69). Но даже эта версия драйвера проблему не исправляет. Попытки через Device Tree Layout поднять частоты на CAN также не дали результатов (хотя на rock pi 3A поднятие частоты, кажется, помогло и плата уехала к заказчику в составе комплекса). 10 hours ago, andreyvdovin said: Добрый день, Удалось ли вам решить данный вопрос? У нас происходит тоже самое. Драйвер сам работает нормально, но периодически проскакивают стандартные пакеты. Доброго времени суток! К сожалению, проблема не решена. Из самой свежей версии ядра Linux под дистрибутивом Armbian, который мы используем, модули rockchip и rockchip_can были почему-то исключены (теперь даже недоступны в конфигураторе ядра), при попытке собрать старое ядро 5.10 драйверы rockchip_can и rockchip_canfd перестали собираться из-за последних изменений от марта-апреля 2024 года. А последняя собирабельная ревизия драйверов датируется 11 августа 2021 года и у нас проблему не решила. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
gosha-z 2 24 июля Опубликовано 24 июля · Жалоба 9 hours ago, kramolnic said: При высокой загрузке шины контроллер CAN по-прежнему сбоит. А можно увидеть какие-то абсолютные значения для проверки? Или примеры приложения, в котором сбоит, чтобы можно было воспроизвести проблему Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
kramolnic 0 24 июля Опубликовано 24 июля · Жалоба 16 minutes ago, gosha-z said: А можно увидеть какие-то абсолютные значения для проверки? Или примеры приложения, в котором сбоит, чтобы можно было воспроизвести проблему У нас собственный протокол поверх CAN, который использует ext формат кадра на скорости 500кбит/с и требует получения сообщений строго в порядке их отправки и строго без потери кадров. Проблема наблюдается на столе (на шине только rockchip и ixxaat usb адаптер, используем linux-утилиту cangen, запускаем с rockchip отправку ext фреймов с высокой частотой, слушаем шину с помощью ixxaat minimon и периодически принимаем std фреймы при валидных, однако, данных). Та же проблема, когда на шине множество устройств (3-6 штук), обменивающихся по нашему протоколу. Проблема, похоже, не зависит от длины данных и вероятность замены (на глаз) не зависит от скорости передачи. Причем на rockpi3a помогло (кажется...) задрать частоту тактирования до 500МГц с помощью Device Tree Layout Overlay (dtbo/dtso). Та же операция для Orange Pi 5 Plus не помогла. Точнее ничего сказать не могу. P.S. вообще, мы сильно намучились с CAN на разных одноплатниках. Начинали с Raspberry Pi 4 с RaspberryPi OS и SPI-чипом MCP2515 - сначала оказалось, что штатный драйвер из комплекта ОС периодически при приеме переставлял соседние пакеты местами (у MCP2515 два приемных буфера, из-за ошибки в коде драйвера чтение принятых данных иногда выполнялось в некорректном порядке). Далее оказалось, что иногда пакеты теряются из-за, по всей видимости, низкой частоты обработки данных с шины SPI. Проблему удалось решить, обновив ядро ОС до экспериментальной rt (realtime) 6-ой версии с помощью raspberry pi update utility. Я это к тому, что нужно быть очень осторожным, полагаясь на современные одноплатники и дистрибутивы ОС - поддержка производителя слабая, код сырой. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 224 24 июля Опубликовано 24 июля · Жалоба 9 минут назад, kramolnic сказал: Я это к тому, что нужно быть очень осторожным, полагаясь на современные одноплатники и дистрибутивы ОС - поддержка производителя слабая, код сырой. Это всегда было так: Хочешь получить гарантированно работающий код? Решение: Напиши его сам. Во все времена так было, а не только с современными. А ещё есть поговорка: "Дарёному коню в зубы не смотрят". Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
sasamy 1 24 июля Опубликовано 24 июля · Жалоба On 7/24/2024 at 11:32 AM, jcxz said: Это всегда было так: Хочешь получить гарантированно работающий код? Решение: Напиши его сам. без референсного кода это всё равно практически невыполнимо и если там неочевидная ошибка вы её бодро перепишете себе On 7/24/2024 at 11:21 AM, kramolnic said: поддержка производителя слабая, код сырой это учитывали ? Quote Notices：The CAN FD bit filling function of RK3568 is different from the CAN FD standard protocol, and CAN FD is not recommended. https://wiki.t-firefly.com/en/Core-3568J/driver_can.html On 7/24/2024 at 11:21 AM, kramolnic said: на скорости 500кбит/с и требует получения сообщений строго в порядке их отправки и строго без потери кадров для Linux такие гарантии сомнительны, разве что PREEMPT_RT поможет Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
kramolnic 0 24 июля Опубликовано 24 июля (изменено) · Жалоба 15 minutes ago, sasamy said: без референсного кода это всё равно практически невыполнимо и если там неочевидная ошибка вы её бодро перепишете себе это учитывали ? https://wiki.t-firefly.com/en/Core-3568J/driver_can.html для Linux такие гарантии сомнительны, разве что PREEMPT_RT поможет мы не используем режим FD 🙂 MCP2515 действительно завелся только под RT. Но например CAN Marathon или IXXAAT через USB работают нормально. Нам не так критично время доставки (в разумных пределах), как надежность Изменено 24 июля пользователем kramolnic Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
sasamy 1 24 июля Опубликовано 24 июля · Жалоба On 7/24/2024 at 12:50 PM, kramolnic said: MCP2515 действительно завелся только под RT. Но например CAN Marathon или IXXAAT через USB работают нормально. Нам не так критично время доставки (в разумных пределах), как надежность через USB у вас подключено устройство которое буферизует принятые пакеты и отдаёт по запросу от хоста - для этого со стороны линукса не требуется реалтайм Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
kramolnic 0 25 июля Опубликовано 25 июля (изменено) · Жалоба 22 hours ago, sasamy said: через USB у вас подключено устройство которое буферизует принятые пакеты и отдаёт по запросу от хоста - для этого со стороны линукса не требуется реалтайм Навряд ли у Марафона огромный буфер внутри железа, у нас данные иногда килобайтными пачками ходят, но потерь через USB нет, правда, пропускная способность USB выше, чем у нашей CAN шины и у марафона большие программные буферы в драйвере. У того же rockchip can довольно большие аппаратные буферы, их хватает для наших целей при нереалтайм-ядре (потерь вроде нет, только подмена Ext на Std). А вот MCP2515 - таки-да, с ним есть некоторые проблемы без rt ядра. Изменено 25 июля пользователем kramolnic Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Arlleex 165 25 июля Опубликовано 25 июля · Жалоба В 24.07.2024 в 11:32, jcxz сказал: Это всегда было так: Хочешь получить гарантированно работающий код? Решение: Напиши его сам. Во все времена так было, а не только с современными. А ещё есть поговорка: "Дарёному коню в зубы не смотрят". Документация под рокчип не ахти какая. Вернее, ее почти нет. Мы и сами копались, сами писали - но результат один - действительно есть подозрение на баг в железе. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
