Как написать свой биос

Со стародавних времён хотел попробовать создать собственный ROM BIOS, который будет записан в отдельную микросхему и будет выполнять какие-то полезные действия. Например, ROM BIOS установлен в видеокартах (по крайне мере старых), контроллерах дисков и много где ещё — это фактически расширения обычного BIOS. Понимаю, что это всё старьё и тягаться с возможностями современного UEFI бессмысленно, но мне очень хотелось создать свой собственный образ, который находится физически в отдельной микросхеме и работает при старте системы. Поэтому пришлось даже для этих целей найти старый комп.

Когда я только решил влезть в этот вопрос, столкнулся с тем, что достаточно мало толковой информации, которая была бы хорошо и чётко изложена. Возможно, я плохо искал, примеров того, как писать свою программу в бутсектор жёсткого диска было много, а вот толкового мануала по созданию BIOS Extension — кот наплакал.

В этой статье мы с вами разберём создание своего ROM BIOS, дальше я расскажу про тонкости и нюансы, напишу низкоуровневый «Hello world», сделаю настоящий интерпретатор BASIC ROM, который стартует при включении компьютера, как в первых IBM PC.

❯ Теория работы расширения BIOS

Думаю, все знают, что такое BIOS, многие заходили в его настройки при старте компьютера. Но, оказывается, есть возможность делать для него модули расширения и создавать там свой функционал.

Если говорить об архитектуре IBM BIOS, то он может быть расширен отдельными модулями, и всё будет работать как единый код. Поэтому в персональную ЭВМ могут быть добавлены дополнительные микросхемы ПЗУ, которые будут включать в себя эти модули.

Многие из вас видели эти микросхемы на сетевых картах, но они также присутствуют в видеокартах VGA Video BIOS, системный (основной) BIOS, BIOS IDE жёсткого диска и многие другие.

Для того чтобы системный BIOS нашёл дополнительный модуль в памяти, есть специальная процедура, которая позволяет его найти. Во время самотестирования POST, после загрузки векторов прерывания в ОЗУ, резидентный код BIOS начинает проверять ПЗУ на наличие специальных байтов заголовка, которые помечают начало дополнительного модуля BIOS. Поиск этих заголовков идёт в диапазоне абсолютных адресов 0C8000h - 0F4000h.

Заголовок имеет определённый вид:

• Два байта обозначают начало секции: 0x55 и 0xAA.
• Сразу за двумя первыми байтами заголовка, следует третий байт, который содержит длину дополнительного кода BIOS. Это количество блоков, длиной 512 байт, необходимых для хранения этого кода. Это ещё значит, что раздел кода расширения BIOS не может быть длиннее:

После того как заголовок был найден, проверяется — является ли последующий раздел настоящим расширением BIOS. Для этого выполняется проверка целостности для указанного количества блоков по 512 байт. Значения каждого байта в блоке суммируются сложением по модулю 0x100 — эффект такой же, как при делении суммы всех байтов на 4096(d). Остаток 0 указывает, что расширение BIOS содержит корректный код. Проще говоря, последний байт должен хранить контрольную сумму, сумма всех предыдущих байтов, с которой даёт нуль.

Как только заголовок идентифицирован, контрольная сумма проверена, то управление будет передано к третьему байту этого расширения, и начинается выполнение программы, содержащейся в этом расширении. Например, видеокарта инициализирует свои регистры, благодаря которым вы можете видеть что-либо на мониторе после включения. Или находят диски, подключённые к компу.

Дальше, когда код был выполнен, управление вновь передаётся к резидентному BIOS, и поиск в памяти дополнительных блоков BIOS продолжается. Этот процесс завершается, когда достигается абсолютный адрес 0F4000h, после которого уже и начинается загрузка с диска.

Внимательный читатель может заметить, что в одной и той же области памяти не может быть двух одинаковых образов, поэтому производители плат расширения для компьютеров дают возможность переназначать адреса, которые использовались с их расширениями BIOS, чтобы не было конфликтов.

Например, в большинстве систем тех лет, есть три стандартных BIOS, которые, как правило, всегда расположены в одном и том же месте:

• Системный BIOS: основной системный BIOS расположен в блоке памяти размером 64 КБ от F0000h до FFFFFh.
• VGA Video BIOS: это BIOS, который нужен для инициализации и управления видеокартой. Обычно он находится в блоке размером 32 КБ от C0000h до C7FFFh. Находится непосредственно на плате видеокарты.
• BIOS жёсткого диска IDE: BIOS, который управляет жёстким диском IDE, если в вашей системе есть IDE, расположен от C8000h до CBFFFh. На старых платах расположен на плате контроллера жёстких дисков, на новой системе, как я понимаю, непосредственно на материнской плате.

Например, можно взять программу RAMVIEW, которую я правил в прошлом посте, и посмотреть BIOS видеокарты.

Просмотр памяти BIOS реальной видеокарты

Переходим по смещению C000h, что как раз соответствует физическому адресу C0000h. Можно сразу увидеть два «магических» числа заголовка: 55h и AAh, затем идёт число 7Ch, которое говорит нам, что это расширение занимает 63488 байта.

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

В общем-то, этой информации должно быть достаточно, чтобы взять и написать свой BIOS.

