Re: [Openocd-development] Clock setup script for STM32F107

Am 10/09/2011 12:37 PM, schrieb Simon Barner: > Dear list, > > I have already posted the attached script some weeks ago. > > It enables the PLL of the STM32F107 and thus configures > the MCU to run at 72 MHz which allows for higher JTAG speeds. > > Since this should be useful for everybody, I would

Re: [Openocd-development] [PATCH] InpOut32 library support in Openocd

On 09/13/2011 11:17 PM, Jaroslaw Niec wrote: If you think adding another --enable-parallel-inpout isn't the best solution I could try to modify giveio code in such a way that if loading of giveio driver fails (always on 64-bit Windows and when giveio.sys isn't installed) then as a fallback inp

Re: [Openocd-development] Coding style

On 28.08.2011 10:04, Øyvind Harboe wrote: Also, I'd be happy to let someone else define what the "correct" coding style is. I don't particularly care as long as the check can be automated and the style is consistent. Are there scripts to fix coding style too? at least indent and the C-Mode in

Re: [Openocd-development] Coding style

On 27.08.2011 19:40, Øyvind Harboe wrote: As a maintainer I'm interested in this subject from the point of view of how it can be used to *save* time of the maintainers. E.g. if we had a script committed that checked that a patch sequence was acceptable, then that report could be amended to the p

Re: [Openocd-development] Automatic RTOS Detection

On 08/23/2011 02:10 PM, Evan Hunter wrote: The way I do this on the STM32 is to use TCL script JTAG to zero the memory before allowing GDB to attach. This is necessary since a previous run of the system can leave valid contents in the RTOS variables, which are indistinguishable from real RTOS da

Re: [Openocd-development] Automatic RTOS Detection

On 08/23/2011 12:24 PM, Øyvind Harboe wrote: What if I have a system with an RTOS and want to debug the startup code using GDB? In that case, memory is *not* yet initialized, yet the symbol table would enable RTOS support. Disable threads using gdb command to do so before connecting?

Re: [Openocd-development] Automatic RTOS Detection

On 08/23/2011 09:47 AM, Evan Hunter wrote: The way it has been designed means that no memory locations are touched until symbol locations are provided by GDB. The symbols names which are available tell the system which RTOS is in use. On most platforms OpenOCD would have initialised the memor

Re: [Openocd-development] Last call before release / Olimex ARM-JTAG-EW patches

