OSDev Series Chapter 23

[Mike]

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.

[pathos]

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]

Sorry, no demo yet do to series updates.

ETA on the demo?

[Mike]

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. 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.

[pathos]

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!

[Insightsoft]

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...

[Mike]

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.

[Insightsoft]

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?

[Mike]

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.

[Insightsoft]

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!

[Insightsoft]

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?

[djsilence]

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.

[Insightsoft]

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?

[djsilence]

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 =))

[Insightsoft]

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...)