Board.KolibriOS.org

Официальный форум KolibriOS
Текущее время: Вс июл 23, 2017 9:45 pm

Часовой пояс: UTC+03:00




Начать новую тему  Ответить на тему  [ 24 сообщения ]  На страницу 1 2 След.
Автор Сообщение
 Заголовок сообщения: User-accessible MMIO
СообщениеДобавлено: Пт дек 25, 2009 3:27 am 
Не в сети
Kernel Developer
Аватара пользователя

Зарегистрирован: Пт авг 14, 2009 1:46 am
Сообщения: 1291
Задача:
Системный сервис Колибри предоставляет пользователю широкий набор функций для работы с оборудованием (доступ к портам ввода-вывода, конфигурационному пространству PCI и даже перехват некоторых векторов прерываний). Предлагаю дополнить этот сервис каналом доступа к "бортовой" памяти устройств (MMIO, Memory-Mapped I/O).

Зачем это надо:
[*] для прямого тестирования железа, без заморочек с драйверами и IOCTL;
[*] для резкого ускорения разработки и значительного упрощения отладки новых драйверов КолибриОС;
[*] при наличии такого канала КОС становится идеальной средой разработки и наладки новой контрольно-измерительной аппаратуры.

Pro et Contra
Доступ к "бортовой" памяти устройств PCI, ATA и USB способен пробить заметную дыру в системной безопасности. К тому же подавляющему большинству пользователей он совершенно не нужен. Поэтому userMMIO-сервис имеет смысл отключить по умолчанию в бинарниках и исходных кодах, и (в отличие от сервиса PCI и i/o ports) включать его только после перекомпиляции ядра с "разрешительным" глобальным параметром.

Вторым ограничением является жесткая привязка сервиса uMMIO только к одному PCI-устройству, явно указываемому в системной переменной debug_pci_device в формате bbbbbbbb dddddfff (bus-device-function). Так можно быть уверенным, что программа, предназначенная для работы с одним устройством, не вломится случайно в адресное пространство другого.

API
Новый сервис предлагаю включить в логически связанный с ним сервис PCI-API в виде подфункий 11 (проверить канал MMIO), 12 (отобразить MMIO-страницу на пользовательский линейный адрес) и 13 (unmap MMIO page) функции 62.

Сразу хочу предупредить: приведенная ниже версия маппинга - очень сырая и дырявая. Прежде чем запрашивать маппинг физических блоков MMIO, юзер должен выделить в статической памяти или в куче своего процесса место для одной полной логической страницы, но ни разу не обращаться по этому адресу с чтением/записью до вызова fn 62:11. Иначе система успеет выделить этой странице реальный блок физической памяти, который будет безвозвратно потерян!

За один вызов маппится ровно одна страница, проверка 4К-выравнивания линейного адреса не производится:


Вложения:
pci32.7z [3.72 КБ]
97 скачиваний

_________________
Узкий специалист подобен флюсу: полнота его - односторонняя.
Козьма Прутков


Последний раз редактировалось art_zh Пн дек 28, 2009 2:01 pm, всего редактировалось 1 раз.
Вернуться к началу
 Заголовок сообщения: Re: User-accessible MMIO
СообщениеДобавлено: Пт дек 25, 2009 6:27 am 
Не в сети
Kernel Developer

Зарегистрирован: Ср мар 08, 2006 6:25 pm
Сообщения: 3927
art_zh

Выдели память user_alloc (68.12), проверь линейный адрес и мапь туда MMIO страницы с флагами PG_SHARED|PG_UW и не забываем про кеширование PG_NOCACHE.

Обратный процесс - вызов user_free (68.13).

Update.

Размер mmio часто больше одной страницы. Таку что лучше мапить страницы commit_pages и освобождать unmap_pages.


Вернуться к началу
 Заголовок сообщения: Re: User-accessible MMIO
СообщениеДобавлено: Пт дек 25, 2009 11:46 am 
Не в сети
Kernel Developer
Аватара пользователя

Зарегистрирован: Пн ноя 28, 2005 8:00 pm
Сообщения: 1601
Serge писал(а):
Выдели память user_alloc (68.12), проверь линейный адрес и мапь туда MMIO страницы с флагами PG_SHARED|PG_UW

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

_________________
Ушёл к умным, знающим и культурным людям.


Вернуться к началу
 Заголовок сообщения: Re: User-accessible MMIO
СообщениеДобавлено: Пт дек 25, 2009 12:02 pm 
Не в сети
Kernel Developer
Аватара пользователя

Зарегистрирован: Пт авг 14, 2009 1:46 am
Сообщения: 1291
Serge
Спасибо, учту. PG_NOCACHE - зевнул, это точно

diamond писал(а):
Serge писал(а):
Выдели память user_alloc (68.12), проверь линейный адрес и мапь туда MMIO страницы с флагами PG_SHARED|PG_UW

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

