Re: [Openocd-development] Current stable release is very very stale
"David Brownell" napisał(a): > Plans are still: (i) merge framework code first, > hold the FT2232/Luminary driver code till later. Have you synchronized your work with that of Tomek Cedro? There is a big chance that Tomek may be doing the same work you've already done... > have to wait a long time to see it ;( As you see (probably) nothing is going > on in this matter... > > If you think that, you've not bothered to read any > of my status reports. OK, let me rephrase. Some ppl said that they are working on the subject, but due to various reasons the cannot continue. As you said - you've created the code last summer, now it's almost winter and you state that you'll not have much time to work on it soon. IMO SWD is the most wanted feature in OpenOCD. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] TARGET: Add "phys" flag to dump_image command
Øyvind Harboe writes: >> Should "phys" flag also be added to "load_image" command? > > And what about the verify_image command? Yes that too. >> Alternatively, would it be possible to expose >> e.g. arm920t_disable_mmu_caches somehow to the command interface so >> that I could disable the MMU and then use "load_image" with physical >> addresses? > > I not getting a warm fuzzy feeling w.r.t. this approach. I agree it's bit scary. However, dump_image phys memory.img 0x3000 134217728 currently enables and disables the MMU and caches 239674 times. Isn't this also quite scary or is it really harmless? ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Lost patches
Are there any patches out there that should have been applied but haven't? -- Ø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] iMX51 workaround
If iMX51 is broken and the current CortexA8 workaround code for it breaks other CPUs, then I think that the automatic workaround code for iMX51 has to be either fixed or removed. Thoughts? -- Ø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
Re: [Openocd-development] Automatic detection of debugbase for cortex A8
> This patch breaks debugging on the DM37x. It appears that the debug
> base and APID is not sufficient to identify problematic processors
> since the DM37x on the Beagleboard XM incorrectly passes the checks in
> arm_adi_v5.c:
>
> for (i = 0; i < sizeof(broken_cpus)/sizeof(struct broken_cpu); i++)
> if (broken_cpus[i].dbgbase == dbgbase &&
> broken_cpus[i].apid == apid) {
> LOG_WARNING("Found broken CPU (%s), trying to fixup "
> "ROM Table location from 0x%08x to 0x%08x",
> broken_cpus[i].model, dbgbase,
> broken_cpus[i].correct_dbgbase);
> dbgbase = broken_cpus[i].correct_dbgbase;
> break;
> }
>
> Is there another way that these problematic CPUs can be identified?
Anyone?
--
Ø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
Re: [Openocd-development] [PULL-REQUEST] Floss-JTAG and Lisa/L updates and fixes
Merged. Thanks! -- Ø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] Release maintainer
Is there anyone on the list with experience as a release engineer for an open source project that would like to have a stab at releasing OpenOCD 0.5? We need some extra hands... -- Ø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
Re: [Openocd-development] STM32 reset halt segfault on Mac OS X
> Thanks will try that next. I also dissected the commits and found out that > the bug got introduced with commit: > 3b68a708c2b039d9b091608eccb2206725742a47 ADIv5: remove ATOMIC/COMPOSITE > interface mode > > In the previous revision everything works and with this one it stops working > for me. Good catch! Unfortunately that's a pretty big commit. The next thing I could suggest in terms of bisection would be to create a working branch and split that commit as many times as possible and do a bisect on that branch... -- Ø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
Re: [Openocd-development] Current stable release is very very stale
--- On Mon, 11/29/10, simon qian wrote: How is going on SWD support? No changes since my last update; I was getting ready to merge the framework code when the merge of the new Jim code made everything break for me. I've not yet had time to go back and unbreak things. Plans are still: (i) merge framework code first, hold the FT2232/Luminary driver code till later. The framework changes haven't affected much of the non-SWD code, but merging it sooner will help avoid future conflicts. The Luminary driver still needs testing time from me, which has gotten harder to come by this month due to other work. I think I'll at least post that code near the time I merge the framework code, since I'll have at least tested its initialization by then, and have a handle on where the real bugs are. I'm not keen on posting very buggy code, and at this point that driver is only compile tested. (I think some of that code might work for other FT2232 based hardware (And as a reminder: I did post a version of the framework code a few months back, so it should have no surprises for anyone who's been tracking my posts on SWD topics. Does the FT-based driver for SWD implemented? I think the driver should be implemented first, so that other code and test can proceed. Yes, see above. Testing time remains the issue; that driver code was written last summer. I also have other stuff consuming my time. (One thing being a need to recover from the new Jim code having merged (and broken my devel setup). Turns out also that JLink published some docs, but they seem limited to memory-based access, which is only part of the SWD story ... and I've not yet made time to think about how that kind of SWD access will behave for us. (That is, it's less capable than JTAG or the FT2232/Luminary type of driver (Or what I think Versaloon can do). Doc URL is now in the JLink driver; see GIT history. It was said that the milestone for next release is SWD support, so probably we'll "The" milestone? Maybe "A" goal among many. have to wait a long time to see it ;( As you see (probably) nothing is going on in this matter... If you think that, you've not bothered to read any of my status reports. - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] SVF Chain Handling (was: lpc3131 and Actel FPGA chain programming)
Note that I'm just a humble maintainer here. I'm not able to follow this part of the OpenOCD conversation and you guys are the experts. Let me know when you all agree that the patches are ready to be merged. -- Ø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
Re: [Openocd-development] [PATCH] TARGET: Add "phys" flag to dump_image command
On Mon, Nov 29, 2010 at 11:12 PM, Timo Juhani Lindfors wrote: > Øyvind Harboe writes: >> This patch introduces a serious and sweeping regression that >> a compiler warning caught: > > Indeed. Thanks for catching this and sorry for forgetting the return. > >> How's the attached updated patch? > > Looks definitely better. > > Should "phys" flag also be added to "load_image" command? And what about the verify_image command? I think that once we add this, it would be nice to have them for all these commands. > Alternatively, would it be possible to expose > e.g. arm920t_disable_mmu_caches somehow to the command interface so > that I could disable the MMU and then use "load_image" with physical > addresses? I not getting a warm fuzzy feeling w.r.t. this approach. -- Ø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
Re: [Openocd-development] Current stable release is very very stale
Maybe this is good idea to increase the build number at least every half a year - this could help keeping packages up to date and even make development faster and more accurate as there would be some predefined deadline for testing and this can be good motivator :-P Best regards Tomek On 30 Nov 2010 04:13, "Eric Parsonage" wrote: > Hi Piotr > > I agree completely with you. The version on Macports is so old simply > because there have been no point releases since then. It means that > everybody that wants to use some new interface like me > has to either mess around building from source or wait for nearly a year > for some other major release to be made. > > Regards > > Eric Parsonage > > > On 30/11/2010, at 8:23 AM, Piotr Esden-Tempski wrote: > > > Hi, > > > > On Nov 29, 2010, at 1:26 PM, Mich... > > > ___ > > Openocd-development mailing list > > Openocd-devel... > ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Current stable release is very very stale
The SWJ cable that I have use tdi and tdo pins anyway but the buffers are
more complex, maybe there is a simple way to make jtag only cable swd aware,
i have some other cables so after the base is working we can give a try on
that :-)
Best regards
Tomek
> On 2010-11-29 14:44, Tomek CEDRO wrote:
>> The SWD API is almost done, for few days already im trying to integrate
>> it into UrJTAG as this is simpler software than OpenOCD from complexity
>> point of view. When transport is verifed (~week 49/50) im moving to
>> OpenOCD and debugging. The hardware I am working on in stm32primer{1,2}
>> and KT-LINK SWJ cable based on FT2232H. I want it all to work by end of
>> year :-)
>
> This would be great!
>
> Do you have some idea how can SWD be used with "typical" FT2232 based
> JTAGs - these which don't have direction control for SWDIO (like Amontec
> JTAGkey, Turtelizer, etc.)?
>
> 4\/3!!
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Current stable release is very very stale
Hi Piotr I agree completely with you. The version on Macports is so old simply because there have been no point releases since then. It means that everybody that wants to use some new interface like me has to either mess around building from source or wait for nearly a year for some other major release to be made. Regards Eric Parsonage On 30/11/2010, at 8:23 AM, Piotr Esden-Tempski wrote: > Hi, > > On Nov 29, 2010, at 1:26 PM, Michael Schwingen wrote: > >> On 11/29/2010 02:57 PM, Tomek CEDRO wrote: >>> ...however I can understand the urge to have stable release done. If the >>> GIT repository contains mainly bugfixes, then maybe it is time to freeze it >>> as 0.4.1, so we can release 0.5.0 with SWD suport as planned - anyway it >>> will probably happen soon when the SWD is already implemented and tested..? >> Sounds good. >> If we currently tell people with problems to try the master branch, I think >> it is time for a new release, even if it contains only bugfixes and no major >> new features. > > I agree on that. Still I think it should be tested more. For example the > problems I currently have on Mac OS should be resolved before a point release > is done? But in general there should be regular point releases with bugfixes, > additional scripts and so on. So that distributions like Debian can update > their packages and contain all the small fixes and scripts for everyone to > use easily. Otherwise the maintainers will fall back to the earlier mode, > where they were packaging some arbitrary git revisions, to provide the users > with a slightly more up to date version of openocd. Major features always > need a long time and should be released in their own pace. > > Cheers Esden > > -- > Blog: http://www.esden.net > Projects: > http://open-bldc.org > http://paparazziuav.org > http://github.org/esden/floss-jtag > http://github.org/esden/summon-arm-toolchain > > ___ > 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] STM32 reset halt segfault on Mac OS X
Hi, On Nov 29, 2010, at 4:24 PM, Antonio Borneo wrote: >> I did some more poking. Maybe it will be useful. As this seems to be a >> memory problem I thought maybe electric-fence will tell us something useful. >> So I compiled oocd with libefence, and this is what I get: >> > Try also "valgrind". > My understanding on electric-fence is that it uses MMU to set page > access permission. This method cannot set anything smaller that the > page size. > So, if you malloc a buffer of 1 byte, you get a full page with R/W permission. > Valgrind, instead, is a x86 (or PPC on old MAC) simulator. It catch > every memory access outside the range return by malloc. > > Antonio Thanks will try that next. I also dissected the commits and found out that the bug got introduced with commit: 3b68a708c2b039d9b091608eccb2206725742a47 ADIv5: remove ATOMIC/COMPOSITE interface mode In the previous revision everything works and with this one it stops working for me. Cheers Esden -- Blog: http://www.esden.net Projects: http://open-bldc.org http://paparazziuav.org http://github.org/esden/floss-jtag http://github.org/esden/summon-arm-toolchain PGP.sig Description: This is a digitally signed message part ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] STM32 reset halt segfault on Mac OS X
> I did some more poking. Maybe it will be useful. As this seems to be a memory > problem I thought maybe electric-fence will tell us something useful. So I > compiled oocd with libefence, and this is what I get: > Try also "valgrind". My understanding on electric-fence is that it uses MMU to set page access permission. This method cannot set anything smaller that the page size. So, if you malloc a buffer of 1 byte, you get a full page with R/W permission. Valgrind, instead, is a x86 (or PPC on old MAC) simulator. It catch every memory access outside the range return by malloc. Antonio ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] STM32 reset halt segfault on Mac OS X
On Nov 29, 2010, at 3:19 PM, Piotr Esden-Tempski wrote:
>
> On Nov 29, 2010, at 12:39 PM, Øyvind Harboe wrote:
>
>> Better.
>>
>> Could you try HEAD w/master branch?
>>
>>> #0 0x000100073314 in mem_ap_read_atomic_u32 (dap=0x10032f540,
>>> address=1, value=0x10032e800) at arm_adi_v5.c:214
>>
>> => this doesn't point to anything sensible, it's the tailend of the fn.
>>
>> Also try w/-O0
>>
>> CFLAGS="-O0 -g" configure ...
>> make clean
>> make
>
>
> I did that but it does not change anything. It is still failing at the same
> line. For more context maybe this helps. This is the signal I get:
> Program received signal EXC_BAD_ACCESS, Could not access memory.
> Reason: 13 at address: 0x
> 0x00010007325c in mem_ap_read_atomic_u32 (dap=0x10032f540, address=1,
> value=0x10032e800) at arm_adi_v5.c:214
>
> Also I stepped through the code and this is what is happening:
> jim_target_reset (interp=0x100308c90, argc=3, argv=0x7fff5fbfc9d8) at
> target.c:4321
> cortex_m3_assert_reset (target=0x10032e950) at cortex_m3.c:921
> mem_ap_read_atomic_u32 (dap=0x10032f7b0, address=3758157296,
> value=0x10032f6b0) at arm_adi_v5.c:209
> dap_run (dap=0x10032f7b0) at arm_adi_v5.h:337
> jtag_dp_run (dap=0x10032f7b0) at adi_v5_jtag.c:435
> jtagdp_transaction_endcheck (dap=0x10032f7b0) at adi_v5_jtag.c:222
> jtag_dp_run (dap=0x10032f7b0) at adi_v5_jtag.c:436
> dap_run (dap=0x10032f7b0) at arm_adi_v5.h:339
> mem_ap_read_atomic_u32 (dap=0x10032f7b0, address=3758157296,
> value=0x10032f6b0) at arm_adi_v5.c:214
>
> these calls work correctly in that order each calling the next. As soon as
> dap_run returns the mem_ap_read_atomic_u32 function wants to return the
> dap_run value but failes with the memory access error quoted before. I have
> never seen such wired behavior before.
I did some more poking. Maybe it will be useful. As this seems to be a memory
problem I thought maybe electric-fence will tell us something useful. So I
compiled oocd with libefence, and this is what I get:
Starting program: /opt/mine/bin/openocd -f interface/flossjtag.cfg -f
board/open-bldc.cfg
Reading symbols for shared libraries . done
Electric Fence 2.1 Copyright (C) 1987-1998 Bruce Perens.
ElectricFence Aborting: free(1003061b0): address not from malloc().
Program received signal SIGILL, Illegal instruction.
0x7fff82ac8616 in __kill ()
(gdb) bt
#0 0x7fff82ac8616 in __kill ()
#1 0x00012ec8 in EF_Abort (pattern=0x10012a2a8 "free(%a): address not
from malloc().") at print.c:137
#2 0x00012596 in free (address=0x1003061b0) at efence.c:699
#3 0x0001000e0301 in SetListFromAny (interp=0x100403e40,
objPtr=0x1005e4fc0) at jim.c:5453
#4 0x0001000e0c29 in Jim_ListLength (interp=0x100403e40,
objPtr=0x1005e4fc0) at jim.c:5728
#5 0x0001000edde5 in Jim_ProcCoreCommand (interp=0x100403e40, argc=4,
argv=0x7fff5fbff240) at jim.c:11775
#6 0x0001000e86b7 in Jim_EvalObj (interp=0x100403e40,
scriptObjPtr=0x100415fc0) at jim.c:9422
#7 0x0001000e8fd3 in Jim_Eval_Named (interp=0x100403e40,
script=0x10012dd48 "\n\n\nproc alias {name args} {\n\tset prefix $args\n\tproc
$name args prefix {\n\t\ttailcall {*}$prefix {*}$args\n\t}\n}\n\n\nproc lambda
{arglist args} {\n\tset name [ref {} function lambda.finalizer]\n\ttailcall
proc $"..., filename=0x10012dd3b "stdlib.tcl", lineno=1) at jim.c:9661
#8 0x000100101a18 in Jim_stdlibInit (interp=0x100403e40) at jim-stdlib.c:7
#9 0x0001000f4124 in Jim_InitStaticExtensions (interp=0x100403e40) at
jim-load-static-exts.c:10
#10 0x0001000d1363 in command_init (startup_tcl=0x10012fd80 "# Defines
basic Tcl procs that must exist for OpenOCD scripts to work.\n#\n# Embedded
into OpenOCD executable\n#\n\n\n# We need to explicitly redirect this to the
OpenOCD command\n# as Tcl defines the exit p"..., interp=0x100403e40) at
command.c:1338
#11 0x000139dc in setup_command_handler (interp=0x0) at openocd.c:267
#12 0x00013ae1 in openocd_main (argc=5, argv=0x7fff5fbff488) at
openocd.c:314
#13 0x00013153 in main (argc=5, argv=0x7fff5fbff488) at main.c:42
I have no clue about the internals of Jim so maybe I just did something wrong.
But who knows it may help. :)
Cheers Esden
--
Blog: http://www.esden.net
Projects:
http://open-bldc.org
http://paparazziuav.org
http://github.org/esden/floss-jtag
http://github.org/esden/summon-arm-toolchain
PGP.sig
Description: This is a digitally signed message part
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] STM32 reset halt segfault on Mac OS X
On Nov 29, 2010, at 12:39 PM, Øyvind Harboe wrote: > Better. > > Could you try HEAD w/master branch? > >> #0 0x000100073314 in mem_ap_read_atomic_u32 (dap=0x10032f540, >> address=1, value=0x10032e800) at arm_adi_v5.c:214 > > => this doesn't point to anything sensible, it's the tailend of the fn. > > Also try w/-O0 > > CFLAGS="-O0 -g" configure ... > make clean > make I did that but it does not change anything. It is still failing at the same line. For more context maybe this helps. This is the signal I get: Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: 13 at address: 0x 0x00010007325c in mem_ap_read_atomic_u32 (dap=0x10032f540, address=1, value=0x10032e800) at arm_adi_v5.c:214 Also I stepped through the code and this is what is happening: jim_target_reset (interp=0x100308c90, argc=3, argv=0x7fff5fbfc9d8) at target.c:4321 cortex_m3_assert_reset (target=0x10032e950) at cortex_m3.c:921 mem_ap_read_atomic_u32 (dap=0x10032f7b0, address=3758157296, value=0x10032f6b0) at arm_adi_v5.c:209 dap_run (dap=0x10032f7b0) at arm_adi_v5.h:337 jtag_dp_run (dap=0x10032f7b0) at adi_v5_jtag.c:435 jtagdp_transaction_endcheck (dap=0x10032f7b0) at adi_v5_jtag.c:222 jtag_dp_run (dap=0x10032f7b0) at adi_v5_jtag.c:436 dap_run (dap=0x10032f7b0) at arm_adi_v5.h:339 mem_ap_read_atomic_u32 (dap=0x10032f7b0, address=3758157296, value=0x10032f6b0) at arm_adi_v5.c:214 these calls work correctly in that order each calling the next. As soon as dap_run returns the mem_ap_read_atomic_u32 function wants to return the dap_run value but failes with the memory access error quoted before. I have never seen such wired behavior before. Cheers Esden -- Blog: http://www.esden.net Projects: http://open-bldc.org http://paparazziuav.org http://github.org/esden/floss-jtag http://github.org/esden/summon-arm-toolchain PGP.sig Description: This is a digitally signed message part ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] SVF Chain Handling (was: lpc3131 and Actel FPGA chain programming)
On Wed, Nov 24, 2010 at 12:10 AM, Wookey wrote: > +++ Andrew Leech [2010-11-17 14:02 +1100]: >> >> Yep I rewrote the command line parser, so the usage is now: >> "usage: svf [-tap device.tap] [-quiet] " >> >> Arguments are checked in a loop so it will accept switches and >> in any order. quiet or -quiet are both recognised. And of course, -tap >> is optional. As such it is now back compatible, much nicer and more >> flexible. There's also a help switch that simply prints usage in case >> anyone tries it. > > As someone who has previously used svf and xsvf functionality with > chained devices I'd like to add another 'yes please this is great' > vote, and thank andrew for his work (I'm glad someone understands > this stuff :-) > > Oddly I have previously found that xsvf files would work even when > they were generated single but used in a chain (or maybe it was the > other way round). I was quite suprised about this and assumed that > openocd was already doing something clever equivalent to the > functionality this patch provides. But obviously that was just dumb > luck. > > And yes the above syntax is the right way tto do this. Breaking > existing scripts is something we should work hard to avoid as it can > make openocd updates in production environments very awkward.. > > Wookey Yeah I'm much happier allowing previous syntax to work fine without modification. I haven't looked at the xsvf module at all, while it would be neater to bring it in line with this one, or even roll both of them rolled together, I don't have any xilinx parts or software so haven't had any call to use it. The xsvf parser or format may very well have chain functionality built into it, I'm not sure. Well I've made a whole heap more updates, and eventually realised I should be splitting them up into separate patches, as many of them are (or should be) somewhat independent. That was a bit of a hassle, but it's neater this way as well as being openocd policy from what I've read. svf_chain_cmd_parser.patch : Main patch, chain tap handling and updated command parser, mostly the same as earlier submitted patch. svf_file_handling.patch: converts file handling from open to fopen etc. Also input files are read as whole lines before parsing. Debatable whether this is neater code, but it does result in 10% speed improvement for me, and should be more portable. svf_progress_indicator.patch: Adds progress indicator (xx% readout) when (-)progress flag added to command line. this works in both quiet and non-quiet modes. This patch is dependent on svf_file_handling.patch being previously applied. svf_time_output_format.patch: time taken readout at end of svf operation converted from direct ms output to minutes-seconds-ms output for better readability. I've used this newer version to program my a3p125 and a3p060 parts on identical chains with lpc3131 multiple times with different flags and haven't had any problems. One significant finding is the time difference when non-quiet (default) mode is used, particularly on windows the verbose output slows the overall operation down a _lot_. I'm talking 1mins 19sec for quiet compared to 6mins 40sec on verbose. The time difference on linux was much much less severe but I haven't tested it with the full length file, but but on a much shorter test file it was a difference of 8 seconds to 14 seconds. The programming works fine either way, just printing the lines takes some time. This slow file is ~290,000 lines of svf, so not surprising that it takes some time to print all this to console. Andrew svf_chain_cmd_parser.patch Description: Binary data svf_file_handling.patch Description: Binary data svf_progress_indicator.patch Description: Binary data svf_time_output_format.patch Description: Binary data ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] TARGET: Add "phys" flag to dump_image command
Øyvind Harboe writes: > This patch introduces a serious and sweeping regression that > a compiler warning caught: Indeed. Thanks for catching this and sorry for forgetting the return. > How's the attached updated patch? Looks definitely better. Should "phys" flag also be added to "load_image" command? Alternatively, would it be possible to expose e.g. arm920t_disable_mmu_caches somehow to the command interface so that I could disable the MMU and then use "load_image" with physical addresses? ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Current stable release is very very stale
Hi, On Nov 29, 2010, at 1:26 PM, Michael Schwingen wrote: > On 11/29/2010 02:57 PM, Tomek CEDRO wrote: >> ...however I can understand the urge to have stable release done. If the >> GIT repository contains mainly bugfixes, then maybe it is time to freeze it >> as 0.4.1, so we can release 0.5.0 with SWD suport as planned - anyway it >> will probably happen soon when the SWD is already implemented and tested..? > Sounds good. > If we currently tell people with problems to try the master branch, I think > it is time for a new release, even if it contains only bugfixes and no major > new features. I agree on that. Still I think it should be tested more. For example the problems I currently have on Mac OS should be resolved before a point release is done? But in general there should be regular point releases with bugfixes, additional scripts and so on. So that distributions like Debian can update their packages and contain all the small fixes and scripts for everyone to use easily. Otherwise the maintainers will fall back to the earlier mode, where they were packaging some arbitrary git revisions, to provide the users with a slightly more up to date version of openocd. Major features always need a long time and should be released in their own pace. Cheers Esden -- Blog: http://www.esden.net Projects: http://open-bldc.org http://paparazziuav.org http://github.org/esden/floss-jtag http://github.org/esden/summon-arm-toolchain PGP.sig Description: This is a digitally signed message part ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PULL-REQUEST] Floss-JTAG and Lisa/L updates and fixes
On 2010-11-29 22:29, Øyvind Harboe wrote: Does anyone have any objections to committing this? The changes are mostly in cfg files anyway, new FT2232 interface type and blinking function is added, only used by this specific JTAG type, so (IMO) no chance to break anything (; 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PULL-REQUEST] Floss-JTAG and Lisa/L updates and fixes
On Nov 29, 2010, at 1:29 PM, Øyvind Harboe wrote: > Does anyone have any objections to committing this? > > Are you the expert on this interface? Umm well, I designed both of the JTAG adapters, the one on Lisa/L and Floss-JTAG. If that is what you mean. Cheers Esden -- Blog: http://www.esden.net Projects: http://open-bldc.org http://paparazziuav.org http://github.org/esden/floss-jtag http://github.org/esden/summon-arm-toolchain PGP.sig Description: This is a digitally signed message part ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PULL-REQUEST] Floss-JTAG and Lisa/L updates and fixes
Does anyone have any objections to committing this? Are you the expert on this interface? -- Ø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
Re: [Openocd-development] Current stable release is very very stale
On 11/29/2010 02:57 PM, Tomek CEDRO wrote: > > ...however I can understand the urge to have stable release done. If > the GIT repository contains mainly bugfixes, then maybe it is time to > freeze it as 0.4.1, so we can release 0.5.0 with SWD suport as planned > - anyway it will probably happen soon when the SWD is already > implemented and tested..? > Sounds good. If we currently tell people with problems to try the master branch, I think it is time for a new release, even if it contains only bugfixes and no major new features. cu Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Current stable release is very very stale
On 2010-11-29 07:40, Eric Parsonage wrote: I want a release version of openocd that supports Lisa-l. Lisa-l support has been in the code for several months now but there is no sight of any release. BTW if you use Windows, you can download development versions of OpenOCD from my webpage - usually updated every 2 months (however if you need some specific version you can always ask). http://www.freddiechopin.info/index.php/en/download/category/10-openocd-dev 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PULL-REQUEST] Floss-JTAG and Lisa/L updates and fixes
On Nov 29, 2010, at 1:06 PM, Øyvind Harboe wrote: > Hi, > > could you post the patches. > > Thanks! > > Easier to review and the way things are normally done here > on the list. Mehh :/ But sure, no problem, here you go! :D Cheers Esden -- Blog: http://www.esden.net Projects: http://open-bldc.org http://paparazziuav.org http://github.org/esden/floss-jtag http://github.org/esden/summon-arm-toolchain 0001-Updated-Floss-JTAG-config-file-to-support-v0.3-and-n.patch Description: Binary data 0002-Added-support-for-the-blinking-leds-on-Floss-JTAG-v0.patch Description: Binary data 0003-Some-cosmetic-fixes-to-the-Lisa-L-layout-support-fun.patch Description: Binary data PGP.sig Description: This is a digitally signed message part ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PULL-REQUEST] Floss-JTAG and Lisa/L updates and fixes
Hi, could you post the patches. Thanks! Easier to review and the way things are normally done here on the list. -- Ø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] [PULL-REQUEST] Floss-JTAG and Lisa/L updates and fixes
Hi, I would like to submit a pull request for the following list of patches: 32e46fb79d7c771d2488 Updated Floss-JTAG config file to support v0.3 and newer. Also added noeeprom version of the config file for older versions of Floss-JTAG. d4bdd0ceb4e0299b8c58 Added support for the blinking leds on Floss-JTAG v0.3 and newer. 7d982dc2d5f00a41362e Some cosmetic fixes to the Lisa/L layout support functions. From here: https://github.com/esden/openocd Cheers Esden -- Blog: http://www.esden.net Projects: http://open-bldc.org http://paparazziuav.org http://github.org/esden/floss-jtag http://github.org/esden/summon-arm-toolchain PGP.sig Description: This is a digitally signed message part ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Current stable release is very very stale
On 2010-11-29 14:44, Tomek CEDRO wrote:
The SWD API is almost done, for few days already im trying to integrate
it into UrJTAG as this is simpler software than OpenOCD from complexity
point of view. When transport is verifed (~week 49/50) im moving to
OpenOCD and debugging. The hardware I am working on in stm32primer{1,2}
and KT-LINK SWJ cable based on FT2232H. I want it all to work by end of
year :-)
This would be great!
Do you have some idea how can SWD be used with "typical" FT2232 based
JTAGs - these which don't have direction control for SWDIO (like Amontec
JTAGkey, Turtelizer, etc.)?
4\/3!!
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] STM32 reset halt segfault on Mac OS X
Hi, On Nov 28, 2010, at 4:56 AM, Øyvind Harboe wrote: > This is a backtrace without line numbers. Could you try to > produce a backtrace with linenumbers? Yes sorry about that, here you go: #0 0x000100073314 in mem_ap_read_atomic_u32 (dap=0x10032f540, address=1, value=0x10032e800) at arm_adi_v5.c:214 #1 0x0001000b8a9a in jim_target_reset (interp=0x100308c90, argc=3, argv=0x7fff5fbfca48) at target.c:4321 #2 0x0001000cf4ca in command_unknown (interp=0x100308c90, argc=4, argv=0x7fff5fbfca40) at command.c:1053 #3 0x0001000e6f73 in Jim_EvalObj (interp=0x100308c90, scriptObjPtr=0x101857fe0) at jim.c:9422 #4 0x0001000ebef1 in Jim_EvalCoreCommand (interp=0x100308c90, argc=3, argv=0x7fff5fbfcb70) at jim.c:11579 #5 0x0001000e6f73 in Jim_EvalObj (interp=0x100308c90, scriptObjPtr=0x10032b5a0) at jim.c:9422 #6 0x0001000e6c88 in Jim_EvalObj (interp=0x100308c90, scriptObjPtr=0x1003196e0) at jim.c:9347 #7 0x0001000ea13b in Jim_IfCoreCommand (interp=0x100308c90, argc=5, argv=0x7fff5fbfcda0) at jim.c:10704 #8 0x0001000e6f73 in Jim_EvalObj (interp=0x100308c90, scriptObjPtr=0x10030f620) at jim.c:9422 #9 0x0001000e7681 in JimCallProcedure (interp=0x100308c90, cmd=0x100318350, filename=0x101857390 "", linenr=1, argc=3, argv=0x7fff5fbfcf58) at jim.c:9603 #10 0x0001000e6fa9 in Jim_EvalObj (interp=0x100308c90, scriptObjPtr=0x100388470) at jim.c:9425 #11 0x0001000ebef1 in Jim_EvalCoreCommand (interp=0x100308c90, argc=4, argv=0x7fff5fbfd060) at jim.c:11579 #12 0x0001000e6f73 in Jim_EvalObj (interp=0x100308c90, scriptObjPtr=0x10032e780) at jim.c:9422 #13 0x0001000e7681 in JimCallProcedure (interp=0x100308c90, cmd=0x100331080, filename=0x100388590 "embedded:startup.tcl", linenr=240, argc=3, argv=0x7fff5fbfd210) at jim.c:9603 #14 0x0001000e6fa9 in Jim_EvalObj (interp=0x100308c90, scriptObjPtr=0x101857970) at jim.c:9425 #15 0x0001000ea13b in Jim_IfCoreCommand (interp=0x100308c90, argc=3, argv=0x7fff5fbfd330) at jim.c:10704 #16 0x0001000e6f73 in Jim_EvalObj (interp=0x100308c90, scriptObjPtr=0x101854580) at jim.c:9422 #17 0x0001000e9e6c in JimForeachMapHelper (interp=0x100308c90, argc=4, argv=0x7fff5fbfd520, doMap=0) at jim.c:10641 #18 0x0001000ea045 in Jim_ForeachCoreCommand (interp=0x100308c90, argc=4, argv=0x7fff5fbfd520) at jim.c:10673 #19 0x0001000e6f73 in Jim_EvalObj (interp=0x100308c90, scriptObjPtr=0x100317e40) at jim.c:9422 #20 0x0001000e7681 in JimCallProcedure (interp=0x100308c90, cmd=0x10031b840, filename=0x101854140 "embedded:startup.tcl", linenr=180, argc=0, argv=0x7fff5fbfd6c0) at jim.c:9603 #21 0x0001000e6fa9 in Jim_EvalObj (interp=0x100308c90, scriptObjPtr=0x100329f60) at jim.c:9425 #22 0x0001000ee7ef in Jim_CatchCoreCommand (interp=0x100308c90, argc=2, argv=0x7fff5fbfd838) at jim.c:12394 #23 0x0001000e6f73 in Jim_EvalObj (interp=0x100308c90, scriptObjPtr=0x10032a260) at jim.c:9422 #24 0x0001000e6269 in Jim_InterpolateTokens (interp=0x100308c90, token=0x101853fb0, tokens=2, objPtrPtr=0x7fff5fbfda30) at jim.c:9099 #25 0x0001000e6ce9 in Jim_EvalObj (interp=0x100308c90, scriptObjPtr=0x10032a2b0) at jim.c:9360 #26 0x0001000e6c88 in Jim_EvalObj (interp=0x100308c90, scriptObjPtr=0x100317b60) at jim.c:9347 #27 0x0001000e7681 in JimCallProcedure (interp=0x100308c90, cmd=0x10031b940, filename=0x101851b90 "", linenr=1, argc=0, argv=0x7fff5fbfdc70) at jim.c:9603 #28 0x0001000e6fa9 in Jim_EvalObj (interp=0x100308c90, scriptObjPtr=0x10032a7e0) at jim.c:9425 #29 0x0001000e78b0 in Jim_Eval_Named (interp=0x100308c90, script=0x7fff5fbfddd0 "ocd_process_reset halt", filename=0x0, lineno=0) at jim.c:9666 #30 0x0001000e7905 in Jim_Eval (interp=0x100308c90, script=0x7fff5fbfddd0 "ocd_process_reset halt") at jim.c:9674 #31 0x0001000af555 in target_process_reset (cmd_ctx=0x101853160, reset_mode=RESET_HALT) at target.c:505 #32 0x0001000b2ebe in handle_reset_command (cmd=0x7fff5fbfdec0) at target.c:2203 #33 0x0001000ce2f8 in run_command (context=0x101853160, c=0x1003288d0, words=0x10183bb60, num_words=2) at command.c:627 #34 0x0001000cd2cc in script_command_run (interp=0x100308c90, argc=2, argv=0x7fff5fbfdfd0, c=0x1003288d0, capture=true) at command.c:227 #35 0x0001000cd37a in script_command (interp=0x100308c90, argc=2, argv=0x7fff5fbfdfd0) at command.c:242 #36 0x0001000e6f73 in Jim_EvalObj (interp=0x100308c90, scriptObjPtr=0x10032b6e0) at jim.c:9422 #37 0x0001000ebef1 in Jim_EvalCoreCommand (interp=0x100308c90, argc=3, argv=0x7fff5fbfe100) at jim.c:11579 #38 0x0001000e6f73 in Jim_EvalObj (interp=0x100308c90, scriptObjPtr=0x10031aa90) at jim.c:9422 #39 0x0001000ee7ef in Jim_CatchCoreCommand (interp=0x100308c90, argc=1, argv=0x7fff5fbfe288) at jim.c:12394 #40 0x0001000e6f73 in Jim_EvalObj (interp=0x100308c90, scriptObjPtr=0x10031a5d0) at jim.c:9422 #41 0x0001000e42b2 in Jim_EvalExpression (interp=0x100308c90, exprObjPtr=0x
Re: [Openocd-development] [PATCH] TARGET: Add "phys" flag to dump_image command
This patch introduces a serious and sweeping regression that
a compiler warning caught:
cc1: warnings being treated as errors
src/target/target.c: In function ‘target_read_buffer’:
src/target/target.c:1490: error: control reaches end of non-void function
How's the attached updated patch?
(Otherwise the patch seems fine to me)
--
Ø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
From d5a167f186dddc060c1a287c6a2f168975976789 Mon Sep 17 00:00:00 2001
From: Timo Juhani Lindfors
Date: Sun, 28 Nov 2010 19:30:12 +0200
Subject: [PATCH] TARGET: Add "phys" flag to dump_image command
---
doc/openocd.texi|9 ++---
src/target/target.c | 37 +
2 files changed, 35 insertions(+), 11 deletions(-)
diff --git a/doc/openocd.texi b/doc/openocd.texi
index 70d789a..1b75f94 100644
--- a/doc/openocd.texi
+++ b/doc/openocd.texi
@@ -5731,9 +5731,12 @@ Otherwise, or if the optional @var{phys} flag is specified,
@cindex image dumping
@anchor{dump_image}
-...@deffn Command {dump_image} filename address size
-Dump @var{size} bytes of target memory starting at @var{address} to the
-binary file named @var{filename}.
+...@deffn Command {dump_image} [phys] filename address size
+Dump @var{size} bytes of target memory starting at @var{address} to
+the binary file named @var{filename}. When the current target has an
+MMU which is present and active, @var{addr} is interpreted as a
+virtual address. Otherwise, or if the optional @var{phys} flag is
+specified, @var{addr} is interpreted as a physical address.
@end deffn
@deffn Command {fast_load}
diff --git a/src/target/target.c b/src/target/target.c
index 93efa76..01dfa6b 100644
--- a/src/target/target.c
+++ b/src/target/target.c
@@ -1393,12 +1393,22 @@ int target_write_buffer(struct target *target, uint32_t address, uint32_t size,
* mode respectively, otherwise data is handled as quickly as
* possible
*/
-int target_read_buffer(struct target *target, uint32_t address, uint32_t size, uint8_t *buffer)
+static int target_read_buffer2(struct target *target, uint32_t address, uint32_t size, uint8_t *buffer, bool physical)
{
int retval;
LOG_DEBUG("reading buffer of %i byte at 0x%8.8x",
(int)size, (unsigned)address);
+ int (*read_fn)(struct target *target,
+ uint32_t address, uint32_t size, uint32_t count, uint8_t *buffer);
+ if (physical)
+ {
+ read_fn=target_read_phys_memory;
+ } else
+ {
+ read_fn=target_read_memory;
+ }
+
if (!target_was_examined(target))
{
LOG_ERROR("Target not examined yet");
@@ -1420,7 +1430,7 @@ int target_read_buffer(struct target *target, uint32_t address, uint32_t size, u
if (((address % 2) == 0) && (size == 2))
{
- return target_read_memory(target, address, 2, 1, buffer);
+ return read_fn(target, address, 2, 1, buffer);
}
/* handle unaligned head bytes */
@@ -1431,7 +1441,7 @@ int target_read_buffer(struct target *target, uint32_t address, uint32_t size, u
if (unaligned > size)
unaligned = size;
- if ((retval = target_read_memory(target, address, 1, unaligned, buffer)) != ERROR_OK)
+ if ((retval = read_fn(target, address, 1, unaligned, buffer)) != ERROR_OK)
return retval;
buffer += unaligned;
@@ -1444,7 +1454,7 @@ int target_read_buffer(struct target *target, uint32_t address, uint32_t size, u
{
int aligned = size - (size % 4);
- if ((retval = target_read_memory(target, address, 4, aligned / 4, buffer)) != ERROR_OK)
+ if ((retval = read_fn(target, address, 4, aligned / 4, buffer)) != ERROR_OK)
return retval;
buffer += aligned;
@@ -1456,7 +1466,7 @@ int target_read_buffer(struct target *target, uint32_t address, uint32_t size, u
if(size >=2)
{
int aligned = size - (size%2);
- retval = target_read_memory(target, address, 2, aligned / 2, buffer);
+ retval = read_fn(target, address, 2, aligned / 2, buffer);
if (retval != ERROR_OK)
return retval;
@@ -1467,13 +1477,18 @@ int target_read_buffer(struct target *target, uint32_t address, uint32_t size, u
/* handle tail writes of less than 4 bytes */
if (size > 0)
{
- if ((retval = target_read_memory(target, address, 1, size, buffer)) != ERROR_OK)
+ if ((retval = read_fn(target, address, 1, size, buffer)) != ERROR_OK)
return retval;
}
return ERROR_OK;
}
+int target_read_buffer(struct target *target, uint32_t address, uint32_t size, uint8_t *buffer)
+{
+ return target_read_buffer2(target, address, size, buffer, false);
+}
+
int target_checksum_memory(struct target *target, uint32_t address, uint32_t size, uint32_t* crc)
{
uint8_t *buffer;
@@ -2605,6 +2620,12 @@ COMMAND_HANDLER(handle_dump_image_command)
struct duration bench;
struct target *target = get_current_target(CMD_CTX);
+ bool physical=strcmp(CMD_ARGV[0], "phys")==0;
+ if (physical)
+ {
+ CMD_ARGC--;
+ CMD_ARGV++
Re: [Openocd-development] Current stable release is very very stale
...however I can understand the urge to have stable release done. If the GIT repository contains mainly bugfixes, then maybe it is time to freeze it as 0.4.1, so we can release 0.5.0 with SWD suport as planned - anyway it will probably happen soon when the SWD is already implemented and tested..? The numbers are not that important as the user experience coming from upgraded, verified and functional release, and I think this thread is a request for one :-) Best regards, Tomek ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Current stable release is very very stale
Hello Simon, Hello Open'ers :-)
The SWD API is almost done, for few days already im trying to integrate it
into UrJTAG as this is simpler software than OpenOCD from complexity point
of view. When transport is verifed (~week 49/50) im moving to OpenOCD and
debugging. The hardware I am working on in stm32primer{1,2} and KT-LINK SWJ
cable based on FT2232H. I want it all to work by end of year :-)
Please take a look at poject website: http://stm32primer2swd.sf.net
Best regards,
Tomek Cedro
On 29 Nov 2010 14:15, "simon qian" wrote:
> How is going on SWD support?
> I haven't follow it for a long time, because I'm too busy with another
> project.
> Maybe I can provide some fund for this next year.
> Or I can provide some versaloon hardwares on which SWD is working.
>
> Does the FT-based driver for SWD implemented?
> I think the driver should be implemented first, so that other code and test
> can proceed.
>
> 2010/11/29
>
>
> >
> > "Eric Parsonage" napisał(a):
> > > I am keen to hear when the next stable ...
>
>
>
> --
> Best Regards, SimonQian
> http://www.SimonQian.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] LPC2919 segmentation fault
Hi Rolf, you're the expert here. Let me know when you think the change is ready to go in. -- Ø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
Re: [Openocd-development] Current stable release is very very stale
How is going on SWD support? I haven't follow it for a long time, because I'm too busy with another project. Maybe I can provide some fund for this next year. Or I can provide some versaloon hardwares on which SWD is working. Does the FT-based driver for SWD implemented? I think the driver should be implemented first, so that other code and test can proceed. 2010/11/29 > "Eric Parsonage" napisał(a): > > I am keen to hear when the next stable release of openocd is going to be > available ? > > I want a release version of openocd that supports Lisa-l. > > Lisa-l support has been in the code for several months now but there is > no sight of any release. > > I dont understand why the process is taking so long ? can somebody > explain ? > > It was said that the milestone for next release is SWD support, so probably > we'll have to wait a long time to see it ;( As you see (probably) nothing is > going on in this matter... > > 4\/3!! > ___ > Openocd-development mailing list > Openocd-development@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/openocd-development > -- Best Regards, SimonQian http://www.SimonQian.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] can openocd support PXA920 ? can't halt it
with the 0.4.0 and latest openocd, I can't recognize the CPU ID, but can't halt
it.
the log is:
$ telnet localhost
Trying ::1...
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Open On-Chip Debugger
> halt
Halt timed out, wake up GDB.
invalid mode value encountered 0
cpsr contains invalid mode value - communication failure
Command handler execution failed
in procedure 'halt'
> reset halt
JTAG tap: pxa920.cpu tap/device found: 0x0c9203d3 (mfg: 0x1e9, part: 0xc920,
ver: 0x0)
timed out while waiting for target halted
TARGET: pxa920.cpu - Not halted
Command handler execution failed
in procedure 'reset'
> halt
Halt timed out, wake up GDB.
timed out while waiting for target halted
Command handler execution failed
in procedure 'halt'
invalid mode value encountered 0
cpsr contains invalid mode value - communication failure
Polling target failed, GDB will be halted. Polling again in 100ms
Polling succeeded again
the configuration file is:
# Marvell PXA920
jtag_khz 1000
if { [info exists CHIPNAME] } {
set _CHIPNAME $CHIPNAME
} else {
set _CHIPNAME pxa920
}
if { [info exists ENDIAN] } {
set _ENDIAN $ENDIAN
} else {
set _ENDIAN little
}
# IDs for all currently known pxa920 chips
if { [info exists CPUTAPID_PXA920 ] } {
set _CPUTAPID_PXA920 $CPUTAPID_PXA920
} else {
set _CPUTAPID_PXA920 0x0c9203d3
}
# set jtag_nsrst_delay to the delay introduced by your reset circuit
# the rest of the needed delays are built into the openocd program
jtag_nsrst_delay 260
reset_config trst_and_srst
# set the jtag_ntrst_delay to the delay introduced by a reset circuit
# the rest of the needed delays are built into the openocd program
jtag_ntrst_delay 250
set _TARGETNAME $_CHIPNAME.cpu
jtag newtap $_CHIPNAME cpu -irlen 11 -ircapture 0x1 -irmask 0x7f \
-expected-id $_CPUTAPID_PXA920
target create $_TARGETNAME arm966e -endian $_ENDIAN \
-chain-position $_TARGETNAME -variant arm946
# work area in internal RAM.
$_TARGETNAME configure -work-area-phys 0xD100A000 -work-area-size 0x2
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