❯ Пишем «Hello Wold» в расширении BIOS.

Когда начинал искать информацию по теме, наткнулся на следующую PDF, которая и стала кладезем информации. Это какая-то презентация, как собирать BIOS-расширения. В конце неё даётся ссылка на репозиторий с прекрасным примером и описанием. Это замечательный пример того, для чего можно было создавать свои расширения в BIOS — защищённая загрузка на жёсткий диск с паролем. Да, во времена UEFI всё это потеряло всякий смысл. Но мы хотим разобраться с этой частью.

Попробовал это расширение, оно у меня высыпалось с ошибкой. Но я понял, что оно работает, потому что оно запустилось и напечатало ошибку. Значит можно взять код, который выводил ошибку и сделать из него «Hello World».

Обкорнав этот пример, получилось настоящий «Привет мир». Сам ассемблеровский код разбирать не буду, он достаточно очевиден, но обращу внимание на некоторые моменты. Код весь можно посмотреть в моём репозитории. Программа собирается транслятором nasm, на мой взгляд, самый удобный и простой транслятор для начинающих, работает как в DOS, Windows, так и в Linux. Для удобства сборки написал Makefile.
Пробежимся по коду hello.asm:

org 0
rom_size_multiple_of equ 512
bits 16
    ; PCI Expansion Rom Header
    ; ------------------------
    db 0x55, 0xAA ; signature
    db rom_size/512; initialization size in 512 byte blocks
entry_point: jmp start
start:

Начинаем работать с нулевого смещения. Вначале мы определяем define rom_size_multiple_of equ 512, который содержит размер блока. Bits 16 говорит, что NASM должен генерировать код для процессора, работающего в шестнадцати битном режиме.

db 0x55, 0xAA — это заголовок, магические числа, которые обозначают начало область начала расширения BIOS.
db rom_size/512 — это один байт, который определяет размер секторов нашей программы. Рассчитывается автоматически с помощью макроса, для этого в конце программы добавлен следующий макрос:

rom_end equ $-$$
rom_size equ (((rom_end-1)/rom_size_multiple_of)+1)*rom_size_multiple_of

Макрос rom_end — получает размер программы в байтах. Далее идёт расчёт размер памяти, кратно блоку 512 байт и сохраняется в макрос rom_size. И это значение уже подставляется в байт в памяти, где рассчитывается количество блоков. Надеюсь, вы не запутались, тут просто происходит рекурсивная трансляция.

После того как заголовок определён, идёт команда jmp start, которая осуществляет прыжок на начало исполнения программы. В конце кода программы, перед макросами расчёта её размеров, резервируется 1 байт для расчёта контрольной суммы:

db 0 ; reserve at least one byte for checksum

В качестве способа ввода-вывода используется стандартное прерывание BIOS int 10h, которое расписывается в любой книжке по ассемблеру, поэтому не вижу смысла подробно на этом останавливаться. Многие студенты пишут подобные опусы на лабораторках в институте.

Самое интересное — расчёт контрольной суммы, и он осуществляется с помощью дополнительной программы addchecksum.c. Её исходники я также позаимствовал из проекта AHCI BIOS Security Extension. Код этой программы тоже стоит разобрать, потому что он интересен и полезен. Не так много работающих примеров, которые умеют считать контрольные суммы для расширения BIOS.

...
int main(int argc, char *argv[]) {
...
    FILE *f=fopen(argv[1], "r+");
...
    fseek(f, 0, SEEK_END);
    int f_size=ftell(f);
    fseek(f, 0, SEEK_SET);
    unsigned char sum=0;
    int i;
    for(i=0;i<f_size-1;i++) {
        sum+=fgetc(f);
    }
    fputc((0x100-sum)&0xff, f);
...
}

С помощью перехода в конец файла fseek(f, 0, SEEK_END); мы получаем размер файла int f_size=ftell(f);. Далее с начала файла образа читаем побайтно и суммируем полученные значения в однобайтовой переменной sum (то есть отбрасывая бит переноса). После чего инвертируем полученное значение и записываем его в последний байт нашей программы fputc((0x100-sum)&0xff, f);, где мы заранее зарезервировали нулевой байт данных. В результате, если просуммировать весь код программы, он должен быть равен нулю, вместе с нашей контрольной суммой (последний байт хранит отрицательное число контрольной суммы).

Собрать это всё можно следующими двумя командами:

gcc addchecksum.c -o addchecksum
nasm hello.asm -fbin -o hello.rom
./addchecksum hello.rom || rm hello.rom

Результатом всех операций, если вы всё сделали правильно, будет файл hello.rom. Осталось найти способ протестировать работоспособность этого бинарника.

❯ Способы отладки BIOS Extension

Самый очевидный и проблемный способ — это прошить программатором микросхему ПЗУ, вставить в специальную панельку на плате ISA или PCI, затем эту карту вставить в комп, включить его и убедиться, что ничего не работает. Есть вообще путь настоящего джедая — это встроить код прям в BIOS на материнской плате, но всё это долго, муторно и неудобно. Есть более простые и удачные решения.

