| 02:08.33 | *** join/#openjtag rd_ (n=rd@trung.tam.mua.ban.trao.doi.phu.nu) |
| 02:25.52 | *** join/#openjtag rd_ (n=rd@trung.tam.mua.ban.trao.doi.phu.nu) [NETSPLIT VICTIM] |
| 02:25.52 | *** join/#openjtag key2 (n=Ritual@193.33.36.20) [NETSPLIT VICTIM] |
| 02:25.52 | *** join/#openjtag blogic (n=john@acme.areaserver.it) [NETSPLIT VICTIM] |
| 02:25.52 | *** join/#openjtag toi (n=pleemans@d5152D3B4.access.telenet.be) |
| 02:40.01 | *** join/#openjtag nslu2-log (n=nslu2-lo@nslu2-linux/dyoung) |
| 02:42.25 | *** join/#openjtag nslu2-log (n=nslu2-lo@nslu2-linux/dyoung) |
| 05:24.49 | *** join/#openjtag pleemans (n=peter@leemanpe.ugent.be) |
| 07:52.23 | *** join/#openjtag rd_ (n=dr@trung.tam.mua.ban.trao.doi.phu.nu) |
| 13:07.08 | *** join/#openjtag rd_ (n=dr@trung.tam.mua.ban.trao.doi.phu.nu) |
| 14:00.45 | *** join/#openjtag prpplague (n=DaveAnde@mail.americanmicrosystems.com) |
| 15:33.24 | *** join/#openjtag pleemans (n=peter@d51A5E76A.access.telenet.be) |
| 17:04.30 | *** join/#openjtag Chocobo (n=swinchen@strongbad.eece.maine.edu) |
| 17:44.30 | fluff | right, i've pulled my s3c24xx patches up to the latest |
| 17:44.43 | fluff | just need to put some copyright headers on 'em and push to our quality control dept |
| 17:45.08 | fluff | good news, my jtagkey arrived today... much nicer |
| 17:45.22 | fluff | getting about 1 page every 2 seconds without acceleration |
| 17:51.28 | *** join/#openjtag likewise (n=chatzill@82-171-189-134.dsl.ip.tiscali.nl) |
| 17:51.47 | likewise | good morning/afternoon/evening/night everyone |
| 17:51.58 | fluff | evening here |
| 17:52.37 | likewise | (same here) |
| 17:53.17 | fluff | not |
| 17:56.14 | prpplague | hehe |
| 17:56.35 | prpplague | fluff: i assume that your jtagkey is ft2232 based? |
| 17:57.36 | fluff | yep |
| 17:58.04 | prpplague | ahh |
| 17:58.06 | likewise | fluff: got own key? |
| 17:58.18 | likewise | fluff: rephrasing: got self-designed jtag key? |
| 17:58.22 | fluff | nope |
| 17:58.42 | prpplague | our flyswatter jtag board is also ft2232 based |
| 17:58.47 | fluff | i'm just working on the analogue front-end for one |
| 17:59.14 | fluff | the test boards arrived this morning |
| 17:59.24 | fluff | 20 of them for ~50ukp |
| 17:59.54 | prpplague | fluff: nice |
| 18:00.14 | prpplague | fluff: you did see the hammer and sledge hammer board we are about to start selling? |
| 18:00.25 | likewise | Anyone familiar with JTAG details here? |
| 18:00.26 | fluff | i think so |
| 18:00.32 | fluff | likewise: sorta |
| 18:00.44 | prpplague | http://www.elinux.org/Hammer_Board |
| 18:00.50 | prpplague | http://www.elinux.org/SledgeHammer_Board |
| 18:00.57 | prpplague | likewise: what aspect of JTAG? |
| 18:01.51 | likewise | prpplague: I'm having JTAG issues with openocd. when we went from IXP420 B0 to B1 stepping, openocd fails here: if (!(field0_in & 1)) return ERROR_TARGET_RESOURCE_NOT_AVAILABLE; in xscale.c/xscale_read_tx() |
| 18:02.12 | likewise | B0 steppings performed fine with OpenOCD. |
| 18:02.28 | *** join/#openjtag p2-mate (n=p2@cable-87-244-173-194.upc.chello.be) |
| 18:02.29 | likewise | which is here in the code: http://svn.berlios.de/wsvn/openocd/trunk/src/target/xscale.c?op=file&rev=206&sc=1 |
| 18:02.58 | prpplague | likewise: i'd have to look, but more that likely something match for the boundry scan |
| 18:03.36 | prpplague | likewise: as to your reference of "JTAG issues" that's kind of like say "Car issues" |
| 18:03.45 | prpplague | likewise: there are alot of different aspects of jtag |
| 18:06.21 | likewise | drath: I think it wants to read a register set by the debug handler earlier. |
| 18:07.42 | drath | ah, i see |
| 18:07.50 | likewise | drath: at first instance I assumed some IEEE JTAG IDCODE to not match, but there seems no such check for it. |
| 18:08.41 | drath | that function can be called to just check if there's data available (e.g. from xscale_poll()), or to actually consume data (if available) |
| 18:09.18 | drath | do you know where it got called from? |
| 18:14.41 | likewise | drath: from xscale_poll() |
| 18:15.44 | drath | ok - did you run into the ERROR("error while polling TX register");? |
| 18:15.53 | drath | or did it just reply ERROR_TARGET_RESOURCE_NOT_AVAILABLE |
| 18:16.10 | likewise | drath: no, it runs into the non-existing else case, i.e. as you say |
| 18:16.54 | drath | ah, ok, so there was just no data in the TX reg |
| 18:17.25 | drath | that's right after starting the OpenOCD? |
| 18:17.31 | likewise | drath: ok, so the debugger handler probably does not run? |
| 18:17.35 | drath | apparently |
| 18:18.49 | likewise | drath: yes, it's set for reset_init. The first time handle_target() is called, it hits this condition |
| 18:19.28 | likewise | thereafter, handle_target() keeps getting called, but xscale_poll() always hits this condition. |
| 18:21.45 | likewise | drath: Is my assumption right that openocd does not check for idcode? |
| 18:24.47 | fluff | load_image is the command I want to send a file to the board |
| 18:24.55 | fluff | to a given address in memory? |
| 18:28.43 | fluff | ok, 6345bytes/second using load_image, is that thought to be ok for a jtagkey running full jtag speed to an arm926ejs? |
| 18:29.22 | fluff | ok, forgot to enable fastness |
| 18:29.27 | fluff | much annoyance |
| 18:33.00 | drath | using FTD2XX i achieved up to 120kbytes/s |
| 18:33.43 | drath | arm7_9 fast_memory_access and arm7_9 dcc_downloads is only safe if the target is running fast enough, usually that means enabled PLL |
| 18:33.52 | drath | which is why both are off by default |
| 18:34.03 | drath | libftdi is considerably slower |
| 18:34.22 | drath | likewise: yeah, the OpenOCD doesn't validate the IDCODE |
| 18:34.33 | drath | likewise: it reads it, and prints out the list of IDs found |
| 18:34.38 | drath | likewise: but otherwise ignores it |
| 18:34.55 | likewise | drath: OK, because indeed the IDCODE is different for the stepping. |
| 18:36.53 | fluff | hmm, using the working area causes an undefined instruction abort :( |
| 18:37.31 | fluff | oops, uboot is running with mmi |
| 18:37.33 | fluff | oops, uboot is running with mmu |
| 18:39.05 | fluff | well, I like you all _lots_ |
| 18:42.44 | prpplague | fluff: generally you have to init a memory region in order to utilize a working area |
| 18:43.04 | prpplague | fluff: i have a small script that inits the sdram prior to usage |
| 18:44.25 | prpplague | fluff: http://www.pastebin.ca/704972 |
| 18:44.35 | prpplague | fluff: that inits the sdram for our s3c2410 board |
| 18:44.48 | prpplague | fluff: you can do something similiar on the s3c2440 of course |
| 18:45.39 | prpplague | fluff: you can also use the TCR in SOC's like the 2440, |
| 18:45.48 | prpplague | fluff: but ofcourse you are limited by the 4k size |
| 18:46.59 | prpplague | fluff: we have a nice little gui for use with openocd in production |
| 18:47.21 | prpplague | fluff: a patch to openocd provides more detailed feedback about the current state of a running script |
| 18:48.02 | drath | fluff: having MMU/caches enabled slows down a lot, because the OpenOCD has to invalidate caches to ensure cache coherency |
| 18:48.25 | prpplague | fluff: we are erase a 16mb nor flash, write the bootloader, 2 kernels, 2 ramdisks, and a small settings block in a little over 3 minutes |
| 18:49.00 | likewise | prpplague: which jtagkey, which processor is that? 10 minutes here for 16 mb nor flash erase and program |
| 18:49.19 | likewise | prpplague: with amontec jtagkey to ixp42x/be |
| 18:49.28 | prpplague | likewise: flyswatter usb jtag and s3c2410 at 200mhz |
| 18:49.34 | drath | all FT2232's are equal |
| 18:49.37 | drath | in terms of speed |
| 18:49.51 | likewise | drath: so it depends on target alone? |
| 18:50.01 | drath | yeah - xscale and ARM7/9 is completely different |
| 18:50.03 | prpplague | drath: unless its a noisy design |
| 18:50.23 | drath | prpplague: heh, yeah, electrically there are huge differences |
| 18:50.59 | drath | the Olimex ARM-USB-OCD refuses to work with a Phytec LPC3180 board |
| 18:51.02 | prpplague | likewise: are you using dcc_downloads? |
| 18:51.13 | drath | prpplague: that command is arm7/9 specific |
| 18:51.26 | prpplague | drath: ahh, didn't know that |
| 18:51.27 | drath | hence the name "arm7_9 dcc_downloads <enable|disable>" |
| 18:51.38 | prpplague | drath: so the xscale doesn't support that ? |
| 18:51.46 | drath | prpplague: XScale does that by default |
| 18:51.53 | prpplague | drath: right, i figured there was an equive for xscale |
| 18:52.03 | drath | prpplague: there's no other mode available on xscale |
| 18:52.08 | prpplague | ahh |
| 18:52.11 | drath | prpplague: you always communicate with a debug handler |
| 18:52.29 | likewise | drath: strange it achieves 30kbytes/s, could that really be the buffer size issue then? (restart overhead) |
| 18:53.07 | drath | likewise: what was your flash throughput? |
| 18:53.17 | likewise | drath: 30 kbytes/second |
| 18:53.26 | drath | likewise: and RAM? |
| 18:53.48 | likewise | while programming CFI strataflash, I did not measure RAM yet. I got stuck when my fellow engineer brought me a B-1 stepping IXP420 board... |
| 18:54.09 | drath | likewise: ah, ok - so you mean compared to the 120kb/s i achieved as a maximum? |
| 18:54.16 | likewise | drath: yes |
| 18:54.40 | drath | likewise: well, that was downloading to an ARM920t - completely different debugging |
| 18:54.56 | drath | likewise: but yeah - larger blocks have a huge impact |
| 18:55.03 | drath | likewise: especially with XScale |
| 18:55.08 | likewise | drath: ok. |
| 18:56.17 | likewise | drath: I assume the debug handler is not run somehow. Where is it supposed to be started? |
| 18:57.17 | drath | it's installed in xscale_deassert_reset() |
| 18:57.39 | drath | and should run once the reset bit in the control register is cleraed |
| 19:02.11 | likewise | drath: * wait 300ms; 150 and 100ms were not enough */ |
| 19:02.13 | likewise | <PROTECTED> |
| 19:03.10 | likewise | I tried various jtag_nsrst_delay values, our reset chip keeps SRST asserted for 150 ms |
| 19:03.58 | drath | likewise: i had to play around with these setting to get PXA27x working |
| 19:04.25 | likewise | drath: interesting. so this value has nothing to do with jtag_nsrst_delay? |
| 19:04.29 | drath | likewise: apparently not all XScales are the same |
| 19:04.44 | drath | likewise: no - jtag_nsrst_delay is meant to account for delays introduced by the reset supervisor |
| 19:05.06 | drath | likewise: the delays in the code are meant to account for delays required by the core itself |
| 19:06.16 | likewise | drath: ok, maybe I need to tweak with this hardcoded value. |
| 19:06.41 | drath | likewise: i'm just downloading ixp42x docs - maybe there's something in the specudates |
| 19:10.11 | likewise | drath: 2.2, 2.3 and 2.4 mention only the SDRAM change. http://download.intel.com/design/network/specupdt/30642807.pdf |
| 20:16.01 | *** join/#openjtag toi (n=pleemans@d5152D3B4.access.telenet.be) |
| 21:35.42 | fluff | drath: I was thinking, would a -script option to run a script and return the status of that be an option for the openocd command line? |
| 21:38.42 | prpplague | fluff: if i understand you correctly, you can already run a script from command line, but i don't believe the main tree of openocd returns a status |
| 21:59.23 | prpplague | fluff: the script is listed in the config file |
| 21:59.42 | fluff | ah, so you give it a config with a script name to run |
| 22:00.12 | prpplague | fluff: correct |
| 22:00.22 | prpplague | fluff: one sec and i'll pastebin my config |
| 22:01.17 | prpplague | fluff: http://www.pastebin.ca/705195 |
| 22:01.23 | prpplague | fluff: thats the cfg file |
| 22:01.30 | prpplague | fluff: which then kicks off the script |
| 22:02.08 | prpplague | fluff: my script then inits the sdram, probes the flash, erases it, transfers the bootloader, kernel and ramdisk, then does a reset and exits openocd |
| 22:02.58 | prpplague | fluff: we added some options where each command that is being issued is echoed to the stdout |
| 22:03.01 | fluff | hmm, it would be useful to know the result, to say something like an automatic programming system |
| 22:03.11 | prpplague | fluff: that way we can parse it a gui |
| 22:03.17 | prpplague | fluff: exactly |
| 22:04.08 | prpplague | fluff: we have 8 usb jtag dongles configured so we can gang program |
| 22:04.19 | prpplague | fluff: our gui guy did a really nice job |
| 22:06.12 | likewise | prpplague: interesting to see. Do you do a verify or checksum pass? |
| 22:06.55 | likewise | prpplague: I have been thinking of writing an assembly CRC routine that runs from the IC or RAM, but my ARM assembly experience is non-existent. |
| 22:07.20 | fluff | likewise: do it in C once the code starts running |
| 22:07.42 | likewise | fluff: you mean a self-test? |
| 22:07.51 | fluff | yeah |
| 22:08.39 | prpplague | likewise: yea we have some test routines that do tests on the sdram first, as well doing crc's on the stored apps |
| 22:09.17 | likewise | prpplague: you run them from openocd, or when the target is up (self-test) |
| 22:09.56 | prpplague | likewise: actually we do both |
| 22:10.15 | prpplague | likewise: new unit is plugged in, operator uses a touchscreen panel pc to start the cycle |
| 22:10.35 | prpplague | likewise: first does a series of sdram initializations |
| 22:11.16 | likewise | I'm creating an openocd-based production env right now, if you care to share your work I'm very much interested. |
| 22:11.16 | prpplague | likewise: then does 6 uploads of various data configurations and checks crcs |
| 22:11.32 | prpplague | likewise: then does the other flashing |
| 22:11.55 | likewise | Currently I have a Cygwin icon that runs a SDRAM test, unlock, erase, flash, but that's about it. |
| 22:12.17 | likewise | Then I got stuck with bugs in the CFI driver, which are now solved. |
| 22:12.49 | likewise | Now I am stuck in a B-1 stepping problem (timing?), and my deadline comes nearer... |
| 22:13.13 | likewise | (ordered a BDI-2000 as fall-back...) |
| 22:13.30 | prpplague | fluff: indeed |
| 22:13.33 | likewise | prpplague: sounds really need |
| 22:13.35 | likewise | neat |
| 22:13.36 | prpplague | fluff: openocd is a gem |
| 22:13.36 | fluff | likewise: ouch |
| 22:13.51 | fluff | you sold bodyparts? |
| 22:13.55 | likewise | fluff: ouch as in $$$? |
| 22:13.58 | fluff | yep |
| 22:14.09 | likewise | yeah, but we cannot delay production... |
| 22:14.59 | likewise | and I need powerpc debugging also |
| 22:15.31 | likewise | good nite, gotta get some sleep |
| 22:15.47 | likewise | thanks for the help everyone |
| 22:15.48 | fluff | yeah, it is almost midnight here |
| 22:15.54 | likewise | 12:15 here |
| 22:15.57 | likewise | 0:15 |
| 22:16.02 | likewise | cu |
| 22:18.13 | prpplague | fluff: if you plan on using more than one jtagkey on a single machine, let me know, i can give you the tips-n-tricks we use |
| 22:18.37 | fluff | we have one machine per jtag |
| 22:19.06 | prpplague | fluff: ahh ok, didn't know if you had plans to do production gang programming |
| 22:19.29 | fluff | buying pcs is _cheap_ |
| 22:20.07 | prpplague | fluff: space isn't |
| 22:20.44 | fluff | not a problem atm for us |
| 22:22.09 | prpplague | ahh |
| 22:22.42 | prpplague | fluff: our production areas are always in need space, so we almost always go with gang programmers for both space and time |
| 22:27.23 | *** join/#openjtag drath_ (i=vmaster@p5B07E24B.dip.t-dialin.net) |
| 22:29.11 | fluff | hmm, two load_images one after the other are causing the system to catch an undefined instructions, both times with r0 equal to the address of the second loadimage |
| 22:29.41 | fluff | if you do them via the command line, it works |
| 22:30.59 | prpplague | fluff: scripted? |
| 22:31.37 | fluff | yeah |