Форум программистов «Весельчак У»
  *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

  • Рекомендуем проверить настройки временной зоны в вашем профиле (страница "Внешний вид форума", пункт "Часовой пояс:").
  • У нас больше нет рассылок. Если вам приходят письма от наших бывших рассылок mail.ru и subscribe.ru, то знайте, что это не мы рассылаем.
   Начало  
Наши сайты
Помощь Поиск Календарь Почта Войти Регистрация  
 
Страниц: [1]   Вниз
  Печать  
Автор Тема: Доступ к PCIe мосту (для сброса PCIe платы)  (Прочитано 12465 раз)
0 Пользователей и 1 Гость смотрят эту тему.
WWX
Участник

ru
Offline Offline

« : 06-11-2020 11:28 » 

Доброго времени суток.

Есть некая PCIe плата. Для того, чтобы корректно реализовать на ней сброс требуется доступ к конфигурационному пространству моста, к которому она подключена.
А именно в регистре моста "Bridge Control Register" (0x3E) на некоторое время установить (6-й) бит "Secondary Bus
Reset". (Во всяком случае в драйвере под Linux для этой платы делается именно так.)

Можно ли что-то подобное сделать под Windows 7 и Windows 10?

В запросе IRP_MN_QUERY_INTERFACE можно запросить следующие интерфейсы (но ни один из них полностью не подходит):

- BUS_INTERFACE_STANDARD - как я понимаю, даёт доступ только к своему конфигурационному пространству (но под Windows 7 работает).

- DEVICE_RESET_INTERFACE_STANDARD - (ещё не пробовал), но, судя по описанию, работает только под Windows 10.

- PCI_EXPRESS_ROOT_PORT_INTERFACE - вероятно делает то, что нужно (т. е. даёт доступ к конфигурационному пространству моста), но не очень документирован, и даже если его расковырять, то не уверен, следует ли так делать.
Записан
Ochkarik
Модератор

ru
Offline Offline
Пол: Мужской

« Ответ #1 : 19-11-2020 11:13 » 

вот тут инфа не поможет?
https://docs.microsoft.com/en-us/windows-hardware/drivers/pci/accessing-pci-device-configuration-space
через IRP_MN_WRITE_CONFIG request or the SetBusData method  или Within the ACPI BIOS?
« Последнее редактирование: 19-11-2020 11:15 от Ochkarik » Записан

RTFM уже хоть раз наконец!  RTFM :[ ну или хотя бы STFW...
WWX
Участник

ru
Offline Offline

« Ответ #2 : 23-11-2020 14:28 » 

Спасибо за ответ.

Про "ACPI BIOS" что-то не понял. Это третий метод доступа к конфигурационному пространству? Там вроде всего два метода...

"IRP_MN_WRITE_CONFIG" или "SetBusData" насколько я понимаю позволяют драйверу писать в конфигурационное пространство своего же устройства.

Точнее в пространство того устройства, чей адрес PDO (Physical Device Object) указывается.
По идее, если узнать адрес PDO или хотя бы адрес объекта любого устройства из стека DO нужного устройства, то можно было бы считать, что задача почти решена.

Но, похоже что: проблема в том, что PDO другого устройства в общем случае (а также в моём случае) нельзя узнать документированным способом.
Если кто-то опровергнет это утверждение, буду только рад.
("IoGetDeviceObjectPointer" в случае с мостом не работает (возвращает ошибку STATUS_INVALID_DEVICE_REQUEST).)

Основательно погуглив, пришёл к выводу: что получить доступ к конфигурационному пространству моста можно только внедрив в его стек свой фильтрующий драйвер. В этом случае значительно усложнится установка ПО, но другого выхода я не вижу.

Собственно метод SetBusData и получается в результате запроса интерфейса BUS_INTERFACE_STANDARD, который я упомянул в первом сообщении.

Начинаю немножко понимать линуксоидов, для того, чтобы сделать то, что в Linux'е делается в две строчки, в Windows'е приходится писать дополнительный драйвер...
Записан
Ochkarik
Модератор

ru
Offline Offline
Пол: Мужской

« Ответ #3 : 24-11-2020 23:29 » 

похоже что действительно так. через фильтр.
https://docs.microsoft.com/en-us/windows-hardware/drivers/kernel/obtaining-configuration-information-from-other-driver-stacks
хотя DeviceTree, по-моему, показывала весь стек включая PDO?
Записан

RTFM уже хоть раз наконец!  RTFM :[ ну или хотя бы STFW...
WWX
Участник

ru
Offline Offline

« Ответ #4 : 25-11-2020 08:08 » 

За ссылку - спасибо. (Почему-то я её пропустил (вот ведь как бывает), хотя и пришёл к правильному выводу.)

Цитата
хотя DeviceTree, по-моему, показывала весь стек включая PDO?

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

"pciscope", например, на ПК (на котором должна работать эта чудо плата) не заработал вообще.
Хотя этот ПК сам по себе очень странный, одних ядер там штук сорок...
Записан
Ochkarik
Модератор

ru
Offline Offline
Пол: Мужской

« Ответ #5 : 25-11-2020 12:02 » new

последняя версия DeviceTree - 2011 года и работает до сих пор) хорошие возможности)
Записан

