Re: [Openocd-development] [patch 2/3] Cortex-A8: support reset-assert event
David Brownell wrote: Use the new reset-assert event; else SRST; else fail. Tested on an OMAP3, using the event. NOTE: still doesn't handle reset halt. For some reason neither VCR nor PRCR seemed effective; they held the value that was written, but VCR didn't trigger debug entry when the reset vector fired (maybe the vector needs configuring?) and PRCR refused to hold the chip in reset until deassert() could force the core into debug state. --- The Cortex-A8 core always resets into Secure Supervisor Mode so SPIDEN must be set high to enable vector catch of Reset ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] first round of mcr mrc interface support completed
2009-10-25 12:31, Øyvind Harboe skrev: You make excellent general points in your post and I agree to what you are saying, however here I'm discussing mrc/mcr specifically and how to proceed with that one. Did you read up on mrc/mcr in targets and consider the current patches changes in detail? If you still disagree with my piecemail approach after having read up on the mcr/mrc details, then I'll be happy to go along with whatever you propose from a general git/patch/branch development point of view on the mcr/mrc case. If I have to commit to doing *all* the work before I start any mrc/mcr work at all, then I'm loathe to start at all and I'd rather just revert the changes I've done so far. Again, this was just a next natural step after having done the memory physical read/write work... Some comments: I prefer read_cp/write_cp to mrc/mcr, since we really want to read/write to the coprocessor registers. The fact that this is implemented using the mrc/mcr instructions is not important here. There are no other arm instructions treated like that, rather we specifiy the registers, memory etc. that we want to access. It is definitely possible that there might be a future coprocessor access debug component that accesses coprocessors using a coresight memory mapped interface. This is pure speculation but is intended to show why read_cp/write_cp better reflects the intended function of this interface. The natural place for this would IHMO be armv4_5, this will include Armv7A targets but not Armv7M targets. Best regards, Magnus ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] first cut at implementing arm926ejs breakpoints in mmu read only memory
2009-10-21 13:12, Øyvind Harboe skrev: Testing and comments much appreciated! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development The va to pa translation should not be done if MMU is not enabled, or rather was not enabled when the target was halted, so that relevant address ranges are actually mapped through the MMU. Best regards, Magnus ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] first round of mcr mrc interface support completed
Thanks for commenting on actual mrc/mcr stuff :-) I can't really comment on whether read_cp/write_cp would be better, I trust you on that one. It should be a trivial modification to the command or interface once we have something common across the implementations to build on. The natural place for this would IHMO be armv4_5, this will include Armv7A targets but not Armv7M targets. armv4_5 isn't used for arm11, so armv4_5 doesn't quite work. Note that armv4_5 is not a pure interface, it's a mix of an interface and an implementation. -- Ãyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer The Arm11 code in OpenOCD was written from scratch and does not use the common Armv4_5 infrastructure or even coding conventions. This is interesting as an alternative test implementation, but we should not use it as an argument on how common ARM architecture stuff should be handled. In this case we keep arm11 as is and later arm11 should be modified to align with the rest of the ARM architecture. Yes armv4_5 is more of an intermediate (abstract) class than a pure interface. It is the right place also to implement some common functionality. Best regards, Magnus ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] first round of mcr mrc interface support completed
As usual, I vote for not retiring old versions to quickly. /M ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] target_phys_read/write_memory writeup
Øyvind Harboe wrote: On Wed, Oct 21, 2009 at 6:43 PM, David Brownell davi...@pacbell.net wrote: On Wednesday 21 October 2009, Řyvind Harboe wrote: Once these changes and discussion has had some time to settle, it would make sense to retire all the mXX_phys commands and let the target.c implementation of mXX w/the phys flag handle those cases... You seem to have done this already (less associated doc updates) ... but I missed the discussion and settle stages! :) Yeah there was actually some prior discussion on this a couple of days ago and I had a small git mishap earlier today when I pushed some stuff that I didn't think was going to be pushed. Moving ahead seemed like the best choice. I'll be doing some more reading on git... There are also some uses of the *_phys stuff in tcl/* files that need to be updated... OK, will fix. My 2 cents: This is not a heavy useage area, since MMU virt/phys handling is very primitive. As far as I can se Öyvinds ideas are sound, setting up the infrastructure in target.c and doing a specific test implementation for 926ejs is a reasonable plan. When this works well, as Övind says, there must be some rewrites of target scripts and documentation to use the new and IHMO improved syntax. Then we can implement target specifc low level handlers. At the moment my BeagleBoard has developed a fever (methinks it is dead) and other work keeps calling, but I think for Cortex A8 and all Armv7A this should work fine. Best regards, Magnus (note: I have now agreed to Övinds proposals two days in a row without any complaints, perhaps I am losing my edge) ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] making target_write_memory() disable read-only MMU bit
Øyvind Harboe wrote: Would anybody object strongly to making target_write_memory() temporarily disable MMU read-only bits? This would be e.g. to enable setting breakpoints in memory the MMU has mapped as read-only. If someone has tips or ideas on how to implement this, I would greatly appreciate input. What target ? It is simple for the Cortex A8. Ask for virt2phys address translation, then write directly to phys RAM and remember to invalidate the I-cache. Best regards, Magnus ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] flash protection
Øyvind Harboe wrote: There is an autoerase option to flash write_image. Would you object strongly to autoerase automatically unlocking the flash if necessary? On some targets the write with autoerase is very slow. A sector erase or full erase followed by write is much faster. IMHO autoerase should not be automatic. Unlocking flash is good. Best regards Magnus ___ 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 #?
Øyvind Harboe wrote: 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. Actually you can checkout things like $ git checkout master~2 Makefile See the branch section and the examples in http://www.kernel.org/pub/software/scm/git/docs/git-checkout.html ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] ADIv5 handling proposal
Without looking deeply (lot of other work the coming weeks) I think this is good, but I would like it in a separate file(module). Called adiv5_component, adiv5_debug or coresight_component ?? So the adiv5 code talks to the MEMAP registers but does not handle the memory mapped components that are accessed through the the MEMAP. This includes the content of the ROMTABLE. Best regards, Magnus Hi! What about implementing more generic access to ADIv5 and APB-AP? I see it like this but what gurus have in mind? ___ 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] ADIv5 handling proposal
Yauheni Kaliuta wrote: Hi! On Tue, Oct 13, 2009 at 1:28 PM, Magnus Lundin lun...@mlu.mine.nu wrote: Without looking deeply (lot of other work the coming weeks) I think this is good, but I would like it in a separate file(module). Called adiv5_component, adiv5_debug or coresight_component ?? So the adiv5 code talks to the MEMAP registers but does not handle the memory mapped components that are accessed through the the MEMAP. This includes the content of the ROMTABLE. Hmm, I do not think so. 1) access to components is a part of the same ADIv5 specification IHI 0031A (shouldn't it be called then swjdp.c like it was?) I will expand my ideas a bit more. No, IHI0031A does not contain the full component specification, Arm ADI is the debug interface, and it does not specify the componets. The specification contains some information about the rom table structure and peripherial identification registers. These are specified in the CoreSight Architecture Specification ARM IHI 0029B. The actual debug comonents are specified in the ArmV7A TRM and Cortex A8 TRM. The importatnt distinction is that debug components are accesed through a memeory space, from a target level using memory reads and writes to the relevant memory space/bus. These components can also be accesed from the processor core over the memory bus. The Arm debug interface is just the set of DP and AP registers that the (recommended) external access implementation uses for access to this memory range. SWJ is the method to talk to DP and AP through JTAG or SW access. So the only target property that the component needs is the memory read/write, for the components the rest of adiv5 is irrelevant. For a target that controls the components using a swjdp interface it is also important to use the correct memap port if there are several, and to make sure that direct memory access is used with no cache or virtual addressing handling. Perhaps we need a taget level structure that describes a memory port, something that can be read and written like memory. The attributes would be * valid memory range * Physical/Virtual memory addressing * Cache handling * Pointer to a memory port driver that does the actual For a Cortex A8 we would have one memory port for each SWJDP-MEMAP port for direct physical access and one memory port for program memory that uses virtual addressing whem MMU is active and also controls cache cleaning and invalidation. We can have a separate memory port that accesses memory through the CPU. Of course twe some work on how to create a user/tcl interface for this structure. 2) if you want to have the layer independent of ap and components layers, then there should be no links in that direction, only from components towards DP. As a result the cpu layer, which uses both components and AP accesses should be aware of scanning, handling (storing/freeing...) scanning results and so on. Well, the target layer must be aware that scanning should be done and that there are components handled by the coresight component layer. Components do their stuff by reading and writing to memory. Even if we let the componets use the swjdp structure to access memory, I think it should be placed in a seperate file. Best regards, Magnus ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Any ideas how OpenOCD should handle virtual addressing and cache coherency?
Øyvind Harboe wrote: On Tue, Oct 13, 2009 at 7:45 PM, Magnus Lundin lun...@mlu.mine.nu wrote: Yauheni Kaliuta wrote: Hi, Magnus! ML == Magnus Lundin writes: [...] I have a simple works for me implementation of memory access with cpu instead of AHB and virt2phys using cp15 for cortex_a8, but already got a problem with interfaces: there is only one set of functions on the high target level and if I switch them to mmu variants, I cannot enable debug on omap from tcl config, direct access is required there. Can you post your virt2phys and read/write memory through cpu. I think the virt2phys should be added to the trunk as soon as possible, and it should be in armv7a.c Ok, I'll recheck it. But what do you think about having read/write_phys on target_common_t level? For me that sounds good, with default implementation begin the same as read/write. Then we only need one implementation of the command handler for read/write_phys. Since this touches all targets we need input from more developers, but I can see no obvious problems. I don't think you need to touch all the targets? Can't you just provide a default implementation? You are right it does not touch the code, but it does change the target type structure and the corresponding entry should be set to NULL or the default implementation. This can be done in target.c:target_init() before calling target-type-init_target(cmd_ctx, target). There are some other fields like virt2phys that should be given default values here. Best regards, Magnus ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Any ideas how OpenOCD should handle virtual addressing and cache coherency?
Magnus Lundin wrote: Øyvind Harboe wrote: On Tue, Oct 13, 2009 at 7:45 PM, Magnus Lundin lun...@mlu.mine.nu wrote: Yauheni Kaliuta wrote: Hi, Magnus! ML == Magnus Lundin writes: [...] I have a simple works for me implementation of memory access with cpu instead of AHB and virt2phys using cp15 for cortex_a8, but already got a problem with interfaces: there is only one set of functions on the high target level and if I switch them to mmu variants, I cannot enable debug on omap from tcl config, direct access is required there. Can you post your virt2phys and read/write memory through cpu. I think the virt2phys should be added to the trunk as soon as possible, and it should be in armv7a.c Ok, I'll recheck it. But what do you think about having read/write_phys on target_common_t level? For me that sounds good, with default implementation begin the same as read/write. Then we only need one implementation of the command handler for read/write_phys. Since this touches all targets we need input from more developers, but I can see no obvious problems. I don't think you need to touch all the targets? Can't you just provide a default implementation? You are right it does not touch the code, but it does change the target type structure and the corresponding entry should be set to NULL or the default implementation. This can be done in target.c:target_init() before calling target-type-init_target(cmd_ctx, target). There are some other fields like virt2phys that should be given default values here. Looking at the code a little, all targets should initialize all target type fields when defining the specific target type structure. This is not true for mmu and virt2phys fields. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Moving to git
My impression, after using git just a little, is that it is a good tool, it takes some learning for effective use. For development work it seems that it gives me much better support for testing several different versions of experimental code than SVN so here it is a big step forward. I do not know anything about mercurial, but beeing written in Python is not enough to convince me, even though I do use and like Python. Regards, Magnus ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] Updated omap3530.cfg with improved reset handling
We can, and sometimes we want to, write to memory while the CortexA8 core is running, but for gbd to load a program and the i-caches to be cleared to core must be halted. So I think there must be a monitor halt after the monitor omap3_dbginit No. I just do arm-none-linux-gnueabi-gdb with cat .gdbinit echo Setting up the environment for debugging gdb.\n # This connects to OpenOcd at localhost: target remote localhost: # Increase the packet size to improve download speed. set remote memory-write-packet-size 1024 set remote memory-write-packet-size fixed #omap3_dbginit must be run in OpenOCD after every reset monitor omap3_dbginit monitor halt # Load the program executable called LEDblink load LEDblink # Load the symbols for the program. symbol-file LEDblink Dirk Magnus ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] Updated omap3530.cfg with improved reset handling
David Brownell wrote: I think that's not quite following the model which the code in the src/helper/startup.tcl file is expecting ... a closer match would use reset-assert-pre (or maybe post) not reset-start. I have done some more testing and trying to understand the reset handling in OpenOCD. This is my understanding of the sequence - reset-start jtag-reset Here the omap3.dap tap is marked as disabled reset-assert-pre target reset assert This is only called if the tap is enabled For CortexA8 we want to set target state to reset and invalidate all cached registers reset assert post reset-deassert-pre target reset deassert This is only called if the tap is enabled For CortexA8 we want to halt the target for reset halt, this needs the tap to be enabled reset deassert post reset end -- My interpretation is: We must write the reset command to PRM_RSTCTRL before the jtag reset stuff. Otherwise the tap will be marked as disabled, even if is still enabled, since the reset has not yet happened, and the mww is impossible. ( It actually kills OpenOCD with openocd: driver.c:243: interface_jtag_add_dr_scan: Assertion `field == out_fields + scan-num_fields' failed. ) The omap3_debugint must be called after the jtag reset stuff and before target reset assert Otherwise the CortexA8 reset assert will not be called since the tap is disabled This gives the following reset event configurationb: omap3.cpu configure -event reset-start omap3.cpu mww $PRM_RSTCTRL 2 omap3.cpu configure -event reset-assert-pre omap3_dbginit Best regards, Magnus ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] Updated omap3530.cfg with improved reset handling
For testing and comments:
Uses the OMAP3530 global software reset and defines corresponding
reset-start and reset-end event handlers.
Best regards,
Magnus
===
.
.
# FIXME much of this should be in reset event handlers
proc omap3_dbginit { } {
poll off
sleep 100
jtag tapenable omap3530.dap
targets
# General Cortex A8 debug initialisation
cortex_a8 dbginit
# Enable DBGU singal for OMAP353x
omap3.cpu mww 0x5401d030 0x2000
poll on
}
set PRM_RSTCTRL 0x48307250
proc omap3_reset { } {
# Global software reset
# RST_GS bit in PRM_RSTCTRL
mww $PRM_RSTCTRL 2
omap3_dbginit
halt
}
omap3.cpu configure -event reset-start omap3.cpu mww $PRM_RSTCTRL 2
omap3.cpu configure -event reset-end omap3_dbginit
Index: tcl/target/omap3530.cfg
===
--- tcl/target/omap3530.cfg (working copy)
+++ tcl/target/omap3530.cfg (revision 2768)
@@ -2,9 +2,9 @@
# http://focus.ti.com/docs/prod/folders/print/omap3530.html
# Other OMAP3 chips remove DSP and/or the OpenGL support
-if { [info exists CHIPNAME] } {
- set _CHIPNAME $CHIPNAME
-} else {
+if { [info exists CHIPNAME] } {
+ set _CHIPNAME $CHIPNAME
+} else {
set _CHIPNAME omap3530
}
@@ -42,6 +42,7 @@
# FIXME much of this should be in reset event handlers
proc omap3_dbginit { } {
poll off
+ reset
sleep 100
jtag tapenable omap3530.dap
@@ -53,17 +54,3 @@
poll on
}
-set PRM_RSTCTRL 0x48307250
-
-proc omap3_reset { } {
- # Global software reset
- # RST_GS bit in PRM_RSTCTRL
- mww $PRM_RSTCTRL 2
- omap3_dbginit
- halt
-}
-
-omap3.cpu configure -event reset-start omap3.cpu mww $PRM_RSTCTRL 2
-omap3.cpu configure -event reset-end omap3_dbginit
-
-
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] Updated omap3530.cfg with improved reset handling
Well, some days our work is a bit more confused then other days.
Dirk Behme wrote:
Magnus Lundin wrote:
For testing and comments:
Uses the OMAP3530 global software reset and defines corresponding
reset-start and reset-end event handlers.
Something is wrong with the patch in attachment? It has to be done the
inverse? I.e.
--- tcl/target/omap3530.cfg(revision 2768)
+++ tcl/target/omap3530.cfg(working copy)
instead of
--- tcl/target/omap3530.cfg(working copy)
+++ tcl/target/omap3530.cfg(revision 2768)
This was done for me by the diff program in kdesvn, and I didnt read
carefully.
Additionally:
I can't find any difference (whitespace only?) in
-if { [info exists CHIPNAME] } {
- set _CHIPNAME $CHIPNAME
-} else {
+if { [info exists CHIPNAME] } {
+ set _CHIPNAME $CHIPNAME
+} else {
There was a whitespace patch from Dave that I had not applied on the tcl
directory.
And:
omap3.cpu configure -event reset-end omap3_dbginit
should call omap3_reset instead of omap3_dbginit? Or who calls
omap3_reset? Or why call omap3_dbginit from omap3_reset, too?
At the end of the reset handling we reinitialise the tap and the debug
interface with omap3_dbginit
omap3_reset is really reset+reinit+halt and you call it if you want to
debug the loading of u-boot by the X-Loader
New patch attaced.
Regards,
Magnus
Index: tcl/target/omap3530.cfg
===
--- tcl/target/omap3530.cfg (revision 2768)
+++ tcl/target/omap3530.cfg (working copy)
@@ -42,7 +42,6 @@
# FIXME much of this should be in reset event handlers
proc omap3_dbginit { } {
poll off
- reset
sleep 100
jtag tapenable omap3530.dap
@@ -54,3 +53,17 @@
poll on
}
+set PRM_RSTCTRL 0x48307250
+
+proc omap3_reset { } {
+ # Global software reset
+ # RST_GS bit in PRM_RSTCTRL
+ mww $PRM_RSTCTRL 2
+ omap3_dbginit
+ halt
+}
+
+omap3.cpu configure -event reset-start omap3.cpu mww $PRM_RSTCTRL 2
+omap3.cpu configure -event reset-end omap3_dbginit
+
+
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] Updated omap3530.cfg with improved reset handling
At the end of the reset handling we reinitialise the tap and the debug interface with omap3_dbginit omap3_reset is really reset+reinit+halt and you call it if you want to debug the loading of u-boot by the X-Loader Do you mean omap3_reset should be called 'manually' if needed, same like omap3_dbginit? Yes, try to use reset and omap3_reset in a telent session and see what happens, also check the output from BeagleBoard console window connected to the serial port. New patch attaced. Tested with 2771 and LEDblink example. No differences seen to svn version. Best regards Dirk Btw.: We still have the issue that first load of LEDblink with gdb fails: Are you running gdb from a script ? Regards, Magnus ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH]cortex_a8_init_debug_access
Magnus Lundin wrote:
For comments and testing:
Add actual code to the previously empty :
cortex_a8_init_debug_access()
Remove details of common cortex8a debug initalisations from
omap3_dbginit and replace with call to externally eposed
cortex_a8 dbginit function.
Best regards,
Magnus
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
And the patch is here :)
Index: tcl/target/omap3530.cfg
===
--- tcl/target/omap3530.cfg (revision 2710)
+++ tcl/target/omap3530.cfg (working copy)
@@ -59,10 +59,11 @@
# 0xd401.b000 - ETB
# 0xd401.d000 - DAPCTL
- omap3.cpu mww 0x54011FB0 0xC5ACCE55
+ cortex_a8 dbginit
+# omap3.cpu mww 0x54011FB0 0xC5ACCE55
- omap3.cpu mdw 0x54011314
- omap3.cpu mdw 0x54011314
+# omap3.cpu mdw 0x54011314
+# omap3.cpu mdw 0x54011314
# omap3.cpu mdw 0x54011080
omap3.cpu mww 0x5401d030 0x2000
Index: src/target/cortex_a8.c
===
--- src/target/cortex_a8.c (revision 2716)
+++ src/target/cortex_a8.c (working copy)
@@ -120,34 +120,27 @@
*/
int cortex_a8_init_debug_access(target_t *target)
{
-#if 0
-# Unlocking the debug registers for modification
-mww 0x54011FB0 0xC5ACCE55 4
+ /* get pointers to arch-specific information */
+ armv4_5_common_t *armv4_5 = target-arch_info;
+ armv7a_common_t *armv7a = armv4_5-arch_info;
+ swjdp_common_t *swjdp = armv7a-swjdp_info;
-# Clear Sticky Power Down status Bit to enable access to
-# the registers in the Core Power Domain
-mdw 0x54011314
-# Check that it is cleared
-mdw 0x54011314
-# Now we can read Core Debug Registers at offset 0x080
-mdw 0x54011080 4
-# We can also read RAM.
-mdw 0x8000 32
+ int retval;
+ uint32_t dummy;
-mdw 0x5401d030
-mdw 0x54011FB8
+ LOG_DEBUG( );
-# Set DBGEN line for hardware debug (OMAP35xx)
-mww 0x5401d030 0x2000
-
-#Check AUTHSTATUS
-mdw 0x54011FB8
-
-# Instr enable
-mww 0x54011088 0x2000
-mdw 0x54011080 4
-#endif
- return ERROR_OK;
+ /* Unlocking the debug registers for modification */
+ /* The debugport might be uninitialised so try twice */
+ retval = mem_ap_write_atomic_u32(swjdp, armv7a-debug_base + CPUDBG_LOCKACCESS, 0xC5ACCE55);
+ if (retval != ERROR_OK)
+ mem_ap_write_atomic_u32(swjdp, armv7a-debug_base + CPUDBG_LOCKACCESS, 0xC5ACCE55);
+ /* Clear Sticky Power Down status Bit in PRSR to enable access to
+ the registers in the Core Power Domain */
+ retval = mem_ap_read_atomic_u32(swjdp, armv7a-debug_base + CPUDBG_PRSR, dummy);
+ /* Enabling of instruction execution in debug mode is done in debug_entry code */
+
+ return retval;
}
int cortex_a8_exec_opcode(target_t *target, uint32_t opcode)
@@ -1441,6 +1434,9 @@
LOG_DEBUG(Configured %i hw breakpoint pairs and %i hw watchpoint pairs,
cortex_a8-brp_num , cortex_a8-wrp_num);
+ /* Configure core debug access */
+ cortex_a8_init_debug_access(target);
+
target-type-examined = 1;
return retval;
@@ -1559,6 +1555,17 @@
}
+static int cortex_a8_handle_dbginit_command(struct command_context_s *cmd_ctx,
+ char *cmd, char **args, int argc)
+{
+ target_t *target = get_current_target(cmd_ctx);
+
+ cortex_a8_init_debug_access(target);
+
+ return ERROR_OK;
+}
+
+
int cortex_a8_register_commands(struct command_context_s *cmd_ctx)
{
command_t *cortex_a8_cmd;
@@ -1575,5 +1582,9 @@
cortex_a8_handle_cache_info_command, COMMAND_EXEC,
display information about target caches);
+ register_command(cmd_ctx, cortex_a8_cmd, dbginit,
+ cortex_a8_handle_dbginit_command, COMMAND_EXEC,
+ Initialize core debug);
+
return retval;
}
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] debug message
Hi, This turns a warning into a debug message. It is printed if there is not as much working area as requested. Many callers try iteratively until a working area of suitable size is found. The current warnings are irritating. It should be up to the caller to decide if this is worth a warning. Most of them just fall back transparently to a different method. Regards, Rolf ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development I think this is OK, it does not change the return value, it is still reported as an error/exception condition, not ERROR_OK. So for the codebase nothing is changed. In the calling functions we do fall back to smaller buffers or alternative implementations. So the error warning should be generated in the calling code, if at all. I am in favour. Regards, Magnus ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] debug message
The proposed patch does not try to solve the general problem of errorhandling in OpenOCD. It simply wants to change the debug level at which this exception is reported to the user. Whats the problem ?? The attached patch *breaks* error reporting in other places. -- Ãyvind Harboe Embedded software and hardware consulting services http://www.zylin.com What other places ? ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [Patch] Use a debug base variable for Cortex A8
Dirk Behme wrote: Magnus Lundin wrote: For comments: This patch changes cortex_a8 to use a variable armv7a-debug_base instead of hardedcoded OMAP3530_DEBUG_BASE . This prepares for looking of debug_base from ROM Table scan (or from config file) At the moment no known functional changes. Tested-by: Dirk Behme dirk.be...@googlemail.com Used LEDblink test code for this. Best regards Dirk No furter comments. Commited. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH]cortex_a8_init_debug_access
For comments and testing: Add actual code to the previously empty : cortex_a8_init_debug_access() Remove details of common cortex8a debug initalisations from omap3_dbginit and replace with call to externally eposed cortex_a8 dbginit function. Best regards, Magnus ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] debug message
Øyvind Harboe wrote: Thank you for a *much* better analysis of the problem. (I checked a few sites and you missed a case where cfi.c is broken if you remove the warning, i.e. no error/warning is logged if you run out of working area, but otherwise a very productive post) I'm still convinced that the warning in target_alloc_working_area() is misplaced. With the current situation, a bunch of warning may be issued, but the software runs perfectly. I suggest that you create a new fn target_alloc_working_area_no_error() and invoke that for the try code and use LOG_ERROR() in target_alloc_working_area() . You can then delete all the superfluous LOG_ERROR() statements in code today that invokes target_alloc_working_area(). Like exceptions, the calling code can either pass up the exception, default case or catch(here the _no_error() is our equivalent) and handle the error. Like exceptions it's possible to catch an exception and ammend context information if necessary, most of the time just passing up an out of working space will be more than sufficient. (don't mention malloc() in this context, because we have swept all that error handling under the carpet for small allocations, here C++ exceptions would have made the code robust...) My head spins, do you really propose that we should have to functions doing exactly the same functionality, the only difference being how a failure is LOGGED ? How about the discussion about tetstable code paths. I know you have opinions about the error handling and I can partly agree. But this is not the way to fix it. If the cfi.c does not recognise an error return from the allocation then it is BROKEN with or without reporting the failure as an error event or a debug log event. This is a problem, but the original patch proposal is still correct. If Rolf like to fix the problems in the calling code then that is very velcome, but do we really require every patch subission that fixes a problem to also fix all problems in calling code ? We have not swept all error handling under the carpet. The case we are discussing is really reporting the failure. And my argument, and as far as I can understand, Rolfs also, is that the calling code should handle this reported problem. There is no no need for try/catch mechanisms, just read and respect the return code ! Best regards Magnus ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] svn 1825 breaks arm1136 burst mode
Øyvind Harboe wrote: On Tue, Sep 15, 2009 at 6:18 AM, michal smulski michal.smul...@ooma.com wrote: I noticed that something was not right with my svn repo after doing various up-rev's and down-rev's and decided to start fresh. It turns out that last 'memwrite burst' working is actually rev 1824 and the failing one is rev 1825 and the offending change is somewhere in ft2232.c file (change r1814 - r1825). I checked out two svn branches from fresh 'r1824' and 'r1825.' The first was still passes the memwrite test and the other one does not. It would explain why you cannot reproduce it on your jtag. Do you have access to ft* based JTAG hardware. Perhaps somebody else on this list can confirm this? Could you review the r1825 changes and point in the right direction to debug this problem? I attached a diffs (via svn diff and diff commands). First of all *great* find! But ouch This is going to be a tough one. Committing huge changes like this in a single commit when it's possible to break it apart is a faux pas, this being an excellent example of why. :-( Well, not really, some changes are major changes. This is, apart from some formatting changes, the switch from long tms sequences to short tms sequences ptch. It is not possible to switch only part of the ft2232.c to using the new tms sequence tables, and the support functions would never be called and tested if commited in an earlier patch. So this seems to a short tms sequence issue. Does the same problems appear when switching to the short tms sequence in the jlink code. So anyone with a jlink and an arm1136 ? It is also possible to use the old, long, tms sequences by issuing the tms_sequence long command and check if this helps. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [Patch] Use a debug base variable for Cortex A8
For comments: This patch changes cortex_a8 to use a variable armv7a-debug_base instead of hardedcoded OMAP3530_DEBUG_BASE . This prepares for looking of debug_base from ROM Table scan (or from config file) At the moment no known functional changes. Best regards, Magnus ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] More CortexA8 debug register definitions
More CortexA8 debug register definitions. Commited. Index: src/target/cortex_a8.h === --- src/target/cortex_a8.h (revision 2700) +++ src/target/cortex_a8.h (working copy) @@ -43,6 +43,7 @@ #define CPUDBG_DIDR 0x000 #define CPUDBG_WFAR 0x018 #define CPUDBG_VCR 0x01C +#define CPUDBG_ECR 0x024 #define CPUDBG_DSCCR 0x028 #define CPUDBG_DTRRX 0x080 #define CPUDBG_ITR 0x084 @@ -63,6 +64,9 @@ #define CPUDBG_CPUID 0xD00 #define CPUDBG_CTYPR 0xD04 #define CPUDBG_TTYPR 0xD0C +#define CPUDBG_LOCKACCESS 0xFB0 +#define CPUDBG_LOCKSTATUS 0xFB4 +#define CPUDBG_AUTHSTATUS 0xFB8 #define BRP_NORMAL 0 #define BRP_CONTEXT 1 Best regard. Magnus ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 1, 2] More fixes for Thumb state debugging
No furter comments received. Commited. Best regards, Magnus Magnus Lundin wrote: Here are two very small patches. The first one fixes the reporting of instruction state. The second one makes sure the processor stays in Thumb state when restoring the PC. After this it is possible to single step Thumb code. Best regards, Magnus ___ 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] Improved handling of Thumb state for Cortex_A8
Hello, If there are no known regressions then perhaps this patch should be commited ? http://lists.berlios.de/pipermail/openocd-development/2009-September/010335.html There are more thumb handling stuff to be fixed so I think this should go first. Regards, Magnus ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Cortex-A8, Introduction
Hello list. For those of you who has not yet had the time to read all the TRM's covering Cortex-A8 and ARM ADIv5, I have started to write up an easy introduction to the debug components in a Cortex-A8 system. This is not intended to replace the TRM's but to help the casual reader gain an understanding of the components involved and how they interact. Hopefully this can also make it easier to understand the Cortex-A8 and ARM-ADI-v5 code in OpenOCD. http://arttools.blogspot.com/2009/09/debugging-on-cortex-a8-system.html Best regards, Magnus ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH][Cortex_A8] Enable-halt-debug-mode-for-cortex_a8.patch
Øyvind Harboe wrote: On Fri, Sep 4, 2009 at 10:30 AM, David Brownelldavi...@pacbell.net wrote: On Friday 04 September 2009, Matt Hsu wrote: retval = mem_ap_write_atomic_u32(swjdp, OMAP3530_DEBUG_BASE + CPUDBG_DRCR, 0x1); Why are you still discarding the error check here That's an obvious bug ... There are probably 100x places in the cortex_m3/a8.c that do not check the return value from mem_ap_read_atomic_u32()... What makes this place different? I would have wanted ALL of the return values to be propagated. This is one of the *great* things about exception handling. You have to go out of your way not to add error handling... It is even worse. The actual error detection is done in swjdp_transaction_endcheck(), and only JTAG communication errors are reported back through the return value. Sticky overruns and sticky errors are logged but they return ERROR_OK. And how should errors be handled and where ? So the whole error handling scheme needs a deep rethink before it is worth the effort of picking at all the little pieces. Regards, Magnus ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH][Cortex_A8] Fix the hardware single-step logic
Matt Hsu wrote: Hi all, This series patches fix the hardware single-step logic mainly. With these patches, you can do the step operation on the telnet session. Also, the programming breakpoints works as well. Cheers, Matt ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development Hi Matt, It makes me very happy to se active work with this code. The bit offset handling is very nice, patches 0001 and 0003. The second patch is more worth thinking about. For the Omap353x we set the DSCR[DSCR_HALT_DBG_MODE] bit in the setup script, and we then assume that the running application does not actively play with the debug settings. This can of course be discussed. Anyway, if we want to set this bit every time we call halt, a small extra cost in USB return trips, then I think the logical place is before we try to halt the core by writing to bit 0 of DRCR. I cannot really se how this patch modifies single stepping or breakpoint handling, can you describe that. It would be helpful with some descriptions of how and when problems occured that you are solving with your patches. Best regards, Magnus ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Improved handling of Thumb state for Cortex_A8
Hello all Cortex_A8 fans !
Please test the following patch that hopefully corrects some insane
errors in Thumb state handling.
(Yes I wrote it myself, but it seems UBoot for BeagleBoard does not use
Thumb Mode)
Best regards
Magnus
Index: src/target/cortex_a8.c
===
--- src/target/cortex_a8.c (revision 2663)
+++ src/target/cortex_a8.c (working copy)
@@ -451,7 +458,6 @@
/* get pointers to arch-specific information */
armv4_5_common_t *armv4_5 = target-arch_info;
armv7a_common_t *armv7a = armv4_5-arch_info;
- cortex_a8_common_t *cortex_a8 = armv7a-arch_info;
swjdp_common_t *swjdp = armv7a-swjdp_info;
// breakpoint_t *breakpoint = NULL;
@@ -499,7 +505,7 @@
/* Make sure that the Armv7 gdb thumb fixups does not
* kill the return address
*/
- if (!(cortex_a8-cpudbg_dscr (1 5)))
+ if (armv7a-core_state == ARMV7A_STATE_ARM)
{
resume_pc = 0xFFFC;
}
@@ -631,7 +636,8 @@
dap_ap_select(swjdp, swjdp_debugap);
LOG_DEBUG(cpsr: %8.8 PRIx32, cpsr);
- armv4_5-core_mode = cpsr 0x3F;
+ armv4_5-core_mode = cpsr 0x1F;
+ armv7a-core_state = (cpsr 0x20)?ARMV7A_STATE_THUMB:ARMV7A_STATE_ARM;
for (i = 0; i = ARM_PC; i++)
{
@@ -650,8 +656,7 @@
ARMV7A_CORE_REG_MODE(armv4_5-core_cache, armv4_5-core_mode, 16).dirty = 0;
/* Fixup PC Resume Address */
- /* TODO Her we should use arch-core_state */
- if (cortex_a8-cpudbg_dscr (1 5))
+ if (armv7a-core_state == ARMV7A_STATE_THUMB)
{
// T bit set for Thumb or ThumbEE state
regfile[ARM_PC] -= 4;
@@ -736,7 +741,6 @@
/* get pointers to arch-specific information */
armv4_5_common_t *armv4_5 = target-arch_info;
armv7a_common_t *armv7a = armv4_5-arch_info;
- cortex_a8_common_t *cortex_a8 = armv7a-arch_info;
breakpoint_t *breakpoint = NULL;
breakpoint_t stepbreakpoint;
@@ -778,7 +782,7 @@
/* Setup single step breakpoint */
stepbreakpoint.address = address;
- stepbreakpoint.length = (cortex_a8-cpudbg_dscr (1 5)) ? 2 : 4;
+ stepbreakpoint.length = (armv7a-core_state == ARMV7A_STATE_THUMB) ? 2 : 4;
stepbreakpoint.type = BKPT_HARD;
stepbreakpoint.set = 0;
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Need help: nothing works
Alain Mouette wrote: Hi, I just changed my Cortex-M3 from LS3S6965 to ML3S6611 and it stopped working :( When I start openocd (0.2, Linux, FTD2232) I get: Open On-Chip Debugger 0.2.0 (2009-07-15-14:00) Release [...] 500 kHz jtag_nsrst_delay: 100 jtag_ntrst_delay: 100 Info : device: 4 Info : deviceID: 67354056 Info : SerialNumber: TLRYVQOW A Info : Description: Turtelizer JTAG/RS232 Adapter A Info : JTAG tap: lm3s6965.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3) Info : JTAG Tap/device matched = I checked and the device code is exactly the same for both chips! Using telnet, if I display memory I get: mdw 0 8 0x: 2010 0021 000d 0029 0045 0045 0045 mdw 2000 8 Maybe it should be (hexadecimal) mdw 0x2000 8 Sticky errors is almost always trying to acces nonéxisting memory. Best regards, Magnus ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Cortex-A8 problems
Matt Hsu wrote: So in the OMAP initialisation script we have the line # set DBGEN signal mww 0x5401d030 0x2000 Hi Magnus, It seems that the debug address space is remapped from 0xD401 to 0x5401. But I could not find out any sections mentioned this remapping. Also, I checked the global memory space mapping in omap35x_TRM. The corresponding address of 0x5401 is for MPU emulation. I could not find out why this remapping is needed. Anything do I miss? The ap debug base address is 0x8000, you can se this in the romtable information for DAP #1 with dap inf 1. Here you can also se the offsets from the debug base address to the debug component adresses. To get the memory address in the MEMAP memory map you must add base+offset: ( the 2 LSB bits are status and not part of the address) 0x8000+0xD401 = 0x5401 ( unsigned 32 integer addresses ) So the values given in OMAP35x TRM table 1.52: Debugger Address Space are not the memory bus addresses but the offsets from the romtable base address. More information can be found in the ARM Debug Interface v5 Architecture Specification, ARM IHI 0031A, sec. 8.1.3 and 14.6 Best regards Magnus ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] FW: AT91SAM9G20-EK.cfg
3) One feature that I think may make sense to add at some point in the future to the main software is support for label/value associations that allow hexadecimal register values to be associated with more legible and understandable names. Looking at mww 0x3ec2 0x2 in a configuration script is more likely to introduce mistakes during reuse, then say mww some_xyz_register 0x2 where the name of the register clues you into what it does or at least where to find it in the datasheet. Agreed. I wonder if this is already possible now? set xyz_register 0x3ec2 set abc_magic_value 0x12341234 ... mww $xyz_register $abc_magic_value #or mww $xyz_register 0x02 Best regards, Magnus ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Cortex-A8 problems
Harald Welte wrote: Hi Magnus, On Mon, Aug 31, 2009 at 05:36:11PM +0200, Magnus Lundin wrote: dap_ap_select(swjdp, 1); before the two lines dap_ap_read_reg_u32(swjdp, 0xFC, idreg); dap_ap_read_reg_u32(swjdp, 0xF8, romaddr); in ahbap_debugport_init() Can you place the call to dap_ap_select(swjdp, 1) in cortex_a8_examine() instead, just after the call to ahbap_debugport_init() ? I see. It's somewhat strange if ARM has all those detailed and fairly extensive specifications (and the romtable to discover the debugging capabilities), but then no standard way how DBGEN can be set? That's weird. It is supposed to be an input to the Cortex_A8 core, so the chip manufacturer can control debug access without modifying the A8 core. So have you looked at the OMAP init script, it is something like this: dap apsel 1 mww 0x54011FB0 0xC5ACCE55 4 # Clear Sticky Power Down status Bit to enable access to the registers in the Core Power Domain mdw 0x54011314 # set DBGEN signal mww 0x5401d030 0x2000 # enable execute instruction and halting debug mode mww 0x54011088 0x6000 # DAP AP 0 is connected to the L3 interconnect and memory bus dap apsel 0 For you I think this might become: dap apsel 1 # Unlock the Lock Access to enable writes to debug registers mww 0x80005FB0 0xC5ACCE55 # Clear Sticky Power Down status Bit to enable access to the registers in the Core Power Domain # Se note on PRSR, C_A8 TRM 12.4.21 mdw 0x80005314 # enable execute instruction and halting debug mode mww 0x80005088 0x6000 # DAP AP 0 is connected to the L3 interconnect and memory bus dap apsel 0 Best regards, Magnus ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Cortex-A8 problems
Beautiful work. Harald Welte wrote: Hi All! Throughout the last week or so, I've been trying to get OpenOCD to work on a new (not public yet) Cortex-A8 based SoC. Right now I feel a bit stuck, despite having read the CoreSight docs from ARM as well as the Cortex-A8 reference manual chapter 12... The first thing I obviously did was to redefine OMAP3530_DEBUG_BASE On the SoC that I'm working on, the base address (on the APB) for the Cortex-A8 is 0x80005000. The ROMTABLE starts at 0x8000 and the entries are also valid, I can decode them properly using 'dap info'. DAPSEL 0 is the AHB, where DAPSEL1 is the APB, like on the OMAP. The only thing special about the Coresight implementation on this SoC is that the 0x8000 / 0x base address is only valid on the APB. The same addresses are mapped to 0xE0D0 on the AHB. However, OpenOCD does not even get to the point of creating the telnet socket for the command interface. In order to get the code to do anything at all, I had to manually insert a dap_ap_select(swjdp, 1); before the two lines dap_ap_read_reg_u32(swjdp, 0xFC, idreg); dap_ap_read_reg_u32(swjdp, 0xF8, romaddr); in ahbap_debugport_init() What happens when you do dap info 0 from the telnet interface ? After that change was made, I can successfully get OpenOCD started, telnet in and then use comands like dap info, dap apsel, etc. However, the Cortex-A8 part is still not working. cortex_a8_examine() works great, i.e. it reads the CPUID, CTYPR, TTYPR and DIDR and they all provide reasonable results. However, as soon as the code enters cortex_a8_poll() and calls retval = mem_ap_read_atomic_u32(swjdp, OMAP3530_DEBUG_BASE + CPUDBG_DSCR, dscr); the implicit swjdp_transaction_endcheck(). Specifically, SSTICKYORUN is set during the first DP_CTRL_STAT read. The LOG_DEBUG(swjdp: status 0x% PRIx32 , ctrlstat); tells me that the clear of the STICKY bit was successful. However, during the next cortex_a8_poll() timer, the same error happens again and again. However, I can already access system memory using mdr from the telnet interface. Just anything regarding the A8 does not work. By manually peeking around in the AHB address space, I can also read the coresight memory range (on 0xE0D0), including some of the A8 registers, including the 0xE0D05000 CPUDBG_DIDR or 0xE0D05D00 CPUDBG_CPUID register. However, if I try to read some other registers such as CPUDBG_DRCR or CPUDBG_WFAR, I will again run into transaction problems. I'm not sure if this is now expected, since I'm now using the AHB to access those registers. Does anyone have a clue how to further debug this problem? By now I unvoluntarily know way more about coresight than I ever wanted to know, so I'm quite happy to receive high-level ideas which I can then try and/or implement. And yes, if I get this fixed I'll obviously contribute the code as well as the .tcl files. Thanks in advance, So you can read some of the registers, can you read CPUDBG_DSCR ? and its value is? Your problems are probably related to the DBGEN signal, this is an input to the Cortex_A8 core and controls debug access. There is some documentation of this in the Cortex_A8 TRM, but no way to controling it from the debug registers defined by ARM. On the Omap3530 this signal can be set by bit 13 in address 0x5401d030 . This can be found in section 25.6.4 of the OMAP353x TRM but they call the signal DBGEM which is probably a mistake. So in the OMAP initialisation script we have the line # set DBGEN signal mww 0x5401d030 0x2000 Hope this can give some help. Best regards Magnus ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] Improving Cortex-A8 support...
Holger Freyther wrote: Hey, today Matt Hsu and me sat together to look into why OpenOCD does not work on the beagle board. We have found and fixed some issues with the code, it should make it more robust and we have fixed the root cause for us. cortex_a8_dap_read_coreregister_u32 only returned 0x0 for the registers, this was due the instruction written to the ITR register was not executed. We will have to enable bit 13 of DSCR to enable the execution of ITR. The attached patch series fixes the problem for me and matt. The patches were done in teamwork.. regards z. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development This is nice work but I have some points that need careful consideration and testing: The usual way for OpenOCD targets to check if a PROCESSOR_HALTED flag has been set is not to do it in the halt command but rather in the poll command. This in general improves performance when using long roundtrip interfaces like USB. This does not affect stability but only moves the actual run state detection, and affect the halt and resume commands. Some other checks lite testing for DTRRXfull and wait for previous instruction patch definetly improves stability but they are performance killer especially for debug work like single stepping. Perhaps we need a debugmode=FAST / debugmode = STABLE flag to control speed vs stability. When developing the cortex_a8 code I had the enable ITR for code execution in the init script. In general we try put put this kind of target initialisations in TCL setup/reset scripts. The relevant part of my omap3_dbginit scrip is: # DAP AP 1 is connected to the L4 EMU, emulation, trace and debug modules dap apsel 1 mww 0x54011FB0 0xC5ACCE55 4 # Clear Sticky Power Down status Bit to enable access to the registers in the Core Power Domain mdw 0x54011314 # set DBGEN signal mww 0x5401d030 0x2000 # enable execute instruction and halting debug mode mww 0x54011088 0x6000 # DAP AP 0 is connected to the L3 interconnect and memory bus dap apsel 0 I hope this can be of use. Best regards, Magnus ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] Improving Cortex-A8 support...
Holger Freyther wrote: On Friday 28 August 2009 19:28:50 Magnus Lundin wrote: The usual way for OpenOCD targets to check if a PROCESSOR_HALTED flag has been set is not to do it in the halt command but rather in the poll command. This in general improves performance when using long roundtrip interfaces like USB. Okay, I was not sure about the state transitions and such, I can remove that part and plant some asserts in the other paths to make sure they are not called before the core is paused. This does not affect stability but only moves the actual run state detection, and affect the halt and resume commands. Some other checks lite testing for DTRRXfull and wait for previous instruction patch definetly improves stability but they are performance killer especially for debug work like single stepping. I sincerely disagree here. These bits directly come out of the Cortex A8 Technical Reference Manual and not following them is not making things fast but it makes them unreliable. In other words, why would ever want to read half of the result? To speed up debugging !! I did read the Cortex_A8 TRM when I first started to work on that code :), and I also tested if things were reasonably stable without the checks. In many situations it is not necessary to check those flag bits and instead rely on bus/instruction timing. The core is inhalted debug and only exectuing opcodes that we have pushed to it for single instruction execution. So we can make educated guesses about the time it takes before the results will be available or the preceding instruction finishes ecxecution. This timing is related to the swjdp-memaccess_tck field that was added to all cortex targets. So it is not unresonable to let crazy people make their own choise to trust fate and speed up dubgging by not always checking theese flags. Thus different debug modes SAFE/FAST , but I do agree there should a safe mode and the original code did not have that. Perhaps we need a debugmode=FAST / debugmode = STABLE flag to control speed vs stability. When developing the cortex_a8 code I had the enable ITR for code execution in the init script. In general we try put put this kind of target initialisations in TCL setup/reset scripts. Ah great, from my understanding the code running on the core can access the L3 and L4 registers as well. So in theory and practice the code running on the core has changed the ITR flag. This is why I put it into the debug_entry right after saving the old DSCR to make sure it is enabled. maybe this clear things up, I will need to single step through linux to see when stuff breaks in OpenOCD... my assumption is enabling the MMU but I will find this out next week. z, The really important thing now is that there are several people working on and testing these things. I am not saying I am right but I do have some experince whith this code and I hope my comments can help in directing further work. Thank you for Your (several of you :) ) work with this code. Best regards Magnus ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] Improving Cortex-A8 support...
Sorry for double responses but it is getting late and my brain is going to sleep on its own. Holger Freyther wrote: I sincerely disagree here. These bits directly come out of the Cortex A8 Technical Reference Manual and not following them is not making things fast but it makes them unreliable. Oh yes, it does make some things fast !! Not checking these flags does have a huge impact on single stepping, this is the type of activity mostly using core opcode execution and thus is affected by waiting for these flags. Doing the checks increases the number of USB roundtrips by 2 to 3 times and this is the absolutly most important individual speed factor when using FT2232 based JTAG interfaces. For loading data to RAM there is no difference. In other words, why would ever want to read half of the result? /Magnus ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Who is using a teletype terminal for code development ?
Hello list. Maybe this is my fault that I have not paid enogh attention to some of the style discussions. But I have stopped to regularily print out code before working on it, and my screen can easily support 1000-1200 pixel wide edit windows. That is 120-140 characters before line wrapping. So why this totally idiotic requirement on 72-80 columns My punched card writer is brokens so it does not really care any longer. And IMHO this breaking up of single commands that fit into 120-140 into a lot of shorter lines does neither improve readibility or stability or code quality. And all those formatting rewrites does make code comprisons very difficult. I would like to se a situation where code quality is not equivalent to whitespace handling and code is routinely truncated to 80 char columns ( we did that in the 80/90ties because equipment did not support any longer lines) , but actual analysis of code structure and performance. That might motivate me to once more take a more active part in OpenOCD development. Happy hacking. Magnus ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] Improving Cortex-A8 support...
Holger Freyther wrote: On Thursday 27 August 2009 16:43:34 Dirk Behme wrote: Holger Freyther wrote: Okay, turns out that I'm not able to omap3_dbginit scan once the linux kernel is running and when linux is starts the poll will start to fail. Does this sound familiar? Do you guys have any ideas? Hmm, there is some rumor that Linux debugging isn't possible as long as we don't have proper Cortex A8 cache and MMU support. If I remember correctly, Magnus always talked about with this only U-Boot debugging is possible. Sorry if I missed something or if I'm completely wrong here ;) Would you know where to start to look? I have not looked at the CoreSight DAP- Lite documentation and such and I assume that this serial wire jtag debug port (swjdap) would just work? Or do you mean that the OMAP3_BASEADDR is now different with the MMU on? Regarding caches, in the Cortex-A8 debug entry sequence the code is executing a barrier (we don't).. z. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development My observations was that if we connect OpenOcd (omap3_dbginit) while UBoot is running and after that start Linux then we can do some debugging. I think we will get problems with distrbing timer interrups, but at least sometimes it was possible to halt and resume a Linux terminal session. After Linux has started up I was never able to get a JTAG connection, I looked for changes in configuration registers that could explain this but could not find anything. The MMU situation, AFIK, is that all register addresses are still OK (physical addresses) since the DAP-MEMAP accesses them directly over the bus, but all register and memory address that are used by the CPU must be translated between virtual and physical. Best regards, Magnus ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] BeagleBoard and Flyswatter
David Brownell wrote: On Tuesday 25 August 2009, Matt Hsu wrote: The problem is I would like to issue commands such as reset halt, bp, resume. The source code shown their implementation are NULL. So I'm curious why coretex_a8 does not have these support? Because nobody submitted patches implementing them yet.. Join in! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development That is weird ! The halt, step, resume and bp handling should be there. The patches and files that was submitted to the list 07/08/2009 (with copies to Dirk) contains cortex_a8.c/h with working halt/step/resume/bp implementations. Of course there might be bugs but they were tested on my Flyswatter/Begle system. I also had no special problems with invalid mode value encountered when debugging UBoot or code loaded into RAM after starting up the Beagleboard to UBoot. No reset functions were implemented. My suggestion was to make a complete replacement of the old cortex_a8 files with the new ones, commit this, test and only then then do the cleanups and larger rewrites. The old code never worked and is not worth preserving, not even as a baseline. Happy hacking, Magnus ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD 0.2.0 : Olimex ARM-USB-TINY - unable to find driver software
Freddie Chopin wrote: Rohit Chandel pisze: Is there any quick test to find out that openocd is installed correctly? use it. That is funny, and true. But the OpenOcd application is almost always installed correctly and from a users point of view there are lots of things that can go wrong with OpenOCD even if they are not in the strictes sence OpenOcd problems: * Drivers for the JTAG interface must be correctly installed and correspond to the configuration of the OpenOCD installation. * Eclipse must be installed with correct scripts and addons to relibly make gdb talk to OpenOCD * The board/target configuratin scripts must be properly setup. * The application to run on the target and the build configurations must be sound For many users, failure at any of these steps will be interpreted as OpenOCD is not correctly installed because OpenOCD does not solve their problems. It is up to the OpenOCD community to handle this complexity, and if you want OpenOCD to thriwe and grow then this is not an OpenOCD installation problem is NOT the answer. /M ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Trying to bring Magnus A8 work up to SVNHEAD
On Wednesday 15 July 2009, Øyvind Harboe wrote: I've made an attempt at bringing Magnus Cortex A8 work up to SVN HEAD. It builds and I hope I resolved the few conflicts correctly. Not tested on Cortex M3 or A8. This splits the remaining work in two parts. It needs sanity testing on A8 before merging. First part creates armv7m.c and the second has the cortex_a8.c code. Changes are primarily style cleanups, plus sorting Magnus' somewhat rambling comments into patch descriptions. - Dave Other than adding svn props for the new files looks ok. For info monitor mode is also available on all arm7/9/11 and cortex -S cores. Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development Many arm cores have a debug monitor, entered by a debug exception. The Cortex-A8 Monitor mode is not a debug state, it is an operating mode with ist own banked register r13 and r14. I have not seen this on any other ARM family, it is not an operation mode in the ARMv4/5 core model. From the Cortex-A8 TRM (sec 2-12): There are eight modes of operation: User mode is the usual ARM program execution state, and is used for executing most application programs Fast interrupt (FIQ) mode is used for handling fast interrupts Interrupt (IRQ) mode is used for general-purpose interrupt handling Supervisor mode is a protected mode for the OS Abort mode is entered after a data abort or prefetch abort System mode is a privileged user mode for the OS Undefined mode is entered when an Undefined Instruction exception occurs Monitor mode is a Secure mode for the Security Extensions Secure Monitor c Best regards Magnus ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Trying to bring Magnus A8 work up to SVN HEAD
Should I commit it if there are no regressions? -- Ãyvind Harboe Embedded software and hardware consulting services http://www.zylin.com If Cortex-M3 is not not broken then I think it should be commited. Regards Magnus ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Trying to bring Magnus A8 work up to SVN HEAD
On Wed, 2009-07-15 at 09:30 -0700, David Brownell wrote: On Wednesday 15 July 2009, Øyvind Harboe wrote: It builds and I hope I resolved the few conflicts correctly. Not tested on Cortex M3 or A8. Hmm, could you maybe split this into two patches, more like what Magnus did? #1 to move the DAP stuff from V7M support to ADIv5. The other adding lots of A8 stuff. That would make it easier to review, also make the revision history more comprehensible. Here is a longer list of issues: - Split into more discrete changes: - One change per patch; his original post was better in this. - One patch per post; the original post feel short here. - Include commit messages that describe the changes in each patch. - Fix minor whitespace style problems: - Missing spaces before/after operator - Wrap long lines at less than 80 columns. - Remove all dead code: - Commented code and #if 0 blocks show the code is not finished. - Extended the documentation (in further patches from the series): - New commands were added: document their syntax and usage - Add a NEWS blurb; update TODO. - There may be other information to add about Cortex A8. - Patch does not show svn:eol-style native properties. I think Magnus needs to polish, split, and resubmit this patch (once he gets back from his vacation). First, it's his code. More importantly, every developer needs to learn how to produce, update, and revise their own patches in order to meet high standards of quality. This holds for any non-trivial open source community, not just OpenOCD. I loath the idea of asking others to fix code of an active developer. If I were to finish these patches, I would end up taking over enough momentum of the code to manage its forward motion. I expect anyone else with such initiative to feel a similar entitlement to do so, and such efforts would mean that it ceases to be his patches to manage. To me, this sounds like a rude thing to do, since he did not abandon those bits to the community's care. While we have provided the community with a patch that will apply against the trunk HEAD, that should be sufficient to enable him to finish the rest of the work. In the meantime, this patch should be used for testing only, and not committed without more work. However, I agree it may get better testing by being split up again, similar to how they were initially presented. Cheers, Zach Hi list, I will not do any more work on these patches in the near future. I know that there is a lot of work to be done before they are up to standard, but I have been asked to submit the work I have done so far, anyway. So I give this to the community to improve. Hopefully the experiments I have done with the Beagleboard and my analysis of how Cortex-A8 relates to other ARM subsystems in OpenOCD can be useful as a basis for a future full and clean Cortex-A8 subsystem. So I have full understanding if somebody does a major rework or if somebody decides to write another implementation. But the patches as they stand actually makes it possible to do basic debugging of Cortex-A8 systems (Beagleboard) and some members of the community have expressed interest in this well aware of the limitations in the present code. I hope this project has not lost the facility to work on and collectively improve incomplete subsystems. So as an old teacher I can only say that I wish the Cortex-A8 code all future success, in whatever form it will transform into after meeting with the community. This is not abandoning, it is setting free to allow future growth. Have a nice summer. Best regards Magnus ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] Identify state of a running CM3 target on startup
Thc cortex_m3_poll function does not identify that a target is running
unless we transition from RESET.
This patch correctly identifies a running target.
Regards
Magnus
Index: src/target/cortex_m3.c
===
--- src/target/cortex_m3.c (revision 2503)
+++ src/target/cortex_m3.c (working copy)
@@ -512,17 +512,24 @@
}
}
- /*
+#if 0
if (cortex_m3-dcb_dhcsr S_SLEEP)
+ {
target-state = TARGET_SLEEP;
- */
-
-#if 0
- /* Read Debug Fault Status Register, added to figure out the lockup when running flashtest.script */
- mem_ap_read_atomic_u32(swjdp, NVIC_DFSR, cortex_m3-nvic_dfsr);
- LOG_DEBUG(dcb_dhcsr 0x%x, nvic_dfsr 0x%x, target-state: %s, cortex_m3-dcb_dhcsr, cortex_m3-nvic_dfsr, target_state_name(target));
+ return ERROR_OK;
+ }
#endif
+ if (target-state == TARGET_UNKNOWN)
+ {
+ /* check if processor is retiring instructions */
+ if (cortex_m3-dcb_dhcsr S_RETIRE_ST)
+ {
+ target-state = TARGET_RUNNING;
+ return ERROR_OK;
+ }
+ }
+
return ERROR_OK;
}
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD + beagle
Wookey skrev: +++ Sergey Lapin [2009-07-06 19:02 +0400]: Hi, all! Is there any news regarding support of BeagleBoard in OpenOCD? Last time I checked, there was none, I'm interested to help, so I want to know the status and what can I do. There is a config file for it in SVN, so I assume there is some... Wookey Hi list, I have done some work and it works as far as - CortexA8 can be halted, stepped and resumed if MMU is inactive. - Data can be up and downloaded to RAM - We can read and modify memory mapped registers - Breakpoints work, but not yet watchpoints, not problems here, it is simply not done yet. So uBoot and standalone programs can be debugged, and it should be possible to write some flash writing code. Debugging Linux on BeagleBoard does not work. I have not had time to keep up with the latest changes in trunk, so there will be some to clean up the code, and I will not have time for more work for the near future. So I will write up some status comments and publish what I have done, as is, before the end of the week. I think all Cortex-A8 materials should be removed from the published 0.2.0 since it does not work, and then add it after 0.2.0 has been cut, with time create some good working code. Best regards Magnus ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD + beagle
Sergey Lapin skrev: On Mon, Jul 6, 2009 at 7:43 PM, Magnus Lundinlun...@mlu.mine.nu wrote: Wookey skrev: +++ Sergey Lapin [2009-07-06 19:02 +0400]: Hi, all! Is there any news regarding support of BeagleBoard in OpenOCD? Last time I checked, there was none, I'm interested to help, so I want to know the status and what can I do. There is a config file for it in SVN, so I assume there is some... Wookey Hi list, I have done some work and it works as far as - CortexA8 can be halted, stepped and resumed if MMU is inactive. - Data can be up and downloaded to RAM - We can read and modify memory mapped registers - Breakpoints work, but not yet watchpoints, not problems here, it is simply not done yet. So uBoot and standalone programs can be debugged, and it should be possible to write some flash writing code. Debugging Linux on BeagleBoard does not work. Which dongle were you using to debug on Beagle? TinCanTools Flyswatter with the BeagleBoard adapter gives both JTAG and serial port monitor. I have not had time to keep up with the latest changes in trunk, so there will be some to clean up the code, and I will not have time for more work for the near future. So I will write up some status comments and publish what I have done, as is, before the end of the week. Thanks a lot, I really can't wait to see your code! Thanks a lot for doing this! S. M. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Summer coding project proposal
Simple project for a CS student. A wrapper with a libftdi interface calling libftd2xx, as a project using a LGPL license So any user can take their binary copy of OpenOCD linked against libftdi and simply replace the libftdi dll file, no need to play with system files or drivers. Is such a library illegal ? Who would have standing to complain ? - FTDI ? no their libray and driver is called in accordance with their documentation. - OpenOCD ? nobody has touched a single line of OpenOCD code - Copyright holders of libftdi, Intra2Net AG ? no, libftdi is LGPL and the new library would only use the header file in accordance with LGPL section 3. Would it work? with a bit of tweaking I would think so. Is this a blatant attempt just to work around the problems with OpenOCD, GPL and libftd2xx ? What do I know ? Maybe yes, but that does not make it illegal. Regards Magnus ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD, the GPL, and FTD2XX
Zach Welch wrote: On Tue, 2009-06-23 at 20:20 +0200, Freddie Chopin wrote: [snip] Why do you consider it OK to ignore a license just because it inconveniences you? Do you hold the same view regarding things you create? Why do you consider it OK to overinterpret the license just because it inconveniences you? In things I create I take the pragmatic view - when something is given for free (like the ftd2xx.dll library) than it is meant to be used, for free - I'm not creating artificial problems that would prevent me to use that something. [snip] Why do you consider it OK to ignore what I and other contributors are saying about the license? Why do you feel it necessary to disrespect our copyright claims? If we interpret it thusly, why do you think that your interpretation should be considered more valid than ours view? What if I told you that my interpretation is based in part on having paid an attorney to counsel me in such nuances? Would that matter? You are being disrespectful to contributors that have made this decision; it is theirs to make and theirs alone. In that way, there is no doubt that you _are_ creating problems by beating this dead horse. What will it take to get you and others to drop this issue? Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development I am a developer, and I have contritubted fair amount of original code to OpenOCD. I did write the CortexM3 stuff, and the SAM7S flash drivers, and was among the first developers not connected to Dominics original thesis work to join the project. Zach does not speak for me. As far as I can see he and David are actively against any exception, I am not!!! Trying to find a solution that is formally acceptable to GPL, but seen as a way to work around the license problem, is perfectly OK. If it is legal then it is legal, even if it is against the spirit of GPL according to the hardliners. Hardline legalisms work both ways. If it is in the spirit of OpenOCD as I knew it then so much better. Regards Magnus ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD, the GPL, and FTD2XX
John Devereux wrote: Anders Montonen anders.monto...@iki.fi writes: On Jun 23, 2009, at 21:20, Freddie Chopin wrote: Anders Montonen pisze: Right, but section four says You may not copy, modify, sublicense, *or* distribute the Program (emphasis added). If it just concerned distribution then there would be no room for interpretation. Still I don't see that as a distribution. The patch by itself is WORTHLESS it needs an executable, moreover - a RIGHT executable. It's not about distribution. The patched binary obviously doesn't satisfy the terms of the GPL, so by my interpretation you no longer have the license to use it. This renders the patch pointless. I may have lost track of the argument here, but surely the GPL is all about distribution? Are you claiming it also restricts use? I don't see anything in the GPL faq that forbids modifying a GPL'ed program, provided it is not distributed. You are right about use, the problem is that the distributor of a binary patch is potentially not in compliance with GPL This is because the patch contains a fragment of the original code linking to the offending library. Still I maintain that champions of open development tools should work towards larger community use, and actively work to make more people use their tools, instead of creating unneccessary problems for the community. /M ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] License
Øyvind Harboe wrote: Could you explain a bit about your thoughts on closed source target and interface drivers together with OpenOCD? I can imagine that a lot of CPU vendors would love the ability to provide a closed source plugin that talks to their CPU. Similarly I believe that there are hardware debuggers that would like to have their product specific code closed source. This is always a tradeoff/balance thing. The protocol to talk to MPSSE is well known/open (they do praise developers of open alternatives on thier web site) , their driver and dll are distributed without restrictions but not with source code. So it is not GPL but at the same time it does not put any restrictions on my code in OpenOCD. What is the situation with the ZY1000, I assume that all modifications to the OpenOCD source tree are public, but can you guarantee that the code running on the Zylin1000 does not link to anything that is nonopen and thus violates the GPL ? Regards Magnus ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] License
Øyvind Harboe wrote: On Tue, Jun 23, 2009 at 11:38 PM, Magnus Lundinlun...@mlu.mine.nu wrote: Ųyvind Harboe wrote: Could you explain a bit about your thoughts on closed source target and interface drivers together with OpenOCD? I can imagine that a lot of CPU vendors would love the ability to provide a closed source plugin that talks to their CPU. Similarly I believe that there are hardware debuggers that would like to have their product specific code closed source. This is always a tradeoff/balance thing. The protocol to talk to MPSSE is well known/open (they do praise developers of open alternatives on thier web site) , their driver and dll are distributed without restrictions but not with source code. So it is not GPL but at the same time it does not put any restrictions on my code in OpenOCD. I'm not overly concerned about the USB issue. There are technical solutions proposed and it will be resolved before long I believe. License change is a red herring w.r.t. that technical problem as far as I can understand. ?? So you are saying that there soon will be open USB solutions for FT2232 without performance loss and with reasonable work practice on windows hosts ?? Created by whom ? Zylin AS? zy1000 runs eCos which is GPL compatible. Jim Tcl was a problem, but I fixed that license. zy1000 runs openocd unmodified. Good enough. Is FTDI in any way competing with you ? /Magnus ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD, the GPL, and FTD2XX
David Brownell wrote: On Tuesday 23 June 2009, Magnus Lundin wrote: Zach does not speak for me. As far as I can see he and David are actively against any exception, I am not!!! I'm not against adding such an exception for the FTD2XX code. This is a VERY different tone from before, so you actually support an exception ?? However, I don't think it's practical to have one for a release that ships in the next couple weeks. And it may not be practical to have one at all, if there are any copyright holders who won't agree (or can't be contacted). The working solutions seems still to be far from working, we are still avating a magic touch, maybe from Zach ? You know, working and debugged code !! - Dave /M ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] License
Photo Leecher wrote: Where does it say that you cannot revoke an exception in a new version/revision? That doesn't make sense??? Sure But it only applies to new code since last release when other rights were granted. This is NOT a GPL problem, it applies anytime you give somebody a time limited licence to anything. And this goes for all FOSS licences. And all other valid licenses, open/free/commercial or whatever /M ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD, the GPL, and FTD2XX
Thomas A. Moulton wrote: On Tue, 2009-06-23 at 15:33 -0700, Rick Altherr wrote: The community as a whole can easily decide to remove your code, replace it, and relicense. The community can also choose to follow an alternate interpretation of the license that you may not agree with. Again, you have no rights to declare which interpretation must be followed. Your rights only extend to bring a court case to decide the claims. The community must reach a resolution and individual members don't have the rights to assert that theirs must be used. Rick, The term community and authors are not interchangeable. What you are suggesting is not a trivial task. And what is your position in this ? Author or community? And what is your opinion ? /M ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] License
David Brownell wrote: On Tuesday 23 June 2009, Magnus Lundin wrote: The protocol to talk to MPSSE is well known/open (they do praise developers of open alternatives on thier web site) , Though for the record ... the bitbang protocol for FT232 (not FT2232) is neither well-known nor open. If that were open, it would be possible to implement JTAG on other FTDI chips. Less efficiently, to be sure, but with easier 1.8V compatibility. - Dave I call BS. Do you know JTAG over FT232 ? Somer folks called you USB expert. The protocols available for FT232 are well published, it is not hard but unpleasant to implement JTAG on them, that is what interfaces like the Altera USB Blaster does. But JTAG over MPSSE is soo much nicer that nobody who has worked with this wants to go back to FT232 (without the extra 2), it is not a tecnical problem it is just a PITA. /M ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] FT2232 Windows - summary of options
Zach Welch wrote: On Sun, 2009-06-21 at 17:38 -0400, Duane Ellis wrote: zach Please DO NOT try to cheat the GPL license. You do not understand how zach far I am willing to take these matters, and I believe any form of binary zach distribution to be a violation: a DLL wrapper, a binary patch, anything! Let me ask this another way. I believe the question is some what moot, and was moot 4 years ago one OpenOCD was originally written. Basic thesis statement, and IANAL... But I can sound like one. If I am the original author of a body of work, I hold the original copyright and can license that body of work as I please, under the GPL with any exception that I please. Those that follow do not have the ability to further restrict, nor change that license. As the original copyright holder, I can choose to explicitly write an exception for a specific use case of the package (or fail to), however - if my personal actions effectively construct and demonstrate that use case - is valid and acceptable - then it is an unwritten exception. You cannot change my original intention, nor can you change that original license and/or any exception that may have been granted before you got involved. Argument. It is well know that Dominic Rath, is the original author of OpenOCD. By reviewing his original releases that I find in the SVN repository, I can't get back to Rev1, Rev 50 fails, Rev 75 works, By Dominic's on hand purposely created OpenOCD to support the ftd2xxx library on windows. As I understand (and Laurent or Dominic can confirm) Domenic worked with Laurent to help develop the ftd2xx driver (and library) based jtag key. Perhaps - I do not now - but I assume. Dominic and other developers of the package at the time actively participated and encouraged the package to be *USED*WITH* and in fact *SOLD*WITH* this 'incompatible library' While not *explicitly* *written* I view this as an original exception that was unwritten, but granted, as demonstrated by the original author, and original copyright holder of the package as an acceptable exception. We as a group, perhaps may not like this fact, but it is what it is. I can not change that original exception, nor can anyone else. It was part of the deal when each of us started to contribute to OpenOCD. For example - see the Amontec Application note - copyright 2000 to 2006 which explicitly references the FT22xx drivers. http://www.amontec.com/pub/amt_ann006.pdf I also point out the history of openocd on the Amontec web site http://www.amontec.com/openocd.shtml (bottom of the page) The person who can clarify any misunderstanding is Domenic, and Dominic alone. The problem with your argument is that the license in the tree is GPL; the license in all of the source code headers is GPL. There are no exceptions stated anywhere in the tree. Consequently, this demonstrates that my contributions were made under the GPL without any exceptions, and I imagine that I am not the only contributor to have come to this particular conclusion based on these same facts. I am afraid that your intent will not matter even one iota, in a court of law. If you want to make exceptions, then they do not apply to the new code. You cannot retroactively change the license; however, you are free to fork the code at a point prior to my having a claim on the copyrights, and make an exception there. Since said license will not be compatible with the GPL anymore, you may not use the changes that I contributed. However, this further presumes that I am the only one that will object to such a change. That may not be the case, and I hope that others authors that share my views will step forward to confirm this point. Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development Yes the licence is GPL, and there are no exceptions stated, unfortunatley. It is definitly possible to add an exception to allow linking to non GPL libraries and still remain GPL, but it is not possible to force derived GPL works to do the same: http://www.fsf.org/licensing/licenses/gpl-faq.html#GPLIncompatibleLibs We only need the consent of the copyright holders. All long time developers of OpenOCD has been aware of the status of the libftd2xxx as proprietary code, have not been complaining and as such have been promoting this use. Or they have been living under a rock for the last couple of years. So perhaps it is time to formalize this exception to GPL that we have been accepting for years and add the exception to the licence in our code. I can tell you all that I have no objections to adding this exception to linking against a non GPL library as far as my contributions to OpnenOCD are concerned. If anybody
Re: [Openocd-development] Idea on dr/irscan command handling
Øyvind Harboe wrote: Q: should dr/irscan throw an error if polling is enabled? OpenOCD does background polling based on a timer, so two consecutive ir/drscan commands could see other JTAG operations intervening, wreaking havoc. Targets such as the OMAP needs to run a sequence of jtag commands uninterrupted. Some ideas: - implementations must start such sequences by poll off and end them with poll on. Ugly, but supported today. - define a wrapper tcl proc that handles reading the current polling state, turning off polling, executing a sequence of commands and then restoring the polling status regardless of whether an exception was thrown or not. Writing such a wrapper is easy. - make all reset event scripts run with background events disabled. The ir/drscan also lacks the ability to return the data clocked in, it does not support longer than 32 bits scans, and there is no statemove/pathmove command + a raft of other shortcomings of these commands, but that's really an independant issue. I do not think this is so bad really: The type of target/tap initialisation that needs dr/ir scans to setup the jtag chain and controller are run before the target can be examined. The type of target initialisations that sets memory mapped registers with mww are not affected by polling- Polls, and many other commands, are not sent to targets that has not been examined. So the initial dr/ir scans are not interrupted. If we want to do manual dr/ir scans after the target has been setup, initialised and examined, the it is reasonable that we have to use poll off. So what I think we need is a delayed target examination, something like when defining a target we set a flag -delay_examine to signal that more setup must be done before the targtet can be examined with arp_examine. My två öre, regards Magnus ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [Patch] TAR autoincrement block size and alignment
Hi
The number of bits used for TAR autoincrement when using
CSW_ADDRINC_PACKED must be at least 10 according to ARM ADI
specifications. Cortex-M3 uses 12 bits (4k blocks) and OMAP35xx uses 10
bits (1k blocks).
This patch adds support for different TAR autotincrement sizes and sets
it to 12 bits for Cortex-M3.
Regards
Magnus
Index: src/target/arm_adi_v5.c
===
--- src/target/arm_adi_v5.c (revision 2032)
+++ src/target/arm_adi_v5.c (working copy)
@@ -41,6 +41,9 @@
#include arm_adi_v5.h
#include time_support.h
+/* ARM ADI Specification requires at least 10 bits used for TAR autoincrement */
+#define TAR_AUTOINCR_BLOCK (swjdp-tar_autoincr_block)
+
/*
* Transaction Mode:
* swjdp-trans_mode = TRANS_MODE_COMPOSITE;
@@ -467,8 +470,8 @@
while (wcount 0)
{
- /* Adjust to write blocks within 4K aligned boundaries */
- blocksize = (0x1000 - (0xFFF address)) 2;
+ /* Adjust to write blocks within boundaries aligned to the TAR autoincremnent size*/
+ blocksize = (TAR_AUTOINCR_BLOCK - ((TAR_AUTOINCR_BLOCK-1) address)) 2;
if (wcount blocksize)
blocksize = wcount;
@@ -517,8 +520,8 @@
{
int nbytes;
- /* Adjust to read within 4K block boundaries */
- blocksize = (0x1000 - (0xFFF address)) 1;
+ /* Adjust to write blocks within boundaries aligned to the TAR autoincremnent size*/
+ blocksize = (TAR_AUTOINCR_BLOCK - ((TAR_AUTOINCR_BLOCK-1) address)) 2;
if (wcount blocksize)
blocksize = wcount;
@@ -613,8 +616,8 @@
{
int nbytes;
- /* Adjust to read within 4K block boundaries */
- blocksize = (0x1000 - (0xFFF address));
+ /* Adjust to write blocks within boundaries aligned to the TAR autoincremnent size*/
+ blocksize = (TAR_AUTOINCR_BLOCK - ((TAR_AUTOINCR_BLOCK-1) address)) 2;
if (wcount blocksize)
blocksize = wcount;
@@ -710,8 +713,8 @@
while (wcount 0)
{
- /* Adjust to read within 4K block boundaries */
- blocksize = (0x1000 - (0xFFF address)) 2;
+ /* Adjust to read blocks within boundaries aligned to the TAR autoincremnent size*/
+ blocksize = (TAR_AUTOINCR_BLOCK - ((TAR_AUTOINCR_BLOCK-1) address)) 2;
if (wcount blocksize)
blocksize = wcount;
@@ -784,8 +787,8 @@
{
int nbytes;
- /* Adjust to read within 4K block boundaries */
- blocksize = (0x1000 - (0xFFF address)) 1;
+ /* Adjust to read blocks within boundaries aligned to the TAR autoincremnent size*/
+ blocksize = (TAR_AUTOINCR_BLOCK - ((TAR_AUTOINCR_BLOCK-1) address)) 2;
if (wcount blocksize)
blocksize = wcount;
@@ -879,8 +882,8 @@
{
int nbytes;
- /* Adjust to read within 4K block boundaries */
- blocksize = (0x1000 - (0xFFF address));
+ /* Adjust to read blocks within boundaries aligned to the TAR autoincremnent size*/
+ blocksize = (TAR_AUTOINCR_BLOCK - ((TAR_AUTOINCR_BLOCK-1) address)) 2;
if (wcount blocksize)
blocksize = wcount;
Index: src/target/arm_adi_v5.h
===
--- src/target/arm_adi_v5.h (revision 2032)
+++ src/target/arm_adi_v5.h (working copy)
@@ -99,8 +99,17 @@
u8 ack;
/* extra tck clocks for memory bus access */
u32 memaccess_tck;
+ /* Size of TAR autoincrement block, ARM ADI Specification requires at least 10 bits */
+ u32 tar_autoincr_block;
+
} swjdp_common_t;
+/* Accessor function for currently selected DAP-AP number */
+static inline u8 dap_ap_get_select(swjdp_common_t *swjdp)
+{
+ return (u8)( swjdp -apsel 24);
+}
+
/* Internal functions used in the module, partial transactions, use with caution */
extern int dap_dp_write_reg(swjdp_common_t *swjdp, u32 value, u8 reg_addr);
/* extern int swjdp_write_apacc(swjdp_common_t *swjdp, u32 value, u8 reg_addr); */
Index: src/target/cortex_m3.c
===
--- src/target/cortex_m3.c (revision 2032)
+++ src/target/cortex_m3.c (working copy)
@@ -1579,6 +1579,7 @@
armv7m-swjdp_info.ap_tar_value = -1;
armv7m-swjdp_info.jtag_info = cortex_m3-jtag_info;
armv7m-swjdp_info.memaccess_tck = 8;
+ armv7m-swjdp_info.tar_autoincr_block = (112); /* Cortex-M3 has 4096 bytes autoincrement range */
/* initialize arch-specific breakpoint handling */
@@ -1599,6 +1600,10 @@
armv7m-store_core_reg_u32 = cortex_m3_store_core_reg_u32;
target_register_timer_callback(cortex_m3_handle_target_request, 1, 1, target);
+ if((retval = arm_jtag_setup_connection(cortex_m3-jtag_info)) != ERROR_OK)
+ {
+ return retval;
+ }
if ((retval = arm_jtag_setup_connection(cortex_m3-jtag_info)) != ERROR_OK)
{
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [Patch] TAR autoincrement block size and alignment
Zach Welch wrote:
On Thu, 2009-06-04 at 12:49 +0200, Magnus Lundin wrote:
Hi
The number of bits used for TAR autoincrement when using
CSW_ADDRINC_PACKED must be at least 10 according to ARM ADI
specifications. Cortex-M3 uses 12 bits (4k blocks) and OMAP35xx uses 10
bits (1k blocks).
This patch adds support for different TAR autotincrement sizes and sets
it to 12 bits for Cortex-M3.
Please remove the #define TAR_AUTOINCR_BLOCK and put the following line
in a static function. Use a temporary variable.
+ /* Adjust to read blocks within boundaries aligned to
the TAR autoincremnent size*/
+ blocksize = (TAR_AUTOINCR_BLOCK -
((TAR_AUTOINCR_BLOCK-1) address)) 2;
Thanks.
Z
New version
Regards
Magnus
Index: src/target/arm_adi_v5.c
===
--- src/target/arm_adi_v5.c (revision 2032)
+++ src/target/arm_adi_v5.c (working copy)
@@ -52,6 +52,18 @@
* are immediatley available.
*/
+
+/* ARM ADI Specification requires at least 10 bits used for TAR autoincrement */
+
+/*
+ u32 tar_block_size(u32 address)
+ Return the largest block starting at address that does not cross a tar block size alignment boundary
+*/
+static u32 max_tar_block_size(u32 tar_autoincr_block, u32 address)
+{
+ return (tar_autoincr_block - ((tar_autoincr_block - 1) address)) 2;
+}
+
/***
* *
* DPACC and APACC scanchain access through JTAG-DP*
@@ -467,8 +479,8 @@
while (wcount 0)
{
- /* Adjust to write blocks within 4K aligned boundaries */
- blocksize = (0x1000 - (0xFFF address)) 2;
+ /* Adjust to write blocks within boundaries aligned to the TAR autoincremnent size*/
+ blocksize = max_tar_block_size(swjdp-tar_autoincr_block, address);
if (wcount blocksize)
blocksize = wcount;
@@ -517,8 +529,8 @@
{
int nbytes;
- /* Adjust to read within 4K block boundaries */
- blocksize = (0x1000 - (0xFFF address)) 1;
+ /* Adjust to write blocks within boundaries aligned to the TAR autoincremnent size*/
+ blocksize = max_tar_block_size(swjdp-tar_autoincr_block, address);
if (wcount blocksize)
blocksize = wcount;
@@ -613,8 +625,8 @@
{
int nbytes;
- /* Adjust to read within 4K block boundaries */
- blocksize = (0x1000 - (0xFFF address));
+ /* Adjust to write blocks within boundaries aligned to the TAR autoincremnent size*/
+ blocksize = max_tar_block_size(swjdp-tar_autoincr_block, address);
if (wcount blocksize)
blocksize = wcount;
@@ -710,8 +722,8 @@
while (wcount 0)
{
- /* Adjust to read within 4K block boundaries */
- blocksize = (0x1000 - (0xFFF address)) 2;
+ /* Adjust to read blocks within boundaries aligned to the TAR autoincremnent size*/
+ blocksize = max_tar_block_size(swjdp-tar_autoincr_block, address);
if (wcount blocksize)
blocksize = wcount;
@@ -784,8 +796,8 @@
{
int nbytes;
- /* Adjust to read within 4K block boundaries */
- blocksize = (0x1000 - (0xFFF address)) 1;
+ /* Adjust to read blocks within boundaries aligned to the TAR autoincremnent size*/
+ blocksize = max_tar_block_size(swjdp-tar_autoincr_block, address);
if (wcount blocksize)
blocksize = wcount;
@@ -879,8 +891,8 @@
{
int nbytes;
- /* Adjust to read within 4K block boundaries */
- blocksize = (0x1000 - (0xFFF address));
+ /* Adjust to read blocks within boundaries aligned to the TAR autoincremnent size*/
+ blocksize = max_tar_block_size(swjdp-tar_autoincr_block, address);
if (wcount blocksize)
blocksize = wcount;
Index: src/target/arm_adi_v5.h
===
--- src/target/arm_adi_v5.h (revision 2032)
+++ src/target/arm_adi_v5.h (working copy)
@@ -99,8 +99,17 @@
u8 ack;
/* extra tck clocks for memory bus access */
u32 memaccess_tck;
+ /* Size of TAR autoincrement block, ARM ADI Specification requires at least 10 bits */
+ u32 tar_autoincr_block;
+
} swjdp_common_t;
+/* Accessor function for currently selected DAP-AP number */
+static inline u8 dap_ap_get_select(swjdp_common_t *swjdp)
+{
+ return (u8)( swjdp -apsel 24);
+}
+
/* Internal functions used in the module, partial transactions, use with caution */
extern int dap_dp_write_reg(swjdp_common_t *swjdp, u32 value, u8 reg_addr);
/* extern int swjdp_write_apacc(swjdp_common_t *swjdp, u32 value, u8 reg_addr); */
Index: src/target/cortex_m3.c
===
--- src/target/cortex_m3.c (revision 2032)
+++ src/target/cortex_m3.c (working copy)
@@ -1579,6 +1579,7 @@
armv7m-swjdp_info.ap_tar_value = -1;
armv7m-swjdp_info.jtag_info = cortex_m3-jtag_info;
armv7m-swjdp_info.memaccess_tck = 8;
+ armv7m-swjdp_info.tar_autoincr_block = (112); /* Cortex-M3 has 4096 bytes autoincrement range
[Openocd-development] [PATCH] Make mdw output readable again
Regards
Magnus
Index: src/target/target.c
===
--- src/target/target.c (revision 2051)
+++ src/target/target.c (working copy)
@@ -1945,9 +1965,9 @@
const char *value_fmt;
switch (size) {
- case 4: value_fmt = %8.8x; break;
- case 2: value_fmt = %4.2x; break;
- case 1: value_fmt = %2.2x; break;
+ case 4: value_fmt = %8.8x ; break;
+ case 2: value_fmt = %4.2x ; break;
+ case 1: value_fmt = %2.2x ; break;
default:
LOG_ERROR(invalid memory read size: %u, size);
exit(-1);
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] Do not try to examine targets with disabled taps
It won't work, but is is not an error. Return ERROR_OK so other targets
in the chain can be examined.
Reagrds
Magnus
Index: src/target/target.c
===
--- src/target/target.c (revision 2051)
+++ src/target/target.c (working copy)
@@ -470,6 +470,11 @@
int target_examine_one(struct target_s *target)
{
+ if (! target-tap-enabled)
+ {
+ LOG_WARNING(Target %s with disabled tap cannot be examined, use arp_examine after init,target_get_name(target));
+ return ERROR_OK;
+ }
return target-type-examine(target);
}
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Strange block size for dump_image
Can anybody explain we OpenOCD uses blocks of size 560 for dump_image ( target.c line 2241 ) ?? Regards, Magnus ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch 2/4] {i,d}rscan next-state tweaks
Øyvind Harboe wrote: - RESET is an illegal end state. It's split out as a separate thing for lots of reasons, including that this triggers events that listeners are listening for, etc. - irscan should use the drscan code implementation. They are almost identical. - DRPAUSE makes no sense for IRSCAN as an endstate according to your new and improved rules... Ditto for DRSCAN If I were a user who wanted to work/play with direct jtag commands from the command line or in a script, I would REALLY hate it if I were told that the official stable states of the JTAG state machine were not available as end states for the scan commands. I could point to the STAPL documentation The DRSTOP statement specifies the IEEE 1149.1 end state for data register scan operations. This end state must be one of the IEEE 1149.1 states: RESET, IDLE, IRPAUSE, or DRPAUSE.. Well ... I am not playing with this at the moment and I can, and do, rewrite the code to work without unneccesary limits, but the strong selling points are lost on me. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] No flash patch comparator unit available cortex-m3.c [jlink]
Gene Smith wrote: Gene Smith wrote: I am unable to set h/w breakpoints or step in my new cortex-m3 (stm3210e-eval board) now using jlink. It was working OK for a while yesterday but now it refuses to do anything. This is with the informal patches we were doing a few weeks ago for jlink which seemed to work great when debugging an arm7tdmi with same jlink. Have not tried the latest trunk version yet. I have tried resetting everything but no luck in stepping to main. It will allow me to set a bp on main but then when I continue or step it produces the info message about the flash patch comparator unit. Not sure what this means except it thinks all the hw breakpoints are used up which I don't think they are since I only set one. Thanks, -gene Updated svn to current r2003 and fixed the problems above. However, don't know why I can't reliably go over jtag_khz 470 like I could when debugging with the same jlink on the str712 demo board (arm7tdmi). With the arm7 I could set the jtag speed to zero (adaptive) and it worked great. With cortex-m3 it seems a bit more limited and error prone (but OK if kept at or below 470). Here's what I see when I go over 470 or set it to zero: RCLK - adaptive Error: AHBAP Cached values: dp_select 0x0, ap_csw 0xa212, ap_tar 0x Error: SWJ-DP OVERRUN - check clock or reduce jtag speed Error: Read MEM_AP_CSW 0x2352, MEM_AP_TAR 0xe000edf0 Error: AHBAP Cached values: dp_select 0x0, ap_csw 0xa212, ap_tar 0x Error: SWJ-DP OVERRUN - check clock or reduce jtag speed Error: Read MEM_AP_CSW 0x2352, MEM_AP_TAR 0x40011c00 Warn : Block read error address 0x40011c00, count 0xe4 Error: AHBAP Cached values: dp_select 0x10, ap_csw 0xa202, ap_tar 0xe000edf0 Error: SWJ-DP OVERRUN - check clock or reduce jtag speed Error: Read MEM_AP_CSW 0x2342, MEM_AP_TAR 0x40011c00 Actually I can do most debugging activities at default 500Khz. But if I try to dump a large memory block (e.g., with insight, mdb etc.) I see the above errors. In the example above I was looking at memory location 0x40011c00 and insight was bring in a full screen of values. The new shorter state transition tables actually decrases the time for completing memory bus access betwen succesive dr scans using the same jtag_khz. So the OVERRUN becomes more likely. I will publish a patch that helps against OVERRUNS soon. Best regards Magnus ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [Patch] Fix overrun problems on Cortex targets.
Here is a patch that helps against the well known OVERRUN errors for Cortex-M3 ( the problem is even worse for Cortex-A8 ) Basically the patch adds a fixed number ( default 8 ) of extra tck clocks before every DR scan that accesses the target memory bus through the DAP_MEMAP. This makes it possible to increase the jtag_khz, tested with JLink at 12MHz, improving total speed. Contents: + change signature for adi_jtag_dp_scan and adi_jtag_dp_scan_u32 to use swjdp_common_t *swjdp instead of arm_jtag_t *jtag_info + change SWJDP_IR/DR_APACC to DAP_IR/DR_APACC to conform with ARM_ADI docs. + add swjdp-memaccess_tck field and code for extra tck clocks before accessing memory bus + Set default memaccess value to 8 for Cortex-M3 + Add dap memaccess command Tested with STM32 andOMAP3530 for several weeks, no known problems. This should apply and build cleanly against trunk. Regards Magnus ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [Patch] Fix overrun problems on Cortex targets.
Yeah ... things happen, but lets try again :)
Index: src/target/arm_adi_v5.c
===
--- src/target/arm_adi_v5.c (revision 1977)
+++ src/target/arm_adi_v5.c (working copy)
@@ -59,43 +59,39 @@
***/
/* Scan out and in from target ordered u8 buffers */
-int adi_jtag_dp_scan(arm_jtag_t *jtag_info, u8 instr, u8 reg_addr, u8 RnW, u8 *outvalue, u8 *invalue, u8 *ack)
+int adi_jtag_dp_scan(swjdp_common_t *swjdp, u8 instr, u8 reg_addr, u8 RnW, u8 *outvalue, u8 *invalue, u8 *ack)
{
+ arm_jtag_t *jtag_info = swjdp-jtag_info;
scan_field_t fields[2];
u8 out_addr_buf;
jtag_add_end_state(TAP_IDLE);
arm_jtag_set_instr(jtag_info, instr, NULL);
+ /* Add specified number of tck clocks before accessing memory bus */
+ if ((instr == DAP_IR_APACC) ((reg_addr == AP_REG_DRW)||((reg_addr0xF0) == AP_REG_BD0) ) (swjdp-memaccess_tck != 0))
+ jtag_add_runtest(swjdp-memaccess_tck, TAP_IDLE);
+
fields[0].tap = jtag_info-tap;
fields[0].num_bits = 3;
buf_set_u32(out_addr_buf, 0, 3, ((reg_addr 1) 0x6) | (RnW 0x1));
fields[0].out_value = out_addr_buf;
-
fields[0].in_value = ack;
-
-
-
-
fields[1].tap = jtag_info-tap;
fields[1].num_bits = 32;
fields[1].out_value = outvalue;
-
fields[1].in_value = invalue;
-
-
-
-
jtag_add_dr_scan(2, fields, TAP_INVALID);
return ERROR_OK;
}
/* Scan out and in from host ordered u32 variables */
-int adi_jtag_dp_scan_u32(arm_jtag_t *jtag_info, u8 instr, u8 reg_addr, u8 RnW, u32 outvalue, u32 *invalue, u8 *ack)
+int adi_jtag_dp_scan_u32(swjdp_common_t *swjdp, u8 instr, u8 reg_addr, u8 RnW, u32 outvalue, u32 *invalue, u8 *ack)
{
+ arm_jtag_t *jtag_info = swjdp-jtag_info;
scan_field_t fields[2];
u8 out_value_buf[4];
u8 out_addr_buf;
@@ -103,20 +99,21 @@
jtag_add_end_state(TAP_IDLE);
arm_jtag_set_instr(jtag_info, instr, NULL);
+ /* Add specified number of tck clocks before accessing memory bus */
+ if ((instr == DAP_IR_APACC) ((reg_addr == AP_REG_DRW)||((reg_addr0xF0) == AP_REG_BD0) ) (swjdp-memaccess_tck != 0))
+ jtag_add_runtest(swjdp-memaccess_tck, TAP_IDLE);
+
fields[0].tap = jtag_info-tap;
fields[0].num_bits = 3;
buf_set_u32(out_addr_buf, 0, 3, ((reg_addr 1) 0x6) | (RnW 0x1));
fields[0].out_value = out_addr_buf;
fields[0].in_value = ack;
-
-
fields[1].tap = jtag_info-tap;
fields[1].num_bits = 32;
buf_set_u32(out_value_buf, 0, 32, outvalue);
fields[1].out_value = out_value_buf;
fields[1].in_value = NULL;
-
if (invalue)
{
@@ -136,14 +133,15 @@
/* scan_inout_check adds one extra inscan for DPAP_READ commands to read variables */
int scan_inout_check(swjdp_common_t *swjdp, u8 instr, u8 reg_addr, u8 RnW, u8 *outvalue, u8 *invalue)
{
- adi_jtag_dp_scan(swjdp-jtag_info, instr, reg_addr, RnW, outvalue, NULL, NULL);
+ adi_jtag_dp_scan(swjdp, instr, reg_addr, RnW, outvalue, NULL, NULL);
+
if ((RnW == DPAP_READ) (invalue != NULL))
{
- adi_jtag_dp_scan(swjdp-jtag_info, SWJDP_IR_DPACC, DP_RDBUFF, DPAP_READ, 0, invalue, swjdp-ack);
+ adi_jtag_dp_scan(swjdp, DAP_IR_DPACC, DP_RDBUFF, DPAP_READ, 0, invalue, swjdp-ack);
}
- /* In TRANS_MODE_ATOMIC all SWJDP_IR_APACC transactions wait for ack=OK/FAULT and the check CTRL_STAT */
- if ((instr == SWJDP_IR_APACC) (swjdp-trans_mode == TRANS_MODE_ATOMIC))
+ /* In TRANS_MODE_ATOMIC all DAP_IR_APACC transactions wait for ack=OK/FAULT and the check CTRL_STAT */
+ if ((instr == DAP_IR_APACC) (swjdp-trans_mode == TRANS_MODE_ATOMIC))
{
return swjdp_transaction_endcheck(swjdp);
}
@@ -153,14 +151,15 @@
int scan_inout_check_u32(swjdp_common_t *swjdp, u8 instr, u8 reg_addr, u8 RnW, u32 outvalue, u32 *invalue)
{
- adi_jtag_dp_scan_u32(swjdp-jtag_info, instr, reg_addr, RnW, outvalue, NULL, NULL);
+ adi_jtag_dp_scan_u32(swjdp, instr, reg_addr, RnW, outvalue, NULL, NULL);
+
if ((RnW==DPAP_READ) (invalue != NULL))
{
- adi_jtag_dp_scan_u32(swjdp-jtag_info, SWJDP_IR_DPACC, DP_RDBUFF, DPAP_READ, 0, invalue, swjdp-ack);
+ adi_jtag_dp_scan_u32(swjdp, DAP_IR_DPACC, DP_RDBUFF, DPAP_READ, 0, invalue, swjdp-ack);
}
- /* In TRANS_MODE_ATOMIC all SWJDP_IR_APACC transactions wait for ack=OK/FAULT and then check CTRL_STAT */
- if ((instr == SWJDP_IR_APACC) (swjdp-trans_mode == TRANS_MODE_ATOMIC))
+ /* In TRANS_MODE_ATOMIC all DAP_IR_APACC transactions wait for ack=OK/FAULT and then check CTRL_STAT */
+ if ((instr == DAP_IR_APACC) (swjdp-trans_mode == TRANS_MODE_ATOMIC))
{
return swjdp_transaction_endcheck(swjdp);
}
@@ -177,7 +176,7 @@
#if 0
/* Danger BROKEN */
- scan_inout_check_u32(swjdp, SWJDP_IR_DPACC, DP_CTRL_STAT, DPAP_READ, 0, ctrlstat);
+ scan_inout_check_u32(swjdp, DAP_IR_DPACC, DP_CTRL_STAT, DPAP_READ, 0, ctrlstat);
/* Danger BROKEN Why will jtag_execute_queue() fail here
R956 introduced the check on return value here and now Michael Schwingen reports
that this code no longer works
@@
Re: [Openocd-development] [Patch] Fix overrun problems on Cortex targets.
Gene Smith wrote:
Magnus Lundin wrote:
Here is a patch that helps against the well known OVERRUN errors for
Cortex-M3 ( the problem is even worse for Cortex-A8 )
Basically the patch adds a fixed number ( default 8 ) of extra tck
clocks before every DR scan that accesses the target memory bus through
the DAP_MEMAP.
This makes it possible to increase the jtag_khz, tested with JLink at
12MHz, improving total speed.
Contents:
+ change signature for adi_jtag_dp_scan and adi_jtag_dp_scan_u32 to use
swjdp_common_t *swjdp instead of arm_jtag_t *jtag_info
+ change SWJDP_IR/DR_APACC to DAP_IR/DR_APACC to conform with ARM_ADI docs.
+ add swjdp-memaccess_tck field and code for extra tck clocks before
accessing memory bus
+ Set default memaccess value to 8 for Cortex-M3
+ Add dap memaccess command
Tested with STM32 andOMAP3530 for several weeks, no known problems.
This should apply and build cleanly against trunk.
Apparently armv7m.c has some sort of problem against r2003. Something
about the copyright I think.
Seems like a editor screwup with Norweian letters.
I remove that part and repost
Index: src/target/arm_adi_v5.c
===
--- src/target/arm_adi_v5.c (revision 1977)
+++ src/target/arm_adi_v5.c (working copy)
@@ -59,43 +59,39 @@
***/
/* Scan out and in from target ordered u8 buffers */
-int adi_jtag_dp_scan(arm_jtag_t *jtag_info, u8 instr, u8 reg_addr, u8 RnW, u8 *outvalue, u8 *invalue, u8 *ack)
+int adi_jtag_dp_scan(swjdp_common_t *swjdp, u8 instr, u8 reg_addr, u8 RnW, u8 *outvalue, u8 *invalue, u8 *ack)
{
+ arm_jtag_t *jtag_info = swjdp-jtag_info;
scan_field_t fields[2];
u8 out_addr_buf;
jtag_add_end_state(TAP_IDLE);
arm_jtag_set_instr(jtag_info, instr, NULL);
+ /* Add specified number of tck clocks before accessing memory bus */
+ if ((instr == DAP_IR_APACC) ((reg_addr == AP_REG_DRW)||((reg_addr0xF0) == AP_REG_BD0) ) (swjdp-memaccess_tck != 0))
+ jtag_add_runtest(swjdp-memaccess_tck, TAP_IDLE);
+
fields[0].tap = jtag_info-tap;
fields[0].num_bits = 3;
buf_set_u32(out_addr_buf, 0, 3, ((reg_addr 1) 0x6) | (RnW 0x1));
fields[0].out_value = out_addr_buf;
-
fields[0].in_value = ack;
-
-
-
-
fields[1].tap = jtag_info-tap;
fields[1].num_bits = 32;
fields[1].out_value = outvalue;
-
fields[1].in_value = invalue;
-
-
-
-
jtag_add_dr_scan(2, fields, TAP_INVALID);
return ERROR_OK;
}
/* Scan out and in from host ordered u32 variables */
-int adi_jtag_dp_scan_u32(arm_jtag_t *jtag_info, u8 instr, u8 reg_addr, u8 RnW, u32 outvalue, u32 *invalue, u8 *ack)
+int adi_jtag_dp_scan_u32(swjdp_common_t *swjdp, u8 instr, u8 reg_addr, u8 RnW, u32 outvalue, u32 *invalue, u8 *ack)
{
+ arm_jtag_t *jtag_info = swjdp-jtag_info;
scan_field_t fields[2];
u8 out_value_buf[4];
u8 out_addr_buf;
@@ -103,20 +99,21 @@
jtag_add_end_state(TAP_IDLE);
arm_jtag_set_instr(jtag_info, instr, NULL);
+ /* Add specified number of tck clocks before accessing memory bus */
+ if ((instr == DAP_IR_APACC) ((reg_addr == AP_REG_DRW)||((reg_addr0xF0) == AP_REG_BD0) ) (swjdp-memaccess_tck != 0))
+ jtag_add_runtest(swjdp-memaccess_tck, TAP_IDLE);
+
fields[0].tap = jtag_info-tap;
fields[0].num_bits = 3;
buf_set_u32(out_addr_buf, 0, 3, ((reg_addr 1) 0x6) | (RnW 0x1));
fields[0].out_value = out_addr_buf;
fields[0].in_value = ack;
-
-
fields[1].tap = jtag_info-tap;
fields[1].num_bits = 32;
buf_set_u32(out_value_buf, 0, 32, outvalue);
fields[1].out_value = out_value_buf;
fields[1].in_value = NULL;
-
if (invalue)
{
@@ -136,14 +133,15 @@
/* scan_inout_check adds one extra inscan for DPAP_READ commands to read variables */
int scan_inout_check(swjdp_common_t *swjdp, u8 instr, u8 reg_addr, u8 RnW, u8 *outvalue, u8 *invalue)
{
- adi_jtag_dp_scan(swjdp-jtag_info, instr, reg_addr, RnW, outvalue, NULL, NULL);
+ adi_jtag_dp_scan(swjdp, instr, reg_addr, RnW, outvalue, NULL, NULL);
+
if ((RnW == DPAP_READ) (invalue != NULL))
{
- adi_jtag_dp_scan(swjdp-jtag_info, SWJDP_IR_DPACC, DP_RDBUFF, DPAP_READ, 0, invalue, swjdp-ack);
+ adi_jtag_dp_scan(swjdp, DAP_IR_DPACC, DP_RDBUFF, DPAP_READ, 0, invalue, swjdp-ack);
}
- /* In TRANS_MODE_ATOMIC all SWJDP_IR_APACC transactions wait for ack=OK/FAULT and the check CTRL_STAT */
- if ((instr == SWJDP_IR_APACC) (swjdp-trans_mode == TRANS_MODE_ATOMIC))
+ /* In TRANS_MODE_ATOMIC all DAP_IR_APACC transactions wait for ack=OK/FAULT and the check CTRL_STAT */
+ if ((instr == DAP_IR_APACC) (swjdp-trans_mode == TRANS_MODE_ATOMIC))
{
return swjdp_transaction_endcheck(swjdp);
}
@@ -153,14 +151,15 @@
int scan_inout_check_u32(swjdp_common_t *swjdp, u8 instr, u8 reg_addr, u8 RnW, u32 outvalue, u32 *invalue)
{
- adi_jtag_dp_scan_u32(swjdp-jtag_info, instr, reg_addr, RnW, outvalue, NULL, NULL);
+ adi_jtag_dp_scan_u32(swjdp, instr, reg_addr, RnW, outvalue, NULL, NULL
Re: [Openocd-development] [PATCH] Ugly fix for J-Link hard power-on
Peter Denison wrote: Some (all?) V6 firmware on the J-Link adapter fails to step the TAP unless the first EMU_CMD_HW_JTAG3 command has 8 bits rather than 7, immediately after adapter power-up. Add a hack to pad out to 8 bits, the first time only. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development Yeah, ugly Another possible way to do this is: at the end of jlink_init(void) do for (i=0; i8; i++)jlink_tap_append_step(1, 0); jlink_tap_execute(); This is then executed before any other scan command and effectively does a tlr reset , and should have no other unknown side effects. Regards Magnus ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [RFC] Some jtag changes
I propose some changes to the jtag subsystem - Add jtag_add_statmove( endstate ) call, the code is already in jtag_add_tlr() - Remove the JTAG_RUNTEST cmd type. - Implement jtag_add_runtest(n) as jtag_add_statemovet(TAP_IDLE) jtag_stableclocks(n) /* Should be n-1 if current tap state is not TAP_IDLE ?? */ - Implement jtag_add_tlr() as jtag_add_statemovet(TAP_RESET) jtag_stableclocks(6)/* I am not 100% sure about this here */ - Make sure that JTAG_STABLECLOCKS is implemented in all drivers (we will soon fingd out otherwise ) Regards Magnus ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [RFC] Some jtag changes
Michael Bruck wrote: On Mon, Jun 1, 2009 at 11:39 AM, Magnus Lundin lun...@mlu.mine.nu wrote: I propose some changes to the jtag subsystem - Add jtag_add_statmove( endstate ) call, the code is already in jtag_add_tlr() - Remove the JTAG_RUNTEST cmd type. - Implement jtag_add_runtest(n) as jtag_add_statemovet(TAP_IDLE) jtag_stableclocks(n) /* Should be n-1 if current tap state is not TAP_IDLE ?? */ - Implement jtag_add_tlr() as jtag_add_statemovet(TAP_RESET) jtag_stableclocks(6)/* I am not 100% sure about this here */ It might work, but it obscures what is going on. Sometimes statemove would succeed and sometimes not but then stableclocks would do the job, because the JTAG driver uses the then false state information from the upper layer. Why would you add such obscure mechanisms to the code? No driver can ever know if the target jtag hardware is in TAP_RESET or not ( or any other state for that matter ). I think that this is a way of acknowleding this fact, not hiding it in much more obscure driver variant code. statemove should be a move between two defined states, not a reset from an unknown state. Especially not as long as the engine does not allow even defining the state to be unknown. A statemove to TAP_RESET is a very well defined move even if the current state is unknown, the jtag state engine was defined to make it so, and as far as we know it is between two known states. The problem is that after reset the tap_state is NOT well defined, even if we would like it to be. In the best of all worlds with good documentation and flawless configuration scripts it could be. jtag_add_tlr() should be implemented as a distinct command in the driver layer and not mixed into statemove. Otherwise you get (exactly as it is now) inconsistent behavior between the lower layer implementations because every driver has its own collection of if's to deal with special cases (like TLR). Implementing tlr in the driver layer does not remove driver specific inconsistenices. TLR should not be a special case for a driver, it is simply just another tms sequence. Putting the logic in jtag.c make behaviour more consistent. My logic is that all jtag operations except for scans, are done by statemoves, pathmoves and and stable clocks, trst and srst are outside of the jtag stateengine. So why not build tlr and runtest() from these elements ? Regards Magnus ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [RFC] Some jtag changes
Øyvind Harboe wrote: On Mon, Jun 1, 2009 at 11:39 AM, Magnus Lundin lun...@mlu.mine.nu wrote: I propose some changes to the jtag subsystem - Add jtag_add_statmove( endstate ) call, the code is already in jtag_add_tlr() Could you write the documentation for this fn as a separate proposal? This is simply the jtag api wrapper for the JTAG_STATEMOVE command type. Move from current state to (stable state) endstate using the current state_table. If we are already in endstate do nothing You are here talking about the application code communicating to the driver that somehow the JTAG state machine state has changed behind the scenes...? No, that concernes the use in jtag_tlr(). This is useful after reset or some communication failure, usually signaled by a failed IR scan verification check. In my experience we get IR verification errors when there is some error causing the actual hw tap state and the drivers idea about current tap state to disagree. I don't understand the motivation for allowing access to this fn, but I vaguely recall that something was written about this on the list recently. Post 0.2? Or are you talking about something along the lines of xsvf_add_statemove() in xsvf.c? Without knowledge about xsvf_add_statemove, probabky so. - Implement jtag_add_tlr() as jtag_add_statemovet(TAP_RESET) jtag_stableclocks(6)/* I am not 100% sure about this here */ Why? To remove different driver interpretations of how this should be done. - Make sure that JTAG_STABLECLOCKS is implemented in all drivers (we will soon fingd out otherwise ) Don't we already have this in jtag_add_clocks()? Look for JTAG_STABLECLOCKS in the current JLink driver. Another thing I'd like first is to see if we can retire jtag_add_end_state(), as this would effectively make removing jtag_add_runtest() that little bit easier... I do not propose to remove jtag_add_runtest. I propose to remove the JTAG_RUNTEST command type and do the implementation in jtag.c layer. This can be done before or after jtag_add_end_state(), there is very little interation. And why am I doing this ? Testing a lot of reset and connect failures for different targets, with diffrent reset configurations for both ft2232 and jlink my conclusion is that the drivers should be smart about efficiently flipping jtag pins using the interface haredware, but jtag command logic and reset logic should be handled in jtag.c layer. So this proposal is part of mw work to make at least ft2232 and jlink drivers behave as similarily as possible. Or we could say move common functionality upwards. Best regards Magnus ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch] added jtag_add_statemove() helper fn
Øyvind Harboe wrote:
Committed 1980
Moved helper fn from xsvf.c to jtag.c to promote it to a helper fn.
This does *NOT* change any of the lower level parts of the
JTAG API or drivers, just shows how to use the JTAG API.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
My idea was to use the state_tables and JTAG_STATEMOVE command we
already have implemented in all drivers.
void jtag_add_statemove(tap_state_t end_state)
{
int retval;
if ((end_state != TAP_INVALID) !tap_is_state_stable(end_state))
{
LOG_ERROR(BUG: TAP path doesn't finish in a stable state);
exit(-1);
}
jtag_prelude(end_state);
retval=interface_jtag_add_statemove(end_state);
if (retval!=ERROR_OK)
jtag_error=retval;
}
int MINIDRIVER(interface_jtag_add_statemove)(tap_state_t end_state)
{
jtag_command_t **last_cmd = jtag_get_last_command_p();
/* allocate memory for a new list member */
*last_cmd = cmd_queue_alloc(sizeof(jtag_command_t));
last_comand_pointer = ((*last_cmd)-next);
(*last_cmd)-next = NULL;
(*last_cmd)-type = JTAG_STATEMOVE;
(*last_cmd)-cmd.statemove =
cmd_queue_alloc(sizeof(statemove_command_t));
(*last_cmd)-cmd.statemove-end_state = end_state;
return ERROR_OK;
}
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] jlink issues
Xiaofan Chen wrote: On Sat, May 30, 2009 at 1:01 AM, Peter Denison open...@marshadder.org wrote: Unfortunately not mine... I still get a 1 returned (instead of a zero) as the error code from EMU_CMD_HW_JTAG3, when I send 8 bits: Debug: 191 667 jlink.c:1032 jlink_usb_write(): jlink_usb_write, out_length = 6, result = 6 Debug: 192 667 jlink.c:1095 jlink_debug_buffer(): cf 00 08 00 ff 00 Debug: 193 694 jlink.c:1054 jlink_usb_read(): jlink_usb_read, result = 1 Debug: 194 694 jlink.c:1095 jlink_debug_buffer(): 00 Debug: 195 695 jlink.c:1069 jlink_usb_read_emu_result(): jlink_usb_read_result, result = 1 Debug: 196 695 jlink.c:1095 jlink_debug_buffer(): 01 Error: 197 695 jlink.c:971 jlink_usb_message(): jlink_usb_message failed with result=1) Error: 198 695 jlink.c:810 jlink_tap_execute(): jlink_tap_execute, wrong result -107 (expected 1) I got similar problem with r1948 and r1508 for the TMS470R1A256 target even though r1508 is supposed to work because of sending 8bits. r1948: Debug: 134 6136 jtag.c:2384 jtag_init_inner(): Init JTAG chain Debug: 135 6136 jtag.c:413 jtag_call_event_callbacks(): jtag event: JTAG controller reset (RESET or TRST) Debug: 136 6136 jtag.c:1630 jtag_reset_callback(): - Debug: 137 6139 jlink.c:1077 jlink_debug_buffer(): cf 00 07 00 7f 00 Debug: 138 6166 jlink.c:1077 jlink_debug_buffer(): 00 Debug: 139 6169 jlink.c:1077 jlink_debug_buffer(): 01 Error: 140 6169 jlink.c:961 jlink_usb_message(): jlink_usb_message failed with result=1) Error: 141 6169 jlink.c:800 jlink_tap_execute(): jlink_tap_execute, wrong result -107 (expected 1) r1508 Info : 111 94 jlink.c:328 jlink_init(): J-Link JTAG Interface ready Debug: 112 94 jlink.c:461 jlink_reset(): trst: 0, srst: 0 Debug: 113 94 jlink.c:964 jlink_debug_buffer(): dd Debug: 114 98 jlink.c:964 jlink_debug_buffer(): df Debug: 115 101 jlink.c:964 jlink_debug_buffer(): 05 ff ff Debug: 116 102 openocd.c:144 handle_init_command(): jtag interface init complete Debug: 117 102 jtag.c:2201 jtag_init_inner(): Init JTAG chain Debug: 118 102 jtag.c:390 jtag_call_event_callbacks(): jtag event: JTAG controller reset (RESET or TRST) Debug: 119 102 jtag.c:1450 jtag_reset_callback(): - Debug: 120 104 jlink.c:964 jlink_debug_buffer(): cf 00 08 00 ff 00 Debug: 121 132 jlink.c:964 jlink_debug_buffer(): 00 Debug: 122 135 jlink.c:964 jlink_debug_buffer(): 01 Error: 123 135 jlink.c:844 jlink_usb_message(): jlink_usb_message failed with result=1) Error: 124 135 jlink.c:704 jlink_tap_execute(): jlink_tap_execute, wrong result -107 (expected 1) Debug: 125 135 jtag.c:2234 jtag_init_reset(): Trying to bring the JTAG controller to life by asserting TRST / RESET And I have no problems with r1948 for the Olimex LPC-P2148. Info : 99 102 jlink.c:350 jlink_init(): J-Link JTAG Interface ready Debug: 100 102 jlink.c:488 jlink_reset(): trst: 0, srst: 0 Debug: 101 103 jlink.c:1077 jlink_debug_buffer(): dd Debug: 102 106 jlink.c:1077 jlink_debug_buffer(): df Debug: 103 116 jlink.c:1077 jlink_debug_buffer(): 05 ff ff Debug: 104 116 openocd.c:138 handle_init_command(): jtag interface init complete Debug: 105 116 jtag.c:2384 jtag_init_inner(): Init JTAG chain Debug: 106 116 jtag.c:413 jtag_call_event_callbacks(): jtag event: JTAG controller reset (RESET or TRST) Debug: 107 116 jtag.c:1630 jtag_reset_callback(): - Debug: 108 119 jlink.c:1077 jlink_debug_buffer(): cf 00 07 00 7f 00 Debug: 109 120 jlink.c:1077 jlink_debug_buffer(): 00 Debug: 110 123 jlink.c:1077 jlink_debug_buffer(): 00 Debug: 111 123 jtag.c:413 jtag_call_event_callbacks(): jtag event: JTAG controller reset (RESET or TRST) Debug: 112 123 jtag.c:1630 jtag_reset_callback(): - Debug: 113 124 jlink.c:1077 jlink_debug_buffer(): ff 00 00 00 ff 00 00 00 ff 00 00 00 ff 00 00 00 Debug: 114 124 jlink.c:1077 jlink_debug_buffer(): 0010 ff 00 00 00 ff 00 00 00 ff 00 00 00 ff 00 00 00 Debug: 115 124 jlink.c:1077 jlink_debug_buffer(): 0020 ff 00 00 00 ff 00 00 00 ff 00 00 00 ff 00 00 00 Debug: 116 124 jlink.c:1077 jlink_debug_buffer(): 0030 ff 00 00 00 ff 00 00 00 ff 00 00 00 ff 00 00 00 Debug: 117 124 jlink.c:1077 jlink_debug_buffer(): 0040 ff 00 00 00 ff 00 00 00 ff 00 00 00 ff 00 00 00 Debug: 118 126 jlink.c:1077 jlink_debug_buffer(): cf 00 8f 02 17 00 00 00 00 00 00 00 00 00 00 00 Debug: 119 126 jlink.c:1077 jlink_debug_buffer(): 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Debug: 120 127 jlink.c:1077 jlink_debug_buffer(): 0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Debug: 121 127 jlink.c:1077 jlink_debug_buffer(): 0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Debug: 122 127 jlink.c:1077 jlink_debug_buffer(): 0040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Debug: 123 127 jlink.c:1077 jlink_debug_buffer(): 0050 00 00 00 00 40 7f 80 7f 00 00 80 7f 00 00 80 7f Debug: 124 127 jlink.c:1077
Re: [Openocd-development] jlink issues
Hi
a bit more debugging
The issue seesms to be in the function jlink_tap_execute
the change in r1509 that causes the issue is:
// number of full bytes (plus one if some would be left over)
byte_length = tap_length / 8 + !!(tap_length % 8);
instead of r1508
/* Pad last byte so that tap_length is divisible by 8 */
while (tap_length % 8 != 0)
{
/* More of the last TMS value keeps us in the same state,
* analogous to free-running JTAG interfaces. */
jlink_tap_append_step(last_tms, 0);
}
byte_length = tap_length / 8;
I have attached logs of both rev, as you can see the line of interest for
r1508 is
Debug: 119 218 jlink.c:963 jlink_debug_buffer(): cf 00 08 00 ff 00
and r1509
Debug: 119 249 jlink.c:963 jlink_debug_buffer(): cf 00 07 00 7f 00
Yes, it definetly seems some JLinks dislikes 7 bit transactions, but not
always, not if they are in a good mode after running rev 1188.
We can patch all transactions to be a multiple of 8, but that has a
tendency of driving some arm7/9 targets into a strange state if the
endstate is IDLE, since this is the clock instruction into cpu. For
Cortex targets this is not a problem.
Still it would be very good to know if this is the problem for (at least
some of) the V6 adapters.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] FT2232 libftdi and ftd2xx performance
Hello list The accepted wisdom seems to be that libftdi is slower than ftd2xx, and when performance is low change to ftd2xx. Is this true or a myth ? Two years ago, or three, this was true, today I am not so sure. I have made some small tests , single stepping arm7, uploading medium sized files to arm925ejs and what I can see is that the libftdi is actualyy a touch faster. ( Linux 2.6 Fedora ) Do we have any other hard facts about this question ? Best regárds Magnus ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] On Resets
Michael Bruck wrote: On Tue, May 26, 2009 at 7:47 PM, Magnus Lundin lun...@mlu.mine.nu wrote: Spencer Oliver wrote: If you define your interface with only srst then the software method will be used. Well it did last time i checked - see jtag_add_reset for code. That code makes a move to TLR. This method is fine when you know in which state you are, but not when OpenOCD is started and the previous TAP state is undefined. I have not dug into jtag.c for a while, i am pretty sure it was not the case. it was a few years back however that this support was originally added. Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development move to TLR works for all current states. It is 7 steps with TMS high, that takes you to TAP_RESET froma any starting state. Moving to TLR from an *unknown* state doesn't work because we pretend that there is no such thing as the TAP being in an unknown state. We rather initialize the boot state to be TAP_RESET. Which is not only false but also leads low level drivers to believe that nothing needs to be done. In particular the ft2232 driver says statemove TAP_RESET - TAP_RESET is redundant and does not need to be executed (see ft2232_execute_statemove() ). I have not had time look look closely into this but I think that what must be decided is the exact semantics of state_move(end_state) - Is it, as I think it should be : move to end_state, and if we are already there do nothing ? Then the tlr call should be implemented , in jtag.c, with a path_move of 7 tms=1 steps. This should work for all start states. And it easy to implement and test witout major disruptions. Definetly possible for 0.2.0 Regards Magnus - ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] On Resets
Michael Schwingen wrote: Magnus Lundin wrote: Michael Bruck wrote: On Tue, May 26, 2009 at 7:47 PM, Magnus Lundin lun...@mlu.mine.nu wrote: move to TLR works for all current states. It is 7 steps with TMS high, that takes you to TAP_RESET froma any starting state. Moving to TLR from an *unknown* state doesn't work because we pretend that there is no such thing as the TAP being in an unknown state. We rather initialize the boot state to be TAP_RESET. Which is not only false but also leads low level drivers to believe that nothing needs to be done. In particular the ft2232 driver says statemove TAP_RESET - TAP_RESET is redundant and does not need to be executed (see ft2232_execute_statemove() ). I have not had time look look closely into this but I think that what must be decided is the exact semantics of state_move(end_state) - Is it, as I think it should be : move to end_state, and if we are already there do nothing ? I think in case of TAP_RESET, an exception to that rule might be useful. Would it make sense to define that a driver has to make sure a requested TAP_RESET end state really ends in TAP_RESET state, regardless of the previous state, ie. the driver needs to always perform the necessary number of clocks with TMS=1 without any clever optimizations? That way, upper layers would have an easy way to re-synchronize state even if openocd and the target do not agree on what the current state is. I see your point and I basically agree, the problem is that state_move uses the state move table(s), that currently do use 7 step reset-reset transitions, but there is no contract for this. I also dislike the idea of having to put exceptions like this in the interface drivers. I think we also should look into how jtag_add_runtest is handled because this is a similar situation where we want to reach a certain endstate and then guarante a certain number of transitions in this state. Best regards Magnus ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] run algorithm problems - and irq fiq
Duane Ellis wrote: I have a observation/question When run algorithm occurs - what/where - etc are interrupts disabled? int arm7_9_debug_entry(target_t *target) Look for buf_set_u32(dbg_ctrl-value, EICE_DBG_CONTROL_INTDIS, ... and the debug_execution flag. For instance: Looking at for instance the armv7 code to blank check a flash. No where does that code *disable* interrupts (grep for erase_check_code) Does something do that? I don't see it. Same for arm7/9. I seem to be missing something.. -Duane. ___ 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] JTAG, FT2232 and JLink
Dick Hollenbeck wrote: Magnus Lundin wrote: Hi I was testing the state move work fronm Dick H. when there were a lot of changes in the codebase. As you know I keep working from the same base . There were some problems remaining so I have waited to send the results, but I hope I found most of them now. Here comes my patch. Best regards Magnus New jtag statetables in ft2232 and jlink The parts concering jtag state tables and transitions are from Dick Hollenbeck Some more 7 bit assumptions found in ft2232_add_scan() ft2232_read_scan() In order to work stably with unknown lengths for the last transition out of SHIFT ft2232, for IN and IO scans we now always two steps from SCAN - EXIT1 - PAUSE, to collect the final scanbit, before calling state_move to reach end state. This is the saame behaviour as in JLink driver Nice catch. This was a single bug, not actually two bugs. However this is not the only solution. This solution breaks the contract that the API would like to honor by ignoring the endstate parameter for the cases where the end state is DRSHIFT or IRSHIFT. If there is another way to solve the problem that does not do this, then would it not be superior? No, there is a separate check to se if endstate is SHIFT, and then all data is transferred with Clock Data Bits and we never leave the SCAN state. But the JLink driver does not handle this situation correctly. Regards Magnus ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] remove cmd_queue_cur_state
Dick Hollenbeck skrev: Zach, I think this patch is fundamentally wrong and is a disaster the moment it is applied. The queue sits between the jtag api and the drivers. The api calls track future state according to the most recent api call submitted (and put onto the back end of the queue) via the cmd_queue_cur_state variable. The drivers consume commands in batch mode off the back end of the queue. They have their own notion of state, and that is what the cable helper API is for. That API has that name deliberately so that you know these functions are for cable drivers, not for the jtag api layer. Rather than worrying about a future state, they are worrying about current state of the taps as the driver actually manipulates TMS and the clock. Right, but the situation where this came up is when the tap state, or actually the target jtag controller changes state and the drivers must be informed about this. We cannot use cmd_queue_cur_state for this since it only records the state for sanity checking. We can add a jtag_add_forced_set_state or someting similar. Or we can do a jtag_execute_queue to flush the command queue and then a tap_set_state(). These two concepts are separate, and cannot be merged because of the queue. tap_set_state() is for current state of the taps. But realize there is can be some delay here also because sometimes their are low level commands buffered before being sent out on USB. So tap_set_state() only tracks to the best of its ability the current state. Dick Best regards Magnus ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Correct script to flash the lpc-2148
Hi
This looks like a reset problem, not a write to flash problem. This is
the type of problems we are trying fix with the latest jtag/jlink/ft2232
patches.
What is the target configuration.
Best regards
Magnus
Xiaofan Chen skrev:
Relative long email.
I have not tried to use flashing so far. So today I tried to learn how to
flash the LPC2148 on board of the Olimex LPC-P2148.
I tried to halt the target and then use
flash write_image isoc_io_sample.hex 0x0 ihex but this does
not seem to work. Then I tried to use the following script from psas
(in part or in full, dcc or non-dcc)
http://www.linuxjournal.com/article/10421
#*
# open ocd (on chip debugger) script to flash lpc2148
# 'info .../OCD/src/openocd/doc/openocd.info'
# 3 is most. 0 is least info.
debug_level 1
# stop
reset halt
# log file
log_output write_flash.log
# pause...500mS
sleep 500
# current state
poll
# Force ARM7 into supervisor mode
reg cpsr 0x13
# mww: Memory word write
# Set the MEMMAP reg to point to flash (avoids problems while trying to flash)
mww 0xE01FC040 1
###
# * arm7_9 dcc_downloads ENABLE|DISABLE Enable the use of the debug
# communications channel (DCC) to write larger (128 byte) amounts
# of memory. DCC downloads offer a huge speed increase, but might be
# potentially unsafe, especially with targets running at a very low
# speed. This command was introduced with OpenOCD rev. 60.
arm7_9 dcc_downloads enable
# Wait for target to enter debug mode. Default time is 5ms.
wait_halt
# pause
sleep 10
# current state
poll
# identify the flash
flash probe 0
# erase first bank only:
flash erase_sector 0 0 26
# pause
sleep 20
# memory display halfword from address [COUNT]
mdh 0x0 30
# pause
sleep 20
###
# * flash write_image [ERASE] FILE [OFFSET] [TYPE] Write the image
# FILE to the current target's flash bank(s). A relocation
# [OFFSET] can be specified and the file [TYPE] can be specified
# explicitly as `bin' (binary), `ihex' (Intel hex), `elf' (ELF file)
# or `s19' (Motorola s19). Flash memory will be erased prior to
# programming if the `erase' parameter is given.
flash write_image isoc_io_sample.hex 0x0 ihex
#flash write_image serial.hex 0x0
#flash erase write_image serial.hex 0x0
#flash write_image serial.elf 0x0 elf
#flash write_image serial.hex 0x0 ihex
#flash write_image serial.bin 0x0 bin
# pause
sleep 20
# memory display halfword from address [COUNT]
mdh 0x0 30
# pause
sleep 20
# can't verify because of 0x14 reserved chksum address (LPC SPEC)
#verify_image serial.hex 0x0 bin
# memory display halfword from address [COUNT]
mdh 0x0 30
# pause
sleep 20
#reset run_and_halt
reset
halt
# pause
sleep 10
# stop the open ocd daemon.
#shutdown
#*
The flashing seem to be successful but the target is not working.
target state: halted
target halted in ARM state due to debug-request, current mode: System
cpsr: 0x805f pc: 0x088c
cpsr (/32): 0x0013
dcc downloads are enabled
target state: halted
target halted in ARM state due to debug-request, current mode: Supervisor
cpsr: 0x0013 pc: 0x088c
flash 'lpc2000' found at 0x
erased sectors 0 through 26 on flash bank 0 in 0.256274s
0x:
0x0020:
wrote 8036 byte from file isoc_io_sample.hex in 1.586009s (4.948053 kb/s)
0x: f018 e59f f018 e59f f018 e59f f018 e59f f018 e59f
e1a0 fff0 e51f f014 e59f
0x0020: 0040 00e4 00e0 00e4 00e4 00d8
00dc
0x: f018 e59f f018 e59f f018 e59f f018 e59f f018 e59f
e1a0 fff0 e51f f014 e59f
0x0020: 0040 00e4 00e0 00e4 00e4 00d8
00dc
This error appears after reset command
Error: invalid mode value encountered
Error: cpsr contains invalid mode value - communication failure
Runtime error, file oocd_flash_lpc2148.script, line 96:
Warn : DBGACK set while target was in unknown state. Reset or
initialize target.
Error: invalid mode value encountered
Error: cpsr contains invalid mode value - communication failure
Warn : DBGACK set while target was in unknown state. Reset or initialize
target.
... (keeps the same error)
After this error, I have to unplug everything and then use lpc21isp
to flash the target so that I can run OpenOCD again with J-Link V3.
I know the hex is correct since the target works when flashing
with lpc21isp. The hex file is built from the lpcusb project and
tested with the Linux host program from psas.
What is the correct step to flash the LPC2148?
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Broken r1870 (head)
Dirk Behme skrev: Zach Welch wrote: On Fri, 2009-05-22 at 10:57 +0200, Øyvind Harboe wrote: Trying again... My editor is screwing things up with whitespace, hence all those irrelevant changes... The second attempt was no better. Here it is done right. First, thanks for helping with this patch! Second, I'm slightly confused about the direction this discussion takes, so I'd like to summarize. Just to get it right, and maybe to be corrected (clarified?) ;) The issue we talk about is that somewhere between r1865 and r1870 a check was added to detect dealing with non-enabled TAP's (here omap3.cpu). Ok, this is fine. This shows that OMAP3 init scripts are broken (they worked fine until ~r1865). So we have to fix OMAP3 init code. Right? Trying to do so I discovered a deadlock https://lists.berlios.de/pipermail/openocd-development/2009-May/007039.html For this, we got the answer [OMAP3 init scripts have to be] implemented correctly and We may need to iron out a few issues in OpenOCD Asking then how to do OMAP3 init scripts correctly https://lists.berlios.de/pipermail/openocd-development/2009-May/007044.html the answer was https://lists.berlios.de/pipermail/openocd-development/2009-May/007048.html omap3_dbginit should be made part of the reset sequence and the patch we now talk about here. As the OMAP3 init scripts seem to be wrong all the time we have them now, my expectation was to get some help with fixing OMAP3 scripts. So my expectation was something like a fix for OMAP3 scripts or at least some pseudo code what to do with OMAP3 scripts. Sorry, but it seems that I'm no OpenOCD scripting expert to be able do everything meaningful with just omap3_dbginit should be made part of the reset sequence. That OMAP3 scripts are broken all the time might already give a hint for this ;) But instead of some more help with fixing broken OMAP3 scripts, we got patch in attachment. Sorry if it's wrong, but it seems to me that this patch only gives better error message for the already known issue OMAP3 deals with non-enabled TAP? But it doesn't help to fix the real issue (OMAP3 scripts broken)? Sorry if I misunderstood anything. This mail is for clarifying it then :) Best regards Dirk ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development My ideas are as follows, (this is from memory so detaills should be checked) We cannot examine a target connected to a disabled tap, this check can be done by the target, cortex_m3_examine() , but also in target.c:target_examne. After the tap has been enabled we must examine the target in order to do any useful work, here we can use the arp_examine command, this is placed in omap3_dbginit after tap handling and before actual target commands. Best regards Magnus ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Being careful not to brake anything is good but ...
Common people So much soul searching about a oneliner in jtag.c . Setting the current tap state with cmd_queue_cur_state = TAP_RESET is an obvious error as 5 minutes of code inspection in jtag.c will show you. The variable is not used in any dr/ir scan code, It is only used in jtag_add_path_move to find the start state, and for sanity check in jtag_add_clocks. It will be overwritten by the next call to jtag_prelude by any ir/dr scan, and all driver code uses tap_get_state() instead. Actually ALL uses of cmd_queue_cur_state should be retired and replaced by correct accessor function tap_get_state(), as it is now we have two variables tracing the current tap state, cmd_queue_cur_state and state_follower. I am not saying that nothing will change from this, it most probably will, but the old code is broken and perhaps it is time to fix it. Have a nice weekend Magnus ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD and different versions of J-Link
Zach Welch wrote: On Sat, 2009-05-23 at 00:18 +0200, Magnus Lundin wrote: Zach Welch wrote: On Tue, 2009-05-19 at 16:53 +0200, Magnus Lundin wrote: Hi Info : J-Link compiled Feb 20 2006 18:20:20 -- Update -- Info : JLink caps 0x3 Error: J-Link command EMU_CMD_GET_MAX_MEM_BLOCK failed (-110) Open OCD seems to get reasonable ansvers from first two JLink commands. The /* query hardware maximum memory block */ should not be run for this version, I had removed it in my patch. Next patch will use results from JLink caps to select what info to query. I am waiting for more info from Segger about version diffrences and endpoints. How are we doing with this patch? It looks like we have made some good progress this week, so I don't want the effort to stall. What are the thoughts about committing your latest version? Even if more changes may be pending, it seems that your work has improved things for folks with some devices, so I think we have made constructive progress from where we were before now. If nothing else, we should get some more testing feedback. ;) Cheers, Zach There is a set of new patches that has been tested by Michael Fischer, as far as i know there were no problems. There are still things that should be fixed in the resethandling in jtag_add_reset and minimizing the differences between ft2232 and jlink behaviour. But still would suggest that the following patcches are commited. They are not untested. I will apply them here and see if they magically cure my own woes. Regardless, I think these changes should be committed in some for, though I can see various ways that I would like to clean your code. Would you mind my taking a pass over them before I commit them? Sure, I am out of style discussions on this list. Incidentally, do you think this might also solve the problem that was just reported by Dylan Reid? I have cc'd him in the hope that he will try your patches and report the latest results. It should help, but from the info given it is hard to tell what actually broke. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Making all jtag controllers behave equally
Hi Now when we have almost got the new state table infrastructure in plaec and working it is time to think ahead. Shall we retire the 7 step transitions ? No ! expand the founctionallity to allow user (target) defined state transition tables, the current code allows that. Maybe not the default and not recommended for casual users but - Why limit the possibilities ?? Make all jtag interfaces behave as similar as possible ! Perhaps the most problematic is reset handling. Interface jtag reset command handlers should ONLY do one thing: - set hw rst and trst lines to desired state, if necessary execute jtag communications Upper Jtag layer (jtag.c) handles ALL logic about - flushing command queues - setting TAP_RESET state when trst is asserted, adding extra state_move(RAT_RESET) , handling srts_pulls_trst logic etc. This is logic is already confusing and doing it in several places even more so. Just some ideas. Have a nice evening Magnus ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] RPM Build
Dean Glazeski wrote: Magnus Lundin wrote: Dean Glazeski wrote: openocd.x86_64: E: statically-linked-binary /usr/lib64/openocd/ecos/at91eb40a.elf openocd.x86_64: E: missing-PT_GNU_STACK-section /usr/lib64/openocd/ecos/at91eb40a.elf openocd.x86_64: W: devel-file-in-non-devel-package /usr/share/openocd/contrib/libdcc/example.c openocd.x86_64: W: devel-file-in-non-devel-package /usr/share/openocd/contrib/libdcc/dcc_stdio.c openocd.x86_64: W: devel-file-in-non-devel-package /usr/share/openocd/contrib/libdcc/dcc_stdio.h openocd.x86_64: W: file-not-utf8 /usr/share/info/openocd.info.gz I think : The libddc files are for building target dcc implementations, and nothing in this list is used by the actual running openocd image on fedora. So this is really reference materials for developers. That might help you decide where to place them. Does this mean I can just remove them and be happy? Doing that definitely makes my life much simpler ;). Unless I hear otherwise, I'll rebuild the RPM without these later tonight (its 7pm where I'm at) and I'll throw the RPM up for review with Fedora tomorrow. Thanks! // Dean Glazeski I have no strong opinion but probably they should be included and go somewhere like /usr/lib/openocd/share/contrib or /usr/share/openocd/contrib/. In the neighboorhood of where all the target cfg files live . This is a bit dictated by Fedora policies. Regards, Magnus ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Short state table enabled as of r1827
Øyvind Harboe wrote: On Tue, May 19, 2009 at 8:53 AM, Spencer Oliver s...@spen-soft.co.uk wrote: Does the LPC2148 (which I have) exhibit the same problem? I can not test the attached patch here, but it is intended to allow switching between the long(old) or new (short) tms_sequence tables. The patch uses the short table as default. Try: tms_sequence long tms_sequence short Just checked with a luminary target i had to hand. Using tms_sequence long fixes the error's seen during the first jtag_examine_chain call. Could this be a missing jtag_add_pathmove()? We want to make OpenOCD robust against the particular path taken do we not? This is black jtag controller magic, I have tested short table for imx21 and omap3530 a lot, seems cortex-m3 does not like the startup sequences. Try to change the first row in the short table, the out from TAP_RESET to the long version. This will not affect performance but give some extra tck clocks in reset. Some target really like that. Have a nice day Magnus ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD and different versions of J-Link
Following patch reads the endpoint numbers from the usb lib device
structure, and it removes some of the extra testing that breaks older
versions of JLink.
This should improve the situation.
Hopefully the same trick works under win and mac os.
Have a nice day
Magnus
Index: src/jtag/jlink.c
===
--- src/jtag/jlink.c (revision 1834)
+++ src/jtag/jlink.c (working copy)
@@ -36,9 +36,12 @@
#define JLINK_WRITE_ENDPOINT 0x02
#define JLINK_READ_ENDPOINT 0x81
+unsigned int jlink_write_ep = JLINK_WRITE_ENDPOINT;
+unsigned int jlink_read_ep = JLINK_READ_ENDPOINT;
+
#define JLINK_USB_TIMEOUT 1000
-// See Section 1.3.2 of the Segger JLink USB protocol manual
+/* See Section 1.3.2 of the Segger JLink USB protocol manual */
/* 2048 is the max value we can use here */
//#define JLINK_TAP_BUFFER_SIZE 2048
#define JLINK_TAP_BUFFER_SIZE 256
@@ -543,7 +546,7 @@
{
int result;
int len;
- u32 jlink_caps, jlink_max_size;
+ u32 jlink_caps;
/* query hardware version */
jlink_simple_command(EMU_CMD_VERSION);
@@ -579,21 +582,6 @@
jlink_caps = buf_get_u32(usb_in_buffer, 0, 32);
LOG_INFO(JLink caps 0x%x, jlink_caps);
-
- /* query hardware maximum memory block */
- jlink_simple_command(EMU_CMD_GET_MAX_MEM_BLOCK);
-
- result = jlink_usb_read(jlink_jtag_handle, 4);
- if (4 != result)
- {
- LOG_ERROR(J-Link command EMU_CMD_GET_MAX_MEM_BLOCK failed (%d)\n, result);
- return ERROR_JTAG_DEVICE_ERROR;
- }
-
- jlink_max_size = buf_get_u32(usb_in_buffer, 0, 32);
- LOG_INFO(JLink max mem block %i, jlink_max_size);
-
-
return ERROR_OK;
}
@@ -661,7 +649,7 @@
int bit_index = tap_length % 8;
u8 bit = 1 bit_index;
- // we do not pad TMS, so be sure to initialize all bits
+ /* we do not pad TMS, so be sure to initialize all bits */
if (0 == bit_index)
{
tms_buffer[index] = tdi_buffer[index] = 0;
@@ -814,6 +802,24 @@
*/
usb_set_altinterface(result-usb_handle, 0);
#endif
+int i;
+for (i =0 ; idev-config[0].interface[0].altsetting[0].bNumEndpoints; i++)
+{
+ u8 epnum = dev-config[0].interface[0].altsetting[0].endpoint[i].bEndpointAddress;
+ {
+ if (epnum0x80)
+ {
+ LOG_DEBUG(usb ep in %02x,epnum);
+ jlink_read_ep = epnum;
+ }
+ else
+ {
+ LOG_DEBUG(usb ep out %02x,epnum);
+ jlink_write_ep = epnum;
+ }
+ }
+}
+
return result;
}
}
@@ -937,7 +943,7 @@
return -1;
}
- result = usb_bulk_write_ex(jlink_jtag-usb_handle, JLINK_WRITE_ENDPOINT,
+ result = usb_bulk_write_ex(jlink_jtag-usb_handle, jlink_write_ep,
(char *)usb_out_buffer, out_length, JLINK_USB_TIMEOUT);
DEBUG_JTAG_IO(jlink_usb_write, out_length = %d, result = %d, out_length, result);
@@ -951,7 +957,7 @@
/* Read data from USB into in_buffer. */
static int jlink_usb_read(jlink_jtag_t *jlink_jtag, int expected_size)
{
- int result = usb_bulk_read_ex(jlink_jtag-usb_handle, JLINK_READ_ENDPOINT,
+ int result = usb_bulk_read_ex(jlink_jtag-usb_handle, jlink_read_ep,
(char *)usb_in_buffer, expected_size, JLINK_USB_TIMEOUT);
DEBUG_JTAG_IO(jlink_usb_read, result = %d, result);
@@ -965,7 +971,7 @@
/* Read the result from the previous EMU cmd into result_buffer. */
static int jlink_usb_read_emu_result(jlink_jtag_t *jlink_jtag)
{
- int result = usb_bulk_read_ex(jlink_jtag-usb_handle, JLINK_READ_ENDPOINT,
+ int result = usb_bulk_read_ex(jlink_jtag-usb_handle, jlink_read_ep,
(char *)usb_emu_result_buffer, 1 /* JLINK_EMU_RESULT_BUFFER_SIZE */,
JLINK_USB_TIMEOUT);
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD and different versions of J-Link
Hi Info : J-Link compiled Feb 20 2006 18:20:20 -- Update -- Info : JLink caps 0x3 Error: J-Link command EMU_CMD_GET_MAX_MEM_BLOCK failed (-110) Open OCD seems to get reasonable ansvers from first two JLink commands. The /* query hardware maximum memory block */ should not be run for this version, I had removed it in my patch. Next patch will use results from JLink caps to select what info to query. I am waiting for more info from Segger about version diffrences and endpoints. Have a nice day, Magnus ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD and different versions of J-Link
The following patch combines my previous patch with most of Ben's patch.
It can use both EMU_CMD_HW_JTAG2 and EMU_CMD_HW_JTAG3
It defaults to EMU_CMD_HW_JTAG2 so it should work with all interfaces
but EMU_CMD_HW_JTAG3 is recommended by SEgger, you can change the
behaviour with
jlink_hw_jtag 3
or
jlink_hw_jtag 2
Autodetection can be done when we know which versions JLink can use what
setting, (-d3 logs of setup messages )
Have a nice day
Magnus
Xiaofan Chen wrote:
On Wed, May 20, 2009 at 12:53 AM, Gene Smith g...@chartertn.net wrote:
OK, one more reply to self...
Using the Magnus patch, I just noticed that after openocd starts the
jlink LED goes off indicating further USB comm is not possible (it seems
to be true) and telnet cmds fail. If I try to restart oocd, I again get
the 3 failed retries on get caps and don't worry like before. If I
revert to Benjamin's patch, it comes up clean with no errors. Now I can
do telnet commands with no problem (such as jlink_info, mdb, reg, etc).
Possibly the intention was to combine these patches, I am not sure. But
anyhow, for what its worth, it is now seems to be working for me with
Ben's patch. (I have not tried to do anything with gdb yet.)
I can see two big differences between the patches. In Ben's patch,
-#define EMU_CMD_HW_JTAG3 0xcf
+#define EMU_CMD_HW_JTAG3 0xce (maybe this is
EMU_CMD_HW_JTAG2 according to Ben's Mach 16 patch).
/* max speed 12MHz v5.0 jlink */
-#define JLINK_MAX_SPEED 12000 (this is only for V5/6/7/Pro)
+#define JLINK_MAX_SPEED 4000 (this is for V1/2/3/4 according to Segger)
The common thing is to correct the endpoint and remove the
EMU_CMD_GET_MAX_MEM_BLOCK command.
Ben's patch remove more things. I will give it a try after work.
Index: src/jtag/jlink.c
===
--- src/jtag/jlink.c (revision 1834)
+++ src/jtag/jlink.c (working copy)
@@ -36,9 +36,13 @@
#define JLINK_WRITE_ENDPOINT 0x02
#define JLINK_READ_ENDPOINT 0x81
+unsigned int jlink_write_ep = JLINK_WRITE_ENDPOINT;
+unsigned int jlink_read_ep = JLINK_READ_ENDPOINT;
+unsigned int jlink_hw_jtag_version = 2;
+
#define JLINK_USB_TIMEOUT 1000
-// See Section 1.3.2 of the Segger JLink USB protocol manual
+/* See Section 1.3.2 of the Segger JLink USB protocol manual */
/* 2048 is the max value we can use here */
//#define JLINK_TAP_BUFFER_SIZE 2048
#define JLINK_TAP_BUFFER_SIZE 256
@@ -60,6 +64,7 @@
#define EMU_CMD_HW_CLOCK 0xc8
#define EMU_CMD_HW_TMS0 0xc9
#define EMU_CMD_HW_TMS1 0xca
+#define EMU_CMD_HW_JTAG2 0xce
#define EMU_CMD_HW_JTAG3 0xcf
#define EMU_CMD_GET_MAX_MEM_BLOCK 0xd4
#define EMU_CMD_HW_RESET0 0xdc
@@ -67,6 +72,7 @@
#define EMU_CMD_HW_TRST0 0xde
#define EMU_CMD_HW_TRST1 0xdf
#define EMU_CMD_GET_CAPS 0xe8
+#define EMU_CMD_GET_HW_VERSION 0xf0
/* max speed 12MHz v5.0 jlink */
#define JLINK_MAX_SPEED 12000
@@ -82,6 +88,7 @@
/* CLI command handler functions */
static int jlink_handle_jlink_info_command(struct command_context_s *cmd_ctx, char *cmd, char **args, int argc);
+static int jlink_handle_jlink_hw_jtag_command(struct command_context_s *cmd_ctx, char *cmd, char **args, int argc);
/* Queue command functions */
static void jlink_end_state(tap_state_t state);
@@ -301,8 +308,11 @@
static int jlink_register_commands(struct command_context_s *cmd_ctx)
{
+
register_command(cmd_ctx, NULL, jlink_info, jlink_handle_jlink_info_command, COMMAND_EXEC,
query jlink info);
+ register_command(cmd_ctx, NULL, jlink_hw_jtag, jlink_handle_jlink_hw_jtag_command, COMMAND_EXEC,
+ set/get jlink hw jtag command version [2|3]);
return ERROR_OK;
}
@@ -318,6 +328,7 @@
return ERROR_JTAG_INIT_FAILED;
}
+ jlink_hw_jtag_version = 2;
check_cnt = 0;
while (check_cnt 3)
{
@@ -543,7 +554,7 @@
{
int result;
int len;
- u32 jlink_caps, jlink_max_size;
+ u32 jlink_caps, jlink_max_size, jlink_hw_version;
/* query hardware version */
jlink_simple_command(EMU_CMD_VERSION);
@@ -579,21 +590,38 @@
jlink_caps = buf_get_u32(usb_in_buffer, 0, 32);
LOG_INFO(JLink caps 0x%x, jlink_caps);
+ if (jlink_caps (11)) /* EMU_CAP_GET_HW_VERSION */
+ {
+ /* query hardware version */
+ jlink_simple_command(EMU_CMD_GET_HW_VERSION);
- /* query hardware maximum memory block */
- jlink_simple_command(EMU_CMD_GET_MAX_MEM_BLOCK);
+ result = jlink_usb_read(jlink_jtag_handle, 4);
+ if (4 != result)
+ {
+ LOG_ERROR(J-Link command EMU_CMD_GET_HW_VERSION failed (%d)\n, result);
+ return ERROR_JTAG_DEVICE_ERROR;
+ }
- result = jlink_usb_read(jlink_jtag_handle, 4);
- if (4 != result)
- {
- LOG_ERROR(J-Link command EMU_CMD_GET_MAX_MEM_BLOCK failed (%d)\n, result);
- return ERROR_JTAG_DEVICE_ERROR;
+ jlink_hw_version = buf_get_u32(usb_in_buffer, 0, 32);
+ LOG_INFO(JLink hw version %i, jlink_hw_version);
}
- jlink_max_size = buf_get_u32(usb_in_buffer, 0, 32);
- LOG_INFO(JLink max mem
[Openocd-development] JTAG, FT2232 and JLink
Hi
I was testing the state move work fronm Dick H. when there were a lot of
changes in the codebase. As you know I keep working from the same base .
There were some problems remaining so I have waited to send the results,
but I hope I found most of them now.
Here comes my patch.
Best regards
Magnus
New jtag statetables in ft2232 and jlink
The parts concering jtag state tables and transitions are from Dick
Hollenbeck
Some more 7 bit assumptions found in
ft2232_add_scan()
ft2232_read_scan()
In order to work stably with unknown lengths for the last transition out
of SHIFT ft2232,
for IN and IO scans we now always two steps from SCAN - EXIT1 - PAUSE,
to collect the final scanbit,
before calling state_move to reach end state. This is the saame
behaviour as in JLink driver
JLink driver has been tweaked and now runs stable. Buffersizes has been
reduced allowing maximum jtag speed
without killing the Linux usb stack.
There is a change from malloc to calloc in jtag.c:jtag_build_buffer()
This removed most weird errors from JLink+ARM7_9 combinations.
Shortest path state moves has been tested with both drivers against
OMAP3530, STM32, ARM926ejs (imx21), LPC2124
Index: src/jtag/jlink.c
===
--- src/jtag/jlink.c (revision 1606)
+++ src/jtag/jlink.c (working copy)
@@ -44,6 +44,11 @@
#define JLINK_USB_TIMEOUT 1000
// See Section 1.3.2 of the Segger JLink USB protocol manual
+/* 2048 is the max value we can use here */
+//#define JLINK_TAP_BUFFER_SIZE 2048
+#define JLINK_TAP_BUFFER_SIZE 256
+//#define JLINK_TAP_BUFFER_SIZE 384
+
#define JLINK_IN_BUFFER_SIZE 2048
#define JLINK_OUT_BUFFER_SIZE 2*2048+4
#define JLINK_EMU_RESULT_BUFFER_SIZE 64
@@ -57,8 +62,11 @@
#define EMU_CMD_VERSION 0x01
#define EMU_CMD_SET_SPEED 0x05
#define EMU_CMD_GET_STATE 0x07
+#define EMU_CMD_HW_CLOCK 0xc8
+#define EMU_CMD_HW_TMS0 0xc9
+#define EMU_CMD_HW_TMS1 0xca
#define EMU_CMD_HW_JTAG3 0xcf
-#define EMU_CMD_GET_MAX_MEM_BLOCK 0xd4
+#define EMU_CMD_GET_MAX_MEM_BLOCK 0xd4
#define EMU_CMD_HW_RESET0 0xdc
#define EMU_CMD_HW_RESET1 0xdd
#define EMU_CMD_HW_TRST0 0xde
@@ -183,7 +191,7 @@
enum scan_type type;
u8 *buffer;
- DEBUG_JTAG_IO(scan end in %i, cmd-cmd.scan-end_state);
+ DEBUG_JTAG_IO(scan end in %s, tap_state_name(cmd-cmd.scan-end_state));
if (cmd-cmd.scan-end_state != TAP_INVALID)
jlink_end_state(cmd-cmd.scan-end_state);
@@ -206,10 +214,13 @@
jlink_tap_execute();
- if (cmd-cmd.reset-trst == 1)
+ if ( (cmd-cmd.reset-trst == 1) || ( cmd-cmd.reset-srst (jtag_reset_config RESET_SRST_PULLS_TRST) ) )
+ {
tap_set_state(TAP_RESET);
+ }
jlink_reset(cmd-cmd.reset-trst, cmd-cmd.reset-srst);
+ jlink_tap_execute();
}
static void jlink_execute_sleep(jtag_command_t *cmd)
@@ -333,6 +344,7 @@
LOG_INFO(J-Link JTAG Interface ready);
jlink_reset(0, 0);
+ jtag_sleep(3000);
jlink_tap_init();
jlink_speed(jtag_speed);
@@ -367,8 +379,9 @@
int i;
int tms = 0;
u8 tms_scan = tap_get_tms_path(tap_get_state(), tap_get_end_state());
+ u8 tms_scan_bits = tap_get_tms_path_len(tap_get_state(), tap_get_end_state());
- for (i = 0; i 7; i++)
+ for (i = 0; i tms_scan_bits; i++)
{
tms = (tms_scan i) 1;
jlink_tap_append_step(tms, 0);
@@ -409,11 +422,14 @@
tap_state_t saved_end_state = tap_get_end_state();
+ jlink_tap_ensure_space(1,num_cycles + 16);
+
/* only do a state_move when we're not already in IDLE */
if (tap_get_state() != TAP_IDLE)
{
jlink_end_state(TAP_IDLE);
jlink_state_move();
+// num_cycles--;
}
/* execute num_cycles */
@@ -434,7 +450,7 @@
{
tap_state_t saved_end_state;
- jlink_tap_ensure_space(1, scan_size + 8);
+ jlink_tap_ensure_space(1, scan_size + 16);
saved_end_state = tap_get_end_state();
@@ -469,24 +485,23 @@
if (srst == 0)
{
jlink_simple_command(EMU_CMD_HW_RESET1);
- jlink_end_state(TAP_RESET);
- jlink_state_move();
}
- else if (srst == 1)
+ if (srst == 1)
{
jlink_simple_command(EMU_CMD_HW_RESET0);
}
+ if (trst == 1)
+ {
+ jlink_simple_command(EMU_CMD_HW_TRST0);
+ }
if (trst == 0)
{
jlink_simple_command(EMU_CMD_HW_TRST1);
+ jtag_sleep(5000);
jlink_end_state(TAP_RESET);
jlink_state_move();
}
- else if (trst == 1)
- {
- jlink_simple_command(EMU_CMD_HW_TRST0);
- }
}
static void jlink_simple_command(u8 command)
@@ -601,10 +616,8 @@
/***/
/* J-Link tap functions */
-/* 2048 is the max value we can use here */
-#define JLINK_TAP_BUFFER_SIZE 2048
-static unsigned tap_length;
+static unsigned tap_length=0;
static u8 tms_buffer[JLINK_TAP_BUFFER_SIZE];
static u8 tdi_buffer[JLINK_TAP_BUFFER_SIZE];
static u8 tdo_buffer[JLINK_TAP_BUFFER_SIZE];
@@ -631,7 +644,7 @@
static void jlink_tap_ensure_space(int scans, int bits)
{
int available_scans =
Re: [Openocd-development] JTAG, FT2232 and JLink
Øyvind Harboe wrote: I've made a quick attempt at modifying the patch to be against svn head, can't test beyond building it though. This took me a couple of minutes, so this patch is only very slightly different in svn head/1606. Looking at the patch, it occurs to me that from a testing/bisection point of view, it would be possible to break this into a number of patches. This would be *greatly* helpful if we need to go back and check if something subtle broke here... ? Well, the modifications to jtag.c are very minor :) The ft2232 stuff is actually a unit, it will hardly build otherwise (Dick told us so and here he was right) I did not include the 2232h and the reconnect parts, they can (easily) be applied later. The JLink is separate and it will be clear if we are using jlink or ft2232 :) I think you should be happy that I did not include the cortex work in this patch, thats a big one ... Have a great evening Magnus ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Cleanup in target.c
This is some thoughts on cleaning up target.c and specifictarget relations. It is not an architectural change, but rather about consistent use of the one we have. A very common pattern is to have something like this target_halt(target_s *target) . Some common cleanup and sanity checking . calling out to: target-type-halt(target) The consequencies should be that: - the specific targets does not have to do general sanity checking that is not unique for a specific target. - target-type-halt(target) should never be called from any other function than target_halt() - the specific implementation of halt() can be called from within the defining module If you work through these issues I am sure that you can make it easier to implement new targets, where onle the really target spicific thins has to be rewritten. Regards Magnus ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Cleanup in target.c
Øyvind Harboe wrote: I think this makes sense. It is roughly along the lines of using a base class where the subclass implements the guts and the base class implements the fn called by normal users. Along the same lines, Michael Bruck was trying to find a reasonable way to reuse the instruction simulation for arm11 so we could get single stepping support for all arm11 targets... I believe that Zach is trying to round up a 0.2 release soon though. Could be good to do this afterwards. With a 0.2 out of the door, it should be easier to do these sorts of things in svn head. Yes, and no. Many of these changes are only debug messages, so I would categorize them as cleanup without functional impact. So the need to be conservative is rather small here. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
