On Jul 2, 2009, at 3:11 PM, Aaron Pace wrote:
Hello, I wrote to this list quite some time ago concerning a board that has 2 gigs of ram mapped in at 0x0.0000.0000 - 0x0.7fff.ffff, and a second 2 gigs of ram at 0x1.0000.0000 - 0x1.7fff.ffff. Kumar responded and mentioned that this wasn't currently supported in the powerpc architecture. I've had this on my 'curiosity' back burner to take a look at for some time. I found a little time to look at this, and what I discovered is that this seems to actually have been a fairly trivial problem to solve. I'd like to get some feedback on the method I used, if possible, to see if I've overlooked something blatantly obvious. In MMU_init of arch/powerpc/mm/init_32.c, where the current code sets lmb.memory.cnt to zero, I instead walk through the memory regions and call lmb_reserve for each chunk of memory that lies in a 'hole'. There are then some minor fixups to make sure that total_memory and total_highmem get the right numbers. This small change allows all four gigabytes of memory to be accessed and used in my tests. Am I missing something obvious? Would you like this in a patch for 32 or next, or is there a reason that this would not be desirable in the powerpc branch?
What you described is one possible solution. However when I was thinking about support non-contiguous memory I was thinking about doing at based on CONFIG_DISCONTIGMEM (see include/asm-generic/ memory_model.h). I think ppc64 supports SPARSEMEM which is a variation on the them.
- k _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
