[Openocd-development] Compilation Warnings on OS X 10.5
Hi,
I received a number of -Wshadow related warnings (treated as errors) while
trying to build on OS X Leopard. In addition, there were two miscellaneous
other warnings in the flash drivers. Attached are two patches which correct
these issues and the commit messages to accompany them.
My system has the following configuration (taken from uname -a):
Darwin 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul 15 16:55:01 PDT 2009;
root:xnu-1228.15.4~1/RELEASE_I386 i386
=== Werror_patch.txt Commit Message ===
compilation: fixes for -Wshadow warnings on OS X
These changes fix -Wshadow compilation warnings on OS X 10.5.8
Compiled with the following configure command:
../configure --prefix=/usr/local --enable-maintainer-mode --enable-jlink
--enable-ft2232_libftdi
=== flash_patch.txt Commit Message ===
compilation: fixes for flash driver warnings on OS X
These changes fix two compilation warnings on OS X 10.5.8:
../../../../src/flash/nor/at91sam3.c:2767: warning: redundant redeclaration
of 'at91sam3_flash'
../../../../src/flash/nor/at91sam3.c:101: warning: previous declaration of
'at91sam3_flash' was here
and
../../../../src/flash/nor/stmsmi.c:205: warning: format not a string literal
and no format arguments
Compiled with the following configure command:
../configure --prefix=/usr/local --enable-maintainer-mode --enable-jlink
--enable-ft2232_libftdi
===
Andrew
diff --git a/src/flash/nor/lpc2900.c b/src/flash/nor/lpc2900.c
index 1c1c90f..7bb9f14 100644
--- a/src/flash/nor/lpc2900.c
+++ b/src/flash/nor/lpc2900.c
@@ -184,7 +184,7 @@ static uint32_t lpc2900_run_bist128(struct flash_bank *bank,
uint32_t addr_from, uint32_t addr_to,
uint32_t (*signature)[4] );
static uint32_t lpc2900_address2sector(struct flash_bank *bank, uint32_t
offset);
-static uint32_t lpc2900_calc_tr( uint32_t clock, uint32_t time );
+static uint32_t lpc2900_calc_tr(uint32_t clock_var, uint32_t time_var);
/*** Helper functions **/
diff --git a/src/helper/fileio.h b/src/helper/fileio.h
index fa499ab..f37dbd1 100644
--- a/src/helper/fileio.h
+++ b/src/helper/fileio.h
@@ -53,7 +53,7 @@ struct fileio
};
int fileio_open(struct fileio *fileio,
- const char *url, enum fileio_access access, enum fileio_type type);
+ const char *url, enum fileio_access access_type, enum fileio_type type);
int fileio_close(struct fileio *fileio);
int fileio_seek(struct fileio *fileio, size_t position);
diff --git a/src/openocd.c b/src/openocd.c
index 109f0e1..62b2238 100644
--- a/src/openocd.c
+++ b/src/openocd.c
@@ -267,7 +267,7 @@ struct command_context *setup_command_handler(Jim_Interp
*interp)
struct command_context *cmd_ctx = command_init(startup, interp);
/* register subsystem commands */
- typedef int (*command_registrant_t)(struct command_context *cmd_ctx);
+ typedef int (*command_registrant_t)(struct command_context
*cmd_ctx_value);
static const command_registrant_t command_registrants[] = {
openocd_register_commands,
server_register_commands,
diff --git a/src/target/arm_dpm.h b/src/target/arm_dpm.h
index 5d75ed4..e180807 100644
--- a/src/target/arm_dpm.h
+++ b/src/target/arm_dpm.h
@@ -100,7 +100,7 @@ struct arm_dpm {
* must currently be disabled. Indices 0..15 are used for
* breakpoints; indices 16..31 are for watchpoints.
*/
- int (*bpwp_enable)(struct arm_dpm *, unsigned index,
+ int (*bpwp_enable)(struct arm_dpm *, unsigned index_value,
uint32_t addr, uint32_t control);
/**
@@ -108,7 +108,7 @@ struct arm_dpm {
* hardware control registers. Indices are the same ones
* accepted by bpwp_enable().
*/
- int (*bpwp_disable)(struct arm_dpm *, unsigned index);
+ int (*bpwp_disable)(struct arm_dpm *, unsigned index_value);
/* The breakpoint and watchpoint arrays are private to the
* DPM infrastructure. There are nbp indices in the dbp
diff --git a/src/target/mips32_pracc.h b/src/target/mips32_pracc.h
index f2c2680..b207a5b 100644
--- a/src/target/mips32_pracc.h
+++ b/src/target/mips32_pracc.h
@@ -45,7 +45,7 @@ int mips32_pracc_read_mem(struct mips_ejtag *ejtag_info,
int mips32_pracc_write_mem(struct mips_ejtag *ejtag_info,
uint32_t addr, int size, int count, void *buf);
int mips32_pracc_fastdata_xfer(struct mips_ejtag *ejtag_info, struct
working_area *source,
- int write, uint32_t addr, int count, uint32_t *buf);
+ int write_t, uint32_t addr, int count, uint32_t *buf);
int mips32_pracc_read_regs(struct mips_ejtag *ejtag_info, uint32_t *regs);
int mips32_pracc_write_regs(struct mips_ejtag *ejtag_info, uint32_t *regs);
diff --git a/src/target/mips_ejtag.h b/src/target/mips_ejtag.h
index 694cb34..a4430b6 100644
--- a/src/target/mips_ejtag.h
+++
Re: [Openocd-development] IFYI -- CEpick-D info (for recent TI chips)
On 26.12.2010 19:41, David Brownell wrote: via Google search, I found the following, which, in conjunction with the Cortex-A9 reference manuals from ARM, may be of interest to folk looking at OMAP4 and other recent TI chips for OpenOCD; it looked to answer some of the questions I've heard on this list. http://processors.wiki.ti.com/index.php/ICEPICK (Also of course you'd use the ARMv7A manual too, but large chunks of that already have debug support in OpenOCD, ( ... for Cortex-A8 cores as on OMAP3, (plus ARMv6/ARM11). Linked from that page is a PDF document http://processors.wiki.ti.com/images/f/f6/Router_Scan_Sequence-ICEpick-D.pdf which may be more information than was public when ICEPICK-C support was added to OpenOCD, enabling DaVinci and OMAP3 operations. (And FWIW, the link-in-a-TAP sequences looked similar at first glance.) The public OMAP4430 reference manual tells which cores are at which address on the ICEpick-D ... e.g. the Cortex-A9 DAP is #9, the Cortex-M3 cores (Ducati) are at #4 and #5, and there are even two ARM968 cores at addresses #2 and #3 (presumably for what older OMAPs used ARM7 cores). (Plus of course the C6000x+ DSP.) Not clear which of those we should be configuring into our scan_chain, maybe just the A9 to start. (That will keep scans faster, and reduce power usage during debug.) I'm thinking the current ICEpick support may need to be packaged as specifically ICEpick-C support; maybe some can be shared with ICEPick-D, I've not investigated yet. Maybe this mail from the PandaBoard (OMAP4) mailing list might be interesting here, too: http://groups.google.com/group/pandaboard/msg/2a4eb67a994b9966 Best regards Dirk ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Compilation Warnings on OS X 10.5
Give HEAD of master a try now. I had to fix some other stuff first though, see latest commits. Nice finds! Thanks! -- Øyvind Harboe Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 87 40 27 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] CORTEX A8: Fix broken CPU identification
This patch fixes the issue where the OMAP CPU (and possibly others) was mistaken
for iMX51 and therefore had misadjusted debug base.
Signed-off-by: Marek Vasut marek.va...@gmail.com
---
src/target/arm_adi_v5.c | 20 +---
1 files changed, 17 insertions(+), 3 deletions(-)
diff --git a/src/target/arm_adi_v5.c b/src/target/arm_adi_v5.c
index 69a3ce7..7df0d4f 100644
--- a/src/target/arm_adi_v5.c
+++ b/src/target/arm_adi_v5.c
@@ -1013,10 +1013,11 @@ is_dap_cid_ok(uint32_t cid3, uint32_t cid2, uint32_t
cid1, uint32_t cid0)
struct broken_cpu {
uint32_tdbgbase;
uint32_tapid;
+ uint32_tidcode;
uint32_tcorrect_dbgbase;
char*model;
} broken_cpus[] = {
- { 0x8000, 0x04770002, 0x6000, imx51 },
+ { 0x8000, 0x04770002, 0x1ba00477, 0x6000, imx51 },
};
int dap_get_debugbase(struct adiv5_dap *dap, int apsel,
@@ -1025,7 +1026,7 @@ int dap_get_debugbase(struct adiv5_dap *dap, int apsel,
uint32_t apselold;
int retval;
unsigned int i;
- uint32_t dbgbase, apid;
+ uint32_t dbgbase, apid, idcode;
/* AP address is in bits 31:24 of DP_SELECT */
if (apsel = 256)
@@ -1044,10 +1045,23 @@ int dap_get_debugbase(struct adiv5_dap *dap, int apsel,
if (retval != ERROR_OK)
return retval;
+ /* Excavate the device ID code */
+ struct jtag_tap *tap = dap-jtag_info-tap;
+ while (tap != NULL) {
+ if (tap-hasidcode) {
+ idcode = tap-idcode;
+ break;
+ }
+ tap = tap-next_tap;
+ }
+ if (tap == NULL || !tap-hasidcode)
+ return ERROR_OK;
+
/* Some CPUs are messed up, so fixup if needed. */
for (i = 0; i sizeof(broken_cpus)/sizeof(struct broken_cpu); i++)
if (broken_cpus[i].dbgbase == dbgbase
- broken_cpus[i].apid == apid) {
+ broken_cpus[i].apid == apid
+ broken_cpus[i].idcode == idcode) {
LOG_WARNING(Found broken CPU (%s), trying to fixup
ROM Table location from 0x%08x to 0x%08x,
broken_cpus[i].model, dbgbase,
--
1.7.2.3
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] CORTEX A8: Fix broken CPU identification
Merged. Thanks! Took it for a spin on AM3517 and that target is no longer incorrectly identified as an imx51. That target still needs work though: oyv...@titan:~/workspace/openocd$ openocd -c interface ZY1000; zy1000_server 127.0.0.1;jtag_khz 50 -f board/am3517evm.cfg Open On-Chip Debugger 0.5.0-dev-00682-g0136977 (2010-12-30-08:23) Licensed under GNU GPL v2 For bug reports, read http://openocd.berlios.de/doc/doxygen/bugs.html Warn : Adapter driver 'ZY1000' did not declare which transports it allows; assuming legacy JTAG-only Info : only one transport option; autoselect 'jtag' 50 kHz 10 kHz trst_only separate trst_push_pull jtag_speed 6000 = JTAG clk=10 kHz Info : clock speed 10 kHz Info : JTAG tap: am35x.jrc tap/device found: 0x0b7ae02f (mfg: 0x017, part: 0xb7ae, ver: 0x0) Info : JTAG tap: am35x.dap enabled Info : am35x.cpu: hardware has 6 breakpoints, 2 watchpoints Error: JTAG-DP STICKY ERROR Error: MEM_AP_CSW 0x2800042, MEM_AP_TAR 0x54011140 Error: JTAG-DP STICKY ERROR Error: MEM_AP_CSW 0x2800042, MEM_AP_TAR 0x54011140 Error: JTAG-DP STICKY ERROR Error: MEM_AP_CSW 0x2800042, MEM_AP_TAR 0x54011140 Error: JTAG-DP STICKY ERROR -- Øyvind Harboe Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 87 40 27 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [beagleboard] Flyswatter with XM
Try with OpenOCD master branch now. Should be fixed. -- Øyvind Harboe Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 87 40 27 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] CORTEX A8: Fix broken CPU identification
On Thursday 30 December 2010 08:27:52 Øyvind Harboe wrote: Merged. Thanks! Took it for a spin on AM3517 and that target is no longer incorrectly identified as an imx51. That target still needs work though: oyv...@titan:~/workspace/openocd$ openocd -c interface ZY1000; zy1000_server 127.0.0.1;jtag_khz 50 -f board/am3517evm.cfg Open On-Chip Debugger 0.5.0-dev-00682-g0136977 (2010-12-30-08:23) Licensed under GNU GPL v2 For bug reports, read http://openocd.berlios.de/doc/doxygen/bugs.html Warn : Adapter driver 'ZY1000' did not declare which transports it allows; assuming legacy JTAG-only Info : only one transport option; autoselect 'jtag' 50 kHz 10 kHz trst_only separate trst_push_pull jtag_speed 6000 = JTAG clk=10 kHz Info : clock speed 10 kHz Info : JTAG tap: am35x.jrc tap/device found: 0x0b7ae02f (mfg: 0x017, part: 0xb7ae, ver: 0x0) Info : JTAG tap: am35x.dap enabled Info : am35x.cpu: hardware has 6 breakpoints, 2 watchpoints Error: JTAG-DP STICKY ERROR Error: MEM_AP_CSW 0x2800042, MEM_AP_TAR 0x54011140 Error: JTAG-DP STICKY ERROR Error: MEM_AP_CSW 0x2800042, MEM_AP_TAR 0x54011140 Error: JTAG-DP STICKY ERROR Error: MEM_AP_CSW 0x2800042, MEM_AP_TAR 0x54011140 Error: JTAG-DP STICKY ERROR These errors here, right ... need to investigate. Any pointers possibly ? ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] AM3517 problems
oyv...@titan:~/workspace/openocd$ openocd -c interface ZY1000; zy1000_server 127.0.0.1;jtag_khz 50 -f board/am3517evm.cfg Open On-Chip Debugger 0.5.0-dev-00682-g0136977 (2010-12-30-08:23) Licensed under GNU GPL v2 For bug reports, read http://openocd.berlios.de/doc/doxygen/bugs.html Warn : Adapter driver 'ZY1000' did not declare which transports it allows; assuming legacy JTAG-only Info : only one transport option; autoselect 'jtag' 50 kHz 10 kHz trst_only separate trst_push_pull jtag_speed 6000 = JTAG clk=10 kHz Info : clock speed 10 kHz Info : JTAG tap: am35x.jrc tap/device found: 0x0b7ae02f (mfg: 0x017, part: 0xb7ae, ver: 0x0) Info : JTAG tap: am35x.dap enabled Info : am35x.cpu: hardware has 6 breakpoints, 2 watchpoints Error: JTAG-DP STICKY ERROR Error: MEM_AP_CSW 0x2800042, MEM_AP_TAR 0x54011140 Error: JTAG-DP STICKY ERROR Error: MEM_AP_CSW 0x2800042, MEM_AP_TAR 0x54011140 Error: JTAG-DP STICKY ERROR Error: MEM_AP_CSW 0x2800042, MEM_AP_TAR 0x54011140 Error: JTAG-DP STICKY ERROR These errors here, right ... need to investigate. Any pointers possibly ? Sorry no. Fire up the debugger on OpenOCD and see what turns up? Try an older version of OpenOCD to see if it is a regression? -- Øyvind Harboe Can Zylin Consulting help on your project? US toll free 1-866-980-3434 / International +47 51 87 40 27 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
