All cross reference labels start with name of the file that contains them. A label for the top section level is simply the name of the file (omitting the .sgml). Other references within the file append a colon and onother name. For example, the label on the mailing list section in the file eresources.sgml is eresources:mail. This gives each file its own cross reference namespace.
		
			
				
	
	
		
			55 lines
		
	
	
	
		
			2.4 KiB
		
	
	
	
		
			Text
		
	
	
	
	
	
			
		
		
	
	
			55 lines
		
	
	
	
		
			2.4 KiB
		
	
	
	
		
			Text
		
	
	
	
	
	
<!-- $Id: memoryuse.sgml,v 1.2 1995-06-30 17:37:42 jfieber Exp $ -->
 | 
						|
<!-- The FreeBSD Documentation Project -->
 | 
						|
 | 
						|
<chapt><heading>PC memory utilization<label id="memoryuse"></heading>
 | 
						|
 | 
						|
<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.
 | 
						|
 | 
						|
 |