diff options
author | Scott Wood <scottwood@freescale.com> | 2010-08-25 14:43:29 -0500 |
---|---|---|
committer | Scott Wood <scottwood@freescale.com> | 2010-10-11 15:10:17 -0500 |
commit | 30486322517c99f09eabc53f5fad43063656a4f0 (patch) | |
tree | af15251c107a436647938b927b9bf885afae85d6 /drivers/mtd/nand/bfin_nand.c | |
parent | ea533c260a801c4e51f92f75165cebe6d7b01e35 (diff) |
nand erase: .spread, .part, .chip subcommands
A while back, in http://lists.denx.de/pipermail/u-boot/2009-June/054428.html,
Michele De Candia posted a patch to not count bad blocks toward the
requested size to be erased. This is desireable when you're passing in
something like $filesize, but not when you're trying to erase a partition.
Thus, a .spread subcommand (named for consistency with
http://lists.denx.de/pipermail/u-boot/2010-August/075163.html) is introduced
to make explicit the user's desire to erase for a given amount of data,
rather than to erase a specific region of the chip.
While passing $filesize to "nand erase" is useful, accidentally passing
something like $fliesize currently produces quite unpleasant results, as the
variable evaluates to nothing and U-Boot assumes that you want to erase
the entire rest of the chip/partition. To improve the safety of the
erase command, require the user to make explicit their intentions by
using a .part or .chip subcommand. This is an incompatible user interface
change, but keeping compatibility would eliminate the safety gain, and IMHO
it's worth it.
While touching nand_erase_opts(), make it accept 64-bit offsets and sizes,
fix the percentage display when erase length is rounded up, eliminate
an inconsistent warning about rounding up the erase length which only
happened when the length was less than one block (rounding up for $filesize
is normal operation), and add a diagnostic if there's an attempt to erase
beginning at a non-block boundary.
Signed-off-by: Scott Wood <scottwood@freescale.com>
Tested-by: Ben Gardiner <bengardiner@nanometrics.ca>
Diffstat (limited to 'drivers/mtd/nand/bfin_nand.c')
0 files changed, 0 insertions, 0 deletions