Re: [Openocd-development] Google presentation on OpenOCD Gerrit experience
On 11/24/2011 3:28 AM, Øyvind Harboe wrote: Comments welcome! https://docs.google.com/present/view?id=dhftn35p_14s2xxcbt3 Very good, and quite interesting. -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] PCB tips and tricks
This is a bit off-topic - but I'll offer this: ??? to make drills metalization at home to produce advanced two layerpcb... maybe you guys know some tricks? ??? I have not found a solution that works in a small-volume hobby setting. I really don't like messing with the Ferric Chloride chemicals to etch the board, I did that 30+ years ago, it's messy and nasty, my results where very poor, inconsistent, and I never really did enough boards to make it worth while. Today the solutions below are FAR better and cheap enough! For those of you in the USA, I have found these two places useful: == Option 1 www.expresspcb.com They have a simple mini-board service, board is fixed size: 64mm x 96mm (2.5in by 3.8in) Double sided, no more then 350 holes, 3 boards, and only in sets of 3 boards. In the USA, we get 3 day delivery after order. No solder mask: $51 + $10 shipping. W/ solder mask: $75 + $10 shipping QTY 3 boards, and only in sets of 3 boards. 4layer w/mask: $98 + $10 shipping They say they ship to europe for about $45 (base price for many boards) I believe these are Tin/Lead - and not RoHS. Not sure if that matters to you, as this is hobby level stuff. Why so cheap: (a) their software does the pcb design. (b) Their software does DRC for their price, and their system (c) Their software submits into their automatic system (d) The can efficiently panel up these boards with other boards (e) Hole count is reasonable (f) Simple shipping scheme - USPS priority mail. ie: It is ZERO TOUCH - I think the only time a human touches it, is when they put it in the envelope. == Option 2 - not sure about europe sales andwww.pcb123.com - aka: SUNSTONE They support EAGLE layouts BOTH have clunky simple FREE schematic/pcb design software, they come with a large parts catalog from Digikey (well known here in the USA) Above are of course hobby grade tools, nothing like the guys at work use, (mentor graphics, they routinely do 10 layer complex, extremely high density layouts). You get what you pay for. Your next step is to buy solder paste, create a reflow oven, etc. or do all of this by hand Just think of the looks your Significant Other will give you when you make one! Priceless! http://www.seattlerobotics.org/encoder/26/oven_art.htm And: http://www.youtube.com/watch?v=LQRcxGjuORM And: http://www.circuitcellar.com/library/print/0704/Lacoste_168/index.htm http://www.circuitcellar.com/library/print/0704/Lacoste_168/Lacoste-168.pdf And: http://www.instructables.com/id/Toaster-Oven-Reflow-Soldering-BGA/ here's a couple solution with a frying pan... I have my doubts... I know people who have done the toaster oven method. I've always done the hand-solder method. http://www.sparkfun.com/tutorials/59 http://www.youtube.com/watch?v=FD-PQ85bGJQNR=1 -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] GPL wiz
oyvind - new files, except for config and macro files, must have the oyvind gpl 2 or later license header and it must state the copyright oyvind holder(you in this case). richardI have been instructed we can only make the contribution if no richard explicit copyright claim is required. Is that acceptable? In situations like this, the GNU people ask that the author place their work(changes) in the public domain, and disclaim copyrights to their work. REFERENCE: http://www.gnu.org/prep/maintain/html_node/Copyright-Papers.html The relevant text is: Would you be willing to sign a copyright disclaimer to put this change in the public domain, so that we can install it in package? I think that is exactly what richard is saying his employer (Qualcomm) wants him to do. In the OPENOCD tradition, a post to the mailing list sort of signs it, I don't think open ocd has ever requested physical paper. In practice, I think that means that richard's work should say something like: /* * This module written by: Richard Uhler @ Qualcomm * Both Richard Uhler and Qualcomm disclaim all copyrights to this work and * have placed this work in the public domain so that this work may freely be * added, or contributed to the OpenOCD project. * * -- If needed, the below might also be appropriate -- * * This work was based upon, or derived from the files: , , and * Which have the following copyright: * * blah blah blah blah */ And IANAL ... so you might want to have appropriate people review this idea. -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] ULINK driver: firmware license questions
All - I've seen a number of things about using the EzUSB chip, i have some experience/knowledge with this chip, and the EzUSB library that generates the license concern, is very easy to work around. -Duane. If you do this you can re-purpose many other devices into JTAG dongles For example: http://www.devasys.com/usbi2cio.htm http://www.usbee.com/sx.html http://www.usbee.com/usbeeex2.html http://www.cutedigi.com/product_info.php?products_id=4515 http://www.minford.ca/html/mf3001.html http://www.knjn.com/shop.html?pg=imgsrc=5131 http://www.knjn.com/FPGA-FX2.html Some of these have an ARM + FPGA + EzUSB chip The EzUSB magic works like this: 1)At POWER ON RESET, the EzUSB chip reads the first 8 bytes of the on board I2C chip. IF I2C chip is not present (or data is corrupt) THEN use ANCHOR (now cypress) Vendor ID, and ANCHOR assigned Product ID. Attach via USB. IF I2C is present, and 8 byte data header is valid, header may be in two forms. CASE 1: Firmware is present - chip loads the firmware from I2C and runs your code. Your code decides when and how to attach. CASE 2: the BOOT HEADER is present only. The boot header has YOUR vendor ID, and YOUR product ID. The boot header has no usb strings, no nothing, ie; 'minimal stuff' But - it has enough to attach via USB.. 2) The magic download trick is this: one USB vendor command. Specifically: the value is '0xA0' (the A is probably for Anchor) Problem: No windows native stuff lets you send VENDOR commands. Example: WinUSB driver library cannot do this, The Cypress EzUSB library + EzUSB driver can ... In contrast, LIBUSB - you *can* send vendor commands :-) Hence you can write a driver using LIBUSB :-) 3) In the USB vendor setup packet, the important two fields are: (a) wValue = 16 bit address to write data to (b) wLength = the number of bytes to write. In effect, the USB vendor command (0xa0) says: Write (N) bytes to memory address(X). You can access the full 8051 internal address space (64K) NOTE: Even if you have assigned your own VID/PID the hardware intercepts the vendor command 0xa0 - and allows any PC application to take control. This is a good thing, especially when you have bugs in your 8051 code. 4) Download STEP 1 - send a vendor command to write 1 byte to the SFR 'reset register' The value 0x01 - puts the CPU in reset, the value 0x00 lets the CPU run. At this step, the CPU is held in reset. 5) Download STEP 2 - repeat vendor commands to download app to internal RAM. You can only write via the 0xa0 command,you cannot read. 6) Download STEP 3 - Write to that same SFR register, and release CPU RESET. your EzUSB chip begins execution at the reset vector. NOTE: When it does this, the USB device is not reset' but remains attached. Your downloaded code - can if needed disconnect and reconnect. The above is generally what the linux tool: fxload does. http://linux.die.net/man/8/fxload = To PROGRAM the on board I2C chip, do the following: Start: Your I2C chip is blank or corrupt. Connect via USB - send the vendor command 0xa0, put cpu in reset. Download new code, remove reset. Your downloaded code re-writes the I2C chip. OR - Above - download prebuilt cypress HEX file That HEX file supports various vendor commands to rd/wr the I2C chip. *END* ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Proposition of new target cfg files scheme
Main con: - a lot of files (there are 80 stm32f's, and so on) ? Since there are 80 some odd versions - could a number of these items be determined directly from the part number? Look at the ordering information from this STM32 PDF http://www.st.com/stonline/products/literature/ds/15057/stm32f102c4.pdf The 11th symbol is the FLASH size, 4=16K, 6=32K, could be generalize like this if not defined( $STMCHIPNUMBER ) then FAIL WITH ERROR endif if STMCHIPNUMBER == STM32F103C6 STM32FLASHSIZE = 32 STM32RAMSIZE=10 endif ... then later do this if not defined( $STM32FLASHSIZE) ) then FAIL with unknown STM32 chip type endif === OR this could be put into a simple table of some type. Indexed by MODEL NUMBER === -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Linux application debugging(run mode) using DCC driver
On 10/6/2010 4:23 PM, Øyvind Harboe wrote: Any thoughts on how the user would upload applications to the Linux target before starting gdbserver? SLIP or PPP over DCC :-) -duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] current windows gdb gui options
duane Q: What are the openocd + gdb + windows users using as their GUI front end?Phil Fong wrote: Various Eclipse, Code Blocks, BTW - I agree with Oyvind - it sort of is painful that Eclipse *requires* you to have a project file to use the debugger. Actually - I played a little bit -I have CygwinX already on my machine (talking to my Linux box) And - DDD is already a Cygwin package.. So I'm going to check that out and see how it goes. It should be quite simple to create a simple batch file that wraps around starting an X server, and starting DDD. I'll update the list when I have a good shellscript/batchfile. I'm sure others have, or will have the same issues, and I know something about setting this up. -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] current windows gdb gui options
For years, I have used gdb-insight - (the Tcl/Tk version of GDB) http://sourceware.org/insight/ However, it has grown long in the tooth, and cygwin has moved on. At this point, the changes in Cygwin have broken the private copy of Tcl/Tk (from 2004), Some notes: Insight has always had a private copy of Tcl/Tk Tcl/Tk dropped cygwin support years ago GDB/Insight no longer builds, and looks painful to fix. Q: What are the openocd + gdb + windows users using as their GUI front end? -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Proposed change for STM32 Flash burner: at 0 as well as 0x8000000
John [st32 flash can be at 0x0 or 0x800, I want to link my code at 0x0...] Is there a specific technical advantage you are gaining? I can't think of any. If there is - please explain. Have you tried the load address in the linker? Hence, the code loads at address(fixed location of flash) and runs at (aliased location) Here's an example of the load address technique. http://lostarm.svn.sourceforge.net/viewvc/lostarm/trunk/chips/at91sam7x256/source/at91sam7x256_ld?revision=28view=markup Examples are on line 68, 79, 196, etc. [ A note of magic, on the linker command line, the variable: __layout_flash is set to 0 or 1] -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] tcl echo and puts question
Spencer Oliver wrote: {about puts)
For puts the model is this:
http://www.tcl.tk/man/tcl8.0/TclCmd/puts.htm
For ECHO... I know nothing..
Øyvind is probably the tcl man to answer this question :)
And I saw he's out for the week.
-Duane.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] freescale mv13224v - flash support
Been away for a while - able to spend some time again. It's not listed in the current docs. any body do flash support for this yet? Or anybody working on it? I have one of these: http://redwirellc.com/store/index.php?route=product/productproduct_id=56 -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Radically improving out of the boxperformance for armX
Øyvind How about enabling fast/DCC memory transfers by default? Yes, why not - now that we have (a) good TAP identification place. (b) good number of board configurations (c) Many things have a workbuffer in the cfg file.. Then, it is a no-brainer to enable that feature by default. -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Openocd vrs Commercial jtag dongles
Recently, I've been using quite a few commercial jtag tools from chip vendors. One thing I've noticed is that they all have implement the design with an small usb-controller + FPGA of some type (typically a xilinx spartan). I can see the real benefit, they download and flash the target at an unbelievable speed, ie: couple seconds for 256K of data. In contrast, non-fpga solutions, (bitbang ftdi, etc) are much slower overall. My guess is they are creating a hugely fast chip specific download engine they just feed data bytes to - and it operates at some hugely fast speed (that probably helps) In theory, the dongle has 2 modes, simple slow bitbang - once the target is determined, download an acceleration engine the fpga. The debugger step-in/over/line/etc rate with these tools is so fast... perhaps they have have implemented some common tasks like step and register dump type sequences in the dongle's fpga. Watch windows are for example very snappy. Sadly, that also requires a lot of engineering expertise to write that fpga code. in the cases I've seen [ie: vendor supplied tools] the chip companies also have a large pool of people who know or understand verilog/vhdl and can write such fpga code. It is just blindingly fast... -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Cross compiler for ARM7 bare metal
Jon Smirl wrote: Can someone help me out and point me to a working cross toolchain for arm7tdmi with uclibc or equivalent on Linux? I've got a working glib setup but it keeps linking in 900KB of run-time code. I've spent all day searching and playing with buildroot and I can't achieve a working environment. Take a look at http://lostarm.sf.net It builds a *COMPLETE* gnu gcc tool chain for ARM7TDMI - bare metal, it uses NEWLIB for the C-Library It uses an older version of GCC, to be honest with you, there are *little* if any benefit you will get if you _really_ want a new version. The example target is an ATMEL at91sam7x256 - but it is very generic. -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] About AGDI interface of RealView MDK and SWJ support
simon qian wrote: Does is possible to get protocol of AGDI interface of RealView MDK? Then OpenOCD will be supported by it. As for AGDI - I have little interest in supporting Keil uVision - the closed IDE from Keil. http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka11379.html I believe others share my view I don't know about the SWJ status. -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] new lpc2xxx cfg files layout
Freddie Chopin wrote:
Here is the patch that adds the lpc2xxx_internals.tcl file and
modifies all lpc2xxx (ARM7) files to use that.
1) Looks good, I agree the reset issue can be resolved later.
2) Only thing I can think of is this.. type of a change
But that is a minor thing, I hate hidden default values.
They are MAGIC - that always mess me up, been burned one too many
many times.
+# check for RESET_CONFIG - if not defined set the default: trst_and_srst
+if { [info exists RESET_CONFIG ] } {
+ set _RESET_CONFIG $RESET_CONFIG
+} else {
+ set _RESET_CONFIG trst_and_srst
+ puts WARNING: RESET_CONFIG not set, assuming: $_RESET_CONFIG
+}
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] two questions
Øyvind Harboe wrote:
I'm hoping Duane will step in here and help out :-)
Item 1:
It sounds like you want options from from the dos/unix command line in
a batch file format. Why don't you _dynamically_ create the
configuration file:openocd.cfg - with your command line parameters
inside it. You could for example - create a perl script - that (a)
parses your command line options, (b) creates an openocd.cfg file then
(c) executes openocd with the -f CONFIGFILENAME option pointing at
your temporary 'openocd.cfg' file.
At this point, you have openocd commands - and 'getopt' is out of the
questions.
Item 2: -
If you want to use JIM based commands ... {and I don't think it is what
you want}
{Historical note: When OpenOCD was written 'JIM-TCL' did not exist, some
commands are JIM commands, some commands are old-school}
This item talks about JIM commands.
For examples of how to do JIM options commands, take a look at the
file: target.c - look for the function that impliments the target
command. Also - search around the code for a common (local) variable
name goi - stands for Get Option Info - it is a bit ugly (I wrote
it) i was trying to make it easier to create common option handling
sequences in some common way. [Jim.c - by default - does everything
'in-line' ]
There are options/methods to handle Enumerations - Options with
numbers, etc.
Another file too look at would be the jtag.c file - where the taps are
created.
Item 3: - Old School Commands
Best choice, since you are looking at NAND stuff is look at how the
${SRC}/flash/nand.c commands are handled
Also - I believe David has done quite a bit of work with the Nand code.
Or look at the other FOOBAR_nand.c files
=Duane
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] two questions
Alexei Babich wrote: Hi, Duane. It sounds like you want options from from the dos/unix command line in a batch file format. Thank you for your detailed letter. As I understand English is not always good, I'm still going to study the letter carefully :) But now, not to waste time, let me clarify: we are talking about C-code inside the driver imx3 * _nand, which takes a string from the config file: nand probe bla-bla [options]. These options, in the form of char *cmd, char **args, int argc, must be analyzed. Comparing [many] variants with constant templates is ugly. I am looking for a good way, which can be used in C-code. Are we talking about the same? If yes, then say yes, please. Yes. The char *cmd, char **args, int argc - is old-style command. Today there is *NO* getopt style feature inside of OpenOCD source code to help old-style commands. There *is* for (new) JIM-TCL commands, but *NOT* for old-style commands. For old-style commands - what does exist is parse_ulong() - and parse_llong() functions and many other parse functions. Look at the end of command.h -Duane ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] How to handle cross target algorithms
duane When this idea would be bad: Little quick downloads david Depends how little... duane When this idea would be good: BULK transfers, flash programing, etc. [snip] david However, another way of looking at it: you suggest david a limited and standardized kind of debug monitor Sort of, but not exactly - I'm saying a more limited standardized kind of algo for more complex things. - and yes exactly with a *STANDARD* command set. -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] arm1136 scripts
Øyvind Harboe wrote:
Regarding the run_algorithm. This makes me think about
the refactoring I did for the arm simulation code
W.r.t. run_algorithm, I was thinking about how much work
it would be to write a *small* machine code translator
that would translate generic code in to machine specific
code... Sounds impossibly hard, but is it really? I haven't
looked at what's out there.
We also talked a while back about the idea of a standardized download to
the target.
The general idea i was taking about at the time is described below.
-Duane.
A small say 2K, 100% position independent common block of arm code.
perhaps - an armv4 based 32bit code (not thumb)
why? Because that would cover all arm7 and arm9 chips.
Perhaps - another for cortexM3
perhaps - another for armv7 - (cortexA8)
Maybe other chips are fixed address - but generally ARM code can be made
to be PIC in a very simple way.
When this idea would be bad: Little quick downloads
When this idea would be good: BULK transfers, flash programing, etc.
The idea is this:
Let us assume there is a 4K block (working space) of ram some where.
The code could be 2K, set aside 1K for stack (yes 1K)
And 1K for a download buffer - could be bigger..
Maybe we work with 4K and 4K...
The entry point would be fixed - always at Buffer+0
Set the program counter there, nothing else needs set.
Then, set a SW breakpoint at - a fixed location.
Example: Buffer + 0x10
This would leave a few bytes @ the start for startup code
And might be easier for different chips (ie: non-arm chips).
The target code *RUNS*, sets up the stack and then enters
some type of for-ever loop, that looks like this:
*AND* is 100% written in *C* code - not assembler.
some_c_function( void )
{
uint32_t buffer[16];
// this example puts the 4K transfer buffer on the stack
uint32_t download_buffer[ 1024 ];
int result;
// assume result=success
result = 0;
for( ;; ){
// buffer[0] = holds result
buffer[0] = result;
// tell app where transfer buffer is located.
buffer[1] = download_buffer[0];
buffer[2] = sizeof(download_buffer);
// this hits openocd breakpoint
openocd_syscall( buffer[0] );
// openocd stuffs parameters in the buffer.
// parameter 0 - is the command.
// parameter 1/2/3 ... /15 are command specific
switch( buffer[0] ){
case CFI_FLASH_ERASE:
// params 1,2,3 are address and length
result= perform_cfi_erase( buffer[0] );
case HIGH_SPEED_DOWNLOAD:
// on ARM this might use CP15 DCC
result =perform_high_speed_download(
buffer[0] );
case .. other commands
// break
} // switch
} // forever()
}
==
Why do I suggest C? And the above method...
Because it would work on *ALL* targets!
One only needs to *compile* a small C program.
And little helpers would be very fast.
-Duane.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] new lpc2xxx cfg files layout
Freddie Chopin wrote: freddie I still cannot agree on that. Which version is better: freddie Your: duane global CHIPNAME duane set CHIPNAME lpc2103 duane global FLASH_SIZE duane set FLASH_SIZE ... duane ... [snip] ... duane source [find target/lpc2xxx_internals.tcl] freddie or mine freddie set CHIPNAME lpc2103 freddie set CRYSTAL_FREQ 1200 freddie set JTAG_FREQ 100 freddie source [find target/lpc2xxx_internals.tcl] The *problem* use case is as follows: I have a chip that does not have a cfg file that i recognize. There is a CFG file for a chip _just_like_my_chip_ How and where do I find the information required to make it work? Assumptions: 1) I do not know or understand TCL - example: if statements look sort of weird. I reasonably understand rather basic script like languages 2) I have a data sheet for part X - and the matching X.cfg file It is basically identical to my chip - the size of the flash different. And there are a few more/less peripherals on chip. 3) I have a data sheet for the NEW part and need to create a .CFG file. I can understand a data sheet - that's what I do for work. I am a reasonably competent HW/SW embedded firmware engineer. Question: Using Method (A) or method (B) What single file or multiple files(plural) do I modify or create? If modifying - what parts of that file do I modify? If not modifying - what do I read to understand? Is it simple and clear? Are there any special rules I must follow? how would I discover it is set FLASH_SIZE? There is no mention of this in the CHIP configuration file. To answer your example issue questions... With your version the first thing the end user would notice is what the hell is the variant? I would expect some reasonable #comment in the configuration file. The same goes for RAM, user would enter 40kB for lpc2148, and that would not be right, as only 32k of those are on the local bus, the rest is for USB DMA. I would expect to find a reasonable comment in the CFG file that describes this scenario, for example: # ram size is 32K # extra 8K is for usb, not usable by OpenoCD set RAM_SIZE 0x8000 a reasonably competent engineer with a data sheet should understand that comment. -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] new lpc2xxx cfg files layout
Freddie Chopin wrote:
I got the second version - it implements ideas from Duane and David.
comments...
-Duane.
===
1) Seems to be missing proc _SET_DEFAULT..
2) There are numerous syntax errors ... example:
# check for VARIANT - it has to be defined
if { [info exists VARIANT ] } {
set _VARIANT $VARIANT
} else {
if { ! [info exists _VARIANT ] } {
Variable: VARIANT is not set, cannot continue
}
}
Is missing the command error
3) You have all the sets in the internal files.
Example:
# LPC2101 - 8kB Flash and 2kB SRAM (CPUTAPID unknown yet, use typical value)
if { $_CHIPNAME == lpc2101 || $_CHIPNAME == LPC2101 } {
_SET_DEFAULT _FLASH_SIZE 0x2000
_SET_DEFAULT _RAM_SIZE 0x800
_SET_DEFAULT _VARIANT lpc2000_v2
}
I would have put *ALL* sets in the CHIP_SPECIFIC file
And some type of validation in the CHIP_INTERNALS file.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] jtag_khz support for parport interfaces
Jonas Horberg wrote: Note that configuration files with jtag_khz or jtag_rclk can not be used with the parport interfaces until a fix is created. Huh? Sorry I'm late to this thread but I have a question. The idea here is: jtag_khz 1000 - should mean no faster then 1mhz There is no min-freq requirement, and to do so would be wrong. Or am I missing something, ie: we *MUST* have a minimum frequency. -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] new lpc2xxx cfg files layout
david Having a hundred or so chip-specific config files is david a messy concept... Yes, but that is exactly what is needed. If there are 100 chips - you need 100 files, with 100 names. Take the openocd-developer-hat off for a little bit and think about this. Configure files are something *END*USERS* mess with. Yes, from our end (the developer end) 100 files is a P.I.T.A, but it is exactly what the *end*user* needs, or they at least need the *SIMPLE* means to add the +1 more file they need. As an *end*user* if I saw a sequence of filenames that I recognized I could examine a few of them - see the simple pattern and settings and could probably follow that simple pattern successfully. By simple I mean: perform lots of set VARNAME VALUE - then include/source a common file. Most developers would understand and modify a simple TCL statement like this with great success: # This chip has 16K flash.. set FLASH_SIZE 0x4000 But instead, using Freddies' approach - one has to (or is lead to believe they must) read through the complicated internals file which is where lots of magic is happening - magic that is to the benefit of the maintainer who understands the complexities of the chip family, and the scripts, and perhaps knows a little bit of TCL. Wearing a naive new users hat - I would see the big internal file Freddie has and assume that I should weave my new chip into that file, and become very confused. That is *NOT* something I think we want users to do. Bottom line: 1) Freddies 'internal' file does too much, and does too much magic about figuring things out. It is ok for the 3 of us to understand... Remember: Our goal is the *end*user* 2) We don't need to create 100 files for 100 chips.. instead we need to create a few of them - such that is very *CLEAR* to a new user how to add 1 more. That's why we converted the configuration files into 3 source statements (1) the interface (2) the board (3) which includes a chip... In the past, there was just one configuration file users where weaving their changes into other files. By splitting them up - it made it easier to understand. SUGGESTION Freddie could create a simple textfile/database and generate 100 chip files from a quasi-table of some sort... that only runs in maintainer mode. BETTER SOLUTION: In contrast, if the *SCRIPT* would examine the chip some how - and read registers and/or other things it *could* configure it self auto magically. For example ATMEL at91 series parts have some registers in the DEBUG UART at a fixed address... I just don't think this better solution is that easy to implement. -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Need help: nothing works... more
Alain Mouette wrote:
I guess that *I will need to debug this mself*, but please, I need
help with basic information: where is the flash writing program, how
does it interface with OpenOCD, ets...
See: ${openocd}/src/flash/stellaris.c
It interfaces via this structure with lots of function pointers.
Line: 55 - flash_driver_t stellaris_flash = { }
STRONG suggestion... turn on debug_level 3 in your openocd.cfg file
and trace your debug messages.
-Duane.
___
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
Re: [Openocd-development] [Fwd: tcl questions.]
michal smulski wrote:
I have a couple questions about tcl:
1. How do you make variables defined as global (see c100regs.tcl
c100helper.tcl) visible in procedures? I would like to reuse defines in
c100regs.tcl. Otherwise, I need to define them every time I want to use
them. I tried 'global' but it does not work.
Take a look at: ${openocd}/tcl/chip/atmel/at91/aic.tcl - there are
numerous examples.
You basically need to say GLOBAL everywhere... even at the level0
(global) scope area.
2. How to I transfer register (say cpsr or r0) to a tcl variable
(similar to memory - tcl in mmw())?
Not done yet :-( - that needs to be added to OpenOCD's version of TCL.
If you are interested in doing this work, I can help point to the path
through the code.
3. I can't add comments wth # at the same line as the tcl command. This
is not a big deal but it would be nice to have.
This is a parsing problem with the way this version of Tcl works.
Understand that JimTCL is a very stripped down and self contained Tcl
implementation.
Thanks,
Michal
___
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
[Openocd-development] [PATCH] - already applied, GCC warning fixes
Committed this simple warning fix.
==
du...@desk ~/test/openocd/src/target
$ svn diff
Index: arm_disassembler.c
===
--- arm_disassembler.c (revision 2657)
+++ arm_disassembler.c (working copy)
@@ -445,6 +445,9 @@
unsigned rn = (opcode 16) 0xf;
char *type, *rot;
+ /* GCC 'uninitialized warning removal' */
+ type = rot = NULL;
+
switch ((opcode 24) 0x3) {
case 0:
type = B16;
du...@desk ~/test/openocd/src/target
$ svn commit -m'Warning fix'
Sendingtarget/arm_disassembler.c
Transmitting file data .
Committed revision 2658.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Who is using a teletype terminal for code development ?
David Brownell wrote: On Friday 28 August 2009, Magnus Lundin wrote: So why this totally idiotic requirement on 72-80 columns Far from idiotic... I second this. The Linux Kernel coding standards also has a few very good rules about indentation width. (a) Tabs are 8 - not 4. (b) Keep lines less then 80. (c) one function one screen (ie: 80x24) Those three things have a dramatic effect on understanding and readability. Tabs Width = mean you do not suffer indentation sickness. The Nlines - limit make it so you can read everything on one screen. Or as David points out, you can fit it inside one IDE tiled window. Some screens are nice and wide, tiny fonts, mine is not - I have to have larger fonts so I can see. -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] warning fix
Simple..
- Duane.
Index: src/target/target.c
===
--- src/target/target.c (revision 2606)
+++ src/target/target.c (working copy)
@@ -1760,7 +1760,7 @@
value = buf_to_str(reg-value,
reg-size, 16);
command_print(cmd_ctx,
- (%i) %s (/%u): 0x%s%s,
+ (%i) %s (/% PRIu32
): 0x%s%s,
count, reg-name,
reg-size, value,
reg-dirty
@@ -1768,7 +1768,7 @@
: );
free(value);
} else {
- command_print(cmd_ctx, (%i) %s (/%u),
+ command_print(cmd_ctx, (%i) %s (/%
PRIu32 ),
count, reg-name,
reg-size) ;
}
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] amtjtagaccel reports incorrect chip ID's
Ferdinand Postema wrote: After checking the whole table, I found two other transitions that were correct, but could be optimized (5 bits in stead of 10 bits). (Forgive me, I have not followed your list of changes and so forth and I am entering the conversation late). One thing we *DO*NOT* want - is one dongle - (amt-jtagaccel) to act differently then some other tap because dongle (A) uses sequence (A), and another dongle (B) uses sequence (B) for the *exact*same*thing*. Please don't mis-understand 'fixing a bug is a correct and good thing' however optimizing things can introduce bugs. Hence my question. -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Universal ft2232 .inf file for windows/libusb-win32
David Brownell wrote: I think this universal inf file I would have thought it should be one with a LOT more IDs... That one omits the Olimex dongles, Sheevaplug, Signalyzer, Flyswatter, the Luminary stuff ... and about a dozen more. That is *exactly* why I suggested that if some could create a *TEMPLATE* *INF* file - any of us 'script-guys' can easily create a script that can easily generate, and easily update the 'universal inf file' -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [Openocd-svn] r2438 - trunk/src/flash
zwe...@mail.berlios.de wrote: Author: zwelch Date: 2009-07-01 00:25:09 +0200 (Wed, 01 Jul 2009) New Revision: 2438 Modified: trunk/src/flash/flash.c Log: Remove at91sam3.h from flash.c; use extern like other drivers. If you are doing this then you should remove the file at91sam3.h also - all it contains is the 'extern' nothing else. The *only* public symbol is - by design - the structure. -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [Openocd-svn] r2438 - trunk/src/flash
Zach However, I would rather see you move some of the things in the C file Zach into the H file (all of the #defines and struct declarations, to start). Zach Basically, use it as the driver's private header file. duane None of those defines are *PUBLIC*. duane None of those structures are *PUBLIC*. zach Read what I said again: private header file. Just because something is zach in a header file does not mean it is a public contract. However, zach putting this into your terms: moving those definitions to H file helps zach define the contract for the C file. I disagree 100% percent. You seem to suggest that major systems such as GCC, GDB, the Linux Kernel, to name but a few - are wrong in this widely used approach. A header file is something any one can #include, and thus defines a public interface, there is no means to enforce the 'this-is-private-do-not-touch' rule. How does this help define the contract for the C file? -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Advanced Reset Process
Øyvind Harboe wrote: On pondering the configure FPGA vs. reset script problem. How about if the target added new commands, such as configure FPGA. This would then be distinct from resetting the CPU, but it could still be placed into the .gdbinit sequence. Why is this not pay svf file? -duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Advanced Reset Process
So - if we are to turn reset inside-out - what commands do we need? 1) ablity to control SRST TRST externally. jtag interface assert SIGNALNAME jtag interface deassert SIGNALNAME 2) Ablity to know SRST TRST configuration. set foo [jtag interface cget -trst-srst-config ] What is that list? Should this have some numeric (bit wise) value? 3) Do we want a macro player at that point - ie: something we can do as a macro like thing? Do we really want to code 'reset halt' for an ARM7 in tcl? Or do we just want to say perform complex operation X, on tap Y *now*. What are those complex operations? By target That list is a non-trivial list of things. -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] clearing all breakpoints watch points
The cortexM3 - and perhaps other targets - have a problem. When GDB exits/disconnects/reconnects - these two functions get called: /* we must remove all breakpoints registered to the target as a previous * GDB session could leave dangling breakpoints if e.g. communication * timed out. */ breakpoint_clear_target(gdb_service-target); watchpoint_clear_target(gdb_service-target); REFERENCE: gdb_server.c - line 760 (or so) However, if the target is not HALTED.. The breakpoints are *NOT* removed. Example: @ arm7_9_unset_watchpoint() @ cortex_m3_remove_breakpoint() @ mips_m4k_remove_breakpoint() Perhaps - things went bad and you had to *reset* the target, or something - but did not *exit* openocd and *resetart* openocd - or other reasons. Slowly target resources are consumed/leaked - specifically hardware compare registers. Suggestions? At some point, the only solution is to bounce/reset/restart openocd. -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] clearing all breakpoints watch points
duane Slowly target resources are consumed/leaked - specifically hardware duane compare registers. duane Suggestions? BTW - this can also be caused by GDB croaking.. while leaving the target running. Examples - SVN 2408 - adds some useful debug information to help see this problem The general idea is a unique id for each breakpoint/watchpoint - ie: BPID.. below. Here, a breakpoint was added, the target went off a clif - and now GDB cannot *remove* the breakpoint because the target is in a bad state. Leak example. Debug: 1164 124671 gdb_server.c:2050 gdb_input_inner(): received packet: 'Z1,800c0,2' Debug: 1165 124671 gdb_server.c:1385 gdb_breakpoint_watchpoint_packet(): - Debug: 1166 124671 target.c:1408 target_write_u32(): address: 0xe000201c, value: 0x400800c1 Debug: 1167 124671 cortex_m3.c:926 cortex_m3_set_breakpoint(): fpc_num 5 fpcr_value 0x400800c1 Debug: 1168 124671 cortex_m3.c:953 cortex_m3_set_breakpoint(): BPID: 6, Type: 0, Address: 0x000800c0 Length: 2 (set=6) Debug: 1169 124671 breakpoints.c:104 breakpoint_add(): added hardware breakpoint at 0x000800c0 of length 0x0002, (BPID: 6) Debug: 1170 124671 gdb_server.c:2050 gdb_input_inner(): received packet: 's' Debug: 1171 124671 gdb_server.c:2050 gdb_input_inner(): received packet: 'g' Debug: 1172 124671 gdb_server.c:2050 gdb_input_inner(): received packet: 'z1,800c0,2' Debug: 1173 124671 gdb_server.c:1385 gdb_breakpoint_watchpoint_packet(): - Warn : 1174 124671 cortex_m3.c:1072 cortex_m3_remove_breakpoint(): target not halted Debug: 1175 124671 breakpoints.c:128 breakpoint_free(): BPID: 6 Example of final failure: Debug: 1911 139921 gdb_server.c:2050 gdb_input_inner(): received packet: 'Z1,800c0,2' Debug: 1912 139921 gdb_server.c:1385 gdb_breakpoint_watchpoint_packet(): - Info : 1913 139937 cortex_m3.c:1047 cortex_m3_add_breakpoint(): no flash patch comparator unit available for hardware breakpoint Info : 1914 139937 breakpoints.c:81 breakpoint_add(): can't add hardware breakpoint, resource not available (BPID=7) -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Breakpoints do not work for LM3S6918 / Eclipse
I still am stuck and no breaky points ! Really? I'm confused. I'm seeing other problems - that are some what related - but I'm not sure (see earlier email subject: Clearing all breakpoints watch points) I see you only setting one breakpoint. I see the breakpoint working. If I look at the log - vrs - the source code - I see the following: Debug: 454 1297182 gdb_server.c:2050 gdb_input_inner(): received packet: 'Z1,196,2' Debug: 509 1352651 gdb_server.c:2050 gdb_input_inner(): received packet: 'z1,196,2' Debug: 515 1627149 gdb_server.c:2050 gdb_input_inner(): received packet: 'Z1,196,2' Debug: 570 1867380 gdb_server.c:2050 gdb_input_inner(): received packet: 'z1,196,2' Debug: 629 5711327 gdb_server.c:2050 gdb_input_inner(): received packet: 'Z1,196,2' Debug: 684 5723749 gdb_server.c:2050 gdb_input_inner(): received packet: 'z1,196,2' 1) All received packets are always printed during debug logs. see: gdb_server.c - line 2050 - 2) All Z (upper case) packets *set* breakpoints 3) All z (lower case) packets *clear* breakpoints The fields are: Z type COMMA address COMMA size See: gdb_breakpoint_watchpoint_add() - line 1375 of gdb_server.c GDB is always using the hardware breakpoint, type 1. Why? Because GDB knows the breakpoint location is in *FLASH* GDB knows this because of the memory map that was sent. ie: gdb_memory_map enable It is always setting/clearing the break point at address 0x196, always a thumb break point (length is 2) I don't see errors in your log - I see them in my log... -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Advanced Reset Process
This avoids switching
programming paradigm from procedural to
event based, i.e. we could add events until
the cows go home and still miss that crucial
event for the next target.
I'd call the current reset events procedural
hooks, myself. Heck, they don't even accept
any parameters ... :)
The original idea/concept for the events was Tck/Tk bind - what i
wanted to do was add support for %T for target, and a host of other
things - much like Tk has %w for window name, and %x and %y for event
location - stuff like that. But never got around to it. Mostly because I
wanted the event stuff to 'gel' a little.
I don't believe that it is possible to *ever*
add a reset event that is flexible enough for
all future targets. I'm in favour of adapting OpenOCD
as we go along rather than create a hugely complicated
monster reset scheme that still won't catch the next
jtag router from hell problems.
Routers weren't the only, or even the main, set
of motivating examples...
But you seem to agree that the reset process
still has holes that need fixing (adapting);
so that question is answered.
Why don't we re-describe the reset process completely.
ie:We define a few models - ie: (A), and (B) - and call those complete.
(That would handle probably 90% of the simple situations).
Then - allow the reset command to be 100% re-written, perhaps what we
need is:
proc reset { } {
jtag assert TRST SRST
jtag sleep-msecs 250
jtag de-assert TRST
jtag ... scan command
jtag .. scan command
jtag .. scan command
jtag de-assert SRST
}
This would *DE*COUPLE* the entire process.
We could then - add a few *TARGET* specific commands, ie:
$TARGET reset-action NAME ... parameters
For example - ARM7/9 - support to do reset-halt, where you stop the
CPU @ the reset vector.
--
Today - the C code *controls* and *drives* the reset sequence.
I'm suggesting we turn that inside out - and make the TCL code - drive
the reset sequence - via commands above.
There would be a few *default* reset sequences - in tcl... that one
could point proc reset at.
-Duane.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] simple refactor - target_state_name()
Replace common function call with simple refactorization. For example: OLD: LOG_DEBUG(target-state: %s, Jim_Nvp_value2name_simple(nvp_target_state, target-state)-name); NEW: LOG_DEBUG(target-state: %s, target_state_name(target)); -Duane. SVN Details === Author: duane Date: 2009-06-28 04:40:08 +0200 (Sun, 28 Jun 2009) New Revision: 2409 Modified: trunk/src/target/arm11.c trunk/src/target/arm7_9_common.c trunk/src/target/cortex_m3.c trunk/src/target/mips_m4k.c trunk/src/target/target.c trunk/src/target/target.h trunk/src/target/xscale.c Log: Refactor code, create target_state_name() ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] svn commit - - More details on GDB connect disconnect
== Author: duane Date: 2009-06-28 04:54:19 +0200 (Sun, 28 Jun 2009) New Revision: 2410 Example: Debug: 812 68734 gdb_server.c:823 gdb_connection_closed(): GDB Close, Target: sam3.cpu, state: halted, gdb_actual_connections=0 == Author: duane Date: 2009-06-28 05:09:15 +0200 (Sun, 28 Jun 2009) New Revision: 2411 Modified: trunk/src/target/target.c Log: Remove extra newline from debug log message (line 3400 - target.c) == -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] ftd2xx - libftdi
Zach Welch wrote: Only libusb+libftdi serves our long-term interests. Wrong. libusb is a *blocking* issue that we cannot control, fix, nor whatever. LIBUSB is not supported by *newer* windows platforms. Unless and until it is supported it becomes a dead end solution, period, end of story. I believe the WinUSB solution is a solution, that for some reason keeps being left off your list. http://msdn.microsoft.com/en-us/library/aa476426.aspx -duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Breakpoints do not work for LM3S6918 / Eclipse
Joe, Try adding this to your configuration file # gdb_memory_map enable # This tells openocd to inform GDB where 'flash lives' - thus GDB will attempt to use hardware breakpoints. You are also not paying attention to what GDB is telling you - when it cannot find the bounds of the current function - not much is going to work.. This is very true of the command step - which - is a *source*level* step. Read back through what I told you about how GDB steps ... if the current PC is not within the bounds of your code - GDB has no way to figure out how to STEP - it can - however stepi - which is an instruction step, but *you* the human need to type stepi - not step. === I start GDB - without a configuration file, and type various commands - below is a transcript of what I am typing with embedded comments. I am using an atmel at91sam3u4E chip on a SAM3U-EK eval board, I do not have a Luminary Micro - however both are cortex-M3 parts. === [du...@borgcube basic-internalflash-project]$ ../../../install/bin/arm-none-eabi-gdb GNU gdb (GDB) 6.7.50.20080107-cvs Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as --host=i686-pc-linux-gnu --target=arm-none-eabi. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/. === I did not specify a CONFIG file on the command-line and I did not specify an ELF file on the command line. therefore I must type commands and specify the ELF file I want to debug. === = Specify the ELF file... = (gdb) file ./bin/basic-internalflash-project-at91sam3u-ek-at91sam3u4-flash.elf Reading symbols from /home/duane/cortex/b/basic-internalflash-project-at91sam3u-ek/basic-internalflash-project/bin/bas ic-internalflash-project-at91sam3u-ek-at91sam3u4-flash.elf...done. = Specify the target = (gdb) target remote 192.168.0.100: Remote debugging using 192.168.0.100: 0x in ?? () = Tell openocd to HALT the target = (gdb) mon halt = Tell openocd to RESET the target. = (gdb) mon reset JTAG tap: sam3.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4) JTAG Tap/device matched = And i tell it to halt again... = (gdb) mon halt target state: halted target halted due to debug-request, current mode: Handler BusFault xPSR: 0x2105 pc: 0x000817dc = Load my program - this actually programs the flash = (gdb) load Loading section .fixed, size 0x133c lma 0x8 Loading section .relocate, size 0xf4 lma 0x8133c Start address 0x811dc, load size 5168 Transfer rate: 4 KB/sec, 2584 bytes/write. = Set a breakpoint at main() = (gdb) break main Breakpoint 1 at 0x800c0: file main.c, line 168. = Tell GDB to continue - see the NOTE from GDB... = (gdb) cont Continuing. Note: automatically using hardware breakpoints for read-only addresses. = I hit my breakpoint.. = Breakpoint 1, main () at main.c:168 168 TRACE_CONFIGURE(DBGU_STANDARD, 115200, BOARD_MCK); (gdb) = Works for me :-) = -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] New Flash Target: Atmel AT91SAM3 - Cortex M3
Zach Welch wrote: Fixed. There were a few could be used uninitialized warnings too. These seem like they should have been covered by --enable-werror. Duane, are you building with that option before committing changes? I normally build with optimization disabled so that I can *debug* the code - with the optimizer disabled, the uninitialized errors will not occur. -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] New Flash Target: Atmel AT91SAM3 - Cortex M3
David Brownell wrote:
I get all kinds of build errors on Ubuntu 9.04/x86_32 where the
chip details banks get initialized. The errors made no sense to
me, and they went away when I changed the
.bank[0] = { ... },
.bank[1] = { ... },
to be
.bank = {{ ... }, { ... }},
i thought the bank[0] = { } was valid C99 initialization.
I've been using cygwin, by default uses:
/usr/lib/gcc/i686-pc-cygwin/3.4.4/specs
Perhaps something has changed I am unaware of .
-Duane.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [Openocd-svn] r2381 - trunk/src/helper
Spencer Oliver wrote: strok_r is not available on win32 - strok is said to be reentrant on win32. Not near a dev pc at the moment so i thought i would point it out - i can make the change later if you do not have time. Hmm... Perhaps we should add strtok_r() to the replacments.c file. We could take an instance from Newlib - it has a BSD licensed implimentation. What do you think? -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] New Flash Target: Atmel AT91SAM3 - Cortex M3
David Brownell wrote:
I get all kinds of build errors on Ubuntu 9.04/x86_32 where the
[snip]
.bank[0] = { ... },
duane i thought the bank[0] = { } was valid C99 initialization.
zach I just realized that I left out the '.bank = ' bits.
zach Sorry for that minor mess, but it compiled. :)
Huh? What do you mean? Confused.
-Duane.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] License
David Brownell wrote: On Wednesday 24 June 2009, Dominic wrote: Being the one who followed the project from its very beginning I believe I do know some things that others may have missed or never heard about. So maybe you can answer this ... What does the arp_ prefix in various commands represent? Address Resolution Protocol was my first reaction ... but that doesn't seem relevant to JTAG. ;) That name arp_ was coined by my self an Oyvind last year when we where trying to introduce Reset events and all the other Jim type events. The ARP - stood for: Advanced Reset Process - -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] openocd, ftd2xx
Zach Welch wrote: Hi all, Here is the full list of GPL-compliant solutions for libftd2xx GPL compliance, after further review, consideration, and enumeration: 1) Documentation: build it yourself! 2) Build-Kit: automate the build on users' machines 3) XXX: to be revealed, if legal 4) libftdi-ftd2xx: ABI compatible with libftdi, wraps ftd2xx 5) sockets: separate ftd2xx into their own process space 6) libusb+libftdi: The Right Thing To Do ;) You are missing (7) - WinUSB - the windows platform type solution that is simular to libusb. Sadly, it does not go back to Win2K - but - most (popular) others are solved. -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch] Unbreak build for Mac OS X
Oleksandr Tymoshenko wrote: Attached patch unbreaks build on MacOS X (I guess on *BSD too): - stdlib.h should be included instead of malloc.h for better portability - Eliminate r could be used uninitialized gcc warning COMMITED - Thanks. -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Possibility of USB Virtual COM port along with JTAG using libusb-win32
Channel A is configured as 245 FIFO mode for Jtag. Channel B is configured as RS232 UART for the serial port. Therefore we should only use libusb-win32 for Channel A and use the FTDI driver for Channel B. Hm interesting... Because OpenOCD is *NOT* talking to this channel - and not using it... then Yes, I think this is a good work around. Earlier I suggested a single inf file that contained everything. Perhaps that is a bad idea. Reason: I have an Olimex Jtag Tiny - (ft2232 based) - it only does JTAG, it does not have the serial port available. I am sure there are other dongles just like that. Maybe - that 4 column text file could be expanded - to include what should channel A do and what should channel B do. -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] New Flash Target: Atmel AT91SAM3 - Cortex M3
SVN Commit -
Author: duane
Date: 2009-06-24 04:01:14 +0200 (Wed, 24 Jun 2009)
New Revision: 2383
OpenOCD now supports the AT91SAM3 - new CortexM3 product from Atmel.
Adds support for the FLASH component, includes DOCs for the new target
in the OpenOCD.texi file.
The openocd.cfg file I used is/was:
#debug_level 3
source [find interface/olimex-jtag-tiny.cfg]
jtag_speed 6
telnet_port
gdb_port
source [find board/atmel_sam3u_ek.cfg]
$_TARGETNAME configure -event gdb-flash-erase-start {
halt
}
init
halt
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] FT2232 Windows - summary of options
All - I believe - I am not sure - that the primary benefit of libft2xxx is as follows: (a) It is measurably faster. That just requires work to make it faster. (b) It works on more platforms, ie: Win7, WinVista, because drivers exist for those platforms. This is tough/hard, nobody on this list is a windows driver developer. Grrr. Such is life. (c) Nobody was offering a universal libusb - type INF files for windows. Looks like Freddie Chopin is working on that :-) Perhaps - we could have a contrib folder with a *binary* libusb0.sys file and associated INF files that references *ALL* ftdi based dongles - (The VID/PID list is in the source file...) That *INF* file and matching SYS file should be deliverable with OpenOCD. (d) There is another choice - WinUSB http://msdn.microsoft.com/en-us/library/aa476426.aspx As I understand, it is a a multi-(windoze)-platform solution that exposes the USB device, functionally in the same manor and style as libusb does, ie: the ablity (1) to rd/wr endpoints, (2) send control commands. I believe there is the only open question that needs to be asked and answered. The MS-WinUSB driver - did not *ship* with WinXP, but is available as a co-install for WinXP. As I understand (I have not confirmed, and I do not know all the details of it), the driver and associated OS-libraries/headers are *PRESENT* on Vista, and I presume Win7 (with appropriate dev tools installed), therefore it functionally *SHIPS* with the operating system, and as such it sould fall under the standard operating system component exception to the GPL. This solution is - by design - something that can be added to WinXP (the co-install solution). I think of it sort of like this: The old system only supplied a CDROM (read-only) driver - later - new systems come with CD-WRITER (and today, we have CD-RW) - the *new* os does not require an upgrade, the *old* os has an upgrade path to make the CD-WRITER (and now CD-RW) work. I should - as a user of that old system - install the OS update - and be able to make use of that GPL software. All is not rosy and perfect, WinUSB would require an INF file that *points* to the driver - much like the work that Freddy is working towards with a universal libusb inf file Agree? -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Universal ft2232 .inf fileforwindows/libusb-win32
Freddie, I want to understand what you are working on. I believe there are 3 or 4 things needed to make OpenOCD work with a universal inf file for LibUSB really work. I think of it this way: (a) We have a simple text file - with 4 columns. Column 1 - Vendor ID Column 2 - Product ID Column 3 - Product Root Device Type, ie: ft2232 - or - other Column 4 - Human Friendly Name. (b) Perhaps that text file supports # comments. (c) Question: Given the above, how hard would it be to create a *SIMPLE* perl, shell, awk, whatever script to create a generic LibUSB windows inf file - that *LIST* *ALL* items listed in the simple text file. (d) If the above is simple - and I believe it is - then packagers of OpenOCD *could* - then package LibUSB0.sys with the INF file.. and the more general problem would be solved. (d) In effect, a packager *could* only need to copy a pre-built libusb0.sys file into the same directory as the generic openocd-libusb.inf file above. *THEN* - a prebuilt cygwin user (or mingw user) *could* - re-install the usb driver for their dongle - and specify the 'openocd-libusb.inf' file instead of the default one that came with/from the dongle vendor. -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [SERIES 0/4] Whitespace Cleaning
Zach Welch wrote:
There have been no objections to these series of patches, so I intend to
regenerate and apply them soon.
There is one thing I do not like - not exactly what you are talking
about here.. I'd rather my voice be heard...
In general, I think a general white space cleanup is nice... and a
good thing... Janitor work - glad you are doing it...
that said, please - I don't want to see us head down the road where
issues like the ones I out line below come up.
==
The general statement is this:
What I do *NOT* like and I find it terribly hard to read - is
utterly *DENSE* code - that is almost *devoid* of white space in both
the x y dimensions. Often, white space is there for a reason - and
cleanup tools - are a tad bit too helpful.
I've been burned by them before!
==
Examples include
==
(a) multiple 'format specifiers' to a printf() like function - counting
function parameters to find 'argument 12' - is daunting.
A specific example: *this* 258 char long printf() statement.
printed = snprintf(buf, buf_size, protection_fields: %i, prot_reg_addr:
0x%x, factory pre-programmed: %i, user programmable: %i\n,
pri_ext-num_protection_fields, pri_ext-prot_reg_addr, 1
pri_ext-fact_prot_reg_size, 1 pri_ext-user_prot_reg_size);
Imagine that - 258 bytes - and that one does not need the c99 format
specifiers! Wow!
At some point, a *single*column* of parameters, one per line... is much
better!
Might not fit some style guide... but please - line length 150 is sort
of absurd.
What I talk about adds white space all over the function call - but
improves readablity.
Collapsed IF statements
==
(b) - Collapsing if() statements that - just - in the end make the
statement *longer* on the line..
Example (bad, 127 char line of code, example from cfi.c)
if((retval = target_write_memory(target, flash_address(bank, 0,
pri_ext-_unlock2), bank-bus_width, 1, command)) != ERROR_OK)
{
return retval;
}
Example (rewrite-good, use a temp variable, to kill line length)
{ uint32_t adr;
adr = flash_address(bank, 0, pri_ext-_unlock2)
retval = target_write_memory(target, adr, bank-bus_width, 1,
command);
}
if( retval != ERROR_OK)
{
return retval;
}
==
White space removal in initialized data, or function calls.
==
(c) Often, a *LONG* table of data is created, and great pain is taken to
*ALIGN* commas, parens, and other elements of the data such that things
line up in a nice neat tabular format,while the whitespace does not meet
style guide rules it is there for other reasons - improved readability
and comprehension..
yea, truthfully - compliance with this is all over the map... it does
vary quite a bit.
-Duane.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Breakpoints do not work for LM3S6918 / Eclipse
Joseph Kuss wrote: To All, I am using openOCD 0.1.0, GDB 6.8 and Eclipse Ganymede For the Eagle100 board, using LM3S6918: I can download my program into flash ok I can start/continue the program, I just can not get breakpoints to work. Please Help. If I need to send this message in a different format or to a different person or group, please let me know. (a) Try your program in *RAM*, see if breakpoints work there, this rules out RAM vrs FLASH breakpoint problems. (b) Where are the breakpoints being placed? Flash or RAM? (c) GDB often tries to keep track of your earlier breakpoints - how many do you have active? With Insight (GDB-TK) one often must cleanup and delete the cached list of break points when code changes, otherwise they get put in rather strange places. (d) Enable the debug log level 3 - what does the log tell you when you set a break point and run (read the openocd manual about this) (e) Where did you get OpenOCD from? Did you build it, or did you download a pre-built version? -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] FT2232 Windows - summary of options
zach Please DO NOT try to cheat the GPL license. You do not understand how zach far I am willing to take these matters, and I believe any form of binary zach distribution to be a violation: a DLL wrapper, a binary patch, anything! Let me ask this another way. I believe the question is some what moot, and was moot 4 years ago one OpenOCD was originally written. Basic thesis statement, and IANAL... But I can sound like one. If I am the original author of a body of work, I hold the original copyright and can license that body of work as I please, under the GPL with any exception that I please. Those that follow do not have the ability to further restrict, nor change that license. As the original copyright holder, I can choose to explicitly write an exception for a specific use case of the package (or fail to), however - if my personal actions effectively construct and demonstrate that use case - is valid and acceptable - then it is an unwritten exception. You cannot change my original intention, nor can you change that original license and/or any exception that may have been granted before you got involved. Argument. It is well know that Dominic Rath, is the original author of OpenOCD. By reviewing his original releases that I find in the SVN repository, I can't get back to Rev1, Rev 50 fails, Rev 75 works, By Dominic's on hand purposely created OpenOCD to support the ftd2xxx library on windows. As I understand (and Laurent or Dominic can confirm) Domenic worked with Laurent to help develop the ftd2xx driver (and library) based jtag key. Perhaps - I do not now - but I assume. Dominic and other developers of the package at the time actively participated and encouraged the package to be *USED*WITH* and in fact *SOLD*WITH* this 'incompatible library' While not *explicitly* *written* I view this as an original exception that was unwritten, but granted, as demonstrated by the original author, and original copyright holder of the package as an acceptable exception. We as a group, perhaps may not like this fact, but it is what it is. I can not change that original exception, nor can anyone else. It was part of the deal when each of us started to contribute to OpenOCD. For example - see the Amontec Application note - copyright 2000 to 2006 which explicitly references the FT22xx drivers. http://www.amontec.com/pub/amt_ann006.pdf I also point out the history of openocd on the Amontec web site http://www.amontec.com/openocd.shtml (bottom of the page) The person who can clarify any misunderstanding is Domenic, and Dominic alone. **END** -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] FT2232 Windows - summary of options
zach I am afraid that your intent will not matter even one iota, in a court of law. This is not, and was not ever my intent, I am speaking of what I see as the original authors GPL+[undocumented]-exception intention. zach If you want to make exceptions, then they do not apply to the new code. You cannot retroactively change the license; The code was *Domenic's* to license in that way, as he was the original author. I am not changing anything, I am only stating what I see as the history of the project, things that happened +3 years before I was involved. I don't like it, you obviously do not, and I believe others equally do not like it. I would like to see this exception *documented* so that it does not expand, or continue beyond this exact situation. Then we can move on. -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] committed - printf() warning fixes
rick For example, in your case:
duane uint32_t x;
duane void funny_function( uint32_t );
duane
duane for( x = 0 ; x 10 ; x++ ){
duaneprintf( X = %d, Calling funny function\n, (int)(x));
duane funny_function( x ) ;
duane }
rick Casting to int is fine as long as int is 32-bits or greater.
I assert that all OpenOCD hosts are: at least 32bit basic machines,
they may be larger.
=
snip
=
rick If you know that int has an appropriate data range for the
task, then (a) works. But you would need to verify that. You should
also leave a comment stating that such a verification was done (and the
date). If you chose uint32_t just for convenience, then it doesn't
matter much, but you are guaranteed that using the C99 printf macro will
avoid any potential truncation issues.
I assert (a) OpenOCD requires that all host basic integer types are at
least 32bits *AND*
I assert (b) the following example is *self*evident* and does not
require a verification comment with date
uint32_tfoo;
printf( The value we care about here is: %d\n, (int)( foo
0x0ff ) );
True or false?
(One could have used 'unsigned int' and '%u' instead).
duane Here, under OpenOCD we generally:
duane (1) assume that all embedded openocd targets are *32bit* at most...
rick This is a bad assumption since it limits us from supporting
various DSPs.
To fix this, requires that we introduce a CORE_ADDR type - much like
GDB has internally, but in a far more complex way. Remember: OpenOCD is
'target agnostic' - ie: Pic32 - is built in - same as ARM - same as
Future64Bit - thus CORE_ADDR will be a complex dynamic type with
specialized addition and subtraction routines, that are current target
aware for example:
CORE_ADDR target_address;
target_addr += 1; // illegal
CORE_ADDR_add( target_addr, 1 ); // allowed
It becomes more complex when/where the target has a *true* Harvard
architecture, and/or non-linear escoterica memory
(while *ARM* is generally Harvard, the majority of implementations make
that go away)
duane (2) assume all host platforms are at least 32bit host platforms
rick Limits us from using 16-bit processors. Not necessarily a
problem, but a potentially unnecessary limitation.
This line of reasoning is a red-herring.
duane (3) and thus, target addresses are generally equal to - or
smaller then the host unsigned integers
rick This is a really bad assumption. Instead we should define a new
type that is the guaranteed size to hold a target address.
See above, the complex type: CORE_ADDR
===
duane 4) In most, if not all of the u32 cases, the format string
duane specifies %08x or equal.
rick And that is horribly wrong for u32. %x will change size between
32-bit and 64-bit windows versions since int changes size.
I agree it is *WRONG* when the value represents a TARGET_CORE_ADDR
type. But this has *NOTHING* to do with the
But otherwise it does not.
For example: A target 32bit value (perhaps the contents of memory) the
resulting value will never take on any value larger then 32bits on the
host. Thus, any host side calculation must be performed with host type
of least 32bits *UNTIL* the sufficiently interesting component of that
value has been extracted.
At that point, the author of the code may choose to use any other
sufficiently wide enough variable type to hold the interesting component.
I again assert all openocd hosts are at least 32bit (or larger) basic
machines. Thus, I assert that a host side cast to int or unsigned
int is at least a 32bit value and in many cases is sufficient for the
majority of printf() like values, TARGET_CORE_ADDR - the exception.
===
duane LOG_INFO( device id = 0x%08x (manuf 0x%03x dev 0x%02x, ver
0x%03x),
duane device_id, (device_id1)0x7ff, (device_id12)0xff,
duane(device_id20)0xfff );
rick The %08x indicates that you want 0 padding to ensure at least 8
hexits are printed from the int. It says very little else.
Agreed.
A *VALID* alternate to the C99 format specifier is thus. as follows:
LOG_INFO( device id = 0x%08x , (unsigned int)(device_id
0x));
This relies upon the earlier assertion: The basic signed/unsigned host
integer types are at least 32bit.
-Duane.
Reason:
At run time, target (A) might be a 32bit arm, and (B) the dsp64bit -
adding 1 - a target specific test must be performed to *wrap* at 2^(n-1)
We are not there today, and we will not be there for a very long time.
If/when that is don
(2) assume all host platforms are at least 32bit host platforms
Limits us from using 16-bit processors. Not necessarily a problem,
but a potentially unnecessary limitation.
(3) and thus, target addresses are generally equal to - or smaller then
the host unsigned integers
This is a really bad assumption. Instead we should define a new type
that is the guaranteed size to hold a target address.
(4) In most, if not all of
[Openocd-development] SVN comit -
Commits - r2296 - through 2347 - are commits that fix printf() -Werrors so that Cygwin will build. These where done (for the most part) as one file per commit so that if a specific issue arises, it can be reverted. This is a *nasty* bunch of mechanical changes... Agh... FYI - anyone writing anything using c99 - uint32_t - a *VERY* common type use categorically across nearly all of openocd cannot use the naked %x format specifier (and this happens nearly everywhere). Instead, one must must instead use the [%08 PRIx32 ] combination. Ugh. -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] inf file for libusb
I think we should start to collect the inf files too? Agree, it would be nice to have a libusb - INF file for all ftdi based chips that point to libusb :-) ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [Openocd-svn] r2293 - trunk/src/jtag
I think this kind of stuff should be prohibited from source files. This is noise for anyone that does not use one specific editor. I disagree.. - But since you are so proactive ... Please also fix arm-jtag-ew.c - remove the VIM version of the same thing. -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] committed - printf() warning fixes
duane FYI - I committed several cygwin specific printf() warning fixes. duaneSimple cast to fix duane these where causing -Werror failures on cygwin. zach I was just about to post some patches to show how to fix all of these zach correctly, as casts are not the right way to do it. In some cases, I can agree, but in others - I don't agree. A cast is by far the most simplest solution. For instance, look at this: LOG_WARNING(writing %d bytes only - as image section is %d bytes and bank is only %d bytes, \ (int)(c-base + c-size - run_address), (int)(run_size), (int)(c-size)); (a) look at what is being printed (b) the possible ranges of numbers (c) the number of parameters involved in the expressions At some point - having to dig back 20 to 30 -lines- to *random* places - because some variables are: (1) function parameters (2) defined at the top most block (3) defined locally to the local block (4) defined a few lines down from the top most block (5) often simplistic 'i/j/k' type vars that are reused because they are handy. (6) By the time I personally dig through the above, and determine all types involved (7) Then understand the underlying arithmetic integer promotion order... *note* this set of equations are simple... (8) a cast to a basic type is truly a very *simple* solution, (9) a cast to a basic type in this case is the K.I.S.S. solution. Either that - or we *need* a different solution here, the above is absurd. Comments? -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] committed - printf() warning fixes
Zach Welch wrote:
On Fri, 2009-06-19 at 20:31 -0400, Duane Ellis wrote:
duane FYI - I committed several cygwin specific printf() warning fixes.
duaneSimple cast to fix
duane these where causing -Werror failures on cygwin.
zach I was just about to post some patches to show how to fix all of these
zach correctly, as casts are not the right way to do it.
In some cases, I can agree, but in others - I don't agree. A cast is by
far the most simplest solution.
For instance, look at this:
LOG_WARNING(writing %d bytes only - as image section is %d
bytes and bank is only %d bytes, \
(int)(c-base + c-size - run_address),
(int)(run_size), (int)(c-size));
(a) look at what is being printed
(b) the possible ranges of numbers
(c) the number of parameters involved in the expressions
At some point - having to dig back 20 to 30 -lines- to *random* places -
because some variables are:
(1) function parameters
(2) defined at the top most block
(3) defined locally to the local block
(4) defined a few lines down from the top most block
(5) often simplistic 'i/j/k' type vars that are reused because they are
handy.
(6) By the time I personally dig through the above, and determine all
types involved
(7) Then understand the underlying arithmetic integer promotion order...
*note* this set of equations are simple...
(8) a cast to a basic type is truly a very *simple* solution,
(9) a cast to a basic type in this case is the K.I.S.S. solution.
Either that - or we *need* a different solution here, the above is absurd.
Comments?
The simple solution is not the correct one in this case. The problem
is that your assumptions about ranges are not portable; that is the
point in using these macros.
You miss an important point, it is *NOT* the possible range of values
the *TYPE* may take on.
It is the range of values the **ACTUAL*DATA** might take on that is
important here.
Consider:
uint32_t x;
void funny_function( uint32_t );
for( x = 0 ; x 10 ; x++ ){
printf( X = %d, Calling funny function\n, (int)(x));
funny_function( x ) ;
}
In the above, I have several choices, (a) I could have used an int
variable - then *cast* it to a uint32_t at the function call (note here:
I am partial to x as a loop control variable, others like i/j/k) or -
because (b) the value will never be negative, I just choose 'uint32_t'
because it was convient.
Is the printf() statement *WRONG* - or is the printf() statement
*CORRECT* in this senario.
If we had to fix this, what would we do to fix this:
Today - we do not have macros, or types like GDB/GCC/GAS.
GDB for instance uses CORE_ADDR - and has infrastructure behind it.
Here, under OpenOCD we generally:
(1) assume that all embedded openocd targets are *32bit* at most...
(2) assume all host platforms are at least 32bit host platforms
(3) and thus, target addresses are generally equal to - or smaller then
the host unsigned integers
(4) In most, if not all of the u32 cases, the format string specifies
%08x or equal.
Are these assumptions *wrong*? If so, we have major other problems we
must deal with.
There are numerous examples of this where - for instance the code does
the following:
LOG_ERROR(Verfication error address 0x%08x, read back 0x%02x,
expected 0x%02x, address + wrote + i, readback[i], chunk[i]);
In this specific case, the *correct* fix is something else.
The address parameter really needs a *function* that handles the width
value. Otherwise, a 64bit target will not work. We are not proposing
to fix these situations today are we? Doing so would really be better
served by a function something like:
char *target_address_as_hex( CORE_ADDR address_value );
One can 'question' the two 8bit values printed, allow me to make my
point another way.
Here is another example:
LOG_INFO( device id = 0x%08x (manuf 0x%03x dev 0x%02x, ver 0x%03x),
device_id, (device_id1)0x7ff, (device_id12)0xff,
(device_id20)0xfff );
The format strings alone tell me that a 32bit unsigned *INTEGER* is
sufficient.
As does the math operators.
Since our *basic* assumption of the host platform is at least a 32bit
unsigned int
A simple cast is valid here.
Are you suggesting that our *basic* host assumption is wrong?
duane 9) a cast to a basic type in this case is the K.I.S.S.
solution.duane
zach I don't care one white about KISS if the code is wrong.
Is this a pedantic position/point you are trying to make?
The code today has *major* problems if/when we have a 64bit target.
The code is more *wrong* when we have 32bit hosts and 64bit targets.
-Duane.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] committed - printf() warning fixes
zach I am opposed to reverting the changes; I would rather zach we take some time to audit the code and fix the system zach to ensure we improve portability. Agreed 100% zach In the same process, we could also fix zach up the 160 odd places where strtoul is zach used without sufficient error checking. Agreed, but i'm messing with other stuff right now and these changes are disruptive. -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [Openocd-svn] r2293 - trunk/src/jtag
Rick Altherr wrote: Rather than casting to int, should the printf's be using the PRI* macros for uint32_t? To be clear, the LOG_INFO() format string is: LOG_INFO(U_tg = %d mV, U_aux = %d mV, U_tgpwr = %d mV, I_tgpwr = %d mA, D1 = %d, Target power %s %s\n, \ Really, if that is *truly* what is needed here, then I want to purchase one of those chips. Imagine, if that chip could *REALLY* withstand a 2^31 - millivolt input *and* handle 2^31 milliAmps. The truth is somewhere else: There are no convince functions to extract a simple integer instead. The value is a U32 because the developer was _lazy_. The solution you suggest - is the tail wagging the dog. -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Nit to pick with recent set of cleanups
zack Seriously? You think that my efforts have increased the obfuscation?
No, in generally it is _fantastically_ better. But as they say, no good
deed goes unpunished. As I said this is a nit.
zach I hope that you can engage in a rational discussion about this
topic.
Simple. Please understand I am referring to *this* item, 99% of what you
have done is great.
duanebool okay = *str !*end ULLONG_MAX != *ul;
in that simple expression 13 things are going on.
(1) variable definition
(1) assignment
(4) variables (1 is a macro value)
(3) indirections
(1) negation
(2) logical and operators
(1) inequality test
===
total 13 things.
This does not pass the K.I.S.S. principle.
Why not not add a () around that, and do it all in the return statement
ternary operator?
Perhaps your approach is different then mine, I let the optimizer be
the smart one.
It is a well trained machine, it tends to make fewer mistakes then me.
My approach is:
(1) less complex if() statements, so what if they are nested some..
That is the optimizers job...
(2) simplistic early returns, or goto bailout' statements.
The optimizer merges and makes it better.
These help reduce nesting levels.
(3) fewer steps in a mathematical expression,
With a complex expression, the debugger cannot step through the
expression.
If you cannot step through the expression with a debugger - it's
hard to test.
(4) If needed, break the expression in half.
Add a few simple temp variables to simplify the steps
The optimizer can put them back together.
(5) Extra braces{} and/or parens() - are like Rick points out
not there for functional reasons, but for clarity reasons.
yes, there are limits on both sides of the discussion, one can easily
go overboard with the above suggestions just as poorly.
In this case - this expression, this place, my reaction was WTF!
I've also had to fight the battle of idiotic complexity scanners, and
justifying why
metric (A) is wrong here, and correct there, while metric (B) says the
opposite.
Many times I've had a new guy (from DOD work, where they had to meet
certain complexity metrics) start work and sit and think hard about
some stupid
sequence of code - much like this example, rather then simply coding it.
Why? Because the culture they grew up in required that style of work.
I always liked asking a few questions of the new guy and asking if they have
ever rated the complexity of pointer stew -
http://blogs.sun.com/plamere/entry/pointer_stew
Complex multi-step expressions like this, remind me of Pointer Stew.
===
-Duane.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Nit to pick with recent set of cleanups
bool okay = *str !*end ULLONG_MAX != *ul;
screaming-rant
In my long career, I have seen too many poor souls - including my self
become the victim of even my own seemingly simple attempts to reduce the
levels of () and {}. Yes, there are cases where it gets a little too
deep, but there must be a balance.
Openocd is not, and should never become an entry in the 'obfuscated C
code contest[1]'. It seems that we are heading down that road.
/screaming-rant
-Duane.
[1] http://www.ioccc.org/
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] RFC: struct cleanup and more
?? on The List here. If I can afford to take the time, OpenOCD will be ?? fully decoupled from its various driver modules. duane Debugging these things become a *ROYAL* *P*I*T*A* duane Symbols don't work, etc, (ie: I've been debugging some SANE drivers, ugh, and I've done quite a duane bit with these). Zach The Linux kernel shows how modules can be done well: static or dynamic. Zach I would settle for no less here. You missed a key point. How the *modules* are done - is well done, no questions asked. How modules are debugged, is another matter entirely. That is my point. -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Cygwin EOL settings - an idea..
All - I saw a while ago something about SHELLOPTS=igncr I suffered from similar problems with LANG=, to the point where - my core scripts set export - and override all LOCALE settings and force them to ENGLISH , more correctly C - not english. Once I did that, many of my problems where greatly resolved. Yea, some of my non-native english speakers complained, I (1) showed the how to undo the problem, (2) and told them when they had a fix for the bug/problem - (3) please send it to me, then (4) I would give them another bug, after a while (5) they gave up and stopped asking. Could there be something we could put in the configure script - that tells CYGWIN - to behave? ie: Perhaps something like the SHELLOPTS thing? For example - maybe in the bootstrap script? And in the CONFIGURE' script? And in the Makefiles? FYI - with SVN - is who thinks what is native and when. Tortiose - Native = Windows, period, no way to override this SVN - cygwin = Native = CYGWIN setting SVN - DOS = Native = Windows SVN - on a Linux box = Unix It's even more nasty, if you share something via SAMBA... -Duane. ___ 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
Re: [Openocd-development] [PATCH] Do not try to examine targets with disabled taps
duane $TARGETNAME mdw
david Though mdw is really impractical for scripting.
yea, it's probably a very bad example, one probably needs to use
'$targetname mem2array or $targetname array2mem, or we can create a
helper sub-command
david A third option: too painful to use. How exactly is $_TARGETNAME
david going to get *into* the event handler since nothing binds the right
david value to that name??
david I'll tell you how. By hard-wiring a particular target name.
I presume you mean the $_TARGETNAME will not be valid when the event is
invoked. TK handles events with things like %w for the window path,
treating the event handler body sort of like an sprintf() format
string. Sadly, JIM is not that complicated, I thought about adding a %T
for the current target name. That would be a good future enhancement.
But - today I think what you mean is this:
Today, all target reset handlers are done like this:
$_targetname configure -event reset-init { CURLYBRACE }
TCL variable parsing rules mean that things in { CURLYBRACE } are not
not expanded right now.
The *could* be done like this:
$_targetname configure -event reset-init double-quoted-string
In the double-quoted case, the double-quoted method would cause the
embeded $_TARGETNAME to be expanded prior to invoking the configure
sub command.
david Some of that's a general event handler issue: the event handlers
have no invocation-specific context.
There is no doubt in my mind there are giant dragons we do not know about.
david [snip] But reset haltmeans I get a bare CPU, in need of
serious re-init, and using a slow JTAG clock...)
Good example of that is a complex multi-target board. However, that
senario presents an N-way way combination that we cannot today make
reusable code for. We can, however document each thing seperately - so
that the user/victim can figure out how to weave the two reset processes
they need together.
-Duane.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Target AJAX like support - User Interface Thread
duane [ajax] david Saying AJAX or talking about any other implementation tech feels to me like putting the cart before the horse. Correct, I should have given more examples. What I ment was - 2 parts: 1) the GUI interface (a) could be built-in webserver + javascript (ajax) OR (b) could be built-in webserver + flash OR (c) could be Ecplipse + JAVA OR (d) could be Tcl/Tk app Perhaps the use of ajax is/was very premature - I really mean that sort of concept, nothing more. 2) The backend part the above pieces talk to. It responds to commands. = So what should we focus on? (A) Wizard type features to help *new*users* get started ie: Some build a basic configuration file tool. That could be *text* - ie: Answer questions, choose from a list. That's not 'inside openocd' - its more of a text configuration file' Could be as simple as Perl CPAN - text mode Or as simple as Linux Kernel make config text mode. (vrs make xconfig, or make menuconfig). (B) Day to day operational features. I think your view is more (A), and mine is more (B). -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Target AJAX like support - User Interface Thread
duane I think your view is more (A), and mine is more (B). david Yet my example of a flash download tool seems more like (B) to me. :) Seems like we both sit at two different ends of the spectrum, you see de-bricking/flashing a board as day to day I don't. That is perhaps good, it makes one think of the other use cases. If I where to list use case areas of interest - they would be: (a) my board is a brick - please help me reflash(recover) my board type GUI interface. Be it linux or some other operating system - the board is dead and must be recovered. This is more for the linux target board developer type. Also WinCE types, ie: urjtag type solution, and is more flash programmer centric Much of this is External NOR flash,or External NAND flash. What is not - is micro-controller based stuff which is more (d) then (a). Boundary scan method works (ie: the UrJTAG approach) but is slow or the download helper code (the OpenOCD approach) faster. (b) How to write a xlinix flash programer type solution aka: Much like Xilinx IMPACT, or the Altera equal (I don't know the name). This is more jtag centric. I guess this is more Dick Holenbeck type centric (he wrote the xsvf support). (c) Boundary Scan - wiggle pins on the jtag chain. People have asked about this... and we have talked about it But there are no drum beaters eager to help. (d) Debug Software Development solutions. Mostly non-linux-kernel micro controller centric uboot debug falls into this category. === agree? ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] Do not try to examine targets with disabled taps
[ targetname tapnames are the same, and is confusing] Yea, ugh, that is my fault, I did all that last year, I set the example. What I did not consider well was the TAP names when I setup my examples after creating the tcl-target-as-an-object-command. FYI - The original idea was to support multi-core targets with different names, for example: mdw - works on the current target, what ever that is... $TARGETNAME mdw That said, I think there is an easy fix - by means of 'enforcement' of naming convention. step 1: a 1 line change @ 'jtag.c' -line 1360 === FROM: sprintf( cp, %s.%s, pTap-chip, pTap-tapname ); TO: sprintf( cp, %s.%s.tap, pTap-chip, pTap-tapname ); This *forces* all tapnames to have the suffix .tap. Step 2, there are 2 options, if (1) is done, I think (B) should be done. (A) a purely mechanical change on all -chain-position options in the CFG files, adding the .tap suffix. (B) Hidden in C code... effectively enforced, like above, see target.c - line 3444..3456 It's important to do that *THERE* - not inside: jtag_tap_by_jim_obj() Reason is we want to add .tap when we *configure* a target. Step 3. is cleanup, I think only applies to the OMAP3530 (beagle board) ie: opmap3530.cfg - the various irscan and drscan commands would need tweaks. ie: From: irscan omap3.jrc ... To: irscan omap3.jrc.tap In total, I think (1) and (2)(B) - make the most amount of sense, ie: taps are named with .tap at the end, there is no other way to do so, and makes it very clear to the the user/victim, ie: If it *ENDS* with *TAP* - it is the *TAP* ... -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] FT2232H based dongle with adaptive clocking support
Patrick Wieland wrote: I am working on a OpenOCD dongle based on the FT2232H. I want to support The FT2232H is already supported :-) See the configure option: --enable-ftd2xx-highspeed Enable building support for FT2232H and FT4232H-based devices (requires =libftd2xx-0.4.16) Look for BUILD_FTD2XX_HIGHSPEED in the source code. Who exactly makes your dongle? Look at src/jtag/ft2232.c - ft2232_layouts[]) To enable adaptive clocking, You specify the jtag clock speed as ZERO. -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] FT2232H based dongle with adaptive clocking support
Patrick Wieland wrote: (I added some ultra high speed level shifters FYI - the XVERVE -signalyzer has this built in, as does many of the SEGGER dongles, do check, you can screw up a target board easily enough. http://www.signalyzer.com/ Warning: the signalyzer *LITE* version - is 3.3/5.0V only! You said I'd have to set jtag clock speed to zero, to enable adaptive clocking, ok, but my problem is how to tell OpenOCD what the current target speed is. You don't need to tell it anything other then 0. ARM has a nice diagram, see the OPENOCD Users manual - Chapter 23, FAQ #1 - *RTCK, also known as: Adaptive Clocking - What is it? it explains this in more detail.* http://openocd.berlios.de/doc/html/FAQ.html#FAQ It has a link to: http://www.arm.com/support/faqdev/4170.html In the ARM diagram, Look at the TCK synchronizer and the RTCK signal to the TAP in the block diagram on the ARM site. -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] Do not try to examine targets with disabled taps
duane $TARGETNAME mdw david You'll notice most of the reset-init event handlers can't use that. CAN'T - or just happen to not use that - Big difference. By design, they should be able to do exactly that, see: src/target/target.c - lines 3559 ... 3731 By design, it should work, that is why for example how [$TARGETNAME cget -chain-position] works. == duane (B) Hidden in C code... effectively enforced, like above, see target.c duane - line 3444..3456 david That is, the -chain-position logic should change? Yes, exactly. What is happening here is the tap_by_jim_obj() is passed the argument to the -chain-position parameter. I suggest instead, doing a simple sprintf() and add .tap as a suffix here That can be done *IN*CODE* - or in the CFG file... One could argue (2)(A) or (2)(B) - either way... it's a toss up. = david If one were to take your (1) forcing the .tap suffix, then IMO david the correct route is to take your (2A) and change all scripts, david plus (1a) update the TAP naming convention to tell folk not to david use tap themselves, and (1b) when creating targets, reject david any target name with a .tap suffix. I do like your approach - it *enforces* a specific naming scheme that is unambiguously clear that foo.tap is the *TAP* and not the thing the tap is controlling, be that boundary scan or a cpu, or a embedded flash. david This seems to me like it'd be much thrash for not much benefit. In consumer electronics, the most important thing is: Can the customer understand/install the product without using the manual. In our case, that will be impossible, but reducing manual lookups is a good thing. There's a subtle thing here that I did when I created these new commands, I quietly enforced inline documentation of parameters in the script files. How? I *COULD* have made the parameters positional, ie: 'the 5th parameter is the tap name' - but i did not on purpose. By *REQUIRING* a prefix it serves as *EXPLICIT* documentation of the parameters purpose, one does not need a comment line above the script command explaining the positional parameters :-) Look at the flash bank command as a *nasty* example. (tcl/target/sam7x256.cfg - line 48) Sure, it is extra typing - but - it is *far*less* end user and developer confusion, after a few parameters I can't keep track of the order of things. It's not thrash if it becomes *in*line* documentation, think +2 years from now, with +10 more targets, and +10 more boards, they will be better documented, that is the bigger win. -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] FT2232H based dongle with adaptive clocking support
Patrick Wieland wrote: So the JTAG-debugger needs an input pin attached to RTCK. OpenOCD has to monitor the state of this pin an wait for a falling edge. When this has been detected, OpenOCD can generate the next clock tick, resp. rising edge on TCK.. right? Is this that what the Amontec Chameleon Dongle is doing in source file 'amt_jtagaccel.c' function 'amt wait scan busy()' ? Be careful with your terms, it is the jtag dongle that needs the input, and the 'jtag dongle needs to be told to use/honor the signal. The jtag dongle generates the JTAG clock, the synch circuit in the target chip, throttles the clock frequency. There is no *debugger* there. Instead, the debugger is GDB.. the debugger GDB connects to openocd - which then controls the jtag dongle, which in turn controls wiggles pins on the jtag interface. I think you are *buried* in the details. 1) gdb - This is the debugger. 2) gdbremote-protocol (via tcp/ip) 3) openocd (application) 3) often a usb interface (sometimes parallel port) 4) if USB - often a ftdi-chip is used -- This is the jtag dongle. 5) In your case, 1.2v level shifters 6) the jtag tap on your chip 7) the arm cpu you want to control and debug your code with. But to answer your question ... Yes, a pin is needed. This is handled *automagically* by the FT2232H chip, you only need to enable it. The ftdi-2232-H monitors the RTCK signal on GPIOL4 See: http://www.ftdichip.com/Documents/AppNotes/AN_108_Command_Processor_for_MPSSE_and_MCU_Host_Bus_Emulation_Modes.pdf Section 6.9 -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [COMMIT] jlink 8bit TLR patch
peter In communication with Rolf Segger, who helpfully contacted me, Thank you Mr Segger - your participation and help is quite great, I have several oem versions of your JLINK, I have to say that your company makes good stuff. Keep up the good work. I don't know how many versions in between are out in the wild, and which ones do or don't require the fix. The question is, should we leave it in, or detect an older firmware and actively suggest an upgrade? The Linux update utility doesn't work - you have to do it in Windows. I suggest the following: This happens *ONLY* on power up. Leave it, extra clocks here don't hurt, its done once... Insert a comment that specifically refers to *THIS* thread on the mailing list. Issue a *DEBUG* warning. Let's not confuse a developer who is using OpenOCD if we can just make it work. Bottom line: OpenOCD - should just work - out of the (virtual) box. -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Target AJAX like support - User Interface Thread
zach Duane, Did you write this plan up? Got Links? If not, care to revisit
zach the vision in a new thread on the list or a patch to The Manual? :)
Nothing wrote up - so I'll put some ideas and concepts here that
could/should be put into the developer manual
This is vision - nothing is cast in stone, so toss up some ideas.
This is the *USERINTERFACE* part of the discussion.
Another thread will be the *command ideas*.
It is *UTTERLY* important that we get this API correct - otherwise we
will screw this feature up big time.
I cannot recommend this GOOGLE TECH TALK - enough
http://lcsd05.cs.tamu.edu/slides/keynote.pdf
http://video.google.com/videoplay?docid=-3733345136856180693
http://www.youtube.com/watch?v=aAb7hSCtvGw
I wrote this 'out of my head' tonight, it is not clean. I've been
thinking about this for quite some time.
You know, we *COULD* - have OpenOCD serve out the OpenOCD manual this
way too.
Hmm Interesting
-Duane
== For reference ==
I assume the reader has read:
${OPENOCD_SRC}/doc/manual/server.txt
That is the starting point of this discussion.
Let us assume the user has opened their web browser and points it at the
openocd built-in-web-server.
What happens?
What is available?
Let's talk about what the user should be able to do.
I want to paint a picture...
Primary
General Experience Goal - Ability Locally Override
Location #1;
The user should always be able to stuff some files in a 'project
local directory'
and serve those files out when the user connects to the built in web
server.
[ie: the directory where OpenOCD runs].
If those files are not found, OpenOCD - searches *standard* places.
Example: My working directory is: c:\myproject
the OpenOCD config file is called: c:\myproject\openocd.cfg
I should be able to put files in: c:\myproject\openocd\
thisdirectory and override the system.
Remember: there are often lots of html files, to many to clutter the
current directory.
Location #2
Users ${HOME}/.openocd/http directory
Location #3
${INSTALLDIR}/ .
Main HTML page - what should index.html be?
There should be 2 of them.
(a) the main full featured one.
(b) the framed header - that wraps around a users file.
Framed Header EXAMPLE:
If I create a my own index.html file.
We should be able to frame that with a small title bar with some
links.
sort of like google image search - It has the original at the top
of the page.
This should exists so that the user always has an out and can get
to the main default openocd page.
Maybe that FRAMED header - is fancy and uses something like this:
http://www.brainjar.com/dhtml/menubar/demo.html
STATIC FILES
We should be able to create some simple html files, for example:
SPECIFICALLY:
These are *directories* where all kinds of kewl things can be put.
What ever you want... the examples here are *directories*
http://localhost:/openocd/static/chip/xilinx/XC3S500E-4FG320C
http://localhost:/openocd/static/target/st/str912
http://localhost:/openocd/static/board/atmel/sam3u-ek
http://localhost:/openocd/static/dongle/xverve/signalizer
Rules should be like Apache.:
First - try the given name.
If the given name is a directory, append index.html and try again.
LOCATION
These files should be in the install directory, these would be
under openod/httpd/static/whatever
the httpd directory should be Parallel to the TCL, and other
directories under install.
REQUIRED FILES
index.html - for static content
or index.tcl- for dynamic content }
OPTIONAL (strongly suggested) various meta-data.json.
TBD - exact format, style, etc.
TBD - other format, other names.
Example: 'flash.json' - could describe the on-board (or
on-chip) flash.
Example: 'memory.json' could describe the memory map.
Example: 'cpu.json' - could describe the CPU.
The cpu.json file in the *board* or *target* directory might
have an http-redirect
example: openocd/static/chip/st/stm32/cpu.json - might REFER
to core/arm/cortex-m3.html
Likewise, the pic32 - might *refer* to the mips/m4k.html
These meta-data files - can be used by some *GENERIC* AJAX like things
that create a *MEMORY* view web page, or a FLASH program page.
Maybe another that can b used to *view/edit/change* cpu registers, or
maybe the ARM co-processor registers.
Imagine a memoryviewer.java - application that uses the meta data
file: 'memory.json' as configuration data.
TBD:
Exact format and content of the *details.json* file.
I think JSON is a simple easy to understand and use file format.
It is also easy for us simple humans to
[Openocd-development] Target - AJAX - Command Ideas
PART DUEX == To understand this - please - read my earlier thread: Target AJAX like support - User Interface Thread. This thread discusses the command ideas. The user interface part is in the earlier thread. What ever we do - we need to come up with a Nifty Protocol name for this part, some name that is utterly silly or socially offensive. -Duane. === I will repeat my self, this point is UTTERLY important that we get this API correct - otherwise we will screw this feature up big time. I cannot recommend this GOOGLE TECH TALK - enough http://lcsd05.cs.tamu.edu/slides/keynote.pdf http://video.google.com/videoplay?docid=-3733345136856180693 http://www.youtube.com/watch?v=aAb7hSCtvGw === SENDING COMMANDS === The tiny server supports HTTP post, and HTTP GET, those are probably enough for our purposes. Lets assume those 2 methods are plenty. = RECEIVING REPLIES = Today, we have a TCL command server. That can continue easily enough. But I want to verify that this is *STILL* a good solution. I cannot judge from the stand point of AJAX, FLASH, and JAVA, which is better. To what degree can they open a socket and talk to it? is this utterly easy? Or is the answer something else: They can, but it is painful, it is easier if we do some type of XHTML requests instead? My understanding of AJAX comes from this: http://www.brainjar.com/dhtml/ajax/default.asp Let us assume the server *CANNOT* easily respond with XML.. Can we choose another format that is simple and easy to parse? Most if not all commands need to return data in some name/value type format that is extendable and easy to parse. I am ignoring the transport scheme, pending resolution of the above). Using the version number request - (below) as an example, the element names (or tag-names) might be: protocol-version: 123 svn-version: 456 sign-on-string: The fancy new openocd version 1.2.3 built by du...@borgcube on 2009.06.03 XML is another idea. JSON is another. Simple ASCII text, as shown above is also very simple, in effect, the reply data component looks like http-headers (on purpose). I cannot judge how easy it is for any of these common web-script languages do the majic they do. I would like input from others about this. = Minimal Commands: = (a) What version are you Reply is multi-part (1) the protocol version number (2) the SVN version number (3) the sign on string OpenOCD gives @ startup. = (b) What are the list of targets. = Reply is the list of names supplied to 'target create' = (c) What are the list of taps? = Reply is the list of names supplied to 'jtag newtap' = (d) There should be *NO* concept of active tap, nor active target = In all cases, all command should *require* a specific target or tap name be specified = (d) For any target, or tap, or board = A means to get *details* about the target or tap, or board Using the TAPNAME, the TARGETNAME, or ?something? as a key. In general, this details request should be redirected to a *static* pre configured file, perhaps a *JSON* file, for example, the request URL might be: http://localhost:/openocd/static/chipatmel/at91sam9260/memory.json (See the 'static meta-data files' in my earlier thread). == (e) The ability to read the value of some TCL variables. == For example, assume I have a TARGET name in my Javascript. That target name might be: at91sam9260.cpu Return the details file for this target. [see above] === (f) The ability to read/write memory === In effect, where one can specify the *width* of the access. target_read_memory() And target_write_memory(). (g) CPU Registers (specifically GDB registers) The ability to get the *NAMES* of the CPU registers. This might come from a cpu-reg-names.json file. The ability to *read* and *write* those registers. I'd hope this would use a common viewer sheme. (h) The ability to read special cpu registers For example ARM cp15 - is not a GDB register. These might be a *special-register-viewer* file. It is late, that is the idea I've had in mind for +1 year And is probably good food for thought for now. *END* ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Target - AJAX - Command Ideas
PART DUEX == To understand this - please - read my earlier thread: Target AJAX like support - User Interface Thread. This thread discusses the command ideas. The user interface part is in the earlier thread. What ever we do - we need to come up with a Nifty Protocol name for this part, some name that is utterly silly or socially offensive. -Duane. === I will repeat my self, this point is UTTERLY important that we get this API correct - otherwise we will screw this feature up big time. I cannot recommend this GOOGLE TECH TALK - enough http://lcsd05.cs.tamu.edu/slides/keynote.pdf http://video.google.com/videoplay?docid=-3733345136856180693 http://www.youtube.com/watch?v=aAb7hSCtvGw === SENDING COMMANDS === The tiny server supports HTTP post, and HTTP GET, those are probably enough for our purposes. Lets assume those 2 methods are plenty. = RECEIVING REPLIES = Today, we have a TCL command server. That can continue easily enough. But I want to verify that this is *STILL* a good solution. I cannot judge from the stand point of AJAX, FLASH, and JAVA, which is better. To what degree can they open a socket and talk to it? is this utterly easy? Or is the answer something else: They can, but it is painful, it is easier if we do some type of XHTML requests instead? My understanding of AJAX comes from this: http://www.brainjar.com/dhtml/ajax/default.asp Let us assume the server *CANNOT* easily respond with XML.. Can we choose another format that is simple and easy to parse? Most if not all commands need to return data in some name/value type format that is extendable and easy to parse. I am ignoring the transport scheme, pending resolution of the above). Using the version number request - (below) as an example, the element names (or tag-names) might be: protocol-version: 123 svn-version: 456 sign-on-string: The fancy new openocd version 1.2.3 built by du...@borgcube on 2009.06.03 XML is another idea. JSON is another. Simple ASCII text, as shown above is also very simple, in effect, the reply data component looks like http-headers (on purpose). I cannot judge how easy it is for any of these common web-script languages do the majic they do. I would like input from others about this. = Minimal Commands: = (a) What version are you Reply is multi-part (1) the protocol version number (2) the SVN version number (3) the sign on string OpenOCD gives @ startup. = (b) What are the list of targets. = Reply is the list of names supplied to 'target create' = (c) What are the list of taps? = Reply is the list of names supplied to 'jtag newtap' = (d) There should be *NO* concept of active tap, nor active target = In all cases, all command should *require* a specific target or tap name be specified = (d) For any target, or tap, or board = A means to get *details* about the target or tap, or board Using the TAPNAME, the TARGETNAME, or ?something? as a key. In general, this details request should be redirected to a *static* pre configured file, perhaps a *JSON* file, for example, the request URL might be: http://localhost:/openocd/static/chipatmel/at91sam9260/memory.json (See the 'static meta-data files' in my earlier thread). == (e) The ability to read the value of some TCL variables. == For example, assume I have a TARGET name in my Javascript. That target name might be: at91sam9260.cpu Return the details file for this target. [see above] === (f) The ability to read/write memory === In effect, where one can specify the *width* of the access. target_read_memory() And target_write_memory(). (g) CPU Registers (specifically GDB registers) The ability to get the *NAMES* of the CPU registers. This might come from a cpu-reg-names.json file. The ability to *read* and *write* those registers. I'd hope this would use a common viewer sheme. (h) The ability to read special cpu registers For example ARM cp15 - is not a GDB register. These might be a *special-register-viewer* file. It is late, that is the idea I've had in mind for +1 year And is probably good food for thought for now. *END* ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] questions about irscan/drscan/etc
someone asked [something like: But what would a TCL user expect]. Hmm, What does not happen to day, is the ability to scan out data bits and capture them in TCL. I think the following would be helpful # Goto this state by any means desired, via any random path, really only good for RESET jtag gotostate STATENAME # Goto next state, must be exactly 1 clock/tms step away, can list multiple states jtag nextstate STATENAME [... more STATENAMEs] # Tell this tap to do a specific scan type # Tapstate must be CAPTUREDR or CAPTUREIR otherwise error jtag scan -type DR|IR -bitlen NBITS -iarray ARRAYNAME -oarray ARRAYNAME -endstate NAME # Simplistic ir scans - of only a few bits jtag scan -type IR -bitlen 5 -value VALUE # Run clocks in RESET, IRPAUSE, DRPAUSE, or IDLE/RUN state jtag idleclocsk NCLOCKS # Finally, jtag execute # NOTE: The above commands are global # and do not account for any tap in bypass, their view is # effectively at the end of the dongle cable. # Wiggle TRST and/or SRST pins jtag set TRST 0 jtag set TRST 1 jtag set SRST 0 jtag set SRST 1 Examples jtag set TRST 0 jtag set SRST 0 sleep 500 jtag set TRST 1 jtag set SRST 1 jtag gotostate RESET jtag gotostate SHIFTIR # ? not sure here, the idea is to put the 5 bit value 0x0c in the IR register jtag scan -type IR -bitlen 5 -value 0x0c -endstate EXITIR # Scan out, 35 bits into MYBITS - with, TDI = 1 during the shift. jtag gotostate CAPTUREDR jtag scan -type DR -bitlen 35 -tdi 1 -oarray MYBITS -endstate EXITDR == -Duane == ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] new target_types.h
zach Move definition of 'struct target_type_s' into new 'target_type.h' file. Hmm, why would this not be in: #include openocd/_types_.h Or something like that, I specifically mean a file with a bunch of forward structure definitions, really simple - the file would not have 'structure contents' - only the names. ie: Something as little and as simple as this: struct foobar_s; typedef struct foobar_s foobar_t; That forward decoration types header file would in it self be very helpful. target_types.h is no better then target.h Reasoning: 90% of the time, all that is really needed/used is a *POINTER* to the structure. -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] new target_types.h
duane [about target_types.h]and openocd/types.h I do like what you have done with target_types.h - Yes, absolutely - good idea, I think I said it wrong, I'm sure I'll make that mistake again. zach You want to expose every struct name to every module? No thanks. We do that now - in a messy way, note: i say struct name not struct content zach we would not need such forward declarations if if we used the 'struct foo_s *' form instead of the typedefs. Absolutely agree with you. I *specifically* do not mean the *contents* of a structure, absolutely not. I'm trying to stop a rash of warnings like this: a.c:2: warning: struct abcXXX declared inside parameter list a.c:2: warning: its scope is only this definition or declaration, which is probably not what you want The simple workaround for the above is, a simple forward struct declaration, nothing more, as in (1) below. (1) struct abcXXX; (2) int foobar( struct abcXXX *p ); Either (A) - is done via a cascade of #include files - effectively what we have today, #include STAR.dot.STAR, and is shown below via arm11.c or (B) every H file has it's own little 'struct foo; /* forward declaration */ - This devolves over time into voodoo and countless useless 'struct foo' things added all over the place, randomly - some files have them, some don't, there is no rhyme nor reason why, suddenly a file one needs it, and the next one does not. They look out of place, people clean up - (like we are doing today) Given some time, these devolve into a mess or (C) you have a simple project specific types.h file - that contains all the simplistic basic types used in the project, and that may include a few major struct foo; names in name only (NOT with content of that struct), the moral equal to sys/types.h, it is a simple solution. Yea, a little messy, but a reasonable mess to contain. Simple rule: (a) always put a forward declaration of any structure in openocd_types.h, and (b) put the structure where it belongs, thus any function can get a pointer to the object - but that is all. (C) simplifies and streamlines the process, a simple openocd_types.h file - is always included, like it is today. For instance, I picked arm11.c - at random, then number in column 1 is the nesting level. arm11.c 1 #include arm11.h 2#include target.h 3Extra 'struct reg_s' 3 Extra 'struct trace_s' 3 Extra 'command_context_s' 3 Extra struct target_type_s' 3 Extra 'struct target_s' 3 #include breakpoints.h 4Extra struct target_s 4#include type.h 3 #include algorithm.h 4 #include type.h 3#include command.h 4 #include types.h 4 #include jim.h 2#include register.h 3 Extra 'stuct target_s' 3#include types.h 2 #include jtag.h 3#include binarybuffer.h 4 #include types.h 3#include log.h 4 #include command.h - That mess goes away with a simple openocd_types.h, the moral equal to sys/types.h - but in this case, a bunch of forward struct definitions. I am not suggesting that the contents of structs be put in this file. - -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] new target_types.h
duane Either (A) - is done via a cascade of #include files - effectively what duane we have today, #include STAR.dot.STAR, and is shown below via arm11.c zach That simply is not true. I spent a lot of time cleaning up things, and zach the tree of headers that you show below is a _gross_ improvement zach on what was going on before. I can improve this mess further, and zach without using a common header like you suggest. But we have a common header file now, 'types.h' zach I think that tree is beautiful compared to what it used to be. I agree, what you have done is *FAR* better, all that I am saying is put 'struct target_s;' (and others) in the file types.h And it will be even better! == I believe that as we go forward, and clean up things - the boiler plate list code will just grow. 3 instances of image_s ./src/flash/flash.h:32:struct image_s; ./src/server/gdb_server.h:31:struct image_s; ./src/target/etm.h:30:struct image_s; 2 instances of scan_field_s ./src/helper/binarybuffer.h:86:struct scan_field_s; ./src/jtag/jtag.h:261:struct scan_field_s; 6 instances of target_s ./src/target/arm_simulator.h:25:struct target_s; ./src/target/breakpoints.h:25:struct target_s; ./src/target/mips_m4k.h:28:struct target_s; ./src/target/register.h:28:struct target_s; ./src/target/target_type.h:6:struct target_s; ./src/target/trace.h:25:struct target_s; 3 instances of ./src/target/armv4_5_cache.h:25:struct command_context_s; ./src/target/target.h:35:struct command_context_s; ./src/target/trace.h:26:struct command_context_s; == -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] Re: [Openocd-svn] r1949 - in trunk/src/jtag: unused function, jlink
(oops, sent this to the svn-mail list Doh!)
This commit earlier - exposes a now unused function,
Patch attached.
Modified: trunk/src/jtag/jlink.c
===
--- trunk/src/jtag/jlink.c 2009-05-30 07:56:14 UTC (rev 1948)
+++ trunk/src/jtag/jlink.c 2009-05-30 11:37:21 UTC (rev 1949)
@@ -234,7 +234,6 @@
{
switch (cmd-type)
{
- case JTAG_END_STATE: jlink_execute_end_state(cmd); break;
case JTAG_RUNTEST: jlink_execute_runtest(cmd); break;
case JTAG_STATEMOVE: jlink_execute_statemove(cmd); break;
case JTAG_PATHMOVE: jlink_execute_pathmove(cmd); break;
==
Index: openocd.head/src/jtag/jlink.c
===
--- openocd.head/src/jtag/jlink.c (revision 1950)
+++ openocd.head/src/jtag/jlink.c (working copy)
@@ -150,14 +150,7 @@
.quit = jlink_quit
};
-static void jlink_execute_end_state(jtag_command_t *cmd)
-{
- DEBUG_JTAG_IO(end_state: %i, cmd-cmd.end_state-end_state);
- if (cmd-cmd.end_state-end_state != TAP_INVALID)
- jlink_end_state(cmd-cmd.end_state-end_state);
-}
-
static void jlink_execute_runtest(jtag_command_t *cmd)
{
DEBUG_JTAG_IO(runtest %i cycles, end in %i,
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Dealing with cumulative patches - and patch sets
All, (especially david zach, you seem to do this very well). Yes, this is some what off-topic for this list, but it is on topic because the list wants small more reviewable patches. To that end, I'm looking for a better way to deal with patch sets, etc. I've noticed that for example some post a nice series of 10 patches... each a minor step... in total quite a lot, and the poster tends to do all of these patches at once. Problem #1. Yea, I can create an SVN patch - from HEAD, but that's not what I'm looking for. For example - if I have 5 changes to a file, and they are standalone patches, I do the work 'independently' - ie: change 1 today, change 2 tomorrow, etc. Other then manually editing the resulting cumulative patch (a nasty job) - what better way or tool is there to do this? Problem #2 So those patches are posted... on the list, waiting for stuff, and I have other things to deal with. Creating the next patch, for a different file - or set of files is again painfully manual. Isn't there some way to say: Hey patch tool - you already know about those first 5 changes in Problem #1 please ... assume those are done, and create my patch file based on that. How can I do that? Again, other then manually editing the patch file, or manually creating crazy command lines to do the diffs/patch generation. Ideas, suggestions, techniques would be quite helpful for me. -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] support avr32
Xiaofan Chen wrote: Back to the basic, how can OpenOCD to wiggle a pin (forget about the PCB Gerber View integration part)? Is this possible? I am not so familiar with JTAG. But intuitively I think this is already difficult. Without downloading a small program to the chips, how do you toggle an I/O pin? Take a look a this introduction: http://www.corelis.com/products/Boundary-Scan_Tutorial.htm The idea is this: If you have a BSDL file, which identifies the JTAG commands, the DR scan order (bit order) of all I/O pins... you don't need much more. Step 1: Scan in a zero the pin, Step 2: Scan in a one on the pin, Step 3: Repeat. There is no target code involved. Same method is used to read the pin.. But - back to the gerber view - or something like it... Perhaps a chip outline. Maybe like the Xilinix pin allocation graphic view program. If you can read all the pins. You can draw logic 1 pins in one color, and 0 in another. If you keep reading, you could draw changing in a different color. Take that to the next level - ie: Gerber view - and you can make board traces blink different colors. -Duane. ___ 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
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] NEC V850 Core
According to an Engineer I talked to, the V850 core is a M4K core which is the same as the PIC32. No, it has a different binary instruction set. Sure has lots of the same types of instructions, however the instruction set books i have show different opcodes, and different opcode encodings. -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] openocd boundary scan
David Brownell wrote: Maybe for i.MX27 ... having a separate TAP for boundary scan seems unusual to me. atmel parts are this way, they have a pin 'JAG SEL' - you must reset the part, it has a seperate tap id when in boundary scan mode. -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] openocd boundary scan
Paul Thomas wrote: I would love to write up a tutorial on using openocd as a boundray scan tool if I get this working. I want some GUI that can do what XJAnalyser can do with Boundary Scan. http://www.xjtag.com/jtag-tools/xjanalyser-jtag-gui.php But what I really want, is that type of pin watch integrated with a GERBER viewer of the board, which would blink entire signal traces some how (not just the pins on the chip) -duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Question on V850 from NEC
Michel Catudal wrote: A MIPS question for those who know. Is there a usefull debug module in the NEC V850? I would think that it would have at least the standard MIPS module. Am I wrong to think that? According to NEC and IAR the only way to debug is to use the minicube. Michel I doubt the V850 would ever be supported by openocd. Reason: Support for it in GCC is long dead (dormant?), along with support for it in GDB, those two things have to come first. -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] run algorithm problems - and irq fiq
duane[about irqs during resume] Magnus Lundin [look here] int arm7_9_debug_entry(target_t *target) Look for buf_set_u32(dbg_ctrl-value, EICE_DBG_CONTROL_INTDIS, ... and the debug_execution flag. Yes, I see that now, thank you. it is the last parameter to the RESUME function. I notice though that the ARM11 does not turn this on. arm11.c - line 1464 Odd.. I don't understand the details there. -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] RFC: uint32_t vrs u32 - et al
zach Sorry Rick, but I think that you and Duane have lost this argument. You have failed to defend your position with facts. It's hard to 'defined my position' - when I asked this last night 9pm - and left early this AM to spend a good part of memorial day holiday on a sail boat (what a Beautiful day where I am) meanwhile, the discussion went on. I was asking more for an opinion, and the *REASON* I wanted to ask this was the recent rash of printf() formatter warning fixes, etc - and how this mess plays out over different host platform, arches, etc. ie: u32 can be created a zillion ways on some platforms, however - to stop 'printf' warnings one should perform X - what ever that is - and that step is a noble goal in it self. I thought - perhaps wrongly - that somebody could point me at something that says the portable cross platform c99 way of printing a uintwhatever_t would be specifier X or something like that. If that did exist, then yes there is a technical reason that method X is better then Y, and that technical reason wins. David's statement: they look and smell long, like an elephant - while funny, I agree with him 100%, that view has no technical component. And to day - zach - you are correct when you say: In this case, the shorthand types are the de facto standard, based on the majority of lines of code that use them. They have already won. That is however, the we always do it that way answer. Understand, I am asking the pot roast question there's another version using a baked ham http://www.snopes.com/weddings/newlywed/secret.asp http://mitmoi.blogspot.com/2006/11/pot-roast-story.html ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.2.0 Status Report
DAVID Ways other folk can help with the doc+code audits are to pick a section of the texi and convert it to use the @deffn presentation style ... then crosscheck against the code. Can you expand on this, explain a little bit more what you mean. I think, @deffn -is a texi type documentation technique, however we are using doxygen here. -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
