From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:37624) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UCuJG-0002cz-1W for qemu-devel@nongnu.org; Tue, 05 Mar 2013 11:01:51 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UCuJ9-0001hl-NQ for qemu-devel@nongnu.org; Tue, 05 Mar 2013 11:01:45 -0500 Received: from mel.act-europe.fr ([194.98.77.210]:43683) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UCtSx-0008U9-A9 for qemu-devel@nongnu.org; Tue, 05 Mar 2013 10:07:43 -0500 Message-ID: <51360A3D.2080302@adacore.com> Date: Tue, 05 Mar 2013 16:07:41 +0100 From: Fabien Chouteau MIME-Version: 1.0 References: <1362158507-19310-1-git-send-email-chouteau@adacore.com> <201303012058.26277.paul@codesourcery.com> <513477C1.5080505@adacore.com> <201303041324.52962.paul@codesourcery.com> <5135CF60.2000606@adacore.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 4/4] target-arm: always set endian bits in big-endian mode List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Paul Brook , afaerber@suse.de, qemu-devel@nongnu.org On 03/05/2013 01:33 PM, Peter Maydell wrote: > On 5 March 2013 18:56, Fabien Chouteau wrote: >> On 03/04/2013 02:24 PM, Paul Brook wrote: >>>> On 03/01/2013 09:58 PM, Paul Brook wrote: >>>>> >>>>> This is wrong for all the CPUs QEMU crrently supports. SCTLR.IE is >>>>> defined to be zero. >>>> >>>> Again I'd like to have more information. Why is it wrong to set IE when >>>> we are in big-endian? > > It's wrong because you're setting IE for all v6 and v7 cores > in bigendian mode, when IE is only valid for R profile cores. > Right, that's something I missed, SCTLR.IE is for R profiles only. > To correctly emulate a bigendian v6/v7 non-R profile core you would > need to arrange for the bswap_code flag to be set (which then causes > us to re-byte-swap code accesses to undo the endianness flip that > TARGET_WORDS_BIGENDIAN would otherwise give us). I suspect that what > you actually want is: > * sctlr bit IE is read-only, and set to 0 or 1 according to the > sctlr reset value defined for the CPU type It's actually more of a board setting. > * the bswap_code flag is set to 1 if TARGET_WORDS_BIGENDIAN && > SCTLR.IE == 0) > but that's just off the top of my head so might be wrong. > If it's that simple (i.e. set the bswap_code flag) I can try to do it, otherwise I'll just pass. My main interest here is cortex-R4. >> Is it possible to have both data and instruction in BE8? > > Yes; this is precisely what SCTLR.IE enables. OK good, that makes sense. >> Since it is a legacy support, I would imagine that SCTLR.IE means BE32 >> access for instructions. Is that right? > > No. It is supporting legacy code; it is not itself a legacy feature. > IE + BE8 (data) looks very very similar to BE32 from the point of view > of code on the CPU; it is code that expects a BE32 kind of view of > the world that is the legacy code being supported. > That's what I fail to understand, why IE + BE8 (data) gives a legacy BE32 view? >>> All the v7 cores QEMU currently supports[1] only implement BE8 mode. The IE >>> bit is reserved and most be zero. Usermode emulation implements both, but the >>> privileged cp15 registers can safely be ignored there. >>> >> >> When I build my qemu-system-armeb, in what mode is it (BE8, BE32, data >> and/or instruction in big-endian)? > > It will effectively behave kind of like a BE32 (word invariant, swaps > both code and data) system; you won't be able to tell the difference > between that and the BE8+SCTLR.IE system you're trying to emulate, > except for accesses to word-width registers on device models. > That needs thought to make sure the changes are actually coherent. > So the current behavior of qemu-system-armeb is BE8+IE, therefore not compatible with any non R profile ARMv6/7. Thanks, -- Fabien Chouteau