On 26/04/2011 23.08, Øyvind Harboe wrote:
The problem is that the ft2232_init() fn will invoke
jtag_xxx() fn's.
However, until ft2232_init() returns, the interface is
not set up and that part of the API is not open for business,
causing strange effects.
ft2232_init() sets up a default speed.
I've noticed strange behaviour in initialization with TI OMAP4430 and
Freescale iMX53 using Amontec JTAGKEY. Even typing keys on OpenOCD shell
was very very slow.
I didn't investigate too much the causes. Anyway this patch fix it.
Signed-off-by: Luca Ellero lro...@gmail.com
---
src/jtag/core.c
I haven't the hardware at hand for testing.
Regards
Luca Ellero
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
On 20/04/2011 9.39, Øyvind Harboe wrote:
Looks a good patch to me. Bringing SMP support on OpenOCD is very good!
Unfortunately at the moment I haven't the hardware at hand for testing.
Thanks for the feedback!
What about the danger of regressions or effects on non-SMP
debugging?
(I haven't
On 20/04/2011 14.35, Michel JAOUEN wrote:
Hello,
I have a panda board. So I can do the test.
In file, omap4430.cfg , only one cortex_a8 is defined.
What is the dbg_base of the second one?
Best regards
Hi Michel,
if you check omap4430.cfg you can find the following info:
# APB DBGBASE
access even if mmu is on :
(This support is needed for ste u8500, DDR is not accessible from ap mem)
Best regards
-Original Message-
From: Øyvind Harboe [mailto:oyvind.har...@zylin.com]
Sent: Monday, April 11, 2011 8:26 PM
To: Michel JAOUEN
Cc: luca ellero; openocd-development
Signed-off-by: Luca Ellero lro...@gmail.com
---
src/target/arm_opcodes.h | 12
1 files changed, 12 insertions(+), 0 deletions(-)
mode change 100644 = 100755 src/target/arm_opcodes.h
diff --git a/src/target/arm_opcodes.h b/src/target/arm_opcodes.h
old mode 100644
new mode 100755
Signed-off-by: Luca Ellero lro...@gmail.com
---
tcl/target/imx53.cfg | 51 ++
1 files changed, 51 insertions(+), 0 deletions(-)
create mode 100644 tcl/target/imx53.cfg
diff --git a/tcl/target/imx53.cfg b/tcl/target/imx53.cfg
new file mode 100644
Freescale iMX53 doesn't seem to like unaligned accesses to his memory
mapped registers.
Anyway this patch makes dump_image/load_image 4X faster for every
access through APB.
Signed-off-by: Luca Ellero lro...@gmail.com
---
src/target/cortex_a.c | 90
On 02/04/2011 18.32, Øyvind Harboe wrote:
How did you test?
Do you have a list of features that work and doesn't work for pandaboard now?
Hi Øyvind,
I just did some basic testing:
- halting processor
- read/write memory/registers
- stepping
- resetting CPU
- setting hardware breakpoints
-
On 04/04/2011 9.43, Øyvind Harboe wrote:
Thanks for testing! That's a pretty good list to kick things off!
Features still to be implemented on PandaBoard (and all others Cortex-A*)
are:
- software breakpoints
Presumably the issue here is how to deal with caching?
I didn't investigate too
On 31/03/2011 19.02, Øyvind Harboe wrote:
Do we delete the dbgbase patchup code now that we
have automatic detection default with manual override?
..ehm, sorry, I think I've miss something here: if you remove dbgbase
code, how can be made manual override?
Thanks
Luca
On 01/04/2011 9.00, Øyvind Harboe wrote:
On Fri, Apr 1, 2011 at 9:01 AM, luca ellerolro...@gmail.com wrote:
On 31/03/2011 19.02, Øyvind Harboe wrote:
Do we delete the dbgbase patchup code now that we
have automatic detection default with manual override?
..ehm, sorry, I think I've miss
On 29/03/2011 22.58, Tormod Volden wrote:
On Tue, Mar 29, 2011 at 10:35 PM, Øyvind Harboe wrote:
How about adding a contribute script which did the following:
- fetch from origin
- commit changes from user, bringing up a text editor with
a template commit message.
- rebase origin to the master
On 21/03/2011 14.20, Øyvind Harboe wrote:
I didn't do anything clever here.
Reading the cortex_a9/a8.c logs it looked like Cortex A8 had simply
been abandoned, so I copied cortex_a9.c onto cortex_a8.c, did a quick
search and replace job and deleted cortex_a9.c.
Any objections?
Insights?
Does
add new mem_ap_sel_* functions (as was made for cortex_a9)
see commit: 779005f43dc372de937dfd4b445f31d882b98eca
Signed-off-by: Luca Ellero lro...@gmail.com
---
src/target/cortex_a8.c | 128 ++-
1 files changed, 60 insertions(+), 68 deletions(-)
diff
stm32-discovery evaluation board (STM32F100RBTB6):
reading device id register (0xE0042000) returns 0x10010420
Signed-off-by: Luca Ellero lro...@gmail.com
---
tcl/target/stm32.cfg |9 +
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/tcl/target/stm32.cfg b/tcl/target
... :-)
Best regards,
Tomek
[1] http://stm32primer2swd.sf.net/
[2] http://libswd.sf.net
That's good, OpenOCD for now is still very JTAGcentric. So SW develop
is always welcome.
regards
Luca Ellero
___
Openocd-development mailing list
Openocd
adiv5_dap) to ap_current
- adds apsel member
this strange choice is made trying to keep coherence in dap apsel command
and to keep compatibility with other code (for example cortex_a8).
Signed-off-by: Luca Ellero lro...@gmail.com
---
Take this patch only as a proposal, I don't want to make changes
Signed-off-by: Luca Ellero lro...@gmail.com
---
src/target/cortex_a9.c | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/src/target/cortex_a9.c b/src/target/cortex_a9.c
index c13d41c..3ad7a7d 100644
--- a/src/target/cortex_a9.c
+++ b/src/target/cortex_a9.c
Signed-off-by: Luca Ellero lro...@gmail.com
---
src/target/cortex_a9.c | 22 ++
1 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/src/target/cortex_a9.c b/src/target/cortex_a9.c
index 3ad7a7d..422da3f 100644
--- a/src/target/cortex_a9.c
+++ b/src/target
Signed-off-by: Luca Ellero lro...@gmail.com
---
src/target/cortex_a9.c | 13 +++--
1 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/src/target/cortex_a9.c b/src/target/cortex_a9.c
index e411335..c13d41c 100644
--- a/src/target/cortex_a9.c
+++ b/src/target/cortex_a9.c
Signed-off-by: Luca Ellero lro...@gmail.com
---
src/target/arm_adi_v5.h | 31 +++
1 files changed, 31 insertions(+), 0 deletions(-)
diff --git a/src/target/arm_adi_v5.h b/src/target/arm_adi_v5.h
index f64f7c8..2aefd60 100644
--- a/src/target/arm_adi_v5.h
+++ b/src
Signed-off-by: Luca Ellero lro...@gmail.com
---
src/target/arm_adi_v5.c | 74 +++
src/target/arm_adi_v5.h |2 +-
2 files changed, 75 insertions(+), 1 deletions(-)
diff --git a/src/target/arm_adi_v5.c b/src/target/arm_adi_v5.c
index 2695c46
* functions instead of mem_ap_*)
make the code more clear and more easier to maintain.
In the future it should be made static to avoid its use outside arm_adi_v5
One further benefit is the various goto has been removed as well
Signed-off-by: Luca Ellero lro...@gmail.com
---
src/target/cortex_a9.c
one to
take this decision ;-)
cheers
luca ellero
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
2011/2/10 Øyvind Harboe oyvind.har...@zylin.com
On Thu, Feb 10, 2011 at 8:57 AM, luca ellero lro...@gmail.com wrote:
Sorry for the double posting. I made some mess :-(
Please discard 1st posting, 2nd is the right one.
Apologies for any inconvenience
This is the right one?
https
but sometimes necessary
;-) in any case we can fix them in the future.
regards
Luca Ellero
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
NOTE: at the moment APB memory accesses are very slow, compared
to AHB accesses. Work has to be done to get it faster (for
example, word accesses instead of byte)
Signed-off-by: Luca Ellero lro...@gmail.com
---
src/target/cortex_a9.c | 159
: at the moment APB memory accesses are very slow, compared
to AHB accesses. Work has to be done to get it faster (for
example LDR/STR instead od LDRB/STRB)
Signed-off-by: Luca Ellero lro...@gmail.com
---
src/target/cortex_a9.c | 160 ++-
1 files
Sorry for the double posting. I made some mess :-(
Please discard 1st posting, 2nd is the right one.
Apologies for any inconvenience
regards
Luca Ellero
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de
On 07/02/2011 3.54, Aaron Carroll wrote:
On 04/02/11 17:31, Mathias K. wrote:
Hello,
On 04.02.2011 01:38, Aaron Carroll wrote:
At a high level, I think it makes sense for functions to be explicit
about selecting an AP... I don't see any advantage to a default.
I don't know if the AP always
Signed-off-by: Luca Ellero lro...@gmail.com
---
src/target/cortex_a8.c |8
src/target/cortex_a9.c |8
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/src/target/cortex_a8.c b/src/target/cortex_a8.c
index 3c80923..f50b149 100644
--- a/src/target/cortex_a8.c
Great, keep us posted. Actually, this will definitely be generally
useful, because there are many other resources that can't be accessed
from the L3 interconnect: the MPCore private regions (per-core timers
and WDT), snoop-control unit, global interrupt controller, local PRCM,
and of course ROM.
Hi Aaron,
On 28/01/2011 5.45, Aaron Carroll wrote:
The reason that you can't read the ROM through the debugger is because
it reads memory through the AHB-AP, which sits on the L3 interconnect.
However, the ROM is actually on the A9's internal L2 interconnect.
On the L3, 0x40028000 doesn't map
Hi Aaron,
On 27/01/2011 6.53, Aaron Carroll wrote:
Hi Luca,
On 26 January 2011 00:13, luca ellerolro...@gmail.com wrote:
With your patch it seems to work. Anyway after issuing halt instruction, I
always get the following message:
target state: halted
target halted in Thumb state due to
complicated). However I'm still investigating... keep
in touch.
Thanks
regards
Luca Ellero
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
?
- OMAP 4430 has two cores. Have someone experience on debugging
multicores (how to halt both cores? what happens when we stop only one
core? on the first phases of boot is sufficient to halt only the 1st MPU?)
Thank you in advance
Best regards
Luca Ellero
to the link you point me.
regards
luca ellero
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
39 matches
Mail list logo
