Acer Aspire 5920g (двойной старт) РЕШЕНО

Аффтор, тему вы пол дня уже обновляете, может, озвучите ваш секретный винбонд? Лень схему смотреть (даже лень, как и вам, озвучивать платформу).
P.S. ну и про двойной старт у интела информации в нете много, остается узнать конкретные причины в вашем случае.

Прошу прощения, забыл: Winbond WPC8769LDG

Для начала, вопрос 3 часть вторая, я бы прошил BIOS, сохранив разумеется старый дамп. Если Вы не имеете программатора, то лучше не лезьте в ноут сами. И честно говоря, мне понятно, как Вы хотите отремонтировать ноут не разбирая, как Кашпировский ?
Прошу извинения. Для начала, HDD снимите, на всякий контакты RAM почистите ластиком, смотрите как будет реагировать ноут без HDD.

Как Кашпировский...сильно конечно - "Перепайка северного моста силой мысли", только бы где такое взять... Ноут пока не решаюсь разбирать больше из за того, что слабо представляю куда мне двигаться дальше в поиске неисправности. Узнал про комбинацию Fn+esc, (переход в бутблок), в моём случае это срабатывает - индикатор включения начинает мигать, но чтения флэшки не происходит. причём независимо от того установлен ли CPU, RAM и.т.д.) к слову ноутбук при отсутствии каких либо комплектующих на борту ведёт себя совершенно одинакового в любой их комбинации, правда повторный автостарт возникает только при при питании от сети.

PS. CPU, RAM, HDD 100% исправны

Добавил:
На 3 ноге Q37 присутствует 3.3V, а это #PLTRST от ICH8, значит сброс снят, тогда совсем не понятно почему не раскручивается диск ?

Продолжение истории.. Разобрал таки ноут, первым делом ткнул логическим анализатором на LPC CLK_33M(TP91) - OK, LAD0(TP87) - в момент включения и далее тишина

Что можно предпринять ещё ? Есть ли смысл проверять ёмкости по питанию (вдруг шумит) ?
Стоит ли шить BIOS ?

----------------------------------------------------------------------------
Обновил биос, в дампе нашлись отличия только в области ESCD (с адреса 0x80000) прошивка оказалась
целой, без "битых" мест. Залил последнюю с сайта асера, поставил Flash наместо, самое интересное что эти действа привели к некоторому положительному сдвигу: появился обмен по LPC в течении около 1мс (данные снять нечем - "колхозный" анализатор не выжимает 33МГц). К тому-же пропал саморестарт. Думаю что перешивка здесь не причём - скорее вего позитивный эффект произошёл от прогрева платы вовремя перепайки микрухи. Возможно что где-то отвал. Пробовал жать на плату - механически это не устраняется.

Опыта в ремонте девайсов с BGA, у меня маловато, что посоветуете предпринять для дальнейшей диагностики ?

Смастерил наконец девайс для съёма данных с LPC, опробовал его на заведомо исправной материнке - под руками оказалась только плата с FWH. Данные снались корректно (присутствуют поля START, IDSEL итд.) .
А вот при подключении к буку летит мусор в течении ~1мс. Возможно что косяки с подключением (наводки на провода например) Но что если действительно по LPC гонит мусор ? В таком случае очевидны проблемы с питанием ЮМ, ведь должно быть контроллер внутри южника реализован "железно", и структура шины в сигналах по линиям, должна присутствовать всегда - проблемы по питанию, кажется единственный случай когда возможны сбои в служебных полях.
Кто нибудь сталкивался в практике ремонта с подобным случаем, не беря в расчёт рассуждение о мусоре на LPC. Имею ввиду срыв обмена данными по LPC о котором я рассказывал в предыдущем сообщении ?

Уже всю голову сломал об этот бук, начинаю подумывать о поиске новой мат платы.

