mirror of
https://git.hardenedbsd.org/hardenedbsd/HardenedBSD.git
synced 2024-12-29 15:10:57 +01:00
51 lines
2.3 KiB
Plaintext
51 lines
2.3 KiB
Plaintext
<!-- $Id: memoryuse.sgml,v 1.4 1995/10/22 00:42:13 jfieber Exp $ -->
|
|
<!-- The FreeBSD Documentation Project -->
|
|
|
|
<sect><heading>PC memory utilization<label id="memoryuse"></heading>
|
|
|
|
<p><em>Contributed by &a.joerg;.<newline>
|
|
16 Apr 1995.</em>
|
|
|
|
<em>A short description of how FreeBSD uses the memory on the i386
|
|
platform</em>
|
|
|
|
The boot sector will be loaded at <tt>0:0x7c00</tt>, and relocates itself
|
|
immediately to <tt>0x7c0:0</tt>. (This is nothing magic, just an adjustment
|
|
for the <tt>%cs</tt> selector, done by an <tt>ljmp</tt>.)
|
|
|
|
It then loads the first 15 sectors at <tt>0x10000</tt> (segment BOOTSEG in the
|
|
biosboot Makefile), and sets up the stack to work below <tt>0x1fff0</tt>.
|
|
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 <tt>a.out</tt> header. It masks
|
|
the file entry point (usually <tt>0xf0100000</tt>) by <tt>0x00ffffff</tt>, and loads the
|
|
file there. Hence the usual load point is 1 MB (<tt>0x00100000</tt>). 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 <tt>0x18</tt> and <tt>0x20</tt> for <tt>%cs</tt> and
|
|
<tt>%ds/%es</tt> in protected mode, and <tt>0x28</tt> to jump back into real mode. The
|
|
kernel is finally started with <tt>%cs</tt> <tt>0x08</tt> and <tt>%ds/%es/%ss</tt> <tt>0x10</tt>, which
|
|
refer to dummy descriptors covering the entire 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.
|
|
|
|
|
|
<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
|
|
<tt>0x1000-0x9ffff</tt> 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.
|
|
|
|
|