How to access files when booting from UEFI?

[chocabloc]

Hello everyone,
I am trying to write a simple UEFI bootloader which loads the kernel from the same directory as the loader. However, I cannot figure out how to load the kernel from the disk. I am using gnu-efi, if that matters.

[kzinti]

This is rather more complex than I think it should be, but here is an example:

https://github.com/kiznit/rainbow-os/bl ... fifile.cpp

I use this code to load my kernel from an EFI bootloader.

Calling code looks like this:

Code: Select all

    void* kernelData;
    size_t kernelSize;

    status = LoadFile(L"\\EFI\\rainbow\\kernel", kernelData, kernelSize);
    if (EFI_ERROR(status))
    {
        Fatal("Failed to load kernel: %p\n", status);
    }

    Log("Kernel loaded at: %p, size: %x\n", kernelData, kernelSize);

[chocabloc]

Thanks, but it still does not work. I don't know what I am doing wrong here...

Code: Select all

#include <efi/efi.h>
#include <efi/efilib.h>
#include <efi/x86_64/efibind.h>
EFI_STATUS
EFIAPI
efi_main (EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable) {

	InitializeLib(ImageHandle, SystemTable);

    EFI_LOADED_IMAGE_PROTOCOL* lip=NULL;
    EFI_GUID lipguid=EFI_LOADED_IMAGE_PROTOCOL_GUID;

    EFI_STATUS status=BS->HandleProtocol(ImageHandle,&lipguid,(void**)&lip);

    if(EFI_ERROR(status) || !lip)
        Print(L"An error occured");

	while(1){
	}

	return EFI_SUCCESS;
}

It always shows an error.

[kzinti]

This code looks fine to me. Any chance you can print out what that error is so that it points us in the right direction?

[chocabloc]

It is error code 2: EFI_INVALID_PARAMETER

[kzinti]

Are you not supposed to use uefi_call_wrapper() when using gnu-efi? (I am not using that library by the way.)

See example here: https://sourceforge.net/p/gnu-efi/code/ ... /apps/t6.c

In your case, this would mean something like:

Code: Select all

EFI_STATUS status = uefi_call_wrapper(BS->HandleProtocol, 3, ImageHandle, &lipguid, (void**)&lip);

See if you can get that "t6.c" example to work, it's part of the gnu-efi source distribution.

If this doesn't work, then something is probably wrong with the way you build the code.

1) Build t6.c with the gnu-efi makefile and verify that it works correctly.
2) Copy the t6.c code into your own project, build it, verify if it still works.

[bzt]

Are you not supposed to use uefi_call_wrapper() when using gnu-efi?

Depends on which ABI you have configured your toolchain to compile for. The big advantage of gnu-efi is that it allows you to use EFI ABI (in which case you don't need uefi_call_wrapper) but also to simply use your host environment's native ABI (in which case you should use uefi_call_wrapper). It's up to you. Other SDK's only allow EFI ABI, and demand specific cross-platform toolchain. With gnu-efi, you have an option.

Cheers,
bzt

[kzinti]

I actually use the EFI ABI with my Linux host compiler that wasn't configured to build for EFI ABI. So I don't need to rely on uefi_call_wrapper() or anything like it.

I am just trying to help the OP. His code looks ok, yet it doesn't work. So I suspect it indeed has something to do with the default ABI of his toolchain, hence my question about using uefi_call_wrapper().

[bzt]

I actually use the EFI ABI with my Linux host compiler that wasn't configured to build for EFI ABI. So I don't need to rely on uefi_call_wrapper() or anything like it.

Uhm, if your compiler is not configured for EFI ABI, that's when you have to use uefi_call_wrapper. I'm pretty sure your cross-toolchain is configured properly.

I am just trying to help the OP. His code looks ok, yet it doesn't work.

And you are doing a great job. I agree this is strange, the code looks just fine indeed, it should work.

So I suspect it indeed has something to do with the default ABI of his toolchain, hence my question about using uefi_call_wrapper().

You are right. Although it's not a must, but better to use uefi_call_wrapper with gnu-efi. Wouldn't hurt, and it makes the source less compiler config dependent. I did not wanted to suggest that your advice is incorrect, I just wanted to say uefi_call_wrapper is not a must, rather compiler config dependent.

Cheers,
bzt

[chocabloc]

YES!! It works now. But why do we need to use uefi_call_wrapper?

[kzinti]

Uhm, if your compiler is not configured for EFI ABI, that's when you have to use uefi_call_wrapper. I'm pretty sure your cross-toolchain is configured properly.

And you are wrong. I am not even using a cross-toolchain. I am using my host Linux compiler.

How can that be? Well turns out GCC allows you to specify the ABI per function using a function attribute. So what I do is simply mark the UEFI protocol methods to use the EFI ABI even though the rest of my code is not using it.

I did end up having to use some trickery inspired from gnu-efi to generate a PE file and do relocations... But the end result is that I don't need a cross-compiler and I am not using gnu-efi.

[kzinti]

YES!! It works now. But why do we need to use uefi_call_wrapper?

If it works, then you don't need to use uefi_call_wrapper() and can ignore it.

I'm curious, how did you solve the problem? What was the issue?

[bzt]

Uhm, if your compiler is not configured for EFI ABI, that's when you have to use uefi_call_wrapper. I'm pretty sure your cross-toolchain is configured properly.

And you are wrong.

Nope, I'm not. You're not using the native ABI, which means you had to tell that to the compiler somehow Either it's through command line options, function attributes, linker script options, or spelling out uefi_call_wrapper each time, doesn't matter.

I am not even using a cross-toolchain. I am using my host Linux compiler.

How can that be? Well turns out GCC allows you to specify the ABI per function using a function attribute.

Which means you have configured your cross-toolchain properly. And since your code won't run on the host system, you're surely cross-compiling. The uefi_call_wrapper is needed, you just told to the compiler to inline it for you on every call automatically. It's a nicer solution than writing out uefi_call_wrapper each time imho, but less portable I think. Is it a gcc-only solution? (There's nothing wrong with saying you have to compile this code with gcc, that's perfectly fine, and the code is more readable.)

Cheers,
bzt

[kzinti]

Hey bzt,

Can you stop derailing threads with your need to have the final word in every side discussion? It's not remotely relevant, interesting or useful. I am pretty sure the OP doesn't care whether you or me is right.

If you feel the need to have endless argumentative debates with people, maybe an os dev forum is not the best place for this. It can be very off-putting to people asking for help and to people trying to help them.

[bzt]

Dear kzinti,

I have no need to have the final word, I have a need to be technically correct. As long as you are spreading misinformation (like one can compile EFI apps without compiling for a special ABI) I'll keep correcting you, because I believe having technically correct information is essential for this community. There are way too many misleading information on the net and way too many incorrect tutorials already. Designing and implementing an operating system is a notoriously hard task enough, there's no need to mislead people.

Best regards,
bzt