[OpenBIOS] [PATCH 5/5] Change OFMEM to allocate memory from the top of RAM downwards.

[Andreas Färber]

Am 22.12.2010 um 11:49 schrieb Mark Cave-Ayland:

> Andreas Färber wrote:
>
>> While I'm not against reversing the direction, your above statement  
>> worries me. Our claim code should only claim free memory. So either  
>> the respective boot loader doesn't actually claim the memory it's  
>> using (the recent ppc bug that broke Haiku), or there's a bug in  
>> ofmem that you're hiding by this change. Both directions should in  
>> theory work, I believe.
>
> Okay - having played with this a bit further, it seems that it's the  
> physical memory allocations that need to be reversed in order to  
> prevent my Solaris 8 kernel from crashing mid-boot. Below is the log  
> from my OFMEM-enabled SPARC32 OpenBIOS booting Solaris 8 with  
> physical memory allocated from the bottom upwards:

[...]
> OFMEM: ofmem_claim phys=ffffffffffffffff size=00018000 align=00000008
> OFMEM: ofmem_claim phys returned 000135000
> OFMEM: ofmem_claim_virt virt=f025d000 size=00018000 align=00000000
> OFMEM: ofmem_map_page_range f025d000 -> 000135000 00018000 mode  
> 000000bc
>
> (hangs at this point)
>
>
> The Solaris boot loader appears to be claiming specific virtual  
> addresses, but claiming the physical addresses from the pool. The  
> last physical address allocated from the pool before the crash is  
> 0x135000 which I think may be overwriting the kernel itself as I  
> have something in the back of my mind that says the kernel is loaded  
> at 0x100000 - Blue any ideas?

As a general piece of advice I would suggest to turn on debugging for  
the CIF. I would assume that the client simply calls "claim", then  
something might be wrong with the mapping to ofmem. Or Solaris makes  
specific assumptions, which Tarl might be able to answer. Maybe you  
need to claim specific parts of memory during initial setup so that  
they are exempt.

Andreas