| 00:17.01 | jeez__ | is there a way of dumping all regs values (arm7tdmi) on OpenOCD ? |
| 00:17.15 | jeez__ | I mean, any monitor command to run in the gdb client ? |
| 00:25.02 | roxfan | gdb command is not enough? |
| 00:26.33 | roxfan | there is "reg" i guess |
| 00:28.43 | jeez__ | roxfan: all commands using gdb and openocd must be "monitor <cmd>" right ? |
| 00:28.55 | jeez__ | the commando, so, would be "monitor reg" ? |
| 00:28.59 | roxfan | yes |
| 00:28.59 | jeez__ | *command |
| 00:29.18 | jeez__ | hmm ok, thanks |
| 00:29.18 | roxfan | but why can't you use gdb's "show registers" or whatever ? |
| 00:29.31 | jeez__ | does it work with openocd ? |
| 00:30.17 | roxfan | well, how would gdb work otherwise? |
| 00:30.23 | jeez__ | with the monitor command ? |
| 00:30.40 | roxfan | no... just plain gdb built-in |
| 00:31.41 | roxfan | ah, it's p[rint] |
| 00:31.53 | jeez__ | well, I guess that I'm kind of confused now |
| 00:31.54 | roxfan | try p $R1 or something |
| 00:32.15 | roxfan | or 'info registers' |
| 00:32.18 | jeez__ | I remember reading somewhere in openocd documentation that I should use monitor commands always |
| 00:32.25 | roxfan | really? |
| 00:32.44 | jeez__ | monitor bp 0xaddrr 0xsize to set breakpoints |
| 00:32.47 | jeez__ | monitor resume |
| 00:32.50 | jeez__ | monitor step |
| 00:32.58 | roxfan | well, if you want to run openocd command then yes, of course you need to add "mon" |
| 00:33.36 | jeez__ | aaaaa, did you think that I was talking about debugging the openocd process itself in gdb ? |
| 00:33.42 | roxfan | but gdb itself supports a lot of that... and if you just pass everything to openocd you can just as well simply use telnet protocol |
| 00:33.53 | roxfan | nono |
| 00:34.08 | jeez__ | sorry, I'm talking about using gdb remote protocol gdb <--> openocd <--> jtag <--> board |
| 00:34.14 | roxfan | yes yes |
| 00:34.44 | roxfan | but as i said, what's the point of using gdb if you plan to bypass it completely? |
| 00:35.27 | jeez__ | well, I'm not going to use gdb, I'll use another debugger with the gdb protocol to communicate with openocd |
| 00:36.10 | roxfan | does that debugger have a command for showing registers? |
| 00:36.30 | jeez__ | yes |
| 00:36.37 | roxfan | then use it :) |
| 00:36.53 | jeez__ | no need to use the monitor reg command ? :P |
| 00:37.09 | roxfan | get/set register values is one of the few commands required to be implemeted in the remote gdb protocol |
| 00:37.33 | jeez__ | but, in this case (using gdb directly), can I use its native commands to debug the board using openocd, even after the "target remote localhost:5555" command ?! o.O |
| 00:37.45 | jeez__ | fuck... maybe I'm really confused now :P |
| 00:37.57 | roxfan | you should be able to |
| 00:38.07 | jeez__ | I've been using monitor commands for the last one month and a half |
| 00:38.18 | roxfan | well, iirc the default arm packet might be missing some system/debug registers... so if you don't see some, try mon reg |
| 00:38.18 | jeez__ | I'll try it right now |
| 00:38.42 | jeez__ | yes, mon reg prints to me a list of all regs I guess |
| 00:38.48 | jeez__ | even cpsr and pc |
| 00:39.20 | roxfan | also, some advanced breakpoints (like watchpoints) might be not implemented with gdb protocol |
| 00:39.30 | roxfan | but the basic stuff should work |
| 00:40.36 | jeez__ | hmm |
| 00:41.00 | jeez__ | but using "break *0xaddrr" and "monitor bp 0xaddrr size" is the same ? |
| 00:41.19 | roxfan | it should be |
| 00:41.47 | roxfan | except in the first case gdb will actually know that the break was scheduled :) |
| 00:59.51 | Circuitsoft | Question: I'm getting "Error: embeddedice.c:191 embeddedice_build_reg_cache(): unknown EmbeddedICE version (comms ctrl: 0x00000000)" |
| 01:00.09 | Circuitsoft | Are there any likely culprits in the config to look at? |
| 01:02.48 | Circuitsoft | http://gist.github.com/107309 |
| 01:05.05 | Circuitsoft | jeez__: Are you using an ARM gdb? |
| 01:05.34 | jeez__ | Circuitsoft: no, normal gdb in target remote mode |
| 01:05.59 | jeez__ | so I just need to use monitor commands and be happy with that :P |
| 01:07.25 | Circuitsoft | That would explain the confusion. What ARM toolchain are you using? |
| 01:09.00 | jeez__ | right now, no one. I've used crossworks to flash my board, and now I have the generated elf file which I'm using as a "map" (symtab, etc) |
| 01:09.22 | Circuitsoft | What platform are you on? Windows? Linux? Other? |
| 01:09.26 | jeez__ | linux |
| 01:09.51 | Circuitsoft | jeez__: http://www.gnuarm.com/support.html |
| 01:10.11 | Circuitsoft | Download binutils, gcc, and gdb from http://ftp.gnu.org/pub/ |
| 01:10.28 | Circuitsoft | Download newlib from (wherever googling newlib gets you) |
| 01:10.35 | jeez__ | Circuitsoft: yes, thanks |
| 01:10.36 | Circuitsoft | Building it from scratch isn't hard, and doesn't take too long. |
| 01:10.59 | jeez__ | but I guess that I don't need this for now... I mean, I'm not cross-compiling anything anymore |
| 01:11.22 | jeez__ | imagine a use case where you just need to debug an embedded system, but you don't have source code nor nothing else |
| 01:11.33 | jeez__ | just the board already flashed and a jtag cable |
| 01:11.49 | jeez__ | and openocd and a client using gdb remote protocol |
| 01:12.03 | Circuitsoft | Having a real arm-gdb is still handy. |
| 01:12.15 | Circuitsoft | You may not need to build the rest of the toolchain, I'm not sure. |
| 01:12.32 | Circuitsoft | That way you can read disassembly listings and examine memory more easily. |
| 01:12.35 | jeez__ | yes, you are right, but the goal here is not to use gdb itself |
| 01:12.41 | jeez__ | I'm doing my own debugger ;) |
| 01:13.10 | jeez__ | we do have our own disassembler (arm, mips, x86, etc) |
| 01:14.03 | jeez__ | by we I mean, the ERESI Reverse Engineering Framework :) |
| 01:14.34 | jeez__ | in a near future, with remote debugging of embedded systems support ;) |
| 01:14.41 | jeez__ | that's the scenario here |
| 01:14.56 | Circuitsoft | The easiest way to do that would probably be as a gdb frontend. |
| 01:15.32 | jeez__ | yes, we have a lib called gdbwrap and a remote debugger for that |
| 01:15.41 | jeez__ | I'm adding support for connecting to openocd servers |
| 01:16.17 | Circuitsoft | I'd just keep using gdbwrap and add "target remote ..." support to it. |
| 01:16.54 | jeez__ | gdbwrap is a wrapper for the protocol, not the gdb client |
| 01:18.05 | Circuitsoft | I really don't get why you would want to do that, but.. |
| 01:19.23 | jeez__ | ahahah, well, maybe someday you will understand it better |
| 01:19.31 | jeez__ | let's have the project ready before :P |
| 01:19.50 | Circuitsoft | More, it's a question of what gdb does not do that you need. |
| 01:20.29 | Circuitsoft | http://sourceware.org/gdb/current/onlinedocs/gdb_26.html |
| 01:21.05 | Circuitsoft | With GDB/MI, you could very easily plug GDB into your own script interpreter. |
| 01:21.49 | jeez__ | yes, but the thing here is what ERESI can do that besides any other debugger |
| 01:22.09 | jeez__ | and adding full support to remote gdb debugging brings us a whole new world to try it out |
| 01:22.26 | Circuitsoft | afaik, all the backends mentioned on the gdbwrap page are just gdb remote protocol implementations. |
| 01:22.31 | Circuitsoft | So, you could connect gdb to any of them. |
| 01:22.46 | Circuitsoft | The only reason I've ever used raw GDB protocol was to write a device-specific programmer we could hand off to our customers when they're afraid to use straight-up GDB by itself. |
| 01:22.55 | Circuitsoft | Wound up writing it in a combination of Python and C# |
| 01:23.21 | Circuitsoft | And that was only because I couldn't get SEGGER J-Flash to work. |
| 01:25.09 | Circuitsoft | Anyway, I haven't actually gotten OpenOCD to work on my target yet. |
| 01:25.18 | Circuitsoft | Getting "Error: embeddedice.c:191 embeddedice_build_reg_cache(): unknown EmbeddedICE version (comms ctrl: 0x00000000)" |
| 01:25.39 | jeez__ | have no clue about it =/ |
| 01:25.54 | Circuitsoft | roxfan? |
| 01:25.57 | jeez__ | openocd is just a gdb server to me ;) |
| 01:26.02 | Circuitsoft | Same here. |
| 01:26.17 | Circuitsoft | Unfortunately, since it can't connect to my target, it doesn't yet work as a gdb server. |
| 01:27.13 | roxfan | sorry, no idea what that means |
| 01:40.51 | *** join/#openjtag roxfan2 (n=dunno@162.38-244-81.adsl-dyn.isp.belgacom.be) |
| 01:43.21 | Circuitsoft | Anyway, it would appear that it's not properly reading the EmbeddedICE version. |
| 01:43.38 | Circuitsoft | I have time to trial-and-error it. What values should I change? |
| 01:52.26 | *** join/#openjtag koobe (n=koobe@83.150.95.26) |
| 02:01.19 | Circuitsoft | My openocd.cfg has two jtag_device lines. |
| 02:01.45 | Circuitsoft | Do the last three parameters matter for both of them, or just the device under test? |
| 02:02.21 | Circuitsoft | I figured I'd brute-force try all combinations, but then realized it'd take 466 hours to try all combinations of both lines, but 6 minutes for all combinations of one line. |
| 02:20.44 | jeez__ | roxfan: when you are using breakpoints, if you set a breakpoint and then you do some monitor resume, do you ever reach that breakpoint ? |
| 02:21.05 | jeez__ | it seems that I never reach breakpoint, even knowing that openocd is setting them |
| 02:21.26 | Circuitsoft | jeez__ Is your target code running in RAM or Flash? |
| 02:22.05 | jeez__ | Flash I guess, since it stills there when I turn it off and on again |
| 02:22.09 | jeez__ | :P |
| 02:22.19 | Circuitsoft | What is your target? |
| 02:22.24 | jeez__ | lpc-e2124 |
| 02:22.27 | jeez__ | from olimex |
| 02:23.00 | Circuitsoft | I know that if the code is running out of flash, and not ram, you'll have a limited number of hardware breakpoints. |
| 02:23.09 | Circuitsoft | On the devices I'm using, it's two. |
| 02:23.30 | jeez__ | Circuitsoft: this one-> http://www.olimex.com/dev/lpc-e2124.html |
| 02:27.31 | Circuitsoft | jeez__ Can you tell me, verbose, the EmbeddedICE version line you get from OpenOCD? |
| 02:27.53 | jeez__ | how do I do that ? |
| 02:28.11 | Circuitsoft | When you first run OpenOCD and it connects to the target, it'll print out a line containing the word EmbeddedICE |
| 02:28.16 | Circuitsoft | Just copy and paste that line here. |
| 02:29.51 | Circuitsoft | It's probably within the first few lines |
| 02:30.38 | jeez__ | Circuitsoft: I have no such line |
| 02:30.44 | Circuitsoft | Hmm. |
| 02:30.46 | Circuitsoft | Okay. |
| 02:35.21 | Circuitsoft | I'm bruteforcing parameters for the jtag_device lines in my config. |
| 02:35.47 | Circuitsoft | Just wondering what to search for that would be in place of "unknown EmbeddedICE version" |
| 04:24.05 | *** join/#openjtag Strontium (n=Strontiu@115.134.178.127) |
| 05:57.08 | *** join/#openjtag pleemans (n=toi@116.54-246-81.adsl-static.isp.belgacom.be) |
| 08:12.18 | *** join/#openjtag starkmjolk (n=starkmjo@h-91-88.A163.priv.bahnhof.se) |
| 08:30.32 | Strontium | Anyone got a copy of ARM Architecture Reference Manual ARMv7-AR Edition DDI 0406 |
| 08:34.16 | roxfan | it's nda'd |
| 08:40.07 | Strontium | crap |
| 08:41.51 | roxfan | are you looking for something in particular? |
| 08:59.30 | Strontium | yes, all of the addresses for things like CPU_ID which might be useful for jtag debuggers, etc. So I can properly work on Cortex_A8 support for openocd. The Cortex_M3 document has them in it. But they are different on the A8. |
| 09:02.16 | *** join/#openjtag roxfan2 (n=dunno@162.38-244-81.adsl-dyn.isp.belgacom.be) |
| 09:02.40 | roxfan2 | grr |
| 09:03.19 | roxfan2 | also check this http://www.arm.com/products/solutions/coresight_spec.html |
| 09:04.04 | roxfan2 | and http://www.arm.com/products/solutions/ADISpecification.html |
| 09:04.44 | Strontium | roxfan, I have all those. |
| 09:04.54 | roxfan | hmm, not enough? |
| 09:05.35 | Strontium | nope. eg. the cortex_a8.h defines: #define CPUID0x54011D00 |
| 09:05.51 | Strontium | but that address appears nowhere in any of those specs |
| 09:12.02 | roxfan | is it an address? maybe it's the value |
| 09:23.12 | Strontium | its an address |
| 09:23.22 | Strontium | I think. |
| 09:23.39 | roxfan | well, i can't find anything matching in any doc |
| 09:23.48 | Strontium | Its an address for M3 |
| 09:53.55 | Circuitsoft | Question. I have an ARM946 which appears to identify itself, over jtag, as an ARM1068E-S, soft macrocell |
| 09:54.14 | Circuitsoft | Seeing as there is no such thing as an ARM1068... |
| 09:56.22 | Circuitsoft | Various info at http://gist.github.com/107309 |
| 10:00.11 | Circuitsoft | Strontium: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0344b/Babififh.html |
| 10:30.08 | Strontium | Circuitsoft: thanks for the link |
| 10:30.14 | Circuitsoft | Does that help? |
| 10:30.19 | Strontium | Yes |
| 10:30.51 | Circuitsoft | Came across it while digging through ARM docs trying to figure out what might be wrong with my JTAG setup. |
| 10:35.16 | Circuitsoft | Strontium: I don't really know that much about JTAG. Any ideas what types of misconfigurations might lead to shifted bits in the returned IDCODE? Is that possible? |
| 10:37.13 | Strontium | Well its possible. But I couldn't really say what sort of errors. Possibly a state machine error. JTAG is a loop, so you need to clock out as many bits as you recieve. If you clock out too many or too few bits your result will be shifted by the under/over run. Is my guess. |
| 10:37.50 | Strontium | Its basically a big shift register and you clock bits in one end and get them out the other. (This is the data register). |
| 10:38.42 | Circuitsoft | What determines the IR length? |
| 10:43.24 | Strontium | The specification. |
| 10:44.02 | Circuitsoft | Will all ARM946e cores have the same IR length? |
| 10:44.11 | Strontium | One way to test it. Clock out heaps of zeros. Many more than a reasonable IR length. You should recieve zeros. Then clock out ones. Count how many zeros you recieve before your first 1. this is the IR length. |
| 10:44.42 | Strontium | I would think so. But the datasheet for the device should say. |
| 10:45.28 | Strontium | Jtag is normally part of the core architecture. Although vendors can change it, especially soc vendors. Because they might add functionality. |
| 10:45.51 | Circuitsoft | This scan chain has two devices. If I specify IRLen of 8 for both of them, OpenOCD does not complain about IR length mismatch. Otherwise, it does. |
| 10:47.57 | Strontium | I saw somewhere someone did an ir length scan somehow with openocd. I dont know how to do that though. |
| 10:48.20 | Strontium | search the mailing lists for it. It was a scan of vaious dr lengths for each possible ir |
| 10:54.14 | *** join/#openjtag pirho (i=pirho@gateway/gpg-tor/key-0x2CEEC9CB) |
| 11:04.25 | Circuitsoft | After running an "irscan" command, I get |
| 11:04.28 | Circuitsoft | couldn't read the requested number of bytes from FT2232 device (1 < 2) |
| 11:04.30 | Circuitsoft | couldn't read from FT2232 |
| 11:07.08 | *** join/#openjtag pirho_ (i=pirho@gateway/gpg-tor/key-0x2CEEC9CB) |
| 11:59.20 | Strontium | Circuitsoft: sorry, i dont know. :( Ive only started hacking on openocd myself. |
| 13:49.42 | *** join/#openjtag ja2 (n=marcus@81-233-153-207-no83.tbcn.telia.com) |
| 13:55.26 | jeez__ | Is the way that openocd handles the arm regs info just saving their values in that context[16] ?! |
| 13:56.10 | jeez__ | I mean, this saves the values from r0 to r15, but we still have cspr and spsr, right ? |
| 13:56.26 | jeez__ | isn't there any struct in the code to save this ? |
| 15:32.47 | *** join/#openjtag Bitmaster (n=Bitmaste@wpa-n5-50.kthopen.kth.se) |
| 15:59.17 | *** join/#openjtag konaya (n=Bitmaste@wpa-n5-50.kthopen.kth.se) |
| 16:25.39 | *** join/#openjtag pirho (i=pirho@gateway/gpg-tor/key-0x2CEEC9CB) |
| 16:56.13 | *** join/#openjtag pirho (i=pirho@gateway/gpg-tor/key-0x2CEEC9CB) |
| 17:54.38 | *** join/#openjtag ChanServ (ChanServ@services.) |
| 17:54.38 | *** join/#openjtag nslu2-log (n=nslu2-lo@limax.nslu2-linux.org) |
| 17:54.38 | *** join/#openjtag roxfan (n=dunno@162.38-244-81.adsl-dyn.isp.belgacom.be) |
| 17:54.38 | *** join/#openjtag pthomas__ (n=pthomas@65.101.35.154) |
| 17:54.38 | *** join/#openjtag keesj (n=keesj@ip49-193-210-87.adsl2.static.versatel.nl) |
| 17:54.39 | *** join/#openjtag uwe_ (n=uwe_@dslb-084-056-024-012.pools.arcor-ip.net) |
| 17:54.39 | *** join/#openjtag rje`mac (n=rje`mac@c-67-185-128-239.hsd1.wa.comcast.net) |
| 17:54.39 | *** join/#openjtag Circuitsoft (n=chatzill@64.244.192.226) |
| 17:54.39 | *** join/#openjtag key2 (n=key2@gob75-7-82-247-113-230.fbx.proxad.net) |
| 17:54.39 | *** join/#openjtag dongs (n=lol@218.219.212.168) |
| 17:54.39 | *** join/#openjtag jeez__ (n=sheushom@200.184.118.130) |
| 17:54.39 | *** join/#openjtag esden (n=esdentem@repl.esden.net) |
| 17:54.39 | *** join/#openjtag Strontium (n=Strontiu@115.134.178.127) |
| 17:54.39 | *** join/#openjtag starkmjolk (n=starkmjo@h-91-88.A163.priv.bahnhof.se) |
| 17:54.39 | *** join/#openjtag ja2 (n=marcus@81-233-153-207-no83.tbcn.telia.com) |
| 17:54.39 | *** join/#openjtag koobe (n=koobe@83.150.95.26) |
| 17:54.39 | *** join/#openjtag flyback (n=scr@c-24-3-13-158.hsd1.pa.comcast.net) |
| 17:54.39 | *** join/#openjtag pytey (n=pytey@84.233.192.144) |
| 17:54.39 | *** join/#openjtag wookey_ (n=wookey@stoneboat.aleph1.co.uk) |
| 17:54.39 | *** mode/#openjtag [+o ChanServ] by irc.freenode.net |
| 17:57.26 | *** join/#openjtag pleemans (n=toi@84.194.170.183) |
| 18:54.55 | roxfan | Strontium: 54xxxxxx address is apparently omap3-specific |
| 20:54.57 | *** join/#openjtag brolin (n=brolin@190.157.14.3) |