Patch to JFFS2 to run on ARM9

["Philip Keller" <keller at metrolab dot ch>]

Hi,

The attached patch allows JFFS2 to compile and run on an ARM9 processor,
using the eCosCentric-supplied arm-elf toolchain.

I ran into the following problems:

* src/fs-ecos.c: 
Trivial typo in level 2 error message generation. This is not
target-specific.

* src/erase.c:
I ran into a (presumably) target-specific compiler bug here. The structure
"marker", used to mark new nodes, is initialized with the following code:
		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)
		};

The code generated is just plain wrong, at least at optimization level 0. In
creating the initialization value for the structure, it uses the element
.magic for intermediate storage to store .nodetype, with the net effect that
"marker" is initialized as
			.magic =
cpu_to_je16(JFFS2_NODETYPE_CLEANMARKER),
			.nodetype =
cpu_to_je16(JFFS2_NODETYPE_CLEANMARKER),
			.totlen =	cpu_to_je32(c->cleanmarker_size)

Subsequent code fails to recognize the unused node, and then things go to
hell in a hand basket.

I worked around this problem by a simple rewrite:
		struct jffs2_unknown_node 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);
The code is of course equivalent, and I see no negative effects,
legibility-, performance- or otherwise.

Of course one should fix the underlying compiler bug, but that's another can
of worms, which I don't really have the time to tackle right now.

Again, if I'm doing something wrong in the patch-submission process, let me
know.

Sincerely,
-- Philip Keller
   Metrolab Instruments SA

Attachment: jffs2.patch
Description: Binary data