Can anyone see anything wrong with the below?[...]
000000 4D5A9000 03000000 04000000 FFFF0000 MZ..............
000010 B8000000 00000000 40000000 00000000 ........@.......
000020 00000000 00000000 00000000 00000000 ................
000030 00000000 00000000 00000000 80000000 ................
000040 0E1FBA0E 00B409CD 21B8014C CD215468 ........!..L.!Th
000050 69732070 726F6772 616D2063 616E6E6F is program canno
000060 74206265 2072756E 20696E20 444F5320 t be run in DOS
000070 6D6F6465 2E0D0D0A 24000000 00000000 mode....$.......
000080 50450000 64860300 E0079363 00000000 PE..d......c....
000090 00000000 F0002E22 0B020216 00020000 ......."........
000090 00000000 F0002E22 0B020216 00020000 ......."........-----------------------^^^^
In the "characteristics" it's marked as a DLL.
Change 2E22 to 2E02 (shown as little endian here) to make it an exe.
"<muta...@gmail.com>" wrote:
[...]
As a Win64 executable it does in fact loop.
But as an EFI app it just returns immediately without error.
At least under Oracle Virtualbox.
It's an infinite loop so that suggests it's not being run at all.
On real hardware I get an error about no OS,
Your at a level before the main OS is loaded. Is it complaining about
that or does the EFI need to be running its own mini OS first?
I've also no experience with (U)EFI code but I notice there can be
other settings for that value:
EFI boot driver
EFI runtime driver
EFI ROM driver
You said you wanted a boot loader which you may need before you can
run any EFI app (I don't know!).
I also don't know if the major and
minor subsystem version fields are relevant (they are for a normal
Win executable).
Also, what purpose does the exported name "_efimain" serve? Does there
need to be any code there?
As a Win64 executable it does in fact loop.
But as an EFI app it just returns immediately without error.
At least under Oracle Virtualbox.
On real hardware I get an error about no OS,
but I have no experience on UEFI on real
hardware so I don't know if I'm doing something wrong.
The file is called EFI\BOOT\BOOTX64.EFI
It is zapped to subsystem 10:
0000D0 00400000 00040000 8F610000 0A000000 .@.......a......
Any ideas?
On Saturday, December 10, 2022 at 5:27:40 AM UTC+8, Apd wrote:
It's an infinite loop so that suggests it's not being run at all.
Right. But if I just type in "fff" or something, I get
command not found (in UEFI shell), so it can
clearly see the EFI.
You're at a level before the main OS is loaded. Is it complaining
about that or does the EFI need to be running its own mini OS first?
My EFI *is* destined to be the main OS. A 64-bit
version of PDOS (http://pdos.org).
I do not have any idea what is happening.
You said you wanted a boot loader which you may need before you can
run any EFI app (I don't know!).
This *is* the boot loader. The firmware should directly
find this. But if you can get an EFI shell (some computers
have this, but I'm using Oracle virtualbox to give me that),
you can operate it like MSDOS except the executables are
called .efi and you can cd to the location and type their
name.
Also, what purpose does the exported name "_efimain" serve? Does there
need to be any code there?
From looking at the web, it looks like you can have any
name for the entry point.
But yes, the 32-bit version has just "efimain", even though
the assembler has "_efimain" - I don't know why the
underscore is being stripped.
But I assume that that wouldn't be an issue because the
name was flexible, and I expected the system to look at
the entry point address, not exported symbols.
What do you mean by "does there need to be any code there"?
All the code (ie the loop) is at the _efimain location.
Right. But if I just type in "fff" or something, I get
command not found (in UEFI shell), so it can
clearly see the EFI.
Sounds like you need some way of debugging this.
You're at a level before the main OS is loaded. Is it complaining
about that or does the EFI need to be running its own mini OS first?
My EFI *is* destined to be the main OS. A 64-bit
version of PDOS (http://pdos.org).
I didn't know that was possible.
From looking at the web, it looks like you can have any
name for the entry point.
Maybe it doesn't need that export at all.
Another thing is I notice the checksum field is filled in your last
hex dump and it's invalid (it was ok for the original DLL you made).
Do EFI apps require this? I know it's needed for kernel mode
executables but isn't for user mode ones.
On Saturday, December 10, 2022 at 7:45:58 AM UTC+8, Apd wrote:
My EFI *is* destined to be the main OS. A 64-bit
version of PDOS (http://pdos.org).
I didn't know that was possible.
What did you think the boot sequence was on a modern 64-bit machine?
Is the subsystem number included in the checksum?
How did you determine the checksum was wrong?
Given that kernel executables require the checksum to be
correct, can I get my "return (5);" executable to be a kernel
program so that I can at least see if Windows agrees that
the checksum is correct?
Then I could zap from 3 to A, then zap the checksum by 7,
if the subsystem is included.
Finally, can you tell me if this executable has the correct
checksum?
"<muta...@gmail.com>" wrote:
On Saturday, December 10, 2022 at 7:45:58 AM UTC+8, Apd wrote:
My EFI *is* destined to be the main OS. A 64-bit
version of PDOS (http://pdos.org).
I didn't know that was possible.
What did you think the boot sequence was on a modern 64-bit machine?I mean that I didn't know you could use PDOS to get an EFI shell and
that PDOS could run Win PE files.
Is the subsystem number included in the checksum?Yes.
How did you determine the checksum was wrong?I have "Dependency Walker" which highlights the checksum in red if
it's invalid.
Given that kernel executables require the checksum to beI don't know. Kernel mode programs are usually drivers loaded by the
correct, can I get my "return (5);" executable to be a kernel
program so that I can at least see if Windows agrees that
the checksum is correct?
OS. Yours isn't built like that.
Then I could zap from 3 to A, then zap the checksum by 7,
if the subsystem is included.
Finally, can you tell me if this executable has the correctYes.
checksum?
Another thought. Are you sure the EFI is 64bit? I have an old Mac with
a 32bit EFI and a 64bit processor.
Another thought. Are you sure the EFI is 64bit? I have an old Mac with
a 32bit EFI and a 64bit processor.
LFB1:
pushq %rcx
LCFI0:
movb $88, 4(%rsp)
movb $0, 5(%rsp)
movb $0, 6(%rsp)
movb $0, 7(%rsp)
movq 60(%rdx), %rax
movq %rax, %rcx
leaq 4(%rsp), %rdx
pushq %r11
pushq %r11
pushq %r11
pushq %r11
call *8(%rax)
sys->simple->print_func(sys->simple, zzz);
movq 60(%rdx), %rax
movq %rax, %rcx
leaq 4(%rsp), %rdx
pushq %r11
pushq %r11
pushq %r11
pushq %r11
call *8(%rax)
Presumably this call does the display. How? What do you expect RAX to contain?
I notice you have no imported library (dll) to call from so,
either you need one or it's doing a direct syscall of some kind into
the OS.
sys->simple->print_func(sys->simple, zzz);
So you need to check this routine to make sure your exe can find and
call it correctly, either from an import library or as some offset
into system memory where the routine lives, as perhaps you are trying
to do.
On Sunday, December 11, 2022 at 9:12:32 PM UTC+8, Apd wrote:
movq 60(%rdx), %rax
movq %rax, %rcx
leaq 4(%rsp), %rdx
pushq %r11
pushq %r11
pushq %r11
pushq %r11
call *8(%rax)
Presumably this call does the display. How? What do you expect RAX to contain?Here is someone else's code that calls the exact
same function:
https://github.com/utshina/uefi-simple/blob/master/main.c
Just under a different name. But same offset - 60.
I notice you have no imported library (dll) to call from so,UEFI is basically a massive OS with syscalls, in the firmware.
either you need one or it's doing a direct syscall of some kind into
the OS.
But it doesn't use either DLLs or interrupts, it is instead
similar to the Amiga. The Amiga hardcodes the address
4, and then has a huge series of pointers from that
address.
UEFI instead gives you the long list of pointers via a pointer
to a struct that is placed "on the stack" (for 64-bit at least,
because the number of parameters is only 2, registers are
used instead of the actual stack) as per Microsoft convention.
sys->simple->print_func(sys->simple, zzz);
So you need to check this routine to make sure your exe can find andYes, the latter is exactly what I am trying to do, and I've
call it correctly, either from an import library or as some offset
into system memory where the routine lives, as perhaps you are trying
to do.
looked at the assembler a million times but can't see
anything wrong with it.
If this was PDOS, I would simply put debug into the OS
to see what is happening. But to do the equivalent here I would
need to figure out how to build the UEFI that comes with Qemu.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 379 |
Nodes: | 16 (2 / 14) |
Uptime: | 42:11:06 |
Calls: | 8,141 |
Calls today: | 4 |
Files: | 13,085 |
Messages: | 5,857,793 |