Аварийное восстановление AMI BIOS

9 Окт 2010 - 22:08 sush 14

Прошивка (восстановление) BIOS

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

Плата Foxconn G41MXE

Сегодня столкнулся с такой вещью: принудительно (нажатием Ctrl + Page Up) запустил аварийную перепрошивку (заранее вставил дискету с файлом образа AMIBOOT.ROM).
Дискета почиталась почиталась, файл прочитался, после чего на экране появился логотип AMI и подряд несколько строк примерно следующего содержания:

Starting Recovery BIOS.
Erasing Flash.
Programming Flash

...........
Reboot System.

Соответсвенно случилась перезагрузка и всё нормально прошилось.
--------------------------------------------------------------------------------------------------------------------------------

Теперь собственно суть вопроса:
Я, ранее разбираясь в этом самом алгоритме аварийного восстановления, был убеждён (да и остаюсь в общем-то), что на этом этапе работы BIOS из устройств инициализировано только самое низкоуровневое и необходимое для перепрошивки.
Видеоконтроллер если и работает, то очень усечённо, его ROM точно не запускался ещё!
Да и вообще, логотип AMI и видео ROM - это упакованные компоненты, а запуск аварийного восстановления возможен также при скомпроментированности упакованных модулей образа BIOS.
Строковые константы тоже кстати сидят в одном из упакованных модулей - Multilanguage.

Почему же я увидел на экране логотип и строки?
Получается, что аварийное восстановление обращается к упакованным модулям?
Если кто сталкивался или разбирался более подробно - подскажите разгадку................................
Я покопаю алгоритм дальше, надо разобраться.
Есть вариант, что принудительный запуск аварийного восстановления отличается от реального сбоя CRC....

9 Окт 2010 - 23:09 maco

Сказочник >> 27069 >> 1742.14

Если это поможет отцу русской демократии:

; 964F1P05.rom

sub_F464A:
	push    ds
	push    es
	mov     al, 0D6h
	out     80h, al
	push    0
	pop     es
	push    8000h
	pop     ds
	mov     al, ds:63h
	and     al, 8
	xor     al, 8
	jz      short loc_F467C
	and     byte ptr ds:63h, 0FEh
	call    far ptr 8000h:71Eh
	jz      short loc_F467C
	xor     al, al
	call    sub_F4683
	jz      short loc_F467C
	mov     cx, ds:66h
	call    far ptr 8000h:80Ch
loc_F467C:
	or      ds:63h, al
	pop     es
	pop     ds
	retn

sub_F4683:
	mov     ax, 0B3B3h
	call    far ptr 8000h:474h
	test    al, 40h
	jz      short loc_F46BB
	and     al, 0BFh
	xchg    ah, al
	call    far ptr 8000h:478h
	mov     al, 0B1h
	call    far ptr 8000h:474h
	mov     ah, al
	mov     al, 0B0h
	call    far ptr 8000h:474h
	cmp     ax, 55AAh
	jnz     short loc_F46BB
	mov     ax, 0B0h
	call    far ptr 8000h:478h
	mov     al, 0Ah
	cmp     ax, ax
	jmp     short locret_F46BF
loc_F46BB:
	xor     al, al
	or      sp, sp
locret_F46BF:
	retn

10 Окт 2010 - 10:23 sush

>> 14

>> to maco

Вы приводите пост, в котором выполняется опрос клавиатуры на предмет нажатия клавиш Ins/Del/Ctrl + Page Up/Ctrl + Page Downp/Ctrl + Home.
Уже в следующей за ним процедуре проверяется необходимость перехода на Rercovery BIOS на данной стадии.
Если были нажатия Ctrl + XXX, то переход произойдёт и пойдёт опрос поддерживаемых устройств аварийного восстановления - это всё известно.
Непонятка с присутсвием упакованных компонент образа в процессе аварийного восстановления....

PS: хотел прилипить к ответу такой же как у вас листинг - ида на сером фоне, но пока не понял как это делается. Подскажите в двух словах.

10 Окт 2010 - 18:56 maco

Сказочник >> 27069 >> 1742.14

Можете покопаться еще в POST D5:

POST D5 писал(-а):

.....
Copies compressed boot block code to memory in right segments.
.....

Можете пойти экспериментальным путем - залить с помощью программатора только bootblock и поглядеть на происходящее.

Листинг - используйте теги .....

10 Окт 2010 - 20:43 sush

>> 14

хм.....
D5 не занимается распаковкой

D5 занимается копирование бутблока в ОЗУ (в сегмент 8000) и переходит туда для продолжения работы, а F000 затеняется RAM

А вот с попоробовать залить только бутблок - это вариант! Эврика!
...только вот микросхема там MX25L8005, а у меня нет к ней программатора
так что критических ошибок допускать нельзя

10 Окт 2010 - 20:55 maco

Сказочник >> 27069 >> 1742.14

О распаковке речь и не идет пока. Просто упоминаются упакованные части bootblock'а - тут уже сами разбирайтесь, есть ли таковые.

sush писал(-а):

только вот микросхема там MX25L8005, а у меня нет к ней программатора

Найти еще одну микросхему с SPI интерфейсом IMHO не сложно (хоть на 64 кб). Программатор для SPI собрать тоже не сложно.
Естественно, производить операции над основной микросхемой нежелательно. Так что ищите еще одну микросхему.

10 Окт 2010 - 21:50 sush

>> 14

упакованных частей в бутблоке нет, там итак неиспользованного места полно остаётся в бутблоке - смысла упаковывать у разработчиков не было
с пробованием разных SPI микросхем всё упирается в программатор
у меня доступен пока что только Мастер-02 с кроваткой PLCC32

10 Окт 2010 - 22:07 maco

Сказочник >> 27069 >> 1742.14

Относительно программатора - в этом же разделе есть темы, посвященные простым программаторам SPI - собираются элементарно.

13 Окт 2010 - 19:55 sush

>> 14

Разобрался с этим моментом.

Дело обстоит так:
в бутблоке только ищется файл образа на накопителе и копируется вместо копии BIOS в ОЗУ
(а я то думал раньше, зачем выполняется повторное создание структуры модулей на базе копии образа.... теперь всё встало на свои места! всему есть причина!)
потом уже в новом биосе ищутся модули 08 и 1B и дальше работа идёт с ними
пока не наступает POST_37_2 (в моей нумераци), где проверяется нужно ли перепрограммировать BIOS той самой копией BIOS
и если нужно, то перепрограммируется и потом hard reset и всё, работаем на новом биосе!

у амишника осталось мало тёмных мест)))))

Вход на сайт

Аварийное восстановление AMI BIOS

Отправить комментарий