BrokenThorn Entertainment - View topic - OSDev Series Chapter 23
It is currently Sat May 18, 2013 4:46 pm




Post new topic Reply to topic  [ 22 posts ]  Go to page 1, 2  Next
OSDev Series Chapter 23 
Author Message
Site Admin
User avatar

Joined: Sat Oct 20, 2007 7:58 pm
Posts: 454
Post OSDev Series Chapter 23
Hello everyone,

OSDev Series Chapter 23 has been released. It covers user mode, TSS, and System API topics. Sorry, no demo yet do to series updates. Everything should be updated by this week including additional content added to this chapter.

Single tasking has been moved to the next chapter, which will cover Loaders in detail: including information on shared resources and PE loading.

_________________
Lead Programmer for BrokenThorn Entertainment, Co.
Website: http://www.brokenthorn.com
Email: webmaster@brokenthorn.com


Sun Sep 19, 2010 11:55 pm
Profile E-mail WWW
Moderator

Joined: Thu Jan 10, 2008 6:43 pm
Posts: 95
Location: USA
Post Re: OSDev Series Chapter 23
Mike wrote:
Hello everyone,

OSDev Series Chapter 23 has been released. It covers user mode, TSS, and System API topics. Sorry, no demo yet do to series updates. Everything should be updated by this week including additional content added to this chapter.

Single tasking has been moved to the next chapter, which will cover Loaders in detail: including information on shared resources and PE loading.


Thanks a lot. Bummer about single tasking -- I was looking forward to it. But I can wait!

[edit]
I just noticed you added the new/changed file list this time -- thanks a lot!


Mon Sep 20, 2010 1:16 pm
Profile
Moderator

Joined: Thu Jan 10, 2008 6:43 pm
Posts: 95
Location: USA
Post Re: OSDev Series Chapter 23
Mike wrote:
Sorry, no demo yet do to series updates.


ETA on the demo?


Wed Sep 29, 2010 5:06 pm
Profile
Site Admin
User avatar

Joined: Sat Oct 20, 2007 7:58 pm
Posts: 454
Post Re: OSDev Series Chapter 23
Hello,

Single tasking is pretty easy to implement with all of the information provided. Everything thats needed has technically already been covered, just not with emphasis toward OS loaders.

Quote:
I just noticed you added the new/changed file list this time -- thanks a lot!
I have seen the request and appreciate your great suggestion. :D I do hope it will improve the series articles when everything is updated and help make the series easier to follow.

With regards to the demo, I should have time in the weekend to release the upcoming demo software. I apologize for the delay, busy week.

_________________
Lead Programmer for BrokenThorn Entertainment, Co.
Website: http://www.brokenthorn.com
Email: webmaster@brokenthorn.com


Tue Oct 05, 2010 9:09 pm
Profile E-mail WWW
Moderator

Joined: Thu Jan 10, 2008 6:43 pm
Posts: 95
Location: USA
Post Re: OSDev Series Chapter 23
Mike wrote:
Single tasking is pretty easy to implement with all of the information provided.

Yeah, for someone who actually knows what they're doing! :lol:

Thanks again!


Wed Oct 06, 2010 1:42 pm
Profile

Joined: Wed Jul 22, 2009 6:44 am
Posts: 63
Post Re: OSDev Series Chapter 23
Code:
                              ++-----------------------------Address             
                              ||             
                              ||           +-----------------Available for System 
                              ||           | +---------------Global Page
                              ++           | |
                             /  \          | |+--------------Page Table Attribute Index
                            /    \         | ||+-------------Dirty
                           /      \        | |||+------------Accessed
                          /        \       | ||||+-----------Cache Disabled
                         /          \      | |||||+----------Write-through
                        /            \     | ||||||+---------User/Supervisor
                       /              \    | |||||||+--------R/W
                      /                \   | ||||||||+-------present
                     /                  \ / \|||||||||
                     7654321o7654321o7654 321o76543210               value in address field
Table 0               ---------------------------------               -----------------------
   entry      0      00000000000000000000 000000000011   4k             0
   entry      1      00000000000000000001 000000000011   4k             1
   entry      2      00000000000000000010 000000000011   4k             2
                  x
   entry   1021      00000000000000111101 000000000011   4k            61
   entry   1022      00000000000000111110 000000000011   4k            62
   entry   1023      00000000000000111111 000000000011   4k   4mb      63




