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
"Spencer Oliver" wrote on 2009-08-18 16:43:32:
> >
> > I found some odd things in ft2232.c when it is built with
> > FT2232H/FT4232H support :
> >
> > 1. It can only be built with the FTD2XX driver. libftdi
> > supports FT2232H/FT4232H
> > since version 0.16
> >
> > 2. A speed value of 0
Fix some command helptext:
- spell "address" right
- list bp/wp params as optional
And make those source lines wrap at sane margins.
---
src/target/target.c | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
--- a/src/target/target.c
+++ b/src/target/target.c
@@ -1505,
Clean up some Cortex-M3 reset handling.
- AIRCR_SYSRESETREQ is generic; use it on any system where
SRST won't fly, not just on Stellaris-based ones.
- Reformat and improve comments about the Stellaris quirk; and
xref the only public docs (an email) about the issue.
It seems that *most* S
On Tuesday 18 August 2009, Dean Glazeski wrote:
> I can't disable the building of libraries so I assumed the library was
> in use by the OpenOCD executable. Am I mistaken?
On this system:
$ ldd src/openocd
linux-vdso.so.1 => (0x7fff7dbfe000)
libdl.so.2 => /lib/libdl.so.2 (0
Hi everybody!
The mail: sopo...@rdss.com.ar it is mine. Now, I will disable the email, and
change it from the "Open-OCD" list. Please sorry, I am very sorry for the
problem. I hope that you will understand.
Best regards,
Sebastián.
___
Openocd-developme
I can't disable the building of libraries so I assumed the library was
in use by the OpenOCD executable. Am I mistaken? If so, I can just
have the spec file delete the libraries that the make process creates.
If there is a configuration option I need to use to make the final
server not use a
I will post it when I am done.
I now realise that this is not so simple, because it might be necessary
to write a device driver for the NAND controller.
So may be it will take a while
Cheers,
Ferdinand
Øyvind Harboe schreef:
> Please post the script to the list so it can be included in the
>
> *MY* concensus is that it should merge. ;)
>
>
> > Do we need also need a 'reg all' when you do want to see
> all the regsiters
>
> On an ARM9 with EmbeddedICE, ETM, and ETB there are over 160
> registers;
> showing "all" would be nasty. "reg r0 r3 r8 sp" would be
> nice; in fact
that
Committed.
*great* work btw. It's nice to see a nicely fleshed out
config file that contains a lot of comments and
also utility fn's.
--
Øyvind Harboe
Embedded software and hardware consulting services
http://www.zylin.com
___
Openocd-development mai
>
> I found some odd things in ft2232.c when it is built with
> FT2232H/FT4232H support :
>
> 1. It can only be built with the FTD2XX driver. libftdi
> supports FT2232H/FT4232H
> since version 0.16
>
> 2. A speed value of 0 is used as a RTCK request indicator.
> This clashes with the
> va
It's not all I want it to be, but it's more than what I started with.
I hope it helps someone else.
Best!
Brian Findlay
mini2440.cfg
Description: Binary data
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists
>
> Attached is an new patch that replace the previous one that had
> some problems.
> * I was not aware of that some interfaces operate on the JTAG
> bus in the initialization routine (the j-link issue a TLR).
> The clock must be configured by the initialization routine
> before the op
I'm not sure it is as simple as changing the casts. I suspect you are
*not* compiling for PC?
IMHO: The problem is that the buffers may not be aligned on word
boundaries. This may result in problems on platforms which have a strict
alignment. Another problem is that it may result in code which is
arm_jtag.h: In function `arm7flip32':
arm_jtag.h:64: warning: cast increases required alignment of target type
arm_jtag.h: In function `arm_le_to_h_u32':
arm_jtag.h:70: warning: cast increases required alignment of target type
...
I made 3 patch files, all warnings are same, but way of fixing are
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
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
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
On Tuesday 18 August 2009, Piotr Ziecik wrote:
> Due to errors in chipselect management in davinci_nand driver
> OpenOCD was able to access only to chips attached to first EMIF
> chipselect. This patch fixes chipselect management code and allows
> OpenOCD to access to NAND devices attached to any E
Cleanup the Stellaris target configs:
- remove endianness options; these chips hard-wire "little"
- $_TARGETNAME updates:
* don't pass $_TARGETNAME where a TAP label is required
* flash config uses $_TARGETNAME (it might not be target #0)
* simplify one $_TARGETNAME construction
- u
Add "cortex_m3 vector_catch" command and docs. One minor
issue with this is that the core debug support uses this
mechanism, then trashes its state over reset. Users can
Work around that (for now) by re-assigning the desired
config after reset.
Also fixes "target halted due to target-not-halted"
Several of the ARMv7M registers are 8 bits or less; don't
display them as 32 bits unless that's their true size.
(Removes some confusion.)
---
src/target/armv7m.c | 49 +
1 file changed, 25 insertions(+), 24 deletions(-)
--- a/src/target/armv7m.c
Clean up ARM7/ARM9 EmbeddedICE register handling ... don't use parallel
arrays (error prone) or assume all registers are 32-bits wide (they can
have fewer bits); don't use spaces in register names, so they can be
passed more easily to the "reg" command.
Minor updates for ARM9 vector_catch support:
On Friday 07 August 2009, Spencer Oliver wrote:
>
> Just wondering what the general concensus is on this?
*MY* concensus is that it should merge. ;)
> Do we need also need a 'reg all' when you do want to see all the regsiters
On an ARM9 with EmbeddedICE, ETM, and ETB there are over 160 regist
I couldn't possibly comment on whether this is the right
thing to do.
Any objections out there to committing?
--
Øyvind Harboe
Embedded software and hardware consulting services
http://www.zylin.com
___
Openocd-development mailing list
Openocd-developme
Due to errors in chipselect management in davinci_nand driver
OpenOCD was able to access only to chips attached to first EMIF
chipselect. This patch fixes chipselect management code and allows
OpenOCD to access to NAND devices attached to any EMIF CS line.
Signed-off-by: Piotr Ziecik
---
src/fla
29 matches
Mail list logo
