From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9124 invoked by alias); 8 Mar 2006 23:03:39 -0000 Received: (qmail 9116 invoked by uid 22791); 8 Mar 2006 23:03:39 -0000 X-Spam-Check-By: sourceware.org Received: from outbound04.telus.net (HELO priv-edtnes27.telusplanet.net) (199.185.220.223) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 08 Mar 2006 23:03:38 +0000 Received: from [192.168.1.126] (really [154.20.239.41]) by priv-edtnes27.telusplanet.net (InterMail vM.6.01.05.04 201-2131-123-105-20051025) with ESMTP id <20060308230328.CSPZ10411.priv-edtnes27.telusplanet.net@[192.168.1.126]>; Wed, 8 Mar 2006 16:03:28 -0700 From: Newsgroups Reader To: Andrew Lunn Cc: ecos-discuss@ecos.sourceware.org In-Reply-To: <20060308215803.GD19406@lunn.ch> References: <3EDBCCE80E95E744A99895CA464987C4A7D291@dtcsrvr09> <20060308215803.GD19406@lunn.ch> Content-Type: text/plain Date: Wed, 08 Mar 2006 23:03:00 -0000 Message-Id: <1141859007.8185.2.camel@saturn.dsivan.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Subject: Re: [ECOS] JFFS2 on ARM target X-SW-Source: 2006-03/txt/msg00094.txt.bz2 We see the same behaviour with GCC for MIPS. The version is: mipsisa32-elf-gcc (GCC) 3.2.1 (eCosCentric). On Wed, 2006-03-08 at 22:58 +0100, Andrew Lunn wrote: > On Wed, Mar 08, 2006 at 03:08:22PM -0500, Doyle, Patrick wrote: > > I'm confused by something I'm seeing with JFFS2 on my arm target, and I was > > wondering if anybody else had seen anything similar. > > > > Basically, what I see is that when JFFS2 goes through and marks a block as > > being erased, it seems to me that it should be writing 'JFFS2_MAGIC_BITMASK' > > (0x1985) to the marker for the block. What I'm seeing is that 0x2003 gets > > written into the marker field. > > > > Staring at disassembled code for a couple of hours makes me believe that > > this is, in fact, exactly what the opcodes are telling the CPU to do, > > despite what one would expect from looking at the C code. > > > > So now I'm curious... are there known bugs with gcc 3.2.1 for the ARM that > > make it a terrible candidate for processing linux-like code that includes > > constructs such as: > > > > > > struct jffs2_unknown_node marker = { > > .magic = cpu_to_je16(JFFS2_MAGIC_BITMASK), > > .nodetype = cpu_to_je16(JFFS2_NODETYPE_CLEANMARKER), > > .totlen = cpu_to_je32(c->cleanmarker_size) > > }; > > packages/fs/jffs2/current/src/fs-ecos.c:24 > > #if (__GNUC__ == 3) && (__GNUC_MINOR__ == 2) && defined (__ARM_ARCH_4__) > #error This compiler is known to be broken. Please see: > #error http://ecos.sourceware.org/ml/ecos-patches/2003-08/msg00006.html > #endif > > 2003-09-23 Andrew Lunn > > * src/fs-ecos.c: Added test to detect known broken ARM compiler > > Andrew -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss