Re: [OpenOCD-devel] Debug probe hardware that can read/write target memory directly

If I was to re-write a USB protocol for OpenOCD - I would do exactly this. Look very carefully at the SWD commands. The commands are exactly 1 byte + 4 byte read, or 1 byte + 4byte write. The first SWD byte always has bits 7 and 0 set (START + PARK) thus there are really only (256/4)=64 possible

Re: [OpenOCD-devel] Debug probe hardware that can read/write target memory directly

ed>> Keep in mind this is a full speed device, not high speed. Cutting down on the number of USB packets needed does help considerably. Full vrs High speed is not important here. Better: draw a timeline of the USB traffic of actual usb traffic captured on the wire and work on fixing that. I a

Re: [OpenOCD-devel] Python API for supplying thread information?

Hi - I’ve been following this thread A while ago - I proposed a very different architecture that would solve a lot of this. Fundamentally, there are two processes: (A) The GDB process and (B) the GDBSERVER process. When debugging an application that runs under a true OS (such as linux) this

Re: [OpenOCD-devel] OpenOCD AArch64 support

>> What might (should?) work in my particular case is, since I'm starting from >> EL2: >> >> - Modify SPSR_EL2, setting bit 4 = 1 and bits 3:0 to some valid aarch32 mode >> (0x3 - svc mode) >> - set ELR_EL2 to a memory location with valid ARM code >> - "ERET" > > OK it "somewhat" worked. I get t

Re: [OpenOCD-devel] QCA IPQ8064

> Yes, thank you. I have corrected for that. Now I'm wondering why the > scan seems to be dying before the end of the ROM table. Why would that > happen? > Could be many different reasons - these will never be fixed. 1) Because the ROM table is full of bugs. 2) There are “hidden features”

Re: [OpenOCD-devel] cmsis_dap: choosing between jtag and swd transport

> On Feb 24, 2016, at 11:40 AM, Phillip Pearson wrote: > > I believe that's someone's STM32 port of the CMSIS-DAP firmware. Here's the > most official looking version I could find :) It is my understanding ARM gives the source code away for free - the official version can be found here htt

Re: [OpenOCD-devel] DAP handling for Cortex-A

> > Speaking of confusing nomenclature, what is a "DAP target" even? Also you > keep on using the term "dap port" which doesn't exist in ADIv5. I think you > mean AP. On an platform with more then 1 DAP you have Dap(X).AccessPort(Y) when I refer to a “Dap Port” - I generally mean an access por

Re: [OpenOCD-devel] DAP handling for Cortex-A

> > You got it wrong, this is a Tcl variable, you can call it whatever you like. > For this example, it's an excellent name. I’m quite familiar with it being a TCL Variable, I was the original author of this feature in OpenOCD. perhaps I should say it differently, inside of openocd - the code

Re: [OpenOCD-devel] DAP handling for Cortex-A

> > > Maybe you could explain how you envision the user to interact with the dap > > > object and with 'mww' and 'mdw’. > > $soc.ahb mdb 0xdeadbeef <- using mem_ap_read() on ap 0 First off: Stop with the names like: “$soc.ahb” - that is not a very good name Reason - There can

Re: [OpenOCD-devel] DAP handling for Cortex-A

As I described earlier about the DAP… >> http://sourceforge.net/p/openocd/mailman/openocd-devel/thread/20150428234557.8376.qm...@stuge.se/ >> >> There are many problems with the DAP, and the gene

Re: [OpenOCD-devel] Possible GPL violation - System Workbench for STM32 (aka AC6)

