Committed.
Thanks!
--
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 XScale Cortex
JTAG debugger and flash programmer
Free eCos workshop in Oslo October 21!
http://www.zylin.com/workshop.html
___
Openocd-development mailing list
Openocd-dev
Committed.
Thanks!
--
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 XScale Cortex
JTAG debugger and flash programmer
Free eCos workshop in Oslo October 21!
http://www.zylin.com/workshop.html
___
Openocd-development mailing list
Openocd-dev
Hi,
here is the whitespace corrected and attached patch. I also reduced the
retries from 16 to 4. I plan to get rid of them entirely eventually.
Cheers,
John McC.
On Tue, 2008-10-07 at 07:43 +0100, Spen wrote:
> John,
>
> >
> > The following patch adds support for DMA mode access as
> > supp
fabio>What has been your experience with MX27 and OpenOCD? Is it working
well?
[I added iMX27 to the subject to help others find message via search
engines]
Works for ARM mode, seems to have major problems with THUMB mode.
I'm not sure about "cache enabled" debugging. :-( - I have more testing
Hello once again,
I noticed that the dbg_write_u16() and dbg_write_u8 functions of
libdcc don't work as expected.
The following Patch will update it to my modified version (which also
includes a dbg_trace_point() function.
Signed-off-by: Frederik Kriewitz <[EMAIL PROTECTED]>
Index: contrib/libdc
On Mon, Oct 06, 2008 at 06:39:24PM -0400, Duane Ellis wrote:
> somebody> I'm not convinced that your JTAG chain is configured correctly
> somebody> or that your JTAG interface is able to communicate with the
> device.
> somebody> ARM11 is finicky
>
> I believe this is exactly the ARM 1176 chip.
One concern I have about testing is availability of targets.
There is, for all practical purposes, an infinite number of combinations
of CPU cores & PCBs out there.
Hopefully as OpenOCD matures, the differences will matters less.
Nothing will replace test farms and we have a sizeable collection
Please recreate the patch against latest version of openocd.c and
post it as a .txt attachment.
openocd.c is troublesome to create patches against due to keyword
expansion, but hopefully the latest version of openocd.c will put those
silly patch problems to bed...
--
Øyvind Harboe
http://www.z
Committed.
Fixes SEGFAULT when setting registers from GDB.
set $cpsr=1234
=> SEGFAULT
Similar problems existed across ARM, Cortex, MIPS and ARM11.
Thanks to Spen for pointing that out!
I didn't test all the cases, I just duplicated the fix from Cortex to
the rest of the code.
Xing fingers t
Committed.
Thanks!
--
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 XScale Cortex
JTAG debugger and flash programmer
Free eCos workshop in Oslo October 21!
http://www.zylin.com/workshop.html
___
Openocd-development mailing list
Openocd-dev
Commands to reproduce:
trace point 1
trace point clear
trace point clear
Signed-off-by: Frederik Kriewitz <[EMAIL PROTECTED]>
Index: src/target/trace.c
===
--- src/target/trace.c (revision 1024)
+++ src/target/trace.c (working cop
On Tue, Oct 7, 2008 at 6:00 PM, Spen <[EMAIL PROTECTED]> wrote:
>
> Not sure what to make of this one - the same code is pretty much used in the
> arm4_5 handling.
> so that probably needs checking aswell.
Really???
> I am guessing but it looks like the arch_type of reg_t is causing the
> initia
On Tue, 2008-10-07 at 18:20 +0200, Dominic wrote:
> On Tuesday 07 October 2008 14:57:37 John McCarthy wrote:
> > On Mon, 2008-10-06 at 18:58 -0400, Duane Ellis wrote:
> > > John McCarthy wrote:
> > > > Hi,
> > > >
> > > > has anyone got OpenOCD working with a Faraday FA526 processor (actually
> > >
On Tuesday 07 October 2008 14:57:37 John McCarthy wrote:
> On Mon, 2008-10-06 at 18:58 -0400, Duane Ellis wrote:
> > John McCarthy wrote:
> > > Hi,
> > >
> > > has anyone got OpenOCD working with a Faraday FA526 processor (actually
> > > a Raritan Kira100 which uses a FA526 processor)? It appears
Not sure what to make of this one - the same code is pretty much used in the
arm4_5 handling.
so that probably needs checking aswell.
I am guessing but it looks like the arch_type of reg_t is causing the
initial problem.
also i struggle to understand why it has only appeeared now!!
Cheers
Spen
I'm using openocd to do both programming the flash and a separate
debugging instance afterwards. The program script needs to tell openocd
to shutdown at the end if programming has been successful, otherwise the
debugging session can't start, however the exit status is always 1
whether or not it
> I do write SDRAM setup code, and believe me, I would rather
> skip re-doing that in the form of a openocd init script if I
> can. On the IXP42x, getting the SDRAM up is quite easy, but
> on some DDR1/DDR2 controllers I have seen that require DQS
> calibration depending on the board layout, it
Timothy Clacy wrote:
> I'm not sure the details of setting-up SDRAM/DDR2 are too much of a
> problem. I would imagine many OpenOCD users are embedded system
> developers and have to write the SDRAM/DDR setup code anyway for their
> firmware. Also, I'm sure you would quickly build-up code sequences
On Mon, 2008-10-06 at 18:58 -0400, Duane Ellis wrote:
> John McCarthy wrote:
> > Hi,
> >
> > has anyone got OpenOCD working with a Faraday FA526 processor (actually
> > a Raritan Kira100 which uses a FA526 processor)? It appears to be an
> > ARM926 variant but apparently not exactly. Does this re
> michael> That depends. Getting DDR2 SDRAM controllers
> initialized can be
> a quite tedious task,
> michael> so you may be stuck with what internal SRAM you
> have available.
> michael> The IXP42x has 2k mini-IC available for code, other CPUs may
> have even smaller TCMs
The PXA25x (and PXA2
On Tue, Oct 7, 2008 at 2:36 PM, Frederik Kriewitz <[EMAIL PROTECTED]> wrote:
> On Tue, Oct 7, 2008 at 2:08 PM, Øyvind Harboe <[EMAIL PROTECTED]> wrote:
>> Committed:
>>
>> Fixed crash in dummy register handling
> Thank you, that seems to fix the problem.
>
> "set arm apcs32 off" will prevent messin
On Tue, Oct 7, 2008 at 2:08 PM, Øyvind Harboe <[EMAIL PROTECTED]> wrote:
> Committed:
>
> Fixed crash in dummy register handling
Thank you, that seems to fix the problem.
"set arm apcs32 off" will prevent messing with the T Bit but it will
trim your PC to 24 too.
If using CodeSourcery setting the
Hi Duane,
--- On Tue, 10/7/08, Duane Ellis <[EMAIL PROTECTED]> wrote:
...
>
> I do not know about the I/O voltage on the IMX31 - but I do
> know about
> the iMX27 - it is 1.8V, not 3.3V
Thanks.
What has been your experience with MX27 and OpenOCD? Is it working well?
Thanks,
Fabio Estevam
Committed:
Fixed crash in dummy register handling
### Eclipse Workspace Patch 1.0
#P openocd
Index: src/target/armv7m.c
===
--- src/target/armv7m.c (revision 1023)
+++ src/target/armv7m.c (working copy)
@@ -8,6 +8,9 @@
* Copyri
On Tue, Oct 7, 2008 at 12:19 PM, Duane Ellis <[EMAIL PROTECTED]> wrote:
> Øyvind Harboe wrote:
>>
>> DRAM makes this more complicated in that non-working ram
>> mode has to be supported.
>>
>> Obviously with DRAM *quantity* of RAM is even less of a problem.
>>
>>
>
> Why must "non-working-ram" mode
> Rather then very low level instructions (ie: zpu) I believe a higher level
The zpu is low level to the code that interprets it, but high level to
the developer: use C w/GCC.
There is a lot of ideas in the air at this point, but I sense a lack of
enthusiasm for the interpreted approach.
--
Øy
Committed:
Georg Acher <[EMAIL PROTECTED]> - arm11 wip. run algorithm + small init bugfix.
Thanks!
--
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 XScale Cortex
JTAG debugger and flash programmer
Free eCos workshop in Oslo October 21!
http://www.zylin.com/workshop.html
Michael Schwingen wrote:
duane> Assertion:
duane> During "flash programing", openocd controls the world and the chip.
duane> And - there is "ram to be had some where" that openocd can use.
michael> That depends. Getting DDR2 SDRAM controllers initialized can be
a quite tedious task,
michael> so
I believe the following is a reasonable summery of where we are.
-Duane.
=
(a) There is little to no ram what so ever in the target.
=
Option 1
Duane feels there is always 4K or more.
Others point out 4K is not alw
Øyvind Harboe wrote:
> I'd like to stick to C (and GCC) as the tool to describe
> target algorithms.
>
> For MIPS/ARM this means position independent code
> w/some clever entrypoint handler.
>
> Assuming all interesting target types can generate position
> independent code: why would we want to int
John McCarthy wrote:
> I was thinking along the same lines. This way we write an opcode stream
> definition for each flash type which works for all targets (with
> external flash). And for each target implementation we provide an
> opcode interpreter and a fast buffer transfer mechanism. The tar
Øyvind Harboe wrote:
> DRAM makes this more complicated in that non-working ram
> mode has to be supported.
>
> Obviously with DRAM *quantity* of RAM is even less of a problem.
>
>
Why must "non-working-ram" mode be supported?
___
Openocd-developm
Fabio Estevam wrote:
> Hi,
>
> I have researched in the list archives and have seen some attempts to get
> MX31 support under OpenOCD.
>
> Has anyone succesfully used OpenOCD with MX31 processor? If so, which JTAG
> hardware have you used?
>
> Thanks,
>
> Fabio Estevam
>
I do not know about t
Hi,
attached is first-try patch of run_algorithm for arm11. It's far from
complete because I don't know anything about modes and states in openocd and
the CPU. Context save/restore is implemented, but I haven't tested it more
than looking at the register dump.
At least it works for me (TM) ;-)
Al
On Mon, 6 Oct 2008, Magnus Lundin wrote:
> Hi
>
> I am just guessing here but it can an issue with the timing of the AHB
> bus and running from flash at 50MHz.
> The SWLDP overrun is received through the JTAG interface, so it seems
> JTAG is working.
> SWDLP overruns are not JTAG problems, they a
Duane Ellis wrote:
> Michael Schwingen wrote:
>> The C code reads its parameters directly from params, and writes its
>> result there.
> Agreed, sounds simple. But I do not think "code-lets" is the right idea.
> It is too simplistic.
>
> Reasoning:
>
> Most "flash sequences" are simplistic, ther
Duane Ellis wrote:
>> There is an objloader in eCos w/a suitable license model.
>> But perhaps we can do position independent code on all targets w/GCC?
>>
> If it requires a "obj loader" we have made something to complex.
It it either that or requiring relocatable code. However, that decision
Duane Ellis wrote:
> Michael Schwingen wrote:
>> First, I think the target code should stay as small as possible,
>> because there may be targets where very little RAM is available for
>> the code.
>
> I disagree, I think we always have 4K of ram, here's why:
>
> Generally:
>There are two
I'd like to stick to C (and GCC) as the tool to describe
target algorithms.
For MIPS/ARM this means position independent code
w/some clever entrypoint handler.
Assuming all interesting target types can generate position
independent code: why would we want to introduce a
CPU independent language/o
On Tue, Oct 7, 2008 at 3:37 AM, Duane Ellis <[EMAIL PROTECTED]> wrote:
> Michael Schwingen wrote:
>> The C code reads its parameters directly from params, and writes its result
>> there.
> Agreed, sounds simple. But I do not think "code-lets" is the right idea.
> It is too simplistic.
>
> Reasonin
On Tue, Oct 7, 2008 at 2:37 AM, Duane Ellis <[EMAIL PROTECTED]> wrote:
> Michael Schwingen wrote:
>> First, I think the target code should stay as small as possible, because
>> there may be targets where very little RAM is available for the code.
>>
>
> I disagree, I think we always have 4K of ram
On Tue, Oct 7, 2008 at 4:36 AM, Fabio Estevam <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I have researched in the list archives and have seen some attempts to get
> MX31 support under OpenOCD.
>
> Has anyone succesfully used OpenOCD with MX31 processor? If so, which JTAG
> hardware have you used?
We'v
42 matches
Mail list logo
