uefi error unsupported when opening graphics output protocol

[zaval]

@zaval: How would UEFI prevent you from drawing to the framebuffer before ExitBootServices? It has no way of doing so! The OSL is running in kernel mode. It can draw to the framebuffer.

obviously it wouldn't prevent. why you think I said that?

[nexos]

I'm confused

for the early stages of the OS initialization, there is video framebuffer, about which you get to know from GOP functions/fields. after your OSL owns the system, you can draw in that framebuffer by yourself.

It appears here that you said that you can only use the framebuffer after calling ExitBootServices. Please correct me if I misunderstood .

[zaval]

I should have written "after your OSL owns the system, you have to draw in that framebuffer by yourself." (as opposed to using GOP during Boot Services).

[nexos]

Ok, that makes more sense. I guess I misunderstood .

[austanss]

zaval, I apologize for my statements. I misread your post. I still haven't fixed this problem. Originally I thought I was forcing an incompatible video mode upon my computer, and that's why it wasn't working. However, I quickly realized that the error lies in the function call to open the protocol, which leaves me stumped.

The UEFI spec reports only one cause for an EFI_UNSUPPORTED error that arises from an OpenProtocol function call.

If Handle does not support Protocol, then EFI_UNSUPPORTED is returned.

Does the handle relate to the specific UEFI implementation of the computer?

[austanss]

After finding this amazing Stack Overflow answer, I am on a lead that I will get back to you on:

https://stackoverflow.com/a/49814997

[austanss]

Blasted, it didn't work. I'm going to attempt to use alternative functions in a last-ditch attempt to make this work on my computer.

[austanss]

I fixed the issue!

Instead of using just OpenProtocol, or using LocateProtocol + (OpenProtocol/HandleProtocol), I just used LocateProtocol and it worked! Magical!

My kernel isn't loading, I'm hanging at getting memory map. However, I don't know for sure that's where it's hanging at, I only know that was the last message being sent.

IN the bootloader/kernel transition, there is a graphical silence period. After getting the memory map, I can't use any more UEFI boot functions. I then have to immediately leave boot services. Then, the bootloader calls the kernel, and after loading a new GDT, new IDT, and calling global constructors, then my kernel main function is called and THEN, after doing a few tasks it configures the terminal. So there is a lot going on and I can't tell where the issue lies. Being that the issue only arises on my real computer, doing the traditional breakpoint isn't going to work efficiently.

I know that a lot of information does come through the serial port.

In fact, my computer even has a serial port. But I don't have a device connected to receive the data. Anyone have any ideas?

[Octocontrabass]

You can access the framebuffer at any time to put pixels on it. Filling the screen with different colors should be good enough for some simple debugging.

[austanss]

You can access the framebuffer at any time to put pixels on it. Filling the screen with different colors should be good enough for some simple debugging.

you're a genius

[austanss]

Right, now I'm kinda pissed.

Code: Select all

kernel_entry:

	mov r15, rdi					;	preserve parameters]

	mov rdi, kernel_taken_over
	call serial_msg

	mov qword [asm_framebuffer_ptr], 0x80000000

	mov edx, 0xFFFFFF
	call set_status_color

. . .

set_status_color:
	push rcx
	mov rcx, [asm_framebuffer_ptr]
%rep 50
	mov dword [rcx], edx // Page fault here
	inc rcx
%endrep
	pop rcx
	ret

section .data

asm_framebuffer_ptr:
	resb 8

[Octocontrabass]

Code: Select all

	mov qword [asm_framebuffer_ptr], 0x80000000

How did you get this number?

[austanss]

Code: Select all

	mov qword [asm_framebuffer_ptr], 0x80000000

How did you get this number?

Thanks for pointing that out, that is a problem.

Given a struct like this:

Code: Select all

typedef struct s_boot_info {
	uint64_t verification;
	Framebuffer *vbe_framebuffer;
	Memory_Map_Descriptor *memory_map;
	uint64_t mmap_size;
	uint64_t mmap_descriptor_size;
	Efi_Runtime_Services *runtime_services;
} Boot_Info;

Where a pointer to said struct is stored in the rdi register...

In assembly, how do I access the Framebuffer pointer, vbe_framebuffer?

[Octocontrabass]

Read it from memory at [rdi+8].

[austanss]

After using the magical color method, and diagnosing a few issues, and removing lines of code, I finally got my OS booting on real hardware! Currently, the sample size is 1 (my computer), but I will test it on multiple other computers when I get the chance.

I've been working on this for a month and a half and I'm so glad I finished it!

I can't believe I've taken a project this far.

I don't know if you can tell how ecstatic I am...

Problems I need to address: interrupts

Once I fix my interrupts, and fix the keyboard, I think I can keep moving forward with this OS, of course, until UEFI 3.0 comes out and obsoletes every operating system except Windows...