| 02:24.35 | *** join/#openjtag jkilb_ (n=jkilb@p5B20BAE3.dip0.t-ipconnect.de) |
| 04:20.24 | rwhitby | drath: ping |
| 04:20.57 | rwhitby | drath: I confirmed that trst and srst are not connected on the dsmg600 board, so that makes it pretty useless for ixp42x debugging, right? |
| 04:21.20 | rwhitby | however, I have an nas100d board which I have confirmed has srst but no trst. Is that any good? |
| 04:40.17 | *** join/#openjtag cbrake_away (n=cbrake@oh-69-34-21-229.sta.embarqhsd.net) [NETSPLIT VICTIM] |
| 04:57.03 | sn9 | rwhitby: neither srst nor trst? |
| 04:57.25 | rwhitby | sn9: dsmg600 has neither |
| 04:57.30 | sn9 | hmm |
| 04:57.33 | rwhitby | nas100d has srst but no trst |
| 04:57.59 | rwhitby | I think I've found srst on the nslu2, but not trst yet. |
| 04:59.37 | sn9 | after some experimentation with openocd on this board, i deduce that it is not really possible to halt the cpu without both |
| 04:59.40 | sn9 | right? |
| 05:00.23 | rwhitby | I could get the nas100d to halt immediately after sreset, and then resume, but it hung when decompressing the linux kernel, so something's not quite right there. |
| 05:00.34 | rwhitby | which board are you working on? |
| 05:00.55 | *** join/#openjtag jkilb_ (n=jkilb@p5B2080A7.dip0.t-ipconnect.de) |
| 05:01.32 | sn9 | airlink101 ar625w, a.k.a. gemtek wrtm-179gn, a.k.a. netgear wnr854t |
| 05:02.47 | sn9 | the wiggler clone i have does not provide separate signals for srst and trst |
| 05:03.42 | sn9 | i cannot poll the cpu unless the single inverted signal is wired to both on the board |
| 05:03.59 | sn9 | but i still don't think it halts properly |
| 05:05.42 | sn9 | i'm thinking that openocd needs to be able to send one signal without sending the other |
| 05:05.42 | sn9 | am i right? |
| 05:08.23 | sn9 | rwhitby: openocd reports that the cpu is halted, and poll always gives the same pc reading, but mdb/mdw give nothing but zeroes, but the disassembler sees what's really there |
| 05:10.12 | rwhitby | sn9: I'm not skilled enough in openocd to answer your question. |
| 05:10.45 | sn9 | the other possibility is that the need for both signals is an openocd quirk |
| 05:11.42 | sn9 | even if you don't know the ins and outs of openocd, can you confirm the roles of the two reset signals? |
| 05:13.16 | *** join/#openjtag rd_ (n=dr@vnsecurity.net) |
| 05:14.47 | sn9 | rwhitby: ^ |
| 05:15.48 | rwhitby | trst is for the tap state machine, srst is for the processor. |
| 05:16.54 | rwhitby | trst is optional in jtag. If the pin is not available, the test logic can be reset by clocking in a reset instruction synchronously. |
| 05:17.19 | sn9 | how would resetting both differ from only resetting the cpu? |
| 05:23.17 | sn9 | rwhitby: ^ |
| 05:23.51 | rwhitby | resetting the cpu does not necessarily reset the tap logic |
| 05:25.09 | sn9 | right, but what would be the application differences in resetting both vs. cpu only? |
| 05:27.03 | sn9 | to halt the cpu for memory reads, etc., would one want to reset both, or just the cpu? |
| 05:29.09 | sn9 | rwhitby: ^ |
| 05:29.50 | rwhitby | reseting the cpu (with srst) means your board reboots |
| 05:30.08 | sn9 | so both? |
| 05:30.18 | rwhitby | reseting the tap logic just puts it in a known state for jtag operations - it should not affect the running of applications |
| 05:30.28 | sn9 | ah, so trst only |
| 05:30.46 | rwhitby | you halt the cpu by clocking in a jtag instruction which halts the cpu |
| 05:30.55 | rwhitby | not by trst or srst |
| 05:31.29 | sn9 | ok, so i may be dealing with two separate problems |
| 05:33.02 | sn9 | but then, why would openocd (or anything else) require the presence of srst to halt? |
| 05:34.33 | sn9 | if srst does nothing except reboot, wouldn't it be just as optional as trst? |
| 05:34.52 | sn9 | rwhitby: ^ |
| 05:36.31 | rwhitby | For some reason, ixp42x needs to be able to reset the target to be able to debug. You need srst to reset the target. |
| 05:37.00 | rwhitby | I suggest reading xscale.c for the answer .. |
| 05:38.01 | sn9 | ah, arm926e-js/feroceon seem to be the same way |
| 05:39.21 | sn9 | so the clocking in of the tap reset instruction is the missing link in openocd, then |
| 05:40.28 | sn9 | the jtag chain cannot be read unless both srst and trst are connected. is that normal? |
| 05:40.32 | sn9 | rwhitby: ^ |
| 05:41.29 | rwhitby | " clocking in of the tap reset instruction" is not what I said |
| 05:41.54 | sn9 | [Mon 05 Nov 2007 09:16:39 PM PST] = <rwhitby> trst is optional in jtag. If the pin is not available, the test logic can be reset by clocking in a reset instruction synchronously. |
| 05:41.57 | rwhitby | reading the jtag chain is independent of both srst and trst |
| 05:42.28 | rwhitby | ah, ok, I thought you were talking about halt. |
| 05:42.48 | rwhitby | <rwhitby> you halt the cpu by clocking in a jtag instruction which halts the cpu |
| 05:43.30 | rwhitby | you should be able to perform jtag operations without either trst or srst. Note that I didn't say you should be able to halt or debug, just perform jtag operations. |
| 05:43.47 | sn9 | so, the reset requirements just to read the chain are a quirk of this core? |
| 05:46.12 | sn9 | rwhitby: ^ |
| 05:46.52 | rwhitby | dunno |
| 05:47.39 | sn9 | well, would it be possible to read the chain on a dsmg600, for example? |
| 05:49.40 | sn9 | rwhitby: ^ |
| 05:52.40 | rwhitby | <rwhitby> reading the jtag chain is independent of both srst and trst |
| 05:53.00 | sn9 | i'll take that as a yes |
| 05:53.48 | rwhitby | well, according to the jtag standard reading the chain is independent of srst and trst (as far as I remember). but that doesn't meant that it works on a dsmg600 |
| 05:54.06 | sn9 | did you try? |
| 06:00.59 | rwhitby | scan_chain gave the correct result on the dsmg600 |
| 06:01.30 | rwhitby | I didn't try much else. |
| 06:01.52 | sn9 | hmm |
| 06:02.27 | sn9 | using openocd or openwince? |
| 06:09.03 | rwhitby | openocd - see the irc log from yesterday |
| 06:09.23 | rwhitby | http://logs.nslu2-linux.org/livelogs/openjtag-prev.txt |
| 06:33.03 | *** join/#openjtag pleemans (n=peter@leemanpe.ugent.be) |
| 07:16.47 | *** join/#openjtag d3 (n=dr@vnsecurity.net) |
| 08:10.21 | drath | sn9: check the linkstation wiki for a thread about using the openocd |
| 08:10.44 | drath | sn9: iirc the thread started with someone mentioning how he found the jtag lines |
| 08:10.53 | sn9 | i have made progress |
| 08:11.02 | drath | ah, ok |
| 08:11.14 | sn9 | there appears to be a power issue when using the jtag connector |
| 08:17.43 | drath | you're using a wiggler, right? |
| 08:18.12 | sn9 | wiggler clone |
| 08:28.47 | drath | ok, and what exactly is the "power issue"? |
| 08:31.14 | sn9 | just a sec |
| 09:03.50 | rwhitby | drath: is ixp42x debugging possible with only srst and no trst ? |
| 09:24.43 | drath | rwhitby: maybe |
| 09:25.22 | drath | rwhitby: in theory moving to Test-Logic-Reset should have the same effect as asserting TRST, but what really happens depends on the implementation |
| 09:25.56 | drath | rwhitby: if you know for sure that you have a working nsrst try "reset_config srst_only" |
| 09:26.19 | drath | rwhitby: that should cause the openocd to use a T-L-R reset whenever nTRST is requested |
| 09:31.41 | rwhitby | drath: I've tried that, and I seem to be able to halt on reset, then resume. The bootloader (redboot) boots, then it loads Apex (second stage bootloader), then it loads the kernel. But the kernel hangs immediately after the decompress. |
| 09:31.49 | rwhitby | any ideas why that would happen? |
| 09:36.08 | drath | a XScale JTAG debugger needs a current copy of the exception vectors |
| 09:36.45 | drath | you need to set up a breakpoint at a point where the exception vectors are already updated, but interrupts not yet enabled |
| 09:36.50 | drath | the procedure is the same as for the bdi |
| 09:37.07 | drath | iirc there even was a patch in mainline once that included a breakpoint for the bdi right in the kernel image |
| 09:37.51 | drath | anyway, if you've managed to halt at reset this means that everything's fine |
| 09:37.57 | drath | that's the really tricky part |
| 09:44.22 | rwhitby | is there any way to halt on the ixp42x other than at reset? |
| 09:44.45 | rwhitby | drath: is there any doco on the procedure for the bdi? |
| 09:46.09 | drath | rwhitby: well, you need to reset once, to install the debug handler |
| 09:46.16 | drath | rwhitby: after that the "halt" command should work |
| 09:47.00 | drath | rwhitby: there used to be some docs regarding bdi + linux, just can't find it right now |
| 09:47.49 | drath | rwhitby: google for ultsol bdi2000 linux |
| 09:47.57 | drath | rwhitby: they've got a pdf explaining it |
| 09:49.09 | rwhitby | drath: got it, thx. |
| 09:50.37 | rwhitby | drath: so is it the case that if I hit a breakpoint in the kernel where the exception vectors are updated, but interrupts are not yet enabled, then openocd will get the new exception vector table, and then everything will be fine from then on, allowing me to halt and resume at will in kernel and applications? |
| 09:50.38 | drath | rwhitby: ka6sox mentioned in #linkstationwiki that he was the one who used a bdi on the nslu2 |
| 09:50.58 | drath | rwhitby: yeah, that's the idea, and i've verified it once |
| 09:51.54 | drath | rwhitby: and it's not only interrupts, but other exceptions as well, like page faults |
| 09:51.58 | rwhitby | drath: I'll check with ka6sox - I didn't know he had access to a bdi, and I've never heard him mention debugging the slug at that level. |
| 09:52.31 | drath | 00:48 < rwhitby> sn9: in nslu2 land we've only used wince jtag tools to reflash. no debugging using openocd (I'm working on that with drath on dsmg600 right now) |
| 09:52.34 | drath | 00:49 < ka6sox-work> what I use was an abatron for mine. |
| 09:53.02 | rwhitby | drath: I think that was still only for reflash, not for debugging. |
| 09:53.17 | rwhitby | but I will check with him anyway. |
| 09:53.28 | drath | rwhitby: i don't think the bdi supports flashing without debugging |
| 09:57.08 | sn9 | drath: ok, what i for awhile thought was trst on the board turns out to be a jtag-enable signal |
| 09:57.33 | sn9 | it seems to want a buffered high signal from the host |
| 09:57.46 | drath | sn9: heh, ok |
| 09:58.15 | drath | sn9: but that shouldn't cause problems - ntrst is supposed to be driven high all the time |
| 09:59.05 | sn9 | wiring it to vcc on either target or host isn't good enough |
| 10:00.16 | sn9 | wiring it to srst caused the problems i experienced earlier |
| 10:05.31 | rwhitby | drath: once the ixp42x is reset and halted, I should be able to probe the flash, right? |
| 10:06.25 | sn9 | when i first wired it to the host's vcc, halting, polling, and memory reads suddenly worked, but flash probing no longer did |
| 10:07.04 | sn9 | eventually, examination of the chain started failing again |
| 10:07.24 | drath | rwhitby: you might have to configure the memory controller |
| 10:07.46 | rwhitby | http://pastebin.ca/763283 <- is that all set up correctly so far? |
| 10:08.35 | rwhitby | drath: you mean like in https://lists.berlios.de/pipermail/openocd-development/2007-September/000334.html ? |
| 10:09.59 | drath | rwhitby: i've never had the chance to work on bigendian hw, but yeah, that's it |
| 10:10.16 | rwhitby | > flash probe 0 |
| 10:10.16 | rwhitby | probing failed for flash bank '#0' at 0x50000000 |
| 10:10.16 | rwhitby | > reg XSCALE_CTRL 0xF8 |
| 10:10.16 | rwhitby | XSCALE_CTRL (/32): 0x000000f8 |
| 10:10.18 | rwhitby | > mww 0xc4000000 0xbd113c42 |
| 10:10.18 | rwhitby | > flash probe 0 |
| 10:10.21 | rwhitby | flash 'cfi' found at 0x50000000 |
| 10:10.22 | rwhitby | success! |
| 10:10.26 | drath | rwhitby: great :) |
| 10:10.42 | drath | rwhitby: i have some bugfixes in my local tree that i still need to test |
| 10:10.50 | rwhitby | so should openocd do that automatically for ixp42x big endian as the poster suggests? |
| 10:10.56 | drath | rwhitby: one causes problems for half-word writes |
| 10:11.01 | drath | rwhitby: no, it shouldn't, imho |
| 10:11.36 | drath | rwhitby: it definitely shouldn't do the memory write, and one could argue about the control register write |
| 10:11.57 | drath | rwhitby: that's what we have target_script for |
| 10:12.09 | drath | rwhitby: you define a script that's executed on every debug-entry after a reset |
| 10:12.17 | drath | rwhitby: that way you can automate such things |
| 10:12.40 | rwhitby | is there scope for such common scripts to be distributed with openocd? |
| 10:13.21 | drath | rwhitby: there's a doc directory with some example configs, we could include such scripts as well |
| 10:13.45 | rwhitby | so now that I've found the flash, should I be able to program it (albeit slowly) without worrying about the rest of the working area and memory controller stuff in https://lists.berlios.de/pipermail/openocd-development/2007-September/000339.html ? |
| 10:14.17 | drath | rwhitby: there are some bugs left, and i'm not sure if it's supposed to work atm |
| 10:14.36 | drath | rwhitby: carsten schlote did some work, he's maintaining a xscale-be tree inside the openocd repository |
| 10:15.13 | rwhitby | drath: my eventual goal is to be able to reflash an nslu2 from Eclipse via openocd ... |
| 10:15.13 | rwhitby | (and debug code on it too) |
| 10:25.52 | rwhitby | drath: is disassemble supported for xscale? |
| 10:29.04 | drath | rwhitby: yeah |
| 10:29.29 | rwhitby | > disassemble 0xf4 |
| 10:29.29 | rwhitby | Command disassemble not found |
| 10:29.41 | drath | armv4_5 disassemble <address> <count> |
| 10:29.49 | rwhitby | aha, thx. |
| 10:29.56 | drath | the command is common to all targets implementing the armv4/5 architecture |
| 10:29.58 | rwhitby | BTW, stepping through the bootloader seems to be working |
| 10:30.05 | drath | cool |
| 10:32.20 | rwhitby | <rwhitby> ka6sox: have you used a bdi to debug a slug? |
| 10:32.20 | rwhitby | <ka6sox> only to program it |
| 10:33.27 | *** join/#openjtag ka6sox (n=ka6sox@nslu2-linux/ka6sox) |
| 10:33.46 | ka6sox | oh my...the gang's all here :D |
| 10:34.02 | rwhitby | ka6sox: I'm currently single-stepping redboot on the nas100d via openocd |
| 10:34.22 | ka6sox | okay what pod are you using? |
| 10:34.27 | rwhitby | (thanks to drath's help) |
| 10:34.33 | rwhitby | currently the amontec jtagkey |
| 10:34.44 | ka6sox | I looked at that... |
| 10:34.46 | rwhitby | can't use the digilent, cause you need srst support. |
| 10:34.53 | ka6sox | right |
| 10:35.23 | rwhitby | will try and get it working with the openmoko debug board, which I believe works just like the jtagkey |
| 10:35.25 | ka6sox | so you are using the 20 pin connector on the NAS100D? |
| 10:35.28 | rwhitby | yes |
| 10:35.35 | ka6sox | k |
| 10:35.50 | rwhitby | doesn't work on the dsmg600 cause it doesn't have srst connected |
| 10:36.11 | ka6sox | I had a bricked redboot on a slug once and used the BDI to reprogram it. |
| 10:36.48 | rwhitby | ka6sox: my eventual goal is to be able to reflash and single step the slug from Eclipse via openocd |
| 10:38.09 | ka6sox | that would be helpful. |
| 10:38.59 | rwhitby | hmm - not stable yet: |
| 10:39.00 | rwhitby | Warning: jtag.c:1132 jtag_read_buffer(): value captured during scan didn't pass the requested check: captured: 0x00 check_value: 0x02 check_mask: 0x06 |
| 10:39.16 | rwhitby | Error: xscale.c:604 xscale_write_rx(): JTAG error while writing RX |
| 10:39.20 | rwhitby | and openocd exits |
| 10:40.46 | drath | rwhitby: try reducing the jtag frequency by using a higher jtag_speed divisor |
| 10:41.09 | drath | rwhitby: a ft2232 jtag works with 6mhz / (1+jtag_speed) |
| 10:41.50 | drath | rwhitby: effective speed is rarely >2mhz, so a setting of 2 shouldn't cause much performance loss |
| 10:42.05 | drath | rwhitby: and the lower frequency improves stability |
| 10:43.16 | rwhitby | yep, that fixed it, thx. |
| 10:43.33 | ka6sox | I was wondering how fast you were clocking it. |
| 10:43.42 | ka6sox | I've rarely used >2mhz |
| 10:46.02 | drath | on an arm9 2mhz gives you ~100kb/s max download speed to ram, which should be good for most purposes |
| 10:46.19 | rwhitby | drath: something is weird - the code I am single stepping has no branches, yet the PC stepped up to 0xf4 then 0xf8 then repeats 0xf4, 0xf8 indefinitely. Those two locations have SUBS and SUBNE instructions. |
| 10:46.29 | rwhitby | 0x000000f4 0xe2511001 SUBS r1, r1, #0x1 |
| 10:46.29 | rwhitby | 0x000000f8 0x124ff00c SUBNE r15, r15, #0xc |
| 10:46.40 | drath | r15 is the pc |
| 10:46.59 | rwhitby | heh - shows how much I know about arm assembly :-) |
| 10:47.06 | drath | 0xf8 subtracts 12 from the pc, and the pc is defined as address of the instruction + 8 |
| 10:47.20 | drath | so 0xf8 is a branch to the preceding instruction |
| 10:47.23 | rwhitby | ok, it is a loop counting down r1. |
| 10:47.28 | drath | right |
| 10:48.11 | rwhitby | ok, r1 is decrementing correctly. |
| 11:20.24 | *** join/#openjtag rd_ (n=dr@vnsecurity.net) |
| 11:28.21 | *** join/#openjtag drath_ (i=vmaster@p5B07C511.dip.t-dialin.net) |
| 12:06.12 | *** join/#openjtag d3 (n=dr@vnsecurity.net) |
| 13:59.29 | *** join/#openjtag prpplague (n=dave@mail.americanmicrosystems.com) |
| 17:32.13 | *** join/#openjtag rd_ (n=dr@vnsecurity.net) |
| 17:45.32 | *** join/#openjtag rd_ (n=dr@vnsecurity.net) |
| 17:51.27 | *** join/#openjtag rd_ (n=dr@vnsecurity.net) [NETSPLIT VICTIM] |
| 17:51.27 | *** join/#openjtag toi (n=pleemans@d5152D3B4.access.telenet.be) |
| 17:52.13 | *** join/#openjtag nslu2-log_ (n=nslu2-lo@nslu2-linux/dyoung) |
| 18:39.08 | *** join/#openjtag rd_ (n=dr@vnsecurity.net) |
| 18:41.26 | *** join/#openjtag Bitmaster (n=Bitmaste@c-5d61e253.325-1-64736c12.cust.bredbandsbolaget.se) |
| 18:59.06 | *** join/#openjtag jkilb_ (n=jkilb@p5B2080A7.dip0.t-ipconnect.de) |
| 20:24.56 | *** join/#openjtag pleemans (n=peter@d51A5E76A.access.telenet.be) |