[SOLVED] passing UEFI runtime services to kernel?

[austanss]

I've been attempting to add reboot functionality to my OS, which at first I thought shouldn't be trivial. I read somewhere that if you pass the Runtime Services to the kernel, you can use the ResetSystem function to reboot the system.

So, I set off to create the necessary structs, enums, declarations, and such to pass the RuntimeServices structure to the kernel. I've been translating types and creating types, however I've had one issue. Namely, the EFIAPI attribute.

I originally thought it was a defined type, but upon closer research it turns out to be EFI compiler magic. I don't know what to replace this keyword with, if anything at all.

Here is an example

UEFI header:

Code: Select all

typedef 
EFI_STATUS
(EFIAPI *EFI_SET_VIRTUAL_ADDRESS_MAP) (
    IN UINTN                        MemoryMapSize,
    IN UINTN                        DescriptorSize,
    IN UINT32                       DescriptorVersion,
    IN EFI_MEMORY_DESCRIPTOR        *VirtualMap
    );

Kernel header:

Code: Select all

typedef
uint64_t
(EfiApi *Efi_Set_Virtual_Address_Map) (
uint64_t         				MemoryMapSize,
uint64_t 						DescriptorSize,
uint64_t 						DescriptorVersion,
Memory_Map_Descriptor	       *VirtualMap
);

Source code: https://github.com/microNET-OS/microCOR ... ext-output

I have EfiApi defined as nothing, just a valueless macro. It compiles, though when calling UEFI functions it triple faults, I assume due to the lack of EFI calling convention. Anyone know how I could fix this?

[Octocontrabass]

It's architecture-specific, but this should work for x86:

Code: Select all

#define EFIAPI __attribute__((ms_abi))

Why is your kernel trying to enable long mode when it's already in long mode?

[austanss]

It's architecture-specific, but this should work for x86:

Code: Select all

#define EFIAPI __attribute__((ms_abi))

Why is your kernel trying to enable long mode when it's already in long mode?

I figured it couldn't hurt to try to enable long mode when already in long mode. I do that for redundancy.

[Octocontrabass]

But it's 64-bit code, it won't execute correctly unless you're already in long mode.

[austanss]

But it's 64-bit code, it won't execute correctly unless you're already in long mode.

I think I was high when I wrote that code...

anyway, the attribute thing didn't work. Is it just for x86, or does it also work for x86_64?

behavior: same as before.

[Octocontrabass]

It should work for both.

I see you declare the "UEFI" variable, but where do you define it? If it's not defined, your linker should complain.

Your "pusha" and "popa" functions are fundamentally broken.

[austanss]

I see you declare the "UEFI" variable, but where do you define it? If it's not defined, your linker should complain.

bootinfo.cxx

Your "pusha" and "popa" functions are fundamentally broken.

I figured.

[Octocontrabass]

Nothing jumps out at me as obviously wrong in how you're calling UEFI functions, unless you have a typo somewhere in your UEFI definitions.

Which exception is causing the triple fault, and what state is the CPU in when it occurs?

[austanss]

Nothing jumps out at me as obviously wrong in how you're calling UEFI functions, unless you have a typo somewhere in your UEFI definitions.

Which exception is causing the triple fault, and what state is the CPU in when it occurs?

Good question.

There is no exception printed to serial...

I made the assumption that it was a triple fault, although it isn't. Could it be possible it's calling to nullptr, which in turn jumps to the reset vector, which in resets the computer?

[austanss]

BLAST! My THC-trained mind looked for any possible ways that the function pointers might be null pointers.

And I figured it out.

You know, sometimes the most trivial things can cause the downfall of a project.

In this case, it didn't cause the downfall.

Just a minor hiccup.

Code: Select all

I forgot to set the RuntimeServices pointer in the Boot_Info struct.