LINUX.ORG.RU

Глючит драйвер uart на imx6ull

 , ,


0

2

День добрый.

Есть устройство собранное на базе imx6ull, ядро linux-imx_4.9.88_2.0.0_ga. Был замечен баг в работе драйвера uart-ов (imx) - периодически перестают прилетать ответы. смотрел с помощью strace - write есть , poll-а нет и соответственно read тоже нет замечено что проблема часто проявляется на устройствах с интенсивным опросом (например по modbus). данные перестают прилетать по всем портам, если сделать некоторым портам close и open то нормальная работа восстанавливается по всем портам. пробовал закинуть драйвер от linux-imx_4.14.98_2.0.0_ga (файл drivers/tty/serial/imx.c) - заметных изменен в работе нет, проблема осталась.

устройство доступно по ssh . подскажите, пожалуйста, что можно посмотреть для поиска причины проблемы ? может какие регистры uart-ов стоит посмотреть ( с помощью devmem2 ) ?

в текущем ядре для imx (imx_5.4) в драйвере drivers/tty/serial/imx.c есть много исправлений для SMP систем, но ядро у меня собрано без SMP. тащить новое ядор 5.4 на устройства точно не буду, драйвер от 4.14.98 не помог, драйвер от 5.4 в 4.9 боязно, вдруг какие еще глюки вылезут.

посоветуйте, как можно вылечить эту проблему , в идеале починить работу драйвера


Ответ на: комментарий от gtk3

время когда происходит глюк известно, в dmesg ничего.

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

psm666
() автор топика

данные перестают прилетать по всем портам, если сделать некоторым портам close и open то нормальная работа восстанавливается по всем портам

ну это явно с SDMA проблема - меняйте фирмварь от более свежей версии BSP/ядра. Посмотрите выхлоп

[code] dmesg | grep dma [/code]

там версия фирмвари sdma будет написана

anonymous
()

Было что то аналогичное, но на предыдущем ИМИКсе (не 6-м). Там типо постоянно ошибки переполнения фифо появлялись. Типа драйвер не успевал обрабатывать входной поток данных, особо не разбирались, заменили на ФТДИ по УСБ и пришло счастье. ))

В общем, посмотри статистику оверранов, оверфловов и прочего из консольки (точно счас не вспомню как). Чтоб понять примерно в чем дело.

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

Можно попробовать увеличить буфер фифо в драйвере (не скажу где, но надо патчить).

В общем, причин может быть дофига.

kuzulis ★★
()
Последнее исправление: kuzulis (всего исправлений: 1)
Ответ на: комментарий от anonymous

фирмварь sdma по все видимости последняя:

[ 0.279910] imx-sdma 20ec000.sdma: using built-in imx/sdma/sdma-imx6q.bin
[ 0.280026] imx-sdma 20ec000.sdma: loaded firmware 3.3

psm666
() автор топика
Ответ на: комментарий от psm666

[ 0.280026] imx-sdma 20ec000.sdma: loaded firmware 3.3

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

anonymous
()

проблема часто проявляется на устройствах с интенсивным опросом (например по modbus)

это наверно коротенькие сообщения ? попробуй отключить DMA на нужных портах

https://community.nxp.com/t5/i-MX-Processors/i-mx6ull-uart-dma-issue/td-p/119...

там написано как дописать для своей платы а тебе надо закоментировать аналогичные строки в imx6ull.dtsi или как-то в своем DTS дропнуть эти параметры - навскидку не знаю как это сделать

anonymous
()
Ответ на: комментарий от anonymous

Нашел как дропнуть в своём DTS параметры

https://elinux.org/Device_Tree_Source_Undocumented#Deleting_nodes_and_properties

arch/arm/boot/dts/imx6ull-myboard.dts

&uart3 {
	pinctrl-names = "default";
	pinctrl-0 = <&pinctrl_uart3>;
	/delete-property/ dmas;
	/delete-property/ dma-names;
	status = "okay";
};

