[ELF bootloader] VMA/LMA --- virtual/physical address

[Neroku]

Hello everybody,

I'm developing a bootloader that loads a (so far stub) kernel in 32-bit protected mode . In the wiki, on Beginner_Mistakes, specifically in the section Avoid Ignorance, it is suggested not to use flat binaries as kernel images, but ELF images instead, just like I am doing.
I want the kernel to reside at physical address 0x00100000 (1MiB) and it being mapped to virtual address 0xC0000000 (3GiB).

Niether the physical memory address the bootloader loads the (ELF program segments of the) kernel at, nor the virtual address this space of addresses will be mapped to, is statically fixed by the bootloader: it is actually determined at runtime and segment-by-segment according to the contents of corresponding p_paddr and p_vaddr that appear in the corresponding program segement header of the to-be-loaded ELF kernel.

I set these two fields in the process of linking (as well as the virtual addresses that the code must have). In terms of the LD linker these two fields, p_paddr and p_vaddr, are known as LMA and VMA, respectively.

I hope I made myself understood to this point...
In order to make it clearer, assume my kernel is named "kernel.elf". If I run the following command on the shell:

Code: Select all

readelf -l kernel.elf

I get the this output:

Code: Select all

Elf file type is EXEC (Executable file)
Entry point 0xc0000000
There are 2 program headers, starting at offset 52

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x001000 0xc0000000 0x00100000 0x03c3c 0x03c3c R E 0x1000
  LOAD           0x005000 0xc0004000 0x00104000 0x00004 0x01e58 RW  0x1000

 Section to Segment mapping:
  Segment Sections...
   00     .text.start .text .rodata .eh_frame 
   01     .data .bss

I would like to ask you whether I am doing the proper usage these two in-the-ELF-image-available fields are meant to.
Has anybody here ever had a similar experience? Please, let me know.

Thanks in Advance

[Rusky]

That looks great. I do the exact same thing here.

[Neroku]

That looks great. I do the exact same thing here.

Thanks a lot.

Did you follow any other approach to load your kernel before making use of this one that both of us are currently using? If so, could you please tell me which one?

[Rusky]

I've used GRUB before (which does the same thing), as well as a flat binary stored in the reserved sectors after the MBR.

[Neroku]

I've used GRUB before (which does the same thing), as well as a flat binary stored in the reserved sectors after the MBR.

Regarding the flat binary, I assume you let the bootloader load the kernel wherever it wants to, however, the entry point of the kernel consists of some kind of position independent code that performs the reallocation to the desired address.
Otherwise you may provide the bootloader with additional parameters or configuration files, so that it has a way to figure out how to properly load the kernel.

[Rusky]

Those are both options, but what I did was a lot simpler- I just linked the flat binary to run at a fixed location that the bootloader knew, loaded it directly there, and jumped to that address.

[Neroku]

Those are both options, but what I did was a lot simpler- I just linked the flat binary to run at a fixed location that the bootloader knew, loaded it directly there, and jumped to that address.

Yes, that's feasible if there is some kind of agreement between the bootloader and the kernel, just like you describe above. It's also faster to implement, more suitable when you are just playing around.

Thank you very much!