| It is currently Wed May 22, 2013 4:00 am |
|
All times are UTC |
Moderator: Moderators
|
Page 1 of 2 |
[ 22 posts ] | Go to page 1, 2 Next |
| Print view | Previous topic | Next topic |
| Author | Message |
|---|---|
|
Site Admin Joined: Sat Oct 20, 2007 7:58 pm Posts: 454 |
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 |
|
|
Moderator
Joined: Thu Jan 10, 2008 6:43 pm Posts: 95 Location: USA |
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 |
|
|
Moderator
Joined: Thu Jan 10, 2008 6:43 pm Posts: 95 Location: USA |
Mike wrote: Sorry, no demo yet do to series updates. ETA on the demo? |
| Wed Sep 29, 2010 5:06 pm |
|
|
Site Admin Joined: Sat Oct 20, 2007 7:58 pm Posts: 454 |
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! 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 |
|
|
Moderator
Joined: Thu Jan 10, 2008 6:43 pm Posts: 95 Location: USA |
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! Thanks again! |
| Wed Oct 06, 2010 1:42 pm |
|
|
Joined: Wed Jul 22, 2009 6:44 am Posts: 63 |
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 |
|
|
Site Admin Joined: Sat Oct 20, 2007 7:58 pm Posts: 454 |
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 |
|
|
Joined: Wed Jul 22, 2009 6:44 am Posts: 63 |
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 |
|
|
Site Admin Joined: Sat Oct 20, 2007 7:58 pm Posts: 454 |
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 |
|
|
Joined: Wed Jul 22, 2009 6:44 am Posts: 63 |
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 |
|
|
Joined: Wed Jul 22, 2009 6:44 am Posts: 63 |
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 |
|
|
Joined: Sun Feb 15, 2009 8:49 pm Posts: 30 Location: Kyiv, Ukraine |
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 |
|
|
Joined: Wed Jul 22, 2009 6:44 am Posts: 63 |
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 |
|
|
Joined: Sun Feb 15, 2009 8:49 pm Posts: 30 Location: Kyiv, Ukraine |
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 |
|
|
Joined: Wed Jul 22, 2009 6:44 am Posts: 63 |
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 |
|
|
Page 1 of 2 |
[ 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 |