On Thu, 2015-01-29 at 17:37 -0600, Peter Tyser wrote: > On Thu, 2015-01-29 at 17:02 -0600, Scott Wood wrote: > > 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? > > OK, I'll add verification to the "nand write.raw" functionality too. > I'd lean towards always verifying and waiting until/if someone > complains about performance. I doubt many (any?) people are doing > timing critical writes in U-Boot. I think the argument that writes > should be verified carries some water, and it'd be nice to not > make the command arguments more complicated than they already are. > > > What about DFU and other non-cmd_nand NAND accesses? > > Are there other non-cmd NAND accesses other than DFU? None jumped > out at me.
There's ubi/jffs2/yaffs2, which are responsible for their own verification, and a read-only access in compulab board code, but otherwise maybe not. The MTD interface is harder to grep for, though. > I'm not too familiar with DFU, but in theory the DFU > programming utilities could already be doing their own verification. > I took a quick look at the dfu-util source, and it doesn't appear > to be doing its own. I'd vote to verify the DFU writes too, since > even more than "nand write" its performance shouldn't be very > critical. I'll break DFU verification out into a separate patch, > and you or others can ACK or reject it then. > > Let me know if the above sounds good and I'll make the changes. Fine with me. -Scott _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot