flat assembler
Message board for the users of flat assembler.

Index > Compiler Internals > FASM support for UEFI

Author
Thread Post new topic Reply to topic
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
I am starting this thread to make some "public push" on Tomasz Wink

Maybe you don't know, but there is nice emerging BIOS replacement, called UEFI. More info here: http://en.wikipedia.org/wiki/UEFI

I was thinking that FASM could easily support this, and be first assembler capable to produce UEFI files directly. UEFI uses normal 32bit and 64bit PE files, just with different subsystem value. All it would take to add support for generating UEFI executables, would be adding bunch of "format PE" specifiers to FASM. UEFI standard has exact binary interface, so assembly programming should be easily possible. UEFI PE has no imports, all needed information is passed as arguments to entry point procedure.

I promise that if Tomasz adds support for these formats, i will write few demos showing how to code UEFI app / driver in FASM.
Post 30 Jul 2008, 05:07
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7802
Location: Kraków, Poland
Tomasz Grysztar
Just let me know what identifiers you need and propose the names for them. Wink
Post 30 Jul 2008, 06:38
View user's profile Send private message Visit poster's website Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
"format PE UEFI32" and "format PE UEFI64"?

Too bad the board availability is still scarce, and the implementations "initial". Once it catches on, it could be pretty nice Smile
Post 30 Jul 2008, 10:27
View user's profile Send private message Visit poster's website Reply with quote
Madis731



Joined: 25 Sep 2003
Posts: 2140
Location: Estonia
Madis731
f0dder's offer seems to change PE version. Where it used to stand 3.1, 4.0, 5.1, there's UEFIxx now. Maybe rather "format PEFIxx" or "format PEUEFIxx" if we like to be verbose.
Post 30 Jul 2008, 13:56
View user's profile Send private message Visit poster's website Yahoo Messenger MSN Messenger Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7802
Location: Kraków, Poland
Tomasz Grysztar
No, f0dder is right, UEFI should be a subsystem keyword, like GUI/console/native.
Post 30 Jul 2008, 14:05
View user's profile Send private message Visit poster's website Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
It is bit more complicated. There are three types of UEFI executables: application, boot driver, and runtime driver.

UEFI specs wrote:
UEFI Images are a class of files defined by UEFI that contain executable code. The most distinguishing feature of UEFI Images is that the first set of bytes in the UEFI Image file contains an image header that defines the encoding of the executable image. UEFI uses a subset of the PE32+ image format with a modified header signature. The modification to the signature value in the PE32+ image is done to distinguish UEFI images from normal PE32 executables. The “+” addition to PE32 provides the 64-bit relocation fix-up extensions to standard PE32 format.

For images with the UEFI image signature, the Subsystem values in the PE image header are defined below. The major differences between image types are the memory type that the firmware will load the image into, and the action taken when the image’s entry point exits or returns. An application image is always unloaded when control is returned from the image’s entry point. A driver image is only unloaded if control is passed back with a UEFI error code.

// PE32+ Subsystem type for EFI images
#define EFI_IMAGE_SUBSYSTEM_EFI_APPLICATION 10
#define EFI_IMAGE_SUBSYSTEM_EFI_BOOT_SERVICE_DRIVER 11
#define EFI_IMAGE_SUBSYSTEM_EFI_RUNTIME_DRIVER 12


Terms "EFI" and "UEFI" are used interchangeably. More correct is "UEFI", but most people still use "EFI".

Another thing that (I believe) needs to be changed in header is CPU architecture:

Quote:

// PE32+ Machine type for EFI images
#define EFI_IMAGE_MACHINE_IA32 0x014c
#define EFI_IMAGE_MACHINE_IA64 0x0200
#define EFI_IMAGE_MACHINE_EBC 0x0EBC
#define EFI_IMAGE_MACHINE_x64 0x8664

EBC is EFI-specific byte code, not important for us. Neither IA64 / Itanium of course.

So my suggestion would be 3 new keywords, like: "efi", "efirt" (or "efiruntime"), "efibs" (or "efiboot"), and use them like:
Code:
format PE EFI
format PE EFIRT
format PE64 EFI
format PE64 EFIBS
    
Post 30 Jul 2008, 16:27
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
I just realized this means that PE+ is used even for 32-bit code. That could be a problem maybe... we'll see what Tomasz says...

If something is not sure, I can provide few 32-bit and 64-bit UEFI executable samples.
Post 30 Jul 2008, 16:48
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7802
Location: Kraków, Poland
Tomasz Grysztar
vid wrote:
Another thing that (I believe) needs to be changed in header is CPU architecture:

Quote:

// PE32+ Machine type for EFI images
#define EFI_IMAGE_MACHINE_IA32 0x014c
#define EFI_IMAGE_MACHINE_IA64 0x0200
#define EFI_IMAGE_MACHINE_EBC 0x0EBC
#define EFI_IMAGE_MACHINE_x64 0x8664

