| 01:46.36 | *** join/#openjtag drath (i=vmaster@p5B07F236.dip.t-dialin.net) |
| 01:58.46 | *** join/#openjtag rd_ (n=rd@211.25.196.30) |
| 05:23.18 | *** join/#openjtag pleemans (n=peter@leemanpe.ugent.be) |
| 06:36.26 | *** join/#openjtag pleemans (n=peter@leemanpe.ugent.be) |
| 07:40.46 | *** join/#openjtag aproemel (n=aproemel@p508A1590.dip0.t-ipconnect.de) |
| 07:53.29 | *** join/#openjtag likewise (n=chatzill@atwork-186.r-212.178.104.atwork.nl) |
| 07:53.39 | likewise | gm |
| 07:53.41 | likewise | hello all |
| 07:59.03 | likewise | drath: helper/types.h lines 60 and 86 have an excessive 0. They should read 0xff00 instead of 0xff000. |
| 13:24.30 | *** join/#openjtag blogic (n=john@acme.areaserver.it) |
| 13:28.41 | *** join/#openjtag prpplague (n=DaveAnde@mail.americanmicrosystems.com) |
| 15:09.57 | *** join/#openjtag prpplague (n=DaveAnde@mail.americanmicrosystems.com) |
| 16:10.18 | *** join/#openjtag p2-mate (n=p2@cable-87-244-173-194.upc.chello.be) |
| 16:40.34 | *** join/#openjtag pleemans (n=peter@d51A5E76A.access.telenet.be) |
| 16:42.40 | *** part/#openjtag ka6sox (n=ka6sox@nslu2-linux/ka6sox) |
| 17:15.13 | *** join/#openjtag rd_ (n=rd@60.54.42.197) |
| 17:19.26 | *** join/#openjtag rd_ (n=rd@trung.tam.mua.ban.trao.doi.phu.nu) |
| 17:21.05 | *** join/#openjtag AM|R (n=gomo@124.82.86.132) |
| 17:21.12 | *** part/#openjtag AM|R (n=gomo@124.82.86.132) |
| 18:06.10 | *** join/#openjtag likewise (n=chatzill@82-171-189-134.dsl.ip.tiscali.nl) |
| 18:10.03 | drath | Hi Leon |
| 18:10.12 | drath | thanks for finding that helper/types.h bug |
| 18:11.06 | drath | in which way is the first word incorrect? any pattern? |
| 18:11.52 | drath | 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 |
| 18:12.38 | likewise | drath: I think I saw 0x8585 every time |
| 18:13.19 | likewise | drath: I saw hardcoded (13 * 4) in the code to copy the algorithm, but I think it's 14 instructions long, not 13. |
| 18:25.53 | drath | that's the "exit point", i.e. the address were a breakpoint is placed to halt when the algorithm finished |
| 18:28.40 | drath | 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 |
| 18:32.51 | likewise | 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. |
| 18:35.35 | drath | after all flashing if finished, in cfi_write() |
| 18:35.41 | drath | s/if/is/ |
| 18:39.08 | likewise | 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. |
| 18:44.00 | drath | it seems write_p doesn't get updated after the block write |
| 18:45.30 | drath | that would explain why the beginning of your image gets corrupted in the end |
| 18:47.36 | likewise | trying to see what you mean |
| 18:48.47 | likewise | but for the simple case, write_p is not used afterwards, is it? |
| 18:49.18 | drath | yeah, it's only used when there's a single byte left in your case |
| 18:50.03 | likewise | drath: that should not be the case. However, I see your point about write_p not being valid. It's a bug. |
| 18:51.22 | drath | the next bug is that count is updated after the block write |
| 18:51.43 | drath | that could corrupt your case, too |
| 19:00.35 | drath | /* block write completed successfully |
| 19:00.35 | drath | <PROTECTED> |
| 19:00.35 | drath | <PROTECTED> |
| 19:00.37 | drath | write_p += (count & ~(bank->bus_width - 1)) |
| 19:00.40 | drath | count -= (count & ~(bank->bus_width - 1)) |
| 19:01.18 | drath | adding this as an 'else' when checking the retval from the block write should solve this problem |
| 19:10.25 | likewise | drath: I cannot find this code you copied above. Where is it from? |
| 19:10.42 | likewise | drath: I am looking at http://svn.berlios.de/wsvn/openocd/trunk/src/flash/cfi.c?op=file&rev=0&sc=0 |
| 19:14.14 | drath | no, that's what needs to be in the code |
| 19:14.37 | likewise | drath: ah ok |
| 19:14.46 | drath | i'll put a diff up, hold on |
| 19:15.09 | drath | irssi decided not to paste the {} |
| 19:16.46 | drath | http://mmd.ath.cx/openocd/cfi.patch |
| 19:17.36 | drath | likewise: this includes your types.h fixes |
| 19:18.57 | likewise | drath: ok, when the count is not updated, the if (count > 0) is executed. |
| 19:19.27 | likewise | drath: (I am still looking at what happened with the old code before your patch) |
| 19:20.49 | likewise | drath: if the (count > 0) code path is taken, the flash is still in write mode. However, a read is performed there. |
| 19:22.29 | drath | ah, ok - you mean we have to switch back to read-array mode |
| 19:23.19 | likewise | drath: yes, in my case, count was > 0, so this code path was taken. |
| 19:23.44 | likewise | it probably reads back the busy / error status, then writes that to word 0. |
| 19:24.41 | drath | 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 |
| 19:24.50 | drath | s/there/the buffer/ |
| 19:26.32 | drath | patch updated |
| 19:29.31 | drath | and updated again - the last one switched to array mode for each tail byte, now this is done only once |
| 19:31.18 | likewise | 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. |
| 19:32.23 | likewise | 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. |
| 19:36.53 | likewise | drath: I do not have the board with me this weekend, I can test next week. Will the URL be valid next week? |
| 19:37.42 | likewise | drath: Oh, and what's this analyzer? http://mmd.ath.cx/openocd/seven_bit_tck_tdi.png |
| 19:42.07 | blogic | drath: we need to do anpther online conference for that vhdl stuff some point this week |
| 19:42.16 | blogic | the guy in italy is now tuned in by me |
| 19:42.25 | blogic | and he will have several questions |
| 20:15.01 | drath | likewise: yeah, i clean the directory only once every few weeks |
| 20:15.15 | drath | likewise: it's a braintechnology LA100: http://www.braintechnology.de/braintechnology/lausb.html |
| 20:16.47 | drath | blogic: sure - i should be available from around 18:30 each day, and all day on weekends |
| 20:18.22 | blogic | drath: ok... i'll try to organize summin |
| 20:18.42 | blogic | drath: the analyzer has linux software ? |
| 20:21.24 | drath | blogic: no - windows only unfortunately |
| 20:21.45 | drath | blogic: no idea if this thing is "good", but i can borrow it from my university |
| 20:27.11 | blogic | ok :-) |
| 21:33.10 | prpplague | drath: you really need a "Download" url on your openocd page |
| 21:37.16 | drath | there's Yagarto to serve to windows users, and packages in debian and ubuntu |
| 21:38.49 | drath | but yeah, the openocd page could use some more content |
| 21:38.54 | drath | including downloads |
| 21:52.56 | prpplague | drath: really just need url to the svn repo |
| 22:15.24 | *** join/#openjtag drath_ (i=vmaster@p5B07F5B9.dip.t-dialin.net) |
| 22:24.53 | *** join/#openjtag drath (i=vmaster@p5B07DDDD.dip.t-dialin.net) |