RTFM уже хоть раз наконец!  RTFM :[ ну или хотя бы STFW...
WWX
Участник

ru
Offline Offline

« Ответ #6 : 26-11-2020 09:20 » 

Да, действительно работает, даже PDO показывает.
(Хотя моё устройство в PnP перспективе показала только после второго запуска, а мост показывала всегда. В Driver перспективе и мост и моё устройство также всегда показывала.)

Но при запущенном DeviceTree не получилось выгрузить драйвер из диспетчера устройств без перезагрузки системы.
Можно предположить, что эта программа использует что-то вроде "ObReferenceObjectByName" (недокументированная широко известная в узких кругах ф-ция (не для законопослушных драйверов)).
Записан
Ochkarik
Модератор

ru
Offline Offline
Пол: Мужской

« Ответ #7 : 27-11-2020 10:56 » 

это они могут, это они любят)
а зачем устройству то сброс шины понадобился? нешто обойтись нельзя было.. не поверю
Записан

RTFM уже хоть раз наконец!  RTFM :[ ну или хотя бы STFW...
WWX
Участник

ru
Offline Offline

« Ответ #8 : 27-11-2020 14:37 » 

Ух, постараюсь объяснить.

Дело в том, что раньше сброс этой платы осуществлялся путём записи в соответствующий регистр. При этом сбрасывалось (почти) всё на плате, включая сам контроллер PCI (но BAR'ы, насколько я понимаю, не сбрасывались).
Корень зла здесь в том, что наши доблестные жестянщики не сделали отдельный сброс всего кроме контроллера PCI.

И всё бы ничего, но нашёлся один ПК, на котором это приводило к Kernel Panic на Linux'е или BSoD'у на Windows'е.
Похоже что подобный сброс трактовался как внезапная потеря устройства, не поддерживающего внезапного удаления.

Если же мост выдаёт "Secondary Bus Reset" то состояние устройства игнорируется системой (ну или по крайней мере система не падает при "пропадании" устройства). Теперь, грубо говоря (но мягко выражаясь) firmware на плате ждёт этого сигнала и сбрасывает сам себя.
Записан
Ochkarik
Модератор

ru
Offline Offline
Пол: Мужской

« Ответ #9 : 27-11-2020 23:47 » 

хм. бывает)) мне раз пришлось писать специальный сервис заливающий прошивку после старта винды для платы с нерабочей флешкой)
 а без сброса никак? ну подумаешь комп перезагрузить после установки драйвера. раньше сплошь и рядом было.
« Последнее редактирование: 27-11-2020 23:49 от Ochkarik » Записан

RTFM уже хоть раз наконец!  RTFM :[ ну или хотя бы STFW...
WWX
Участник

ru
Offline Offline

« Ответ #10 : 30-11-2020 07:26 » 

Увы, сброс нужен не для установки драйвера, а для "нормальной" работы платы.
(В процессе работы её нужно периодически сбрасывать.)
Записан
Ochkarik
Модератор

ru
Offline Offline
Пол: Мужской

« Ответ #11 : 30-11-2020 11:16 » 

я имел в виду что при перезагрузке сброс же происходит один раз.
а если IRP_MN_SURPRISE_REMOVAL обработать? кто BSOD вызывал, драйвер устройства или драйвер шины одного единственного ПК?
Записан

RTFM уже хоть раз наконец!  RTFM :[ ну или хотя бы STFW...
WWX
Участник

ru
Offline Offline

« Ответ #12 : 30-11-2020 14:27 » 

Цитата
я имел в виду что при перезагрузке сброс же происходит один раз.
Ну это я неточно выразился.
Прикладной софт должен иметь возможность сбрасывать плату неограниченное количество раз без перезагрузки ПК.
Цитата
а если IRP_MN_SURPRISE_REMOVAL обработать? кто BSOD вызывал, драйвер устройства или драйвер шины одного единственного ПК?
Пробовал делать обработку IRP_MN_SURPRISE_REMOVAL - не помогло.

Максимум чего тогда (без фильтра) добился это в IRP_MN_QUERY_CAPABILITIES ставил "Removable" и "SurpriseRemovalOK".
При этом появлялась иконка в трее (наподобие извлечения флешки). Если т. о. через неё выгрузить драйвер, то можно один раз "безопасно" сбросить плату через кнопку сброса (эта кнопка расположена на самой плате). При повторном нажатии (равно как и при первом нажатии без подобной подготовки) ловится BSoD.
Но после такого сброса драйвер уже не загружается. Система ждёт, что плата исчезнет физически (но такой эксперимент чё-то не хочется проводить).
Видимо нужно было "Политику удаления" поменять с "1" на "3" (как у флешки). Но как это сделать я не нашёл.

А вот через фильтр вроде бы нормально сбрасывается.

BSoD вызывал точно не драйвер устройства, а вот кто именно - не особо понятно.
Собственно BSoD: 0x124: WHEA_UNCORRECTABLE_ERROR.

Рабочая гипотеза, что на плате присутствует аппаратный модуль, который бдит за состоянием устройств и в случае чего оповещает об этом ОС...
Записан
Страниц: [1]   Вверх
  Печать  
 

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines