OSDev.org

Where can I find documentation on programming for the Intel 64 architecture (x86_64)?

PavelCheckov wrote:Where can I find documentation on programming for the Intel 64 architecture (x86_64)?

https://software.intel.com/content/www/ ... l-sdm.html

How do I get keyboard input, screen output, and printer output on a computer with UEFI? In BIOS it is easy, but that si no longer supported, is there some sort of assembly UEFI call?

PavelCheckov wrote:How do I get keyboard input, screen output, and printer output on a computer with UEFI? In BIOS it is easy, but that si no longer supported, is there some sort of assembly UEFI call?

The UEFI specs are here:
https://uefi.org/specifications

More focussed on kernel development:
https://wiki.osdev.org/UEFI
https://wiki.osdev.org/UEFI_App_Bare_Bones

You can use the same functions from C and from Assembler. So it probably it is easier for you to call them from C! But you are free to use Assembler if you prefer.

EDIT: It is worth mentioning that you will write your own keyboard and screen functions yourself for your OS on UEFI. There are primitive keyboard and text-output drivers available, but they are only used during boot-time.

Greetings
Peter

PavelCheckov wrote:Where can I find documentation on programming for the Intel 64 architecture (x86_64)?

The OSDev.org Wiki - Got a question? Search this first!

PavelCheckov wrote:How do I get keyboard input, screen output, and printer output on a computer with UEFI?

What PeterX said, plus
https://wiki.osdev.org/GNU-EFI an easy way out to avoid using the bloated EDK II
https://wiki.osdev.org/GOP screen output (besides of ConOut->OutputString)
https://wiki.osdev.org/Loading_files_under_UEFI for high-level disk interface (open/read/close)
https://wiki.osdev.org/Reading_sectors_under_UEFI for low-level read/write sector interface

PavelCheckov wrote: In BIOS it is easy, but that si no longer supported, is there some sort of assembly UEFI call?

Sort of. No assembly needed. When your app is executed, it receives a pointer as an argument (see efiapi.h line 346). That pointer points to a struct called System Table, with further pointers to OOP-like objects (structs with properties and method references, see efiapi.h line 943). Those include Console Input and Output, the first for reading input from keyboard, the latter for printing strings. You can access the properties just like any other variables, but for calling the method you need a special EFI ABI. If you have a properly configured cross-compiler and the EDK II, then you can do Advantage: seemingly simpler code. Disadvantage: special C compiler needed, all your function calls will use the EFI ABI, even the internal ones. On the other hand, with GNU-EFI you can use your host compiler and here the uefi_call_wrapper() takes care of converting between your host compiler's ABI and EFI ABI. Disadvantage: you have to write uefi_call_wrapper() in your code and count the arguments yourself, advantage: fully portable source, it works with all C compilers on all operating systems.

This uefi_call_wrapper() is the closest thing to BIOS interrupt services. In BIOS you have used an interrupt number and registers to choose a function, in EFI you pick different structs and methods from the System Table then call it using the EFI ABI.

And just for completeness, if you want to use Assembly, uefi.inc include file provides the same uefi_call_wrapper as a fasm macro, as well as the struct definitions for the most important structs (system table, simple input, console out, etc.).

Cheers,
bzt

I know the article says that it is meant for FASM, but will uefi.inc work with NASM as well? (I only have NASM, and personally consider it easier to use)

PavelCheckov wrote:I know the article says that it is meant for FASM, but will uefi.inc work with NASM as well? (I only have NASM, and personally consider it easier to use)

No. I won't work with Nasm. EDIT: I meant IT won't, not I won't.

Greetings
Peter

Is there a more advanced version for assembly, because the article says that it gives limited access, and only three things to do?

You won't get far with uefi.inc. You wouldn't even if there existed a more advanced version of it (which doesnt afaik.)

UEFI works different than old Legacy BIOS. With Legacy BIOS and a real mode kernel you can call the disk and text etc. functions from the kernel. With UEFI you write these functions from scratch. You can use the functions used in uefi.inc during boot-time. But when you reach kernel main code you won'*t use them anymore, because they are only of limited use. For example text-output to screen: In the kernel you will have a graphics screen driver and text output will be ontop of that (you know, with a font etc.) You will have your own full-fletched disc sector I/O driver(s), too and file system code ontop of that.

You can somehow compare that with a protected mode kernel on old BIOS where you can't use BIOS interrupts.

Greetings
Peter

Im very new to OS development, and am just trying to figure how to output text to the screen and input text in a sort of command line setup, and also be able to write and read files from the hard drive.

PavelCheckov wrote:Im very new to OS development, and am just trying to figure how to output text to the screen and input text in a sort of command line setup, and also be able to write and read files from the hard drive.

Yeah, ok! Then I suggest you will either learn Fasm or use C. And don't get frustrated/discouraged that there is so much to read about UEFI.

EDIT: Sorry I came up with this so late:
On what OS do you want to develop your own OS? Windows? Linux? DOS??

Greetings
Peter

I am using Windows 10, Red Hat and Scientific Linux for programming and a old Inspiron 9300 running Windows XP for testing.

EDIT: If I have kernel.o and liner.ld, how would I modify:

PavelCheckov wrote:I am using Windows 10, Red Hat and Scientific Linux for programming and a old Inspiron 9300 running Windows XP for testing.

EDIT: If I have kernel.o and liner.ld, how would I modify:

Code: Select all

x86_64-elf-gcc -ffreestanding <other options> -T <linker script> <all object files> -o <kernel executable> -nostdlib -lgcc

You should use a cross compiler that produces PE32+ (=64bit PE) instead of x86_64-elf-gcc.

I more meant where should I put what

That should work. (Normally no linker script needed.) Actually I have more options: