> I've failed to find link now, but reproduced patch and attached it to this
> mail,
> so I think you will remember this one.
That one... It's in TODO file. Someone needs to step up to the plate and
fix the automake files I don't know the install rules, etc. that need to be
followed.
--
Øy
Committed.
Thanks!
--
Øyvind Harboe
Embedded software and hardware consulting services
http://www.zylin.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Committed.
Thanks!
--
Øyvind Harboe
Embedded software and hardware consulting services
http://www.zylin.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Here, I agree with Duane,
The end user want to debug/flash a device -> not a concept of multiple
devices.
You may auto-generate the files one time at the MAKE of openocd.
Or you may have a separated script, generating this file one time and
put these file to the trunk.
Regards,
Laurent
http:/
>> Anyone got a PXA270 to donate so I can test?
>
> We can almost certainly get you a balloon board if it would help keep
> Openocd-on-pxa270 in good fettle.
Thanks!
Please mail it to:
Zylin AS
att. Øyvind Harboe
Auglendsdalen 78
4017 Stavanger
Norway
tel. +47 51 63 25 00
--
Øyvind Harboe
Embe
On Wed, Sep 9, 2009 at 1:26 AM, David Brownell wrote:
> On Tuesday 08 September 2009, Ųyvind Harboe wrote:
>> There was a bug in waiting in the code that handled tap
>> events when more than 2 event types were added
>
> I saw that and had a different fix, which handled one
> additional case.
>
Optionally shave time off the armv4_5 run_algorithm() code: let
them terminate using software breakpoints, avoiding roundtrips
to manage hardware ones.
Enable this by using BKPT to terminate execution instead of "branch
to here" loops. Then pass zero as the exit address, except when
running on a
Fix docs on ARM11 MCR and MRC coprocessor commands:
correct read-vs-write; and describe the params.
(ARM920 and ARM926 have cp15-specific commands; this
approach is more generic. MCR2, MRC2, MCRR, MCRR2,
MRRC, and MRRC2 instructions could also get exposed.)
---
doc/openocd.texi | 18 ++
On Wed, Sep 9, 2009 at 12:25 AM, Øyvind Harboe wrote:
> On Tue, Sep 8, 2009 at 8:50 PM, Sergey Lapin wrote:
>> 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 capt
+++ Øyvind Harboe [2009-09-08 22:25 +0200]:
> On Tue, Sep 8, 2009 at 8:50 PM, Sergey Lapin wrote:
> > 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)
That is the corr
On Tuesday 08 September 2009, Øyvind Harboe wrote:
> There was a bug in waiting in the code that handled tap
> events when more than 2 event types were added
I saw that and had a different fix, which handled one
additional case.
But why was the call to the post-reset handler failing?
__
Freddie Chopin wrote:
freddie> I still cannot agree on that. Which version is better:
freddie> Your:
duane> global CHIPNAME
duane> set CHIPNAME lpc2103
duane> global FLASH_SIZE
duane> set FLASH_SIZE ...
duane> ... [snip] ...
duane> source [find target/lpc2xxx_internals.tcl]
freddie> or mine
fre
On Monday 07 September 2009, Øyvind Harboe wrote:
> 1. test that a robust post reset event can be written for Beagleboard
> that handles the "100 clocks after reset" problems.
With
jtag configure $_CHIPNAME.jrc -event post-reset "runtest 100"
when I "reset" at tcl I get "There are no en
take #2...
There was a bug in waiting in the code that handled tap
events when more than 2 event types were added
--
Øyvind Harboe
Embedded software and hardware consulting services
http://www.zylin.com
### Eclipse Workspace Patch 1.0
#P openocd
Index: src/flash/str9xpec.c
==
On Tue, Sep 8, 2009 at 8:50 PM, Sergey Lapin wrote:
> 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 scan didn't pass the requested check:
> captured: 0
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 scan didn't pass the requested check:
captured: 0x00 check_value: 0x02 check_mask: 0x07
JTAG error while writing DC
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 possi
Øyvind Harboe schrieb:
> Does anyone have an s3c6410 PCB out there they
> could donate to us?
I am currently working on a S3C6410 based board but I have only some samples
here.
I hope that we can go in production in october and that I can convince my boss
to donate one.
Duane Ellis pisze:
> As an *end*user* if I saw a sequence of filenames that I recognized I
> could examine a few of them - see the simple pattern and settings and
> could probably follow that simple pattern successfully. By simple I
> mean: perform lots of "set VARNAME VALUE" - then include/so
Hello, all.
Can anyone suggest what options should be passed to the "indent", to format the
source code under the rules of formatting C-code ?
Thank you.
--
Regards,
Alexei Babich, circuit design engineer, Rezonans plc., Chelyabinsk, Russia
http://www.rez.ru
Jabber ID: imp...@jabber.ru
20 matches
Mail list logo