On 08/03/2011 11:45 AM, Dimitar Dimitrov wrote: Simon, Additionally, the device expects the speed in Hz, not kHz. I figured this out be sniffing the USB traffic generated by IAR EWARM (using Olimex' JLINK emulation driver). Since the default speed in the target configuration file is 1000 kH

Re: [Openocd-development] PCB tips and tricks

Am 07/08/2011 10:35 PM, schrieb Tomek CEDRO: >> Simply drill the holes and solder both sides - with a thin wire if there >> is no THT pin. This may be a bit painful, but works quite well if you >> take care during layout so that you do not place vias under parts. > Yes, this is the obvious solution

Re: [Openocd-development] [PATCH] adding interface_signal and bitbang functionalities

Am 07/08/2011 08:30 PM, schrieb Tomek CEDRO: > ps/2: You can make perfect one layer pcb at home using > photolitography (laser printer + standard laser foil + positive 20 + > cleaner + philips halogen bulb type 14552 12V/75W only requires 1 > minute to create perfect mask). Still I don't know any s

Re: [Openocd-development] MIPS target, big endian host

Am 07/07/2011 10:41 PM, schrieb Mahr, Stefan: > Probably the best way would be to remove endianness swapping from > mips_m4k_read_memory > and put it to mips32_pracc/dma_read_mem32/16. Same for write. > > pro: mips32_pracc_read_mem32, ... will return a byte array in target > endianness, so no cas

Re: [Openocd-development] [OpenOCD][PULL Request][MIPS32] CP0 coprocessor manipulation and cache synchronization routines

Am 07/07/2011 07:27 PM, schrieb Drasko DRASKOVIC: > Hi all, > I am happy to present you several exciting enhancements to the MIPS32 target. This is great! I do not (yet) use MIPS, but from the descriptions of what you did, this should bring OpenOCD a good step forward. cu Michael ___

Re: [Openocd-development] USB Blaster support broken

On 06/28/2011 09:34 AM, Laurent Gauch wrote: Greetings all, In the past few days I have been trying to get my USB Blaster clone (called "USB Blaster mini") to work with OpenOCD from the latest git tree (762ca59dd5cbe70026234d549bb5f5ac1a05d5b4

Re: [Openocd-development] USB Blaster support broken

On 06/28/2011 09:19 AM, Domien Nowicki wrote: Greetings all, In the past few days I have been trying to get my USB Blaster clone (called "USB Blaster mini") to work with OpenOCD from the latest git tree (762ca59dd5cbe70026234d549bb5f5ac1a05d5b4

Re: [Openocd-development] [OpenOCD] [PATCH 1/1] load_image should use virtual (p_vaddr) instead of physical (p_paddr) ELF segment addr

Am 06/22/2011 01:05 PM, schrieb Øyvind Harboe: > To me this looks great! > > I haven't haven't studied the problem. Neither me (not in detail). The description in the mailing lists sounds reasonable, and the patch seems to achieve what was discussed here, so unless someone else spots problems, I wo

Re: [Openocd-development] [PATCH] Implementation of a remote bitbang jtag driver

On 24.06.2011 17:40, Uhler, Richard wrote: Attached is an updated version of the remote bitbang patch generated following the instructions from http://repo.or.cz/w/openocd.git/blob/HEAD:/HACKING. The remote bitbang jtag driver is useful for debugging software running on processors which are b

Re: [Openocd-development] Cortex M3: Patch for automatic handling of interrupt mask during stepping

On 24.06.2011 11:32, Øyvind Harboe wrote: Anyone have any objections against this patch? Did anyone else but Andreas Fritiofson review it in detail? I have not looked at the code, but I like the concept. As long as there is a way to get the old behaviour in case of problems (I think there is

Re: [Openocd-development] [PATCH 3/3] ft2232: Add casts to avoid warnings

On 23.06.2011 14:39, Laurent Gauch wrote: />>/ I don't see how. />/ />/ I haven't followed this(big discussions), but I've seen on the list />/ in the past that casting is frowned upon and using these />/ macros is cheered... Anyway... I'm happy to follow the path />/ of using these macros, I cer

Re: [Openocd-development] [OpenOCD] [PATCH 1/1] load_image should use virtual (p_vaddr) instead of physical (p_paddr) ELF segment addr

Am 06/21/2011 07:19 PM, schrieb Drasko DRASKOVIC: > >> Perhaps bfd library? > Yes, that would be the right place, but I hoped to avoid further digging ;). > > Here is something interesting, from the gdb's src/bfd/elf.c, line 963 > (and it is related to one of the posts I mentioned previously) : > >

Re: [Openocd-development] bitbanging ft2232 dongle port from TCL is TOO DANGEROUS : PLEASE COMMENT

Am 06/20/2011 08:14 PM, schrieb Øyvind Harboe: >> Please explain the dangers. > If a driver can't implement a sane feature safely, then the driver shouldn't > implement that feature Fine. I *do* think hardware should be designed in a way that it can not be damaged by software, but if existing

Re: [Openocd-development] bitbanging ft2232 dongle port from TCL is TOO DANGEROUS : PLEASE COMMENT

Am 06/20/2011 02:44 PM, schrieb Laurent Gauch: >> only one transport option; autoselect 'jtag' >> > interface_signal list >> interface_signal list >> Interface Signal Name |Mask| Value >> -- >> > interface_signal add

Re: [Openocd-development] RFC Release Cycle

Am 06/17/2011 03:15 AM, schrieb Jean-Christophe PLAGNIOL-VILLARD: > Hi all, > > I'd like to propose the following release cycle > > For the people familiar with Linux kernel its basically the same > > 2 development window: > merge window > fix window > > We will

Re: [Openocd-development] New development version of OpenOCD available at last!

Am 06/16/2011 12:56 AM, schrieb Spencer Oliver: > > > On Jun 15, 2011 11:40 PM, "Tomek CEDRO" > wrote: > > > > So is there anyone else wanting to release 0.4.1 (or any other) from > > the current source tree?? There were so many people interested... > > > > I am all f

Re: [Openocd-development] New development version of OpenOCD available at last!

Am 06/11/2011 09:41 AM, schrieb Freddie Chopin: > >> I think a release should be cut at either of these two points >> for a project like OpenOCD which is still very active and not >> reaching mature state. >> 1) Enough patches have been accumulated. >> 1) A certain time has been passed, say 6-month

Re: [Openocd-development] Outstanding patches => Fix: Correctly exit function: ft2232_init when an error occurred

Am 06/11/2011 09:55 AM, schrieb Freddie Chopin: > On 2011-06-10 22:06, Peter Stuge wrote: >> And that just because the code does not have information, it should >> not make guesses. > > Restoring initial state of FT2232 interface is just like "pulling a > plug" - disconnecting JTAG from board. I re

Re: [Openocd-development] Outstanding patches => Fix: Correctly exit function: ft2232_init when an error occurred

Am 06/11/2011 09:48 AM, schrieb Freddie Chopin: > Full support here - for me after shutting down OpenOCD I'd like it to > restore interface to "initial" state (in most cases - "transparent"). > Sometimes - when the interface is placed inside some device it's > difficult to physically disconnect it

Re: [Openocd-development] Outstanding patches => Fix: Correctly exit function: ft2232_init when an error occurred

Am 06/11/2011 01:32 AM, schrieb Peter Stuge: > Tomek CEDRO wrote: If you switch output into Hi-Z the pull-up or pull-down resistor will take care of the on the pin state. >>> I think Michael's point is that *which* state it is is not known (and >>> can not be known) by generic ft2232 code

Re: [Openocd-development] Outstanding patches => Fix: Correctly exit function: ft2232_init when an error occurred

Am 06/10/2011 09:51 PM, schrieb Tomek CEDRO: > On Fri, Jun 10, 2011 at 7:17 PM, Michael Schwingen > wrote: >> If we agree that we do not want to touch the target, that means the >> lowlevel interface driver must not change any signal state upon exit, >> because it does

Re: [Openocd-development] Outstanding patches => Fix: Correctly exit function: ft2232_init when an error occurred

Am 06/10/2011 09:41 AM, schrieb Laurent Gauch: >> >> Hello Andreas :-) >> >> On Thu, Jun 9, 2011 at 11:30 PM, Andreas Fritiofson >> > > wrote: >> >>/ I have created simple quit() that sets all port pins high and as >> input >> />>/ (mps

Re: [Openocd-development] Outstanding patches => Fix: Correctly exit function: ft2232_init when an error occurred

Am 06/10/2011 04:35 PM, schrieb Laurent Gauch: >> >> If I quit OpenOCD, I expect the target to stay in the same state as >> before. >> If it was in reset, I expect it to stay in reset and not start some code >> uncontrolled. >> > > Yes you're right Michael regarding the state of the TARGET. > >

Re: [Openocd-development] Peter Stuge is now an OpenOCD maintainer

Am 06/10/2011 07:00 PM, schrieb Pete Batard: > It is. Heck, I only have to quote you on being "confident that a > release before 2011 (was) achievable", or Segher dismissing people > like myself or Xiaofan as "naysayer" when we shared our pessimistic > outlook about that statement, to make you real

Re: [Openocd-development] [PATCH 2/5] ft2232: Refactor ft2232_init_*() into ft2232_initone()

Am 06/10/2011 09:21 AM, schrieb Laurent Gauch: > Please remember guys also to properly fix the ft2232_quit() as Laurent >> proposed, this is also necessary to bring interface to default state >> on quit :-) >> > And not only the specific layout, but the mpsse must be reseted. > We have to make s

