Re: [Openocd-development] Mailing list?
Maybe you should add an item to the Sourceforge Operations Group issue tracker: http://sourceforge.net/tracker/?func=addgroup_id=160677atid=816806 Since it seems to not be looked at, a more direct approach may be appropriate. -Original Message- From: openocd-development-boun...@lists.berlios.de [mailto:openocd- development-boun...@lists.berlios.de] On Behalf Of Spencer Oliver Sent: Monday, December 19, 2011 9:44 AM To: Freddie Chopin Cc: openocd-development@lists.berlios.de Subject: Re: [Openocd-development] Mailing list? On 17 December 2011 16:49, Freddie Chopin freddie_cho...@op.pl wrote: Hi! From what I've read berlios has found some funding so it's going to operate, but will the mailing lists be kept online? Sourceforge deleted the list, there is an archive available, so what's so hard in undeleting it? I wish i could answer but we are still waiting for sf to fix the issue. The original sf ticket is here, feel free to bombard sf until they sort it out: https://sourceforge.net/apps/trac/sourceforge/ticket/22906 So far i have tried the trac ticket, irc and email - i have been promised that the priority has been raised - and then nothing. I am also trying to get an email for the support manager to complain as i believe this is not acceptable - the mailing list is the main communication channel for OpenOCD. Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Patch for at91sam9263 tcl
git commit --amend --sign-off Or something like that. It's complaining that there's no Signed Off By line in the commit message. Mick Davis mi...@goanna.iinet.net.au wrote: Hi I have the attached trivial patch. It fixes a missing brace in a tcl script. (I've had no success with the instructions in HACKING. I get the following error for the push. Its not clear to me if I need some further authorization. I've also tried different username settings.) ! [remote rejected] HEAD - refs/for/master (not Signed-off-by author/committer/uploader) error: failed to push some refs to 'ssh://mi...@openocd.zylin.com:29418/openocd.git' -- Mick Davis Goanna Technologies Pty Ltd +61 8 9444 2634 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] git gui
-Original Message- From: openocd-development-boun...@lists.berlios.de [mailto:openocd- development-boun...@lists.berlios.de] On Behalf Of Pete Batard Sent: Wednesday, October 26, 2011 6:26 AM To: openocd-development@lists.berlios.de Subject: Re: [Openocd-development] git gui On 2011.10.26 06:07, Øyvind Harboe wrote: On Wed, Oct 26, 2011 at 2:12 AM, Peter Stugepe...@stuge.se wrote: jim norris wrote: For those using a git gui, what are you using? On which system? For Windows, there is Git Extensions and TortoiseGit. The Git Extensions looked less slick than TortoiseGit last time I looked, but TortoisGit on the other hand lacked fundamental functionality. I recommend Gerrit. Gerrit makes a lot of the nastier concepts, like interactive rebasing and communication easier. From my experience TortoiseGit is a step down the wrong path. It makes things easier than possible, i.e. it tosses hard concepts out of the window. Where is the interactive rebase functionality? You mean, this [1]? For the record, I have been using TortoiseGit pretty much on a daily basis, for almost two years now and from my personal experience, not only have I found it filling pretty much all of my git needs (besides, it's based on msys-git, so commandline git is only one click away), but also, unlike Peter, I found that if there's one tool that benefits greatly from having a solid GUI, it has to be git. Who'd want to go back to using commandline for diffs, log, or branch switching, when you have a GUI with *easy* navigation at your fingertips [2]?. Also, judging from the general praise for gerrit, which also provides a solid GUI frontend albeit web based (hence more complex for regular git users to setup on their own -- I wouldn't advocate it as a solution for a user who simply wants a GUI on their machine), I can only assume that many have come to share the view that some GUI ontop of git actually does wonders. Thus, do you guys, who seem to be opposed to the use of TortoiseGit, have better evidence to back up your claims? If not, I would advise Jim to take Øyvind and Peter's advice with a grain of salt, or at least also consider the advice of someone who, through nearly two years of continuous usage, has reason to believe that using TortoiseGit has actually increased their git productivity. Of course, just like Peter and Øyvind's, this is merely an opinion. Regards, /Pete [1] http://img689.imageshack.us/img689/697/tgitinteractiverebase.png [2] http://img190.imageshack.us/img190/3281/tgitdiff.png ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development I guess TortoiseGit has come a long way since I last looked. I have seen it corrupt a repository[1], but that could be a known bug that's long- fixed. I've always used Git on the command line, and when trying to use Mercurial, I find it's command-line interface quite irritating in how much it doesn't do. I generally use the Git command-line interface alongside gitk, using gitk like a GPS navigator of the repo history; It shows me where I've been, where I am now, and gives me easy quick reference to where I want to be, making command line tools far more palatable. I do use the git gui blame tool. I also mentioned git gui before; It seems to lack functionality upon first look, but has excellent display and browsing ability. - Alex ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Can't push...
There's no x in the url. openocd.zylin.com -Original Message- From: openocd-development-boun...@lists.berlios.de [mailto:openocd- development-boun...@lists.berlios.de] On Behalf Of jim norris Sent: Wednesday, October 26, 2011 6:49 PM To: Spencer Oliver Cc: Openocd-development@lists.berlios.de Subject: Re: [Openocd-development] Can't push... Here's the verbose output. $ git push -v review Pushing to ssh://jnor...@openocd.zylinx.com:29418/openocd.git ssh: connect to host openocd.zylinx.com port 29418: Connection timed out fatal: The remote end hung up unexpectedly ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] git gui
I actually use git gui. It's not quite as slick as some other options, but it has a lot of functionality in it. -Original Message- From: openocd-development-boun...@lists.berlios.de [mailto:openocd- development-boun...@lists.berlios.de] On Behalf Of Peter Stuge Sent: Tuesday, October 25, 2011 7:13 PM To: openocd-development@lists.berlios.de Subject: Re: [Openocd-development] git gui jim norris wrote: For those using a git gui, what are you using? On which system? For Windows, there is Git Extensions and TortoiseGit. The Git Extensions looked less slick than TortoiseGit last time I looked, but TortoisGit on the other hand lacked fundamental functionality. For Mac, there is GitX which is kinda nice, but also did not have enough functionality last time I looked. There was some payware which looked nice, but I didn't try it and don't recall the name. I find that using the CLI is by far the easiest, and all features are available. //Peter ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] git question.....
Does file3 rely on file2, which relies on file1, or are they all independent? If they're a sequence, then git checkout -b temp HEAD~2 edit file1.c git add file1.c git commit --amend git checkout original branch git rebase temp git push review You don't need to do individual pushes for each commit, as the sequence of commits leading up to the head of the branch off of trunk will create a sequence of patches in Gerrit. -Original Message- From: openocd-development-boun...@lists.berlios.de [mailto:openocd- development-boun...@lists.berlios.de] On Behalf Of jim norris Sent: Tuesday, October 25, 2011 6:58 PM To: Openocd-development@lists.berlios.de Subject: [Openocd-development] git question. I do the following... git add file1.c git commit file1.c git push review git add file2.c git commit file2.c git push review git add file3.c git commit file3.c git push review I then realize I made a mistake in file1.c so... -- make the change git add file1.c git commit --amend file1.c However, the comment message I see when I do the commit is from the commit of file3.c. Is this okay? Or did I do something wrong? I've noticed there's a -C option that indicates to pick up information from a previous commit. Is that what should be used? ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] git question.....
Oh, that should be git rebase -I temp and remove the pick line for the original commit, so that its replacement will be there instead. -Original Message- From: openocd-development-boun...@lists.berlios.de [mailto:openocd- development-boun...@lists.berlios.de] On Behalf Of Austin, Alex Sent: Tuesday, October 25, 2011 8:28 PM To: jim norris; Openocd-development@lists.berlios.de Subject: Re: [Openocd-development] git question. Does file3 rely on file2, which relies on file1, or are they all independent? If they're a sequence, then git checkout -b temp HEAD~2 edit file1.c git add file1.c git commit --amend git checkout original branch git rebase temp git push review You don't need to do individual pushes for each commit, as the sequence of commits leading up to the head of the branch off of trunk will create a sequence of patches in Gerrit. -Original Message- From: openocd-development-boun...@lists.berlios.de [mailto:openocd- development-boun...@lists.berlios.de] On Behalf Of jim norris Sent: Tuesday, October 25, 2011 6:58 PM To: Openocd-development@lists.berlios.de Subject: [Openocd-development] git question. I do the following... git add file1.c git commit file1.c git push review git add file2.c git commit file2.c git push review git add file3.c git commit file3.c git push review I then realize I made a mistake in file1.c so... -- make the change git add file1.c git commit --amend file1.c However, the comment message I see when I do the commit is from the commit of file3.c. Is this okay? Or did I do something wrong? I've noticed there's a -C option that indicates to pick up information from a previous commit. Is that what should be used? ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD Gerrit Review
-Original Message- From: openocd-development-boun...@lists.berlios.de [mailto:openocd- development-boun...@lists.berlios.de] On Behalf Of Jason ... 1.) Threading versions of a patch series together. So, when the maintainer has a chance to look at the thread, he/she can just go to the end of the thread to get the latest version. This would require a hook script in 'git format-patch' to add In-Reply-To: and to do patch versioning (read and detect from output directory?). Possibly, --versioning? Basically, I'm replacing gerrit's Change-Id with smtp's already useful Message-Id and In-Reply-To. Could the Message-Id be set to, exactly, the Change-Id? ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Show of hands for/against gerrit
+2 Reviewed, +1 Verified... :) Having used Gerrit a little bit, where I work, it seems to enforce a workflow that this mailing list already uses. Any submitted patch needs to go through the review process before it is accepted into Trunk. If a patch needs work, a second version can be submitted with the same Change-Id, and the history of reviews for both patches will be attached together, and only the final revision will be accepted into trunk. My only issue is, I wonder where it would be hosted? Can SourceForge do that? What about appspot.com (AppEngine)? - Alex -Original Message- From: openocd-development-boun...@lists.berlios.de [mailto:openocd-development-boun...@lists.berlios.de] On Behalf Of Øyvind Harboe Sent: Thursday, October 06, 2011 4:02 PM To: openocd-development@lists.berlios.de Subject: [Openocd-development] Show of hands for/against gerrit I find gerrit intriguing as a way of managing patches. Can I have a show of hands of contributors for/against/don't care/don't know? -- Øyvind Harboe - Can Zylin Consulting help on your project? US toll free 1-866-980-3434 http://www.zylin.com/ ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Unusual ARM chip
Infineon/Intel Xgold213. (I wasn't sure if I was allowed to mention that in a public forum until today). -Original Message- From: Øyvind Harboe [mailto:oyvind.har...@zylin.com] Sent: Wednesday, May 18, 2011 12:18 AM To: Austin, Alex Cc: openocd-development@lists.berlios.de Subject: Re: [Openocd-development] Unusual ARM chip Which chip? -- Øyvind Harboe Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 87 40 27 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Unusual ARM chip
I am attempting to use OpenOCD with a cellular chipset with an ARM11 and an ARM7+DSP core. I can access it with the Lauterbach debugger, but I find the interface very difficult to use and would prefer OpenOCD. It looks like some sort of TAP controller, perhaps like an OMAP3. Has anyone seen anything like this? Any idea how to get past it? Upon a scan, OpenOCD shows me: alex@msp-clx-aaustin:~$ openocd -f interface/jtagkey2.cfg -c jtag_khz\ 1 Open On-Chip Debugger 0.5.0-dev-00219-g737c9b6-dirty (2010-05-06-14:21) Licensed under GNU GPL v2 For bug reports, read http://openocd.berlios.de/doc/doxygen/bugs.html 1 kHz Info : max TCK change to: 3 kHz Info : clock speed 1 kHz Warn : There are no enabled taps. AUTO PROBING MIGHT NOT WORK!! Warn : AUTO auto0.tap - use jtag newtap auto0 tap -expected-id 0x30180083 ... Warn : AUTO auto0.tap - use ... -irlen 8 Warn : gdb services need one or more targets defined -- Alex Austin Associate Software Engineer Spectrum Design Solutions 110 North 5th Street, Floor 3 Minneapolis, MN 55403 Direct: +1.612.435.5537 Main: +1.612.435.0789 Mobile: +1.651.238.9273 Email: alex.aus...@spectrumdsi.com www.spectrumdsi.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD becoming an Eclipse TCF Agent
Øyvind, I wrote that based purely on briefs that I've read online. I've seen references to TCF using JSON in the transport, but I know nothing beyond that. Unfortunately, I'm not sure my position would allow me to spend work-hours on it, but I may be able to look into it more on my own time. Wouldn't happen very fast, though. Also, I don't think it would be worth doing much until GDB either provides a TCF interface alongside GDB/MI or there is a fork that does. - Alex -Original Message- From: Øyvind Harboe [mailto:oyvind.har...@zylin.com] Sent: Friday, May 13, 2011 12:25 AM To: Austin, Alex Cc: openocd-development@lists.berlios.de Subject: Re: [Openocd-development] OpenOCD becoming an Eclipse TCF Agent Hi Alex, thanks for the insight! This is very interesting Do you know what it would take to implement such a server? A gdb server, that OpenOCD has, has as a lot of optional functionality. What's the minimum that we'd have to do to get started? -- Øyvind Harboe Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 87 40 27 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD becoming an Eclipse TCF Agent
From what I understand, what this would allow such a stackup as: Component Provides ARM Core JTAG OpenocdTCF (addresses only) GDBTCF (interprets symbol table, handles soft breakpoints) My_rtos_xlator TCF (knows where to find thread state tables) Oprofile TCF (keeps statistics of thread and function runtimes) EclipseGUI with full knowledge of thread state and profiling info You could pull out My_rtos_xlator and still have access to function-specific profiling. You could pull out the oprofile layer if you don't need it. You could write My_rtos_xlator in a platform-agnostic manner with GDB and openocd translating it to support whichever target the rtos is running on. -Original Message- From: openocd-development-boun...@lists.berlios.de [mailto:openocd-development-boun...@lists.berlios.de] On Behalf Of Martin Davey Sent: Thursday, May 12, 2011 3:08 PM To: Øyvind Harboe Cc: openocd-development@lists.berlios.de Subject: Re: [Openocd-development] OpenOCD becoming an Eclipse TCF Agent On 12/05/2011 20:22, Øyvind Harboe wrote: So OpenOCD would have a TCF TCP/IP server that would feed output/input from DCC? Why is code required on the target? As I understand it, you can run an agent on the target, or the agent could be like OpenOCD and bridge between the JTAG and TCF connnection. The communication between TCF and the Agent is JSON. Extra services like target discovery etc would make the whole thing very slick. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] ARM 1176
I know ARM11 support is incomplete, but I was hoping to be able to read/write flash. == alex@msp-clx-aaustin:~/Projects/openocd$ ./src/openocd -f interface/jtagkey2.cfg \ -c jtag newtap xgold cpu -irlen 5 -ircapture 0x1 -irmask 0x1f -expected-id 0x30180083 \ -c target create xgold.cpu arm11 -endian little -chain-position xgold.cpu -variant arm1176 \ -c jtag_khz 1 Open On-Chip Debugger 0.5.0-dev-00876-g15c5d05 (2011-05-10-14:17) Licensed under GNU GPL v2 For bug reports, read http://openocd.berlios.de/doc/doxygen/bugs.html Info : only one transport option; autoselect 'jtag' xgold.cpu 1 kHz Info : max TCK change to: 3 kHz Info : clock speed 1 kHz Info : JTAG tap: xgold.cpu tap/device found: 0x30180083 (mfg: 0x041, part: 0x0180, ver: 0x3) Error: IR capture error at bit 5, saw 0x01 not 0x...3 Warn : Bypassing JTAG setup events due to errors Error: 'arm11 target' JTAG error SCREG OUT 0x00 Error: unexpected ARM11 ID code Polling target failed, GDB will be halted. Polling again in 100ms Polling target failed, GDB will be halted. Polling again in 300ms Polling target failed, GDB will be halted. Polling again in 700ms Polling target failed, GDB will be halted. Polling again in 1500ms Polling target failed, GDB will be halted. Polling again in 3100ms Polling target failed, GDB will be halted. Polling again in 6300ms (and it continues) What does the IR capture error indicate? What does SCREG OUT 0x00 mean? Is the openocd scan still reading the IDCODE wrong? I do know that it is an ARM1176. Alex Austin Associate Software Engineer Spectrum Design Solutions 110 North 5th Street, Floor 3 Minneapolis, MN 55403 Direct: +1.612.435.5537 Main: +1.612.435.0789 Mobile: +1.651.238.9273 Email: alex.aus...@spectrumdsi.com www.spectrumdsi.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] ARM 1176
BTW, a scan shows: == alex@msp-clx-aaustin:~/Projects/openocd$ ./src/openocd -f interface/jtagkey2.cfg -c jtag_khz 1000 Open On-Chip Debugger 0.5.0-dev-00876-g15c5d05 (2011-05-10-14:17) Licensed under GNU GPL v2 For bug reports, read http://openocd.berlios.de/doc/doxygen/bugs.html Info : only one transport option; autoselect 'jtag' 1000 kHz Info : max TCK change to: 3 kHz Info : clock speed 1000 kHz Warn : There are no enabled taps. AUTO PROBING MIGHT NOT WORK!! Warn : AUTO auto0.tap - use jtag newtap auto0 tap -expected-id 0x30180083 ... Warn : AUTO auto0.tap - use ... -irlen 8 Warn : gdb services need one or more targets defined == -Original Message- From: openocd-development-boun...@lists.berlios.de [mailto:openocd-development-boun...@lists.berlios.de] On Behalf Of Austin, Alex Sent: Tuesday, May 10, 2011 2:34 PM To: openocd-development@lists.berlios.de Subject: [Openocd-development] ARM 1176 I know ARM11 support is incomplete, but I was hoping to be able to read/write flash. == alex@msp-clx-aaustin:~/Projects/openocd$ ./src/openocd -f interface/jtagkey2.cfg \ -c jtag newtap xgold cpu -irlen 5 -ircapture 0x1 -irmask 0x1f -expected-id 0x30180083 \ -c target create xgold.cpu arm11 -endian little -chain-position xgold.cpu -variant arm1176 \ -c jtag_khz 1 Open On-Chip Debugger 0.5.0-dev-00876-g15c5d05 (2011-05-10-14:17) Licensed under GNU GPL v2 For bug reports, read http://openocd.berlios.de/doc/doxygen/bugs.html Info : only one transport option; autoselect 'jtag' xgold.cpu 1 kHz Info : max TCK change to: 3 kHz Info : clock speed 1 kHz Info : JTAG tap: xgold.cpu tap/device found: 0x30180083 (mfg: 0x041, part: 0x0180, ver: 0x3) Error: IR capture error at bit 5, saw 0x01 not 0x...3 Warn : Bypassing JTAG setup events due to errors Error: 'arm11 target' JTAG error SCREG OUT 0x00 Error: unexpected ARM11 ID code Polling target failed, GDB will be halted. Polling again in 100ms Polling target failed, GDB will be halted. Polling again in 300ms Polling target failed, GDB will be halted. Polling again in 700ms Polling target failed, GDB will be halted. Polling again in 1500ms Polling target failed, GDB will be halted. Polling again in 3100ms Polling target failed, GDB will be halted. Polling again in 6300ms (and it continues) == What does the IR capture error indicate? What does SCREG OUT 0x00 mean? Is the openocd scan still reading the IDCODE wrong? I do know that it is an ARM1176. Alex Austin Associate Software Engineer Spectrum Design Solutions 110 North 5th Street, Floor 3 Minneapolis, MN 55403 Direct: +1.612.435.5537 Main: +1.612.435.0789 Mobile: +1.651.238.9273 Email: alex.aus...@spectrumdsi.com www.spectrumdsi.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD Cortex-A8 / S5PC100 support...?
I imagine the problem is voltage, actually. The OMAP3530 and other similar devices run their JTAG ports at 1.8V, and the ARM-USB-OCD doesn't like working below 3V. From: openocd-development-boun...@lists.berlios.de [openocd-development-boun...@lists.berlios.de] On Behalf Of Nick Pelling [nickpell...@nanodome.com] Sent: Friday, December 03, 2010 12:52 PM To: openocd-development@lists.berlios.de Subject: [Openocd-development] OpenOCD Cortex-A8 / S5PC100 support...? Hi everyone, I've just plugged my trusty old Olimex ARM-USB-OCD (the Swiss Army Knife of JTAG debuggers) into my shiny new S5PC100-based board and... I'm struggling to see how to get it working even slightly. Has anyone got anywhere with the s5pc100 or other CoreSight-based Cortex A8s (apart from the OMAP3530 as per http://elinux.org/BeagleBoardOpenOCD )? Firas Achkar mentioned trying this on the urbetter board (which I think is actually the original ODroid) a month ago, as did Matt Hsu in November 2009. But trying the latest openocd's autoprobe (as David Brownell suggested then) didn't seem to produce anything so revealing as an ID code. Incidentally, I've read through the CoreSight chapter in the latest Samsung datasheet but that had precisely nothing so useful as a TAP ID code or a DAP ID code to get started. Stepping through every occurrence of JTAG also revealed nothing useful. Any suggestions? Has anyone tried the same thing for the S5PC110 (as per the ODroid-T etc)? Might there be some hidden nest of Samsung SoC OpenOCD developers in a far-flung corner of Korea? Cheers, Nick Pelling ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] git submodule failure behind HTTP-only proxy
Personally, I prefer the git protocol if possible. It's much faster and has lower overhead. I think the best idea would be to add .gitmodules to .gitignore and have the bootstrap script modify .gitmodules to point to either git: or http: depending on some user preference. Øyvind Harboe oyvind.har...@zylin.com wrote: My workaround is to manually edit .git/config before the update. I replaced this section [submodule tools/git2cl] url = git://repo.or.cz/git2cl.git by [submodule tools/git2cl] url = http://repo.or.cz/r/git2cl.git This is not a workaround, it's a solution! :-) The only question is whether we should commit the change. -- Øyvind Harboe Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 63 25 00 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD for Jlink JTAG
Try a lower clock speed. That looks like signal integrity issues. Either that, or one of the wires isn't connected as solidly as it could be. elex S elexs...@gmail.com wrote: Hello, I am new to JTAG and OpenOCD. I want to use Jlink-JTAG with my PHYTEC LPC3250 board. Hence, I have downloaded code from http://developer.berlios.de/projects/openocd;. I built the code as follows: cd openocd-0.4.0 ./configure --enable-jlink make make install Then I tried 'openocd executable as follows sudo openocd -f /usr/local/share/openocd/scripts/interface/jlink.cfg -f /usr/local/share/openocd/scripts/board/phytec_lpc3250.cfg -c 'reset_config trst_and_srst' However application fails to connect with JTAG and gets hang in between. Could you please provide me some pointers. I have captured log: Open On-Chip Debugger 0.4.0 (2010-11-23-12:13) Licensed under GNU GPL v2 For bug reports, read http://openocd.berlios.de/doc/doxygen/bugs.html jtag_nsrst_delay: 200 jtag_ntrst_delay: 1 200 kHz trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain dcc downloads are enabled trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain Info : J-Link initialization started / target CPU reset initiated Error: J-Link command EMU_CMD_VERSION failed (-110) Info : J-Link JTAG Interface ready Info : clock speed 200 kHz Info : JTAG tap: lpc3250.sjc tap/device found: 0x00ff (mfg: 0x07f, part: 0x, ver: 0x0) Warn : JTAG tap: lpc3250.sjc UNEXPECTED: 0x00ff (mfg: 0x07f, part: 0x, ver: 0x0) Error: JTAG tap: lpc3250.sjc expected 1 of 1: 0x1b900f0f (mfg: 0x787, part: 0xb900, ver: 0x1) Info : JTAG tap: lpc3250.cpu tap/device found: 0x00ff (mfg: 0x07f, part: 0x, ver: 0x0) Warn : JTAG tap: lpc3250.cpu UNEXPECTED: 0x00ff (mfg: 0x07f, part: 0x, ver: 0x0) Error: JTAG tap: lpc3250.cpu expected 1 of 1: 0x17900f0f (mfg: 0x787, part: 0x7900, ver: 0x1) Warn : Unexpected idcode after end of chain: 128 0xdec65cff Warn : Unexpected idcode after end of chain: 160 0x00da Warn : Unexpected idcode after end of chain: 192 0x Warn : Unexpected idcode after end of chain: 224 0x Warn : Unexpected idcode after end of chain: 256 0x Warn : Unexpected idcode after end of chain: 288 0x Warn : Unexpected idcode after end of chain: 320 0x Warn : Unexpected idcode after end of chain: 352 0xe400 Warn : Unexpected idcode after end of chain: 384 0xe8d0ced2 Warn : Unexpected idcode after end of chain: 416 0x60606440 Warn : Unexpected idcode after end of chain: 448 0x60645a66 Warn : Unexpected idcode after end of chain: 480 0xfe407260 Warn : Unexpected idcode after end of chain: 512 0x1b900f0f Warn : Unexpected idcode after end of chain: 544 0x17926f0f Error: double-check your JTAG setup (interface, speed, missing TAPs, ...) Info : JTAG tap: lpc3250.sjc tap/device found: 0x00ff (mfg: 0x07f, part: 0x, ver: 0x0) Warn : JTAG tap: lpc3250.sjc UNEXPECTED: 0x00ff (mfg: 0x07f, part: 0x, ver: 0x0) Error: JTAG tap: lpc3250.sjc expected 1 of 1: 0x1b900f0f (mfg: 0x787, part: 0xb900, ver: 0x1) Info : JTAG tap: lpc3250.cpu tap/device found: 0x00ff (mfg: 0x07f, part: 0x, ver: 0x0) Warn : JTAG tap: lpc3250.cpu UNEXPECTED: 0x00ff (mfg: 0x07f, part: 0x, ver: 0x0) Error: JTAG tap: lpc3250.cpu expected 1 of 1: 0x17900f0f (mfg: 0x787, part: 0x7900, ver: 0x1) Warn : Unexpected idcode after end of chain: 480 0xfeff Warn : Unexpected idcode after end of chain: 512 0x1b900f0f Warn : Unexpected idcode after end of chain: 544 0x17926f0f Error: double-check your JTAG setup (interface, speed, missing TAPs, ...) Command handler execution failed Warn : jtag initialization failed; try 'jtag init' again. ^C Please let me know, If I am missing some steps. Regards, Surendra ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Need help with wiggler and pxa270
Try it slower. Try 25kHz to start and see how that goes.
Oleg Kravchenko o...@kaa.org.ua wrote:
Hello!
I am assemble this cable
http://downloads.amilda.org/MODs/JTAG/wiggler.gifand I want try
openocd with my pocket pc based on pxa270 cpu, but I can't
setup proper config file and as result I am received lots of errors :(
Help please!
# cat openocd.cfg
interface parport
parport_port 0
parport_cable wiggler2
jtag_khz 100
if { [info exists CHIPNAME] } {
set _CHIPNAME $CHIPNAME
} else {
set _CHIPNAME pxa270
}
if { [info exists ENDIAN] } {
set _ENDIAN $ENDIAN
} else {
set _ENDIAN little
}
if { [info exists CPUTAPID ] } {
set _CPUTAPID $CPUTAPID
} else {
set _CPUTAPID 0x79265013
}
jtag_nsrst_delay 260
jtag_ntrst_delay 0
reset_config trst_and_srst separate
set _TARGETNAME $_CHIPNAME.cpu
jtag newtap $_CHIPNAME cpu -irlen 7 -ircapture 0x1 -irmask 0x7f -expected-id
$_CPUTAPID
target create $_TARGETNAME xscale -endian $_ENDIAN -chain-position
$_TARGETNAME -variant pxa27x
# maps to PXA internal RAM. If you are using a PXA255
# you must initialize SDRAM or leave this option off
#_TARGETNAME configure -work-area-phys 0x5c00 -work-area-size 0x1
-work-area-backup 0
# openocd
Open On-Chip Debugger 0.4.0 (2010-10-12-21:17)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.berlios.de/doc/doxygen/bugs.html
parport port = 0x0
100 kHz
jtag_nsrst_delay: 260
jtag_ntrst_delay: 0
trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain
Info : pxa270.cpu: hardware has 2 breakpoints and 2 watchpoints
Info : clock speed 100 kHz
Info : JTAG tap: pxa270.cpu tap/device found: 0x79265013 (mfg: 0x009, part:
0x9265, ver: 0x7)
Info : accepting 'gdb' connection from 0
Warn : acknowledgment received, but no packet pending
undefined debug reason 6 - target needs reset
Warn : target not halted
Warn : target not halted
Warn : target not halted
Warn : target not halted
Warn : target not halted
Warn : target not halted
Warn : target not halted
Warn : target not halted
Warn : target not halted
Info : JTAG tap: pxa270.cpu tap/device found: 0x79265013 (mfg: 0x009, part:
0x9265, ver: 0x7)
target state: halted
target halted in ARM state due to debug-request, current mode: Supervisor
cpsr: 0x88d3 pc: 0x
MMU: disabled, D-Cache: disabled, I-Cache: disabled
(processor reset)
Warn : Bad value '01' captured during DR or IR scan:
Warn : check_value: 0x02
Warn : check_mask: 0x06
Error: JTAG error while reading TX
error while polling TX register, reset CPU
Error: time out writing RX register
Error: time out writing RX register
Error: time out writing RX register
Warn : Bad value '01' captured during DR or IR scan:
Warn : check_value: 0x02
Warn : check_mask: 0x06
Error: JTAG error while writing RX
Error: time out writing RX register
Error: time out writing RX register
Error: time out writing RX register
Error: time out writing RX register
Error: time out writing RX register
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [BUG] Driver for USB-Blaster (partially) broken
Can you git bisect to find the problem commit? Felix dg1...@gmx.de wrote: Hi, the driver for the Altera USB-Blaster and compatibles in version 0.4.0 (and up to the current git snapshot) is (at least partially) broken. Somewhere in the merge process, the bit which enables the output (and the LED in the original altera usb blaster) must have got lost. It was included in the first version supplied to the mailing list in december 2009. At the moment the output of the CPLD which drives the JTAG (and the GPIO) pins just stays in tristate (at least with the original USB Blaster, maybe some clones dont use this functionality and provide always-enabled outputs) and does not do anything. After fixing this bug I ran into some speed issues (maybe a problem of libftdi). JTAG communication basically works, but is incredibly slow (TCLK about 100 Hz - not kHz). So its not really usable for debugging in this way (as I said, maybe this is related to libftdi). I'll try to provide a patch for that if no one else is working on it. Felix ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 2/2] Added Seralyzer
Sorry, first time I've used git-send-email. Didn't realize the
commit message was so sparse.
While the Seralyzer is currently an internal-only tool in our
Company, I don't think adding it to upstream will have any effect
on the maintainability of the ft2232 driver.
-Original Message-
From: a...@compbox [mailto:a...@compbox]
Sent: Monday, September 27, 2010 4:04 PM
To: openocd-development@lists.berlios.de
Cc: Austin, Alex
Subject: [PATCH 2/2] Added Seralyzer
---
src/jtag/drivers/ft2232.c | 89
+++
tcl/interface/seralyzer.cfg |9
2 files changed, 98 insertions(+), 0 deletions(-)
create mode 100644 tcl/interface/seralyzer.cfg
diff --git a/src/jtag/drivers/ft2232.c b/src/jtag/drivers/ft2232.c
index 01af152..fc91329 100644
--- a/src/jtag/drivers/ft2232.c
+++ b/src/jtag/drivers/ft2232.c
@@ -175,6 +175,7 @@ static int usbjtag_init(void);
static int jtagkey_init(void);
static int lm3s811_jtag_init(void);
static int icdi_jtag_init(void);
+static int seralyzer_init(void);
static int olimex_jtag_init(void);
static int flyswatter_init(void);
static int turtle_init(void);
@@ -193,6 +194,7 @@ static int lisa_l_init(void);
/* reset procedures for supported layouts */
static void ftx23_reset(int trst, int srst);
static void jtagkey_reset(int trst, int srst);
+static void seralyzer_reset(int trst, int srst);
static void olimex_jtag_reset(int trst, int srst);
static void flyswatter_reset(int trst, int srst);
static void turtle_reset(int trst, int srst);
@@ -310,6 +312,10 @@ static const struct ft2232_layout
ft2232_layouts[] =
.reset = ftx23_reset,
.blink = lisa_l_blink,
.channel = INTERFACE_B,
+},
+ { .name = seralyzer,
+ .init = seralyzer_init,
+ .reset = seralyzer_reset,
},
{ .name = NULL, /* END OF TABLE */ },
};
@@ -1414,6 +1420,34 @@ static void ftx23_reset(int trst, int srst)
buffer_write(low_direction);
}
+static void seralyzer_reset(int trst, int srst)
+{
+ if (trst == 1)
+ {
+ low_output = ~nTRST;
+ }
+ else if (trst == 0)
+ {
+ low_output |= nTRST;
+ }
+
+ if (srst == 0)
+ {
+ low_output = ~nSRST;
+ }
+ else if (srst == 1)
+ {
+ low_output |= nSRST;
+ }
+
+ /* command set data bits low byte */
+ buffer_write(0x80);
+ buffer_write(low_output);
+ buffer_write(low_direction);
+ LOG_DEBUG(trst: %i, srst: %i, low_output: 0x%2.2x,
low_direction: 0x%2.2x, trst, srst, low_output,
+ low_direction);
+}
+
static void jtagkey_reset(int trst, int srst)
{
enum reset_types jtag_reset_config = jtag_get_reset_config();
@@ -2686,6 +2720,61 @@ static int redbee_init(void)
return ERROR_OK;
}
+static int seralyzer_init(void)
+{
+ uint8_t buf[3];
+ uint32_t bytes_written;
+
+ low_output= 0x08;
+ low_direction = 0x6b;
+
+ if (strcmp(layout-name, seralyzer) == 0)
+ {
+ nTRST= 0x40;
+ nTRSTnOE = 0x00; /* no output enable for nTRST */
+ nSRST= 0x20;
+ nSRSTnOE = 0x00; /* no output enable for nSRST */
+ }
+ else
+ {
+ LOG_ERROR(BUG: seralyzer_init called for non seralyzer
layout);
+ exit(-1);
+ }
+
+ enum reset_types jtag_reset_config = jtag_get_reset_config();
+ if (jtag_reset_config RESET_TRST_OPEN_DRAIN)
+ {
+ LOG_ERROR(can't set nTRST to open-drain on the
Seralyzer);
+ }
+ else
+ {
+ low_output |= nTRST;
+ }
+
+ if (jtag_reset_config RESET_SRST_PUSH_PULL)
+ {
+ LOG_ERROR(can't set nSRST to push-pull on the Seralyzer);
+ }
+ else
+ {
+ low_output |= nSRST;
+ }
+
+ /* initialize low byte for jtag */
+ buf[0] = 0x80; /* command set data bits low byte */
+ buf[1] = low_output;/* value (TMS = 1,TCK = 0, TDI = 0, nOE =
0) */
+ buf[2] = low_direction; /* dir (output = 1), TCK/TDI/TMS = out,
TDO = in, nOE = out */
+ LOG_DEBUG(%2.2x %2.2x %2.2x, buf[0], buf[1], buf[2]);
+
+ if (((ft2232_write(buf, 3, bytes_written)) != ERROR_OK) ||
(bytes_written != 3))
+ {
+ LOG_ERROR(couldn't initialize FT2232 with 'JTAGkey'
layout);
+ return ERROR_JTAG_INIT_FAILED;
+ }
+
+ return ERROR_OK;
+}
+
static int jtagkey_init(void)
{
uint8_t buf[3];
diff --git a/tcl/interface/seralyzer.cfg b/tcl/interface/seralyzer.cfg
new file mode 100644
index 000..5c89fb2
--- /dev/null
+++ b/tcl/interface/seralyzer.cfg
@@ -0,0 +1,9 @@
+#
+# SpectrumDSI Seralyzer
+#
+
+interface ft2232
+ft2232_device_desc USB Serial Analyzer v0.2
+ft2232_layout seralyzer
+ft2232_vid_pid 0x0403 0x6011
Re: [Openocd-development] Possible reset halt startup bug?
Anyone else get this message? Is it coincidence that I understand it? Gary Carlson gcarl...@carlson-minot.com wrote: I am just curious if the small problem that I discovered this afternoon can be duplicated by any other developers/users using other jlink dongles (or even non-jlink dongles). The first time through a reset halt seems to fail, but subsequently operates flawlessly thereafter. If anyone has some interest, this is the process: 1. Shutdown openocd (if already running). 2. Start openocd using the appropriate config file for your board. 3. Open telnet session and type the commands listed in blue: Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. Open On-Chip Debugger halt poll background polling: on TAP: at91sam9g20.cpu (enabled) target state: halted target halted in ARM state due to breakpoint, current mode: Supervisor cpsr: 0x00d3 pc: 0x MMU: disabled, D-Cache: disabled, I-Cache: disabled reset halt JTAG tap: at91sam9g20.cpu tap/device found: 0x0792603f (mfg: 0x01f, part: 0x7926, ver: 0x0) timed out while waiting for target halted TARGET: at91sam9g20.cpu - Not halted Command handler execution failed in procedure 'reset' called at file command.c, line 650 called at file command.c, line 361 reset halt JTAG tap: at91sam9g20.cpu tap/device found: 0x0792603f (mfg: 0x01f, part: 0x7926, ver: 0x0) target state: halted target halted in ARM state due to breakpoint, current mode: Supervisor cpsr: 0x00d3 pc: 0x MMU: disabled, D-Cache: disabled, I-Cache: disabled NOTE! DCC downloads have not been enabled, defaulting to slow memory writes. Type 'help dcc'. NOTE! Severe performance degradation without fast memory access enabled. Type 'help fast'. Gary ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Possible reset halt startup bug?
And that is not, at all, what I saw in the quoted text area. I only saw the phrase Iyi ge which is Turkish for Good development . Austin, Alex alex.aus...@spectrumdsi.com wrote: Anyone else get this message? Is it coincidence that I understand it? Gary Carlson gcarl...@carlson-minot.com wrote: I am just curious if the small problem that I discovered this afternoon can be duplicated by any other developers/users using other jlink dongles (or even non-jlink dongles). The first time through a reset halt seems to fail, but subsequently operates flawlessly thereafter. If anyone has some interest, this is the process: 1. Shutdown openocd (if already running). 2. Start openocd using the appropriate config file for your board. 3. Open telnet session and type the commands listed in blue: Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. Open On-Chip Debugger halt poll background polling: on TAP: at91sam9g20.cpu (enabled) target state: halted target halted in ARM state due to breakpoint, current mode: Supervisor cpsr: 0x00d3 pc: 0x MMU: disabled, D-Cache: disabled, I-Cache: disabled reset halt JTAG tap: at91sam9g20.cpu tap/device found: 0x0792603f (mfg: 0x01f, part: 0x7926, ver: 0x0) timed out while waiting for target halted TARGET: at91sam9g20.cpu - Not halted Command handler execution failed in procedure 'reset' called at file command.c, line 650 called at file command.c, line 361 reset halt JTAG tap: at91sam9g20.cpu tap/device found: 0x0792603f (mfg: 0x01f, part: 0x7926, ver: 0x0) target state: halted target halted in ARM state due to breakpoint, current mode: Supervisor cpsr: 0x00d3 pc: 0x MMU: disabled, D-Cache: disabled, I-Cache: disabled NOTE! DCC downloads have not been enabled, defaulting to slow memory writes. Type 'help dcc'. NOTE! Severe performance degradation without fast memory access enabled. Type 'help fast'. Gary ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] ST-Link with OpenOCD?
At that level, it may make sense to build a separate GDB server. The GDB remote protocol is not very difficult, and I've done it in HL languages. Contact me off-list if you'd like help doing so. - Alex -Original Message- From: openocd-development-boun...@lists.berlios.de [mailto:openocd- development-boun...@lists.berlios.de] On Behalf Of Spencer Oliver Sent: Tuesday, March 23, 2010 9:02 AM To: simon qian Cc: openocd-development@lists.berlios.de Subject: Re: [Openocd-development] ST-Link with OpenOCD? On 23/03/2010 10:12, simon qian wrote: ST doesn't open the protocol of ST-Link, so it's impossible to support it in OpenOCD. I have 2 ST-Link sent by vendor of ST, but now, they are Versaloon. ST sent me the api, it is based on mass storage device. They are happy for openocd to support it. The current issue is that it is high level access only, eg. Step Core, Read registers etc. So some changes are required to support this kind of dongle. Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Someone using OpenOCD with Maxim MAXQ622?
-Original Message- From: openocd-development-boun...@lists.berlios.de [mailto:openocd- development-boun...@lists.berlios.de] On Behalf Of Michelle Konzack Sent: Thursday, March 04, 2010 5:20 PM To: openocd-development@lists.berlios.de Subject: Re: [Openocd-development] Someone using OpenOCD with Maxim MAXQ622? ... Do you know a chip which is 1) physical small 2) possibel TSOP, QFP or equivalent 3) consumes ony som mA of energy 4) mostly automotive 5) 1x I²C 6) 1x SPI and chip one has either a) 1x USB device b) 1x CAN Sorry, but any ARM7TDMI suck to much STM32F103 - I2C, SPI, CAN and USB. Available in both qfn and qfp, can be clocked as slow as you want. Only the on-chip peripherals will take notable power, and they can all be selectively shut off. Otherwise, does anyone know if we support PIC32 yet? It is a MIPS m4K. - Alex ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD auto-config
For interface, it just tries all the interface definitions in /usr/local/share/openocd/scripts/interface. Whichever one is detected last is then loaded with an empty scan chain, and it should report all the detected TAPs on the chain. Note, that's just the test code which tests a wrapper class. Look at the bottom in the if __name__ == '__main__': section. -Original Message- From: Xiaofan Chen [mailto:xiaof...@gmail.com] Sent: Friday, February 19, 2010 1:17 AM To: Austin, Alex Cc: openocd-development@lists.berlios.de Subject: Re: [Openocd-development] OpenOCD auto-config On Thu, Feb 18, 2010 at 2:17 PM, Austin, Alex alex.aus...@spectrumdsi.com wrote: Just starting to write a wrapper to auto-config openocd. Using python, it's a class that attempts to wrap openocd configuration. So far it doesn't do much, but I would appreciate any comments anyone has. Go ahead and run it on your machines (only Linux supported ATM) as it doesn't write to any files except /dev/null. What does it do right now? Just finding out the interface? I actually have the Luminary EK-LM3S1968 instead of LM3S811. [mc...@myfreebsd ~/Downloads]$ pythin openocd.py bash: pythin: command not found [mc...@myfreebsd ~/Downloads]$ python openocd.py Finding interfaces... Found dummy Found luminary Found luminary-lm3s811 Found jlink -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] OpenOCD auto-config
Just starting to write a wrapper to auto-config openocd. Using python, it's a class that attempts to wrap openocd configuration. So far it doesn't do much, but I would appreciate any comments anyone has. Go ahead and run it on your machines (only Linux supported ATM) as it doesn't write to any files except /dev/null. Be sure to edit the top to locate openocd correctly (Right now, it assumes /usr/local). I'll comment it tomorrow when I'm less brain- fried. Enjoy, - Alex Austin openocd.py Description: openocd.py ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] dsp56371 crash
Version in use: v0.4.0-rc1-194-gf7a6e62 Configuration: ./configure --enable-maintainer-mode --enable-jlink --enable-ft2232_libftdi --enable-usb_blaster_libftdi --enable-amtjtagaccel CFLAGS=-O0\ -g3 Config file: source [find interface/axm0432.cfg] set CPUTAPID 0x01c0001d source [find target/dsp56321.cfg] jtag_khz 1000 openocd segfaults upon connecting to it. I've tracked it down to target_get_gdb_reg_list being called when target-type-get_gdb_reg_list is null. Tracing back to where the target-type comes from, it never gets set in dsp563xx.c, so is null. Why isn't this set? If it's not supposed to be set, why is target_get_gdb_reg_list being called? ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] dsp56371 crash
The GDB in question is the gdb56300.exe provided by freescale, running under WINE. I had the source for it at one time, but I've somehow managed to misplace it. From: David Brownell [davi...@pacbell.net] Sent: Saturday, February 13, 2010 5:52 AM To: openocd-development@lists.berlios.de Cc: Austin, Alex Subject: Re: [Openocd-development] dsp56371 crash On Saturday 13 February 2010, Austin, Alex wrote: openocd segfaults upon connecting to it. I've tracked it down to target_get_gdb_reg_list being called when target-type-get_gdb_reg_list is null. Tracing back to where the target-type comes from, it never gets set in dsp563xx.c, so is null. Why isn't this set? Good question. Which GDB version were you using? If it's not supposed to be set, why is target_get_gdb_reg_list being called? Another good question. It shouldn't crash, regardless. Could you maybe come up with a quick patch to prevent 0.4.0 from crashing? I don't know that you'd be able to talk with GDB without that support. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Problem building Oenocd (Master branch of Git)
The master branch tip changes relatively often. Can you run git describe and tell us the result? From: openocd-development-boun...@lists.berlios.de [openocd-development-boun...@lists.berlios.de] On Behalf Of EG [guent...@striges.de] Sent: Friday, February 12, 2010 5:51 AM To: openocd-development@lists.berlios.de Subject: [Openocd-development] Problem building Oenocd (Master branch of Git) Hi there, I've received the master branch by GIT, have run bootstrap, tried to compile it under MingW, it compiles fine except the last link for openocd.exe, it states: make[4]: Entering directory `/home/Enrico/openocd/src' /bin/sh ../libtool --mode=link gcc -std=gnu99 -g -O2 -I/home/enrico/ocd_all/include -D__USE_MINGW_ANSI_STDIO -Wall -Wstrict-prototypes -Wformat-security -Wextra -Wno-unused-parameter -Wbad-function-cast -Wcast-align -Wredundant-decls -Werror -L/home/enrico/ocd_all/lib -o openocd.exe main.o libopenocd.la -lftd2xx gcc -std=gnu99 -g -O2 -I/home/enrico/ocd_all/include -D__USE_MINGW_ANSI_STDIO -Wall -Wstrict-prototypes -Wformat-security -Wextra -Wno-unused-parameter -Wbad-function-cast -Wcast-align -Wredundant-decls -Werror -o openocd.exe main.o -L/home/enrico/ocd_all/lib ./.libs/libopenocd.a -lws2_32 -lftd2xx ./.libs/libopenocd.a(libopenocd_la-openocd.o): In function `handle_version_command': D:/Tools/MingW/msys/home/Enrico/openocd/src/openocd.c:60: undefined reference to `flash_register_commands' ./.libs/libopenocd.a(libserver_la-gdb_server.o): In function `gdb_query_packet': D:/Tools/MingW/msys/home/Enrico/openocd/src/server/gdb_server.c:1862: undefined reference to `flash_get_bank_count' D:/Tools/MingW/msys/home/Enrico/openocd/src/server/gdb_server.c:1877: undefined reference to `flash_get_bank_count' D:/Tools/MingW/msys/home/Enrico/openocd/src/server/gdb_server.c:1671: undefined reference to `flash_get_bank_count' D:/Tools/MingW/msys/home/Enrico/openocd/src/server/gdb_server.c:1674: undefined reference to `get_flash_bank_by_num' D:/Tools/MingW/msys/home/Enrico/openocd/src/server/gdb_server.c:1673: undefined reference to `flash_get_bank_count' D:/Tools/MingW/msys/home/Enrico/openocd/src/server/gdb_server.c:1684: undefined reference to `flash_get_bank_count' D:/Tools/MingW/msys/home/Enrico/openocd/src/server/gdb_server.c:1687: undefined reference to `flash_get_bank_count' ./.libs/libopenocd.a(libserver_la-gdb_server.o): In function `gdb_v_packet': D:/Tools/MingW/msys/home/Enrico/openocd/src/server/gdb_server.c:1976: undefined reference to `flash_set_dirty' D:/Tools/MingW/msys/home/Enrico/openocd/src/server/gdb_server.c:1986: undefined reference to `flash_erase_address_range' D:/Tools/MingW/msys/home/Enrico/openocd/src/server/gdb_server.c:2053: undefined reference to `flash_write' collect2: ld returned 1 exit status make[4]: *** [openocd.exe] Error 1 make[4]: Leaving directory `/home/Enrico/openocd/src' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/home/Enrico/openocd/src' make[2]: *** [all] Error 2 make[2]: Leaving directory `/home/Enrico/openocd/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/Enrico/openocd' make: *** [all] Error 2 I've no idea why ? do I need addional libs here ? Thx in advance, Enrico ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] bug database [ WAS Re: STR7x flash protect ... ]
I'm intrigued by having the bug database stored in git together with the repository. Especially for posterity, offlline usage, etc. I was kinda wondering if we could have the wiki stored in git as well. (14 days cooloff before pushing or somesuch?). The only really viable option seems to be gitit, and I'm not sure we want something that complex. We're probably better off sticking with known-good and hosted wiki options. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] bug database [ WAS Re: STR7x flash protect ... ]
As far as bug databases go, I'm kinda partial to ticgit. It stores the whole bug database in one git branch that never actually gets checked out. It hasn't been updated in a while, but it's not exactly a complex system, either. http://wiki.github.com/schacon/ticgit/ From: openocd-development-boun...@lists.berlios.de [mailto:openocd-development-boun...@lists.berlios.de] On Behalf Of Dean Glazeski Sent: Thursday, January 28, 2010 9:56 PM To: David Brownell Cc: openocd-development@lists.berlios.de Subject: Re: [Openocd-development] bug database [ WAS Re: STR7x flash protect ... ] The only significant anti- sentiment I have is that the Trac git plug-in hasn't had an update since 28th of August of 2009. I'm going to play with this a little bit with my sourceforge project that's hooked up to git and I'll get back to you. Alright, it's impossible to do it, for now. The Sourceforge people haven't setup the ability to have Trac connect to a git repository. If we want to do only development tracking in the wiki and manage bugs and features in Trac, I think it's still a good idea. They may eventually get the git connector working, but for now it's a no go. You can build the plug-in in a shell on sourceforge, but I have no idea how to make trac aware of the plugin. Here's a ticket about it: https://sourceforge.net/apps/trac/sourceforge/ticket/7674 Please, do consider using it. Having a viable ticket manager is a great idea. -- // Dean Glazeski ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Issues with interface amt_jtagaccel
On January 28 2010, Matthew Fletcher wrote: Can anyone verify that this interface is still functional in 0.4 ? Out of 0.4-rc1, 0.3.1 and an old rev.131 fetch only the old rev.131 fetch works to a certain extent. In all cases the openocd was built from source on cygwin with only amt_jtagaccell and parport_give_io enabled in configure. Since you have a test-case of sorts, could you do a git-bisect on it? Just type the following: git bisect start git bisect good v0.3.1 git bisect bad v0.4.0-rc1 Then, repetitively: ./bootstrap ./configure --whatever-opts-you-use make -j3 src/openocd -f /path/to/your/config.conf git bisect good|bad Once it says you're done, run git describe and report the output here. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Issues with interface amt_jtagaccel
My mistake - I read too fast. Correction inline. I've used the amt_jtagaccel on v0.1.0, so I'm pretty sure it works. I don't have a working test setup right now, though. On January 28 2010, Matthew Fletcher wrote: Can anyone verify that this interface is still functional in 0.4 ? Out of 0.4-rc1, 0.3.1 and an old rev.131 fetch only the old rev.131 fetch works to a certain extent. In all cases the openocd was built from source on cygwin with only amt_jtagaccell and parport_give_io enabled in configure. Since you have a test-case of sorts, could you do a git-bisect on it? Just type the following: git bisect start git bisect good v0.1.0 git bisect bad v0.3.1 Then, repetitively: ./bootstrap ./configure --whatever-opts-you-use make -j3 src/openocd -f /path/to/your/config.conf git bisect good|bad Once it says you're done, run git describe and report the output here. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] [testing] Test cases ran on v0.4.0-rc1
On Friday, January 29, 2010, David Brownell wrote: ... I'd rather see kilo bytes (KB) not Kibi bytes (KiB) in such contexts too. Kilobytes per second is something I can often do math with in my head. Kibibytes, not; likewise kilobits per second. The problem with doing math with kilobytes in your head is that most people refer to kibibytes as kilobytes. Anyway, the difference is so small (1024 vs 1000) that it would probably be preferable to use kibibytes anyway, if for no other reason than evangelization of IEC-defined SI standards. Of course, for those of us who think in binary and hex, the fact that you can convert between bytes and kibibytes with just a left/right shift is a big plus. - Alex ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Other compilers
So, just for curiosity, I decided to try llvm-clang to build openocd.
I haven't actually run the build yet, but it's just over half the
size of the gcc build, and compiled just a touch faster, too. Any
comments? The time output is from make -j3 calls.
openocd-via-gcc:
real0m25.669s
user0m35.514s
sys 0m3.356s
3308583b3232k
openocd-via-clang:
real0m22.014s
user0m29.186s
sys 0m3.260s
1742244b1702k
Building with clang did take a few very small changes - The change to
helper/log.h is because clang doesn't like an expression where the
result is unused. In helper/system.h, I just defined true and false
since clang doesn't have them builtin.
From 9d5082c0c7825a6492714d9363cf9a9d570a20d3 Mon Sep 17 00:00:00 2001
From: Alex Austin alex.aus...@spectrumdsi.com
Date: Fri, 29 Jan 2010 00:41:44 -0600
Subject: [PATCH] Clang support
---
src/helper/log.h|2 +-
src/helper/system.h |5 +
2 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/src/helper/log.h b/src/helper/log.h
index ebcb8a1..b887e0c 100644
--- a/src/helper/log.h
+++ b/src/helper/log.h
@@ -111,7 +111,7 @@ extern int debug_level;
#define LOG_LEVEL_IS(FOO) ((debug_level) = (FOO))
#define LOG_DEBUG(expr ...) \
- ((debug_level = LOG_LVL_DEBUG) ? log_printf_lf (LOG_LVL_DEBUG,
__FILE__, __LINE__, __FUNCTION__, expr) , 0 : 0)
+ do {if (debug_level = LOG_LVL_DEBUG) log_printf_lf
(LOG_LVL_DEBUG, __FILE__, __LINE__, __FUNCTION__, expr);} while (0)
#define LOG_INFO(expr ...) \
log_printf_lf (LOG_LVL_INFO, __FILE__, __LINE__, __FUNCTION__,
expr)
diff --git a/src/helper/system.h b/src/helper/system.h
index 169df1c..77a867a 100644
--- a/src/helper/system.h
+++ b/src/helper/system.h
@@ -83,4 +83,9 @@
#include fcntl.h
#endif
+#ifndef true
+#define true -1
+#define false 0
+#endif
+
#endif // SYSTEM_H
--
1.6.6
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Other compilers
~/Projects $ size openocd.gcc textdata bss dec hex filename 915920 11600 90668 1018188 f894c openocd.gcc ~/Projects $ size openocd.clang textdata bss dec hex filename 902754 10684 90572 1004010 f51ea openocd.clang -Original Message- From: David Brownell [mailto:davi...@pacbell.net] Sent: Friday, January 29, 2010 1:35 AM To: openocd-development@lists.berlios.de Cc: Austin, Alex Subject: Re: [Openocd-development] Other compilers On Thursday 28 January 2010, Austin, Alex wrote: +#ifndef true +#define true -1 ANSI-C defines true as 1 not -1 ... best to use that for compatibility. I suspect I'll merge this portability patch with that change... That makes little sense to me, especially since I've always seen TRUE defined as -1. Oh well. Either way shouldn't matter. +#define false 0 +#endif By the way, were those object sizes size output (which removes all kinds of extraneous stuff)? - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch/rfc] Add support for multiple-ports on FT4232H
-Original Message- From: David Brownell [mailto:davi...@pacbell.net] Sent: Wednesday, December 30, 2009 3:17 PM To: Laurent Gauch Cc: openocd-development@lists.berlios.de; Austin, Alex Subject: Re: [Openocd-development] [patch/rfc] Add support for multiple-ports on FT4232H ... The best to do: 2. Split the actual ft2232.c to two file ft2232_new.c and mpsse.c . Then Austin could call funtions from mppse.c. When all is working we will rename ft2232_new.c to ft2232.c. Finally we will have : ft2232.c ft4232.c mpsse.c And, preferably, jtagkey2.c and friends ... there are *two* sets of headaches with the current approach. One is how the core code is factored. Another is how all the wiring variants are handled. Would it hurt too much to start out creating a library that wraps either libftd2xx or libftdi depending on configuration and exposes the same interface either way? Maybe libftdi could be extended to use libftd2xx if available and libusb if not? Re: supporting multiple interfaces for our device: After considering our needs, I've managed to move the reset lines to ADBUS5 and ADBUS6, since anyone who doesn't put a pull-up on the reset lines of a possible target will be answering to our senior systems engineer. That leaves BDBUS completely free for other uses TBD, and makes multiple-port support not quite so necessary. (Now I just need to see if I can solder the 4232HQ back onto the board...) ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch/rfc] Add support for multiple-ports on FT4232H
-Original Message- From: openocd-development-boun...@lists.berlios.de [mailto:openocd- development-boun...@lists.berlios.de] On Behalf Of Øyvind Harboe Sent: Thursday, December 24, 2009 1:09 AM To: Austin, Alex Cc: Laurent Gauch; openocd-development@lists.berlios.de Subject: Re: [Openocd-development] [patch/rfc] Add support for multiple-ports on FT4232H I could probably do this, but supporting the 4232 is time I can bill to my company, while driver refactoring is not (yet). Why should the community take on cleanup and refactoring work to support your company's patch? The refactor is not to support our patch, just to clean up the ft2232 driver. My comment is in response to something that was said should probably be done anyway, not specifically to support our device. I think support for our device could be done without said refactor, but the code would be uglier-yet and you would be unlikely to accept it. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch/rfc] Add support for multiple-ports on FT4232H
On Wednesday 23 December 2009, Laurent Gauch wrote: On Tuesday 22 December 2009, Alex Austin wrote: I doubt this is the right way to do things, but it hasn't broken anything yet. This is just providing framework support for an adapter with reset lines driven by BDBUS instead of ACBUS. I am a bit worry seeing your code, and the idea to mix both A channel (JTAG) and B channel (SRST) bus. If you really have to mix A and B for the same functionality as the Amontec JTAGkey or other Dongles in the driver ft2232.c, you should have to write a new driver as ft2232_mixed_channel.c . You only complicate the code and make SPEED regression including your idea/code in the actual ft2232.c. The reason for the separation is that the FT4232 does not have *CBUS ports, creating the need to separate out the reset lines to a different device. As for speed regressions, they are minimal (+just a few clock cycles) unless you actually have streams of ft2232 commands for multiple ports. On Wednesday 23 December 2009, David Brownell wrote: Hmm, maybe splitting the ft2232.c code into more manageable chunks would suffice? That's a mess which *does* need to be sorted out, IMO. For the post-0.4 merge window though. I could probably do this, but supporting the 4232 is time I can bill to my company, while driver refactoring is not (yet). - Alex ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Add support for multiple-ports on FT4232H
Ignore this for now. It runs fine with -O0, segfaults with -O2. Now to figure out why. -Original Message- From: openocd-development-boun...@lists.berlios.de [mailto:openocd- development-boun...@lists.berlios.de] On Behalf Of Austin, Alex Sent: Tuesday, December 22, 2009 4:45 PM To: openocd-development@lists.berlios.de Subject: [Openocd-development] Add support for multiple-ports on FT4232H I doubt this is the right way to do things, but it hasn't broken anything yet. This is just providing framework support for an adapter with reset lines driven by BDBUS instead of ACBUS. I don't expect this to be in 0.4-RCanything, but I wouldn't mind another set of eyes. - Alex ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch/rfc] NOR FLASH: only erase/unlock whole sectors
Read-modify-erase-write on per-sector basis? -Original Message- From: openocd-development-boun...@lists.berlios.de [mailto:openocd- development-boun...@lists.berlios.de] On Behalf Of David Brownell Sent: Tuesday, December 22, 2009 8:23 PM To: Øyvind Harboe Cc: openocd-development@lists.berlios.de Subject: Re: [Openocd-development] [patch/rfc] NOR FLASH: only erase/unlock whole sectors On Tuesday 22 December 2009, Øyvind Harboe wrote: This is a bit worse than I thought. This breaks flash write_image as well. That was *this* problem report, in fact... Flash write_image will first erase all sectors in address ranges of all segments to be written, then it will write all segments. In short, kind of broken-by-design. When other portions of one of those sector should not have been erased -- maybe the portion being written was still erased! -- it's trashing stuff that should have been left alone. Example: I might have two images to write, which don't overlap. Erase, write one, write the next. Whoops ... it needlessly erased part of the first image in order to write the second one, because they used different parts of a sector. I'm going to sort through the messages here and come up with a solution that's not broken-by-design. - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Codecheck
-Original Message-
From: openocd-development-boun...@lists.berlios.de [mailto:openocd-
development-boun...@lists.berlios.de] On Behalf Of Lennert Buytenhek
Sent: Wednesday, December 16, 2009 2:57 PM
To: Øyvind Harboe
Cc: openocd-development@lists.berlios.de
Subject: Re: [Openocd-development] Codecheck
On Wed, Dec 16, 2009 at 09:46:29PM +0100, Øyvind Harboe wrote:
for number_of_mallocs:
{
- fix the file
- see if it compiles.
- create a patch
- send it too you.
}
No.
- fix a file(including build it)
- commit to local git
While I am of the opinion that git is the greatest thing since sliced
bread, I don't think that it is a good idea to require that people
learn
some VCS they aren't familiar with to contribute to a project.
E.g. if someone is already familiar with quilt, they can do most of the
local patch management they need without having to learn git (even if
the latter is a good idea, it should not be required upfront).
In this case, if someone sends a patch series to the list, I don't
think it should matter which VCS was used to manage that patch series
during local development.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
If you're already familiar with Quilt, check out StGit. But, really, I
haven't found any tool that makes it easier to manage patches than Git.
That is, essentially, its purpose.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Codecheck
Actually, probably not a bad idea for a long-term fix. AFAIK, Posix OSes will inform you of malloc failures with SIGKILL rather than NULL. The article on gmane.comp.audio.jackit had some very good discussion on this point, so emulating that functionality under Windows is probably a decent way to go. http://article.gmane.org/gmane.comp.audio.jackit/19998 On Wednesday 16 December 2009, David Brownell wrote: On Wednesday 16 December 2009, Igor Skochinsky wrote: Actually, I think a common emalloc() function that (in the unlikely event of malloc failure) prints an error message and exits the app is a better choice than sticking checks everywhere. Not a bad idea for a near-term fix... ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] FT4232H support
Hello, I've built a JTAG adapter (Very similar to oocdlink-h) using the FT4232H instead of the FT2232H. Due to the lack of ACBUS on the 4232, I've routed the reset lines to the same pins on BDBUS. CDBUS and DDBUS both go to serial ports. What would be the best way to support that? Should I manually open the 2nd port on jtag_init in bit-bang mode and use it for reset events, or is there a better way to do that? Thanks, - Alex ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD GUI
I would like to see openocd always start, even if the config file is invalid. Then, it can be configured via telnet and, hopefully, Have a command to dump a config file. If the telnet interface supported completion a la Cisco routers (press ? to list available completions), it would not be difficult to write flexible GUIs that wrap around it, and it would be nicer to use in and of itself. -Original Message- From: openocd-development-boun...@lists.berlios.de [mailto:openocd- development-boun...@lists.berlios.de] On Behalf Of David Brownell Sent: Tuesday, October 20, 2009 11:19 AM To: openocd-development@lists.berlios.de Subject: Re: [Openocd-development] OpenOCD GUI On Tuesday 20 October 2009, Øyvind Harboe wrote: The alternative is to create a complete API and stick to it. We're not keen, nor do we see the need for the sort of simple functionality that has been outlined. Web access *IS* an API ... at least, as soon as any client starts to use it that way. That's why there's been such a lot of interest in web programming interfaces that uplevel things from screen scraping to something that's more maintainable. IMO that's kind of moot until whatever non-commandline UI starts to get more users, though. :) ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] What's git's equivalent to svn version #?
You can do that if you want. Otherwise, since every git command uses git rev-parse implicitly, the result of git describe is a valid revision descriptor. You can git checkout -b my_temp_branch output_of_git_describe -Original Message- From: openocd-development-boun...@lists.berlios.de [mailto:openocd- development-boun...@lists.berlios.de] On Behalf Of David Brownell Sent: Saturday, October 17, 2009 3:50 PM To: openocd-development@lists.berlios.de Subject: Re: [Openocd-development] What's git's equivalent to svn version #? On Saturday 17 October 2009, Øyvind Harboe wrote: How do I figure out what version a git describe refers to? git rev-parse $(git describe) ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] cast from long to HANDLER on MinGW-W64
“What do you think is the worst that could happen by issuing a 0 + on an integer value that is meant to be used as a valid pointer in the first place?” Remember: (((int32_t *)0) + 5) == 20. From: openocd-development-boun...@lists.berlios.de [mailto:openocd-development-boun...@lists.berlios.de] On Behalf Of Redirect Slash NIL Sent: Saturday, October 17, 2009 6:14 PM To: openocd-development@lists.berlios.de Subject: Re: [Openocd-development] [PATCH] cast from long to HANDLER on MinGW-W64 2009/10/17 David Brownell davi...@pacbell.netmailto:davi...@pacbell.net What's with the strange (HANDLE)(0 + _get_osfhandle())? The 0 + is mutant... Yeah. The problem here is that HANDLE is typedef'd as void* (in winnt.h), whereas _get_osfhandle() returns a long (http://msdn.microsoft.com/en-us/library/ks2530z6.aspx), and gcc insists on returning a warning when casting a 32 bit long into a 64 bit pointer (cast to pointer from integer of different size). The most elegant way I found to avoid that warning is to do an arithmetic operation first. Of course one has to wonder why a function that is meant to return a handle does not actually return a type HANDLE... The only other way I see to do it is to add idefs for MINGW64 so that we cast _get_osfhandle() to a long long first. What do you think is the worst that could happen by issuing a 0 + on an integer value that is meant to be used as a valid pointer in the first place? _get_osfhandle is meant to provide a pointer (handle) that is valid for the OS it's actually being executed in. It's just that for whatever reason, the makers of that function decided to return anything but a handle but I still think what we're doing here should be pretty safe. Regards ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] A little Git repo cleanup
I just did a clone of the git repository and noticed how long it took to clone one of the many objects. After a little sleuthing, I've determined that: 2869bc4... Adds a few small files 2f37d16... Adds several large files. af3b53a... Adds more large files. It immediately succeeds the previous 1ef7ccc... Removes all files added by previous three commits and nothing else Removing those four commits brings the repo from 99MB to 5MB. While doing so would destroy history that others' use, it would be a great boon to those who are cloning it for the first time, and would not be difficult for the rest of us to synchronize with. Any takers? ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] What's git's equivalent to svn version #?
Well, that won't really work since history is nonlinear. You can git log --oneline -- path/to/file to list out the last commit to modify that file. Then git describe abbreviated_hash_from_first_line_of_log and it'll give you something like: tagname-commit-count-since-gAbbreviated SHA1 which is a valid way to specify a revision. -Original Message- From: openocd-development-boun...@lists.berlios.de [mailto:openocd- development-boun...@lists.berlios.de] On Behalf Of Øyvind Harboe Sent: Wednesday, October 14, 2009 9:12 AM To: openocd-development@lists.berlios.de Subject: [Openocd-development] What's git's equivalent to svn version #? What's the most reasonable way to refer to a git version for human beings? In svn it's a small integer(only in the thousands). I was thinking about something like 0.2 + N versions. -- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Eclipse git gui
The git gui itself is probably a bit nicer. Myself, I always use the git command line tools, though I find gitk indispensible as a roadmap. To try the git gui, type git gui at the command line. Oh, and it works perfectly in cygwin, and identically in Linux. - Alex -Original Message- From: openocd-development-boun...@lists.berlios.de [mailto:openocd- development-boun...@lists.berlios.de] On Behalf Of Øyvind Harboe Sent: Thursday, October 08, 2009 8:38 AM To: openocd-development@lists.berlios.de Subject: [Openocd-development] Eclipse git gui I'm using the Eclipse git GUI now. It feels pretty awkward and minimalistic, but is robust so far and can probably cope with some of the most common operations. It seems to behave well if I do some tasks in shell and some in Eclipse. Note, I'm running Ubuntu/Linux. I shudder at the thought of trying to pull that off w/Cygwin... The awkward bit is also because it will take quite a bit of time before my brain immune system stops rejecting git concepts :-) http://www.eclipse.org/egit/ Checking out a project is a bit different than svn obviously: - Use File-Import to import the repository - Create empty project - Use Team-Share this project to the git repository Clearly these guys have some way to go to make this intuitive, but that's as much due to the very different nature of git as anything... -- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Switch to non-Berlios mailing list
Notice the number of messages with a subject line of Berlios outage... -Original Message- From: openocd-development-boun...@lists.berlios.de [mailto:openocd- development-boun...@lists.berlios.de] On Behalf Of Tom Moulton Sent: Tuesday, October 06, 2009 12:17 PM To: openocd-development@lists.berlios.de Subject: Re: [Openocd-development] Switch to non-Berlios mailing list There may be an obvious reason my suggestion is NOT good but here goes... Why not leave the mailing list here? I just want to make sure an obvious answer is not missed... tom ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Moving to git
-Original Message- From: openocd-development-boun...@lists.berlios.de [mailto:openocd- development-boun...@lists.berlios.de] On Behalf Of Grant Edwards Sent: Tuesday, October 06, 2009 12:52 PM To: openocd-development@lists.berlios.de Subject: Re: [Openocd-development] Moving to git On 2009-10-06, Ra?l S?nchez Siles rsanch...@infoglobal.es wrote: !!! And if anyone objects to GIT, please speak up ASAP !!! I think mercurial [0] could be a good option. It's a well known distributed VCS, maybe not as spread or known as git, but it's fulfilling most if not all general users aspirations. I find it generally speaking easier to use than git and the move from those used to SVN should be less painful. This exact same discuss is taking place in a different open-source project in which I participate, and several people there have also said that they thought mercurial would be an easier transition than git. I would give a few points to mercurial for being written in Python. I would expect it to be a lot more stable than something written in C. However, my opinion shouldn't be weighted very heavily since I'm just a user when it comes to openocd. I also generally prefer python. However, Python apps are really only more stable than C apps insofar as segfaults go. I would dare say git gets much more solid testing, as it's used by the Linux kernel, where just about every new feature will be tried and beaten on. Only one unstable release, ever (so far) in the history of git, has had data consistency problems, and the warning went out on the mailing list within a few minutes. That was years ago, and hasn't happened again since. If you watch Linus' Google Tech Talk on Git, he makes several points about workflows that are only possible with the performance you get from the C-based core of git. He discusses Mercurial as interesting, but it's Python base will cause it to perform worse for many operations. See http://www.whygitisbetterthanx.com for some performance/feature comparisons including with Mercurial. -- Grant Edwards grante Yow! Are we on STRIKE yet? at visi.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Moving to git
Since many people seem to not be fond of sourceforge, have you considered GitHub? Just put a README.markdown in the project and it will become a nice webpage front for the project. They already provide source browsing and snapshots available via HTTP, and make it trivially easy for anyone to (a) fork the project and (b) make changes in forks available to the original project. Plus, we could always use their Wiki for a project page. - Alex -Original Message- From: openocd-development-boun...@lists.berlios.de [mailto:openocd-development-boun...@lists.berlios.de] On Behalf Of Øyvind Harboe Sent: Monday, October 05, 2009 12:57 PM To: openocd-development@lists.berlios.de Subject: [Openocd-development] Moving to git Zach, David and I as maintainers constitute the committee to move OpenOCD to sourceforge and make some choices about how things will be moved on behalf of the community. We want input from the community, but we also need a bit of leadership to execute the steps. In short, the following will happen: 1. The source will be held in git. https://sourceforge.net/projects/openocd/ 2. Zach, David and I are managers for the OpenOCD project at sourceforge. 3. There is already a mailing list set up for OpenOCD at sourceforge 4. The top web pages will be very slightly reworked so that web pages are in fact kept under git and generated by doxygen, phasing out wordpress. Schedule: Thursday October 8. 2009 08:00 EST: 1. Berlios svn will be made read only and the svn head will be deleted, leaving behind only a README w/reference to the openocd project at sourceforge. The entire svn history will remain available on Berlios indefinitely. 2. The Berlios web page will be changed into a stub pointing to sourceforge. 3. the mailing list will be disabled and all openocd subscribers will receive an invitation to subscribe to the openocd mailing list at sourceforge. The sourceforge mailing list is the least sucky alternative for hosting mailinglists at this point. -- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Moving to git
-Original Message- From: David Brownell [mailto:davi...@pacbell.net] Sent: Monday, October 05, 2009 6:37 PM To: openocd-development@lists.berlios.de Cc: Austin, Alex Subject: Re: [Openocd-development] Moving to git On Monday 05 October 2009, Austin, Alex wrote: Since many people seem to not be fond of sourceforge, AFAIK that's just the email. Which has issues like crappy archives, bad spam filtering, ads, and such. have you considered GitHub? In terms of GIT support is it significantly better than SourceForge? Haven't used git on sourceforge, but it wouldn't surprise me. Just put a README.markdown in the project and it will become a nice webpage front for the project. We need a bit more than that from the web face. Current notions include making the website give better access to the project docs: the User's Guide, and the doxygen Developer's Guide output. http://www.github.com/blog/272-github-pages Put your entire website in a branch on the git repo. That can Include doxygen-generated stuff if need be. They already provide source browsing and snapshots available via HTTP, Everyone seems to run gitweb, so that's not going to be a compelling advantage to any service. I use gitweb too. Compared to github's interface, it's a mere toy. and make it trivially easy for anyone to (a) fork the project Already easy, courtesy of GIT. :) GitHub takes it much further, in that it would be easy for anyone Looking at OpenOCD to find all the forks of it on GitHub, and even see where the history split off. and (b) make changes in forks available to the original project. Plus, we could always use their Wiki for a project page. We'd need someone to volunteer to manage and evolve a Wiki. And some folk don't like them. That particular change merits a separate discussion. Note that SourceForge supports wiki stuff too. - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
