Re: [OpenOCD-devel] make arm_adi_v5.c transport independent
On Mar 15, 2012 3:15 AM, simonqian.openocd simonqian.open...@gmail.com wrote: Yes, I know how SRST should not be processed in DAP, but make the change you mentioned is too large for me to handle in OpenOCD. And it also risky because it affect too much in OpenOCD. Ok then lets do it as you proposed if its already working :-) In vsprog, I have the similar interface layer, which processes all signals to the target. SRST control in vsprog is in GPIO module, for example: interfaces-gpio.config(0, GPIO_SRST, GPIO_SRST, 0, 0); interfaces-gpio.set(0, GPIO_SRST); There is of course jtag and swd function, and can be called like: interfaces-jtag_hl.ir(); interfaces-jtag_hl.dr(); interfaces-swd.transact(); So it's very simple for me to add different transports and targets in vsprog. So we should place that reset implementation using interface bitbang..? The main advantage of this solution is to create and operate on signals at runtime.. About double buffer operation in cortex-m targets. There are 2 buffers in working area of target chip, flash loader will do programming operations if one of them is filled with data. And while the flash loader is doing the programming, we can meanwhile download data into the other buffer. So if we select the right buffer size, we can get the max speed. For stm32, as I test on versaloon, it's about 35KB/s. So there is some code uploaded and executed on the target and that code use ram buffers to store data for better efficiency..? Where can I read more about this solution? Will it work with OpenOCD? Best regards :-) Tomek CeDeROM, SQ7MHZ, http://www.tomek.cedro.info -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] make arm_adi_v5.c transport independent
On Mar 15, 2012 4:32 AM, Peter Stuge pe...@stuge.se wrote: Tomek CEDRO wrote: I am a bit afraid that my great ideas on automatic error handling and enqueueing longer operation sequences are anyway going to be broken because of the USB latency bottleneck :-( Were maximum FT2232H transfers calculated by anyone for JTAG already? Peter, would that be possible to have small transfer latency less than 1us for FT2232 devices using libftdi/libusb? Yes, but only if the correct number of transfers are queued in advanced using the libusb-1.0 async API. Then the multiple bulk transfers can be scheduled by the USB host controller within the same 125µs microframe. But obviously it's not possible to evaluate any data from transfer one before submitting transfer two in this case. If the number of transfers can not be predicted then the minimum theoretical latency per transfer is 125µs ie. one microframe, but in practise it will be tens of ms because of context switching between kernel and userspace. Ugh, this will not help as we need to evaluate results very often as you noted. Also this would vary across different platforms... Ill see how things could be speeded up using TAR autoincrement and sticky errors handling so we write large data in bursts of few kilobytes at once (1k or 64k max for mpsse per command)... Best regards :-) Tomek CeDeROM, SQ7MHZ, http://www.tomek.cedro.info -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] make arm_adi_v5.c transport independent
Tomek CEDRO wrote: in practise it will be tens of ms Ugh, this will not help as we need to evaluate results very often as you noted. Also this would vary across different platforms... Yep. Ill see how things could be speeded up using TAR autoincrement and sticky errors handling so we write large data in bursts of few kilobytes at once (1k or 64k max for mpsse per command)... That's great if possible. This is why I rant so violently against FTDI chips. They are too stupid. //Peter -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] make arm_adi_v5.c transport independent
On Mar 15, 2012 8:30 AM, Peter Stuge pe...@stuge.se wrote: Ill see how things could be speeded up using TAR autoincrement and sticky errors handling so we write large data in bursts of few kilobytes at once (1k or 64k max for mpsse per command)... That's great if possible. This is why I rant so violently against FTDI chips. They are too stupid. Well on the other they are very generic and cheap so versatile solutions can be built on top of them (and they are) easily. Yesterday trick pushes mpsse to the limits already, I have also some idea on how to compact unidirectional operations from the queue. TAR autoincrement should give a breakthrough speed on generic adapters. Maybe the double buffer can be implemented in OpenOCD as well. Its not that bad, there are still lots of possibilities to try :-) Best regards, Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] make arm_adi_v5.c transport independent
Yup, the easiest way to test thing without changing stuff with dependencies
in multiple places would be simply to create a wrapper for existing
function that will call original with _jtag suffix or new one with _swd
suffix, just as I did in case of memapreadu32. Changing functions inline
would produce more work in future so I would prefer to create a wrapper and
additional function to leave original untouched (except _jtag prefix)... is
that ok for you Simon?
Best regards :-)
Tomek
--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
On Mar 15, 2012 2:57 PM, simonqian.openocd simonqian.open...@gmail.com
wrote:
**
OK, I have tested this patch with my other SWD patches, it works well.
But another code should be fixed too.
I want to query for how to fix it.
on reset init command, init_reset procedure in startup.tcl will be
called:
proc init_reset { mode } {
jtag arp_init-reset
}
and then jim_jtag_arp_init_reset will be called to process jtag
arp_init-reset.
But jim_jtag_arp_init_reset will call jtag_init_reset, which is not valid
under SWD mode.
I want to know how to fix it.
startup.tcl should detect current transport and call jtag arp_init-reset
in JTAG mode?
Or add a check in jim_jtag_arp_init_reset like below:
if (transport_is_jtag())
{
int e = jtag_init_reset(context);
if (e != ERROR_OK) {
Jim_Obj *eObj = Jim_NewIntObj(goi.interp, e);
Jim_SetResultFormatted(goi.interp, error: %#s, eObj);
Jim_FreeNewObj(goi.interp, eObj);
return JIM_ERR;
}
}
--
simonqian.openocd
*From:* simonqian.openocd simonqian.open...@gmail.com
*Date:* 2012-03-15 02:34
*To:* Tomek CEDRO tomek.ce...@gmail.com
*CC:* openocd-devel openocd-devel@lists.sourceforge.net; Peter
Stugepe...@stuge.se
*Subject:* Re: Re: [OpenOCD-devel] make arm_adi_v5.c transport independent
First patch to review: no call jtag_add_reset regardless of the
transport selected.
--
simonqian.openocd
--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure___
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] make arm_adi_v5.c transport independent
Tomek CEDRO wrote: On Mar 15, 2012 8:30 AM, Peter Stuge pe...@stuge.se wrote: Ill see how things could be speeded up using TAR autoincrement and sticky errors handling so we write large data in bursts of few kilobytes at once (1k or 64k max for mpsse per command)... That's great if possible. This is why I rant so violently against FTDI chips. They are too stupid. Well on the other they are very generic and cheap A Cortex-M3 (LPC1343 or STM32) *development board* is cheaper than an FTDI *chip* actually. //Peter -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] make arm_adi_v5.c transport independent
On 15.03.2012 16:04, Peter Stuge wrote: Tomek CEDRO wrote: On Mar 15, 2012 8:30 AM, Peter Stuge pe...@stuge.se wrote: Ill see how things could be speeded up using TAR autoincrement and sticky errors handling so we write large data in bursts of few kilobytes at once (1k or 64k max for mpsse per command)... That's great if possible. This is why I rant so violently against FTDI chips. They are too stupid. Well on the other they are very generic and cheap A Cortex-M3 (LPC1343 or STM32) *development board* is cheaper than an FTDI *chip* actually. But not that much: http://apple.clickandbuild.com/cnb/shop/ftdichip?op=catalogue-products-nullprodCategoryID=75title=FT4232H+Module Regards, Mathias -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] make arm_adi_v5.c transport independent
So I implement it as below:
First add swd_init_reset:
int swd_init_reset(struct command_context *cmd_ctx)
{
int retval = adapter_init(cmd_ctx);
if (retval != ERROR_OK)
return retval;
LOG_DEBUG(Initializing with hard SRST reset);
jtag_add_reset(0, 1);
jtag_add_reset(0, 0);
retval = jtag_execute_queue();
return retval;
}
And in jim_jtag_arp_init_reset:
if (transport_is_jtag())
e = jtag_init_reset(context);
else if (transport_is_swd())
e = swd_init_reset(context);
I'm doing some tests, if it's OK I'll format a new patch.
And next patch will be to make arm_adi_v5 transport independent.
And then add the SWD driver layer.
Then enjoy SWD.
simonqian.openocd
From: Tomek CEDRO
Date: 2012-03-15 23:03
To: simonqian.openocd
CC: openocd-devel; Peter Stuge
Subject: Re: Re: [OpenOCD-devel] make arm_adi_v5.c transport independent
Yup, the easiest way to test thing without changing stuff with dependencies in
multiple places would be simply to create a wrapper for existing function that
will call original with _jtag suffix or new one with _swd suffix, just as I did
in case of memapreadu32. Changing functions inline would produce more work in
future so I would prefer to create a wrapper and additional function to leave
original untouched (except _jtag prefix)... is that ok for you Simon?
Best regards :-)
Tomek
--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
On Mar 15, 2012 2:57 PM, simonqian.openocd simonqian.open...@gmail.com
wrote:
OK, I have tested this patch with my other SWD patches, it works well.
But another code should be fixed too.
I want to query for how to fix it.
on reset init command, init_reset procedure in startup.tcl will be called:
proc init_reset { mode } {
jtag arp_init-reset
}
and then jim_jtag_arp_init_reset will be called to process jtag
arp_init-reset.
But jim_jtag_arp_init_reset will call jtag_init_reset, which is not valid under
SWD mode.
I want to know how to fix it.
startup.tcl should detect current transport and call jtag arp_init-reset in
JTAG mode?
Or add a check in jim_jtag_arp_init_reset like below:
if (transport_is_jtag())
{
int e = jtag_init_reset(context);
if (e != ERROR_OK) {
Jim_Obj *eObj = Jim_NewIntObj(goi.interp, e);
Jim_SetResultFormatted(goi.interp, error: %#s, eObj);
Jim_FreeNewObj(goi.interp, eObj);
return JIM_ERR;
}
}
simonqian.openocd
From: simonqian.openocd
Date: 2012-03-15 02:34
To: Tomek CEDRO
CC: openocd-devel; Peter Stuge
Subject: Re: Re: [OpenOCD-devel] make arm_adi_v5.c transport independent
First patch to review: no call jtag_add_reset regardless of the transport
selected.
simonqian.openocd--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure___
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] make arm_adi_v5.c transport independent
simonqian.openocd wrote: I'm doing some tests, if it's OK I'll format a new patch. I think it looks fine. Am looking forward to the patch. I would suggest changing the Tcl command from jtag to e.g. transport while keeping backwards compatibility but outputing a warning whenever someone uses the old command, but that can be done later. //Peter -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] Bug in mips32_pracc_read_mem32
On 03/14/2012 07:24 PM, salvador wrote: Hello If i try the command mdw addr n with n greater than 1024 the data displayed is wrong from 1025 onward. The bug is located in mips32_pracc.c, in function mips32_pracc_read_mem32 About line 364: count -= blocksize; addr += blocksize; bytesread += blocksize; Should be: count -= blocksize; addr += blocksize * sizeof(uint32_t); bytesread += blocksize; bytesread is a variable that counts words A little confusing, isn't it? Thanks Salvador. -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel Sorry Drasko, i can see your reply at openocd mail archives but not in my mail box, so i reply to my first mail. Step by step: 1.- There is no call to mips32_pracc_read_mem32() in mips_m4k_read_memory(). 2.- I guess you mean a call to mips32_pracc_read_mem(). This function has a parameter int size. 3.- The function mips32_pracc_read_mem() is defined in mips32_pracc.c . This function calls mips32_pracc_read_mem32() only if the parameter size is 4 (WORD) and count 1. 4.- In function mips32_pracc_read_mem32(), in the call to mips32_pracc_exec() the variable bytesread is used as an index in a matrix of uint32_t (WORDS). Sorry but i can not find anything in the code that says bytesread or count counts bytes. But WORDS, yes. Thanks Salvador. -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] [PATCH]: 363131e drivers/jtag: rewrite usb_blaster driver
On 5 March 2012 10:30, Spencer Oliver s...@spen-soft.co.uk wrote: On 17 February 2012 15:55, ger...@openocd.zylin.com wrote: This is an automated email from Gerrit. Robert Jarzmik (robert.jarz...@free.fr) just uploaded a new patch set to Gerrit, which you can find at http://openocd.zylin.com/467 -- gerrit commit 363131eb9c96388e75e33e07b736a5fdc9b6b821 Author: Robert Jarzmik robert.jarz...@free.fr Date: Mon Jan 16 11:31:30 2012 +0100 drivers/jtag: rewrite usb_blaster driver Rewrite the Altera USB Blaster dongle driver : - make extensive use of byte-shift mode, to improve JTAG speed This is the main reason of the rewrite. It improves the memory dumps with a factor 3 at least, and upload 12 times, from 1 kBytes/sec to 13 kBytes/sec with a USB-Blaster connected to a PXA270 JTAG TAP. - split the low level API part (between FTDI and FTD2xx) from core driver, so that in the future, if both libftdi and ftd2xx can coexist, the driver will be able to switch dynamically from one access to the other. Change-Id: I2ee9cedf4a5eb27501f337993ee0cdee52517e7c Signed-off-by: Robert Jarzmik robert.jarz...@free.fr Is anyone able to test this patch ? if i do not here any objections by the weekend then i am going to commit this patch. Spen -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
[OpenOCD-devel] [PATCH]: 05b2537 gdb_server: Simple close the connection and not exit openocd.
This is an automated email from Gerrit.
Mathias Küster (kes...@freenet.de) just uploaded a new patch set to Gerrit,
which you can find at http://openocd.zylin.com/523
-- gerrit
commit 05b25371a10a4f74ab40064ec24fc6cad85f4057
Author: Mathias K kes...@freenet.de
Date: Thu Mar 15 09:11:19 2012 +0100
gdb_server: Simple close the connection and not exit openocd.
This patch let openocd running and only close the gdb connection
on error.
Change-Id: Ifb88e16834b51207cc4c82210eab904ed8d30b71
Signed-off-by: Mathias K kes...@freenet.de
diff --git a/src/server/gdb_server.c b/src/server/gdb_server.c
index 40ab1c4..3a390de 100644
--- a/src/server/gdb_server.c
+++ b/src/server/gdb_server.c
@@ -1089,7 +1089,7 @@ static int gdb_get_register_packet(struct connection
*connection,
if (reg_list_size = reg_num) {
LOG_ERROR(gdb requested a non-existing register);
- exit(-1);
+ return ERROR_SERVER_REMOTE_CLOSED;
}
if (!reg_list[reg_num]-valid)
--
--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
___
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel
[OpenOCD-devel] [PATCH]: 906c3b0 armv7m: detect floating point feature
This is an automated email from Gerrit.
Mathias Küster (kes...@freenet.de) just uploaded a new patch set to Gerrit,
which you can find at http://openocd.zylin.com/524
-- gerrit
commit 906c3b0d3638e71ba823f91341693f393aff0078
Author: Mathias K kes...@freenet.de
Date: Thu Mar 15 14:58:32 2012 +0100
armv7m: detect floating point feature
This patch add fp feature detection on cortex-m4.
Change-Id: I99e9d1bf5534630a22b8ad9c878165683db2d0ba
Signed-off-by: Mathias K kes...@freenet.de
diff --git a/src/target/armv7m.c b/src/target/armv7m.c
index e9862e9..426e928 100644
--- a/src/target/armv7m.c
+++ b/src/target/armv7m.c
@@ -632,6 +632,7 @@ int armv7m_init_arch_info(struct target *target, struct
armv7m_common *armv7m)
struct arm *arm = armv7m-arm;
armv7m-common_magic = ARMV7M_COMMON_MAGIC;
+ armv7m-fp_feature = FP_NONE;
arm-core_type = ARM_MODE_THREAD;
arm-arch_info = armv7m;
diff --git a/src/target/armv7m.h b/src/target/armv7m.h
index 18515ac..6002b57 100644
--- a/src/target/armv7m.h
+++ b/src/target/armv7m.h
@@ -154,6 +154,11 @@ enum {
ARMV7M_LAST_REG,
};
+enum {
+ FP_NONE = 0,
+ FPv4_SP,
+};
+
#define ARMV7M_COMMON_MAGIC 0x2A452A45
struct armv7m_common {
@@ -165,6 +170,8 @@ struct armv7m_common {
int exception_number;
struct adiv5_dap dap;
+ int fp_feature;
+
uint32_t demcr;
/* Direct processor core register read and writes */
diff --git a/src/target/cortex_m.c b/src/target/cortex_m.c
index 76e197c..488899c 100644
--- a/src/target/cortex_m.c
+++ b/src/target/cortex_m.c
@@ -1756,13 +1756,20 @@ fail1:
*/
}
+#define MVFR0 0xe000ef40
+#define MVFR1 0xe000ef44
+
+#define MVFR0_DEFAULT_M4 0x10110021
+#define MVFR1_DEFAULT_M4 0x1111
+
int cortex_m3_examine(struct target *target)
{
int retval;
- uint32_t cpuid, fpcr;
+ uint32_t cpuid, fpcr, mvfr0, mvfr1;
int i;
struct cortex_m3_common *cortex_m3 = target_to_cm3(target);
struct adiv5_dap *swjdp = cortex_m3-armv7m.dap;
+ struct armv7m_common *armv7m = target_to_armv7m(target);
retval = ahbap_debugport_init(swjdp);
if (retval != ERROR_OK)
@@ -1783,6 +1790,17 @@ int cortex_m3_examine(struct target *target)
i, (uint8_t)((cpuid 20) 0xf),
(uint8_t)((cpuid 0) 0xf));
LOG_DEBUG(cpuid: 0x%8.8 PRIx32 , cpuid);
+ /* test for floating point feature on cortex-m4 */
+ if (i == 4) {
+ target_read_u32(target, MVFR0, mvfr0);
+ target_read_u32(target, MVFR1, mvfr1);
+
+ if ((mvfr0 == MVFR0_DEFAULT_M4) (mvfr1 ==
MVFR1_DEFAULT_M4)) {
+ LOG_DEBUG(Cortex-M%d floating point feature
FPv4_SP found, i);
+ armv7m-fp_feature = FPv4_SP;
+ }
+ }
+
/* NOTE: FPB and DWT are both optional. */
/* Setup FPB */
--
--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
___
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel
[OpenOCD-devel] [PATCH]: 0e5f770 stm32: Update register read/write to the register definition.
This is an automated email from Gerrit. Mathias Küster (kes...@freenet.de) just uploaded a new patch set to Gerrit, which you can find at http://openocd.zylin.com/525 -- gerrit commit 0e5f770a2a74ddd981a52d10f6359d2c27642e86 Author: Mathias K kes...@freenet.de Date: Thu Mar 15 15:25:27 2012 +0100 stm32: Update register read/write to the register definition. This patch fix the register index on read/write register. Change-Id: I7b52a927a48259d6f497ac0f474aff7ff1529e9a Signed-off-by: Mathias K kes...@freenet.de diff --git a/src/target/stm32_stlink.c b/src/target/stm32_stlink.c index 7bec73f..7336b14 100644 --- a/src/target/stm32_stlink.c +++ b/src/target/stm32_stlink.c @@ -71,10 +71,14 @@ static int stm32_stlink_load_core_reg_u32(struct target *target, LOG_DEBUG(load from core reg %i value 0x% PRIx32 , (int)num, *value); break; - case 33: - case 64 ... 96: + case ARMV7M_FPSID: + case ARMV7M_FPEXC: + *value = 0; + break; + + case ARMV7M_FPSCR: /* Floating-point Status and Registers */ - retval = target_write_u32(target, ARMV7M_SCS_DCRSR, num); + retval = target_write_u32(target, ARMV7M_SCS_DCRSR, 33); if (retval != ERROR_OK) return retval; retval = target_read_u32(target, ARMV7M_SCS_DCRDR, value); @@ -83,6 +87,21 @@ static int stm32_stlink_load_core_reg_u32(struct target *target, LOG_DEBUG(load from core reg %i value 0x% PRIx32 , (int)num, *value); break; + case ARMV7M_S0 ... ARMV7M_S31: + /* Floating-point Status and Registers */ + retval = target_write_u32(target, ARMV7M_SCS_DCRSR, num-ARMV7M_S0+64); + if (retval != ERROR_OK) + return retval; + retval = target_read_u32(target, ARMV7M_SCS_DCRDR, value); + if (retval != ERROR_OK) + return retval; + LOG_DEBUG(load from core reg %i value 0x% PRIx32 , (int)num, *value); + break; + + case ARMV7M_D0 ... ARMV7M_D15: + value = 0; + break; + case ARMV7M_PRIMASK: case ARMV7M_BASEPRI: case ARMV7M_FAULTMASK: @@ -164,18 +183,35 @@ static int stm32_stlink_store_core_reg_u32(struct target *target, LOG_DEBUG(write core reg %i value 0x% PRIx32 , (int)num, value); break; - case 33: - case 64 ... 96: + case ARMV7M_FPSID: + case ARMV7M_FPEXC: + break; + + case ARMV7M_FPSCR: /* Floating-point Status and Registers */ retval = target_write_u32(target, ARMV7M_SCS_DCRDR, value); if (retval != ERROR_OK) return retval; - retval = target_write_u32(target, ARMV7M_SCS_DCRSR, num | (116)); + retval = target_write_u32(target, ARMV7M_SCS_DCRSR, 33 | (116)); if (retval != ERROR_OK) return retval; LOG_DEBUG(write core reg %i value 0x% PRIx32 , (int)num, value); break; + case ARMV7M_S0 ... ARMV7M_S31: + /* Floating-point Status and Registers */ + retval = target_write_u32(target, ARMV7M_SCS_DCRDR, value); + if (retval != ERROR_OK) + return retval; + retval = target_write_u32(target, ARMV7M_SCS_DCRSR, (num-ARMV7M_S0+64) | (116)); + if (retval != ERROR_OK) + return retval; + LOG_DEBUG(write core reg %i value 0x% PRIx32 , (int)num, value); + break; + + case ARMV7M_D0 ... ARMV7M_D15: + break; + case ARMV7M_PRIMASK: case ARMV7M_BASEPRI: case ARMV7M_FAULTMASK: -- -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] Bug in mips32_pracc_read_mem32
Hi，
Date: Thu, 15 Mar 2012 19:11:45 +0100
From: drasko.drasko...@gmail.com
To: salva...@telecable.es
CC: openocd-devel@lists.sourceforge.net
Subject: Re: [OpenOCD-devel] Bug in mips32_pracc_read_mem32
On Thu, Mar 15, 2012 at 6:44 PM, salvador salva...@telecable.es wrote:
On 03/14/2012 07:24 PM, salvador wrote:
1.- There is no call to mips32_pracc_read_mem32() in
mips_m4k_read_memory().
Yes, there is. It is called implicitly, by mips32_pracc_read_mem().
Anyway, count parameter is propagated.
Looking in the mips_m4k_read_memory() you can easily see that it is
used to count __BYTES__ :
t = malloc(count * size * sizeof(uint8_t));
2.- I guess you mean a call to mips32_pracc_read_mem(). This function
has a parameter int size.
Yes. Size of variable does not meter. It is a placeholder for integer
- a number. This number, however, can be a number of apples, ducks or,
as in this case - bytes.
3.- The function mips32_pracc_read_mem() is defined in mips32_pracc.c
. This function calls mips32_pracc_read_mem32() only if the
parameter size is 4 (WORD) and count 1.
Yes. 'size' is the acces width : w, hw or b. Independantly, 'count'
is nb of bytes.
i think 'count' is not nb of bytes. see the followin code from the function ――
mips_m4k_read_memoryfor(i = 0; i (count*size); i += size) {
switch(size){ case 4: t32 =
le_to_h_u32(buffer[i]);
target_buffer_set_u32(target,buffer[i], t32); break;
..
if 'count' is really nb of bytes, i think the code should be the follwing
instead of the above: for(i = 0; i (count); i += size)
...In my opinion , for a word access , 'count' is nb
of wordfor a halfword access , 'count' is nb of halfword
for a byte access , 'count' is nb of byte
'size' parameter is used in the switch in mips32_pracc_read_mem() in
order to call correct miniprogram - one that reads w, hw or b.
4.- In function mips32_pracc_read_mem32(), in the call to
mips32_pracc_exec() the variable bytesread is used as an index in a
matrix of uint32_t (WORDS).
Sorry but i can not find anything in the code that says bytesread or
count counts bytes. But WORDS, yes.
Sorry, but everything is there, written black on white (or whatever
syntax coloring you use ;)).
You'll just have to inspect the code more carefully and follow the
call graph. Use cscope, if that will help you.
As a hint follow the propagation of count parameter - find it's
origin and you'll see that it holds a nb of octets.
BR,
Drasko
--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
___
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel
--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure___
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel
