On Sat, 2009-10-24 at 15:03 +0200, Øyvind Harboe wrote:
> Attached are the remaining patches for the first round of
> target->type->mcr/mrc support.
>
> There is a writeup in TODO of the harder targets
> that remain. E.g. arm966e support requires good knowledge
> of that target + ideally access to
Hi all,
There has been talk about creating branches on the server, but
local branches eliminate the pressing need for public branches.
I believe public branches often result in tragedy of the commons;
without clear ownership, they may not be managed as efficiently as with
branches managed wholly i
On Sat, 2009-10-24 at 10:40 -0700, David Brownell wrote:
> On Saturday 24 October 2009, Zach Welch wrote:
> > we should start an 0.3.0-rc-dev series almost immediately.
>
> Better: just "0.3.0-rc". An RC series should not be
> getting much beyond bugfixes; it's not dev series.
I would say that o
On Sat, 24 Oct 2009, David Brownell wrote:
> > I'm very pleased we have successfully migrated to git
> > before 0.3.
>
> Yes; though as Nico pointed out, doing some work in
> branches would be a good thing. (I'm thinking of
> checking out "stgit" myself ... )
I was a quilt user before Git. The
On Sat, 24 Oct 2009, David Brownell wrote:
> On Saturday 24 October 2009, Igor Skochinsky wrote:
> > I think you need to fix your client unless some relay server screwed
> > up the message. Here, David's email headers say:
> > Content-Type: text/plain; charset="iso-8859-1"
> > Content-Transfer-Enc
Hello Colin,
I don't see the point of making an advanced disassembler out of
OpenOCD. I think the main purpose of adding the routine was to do some
spot checks during debugging. In fact, it's probably not really
necessary once gdb interface was implemented, as gdb can do
disassembly itself.
If you
On 25 Oct, 2009, at 01:36, Colin Howarth wrote:
>
> For those that do do assembly code, do you have a Good (TM)
> disassembler?
BTW, I wanted know if there's a free one available that i don't know
about — I didn't mean to imply that I'd written a good disassembler,
myself! :-)
At presen
Hello all,
I'm not entirely sure this is appropriate here, it being an OpenOCD
developer's list and not an ARM developer's list as such :-(
However, I was wondering how many of you actually code in ARM
assembler? Do you avoid it wherever you can, using a "high-level"
language and gcc?
F
Oleg,
Thanks for being responsive to David's requests. While this patch looks
great for reviewing your new device's support, I think that we should
avoid pushing it to the repository. We should wait for the libftdi
patch to be committed and scheduled for some future release.
Users should never
Anyone else noted how, now that Unicode is becoming slightly more
widespread, weird glyphs have started cropping up again?
On 24 Oct, 2009, at 21:07, David Brownell wrote:
> On Saturday 24 October 2009, Igor Skochinsky wrote:
>> I think you need to fix your client unless some relay server scre
Hi Dave,
Thank you for your feedback!
Unfortunately new Signalyzer H relies on FTDI's
FT_WriteEE()/FT_ReadEE() and similar functions from libftdi to
implement some of the functionality. The only reason for adding new
#define and --enable-signalyzer_h is because current libftdi
implementation does
On Saturday 24 October 2009, Igor Skochinsky wrote:
> I think you need to fix your client unless some relay server screwed
> up the message. Here, David's email headers say:
> Content-Type: text/plain; charset="iso-8859-1"
> Content-Transfer-Encoding: quoted-printable
Hmm ... while that message wa
On Saturday 24 October 2009, Øyvind Harboe wrote:
> But should vector_catch be arm9 specific even so? Doesn't
> xscale + arm11 support somesuch?
There are multiple vector_catch commands; just look
at the concept index in the User's Guide.
> I think the polymorphism at the C rather than command l
On Saturday 24 October 2009, Øyvind Harboe wrote:
> Seems like you are not too excited about register
> caching either
>
> Before deleting all register caching we have to consider
> the performance impact. Perhaps we could remove
> register caching from the user's point of view, but
> keep it
Hi,
On Sat, Oct 24, 2009 at 19:55, Øyvind Harboe wrote:
>> Yes; we're overdue to close this dev cycle, IMO.
>> I get the feeling Ųyvind is impatient for 0.4.0-dev ... :)
>
> One day I'll be able to post messages/email and have
> my name come out right: Øyvind.
>
> See http://www.zylin.com/contac
On Saturday 24 October 2009, Øyvind Harboe wrote:
> Hi D*vid & *ach,
>
> On Sat, Oct 24, 2009 at 7:40 PM, David Brownell wrote:
> > On Saturday 24 October 2009, Zach Welch wrote:
> >> we should start an 0.3.0-rc-dev series almost immediately.
> >
> > Better: just "0.3.0-rc". An RC series should
On 24 Oct, 2009, at 19:55, Øyvind Harboe wrote:
> Hi D*vid & *ach,
>
> On Sat, Oct 24, 2009 at 7:40 PM, David Brownell b...@pacbell.net> wrote:
>> Yes; we're overdue to close this dev cycle, IMO.
>> I get the feeling Ųyvind is impatient for 0.4.0-dev ... :)
>
> One day I'll be able to post messa
On Sat, Oct 24, 2009 at 7:13 PM, David Brownell wrote:
> On Saturday 24 October 2009, Øyvind Harboe wrote:
>> On Fri, Oct 23, 2009 at 10:37 PM, David Brownell wrote:
>> > On Friday 23 October 2009, Øyvind Harboe wrote:
>> >> Here is a thought:
>> >>
>> >> Retire arm9 vector_catch C code and write
Hi D*vid & *ach,
On Sat, Oct 24, 2009 at 7:40 PM, David Brownell wrote:
> On Saturday 24 October 2009, Zach Welch wrote:
>> we should start an 0.3.0-rc-dev series almost immediately.
>
> Better: just "0.3.0-rc". An RC series should not be
> getting much beyond bugfixes; it's not dev series.
I t
On Saturday 24 October 2009, Zach Welch wrote:
> we should start an 0.3.0-rc-dev series almost immediately.
Better: just "0.3.0-rc". An RC series should not be
getting much beyond bugfixes; it's not dev series.
Yes; we're overdue to close this dev cycle, IMO.
I get the feeling Øyvind is impatien
On Saturday 24 October 2009, Timo Boettcher wrote:
> openocd -f openocd/openocd.cfg -f openocd/olimex-arm-usb-ocd.cfg -f
> openocd/openocd-sam7s256.cfg -c "mt_flash_bin glow_flash.bin"
> I get:
>
> = begin openocd output =
> Warn : use 'sam7se256.cpu' as target identifier, not '0'
> Unkno
On Saturday 24 October 2009, Michael Schwingen wrote:
> If you want to spell out the vector names, the command arguments get
> target-specific - not sure if this is good.
Which means the command itself is target-specific...
at which point, common syntax is IMO ungood/misleading.
___
On Saturday 24 October 2009, Øyvind Harboe wrote:
> On Fri, Oct 23, 2009 at 10:37 PM, David Brownell wrote:
> > On Friday 23 October 2009, Øyvind Harboe wrote:
> >> Here is a thought:
> >>
> >> Retire arm9 vector_catch C code and write a Tcl
> >> proc instead on top of "reg vector_catch".
> >>
> >
Hi!
I am trying to configure openocd to run it fom my Makefile.
Running it manually works:
= begin openocd session =
% nc localhost
Open On-Chip Debugger
> halt
halt
target state: halted
target halted in ARM state due to debug-request, current mode:
Supervisor
cpsr: 0x205
Attached are the remaining patches for the first round of
target->type->mcr/mrc support.
There is a writeup in TODO of the harder targets
that remain. E.g. arm966e support requires good knowledge
of that target + ideally access to test hardware, so that's not
something I can or should attempt at t
---
.gitmodules |3 +++
tools/git2cl |1 +
2 files changed, 4 insertions(+), 0 deletions(-)
create mode 100644 .gitmodules
create mode 16 tools/git2cl
diff --git a/.gitmodules b/.gitmodules
new file mode 100644
index 000..2fcecfd
--- /dev/null
+++ b/.gitmodules
@@ -0,0 +1,3 @@
---
tools/release/version.sh | 137 ++
1 files changed, 137 insertions(+), 0 deletions(-)
create mode 100755 tools/release/version.sh
diff --git a/tools/release/version.sh b/tools/release/version.sh
new file mode 100755
index 000..bef79d0
--- /dev
---
tools/release/helpers.sh | 60 ++
1 files changed, 60 insertions(+), 0 deletions(-)
create mode 100644 tools/release/helpers.sh
diff --git a/tools/release/helpers.sh b/tools/release/helpers.sh
new file mode 100644
index 000..2dd5bae
--- /dev/
Update documentation to reflect GIT methodology.
Rewrite tools/release.sh script to use new GIT processes.
---
With this update, tools/release.sh may be used for producing private
releases in local branches. This allows distributors to easily produce
their own readily-identifiable packages with th
Runs the release.sh script in a freshly cloned repository, charting
one hypothetical future of OpenOCD's lineage.
---
tools/release/test.sh | 121 +
1 files changed, 121 insertions(+), 0 deletions(-)
create mode 100755 tools/release/test.sh
diff -
A '.*' rule prevents the 'git submodule add' from correctly adding the
first submodule, because it creates the .gitmodule file. This file will
not be added (without -f) result in incomplete submodule commits.
The new rules mask the specific files present in my own build tree, but
additional rules
Øyvind Harboe wrote:
> Is it unreasonable to have a common vector_catch syntax
> across e.g. Cortex, MIPS and ARMx for e.g. data abort?
Not sure. However, I think it might be difficult to have a common syntax
that can handle *all* kinds of catchable events on all targets,
including non-ARM.
Hi all,
The following series of patches present new GIT-based release scripts.
The associated documentation that describes the process requires work,
but some parts have been updated. Please provide feedback after testing
them on your own clones.
For testing, the last patch provides a test scri
On Fri, Oct 23, 2009 at 10:37 PM, David Brownell wrote:
> On Friday 23 October 2009, Øyvind Harboe wrote:
>> Here is a thought:
>>
>> Retire arm9 vector_catch C code and write a Tcl
>> proc instead on top of "reg vector_catch".
>>
>> Thoughts?
>
> Erm ... why?
>
> Rename "arm9tdmi" to "arm9", sure
On Sat, 2009-10-24 at 10:09 +0200, Øyvind Harboe wrote:
> Should we try to set a 0.3 schedule now that we're all
> switched to git?
We had been talking about 0.3 from before the transition off SVN.
With GIT, pushing commits to the repository should happen only after
full review, so recent feature
Should we try to set a 0.3 schedule now that we're all
switched to git?
2-3 weeks out?
--
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer
___
Openocd-development mailing list
Openocd-devel
On Sat, Oct 24, 2009 at 6:09 AM, Nicolas Pitre wrote:
> On Fri, 23 Oct 2009, Øyvind Harboe wrote:
>
>> Since this work will take place over some period of time, I had to
>> commit now.
>
> *IN* *A* *SEPARATE* *BRANCH* !!
OK.
Switching to branched development as of writing. I'm still
working on m
37 matches
Mail list logo
