mirror of
https://git.hardenedbsd.org/hardenedbsd/HardenedBSD.git
synced 2024-11-19 01:11:05 +01:00
73 lines
3.0 KiB
Plaintext
73 lines
3.0 KiB
Plaintext
~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
|
|
|