Re: [Openocd-development] Outstanding patches => Fix: Correctly exit function: ft2232_init when an error occurred

Am 06/10/2011 09:33 AM, schrieb Laurent Gauch: > >> >/ Do you have any other ideas on what should be done on ft2232_quit() >> />/ except rtck, hi-z, div5..? I can prepare a patch, or Peter will as I >> />/ can see he is already working out the subject :-) >> / >> >> What problem is setting pins to

Re: [Openocd-development] Outstanding patches => Fix: Correctly exit function: ft2232_init when an error occurred

Am 06/10/2011 02:51 AM, schrieb Tomek CEDRO: > Not sure if OUTPUT-HIGH for FT2232 means Hi-Z but most buffers you > mention in those interfaces are tri-state buffers from what I have > seen on ~5 different devices. Tri-state buffers are active-low, so > setting pins to input (Hi-Z) should give Hi-Z

Re: [Openocd-development] Outstanding patches => Fix: Correctly exit function: ft2232_init when an error occurred

Am 06/07/2011 11:23 AM, schrieb Laurent Gauch: > Hi Michael, >> Am 06/06/2011 02:10 PM, schrieb Laurent Gauch: >> >/ Yes, this is to decouple the open and init (open the handle, init >> />/ the associated specific layout). >> / >> Is there case where open is used without init, or init without ope

Re: [Openocd-development] Outstanding patches => Fix: Correctly exit function: ft2232_init when an error occurred

