Menu
▾
▴
[Subtrick-cvs] TiTan/doc/design mem-lay.txt,NONE,1.1
|
From: <sl...@us...> - 2002-08-26 15:44:18
|
Update of /cvsroot/subtrick/TiTan/doc/design
In directory usw-pr-cvs1:/tmp/cvs-serv814
Added Files:
mem-lay.txt
Log Message:
Memory Layout/Kernel Loading
--- NEW FILE: mem-lay.txt ---
Subject : Memory layout / Kernel loading
Part Of The TiTan OS Development Project
Author : Ayman El Sayed
Operating System Sector : Boot
Programming Language : Assembly
Revision : 2
When the computer boots up This is how the memory looks like (in realmode)
you only have access to 1MB of memory
0x00000 - 0x003ff |Interrupt Vector Table|
| 1024 byte |
----------------------
0x00400 - 0x004ff | Bios Data Area |
| 256 byte |
0x00500 - 0x9ffff ----------------------
| FREE Our |
| |
| FREE Part |
| |
| FREE |
| 638 kb |
|(exactly 654079 bytes)|
0xA0000 - 0xAFFFF ----------------------
| Vga Graphic Buffer |
| 64 kb |
0xB0000 - 0xB7FFF ----------------------
| MDA text Buffer |
| 32 kb |
----------------------
0xB8000 - 0xBFFFF | Vga text Buffer |
| 32 kb |
----------------------
0xC0000 - 0xC7FFF | Vga Bios |
| 32 kb |
----------------------
0xC8000 - 0xDFFFF | Free (Reserved) |
| 96 kb |
----------------------
0xE0000 - 0xFFFFF | System/PCI BIOS |
| 127kb |
----------------------
The first thing that I would like to point out is that in protected mode
you don't have access to interrupts that's because you clear the
interrupt vector table (0x00000 -0x003ff) when entering protected mode
and even if you saved the interrupt vector table ,it will be useless
simply because you got to be in 16 bit mode to use the 16 bit IVT
(the 16 bit IVT is 16bit:16bit while in protected mode
we will be using 32 bit)
As you can see the free part (Before entering protected Mode) is
from 0x00500 to 0x9FFFF . so this is the part that we should load
the kernel.img , kernel data , kernel stack in . now you might ask
why not use memory 0x100000 to 0xFFFFFF(above 1 mb)as we're in protected
mode and we're not limited to 0xFFFFF ?.well that's true but the problem
is how would you use interrupt 0x13 to load the kernel image after
entering protected mode? you can't ofcourse ,cause interrupts are
disabled.so now what you can do is load the kernel.img in realmode
in somewhere from 0x00500 to 0x9FFFF and (after entering protected mode)
move the kernel in an address 0x100000 or above so you can have all
the free memory you want (You still can keep it in the 638 kb but why
limit yourself?)
I suggest to load the kernel in address 0x08000
(to be completly safe not to mess up anything)
like that
0x08000 | kernel.img |
-----------
| kernel data |
-----------
| Kernel Stack |
-----------
......
......
......
......
0x9FFFF ......
(Note: 0x08000 is 32 kb from beginning of memory (address 0x00000)
So it's ok for the kernel init to be in address 0x00700 ,as it is a lot less than 30 kb ((0x08000 - 0x00700)/1024) in our case so it won't get into kernel.img Area)
Now what about kernel parameters?
Kernel parameters are informations about the computer we're using
that we got by using interrupts in realmode ,like cpu type,amount
of memory ,the drive we're booting from also inputs from users
and other things that we might want to have access to after
entering protected mode.Now to keep access to those things we need
to save them in a specific place in memory so that after entering
protected mode we can retrieve them from that place again.
I suggest to place them at address 0x90000 ,that would give us
more than enough space to place all the kernel parameters we need
(from 0x90000 to 0x9FFFF) and won't take much from the kernel space
area .
now the memory should look like this
0x08000 | kernel.img |
| kernel data |
| Kernel Stack |
......
......
......
......
......
0x90000 | Kernel |
| Parameters |
0x9FFFF | |
Then (After entering protected mode and having access to memory
above 1 MB) mov the kernel from address 0x08000 to 0x100000
so it'll look like that
---------------------
0xE0000 - 0xFFFFF | System/PCI BIOS |
| 127kb |
0x100000 - 0ximg-end ---------------------
| Kernel Image |
| |
---------------------
| Kernel Data |
| |
---------------------
| Kernel Stack |
| |
---------------------
(Note that here the kernel data and stack can be as big
As we want to cause we're not limited to 638 kb )
Now you might also ask , why do it in that order
kernel.img - kernel data - kernel stack ? that's because if
we're gonna port Gcc we must also port ld (linker) , and ld
by default links the data section immediately after the
code section so that's why I suggested it to be in that order.
Now to run the kernel code we simply jmp 0x100000 and start
executing kernel instructions .
|
