[Qemu-devel] Re: OBP under qemu-system-sparc64

[Blue Swirl <blauwirbel@gmail.com>]

On 4/14/10, Artyom Tarasenko <atar4qemu@googlemail.com> wrote:
> 2010/4/14 Blue Swirl <blauwirbel@gmail.com>:
>
> > On 4/14/10, Artyom Tarasenko <atar4qemu@googlemail.com> wrote:
>  >> 2010/4/14 Artyom Tarasenko <atar4qemu@googlemail.com>:
>  >>
>  >> > 2010/4/3 Blue Swirl <blauwirbel@gmail.com>:
>  >>  >> could be interesting to see what OBP
>  >>  >> from a real machine would think of the QEMU machine.
>  >>  >
>  >>  > it doesn't live long enough to think something (must be something trivial):
>  >>  >
>  >>  > $ sparc64-softmmu/qemu-system-sparc64 -bios u1_v3.11.1.bin -nographic
>  >>  > -cpu 'TI UltraSparc I' -d in_asm,int,cpu
>  >>  > --------------
>  >>  > IN:
>  >>  > 0x000001fff0000020:  ldxa  [ %g0 ] (69), %g2
>  >>  > 0x000001fff0000024:  stxa  %g0, [ %g0 ] (69)
>  >>  > 0x000001fff0000028:  b,a   0x1fff0001d88
>  >>  >
>  >>  > --------------
>  >>  > IN:
>  >>  > 0x000001fff0001d88:  rdpr  %cwp, %g1
>  >>  > 0x000001fff0001d8c:  wrpr  0, %cwp
>  >>  > 0x000001fff0001d90:  wrpr  %g1, 0, %cwp
>  >>  > 0x000001fff0001d94:  call  0x1fff0000210
>  >>  > 0x000001fff0001d98:  add  %g0, %g0, %o0
>  >>  >
>  >>  > --------------
>  >>  > IN:
>  >>  > 0x000001fff0000210:  mov  0x1ff, %o1    ! 0x1ff
>  >>  > 0x000001fff0000214:  sllx  %o1, 0x20, %o1
>  >>  > 0x000001fff0000218:  sethi  %hi(0xf1300000), %o2
>  >>  > 0x000001fff000021c:  or  %o2, %o1, %o2
>  >>  > 0x000001fff0000220:  stba  %o0, [ %o2 ] (21)
>  >>
>  >>
>  >> and on the real machine there seems to be some device connected to this address:
>  >>  ok 1fff1300000 bypass-asi spacel@ .
>  >>  Data Access Error
>  >>  ok cpu-afsr@ .
>  >>  104000000
>  >>  ok 1fff1300000 bypass-asi spacel@ .
>  >>  Data Access Error
>  >>  ok cpu-afar@ . cpu-afsr@ .
>  >>  1fff1300000 104000000
>  >>  But, with single bytes it works:
>  >>  ok 1fff1300000 bypass-asi spacec@ .
>  >>  64
>  >>  ok 1fff1300001 bypass-asi spacec@ .
>  >>  64
>  >>  ok 1fff1300002 bypass-asi spacec@ .
>  >>  64
>  >>  ok 1fff1300003 bypass-asi spacec@ .
>  >>  64
>  >>
>  >>  If I put pseudodevices there it still doesn't get too far:
>  >>  #### skip unassigned mem access to 000001fff1300000
>  >>  #### skip unassigned mem access to 000001fff1300004
>  >>  #### skip unassigned mem access to 000001fff1300005
>  >>  #### skip unassigned mem access to 000001fff1300006
>  >>  #### skip unassigned mem access to 000001fff1300007
>  >
>  > It's this device:
>  >            model:  'SUNW,sc-up'
>  >            reg:  0000000f.01300000.00000008
>  >            name:  'sc'
>
>
> thought about it, but it says xx08, and OBP tries xx00+

No, the third value is length. The second value is an offset to the
parent range. The first value is a selector from parent device
'ranges' property which in this case has these values (slightly
formatted):
00000000.00000000.000001ff.00000000.10000000.
00000001.00000000.000001ff.10000000.10000000.
00000002.00000000.000001ff.20000000.10000000.
00000003.00000000.000001ff.30000000.10000000.
0000000d.00000000.000001ff.d0000000.10000000.
0000000e.00000000.000001ff.e0000000.10000000.
0000000f.00000000.000001ff.f0000000.10000000

The last one (0xf) gives a range of 0x1fff0000000 to 0x1fffffffffff.

>  >>  #### skip unassigned mem access to 000001fff1900000
>  >
>  >            address:  fffb6000
>  >            reg:  0000000f.01900000.00000001
>  >            name:  'auxio'
>  >
>  >>  #### skip unassigned mem access to 000001fff1100004
>  >
>  >            device_type:  'serial'
>  >            reg:  0000000f.01100000.00000004
>  >            name:  'zs'
>  >
>  >>  #### skip unassigned mem access to 000001fff1100004
>  >>  #### skip unassigned mem access to 000001fff1100000
>  >>  #### skip unassigned mem access to 000001fff1300007
>  >>  #### skip unassigned mem access to 000001fff1200001
>  >
>  >            reg:  0000000f.01200000.00002000
>  >            model:  'mk48t59'
>  >            name:  'eeprom'
>  >
>  > Zilog serial (escc) and m48t59 are already implemented.
>
>
> Yes, but I thought they are also already wired.
>  I'll create one more hwdef entry then.
>
>  On the other hand I see
>  .console_serial_base = 0
>  . Do we want to keep this setting? How does it work under OpenBIOS?

It's for the Niagara machine, which uses a PC-style serial port.
OpenBIOS does not support that machine type (yet?).