Table 768            ---------------------------------
   entry      0      00000000000000010000 000000000011   4k            16
   entry      1      00000000000000010001 000000000011   4k            17
   entry      2      00000000000000010010 000000000011   4k            18
                  x
   entry   1021      00000000000001001101 000000000011   4k            77
   entry   1022      00000000000001001110 000000000011   4k            78
   entry   1023      00000000000001001111 000000000011   4k   4mb      79



Will the entries multiplied by 4k??

on "copy kernel"
you use: 0xC0000000
1100000000 0000000000 000000000000
PDE=3 pointing to ????? There is not any entry at position 3 (only 0 and 768)
PTE=0 pointing to 0 PAGE
Offset=0 starting from first byte of that page...

_________________
_____________
Think it, build it, bit by bit...


Wed Oct 06, 2010 8:05 pm
Profile E-mail
Site Admin
User avatar

Joined: Sat Oct 20, 2007 7:58 pm
Posts: 454
Post Re: OSDev Series Chapter 23
Hello,

0xC0000000 is a virtual address that refers to PDE 768 (not 3). The high ten bits, 1100000000 binary = 768 decimal. The PTE and offset bits refer to PTE 0, offset 0 in the page entry.

You are correct that the only two page tables created are for PDE entry 0 and 768.

_________________
Lead Programmer for BrokenThorn Entertainment, Co.
Website: http://www.brokenthorn.com
Email: webmaster@brokenthorn.com


Thu Oct 07, 2010 2:36 am
Profile E-mail WWW

Joined: Wed Jul 22, 2009 6:44 am
Posts: 63
Post Re: OSDev Series Chapter 23
You are absolutely right... (I was doing the calculation visually, and tired, I did it badly ...)

...and what about the index. Are they multiplied by 4k?

_________________
_____________
Think it, build it, bit by bit...


Thu Oct 07, 2010 8:52 am
Profile E-mail
Site Admin
User avatar

Joined: Sat Oct 20, 2007 7:58 pm
Posts: 454
Post Re: OSDev Series Chapter 23
Hello,

The granularity bit is used to set page granularity. If 0, the set limit is in bytes. If its set, its multiplied by 4k.

_________________
Lead Programmer for BrokenThorn Entertainment, Co.
Website: http://www.brokenthorn.com
Email: webmaster@brokenthorn.com


Thu Oct 07, 2010 10:56 pm
Profile E-mail WWW

Joined: Wed Jul 22, 2009 6:44 am
Posts: 63
Post Re: OSDev Series Chapter 23
You mean, the descriptor bit (GDT), right? (am I right?)
You set it to 1, then the indexes are multiplied by 4k

Thus,
Code:
Available for System  =0
Global Page=0
Page Table Attribute Index=0
Dirty=0
Accessed=0
Cache Disabled=0
Write-through=0
User/Supervisor=0
R/W=1
present=1


Code:
address * 4k (it makes sense. it forces memory to be exactly 4k apart along the way)


That was all I needed. Thanks!

_________________
_____________
Think it, build it, bit by bit...


Fri Oct 08, 2010 12:45 am
Profile E-mail

Joined: Wed Jul 22, 2009 6:44 am
Posts: 63
Post Re: OSDev Series Chapter 23
Hi, Mike (again)

---input---
my system has 128 Mb
---/input---


