| 05:03.10 | *** join/#openjtag jkilb_ (n=jkilb@p5B20BAE3.dip0.t-ipconnect.de) |
| 05:21.35 | *** join/#openjtag rd_ (n=dr@vnsecurity.net) |
| 06:08.55 | *** join/#openjtag rd_ (n=dr@vnsecurity.net) |
| 06:30.57 | *** join/#openjtag pleemans (n=peter@leemanpe.ugent.be) |
| 06:34.18 | *** join/#openjtag rd_ (n=dr@vnsecurity.net) |
| 06:52.03 | *** join/#openjtag d3 (n=dr@vnsecurity.net) |
| 07:40.15 | rwhitby | anyone used openocd to access xscale via jtag? |
| 07:40.24 | rwhitby | (in particular, ixp42x) |
| 07:40.43 | rwhitby | drath: any pointers? |
| 07:41.50 | rwhitby | 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) |
| 07:46.26 | drath | hey rwhitby |
| 07:46.29 | drath | http://openfacts.berlios.de/index-en.phtml?title=OpenOCD_scripts |
| 07:46.32 | drath | has some example configuration scripts |
| 07:46.38 | drath | they might be a bit outdated |
| 07:47.01 | drath | but the documentation at http://openfacts.berlios.de/index-en.phtml?title=OpenOCD_configuration should be ok |
| 07:47.47 | rwhitby | is this expected? |
| 07:47.48 | rwhitby | > flash bank cfi 0x50000000 0x01000000 2 2 0 |
| 07:47.48 | rwhitby | Command bank not found |
| 07:48.06 | drath | flash banks have to be configured in the .cfg file |
| 07:48.26 | rwhitby | gotcha |
| 07:48.34 | drath | the other "flash" commands are available later via telnet/gdb-monitor |
| 07:48.49 | rwhitby | ok, will try this later tonight (about 2 hours time) - will you be around then? |
| 07:49.07 | drath | there are some semi-known issues with BE flash access |
| 07:49.28 | rwhitby | 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. |
| 07:49.35 | drath | rwhitby: yeah, gotta get to the office now, but i'm usually watching my irc window once in a while |
| 07:49.59 | rwhitby | ok, I'll ping and not expect an immediate response - I do the same myself at work :-) |
| 07:50.31 | rwhitby | I'll also be work on some Freecom FSG-3 boards too - ixp42x also. |
| 07:57.42 | rwhitby | drath: does this look right? http://pastebin.ca/762026 |
| 07:58.12 | rwhitby | where do I find the debug_handler.bin file, and where do I need to put it? |
| 08:03.51 | rwhitby | ok, got past that - now I can't halt. |
| 08:07.05 | rwhitby | new log at http://pastebin.ca/762028 |
| 08:10.31 | drath | rwhitby: is that hardware known to work with JTAG debuggers? |
| 08:13.23 | drath | the main problem with consumer xscale hardware is that the reset lines often can't be controlled individually |
| 08:14.12 | drath | the linksys nrv54g for example has the 20pin JTAG header, but that's only useable for boundary-scan, i.e. like wince jtag tools |
| 08:19.27 | rwhitby | drath: this is the first known use of jtag on this device |
| 08:20.48 | rwhitby | (and I don't have a schematic of course) |
| 08:21.19 | rwhitby | we have used wince jtag tools on these types of devices before (like the nslu2) |
| 08:21.48 | rwhitby | drath: can openocd be used as a wince jtag tools replacement for flash programming even if the lines are not separate? |
| 08:21.48 | drath | ok, i guess we have to ensure proper operation of the reset signals before we continue |
| 08:21.58 | drath | rwhitby: no, that's something completely different |
| 08:27.10 | rwhitby | 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) |
| 08:28.36 | drath | use a .cfg with no reference to the target, i.e. remove the "target ...", "flash ...", "working_area ..." etc. lines |
| 08:28.45 | drath | that gives you full JTAG control via telnet |
| 08:29.47 | rwhitby | is there a sequence that you then go through to determine the reset signal operation? |
| 08:31.01 | drath | using jtag_reset <trst> <srst> (check help for correct order of arguments) you can assert one of the signals |
| 08:31.05 | *** join/#openjtag dwery (n=dwery@nslu2-linux/dwery) |
| 08:31.16 | drath | you then declare a variable "var id 32" to hold the idcode |
| 08:31.50 | rwhitby | ok, so I remove the reset_config, daemon_startup, target, run_and_halt_time and flash commands from the cfg file |
| 08:32.59 | rwhitby | ok, did "jtag_reset 1 0" then "var id 32" |
| 08:34.07 | drath | mhh, sorry, start with jtag_reset 0 0, to have them both deasserted |
| 08:34.13 | drath | then endstate rti |
| 08:34.31 | drath | drscan 0 0 |
| 08:34.32 | drath | var 0 |
| 08:34.46 | drath | var should now hold the IDCODE |
| 08:34.50 | rwhitby | id (1 fields): |
| 08:34.51 | rwhitby | 0x19277013 (/32) |
| 08:35.43 | rwhitby | which matches what "scan_chain" reports |
| 08:35.51 | drath | ok, should be fine |
| 08:36.09 | drath | now assert trst (jtag_reset 1 0) |
| 08:36.13 | rwhitby | which reset_config should I be using? |
| 08:36.14 | drath | and scan again: drscan 0 0 |
| 08:36.29 | drath | trst_and_srst |
| 08:36.32 | drath | nothing else |
| 08:36.38 | rwhitby | is that the default? |
| 08:36.56 | drath | not sure, sorry, haven't looked at the lowlevel code for quite a while |
| 08:37.03 | rwhitby | ok, will start again with that |
| 08:38.50 | drath | which jtag interface are you using? |
| 08:39.22 | rwhitby | amontec jtag key |
| 08:39.39 | rwhitby | ok, last command gave: |
| 08:39.40 | rwhitby | Warning: jtag.c:557 jtag_add_dr_scan(): JTAG command queued, while TRST is low (TAP in reset) |
| 08:39.56 | drath | that's fine - we want no valid result here |
| 08:40.02 | drath | check the content of var |
| 08:40.15 | rwhitby | > var 0 |
| 08:40.17 | rwhitby | id (1 fields): |
| 08:40.17 | rwhitby | 0x19277013 (/32) |
| 08:40.34 | rwhitby | trst is still asserted |
| 08:41.02 | drath | humm... i would've expected a 0x0 or 0xffffffff depending on the pullup/down |
| 08:42.21 | rwhitby | in response to jtag_reset 1 0, I got: |
| 08:42.25 | rwhitby | Debug: ft2232.c:963 jtagkey_reset(): trst: 1, srst: 0, high_output: 0x08, high_direction: 0x0f |
| 08:43.10 | rwhitby | I see, you want to hold trst low, and expect a tristate tdo output |
| 08:43.12 | drath | ok, try "endstate tlr" "drscan 0 0" again |
| 08:43.46 | rwhitby | same result |
| 08:44.01 | drath | hum, trst might be driven high hard on your board |
| 08:44.12 | drath | or not connected at all |
| 08:44.31 | drath | ok, let's try srst |
| 08:44.34 | rwhitby | quite possible - I'll take a look at the board tomorrow - I haven't traced any signals on it. |
| 08:44.41 | drath | jtag_reset 0 1 |
| 08:44.46 | drath | drscan 0 0 |
| 08:44.56 | drath | make sure endstate is "tlr" |
| 08:44.59 | drath | not "rti" as before |
| 08:45.29 | rwhitby | Warning: jtag.c:647 jtag_add_dr_scan(): scan data for a device in BYPASS |
| 08:45.35 | rwhitby | > var 0 |
| 08:45.35 | rwhitby | id (1 fields): |
| 08:45.35 | rwhitby | 0x19277013 (/32) |
| 08:46.19 | drath | do you have a way to verify if the device is being held in reset? |
| 08:47.53 | rwhitby | I have remote serial console |
| 08:48.51 | drath | ok, can you check if it's running right now? |
| 08:49.14 | drath | if not, use "jtag_reset 0 0" to let the device out of reset - should be running then |
| 08:50.33 | rwhitby | hmm - can't contact it. I might not have hooked the serial back up after attaching jtag |
| 08:51.02 | rwhitby | ok, so I can verify srst tomorrow by looking at serial. trst shouldn't affect running operation, right? |
| 08:51.02 | drath | ok, well, at least we now know two things: |
| 08:51.08 | drath | - trst doesn't work as expeced |
| 08:51.17 | drath | - srst at least doesn't assert trst at well |
| 08:51.27 | drath | we might be able to live without trst, gotta look at the code this evening |
| 08:52.17 | rwhitby | 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. |
| 08:52.53 | rwhitby | drath: thanks for your help - will try and contact you again in 18 to 24 hours time. |
| 08:56.14 | drath | all right, just ping me, and if i don't answer leave me a message |
| 08:57.17 | rwhitby | will do, thx. |
| 10:16.27 | *** join/#openjtag rd_ (n=dr@vnsecurity.net) |
| 10:24.35 | *** join/#openjtag rd_ (n=dr@vnsecurity.net) |
| 11:02.19 | *** join/#openjtag d5 (n=dr@vnsecurity.net) |
| 11:28.09 | *** join/#openjtag drath_ (i=vmaster@p5B07CD0A.dip.t-dialin.net) |
| 12:27.22 | *** join/#openjtag rd_ (n=dr@vnsecurity.net) |
| 12:27.47 | *** join/#openjtag rd_ (n=dr@vnsecurity.net) |
| 12:49.28 | *** join/#openjtag rd_ (n=dr@vnsecurity.net) |
| 13:56.09 | *** join/#openjtag d1 (n=dr@vnsecurity.net) |
| 14:25.34 | *** join/#openjtag prpplague (n=dave@mail.americanmicrosystems.com) |
| 14:46.18 | *** join/#openjtag rd_ (n=dr@vnsecurity.net) |
| 15:23.38 | *** join/#openjtag d1 (n=dr@vnsecurity.net) |
| 15:48.38 | *** join/#openjtag sn9 (n=danielg4@gimpelevich.san-francisco.ca.us) |
| 15:50.40 | *** join/#openjtag sn9[ark] (n=arklinux@gimpelevich.san-francisco.ca.us) |
| 15:52.50 | sn9[ark] | Error: arm7_9_common.c:562 arm7_9_execute_sys_speed(): timeout waiting for SYSCOMP & DBGACK, last DBG_STATUS: 0 |
| 15:52.50 | sn9[ark] | Error: armv4_5.c:591 armv4_5_run_algorithm(): timeout waiting for algorithm to complete, trying to halt target |
| 15:52.50 | sn9[ark] | Error: armv4_5.c:600 armv4_5_run_algorithm(): target didn't reenter debug state, exiting |
| 15:54.09 | sn9 | that's what i get when i try to use "flash write 0 foo 0x7f0000" |
| 15:54.45 | sn9 | how do i fix that? |
| 15:56.35 | sn9 | this is using a wiggler clone, btw |
| 15:57.14 | drath | which target? |
| 15:57.29 | sn9 | marvell feroceon 88f5181l |
| 15:58.03 | drath | the feroceon is barely supported - the guys from linkstationwiki reported once successful flashing, using no working_area |
| 15:58.36 | sn9 | ah, so it's the working_area part that's failing? |
| 15:58.51 | drath | well, resume doesn't work |
| 15:59.07 | drath | and when using a working_area, the target is resumed, to execute the flash algorithm |
| 15:59.14 | sn9 | oh |
| 15:59.26 | drath | without a working_area individual memory accesses are used |
| 15:59.29 | drath | that's a lot slower |
| 15:59.40 | drath | but at least single memory accesses seem to work on the feroceon |
| 16:00.29 | sn9 | i'm trying to do this while pc points to garbage, btw |
| 16:01.21 | drath | in that case you should first check if the target really halted by issuing multiple "poll" commands |
| 16:03.18 | sn9 | cpsr and pc do not change when i do that |
| 16:03.53 | sn9 | armv4_5 disassemble says UNDEFINED INSTRUCTION |
| 16:05.19 | drath | ok, you'd get a "target running" or something like that if there was a problem |
| 16:05.25 | drath | try "mdw 0x0" |
| 16:05.47 | drath | if that gives the same result after several tries you should be fine |
| 16:06.40 | sn9 | it does, but the SYSCOMP & DBGACK thing appears in the log each time |
| 16:07.02 | sn9 | it produces zeroes, btw |
| 16:08.27 | sn9 | even when disassemble shows crap there |
| 16:09.16 | drath | well, kind of impossible to know what's going on inside the feroceon |
| 16:09.38 | drath | they wouldn't even let me see the nda, let alone the information that requires a nda to be signed |
| 16:10.24 | sn9 | yeah, marvell has no coherent policies for that kind of thing |
| 16:18.47 | sn9 | something interesting i found: |
| 16:19.26 | sn9 | http://wiki.dns323.info/hardware:jtag#todo |
| 16:19.49 | sn9 | that device is 88f5181l-based, too |
| 16:20.16 | sn9 | do you know anything about that patch? |
| 16:22.07 | sn9 | drath: ^ |
| 16:23.50 | sn9 | also, note the report there that mem access works |
| 16:26.08 | sn9 | maybe it has something to do with my need to use "reset_config srst_only combined" in openocd.cfg? |
| 23:51.17 | *** join/#openjtag nslu2-log_ (n=nslu2-lo@nslu2-linux/dyoung) |
| 23:59.19 | *** join/#openjtag rwhitby (n=rwhitby@nslu2-linux/rwhitby) |