RE: [ECOS] JFFS2 on ARM target

RE: [ECOS] JFFS2 on ARM target

[Doyle, Patrick]

> -----Original Message-----
> From: Andrew Lunn [mailto:andrew@lunn.ch] 
> Sent: Wednesday, March 08, 2006 4:58 PM
> To: Doyle, Patrick
> Cc: ecos-discuss@ecos.sourceware.org
> Subject: Re: [ECOS] JFFS2 on ARM target
> 
> 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  <andrew.lunn@ascom.ch>
> 
>         * src/fs-ecos.c: Added test to detect known broken 
> ARM compiler
> 
>         Andrew
> 
Thanks Andrew,
I'll look at mtd distribution, see if it includes Øyvind's patch, and figure
out what to do next based on what I find there.  In the mean time,
experimental evidence suggests that the 'defined(__ARM_ARCH_4__)' should be
'defined(__ARM_ARCH_4T_)' in fs-ecos.c.  At least on my system, which
compiles fs-ecos.c with the following command:

arm-elf-gcc -c  -I/home/wpd/ess/redboot/dbw-redboot-ram/install/include
-I/home/wpd/eCos/ecos-20060228/packages/fs/jffs2/current
-I/home/wpd/eCos/ecos-20060228/packages/fs/jffs2/current/src
-I/home/wpd/eCos/ecos-20060228/packages/fs/jffs2/current/tests -I.
-I/home/wpd/eCos/ecos-20060228/packages/fs/jffs2/current/src/
-finline-limit=7000 -mcpu=arm9 -Wall -Wpointer-arith -Wstrict-prototypes
-Winline -Wundef  -g -O2 -ffunction-sections -fdata-sections
-fno-exceptions   -D__ECOS -nostdinc -iwithprefix include
-Wp,-MD,src/fs-ecos.tmp -o src/fs_jffs2_fs-ecos.o
/home/wpd/eCos/ecos-20060228/packages/fs/jffs2/current/src/fs-ecos.c

--wpd

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] JFFS2 on ARM target

[Andrew Lunn]

On Thu, Mar 09, 2006 at 11:27:02AM -0500, Doyle, Patrick wrote:
> > -----Original Message-----
> > From: Andrew Lunn [mailto:andrew@lunn.ch] 
> > Sent: Wednesday, March 08, 2006 4:58 PM
> > To: Doyle, Patrick
> > Cc: ecos-discuss@ecos.sourceware.org
> > Subject: Re: [ECOS] JFFS2 on ARM target
> > 
> > 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  <andrew.lunn@ascom.ch>
> > 
> >         * src/fs-ecos.c: Added test to detect known broken 
> > ARM compiler
> > 
> >         Andrew
> > 
> Thanks Andrew,
> I'll look at mtd distribution, see if it includes ?yvind's patch, and figure
> out what to do next based on what I find there.  In the mean time,
> experimental evidence suggests that the 'defined(__ARM_ARCH_4__)' should be
> 'defined(__ARM_ARCH_4T_)' in fs-ecos.c.  At least on my system, which
> compiles fs-ecos.c with the following command:
> 
> arm-elf-gcc -c  -I/home/wpd/ess/redboot/dbw-redboot-ram/install/include
> -I/home/wpd/eCos/ecos-20060228/packages/fs/jffs2/current
> -I/home/wpd/eCos/ecos-20060228/packages/fs/jffs2/current/src
> -I/home/wpd/eCos/ecos-20060228/packages/fs/jffs2/current/tests -I.
> -I/home/wpd/eCos/ecos-20060228/packages/fs/jffs2/current/src/
> -finline-limit=7000 -mcpu=arm9 -Wall -Wpointer-arith -Wstrict-prototypes
> -Winline -Wundef  -g -O2 -ffunction-sections -fdata-sections
> -fno-exceptions   -D__ECOS -nostdinc -iwithprefix include
> -Wp,-MD,src/fs-ecos.tmp -o src/fs_jffs2_fs-ecos.o
> /home/wpd/eCos/ecos-20060228/packages/fs/jffs2/current/src/fs-ecos.c

Strange, it works for me. I wounder if its becasue you are using arm9?

Please could you give the output when you call gcc with -v. I think
that will show all the defines which are passed to CPP.

        Thanks
                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

Re: [ECOS] JFFS2 on ARM target

[Jürgen Lambrecht]

I had the same problem with JFFS2 on my ARM target, and I also do not get the error message about a broken compiler.
I use an Atmel ARM7 AT91M55800A (on eb55 demo board), an arm7tdmi.
As you request below:

$ arm-elf-gcc -v
Reading specs from /opt/ecos/gnutools/arm-elf/bin/../lib/gcc-lib/arm-elf/3.2.1/specs
Configured with: /local/demonweb/tools/ecos-gnutools-v1.4/r2/arm-elf/cygwin/tar_bz2/source/gcc-3.2.1
/configure --target=arm-elf --prefix=/local/demonweb/tools/ecos-gnutools-v1.4/r2/arm-elf/cygwin/tar_
bz2/opt/ecos/gnutools/arm-elf --enable-languages=c,c++ --with-gnu-as --with-gnu-ld --with-newlib --w
ith-gxx-include-dir=/local/demonweb/tools/ecos-gnutools-v1.4/r2/arm-elf/cygwin/tar_bz2/opt/ecos/gnut
ools/arm-elf/arm-elf/include
Thread model: single
gcc version 3.2.1

with ' arm-elf-gcc -dumpspecs', I get amongs others this output:

*cpp_cpu_arch:
-Acpu=arm -Amachine=arm %{march=arm2:-D__ARM_ARCH_2__} %{march=arm250:-D__ARM_ARCH_2__} %{march=arm3
:-D__ARM_ARCH_2__} %{march=arm6:-D__ARM_ARCH_3__} %{march=arm600:-D__ARM_ARCH_3__} %{march=arm610:-D
__ARM_ARCH_3__} %{march=arm7:-D__ARM_ARCH_3__} %{march=arm700:-D__ARM_ARCH_3__} %{march=arm710:-D__A
RM_ARCH_3__} %{march=arm720:-D__ARM_ARCH_3__} %{march=arm7100:-D__ARM_ARCH_3__} %{march=arm7500:-D__
ARM_ARCH_3__} %{march=arm7500fe:-D__ARM_ARCH_3__} %{march=arm7m:-D__ARM_ARCH_3M__} %{march=arm7dm:-D
__ARM_ARCH_3M__} %{march=arm7dmi:-D__ARM_ARCH_3M__} %{march=arm7tdmi:-D__ARM_ARCH_4T__} %{march=arm8
:-D__ARM_ARCH_4__} %{march=arm810:-D__ARM_ARCH_4__} %{march=arm9:-D__ARM_ARCH_4T__} %{march=arm920:-
D__ARM_ARCH_4__} %{march=arm920t:-D__ARM_ARCH_4T__} %{march=arm9tdmi:-D__ARM_ARCH_4T__} %{march=stro
ngarm:-D__ARM_ARCH_4__} %{march=strongarm110:-D__ARM_ARCH_4__} %{march=strongarm1100:-D__ARM_ARCH_4_
_} %{march=xscale:-D__ARM_ARCH_5TE__} %{march=xscale:-D__XSCALE__} %{march=armv2:-D__ARM_ARCH_2__} %
{march=armv2a:-D__ARM_ARCH_2__} %{march=armv3:-D__ARM_ARCH_3__} %{march=armv3m:-D__ARM_ARCH_3M__} %{
march=armv4:-D__ARM_ARCH_4__} %{march=armv4t:-D__ARM_ARCH_4T__} %{march=armv5:-D__ARM_ARCH_5__} %{ma
rch=armv5t:-D__ARM_ARCH_5T__} %{march=armv5e:-D__ARM_ARCH_5E__} %{march=armv5te:-D__ARM_ARCH_5TE__}
%{!march=*:  %{mcpu=arm2:-D__ARM_ARCH_2__}  %{mcpu=arm250:-D__ARM_ARCH_2__}  %{mcpu=arm3:-D__ARM_ARC
H_2__}  %{mcpu=arm6:-D__ARM_ARCH_3__}  %{mcpu=arm600:-D__ARM_ARCH_3__}  %{mcpu=arm610:-D__ARM_ARCH_3
__}  %{mcpu=arm7:-D__ARM_ARCH_3__}  %{mcpu=arm700:-D__ARM_ARCH_3__}  %{mcpu=arm710:-D__ARM_ARCH_3__}
   %{mcpu=arm720:-D__ARM_ARCH_3__}  %{mcpu=arm7100:-D__ARM_ARCH_3__}  %{mcpu=arm7500:-D__ARM_ARCH_3__
}  %{mcpu=arm7500fe:-D__ARM_ARCH_3__}  %{mcpu=arm7m:-D__ARM_ARCH_3M__}  %{mcpu=arm7dm:-D__ARM_ARCH_3
M__}  %{mcpu=arm7dmi:-D__ARM_ARCH_3M__}  %{mcpu=arm7tdmi:-D__ARM_ARCH_4T__}  %{mcpu=arm8:-D__ARM_ARC
H_4__}  %{mcpu=arm810:-D__ARM_ARCH_4__}  %{mcpu=arm9:-D__ARM_ARCH_4T__}  %{mcpu=arm920:-D__ARM_ARCH_
4__}  %{mcpu=arm920t:-D__ARM_ARCH_4T__}  %{mcpu=arm9tdmi:-D__ARM_ARCH_4T__}  %{mcpu=strongarm:-D__AR
M_ARCH_4__}  %{mcpu=strongarm110:-D__ARM_ARCH_4__}  %{mcpu=strongarm1100:-D__ARM_ARCH_4__}  %{mcpu=x
scale:-D__ARM_ARCH_5TE__}  %{mcpu=xscale:-D__XSCALE__}  %{!mcpu*:%(cpp_cpu_arch_default)}}

