EFI программирование.

Помогите разобраться.
научился выводить текст. но он только английский.
если писать по русски то выводятся '?'

мне надо загрузить свой шрифт, но не могу понять как? может кто знает, помогите.

 

Одна загрузка шрифта тебе не поможет.
http://wiki.phoenix.com/wiki/index.php/EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL
Тут есть подсказка, откуда начать копать.

 

я уже читал. и пользуюсь именно этим. но на экране видно только английские буквы.
вместо остальных (пробовал и просто ascii и unicode) выводятся '?'.

я даже загружал шрифт через порты. как в dos. если выводить через память(b8000h) то все нормально. а если через
EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL то картина таже.

я так понял что надо использовать HII сервис. но не могу понять как.

 

Нет, не читали. В примечании к OutputString() на этой странице есть ответ на ваш вопрос.
А код статуса точно указывает на причину ошибки. Он же у вас "EFI_WARN_UNKNOWN_GLYPH", я угадал?

 

я через эмулятор пробую. ошибок нет.
а на uefi Home. мне уже ответили. какими функциями пользоваться. не хватает только примера.
не совсем понимаю как должна выглядеть структура с шрифтом.

вот ихный ответ:
There are three scenarios:



1) You want to display Cyrillic characters using the Unicode character values. (supported through HII standard font)

2) You want to display Cyrillic characters using characters 0-255 (i.e. as if you replaced the VGA font with INT 0x10) (not supported)

3) You want to input characters from a keyboard and have Cyrillic displayed. (supported through HII keyboard layout)



For #1, the font can be uploaded using the HII Database (ch. 29.4) in the UEFI specification. The format of the font packages is described in ch. 28.3.2 (simplified 8x19)



Also on www.tianocore.org, there is a utility called “DriverSample” that attempts to test a bunch of the HII interface components, and there is also a GraphicsConsole driver which manages the uploading of the font data into the font protocol.

 

MisHel64
я уже почти разобрался только не пойма что писать в GUID. самому придумать?
и как проверить что он такой один?

 

abcd008
Хотелось бы поднять тему! Получилось ли что-то. Если да, можете, пожалуйста, написать, что да как?

 

яб и сам непрочь поднять тему, только некто не чего незнает.

что именно интересует? я сам немного разобрался. сейчас завис на вопросе загрузки шрифта. но пока нет времени работаю над PXE.

вот здесь есть пример http://x86asm.net/articles/uefi-programming-first-steps/
чтоб правильно работало надо закомментировать последнюю строку (section '.reloc' fixups data discardable), а то последние версии fasm не правильно работают с x64 reloc

для вызовов функцый можно использовать PROC64.inc (invok или fastcall)
сами параметры описаны в uefi спецификации.

для проверки кода я гдето брал эмулятор для загрузочной флешки(но это неудобно. надо перезагружаться каждый раз), сейчас тестирую в virtualbox(все устраивает, правда для x64 пришлось ставить 64 битную ОС)

 

Вот тут ещё есть интересное
http://uefi.blogspot.com/2009/09/uefi-hii-part-1.html

А что, PXE под UEFI занимаешься???

 

нет там сложно, да и невстречал еще не железа не эмулятора для проверки. поэтому пока разбираюсь толлько с обычным pxe из под биос

 

поповоду шрифтов. можно разобраться со структурой данных. но я не пойму какой функцыей грузить шрифт
NewPackageList
UpdatePackageList

самый большой вопрос что писать в guid

 

По функциям - пока с HII не разбирался.
А GUID - можно придумать самому. Те, которые общеприняты, указаны в стандарте. Вроде как даже в инструкции к EDK сказано, что используемые там нестандартизированные GUID, требуются в установке в систему.
Думаю, большие производители используют генераторы случайных чисел для своих GUID. 128 битное число, которое ну очень сложно повторить. Так что переживать за то, что с кем-то пересечёшься.
А вообще, в Appendix A спецификации UEFI 2.3.1.( таблица 209) указан формат GUID. Есть ссылка на RFC4122. Плюс в GUID присутствует временная метка.
Ну и в конце концов, всегда можно использовать хеш-функцию от чего-то личного. Тут уж как тоже не повторишь.

 

abcd008

Это предыдущие неправильно с релоками работают. Когда нет мест, требующих релокаций, старые версии создают в таблице пустой блок с невалидным RVA. Правильное поведение — создавать пустую секцию релоков, как это делают последние версии fasm.

 

правильно нен пустую саздавать , а вообще не делать.
а то он создает ссылку с размером, а в таблице пусто и размер нулевой.

может оно по вашему и правильно, но не один эмулятор с таким файлом efi не работает, и на реальном железе тоже не хочет, а вот если закомментировать(убрать релок вообще). то все прекрасно работает. я долго ломал голову почему мои проги не работали, потом понял что это из за релок. теперь я либо компилирую на старой версии фасм или без релок

 

lsvmo
прокрутку экрана я думаю ты не как не уберешь. так же как и биос, при записи последнего символа, он переходит на следующую строку.
чтоб от этого избавится нужно самому писать код вывода на экран, на прямую через память.

 

abcd008

Смешно. Правильно с чьей точки зрения? Вы ведь сами fasm'у говорите делать секцию релоков, вот он и не своельничает, покорно делает. А раз релоцировать нечего, то будьте добры получите, что заказывали.

Ясно дело, что не работает. Поэтому либо вообще не говорите делать fasm'у секцию релокаций, либо гарантируйте хотя бы одно слово, требующее релокации. Например, вставив куда-нибудь dq $ .

 

я с тобой согласен.
но когда код большой, невсегда знаешь есть релеки или нет. поэтому и создаешь секцию.

 

abcd008
Большому коду ведь не страшно лишние восемь байт заиметь, как цену за гарантию наличия? После чего создавайте на здоровье.

 

если честно то я думал раньше что x64 позиционно независим. он же весь от rip пляшет.?
dq $ -возьму на заметку)

 

abcd008

Не обязательно. Например, можно загрузить адрес так: lea rax,[var], а можно так: mov rax,var. Первый вариант будет базонезависим, а вот второй потребует релокацию. Для аналогичного 32-битного кода, естесственно, оба варианта требуют релокацию.
Ну а если уж писать dq $, то это вообще просто инициализированные данные, а не код. Никакая rip-относительная адресация не позволит сделать адресонезависимым само значение адреса.