Если Вы внимательно читали предыдущее сообщение, то

icbook писал(-а):
vi писал(-а):
Ну идейно, даташит на интеловские мосты есть в свободном доступе, нужна живая мать, чтоб поглядеть какие адреса BIOS для USB контроллера назначает и под нож все обращения к ним.

Если Вы внимательно читали предыдущее сообщение, то кроме 25-го кода найдется еще несколько точек, где есть манипуляции с USB.

Читал внимательно, все зависит от пряморукости написания биос, идейно было-бы правильно со стороны биос - пропускать весь инит при usb задизабленном;) Но скорее всего пряморукие писатели биоса смос не проверяют и придется ловить все записи по соответствующим портам, хуже но решаемо;)

icbook писал(-а):

vi писал(-а):
Кроме того злачное место это отключение usb контроллера в BIOS - т.е. делаем дамп CMOS с включенным контороллером и выключенным, ищем нужную ячейку, а потом при проверке данной ячейки - USB всегда выключен

Это идея хороша для i386...

.
почему?

icbook писал(-а):

vi писал(-а):
Гм. заняться что-ли? Времени вот только на все не хватает..
.
С нетерпением ждем результатов:)
vi писал(-а):
Так, 0x25 код это вроде уже не бут-блок?

Не бут-блок... Это точно...

Это и останавливает, я для тестера памяти бут-блок ковырял, там все было-бы быстрее

Добавлено спустя 4 минуты 55 секунд:

_AVP_ писал(-а):
2 icbook:
А как приблизительно выглядит код при инициализации на пост 25?
Тк устройств опрашивать предстоит много чтото типа
CALL иниц. PCI устройства 0
JMP по какому-то флагу на останов
CALL иниц. PCI устройства 1

IMHO Там скорее не jmp на останов, а бесконечное ожидание ответа от сгоревшего контроллера, или подвисон чипа при попытке его программмирования