Здравствуйте.

Материнская плата, грелся хаб и ЕС.

Были заменяны, хаб 3 раза на разные рабочие.

Проблема, по секвенсу все поднимается до SM_SDRAMPWROK, H_PWRGOOD хаб уже не выдает.

После этого, следует сброс SLP_S и все по новой.

Я не знаю, что добавить... Замерял все сигналы на ЕС, скачат в такт только слипмоды и HWPG, который от них зависит через 1.5V и CLK_RUN#
И да я действительно обмерил все 128 ног ес.

ЕС держит все сигналы для хаба, а хаб все равно грохает SLP_S, все питальники отрабатывают нормально.

Если запускать без ЦПУ, все висит на шаге 35 (HWPG) включительно, как и на живой матери что под рукой...

B+ не скачет?

_________________
The fish will soon be caught that nibbles at every bait...)

и cpu_core тоже? так ведь для этого не все условия

Нет =)



Нет, VCORE естественно по нулям. Извиняюсь, думал будет очевидно с топика.

не, это я извиняюсь... читая содержание, заголовок частенько забываю о чем.

ну если нет vcore, то тогда собственно возвращаемся так кстати апнутой теме 2012 года
viewtopic.php?f=231&t=81673

И? Понятно, почему нет VCORE, нет H_PWRGOOD, как выяснено в недавной теме оффтопа viewtopic.php?f=33&t=127481

Суть в том, что хаб, почему то сбрасывает SLP_S3\SLP_S5\SLP_S4 вместо того, что бы выдать H_PWRGOOD.
Природа сего явления мне не ясна.

И что самое странное, SUS_ON\RUN_ON остаются. Что по мне, исключает ложное срабатывание всяких там термо и OV защит.
Добавлю что ME_SUS_PWR_ACK всегда высокий.

У нас получается, что ЕС говорит платформе работать и ждет последнего шага от хаба, а хаб ресетиться как только должен выдать добро на запуск VCORE, да еще и не до конца (ME_SUS_PWR_ACK высокий). Мудота какая то...

Еше раз поменял хаб, без вариков.

Провел эксперимент на рабочей - накоротко замкнул H_PWRGOOD, мать не ресетиться так. Просто ждет этот самый H_PWRGOOD.
Те ресет хаба происходит не от того что он "пытается" выдать H_PWRGOOD и не видя VCORE перезапускается. Причина иная...

сталкивался с подобной дребеденью несколько раз и не решил проблему.
тоже все было поменяно, питания проверены, шилось -перешивалось - и нифига.
не знаю, может хаб не вовремя получает hwpg , а тот задерживается из-за
какого-нить опаздывающего pwg, а тот опаздывает из-за медленно подымающейся вторички.
вообщем, хрень и гадание на кофейной гуще.

причем , были варианты как с просто сбрасываемыми слипами (один раз в ноль) после
того как все питания запущены, так и варианты со скачущими слипами и при этом тоже питания
стояли в норме(мульт их не сбрасывал)

Фуххх. Умудрился точно так же сломать (намерено) живую R09.

Вообщем описанное мной поведение, вызвано отсутствием обмена по линии SPI между PCH и EC.
В случае обрыва линии, поведение мат платы становиться 1 в 1. Проверил, на мертвой обмена таки то же нет.

EC тут выступает в роли ведомого, значит PCH должен начинать обмен, что он и делает. EC в ответ посылает нули.
Осталось понять, почему, EC отказывается осуществлять обмен по шине... предложения приветствуются.

не думаю, что хаб обменивается с ЕС по SPI.
их общая SPI сугубо для чтения флэши, причем во времени их обращения разделены.
имхо.
разделив шину, можно конкретно увидеть , кто инициирует CS#

Курим схему, она в открытом. SPI хаба ведет на EC. На ЕС SPI-slave реализован софтварно (написано что GPIO) и походу эмулирует флешь, либо он хардварно может это делать, суть не меняется.

Починилося...

Причина была в том, что из-за небольшого... кхм... залития PQ13 (усилитель RUN_ON) 5V_ALW\3.3V_ALW попадали на 5V_RUN\3.3_RUN, платформа себя начинала вести подобным образом...

Итого, 3 раза замененный хаб, один из доноров подох при реболе, 2 раза поменян ЕС, прошито бесчисленное кол-во разных биосов, вызвонено половина дорог от хаба до проца, изза полнуночной работы убит тестовый процессор, куплен новый видеочип за 4.5к.