Всё хорошее придумано для нас — это виртуальные машины, в данном случае использовал VirtualBox и qemu. Второй вариант быстрее и проще, первый — доступен в Windows, а поскольку большую часть времени работаю в wsl под Windows, для меня это актуально. Да, я знаю, что qemu есть для Windows, но таков путь.

VirtualBox

Для того чтобы протестировать ROM BIOS Extension, я создал пустую виртуальную машину. Там не требуется даже подключать жёсткий диск, он не нужен. Далее необходимо подключить данный образ к виртуальной машине. В Windows делал следующим образом, запускаю PowerShell и выполняю:

cd "C:Program FilesOracleVirtualBox"
.VBoxManage.exe setextradata testrom "VBoxInternal/Devices/pcbios/0/Config/LanBootRom" "c:tmphello.rom"

После этого можно просто подменять файл c:tmphello.rom и всё будет работать. В Linux тоже всё работает, команда такая же, разве что не требуется лезть по явному пути, так как путь до VBoxManage уже содержится в переменной PATH.

Копирую файл hello.rom в c:tmp и пробую запустить виртуальную машину.

Тестирование образа ROM в VirtualBox

Всё отлично работает. Но для меня qemu показалось намного удобнее и проще, без всех этих плясок с созданием машины и прописыванием путей до образа. И запустить её можно из любой папки.

Запуск BIOS в qemu

Протестировать в виртуальной машине qemu можно одной командой, прямо из папки с получившимся бинарником:

qemu-system-i386  -net none -option-rom hello.rom

• -net none говорит, что сети у нас нет.
• -option-rom — указывает образ ROM-файла.

Очень просто и удобно. Плюс можно сразу встроить в Makefile, чтобы собрать и проверить.

Запускаем тестирование программы из Makefile

Оба инструмента имеют право на жизнь, но мой выбор — это qemu, плюс там удобно будет ещё и посмотреть, что происходит с моей программой.

❯ Тестирование на реальном железе

Если первая часть статьи показалась вам сложной, то нет — это была самая простая часть проекта. Самая сложная часть, которая отняла у меня большую часть времени — это запуск всего на реальном железе.

Вообще, не так много способов установить свой собственный ROM в память компьютера, самый простой – это подобрать сетевую карту, у которой есть кроватка для установки ROM. Вроде бы прошивай ПЗУ, устанавливай в кроватку и вперед, но как обычно, путь был тернист.

Попытка на 386 машине

Изначально планировал весь проект реализовать на 386 машине, железо которой мне было любезно предоставлено spiritus_sancti.

386 материнская плата

Чтобы оживить его, пришлось пройти настоящий квест по разворачиванию DOS на Compact Flash, оказалась не такая простая задачка, с танцами. О чём подробно описал у себя в ЖЖ. Все эти мытарства были нужны для того, чтобы увидеть образ ПЗУ в памяти ЭВМ.

Для прошивки взял микросхему M2764, программатор долго её не хотел видеть, всё давал ошибки ножек. Но всё же дал её прошить.

Прошивка микросхемы

После прошивки вставил её в панельку сетевой карты и стал ждать чуда.

ПЗУ M2764 в панельке сетевой карты

Но чуда не произошло, сколько я не плясал с бубном, но видел при загрузке только такую картину:

BIOS найден не был, попытка загрузиться на дискетку

Тогда я тщетно пытался разыскать свой код в памяти с помощью утилиты debug (для этого и ставил DOS). Но безуспешно, в результате решил взять железо посвежее для своих опытов.

Pentium 4 и сетевая карта Realtek RTL8139

Поскребя по сусекам в своём гараже, обнаружил там системный блок с Pentium 4, который долгое время стоял под дождём, но оказался живым. И подумал, что он вполне может подойти для моих целей. Винт был мёртв и хрустел французской булкой, но меня это не волновало, главное, чтобы работал BIOS и PCI.

Потрошка подопытного, все шлейфы отключены, во избежание

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

Старт, всё живое, дисков нет

Чтобы код с сетевой карты выполнился, необходимо обязательно указать загрузку с LAN. Как это ни странно, по умолчанию выполняться он не будет, хотя мануалы гласят об обратном.

Включаем исполнение кода на сетевой карте

Есть верный способ сделать что-то хорошо — это повторить за кем-то. Поэтому, решил взять не только куски кода из проекта AHCI BIOS, но и рекомендации по выбору сетевой карты:

This one uses the Realtek RTL8139 controller, which is my recommendation. Network cards with the RTL8139 are easy and cheap to find on the second hand market. The network card should come with an unpopulated DIP-28 socket, so you will also need to get a DIP-28 EEPROM as the actual option ROM. Any ROM that sells as 28C64 should be compatible.

Вместо 28C64 решил использовать микросхему M2764, которая у меня уже была в наличии. Карта очень распространённая и купить её не проблема, главное следить, чтобы в ней была панелька.

Как я узнал из статьи «Boot manager для 486-го компьютера», для работы BOOT ROM сетевую карту нужно конфигурировать. Нашёл с трудом драйвера для RTL8139 под ДОС и даже настроил, чтобы всё корректно работало.

Настройка сетевой карты в драйверах

Ставлю прошитое ранее ПЗУ в эту сетевую карту, ииии…

Установленное ПЗУ. Железка снята для удобства многократной установки платы

