Здравствуйте. Имеется устройство с установленным на нём uLinux. Устройство имеет кучу периферии, документация на конфигурирование которой весьма запутанная. Имеется также демо программа в бинарных кодах под uLinux, которая конфигурирует устройство требуемым образом. Все регистры отображены в память (адреса известны). Есть идея запустить эту программу, затем посмотреть содержимое этих регистров с помощью своей утилиты. Подскажите, как её сделать. Насколько я знаю, в линуксе, как и в винде программа работает в виртуальном адресном пространстве. Читал про mmap, но практике всё туго. Если можно, подскажите.

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

Спасибо. То есть если у меня регистр ADC_DATA находится, к примеру, по адресу 0x2400, то его можно прочесть по указателю на 0x2400. Разумеется, с приведением типов. Я вас правильно понял?

Не уверен что можно, но я с uclinux не работал, так что ничего сказать по этому поводу не могу. Но сам факт того, что пользовательское приложение работает с регистрами напрямую, ставит под большой вопрос целесообразность использования uclinux, так что я все-таки думаю что общение с периферией реализовано с использованием интерфейсов операционной системы.

Здравствуйте. Пакета ltrace там нет. Попробую собрать. Да. При обращении к регистрам пишет сегменташион фаулт. Надо будет матчасть подучить. Посоветуйте учебник по ucLinux.

Как такового учебника по ucLinux'у нету, но есть неплохая глава совсем для начинающих в книге "Embedded Linux system design and development". Перевод можно найти по этой ссылке .

регистры доступны из пространства ядра. В теории содержимое регистров может смотреть модуль ядра и передавать в пространство пользователя.

Ваша программа работает в режиме User, а для доступа к регистрам периферии нужен режим Supervisor (речь об аппаратных режимах процессора). Когда вы пытаетесь обратиться по адресу к регистру периферии, возникает аппаратное исключение, обработчик которого (из ядра) и сообщает вам сею весть.

Вам правильно сказали: нельзя просто так из приложения лазить к регистрам напрямую - это прямое нарушение концепции безопасности ОС. Для работы с периферийными устройствами используются драйвера оных устройств. Найдите (или напишите) драйвер для своего устройства.

Неправилно сказали
Программный код пользовательского режима вполне может (с существенными ограничениями) обращаться к регистрам внешних устройств. См. прямо в системе man по:
ioperm(2), iopl(2), inb(2), outb(2), capabilities(7) и т.д. (процессор i386 только).
Кроме того, Linux предоставляет даже специальное символьное устройство /dev/port для прямых чтения и записи в порты внешних устройств (с правами root, естественно).

Более того, во многих случаях в Linux всячески поощряется организация ввода/вывода именно из пространства пользователя, без написания модулей ядра (драйверов). Для того делаются специальные и достаточно сложные инструменты промежуточного слоя. Самые известные тому примеры: проект libusb и файловая система FUSE, на которых в последние годы реализуется стандартная поддержка тысяч разнообразных устройств от их производителей.

P.S. Детали и примеры использования всего этого хозяйства можете посмотреть здесь: Практикум по Linux Kernel.

Ссылка криво вставилась, поправьте если не сложно.

Спасибо, поправил.
Пробуйте.

Не означает ли это, что пользовательское приложение (запущенное от root) может завалить систему? Ну, если есть прямой доступ к железу.

Нет, не означает.
Потому что приложение, запущенное с root-привилегиями уже не является "пользовательским" - не нужно давать ординарным пользователям таких привилегий.
А не означает ли то, что тот же пользователь простым нажатием RESET ("если есть прямой доступ к железу" ) может достичь того же результата?

А вот элементарнейший код, уровня "Hello world", модуля ядра при малейшей ошибке его криворукого написания обязательно завалит систему.
А вообще, завалить систему Linux (и любую другую!), имея права root, есть 1000000 и ещё 1 способов, куда эстетичнее, чем тупо писать по портам. На то они и права root.

P.S. То, что пользователь может воткнуть 2 пальца в электророзетку, ещё вовсе не повод к пацифистским призывам отказаться от пользования электричеством вообще.

