[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: loading kernels with different LMA and VMA (fwd)
From: |
Rogelio M. Serrano Jr. |
Subject: |
Re: loading kernels with different LMA and VMA (fwd) |
Date: |
Thu, 29 Mar 2001 01:01:01 +0800 (PHT) |
---------- Forwarded message ----------
Date: Thu, 29 Mar 2001 00:54:41 +0800 (PHT)
From: Rogelio M. Serrano Jr. <address@hidden>
To: Michael Hohmuth <address@hidden>
Subject: Re: loading kernels with different LMA and VMA
On 28 Mar 2001, Michael Hohmuth wrote:
> Perhaps an incorrect error message. Even if GRUB could load it, it
> could not run your kernel because the Multiboot standard mandates
> one-to-one virtual-to-physical mappings -- that is, there is no
What i was planning to do was load a kernel linked at a high virtual
adress but with a self relocating stub in front that sets up paging then
relocates the kernel with VM properly initialized.
something like:
#define KVABASE 0xf0000000
#define VATOPHYS(x) ((x)-KVABASE)
_start:
movl VATOPHYS(stack_top),%esp
.
.
.set up page tables here
.enable paging
.
pushl $K_CS
pushl $pushl virtual_entry
lret
virtual_entry:
// we are relocated virtual at this point.
> mapping for virtual addresses larger than the largest physical-memory
> address. In fact, paging is not even enabled when GRUB starts the
> kernel.
>
> > It looks like the only way i can remap a kernel to a higher virtual
> > memory is to use the gdt otherwise i have to relocate all symbols in
> > my kernel (argh).
>
> My solution was to boot a small wrapper program that sets up a simple
> page table, enables paging, copies the kernel (linked as an opaque
> binary-data block into the wrapper) to its target destination, and
> finally jumps to the kernel's startup code.
>
I wanted to avoid creating a binary absolute image. I was already thinking
of doing something similar. I was planning to either load the kernel as
a module or appended to a wrapper similar to yours. Then the wrapper would
read the ELF headers from the kernel image and load it just like it was an
ordinary executable. That way i dont have to do something special besides
a link using a simple ld script.
But i found out from reading the grub sources that it might be much less
work to actually modify grub to load at the specified physical
address. Paging does not even need to be enabled. Just look up the p_paddr
and load everything there and let kernel do its own relocation. My main
problem is how to specify the proper e_entry in the elf header to point to
the LMA. In fact grub looks like it should load my kernel properly.
im looking at boot.c: function: load_image
line
104 {
105 if (type == KERNEL_TYPE_MULTIBOOT)
106 entry_addr = (entry_func) pu.elf->e_entry;
107 else
108 entry_addr = (entry_func) (pu.elf->e_entry & 0xFFFFFF);
109
110 if (((int) entry_addr) < 0x100000)
111 errnum = ERR_BELOW_1MB;
112
113 /* don't want to deal with ELF program header at some random
114 place in the file -- this generally won't happen */
115 if (pu.elf->e_phoff == 0 || pu.elf->e_phnum == 0
116 || ((pu.elf->e_phoff + (pu.elf->e_phentsize *
in line 110 if my e_entry is 0xf0100000 we should not get an error right?
same with line 520: my p_addr this time is 0x100000
511 grub_seek (phdr->p_offset);
512 filesiz = phdr->p_filesz;
513
514 if (type == KERNEL_TYPE_FREEBSD || type ==
KERNEL_TYPE_NETBSD)
515 memaddr = RAW_ADDR (phdr->p_paddr & 0xFFFFFF);
516 else
517 memaddr = RAW_ADDR (phdr->p_paddr);
518
519 memsiz = phdr->p_memsz;
520 if (memaddr < RAW_ADDR (0x100000))
521 errnum = ERR_BELOW_1MB;
522 /* make sure we only load what we're supposed to! */
523 if (filesiz > memsiz)
524 filesiz = memsiz;
525 /* mark memory as used */
am i getting the error at 111?
> Michael
> --
> address@hidden, address@hidden
> http://home.pages.de/~hohmuth/
>
- Re: loading kernels with different LMA and VMA (fwd),
Rogelio M. Serrano Jr. <=