**** BEGIN LOGGING AT Tue Nov 06 02:59:56 2007 Nov 06 04:20:24 drath: ping Nov 06 04:20:57 drath: I confirmed that trst and srst are not connected on the dsmg600 board, so that makes it pretty useless for ixp42x debugging, right? Nov 06 04:21:20 however, I have an nas100d board which I have confirmed has srst but no trst. Is that any good? Nov 06 04:57:02 rwhitby: neither srst nor trst? Nov 06 04:57:25 sn9: dsmg600 has neither Nov 06 04:57:30 hmm Nov 06 04:57:32 nas100d has srst but no trst Nov 06 04:57:58 I think I've found srst on the nslu2, but not trst yet. Nov 06 04:59:37 after some experimentation with openocd on this board, i deduce that it is not really possible to halt the cpu without both Nov 06 04:59:40 right? Nov 06 05:00:23 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. Nov 06 05:00:34 which board are you working on? Nov 06 05:01:31 airlink101 ar625w, a.k.a. gemtek wrtm-179gn, a.k.a. netgear wnr854t Nov 06 05:02:46 the wiggler clone i have does not provide separate signals for srst and trst Nov 06 05:03:41 i cannot poll the cpu unless the single inverted signal is wired to both on the board Nov 06 05:03:59 but i still don't think it halts properly Nov 06 05:05:26 i'm thinking that openocd needs to be able to send one signal without sending the other Nov 06 05:05:30 am i right? Nov 06 05:08:23 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 Nov 06 05:10:11 sn9: I'm not skilled enough in openocd to answer your question. Nov 06 05:10:44 the other possibility is that the need for both signals is an openocd quirk Nov 06 05:11:42 even if you don't know the ins and outs of openocd, can you confirm the roles of the two reset signals? Nov 06 05:14:45 rwhitby: ^ Nov 06 05:15:46 trst is for the tap state machine, srst is for the processor. Nov 06 05:16:51 trst is optional in jtag. If the pin is not available, the test logic can be reset by clocking in a reset instruction synchronously. Nov 06 05:17:16 how would resetting both differ from only resetting the cpu? Nov 06 05:23:14 rwhitby: ^ Nov 06 05:23:49 resetting the cpu does not necessarily reset the tap logic Nov 06 05:25:05 right, but what would be the application differences in resetting both vs. cpu only? Nov 06 05:26:59 to halt the cpu for memory reads, etc., would one want to reset both, or just the cpu? Nov 06 05:29:06 rwhitby: ^ Nov 06 05:29:46 reseting the cpu (with srst) means your board reboots Nov 06 05:30:05 so both? Nov 06 05:30:11 reseting the tap logic just puts it in a known state for jtag operations - it should not affect the running of applications Nov 06 05:30:24 ah, so trst only Nov 06 05:30:42 you halt the cpu by clocking in a jtag instruction which halts the cpu Nov 06 05:30:52 not by trst or srst Nov 06 05:31:26 ok, so i may be dealing with two separate problems Nov 06 05:32:54 but then, why would openocd (or anything else) require the presence of srst to halt? Nov 06 05:34:28 if srst does nothing except reboot, wouldn't it be just as optional as trst? Nov 06 05:34:49 rwhitby: ^ Nov 06 05:36:27 For some reason, ixp42x needs to be able to reset the target to be able to debug. You need srst to reset the target. Nov 06 05:36:57 I suggest reading xscale.c for the answer .. Nov 06 05:37:57 ah, arm926e-js/feroceon seem to be the same way Nov 06 05:39:18 so the clocking in of the tap reset instruction is the missing link in openocd, then Nov 06 05:40:24 the jtag chain cannot be read unless both srst and trst are connected. is that normal? Nov 06 05:40:26 rwhitby: ^ Nov 06 05:41:25 " clocking in of the tap reset instruction" is not what I said Nov 06 05:41:50 [Mon 05 Nov 2007 09:16:39 PM PST] = trst is optional in jtag. If the pin is not available, the test logic can be reset by clocking in a reset instruction synchronously. Nov 06 05:41:54 reading the jtag chain is independent of both srst and trst Nov 06 05:42:25 ah, ok, I thought you were talking about halt. Nov 06 05:42:44 you halt the cpu by clocking in a jtag instruction which halts the cpu Nov 06 05:43:26 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. Nov 06 05:43:43 so, the reset requirements just to read the chain are a quirk of this core? Nov 06 05:46:09 rwhitby: ^ Nov 06 05:46:46 dunno Nov 06 05:47:34 well, would it be possible to read the chain on a dsmg600, for example? Nov 06 05:49:34 rwhitby: ^ Nov 06 05:52:36 reading the jtag chain is independent of both srst and trst Nov 06 05:52:56 i'll take that as a yes Nov 06 05:53:40 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 Nov 06 05:53:58 did you try? Nov 06 06:00:56 scan_chain gave the correct result on the dsmg600 Nov 06 06:01:25 I didn't try much else. Nov 06 06:01:49 hmm Nov 06 06:02:24 using openocd or openwince? Nov 06 06:08:58 openocd - see the irc log from yesterday Nov 06 06:09:19 http://logs.nslu2-linux.org/livelogs/openjtag-prev.txt Nov 06 08:10:21 sn9: check the linkstation wiki for a thread about using the openocd Nov 06 08:10:44 sn9: iirc the thread started with someone mentioning how he found the jtag lines Nov 06 08:10:53 i have made progress Nov 06 08:11:01 ah, ok Nov 06 08:11:13 there appears to be a power issue when using the jtag connector Nov 06 08:17:42 you're using a wiggler, right? Nov 06 08:18:12 wiggler clone Nov 06 08:28:46 ok, and what exactly is the "power issue"? Nov 06 08:31:14 just a sec Nov 06 09:03:50 drath: is ixp42x debugging possible with only srst and no trst ? Nov 06 09:24:43 rwhitby: maybe Nov 06 09:25:22 rwhitby: in theory moving to Test-Logic-Reset should have the same effect as asserting TRST, but what really happens depends on the implementation Nov 06 09:25:56 rwhitby: if you know for sure that you have a working nsrst try "reset_config srst_only" Nov 06 09:26:19 rwhitby: that should cause the openocd to use a T-L-R reset whenever nTRST is requested Nov 06 09:31:42 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. Nov 06 09:31:49 any ideas why that would happen? Nov 06 09:36:07 a XScale JTAG debugger needs a current copy of the exception vectors Nov 06 09:36:45 you need to set up a breakpoint at a point where the exception vectors are already updated, but interrupts not yet enabled Nov 06 09:36:50 the procedure is the same as for the bdi Nov 06 09:37:07 iirc there even was a patch in mainline once that included a breakpoint for the bdi right in the kernel image Nov 06 09:37:51 anyway, if you've managed to halt at reset this means that everything's fine Nov 06 09:37:57 that's the really tricky part Nov 06 09:44:22 is there any way to halt on the ixp42x other than at reset? Nov 06 09:44:45 drath: is there any doco on the procedure for the bdi? Nov 06 09:46:09 rwhitby: well, you need to reset once, to install the debug handler Nov 06 09:46:16 rwhitby: after that the "halt" command should work Nov 06 09:47:00 rwhitby: there used to be some docs regarding bdi + linux, just can't find it right now Nov 06 09:47:49 rwhitby: google for ultsol bdi2000 linux Nov 06 09:47:57 rwhitby: they've got a pdf explaining it Nov 06 09:49:09 drath: got it, thx. Nov 06 09:50:37 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? Nov 06 09:50:37 rwhitby: ka6sox mentioned in #linkstationwiki that he was the one who used a bdi on the nslu2 Nov 06 09:50:58 rwhitby: yeah, that's the idea, and i've verified it once Nov 06 09:51:54 rwhitby: and it's not only interrupts, but other exceptions as well, like page faults Nov 06 09:51:58 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. Nov 06 09:52:31 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) Nov 06 09:52:34 00:49 < ka6sox-work> what I use was an abatron for mine. Nov 06 09:53:02 drath: I think that was still only for reflash, not for debugging. Nov 06 09:53:17 but I will check with him anyway. Nov 06 09:53:28 rwhitby: i don't think the bdi supports flashing without debugging Nov 06 09:57:08 drath: ok, what i for awhile thought was trst on the board turns out to be a jtag-enable signal Nov 06 09:57:33 it seems to want a buffered high signal from the host Nov 06 09:57:45 sn9: heh, ok Nov 06 09:58:15 sn9: but that shouldn't cause problems - ntrst is supposed to be driven high all the time Nov 06 09:59:05 wiring it to vcc on either target or host isn't good enough Nov 06 10:00:15 wiring it to srst caused the problems i experienced earlier Nov 06 10:05:31 drath: once the ixp42x is reset and halted, I should be able to probe the flash, right? Nov 06 10:06:25 when i first wired it to the host's vcc, halting, polling, and memory reads suddenly worked, but flash probing no longer did Nov 06 10:07:04 eventually, examination of the chain started failing again Nov 06 10:07:25 rwhitby: you might have to configure the memory controller Nov 06 10:07:46 http://pastebin.ca/763283 <- is that all set up correctly so far? Nov 06 10:08:35 drath: you mean like in https://lists.berlios.de/pipermail/openocd-development/2007-September/000334.html ? Nov 06 10:09:59 rwhitby: i've never had the chance to work on bigendian hw, but yeah, that's it Nov 06 10:10:16 > flash probe 0 Nov 06 10:10:16 probing failed for flash bank '#0' at 0x50000000 Nov 06 10:10:16 > reg XSCALE_CTRL 0xF8 Nov 06 10:10:16 XSCALE_CTRL (/32): 0x000000f8 Nov 06 10:10:18 > mww 0xc4000000 0xbd113c42 Nov 06 10:10:18 > flash probe 0 Nov 06 10:10:21 flash 'cfi' found at 0x50000000 Nov 06 10:10:22 success! Nov 06 10:10:26 rwhitby: great :) Nov 06 10:10:42 rwhitby: i have some bugfixes in my local tree that i still need to test Nov 06 10:10:50 so should openocd do that automatically for ixp42x big endian as the poster suggests? Nov 06 10:10:56 rwhitby: one causes problems for half-word writes Nov 06 10:11:01 rwhitby: no, it shouldn't, imho Nov 06 10:11:36 rwhitby: it definitely shouldn't do the memory write, and one could argue about the control register write Nov 06 10:11:57 rwhitby: that's what we have target_script for Nov 06 10:12:09 rwhitby: you define a script that's executed on every debug-entry after a reset Nov 06 10:12:16 rwhitby: that way you can automate such things Nov 06 10:12:40 is there scope for such common scripts to be distributed with openocd? Nov 06 10:13:21 rwhitby: there's a doc directory with some example configs, we could include such scripts as well Nov 06 10:13:45 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 ? Nov 06 10:14:17 rwhitby: there are some bugs left, and i'm not sure if it's supposed to work atm Nov 06 10:14:36 rwhitby: carsten schlote did some work, he's maintaining a xscale-be tree inside the openocd repository Nov 06 10:14:52 drath: my eventual goal is to be able to reflash an nslu2 from Eclipse via openocd ... Nov 06 10:15:03 (and debug code on it too) Nov 06 10:25:52 drath: is disassemble supported for xscale? Nov 06 10:29:04 rwhitby: yeah Nov 06 10:29:29 > disassemble 0xf4 Nov 06 10:29:29 Command disassemble not found Nov 06 10:29:41 armv4_5 disassemble
Nov 06 10:29:48 aha, thx. Nov 06 10:29:56 the command is common to all targets implementing the armv4/5 architecture Nov 06 10:29:58 BTW, stepping through the bootloader seems to be working Nov 06 10:30:05 cool Nov 06 10:32:19 ka6sox: have you used a bdi to debug a slug? Nov 06 10:32:20 only to program it Nov 06 10:33:46 oh my...the gang's all here :D Nov 06 10:34:01 ka6sox: I'm currently single-stepping redboot on the nas100d via openocd Nov 06 10:34:22 okay what pod are you using? Nov 06 10:34:25 (thanks to drath's help) Nov 06 10:34:32 currently the amontec jtagkey Nov 06 10:34:44 I looked at that... Nov 06 10:34:46 can't use the digilent, cause you need srst support. Nov 06 10:34:53 right Nov 06 10:35:23 will try and get it working with the openmoko debug board, which I believe works just like the jtagkey Nov 06 10:35:25 so you are using the 20 pin connector on the NAS100D? Nov 06 10:35:29 yes Nov 06 10:35:35 k Nov 06 10:35:50 doesn't work on the dsmg600 cause it doesn't have srst connected Nov 06 10:36:11 I had a bricked redboot on a slug once and used the BDI to reprogram it. Nov 06 10:36:48 ka6sox: my eventual goal is to be able to reflash and single step the slug from Eclipse via openocd Nov 06 10:38:09 that would be helpful. Nov 06 10:38:59 hmm - not stable yet: Nov 06 10:39:00 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 Nov 06 10:39:16 Error: xscale.c:604 xscale_write_rx(): JTAG error while writing RX Nov 06 10:39:20 and openocd exits Nov 06 10:40:46 rwhitby: try reducing the jtag frequency by using a higher jtag_speed divisor Nov 06 10:41:09 rwhitby: a ft2232 jtag works with 6mhz / (1+jtag_speed) Nov 06 10:41:50 rwhitby: effective speed is rarely >2mhz, so a setting of 2 shouldn't cause much performance loss Nov 06 10:42:05 rwhitby: and the lower frequency improves stability Nov 06 10:43:16 yep, that fixed it, thx. Nov 06 10:43:33 I was wondering how fast you were clocking it. Nov 06 10:43:42 I've rarely used >2mhz Nov 06 10:46:02 on an arm9 2mhz gives you ~100kb/s max download speed to ram, which should be good for most purposes Nov 06 10:46:19 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. Nov 06 10:46:29 0x000000f4 0xe2511001 SUBS r1, r1, #0x1 Nov 06 10:46:29 0x000000f8 0x124ff00c SUBNE r15, r15, #0xc Nov 06 10:46:40 r15 is the pc Nov 06 10:46:59 heh - shows how much I know about arm assembly :-) Nov 06 10:47:05 0xf8 subtracts 12 from the pc, and the pc is defined as address of the instruction + 8 Nov 06 10:47:20 so 0xf8 is a branch to the preceding instruction Nov 06 10:47:23 ok, it is a loop counting down r1. Nov 06 10:47:28 right Nov 06 10:48:11 ok, r1 is decrementing correctly. **** BEGIN LOGGING AT Tue Nov 06 17:51:34 2007 **** ENDING LOGGING AT Wed Nov 07 02:59:57 2007