Reset, обесточивание, удар кувалдой и т.п. - это всё понятные способы "завалить систему" с разной степенью фатальности. Речь не о них, а о непреднамеренных действиях, выполняемых по неосторожности/незнанию.

Хорошо, по-другому спрошу. Вот некто написал приложение, которае лазит напрямую к железу. Этот некто не имеет рутовых прав, он юзер, и его приложение - сугубо юзерное, не предназначенное для запуска от рута. Вопросы:

• сможет ли такое приложение получить доступ к аппаратным регистрам?
• сможет ли такое приложение завалить систему?

Я понял - вам просто не с кем поговорить...


1. не сможет
2. не сможет
Но! ... при таких условиях приложение никогда не сможет получить доступа к аппаратным ресурсам. Никаким способом - точно так же, как такой пользователь не сможет загрузить и модуль ядра, чего бы там супер-пупер гениального он не написал.
Без root-прав - сиди в пользовательской песочнице.

А если у файла установлен атрибут setuid?

А если у файла установлен атрибут setuid, то установлен он не от Духа Святого , а вы его сами установили, и, хотелось бы думать, что зная зачем это делаете.
Ну и т.д. ... про setuid в этом качестве множество написано, и про нежелательность его использования вообще ... и все дальнейшие обсуждения в этом направлении будут уже просто бла-бла-бла...


Чтоб ... не растекаться умом по древу, не разводить словопрения - подведём как итог: то, что ТС-ра интересует и что он спрашивает, сводится к следующему:
- как можно читать/писать в Linux по портам и наблюдать обменные операции?
- обязательно ли для этого писать модуль ядра Linux, чтобы доступ к портам осуществлять в супервизорном режиме процессора (кольцо защиты 0)?

Ответы можно сгрупировать так:
- кроме обменных операций из ядра (модуля) их можно выполнять и из пространства пользователя...
- операциями типа inb(), outb() ...
- и это именно не машинные привилегированные команды, как в ядре, а системные вызовы Linux...
- в чём можно убедиться (обращаем внимание на 2):

- ... и которые контролируются ядром Linux с той же степенью безопасности, как и все другие системные вызовы.
- кроме того, специально предоставляется ещё и специальное символьное устройство /dev/port для доступа к портам.

А итог:
- во многих (достаточно многих) случаях, когда нужно обслуживание внешнего устройства (ввод-вывод)...
- если есть возможность это написать без написания модулей ядра, в пространстве пользователя - то именно это и есть предпочтительное решение
- и многие крупные девелоперские проекты Linux последнего времени были направлены именно на создание и предоставление таких инструментариев: libusb, файловая система FUSE ... да и udev, netlink и sysfs.
- и тысячи образцов разнообразных проприетарных устройстм и гаджетов последних лет от производителей обеспечиваются поддержкой именно в таких техниках - это есть тенденция последнего времени.

P.S. Если кто интересовался архитектурой микроядерных ОС, то он вспомнит, что в них обеспечивается устойчивость и жизнеспособность на порядки выше, чем во всех Linux и Windows вместе взятые , именно за счёт того, что драйверы там вынесены из супервизорного режима (ядра), выполняются либо в пользовательском пространстве, либо в промежуточных кольцах защиты (1 или 2) процессора.

Именно: segmentation fault в пространстве пользователя приведет к краху апликации, а в ядре к краху системы. Однако я хотел бы указать на реальную опасность бездумного использования доступа ко внутренней памяти устройств. В embedded устройстве, записав неправильное значение в регистры PMIC (Power Management Integrated circuit), можно сжечь ваше устройство. Иногда даже чтение может привести к тяжелым сбоям. Некоторые устройства сбрасывают флаги событий автоматически при чтении статуса. Какие-то события не дойдут до назначения. Мой совет если надо писать в регистры -- семь раз подумай. Наличие простого способа доступа к памяти (устройствам) позволяет тем, кто не осилит написать и установить драйвер убить систему.

