Re: [Openocd-development] arm11 srst behavior

On Wed, Oct 14, 2009 at 7:01 AM, michal smulski wrote: > > arm11 has a bug in that you cannot at the same time assert srst to the > arm11 core and access its JTAG logic. Asserting srst will disable TAP > logic. So SRST gates JTAG What I'm also unclear about is whether SRST issues a tms seque

Re: [Openocd-development] arm11 srst behavior

> So I'd think the current code is behaving, modulo issues > you might have with iMX31 ... The currrent code target/arm11* code doesn't assert srst, it just issues a halt during assert. -- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash progr

Re: [Openocd-development] arm11 srst behavior

On Tuesday 13 October 2009, michal smulski wrote: > arm11 has a bug in that you cannot at the same time assert srst to the > arm11 core and access its JTAG logic. Asserting srst will disable TAP > logic. Maybe *some* processors do, but I just fired up an OMAP2420 and found that it's not true:

Re: [Openocd-development] getting Hitex Comstick OR STR912 Eval board running? [solved]

So this isn't a patch for openocd, I take it. You should go to the libftdi guys, or perhaps someone on this list will comment... -- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Open

Re: [Openocd-development] arm11 srst behavior

arm11 has a bug in that you cannot at the same time assert srst to the arm11 core and access its JTAG logic. Asserting srst will disable TAP logic. My guess is that flops' reset pin in JTAG core are connected to srst. It is unclear to me how long you have to wait after reset before accessing JT

Re: [Openocd-development] Build problems with xscale/debug_handler.bin

On Tuesday 13 October 2009, Øyvind Harboe wrote: > On Tue, Oct 13, 2009 at 10:47 AM, David Brownell wrote: > > On Monday 12 October 2009, David Brownell wrote: > >> Something needs to add a "-I$(SRCDIR)", or equivalent, to > >> the options used to invoke the assembler. > > > > Looks like the src/t

Re: [Openocd-development] [PATCH] fix detection of PLD instructions

Merged both patches, thanks. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] getting Hitex Comstick OR STR912 Eval board running? [solved]

On Tuesday 13 October 2009, Øyvind Harboe wrote: > On Tue, Oct 13, 2009 at 8:57 PM, David Brownell wrote: > > On Tuesday 13 October 2009, Øyvind Harboe wrote: > >> > If so, a diff follows. I've never submitted a diff before, so I'm not > >> > sure > >> > if I did it the right way around. > > > >

[Openocd-development] [PATCH] fix detection of PLD instructions

