[Prev][Next][Index][Thread]

Re: Loading the kernel.


----- Original Message -----
From: Imobac Exposito (alu1360)-Vicente Cruz (alu1345) - Fresnadillo Perez
(alu1364) <mkernel@csi.ull.es>
To: <oskit-users@cs.utah.edu>
Sent: mercoledì 12 aprile 2000 21.59
Subject: Loading the kernel.


> Hi,
> we are trying to load our kernel at a certain virtual address(3GB). In
> order to do it we have made a loader, which, basically, makes the next:
> . Enables the virtual memory (svm_init),
> . Reads the kernel from disk,
> . With svm allocates virtual memory for it and,
> . Jumps to the entry point of the kernel, with a lcall.
> Everything  seems to work fine, we have tried to load very
> simple kernels, for example an infinite loop, and it works.
> After that we wanted to make kernels a bit more complicated. For example,
> one with only a call to oskit_clientos_init() but we got the following
> error:
>
> oskit_clientos_init: Problem creating global registry.
>
> We suppose the problem is due to a call to oskit_mem_alloc in the
> function oskit_services_create in com/services.c (we have oskit-0.97 with
> snapshot 19991124).
>
> How can we fix it?
> Is anything wrong in the steps we have followed to load the kernel?
>

We have had almost the same problem with our kernel. I say *almost* as we do
not use svm, but rather enable paging by ourselves. Anyway, here are the
steps we perform to load our kernel. Hope it helps!

1) we have a "loader" and a "kernel" that are loaded together at boot time
(the kernel is loaded as a module). The loader is linked against the default
OSKit libraries (it is a normal OSKit "kernel"), while the kernel uses a
slightly modified version of multiboot_init_mem.c
2) the loader prepares the page tables and then performs the same steps
performed by the multiboot->FreeBSD boot loader adaptor (provided by the
OSKit) to interpret the module and put it in a temporary memory zone
3) the assembler stub, that copies the module to its final physical position
in memory, enables paging and then jumps to the module entry point
4) the module now runs with paging enabled and at a virtual address that
differs from the physical address. It performs all the the normal stuff done
by base_multiboot_main, but the modified base_multiboot_init_mem function
also skips the page tables allocated by the loader in step 2.

Another problem is caused by some device drivers making the assumption
"virtual = physical". However, it *looks* like they assume these equality at
initialisation and probe time only. The solution is to prepare an additional
1:1 mapping for the first 1Mbyte of memory (we'll never get rid of 8086
limits!) in step 2. This mapping will be eliminated in step 4, after all
device initialisation stuff is done. Linux does exactly the same.

Giuseppe Lettieri
References: