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