From: Scott Wood <scottwood@freescale.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] U-boot nand bug, read.part should fail
Date: Thu, 7 Feb 2013 16:22:28 -0600 [thread overview]
Message-ID: <1360275748.27002.11@snotra> (raw)
In-Reply-To: <EB954A16-722A-4D9C-8A09-D262849B54ED@3gfp.com> (from hchapman-uboot@3gfp.com on Thu Feb 7 16:13:55 2013)
On 02/07/2013 04:13:55 PM, Harvey Chapman wrote:
> [ I started this conversation off-list before I joined the list. ]
>
> The idea is to add .part as a valid command suffix to nand read/write
> so it would match nand erase.part. The code to implement it makes
> "nand read.part" act identically to "nand read".
>
> On Feb 7, 2013, at 4:59 PM, Scott Wood <scottwood@freescale.com>
> wrote:
>
> >> >> In fact, I think erase should be modified to deprecate
> erase.part and make erase work like read does now.
> >> >
> >> > Erase used to work like read does. I deliberately changed it so
> that typos (e.g. "nand erase $partition $fliesize") don't end up
> erasing your entire partition or chip.
> >> Ah, then maybe we should add .part to nand read for consistency?
> I'm ok either way.
> >
> > That would get messy because it would be orthogonal to other
> suffixes. Reading too much is not as harmful as
>
> Nothing would change other than do_nand() would treat "nand read" and
> "nand read.part" identically.
The only reason to add .part/.chip is if the unsuffixed versions no
longer operate on entire partitions/chips.
> > erasing too much. Writing too much can be bad, though. Perhaps we
> should just eliminate the ability to do reads/writes without explicit
> size (it already has problems with the size needing adjustment due to
> bad blocks).
>
> I liked that I didn't have to specify the size.
It's fine until you get a bad block in the partition, and you end up
accessing the first block of the next partition (or getting "Attempt to
read/write outside the flash area" if it's the last partition).
Of course, fixing partition/chip accesses to account for this when
determining size would be even better. :-)
-Scott
next prev parent reply other threads:[~2013-02-07 22:22 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1360274360.27002.10@snotra>
2013-02-07 22:13 ` [U-Boot] U-boot nand bug, read.part should fail Harvey Chapman
2013-02-07 22:22 ` Scott Wood [this message]
2013-02-08 15:48 ` Harvey Chapman
2013-02-08 16:44 ` Harvey Chapman
2013-02-08 23:34 ` Scott Wood
2013-02-09 1:02 ` Harvey Chapman
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=1360275748.27002.11@snotra \
--to=scottwood@freescale.com \
--cc=u-boot@lists.denx.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.