Re: [OpenBIOS] Qemu/OpenBIOS 64-bit

[Mark Cave-Ayland]

On 29/12/13 14:12, Artyom Tarasenko wrote:
> > Gah. Sorry Nick - this message was definitely a case of "fingers before
> > brain. What I meant to say was that I see the "VAC too big!" error on my
> > local copy of *64-bit* Solaris 9 too. I currently don't have access to a
> > Solaris 9 32-bit image for testing, but it sounds as if it is working fine
> > for you which is great.
>
> Actually "VAC too big" is a pretty nice error: it should happen in the
> early sfmmu initialization phase, but for some reason I never get it.
> I tried to make the boot process more verbose, but for this I'd need a
> working kadb. Maybe it's easy to make it working?
> With CIF_DEBUG booting kadb looks like this:
>
> Jumping to entry point 0000000000100000 for type 0000000000000001...
> switching to new context: entry point 0x100000 stack 0x00000000ffe86a01
> finddevice("/chosen") = 0x00000000ffe1bed0
> getproplen(0x00000000ffe1bed0, "mmu") = 0x0000000000000004
> getproplen(0x00000000ffe1bed0, "mmu") = 0x0000000000000004
> getprop(0x00000000ffe1bed0, "mmu", 0x000000000013e02c, 4) = service
> getprop: possible argument error (0 1)
>
> ^^^ The message about possible argument error keeps appearing on every
> call after this point.
> [...]
>
> getprop(0x00000000ffe30940, "clock-frequency", 0x0000000000138608, 4)
> = service getprop: possible argument error (0 1)
> 3990516880
> 0x00138608  05 f5 e1 00 __ __ __ __ __ __ __ __ __ __ __ __  .��.
> getproplen(0x00000000ffe30940, "status") = 0xffffffffffffffff
>
> ^^^ are we missing "status" property?
>
> child(0x00000000ffe30940) = 0x0000000000000000
> peer(0x00000000ffe30940) = 0x0000000000000000
> peer(0x00000000ffe1b838) = 0x0000000000000000
> of_client_interface: interpret 00000000eddac894 0000000000000000
> 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> interpret : kadb_callback   %pc   dup f000.0000 ffff.ffff between if
> drop exit then   h# eddda630  x!  %npc h# eddb0758  x!  %g1 h#
> eddda6d0  x!  %g2 h# eddda6d8  x!  %g3 h# eddda6e0  x!  %g4 h#
> eddda720  x!  %g5 h# eddda728  x!  %g6 h# eddda730  x!  %g7 h#
> eddda738  x!  1 %tstate h# eddaf070  x!  1 %tt h# eddd9e48  l!  h#
> edd008ec   set-pc     go ;  ([6] -- [0])
> %pc:interpret: exception -13 caught
>
> ^^^ I guess things go wrong after this point.
>
> interpret ': kadb_callback   %pc   dup f000.0000 ffff.ffff between if
> drop exit then   h# eddda630  x!  %npc h# eddb0758  x!  %g1 h#
> eddda6d0  x!  %g2 h# eddda6d8  x!  %g3 h# eddda6e0  x!  %g4 h#
> eddda720  x!  %g5 h# eddda728  x!  %g6 h# eddda730  x!  %g7 h#
> eddda738  x!  1 %tstate h# eddaf070  x!  1 %tt h# eddd9e48  l!  h#
> edd008ec   set-pc     go ; ': possible argument error (4--0) got 0
> handle_calls return:
> of_client_interface: interpret 00000000edd28010 0000000000000000
> 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> interpret  ['] kadb_callback init-debugger-hook  ([6] -- [0])
> kadb_callback:interpret: exception -13 caught
> interpret ' ['] kadb_callback init-debugger-hook ': possible argument
> error (4--0) got 0
>
> And then kadb prompt appears but it can't start executing the kernel:
>
> kadb[0]: :c
> of_client_interface: call-method 00000000eddac6e0 00000000ffc847f0
> 0000000001006000
> call-method translate ([3] -- [5])
> handle_calls return: 0000000000000000 ffffffffffffffff
> 0000000000000032 0000000000000000 000000001f806000
> of_client_interface: call-method 00000000eddac668 00000000ffc847f0
> 0000000000000033 0000000000002000 00000000ffc7e000 0000000000000000
> 000000001f806000
> call-method map ([7] -- [1])
> handle_calls return: 0000000000000000
> of_client_interface: call-method 00000000eddac6c8 00000000ffc847f0
> 0000000000002000 00000000ffc7e000
> call-method unmap ([4] -- [0])
> call-method 'unmap': possible argument error (2--0) got 0
> handle_calls return:
> Unhandled Exception 0x000000000000017e
> PC = 0x0000000001006f90 NPC = 0x0000000001006f94
> Stopping execution

Ah this is because of a bug in Solaris whereby it requests too many 
parameters to be returned with respect to the CIF method that is being 
called. The fix is for OpenBIOS to not allow the client to POP() more 
items from the stack than were there before the CIF call, for which I 
have a local patch whilst I wait for the QEMU guys to update their git 
repository from our SVN.

Please try the attached and let me know if you manage to get any further.

ATB,

Mark.