public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
From: "Doyle, Patrick" <WPD@dtccom.com>
To: ecos-discuss@ecos.sourceware.org
Subject: [ECOS] JFFS2 on ARM target
Date: Wed, 08 Mar 2006 20:00:00 -0000	[thread overview]
Message-ID: <3EDBCCE80E95E744A99895CA464987C4A7D291@dtcsrvr09> (raw)

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

             reply	other threads:[~2006-03-08 20:00 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-03-08 20:00 Doyle, Patrick [this message]
2006-03-08 21:58 ` Andrew Lunn
2006-03-08 23:03   ` Newsgroups Reader
2006-03-09 16:18 Doyle, Patrick
2006-03-09 20:42 ` Andrew Lunn
2006-06-20 14:35   ` Jürgen Lambrecht
2006-03-09 20:11 Doyle, Patrick
2006-03-09 20:39 ` Andrew Lunn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3EDBCCE80E95E744A99895CA464987C4A7D291@dtcsrvr09 \
    --to=wpd@dtccom.com \
    --cc=ecos-discuss@ecos.sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).