Re: [Openocd-development] Debugging from NAND Flash
Unfortunately I can't change the PC: (gdb) set $pc=0xd850 Value being assigned to is no longer active. Fixed in head of GDB? http://www.nabble.com/Patch-for-the-gdb-problem-%C2%ABValue-being-assigned--to-is-no-longer-active%C2%BB-td23615004.html Is there any other way to setup the PC to right position? I've always used a monitor reg pc xxx command, even with other hardware debuggers. Never trusted GDB to do this :-) -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] playsxvf regression
1614 introduces *lots* of changes. It could have been broken into half a dozen commits. :-) One thing to try: tms_sequence long -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] FW: AT91SAM9G20-EK.cfg
Gary Carlson wrote: 1) One of the features that the software currently allows is configuration setting inheritance from board to target to CPU. While I generally am a big advocate of extensibility in most software projects, I have been very leery of doing this for hardware-specific configuration files. Over every person's career, many of battle scars are left behind. And I have many on mine that were related to nightmare debugger/emulator configuration problems where I tried to inherit one thing from another. The one danger with inheritance in this particular scenario is many people will see a target and naturally glom onto it without giving too much thought about the consequences. Many processor families have rather incestuous relationships that share many common details, but inevitably have differences -- often very subtle ones. These little details, however, sometimes generate big consequences. The other danger always lurking with the current approach is that it is entirely possible one developer can make a change to the underlying root target file without realizing that it may propagate undesirable changes into higher-level board files. Unfortunately these type of issues are not typically discovered until much later. For these two reasons, I wonder if it may not make more sense at some point to discourage target configurations all together and encourage self-sufficient board-level configuration files instead, even though this normally goes against the grain of extensibility. The key to making this work would be to break the directory structure along processor models/manufactuer (i.e. arm926-ejs/atmel) and then lump individual board configuration files under the appropriate directories. If a developer plans on using a particular processor in a design that doesn't have an existing debugger configuration file, they quickly know which board configuration files are likely to be similar and then clone it with little risk of clobbering something else. I don't think that would be a good idea. I see the problem, but your approach would lead to several board config files that contain almost identical copies of the target specifications, leaving the user to find out the differences and wonder *why* something was put different in a special config. 2) One possible process improvement that I believe makes sense is to start enforcing a rule that authors of new configuration files must include a minimal comment header at the top of the file that specifies the exact hardware/debugger combination used. The SAM-ICE (J-link) debugger I am using for example has a number of internal quirks that may not exist in other brands and vice-versa. That sounds good. 3) One feature that I think may make sense to add at some point in the future to the main software is support for label/value associations that allow hexadecimal register values to be associated with more legible and understandable names. Looking at mww 0x3ec2 0x2 in a configuration script is more likely to introduce mistakes during reuse, then say mww some_xyz_register 0x2 where the name of the register clues you into what it does or at least where to find it in the datasheet. Agreed. I wonder if this is already possible now? cu Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] FW: AT91SAM9G20-EK.cfg
2) One possible process improvement that I believe makes sense is to start enforcing a rule that authors of new configuration files must include a minimal comment header at the top of the file that specifies the exact hardware/debugger combination used. The SAM-ICE (J-link) debugger I am using for example has a number of internal quirks that may not exist in other brands and vice-versa. To enforce rules on target scripts, we first need to have some rules to enforce against. I suggest that you start writing up a patch against the OpenOCD documentation on requirements for target config scripts. The other problem I have with this is that I want as many scripts as possible, even if they are crummy Perhaps we could mark or name scripts that don't follow the rules as work-in-progress? I.e. either it needs to have all the right comments features, or it needs a work in progress note at the top? -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] FW: AT91SAM9G20-EK.cfg
3) One feature that I think may make sense to add at some point in the future to the main software is support for label/value associations that allow hexadecimal register values to be associated with more legible and understandable names. Looking at mww 0x3ec2 0x2 in a configuration script is more likely to introduce mistakes during reuse, then say mww some_xyz_register 0x2 where the name of the register clues you into what it does or at least where to find it in the datasheet. Agreed. I wonder if this is already possible now? set xyz_register 0x3ec2 set abc_magic_value 0x12341234 ... mww $xyz_register $abc_magic_value #or mww $xyz_register 0x02 Best regards, Magnus ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] write image on sam7x512
Some quick comments... Why are you using reset halt and not reset init? last qestion: if i try the command line openocd -f jtagkey.cfg -f sam7x512.cfg -c script flash.script I have an error: Unknown command: reset halt You need to set up OpenOCD after configuring it by running the init command: openocd -f jtagkey.cfg -f sam7x512.cfg -c init -c script flash.script -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] FW: AT91SAM9G20-EK.cfg
I can now see that I left off a critical detail! :) Yes, you most certainly can use a TCL set command to accomplish this. The only issue is you have to spend an inordinate amount of time entering the values by hand. That in itself is another source for errors -- especially on processors with large configuration register sets. Most processor manufacturers typically provide a standard C include file with their reference projects that have all the configuration registers and their relevant addresses pre-defined. What I was thinking was something that allows a person to capitalize off existing C header files directly in the form of a special TCL include statement. I am not too familiar with how the existing TCL parser works, so this idea may be impractical, however. Gary On 9/1/09 12:12 AM, Magnus Lundin lun...@mlu.mine.nu wrote: 3) One feature that I think may make sense to add at some point in the future to the main software is support for label/value associations that allow hexadecimal register values to be associated with more legible and understandable names. Looking at mww 0x3ec2 0x2 in a configuration script is more likely to introduce mistakes during reuse, then say mww some_xyz_register 0x2 where the name of the register clues you into what it does or at least where to find it in the datasheet. Agreed. I wonder if this is already possible now? set xyz_register 0x3ec2 set abc_magic_value 0x12341234 ... mww $xyz_register $abc_magic_value #or mww $xyz_register 0x02 Best regards, Magnus ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] FW: AT91SAM9G20-EK.cfg
On 9/1/09 12:04 AM, Øyvind Harboe oyvind.har...@zylin.com wrote: 2) One possible process improvement that I believe makes sense is to start enforcing a rule that authors of new configuration files must include a minimal comment header at the top of the file that specifies the exact hardware/debugger combination used. The SAM-ICE (J-link) debugger I am using for example has a number of internal quirks that may not exist in other brands and vice-versa. To enforce rules on target scripts, we first need to have some rules to enforce against. I suggest that you start writing up a patch against the OpenOCD documentation on requirements for target config scripts. The other problem I have with this is that I want as many scripts as possible, even if they are crummy Perhaps we could mark or name scripts that don't follow the rules as work-in-progress? I.e. either it needs to have all the right comments features, or it needs a work in progress note at the top? I can definitely see your perspective of trying to get as many configuration files as possible. There is some truth to what you said earlier about quantity over quality in the startup phase of any project. In some ways it is not too much different then a dating site. If you only have two singles signed up, getting additional people to subscribe to the service may be difficult. This idea I think has merit for the long term, but maybe leaving things unchanged for now makes better sense. Gary Gary Carlson Gary Carlson, MSEE Principal Engineer Carlson-Minot Inc. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] FW: AT91SAM9G20-EK.cfg
Crazy idea: - write a small C app for the target that goes along with board config file - this .elf file is loaded by OpenOCD - use built-in ARM simulator to execute fn's in that .elf file ? -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] FW: AT91SAM9G20-EK.cfg
Øyvind Harboe wrote: Crazy idea: - write a small C app for the target that goes along with board config file - this .elf file is loaded by OpenOCD - use built-in ARM simulator to execute fn's in that .elf file What advantage does that provide? You need a disassembler to view the effective board-init sequence, you need a cross-toolchain to modify the code, in comparison to just changing a script file. cu Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Cortex-A8 problems
Hi Magnus, On Mon, Aug 31, 2009 at 05:36:11PM +0200, Magnus Lundin wrote: dap_ap_select(swjdp, 1); before the two lines dap_ap_read_reg_u32(swjdp, 0xFC, idreg); dap_ap_read_reg_u32(swjdp, 0xF8, romaddr); in ahbap_debugport_init() What happens when you do dap info 0 from the telnet interface ? === Open On-Chip Debugger dap info 0 ap identification register 0x14770001 Type is mem-ap AHB ap debugbase 0x No ROM table present dap info 1 ap identification register 0x04770002 Type is mem-ap APB ap debugbase 0x8000 ROM table in legacy format CID3 0xb1, CID2 0x5, CID1 0x10 CID0, 0xd MEMTYPE system memory not present. Dedicated debug bus ROMTABLE[0x0] = 0x1003 Component base address 0x80001000, pid4 0x4, start address 0x80001000 Component cid1 0x90, class is CoreSight component CID3 0xb1, CID2 0x5, CID1 0x90, CID0, 0xd PID3 0x0, PID2 0xb, PID1 0xb9, PID0, 0x7 ROMTABLE[0x4] = 0x2003 Component base address 0x80002000, pid4 0x4, start address 0x80002000 Component cid1 0x90, class is CoreSight component CID3 0xb1, CID2 0x5, CID1 0x90, CID0, 0xd PID3 0x0, PID2 0xb, PID1 0xb9, PID0, 0x6 ROMTABLE[0x8] = 0x4003 Component base address 0x80004000, pid4 0x4, start address 0x80004000 Component cid1 0x90, class is CoreSight component CID3 0xb1, CID2 0x5, CID1 0x90, CID0, 0xd PID3 0x0, PID2 0xb, PID1 0xb9, PID0, 0x8 ROMTABLE[0xc] = 0x5003 Component base address 0x80005000, pid4 0x4, start address 0x80005000 Component cid1 0x90, class is CoreSight component CID3 0xb1, CID2 0x5, CID1 0x90, CID0, 0xd PID3 0x0, PID2 0x5b, PID1 0xbc, PID0, 0x8 ROMTABLE[0x10] = 0x6003 Component base address 0x80006000, pid4 0x4, start address 0x80006000 Component cid1 0x90, class is CoreSight component CID3 0xb1, CID2 0x5, CID1 0x90, CID0, 0xd PID3 0x0, PID2 0x5b, PID1 0xb9, PID0, 0x21 ROMTABLE[0x14] = 0x7003 Component base address 0x80007000, pid4 0x4, start address 0x80007000 Component cid1 0x90, class is CoreSight component CID3 0xb1, CID2 0x5, CID1 0x90, CID0, 0xd PID3 0x0, PID2 0x5b, PID1 0xb9, PID0, 0x22 ROMTABLE[0x18] = 0x8003 Component base address 0x80008000, pid4 0x0, start address 0x80008000 Component cid1 0x0, class is Reserved CID3 0x0, CID2 0x0, CID1 0x0, CID0, 0x0 PID3 0x0, PID2 0x0, PID1 0x0, PID0, 0x0 ROMTABLE[0x1c] = 0x0 End of ROM table dap info 3 ap identification register 0x No AP found at this apsel 0x3 No ROM table present === However, as soon as the code enters cortex_a8_poll() and calls retval = mem_ap_read_atomic_u32(swjdp, OMAP3530_DEBUG_BASE + CPUDBG_DSCR, dscr); the implicit swjdp_transaction_endcheck(). Specifically, SSTICKYORUN is set during the first DP_CTRL_STAT read. So you can read some of the registers, can you read CPUDBG_DSCR ? and its value is? no, it cannot be read. neither from u-boot, nor from the AHB DAP Your problems are probably related to the DBGEN signal, this is an input to the Cortex_A8 core and controls debug access. There is some documentation of this in the Cortex_A8 TRM, but no way to controling it from the debug registers defined by ARM. I see. It's somewhat strange if ARM has all those detailed and fairly extensive specifications (and the romtable to discover the debugging capabilities), but then no standard way how DBGEN can be set? That's weird. After searching the Cortex-A8 TRM, I found Chapter 12.5.10 authentication status register (0xFB8). Bit 0 of this register is supposed to correspond to the DBGEN level. Reading this register through 'mdw 0x80005fb8' tells me it is set to 0xff, which would mean that DBGEN is set. Also, the SoC has its own SJGTAG_STATUS register that prinets the DBGEN, NIDEN, SPIDEN, SPNIDEN signals at 0x80008004, and all of those are set to '1' So what now? Any more ideas? -- - Harald Welte lafo...@gnumonks.org http://laforge.gnumonks.org/ Privacy in residential applications is a desirable marketing option. (ETSI EN 300 175-7 Ch. A6) ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] FW: AT91SAM9G20-EK.cfg
On Tue, Sep 1, 2009 at 10:24 AM, Michael Schwingenrincew...@discworld.dascon.de wrote: Øyvind Harboe wrote: Crazy idea: - write a small C app for the target that goes along with board config file - this .elf file is loaded by OpenOCD - use built-in ARM simulator to execute fn's in that .elf file What advantage does that provide? You need a disassembler to view the effective board-init sequence, you need a cross-toolchain to modify the code, in comparison to just changing a script file. You can use the header files for the target file without having to port the existing C code to OpenOCD init code. One way to sidestep writing init sequences that I use, is to write a small piece of code to flash (somehow, possibly very slowly without working memory), run u-boot, or somesuch. then I reset run + halt the CPU and issue a load to load an application into RAM. I prefer a nice crisp self-contained init sequence to the above approach any day though. -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Cortex-A8 problems
Harald Welte wrote: Hi Magnus, On Mon, Aug 31, 2009 at 05:36:11PM +0200, Magnus Lundin wrote: dap_ap_select(swjdp, 1); before the two lines dap_ap_read_reg_u32(swjdp, 0xFC, idreg); dap_ap_read_reg_u32(swjdp, 0xF8, romaddr); in ahbap_debugport_init() Can you place the call to dap_ap_select(swjdp, 1) in cortex_a8_examine() instead, just after the call to ahbap_debugport_init() ? I see. It's somewhat strange if ARM has all those detailed and fairly extensive specifications (and the romtable to discover the debugging capabilities), but then no standard way how DBGEN can be set? That's weird. It is supposed to be an input to the Cortex_A8 core, so the chip manufacturer can control debug access without modifying the A8 core. So have you looked at the OMAP init script, it is something like this: dap apsel 1 mww 0x54011FB0 0xC5ACCE55 4 # Clear Sticky Power Down status Bit to enable access to the registers in the Core Power Domain mdw 0x54011314 # set DBGEN signal mww 0x5401d030 0x2000 # enable execute instruction and halting debug mode mww 0x54011088 0x6000 # DAP AP 0 is connected to the L3 interconnect and memory bus dap apsel 0 For you I think this might become: dap apsel 1 # Unlock the Lock Access to enable writes to debug registers mww 0x80005FB0 0xC5ACCE55 # Clear Sticky Power Down status Bit to enable access to the registers in the Core Power Domain # Se note on PRSR, C_A8 TRM 12.4.21 mdw 0x80005314 # enable execute instruction and halting debug mode mww 0x80005088 0x6000 # DAP AP 0 is connected to the L3 interconnect and memory bus dap apsel 0 Best regards, Magnus ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] FW: AT91SAM9G20-EK.cfg
Øyvind Harboe wrote: What advantage does that provide? You need a disassembler to view the effective board-init sequence, you need a cross-toolchain to modify the code, in comparison to just changing a script file. You can use the header files for the target file without having to port the existing C code to OpenOCD init code. Hm - yes, that might be useful. I have used objdump to extract the initialization tables from my board-init code to create BDI2000/OpenOCD init scripts. cu Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] FW: AT91SAM9G20-EK.cfg
Hm - yes, that might be useful. I have used objdump to extract the initialization tables from my board-init code to create BDI2000/OpenOCD init scripts. Now, if we could do that in some *nice* way it would be quite a powerful method. Most every PCB out there has some working sample code -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] write image on sam7x512
On Tue, Sep 1, 2009 at 11:54 AM, Peter Zuidemapzuid...@octrium.com wrote: The AT91SAM7X(C)512 contains 2 flash banks, each 256KB. Yes, I know You have to change the sam7x512.cfg and add a flash-bank definition. Are you sure? The doc/openocd.pdf has some information in chapter 13 Flash programming. You could try this: flash bank at91sam7 0 0 0 0 0 flash bank at91sam7 0 0 0 0 1 If I try that I obtain: Error: target '1' not defined anyway, only with flash bank at91sam7 0 0 0 0 0 openOCD correcty detects 2 banks: flash banks #0: at91sam7 at 0x0010, size 0x0004, buswidth 4, chipwidth 0 #1: at91sam7 at 0x0014, size 0x0004, buswidth 4, chipwidth 0 From the telnet console (to OpenOCD) check if this 2nd bank is available/working: flash info 1 here is the result: flash info 1 #1 : at91sam7 at 0x0014, size 0x0004, buswidth 4, chipwidth 0 # 0: 0x (0x4000 16kB) not protected # 1: 0x4000 (0x4000 16kB) not protected # 2: 0x8000 (0x4000 16kB) not protected # 3: 0xc000 (0x4000 16kB) not protected # 4: 0x0001 (0x4000 16kB) not protected # 5: 0x00014000 (0x4000 16kB) not protected # 6: 0x00018000 (0x4000 16kB) not protected # 7: 0x0001c000 (0x4000 16kB) not protected # 8: 0x0002 (0x4000 16kB) not protected # 9: 0x00024000 (0x4000 16kB) not protected # 10: 0x00028000 (0x4000 16kB) not protected # 11: 0x0002c000 (0x4000 16kB) not protected # 12: 0x0003 (0x4000 16kB) not protected # 13: 0x00034000 (0x4000 16kB) not protected # 14: 0x00038000 (0x4000 16kB) not protected # 15: 0x0003c000 (0x4000 16kB) not protected at91sam7 driver information: Chip is AT91SAM7X512 Cidr: 0x275c0a40 | Arch: 0x0075 | Eproc: ARM7TDMI | Version: 0x000 | Flashsize: 0x0004 Master clock (estimated): 53583 KHz | External clock: 0 KHz Pagesize: 256 bytes | Lockbits(16): 0 0x | Pages in lock region: 0 Securitybit: 0 | Nvmbits(3): 1 0x4 This is obtained without the config line: flash bank at91sam7 0 0 0 0 1 thanks -- Assioma di Cole: La somma dell'intelligenza sulla Terra è costante; la popolazione è in aumento Massimiliano Cialdi cia...@gmail.com massimiliano.cia...@powersoft.it ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Debugging from NAND Flash
Hi Oyvind, On 9/1/09, Øyvind Harboe oyvind.har...@zylin.com wrote: Fixed in head of GDB? http://www.nabble.com/Patch-for-the-gdb-problem-%C2%ABValue-being-assigned--to-is-no-longer-active%C2%BB-td23615004.html Thank you very much! Is there any other way to setup the PC to right position? I've always used a monitor reg pc xxx command, even with other hardware debuggers. Never trusted GDB to do this :-) Still not working: (gdb) target remote : Remote debugging using : 0xd800 in ?? () (gdb) monitor reg pc 0xd850 pc (/32): 0xD850 (gdb) si 0xd800 in ?? () Infinite loop detected (gdb) (gdb) monitor reg pc 0xd850 pc (/32): 0xD850 (gdb) info reg r0 0x7453646a 1951622250 r1 0x4b4c4c3e 1263291454 r2 0x56905a50 1452300880 r3 0x3662b5f2 912438770 r4 0x68002683 1744840323 r5 0x61120b0101785776 r6 0x951222d1 2500993745 r7 0x36ad8be1 917343201 r8 0x20af44b6 548357302 r9 0x200312d2 537072338 r100x8802280142615168 r110x20 2097152 r120x10236036 270753846 sp 0x6436a1eb 0x6436a1eb lr 0x82a3e65e 2191779422 pc 0xd800 0xd800 fps0x0 0 cpsr 0xd3 211 (gdb) Is this a BUG on OpenOCD? Best Regards, Alan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [Fwd: tcl questions.]
michal smulski wrote:
When I run this code:
set CONFIG_SYS_HZ_CLOCK16500
global CONFIG_SYS_HZ_CLOCK
proc showAmbaPLL {} {
global CONFIG_SYS_HZ_CLOCK
puts [format CONFIG_SYS_HZ_CLOCK %d $CONFIG_SYS_HZ_CLOCK]
}
I get this message:
Runtime error, file t.tcl, line 198:
can't read CONFIG_SYS_HZ_CLOCK: no such variable
in procedure 'showAmbaPLL' called at file command.c, line 473
What am I doing wrong?
Not sure, it works for me as follows (below are cut paste directly
from my cygwin terminal)
my openocd.cfg =
[NOTE: I am not configuring taps, or anything]
du...@desk ~/ocd/bare
$ cat openocd.cfg
source [find interface/olimex-jtag-tiny.cfg]
telnet_port
gdb_port
my simple 't.tcl' =
du...@desk ~/ocd/bare
$ cat t.tcl
set CONFIG_SYS_HZ_CLOCK 1650
global CONFIG_SYS_HZ_CLOCK
proc duane {} {
global CONFIG_SYS_HZ_CLOCK
puts [format The value is %d $CONFIG_SYS_HZ_CLOCK]
}
du...@desk ~/ocd/bare
$
== telnet session===
Open On-Chip Debugger
source t.tcl
info globals CONFIG_SYS_HZ_CLOCK
CONFIG_SYS_HZ_CLOCK
info globals
CONFIG_SYS_HZ_CLOCK ocd_cpu_list ocd_helptext jim_libpath ocd_HOSTOS
jim_interac
tive
duane
The value is 1650
exit
Connection to host lost.
du...@desk ~
$
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] svn 2600 Cygwin windows build failed at texi !!!
The svn 2600 cannot finalize MAKE under windows cygwin.
Note: openocd.exe is compiled and is working for both Amontec JTAGkey
and Amontec JTAGkey-2
Here the result of the last line of make :
make[2]: Leaving directory
`/cygdrive/c/amontec/openocd_builder/svn/trunk/src'
Making all in doc
make[2]: Entering directory
`/cygdrive/c/amontec/openocd_builder/svn/trunk/doc'
restore=: backupdir=.am$$ \
am__cwd=`pwd` CDPATH=${ZSH_VERSION+.}: cd . \
rm -rf $backupdir mkdir $backupdir \
if (/bin/sh
/cygdrive/c/amontec/openocd_builder/svn/trunk/missing --run
makeinfo --version) /dev/null 21; then \
for f in openocd.info openocd.info-[0-9]
openocd.info-[0-9][0-9] openo
cd.i[0-9] openocd.i[0-9][0-9]; do \
if test -f $f; then mv $f $backupdir; restore=mv; else :; fi; \
done; \
else :; fi \
cd $am__cwd; \
if /bin/sh /cygdrive/c/amontec/openocd_builder/svn/trunk/missing
--run m
akeinfo -I . \
-o openocd.info openocd.texi; \
then \
rc=0; \
CDPATH=${ZSH_VERSION+.}: cd .; \
else \
rc=$?; \
CDPATH=${ZSH_VERSION+.}: cd . \
$restore $backupdir/* `echo ./openocd.info | sed
's|[^/]*$||'`; \
fi; \
rm -rf $backupdir; exit $rc
openocd.texi:12: @include `version.texi': No such file or directory.
openocd.texi:37: warning: undefined flag: VERSION.
openocd.texi:38: warning: undefined flag: UPDATED.
openocd.texi:58: warning: undefined flag: VERSION.
openocd.texi:59: warning: undefined flag: UPDATED.
makeinfo: Removing output file `openocd.info' due to errors; use --force
to pres
erve.
make[2]: *** [openocd.info] Error 1
make[2]: Leaving directory
`/cygdrive/c/amontec/openocd_builder/svn/trunk/doc'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/cygdrive/c/amontec/openocd_builder/svn/trunk'
make: *** [all] Error 2
Press any key to continue . . .
Laurent
http://www.amontec.com
Amontec JTAGkey : ft2232d full-speed usb JTAG 6mhz 5v-to-1.4v
Amontec JTAGkey-2 : ft2232h high-speed usb JTAG 30mhz 5v-to-1.3v RTCK
Amontec JTAGkey-2 makes the openocd as 8x faster !
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
