Pull to refresh

Comments 7

Отлично, замечу только, что с gST->ConOut и gST->ConIn напрямую стоит работать только в процессе начального обучения, потому что цепочки из X->Y->Z(X->Y, T) сильно замусоревают код и его становится неприятно читать, а читаемость — это, на мой взгляд, вторая по важности характериска кода прошивки после работоспособности.
В реальных приложениях и драйверах обычно используют библиотеку PrintLib, которая превращает кошмарный gST->ConOut->OutputString(gST->ConOut, L"String") во вполне безобидные Print(L"String") или AsciiPrint("String").
Скорее всего, это все будет в следующих частях, ждем с нетерпением.

Это специально, чтобы с самого начала уяснили, откуда у консольного вывода ноги растут. Этой же цели и скриншоты с watch для gST служат.
И, в целях обучения же, не стал пока с Status возиться, который по фен-шуй полагается анализировать для OutputString() — все равно там только EFI_SUCCESS будет, нет смысла показывать новичкам, что он всегда такой, он иногда очень даже полезен :)

Спасибо, все очень доступно! Планируете описать процесс деплоя драйвера в виртуалку более подробно? Интересуюсь с целью встраивания данного подхода в CI.

Что означает «процесс деплоя драйвера в виртуалку»?

— встроить драйвер в NVRAM, по аналогии с Линуксом — в ядро, чтобы не грузить каждый раз при помощи startup.nsh?

Это просто — открываем C:\fw\edk2\Nt32PkgNt32Pkg.fdf и прописываем внизу списка модулей, следующих за строкой "# DXE Phase modules", ставшую нам знакомой строчку

EducationPkg/MyFirstDriver/MyFirstDriver.inf

После чего надо закомментировать загрузку нашего драйвера в startup.nsh и все, после перекомпиляции MyFirstDriver будет сидеть в NVRAM.
Я умышленно не стал этого делать, поскольку драйвер явно не из тех, что требуется иметь всегда :) Он к тому же останавливает загрузку, требуя ручного ввода.

— показать реализацию функций драйвера Loadimage() — StartImage — UnloadImage() и Supported() — Start() — Stop() — Unload() в соответствии с UEFI Driver Model?

В руководствах (Zimmer, Charlstrom) это объяснено довольно запутанно, точнее, нормально по отдельности, но слабо воспринимается в комплексе. У меня есть готовая статья на эту тему, но там именно объяснения, как это все работает, своего кода немного. Я боюсь, никто не будет ее читать, народ любит сам попрограммировать — а время на подготовку статьи немаленькое, бесполезный шлак выпускать не хочется, надо все из статьи досконально в VirtualBox на «чистом» дереве edk2 проверять, постоянно думая, что из очевидного (для меня) надо описывать в тексте, и описывать подробно.

И что такое Cl в данном контексте?

Имелось в виду, где происходит монтирование файловой системы виртуалки для загрузки собранного драйвера, какие средства под Windows для этого используются, как собственно запускается образ ВМ (qemu?) Возможно ли это использовать в отрыве от edk2.

Если нужно что-то вроде cookbook для qemu под Windows, то вот оно.

А глубже — надо документацию читать, на их сайте, или перевод

edk2 тут вообще не нужен, он использует порт qemu под названием ovmf, с ограничениями, которые ни к чему без необходимости
Замечательная статья, Николай, спасибо. В отличии от первой, лично для себя отметил что-то новое. Приятно, что «UEFI-энтузиастов» становится больше.
Only those users with full accounts are able to leave comments. Log in, please.