From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:56441) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UCpY7-0002rH-KZ for qemu-devel@nongnu.org; Tue, 05 Mar 2013 05:56:54 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UCpY5-0001db-Vv for qemu-devel@nongnu.org; Tue, 05 Mar 2013 05:56:47 -0500 Received: from mel.act-europe.fr ([194.98.77.210]:56807) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UCpY5-0001d4-HT for qemu-devel@nongnu.org; Tue, 05 Mar 2013 05:56:45 -0500 Message-ID: <5135CF60.2000606@adacore.com> Date: Tue, 05 Mar 2013 11:56:32 +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> In-Reply-To: <201303041324.52962.paul@codesourcery.com> Content-Type: text/plain; charset=ISO-8859-6 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: Paul Brook Cc: peter.maydell@linaro.org, qemu-devel@nongnu.org, afaerber@suse.de On 03/04/2013 02:24 PM, Paul Brook wrote: >> On 03/01/2013 09:58 PM, Paul Brook wrote: >>>> +#ifdef TARGET_WORDS_BIGENDIAN >>>> + if (arm_feature(env, ARM_FEATURE_V6) >>>> + || arm_feature(env, ARM_FEATURE_V7)) { >>>> + /* IE and EE bits stay set for big-endian */ >>>> + env->cp15.c1_sys |= (1 << 31) | (1 << 25); >>>> + } >>>> +#endif >>> >>> 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? > > The ARM architecture defines two big-endian modes. In BE8 mode only data > accesses big-endian, code fetches are still little-endian. In BE32 mode both > code and data are big-endian. In theory a fourth mode (big-endian code, > little-endian data) exists, though I've never seen that used. > I'm a bit lost. You say that BE32 means data and instruction in big-endian and BE8 only data in big-endian. And this is confirmed by Peter's article : (http://translatedcode.wordpress.com/2012/04/02/this-end-up/). For me there's two different things: - big-endian kind: BE32 or BE8 - endianness of data/instruction Is it possible to have both data and instruction in BE8? Now in the ARMv7 ARM chapter A3.3.2: "Instruction endianness static configuration, ARMv7-R only To provide support for legacy big-endian object code, the ARMv7-R profile supports optional byte order reversal hardware as a static option from reset. The ARMv7-R profile includes a read-only bit in the CP15 Control Register, SCTLR.IE, bit [31]. For more information, see c1, System Control Register (SCTLR) on page B4-45." Since it is a legacy support, I would imagine that SCTLR.IE means BE32 access for instructions. Is that right? > 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)? Thanks, -- Fabien Chouteau