Question on Physical Memory Management in JamesM tutorial

Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
Post Reply
madjake
Posts: 3
Joined: Wed Jan 23, 2013 7:14 am

Question on Physical Memory Management in JamesM tutorial

Post by madjake »

Hi,

I'm working my way through the JamesM tutorial (latest rev from googlecode) and I'm confused about how the physical memory is being initialized in chapter_7.

There is the following call to init_pmm() in main.c:

Code: Select all

init_pmm (mboot_ptr->mem_upper);
From the multiboot spec, I understand that mem_upper is the amount of "upper memory" (memory above 1MB) expressed in KB.
However, init_pmm() appears to be expecting an address where it can start memory allocation.

Code: Select all

void init_pmm (uint32_t start)
{
  // Ensure the initial page allocation location is page-aligned.
  pmm_location = (start + 0x1000) & PAGE_MASK;
}
So it looks like I'm passing a memory size in KB to a function that is expecting a physical memory address. It works but doesn't look right to me. What am I missing here?

Thanks in advance to those who kindly help the newbies on this forum. It is a great learning resource. And many thanks to JamesM for creating this tutorial.
Last edited by madjake on Wed Jan 23, 2013 9:09 am, edited 1 time in total.
User avatar
Griwes
Member
Member
Posts: 374
Joined: Sat Jul 30, 2011 10:07 am
Libera.chat IRC: Griwes
Location: Wrocław/Racibórz, Poland
Contact:

Re: Question on Physical Memory Management in JamesM tutoria

Post by Griwes »

Could you please stop confusing "noob" (= idiot who tries to do something, but is too stupid to learn anything; we are always trying to make them go away) and "newbie" (= someone who just came to the field)? Thanks.

Now, quoting Multiboot Specification:
The value returned for upper memory is maximally the address of the first upper memory hole minus 1 megabyte. It is not guaranteed to be this value.
So, essentially, it *is* address, but validity of this pmm_init() call is, I would say, questionable.
Reaver Project :: Repository :: Ohloh project page
<klange> This is a horror story about what happens when you need a hammer and all you have is the skulls of the damned.
<drake1> as long as the lock is read and modified by atomic operations
madjake
Posts: 3
Joined: Wed Jan 23, 2013 7:14 am

Re: Question on Physical Memory Management in JamesM tutoria

Post by madjake »

Griwes wrote:Could you please stop confusing "noob" (= idiot who tries to do something, but is too stupid to learn anything; we are always trying to make them go away) and "newbie" (= someone who just came to the field)? Thanks.
Fixed. Apologies to any newbies that I may have offended.
Now, quoting Multiboot Specification:
The value returned for upper memory is maximally the address of the first upper memory hole minus 1 megabyte. It is not guaranteed to be this value.
So, essentially, it *is* address, but validity of this pmm_init() call is, I would say, questionable.
I read that in the specification but it actually added to my confusion. If mem_upper is expressed in kilobytes, how can it be used unmodified as an address expressed in bytes? At the very least, I'd expect to see a transform from kilobytes to bytes somewhere.

For example, on my 32MB VM, I see that mem_upper returns 31860 kilobytes. pmm_init() takes this value of 31860, aligns it to 4K page boundary and starts allocating at the address value of 32768. It appears to work now but I don't understand why it will continue to work reliably.
User avatar
AJ
Member
Member
Posts: 2646
Joined: Sun Oct 22, 2006 7:01 am
Location: Devon, UK
Contact:

Re: Question on Physical Memory Management in JamesM tutoria

Post by AJ »

Hi,

I haven't looked in to that tutorial in great deatil for some time, but there are some known bugs in there. I believe JamesM left some of these intact to prevent copy and paste coding, but am not sure if this is one of them! I know that at one point there was talk of an updated tutorial, but believe that this never happened.

Cheers,
Adam
madjake
Posts: 3
Joined: Wed Jan 23, 2013 7:14 am

Re: Question on Physical Memory Management in JamesM tutoria

Post by madjake »

AJ wrote:Hi,

I haven't looked in to that tutorial in great deatil for some time, but there are some known bugs in there. I believe JamesM left some of these intact to prevent copy and paste coding, but am not sure if this is one of them! I know that at one point there was talk of an updated tutorial, but believe that this never happened.

Cheers,
Adam
Thanks for the heads up, Adam. I noticed that the googlecode project was active up until September 2011 so I assumed the tutorial was in good shape. It would be a shame if there were intentional bugs because the code is well documented and I've learnt a lot from the previous chapters.

I'm fairly certain that this pmm_init() call is a bug because simply going from a 32MB VM setup to a 64MB predictably results in the page directory trashing the kernel code (at least on my bochs setup). I'll need to do more reading to understand where the page directory should have been allocated. If anyone has already completed the tutorial and fixed this bug, please post your solution.
halofreak1990
Member
Member
Posts: 41
Joined: Thu Aug 09, 2012 5:10 am

Re: Question on Physical Memory Management in JamesM tutoria

Post by halofreak1990 »

For my own kernel, I chose an arbitrary memory address to store the physical memory bitmap, using the value in the multiboot structure to specify the maximum size of allocatable memory.

At present, the memory bitmap is located at address 0xC0001000, which maps to 0x1000 physical, and the kernel's own page directory is actually part of my kernel binary.
<PixelToast> but i cant mouse

Porting is good if you want to port, not if you want maximum quality. -- sortie
Post Reply