From: Scott Wood <scottwood@freescale.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 1/1] nand: adjust erase/read/write partition/chip size for bad blocks
Date: Wed, 27 Feb 2013 15:48:58 -0600 [thread overview]
Message-ID: <1362001738.15577.16@snotra> (raw)
In-Reply-To: <3570adfb2947eff6fe6cdb8ee38754361cfdc4f0.1361937259.git.hchapman@3gfp.com> (from hchapman@3gfp.com on Tue Feb 26 21:57:14 2013)
On 02/26/2013 09:57:14 PM, Harvey Chapman wrote:
> Adjust the sizes calculated for whole partition/chip operations by
> removing the size of bad blocks so we don't try to erase/read/write
> past a partition/chip boundary.
>
> Signed-off-by: Harvey Chapman <hchapman@3gfp.com>
> ---
> common/cmd_nand.c | 35 +++++++++++++++++++++++++++++++++++
> 1 file changed, 35 insertions(+)
I don't think we want to do this adjustment for erase -- the value you
pass in there is already defined as being the range of blocks on the
flash, rather than the amount of data you want to be able to store in
the range (except for the ".spread" variant, but that can't be used
with .part or .chip).
This makes me wonder if a better approach would be a flag that tells
the nand_read|write_skip_bad() function whether "size" is meant as
"good data size" or "actual size"? Then we could just set that flag
for whole-chip/whole-partition accesses, and let the existing bad block
skipping code handle it with some minor tweaks. This would be similar
to opts->spread for erase.
-Scott
prev parent reply other threads:[~2013-02-27 21:48 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-27 3:57 [U-Boot] [PATCH 0/1] nand: adjust erase/read/write partition/chip size for bad blocks Harvey Chapman
2013-02-27 3:57 ` [U-Boot] [PATCH 1/1] " Harvey Chapman
2013-02-27 21:48 ` Scott Wood [this message]
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=1362001738.15577.16@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox