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

[Artyom Tarasenko <atar4qemu@googlemail.com>]

2010/4/14 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?).

To me it looks the other way round: Niagra uses .console_serial_base
and the two others use PC-style.
So, OpenBIOS supports PC-style serials?


-- 
Regards,
Artyom Tarasenko

solaris/sparc under qemu blog: http://tyom.blogspot.com/