Решил вынести в отдельную тему, хотя может можно было кинуть в теоретические вопросы. Ну если что , перекинте...
Облазил форум, многие темы посвящены конкретной плате, а у меня вопрос следующий.
Очень хочется просто прочитать BIOS. Не перезаписать, а просто прочитать. Да, уточнение, чтение на этапе загрузки, то есть осуществляется из кода BIOS платы расширения. Прочитав умные книги
, выяснил, что как минимум у AWARD и AMI BIOS отображается на область памяти (FFFFFFFFh - объем чипа BIOS). То есть возникает резонное предположение о возможности просканировать эту область памяти и соответственно быть отправленным южным мостом в чип BIOS (хотя может он уже в этот момент туда и не отправляет). Однако где-то в этой области возникают непонятки, в смысле, то ли что-то там отображается из внутренних регистров чипа, то ли код распакованного BIOS меняется после каждой загрузки, но в этой области памяти некоторые участки изменяются при перезагрузке, хотя остальные совпадают с образом, скачанным с сайта производителя. Кстати, как отображается память BIOS у других производителей, в том числе IBM? Кто дизассемблировал, подскажите!
В общем, вопрос следующий. Как можно просто прочитать BIOS на этапе работы самого BIOS ( то есть при выполнении BIOS платы расширения), можно ли разрешить чтение напрямую из флеш-биос путем программирования его регистров, можно ли как-то универсализировать эту процедуру, хотя бы в рамках одного производителя (используются может одни и те же регистры для разрешения чтения)??? Или это вообще гиблое дело???
Пожалуйста, высказывайте мнения, Все интересно!!!
Для доступа на чтение нужно выполнить следующие шаги.
1. Определить чипсет (северный + южный мост). Это универсальная процедура поиска PCI-устройств по коду класса/подкласса.
2. Настроить чипсет для доступа на чтение к адресам в конце 4-го гигабайта. Полностью зависит от конкретного чипсета.
3. Узнать размер прошивки. Это отдельная непростая песня из нескольких куплетов - настройка железа для чтения и записи, определение типа микросхемы ПЗУ посредством выполнения последовательности магических команд, определение размера прошивки по таблице "тип-размер".
4. Прочитать прошивку - универсальная процедура.
5. Вернуть прежние настройки чипсета.
Другими словами, здесь правила игры определяются разработчиками чипсетов (Intel и др.), а не биосописателями AWARD и пр.
Настаиваю на обратном. Учитывая простоту паскаля и примитивность исполнения кода uniflash - её как раз можно рекомендовать в качестве пособия для изучения.
В частности, при изучении всё того же uniflash сразу будет видна некорректность данного утверждения. Строго наоборот - единственно правильным методом есть ориентировка на специфику производителя BIOS, а не попытка реализовать "классический" подход (без учёта "платоспецифичных", ОЕМ-специфичных и т.п. особенностей). Как раз развитие данного подхода сделано в runiflash.
Очень рад, что откликнулись!
Strelets,
настройка железа для чтения и записи... Почему-то мне кажется, что на запись настраивать сложнее, чем на чтение, а меня интересует только чтение...
Кстати, размер BIOS примерно одинаков у всех, ну или его можно задать в процессе работы программы, единственно , что выдаст BIOS при обращении к адресу, в котором уже не лежит BIOS?? Если это отлавливается, то можно песню из нескольких куплетов :-) не писать и все упростить...
Упомянуты таблицы класс-подкласс, тип-размер... Откуда их можно взять или это дается разработчикам по запросу к фирме производителю?
Вообще, по каждому пункту есть вопросы, может подскажет кто-нибудь ссылки на литературу, статьи ...Чем больше, тем лучше... Окромя Салихана (Pinczako), его почти всего заботал :-) Желательно с примерами работы с регистрами южных и северных мостов...поближе к этим пяти пунктам
Хочу вплотную занятся этим вопросом, покопаться для разных линеек BIOS (правда, я так понял проект Uniflash заглох... но и мне то нужно только считывать...:-)
Savely и Apple_rom, спасибо за идею, сейчас попробую поискать в инете исходники, (напишу сразу, если не сложно, скиньте ссылку, а то вдруг не найду :-))
apple_rom
<font size="1">> Настаиваю на обратном
</font>
Мягко говоря, нет уверенности, что uniflash/runiflash, будучи перенесенными в биос платы расширения, позволят читать любые биосы. Можно, конечно, искать в биосе сигнатуры типа "ASUS_FLASH" или "@AWDFLASH" и пользоваться биосными хуками для доступа к ПЗУ.
Но это тоже далеко не универсальный подход. Тот же AWARD имеет полное право изменить в ближайшем будущем формат своих биосов, что приведет к резкому ухудшению настроения у уважаемого lsvmo, который (предположим) легкомысленно понадеялся на мощь и красоту uniflash для чтения биоса.
А что делать с биосами других "менее продвинутых" производителей, о которых не ведает uniflash? Возвращать платы расширения для перепрошивки их биосов?
Так что мое мнение остается грустным. Универсальной читалки биосов не существует ввиду отсутствия биосных стандартов в этой области.
<font size="1">> Вообще, по каждому пункту есть вопросы
</font><font size="2">Мой ICQ 85199478. Стучитесь, расскажу всё, что знаю :)</font>
Я не говорю про универсальность, я говорю, что это единственно верный путь. Все остальные - заставят очень быстро остыть, как только на практике окажется, что большинство использует защиту от прошивки, что автоматически делает бессмысленными "классический" подход. Это собственно то, на что напоролся в своё время uniflash, когда начиная с Pentium3 стал шить резко меньшее количество систем, а на P4/K7 и совсем издох. В то время, как с минимальными манипуляциями теперешний runiflash работоспособен на всех системах вплоть до SPI-шных.
apple_rom,
что Вы подразумеваете под "классическим" подходом и подходом в стиле "<font color="#0000ff">runiflash</font>"?
Правильно ли я понимаю, что в Вашем представлении классический подход - это ручная настройка чипсета, в то время как <font color="#0000ff">runiflash</font> делает это (попутно снимая защиту от записи) посредством вызова существующих биосных хуков?
Именно такая философия изначально и заложена в uniflash (когда отсутствует пункт снятия защиты от записи и других ОЕМ-специфичных вещей). Сначала это было (и в некоторых случаях остаётся) его главной сильной стороной. Но с развитием стало понятно, что не всегда такой алгоритм срабатывает. В результате постепенно добавилось считывание DMI для реализации "конкретно-платозависимых" процедур размапливания, для AMIBIOS старых ядер добавились его функции/прерывания по прошивке и т.п. В то же время - правильным было бы не (с)только изучать регистры, нужные для размапливания, но и заточить под известные структуры а-ля AWDFLASH, ASUS_FLASH сотоварищи. Подобный подход, понятно, не позволит (напрямую) шить Phoenix, Insyde и т.п., однако закроет вопрос по Award и AMI, что для наших широт - весьма значимый процент. Именно это - прошивка посредством упомянутых "хуков" и было сделано в runiflash - в противопоставление используемому по умолчанию "классическому" способу.