Свой модуль для EFI

Заметил особенность:
BIOSPatcher распознает модуль , а PhoenixTOOL нет (т.е. не извлекает его и т.д.). При том что я рассчитываю как контрольную сумму заголовка модуля, так и всего файла по спецификации. Что еще знает PhoenixTOOL о модулях, чего не знаю я?
Кстати, как называется поле (структура) в заголовке которое идет File State (d нем хранится истинный размер модуля без заголовка и File Tail)? Это EFI_COMMON_SECTION_HEADER?

К сожалению, не могу помочь Miyka...

Но с удовольствием поделюсь с начинающими ссылками, после прочтения которых ( ну и спецификации UEFI) можно порадоваться написанному HelloWord

x86asm.net/articles/uefi-programming-first-steps/index.html

А чел, написавший её довольно интересный...
media.blackhat.com/bh-usa-08/video/bh-us-08-Bailey/black-hat-usa-08-bailey...
Вот его продукты
hypervista-tech.com/our_products.html

И параллельно вопрос.
Кто-нибудь занимался созданием UEFI PCI Extension ROM Option? Там практически всё то же самое, что и для обычного Legacy PCI ROM.
Но может кто-нибудь посоветовать, как его собирать, может, есть в EDK автоматические инструменты и как строить свой код...?

О не верю своим глазам, кто то ответил на мой вопрос.
lsvmo, огромное спасибо за эти бесценные ссылки.
UEFI PCI Extension ROM Option это исполняемые в реальном режиме или что? (у меня туговато с терминологией)
А вы как, а точнее где запускаете собранные ромы? В SHELL или на станции?

Option ROM - то, что прошивается в BIOS плат расширений (типа PCI, PCI-E, сетевой карты).
В новой терминологии Legacy Option ROM - это код расширения, работающий без EFI, и соответственно
UEFI PCI Extension ROM Option - та же фигня, только написанная под EFI.

Старый (Legacy) код расширения исполнялся в реальном режиме, точнее (скорее всего) в эмуляции 16-битного из 32-битного.

Исполняется ли UEFI в реальном режиме - вряд ли. Насколько я понял из спецификации новый механизм приспособлен под выполнение в нормальных режимах процессора. Есть даже возможность писать код под виртуальную машину UEFI.

Собранный hello.efi запускается в Shell'е. Только как-то смешно у меня получилось. Есть плата с процом Intel Atom и поддержкой em64T. Компилятор и линкер использовал из Visual Studio из папки AMD, заголовки для EFI указывал em64T. EDK II скачан с Intel'а. Только тогда это сработало. Обычный компилятор, из директорий IA32, IA64, x86_IA32, x86_IA64 - пишет при запуске, что shell не поддерживает данную архитектуру.

Кстати, в статьях указаны инструменты из предыдущих EDK. В новом EDK есть утилита GenFw, которая поддерживает больше конечных форм файла .efi.
Есть EfiRom, которой на фход подаёшь файл .efi, а она делает образ для ROM.
Но обычный Hello Word там почему-то не работает. Как понять, передаётся ли туда вообще код - не понятно. Какой образ туда запихивать - тоже. Application или BootService.
В общем, не понятно как вызывается этот код из ROM'a. И есть ли в BIOS реализация этого вызова.

Покопался тут ещё.
Образ туда запихивается (см. 13.4.2.1 UEFI Spec 2_3_1) BootService Или Runtime Service. Приложения не выполняются, хотя запихнуть их туда можно и можно даже как-то вызвать, но другими методами. Вывод на экран, возможно, не действует (но это по спецификации 1.10). Работа с клавой тоже.

Остаётся непонятным, как должен быть устроен код. Чтобы его откомпилить и хоть что-то получить.

Код для UEFI PCI Extension ROM Option это EFI-драйвер (MODULE_TYPE = UEFI_DRIVER ).
Далее все как для обычных драйверов EFI. Rom генерируется путем склеивания "обычного" ROM-bios модуля и UEFI в сжатом виде, к которому добавляется обычный заголовок ROM-модуля. ПЗУ для прошивки должно быть соответствующего размера, для вмещения такого "двойного модуля".

както так ...
uefi.org/learning_center/UPFS11_P6_OptionROM_AMI.pdf

ключевые слова:
- "Common OpROMCombos"

к сожалению (и как всегда)
для опытов в данной области одного желания мало
даже если я/ты/он/она ... и слеплю UEFI OpROM ... то куда я его "залью"
что бы протестировать/отладить??

PS:ссылки на "конструкторы" т.е. железо (PCI/PCIe) куда "заливать" приветствуются

PS2: и ещё для общего развития
uefi.blogspot.com/2010/04/uefi-hii-hacking.html
uefi.blogspot.com/2009/09/uefi-hii-part-1.html

awoland> Далее все как для обычных драйверов EFI.

фраза может вызывать налет замешательства для начинающих (коим и я являюсь)
попала в руки книжеца:
"Harnessing the UEFI Shell" Moving the platform beyond DOS. Intel Press. ISBN 978-1-934053-14-0

а в ней : Chapter 11. Managing UEFI Drivers Using the Shell

далее описывантся какие функции должен поддерживать драйвет и какими командами из
шела можно проверять их доступность/функциональность
пример Table11.1

команда________ тестируемый сервис
load -nc_______ DriverEntryPoint()/Supported()
load___________ DriverEntryPoint()/Supported() / Start()
unload_________ Unload
connect________ Supported() / Start()
disconnect_____ Stop()
reconnect______ Supported() / Start() / Stop()
drivers________ GetDriverName()
devices________ GetControllerName()
devtree________ GetControllerName()
dh -d__________ GetControllerName() / GetDriverName()
drvcfg -s______ SetOptions()
и пр.

чередуя с "memmap" и "dh" смотрим что работает/не работает
утилита "EfiRom" преобразует наш/ваш "Driver.efi" во что надо
а команда "loadpcirom" продолжет тестирование до прошивки в железо

комментарии практикующих "драйверо-писателей" приветствуются