Вот сабж, меня заинтересовало то, как биос делает так, что встроенные контроллеры, дополнительные райд, сата, усб, файрвайр и прочие могут быть выключены таким хитрым образом, что не появляются в пци пространстве, к которому, как известно, доступ для отпроса осуществляется посредством портов. Как биос их из пци пространства отшивает? Можно ли сделать так уже будучи в ос системе, удалить контроллер любой из пци пространства, если тот не используется?
Я так понимаю, это прерогатива пци биоса и все устройства найденные так или иначе проявляются в определённой области памяти, вот как бы ими заведовать из под оси?
Очень прошу помощи по этому вопросу у гуру обитающих на этом замечательнейшем форуме :P
Мне самому нужно удалить из пци пространства устройство, которое я выключить не могу, а именно это FireWire контроллер в качестве второго функционального устройства у звуковой карты, что ни делай, всё время с ним конфликты и система не выключает его, всё время помеченым остаётся, как бельмо в глазу :oops: хотя сказать, чтобы особо мешало нельзя, но всё равно на общий вид давит.
ну, задача была отключить PCIйное адрессное пространство. Т.е. чтобы PCI PnP ID вообще не отдавался. FFFF - не выход, т.к. это может означать, что дивайсов больше нет. Поэтому половину программ может заколбасить.
K9
вариантов много как реализовать на практике. Например, действительно управлять питанием чипа. Но я привел самый простой случай :D
Для WinXP и п.т. ОС рекомендаций нет.
Но по большому-то счету вызывает сомнение способ решения того конфликта, о котором говорится в первом посте. А можно подробнее о звуке с 1394 на борту?
у сказя свой БИОС? Уверен, что пунктик отвечает за "включенность" БИОСа сказюка, а не за его наличие на PCI :D По крайней мере, так сделано, например, на Супермайкрах.
BTW, VenID/DevID не пишется через WPCREdit. Можете сами проверить. Либо оно лежит в епромке (как на SB Live!), либо во флешке (Silicon), либо внутри чипса...
Ну, в общем случае врайтабельно практически все, за исключением VID/DID, RevID, Class Code, HeaderType.
А способ решения - да, не стреляем ли из пушки по воробьям?
Правильно. Как только программа натыкается на VenID=DevID=FFFF она понимает, что больше дивайсов нет. Т.к. кол-во дивайсов изначально не известно.
P.S. У меня есть свой энумератор PCI, проверенный на тысячах компов :wink: Там как раз недавно был переход на след. DevNo, который исправлен на переход к след. FuncNo. Девайсов стало больше :lol: (во всяком случае количество стало совпадать с Виндой).
идем по дивайсам от 0-й шины, 0-го дивайса, 0-функции.
Видим FFFF - возвращаемся на уровень выше.
Поэтому FFFF - маркер
а) того, что больше нету функций у multifunction device => переходим к след. дивайсу
б) если мы увидели такой настоящий дивайс, который не мульти-, то переходим к след. шине PCI.
в) как там с шинами PCI я уже не знаю :( :(
Дабы прекратить споры, предлагаю остановиться на двух моментах:
а) если дивайса нет, то получаем Devid=FFFF
б) но т.к. кол-во дивайсов не известно, а нумерация (адресация) у них подряд, то дойдя до FFFF, энумеровать (как оно по-русски? а! перечислять!) дивайсы уже надо
Спорить - смысла нет, если есть дока. Надо ее просто почитать, что я и собираюсь сделать. Возможно, у меня в проге хромает логика (проверка мультифункциональности не в том месте и т.п), вот о чем я подумал...
Для NCR810 - правильное утверждение последнее: внутри чипа. Безо всяких SCSI BIOS сей дивайс будет работать (правда в ограниченой функциональности) в "типа Виндоус", да и наверное в Юниксах тоже.
Могу рекомндовать вместо чтения доки дизассблировать стартовый фрагмент Феникс БИОС (сейчас это актуально, isn't it?). Там буквально вначале есть процедура поиска Class Code (даю наводку - 0x600). И сразу логика работы с PCI шиной становится на место. Это что-то подобное
mov ecx, 80000000h
xchg eax, ecx
mov al, 8
Loop:
mov dx, 0CF8h
out dx, eax
mov dx, 0CFCh
mov edi, eax
. . .
PS Изрядно мы уклонились от предложенной темы?
:)