[OpenBIOS] Booting SunOS from OpenBIOS

[Artyom Tarasenko]

On Sat, Apr 6, 2013 at 10:27 AM, Artyom Tarasenko <atar4qemu at gmail.com> wrote:
> On Sat, Apr 6, 2013 at 9:16 AM, Mark Cave-Ayland
> <mark.cave-ayland at ilande.co.uk> wrote:
>> On 05/04/13 21:08, Tarl Neustaedter 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.
>>
>>
>> Ah now I see. It looks as if kadb assumes that it has free use of the region
>> from 0xffc00000 but the OFMEM allocator starts auto-allocating memory from
>> beneath the internal heap which is below the ROM image at 0xffd00000. As
>> Tarl rightly points out, as the allocations grow then kadb tries to grab an
>> area of memory we have already claimed which causes the overlap error.
>>
>> Does the attached patch against SVN trunk enable you to get into kadb? It's
>> the same as my last patch except for the following addition:
>>
>> --- a/openbios-devel/arch/sparc32/ofmem_sparc32.c
>> +++ b/openbios-devel/arch/sparc32/ofmem_sparc32.c
>> @@ -61,7 +61,7 @@ ucell ofmem_arch_get_heap_top(void)
>>
>>  ucell ofmem_arch_get_virt_top(void)
>>  {
>> -       return (ucell)TOP_OF_RAM;
>> +       return (ucell)0xff000000;
>>  }
>>
>> So when we are auto-allocating from OFMEM, rather than starting from beneath
>> the internal heap, we simply start auto-allocating from 0xff000000 downwards
>> which should leave the 0xffc00000 region being used by kadb well alone. A
>> quick test with the patch shows that my Solaris 8 image can still boot both
>> normally and into kadb.
>
> Yes! In kadb I get!
>
> FMEM: ofmem_map_page_range ffcb0000 -> 006ea0000 00008000 mode 000000bc
> .vmunix loaded - 0x7c000 bytes used
>
> Unfortunately it's not as helpful as it became under Solaris 2.6+ :

Especially when someone hasn't use it for the long time. Actually it's
pretty good:

kadb> :c
OFMEM: ofmem_claim phys=ffffffffffffffff size=00001000 align=00001000
OFMEM: ofmem_claim_virt virt=00000000 size=00001000 align=00001000
OFMEM: ofmem_map_page_range fef65000 -> 006f77000 00001000 mode 000000bc
Begin traceback... sp = f0186b20
Called from ffc017cc, fp=f0186b80, args=9 f013f870 f013f874 0 200 0
Called from f013f83c, fp=f0186c08, args=f01e4000 1 f01e2bf0 fd020000
f0186d88 f01e2ff4
Called from f0140a38, fp=f0186c68, args=f01e563c 1cc5 f01e5652
ff000008 ff000008 4400fe1
Called from f0054f44, fp=f0186cc8, args=f0186d8c 22 ffffffff a f0186d8c 22
Called from f0054724, fp=f0186d28, args=f0186d8c 22 5 0 ffffffff 0
Called from f0054494, fp=f0186e18, args=f01e2173 f0186ec0 5 0 f0186e10 0
Called from f0132e7c, fp=f0186e78, args=f01e2173 0 0 0 f0186e98 f0186ec0
Called from f01375e0, fp=f0186ef8, args=f01e43c2 ffd2e31c f01e28f4 0
f01e2b1c ffffffff
Called from f0005250, fp=f0186f58, args=400 f01aa000 f9fbe000 0 200 f0178570
Called from ffc11c94, fp=0, args=4000 3ffb78 0 ffc37570 ffc259d0 1
End traceback...
fault and calling cmd: trap 9 sp f0186b20 pc f013f870 npc f013f874
stopped at      0:              unimp   0x0
kadb> $c
PR_BASE() + 0
kadb> f0054f44?ai
_writekmsg+0x68:                _writekmsg+0x68:                call
 _mpprom_write_nl7
kadb> f0005250?ai
_firsthighinstr+0xd8:           _firsthighinstr+0xd8:           call
 _early_startup
kadb>

Woo-hoo!


--
Regards,
Artyom Tarasenko

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