50 lines
		
	
	
	
		
			2.3 KiB
		
	
	
	
		
			Text
		
	
	
	
	
	
			
		
		
	
	
			50 lines
		
	
	
	
		
			2.3 KiB
		
	
	
	
		
			Text
		
	
	
	
	
	
| <!-- $Id: memoryuse.sgml,v 1.9 1997-02-22 12:58:51 peter 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 is 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 has 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.
 | |
| 
 | |
| 
 |