Re: [Openocd-development] jtag_add_scan_check Assertion Error
Hello,
backtrace from current git repo source.
Regards,
Mathias
---
openocd: core.c:421: jtag_add_scan_check: Assertion `(field-check_value ==
((void *)0)) ||
(field-in_value != ((void *)0))' failed.
Program received signal SIGABRT, Aborted.
0xe424 in __kernel_vsyscall ()
(gdb) bt full
#0 0xe424 in __kernel_vsyscall ()
No symbol table info available.
#1 0xb7e53636 in raise () from /lib/libc.so.6
No symbol table info available.
#2 0xb7e54b6c in abort () from /lib/libc.so.6
No symbol table info available.
#3 0xb7e4c865 in ?? () from /lib/libc.so.6
No symbol table info available.
#4 0xb7e4c91d in __assert_fail () from /lib/libc.so.6
No symbol table info available.
#5 0x0804dc2e in jtag_add_scan_check (active=0x81becf0, jtag_add_scan=0x6,
in_num_fields=135517632,
in_fields=0xbfffd5c8, state=TAP_IDLE) at core.c:421
field = 0xbfffd5c8
i = optimized out
__PRETTY_FUNCTION__ = jtag_add_scan_check
#6 0x080d97cc in arm_jtag_set_instr_inner (jtag_info=0x81c01f4, new_instr=10,
no_verify_capture=0x0,
end_state=TAP_IDLE) at arm_jtag.c:48
tap = 0x81becf0
field = {num_bits = 4, out_value = 0xbfffd5dc
*\320\031\b\370\325\377\277C]\351\267\071,
in_value = 0x0,
check_value = 0x81bed58 \001, check_mask = 0x81bed68 \017}
t = *\320\031\b
#7 0x080b32aa in arm_jtag_set_instr (new_instr=10, jtag_info=0x81c01f4,
no_verify_capture=optimized out,
end_state=optimized out) at arm_jtag.h:52
tap = optimized out
#8 adi_jtag_dp_scan (dap=0x81c02ac, instr=10 '\n', reg_addr=4 '\004', RnW=1
'\001',
outvalue=0xbfffd6dc ,
invalue=0x0, ack=0x0) at adi_v5_jtag.c:91
jtag_info = 0x81c01f4
fields = {{num_bits = -1209443005, out_value = 0x6 Address 0x6 out of
bounds,
in_value = 0x81b5e88 \377\377\377\377XM\034\b\016, check_value =
0x81a40b0
\350b\033\b\360b\033\b,
check_mask = 0x819d0f8 \030\b\032\bhg\027\b\020}, {num_bits =
-1073752408,
out_value = 0x8118c8b 1n\020\001\211Ѓ\304,[^_]Ð\215t,
in_value = 0x81a40b0 \350b\033\b\360b\033\b, check_value =
0x81b62f0
H\312\033\b\b\320\031\b\020,
check_mask = 0x81bca50 0\274\033\bext}}
out_addr_buf = optimized out
retval = 0
#9 0x080b3462 in adi_jtag_dp_scan_u32 (dap=optimized out, instr=optimized
out,
reg_addr=optimized out,
RnW=1 '\001', outvalue=0, invalue=0x0, ack=0x0) at adi_v5_jtag.c:144
out_value_buf = \000\000\000
retval = optimized out
#10 0x080b34de in adi_jtag_scan_inout_check_u32 (dap=0x81c02ac,
instr=optimized out,
reg_addr=optimized out,
RnW=1 '\001', outvalue=0, invalue=0x0) at adi_v5_jtag.c:173
---Type return to continue, or q return to quit---
retval = optimized out
#11 0x080d061b in dap_queue_dp_read (data=0x0, dap=0x81c02ac, reg=optimized
out) at arm_adi_v5.h:260
reg = 4
#12 ahbap_debugport_init (dap=0x81c02ac) at arm_adi_v5.c:1185
ctrlstat = optimized out
cnt = 0
retval = -1073751944
__func__ = ahbap_debugport_init
#13 0x080ea536 in cortex_m3_examine (target=0x81beee8) at cortex_m.c:1894
retval = optimized out
cpuid = 134546344
fpcr = optimized out
i = optimized out
cortex_m3 = 0x81c01f0
swjdp = 0x81c02ac
__func__ = cortex_m3_examine
__FUNCTION__ = cortex_m3_examine
#14 0x08065843 in target_examine_one (target=0x81beee8) at target.c:618
No locals.
#15 target_examine () at target.c:651
retval = 0
target = 0x81beee8
#16 0x0804b6be in handle_init_command (cmd=0xbfffd878) at openocd.c:150
retval = 0
initialized = 1
__func__ = handle_init_command
#17 0x0807b566 in run_command (num_words=1, words=0x81bc960, c=0x81b0318,
context=optimized out)
at command.c:618
cmd = {ctx = 0x819d008, current = 0x81b0318, name = 0x81b2570 init,
argc = 0, argv =
0x81bc964}
retval = optimized out
#18 script_command_run (interp=0x819d028, argc=136038600, argv=0xbfffd90c,
c=0x81b0318,
capture=true) at command.c:218
__FUNCTION__ = script_command_run
nwords = 1
state = 0x81bc8c8
cmd_ctx = optimized out
retval = -1073751796
#19 0x08125804 in Jim_EvalObj (interp=0x819d028, scriptObjPtr=0x81b5eb0) at
jim.c:10083
argc = 1
j = optimized out
cmd = 0x81a2518
i = 2
script = 0x81b5638
---Type return to continue, or q return to quit---
token = 0x81b6050
retcode = 0
sargv = {0x81bf170, 0x81bc9d8, 0x819d028, 0xbfffd948, 0x811a1f0,
0x819d028, 0x81bc9d8, 0x2}
argv = 0xbfffd90c
linenr = 1
#20 0x0812788c in Jim_EvalCoreCommand (interp=0x819d028, argc=3,
argv=0xbfffd9cc) at jim.c:12270
rc = optimized out
#21 0x08125804 in Jim_EvalObj (interp=0x819d028, scriptObjPtr=0x81b2e58) at
jim.c:10083
argc = 3
j = optimized out
cmd = 0x819e1f8
i = 4
script = 0x81b2f60
Re: [Openocd-development] Flashing STM32 F2
Hello,
you can try to use the offset parameter (flash bank address):
flash write_image image 0x0800
Regards,
Mathias
On 15.12.2011 01:31, Damjan Marion wrote:
Hi,
I tried to flash STM32 F2 in the same way like i do on F1 devices and hit
some issues:
My 1st try was with stm32f2x mass_erase 0 but seems that there is no
subcommands registered.
Help lists:
stm32f2x
stm32f2x flash command group (command valid any time)
stm32f2x.c:
static const struct command_registration stm32x_exec_command_handlers[] = {
COMMAND_REGISTRATION_DONE
};
When I try to use flash write_image erase FILE i got:
flash write_image erase hello.bin
auto erase enabled
wrote 0 bytes from file hello.bin in 0.000433s (0.000 KiB/s)
Is this expected behavior or I'm hitting some specific issue?
Thanks,
Damjan
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Flashing STM32 F2
Hello,
the commands doesn't work for me too. You can use flash erase_sector and flash
write_bank.
Regards,
Mathias
On 15.12.2011 01:31, Damjan Marion wrote:
Hi,
I tried to flash STM32 F2 in the same way like i do on F1 devices and hit
some issues:
My 1st try was with stm32f2x mass_erase 0 but seems that there is no
subcommands registered.
Help lists:
stm32f2x
stm32f2x flash command group (command valid any time)
stm32f2x.c:
static const struct command_registration stm32x_exec_command_handlers[] = {
COMMAND_REGISTRATION_DONE
};
When I try to use flash write_image erase FILE i got:
flash write_image erase hello.bin
auto erase enabled
wrote 0 bytes from file hello.bin in 0.000433s (0.000 KiB/s)
Is this expected behavior or I'm hitting some specific issue?
Thanks,
Damjan
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] git gui/cola doesn't push to review
FYI i have append i picture from what i can select in the gui. If i select review as remote the error message looks like this: # Pushing to ssh://hidden@openocd.zylin.com:29418/openocd.git # remote: Resolving deltas: 0% (0/2) # To ssh://hidden@openocd.zylin.com:29418/openocd.git # ! [remote rejected] master - master (prohibited by Gerrit) # error: failed to push some refs to 'ssh://hidden@openocd.zylin.com:29418/openocd.git' The git gui try to push it into the master branch directly. The right way to do it is to push it over the menu Remote-Push to-review. Regards, Mathias On 30.11.2011 01:46, Peter Stuge wrote: Mathias K. wrote: If i try to push i can choose the review as target but it will always pushed into the master and i got a error message. The console command git push review works. Any hints? Can you choose which local branch to push, and which branch on the remote that it should be pushed into? The key is to push into: refs/for/master One canonical command line for this would e.g. be: git push review HEAD:refs/for/master //Peter attachment: git_gui_push_review.png___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] git gui/cola doesn't push to review
Hello, i have a little problem with git gui to push the commits to the review server. If i try to push i can choose the review as target but it will always pushed into the master and i got a error message. The console command git push review works. Any hints? Thanks Regards, Mathias ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Gerrit mail subject
Hello, Am 31.10.2011 06:10, schrieb Peter Stuge: Mathias K. wrote: can you remove the magic incomplete number too? In this case the 1533d9d. This number is useless in the subject: I disagree. This is an abbreviated commit hash, which identifies the commit that was pushed. There's also Gerrit's identifiers, but losing the commit hash would be impractical. Okay, is it possible to change the commit message on a commit with the same commit hash? No, besides contents the hash also depends on commit time and commit message. That's exactly why the hash is useful, to identify the particular commit that is refered to. Please explain what we can do with this id in the subject in this mailinglist. Anyway, can you give gerrit a real name e.g. CIA like some ICQ bots? Regards, Mathias ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Gerrit mail subject
Hello, Em 28-10-2011 05:35, Jon Povey escreveu: In fact I would get rid of [Openocd-development] too. There are headers for sorting mail, other mailing lists I use don't have this, and are more usable for that IMO. -1 What about making it much shorter, like: [oocd-dev] the subject is part of the header and any prefix is redundant because the list-id is also part of the header. Subject: Re: [Openocd-development] Gerrit mail subject List-Id: openocd-development.lists.berlios.de If you want to see it right then visit the lkml. Regards, Mathias ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Gerrit mail subject
Hello, is there any chance to reduce the gerrit subject line to a normal length with more information at the beginning? Currently the subject consist of 50% static text at the beginning. [Openocd-development] New patch to review for openocd: XXX bugfixes: Thanks, Mathias ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Gerrit mail subject
Hello, can you remove the magic incomplete number too? In this case the 1533d9d. This number is useless in the subject: [Openocd-development] openocd patch: 1533d9d cfi: unsupported code paths are now covered by asserts Now we have 2 times openocd as static text left. Do you think we need it? Regards, Mathias Am 28.10.2011 16:14, schrieb Peter Stuge: Jon Povey wrote: is there any chance to reduce the gerrit subject line to a normal length with more information at the beginning? Currently the subject consist of 50% static text at the beginning. [Openocd-development] New patch to review for openocd: XXX bugfixes: I agree. maybe one or two characters of the commit-id are all I see before the subject gets chopped off on my display. I just changed it to New openocd patch: xxx In fact I would get rid of [Openocd-development] too. +1 but since this is a bit more established maybe give people time to change their filters? Or just change it and people will change after? //Peter ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Gerrit mail subject
Hello, another case. Every user use [PATCH] if he send a patch to the mailinglist. Why we should not use [REVIEW] for the gerrit messages? [Openocd-development] [PATCH] cfi: unsupported code paths are now covered by asserts [Openocd-development] [REVIEW] cfi: unsupported code paths are now covered by asserts Regards, Mathias Am 28.10.2011 20:03, schrieb Mathias K.: Hello, can you remove the magic incomplete number too? In this case the 1533d9d. This number is useless in the subject: [Openocd-development] openocd patch: 1533d9d cfi: unsupported code paths are now covered by asserts Now we have 2 times openocd as static text left. Do you think we need it? Regards, Mathias Am 28.10.2011 16:14, schrieb Peter Stuge: Jon Povey wrote: is there any chance to reduce the gerrit subject line to a normal length with more information at the beginning? Currently the subject consist of 50% static text at the beginning. [Openocd-development] New patch to review for openocd: XXX bugfixes: I agree. maybe one or two characters of the commit-id are all I see before the subject gets chopped off on my display. I just changed it to New openocd patch: xxx In fact I would get rid of [Openocd-development] too. +1 but since this is a bit more established maybe give people time to change their filters? Or just change it and people will change after? //Peter ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Gerrit mail subject
Hello, Am 28.10.2011 20:15, schrieb Peter Stuge: Mathias K. wrote: can you remove the magic incomplete number too? In this case the 1533d9d. This number is useless in the subject: I disagree. This is an abbreviated commit hash, which identifies the commit that was pushed. There's also Gerrit's identifiers, but losing the commit hash would be impractical. Okay, is it possible to change the commit message on a commit with the same commit hash? If so the hash make sense to sort the messages. [Openocd-development] openocd patch: 1533d9d cfi: unsupported code paths are now covered by asserts Now we have 2 times openocd as static text left. Do you think we need it? My idea is obviously that we'll remove the first one. When you move to sourceforge this can be done in this step. Maybe you can remove the prefix completely. I think the List-Id in the mail header is enough to filter the mail. Regards, Mathias ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] request to change the filename nor/tms470.c/.h
Hello, this is a request to change the filename and (later) the internal names to tif05.c/.h / tif05 or something. Background: The TMS470R cpu from TI use the F05 Flash Module. The latest chips TMS470MF and TMS570 use the new F035 Flash Module. The Flash Modules are quite different and the current naming is really bad to add the new Flash Module also the flash name should not rely on the cpu name (in this content). I would prefer tif05.c/.h and tif035.c/.h and for the configuration tif05 / tif035. What do you think about it? Regards, Mathias ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] ft2232: Set PWR_RST and LOOPBACK for xds100v2
Hello Kyle,
the patch works with the TMS570 eval. board. You should use gerrit to submit
the patch.
Short instruction that works for me:
1.) register at http://openocd.zylin.com/ with a OPENID (you need a google or
yahoo account (or other))
2.) create a ssl certificate and set it in your profile at gerrit and make it
available to your
local ssh client
3.) choose a USERNAME
4.) clone the current openocd git git clone
git://openocd.git.sourceforge.net/gitroot/openocd/openocd
5.) change the email and name in the git repo (local or global) to your
registration set at 1.
6.) execute: git remote add review
ssh://usern...@openocd.zylin.com:29418/openocd.git (USERNAME is
your registration USERNAME)
7.) execute: git config remote.review.push HEAD:refs/for/master
8.) execute: scp -p -P 29418 usern...@openocd.zylin.com:hooks/commit-msg
.git/hooks/ (USERNAME is
your registration USERNAME)
9.) apply your changes again
10.) push the changes to review
Hope that i don't miss anything.
Regards,
Mathias
Am 24.10.2011 19:42, schrieb Kyle Manna:
The CPLD on the xds100v2 expects to see a rising edge on PWR_RST to
enable the outputs. This patch creates that transition correctly by
fixing the direction register for PWR_RST.
THe CPLD will also loop back the data if the LOOPBACK signal is
asserted. Set this signal to an output and keep it clear.
This was tested with a TI DM3730 Beagleboard xM.
Signed-off-by: Kyle Manna kyle.ma...@fuel7.com
---
src/jtag/drivers/ft2232.c | 53
+
1 files changed, 39 insertions(+), 14 deletions(-)
diff --git a/src/jtag/drivers/ft2232.c b/src/jtag/drivers/ft2232.c
index 3cca26d..ceb3c0b 100644
--- a/src/jtag/drivers/ft2232.c
+++ b/src/jtag/drivers/ft2232.c
@@ -3175,40 +3175,65 @@ static int flossjtag_init(void)
return ftx232_dbus_write();
}
+/*
+ * The reference schematic from TI for the XDS100v2 has a CPLD on which opens
+ * the door for a number of different configurations
+ *
+ * Known Implementations:
+ *
http://processors.wiki.ti.com/images/9/93/TMS570LS20216_USB_STICK_Schematic.pdf
+ *
+ * http://processors.wiki.ti.com/index.php/XDS100 (rev2)
+ * * CLPD logic: Rising edge to enable outputs (XDS100_PWR_RST)
+ * * ACBUS3 to transition 0-1 (OE rising edge)
+ * * CPLD logic: Put the EMU0/1 pins in Hi-Z:
+ * * ADBUS5/GPIOL1 = EMU_EN = 1
+ * * ADBUS6/GPIOL2 = EMU0 = 0
+ * * ACBUS4/SPARE0 = EMU1 = 0
+ * * CPLD logic: Disable loopback
+ * * ACBUS6/SPARE2 = LOOPBACK = 0
+ */
+#define XDS100_nEMU_EN (15)
+#define XDS100_nEMU0 (16)
+
+#define XDS100_PWR_RST (13)
+#define XDS100_nEMU1 (14)
+#define XDS100_LOOPBACK (16)
static int xds100v2_init(void)
{
- low_output= 0x3A;
- low_direction = 0x7B;
+ /* These are in the lower byte */
+ nTRST= 0x10;
+ nTRSTnOE = 0x10;
+
+ /* These aren't actually used on 14 pin connectors */
+ /* These are in the upper byte */
+ nSRST= 0x01;
+ nSRSTnOE = 0x01;
+
+ low_output= 0x08 | nTRST | XDS100_nEMU_EN;
+ low_direction = 0x0b | nTRSTnOE | XDS100_nEMU_EN | XDS100_nEMU0;
- /* initialize low byte for jtag */
if (ft2232_set_data_bits_low_byte(low_output,low_direction) != ERROR_OK)
{
LOG_ERROR(couldn't initialize FT2232 with 'xds100v2' layout);
return ERROR_JTAG_INIT_FAILED;
}
- nTRST= 0x10;
- nTRSTnOE = 0x0; /* not output enable for nTRST */
- nSRST= 0x00;/* TODO: SRST is not supported yet */
- nSRSTnOE = 0x00;/* no output enable for nSRST */
-
- high_output= 0x00;
- high_direction = 0x59;
+ high_output = 0;
+ high_direction = nSRSTnOE | XDS100_LOOPBACK | XDS100_PWR_RST |
XDS100_nEMU1;
/* initialize high byte for jtag */
if (ft2232_set_data_bits_high_byte(high_output,high_direction) !=
ERROR_OK)
{
- LOG_ERROR(couldn't initialize FT2232 with 'xds100v2' layout);
+ LOG_ERROR(couldn't put CPLD in to reset with 'xds100v2'
layout);
return ERROR_JTAG_INIT_FAILED;
}
- high_output= 0x86;
- high_direction = 0x59;
+ high_output |= XDS100_PWR_RST;
/* initialize high byte for jtag */
if (ft2232_set_data_bits_high_byte(high_output,high_direction) !=
ERROR_OK)
{
- LOG_ERROR(couldn't initialize FT2232 with 'xds100v2' layout);
+ LOG_ERROR(couldn't bring CPLD out of reset with 'xds100v2'
layout);
return ERROR_JTAG_INIT_FAILED;
}
-- 1.7.5.4
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] ft2232: Set PWR_RST and LOOPBACK for xds100v2
Ups, sorry, this is our guideline: http://openocd.sourceforge.net/doc/doxygen/html/index.html Regards, Mathias Am 25.10.2011 22:44, schrieb Mathias K.: Hello, you should update http://openocd.sourceforge.net/doc/doxygen/html/patchguide.html or remove this ugly Developer's Guide. Regards, Mathias Am 25.10.2011 22:32, schrieb Peter Stuge: Mathias K. wrote: 2.) create a ssl certificate and set it in your profile at gerrit and make it available to your local ssh client SSH private key - not an SSL certificate. See also http://openocd.zylin.com/gitweb/?p=openocd.git;a=blob;f=HACKING //Peter ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] TMDX570LS20SUSB config files
Hello,
i have append my experimental config files for the ti tms570 usb eval board.
Flash is not supported
by openocd yet. Maybe its useful for someone.
flash info 0
device_ident_reg = 0x80206d0d
Could not identify part 0x21 as a member of the TMS470 family.
auto_probe failed
in procedure 'flash'
Regards,
Mathias
#
# TMS570 Microcontroller USB Kit
# http://www.ti.com/tool/tmdx570ls20susb
#
source [find interface/xds100v2.cfg]
set CHIPNAME tms570ls
adapter_khz 10
source [find target/ti_tms570ls.cfg]
#
# TI TMS570LS
#
###
# User modifiable parameters
###
set _ENDIAN big
if { [info exists CHIPNAME] } {
set _CHIPNAME $CHIPNAME
} else {
set _CHIPNAME tms570ls
}
set _JRC_TAPID 0x1b7b302f
# Run the adapter at the fastest acceptable speed with the slowest possible
# core clock.
adapter_khz 100
###
# JTAG setup
# The OpenOCD commands are described in the TAP Declaration section
# http://openocd.berlios.de/doc/html/TAP-Declaration.html
###
source [find target/icepick.cfg]
# The TAP order should be described from the TDO connection in OpenOCD to the
# TDI pin. The OpenOCD FAQ describes this in more detail:
# http://openocd.berlios.de/doc/html/FAQ.html
# From SPRUGN4B CH27 the available secondary TAPs are in this order from TDO:
#
# Device | TAP number
# -|
# DAP | 3
# Sequencer| 2 Note: The sequencer is an ARM968
# DSP | 1
# D2D | 0
#
# Right now the only secondary tap enabled is the DAP so the rest are left
# undescribed.
##
# Start of Chain Description
# The Secondary TAPs all have enable functions defined for use with the ICEpick
# Only the DAP is enabled. The AM37xx does not have the Sequencer or DSP but
# the TAP numbers for ICEpick do not change.
#
# TODO: A disable function should also be added.
##
# Secondary TAP: D2D it is not in the chain by default (-disable)
# The ICEpick can be used to enable it in the chain.
# This IRLEN is probably incorrect - not sure where the documentation is.
jtag newtap $_CHIPNAME etb -irlen 4 -ircapture 0x1 -irmask 0x0f -disable
jtag configure $_CHIPNAME.etb -event tap-enable \
icepick_c_tapenable $_CHIPNAME.jrc 1
# Secondary TAP: DAP is closest to the TDO output
# The TAP enable event also needs to be described
jtag newtap $_CHIPNAME dap -irlen 4 -ircapture 0x1 -irmask 0x1 -disable
jtag configure $_CHIPNAME.dap -event tap-enable \
icepick_c_tapenable $_CHIPNAME.jrc 0
# Primary TAP: ICEpick - it is closest to TDI so last in the chain
jtag newtap $_CHIPNAME jrc -irlen 6 -ircapture 0x1 -irmask 0x3f \
-expected-id $_JRC_TAPID
##
# End of Chain Description
##
##
# Start JTAG TAP events
##
# some TCK tycles are required to activate the DEBUG power domain
jtag configure $_CHIPNAME.jrc -event post-reset runtest 100
# Enable the DAP TAP
jtag configure $_CHIPNAME.jrc -event setup jtag tapenable $_CHIPNAME.dap
##
# End JTAG TAP events
##
###
# Target Setup:
# This section is described in the OpenOCD documentation under CPU Configuration
# http://openocd.berlios.de/doc/html/CPU-Configuration.html
###
# Create the CPU target to be used with GDB: Cortex-A8, using DAP
set _TARGETNAME $_CHIPNAME.dap
target create $_TARGETNAME cortex_a8 -chain-position $_CHIPNAME.dap
# -variant arm1176
# The DM37x has 64K of SRAM starting at address 0x4020_. Allow the first
# 16K to be used as a scratchpad for OpenOCD.
#$_TARGETNAME configure -work-area-phys 0x4020 -work-area-size 0x4000
# size is automatically calculated by probing
set _FLASHNAME $_CHIPNAME.flash
flash bank $_FLASHNAME tms470 0x0 0x0020 1 1 $_TARGETNAME
###
# Target Functions
# Add any functions needed for the target here
###
# Run this to enable invasive debugging. This is run automatically in the
# reset sequence.
proc amdm37x_dbginit {target} {
# # General Cortex A8 debug initialisation
cortex_a8 dbginit
# Enable DBGEN signal. This signal is described in the ARM v7 TRM, but
# access to the signal appears to be implementation specific. TI does not
# describe this register much except a quick line that states DBGEM (sic) is
# at this address and this bit.
# $target mww phys 0x5401d030 0x2000
}
#jtag_rclk 100
#etm config $_TARGETNAME 16 normal half etb
#etb config $_TARGETNAME $_CHIPNAME.etb
##
# Start Target Reset Event Setup:
##
# Set
Re: [Openocd-development] gerrit hosting
Hello, Am 08.10.2011 12:11, schrieb Øyvind Harboe: sourceforge does not offer gerrit. Is there a hosting service that does? gerrit is only a proxy before git. You can install it on any machine and use the gerrit host instead of the git host to work with the repo. Anyway you can check this site to find any hoster with a code review ability: http://en.wikipedia.org/wiki/Comparison_of_open_source_software_hosting_facilities Regards, Mathias ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Fwd: BerliOS will be closed on 31.12.2011
Am 01.10.2011 09:02, schrieb Øyvind Harboe: No mailing list??? No. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] load image with different memory types and overlapping addresses
Hello, i have checked the sources to find a way that works for this issue but this would make a big api change. Currently there is no way to tell the target write memory function the kind of memory that needs to be written. In my case the dsp563xx p,x,y memory. Would it make sense to change this globally or is it better to add a special dsp563xx command to load this kind of image? The image type is lod. Thanks Regards, Mathias ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] dsp563xx: add target events, run algorithm and default r/w buffer api
Patch appended.
From e1fa97a81eba9901b3fa3af9169705d745406661 Mon Sep 17 00:00:00 2001
From: Mathias K. kes...@freenet.de
Date: Wed, 21 Sep 2011 19:18:26 +0200
Subject: add target events, run algorithm and default r/w buffer api
Target events are added to get better gdb support. The run
algorithm functionality are implemented to support feature
fast flash write functionality. The new r/w buffer api is now
used to support the special memory address handling. The output
of the md command was fixed.
---
src/target/dsp563xx.c | 180 +++--
1 files changed, 173 insertions(+), 7 deletions(-)
diff --git a/src/target/dsp563xx.c b/src/target/dsp563xx.c
index 5290b63..b7f23c7 100644
--- a/src/target/dsp563xx.c
+++ b/src/target/dsp563xx.c
@@ -25,6 +25,7 @@
#include target.h
#include target_type.h
+#include algorithm.h
#include register.h
#include dsp563xx.h
#include dsp563xx_once.h
@@ -548,9 +549,14 @@ static int dsp563xx_reg_pc_read(struct target *target)
{
if ( (once_regs[ONCE_REG_IDX_OPABF11].reg 1) == 0 )
{
- LOG_DEBUG(%s conditional branch not supported yet, __FUNCTION__);
+ LOG_DEBUG(%s conditional branch not supported yet (0x%x 0x%x 0x%x), __FUNCTION__,
+(once_regs[ONCE_REG_IDX_OPABF11].reg 1),
+once_regs[ONCE_REG_IDX_OPABDR].reg,
+once_regs[ONCE_REG_IDX_OPABEX].reg);
- /* TODO: use disassembly to set correct pc offset */
+ /* TODO: use disassembly to set correct pc offset
+ * read 2 words from OPABF11 and disasm the instruction
+ */
dsp563xx-core_regs[DSP563XX_REG_IDX_PC] = (once_regs[ONCE_REG_IDX_OPABF11].reg 1) 0x00FF;
}
else
@@ -995,7 +1001,8 @@ static int dsp563xx_jtag_debug_request(struct target *target)
static int dsp563xx_poll(struct target *target)
{
int err;
- uint32_t once_status;
+ struct dsp563xx_common *dsp563xx = target_to_dsp563xx(target);
+ uint32_t once_status=0;
int state;
state = dsp563xx_once_target_status(target-tap);
@@ -1019,9 +1026,18 @@ static int dsp563xx_poll(struct target *target)
if ((err = dsp563xx_debug_init(target)) != ERROR_OK)
return err;
- target_call_event_callbacks(target, TARGET_EVENT_HALTED);
+ if ( once_status (DSP563XX_ONCE_OSCR_MBO|DSP563XX_ONCE_OSCR_SWO) )
+ {
+target_call_event_callbacks(target, TARGET_EVENT_DEBUG_HALTED);
+ }
+ else
+ {
+target_call_event_callbacks(target, TARGET_EVENT_HALTED);
+ }
LOG_DEBUG(target-state: %s (%x), target_state_name(target),once_status);
+
+ LOG_INFO(halted: PC: 0x%x, dsp563xx-core_regs[DSP563XX_REG_IDX_PC] );
}
}
@@ -1098,6 +1114,8 @@ static int dsp563xx_resume(struct target *target, int current, uint32_t address,
target-state = TARGET_RUNNING;
+ target_call_event_callbacks(target, TARGET_EVENT_DEBUG_RESUMED);
+
return ERROR_OK;
}
@@ -1205,6 +1223,13 @@ static int dsp563xx_step_ex(struct target *target, int current, uint32_t address
static int dsp563xx_step(struct target *target, int current, uint32_t address, int handle_breakpoints)
{
int err;
+ struct dsp563xx_common *dsp563xx = target_to_dsp563xx(target);
+
+ if (target-state != TARGET_HALTED)
+ {
+ LOG_WARNING(target not halted);
+ return ERROR_TARGET_NOT_HALTED;
+ }
if ( (err=dsp563xx_step_ex(target, current, address, handle_breakpoints, 0)) != ERROR_OK )
{
@@ -1214,6 +1239,8 @@ static int dsp563xx_step(struct target *target, int current, uint32_t address, i
target-debug_reason = DBG_REASON_SINGLESTEP;
target_call_event_callbacks(target, TARGET_EVENT_HALTED);
+ LOG_INFO(halted: PC: 0x%x, dsp563xx-core_regs[DSP563XX_REG_IDX_PC] );
+
return err;
}
@@ -1274,8 +1301,10 @@ static int dsp563xx_deassert_reset(struct target *target)
return err;
}
}
-
-// target-state = TARGET_RUNNING;
+ else
+ {
+ target-state = TARGET_RUNNING;
+ }
LOG_DEBUG(%s, __FUNCTION__);
return ERROR_OK;
@@ -1287,6 +1316,97 @@ static int dsp563xx_soft_reset_halt(struct target *target)
return ERROR_OK;
}
+static int dsp563xx_run_algorithm(struct target *target,
+ int num_mem_params, struct mem_param *mem_params,
+ int num_reg_params, struct reg_param *reg_params,
+ uint32_t entry_point, uint32_t exit_point,
+ int timeout_ms, void *arch_info)
+{
+ int i;
+ int retvaltemp,retval = 0;
+ struct dsp563xx_common *dsp563xx = target_to_dsp563xx(target);
+
+ if (target-state != TARGET_HALTED)
+ {
+ LOG_WARNING(target not halted);
+ return ERROR_TARGET_NOT_HALTED;
+ }
+
+ for (i = 0; i num_mem_params; i++)
+ {
+ if ((retval = target_write_buffer(target, mem_params[i].address, mem_params[i].size, mem_params[i].value)) != ERROR_OK)
+ {
+ return retval;
+ }
+ }
+
+ for (i = 0; i num_reg_params; i++)
+ {
+ struct reg *reg = register_get_by_name(dsp563xx-core_cache, reg_params[i].reg_name, 0);
+
+ if (!reg)
+ {
+ LOG_ERROR(BUG: register '%s' not found, reg_params[i].reg_name);
+ continue;
+ }
+
+ if (reg-size != reg_params[i].size)
+ {
+ LOG_ERROR(BUG: register '%s' size doesn't
Re: [Openocd-development] [PATCH] kinetis cpu flash driver
Hello, i prefer something like this (i don't want to start a goto discussion): if ( tap-hasidcode (dap_syssec_filter_data[i].idcode == tap-idcode) ) but we should be sure that idcode is initialized with an invalid value like zero but independent of the hasidcode flag. Regards, Mathias Am 19.09.2011 18:50, schrieb Øyvind Harboe: I'll let it cool off for a few days. Please give word if further work is required and we should submit an updated patch. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] kinetis cpu flash driver
Hello,
i have worked on the issues, please let me know if there was something that i
have not picked up.
Regards,
Mathias
Am 16.09.2011 10:00, schrieb Øyvind Harboe:
First of all, overall I think the code looks good!
Some nit-picking below.
The OpenOCD error handling is modeled upon exception handling, report error
in place and then just propagate errors (exceptions) without changing the
return
value.
1. Switch to LOG_ERROR.
+FLASH_BANK_COMMAND_HANDLER(kinetis_flash_bank_command)
+{
+ if (CMD_ARGC 6) {
+ LOG_WARNING(incomplete flash_bank kinetis configuration %d,
+ CMD_ARGC);
+ return ERROR_FLASH_OPERATION_FAILED;
+ }
2. Just return LOG_ERROR()
+static int kinetis_protect(struct flash_bank *bank, int set, int first,
+ int last)
+{
+ struct flash_bank *master_bank = kinetis_get_master_bank(bank);
+
+ LOG_WARNING(kinetis_protect not supported yet);
+
+ if (bank-target-state != TARGET_HALTED) {
+ LOG_ERROR(Target not halted);
+ return ERROR_TARGET_NOT_HALTED;
+ }
+
+ if (master_bank == NULL) {
+ return ERROR_FLASH_OPERATION_FAILED;
+ }
+
+ return ERROR_OK;
+}
3. Modify to return error as primary return value and pointer in
secondary return
value, then just propagate the return value unchanged upon error.
+static struct flash_bank *kinetis_get_master_bank(struct flash_bank *bank)
4. This fn does not propagate failure:
+static void kinetis_update_bank_info(struct flash_bank *bank)
+{
+ struct flash_bank *master_bank = kinetis_get_master_bank(bank);
+
+ if (master_bank == NULL) {
+ return;
+ }
+
5. propagate (just return) the error code, do not change it:
+ if (kinetis_ftfl_command(bank, w0, w1, w2) != ERROR_OK) {
+ return ERROR_FLASH_OPERATION_FAILED;
+ }
+
+
From ab35e7489fb125fac84049040ea86776f34cf952 Mon Sep 17 00:00:00 2001
From: Mathias K. kes...@freenet.de
Date: Sat, 17 Sep 2011 10:09:50 +0200
Subject: [PATCH 2/2] kinetis cpu flash driver
Initial release of the freescale kinetis cpu flash driver.
---
src/flash/nor/Makefile.am |3 +-
src/flash/nor/drivers.c |2 +
src/flash/nor/kinetis.c | 562 +
3 files changed, 566 insertions(+), 1 deletions(-)
create mode 100644 src/flash/nor/kinetis.c
diff --git a/src/flash/nor/Makefile.am b/src/flash/nor/Makefile.am
index d7d66b0..a966826 100644
--- a/src/flash/nor/Makefile.am
+++ b/src/flash/nor/Makefile.am
@@ -32,7 +32,8 @@ NOR_DRIVERS = \
tms470.c \
virtual.c \
fm3.c \
- dsp5680xx_flash.c
+ dsp5680xx_flash.c \
+ kinetis.c
noinst_HEADERS = \
core.h \
diff --git a/src/flash/nor/drivers.c b/src/flash/nor/drivers.c
index 5d6e248..a437d84 100644
--- a/src/flash/nor/drivers.c
+++ b/src/flash/nor/drivers.c
@@ -45,6 +45,7 @@ extern struct flash_driver stmsmi_flash;
extern struct flash_driver em357_flash;
extern struct flash_driver dsp5680xx_flash;
extern struct flash_driver fm3_flash;
+extern struct flash_driver kinetis_flash;
/**
* The list of built-in flash drivers.
@@ -75,6 +76,7 @@ static struct flash_driver *flash_drivers[] = {
em357_flash,
fm3_flash,
dsp5680xx_flash,
+ kinetis_flash,
NULL,
};
diff --git a/src/flash/nor/kinetis.c b/src/flash/nor/kinetis.c
new file mode 100644
index 000..2613522
--- /dev/null
+++ b/src/flash/nor/kinetis.c
@@ -0,0 +1,562 @@
+/***
+ * Copyright (C) 2011 by Mathias Kuester *
+ * kes...@freenet.de *
+ * *
+ * This program is free software; you can redistribute it and/or modify *
+ * it under the terms of the GNU General Public License as published by *
+ * the Free Software Foundation; either version 2 of the License, or *
+ * (at your option) any later version. *
+ * *
+ * This program is distributed in the hope that it will be useful, *
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of*
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the *
+ * GNU General Public License for more details. *
+ * *
+ * You should have received a copy of the GNU General Public License *
+ * along with this program; if not, write to the *
+ * Free Software Foundation, Inc., *
+ * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA
Re: [Openocd-development] OpenOCD vs. Colibri PXA320 v2.0b
Hello, Am 13.09.2011 15:28, schrieb Oliver Döring: I'm having lots of problems with this Toradex board. I use a custom carrier board without JTAG buffers, so I connected my JTAG-USB directly to the Colibri FFC JTAG connector. My JTAG adapter is FT2232 based and uses the OOCDLink layout, which means it has NTRST and NSRST buffers with OE. I traced all the signals from the Colibri board to the JTAG adapters, everything looks ok. I looked at the signals with an (analogue) oscilloscope and saw the reset signals and pulses on TMS, TCK, TDI and TDO. the board already buffers the lines TMS,nTRST,TCK,TDI and TDO with a SN74LVC16244A (http://www.toradex.com/files/media/pdf/Colibri%20Evalboard%20V2.1%20Schematics.pdf). However, here is what I get: Please post your configuration file. Is it the same like in openocd or http://openpxa.git.sourceforge.net? Maybe you can try to use only the tap reset line and not the system reset. Regards, Mathias ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] kinetis auto mass erase on secured devices
Hello,
this patch add support for debug port access on a secured kinetis cpu with mass
erase enabled.
Regards,
Mathias
From 63c322864f50d9c3489f498e2f29a508ac9156d8 Mon Sep 17 00:00:00 2001
From: Mathias K. kes...@freenet.de
Date: Mon, 12 Sep 2011 20:28:23 +0200
Subject: [PATCH] kinetis auto mass erase on secured devices
This is a proof of concept to get access to the debug port of a
secured kinetis cpu. On full flash erase the cpu is automatically
secured and the debug port is not accessible.
To get this to work the srst line is needed and the necessary
configuration should be added to the configuration file.
---
src/target/arm_adi_v5.c | 182 +++
1 files changed, 182 insertions(+), 0 deletions(-)
diff --git a/src/target/arm_adi_v5.c b/src/target/arm_adi_v5.c
index f8a2e22..cd68a20 100644
--- a/src/target/arm_adi_v5.c
+++ b/src/target/arm_adi_v5.c
@@ -955,6 +955,186 @@ int mem_ap_sel_write_buf_u32(struct adiv5_dap *swjdp, uint8_t ap,
return mem_ap_write_buf_u32(swjdp, buffer, count, address);
}
+#define MDM_REG_STAT 0x00
+#define MDM_REG_CTRL 0x04
+#define MDM_REG_ID 0xfc
+
+#define MDM_STAT_FMEACK (10)
+#define MDM_STAT_FREADY (11)
+#define MDM_STAT_SYSSEC (12)
+#define MDM_STAT_SYSRES (13)
+#define MDM_STAT_FMEEN (15)
+#define MDM_STAT_BACKDOOREN (16)
+#define MDM_STAT_LPEN (17)
+#define MDM_STAT_VLPEN (18)
+#define MDM_STAT_LLSMODEXIT (19)
+#define MDM_STAT_VLLSXMODEXIT (110)
+#define MDM_STAT_CORE_HALTED (116)
+#define MDM_STAT_CORE_SLEEPDEEP (117)
+#define MDM_STAT_CORESLEEPING (118)
+
+#define MEM_CTRL_FMEIP (10)
+#define MEM_CTRL_DBG_DIS (11)
+#define MEM_CTRL_DBG_REQ (12)
+#define MEM_CTRL_SYS_RES_REQ (13)
+#define MEM_CTRL_CORE_HOLD_RES (14)
+#define MEM_CTRL_VLLSX_DBG_REQ (15)
+#define MEM_CTRL_VLLSX_DBG_ACK (16)
+#define MEM_CTRL_VLLSX_STAT_ACK (17)
+
+/**
+ *
+ */
+int dap_syssec_kinetis_mdmap(struct adiv5_dap *dap)
+{
+ uint32_t val;
+ int retval;
+ enum reset_types jtag_reset_config = jtag_get_reset_config();
+
+ dap_ap_select(dap, 1);
+
+ /* first check mdm-ap id register */
+ retval = dap_queue_ap_read(dap, MDM_REG_ID, val);
+ if (retval != ERROR_OK)
+ return retval;
+ dap_run(dap);
+
+ if ( val != 0x001C )
+ {
+ LOG_DEBUG(id doesn't match %08X != 0x001C,val);
+ dap_ap_select(dap, 0);
+ return ERROR_FAIL;
+ }
+
+ /* read and parse status register
+ * it's important that the device is out of
+ * reset here
+ */
+ retval = dap_queue_ap_read(dap, MDM_REG_STAT, val);
+ if (retval != ERROR_OK)
+ return retval;
+ dap_run(dap);
+
+ LOG_DEBUG(MDM_REG_STAT %08X,val);
+
+ if ( (val (MDM_STAT_SYSSEC|MDM_STAT_FREADY)) != (MDM_STAT_FREADY) )
+ {
+ LOG_DEBUG(MDMAP: system is secured, masserase needed);
+
+ if ( !(val MDM_STAT_FMEEN) )
+ {
+ LOG_DEBUG(MDMAP: masserase is disabled);
+ }
+ else
+ {
+ /* we need to assert reset */
+ if ( jtag_reset_config RESET_HAS_SRST )
+ {
+/* default to asserting srst */
+if (jtag_reset_config RESET_SRST_PULLS_TRST)
+{
+ jtag_add_reset(1, 1);
+}
+else
+{
+ jtag_add_reset(0, 1);
+}
+ }
+ else
+ {
+LOG_DEBUG(SRST not configured);
+dap_ap_select(dap, 0);
+return ERROR_FAIL;
+ }
+
+ while(1)
+ {
+retval = dap_queue_ap_write(dap, MDM_REG_CTRL, MEM_CTRL_FMEIP);
+if (retval != ERROR_OK)
+ return retval;
+dap_run(dap);
+/* read status register and wait for ready */
+retval = dap_queue_ap_read(dap, MDM_REG_STAT, val);
+if (retval != ERROR_OK)
+ return retval;
+dap_run(dap);
+LOG_DEBUG(MDM_REG_STAT %08X,val);
+
+if ( (val1))
+ break;
+ }
+
+ while(1)
+ {
+retval = dap_queue_ap_write(dap, MDM_REG_CTRL, 0);
+if (retval != ERROR_OK)
+ return retval;
+dap_run(dap);
+/* read status register */
+retval = dap_queue_ap_read(dap, MDM_REG_STAT, val);
+if (retval != ERROR_OK)
+ return retval;
+dap_run(dap);
+LOG_DEBUG(MDM_REG_STAT %08X,val);
+/* read control register and wait for ready */
+retval = dap_queue_ap_read(dap, MDM_REG_CTRL, val);
+if (retval != ERROR_OK)
+ return retval;
+dap_run(dap);
+LOG_DEBUG(MDM_REG_CTRL %08X,val);
+
+if ( val == 0x00 )
+ break;
+ }
+ }
+ }
+
+ dap_ap_select(dap, 0);
+
+ return ERROR_OK;
+}
+
+/** */
+typedef struct dap_syssec_filter_s {
+ /** */
+ uint32_t idcode;
+ /** */
+ int (*dap_init)(struct adiv5_dap *dap);
+} dap_syssec_filter_s;
+
+/** */
+static struct dap_syssec_filter_s dap_syssec_filter[] = {
+ { 0x4BA00477, dap_syssec_kinetis_mdmap }
+};
+
+
+/**
+ *
+ */
+int dap_syssec(struct adiv5_dap *dap)
+{
+ unsigned int i;
+ struct jtag_tap *tap;
+
+ for(i=0;isizeof(dap_syssec_filter);i++)
+ {
+ tap = dap-jtag_info-tap;
+
+ while (tap != NULL)
+ {
+ if (!tap-hasidcode)
+continue;
+ if ( dap_syssec_filter[i].idcode == tap-idcode )
+ {
+LOG_DEBUG(DAP: mdmap_init for idcode: %08x,tap-idcode);
+dap_syssec_filter[i].dap_init(dap);
+ }
+ tap
Re: [Openocd-development] [PATCH] kinetis cpu flash driver
Hello,
this patch removes the test code used to verify the functionality.
Regards,
Mathias
Am 12.09.2011 16:17, schrieb Mathias K.:
Hello,
i have done some work on the kinetis cpu flash driver. Erase,write and read
protection works.
Regards,
Mathias
From 3a4d6a735680b0015de4f07db1b91a1f4112e898 Mon Sep 17 00:00:00 2001
From: Mathias K. kes...@freenet.de
Date: Mon, 12 Sep 2011 21:42:59 +0200
Subject: [PATCH 3/3] remove test code
---
src/flash/nor/kinetis.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/src/flash/nor/kinetis.c b/src/flash/nor/kinetis.c
index 548df57..116363c 100644
--- a/src/flash/nor/kinetis.c
+++ b/src/flash/nor/kinetis.c
@@ -278,8 +278,6 @@ static int kinetis_write(struct flash_bank *bank, uint8_t * buffer,
return result;
}
- buf[0] = 0;
-
if (!(buf[0] (1 1))) {
/* fallback to longword write */
fallback = 1;
--
1.7.3.4
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] kinetis auto mass erase on secured devices
Hello,
yes you are right. Changes appended.
Regards,
Mathias
Am 12.09.2011 21:09, schrieb Eric Wetzel:
On Mon, Sep 12, 2011 at 2:34 PM, Mathias K. kes...@freenet.de wrote:
Hello,
this patch add support for debug port access on a secured kinetis cpu with
mass erase enabled.
Regards,
Mathias
Hi,
This patch introduces an unused and unnecessary typedef and a tiny bit
of Hungarian-ish notation (the _s in dap_syssec_filter_s). Not sure if
we're going to be moving ahead on the Linux style, but automatic
formatters will not catch the Linux aversion to typedefs and
Hungarian.
Regards,
~Eric
From becb405a8fb2253cbc99b114d2701ff81dc5bd6b Mon Sep 17 00:00:00 2001
From: Mathias K. kes...@freenet.de
Date: Mon, 12 Sep 2011 21:24:17 +0200
Subject: [PATCH] kinetis auto mass erase on secured devices
This is a proof of concept to get access to the debug port of a
secured kinetis cpu. On full flash erase the cpu is automatically
secured and the debug port is not accessible.
To get this to work the srst line is needed and the necessary
configuration should be added to the configuration file.
---
src/target/arm_adi_v5.c | 182 +++
1 files changed, 182 insertions(+), 0 deletions(-)
diff --git a/src/target/arm_adi_v5.c b/src/target/arm_adi_v5.c
index f8a2e22..21dc54c 100644
--- a/src/target/arm_adi_v5.c
+++ b/src/target/arm_adi_v5.c
@@ -955,6 +955,186 @@ int mem_ap_sel_write_buf_u32(struct adiv5_dap *swjdp, uint8_t ap,
return mem_ap_write_buf_u32(swjdp, buffer, count, address);
}
+#define MDM_REG_STAT 0x00
+#define MDM_REG_CTRL 0x04
+#define MDM_REG_ID 0xfc
+
+#define MDM_STAT_FMEACK (10)
+#define MDM_STAT_FREADY (11)
+#define MDM_STAT_SYSSEC (12)
+#define MDM_STAT_SYSRES (13)
+#define MDM_STAT_FMEEN (15)
+#define MDM_STAT_BACKDOOREN (16)
+#define MDM_STAT_LPEN (17)
+#define MDM_STAT_VLPEN (18)
+#define MDM_STAT_LLSMODEXIT (19)
+#define MDM_STAT_VLLSXMODEXIT (110)
+#define MDM_STAT_CORE_HALTED (116)
+#define MDM_STAT_CORE_SLEEPDEEP (117)
+#define MDM_STAT_CORESLEEPING (118)
+
+#define MEM_CTRL_FMEIP (10)
+#define MEM_CTRL_DBG_DIS (11)
+#define MEM_CTRL_DBG_REQ (12)
+#define MEM_CTRL_SYS_RES_REQ (13)
+#define MEM_CTRL_CORE_HOLD_RES (14)
+#define MEM_CTRL_VLLSX_DBG_REQ (15)
+#define MEM_CTRL_VLLSX_DBG_ACK (16)
+#define MEM_CTRL_VLLSX_STAT_ACK (17)
+
+/**
+ *
+ */
+int dap_syssec_kinetis_mdmap(struct adiv5_dap *dap)
+{
+ uint32_t val;
+ int retval;
+ enum reset_types jtag_reset_config = jtag_get_reset_config();
+
+ dap_ap_select(dap, 1);
+
+ /* first check mdm-ap id register */
+ retval = dap_queue_ap_read(dap, MDM_REG_ID, val);
+ if (retval != ERROR_OK)
+ return retval;
+ dap_run(dap);
+
+ if ( val != 0x001C )
+ {
+ LOG_DEBUG(id doesn't match %08X != 0x001C,val);
+ dap_ap_select(dap, 0);
+ return ERROR_FAIL;
+ }
+
+ /* read and parse status register
+ * it's important that the device is out of
+ * reset here
+ */
+ retval = dap_queue_ap_read(dap, MDM_REG_STAT, val);
+ if (retval != ERROR_OK)
+ return retval;
+ dap_run(dap);
+
+ LOG_DEBUG(MDM_REG_STAT %08X,val);
+
+ if ( (val (MDM_STAT_SYSSEC|MDM_STAT_FREADY)) != (MDM_STAT_FREADY) )
+ {
+ LOG_DEBUG(MDMAP: system is secured, masserase needed);
+
+ if ( !(val MDM_STAT_FMEEN) )
+ {
+ LOG_DEBUG(MDMAP: masserase is disabled);
+ }
+ else
+ {
+ /* we need to assert reset */
+ if ( jtag_reset_config RESET_HAS_SRST )
+ {
+/* default to asserting srst */
+if (jtag_reset_config RESET_SRST_PULLS_TRST)
+{
+ jtag_add_reset(1, 1);
+}
+else
+{
+ jtag_add_reset(0, 1);
+}
+ }
+ else
+ {
+LOG_DEBUG(SRST not configured);
+dap_ap_select(dap, 0);
+return ERROR_FAIL;
+ }
+
+ while(1)
+ {
+retval = dap_queue_ap_write(dap, MDM_REG_CTRL, MEM_CTRL_FMEIP);
+if (retval != ERROR_OK)
+ return retval;
+dap_run(dap);
+/* read status register and wait for ready */
+retval = dap_queue_ap_read(dap, MDM_REG_STAT, val);
+if (retval != ERROR_OK)
+ return retval;
+dap_run(dap);
+LOG_DEBUG(MDM_REG_STAT %08X,val);
+
+if ( (val1))
+ break;
+ }
+
+ while(1)
+ {
+retval = dap_queue_ap_write(dap, MDM_REG_CTRL, 0);
+if (retval != ERROR_OK)
+ return retval;
+dap_run(dap);
+/* read status register */
+retval = dap_queue_ap_read(dap, MDM_REG_STAT, val);
+if (retval != ERROR_OK)
+ return retval;
+dap_run(dap);
+LOG_DEBUG(MDM_REG_STAT %08X,val);
+/* read control register and wait for ready */
+retval = dap_queue_ap_read(dap, MDM_REG_CTRL, val);
+if (retval != ERROR_OK)
+ return retval;
+dap_run(dap);
+LOG_DEBUG(MDM_REG_CTRL %08X,val);
+
+if ( val == 0x00 )
+ break;
+ }
+ }
+ }
+
+ dap_ap_select(dap, 0);
+
+ return ERROR_OK;
+}
+
+/** */
+struct dap_syssec_filter {
+ /** */
+ uint32_t idcode;
+ /** */
+ int (*dap_init)(struct adiv5_dap *dap);
+};
+
+/** */
+static struct dap_syssec_filter dap_syssec_filter_data
Re: [Openocd-development] [PATCH] kinetis cpu flash driver
No problem.
Am 12.09.2011 21:49, schrieb Øyvind Harboe:
Please squash the patches together and repost if they do belong in
the same patch.
Thanks!
From 1b17ccce801ff322ff5372207d82fb8827b4cbcf Mon Sep 17 00:00:00 2001
From: Mathias K. kes...@freenet.de
Date: Mon, 12 Sep 2011 21:58:49 +0200
Subject: [PATCH 2/2] kinetis cpu flash driver
Initial release of the freescale kinetis cpu flash driver.
---
src/flash/nor/Makefile.am |3 +-
src/flash/nor/drivers.c |2 +
src/flash/nor/kinetis.c | 532 +
3 files changed, 536 insertions(+), 1 deletions(-)
create mode 100644 src/flash/nor/kinetis.c
diff --git a/src/flash/nor/Makefile.am b/src/flash/nor/Makefile.am
index d7d66b0..a966826 100644
--- a/src/flash/nor/Makefile.am
+++ b/src/flash/nor/Makefile.am
@@ -32,7 +32,8 @@ NOR_DRIVERS = \
tms470.c \
virtual.c \
fm3.c \
- dsp5680xx_flash.c
+ dsp5680xx_flash.c \
+ kinetis.c
noinst_HEADERS = \
core.h \
diff --git a/src/flash/nor/drivers.c b/src/flash/nor/drivers.c
index 5d6e248..a437d84 100644
--- a/src/flash/nor/drivers.c
+++ b/src/flash/nor/drivers.c
@@ -45,6 +45,7 @@ extern struct flash_driver stmsmi_flash;
extern struct flash_driver em357_flash;
extern struct flash_driver dsp5680xx_flash;
extern struct flash_driver fm3_flash;
+extern struct flash_driver kinetis_flash;
/**
* The list of built-in flash drivers.
@@ -75,6 +76,7 @@ static struct flash_driver *flash_drivers[] = {
em357_flash,
fm3_flash,
dsp5680xx_flash,
+ kinetis_flash,
NULL,
};
diff --git a/src/flash/nor/kinetis.c b/src/flash/nor/kinetis.c
new file mode 100644
index 000..116363c
--- /dev/null
+++ b/src/flash/nor/kinetis.c
@@ -0,0 +1,532 @@
+/***
+ * Copyright (C) 2011 by Mathias Kuester *
+ * kes...@freenet.de *
+ * *
+ * This program is free software; you can redistribute it and/or modify *
+ * it under the terms of the GNU General Public License as published by *
+ * the Free Software Foundation; either version 2 of the License, or *
+ * (at your option) any later version. *
+ * *
+ * This program is distributed in the hope that it will be useful, *
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of*
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the *
+ * GNU General Public License for more details. *
+ * *
+ * You should have received a copy of the GNU General Public License *
+ * along with this program; if not, write to the *
+ * Free Software Foundation, Inc., *
+ * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. *
+ ***/
+#ifdef HAVE_CONFIG_H
+#include config.h
+#endif
+
+#include imp.h
+#include helper/binarybuffer.h
+
+static struct flash_bank *kinetis_get_master_bank(struct flash_bank *bank)
+{
+ struct flash_bank *master_bank;
+
+ master_bank = get_flash_bank_by_name_noprobe(bank-name);
+ if (master_bank == NULL) {
+ LOG_ERROR(master flash bank '%s' does not exist,
+ (char *)bank-driver_priv);
+ }
+
+ return master_bank;
+}
+
+static void kinetis_update_bank_info(struct flash_bank *bank)
+{
+ struct flash_bank *master_bank = kinetis_get_master_bank(bank);
+
+ if (master_bank == NULL) {
+ return;
+ }
+
+ /* update the info we do not have */
+ bank-size = master_bank-size;
+ bank-chip_width = master_bank-chip_width;
+ bank-bus_width = master_bank-bus_width;
+ bank-num_sectors = master_bank-num_sectors;
+ bank-sectors = master_bank-sectors;
+}
+
+FLASH_BANK_COMMAND_HANDLER(kinetis_flash_bank_command)
+{
+ if (CMD_ARGC 6) {
+ LOG_WARNING(incomplete flash_bank kinetis configuration %d,
+ CMD_ARGC);
+ return ERROR_FLASH_OPERATION_FAILED;
+ }
+
+ LOG_INFO(add flash_bank kinetis %s, bank-name);
+
+ return ERROR_OK;
+}
+
+static int kinetis_protect(struct flash_bank *bank, int set, int first,
+ int last)
+{
+ struct flash_bank *master_bank = kinetis_get_master_bank(bank);
+
+ LOG_WARNING(kinetis_protect not supported yet);
+
+ if (bank-target-state != TARGET_HALTED) {
+ LOG_ERROR(Target not halted);
+ return ERROR_TARGET_NOT_HALTED;
+ }
+
+ if (master_bank == NULL) {
+ return ERROR_FLASH_OPERATION_FAILED;
+ }
+
+ return ERROR_OK;
+}
+
+static int kinetis_protect_check(struct flash_bank *bank)
+{
+ struct flash_bank *master_bank = kinetis_get_master_bank(bank);
+ uint8_t buffer[4];
+ uint32_t fprot, psize, psec;
+ int result;
+ int i, b;
+
+ if (bank-target-state
[Openocd-development] kinetis cpu cortex-m4
Hello, is there any way to configure the MDM-AP (AP 1) from the K40-CPU shortly after ahbap_debugport_init and before any memory is read from the cpu? The initialization should be called if the IDCODE match, like a blacklist filter. This is important if the security on this cpu is enabled. It would be nice if you can give me some suggestion to do this. Regards, Mathias ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Kinetis KwikStik (Cortex-m4)
I get this issue because wrong target alignment. Flash commands works now. Am 09.09.2011 20:43, schrieb Mathias K.: any progress with flash programming? I have tried to start a mass-erase but i only get a MSGSTAT0. There is no protection enabled, i don't know whats wrong. Regards, Mathias ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Kinetis KwikStik (Cortex-m4)
Hello, Am 18.06.2011 15:21, schrieb j. m. norris: this is still work-in-progress and the writing of the on-chip flash does not work. I'm in the process of writing the code for that and I hope to submit that soon. any progress with flash programming? I have tried to start a mass-erase but i only get a MSGSTAT0. There is no protection enabled, i don't know whats wrong. Regards, Mathias ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Moin / my DSP563 plans
Hello, the 563xx is already supported by openocd. Symphony Studio works from a win pc connected to a linux openocd with a ftdi jtag device connected to the dsp. Breakpoints still not supported (ported) yet. Regards, Mathias Am 31.08.2011 13:45, schrieb Sam Hawkens: Alex, Stefan, it would be great to get the freescale openocd fork back into the official repo. The only thing is - I am not so sure branching is the best solution. I agree the 563xx is very different from any other processor in the universe. But a branch could cause trouble concerning future support. Maybe it would be easier to merge the rather old source from freescale against the current openocd source and bring things up to a quality high enough. Anyway, I have great interest in using my Symphony Soundbite EVM and hopefully my own hardware design with openocd. So if I can be of any help please feel free to contact me. I am currently trying to get the entire Symphony Studio Suite running on linux. I am not really interested in the c compiler, but the entire SDK is kind of nice. If anyone is interested in this, let me know. Or if anyone has succeeded using the toolchain on linux. Sam ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Coding style
Hello, eclipse are also able to format to a desired coding style. I think we should define an indent rule and use it as base. Personally i use the Allman-Style. Openocd mix more then two styles, i have seen Allman, KR and GNU. Regards, Mathias Am 28.08.2011 13:50, schrieb Michael Schwingen: On 28.08.2011 10:04, Øyvind Harboe wrote: Also, I'd be happy to let someone else define what the correct coding style is. I don't particularly care as long as the check can be automated and the style is consistent. Are there scripts to fix coding style too? at least indent and the C-Mode in emacs can do automatic re-formatting according to a configurable style. cu Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] TMS570 support in OpenOCD
Hello Tom, i have this stick too and it would be really nice if you can add flash support for this cpu. Regards, Mathias Am 23.08.2011 23:23, schrieb Tom Cauchois: Hi, I'm bringing up the TMS570 usb stick devkit (part# TMDX570LS20SUSB) with OpenOCD. I've gotten the target configuration working and I'd like to contribute the target and board files, since it had a few hoops to jump through (ICEPICK, no SRST, etc.). I'm still trying to get the flash driver to work. TMS570 uses the same flash technology as TMS470 (TI calls it F035), but the register mappings are different. Has anybody added an option to use the 570 register map? If not, I'd be happy to do so and contribute the patch. Thanks! Tom ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] how to use xds 100v2 Jtag with Openocd
Hello, Am 26.06.2011 14:30, schrieb Amit kumar: I am following http://elinux.org/BeagleBoardOpenOCD;, I am new to Openocd and bank on the support of this list. ./configure --enable-ft2232_ftd2xx --with-ftd2xx-linux-tardir=path_to/libftd2xx0.4.16 --prefix=/home/user/bin/openOCD is not Also, ./configure --enable-ft2232_libftdi --prefix=/home/root/bin/openOCD. Specify with-ftd2xx-linux-tardir and then it should work. Regards, Mathias ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] Get register value if it's invalid in cache
I think gdb will get the register list and then, maybe depending on used debug application, all register values. But we should remember that some/all functions in the current implementation, that need a target register to work, simple doesn't check if a register already stored or not. They only check if a target is halted or not. Regards, Mathias Am 03.05.2011 22:05, schrieb Øyvind Harboe: Start with a smoketest. Would this improve performance on ARM targets you think? ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] Get register value if it's invalid in cache
Am 03.05.2011 22:12, schrieb Jie Zhang: I'm not familiar with ARM targets. So I'm not very sure. My guess is this can also improve performance on ARM targets but they needs be adapted to this lazy read usage. Your blackfin is fast enough. This read usage only affect you if you rape the step command with some register output to find a bug in your application/kernel/bootloader. It's time to buy a faster Jtag-Adapter. This is awesome! Regards, Mathias ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Read register using GDB
Hello, please tell us more about your target platform. Regards, Mathias Am 02.05.2011 18:06, schrieb Jie Zhang: Hi, I encountered an issue when using OpenOCD with GDB. After GDB connects to OpenOCD and halt the target, info reg command returns all zeros for all registers. I took a look at the related code and found that when GDB requests register values from OpenOCD, OpenOCD does not read register from target, instead it just calls target_get_gdb_reg_list to create a register list without initializing it with real register value, and then just returns them to GDB. Is it a bug or by design? Regards, Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Read register using GDB
If you stop the target you should store the target context into the local register cache and if you resume the target you need to restore the context. This is why the target registers never read again if the target already halted. Am 02.05.2011 18:22, schrieb Jie Zhang: Thank you for your reply! I'm adding a new target to OpenOCD. But I think all existing targets in OpenOCD have this issue. Maybe I missed something... Jie On Mon, May 2, 2011 at 12:13 PM, Mathias K. kes...@freenet.de mailto:kes...@freenet.de wrote: Hello, please tell us more about your target platform. Regards, Mathias Am 02.05.2011 18:06, schrieb Jie Zhang: Hi, I encountered an issue when using OpenOCD with GDB. After GDB connects to OpenOCD and halt the target, info reg command returns all zeros for all registers. I took a look at the related code and found that when GDB requests register values from OpenOCD, OpenOCD does not read register from target, instead it just calls target_get_gdb_reg_list to create a register list without initializing it with real register value, and then just returns them to GDB. Is it a bug or by design? Regards, Jie ___ Openocd-development mailing list Openocd-development@lists.berlios.de mailto:Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD and 16-bit CFI flash on an 8-bit bus
Hello, there are several mechanism to protect or unprotect the sectors (factory/customer). If the Secured Silicon Sector locked you need 12V at the reset pin to execute the Temporary Sector Group Unprotect command. If the Secured Silicon Sector not locked you are able to unlock the sectors permanently inside the Secured Silicon Sector Command Sequence. Regards, Mathias Am 19.04.2011 07:37, schrieb Rogan Dawes: On 2011/04/18 10:00 PM, Michael Schwingen wrote: Any ideas why the flash unprotect might fail? AFAIR, this is not implemented for AMD/Spansion parts, since these parts never had any protection mechanism when they started. In Contrast, many Intel flashes come up protected out of reset and *need* the unprotect operation. Are you sure your flash *does* have protection and *needs* unprotect? Otherwise, you can simple remove the unprotect option. cu Michael Hi Michael, Well, flash info 0 shows that certain sectors are protected and that others are not, which suggests that protection is actually present and implemented in this particular chip. I'll try to dig into this in a bit more detail. Thanks Rogan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] fix broken dap component base for tms570 on debug logic
Hello,
i only have test it with this configuration, no more investigations. I think
the biggest problem is
the flash write functionality.
Regards,
Mathias
Am 13.04.2011 20:05, schrieb Ingo Hornberger:
Mathias K. kesmtp@... writes:
[...]
Anyway, i was able to connect to the cortex-r4 (tms570) with a cortex_a8
configuration. I can read
the registers, halt, step and resume seems to work.
Regards,
Mathias
---
[...]
Hi Mathias,
I am currently evaluating the TMS570 with OpenOCD. I played around with it a
little bit, but I think I still have a problem in my configuration.
I get the following warning on every command (which I think is actually an
error ;) ):
Warn : Invalid ACK 0x6 in JTAG-DP transaction
Could you please provide your openocd.cfg to me?
TIA!
Best regards,
Ingo
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
source [find interface/ti-tms570.cfg]
set CHIPNAME tms570
set CHIPTYPE am35x
adapter_khz 10
source [find target/amdm37x.cfg]
#
# Copyright (C) 2010by Karl Kurbjun
# Copyright (C) 2009, 2010 by Ãyvind Harboe
# Copyright (C) 2009by David Brownell
# Copyright (C) 2009by Magnus Lundin
#
# TI AM/DM37x
# http://www.ti.com/litv/pdf/sprugn4b
#
# This script is based on the AM3517 initialization. It should be considered
# preliminary since it needs more complete testing and only the basic
# operations work.
#
###
# User modifiable parameters
###
set _ENDIAN big
# This script uses the variable CHIPTYPE to determine whether this is an AM35x
# or DM37x target. If CHIPTYPE is not set it will error out.
if { [info exists CHIPTYPE] } {
if { [info exists CHIPNAME] } {
set _CHIPNAME $CHIPNAME
} else {
set _CHIPNAME $CHIPTYPE
}
switch $CHIPTYPE {
dm37x {
# Primary TAP: ICEpick-C (JTAG route controller) and boundary scan
set _JRC_TAPID 0x1b7b302f
}
am35x {
# Primary TAP: ICEpick-C (JTAG route controller) and boundary scan
set _JRC_TAPID 0x1b7b302f
}
default {
error ERROR: CHIPTYPE was set, but it was not set to a valid value.
Acceptable values are \dm37x\ or \am35x\.
}
}
} else {
error ERROR: CHIPTYPE was not defined. Please set CHIPTYPE to \am35x\ for
the AM35x or \dm37x\ for the DM37x series in the board configuration.
}
# Run the adapter at the fastest acceptable speed with the slowest possible
# core clock.
adapter_khz 100
###
# JTAG setup
# The OpenOCD commands are described in the TAP Declaration section
# http://openocd.berlios.de/doc/html/TAP-Declaration.html
###
# The AM/DM37x has an ICEpick module in it like many of TI's other devices. More
# can be read about this module in sprugn4b under chapter 27: Debug and
# Emulation. The module is used to route the JTAG chain to the various
# subsystems in the chip.
source [find target/icepick.cfg]
# The TAP order should be described from the TDO connection in OpenOCD to the
# TDI pin. The OpenOCD FAQ describes this in more detail:
# http://openocd.berlios.de/doc/html/FAQ.html
# From SPRUGN4B CH27 the available secondary TAPs are in this order from TDO:
#
# Device | TAP number
# -|
# DAP | 3
# Sequencer| 2 Note: The sequencer is an ARM968
# DSP | 1
# D2D | 0
#
# Right now the only secondary tap enabled is the DAP so the rest are left
# undescribed.
##
# Start of Chain Description
# The Secondary TAPs all have enable functions defined for use with the ICEpick
# Only the DAP is enabled. The AM37xx does not have the Sequencer or DSP but
# the TAP numbers for ICEpick do not change.
#
# TODO: A disable function should also be added.
##
# Secondary TAP: D2D it is not in the chain by default (-disable)
# The ICEpick can be used to enable it in the chain.
# This IRLEN is probably incorrect - not sure where the documentation is.
jtag newtap $_CHIPNAME etb -irlen 4 -ircapture 0x1 -irmask 0x0f -disable
jtag configure $_CHIPNAME.etb -event tap-enable \
icepick_c_tapenable $_CHIPNAME.jrc 1
# Secondary TAP: DAP is closest to the TDO output
# The TAP enable event also needs to be described
jtag newtap $_CHIPNAME dap -irlen 4 -ircapture 0x1 -irmask 0x1 -disable
jtag configure $_CHIPNAME.dap -event tap-enable \
icepick_c_tapenable $_CHIPNAME.jrc 0
# Primary TAP: ICEpick - it is closest to TDI so last in the chain
jtag newtap $_CHIPNAME jrc -irlen 6 -ircapture 0x1 -irmask 0x3f \
-expected-id $_JRC_TAPID
##
# End of Chain Description
Re: [Openocd-development] Help with stellaris
Hello, sometimes i see this messages if my jtag cable (flat cable) not correct connected to the target board. But this is a cable issue. Regards, Mathias Am 12.04.2011 14:44, schrieb Sergio: Info : JTAG tap: lm3s2776.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3) Warn : Invalid ACK 0 in JTAG-DP transaction Warn : Invalid ACK 0x7 in JTAG-DP transaction Warn : Invalid ACK 0 in JTAG-DP transaction Warn : Invalid ACK 0 in JTAG-DP transaction Warn : Block read error address 0xe000ed00, count 0x1 Warn : Invalid ACK 0 in JTAG-DP transaction Warn : Invalid ACK 0 in JTAG-DP transaction Warn : Invalid ACK 0 in JTAG-DP transaction Warn : Invalid ACK 0 in JTAG-DP transaction Warn : Invalid ACK 0 in JTAG-DP transaction Warn : Invalid ACK 0 in JTAG-DP transaction Warn : Invalid ACK 0 in JTAG-DP transaction Warn : Invalid ACK 0 in JTAG-DP transaction ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] ULINK driver: firmware license questions
Am 06.04.2011 18:58, schrieb Michael Schwingen: Am 04/06/2011 05:45 PM, schrieb Laurent Gauch: However, if the ULINK is basically an EZ-USB chip which downloads its code via USB, using the ULINK protocol would also mean we would have to use Keil's firmware, as it needs to be downloaded every time the ULINK adapter is powered on. If i remember correct (from an older and different project) the firmware upload is done with the EZ-USB protocol, there is no custom software bootloader inside the chip. But the reverse engineering include hardware and software skills and not only the protocol stuff. The library source code is a modified version of the original source from Keil, which does not contain any license information. You should look what kind of copyright cypress use original for this lib and ask cypress if they sell the source to keil or it is always free and ask Keil why they give out this modified source without any copyright information (honey pot). Regards, Mathias ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] ULINK driver: firmware license questions
Hello, Am 06.04.2011 19:53, schrieb Martin Schmölzer: On Wed, 2011-04-06 at 17:45 +0200, Laurent Gauch wrote: The EZ-USB gives access to USB but not to the ULINK interface. Right ? The ULINK consists of the EZ-USB microcontroller, an SRAM, an EEPROM and level shifters. There's even a schematic floating around the net: http://www.mikrocontroller.net/attachment/51828/ULink.pdf Keil is just using the digital I/O of the EZ-USB to read/write the JTAG signals, quite simple actually. From the schematic (only to know about): Keil ULINK Reverse Engineered by Johann Glaser 2009-05-31 This is only for research purposes and to use the quite generic hardware to implement other programming devices as well as Linux support. He wrote that he has written his own firmware, so that would probably use a different protocol but just run on the ULINK hardware - that would be perfectly acceptable. Exactly. I have designed my own protocol and implemented it in my custom firmware. I've also written a demo program in C++ that can erase/program flash, read/write fuses, ... in various Atmel AVR (8-bit) devices with my ULINK firmware. If you use the ATMEL-JTAG interface or the special spi interface with the reset line as chip select? Regards, Mathias ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] cygwin: git head jimsh compilation failed
I was able to link openocd against libjim. There is only a problem to link jimsh against libjim. Regards, Mathias Am 02.04.2011 03:10, schrieb Steve Bennett: On 10/03/2011, at 9:20 PM, Mathias K. wrote: I have append it, it is only the linker output. Am 10.03.2011 11:47, schrieb Peter Stuge: Mathias K. wrote: Any hints to solve this problem? Please send exact copy of error messages, otherwise any diagnosis is impossible. It looks like something has gone wrong with the creation of libjim.a and it is empty. Please post the output of: nm libjim.a -- µWeb: Embedded Web Framework - http://uweb.workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: +61 434 921 300 E: ste...@workware.net.au F: +61 7 3391 6002 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD crash on startup with JtagKey
Hello, please tell us the version of the ftd2xx or read the ml. Regards, Mathias Am 31.03.2011 19:14, schrieb Gwennaël Arbona: Hi, I am having a bug using OpenOCD 0.5.0-dev-00815-g8d338f3 (just compiled). I am working on Debian Squeeze 32 bits. I am using ftd2xx from FTDI. So I got it compiled, and now it is shutting down almost immediatly. Here is my command and output: $ openocd -f /usr/share/openocd/scripts/interface/jtagkey.cfg Open On-Chip Debugger 0.5.0-dev-00815-g8d338f3 (2011-03-31-18:24) Licensed under GNU GPL v2 For bug reports, read http://openocd.berlios.de/doc/doxygen/bugs.html Info : only one transport option; autoselect 'jtag' Error: unable to get latency timer: 4 in procedure 'init' WTF is this? My hardware is a brand new JTAGKey (never used so far). Seems running OK, no warning from dmesg, perfectly detected Amontec etc. If any other info is useful, feel free to ask. Thanks --- Gwennaël ARBONA gwennael.arb...@gmail.com mailto:gwennael.arb...@gmail.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD and D2XX v.1.0.4 for Linux
Hello,
i can't reproduce your errors. The libftdi and d2xx works like a charm here
(linux/windows). Error 4
means IO Error. I think you have carefully check your USB cables and your
hardware. If you work with
linux you can try dmesg to get some reports about hardware problems,
specially usb.
Regards,
Mathias
Am 29.03.2011 12:37, schrieb Drasko DRASKOVIC:
Hi all,
commenting out FT_GetLatencyTimer() call seems to be a workaround :
#if 0
if ((status = FT_GetLatencyTimer(ftdih, latency_timer)) != FT_OK)
{
LOG_ERROR(unable to get latency timer: %lu, status);
return ERROR_JTAG_INIT_FAILED;
}
else
#endif
{
latency_timer = 2;
LOG_DEBUG(current latency timer: %i, latency_timer);
}
I have no idea why this function is not working.
This workaround seems to be fixing
Error: couldn't read enough bytes from FT2232 device (0 5)
problem that I saw before with libftdi.
However, more surprising are build problems with OpenOCD and D2XX
1.0.4 that I described below.
BR,
Drasko
On Mon, Mar 28, 2011 at 4:07 PM, Drasko DRASKOVIC
drasko.drasko...@gmail.com wrote:
Hi all,
I downloaded D2XX driver from here :
http://www.ftdichip.com/Drivers/D2XX.htm. It is version 1.0.4 for
Linux x86 (32-bit).
I tried compiling OpenOCD with libftd2xx statically (which is by
default). Configuration is failing with :
checking uninstalled ftd2xx distribution...
-L/home/ddraskovic/sandbox/libftd2xx1.0.4/libftd2xx1.0.4/static_lib
/home/ddraskovic/sandbox/libftd2xx1.0.4/libftd2xx1.0.4/static_lib/libftd2xx.a
checking whether ftd2xx library works... configure: error: Cannot
build run test program using ftd2xx.lib
In config.log I saw :
/home/ddraskovic/sandbox/libftd2xx1.0.4/libftd2xx1.0.4/static_lib/libftd2xx.a(ftd2xx.o):
In function `FTCommonOpen':
/home/madamson/Desktop/Mac-Linux sources/libftd2xx/ftd2xx.c:1654:
undefined reference to `pthread_create'
/home/madamson/Desktop/Mac-Linux sources/libftd2xx/ftd2xx.c:1656:
undefined reference to `pthread_create'
/home/ddraskovic/sandbox/libftd2xx1.0.4/libftd2xx1.0.4/static_lib/libftd2xx.a(ftd2xx.o):
In function `FT_Close':
/home/madamson/Desktop/Mac-Linux sources/libftd2xx/ftd2xx.c:1812:
undefined reference to `pthread_join'
/home/madamson/Desktop/Mac-Linux sources/libftd2xx/ftd2xx.c:1821:
undefined reference to `pthread_join'
So obviously it was missing libpthrads.
After adding -lpthread to CFLAGS, there is another problem :
/home/ddraskovic/sandbox/libftd2xx1.0.4/libftd2xx1.0.4/static_lib/libftd2xx.a(linux_usbfs.o):
In function `find_monotonic_clock':
/home/madamson/Desktop/Mac-Linux
sources/libftd2xx/libusb/libusb/os/linux_usbfs.c:206: undefined
reference to `clock_gettime'
/home/ddraskovic/sandbox/libftd2xx1.0.4/libftd2xx1.0.4/static_lib/libftd2xx.a(linux_usbfs.o):
In function `op_clock_gettime':
/home/madamson/Desktop/Mac-Linux
sources/libftd2xx/libusb/libusb/os/linux_usbfs.c:2146: undefined
reference to `clock_gettime'
/home/madamson/Desktop/Mac-Linux
sources/libftd2xx/libusb/libusb/os/linux_usbfs.c:2148: undefined
reference to `clock_gettime'
So librt is already missing, and I had to add -lrt also to CFLAGS.
After this I was able to sucessfully compile OpenOCD with libftd2xx,
with observation of warnings like this during compile :
ft2232.c: In function ‘ft2232_write’:
ft2232.c:512: warning: format ‘%lu’ expects type ‘long unsigned int’,
but argument 6 has type ‘FT_STATUS’
ft2232.c: In function ‘ft2232_read’:
ft2232.c:555: warning: format ‘%lu’ expects type ‘long unsigned int’,
but argument 6 has type ‘FT_STATUS’
ft2232.c: In function ‘ft2232_init_ftd2xx’:
ft2232.c:2194: warning: format ‘%lu’ expects type ‘long unsigned int’,
but argument 6 has type ‘FT_STATUS’
ft2232.c:2198: warning: format ‘%lu’ expects type ‘long unsigned int’,
but argument 6 has type ‘FT_STATUS’
ft2232.c:2214: warning: format ‘%lu’ expects type ‘long unsigned int’,
but argument 6 has type ‘DWORD’
Same kind of wornings are present when we compile libftd2xx as a shared
library.
When I try to start newly compiled OpenOCD binary I am getting :
Debug: 169 18 ft2232.c:2433 ft2232_init() 104248: ft2232 interface
using shortest path jtag state transitions
Debug: 170 18 ft2232.c:2133 ft2232_init_ftd2xx() 104248: 'ft2232'
interface using FTD2XX with 'jtagkey' layout (0403:cff8)
Error: 171 56 ft2232.c:2239 ft2232_init_ftd2xx() 137560: unable to get
latency timer: 4
Debug: 172 56 command.c:638 run_command() 137448: Command failed with
error code -100
Came behavior with libftd2xx as a shared lib.
libftd2xx0.4.16 which I used before does not show this error (but has
some other problems and that's why I want to replace it with new
version or ideally Amontec officiel drivers).
I am using Amontec JTAGKey2 probe. Since Officiel Amontec drivers are
based on version 1.0.4 of D2XX I am getting exactly same error.
What can be
Re: [Openocd-development] OpenOCD and D2XX v.1.0.4 for Linux
Am 29.03.2011 15:16, schrieb Drasko DRASKOVIC: Xiaofan, thanks for this confirmation. We can say that we identified the issue. However, it is still strange that the issue is not reproducible by Mathias... Mathias, are you sure that you used latest D2XX, version 1.0.4 ? No, not this one. I have test it with: WinXP: d2xx 2.08.12 (2011-02-28) Linux: d2xx 0.4.16-r1 Linux: libftdi 0.18 Regards, Mathias ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD and D2XX v.1.0.4 for Linux
Yes, but works with the latest windows d2xx. Regards, Mathias Am 29.03.2011 16:21, schrieb Drasko DRASKOVIC: On Tue, Mar 29, 2011 at 4:03 PM, Mathias K. kes...@freenet.de wrote: Linux: d2xx 0.4.16-r1 Yes, it works for me also with 0.4.16. Problem is in new D2XX 1.0.4. BR, Drasko ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 1/2] dsp563xx: fix bug in x buffer handling
Yes, thanks. Am 15.03.2011 16:32, schrieb Øyvind Harboe: better? ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] chunksize src/flash/nor/tcl.c
Hello, for performance reason i would change the chunksize in src/flash/nor/tcl.c from a hard coded value to a option/parameter with a default value of the old hard coded value (1024). Currently i use a value of 32*1024. Can anyone give me a suggestion to add this to the configuration file, preferably a option in the flash section? Thanks, Mathias ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] MIPS (Big Endian) Questions
Hello, Am 17.03.2011 13:45, schrieb Drasko DRASKOVIC: 1) In openocd/src/target/mips_m4k.c we can see that target endianess is checked and treated only mips_m4k_bulk_write_memory() in and not mips_m4k_write_memory() and mips_m4k_read_memory(). Why is this so ? (It leads to wrong SDRAM setup, as mww and mdw commands make no sense in my case, because mips_m4k_write_memory() is called and my taget is big endian). You need to call target.c:target_buffer_get_u32 and the other functions to convert your data to the correct endianness. 2) When is mips_m4k_bulk_write_memory() actually called ? Obviously from my tests - not always. I can see it called when I am trying to load bigger files into SDRAM, but for smaller directly mips_m4k_write_memory() is called (and thus endianess is never treated). How does this fast_write actually works in MIPS case ? Bulk is called on aligned data and a length 128 bytes if i remember correct (target.c:target_write_buffer). 3) Can we conclude based on this that big endian targets for MIMPS are not supported in the current OpenOCD implementation ? Did anyone had sucess running OpenOCD eith big endian target and how is it done in this case, having in mind problems I pointed out. The dsp56k is big endian. See 1) Regards, Mathias ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] MIPS and Big Endian
Hello, the send buffer looks okay. Maybe this is a timeout problem. Do you use the d2xx or ftdi library? Regards, Mathias Am 17.03.2011 13:14, schrieb Drasko DRASKOVIC: 3174056 Debug: 3174389 188209 ft2232.c:809 ft2232_send_and_recv(): write buffer (size 18): 3174057 Debug: 3174390 188209 ft2232.c:784 ft2232_debug_dump_buffer(): 4b 02 01 39 02 00 00 c0 04 3b 06 80 6b 01 81 4b 3174058 Debug: 3174391 188209 ft2232.c:790 ft2232_debug_dump_buffer(): 02 03 3174059 Error: 3174392 192209 ft2232.c:584 ft2232_read(): couldn't read enough bytes from FT2232 device (0 5) 3174060 Error: 3174393 192209 ft2232.c:839 ft2232_send_and_recv(): couldn't read from FT2232 3174061 Error: 3174394 192209 mips_ejtag.c:115 Errors repeat later : 5759736 Debug: 5760353 334312 ft2232.c:809 ft2232_send_and_recv(): write buffer (size 27): 5759737 Debug: 5760354 334312 ft2232.c:784 ft2232_debug_dump_buffer(): 4b 03 03 1b 03 0a 4b 02 03 4b 02 01 39 02 00 00 5759738 Debug: 5760355 334312 ft2232.c:790 ft2232_debug_dump_buffer(): c0 00 3b 06 80 6b 01 81 4b 02 03 5759739 Error: 5760356 338311 ft2232.c:584 ft2232_read(): couldn't read enough bytes from FT2232 device (0 5) 5759740 Error: 5760357 338311 ft2232.c:839 ft2232_send_and_recv(): couldn't read from FT2232 5759741 Error: 5760358 338311 mips_ejtag.c:115 mips_ejtag_drscan_32(): register read failed ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] MIPS and Big Endian
I think you should reduce your clock speed first. Am 17.03.2011 16:27, schrieb Drasko DRASKOVIC: clock speed 6000 kHz ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] MIPS and Big Endian
Hello, Am 16.03.2011 20:19, schrieb Drasko DRASKOVIC: However, trying to load a bigger image function mips_m4k_bulk_write_memory() is called an fails in mips32_pracc_fastdata_xfer(). So, making mips_m4k_bulk_write_memory() to fall straight away to simple mips_m4k_write_memory(), like in mentioned David's commit b271efe12132e93cb17adb037323f6cf251305b2 seems to be showing better results, but I still have following error for bigger writes : couldn't read enough bytes from FT2232 device (0 5) couldn't read from FT2232 register read failed Do you have any idea why this is happening and can this be related to Amontec JTAG Key 2 probe I have been using ? Can you try to start openocd with -d 3 and try again to see more informations related to this issue. Regards, Mathias ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 1/2] dsp563xx: fix bug in x buffer handling
Hello,
the correct fix should be:
((uint32_t*)buffer)[i+1] = ((uint32_t*)buffer_x)[i1];
This function merge buffer_y and buffer_x into buffer.
Regards,
Mathias
Am 15.03.2011 15:08, schrieb Øyvind Harboe:
found by inspection, not confirmed.
Signed-off-by: Øyvind Harboe oyvind.har...@zylin.com
---
src/target/dsp563xx.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/target/dsp563xx.c b/src/target/dsp563xx.c
index cb2025e..4969ed5 100644
--- a/src/target/dsp563xx.c
+++ b/src/target/dsp563xx.c
@@ -1467,7 +1467,7 @@ static int dsp563xx_read_memory(struct target *target,
int mem_type, uint32_t ad
for(i=0,i1=0;icount;i+=2,i1++)
{
((uint32_t*)buffer)[i] = ((uint32_t*)buffer_y)[i1];
- ((uint32_t*)buffer)[i] = ((uint32_t*)buffer_x)[i1];
+ ((uint32_t*)buffer)[i] = ((uint32_t*)buffer_x)[i1+1];
}
free(buffer_y);
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] cygwin: git head jimsh compilation failed
Hello, the current git head failed to compile jimtcl. I use latest cygwin and following configure options: ./configure --enable-maintainer-mode --disable-werror --disable-shared \ --enable-ft2232_ftd2xx \ --with-ftd2xx-win32-zipdir=/cygdrive/c/data/cdm/ Last compiler line: gcc -g -O2 -o jimsh.exe jimsh.o libjim.a -lwsock32 -lm Error messages are about undefined references to Jim_NewListObj ... and stderr. I can disable the compilation of jimsh in the jimtcl/Makefile and then all is compiling fine. Any hints to solve this problem? Regards, Mathias ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] cygwin: git head jimsh compilation failed
I have append it, it is only the linker output. Am 10.03.2011 11:47, schrieb Peter Stuge: Mathias K. wrote: Any hints to solve this problem? Please send exact copy of error messages, otherwise any diagnosis is impossible. make all-recursive make[1]: Entering directory `/cygdrive/c/data/cygwin/openocd/src/openocd' Making all in jimtcl make[2]: Entering directory `/cygdrive/c/data/cygwin/openocd/src/openocd/jimtcl' gcc -g -O2 -o jimsh.exe jimsh.o libjim.a -lwsock32 -lm jimsh.o: In function `JimSetArgv': /home/user/private/openocd/openocd/jimtcl/jimsh.c:51: undefined reference to `Jim_NewListObj' /home/user/private/openocd/openocd/jimtcl/jimsh.c:55: undefined reference to `Jim_NewStringObj' /home/user/private/openocd/openocd/jimtcl/jimsh.c:57: undefined reference to `Jim_ListAppendElement' /home/user/private/openocd/openocd/jimtcl/jimsh.c:60: undefined reference to `Jim_SetVariableStr' /home/user/private/openocd/openocd/jimtcl/jimsh.c:61: undefined reference to `Jim_NewIntObj' /home/user/private/openocd/openocd/jimtcl/jimsh.c:61: undefined reference to `Jim_SetVariableStr' jimsh.o: In function `main': /home/user/private/openocd/openocd/jimtcl/jimsh.c:70: undefined reference to `Jim_CreateInterp' /home/user/private/openocd/openocd/jimtcl/jimsh.c:71: undefined reference to `Jim_RegisterCoreCommands' /home/user/private/openocd/openocd/jimtcl/jimsh.c:74: undefined reference to `Jim_InitStaticExtensions' /home/user/private/openocd/openocd/jimtcl/jimsh.c:79: undefined reference to `Jim_SetVariableStrWithStr' /home/user/private/openocd/openocd/jimtcl/jimsh.c:80: undefined reference to `Jim_SetVariableStrWithStr' /home/user/private/openocd/openocd/jimtcl/jimsh.c:81: undefined reference to `Jim_Eval' /home/user/private/openocd/openocd/jimtcl/jimsh.c:102: undefined reference to `Jim_NewStringObj' /home/user/private/openocd/openocd/jimtcl/jimsh.c:102: undefined reference to `Jim_SetVariableStr' /home/user/private/openocd/openocd/jimtcl/jimsh.c:104: undefined reference to `Jim_EvalFile' /home/user/private/openocd/openocd/jimtcl/jimsh.c:120: undefined reference to `Jim_FreeInterp' /home/user/private/openocd/openocd/jimtcl/jimsh.c:96: undefined reference to `Jim_Eval' /home/user/private/openocd/openocd/jimtcl/jimsh.c:98: undefined reference to `Jim_GetString' jimsh.o: In function `printf': /usr/include/bits/stdio2.h:105: undefined reference to `__printf_chk' jimsh.o: In function `main': /home/user/private/openocd/openocd/jimtcl/jimsh.c:75: undefined reference to `Jim_MakeErrorMessage' /home/user/private/openocd/openocd/jimtcl/jimsh.c:76: undefined reference to `Jim_GetString' jimsh.o: In function `fprintf': /usr/include/bits/stdio2.h:98: undefined reference to `stderr' /usr/include/bits/stdio2.h:98: undefined reference to `__fprintf_chk' jimsh.o: In function `main': /home/user/private/openocd/openocd/jimtcl/jimsh.c:80: undefined reference to `Jim_SetVariableStrWithStr' /home/user/private/openocd/openocd/jimtcl/jimsh.c:81: undefined reference to `Jim_Eval' /home/user/private/openocd/openocd/jimtcl/jimsh.c:112: undefined reference to `Jim_GetExitCode' /home/user/private/openocd/openocd/jimtcl/jimsh.c:85: undefined reference to `Jim_MakeErrorMessage' /home/user/private/openocd/openocd/jimtcl/jimsh.c:86: undefined reference to `Jim_GetString' jimsh.o: In function `fprintf': /usr/include/bits/stdio2.h:98: undefined reference to `stderr' /usr/include/bits/stdio2.h:98: undefined reference to `__fprintf_chk' jimsh.o: In function `main': /home/user/private/openocd/openocd/jimtcl/jimsh.c:90: undefined reference to `Jim_InteractivePrompt' /home/user/private/openocd/openocd/jimtcl/jimsh.c:107: undefined reference to `Jim_MakeErrorMessage' /home/user/private/openocd/openocd/jimtcl/jimsh.c:108: undefined reference to `Jim_GetString' jimsh.o: In function `fprintf': /usr/include/bits/stdio2.h:98: undefined reference to `stderr' /usr/include/bits/stdio2.h:98: undefined reference to `__fprintf_chk' /usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../libcygwin.a(libcmain.o):(.text+0xa9): undefined reference to `_WinMain@16' collect2: ld returned 1 exit status make[2]: *** [jimsh.exe] Error 1 make[2]: Leaving directory `/cygdrive/c/data/cygwin/openocd/src/openocd/jimtcl' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/cygdrive/c/data/cygwin/openocd/src/openocd' make: *** [all] Error 2 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] New warnings about ftdi read buffer
Hello, this message should be only visible if the debug output enabled. If you have usb read/write problems sometimes, this is the point you have to look. Regards, Mathias Am 03.03.2011 10:19, schrieb Jon Povey: Since 6ddcee7d20ee873f1c214736c22f29d9781dded4 When I try to read memory, I get read buffer size looks to high (I suppose that should be too instead of to) e.g. amontec jtagkey, TI DM355 (ARM926EJ-S) mdb 0 64 read buffer size looks to high read buffer size looks to high read buffer size looks to high 0x: fe 1f 00 ea fd 1f 00 ea fc 1f 00 ea 04 f0 5e e2 08 f0 5e e2 f9 1f 00 ea f8 1f 00 ea e0 27 00 ea 0x0020: 29 0b 00 00 00 00 00 00 31 0f 09 ee 11 0f 19 ee 38 00 9f e5 1d 00 80 e3 11 0f 09 ee 34 00 9f e5 As a user, how am I supposed to react to this message? It's rather opaque. And things still seem to work. So far just noticed it on longish memory dumps. -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] ft2232: fix log message and change log output to debug
Hello,
this patch fix the log message and change the log output to debug.
Regards,
Mathias
From 1eea6ab88e31e912eea0f4b14c7317329fa6 Mon Sep 17 00:00:00 2001
From: Mathias K. kes...@freenet.de
Date: Thu, 3 Mar 2011 10:28:21 +0100
Subject: [PATCH] ft2232: fix log message and change log output to debug
---
src/jtag/drivers/ft2232.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/jtag/drivers/ft2232.c b/src/jtag/drivers/ft2232.c
index a84d069..fdabb64 100644
--- a/src/jtag/drivers/ft2232.c
+++ b/src/jtag/drivers/ft2232.c
@@ -2100,7 +2100,7 @@ static int ft2232_execute_queue(void)
if (ft2232_expect_read = FT2232_BUFFER_READ_QUEUE_SIZE )
{
if (ft2232_expect_read
(FT2232_BUFFER_READ_QUEUE_SIZE+1) )
- LOG_WARNING(read buffer size looks to high);
+ LOG_DEBUG(read buffer size looks too high
%d/%d,ft2232_expect_read,(FT2232_BUFFER_READ_QUEUE_SIZE+1));
if (ft2232_send_and_recv(first_unsent, cmd) != ERROR_OK)
retval = ERROR_JTAG_QUEUE_FAILED;
first_unsent = cmd;
--
1.7.3.4
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] target: memory alignment option
Hello,
this patch add a target memory alignment option.
Regards,
Mathias
From 7cafbb5b454fb79f36368e9b8c3a62b486f6c024 Mon Sep 17 00:00:00 2001
From: Mathias K. kes...@freenet.de
Date: Thu, 3 Mar 2011 11:01:46 +0100
Subject: [PATCH] target: memory alignment option
Add a target option to enable/disable memory alignment.
---
src/target/target.c | 19 ++-
src/target/target.h |8
2 files changed, 26 insertions(+), 1 deletions(-)
diff --git a/src/target/target.c b/src/target/target.c
index 3a6c6bb..971531b 100644
--- a/src/target/target.c
+++ b/src/target/target.c
@@ -1356,6 +1356,14 @@ int target_write_buffer(struct target *target, uint32_t
address, uint32_t size,
return ERROR_FAIL;
}
+ /* if memory alignment disabled handle all parameters
+* on target implementation
+*/
+ if ( target-alignment == MEMORY_ALIGNMENT_DISABLED )
+ {
+ return target_write_memory(target, address, 0, size, buffer);
+ }
+
if (((address % 2) == 0) (size == 2))
{
return target_write_memory(target, address, 2, 1, buffer);
@@ -1438,6 +1446,14 @@ int target_read_buffer(struct target *target, uint32_t
address, uint32_t size, u
return ERROR_FAIL;
}
+ /* if memory alignment disabled handle all parameters
+* on target implementation
+*/
+ if ( target-alignment == MEMORY_ALIGNMENT_DISABLED )
+ {
+ return target_read_memory(target, address, 0, size, buffer);
+ }
+
if (((address % 2) == 0) (size == 2))
{
return target_read_memory(target, address, 2, 1, buffer);
@@ -3695,7 +3711,6 @@ static Jim_Nvp nvp_config_opts[] = {
{ .name = -variant, .value = TCFG_VARIANT },
{ .name = -coreid, .value = TCFG_COREID },
{ .name = -chain-position, .value = TCFG_CHAIN_POSITION },
-
{ .name = NULL, .value = -1 }
};
@@ -4673,6 +4688,8 @@ static int target_create(Jim_GetOptInfo *goi)
/* will be set by -endian */
target-endianness = TARGET_ENDIAN_UNKNOWN;
+ target-alignment = MEMORY_ALIGNMENT_ENABLED;
+
/* default to first core, override with -coreid */
target-coreid = 0;
diff --git a/src/target/target.h b/src/target/target.h
index 2bf9668..07b6e6f 100644
--- a/src/target/target.h
+++ b/src/target/target.h
@@ -90,6 +90,13 @@ enum target_endianess
TARGET_BIG_ENDIAN = 1, TARGET_LITTLE_ENDIAN = 2
};
+enum memory_alignment
+{
+ MEMORY_ALIGNMENT_UNKNOWN = 0,
+ MEMORY_ALIGNMENT_ENABLED = 1,
+ MEMORY_ALIGNMENT_DISABLED = 2
+};
+
struct working_area
{
uint32_t address;
@@ -140,6 +147,7 @@ struct target
struct working_area *working_areas;/* list of allocated working areas */
enum target_debug_reason debug_reason;/* reason why the target entered
debug state */
enum target_endianess endianness; /* target endianess */
+ enum memory_alignment alignment;/* memory alignment */
// also see: target_state_name()
enum target_state state;/* the current
backend-state (running, halted, ...) */
struct reg_cache *reg_cache;/* the first register cache of
the target (core regs) */
--
1.7.3.4
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] ft2232 drivers question
Hello, read http://www.ftdichip.com/Support/Documents/DataSheets/ICs/DS_FT4232H.pdf page 9. Looks like a wrong hardware implementation. It is not possible to switch any jtag pin. Regards, Mathias Am 02.03.2011 13:22, schrieb Jean-Christophe PLAGNIOL-VILLARD: Hi, I'm currently adding the support of a third party JTAG based on a ftdi FT4232 but on my devices the TDO is connected to ADBUS1 and TDI ADBUS2 how can I specify this in the drivers? Best Regards, J. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] question about memory access in target.c
Am 25.02.2011 17:54, schrieb Michael Schwingen: Mathias K. wrote: Am 25.02.2011 14:38, schrieb Michael Schwingen: Mathias K. wrote: I think you can't simple abstract this with 8/16/24/32bit access, because in my case the data bus has always a 24bit width and the address bus increment is always one (one address and 3 bytes of data). There is no alternative alignment how you can describe a byte of this 24bit with a bus address, thats the problem. So the problem is that a word (of 24 bits) is supported as the *only* access type? Yes, thats true. In that case, I think we should talk about unaligned accesses insteadof harvard/risc. Okay, sounds good. Now the question is how to handle this at the higher layers: - only allow word-sized accesses - ie. fail all byte-read/write attempts This should work. GDB as example always read/write the memory or registers with a 32bit access, the highest byte is never used but transfered. If all upper layers (including flash programming etc.) can live with that restriction, this would be my preferred solution - do not try to get smart and (badly) emulate things that the platform can't provide. I think thats okay. Debugging already works and on my platform flash programming is another problem. There are 3 16-Bit cfi chips running in 8-Bit mode and every chip mapped to one byte in this 24-Bit data word ;-). More then one chip in a memory area is not supported by openocd, alignment is heavily used in cfi.c and the write_block functions simple wrap an unknown target pointer to armv7m (target_to_armv7m(target)). But that's another construction site. - invent virtual byte addresses (as word address * 3) and do read-modify-write cycles in case a single byte shall be written This make the implementation very complicated and no difference to the outside. I think thats not the right way. I agree - this sounds like a bad hack, but it might be necessary in case other software that is much more difficult to change requires such a behaviour. So if it is only allowing/disallowing unaligned or non-machineword-sized accesses, I think the chip driver should just provide 1 or 2 flags with these meanings that the upper layers check. This is nothing the user needs to change, right? Yes, thats right. One parameter to enable/disable alignment should be fine. I think the data bus width is not necessary here and flash programming use his own parameters. Regards, Mathias ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] question about memory access in target.c
Hello,
this patch add the risc (default) and harvard architecture to the target
structure. Currently
this patch only affect the memory read/write functions.
Regards,
Mathias
From dbfc2e3b9473a9cfb48c3e6e651be7152f32748b Mon Sep 17 00:00:00 2001
From: Mathias K. kes...@freenet.de
Date: Thu, 24 Feb 2011 09:31:37 +0100
Subject: [PATCH] target: add target architecture risc and harvard
This patch separate the target architecture into risc and
harvard (default risc). This will solve the alignmend problem
on memory read/write access. On harvard architecture this
should be done in the target implementation.
---
src/target/target.c | 55 ++-
src/target/target.h |8 +++
2 files changed, 62 insertions(+), 1 deletions(-)
diff --git a/src/target/target.c b/src/target/target.c
index 3a6c6bb..025a50d 100644
--- a/src/target/target.c
+++ b/src/target/target.c
@@ -220,6 +220,12 @@ static const Jim_Nvp nvp_target_endian[] = {
{ .name = NULL, .value = -1 },
};
+static const Jim_Nvp nvp_target_architecture[] = {
+ { .name = risc,.value = TARGET_ARCH_RISC },
+ { .name = harvard, .value = TARGET_ARCH_HARVARD },
+ { .name = NULL, .value = -1 },
+};
+
static const Jim_Nvp nvp_reset_modes[] = {
{ .name = unknown, .value = RESET_UNKNOWN },
{ .name = run, .value = RESET_RUN },
@@ -1356,6 +1362,14 @@ int target_write_buffer(struct target *target, uint32_t
address, uint32_t size,
return ERROR_FAIL;
}
+ /* on harvard architecture we handle all parameters
+* on target implementation
+*/
+ if ( target-architecture == TARGET_ARCH_HARVARD )
+ {
+ return target_write_memory(target, address, 0, size, buffer);
+ }
+
if (((address % 2) == 0) (size == 2))
{
return target_write_memory(target, address, 2, 1, buffer);
@@ -1438,6 +1452,14 @@ int target_read_buffer(struct target *target, uint32_t
address, uint32_t size, u
return ERROR_FAIL;
}
+ /* on harvard architecture we handle all parameters
+* on target implementation
+*/
+ if ( target-architecture == TARGET_ARCH_HARVARD )
+ {
+ return target_read_memory(target, address, 0, size, buffer);
+ }
+
if (((address % 2) == 0) (size == 2))
{
return target_read_memory(target, address, 2, 1, buffer);
@@ -3682,6 +3704,7 @@ enum target_cfg_param {
TCFG_VARIANT,
TCFG_COREID,
TCFG_CHAIN_POSITION,
+ TCFG_ARCH,
};
static Jim_Nvp nvp_config_opts[] = {
@@ -3695,7 +3718,7 @@ static Jim_Nvp nvp_config_opts[] = {
{ .name = -variant, .value = TCFG_VARIANT },
{ .name = -coreid, .value = TCFG_COREID },
{ .name = -chain-position, .value = TCFG_CHAIN_POSITION },
-
+ { .name = -arch ,.value = TCFG_ARCH },
{ .name = NULL, .value = -1 }
};
@@ -3986,6 +4009,28 @@ static int target_configure(Jim_GetOptInfo *goi, struct
target *target)
Jim_SetResultString(goi-interp,
target-tap-dotted_name, -1);
/* loop for more e*/
break;
+
+ case TCFG_ARCH:
+ if (goi-isconfigure) {
+ e = Jim_GetOpt_Nvp(goi,
nvp_target_architecture, n);
+ if (e != JIM_OK) {
+ Jim_GetOpt_NvpUnknown(goi,
nvp_target_architecture, 1);
+ return e;
+ }
+ target-architecture = n-value;
+ } else {
+ if (goi-argc != 0) {
+ goto no_params;
+ }
+ }
+ n = Jim_Nvp_value2name_simple(nvp_target_architecture,
target-architecture);
+ if (n-name == NULL) {
+ target-architecture = TARGET_ARCH_RISC;
+ n =
Jim_Nvp_value2name_simple(nvp_target_architecture, target-architecture);
+ }
+ Jim_SetResultString(goi-interp, n-name, -1);
+ /* loop for more */
+ break;
}
} /* while (goi-argc) */
@@ -4673,6 +4718,9 @@ static int target_create(Jim_GetOptInfo *goi)
/* will be set by -endian */
target-endianness = TARGET_ENDIAN_UNKNOWN;
+ /* can also be set by -arch */
+ target-architecture = TARGET_ARCH_UNKNOWN;
+
/* default to first core, override with -coreid */
target-coreid = 0;
@@ -4729,6 +4777,11 @@ static int target_create(Jim_GetOptInfo *goi)
target-endianness = TARGET_LITTLE_ENDIAN
[Openocd-development] [PATCH] ft2232: fix possible read buffer overflow
Hello,
i have done more tests on this issue and i have create the patch bellow.
Regards,
Mathias
From f2ecac695568717b953c0a323ac683e28108f11f Mon Sep 17 00:00:00 2001
From: Mathias K. kes...@freenet.de
Date: Thu, 24 Feb 2011 12:53:52 +0100
Subject: [PATCH] ft2232: fix possible read buffer overflow
This patch fix a possible read buffer overflow in ft2232_execute_queue.
Also the correct read queue size for libftdi and libftd2xx was added and
and tested.
In function ft2232_write a uninitialized value was initialized because we
don't know if this value was set in the ftdi api call.
---
src/jtag/drivers/ft2232.c | 20 +---
1 files changed, 17 insertions(+), 3 deletions(-)
diff --git a/src/jtag/drivers/ft2232.c b/src/jtag/drivers/ft2232.c
index 9024f8e..a84d069 100644
--- a/src/jtag/drivers/ft2232.c
+++ b/src/jtag/drivers/ft2232.c
@@ -373,6 +373,12 @@ static int require_send;
a comment would have been nice.
*/
+#if BUILD_FT2232_FTD2XX == 1
+#define FT2232_BUFFER_READ_QUEUE_SIZE (64*64)
+#else
+#define FT2232_BUFFER_READ_QUEUE_SIZE (64*4)
+#endif
+
#define FT2232_BUFFER_SIZE 131072
static uint8_t* ft2232_buffer = NULL;
@@ -499,7 +505,7 @@ static int ft2232_write(uint8_t* buf, int size, uint32_t*
bytes_written)
{
#if BUILD_FT2232_FTD2XX == 1
FT_STATUS status;
- DWORD dw_bytes_written;
+ DWORD dw_bytes_written = 0;
if ((status = FT_Write(ftdih, buf, size, dw_bytes_written)) != FT_OK)
{
*bytes_written = dw_bytes_written;
@@ -2081,12 +2087,20 @@ static int ft2232_execute_queue(void)
while (cmd)
{
+ /* fill the write buffer with the desired command */
if (ft2232_execute_command(cmd) != ERROR_OK)
retval = ERROR_JTAG_QUEUE_FAILED;
- /* Start reading input before FT2232 TX buffer fills up */
+ /* Start reading input before FT2232 TX buffer fills up.
+* Sometimes this happens because we don't know the
+* length of the last command before we execute it. So
+* we simple inform the user.
+*/
cmd = cmd-next;
- if (ft2232_expect_read 256)
+
+ if (ft2232_expect_read = FT2232_BUFFER_READ_QUEUE_SIZE )
{
+ if (ft2232_expect_read
(FT2232_BUFFER_READ_QUEUE_SIZE+1) )
+ LOG_WARNING(read buffer size looks to high);
if (ft2232_send_and_recv(first_unsent, cmd) != ERROR_OK)
retval = ERROR_JTAG_QUEUE_FAILED;
first_unsent = cmd;
--
1.7.3.4
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] question about memory access in target.c
Hello, i see two possible solutions. The first is to add a bit option to the target struct that define the supported memory access like 8,16,32 bit (default 8/16/32) and target_write_buffer/target_read_buffer would align in respect to this value. I don't prefer this. The second is to add a target architecture identifier and this choose between risc (default) and harvard. On harvard all paramaters from target_write_buffer/target_read_buffer are unchanged and the target read/write memory functions are directly called. All needfull alignment is done in the target implementation. Any suggestions? Regards, Mathias Am 20.02.2011 19:10, schrieb Øyvind Harboe: Is there any chance to add a configuration option that would disable the alignment functionality for a target? I'd rather define another level of polymorphism where the current behavior is the default, but overridable by the target. This is how we've done things before. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] question about jimtcl and gdb commands
This works, i need the global command context to access this variable from c:
/* from openocd.c */
extern struct command_context *global_cmd_ctx;
/* get the interpreter */
Jim_Interp *interp = global_cmd_ctx-interp;
Jim_Obj * memspace = Jim_GetGlobalVariableStr(interp,memspace, JIM_NONE);
if ( memspace)
{
printf(memspace: %s\n,Jim_GetString(memspace,NULL));
}
else
{
printf(memspace not found\n);
}
Am 18.02.2011 08:58, schrieb Øyvind Harboe:
Now i need to access this variable from c.
Use a Tcl C function to read the contents of the variable?
Jim_GetVariable - see jimtcl/jim.c
I guess I don't know enough about the context to reply sensibly.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] dsp563xx: minor fixes, code cleanup
Hello,
okay. I have rebased the master branch and the commit comments are adapted.
Regards,
Mathias
Am 17.02.2011 08:27, schrieb Øyvind Harboe:
Hi,
I failed to apply patch 0001.
Could you rebase to the master branch?
Thanks!
git tips:
git fetch origin
git rebase origin/master
= resolve any conflicts
git format-patch HEAD~2
about commit comments. You can edit commit coments in an interactive
rebase:
git rebase -i HEAD~3
will bring up a list of commits and if you chose edit for a commit, you
can modify the changes for that commit or simply change the commit
comment:
git commit --amend
The format of a commit comment is(by convention):
topic: short descript
blank line
longer description
From 9132f87664eeb9021d05e9e99d20ac530c7681ae Mon Sep 17 00:00:00 2001
From: Mathias K. kes...@freenet.de
Date: Thu, 17 Feb 2011 09:05:42 +0100
Subject: [PATCH 1/2] dsp563xx_once: Correct wrong return value on jtag
communication errors
This patch change the return value on a jtag communication error
to TARGET_UNKNOWN because this function should return the current
target status and not a error code from the underlying api call.
Also the validity of the jtag_status is extended to all static
bits in this value.
---
src/target/dsp563xx_once.c | 14 +++---
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/src/target/dsp563xx_once.c b/src/target/dsp563xx_once.c
index d19323e..d95dcdf 100644
--- a/src/target/dsp563xx_once.c
+++ b/src/target/dsp563xx_once.c
@@ -29,6 +29,9 @@
#include dsp563xx.h
#include dsp563xx_once.h
+#define JTAG_STATUS_STATIC_MASK0x03
+#define JTAG_STATUS_STATIC_VALUE 0x01
+
#define JTAG_STATUS_NORMAL 0x01
#define JTAG_STATUS_STOPWAIT 0x05
#define JTAG_STATUS_BUSY 0x09
@@ -100,19 +103,16 @@ int dsp563xx_once_target_status(struct jtag_tap *tap)
uint8_t jtag_status;
if ((err = dsp563xx_jtag_sendinstr(tap, jtag_status,
JTAG_INSTR_ENABLE_ONCE)) != ERROR_OK)
- return err;
+ return TARGET_UNKNOWN;
if ((err = jtag_execute_queue()) != ERROR_OK)
- return err;
+ return TARGET_UNKNOWN;
- if ((jtag_status 1) != 1)
- {
+ /* verify correct static status pattern */
+ if ( (jtag_status JTAG_STATUS_STATIC_MASK) !=
JTAG_STATUS_STATIC_VALUE )
return TARGET_UNKNOWN;
- }
if (jtag_status != JTAG_STATUS_DEBUG)
- {
return TARGET_RUNNING;
- }
return TARGET_HALTED;
}
--
1.7.3.4
From 8490711ce21a7a87a32a5280ff1b906944e4 Mon Sep 17 00:00:00 2001
From: Mathias K. kes...@freenet.de
Date: Thu, 17 Feb 2011 09:11:25 +0100
Subject: [PATCH 2/2] dsp563xx: minor fixes, code cleanup
This patch move the dsp563xx_target_create function to the
related code block. Also the target examine function was added
and the register cache is initialized in a separate function. The
missing functionality to invalidate the x memory context on memory
writes was also added.
---
src/target/dsp563xx.c | 162 +
1 files changed, 110 insertions(+), 52 deletions(-)
diff --git a/src/target/dsp563xx.c b/src/target/dsp563xx.c
index 5e30739..8e1d6f7 100644
--- a/src/target/dsp563xx.c
+++ b/src/target/dsp563xx.c
@@ -328,21 +328,6 @@ static int dsp563xx_write_core_reg(struct target *target,
int num)
return ERROR_OK;
}
-static int dsp563xx_target_create(struct target *target, Jim_Interp * interp)
-{
- struct dsp563xx_common *dsp563xx = calloc(1, sizeof(struct
dsp563xx_common));
-
- if (!dsp563xx)
- return ERROR_INVALID_ARGUMENTS;
-
- dsp563xx-jtag_info.tap = target-tap;
- target-arch_info = dsp563xx;
- dsp563xx-read_core_reg = dsp563xx_read_core_reg;
- dsp563xx-write_core_reg = dsp563xx_write_core_reg;
-
- return ERROR_OK;
-}
-
static int dsp563xx_get_core_reg(struct reg *reg)
{
struct dsp563xx_core_reg *dsp563xx_reg = reg-arch_info;
@@ -379,6 +364,48 @@ static int dsp563xx_set_core_reg(struct reg *reg, uint8_t
* buf)
return ERROR_OK;
}
+static const struct reg_arch_type dsp563xx_reg_type = {
+ .get = dsp563xx_get_core_reg,
+ .set = dsp563xx_set_core_reg,
+};
+
+static void dsp563xx_build_reg_cache(struct target *target)
+{
+ struct dsp563xx_common *dsp563xx = target_to_dsp563xx(target);
+
+ struct reg_cache **cache_p =
register_get_last_cache_p(target-reg_cache);
+ struct reg_cache *cache = malloc(sizeof(struct reg_cache));
+ struct reg *reg_list = malloc(sizeof(struct reg) *
DSP563XX_NUMCOREREGS);
+ struct dsp563xx_core_reg *arch_info = malloc(sizeof(struct
dsp563xx_core_reg) * DSP563XX_NUMCOREREGS);
+ int i;
+
+ /* Build the process context cache */
+ cache-name = dsp563xx registers;
+ cache-next = NULL;
+ cache-reg_list = reg_list
[Openocd-development] question about jimtcl and gdb commands
Hello, i try to work with a propritary software and a openocd gdb connection to my dsp563xx target. This software sends a very important command qset memspace 3. This command switch between the different target memory types (p,x,y,l) before a data upload/download. I have tracked down the gdb parser to command.c::command_run_line, this function is called because the q as prefix. In this funtions there is something done with jimtcl Now my question, is it possible to write a tcl function that is able to wrap this gdb command to a known target command? Thanks, Mathias ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] fyi: make failed with -j2
Hello, Am 17.02.2011 13:17, schrieb Edgar Grimberg: What does make --version GNU Make 3.81 Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. This program built for i686-pc-linux-gnu tell you about the version of make? What platform are you compiling on and what platform are you compiling for ? Host and target is the same: X86. I think there are some missing dependencies. My command line is: make -j2 clean all The error is: ar: jim-subcmd.o: No such file or directory But this commands seems to work: make clean make -j2 all Regards, Mathias ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] question about jimtcl and gdb commands
Looks like the tcl function is not called:
Debug: 355 26143 gdb_server.c:2183 gdb_input_inner(): received packet:
'qRcmd,736574206d656d73706163652030'
parameter for command_run_line() - qset memspace 0
User : 356 26147 command.c:707 command_run_line(): 0
Debug: 357 26147 gdb_server.c:388 gdb_put_packet_inner(): sending packet
'$O30#b2'
Am 17.02.2011 19:48, schrieb Øyvind Harboe:
Not quite sure what you're asking
Add qset to your config?
# handle qset...
proc qset {a b} {
# Do stuff here...
}
# Invoke tcl 'qset' proc
monitor qset foo bar
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] question about jimtcl and gdb commands
Am 18.02.2011 08:19, schrieb Øyvind Harboe: On Fri, Feb 18, 2011 at 8:12 AM, Mathias K. kes...@freenet.de wrote: Okay, i have found the issue. If i use the monitor command from gdb i receive the string qqset memspace 0, with an extra q in the prefix. This will call the tcl function qset, the first q is removed. But the software sends only qset memspace 0, the tcl command is then set memspace 0 and the command set is called. Where does the extra 'q' come from? This comes from gdb and is the command general query. Is there any way to access the value memspace from c ? Yes, implement the tcl command in C. I think the set command is a general tcl command and i can't overwrite it!? On a telnet connection i can print the memspace variable with: echo $memspace 3 Now i need to access this variable from c. Regards, Mathias ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] dsp563xx: minor fixes, code cleanup
Changes:
[PATCH 1/2]
- move dsp563xx_target_create and dsp563xx_target_create function
- separate register cache initialization to dsp563xx_build_reg_cache function
- add dsp563xx_examine function and print out correct dsp variant
[PATCH 2/2]
- fix wrong target status return value on jtag communication errors
- check the static pattern in jtag status to verify that the value is almost
correct, this check
fail if no target is present
Regards,
Mathias
From 10c511d919ad5e9ea1c5c82ba4e845fd6357d945 Mon Sep 17 00:00:00 2001
From: Mathias K. kes...@freenet.de
Date: Wed, 16 Feb 2011 15:00:06 +0100
Subject: [PATCH 1/2] - move dsp563xx_target_create and dsp563xx_target_create
function
- separate register cache initialization to dsp563xx_build_reg_cache function
- add dsp563xx_examine function and print out correct dsp variant
---
src/target/dsp563xx.c | 132 ++--
1 files changed, 82 insertions(+), 50 deletions(-)
diff --git a/src/target/dsp563xx.c b/src/target/dsp563xx.c
index 603ccd8..04ac7d4 100644
--- a/src/target/dsp563xx.c
+++ b/src/target/dsp563xx.c
@@ -328,21 +328,6 @@ static int dsp563xx_write_core_reg(struct target *target,
int num)
return ERROR_OK;
}
-static int dsp563xx_target_create(struct target *target, Jim_Interp * interp)
-{
- struct dsp563xx_common *dsp563xx = calloc(1, sizeof(struct
dsp563xx_common));
-
- if (!dsp563xx)
- return ERROR_INVALID_ARGUMENTS;
-
- dsp563xx-jtag_info.tap = target-tap;
- target-arch_info = dsp563xx;
- dsp563xx-read_core_reg = dsp563xx_read_core_reg;
- dsp563xx-write_core_reg = dsp563xx_write_core_reg;
-
- return ERROR_OK;
-}
-
static int dsp563xx_get_core_reg(struct reg *reg)
{
struct dsp563xx_core_reg *dsp563xx_reg = reg-arch_info;
@@ -379,6 +364,48 @@ static int dsp563xx_set_core_reg(struct reg *reg, uint8_t
* buf)
return ERROR_OK;
}
+static const struct reg_arch_type dsp563xx_reg_type = {
+ .get = dsp563xx_get_core_reg,
+ .set = dsp563xx_set_core_reg,
+};
+
+static void dsp563xx_build_reg_cache(struct target *target)
+{
+ struct dsp563xx_common *dsp563xx = target_to_dsp563xx(target);
+
+ struct reg_cache **cache_p =
register_get_last_cache_p(target-reg_cache);
+ struct reg_cache *cache = malloc(sizeof(struct reg_cache));
+ struct reg *reg_list = malloc(sizeof(struct reg) *
DSP563XX_NUMCOREREGS);
+ struct dsp563xx_core_reg *arch_info = malloc(sizeof(struct
dsp563xx_core_reg) * DSP563XX_NUMCOREREGS);
+ int i;
+
+ /* Build the process context cache */
+ cache-name = dsp563xx registers;
+ cache-next = NULL;
+ cache-reg_list = reg_list;
+ cache-num_regs = DSP563XX_NUMCOREREGS;
+ (*cache_p) = cache;
+ dsp563xx-core_cache = cache;
+
+ for (i = 0; i DSP563XX_NUMCOREREGS; i++)
+ {
+ arch_info[i].num = dsp563xx_regs[i].id;
+ arch_info[i].name = dsp563xx_regs[i].name;
+ arch_info[i].size = dsp563xx_regs[i].bits;
+ arch_info[i].eame = dsp563xx_regs[i].eame;
+ arch_info[i].instr_mask = dsp563xx_regs[i].instr_mask;
+ arch_info[i].target = target;
+ arch_info[i].dsp563xx_common = dsp563xx;
+ reg_list[i].name = dsp563xx_regs[i].name;
+ reg_list[i].size = dsp563xx_regs[i].bits;
+ reg_list[i].value = calloc(1, 4);
+ reg_list[i].dirty = 0;
+ reg_list[i].valid = 0;
+ reg_list[i].type = dsp563xx_reg_type;
+ reg_list[i].arch_info = arch_info[i];
+ }
+}
+
static int dsp563xx_read_register(struct target *target, int num, int force);
static int dsp563xx_write_register(struct target *target, int num, int force);
@@ -771,48 +798,52 @@ static void dsp563xx_invalidate_x_context(struct target
*target, uint32_t addr_s
}
}
-static const struct reg_arch_type dsp563xx_reg_type = {
- .get = dsp563xx_get_core_reg,
- .set = dsp563xx_set_core_reg,
-};
+static int dsp563xx_target_create(struct target *target, Jim_Interp * interp)
+{
+ struct dsp563xx_common *dsp563xx = calloc(1, sizeof(struct
dsp563xx_common));
+
+ if (!dsp563xx)
+ return ERROR_INVALID_ARGUMENTS;
+
+ dsp563xx-jtag_info.tap = target-tap;
+ target-arch_info = dsp563xx;
+ dsp563xx-read_core_reg = dsp563xx_read_core_reg;
+ dsp563xx-write_core_reg = dsp563xx_write_core_reg;
+
+ return ERROR_OK;
+}
static int dsp563xx_init_target(struct command_context *cmd_ctx, struct target
*target)
{
- /* get pointers to arch-specific information */
- struct dsp563xx_common *dsp563xx = target_to_dsp563xx(target);
+ LOG_DEBUG(%s, __FUNCTION__);
- struct reg_cache **cache_p =
register_get_last_cache_p(target-reg_cache);
- struct reg_cache *cache = malloc(sizeof(struct reg_cache
[Openocd-development] fyi: make failed with -j2
Hello, i would inform you that make failed on my site with the make switch-jX and X greater than 1. Regards, Mathias ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Correct definition of JTAG_INSTR_CLAMP in dsp563xx_once.c
Yes. Am 14.02.2011 15:35, schrieb Øyvind Harboe: Should this patch be merged? ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] dsp563xx mem rw changes
Hello,
changes:
PATCH 1
- execute jtag queue at the end of the memory transfer
- add bulk memory write function
PATCH 2
- add parameter flush to the once api to signalize if the jtag queue need to be
flushed after the
command
Regards,
Mathias
Am 14.02.2011 15:35, schrieb Øyvind Harboe:
Should this fix be merged?
Any objections?
Could you write a patch with a better commit comment?
Thanks!
From 684ffa06a3e18495d6653d6e89f2a058636bbd89 Mon Sep 17 00:00:00 2001
From: Mathias K. kes...@freenet.de
Date: Tue, 15 Feb 2011 16:59:23 +0100
Subject: [PATCH 1/2] - add bulk memory write function
- execute jtag queue at the end of the memory transfer
---
src/target/dsp563xx.c | 58 +++-
1 files changed, 47 insertions(+), 11 deletions(-)
diff --git a/src/target/dsp563xx.c b/src/target/dsp563xx.c
index 4371d0a..10365df 100644
--- a/src/target/dsp563xx.c
+++ b/src/target/dsp563xx.c
@@ -29,8 +29,6 @@
#include dsp563xx.h
#include dsp563xx_once.h
-//#define DSP563XX_JTAG_INS_LEN 4
-
#define ASM_REG_W_R0 0x60F400
#define ASM_REG_W_R1 0x61F400
#define ASM_REG_W_R2 0x62F400
@@ -1138,9 +1136,16 @@ static int dsp563xx_read_memory(struct target *target,
int mem_type, uint32_t ad
return ERROR_TARGET_NOT_HALTED;
}
+ /* we only support 4 byte aligned data */
+ if ( size != 4 )
+ {
+ return ERROR_INVALID_ARGUMENTS;
+ }
+
switch (mem_type)
{
case MEM_X:
+ /* TODO: mark effected queued registers */
move_cmd = 0x61d800;
break;
case MEM_Y:
@@ -1173,17 +1178,30 @@ static int dsp563xx_read_memory(struct target *target,
int mem_type, uint32_t ad
for (i = 0; i x; i++)
{
- data = 0;
if ((err = dsp563xx_once_execute_sw_ir_nq(target-tap,
move_cmd)) != ERROR_OK)
return err;
- if ((err = dsp563xx_once_execute_sw_ir(target-tap, 0x08D13C))
!= ERROR_OK)
+ if ((err = dsp563xx_once_execute_sw_ir_nq(target-tap,
0x08D13C)) != ERROR_OK)
return err;
- if ((err = dsp563xx_once_reg_read(target-tap,
DSP563XX_ONCE_OGDBR, data)) != ERROR_OK)
+ if ((err = dsp563xx_once_reg_read_nq(target-tap,
DSP563XX_ONCE_OGDBR, (uint32_t*)b)) != ERROR_OK)
return err;
- target_buffer_set_u32(target, b, data);
b += 4;
+ }
- LOG_DEBUG(R: %08X, data);
+ /* flush the jtag queue */
+ if ((err = jtag_execute_queue()) != ERROR_OK)
+ {
+ return err;
+ }
+
+ /* walk over the buffer and fix target endianness */
+ b = buffer;
+
+ for (i = 0; i x; i++)
+ {
+ data = *((uint32_t*)b) 0x00FF;
+// LOG_DEBUG(R: %08X, *((uint32_t*)b));
+ target_buffer_set_u32(target, b, data);
+ b += 4;
}
return ERROR_OK;
@@ -1210,6 +1228,12 @@ static int dsp563xx_write_memory(struct target *target,
int mem_type, uint32_t a
return ERROR_TARGET_NOT_HALTED;
}
+ /* we only support 4 byte aligned data */
+ if ( size != 4 )
+ {
+ return ERROR_INVALID_ARGUMENTS;
+ }
+
switch (mem_type)
{
case MEM_X:
@@ -1246,18 +1270,24 @@ static int dsp563xx_write_memory(struct target *target,
int mem_type, uint32_t a
for (i = 0; i x; i++)
{
data = target_buffer_get_u32(target, b);
- data = 0x00ff;
- LOG_DEBUG(W: %08X, data);
+// LOG_DEBUG(W: %08X, data);
+
+ data = 0x00ff;
if ((err = dsp563xx_once_execute_dw_ir_nq(target-tap,
0x61F400, data)) != ERROR_OK)
return err;
- if ((err = dsp563xx_once_execute_sw_ir(target-tap, move_cmd))
!= ERROR_OK)
+ if ((err = dsp563xx_once_execute_sw_ir_nq(target-tap,
move_cmd)) != ERROR_OK)
return err;
-
b += 4;
}
+ /* flush the jtag queue */
+ if ((err = jtag_execute_queue()) != ERROR_OK)
+ {
+ return err;
+ }
+
return ERROR_OK;
}
@@ -1266,6 +1296,11 @@ static int dsp563xx_write_memory_p(struct target
*target, uint32_t address, uint
return dsp563xx_write_memory(target, MEM_P, address, size, count,
buffer);
}
+static int dsp563xx_bulk_write_memory_p(struct target *target, uint32_t
address, uint32_t count, uint8_t *buffer)
+{
+ return dsp563xx_write_memory(target, MEM_P, address, 4, count, buffer);
+}
+
static void handle_md_output(struct command_context *cmd_ctx, struct target
*target, uint32_t address, unsigned size, unsigned count, const uint8_t *
buffer)
{
const
[Openocd-development] [PATCH] dsp563xx: fix resume and step function ...
Changes:
- remove pipeline context, use once register instead
- fix wrong register write in resume and step function
- add more conditional branch handling
Regards,
Mathias
From 996a0c10623ed05e5bb3187b9f2134e51d279887 Mon Sep 17 00:00:00 2001
From: Mathias K. kes...@freenet.de
Date: Tue, 15 Feb 2011 20:17:10 +0100
Subject: [PATCH 4/4] - remove pipeline context, use once register instead
- fix wrong register write in resume and step function
- add more conditional branch handling
---
src/target/dsp563xx.c | 143 -
src/target/dsp563xx.h | 10
2 files changed, 82 insertions(+), 71 deletions(-)
diff --git a/src/target/dsp563xx.c b/src/target/dsp563xx.c
index f6f9c4f..603ccd8 100644
--- a/src/target/dsp563xx.c
+++ b/src/target/dsp563xx.c
@@ -92,32 +92,60 @@
#define ASM_REG_W_AAR2 0xF7
#define ASM_REG_W_AAR3 0xF6
+enum once_reg_idx {
+ ONCE_REG_IDX_OSCR=0,
+ ONCE_REG_IDX_OMBC=1,
+ ONCE_REG_IDX_OBCR=2,
+ ONCE_REG_IDX_OMLR0=3,
+ ONCE_REG_IDX_OMLR1=4,
+ ONCE_REG_IDX_OGDBR=5,
+ ONCE_REG_IDX_OPDBR=6,
+ ONCE_REG_IDX_OPILR=7,
+ ONCE_REG_IDX_PDB=8,
+ ONCE_REG_IDX_OTC=9,
+ ONCE_REG_IDX_OPABFR=10,
+ ONCE_REG_IDX_OPABDR=11,
+ ONCE_REG_IDX_OPABEX=12,
+ ONCE_REG_IDX_OPABF0=13,
+ ONCE_REG_IDX_OPABF1=14,
+ ONCE_REG_IDX_OPABF2=15,
+ ONCE_REG_IDX_OPABF3=16,
+ ONCE_REG_IDX_OPABF4=17,
+ ONCE_REG_IDX_OPABF5=18,
+ ONCE_REG_IDX_OPABF6=19,
+ ONCE_REG_IDX_OPABF7=20,
+ ONCE_REG_IDX_OPABF8=21,
+ ONCE_REG_IDX_OPABF9=22,
+ ONCE_REG_IDX_OPABF10=23,
+ ONCE_REG_IDX_OPABF11=24,
+};
+
static struct once_reg once_regs[] = {
- {0, 0x00, 24, OSCR, 0},
- {1, 0x01, 24, OMBC, 0},
- {2, 0x02, 24, OBCR, 0},
- {3, 0x05, 24, OMLR0, 0},
- {4, 0x06, 24, OMLR1, 0},
- {5, 0x09, 24, OGDBR, 0},
- {6, 0x0a, 24, OPDBR, 0},
- {7, 0x0b, 24, OPILR, 0},
- {8, 0x0c, 24, PDB, 0},
- {9, 0x0d, 24, OTC, 0},
- {10, 0x0f, 24, OPABFR, 0},
- {11, 0x10, 24, OPABDR, 0},
- {12, 0x11, 24, OPABEX, 0},
- {13, 0x12, 25, OPABF0, 0},
- {14, 0x12, 25, OPABF1, 0},
- {15, 0x12, 25, OPABF2, 0},
- {16, 0x12, 25, OPABF3, 0},
- {17, 0x12, 25, OPABF4, 0},
- {18, 0x12, 25, OPABF5, 0},
- {19, 0x12, 25, OPABF6, 0},
- {20, 0x12, 25, OPABF7, 0},
- {21, 0x12, 25, OPABF8, 0},
- {22, 0x12, 25, OPABF9, 0},
- {23, 0x12, 25, OPABF10, 0},
- {24, 0x12, 25, OPABF11, 0},
+ {ONCE_REG_IDX_OSCR,DSP563XX_ONCE_OSCR,24, OSCR,0},
+ {ONCE_REG_IDX_OMBC,DSP563XX_ONCE_OMBC,24, OMBC,0},
+ {ONCE_REG_IDX_OBCR,DSP563XX_ONCE_OBCR,24, OBCR,0},
+ {ONCE_REG_IDX_OMLR0, DSP563XX_ONCE_OMLR0, 24, OMLR0, 0},
+ {ONCE_REG_IDX_OMLR1, DSP563XX_ONCE_OMLR1, 24, OMLR1, 0},
+ {ONCE_REG_IDX_OGDBR, DSP563XX_ONCE_OGDBR, 24, OGDBR, 0},
+ {ONCE_REG_IDX_OPDBR, DSP563XX_ONCE_OPDBR, 24, OPDBR, 0},
+ {ONCE_REG_IDX_OPILR, DSP563XX_ONCE_OPILR, 24, OPILR, 0},
+ {ONCE_REG_IDX_PDB, DSP563XX_ONCE_PDBGOTO, 24, PDB, 0},
+ {ONCE_REG_IDX_OTC, DSP563XX_ONCE_OTC, 24, OTC, 0},
+ {ONCE_REG_IDX_OPABFR, DSP563XX_ONCE_OPABFR, 24, OPABFR, 0},
+ {ONCE_REG_IDX_OPABDR, DSP563XX_ONCE_OPABDR, 24, OPABDR, 0},
+ {ONCE_REG_IDX_OPABEX, DSP563XX_ONCE_OPABEX, 24, OPABEX, 0},
+ {ONCE_REG_IDX_OPABF0, DSP563XX_ONCE_OPABF11, 25, OPABF0, 0},
+ {ONCE_REG_IDX_OPABF1, DSP563XX_ONCE_OPABF11, 25, OPABF1, 0},
+ {ONCE_REG_IDX_OPABF2, DSP563XX_ONCE_OPABF11, 25, OPABF2, 0},
+ {ONCE_REG_IDX_OPABF3, DSP563XX_ONCE_OPABF11, 25, OPABF3, 0},
+ {ONCE_REG_IDX_OPABF4, DSP563XX_ONCE_OPABF11, 25, OPABF4, 0},
+ {ONCE_REG_IDX_OPABF5, DSP563XX_ONCE_OPABF11, 25, OPABF5, 0},
+ {ONCE_REG_IDX_OPABF6, DSP563XX_ONCE_OPABF11, 25, OPABF6, 0},
+ {ONCE_REG_IDX_OPABF7, DSP563XX_ONCE_OPABF11, 25, OPABF7, 0},
+ {ONCE_REG_IDX_OPABF8, DSP563XX_ONCE_OPABF11, 25, OPABF8, 0},
+ {ONCE_REG_IDX_OPABF9, DSP563XX_ONCE_OPABF11, 25, OPABF9, 0},
+ {ONCE_REG_IDX_OPABF10, DSP563XX_ONCE_OPABF11, 25, OPABF10, 0},
+ {ONCE_REG_IDX_OPABF11, DSP563XX_ONCE_OPABF11, 25, OPABF11, 0},
// {25,0x1f,24,NRSEL,0},
};
@@ -432,35 +460,41 @@ static int dsp563xx_reg_write(struct target *target,
uint32_t instr_mask, uint32
static int dsp563xx_reg_pc_read(struct target *target)
{
- int err;
- uint32_t opabdr, opabex;
struct dsp563xx_common *dsp563xx = target_to_dsp563xx(target);
/* pc was changed, nothing todo */
if (dsp563xx-core_cache-reg_list[REG_NUM_PC].dirty)
return ERROR_OK;
- if ((err = dsp563xx_once_reg_read(target-tap, 1, DSP563XX_ONCE_OPABDR,
opabdr)) != ERROR_OK)
- return err;
- if ((err = dsp563xx_once_reg_read
Re: [Openocd-development] [PATCH] ft2232.c add functions to set high/low byte
Hello,
the mpsse buffer preparation and send functionality is done in:
ft2232_set_data_bits_low_byte
ft2232_set_data_bits_high_byte
You only need to deliver the port value and direction to this functions. Thats
all.
Regards,
Mathias
Am 14.02.2011 10:36, schrieb Laurent Gauch:
Why removing a lot of code ?
As :
static int jtagkey_init(void)
{
-uint8_t buf[3];
-uint32_t bytes_written;
-
low_output= 0x08;
low_direction = 0x1b;
/* initialize low byte for jtag */
-buf[0] = 0x80; /* command set data bits low byte */
-buf[1] = low_output;/* value (TMS = 1,TCK = 0, TDI = 0, nOE = 0) */
-buf[2] = low_direction; /* dir (output = 1), TCK/TDI/TMS = out, TDO =
in, nOE = out */
-LOG_DEBUG(%2.2x %2.2x %2.2x, buf[0], buf[1], buf[2]);
-
-if (ft2232_write(buf, sizeof(buf), bytes_written) != ERROR_OK)
+if (ft2232_set_data_bits_low_byte(low_output,low_direction) != ERROR_OK)
{
LOG_ERROR(couldn't initialize FT2232 with 'JTAGkey' layout);
return ERROR_JTAG_INIT_FAILED;
Please explain?
Regards,
Laurent
http://www.amontec.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] dsp563xx mem rw changes
No, i need to change this. Anyway the overflow of the command read buffer size in ft2232 should be fixed (patched) first. I think in some circumstances this can happen again (i have not seen this yet) and this function need some more work to avoid this case in the future. Am 14.02.2011 15:35, schrieb Øyvind Harboe: Should this fix be merged? Any objections? Could you write a patch with a better commit comment? Thanks! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] dsp568013 - switching/disabling taps
Hello,
you can try configure with --enable-verbose-jtag-io. All the jtag
input/output is done in interface.c.
Regards,
Mathias
Am 15.02.2011 02:28, schrieb Rodrigo Rosa:
Hi,
We've been trying to communicate via JTAG (through a signalyzer H2)
with a freescale 568013.
Modifying the code for the dsp56321 we were able to communicate with
our chip. It has two taps, a MASTER tap and a CORE tap.
The default tap is the MASTER tap, and by default the CORE tap is
disabled. There is a command to switch from the MASTER tap to the CORE
tap and vice versa. Since it is a switch, only ONE tap is connected at
a time.
We need to make openocd know that the command that switches from
MASTER to CORE disables MASTER (and the command to switch from CORE to
MASTER disables CORE).
The config file (see below) shows the hack we are currently using
(empty disable functions).
#-
#-
# Script for freescale DSP568013
#
source [find interface/signalyzer-h2.cfg]
if { [info exists CHIPNAME] } {
set _CHIPNAME $CHIPNAME
} else {
set _CHIPNAME dsp568013
}
if { [info exists ENDIAN] } {
set _ENDIAN $ENDIAN
} else {
# this defaults to a big endian
set _ENDIAN big
}
if { [info exists CPUTAPID ] } {
set _CPUTAPID $CPUTAPID
} else {
# force an error till we get a good number
set _CPUTAPID 0x01f2801d
}
#jtag speed
adapter_khz 10
#has only trst
reset_config trst_only
#MASTER tap
jtag newtap $_CHIPNAME chp -irlen 8 -ircapture 1 -irmask 0x03
-expected-id $_CPUTAPID
#CORE tap
jtag newtap $_CHIPNAME cpu -irlen 4 -ircapture 1 -irmask 0x03 -disable
-expected-id 0x02211004
#target configuration
set _TARGETNAME $_CHIPNAME.cpu
#target create $_TARGETNAME dsp5680xx -endian $_ENDIAN -chain-position
$_TARGETNAME
#select CORE tap by modifying the TLM register.
#to be used when MASTER tap is selected.
jtag configure $_TARGETNAME -event tap-enable
irscan $_CHIPNAME.chp 0x05;
drscan $_CHIPNAME.chp 4 0x02;
jtag tapdisable $_CHIPNAME.chp;
#select MASTER tap by modifying the TLM register.
#to be used when CORE tap is selected.
jtag configure $_CHIPNAME.chp -event tap-enable
irscan $_TARGETNAME 0x4;
drscan $_TARGETNAME 4 0x1;
jtag tapdisable $_TARGETNAME;
jtag configure $_TARGETNAME -event tap-disable {
}
jtag configure $_CHIPNAME.chp -event tap-disable {
}
#working area at base of ram
#$_TARGETNAME configure -work-area-virt 0
#-
#-
The tap seems to switch. After switching we can get what we believe is
the CORE tap's IDCODE by executing:
scan_chain
TapName Enabled IdCode Expected IrLen IrCap IrMask
-- --- -- -- - - --
0 dsp568013.chp Y 0x01f2801d 0x01f2801d 8 0x01 0x03
1 dsp568013.cpu n 0x 0x02211004 4 0x01 0x03
jtag tapenable dsp568013.cpu
JTAG tap: dsp568013.chp disabled
JTAG tap: dsp568013.cpu enabled
1
scan_chain
TapName Enabled IdCode Expected IrLen IrCap IrMask
-- --- -- -- - - --
0 dsp568013.chp n 0x01f2801d 0x01f2801d 8 0x01 0x03
1 dsp568013.cpu Y 0x 0x02211004 4 0x01 0x03
irscan dsp568013.cpu 0x2
drscan dsp568013.cpu 32 0
02211004
Switching back to the MASTER tap does not seem to work correctly.
After switching to the CORE tap and back to the MASTER tap we cannot
execute IDCODE successfully.
We get the following on telnet:
jtag tapenable dsp568013.chp
JTAG tap: dsp568013.cpu disabled
JTAG tap: dsp568013.chp enabled
1
irscan dsp568013.chp 0x02
drscan dsp568013.chp 32 0
drscan dsp568013.chp 32 0
drscan dsp568013.chp 32 2
0004
looks like the tap is working in BYPASS. if we run pathmove RESET
everything works fine again:
pathmove RESET
irscan dsp568013.chp 0x02
drscan dsp568013.chp 32 0
01F2801D
What is the correct way to do the switching?
Also, is there any way to get irscan to show what was shifted in?
Thanks!
--
Rodrigo.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] ft2232.c add functions to set high/low byte
Hello,
this patch add 2 functions to set data bits high/low byte.
Regards,
Mathias
From b1cdc2056c85b9798d4f2ffe6a5b2f3f2f8fef05 Mon Sep 17 00:00:00 2001
From: Mathias K. kes...@freenet.de
Date: Sun, 13 Feb 2011 13:21:42 +0100
Subject: [PATCH] - add functions for ft2232 set data bits high/low byte command
---
src/jtag/drivers/ft2232.c | 373 +++--
1 files changed, 93 insertions(+), 280 deletions(-)
diff --git a/src/jtag/drivers/ft2232.c b/src/jtag/drivers/ft2232.c
index b6a1a3a..59fc21c 100644
--- a/src/jtag/drivers/ft2232.c
+++ b/src/jtag/drivers/ft2232.c
@@ -2373,6 +2373,46 @@ static int ft2232_purge_libftdi(void)
#endif /* BUILD_FT2232_LIBFTDI == 1 */
+static int ft2232_set_data_bits_low_byte( uint8_t value, uint8_t direction )
+{
+ uint8_t buf[3];
+ uint32_t bytes_written;
+
+ buf[0] = 0x80; /* command set data bits low byte */
+ buf[1] = value; /* value */
+ buf[2] = direction; /* direction */
+
+ LOG_DEBUG(%2.2x %2.2x %2.2x, buf[0], buf[1], buf[2]);
+
+ if (ft2232_write(buf, sizeof(buf), bytes_written) != ERROR_OK)
+ {
+ LOG_ERROR(couldn't initialize data bits low byte);
+ return ERROR_JTAG_INIT_FAILED;
+ }
+
+ return ERROR_OK;
+}
+
+static int ft2232_set_data_bits_high_byte( uint8_t value, uint8_t direction )
+{
+ uint8_t buf[3];
+ uint32_t bytes_written;
+
+ buf[0] = 0x82; /* command set data bits high byte */
+ buf[1] = value; /* value */
+ buf[2] = direction; /* direction */
+
+ LOG_DEBUG(%2.2x %2.2x %2.2x, buf[0], buf[1], buf[2]);
+
+ if (ft2232_write(buf, sizeof(buf), bytes_written) != ERROR_OK)
+ {
+ LOG_ERROR(couldn't initialize data bits high byte);
+ return ERROR_JTAG_INIT_FAILED;
+ }
+
+ return ERROR_OK;
+}
+
static int ft2232_init(void)
{
uint8_t buf[1];
@@ -2477,9 +2517,6 @@ static inline void ftx232_dbus_init(void)
*/
static int ftx232_dbus_write(void)
{
- uint8_t buf[3];
- uint32_t bytes_written;
-
enum reset_types jtag_reset_config = jtag_get_reset_config();
if (jtag_reset_config RESET_TRST_OPEN_DRAIN)
{
@@ -2504,12 +2541,7 @@ static int ftx232_dbus_write(void)
}
/* initialize low byte for jtag */
- buf[0] = 0x80; /* command set data bits low byte */
- buf[1] = low_output;/* value (TMS = 1,TCK = 0, TDI = 0, xRST high)
*/
- buf[2] = low_direction; /* dir (output = 1), TCK/TDI/TMS = out, TDO =
in */
- LOG_DEBUG(%2.2x %2.2x %2.2x, buf[0], buf[1], buf[2]);
-
- if (ft2232_write(buf, sizeof(buf), bytes_written) != ERROR_OK)
+ if (ft2232_set_data_bits_low_byte(low_output,low_direction) != ERROR_OK)
{
LOG_ERROR(couldn't initialize FT2232 DBUS);
return ERROR_JTAG_INIT_FAILED;
@@ -2609,19 +2641,11 @@ static int signalyzer_init(void)
static int axm0432_jtag_init(void)
{
- uint8_t buf[3];
- uint32_t bytes_written;
-
low_output= 0x08;
low_direction = 0x2b;
/* initialize low byte for jtag */
- buf[0] = 0x80; /* command set data bits low byte */
- buf[1] = low_output;/* value (TMS = 1,TCK = 0, TDI = 0, nOE = 0) */
- buf[2] = low_direction; /* dir (output = 1), TCK/TDI/TMS = out, TDO =
in, nOE = out */
- LOG_DEBUG(%2.2x %2.2x %2.2x, buf[0], buf[1], buf[2]);
-
- if (ft2232_write(buf, sizeof(buf), bytes_written) != ERROR_OK)
+ if (ft2232_set_data_bits_low_byte(low_output,low_direction) != ERROR_OK)
{
LOG_ERROR(couldn't initialize FT2232 with 'JTAGkey' layout);
return ERROR_JTAG_INIT_FAILED;
@@ -2662,13 +2686,8 @@ static int axm0432_jtag_init(void)
high_output |= nSRST;
}
- /* initialize high port */
- buf[0] = 0x82; /* command set data bits high byte */
- buf[1] = high_output; /* value */
- buf[2] = high_direction;/* all outputs (xRST and xRSTnOE) */
- LOG_DEBUG(%2.2x %2.2x %2.2x, buf[0], buf[1], buf[2]);
-
- if (ft2232_write(buf, sizeof(buf), bytes_written) != ERROR_OK)
+ /* initialize high byte for jtag */
+ if (ft2232_set_data_bits_high_byte(high_output,high_direction) !=
ERROR_OK)
{
LOG_ERROR(couldn't initialize FT2232 with 'Dicarlo' layout);
return ERROR_JTAG_INIT_FAILED;
@@ -2679,22 +2698,11 @@ static int axm0432_jtag_init(void)
static int redbee_init(void)
{
- uint8_t buf[3];
- uint32_t bytes_written;
-
low_output= 0x08;
low_direction = 0x2b;
/* initialize low byte for jtag */
- /* command set data bits low byte */
- buf[0] = 0x80;
- /* value (TMS = 1,TCK = 0, TDI = 0, nOE = 0) */
- buf[2] = low_direction;
- /* dir (output
[Openocd-development] [PATCH] ft2232.c add functions to set high/low byte
Changes:
- separate all set data bits high/low byte command releated code into 2
functions for better readability
- change wrong log messages to correct the output
- change some of the blink led functions that can use a simple xor instead of
the if statement
Regards,
Mathias
From b1cdc2056c85b9798d4f2ffe6a5b2f3f2f8fef05 Mon Sep 17 00:00:00 2001
From: Mathias K. kes...@freenet.de
Date: Sun, 13 Feb 2011 13:21:42 +0100
Subject: [PATCH] - add functions for ft2232 set data bits high/low byte command
---
src/jtag/drivers/ft2232.c | 373 +++--
1 files changed, 93 insertions(+), 280 deletions(-)
diff --git a/src/jtag/drivers/ft2232.c b/src/jtag/drivers/ft2232.c
index b6a1a3a..59fc21c 100644
--- a/src/jtag/drivers/ft2232.c
+++ b/src/jtag/drivers/ft2232.c
@@ -2373,6 +2373,46 @@ static int ft2232_purge_libftdi(void)
#endif /* BUILD_FT2232_LIBFTDI == 1 */
+static int ft2232_set_data_bits_low_byte( uint8_t value, uint8_t direction )
+{
+ uint8_t buf[3];
+ uint32_t bytes_written;
+
+ buf[0] = 0x80; /* command set data bits low byte */
+ buf[1] = value; /* value */
+ buf[2] = direction; /* direction */
+
+ LOG_DEBUG(%2.2x %2.2x %2.2x, buf[0], buf[1], buf[2]);
+
+ if (ft2232_write(buf, sizeof(buf), bytes_written) != ERROR_OK)
+ {
+ LOG_ERROR(couldn't initialize data bits low byte);
+ return ERROR_JTAG_INIT_FAILED;
+ }
+
+ return ERROR_OK;
+}
+
+static int ft2232_set_data_bits_high_byte( uint8_t value, uint8_t direction )
+{
+ uint8_t buf[3];
+ uint32_t bytes_written;
+
+ buf[0] = 0x82; /* command set data bits high byte */
+ buf[1] = value; /* value */
+ buf[2] = direction; /* direction */
+
+ LOG_DEBUG(%2.2x %2.2x %2.2x, buf[0], buf[1], buf[2]);
+
+ if (ft2232_write(buf, sizeof(buf), bytes_written) != ERROR_OK)
+ {
+ LOG_ERROR(couldn't initialize data bits high byte);
+ return ERROR_JTAG_INIT_FAILED;
+ }
+
+ return ERROR_OK;
+}
+
static int ft2232_init(void)
{
uint8_t buf[1];
@@ -2477,9 +2517,6 @@ static inline void ftx232_dbus_init(void)
*/
static int ftx232_dbus_write(void)
{
- uint8_t buf[3];
- uint32_t bytes_written;
-
enum reset_types jtag_reset_config = jtag_get_reset_config();
if (jtag_reset_config RESET_TRST_OPEN_DRAIN)
{
@@ -2504,12 +2541,7 @@ static int ftx232_dbus_write(void)
}
/* initialize low byte for jtag */
- buf[0] = 0x80; /* command set data bits low byte */
- buf[1] = low_output;/* value (TMS = 1,TCK = 0, TDI = 0, xRST high)
*/
- buf[2] = low_direction; /* dir (output = 1), TCK/TDI/TMS = out, TDO =
in */
- LOG_DEBUG(%2.2x %2.2x %2.2x, buf[0], buf[1], buf[2]);
-
- if (ft2232_write(buf, sizeof(buf), bytes_written) != ERROR_OK)
+ if (ft2232_set_data_bits_low_byte(low_output,low_direction) != ERROR_OK)
{
LOG_ERROR(couldn't initialize FT2232 DBUS);
return ERROR_JTAG_INIT_FAILED;
@@ -2609,19 +2641,11 @@ static int signalyzer_init(void)
static int axm0432_jtag_init(void)
{
- uint8_t buf[3];
- uint32_t bytes_written;
-
low_output= 0x08;
low_direction = 0x2b;
/* initialize low byte for jtag */
- buf[0] = 0x80; /* command set data bits low byte */
- buf[1] = low_output;/* value (TMS = 1,TCK = 0, TDI = 0, nOE = 0) */
- buf[2] = low_direction; /* dir (output = 1), TCK/TDI/TMS = out, TDO =
in, nOE = out */
- LOG_DEBUG(%2.2x %2.2x %2.2x, buf[0], buf[1], buf[2]);
-
- if (ft2232_write(buf, sizeof(buf), bytes_written) != ERROR_OK)
+ if (ft2232_set_data_bits_low_byte(low_output,low_direction) != ERROR_OK)
{
LOG_ERROR(couldn't initialize FT2232 with 'JTAGkey' layout);
return ERROR_JTAG_INIT_FAILED;
@@ -2662,13 +2686,8 @@ static int axm0432_jtag_init(void)
high_output |= nSRST;
}
- /* initialize high port */
- buf[0] = 0x82; /* command set data bits high byte */
- buf[1] = high_output; /* value */
- buf[2] = high_direction;/* all outputs (xRST and xRSTnOE) */
- LOG_DEBUG(%2.2x %2.2x %2.2x, buf[0], buf[1], buf[2]);
-
- if (ft2232_write(buf, sizeof(buf), bytes_written) != ERROR_OK)
+ /* initialize high byte for jtag */
+ if (ft2232_set_data_bits_high_byte(high_output,high_direction) !=
ERROR_OK)
{
LOG_ERROR(couldn't initialize FT2232 with 'Dicarlo' layout);
return ERROR_JTAG_INIT_FAILED;
@@ -2679,22 +2698,11 @@ static int axm0432_jtag_init(void)
static int redbee_init(void)
{
- uint8_t buf[3];
- uint32_t bytes_written;
-
low_output= 0x08;
low_direction = 0x2b;
/* initialize
Re: [Openocd-development] [PATCH] interface decrease calling overhead
Hello, i think this patch make sense because the functions are called very often (column calls in the profile data) and do a little bit more then nothing. Am 11.02.2011 07:29, schrieb Øyvind Harboe: I don't have any objections to this particular patch, but if we have to start doing tweaks at this level, then where does it end? If you start optimizing the code with the result of a performance improvement you are looking for functions that called very often and/or use a couple of the application runtime. Not all functions you find can be optimized and its always a compromise between maintainability/clearness, performance and a stable api. I mean the tap stuff inside the interface.c file is part of the heard of openocd and can be made more efficiency. In one part of the file fast tms sequence tables are used and mixed with case statements to determine the tms path and in another part of the file the tap state transistion is determined by a big case statement, why no faster tables there ? Is there any profiling data that backs up this particular optimization as particularly effective? Thats the profile stuff of my session. I read 1 words of the memory and because the nature of the once interface (dsp563xx) there are many tap state changes. With other targets this may not happen because a better/other jtag interface design. Each sample counts as 0.01 seconds. % cumulative self self total time seconds secondscalls ms/call ms/call name 31.82 0.07 0.07 131877 0.00 0.00 clock_tms 18.18 0.11 0.04 385430 0.00 0.00 tap_state_transition 13.64 0.14 0.037 0.00 0.00 buf_set_buf 9.09 0.16 0.02 800438 0.00 0.00 tap_get_state *** 9.09 0.18 0.02 607648 0.00 0.00 tap_move_ndx 4.55 0.19 0.01 385430 0.00 0.00 tap_set_state_impl *** 4.55 0.20 0.01 182295 0.00 0.00 tap_get_tms_path_len 4.55 0.21 0.0160767 0.00 0.00 tap_is_state_stable 4.55 0.22 0.0160765 0.00 0.00 ft2232_execute_scan 0.00 0.22 0.00 243066 0.00 0.00 cmd_queue_alloc 0.00 0.22 0.00 232715 0.00 0.00 tap_get_end_state *** 0.00 0.22 0.00 121530 0.00 0.00 jtag_scan_type 0.00 0.22 0.00 121529 0.00 0.00 tap_get_tms_path 0.00 0.22 0.007 0.00 0.00 buf_cpy 0.00 0.22 0.0071110 0.00 0.00 move_to_state 0.00 0.22 0.0060768 0.00 0.00 jtag_queue_command 0.00 0.22 0.0060767 0.00 0.00 ft2232_end_state 0.00 0.22 0.0060767 0.00 0.00 jtag_checks 0.00 0.22 0.0060767 0.00 0.00 jtag_prelude 0.00 0.22 0.0060767 0.00 0.00 tap_set_end_state *** ... snip ... In sum there are 4308134 function calls in this session and the marked 4 functions are called 1479350 times (34%) in sum without any real algorithm inside the function body. Regards, Mathias ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] interface decrease calling overhead
Hello, Am 11.02.2011 10:01, schrieb Øyvind Harboe: What kind of CPU are you running OpenOCD on? It's a Intel T7200. Regards, Mathias ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] interface decrease calling overhead
Hello, Am 11.02.2011 10:17, schrieb Øyvind Harboe: How about rewriting clock_tms then? Because the used time? This session was to short (some seconds) to get a meaningful time statistic. Regards, Mathias ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] dsp563xx mem rw changes
On a memory read/write access the queue has always flushed at the end. But if i read some more data without a queue excecute in the middle and only at the end i get this error: Error: ftdi_write_data: usb bulk write failed Error: couldn't write MPSSE commands to FT2232 I think there are to much data in the queue??? I don't know what happens there. With a queue excecute after every single memory word read/write access this function is horrible slow and the jtag sclk has really long pause between the single transfers. Regards, Mathias Am 11.02.2011 09:34, schrieb Laurent Gauch: Here I have objection. Adding delay by flushing queue is not a good implementation, since the flush of the queue will have different timing regarding the JTAG probe used: - With Amontec JTAGkey USB full-speed a flush will be around 1-2ms - With Amontec JTAGkey-2 USB High-speed a flush will be around 125us - 250us. - With the coming Amontec Smart JTAGkey-x (running openocd on the JTAGkey) a flush will be around 100ns - 200ns. ... For JTAG the best to add delay will be to use a run tck in IDLE state. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] dsp563xx mem rw changes
Hello,
Am 11.02.2011 16:21, schrieb Mathias K.:
On a memory read/write access the queue has always flushed at the end.
But if i read some more data without a queue excecute in the middle and only
at the end i get this
error:
Error: ftdi_write_data: usb bulk write failed
Error: couldn't write MPSSE commands to FT2232
I think there are to much data in the queue??? I don't know what happens
there.
I have found it. The command buffer overflows and the jtag stop working. I have
add a simple patch
and a description of a possible better solution (hopefully).
Regards,
Mathias
diff --git a/src/jtag/drivers/ft2232.c b/src/jtag/drivers/ft2232.c
index f8b2927..b6a1a3a 100644
--- a/src/jtag/drivers/ft2232.c
+++ b/src/jtag/drivers/ft2232.c
@@ -2081,11 +2081,20 @@ static int ft2232_execute_queue(void)
while (cmd)
{
+ /* fill the write buffer with the desired command */
if (ft2232_execute_command(cmd) != ERROR_OK)
retval = ERROR_JTAG_QUEUE_FAILED;
- /* Start reading input before FT2232 TX buffer fills up */
+ /* Start reading input before FT2232 TX buffer fills up
+* TODO: sometimes this happens because we don't know the
+* length of the last executed command so we have to
+* rewind the buffer, start send_and_recv and execute
+* the last command again
+*
+* is this to much work for you simple decrease this magic
+* number and try it again ;-)
+*/
cmd = cmd-next;
- if (ft2232_expect_read 256)
+ if (ft2232_expect_read 255)
{
if (ft2232_send_and_recv(first_unsent, cmd) != ERROR_OK)
retval = ERROR_JTAG_QUEUE_FAILED;
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] current and maximum jtag queue size for jtag hardware ?
Hello, is there any way to determine the current and maximum queue size before a jtag_execute_queue() has to be executed ? Regards, Mathias ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Correct definition of JTAG_INSTR_CLAMP in dsp563xx_once.c
Hello, in app. note AN1839 (dsp563xx) its 3 ;-). In DSP56300FM and AN2074 they use the correct number 5. Regards, Mathias Am 10.02.2011 20:25, schrieb Phil Fong: Hi, I've been working on Rodrigo on adding support to flash Freescale dsp56800e devices and have been looking at the dsp563xx code. I think the define for the JTAG CLAMP instruction in dsp563xx_once.c is incorrect. It should be 0x05 according the Freescale AN2074 (and is also 0x05 in the dsp568xx according to AN1935). It won't actually change anything in OpenOCD since this define is not used anywhere (as far as I can tell). The patch below fixes this. Phil --- src/target/dsp563xx_once.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/target/dsp563xx_once.c b/src/target/dsp563xx_once.c index b7443fa..1d04e89 100644 --- a/src/target/dsp563xx_once.c +++ b/src/target/dsp563xx_once.c @@ -37,8 +37,8 @@ #define JTAG_INSTR_EXTEST0x00 #define JTAG_INSTR_SAMPLE_PRELOAD0x01 #define JTAG_INSTR_IDCODE0x02 -#define JTAG_INSTR_CLAMP0x03 #define JTAG_INSTR_HIZ0x04 +#define JTAG_INSTR_CLAMP0x05 #define JTAG_INSTR_ENABLE_ONCE0x06 #define JTAG_INSTR_DEBUG_REQUEST0x07 #define JTAG_INSTR_BYPASS0x0F ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] dsp563xx mem rw changes
Changes:
- delay jtag queue excecution to decrease memory read/write times
- fix an early queue excecution in once interface
diff --git a/src/target/dsp563xx.c b/src/target/dsp563xx.c
index 4371d0a..9bfb9a1 100644
--- a/src/target/dsp563xx.c
+++ b/src/target/dsp563xx.c
@@ -29,8 +29,6 @@
#include dsp563xx.h
#include dsp563xx_once.h
-//#define DSP563XX_JTAG_INS_LEN 4
-
#define ASM_REG_W_R0 0x60F400
#define ASM_REG_W_R1 0x61F400
#define ASM_REG_W_R2 0x62F400
@@ -1129,6 +1127,7 @@ static int dsp563xx_read_memory(struct target *target,
int mem_type, uint32_t ad
uint32_t i, x;
uint32_t data, move_cmd;
uint8_t *b;
+ int flush_cnt;
LOG_DEBUG(address: 0x%8.8 PRIx32 , size: 0x%8.8 PRIx32 , count:
0x%8.8 PRIx32, address, size, count);
@@ -1141,6 +1140,7 @@ static int dsp563xx_read_memory(struct target *target,
int mem_type, uint32_t ad
switch (mem_type)
{
case MEM_X:
+ /* TODO: mark effected queued registers */
move_cmd = 0x61d800;
break;
case MEM_Y:
@@ -1167,23 +1167,43 @@ static int dsp563xx_read_memory(struct target *target,
int mem_type, uint32_t ad
x = count;
b = buffer;
+ flush_cnt = 0;
if ((err = dsp563xx_once_execute_dw_ir(target-tap, 0x60F400, address))
!= ERROR_OK)
return err;
for (i = 0; i x; i++)
{
- data = 0;
if ((err = dsp563xx_once_execute_sw_ir_nq(target-tap,
move_cmd)) != ERROR_OK)
return err;
- if ((err = dsp563xx_once_execute_sw_ir(target-tap, 0x08D13C))
!= ERROR_OK)
+ if ((err = dsp563xx_once_execute_sw_ir_nq(target-tap,
0x08D13C)) != ERROR_OK)
return err;
- if ((err = dsp563xx_once_reg_read(target-tap,
DSP563XX_ONCE_OGDBR, data)) != ERROR_OK)
+ if ((err = dsp563xx_once_reg_read_nq(target-tap,
DSP563XX_ONCE_OGDBR, (uint32_t*)b)) != ERROR_OK)
return err;
- target_buffer_set_u32(target, b, data);
b += 4;
- LOG_DEBUG(R: %08X, data);
+ /* delay jtag queue excecution */
+ if ( ++flush_cnt = 20 )
+ {
+ if ((err = jtag_execute_queue()) != ERROR_OK)
+ return err;
+ flush_cnt = 0;
+ }
+ }
+
+ /* flush the jtag queue */
+ if ((err = jtag_execute_queue()) != ERROR_OK)
+ return err;
+
+ /* walk over the buffer and fix target endianness */
+ b = buffer;
+
+ for (i = 0; i x; i++)
+ {
+ data = *((uint32_t*)b) 0x00FF;
+// LOG_DEBUG(R: %08X, *((uint32_t*)b));
+ target_buffer_set_u32(target, b, data);
+ b += 4;
}
return ERROR_OK;
@@ -1201,6 +1221,7 @@ static int dsp563xx_write_memory(struct target *target,
int mem_type, uint32_t a
uint32_t i, x;
uint32_t data, move_cmd;
uint8_t *b;
+ int flush_cnt;
LOG_DEBUG(address: 0x%8.8 PRIx32 , size: 0x%8.8 PRIx32 , count:
0x%8.8 PRIx32 , address, size, count);
@@ -1239,6 +1260,7 @@ static int dsp563xx_write_memory(struct target *target,
int mem_type, uint32_t a
x = count;
b = buffer;
+ flush_cnt = 0;
if ((err = dsp563xx_once_execute_dw_ir(target-tap, 0x60F400, address))
!= ERROR_OK)
return err;
@@ -1246,18 +1268,30 @@ static int dsp563xx_write_memory(struct target *target,
int mem_type, uint32_t a
for (i = 0; i x; i++)
{
data = target_buffer_get_u32(target, b);
- data = 0x00ff;
- LOG_DEBUG(W: %08X, data);
+// LOG_DEBUG(W: %08X, data);
+
+ data = 0x00ff;
if ((err = dsp563xx_once_execute_dw_ir_nq(target-tap,
0x61F400, data)) != ERROR_OK)
return err;
- if ((err = dsp563xx_once_execute_sw_ir(target-tap, move_cmd))
!= ERROR_OK)
+ if ((err = dsp563xx_once_execute_sw_ir_nq(target-tap,
move_cmd)) != ERROR_OK)
return err;
-
b += 4;
+
+ /* delay jtag queue excecution */
+ if ( flush_cnt++ = 20 )
+ {
+ if ((err = jtag_execute_queue()) != ERROR_OK)
+ return err;
+ flush_cnt = 0;
+ }
}
+ /* flush the jtag queue */
+ if ((err = jtag_execute_queue()) != ERROR_OK)
+ return err;
+
return ERROR_OK;
}
@@ -1266,6 +1300,11 @@ static int dsp563xx_write_memory_p(struct target
*target, uint32_t address, uint
return dsp563xx_write_memory(target, MEM_P, address, size, count,
buffer);
}
+static int
[Openocd-development] [PATCH] interface decrease calling overhead
Changes:
- declare tap_set_state_impl, tap_get_state, tap_set_end_state,
tap_get_end_state as static inline,
this will decrease the calling overhead for this status getter and setter
functions
diff --git a/src/jtag/interface.c b/src/jtag/interface.c
index 1ed4512..8d5d514 100644
--- a/src/jtag/interface.c
+++ b/src/jtag/interface.c
@@ -38,38 +38,13 @@
* @see tap_set_state() and tap_get_state() accessors.
* Actual name is not important since accessors hide it.
*/
-static tap_state_t state_follower = TAP_RESET;
-
-void tap_set_state_impl(tap_state_t new_state)
-{
- /* this is the state we think the TAPs are in now, was cur_state */
- state_follower = new_state;
-}
-
-tap_state_t tap_get_state()
-{
- return state_follower;
-}
+tap_state_t state_follower = TAP_RESET;
/**
* @see tap_set_end_state() and tap_get_end_state() accessors.
* Actual name is not important because accessors hide it.
*/
-static tap_state_t end_state_follower = TAP_RESET;
-
-void tap_set_end_state(tap_state_t new_end_state)
-{
- /* this is the state we think the TAPs will be in at completion of the
- current TAP operation, was end_state
- */
- end_state_follower = new_end_state;
-}
-
-tap_state_t tap_get_end_state()
-{
- return end_state_follower;
-}
-
+tap_state_t end_state_follower = TAP_RESET;
int tap_move_ndx(tap_state_t astate)
{
diff --git a/src/jtag/interface.h b/src/jtag/interface.h
index 958af8f..623b106 100644
--- a/src/jtag/interface.h
+++ b/src/jtag/interface.h
@@ -36,9 +36,15 @@
* cable.
*/
+/** */
+extern tap_state_t state_follower;
/** implementation of wrapper function tap_set_state() */
-void tap_set_state_impl(tap_state_t new_state);
+static inline void tap_set_state_impl(tap_state_t new_state)
+{
+ /* this is the state we think the TAPs are in now, was cur_state */
+ state_follower = new_state;
+}
/**
* This function sets the state of a state follower which tracks the
@@ -74,7 +80,13 @@ static inline void tap_set_state(tap_state_t new_state)
* state of the TAPs connected to the cable. @see tap_set_state @return
* tap_state_t The state the TAPs are in now.
*/
-tap_state_t tap_get_state(void);
+static inline tap_state_t tap_get_state(void)
+{
+ return state_follower;
+}
+
+/** */
+extern tap_state_t end_state_follower;
/**
* This function sets the state of an end state follower which tracks
@@ -87,13 +99,23 @@ tap_state_t tap_get_state(void);
* @param new_end_state The state the TAPs should enter at completion of
* a pending TAP operation.
*/
-void tap_set_end_state(tap_state_t new_end_state);
+static inline void tap_set_end_state(tap_state_t new_end_state)
+{
+ /* this is the state we think the TAPs will be in at completion of the
+ current TAP operation, was end_state
+ */
+ end_state_follower = new_end_state;
+}
/**
* For more information, @see tap_set_end_state
* @return tap_state_t - The state the TAPs should be in at completion of the
current TAP operation.
*/
-tap_state_t tap_get_end_state(void);
+static inline tap_state_t tap_get_end_state(void)
+{
+ return end_state_follower;
+}
+
/**
* This function provides a bit sequence indicating what has to be
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] buf_set_buf around 30% speed increase
Hello, On 05.02.2011 10:43, Øyvind Harboe wrote: What sort of CPU did you run the tests on? Which test? The target cpu/mcu or my system cpu? Let me know when the patch is ready to be committed. I suppose it could need a bit of coolof . I think its fine. Regards, Mathias ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] FT2232 USB Unplug
Hello, On 08.02.2011 15:37, Tom Schouten wrote: However, when restarting OpenOCD after USB replug it does work like normal. Is there a way to make this recover inside OpenOCD, or otherwise to simply exit the application so it can be restarted automatically? Yes, you can exit openocd. Try the shutdown command. Regards, Mathias ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] buf_set_buf around 30% speed increase
Hello, On 07.02.2011 09:09, Øyvind Harboe wrote: What impact would it have to make this an inline fn? I think there is no need to declare this big function as inline. This will only increase the code size. I see some functions in the jtag/interface.c file with a very small body that could be declared as inline because they are called very very often: tap_set_state_impl tap_get_state tap_set_end_state tap_get_end_state Regards, Mathias ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] cortex_a9: fix dap_ap_select() usage
Hello, On 07.02.2011 09:27, luca ellero wrote: 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 equal in a complete architecture or is this done at cpu vendor level. For mem read/writes we need the AP with the CPU component. You can determine this by dap info X command (as example cortex_r4/TMS570): [snip] If i look into the cortex_a8 sources then i think the cpu component is in AP 0 and there is no switching needed. Can anyone send the dap info X output for a cortex_a8 ? On A8/omap35xx and A9/omap44xx, the CPU CoreSight component is on AP 0 (an APB-AP). However, for both these platforms we do memory accesses on AP 1, which is an AHB-AP. One advantage of this is the core does not need to be halted to access memory. The upshot is that we do need to switch between AP's. I agree that this should be abstracted somehow, but in the mean time A9 is broken :) Correct me if I'm wrong but I think it's the opposite: AHB-AP is 0 and APB-AP is 1. Furthermore, there is also a JTAG-AP which is AP 2. It's the same for me. At the moment I'm just implementing access to memory through APB (so we can access also memory on L2). What I'm doing right now is differentiating access based on which AP is selected. In other words if we want to access memory through AHB we need to issue dap apsel 0 before, if we want to access memory through APB we need to issue dap apsel 1 before. What do you think? Have you any better ideas? This should be done in arm_adi_v5.c and for maybe future changes of ap numbering the correct AP for AHB and APB is a variable in struct adiv5_dap and not hard coded. Maybe dap-ap_ahb and dap-ap_apb. For the first implementation/test the initialization of both should be hard coded and later this can be done in some kind of dap auto detection. For auto detection we can use parts of the dap_info_command function. This function walk over all AP and the connected components. Regards, Mathias ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] cortex_a9: fix dap_ap_select() usage
Hello, On 07.02.2011 03:54, Aaron Carroll wrote: On A8/omap35xx and A9/omap44xx, the CPU CoreSight component is on AP 0 (an APB-AP). However, for both these platforms we do memory accesses on AP 1, which is an AHB-AP. One advantage of this is the core does not need to be halted to access memory. The upshot is that we do need to switch between AP's. I agree that this should be abstracted somehow, but in the mean time A9 is broken :) So we need one AP to control the DP and a second AP for all the MEM-AP read/write functions. I think this can be done completely in arm_di_v5.c/.h. Is this is done we no longer need to use the dap_ap_select function in the higher layers. Regards, Mathias ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Implementing per-TAP data
Hello, On 07.02.2011 03:57, Aaron Carroll wrote: On 04/02/11 17:00, Øyvind Harboe wrote: Maybe DAPs should exist independently of JTAG and targets and targets should refer to the DAP relevant to that target? Agreed, but then how does one discover the DAP relevant to a TAP. Suppose core0 is online and you're bringing up core1... all you have is a fresh target and a TAP pointer. And the DAP in the JTAG chain. If you enable the DAP you are able to access the external chain behind the DAP and to the CPUs and all other components. http://www.arm.com/images/CoreSight_Diagram.jpg Regards, Mathias ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] buf_set_buf around 30% speed increase
Hello,
this patch increase the speed of the buf_set_buf function around 30%.
Regards,
Mathias
diff --git a/src/helper/binarybuffer.c b/src/helper/binarybuffer.c
index 3a16cce..e789e6f 100644
--- a/src/helper/binarybuffer.c
+++ b/src/helper/binarybuffer.c
@@ -133,19 +133,34 @@ void* buf_set_buf(const void *_src, unsigned src_start,
{
const uint8_t *src = _src;
uint8_t *dst = _dst;
+ unsigned sb,db,sq,dq;
+
+ sb = src_start / 8;
+ db = dst_start / 8;
+ sq = src_start % 8;
+ dq = dst_start % 8;
- unsigned src_idx = src_start, dst_idx = dst_start;
for (unsigned i = 0; i len; i++)
{
- if (((src[src_idx / 8] (src_idx % 8)) 1) == 1)
- dst[dst_idx / 8] |= 1 (dst_idx % 8);
+ if (((*src (sq7)) 1) == 1)
+ *dst |= 1 (dq7);
else
- dst[dst_idx / 8] = ~(1 (dst_idx % 8));
- dst_idx++;
- src_idx++;
+ *dst = ~(1 (dq7));
+
+ if ( sq++ == 7 )
+ {
+ sq = 0;
+ src++;
+ }
+
+ if ( dq++ == 7 )
+ {
+ dq = 0;
+ dst++;
+ }
}
- return dst;
+ return (uint8_t*)_dst;
}
uint32_t flip_u32(uint32_t value, unsigned int num)
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] buf_set_buf around 30% speed increase
Hello,
okay the patch has a little bug. I have not set the correct start pointer of the input and output
buffer.
Also i have checked the input of this function and in many cases a simple byte
copy is possible.
I have added this check now and is it possible the buffer is copied byte by
byte and not bit by bit.
With byte boundary input the test looks like this:
buf_set_buf 0x0200 iteration test:
runtime (seconds): old: 6.828559 new: 0.436191 diff: 6.392368
runtime (seconds): old: 6.853636 new: 0.430389 diff: 6.423247
runtime (seconds): old: 6.794985 new: 0.423065 diff: 6.371920
Without:
buf_set_buf 0x0200 iteration test:
runtime (seconds): old: 6.370869 new: 5.552624 diff: 0.818245
runtime (seconds): old: 6.420730 new: 5.665887 diff: 0.754843
runtime (seconds): old: 6.583306 new: 5.599021 diff: 0.984285
Regards,
Mathias
diff --git a/src/helper/binarybuffer.c b/src/helper/binarybuffer.c
index 3a16cce..e789e6f 100644
--- a/src/helper/binarybuffer.c
+++ b/src/helper/binarybuffer.c
@@ -133,19 +133,34 @@ void* buf_set_buf(const void *_src, unsigned src_start,
{
const uint8_t *src = _src;
uint8_t *dst = _dst;
+ unsigned sb,db,sq,dq;
+
+ sb = src_start / 8;
+ db = dst_start / 8;
+ sq = src_start % 8;
+ dq = dst_start % 8;
- unsigned src_idx = src_start, dst_idx = dst_start;
for (unsigned i = 0; i len; i++)
{
- if (((src[src_idx / 8] (src_idx % 8)) 1) == 1)
- dst[dst_idx / 8] |= 1 (dst_idx % 8);
+ if (((*src (sq7)) 1) == 1)
+ *dst |= 1 (dq7);
else
- dst[dst_idx / 8] = ~(1 (dst_idx % 8));
- dst_idx++;
- src_idx++;
+ *dst = ~(1 (dq7));
+
+ if ( sq++ == 7 )
+ {
+ sq = 0;
+ src++;
+ }
+
+ if ( dq++ == 7 )
+ {
+ dq = 0;
+ dst++;
+ }
}
- return dst;
+ return (uint8_t*)_dst;
}
uint32_t flip_u32(uint32_t value, unsigned int num)
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] buf_set_buf around 30% speed increase
sorry, wrong file ...
diff --git a/src/helper/binarybuffer.c b/src/helper/binarybuffer.c
index 3a16cce..08e149a 100644
--- a/src/helper/binarybuffer.c
+++ b/src/helper/binarybuffer.c
@@ -133,19 +133,48 @@ void* buf_set_buf(const void *_src, unsigned src_start,
{
const uint8_t *src = _src;
uint8_t *dst = _dst;
+ unsigned i,sb,db,sq,dq, lb,lq;
+
+ sb = src_start / 8;
+ db = dst_start / 8;
+ sq = src_start % 8;
+ dq = dst_start % 8;
+ lb = len / 8;
+ lq = len % 8;
+
+ src += sb;
+ dst += db;
+
+ /* check if both buffers are on byte boundary and
+* len is a multiple of 8bit so we can simple copy
+* the buffer */
+ if ( (sq == 0) (dq == 0) (lq == 0) )
+ {
+ for (i = 0; i lb; i++)
+ *dst++ = *src++;
+ return (uint8_t*)_dst;
+ }
- unsigned src_idx = src_start, dst_idx = dst_start;
- for (unsigned i = 0; i len; i++)
+ /* fallback to slow bit copy */
+ for (i = 0; i len; i++)
{
- if (((src[src_idx / 8] (src_idx % 8)) 1) == 1)
- dst[dst_idx / 8] |= 1 (dst_idx % 8);
+ if (((*src (sq7)) 1) == 1)
+ *dst |= 1 (dq7);
else
- dst[dst_idx / 8] = ~(1 (dst_idx % 8));
- dst_idx++;
- src_idx++;
+ *dst = ~(1 (dq7));
+ if ( sq++ == 7 )
+ {
+ sq = 0;
+ src++;
+ }
+ if ( dq++ == 7 )
+ {
+ dq = 0;
+ dst++;
+ }
}
- return dst;
+ return (uint8_t*)_dst;
}
uint32_t flip_u32(uint32_t value, unsigned int num)
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] dsp563xx: add x, y and p memory access
Hello,
this patch add commands to access to x,y and p memory. For run time optimization some local jtag
function was changed to static inline.
Regards,
Mathias
diff --git a/src/target/dsp563xx.c b/src/target/dsp563xx.c
index 85d559a..4371d0a 100644
--- a/src/target/dsp563xx.c
+++ b/src/target/dsp563xx.c
@@ -201,6 +201,7 @@ static const struct
};
#define REG_NUM_R0 0
+#define REG_NUM_R1 1
#define REG_NUM_N0 8
#define REG_NUM_N1 9
#define REG_NUM_M0 16
@@ -221,6 +222,13 @@ static const struct
#define REG_NUM_AAR2 52
#define REG_NUM_AAR3 53
+enum memory_type
+{
+ MEM_X = 0,
+ MEM_Y = 1,
+ MEM_P = 2,
+};
+
#define INSTR_JUMP 0x0AF080
/* Effective Addressing Mode Encoding */
#define EAME_R00x10
@@ -359,11 +367,11 @@ static int dsp563xx_reg_read_high_io(struct target
*target, uint32_t instr_mask,
dsp563xx-read_core_reg(target, REG_NUM_R0);
/* move source memory to r0 */
- instr = INSTR_MOVEP_REG_HIO(0, 0, EAME_R0, instr_mask);
+ instr = INSTR_MOVEP_REG_HIO(MEM_X, 0, EAME_R0, instr_mask);
if ((err = dsp563xx_once_execute_sw_ir_nq(target-tap, instr)) !=
ERROR_OK)
return err;
/* move r0 to debug register */
- instr = INSTR_MOVEP_REG_HIO(0, 1, EAME_R0, 0xfc);
+ instr = INSTR_MOVEP_REG_HIO(MEM_X, 1, EAME_R0, 0xfc);
if ((err = dsp563xx_once_execute_sw_ir(target-tap, instr)) != ERROR_OK)
return err;
/* read debug register */
@@ -389,7 +397,7 @@ static int dsp563xx_reg_write_high_io(struct target
*target, uint32_t instr_mask
if ((err = dsp563xx_once_execute_dw_ir_nq(target-tap, 0x60F400, data))
!= ERROR_OK)
return err;
/* move r0 to destination memory */
- instr = INSTR_MOVEP_REG_HIO(0, 1, EAME_R0, instr_mask);
+ instr = INSTR_MOVEP_REG_HIO(MEM_X, 1, EAME_R0, instr_mask);
if ((err = dsp563xx_once_execute_sw_ir(target-tap, instr)) != ERROR_OK)
return err;
@@ -404,7 +412,7 @@ static int dsp563xx_reg_read(struct target *target,
uint32_t eame, uint32_t * da
int err;
uint32_t instr;
- instr = INSTR_MOVEP_REG_HIO(0, 1, eame, 0xfc);
+ instr = INSTR_MOVEP_REG_HIO(MEM_X, 1, eame, 0xfc);
if ((err = dsp563xx_once_execute_sw_ir_nq(target-tap, instr)) !=
ERROR_OK)
return err;
/* nop */
@@ -1114,33 +1122,12 @@ static int dsp563xx_soft_reset_halt(struct target
*target)
return ERROR_OK;
}
-/*
-* 00 nop
-* 46F400 AABBCCmove #$aabbcc,y0
-* 60F400 AABBCCmove #$aabbcc,r0
-* 467000 AABBCCmove y0,x:AABBCC
-* 607000 AABBCCmove r0,x:AABBCC
-
-* 46E000 move x:(r0),y0
-* 4EE000 move y:(r0),y0
-* 07E086 move p:(r0),y0
-
-* 0450B9 move sr,r0
-* 0446BA move omr,y0
-* 0446BC move ssh,y0
-* 0446BD move ssl,y0
-* 0446BE move la,y0
-* 0446BF move lc,y0
-*
-* 61F000 AABBCCmove x:AABBCC,r1
-* 076190 movem r0,p:(r1)
-*
-*/
-static int dsp563xx_read_memory_p(struct target *target, uint32_t address,
uint32_t size, uint32_t count, uint8_t * buffer)
+static int dsp563xx_read_memory(struct target *target, int mem_type, uint32_t
address, uint32_t size, uint32_t count, uint8_t * buffer)
{
int err;
+ struct dsp563xx_common *dsp563xx = target_to_dsp563xx(target);
uint32_t i, x;
- uint32_t data;
+ uint32_t data, move_cmd;
uint8_t *b;
LOG_DEBUG(address: 0x%8.8 PRIx32 , size: 0x%8.8 PRIx32 , count:
0x%8.8 PRIx32, address, size, count);
@@ -1151,41 +1138,68 @@ static int dsp563xx_read_memory_p(struct target
*target, uint32_t address, uint3
return ERROR_TARGET_NOT_HALTED;
}
+ switch (mem_type)
+ {
+ case MEM_X:
+ move_cmd = 0x61d800;
+ break;
+ case MEM_Y:
+ move_cmd = 0x69d800;
+ break;
+ case MEM_P:
+ move_cmd = 0x07d891;
+ break;
+ default:
+ return ERROR_INVALID_ARGUMENTS;
+ }
+
+ /* we use r0 to store temporary data */
+ if (!dsp563xx-core_cache-reg_list[REG_NUM_R0].valid)
+ dsp563xx-read_core_reg(target, REG_NUM_R0);
+ /* we use r1 to store temporary data */
+ if (!dsp563xx-core_cache-reg_list[REG_NUM_R1].valid)
+ dsp563xx-read_core_reg(target, REG_NUM_R1);
+
+ /* r0 is no longer valid on target */
+
Re: [Openocd-development] [PATCH] cortex_a9: fix dap_ap_select() usage
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 equal in a complete architecture or is this done at cpu vendor level. For mem read/writes we need the AP with the CPU component. You can determine this by dap info X command (as example cortex_r4/TMS570): dap info 0 AP ID register 0x14770001 Type is MEM-AP AHB AP BASE 0x No ROM table present dap info 1 AP ID register 0x04770002 Type is MEM-AP APB AP BASE 0x8000 ROM table in legacy format MEMTYPE System memory not present. Dedicated debug bus. ROMTABLE[0x0] = 0x1003 Component base address 0x80001000, start address 0x80001000 Component class is 0x9, CoreSight component Type is 0x15, Debug Logic, Processor Peripheral ID[4..0] = hex 04 00 6b bc 14 Part is -*- unrecognized -*- ROMTABLE[0x4] = 0x2003 Component base address 0x80002000, start address 0x80002000 Component class is 0x9, CoreSight component Type is 0x13, Trace Source, Processor Peripheral ID[4..0] = hex 04 00 0b b9 30 Part is Cortex-R4 ETM (Embedded Trace) ROMTABLE[0x8] = 0x3003 Component base address 0x80003000, start address 0x80003000 Component class is 0x9, CoreSight component Type is 0x11, Trace Sink, Port Peripheral ID[4..0] = hex 04 00 1b b9 12 Part is Coresight TPIU (Trace Port Interface Unit) ROMTABLE[0xc] = 0x4003 Component base address 0x80004000, start address 0x80004000 Component class is 0x9, CoreSight component Type is 0x04, Debug Control, other Peripheral ID[4..0] = hex 00 00 09 70 00 Part is Cortex-M3 NVIC (Interrupt Controller) ROMTABLE[0x10] = 0x0 End of ROM table dap info 2 AP ID register 0x14760010 Type is JTAG-AP No ROM table present dap info 3 AP ID register 0x No AP found at this apsel 0x3 No ROM table present If i look into the cortex_a8 sources then i think the cpu component is in AP 0 and there is no switching needed. Can anyone send the dap info X output for a cortex_a8 ? Is my assumption is true then the correct AP can select at a lower level and the higher level don't need to know about the correct AP. How this structure is looking in your multi core a9 ? Regards, Mathias ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
