**** BEGIN LOGGING AT Fri Sep 14 02:59:56 2007 Sep 14 07:54:42 gm Sep 14 07:54:44 hello all Sep 14 08:00:07 drath: helper/types.h lines 60 and 86 have an excessive 0. They should read 0xff00 instead of 0xff000. Sep 14 18:11:12 Hi Leon Sep 14 18:11:21 thanks for finding that helper/types.h bug Sep 14 18:12:15 in which way is the first word incorrect? any pattern? Sep 14 18:13:00 debugging the target algorithms is rather difficult - i used to debug them as normal target code, then once i had them right I put them into the code array Sep 14 18:13:47 drath: I think I saw 0x8585 every time Sep 14 18:14:27 drath: I saw hardcoded (13 * 4) in the code to copy the algorithm, but I think it's 14 instructions long, not 13. Sep 14 18:27:01 that's the "exit point", i.e. the address were a breakpoint is placed to halt when the algorithm finished Sep 14 18:29:49 i believe the problem you're seeing is only triggered on BE hosts - i flashed my CS-E9302 board just recently, and that's using a intel CFI chip, too Sep 14 18:34:00 drath: my target is BE, my host is a x86 PC (LE). I wonder, where is the CFI flash put into "read array" mode after workarea algorithm programming? It seem the first words is overwritten after flashing the binary. Sep 14 18:36:44 after all flashing if finished, in cfi_write() Sep 14 18:36:49 s/if/is/ Sep 14 18:36:50 drath meant: after all flashing is finished, in cfi_write() Sep 14 18:40:16 drath: ok, for the really simple case (multiple 16-bit writes, 16-bit aligned, cfi_write() is really simple, all the rare paths should not be taken in the code. I have to verify that that is indeed the case. Sep 14 18:45:09 it seems write_p doesn't get updated after the block write Sep 14 18:46:38 that would explain why the beginning of your image gets corrupted in the end Sep 14 18:48:45 trying to see what you mean Sep 14 18:49:56 but for the simple case, write_p is not used afterwards, is it? Sep 14 18:50:27 yeah, it's only used when there's a single byte left in your case Sep 14 18:51:12 drath: that should not be the case. However, I see your point about write_p not being valid. It's a bug. Sep 14 18:52:31 the next bug is that count is updated after the block write Sep 14 18:52:52 that could corrupt your case, too Sep 14 19:01:44 /* block write completed successfully Sep 14 19:01:44 * update write pointer and count Sep 14 19:01:44 */ Sep 14 19:01:46 write_p += (count & ~(bank->bus_width - 1)) Sep 14 19:01:49 count -= (count & ~(bank->bus_width - 1)) Sep 14 19:02:27 adding this as an 'else' when checking the retval from the block write should solve this problem Sep 14 19:11:34 drath: I cannot find this code you copied above. Where is it from? Sep 14 19:11:51 drath: I am looking at http://svn.berlios.de/wsvn/openocd/trunk/src/flash/cfi.c?op=file&rev=0&sc=0 Sep 14 19:15:23 no, that's what needs to be in the code Sep 14 19:15:46 drath: ah ok Sep 14 19:15:55 i'll put a diff up, hold on Sep 14 19:16:18 irssi decided not to paste the {} Sep 14 19:17:55 http://mmd.ath.cx/openocd/cfi.patch Sep 14 19:18:46 likewise: this includes your types.h fixes Sep 14 19:20:06 drath: ok, when the count is not updated, the if (count > 0) is executed. Sep 14 19:20:36 drath: (I am still looking at what happened with the old code before your patch) Sep 14 19:21:58 drath: if the (count > 0) code path is taken, the flash is still in write mode. However, a read is performed there. Sep 14 19:23:38 ah, ok - you mean we have to switch back to read-array mode Sep 14 19:24:28 drath: yes, in my case, count was > 0, so this code path was taken. Sep 14 19:24:53 it probably reads back the busy / error status, then writes that to word 0. Sep 14 19:25:51 guess it didn't read for memory in your case - count was significantly higher than the bus_width, so bytes would have come from there Sep 14 19:25:59 s/there/the buffer/ Sep 14 19:25:59 drath meant: guess it didn't read for memory in your case - count was significantly higher than the bus_width, so bytes would have come from the buffer Sep 14 19:27:41 patch updated Sep 14 19:30:40 and updated again - the last one switched to array mode for each tail byte, now this is done only once Sep 14 19:32:28 drath: In my case, indeed, I would only execute the first two for loops, the init to zero, and read from buffer. At this point, buffer should still be equal to the function buffer argument value. Sep 14 19:33:32 drath: I'm eager to see what the cfi_write_word(bank, current_word, write_p); did in my case, it probably ruined the first word in flashrom. When 0xffff was there, it changed to 0x8585. Sep 14 19:38:02 drath: I do not have the board with me this weekend, I can test next week. Will the URL be valid next week? Sep 14 19:38:52 drath: Oh, and what's this analyzer? http://mmd.ath.cx/openocd/seven_bit_tck_tdi.png Sep 14 19:43:17 drath: we need to do anpther online conference for that vhdl stuff some point this week Sep 14 19:43:26 the guy in italy is now tuned in by me Sep 14 19:43:34 and he will have several questions Sep 14 20:16:10 likewise: yeah, i clean the directory only once every few weeks Sep 14 20:16:25 likewise: it's a braintechnology LA100: http://www.braintechnology.de/braintechnology/lausb.html Sep 14 20:17:57 blogic: sure - i should be available from around 18:30 each day, and all day on weekends Sep 14 20:19:31 drath: ok... i'll try to organize summin Sep 14 20:19:51 drath: the analyzer has linux software ? Sep 14 20:22:34 blogic: no - windows only unfortunately Sep 14 20:22:54 blogic: no idea if this thing is "good", but i can borrow it from my university Sep 14 20:28:21 ok :-) Sep 14 21:34:20 drath: you really need a "Download" url on your openocd page Sep 14 21:38:26 there's Yagarto to serve to windows users, and packages in debian and ubuntu Sep 14 21:39:59 but yeah, the openocd page could use some more content Sep 14 21:40:04 including downloads Sep 14 21:54:06 drath: really just need url to the svn repo **** ENDING LOGGING AT Sat Sep 15 02:59:57 2007