| 01:46.53 | *** join/#openjtag johnrw (n=johnrw@c-68-39-252-155.hsd1.nj.comcast.net) |
| 07:01.26 | *** join/#openjtag pleemans (n=toi@116.54-246-81.adsl-static.isp.belgacom.be) |
| 11:47.21 | *** join/#openjtag pirho (i=pirho@gateway/gpg-tor/key-0x2CEEC9CB) |
| 19:04.46 | *** join/#openjtag dirk2 (n=dirk@p5B04352D.dip0.t-ipconnect.de) |
| 19:18.55 | keesj | Hi dirk2 |
| 19:22.32 | dirk2 | hi |
| 19:22.57 | dirk2 | any svf progress? |
| 19:23.36 | keesj | no, but I think the sequence was 100% oke anyhow |
| 19:24.06 | dirk2 | but you can't get the ID register 0x4? |
| 19:24.48 | keesj | I need to look into that. this info needs to be on the elinux wiki |
| 19:25.55 | dirk2 | I think depending on free time, I will go on with some more hacking directly in urjtag. Maybe I can implement a 'init OMAP3 command' |
| 19:25.56 | keesj | but I had fun today creating a "visualisation" for the logic analyzer using ruby |
| 19:26.33 | dirk2 | btw: Thanks for the logic analyzer hint last week. A friend of mine is thinking about buying it |
| 19:26.53 | dirk2 | $160 is quite cheap |
| 19:27.04 | dirk2 | and they propose linux software for ~March |
| 19:27.42 | dirk2 | s/propose/promise/ |
| 19:27.44 | keesj | http://box.mmapps.net/analyzer.zip and the UI looks like this http://paste-it.net/raw/public/a44f1e4/ |
| 19:28.08 | keesj | dirk2: they promissed it end jarnuary also |
| 19:28.29 | dirk2 | keesj: well, I think for $160 it's ok ;) |
| 19:28.52 | keesj | the protocol can only be very simple anyway |
| 19:29.15 | keesj | I looked on sourceforge and there are at lease a few OK GUI's |
| 19:30.32 | dirk2 | did you try to run the logic analyzer data through something like a perl script to create a JTAG protocol analysis? |
| 19:30.39 | keesj | I think that usbee is a concurent of the one I am using https://www.sparkfun.com/commerce/product_info.php?products_id=8938 there are some comments that all match my experiance |
| 19:33.01 | keesj | not yet , that wold really be trivial, perhaps the next step , but clearly not required any more. to follow the jtag state machine you only need to look at the clock and tms |
| 19:34.09 | dirk2 | back to OMAP3 jtag: Looking at urjtag's 'discovery' output it (correctly) detects DR #7 as 8 bit long. |
| 19:34.22 | dirk2 | If I understand TI's config correctly, we have to send 0x89 to this register. |
| 19:34.39 | dirk2 | Then we have to send 0xa3002108 as 32 bit value to DR #2 (?). |
| 19:34.51 | dirk2 | But DR #2 is detected as 1 bit length only: Detecting DR length for IR 000010 ... 1 |
| 19:35.57 | keesj | yes I saw that , but bdi does the same. therefore I think it must be the discovery that goes wrong |
| 19:36.53 | dirk2 | hmm, or with 0x89 we switch to a 32 bit register? |
| 19:37.39 | dirk2 | for instance, write 0x89 to DR #7 == enable 32 bit register DR #2 |
| 19:43.36 | keesj | we need to try the dbi sequence |
| 19:43.47 | keesj | https://accesovpn.terra.es/http/elinux.org/BeagleBoardJTAG |
| 19:44.48 | dirk2 | sorry, dbi? |
| 19:45.03 | keesj | bdi |
| 19:45.33 | keesj | and about Parameter : The port address field is '0x0f000000'. Parameter : The port address value is '3'. |
| 19:46.12 | keesj | I think what they are saying is that in the command that follow |
| 19:47.08 | keesj | the address used is (3) the as the bytes in [23:27] |
| 19:47.22 | keesj | so Parameter : The send data value is '0xa3002108'. |
| 19:47.55 | keesj | is't the same 3 and probably also saying that the DAP is located and the 4th port of the JCR |
| 19:48.15 | dirk2 | bdi: yes (I wonder about the URL https://accesovpn.terra.es/ though) |
| 19:48.36 | keesj | as there can be up to 15 tap's connected (needs 4 bytes) |
| 19:48.38 | keesj | Parameter : The send data value is '0xa3002108'. |
| 19:48.55 | dirk2 | yes, this is my understanding, too |
| 19:50.33 | keesj | is searching for the screen shot showing the ICEPICK and the other components somewhere else on the wiki |
| 19:51.07 | dirk2 | think to remember that it is in the TI slides |
| 19:52.57 | dirk2 | http://focus.ti.com/lit/ml/sprp603/sprp603.pdf page 6 ? |
| 19:54.19 | dirk2 | or page 10 ? |
| 19:58.00 | dirk2 | keesj: btw: Do you like to attend with OMAP3 OpenOCD project at Beagle contest? |
| 19:58.29 | dirk2 | keesj: I can't do it my self, but I like to help :) |
| 19:59.04 | keesj | I don't see what I can gain doing that. It might help getting more people in |
| 19:59.34 | dirk2 | You could win a beagle rev C2 |
| 20:03.20 | dirk2 | keesj: Assuming we get UrJTAG to configure OMAP3 properly (by svf or source code hack), how would we proceed with OpenOCD then? |
| 20:04.39 | keesj | That would be step two |
| 20:05.17 | keesj | that is where one need to read the cortex trm and implement software support |
| 20:05.22 | dirk2 | Do you have already any plan/idea for this second step? |
| 20:06.01 | *** join/#openjtag pleemans (n=toi@d54C2AAB7.access.telenet.be) |
| 20:06.05 | keesj | not as such no. |
| 20:06.36 | keesj | I would procceed much in the same way I have been doing until now |
| 20:06.58 | keesj | I think the openocd guys will hop in as it is then a "software only" issue |
| 20:07.35 | dirk2 | keesj: Hmm, before TRM step OpenOCD needs 'do JTAG init the same way we did with urjtag and which showed to work' step? I.e. OpenOCD JTAG config has to be adapted to do stuff needed for OMAP3 correctly, no? |
| 20:08.18 | keesj | yes , perhaps as you sugested urjtag could be the first step. |
| 20:08.56 | keesj | my personal feeling is that once it works for urjtag we must have enough understanding of it to make it work under openocd |
| 20:09.37 | dirk2 | yes. Or show the OpenOCD people how it works in urjtag and ask them 'how can we do it the same way in OpenOCD' |
| 20:09.39 | keesj | I would also certainly look if it is possible to implement it on urjtag. |
| 20:10.57 | dirk2 | 'to implement it on urjtag': implement what? Don't use OpenOCD and use e.g. gdb with urjtag? |
| 20:12.39 | keesj | openocd also has svf support. but when we know what to do it can be as simple as |
| 20:13.02 | keesj | "don't" reset the damm thing once initialized. |
| 20:13.58 | keesj | My biggest fear is that we need adaptive clocking or something that we can simply not do |
| 20:14.24 | dirk2 | adaptive clocking? RTCK? |
| 20:14.32 | keesj | yes |
| 20:44.01 | *** join/#openjtag pytey (n=pytey@84.233.192.144) |
| 21:12.55 | *** join/#openjtag ft_ (n=pytey@84.233.192.144) |
| 21:16.56 | *** join/#openjtag pytey (n=pytey@84.233.192.144) |
| 22:12.40 | *** join/#openjtag pirho_ (i=pirho@gateway/gpg-tor/key-0x2CEEC9CB) |
| 22:13.04 | *** join/#openjtag pytey (n=pytey@84.233.192.144) |
| 23:04.14 | *** join/#openjtag nslu2-log (n=nslu2-lo@limax.nslu2-linux.org) |
| 23:06.11 | *** join/#openjtag nslu2-log (n=nslu2-lo@limax.nslu2-linux.org) |