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

[Kenneth Salerno]

----- Original Message -----

> From: Mark Cave-Ayland <mark.cave-ayland at siriusit.co.uk>
> To: openbios at openbios.org
> 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: +44 870 608 0063
> 
> 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