> >
> > In spens case, yes, I think something did change.
> >
> > I think SPEN is thinking "reset" - plain - halts the CPU.
> But it does
> > not - it does "reset run".
> >
> > I think that decision - which happened about 1 month ago -
> was perhaps
> > a bad choice (there was lots of email ab
On Fri, Oct 17, 2008 at 5:41 AM, Duane Ellis <[EMAIL PROTECTED]> wrote:
> spen> [confused about reset events]
>
> oyvind> [ go read the source code ]
>
> This needs a bit more documentation :-(
>
> In spens case, yes, I think something did change.
>
> I think SPEN is thinking "reset" - plain - halt
> Step 3
>
> We create a new "event" - that does -invokes a TCL script.
>
> That TCL script does the following:
>
> (a) wiggle pins and configure the JRC tap.
> (b) executes the "jtag order" command.
Could you clarify this a bit more?
I'm wondering if we should reduce the # of events
spen> [confused about reset events]
oyvind> [ go read the source code ]
This needs a bit more documentation :-(
In spens case, yes, I think something did change.
I think SPEN is thinking "reset" - plain - halts the CPU. But it does
not - it does "reset run".
I think that decision - which hap
Fabio> I am trying to write to MX31 (ARM11) CP15 registers
Fabio> using OpenOCD. The commands I want to perform are:
Fabio> setreg @CP15_CONTROL=0x00050078
[snip]
Georg> [it works, using the mcr/mrc commands]
fabio> Thanks. It worked as follows:
fabio> monitor arm11 mcr 1 0 0 15 2 4 0x00050078
f
Øyvind Harboe wrote:
> Here is a thought:
>
> - define jtag device/target num to be a unique id that has nothing
> to do with the ordering of targets/jtag devices
>
This exists now for the TARGET - not for the TAP chain.
(ie: remember the [new_target_name] thing?)
> - the jtag device chain can
duane> Can we get confirmation about how the JRC works in OMAP?
kees> I am sure there must be exceptions to your rules but I guess that
having this 3rd state will make it very easy to implement what we need
right now
kees>Why are those assumptions important? Why is is hard to "insert" an
eleme
Laurentiu Cocanu wrote:
> Hi
> I integrated READ_TARGET_COMMENT.txt content into openocd general
> documentation (outputted as openocd.pdf).
Thank you for doing that for me! I really appreciate it.
-Duane (they guy who was to lazy to do that)
___
On Thu, Oct 16, 2008 at 11:17 PM, Spen <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I am unable to get either of the following working.
>
> target_script 0 reset program.ocr
> [new_target_name] configure -event reset-init { script program.ocr }
>
> Looks like the TARGET_EVENT_RESET_INIT never gets called a
Hi,
I am unable to get either of the following working.
target_script 0 reset program.ocr
[new_target_name] configure -event reset-init { script program.ocr }
Looks like the TARGET_EVENT_RESET_INIT never gets called anywhere, has
something changed?
If i change the reset-init to reset_start then
Georg,
--- On Thu, 10/16/08, Georg Acher <[EMAIL PROTECTED]> wrote:
> From: Georg Acher <[EMAIL PROTECTED]>
> Subject: Re: [Openocd-development] ARM11 CP15 access support
> To: openocd-development@lists.berlios.de
> Date: Thursday, October 16, 2008, 2:46 PM
> On Thu, Oct 16, 2008 at 10:12:06AM -0
> >>
> >> Help already exists...
> >>
> >
> > Could i ask where ?
>
> help fill
>
> =>
> register_command(cmd_ctx, flash_cmd, "fillw",
> handle_flash_fill_command, COMMAND_EXEC,
>"fill with
> pattern ");
> register_co
I already had the lm3s8962 working on Ubuntu 8.04 with OpenOCD using
libftdi (Never tried the official one).
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
target and jtag device number is used to tie a target to a jtag device.
However with jtag devices being enabled/disabled, device num no longer has
an unambigous meaning.
If we allow reordering the jtag chain, then device num becomes even
less well defined.
Here is a thought:
- define jtag dev
On Thu, Oct 16, 2008 at 7:44 PM, Kees Jongenburger
<[EMAIL PROTECTED]> wrote:
> On Wed, Oct 15, 2008 at 1:16 AM, Duane Ellis <[EMAIL PROTECTED]> wrote:
>> Attention Beagle Guys,
>
> Hello Duane.
>
> I am sure there must be exceptions to your rules but I guess
> that having this 3rd state will make
The warnings are trying to tell you that performance will
suck without working memory
How would you suggest that OpenOCD should convey the
need for working memory to improve performance?
Manual?
More printed warnings?
Ideas?
There is no sarcasm in the above, I believe it to be a genuine
pr
On Thu, Oct 16, 2008 at 10:12:06AM -0700, Fabio Estevam wrote:
> Hi,
>
> I am trying to write to MX31 (ARM11) CP15 registers using OpenOCD. The
> commands I want to perform are:
>
> setreg @CP15_CONTROL=0x00050078
> // configuring CP15 for enabling the pripheral bus
> setreg @CP15_PERIP_MEM_REMAP=
Hi,
Sorry, new here.
Target PCB/board description
Stellaris Lm3s8962 Cortex from
http://www.luminarymicro.com/products/LM3S8962.html
- Config scripts
#daemon configuration
telnet_port
gdb_port
#interface
interface ft2232
ft2232_device_desc "Stellaris Evaluation Board"
ft2232_lay
On Wed, Oct 15, 2008 at 1:16 AM, Duane Ellis <[EMAIL PROTECTED]> wrote:
> Attention Beagle Guys,
Hello Duane.
I am sure there must be exceptions to your rules but I guess
that having this 3rd state will make it very easy to implement what we
need right now
Why are those assumptions important?
Wh
Read:
http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS
also try adding working memory.
--
Ø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
Hi,
I am trying to write to MX31 (ARM11) CP15 registers using OpenOCD. The commands
I want to perform are:
setreg @CP15_CONTROL=0x00050078
// configuring CP15 for enabling the pripheral bus
setreg @CP15_PERIP_MEM_REMAP=0x4015
(This is RealView tool sintax)
Is this currently supported on O
Hi Guys,
I am using Ubuntu 8.04 TLS, OpenOCD cortex-m3, ftd2xx0.4.15 driver. To
flash 111kb .bin file
in telnet terminal:
wrote file myfile.bin to flash bank 0 at offset 0x in 429s 916774us
in OpenOCD terminal:
Warning: stellaris.c:724 stellaris_write(): couldn't use block writes,
fa
On Thu, Oct 16, 2008 at 6:41 PM, Spen <[EMAIL PROTECTED]> wrote:
>> > Did not even realise we had a flash fill function!
>> > Could be worth adding something to the docs.
>>
>> Help already exists...
>>
>
> Could i ask where ?
help fill
=>
register_command(cmd_ctx, flash_cmd, "fil
> > Did not even realise we had a flash fill function!
> > Could be worth adding something to the docs.
>
> Help already exists...
>
Could i ask where ?
Cheers
Spen
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lis
On Thu, Oct 16, 2008 at 3:03 PM, Spen <[EMAIL PROTECTED]> wrote:
>>
>> This makes it possible for flash fill to modify part of a
>> sector. Erase can still be invoked seperately and explicitly.
>>
>
> Did not even realise we had a flash fill function!
> Could be worth adding something to the docs.
On Thu, Oct 16, 2008 at 3:13 PM, Laurentiu Cocanu
<[EMAIL PROTECTED]> wrote:
> Hi
> I integrated READ_TARGET_COMMENT.txt content into openocd general
> documentation (outputted as openocd.pdf).
Commited.
Thanks!
--
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 XScale Cortex
JTAG de
Hi
I integrated READ_TARGET_COMMENT.txt content into openocd general
documentation (outputted as openocd.pdf).
Index: openocd.texi
===
--- openocd.texi(revision 1065)
+++ openocd.texi(working copy)
@@ -941,6 +941,449 @@
>
> This makes it possible for flash fill to modify part of a
> sector. Erase can still be invoked seperately and explicitly.
>
Did not even realise we had a flash fill function!
Could be worth adding something to the docs.
Cheers
Spen
___
Openocd-d
Committed.
This makes it possible for flash fill to modify part of a sector. Erase can
still be invoked seperately and explicitly.
### Eclipse Workspace Patch 1.0
#P openocd
Index: src/flash/flash.c
===
--- src/flash/flash.c (revis
29 matches
Mail list logo