Am 06/06/2011 02:10 PM, schrieb Laurent Gauch: > Yes, this is to decouple the open and init (open the handle, init > the associated specific layout). Is there case where open is used without init, or init without open? Otherwise, this is just unnecessarily complex. > (more smaller function ...

Re: [Openocd-development] [PATCH] use one configuration for all JTAGkey devices.

Am 06/06/2011 01:44 PM, schrieb Laurent Gauch: > > If our ft2232.c patches are not merged quickly, Amontec Team will > certainly come with a new specific jtagkey.c API driver instead of > the ft2232.c JTAG driver. > The advantage with a specific Amontec JTAGkey API driver in openocd, > will be to

Re: [Openocd-development] [PATCH] use one configuration for all JTAGkey devices.

Am 06/06/2011 09:20 AM, schrieb Yegor Yefremov: > Signed-off-by: Yegor Yefremov > > --- > tcl/interface/jtagkey2.cfg |7 ++- > tcl/interface/jtagkey2p.cfg |7 ++- > 2 files changed, 4 insertions(+), 10 deletions(-) > > Index: b/tcl/interface/jtagkey2.cfg > ===

Re: [Openocd-development] Error: .. adapter speed not selected

Am 05/26/2011 10:47 PM, schrieb Paul Claessen: > > Thanks for your much appreciated quick response. > I'm using my own .cfg for file an Olimex Tiny. I simply added the > suggested 'adapter_khz' (with value 1000, although I'm not sure what a > reasonable value would be; I guess that depends on the t

Re: [Openocd-development] Error: .. adapter speed not selected

Am 05/26/2011 09:12 PM, schrieb Paul Claessen: > In April (2011) I built openocd version 0.5.0-dev-00858 and used it > successfully with an Olimex OpenOCD JTAG Tiny. > I recently built version 0.5.0-dev-00882 and I now get the following > error: > > Error: An adapter speed is not selected in the

Re: [Openocd-development] [PATCH] beagleboard: add support for various icepick versions

Am 05/04/2011 07:14 AM, schrieb Øyvind Harboe: > --- a/tcl/target/amdm37x.cfg > +++ b/tcl/target/amdm37x.cfg > @@ -29,11 +29,11 @@ if { [info exists CHIPTYPE] } { > switch $CHIPTYPE { >dm37x { > # Primary TAP: ICEpick-C (JTAG route controller) and boundary scan > - set

Re: [Openocd-development] [PATCH] Correct very slow initialization steps and strange behaviour

Am 04/27/2011 11:50 AM, schrieb Tomek CEDRO: > Hello :-) I think default-low-speed is safer choice for unaware users > or developers simply reading out idcode.. also it can be easily > changed into something more device specific to gain better performance > :-) Hi, this brings us back to the quest

Re: [Openocd-development] sw breakpoints in flash

On 04/26/2011 10:20 AM, Øyvind Harboe wrote: Here is an idea for a new feature: sw breakpoints in flash. The way this feature would work would be to detect if a breakpoint is in the flash region. If it is, a hw breakpoint would be used until the hw breakpoints run out. At that point the flash s

Re: [Openocd-development] OpenOCD and 16-bit CFI flash on an 8-bitbus

Am 04/19/2011 04:59 PM, schrieb Rogan Dawes: > Hi *, > > So it seems that there is something more seriously wrong. I tried to > write to one of the sectors that was shown as unprotected (per "flash > info 0" output), using the following command: > > openocd -f buspirate.cfg -f dns323.cfg -d3 -l ope

Re: [Openocd-development] OpenOCD and 16-bit CFI flash on an 8-bit bus

Am 04/18/2011 09:24 PM, schrieb Rogan Dawes: > > Hi Alexandre, > > Your working cfi definition worked for me, too, after adjusting > addresses and sizes. Thanks you! Now the flash is recognized, and all > the sectors are properly identified. > > However, I am still not able to flash a replacement f

Re: [Openocd-development] LPC32XX Nand support

On 04/15/2011 06:53 AM, Øyvind Harboe wrote: Any objections to merging? No. cu Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Nor flash non-cfi

On 04/15/2011 06:53 AM, Øyvind Harboe wrote: Any objections? No. cu Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] LPC32XX Nand support

Am 04/12/2011 06:09 PM, schrieb Alexandre Pereira da Silva: > Hi, > > Here two patches about this issue. > >> Hi, >> >> Is anybody using the LPC32XX nand driver? >> >> I'm having some issues about large nand devices support. It's >> relatively easy to make the current openocd driver suporte larger

Re: [Openocd-development] Nor flash non-cfi

Am 04/12/2011 06:10 PM, schrieb Alexandre Pereira da Silva: > Hi, > > I found a issue in the fixup detection of a x16 non cfi flash > connected in a x8 bus. > > Attached the patch to fix the issue. It seems in the x16_as_x8 case, you are only comparing 8 bits of the device ID - this looks wrong to

Re: [Openocd-development] ULINK driver: firmware license questions

Laurent Gauch wrote: So, ULINK hardware is only used as board platform :-) So, you have your own protocol. I hope you have your own USB VID/PID too. Why should he? The hardware comes with a valid VID/PID combination - since he only loads a different firmware into the RAM of the ULINK, I do not

