[Openocd-development] [patch/rfc] let reset_config tokens appear in any order
Make it so the magic "reset_config" keywords can be provided in any
order. Example, "trst_and_srst" after "srst_open_drain", omitting
the "separate" combination (which should be the default in any case).
Why? (a) Makes it easier to define things at the right
level (adapter, board, target). You can just specify the
thing you *know* instead of having to somehow "know"
extraneous things, just so you can provide a long enough
keyword list. (b) Removing needless error paths is always
good; such sequencing shouldn't matter.
This includes two behavioral changes:
(1) When "handle_reset_config" sees a parameter error, it
immediately exits without changing anything. This is
best viewed as a bugfix. (Old behavior: restore all
the defaults, even if they weren't previously active.)
(2) Only the behaviors that were explicitly specified get
changed. (Old behavior: everything else gets reset to
the "default".) So for example you can specify SRST
drive requuirements without saying anything about the
three unrelated topics you previously had to specify,
and thus with no risk of providing incorrect values.
That second one might cause confusion for any configs that end
up calling "reset_config" twice, so it will deserve to be called
out in the release notes.
Update docs accordingly. Note that at least some versions of
the texi-to-html tools can't handle "@xref{with spaces}", but
those work properly in PDF and in the info files.
---
doc/openocd.texi | 62 +--
src/jtag/jtag.c | 140 -
2 files changed, 134 insertions(+), 68 deletions(-)
... this is "PROPOSAL 1" implemented. Didn't yet sanity test.
Make it so the magic "reset_config" keywords can be provided in any
order. Example, "trst_and_srst" after "srst_open_drain", omitting
the "separate" combination (which should be the default in any case).
Why? (a) Makes it easier to define things at the right
level (adapter, board, target). You can just specify the
thing you *know* instead of having to somehow "know"
extraneous things, just so you can provide a long enough
keyword list. (b) Removing needless error paths is always
good; such sequencing shouldn't matter.
This includes two behavioral changes:
(1) When "handle_reset_config" sees a parameter error, it
immediately exits without changing anything. This is
best viewed as a bugfix. (Old behavior: restore all
the defaults, even if they weren't previously active.)
(2) Only the behaviors that were explicitly specified get
changed. (Old behavior: everything else gets reset to
the "default".) So for example you can specify SRST
drive requuirements without saying anything about the
three unrelated topics you previously had to specify,
and thus with no risk of providing incorrect values.
That second one might cause confusion for any configs that end
up calling "reset_config" twice, so it will deserve to be called
out in the release notes.
Update docs accordingly. Note that at least some versions of
the texi-to-html tools can't handle "@xref{with spaces}", but
those work properly in PDF and in the info files.
---
doc/openocd.texi | 62 +--
src/jtag/jtag.c | 140 -
2 files changed, 134 insertions(+), 68 deletions(-)
--- a/doc/openocd.texi
+++ b/doc/openocd.texi
@@ -1552,9 +1552,13 @@ jtag_rclk 3000
Every system configuration may require a different reset
configuration. This can also be quite confusing.
+Resets also interact with @var{reset-init} event handlers,
+which do things like setting up clocks and DRAM, and
+JTAG clock rates. (@xref{JTAG Speed}.)
Please see the various board files for examples.
-...@b{note} to maintainers and integrators:
+...@quotation Note
+To maintainers and integrators:
Reset configuration touches several things at once.
Normally the board configuration file
should define it and assume that the JTAG adapter supports
@@ -1565,6 +1569,7 @@ which will be true for most (or all) boa
And when the JTAG adapter doesn't support everything, the
system configuration file will need to override parts of
the reset configuration provided by other files.
+...@end quotation
@section Types of Reset
@@ -1669,31 +1674,58 @@ How long (in milliseconds) OpenOCD shoul
nTRST (active-low JTAG TAP reset) before starting new JTAG operations.
@end deffn
-...@deffn {Command} reset_config signals [combination [trst_type [srst_type]]]
+...@deffn {Command} reset_config mode_flag ...
This command tells OpenOCD the reset configuration
of your combination of JTAG interface, board, and target.
-If the JTAG interface provides SRST, but the board doesn't connect
-that signal properly, then OpenOCD can't use it. @var{signals} can
-be @option{none}, @option{trst_only}, @option{srst_only} or
-...
Re: [Openocd-development] TMS470 Scripts
Hi, 2009/5/26 Xiaofan Chen : > Does anyone have the device cfg file for TMS470 chips, like TMS470R1A256? > I searched the mailing list archive and it seems that it should work. But I > could not find a cfg file for it. How should I write the cfg file for it? I have working configuration for TMS470R1A384 with my simple parport jtag dongle. Currently I'm in the office, I will sent it later. Unfortunately I didn't update svn for a few months, because of wrong big-endian support for this chip (there is small dirty patch to workaround this issue). Maybe I will try some new revision someday. Regards, Krzysztof ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Sorry for breaking the thread
On Tue, 2009-05-26 at 12:54 +0800, Xiaofan Chen wrote: > On Tue, May 26, 2009 at 12:03 PM, Zach Welch wrote: > > On Tue, 2009-05-26 at 11:36 +0800, SimonQian wrote: > >> As Zach Welch mentioned, my posts breaks the thread. > > > > Translation: for some reason he and a few others' replies are often (but > > not always) threaded incorrectly in some e-mail readers. > > > > Just for your information, his posts do not break the thread > in Gmail. The threading is fine under Gmail. I also just discovered that I could use gconf-editor to set: apps->evolution->mail->display : thread_subject=on Still, I think the original problem lies with Foxmail. It would cause me problems to have the thread_subject feature enabled indiscriminately, which makes me think that Google and mail-archive.com are doing something much more intelligent. With simple subject matching, discussions with Threads that coincidentally have the same subject suddenly appear to be part of the same discussion. This is probably why that feature is disabled by default. Based on what Rick said (and some help from Google), it seems mail clients should be providing the References or In-Reply-To fields. Based on [1], It looks like Foxmail 6 should support this feature, so the real source of the problem remains unclear to me. Anyway, sorry for the noise. Cheers, Zach [1] http://gladiator-antivirus.com/forum/index.php?showtopic=28343 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] issues with openocd/src/target/interface/calao-usb-a9260*
Who maintains these OpenOCD files? The c01.cfg and c02.cfg files differ only in the PID: interface ft2232 ft2232_layout jtagkey ft2232_device_desc "USB-A9260 A" ft2232_vid_pid 0x0403 0x6010 script interface/calao-usb-a9260.cfg script target/at91sam9260minimal.cfg * BUG: shouldn't include a "target" file or a second interface. * BUG: no such file "at91sam9260minimal.cfg"... That "interface" file is buggy too: jtag_speed 1200 0 jtag_nsrst_delay 200 jtag_ntrst_delay 200 * BUG: doesn't define an interface * BUG: extra argument to jtag_speed I'm guessing these are the "usb key" type products, so these would better be moved to board/* with the non-"interface" code directly incorporated ... and the jtag_speed thing fixed. (Perhaps after the upcoming move of all the config files to a new spot in the source tree.) [ I've CC'd the Calao Systems "tech support" email, in hopes that maybe they'll update these two ... and maybe even contribute configs for their other boards which integrate ft2232-based JTAG, before the release process starts tightening down next month. ] - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Sorry for breaking the thread
On Tue, May 26, 2009 at 12:03 PM, Zach Welch wrote: > On Tue, 2009-05-26 at 11:36 +0800, SimonQian wrote: >> As Zach Welch mentioned, my posts breaks the thread. > > Translation: for some reason he and a few others' replies are often (but > not always) threaded incorrectly in some e-mail readers. > Just for your information, his posts do not break the thread in Gmail. The threading is fine under Gmail. -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Sorry for breaking the thread
2009/5/26 SimonQian : > As Zach Welch mentioned, my posts breaks the thread. > I don't know why, and even don't know how to break it. > I'll switch to GMail for OpenOCD maillist. > Should it be working properly? Yes Gmail is a very good option for mailing list. It works very well. The worst may be Outlook (not Outlook Express) which is very difficult to not to top post. Lotus Notes may be in the same league as Outlook. Both are widely used in the Corporate world though where top posting seems to be more appropriate in most cases. But top posting seems to be despised in many mailing lists. -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Sorry for breaking the thread
It appears that his mailer (Foxmail according to the headers) doesn't include the References: header when replying. Rick On May 25, 2009, at 9:03 PM, Zach Welch wrote: On Tue, 2009-05-26 at 11:36 +0800, SimonQian wrote: As Zach Welch mentioned, my posts breaks the thread. Translation: for some reason he and a few others' replies are often (but not always) threaded incorrectly in some e-mail readers. To give a basis for comparison, look at the BerliOS archive of his thread today, entitled 'svn tap name patch': https://lists.berlios.de/pipermail/openocd-development/2009-May/thread.html It appears as several scattered different threads, which is how it appeared in my mailbox (amidst all the other threads). Interestingly, more research shows that mail-archive.com handled it just fine: http://www.mail-archive.com/openocd-development@lists.berlios.de/ If I had to guess, they are smart enough to look for these kinds of exceptions based on subject. That's buggy in other respects. I don't know why, and even don't know how to break it. Me neither. I wrote you to see if we could figure it out off-list. My first guess might buggy/old client software; a new one might be related to different native languages (i18n bugs). I'll switch to GMail for OpenOCD maillist. Should it be working properly? Most likely. I cannot fathom what the problems might be. After having done the above research, I am willing to admit that there are bugs in Evolution's threading (at least compared to mail-archive.com), but the fact that mailman has the same problems says something bigger is happening here. Can anyone clue us in? Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development -- Rick Altherr kc8...@kc8apf.net "He said he hadn't had a byte in three days. I had a short, so I split it with him." -- Unsigned smime.p7s Description: S/MIME cryptographic signature ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] RFC: uint32_t vrs u32 - et al
On May 25, 2009, at 6:31 PM, David Brownell wrote: On Monday 25 May 2009, Rick Altherr wrote: Actually, David Brownell agrees that it does fix bugs regarding portability of the existing definitions in types.h. Perhaps your passion for this debate clouded your sight to that fact. Trust me, there is no passion on this end. Only experience and willingness to "do the right thing". There are no reports of bugs encountered by users that are solved by changing the types with either patch for 0.2.0. The only potential case is for Windows 64-bit since ints become 64-bit. Otherwise, all of our platforms correctly map the types as defined. I don't think you can know what "all our platforms" are though. The code should just work on all platforms where the various prerequisites are available; this set of developers will have only partial coverage. Merging Zach's patch is a way to help make *sure* that any bugs which appear can not be specific to OpenOCD. And if anyone is really claiming it's too risky to merge now, I'd conclude that we must only be a week or two from release... I consider changing the basic type definitions to be fairly risky even if it shouldn't change for most platforms. You are correct that we don't know all the platforms where the code is compiled. That's a side effect of distributing as source. Of course, we do know the platforms that we regularly use and we also know that they currently work. Ultimately, I'm one voice in the crowd. Zach and numerous others have commit privileges to the repo. If the community has decided that such a patch is low enough risk and important enough for the next release, then so be it. I do not support such a decision, but such is the way of dealing with any group of people working together. -- Rick Altherr kc8...@kc8apf.net "He said he hadn't had a byte in three days. I had a short, so I split it with him." -- Unsigned smime.p7s Description: S/MIME cryptographic signature ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Sorry for breaking the thread
On Tue, 2009-05-26 at 11:36 +0800, SimonQian wrote: > As Zach Welch mentioned, my posts breaks the thread. Translation: for some reason he and a few others' replies are often (but not always) threaded incorrectly in some e-mail readers. To give a basis for comparison, look at the BerliOS archive of his thread today, entitled 'svn tap name patch': https://lists.berlios.de/pipermail/openocd-development/2009-May/thread.html It appears as several scattered different threads, which is how it appeared in my mailbox (amidst all the other threads). Interestingly, more research shows that mail-archive.com handled it just fine: http://www.mail-archive.com/openocd-development@lists.berlios.de/ If I had to guess, they are smart enough to look for these kinds of exceptions based on subject. That's buggy in other respects. > I don't know why, and even don't know how to break it. Me neither. I wrote you to see if we could figure it out off-list. My first guess might buggy/old client software; a new one might be related to different native languages (i18n bugs). > I'll switch to GMail for OpenOCD maillist. > Should it be working properly? Most likely. I cannot fathom what the problems might be. After having done the above research, I am willing to admit that there are bugs in Evolution's threading (at least compared to mail-archive.com), but the fact that mailman has the same problems says something bigger is happening here. Can anyone clue us in? Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Sorry for breaking the thread
As Zach Welch mentioned, my posts breaks the thread. I don't know why, and even don't know how to break it. I'll switch to GMail for OpenOCD maillist. Should it be working properly? 2009-05-26 Best Regards, Simon Qian SimonQian(simonq...@simonqian.com) www.SimonQian.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] RFC: smoketest plans (was Re: 0.2.0 Pending RFCs)
Hi all,
I started this outline of my "smoketest" plans as a reply to David, but
it grew enough to deserve spawning its own new thread.
On Sun, 2009-05-24 at 14:20 -0700, David Brownell wrote:
> On Saturday 23 May 2009, Zach Welch wrote:
> > 5) commit testing tools
> > - one-step smoke tests! I probably need another week for this.
> > - all in-tree with no new dependencies (maybe a Perl module or two)
> > -
> > http://www.mail-archive.com/openocd-development@lists.berlios.de/msg04030.html
>
> What's the future of the existing testing/* stuff by the way?
> Not that I've done more than glance at it ...
I am hoping that parts of it can be integrated at the lowest level, but
it would take a lot of work to get it to where I want. I haven't
figured out how to run those tests (much less extend them), so I think
it will be difficult for users to try them out as it stands.
I view each user's contribution as only part of a single smoke-test. In
other words, accurate test results will only be derivable after amassing
multitudes of reports from many different users. Further, I want to
allow users collect to their own reports and data, as it should be
possible to extend the smoke-test for custom work. This seeks to
provide the same extensibility for testing as the configuration files
that we want to give interface/chip/target/board support.
For the data set to be useful, these results need to be easy and fast to
produce (and include all of the information required to diagnose
frequently seen problems), and the results need to be available for
others to review instantly. Users making (or collecting) these reports
should need only their SVN working copy and standard development tools,
but the data should not be required to be stored in the repository.
In parallel and conjunction with my Support DB work, here are some
things that I have vaguely planed to implement in this area:
- extend 'make check' with a smoketest app
- checks for OOCD_TEST_CONFIG, etc. in environment (or config file)
- if properly set, runs the smoke test with specified parameters
- openocd -f ${OOCD_TEST_CONFIG}
- implies a modular test suite (see below)
- should be able to run some minimal tests with dummy interface:
- compare results of baseline sanity checks with expected results
- builds a more complete test suite:
- existing testing/examples/ look like a great start
- all targets should be tested fully and for all capabilities
- we do NOT want a "lowest common denominator" test suite
- ... but can we start with one to get going?
- probably requires one test configuration file per board/target
- modularization can occur here, just like with targets/boards/chips
- coverage can increase over time, building up bundles of tests
- add 'smoketest' Makefile target:
- calls 'make check' (and the smoketest app)
- gather inputs and output into a report file
- add targets to post the report:
- 'smokereport' -- send to list via e-mail (via sendmail)
- 'smokepost' -- send web form (via curl or other script)
- automatically build tool-chains required for cross-compiling
- produce mingw32, arm-elf, others using in-tree scripts
- build all required target code from sources
If I get a little bit further, I will be able to address all of these
issues in much greater detail. I am hoping the original author of the
'testing/' code will step forward and contribute their feedback; I have
started to eyeball its documentation for incorporation into The Manual.
If nothing else, Øyvind added the new selftest.cfg to the tree, so I
expect that he will want to contribute to this effort when he gets back
from his vacation. I would like to try to get some or all of these
features in place for 0.2.0, since these should not affect the core
functionality of OpenOCD in any respect.
Cheers,
Zach
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.2.0 Pending RFCs
On Sat, 2009-05-23 at 21:55 -0700, Zach Welch wrote: [snip] > 2) move board, target, and interface Jim script directories to src/tcl/ > - this will move the whole directories intact, parallel to tcl/chip. > - more structure can be added, if we see fit; this is a small step. > - > http://www.mail-archive.com/openocd-development@lists.berlios.de/msg04685.html > > 3) move src/tcl to tcl/ > - aims to cleanly separate the C and TCL code trees > - > http://www.mail-archive.com/openocd-development@lists.berlios.de/msg04699.html > > 4) change location of installed files: > - RPM packaging exposed filesystem standards conformance issues. > - need to resolve the list of changes to make, to do during the above. > - > http://www.mail-archive.com/openocd-development@lists.berlios.de/msg04626.html [snip] At this point, I believe all of the opposition to the above ideas has been resolved in favor of proceeding with their proposed actions, and no further objections have been raised. This is the final call for further discussion before I proceed to make these changes. Obviously, this will cause a serious disruption for anyone with files not committed to the tree; however, these changes will benefit the directory structure of the project immensely. When complete, users will be able to discover and explore the OpenOCD tarballs more intuitively than with the present structure. I intend to commit these changes in the order listed. This means you should wait to clean up until all of the moving has been finished (steps labeled 2 and 3 above). The final step (labeled 4) will consist of purely automake input changes, from what I can see today. Afterwards, there should be absolutely _zero_ functional changes. If you have changes or new files in these parts of your working copies, migration from the old version will simply require you to: 1) move any local files from their old locations to the new, then 2) remove the old directory structures Reverse migration should be possible using similar steps. Please let me know if I have overlooked anything in these matters. Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] openocd & boundary scan
> > When I do scan_chain > > I get both imx27.bs and imx27.cpu which looks normal. Maybe for i.MX27 ... having a separate TAP for boundary scan seems unusual to me. ISTR that most ARM cores are set up so that they have an integrator-provided scan chain (plus the EmbeddedICE, maybe an ETM, etc), conventionally for boundary scan. And several TI chips have their boundary scan hanging off the IcePICK, a.k.a. "JTAG Routing Controller" (JRC), so it's accessible even when the various ARM and DSP cores aren't switched into the scan chain. Re how to do it ... I'd kind of hope that a key step would be throwing a BSDL file into the OpenOCD config, since making *use* of the boundary scan involves info that's in that file. Example, knowing which registers to use, how big they are, what the bit semantics are, what instruction opcodes are involved, etc. - Dave ___ 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
On Monday 25 May 2009, Rick Altherr wrote: > > > > Actually, David Brownell agrees that it does fix bugs regarding > > portability of the existing definitions in types.h. > > > > Perhaps your passion for this debate clouded your sight to that fact. > > > > Trust me, there is no passion on this end. Only experience and > willingness to "do the right thing". There are no reports of bugs > encountered by users that are solved by changing the types with either > patch for 0.2.0. The only potential case is for Windows 64-bit since > ints become 64-bit. Otherwise, all of our platforms correctly map the > types as defined. I don't think you can know what "all our platforms" are though. The code should just work on all platforms where the various prerequisites are available; this set of developers will have only partial coverage. Merging Zach's patch is a way to help make *sure* that any bugs which appear can not be specific to OpenOCD. And if anyone is really claiming it's too risky to merge now, I'd conclude that we must only be a week or two from release... ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] svf patch for segfault
On Tue, 2009-05-26 at 02:03 +0800, SimonQian wrote: > This patch fix segfault reported by R.Doss. > Committed, r1915. --Z ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] svf patch for 32bit scan
On Tue, 2009-05-26 at 00:34 +0800, SimonQian wrote: > Add svf_get_mask_u32 to generate a mask according to bitlen. > Fix this bug in other functions except for svf_check_tdo. > > Next patch will fix the segfault reported by R.Doss. > Committed, r1914. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] openocd & boundary scan
On Tue, May 26, 2009 at 8:17 AM, Zach Welch wrote: > I recently added "BSDL support" to a pending patch to The List of tasks > to consider for the future, but any kind of "full" boundary scan support > would be great for OpenOCD to have in-tree and documented. > What about the 3rd choice STAPL (other than SVF and BSDL) STAPL? http://www.jedec.org/download/search/jesd71.pdf It seems to me that some product are using it. http://www.altera.com/literature/an/AN425.pdf Open source implementation: http://www.ise.pw.edu.pl/~wzab/usb_stapl_player/index.html -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] support avr32
2009/5/26 Michel Catudal : > Then Fedora 9 should work for you if my Ubuntu script is not complete for > that. I know it will compile on Fedora 9 but not sure yet on Ubuntu. > I will have the binary and source by week end. Thanks a lot. I will take a look. I have a starter kit for XE166 but I have not used it. Infineon CAN parts (C167 and 8051) used to be popular here but not any more since ARM takes over. >>> I do have GCC for Renesas as well. If someone needs it I would need to >>> recompile it under the new systems. >>> Last I worked with it was with Fedora 8. I do have the latest source for >>> Renesas. > > I may have this one done by next week but not certain. Before I put it up I > have to make sure the package compiles good. I don't have a script made > for Ubuntu but I should be able to adapt my arm script for it. The > difference for compilation are minor. Do you need C++ or not? > No I do not need C++. What I am more interested is the one for R8C/M16C/M32C. > If some preference is made on one over the other I would suggest to put > more importance on the AVR32 devices not targeted for Linux as they are > the likely devices to be use for most small embedded designs. Unlike the > bigger AVR32 devices they do not require uboot but require some form of > JTAG debugging much like ARM7 or cortex devices. Agreed. > Parallel designs should be in place. I am very interested in having a > PIC32 debug working and am spending time on this effort. I will not > present any patches until I get something > working to my satisfaction. I would like to be informed though if anyone > else is working on it so we can exchange ideas. Thanks for the information. -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] RFC: uint32_t vrs u32 - et al
On May 25, 2009, at 5:07 PM, Zach Welch wrote:
On Mon, 2009-05-25 at 16:02 -0700, Rick Altherr wrote:
On May 25, 2009, at 3:37 PM, Zach Welch wrote:
The opposing patch is attached. As I already mentioned, it is
large,
but the changes were done entirely with the following commands:
find . -name \*.[ch] -exec sed -i .old -e 's/u8/uint8_t/g' {} \;
find . -name \*.[ch] -exec sed -i .old -e 's/u16/uint16_t/g' {}
\;
find . -name \*.[ch] -exec sed -i .old -e 's/u32/uint32_t/g' {}
\;
find . -name \*.[ch] -exec sed -i .old -e 's/u64/uint64_t/g' {}
\;
find . -name \*.[ch] -exec sed -i .old -e 's/_uint8_t/_uint8/
g' {} \;
find . -name \*.[ch] -exec sed -i .old -e 's/_uint16_t/_uint16/
g' {} \;
find . -name \*.[ch] -exec sed -i .old -e 's/_uint32_t/_uint32/
g' {} \;
find . -name \*.[ch] -exec sed -i .old -e 's/_uint64_t/_uint64/
g' {} \;
The first set just do a bulk rename of the types, but it also
changes
function names. Since it looks odd to include the _t in a
function
name, the second set changes the pattern used for function
names to
not include the _t.
I hate it. You seriously want to make all of the functions that
referred to u16 or u32 to now refer to uint16 and uint32??? This
was
_exactly_ what I meant when I said a patch would be hard to
create.
It wasn't hard to create at all. Eight find and replaces is all it
took. Less than 10 minutes.
It was incomplete and would probably raise objections from others.
How was it incomplete? It still compiled and I saw no obvious
errors. The only contentious portion is the changing of a the
function names that included uX.
1) Does not update the style guide.
2) Does not include inttypes.h or stdint.h unconditionally.
3) Does not remove those headers from other files
Basically, the rest of the work that I did in the patch that I posted.
Sure, that's all trivial, but they validate the point.
If they are trivial, it doesn't validate your point. Both patches are
viable and easy to "complete."
Also, you do realize that the scope of these changes is _much_
more
likely to be disruptive to anyone with out-of-tree changes in
progress?
Yup. It is. Sadly until we decide on all these various
conventions,
things are always going to be disruptive to those with out-of-tree
changes. At least in this case, syncing with ToT is relatively
simple. Using minimal change as an argument for is dangerous.
Consider the local minimum effect. To get to a better solution,
you
might need to stir things up a bit in the short term. The question
we
need to be asking is "Do we do a big change now, or do we live
with a
non-standard type system?"
We are talking about 0.2.0. Would you like to perform the risk/
reward
analysis of my patch versus yours, focusing on the impact they will
each
have on fixes being developed for the release?
As we already know, the bulk of the work for 0.2.0 is in the tree
already. In terms of risk/reward, both patches provide low reward
for
low-medium risk. I wouldn't really consider either for 0.2.0 just
because they don't really impact the users at all. It's just a
consistency cleanup in the code.
I would not bet on all changes being in the tree. Too presumptuous.
Considering we've been warning that the patches allowed into the tree
are being restricted, most of the active people have contributed their
patches so it will make it into 0.2.0. If their patch isn't for
0.2.0, then they should be prepared to do any updates necessary.
Actually, David Brownell agrees that it does fix bugs regarding
portability of the existing definitions in types.h.
Perhaps your passion for this debate clouded your sight to that fact.
Trust me, there is no passion on this end. Only experience and
willingness to "do the right thing". There are no reports of bugs
encountered by users that are solved by changing the types with either
patch for 0.2.0. The only potential case is for Windows 64-bit since
ints become 64-bit. Otherwise, all of our platforms correctly map the
types as defined.
If anything, my frustration derives from the fact that -- as a
maintainer yourself -- you should have been looking at the consensus
that was already being expressed by the community and let it drop
sooner
than this (nevermind 0.2.0 considerations). As a project leader, I
see
these kinds of debates as detrimental to being effective in a
community,
as it appears the individuals are unable resolve their points in an
efficient and effective manner.
There is _no_ harm is having a discussion on alternatives. It
doesn't
make us any less efficient or effective. It _does_ allow for both
side to show their cards and for the points to be clarified. I didn't
feel to need to "just drop it" because the arguments presented for
the
short types were based on preference alone. So far we've had a few
early opinions followed by a few long opinions. Only you and I seem
to really be debating anything. Th
Re: [Openocd-development] [patch] reset configuration doc updates
On Mon, 2009-05-25 at 15:34 -0700, David Brownell wrote: > Update the "Reset Configuration" information in the User's guide: > > - Convert to @deffn syntax > - Move tutorial text from command descriptions into new sections > - Describe several different types of JTAG-visible reset > - Expand descriptions of configuration tweaks for SRST and TRST > - Link to the "reset" command, and vice versa > - Bugfix the "reset_config" description (it didn't match the code) > > Plus, be more proscriptive: do it in board config files, except for > the oddball cases where that won't work. (Current target.cfg files > seem to have much goofage there; several seem board-specific.) > --- > doc/openocd.texi | 176 - > 1 file changed, 121 insertions(+), 55 deletions(-) Committed, r1913. --Z ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] support avr32
Xiaofan Chen a écrit : > 2009/5/25 Michel Catudal : > > >>> Within theses chips and ColdFire, Infineon XE166 does not seem to have gcc >>> support. >>> >> Incorrect, I have one, do you need it? I could provide some binaries on >> my web site if I have space left. >> It is about two years old, I am trying to get the lastest source but am >> having some problem with the company who so far >> has refused to abide by the GPL. They did provide me with the source a >> couple of years ago. >> I may look into updating the new sources myself but this is not my top >> priority at the moment. >> Which version would you need? I have Mandriva 2009.0, Fedora 9, SuSE >> 11.1 and Ubuntu 8.10 systems. >> > > Source codes and build instructions are the best. If not, Ubuntu will be > good since that is my main distro (now 9.04/8.10). I also use Fedora 10. > > Then Fedora 9 should work for you if my Ubuntu script is not complete for that. I know it will compile on Fedora 9 but not sure yet on Ubuntu. I will have the binary and source by week end. This would be the two year old version as I haven't been successfull into getting the latest source yet. The funny part about the company in question, they have recently bought part of a company that my employer had outsourced to a few years ago. The beauty of outsourcing ... I spent over a month fixing the mess as we were about to lose a multi million dollars contract. When the customer found out that I was again in charge they calmed down. Last week when we discussed the different compilers for infineon we had a good laugh when I noticed that. >> I do have GCC for Renesas as well. If someone needs it I would need to >> recompile it under the new systems. >> Last I worked with it was with Fedora 8. I do have the latest source for >> Renesas. >> >> > > Again, Source codes and build instructions are the best. If not, Ubuntu will > be > good since that is my main distro (now 9.04/8.10). I also use Fedora 10 > and Arch Linux (testing purpose only). > I may have this one done by next week but not certain. Before I put it up I have to make sure the package compiles good. I don't have a script made for Ubuntu but I should be able to adapt my arm script for it. The difference for compilation are minor. Do you need C++ or not? I have been using SuSE 11.1 for a while but all of a sudden my mouse double click no longer work after an update so for now most of my work is on Fedora 9. I will install Fedora 11 shortly. I have installed Ubuntu out of curiosity and so I can support systems where I install Ubuntu, but I am not impressed, Redhat is superior and packaging creation is not as much a pain as it with Ubuntu. I usually prefer to install Ubuntu for people in the family who don't know anything about Linux as it presents me less work but for my own use, no way. -- Tired of Microsoft's rebootive multitasking? then it's time to upgrade to Linux. http://home.comcast.net/~mcatudal ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] openocd & boundary scan
On Mon, 2009-05-25 at 15:21 -0700, Paul Thomas wrote: > Hello, > > I would like to do a boundary scan on a imx27 part. I've looked > through the documentation and mailing list and I don't see much on > this. The most helpful thing has been a very short wikipedia entry on > the SVF format (http://en.wikipedia.org/wiki/Serial_Vector_Format). I > do see the svf command from the telnet interface. Is svf working? Does > anyone have example files? So I take it that svf is using the irscan & > drscan functions? What are irscan & drscan doing? When I do scan_chain > I get both imx27.bs and imx27.cpu which looks normal. > > What I actually want to do with the boundary scan is check that none > of the data/address lines to the ram are shorted. I am not aware of this usage, but I figure it must be possible with some work. Hopefully, others can chime in with their experiences or ideas. I recently added "BSDL support" to a pending patch to The List of tasks to consider for the future, but any kind of "full" boundary scan support would be great for OpenOCD to have in-tree and documented. > I would love to write up a tutorial on using openocd as a boundray > scan tool if I get this working. I would love for you to do that too! Cheers, Zach ___ 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
On Mon, 2009-05-25 at 16:02 -0700, Rick Altherr wrote:
> On May 25, 2009, at 3:37 PM, Zach Welch wrote:
>
> The opposing patch is attached. As I already mentioned, it is
> large,
> but the changes were done entirely with the following commands:
>
> find . -name \*.[ch] -exec sed -i .old -e 's/u8/uint8_t/g' {} \;
> find . -name \*.[ch] -exec sed -i .old -e 's/u16/uint16_t/g' {} \;
> find . -name \*.[ch] -exec sed -i .old -e 's/u32/uint32_t/g' {} \;
> find . -name \*.[ch] -exec sed -i .old -e 's/u64/uint64_t/g' {} \;
>
> find . -name \*.[ch] -exec sed -i .old -e 's/_uint8_t/_uint8/
> g' {} \;
> find . -name \*.[ch] -exec sed -i .old -e 's/_uint16_t/_uint16/
> g' {} \;
> find . -name \*.[ch] -exec sed -i .old -e 's/_uint32_t/_uint32/
> g' {} \;
> find . -name \*.[ch] -exec sed -i .old -e 's/_uint64_t/_uint64/
> g' {} \;
>
> The first set just do a bulk rename of the types, but it also
> changes
> function names. Since it looks odd to include the _t in a function
> name, the second set changes the pattern used for function names to
> not include the _t.
> >>>
> >>> I hate it. You seriously want to make all of the functions that
> >>> referred to u16 or u32 to now refer to uint16 and uint32??? This
> >>> was
> >>> _exactly_ what I meant when I said a patch would be hard to create.
> >>>
> >>
> >> It wasn't hard to create at all. Eight find and replaces is all it
> >> took. Less than 10 minutes.
> >
> > It was incomplete and would probably raise objections from others.
> >
>
> How was it incomplete? It still compiled and I saw no obvious
> errors. The only contentious portion is the changing of a the
> function names that included uX.
1) Does not update the style guide.
2) Does not include inttypes.h or stdint.h unconditionally.
3) Does not remove those headers from other files
Basically, the rest of the work that I did in the patch that I posted.
Sure, that's all trivial, but they validate the point.
> >>> Also, you do realize that the scope of these changes is _much_ more
> >>> likely to be disruptive to anyone with out-of-tree changes in
> >>> progress?
> >>>
> >>
> >> Yup. It is. Sadly until we decide on all these various conventions,
> >> things are always going to be disruptive to those with out-of-tree
> >> changes. At least in this case, syncing with ToT is relatively
> >> simple. Using minimal change as an argument for is dangerous.
> >> Consider the local minimum effect. To get to a better solution, you
> >> might need to stir things up a bit in the short term. The question
> >> we
> >> need to be asking is "Do we do a big change now, or do we live with a
> >> non-standard type system?"
> >
> > We are talking about 0.2.0. Would you like to perform the risk/reward
> > analysis of my patch versus yours, focusing on the impact they will
> > each
> > have on fixes being developed for the release?
> >
>
> As we already know, the bulk of the work for 0.2.0 is in the tree
> already. In terms of risk/reward, both patches provide low reward for
> low-medium risk. I wouldn't really consider either for 0.2.0 just
> because they don't really impact the users at all. It's just a
> consistency cleanup in the code.
I would not bet on all changes being in the tree. Too presumptuous.
> > A local minimum would be better than no change and much better than
> > your
> > proposed big change. It would better to have and stick to a
> > convention
> > that we can change later, minimizing the cost to everyone today.
> >
>
> Any change increases the cost to anyone developing patches out of
> tree. In the grand scheme of things, neither patch is necessary today
> and neither really reduces the impact on outstanding patches. In
> either case, some set of patch authors will need to do some work to
> update.
>
> > I cleaned up the code to the current convention because it is the
> > right
> > thing to do _today_. Period. Tomorrow is a different story, and you
> > should definitely be aware that I am open to a patch like yours
> > someday.
> > Just not for 0.2.0, okay?
> >
>
> I'm much more a fan of "think first, then do". In this case, rushing
> to enforce consistency doesn't magically make the situation better.
> For 0.2.0, neither patch should be accepted since neither introduces
> any bug fix or user visible benefit. As for tomorrow, we should
> actually figure out what we want to do and then make a patch to do it.
Actually, David Brownell agrees that it does fix bugs regarding
portability of the existing definitions in types.h.
Perhaps your passion for this debate clouded your sight to that fact.
> >>> The two sides have chimed in, patches have been
> >> provided, and a fair number of developers have commented. It's up to
> >> the majority to decide which way to go.
> >
> > Okay, I waited to pull the consensus card, but the m
[Openocd-development] TMS470 Scripts
Does anyone have the device cfg file for TMS470 chips, like TMS470R1A256?
I searched the mailing list archive and it seems that it should work. But I
could not find a cfg file for it. How should I write the cfg file for it?
For the V6 Jlink (my V3 does not seem to work) and the IAR Kickstart board
for TMS470R1A256, the following is the output from Segger's Linux utility.
mc...@ubuntu904:~/Desktop/build/openocd/jlink$ ./start
SEGGER J-Link Commander V4.03a ('?' for help)
Compiled Feb 2 2009 11:34:21
Updating firmware: J-Link ARM V6 compiled Jan 15 2009 11:58:34
Replacing firmware: J-Link ARM V6 compiled Dec 03 2007 17:34:18
Waiting for new firmware to boot
New firmware booted successfully
** Error: Communication timed out after firmware update
DLL version V4.03a, compiled Feb 2 2009 11:34:13
Unable to retrieve firmware info !
S/N : 156007287
OEM : IAR
Feature(s) : RDI, FlashDL, GDBFull, FlashBP, JFlash
VTarget = 3.138V
Info: TotalIRLen = 4, IRPrint = 0x01
WARNING: Identified core does not match configuration. (Found: ARM7,
Configured: None)
Found 1 JTAG device, Total IRLen = 4:
Id of device #0: 0x3100E02F
Found ARM with core Id 0x3100E02F (ARM7)
JTAG speed: 5 kHz
J-Link>?
J-Link>hwinfo
HWInfo[00] = Target power is enabled
HWInfo[02] = 12mA (ITarget)
HWInfo[03] = 19mA (ITargetPeak)
HWInfo[04] = 19mA (ITargetPeakOperation)
HWInfo[10] = 0ms(ITargetMaxTime0)
HWInfo[11] = 0ms(ITargetMaxTime1)
HWInfo[12] = 0ms(ITargetMaxTime2)
J-Link>halt
J-Link>i
JTAG Id: 0x3100E02F Version: 0x3 Part no: 0x100e Man. Id: 0017
J-Link>st
VTarget=3.138V
ITarget=1mA
TCK=1 TDI=0 TDO=0 TMS=0 TRES=1 TRST=1
Supported JTAG speeds:
- 48 MHz/n, (n>=4). => 12000kHz, 9600kHz, 8000kHz, ...
- Adaptive clocking
J-Link>is
JTAG scan length: 4
J-Link>mr
RTCK did not react
J-Link>ms
Syntax: ms
J-Link>ms 1
Length of scan chain [1] = 33
J-Link>ms 0
Length of scan chain [0] = 105
J-Link>ms 2
Length of scan chain [2] = 38
J-Link>ms 3
Length of scan chain [3] = 2
J-Link>ms 4
Length of scan chain [4] = 157
Thanks in advance.
--
Xiaofan http://mcuee.blogspot.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] support avr32
2009/5/25 Michel Catudal : >> Within theses chips and ColdFire, Infineon XE166 does not seem to have gcc >> support. > > Incorrect, I have one, do you need it? I could provide some binaries on > my web site if I have space left. > It is about two years old, I am trying to get the lastest source but am > having some problem with the company who so far > has refused to abide by the GPL. They did provide me with the source a > couple of years ago. > I may look into updating the new sources myself but this is not my top > priority at the moment. > Which version would you need? I have Mandriva 2009.0, Fedora 9, SuSE > 11.1 and Ubuntu 8.10 systems. Source codes and build instructions are the best. If not, Ubuntu will be good since that is my main distro (now 9.04/8.10). I also use Fedora 10. > I do have GCC for Renesas as well. If someone needs it I would need to > recompile it under the new systems. > Last I worked with it was with Fedora 8. I do have the latest source for > Renesas. > Again, Source codes and build instructions are the best. If not, Ubuntu will be good since that is my main distro (now 9.04/8.10). I also use Fedora 10 and Arch Linux (testing purpose only). -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] RFC: uint32_t vrs u32 - et al
On May 25, 2009, at 3:37 PM, Zach Welch wrote:
The opposing patch is attached. As I already mentioned, it is
large,
but the changes were done entirely with the following commands:
find . -name \*.[ch] -exec sed -i .old -e 's/u8/uint8_t/g' {} \;
find . -name \*.[ch] -exec sed -i .old -e 's/u16/uint16_t/g' {} \;
find . -name \*.[ch] -exec sed -i .old -e 's/u32/uint32_t/g' {} \;
find . -name \*.[ch] -exec sed -i .old -e 's/u64/uint64_t/g' {} \;
find . -name \*.[ch] -exec sed -i .old -e 's/_uint8_t/_uint8/
g' {} \;
find . -name \*.[ch] -exec sed -i .old -e 's/_uint16_t/_uint16/
g' {} \;
find . -name \*.[ch] -exec sed -i .old -e 's/_uint32_t/_uint32/
g' {} \;
find . -name \*.[ch] -exec sed -i .old -e 's/_uint64_t/_uint64/
g' {} \;
The first set just do a bulk rename of the types, but it also
changes
function names. Since it looks odd to include the _t in a function
name, the second set changes the pattern used for function names to
not include the _t.
I hate it. You seriously want to make all of the functions that
referred to u16 or u32 to now refer to uint16 and uint32??? This
was
_exactly_ what I meant when I said a patch would be hard to create.
It wasn't hard to create at all. Eight find and replaces is all it
took. Less than 10 minutes.
It was incomplete and would probably raise objections from others.
How was it incomplete? It still compiled and I saw no obvious
errors. The only contentious portion is the changing of a the
function names that included uX.
Also, you do realize that the scope of these changes is _much_ more
likely to be disruptive to anyone with out-of-tree changes in
progress?
Yup. It is. Sadly until we decide on all these various conventions,
things are always going to be disruptive to those with out-of-tree
changes. At least in this case, syncing with ToT is relatively
simple. Using minimal change as an argument for is dangerous.
Consider the local minimum effect. To get to a better solution, you
might need to stir things up a bit in the short term. The question
we
need to be asking is "Do we do a big change now, or do we live with a
non-standard type system?"
We are talking about 0.2.0. Would you like to perform the risk/reward
analysis of my patch versus yours, focusing on the impact they will
each
have on fixes being developed for the release?
As we already know, the bulk of the work for 0.2.0 is in the tree
already. In terms of risk/reward, both patches provide low reward for
low-medium risk. I wouldn't really consider either for 0.2.0 just
because they don't really impact the users at all. It's just a
consistency cleanup in the code.
A local minimum would be better than no change and much better than
your
proposed big change. It would better to have and stick to a
convention
that we can change later, minimizing the cost to everyone today.
Any change increases the cost to anyone developing patches out of
tree. In the grand scheme of things, neither patch is necessary today
and neither really reduces the impact on outstanding patches. In
either case, some set of patch authors will need to do some work to
update.
I cleaned up the code to the current convention because it is the
right
thing to do _today_. Period. Tomorrow is a different story, and you
should definitely be aware that I am open to a patch like yours
someday.
Just not for 0.2.0, okay?
I'm much more a fan of "think first, then do". In this case, rushing
to enforce consistency doesn't magically make the situation better.
For 0.2.0, neither patch should be accepted since neither introduces
any bug fix or user visible benefit. As for tomorrow, we should
actually figure out what we want to do and then make a patch to do it.
The two sides have chimed in, patches have been
provided, and a fair number of developers have commented. It's up to
the majority to decide which way to go.
Okay, I waited to pull the consensus card, but the majority of others
have already expressed their opinion that the shorthand status quo
would
be acceptable (if not preferred). I think even Duane is okay with it.
While you thus represent the minority, I have entertained this
argument
because your earlier point was essentially correct: both of our
proposed
standards are perfectly valid conventions in their own right.
Yup and having a discussion on the merits of each is good and healthy.
If anything, my frustration derives from the fact that -- as a
maintainer yourself -- you should have been looking at the consensus
that was already being expressed by the community and let it drop
sooner
than this (nevermind 0.2.0 considerations). As a project leader, I
see
these kinds of debates as detrimental to being effective in a
community,
as it appears the individuals are unable resolve their points in an
efficient and effective manner.
There is _no_ harm is having a discussion on alternatives. It doesn't
make us
Re: [Openocd-development] [patch] reset configuration doc updates
On Monday 25 May 2009, David Brownell wrote:
> - Bugfix the "reset_config" description (it didn't match the code)
To recap, current code says the syntax is:
reset_config signals [combination [trst_type [srst_type]]]
PROPOSAL 1: make it so any of those magic keywords can be provided,
in any order. Example, "trst_and_srst" after "srst_open_drain",
omitting the "separate" combination (which should be the default
in any case).
Why? (a) Makes it easier to override things at the
right level (adapter, board, target). You can just
specify the thing you *know* instead of having to
somehow "know" things earlier in that sequence.
(b) Removing needless error paths is always good;
that sequencing shouldn't matter.
PROPOSAL 2: Add "srst_disable" and "trst_disable", which would
be "sticky" and used to infer the "signals".
Why? Any of {target, board, adapter} could filter
out one of those signals. This makes it easy for
them to declare they've done so, and impossible
for some other component to lie and say the signal
magically re-appeared.
PROPOSAL 3: Make "reset_config" be available only during the
server configuration stage.
Why? Looks to me like there's no valid reason to
change these after server startup. Same may be
true of the [st]rst_delay parameters. Once the
working setup is established, it should stay forever.
___
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
On Mon, 2009-05-25 at 15:02 -0700, Rick Altherr wrote:
> On May 25, 2009, at 2:50 PM, Zach Welch wrote:
>
> > On Mon, 2009-05-25 at 14:38 -0700, Rick Altherr wrote:
> >> On May 25, 2009, at 2:24 PM, Zach Welch wrote:
> >>
> > Further, you can argue with the following assertions -- only if
> > you
> > can
> > show me a patch that proves them wrong:
> >
> >>>
> >>> Show me your patch, or let me commit mine. This debate is silly.
> >>>
> >>> Cheers,
> >>>
> >>> Zach
> >>
> >>
> >> It's interesting that every time a discussion about preferences comes
> >> up, it typically ends with "Here's my patch. This is silly. My
> >> patch
> >> already works, let's just commit it." It's not like discussion is
> >> painful or this issue is causing problems for anyone. We're better
> >> off coming up with an answer that everyone is OK with rather than
> >> just
> >> defaulting to whatever patch shows up first.
> >
> > Actually, these kinds of issues are very frustrating to me personally,
> > because they always end up being counterproductive. This is why I am
> > maintaining the Style Guide. I desperately want to hereafter resolve
> > this debate by shouting "RTFM and STFU"; anything else is time wasted.
> > The burden of proof lies on the person that lacks a patch in-hand.
> >
> > Until these matters are fully resolved, the discussion does cause a
> > problem because it prevents us from moving forward with genuinely
> > productive work on the system.
> >
>
> It isn't counterproductive the first time the discussion happens.
> It's counterproductive when someone wants to go against the
> established convention. The burden is always on the person who is
> arguing for something different that the convention. In this case,
> it's both of us.
True. However, I have been thinking about the bigger context: 0.2.0.
> >> The opposing patch is attached. As I already mentioned, it is large,
> >> but the changes were done entirely with the following commands:
> >>
> >> find . -name \*.[ch] -exec sed -i .old -e 's/u8/uint8_t/g' {} \;
> >> find . -name \*.[ch] -exec sed -i .old -e 's/u16/uint16_t/g' {} \;
> >> find . -name \*.[ch] -exec sed -i .old -e 's/u32/uint32_t/g' {} \;
> >> find . -name \*.[ch] -exec sed -i .old -e 's/u64/uint64_t/g' {} \;
> >>
> >> find . -name \*.[ch] -exec sed -i .old -e 's/_uint8_t/_uint8/g' {} \;
> >> find . -name \*.[ch] -exec sed -i .old -e 's/_uint16_t/_uint16/
> >> g' {} \;
> >> find . -name \*.[ch] -exec sed -i .old -e 's/_uint32_t/_uint32/
> >> g' {} \;
> >> find . -name \*.[ch] -exec sed -i .old -e 's/_uint64_t/_uint64/
> >> g' {} \;
> >>
> >> The first set just do a bulk rename of the types, but it also changes
> >> function names. Since it looks odd to include the _t in a function
> >> name, the second set changes the pattern used for function names to
> >> not include the _t.
> >
> > I hate it. You seriously want to make all of the functions that
> > referred to u16 or u32 to now refer to uint16 and uint32??? This was
> > _exactly_ what I meant when I said a patch would be hard to create.
> >
>
> It wasn't hard to create at all. Eight find and replaces is all it
> took. Less than 10 minutes.
It was incomplete and would probably raise objections from others.
> > Also, you do realize that the scope of these changes is _much_ more
> > likely to be disruptive to anyone with out-of-tree changes in
> > progress?
> >
>
> Yup. It is. Sadly until we decide on all these various conventions,
> things are always going to be disruptive to those with out-of-tree
> changes. At least in this case, syncing with ToT is relatively
> simple. Using minimal change as an argument for is dangerous.
> Consider the local minimum effect. To get to a better solution, you
> might need to stir things up a bit in the short term. The question we
> need to be asking is "Do we do a big change now, or do we live with a
> non-standard type system?"
We are talking about 0.2.0. Would you like to perform the risk/reward
analysis of my patch versus yours, focusing on the impact they will each
have on fixes being developed for the release?
A local minimum would be better than no change and much better than your
proposed big change. It would better to have and stick to a convention
that we can change later, minimizing the cost to everyone today.
I cleaned up the code to the current convention because it is the right
thing to do _today_. Period. Tomorrow is a different story, and you
should definitely be aware that I am open to a patch like yours someday.
Just not for 0.2.0, okay?
> > Are you insane or merely sadistic? :)
> >
>
> Neither and the smiley doesn't really help your case either. You're
> taking this _way_ too personal for something that is a relatively
> mundane discussion.
The smiley meant to frame the rhetorical question as humorous. Clearly,
this was not the time or place for that, so I must wonder if I am not
alone in fitting
[Openocd-development] [patch] reset configuration doc updates
Update the "Reset Configuration" information in the User's guide:
- Convert to @deffn syntax
- Move tutorial text from command descriptions into new sections
- Describe several different types of JTAG-visible reset
- Expand descriptions of configuration tweaks for SRST and TRST
- Link to the "reset" command, and vice versa
- Bugfix the "reset_config" description (it didn't match the code)
Plus, be more proscriptive: do it in board config files, except for
the oddball cases where that won't work. (Current target.cfg files
seem to have much goofage there; several seem board-specific.)
---
doc/openocd.texi | 176 -
1 file changed, 121 insertions(+), 55 deletions(-)
Update the "Reset Configuration" information in the User's guide:
- Convert to @deffn syntax
- Move tutorial text from command descriptions into new sections
- Describe several different types of JTAG-visible reset
- Expand descriptions of configuration tweaks for SRST and TRST
- Link to the "reset" command, and vice versa
- Bugfix the "reset_config" description (it didn't match the code)
Plus, be more proscriptive: do it in board config files, except for
the oddball cases where that won't work. (Current target.cfg files
seem to have much goofage there; several seem board-specific.)
---
doc/openocd.texi | 176 -
1 file changed, 121 insertions(+), 55 deletions(-)
--- a/doc/openocd.texi
+++ b/doc/openocd.texi
@@ -1551,67 +1551,133 @@ jtag_rclk 3000
@cindex Reset Configuration
Every system configuration may require a different reset
-configuration. This can also be quite confusing. Please see the
-various board files for example.
+configuration. This can also be quite confusing.
+Please see the various board files for examples.
-...@section jtag_nsrst_delay <@var{ms}>
-...@cindex jtag_nsrst_delay
-...@*how long (in milliseconds) OpenOCD should wait after deasserting
-nSRST before starting new JTAG operations.
+...@b{note} to maintainers and integrators:
+Reset configuration touches several things at once.
+Normally the board configuration file
+should define it and assume that the JTAG adapter supports
+everything that's wired up to the board's JTAG connector.
+However, the target configuration file could also make note
+of something the silicon vendor has done inside the chip,
+which will be true for most (or all) boards using that chip.
+And when the JTAG adapter doesn't support everything, the
+system configuration file will need to override parts of
+the reset configuration provided by other files.
-...@section jtag_ntrst_delay <@var{ms}>
-...@cindex jtag_ntrst_delay
-...@*same @b{jtag_nsrst_delay}, but for nTRST
+...@section Types of Reset
-The jtag_n[st]rst_delay options are useful if reset circuitry (like a
-big resistor/capacitor, reset supervisor, or on-chip features). This
-keeps the signal asserted for some time after the external reset got
-deasserted.
+There are many kinds of reset possible through JTAG, but
+they may not all work with a given board and adapter.
+That's part of why reset configuration can be error prone.
-...@section reset_config
+...@itemize @bullet
+...@item
+...@emph{system Reset} ... the @emph{SRST} hardware signal
+resets all chips connected to the JTAG adapter, such as processors,
+power management chips, and I/O controllers. Normally resets triggered
+with this signal behave exactly like pressing a RESET button.
+...@item
+...@emph{jtag TAP Reset} ... the @emph{TRST} hardware signal resets
+just the TAP controllers connected to the JTAG adapter.
+Such resets should not be visible to the rest of the system; resetting a
+device's the TAP controller just puts that controller into a known state.
+...@item
+...@emph{emulation Reset} ... many devices can be reset through JTAG
+commands. These resets are often distinguishable from system
+resets, either explicitly (a "reset reason" register says so)
+or implicitly (not all parts of the chip get reset).
+...@item
+...@emph{other Resets} ... system-on-chip devices often support
+several other types of reset.
+You may need to arrange that a watchdog timer stops
+while debugging, preventing a watchdog reset.
+There may be individual module resets.
+...@end itemize
-...@b{note:} To maintainers and integrators: Where exactly the
-``reset configuration'' goes is a good question. It touches several
-things at once. In the end, if you have a board file - the board file
-should define it and assume 100% that the DONGLE supports
-anything. However, that does not mean the target should not also make
-not of something the silicon vendor has done inside the
-chip. @i{Grr nothing is every pretty.}
+In the best case, OpenOCD can hold SRST, then reset
+the TAPs via TRST and send commands through JTAG to halt the
+CPU at the reset vector before the 1st instruction is executed.
+Then when it finally releases the SRST signal, the system is
+h
[Openocd-development] openocd & boundary scan
Hello, I would like to do a boundary scan on a imx27 part. I've looked through the documentation and mailing list and I don't see much on this. The most helpful thing has been a very short wikipedia entry on the SVF format ( http://en.wikipedia.org/wiki/Serial_Vector_Format). I do see the svf command from the telnet interface. Is svf working? Does anyone have example files? So I take it that svf is using the irscan & drscan functions? What are irscan & drscan doing? When I do scan_chain I get both imx27.bs and imx27.cpu which looks normal. What I actually want to do with the boundary scan is check that none of the data/address lines to the ram are shorted. I would love to write up a tutorial on using openocd as a boundray scan tool if I get this working. thanks, Paul ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] A real question about tap states
To move the discussion onto something that miqht require a bit o f real analysis: Why does some targets work better during "reset halt" when the TAP_RESET-> IR_SHIFT is B8(0011000,7) instead of B8(0011011,7) . And the hard question: why does the first variant work for the ft2232 driver when the JLink driver needs the second, for the same target. I have recently tried so many variants that my head is spinning. Have a nice evening Magnus ___ 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
On Monday 25 May 2009, Rick Altherr wrote: > >>> Show me your patch, or let me commit mine. This debate is silly. My two cents: Commit Zach's patch, since it ends up resolving potential bugs with e.g. "u32" != "uint32_t". Then put the debate off to the side for a while. Arguing like that is counterproductive. If, on some future day, an agreemnt to use one vs the other arrives, then patches can be merged that actually change coding conventions. ___ 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
On May 25, 2009, at 2:50 PM, Zach Welch wrote:
On Mon, 2009-05-25 at 14:38 -0700, Rick Altherr wrote:
On May 25, 2009, at 2:24 PM, Zach Welch wrote:
Further, you can argue with the following assertions -- only if
you
can
show me a patch that proves them wrong:
Show me your patch, or let me commit mine. This debate is silly.
Cheers,
Zach
It's interesting that every time a discussion about preferences comes
up, it typically ends with "Here's my patch. This is silly. My
patch
already works, let's just commit it." It's not like discussion is
painful or this issue is causing problems for anyone. We're better
off coming up with an answer that everyone is OK with rather than
just
defaulting to whatever patch shows up first.
Actually, these kinds of issues are very frustrating to me personally,
because they always end up being counterproductive. This is why I am
maintaining the Style Guide. I desperately want to hereafter resolve
this debate by shouting "RTFM and STFU"; anything else is time wasted.
The burden of proof lies on the person that lacks a patch in-hand.
Until these matters are fully resolved, the discussion does cause a
problem because it prevents us from moving forward with genuinely
productive work on the system.
It isn't counterproductive the first time the discussion happens.
It's counterproductive when someone wants to go against the
established convention. The burden is always on the person who is
arguing for something different that the convention. In this case,
it's both of us.
The opposing patch is attached. As I already mentioned, it is large,
but the changes were done entirely with the following commands:
find . -name \*.[ch] -exec sed -i .old -e 's/u8/uint8_t/g' {} \;
find . -name \*.[ch] -exec sed -i .old -e 's/u16/uint16_t/g' {} \;
find . -name \*.[ch] -exec sed -i .old -e 's/u32/uint32_t/g' {} \;
find . -name \*.[ch] -exec sed -i .old -e 's/u64/uint64_t/g' {} \;
find . -name \*.[ch] -exec sed -i .old -e 's/_uint8_t/_uint8/g' {} \;
find . -name \*.[ch] -exec sed -i .old -e 's/_uint16_t/_uint16/
g' {} \;
find . -name \*.[ch] -exec sed -i .old -e 's/_uint32_t/_uint32/
g' {} \;
find . -name \*.[ch] -exec sed -i .old -e 's/_uint64_t/_uint64/
g' {} \;
The first set just do a bulk rename of the types, but it also changes
function names. Since it looks odd to include the _t in a function
name, the second set changes the pattern used for function names to
not include the _t.
I hate it. You seriously want to make all of the functions that
referred to u16 or u32 to now refer to uint16 and uint32??? This was
_exactly_ what I meant when I said a patch would be hard to create.
It wasn't hard to create at all. Eight find and replaces is all it
took. Less than 10 minutes.
Also, you do realize that the scope of these changes is _much_ more
likely to be disruptive to anyone with out-of-tree changes in
progress?
Yup. It is. Sadly until we decide on all these various conventions,
things are always going to be disruptive to those with out-of-tree
changes. At least in this case, syncing with ToT is relatively
simple. Using minimal change as an argument for is dangerous.
Consider the local minimum effect. To get to a better solution, you
might need to stir things up a bit in the short term. The question we
need to be asking is "Do we do a big change now, or do we live with a
non-standard type system?"
Are you insane or merely sadistic? :)
Neither and the smiley doesn't really help your case either. You're
taking this _way_ too personal for something that is a relatively
mundane discussion. The two sides have chimed in, patches have been
provided, and a fair number of developers have commented. It's up to
the majority to decide which way to go.
Cheers,
Zach
--
Rick Altherr
kc8...@kc8apf.net
"He said he hadn't had a byte in three days. I had a short, so I split
it with him."
-- Unsigned
smime.p7s
Description: S/MIME cryptographic signature
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] RFC: uint32_t vrs u32 - et al
On Mon, 2009-05-25 at 14:38 -0700, Rick Altherr wrote:
> On May 25, 2009, at 2:24 PM, Zach Welch wrote:
>
> >>> Further, you can argue with the following assertions -- only if you
> >>> can
> >>> show me a patch that proves them wrong:
> >>>
> >
> > Show me your patch, or let me commit mine. This debate is silly.
> >
> > Cheers,
> >
> > Zach
>
>
> It's interesting that every time a discussion about preferences comes
> up, it typically ends with "Here's my patch. This is silly. My patch
> already works, let's just commit it." It's not like discussion is
> painful or this issue is causing problems for anyone. We're better
> off coming up with an answer that everyone is OK with rather than just
> defaulting to whatever patch shows up first.
Actually, these kinds of issues are very frustrating to me personally,
because they always end up being counterproductive. This is why I am
maintaining the Style Guide. I desperately want to hereafter resolve
this debate by shouting "RTFM and STFU"; anything else is time wasted.
The burden of proof lies on the person that lacks a patch in-hand.
Until these matters are fully resolved, the discussion does cause a
problem because it prevents us from moving forward with genuinely
productive work on the system.
> The opposing patch is attached. As I already mentioned, it is large,
> but the changes were done entirely with the following commands:
>
> find . -name \*.[ch] -exec sed -i .old -e 's/u8/uint8_t/g' {} \;
> find . -name \*.[ch] -exec sed -i .old -e 's/u16/uint16_t/g' {} \;
> find . -name \*.[ch] -exec sed -i .old -e 's/u32/uint32_t/g' {} \;
> find . -name \*.[ch] -exec sed -i .old -e 's/u64/uint64_t/g' {} \;
>
> find . -name \*.[ch] -exec sed -i .old -e 's/_uint8_t/_uint8/g' {} \;
> find . -name \*.[ch] -exec sed -i .old -e 's/_uint16_t/_uint16/g' {} \;
> find . -name \*.[ch] -exec sed -i .old -e 's/_uint32_t/_uint32/g' {} \;
> find . -name \*.[ch] -exec sed -i .old -e 's/_uint64_t/_uint64/g' {} \;
>
> The first set just do a bulk rename of the types, but it also changes
> function names. Since it looks odd to include the _t in a function
> name, the second set changes the pattern used for function names to
> not include the _t.
I hate it. You seriously want to make all of the functions that
referred to u16 or u32 to now refer to uint16 and uint32??? This was
_exactly_ what I meant when I said a patch would be hard to create.
Also, you do realize that the scope of these changes is _much_ more
likely to be disruptive to anyone with out-of-tree changes in progress?
Are you insane or merely sadistic? :)
Cheers,
Zach
___
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
On Mon, 2009-05-25 at 14:01 -0700, Rick Altherr wrote: > On May 25, 2009, at 1:52 PM, Zach Welch wrote: > > > On Mon, 2009-05-25 at 13:10 -0700, Rick Altherr wrote: > > [snip] > > > >>> Sorry Rick, but I think that you and Duane have lost this argument. > >>> You have failed to defend your position with facts. > >> > >> I could say the same of everyone else. Considering the entire issue > >> is rooted in preference, there are no hard facts to be presented. > > > > Okay, apparently I need to spell them out for you. > > > > Here are the facts: > > > > 1) They are shorter: 3 < 7 and 3 < 8. > > Agreed, but that doesn't make them better for usage. Naming every > variable in a function with a single letter is shorter too. > > > 2) most of the OpenOCD code uses the short types > > - it was developed before the C99 types could be relied upon > > - "grandfathering" these types says nothing about the rest of > > OpenOCD > > I know _why_ they are there. Keeping them by "grandfathering" does > set a precedent or at least makes the rest of the type conventions > odd. Imagine how you would document this in the developer manual: > "All types are of the form x_t where x is a descriptive name in lower- > case with words joined by underscores. The name should encapsulate > the subsystem the type is related to and what it represents. NOTE: > The types for defined-width integers are an exception to these rules." Nothing is perfect, particular not policies. > > 3) the patch to unify the changes to short types is minor and > > finished: > > - it uses the C99 types fully, so we get all of their benefits > > - it will fix portability problems on some 64-bit architectures > > - it leaves the code more correct than it was before the patch > > > > Agreed. Of course, that doesn't mean that it is the only option or > even the option we want to go with. A similar patch can provide all > of those same benefits by using the C99 types directly but doesn't > have the "is minor and already finished" part. > > > Further, you can argue with the following assertions -- only if you > > can > > show me a patch that proves them wrong: > > Show me your patch, or let me commit mine. This debate is silly. Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] On Resets
On Monday 25 May 2009, Michael Bruck wrote: > My suggestion would be to expose the resets as a generic GPIO layer > that is available to scripts. That might be generally useful. Example, Texas Instruments routinely bundles EMU0 and EMU1 signals with their JTAG adapters. Near as I can tell, they serve both as inputs and as outputs to various systems. I've seen docs that reference their use as system outputs ... as event triggers like "trace buffer is full now" as well as for other interactions. Others seem to reference them as system inputs. I think the use of those signals is a bit on the chip-specific side of things. That said, I still think that having a way for boards or JTAG adapters to say "I don't pass ", like TRST or SRST, could be good. The "reset_config trst_only" type of behavior could be inferred ... instead of needing to get overridden in "openocd.cfg" based on adapter+board combo. - Dave ___ 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
On May 25, 2009, at 1:52 PM, Zach Welch wrote: On Mon, 2009-05-25 at 13:10 -0700, Rick Altherr wrote: [snip] Sorry Rick, but I think that you and Duane have lost this argument. You have failed to defend your position with facts. I could say the same of everyone else. Considering the entire issue is rooted in preference, there are no hard facts to be presented. Okay, apparently I need to spell them out for you. Here are the facts: 1) They are shorter: 3 < 7 and 3 < 8. Agreed, but that doesn't make them better for usage. Naming every variable in a function with a single letter is shorter too. 2) most of the OpenOCD code uses the short types - it was developed before the C99 types could be relied upon - "grandfathering" these types says nothing about the rest of OpenOCD I know _why_ they are there. Keeping them by "grandfathering" does set a precedent or at least makes the rest of the type conventions odd. Imagine how you would document this in the developer manual: "All types are of the form x_t where x is a descriptive name in lower- case with words joined by underscores. The name should encapsulate the subsystem the type is related to and what it represents. NOTE: The types for defined-width integers are an exception to these rules." 3) the patch to unify the changes to short types is minor and finished: - it uses the C99 types fully, so we get all of their benefits - it will fix portability problems on some 64-bit architectures - it leaves the code more correct than it was before the patch Agreed. Of course, that doesn't mean that it is the only option or even the option we want to go with. A similar patch can provide all of those same benefits by using the C99 types directly but doesn't have the "is minor and already finished" part. Further, you can argue with the following assertions -- only if you can show me a patch that proves them wrong: A patch to use C99 types would be: - difficult to create in the first place, Entirely sed-able. - bigger than the community would be able or willing to review, and These usually fall into the "large but mechanical" bucket and are easy to review. - a major source functional regressions. Assuming that u32 is a typedef for uint32_t, then there is no possibility of a functional regression. If u32 _isn't_ a typedef for uint32_t, then moving the short types to be based on the C99 types has just as much likelihood for functional regressions. Cheers, Zach -- Rick Altherr kc8...@kc8apf.net "He said he hadn't had a byte in three days. I had a short, so I split it with him." -- Unsigned smime.p7s Description: S/MIME cryptographic signature ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] RFC: uint32_t vrs u32 - et al
On Monday 25 May 2009, Duane Ellis wrote:
> David's statement: "they look and smell long, like an elephant" - while
> funny, I agree with him 100%, that view has no technical component.
;)
I'd say that "easier to type" is technical. It might not be
compelling, but ... the whole reason there are style guides is
because such issues are rarely compelling.
if (...) {
...
} else {
...
}
versus
if (...)
{
...
}
else
{
...
}
isn't a technical discussion either. "K&R style" is nonetheless
the longest-established C programming style.
- Dave
___
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
On Mon, 2009-05-25 at 16:21 -0400, Duane Ellis wrote: > 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 "uint_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. My full version of the patch uses the C99 types in the least disruptive way possible to the tree, but they _are_ used. My changes are the best technical improvements to make, short of potentially systemic patching to use the C99 types throughout the tree (that idea scares me to death). --Z ___ 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
On Mon, 2009-05-25 at 13:10 -0700, Rick Altherr wrote: [snip] > > Sorry Rick, but I think that you and Duane have lost this argument. > > You have failed to defend your position with facts. > > I could say the same of everyone else. Considering the entire issue > is rooted in preference, there are no hard facts to be presented. Okay, apparently I need to spell them out for you. Here are the facts: 1) They are shorter: 3 < 7 and 3 < 8. 2) most of the OpenOCD code uses the short types - it was developed before the C99 types could be relied upon - "grandfathering" these types says nothing about the rest of OpenOCD 3) the patch to unify the changes to short types is minor and finished: - it uses the C99 types fully, so we get all of their benefits - it will fix portability problems on some 64-bit architectures - it leaves the code more correct than it was before the patch Further, you can argue with the following assertions -- only if you can show me a patch that proves them wrong: A patch to use C99 types would be: - difficult to create in the first place, - bigger than the community would be able or willing to review, and - a major source functional regressions. Cheers, Zach ___ 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
Rick Altherr wrote: > > New developers to the project. Not all advanced coders _prefer_ > shorter names just to save on typing. I'm not suggesting we > "dumb-down" anything. Using cryptic short names to save on typing is > an elitist attitude that makes the barrier to entry for new developers > higher and makes the time to come up to speed on a portion of the > codebase longer. Code should be clear and concise. If a longer > function name describes the effect of the function better, then it > should be the longer name. That doesn't mean that every function > should have a long name. Same for types. If a longer or additional > type name would clarify the code, then it should be used. u32 doesn't > clarify anything. It just replaces the familiar type defined by a > well-known standard with something 5 characters shorter. Ack from me. If I see uint32_t, I know immediately what it is, and that it comes from a system header and has a well-defined meaning. Wrappig that in a project header to provide u32 means I have to look up where it is defined. > I could say the same of everyone else. Considering the entire issue > is rooted in preference, there are no hard facts to be presented. > Some prefer to have shorter names, some prefer to have more > descriptive names. Either option is workable, but in my experience > with introducing developers to projects, more descriptive names and > types lower the barrier to entry and reduce the amount of guidance the > current developers need to provide. IMHO, it's not so much length - I prefer short names as long as they are descriptive, but if there is a defined standard, I prefer to use that (the the Linux way is "uint32_t" - there is more code for userspace, which uses that, than there is kernel code, and more programmers will be familiar with the userspace definitions, which also match C99 and are not Linux-specific). cu Michael ___ 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
On May 25, 2009, at 1:21 PM, Duane Ellis wrote: zach> Sorry Rick, but I think that you and Duane have lost this argument. You have failed to defend your position with facts. 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 "uint_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. Actually, this does exist. As part of C99, not only are the types like uin32_t defined but there is a corresponding macro PRIu32 that is the format code for printing a uint32_t. These exist for all the C99- defined integer types (int8_t, uint8_t, int16_t, etc). See inttypes.h. -- Rick Altherr kc8...@kc8apf.net "He said he hadn't had a byte in three days. I had a short, so I split it with him." -- Unsigned smime.p7s Description: S/MIME cryptographic signature ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] RFC: uint32_t vrs u32 - et al
Rick Altherr a écrit : > Perhaps I'm jaded from writing code for OS X where function names are > intended to be descriptive and thus end up long. Most editors include > autocompletion which makes the difference minimal in practice. Even > when I'm writing code in vi, I prefer the longer type names since it > make it clear that a) it's a type by having the _t suffix and b) > that's an unsigned int. With u32, there are plenty of cases where odd > naming collisions can occur. It's also not clear that its an integer, > but just an unsigned 32-bit something. To be entirely honest, I > prefer seeing long, descriptive function prototypes like: > I hate the autocompletion in my editor because I think it's crap. (slickedit) I consider it some kind of trojan which makes stupid decisions which I most of the time disagree with. I can understand some logic in having some descriptive value if someone is too lazy to write comments but it is usually not necessary if intelligent comments are used. I find it more usefull to spend some time describing the functions. Where I work we have coding rules but it doesn't involve descriptive names so much as identifying what type it is and which module it belongs to. iApp_iData1 lApp_iData1 llApp_iData1 ucApp_iData1 uiApp_iData1 ulApp_iData1 ullApp_iData1 vApp_iData1 Without telling you specifically the type you can identify easily if rules are obeyed. For convenience and clarity I combine the two ideas of having descriptive names as well as comments. Descriptive names is not so important for us as which module it is part of. As to the "unsigned int" type I have a preference with u16 because it is what ST uses in their libraries and it simplier and quicker to type. I find no special purpose or improvement to use the long version for that. With NEC it is U16 so I will need to override that in my system.h for my project files. I find the whole discussion silly and the proposed change ridiculous. Michel -- Tired of Microsoft's rebootive multitasking? then it's time to upgrade to Linux. http://home.comcast.net/~mcatudal ___ 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 "uint_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] RFC: uint32_t vrs u32 - et al
On May 25, 2009, at 12:28 PM, Zach Welch wrote: 1) It's shorter/faster to type. This argument has been hashed out extensively on the Linux mailing lists. Linus has it right in this debate to prefer s32/u32. POSIX is dumb; however, that doesn't mean we can't exploit their work for own purposes. Perhaps I'm jaded from writing code for OS X where function names are intended to be descriptive and thus end up long. Most editors include autocompletion which makes the difference minimal in practice. Even when I'm writing code in vi, I prefer the longer type names since it make it clear that a) it's a type by having the _t suffix and b) that's an unsigned int. With u32, there are plenty of cases where odd naming collisions can occur. It's also not clear that its an integer, but just an unsigned 32-bit something. To be entirely honest, I prefer seeing long, descriptive function prototypes like: status_t TriggerSetThreadStateFilter(trigger_t trigger, const thread_state_t * stateMasks, uint32_t numberOfStateMasks, error_t * error); I pulled this particular example from another project I'm working on, but it should illustrate the point. You can understand what most of the parameters are and have a decent idea of what the function does. The compiler doesn't care about names, so we should optimize them for the people. Which people? People that need to have their hands held with long fluffy names? Or for advanced coders that they can handle (and prefer) the shorter conventions? We should not dumb-down the OpenOCD code, and that is _exactly_ what you are describing. New developers to the project. Not all advanced coders _prefer_ shorter names just to save on typing. I'm not suggesting we "dumb- down" anything. Using cryptic short names to save on typing is an elitist attitude that makes the barrier to entry for new developers higher and makes the time to come up to speed on a portion of the codebase longer. Code should be clear and concise. If a longer function name describes the effect of the function better, then it should be the longer name. That doesn't mean that every function should have a long name. Same for types. If a longer or additional type name would clarify the code, then it should be used. u32 doesn't clarify anything. It just replaces the familiar type defined by a well-known standard with something 5 characters shorter. 2) More importantly, this patch applies the principle of least change. These changes both unify the type system around the types that are defined in "types.h" (and with the Linux kernel). Thus, we achieve conformance to an internal (and external) standard that we can enforce from here on. With less typing (this goes both for the types themselves and for the changes necessary to convert the entire tree to use the types that are used in only a handful of files today). Given that the state of the code is a hodgepodge of various naming conventions, I don't see it being a good source for "it was mostly that way already". I'd rather we chose a sensible convention based on merits and apply it wholesale rather than just letting majority rule. Clearly you have not looked at the code with regard to this issue. The code is NOT a "hodgepodge" when it comes to these types. I was referring to the grander concerns for following the "it was mostly that way already" philosophy. The use of types is probably the _only_ mostly consistent item in the whole source tree. I would hate to see the use of that philosophy here as justification for doing so in other cases. Having the types align with the Linux kernel is of effectively no importance. I happen to do all my development on OS X which follows the C99 naming standards for anything in the BSD layer. Familiarity in this case doesn't hold across the gamut of our developer base. How about familiarity with the OpenOCD code, which uses these types? How about the fact that 99% of the OpenOCD code already uses them? See above. It's more of a concern about the slippery slope on using that justification. Since you brought it up, however, there are ~10 people who are familiar with the OpenOCD code base. Any given new developer has a good chance of being unfamiliar with these types since they are far from a standard convention. Now, for u32 specifically, I don't think the jump is too hard, but if we go down this path of choosing type names that are optimized for typing, it can easily get out of hand and confusing. Just consider the short form of intmax_t following the convention proposed: smax. Tell me that that has a low chance of being confusing or hitting conflicts. Do we also shorten the type names for things like struct jtag_tap_s? Does it become 'j', 'jtag', 'tap', ...? Sorry Rick, but I think that you and Duane have lost this argument. You have failed to defend your position with facts. I could say the same of every
Re: [Openocd-development] RFC: uint32_t vrs u32 - et al
On May 25, 2009, at 17:41, Nicolas Pitre wrote: > As far as my opinion matters, I don't think that uint32_t is that much > clearer than u32. It is however what the language standard specifies, and provided by the compiler. Complaints that the C99 type definitions are so much more difficult to type are just utterly bogus. > And Linux makes for a big example where plenty of odd naming > collisions is simply not an issue in practice When the Linux kernel was started, the very idea of having a language standard was a novel concept. Regards, Anders Montonen ___ 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
On Sun, 2009-05-24 at 22:43 -0700, Rick Altherr wrote: > On May 24, 2009, at 9:37 PM, Zach Welch wrote: > > > On Sun, 2009-05-24 at 21:19 -0700, Rick Altherr wrote: > >> =On May 24, 2009, at 9:04 PM, Zach Welch wrote: > >> > >>> On Sun, 2009-05-24 at 20:51 -0700, David Brownell wrote: > On Sunday 24 May 2009, Zach Welch wrote: > > - add iN equivalents to intN_t types; i32 is used by > > replacements.h > > The traditional sibling of a "u32" (unsigned) is an "s32" (signed). > > I don't know where "i32" came from, it's an interloper. > >>> > >>> That would be me, taking a blind stab in the dark. Mea culpa. > >>> > >>> Fixed: new patch attached for consideration. I have also fixed the > >>> duplicated section heading in the documentation. Anything else? > >>> > >>> Cheers, > >>> > >>> Zach > >>> > >>> > >> > >> > >> Maybe I misunderstood. I thought we were deprecating the use of > >> "u32" > >> in favor of the C99-defined "uint32_t". Why would we define another > >> set of types when there a perfectly fine versions already available > >> as > >> part of the language standard? > > > > Heh. I just went back and re-read the original post and realized my > > mistake; however, I will defend my changes with two principles: > > > > 1) It's shorter/faster to type. This argument has been hashed out > > extensively on the Linux mailing lists. Linus has it right in this > > debate to prefer s32/u32. POSIX is dumb; however, that doesn't mean > > we > > can't exploit their work for own purposes. > > > > Perhaps I'm jaded from writing code for OS X where function names are > intended to be descriptive and thus end up long. Most editors include > autocompletion which makes the difference minimal in practice. Even > when I'm writing code in vi, I prefer the longer type names since it > make it clear that a) it's a type by having the _t suffix and b) > that's an unsigned int. With u32, there are plenty of cases where odd > naming collisions can occur. It's also not clear that its an integer, > but just an unsigned 32-bit something. To be entirely honest, I > prefer seeing long, descriptive function prototypes like: > > status_t TriggerSetThreadStateFilter(trigger_t trigger, const > thread_state_t * stateMasks, uint32_t numberOfStateMasks, error_t * > error); > > I pulled this particular example from another project I'm working on, > but it should illustrate the point. You can understand what most of > the parameters are and have a decent idea of what the function does. > The compiler doesn't care about names, so we should optimize them for > the people. Which people? People that need to have their hands held with long fluffy names? Or for advanced coders that they can handle (and prefer) the shorter conventions? We should not dumb-down the OpenOCD code, and that is _exactly_ what you are describing. > > 2) More importantly, this patch applies the principle of least change. > > These changes both unify the type system around the types that are > > defined in "types.h" (and with the Linux kernel). Thus, we achieve > > conformance to an internal (and external) standard that we can enforce > > from here on. With less typing (this goes both for the types > > themselves > > and for the changes necessary to convert the entire tree to use the > > types that are used in only a handful of files today). > > > > Given that the state of the code is a hodgepodge of various naming > conventions, I don't see it being a good source for "it was mostly > that way already". I'd rather we chose a sensible convention based on > merits and apply it wholesale rather than just letting majority rule. Clearly you have not looked at the code with regard to this issue. The code is NOT a "hodgepodge" when it comes to these types. > Having the types align with the Linux kernel is of effectively no > importance. I happen to do all my development on OS X which follows > the C99 naming standards for anything in the BSD layer. Familiarity > in this case doesn't hold across the gamut of our developer base. How about familiarity with the OpenOCD code, which uses these types? How about the fact that 99% of the OpenOCD code already uses them? Sorry Rick, but I think that you and Duane have lost this argument. You have failed to defend your position with facts. Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] On Resets
Michael Bruck wrote: > Is there any particular reason why the JTAG layer uses hardware resets (TRST)? > > I would assume that the most portable way to go to TLR, the one that > works even if all reset lines are missing or are not yet or > incorrectly configured would be to shift out five HIGH bits which > leads to TLR regardless in which state the TAP is. > > Currently the JTAG layer doesn't even offer this simple function. So I > am wondering if the people who conceived the reset machinery were > unaware of this TLR mechanism. > Not sure. I dimly remember a CPU (MPC857?) with an errata where an external TRST was *required* to get JTAG working. Apart from such corner cases, I see no problem in using the TLR method as default on targets where it works. cu Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] JTAG, FT2232 and JLink
Unsubscribe. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] svf patch for segfault
This patch fix segfault reported by R.Doss. TODO: R.Doss's svf file has a very large scan: SDR 2732719 TDI (0002000200020002000200020002000200020002000200020002000200020002580042861.. Size of this scan is 2732719 bits. It sould be processed with one jtag_add_plain_dr_scan. Does all IF drivers support such a long scan? 2009-05-26 Best Regards, Simon Qian SimonQian(simonq...@simonqian.com) www.SimonQian.com svf_fix_segfault_20090526_0.patch Description: Binary data ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] JTAG, FT2232 and JLink
Dick Hollenbeck wrote: > Magnus Lundin wrote: >> Hi >> >> I was testing the state move work fronm Dick H. when there were a lot >> of changes in the codebase. As you know I keep working from the same >> base . There were some problems remaining so I have waited to send >> the results, but I hope I found most of them now. >> >> Here comes my patch. >> >> Best regards >> Magnus >> >> >> New jtag statetables in ft2232 and jlink >> >> >> The parts concering jtag state tables and transitions are from Dick >> Hollenbeck >> >> Some more 7 bit assumptions found in >>ft2232_add_scan() >>ft2232_read_scan() >> >> In order to work stably with unknown lengths for the last transition >> out of SHIFT ft2232, >> for IN and IO scans we now always two steps from SCAN -> EXIT1 -> >> PAUSE, to collect the final scanbit, before calling state_move to >> reach end state. This is the saame behaviour as in JLink driver > > > Nice catch. This was a single bug, not actually two bugs. > > > However this is not the only solution. This solution breaks the > contract that the API would like to honor by ignoring the endstate > parameter for the cases where the end state is DRSHIFT or IRSHIFT. > If there is another way to solve the problem that does not do this, > then would it not be superior? > No, there is a separate check to se if endstate is SHIFT, and then all data is transferred with Clock Data Bits and we never leave the SCAN state. But the JLink driver does not handle this situation correctly. Regards Magnus ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] svf patch for 32bit scan
Add svf_get_mask_u32 to generate a mask according to bitlen. Fix this bug in other functions except for svf_check_tdo. Next patch will fix the segfault reported by R.Doss. 2009-05-26 Best Regards, Simon Qian SimonQian(simonq...@simonqian.com) www.SimonQian.com svf_32bit_bug_20090526_0.patch Description: Binary data ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] JTAG, FT2232 and JLink
Magnus Lundin wrote: > Hi > > I was testing the state move work fronm Dick H. when there were a lot > of changes in the codebase. As you know I keep working from the same > base . There were some problems remaining so I have waited to send the > results, but I hope I found most of them now. > > Here comes my patch. > > Best regards > Magnus > > > New jtag statetables in ft2232 and jlink > > > The parts concering jtag state tables and transitions are from Dick > Hollenbeck > > Some more 7 bit assumptions found in >ft2232_add_scan() >ft2232_read_scan() > > In order to work stably with unknown lengths for the last transition > out of SHIFT ft2232, > for IN and IO scans we now always two steps from SCAN -> EXIT1 -> > PAUSE, to collect the final scanbit, before calling state_move to > reach end state. This is the saame behaviour as in JLink driver Nice catch. This was a single bug, not actually two bugs. However this is not the only solution. This solution breaks the contract that the API would like to honor by ignoring the endstate parameter for the cases where the end state is DRSHIFT or IRSHIFT. If there is another way to solve the problem that does not do this, then would it not be superior? Before offering a solution, I mention that the problem is because the ft2232 moves the shifted in bits on the reply to a "partial byte command" based on the number of clocks. This is the problem. So you have know the number of clocks to get to the partial byte within the full byte reply. Another solution is to record the number of clocks sent out and then use that number later in finding the partial byte. This can be done by recording that number in the command object itself, say in a spare field reserved for the driver. Then later in scan_read() this can be consulted and the partial byte can be found in the buffer within the full byte. This lets you preserve the contract that the API would like to commit to, but is currently not committing to. And it is simple. Dick ___ 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
Nicolas Pitre a écrit : > > > As far as my opinion matters, I don't think that uint32_t is that much > clearer than u32. It is widely assumed that u32 refers to an integer > and not a float, hence having the information carried everywhere is up > only for additional typing and screen realestate. And Linux makes for a > big example where plenty of odd naming collisions is simply not an issue > in practice (I know this example might not have such a weight for OS X > fans though). > > > Nicolas > ___ > I agree, personally I prefer u32 because it is quicker to write. Michel -- Tired of Microsoft's rebootive multitasking? then it's time to upgrade to Linux. http://home.comcast.net/~mcatudal ___ 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
Xiaofan Chen a écrit : > At that time, NEC documentation is quite bad. Their emulator was > very expensive. NEC chips seemed to be ok then. Luckily I > chose Microchip and not Atmel AT90S AVR since Atmel obsoleted > all the AT90S AVR over the years and the product needs to be > in the market for 10-15 years at 100k-200k per year. > > They have since moved to all flash and use JTAG debugging which they call N-WIRE. NEC's documentation is not easily available but once you are a customer you get a lot more than most people get. It is not as bad as TI which we had so sign non disclosure agreement with. NEC doesn't really care, I think the problem is that most of the good documentation is on the European site. I have suggested to have that changed and make some links so that would be transparent and was told that it was a good idea. There is no sense to have data duplicated in different sites around the world when each site can be accessed from anywhere in the world. The problems though is that people here in the USA do not think about looking at European or Asians sites and assume that documentation of their devices is not available. Most data that I have seem to have been translated in Germany. For a while all I had was in Japanese and I was using a translator site. When I complained to NEC they provided me with a link to a site in Europe. Thev V850E devices that I am looking at using have been out for a couple of years. Michel -- Tired of Microsoft's rebootive multitasking? then it's time to upgrade to Linux. http://home.comcast.net/~mcatudal ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] remove cmd_queue_cur_state
Magnus Lundin wrote:
> Dick Hollenbeck skrev:
>> Zach,
>>
>> I think this patch is fundamentally wrong and is a disaster the
>> moment it is applied.
>>
>> The queue sits between the jtag api and the drivers. The api calls
>> track "future" state according to the most recent api call submitted
>> (and put onto the back end of the queue) via the cmd_queue_cur_state
>> variable.
>>
>> The drivers consume commands in batch mode off the back end of the
>> queue. They have their own notion of state, and that is what the
>> "cable helper API" is for. That API has that name deliberately so
>> that you know these functions are for cable drivers, not for the jtag
>> api layer. Rather than worrying about a future state, they are
>> worrying about current state of the taps as the driver actually
>> manipulates TMS and the clock.
>>
>>
> Right, but the situation where this came up is when the tap state, or
> actually the target jtag controller changes state and the drivers must
> be informed about this.
>
> We cannot use cmd_queue_cur_state for this since it only records the
> state for sanity checking.
Nonsense.
cmd_queue_cur_state is a record of "the future effect of the most
recently queued command", i.e. what was last put into the queue. The
queue can be thought of as a pipe with a delay, and the contents of the
queue should eventually find its way to the driver then to the tap
controllers. Anything in the queue cannot be undone, but is not in
effect yet. Image a piece of PVC pipe and you put billiard balls into
it of different colors. There is a delay, and then the balls come out
in the same sequence some time later.
Two observers, one at the entrance to the pipe and one at the tail of
the pipe will see the same balls, but not at the same time. The balls
are analogous to the commands.
tap_set_state() is a "reporting mechanism" by the last observer. The
driver is reporting what it did to the taps and what state the driver
believes the actual hardware taps to be in because of actions that the
driver took in response to commands coming in via the queue. Only the
driver executes commands and therefore it is the only code which knows
what it did, and how this effects the actual taps. Therefore they
should be the only ones to call tap_set_state().
If you allow anybody but a driver to call tap_set_state() you have
perverted the purpose of tap_set_state() and you have brought on
insanity, so checking for it, as you state, is not needed, because it is
sure to be present.
You can create an accessor/variable pair for the front of the queue, but
it must be separate from the cable helper api.
I would suggest
jtag_set_future_state(),
jtag_record_future_state(), or
jtag_set_requested_state()
as possible function names for this encapsulation of the global variable
that you would like to hide.
jtag_set_requested_state( aState )
{
cmd_queue_cur_state = aState
}
jtag_get_requested_state()
{
return cmd_queue_cur_state;
}
All suggestions use a prefix different from the tap_ prefix which seems
to be common among functions in the cable helper api. Seems to be,
because that is how I wrote them.
Do not confuse what you are seeing at the entrance to the pipe and the
expected consequences of commands issued there at the jtag level, with
what is actually in the tap controllers beyond the end of the pipe and
accomplished by the drivers.
Dick
>
> We can add a " jtag_add_forced_set_state" or someting similar.
>
> Or we can do a jtag_execute_queue to flush the command queue and then
> a tap_set_state().
>> These two concepts are separate, and cannot be merged because of the
>> queue. tap_set_state() is for current state of the taps. But
>> realize there is can be some delay here also because sometimes their
>> are low level commands buffered before being sent out on USB. So
>> tap_set_state() only tracks to the best of its ability the current
>> state.
>>
>>
>> Dick
>>
>>
> Best regards
> Magnus
>
>
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] svn 1881 with jlink and STM32
On Monday 25 May 2009, Nicolas Pitre wrote: > On Sat, 23 May 2009, David Brownell wrote: > > > I see messages about needing to increase some GDB timeout/interval. But > > that's foolishness, since I'm not even working with GDB when they start > > spamming me. > > This is indeed really irritating. > > What about those messages being displayed only when a gdb connection is > actually in use? That'd be a start; it'd address the symptom, which is better than nothing. ___ 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
Xiaofan Chen a écrit : > 2009/5/25 Michel Catudal : > >> Some devices can be bought at relatively low price for personal designs, >> so it is not just for us in the automotive industry. >> http://www.futureelectronics.com/en/Search.aspx?dsNav=Ntk:PartNumberSearch|V850|1|,Ny:True,Nea:True >> > > I've seen a few designs with NEC V850 (Mini PLCs). > > NEC is very big in the US automotive industry and is a major player here. They have foundries in many places around the world. The funny part with most of our American company is that to same money they have moved the production outside to low cost labor countries. NEC has build big in the USA and move some production here. They have won the hearts and minds of a lot of American Engineers. >> They are well known for having good prices for small 8 bit devices >> http://www.futureelectronics.com/en/Technologies/Product.aspx?ProductID=UPD78F9202MACACANEC2877710 >> > > I've the luxury to read some assembly codes of NEC17k 4-bit > OTP/Masks MCUs. NEC was suggesting us to go for their 78K > 8-bit. But in the end I replaced them with Microchip PIC16 in > a simple but important design (EEx explosion proof Automation > market: a transformer isolated barrier which is the bread and > butter for the company). That was back in 1999 in my previous job. > At that time, NEC documentation is quite bad. Their emulator was > very expensive. NEC chips seemed to be ok then. Luckily I > chose Microchip and not Atmel AT90S AVR since Atmel obsoleted > all the AT90S AVR over the years and the product needs to be > in the market for 10-15 years at 100k-200k per year. > > The nice thing with NEC is that they don't discontinue parts as do other company. They still provide you with 4 bits or 8 bits devices if you need them even when the parts no longer officially exist. If you have a design with their devices they will provide you with parts as long as you are willing to pay for them. This is very important for us for military and automotive designs because they doesn't want any change when a product works. Companies bad for pulling parts of the market are Freescale and Hitachi (now Renesas). NEC and ST are two companies who have made serious profits last year while companies like NXP, Infineon and Freescale have huge debts. Michel -- Tired of Microsoft's rebootive multitasking? then it's time to upgrade to Linux. http://home.comcast.net/~mcatudal ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] support avr32
Nico Coesel a écrit : > FYI: > Coldfire = 68000 > Codesourcery offers precompiled GCC with Coldfire support. Maybe > Freescale can be persuaded to donate some hardware. They are losing > designs because they are currently forcing their customers to use > Codewarrior. > The Codewarrior crap is just part of the problems with Freescale. Some people have some other reason to ignore them http://www.reuters.com/article/innovationNewsTechMediaTelco/idUSTRE52U58720090331 There is also the huge debt which make people believe that the company may be near collapse. They were bought by the Carlyle Group at 4 times its value. Michel -- Tired of Microsoft's rebootive multitasking? then it's time to upgrade to Linux. http://home.comcast.net/~mcatudal ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] svf tap name patch
Committed revision 1912. On May 25, 2009, at 8:34 AM, SimonQian wrote: This patch add tap_state_svf_name in svf.c. Change RUN/IDLE to IDLE. IDLE is svf standard. 2009-05-25 Best Regards, Simon Qian SimonQian(simonq...@simonqian.com) www.SimonQian.com 发件人： SimonQian 发送时间： 2009-05-25 23:15:58 收件人： SimonQian; Openocd-Dev 抄送： 主题： Re: [Openocd-development] svf tap name patch This patch has some problems, in the recent jtag.h, tap states are different from original settings. I'll provide another patch soon. 2009-05-25 Best Regards, Simon Qian SimonQian(simonq...@simonqian.com) www.SimonQian.com 发件人： SimonQian 发送时间： 2009-05-25 22:03:56 收件人： Openocd-Dev 抄送： 主题： [Openocd-development] svf tap name patch This patch setup svf tap name in svf.c instead of calling tap_state_name. 2009-05-25 Best Regards, Simon Qian SimonQian(simonq...@simonqian.com) www.SimonQian.com < svf_tap_name_20090525_2 .patch>___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development -- Rick Altherr kc8...@kc8apf.net "He said he hadn't had a byte in three days. I had a short, so I split it with him." -- Unsigned smime.p7s Description: S/MIME cryptographic signature ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] PATCH] [0/3] cfi x16_as_x8 implementation.
Committed revision 1911.
On May 25, 2009, at 8:22 AM, Raúl Sánchez Siles wrote:
Hello:
On Friday 22 May 2009 20:16:14 Michael Schwingen wrote:
Raúl Sánchez Siles wrote:
Hello all:
This start a patchset series for implementing x16_as_x8 cfi
compliant
feature.
· 01-x16_as_x8-consolidate_addresses.patch
· 02-x16_as_x8-flash_address.patch
· 03-x16_as_x8-multibyte_read.patch
I have taken a view to the CFI specification [0] and it looks
that the
approach should also work for intel chips, while I had only tested
it
with spansion flash.
That looks good to me - I would have expected a lot more changes.
Some style comments:
- I do not really like left shifts with what is effectively a bool
variable as shift amount ("bank->bus_width << cfi_info-
>x16_as_x8"). The
logic is correct, but it looks strange.
For this point I propose the attached patch. In case it is decided
to be
applied consider the commit message:
"cfi flash_address coding style fix."
HTH,
--
Raúl Sánchez Siles
Departamento de Montaje
INFOGLOBAL, S. A.
* C/ Virgilio, 2. Ciudad de la Imagen.
28223 Pozuelo de Alarcón (Madrid), España
* T: +34 91 506 40 00
* F: +34 91 506 40 01
<01_cfi-
correct_bool_shift.txt>___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
--
Rick Altherr
kc8...@kc8apf.net
"He said he hadn't had a byte in three days. I had a short, so I split
it with him."
-- Unsigned
smime.p7s
Description: S/MIME cryptographic signature
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Question on V850 from NEC
Duane Ellis a écrit : > > 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. > > > The V850E is the latest and the latest GCC is working relatively well from my tests. I will test it with the minicube in a few weeks and make some comparisions with NEC and IAR. I created the binaries for V850E so I could learn more about that device that I am seriously looking into using for a new design. I I use it I will likely buy the NEC or IAR Compiler. Support for it would require to use the minicube if I am not mistaken as from my talks with NEC the debug part is there. It would require some reverse engineering because I doubt very much that NEC would release information on it. This is a lot of work. I wasn't asking if there was support planned, I was just curious about their N-WIRE interface and as to what is in the processor. Michel -- Tired of Microsoft's rebootive multitasking? then it's time to upgrade to Linux. http://home.comcast.net/~mcatudal ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] svf tap name patch
This patch add tap_state_svf_name in svf.c. Change RUN/IDLE to IDLE. IDLE is svf standard. 2009-05-25 Best Regards, Simon Qian SimonQian(simonq...@simonqian.com) www.SimonQian.com 发件人： SimonQian 发送时间： 2009-05-25 23:15:58 收件人： SimonQian; Openocd-Dev 抄送： 主题： Re: [Openocd-development] svf tap name patch This patch has some problems, in the recent jtag.h, tap states are different from original settings. I'll provide another patch soon. 2009-05-25 Best Regards, Simon Qian SimonQian(simonq...@simonqian.com) www.SimonQian.com 发件人： SimonQian 发送时间： 2009-05-25 22:03:56 收件人： Openocd-Dev 抄送： 主题： [Openocd-development] svf tap name patch This patch setup svf tap name in svf.c instead of calling tap_state_name. 2009-05-25 Best Regards, Simon Qian SimonQian(simonq...@simonqian.com) www.SimonQian.com svf_tap_name_20090525_2.patch Description: Binary data ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] support avr32
Xiaofan Chen a écrit : > On Mon, May 25, 2009 at 11:28 AM, Xiaofan Chen wrote: > >> There are many 16/32bit MCUs which will benefit from OpenOCD if >> they are supported. Most popular non-ARM ones I can think of are Renesas >> M16C/32C, H8/H8S/H8SX, Infineon XC166/XE166, TI MSP430. >> >> Just look at this chart for top 10 MCU vendors. >> http://www.eetasia.com/STATIC/ARTICLE_IMAGES/200904/EEOL_2009APR17_CTRLD_NT_01.gif >> > > Within theses chips and ColdFire, Infineon XE166 does not seem to have gcc > support. Incorrect, I have one, do you need it? I could provide some binaries on my web site if I have space left. It is about two years old, I am trying to get the lastest source but am having some problem with the company who so far has refused to abide by the GPL. They did provide me with the source a couple of years ago. I may look into updating the new sources myself but this is not my top priority at the moment. Which version would you need? I have Mandriva 2009.0, Fedora 9, SuSE 11.1 and Ubuntu 8.10 systems. I do have GCC for Renesas as well. If someone needs it I would need to recompile it under the new systems. Last I worked with it was with Fedora 8. I do have the latest source for Renesas. > So even though they have free DAS JTAG server which supports > cheap USB Jtag tools, it may not be that effective to offer OpenOCD support. > ftp://ftp.extra.infineon.com/MC_Skits_SW/UC-UConnect_XE164/Tools/DAS/DAS_Product_Brief_v1_0.pdf > > M16C and H8/H8S do have gcc support. But I do not know if there are any > cheap non-Renesas debugging tools for them. Renesas tools are getting > cheaper though. I even got a free M16C Tiny kit (a USB debugger and > a startkit board) from them just by visiting their website and put in some > contact information. > > I am not familiar with Fujitsu and NEC MCUs. > > Fujitsu micros require an emulator. I work with them on gauges and clusters. The emulator cost us about $12000 NEC has some real low cost 8 bits micros, some 16 bits and 32 bits micros also relatively low cost. Future is the distributor. You can get a debugger for the 8 bits devices for about $150 for the 8K devices. > So I will vote for PIC32 support first (being a Microchip fan and since the > support is more or less in place), then MSP430/AVR32/AVR support, then > ColdFire support. But of course the priority should be to get ARM > stable with different cores. ST, TI/Luminary, Atmel, NXP (No 6 to 10) > are all ARM MCU Vendors. > > My impression so far is that Atmel is probably farther ahead than Microchip on the 32 bits devices. Microchip seems very far behind in the automotive industry. I should find out more this week. I won't be able to give any specific details on their plan but I can say that they are not ready for me to take them seriously for new designs. Atmel doesn't have full documentation on the CAN AVR32 devices because they are waiting for the demo boards to be out. Parts were available for sampling last year. Because Atmel is much friendlier to the opensource I would vote for them if there was to be one over the other. I still think that both types of devices need serious consideration. Microchip is not very friendly to the opensource world but their stuff works. I am always fascinated with their devices when we do the harsh environment tests. I hate the Microchip banking shit on the 8 bits devices but hardware wise they are hard to beat. One could assume that their 32 bits devices will be just as good. If some preference is made on one over the other I would suggest to put more importance on the AVR32 devices not targeted for Linux as they are the likely devices to be use for most small embedded designs. Unlike the bigger AVR32 devices they do not require uboot but require some form of JTAG debugging much like ARM7 or cortex devices. Parallel designs should be in place. I am very interested in having a PIC32 debug working and am spending time on this effort. I will not present any patches until I get something working to my satisfaction. I would like to be informed though if anyone else is working on it so we can exchange ideas. Michel -- Tired of Microsoft's rebootive multitasking? then it's time to upgrade to Linux. http://home.comcast.net/~mcatudal ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] PATCH] [0/3] cfi x16_as_x8 implementation.
Hello:
On Friday 22 May 2009 20:16:14 Michael Schwingen wrote:
> Raúl Sánchez Siles wrote:
> > Hello all:
> >
> > This start a patchset series for implementing x16_as_x8 cfi compliant
> > feature.
> >
> > · 01-x16_as_x8-consolidate_addresses.patch
> > · 02-x16_as_x8-flash_address.patch
> > · 03-x16_as_x8-multibyte_read.patch
> >
> > I have taken a view to the CFI specification [0] and it looks that the
> > approach should also work for intel chips, while I had only tested it
> > with spansion flash.
>
> That looks good to me - I would have expected a lot more changes.
>
> Some style comments:
> - I do not really like left shifts with what is effectively a bool
> variable as shift amount ("bank->bus_width << cfi_info->x16_as_x8"). The
> logic is correct, but it looks strange.
>
For this point I propose the attached patch. In case it is decided to be
applied consider the commit message:
"cfi flash_address coding style fix."
HTH,
--
Raúl Sánchez Siles
Departamento de Montaje
INFOGLOBAL, S. A.
* C/ Virgilio, 2. Ciudad de la Imagen.
28223 Pozuelo de Alarcón (Madrid), España
* T: +34 91 506 40 00
* F: +34 91 506 40 01
Index: src/flash/cfi.c
===
--- src/flash/cfi.c (revisión: 1910)
+++ src/flash/cfi.c (copia de trabajo)
@@ -114,9 +114,11 @@
{
cfi_flash_bank_t *cfi_info = bank->driver_priv;
+ if(cfi_info->x16_as_x8) offset*=2;
+
/* while the sector list isn't built, only accesses to sector 0 work */
if (sector == 0)
- return bank->base + (offset * bank->bus_width <<
cfi_info->x16_as_x8 );
+ return bank->base + offset * bank->bus_width;
else
{
if (!bank->sectors)
@@ -124,7 +126,7 @@
LOG_ERROR("BUG: sector list not yet built");
exit(-1);
}
- return bank->base + bank->sectors[sector].offset + (offset *
bank->bus_width << cfi_info->x16_as_x8 );
+ return bank->base + bank->sectors[sector].offset + offset *
bank->bus_width;
}
}
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] svf tap name patch
This patch has some problems, in the recent jtag.h, tap states are different from original settings. I'll provide another patch soon. 2009-05-25 Best Regards, Simon Qian SimonQian(simonq...@simonqian.com) www.SimonQian.com 发件人： SimonQian 发送时间： 2009-05-25 22:03:56 收件人： Openocd-Dev 抄送： 主题： [Openocd-development] svf tap name patch This patch setup svf tap name in svf.c instead of calling tap_state_name. 2009-05-25 Best Regards, Simon Qian SimonQian(simonq...@simonqian.com) www.SimonQian.com ___ 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
2009/5/25 Michel Catudal : > Some devices can be bought at relatively low price for personal designs, > so it is not just for us in the automotive industry. > http://www.futureelectronics.com/en/Search.aspx?dsNav=Ntk:PartNumberSearch|V850|1|,Ny:True,Nea:True I've seen a few designs with NEC V850 (Mini PLCs). > They are well known for having good prices for small 8 bit devices > http://www.futureelectronics.com/en/Technologies/Product.aspx?ProductID=UPD78F9202MACACANEC2877710 I've the luxury to read some assembly codes of NEC17k 4-bit OTP/Masks MCUs. NEC was suggesting us to go for their 78K 8-bit. But in the end I replaced them with Microchip PIC16 in a simple but important design (EEx explosion proof Automation market: a transformer isolated barrier which is the bread and butter for the company). That was back in 1999 in my previous job. At that time, NEC documentation is quite bad. Their emulator was very expensive. NEC chips seemed to be ok then. Luckily I chose Microchip and not Atmel AT90S AVR since Atmel obsoleted all the AT90S AVR over the years and the product needs to be in the market for 10-15 years at 100k-200k per year. -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Question on V850 from NEC
Xiaofan Chen a écrit : > 2009/5/25 Michel Catudal : > >> 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. >> >> > > I do not know much about V850. Are you suggesting that V850 > and MIPS core have some relations? Google does not suggest > this... > > It might not be or is derived from one. I asked the question because I was told at one time by a salesman that it was a MIPS That line might give the implication that it is some sort of mips device. /usr/lib/gcc-lib/mips-linux-gnu/2.95.4/include/va-v850.h But from this site it appears to be an NEC design http://www.nec.co.jp/press/en/9708/2801.html Their JTAG interface is called N-WIRE Their devices are about the best I have seen as far as embedded devices are. Look at the V850ES though for the current ones. For interrupt access An ARM7TDMI takes 24 cycles to get to an interrupt A Cortex-M3 takes 12 cycles to get to an interrupt A V850E takes 4 cycles to get to an interrupt As far as speed, at 32Mhz V850E is close to twice the speed of a Micronas ARM7TDMI at 48Mhz. I had never thought about looking at these devices until we were forced to do so by Micronas screwing us by discontinuing their ARM7TDMI flash devices. I am very impressed by their Dashboard (Cluster) and Body devices (2 to 6 CAN available and price is very good) The NEC programmer is only $100 but it is serial. The debugging is N-WIRE (JTAG) and requires a device for debugging ($250-$500). I was wondering if anyone is familiar with these processors internals to know if the internal debugging module has enough so we could do some debugging without needing the outside device. Some devices can be bought at relatively low price for personal designs, so it is not just for us in the automotive industry. http://www.futureelectronics.com/en/Search.aspx?dsNav=Ntk:PartNumberSearch|V850|1|,Ny:True,Nea:True They are well known for having good prices for small 8 bit devices http://www.futureelectronics.com/en/Technologies/Product.aspx?ProductID=UPD78F9202MACACANEC2877710 Michel -- Tired of Microsoft's rebootive multitasking? then it's time to upgrade to Linux. http://home.comcast.net/~mcatudal ___ 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
On Sun, 24 May 2009, Rick Altherr wrote: > > On May 24, 2009, at 9:37 PM, Zach Welch wrote: > > > On Sun, 2009-05-24 at 21:19 -0700, Rick Altherr wrote: > > > =On May 24, 2009, at 9:04 PM, Zach Welch wrote: > > > > > > > On Sun, 2009-05-24 at 20:51 -0700, David Brownell wrote: > > > > > On Sunday 24 May 2009, Zach Welch wrote: > > > > > > - add iN equivalents to intN_t types; i32 is used by replacements.h > > > > > > > > > > The traditional sibling of a "u32" (unsigned) is an "s32" (signed). > > > > > > > > > > I don't know where "i32" came from, it's an interloper. > > > > > > > > That would be me, taking a blind stab in the dark. Mea culpa. > > > > > > > > Fixed: new patch attached for consideration. I have also fixed the > > > > duplicated section heading in the documentation. Anything else? > > > > > > > > Cheers, > > > > > > > > Zach > > > > > > > > > > > > > > > > > Maybe I misunderstood. I thought we were deprecating the use of "u32" > > > in favor of the C99-defined "uint32_t". Why would we define another > > > set of types when there a perfectly fine versions already available as > > > part of the language standard? > > > > Heh. I just went back and re-read the original post and realized my > > mistake; however, I will defend my changes with two principles: > > > > 1) It's shorter/faster to type. This argument has been hashed out > > extensively on the Linux mailing lists. Linus has it right in this > > debate to prefer s32/u32. POSIX is dumb; however, that doesn't mean we > > can't exploit their work for own purposes. > > > > Perhaps I'm jaded from writing code for OS X where function names are intended > to be descriptive and thus end up long. Most editors include autocompletion > which makes the difference minimal in practice. Even when I'm writing code in > vi, I prefer the longer type names since it make it clear that a) it's a type > by having the _t suffix and b) that's an unsigned int. With u32, there are > plenty of cases where odd naming collisions can occur. As far as my opinion matters, I don't think that uint32_t is that much clearer than u32. It is widely assumed that u32 refers to an integer and not a float, hence having the information carried everywhere is up only for additional typing and screen realestate. And Linux makes for a big example where plenty of odd naming collisions is simply not an issue in practice (I know this example might not have such a weight for OS X fans though). Nicolas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] svn 1881 with jlink and STM32
On Sat, 23 May 2009, David Brownell wrote: > I see messages about needing to increase some GDB timeout/interval. But > that's foolishness, since I'm not even working with GDB when they start > spamming me. This is indeed really irritating. What about those messages being displayed only when a gdb connection is actually in use? Nicolas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Does IF drivers designed to accept very large scan size?
In R.Doss's svf test, his svf file has a very large scan, size of which is 2732719 bits. This scan should be processed in one jtag_add_plain_dr_scan. But as I remember, driver of jlink doesn't support that size, and versaloon driver should also be modified. 2009-05-25 Best Regards, Simon Qian SimonQian(simonq...@simonqian.com) www.SimonQian.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 0.2.0 Status Report
On Sun, May 24, 2009 at 12:36 PM, Zach Welch wrote: > The following issues have been reported and should try to be resolved: > - flashing on LPC-P2148 (Xiaofan Chen) Just want to say that this problem is now solved. Please refer to the other thread about the solution. I need to erase the first bank before flashing the hex files. Thanks for your great work! -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Correct script to flash the lpc-2148
On Mon, May 25, 2009 at 10:09 AM, Xiaofan Chen wrote: > Now we are testing other hex file. I believe there may be two issues > involved after Michael fixed the checksum issue for lpc-2148. > > 1) Potential J-Link stability issues. I will check out V6. If it is ok > and V3 is not, then V3/V4 may need some work. I still encounter > startup errors with V3 from time to time. > 2) Reset/Halt/Out-of-Sync issue. Again I will check out V6 to see > if it is better. No issues any more. It turns out that I need to manually erase the first bank by using "flash erase_sector 0 0 26" before flashing the hex file (please refer to the other thread). Both J-Link V3 and V6 are working now. Thanks a lot for your patches to get V3 working as well. Now I can really get started learning to use OpenOCD. -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] svf tap name patch
This patch setup svf tap name in svf.c instead of calling tap_state_name. 2009-05-25 Best Regards, Simon Qian SimonQian(simonq...@simonqian.com) www.SimonQian.com svf_tap_name_20090525.patch Description: Binary data ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Correct script to flash the lpc-2148
On Mon, May 25, 2009 at 9:58 PM, Xiaofan Chen wrote: > On Mon, May 25, 2009 at 9:56 PM, Xiaofan Chen wrote: >> On Mon, May 25, 2009 at 9:46 PM, Xiaofan Chen wrote: > But it still does not work with the lpcusb isoc hex file. >>> >>> According to vbindiff report of the dump file, the first 0x160 >>> portion of the dump is not correct. Other than that, it seems >>> to be ok. >>> >>> dump_isoc.bin is from OpenOCD. >>> isoc_io_sample.bin is from arm-elf-objcopy. >>> >> >> Problem solved. I need to erase the first bank! >> # erase first bank only: >> flash erase_sector 0 0 26 >> >> Now it works! Thanks for the help. > > It seems that I am a lousy programmer but not too bad at > debugging issues. ;-) > > Thanks a lot for the help from Michael Fisher! > I tried to use the other hex file from JCWren's example, and it is also working. So I can say problem solved. Maybe this is a known trick (from what I see in the psas script). So sorry for the false alarming if this is indeed a known trick. -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] On Resets
Hi Michael, On 5/25/09, Michael Bruck wrote: > Is there any particular reason why the JTAG layer uses hardware resets > (TRST)? > > I would assume that the most portable way to go to TLR, the one that > works even if all reset lines are missing or are not yet or > incorrectly configured would be to shift out five HIGH bits which > leads to TLR regardless in which state the TAP is. > > Currently the JTAG layer doesn't even offer this simple function. So I > am wondering if the people who conceived the reset machinery were > unaware of this TLR mechanism. > > Unless there are good reasons (for example that we have cases where > going to TLR vs. asserting TRST produce differing results) I think the > reset lines should not be used from the JTAG layer at all, they should > be available to scripts (and possibly targets, but I think even that > is bad design for generic CPU drivers). > > My suggestion would be to expose the resets as a generic GPIO layer > that is available to scripts. An initial system reset (if that is > available in a system) could be generated via a configuration command. > Asserting TRST is from what I understand redundant, I don't see the > use in doing all the extra work that is done currently by the JTAG > layer to try to use that. > > Also I strongly suspect that the many recent reports on the list of > varying behavior when starting openocd several times in a row may be a > result of failed attempts to reset the TAP state via hardware lines. > At least we should consider adding the five 1's mechanism to the JTAG > initialization to reduce potential for such errors. > I agree with you. I found a board (i.MX25PDK rev 1.0) which needs to reset using this approach (letting TMS High during 5 clock pulses). It will be important to use this approach as default or implement it as a fall-back approach. Best Regards, > > Michael > Alan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Correct script to flash the lpc-2148
On Mon, May 25, 2009 at 9:56 PM, Xiaofan Chen wrote:
> On Mon, May 25, 2009 at 9:46 PM, Xiaofan Chen wrote:
But it still does not work with the lpcusb isoc hex file.
>>
>> According to vbindiff report of the dump file, the first 0x160
>> portion of the dump is not correct. Other than that, it seems
>> to be ok.
>>
>> dump_isoc.bin is from OpenOCD.
>> isoc_io_sample.bin is from arm-elf-objcopy.
>>
>
> Problem solved. I need to erase the first bank!
> # erase first bank only:
> flash erase_sector 0 0 26
>
> Now it works! Thanks for the help.
It seems that I am a lousy programmer but not too bad at
debugging issues. ;-)
Thanks a lot for the help from Michael Fisher!
mc...@ubuntu904:~/Desktop/build/openocd/jlinkv3/flash$ openocd -f myopenocd.cfg
Open On-Chip Debugger 0.2.0-in-development (2009-05-25-21:15) svn:1910
BUGS? Read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS
$URL: svn://svn.berlios.de/openocd/trunk/src/openocd.c $
RCLK - adaptive
Info : J-Link compiled Feb 20 2006 18:20:20 -- Update --
Info : JLink caps 0x3
Info : JLink hw version 3
Info : Vref = 3.268 TCK = 1 TDI = 0 TDO = 0 TMS = 0 SRST = 1 TRST = 255
Info : J-Link JTAG Interface ready
Info : JTAG tap: lpc2148.cpu tap/device found: 0x4f1f0f0f
(Manufacturer: 0x787, Part: 0xf1f0, Version: 0x4)
Info : JTAG Tap/device matched
Info : accepting 'telnet' connection from 0
target state: halted
target halted in ARM state due to debug-request, current mode: System
cpsr: 0x205f pc: 0x0868
target state: halted
target halted in ARM state due to debug-request, current mode: System
cpsr: 0x205f pc: 0x0868
flash 'lpc2000' found at 0x
0x: f018 e59f f018 e59f f018 e59f f018 e59f f018 e59f 5f84
b920 fff0 e51f f014 e59f
0x0020: 0040 00e4 00e0 00e4 00e4 00d8
00dc
erased sectors 0 through 26 on flash bank 0 in 0.255993s
0x:
0x0020:
Warn : Verification will fail since checksum in image(0xe1a0)
written to flash was different from calculated vector
checksum(0xb9205f84).
Warn : To remove this warning modify build tools on developer PC to
inject correct LPC vector checksum.
wrote 8036 byte from file isoc_io_sample.hex in 1.627033s (4.823293 kb/s)
0x: f018 e59f f018 e59f f018 e59f f018 e59f f018 e59f 5f84
b920 fff0 e51f f014 e59f
0x0020: 0040 00e4 00e0 00e4 00e4 00d8
00dc
0x: f018 e59f f018 e59f f018 e59f f018 e59f f018 e59f 5f84
b920 fff0 e51f f014 e59f
0x0020: 0040 00e4 00e0 00e4 00e4 00d8
00dc
0x0040: 0078 e59f f0db e321 d000 e1a0 0040 e240 f0d7 e321 d000
e1a0 0040 e240 f0d1 e321
0x0060: d000 e1a0 0040 e240 f0d2 e321 d000 e1a0 0c01 e240 f0d3
e321 d000 e1a0 0b01 e240
0x0080: f0df e321 d000 e1a0 1034 e59f 2034 e59f 3034 e59f 0003
e152 0004 3491 0004 3482
0x: f018 e59f f018 e59f f018 e59f f018 e59f f018 e59f 5f84
b920 fff0 e51f f014 e59f
0x0020: 0040 00e4 00e0 00e4 00e4 00d8
00dc
0x0040: 0078 e59f f0db e321 d000 e1a0 0040 e240 f0d7 e321 d000
e1a0 0040 e240 f0d1 e321
0x0060: d000 e1a0 0040 e240 f0d2 e321 d000 e1a0 0c01 e240 f0d3
e321 d000 e1a0 0b01 e240
0x0080: f0df e321 d000 e1a0 1034 e59f 2034 e59f 3034 e59f 0003
e152 0004 3491 0004 3482
0x00a0: fffb 3aff e3a0 1020 e59f 2020 e59f 0002 e151 0004
3481 fffc 3aff 01b7 ea00
0x00c0: 7edc 4000 1f64 0200 4000 0200 4000 0200 4000 06a8
4000 fffe eaff fffe eaff
0x00e0: fffe eaff fffe eaff 00ff e200 4030 e92d 3010 e240 5040
e59f 000f e350 30ff e203
0x0100: e083 e1a0 3000 9595 3004 8595 c080 e1a0 2003 93a0 2003
83a0 3c12 91c3 3e12 81c3
0x0120: 10ff e201 3c11 9183 3e11 8183 4005 e1a0 3000 9585 3004
8585 8030 e8bd c000 e002
Info : JTAG tap: lpc2148.cpu tap/device found: 0x4f1f0f0f
(Manufacturer: 0x787, Part: 0xf1f0, Version: 0x4)
Info : JTAG Tap/device matched
mc...@ubuntu904:~/Desktop/build/openocd/jlinkv3/flash$ telnet localhost
Trying ::1...
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Open On-Chip Debugger
> halt
target state: halted
target halted in ARM state due to debug-request, current mode: System
cpsr: 0x205f pc: 0x0868
> poll
target state: halted
target halted in ARM state due to debug-request, current mode: System
cpsr: 0x205f pc: 0x0868
> flash probe 0
flash 'lpc2000' found at 0x
> mdh 0x0 30
0x: f018 e59f f018 e59f f018 e59f f018 e59f f018 e59f 5f84
b920 fff0 e51f f014 e59f
0x0020: 0040 00e4 00e0 00e4 00e4 00d8
00dc
> flash erase_sector 0 0 26
erased sectors 0 through 26 on flash bank 0 in 0.255993s
> mdh 0x0 30
0x:
0x0020:
Re: [Openocd-development] Correct script to flash the lpc-2148
On Mon, May 25, 2009 at 9:46 PM, Xiaofan Chen wrote: >>> But it still does not work with the lpcusb isoc hex file. > > According to vbindiff report of the dump file, the first 0x160 > portion of the dump is not correct. Other than that, it seems > to be ok. > > dump_isoc.bin is from OpenOCD. > isoc_io_sample.bin is from arm-elf-objcopy. > Problem solved. I need to erase the first bank! # erase first bank only: flash erase_sector 0 0 26 Now it works! Thanks for the help. -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Correct script to flash the lpc-2148
On Mon, May 25, 2009 at 8:13 PM, Xiaofan Chen wrote: >>> With the simple script, V1906 can talk to J-Link V6. It seems to >>> work with your simple LED 1/2 blinking hex file. I tried both >>> jlink_hw_jtag 2 or 3. >>> >>> More tests to follow. >> >> But it still does not work with the lpcusb isoc hex file. According to vbindiff report of the dump file, the first 0x160 portion of the dump is not correct. Other than that, it seems to be ok. dump_isoc.bin is from OpenOCD. isoc_io_sample.bin is from arm-elf-objcopy. dump_isoc.bin : 18 F0 9F E5 18 F0 9F E5 18 F0 9F E5 18 F0 9F E5 0010: 18 F0 9F E5 00 00 21 A0 10 F0 1F E5 10 F0 9F E5 ..!. 0020: 40 00 00 00 E0 00 00 00 C0 00 00 00 C0 00 00 00 @... 0030: C4 00 00 00 00 00 00 00 C0 00 00 00 00 00 00 00 0040: 00 00 80 E1 00 00 20 E1 00 00 A0 E1 00 00 00 E0 .. . 0050: 00 00 20 E1 00 00 A0 E1 00 00 00 E0 00 00 20 E1 .. . .. . 0060: 00 D0 20 E1 40 00 00 E0 D2 F0 21 E3 00 D0 80 E1 .. @... ..!. 0070: 01 00 01 E2 50 D0 01 E1 00 D0 20 E1 00 00 00 E0 P... .. . 0080: D3 F0 21 E3 00 D0 80 E1 24 10 9F E5 24 20 9F E5 ..!. $...$ .. isoc_io_sample.bin : 18 F0 9F E5 18 F0 9F E5 18 F0 9F E5 18 F0 9F E5 0010: 18 F0 9F E5 00 00 A0 E1 F0 FF 1F E5 14 F0 9F E5 0020: 40 00 00 00 E4 00 00 00 E0 00 00 00 E4 00 00 00 @... 0030: E4 00 00 00 D8 00 00 00 DC 00 00 00 00 00 00 00 0040: 78 00 9F E5 DB F0 21 E3 00 D0 A0 E1 40 00 40 E2 x.!. @.@. 0050: D7 F0 21 E3 00 D0 A0 E1 40 00 40 E2 D1 F0 21 E3 ..!. @@...!. 0060: 00 D0 A0 E1 40 00 40 E2 D2 F0 21 E3 00 D0 A0 E1 @.@. ..!. 0070: 01 0C 40 E2 D3 F0 21 E3 00 D0 A0 E1 01 0B 40 E2 @...!. ..@. 0080: DF F0 21 E3 00 D0 A0 E1 34 10 9F E5 34 20 9F E5 ..!. 4...4 .. dump_isoc.bin 0080: D3 F0 21 E3 00 D0 80 E1 24 10 9F E5 24 20 9F E5 ..!. $...$ .. 0090: 00 30 80 E1 02 00 50 E1 04 00 81 14 04 00 82 10 .0P. 00A0: 00 00 0F 20 00 00 80 E3 00 11 09 E1 00 00 80 E1 ... 00B0: 00 00 00 E1 00 00 81 24 0C E0 A0 20 12 01 00 E0 ...$ ... 00C0: 01 00 00 40 00 00 00 00 00 00 00 40 00 02 00 40 @ @...@ 00D0: 00 02 00 40 A8 06 00 40 FE FF FF EA FE FF FF EA @...@ 00E0: FE FF FF EA FE FF FF EA 00 00 00 40 00 00 00 40 @...@ 00F0: 00 00 00 40 08 00 00 40 00 00 00 40 00 00 00 40 @...@ @...@ 0100: 00 00 00 40 00 00 80 00 04 10 05 80 00 00 A0 E1 @ isoc_io_sample.bin 0080: DF F0 21 E3 00 D0 A0 E1 34 10 9F E5 34 20 9F E5 ..!. 4...4 .. 0090: 34 30 9F E5 03 00 52 E1 04 00 91 34 04 00 82 34 40R. ...4...4 00A0: FB FF FF 3A 00 00 A0 E3 20 10 9F E5 20 20 9F E5 ...: ... .. 00B0: 02 00 51 E1 04 00 81 34 FC FF FF 3A B7 01 00 EA ..Q4 ...: 00C0: DC 7E 00 40 64 1F 00 00 00 02 00 40 00 02 00 40 @d... @...@ 00D0: 00 02 00 40 A8 06 00 40 FE FF FF EA FE FF FF EA @...@ 00E0: FE FF FF EA FE FF FF EA FF 00 00 E2 30 40 2D E9 .@-. 00F0: 10 30 40 E2 40 50 9F E5 0F 00 50 E3 FF 30 03 E2 @.@P.. ..P..0.. 0100: 83 E0 A0 E1 00 30 95 95 04 30 95 85 80 C0 A0 E1 .0.. .0.. dump_isoc.bin 0110: 00 20 80 81 02 20 A0 83 00 30 81 81 00 30 80 81 . ... .. .0...0.. 0120: 08 10 01 E0 10 30 83 81 00 20 83 81 00 00 80 E1 .0.. . .. 0130: 00 30 81 80 00 30 85 85 00 00 9D E0 00 02 02 E0 .0...0.. 0140: 00 00 8D E5 04 30 0D E1 00 00 8B 02 00 00 8D E5 .0.. 0150: 00 20 0D E1 00 00 95 01 03 00 00 E0 00 00 0D E1 . .. 0160: 10 30 40 E2 40 00 00 00 07 00 00 00 FF 30 07 E2 @.@... .0.. 0170: 83 E0 A0 E1 00 30 95 95 04 30 95 85 80 C0 A0 E1 .0.. .0.. 0180: 03 20 A0 93 03 20 A0 83 12 3C C3 91 12 3E C3 81 . ... .. .<...>.. 0190: FF 10 01 E2 11 3C 83 91 11 3E 83 81 05 40 A0 E1 .<.. .>@.. isoc_io_sample.bin 0110: 03 20 A0 93 03 20 A0 83 12 3C C3 91 12 3E C3 81 . ... .. .<...>.. 0120: FF 10 01 E2 11 3C 83 91 11 3E 83 81 05 40 A0 E1 .<.. .>@.. 0130: 00 30 85 95 04 30 85 85 30 80 BD E8 00 C0 02 E0 .0...0.. 0... 0140: 00 00 9F E5 1E FF 2F E1 00 87 93 03 00 00 9F E5 ../. 0150: 1E FF 2F E1 00 87 93 03 FF 00 00 E2 30 40 2D E9 ../. .@-. 0160: 10 30 40 E2 40 50 9F E5 0F 00 50 E3 FF 30 03 E2 @.@P.. ..P..0.. 0170: 83 E0 A0 E1 00 30 95 95 04 30 95 85 80 C0 A0 E1 .0.. .0.. 0180: 03 20 A0 93 03 20 A0 83 12 3C C3 91 12 3E C3 81 . ... .. .<...>.. 0190: FF 10 01 E2 11 3C 83 91 11 3E 83 81 05 40 A0 E1 .<.. .>@.. dump_isoc.bin 0110: 00 20 80 81 02 20 A0 83 00 30 81 81 00 30 80 81 . ..
[Openocd-development] On Resets
Is there any particular reason why the JTAG layer uses hardware resets (TRST)? I would assume that the most portable way to go to TLR, the one that works even if all reset lines are missing or are not yet or incorrectly configured would be to shift out five HIGH bits which leads to TLR regardless in which state the TAP is. Currently the JTAG layer doesn't even offer this simple function. So I am wondering if the people who conceived the reset machinery were unaware of this TLR mechanism. Unless there are good reasons (for example that we have cases where going to TLR vs. asserting TRST produce differing results) I think the reset lines should not be used from the JTAG layer at all, they should be available to scripts (and possibly targets, but I think even that is bad design for generic CPU drivers). My suggestion would be to expose the resets as a generic GPIO layer that is available to scripts. An initial system reset (if that is available in a system) could be generated via a configuration command. Asserting TRST is from what I understand redundant, I don't see the use in doing all the extra work that is done currently by the JTAG layer to try to use that. Also I strongly suspect that the many recent reports on the list of varying behavior when starting openocd several times in a row may be a result of failed attempts to reset the TAP state via hardware lines. At least we should consider adding the five 1's mechanism to the JTAG initialization to reduce potential for such errors. Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] svf fix according to SVN head and R.Doss's test
I'll fix below: 1. setup svf tap state names instead of using tap_state_name Return values of tap_state_name is now non-svf-standard. So I cannot use this function to setup svf tap state names. 2. malloc memory automatically to handle with any size of tap scan I'll provide first the patch to fix 1, and then 2. 2009-05-25 Best Regards, Simon Qian SimonQian(simonq...@simonqian.com) www.SimonQian.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] svn 1881 with jlink and STM32
On Sat, May 23, 2009 at 8:49 AM, Dylan Reid wrote:
> static int jlink_get_version_info(void)
>
> The crazy thing is that sometimes this works. Often enough to be
> usable actually. I added a check to jlink_usb_read and it makes it
> fail every time. I attached the patch as I think it is the right
> thing to do anyways. If you increase JLINK_IN_BUFFER_SIZE to
> something big enough, it will keep it functional.
>
> I don't have any experience with low level jtag interfacing, what is
> this code trying to do? Should something other than "J-" be returned
> after EMU_CMD_VERSION?
I am seeing the same problem for my V6. Increasing the USB
timeout to 5000ms does not help.
And this is actually correct as J-Link Linux utility are reporting
similar problems.
For my V3 J-Link, Segger utility seems to be ok. OpenOCD does still
print out errors.
But anyway, I think this may not be really important.
mc...@ubuntu904:~/Desktop/build/openocd/jlinkv6$ openocd -f myopenocd.cfg
Open On-Chip Debugger 0.2.0-in-development (2009-05-25-20:35) svn:1910M
BUGS? Read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS
$URL: svn://svn.berlios.de/openocd/trunk/src/openocd.c $
RCLK - adaptive
Error: J-Link command EMU_CMD_VERSION failed (-110)
Error: J-Link command EMU_CMD_VERSION impossible return length 0x2d4a
Error: J-Link command EMU_CMD_VERSION failed (-110)
mc...@ubuntu904:~/Desktop/build/openocd/jlink$ ./start
SEGGER J-Link Commander V4.03a ('?' for help)
Compiled Feb 2 2009 11:34:21
Updating firmware: J-Link ARM V6 compiled Jan 15 2009 11:58:34
Replacing firmware: J-Link ARM V6 compiled Dec 03 2007 17:34:18
Waiting for new firmware to boot
New firmware booted successfully
** Error: Communication timed out after firmware update
DLL version V4.03a, compiled Feb 2 2009 11:34:13
Unable to retrieve firmware info !
S/N : 156007287
OEM : IAR
Feature(s) : RDI, FlashDL, GDBFull, FlashBP, JFlash
VTarget = 3.248V
Info: TotalIRLen = 4, IRPrint = 0x01
WARNING: Identified core does not match configuration. (Found: ARM7,
Configured: None)
Found 1 JTAG device, Total IRLen = 4:
Id of device #0: 0x4F1F0F0F
Found ARM with core Id 0x4F1F0F0F (ARM7)
ETM V1.2: 1 pairs addr.comp, 0 data comp, 4 MM decs, 1 counters
RTCK reaction time is approx. 126ns
Using adaptive clocking instead of fixed JTAG speed.
J-Link>f
Unable to retrieve firmware info !
mc...@ubuntu904:~/Desktop/build/openocd/jlink$ ./start
SEGGER J-Link Commander V4.03a ('?' for help)
Compiled Feb 2 2009 11:34:21
DLL version V4.03a, compiled Feb 2 2009 11:34:13
Firmware: J-Link compiled Feb 20 2006 18:20:20 -- Update --
Hardware: V3.00
S/N : 3330
OEM : IAR
VTarget = 3.272V
Info: TotalIRLen = 4, IRPrint = 0x01
WARNING: Identified core does not match configuration. (Found: ARM7,
Configured: None)
Found 1 JTAG device, Total IRLen = 4:
Id of device #0: 0x4F1F0F0F
Found ARM with core Id 0x4F1F0F0F (ARM7)
ETM V1.2: 1 pairs addr.comp, 0 data comp, 4 MM decs, 1 counters
JTAG speed: 5 kHz
J-Link>f
Firmware: J-Link compiled Feb 20 2006 18:20:20 -- Update --
Hardware: V3.00
mc...@ubuntu904:~/Desktop/build/openocd/jlinkv3$ openocd -f myopenocd.cfg
Open On-Chip Debugger 0.2.0-in-development (2009-05-25-20:35) svn:1910M
BUGS? Read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS
$URL: svn://svn.berlios.de/openocd/trunk/src/openocd.c $
RCLK - adaptive
Error: J-Link command EMU_CMD_VERSION failed (-110)
Info : J-Link compiled Feb 20 2006 18:20:20 -- Update --
Info : JLink caps 0x3
Info : JLink hw version 3
Info : Vref = 3.270 TCK = 1 TDI = 0 TDO = 0 TMS = 0 SRST = 1 TRST = 255
Info : J-Link JTAG Interface ready
Warn : keep_alive() was not invoked in the 1000ms timelimit. GDB alive
packet not sent! (15107). Workaround: increase "set remotetimeout" in
GDB
Info : JTAG tap: lpc2148.cpu tap/device found: 0x4f1f0f0f
(Manufacturer: 0x787, Part: 0xf1f0, Version: 0x4)
Info : JTAG Tap/device matched
^C
--
Xiaofan http://mcuee.blogspot.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Correct script to flash the lpc-2148
On Sun, May 24, 2009 at 5:59 PM, Michael Fischer wrote: > > But it could be possible that the J-Link had a problem too. >From all the tests, it seems to me that it is a J-Link problem. It seems to me that you can flash the LPC-2148 with ft2232 interface or with the Segger J-Flash using J-Link. But I can not flash bigger hex files with J-Link with OpenOCD and I tested both V3 and V6 J-Link. > Have other users problem with flashing the LPC2148? > I hope other users can also report their success or failure with J-Link and flashing LPC2148 or similar NXP ARM7 parts. -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Correct script to flash the lpc-2148
On Mon, May 25, 2009 at 8:09 PM, Xiaofan Chen wrote: > On Mon, May 25, 2009 at 8:02 PM, Xiaofan Chen wrote: >> With the simple script, V1906 can talk to J-Link V6. It seems to >> work with your simple LED 1/2 blinking hex file. I tried both >> jlink_hw_jtag 2 or 3. >> >> More tests to follow. > > But it still does not work with the lpcusb isoc hex file. I mean the device is not functional. It does not work with jcwren's example either. Here I use manual reset. The flashing all seems to be successful but the device is not working. mc...@ubuntu904:~/Desktop/build/openocd/jlinkv6$ openocd -f myopenocd.cfg Open On-Chip Debugger 0.2.0-in-development (2009-05-24-21:41) svn:1906 BUGS? Read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS $URL: svn://svn.berlios.de/openocd/trunk/src/openocd.c $ RCLK - adaptive Error: J-Link command EMU_CMD_VERSION failed (-110) Error: J-Link command EMU_CMD_VERSION impossible return length 0x2d4a Error: J-Link command EMU_CMD_VERSION failed (-110) Info : J-Link ARM V6 compiled Dec 03 2007 17:34:18 Info : JLink caps 0xf7fbf Info : JLink hw version 6 Info : JLink max mem block 9992 Info : Vref = 3.248 TCK = 1 TDI = 0 TDO = 0 TMS = 0 SRST = 1 TRST = 1 Info : J-Link JTAG Interface ready Warn : keep_alive() was not invoked in the 1000ms timelimit. GDB alive packet not sent! (6123). Workaround: increase "set remotetimeout" in GDB Info : JTAG tap: lpc2148.cpu tap/device found: 0x4f1f0f0f (Manufacturer: 0x787, Part: 0xf1f0, Version: 0x4) Info : JTAG Tap/device matched Info : accepting 'telnet' connection from 0 target state: halted target halted in ARM state due to debug-request, current mode: Abort cpsr: 0x40d7 pc: 0x010c Warn : Verification will fail since checksum in image(0xe59ff004) written to flash was different from calculated vector checksum(0xb9205f88). Warn : To remove this warning modify build tools on developer PC to inject correct LPC vector checksum. wrote 232748 byte from file lpc2148.hex in 47.024014s (4.833551 kb/s) ^C mc...@ubuntu904:~/Desktop/build/openocd/jlinkv6$ telnet localhost Trying ::1... Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. Open On-Chip Debugger > halt target state: halted target halted in ARM state due to debug-request, current mode: Abort cpsr: 0x40d7 pc: 0x010c > flash write_image lpc2148.hex 0x0 Verification will fail since checksum in image(0xe59ff004) written to flash was different from calculated vector checksum(0xb9205f88). To remove this warning modify build tools on developer PC to inject correct LPC vector checksum. wrote 232748 byte from file lpc2148.hex in 47.024014s (4.833551 kb/s) > Connection closed by foreign host. So the yellow J-Link V6 behaves the same as V3. Other than the simple LED blinking program, the two other hex files are not working. -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Correct script to flash the lpc-2148
On Mon, May 25, 2009 at 8:02 PM, Xiaofan Chen wrote: > With the simple script, V1906 can talk to J-Link V6. It seems to > work with your simple LED 1/2 blinking hex file. I tried both > jlink_hw_jtag 2 or 3. > > More tests to follow. But it still does not work with the lpcusb isoc hex file. mc...@ubuntu904:~/Desktop/build/openocd/jlinkv6$ openocd -f myopenocd.cfg Open On-Chip Debugger 0.2.0-in-development (2009-05-24-21:41) svn:1906 BUGS? Read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS $URL: svn://svn.berlios.de/openocd/trunk/src/openocd.c $ RCLK - adaptive Info : J-Link ARM V6 compiled Dec 03 2007 17:34:18 Info : JLink caps 0xf7fbf Info : JLink hw version 6 Info : JLink max mem block 9992 Info : Vref = 3.248 TCK = 1 TDI = 0 TDO = 0 TMS = 0 SRST = 1 TRST = 1 Info : J-Link JTAG Interface ready Info : JTAG tap: lpc2148.cpu tap/device found: 0x4f1f0f0f (Manufacturer: 0x787, Part: 0xf1f0, Version: 0x4) Info : JTAG Tap/device matched Warn : DBGACK set while target was in unknown state. Reset or initialize target. target state: halted target halted in ARM state due to breakpoint, current mode: System cpsr: 0x80df pc: 0x0140 Info : accepting 'telnet' connection from 0 target state: halted target halted in ARM state due to breakpoint, current mode: System cpsr: 0x80df pc: 0x0140 Info : JTAG tap: lpc2148.cpu tap/device found: 0x4f1f0f0f (Manufacturer: 0x787, Part: 0xf1f0, Version: 0x4) Info : JTAG Tap/device matched target state: running target state: halted target halted in ARM state due to debug-request, current mode: System cpsr: 0x80df pc: 0x0128 Warn : Verification will fail since checksum in image(0xe1a0) written to flash was different from calculated vector checksum(0xb9205f84). Warn : To remove this warning modify build tools on developer PC to inject correct LPC vector checksum. wrote 8036 byte from file isoc_io_sample.hex in 2.891050s (2.714466 kb/s) Info : JTAG tap: lpc2148.cpu tap/device found: 0x4f1f0f0f (Manufacturer: 0x787, Part: 0xf1f0, Version: 0x4) Info : JTAG Tap/device matched target state: running target state: halted target halted in ARM state due to debug-request, current mode: Abort cpsr: 0x40d7 pc: 0x014c Info : JTAG tap: lpc2148.cpu tap/device found: 0x4f1f0f0f (Manufacturer: 0x787, Part: 0xf1f0, Version: 0x4) Info : JTAG Tap/device matched ^C mc...@ubuntu904:~/Desktop/build/openocd/jlinkv6$ telnet localhost Trying ::1... Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. Open On-Chip Debugger > halt > poll target state: halted target halted in ARM state due to breakpoint, current mode: System cpsr: 0x80df pc: 0x0140 > reset JTAG tap: lpc2148.cpu tap/device found: 0x4f1f0f0f (Manufacturer: 0x787, Part: 0xf1f0, Version: 0x4) JTAG Tap/device matched > poll target state: running > halt target state: halted target halted in ARM state due to debug-request, current mode: System cpsr: 0x80df pc: 0x0128 > jlink_hw_jtag 3 > flash write_image isoc_io_sample.hex 0x0 Verification will fail since checksum in image(0xe1a0) written to flash was different from calculated vector checksum(0xb9205f84). To remove this warning modify build tools on developer PC to inject correct LPC vector checksum. wrote 8036 byte from file isoc_io_sample.hex in 2.891050s (2.714466 kb/s) > reset JTAG tap: lpc2148.cpu tap/device found: 0x4f1f0f0f (Manufacturer: 0x787, Part: 0xf1f0, Version: 0x4) JTAG Tap/device matched > init > poll target state: running > halt target state: halted target halted in ARM state due to debug-request, current mode: Abort cpsr: 0x40d7 pc: 0x014c > reset JTAG tap: lpc2148.cpu tap/device found: 0x4f1f0f0f (Manufacturer: 0x787, Part: 0xf1f0, Version: 0x4) JTAG Tap/device matched > Connection closed by foreign host. -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Correct script to flash the lpc-2148
On Mon, May 25, 2009 at 7:43 PM, Xiaofan Chen wrote: >> I will try with the J-Link V6 a bit later and report. >> > Somehow 1906 can not connect to my J-Link V6 with your script. With the simple script, V1906 can talk to J-Link V6. It seems to work with your simple LED 1/2 blinking hex file. I tried both jlink_hw_jtag 2 or 3. More tests to follow. source [find target/lpc2148.cfg] source [find interface/jlink.cfg] #--- Daemon Configuration telnet_port gdb_port tcl_port # Tell gdb that you can use us to program the device (requires GDB >=6.7 and libexapt) gdb_memory_mapenable gdb_flash_program enable mc...@ubuntu904:~/Desktop/build/openocd/jlinkv6$ openocd -f myopenocd.cfg Open On-Chip Debugger 0.2.0-in-development (2009-05-24-21:41) svn:1906 BUGS? Read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS $URL: svn://svn.berlios.de/openocd/trunk/src/openocd.c $ RCLK - adaptive Error: J-Link command EMU_CMD_VERSION impossible return length 0x2d4a Error: J-Link command EMU_CMD_VERSION failed (-110) Info : J-Link ARM V6 compiled Dec 03 2007 17:34:18 Info : JLink caps 0xf7fbf Info : JLink hw version 6 Info : JLink max mem block 9992 Info : Vref = 3.248 TCK = 1 TDI = 0 TDO = 0 TMS = 0 SRST = 1 TRST = 1 Info : J-Link JTAG Interface ready Warn : keep_alive() was not invoked in the 1000ms timelimit. GDB alive packet not sent! (3212). Workaround: increase "set remotetimeout" in GDB Info : JTAG tap: lpc2148.cpu tap/device found: 0x4f1f0f0f (Manufacturer: 0x787, Part: 0xf1f0, Version: 0x4) Info : JTAG Tap/device matched Info : accepting 'telnet' connection from 0 target state: halted target halted in ARM state due to debug-request, current mode: System cpsr: 0x80df pc: 0x0194 wrote 756 byte from file led12_blink.hex in 0.644003s (1.146394 kb/s) Info : JTAG tap: lpc2148.cpu tap/device found: 0x4f1f0f0f (Manufacturer: 0x787, Part: 0xf1f0, Version: 0x4) Info : JTAG Tap/device matched target state: halted target halted in ARM state due to debug-request, current mode: System cpsr: 0x80df pc: 0x0178 Error: Target not halted Error: error writing to flash at address 0x at offset 0x (-304) target state: halted target halted in ARM state due to debug-request, current mode: System cpsr: 0x80df pc: 0x0124 wrote 756 byte from file led12_blink.hex in 0.370004s (1.995333 kb/s) Info : JTAG tap: lpc2148.cpu tap/device found: 0x4f1f0f0f (Manufacturer: 0x787, Part: 0xf1f0, Version: 0x4) Info : JTAG Tap/device matched target state: halted target halted in ARM state due to debug-request, current mode: System cpsr: 0x80df pc: 0x0124 ^C mc...@ubuntu904:~/Desktop/build/openocd/jlinkv6$ telnet localhost Trying ::1... Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. Open On-Chip Debugger > halt target state: halted target halted in ARM state due to debug-request, current mode: System cpsr: 0x80df pc: 0x0194 > jlink_hw_jtag 3 > flash write_image led12_blink.hex 0x0 wrote 756 byte from file led12_blink.hex in 0.644003s (1.146394 kb/s) > reset JTAG tap: lpc2148.cpu tap/device found: 0x4f1f0f0f (Manufacturer: 0x787, Part: 0xf1f0, Version: 0x4) JTAG Tap/device matched > halt target state: halted target halted in ARM state due to debug-request, current mode: System cpsr: 0x80df pc: 0x0178 > resume > jlink_hw_jtag 2 > flash write_image led12_blink.hex 0x0 Target not halted error writing to flash at address 0x at offset 0x (-304) called at file "command.c", line 453 called at file "embedded:startup.tcl", line 89 called at file "embedded:startup.tcl", line 91 called at file "embedded:startup.tcl", line 93 > halt target state: halted target halted in ARM state due to debug-request, current mode: System cpsr: 0x80df pc: 0x0124 > flash write_image led12_blink.hex 0x0 wrote 756 byte from file led12_blink.hex in 0.370004s (1.995333 kb/s) > reset JTAG tap: lpc2148.cpu tap/device found: 0x4f1f0f0f (Manufacturer: 0x787, Part: 0xf1f0, Version: 0x4) JTAG Tap/device matched > jlink_hw_jtag 3 > halt target state: halted target halted in ARM state due to debug-request, current mode: System cpsr: 0x80df pc: 0x0124 > Connection closed by foreign host. -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Correct script to flash the lpc-2148
On Mon, May 25, 2009 at 7:31 PM, Xiaofan Chen wrote: > I will try with the J-Link V6 a bit later and report. > Somehow 1906 can not connect to my J-Link V6 with your script. mc...@ubuntu904:~/Desktop/build/openocd/jlinkv6$ openocd -f jlink.cfg Open On-Chip Debugger 0.2.0-in-development (2009-05-24-21:41) svn:1906 BUGS? Read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS $URL: svn://svn.berlios.de/openocd/trunk/src/openocd.c $ 30 kHz Info : J-Link ARM V6 compiled Dec 03 2007 17:34:18 Info : JLink caps 0xf7fbf Info : JLink hw version 6 Info : JLink max mem block 9992 Info : Vref = 3.248 TCK = 1 TDI = 0 TDO = 0 TMS = 0 SRST = 1 TRST = 1 Info : J-Link JTAG Interface ready Error: usb_bulk_read failed (requested=1, result=-110) Error: jlink_tap_execute, wrong result -107 (expected 1) Warn : keep_alive() was not invoked in the 1000ms timelimit. GDB alive packet not sent! (3121). Workaround: increase "set remotetimeout" in GDB Error: usb_bulk_read failed (requested=1, result=-110) Error: jlink_tap_execute, wrong result -107 (expected 1) Warn : keep_alive() was not invoked in the 1000ms timelimit. GDB alive packet not sent! (3222). Workaround: increase "set remotetimeout" in GDB Error: usb_bulk_read failed (requested=1, result=-110) Error: jlink_tap_execute, wrong result -107 (expected 1) Warn : keep_alive() was not invoked in the 1000ms timelimit. GDB alive packet not sent! (3408). Workaround: increase "set remotetimeout" in GDB 30 kHz Error: usb_bulk_read failed (requested=1, result=-110) Error: jlink_tap_execute, wrong result -107 (expected 1) Warn : keep_alive() was not invoked in the 1000ms timelimit. GDB alive packet not sent! (3230). Workaround: increase "set remotetimeout" in GDB Error: usb_bulk_read failed (requested=1, result=-110) Error: jlink_tap_execute, wrong result -107 (expected 1) Runtime error, file "embedded:startup.tcl", line 173: error: -104 Runtime error, file "jlink.cfg", line 104: -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Correct script to flash the lpc-2148
On Sun, May 24, 2009 at 11:10 PM, Michael Fischer wrote: > Hello Xiaofan, > > I have tesed to flash the program here. I could flash it > with my ft2232 device. I do not check the functionality > of the program itself, LED1 was flashing. And you can switch on/off LED 2 by pressing the two switches. So I think you flashing is good. >>2) And it seems to have reset/halt problem. > This is correct, I could not get in contact with OpenOCD. > And I could not get in contact with the original segger > sw and try to erase the CPU. Here I must use FlashMagic > and the ICSP interface to erase the CPU. > > Is it possible that the application switch of the JTAG > interface here? Indeed. I tried to communicate with the chip programmed by lpc21isp (functional) with Segger's Linux utility or OpenOCD and both are not working. So the author may have disable JTAG. I have not looked in detail of the codes yet. So in the end, it is working at your end using the ft2232 interface for OpenOCD. I will try with the J-Link V6 a bit later and report. -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] rev1910 - unable to compile with ftd2xx enabled
On Monday 25 May 2009 13:28:03 Hubert Hoegl wrote: > I had the same error yesterday. It seems that you have to change the > order of the commandline in this way: > > gcc ... .libs/libopenocd.so > /home/vylu/downloads/ftd2xx/extracted/libftd2xx0.4.16_x86_64/static_lib/lib >ftd2xx.a.0.4.16 -ldl -lpthread Thanks, Hubert. Maybe somebody could fix autoconf scripts, if the problem is there? -- vylu ___ 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] rev1910 - unable to compile with ftd2xx enabled
On Monday 25 May 2009 11:59:42 Xiaofan Chen wrote: > I usually re-run bootstrap or to pull the subversion source again. Maybe > you can try this. Yes, I've tried that already... It doesn't help. -- vylu ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] rev1910 - unable to compile with ftd2xx enabled
Hallo Vytautas, I had the same error yesterday. It seems that you have to change the order of the commandline in this way: gcc ... .libs/libopenocd.so /home/vylu/downloads/ftd2xx/extracted/libftd2xx0.4.16_x86_64/static_lib/libftd2xx.a.0.4.16 -ldl -lpthread Regards, Hubert On Mon, May 25, 2009 at 11:53:24AM +0300, Vytautas Lukenskas wrote: > Hi all, > > I'm unable to compile latest trunk with ftd2xx library. Linker fails with > the > following error: > > make[3]: Entering directory `/usr/src/openocd/trunk/src' > /bin/sh ../libtool --tag=CC --mode=link > gcc -std=gnu99 -g -O2 > -I/home/vylu/downloads/ftd2xx/extracted/libftd2xx0.4.16_x86_64 -Wall > -Wstrict-prototypes -Wformat-security -Wextra -Wno-unused-parameter > -Wbad-function-cast -Wcast-align -Wredundant-decls -Werror -o > openocd main.o > libopenocd.la -ldl > /home/vylu/downloads/ftd2xx/extracted/libftd2xx0.4.16_x86_64/static_lib/libftd2xx.a.0.4.16 > -lpthread > gcc -std=gnu99 -g -O2 > -I/home/vylu/downloads/ftd2xx/extracted/libftd2xx0.4.16_x86_64 -Wall > -Wstrict-prototypes -Wformat-security -Wextra -Wno-unused-parameter > -Wbad-function-cast -Wcast-align -Wredundant-decls -Werror -o .libs/openocd > main.o > /home/vylu/downloads/ftd2xx/extracted/libftd2xx0.4.16_x86_64/static_lib/libftd2xx.a.0.4.16 > ./.libs/libopenocd.so -ldl -lpthread > ./.libs/libopenocd.so: undefined reference to `FT_GetLatencyTimer' > ./.libs/libopenocd.so: undefined reference to `FT_Close' > ./.libs/libopenocd.so: undefined reference to `FT_SetBitMode' > ./.libs/libopenocd.so: undefined reference to `FT_OpenEx' > ./.libs/libopenocd.so: undefined reference to `FT_Read' > ./.libs/libopenocd.so: undefined reference to `FT_SetTimeouts' > ./.libs/libopenocd.so: undefined reference to `FT_SetVIDPID' > ./.libs/libopenocd.so: undefined reference to `FT_Write' > ./.libs/libopenocd.so: undefined reference to `FT_SetLatencyTimer' > ./.libs/libopenocd.so: undefined reference to `FT_ListDevices' > ./.libs/libopenocd.so: undefined reference to `FT_Purge' > collect2: ld returned 1 exit status > . > etc. > > configure script parameters are: > ./configure --enable-maintainer-mode --enable-ft2232_ftd2xx > --with-ftd2xx-linux-tardir=/home/vylu/downloads/ftd2xx/extracted/libftd2xx0.4.16_x86_64 > > Are the latest revisions broken, or I just use wrong configure instructions? > > Regards, > vylu > ___ > Openocd-development mailing list > Openocd-development@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/openocd-development ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] 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] support avr32
> -Oorspronkelijk bericht- > Van: openocd-development-boun...@lists.berlios.de > [mailto:openocd-development-boun...@lists.berlios.de] Namens > Xiaofan Chen > Verzonden: maandag 25 mei 2009 10:54 > Aan: openocd-development@lists.berlios.de > Onderwerp: Re: [Openocd-development] support avr32 > > On Mon, May 25, 2009 at 11:28 AM, Xiaofan Chen > wrote: > > > > There are many 16/32bit MCUs which will benefit from > OpenOCD if they > > are supported. Most popular non-ARM ones I can think of are Renesas > > M16C/32C, H8/H8S/H8SX, Infineon XC166/XE166, TI MSP430. > > > > Just look at this chart for top 10 MCU vendors. > > > http://www.eetasia.com/STATIC/ARTICLE_IMAGES/200904/EEOL_2009APR17_CTR > > LD_NT_01.gif > > Within theses chips and ColdFire, Infineon XE166 does not > seem to have gcc support. So even though they have free DAS FYI: Coldfire = 68000 Codesourcery offers precompiled GCC with Coldfire support. Maybe Freescale can be persuaded to donate some hardware. They are losing designs because they are currently forcing their customers to use Codewarrior. The Renesas controllers are another story. Turning the code read protection on requires an NDA so OpenOCD is not likely to be able to support code read protection on Renesas chips. Nico Coesel ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] support avr32
On Mon, May 25, 2009 at 11:28 AM, Xiaofan Chen wrote: > > There are many 16/32bit MCUs which will benefit from OpenOCD if > they are supported. Most popular non-ARM ones I can think of are Renesas > M16C/32C, H8/H8S/H8SX, Infineon XC166/XE166, TI MSP430. > > Just look at this chart for top 10 MCU vendors. > http://www.eetasia.com/STATIC/ARTICLE_IMAGES/200904/EEOL_2009APR17_CTRLD_NT_01.gif Within theses chips and ColdFire, Infineon XE166 does not seem to have gcc support. So even though they have free DAS JTAG server which supports cheap USB Jtag tools, it may not be that effective to offer OpenOCD support. ftp://ftp.extra.infineon.com/MC_Skits_SW/UC-UConnect_XE164/Tools/DAS/DAS_Product_Brief_v1_0.pdf M16C and H8/H8S do have gcc support. But I do not know if there are any cheap non-Renesas debugging tools for them. Renesas tools are getting cheaper though. I even got a free M16C Tiny kit (a USB debugger and a startkit board) from them just by visiting their website and put in some contact information. I am not familiar with Fujitsu and NEC MCUs. So I will vote for PIC32 support first (being a Microchip fan and since the support is more or less in place), then MSP430/AVR32/AVR support, then ColdFire support. But of course the priority should be to get ARM stable with different cores. ST, TI/Luminary, Atmel, NXP (No 6 to 10) are all ARM MCU Vendors. -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] rev1910 - unable to compile with ftd2xx enabled
On Mon, May 25, 2009 at 4:53 PM, Vytautas Lukenskas wrote: > I'm unable to compile latest trunk with ftd2xx library. Linker fails with the > following error: > ./.libs/libopenocd.so: undefined reference to `FT_GetLatencyTimer' > I do not use Linux x86_64 and FTD2xx but when I encounter similar problems, I usually re-run bootstrap or to pull the subversion source again. Maybe you can try this. -- Xiaofan http://mcuee.blogspot.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] rev1910 - unable to compile with ftd2xx enabled
Hi all, I'm unable to compile latest trunk with ftd2xx library. Linker fails with the following error: make[3]: Entering directory `/usr/src/openocd/trunk/src' /bin/sh ../libtool --tag=CC --mode=link gcc -std=gnu99 -g -O2 -I/home/vylu/downloads/ftd2xx/extracted/libftd2xx0.4.16_x86_64 -Wall -Wstrict-prototypes -Wformat-security -Wextra -Wno-unused-parameter -Wbad-function-cast -Wcast-align -Wredundant-decls -Werror -o openocd main.o libopenocd.la -ldl /home/vylu/downloads/ftd2xx/extracted/libftd2xx0.4.16_x86_64/static_lib/libftd2xx.a.0.4.16 -lpthread gcc -std=gnu99 -g -O2 -I/home/vylu/downloads/ftd2xx/extracted/libftd2xx0.4.16_x86_64 -Wall -Wstrict-prototypes -Wformat-security -Wextra -Wno-unused-parameter -Wbad-function-cast -Wcast-align -Wredundant-decls -Werror -o .libs/openocd main.o /home/vylu/downloads/ftd2xx/extracted/libftd2xx0.4.16_x86_64/static_lib/libftd2xx.a.0.4.16 ./.libs/libopenocd.so -ldl -lpthread ./.libs/libopenocd.so: undefined reference to `FT_GetLatencyTimer' ./.libs/libopenocd.so: undefined reference to `FT_Close' ./.libs/libopenocd.so: undefined reference to `FT_SetBitMode' ./.libs/libopenocd.so: undefined reference to `FT_OpenEx' ./.libs/libopenocd.so: undefined reference to `FT_Read' ./.libs/libopenocd.so: undefined reference to `FT_SetTimeouts' ./.libs/libopenocd.so: undefined reference to `FT_SetVIDPID' ./.libs/libopenocd.so: undefined reference to `FT_Write' ./.libs/libopenocd.so: undefined reference to `FT_SetLatencyTimer' ./.libs/libopenocd.so: undefined reference to `FT_ListDevices' ./.libs/libopenocd.so: undefined reference to `FT_Purge' collect2: ld returned 1 exit status . etc. configure script parameters are: ./configure --enable-maintainer-mode --enable-ft2232_ftd2xx --with-ftd2xx-linux-tardir=/home/vylu/downloads/ftd2xx/extracted/libftd2xx0.4.16_x86_64 Are the latest revisions broken, or I just use wrong configure instructions? Regards, vylu ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] PATCH] [0/3] cfi x16_as_x8 implementation.
On Friday 22 May 2009 20:16:14 Michael Schwingen wrote:
> Raúl Sánchez Siles wrote:
> > Hello all:
> >
> > This start a patchset series for implementing x16_as_x8 cfi compliant
> > feature.
> >
> > · 01-x16_as_x8-consolidate_addresses.patch
> > · 02-x16_as_x8-flash_address.patch
> > · 03-x16_as_x8-multibyte_read.patch
> >
> > I have taken a view to the CFI specification [0] and it looks that the
> > approach should also work for intel chips, while I had only tested it
> > with spansion flash.
>
> That looks good to me - I would have expected a lot more changes.
>
> Some style comments:
> - I do not really like left shifts with what is effectively a bool
> variable as shift amount ("bank->bus_width << cfi_info->x16_as_x8"). The
> logic is correct, but it looks strange.
>
> - In cfi.c, I think we should always use a loop of single-byte reads
> instead of using separate code for the x16_as_x8 and the "normal" case.
> Using the single-byte reads should be safe on wider bus/flash widths,
> and would make one code path that is better tested.
>
> cu
> Michael
>
I see, thanks for reviewing. Now that's committed and since those comments
won't change behaviour I'll review the current style I've used to take that
into account. I'll see what I can do.
Regards,
--
Raúl Sánchez Siles
Departamento de Montaje
INFOGLOBAL, S. A.
* C/ Virgilio, 2. Ciudad de la Imagen.
28223 Pozuelo de Alarcón (Madrid), España
* T: +34 91 506 40 00
* F: +34 91 506 40 01
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
