на чём написан BIOS и можно ли его програмно «покоцать&
19 лет на сайте
пользователь #5422
20 лет на сайте
пользователь #1281
С такими вопросами тебе его только плоскогубцами «коцать».
19 лет на сайте
пользователь #2148
учите ассемблер, товарисчи, 
20 лет на сайте
пользователь #1595
20 лет на сайте
пользователь #525
У меня можно УФ покоцать, да так что и вовсе не будет
19 лет на сайте
пользователь #5422
а я гдето видел что он на С какомто написан но страшно не уверен потому что не помню источникак!
Kamkad3,e а ты уверен?
19 лет на сайте
пользователь #2887
Ох. Ну люди, вы такими вопросами иногда просто убиваете.
Написан он может быть на чем угодно. Все равно в машинный код компилируется. Хотя, учитывая специфику выполняемых им функций писать его лучше на ассемблере. Покоцать можно. Для этого необходимо чтобы БИОС хранился на перепрограммируемых микросхемах (в старых мамах были или совсем не перешиваемые, или перешиваемые тольок программатором). Интерфейс к управлению FlashBIOS ищите на сайте Intel. По крайней мере два года назад я такое там видел.
Только зачем все это? Повторить Вин ЧИХ?
19 лет на сайте
пользователь #2148
люди учитесь на фпми, там на первом курсе ассемблер читает, страшный дядка, которо зукой кличут, 
19 лет на сайте
пользователь #4841
20 лет на сайте
пользователь #1254
19 лет на сайте
пользователь #2148
нет, там тебя никто не заставляет, но если ты сам хочешь ты очень многое узнаешь, а преподы тебе в этом помогут, ты только спрашивай у них,
. как говорицца Э было бы желание. Э
19 лет на сайте
пользователь #3813
kamkad3e, у нас Дубков читал. меня не сильно приколол.
20 лет на сайте
пользователь #1641
а я гдето видел что он на С какомто написан
Какой Си? Уже давно биусы на Вижуал Бэйсике пишут 
19 лет на сайте
пользователь #5333
Да, братцы, дела у вас плохи!
Ладно. Итак, двоичный образ BIOS-программы (написанной не важно на чем) хранится на BIOS-ИМС. Если она Flash или EEPROM, то ее можно перепрошить с помощью спецпрограмм или программатора. Короче, сначала этот образ нужно
Пишем для UEFI BIOS в Visual Studio. Часть 1 — разворачивание среды разработки, компиляция и запуск на отладку
Введение
Цель статьи — провести начинающего за руку по первому UEFI проекту, оставаясь в привычной ему среде. Для более опытных людей, надеюсь, будет интересным поработать в VS вместо привычной командной строки, или разобрать подход и перенести его в любимый Eclipse.
Начнем с простых вещей, вывода строки на консоль и русификации (довольно востребованная вещь, причем простая в реализации), потом будет работа с формами в HII (то, что называлось в обиходе страницами BIOS Setup), потом графика, потом Boot Manager, а потом видно будет (с).
Желающие — прошу пожаловать под кат.
Сейчас необходимо решить, оно вам надо или нет. Потратим на это пол-страницы на старте, чтобы не тратить пол-дня и в конце понять, что вам надо совсем другое. Или, надеюсь, наоборот — загореться энтузиазмом и выкроить время на прочтение статьи.
Вначале хорошее
2) Работать будем со всеми возможностями Visual Studio, т.е. доступны breakpoints, watch, step execution и остальное. Перекомпиляция и запуск несложного модуля занимает 8-10 секунд.
3) Файловая система виртуалки доступна на Windows-машине для записи-чтения. Очень пригодится, если надо будет редактировать скрипты UEFI Shell, после запуска посмотреть скриншоты и проанализировать логи средствами Windows.
4) Никакого ассемблера, только С/С++.
Теперь о том, что мы делать не будем
1) Мы будем работать в DXE (где уже есть UEFI Shell) и поздних фазах. В более ранние фазы не полезем, поскольку нас туда никто не пустит, по крайней мере – для Intel-процессоров. Позже будет объяснение, почему. Если хотите сделать полный цикл, от включения до загрузки ОС, причем быстро и не забивая голову кучей ненужной и неинтересной вам в данный момент информацией, а ручное конфигурирование системы вам совершенно не требуется – дальше не читайте, а наберите в Гугле «coreboot».
2) «Графического» UEFI с мышкой и кнопками, как у Dell, MSI и прочих, здесь не будет. Это платные среды, для использования в крупных компаниях. Есть, разумеется, энтузиасты, которые сами создают их своими руками, не ответив предварительно на вопрос «Зачем?», но обычно их энтузиазм заканчивается на второй форме с кнопками.
3) Мы будем работать с компилятором Visual Studio. Желающие могут настроить gcc в cygwin, или icc, но в данный момент не стоит задача получить оптимальный быстрый код, а стоит задача быстро пройти путь к началу полноценной работы.
Все, предварительные танцы закончены, кто надо – воодушевлен, кто надо – напуган.
Переходим к делу
Первым делом, скачиваем репозиторий в корень диска. Развернется он в с:/FW. Если каталог FW в корне диска уже наличествует, то лучше бы его переименовать, потому что все конфиги настроены именно туда в абсолютных путях. Не по фэн-шуй, но перфекционисты всегда могут поправить абсолютные пути на относительные, написав соответствующий скрипт, который это делает.
Итак, у кого на машине есть git в командной строке, выполняют команду в cmd окне (или в Far Commander, не суть) из корневого каталога:
git clone https://github.com/ProgrammingInUEFI/FW
а те, у кого нет, идут по ссылке на github, скачивают zip-файл и раскрывают его в каталог с:/FW.
Как было ранее обещано, приведем подсказку из Интеловского тренинга по использованию другой конфигурации, отличной от указанной в начале статьи. Ищите свое сочетание в табличке, если предлагаемое по каким-то причинам не подходит:
Конфигурирование среды для версии, отличной от VS2010
Открываем файл c:\FW\edk2\Conf\target.txt и в строчке
TOOL_CHAIN_TAG = VS2010x86
Заменяем VS2010x86 на тэг установленной у вас версии Visual Studio. Для Visual Studio 2010 тэг останется как есть, для других версий VS – смотрите картинку выше, или список в начале файла c:\FW\edk2\Conf\tools_def.txt
Собственно, среда разработки edk2 развернута полностью и в ней можно работать из командной строки. Некоторые так и работают всю жизнь («угорать по хардкору, поддерживать дух старой школы и всё такое» — (с) CodeRush в своей ставшей классической статье). Но мы все же пойдем дальше, пересаживать человека из MSVS обратно в командную строку — негуманно, особенно в 2017.
Настраиваем проект в Visual Studio
Открываем Visual Studio, в нем открываем Solution NT32.sln из каталога C:\FW\VS\NT32. В целях уменьшения времени входа в тему, в solution уже создан одноименный проект NT32, в котором уже сделаны описанные ниже настройки. Это если не получится создать самим – чтобы иметь гарантированно рабочие настройки проекта. Такой подход сильно сократит время поиска источника проблем, в случае их появления. Тем не менее, лучше пройти описанный ниже путь самим, и понять смысл настроек – это облегчит настройку следующих проектов.
Полезно будет сразу в Tools->Options настроить рабочий каталог на c:\FW\VS, но если в VS ведется другой, рабочий проект, то так делать не надо:
Создание проекта
Создаем в Solution NT32 новый проект для Visual C++ (правой клавишей на Solution NT32, Add->New Project, выбираем опцию Makefile Project), и назовем его MyFirstUEFIProject (или как угодно еще). Жмем Finish.
Выбираем в Solution проект NT32, выбираем из контекстного меню Project->Properties и производим настройки проекта.
Настройка NMake опций
Выбираем в окне слева строку Configurarion Properties → NMake, в окне справа — строку Build Command Line
Жмем Edit… и в открывшемся текстовом окне вводим:
Сейчас стоит немного объяснить, что мы делаем. По сути, мы пишем в этом окне обычный пакетный bat-файл вместо makefile.
В первой строке устанавливается переменная окружения ассемблера NASM_PREFIX в том виде, как ее понимает edk2, то есть путь, по которому лежит файл nasm.exe. На ассемблере мы сами писать не будем, но нашей системе сборки ассемблер нужен обязательно.
Во второй строке вызывается скрипт настройки среды edk2 и настраиваются переменные окружения для данного сеанса компиляции и запуска (вне VS эти переменные не отражаются). Ключ –nt32 указывает системе сборки, что компилировать исходники надо для пакета (package) Nt32Pkg, расположенного в C:\FW\edk2\Nt32Pkg. Этих пакетов там много, мы их рассмотрим, но не сейчас.
В третьей строке мы даем команду на компиляцию в только что настроенной среде (build.exe лежит в C:\FW\edk2\BaseTools\Bin\Win32, этот путь прописывается в предыдущей строчке, в edksetup.bat)
Итак, вот что у нас должно появиться в итоге в текстовом окне Build Command Line:
Затем вводим в следующей строке Rebuild Command Line в открывшееся по Edit … окно следующий текст
Команда build clean означает то самое, что вы предполагаете. Она делает полную перестройку проекта с перекомпиляцией всех модулей.
Что мы вводим в окне из Clean Command Line, наверное, все уже догадались:
Честно говоря, особо эта опция не нужна, в 99% случаев хватит Rebuild, но пускай будет – например, очистить среду для ее переноса в другое место или заливки на github.
В итоге, у нас должно получиться вот такое окно:
Все с настройкой NMake.
Настройка опции Debugging
Итак, открываем строчку Debugging и вводим:
В строчке Command:
В строчке “Working Directory”:
SecMain.exe – объяснять сейчас, что это такое – долго, если очень кратко и упрощенно – то это аналог bootloader-a, который запускает все остальное.
Рабочий каталог – сюда будут помещаться все успешно созданные модули, и доступны они будут все сразу из командной строки.
Итак, вот что мы должны получить после настроек в этом окне:
На этом все с настройками проекта.
Построение проекта
Вызываем Build Solution, смотрим на экран примерно минуту, в течение которой есть наибольший риск быть обруганным компилятором, и идем пить кофе – создаваться это все будет 10-15 мин, в зависимости от ресурсов вашего компьютера. Ничто нудное не вечно, и в конце концов мы получаем сообщение:
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========
Если же вместо этого получено что-то иное, смотрите, правильно ли вы прошли все шаги. Наиболее тяжелый случай – получить:
LINK : fatal error LNK1123: failure during conversion to COFF: file invalid or corrupt
это баг среды VS2010 и означает, что VS2010 установлен без SP1. Поставьте SP1, или ищите способы затыкания этой ошибки в инете.
Если же получили ошибку и из сообщений компилятора не понятно, что это такое – переставьте дефолтный проект на NT32 и запустите его на компиляцию с отладкой. Если и там ошибка – проверьте еще раз соответствие TOOL_CHAIN_TAG предопределенным значениям, описанным в tools_def.txt. Больше ничего там упираться не может, разве что сам Visual Studio установлен, хм, не вполне стандартно, или использует сторонний компилятор.
Работа в UEFI Shell
Итак, все скомпилялось хорошо, и вы читаете эти строки. Теперь жмем на любимую F5 и после примерно минуты работы с диском (чуть позже сократим и это время) получаем вот такую требуемую картинку:
Собственно, это и есть UEFI Shell. Как в нем работать – написана куча руководств, посмотрите в Гугле, а мы пока сделаем в нем несколько вещей.
1. Смотрим, что мы там накомпиляли за эти 10 минут. Вводим fs0: (UEFI Shell нечувствителен к регистру) и затем ls –b, где опция –b означает ожидание нажатия Enter для прокрутки страницы, ибо список там большой, не на один экран.
Теперь стало понятно, что означал параметр “Working Directory” в настройке опций проекта Visual Studio — C:\FW\edk2\Build\NT32IA32\DEBUG_VS2010x86\IA32\. Там этот же самый список файлов, и лучше его смотреть (и редактировать скрипты) через развитую оболочку Far Commander (или Total Commander), чем с командной строки в UEFI Shell.
2. В UEFI Shell и набираем “hel”, жмем Tab и видим на экране Helloworld.efi. Не то, чтобы мы совсем не догадывались, что будет, если нажать после этого Enter, но проверить-то надо! Жмем и получаем троекратное UEFI Hello World!. Число повторений – это конфигурируемый в настройках среды (а не в исходниках) внешний параметр и мы будем эту конфигурацию потом разбирать.
3. Набираем exit и попадаем в наше любимое и знакомое окно:
Ну вот, можно любоваться на плоды своих трудов. После этого стрелками гоним фокус на Reset и виртуалка закрывается, возвращая нас в знакомое окно MSVC.
Выводим свою строку
Создание полностью своего приложения потребует достаточно много настроек, которые лучше будет рассмотреть в следующей статье — иначе получится большой объем, а длинные простыни никто не читает. Однако же в заголовке этой статьи написано «Программирование», а мы пока занимались только настройкой. Чтобы сдержать обещание, давайте в этой статье сделаем очень простую модификацию приложения HelloWorld, используя его имеющийся набор файлов, а в следующей статье создадим свой, при помощи Интеловской утилиты UEFI Driver Wizard, поскольку прогонять начинающих по полному циклу создания набора файлов для UEFI драйвера (или приложения) — это нечеловеколюбиво, дико рутинно и несет риск потери 90% аудитории. Если человека зацепит — он сам к этому придет со временем, а если хочется просто поиграться — нет смысла тратить на это кучу времени, благо многое давно уже делается автоматически через UEFI Driver Wizard, причем по фэн-шуй, чего от новичка ждать наивно.
Итак, открываем в Visual Studio файл
C:\FW\edk2\MdeModulePkg\Application\HelloWorld\HelloWorld.c
И добавим свою простую строчку, сразу после объявления переменных в единственной функции:
Разумеется, текст можно заменить на что угодно, только английскими буквами — русский шрифт edk2 еще не понимает, мы добавим его в следующих статьях. Можете поставить на эту строку обычный breakpoint и посмотреть, как себя поведет Visual Studio.
Жмем F5, после компиляции и устранения ошибок вводим «fs0:», HelloWorld.efi и получим такой вывод:
На этом все. В следующей статье мы немного поработаем в UEFI Shell, чтобы освоиться, и разберем немного теории.
Какой язык программирования используется для написания программы BIOS?
Как я понимаю, код / битовый поток BIOS, который содержится в ПЗУ, должен быть общим (работать вместе с несколькими типами процессоров или ISA). Кроме того, я увидел упомянутое в сети, что можно сбросить его код (и «разобрать» его).
Итак, на каком языке, в наборе команд или в машинном коде написано? Разве ему не нужен какой-либо процессор для выполнения своих операций? Если да, то я предполагаю, что он будет использовать внешний процессор, тогда как он узнает конкретный набор команд используемого?
Может быть, у него есть внутренний процессор?
БИОСы были написаны исключительно на ассемблере, но переход был сделан давно, чтобы написать большую часть кода на каком-либо языке более высокого уровня, и оставить на ассемблере как можно меньше его частей, предпочтительно только загрузчик, (первые несколько сотен инструкций, к которым процессор переходит после запуска / сброса) и все подпрограммы, связанные с конкретными особенностями базовой архитектуры.
BIOS уже писались в основном на C еще в начале девяностых. (Я написал BIOS на 90% C, сборка 10% в начале девяностых.)
Что также очень помогло в этом направлении:
Библиотеки C, предназначенные для конкретной архитектуры и включающие функции для работы с особенностями этой архитектуры, например, функции для чтения / записи байтов в / из портов ввода-вывода архитектуры x86. Microsoft C всегда предлагал библиотечные функции для такого рода вещей.
Компиляторы C, которые не только нацелены на конкретную архитектуру ЦП, но даже предлагают расширения для языка С, которые можно использовать для написания кода, использующего специальные функции ЦП. Например, архитектура x86 поддерживает вещи, известные как прерывания, которые вызывают подпрограммы, известные как обработчики прерываний, и требует, чтобы они имели специальные последовательности команд входа / выхода. С самого начала Microsoft C поддерживал специальные ключевые слова, которые можно было использовать для обозначения функции как обработчика прерываний, чтобы она могла вызываться непосредственно прерыванием ЦП, поэтому вам не нужно было писать для нее какую-либо сборку.
В настоящее время я предполагаю, что большая часть BIOS написана на C ++, если не на каком-либо языке более высокого уровня.
Подавляющее большинство кода, составляющего BIOS, относится к конкретному аппаратному обеспечению, поэтому его не нужно переносить: гарантируется, что он всегда будет работать на одном и том же типе CPU. Процессор может развиваться, но пока он поддерживает обратную совместимость с предыдущими версиями, он все еще может работать с BIOS без изменений. Кроме того, вы всегда можете перекомпилировать части BIOS, написанные на C, для естественной работы на любом новом процессоре, который появится, если возникнет такая необходимость.
Причина, по которой мы пишем BIOS на языках более высокого уровня, чем на ассемблере, заключается в том, что писать их проще, а не потому, что они действительно должны быть переносимыми.
Возвращаясь к BIOS, я думаю, что также важно учитывать экономику выбранного языка программирования. BIOS обычно пишется как необходимость дополнять продажи оборудования. Известно, что современные системы BIOS в основном написаны на C и / или на ассемблере. Переход к другому инструменту привел бы к значительным затратам к тому, что обычно считается товарной продукцией, что может очень негативно повлиять на продажи. Не вдаваясь в экономику 101, я могу заверить вас, что, возможно, ОЕМ-изготовителю не стоит отказываться от проверенных временем инструментов, проверенных десятилетиями.
Конечно, есть и будут проекты для любителей писать BIOS. Похоже, что они тоже до сих пор выбирают C и / или сборку. Возможно, однажды будут использованы другие технологии. Но сегодня выбор четко определен.
newshitech
newshitech Hi Tech новости
Современный ПК невозможно представить без BIOS (англ. Basic Input-Output System – базовая система ввода-вывода, БСВВ) – программы, находящейся в ПЗУ (постоянном запоминающем устройстве) персонального компьютера и исполняющейся при включении питания. Главная функция BIOS – подготовить машину к тому, чтобы основное программное обеспечение (в большинстве случаев это операционная система), записанное на различных носителях (жесткий диск, дискета, компакт-диск или доступное через сеть), могло загрузиться и получить контроль над компьютером. ПК без BIOS – это как маленький ребенок, не умеющий даже разговаривать. Однако если компьютер как таковой появился еще в середине прошлого столетия, то сам BIOS несколько позже.
Твердое
Микросхем BIOS существует всего четыре типа: ROM (Read Only Memory) или ПЗУ, PROM (Programmable ROM) или ППЗУ (программируемое ПЗУ), EPROM (Erasable PROM) или СППЗУ (Стираемое ППЗУ), EEPROM (Electrically EPROM) или ЭСППЗУ (электронно стираемое ППЗУ), второе название – flash ROM. Именно в таком порядке, как перечислено, они и были разработаны. Начнем с самого старого типа – ROM.
Самые первые ПЗУ, как понятно из названия, были неперезаписываемые и представляли собой матрицу с выжженным программным кодом. Такой тип BIOS просуществовал очень недолго.
Первое ППЗУ было создано в конце 1970-х годов фирмой Texas Instruments. Его емкость составляла 2 Мбит. Принцип работы был крайне примитивен и основывался на том же самом «прожиге», что и ROM. Единственным отличием была возможность «прожига» в домашних условиях (при наличии специального оборудования). Сама микросхема могла быть записана только один раз. При необходимости обновления BIOS покупалась новая микросхема-болванка PROM и снова выполнялось нанесение кода BIOS’а.
Несколько позже на смену ППЗУ пришла EPROM. Отличий между ними было немного. Принцип работы, а также маркировки были идентичны. Единственное отличие заключалось в возможности стирания ЭСПЗУ. Сам процесс стирания был достаточно муторным. Для этого требовалось мощное облучение с длиной волны в 2.537 ангстрем и высокой интенсивностью в 12000 мВт/см2. Расстояние от источника облучения до микросхемы не должно было превышать 30 мм. Время экспозиции составляло от 5 до 15 мин. Для стирания записанной информации применялось специальное устройство. Еще один «девайс», как и в случае с PROM, был нужен для прожига требуемой версии BIOS.
Достаточно привычный тип микросхем BIOS’ов, а именно EEPROM получили широкое распространение только в 1994 году. Их основным отличием от «прадедушек» являлось отсутствие необходимости демонтажа с платы. Процесс перепрограммирования выполнялся посредством специализированных программных утилит и мог быть выполнен пользователем в домашних условиях.
MrBIOS от Microid Research
В своем раннем детстве базовая система ввода-вывода была не ребенком, а Мистером. Да-да, в самом начале был не BIOS, а MrBIOS. Именно так в 1986 году назвала свое детище компания Microid Research. История новорожденного Мистера началась с того, что Microid Research не успела «вклиниться» в стандарт PC AT/ATX. Впервые использование низкоуровневого ПО Microid Research было замечено в ПК i386. Первыми заказчиками стали такие компании, как DataExpert, Giga-Byte Technology, First International Computer, J-Mark Computer и некоторые другие.
Однако на рынке низкоуровневого ПО Microid Research не была одинокой. Развитие MrBIOS продолжалось наряду с массовым производством чипсетов компанией OPTi. Для каждого чипсета Microid Research разрабатывала новую версию MrBIOS. Но монопольной ситуации здесь не возникало ввиду сотрудничества OPTi с American Megatrends, Award Software и Systemsoft. Тем не менее, именно Microid Research в те годы была бесспорным лидером на рынке «прошивок».
Универсальность MrBIOS’а как такового была заложена в первые же годы его жизни. Программный код детища Microid Research не рассчитывался на индивидуальные особенности того или иного чипсета. Это давало возможность легкой адаптации продукта для целого ряда устройств. В конечном итоге в список клиентов Microid Research попадает Ocean Technology – гигант электронной индустрии того времени. Если его имя тебе не известно, то мы приведем название торговой марки, под которым продавалась большая часть продукции этого производителя – Octek. В конечном итоге прибыль Microid Research от продажи MrBIOS’а удвоилась, ибо программный код, разработанный для одного и того же чипсета, продавался сперва OPTi а затем и Ocean Technology.
В условиях дороговизны разработки низкоуровневого ПО персонально под каждый чипсет без создания достаточной универсальности многие другие разработчики «прошивок», предназначавшихся исключительно для того или иного чипсета, потерпели крах. Это привело к пополнению списка клиентов Microid Research. В начале 90-х годов туда попадают малоизвестные компании: Contaq, Efar Microsystems, ETEQ Headland Technologies, Microsystems,VLSI Technology. Апогеем развития Microid Research в те годы стал контракт с IBM.
Компьютерный бум первой половины 90-х спровоцировал так называемую The First Big PC Price War – первую большую ценовую войну ПК. Набрав бешеные обороты производства, рынок компьютерной индустрии породил таких гигантов, как Intel, Tyan, Supermicro, Asus. Это стало началом конца Microid Research и MrBIOS’а. Крупные производители вполне могли себе позволить «одноразовую» покупку низкоуровневого ПО с последующей адаптацией оного собственными силами. Далее в условиях конкуренции появилось понятие бесплатного обновления BIOS, которое разрабатывалось компанией-изготовителем материнских плат (а именно здесь в то время, да и сейчас, BIOS получает наибольшее распространение). Такая ситуация вынудила Microid Research «сдать» свои позиции. Несколько лет спустя при обращении на сайт www.mrbios.com происходит переадресация на www.unicore.com. Это дает основания полагать, что именно компания Unicore Software стала последним приютом MrBIOS’a…
Завершая наш рассказ о MrBIOS’е как о «праотце» современного BIOS’a, отметим основные преимущества программного кода Microid Research над конкурентами тех лет. И здесь есть чему удивиться. Для временного хранения данных использовались страничные регистры DMA – на то время реализацию временного хранилища именно таким образом можно характеризовать как новаторскую. Примечательна поддержка двух каналов FDD-контроллера, что дает возможность подключения четырех дисководов. Потребность в таком количестве достаточно медленных и малоемких носителей информации, конечно, сомнительна, но тем не менее. А вот что действительно интересно, так это реализация поддержки четырех (!) IDE-каналов, что обеспечивает возможность подключения восьми винчестеров или оптических приводов. Так, если современные BIOS’ы поддерживают только Primary и Secondary каналы, то «Мистер старичок» может похвастаться еще Tertiary и Quartery. И даже более. Когда, как ты думаешь, появилась поддержка RAID-массивов? В 1996-ом году. В то время никто из конкурентов не мог предложить полный конкурентоспособный аналог. Однако техническое превосходство MrBIOS’а подложило ему «свинью». Опередив время предложением невостребованных в те годы функций, MrBIOS утратил возможность конкурировать по цене. Осенью 1998 года Phoenix Technologies поглощает Award Software и несколько позже провоцирует продажу Unicore, владельца Microid Research на то время, компании Touchstone Software. С учетом сотрудничества Touchstone Software с Award Software судьба MrBIOS была решена не в пользу оного…
Phoenix Award от Phoenix Technologies
Несмотря на то, что старт эпохи BIOS’а принято ассоциировать с MrBIOS, компания Phoenix Technologies начала первые продажи низкоуровневого программного кода раньше, чем Microid Research, на три года. Несмотря на явное превосходство MrBIOS’а на заре «прошивок», целый перечень канонов «биосостроения» был создан именно Phoenix Technologies, поэтому в данном разделе мы сосредоточимся на самых интересных аспектах различных разработок Phoenix в области BIOS’ов.
Уникальное новшество было анонсировано осенью 2003 года. Имя ему – Phoenix TrustedCore NB. Phoenix TrustedCore NB позволяет управлять настройками BIOS’а удаленного ПК по сети. При этом наличие ОС на администрируемом ПК вовсе не обязательно – поддержку сети полностью обеспечивает TrustedCore NB. Таким образом, системный администратор получает удаленный доступ к базовым настройкам компьютера даже в случае, если операционная система вышла из строя.
Еще одной новаторской разработкой Phoenix является система Core Managed Environment. Предназначена она для создания некой резервной области на жестком диске, куда в случае сбоя операционной системы могут быть сохранены все нужные данные. Разумеется, если речь идет о сбое ОС, то все функции резервного сохранения данных реализованы сторонними средствами: в данном случае, самой системой Core Managed Environment и специальной кнопки «panic». Название последней с учетом ее функций не может не вызывать улыбку :-). По механизму действия CME схожа с другими восстанавливающими программами, такими как Roxio’s GoBack или утилита Windows XP System Restore. Настройки системы резервного сохранения данных изначально задаются изготовителем ПК и впоследствии могут быть изменены пользователем по его личному усмотрению. При этом следует понимать, что Core Managed Environment никоим образом не может претендовать на звание полноценной замены ОС – это не более чем «продвинутая примочка». На данный момент распространение оной весьма невелико… Ценовой аспект внедрения этой технологии сдерживает экспансию на рынок. Тем не менее, готовность поддержать описанную новацию выразили Founder Technology, Grid Technology Partners, Legend, National Semiconductor, Samsung и Transmeta.
Ну и наконец осветим сочетание слов Phoenix и Award. В 1998 году Award Software была куплена Phoenix Technologies, и под словом Award понимается ничего более, чем просто торговая марка.
AMI BIOS от American Megatrends Inc.
Говоря о AMI BIOS, сразу хочется начать с основной изюминки программного продукта этой фирмы – модульности. Данная концепция, известная под названием Modular BIOS, в свое время была подхвачена практически всеми разработчиками низкоуровневого ПО. Идеология здесь простая: основной разработчик BIOS’а, то есть в данном случае AMI, пишет ядро (core) BIOS’а. Окончательную адаптацию с помощью специальной утилиты AMIBCP (BIOS Configuration Program) под конкретный чипсет выполняет фирма-покупатель BIOS’a.
Первой ласточкой стал AMIBIOS Plus. На сегодняшний день в современных версиях программного кода AMI от самой первой версии практически ничего не осталось. Первой версией AMI BIOS, в которой имелись долгосрочные изменения, прослужившие добрый десяток лет, стала Core 2.x. Именно здесь впервые появились такие существующие и по сей день разделы, как Configure BIOS Features, Configure CMOS Setup и Configure BIOS Setup.
Двумя годами позже впервые в истории биосостроения American Megatrends представила миру BIOS с графическим интерфейсом – WinBIOS (AMIBIOS Core 3.x). За ненадобностью такого «наворота» WinBIOS широкого распространения не получил и тихонько развивался в стенах породившей его компании наряду со стандартным текстовым интерфейсом HiFlex.
В 1994 году выходит в свет AMIBIOS95 Core 4.x. Из основных нововведений отметим следующие: поддержка старта Windows 95 и Flash ROM. Последняя новация дала старт новой эпп5е BIOS. За обновлением BIOS’а системной платы теперь мог следить сам пользователь. Кроме того, здесь был реализован обобщенный подход к инициализации устройств на всех типах шин посредством Device Initialization Manager (DIM).
Год спустя появляется AMIBIOS95+ Core 5.x с внушительным перечнем мощнейших изменений: поддержка многопроцессорных систем согласно MPS v1.1, поддержка спецификации PCI v2.1 и разветвленных PCI-шин, управление энергосбережением APM 1.1, автоопределение жестких дисков и режимов их работы (PIO), поддержка соединения по инфракрасному порту (IrDA).
Модульная система была усовершенствована с выходом AMIBIOS Core 6.x. Здесь стоит отметить преемственность кода в части контрольных точек, загрузочного блока и процедур инициализации с помощью DIM-менеджера, а также четкую идентификацию блоков программного кода с помощью меток.
Последней версией XX века низкоуровневого ПО American Megatrends стал AMIBIOS Core 7.x. Наиболее существенные новшества здесь следующие: PC2001, WfM 2.0 и Enhanced Disk Drive Secure Boot 3.0. Примечательным фактом, связанным с выходом упомянутой версии BIOS, стал дебют модуля ezPORT, который обслуживает пользовательское меню. Именно он разрешил интерфейсный спор между WinSetup и HiFlex в пользу последнего. Кроме того, в Core 7.x появляются LBA-48, а также целый перечень доработок в таких модулях, как CPU-4.24, GreenPC-1.11, APM-1.2/1.11 и USB-1.30.
AMIBIOS 8 вышел в свет в октябре 2001 года. Помимо очередных усовершенствований отдельных частей программного кода, немало было сделано в плане повышения безопасности перепрошивки BIOS’а пользователем. Здесь речь идет о двух вещах: Flash Update и BIOS Recovery. Если при старте контрольная сумма не совпадает, автоматически запускается служба BIOS Recovery. В очередной раз улучшена модульность программного кода. Его редактирование для адаптации под конкретный чипсет теперь выполняется посредством визуального интерфейса Visual eBios и редактора карт прерываний IRQ Wizard.
Следующим шагом в развитии низкоуровневого программного обеспечения AMI стал анонс в начале 2003 года BIOS’а, поддерживающего спецификации TCPA 1.0. Они были созданы альянсом Trusted Computing Platform Alliance (TCPA) для обеспечения компьютерной безопасности на аппаратном уровне. В упомянутый альянс входят многие крупные производители компьютерного оборудования, такие, как IBM, Intel, Hewlett-Packard и другие.
EFI – BIOS будущего
Разумеется, технический прогресс не стоит на месте. Еще в 2003 году компания Intel представила совершенно новую концепцию BIOS’а: Platform Innovation Framework for the Extensible Firmware Interface (EFI) (Расширяемый микропрограммный интерфейс). Это модульная, платформенно-независимая оболочка, позволяющая загружать различные функции BIOS’а. Универсальность EFI базируется на новой для BIOS’ов типологии программного кода – драйверности. Новый код написан на языке «С», сама архитектура является достаточно простой, наращиваемой и имеет модульную структуру. Это позволяет добавлять модули, разработанные разными компаниями. Инфраструктура поддерживает функционирование технологий IA-32, Intel Itanium и Intel XScale по единой схеме и включает в себя модуль поддержки совместимости (compatibility support module, CSM) для обеспечения загрузки имеющихся операционных систем, а также осуществления их связи с современной архитектурой.
Сугубо прагматичный интерфейс ныне существующих типов BIOS’ов предложено модернизировать под внешний вид наиболее привычных операционных систем, то есть Windows. Для обновления версий EFI более не потребуется пресловутая дискета. Теперь изначально будет иметься полноценная поддержка USB-накопителей.
Несмотря на четырехлетнюю давность анонса, еще равно говорить о массовой экспансии EFI на оккупированную старичком BIOS’ом территорию. Что именно мы увидим в будущем, покажет время.
