Re: [OpenBIOS] Booting SunOS from OpenBIOS

[Mark Cave-Ayland]

On 04/04/13 20:35, Artyom Tarasenko wrote:
> SunOS crashes at the same place as with your previous patch. (Which is
> probably a good sign).
>
> There is one interesting thing when I try to boot kadb:
> OFMEM: ofmem_claim phys=ffffffffffffffff size=00001000 align=00001000
> OFMEM: ofmem_claim_virt virt=00000000 size=00001000 align=00001000
> OFMEM: ofmem_map_page_range ffc66000 ->  006f7a000 00001000 mode 000000bc

So 0xffc66000 must be being returned back to client for it to use during 
subsequent calculations...
> OFMEM: ofmem_claim phys=ffffffffffffffff size=00002000 align=00002000
> OFMEM: ofmem_claim_virt virt=ffc65000 size=00002000 align=00000000

Can you definitely confirm that virt == va after this second call to 
ofmem_claim_virt()? (i.e. confirm that va isn't being rounded to 
0xffc65000 when passing in va = 0xffc64000 somehow?).

ATB,

Mark.

Booting SunOS from OpenBIOS

[Mark Cave-Ayland]

On 04/04/13 21:32, Mark Cave-Ayland wrote:
> > SunOS crashes at the same place as with your previous patch. (Which is
> > probably a good sign).
> >
> > There is one interesting thing when I try to boot kadb:
> > OFMEM: ofmem_claim phys=ffffffffffffffff size=00001000 align=00001000
> > OFMEM: ofmem_claim_virt virt=00000000 size=00001000 align=00001000
> > OFMEM: ofmem_map_page_range ffc66000 -> 006f7a000 00001000 mode 000000bc
>
> So 0xffc66000 must be being returned back to client for it to use during
> subsequent calculations...

Actually there is another option - does the previous allocation before 
this one that returns 0xffc67000 as the virtual address? In that case it 
could indicate that va=0x0 doesn't have a special meaning after all.

Is it possible for you to post the complete log output from an unpatched 
OpenBIOS for us to look at so we can see the complete pattern of 
allocations?

ATB,

Mark.

Booting SunOS from OpenBIOS

[Artyom Tarasenko]

On Thu, Apr 4, 2013 at 10:45 PM, Mark Cave-Ayland
 wrote:
> On 04/04/13 21:32, Mark Cave-Ayland wrote:
> > > SunOS crashes at the same place as with your previous patch. (Which is
> > > probably a good sign).
> > >
> > > There is one interesting thing when I try to boot kadb:
> > > OFMEM: ofmem_claim phys=ffffffffffffffff size=00001000 align=00001000
> > > OFMEM: ofmem_claim_virt virt=00000000 size=00001000 align=00001000
> > > OFMEM: ofmem_map_page_range ffc66000 -> 006f7a000 00001000 mode 000000bc
> >
> > So 0xffc66000 must be being returned back to client for it to use during
> > subsequent calculations...
>
> Actually there is another option - does the previous allocation before this
> one that returns 0xffc67000 as the virtual address? In that case it could
> indicate that va=0x0 doesn't have a special meaning after all.
>
> Is it possible for you to post the complete log output from an unpatched
> OpenBIOS for us to look at so we can see the complete pattern of
> allocations?

The with the unpatched one it dies pretty early, right after claiming va=0x0.
See the the attachment.

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