1995-09-25 04:53:33 +00:00
|
|
|
<!-- $Id: memoryuse.sgml,v 1.2 1995/06/30 17:37:42 jfieber Exp $ -->
|
1995-05-18 03:05:22 +00:00
|
|
|
<!-- The FreeBSD Documentation Project -->
|
|
|
|
|
|
1995-09-25 04:53:33 +00:00
|
|
|
<sect><heading>PC memory utilization<label id="memoryuse"></heading>
|
1995-05-18 03:05:22 +00:00
|
|
|
|
|
|
|
|
<p><em>Contributed by &a.joerg;.<newline>
|
|
|
|
|
16 Apr 1995.</em>
|
|
|
|
|
|
|
|
|
|
<bf>Question:</bf> <em>By the way, I have seen no description
|
|
|
|
|
of how FreeBSD uses PC memory, ie
|
|
|
|
|
what 0-640K gets used for, does the kernel load there or higher,
|
|
|
|
|
is the kernel relocated, etc. Is there a paper on this?</em>
|
|
|
|
|
|
|
|
|
|
The boot sector will be loaded at 0:0x7c00, and relocates itself
|
|
|
|
|
immediately to 0x7c0:0. (This is nothing magic, just an adjustment
|
|
|
|
|
for the %cs selector, done by an ljmp.)
|
|
|
|
|
|
|
|
|
|
It then loads the first 15 sectors at 0x10000 (segment BOOTSEG in the
|
|
|
|
|
biosboot Makefile), and sets up the stack to work below 0x1fff0.
|
|
|
|
|
After this, it jumps to the entry of boot2 within that code. I.e., it
|
|
|
|
|
jumps over itself and the (dummy) partition table, and it's going to
|
|
|
|
|
adjust the %cs selector---we are still in 16-bit mode there.
|
|
|
|
|
|
|
|
|
|
boot2 asks for the boot file, and examines the a.out header. It masks
|
|
|
|
|
the file entry point (usually 0xf0100000) by 0x00ffffff, and loads the
|
|
|
|
|
file there. Hence the usual load point is 1 MB (0x00100000). During
|
|
|
|
|
load, the boot code toggles back and forth between real and protected
|
|
|
|
|
mode, to use the BIOS in real mode.
|
|
|
|
|
|
|
|
|
|
The boot code itself uses segment selectors 0x18 and 0x20 for %cs and
|
|
|
|
|
%ds/%es in protected mode, and 0x28 to jump back into real mode. The
|
|
|
|
|
kernel is finally started with %cs 0x08 and %ds/%es/%ss 0x10, which
|
|
|
|
|
refer to dummy descriptors covering the whole address space.
|
|
|
|
|
|
|
|
|
|
The kernel will be started at its load point. Since it's been linked
|
|
|
|
|
for another (high) address, it will have to execute PIC until the page
|
|
|
|
|
table and page directory stuff is setup properly, at which point
|
|
|
|
|
paging will be enabled and the kernel will finally run at the address
|
|
|
|
|
for which it was linked.
|
|
|
|
|
|
|
|
|
|
The kernel still skips over the first 0x500 bytes of code, in the
|
|
|
|
|
assumption this were valuable BIOS data space (back from old days
|
|
|
|
|
where it has been loaded low).
|
|
|
|
|
|
|
|
|
|
<em>Contributed by &a.davidg;.<newline>
|
|
|
|
|
16 Apr 1995.</em>
|
|
|
|
|
|
|
|
|
|
The physical pages immediately following the kernel BSS contain
|
|
|
|
|
proc0's page directory, page tables, and upages. Some time later
|
|
|
|
|
when the VM system is initialized, the physical memory between
|
|
|
|
|
0x1000-0x9ffff and the physical memory after the kernel
|
|
|
|
|
(text+data+bss+proc0 stuff+other misc) is made available in the
|
|
|
|
|
form of general VM pages and added to the global free page list.
|
|
|
|
|
|
|
|
|
|
|
