Net: FEC
Normal Boot
Hit any key to stop autoboot: 0
u-boot > ext2load mmc 0:1 0x12000000 /boot/zImage.imx6dl-oem
MMC: no card present
** Bad device mmc 0 **
u-boot > ext2load mmc 1:1 0x12000000 /boot/zImage.imx6dl-oem
13189985 bytes read in 748 ms (16.8 MiB/s)
u-boot > bootz 0x12000000
Kernel image @ 0x12000000 [ 0x000000 - 0xc8b2b0 ]
Результат тот же:
echo 111 > /dev/spidev0.0 сбрасывает выход 5.19 в низкий уровень, когда к нему подключен резистор на 2 кОм, после того, как он был выставлен новым ./ugpio.
Правда есть два момента. 1. spidev ругается при загрузке
spidev spi0.0: buggy DT: spidev listed directly in DT
------------[ cut here ]------------
WARNING: CPU: 0 PID: 1 at drivers/spi/spidev.c:731 spidev_probe+0x1a4/0x1c0()
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.1.15 #5
Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
[<8001667c>] (unwind_backtrace) from [<8001266c>] (show_stack+0x10/0x14)
[<8001266c>] (show_stack) from [<807079e4>] (dump_stack+0x74/0xb4)
и т.д.
Могу сказать, в моих сборках для этого ядра тоже самое. У себя используем другое ядро, там все нормально, потому заметил только сегодня. Само устройство при этом создается и работает.
2. ugpio на initramfs и в архиве имеют разные размеры, свежий на initrams.
В принципе, теоретически, имеется возможность предоставить удаленный доступ к плате(скажем, через ssh), если у Вас есть время и желание посмотреть все самолично. Ценного на плате нет ничего, менять можно будет что угодно. Разве что вместо мультиметра мониторить состояние выходов по регистрам придется, ну или через skype состояние у меня запрашивать. Но это будет возможно только в понедельник.
Здравствуйте!
Мы додумались таки протестировать Вашу конфигурацию. Подтверждаю, что если выход подключать через резистор 2 кОм и светодиод, то все работает.
Прошу протестировать нашу конфигурацию, где никакого светодиода нет. Выход через резистор 2 кОм на землю. Контролировать вольтметром. Впрочем и с резистором на 5,8 кОм у меня не работает также.
У нас выходы работают на ключ ULN2003D, вернее не работают.
Проверил с одним резистором 2 кОм - всё как описывали - сбрасывается выход в 0
(или на вход встает - не могу сказать). Через sysfs работает как положено. Вывод тут один - что-то некорректно в коде работы через mmap. Если честно - для меня это тоже сюрприз, в своем примере я взял реализацию работы с gpio из убута.
Решение о переработке ПО уже есть. Оно работает на разных контроллерах и изначально была работа через mmap. Проблем до сих пор не было. Плохо то, что теперь на разных платформах будет разные решения. Но это не смертельно. Есть еще два момента:
1. Непонятно, что происходит и почему нагрузка так влияет, система так поступает только с выходами с такой нагрузкой. Непонятно, чего и где ждать. У нас очень плотная работа с периферией: входы, выходы, микросхемы uart на spi, АЦП, LVDS, датчики и внешние платы на I2C. Поэтому внезависимости ни от чего "в фоне" будем пробовать разобраться.
2. Через sysfs все работает, хотелось бы разобраться - почему. При этом система пин явно использует как выход, она про него "знает". Но, когда в dts выход определяется как выход, он также появляется в системе, но не работает. Для sysfs он становится недоступным. Более того, у меня получилось определить в dts этот выход с активным высоким уровнем. Так вот, когда с помощью mmap я его сбросил в 0, затем выполнил обращение к SPI - выход выставился в 1(ну или вернулся в исходное состояние, не знаю).
на вход не встает, gdir не меняется, dr переписывается
одновременный досуп к регистру из разных мест без блокировки в принципе не может работать без проблем - изменение регистра не атомарное. Берем ваш тест
int mask=PIO5_Reg->GDIR;
mask |= 1<<19 | 1<<20;
PIO5_Reg->GDIR = mask;
типичное чтение-модификация-запись. Теперь представьте - ядро в промежутке между чтением и записью в вашем коде записало какое-то новое значение в этот регистр - например изменило бит 5 (планировщик например прервал вашу задачу в юзерспейс или прерывание сработало или система многоядерная и код параллельно выполняется), ваша запись вернет этот бит в прежнее состояние.
Соглашусь с Вами, что-то не задумывался об этом ранее. Но, тем не менее, до сих пор работало. Переделки кода ПО связаны с отработкой этого кода, у нас не всегда есть все железо, чтобы его отработать. Вернее, такого никогда не бывает, чтобы все было. Будем поправлять постепенно... Спасибо!
Тогда давайте подведем итог.
Если не смотреть на то, что система по разному реагирует на нагрузку, то происходит следующее.
Система использует выход 5.17 CS ECSPI0 как gpio.
При обращении к spi система переписывает регистр DR целиком без учета наших действий по mmap, чем сбрасывает состояние нашего выхода. Она не пытается считать регистр и, выставив свой бит, записать обратно, а записывает какое-то свое состояние по своему разумению.
Работа с gpio через mmap, помимо прочего, может приводить к коллизиям, что подтверждается и вышесказанным, потому очень не рекомендуется.
Думаю, тему можно закрыть как решенную. Еще бы переименовать ее на что-то типа "Проблемы при работе под Linux с gpio через mmap", что более точно отражает содержание.
Спасибо!
10.11.2017 12:47 
10.11.2017 12:48
