Работа BIOS-а

Всем доброго дня.
У меня есть несколько вопросов.
1. В каком режиме работает процессор, когда выполняет системную BIOS? (как я понимаю в 16-битном реальном режиме)
2. Какими ПО лучше пользоваться, для отладки своего приложения, которое будет изначально работать в 16-битном реальном режиме, а потом переключаться в 32-разрядный?

 

Эмуляторами типа bochs

 

Aleksey_K,

1. Точно это могут сказать только авторы BIOS. Логично предположить что для реализации функций работы с extended памятью (int15/87) защищённый режим временно используется, как и для теста памяти при POST. Также имеются 16- и 32-бит интерфейсы защищённого режима для APM/SMBus/PCCard/PCIBIOS, так что всё неоднозначно. Но в большинстве случаев — в RM.

2. Я использую отладчик из Bochs.

 

а он по исходникам умеет олаживать?

 

EFiR

нет

 

Он умеет грузить символы. Мне большего из исходников на асме не особо и нужно.

 

Aleksey_K

Начинает работу в реальном режиме, однако значительная часть кода (скорее, даже большая часть) работает в защищённом и режиме управления системой (SMM).

 

Спасибо всем за ответы, есть еще один вопрос - операционная система в которой производить отладку.

В данный момент решил посмотреть как работает аналогичная программа (начинает в RM потом периодически переключается в PM и обратно), но тут получается следующее. Запускаю программу в дебагере, и когда выполняется команда перехода в PM компьютер уходит в перезагрузку.
ОС - PTS-DOS
Дебаггер - DBGR

Как отлаживать подобные ситуации?

 

Как уже сказали -- отлаживать можно в *nix/Win с помощью Bochs (http://bochs.sf.net). Bochs дает довольно информативное описание причин перезагрузки.

 

Mika0x65

Беда в том, что утилита которую трассировал запускается только под DOS 6.22

Сейчас нашел аналогичную утилиту, работающую под Win. Загружаю ее в IDA (5.5.0.925t). Там есть два локальных дебагера.
Local Win32 debugger и Local Bochs debugger (поставил версию 2.4.5). Так вот первый дебагер работает, только довольно заметно грузит систему после третьего-четвертого старта отладки. А вот при запуске Bochs отладчик грузиться, но тут же вылетает с ошибкой "Failed to inspect register!" А оценить охота, так разрекламировали...

Никто с подобной проблемой не встречался?

 

В качестве альтернативы могу присоветовать qemu. Он по умолчанию умеет показывать регистры и смотреть память (по физическим или линейным адресам) плюс по мелочи. Вроде как к нему подключается отладчик gdb, но я не пробовал.

 

Vic3Dexe
Я так понимаю qemu сможет сэмулировать мне процессор? Это конечно хорошо, но моя задача - разобраться с ethernet-контроллером находящемся на материнке. А если еще точнее - разобрать механизм обращения к прошивке этого контроллера. Вот и мучаю утилиты производителя.

Виндовская утилита позволяет делать тест установленной EEPROM, но сколько я ее не гонял в IDA, так и не понял где она обращается непосредственно к контроллеру. Она тупо берет из Винды несколько параметров устройства (Ven_ID, Dev_ID и еще пару), сравнивает их со своими внутренними константами и все! первое равно второму - ч.т.д. - тест успешен!

Досовская утилита более дельная, показывает свободное место в EEPROM, размер хранимых файлов и их адреса на EEPROM. Все вроде бы красиво, НО! Хз как ее отладить после перевода процессора в защищенный режим. Утилита упакованая, то есть после запуска она распаковавает какую-то свою часть, при запуске теста возможно распаковывает другую и т.д., но этого я уже не вижу - переход в PM - перезагрузка системы.

Хотел сделать дамп памяти с этой утилитой, когда вызывается только один тест - опять проблема. Дебагер DBGR некоректро запускается когда грузишь прогу с параметром. Вроде как дебагер работает, но вот прога, которая загружается не воспринимает параметр.

Может кто-нибудь поможет советом, как получить текст такой утилиты?

 

qemu эмулирует машину, так же как и бош и иже с ними.

 

А, стоп, или нужен просто отладчик без отрыва от реального железа? Тогда qemu мимо кассы, да.

 

Vic3Dexe

Все правильно понял, нужна работа с реальной железкой, находящейся на материнке.

 

Aleksey_K
Вообще-то эмуляторы эмулируют "голое железо", т.е. создают виртуальный компьютер, на котором ты можешь установить себе ДОС и отлаживать ДОС прогу штатным отладчиком эмулятора. И переход виртуального процессора в защищённый режим тебе не помешает.
http://ru.wikipedia.org/wiki/Сравнение_виртуальных_машин

 

Y_Mur

Если я тебя правильно понимаю, виртуальная машина, делает полную "виртуальную" копию железки на которую поставлено? Но как я понимаю он будет эмулировать мои обращения к контроллеру, а не выполнять их с реальным. Тогда возникает вопрос, что "ответит" виртуальный Ethernet контроллер, например при запросе на чтение прошивки?

 

Aleksey_K

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

 

Aleksey_K,

Должно быть, зверская защита на этой DOS-утилите стоит, если не удаётся её в IDA понять.

Если она ходит в PM, не готовый ли DOS-extender используется? Возможно, выложив её сюда (или ещё куда), получится выяснить, с чем её есть.

 

baldr

Вряд ли там, какая-то хитрая защита, скорее это просто отсутствие у меня опыта подобной работы.

Не знаю... утилита анализирует тип процессора, и если запуск происходит на 386-м (или если заставить утилиту так думать), то перехода в PM не будет, мы останемся в RM.

Если интересно, то вот эта утилита, правда не вся, без bin-файлов с дополнительными тестами. Запускается под DOS 6.22 или выше, работает с Ethernet-контроллерами Broadcom. Меня в ней интересует, все что связано с чтением данных на EEPROM подключенной к этому контроллеру.