Board.KolibriOS.org

Официальный форум KolibriOS
Текущее время: Чт июл 20, 2017 11:34 pm

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




Начать новую тему  Ответить на тему  [ 32 сообщения ]  На страницу 1 2 3 След.
Автор Сообщение
 Заголовок сообщения: Диспетчер устройств
СообщениеДобавлено: Пт окт 01, 2010 6:38 pm 
Не в сети
Kernel Developer

Зарегистрирован: Ср мар 08, 2006 6:25 pm
Сообщения: 3927
Предварительный код.
Выполняет сканирование шин ACPI и PCI, определяет диапазоны ввода-вывода и другие необходимые ресурсы. В конце работы выводит таблицу обнаруженных устройств PCI и номера IRQ в PIC и APIC режимах. Устройства не использующие irq в список не попадают. Пример таблицы:
Код:
PCI_8086_24d2 bus:0 devfn: e8 pin 1 bios irq: 5 acpi irq: 16
PCI_8086_24d4 bus:0 devfn: e9 pin 2 bios irq: 4 acpi irq: 19
PCI_8086_24d7 bus:0 devfn: ea pin 3 bios irq: 11 acpi irq: 18
PCI_8086_24de bus:0 devfn: eb pin 1 bios irq: 5 acpi irq: 16
PCI_8086_24dd bus:0 devfn: ef pin 4 bios irq: 3 acpi irq: 23
PCI_8086_24d1 bus:0 devfn: fa pin 1 bios irq: 0 acpi irq: 18
PCI_8086_24d3 bus:0 devfn: fb pin 2 bios irq: 7 acpi irq: 17
PCI_8086_24d5 bus:0 devfn: fd pin 2 bios irq: 7 acpi irq: 17
PCI_1002_9495 bus:1 devfn: 0 pin 1 bios irq: 5 acpi irq: 16
PCI_1002_aa38 bus:1 devfn: 1 pin 2 bios irq: 7 acpi irq: 17
PCI_1106_3106 bus:2 devfn: 8 pin 1 bios irq: 10 acpi irq: 21

Для тестирования диспетчера устройств я создал специальный бранч Kolibri-acpi.
На первом этапе необходимо включить в ядро патч Ghost-a настраивающий APIC. Примерный порядок работы: ядро проверяет наличие ioapic и возможность работы через io_apic, устанавливает переменную apic_mode в ACPI_IRQ_MODEL_IOAPIC=1, затем загружает диспетчер устройств. Диспетчер выполняет инициализацию ACPICA и определение устройств, описанное выше. В конце инициализации в кофигурационное пространство PCI будет записан номер IRQ в режиме IOAPIC. После этого существующие драйверы смогут работать с устройствами без изменения кода.

На втором этапе необходимо убрать из ядра и перенести в диспетчер устройств
- прямой доступ к шине PCI(bus/pci32.inc)
- резервирование портов ввода-вывода
Переписать работу с обработчиками irq
- удалить функции 41 42 44 45
- сделать каскадные обработчики irq
- сделать обработчики irq пользовательского режима.

Заключительный этап. Переход к полноценной драйверной модели.
- к существующим спискам устройств acpi и pci добавляются списки логических устройств и драйверов/сервисов. Каждое устройство монтируется на виртуальную шину. Каждый драйвер реализует необходимые обработчики подключения и отключения устройства, управления питанием и т.д. Существующая сейчас возможность резервировать любые порты ввода-вывода и линии irq а также читать и писать конфигурационное пространство любых PCI устройств закрывается. По крайней мере для драйверов пользовательского режима. Все подобные операции осуществляются только с учётом ресурсов, используемых устройством.


Вернуться к началу
 Заголовок сообщения: Re: Диспетчер устройств
СообщениеДобавлено: Пт окт 01, 2010 9:42 pm 
Не в сети
Аватара пользователя

Зарегистрирован: Пт июн 27, 2008 3:22 pm
Сообщения: 971
Ещё один большой шаг вперед! И пусть ещё кто-нибудь попробует сказать, что в Колибри принципиально невозможно что-то сделать. :)

Возникли некоторые вопросы.
1. Диспетчер устройств - это обычный процесс без каких-либо привилегий правильно? Если так, что будет если его убьют?
2. Как драйвера будут общаться с диспетчером?
3. После второго этапа, как будет осуществляться доступ к PCI, IRQ и портам?
4. Реализацию управления питанием устройства и динамическое подключение.отключение со стороны драйвера можно будет отложить или необходимо будет реализовать сразу?


Вернуться к началу
 Заголовок сообщения: Re: Диспетчер устройств
СообщениеДобавлено: Пт окт 01, 2010 10:17 pm 
Не в сети
Kernel Developer
Аватара пользователя

Зарегистрирован: Пт авг 14, 2009 1:46 am
Сообщения: 1291
Гм...
тут сумненья возникли-с...

1) сейчас новый бранч Kolibri-acpi уже находится 1-м этапе, а остальные два - еще впереди, или я что-то не так понял?

2) аналогичной функциональности сейчас можно добиться и в транке (pcidev + Ghost-патч)?

