public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Mark Jackson <mpfj-list@newflow.co.uk>
To: "linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>
Cc: lkml <linux-kernel@vger.kernel.org>
Subject: General question regarding multiple partitions on a single NOR device
Date: Thu, 06 Jun 2013 20:18:09 +0100	[thread overview]
Message-ID: <51B0E071.70909@newflow.co.uk> (raw)

On one of our products, we have 2 64Mbit NOR devices:- one to hold the
kernel, filesystem, etc, and the other to store "user" data.

The gotcha is that the "user" data is stored using our own wear
levelling code, with read / write / erase operations being carried out
on the raw flash device.

We are now designing a new CPU board with a single 1Gbit Spansion NOR
part on it, rather than the 2 separate devices.

I am planning to allocate 512Mbit to the "system" partitions (eg
bootloader, kernel, filesystem) and have the other 512Mbit as the "data"
partition.

Currently our wear levelling code uses mmap() to gain direct access to
the flash chip, which is not an issue, since all filesystem updates etc
are all carried out on the completely separate chip (via jffs2).

What I would like to know is, when the "system" and "user" partitions
reside on the *same" flash device, if I read/write directly to the
"user" partition, how do I maintain the jffs2 integrity on other
"system" partitions that may be doing their own read/write/erase
operations ?

If I can't read/write directly, can the same be achieved using the mtd
character device using something like:-

fd = open("/dev/mtd4", ..);
seek(fd, 1234);
write(fd, buff, ...);
...etc...

If I need to "manually" erase a sector on our custom data partition, how
can that be handled without disrupting any jffs2 flash access on the
other "system" partitions ?

Do the mtd ioctl() functions handle all the flash locking for me ?

Or is this a bit hole I'm digging for myself ?

Thanks for any help anyone can offer.

Regards
Mark J.

                 reply	other threads:[~2013-06-06 19:47 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=51B0E071.70909@newflow.co.uk \
    --to=mpfj-list@newflow.co.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.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