Устанавливаю её в системный блок, загружаюсь и ничего. Как я не бился, как ни крутился, что не делал — не получается. Именно тогда я озадачился поиском программы просмотра памяти. С помощью RAMVIEW смотрел всю память, но так и не встретил там участка с моим образом (ключевое слово «Hello Word» в начале сегмента).

Стало понятно, что нужно брать сетевую карту, у которой уже есть настоящий, живой Boot ROM и смотреть как же он работает. Это сетевые карты типа PXE.

Рабочий вариант: сетевуха с образом PXE

Идея простая, найти сетевую карту с рабочим ПЗУ, затем посмотреть, как оно устроено. Отпаять с неё микросхему ПЗУ, зашить свою прошивку и припаять обратно. Но потом я подумал: а зачем отпаивать, если можно поставить просто панельку. Так я и поступил.

PXE-сетевые карты стоят на досках объявлений дешевле, чем микросхемы ПЗУ в магазине. Поэтому, купил сразу несколько плат, чтобы было место для экспериментов. Выбор пал на распространённую модель: 3Com 3C905C-TXM.

Сетевая карта с PXE

Ставлю её в компьютер, и, о чудо, она грузится!

PXE ROM успешно обнаружен!

Можно даже посмотреть, как выглядит образ PXE ROM в памяти компьютера, с помощью утилиты RAMVIEW.

Образ PXE ROM в памяти компьютера

Здесь для меня была ценная информация, где я смогу найти образ своей программы в памяти компьютера. Всё точно так же, магические два числа и размер образа в секторах.

Дело стало за малым: отпаять микросхему и припаять панельку. На деле оказалась не такая простая процедура, как я думал, даже пришлось носить к профессиональному монтажнику (благо есть такая возможность), но у меня всё получилось.

Снимаем микросхему ПЗУ

Монтируем панель для микросхем

Прошиваем

Устанавливаем микросхему на своё законное место. Для сравнения плата с панелькой и микросхемой, запаянной штатно:

Всё, теперь всё готово к тестированию. Вставляем плату в компьютер, и всё работает!

Суровый аппаратный Hello World

Этот удивительный момент даже заснял на видео.

Теперь даже можно проверить, что в памяти видно эту программу. Обратите внимание на строку «Hello world.» в конце.

По адресу PXE теперь живёт «Привет мир»

Всё это конечно прикольно, но хочется чего-то более полезного и функционального, ведь умение делать свой ROM BIOS дарит много новых возможностей. А давайте сделаем настоящий ROM BASIC?

❯ BIOS ROM BASIC

Старожилы помнят, что в первых персональных компьютерах IBM интерпретатор BASIC был встроен в ROM BIOS. И мне показалась забавной загружаться вместо ОС в интерпретатор BASIC.

Главная задача, которая стояла предо мной — это найти хорошие исходники BASIC, написанные на ассемблере. Может показаться забавным, но Microsoft официально, в своём репозитории выложила исходники GW-BASIC. Однако, внимательно посмотрел на них, почитал статьи тех, кто пытался их собрать, например, и понял, что дело гиблое. В результате я отказался от идеи использовать этот исходник, хотя, конечно, это было бы очень аутентично.

Мне же посоветовали исходники bootBASIC, который занимает всего 512 байт, и рассчитан для работы в загрузочном секторе жёсткого диска. По счастливому стечению обстоятельств, в качестве транслятора там тоже использовался nasm.

Я сделал клон этого проекта, за пару часов добавил функционал, чтобы он компилировал ещё образ для ROM сетевой карты: добавил в начале магическое число, размер и в конце контрольную сумму — теперь вы всё знаете и сами умеете.

Осталось только собрать образ ROM простой командой:

make basic.rom

И проверить его:

make runqemurom

Но всё это не спортивно, интересно попробовать в реальном железе. И таки да, оно работает!

Как говорится, лучше один раз увидеть, чем тысячу раз прочитать. Поэтому вот вам небольшое кинцо.

❯ Заключение

Кто бы мог подумать, что создание своего образа BIOS окажется таким интересным и продолжительным квестом. Мне пришлось купить около десятка сетевых карт, чтобы наконец найти рабочую. Проблемы с ROM, которые у меня были, вероятнее всего связаны с плохим качеством микросхемы ПЗУ.

Очень много этапов экспериментов не вошло в статью, как минимум у меня около десятка различных вариаций «Hello world», написанных в разной стилистике ассемблера. Поле для экспериментов просто непаханое. Несмотря на то, что это старьё, такой опыт полезен для разработки на голом железе и может быть использован при программировании других модулей.

Хоть литературы по теме немного, создавать свой ПЗУ BIOS совершенно несложно. Это не сильно отличается от примеров создания загрузчика в бутсектор жёсткого диска. Просто нужно помнить, что есть ещё контрольная сумма, которую тоже нужно уметь считать и записывать в конец образа ROM.

❯ Полезные ссылки

1. Краткое описание что такое BIOS Extension.
2. Презентация, которая сдвинула меня с мёртвой точки.
3. Репозиторий проекта AHCI BIOS Security Extension.
4. Мой репозиторий BIOS «Hello world.».
5. Оригинальный репозиторий bootBASIC.
6. Мой репозиторий, который умеет грузиться в ROM BIOS.
7. Интересная статья по теме «Boot manager для 486-го компьютера».