>> It would have been decent to give hime some time to >> respond. > > Did I do something wrong here? > You did the correct thing by keeping vigilant and looking for things. Thanks for keeping your eye ball open. I wish we had somebody to keep track of the Russian, China and Korea sites (as

Re: [OpenOCD-devel] I2C and JTAG

> Is it possible( or common) to use I2C bus to halt a CPU and work in a > similar way as that > with JTAG? > Broadcom uses I2C bus to ( probably) halt CPU, but I am not sure if it is a > real JTAG > condition or just a virtual JTAG condition. I presume you are new to JTAG based debugging.

Re: [OpenOCD-devel] Findind out maximun JTAG/SWD frequency

>> I googled for some time, but couldn't find hard number what restrictions for >> the JTAG/SWD frequency apply. I was the source of the original (CLK/6) in the documetation - it is a simplification that makes it easier for people to get correct without much reading and technical understandin

Re: [OpenOCD-devel] tcl script

Not today. Solution: Add a sub command to the target object command, 1) re-impliment the handle_reg_command as a JIM command. http://sourceforge.net/p/openocd/code/ci/master/tree/src/target/target.c#l2444

Re: [OpenOCD-devel] RFC: unified trace featutre

This is not a simple thing and is not something you really want to do with wireshark directly, indirectly yes - but not directly. OpenOCD should provide only the means to extract (download) the captured trace data from the ETB (more correctly, the TMC - trace memory controller) and create a fi

Re: [OpenOCD-devel] Cortex A/M - DAP crazyness

> The tap structure is still not a good place to have it. There are better > places. Look at http://openocd.zylin.com/2137 where I just pushed some > proof-of-concept code (i.e. at least it compiles) to show what I'm after. > We don’t disagree about the long term solution, what we disagree abo

Re: [OpenOCD-devel] Cortex A/M - DAP crazyness

> andreas> No I mean TARGETID as defined by ADIv5.2, which must be known to be > able to select a device on a multidrop SWD link. Ok, i see the confusion. The TARGETID - as define by ARM, is identical to the JTAG-TAP-ID in style and format, thus in my mind the TARGETID = TAPID, but that is not

Re: [OpenOCD-devel] Cortex A & M - issue = assumed DAP access ports

duane>> [ suggest: means to specify the DEBUG and MEM ap ports for a core, without using ROM tables and hard coding] Paul.Fertser>> [ Lots of back and forth with duane about this ] My ask right now is: I believe this idea is good to move forward on - asking for confirmation. Note: Paul

Re: [OpenOCD-devel] Cortex A/M - DAP crazyness

JTAG_TAP linked list. This looks like changes localized in the interface layer. - But that would be future work (addressed when the dap-jtag-ap is supported) -Duane. On May 4, 2014, at 12:08 PM, Andreas Fritiofson wrote: > > > On Sat, May 3, 2014 at 7:42 AM, Duane Ellis wro

Re: [OpenOCD-devel] Cortex-M3 - Issue: BKPT_TYPE_BY_ADDRESS()