Re: [Openocd-development] ULINK driver: firmware license questions

Am 04/06/2011 05:45 PM, schrieb Laurent Gauch: >> Hi! >> >> I'm currently working on a driver for the Keil ULINK adapter. >> >> I have developed a custom firmware for the ULINK's Cypress EZ-USB >> microcontroller during the last six months and recently began >> implementing the OpenOCD driver. Of c

Re: [Openocd-development] Firmware download to JTAG adapter from OpenOCD driver

Am 04/03/2011 09:32 PM, schrieb Martin Schmölzer: > On Sat, 2011-04-02 at 22:50 -0700, Phil Fong wrote: > >> I have not used this code myself so I'm not sure how you are supposed >> to use it. However, I think it is used by the load_image command so >> if it's broken than load image is broken. > O

Re: [Openocd-development] cortex a8/a9 debug base

Øyvind Harboe wrote: I'm wondering if it would be better to ditch the automatic fixup code and use parameters to target in config script. Default would be to use the automatic detection per ARM's specification. Since auto-detecting the broken devices seems to be problematic, I think that wou

Re: [Openocd-development] question about memory access in target.c

Mathias K. wrote: Hello, Am 25.02.2011 14:38, schrieb Michael Schwingen: Mathias K. wrote: I think you can't simple abstract this with 8/16/24/32bit access, because in my case the data bus has always a 24bit width and the address bus increment is always one (one address and 3

Re: [Openocd-development] question about memory access in target.c

Mathias K. wrote: Hello, Am 24.02.2011 22:27, schrieb Michael Schwingen: Am 02/24/2011 09:36 AM, schrieb Mathias K.: this patch add the risc (default) and harvard architecture to the target structure. Currently this patch only affect the memory read/write functions. I am not

Re: [Openocd-development] question about memory access in target.c

Am 02/24/2011 09:36 AM, schrieb Mathias K.: > Hello, > > this patch add the risc (default) and harvard architecture to the target > structure. Currently > this patch only affect the memory read/write functions. I am not sure if "RISC" vs. "Harvard" are the right terms. IIRC, "Harvard" only means

Re: [Openocd-development] [PATCH] interface decrease calling overhead

On 02/11/2011 07:29 AM, Øyvind Harboe wrote: I don't have any objections to this particular patch, but if we have to start doing tweaks at this level, then where does it end? I am not too fond of this since it exposes internals that should stay internals (variables that were static are now globa

Re: [Openocd-development] [PATCH] buf_set_buf around 30% speed increase

Am 02/07/2011 09:37 AM, schrieb Øyvind Harboe: > On Mon, Feb 7, 2011 at 9:27 AM, Mathias K. wrote: >> Hello, >> >> On 07.02.2011 09:09, Øyvind Harboe wrote: >>> What impact would it have to make this an >>> inline fn? >> I think there is no need to declare this "big" function as inline. This will

Re: [Openocd-development] Flash Freescale 56F8013?

Am 01/29/2011 05:53 AM, schrieb Phil Fong: > I have a Freescale 56F8013 which is a DSC from the DSP56800E family that I > want > to flash. I am planning on connecting a FTDI FT2232H to the JTAG pins and > wish > to flash it. > > Freescale provides documentation as to the TAP and ON/CE commands

Re: [Openocd-development] [PATCH 0/6] OMAP4430/Cortex-A9 Support

On 01/29/2011 08:43 AM, Aaron Carroll wrote: I wonder what the best way to is to implement this. One option could be a table that maps address ranges to access methods. This would have to be configured both cpu-cpu (e.g. Cortex-A9 per-core timers) and per-SoC (e.g. OMAP4430 ROM). This would

Re: [Openocd-development] Cable madness

On 01/10/2011 04:53 AM, Andrew Leech wrote: Hah, I am the hw engineer (as well) and I crimp most of my cables with my trusty long nose pliers. I don't have much in the way of fancy crimping tools, but haven't ever really needed them (they do a nice job though when you can get them). I must say t

Re: [Openocd-development] [PATCH] lpc21xx: common target script

