On Tue, 2015-01-27 at 17:47 -0600, Peter Tyser wrote: > Hi Scott, > > > > > I waffled about removing it, but leaned towards leaving it in because: > > > - I didn't want to change the existing U-Boot behavior for other > > > users. A google of 'u-boot "nand write"' shows a lot of examples that > > > don't include verification of writes, and they should if we remove > > > auto-verification. > > > > How many configs actually enable this option? I don't see many beyond > > the FSL PPC boards (which are so full of copy-and-paste that it probably > > wasn't deliberate). > > Yeah, the majority are FSL 83xx and 85xx, with 2 or so random ARM boards. > > > > - The reason it was removed in Linux was "Both UBI and JFFS2 are able > > > to read verify what they wrote already. There are also MTD tests > > > which do this verification." I thought U-Boot was more likely than > > > Linux to use raw NAND writes without a filesystem, so leaving it in U- > > > Boot made sense since the UBI/JFFS2 logic didn't apply as much here. > > > > Right, though raw writes ought to be limited to blocks that aren't > > written often enough to fail. > > > > > - I didn't think a lot of people would know they have to explicitly > > > verify NAND contents after a write, since they'd assume it was like > > > other memories that aren't as lossy. > > > > > > - The penalty of slightly different code from Linux and a small > > > performance hit was worth the gain of auto-verification to me. I > > > viewed consolidating it into one small chunk of code as a happy medium. > > > > The davinci patches show that there can still be driver dependencies > > depending on what the driver overrides. I'm not hugely opposed, but it > > seems like it would be better to do it at a higher level (e.g. in > > nand_util.c with a flag to enable, and either make support mandatory, or > > if you try to use that command variant without support it fails rather > > than silently not verifying). > > That seems like a good idea. How about: > - Remove all CONFIG_MTD_NAND_VERIFY_WRITE references > > - Add a new flag WITH_WR_VERIFY and have nand_write_skip_bad() in > nand_util.c verify writes only when it is set. > > - Update the calls to nand_write_skip_bad() in cmd_nand.c to include > the new WITH_WR_VERIFY flag. I'd vote to enable it for all boards, > but let me know if you disagree. > > That would make all "nand write" commands verify writes, with the > exception of "nand write.raw". Any opinion on if this should also > be verified? I only use it for development/testing, so don't have > a strong opinion.
"raw" refers to the absence of ECC, and I'd rather not overload it to mean "don't verify". Should it also be possible to request non-raw non-verified accesses? Or should we always verify and wait until someone complains about performance? What about DFU and other non-cmd_nand NAND accesses? -Scott _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
