From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DcOPk-0006EP-W9 for qemu-devel@nongnu.org; Sun, 29 May 2005 10:05:17 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DcOPf-0006BR-W9 for qemu-devel@nongnu.org; Sun, 29 May 2005 10:05:12 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DcOPe-00069d-Vc for qemu-devel@nongnu.org; Sun, 29 May 2005 10:05:11 -0400 Received: from [194.251.242.242] (helo=fep17.inet.fi) by monty-python.gnu.org with esmtp (Exim 4.34) id 1DcONz-0000xR-15 for qemu-devel@nongnu.org; Sun, 29 May 2005 10:03:27 -0400 Received: from co.inet.fi ([80.220.124.133]) by fep17.inet.fi with ESMTP id <20050529140203.QXJ15942.fep17.inet.fi@co.inet.fi> for ; Sun, 29 May 2005 17:02:03 +0300 Message-ID: <4299CB5B.1080006@co.inet.fi> Date: Sun, 29 May 2005 17:02:03 +0300 From: Tero Kaarlela MIME-Version: 1.0 Subject: Re: [Qemu-devel] OS/2 Bootloader Some weird behaviour of branch instruction References: <4294C037.2070509@co.inet.fi> <4294CB13.9080002@co.inet.fi> <1117054631.15980.112.camel@rapid> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org J. Mayer wrote: >On Wed, 2005-05-25 at 21:59 +0300, Tero Kaarlela wrote: > > >>I have just realized that when running in LE mode in_asm dump is not >>useful because it shows code in BE-format. I'll try to make it print in >>LE format. And those invalid opcodes is this because after OS/2 crashes >>Qemu tries to start its own code but crashes because before this >>Processor should be returned to BE-format? >> >> > >It should display insns in little-endian format, if you're up to date. >Take a look at the code in disas.c and ppc-dis.c, you'll see the case is >handled. > > Yes I used out of date binaries(0.6.1 + patches). My mistake sorry. >But the 0x3c opcode is valid ... on POWER2 (namely stfq). >Then I guess you choose a platform which is a RS/6000 with a POWER2, not >a PowerPC. >I'm afraid POWER1 & POWER2 won't be emuled soon, if they'll ever be... >Please check this point. > Bootloader check PVR at very early stage of boot accepted ones are: 601 603 604 If something else is reported bootloader goes to indefiniteve loop. >Another point: > > >> I took a look at qemu in_asm & cpu debugging with OS/2 bootloader >>under Qemu -prep. And there is something weird happening in my opinion: >> >>This happens after boot.cfg has been gone through and kernel bootstrap >>task should start: >> >>IN: >>0xf0107068: .long 0x10009d81 >>0xf010706c: tdi 0,r0,27776 >>0xf0107070: bl F011EDF0 <<= Shouldnt this branch to F011EDF0 >>instead of going on??? >> >> > >As this is a subroutine call, I guess this routine as already been called from somewhere else. >As Qemu only displays blocks at translation time, you don't have any dump any more >when calling a routine twice. > After compiling CVS version lines above look like this: IN: 0xf0107068: lwz r12,16(r29) 0xf010706c: lwz r3,8(r12) 0xf0107070: lwz r11,328(r29) 0xf0107074: cmpwi r11,0 0xf0107078: beq F01070A4 invalid/unsupported opcode: 3c - 16 - 0a (f01072ac) 0x00000300 0 IN: 0x00000300: .long 0xf01072ac invalid/unsupported opcode: 3c - 18 - 1c (f0000730) 0x00000700 0 IN: 0x00000700: .long 0xf0000730 Could this be because OS/2 can't handle this much ram(128mb). OS/2 has always been very specific about maximum memory(ie. versions 1.x can't boot on machines that report more than 16mb ram. this is one of the reasons 1.x versions dont boot under Qemu and thats why many BIOSES have option "boot to OS/2). During 1995 when OS/2 PPC was made 16mb was much and 32mb was huge amount of memory. Tero Kaarlela