EBC is EFI-specific byte code, not important for us. Neither IA64 / Itanium of course.

These are exactly the same as standard PE machine types, no need to worry about this field.
Post 30 Jul 2008, 17:26
View user's profile Send private message Visit poster's website Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
I'd prefer "UEFIAPP", "UEFIBOOT", "UEFIRUNTIME" - looks less like alphabet soup than the abbreviated names, and you only need it once per app anyway. Don't think it's necessary to go all the way and do "application" and suffix "driver" to the two others, though Smile
Post 30 Jul 2008, 17:46
View user's profile Send private message Visit poster's website Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
f0dder: No problem with me. Doesn't matter as long as it is once per program, and at least we will prevent name collisions.

Tomasz: how about using PE+ for 32 bit executables? I think that is something new. Maybe I should send you example of 32bit UEFI executable?
Post 30 Jul 2008, 18:08
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7802
Location: Kraków, Poland
Tomasz Grysztar
vid wrote:
Tomasz: how about using PE+ for 32 bit executables? I think that is something new. Maybe I should send you example of 32bit UEFI executable?

You can do it. However the PE+ specs from Microsoft are quite clean, I have no trouble with them.
Post 30 Jul 2008, 18:30
View user's profile Send private message Visit poster's website Reply with quote
tom tobias



Joined: 09 Sep 2003
Posts: 1320
Location: usa
tom tobias
Describing UEFI, vid wrote:

It is bit more complicated. There are three types of UEFI executables: application, boot driver, and runtime driver.



implementations of EFI typically support FAT32 as their file system.....
EFI has been criticized for bringing more complexity to the system, without bringing significant advantages and disabling fully open-source BIOS replacements like OpenBIOS and coreboot

Question: will UEFI permit a user to modify pre-OS options using a USB keyboard/mouse, instead of PS/2?
Confused
Post 30 Jul 2008, 19:33
View user's profile Send private message Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
My implementation of UEFI supports USB keyboard.
Post 30 Jul 2008, 20:13
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
Madis731



Joined: 25 Sep 2003
Posts: 2140
Location: Estonia
Madis731
vid: but is it legacy-enabled, or a full-blown USB driver? I know Intel has USB2.0 speed in the boot-up time. For example booting from USB-stick.

I made a mistake there before - it goes like this: PE GUI 4.0 Smile not just 4.0
anyway I liked the verbose "UEFIAPP", "UEFIBOOT", "UEFIRUNTIME" options better that f0dder posted, but I still like to see the 64-bit suffix moved after PE not the EFI new magic words we think of.
So criticism to f0dders first posts Smile (sorry) "format PE UEFI64" should be more like "format PE64 UEFI".

Btw, do we have democracy over here or will Tomasz eventually decide? Very Happy
Post 30 Jul 2008, 22:00
View user's profile Send private message Visit poster's website Yahoo Messenger MSN Messenger Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
Quote:
"format PE UEFI64" should be more like "format PE64 UEFI".
Yeah, agree on that, actually Smile
Post 30 Jul 2008, 22:04
View user's profile Send private message Visit poster's website Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
Madis: I think UEFI has pretty complete USB stack implementation. You know, BIOS vendors already have the code, why not port it to UEFI driver?

So I think we have agreed about names.
Post 30 Jul 2008, 22:53
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
Madis731



Joined: 25 Sep 2003
Posts: 2140
Location: Estonia
Madis731
We have agreed about the names Wink

USB is still bothering me. Can we make OS thinner as opposed to fat BIOS. Examine this thought with me, please Smile

When the handover is made between BIOS/OS then BIOS knows alot of stuff about the machine (and *should* know). So the RAM/VID/CPU configuration is already known and can be thrown into some structures and OSs that are built up on it will have less tedious work and more OS-specific work (i.e. making OS user-friendly etc.).

The first example is USB as we have learned - can the driver and functions be handed over to OS as interrupts or something? Maybe I'm rushing and we'll all learn about it in a while, but well...I'm curious Very Happy
Post 31 Jul 2008, 19:17
View user's profile Send private message Visit poster's website Yahoo Messenger MSN Messenger Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
Quote:
When the handover is made between BIOS/OS then BIOS knows alot of stuff about the machine (and *should* know). So the RAM/VID/CPU configuration is already known and can be thrown into some structures and OSs that are built up on it will have less tedious work and more OS-specific work (i.e. making OS user-friendly etc.).

Exactly what UEFI does. But UEFI isn't only about knowing, you need lot of code just to keep it working. This code isn't provided by UEFI anymore, since OS loader signals it is starting OS.

I think it would be possible to easily write hobby OS under UEFI, by simply not telling it to unload (Not calling ExitBootServices()). But I am not that much into hobby OSes :]
Post 31 Jul 2008, 20:50
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar. Also on GitHub, YouTube, Twitter.

Website powered by rwasa.