About your "pmmngr_init"
Code:
-1. You set table 768 to point to 0x100000 (phys);
-2. You copy the kernel to the very first byte of that table (let's call it head) down to len(kernel) (let's call it tail)  and 16896 bytes long...
-3. Jump to Kernel
-4. In kernel, at pmmngr_init you set:
   - _mmngr_memory_size -> 130816d (from the loader)
        - _mmngr_memory_map -> ponting to vrt_address of tail -> C0004200
        - _mmngr_max_blocks -> (all memory in bytes(133.955.584) / 4096) -> 32704 (blocks)
        - _mmngr_used_blocks -> _mmngr_max_blocks
        - then comes memset that, basically, put 0xf in all bytes (along the way)...
              - Initial counter value: _mmngr_max_blocks / PMMNGR_BLOCKS_PER_BYTE(8) -> 4088
              - SOURCE: tail's address + 4088
              - TARGET: when counter(c) reach 0 -> or tail's address

    0xC0000000-krnl Head
    0xC000XXXX-krnl body
    0xC0004200-krnl tail
    0xC000XXXX-0xF
    0xC00051F8-0xF   (tail's address + 4088d)


I need to understand this number 4088 (Number of blocks/8)
Why you add 4088 bytes (all seted to 0xF) just above the kernel? is it fundamental?

_________________
_____________
Think it, build it, bit by bit...


Sun Oct 10, 2010 10:44 pm
Profile E-mail
User avatar

Joined: Sun Feb 15, 2009 8:49 pm
Posts: 30
Location: Kyiv, Ukraine
Post Re: OSDev Series Chapter 23
This 4088 bytes is physical memory map. Each bit in this area of bytes shows the state of physical memory block (each 4KB in size) (e.g. first bit of first byte 0 => your first 4KB are free for use, 1 => it is already used, or not used if memory region type is not available). So, to store information of 8 memory blocks will be enough 8 bits => BLOCKS_PER_BYTE = 8; If you try run it on other machine with other amount or RAM number of bytes written right after kernel will be different.

But I can't understand, why 0x0F? Shouldn't it be 0xFF? I use 0xFF instead 0x0F and everything works fine.

_________________
Thinking of great - thinking of little, thinking of little - thinking of great.


Mon Oct 11, 2010 12:14 am
Profile E-mail WWW

Joined: Wed Jul 22, 2009 6:44 am
Posts: 63
Post Re: OSDev Series Chapter 23
its seems to me that is a bug, since a 8 block is represented by a byte...
and it works fine in any fashion because we haven't much use of memory.
But it seems that you are right and should be 0xFF

On dealing with BIOS region, why Mike sets it as a free blocks of memory? it's not supposed to be marked as "in use" memory? (see pmmngr_init_region)
...just like he did with kernel region; he left it marked (in use)... (see pmmngr_deinit_region)
...and other memory blocks is left marked as "in use" - why?
...is not supposed that, at this stage, only BIOS data area and, of course, the Kernel, has to be marked?

_________________
_____________
Think it, build it, bit by bit...


Mon Oct 11, 2010 11:26 am
Profile E-mail
User avatar

Joined: Sun Feb 15, 2009 8:49 pm
Posts: 30
Location: Kyiv, Ukraine
Post Re: OSDev Series Chapter 23
I guess we don't need IVT anymore, while we are in protected mode. (And it is [0x00 - 0x3FF] region of memory). You can set it as in use, but think before: will you use it? The only BIOS area that lefts untouchable - Extra Bios Data Region and ROM area (because type of that regions is Reserved, so that regions are set as busy). And talking about 8 memory blocks per byte: it's not a bug, it is normal way: to store information about 4GB of physical memory you jest need 128KB. You even shouldn't allocated more than one page. Of course, if you go with PAE (Physical Address Extension) you have to find another way. But I really don't think you Virtual Machine has at least 4 GB of RAM =))

_________________
Thinking of great - thinking of little, thinking of little - thinking of great.


Mon Oct 11, 2010 12:06 pm
Profile E-mail WWW

Joined: Wed Jul 22, 2009 6:44 am
Posts: 63
Post Re: OSDev Series Chapter 23
djsilence wrote:
I guess we don't need IVT anymore, while we are in protected mode. (And it is [0x00 - 0x3FF] region of memory). You can set it as in use, but think before: will you use it? The only BIOS area that lefts untouchable - Extra Bios Data Region and ROM area (because type of that regions is Reserved, so that regions are set as busy). And talking about 8 memory blocks per byte: it's not a bug, it is normal way: to store information about 4GB of physical memory you jest need 128KB. You even shouldn't allocated more than one page. Of course, if you go with PAE (Physical Address Extension) you have to find another way. But I really don't think you Virtual Machine has at least 4 GB of RAM =))


i was not talking about IVT... I was talking about the information stored in (memory_region*)0x1000 with function 0x15 (eax=0xe820) (Originally introduced with the Phoenix BIOS v4.0)
Code:
01h    memory, available to OS
02h    reserved, not available (e.g. system ROM, memory-mapped device)
03h    ACPI Reclaim Memory (usable by OS after reading ACPI tables)
04h    ACPI NVS Memory (OS is required to save this memory between NVS sessions)
other  not defined yet -- treat as Reserved


About 8 memory blocks per bytes: What I said was that Mike has put 0xF instead 0xFF (perhaps, forgotten...)

_________________
_____________
Think it, build it, bit by bit...


Mon Oct 11, 2010 3:29 pm
Profile E-mail
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 22 posts ]  Go to page 1, 2  Next


Who is online

Users browsing this forum: No registered users and 0 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron

Powered by phpBB © phpBB Group.
Original Design by Vjacheslav Trushkin for Free Forums/DivisionCore.
Theme and forum modified by BrokenThorn Entertainment, Co.