в ядре 4.9.xx DMA на уартах включен по умолчанию в imx6ull.dtsi

https://source.codeaurora.org/external/imx/linux-imx/tree/arch/arm/boot/dts/i...

в 5.4.xx отключен по умолчанию

https://source.codeaurora.org/external/imx/linux-imx/tree/arch/arm/boot/dts/i...

Впринципе можно смело отключать DMA - у imx6ull на уартах хорошая аппаратная буферизация FIFO

Two independent, 32-entry FIFOs for transmit and receive

DMA проявляется только на длинных пакетах больше 32 байта - будет меньше прерываний от уарта

anonymous
()

полечил проблемы с уартом на imx6ull заменой этого куска говен на stm32mp153. Доволен как слон.

anonymous
()
Ответ на: комментарий от anonymous

полечил проблемы с уартом на imx6ull заменой этого куска говен на stm32mp153

и венду переустановил. У чувака не получилось решить задачу и он еще этим гордится :)

anonymous
()
Ответ на: комментарий от anonymous

и венду переустановил. У чувака не получилось решить задачу и он еще этим гордится :)

Вот тебе задача: сделай из говна пулю.

А моя жизнь слишком коротка для того что б ковыряться в жидкой субстанции.

Если немного погуглить то бфстро выясниться что проблемы с уартом у этого imx тянуться уже лет 10 прям с начала производства. и всеравно периодически всплывают.

anonymous
()
Ответ на: комментарий от anonymous

как описал топикстартер

он вообще ничего не описал, подозреваю он даже не догадывался что у порта может быть DMA кроме FIFO и это можно и нужно конфигурировать. У i.MX недостаточно документации по SDMA

http://billauer.co.il/blog/2011/10/imx-sdma-howto-memory-map/

anonymous
()
Ответ на: комментарий от anonymous

Обновление до firmware 3.5 не помогло. вместо тишины из порта увидел «залипшее» , непрерывно получаемое, значение из одного из портов (/dev/ttymxc2):

read(34, «UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU»…, 256) = 256

read(34, «UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU»…, 256) = 256

read(34, «UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU»…, 256) = 256

Если сделать close этому порту то нормальная работа восстанавливается.

буду пробовать отключать DMA.

psm666
() автор топика
Ответ на: комментарий от psm666

rs485

как вы управляете переключением приём/передача на трансивере ? использую релиз 4.9.11 (предыдущий перед 4.9.88) пришлось бэкпортировать патчи из майнстримного ядра иначе там какая-то ерунда была на управляющем выводе - сигнал инвертированный. Сравнил с 4.9.88 там ничего не исправлено. Осцилом не проверяли как себя ведёт RTS ?

anonymous
()
Ответ на: комментарий от anonymous

По всей видимости отключение DMA решило проблемку. но наверняка будет известно недели через 2 - 3 если не проявится.

по поводу управления 485 :

/sbin/rs485conf -e1 -o1 -a0 -r0 /dev/ttymxc1

сборку ядра rootfs для устройства делал не я, в драйверах видел что в новых версиях инвертировали логику rts, вопрос с неправильно работой rts решили тем что направление передачи повесили не на RTS а на CTS

psm666
() автор топика
Ответ на: комментарий от psm666

в новых версиях инвертировали логику rts, вопрос с неправильно работой rts решили тем что направление передачи повесили не на RTS а на CTS

если порт в режиме DCE (это по умолчанию) то управление через CTS

https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/i-MX6-What-does-t...

на большинстве уартов управление через RTS. Мы использовали GPIO для управления полудуплексным приемомпередатчиком, так намного удобней - переключить любой свободный пин на GPIO и указать его в качестве управляющего в DTS, но оказалось что в 4.9 управляющий GPIO дёргался с инверсией, бэкпорт из более свежего ядра решил проблему.

spbob
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.