OSDev.org

Hi this is my first post here!

Right now i'm working on a bootloader in uefi and it's going quite fine. I'm able to draw a nice background gradient, load a logo and draw that as well. Right now i'm busy trying to load a kernel image (in ELF format) and handing control over to this kernel.

I have a few questions about this process:
- Paging is turned on in uefi, but do i need to alter the page tables before i load the kernel, or can the kernel take care of this?
- When loading the kernel, can i just load the full image or do i need to allocate diffrent areas for example for stack etc?
- When the kernel is loaded in memory and ExitBootServices() is called, how the heck do i jump to the kernel? Can this happen via an efi function (not likely), a pointer, inline assembly, or an assembly file linked to my EFI file?
- After i've succesfuly handed control to the kernel, just for confirmation, i need to setup the paging table again and call x64 functions via inline assembly?

Thanks in advance for your help!

joejoepie wrote: - Paging is turned on in uefi, but do i need to alter the page tables before i load the kernel, or can the kernel take care of this?
- When loading the kernel, can i just load the full image or do i need to allocate diffrent areas for example for stack etc?

It's up to you. It's your loader, your kernel, your image format.

- When the kernel is loaded in memory and ExitBootServices() is called, how the heck do i jump to the kernel? Can this happen via an efi function (not likely), a pointer, inline assembly, or an assembly file linked to my EFI file?

How a jump into the code could happen via some other function call? JumpIntoThereForMePlease()? There is no such a "useful" function. xD
You load your image, you find its entry point, you throw its arguments at it, accordingly to your calling convention, and you do jump into the entrypoint. You might do this in assembly, C or even XML, I heard there are even such approaches.
Read carefully UEFI spec on the ExitBootServices() and GetMemoryMap() services. That's the ultimate reference regarding the interaction between the FW and your loader at the control transfer phase between them.
Once ExitBootServices() completed, your code owns the memory map, you could do all you want and need.
First, it seems, you need to learn a lot.
Don't forget to not trash FW reserved memory.

- After i've succesfuly handed control to the kernel, just for confirmation, i need to setup the paging table again and call x64 functions via inline assembly?

Thanks in advance for your help!

Having your kernel being able at least print something about its existence, generally means you are already aware of what you need to do with the memory layout/translation setup.
Just learn and think about what your memory management should look like, then you will know whether you need to rebuild page tables after your own loader or not. nobody knows this in fact. except you. in future.

Thanks a lot for your info!

I'm indeed still learning a lot, luckily i have osdev wiki and the UEFI spec!
I've searched some stuff and apparently you can jump in C by using a function pointer,
but i'm not sure this will work for me since mu efi bootloader is in PE format, and the kernel
will be ELF... So an inline assembly jump will have to do i guess.

Os development certainly is an interesting topic!

joejoepie wrote:Thanks a lot for your info!

I'm indeed still learning a lot, luckily i have osdev wiki and the UEFI spec!
I've searched some stuff and apparently you can jump in C by using a function pointer,
but i'm not sure this will work for me since mu efi bootloader is in PE format, and the kernel
will be ELF... So an inline assembly jump will have to do i guess.

Os development certainly is an interesting topic!

why shouldn't it work? it doesn't depend on the loader executable format, your loader just needs to be an elf loader, or whatever image format you choose for its payload. the loader and the callee should just follow the same calling convention, basically the loader should place arguments the way, the kernel entry expects them, it has nothing to do with what format your loader is, nor the kernel image format.