**** BEGIN LOGGING AT Mon Nov 05 02:59:57 2007 Nov 05 07:40:15 anyone used openocd to access xscale via jtag? Nov 05 07:40:24 (in particular, ixp42x) Nov 05 07:40:43 drath: any pointers? Nov 05 07:41:50 in particular, I'm looking first to be able to read and program the flash connected to the ixp42x in a D-Link DSM-G600 device (which is much like an NSLU2, except it is has a 20 pin jtag connector on board) Nov 05 07:46:26 hey rwhitby Nov 05 07:46:28 http://openfacts.berlios.de/index-en.phtml?title=OpenOCD_scripts Nov 05 07:46:32 has some example configuration scripts Nov 05 07:46:38 they might be a bit outdated Nov 05 07:47:01 but the documentation at http://openfacts.berlios.de/index-en.phtml?title=OpenOCD_configuration should be ok Nov 05 07:47:47 is this expected? Nov 05 07:47:47 > flash bank cfi 0x50000000 0x01000000 2 2 0 Nov 05 07:47:48 Command bank not found Nov 05 07:48:05 flash banks have to be configured in the .cfg file Nov 05 07:48:26 gotcha Nov 05 07:48:33 the other "flash" commands are available later via telnet/gdb-monitor Nov 05 07:48:49 ok, will try this later tonight (about 2 hours time) - will you be around then? Nov 05 07:49:06 there are some semi-known issues with BE flash access Nov 05 07:49:28 I want to get this working on the DSMG600, then work out how to find the rst line on the nslu2 and get openocd working with the nslu2. Nov 05 07:49:35 rwhitby: yeah, gotta get to the office now, but i'm usually watching my irc window once in a while Nov 05 07:49:59 ok, I'll ping and not expect an immediate response - I do the same myself at work :-) Nov 05 07:50:31 I'll also be work on some Freecom FSG-3 boards too - ixp42x also. Nov 05 07:57:41 drath: does this look right? http://pastebin.ca/762026 Nov 05 07:58:12 where do I find the debug_handler.bin file, and where do I need to put it? Nov 05 08:03:51 ok, got past that - now I can't halt. Nov 05 08:07:05 new log at http://pastebin.ca/762028 Nov 05 08:10:31 rwhitby: is that hardware known to work with JTAG debuggers? Nov 05 08:13:23 the main problem with consumer xscale hardware is that the reset lines often can't be controlled individually Nov 05 08:14:11 the linksys nrv54g for example has the 20pin JTAG header, but that's only useable for boundary-scan, i.e. like wince jtag tools Nov 05 08:19:27 drath: this is the first known use of jtag on this device Nov 05 08:20:47 (and I don't have a schematic of course) Nov 05 08:21:19 we have used wince jtag tools on these types of devices before (like the nslu2) Nov 05 08:21:47 drath: can openocd be used as a wince jtag tools replacement for flash programming even if the lines are not separate? Nov 05 08:21:48 ok, i guess we have to ensure proper operation of the reset signals before we continue Nov 05 08:21:57 rwhitby: no, that's something completely different Nov 05 08:27:09 drath: is there a way I can determine proper operation without physical access to the device and a logic analyser (both of which are at work, and I'm at home accessing the host system remotely) Nov 05 08:28:36 use a .cfg with no reference to the target, i.e. remove the "target ...", "flash ...", "working_area ..." etc. lines Nov 05 08:28:45 that gives you full JTAG control via telnet Nov 05 08:29:47 is there a sequence that you then go through to determine the reset signal operation? Nov 05 08:31:01 using jtag_reset (check help for correct order of arguments) you can assert one of the signals Nov 05 08:31:16 you then declare a variable "var id 32" to hold the idcode Nov 05 08:31:49 ok, so I remove the reset_config, daemon_startup, target, run_and_halt_time and flash commands from the cfg file Nov 05 08:32:58 ok, did "jtag_reset 1 0" then "var id 32" Nov 05 08:34:07 mhh, sorry, start with jtag_reset 0 0, to have them both deasserted Nov 05 08:34:13 then endstate rti Nov 05 08:34:31 drscan 0 0 Nov 05 08:34:32 var 0 Nov 05 08:34:45 var should now hold the IDCODE Nov 05 08:34:50 id (1 fields): Nov 05 08:34:51 0x19277013 (/32) Nov 05 08:35:42 which matches what "scan_chain" reports Nov 05 08:35:51 ok, should be fine Nov 05 08:36:08 now assert trst (jtag_reset 1 0) Nov 05 08:36:13 which reset_config should I be using? Nov 05 08:36:14 and scan again: drscan 0 0 Nov 05 08:36:28 trst_and_srst Nov 05 08:36:31 nothing else Nov 05 08:36:38 is that the default? Nov 05 08:36:55 not sure, sorry, haven't looked at the lowlevel code for quite a while Nov 05 08:37:03 ok, will start again with that Nov 05 08:38:50 which jtag interface are you using? Nov 05 08:39:22 amontec jtag key Nov 05 08:39:39 ok, last command gave: Nov 05 08:39:39 Warning: jtag.c:557 jtag_add_dr_scan(): JTAG command queued, while TRST is low (TAP in reset) Nov 05 08:39:56 that's fine - we want no valid result here Nov 05 08:40:01 check the content of var Nov 05 08:40:14 > var 0 Nov 05 08:40:16 id (1 fields): Nov 05 08:40:16 0x19277013 (/32) Nov 05 08:40:34 trst is still asserted Nov 05 08:41:02 humm... i would've expected a 0x0 or 0xffffffff depending on the pullup/down Nov 05 08:42:21 in response to jtag_reset 1 0, I got: Nov 05 08:42:25 Debug: ft2232.c:963 jtagkey_reset(): trst: 1, srst: 0, high_output: 0x08, high_direction: 0x0f Nov 05 08:43:10 I see, you want to hold trst low, and expect a tristate tdo output Nov 05 08:43:11 ok, try "endstate tlr" "drscan 0 0" again Nov 05 08:43:46 same result Nov 05 08:44:01 hum, trst might be driven high hard on your board Nov 05 08:44:12 or not connected at all Nov 05 08:44:31 ok, let's try srst Nov 05 08:44:34 quite possible - I'll take a look at the board tomorrow - I haven't traced any signals on it. Nov 05 08:44:41 jtag_reset 0 1 Nov 05 08:44:45 drscan 0 0 Nov 05 08:44:55 make sure endstate is "tlr" Nov 05 08:44:58 not "rti" as before Nov 05 08:45:29 Warning: jtag.c:647 jtag_add_dr_scan(): scan data for a device in BYPASS Nov 05 08:45:35 > var 0 Nov 05 08:45:35 id (1 fields): Nov 05 08:45:35 0x19277013 (/32) Nov 05 08:46:19 do you have a way to verify if the device is being held in reset? Nov 05 08:47:52 I have remote serial console Nov 05 08:48:51 ok, can you check if it's running right now? Nov 05 08:49:13 if not, use "jtag_reset 0 0" to let the device out of reset - should be running then Nov 05 08:50:33 hmm - can't contact it. I might not have hooked the serial back up after attaching jtag Nov 05 08:51:02 ok, so I can verify srst tomorrow by looking at serial. trst shouldn't affect running operation, right? Nov 05 08:51:02 ok, well, at least we now know two things: Nov 05 08:51:07 - trst doesn't work as expeced Nov 05 08:51:17 - srst at least doesn't assert trst at well Nov 05 08:51:27 we might be able to live without trst, gotta look at the code this evening Nov 05 08:52:16 ok, and I will repeat all this in about 18 hours time at lunch tomorrow while at the physical device and with a logic probe in hand. Nov 05 08:52:53 drath: thanks for your help - will try and contact you again in 18 to 24 hours time. Nov 05 08:56:13 all right, just ping me, and if i don't answer leave me a message Nov 05 08:57:16 will do, thx. Nov 05 15:52:50 Error: arm7_9_common.c:562 arm7_9_execute_sys_speed(): timeout waiting for SYSCOMP & DBGACK, last DBG_STATUS: 0 Nov 05 15:52:50 Error: armv4_5.c:591 armv4_5_run_algorithm(): timeout waiting for algorithm to complete, trying to halt target Nov 05 15:52:50 Error: armv4_5.c:600 armv4_5_run_algorithm(): target didn't reenter debug state, exiting Nov 05 15:54:08 that's what i get when i try to use "flash write 0 foo 0x7f0000" Nov 05 15:54:45 how do i fix that? Nov 05 15:56:35 this is using a wiggler clone, btw Nov 05 15:57:14 which target? Nov 05 15:57:28 marvell feroceon 88f5181l Nov 05 15:58:03 the feroceon is barely supported - the guys from linkstationwiki reported once successful flashing, using no working_area Nov 05 15:58:36 ah, so it's the working_area part that's failing? Nov 05 15:58:51 well, resume doesn't work Nov 05 15:59:06 and when using a working_area, the target is resumed, to execute the flash algorithm Nov 05 15:59:14 oh Nov 05 15:59:25 without a working_area individual memory accesses are used Nov 05 15:59:29 that's a lot slower Nov 05 15:59:40 but at least single memory accesses seem to work on the feroceon Nov 05 16:00:29 i'm trying to do this while pc points to garbage, btw Nov 05 16:01:20 in that case you should first check if the target really halted by issuing multiple "poll" commands Nov 05 16:03:17 cpsr and pc do not change when i do that Nov 05 16:03:52 armv4_5 disassemble says UNDEFINED INSTRUCTION Nov 05 16:05:18 ok, you'd get a "target running" or something like that if there was a problem Nov 05 16:05:24 try "mdw 0x0" Nov 05 16:05:47 if that gives the same result after several tries you should be fine Nov 05 16:06:39 it does, but the SYSCOMP & DBGACK thing appears in the log each time Nov 05 16:07:02 it produces zeroes, btw Nov 05 16:08:26 even when disassemble shows crap there Nov 05 16:09:16 well, kind of impossible to know what's going on inside the feroceon Nov 05 16:09:38 they wouldn't even let me see the nda, let alone the information that requires a nda to be signed Nov 05 16:10:24 yeah, marvell has no coherent policies for that kind of thing Nov 05 16:18:47 something interesting i found: Nov 05 16:19:25 http://wiki.dns323.info/hardware:jtag#todo Nov 05 16:19:48 that device is 88f5181l-based, too Nov 05 16:20:15 do you know anything about that patch? Nov 05 16:22:07 drath: ^ Nov 05 16:23:50 also, note the report there that mem access works Nov 05 16:26:08 maybe it has something to do with my need to use "reset_config srst_only combined" in openocd.cfg? **** ENDING LOGGING AT Mon Nov 05 23:50:56 2007 **** BEGIN LOGGING AT Mon Nov 05 23:51:17 2007 **** ENDING LOGGING AT Tue Nov 06 02:59:56 2007