Weiguang SHI wrote:
> I need your help to understand this.
> In machdep.c,
>
> 1451 /*
> 1452 * map page 1 R/W into the kernel page table so we can use
> it
> 1453 * as a buffer. The kernel will unmap this page later.
> 1454 */
> 1455 pte = (pt_entry_t)vtopte(KERNBASE + (1 <<PAGE_SHIFT));
> 1456 *pte = (1 << PAGE_SHIFT) | PG_RW | PG_V;
>
> According to my calculation, pte=0xbfcc0001 and *pte will yield
> 0x2FF,0xC0,0x1 as indexes to the page directory table, page table and
> an offset. My page directory table is like this (starting at physical
> address 0x2C2000):
>
> index page_table_base_address; prot
> ---------- -----------------------------
> 0,0x1D 0x2A4,0x2C1 ; RW
> 0x2FF 0x2C2 ; RW
> 0x300,0x31D 0x2A4,0x2C1 ; RW
>
> The entries that are not listed are all zeros. This table was created
> by "create_pagetable" in locore.s
>
> I know there is a recursive reference, i.e., the 0x2ff entry. But I
> need more (authoritative) explanation on how the triple
> (0x2ff,0xc0,0x1) is going to be resolved.
>
> Would you shed some light?
It gets resolved as the address 0x0C001000. It is a page address
for a 4k page (hint: 0x1000 * 0xc001).
The reason it is mapped is to give a scratchpad area for the VM86()
call(s) to get the memory size information from the BIOS.
The lower area of memory is a 16MB region, when trapping to virtual
8086 mode. The kernel is loaded starting at 1MB in the virtual
address space. For all intents and purposes, the kernel is loaded
at 1MB, as far as it is concerned, and as far as the VM86() code
is concerned, and up to 16MB of RAM is mapped into the VM86() real
mode address space.
Remember that by the time you are running the getmemsize() code,
you are well into the startup code, and have virtual memory enabled.
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