ТС навряд ли использует i386. Скорее всего ARM. В обычном Линуксе для доступа к регистрам я делаю следующим образом. Сначала смотрю по каким адресам зарегистрированы регистры в псевдо файле: /proc/iomem.
Все последуящие операции производятся пользователем root.
Потом, используя map для устройства /dev/mem, получаю доступ к области памяти. Насколько я понимаю вопрос: Если область памяти не зарегистрирована в ядре (что мы и видим в /proc/iomem), то до памяти не достучишься. Как обстоит дело с вашей системой я не знаю. Дело в том, что операция map производится для того, чтобы получить виртуальный адрес, соответствующий искомому физическому. ucLinux не нуждается в такой операции ибо у него нет виртуальной памяти.
Попробуйте напрямую писать и читать в область памяти из /proc/iomem, соответствующую вашему устройству.
Я сейчас пишу в свободное время утилитку для подобного доступа к регистрам. Будет готова -- дам ссылку.

Интересно бы

С работы еле живой выползаю. Кучу контракторов сократили -- на нас много неожиданных обязанностей навалили. Сейчас изучаем матчасть.
Вылизывать апликацию нет сил. Напишу предупреждение, что если не знаешь что читать и писать, то можешь подвесить или спалить компьютер, чтоб не лезли куда не надо и выложу. В принципе если утилитой dd неправильно пользоваться, то систему легко можно убить -- так что полагаю моя утилитка имеет право на жизнь. Поставлю в опен сорс -- если кому понадобиться улучшить -- пожалуйста.
Ведь от нее есть и польза если не злоупотреблять.
Например надо подобрать значения регистров в таймере, чтобы настроить PWM -- из апликации попробовал и сразу увидел результат.

Выложил:
https://github.com/stepanovr/linuxreg

Поскольку делал для Raspberry PI, то на 32 бита получилось. 64 бита криво выглядят -- надо будет найти время.
Вам, olej, она навряд ли подойдет. Ведь вы в основном на 386 архитектуре, а она сегодня 64 бита.

Знаю, что много криво сделано, но это мой первый опыт на ncurses. Тем более я больше драйверами и реалтаймом занимаюсь, а здесь понадобился интерфейс пользователя какой-никакой.

Посмотреть все детали доступа к регистрам можно в фаиле app/rdmem.c

Есть программка devregs: https://community.nxp.com/docs/DOC-97543
https://github.com/boundarydevices/imx-util...ter/devregs.cpp

посматрите примерны на "малинке" ( я тоже такие писал ), они как раз на прямую работают с переферийными регистрами - да, nmap или подобное - оно делает копию адресного пространства и вы с ним работает ( но, только от root ). - этого обычно вполне достаточно ..

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

Как раз для малинки и делал В документе даны неверные адреса GPIO. Потерял время на бодание. Моя апликация находит правильные адреса и показывает их.
Попробуйте на малнке.
Да и не всегда есть время писать.



Ну да. Совершенно аналогично. Как я ранее и описал метод доступа. Правда ограничено для использования только на Frescale imx6X и imx53. И наверное только какой-то специальный Линукс. Я не очень внимателен, но не встречал такого файла (псевдо файла) /etc/devregs.dat. Думаю, что это какой-то специальный случай.



Пользуясь случаем хочу выразить вам благодарность от читателя. Во многих документах по open source описание понятно только тем кто "посвящен". Вот например библия по драйверам Линукс. Три автора Corbet, Rubini и Kroah-Hartman.
Будучи уже не худшим разработчиком встроеных апликаций реального времени я долго не мог охватить всего описанниго. Упускаются какие-то "и так понятные любому" мелочи.
Ваши книги понятны и новичкам. При том что все понятно изложен материал о совсем непростых вещах.

Правда неплохо детали установки, компиляции и разных свойств ядра описаны в Linux Kernel in a Nutshell автор (тот же из драйверов) Greg Kroah-Hartman. Но она не о драйверах и модулях. Но это скорее исключение.
Кстати мне очень понравился ваш (я больше нигде его не встречал) прием с установкой модуля, который всегда возврашает ошибку. При этом можно распечатать значения любых переменых из ядра.

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

