Re: [Openocd-development] RFC: struct cleanup and more
On Jun 2, 2009, at 9:42 PM, Michael Bruck wrote: On Wed, Jun 3, 2009 at 6:38 AM, Rick Altherr kc8...@kc8apf.net wrote: I'm speaking in general terms, but, yes, simple accessors can definitely be a problem depending how the program is structured. I've seen many a game engine written in C++ with full encapsulation where a statistical profile shows nearly all of the time in the prolog and epilog. The actual accessor doesn't cost anything (maybe 1-2 instructions), but the setup for the stack frame kills it. A stack frame setup forces accesses to memory so even though the number of instructions is small, the impact on the performance is significant. Having the instructions sit in the icache does help in terms of instruction fetch times, but the data operations involve a read-modify-write pattern which won't sit well in many cache structures. To be entirely fair, this problem with accessors mainly shows up when there are a large number of instances of the object and the accessor is being called as part of a traversal over the instances. The typical solution is to allow direct access to the data member to avoid the stack frame setup/teardown overhead. Wouldn't you have the accessor as inlined member function in C++ (while keeping the data private)? Michael A good C++ compiler will automatically inline such functions at sufficient levels of optimization. Of course, there are limits as to what most compilers will inline and so this can really bite you. I've seen this fairly frequently on a lot of different source bases. Of course, everyone should be following the optimization creed: measure first, then optimize what is taking time. Otherwise you end up doing things like getting rid of all your accessor methods and find out it doesn't make any difference. -- Rick Altherr kc8...@kc8apf.net He said he hadn't had a byte in three days. I had a short, so I split it with him. -- Unsigned smime.p7s Description: S/MIME cryptographic signature ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch] Files that point to stm32.cfg
While it appears I made this realization erroneously with regard to the original thread, I believe the attached patch fixes the real problem that it made me spot. Are these files being used? Hopefully they will be at some point. Duane did this a loong time a go and this is part of his greater vision to have more hefty target peripheral support. -- Øyvind Harboe Embedded software and hardware consulting services http://consulting.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch] Files that point to stm32.cfg
On Wed, 2009-06-03 at 08:18 +0200, Øyvind Harboe wrote: While it appears I made this realization erroneously with regard to the original thread, I believe the attached patch fixes the real problem that it made me spot. Are these files being used? Hopefully they will be at some point. Duane did this a loong time a go and this is part of his greater vision to have more hefty target peripheral support. I do like the general flavor of it. I have started to sketch out a STR91x family tree, but it is not usable yet. Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch] Files that point to stm32.cfg
On Wed, Jun 3, 2009 at 8:32 AM, Zach Welch z...@superlucidity.net wrote: On Wed, 2009-06-03 at 08:18 +0200, Øyvind Harboe wrote: While it appears I made this realization erroneously with regard to the original thread, I believe the attached patch fixes the real problem that it made me spot. Are these files being used? Hopefully they will be at some point. Duane did this a loong time a go and this is part of his greater vision to have more hefty target peripheral support. I do like the general flavor of it. I have started to sketch out a STR91x family tree, but it is not usable yet. The next step in Duane's plan is to create a web interface for these target specific things :-) -- Øyvind Harboe Embedded software and hardware consulting services http://consulting.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch] Files that point to stm32.cfg
On Wed, 2009-06-03 at 08:33 +0200, Øyvind Harboe wrote: On Wed, Jun 3, 2009 at 8:32 AM, Zach Welch z...@superlucidity.net wrote: On Wed, 2009-06-03 at 08:18 +0200, Øyvind Harboe wrote: While it appears I made this realization erroneously with regard to the original thread, I believe the attached patch fixes the real problem that it made me spot. Are these files being used? Hopefully they will be at some point. Duane did this a loong time a go and this is part of his greater vision to have more hefty target peripheral support. I do like the general flavor of it. I have started to sketch out a STR91x family tree, but it is not usable yet. The next step in Duane's plan is to create a web interface for these target specific things :-) I am starting to love it. Duane, Did you write this plan up? Got Links? If not, care to revisit the vision in a new thread on the list or a patch to The Manual? :) --Z ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] cif_probe failure
jie.zeng wrote: If we want to access a register in the board, we must pass the base address which tell cpu where the register reside and a proper offset(depends on bus-width), right? If the offset is not fix the datasheet, how the cpu can access that reg correctly? In my opinion, the base is 0x1000 in this case. The offset(in fact its on-chip addr) from datasheet(flash) are 0x2aa(word) and 0x555(byte). So CPU write memory should use the address 0x12AA or 0x1555. But now cpu use a wrong address which is 0x1554. The result is that cannot get right ManufacturerID and probe failure. You still have not described (or I missed it) your flash setup: what kind of flash, mode (8/16 bit), bus width of the CPU, and how it is all connected together. Also, what flash bank configuration are you using in your openocd config? Without that information, it is impossible to tell what addresses are needed to access the flash. cu Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] TRST asserted callback fixes
This patch cleans up where the TRST asserted callback is invoked.
The old code invoked the callback too many times(harmless) and
was very unclear.
There are now three clear cases when TRST asserted is invoked.
The event is invoked *after* TRST is asserted(or queued rather, which
could be immediately for synchronous execution).
- TLR reset
- SRST pulls TRST
- TRST asserted
Comments?
--
Øyvind Harboe
Embedded software and hardware consulting services
http://consulting.zylin.com
Index: C:/workspace/openocd/src/jtag/jtag.c
===
--- C:/workspace/openocd/src/jtag/jtag.c(revision 2032)
+++ C:/workspace/openocd/src/jtag/jtag.c(working copy)
@@ -393,9 +393,6 @@
jtag_error=ERROR_JTAG_TRST_ASSERTED;
return;
}
-
- if (cmd_queue_end_state == TAP_RESET)
- jtag_call_event_callbacks(JTAG_TRST_ASSERTED);
}
static void jtag_prelude(tap_state_t state)
@@ -601,6 +598,8 @@
retval=interface_jtag_add_tlr();
if (retval!=ERROR_OK)
jtag_error=retval;
+
+ jtag_call_event_callbacks(JTAG_TRST_ASSERTED);
}
void jtag_add_pathmove(int num_states, const tap_state_t *path)
@@ -760,7 +759,6 @@
LOG_DEBUG(JTAG reset with RESET instead of TRST);
jtag_add_end_state(TAP_RESET);
jtag_add_tlr();
- jtag_call_event_callbacks(JTAG_TRST_ASSERTED);
return;
}
Index: C:/workspace/openocd/src/jtag/jtag.h
===
--- C:/workspace/openocd/src/jtag/jtag.h(revision 2032)
+++ C:/workspace/openocd/src/jtag/jtag.h(working copy)
@@ -218,6 +218,16 @@
LINE_PUSH_PULL = 0x1,
};
+/*
+ * There are three cases when JTAG_TRST_ASSERTED callback is invoked. The
+ * event is invoked *after* TRST is asserted. It is illegal to communicate
+ * with the JTAG interface during the callback(as there is currently
+ * a queue being built).
+ * - TMS reset
+ * - SRST pulls TRST
+ * - TRST asserted
+ *
+ **/
enum jtag_event {
JTAG_TRST_ASSERTED
};
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] cif_probe failure
Hello, Thank you for your time. You still have not described (or I missed it) your flash setup: what kind of flash, mode (8/16 bit), bus width of the CPU, and how it is all connected together. Also, what flash bank configuration are you using in your openocd config? Without that information, it is impossible to tell what addresses are needed to access the flash. Sorry, I must make some mistakes and confused about some basic concepts now. First let me list what I know. My board used vitesse chip and the core is ARM926ejs. From the pin table, there are 8 bit for data bus and 24 bit for address bus. Q: what kind of flash, mode (8/16 bit)? FLASH is EN29LV640T/B, 64 Megabit (8M x 8-bit / 4M x 16-bit) Flash Memory Boot Sector Flash Memory. The mode is 8-bit I think since it connected DQ0~DQ7 as data channel. Q: bus width of the CPU? You mean address bus width? If so, it's configurable and the value is 8 or 16 bit. All of the addr pin(24) connect with flash. I set this bus width to 16 bit through change a register. Now start to talk the openocd config. flash bank # chip_width(addr width) is 16 bit, bus_width(data width) is 8 bit flash bank cfi 0x1000 0x800 2 1 0 Is it correct? In fact, I am not very sure the meaning of chip_width and bus_width in bank structure from source code. With this config, cfi_probe() failed. I think its addresses' problem( maybe may config's ) and I set the value manually and it succeed. Regards, -- ZJ ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Change jtag illegal args error into assert()
Committed 2033
Convert obscure illegal arguments case to an assert rather than
runtime error. I have never seen this error in OpenOCD btw...
--
Øyvind Harboe
Embedded software and hardware consulting services
http://consulting.zylin.com
Index: C:/workspace/openocd/src/jtag/jtag.c
===
--- C:/workspace/openocd/src/jtag/jtag.c(revision 2032)
+++ C:/workspace/openocd/src/jtag/jtag.c(working copy)
@@ -393,9 +393,6 @@
jtag_error=ERROR_JTAG_TRST_ASSERTED;
return;
}
-
- if (cmd_queue_end_state == TAP_RESET)
- jtag_call_event_callbacks(JTAG_TRST_ASSERTED);
}
static void jtag_prelude(tap_state_t state)
@@ -601,6 +598,8 @@
retval=interface_jtag_add_tlr();
if (retval!=ERROR_OK)
jtag_error=retval;
+
+ jtag_call_event_callbacks(JTAG_TRST_ASSERTED);
}
void jtag_add_pathmove(int num_states, const tap_state_t *path)
@@ -760,7 +759,6 @@
LOG_DEBUG(JTAG reset with RESET instead of TRST);
jtag_add_end_state(TAP_RESET);
jtag_add_tlr();
- jtag_call_event_callbacks(JTAG_TRST_ASSERTED);
return;
}
Index: C:/workspace/openocd/src/jtag/jtag.h
===
--- C:/workspace/openocd/src/jtag/jtag.h(revision 2032)
+++ C:/workspace/openocd/src/jtag/jtag.h(working copy)
@@ -218,6 +218,16 @@
LINE_PUSH_PULL = 0x1,
};
+/*
+ * There are three cases when JTAG_TRST_ASSERTED callback is invoked. The
+ * event is invoked *after* TRST is asserted. It is illegal to communicate
+ * with the JTAG interface during the callback(as there is currently
+ * a queue being built).
+ * - TMS reset
+ * - SRST pulls TRST
+ * - TRST asserted
+ *
+ **/
enum jtag_event {
JTAG_TRST_ASSERTED
};
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] cif_probe failure
zengjie wrote: My board used vitesse chip and the core is ARM926ejs. From the pin table, there are 8 bit for data bus and 24 bit for address bus. Q: what kind of flash, mode (8/16 bit)? FLASH is EN29LV640T/B, 64 Megabit (8M x 8-bit / 4M x 16-bit) Flash Memory Boot Sector Flash Memory. The mode is 8-bit I think since it connected DQ0~DQ7 as data channel. You are using an 16-bit flash in 8-bit mode, making it effectively an 8-bit flash with shifted address lines. In that case, you need the x16_as_x8 option, which explains why your probe fails. Q: bus width of the CPU? You mean address bus width? If so, it's configurable and the value is 8 or 16 bit. All of the addr pin(24) connect with flash. I set this bus width to 16 bit through change a register. This can not work if the flash is connected with only 8 data lines. If only DQ0-DQ7 is connected, you need to configure the CPU bus to be 8 bits wide when accessing the flash. Now start to talk the openocd config. flash bank # chip_width(addr width) is 16 bit, bus_width(data width) is 8 bit flash bank cfi 0x1000 0x800 2 1 0 Is it correct? In fact, I am not very sure the meaning of chip_width and bus_width in bank structure from source code. chip_width is 1, since 1 byte (8 bits) are connected, and bus_width should be 1, too. Furthermore, you need the x16_as_x8 option to tell openocd that the flash uses shifted address lines. I hope the address lines are connected correctly (with A-1 on the flash connected to A0 on the CPU)? cu Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD now available on FreeBSD
On Wednesday 03 June 2009, CeDeROM wrote: Got patches for us? :) Do You mean patches for the other cables or to build the package? If You want to build the program, update the port tree with portsnap and type: I suspect he meant patches against the current OpenOCD tree to make sure your FreeBSD support is only *packaging* work. That is, it should be possible to pull down the current source (using SVN) and build it on BSD without any source code changes. If it's not possible, that's a bug ... and one that's better fixed upstream, than as part of packaging. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [path 1/5] openocd.texi - str9xpec and mflash updates
Convert the str9xpec driver info to use @deffn; alphabetize;
add the missing part_id command.
Convert the mflash support to use @deffn; alphabetize.
---
doc/openocd.texi | 159 -
1 file changed, 85 insertions(+), 74 deletions(-)
Convert the str9xpec driver info to use @deffn; alphabetize;
add the missing part_id command.
Convert the mflash support to use @deffn; alphabetize.
---
doc/openocd.texi | 159 -
1 file changed, 85 insertions(+), 74 deletions(-)
--- a/doc/openocd.texi
+++ b/doc/openocd.texi
@@ -2953,112 +2953,123 @@ When performing a unlock remember that y
has been locked. Halting the core is not required for the @option{str9xpec} driver
as mentioned above, just issue the commands above manually or from a telnet prompt.
-...@subsubsection str9xpec driver options
-
-...@b{flash bank str9xpec} @var{base} @var{size} 0 0 @var{target}
-...@*before using the flash commands the turbo mode must be enabled using str9xpec
-...@option{enable_turbo} @var{num.}
-
+...@deffn {Flash Driver} str9xpec
Only use this driver for locking/unlocking the device or configuring the option bytes.
Use the standard str9 driver for programming.
+Before using the flash commands the turbo mode must be enabled using the
+...@command{str9xpec enable_turbo} command.
-...@subsubsection str9xpec specific commands
-...@cindex str9xpec specific commands
-These are flash specific commands when using the str9xpec driver.
+Several str9xpec-specific commands are defined:
-...@itemize @bullet
-...@item @b{str9xpec enable_turbo} @var{num}
-...@cindex str9xpec enable_turbo
-...@*enable turbo mode, will simply remove the str9 from the chain and talk
+...@deffn Command {str9xpec disable_turbo} num
+Restore the str9 into JTAG chain.
+...@end deffn
+
+...@deffn Command {str9xpec enable_turbo} num
+Enable turbo mode, will simply remove the str9 from the chain and talk
directly to the embedded flash controller.
-...@item @b{str9xpec disable_turbo} @var{num}
-...@cindex str9xpec disable_turbo
-...@*restore the str9 into JTAG chain.
-...@item @b{str9xpec lock} @var{num}
-...@cindex str9xpec lock
-...@*lock str9 device. The str9 will only respond to an unlock command that will
+...@end deffn
+
+...@deffn Command {str9xpec lock} num
+Lock str9 device. The str9 will only respond to an unlock command that will
erase the device.
-...@item @b{str9xpec unlock} @var{num}
-...@cindex str9xpec unlock
-...@*unlock str9 device.
-...@item @b{str9xpec options_read} @var{num}
-...@cindex str9xpec options_read
-...@*read str9 option bytes.
-...@item @b{str9xpec options_write} @var{num}
-...@cindex str9xpec options_write
-...@*write str9 option bytes.
-...@end itemize
+...@end deffn
-...@subsubsection STR9 option byte configuration
-...@cindex STR9 option byte configuration
+...@deffn Command {str9xpec part_id} num
+Prints the part identifier for bank @var{num}.
+...@end deffn
+
+...@deffn Command {str9xpec options_cmap} num (@option{bank0}|@option{bank1})
+Configure str9 boot bank.
+...@end deffn
+
+...@deffn Command {str9xpec options_lvdsel} num (@option{vdd}|@option{vdd_vddq})
+Configure str9 lvd source.
+...@end deffn
+
+...@deffn Command {str9xpec options_lvdthd} num (@option{2.4v}|@option{2.7v})
+Configure str9 lvd threshold.
+...@end deffn
+
+...@deffn Command {str9xpec options_lvdwarn} bank (@option{vdd}|@option{vdd_vddq})
+Configure str9 lvd reset warning source.
+...@end deffn
+
+...@deffn Command {str9xpec options_read} num
+Read str9 option bytes.
+...@end deffn
+
+...@deffn Command {str9xpec options_write} num
+Write str9 option bytes.
+...@end deffn
+
+...@deffn Command {str9xpec unlock} num
+unlock str9 device.
+...@end deffn
+
+...@end deffn
-...@itemize @bullet
-...@item @b{str9xpec options_cmap} @var{num} @option{bank0}|@option{bank1}
-...@cindex str9xpec options_cmap
-...@*configure str9 boot bank.
-...@item @b{str9xpec options_lvdthd} @var{num} @option{2.4v}|@option{2.7v}
-...@cindex str9xpec options_lvdthd
-...@*configure str9 lvd threshold.
-...@item @b{str9xpec options_lvdsel} @var{num} @option{vdd}|@option{vdd_vddq}
-...@cindex str9xpec options_lvdsel
-...@*configure str9 lvd source.
-...@item @b{str9xpec options_lvdwarn} @var{bank} @option{vdd}|@option{vdd_vddq}
-...@cindex str9xpec options_lvdwarn
-...@*configure str9 lvd reset warning source.
-...@end itemize
@section mFlash
@subsection mFlash Configuration
@cindex mFlash Configuration
-...@b{mflash bank} @var{soc} @var{base} @var{RST pin} @var{target}
-...@cindex mflash bank
-...@*configures a mflash for @var{soc} host bank at
-@var{base}. Pin number format is dependent on host GPIO calling convention.
-Currently, mflash bank support s3c2440 and pxa270.
-(ex. of s3c2440) mflash @var{RST pin} is GPIO B1.
+...@deffn {Config Command} {mflash bank} soc base RST_pin target
+Configures a mflash for @var{soc} host bank at
+address @var{base}.
+The pin number
[Openocd-development] [patch 2/5] openocd.texi - update interface driver section
Convert the Interface/Dongle Config chapter's section
on drivers to use the @deffn syntax, and integrate the
presentation of the driver-specific commands with the
relevant driver. Alphabetize.
Cross-checked against the code ... several adapters were
not listed, and a few commands weren't.
(Maintainers for the versaloon and zy1000 drivers would be
good candidates to add the commands missing from those
sections...)
---
doc/openocd.texi | 393 +
1 file changed, 216 insertions(+), 177 deletions(-)
Convert the Interface/Dongle Config chapter's section
on drivers to use the @deffn syntax, and integrate the
presentation of the driver-specific commands with the
relevant driver. Alphabetize.
Cross-checked against the code ... several adapters were
not listed, and a few commands weren't.
(Maintainers for the versaloon and zy1000 drivers would be
good candidates to add the commands missing from those
sections...)
---
doc/openocd.texi | 393 +
1 file changed, 216 insertions(+), 177 deletions(-)
--- a/doc/openocd.texi
+++ b/doc/openocd.texi
@@ -1302,39 +1302,26 @@ use @var{enable} see these errors report
@node Interface - Dongle Configuration
@chapter Interface - Dongle Configuration
-Interface commands are normally found in an interface configuration
-file which is sourced by your openocd.cfg file. These commands tell
-OpenOCD what type of JTAG dongle you have and how to talk to it.
-...@section Simple Complete Interface Examples
-...@b{a Turtelizer FT2232 Based JTAG Dongle}
-...@verbatim
-#interface
-interface ft2232
-ft2232_device_desc Turtelizer JTAG/RS232 Adapter A
-ft2232_layout turtelizer2
-ft2232_vid_pid 0x0403 0xbdc8
-...@end verbatim
-...@b{a SEGGER Jlink}
-...@verbatim
+JTAG Adapters/Interfaces/Dongles are normally configured
+through commands in an interface configuration
+file which is sourced by your @file{openocd.cfg} file, or
+through a command line @option{-f interface/cfg} option.
+
+...@example
+source [find interface/olimex-jtag-tiny.cfg]
+...@end example
+
+These commands tell
+OpenOCD what type of JTAG adapter you have, and how to talk to it.
+A few cases are so simple that you only need to say what driver to use:
+
+...@example
# jlink interface
interface jlink
-...@end verbatim
-...@b{a Raisonance RLink}
-...@verbatim
-# rlink interface
-interface rlink
-...@end verbatim
-...@b{parallel Port}
-...@verbatim
-interface parport
-parport_port 0xc8b8
-parport_cable wiggler
-jtag_speed 0
-...@end verbatim
-...@b{arm-jtag-ew}
-...@verbatim
-interface arm-jtag-ew
-...@end verbatim
+...@end example
+
+Most adapters need a bit more configuration than that.
+
@section Interface Configuration
@@ -1353,180 +1340,232 @@ Returns the name of the interface driver
@section Interface Drivers
-Currently supported interface drivers are:
+Each of the interface drivers listed here must be explicitly
+enabled when OpenOCD is configured, in order to be made
+available at run time.
-...@itemize @minus
+...@deffn {Interface Driver} {amt_jtagaccel}
+Amontec Chameleon in its JTAG Accelerator configuration,
+connected to a PC's EPP mode parallel port.
+This defines some driver-specific commands:
-...@item @b{parport}
-...@* PC parallel port bit-banging (Wigglers, PLD download cable, ...)
+...@deffn {Config Command} {parport_port} number
+Specifies either the address of the I/O port (default: 0x378 for LPT1) or
+the number of the @file{/dev/parport} device.
+...@end deffn
-...@item @b{amt_jtagaccel}
-...@* Amontec Chameleon in its JTAG Accelerator configuration connected to a PC's EPP
-mode parallel port
+...@deffn {Config Command} rtck [...@option{enable}|@option{disable}]
+Displays status of RTCK option.
+Optionally sets that option first.
+...@end deffn
+...@end deffn
-...@item @b{ft2232}
-...@* FTDI FT2232 (USB) based devices using either the open-source libftdi or the binary only
-FTD2XX driver. The FTD2XX is superior in performance, but not available on every
-platform. The libftdi uses libusb, and should be portable to all systems that provide
-libusb.
+...@deffn {Interface Driver} {arm-jtag-ew}
+Olimex ARM-JTAG-EW USB adapter
+This has one driver-specific command:
-...@item @b{ep93xx}
-...@*cirrus Logic EP93xx based single-board computer bit-banging (in development)
+...@deffn Command {armjtagew_info}
+Logs some status
+...@end deffn
+...@end deffn
-...@item @b{presto}
-...@* ASIX PRESTO USB JTAG programmer.
+...@deffn {Interface Driver} {at91rm9200}
+Supports bitbanged JTAG from the local system,
+presuming that system is an Atmel AT91rm9200
+and a specific set of GPIOs is used.
+...@c command: at91rm9200_device NAME
+...@c chooses among list of bit configs ... only one option
+...@end deffn
-...@item @b{usbprog}
-...@* usbprog is a freely programmable USB adapter.
+...@deffn {Interface Driver} {dummy}
+A dummy software-only driver for debugging.
+...@end deffn
[Openocd-development] [patch 3/5] src/jtag/*c whitespace removal
Remove pernicious whitespace from src/jtag/*c files; mostly
the end-of-line flavor for now, although there's more.
---
src/jtag/arm-jtag-ew.c | 14 -
src/jtag/bitbang.c |2
src/jtag/ep93xx.c | 14 -
src/jtag/jlink.c | 38 ++--
src/jtag/jtag.c|2
src/jtag/parport.c | 62 +++
src/jtag/presto.c | 18 +-
src/jtag/vsllink.c | 382 +++
8 files changed, 266 insertions(+), 266 deletions(-)
Remove pernicious whitespace from src/jtag/*c files; mostly
the end-of-line flavor for now, although there's more.
---
src/jtag/arm-jtag-ew.c | 14 -
src/jtag/bitbang.c |2
src/jtag/ep93xx.c | 14 -
src/jtag/jlink.c | 38 ++--
src/jtag/jtag.c|2
src/jtag/parport.c | 62 +++
src/jtag/presto.c | 18 +-
src/jtag/vsllink.c | 382 +++
8 files changed, 266 insertions(+), 266 deletions(-)
--- a/src/jtag/arm-jtag-ew.c
+++ b/src/jtag/arm-jtag-ew.c
@@ -1,4 +1,4 @@
-// vim:ts=4 sw=4:
+// vim:ts=4 sw=4:
/***
* Copyright (C) 2009 by Dimitar Dimitrov dinu...@gmail.com*
@@ -222,14 +222,14 @@ static int armjtagew_speed(int speed)
usb_out_buffer[0] = CMD_GET_TCK_FREQUENCY;
result = armjtagew_usb_message(armjtagew_jtag_handle, 1, 4);
speed_real = (int)buf_get_u32(usb_in_buffer,0,32);
- if(result 0)
+ if(result 0)
{
LOG_ERROR(ARM-JTAG-EW getting speed failed (%d), result);
return ERROR_JTAG_DEVICE_ERROR;
- }
+ }
else
{
- LOG_INFO(Requested speed %dkHz, emulator reported %dkHz., speed, speed_real);
+ LOG_INFO(Requested speed %dkHz, emulator reported %dkHz., speed, speed_real);
}
return ERROR_OK;
@@ -334,7 +334,7 @@ static void armjtagew_path_move(int num_
for (i = 0; i num_states; i++)
{
/*
- * TODO: The ARM-JTAG-EW hardware delays TDI with 3 TCK cycles when in RTCK mode.
+ * TODO: The ARM-JTAG-EW hardware delays TDI with 3 TCK cycles when in RTCK mode.
* Either handle that here, or update the documentation with examples
* how to fix that in the configuration files.
*/
@@ -504,7 +504,7 @@ static int armjtagew_get_version_info(vo
usb_out_buffer[0] = CMD_GET_VERSION;
result = armjtagew_usb_message(armjtagew_jtag_handle, 1, 4+15+256);
- if (result != 0)
+ if (result != 0)
{
LOG_ERROR(ARM-JTAG-EW command CMD_GET_VERSION failed (%d)\n, result);
return ERROR_JTAG_DEVICE_ERROR;
@@ -791,7 +791,7 @@ static int armjtagew_usb_message(armjtag
if (result == out_length)
{
result = armjtagew_usb_read(armjtagew_jtag, in_length);
- if (result != in_length)
+ if (result != in_length)
{
LOG_ERROR(usb_bulk_read failed (requested=%d, result=%d), in_length, result);
return -1;
--- a/src/jtag/bitbang.c
+++ b/src/jtag/bitbang.c
@@ -79,7 +79,7 @@ static void bitbang_state_move(int skip)
int i=0, tms=0;
u8 tms_scan = tap_get_tms_path(tap_get_state(), tap_get_end_state());
int tms_count = tap_get_tms_path_len(tap_get_state(), tap_get_end_state());
-
+
for (i = skip; i tms_count; i++)
{
tms = (tms_scan i) 1;
--- a/src/jtag/ep93xx.c
+++ b/src/jtag/ep93xx.c
@@ -53,13 +53,13 @@ static int ep93xx_quit(void);
struct timespec ep93xx_;
-jtag_interface_t ep93xx_interface =
+jtag_interface_t ep93xx_interface =
{
.name = ep93xx,
.execute_queue = bitbang_execute_queue,
- .speed = ep93xx_speed,
+ .speed = ep93xx_speed,
.register_commands = ep93xx_register_commands,
.init = ep93xx_init,
.quit = ep93xx_quit,
@@ -84,12 +84,12 @@ static void ep93xx_write(int tck, int tm
output_value |= TCK_BIT;
else
output_value = ~TCK_BIT;
-
+
if (tms)
output_value |= TMS_BIT;
else
output_value = ~TMS_BIT;
-
+
if (tdi)
output_value |= TDI_BIT;
else
@@ -111,7 +111,7 @@ static void ep93xx_reset(int trst, int s
output_value |= SRST_BIT;
else if (srst == 1)
output_value = ~SRST_BIT;
-
+
*gpio_data_register = output_value;
nanosleep(ep93xx_, NULL);
}
@@ -153,7 +153,7 @@ static int ep93xx_init(void)
{
int ret;
- bitbang_interface = ep93xx_bitbang;
+ bitbang_interface = ep93xx_bitbang;
ep93xx_.tv_sec = 0;
ep93xx_.tv_nsec = 1000;
@@ -203,7 +203,7 @@ static int ep93xx_init(void)
gpio_data_direction_register = gpio_controller + 0x18;
LOG_INFO(gpio_data_register = %p\n, gpio_data_register);
- LOG_INFO(gpio_data_direction_reg = %p\n, gpio_data_direction_register);
+ LOG_INFO(gpio_data_direction_reg = %p\n, gpio_data_direction_register);
/*
* Configure bit 0 (TDO) as an input, and bits 1-5 (TDI, TCK
* TMS, TRST, SRST) as outputs. Drive TDI and TCK low, and
--- a/src/jtag/jlink.c
+++ b/src/jtag/jlink.c
@@ -59,24 +59,24 @@ static u8 usb_out_buffer[JLINK_OUT_BUFFE
static u8 usb_emu_result_buffer[JLINK_EMU_RESULT_BUFFER_SIZE];
/* Constants for JLink command */
-#define
[Openocd-development] [patch 4/5] ft2232c whitespace and minor fixes
Remove pernicious whitespace from ft2232 driver; as usual,
end-of-line noise, but here also much line-internal stuff.
Plus minor cleanup:
- make Olimex glue warn about Olimex issues instead of JTAGkey issues;
- make some data static+const;
- don't export some internal symbols.
---
src/jtag/ft2232.c | 534 ++--
1 file changed, 267 insertions(+), 267 deletions(-)
Remove pernicious whitespace from ft2232 driver; as usual,
end-of-line noise, but here also much line-internal stuff.
Plus minor cleanup:
- make Olimex glue warn about Olimex issues instead of JTAGkey issues;
- make some data static+const;
- don't export some internal symbols.
---
src/jtag/ft2232.c | 534 ++--
1 file changed, 267 insertions(+), 267 deletions(-)
--- a/src/jtag/ft2232.c
+++ b/src/jtag/ft2232.c
@@ -52,7 +52,7 @@
#if (BUILD_FT2232_FTD2XX==1 BUILD_FT2232_LIBFTDI==1)
#error BUILD_FT2232_FTD2XX BUILD_FT2232_LIBFTDI are mutually exclusive
-#elif(BUILD_FT2232_FTD2XX!=1 BUILD_FT2232_LIBFTDI!=1)
+#elif (BUILD_FT2232_FTD2XX!=1 BUILD_FT2232_LIBFTDI!=1)
#error BUILD_FT2232_FTD2XX || BUILD_FT2232_LIBFTDI must be chosen
#endif
@@ -101,8 +101,8 @@ static char * ft2232_device_desc_A
static char*ft2232_device_desc = NULL;
static char*ft2232_serial = NULL;
static char*ft2232_layout = NULL;
-static u8 ft2232_latency = 2;
-static unsigned ft2232_max_tck = 6000;
+static u8 ft2232_latency = 2;
+static unsigned ft2232_max_tck = 6000;
#define MAX_USB_IDS 8
@@ -119,17 +119,17 @@ typedef struct ft2232_layout_s
} ft2232_layout_t;
/* init procedures for supported layouts */
-static int usbjtag_init(void);
-static int jtagkey_init(void);
-static int olimex_jtag_init(void);
-static int flyswatter_init(void);
-static int turtle_init(void);
-static int comstick_init(void);
-static int stm32stick_init(void);
-static int axm0432_jtag_init(void);
-static int sheevaplug_init(void);
-static int icebear_jtag_init(void);
-static int cortino_jtag_init(void);
+static int usbjtag_init(void);
+static int jtagkey_init(void);
+static int olimex_jtag_init(void);
+static int flyswatter_init(void);
+static int turtle_init(void);
+static int comstick_init(void);
+static int stm32stick_init(void);
+static int axm0432_jtag_init(void);
+static int sheevaplug_init(void);
+static int icebear_jtag_init(void);
+static int cortino_jtag_init(void);
/* reset procedures for supported layouts */
static void usbjtag_reset(int trst, int srst);
@@ -148,7 +148,7 @@ static void olimex_jtag_blink(void);
static void flyswatter_jtag_blink(void);
static void turtle_jtag_blink(void);
-ft2232_layout_t ft2232_layouts[] =
+static const ft2232_layout_t ft2232_layouts[] =
{
{ usbjtag, usbjtag_init, usbjtag_reset, NULL},
{ jtagkey, jtagkey_init, jtagkey_reset, NULL},
@@ -170,15 +170,15 @@ ft2232_layout_t ft2232_layouts[] =
static u8 nTRST, nTRSTnOE, nSRST, nSRSTnOE;
-static ft2232_layout_t*layout;
+static const ft2232_layout_t *layout;
static u8 low_output = 0x0;
static u8 low_direction = 0x0;
static u8 high_output= 0x0;
static u8 high_direction = 0x0;
#if BUILD_FT2232_FTD2XX == 1
-static FT_HANDLE ftdih = NULL;
-static FT_DEVICE ftdi_device = 0;
+static FT_HANDLE ftdih = NULL;
+static FT_DEVICE ftdi_device = 0;
#elif BUILD_FT2232_LIBFTDI == 1
static struct ftdi_context ftdic;
#endif
@@ -213,10 +213,10 @@ static int ft2232_expect_rea
* writes a byte into the byte buffer, ft2232_buffer, which must be sent later.
* @param val is the byte to send.
*/
-static inline void buffer_write( u8 val )
+static inline void buffer_write(u8 val)
{
- assert( ft2232_buffer );
- assert( (unsigned) ft2232_buffer_size (unsigned) FT2232_BUFFER_SIZE );
+ assert(ft2232_buffer);
+ assert((unsigned) ft2232_buffer_size (unsigned) FT2232_BUFFER_SIZE);
ft2232_buffer[ft2232_buffer_size++] = val;
}
@@ -226,8 +226,8 @@ static inline void buffer_write( u8 val
*/
static inline u8 buffer_read(void)
{
- assert( ft2232_buffer );
- assert( ft2232_read_pointer ft2232_buffer_size );
+ assert(ft2232_buffer);
+ assert(ft2232_read_pointer ft2232_buffer_size);
return ft2232_buffer[ft2232_read_pointer++];
}
@@ -238,51 +238,51 @@ static inline u8 buffer_read(void)
* Rigorous state transition logging is done here via tap_set_state().
*
* @param mpsse_cmd One of the MPSSE TMS oriented commands such as
- * 0x4b or 0x6b. See the MPSSE spec referenced above for their
- * functionality. The MPSSE command Clock Data to TMS/CS Pin (no Read)
- * is often used for this, 0x4b.
+ * 0x4b or 0x6b. See the MPSSE spec referenced above for their
+ * functionality. The MPSSE command Clock Data to TMS/CS Pin
[Openocd-development] [patch 5/5] openocd.texi - general (misc) commands chapter
Update the General Commands (a.k.a. random stuff) chapter,
and associated chunks of other text:
- Switch to @deffn and review everything that's documented
- Improve descriptions of reset events, with reference to
the setup.tcl code which issues them.
- Move one zy1000-specific command to that driver's doc.
- There is no script command; remove its doc.
NOTE: Some things missing from this bit of work are:
1- Reviewing the code to catch various *missing* functions,
mostly from target.c
2- Alphabetizing and organizing. This chapter is a real
grab-bag with no evident focus or structural principle.
3- Hole-filling and bugfixing with respect to messaging/logging.
Example, what principle could possibly justify the tcl command
output going into the server output/log instead of just the
telnet session?
4- Not just for this chapter ... but there should be a section
with descriptions of all the supported image file formats,
so every image command can just reference that section.
---
doc/openocd.texi | 406 -
1 file changed, 251 insertions(+), 155 deletions(-)
Update the General Commands (a.k.a. random stuff) chapter,
and associated chunks of other text:
- Switch to @deffn and review everything that's documented
- Improve descriptions of reset events, with reference to
the setup.tcl code which issues them.
- Move one zy1000-specific command to that driver's doc.
- There is no script command; remove its doc.
NOTE: Some things missing from this bit of work are:
1- Reviewing the code to catch various *missing* functions,
mostly from target.c
2- Alphabetizing and organizing. This chapter is a real
grab-bag with no evident focus or structural principle.
3- Hole-filling and bugfixing with respect to messaging/logging.
Example, what principle could possibly justify the tcl command
output going into the server output/log instead of just the
telnet session?
4- Not just for this chapter ... but there should be a section
with descriptions of all the supported image file formats,
so every image command can just reference that section.
---
doc/openocd.texi | 406 -
1 file changed, 251 insertions(+), 155 deletions(-)
--- a/doc/openocd.texi
+++ b/doc/openocd.texi
@@ -1565,6 +1565,12 @@ This is the Zylin ZY1000 JTAG debugger.
This defines some driver-specific commands,
which are not currently documented here.
@end quotation
+
+...@deffn Command power [...@option{on}|@option{off}]
+Turn power switch to target on/off.
+No arguments: print status.
+...@end deffn
+
@end deffn
@anchor{JTAG Speed}
@@ -2308,26 +2314,33 @@ The following events are available:
@item @b{old-pre_resume}
@* DO NOT USE THIS: Used internally
@item @b{reset-assert-pre}
-...@* Before reset is asserted on the tap.
+...@* Issued as part of @command{reset} processing
+after SRST and/or TRST were activated and deactivated,
+but before reset is asserted on the tap.
@item @b{reset-assert-post}
-...@* Reset is now asserted on the tap.
+...@* Issued as part of @command{reset} processing
+when reset is asserted on the tap.
@item @b{reset-deassert-pre}
-...@* Reset is about to be released on the tap
+...@* Issued as part of @command{reset} processing
+when reset is about to be released on the tap.
@item @b{reset-deassert-post}
-...@* Reset has been released on the tap
+...@* Issued as part of @command{reset} processing
+when reset has been released on the tap.
@item @b{reset-end}
-...@* Currently not used.
+...@* Issued as the final step in @command{reset} processing.
@item @b{reset-halt-post}
@* Currently not usd
@item @b{reset-halt-pre}
@* Currently not used
@item @b{reset-init}
@* Used by @b{reset init} command for board-specific initialization.
+This event fires after @emph{reset-deassert-post}.
This is where you would configure PLLs and clocking, set up DRAM so
you can download programs that don't fit in on-chip SRAM, set up pin
multiplexing, and so on.
@item @b{reset-start}
-...@* Currently not used
+...@* Issued as part of @command{reset} processing
+before either SRST or TRST are activated.
@item @b{reset-wait-pos}
@* Currently not used
@item @b{reset-wait-pre}
@@ -3472,27 +3485,37 @@ port is .
@section Daemon Commands
-...@subsection sleep [...@var{msec}]
-...@cindex sleep
-...@*wait for n milliseconds before resuming. Useful in connection with script files
-(@var{script} command and @var{target_script} configuration).
+...@deffn Command sleep msec [...@option{busy}]
+Wait for at least @var{msec} milliseconds before resuming.
+If @option{busy} is passed, busy-wait instead of sleeping.
+(This option is strongly discouraged.)
+Useful in connection with script files
+(@command{script} command and @command{target_name} configuration).
+...@end deffn
-...@subsection shutdown
-...@cindex shutdown
-...@*close the
Re: [Openocd-development] OpenOCD now available on FreeBSD
On Wed, 2009-06-03 at 13:57 -0700, David Brownell wrote: On Wednesday 03 June 2009, CeDeROM wrote: Got patches for us? :) Do You mean patches for the other cables or to build the package? If You want to build the program, update the port tree with portsnap and type: I suspect he meant patches against the current OpenOCD tree to make sure your FreeBSD support is only *packaging* work. That is, it should be possible to pull down the current source (using SVN) and build it on BSD without any source code changes. If it's not possible, that's a bug ... and one that's better fixed upstream, than as part of packaging. Precisely. Packagers and distributors should _never_ maintain out-of-tree patches, unless the upstream tree has rejected them. To do otherwise is forked. --Z ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] shut up GDB debugging when no GDB connections are used
On Saturday 30 May 2009, Øyvind Harboe wrote: OpenOCD is currently single threaded so sending keep alive messages is tedious... pthreads is a new can of works entirely, but perhaps it *would* be a good idea introduce some multithreaded capabilities in OpenOCD? I'd think that's a technically good approach. There will be some portability issues to strangle though. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [path 1/5] openocd.texi - str9xpec and mflash updates
On Wed, 2009-06-03 at 14:00 -0700, David Brownell wrote: Convert the str9xpec driver info to use @deffn; alphabetize; add the missing part_id command. Convert the mflash support to use @deffn; alphabetize. --- doc/openocd.texi | 159 - 1 file changed, 85 insertions(+), 74 deletions(-) Committed r2034. --Z ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] ARM document: Writing JTAG Sequences for ARM9 Processors
On Tuesday 02 June 2009, Igor Skochinsky wrote: HTML: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dai0205a/index.html So entering the RUN/IDLE state (RTI) will sometimes be clocking instructions through the ARM9 instruction pipeline? Interesting. Those EmbeddedICE operations must be paying *very* careful attention to state transitions... ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch 3/5] src/jtag/*c whitespace removal
On Wed, 2009-06-03 at 14:02 -0700, David Brownell wrote: Remove pernicious whitespace from src/jtag/*c files; mostly the end-of-line flavor for now, although there's more. --- src/jtag/arm-jtag-ew.c | 14 - src/jtag/bitbang.c |2 src/jtag/ep93xx.c | 14 - src/jtag/jlink.c | 38 ++-- src/jtag/jtag.c|2 src/jtag/parport.c | 62 +++ src/jtag/presto.c | 18 +- src/jtag/vsllink.c | 382 +++ 8 files changed, 266 insertions(+), 266 deletions(-) Committed, r2036. --Z ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch 4/5] ft2232c whitespace and minor fixes
On Wed, 2009-06-03 at 14:03 -0700, David Brownell wrote: Remove pernicious whitespace from ft2232 driver; as usual, end-of-line noise, but here also much line-internal stuff. Committed, r2038. Plus minor cleanup: - make Olimex glue warn about Olimex issues instead of JTAGkey issues; - make some data static+const; - don't export some internal symbols. Committed, r2037. Whitespace changes should be completely separate from patches that make real changes. Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch 2/5] openocd.texi - update interface driver section
On Wed, 2009-06-03 at 14:01 -0700, David Brownell wrote: Convert the Interface/Dongle Config chapter's section on drivers to use the @deffn syntax, and integrate the presentation of the driver-specific commands with the relevant driver. Alphabetize. Cross-checked against the code ... several adapters were not listed, and a few commands weren't. (Maintainers for the versaloon and zy1000 drivers would be good candidates to add the commands missing from those sections...) --- doc/openocd.texi | 393 + 1 file changed, 216 insertions(+), 177 deletions(-) Committed, r2035. Z ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch 5/5] openocd.texi - general (misc) commands chapter
On Wed, 2009-06-03 at 14:07 -0700, David Brownell wrote: Update the General Commands (a.k.a. random stuff) chapter, and associated chunks of other text: - Switch to @deffn and review everything that's documented - Improve descriptions of reset events, with reference to the setup.tcl code which issues them. - Move one zy1000-specific command to that driver's doc. - There is no script command; remove its doc. NOTE: Some things missing from this bit of work are: 1- Reviewing the code to catch various *missing* functions, mostly from target.c 2- Alphabetizing and organizing. This chapter is a real grab-bag with no evident focus or structural principle. 3- Hole-filling and bugfixing with respect to messaging/logging. Example, what principle could possibly justify the tcl command output going into the server output/log instead of just the telnet session? 4- Not just for this chapter ... but there should be a section with descriptions of all the supported image file formats, so every image command can just reference that section. Committed, r2039. --Z ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] cif_probe failure
On Wed, 2009-06-03 at 18:55 +0200, Michael Schwingen wrote: flash bank # chip_width(addr width) is 16 bit, bus_width(data width) is 8 bit flash bank cfi 0x1000 0x800 2 1 0 Is it correct? In fact, I am not very sure the meaning of chip_width and bus_width in bank structure from source code. chip_width is 1, since 1 byte (8 bits) are connected, and bus_width should be 1, too. Furthermore, you need the x16_as_x8 option to tell openocd that the flash uses shifted address lines. I hope the address lines are connected correctly (with A-1 on the flash connected to A0 on the CPU)? You're quite right. After I changed CPU bus to 8 bit wide and follow from your word, the new config is: flash bank cfi 0x1000 0x800 1 1 0 x16_as_x8 It works now. telnet Flash Manufacturer/Device: 0x007f 0x00c9 flash 'cfi' found at 0x1000 So I can do program the flash with cfi I think. Thanks a lot. PS: The lastest openocd manual has no description about x16_as_x8 option??? Regars, -- ZJ ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] cif_probe failure
On Wednesday 03 June 2009, jie.zeng wrote:
PS: The lastest openocd manual has no description about x16_as_x8
option???
Upcoming patch changes that to:
@item @var{x16_as_x8} ... when a 16-bit flash is hooked up to an 8-bit bus.
Good enough?
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Target AJAX like support - User Interface Thread
zach Duane, Did you write this plan up? Got Links? If not, care to revisit
zach the vision in a new thread on the list or a patch to The Manual? :)
Nothing wrote up - so I'll put some ideas and concepts here that
could/should be put into the developer manual
This is vision - nothing is cast in stone, so toss up some ideas.
This is the *USERINTERFACE* part of the discussion.
Another thread will be the *command ideas*.
It is *UTTERLY* important that we get this API correct - otherwise we
will screw this feature up big time.
I cannot recommend this GOOGLE TECH TALK - enough
http://lcsd05.cs.tamu.edu/slides/keynote.pdf
http://video.google.com/videoplay?docid=-3733345136856180693
http://www.youtube.com/watch?v=aAb7hSCtvGw
I wrote this 'out of my head' tonight, it is not clean. I've been
thinking about this for quite some time.
You know, we *COULD* - have OpenOCD serve out the OpenOCD manual this
way too.
Hmm Interesting
-Duane
== For reference ==
I assume the reader has read:
${OPENOCD_SRC}/doc/manual/server.txt
That is the starting point of this discussion.
Let us assume the user has opened their web browser and points it at the
openocd built-in-web-server.
What happens?
What is available?
Let's talk about what the user should be able to do.
I want to paint a picture...
Primary
General Experience Goal - Ability Locally Override
Location #1;
The user should always be able to stuff some files in a 'project
local directory'
and serve those files out when the user connects to the built in web
server.
[ie: the directory where OpenOCD runs].
If those files are not found, OpenOCD - searches *standard* places.
Example: My working directory is: c:\myproject
the OpenOCD config file is called: c:\myproject\openocd.cfg
I should be able to put files in: c:\myproject\openocd\
thisdirectory and override the system.
Remember: there are often lots of html files, to many to clutter the
current directory.
Location #2
Users ${HOME}/.openocd/http directory
Location #3
${INSTALLDIR}/ .
Main HTML page - what should index.html be?
There should be 2 of them.
(a) the main full featured one.
(b) the framed header - that wraps around a users file.
Framed Header EXAMPLE:
If I create a my own index.html file.
We should be able to frame that with a small title bar with some
links.
sort of like google image search - It has the original at the top
of the page.
This should exists so that the user always has an out and can get
to the main default openocd page.
Maybe that FRAMED header - is fancy and uses something like this:
http://www.brainjar.com/dhtml/menubar/demo.html
STATIC FILES
We should be able to create some simple html files, for example:
SPECIFICALLY:
These are *directories* where all kinds of kewl things can be put.
What ever you want... the examples here are *directories*
http://localhost:/openocd/static/chip/xilinx/XC3S500E-4FG320C
http://localhost:/openocd/static/target/st/str912
http://localhost:/openocd/static/board/atmel/sam3u-ek
http://localhost:/openocd/static/dongle/xverve/signalizer
Rules should be like Apache.:
First - try the given name.
If the given name is a directory, append index.html and try again.
LOCATION
These files should be in the install directory, these would be
under openod/httpd/static/whatever
the httpd directory should be Parallel to the TCL, and other
directories under install.
REQUIRED FILES
index.html - for static content
or index.tcl- for dynamic content }
OPTIONAL (strongly suggested) various meta-data.json.
TBD - exact format, style, etc.
TBD - other format, other names.
Example: 'flash.json' - could describe the on-board (or
on-chip) flash.
Example: 'memory.json' could describe the memory map.
Example: 'cpu.json' - could describe the CPU.
The cpu.json file in the *board* or *target* directory might
have an http-redirect
example: openocd/static/chip/st/stm32/cpu.json - might REFER
to core/arm/cortex-m3.html
Likewise, the pic32 - might *refer* to the mips/m4k.html
These meta-data files - can be used by some *GENERIC* AJAX like things
that create a *MEMORY* view web page, or a FLASH program page.
Maybe another that can b used to *view/edit/change* cpu registers, or
maybe the ARM co-processor registers.
Imagine a memoryviewer.java - application that uses the meta data
file: 'memory.json' as configuration data.
TBD:
Exact format and content of the *details.json* file.
I think JSON is a simple easy to understand and use file format.
It is also easy for us simple humans to
[Openocd-development] Target - AJAX - Command Ideas
PART DUEX == To understand this - please - read my earlier thread: Target AJAX like support - User Interface Thread. This thread discusses the command ideas. The user interface part is in the earlier thread. What ever we do - we need to come up with a Nifty Protocol name for this part, some name that is utterly silly or socially offensive. -Duane. === I will repeat my self, this point is UTTERLY important that we get this API correct - otherwise we will screw this feature up big time. I cannot recommend this GOOGLE TECH TALK - enough http://lcsd05.cs.tamu.edu/slides/keynote.pdf http://video.google.com/videoplay?docid=-3733345136856180693 http://www.youtube.com/watch?v=aAb7hSCtvGw === SENDING COMMANDS === The tiny server supports HTTP post, and HTTP GET, those are probably enough for our purposes. Lets assume those 2 methods are plenty. = RECEIVING REPLIES = Today, we have a TCL command server. That can continue easily enough. But I want to verify that this is *STILL* a good solution. I cannot judge from the stand point of AJAX, FLASH, and JAVA, which is better. To what degree can they open a socket and talk to it? is this utterly easy? Or is the answer something else: They can, but it is painful, it is easier if we do some type of XHTML requests instead? My understanding of AJAX comes from this: http://www.brainjar.com/dhtml/ajax/default.asp Let us assume the server *CANNOT* easily respond with XML.. Can we choose another format that is simple and easy to parse? Most if not all commands need to return data in some name/value type format that is extendable and easy to parse. I am ignoring the transport scheme, pending resolution of the above). Using the version number request - (below) as an example, the element names (or tag-names) might be: protocol-version: 123 svn-version: 456 sign-on-string: The fancy new openocd version 1.2.3 built by du...@borgcube on 2009.06.03 XML is another idea. JSON is another. Simple ASCII text, as shown above is also very simple, in effect, the reply data component looks like http-headers (on purpose). I cannot judge how easy it is for any of these common web-script languages do the majic they do. I would like input from others about this. = Minimal Commands: = (a) What version are you Reply is multi-part (1) the protocol version number (2) the SVN version number (3) the sign on string OpenOCD gives @ startup. = (b) What are the list of targets. = Reply is the list of names supplied to 'target create' = (c) What are the list of taps? = Reply is the list of names supplied to 'jtag newtap' = (d) There should be *NO* concept of active tap, nor active target = In all cases, all command should *require* a specific target or tap name be specified = (d) For any target, or tap, or board = A means to get *details* about the target or tap, or board Using the TAPNAME, the TARGETNAME, or ?something? as a key. In general, this details request should be redirected to a *static* pre configured file, perhaps a *JSON* file, for example, the request URL might be: http://localhost:/openocd/static/chipatmel/at91sam9260/memory.json (See the 'static meta-data files' in my earlier thread). == (e) The ability to read the value of some TCL variables. == For example, assume I have a TARGET name in my Javascript. That target name might be: at91sam9260.cpu Return the details file for this target. [see above] === (f) The ability to read/write memory === In effect, where one can specify the *width* of the access. target_read_memory() And target_write_memory(). (g) CPU Registers (specifically GDB registers) The ability to get the *NAMES* of the CPU registers. This might come from a cpu-reg-names.json file. The ability to *read* and *write* those registers. I'd hope this would use a common viewer sheme. (h) The ability to read special cpu registers For example ARM cp15 - is not a GDB register. These might be a *special-register-viewer* file. It is late, that is the idea I've had in mind for +1 year And is probably good food for thought for now. *END* ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Target - AJAX - Command Ideas
PART DUEX == To understand this - please - read my earlier thread: Target AJAX like support - User Interface Thread. This thread discusses the command ideas. The user interface part is in the earlier thread. What ever we do - we need to come up with a Nifty Protocol name for this part, some name that is utterly silly or socially offensive. -Duane. === I will repeat my self, this point is UTTERLY important that we get this API correct - otherwise we will screw this feature up big time. I cannot recommend this GOOGLE TECH TALK - enough http://lcsd05.cs.tamu.edu/slides/keynote.pdf http://video.google.com/videoplay?docid=-3733345136856180693 http://www.youtube.com/watch?v=aAb7hSCtvGw === SENDING COMMANDS === The tiny server supports HTTP post, and HTTP GET, those are probably enough for our purposes. Lets assume those 2 methods are plenty. = RECEIVING REPLIES = Today, we have a TCL command server. That can continue easily enough. But I want to verify that this is *STILL* a good solution. I cannot judge from the stand point of AJAX, FLASH, and JAVA, which is better. To what degree can they open a socket and talk to it? is this utterly easy? Or is the answer something else: They can, but it is painful, it is easier if we do some type of XHTML requests instead? My understanding of AJAX comes from this: http://www.brainjar.com/dhtml/ajax/default.asp Let us assume the server *CANNOT* easily respond with XML.. Can we choose another format that is simple and easy to parse? Most if not all commands need to return data in some name/value type format that is extendable and easy to parse. I am ignoring the transport scheme, pending resolution of the above). Using the version number request - (below) as an example, the element names (or tag-names) might be: protocol-version: 123 svn-version: 456 sign-on-string: The fancy new openocd version 1.2.3 built by du...@borgcube on 2009.06.03 XML is another idea. JSON is another. Simple ASCII text, as shown above is also very simple, in effect, the reply data component looks like http-headers (on purpose). I cannot judge how easy it is for any of these common web-script languages do the majic they do. I would like input from others about this. = Minimal Commands: = (a) What version are you Reply is multi-part (1) the protocol version number (2) the SVN version number (3) the sign on string OpenOCD gives @ startup. = (b) What are the list of targets. = Reply is the list of names supplied to 'target create' = (c) What are the list of taps? = Reply is the list of names supplied to 'jtag newtap' = (d) There should be *NO* concept of active tap, nor active target = In all cases, all command should *require* a specific target or tap name be specified = (d) For any target, or tap, or board = A means to get *details* about the target or tap, or board Using the TAPNAME, the TARGETNAME, or ?something? as a key. In general, this details request should be redirected to a *static* pre configured file, perhaps a *JSON* file, for example, the request URL might be: http://localhost:/openocd/static/chipatmel/at91sam9260/memory.json (See the 'static meta-data files' in my earlier thread). == (e) The ability to read the value of some TCL variables. == For example, assume I have a TARGET name in my Javascript. That target name might be: at91sam9260.cpu Return the details file for this target. [see above] === (f) The ability to read/write memory === In effect, where one can specify the *width* of the access. target_read_memory() And target_write_memory(). (g) CPU Registers (specifically GDB registers) The ability to get the *NAMES* of the CPU registers. This might come from a cpu-reg-names.json file. The ability to *read* and *write* those registers. I'd hope this would use a common viewer sheme. (h) The ability to read special cpu registers For example ARM cp15 - is not a GDB register. These might be a *special-register-viewer* file. It is late, that is the idea I've had in mind for +1 year And is probably good food for thought for now. *END* ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] cif_probe failure
On Wed, 2009-06-03 at 19:51 -0700, David Brownell wrote:
On Wednesday 03 June 2009, jie.zeng wrote:
PS: The lastest openocd manual has no description about x16_as_x8
option???
Upcoming patch changes that to:
@item @var{x16_as_x8} ... when a 16-bit flash is hooked up to an 8-bit bus.
Good enough?
Yeah I think. Its understandable. Thanks.
Regards,
--
ZJ
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
