Board.KolibriOS.org

Official KolibriOS board
It is currently Thu Jun 27, 2019 1:35 pm

All times are UTC+03:00




Post new topic  Reply to topic  [ 32 posts ]  Go to page 1 2 3 Next
Author Message
PostPosted: Fri Oct 01, 2010 6:38 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Предварительный код.
Выполняет сканирование шин ACPI и PCI, определяет диапазоны ввода-вывода и другие необходимые ресурсы. В конце работы выводит таблицу обнаруженных устройств PCI и номера IRQ в PIC и APIC режимах. Устройства не использующие irq в список не попадают. Пример таблицы:
Code:
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 устройств закрывается. По крайней мере для драйверов пользовательского режима. Все подобные операции осуществляются только с учётом ресурсов, используемых устройством.


Top
   
PostPosted: Fri Oct 01, 2010 9:42 pm 
Offline
User avatar

Joined: Fri Jun 27, 2008 3:22 pm
Posts: 988
Ещё один большой шаг вперед! И пусть ещё кто-нибудь попробует сказать, что в Колибри принципиально невозможно что-то сделать. :)

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


Top
   
PostPosted: Fri Oct 01, 2010 10:17 pm 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1331
Гм...
тут сумненья возникли-с...

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

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

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

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


Top
   
PostPosted: Fri Oct 01, 2010 10:38 pm 
Offline
User avatar

Joined: Fri Jun 27, 2008 3:22 pm
Posts: 988
art_zh wrote:
1) сейчас новый бранч Kolibri-acpi уже находится 1-м этапе, а остальные два - еще впереди, или я что-то не так понял?

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


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

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


Top
   
PostPosted: Fri Oct 01, 2010 11:28 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Asper

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


Last edited by Serge on Fri Oct 01, 2010 11:45 pm, edited 1 time in total.

Top
   
PostPosted: Fri Oct 01, 2010 11:44 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
art_zh

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


Top
   
PostPosted: Sat Oct 02, 2010 11:48 am 
Offline

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


Top
   
PostPosted: Sat Oct 02, 2010 12:54 pm 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1331
maximYCH
- остынь.
- перечти сабж еще раз.
- спокойно пораскинь мозгами.

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


Top
   
PostPosted: Mon Oct 04, 2010 4:42 pm 
Offline
Kernel Developer
User avatar

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

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

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


Top
   
PostPosted: Mon Oct 04, 2010 4:54 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
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, что не даёт сканить всё подряд.


Last edited by Serge on Mon Oct 04, 2010 11:00 pm, edited 2 times in total.

Top
   
PostPosted: Mon Oct 04, 2010 5:03 pm 
Offline
User avatar

Joined: Tue May 08, 2007 12:44 am
Posts: 346
А можно поинтересоваться, к каким именно системам применимо понятие "старая" в данном контексте?

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


Top
   
PostPosted: Mon Oct 04, 2010 5:15 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Freeman

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


Top
   
PostPosted: Mon Oct 04, 2010 7:26 pm 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1331
Не совсем так - все новые чипсеты имеют встроенный механизм конфигурации 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 конвейеризируется и не ломает кэш (само собой, при соблюдении когеррентности шины).


Top
   
PostPosted: Mon Oct 04, 2010 11:09 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
art_zh

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


Top
   
PostPosted: Wed Feb 09, 2011 9:30 am 
Offline
User avatar

Joined: Tue Aug 25, 2009 4:45 pm
Posts: 794
По поводу старой модели доступа к PCI и новой - почему бы не сделать условную компиляцию - где надо скомпилировать по старой модели доступа, а где можно - по новой?


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 32 posts ]  Go to page 1 2 3 Next

All times are UTC+03:00


Who is online

Users browsing this forum: Bing [Bot] and 3 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Limited