Re: [Openocd-development] [patch 0/3] openocd.texi updates
On Wednesday 27 May 2009, Zach Welch wrote: Basically after these three patches, NOR and NAND flash docs use parallel structure, and the command index is much more filled out. The NOR docs are now a *LOT* more complete and accurate. Committed, r1936-1938. Very nice work. Keep 'em coming. :) Thanks... However, there are still six flash drivers that are not documented. And the str9xpec driver docs are still a mess (albeit now a *localized* mess); More generally, I am wondering how many users are using this driver. There do not appear to be any examples of the usage of it in the tcl/ tree, though the mailing list might have something archived. It looks like Spencer Oliver committed that code originally in 2007, so I've cc'd him to ensure we get his feedback. Likewise the ocl driver, although at least that one isn't painful to document. The main issue there seems to be a complete lack of description about what an ocl might be. The ECOS flash driver is cryptic too. and the mflash stuff still looks kind of like it doesn't really belong in that chapter. I have cc'd unsik Kim to see what he thinks might be done, since he is the principle author of that code and recently updated those sections. I suspect it should just be its own chapter. But one thing that's missing is a description of just what an mflash is. mflash.com seems unrelated. :) David, could I talk you into taking a stab at the newly added Texinfo sections of The Manual? [1,2] I think a guide for preferred markup and style would help clean up the documentation as much the C style guide should help clean up the code. Maybe. I'm just going by the texinfo manual, which isn't especially hard to understand. You seem to understand Texinfo, and I figure your recent efforts should mean the information is still fresh in your brain. If the Doxygen markup poses an obstacle, I recommend reading the Doxygen Primer and Style Guide (and providing feedback). ;) At the very least, it would be nice to have fairly direct links to on-line documentation and tutorials (as I will do with the links I posted for learning LaTeX). With driver information and style guidance, others can take a look at the str9xpec part of the manual and audit the driver commands and code. The str9xpec stuff has a significant *conceptual* issue to resolve first. Then formatting stuff will be easy. But needing a complete secondary driver just to set a few things which other drivers handle using a few driver-specific commmands ... seems doomed to be forevermore confusing. - Dave Cheers, Zach [1] doc/manual/primer/docs.txt -- contains a skeletal Texinfo Primer [2] doc/manual/style.txt -- contains a skeletal Texinfo Style Guide ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] NEC V850 Core
-Oorspronkelijk bericht- Van: openocd-development-boun...@lists.berlios.de [mailto:openocd-development-boun...@lists.berlios.de] Namens Michel Catudal Verzonden: donderdag 28 mei 2009 5:33 Aan: Duane Ellis; openocd-development Onderwerp: Re: [Openocd-development] NEC V850 Core Duane Ellis a écrit : **THIS*IS*OFF*LIST** The context switching in the NEC devices has no match. Really, I'd like to see how you do this, in a pre-empt context switch there are lots of registers to save, do you have a *specific* NEC support group you work with? I'd like a name or two, local guys here are clue-less. Factory guy came in 5 months ago, gave us a training session about PM Plus not able to answer questions I had. This is not something a salesman is telling me but actual data from NEC where they compare the AR7TDMI, Cortex-M3 and V850ES According to their chart, an interrupt takes 24 cycles for ARM7TDMI, 12 for Cortex-M3 and 4 for their new V850ES. I don't understand why there is so much emphasis on the number of cycles it takes to get into an interrupt. Sounds more like a sales pitch to me. If your software and hardware is designed well, the number of interrupts is few and a lot is done inside an interrupt routine. In other words: the number of cycles to get into an interrupt is usually neglegible compared against the number of cycles it takes to actually execute the interrupt service routine. Also, it is very hard to have a fixed time between the interrupt and entering the interrupt service routine. Other interrupts may be pending or some instructions may take longer. The hardware should allow for delayed interrupts without going up in smoke. Hence, the number of cycles it takes to enter the interrupt service routine becomes less relevant anyway. I did a design with an LPC2000 series controller (ARM7TDMI) from NXP in which I used a 300kHz timer interrupt to implement a DC-DC converter in software (voltage control and cycle-by-cycle current limitting). I didn't need to use the FIQ (fast interrupt) or assembly code. The timing isn't really critical because the LPC2000 has some really nifty features in its hardware. Heck, its all ARM 16 bit thumb code too. Anyway, just get as much mips as you can. The V850 sounds like a hard to get part to me if you're not buying large quantities. I'd stick with an ARM controller. There is a lot of choice and moving to another manufacturer doesn't require to learn a whole new toolchain and CPU. Nico Coesel ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] openocd too slow
I tried openocd r1836 and r1938 with the same results.
I need to flash an AT91SAM7X256 (the board is evaluation buord from
atmel) with an Amontec jtagkey-tiny.
My PC runs ubuntu linux 8.10 64bit, and I use libftdi 0.16 (configured
as defaults)
PC is an intel core2 q8300 and 4GB ram
I run openocd with the following command line
$ sudo openocd -f scrips/jtagkey.cfg -f scrips/sam7x256.cfg -d 3
with scrips:
8--- jtagkey.cfg 8---
#
# Amontec JTAGkey
#
# http://www.amontec.com/jtagkey.shtml
#
#daemon configuration
telnet_port
gdb_port
interface ft2232
ft2232_device_desc Amontec JTAGkey A
ft2232_layout jtagkey
ft2232_vid_pid 0x0403 0xcff8
8---8---8---
and
8--- sam7x256.cfg 8---
#use combined on interfaces or targets that can't set TRST/SRST separately
reset_config srst_only srst_pulls_trst
if { [info exists CHIPNAME] } {
set _CHIPNAME $CHIPNAME
} else {
set _CHIPNAME sam7x256
}
if { [info exists ENDIAN] } {
set _ENDIAN $ENDIAN
} else {
set _ENDIAN little
}
if { [info exists CPUTAPID ] } {
set _CPUTAPID $CPUTAPID
} else {
set _CPUTAPID 0x3f0f0f0f
}
jtag newtap $_CHIPNAME cpu -irlen 4 -ircapture 0x1 -irmask 0xf
-expected-id $_CPUTAPID
set _TARGETNAME [format %s.cpu $_CHIPNAME]
target create $_TARGETNAME arm7tdmi -endian $_ENDIAN -chain-position
$_TARGETNAME -variant arm7tdmi
$_TARGETNAME configure -event reset-init {
# disable watchdog
mww 0xfd44 0x8000
# enable user reset
mww 0xfd08 0xa501
# CKGR_MOR : enable the main oscillator
mww 0xfc20 0x0601
sleep 10
# CKGR_PLLR: 96.1097 MHz
mww 0xfc2c 0x00481c0e
sleep 10
# PMC_MCKR : MCK = PLL / 2 ~= 48 MHz
mww 0xfc30 0x0007
sleep 10
# MC_FMR: flash mode (FWS=1,FMCN=60)
mww 0xff60 0x003c0100
sleep 100
}
$_TARGETNAME configure -work-area-virt 0 -work-area-phys 0x0020
-work-area-size 0x4000 -work-area-backup 0
#flash bank driver base size chip_width bus_width
flash bank at91sam7 0 0 0 0 0
# For more information about the configuration files, take a look at:
# openocd.texi
8---8---8---
then I connect via telnet to port
I run the following commands
arm7_9 dcc_downloads enable
dcc downloads are enabled
arm7_9 fast_memory_access enable
fast memory access is enabled
flash write_image erase firmware.bin 0x10 bin
auto erase enabled
wrote 44616 byte from file firmware.bin in 11.045264s (3.944705 kb/s)
openocd (both r1836 and r1938) are configured using first bootstrap and
./configure --enable-ft2232_libftdi --disable-werror --enable-maintainer-mode
I attach debug trace outputed from openocd.
what is wrong? How can I speed up the process?
Maybe the opensource libftdi? Do I need to try with ftd2xx driver
provided by Amontec? I don't think that is for 64bit systems, isn't
it?
thanks
--
Assioma di Cole: La somma dell'intelligenza sulla Terra è costante;
la popolazione è in aumento
Massimiliano Cialdi
cia...@gmail.com
massimiliano.cia...@powersoft.it
debug_trace.txt.gz
Description: GNU Zip compressed data
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] NEC V850 Core
**ALL** This subject of this thread no longer is about OpenOCD or JTAG. It should not remain on *THIS* (a jtag debugging mailing list) and should end (on this list) now. If you feel you should reply, please do so *off*list* -Duane ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] support avr32
Hi Duane, On 5/27/09, Duane Ellis open...@duaneellis.com wrote: FYI - most of UrJTAG's support is *BOUNDARY*SCAN* - based external chip flash programing via boundary scan Arggg, then it will not help too much! There is a variant/fork of UrJTAG - (link below) that ADI supports - a private fork ADI maintains - for GDB Remote debug. Thank you for links, Alan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch 0/3] openocd.texi updates
Here are more doc updates - get rid of most PDF generation errors, like the line too long ones, as well as the can't do sane linebreak warnings - restructure flash driver descriptions so each driver's info is in one place, not scattered through up to three locations - restructure flash command presentation This was done with reference to the code, so many errors and omissions were also fixed. Basically after these three patches, NOR and NAND flash docs use parallel structure, and the command index is much more filled out. The NOR docs are now a *LOT* more complete and accurate. However, there are still six flash drivers that are not documented. And the str9xpec driver docs are still a mess (albeit now a *localized* mess); and the mflash stuff still looks kind of like it doesn't really belong in that chapter. One point i would make - you have added a comment that the mass_erase cmds are pointless. Ttue the same thing can be acheived using erase_address or erase_sector but you need to know the flash info. mass_erase enables the whole device to be erased without knowing this kind of information. perhaps we can add a feature that will erase the whole bank, eg. flash erase_all bank number or modify one the of the existing erase functions. Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Config file cannot work on ARM926EJS board.
Just took a quick look and the one thing that jumped out at me was your JTAG
speed. jtag_speed is a depreciated command ... it should be jtag_khz. I
too have a eval board based on a ARM926EJS core ... it is a Atmel
at91sam9260ek based board. The thing I ran into was my board initially runs
using the 32k clock which required me to use a setting of jtag_khz 4 until
all the required registers are initialized (Clocks, SDRAM timing etc.) and
then I could bump up to jtag_khz 3000 and it would work with my board.
Not sure that helps you but maybe my experience applies to your situation.
Regards,
Brian
On Tue, May 26, 2009 at 9:18 PM, jie.zeng jie.z...@soliton.com.cn wrote:
Hello list,
I'm new to OpenOCD. Now I'm trying to make the config files for our new
eval board which use the ARM926EJS core. Many problems come up that I
can't solve alone.
Environment:
Eval Board and CPU core is ARM926EJS.
JTAG Adapter is a OpenJTAG compatible one (USB=JTAG).
Debian(etch).
OpenOCD is the lastest version from svnroot.
First please have a look my config files:
### interface.cfg ###
interface ft2232
jtag_speed 0
ft2232_vid_pid 0x1457 0x5118
ft2232_layout jtagkey_prototype_v1
ft2232_device_desc USB=JTAGRS232
### flash.cfg ###
# flash bank driver base size chip_width bus_width target#
flash bank cfi 0x1000 0x0100 2 2 0
### target.cfg ###
reset_config trst_and_srst
if { [info exists CHIPNAME] } {
set _CHIPNAME $CHIPNAME
} else {
set _CHIPNAME arm926ejs
}
if { [info exists ENDIAN] } {
set _ENDIAN $ENDIAN
} else {
set _ENDIAN little
}
if { [info exists CPUTAPID ] } {
set _CPUTAPID $CPUTAPID
} else {
# From ARM926EJS Tech Ref Manual
set _CPUTAPID 0x07926F0F
}
if { [info exists FLASHTAPID ] } {
set _CPUTAPID $FLASHTAPID
}
if { [info exists BSTAPID ] } {
set _CPUTAPID $BSTAPID
}
# cpu tap
jtag newtap $_CHIPNAME cpu -irlen 4 -ircapture 0x1 -irmask 0xf
-expected-id $_CPUTAPID
# flash tap
#jtag newtap $_CHIPNAME flash -irlen 4 -ircapture 0x1 -irmask 0xf
# bs tap
#jtag newtap $_CHIPNAME bs -irlen 4 -ircapture 0x1 -irmask 0xf
-expected-id $_BSTAPID
set _TARGETNAME [format %s.cpu $_CHIPNAME]
# target create NAME TYPE PARAMS ...
target create $_TARGETNAME arm926ejs \
-endian $_ENDIAN \
-chain-position $_TARGETNAME \
-variant arm926ejs
jtag_nsrst_delay 200
jtag_ntrst_delay 200
### board.cfg ###
debug_level 3
telnet_port
gdb_port
source [find config/interface.cfg]
source [find config/target.cfg]
source [find config/flash.cfg]
$_TARGETNAME configure -event reset-init {
# needed and whats it, its from board datasheet register part??
mww 0x7200 0x0021 # Memory Interface Config
mww 0x7204 0x0020 # DRAM Param Config
mww 0x7210 0x322b8e83 # DRAM Timing Param 0
mww 0x7214 0x140F10C8 # DRAM Timing Param 1
mww 0x7218 0x0007030D # DRAM Timing Param 2
mww 0x7230 0x0030 # DDQ Output Delay Control(DDR only)
#
# Bank 0 at 0x1000
# Bank 1 at 0x1100
# Bank 2 at 0x1200
# Bank 3 at 0x1300
#
mww 0x7300 0x # Mem Bank 0 Config
mww 0x7600 0x # Remap ?
# whats it
flash probe 0
}
$_TARGETNAME configure \
-work-area-phys 0x30 \
-work-area-size 65536 \
-work-area-backup 0
That's all my current file. When I run openocd, I got following output
and I'm sure something must be wrong.
### output.log ###
c...@cj:~/openocd/bin$ sudo ./openocd -f board.cfg
Open On-Chip Debugger 0.2.0-in-development (2009-05-26-10:57) svn:1913M
BUGS? Read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS
$URL: svn://svn.berlios.de/openocd/trunk/src/openocd.c $
Debug: 6 0 command.c:88 script_command(): script_command - telnet_port
Debug: 7 0 command.c:105 script_command(): script_command - telnet_port,
argv[0]=ocd_telnet_port
Debug: 8 0 command.c:105 script_command(): script_command - telnet_port,
argv[1]=
Debug: 10 0 command.c:88 script_command(): script_command - gdb_port
Debug: 11 0 command.c:105 script_command(): script_command - gdb_port,
argv[0]=ocd_gdb_port
Debug: 12 0 command.c:105 script_command(): script_command - gdb_port,
argv[1]=
Debug: 13 1 configuration.c:83 find_file(): found config/interface.cfg
Debug: 15 1 command.c:88 script_command(): script_command - interface
Debug: 16 1 command.c:105 script_command(): script_command - interface,
argv[0]=ocd_interface
Debug: 17 1 command.c:105 script_command(): script_command - interface,
argv[1]=ft2232
Debug: 19 1 command.c:88 script_command(): script_command - jtag_speed
Debug: 20 1 command.c:105 script_command(): script_command - jtag_speed,
argv[0]=ocd_jtag_speed
Debug: 21 1 command.c:105 script_command(): script_command - jtag_speed,
argv[1]=0
Debug: 22 1 jtag.c:2767 handle_jtag_speed_command(): handle jtag speed
User : 23 1 command.c:380 command_print(): jtag_speed: 0
Debug: 25 1 command.c:88 script_command(): script_command -
[Openocd-development] meminfo cmd
Hi, I notice that the meminfo cmd seems to be zylin specific (ecosboard.c/ioutil.c). Currently this is in the openocd texi - this should really be removed. Thoughts? Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] On Resets
On Wed, May 27, 2009 at 11:25 PM, Magnus Lundin lun...@mlu.mine.nu wrote: Michael Schwingen wrote: Magnus Lundin wrote: Michael Bruck wrote: On Tue, May 26, 2009 at 7:47 PM, Magnus Lundin lun...@mlu.mine.nu wrote: move to TLR works for all current states. It is 7 steps with TMS high, that takes you to TAP_RESET froma any starting state. Moving to TLR from an *unknown* state doesn't work because we pretend that there is no such thing as the TAP being in an unknown state. We rather initialize the boot state to be TAP_RESET. Which is not only false but also leads low level drivers to believe that nothing needs to be done. In particular the ft2232 driver says statemove TAP_RESET - TAP_RESET is redundant and does not need to be executed (see ft2232_execute_statemove() ). I have not had time look look closely into this but I think that what must be decided is the exact semantics of state_move(end_state) - Is it, as I think it should be : move to end_state, and if we are already there do nothing ? That would make the implementations unnecessary complex. And you duplicate a lot of logic in each driver. I would even remove the 'if' that causes the TAP_RESET-TAP_RESET to be ignored because such an optimization should be performed uniformly for all JTAG devices by the jtag.c layer. I think in case of TAP_RESET, an exception to that rule might be useful. Would it make sense to define that a driver has to make sure a requested TAP_RESET end state really ends in TAP_RESET state, regardless of the previous state, ie. the driver needs to always perform the necessary number of clocks with TMS=1 without any clever optimizations? That way, upper layers would have an easy way to re-synchronize state even if openocd and the target do not agree on what the current state is. My preferred solution would be to keep statemove simple (just the table lookup) and add a JTAG_TLR_RESET instruction to the interface which in turn would just clock out the 1's. In the long run we could then add an undefined tap state (for example TAP_INVALID) and enforce that only the jtag_add_tlr command can be called from that. This would help finding reset problems not only after startup but also when a system reset is performed (which would set that as well). I see your point and I basically agree, the problem is that state_move uses the state move table(s), that currently do use 7 step reset-reset transitions, but there is no contract for this. I would prefer the contract in the end to be move within the table with well-defined start and end states to make it as simple as possible. Whatever can be done in jtag.c should be done there to avoid code duplication and to avoid inconsistent behavior when changing JTAG interfaces. That includes the differentiation between a vanilla statemove and a TLR from undefined state. And it includes turning a statemove into a NOP if start state and end state are equal (and if that is the behavior that the community in fact wants). I also dislike the idea of having to put exceptions like this in the interface drivers. I think we also should look into how jtag_add_runtest is handled because this is a similar situation where we want to reach a certain endstate and then guarante a certain number of transitions in this state. Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] meminfo cmd
On Thu, May 28, 2009 at 5:12 PM, Spencer Oliver s...@spen-soft.co.uk wrote: Hi, I notice that the meminfo cmd seems to be zylin specific (ecosboard.c/ioutil.c). Currently this is in the openocd texi - this should really be removed. This is not Zylin specific. This is useful for embedded hosts to check how much memory is lefte(e.g. uClinux or eCos). This can be used in regression testing scripts to check for memory leaks. It probably has little value on PC (Linux/Windows/Mac) hosts where the total system memory available poorly corelated to what OpenOCD is using. There are much more effective tools on PCs (valgrind, sp?) to track this sort of problems. -- Ø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] On Resets
In the mists of time SRST TRST probably had some well defined function and meaning. However, over time MCU vendors have repurposed these signals, tied them to other signals, etc. for various mysterious and more or less well intended purposes. The reset_config doc should explain that what SRST and TRST does is actually HIGHLY target and architecture specific. OpenOCD tries to allieviate the situation using two techniques: - allow target scripts to define which signals that should be used - the more common tricky repurposing of these signals such as having srst pull trst are supported by reset_config There ARE interfaces that do not have TRST and SRST both, but really one is much better off considering reset_config a configuration on how to operate the target. If TRST support is *required* by the target, e.g. XScale, then interfaces that do not support that just will not work. -- Ø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 0/3] openocd.texi updates
On Thursday 28 May 2009, Spencer Oliver wrote: One point i would make - you have added a comment that the mass_erase cmds are pointless. Ttue the same thing can be acheived using erase_address or erase_sector but you need to know the flash info. mass_erase enables the whole device to be erased without knowing this kind of information. perhaps we can add a feature that will erase the whole bank, eg. flash erase_all bank number or modify one the of the existing erase functions. True, there's no flash erase command that accepts a bank; they all use addresses. That's another example of the command set not being orthogonal. ;) I agree that having the bank-address commands offer the same functionality as the target-address ones would be good. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] On Resets
On Thu, May 28, 2009 at 5:41 PM, Øyvind Harboe oyvind.har...@zylin.com wrote: There ARE interfaces that do not have TRST and SRST both, but really one is much better off considering reset_config a configuration on how to operate the target. If TRST support is *required* by the target, e.g. XScale, then interfaces that do not support that just will not work. Is that a documented behavior on XScale or the result of testing with OpenOCD ? Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch 0/3] openocd.texi updates
On Thursday 28 May 2009, Spencer Oliver wrote: One point i would make - you have added a comment that the mass_erase cmds are pointless. Ttue the same thing can be acheived using erase_address or erase_sector but you need to know the flash info. mass_erase enables the whole device to be erased without knowing this kind of information. perhaps we can add a feature that will erase the whole bank, eg. flash erase_all bank number or modify one the of the existing erase functions. True, there's no flash erase command that accepts a bank; they all use addresses. That's another example of the command set not being orthogonal. ;) I agree that having the bank-address commands offer the same functionality as the target-address ones would be good. An 'erase all' command would be nice. A complete erase is often required. It is a big plus for automated programming. One thing less to detect. Nico Coesel ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] openocd too slow
On Thursday 28 May 2009 12:57:38 massimiliano cialdi wrote: Maybe the opensource libftdi? Do I need to try with ftd2xx driver provided by Amontec? I don't think that is for 64bit systems, isn't it? Hi, You could try ftd2xx lib directly from ftdichip -- they have x86_64 version. Here is link: http://www.ftdichip.com/Drivers/D2XX.htm -- vylu ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [patch] openocd.texi arch/core commands
Start converting the architecture-specific commands to @deffn format,
reviewing against the code.
* armv4_5 disassemble ... now documented; although Jazelle code
is not handled
* It's armv4_5 core_state not core_mode; although Jazelle state
is not handled
* arm7/9 debug commands ... now with other arm7_9 commands, no
longer in a separate section
* arm926ejs cp15 ... previous description was broken, it matched
the code for arm920t instead
* Have separate subsections for ARMv4/ARMv5, ARMv6, and ARMv7; the
latter are new
* Move core-specific descriptions into sub-subsections under those
architectures; XScale and ARM11 descriptions are new
The new XScale and ARM11 command descriptions surely need elaboration
and review. ARM CP15 operation descriptions in general seem to be
confused and incomplete.
At this point I don't thnk any architecture-specific or core-specific
commands remain undocumented, but I might have missed something...
---
doc/openocd.texi | 516 +
1 file changed, 366 insertions(+), 150 deletions(-)
Start converting the architecture-specific commands to @deffn format,
reviewing against the code.
* armv4_5 disassemble ... now documented; although Jazelle code
is not handled
* It's armv4_5 core_state not core_mode; although Jazelle state
is not handled
* arm7/9 debug commands ... now with other arm7_9 commands, no
longer in a separate section
* arm926ejs cp15 ... previous description was broken, it matched
the code for arm920t instead
* Have separate subsections for ARMv4/ARMv5, ARMv6, and ARMv7; the
latter are new
* Move core-specific descriptions into sub-subsections under those
architectures; XScale and ARM11 descriptions are new
The new XScale and ARM11 command descriptions surely need elaboration
and review. ARM CP15 operation descriptions in general seem to be
confused and incomplete.
At this point I don't thnk any architecture-specific or core-specific
commands remain undocumented, but I might have missed something...
---
doc/openocd.texi | 516 +
1 file changed, 366 insertions(+), 150 deletions(-)
--- a/doc/openocd.texi
+++ b/doc/openocd.texi
@@ -2482,8 +2482,9 @@ Write the image @file{filename} to the c
A relocation @var{offset} may be specified, in which case it is added
to the base address for each section in the image.
The file [...@var{type}] can be specified
-explicitly as @option{bin} (binary), @option{ihex} (Intel hex), @option{elf}
-(ELF file) or @option{s19} (Motorola s19).
+explicitly as @option{bin} (binary), @option{ihex} (Intel hex),
+...@option{elf} (ELF file), @option{s19} (Motorola s19).
+...@option{mem}, or @option{builder}.
The relevant flash sectors will be erased prior to programming
if the @option{erase} parameter is given.
The flash bank to use is inferred from the @var{address} of
@@ -3463,188 +3464,403 @@ Profiling samples the CPU's program coun
@end itemize
-...@section Target Specific Commands
-...@cindex Target Specific Commands
+...@section Architecture and Core Specific Commands
+...@cindex Architecture Specific Commands
+...@cindex Core Specific Commands
+Most CPUs have specialized JTAG operations to support debugging.
+OpenOCD packages most such operations in its standard command framework.
+Some of those operations don't fit well in that framework, so they are
+exposed here using architecture or implementation specific commands.
-...@section Architecture Specific Commands
-...@cindex Architecture Specific Commands
+...@subsection ARMv4 and ARMv5 Architecture
+...@cindex ARMv4 specific commands
+...@cindex ARMv5 specific commands
-...@subsection ARMV4/5 specific commands
-...@cindex ARMV4/5 specific commands
+These commands are specific to ARM architecture v4 and v5,
+including all ARM7 or ARM9 systems and Intel XScale.
+They are available in addition to other core-specific
+commands that may be available.
-These commands are specific to ARM architecture v4 and v5, like all ARM7/9 systems
-or Intel XScale (XScale isn't supported yet).
-...@itemize @bullet
-...@item @b{armv4_5 reg}
-...@cindex armv4_5 reg
-...@*display a list of all banked core registers, fetching the current value from every
+...@deffn Command {armv4_5 core_state} [arm|thumb]
+Displays the core_state, optionally changing it to process
+either @option{arm} or @option{thumb} instructions.
+The target may later be resumed in the currently set core_state.
+(Processors may also support the Jazelle state, but
+that is not currently supported in OpenOCD.)
+...@end deffn
+
+...@deffn Command {armv4_5 disassemble} address count [thumb]
+...@cindex disassemble
+Disassembles @var{count} instructions starting at @var{address}.
+If @option{thumb} is specified, Thumb (16-bit) instructions are used;
+else ARM (32-bit) instructions are used.
+(Processors may also support the Jazelle state,
Re: [Openocd-development] [patch 0/3] openocd.texi updates
On Thursday 28 May 2009, Nico Coesel wrote: An 'erase all' command would be nice. A complete erase is often required. It is a big plus for automated programming. One thing less to detect. -ENOPATCH :) ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] On Resets
On Thursday 28 May 2009, Øyvind Harboe wrote: In the mists of time SRST TRST probably had some well defined function and meaning. I think they still *do* ... but it seems vendors have felt free to play with at least TAP resets in ways that prevent tools that conform only to JTAG specs from working as desired. One recently-presented example is that MSP430 TAP reset sequence [1] (must pulse TMS twice with TCK and TDI high to ensure a fuse check is done). That doesn't change TRST or SRST semantics. Likewise, if Xscale requires TRST ... that doesn't necessarily need to cause conformance issues. Seems to me one of the issues is just that vendors don't want to have debugger support be a pure cost center. They want *some* ways to couple it to some income stream, and build an ecosystem around that. So features arrive that involve a little more work than just conform to JTAG spec. No problem when docs are available ... but sometimes they aren't. - Dave [1] https://lists.berlios.de/pipermail/openocd-development/2009-May/007242.html ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch] openocd.texi arch/core commands
On Thu, 2009-05-28 at 14:55 -0700, David Brownell wrote: Start converting the architecture-specific commands to @deffn format, reviewing against the code. * armv4_5 disassemble ... now documented; although Jazelle code is not handled * It's armv4_5 core_state not core_mode; although Jazelle state is not handled * arm7/9 debug commands ... now with other arm7_9 commands, no longer in a separate section * arm926ejs cp15 ... previous description was broken, it matched the code for arm920t instead * Have separate subsections for ARMv4/ARMv5, ARMv6, and ARMv7; the latter are new * Move core-specific descriptions into sub-subsections under those architectures; XScale and ARM11 descriptions are new The new XScale and ARM11 command descriptions surely need elaboration and review. ARM CP15 operation descriptions in general seem to be confused and incomplete. At this point I don't thnk any architecture-specific or core-specific commands remain undocumented, but I might have missed something... --- doc/openocd.texi | 516 + 1 file changed, 366 insertions(+), 150 deletions(-) Committed, r1939. --Z ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] support avr32
Alan Carvalho de Assis wrote: Hi Duane, On 5/27/09, Duane Ellis open...@duaneellis.com wrote: FYI - most of UrJTAG's support is *BOUNDARY*SCAN* - based external chip flash programing via boundary scan Arggg, then it will not help too much! No - actually it is useful for other purposes... a method to flash something - however slow it may be - is better then no method to flash something, or the ability to flash a board with a CPU you do not support. UrJTAG's approach is to read the BSDL file -figure out the bus structure - and read and write memory locations. One could - create some interesting things. And - most importantly - it can be used to create a debug tool useful for board bring up. For example - you have a new board you are trying to bring up - nothing works - you can use BSDL - to wiggle/pulse a pin and probe it out. I'd be *REALLY* happy if I could create a JTAG hardware test - using BSDL files... Granted, for production purposes - it would be very slow. But - for simple prototype work - it would be great. Sure, production hardware jtag tests that take 10 minutes are *TOO*LONG* - however - the ability to perform a hardware jtag test on a *SIMPLE* 5 piece prototype build - is another matter. I'd let it run over lunch - or while I am in a meeting, when I'm back I know know my prototype is mostly working :-) YEA! That does not yet exist. -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] support avr32
On Fri, May 29, 2009 at 7:22 AM, Duane Ellis open...@duaneellis.com wrote: No - actually it is useful for other purposes... a method to flash something - however slow it may be - is better then no method to flash something, or the ability to flash a board with a CPU you do not support. UrJTAG's approach is to read the BSDL file -figure out the bus structure - and read and write memory locations. One could - create some interesting things. And - most importantly - it can be used to create a debug tool useful for board bring up. For example - you have a new board you are trying to bring up - nothing works - you can use BSDL - to wiggle/pulse a pin and probe it out. I'd be *REALLY* happy if I could create a JTAG hardware test - using BSDL files... Granted, for production purposes - it would be very slow. But - for simple prototype work - it would be great. Sure, production hardware jtag tests that take 10 minutes are *TOO*LONG* - however - the ability to perform a hardware jtag test on a *SIMPLE* 5 piece prototype build - is another matter. I'd let it run over lunch - or while I am in a meeting, when I'm back I know know my prototype is mostly working :-) YEA! That does not yet exist. How does those higher end tester like Agilent 3070 in circuit tester work? Do they require extra add-on for JTAG related stuff like Boundary Scan? Do they use BDSL files? I know they can flash some MCUs but not all. Last time we have to use off-line programming for TMS470R1A64/A256 since the support was not ready yet. -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [patch] openocd.texi ... more NOR flash drivers
Provide basic documentation for some of the other flash drivers.
avr ... looks incomplete, may work with one AVR8 microcontroller
ecosflash ... can't find docs
lpc288x ... an NXP part, driver seems lpc2888-specific
ocl ... some arm7/arm9 thing, can't find docs
pic32mx ... looks incomplete, for PIC32MX (MIPS 4K) devices
tms470 ... for TI TMS470 parts
Still seems to be mostly arm7tdmi... several of these have no
users in the current tree.
---
doc/openocd.texi | 74 +
1 file changed, 74 insertions(+)
Provide basic documentation for some of the other flash drivers.
avr ... looks incomplete, may work with one AVR8 microcontroller
ecosflash ... can't find docs
lpc288x ... an NXP part, driver seems lpc2888-specific
ocl ... some arm7/arm9 thing, can't find docs
pic32mx ... looks incomplete, for PIC32MX (MIPS 4K) devices
tms470 ... for TI TMS470 parts
Still seems to be mostly arm7tdmi... several of these have no
users in the current tree.
---
doc/openocd.texi | 74 +
1 file changed, 74 insertions(+)
--- a/doc/openocd.texi
+++ b/doc/openocd.texi
@@ -2625,6 +2625,19 @@ the appropriate at91sam7 target.
@end deffn
@end deffn
+...@deffn {Flash Driver} avr
+The AVR 8-bit microcontrollers from Atmel integrate flash memory.
+...@emph{the current implementation is incomplete.}
+...@comment - defines mass_erase ... pointless given flash_erase_address
+...@end deffn
+
+...@deffn {Flash Driver} ecosflash
+...@emph{no idea what this is...}
+The @var{ecosflash} driver defines one mandatory parameter,
+the name of a modules of target code which is downloaded
+and executed.
+...@end deffn
+
@deffn {Flash Driver} lpc2000
Most members of the LPC2000 microcontroller family from NXP
include internal flash and use ARM7TDMI cores.
@@ -2649,6 +2662,46 @@ flash bank lpc2000 0x0 0x7d000 0 0 $_TAR
@end example
@end deffn
+...@deffn {Flash Driver} lpc288x
+The LPC2888 microcontroller from NXP needs slightly different flash
+support from its lpc2000 siblings.
+The @var{lpc288x} driver defines one mandatory parameter,
+the programming clock rate in Hz.
+LPC flashes don't require the chip and bus width to be specified.
+
+...@example
+flash bank lpc288x 0 0 0 0 $_TARGETNAME 1200
+...@end example
+...@end deffn
+
+...@deffn {Flash Driver} ocl
+...@emph{no idea what this is, other than using some arm7/arm9 core.}
+
+...@example
+flash bank ocl 0 0 0 0 $_TARGETNAME
+...@end example
+...@end deffn
+
+...@deffn {Flash Driver} pic32mx
+The PIC32MX microcontrollers are based on the MIPS 4K cores,
+and integrate flash memory.
+...@emph{the current implementation is incomplete.}
+
+...@example
+flash bank pix32mx 0 0 0 0 $_TARGETNAME
+...@end example
+
+...@comment numerous *disabled* commands are defined:
+...@comment - chip_erase ... pointless given flash_erase_address
+...@comment - lock, unlock ... pointless given protect on/off (yes?)
+...@comment - pgm_word ... shouldn't bank be deduced from address??
+Some pic32mx-specific commands are defined:
+...@deffn Command {pic32mx pgm_word} address value bank
+Programs the specified 32-bit @var{value} at the given @var{address}
+in the specified chip @var{bank}.
+...@end deffn
+...@end deffn
+
@deffn {Flash Driver} stellaris
All members of the Stellaris LM3Sxxx microcontroller family from
Texas Instruments
@@ -2738,6 +2791,27 @@ The @var{num} parameter is a value shown
@end deffn
+...@deffn {Flash Driver} tms470
+Most members of the TMS470 microcontroller family from Texas Instruments
+include internal flash and use ARM7TDMI cores.
+This driver doesn't require the chip and bus width to be specified.
+
+Some tms470-specific commands are defined:
+
+...@deffn Command {tms470 flash_keyset} key0 key1 key2 key3
+Saves programming keys in a register, to enable flash erase and write commands.
+...@end deffn
+
+...@deffn Command {tms470 osc_mhz} clock_mhz
+Reports the clock speed, which is used to calculate timings.
+...@end deffn
+
+...@deffn Command {tms470 plldis} (0|1)
+Disables (@var{1}) or enables (@var{0}) use of the PLL to speed up
+the flash clock.
+...@end deffn
+...@end deffn
+
@subsection str9xpec driver
@cindex str9xpec
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch] openocd.texi ... more NOR flash drivers
On Thu, 2009-05-28 at 18:16 -0700, David Brownell wrote: Provide basic documentation for some of the other flash drivers. avr ... looks incomplete, may work with one AVR8 microcontroller ecosflash ... can't find docs lpc288x ... an NXP part, driver seems lpc2888-specific ocl ... some arm7/arm9 thing, can't find docs pic32mx ... looks incomplete, for PIC32MX (MIPS 4K) devices tms470 ... for TI TMS470 parts Still seems to be mostly arm7tdmi... several of these have no users in the current tree. --- doc/openocd.texi | 74 + 1 file changed, 74 insertions(+) Committed, r1941. --Z ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.2.0 Status Update
On Fri, May 29, 2009 at 10:04 AM, Zach Welch z...@superlucidity.net wrote: The following tasks appear to be pending for the 0.2.0 release: - fix OMAP3 problems reported by Dick Behme (or did these get resolved?) - final packaging fix-ups (RPM file layout) - reporting/testing tools - documentation: - updates and clean-ups for The Guide (openocd.texi): - document commands for str9pec, ocl, xscale, arm11, and others - remove 'variant' test from most of The Guide. - add expiration dates for all deprecated calls. - update and review The Manual (doxygen) - add Quick/Full/Hardware References? (seems possible and worth doing) - updates for configuration files: - c01.cfg and c02.cfg - others? What about the J-Link issues with various target in the thread TMS470 Scripts? TMS470: https://lists.berlios.de/pipermail/openocd-development/2009-May/007391.html USR8200 (IXP422): https://lists.berlios.de/pipermail/openocd-development/2009-May/007403.html STM32: https://lists.berlios.de/pipermail/openocd-development/2009-May/007406.html For my short time experiences with OpenOCD/J-Link, it has been much more usable now. But it seems there are still quite some issues with J-Link (different versions). Maybe this will not make it to 0.2.0 though. -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.2.0 Status Update
(sorry for sending to Zach and not to the list, IMHO that Reply-To behaviour is annoying, despite what was written about that in the past) From the ordinary-user point of view. - ft2232 high-speed device support Does anyone use those? They are still pretty new and I haven't seen any finished interface with them. IMHO this is not required for 0.2.0 - finish work to allow parts of libopenocd to be exposed. IMHO also not required for 0.2.0, as there were no tests of that lib (?) 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