А чем эти глюки принципиально будут отличаться от обычной незакрытой кучи?
Только тем, что реальные физические страницы не потеряются, а останутся на своем месте, по тем же BIOS-адресам.

_________________
Узкий специалист подобен флюсу: полнота его - односторонняя.
Козьма Прутков


Вернуться к началу
 Заголовок сообщения: Re: User-accessible MMIO
СообщениеДобавлено: Пт дек 25, 2009 12:12 pm 
Не в сети
Kernel Developer
Аватара пользователя

Зарегистрирован: Пн ноя 28, 2005 8:00 pm
Сообщения: 1601
art_zh писал(а):
А чем эти глюки принципиально будут отличаться от обычной незакрытой кучи?

Код:
proc free_page
;arg:  eax  page address
           pushfd
           cli
           shr eax, 12                        ;page index
           bts dword [sys_pgmap], eax         ;that's all!

Вопрос на засыпку: что будет, если free_page (начало кода которой приведено выше) попытается освободить страницу, находящуюся за пределами физической памяти (на которую рассчитан битовый массив sys_pgmap)?

_________________
Ушёл к умным, знающим и культурным людям.


Вернуться к началу
 Заголовок сообщения: Re: User-accessible MMIO
СообщениеДобавлено: Пт дек 25, 2009 2:17 pm 
Не в сети
Kernel Developer
Аватара пользователя

Зарегистрирован: Пт авг 14, 2009 1:46 am
Сообщения: 1291
diamond писал(а):
Вопрос на засыпку: что будет, если free_page (начало кода которой приведено выше) попытается освободить страницу, находящуюся за пределами физической памяти (на которую рассчитан битовый массив sys_pgmap)?

В данном конкретном случае - ничего страшного не случится. Поскольку физические адреса MMIO находятся в самой верхней зоне адресного пространства, просто будет поставлен бит где-то в самом конце таблицы sys_pgmap, куда менеджер памяти никогда не заглядывает.
Неплохо было бы при инициализации забить всю верхнюю зону этой таблицы единицами, тогда и на счетчике свободных страниц это никак не отразится
Код:
; ( proc free_page)
.....
           bts dword [sys_pgmap], eax         ;that's all!
           cmc
           adc [pg_data.pages_free], 0

далее идет
cmp [page_start], eax
и сразу же - на выход, без каких-бы то ни было катастрофических последствий.

_________________
Узкий специалист подобен флюсу: полнота его - односторонняя.
Козьма Прутков


Вернуться к началу
 Заголовок сообщения: Re: User-accessible MMIO
СообщениеДобавлено: Пт дек 25, 2009 2:49 pm 
Не в сети
Kernel Developer
Аватара пользователя

Зарегистрирован: Пн ноя 28, 2005 8:00 pm
Сообщения: 1601
art_zh писал(а):
В данном конкретном случае - ничего страшного не случится. Поскольку физические адреса MMIO находятся в самой верхней зоне адресного пространства, просто будет поставлен бит где-то в самом конце таблицы sys_pgmap

Ответ неверный. Рекомендую подумать ещё раз, учитывая (уже приведённый) факт, что массив sys_pgmap рассчитан на покрытие физической памяти.

_________________
Ушёл к умным, знающим и культурным людям.


Вернуться к началу
 Заголовок сообщения: Re: User-accessible MMIO
СообщениеДобавлено: Пт дек 25, 2009 4:42 pm 
Не в сети
Kernel Developer

Зарегистрирован: Ср мар 08, 2006 6:25 pm
Сообщения: 3927
diamond

user_free расшареные страницы не трогает. В остальных случаях terminate вызывает destroy_app_space, та destroy_page_table
Код:
proc destroy_page_table stdcall, pg_tab:dword

       push esi

       mov esi, [pg_tab]
       mov ecx, 1024
.free:
       mov eax, [esi]
       test eax, 1
       jz .next
           test eax, 1 shl 9
           jnz .next                      ;skip shared pages
       call free_page
.next:
       add esi, 4
       dec ecx
       jnz .free
       pop esi
       ret
endp

Или есть другой способ "разобрать" адресное пространство ?


Вернуться к началу
 Заголовок сообщения: Re: User-accessible MMIO
СообщениеДобавлено: Пт дек 25, 2009 5:03 pm 
Не в сети
Kernel Developer
Аватара пользователя

Зарегистрирован: Пн ноя 28, 2005 8:00 pm
Сообщения: 1601
Пардон, не заметил флага PG_SHARED. Тогда вопрос снимается.


Вернуться к началу
 Заголовок сообщения: Re: User-accessible MMIO
СообщениеДобавлено: Пт дек 25, 2009 5:33 pm 
Не в сети

