Here's a patch to fix the increment. I'll mess around with error output later. There are a lot of areas that I would like to visit to update error output. So many errors don't present proper fault output. It makes it hard to trace problems when regressions happen :) I'll spend some time with that once I have the AT91SAM9 NAND working and get a start with the dataflash.
// Dean Glazeski On Thu, Nov 19, 2009 at 5:12 PM, Zach Welch <z...@superlucidity.net> wrote: > 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 <dngl...@gmail.com> > > > 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 > > > <z...@superlucidity.net> 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 > > > > > > > > > > > > > > > >
From d2eaf8b518512af71660e9593cc84d24479dc3ae Mon Sep 17 00:00:00 2001 From: Dean Glazeski <dngl...@gmail.com> Date: Thu, 19 Nov 2009 17:12:23 -0600 Subject: [PATCH] NAND verify doesn't advance. Fix to move the device address up as the contents are verified. --- src/flash/nand.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/flash/nand.c b/src/flash/nand.c index ccc3f46..ec46bc4 100644 --- a/src/flash/nand.c +++ b/src/flash/nand.c @@ -1593,7 +1593,7 @@ COMMAND_HANDLER(handle_nand_verify_command) } file.size -= bytes_read; - file.address += nand->page_size; + dev.address += nand->page_size; } if (nand_fileio_finish(&file) == ERROR_OK) -- 1.6.2.5
_______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
