How to relocate test kernel's text data and bss in ram??

[tushs]

Hi I have small test kernel (grub as boot loader) installed gdt idt, console and serial logger. Before going to paging I want to understand how to relocated (copy all my kernel to known pages) text data and bss in ram. since after some calculation I know what is highest usable memory page bellow 4 GB space and I want my kernel data bss stack to those higher address (at the end of ram). One more thing what is the exact size of ram that DMA processor can address?

[egos]

alloc and memcopy or remap?

One more thing what is the exact size of ram that DMA processor can address?

DMA8 - 1 mb
DMA16 - 16 mb
DMA32 - 4 gb or even more

[tushs]

Sorry I did not got your ans

alloc and memcopy or remap?

Suppose I have kernel starting and running @ 0x100000 and now I want to move it to 0x80000000 (say 2GB). I need to copy all text data and bss from old location to new. and I need to jump to new location code. set up new stack etc. But what about addresses of variable and functions in code segment which are hard coded in text section. new code will not find valid new address.
Point is how can I compile relocatable kernel, how to copy segments and make jump to new kernel address?

[egos]

There're only two ways.

1) Put init code into section(s) with 1 mb precompiled starting address and put relocatable code into section(s) with 2 gb precompiled starting address.

2) On the same principles relocate relocatable code dinamically using fixup info.

Edited. There's one hard way.

3) Use position independent relocatable code.

Point is how can I compile relocatable kernel, how to copy segments and make jump to new kernel address?

It is compiler specific. You can put two binaries into one kernel binary by some tools too. In fasm I just use org directive.

Code: Select all

  org 8000h
  put startupcode16,initcode16,startupdata16,initdata16
  virtual
  rb 10000h-$
  end virtual
  use32
  put startupcode32,initcode32,startupdata32,initdata32
  align 4
  getsum32 STARTUP_SUM32
  label PACKAGE_BASE
  org SYMBOLS_BASE <<<--- LOOK HERE
  put code,data
  getsum32 SYMBOLS_SUM32
  virtual
  put bss
  set KERNEL_PCOUNT,($+0FFFh)/1000h-KERNEL_PINDEX
  put rma
  set KERNEL_TCOUNT,($+3FFFFFh)/400000h-KERNEL_TINDEX
  end virtual
  set SYMBOLS_SIZE,$-SYMBOLS_BASE
  org PACKAGE_BASE+SYMBOLS_SIZE
  rb 3FFh - ($+7) mod 400h
  dd (-STARTUP_SUM32-SYMBOLS_SUM32) and 0FFFFFFFFh,0AA554745h

I use memcopy method.

Code: Select all

  mov esi,PACKAGE_BASE
  mov edi,SYMBOLS_BASE
  mov ecx,(SYMBOLS_SIZE+3)/4
  rep movsd
  jmp KCODE:@f
@@:
  ...
  jmp start ; start is label within relocated code

[tushs]

Can u point out some example, link of 2nd option, how to build relocatable code with gcc and what fixup info is required.
I want to decide relocation address after loading be'cos then I will have all physical memory info and depending on size of RAM I will load kernel to upper address. I am using c , gcc, gas assembler.

[Combuster]

Before going to paging I want to understand how to relocate

Building a relocating linker is not the biggest deal, the bigger problem is that you need the relocation data for that (which means module/ramdisk support very early in the kernel, or some other complex magic to copy raw ELF data into the binary), and that you can't sanely transfer anything that's live. Worst of it all, it is in almost all cases completely unnecessary, and I get the idea that you want to do something more complex than the final result as an intermediate step.

If you want a kernel at 2G, link it there and load it there. If you want a kernel at 2G even if there's no memory there which is likely for an emulator, link it at 2G, load it somewhere else, and then use paging. Only if your kernel should be at a non-fixed address, does relocating or PIC make sense, but it also implies that everything else in your system should later be relocatable.

[egos]

I want to decide relocation address after loading be'cos then I will have all physical memory info and depending on size of RAM I will load kernel to upper address.

What is reason to do that? If you use paging your kernel can be placed/mapped at any fixed precompiled virtual address. As Combuster said you should make relocation using programming way only if your kernel will be able to be placed/mapped at different virtual addresses.

[tushs]

why I got into relocation is I want set lower memory free for DMA use. I wanted to avoid kernel in that address space.

[LegendDairy]

You could also use an intrd to load a binairy, then you relocated that binairy, then jump to that binairy and that one erases the orignal kernel, but this will take some precious start up time...

[egos]

why I got into relocation is I want set lower memory free for DMA use. I wanted to avoid kernel in that address space.

I use memcopy for that reason to make available base memory for legacy hardware. You must understand that only virtual addresses are important. It's easy to write init code in asm (position independent or not) that will copy your kernel at any physical address and then will map it at fixed precompiled virtual address or firstly will map free memory at this virtual address and then will copy your kernel. There's small problem when your kernel is loaded by GRUB because it can try to load the kernel at high virtual address (not at low physical address) but ELF stores both virtual and physical addresses and I think that will be alright.

[Combuster]

why I got into relocation is I want set lower memory free for DMA use. I wanted to avoid kernel in that address space.

Then why not do the most straightforward thing and just tell grub to load your kernel at 16M? Unless you plan on running on an underpowered 586 or worse, that pretty much solves your problem instantly.