Re: [Openocd-development] [patch] target list tweaks
Committed. Thanks! -- Ø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] fix $target_name cget -work-area-backup
Committed. Thanks! -- Ø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
[Openocd-development] Monolithic config files
One thing I see on the net are monolithic config files where the configuration of the interface is mixed into the target configuration. How about making it illegal to have the interface command together with target? This would (strongly) encourage target files to be made independant of interface configuration. Enforcement can be done in various ways... -- Ø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
[Openocd-development] Monolithic config files
One thing I see on the net are monolithic config files where the configuration of the interface is mixed into the target configuration. How about making it illegal to have the interface command together with target? This would (strongly) encourage target files to be made independant of interface configuration. Enforcement can be done in various ways... For me, it is a bad idea ! Fro some of our cusotmers, we provide an unique configuration file for their custom board. This unique configuration file include startup : - statup sequence - interface - board - ... Having ONE unique configuration file IS a big advantage making the configuration stronger. Regards, Laurent http://www.amontec.com -- Making JTAG a Snap with JTAGkey full-speed USB JTAG adapter with JTAGkey2 high-speed USB JTAG dongle ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Monolithic config files
Why do you prefer to have the interface definition inside such config files? Why would you *not* want the interface config file to come from OpenOCD's published configuration files for interaces? openocd -f interface/abc.cfg -f customerconfig.cfg -- Ø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] Monolithic config files
Øyvind Harboe wrote: Why do you prefer to have the interface definition inside such config files? Why would you *not* want the interface config file to come from OpenOCD's published configuration files for interaces? openocd -f interface/abc.cfg -f customerconfig.cfg At the begin of OpenOCD (in 2005 for Amontec), it was very powerful to have the possibility to provide to our customers only one openocd.exe and one openocd.cfg for their specific boards. In this way, Amontec was minimizing the risk regarding file versions ... This was the case for a lot of our customers using OpenOCD in daisy chain (multi TAP/devices in the same chain), ... When your customer ask you for an issue using the OpenOCD for their specific JTAG chain, your first reflex is to ask about what version they use, what configuration files they use, and if possible the shematic of the specific board ... Some mails after, some hours after, you provide one openocd.exe and one openocd.cfg , and you ask your customer to test with these two files as: openocd -f myconfig.cfg The openocd -f interface/abc.cfg -f customerconfig.cfg is better as it split interface and board configuration, but sometimes the ONE configuration file can stay a great advantage. Regards, Laurent http://www.amontec.com -- Making JTAG a Snap with JTAGkey full-speed USB JTAG adapter with JTAGkey2 high-speed USB JTAG dongle ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] ADuC702x Flash driver
I am trying to program the Internal Flash of a ADuC7021 with OpenOCD and an Olimex OpenOCD JTAG TINY A If I use the other tool chain (IAR) to program the part I can use OpenOCD to 'verify_image file 0 elf' But if I try to do a flash write_image file.elf 0 elf It tells me there is no flash at 0 flash write_image file.elf 0 elf No flash at address 0x No flash at address 0x8000 No flash at address 0x8140 No flash at address 0x9708 wrote 0 byte from file file.elf in 0.00s (nan kb/s) flash banks returns: flash banks #0: aduc702x at 0x0008, size 0xf800, buswidth 0, chipwidth 0 Which is where the flash is physically located, but at Reset (POR) it maps flash to 0 which where we expect to execute from. I did try adding an offset to get to the base of flash flash write_image file.elf 0x8 elf but that crashes (using windows openocd-ftd2xx) Open On-Chip Debugger 0.2.0-in-development (2009-05-23-14:36) svn:1888M (snapshot 1888 from SVN tree + patch, no official release) Is the maintainer of ADuC702x active? Anyone else using this driver? tom ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Monolithic config files
On Monday 08 June 2009, Øyvind Harboe wrote: How about making it illegal to have the interface command together with target? I'd say no, on the general principle that such policy choices should in user hands. This would (strongly) encourage target files to be made independant of interface configuration. I wouldn't object to a warning, if it could be suppressed for the inevitable cases where it's spurious. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] ADuC702x Flash driver
Thomas A. Moulton t...@moulton.us writes: I am trying to program the Internal Flash of a ADuC7021 with OpenOCD and an Olimex OpenOCD JTAG TINY A If I use the other tool chain (IAR) to program the part I can use OpenOCD to 'verify_image file 0 elf' But if I try to do a flash write_image file.elf 0 elf It tells me there is no flash at 0 flash write_image file.elf 0 elf No flash at address 0x No flash at address 0x8000 No flash at address 0x8140 No flash at address 0x9708 wrote 0 byte from file file.elf in 0.00s (nan kb/s) flash banks returns: flash banks #0: aduc702x at 0x0008, size 0xf800, buswidth 0, chipwidth 0 Which is where the flash is physically located, but at Reset (POR) it maps flash to 0 which where we expect to execute from. I did try adding an offset to get to the base of flash flash write_image file.elf 0x8 elf but that crashes (using windows openocd-ftd2xx) Open On-Chip Debugger 0.2.0-in-development (2009-05-23-14:36) svn:1888M (snapshot 1888 from SVN tree + patch, no official release) Is the maintainer of ADuC702x active? Anyone else using this driver? Hi Thomas, I am using it and can confirm that it generally works OK. I think I did need to use the offset. This should be my programming config file fragment: == init halt # Write to MEMMAP to enable access to flash below first 64 bytes mwh 0xf804 0x8 #setup POWCON register to obtain the default 5.22MHz (RC osc) clock. # POWKEY1 = 0x01; mwh 0x0404 0x01 # POWCON = 0x0; mwh 0x0408 0x0 # POWKEY2 = 0xF4; mwh 0x040c 0xf4 flash erase_address 0x8 0xf800 flash write_image test.bin 0x8 bin verify_image test.bin 0x8 bin == I was using it on a windows machine to which I don't have easy access at the moment, but I think it was as above. If you have no luck let me know I will find out my exact configuration. -- John Devereux ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Cygwin build fail (no ftdi, -mno-cygwin)
Before trying to build I downloaded and installed the libusb stuff for win32 (usb.h and the library itself) as directed in the sparkfun faq. Also made sure all cygwin parts are up to date (make, automake, autoconf etc). Then I did: make distclean ./bootstrap ./configure --enable-maintainer-mode --enable-jlink --enable-rlink CC=gcc -mno-cygwin with no apparent errors. As soon as I start the make I see the following error which I don't understand: $ make make all-recursive make[1]: Entering directory `/cygdrive/c/Documents and Settings/smited/openocd-0.1.0/trunk' Making all in src make[2]: Entering directory `/cygdrive/c/Documents and Settings/smited/openocd-0.1.0/trunk/src' Making all in helper make[3]: Entering directory `/cygdrive/c/Documents and Settings/smited/openocd-0.1.0/trunk/src/helper' /bin/sh ../../libtool --tag=CC --mode=compile gcc -mno-cygwin -std=gnu99 -DHAVE_CONFIG_H -I. -I../.. -I../../src/server -I../.. /src/target -DPKGDATADIR=\/usr/local/share/openocd\ -Wno-sign-compare -g -O2 -Wall -Wstrict-prototypes -Wformat-security -Wextr a -Wno-unused-parameter -Wbad-function-cast -Wcast-align -Wredundant-decls -Werror -MT libhelper_la-binarybuffer.lo -MD -MP -MF .d eps/libhelper_la-binarybuffer.Tpo -c -o libhelper_la-binarybuffer.lo `test -f 'binarybuffer.c' || echo './'`binarybuffer.c ../../libtool: line 846: X--tag=CC: command not found ../../libtool: line 879: libtool: ignoring unknown tag : command not found ../../libtool: line 846: X--mode=compile: command not found ../../libtool: line 1013: *** Warning: inferring the mode of operation is deprecated.: command not found ../../libtool: line 1014: *** Future versions of Libtool will require --mode=MODE be specified.: command not found ../../libtool: line 1157: Xgcc: command not found ../../libtool: line 1157: X-mno-cygwin: command not found ../../libtool: line 1157: X-std=gnu99: command not found ../../libtool: line 1157: X-DHAVE_CONFIG_H: command not found ../../libtool: line 1157: X-I.: command not found ../../libtool: line 1157: X-I../..: is a directory ../../libtool: line 1157: X-I../../src/server: No such file or directory ../../libtool: line 1157: X-I../../src/target: No such file or directory ../../libtool: line 1157: X-DPKGDATADIR=/usr/local/share/openocd: No such file or directory ../../libtool: line 1157: X-Wno-sign-compare: command not found ../../libtool: line 1157: X-g: command not found ../../libtool: line 1157: X-O2: command not found ../../libtool: line 1157: X-Wall: command not found ../../libtool: line 1157: X-Wstrict-prototypes: command not found ../../libtool: line 1157: X-Wformat-security: command not found ../../libtool: line 1157: X-Wextra: command not found ../../libtool: line 1157: X-Wno-unused-parameter: command not found ../../libtool: line 1157: X-Wbad-function-cast: command not found ../../libtool: line 1157: X-Wcast-align: command not found ../../libtool: line 1157: X-Wredundant-decls: command not found ../../libtool: line 1157: X-Werror: command not found ../../libtool: line 1157: X-MT: command not found ../../libtool: line 1157: Xlibhelper_la-binarybuffer.lo: command not found ../../libtool: line 1157: X-MD: command not found ../../libtool: line 1157: X-MP: command not found ../../libtool: line 1157: X-MF: command not found ../../libtool: line 1157: X.deps/libhelper_la-binarybuffer.Tpo: No such file or directory ../../libtool: line 1157: X-c: command not found ../../libtool: line 1209: Xlibhelper_la-binarybuffer.lo: command not found ../../libtool: line 1214: libtool: compile: cannot determine name of library object from `': command not found make[3]: *** [libhelper_la-binarybuffer.lo] Error 1 make[3]: Leaving directory `/cygdrive/c/Documents and Settings/smited/openocd-0.1.0/trunk/src/helper' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/cygdrive/c/Documents and Settings/smited/openocd-0.1.0/trunk/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/cygdrive/c/Documents and Settings/smited/openocd-0.1.0/trunk' make: *** [all] Error 2 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Monolithic config files
Øyvind Harboe wrote: Why do you prefer to have the interface definition inside such config files? It makes perfect sense if the interface is on the same board as the target, as with many of the USB-dongle style evaluation kits (STR9-comstick etc.). Why would you *not* want the interface config file to come from OpenOCD's published configuration files for interaces? Hm - I found I had to edit the interface configs anyway, so I now have copies sitting in ~/.openocd[1], along with my target config files. Also, by doing so I can omit the interface/ and target/ prefixes on the commandline. I agree that is makes sense to have target and interface configs separate (I do so, because I tend to switch between FT2232 and parport dongles on the same targets), but I would not forbid single config files - they may be useful for special setups. cu Michael [1] /usr/local/bin/openocd is a wrapper that basically contains exec /opt/openocd-0.1.0/bin/openocd -s ~/.openocd $@ ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Retired endstate command
Øyvind Harboe wrote: Committed. Retired endstate(and updated docs). Background polling would overwrite any changes to the endstate. From the command line point of with the recent changes to ir/drscan the endstate command wasn't used anyway. The best I can do for the beagleboard config files that use endstate is to let it fail w/a syntax error, because I have no idea what the script expected that command to do and the endstate command probably didn't do what the script writers expected anyway. Which information do you need to get an idea what the beagle script is expected to do? It's my understanding that the script tries to implement what's documented in http://elinux.org/OMAP3530_ICEPICK#Adding_TAPs_to_the_Scan_Chain and is called there The route to JTAG shift state is 'shortest transition. Best regards Dirk ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Retired endstate command
Which information do you need to get an idea what the beagle script is expected to do? I can't dive into the OMAP stuff with the time I have for OpenOCD, so I'll await specific feedback. I just know that the endstate command was broken in seven different ways. There was a discussion on the many shortcomings of ir/drscan commands. Also there isn't(I don't think) a pathmove/statemove command, which I can easily imagine is necessary too. What I believe is required to get OMAP up and running is: - a good OpenOCD engineer dedicating enough time at the problem. There are plenty of those around, but nobody who currently has the motivation to address all the problems and install OMAP into his brain. - clean up support the ir/drscan commands + add pathmove/statemove commands - create a way to robustely execute sequences that do not get bowled over by background polling - use all of the above to write robust configuration scripts -- Ø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] Monolithic config files
One thing that I'd like to see are more target config scripts being fed back to the community -- Ø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] ADuC702x Flash driver
[snip] == I was using it on a windows machine to which I don't have easy access at the moment, but I think it was as above. If you have no luck let me know I will find out my exact configuration. -- John Devereux I made some progress. I tried your memory writes and it does the same thing either way. I then disabled the 'work area' and it worked (very very slowly) (as expected) I guess if you can check that machine and see if there is anything important left out... If needed I should be able to build a local version for testing, but I'd love to let someone else look at the windows traceback to see if it is something obvious first... -- Tom ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Cygwin build fail (no ftdi, -mno-cygwin)
Rick Altherr wrote: On Jun 8, 2009, at 3:03 PM, Gene Smith wrote: Gene Smith wrote: Before trying to build I downloaded and installed the libusb stuff for win32 (usb.h and the library itself) as directed in the sparkfun faq. Also made sure all cygwin parts are up to date (make, automake, autoconf etc). Then I did: make distclean ./bootstrap ./configure --enable-maintainer-mode --enable-jlink --enable-rlink CC=gcc -mno-cygwin with no apparent errors. As soon as I start the make I see the following error which I don't understand: $ make make all-recursive make[1]: Entering directory `/cygdrive/c/Documents and Settings/smited/openocd-0.1.0/trunk' Making all in src make[2]: Entering directory `/cygdrive/c/Documents and Settings/smited/openocd-0.1.0/trunk/src' Making all in helper make[3]: Entering directory `/cygdrive/c/Documents and Settings/smited/openocd-0.1.0/trunk/src/helper' /bin/sh ../../libtool --tag=CC --mode=compile gcc -mno-cygwin big snip In trunk/libtool had to replace ECHO= with echo= where it is defined as printf. Not sure why. Someone pointed this out: google libtool file the line takes you to it, with quotes. This seems to come from the cygwin file /usr/shared/aclocal/libtool.m4. The linux version is older and uses a lower case echo and defines it as simply echo and not printf. Since libtool file under trunk is built with libtool.m4 at ./bootstrap the above change is not a permanent fix. Any idea on this echo/ECHO thing? Cygwin complains about blank lines in file guess-rev.sh. Not sure that they are fatal errors but I added # at beginning of lines 3, 5 and 7 and don't see command not found \r for these lines. This is due to the eol-style being wrong in SVN. I just committed a fix. After this it almost builds except for complains about OPENOCD_VERSION at 2 lines in openocd.c. When I change the definition of OPENOCD_VERSION to just Open On-Chip Debugger, my kluge without the additional version macros it builds OK. Have not yet tried to see if it actually works, but it builds w/o error now in cygwin. It just occurred to me that possibly my problem is related to the fact that I just copied the linux openocd tree (r2005) over to windows and built it on cygwin. Is it required that the tree be checked out of svn in cygwin to build on cygwin? Windows uses different line endings from Linux. SVN automatically uses the correct version for the platform you are doing the checkout on. If you just copied it from Linux to Windows, then that could explain some of the guess-rev.sh problems. The OPENOCD_VERSION problems likely are due to problems with guess-rev.sh since the output of that script is used to make that symbol. I thought I had cygwin set to expect unix style endings. But maybe the -mno-cygwin gcc option cancels it during the build? I will try a cygwin svn checkout tomorrow. Thanks for the help! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Monolithic config files
oyvind [make monolithic config files illegal] laurent For me, it is a bad idea ! I also dislike it, it is often helpful for debug reasons. -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [patch] add board/csb337.cfg
Add configuration for an old AT91rm9200 board, the Cogent CSB 337.
Worth noting from the OpenOCD perspective:
- It got a real hardware trace port connector; wired up here as
much as we can, lacking inexpensive trace-aware dongles.
- This is the first in-tree use of the arm920t cp15 command.
It adjusts the CPU clocking and enables i-cache, which gives
more than 4x speedup after booting Linux; it's visible even
just running U-Boot.
Oddly, OpenOCD is numbering its cp15 registers differently than
the ARM920T documentation. Haven't sorted that out yet...
---
tcl/board/csb337.cfg | 118 +
1 file changed, 118 insertions(+)
Add configuration for an old AT91rm9200 board, the Cogent CSB 337.
Worth noting from the OpenOCD perspective:
- It got a real hardware trace port connector; wired up here as
much as we can, lacking inexpensive trace-aware dongles.
- This is the first in-tree use of the arm920t cp15 command.
It adjusts the CPU clocking and enables i-cache, which gives
more than 4x speedup after booting Linux; it's visible even
just running U-Boot.
Oddly, OpenOCD is numbering its cp15 registers differently than
the ARM920T documentation. Haven't sorted that out yet...
---
tcl/board/csb337.cfg | 118 +
1 file changed, 118 insertions(+)
--- /dev/null
+++ b/tcl/board/csb337.cfg
@@ -0,0 +1,118 @@
+# Cogent CSB337
+# http://cogcomp.com/csb_csb337.htm
+
+source [find target/at91rm9200.cfg]
+
+# boots from NOR on CS0: 8 MBytes CFI flash, 16-bit bus
+flash bank cfi 0x1000 0x0080 2 2 $_TARGETNAME
+
+# ETM9 trace port connector present on this board, 16 data pins.
+if { [info exists ETM_DRIVER] } {
+ etm config $_TARGETNAME 16 normal half $ETM_DRIVER
+ # OpenOCD may someday support a real trace port driver...
+ # system config file would need to configure it.
+} else {
+ etm config $_TARGETNAME 16 normal half dummy
+ etm_dummy config $_TARGETNAME
+}
+
+proc csb337_clk_init { } {
+ # CPU is in Slow Clock Mode (32KiHz) ... needs slow JTAG clock
+ jtag_khz 8
+
+ # CKGR_MOR: start main oscillator (3.6864 MHz)
+ mww 0xfc20 0xff01
+ sleep 10
+
+ # CKGR_PLLAR: start PLL A for CPU and peripherals (184.32 MHz)
+ mww 0xfc28 0x20313e01
+ # CKGR_PLLBR: start PLL B for USB timing (96 MHz, with div2)
+ mww 0xfc2c 0x12703e18
+ # let PLLs lock
+ sleep 10
+
+ # PMC_MCKR: switch to CPU clock = PLLA, master clock = CPU/4
+ mww 0xfc30 0x0302
+ sleep 20
+
+ # CPU is in Normal Mode ... allows faster JTAG clock speed
+ jtag_khz 4
+}
+
+proc csb337_nor_init { } {
+ # SMC_CSR0: adjust timings (10 wait states)
+ mww 0xff70 0x1100318a
+
+ flash probe 0
+}
+
+proc csb337_sdram_init { } {
+ # enable PIOC clock
+ mww 0xfc10 0x0010
+ # PC31..PC16 are D31..D16, with internal pullups like D15..D0
+ mww 0xf870 0x
+ mww 0xf874 0x0
+ mww 0xf804 0x
+
+ # SDRC_CR: set timings
+ mww 0xff98 0x2188b0d5
+
+ # SDRC_MR: issue all banks precharge to SDRAM
+ mww 0xff90 2
+ mww 0x2000 0
+
+ # SDRC_MR: 8 autorefresh cycles
+ mww 0xff90 4
+ mww 0x2000 0
+ mww 0x2000 0
+ mww 0x2000 0
+ mww 0x2000 0
+ mww 0x2000 0
+ mww 0x2000 0
+ mww 0x2000 0
+ mww 0x2000 0
+
+ # SDRC_MR: set SDRAM mode registers (CAS, burst len, etc)
+ mww 0xff90 3
+ mww 0x2080 0
+
+ # SDRC_TR: set refresh rate
+ mww 0xff94 0x200
+ mww 0x2000 0
+
+ # SDRC_MR: normal mode, 32 bit bus
+ mww 0xff90 0
+ mww 0x2000 0
+}
+
+# The rm9200 chip has just been reset. Bring it up far enough
+# that we can write flash or run code from SDRAM.
+proc csb337_reset_init { } {
+ csb337_clk_init
+
+ # EBI_CSA: CS0 = NOR, CS1 = SDRAM
+ mww 0xff60 0x02
+
+ csb337_nor_init
+ csb337_sdram_init
+
+ # Update CP15 control register ... we don't seem to be able to
+ # read/modify/write its value through a TCL variable, so just
+ # write it. Fields are zero unless listed here ... and note
+ # that OpenOCD numbers this register 2, not 1 (!).
+ #
+ # - Core to use Async Clocking mode (so it uses 184 MHz most
+ #of the time instead of limiting to the master clock rate):
+ # iA(31) = 1, nF(30) = 1
+ # - Icache on (it's disabled now, slowing i-fetches)
+ # I(12) = 1
+ # - Reserved/ones
+ # 6:3 = 1
+ # - Alignment traps enabled
+ # A(1) = 1
+ arm920t cp15 2 0xc000107a
+}
+
+$_TARGETNAME configure -event reset-init {csb337_reset_init}
+
+# vim:syntax tcl
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch] add board/csb337.cfg
On Mon, 2009-06-08 at 17:50 -0700, David Brownell wrote: Add configuration for an old AT91rm9200 board, the Cogent CSB 337. Worth noting from the OpenOCD perspective: - It got a real hardware trace port connector; wired up here as much as we can, lacking inexpensive trace-aware dongles. - This is the first in-tree use of the arm920t cp15 command. It adjusts the CPU clocking and enables i-cache, which gives more than 4x speedup after booting Linux; it's visible even just running U-Boot. Oddly, OpenOCD is numbering its cp15 registers differently than the ARM920T documentation. Haven't sorted that out yet... --- tcl/board/csb337.cfg | 118 + 1 file changed, 118 insertions(+) Committed, r2134. --Z ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] STR912 target
Hi all,
First, let me apologize for the mistaken extra changes in r2134.
While I have reverted them in 2135, they do reflect some cleanup and
touch-ups required to support my platform, and I have been meaning to
take some time to figure out how to integrate these properly. Since
this is the second time these changes have unexpectedly visited the
mailing list, I figure now is a good a time as any to discuss them.
Does anyone have the hardware for which this target configuration works
as it is written? Would you like to work with me to factor the STR91x
support in the tree into smaller pieces, such that we do not have to
repeat the chip configuration steps repeatedly throughout the TCL tree?
To wit, I would like to eliminate the duplication between the str912.cfg
file and the str9-comstick.cfg that exists presently. This work should
also document how others can rewrite other configuration files.
Cheers,
Zach
Forwarded Message
From: zwe...@mail.berlios.de
To: openocd-...@lists.berlios.de
Subject: [Openocd-svn] r2135 - trunk/tcl/target
Date: Tue, 9 Jun 2009 03:01:17 +0200
Author: zwelch
Date: 2009-06-09 03:01:13 +0200 (Tue, 09 Jun 2009)
New Revision: 2135
Modified:
trunk/tcl/target/str912.cfg
Log:
Revert changes from r2134 that snuck into the commit. Mea culpa.
Modified: trunk/tcl/target/str912.cfg
===
--- trunk/tcl/target/str912.cfg 2009-06-09 00:58:23 UTC (rev 2134)
+++ trunk/tcl/target/str912.cfg 2009-06-09 01:01:13 UTC (rev 2135)
@@ -1,6 +1,4 @@
# script for str9
-# For more information about the configuration files, take a look at:
-# openocd.texi
if { [info exists CHIPNAME] } {
set _CHIPNAME $CHIPNAME
@@ -21,74 +19,52 @@
jtag_ntrst_delay 100
#use combined on interfaces or targets that can't set TRST/SRST separately
-#reset_config trst_and_srst
+reset_config trst_and_srst
if { [info exists FLASHTAPID ] } {
set _FLASHTAPID $FLASHTAPID
} else {
set _FLASHTAPID 0x04570041
}
-jtag newtap $_CHIPNAME flash \
- -irlen 8 -ircapture 0x1 -irmask 0x1 \
- -expected-id $_FLASHTAPID
+jtag newtap $_CHIPNAME flash -irlen 8 -ircapture 0x1 -irmask 0x1 -expected-id
$_FLASHTAPID
if { [info exists CPUTAPID ] } {
set _CPUTAPID $CPUTAPID
} else {
set _CPUTAPID 0x25966041
}
-jtag newtap $_CHIPNAME cpu \
- -irlen 4 -ircapture 0x1 -irmask 0xf \
- -expected-id $_CPUTAPID
+jtag newtap $_CHIPNAME cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id
$_CPUTAPID
if { [info exists BSTAPID ] } {
- set _BSTAPID1 $BSTAPID
- set _BSTAPID2 $BSTAPID
+ set _BSTAPID $BSTAPID
} else {
- set _BSTAPID1 0x1457f041
- set _BSTAPID2 0x2457f041
+ set _BSTAPID 0x1457f041
}
-jtag newtap $_CHIPNAME bs \
- -irlen 5 -ircapture 0x1 -irmask 0x1 \
- -expected-id $_BSTAPID1 -expected-id $_BSTAPID2
+jtag newtap $_CHIPNAME bs-irlen 5 -ircapture 0x1 -irmask 0x1 -expected-id
$_BSTAPID
set _TARGETNAME [format %s.cpu $_CHIPNAME]
-target create $_TARGETNAME arm966e \
- -endian $_ENDIAN \
- -chain-position $_TARGETNAME \
- -variant arm966e
+target create $_TARGETNAME arm966e -endian $_ENDIAN -chain-position
$_TARGETNAME -variant arm966e
$_TARGETNAME configure -event reset-start { jtag_rclk 16 }
-proc str9x_config { } {
- # -- Enable 96K RAM w/:
- #PFQBC enabled / DTCM AHB wait-states disabled
- mww 0x5C002034 0x0191
- #PFQBC disabled / DTCM AHB wait-states enabled
- #mww 0x5C002034 0x0196
+$_TARGETNAME configure -event reset-init {
+ # We can increase speed now that we know the target is halted.
+ #jtag_rclk 3000
+
+ # -- Enable 96K RAM
+ # PFQBC enabled / DTCM AHB wait-states disabled
+ mww 0x5C002034 0x0191
- # 256K/32k
- str9x flash_config 0 3 2 0 0x4
- # 512K/32K
- #str9x flash_config 0 4 2 0 0x8
+ str9x flash_config 0 4 2 0 0x8
+ flash protect 0 0 7 off
}
-proc str9x_init { } {
- # enable RTCK
- jtag_rclk 0
- str9x_config
-}
+$_TARGETNAME configure -work-area-virt 0 -work-area-phys 0x5000
-work-area-size 16384 -work-area-backup 0
-$_TARGETNAME configure -event reset-init str9x_init
-
-$_TARGETNAME configure \
- -work-area-virt 0 \
- -work-area-phys 0x5000 \
- -work-area-size 16384 \
- -work-area-backup 0
-
#flash bank str9x base size 0 0 target# variant
-flash bank str9x 0x 0x0004 0 0 0
-flash bank str9x 0x0004 0x8000 0 0 0
+flash bank str9x 0x 0x0008 0 0 0
+flash bank str9x 0x0008 0x8000 0 0 0
+# For more information about the configuration files, take a look at:
+# openocd.texi
___
Openocd-svn mailing list
openocd-...@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-svn
___
Openocd-development
Re: [Openocd-development] Retired endstate command
Øyvind Harboe wrote: Which information do you need to get an idea what the beagle script is expected to do? I can't dive into the OMAP stuff with the time I have for OpenOCD, While this is fine (it's not different with me, else I would help more ;) ), I think we could try to improve dealing with this situation: Sorry, but it's my personal impression from one or two discussions that the way we deal at the moment with this is OMAP3 is broken, I don't understand it, add even stronger error messages that everybody knows it. Well, we already know ;) I would vote to do instead: - Tell exactly what is broken (from a technical point of view, maybe on a level a not so experienced OpenOCD engineer could understand, too ;) ). Example from this script: endstate command probably didn't do what the script writers expected anyway. Why not better use two sentences explaining the potential technical problem seen? - Instead of spending time implementing even stronger error messages, better spend the time in discussion or detailed description how to fix the broken stuff. so I'll await specific feedback. This is fine. But in the starting point of this thread there wasn't a question for feedback. It was because I have no idea what the script expected that command to do I disable it. And, if others like to help with missing information (see above what do you like to know?) the answer is I have no time. Again, that's fine, but if the answer for people trying to help is I have no time, this doesn't seem to really work. I just know that the endstate command was broken in seven different ways. There was a discussion on the many shortcomings of ir/drscan commands. Also there isn't(I don't think) a pathmove/statemove command, which I can easily imagine is necessary too. What I believe is required to get OMAP up and running is: - a good OpenOCD engineer dedicating enough time at the problem. From my point of view Magus is a good candidate for this. So seems we already have one :) There are plenty of those around, but nobody who currently has the motivation to address all the problems and install OMAP into his brain. - clean up support the ir/drscan commands + add pathmove/statemove commands - create a way to robustely execute sequences that do not get bowled over by background polling - use all of the above to write robust configuration scripts Anyway, let's go on with Magnus' answer to this (see other mail). Best regards Dirk ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] assert vs. error messages
How about a clearer policy of using assert()'s?
I'm thinking that error()'s should be reserved for real runtime errors.
if (!tap_is_state_stable(path[num_states - 1]))
{
LOG_ERROR(BUG: TAP path doesn't finish in a stable state);
- exit(-1);
+ jtag_set_error(ERROR_JTAG_NOT_STABLE_STATE);
+ return;
}
The above should be an assert().
--
Ø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
