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>master
parent
ea533c260a
commit
3048632251
Loading…
Reference in new issue