OSDev Series Chapter 23

News discussions

Moderator: Moderators

OSDev Series Chapter 23

Postby Mike » Sun Sep 19, 2010 11:55 pm

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
User avatar
Mike
Site Admin
 
Posts: 463
Joined: Sat Oct 20, 2007 7:58 pm

Re: OSDev Series Chapter 23

Postby pathos » Mon Sep 20, 2010 1:16 pm

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!
pathos
Moderator
 
Posts: 97
Joined: Thu Jan 10, 2008 6:43 pm
Location: USA

Re: OSDev Series Chapter 23

Postby pathos » Wed Sep 29, 2010 5:06 pm

Mike wrote:Sorry, no demo yet do to series updates.


ETA on the demo?
pathos
Moderator
 
Posts: 97
Joined: Thu Jan 10, 2008 6:43 pm
Location: USA

Re: OSDev Series Chapter 23

Postby Mike » Tue Oct 05, 2010 9:09 pm

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.

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
User avatar
Mike
Site Admin
 
Posts: 463
Joined: Sat Oct 20, 2007 7:58 pm

Re: OSDev Series Chapter 23

Postby pathos » Wed Oct 06, 2010 1:42 pm

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!
pathos
Moderator
 
Posts: 97
Joined: Thu Jan 10, 2008 6:43 pm
Location: USA

Re: OSDev Series Chapter 23

Postby Insightsoft » Wed Oct 06, 2010 8:05 pm

Code: Select all
                              ++-----------------------------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...
Insightsoft
 
Posts: 63
Joined: Wed Jul 22, 2009 6:44 am

Re: OSDev Series Chapter 23

Postby Mike » Thu Oct 07, 2010 2:36 am

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
User avatar
Mike
Site Admin
 
Posts: 463
Joined: Sat Oct 20, 2007 7:58 pm

Re: OSDev Series Chapter 23

Postby Insightsoft » Thu Oct 07, 2010 8:52 am

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...
Insightsoft
 
Posts: 63
Joined: Wed Jul 22, 2009 6:44 am

Re: OSDev Series Chapter 23

Postby Mike » Thu Oct 07, 2010 10:56 pm

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
User avatar
Mike
Site Admin
 
Posts: 463
Joined: Sat Oct 20, 2007 7:58 pm

Re: OSDev Series Chapter 23

Postby Insightsoft » Fri Oct 08, 2010 12:45 am

You mean, the descriptor bit (GDT), right? (am I right?)
You set it to 1, then the indexes are multiplied by 4k

Thus,
Code: Select all
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: Select all
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...
Insightsoft
 
Posts: 63
Joined: Wed Jul 22, 2009 6:44 am

Re: OSDev Series Chapter 23

Postby Insightsoft » Sun Oct 10, 2010 10:44 pm

Hi, Mike (again)

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


About your "pmmngr_init"
Code: Select all
-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...
Insightsoft
 
Posts: 63
Joined: Wed Jul 22, 2009 6:44 am

Re: OSDev Series Chapter 23

Postby djsilence » Mon Oct 11, 2010 12:14 am

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.
User avatar
djsilence
 
Posts: 30
Joined: Sun Feb 15, 2009 8:49 pm
Location: Kyiv, Ukraine

Re: OSDev Series Chapter 23

Postby Insightsoft » Mon Oct 11, 2010 11:26 am

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...
Insightsoft
 
Posts: 63
Joined: Wed Jul 22, 2009 6:44 am

Re: OSDev Series Chapter 23

Postby djsilence » Mon Oct 11, 2010 12:06 pm

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.
User avatar
djsilence
 
Posts: 30
Joined: Sun Feb 15, 2009 8:49 pm
Location: Kyiv, Ukraine

Re: OSDev Series Chapter 23

Postby Insightsoft » Mon Oct 11, 2010 3:29 pm

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: Select all
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...
Insightsoft
 
Posts: 63
Joined: Wed Jul 22, 2009 6:44 am

Next

Return to News Discussion

Who is online

Users browsing this forum: No registered users and 2 guests