*cpp_cpu_arch_default:
-D__ARM_ARCH_4T__


Kind regards,
Jürgen Lambrecht


Andrew Lunn wrote:
> On Thu, Mar 09, 2006 at 11:27:02AM -0500, Doyle, Patrick wrote:
> 
>>>-----Original Message-----
>>>From: Andrew Lunn [mailto:andrew@lunn.ch] 
>>>Sent: Wednesday, March 08, 2006 4:58 PM
>>>To: Doyle, Patrick
>>>Cc: ecos-discuss@ecos.sourceware.org
>>>Subject: Re: [ECOS] JFFS2 on ARM target
>>>
>>>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  <andrew.lunn@ascom.ch>
>>>
>>>        * src/fs-ecos.c: Added test to detect known broken 
>>>ARM compiler
>>>
>>>        Andrew
>>>
>>
>>Thanks Andrew,
>>I'll look at mtd distribution, see if it includes ?yvind's patch, and figure
>>out what to do next based on what I find there.  In the mean time,
>>experimental evidence suggests that the 'defined(__ARM_ARCH_4__)' should be
>>'defined(__ARM_ARCH_4T_)' in fs-ecos.c.  At least on my system, which
>>compiles fs-ecos.c with the following command:
>>
>>arm-elf-gcc -c  -I/home/wpd/ess/redboot/dbw-redboot-ram/install/include
>>-I/home/wpd/eCos/ecos-20060228/packages/fs/jffs2/current
>>-I/home/wpd/eCos/ecos-20060228/packages/fs/jffs2/current/src
>>-I/home/wpd/eCos/ecos-20060228/packages/fs/jffs2/current/tests -I.
>>-I/home/wpd/eCos/ecos-20060228/packages/fs/jffs2/current/src/
>>-finline-limit=7000 -mcpu=arm9 -Wall -Wpointer-arith -Wstrict-prototypes
>>-Winline -Wundef  -g -O2 -ffunction-sections -fdata-sections
>>-fno-exceptions   -D__ECOS -nostdinc -iwithprefix include
>>-Wp,-MD,src/fs-ecos.tmp -o src/fs_jffs2_fs-ecos.o
>>/home/wpd/eCos/ecos-20060228/packages/fs/jffs2/current/src/fs-ecos.c
> 
> 
> Strange, it works for me. I wounder if its becasue you are using arm9?
> 
> Please could you give the output when you call gcc with -v. I think
> that will show all the defines which are passed to CPP.
> 
>         Thanks
>                 Andrew
> 

-- 
Jürgen Lambrecht
Diksmuidse Heerweg 338
8200 Sint-Andries
Tel: +32 (0)50 842901
GSM: +32 (0)476 313389

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] JFFS2 on ARM target

[Andrew Lunn]

On Thu, Mar 09, 2006 at 03:19:08PM -0500, Doyle, Patrick wrote:
> Hello again Andrew,
> 
> OK, I've poked around a bit...
> 
> What I've seen is that the jffs2 tree has migrated a bit since it was
> imported into the eCos tree.  The other thing I've seen is an "ecos"
> directory which has your fingerprints all over it :-)

Yes, but not for a while. As you said, the jffs2 tree has moved on
quite a lot. I've no idea if it will compile inside eCos any more.

> I'm not in a position right now to upgrade eCos to the latest jffs2, so what
> I would like to do is to submit ?yvind's patch (suitably updated to reflect
> the latest changes in jffs2) to the jffs2 maintainer while simultaneously
> submitting the same patch (suitably not updated) for integration into eCos.

I expect it will be reject. It was when Oyvind submitted the
patch. There response was something like: Gcc is broken, fix gcc.

        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

RE: [ECOS] JFFS2 on ARM target

[Doyle, Patrick]

[-- Attachment #1: Type: text/plain, Size: 1894 bytes --]

Hello again Andrew,

OK, I've poked around a bit...

What I've seen is that the jffs2 tree has migrated a bit since it was
imported into the eCos tree.  The other thing I've seen is an "ecos"
directory which has your fingerprints all over it :-)

I'm not in a position right now to upgrade eCos to the latest jffs2, so what
I would like to do is to submit Øyvind's patch (suitably updated to reflect
the latest changes in jffs2) to the jffs2 maintainer while simultaneously
submitting the same patch (suitably not updated) for integration into eCos.

Basically, what I've seen (and what I've seen others see) is that there is a
bug in the gcc-3.2.x ARM compiler when optimizing 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)
};

I was gratified to see Øyvind's patch that looked identical to the one I was
preparing.  I've looked around, and this construct is used in the
"compr_*.c" files to initialize static variables (which should be fine) and
in "erase.c" to initialize an automatic variable (which is not fine).

Before I go bursting into the mtd scene saying, "Would you mind applying
this patch to work around a compiler bug that some folks using eCos are
fighting...", I thought I would check in with you first, since you seem to
be the designated eCos representative.  I have (perhaps) attached both
patches for your review.

On an almost different topic...
This structure also shows up in a few other files I see (well, my perl
script sees) in the eCos tree:

net/ftpclient/current/tests/ftp_var_example.c
devs/eth/phy/current/include/eth_phy.h
devs/spi/arm/at91/current/src/spi_at91.c
devs/spi/arm/eb55/current/src/spi_eb55.c

But these all seem to be static initializers.

--wpd



[-- Attachment #2: mtd.patch --]
[-- Type: application/octet-stream, Size: 1281 bytes --]

Index: fs/jffs2/erase.c
===================================================================
RCS file: /home/cvs/mtd/fs/jffs2/erase.c,v
retrieving revision 1.92
diff -u -r1.92 erase.c
--- fs/jffs2/erase.c	21 Jan 2006 21:50:44 -0000	1.92
+++ fs/jffs2/erase.c	9 Mar 2006 19:54:57 -0000
@@ -388,15 +388,14 @@
 	} else {
 
 		struct kvec vecs[1];
-		struct jffs2_raw_ebh ebh = {
-			.magic =        cpu_to_je16(JFFS2_MAGIC_BITMASK),
-			.nodetype =     cpu_to_je16(JFFS2_NODETYPE_ERASEBLOCK_HEADER),
-			.totlen =       cpu_to_je32(c->ebh_size),
-			.reserved =     0,
-			.compat_fset =  JFFS2_EBH_COMPAT_FSET,
-			.incompat_fset = JFFS2_EBH_INCOMPAT_FSET,
-			.rocompat_fset = JFFS2_EBH_ROCOMPAT_FSET,
-		};
+
+                memset(&marker, 0, sizeof(marker));
+                marker.magic         = cpu_to_je16(JFFS2_MAGIC_BITMASK);
+                marker.nodetype      = cpu_to_je16(JFFS2_NODETYPE_ERASEBLOCK_HEADER);
+                marker.totlen        = cpu_to_je32(c->cleanmarker_size);
+                marker.compat_fset   = JFFS2_EBH_COMPAT_FSET;
+                marker.incompat_fset = JFFS2_EBH_INCOMPAT_FSET;
+                marker.rocompat_fset = JFFS2_EBH_ROCOMPAT_FSET;
 
 		ebh_ref = jffs2_alloc_raw_node_ref();
 		if (!ebh_ref) {

[-- Attachment #3: ecos.patch --]
[-- Type: application/octet-stream, Size: 2642 bytes --]

Index: packages/fs/jffs2/current/ChangeLog
===================================================================
RCS file: /cvs/ecos/ecos/packages/fs/jffs2/current/ChangeLog,v
retrieving revision 1.50
diff -u -r1.50 ChangeLog
--- packages/fs/jffs2/current/ChangeLog	3 Aug 2005 20:39:51 -0000	1.50
+++ packages/fs/jffs2/current/ChangeLog	9 Mar 2006 19:58:56 -0000
@@ -1,3 +1,12 @@
+2006-03-09  Patrick Doyle  <wpd@dtccom.com>
+
+	* src/fs-ecos.c: Removed (nonworking) test for gcc-3.2.x for the
+	arm. 
+
+	* src/erase.c (jffs2_mark_erased_block): Worked around a arm-elf
+	gcc-3.2.x compiler bug by initializing members of a structure
+	explicitly rather than using designated initializers.
+
 2005-08-03  Andrew Lunn  <andrew.lunn@ascom.ch>
 
 	* tests/jffs2_1.c: Include <stdio.h> to stop compiler warning.
Index: packages/fs/jffs2/current/src/erase.c
===================================================================
RCS file: /cvs/ecos/ecos/packages/fs/jffs2/current/src/erase.c,v
retrieving revision 1.10
diff -u -r1.10 erase.c
--- packages/fs/jffs2/current/src/erase.c	30 Jul 2005 15:30:42 -0000	1.10
+++ packages/fs/jffs2/current/src/erase.c	9 Mar 2006 19:58:57 -0000
@@ -382,11 +382,12 @@
 	} else {
 
 		struct kvec vecs[1];
-		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)
-		};
+		struct jffs2_unknown_node marker;
+
+                memset(&marker, 0, sizeof(marker));
+                marker.magic    = cpu_to_je16(JFFS2_MAGIC_BITMASK);
+                marker.nodetype = cpu_to_je16(JFFS2_NODETYPE_CLEANMARKER);
+                marker.totlen   = cpu_to_je32(c->cleanmarker_size);
 
 		marker_ref = jffs2_alloc_raw_node_ref();
 		if (!marker_ref) {
Index: packages/fs/jffs2/current/src/fs-ecos.c
===================================================================
RCS file: /cvs/ecos/ecos/packages/fs/jffs2/current/src/fs-ecos.c,v
retrieving revision 1.38
diff -u -r1.38 fs-ecos.c
--- packages/fs/jffs2/current/src/fs-ecos.c	30 Jul 2005 15:30:42 -0000	1.38
+++ packages/fs/jffs2/current/src/fs-ecos.c	9 Mar 2006 19:58:58 -0000
@@ -21,11 +21,6 @@
 #include <string.h>
 #include <cyg/io/config_keys.h>
 
-#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
-
 //==========================================================================
 // Forward definitions
 


[-- Attachment #4: Type: text/plain, Size: 148 bytes --]

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] JFFS2 on ARM target

[Newsgroups Reader]

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  <andrew.lunn@ascom.ch>
> 
>         * 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

Re: [ECOS] JFFS2 on ARM target

[Andrew Lunn]

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  <andrew.lunn@ascom.ch>

        * 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

[ECOS] JFFS2 on ARM target

[Doyle, Patrick]

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)
};

I've been using 3.2.1 for years without problems, but I've been using it in
eCos to do eCos related stuff.  Since JFFS2 was originally designed for
Linux, it looks more Linux-like than eCos-like.

I notice I've been using 3.4.5 for my Linux builds.

--wpd

Patrick Doyle
Manager, Digital Systems Group
DTC Communications, Inc.
Phone: (603) 546-2179
Fax: (603) 880-6965
Email: wpd@dtccom.com

 

This communication is from DTC Communications, Inc. and is intended to be
confidential and solely for the use of the persons or entities addressed
above.  If you are not an intended recipient, be aware that the information
contained herein may be protected from unauthorized use by privilege or law,
and any copying, distribution, disclosure, or other use of this information
is prohibited.  If you have received this communication in error, please
contact the sender by return e-mail or telephone the above number
immediately and delete or destroy all copies.  Thank you for your
cooperation.

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss