**** BEGIN LOGGING AT Tue May 05 02:59:57 2009
May 05 11:44:11 <ja2> I finally got the openocd to run. But connecting to openocds default port via telnet is not working. Hints? Maybe my openocd.cfg is missing something. telnet :4444 should do, shouldnt it?
May 05 12:22:59 <ja2> Ah, now I telnet connected, but cant halt the target. Something missing?
May 05 13:40:42 <ja2> Ah, finally I got the target to halt.
May 05 14:25:56 <ja2> > production_info
May 05 14:25:56 <ja2> Imagine an explanation here...
May 05 15:36:12 <Strontium> hi dirk2
May 05 15:42:12 <dirk2> Strontium: hi
May 05 15:42:29 <Strontium> did you see my post about cortex_a8?
May 05 15:43:04 <dirk2> yes, was busy with other stuff, haven't got the details yet ;)
May 05 15:43:18 <dirk2> Strontium: What I observed while doing all the stuff manually
May 05 15:43:40 <dirk2> was that dap apsel 1  sometimes fails the first time
May 05 15:44:07 <dirk2> Strontium: Is this what your mail tries to say? Or is this an other issue? Sorry for asking ;)
May 05 15:44:31 <Strontium> yes, thats it.  With the script it became very clear
May 05 15:44:47 <Strontium> its immediately after a target reset
May 05 15:45:33 <dirk2> yes. While doing it manually, I didn't care and just did it a second time
May 05 15:45:43 <dirk2> But a script might fail with this :(
May 05 15:45:59 <Strontium> and so it did :)
May 05 15:46:29 <Strontium> Its like the results of the work done by ahbap_debugport_init(swjdp); are ignored.
May 05 15:46:49 <Strontium> so you need to do it a second time to get them to register
May 05 15:47:53 <dirk2> Strontium: I didn't look at the details :( Great that you did!
May 05 15:47:59 <Strontium> Id love to help out debuggin this, but arm wont give me access to any of their "need their permission" documents, because my company doesn't have a web page.
May 05 15:48:21 <Strontium> and by this I mean Cortex-a8.  But i will do as much as I can with the public docs
May 05 15:48:38 <dirk2> Strontium: Documents: I thought this first, too.
May 05 15:49:01 <dirk2> Strontium: But if we talk about the documents in (dirk2 searches the link ...)
May 05 15:49:19 <Strontium> I am stumped as to how to fix it properly though.  I need to learn more about the code
May 05 15:49:30 <dirk2> http://elinux.org/BeagleBoardOpenOCD#Cortex_A8_support
May 05 15:49:36 <dirk2> i.e. the first 2 documents
May 05 15:49:46 <dirk2> you only need *any* mail address
May 05 15:50:00 <dirk2> I tried it with my gmail address and it worked
May 05 15:50:00 <Strontium> thats them,
May 05 15:50:12 <Strontium> really.  I thought it would be the same as the architecture reference
May 05 15:50:28 <dirk2> Strontium: no, there seems to be a difference
May 05 15:51:03 <dirk2> There seems to be really confidential documents where applys what you describe
May 05 15:51:29 <dirk2> Then there are these documents, where you just have to ack a 'license agreement' by giving them your mail address
May 05 15:51:32 <Strontium> ok, i will try and get them then.
May 05 15:52:34 <dirk2> As I understand it, the 'license agreement'  just tries to ensure that you use the documents for JTAG SW development and not for copying their IP into other SoCs
May 05 15:53:52 <Strontium> ok, thanks. will try and dl them now.
May 05 15:55:44 <dirk2> ok, and I will read your mail a little more carefully ;)
May 05 15:57:48 <Strontium> sorry if its confusing.
May 05 15:58:03 <Strontium> glad I caught you.  I was just about to call it a night.
May 05 15:58:35 <Strontium> I will be on here most of the time now, so if you need me to do anything for you, just msg me.
May 05 16:02:19 <dirk2> I'm happy that the number of people looking at Cortex A8 support for OpenOCD increase now :) You, Magnus, Ray -> Hopefully we will get it to run now, soon. Unfortunately, I have only some minutes each day for this. So please some patience if I don't answer immediately...
May 05 16:06:57 <Strontium> dirk2, sure thing.  I know what it is like.
May 05 16:13:22 <Strontium> night
May 05 20:43:11 <Circuitsoft> Hello. Any clues as to the following from openocd?
May 05 20:43:19 <Circuitsoft> Info:    jtag.c:1376 jtag_examine_chain(): JTAG device found: 0x29dd202b (Manufacturer: 0x015, Part: 0x9dd2, Version: 0x2)
May 05 20:43:21 <Circuitsoft> Info:    jtag.c:1376 jtag_examine_chain(): JTAG device found: 0x25a6802b (Manufacturer: 0x015, Part: 0x5a68, Version: 0x2)
May 05 20:43:24 <Circuitsoft> Error:   jtag.c:1431 jtag_validate_chain(): Error validating JTAG scan chain, IR mismatch, scan returned 0x0101
May 05 20:43:48 <jeez__> hey guys, does anyone know where can I find the ARM register context structure in OPenOCD src ?
May 05 20:44:14 <Circuitsoft> Do I at least have ft2232_layout right?
May 05 20:50:12 <ja2> jeez__: 'reg' or?
May 05 20:50:52 <ja2> Circuitsoft: Something is fuzzy with your .cfg. I dont know what.
May 05 20:51:48 <Circuitsoft> ja2: I actually got the config verbose from the manufacturer of the target.
May 05 20:52:03 <Circuitsoft> Did I at least specify the correct ft2232_layout?
May 05 20:53:32 <ja2> That I do not know. Are you linux or win?
May 05 20:53:36 <Circuitsoft> linux
May 05 20:53:52 <ja2> If you cat /proc/bus/usb/devices
May 05 20:54:09 <ja2> and look for your jtag devices. 
May 05 20:54:24 <ja2> Are they on USB by the way?
May 05 20:54:30 <Circuitsoft> yes.
May 05 20:54:37 <Circuitsoft> Olimex FT2232-based
May 05 20:54:45 <Circuitsoft> S:  Product=Olimex OpenOCD JTAG
May 05 20:55:03 <ja2> Me too. To be honesy, I got it working today. Never used ARM before.
May 05 20:55:10 <Circuitsoft> I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=usbfs
May 05 20:55:29 <ja2> Ok, so the driver is loaded alright.
May 05 20:55:30 <Circuitsoft> I've been using a Segger J-Link on Windows for several months.
May 05 20:55:44 <Circuitsoft> Worked quite nicely, but Windows is getting gradually more and more annoying.
May 05 20:56:02 <Circuitsoft> And they don't have a GDB server for Linux.
May 05 20:56:39 <ja2> Windows was annoying already at 3.1
May 05 20:57:01 <ja2> in the .cfg you go: ft2232_layout olimex-jtag ?
May 05 20:57:20 <Circuitsoft> yes
May 05 20:57:51 <ja2> and: ft2232_vid_pid ?
May 05 20:58:02 <Circuitsoft> Had to set ft2232_vid_pid since it refused to work with ft2232_descriptoin
May 05 20:58:17 <Circuitsoft> It's finding devices on the chain, so I think it's communicating properly.
May 05 20:59:40 <ja2> Yes. You got a line with jtag newtap ... ?
May 05 21:00:42 <ja2> (I dont even know exactly what that line does) :/
May 05 21:00:43 <Circuitsoft> no
May 05 21:02:36 <Circuitsoft> ja2: /query Circuitsoft
May 05 21:04:03 <jeez__> ja2: ?!
May 05 22:01:23 <Circuitsoft> Can anyone here explain the meaning of the number after "IR mismatch, scan returned"
May 05 22:13:33 <Circuitsoft> Well, got that solved, or so I think.
May 05 22:13:43 <Circuitsoft> Now: "Error:   embeddedice.c:191 embeddedice_build_reg_cache(): unknown EmbeddedICE version (comms ctrl: 0x00000000)"
May 05 22:13:59 * Circuitsoft is going to eat. Back later.
May 06 00:17:01 <jeez__> is there a way of dumping all regs values (arm7tdmi) on OpenOCD ?
May 06 00:17:16 <jeez__> I mean, any monitor command to run in the gdb client ?
May 06 00:25:02 <roxfan> gdb command is not enough?
May 06 00:26:33 <roxfan> there is "reg" i guess
May 06 00:28:44 <jeez__> roxfan: all commands using gdb and openocd must be "monitor <cmd>" right ?
May 06 00:28:55 <jeez__> the commando, so, would be "monitor reg" ?
May 06 00:28:58 <roxfan> yes
May 06 00:28:59 <jeez__> *command
May 06 00:29:18 <roxfan> but why can't you use gdb's "show registers" or whatever ?
May 06 00:29:18 <jeez__> hmm ok, thanks
May 06 00:29:32 <jeez__> does it work with openocd ?
May 06 00:30:17 <roxfan> well, how would gdb work otherwise?
May 06 00:30:24 <jeez__> with the monitor command ?
May 06 00:30:40 <roxfan> no... just plain gdb built-in
May 06 00:31:41 <roxfan> ah, it's p[rint]
May 06 00:31:53 <jeez__> well, I guess that I'm kind of confused now
May 06 00:31:54 <roxfan> try p $R1 or something
May 06 00:32:15 <roxfan> or 'info registers'
May 06 00:32:18 <jeez__> I remember reading somewhere in openocd documentation that I should use monitor commands always
May 06 00:32:25 <roxfan> really?
May 06 00:32:44 <jeez__> monitor bp 0xaddrr 0xsize to set breakpoints
May 06 00:32:48 <jeez__> monitor resume
May 06 00:32:51 <jeez__> monitor step
May 06 00:32:58 <roxfan> well, if you want to run openocd command then yes, of course you need to add "mon"
May 06 00:33:36 <jeez__> aaaaa, did you think that I was talking about debugging the openocd process itself in gdb ?
May 06 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
May 06 00:33:53 <roxfan> nono
May 06 00:34:09 <jeez__> sorry, I'm talking about using gdb remote protocol gdb <--> openocd <--> jtag <--> board
May 06 00:34:13 <roxfan> yes yes
May 06 00:34:44 <roxfan> but as i said, what's the point of using gdb if you plan to bypass it completely?
May 06 00:35:28 <jeez__> well, I'm not going to use gdb, I'll use another debugger with the gdb protocol to communicate with openocd
May 06 00:36:09 <roxfan> does that debugger have a command for showing registers?
May 06 00:36:30 <jeez__> yes
May 06 00:36:37 <roxfan> then use it :)
May 06 00:36:53 <jeez__> no need to use the monitor reg command ? :P
May 06 00:37:09 <roxfan> get/set register values is one of the few commands required to be implemeted in the remote gdb protocol
May 06 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
May 06 00:37:46 <jeez__> fuck... maybe I'm really confused now :P
May 06 00:37:57 <roxfan> you should be able to
May 06 00:38:07 <jeez__> I've been using monitor commands for the last one month and a half
May 06 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
May 06 00:38:18 <jeez__> I'll try it right now
May 06 00:38:42 <jeez__> yes, mon reg prints to me a list of all regs I guess
May 06 00:38:48 <jeez__> even cpsr and pc
May 06 00:39:20 <roxfan> also, some advanced breakpoints (like watchpoints) might be not implemented with gdb protocol
May 06 00:39:30 <roxfan> but the basic stuff should work
May 06 00:40:36 <jeez__> hmm
May 06 00:41:00 <jeez__> but using "break *0xaddrr" and "monitor bp 0xaddrr size" is the same ?
May 06 00:41:19 <roxfan> it should be
May 06 00:41:47 <roxfan> except in the first case gdb will actually know that the break was scheduled :)
May 06 00:59:52 <Circuitsoft> Question: I'm getting "Error:   embeddedice.c:191 embeddedice_build_reg_cache(): unknown EmbeddedICE version (comms ctrl: 0x00000000)"
May 06 01:00:09 <Circuitsoft> Are there any likely culprits in the config to look at?
May 06 01:02:48 <Circuitsoft> http://gist.github.com/107309
May 06 01:05:06 <Circuitsoft> jeez__: Are you using an ARM gdb?
May 06 01:05:34 <jeez__> Circuitsoft: no, normal gdb in target remote mode
May 06 01:05:59 <jeez__> so I just need to use monitor commands and be happy with that :P
May 06 01:07:25 <Circuitsoft> That would explain the confusion. What ARM toolchain are you using?
May 06 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)
May 06 01:09:22 <Circuitsoft> What platform are you on? Windows? Linux? Other?
May 06 01:09:26 <jeez__> linux
May 06 01:09:51 <Circuitsoft> jeez__: http://www.gnuarm.com/support.html
May 06 01:10:12 <Circuitsoft> Download binutils, gcc, and gdb from http://ftp.gnu.org/pub/
May 06 01:10:28 <Circuitsoft> Download newlib from (wherever googling newlib gets you)
May 06 01:10:35 <jeez__> Circuitsoft: yes, thanks
May 06 01:10:36 <Circuitsoft> Building it from scratch isn't hard, and doesn't take too long.
May 06 01:11:00 <jeez__> but I guess that I don't need this for now... I mean, I'm not cross-compiling anything anymore
May 06 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
May 06 01:11:34 <jeez__> just the board already flashed and a jtag cable
May 06 01:11:49 <jeez__> and openocd and a client using gdb remote protocol
May 06 01:12:03 <Circuitsoft> Having a real arm-gdb is still handy.
May 06 01:12:15 <Circuitsoft> You may not need to build the rest of the toolchain, I'm not sure.
May 06 01:12:32 <Circuitsoft> That way you can read disassembly listings and examine memory more easily.
May 06 01:12:35 <jeez__> yes, you are right, but the goal here is not to use gdb itself
May 06 01:12:41 <jeez__> I'm doing my own debugger ;)
May 06 01:13:10 <jeez__> we do have our own disassembler (arm, mips, x86, etc)
May 06 01:14:03 <jeez__> by we I mean, the ERESI Reverse Engineering Framework :)
May 06 01:14:34 <jeez__> in a near future, with remote debugging of embedded systems support ;)
May 06 01:14:41 <jeez__> that's the scenario here 
May 06 01:14:56 <Circuitsoft> The easiest way to do that would probably be as a gdb frontend.
May 06 01:15:32 <jeez__> yes, we have a lib called gdbwrap and a remote debugger for that
May 06 01:15:41 <jeez__> I'm adding support for connecting to openocd servers
May 06 01:16:18 <Circuitsoft> I'd just keep using gdbwrap and add "target remote ..." support to it.
May 06 01:16:54 <jeez__> gdbwrap is a wrapper for the protocol, not the gdb client
May 06 01:18:06 <Circuitsoft> I really don't get why you would want to do that, but..
May 06 01:19:23 <jeez__> ahahah, well, maybe someday you will understand it better
May 06 01:19:32 <jeez__> let's have the project ready before :P
May 06 01:19:50 <Circuitsoft> More, it's a question of what gdb does not do that you need.
May 06 01:20:30 <Circuitsoft> http://sourceware.org/gdb/current/onlinedocs/gdb_26.html
May 06 01:21:05 <Circuitsoft> With GDB/MI, you could very easily plug GDB into your own script interpreter.
May 06 01:21:49 <jeez__> yes, but the thing here is what ERESI can do that besides any other debugger
May 06 01:22:09 <jeez__> and adding full support to remote gdb debugging brings us a whole new world to try it out
May 06 01:22:26 <Circuitsoft> afaik, all the backends mentioned on the gdbwrap page are just gdb remote protocol implementations.
May 06 01:22:31 <Circuitsoft> So, you could connect gdb to any of them.
May 06 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.
May 06 01:22:56 <Circuitsoft> Wound up writing it in a combination of Python and C#
May 06 01:23:22 <Circuitsoft> And that was only because I couldn't get SEGGER J-Flash to work.
May 06 01:25:09 <Circuitsoft> Anyway, I haven't actually gotten OpenOCD to work on my target yet.
May 06 01:25:18 <Circuitsoft> Getting "Error: embeddedice.c:191 embeddedice_build_reg_cache(): unknown EmbeddedICE version (comms ctrl: 0x00000000)"
May 06 01:25:40 <jeez__> have no clue about it =/
May 06 01:25:54 <Circuitsoft> roxfan?
May 06 01:25:57 <jeez__> openocd is just a gdb server to me ;)
May 06 01:26:02 <Circuitsoft> Same here.
May 06 01:26:18 <Circuitsoft> Unfortunately, since it can't connect to my target, it doesn't yet work as a gdb server.
May 06 01:27:13 <roxfan> sorry, no idea what that means
May 06 01:43:21 <Circuitsoft> Anyway, it would appear that it's not properly reading the EmbeddedICE version.
May 06 01:43:38 <Circuitsoft> I have time to trial-and-error it. What values should I change?
May 06 02:01:19 <Circuitsoft> My openocd.cfg has two jtag_device lines.
May 06 02:01:45 <Circuitsoft> Do the last three parameters matter for both of them, or just the device under test?
May 06 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.
May 06 02:20:45 <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 ?
May 06 02:21:05 <jeez__> it seems that I never reach breakpoint, even knowing that openocd is setting them
May 06 02:21:27 <Circuitsoft> jeez__ Is your target code running in RAM or Flash?
May 06 02:22:05 <jeez__> Flash I guess, since it stills there when I turn it off and on again
May 06 02:22:09 <jeez__> :P
May 06 02:22:19 <Circuitsoft> What is your target?
May 06 02:22:25 <jeez__> lpc-e2124
May 06 02:22:27 <jeez__> from olimex
May 06 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.
May 06 02:23:09 <Circuitsoft> On the devices I'm using, it's two.
May 06 02:23:30 <jeez__> Circuitsoft: this one-> http://www.olimex.com/dev/lpc-e2124.html 
May 06 02:27:31 <Circuitsoft> jeez__ Can you tell me, verbose, the EmbeddedICE version line you get from OpenOCD?
May 06 02:27:53 <jeez__> how do I do that ?
May 06 02:28:12 <Circuitsoft> When you first run OpenOCD and it connects to the target, it'll print out a line containing the word EmbeddedICE
May 06 02:28:16 <Circuitsoft> Just copy and paste that line here.
May 06 02:29:52 <Circuitsoft> It's probably within the first few lines
May 06 02:30:38 <jeez__> Circuitsoft: I have no such line
May 06 02:30:44 <Circuitsoft> Hmm.
May 06 02:30:46 <Circuitsoft> Okay.
May 06 02:35:21 <Circuitsoft> I'm bruteforcing parameters for the jtag_device lines in my config.
May 06 02:35:48 <Circuitsoft> Just wondering what to search for that would be in place of "unknown EmbeddedICE version"
**** ENDING LOGGING AT Wed May 06 02:59:57 2009