Comments 16
Приятно видеть статьи про UEFI на Хабре, спасибо за материал.
Главный недостаток дефолтного OVMF — 32х-битность и не совсем честная эмуляция оборудования, но если не пробовать пробрасывать туда железо и отлаживать там VT-d, SGX и подобные вещи, хорошая эмуляция которых будет доступна еще не скоро, то такой подход намного лучше, чем "голый" EDK2.
Заодно порекомендую проект VisualUEFI товарища Ионеску, преследующий те же цели, да еще и 64х-битный.
Если про VisualUEFI, которую Вы также упоминали в статье про DXE-драйвер — то, конечно, я ее попробовал, перед тем как творить что-то свое (хотя какое там свое — по сути, я соединил два компонента в единое целое так, как не видел в инете, и получилось, на удивление, очень удобно). Дело в другом…
Видимо, я пересидел в проектных менеджерах :) Задача статьи — быстрый ввод новичка в тему, в проект. То, что предложил я — скачать папку одной командой git, поправить в ней один-единственный файл в одном-единственном месте и все. Дальше новичку доступна (почти) вся огромная гамма примеров в фреймворке edk2 (в крайнем случае — добавить/раскомментировать единственную строку в соответствующем dsc файле), просто щелкнув по проекту NT32 правой кнопкой, выбрав Add Files и затащив в проект мышкой все файлы из каталога проекта. Это на самом деле все, дальше можно добавлять свой код, брякпойнты и делать все те фокусы, к которым привык, скажем, человек, пишущий на C#. Если мы говорим про свой, новый проект, то inf-файлы и все остальное генерирутся автоматом, через Intel UEFI Driver Wizard — я покажу это в следующей статье, которая уже готова, надо только оформить.
У Ионеску это, при всем к нему уважении — новый фреймворк. Он совместим, в принципе, с edk2, но только в одну сторону — в свою. Обратной дороги нет, и той, что предложена, придется учиться некоторое время. Примеров там — с гулькин нос. А человеку потом переучиваться на edk2, если он выберет тернистую дорогу UEFI и пойдет снова работать к какому-нибудь IBV (впрочем, я в IBV не работал, не знаю реально, как у них фреймворки отличаются от edk2)
Пожалуйста, рад что кому-то моя статья помогла.
По поводу нового фреймворка — соглашусь, но новички перестанут быть новичками, и изучать сборочную систему EDK2 им все равно придется, неважно, с чего они при этом начинали, с NT32Pkg, c VisualUEFI, или с какой-нибудь IDE от IBV (я раньше работал с Visual eBIOS, которая сделана из Eclipse, сейчас работаю с Xcode). Визарды — это отлично, конечно, но их быстро перестанет хватать.
Не могу сказать, что лучше начинать прямо с EDK2, как это сделано в моей статье, но точно могу сказать, что работать с EDK2 в любом случае придется, рано или поздно, так или иначе.
В этой статье, вроде бы, написано, как расширять сам UEFI. UEFI — это современный аналог BIOS. То, что мне нужно, на уровень выше BIOS и только лишь пользуется его возможностями. Значит, описанное здесь — не то, что мне нужно?
В идеале, я бы хотел найти фреймворк для написания таких приложений, что-то вроде микроОС, которая бы прятала всякие сложные для понимания вещи вроде работы с экраном, инициализации памяти, или организации многопоточности / синхронизации между потоками.
habrahabr.ru/company/neobit/blog/173263
для таких историй вроде принято WinPE юзать? Или это слишком громоздкая "микроОС" для вашей утилиты?
UEFI BIOS — это про то, что до загрузки ОС. Когда начинает загружаться ОС, UEFI BIOS уходит «в глубокое подполье», большинство ее функций становится недоступно, по принципу разделения ответственности между ОС и BIOS. Сама цель UEFI BIOS — минимально проинициализировать аппаратуру, процессор и чипсет, до той степени, чтобы максимально быстро стала возможной загрузка ОС. Т.е. проверить секьюрити, сделать доступными диски и консоль вывода (на предмет диагностики ошибок), и передать управление загрузчику. Все, что можно перенести из BIOS в ОС — переносится без разговоров. Все эти красивые окошечки с управлением от мышки в MSI BIOS Setup и прочих — конфигурационные, на скорость обычной загрузки они не влияют никак.
Только статья не про утилиту, это учебник, с набором уже настроенных конфигов. Утилиту я для этого не писал, используется все готовое :)
Это оно и есть.
На носителе создаётся партишн EFI, форматируется в FAT (-12, -16 или -32 — зависит обычно от размера партишна). В нём в корне лежит папка EFI, а в ней — либо прямо, либо в подпапках — приложения с расширением .efi
Как раз процесс создания одного из них описан в статье.
Дальше уже дело настроек.
Для сменных носителей (флешки) этот партишн может сканироваться и создаваться на лету меню с доступными опциями.
Для постоянных — можно либо так же, либо прописать меню в ROM.
На убунте это делается (из-под-рута) командой efibootmgr. Например, можно прямо в EFI положить ядро, и прописать в ROM (упс… теперь это называется NVRAM. По смыслу то же, но дьявол в деталях). Но обычно туда кладут GRUB. Или тот же memcheck.
В общем — воспринимайте это как старый-добрый DOS. Который при этом умеет работать с разными носителями, но понимает только партишны EFI. И видит там только программы (.efi).
Отдельный момент (а иногда и головняк) — если в NVRAM прописан конкретный плагин на конкретном диске — а диск вдруг поменяли. Иногда получается довольно весело.
Глава 3 в Manual QNX
и Глава 13 Manual IDE
Соответственно, вы запускаете не ОС, а вашу программу. Или см. в сторону FreeRTOS.
Пишем для UEFI BIOS в Visual Studio. Часть 1 — разворачивание среды разработки, компиляция и запуск на отладку