а что, если в качестве опорного сигнала попробовать использовать наиболее подходящий сигнал инициализации периферии: CB(_B) starts up a virtual machine, which does: - initializes the PCI Bridge - disables the GPU PCIE JTAG test port - initializes the serial port - talks to the SMC to clear the "handshake" bit - initializes memory - generates RROD if memory init fails т.е. который четко можно привязать по времени и отследить на матери[/QUOTE]
вот только глючим проц именно чтоб запустить этот самый CB_B, в момент работы CB_A, который нихрена не инициализирует
Еще кстати как дополнение к возможности поискать пост-шину.. Работа рутинная, но все же - опираясь на даташит старого ЦПУ (а можно и без него) вполне реально отмести кучу пинов процессора - там через один земля, и масса дорожек к ОЗУ идет, питания можно промерить... А вот что не получится исключить - там поискать посты.
Возможно вообще убрана из загрузчиков выставка пост-кодов? А для тестирования используются сервисные загрузчики Если так, то надо ждать когда китайцы своруют сервисный загрузчик CB_A, как когда-то было с CB_B
это может растянуться на несколько месяцев.. если вообще к чему-то приведет. сложность на уровне разработки под винбонд, объем в тыщу раз больше помощника бы.. да походу никто из присутствующих не осилит :(
ты же писал, что проц они там под твоим руководством перекидывают или что то в этом роде на винчестере, буквально месяц назад
сказал что TX годы потратили на разработку RGH и наверняка проверяли эту идею, нет смысла возиться сама идея довольно проста - раз регистры повреждаются от глича, давайте после глича их восстановим как были. проблема лишь в том, что регистров этих больше сотни. А мой метод чтения регистров уж очень неудобен для массового чтения. короче считать состояние сотни регистров моими способами - занятие не для слабонервных
Если кто хорошо разбирается в железе и ассемблере, плюс имеет пару свободных месяцев, могу на него всё свалить)) самому мне надоест с этим возиться уже через неделю :( дак нечего приказывать...
