или я чтото пропустил, или плохо искал, но не нашел ничего путного по теме :(
а потому решил поделиться мелочами на ниве взращивания драйверов для ЕФИ.
Мои познания о драйверах основываются на ДОСе (старожилы помнят талмуд R.Jourdain), т.е. есть железо знакомое нам и им надо управлять.
Как известно в ЕФИ отсутствуют прерывания, как класс, применяется поллинг-
Стратегия выбирается такая: создается драйвер со стандартным протоколом (EFI_DRIVER_BINDING_PROTOCOL) , т.е. в точке входа мы обьявляем системе - что его поддерживаем (функции Support/Start/Stop) и выходим из точки старта.
Система принимает к сведению, что новый драйверок подвешан и начинает его "скармливать" существующим в системе контроллерам, т.е.функция Support нашего драйвера начинает вызываться поочередно всеми контроллерами, и мы анализируя DevicePath контроллера - решаем поддерживаем мы его (повиснем мы на нем) или нет. Если мы не наком не повиснем то наша функция Start так и не запустится, или запустится тем кого поддержим.
Да , кстати , если мы кого поддерживаем то мы могем обьявить свои протоколы для управления драйвером из вне.
Наш Start запускает таймер на поллинг.
драйвер у нас будет учебный, я например довольствовался выводом в порт 0х80
но добавил для наглядности и вывод на экран
прилагаемый test.efi - 32 разрядный для EDKII
хотя сам я тренировался на х64AMI версии
тут возникает вопрос на кого "вешаться", вопрос не праздный
информации о контроллере у нас с гулькин нос, поетому ковыряемся в DevicePath,
вот тут и выясняются преимущества реального железа перед симулятором, в симуляторе мы видим GUID, а он малоинформативен, другое дело в железе - информации пруд пруди - я например вешал драйвер на PS/2 клаву,
в симуляторе пришлось вешать на GUID="0x4E11E955-...." т.е.TxtIn/Out
драйвер запускается в Shell командой "load test.efi"
наличие его в системе проверяется командами "dh -d -v -b" и "drivers"
после запуска в нижнем правом углу экрана видим меняющуюся цифру как результат поллинга
как на наш драйвер можно "повлиять" из вне ? именно для етого в нашем драйвере предусмотрен собственный протокол !!
добавляем приложение (Test2.efi)которое сначала ищет наш протокол по GUID, а потом управляет направлением счета или его возможностью
функции загрузки драйвера приложением и его выгрузки пока не поддерживаются
вы спросите, а где же OpRom? вот для этого наш test.efi обрабатывается EfiRom.exe
я тренировался так
"efirom -v 8086 -d 0x10EA -e test.efi "
т.е. подтасовал его под гигабитную сетевушку ,
и загружал свежеиспеченный OpROM в Shell командой "LoadPciRom test.rom".
позже прилепил к биосу и радовался бегущей цифре и в СетапМеню и в Shell
как то так ...
трудно предположить для чего они бывают, и как ими "пользоваться", с ужасом представляю себе, что кто-то черпает оттуда, чертовски полезные "дату/время".
Документация по етому поводу говорит - "пользуйтесь как старыми добрыми прерываниями БИОСа", достаточно "щедрое" описание ;) (из под виртуальных машин и пр.)
Но есть одно приятное "но", повесить свой RUN-Time сервис в SMM/SMI.
Да, RUN-Time сервисы можно вешать как коллбэк в SMI, мало того - можно и на периодический SMI таймер 8/16/64 секунд (АМИ) и пользоваться ими "откуда попало"
Правда праздник сердца прекращается по наступлении BDS фазы, это и логично - ЕФИ серьезная вестч , а не рассадник вирусов
PS: а еще в EFI до безобразия просто (из Shell) добавляются собственные ACPI таблицы, но это уже совсем другая история