[OpenBIOS] Booting SunOS from OpenBIOS

[Artyom Tarasenko]

On Sat, Apr 6, 2013 at 11:07 AM, Blue Swirl <blauwirbel at gmail.com> wrote:
> On Sat, Apr 6, 2013 at 1:50 AM, Artyom Tarasenko <atar4qemu at gmail.com> wrote:
>> On Fri, Apr 5, 2013 at 10:08 PM, Tarl Neustaedter <tarl-b2 at tarl.net> wrote:
>>> On 2013-Apr-5 15:40 , Artyom Tarasenko wrote:
>>>>
>>>> [...]
>>>>
>>>> OFMEM: ofmem_map_page_range ffc7d000 -> 006f7d000 00001000 mode 000000bc
>>>> OFMEM: ofmem_claim phys=ffffffffffffffff size=00014000 align=00020000
>>>> OFMEM: ofmem_claim_virt virt=00000000 size=00014000 align=00020000
>>>> OFMEM: ofmem_map_page_range ffc60000 -> 006f60000 00014000 mode 000000bc
>>>>
>>>> ^^^^ this one
>>>
>>>
>>> Wherever that's coming from, that looks like an allocator doing descending
>>> addresses.
>>>
>>>
>>>> OFMEM: ofmem_map_page_range ffc5c000 -> 006f78000 00001000 mode 000000bc
>>>> OFMEM: ofmem_claim phys=ffffffffffffffff size=00002000 align=00002000
>>>> OFMEM: ofmem_claim_virt virt=ffc5d000 size=00002000 align=00000000
>>>> OFMEM: ofmem_map_page_range ffc5d000 -> 006f5e000 00002000 mode 000000bc
>>>> ...OFMEM: ofmem_claim phys=ffffffffffffffff size=00002000 align=00002000
>>>> OFMEM: ofmem_claim_virt virt=ffc5f000 size=00002000 align=00000000
>>>> OFMEM: Non-free virtual memory claimed!
>>>>
>>>> ^^^^ overlaps with this one.
>>>
>>>
>>> This allocator, whatever it is has been doing ascending addresses. This
>>> actually looks like you simply ran out of room.
>>
>> Ops. Good catch!
>> Mark, can we just allocate more RAM, or do we have serious problem?
>>
>>> You might change that patch rather than rounding up to the next 2^n, don't
>>> bother aligning to anything more than 0x2000.
>>
>> You mean
>>
>>         } else if ( align > 0x2000) {
>>             align = 0x2000;
>>         } else {
>
> This would probably break allocation for IOMMU table, it needs to be
> aligned (physically) to table size (like 32MB).


Hmm. The successful log in the previous mail was produced with this code...
Will remove it and test again.


--
Regards,
Artyom Tarasenko

linux/sparc and solaris/sparc under qemu blog:
http://tyom.blogspot.com/search/label/qemu