OSDev.org

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

No, because those are all you need in a boot loader. You want to read data from disk (obviously), set up screen and get user keystrokes. What else do you need?

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)

NASM is not easier and it doesn't have as sophisticated macros as FASM. The uefi_call_wrapper macro takes advantage of those macro functions to accumulate arguments etc. That's just not possible with NASM. You could however convert the source into NASM macros, by creating 11 ones depending on the number of arguments: uefi_call_wrapper0, uefi_call_wrapper1, uefi_call_wrapper2 etc.

PavelCheckov wrote:Im very new to OS development, and am just trying to figure how to output text to the screen and input text

Then are you sure you want to code Assembly for UEFI? That's a difficult task by all standards. UEFI was specifically designed with C/C++ in mind (and bloat may I add).

Here's what you'll need:
SystemTable->ConIn->ReadKeyStroke - to get a character from keyboard (INT 16h/AX=0)
SystemTable->ConOut->OutputString - to write string to the screen (no BIOS equivalent, maybe INT 10h/AH=0Eh in a loop)
SystemTable->BootServices->LocateProtocol - to find pointers to interfaces not listed in the SystemTable

One of those further interfaces is GOP, which provides similar functions like VESA (INT 10h/AX=4Fxx). Another one is SIMPLE_FILE_SYSTEM_PROTOCOL, to load files from the ESP. If you're new to OSDev, I would not recommend reading disks at sector level, but if you want, use BLOCK_IO_PROTOCOL (INT 13h). All of these have wiki pages.

PavelCheckov wrote:I more meant where should I put what

What do you mean? What what? The compiled kernel.efi? You should create a bootable disk image with an EFI System Partition and boot that image in qemu, or write it to an USB stick and boot it on real machine (you obviously won't need any OS on your test machine, just set it up to boot from USB sticks).

Cheers,
bzt

Can I skip UEFI, and create my own IO functions using the ports?

PavelCheckov wrote:Can I skip UEFI, and create my own IO functions using the ports?

No. The machine when turned on always executes the firmware first (UEFI in your case).

You might get a workaround if your firmware is old enough it might have a "legacy CSM" option. With that enabled you can write a boot sector and a loader that uses BIOS services (but again, Intel has officially obsoleted legacy CSM in 2020, don't rely on it on the long run).

An alternative (if your motherboard is supported) to flash the board and replace UEFI with coreboot. Then you won't have neither UEFI services nor BIOS interrupts, instead you'll have to statically link your code with libpayload and use its functions. My boot loader has implemented that, you can take a look at my source on how to use that library.

Cheers,
bzt

Let me rephrase my question: I am using BOOTBOOT to boot to my kernel in C, can I use inb() and outb() instead of UEFI interrupts/subroutines/whatcha-ma-call-its to communicate with the keyboard, mouse, hard disk, and screen?

PavelCheckov wrote:Let me rephrase my question: I am using BOOTBOOT to boot to my kernel in C, can I use inb() and outb() instead of UEFI interrupts/subroutines/whatcha-ma-call-its to communicate with the keyboard, mouse, hard disk, and screen?

Yeah, you can.