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