On 23/05/11 22:36, Kenneth Salerno wrote:
Andreas, here is the behavior I'm seeing: if I set the memory allocation to 259M, I get this fatal error just as it finishes reading cd:,\ppc\bootinfo.txt:
OFMEM: ofmem_claim 0000412c 00000040 00000000 OFMEM: ofmem_map_page_range 00004000 -> 0000000000004000 00001000 mode 00000002 OFMEM: ofmem_claim 0000416c 00ecc600 00000000 OFMEM: ofmem_map_page_range 00004000 -> 0000000000004000 00ecd000 mode 00000002 OFMEM: ofmem_claim 0fe00000 00200000 00000000 OFMEM: **** ofmem_claim failure ***!
Now that's interesting. The above message comes from this snippet of code here (libopenbios/ofmem_common.c:606):
if( !align ) { if( is_free(addr, size, ofmem->virt_range) && is_free(addr, size, ofmem->phys_range) ) { ofmem_claim_phys_( addr, size, 0, 0, 0, 0 ); ofmem_claim_virt_( addr, size, 0, 0, 0, 0 ); virt = phys = addr; } else { OFMEM_TRACE("**** ofmem_claim failure ***!\n"); return -1; } }
So what is happening is that OFMEM is failing to claim either the physical or virtual address for that particular section of memory. Looking further, it seems that the secret is actually in the numbers:
0xfe00000 = 266M
Because in the above code we claim both physical and virtual memory at the same address, then the above will only be valid with at least 260M of RAM.
Now I understand this better, I'm beginning to think that since these routines are called by the MMU node claim functions, in actual fact it is just the virtual address that is being specified and hence we should just allocate the next free physical address rather than creating a 1:1 virtual to physical mapping.
What happens if you change the physical allocation in the section above to the following?
ofmem_claim_phys_( 0, size, PAGE_SIZE, 0, ofmem_arch_get_phys_top(), -1 );
That should pick the next free page-aligned physical region instead, and therefore guarantee that the allocated range will lie within the physical machine RAM.
ATB,
Mark.