Index
> Compiler Internals > FASM support for UEFI |
| Author |
|
|
vid 30 Jul 2008, 05:07
I am starting this thread to make some "public push" on Tomasz
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. |
|||
30 Jul 2008, 05:07 |
|
|
Tomasz Grysztar 30 Jul 2008, 06:38
Just let me know what identifiers you need and propose the names for them.
|
|||
|
30 Jul 2008, 06:38 |
|
|
Madis731 30 Jul 2008, 13:56
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.
|
|||
|
30 Jul 2008, 13:56 |
|
|
Tomasz Grysztar 30 Jul 2008, 14:05
No, f0dder is right, UEFI should be a subsystem keyword, like GUI/console/native.
|
|||
|
30 Jul 2008, 14:05 |
|
|
vid 30 Jul 2008, 16:27
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. 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:
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
|
|||
|
30 Jul 2008, 16:27 |
|
|
vid 30 Jul 2008, 16:48
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. |
|||
|
30 Jul 2008, 16:48 |
|
|
Tomasz Grysztar 30 Jul 2008, 17:26
vid wrote: Another thing that (I believe) needs to be changed in header is CPU architecture: These are exactly the same as standard PE machine types, no need to worry about this field. |
|||
|
30 Jul 2008, 17:26 |
|
|
f0dder 30 Jul 2008, 17:46
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
 |
|||
|
30 Jul 2008, 17:46 |
|
|
vid 30 Jul 2008, 18:08
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? |
|||
|
30 Jul 2008, 18:08 |
|
|
Tomasz Grysztar 30 Jul 2008, 18:30
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. |
|||
|
30 Jul 2008, 18:30 |
|
|
tom tobias 30 Jul 2008, 19:33
Describing UEFI, vid wrote:
vid's link, above wrote:
Question: will UEFI permit a user to modify pre-OS options using a USB keyboard/mouse, instead of PS/2?  |
|||
|
30 Jul 2008, 19:33 |
|
|
vid 30 Jul 2008, 20:13
My implementation of UEFI supports USB keyboard.
|
|||
|
30 Jul 2008, 20:13 |
|
|
Madis731 30 Jul 2008, 22:00
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 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 (sorry) "format PE UEFI64" should be more like "format PE64 UEFI".
Btw, do we have democracy over here or will Tomasz eventually decide?  |
|||
|
30 Jul 2008, 22:00 |
|
|
f0dder 30 Jul 2008, 22:04
Quote: "format PE UEFI64" should be more like "format PE64 UEFI". |
|||
|
30 Jul 2008, 22:04 |
|
|
vid 30 Jul 2008, 22:53
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. |
|||
|
30 Jul 2008, 22:53 |
|
|
Madis731 31 Jul 2008, 19:17
We have agreed about the names
USB is still bothering me. Can we make OS thinner as opposed to fat BIOS. Examine this thought with me, please
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 |
|||
|
31 Jul 2008, 19:17 |
|
|
vid 31 Jul 2008, 20:50
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 :] |
|||
|
31 Jul 2008, 20:50 |
|
< Last Thread | Next Thread > |
Forum Rules:
|