Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 25
Большое пожалуйста.
Драйвер собирается для целевой архитектуры и для разных архитектур нужны разные драйверы. По идее, есть возможность собрать DXE-драйвер в байткод EBC, но, во-первых, далеко не во всех прошивках есть драйвер для исполнения этого байткода (зовут его EbcDxe, можете открыть свою прошивку в UEFITool и поискать такой), во-вторых, сам этот исполнитель пока собирается только для IA32, AMD64 и IA-64, т.е. ARM, MIPS и PPC все равно в пролете, в-третьих, компилятор в EBC стоит денег, а бесплатно можно только писать непосредственно на байткоде, как это делает icbook.
В общем, намного проще собрать несколько платформо-зависимых драйверов и рядом их положить, места сейчас для OptionROM хватает, а для обычной прошивки кроссплатформенность вообще не нужна, если процессор вдруг не поменятся с x86 на ARM (у AMD были планы сделать попиново совместимые процессоры с различными ядрами, но от них отказались, и правильно, на мой взгляд).
Драйвер собирается для целевой архитектуры и для разных архитектур нужны разные драйверы. По идее, есть возможность собрать DXE-драйвер в байткод EBC, но, во-первых, далеко не во всех прошивках есть драйвер для исполнения этого байткода (зовут его EbcDxe, можете открыть свою прошивку в UEFITool и поискать такой), во-вторых, сам этот исполнитель пока собирается только для IA32, AMD64 и IA-64, т.е. ARM, MIPS и PPC все равно в пролете, в-третьих, компилятор в EBC стоит денег, а бесплатно можно только писать непосредственно на байткоде, как это делает icbook.
В общем, намного проще собрать несколько платформо-зависимых драйверов и рядом их положить, места сейчас для OptionROM хватает, а для обычной прошивки кроссплатформенность вообще не нужна, если процессор вдруг не поменятся с x86 на ARM (у AMD были планы сделать попиново совместимые процессоры с различными ядрами, но от них отказались, и правильно, на мой взгляд).
Придется держать отдельные версии в любом случае — исполнитель EBC стартует в начале фазы DXE, а там еще до этого две фазы на полмегабайта кода суммарно, которые делают всю черную работу по инициализации процессора, кэша L2, оперативной памяти и других жезненно необходимых устройств. Это все на EBC не напишешь, как не крутись.
Драйверы те написаны на тулките GNU-EFI и тоже собираются по экземпляру для каждой архитектуры, на данный момент только для x86 и amd64.
Драйверы те написаны на тулките GNU-EFI и тоже собираются по экземпляру для каждой архитектуры, на данный момент только для x86 и amd64.
Если в прошивке нет EbcDxe (что иногда встречается), то этот драйвер можно запустить командой run. Такое решение открывает путь для EBC, как универсального средства общения (с известными оговорками «универсального», кончено).
И тогда этих EbcDxe тоже надо с собой носить по количеству архитектур. Если основной драйвер огромный (UGA/GOP-драйвер для Radeon for MAC, к примеру), то есть смысл собрать его в EBC и носить с собой пригоршню интерпретаторов на каждый случай, а вот для таких поделок в 3 экрана EBC — только лишний оверхед.
Спасибо за статью! Давно пора было бы суммировать наработки в этом направлении: стоит вспомнить хотя бы рекомендации Курта Цзяо (Kurt Qiao). Непонятно, что мешает производителям разместить это вобщем-то тривиальную фичу в UEFI BIOS?
Что мешает — да ничего, собственно. ASUS, к примеру, давно уже позволяет сохранить по F12 скриншот BIOS Setup в формате BMP. Почему это до сих пор не внедрено в массы — черт его знает, разработчики не видят необходимости (у них перенаправление текстовой консоли есть, его хватает в 95% случаев), менеджеры никогда не работали с BIOS Setup и не знаю про него ничего, а пользователи не могу достучаться до людей, принимающих решения, через три линии «технической поддержки».
Ноутбучный UEFI у ASUS не очень-то и сохраняет скриншоты :) Я, конечно, понимаю, что через IPMI можно все что угодно задокументировать (да и сам так не раз делал), но вот на продакш-сервере не очень то и разгонишься перезагружаться с этой в общем-то благородной целью.
Вот, кстати, хорошая иллюстрация, как скриншоты на серваке снимали удаленно :)
Вот, кстати, хорошая иллюстрация, как скриншоты на серваке снимали удаленно :)
всегда удивлялся почему во всяких игрушках где скриншоты нужны только чтобы выпендрица, разработчики вставляют собственные перехватчики для снятия скриншотов, а в программах где действительно без скриншота бывает не обьясниш — нет.
скриншот это для примера
Просто потому, что в игры играют миллионы, а настройками BIOS Setup делятся десятки. Денег на этой фиче не заработать, только из за нее плату у тебя, а не у конкурента, никто не купит — т.е. для производителя смысла в этой фиче почти нет. Мне она понадобилась — вот я ее и написал.
скриншот это для примера
ведь не только скришоты там делать — но и что-то полезное/бесполезное. Например встроенную защиту или вирус.
ведь не только скришоты там делать — но и что-то полезное/бесполезное. Например встроенную защиту или вирус.
В данном случае, это все же больше для скриншотов, чем для примера.
Интересущихся «вирусами» советую посмотреть код SMM Backdoor уважаемого d_olex, и его запись в блоге о разработке этого бэкдора.
Интересущихся «вирусами» советую посмотреть код SMM Backdoor уважаемого d_olex, и его запись в блоге о разработке этого бэкдора.
что-то типа тотал-коммандера нужно по зарез! и антивирусники, безусловно!
Спасибо большое за статью. Ваши статьи не только интересны, но и полезны с точки зрения простоты изложения материала. И можно все попробовать) Если будет время на выходных, то я постараюсь запустить Ваш драйвер из OpROM нашей железяки и выложить здесь скриншоты. Извините за оффтоп, но у меня есть вопрос по русификации вывода драйвера, если прошивка не поддерживает русский язык. Сложно ли это сделать? Достаточно ли реализовать протокол работы с шрифтами внутри драйвера?
Если получится запустить из OROM, будет совсем хорошо, спасибо за попытку заранее.
По руссификации — не сталкивался с этой задачей, но думаю, что пары протоколов будет достаточно (знать бы только каких именно...). В крайнем случае, интерфейс можно весь в графической консоли битмапами рисовать, как в старые добрые времена.
По руссификации — не сталкивался с этой задачей, но думаю, что пары протоколов будет достаточно (знать бы только каких именно...). В крайнем случае, интерфейс можно весь в графической консоли битмапами рисовать, как в старые добрые времена.
Для чтения образа экрана используется функциональность GOP.BLT? Прямое обращение к видеопамяти исключено полностью?
Тогда, по идее, это должно без проблем работать и на видеоадаптерах со статусом BLT Only.
CodeRush спасибо. действительно хорошая статья для начинающих.
у меня возник вопрос по вашей статье, он касается метода сохранения изображения на доступной файловой системе.
выше вы пишете:
получается что на NTFS/Ext3/HFS писать ничего не получится? есть ли какие нибудь возможные варианты для решения сего вопроса?
заранее благодарю за ответ.
// upd.: посмотрел решение записи файлов в vector-edk от h-team. там используется модуль NtfsPkg, т.е вопрос с NTFS в данном случае решен. остается вопрос только с юниксовыми фс.
у меня возник вопрос по вашей статье, он касается метода сохранения изображения на доступной файловой системе.
выше вы пишете:
Чаще всего единственные известные ФС — семейство FAT12/16/32 (иногда только FAT32), которые по стандарту UEFI могут использоваться для ESP.
получается что на NTFS/Ext3/HFS писать ничего не получится? есть ли какие нибудь возможные варианты для решения сего вопроса?
заранее благодарю за ответ.
// upd.: посмотрел решение записи файлов в vector-edk от h-team. там используется модуль NtfsPkg, т.е вопрос с NTFS в данном случае решен. остается вопрос только с юниксовыми фс.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Пишем DXE-драйвер для снятия скриншотов с BIOS Setup и других UEFI-приложений