Index
> Main > x64 UEFI supportGoto page 1, 2, 3 Next |
| Author |
|
|
XVilka 29 May 2012, 12:18
Hello!
I'm trying to write small hello world application for UEFI, like in article http://x86asm.net/articles/uefi-programming-first-steps/index.html But that example doesnt work on any UEFI hardware I have - it have wrong header. Also for UEFI it should not produce MZ DOS stub, just fill it by zeroes. Code: format pe64 dll efi entry main section '.text' code executable readable include 'efi.inc' main: ... section '.data' data readable writeable Handle dq ? SystemTable dq ? _hello du 'Hello World',13,10,'(From EFI app written in FASM)',13,10,0 section '.reloc' fixups data discardable |
|||
29 May 2012, 12:18 |
|
|
Tomasz Grysztar 29 May 2012, 12:29
You can create the empty stub this way:
Code: format PE64 EFI DLL on 'nul' And what is wrong with the header? |
|||
|
29 May 2012, 12:29 |
|
|
XVilka 29 May 2012, 13:18
Thx! Thats looks better.
Attached hello.efi - invalid UEFI image Here is output from UEFI Shell: Code: fs0:\> load hello.efi load: fs0:\HELLO.EFI is not a image Exit status code: Invalid Parameter Also attached valid UEFI image: Code: fs0:\> load valid.efi ReadyToBoot()load: Image fs0:\valid.efi loaded at 2ADD000 - Success
|
|||||||||||||||||||||
|
29 May 2012, 13:18 |
|
|
XVilka 29 May 2012, 16:55
btw, updated a bit 'efi.inc' file, attached
|
|||||||||||
|
29 May 2012, 16:55 |
|
|
Feryno 30 May 2012, 08:53
Hi,
I'll try to run you files at my home PC (AMD FX-4100, ASUS M5A99X EVO with AMI UEFI version 0901) but won't have time to do that earlier than at weekend (I'm currently too busy and outside all free time). The PC I'm sitting in front of just now has BIOS, not UEFI. Could you try EFIRUNTIME flag also? Could you try to copy your program into USB disk into /efi/boot/bootx64.efi (your program should be compiled with EFIBOOT flag then) and boot it? What MB and CPU do you have? If you have Intel CPU, could you test this please: http://board.flatassembler.net/topic.php?p=142450#142450 (whether it even runs, it uses some special detection procedures scanning Intel Debug feature MSRs, AMD has them stable but Intel uses 3 versions of these MSRs and maybe more in feature, I didn't want to assign MSRs where are they after cpuid more than 100 various models) |
|||
|
30 May 2012, 08:53 |
|
|
XVilka 30 May 2012, 10:33
Feryno: what kind of output you need? I have both Intel-based and AMD based UEFI boards, both modern.
Btw, are there any way to save output/log of debugger somewhere? It will be very useful for both using and testing. (Posted in FDBG thread) About invalid images - see attached source hello.asm + uefi.inc and produced efi image - invalid efi image (can't be loaded in shell or from option rom) This is just stub, so can't understand whats wrong.
|
|||||||||||
|
30 May 2012, 10:33 |
|
|
Feryno 30 May 2012, 13:22
It will be some flag somewhere
The uefi fdbg is very limited (version 0000), you can't even load your program, must be compiled with the debugger into 1 file Thank for reporting well behaviour on Intel CPU |
|||
|
30 May 2012, 13:22 |
|
|
Feryno 31 May 2012, 05:16
does this help or not at your PC:
Code: format pe64 dll efiruntime or this: Code: format pe64 dll efiboot personally I also managed to run uefi shell from external drive (USB flash), have also AMI UEFI from the uefi shell I managed to run only incompiled commands, never succeeded with running any external program maybe the load command built-in uefi shell is only for loading drivers and not common applications? (so the idea using EFIRUNTIME flag) |
|||
|
31 May 2012, 05:16 |
|
|
XVilka 31 May 2012, 07:19
so, results are same for all
hello2.efi: Code:
format PE64 dll efi on 'nul'
Code:
format PE64 dll efiboot on 'nul'
Code:
format PE64 dll efiruntime on 'nul'
Produced files have these differences in header:
First timestamp, then 4 bytes checksum, so produced files differ only in right way - with PE.OptionalHeader.Subsystem at 0x9C offset. strange. all other looks same It doesnt start even if i place it in /efi/boot/bootx64.efi |
|||
|
31 May 2012, 07:19 |
|
|
Feryno 31 May 2012, 10:00
yes, differences are in timestamp+checksum and the last byte means:
0Ah=10=EFI 0B=EFIBOOT 0C=EFIRUNTIME When I played with efi shell (months ago) I tried to execute external programs directly = without the load command, but never succeeded... According the video at this page the load command should not be necessary: http://diit.cz/clanek/instalace-windows-7-x64-pres-efi look at the video in the middle of the page I also remembered that something changed in FASM few months ago (maybe year, time passes with different speed for me now, so have bad personal approximations) when added support for large PE images then I was unable to run win64 drivers, had to revert to older version of FASM, but it lacked some instructions I needed so I used newer version and edited something in FASM source and recompiled the binary |
|||
|
31 May 2012, 10:00 |
|
|
Feryno 31 May 2012, 10:07
found that modification necessary for win x64 drivers, luckily have an USB flash disk with me and searched archives with string I rememberer 'compiled with'
; compiled with patched version of fasm 1.69.31 ; this had to be modified in FASM: ; formats.inc ; orignal: mov dword [edx+16h],20B002Fh; flags and magic value ; corrected: mov dword [edx+16h],20B002Eh; flags and magic value ; orignal: mov byte [edx+5Eh+1],1 ; corrected: mov byte [edx+5Eh+1],0 |
|||
|
31 May 2012, 10:07 |
|
|
Tomasz Grysztar 31 May 2012, 10:30
Feryno wrote: ; orignal: mov dword [edx+16h],20B002Fh; flags and magic value Feryno wrote: ; orignal: mov byte [edx+5Eh+1],1 |
|||
|
31 May 2012, 10:30 |
|
|
XVilka 31 May 2012, 11:17
And here attached parsed PE header of valid (successfully booting EFI image, even with "load valid.efi" command from the shell), in CSV format
And here it is available online http://pastie.org/private/nqpnpykoaoq5oawbgkjdja
|
|||||||||||
|
31 May 2012, 11:17 |
|
|
Feryno 31 May 2012, 12:49
found also this difference:
DllCharacteristics: valid 0 invalid 40h it is the word after word subsystem |
|||
|
31 May 2012, 12:49 |
|
|
Tomasz Grysztar 31 May 2012, 13:28
Feryno wrote: found also this difference: |
|||
|
31 May 2012, 13:28 |
|
|
Feryno 01 Jun 2012, 09:42
IMAGE_OPTIONAL_HEADER64.ImageBase = 0 for valid, 400000h for invalid
XVilka could you test these headers: Code: format PE64 dll efi on 'nul' at 0 Code: format PE64 dll efiboot on 'nul' at 0 |
|||
|
01 Jun 2012, 09:42 |
|
|
XVilka 01 Jun 2012, 10:48
Of course you mean
Code: format PE64 dll efi at 0 on 'nul' Though both still give me error when trying to do "load" command or just calling directly. It is strange, that "load fdbg.efi" give me error, that "Image fs0:\fdbg.efi is not a driver", while just typing "fdbg.efi" and pressing enter works ok So, looks like "load" command works only for drivers, while direct execution works only for applications. |
|||
|
01 Jun 2012, 10:48 |
|
|
Feryno 01 Jun 2012, 12:40
Yes, it seems the load command is used to load drivers only (EFIRUNTIME should be driver?, EFIBOOT should be boot manager?, EFI should be common program?)
fdbg.efi is compiled as an application (EFI) I even didn't succeed to run the fdbg.efi using uefi shell, had success only booting it /efi/boot/bootx64.efi Must try it again, now it is rainy otside so I can not work there and return home to perform some tests. fdbg.efi has quite huge sections, maybe UEFI refuses to load too small images or images with too small sections maybe UEFI refuses to load images with empty relocs ? I must test this also. |
|||
|
01 Jun 2012, 12:40 |
|
|
XVilka 04 Jun 2012, 07:24
Feryno: So, any news about testing (you wrote, that you can do weekend)? Or may be new ideas?
|
|||
|
04 Jun 2012, 07:24 |
|
| Goto page 1, 2, 3 Next < Last Thread | Next Thread > |
Forum Rules:
|