[OpenBIOS] Booting SunOS from OpenBIOS

[Artyom Tarasenko]

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+ :

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> bt
symbol not found
kadb>

But still it's definitely a progress!


--
Regards,
Artyom Tarasenko

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