UEFI inferences.

[d2alphame]

I intend to put here a few things I can draw from reading the UEFI specs (spec 2.3.1). I might likely add to this as time goes on. So, here's a few things;

Firmware boots up in long mode 64bits (this is good news for those of us targeting 64bits), and also with paging enabled (though memory is identity mapped)

[Brendan]

Hi,

Firmware boots up in long mode 64bits (this is good news for those of us targeting 64bits), and also with paging enabled (though memory is identity mapped)

On 80x86; UEFI firmware may be 64-bit with "identity mapped" paging, or 32-bit without paging.

I'm not too sure how many systems with 64-bit CPUs use 32-bit UEFI firmware. I know there are older Apple machines like this; but I also think Windows doesn't support 32-bit UEFI at all (so I doubt there'd be many "white box" 80x86 machines with 32-bit UEFI).


Cheers,

Brendan

[d2alphame]

I'm at a point where I need to buy real UEFI hardware (Phoenix or AMI) to continue (just saying).

So I need to check out the PE32+ header format specifications. I'm programming in NASM... If I can write a header in NASM to #include with my uefi programs... all I know is that uefi images have a PE32+ header without the import/export tables and the relocation tables (UEFI specs 2.3.1 errata C) and also new values for subsystem and machine type fields. The new values are


for SUBSYSTEM

Efi Application = 10
Boot Service Driver = 11
Runtime Driver = 12



for MACHINE TYPE

IA32 = 0x014c
IA64 = 0x0200
Efi Byte Code = 0x0ebc
x64 = 0x8664
ARMTHUMB-MIXED = 0x01c2


In my case I'm only interested in the Subsystem values and x64 under machine type

[d2alphame]

Hi,

Firmware boots up in long mode 64bits (this is good news for those of us targeting 64bits), and also with paging enabled (though memory is identity mapped)

On 80x86; UEFI firmware may be 64-bit with "identity mapped" paging, or 32-bit without paging.

I'm not too sure how many systems with 64-bit CPUs use 32-bit UEFI firmware. I know there are older Apple machines like this; but I also think Windows doesn't support 32-bit UEFI at all (so I doubt there'd be many "white box" 80x86 machines with 32-bit UEFI).


Cheers,

Brendan

Thanks for the tip Brendan. Wow! Windows doesn't support 32-bit UEFI at all!?

[Antti]

If you are going to do PE32+ header manually, I recommend that you do not use the relocation table at all (position independent code). Also, set SectionAlignment and FileAligment to value 4096. This simplifies things.

[feryno]

I'm at a point where I need to buy real UEFI hardware (Phoenix or AMI) to continue (just saying).

qemu + OVMF is not not enough?
http://sourceforge.net/apps/mediawiki/t ... title=OVMF

[d2alphame]

If you are going to do PE32+ header manually, I recommend that you do not use the relocation table at all (position independent code). Also, set SectionAlignment and FileAligment to value 4096. This simplifies things.

In fact UEFI says "no relocation tables!" the Alignment stuff is new though, I'll remember to stick to that. Thanks.

qemu + OVMF is not not enough?

I like to use vmware player (I don't trust emulators at all - and I don't even trust vmware player either). My plan for my os is for real hardware.

[d2alphame]

Continuing with my inferences. (on x64) when firmware makes a call to your os loader or uefi apps, a handle to your app/loader is passed in the RCX register, a pointer to the system table is passed in the RDX register and the return address in RSP. The system table contains among other things, console in and console out stuffs, a pointer the boot services table, a pointer to the runtime services table, a pointer to the configuration table, etc

[Antti]

If you look at the Microsoft x64 calling convention (UEFI uses it), you notice that RCX and RDX registers are used for passing the parameters. So those registers are not just "random."

[d2alphame]

If you look at the Microsoft x64 calling convention (UEFI uses it), you notice that RCX and RDX registers are used for passing the parameters. So those registers are not just "random."

Thanks man

[d2alphame]

Further inferences: During boot, 128kb (131072 bytes) of stack space is provided.