В данном случае при компиляции ядра был установлен адрес моей видеокарты
mmpi_pci_addr = 0х100 ; (b1.d0:f0)
Важно: все svn-сорцы и бинарники должны идти с предустановленным mmpi_pci_addr = -1,
для блокировки пользовательского доступа ко всем MMIO-ресурсам
User-accessible MMIO
-
Евангелие от Иоанна: стих 1[/size]
Code: Select all
; В начале было Слово: B32: mov ax, os_stack ; Selector for os
Код pci32.inc можно добавить на SVN в trunk?
Залил (с 5-й попытки )<Lrz> wrote:Код pci32.inc можно добавить на SVN в trunk?
Евангелие от Иоанна: стих 1[/size]
Code: Select all
; В начале было Слово:
B32: mov ax, os_stack ; Selector for os
А build.bat в корневой директории зачем оставил?art_zh wrote:Залил (с 5-й попытки )
И кстати, раз уж это не является необходимым сервисом (как я понял, только для облегчения разработки драйверов), то почему бы не оформить это в виде драйвера, ведь все используемые процедуры доступны и из драйвера. Кому надо, тот его загрузит. А так - будет лежать балластом в ядре. Кроме того, прямой доступ из usermode к устройствам в обход драйвера - не самый безопасный вариант.
tsdima
Мусор от первой закачки прибрал.
Насчет драйвера.
Добавляя 3 новых API-функции, я руководствовался следующими соображениями:
1. Колибри - не Линукс: здесь легче изменить ядро, чем довести до ума новый драйвер.
2. Системный сервис - он на то и системный, чтобы сидеть в составе кернела, а не в примочках. "Ядерные" модули в монолитной ОСи смотрятся криво.
3. Механизм системных вызовов гораздо надежнее и эффективнее, чем еще один IOCTL-канал черезж.драйвер.
4. Система однозначно предоставляет пользователю не более одного канала MMIO, и только для общения с конкретно указанным при компиляции устройством. А если сервис реализовать через драйвер - тогда юзер сможет сдуру понамаппить сколько угодно и каких угодно устройств, в любой комбинации. ИМХО первый вариант гораздо лучше застрахован от случайного доступа к чужому и системному железу.
5. Вредитель через MMIO не полезет - в распоряжении злоумышленника есть тысяча гораздо более удобных системных дыр.
6. С тезисом о том, что пользовательский доступ к "железной" памяти устройств "не является необходимым", я категорически не согласен. Нужно много новых драйверов, хороших и разных. А как довести до ума драйвер USB без отладчика? SATA? Независимый (от BIOS) энумератор устройств, конфигуратор PCIe, хотплаг? Без uMMIO у нас не будет никаких шансов на их скорую реализацию.
7. Если полноценная desktop-KOS - дело отдаленного будущего, а для netbook-KOS свет клином сошелся на графическом браузере, то embedded-KOS уже не за горами. Для многих приложений (АСУ, системы сбора данных и обработки сигналов) отдельный системный драйвер и не нужен вовсе - там приложение должно напрямую рулить железом, а система призвана лишь обеспечивать ему вспомогательный сервис и удобный аппаратный канал.
Мусор от первой закачки прибрал.
Насчет драйвера.
Добавляя 3 новых API-функции, я руководствовался следующими соображениями:
1. Колибри - не Линукс: здесь легче изменить ядро, чем довести до ума новый драйвер.
2. Системный сервис - он на то и системный, чтобы сидеть в составе кернела, а не в примочках. "Ядерные" модули в монолитной ОСи смотрятся криво.
3. Механизм системных вызовов гораздо надежнее и эффективнее, чем еще один IOCTL-канал через
4. Система однозначно предоставляет пользователю не более одного канала MMIO, и только для общения с конкретно указанным при компиляции устройством. А если сервис реализовать через драйвер - тогда юзер сможет сдуру понамаппить сколько угодно и каких угодно устройств, в любой комбинации. ИМХО первый вариант гораздо лучше застрахован от случайного доступа к чужому и системному железу.
5. Вредитель через MMIO не полезет - в распоряжении злоумышленника есть тысяча гораздо более удобных системных дыр.
6. С тезисом о том, что пользовательский доступ к "железной" памяти устройств "не является необходимым", я категорически не согласен. Нужно много новых драйверов, хороших и разных. А как довести до ума драйвер USB без отладчика? SATA? Независимый (от BIOS) энумератор устройств, конфигуратор PCIe, хотплаг? Без uMMIO у нас не будет никаких шансов на их скорую реализацию.
7. Если полноценная desktop-KOS - дело отдаленного будущего, а для netbook-KOS свет клином сошелся на графическом браузере, то embedded-KOS уже не за горами. Для многих приложений (АСУ, системы сбора данных и обработки сигналов) отдельный системный драйвер и не нужен вовсе - там приложение должно напрямую рулить железом, а система призвана лишь обеспечивать ему вспомогательный сервис и удобный аппаратный канал.
Евангелие от Иоанна: стих 1[/size]
Code: Select all
; В начале было Слово:
B32: mov ax, os_stack ; Selector for os
ИМХО, можно и в драйвере предусмотреть ту-же самую глобальную переменную, хранящую конкретное устройство, и на мой взгляд, лучше было бы позволить инициализировать эту переменную, но только один раз. На мой взгляд, вероятность ошибиться при установке этой переменной в исходном коде ядра и при установке её в исходном коде вызова функции инициализации драйвера в тестовом приложении одинаковая.art_zh wrote:4. Система однозначно предоставляет пользователю не более одного канала MMIO, и только для общения с конкретно указанным при компиляции устройством. А если сервис реализовать через драйвер - тогда юзер сможет сдуру понамаппить сколько угодно и каких угодно устройств, в любой комбинации. ИМХО первый вариант гораздо лучше застрахован от случайного доступа к чужому и системному железу.
Неудобство в следующем: каждый раз, обновляясь с SVN я должен буду не забыть установить эту переменную в коде ядра. Хорошо, если она одна, но если мы и дальше будем применять такую тактику, то перед компиляцией нужно будет делать нечто аналогичное "конфигурации перед компиляцией" в линухе.
Преобразовал переменную mmio_pci_addr типа word (кстати, помещать инициализированную переменную после неинициализированных было не очень хорошей идеей) в константу времени компиляции; по умолчанию константа не определена и соответствующий код при компиляции вообще не включается в бинарник (не то чтобы его там было много, но раз он всё равно неактивен...).
P.S. Перед заливкой чего бы то ни было на svn желательно всё же проверять это хотя бы на компилябельность. У меня есть и более интересные занятия, нежели при подготовке ночной сборки выяснять, почему pcidev вообще перестал компилироваться.
P.S. Перед заливкой чего бы то ни было на svn желательно всё же проверять это хотя бы на компилябельность. У меня есть и более интересные занятия, нежели при подготовке ночной сборки выяснять, почему pcidev вообще перестал компилироваться.
Вообще-то при обновлении по svn up (aka svn update) все локальные изменения сохраняются, так что установить значение в локальной копии репозитория достаточно один раз.tsdima wrote:каждый раз, обновляясь с SVN я должен буду не забыть установить эту переменную в коде ядра.
Ушёл к умным, знающим и культурным людям.
...а я в это же время перемещал mmio_pci_addr в "более подходящее место". В результате - коллизия версий, час на расшивку и 2 лишние закачки.diamond wrote:Преобразовал переменную mmio_pci_addr типа word (кстати, помещать инициализированную переменную после неинициализированных было не очень хорошей идеей) в константу времени компиляции; по умолчанию константа не определена и соответствующий код при компиляции вообще не включается в бинарник (не то чтобы его там было много, но раз он всё равно неактивен...).
Условная компиляция системных функций? я бы ни за что на такое не решился... а с другой стороны, почему бы и нет?
Тут моя запарка, виноват.diamond wrote:P.S. Перед заливкой чего бы то ни было на svn желательно всё же проверять это хотя бы на компилябельность. У меня есть и более интересные занятия, нежели при подготовке ночной сборки выяснять, почему pcidev вообще перестал компилироваться.
config.h - не самое худшее из того, что есть в Линуксе. Мы к этому тоже когда-то обязательно придем.tsdima wrote: Неудобство в следующем: каждый раз, обновляясь с SVN я должен буду не забыть установить эту переменную в коде ядра. Хорошо, если она одна, но если мы и дальше будем применять такую тактику, то перед компиляцией нужно будет делать нечто аналогичное "конфигурации перед компиляцией" в линухе.
Начиная с Rev.1370 сервис работает стабильно. Проверял на 4 разных машинах и на разных PCI-картах.
Для включения - раскомментировать константу mmio_pci_addr в самом начале bus/pci/pci32.inc и установить реальный PCI-адрес тестируемого утстройства.
Исправил пару багов в PciDev.asm и добавил чтение ROM-блока (правда, пока что не нашел ни одной коммерческой карты, в которой ROM был бы открыт для чтения...)
Для включения - раскомментировать константу mmio_pci_addr в самом начале bus/pci/pci32.inc и установить реальный PCI-адрес тестируемого утстройства.
Исправил пару багов в PciDev.asm и добавил чтение ROM-блока (правда, пока что не нашел ни одной коммерческой карты, в которой ROM был бы открыт для чтения...)
- Attachments
-
-
CAP1.gif (17.23 KiB)Viewed 10281 times
-
Евангелие от Иоанна: стих 1[/size]
Code: Select all
; В начале было Слово:
B32: mov ax, os_stack ; Selector for os
art_zh, спасибо ummio очень полезная функция, с помощью нее уже сдампил mmio блок с wifi-адаптера. Вот, сделал для себя памятку как этим пользоваться и добавил обертку этих трех системных вызовов на Си чтобы в сишных программах использовать, может быть кому пригодится )
- Attachments
-
- Downloaded 269 times
The best way to predict the future is to create it.
Они были документированы3) Становятся доступны подфункции 11, 12, 13 системной функции 62.
Они не документированы в вики. Поэтому я, почитав исходники pci32.asm понял как их использовать т.е в какие регистры что ложить, и потом составил такие обертки для их вызова из Си:
просто кто-то когда-то почему-то посчитал что это никому нафиг не нужно
Эээ... надо бы добавить в SYSFUNC(R).TXT
Из хаоса в космос
добавил 10 лет назад - и в русскую, и в английскую версиюLeency wrote:Эээ... надо бы добавить в SYSFUNC(R).TXT
P.S. SVN говорит, что описание расширенного сервиса PCI (ф.62 : пф.12,13) висело в транке с 3 января 2010 (r1353, art_zh) по 17 октября 2010 (r1662, Nazarus)
Удивительно, но через 10 лет вдруг появился второй человек, которому это вообще интересно
- настолько, что он полез в ядерный код разбираться что к чему
откатил описание функции 62 на Вики как было раньше
Евангелие от Иоанна: стих 1[/size]
Code: Select all
; В начале было Слово:
B32: mov ax, os_stack ; Selector for os
Просто заинтересовался темой написания драйвера на wifi адаптер, и решил так сказать сначала прощупать почву - с помощью сишной программы посмотреть что же лежит в mmio у pci устройств..art_zh wrote: Удивительно, но через 10 лет вдруг появился второй человек, которому это вообще интересно
- настолько, что он полез в ядерный код разбираться что к чему
The best way to predict the future is to create it.
Who is online
Users browsing this forum: No registered users and 22 guests