P.S. Если вам интересно моё творчество, вы можете следить за мной ещё в телеграмме.

Category:

• IT
• Cancel

Тот уникальный случай, когда я пишу пост в ЖЖ сильно позже, чем вышел пост на хабре. В телеге вышел вовремя. Прошу понять, простить и полюбить, в командировке, было просто не до того. Исправляюсь, пишу с сапсановского вайфая.

Хотели ли вы когда-нибудь написать свой BIOS? А BIOS вместе со встроенным BASIC? А вообще представляете как работает BIOS и как писать свои модули расширения? Уже давно у людей витает в воздухе идея сделать свой ROM BASIC и поиграться с ним, но вот прям рабочих и живых решений, по крайне мере в рунете я не встречал. В чатике давно муссируется тема, как это сделать. И сложнее всего было не проболтаться, что я знаю как это делать и уже есть готовое решение.
И вот, настал счастливый миг, когда могу явить это решение широкой публике. Подробности в моей статье:

Буду рад вашим комментариям, лайкам, дополнениям.

A BIOS can be written in assembly but doesn’t have to be, some parts need to be to get the parameters for the system call since they don’t match the compilers calling convention.

How do you flash it? Varies from motherboard to motherboard, I would start with an open source virtual machine and write a bios for that. Or create a virtual machine where you have written the bios. The mechanism varies from vendor to vendor, generally you boot dos (dos is not dead, it is very much alive in the PC world, esp motherboard development and embedded systems). I wouldn’t mess around with a real motherboard, if you don’t already know the answers to all of these questions you are going to brick a number of motherboards if you take that path.

You can try to take a bios upgrade for your mother board and reverse engineer it (although there is probably a click through agreement that says that you wont). If you figure it out you can both load it and hack at at. I wouldn’t go there, you will brick your system before you figure it out.

Is writing a bios really what you are after? Fairly old school, would be like writing 6502 code for fun. There are many low level problems that are more useful and as interesting.

If you can write asm the writing machine code is not that difficult at all, you could just go do that for fun. x86 is dreadful, you should spend some time learning other systems and their asm and machine code (and writing operating systems for them). ARM dominates the world and doesn’t rely on a bios. I have been told that to get a video card up on a non-x86 system you still have to fiddle something in x86 on the x86 bios, could figure out how to bring up a mainstream video card without the need to run the x86 bios. watch an emulator run the bios and see what it does, figure it out replace that power on init without the bios doing it…Writing an instruction set simulator or disassembler is the next step beyond writing machine code, I wouldn’t waste even a second of time on x86 though, I can suggest a list of alternatives (or you could just play with the simulators I have written or collected).

If an x86 bios is the way you want to go, your best path is to write, replace, or hack on a bios for a virtual machine being qemu, virtualbox, or other. Replacing that bios with yours would likely be replacing a file in some directory or using a command line option to specify an alternate bios. Once you are well experienced in that then if there are still motherboards with legacy bioses on them perhaps you can hack your way into programming one (need to buy several of each type of motherboard as you WILL brick some). With so many embedded systems out there that can be had for $20 to $200 with the same level of experience gained, it doesn’t make sense to hack on a pc motherboard without decent schematics and documentation. You could dig up an original PC with the schematic and bios listing being documented, and the bios being socketed so if yours doesn’t boot (and doesn’t destroy the motherboard) it isn’t a brick you can reprogram or replace the bios chip. Probably want to use a microcontroller to stand in as a fake bios, as finding the right hardware to reprogram more bios chips is perhaps harder to find that working original PC’s…There is an amiga community that is likely a lot more fun and would be happy to have you improving/tweaking their bios, say putting modern hardware behind the legacy system calls.

BIOS может быть написан на ассемблере, но не обязательно, некоторые части должны быть такими, чтобы получить параметры для системного вызова, поскольку они не соответствуют соглашению о вызовах компиляторов.

Как вы его прошиваете? Варьируется от материнской платы к материнской плате, я бы начал с виртуальной машины с открытым исходным кодом и написал для нее биос. Или создайте виртуальную машину, где вы написали биос. Механизм варьируется от поставщика к поставщику, обычно вы загружаете DOS (DOS не умер, он очень жив в мире ПК, особенно при разработке материнских плат и встроенных систем). Я бы не стал возиться с настоящей материнской платой, если вы еще не знаете ответов на все эти вопросы, вы собираетесь испортить несколько материнских плат, если пойдете по этому пути.

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

Написание биоса действительно то, что вам нужно? Довольно старая школа, это все равно, что писать код 6502 для развлечения. Есть много задач низкого уровня, которые более полезны и интересны.

