Устранение из пци пространства
Вот сабж, меня заинтересовало то, как биос делает так, что встроенные контроллеры, дополнительные райд, сата, усб, файрвайр и прочие могут быть выключены таким хитрым образом, что не появляются в пци пространстве, к которому, как известно, доступ для отпроса осуществляется посредством портов. Как биос их из пци пространства отшивает? Можно ли сделать так уже будучи в ос системе, удалить контроллер любой из пци пространства, если тот не используется?
Я так понимаю, это прерогатива пци биоса и все устройства найденные так или иначе проявляются в определённой области памяти, вот как бы ими заведовать из под оси?
Очень прошу помощи по этому вопросу у гуру обитающих на этом замечательнейшем форуме :P
Мне самому нужно удалить из пци пространства устройство, которое я выключить не могу, а именно это FireWire контроллер в качестве второго функционального устройства у звуковой карты, что ни делай, всё время с ним конфликты и система не выключает его, всё время помеченым остаётся, как бельмо в глазу :oops: хотя сказать, чтобы особо мешало нельзя, но всё равно на общий вид давит.
Прошивка и настройка BIOS, переделка и ремонт материнских плат, БП, видеокарт, HDD.
ROM.by 2002-2019 © apple_rom
savely_s
ну, задача была отключить PCIйное адрессное пространство. Т.е. чтобы PCI PnP ID вообще не отдавался. FFFF - не выход, т.к. это может означать, что дивайсов больше нет. Поэтому половину программ может заколбасить.
K9
вариантов много как реализовать на практике. Например, действительно управлять питанием чипа. Но я привел самый простой случай
Аццкий ромбовод {:€
Я пока не волшебник - я только учусь! :-P
Из ОС можно работать только с теми полями хедера PCI устройства, которые врайтебельны: например, можно прописать IRQ или базовый адрес ввода-вывода. Для Win9x это элементарно делается через autoexec. (Было время, когда я таким образом лет десять назад патчил криво сконструированные SCSI адаптеры на NCR810. BIOS им прерывание не назначал в принципе, и я прописывал в нужный регистр 0хВ, задавая таким образом IRQ11). Думаю, если поэкспериментровать, что-то может и получиться. Рекомендую PCI.exe, Version 2.2, Brought to you By Intel Corporation's Friendly - PCD Systems Engineering.
Для WinXP и п.т. ОС рекомендаций нет.
Но по большому-то счету вызывает сомнение способ решения того конфликта, о котором говорится в первом посте. А можно подробнее о звуке с 1394 на борту?
K9
у сказя свой БИОС? Уверен, что пунктик отвечает за "включенность" БИОСа сказюка, а не за его наличие на PCI
BTW, VenID/DevID не пишется через WPCREdit. Можете сами проверить. Либо оно лежит в епромке (как на SB Live!), либо во флешке (Silicon), либо внутри чипса...
Аццкий ромбовод {:€
Я пока не волшебник - я только учусь! :-P
FFFF - не девайсов больше нет, а просто по опред.BusNo/DevNo/Function нет устройства. Насколько я знаю - единственный способ енумерации PCI - тупой перебор. По Bus/Dev/Func
Ну, в общем случае врайтабельно практически все, за исключением VID/DID, RevID, Class Code, HeaderType.
А способ решения - да, не стреляем ли из пушки по воробьям?
А кому счас легко...
Правильно. Как только программа натыкается на VenID=DevID=FFFF она понимает, что больше дивайсов нет. Т.к. кол-во дивайсов изначально не известно.
Аццкий ромбовод {:€
Я пока не волшебник - я только учусь! :-P
Неа. Она должна всего лишь перейти к след. номеру функции. Для старых PCI - возможно к следующему DevNo. Но правильнее - к функции.
P.S. У меня есть свой энумератор PCI, проверенный на тысячах компов
Там как раз недавно был переход на след. DevNo, который исправлен на переход к след. FuncNo. Девайсов стало больше 
(во всяком случае количество стало совпадать с Виндой).
А кому счас легко...
Алгоритм такой:
идем по дивайсам от 0-й шины, 0-го дивайса, 0-функции.
Видим FFFF - возвращаемся на уровень выше.
Поэтому FFFF - маркер
а) того, что больше нету функций у multifunction device => переходим к след. дивайсу
б) если мы увидели такой настоящий дивайс, который не мульти-, то переходим к след. шине PCI.
в) как там с шинами PCI я уже не знаю
Дабы прекратить споры, предлагаю остановиться на двух моментах:
а) если дивайса нет, то получаем Devid=FFFF
б) но т.к. кол-во дивайсов не известно, а нумерация (адресация) у них подряд, то дойдя до FFFF, энумеровать (как оно по-русски? а! перечислять!) дивайсы уже надо
Аццкий ромбовод {:€
Я пока не волшебник - я только учусь! :-P
Однако, пойду читать доку... Что-то у меня появилось желание увидеть/вспомнить, что пишут по этому поводу PCISIG.
Спорить - смысла нет, если есть дока. Надо ее просто почитать, что я и собираюсь сделать. Возможно, у меня в проге хромает логика (проверка мультифункциональности не в том месте и т.п), вот о чем я подумал...
А кому счас легко...
Для 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 Изрядно мы уклонились от предложенной темы?
:)
Отправить комментарий