---------------------
Укоротив провода, идущие от LPC к "прицепу" удалось увидеть картину происходящего, сильно осложняет диагностику факт того что данные передаются блоками по 64 байта (то-есть нельзя узнать точный адрес перехода внутри этого 64 байтного блока, но с некоторой долей уверенности можно сказать что шина CPU-NB исправна upd: шина адреса-данных). Но в отличии от исправной системы, на этой материнке южный мост инициирует ретрейн, вплоть до 10 раз перезапрашивает каждый блок, случалось если в процессе старта ретрейнов происходит не очень много то инициализация доползала до поста D0

перезапросы явление вполне нормальное, так происходит и на десктопной материнке, видимо в чипсете не предусмотрен(не инициализирован) буфер данных для firmware read запросов, и для каждой DMI транзакции блок перечитывается (по количеству циклов можно примерно судить на сколько продвинулось выполнение программы относительно точки перехода) . в моём случае MCH возможно зависал при запросе от CPU на IO операцию - тк прошло всего 3 цикла чтения блока c адреса F000:E140 полагаю что зависание произошло какк реакция на первую попавшуюся команду OUT (запись в configuration space ADDRESS register) адресу F000:E16A, в документации сказано, что MCH генерирует DMI configuration cycle, только после записи IO configuration space DATA register - но кажется (опять таки только предположение) что за три цикла (по LPC) CPU не успевает дойти до второй команды OUT, так что отвал по линии #REQA[4] вполне вероятен. Я решил как следует прогреть MCH (оказалось что его до меня уже грели, под ним начал кипеть флюс) после чего мать стартанула.

в качестве бонуса в прикреплённом архиве дамп LPC во время неисправности (снятый без искажений), и программа для конвертации дампа в образ адресного пространства ( для просмотра в дизассемблере например). У кого возникнет интерес к LPC тестеру - пишите.

Вложение	Размер
lpc.rar	69.72 КБ

Мне очень интересно что за анализатор и устройство для съёма данных с LPC!
Если будет время, могли бы рассказать?

По поводу анализатора, в архиве есть исходник, а сам прибор представляет собой контроллер
Cypress EZUSB2 + плис ( в сети часто упоминается этот контроллер, на таком собраны простенькие логические анализаторы Saleae Logic/USBee Suite, там контроллер FIFO работает синхронно от внутреннего тактового генератора), в принципе наверное можно обойтись только одним контроллером - у него есть
всё что нужно для этих целей - внутренний FIFO, и асинхронное тактирование интерфейса в 8ми битном режиме он позволяет подать на вход IFCLK тактовый сигнал до 48 Mhz (тоесть почти пиковое использование полосы пропускания USB 2.0 - то есть вполне возможна передача до восьми 48Mhz сигналов. Если использовать внешнюю логику, для обработки входящих сигналов возможности становятся еще шире, например прердача 4 90Mhz сигналов, но в моём случае плис, использована главным образом как "костыль", я не смог решит проблему со стороны хоста (libusb1-0) Дело в том что при отсутствии входящих пакетов (нет тактирование IFCLK), libusb_fill_bulk_transfer отваливается по таймауту, а предусматривать больший таймаут, либо перезапрос на ожидание передачи, то теряется часть информации (процессы в libusb занимают длительное время, за которое теряется входящая информация из FIFO). Для того ПЛИС отслеживает появление внешнего тактирования от материнки и переключает IFCLK от внутреннего тактового генератора (можно взять PLL от самой Cypress EZ-USB) к синхорнному с LPC генератору PCI_CLK) возможно эта проблема решаема правильным программированием Cypress-EZUSB, но я не стал разбираться как это сделать, т.к и плата Cypress + Altera была уже готова (взята от другого проекта) впринципе измененения коснулись только прошивки Альтеры. Да ещё забыл сказать - как видно из файла lpc.dat Альтера расрпараллеливает входяшие данные, а интерфейс в режиме 16 тактируется PCI_CLK / 2. Делал так потому что уже был готовый софт под такой режим.

PS У Cypress есть контроллер под USB 3.0 в совокупности с быстродействующей плис - это даёт действительно огромные возможности по отладке различных устройств

OK, спасибо большое за разъяснения о логическом анализаторе!!