Если вы можете писать asm, писать машинный код совсем не сложно, вы можете просто заняться этим ради удовольствия. x86 ужасен, вам следует потратить некоторое время на изучение других систем и их ассемблера и машинного кода (и на написание операционных систем для них). ARM доминирует в мире и не полагается на биос. Мне сказали, что для того, чтобы установить видеокарту в системе, отличной от x86, вам все равно придется что-то возиться с x86 в биосе x86, чтобы понять, как запустить основную видеокарту без необходимости запуска биоса x86. посмотрите, как эмулятор запускает биос, и посмотрите, что он делает, выясните, как заменить это питание при инициализации без того, чтобы биос делал это … Написание симулятора набора инструкций или дизассемблера — это следующий шаг после написания машинного кода, я бы не стал тратить даже хотя раз на секунду на x86, я могу предложить список альтернатив (или вы могли бы просто поиграть с симуляторами, которые я написал или собрал).

Если вам нужен биос x86, лучше всего написать, заменить или взломать биос для виртуальной машины, например qemu, virtualbox или другой. Замена этого биоса вашим, скорее всего, будет заменой файла в каком-то каталоге или использованием параметра командной строки для указания альтернативного биоса. После того, как вы хорошо разбираетесь в этом, тогда, если на них все еще есть материнские платы с устаревшими биозами, возможно, вы сможете взломать свой путь к программированию (необходимо купить несколько материнских плат каждого типа, так как некоторые из них будут кирпичными). С таким количеством встраиваемых систем, которые можно купить за 20–200 долларов при том же уровне полученного опыта, нет смысла взламывать материнскую плату ПК без приличных схем и документации. Вы можете откопать оригинальный ПК с задокументированной схемой и списком биос, а биос подключен, поэтому, если ваш не загружается (и не разрушает материнскую плату), это не кирпич, который вы можете перепрограммировать или заменить биос чип. Возможно, вы захотите использовать микроконтроллер в качестве поддельного биоса, так как найти подходящее оборудование для перепрограммирования большего количества чипов биоса, возможно, труднее найти работающий оригинальный ПК … Существует сообщество амига, которое, вероятно, намного веселее и будет буду счастлив, если вы улучшите/настроите их биос, скажем, установив современное оборудование вместо устаревших системных вызовов.

Пишем для UEFI BIOS в Visual Studio. Часть 1 — разворачивание среды разработки, компиляция и запуск на отладку

В этой статье будет описано, как быстро начать программировать для UEFI во фреймворке edk2 в среде Visual Studio, не тратя массу времени на настройку среды обычным способом, по оригинальным мануалам. Достаточно дать команду git clone . в корневом каталоге диска, и это на самом деле все, среда будет полностью установлена и готова к работе. Требуются 64-разрядная Windows 7 и выше c Visual Studio 2008-2015. Эти два условия не обязательны, но тогда придется немного потрудиться над собиранием системы edk2—Visual Studio в единое целое, краткая памятка будет приведена.

Цель статьи — провести начинающего за руку по первому UEFI проекту, оставаясь в привычной ему среде. Для более опытных людей, надеюсь, будет интересным поработать в VS вместо привычной командной строки, или разобрать подход и перенести его в любимый Eclipse.

Начнем с простых вещей, вывода строки на консоль и русификации (довольно востребованная вещь, причем простая в реализации), потом будет работа с формами в HII (то, что называлось в обиходе страницами BIOS Setup), потом графика, потом Boot Manager, а потом видно будет (с).

Желающие — прошу пожаловать под кат.

Сейчас необходимо решить, оно вам надо или нет. Потратим на это пол-страницы на старте, чтобы не тратить пол-дня и в конце понять, что вам надо совсем другое. Или, надеюсь, наоборот — загореться энтузиазмом и выкроить время на прочтение статьи.

Вначале хорошее

1) Аппаратура не понадобится от слова совсем. Никаких Evaluation Boards, никаких Intel BlueBox JTAG за $3000. Все будет отлаживаться в 32-битной виртуальной машине OVMF – портированной Интелом виртуалке qemu для отладки UEFI Firmware. Для перекомпиляции под реальную платформу достаточно потом — после отладки — переставить пару ключей в настройках компиляции, и на этом все.

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:FWedk2Conftarget.txt и в строчке
TOOL_CHAIN_TAG = VS2010x86

Заменяем VS2010x86 на тэг установленной у вас версии Visual Studio. Для Visual Studio 2010 тэг останется как есть, для других версий VS – смотрите картинку выше, или список в начале файла c:FWedk2Conftools_def.txt

Собственно, среда разработки edk2 развернута полностью и в ней можно работать из командной строки. Некоторые так и работают всю жизнь («угорать по хардкору, поддерживать дух старой школы и всё такое» — (с) CodeRush в своей ставшей классической статье). Но мы все же пойдем дальше, пересаживать человека из MSVS обратно в командную строку — негуманно, особенно в 2017.

Настраиваем проект в Visual Studio

Открываем Visual Studio, в нем открываем Solution NT32.sln из каталога C:FWVSNT32. В целях уменьшения времени входа в тему, в solution уже создан одноименный проект NT32, в котором уже сделаны описанные ниже настройки. Это если не получится создать самим – чтобы иметь гарантированно рабочие настройки проекта. Такой подход сильно сократит время поиска источника проблем, в случае их появления. Тем не менее, лучше пройти описанный ниже путь самим, и понять смысл настроек – это облегчит настройку следующих проектов.

Полезно будет сразу в Tools->Options настроить рабочий каталог на c:FWVS, но если в 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:FWedk2Nt32Pkg. Этих пакетов там много, мы их рассмотрим, но не сейчас.

