* [Qemu-devel] OBP under qemu-system-sparc64
@ 2010-04-14 15:17 Artyom Tarasenko
2010-04-14 16:15 ` [Qemu-devel] " Artyom Tarasenko
0 siblings, 1 reply; 9+ messages in thread
From: Artyom Tarasenko @ 2010-04-14 15:17 UTC (permalink / raw)
To: Blue Swirl; +Cc: The OpenBIOS Mailinglist, qemu-devel
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)
0x000001fff0000224: add %o2, 4, %o2
0x000001fff0000228: lduba [ %o2 ] (21), %o1
0x000001fff000022c: sllx %o1, 8, %o0
0x000001fff0000230: inc %o2
0x000001fff0000234: lduba [ %o2 ] (21), %o1
0x000001fff0000238: or %o0, %o1, %o0
0x000001fff000023c: sllx %o0, 8, %o0
0x000001fff0000240: inc %o2
0x000001fff0000244: lduba [ %o2 ] (21), %o1
0x000001fff0000248: or %o0, %o1, %o0
0x000001fff000024c: sllx %o0, 8, %o0
0x000001fff0000250: inc %o2
0x000001fff0000254: lduba [ %o2 ] (21), %o1
0x000001fff0000258: or %o0, %o1, %o0
0x000001fff000025c: retl
0x000001fff0000260: nop
qemu: fatal: Trap 0x0032 while trap level (5) >= MAXTL (5), Error state
pc: 000001fff0000220 npc: 000001fff0000224
General Registers:
%g0-3: 0000000000000000 0000000000000007 0000000000000000 0000000000000000
%g4-7: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
Current Register Window:
%o0-3: 0000000000000000 000001ff00000000 000001fff1300000 0000000000000000
%o4-7: 0000000000000000 0000000000000000 0000000000000000 000001fff0001d94
%l0-3: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
%l4-7: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
%i0-3: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
%i4-7: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
Floating Point Registers:
%f00: 000000000.000000 000000000.000000 000000000.000000 000000000.000000
%f04: 000000000.000000 000000000.000000 000000000.000000 000000000.000000
%f08: 000000000.000000 000000000.000000 000000000.000000 000000000.000000
%f12: 000000000.000000 000000000.000000 000000000.000000 000000000.000000
%f16: 000000000.000000 000000000.000000 000000000.000000 000000000.000000
%f20: 000000000.000000 000000000.000000 000000000.000000 000000000.000000
%f24: 000000000.000000 000000000.000000 000000000.000000 000000000.000000
%f28: 000000000.000000 000000000.000000 000000000.000000 000000000.000000
%f32: 000000000.000000 000000000.000000 000000000.000000 000000000.000000
%f36: 000000000.000000 000000000.000000 000000000.000000 000000000.000000
%f40: 000000000.000000 000000000.000000 000000000.000000 000000000.000000
%f44: 000000000.000000 000000000.000000 000000000.000000 000000000.000000
%f48: 000000000.000000 000000000.000000 000000000.000000 000000000.000000
%f52: 000000000.000000 000000000.000000 000000000.000000 000000000.000000
%f56: 000000000.000000 000000000.000000 000000000.000000 000000000.000000
%f60: 000000000.000000 000000000.000000 000000000.000000 000000000.000000
pstate: 00000035 ccr: 00 (icc: ---- xcc: ----) asi: 00 tl: 5 pil: 0
cansave: 0 canrestore: 0 otherwin: 0 wstate: 0 cleanwin: 0 cwp: 7
fsr: 0000000000000000 y: 0000000000000000 fprs: 0000000000000000
Just in case, the properties of the real machine:
ok cd /
ok .properties
breakpoint-trap 0000007f
#size-cells 00000002
energystar-v2
model SUNW,501-2486
name SUNW,Ultra-1
clock-frequency 04f9f54d
banner-name Sun Ultra 1 UPA/SBus (UltraSPARC 167MHz)
device_type upa
ok cd /SUNW,UltraSPARC
ok .properties
manufacturer# 00 00 00 17
implementation# 00 00 00 10
mask# 00 00 00 40
sparc-version 00 00 00 09
ecache-associativity 00 00 00 01
ecache-line-size 00 00 00 40
ecache-size 00 08 00 00
#dtlb-entries 00 00 00 40
dcache-associativity 00 00 00 01
dcache-line-size 00 00 00 20
dcache-size 00 00 40 00
#itlb-entries 00 00 00 40
icache-associativity 00 00 00 02
icache-line-size 00 00 00 20
icache-size 00 00 40 00
upa-portid 00000000
clock-frequency 09f3ea9a
reg 000001c0 00000000 00000000 00000008
device_type cpu
name SUNW,UltraSPARC
--
Regards,
Artyom Tarasenko
solaris/sparc under qemu blog: http://tyom.blogspot.com/
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Qemu-devel] Re: OBP under qemu-system-sparc64
2010-04-14 15:17 [Qemu-devel] OBP under qemu-system-sparc64 Artyom Tarasenko
@ 2010-04-14 16:15 ` Artyom Tarasenko
2010-04-14 18:38 ` Blue Swirl
0 siblings, 1 reply; 9+ messages in thread
From: Artyom Tarasenko @ 2010-04-14 16:15 UTC (permalink / raw)
To: Blue Swirl; +Cc: The OpenBIOS Mailinglist, qemu-devel
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
#### skip unassigned mem access to 000001fff1900000
#### skip unassigned mem access to 000001fff1100004
#### skip unassigned mem access to 000001fff1100004
#### skip unassigned mem access to 000001fff1100000
#### skip unassigned mem access to 000001fff1300007
#### skip unassigned mem access to 000001fff1200001
then it hangs. If I don't do it for the last one (1fff1200001) then qemu says
Aborted.
Since it's qemu issue, I won't post the further results on the
OpenBIOS mailing list. qemu-devel should be enough.
> 0x000001fff0000224: add %o2, 4, %o2
> 0x000001fff0000228: lduba [ %o2 ] (21), %o1
> 0x000001fff000022c: sllx %o1, 8, %o0
> 0x000001fff0000230: inc %o2
> 0x000001fff0000234: lduba [ %o2 ] (21), %o1
> 0x000001fff0000238: or %o0, %o1, %o0
> 0x000001fff000023c: sllx %o0, 8, %o0
> 0x000001fff0000240: inc %o2
> 0x000001fff0000244: lduba [ %o2 ] (21), %o1
> 0x000001fff0000248: or %o0, %o1, %o0
> 0x000001fff000024c: sllx %o0, 8, %o0
> 0x000001fff0000250: inc %o2
> 0x000001fff0000254: lduba [ %o2 ] (21), %o1
> 0x000001fff0000258: or %o0, %o1, %o0
> 0x000001fff000025c: retl
> 0x000001fff0000260: nop
>
> qemu: fatal: Trap 0x0032 while trap level (5) >= MAXTL (5), Error state
> pc: 000001fff0000220 npc: 000001fff0000224
>
> General Registers:
> %g0-3: 0000000000000000 0000000000000007 0000000000000000 0000000000000000
> %g4-7: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
>
> Current Register Window:
> %o0-3: 0000000000000000 000001ff00000000 000001fff1300000 0000000000000000
> %o4-7: 0000000000000000 0000000000000000 0000000000000000 000001fff0001d94
> %l0-3: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> %l4-7: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> %i0-3: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> %i4-7: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
>
> Floating Point Registers:
> %f00: 000000000.000000 000000000.000000 000000000.000000 000000000.000000
> %f04: 000000000.000000 000000000.000000 000000000.000000 000000000.000000
> %f08: 000000000.000000 000000000.000000 000000000.000000 000000000.000000
> %f12: 000000000.000000 000000000.000000 000000000.000000 000000000.000000
> %f16: 000000000.000000 000000000.000000 000000000.000000 000000000.000000
> %f20: 000000000.000000 000000000.000000 000000000.000000 000000000.000000
> %f24: 000000000.000000 000000000.000000 000000000.000000 000000000.000000
> %f28: 000000000.000000 000000000.000000 000000000.000000 000000000.000000
> %f32: 000000000.000000 000000000.000000 000000000.000000 000000000.000000
> %f36: 000000000.000000 000000000.000000 000000000.000000 000000000.000000
> %f40: 000000000.000000 000000000.000000 000000000.000000 000000000.000000
> %f44: 000000000.000000 000000000.000000 000000000.000000 000000000.000000
> %f48: 000000000.000000 000000000.000000 000000000.000000 000000000.000000
> %f52: 000000000.000000 000000000.000000 000000000.000000 000000000.000000
> %f56: 000000000.000000 000000000.000000 000000000.000000 000000000.000000
> %f60: 000000000.000000 000000000.000000 000000000.000000 000000000.000000
> pstate: 00000035 ccr: 00 (icc: ---- xcc: ----) asi: 00 tl: 5 pil: 0
> cansave: 0 canrestore: 0 otherwin: 0 wstate: 0 cleanwin: 0 cwp: 7
> fsr: 0000000000000000 y: 0000000000000000 fprs: 0000000000000000
>
>
> Just in case, the properties of the real machine:
> ok cd /
> ok .properties
> breakpoint-trap 0000007f
> #size-cells 00000002
> energystar-v2
> model SUNW,501-2486
> name SUNW,Ultra-1
> clock-frequency 04f9f54d
> banner-name Sun Ultra 1 UPA/SBus (UltraSPARC 167MHz)
> device_type upa
>
> ok cd /SUNW,UltraSPARC
> ok .properties
> manufacturer# 00 00 00 17
> implementation# 00 00 00 10
> mask# 00 00 00 40
> sparc-version 00 00 00 09
> ecache-associativity 00 00 00 01
> ecache-line-size 00 00 00 40
> ecache-size 00 08 00 00
> #dtlb-entries 00 00 00 40
> dcache-associativity 00 00 00 01
> dcache-line-size 00 00 00 20
> dcache-size 00 00 40 00
> #itlb-entries 00 00 00 40
> icache-associativity 00 00 00 02
> icache-line-size 00 00 00 20
> icache-size 00 00 40 00
> upa-portid 00000000
> clock-frequency 09f3ea9a
> reg 000001c0 00000000 00000000 00000008
> device_type cpu
> name SUNW,UltraSPARC
--
Regards,
Artyom Tarasenko
solaris/sparc under qemu blog: http://tyom.blogspot.com/
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Qemu-devel] Re: OBP under qemu-system-sparc64
2010-04-14 16:15 ` [Qemu-devel] " Artyom Tarasenko
@ 2010-04-14 18:38 ` Blue Swirl
2010-04-14 19:30 ` Artyom Tarasenko
0 siblings, 1 reply; 9+ messages in thread
From: Blue Swirl @ 2010-04-14 18:38 UTC (permalink / raw)
To: Artyom Tarasenko; +Cc: qemu-devel
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'
> #### 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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Qemu-devel] Re: OBP under qemu-system-sparc64
2010-04-14 18:38 ` Blue Swirl
@ 2010-04-14 19:30 ` Artyom Tarasenko
2010-04-14 19:44 ` Blue Swirl
0 siblings, 1 reply; 9+ messages in thread
From: Artyom Tarasenko @ 2010-04-14 19:30 UTC (permalink / raw)
To: Blue Swirl; +Cc: qemu-devel
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+
>> #### 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?
--
Regards,
Artyom Tarasenko
solaris/sparc under qemu blog: http://tyom.blogspot.com/
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Qemu-devel] Re: OBP under qemu-system-sparc64
2010-04-14 19:30 ` Artyom Tarasenko
@ 2010-04-14 19:44 ` Blue Swirl
2010-04-14 20:33 ` Artyom Tarasenko
0 siblings, 1 reply; 9+ messages in thread
From: Blue Swirl @ 2010-04-14 19:44 UTC (permalink / raw)
To: Artyom Tarasenko; +Cc: qemu-devel
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?).
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Qemu-devel] Re: OBP under qemu-system-sparc64
2010-04-14 19:44 ` Blue Swirl
@ 2010-04-14 20:33 ` Artyom Tarasenko
2010-04-21 21:53 ` Artyom Tarasenko
0 siblings, 1 reply; 9+ messages in thread
From: Artyom Tarasenko @ 2010-04-14 20:33 UTC (permalink / raw)
To: Blue Swirl; +Cc: qemu-devel
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/
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Qemu-devel] Re: OBP under qemu-system-sparc64
2010-04-14 20:33 ` Artyom Tarasenko
@ 2010-04-21 21:53 ` Artyom Tarasenko
2010-04-28 19:56 ` Artyom Tarasenko
0 siblings, 1 reply; 9+ messages in thread
From: Artyom Tarasenko @ 2010-04-21 21:53 UTC (permalink / raw)
To: Blue Swirl; +Cc: qemu-devel
What is actually the closest sun4u model that qemu emulates?
Since it's a pci one I gave Ultra-5's OBP a shot, but it also dies
before the serial console is initialized:
$ sparc64-softmmu/qemu-system-sparc64 -bios
/home/tyom/sparc/prom/u5_v3.19.4.bin -nographic -d in_asm,int,cpu
#### skip unassigned mem access to 000001fff1000010
#### skip unassigned mem access to 000001fff1000014
#### skip unassigned mem access to 000001fff1710000
#### skip unassigned mem access to 000001fff1710004
#### skip unassigned mem access to 000001fff1710008
#### skip unassigned mem access to 000001fff1300398
#### skip unassigned mem access to 000001fff130015c
#### skip unassigned mem access to 000001fff130002e
<hang>
--
Regards,
Artyom Tarasenko
solaris/sparc under qemu blog: http://tyom.blogspot.com/
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Qemu-devel] Re: OBP under qemu-system-sparc64
2010-04-21 21:53 ` Artyom Tarasenko
@ 2010-04-28 19:56 ` Artyom Tarasenko
2010-04-28 20:10 ` Blue Swirl
0 siblings, 1 reply; 9+ messages in thread
From: Artyom Tarasenko @ 2010-04-28 19:56 UTC (permalink / raw)
To: Blue Swirl; +Cc: qemu-devel
2010/4/21 Artyom Tarasenko <atar4qemu@googlemail.com>:
> What is actually the closest sun4u model that qemu emulates?
I'll put it the other way round then:
Does qemu sun4u have anything in common with any real sun4u machine?
Like PCI/EBUS/Serial addr?
> Since it's a pci one I gave Ultra-5's OBP a shot, but it also dies
> before the serial console is initialized:
>
> $ sparc64-softmmu/qemu-system-sparc64 -bios
> /home/tyom/sparc/prom/u5_v3.19.4.bin -nographic -d in_asm,int,cpu
> #### skip unassigned mem access to 000001fff1000010
> #### skip unassigned mem access to 000001fff1000014
> #### skip unassigned mem access to 000001fff1710000
> #### skip unassigned mem access to 000001fff1710004
> #### skip unassigned mem access to 000001fff1710008
> #### skip unassigned mem access to 000001fff1300398
> #### skip unassigned mem access to 000001fff130015c
> #### skip unassigned mem access to 000001fff130002e
> <hang>
--
Regards,
Artyom Tarasenko
solaris/sparc under qemu blog: http://tyom.blogspot.com/
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Qemu-devel] Re: OBP under qemu-system-sparc64
2010-04-28 19:56 ` Artyom Tarasenko
@ 2010-04-28 20:10 ` Blue Swirl
0 siblings, 0 replies; 9+ messages in thread
From: Blue Swirl @ 2010-04-28 20:10 UTC (permalink / raw)
To: Artyom Tarasenko; +Cc: qemu-devel
On 4/28/10, Artyom Tarasenko <atar4qemu@googlemail.com> wrote:
> 2010/4/21 Artyom Tarasenko <atar4qemu@googlemail.com>:
>
> > What is actually the closest sun4u model that qemu emulates?
At least Ultra-5 and Netra-T1.
> I'll put it the other way round then:
> Does qemu sun4u have anything in common with any real sun4u machine?
> Like PCI/EBUS/Serial addr?
Not exactly, for example EBUS should be behind one of the PCI bridges.
I haven't moved it there, because PCI probing in OpenBIOS does not
handle that case yet. It's also a bit unclear to me whether the PCI
bridges work correctly in QEMU.
> > Since it's a pci one I gave Ultra-5's OBP a shot, but it also dies
> > before the serial console is initialized:
> >
> > $ sparc64-softmmu/qemu-system-sparc64 -bios
> > /home/tyom/sparc/prom/u5_v3.19.4.bin -nographic -d in_asm,int,cpu
> > #### skip unassigned mem access to 000001fff1000010
> > #### skip unassigned mem access to 000001fff1000014
> > #### skip unassigned mem access to 000001fff1710000
> > #### skip unassigned mem access to 000001fff1710004
> > #### skip unassigned mem access to 000001fff1710008
> > #### skip unassigned mem access to 000001fff1300398
> > #### skip unassigned mem access to 000001fff130015c
> > #### skip unassigned mem access to 000001fff130002e
> > <hang>
>
>
> --
> Regards,
> Artyom Tarasenko
>
> solaris/sparc under qemu blog: http://tyom.blogspot.com/
>
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2010-04-28 20:10 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-04-14 15:17 [Qemu-devel] OBP under qemu-system-sparc64 Artyom Tarasenko
2010-04-14 16:15 ` [Qemu-devel] " Artyom Tarasenko
2010-04-14 18:38 ` Blue Swirl
2010-04-14 19:30 ` Artyom Tarasenko
2010-04-14 19:44 ` Blue Swirl
2010-04-14 20:33 ` Artyom Tarasenko
2010-04-21 21:53 ` Artyom Tarasenko
2010-04-28 19:56 ` Artyom Tarasenko
2010-04-28 20:10 ` Blue Swirl
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.