Signed-off-by: Lennert Buytenhek diff --git a/src/target/arm_disassembler.c b/src/target/arm_disassembler.c index 2755cc2..5b0046b 100644 --- a/src/target/arm_disassembler.c +++ b/src/target/arm_disassembler.c @@ -110,7 +110,7 @@ static int evaluate_pld(uint32_t opcode, uint32_t a

Re: [Openocd-development] getting Hitex Comstick OR STR912 Eval board running? [solved]

On Tue, Oct 13, 2009 at 8:57 PM, David Brownell wrote: > On Tuesday 13 October 2009, Øyvind Harboe wrote: >> > If so, a diff follows. I've never submitted a diff before, so I'm not sure >> > if I did it the right way around. > > "git diff > my.patch" > then edit it to provide a good descripti

Re: [Openocd-development] PXA270 problems

On Friday 11 September 2009, Wookey wrote: > +++ Sergey Lapin [2009-09-08 22:50 +0400]: > > Hi, all! > > > > When working with PXA270 I see the following messages on reset. > > > > JTAG tap: pxa270.cpu tap/device found: 0x49265013 (mfg: 0x009, part: > > 0x9265, ver: 0x4) > > value captured during

[Openocd-development] [patch/rft] xscale: always reload handler after reset

Remove needless debug handler state. - "handler_installed" became wrong as soon as the second TRST+SRST reset was issued ... so the handler was never reloaded after the reset removed it from the mini-icache. This fixes the bug where subsequent resets fail on PXA255 (if the first o

Re: [Openocd-development] getting Hitex Comstick OR STR912 Eval board running? [solved]

On Tuesday 13 October 2009, Øyvind Harboe wrote: > > If so, a diff follows. I've never submitted a diff before, so I'm not sure > > if I did it the right way around. "git diff > my.patch" then edit it to provide a good description, and remove cruft If you're modifying your own repository, w

Re: [Openocd-development] [patch/rfc] simplify XScale debug handler installation

On Tuesday 13 October 2009, Michael Schwingen wrote: > David Brownell wrote: > > How stable do you find the XScale support, by the way? > > Looks quite stable to me. I use it regularly at home on IXP42x I got that impression ("stable for you"); but it's really not worked well at all on my old

[Openocd-development] [PATCH] fix pass_condition() LE condition code check

Signed-off-by: Lennert Buytenhek -- The LE check is obviously buggy (as easily triggered during some testing), but I didn't audit the rest of the cases. diff --git a/src/target/arm_simulator.c b/src/target/arm_simulator.c index 7c610a5..93fb3dd 100644 --- a/src/target/arm_simulator.c +++ b/src/ta

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 wrote: >> >> >>> Yauheni Kaliuta wrote: >>> >>> Hi, Magnus! > "ML" == Magnus Lundin writes: > > >

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 wrote: > >> Yauheni Kaliuta wrote: >> >>> Hi, Magnus! >>> >>> >>> "ML" == Magnus Lundin writes: >>> [...] >>> >>> > > I have a simple "works for me" implementation of m

Re: [Openocd-development] Any ideas how OpenOCD should handle virtual addressing and cache coherency?

On Tue, Oct 13, 2009 at 7:45 PM, Magnus Lundin 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 corte

Re: [Openocd-development] getting Hitex Comstick OR STR912 Eval board running? [solved]

On Tue, Oct 13, 2009 at 7:45 PM, Colin Howarth wrote: > Dunce me, hadn't added --enable-ft2232_libftdi to ./configure > > Seems to work OK now :-) > > > > On 13 Oct, 2009, at 19:27, Øyvind Harboe wrote: > >> Try one step at the time... First a patch with the bugfix, >> get it committed and then tr

Re: [Openocd-development] Any ideas how OpenOCD should handle virtual addressing and cache coherency?

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 interfa

[Openocd-development] getting Hitex Comstick OR STR912 Eval board running? [solved]

Dunce me, hadn't added --enable-ft2232_libftdi to ./configure Seems to work OK now :-) On 13 Oct, 2009, at 19:27, Øyvind Harboe wrote: > Try one step at the time... First a patch with the bugfix, > get it committed and then try to attack the next part of > the problem. Is this list also for l

Re: [Openocd-development] [patch/rfc] simplify XScale debug handler installation

David Brownell wrote: > On Monday 12 October 2009, Michael Schwingen wrote: > >>> I'll ask the folk using XScale to sanity check; I doubt this >>> set of XScale patches would have broken anything, but I can >>> only test on this one ancient PXA255 board I've got. >>> >> I just made a shor

Re: [Openocd-development] Any ideas how OpenOCD should handle virtual addressing and cache coherency?

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 targ

Re: [Openocd-development] getting Hitex Comstick OR STR912 Eval board running?

Try one step at the time... First a patch with the bugfix, get it committed and then try to attack the next part of the problem. -- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Ope

Re: [Openocd-development] [PATCH] Cleanup: nuke trailling whitespaces

Committed. Thanks! -- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/o

[Openocd-development] getting Hitex Comstick OR STR912 Eval board running?

Hi, my last email (Re: not quite up and running... :-( didn't get much of a response. Was it unclear, boring, not relevant to the list or unfriendly? Or did it just get overlooked? :-) Anyway, I posted that I wasn't getting very far with the following setup: > > libusb-0.1.10a > libftdi

Re: [Openocd-development] ADIv5 handling proposal

On Tuesday 13 October 2009, Magnus Lundin wrote: > The actual debug comonents are specified in the ArmV7A TRM and Cortex A8 > TRM. Not for Cortex M3 they aren't! :) (Which doesn't negate your point that the ADI arch doc doesn't specify those components; it does highlight *why* the arch doc isn'

[Openocd-development] [PATCH] Cleanup: nuke trailling whitespaces

From: Yauheni Kaliuta Signed-off-by: Yauheni Kaliuta --- contrib/libdcc/dcc_stdio.c |4 ++-- contrib/libdcc/example.c |6 +++--- ecosflash/flash.c | 12 ++-- src/flash/lpc2900.c|2 +- src/target/arm11.c |2 +- src/target/armv7a.c|

Re: [Openocd-development] ADIv5 handling proposal

Hi! On Tue, Oct 13, 2009 at 7:28 PM, Magnus Lundin wrote: > Yauheni Kaliuta wrote: >> >> Hi! >> >> On Tue, Oct 13, 2009 at 1:28 PM, Magnus Lundin 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)

Re: [Openocd-development] Any ideas how OpenOCD should handle virtual addressing and cache coherency?

Yauheni Kaliuta wrote: > Hi! > > On Thu, Oct 1, 2009 at 9:41 PM, Magnus Lundin > wrote: > > Any ideas how OpenOCD should handle virtual addressing and cache > coherency? > > > [..] > > > I am planning to implement these for the ARMv7A/CortexA8 and I am >

Re: [Openocd-development] ADIv5 handling proposal

Yauheni Kaliuta wrote: > Hi! > > On Tue, Oct 13, 2009 at 1:28 PM, Magnus Lundin 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 ?? >> >>

[Openocd-development] Do not replace virt2phys with the default one if it was assigned

From 2cefc67a645ad25c1eba2b6d4e090c4e4583dc03 Mon Sep 17 00:00:00 2001 From: Yauheni Kaliuta Date: Sun, 11 Oct 2009 18:27:27 +0300 Subject: [PATCH] Do not replace virt2phys with the default one if it was assigned Signed-off-by: Yauheni Kaliuta --- src/target/target.c |1 - 1 files changed,

Re: [Openocd-development] Do not replace virt2phys with the default one if it was assigned

Committed. Thanks! -- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/o

[Openocd-development] arm11 srst behavior

Can someone help me explain what the effects of asserting srst on an arm11 is? Does anyone know how to safely reset an arm11 into the halted state? I've been trying to read the arm11 documentation and tinkering with the OpenOCD arm11 code against an iMX31, without becoming a whole lot wiser... I

Re: [Openocd-development] ADIv5 handling proposal

Hi! On Tue, Oct 13, 2009 at 1:28 PM, Magnus Lundin 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

Re: [Openocd-development] PATCH: 64 bit fixes for Windows x64 compilation using libftdi/libusb

On Tue, Oct 13, 2009 at 6:33 PM, Redirect "Slash" NIL wrote: > Aha, but the thing is, I am not distributing a test-signed device driver. In > my archive, I am actually providing *unsigned* drivers, along with the tools > & script for users to self-sign them, and I am requiring users to do their >

Re: [Openocd-development] Cross compiler for ARM7 bare metal

+++ Wookey [2009-10-10 12:33 +0100]: > +++ Jon Smirl [2009-10-08 17:33 -0400]: > > Can someone help me out and point me to a working cross toolchain for > > arm7tdmi with uclibc or equivalent on Linux? I've got a working glib > > setup but it keeps linking in 900KB of run-time code. I had two repl

Re: [Openocd-development] Asserting only srst when srst pulls trst

On Tuesday 13 October 2009, Øyvind Harboe wrote: > Reading documentation on arm11 about reset types doesn't make > me any less confused. It seems like "power on reset" is not accessible > via srst, trst or the debug registers and that the "power on reset" > can reset stuff that can't be reset other

Re: [Openocd-development] PATCH: 64 bit fixes for Windows x64 compilation using libftdi/libusb

(repost to reply to the whole list now) Hi Xiaofan, 2009/10/13 Xiaofan Chen > > One of the major issue is that you are now using test-signed driver > with Vista 64bit and Windows 7 64bit. > Yes indeed, although I personally don't consider it as a major issue. It is my personal opinion that, s

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 a

Re: [Openocd-development] PATCH: 64 bit fixes for Windows x64 compilation using libftdi/libusb

Hi, Sorry about the inline patch. Please find the original diff file as a text attachment. The only warning fix is in /src/helper/replacements.c and has to do with MinGW not linking a "long" being cast to "HANDLE" (= 64 bit void*), so I'm not sure it's worth splitting it (it's still 64 bit relate

Re: [Openocd-development] Retire arm11 no_increment

On Tuesday 13 October 2009, Daniel Bäder wrote: > there should the possibility to do a memwrite without increment > because you need it for nand flash (at least on Samsung processors) > I don't know if this option is the right way to do this. Wouldn't making src/flash/arm_nandio.c work on ARMv6

[Openocd-development] ADIv5 handling proposal

Hi! What about implementing more generic access to ADIv5 and APB-AP? I see it like this but what gurus have in mind? From 5e3072d911f89184d159232c0f410c0252161a25 Mon Sep 17 00:00:00 2001 From: Yauheni Kaliuta Date: Tue, 13 Oct 2009 12:47:05 +0300 Subject: [PATCH] More abstract interface to acces

[Openocd-development] Asserting only srst when srst pulls trst

I'm tinkering with arm11 code and I'm wondering whether or not we'll need to allow srst to be asserted alone even if srst pulls trst flag is set... Reading documentation on arm11 about reset types doesn't make me any less confused. It seems like "power on reset" is not accessible via srst, trst or

Re: [Openocd-development] [patch/rfc] simplify XScale debug handler installation

On Monday 12 October 2009, Michael Schwingen wrote: > > I'll ask the folk using XScale to sanity check; I doubt this > > set of XScale patches would have broken anything, but I can > > only test on this one ancient PXA255 board I've got. > > I just made a short test on IXP425 - compiled & installed

[Openocd-development] SWJ interface support -- expand vsllink_execute_queue command type

Hi, Add SWJ_SEQ as command type, with parameters: 1. trn_type, tru_cycles(uint8_t): define Trn: Turnaround. This is a period during which the line is not driven and the state of the line is undefined. The length of the turnaround period is controlled by the TURNROUND field in the Wire C

Re: [Openocd-development] Retire arm11 no_increment

David Brownell schrieb: > On Tuesday 13 October 2009, Daniel Bäder wrote: >> there should the possibility to do a memwrite without increment >> because you need it for nand flash (at least on Samsung processors) >> I don't know if this option is the right way to do this. > > Wouldn't making src/

Re: [Openocd-development] not quite up and running... :-(

On Monday 12 October 2009, Colin Howarth wrote: > libusb-0.1.10a/tests/descriptor_test gives this: > > > > 001/004-0640-002c-00-00     0640/002C > - Unable to fetch manufacturer string > - Unable to fetch product string Implying that it was able to read the device descriptor, but for some reaso

Re: [Openocd-development] Build problems with xscale/debug_handler.bin

On Tue, Oct 13, 2009 at 10:47 AM, David Brownell wrote: > On Monday 12 October 2009, David Brownell wrote: >> Something needs to add a "-I$(SRCDIR)", or equivalent, to >> the options used to invoke the assembler. > > Looks like the src/target/Makefile.am is already set up > with a boatload of "-I.

Re: [Openocd-development] Build problems with xscale/debug_handler.bin

On Monday 12 October 2009, David Brownell wrote: > Something needs to add a "-I$(SRCDIR)", or equivalent, to > the options used to invoke the assembler. Looks like the src/target/Makefile.am is already set up with a boatload of "-I..." options, which omit the target directory ... please try adding

Re: [Openocd-development] Retire arm11 no_increment

On Tue, Oct 13, 2009 at 10:37 AM, Daniel Bäder wrote: > David Brownell schrieb: >> On Tuesday 13 October 2009, Daniel Bäder wrote: >>> there should the possibility to do a memwrite without increment >>> because you need it for nand flash (at least on Samsung processors) >>> I don't know if this op

Re: [Openocd-development] Retire arm11 no_increment

On Tue, Oct 13, 2009 at 9:38 AM, Daniel Bäder wrote: > Øyvind Harboe schrieb: >> Can anyone come up with a reason why we should have the >> "arm11 no_increment" option? > > there should the possibility to do a memwrite without increment > because you need it for nand flash (at least on Samsung pro

Re: [Openocd-development] PATCH: 64 bit fixes for Windows x64 compilation using libftdi/libusb

On Monday 12 October 2009, Øyvind Harboe wrote: > please split the patches in two separate posts(one for Win64 stuff > and another for warning fixes) and email them as attachments. I said something similar off-list. :) The issue is that the patch was at least line-wrapped, if not also mangled in

Re: [Openocd-development] Retire arm11 no_increment

Øyvind Harboe schrieb: > Can anyone come up with a reason why we should have the > "arm11 no_increment" option? there should the possibility to do a memwrite without increment because you need it for nand flash (at least on Samsung processors) I don't know if this option is the right way to do th