В третьей строке мы даем команду на компиляцию в только что настроенной среде (build.exe лежит в C:FWedk2BaseToolsBinWin32, этот путь прописывается в предыдущей строчке, в 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:FWedk2BuildNT32IA32DEBUG_VS2010x86IA32. Там этот же самый список файлов, и лучше его смотреть (и редактировать скрипты) через развитую оболочку 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:FWedk2MdeModulePkgApplicationHelloWorldHelloWorld.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 пишется с использованием Assembly, C или их комбинации .

BIOS должен быть написан на языке, который может компилироваться в машинный код , понятный физическому аппаратному компьютеру. Это устраняет языки с прямой или промежуточной интерпретацией (Perl, Python, PHP, Ruby, Java, C #, JavaScript и т. Д.) Как подходящие для написания BIOS. (Хотя, теоретически, можно реализовать один из этих языков либо для прямой компиляции в статический машинный код, либо встроить интерпретатор в BIOS. Например, есть проект GCJ для Java, созданный на основе программного обеспечения).

Большинство OEM-производителей внедряют BIOS, расширяя проприетарные, универсальные реализации BIOS такими компаниями, как American Megatrends и Phoenix Techologies . (Вероятно, вы уже видели одну из этих компаний, отображенную на первом экране загрузки компьютера.) Исходный код для этих реализаций не является общедоступным, но некоторые из них утекли. Я не хочу ссылаться на это непосредственно на C и исходный код сборки, но в Интернете есть места, где обсуждается этот исходный код для тех, кто хочет заглянуть.

Некоторые производители оборудования, например производители, ориентированные на высокопроизводительные и игровые рынки, насыщают свои реализации BIOS функциями настройки, статистикой и привлекательными пользовательскими интерфейсами, разработанными для их точных реализаций. Многие из этих функций выходят за рамки того, что предлагается в универсальных продуктах, выпускаемых American Megatrends и другими. К сожалению, эти компании часто рассматривают выпуск своего исходного кода как угрозу безопасности , поэтому об этих реализациях высокого уровня известно мало, потому что о них мало что известно. Конечно, можно найти способы доступа и декомпиляции таких реализаций BIOS, но это может быть трудным и, возможно, незаконным.

Возвращаясь к первоначальному вопросу, из-за необходимости создавать собственный машинный код, BIOS должен быть реализован на языке программирования, поддерживаемом компилятором машинного кода . Хотя таких языков много, и хотя я уверен, что за последние несколько десятилетий в экспериментах использовалось несколько языков, каждая открытая реализация BIOS, которую я смог найти, специально основана на комбинации C и / или сборки. Реализации BIOS с открытым исходным кодом, на которые я смотрел, чтобы сформировать этот вывод, включают OpenBIOS , tinyBIOS , coreboot , Intel BIOS и Libreboot, Я также рассмотрел некоторые очень старые реализации BIOS, которые не актуальны сегодня, но также следовали правилу C и / или сборки.

Я думаю также уместно взглянуть на другое программное обеспечение, созданное для непосредственного взаимодействия с оборудованием. Мы знаем, например, что ядро Linux , то OS X ядро и ядро Windows , в основном C с некоторой сборкой и некоторыми высокоуровневыми языками для выполнения конкретных задач. Мы также знаем, что аппаратные драйверы для Linux и аппаратные драйверы для Windows написаны в основном на C.

Возвращаясь к BIOS, я думаю, что также важно учитывать экономику выбранного языка программирования. BIOS обычно пишется как необходимость дополнять продажи оборудования. Известно, что современные системы BIOS в основном написаны на C и / или на ассемблере. Переход к другому инструменту привел бы к значительным затратам к тому, что обычно считается товарной продукцией, что может очень негативно повлиять на продажи. Не вдаваясь в экономику 101, я могу заверить вас, что, возможно, ОЕМ-изготовителю не стоит отказываться от проверенных временем инструментов, проверенных десятилетиями.

Конечно, есть и будут проекты для любителей писать BIOS. Похоже, что они тоже до сих пор выбирают C и / или сборку. Возможно, однажды будут использованы другие технологии. Но сегодня выбор четко определен.

Написание собственного BIOS

Я не сумасшедший, просто изобретаю колесо: D
Я написал загрузчики, мини-драйверы для мыши и клавиатуры, мини-ОС и так далее.

Я всегда стараюсь избегать прерываний DOS, используя только BIOS, пытаясь продвигать unity mini OS, но внезапно я решил написать свой собственный BIOS:)

легенда сказал :
Я был программистом высокого уровня, потом низкого. Однажды я стану программистом машинного языка!

написан ли BIOS в сборке? Как могу я помахать им? Каков механизм? Могу ли я начать редактирование текущего BIOS?

4 ответов

BIOS может быть записан в сборке, но не обязательно, некоторые части должны быть, чтобы получить параметры для системного вызова, поскольку они не соответствуют Соглашению о вызове компиляторов.

Как прошить его? Варьируется от материнской платы к материнской плате, я бы начал с виртуальной машины с открытым исходным кодом и написал bios для этого. Или создайте виртуальную машину, на которой вы написали bios. Механизм варьируется от поставщика к поставщику, как правило, вы загружаете dos (dos не мертв, это очень жив в мире ПК, разработке материнских плат esp и встроенных систем). Я бы не возился с реальной материнской платой, если вы еще не знаете ответов на все эти вопросы, вы собираетесь заложить кирпичом ряд материнских плат, если вы пойдете по этому пути.

вы можете попробовать взять обновление bios для вашей материнской платы и реконструировать его (хотя, вероятно, есть соглашение, в котором говорится, что вы не будете). Если вы поймете это, вы можете загрузить его и взломать на. Я бы не пошел туда, вы заложите кирпичом свою систему, прежде чем поймете это.

действительно ли вы пишете bios? Довольно старая школа, было бы похоже на написание кода 6502 для удовольствия. Есть много проблем низкого уровня, которые являются более полезными и интересными.

Если вы можете написать asm код пишущей машины не так сложно, вы можете просто пойти сделать это для удовольствия. x86 ужасен, вы должны потратить некоторое время на изучение других систем и их asm и машинный код (и написание операционных систем для них). ARM доминирует в мире и не полагается на bios. Мне сказали, что для того, чтобы получить видеокарту в системе, отличной от x86, вам все равно нужно что-то возиться в x86 в x86 bios, можно выяснить, как поднять основную видеокарту без необходимости запускать x86 bios. посмотрите, как эмулятор запускает bios и посмотрите,что он делает, выясните, замените это питание на init без bios. Написание тренажера набора инструкций или дизассемблер-это следующий шаг после написания машинного кода, я бы не стал тратить ни секунды времени на x86, хотя, я могу предложить список альтернатив (или вы можете просто поиграть в симуляторы я написал или собираются).

Если bios x86-это то, что вы хотите, ваш лучший путь-написать, заменить или взломать bios для виртуальной машины qemu, virtualbox или другого. Замена этого bios на ваш, вероятно, заменит файл в каком-либо каталоге или с помощью команды опция line для указания альтернативного bios. После того, как вы хорошо опытны в этом, то если есть еще материнские платы с наследием bioses на них, возможно, вы можете взломать свой путь в программировании один (нужно купить несколько каждого типа материнской платы, как вы будете кирпич некоторые). С таким количеством встроенных систем, которые могут быть за $20 до $ 200 С таким же уровнем опыта, не имеет смысла взломать материнскую плату ПК без достойных схем и документации. Можно нарыть оригинальный ПК со схемой и списком bios документируется, а bios закрепляется, поэтому, если ваш не загружается (и не разрушает материнскую плату), это не кирпич, который вы можете перепрограммировать или заменить чип bios. Вероятно, хотите использовать микроконтроллер, чтобы стоять в качестве поддельного bios, так как найти правильное оборудование для перепрограммирования большего количества чипов bios, возможно, сложнее найти, что работает оригинальный ПК. Существует сообщество amiga, которое, вероятно, намного веселее и будет рад вас видеть улучшение / настройка их bios, скажем, размещение современного оборудования за устаревшими системными вызовами.

Fwiw Modbin-это программа DOS, которая, как следует из названия, изменяет изображения BIN, особенно с целью простых qnd довольно экстремальных изменений существующего кода BIOS.

Если вы можете получить старый mobo (многие выбрасываются все еще работают), я бы рекомендовал вам поиграть с BIOS. Это информативно и весело, если кто-то так склонен, и Вы, кажется,:) было время, когда я загружал изображения BIOS с mobos, которые имели те же или похожие чипсеты, хотя сделано другим изготовителем. иногда для значительного преимущества, включая такие простые, как продолжение получения обновлений BIOS после того, как оригинальный производитель mobo уронил мяч или пошел животом вверх, а также функции и параметры производительности и изменения.

