Re: [OpenBIOS] Getting Closer With Booting AIX? I Would Like to Help Please.

[Kenneth Salerno]

----- Original Message -----
> From: Mark Cave-Ayland 
> To: [e-mail]
> Cc: 
> Sent: Tuesday, May 24, 2011 5:56 AM
> Subject: Re: [OpenBIOS] Getting Closer With Booting AIX? I Would Like to Help Please.
>
> 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.
>
> -- Mark Cave-Ayland - Senior Technical Architect
> PostgreSQL - PostGIS
> Sirius Corporation plc - control through freedom
> http://www.siriusit.co.uk
> t: [phone]
>
> Sirius Labs: http://www.siriusit.co.uk/labs
>
> -- OpenBIOS                 http://openbios.org/
> Mailinglist:  http://lists.openbios.org/mailman/listinfo
> Free your System - May the Forth be with you

Changed code as requested:

if( !align ) {
            OFMEM_TRACE("we are here! KPS\n");
                if( is_free(addr, size, ofmem->virt_range) &&
                    is_free(addr, size, ofmem->phys_range) ) {
                        ofmem_claim_phys_( 0, size, PAGE_SIZE, 0, ofmem_arch_get_phys_top(), -1 );
                        ofmem_claim_virt_( addr, size, 0, 0, 0, 0 );
                        virt = phys = addr;
                } else {
                        OFMEM_TRACE("**** ofmem_claim failure ***!\n");
                        return -1;
                }

Same result however:
> > OFMEM: ofmem_claim 0000412c 00000040 00000000
> > OFMEM: we are here! KPS
> > OFMEM: ofmem_map_page_range 00004000 -> 0000000000004000 00001000 mode 00000002
> > OFMEM: ofmem_claim 0000416c 00ecc600 00000000
> > OFMEM: we are here! KPS
> > OFMEM: ofmem_map_page_range 00004000 -> 0000000000004000 00ecd000 mode 00000002
> > OFMEM: ofmem_claim 0fe00000 00200000 00000000
> > OFMEM: we are here! KPS
> > OFMEM: **** ofmem_claim failure ***!

Only now when I try -m 260 I'm getting the error either way:
> > OFMEM: ofmem_claim 0000412c 00000040 00000000
> > OFMEM: we are here! KPS
> > OFMEM: ofmem_map_page_range 00004000 -> 0000000000004000 00001000 mode 00000002
> > OFMEM: ofmem_claim 0000416c 00ecc600 00000000
> > OFMEM: we are here! KPS
> > OFMEM: ofmem_map_page_range 00004000 -> 0000000000004000 00ecd000 mode 00000002
> > OFMEM: ofmem_claim 0fe00000 00200000 00000000
> > OFMEM: we are here! KPS
> > OFMEM: **** ofmem_claim failure ***!

If I put -m 512 it works:
> > OFMEM: ofmem_claim 0000412c 00000040 00000000
> > OFMEM: we are here! KPS
> > OFMEM: ofmem_map_page_range 00004000 -> 0000000000004000 00001000 mode 00000002
> > OFMEM: ofmem_claim 0000416c 00ecc600 00000000
> > OFMEM: we are here! KPS
> > OFMEM: ofmem_map_page_range 00004000 -> 0000000000004000 00ecd000 mode 00000002
> > OFMEM: ofmem_claim 0fe00000 00200000 00000000
> > OFMEM: we are here! KPS
> > OFMEM: ofmem_map_page_range 0fe00000 -> 000000000fe00000 00200000 mode 00000002

If I revert back to the original code, I can use -m 260 again:
> > OFMEM: ofmem_claim 0000412c 00000040 00000000
> > OFMEM: we are here! KPS
> > OFMEM: ofmem_map_page_range 00004000 -> 0000000000004000 00001000 mode 00000002
> > OFMEM: ofmem_claim 0000416c 00ecc600 00000000
> > OFMEM: we are here! KPS
> > OFMEM: ofmem_map_page_range 00004000 -> 0000000000004000 00ecd000 mode 00000002
> > OFMEM: ofmem_claim 0fe00000 00200000 00000000
> > OFMEM: we are here! KPS
> > OFMEM: ofmem_map_page_range 0fe00000 -> 000000000fe00000 00200000 mode 00000002

Ken