Разбираю код биоса мат. P4P800, дошел до перехода в защищённый режим и наткнулся на код 2E 0F 01 16 C8 03 IDA пишет lgdt fword ptr cs:unk_F03C8, немогу понять роль префикса?, если опкод 0F 01, почему операнд 3х байтный?, что за цифра 16?, если должнобыть или 16 или 32,(CS текущий сегмент), Если верить IDA то на F03C8 начинается GDT, но там 20 00 C0 03 0F 93 00 00 FF FF 00 00 00 93 00 00, вторые 8 байт очень похожи, но 0 таблица заполнена - так и должно быть?, я думал там нули... После установки CR0 стоит E9 00 00 ( jmp $+3) - немогу понять куда прыгаю, а также как вести себя с этой команды: запоминать адрес, перегружатся в 32 разрядном режиме или оставатся в 16 - на команды режим ну ни как не влияет.... Есть ищё 1 млн вопросов и 1 тележка, сам постораюсь найти ответы , но тут я застрял и никак не сдвинусь помогите!
Префикс, надо полагать, выполняет свою обычную роль: указывает процессору, что за данными надо обращаться к сегменту кода, а не данных. Полную расшифровку кода команды надо смотреть в интеловской документации, лично мне лениво: Вам же нужно, вот и почитайте мануал, там всё подробно и даже более-менее внятно описано. В нулевом элементе ГДТ, по идее, можно хранить всё, что угодно: процессор не допускает обращения по нулевому селектору автоматически, а соответственно, не нуждается в информации из нулевого элемента. Насчёт перехода дизассемблер всё внятно написал: переход на 3 байта вперёд от текущей позиции. Поскольку код команды занимает тоже 3 байта, произойдёт переход на следующую команду. Кстати, не факт, что дизассемблер адекватно будет проводить дизассемблирование и дальше, если был перезагружен ЦР0, тут надо собственную соображалку включать да проверять, правильно ли он работает...
"указывает процессору, что за данными надо обращаться к сегменту кода, а не данных" - это я немогу понять, у меня вроде как бы ещё нет сегментов(по различиям), я думал lgdt какимто образом переписывает адрес текущего сегмента в GDTR но нигде не нашол про такое использование. По документации "0F 01 /2 LGDT m16 & 32 Load m into GDTR" 4 или 6 байт. Если переход нат 3 байта вперёд, не проще было забить 3 пустые операции или вообще его удалить, разве там нужна временнай задержка?
Debris Сегменты в 16- и 32-разрядных режимах есть всегда. Изучите для начала реальный режим, ведь переход в защищённый выполняется из реального. И вообще, лучше и не помышляйте о дизассемблировании БИОСа без твёрдых знаний и реального режима, и защищённого, плюс неплохого понимания принципов работы "центральной" периферии типа контроллеров прерываний, таймеров, плюс наличия представления о том, что такое SMM, нафиг оно нужно и как работает, плюс хотя бы поверхностного знакомства с PnP, ACPI и т.д... Ведь всё это активно используется в БИОСе или им реализуется. Пы.Сы. Как по мне, так проще качественно дизассемблировать ядро Винды, чем БИОС.
Лень смотреть в руководство, но код вполне понятный: 2E - префикс 0F 01 - двухбайтовый опкод 16 - байт ModRM C8 03 - 16-разрядное смещение 20 00 C0 03 0F 93 00 00 - это явно дескриптор. lgdt должна ссылаться на образ GDTR в памяти, находящийся по адресу cs:3C8h. Может не полагаться на то, что пишет IDA, и самому вычислить этот адрес, исходя из текущего значения cs. Внутрисегментный переход ни на что не влияет - код остается 16-разрядным, база сегмента прежней, хотя формально вы уже находитесь в защищенном режиме.
Кстати нет! Может быть (одновременно?) и образ GDTR, т.к. 16-разрядная lgdt использует только 3 младших байта базового адреса, т.е. базой GDT будет 0F03C0h, а 93h будет проигнорирован. Немного смущает значение лимита (20h) - правильнее 1Fh, но это распространенная ошибка даже среди профессиональных разработчиков - она не очень критична.
Тут дело не в задержках. Правило перехода в защищённый режим (и обратно) гласит: Следующей командой после изменения флага в CR0 обязательная должна быть JMP. Только обычно это дальний джамп, с указанием нового сегмента кода. Фактически измение режима происходит после этого джампа. Первая инструкция, на которую переходит этот джамп выполняется в новом режиме. Чтобы хорошо разобраться как это всё работает, лучше самому написать программу, которая будет переключать режимы процессора, устанавливать и обрабатывать прерывания, использовать APIC, и прочее. Чисто в теории это сложновато, нужна практика...
dinoweb Вообще, там должен быть именно дальний переход. Режим-то уже переключен (он переключается именно изменением CR0), а вот новый дескриптор кода не загружен, и действует старый, для реального режима. Из-за этого и нужен дальний переход, который перезагрузит CS.
Я тоже уже много где читал про дальний переход, но имеем что имеем, правда разбираю файл биоса скачаный на маттеринку с нета не факт что он рабочий и не повесит мать..., а скопировать с биоса я ещё не знаю как (что б копатся в рабочем), а насчёт практического программирования то же нужно ведь код прошивать в биос да и как наблюдать разве только через порт ошибок если вставить карту...., был бы какойнибудь симулятор проца.. но я такого неслышал... остаётся толко теория потом подвешеная мать и вырваные волосы на голове....
Так получается до дальнего перехода код работает по базе оставшейся от реального режима в теневом регистре... тогда опять же зачем этот джимп сюда влепили...эх
если пытатся ставить дискеты..., то система уже инициализирована и работает стандартно, а мне хотелось бы разобратся в работе компьютера с самого нуля когда он ещё не видит ни памяти ни видюхи ... и некоторые команды просто не смогут работать наскоко я понял допустим по причине что нет ещё стека...
Ваша идея ("разобратся в работе компьютера с самого нуля когда он ещё не видит ни памяти ни видюхи"), несмотря на всю привлекательность, фактически недостижима. Часть оборудования ПК зависит от производителя материнки, а свои секреты они не раскрывают. Например, нет подробностей, касающихся управления электропитанием процессора, памяти и микросхем чипсета -- а между тем всем этим заведует код BIOS, работающий в режиме SMM незаметно для остальных программ, выполняемых на комьютере, включая ОС (ну, за исключением неожиданных потерь времени на выполнение кода SMM вместо нормальной работы). Нет полной ясности с определением оборудования, установленного на системной плате (гарантированно можно узнать лишь об устройствах, поддерживающих PnP, поскольку там всё стандартизировано, но вот, например, о реальном наличии или отсутствии COM-портов можно только догадываться: даже если их контроллер физически присутствует, сами порты могут быть не распаяны, что практически равносильно отсутствию портов). БИОСу в этом плане проще: он заранее "знает", какие железяки имеются и как с ними работать (ведь БИОС "затачивается" под конкретную плату со всеми её особенностями). Даже с процессорами полной ясности нет, поскольку у них имеются моделезависимые регистры (MSR), которые производителями описываются не полностью. Ну и т.д. и т.п. -- и это не говоря об объёме информации, которую необходимо изучить, чтобы хотя бы приблизиться к достижению заявленной цели. Инициализацию можно повторить всегда, за исключением повторной инициализации кой-каких вещей, связанных с режимом SMM: в чипсетах бывают защёлки на это дело, которые не дадут сменить однажды установленную конфигурацию. Кстати говоря, какое отношение к этому имеет ДОС? Любая система грузится БИОСом, и ничто не мешает вместо системы подсунуть свою собственную программу: БИОСу-то абсолютно без разницы, что загружать. И ещё. Если уж имеется такой интерес к низкоуровневым глубинам, то зачем изучать именно ПК, тем более что время этой платформы, похоже, постепенно подходит к концу? Во всяком случае, в мобильных устройствах используются процессоры архитектуры ARM, уже появляются нетбуки и ноутбуки на них, Микрософт тоже не зря решила подсуетиться и выпустить следующую Винду не только под ИА-32, но и под АРМ... Правда, у ПК есть достоинство: он всегда под рукой, а игрушку с АРМом ещё купить надо (всякие телефоны в силу ряда причин для изучения подходят плохо)...
очень интересно особено про арм, щас поищу, а вообще думал мать то состоит из стандартных микросхем производители материнок их по всему миру закупают, так что даташит на всю начинку матери по элементам собрать та можна остаётся разобратся только как они это всё сгрупировали вот тут то биос и стоит колупать притом разобравшись в 1 матери думаю %80 буду знать от любой матери х86. Насчёт платформы это печально я не думаю что она так скоро загнётся под нё ведь стоко сделано, люди до сих пор 386 пользуются, а мощные ещё лет 30 точняк прослужат... насчёт купить это да.... притом купить и поламать мечта любого.... С инфой про MSR уже столкнулся, и немного не понимаю политику intel всегда на любой электроный элемент выходила куча инфы как с ним работать для быстрого внедрения а тут секреты..., правда они продают книги по заоблачным ценам для разработчиков, может как-нибудь подкоплю.
Debris Хотя основу матери составляют стандартные микросхемы (чипсет, почти всегда от производителя процессора, плюс несколько хорошо известных микросхем, отвечающих за древние интерфейсы типа RS-232 (COM-порт) и PS/2, плюс, возможно, контроллеры локалки, УСБ 3.0 и т.п.), есть ещё целая куча вещей, которые обычно не замечают и которые могут сильно изменяться от производителя к производителю; в первую очередь это как раз то самое управление вентиляторами и электропитанием. Особенно это заметно сейчас, когда все, кому не лень, извращаются со всякими дурацкими технологиями энергосбережения (которые нередко только повышают суммарный расход энергии). Вся эта фигня обычно никак не документирована, но ведь её надо должным образом обслуживать, чтобы плата работала, причём, грубо говоря, половина кода БИОСа как раз и занимается работой с недокументированными или частично документированными вещами. Что касается MSR, то они нужны только разработчикам БИОСов. Кроме того, они могут постоянно меняться даже в пределах одного семейства процессоров. Поэтому, наверное, Интел и не стала открывать эту информацию, предоставляя её лишь тем, кто реально в ней нуждается. Обычным осеписателям MSR даром не требуются, не говоря уже о разработчиках прикладного ПО. В общем, лично я думаю, что затея эта -- не совсем пустая, но в целом бесполезная трата времени. Куда лучше было бы хорошо освоить процессор, а то у Вас, судя по предыдущим постам, весьма смутное представление о многих базовых вещах типа работы механизма сегментации или кодирования команд. Речь, естественно, не о том, чтобы всё это наизусть выучить, но чтобы понимать без проблем.
