Re: [Openocd-development] NAND File I/O parses wrong argument
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 Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] NAND File I/O parses wrong argument
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 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] NAND File I/O parses wrong argument
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 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] NAND File I/O parses wrong argument
Thanks for the feedback. I will take a closer look at the code. I am not entirely surprised by this bug in the new function (given the way that I implemented it), but it's great to hear that I didn't cause any other regressions with the existing commands. --Z On Thu, 2009-11-19 at 16:58 -0600, Dean Glazeski 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 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] NAND File I/O parses wrong argument
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 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] NAND File I/O parses wrong argument
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
Re: [Openocd-development] NAND File I/O parses wrong argument
Thanks. I think David and I have both been improving the error handling in places that we touch, but we need a more systematic approach to it. I have been thinking about starting an automated test suite for 0.4.0, as such might have prevented a few of the minor issues that we've seen. Any contributions that you feel like making... send the patches. :) On Thu, 2009-11-19 at 17:15 -0600, Dean Glazeski wrote: 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 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