3) с предложенным вторым этапом развития дескоп-системы согласен на 100%. Для embedded-версий этот путь не годится. Налицо форк проекта. Это не плохо и не хорошо - это (имхо) уже назревшая "взрослая" стадия развития Системы.

4) насчет 3-го этапа. А как быть с хотплагом и устройствами, которые BIOS по какой-то причине не смог определить? Сможет ли драйвер их увидеть при такой организации подсистемы?


Вернуться к началу
 Заголовок сообщения: Re: Диспетчер устройств
СообщениеДобавлено: Пт окт 01, 2010 10:38 pm 
Не в сети
Аватара пользователя

Зарегистрирован: Пт июн 27, 2008 3:22 pm
Сообщения: 971
art_zh писал(а):
1) сейчас новый бранч Kolibri-acpi уже находится 1-м этапе, а остальные два - еще впереди, или я что-то не так понял?

2) аналогичной функциональности сейчас можно добиться и в транке (pcidev + Ghost-патч)?


C pcidev аналогичной функциональности не добиться, так как он не работает с драйвером ACPICA в отличие от диспетчера. А текущий функционал и предлагается тестировать на транк версии с патчем Ghost'а. В архиве драйвер ACPICA, диспетчер и пример лога.

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


Вернуться к началу
 Заголовок сообщения: Re: Диспетчер устройств
СообщениеДобавлено: Пт окт 01, 2010 11:28 pm 
Не в сети
Kernel Developer

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

1.На данный момент это обычный загружаемый сервис в пространстве ядра. Его нельзя убить.
2. Точно ещё не определено. Если перевести все драйверы на PE диспетчер сможет экспортировать ключевые функции.
3. Резервирование портов будет происходить аналогичным образом, только запрос будет обслуживать диспетчер устройств. Оперции с битовой картой портов останутся в ядре. Обработка irq изменится. Нынешние функции пользовательского режима для большинства устройств просто бессмыслены. Для каждого вектора будет вызываться цепочка обработчиков. Если в этой цепочке будет обработчик из user-mode то вектор маскируется в apic, а потоку отправляется соответствующее событие. В конце пользовательский обработчик должен вызвать специальную функцию и сообщить ядру что прерывание обработано, иначе вектор останется замаскированым. Конечно при такой схеме латентность обработчиков будет значительной, зато можно писать драйверы работающие в пользовательском режиме и "играть в микроядро". И делать пошаговую трассировку обработчиков прерываний в самой Колибри.
4. Это будет зависеть от выбранной драйверной модели. Я специально не детализировал последнюю часть потому что смогу занятся ей не раньше февраля. Так что у форумных теоретиков и любителей всё детально проектировать есть четыре месяца на разработку API. Если ничего толкового не предложат сделаю по своему разумению. Не взыщите.


Последний раз редактировалось Serge Пт окт 01, 2010 11:45 pm, всего редактировалось 1 раз.

Вернуться к началу
 Заголовок сообщения: Re: Диспетчер устройств
СообщениеДобавлено: Пт окт 01, 2010 11:44 pm 
Не в сети
Kernel Developer

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

Патч Ghost-a застопорился во многом из-за проблем с определением векторов irq в режиме ioapic. Текущий код в devman решает эту проблему. Он будет работать и с pic, но если номера векторов известны точно, глупо не использовать apic.
4. Это опять зависит от будущей драйверной модели. Если железо способно сообщить о подключении и отключении нового устройства то драйвер шины должен получить событие. Что он будет делать дальше - вопрос.


Вернуться к началу
 Заголовок сообщения: Re: Диспетчер устройств
СообщениеДобавлено: Сб окт 02, 2010 11:48 am 
Не в сети

Зарегистрирован: Вс ноя 04, 2007 2:46 am
Сообщения: 390
Для embedded-версий этот путь не годится. Налицо форк проекта. Это не плохо и не хорошо - это (имхо) уже назревшая "взрослая" стадия развития Системы.
Что я слышу???? embedded версия официальной? Нет? Тогда извините, но лучше бы Вы этого вообще не говорили. Вот когда embedded направление официально станет главным направлением КОС - пожалуйста. А извините, говорить что сейчас десктоп - это форк направление -- крайне возмутительно.
И если уж на то пошло, то embedded версия должна быть форком, но никак не десктоп.


Вернуться к началу
 Заголовок сообщения: Re: Диспетчер устройств
СообщениеДобавлено: Сб окт 02, 2010 12:54 pm 
Не в сети
Kernel Developer
Аватара пользователя

Зарегистрирован: Пт авг 14, 2009 1:46 am
Сообщения: 1291
maximYCH
- остынь.
- перечти сабж еще раз.
- спокойно пораскинь мозгами.

И не путай бранч с форком. Kolibri-HD - это бранч основного ядра.
А МеОС и КОС - это форк старого проекта на 2 (почти) независимые ветки, которые никогда уже не сольются в одно русло.


Вернуться к началу
 Заголовок сообщения: Re: Диспетчер устройств
СообщениеДобавлено: Пн окт 04, 2010 4:42 pm 
Не в сети
Kernel Developer
Аватара пользователя

Зарегистрирован: Пт авг 14, 2009 1:46 am
Сообщения: 1291
Бегло посмотрел devman на svn. Пока еще не компилил.
Код читается легко (легче чем сорцы линукса), хотя очень сильно чувствуется привязка к линуксовской структуре модулей. Еле разыскал где находится pci.h (оказалость что в \drivers\include\linux\, как и многое другое).

У меня тут созрел такой вопрос (не только к автору, но и ко всем коллегам): а может сразу отказаться от древнего доступа к конфигурационному пространству через порты?
PCIe-пространство сейчас есть на всех более-менее новых платформах, и уж если все равно заморачиваемся с ACPI, то и единый доступ к нему можно будет получить для всех платформ.
Такой подход не только резко упростит код (вместо call pci_read_config_word можно обойтись одним mov ax, word[dev_config+reg_offs]), но и позволит унифицировать доступ к конфигспейсу всех устройств.
Про ненужные задержки ввода-вывода я вообще не говорю.

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


Вернуться к началу
 Заголовок сообщения: Re: Диспетчер устройств
СообщениеДобавлено: Пн окт 04, 2010 4:54 pm 
Не в сети
Kernel Developer

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

Есть ещё много старых систем. Сам на такой сижу. pci_read_config_xxx должна скрывать реализацию доступа.

pci_read_config_xxx(pci_dev)->pci_bus_read_config(pci_dev->bus)->raw_pci_read_config(pci_bus). Последняя является виртуальной функцией и перегружается в зависимости от механизма доступа и типа шины. Конечно немного громозко по сравнению mov ax, word[dev_config+reg_offs]), но это как раз и есть унификация доступа.

Есть и ещё причины.
1. Функция проверяет reg_offs на выравнивание и на максимальное значение.
2. Синхронизация доступа. Актуально при работе через порты.
3. Права на доступ. В данном случае надо получить структуру pci_dev, что не даёт сканить всё подряд.


Последний раз редактировалось Serge Пн окт 04, 2010 11:00 pm, всего редактировалось 2 раза.

Вернуться к началу
 Заголовок сообщения: Re: Диспетчер устройств
СообщениеДобавлено: Пн окт 04, 2010 5:03 pm 
Не в сети
Аватара пользователя

Зарегистрирован: Вт май 08, 2007 12:44 am
Сообщения: 340
А можно поинтересоваться, к каким именно системам применимо понятие "старая" в данном контексте?

_________________
Разработчик языка программирования Кантор


Вернуться к началу
 Заголовок сообщения: Re: Диспетчер устройств
СообщениеДобавлено: Пн окт 04, 2010 5:15 pm 
Не в сети
Kernel Developer

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

Видимо к системам без PCI Express.


Вернуться к началу
 Заголовок сообщения: Re: Диспетчер устройств
СообщениеДобавлено: Пн окт 04, 2010 7:26 pm 
Не в сети
Kernel Developer
Аватара пользователя

Зарегистрирован: Пт авг 14, 2009 1:46 am
Сообщения: 1291
Не совсем так - все новые чипсеты имеют встроенный механизм конфигурации PCIe extended config даже при физическом отсутствии слотов PCI express. В чипсетах АМД, например, связь между мостами аппаратно реализована через PCIe x4.

В "старых системах" доступ к конфигурационному пространству устройств производился исключительно через порты 0xcf8-cfc, покрывая только 1кб конфигурационного пространства для каждого устройства.
Новый механизм использует MMIO и резервирует 4к на устройство.

Serge
1. MMIO-доступ никогда не пересекает границы конфигспейса данного устройства и всегда выровнен по DW и DD
2. Не кэшируется и не конфликтует с параллельными запросами (что вполне естественно, ведь это лишь другая обертка того же самого конфигурационного цикла шины)
3. Пункт засчитан. Хотя ничто не мешает маппить MMIO блоками (1 bdf = 4к) и передавать пользователю линейный адрес.
Но тогда - от меня:
4. MMIO конвейеризируется и не ломает кэш (само собой, при соблюдении когеррентности шины).


Вернуться к началу
 Заголовок сообщения: Re: Диспетчер устройств
СообщениеДобавлено: Пн окт 04, 2010 11:09 pm 
Не в сети
Kernel Developer

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

Не надо меня за советскую власть агитировать :D Я сам делал MMIO доступ для AC97 там где он есть. И тоже через виртуальные функции, чтобы один код работал везде. Там, где шина может работать через MMIO, будет работать. Со временем. Но для драйверов способ доступа должен быть однотипным. Фактически это HAL.


Вернуться к началу
 Заголовок сообщения: Re: Диспетчер устройств
СообщениеДобавлено: Ср фев 09, 2011 9:30 am 
Не в сети
Аватара пользователя

Зарегистрирован: Вт авг 25, 2009 4:45 pm
Сообщения: 788
По поводу старой модели доступа к PCI и новой - почему бы не сделать условную компиляцию - где надо скомпилировать по старой модели доступа, а где можно - по новой?


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

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


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

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


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

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