| 05:47.30 | *** join/#openjtag dot (n=ka6sox@netblock-68-183-62-135.dslextreme.com) |
| 06:13.21 | *** join/#openjtag AchiestDragon (n=david@whipy.demon.co.uk) |
| 06:13.21 | *** join/#openjtag dwery (n=dwery@nslu2-linux/dwery) [NETSPLIT VICTIM] |
| 06:36.31 | *** join/#openjtag rd_ (n=redragon@segfault.net) |
| 07:28.36 | *** join/#openjtag rd__ (n=redragon@segfault.net) |
| 08:16.54 | *** join/#openjtag xela (n=xela@i3ED6F5E2.versanet.de) |
| 08:17.16 | xela | Hello drath! |
| 08:17.56 | xela | Was a pretty long debugging session last friday and yesterday (15hrs in one stretch) |
| 08:18.05 | xela | finally tracked down the problem in my app |
| 08:18.19 | xela | but only with help of openocd and especially your help! |
| 08:38.56 | drath | heh, cool |
| 09:28.34 | xela | ah ok you there |
| 09:29.19 | xela | what do you think about extending the flash algorithm so the code erases the sections it intends to flash? |
| 09:33.37 | drath | hum, well, the current scheme gives greater flexibility, like allowing you to flash sectors in several steps |
| 09:33.45 | xela | true |
| 09:34.10 | xela | does the flash algorith very the code? |
| 09:34.14 | xela | using a crc16 or such? |
| 09:34.58 | drath | not at all |
| 09:35.10 | drath | if you meant "verify" |
| 09:35.39 | xela | verify, yes |
| 09:36.02 | xela | how do you feel about integrating such? |
| 09:36.18 | xela | openocd could calculate the given crc16 |
| 09:36.45 | xela | and after flashing there could run some algorithm in the ram to calculate the actual crcr |
| 09:36.46 | xela | crc |
| 09:37.08 | xela | so openocd doesnt have to dump all the info |
| 09:37.19 | xela | (crc16 is pretty fast and easy if using lookup tables) |
| 09:38.06 | drath | ok, we could add a CRC16 algorithm, much like the current flash writing algorithms, to safe us from having to read a possibly large area of target memory |
| 09:39.18 | xela | yes |
| 09:39.50 | xela | i havent looked into the source code of openocd at all |
| 09:39.55 | xela | is it c or c++? |
| 09:39.57 | drath | C |
| 09:40.23 | xela | would you describe it as, hum, hard to read or understand? |
| 09:40.40 | xela | (most c++ code i have read ever was plain ugly) |
| 09:40.51 | drath | the overall structure might be a bit hard to understand, but the code itself is rather straightforward |
| 09:41.07 | xela | sounds good |
| 09:41.21 | xela | i will be away for the next to weeks from friday on |
| 09:41.28 | xela | but after that i wanna look inside |
| 09:41.51 | drath | well, a verify has always been on my list, and should be pretty easy to implement |
| 09:41.54 | xela | (having worked on RapidSVN for six years now I am looking for something new...) |
| 09:42.03 | xela | yes, would think so to |
| 09:42.09 | drath | we could start with dump-comparing, as that's a lot easier |
| 09:42.22 | drath | and add CRC16 verification as a speed-up for targets offering a working_area |
| 09:42.32 | xela | but its time-expensice if its the default |
| 09:42.44 | xela | s/expensice/expensive/ |
| 09:42.52 | drath | the code can automatically fall back to dumping if there's no working_area |
| 09:43.23 | xela | yes |
| 09:43.41 | xela | but i guess we wont have the dump-verify enabled by default |
| 09:43.49 | xela | extra command? or extra option? |
| 09:44.11 | drath | uhm, no - it would try to use a working_area, and if that fails, it uses the dumping |
| 09:44.19 | drath | just like the current write algorithms do |
| 09:44.43 | drath | transparent to the user |
| 09:45.14 | drath | there are situations where you simply don't have a working area, like when there's only SDRAM which has yet to be initialized |
| 09:45.28 | xela | but right now, if the jtag speed is low flashing would take twice as long |
| 09:45.36 | xela | yes |
| 09:45.42 | drath | yeah, verify would of course be an option |
| 09:45.56 | drath | i have yet to see flashing fail on any of my devices |
| 09:46.04 | xela | yes? |
| 09:46.13 | xela | i dont know if its especially the str750 |
| 09:46.25 | xela | but here it happens often |
| 09:46.40 | drath | (LPC2000, STR711, SAM7S, SAM7X and several external Intel flash chips) |
| 09:47.03 | drath | this is definitely due to a bug |
| 09:47.15 | xela | the situation is not better when i flash the thing using RLink-Pro |
| 09:47.37 | drath | oh... |
| 09:47.41 | drath | flashing fails there, too? |
| 09:47.44 | xela | the STR711 has a smaller flash, right? |
| 09:47.46 | xela | yes it does |
| 09:47.56 | xela | not as often but every third try |
| 09:48.13 | xela | what eval boards do you work with? |
| 09:48.23 | drath | flash size of the STR7x depends on the letters after the number, like STR711FR2 -> FR2 |
| 09:49.00 | drath | the FR2 has 256+16 flash and 64 ram |
| 09:49.33 | drath | i mostly use the eval boards as testing targets for the openocd, no real projects, aside from getting u-boot and linux to run on the bigger ones |
| 09:50.57 | xela | so flashing the str711fr2 in one strech works for you? |
| 09:51.26 | drath | yeah, the whole 256kb in one go |
| 09:52.45 | xela | so which eval board do you use and which jtag adapter? |
| 09:53.20 | xela | we are using the Raisonance REva (with several daughter boards) and the Amontec JTagKey |
| 09:53.52 | drath | an Olimex STR-H711 (header board, just the STR + crystal etc.) with Amontec JTAGkey, JTAGkey-Tiny or Signalyzer |
| 09:54.00 | drath | they're all FT2232 based so there's no difference |
| 09:55.22 | xela | hm |
| 09:57.46 | xela | so i wonder whats happening on my boards |
| 09:57.54 | xela | (4 MHz crystal) |
| 09:58.09 | drath | same here |
| 09:58.40 | drath | hum, is there really no errata for the STR7x - couldn't find any, but I can't believe they got their chips completely right |
| 09:59.06 | xela | yea |
| 10:01.22 | xela | where did you get your olimex boards? direct from olimex or from elektronikladen.de |
| 10:01.24 | xela | ? |
| 10:02.38 | drath | the STR7 is from my university, don't know where they got it from |
| 10:03.07 | drath | the others i got directly from Olimex, and one from a hungarian distributor of them |
| 10:05.37 | xela | i see |
| 10:06.58 | xela | mikrocontroller.net dont have them :-( |
| 10:06.58 | xela | they do have other stuff from olimex but not this one |
| 10:06.58 | xela | ok... have to run... will be back in 2-3 hours |
| 10:07.50 | drath | ok, bye |
| 10:36.56 | *** join/#openjtag nslu2-log_ (n=nslu2-lo@nslu2-linux/dyoung) |
| 10:39.03 | *** join/#openjtag ka6sox-laptop (n=ka6sox@nslu2-linux/ka6sox) [NETSPLIT VICTIM] |
| 10:39.03 | *** join/#openjtag nm (n=hongtd@58.187.131.212) [NETSPLIT VICTIM] |
| 10:39.03 | *** join/#openjtag nslu2-log (n=nslu2-lo@nslu2-linux/dyoung) |
| 11:03.22 | *** join/#openjtag bullet (n=bullet@205-78.0-85.cust.bluewin.ch) |
| 13:03.08 | *** join/#openjtag bullet (n=bullet@205-78.0-85.cust.bluewin.ch) |
| 13:16.12 | *** join/#openjtag prpplague (n=dave@mail.americanmicrosystems.com) |
| 14:09.49 | *** join/#openjtag xela_ (n=xela@i3ED6F5E2.versanet.de) |
| 14:09.50 | *** join/#openjtag xela (n=chatzill@p549CA146.dip0.t-ipconnect.de) |
| 14:09.56 | xela | Rehi! |
| 14:41.48 | *** join/#openjtag Chocobo (n=swinchen@strongbad.eece.maine.edu) |
| 14:44.27 | *** join/#openjtag xela__ (n=chatzill@p549CA146.dip0.t-ipconnect.de) |
| 15:34.46 | Chocobo | so is getting started with jtag complicated? |
| 15:35.39 | ka6sox-laptop | not really. |
| 15:36.16 | Chocobo | I just ordered some AVR samples with jtag interface, I figure that would be a good starting point. |
| 15:36.44 | drath | JTAG is used for lots of different purposes - JTAG itself is rather easy |
| 15:38.01 | Chocobo | it is used for programming, debugging, boundary scan, and in system emulation correct? |
| 15:38.28 | drath | guess so |
| 15:44.29 | xela__ | drath: what is the calling "interface" between openocd and a embedded routine like the flash routine? |
| 15:44.37 | xela__ | it gets copied to some ram location |
| 15:44.47 | xela__ | then it gets called |
| 15:44.52 | xela__ | how does it return? |
| 15:46.55 | drath | with a breakpoint |
| 15:47.23 | drath | int armv4_5_run_algorithm(struct target_s *target, int num_mem_params, mem_param_t *mem_params, int num_reg_params, reg_param_t *reg_params, u32 entry_point, u32 exit_point, int timeout_ms, void *arch_info) |
| 15:47.34 | drath | that's the function that calls the algorithm |
| 15:47.53 | drath | the code is passed as a mem_param |
| 15:48.01 | xela__ | nice |
| 15:48.25 | xela__ | so how do you compile the embedded routines? |
| 15:48.38 | xela__ | c code using arm-elf-gcc with a simple linker script |
| 15:48.59 | xela__ | so you will get a binary with just the function without any surrounding frame? |
| 15:49.09 | drath | the current routines are all handcrafted assembler ;) |
| 15:49.31 | drath | the str7x write routine is 80 bytes - i doubt a compiler would do better |
| 15:49.47 | xela__ | gcc isnt that bad, i am really astonished about its work |
| 15:49.54 | xela__ | just thinking about the crc |
| 15:50.10 | xela__ | are the write routines thumb? |
| 15:50.15 | drath | no, arm |
| 15:50.44 | drath | yeah, gcc could probably do the same, but having it all in assembler is easier to work with |
| 15:51.37 | xela__ | how do you embed the embedded code in the openocd code? |
| 15:51.37 | drath | like i don't need function prologues etc., that's all done inside the host code, with the right values passed in the register parameters |
| 15:51.46 | drath | u32 code[] = ;) |
| 15:51.47 | xela__ | just memory with the mnemnonics |
| 15:52.02 | xela__ | ok |
| 15:52.07 | drath | this probably needs to be reworked at some time |
| 15:52.12 | xela__ | but would be doable with gcc as well. |
| 15:52.34 | drath | yeah, of course you could use gcc to generate the code |
| 15:52.40 | xela__ | arm-elf-gcc (with __naked functions) -> ld -> foo.bin -> script converts to code snipped |
| 15:53.10 | drath | it just wasn't necessary for the flash write routines, that merely copy data and compare the status |
| 15:53.34 | xela__ | true |
| 15:53.54 | xela__ | does openocd use autotools for build? |
| 15:53.58 | drath | yeah |
| 15:54.25 | xela__ | good |
| 15:54.33 | drath | the only target code that goes through cross tools is the XScale debug handler |
| 15:54.35 | xela__ | (well, once one has it working...) |
| 15:54.43 | drath | heh, yeah |
| 15:54.48 | xela__ | ah ok, but the skeleton is there |
| 15:55.01 | xela__ | (thought about converting RapidSVN from autotools to cmake) |
| 15:55.15 | drath | if you call target/xscale/build.sh a skeleton, then yes |
| 15:55.29 | drath | i keep the generated binary in svn |
| 15:55.34 | drath | as this rarely changes |
| 15:55.52 | drath | and a user shouldn't need the cross tools to build the debugger |
| 15:55.59 | xela__ | i know about the discussions whether or not to version binaries... |
| 15:56.33 | xela__ | for customers code we version it as well (together with elf and map) so we can debug without build dependencies (compiler versions and so on) |
| 16:08.27 | drath | at some point the algorithm handling in openocd needs to be enhanced anyway, like when there's support for non-ARM targets and CFI flashes - the algorithm stuff should then automatically pick the right algorithm file, without a need to duplicate all the generic stuff |
| 16:10.46 | xela__ | sounds like future... |
| 16:11.05 | xela__ | another question: what is your job situation... how do you find time for openocd? |
| 16:11.51 | drath | writing my master's thesis, which builds upon the OpenOCD (my diploma thesis project), so currently I still find time to work on it every now and then |
| 16:12.28 | xela__ | and once you are dont with your masters thesis? |
| 16:12.58 | drath | guess i have to get myself a job then ;) but i currently don't have anything special in mind |
| 16:13.47 | xela__ | hopefully openocd wont be orphaned then... |
| 16:14.30 | drath | no, certainly not - i've already put so much time in there i wont let it die |
| 16:15.27 | *** join/#openjtag Chocobo (n=swinchen@strongbad.eece.maine.edu) |
| 16:15.28 | xela__ | good to hear... |
| 16:15.33 | xela__ | where in germany are you located anyhow? |
| 16:15.39 | drath | Augsburg |
| 16:16.16 | xela__ | quite close... Ravensburg |
| 16:16.38 | drath | ah, nice |
| 16:17.01 | drath | never been there, but it's supposed to be a nice town |
| 16:18.42 | xela__ | near the Bodensee and the Alpen... |
| 16:18.45 | xela__ | really nice |
| 16:19.04 | xela__ | used to have a friend in Koenigsbrunn... liked Augburg a lot |
| 16:19.15 | drath | heh, actually i live in Koenigsbrunn :) |
| 16:19.25 | xela__ | :-) |
| 16:19.38 | drath | but few people know that, and Augsburg is close enough |
| 16:19.39 | xela__ | and i cycled along the Lech a couple of times... really nice |
| 16:19.41 | Chocobo | Anyone here messed around with the TI ez430 |
| 16:22.52 | *** join/#openjtag p2-mate (n=p2@cable-87-244-173-194.upc.chello.be) |
| 16:39.32 | *** join/#openjtag toi (n=pleemans@d5152D3B4.access.telenet.be) |
| 16:59.00 | *** join/#openjtag toi_ (n=pleemans@d5152D3B4.access.telenet.be) |
| 18:22.16 | *** join/#openjtag ka6sox (n=ka6sox@nslu2-linux/ka6sox) |
| 18:28.33 | *** join/#openjtag bullet (n=bullet@205-78.0-85.cust.bluewin.ch) |
| 18:31.00 | *** join/#openjtag ka6sox-laptop (n=tom@nslu2-linux/ka6sox) |
| 18:31.34 | *** part/#openjtag ka6sox (n=ka6sox@nslu2-linux/ka6sox) |
| 18:34.46 | *** part/#openjtag ka6sox-laptop (n=tom@nslu2-linux/ka6sox) |
| 19:12.26 | *** join/#openjtag drath_ (i=vmaster@p5b07d1d0.dip.t-dialin.net) |
| 20:24.59 | *** join/#openjtag drath (i=vmaster@p5b07d1d0.dip.t-dialin.net) [NETSPLIT VICTIM] |
| 20:24.59 | *** join/#openjtag bullet (n=bullet@205-78.0-85.cust.bluewin.ch) [NETSPLIT VICTIM] |
| 20:24.59 | *** join/#openjtag toi_ (n=pleemans@d5152D3B4.access.telenet.be) [NETSPLIT VICTIM] |
| 20:24.59 | *** join/#openjtag xela_ (n=xela@i3ED6F5E2.versanet.de) [NETSPLIT VICTIM] |
| 20:24.59 | *** join/#openjtag prpplague (n=dave@mail.americanmicrosystems.com) |
| 20:24.59 | *** join/#openjtag rd_ (n=redragon@segfault.net) [NETSPLIT VICTIM] |
| 20:24.59 | *** join/#openjtag muasch|swiss (n=muasch@31.14.3.213.fix.bluewin.ch) [NETSPLIT VICTIM] |
| 20:24.59 | *** join/#openjtag rwhitby (n=nrwhitby@nslu2-linux/rwhitby) [NETSPLIT VICTIM] |
| 20:24.59 | *** join/#openjtag wookey_ (i=wookey@courthouse.aleph1.co.uk) [NETSPLIT VICTIM] |
| 20:28.16 | *** join/#openjtag nm (n=hongtd@58.187.131.212) |
| 23:48.26 | rwhitby | drath: we're sure to have a job for you in Australia when you're finished your masters :-) |