Зарегистрирован: Вс ноя 04, 2007 2:46 am
Сообщения: 390
Я написал план, пофиг на ваше мнение, выполняйте. (c) главнокомандующий
diamond, заметь, я такого не говорил и не писал (ни тут, ни в вике).
А то, что я написал в вике - обобщения с форума.


Вернуться к началу
 Заголовок сообщения: Re: User-accessible MMIO
СообщениеДобавлено: Пн дек 28, 2009 1:15 pm 
Не в сети
Kernel Developer
Аватара пользователя

Зарегистрирован: Пт авг 14, 2009 1:46 am
Сообщения: 1291
Serge писал(а):
art_zh

Выдели память user_alloc (68.12), проверь линейный адрес и мапь туда MMIO страницы с флагами PG_SHARED|PG_UW и не забываем про кеширование PG_NOCACHE.

Обратный процесс - вызов user_free (68.13).

Update.

Размер mmio часто больше одной страницы. Таку что лучше мапить страницы commit_pages и освобождать unmap_pages.


Все так и сделал
Вложение:
pci32.7z [3.72 КБ]
92 скачивания

Система грузится нормально :roll: вплоть до установки видеорежима.... Потом вышибает на перезагрузку.

Отключил АТI- драйвер - все загрузилось без проблем.
Похоже, ATIKMS где-то перехватывает сервис PCI?

_________________
Узкий специалист подобен флюсу: полнота его - односторонняя.
Козьма Прутков


Вернуться к началу
 Заголовок сообщения: Re: User-accessible MMIO
СообщениеДобавлено: Пн дек 28, 2009 6:22 pm 
Не в сети
Kernel Developer

Зарегистрирован: Ср мар 08, 2006 6:25 pm
Сообщения: 3927
art_zh

Не перехватывает, но активно юзает.
pci_api
pci_read8
pci_read16
pci_read32
pci_write8
pci_write16
pci_write32

А до изменений нормально грузилось ?


Вернуться к началу
 Заголовок сообщения: Re: User-accessible MMIO
СообщениеДобавлено: Ср дек 30, 2009 3:28 pm 
Не в сети
Kernel Developer
Аватара пользователя

Зарегистрирован: Пт авг 14, 2009 1:46 am
Сообщения: 1291
Serge
Оказалось, что я зацепил pci_write копипастом, fixed.
Еще там была пара багов с перераскладкой регистров при системном вызове, разобрался с помощью diamond'а.
Сейчас вроде все нормально; для тестирования слегка переделал утилиту pcidev.asm, теперь она видит выделенные юзеру каналы MMIO, распознает и маппит RAM-блоки, после чего пробует прочитать первую страницу из бортовой памяти.

После 1 января выложу файлы здесь.
На svn залью когда дадут аккаунт.

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

_________________
Узкий специалист подобен флюсу: полнота его - односторонняя.
Козьма Прутков


Вернуться к началу
 Заголовок сообщения: Re: User-accessible MMIO
СообщениеДобавлено: Ср дек 30, 2009 7:33 pm 
Не в сети
Kernel Developer
Аватара пользователя

Зарегистрирован: Пн мар 20, 2006 10:44 am
Сообщения: 557
Вначале нужно добавить поддержку PCI потом думать о том как его в user mode тянуть. Сейчас PCI это костыль таких размеров что многие думают что PCI есть, но на самом деле, его нет...


Вернуться к началу
 Заголовок сообщения: Re: User-accessible MMIO
СообщениеДобавлено: Чт дек 31, 2009 1:50 pm 
Не в сети
Kernel Developer
Аватара пользователя

Зарегистрирован: Пт авг 14, 2009 1:46 am
Сообщения: 1291
Вложение:
Комментарий к файлу: новый PCI API и утилита PciDev.asm
pci32.7z [9.05 КБ]
91 скачивание


Самая важная - функция 62:12.
Она не только маппит блок необходимой длины на юзерспейс, но еще и избавляет от нудных манипуляций с BAR-регистрами и физическими адресами. Единственное, что надо держать в памяти: длина блока задается в байтах, а смещение в физической памяти - в целых страницах (1стр = 4к байт).
Это так и задумано, иначе у юзера будет соблазн выставить не выравненный по началу страницы оффсет, что обязательно приведет либо к потере данных при маппинге, либо к сдвигу реальных линейных адресов относительно запрашиваемых приложением.

_________________
Узкий специалист подобен флюсу: полнота его - односторонняя.
Козьма Прутков


Последний раз редактировалось art_zh Сб янв 02, 2010 3:18 pm, всего редактировалось 1 раз.

Вернуться к началу
Показать сообщения за:  Поле сортировки  
Начать новую тему  Ответить на тему  [ 24 сообщения ]  На страницу 1 2 След.

Часовой пояс: UTC+03:00


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 2 гостя


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
Создано на основе phpBB® Forum Software © phpBB Limited
Русская поддержка phpBB