From: Ross Younger <wry@ecoscentric.com>
To: Andrew Lunn <andrew.lunn@ascom.ch>
Cc: John Dallaway <john@dallaway.org.uk>,
ecos-maintainers@ecos.sourceware.org,
Rutger Hofman <rutger@cs.vu.nl>,
Simon Kallweit <simon.kallweit@intefo.ch>,
Sergei Gavrikov <sergei.gavrikov@gmail.com>
Subject: Re: NAND & YAFFS
Date: Sat, 16 May 2009 12:50:00 -0000 [thread overview]
Message-ID: <4A0EB6C5.3020005@ecoscentric.com> (raw)
In-Reply-To: <20090516104332.GE31991@ma.tech.ascom.ch>
Hi Andrew,
> Im having trouble getting my head around partitions.
>
> If i understand the documentation correctly, the only thing the
> concept does it prevent a buggy filesystem or application reading data
> from a different partition than it "opened" with
> cyg_nand_get_partition(). The partition has zero affect on addressing.
>
> Am i missing something? What else are partitions good for?
Partitions may be a bit of a misleading term for it, but it's the best I
could come up with. It seems quite common for boards (both dev boards, and
deployed products) to have a single NAND device or array, carved up into two
(or more) separate filesystems. As you observe, addressing is completely
unaffected, and this is based on my observations of other devices; I added
in the boundary enforcement purely out of paranoia.
To take the example of the embedded Linux world, typically the primary boot
loader uses the filesystem on the first partition (think of it as "/boot")
to get a kernel or application image, which then uses the second (much
larger) partition as its root filesystem. These two partitions could be the
same filesystem, or the boot partition could be something simpler to
simplify the boot loader.
Also, having the partition information in one place means that filesystems
can read out their limits from it, rather than having to be configured
separately.
Ross
--
eCosCentric Ltd, Barnwell House, Barnwell Drive, Cambridge CB5 8UU, UK
Registered in England no. 4422071. www.ecoscentric.com
next prev parent reply other threads:[~2009-05-16 12:50 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-13 13:59 Ross Younger
2009-05-13 14:22 ` Simon Kallweit
2009-05-13 16:28 ` Sergei Gavrikov
2009-05-13 19:03 ` John Dallaway
2009-05-15 16:50 ` Ross Younger
2009-05-16 10:43 ` Andrew Lunn
2009-05-16 12:50 ` Ross Younger [this message]
2009-05-18 7:13 ` Andrew Lunn
2009-05-18 10:42 ` Rutger Hofman
2009-06-02 18:18 ` John Dallaway
2009-06-03 6:55 ` Andrew Lunn
2009-05-14 18:41 ` Rutger Hofman
2009-05-15 9:48 ` John Dallaway
2009-05-15 9:52 ` Andrew Lunn
2009-05-15 10:18 ` Simon Kallweit
2009-05-16 9:50 ` Andrew Lunn
2009-05-18 9:39 ` Paul Beskeen
2009-05-18 9:55 ` Simon Kallweit
2009-05-15 16:19 ` Paul Beskeen
2009-05-15 6:44 cetoni GmbH - Uwe Kindler
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=4A0EB6C5.3020005@ecoscentric.com \
--to=wry@ecoscentric.com \
--cc=andrew.lunn@ascom.ch \
--cc=ecos-maintainers@ecos.sourceware.org \
--cc=john@dallaway.org.uk \
--cc=rutger@cs.vu.nl \
--cc=sergei.gavrikov@gmail.com \
--cc=simon.kallweit@intefo.ch \
/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).