From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DJU6t-0003Gd-Al for qemu-devel@nongnu.org; Thu, 07 Apr 2005 06:19:45 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DJU6r-00039B-8Z for qemu-devel@nongnu.org; Thu, 07 Apr 2005 06:19:37 -0400 Received: from [62.210.158.45] (helo=quito.magic.fr) by monty-python.gnu.org with esmtp (Exim 4.34) id 1DJUVl-0007bs-St for qemu-devel@nongnu.org; Thu, 07 Apr 2005 06:45:22 -0400 Subject: Re: [Qemu-devel] Is Little endian supported by Qemu -prep From: "J. Mayer" In-Reply-To: <4254DB0D.6060509@co.inet.fi> References: <4254DB0D.6060509@co.inet.fi> Content-Type: text/plain Date: Thu, 07 Apr 2005 12:44:39 +0200 Message-Id: <1112870679.28622.96.camel@rapid> Mime-Version: 1.0 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 On Thu, 2005-04-07 at 10:02 +0300, Tero Kaarlela wrote: > Still working on OS/2 PPC edition bootloading. I got patch to ppc_prep.c > from J Mayer to make it support non-continuous I/O map mode. It seemed > to work ok. But catched bug in the further code after line mfspr > r3,1008. I modified ppc_prep.c Processor version from 0x00080000 (g3) > to 0x00040000 (604) and problem was fixed. Now it crashes after code: > > subfic r0,r0,-32690 > mtlr r0 > blr > (LR = ffef7f1e) > r0 was 0x00100130 to begin with > > This error happens shortly after changinfg MSR state from 0x00000030 > to 0x00000031 (change mode from Big-endian to Little endian) So might > Little-endian be reason why LR goes nuts?:) Yes, that's the reason. As far as I know, Qemu has no support for dynamic endian modes. I did not think any OS did use LE mode... Imho, the simple way to handle this is to add a bit in the translation bloc state (flags in cpu-exec.c) and exend the memory access tables (using mem_idx in target-ppc/translate.c) for little-endian case. This is not so hard to do, but as all memory access routines have to be duplicated, it may take some time to do the patch. The great thing doing this way is that little endian mode will be as efficient as BE mode.. I'll take a look during the week end and give you a patch so you may go on testing OS/2. -- J. Mayer Never organized