On Thu, 2009-11-19 at 15:08 -0800, Zach Welch wrote:
> At the moment, I just want correctness.  Thanks for doing the detective
> work, but you're also welcom.

Whoops... that one slipped away from me....  you're also welcome to put
together an initial patch for it.   Similarly, you are welcome to submit
a patch to improve the output, but I think the memcmps are good for the
first check.  A for-loop (in a static helper function) could then do a
slower check to produce good output.

--

> On Thu, 2009-11-19 at 17:04 -0600, Dean Glazeski wrote:
> > After writing this email, I came across the bug.  There are a few ways
> > to fix it and I'll leave it to you to decide.  The dev.address needs
> > to be advanced with the file.address in the main verify loop.  This
> > might be replaceable by just advancing dev and not file, or moving
> > both, etc.
> > 
> > As another note, would it be better to have a for loop iterate through
> > data as opposed to using memcmp?  memcmp is faster, but you can
> > provide more information if things are in a for loop.
> > 
> > // Dean Glazeski
> > 
> > 
> > On Thu, Nov 19, 2009 at 4:58 PM, Dean Glazeski <[email protected]>
> > wrote:
> >         nand verify is not working.  I'm trying to trace it to the
> >         problem, but it appears there is something wrong with the file
> >         struct that's reading the file.  Somehow the data read from
> >         the file doesn't match the actual data in the file.  The odd
> >         ball thing is that nand erase, followed by nand write,
> >         followed by nand dump produces matching bin files to the
> >         original written bin file.  It also appears that the file
> >         struct is used in the same way in the nand write handler, so
> >         I'm a bit confused.  I'm going to keep poking until I figure
> >         it out or some one posts something here.
> >         
> >         As another curveball, it reads 0x1B when not verifying oob and
> >         0x05 when I tell it to at location 0.  The correct value in
> >         the file is 0x1E for that location and the NAND device does
> >         return this value when read.
> >         
> >         // Dean Glazeski
> >         
> >         
> >         
> >         
> >         On Thu, Nov 19, 2009 at 9:15 AM, Zach Welch
> >         <[email protected]> wrote:
> >                 On Wed, 2009-11-18 at 23:25 -0600, Dean Glazeski
> >                 wrote:
> >                 > Hi all,
> >                 >
> >                 > Recent NAND file I/O changes are parsing the wrong
> >                 argument for the
> >                 > size.  Should be third argument, not second.
> >                 
> >                 
> >                 Pushed.  Let me know if you find any other problems.
> >                  Incidentally, does
> >                 the 'new verify' command work for you (after this
> >                 fix)? :)
> >                 
> >                 --Z
> >         
> >         
> > 
> 
> 


_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development

Reply via email to