Я предлагаю администрации форума (модератору) сделать прикрепленную тему, где olej выложит ссылки на свежие версии своих книг. Если он конечно не против.

Легко портируется на другой ARM. Например, мы её используем и для ls1020.
Линукс обычный.
У многих программ есть конфигурационные файлы. /etc/devregs.dat -- это конфигурационный файл программы devregs. Но она может работать и без него. Просто devregs.dat удобен для описания регистров, чтобы можно было использовать не "голые" адреса, а символические имена, и даже отдельные поля.

Я подумал, что /etc/devregs.dat это псевдо файл, хотя мог бы и сообразить по месту положения, что конфигурационный. Торможу. Псевдо файлы в /proc и /sys.
А кто заполняет или откуда брать такой конфигурационный файл для, скажем, Sitara процессора?
Попробуйте мою апликацию. Она не лезет в произвольные места, а только в регистрированные. Ну и их имена дает в меню. Хоть и примитивный, но оконный интерфейс. Позволяет легко понять, что делать. Можно листать читаемую память.
За критические отзывы буду признателен.
Там еще не отлажен механизм восстановления после изменения размера окна терминала в процессе работы. Плюс к другим недостаткам.

Не знаю, нужно ли отдельную тему, а всё, что меня интересовало в последние 2-3 года (или больше) описано и свободно доступно здесь: Linux для программиста.
Пользуйтесь на здоровье.

Спасибо. Запишу ссылку. Сейчас собираю литературу по сетевым драйверам. Лучшее что нашел документ Linux Kernel Networking by Rami Rosen. Посмотрю если у вас есть что-нибудь по сетевым драйверам.

тама смещенные адреса - тоже пободался чутка, было дело ..

факт лишь тот - что прямой доступ только по руту или драйвер ...

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

Смещенные гигабайт . Я бодался пока не нашел какую-то апликацию в сети и в ней увидел, что вместо
7f200000-7f2000b3 адреса 3f200000-3f2000b3. Меня это разозлило и я написал апликацию, которая сама видит где правильные адреса.

Мне то что по руту не мешает. Я для поиска правильной конфигурации регистров писал апликацию, которую и с рутом можно запустить. Мне в тот момент надо было измерить джиттер кернелного таймера. Просто было любопытно если драйвер телефонного таймера без железа, а чисто на софте -- сильно будет гулять интервал. Дело в том, что для VOIP телефонов подклученых к Asterisk можно потерять синхронизацию в conference call (не знаю как по-русски -- уехал из республики развалившегосю СССР когда такого еще не было). Для этого последним в конфигурации ставят телефон на железе, а не программный или если нет такого -- то таймер. Самое смешное, что все сделал -- увидел осциллографом сигнал. Сделал логгер и осталось сделать резисторный делитель, чтобы согласовать выход 3.3V GPIO со входом логгера 250 милливольт аудио. Уже несколько месяцев некогда.

Насколько по основе данный сервис схож с devmem2 + mem2io.c?

http://sg.danny.cz/foxg20/ag25g20_utils-0.96r10/

http://www.makelinux.net/books/embedded_li...drivers/text152

Не очень понимаю о чем вы. Никакого сервиса нет. Я просто апликацию написал, которая находит по каким адресам находится периферия и мапирует адреса для получения доступа к ним. Как я описывал ранее.
Если ядро скомпилировано с защитой от доступа,то никакая апликация не сможет увидеть. Нужно писать драйвер, что позволит влегкую подвесить ядро вводом неверных параметров.

Да, хорошая аппликация. Вопрос, собственно был о разнице или, наоборот, схожести методов получения доступа к регистрам, который применили вы и который используется в devmem2.

Спасибо не добром слове. Думаю, что не так много способов есть доступа. Открывается файл и затем маппируется. Все функции в этом файле кроме самой первой это делают. Весь трюк доступа здесь и есть -- остальное оформление и удобства:
https://github.com/stepanovr/linuxreg/blob/...ter/app/rdmem.c