On Thursday 28 January 2010, Austin, Alex wrote:
~/Projects $ size openocd.gcc
textdata bss dec hex filename
915920 11600 90668 1018188 f894c openocd.gcc
~/Projects $ size openocd.clang
textdata bss dec hex filename
902754 10684 90572
On Thursday 28 January 2010, David Brownell wrote:
If you want to know why the standard uses 1, there are
probably rationale documents circulating. I'd guess
one of the reasons is to facilitate bool == bit type
implementations ... signed bits are nonsensical!
Oh, and one more reason: a == a
Right now I seem to be the person doing this for the bugs
that can (or should!) affect the 0.4.0 release; nobody
volunteered to handle *any part of that* for the community.
Since I'm doing some testing these days, sign me up as a volunteer for
the bug database.
... And as far as I can tell,
There appears to be a certain amount of rot in the amt_jtagaccel driver,
That was my conclusion when I noticed, not long ago, that
it wouldn't even *build* with PPDEV enabled ... an issue
that's been around for quite some time.
I can post a patch for review of some of the fixups i've done so
On Tue, Jan 26, 2010 at 5:38 AM, David Brownell davi...@pacbell.net wrote:
On Tuesday 19 January 2010, Øyvind Harboe wrote:
Run the following and it will fail to halt occasionally. This is not a
regression,
but I thought I'd post this tip on how to reproduce flaky reset problems...
Got any
On Friday 29 January 2010, Matthew Fletcher wrote:
There appears to be a certain amount of rot in the amt_jtagaccel driver,
That was my conclusion when I noticed, not long ago, that
it wouldn't even *build* with PPDEV enabled ... an issue
that's been around for quite some time.
I can
Hi,
We could think to replace
kb/s
by
KBytes/s
or
kbytes/s
Or (and this is the best to use for me)
kbps as kilo bits per sec
mbps as mega bits per sec
the kb is for bytes or bits ?
the /s is used but it is not scientific ?
So I vote for kbps and mbps instead kb/s for any datarate in
On Friday 29 January 2010, Edgar Grimberg wrote:
Right now I seem to be the person doing this for the bugs
that can (or should!) affect the 0.4.0 release; nobody
volunteered to handle *any part of that* for the community.
Since I'm doing some testing these days, sign me up as a volunteer
As far as bug databases go, I'm kinda partial to ticgit. It stores the whole
bug database in one git branch that never actually gets checked out. It hasn't
been updated in a while, but it's not exactly a complex system, either.
http://wiki.github.com/schacon/ticgit/
From:
On Fri, Jan 29, 2010 at 10:50 AM, Edgar Grimberg
edgar.grimb...@zylin.com wrote:
On Tue, Jan 26, 2010 at 5:38 AM, David Brownell davi...@pacbell.net wrote:
On Tuesday 19 January 2010, Øyvind Harboe wrote:
Run the following and it will fail to halt occasionally. This is not a
regression,
but I
On January 28 2010, Matthew Fletcher wrote:
Can anyone verify that this interface is still functional in 0.4 ? Out
of 0.4-rc1, 0.3.1 and an old rev.131 fetch only the old rev.131 fetch
works to a certain extent. In all cases the openocd was built from
source on cygwin with only amt_jtagaccell
Can anyone verify that this interface is still functional in 0.4 ? Out
of 0.4-rc1, 0.3.1 and an old rev.131 fetch only the old rev.131 fetch
works to a certain extent. In all cases the openocd was built from
source on cygwin with only amt_jtagaccell and parport_give_io enabled
in configure.
On Friday 29 January 2010, Edgar Grimberg wrote:
JTAG tap: str710.cpu tap/device found: 0x3f0f0f0f (mfg: 0x787, part:
0xf0f0, ver: 0x3)
srst pulls trst - can not reset into halted mode. Issuing halt after reset.
Jazelle debug entry -- BROKEN!
Jazelle state handling is BROKEN!
target state:
On Friday 29 January 2010, Austin, Alex wrote:
On January 28 2010, Matthew Fletcher wrote:
Can anyone verify that this interface is still functional in 0.4 ? Out
of 0.4-rc1, 0.3.1 and an old rev.131 fetch only the old rev.131 fetch
By rev.131 do you mean the SVN ID? The one which
On Friday 29 January 2010, Laurent Gauch wrote:
Hi,
We could think to replace
kb/s
by
KBytes/s
or
kbytes/s
My vote: spell it out. And don't try to use the
widely-misunderstood b/bit B/byte convention.
Or (and this is the best to use for me)
kbps as kilo bits per sec
On Friday 29 January 2010, Matthew Fletcher wrote:
I will have a look when i have some time, and if git works on cygwin.
Yes it does; current cygwin has a git package.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
but i think
amt_jtagaccel / common_arm7-9 needs some attention as stepping in arm thumb
mode seems to cause invalid instruction traps and is generally pretty
unstable.
I think it was Nico who had a bunch of Thumb stepping fixes.
The quantity made me suspect there were likely more issues
My mistake - I read too fast. Correction inline. I've used the
amt_jtagaccel on v0.1.0, so I'm pretty sure it works. I don't have a
working test setup right now, though.
On January 28 2010, Matthew Fletcher wrote:
Can anyone verify that this interface is still functional in 0.4 ? Out
of
On Friday, January 29, 2010, David Brownell wrote:
...
I'd rather see kilo bytes (KB) not Kibi bytes (KiB)
in such contexts too. Kilobytes per second is something
I can often do math with in my head. Kibibytes, not;
likewise kilobits per second.
The problem with doing math with
The physical ETM trace port of a new ARM ( Cortex) is including one
clock line + 4 Data Line
Anyone knows if the ETM Trace packet is ever based 32bits (8 nibbles) or
could be 16bits (4 nibbles) ?
Regards,
Laurent
___
Openocd-development mailing list
This would help to avoid picking a magic value for true.
#define false 0
#define true (!false) // this will actually evaluate to 1
On the other hand, code that relies on specific values for true is
IMHO buggy or at least error prone (especially if true == -1!!),
which implies that the define
Andreas Fritiofson wrote:
This would help to avoid picking a magic value for true.
#define false 0
#define true (!false) // this will actually evaluate to 1
IMHO, this is unnecessary obfuscation.
The C standard guarantees that this will evaluate to 1, so why not write
1 directly?
On the
I'm trying to get openOCD to work with the PNX8009. It was originally
developed by NXP, but is now manufactured by DSPG. The only non-NDA'd
info I can find is mcuol.com/download/upfile/75016086.pdf
I'm having trouble getting a usable datasheet from DSPG, so I'm flying a
little blind. What I've
On Friday 29 January 2010, Andreas Fritiofson wrote:
On the other hand, code that relies on specific values for true is
IMHO buggy or at least error prone (especially if true == -1!!),
which implies that the define shouldn't be used at all in comparisons.
That was implicit in the point I made
On Friday 29 January 2010, Matthew Fletcher wrote:
Are you testing on a chip with an ICE that
does hardware stepping?
Its a phillips/NXP LPC2292, it does have EmbeddedICE but im
not 100% sure in what mode of operation i've got it.
So it's an ARM7TDMI. Those don't have the hardware
On Friday 29 January 2010, Laurent Gauch wrote:
The physical ETM trace port of a new ARM ( Cortex) is including one
clock line + 4 Data Line
I thought that was a fairly standard option lately ... some trace ports
support more bandwidth (e.g. 64 bits), most can throttle down to 4 bits
(or
On Fri, Jan 29, 2010 at 7:11 PM, Michael Schwingen
rincew...@discworld.dascon.de wrote:
Andreas Fritiofson wrote:
This would help to avoid picking a magic value for true.
#define false 0
#define true (!false) // this will actually evaluate to 1
IMHO, this is unnecessary obfuscation.
The C
27 matches
Mail list logo
