Использование JTAG для диагностики неисправностей материнских плат

А я и не связываюсь (с Сентинелом). Просто уже существует готовый софт защищенный Сентинелом, это Flynn OnTAP. Вы можете уже сегодня приобрести его, и, если у Вас есть вся необходимая инфа по Вашей материнской плате (схемы, нетлисты, файлы BSDL), попробовать создать свою собственную тестовую аппликацию. Видите, все просто. Разделяй и властвуй, т.е. приобретай и действуй. Вперед и с песней.

На нашем сайте jtag-test.ru/ Вы найдете ссылку на бесплатную 30-дневную версию софта и на бесплатный учебный проект. Будут вопросы - пишите.

Если посмотреть схему десктопной материнки, то TCK, TRST#, TMS, TDI на шине PCI притянуты
к VCC и GND.
Даже на "серверной" MS-6377 они не объединены в цепочку, а на набортном SCSI вообще на землю вглухую.

Так что вариант подлезть через PCI отпадает.

для +/- универсальности остаётся вариант проходного переходника для CPU, но опять-же
провести именно граничное сканирование не получится из-за того, что цепочка на плате не разведена....только если на AMD-шных платах на 780-м и выше чипсете она будет.

Поэтому остаётся только работать в режиме отладки через процессор, но для этого надо чтобы
по меньшей мере работал камень, тогда ещё худо-бедно можно протестить память (в случае с AMD напрямую ) , NB, возможно SB....при рабочих мостах можно добраться до периферии на LPC, PCI, PCI-E.....но без документации на всю цепочку сделать это ИМХО нереально

Почему же? Реверс-инжиниринг никто еще не отменял... Да и опенсорс-BIOS имеются...
А то, что диагностировать прийдется в режиме отладки - собссно с начала темы говорилось Потому я и упомянул пользовательские скрипты/модули - т.к. не думаю, что разработчик осилит учесть схемотехнические особенности сотен (если не тысяч) моделей плат, в т.ч. и снятых с производства - а особенно с наличием нестандартных решений (к примеру, DualBIOS - прошить такую плату будет несколько проблематично)... Хотя, возможно, для краткой диагностики хватит и инициализации связки СМ-ЮМ-мульт...

Извини, брат, ты не в теме.. Без обид. Реверснуть "нетлисты, файлы BSDL", имея в руках только железку... А BIOS там нужен постольку-поскольку...

Мы же вроде как говорим о запуске процессора в режиме отладки и выполнения на нем кода, инициализирующего по очереди (и проверяющего результат соответственно) СМ, ЮМ, мульт... Т.к. JTAG цепочки на платах в общем случае нет.
Хотя насколько жизнеспособна подобная идея (вернее, в каких условиях проц остается функционирующим) - покажет разве что эксперимент.
А реверснуть нетлист, имея на руках распаянную в ноль плату, с тщательно переписанными поз. обозначениями и номиналами элементов - реально. Да, муторно, но реально. + ко всему - данный процесс поддается автоматизации

NiTr0

не согласен. Согласился бы, если кто-нибудь предложил бы реальный способ сделать это. А так это из области ненаучной фантастики.

Ну, тоже как-то через одно место... Получаем что-то типа суперпродвинутой POST-карты с заливанием "типа BIOS" напрямую в проц. И те же гадания - определить со стороны проца глючит тот же СМ или нет. Так вон POST-кодов, по которым СМ меняют - вагон и маленькая тележка, и они совсем неочевидны.

ИМХО: Эта штука полезна только разработчикам, для ремонта это неоправданно:
Если человек может писать сам скрипты на асме для пошаговой отладки железа,
то он обычно не занимается ремонтом матерей, и зарабатывает свою большую з.п. совсем по другому
Если всю эту работу возложить на фирму-производитель комплекса, то фирма погрязнет в саппорте и ценник на продукт будет не по карману даже небольшому С.Ц.....не говоря уже о частниках.
А у авторизованных С.Ц. обычно есть приблуды и тулзы от производителя, плюс доки и схемы от них-же.

В первую очередь - плюс в том, что нет привязки к цепочке LPC-ЮМ-СМ-проц, при серьезной проблеме в любом месте которой ни одного пост-кода вообще не высветится. Неважно, будь это подбитый МИО, засаживающий LPC, или отвал пятака на шине СМ-ЮМ, или отвал сокета...
+ ко всему - пост-коды неочевидны в первую очередь из-за того, что на каждом из этапов инициализируется довольно много устройств (к примеру, POST 25 - кто его знает, что накрылось; или тот же С1 у нфорсов - связанный с проблемами на PCI-E линках).
Да и даже исполнение родного биоса в режиме пошаговой отладки, с краткой историей записи в порты ввода-вывода, в идеале - с расшифровкой, ИМХО, прилично поможет свет пролить на источник проблем