From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O28VN-0000r3-9L for qemu-devel@nongnu.org; Wed, 14 Apr 2010 15:44:09 -0400 Received: from [140.186.70.92] (port=56972 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O28VL-0000q4-IC for qemu-devel@nongnu.org; Wed, 14 Apr 2010 15:44:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O28VH-0005eD-DG for qemu-devel@nongnu.org; Wed, 14 Apr 2010 15:44:07 -0400 Received: from mail-pv0-f173.google.com ([74.125.83.173]:56305) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O28VH-0005dk-3v for qemu-devel@nongnu.org; Wed, 14 Apr 2010 15:44:03 -0400 Received: by pvd12 with SMTP id 12so327696pvd.4 for ; Wed, 14 Apr 2010 12:44:01 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: Date: Wed, 14 Apr 2010 22:44:01 +0300 Message-ID: From: Blue Swirl Content-Type: text/plain; charset=UTF-8 Subject: [Qemu-devel] Re: OBP under qemu-system-sparc64 List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Artyom Tarasenko Cc: qemu-devel On 4/14/10, Artyom Tarasenko wrote: > 2010/4/14 Blue Swirl : > > > On 4/14/10, Artyom Tarasenko wrote: > >> 2010/4/14 Artyom Tarasenko : > >> > >> > 2010/4/3 Blue Swirl : > >> >> 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?).