Put David's and my answer regarding loader and kernel memory usage

here.
This commit is contained in:
Joerg Wunsch 1995-04-16 13:04:21 +00:00
parent afb7eb14a5
commit 28cd12e87e
Notes: svn2git 2020-12-20 02:59:44 +00:00
svn path=/head/; revision=7885

View File

@ -0,0 +1,72 @@
~From: J Wunsch <j@uriah.heep.sax.de>
~Message-Id: <199504160843.KAA16160@uriah.heep.sax.de>
~Subject: Memory usage (Was Re: Memory init pattern)
~To: freebsd-hackers@FreeBSD.org (FreeBSD hackers)
~Date: Sun, 16 Apr 1995 10:43:29 +0200 (MET DST)
[Audience extended to -hackers, since it's a general topic.]
As Frank Durda IV wrote:
>
> 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?
Since i've just digged through the boot code, i can tell you what's
going there. :) [Someone going to collect this sort of messages
and making a kernel hackers manual?]
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 finally runs at the address
where it has been linked to.
[... -- no longer valid]
The later memory usage (once paging is enabled) could better be
explained by the VM folks.
--
cheers, J"org
joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/
Never trust an operating system you don't have sources for. ;-)
~Message-Id: <199504160955.CAA00143@corbin.Root.COM>
~To: freebsd-hackers@FreeBSD.org (FreeBSD hackers)
~Subject: Re: Memory usage (Was Re: Memory init pattern)
~From: David Greenman <davidg@Root.COM>
~Date: Sun, 16 Apr 1995 02:55:50 -0700
...
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.
Does this answer the question?
-DG