Это привело к «горячему миганию», которое тянет вверх чип BIOS с носком, так что штыри едва вошли в контакт и один раз загрузились, потянув его и заменив плохой (часто тот, который я fuxored), в то время как все еще работает и мигает, используя кэшированную функцию BIOS, которая поддерживала активность системы. Забавные вещи для тех из нас, кто выродок убеждения и дал мне уверенность, чтобы написать драйверы устройств для OS / 2

есть способы прошить bios, кроме того, чтобы компьютер работал, возможно. Но это требует некоторого оборудования. Хотя это не должно быть слишком дорого.

Он объяснил это более подробно, хотя вы, возможно, не ищете инфекции, некоторые технологии для получения bios покрыты, где клип программирования является одним из них.

Если вы хотите написать BIOS для IBM PC совместимого компьютера (который является то, что большинство настольных ПК сегодня, хотя и с большим количеством расширений для набора инструкций CPU, и некоторые различные интерфейсы шины), то я предлагаю вам посмотреть через IBM PC, IBM PC XT и IBM PC AT технические справочники. В частности, IBM PC AT manual, как таков фактический стандарт.

в этих руководствах есть список программ полного BIOS, который IBM использовала на своих компьютерах, и они находятся на языке ассемблера. Возможно, вам придется немного порыться в этих руководствах (особенно в IBM PC at one), чтобы найти их, поскольку некоторые из них не перечислены непосредственно в оглавлении, но они есть. Надеюсь, те первые версии BIOS, может вам для начала.