duane>> [[ started this: about creating a memory range to determine breakpoints, because CortexM macro is wrong headed ]] Freddie>> [[ points out using the flash memory area … ]] duane>> [ That means the target has to be probed - cannot always probe ] duane>> [ Not all targets have a “flash driv

Re: [OpenOCD-devel] Cortex-M3 - Issue: BKPT_TYPE_BY_ADDRESS()

On May 4, 2014, at 12:12 PM, Andreas Fritiofson wrote: > Well, actually I think that it's common to put the minimum sram size for the > family in the config file. Look at the stm32 configs for example. > Stated another way, the openocd configuration file states MEM_RANGE( ST

[OpenOCD-devel] splitting Openocd into parts, scripting, GUIs etc

Changing the subject line to reflect a very different chain of thought On May 3, 2014, at 11:43 PM, Paul Fertser wrote: >> Are you familiar with Rube Goldberg Designs … A very american >> cartoon. (British may recognize: W. Heath Robinson) > > Hehe, fascinating. I hope my proposal to have an o

Re: [OpenOCD-devel] Cortex A & M - issue = assumed DAP access ports

On May 3, 2014, at 11:15 PM, Paul Fertser wrote: >> >> The platform may have 8 cpus. I do not want to connect and attach, >> and probe every single CPU. Perhaps I only want to connect and >> attach to the (NTH) cpu. >> >> With auto discovery, how do I tell the system to *SKIP* a specific >>

Re: [OpenOCD-devel] Cortex A/M - DAP crazyness

On May 3, 2014, at 7:42 AM, Paul Fertser wrote: That DAP with other processors via the JTAG_AP port. >>> >>> What if OpenOCD would expose JTAG_AP ports via a regular socket with a >>> JTAG-level protocol >> >> It should provide a standalone tap-struct - just like all of the >> other

Re: [OpenOCD-devel] Cortex A & M - issue = assumed DAP access ports

On May 3, 2014, at 7:48 AM, Paul Fertser wrote: >>> >> Multi level ROM tables (not currently supported), and ROM tables >> with bugs (no HW guys have have bugs, its only us SW guys right?) >> they may never get fixed. > > Displaying of nested ROM tables is already available in 0.8.0, dbgbase >

Re: [OpenOCD-devel] Cortex-M3 - Issue: BKPT_TYPE_BY_ADDRESS()

On May 3, 2014, at 8:42 AM, Paul Fertser wrote: > On Sat, May 03, 2014 at 07:03:18AM -0700, Duane Ellis wrote: >> >> On May 3, 2014, at 12:20 AM, Paul Fertser wrote: >>> >>>> Could write a new function - something like: >>>> flash_IsThisAd

Re: [OpenOCD-devel] Cortex-M3 - Issue: BKPT_TYPE_BY_ADDRESS()

On May 3, 2014, at 12:20 AM, Paul Fertser wrote: > >> Could write a new function - something like:flash_IsThisAddressInFlash( >> target_pointer, ADDRESS ) this would *NOT* probe anything >> Do you see a problem with assuming the “flash address range” is always valid >> if not auto-prob

Re: [OpenOCD-devel] Cortex A & M - issue = assumed DAP access ports

On May 2, 2014, at 11:30 PM, Paul Fertser wrote: > Hi, > > On Wed, Apr 30, 2014 at 01:59:36PM -0700, Duane Ellis wrote: >> * The Cortex A code sometimes cannot discover the correct AP ports > > Do you have an example of when it happens and how? Multi level ROM tables (no

Re: [OpenOCD-devel] Cortex A/M - DAP crazyness

, 2014 at 10:42:15PM -0700, Duane Ellis wrote: >> On Apr 30, 2014, at 11:27 PM, Duane Ellis wrote: >>> BTW - also need a solution for a JTAG tap that is accessed via the DAP -> >>> JTAG_AP interface.. >>> >>> ie: Openodd -> inte

Re: [OpenOCD-devel] Cortex A/M - DAP crazyness

On Apr 30, 2014, at 11:27 PM, Duane Ellis wrote: > duane>> In the “TAP” structure - add a “DAP” pointer > > andreas> No, target->tap is JTAG specific. An SWD only setup should not need > to have a tap pointer. > > That’s a problem - Please thing about a

Re: [OpenOCD-devel] Cortex-M3 - Issue: BKPT_TYPE_BY_ADDRESS()

Freddie>> [[ use the flash bank info ]] duane>> I don’t see where OpenOCD knows this. Paul>> target with supported flash you already have "flash bank …" Thanks that helped me find the link. There are two lists List (TARGET) - the list of all targets, and List(FLASHBANKS) They are not directly

Re: [OpenOCD-devel] Cortex-M3 - Issue: BKPT_TYPE_BY_ADDRESS()

duane>> And associated configure commands at the generic target level to configure this manually? Freddie> But if the distinction is related only to memory type (flash/RAM) there is no need for a new commands - OpenOCD knows where the flash is… I don’t see where OpenOCD knows this. As I rememb

Re: [OpenOCD-devel] Cortex-M3 - Issue: BKPT_TYPE_BY_ADDRESS()

Freddie> Wouldn't it be better to just have a generic solution for all the targets I presume you mean adding a breakpoint type/range structure to struct target? And perhaps an accessor function: bkpt_type = target_bkpt_by_address( struct target *pTarget, TARGET_ADDRESS ); And asso

Re: [OpenOCD-devel] Cortex A/M - DAP crazyness

duane>> In the “TAP” structure - add a “DAP” pointer andreas> No, target->tap is JTAG specific. An SWD only setup should not need to have a tap pointer. That’s a problem - Please thing about a solution. BTW - also need a solution for a JTAG tap that is accessed via the DAP -> JTAG_AP

[OpenOCD-devel] Cortex A/M - DAP crazyness

This is another cortex-A/M change There are multiple “dap” data structures in a few places - and there are pointers to them in others. This is problematic if there are multiple users of the same DAP For example a Cortex A and Cortex M … Example - There is a mem

[OpenOCD-devel] Cortex-M3 - Issue: BKPT_TYPE_BY_ADDRESS()

There are a number of wrong assumptions in the CortexM3 code that I am proposing to fix. This is one of them - there are others - I’m keeping them in separate emails so that they can be discussed separately. Corex_m.c - line 59 - Assumes that any address < 0x2000 => Flash memory and is har

[OpenOCD-devel] Cortex A & M - issue = assumed DAP access ports

Another one of the cortex M series issues * The Cortex M code assumes that the DAP ports are rather fixed. * The Cortex A code sometimes cannot discover the correct AP ports * The current code does not support mixed cortexA and cortexM on the same DAP (below det

Re: [OpenOCD-devel] multi-core status

>> And yes, every target should get its own gdb port and gdb context, and that >> is already implemented. yea, it seems to support this. It’s just a giant super loop. >> if that target smp line is commented out. I think current ‘target amp’ is wrong headed, in that it marks every target as

[OpenOCD-devel] multi-core status

Hmm, Been reading the code - I don’t see support for Multicore at this time. Has anybody looked into this? By multicore I mean the following: 1)An ARM DAP - with multiple ARM cpus attached 2) Some in an SMP configuration, ie: 2 or 4 CortexA7s 3) Others as independent CPUs (i.e.: A co

Re: [OpenOCD-devel] Gerrit newbie making noise

On Mon, Mar 3, 2014 at 2:17 AM, Xiaofan Chen wrote: > Usually that means your device does not have a unique serial number. > If the device has a unique serial number, Windows will not need to > re-install the driver for your device. This problem also occurs in locked down retail

Re: [OpenOCD-devel] TCL RPC how to get output of commands

What are you expecting the ‘mem2array’ to do? As the name implies, the function reads memory and places it into an array variable, there would be no output from that. If I remember the syntax of this command: mem2array outputArray 8 0x023223 1 means: Create an array variable Read

Re: [OpenOCD-devel] permissions errors for libusb

n wrote: > > On Sat, Feb 22, 2014 at 4:29 PM, Paul Fertser wrote: > On Sat, Feb 22, 2014 at 07:24:52AM -0800, Duane Ellis wrote: > >Openocd provides a UDEV file named: "openocd.udev" you must copy/rename > > this > > file to exactly: > >/e

[OpenOCD-devel] state of multicore?

Hi, Now that I’m on to my next step - what is the state of the Coresight DAP, and multi-core debug in OpenOCD? More specifically: I have CortexM3’s off of a DAP (not Dap-lite) I have multiple ARMv7’s off of a DAP setup in a SMP form What is the general state of simultan

Re: [OpenOCD-devel] permissions errors for libusb

I figured out the problem, this was *NOT* very clear The user manual could be improved as follows: -- a) In section 4, change: FROM: On Linux, this usually involves installing a file in /etc/udev/rules.d, TO: On Linux, this requires a rules file in /etc/udev/rules.d [See t

[OpenOCD-devel] permissions errors for libusb

Hi - It has been a few years since I have done things with OpenOCD, and need to try some stuff out. When I try to run OpenOCD - I get this error message: LIBUSB_ERROR_ACCESS Google is not helping me tonight… (a) I have a Ubuntu box - 12.04 LTS (b) I have OpenOCD built using LIBUSB-1 (This is