Am 01/07/2011 05:43 PM, schrieb Freddie Chopin: > On 2011-01-07 17:22, Freddie Chopin wrote: >> I've come up with an improvement of the idea - I'll present the patch >> tomorrow. This will make it easier to create custom versions of specific >> targets (; > > Here is an example of lpc2103.cfg with

Re: [Openocd-development] LPC2xxx scripts

Am 01/07/2011 05:44 PM, schrieb Øyvind Harboe: > On Fri, Jan 7, 2011 at 5:38 PM, Michael Schwingen > wrote: >> Am 01/07/2011 05:18 PM, schrieb Øyvind Harboe: >>> The construct below has a comment to explain >>> what the following statement means => duplicati

Re: [Openocd-development] LPC2xxx scripts

Am 01/07/2011 05:18 PM, schrieb Øyvind Harboe: > The construct below has a comment to explain > what the following statement means => duplication. > > How about using named parameters instead? > > I think named parameters might even have a concept > of default values in Tcl, but offhand I don't kno

Re: [Openocd-development] New patch series for the handling of CFI with stm32

Am 01/05/2011 06:04 PM, schrieb Jonathan dumaresq: > Hi, > > Here my new series of patches. Looks good after a cursory inspection. The strcmp for "cortex_m3" looks a bit dodgy - I guess the target should be reworked to provide some enum for that purpose. However, that can be done later and should

[Openocd-development] [PATCH 1/4] non-CFI flash code uses data from CFI structures. Make sure that timeouts are filled in on non-CFI flashes, and print CFI information in all cases, nut just on CFI fl

Signed-off-by: Michael Schwingen --- src/flash/nor/cfi.c | 187 +++ src/flash/nor/non_cfi.c | 10 ++- 2 files changed, 98 insertions(+), 99 deletions(-) diff --git a/src/flash/nor/cfi.c b/src/flash/nor/cfi.c index 74362c4..5a35aae 100644 --- a

[Openocd-development] [PATCH 3/4] cfi.c: whitespace cleanup

Signed-off-by: Michael Schwingen --- src/flash/nor/cfi.c | 44 ++-- 1 files changed, 22 insertions(+), 22 deletions(-) diff --git a/src/flash/nor/cfi.c b/src/flash/nor/cfi.c index f25f46d..10a8f62 100644 --- a/src/flash/nor/cfi.c +++ b/src/flash/nor

[Openocd-development] (no subject)

[resend, because the list rejected my previous submission] when working on a board with a SST 39VF020 flash, I noticed that support for these flashs seems to be broken, because the CFI code uses timeout values that are initialized to zero in the non-CFI code. The following patches change that to

[Openocd-development] [PATCH 4/4] actux3.cfg: add function to setup for u-boot debugging

Signed-off-by: Michael Schwingen --- tcl/board/actux3.cfg | 22 ++ 1 files changed, 22 insertions(+), 0 deletions(-) diff --git a/tcl/board/actux3.cfg b/tcl/board/actux3.cfg index 922d4fc..5435ff8 100644 --- a/tcl/board/actux3.cfg +++ b/tcl/board/actux3.cfg @@ -45,3

[Openocd-development] [PATCH 2/4] cfi_protect is not implemented on Spansion flashes (many do not even have protection bits). Demote from error to warning, so that common board code can use "flash wri

Signed-off-by: Michael Schwingen --- src/flash/nor/cfi.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/flash/nor/cfi.c b/src/flash/nor/cfi.c index 5a35aae..f25f46d 100644 --- a/src/flash/nor/cfi.c +++ b/src/flash/nor/cfi.c @@ -1163,8 +1163,8 @@ static int

[Openocd-development] Some updates for non-CFI flashs

Hi, when working on a board with a SST 39VF020 flash, I noticed that support for these flashs seems to be broken, because the CFI code uses timeout values that are initialized to zero in the non-CFI code. The following patches change that to use (hopefully) large enough timeout values, and move t

Re: [Openocd-development] Help needed for SAM3S4C

Am 12/20/2010 02:32 PM, schrieb Kenan Özdemir: > > Hi, > > somehow my code is not working. Recently I tried to figure out, why > there are these unexpected jumps in my programcode. After a look at > the Disassembly, I found something strange.. > > My first lines in main are these: > > int a =

Re: [Openocd-development] Proposal: update IXP42x config files

ng area address. Is the attachment OK, or do I need to send patches inline? cu Michael >From fcfeae660e6e2aaa310e9dee221fd013f82806ef Mon Sep 17 00:00:00 2001 From: Michael Schwingen Date: Sun, 19 Dec 2010 16:17:46 +0100 Subject: [PATCH] update IXP42x target / XBA board config --- tcl/boar

Re: [Openocd-development] Proposal: update IXP42x config files

Am 12/17/2010 10:38 PM, schrieb Steve Bennett: >> +# setup expansion bus CS >> + >> ## >> +mww 0xc400 0xbd113842 #CS0 : Flash, write enabled @0x5000 > Tcl only recognises comments at the beginning of a co

Re: [Openocd-development] Reorganizing the target/board scripts

On 12/18/2010 10:15 PM, Øyvind Harboe wrote: How about having target scripts export a proc as the default behavior rather than just executing statements? This would get rid of using (effectively global)variables as a way to communicate with these scripts. A proc also opens up for handling varia

Re: [Openocd-development] Help needed for SAM3S4C

Am 12/18/2010 09:05 PM, schrieb Kenan Özdemir: > Sorry I forgot to tell you that after a couple of steps, it is > returning to the main routine and then keeps executing the rest of the > code An embedded system has nowhere to go after you exit "main", so it might crash, restart, and re-enter main f

Re: [Openocd-development] Problem loading to CFI flash

Am 12/17/2010 04:36 PM, schrieb Jonathan dumaresq: > Hi all, > > Here my first patches to be able to use the CFI driver on cortex M3 with the > helper code on target. This is probably not the better way of doing it, but > at least it's work. This have been tested on real hardware. The default cfg >

[Openocd-development] Proposal: update IXP42x config files

l >From 6da9b215b386714a61472665c642f31f726a6b37 Mon Sep 17 00:00:00 2001 From: Michael Schwingen Date: Thu, 16 Dec 2010 23:48:12 +0100 Subject: [PATCH] update IXP42x target / XBA board config --- tcl/board/actux3.cfg | 48 +++ tcl/target/ixp42x.

Re: [Openocd-development] Getting rid of default jtag clock rate

On 12/07/2010 10:39 AM, Laurent Gauch wrote: > Will be never good. A JTAG frequency is not only board specific, but > wire (cable length) dependent, buffer dependend, dongle dependent > Too many parameters !!! Chip, dongle, board configs could supply max values (and OpenOCD would have to selec

Re: [Openocd-development] Getting rid of default jtag clock rate

On 12/06/2010 10:53 AM, Laurent Gauch wrote: > > > Øyvind Harboe wrote: >> I don't subscribe to the idea that there is a safe, correct and robust >> default setting for JTAG clock, better to make the user get a >> good error message that points him in the right direction. >> >> 1MHz will fail on pl

Re: [Openocd-development] Getting rid of default jtag clock rate

On 12/05/2010 01:45 PM, Øyvind Harboe wrote: > Does anyone have any objections to getting rid of the > concept of a default JTAG clock rate? > > Basically, I'd like OpenOCD to refuse to start until the > script defines the clock rate. Sounds good to me. cu Michael ___

Re: [Openocd-development] (patch) Change target script for LPC2478

On 04.12.2010 10:08, Freddie Chopin wrote: So you're all about correctness and you don't reset halt the chip before flashing? How is that correct? Actually flashing does not work if you don't "reset halt" the chip. The need for halting is obvious. The need for reset is not, but think about what w

Re: [Openocd-development] (patch) Change target script for LPC2478

On 04.12.2010 10:31, Freddie Chopin wrote: As for the second paragraph, you are wrong. All LPC2xxx target config files have that frequency embedded without possibility to change with some parameters in board config files and - somehow - people manage to use it without problems. How do you know?

Re: [Openocd-development] (patch) Change target script for LPC2478

On 12/03/2010 11:11 PM, Freddie Chopin wrote: > How can this be unreliable? LPC23xx/LPC24xx after reset use 4MHz > internal clock. Doing "reset halt" sets that clock and prevents any > code from changing that (let's not talk about broken cases, because a > broken case can be found everywhere), so w

Re: [Openocd-development] (patch) Change target script for LPC2478

On 12/03/2010 10:06 PM, Freddie Chopin wrote: > On 2010-12-03 21:39, Rolf Meeser wrote: >> The clock parameter is vital for correct and reliable flash programming. >> It must be possible for the user to select the frequency that he is >> using. > I don't know how about you, but me (and 99% of "norm

Re: [Openocd-development] (patch) Change target script for LPC2478

On 12/03/2010 10:12 PM, Freddie Chopin wrote: > > Crazy idea nr 2 - why not set max frequency - this way this pulse will > always be long enough (I don't see any reason for problems with longer > pulse) - maybe this way this parameter would not be required too? I don't know about the flash in the L

Re: [Openocd-development] Programming external flash with OpenOCD fails

On 11/30/2010 08:36 PM, Starkeeper wrote: > Indeed it works without the wokring area! OK. That means at least the flash is working, and the bus setup is probably also OK. OpenOCD tried to download code + data to RAM on the target, and something in that process goes wrong. I don't know the LPC inte

Re: [Openocd-development] Current stable release is very very stale

On 12/01/2010 10:32 PM, Freddie Chopin wrote: > This is also an important issue (; Rowley has done a "converter" for > Amontec JTAGkey, but so far I haven't found much detail about it. It > would be very very cool to be able to use "old" JTAGs with OpenOCD and > SWD - with some kind of detachable s

Re: [Openocd-development] Programming external flash with OpenOCD fails

On 11/30/2010 07:06 PM, Starkeeper wrote: > Hi there, > I have an external flash (Spansion S29GL128N90) connected to a NXP LPC2478 > microcontroller. Everytime when I try to flash this external flash I get the > following error from OpenOCD (Version 0.4.0 and self compiled 0.5.0): > > Flash Manufac

Re: [Openocd-development] Current stable release is very very stale

On 11/29/2010 02:57 PM, Tomek CEDRO wrote: > > ...however I can understand the urge to have stable release done. If > the GIT repository contains mainly bugfixes, then maybe it is time to > freeze it as 0.4.1, so we can release 0.5.0 with SWD suport as planned > - anyway it will probably happen so

Re: [Openocd-development] [patch]cfi_query_string(): Could not probe bank: no QRY

On 11/25/2010 06:13 AM, 韦东山 wrote: For some flash, such as SST39VF6401B, it needs 3 step to enter CFI mode. --- src/flash/nor/cfi.c.origin Thu Nov 11 05:42:00 2010 +++ src/flash/nor/cfi.c Thu Nov 25 12:31:18 2010 @@ -2264,6 +2264,24 @@ struct cfi_flash_bank *cfi_info = bank->driver_priv

Re: [Openocd-development] Problem loading to CFI flash

On 11/22/2010 07:10 PM, Jonathan dumaresq wrote: > >> Cannot see anthing wrong with that log - except it is probably slow. >> >> Cheers >> Spen > The problem seem to me that the remaining bytes should be zero at the end of > the flashing ? It should be, yes. However, I can't see the end in the log

Re: [Openocd-development] STM32 reset_config

On 11/12/2010 06:40 PM, Freddie Chopin wrote: > Show my an example of any _normal_ JTAG interface that does not have > srst? As for the second case, OpenOCD's main purpose is debugging, not > programming, so production boards are not very interesting here. At least the Xilinx JTAG cables have no re

Re: [Openocd-development] Proposition of new target cfg files scheme

Laurent Gauch wrote: under target directories we should add the architecture family directories as - target - arm - STM32 stm32f103rb.cfg stm32f107v8.cfg stm32f100rb.cfg This gets quite annoying to type when specifying the target, and it makes it necessary to ha

Re: [Openocd-development] [PATCH] contrib: add ram loader src code

On 10/27/2010 10:29 PM, Øyvind Harboe wrote: > I actually don't think it is an unreasonable expectation. I know I >> have not had OpenOCD without the cross toolchain. >> >> However, compiling them could be done in make dist, rather than make. >> (Ie. when preparing a tarball, rather than when compi

Re: [Openocd-development] Software breakpoints with GDB do not work

Drasko DRASKOVIC wrote: > For the quick and dirty solution, I created int > arm946e_write_memory(struct target *target, uint32_t address, uint32_t > size, uint32_t count, uint8_t *buffer) to replace currently used > arm7_9_write_memory(). > Inside it I just call existing arm7_9_write_memory() and t

Re: [Openocd-development] [PATCH] Add ft2232_index command

On 08/10/2010 08:57 AM, David Brownell wrote: I's think serial numbers would suffice, and be much more usable/stable. I think a USB device is not required to have a serial number, so in that case, you are suck with using some kind of index, bus/device ID or similar. cu Michael __

Re: [Openocd-development] [PATCH] avr: Add 2 commands for reading AVR Bits/Byte.

simon qian wrote: > And there is a unique ID in signature row of some AVR. > May be it's an interesting feature to use. > > Is there any safe way to support AVR fuse/lock writing? > As you know, such code is very simple, both for JTAG and ISP. > Yes, It's really dangerout to write these sections,

Re: [Openocd-development] [PATCH] avr: Add 2 commands for reading AVR Bits/Byte.

On 08/03/2010 12:01 PM, zeal wrote: This patch add the below commands (just for determining stuff). 1. read_bits for reading Fuse/Lock bits. 2. read_byte for reading Signature/Calibration byte. This looks good - however, I have issues with the command names: both names do not represen

Re: [Openocd-development] is "dap info 0" working for you?

On 11.07.2010 02:54, David Brownell wrote: Not "just" -- see the schematics, you'll notice a bunch of wiring needed to support SWD as an option in addition to JTAG.Some SWD signals are bidirectional, so a pure JTAG adapter is not going to handle SWD too. This looks like only a 74xx125 is nee

  1   2   3   >