[Openocd-development] [patch] add overridable Tcl "init_reset"
This abstracts the "jtag arp_init-reset" call into a method
called from OpenOCD startup and reset processing.
Platforms which have different requirements for how such hard
resets must be performed can now override "init_reset" instead
of needing to rebuild custom hacked versions of the server.
---
NEWS |1 +
src/helper/startup.tcl | 29 +
2 files changed, 22 insertions(+), 8 deletions(-)
--- a/NEWS
+++ b/NEWS
@@ -8,6 +8,7 @@ JTAG Layer:
New reset_config options for SRST gating the JTAG clock (or not)
TAP declaration no longer requires ircapture and mask attributes
New "post-reset" event handler for TAP-invariant setup code
+Overridable Tcl "init_reset" and "jtag_init" procedures
Target Layer:
New commands for use with Cortex-M3 processors:
--- a/src/helper/startup.tcl
+++ b/src/helper/startup.tcl
@@ -134,6 +134,23 @@ proc ocd_gdb_restart {target_id} {
reset halt
}
+
+# This reset logic may be overridden by board/target/... scripts as needed
+# to provide a reset that, if possible, is close to a power-up reset.
+#
+# Exit requirements include: (a) JTAG must be working, (b) the scan
+# chain was validated with "jtag arp_init" (or equivalent), (c) nothing
+# stays in reset. No TAP-specific scans were performed. It's OK if
+# some targets haven't been reset yet; they may need TAP-specific scans.
+#
+# The "mode" values include: halt, init, run (from "reset" command);
+# startup (at OpenOCD server startup, when JTAG may not yet work); and
+# potentially more (for reset types like cold, warm, etc)
+proc init_reset { mode } {
+ jtag arp_init-reset
+}
+
+
global in_process_reset
set in_process_reset 0
@@ -189,10 +206,7 @@ proc ocd_process_reset_inner { MODE } {
# Use TRST or TMS/TCK operations to reset all the tap controllers.
# TAP reset events get reported; they might enable some taps.
- #
- # REVISIT arp_init-reset pulses SRST (if it can) with TRST active;
- # but SRST events aren't reported (unlike "jtag arp_reset", below)
- jtag arp_init-reset
+ init_reset $MODE
# Examine all targets on enabled taps.
foreach t $targets {
@@ -361,11 +375,11 @@ proc capture_catch {a} {
}
-# Executed during "init". Can be implemented by target script
-# tar
+# Executed during "init". Can be overridden
+# by board/target/... scripts
proc jtag_init {} {
if {[catch {jtag arp_init} err]!=0} {
# try resetting additionally
- jtag arp_init-reset
+ init_reset startup
}
-}
\ No newline at end of file
+}
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [patch] make PXA255 targets enumerate sort-of-OK
Startup now mostly works, except that the initial target state
is "unknown" ... previously, it refused to even start.
Getting that far required fixing the ircapture value (which
can never have been correct!) and the default JTAG clock rate,
then providing custom reset script.
The "reset" command is still iffy. DCSR updates, and loading
the debug handler, report numerous DR/IR capture failures.
But once that's done, "poll" reports that the CPU is halted
(which it shouldn't be, this was "reset run"!), due to the
rather curious reason "target-not-halted".
---
Summary: you still can't debug these parts, but it's closer.
NEWS |1 +
tcl/target/pxa255.cfg | 35 ---
2 files changed, 33 insertions(+), 3 deletions(-)
--- a/NEWS
+++ b/NEWS
@@ -39,6 +39,7 @@ Board, Target, and Interface Configurati
Samsung s3c2450
Mini2440 board
Numeric TAP and Target identifiers now trigger warnings
+PXA255 partially enumerates
Documentation:
Capture more debugging and setup advice
--- a/tcl/target/pxa255.cfg
+++ b/tcl/target/pxa255.cfg
@@ -19,8 +19,37 @@ if { [info exists CPUTAPID ] } {
set _CPUTAPID 0x69264013
}
-jtag newtap $_CHIPNAME cpu -irlen 5 -ircapture 0x1e -irmask 0x1f -expected-id
$_CPUTAPID
+jtag newtap $_CHIPNAME cpu -irlen 5 -expected-id $_CPUTAPID
set _TARGETNAME $_CHIPNAME.cpu
-target create $_TARGETNAME xscale -endian $_ENDIAN -chain-position $_TARGETNAME
-debug_level 3
+target create $_TARGETNAME xscale -endian $_ENDIAN \
+ -chain-position $_CHIPNAME.cpu
+
+# PXA255 comes out of reset using 3.6864 MHz oscillator.
+# Until the PLL kicks in, keep the JTAG clock slow enough
+# that we get no errors.
+jtag_khz 300
+$_TARGETNAME configure -event "reset-start" { jtag_khz 300 }
+
+# reset processing that works with PXA
+proc init_reset {mode} {
+ # assert both resets; equivalent to power-on reset
+ jtag_reset 1 1
+
+ # drop TRST after at least 32 cycles
+ sleep 1
+ jtag_reset 0 1
+
+ # minimum 32 TCK cycles to wake up the controller
+ runtest 50
+
+ # now the TAP will be responsive; validate scanchain
+ jtag arp_init
+
+ # ... and take it out of reset
+ jtag_reset 0 0
+}
+
+proc jtag_init {} {
+ init_reset startup
+}
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Cross compiler for ARM7 bare metal
On Thursday 08 October 2009, Jon Smirl wrote: > >> Right; and does the CodeSourcery uCLinux version help at all? > > > > I'm still building it. They only had 32b pre-built binaries and I'm running > > 64b. > > I gave up fixing build problems on Ubuntu. Now I'm seeing if I can get > the 32b binaries working. Yeah, I just use the pre-build 32-bit binaries even on 64-bit boxen. I probably lose minutes a day! ;) ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] openocd-svn enabled with GIT (was Re: openocd-svn mailing list retired)
On Thu, 2009-10-08 at 08:43 +0200, Øyvind Harboe wrote: > > After posting, I did some research and found there is a standard script > > that can be integrated as a hook. I can try to figure out the best way > > to enable it for our purposes. Do we want to start a new list for it, > > or should we live with the existing openocd-svn list? > > Use openocd-svn mailing list until we decide on what to do long term > with mailing lists. I have set up a post-receive hook in the SF.net repository, so we should start to see git commit messages appear on the openocd-svn mailing list. If there are problems with your next push, this might be the reason. Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Cross compiler for ARM7 bare metal
On Fri, Oct 9, 2009 at 1:01 AM, Jon Smirl wrote: > On Fri, Oct 9, 2009 at 12:56 AM, David Brownell wrote: >> On Thursday 08 October 2009, Jon Smirl wrote: >>> libc is the problem. >> >> Right; and does the CodeSourcery uCLinux version help at all? > > I'm still building it. They only had 32b pre-built binaries and I'm running > 64b. I gave up fixing build problems on Ubuntu. Now I'm seeing if I can get the 32b binaries working. > >> >> If you're doing that kind of not-quite-bare metal work, I'd >> expect you would need a semicustom libc. >> >> - Dave >> >> > > > > -- > Jon Smirl > jonsm...@gmail.com > -- Jon Smirl jonsm...@gmail.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Cross compiler for ARM7 bare metal
Have a look at http://opensource.zylin.com/gccbinary.html -- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Cross compiler for ARM7 bare metal
On Fri, Oct 9, 2009 at 12:56 AM, David Brownell wrote: > On Thursday 08 October 2009, Jon Smirl wrote: >> libc is the problem. > > Right; and does the CodeSourcery uCLinux version help at all? I'm still building it. They only had 32b pre-built binaries and I'm running 64b. > > If you're doing that kind of not-quite-bare metal work, I'd > expect you would need a semicustom libc. > > - Dave > > -- Jon Smirl jonsm...@gmail.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Cross compiler for ARM7 bare metal
On Thu, Oct 8, 2009 at 7:02 PM, David Brownell wrote: > On Thursday 08 October 2009, Michel Catudal wrote: >> An arm-linux-gcc is only for Linux based system, not bare metal stuff. > > Depends what you mean by "bare metal". > > I use "arm-none-linux-gnueabi-gcc" all the time to compile > Linux kernels; and sometimes for U-Boot, or stuff running > on Cortex-M3. By any reasonable definition all of that > counts as "bare metal". I'm building Contiki on the MC1322x. Contiki has things like exit() and snprintf() in it. Use the ARM9 compiler in OpenEmbedded those routines link to glibc and it brings in 900KB of code. So I have a working compiler, I just don't have a reasonable libc. > > So far as I can tell, all those compilers will work fine > in that mode: tell it to ignore all system libraries, not > to use dynamic linking, and get friendly with linker config > scripts ... and there will be no problem sticking the reset > vectors , code in NOR flash (or SRAM), etc. > You'd have to work hard to get that to break, as I understand > things. > > Now, the *libc* stuff is a more confusing story. Bare > metal has no file system, so fopen() raises conceptual > problems. Doesn't even have stdout, so printf() has > the same kind of problems. No network stack; socket() > is not gonna work either. But stuff like strcpy() can > work, vsnprintf(), and given some help you can even have > malloc() and free(). That's all system library stuff > though. libc is the problem. > > - Dave > > ___ > Openocd-development mailing list > Openocd-development@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/openocd-development > -- Jon Smirl jonsm...@gmail.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Cross compiler for ARM7 bare metal
On Thursday 08 October 2009, Jon Smirl wrote: > libc is the problem. Right; and does the CodeSourcery uCLinux version help at all? If you're doing that kind of not-quite-bare metal work, I'd expect you would need a semicustom libc. - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Cross compiler for ARM7 bare metal
On Thu, Oct 8, 2009 at 7:13 PM, Duane Ellis wrote: > Jon Smirl wrote: >> >> Can someone help me out and point me to a working cross toolchain for >> arm7tdmi with uclibc or equivalent on Linux? I've got a working glib >> setup but it keeps linking in 900KB of run-time code. >> >> I've spent all day searching and playing with buildroot and I can't >> achieve a working environment. >> >> > > Take a look at > > http://lostarm.sf.net > > It builds a *COMPLETE* gnu gcc tool chain for ARM7TDMI - bare metal, it uses > NEWLIB for the C-Library This won't build on Unbuntu 9.04 with the current gcc. Doesn't look like serious problems but I'll try CodeSourcery next. > > It uses an older version of GCC, to be honest with you, there are *little* > if any benefit you will get if you _really_ want a new version. > > The example target is an ATMEL at91sam7x256 - but it is very generic. > > -Duane. > > > -- Jon Smirl jonsm...@gmail.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Cross compiler for ARM7 bare metal
On Thursday 08 October 2009, Michel Catudal wrote: > > It uses an older version of GCC, to be honest with you, there are > > *little* if any benefit you will get if you _really_ want a new version. > > > > > You're kidding are you? > There are many benefits to the newer compilers, including support for > newer devices. > The old stuff is completely useless for Cortex-M3 or Cortex-A8 But $SUBJECT specfied ARM7, specifically ARM7TDMI, not Cortex. Hardly new. I have no doubt that there have been some changes in code generation in more recent GCC versions. And likewise, I know that some of the changes were not *improvements* in terms of ARM codegen, so that some folk resisted GCC upgrades... I believe that the GCC folk will improve those codegen goofs over time, but it takes time to adapt to the back-end changes which have been filtering in, and tweak things to work as well on ARM as on, say, x86 (which gets more attention). - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] retiring old services
On Thursday 08 October 2009, Nicolas Pitre wrote: > Now let's hope that the move to Git will allow proper patch attributions > to be recorded in the repository, instead of only committer information > as it was the case with SVN (attribution in the commit log isn't good > enough). that would allow for 'blame' to work properly which helps a > lot when it's time to CC the biggest contributor of a file (which > usually happens to be the best person to review the patch). For patches I merge, I'll be aiming to use git-am and preserve those attributions. And I hope other committers will be doing the same thing ... Of course it's only been about a day now that we've been using GIT! :) Agreed that patch discipline like CCing reviewers would probably be a Good Thing to evolve. - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Cross compiler for ARM7 bare metal
Le 08/10/2009 19:13, Duane Ellis a écrit : > > > Take a look at > > http://lostarm.sf.net > > That is very old stuff It is easier to download mine or create your own with my source files. I use the latest 4.4.1 code. > It builds a *COMPLETE* gnu gcc tool chain for ARM7TDMI - bare metal, it > uses NEWLIB for the C-Library > > It uses an older version of GCC, to be honest with you, there are > *little* if any benefit you will get if you _really_ want a new version. > > You're kidding are you? There are many benefits to the newer compilers, including support for newer devices. The old stuff is completely useless for Cortex-M3 or Cortex-A8 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] Cross compiler for ARM7 bare metal
Le 08/10/2009 19:02, David Brownell a écrit : > On Thursday 08 October 2009, Michel Catudal wrote: > >> An arm-linux-gcc is only for Linux based system, not bare metal stuff. >> > Depends what you mean by "bare metal". > > I use "arm-none-linux-gnueabi-gcc" all the time to compile > Linux kernels; and sometimes for U-Boot, or stuff running > on Cortex-M3. By any reasonable definition all of that > counts as "bare metal". > > It is easier just to create 2 different compilers, one with libc and one with newlib > So far as I can tell, all those compilers will work fine > in that mode: tell it to ignore all system libraries, not > to use dynamic linking, and get friendly with linker config > scripts ... and there will be no problem sticking the reset > vectors, code in NOR flash (or SRAM), etc. > You'd have to work hard to get that to break, as I understand > things. > > Now, the *libc* stuff is a more confusing story. Bare > metal has no file system, so fopen() raises conceptual > problems. Not always true, with the software I got from Atmel for the AVR32 U3 devices they have FAT a library > Doesn't even have stdout, so printf() has > the same kind of problems. No network stack; socket() > is not gonna work either. But stuff like strcpy() can > work, vsnprintf(), and given some help you can even have > malloc() and free(). That's all system library stuff > though. > > - Dave > They do in newlib but that is bloated stuff which I never use. 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] retiring old services
On Thu, 2009-10-08 at 00:08 -0700, Zach Welch wrote: > On Wed, 2009-10-07 at 22:32 -0700, Zach Welch wrote: > > Hi all, > > > > Some off-list discussion during the recent outage brought up the idea of > > streamlining the BerliOS project site. Here are the list of services > > that the maintainers want to deactivate, with suggested alternatives: > > > > - Disable Bug Tracker and Bug Dependency List, Support, Forums, > > Patch Manager, and Feature Requests: post to the mailing list > > - Disable Screenshots: we can put such content on the web site > > - Disable Doc Manager: we provide access to such with Doxygen+web > > - Disable Donations: this appears to be a "WONT FIX" with BerliOS > > > > This leaves BerliOS with Mailing Lists, File Releases, and WordPress. > > I will be sure to migrate any useful content into the repository, if any > > still needs it. Are there any strong objections to these plans? > > Here is the content that seems to deserve to be merged into the > repository. Could others verify that these have not been addressed and > deserve to be merged? The first seems easy and relatively acceptable, > but the others may have been handled in other ways. > > Bugs, Features, and Patches: > - Flash Shevaplug U-Boot: > - > https://developer.berlios.de/bugs/?func=detailbug&bug_id=16028&group_id=4148 > - > https://developer.berlios.de/patch/?func=detailpatch&patch_id=2792&group_id=4148 > - Resume after breakpoint on X-Scale: > - > https://developer.berlios.de/bugs/?func=detailbug&bug_id=15867&group_id=4148 > - Improve interactive support (e.g. 'pause', etc.). > - > https://developer.berlios.de/feature/?func=detailfeature&feature_id=4086&group_id=4148 I have closed out all of the open issues and retired these systems, committing and pushing the sheevaplug patch. I have also posted a message to WordPress to notify users of these changes. Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] retiring old services
On Thu, 8 Oct 2009, David Brownell wrote: > On Thursday 08 October 2009, Nicolas Pitre wrote: > > > > > For the XScale and Sheevaplug things, I suggest Nicolas Pitre > > > tell us what to do. > > > > I don't know anything about OpenOCD and XScale ((I guess that should be > > Øyvind). > > I was thinking XScale ~= Marvell and that you've > recently been affiliated there ... but if you're > no longer the XScale guru you once were, that's > understandable. ;) Yep. Life moved on. Eric Miao is Linux PXA guru these days. but I never got involved with OpenOCd+XScale though. > > That's a classical problem with patch tracking systems. they get > > cluttered with patches that become outdated and/or obsolete. > > Which is why Linux uses mailing lists and relies on > reposting, instead of a database that needs much more > attention than is available. Yep. And so does git and other projects. Now let's hope that the move to Git will allow proper patch attributions to be recorded in the repository, instead of only committer information as it was the case with SVN (attribution in the commit log isn't good enough). that would allow for 'blame' to work properly which helps a lot when it's time to CC the biggest contributor of a file (which usually happens to be the best person to review the patch). For example, I'd be interested to be CC'd on Feroceon related patches, otherwise chances for me to miss them are much greater. Nicolas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] retiring old services
On Thursday 08 October 2009, Nicolas Pitre wrote: > > > For the XScale and Sheevaplug things, I suggest Nicolas Pitre > > tell us what to do. > > I don't know anything about OpenOCD and XScale ((I guess that should be > Øyvind). I was thinking XScale ~= Marvell and that you've recently been affiliated there ... but if you're no longer the XScale guru you once were, that's understandable. ;) > That's a classical problem with patch tracking systems. they get > cluttered with patches that become outdated and/or obsolete. Which is why Linux uses mailing lists and relies on reposting, instead of a database that needs much more attention than is available. - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Cross compiler for ARM7 bare metal
Jon Smirl wrote: > Can someone help me out and point me to a working cross toolchain for > arm7tdmi with uclibc or equivalent on Linux? I've got a working glib > setup but it keeps linking in 900KB of run-time code. > > I've spent all day searching and playing with buildroot and I can't > achieve a working environment. > > Take a look at http://lostarm.sf.net It builds a *COMPLETE* gnu gcc tool chain for ARM7TDMI - bare metal, it uses NEWLIB for the C-Library It uses an older version of GCC, to be honest with you, there are *little* if any benefit you will get if you _really_ want a new version. The example target is an ATMEL at91sam7x256 - but it is very generic. -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] retiring old services
On Thu, 8 Oct 2009, David Brownell wrote: > On Thursday 08 October 2009, Zach Welch wrote: > > - Improve interactive support (e.g. 'pause', etc.). > > - > > https://developer.berlios.de/feature/?func=detailfeature&feature_id=4086&group_id=4148 > > pause ~= sleep > text output == echo > > ... close this "feature request" as resolved. > > > For the XScale and Sheevaplug things, I suggest Nicolas Pitre > tell us what to do. I don't know anything about OpenOCD and XScale ((I guess that should be Øyvind). As for the sheevaPlug patch, I don't mind if it is applied... although the 0x4 for the size looks suspicious to me (why not 0x2?). > In general I'd be inclined to close many of those patches > with some kind of "resubmit the normal way if this is still > a problem" status. There are several patches for random > JTAG adapters, which surely need updating and re-testing > by someone who actually has that hardware ... That's a classical problem with patch tracking systems. they get cluttered with patches that become outdated and/or obsolete. Also if there is no one to actually do the patch assignment then I certainly won't go have a look periodically just in case some random patch could interest me. Nicolas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Cross compiler for ARM7 bare metal
On Thursday 08 October 2009, Michel Catudal wrote: > An arm-linux-gcc is only for Linux based system, not bare metal stuff. Depends what you mean by "bare metal". I use "arm-none-linux-gnueabi-gcc" all the time to compile Linux kernels; and sometimes for U-Boot, or stuff running on Cortex-M3. By any reasonable definition all of that counts as "bare metal". So far as I can tell, all those compilers will work fine in that mode: tell it to ignore all system libraries, not to use dynamic linking, and get friendly with linker config scripts ... and there will be no problem sticking the reset vectors , code in NOR flash (or SRAM), etc. You'd have to work hard to get that to break, as I understand things. Now, the *libc* stuff is a more confusing story. Bare metal has no file system, so fopen() raises conceptual problems. Doesn't even have stdout, so printf() has the same kind of problems. No network stack; socket() is not gonna work either. But stuff like strcpy() can work, vsnprintf(), and given some help you can even have malloc() and free(). That's all system library stuff though. - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Cross compiler for ARM7 bare metal
Le 08/10/2009 18:13, David Brownell a écrit : > On Thursday 08 October 2009, Jon Smirl wrote: > >> Can someone help me out and point me to a working cross toolchain for >> arm7tdmi with uclibc or equivalent on Linux? I've got a working glib >> setup but it keeps linking in 900KB of run-time code. >> >> I've spent all day searching and playing with buildroot and I can't >> achieve a working environment. >> > I've usually had bad luck with buildroot too. > > Does the CodeSourcery LITE uCLinux toolchain behave for you? > > http://www.codesourcery.com/sgpp/lite/arm/portal/subscripti...@template=lite > > > An arm-linux-gcc is only for Linux based system, not bare metal stuff. There is arm-elf-gcc for that, like the ones on my website, I don't charge anything for it. I run out of space so I don't have very many Linux distribution versions on my website. 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] Cross compiler for ARM7 bare metal
On Thursday 08 October 2009, Jon Smirl wrote: > Can someone help me out and point me to a working cross toolchain for > arm7tdmi with uclibc or equivalent on Linux? I've got a working glib > setup but it keeps linking in 900KB of run-time code. > > I've spent all day searching and playing with buildroot and I can't > achieve a working environment. I've usually had bad luck with buildroot too. Does the CodeSourcery LITE uCLinux toolchain behave for you? http://www.codesourcery.com/sgpp/lite/arm/portal/subscripti...@template=lite ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Cross compiler for ARM7 bare metal
Can someone help me out and point me to a working cross toolchain for arm7tdmi with uclibc or equivalent on Linux? I've got a working glib setup but it keeps linking in 900KB of run-time code. I've spent all day searching and playing with buildroot and I can't achieve a working environment. -- Jon Smirl jonsm...@gmail.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] Updated omap3530 .cfg with improved reset handling
On Wednesday 30 September 2009, Magnus Lundin wrote:
>
> >> +omap3.cpu configure -event reset-start "omap3.cpu mww $PRM_RSTCTRL 2"
> >> +omap3.cpu configure -event reset-end "omap3_dbginit"
> >>
> >
> > Isn't there a chicken/egg thing having "omap3.cpu mww ..." do
> > its thing without having forcibly enabled the TAP, which is
> > done early in omap3_dbginit?
>
> Yes there is, but I think that when we connect to a target we just do
> omap3_dbginit right after init,
The new "setup" TAP event kicks in on both server startup
("connect to target") and reset code paths. On DaVinci it
works well as the place to "jtag tapenable $THE_ARM" to
make the ICEpick do its enable dance. OMAP3 too?
I'm thinking one of these days there should be some scan chain
verification done after tap enable/disable. Now that the TLR
has been removed, I think jtag_validate_ircapture() is a good
candidate. Something to validate an IDCODE would be good too,
but for now we don't know its opcode.
> with no reset as default. We do not always want to reset the whole
> system at every connection, for instance when debugging a running
> Linux kernel or applications.
Certainly not! :)
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Moving to git
On Wed, 7 Oct 2009, Raúl Sánchez Siles wrote: > I said I didn't want to start a flamewar and provided there has been, at > least, a slight interest on my messages, I'll try to clear up some point and > leave the thread alone. I cannot resist correcting you on one point though. [...] > That benchmark is not taking into account wire protocol, very important for > operations like clone, where I think Mercurial is more efficient. All VCS comparisons (and not only DVCS_ I've seen, Git always came out as having the tightest repository format, better than CVS, svN, HG, Bazaar, etc. And git uses the same format on thewire for clone transfer or even for bringing your local copy up to date. And I happen to know a bit about this since a significant part of the Git code involved in transfer operations is actually mine. So I don't really believe that Mercurial is more efficient in that regard. Nicolas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Eclipse git gui
The git gui itself is probably a bit nicer. Myself, I always use the git command line tools, though I find gitk indispensible as a roadmap. To try the git gui, type "git gui" at the command line. Oh, and it works perfectly in cygwin, and identically in Linux. - Alex > -Original Message- > From: openocd-development-boun...@lists.berlios.de [mailto:openocd- > development-boun...@lists.berlios.de] On Behalf Of Øyvind Harboe > Sent: Thursday, October 08, 2009 8:38 AM > To: openocd-development@lists.berlios.de > Subject: [Openocd-development] Eclipse git gui > > I'm using the Eclipse git GUI now. > > It feels pretty awkward and minimalistic, but is robust so far and > can probably cope with some of the most common operations. > > It seems to behave well if I do some tasks in shell and some > in Eclipse. Note, I'm running Ubuntu/Linux. I shudder at > the thought of trying to pull that off w/Cygwin... > > The awkward bit is also because it will take quite a bit of time > before my brain immune system stops rejecting git concepts :-) > > > http://www.eclipse.org/egit/ > > Checking out a project is a bit different than svn obviously: > > - Use File->Import to import the repository > - Create empty project > - Use Team->Share this project to the git repository > > Clearly these guys have some way to go to make this > intuitive, but that's as much due to the very different > nature of git as anything... > > -- > Øyvind Harboe > http://www.zylin.com/zy1000.html > ARM7 ARM9 ARM11 XScale Cortex > JTAG debugger and flash programmer > ___ > 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] retiring old services
On Thursday 08 October 2009, Zach Welch wrote: > - Improve interactive support (e.g. 'pause', etc.). > - > https://developer.berlios.de/feature/?func=detailfeature&feature_id=4086&group_id=4148 pause ~= sleep text output == echo ... close this "feature request" as resolved. For the XScale and Sheevaplug things, I suggest Nicolas Pitre tell us what to do. In general I'd be inclined to close many of those patches with some kind of "resubmit the normal way if this is still a problem" status. There are several patches for random JTAG adapters, which surely need updating and re-testing by someone who actually has that hardware ... Though #856 look wrong, whatever it was trying to do. :) ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [patch] prevent abort via polling during jtag_reset
Observed:
openocd: core.c:318: jtag_checks: Assertion `jtag_trst == 0' failed.
The issue was that nothing disabled background polling during calls
from the TCL shell to "jtag_reset 1 1". Fix by moving the existing
poll-disable mechanism to the JTAG layer where it belongs, and then
augmenting it to always pay attention to TRST and SRST.
---
src/jtag/core.c | 26 ++
src/jtag/jtag.h | 17 +
src/target/target.c | 17 -
3 files changed, 51 insertions(+), 9 deletions(-)
--- a/src/jtag/core.c
+++ b/src/jtag/core.c
@@ -137,6 +137,32 @@ int jtag_error_clear(void)
return temp;
}
+//
+
+static bool jtag_poll = 1;
+
+bool is_jtag_poll_safe(void)
+{
+ /* Polling can be disabled explicitly with set_enabled(false).
+* It is also implicitly disabled while TRST is active and
+* while SRST is gating the JTAG clock.
+*/
+ if (!jtag_poll || jtag_trst != 0)
+ return false;
+ return jtag_srst == 0 || (jtag_reset_config & RESET_SRST_NO_GATING);
+}
+
+bool jtag_poll_get_enabled(void)
+{
+ return jtag_poll;
+}
+
+void jtag_poll_set_enabled(bool value)
+{
+ jtag_poll = value;
+}
+
+//
jtag_tap_t *jtag_all_taps(void)
{
--- a/src/jtag/jtag.h
+++ b/src/jtag/jtag.h
@@ -737,4 +737,21 @@ int jtag_get_error(void);
*/
int jtag_error_clear(void);
+/**
+ * Return true if it's safe for a background polling task to access the
+ * JTAG scan chain. Polling may be explicitly disallowed, and is also
+ * unsafe while nTRST is active or the JTAG clock is gated off.,
+ */
+bool is_jtag_poll_safe(void);
+
+/**
+ * Return flag reporting whether JTAG polling is disallowed.
+ */
+bool jtag_poll_get_enabled(void);
+
+/**
+ * Assign flag reporting whether JTAG polling is disallowed.
+ */
+void jtag_poll_set_enabled(bool value);
+
#endif /* JTAG_H */
--- a/src/target/target.c
+++ b/src/target/target.c
@@ -269,8 +269,6 @@ static int new_target_number(void)
return x + 1;
}
-static int target_continuous_poll = 1;
-
/* read a uint32_t from a buffer in target memory endianness */
uint32_t target_buffer_get_u32(target_t *target, const uint8_t *buffer)
{
@@ -436,13 +434,14 @@ int target_process_reset(struct command_
* more predictable, i.e. dr/irscan & pathmove in events will
* not have JTAG operations injected into the middle of a sequence.
*/
- int save_poll = target_continuous_poll;
- target_continuous_poll = 0;
+ bool save_poll = jtag_poll_get_enabled();
+
+ jtag_poll_set_enabled(false);
sprintf(buf, "ocd_process_reset %s", n->name);
retval = Jim_Eval(interp, buf);
- target_continuous_poll = save_poll;
+ jtag_poll_set_enabled(save_poll);
if (retval != JIM_OK) {
Jim_PrintErrorMessage(interp);
@@ -1726,7 +1725,7 @@ int handle_target(void *priv)
* Skip targets that are currently disabled.
*/
for (target_t *target = all_targets;
- target_continuous_poll && target;
+ is_jtag_poll_safe() && target;
target = target->next)
{
if (!target->tap->enabled)
@@ -1886,7 +1885,7 @@ static int handle_poll_command(struct co
if (argc == 0)
{
command_print(cmd_ctx, "background polling: %s",
- target_continuous_poll ? "on" : "off");
+ jtag_poll_get_enabled() ? "on" : "off");
command_print(cmd_ctx, "TAP: %s (%s)",
target->tap->dotted_name,
target->tap->enabled ? "enabled" : "disabled");
@@ -1902,11 +1901,11 @@ static int handle_poll_command(struct co
{
if (strcmp(args[0], "on") == 0)
{
- target_continuous_poll = 1;
+ jtag_poll_set_enabled(true);
}
else if (strcmp(args[0], "off") == 0)
{
- target_continuous_poll = 0;
+ jtag_poll_set_enabled(false);
}
else
{
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [patch] Stop ignoring most scan chain validation errors
Among other things this causes startup errors to kick in the
fallback "reset harder" logic during server startup. Comments
are also updated a bit, explaining what the various error paths
signify (in at least my observation).
There's one clss of validation error that we can plausibly ignore:
when wrong IDCODE values are observed.
This change seems to have helped make an OMAP5912 behave much
more reliably. There's still some post-reset flakiness, but
it's unrelated to scan verification.
---
src/jtag/core.c | 64 +-
src/jtag/jtag.h |1
2 files changed, 50 insertions(+), 15 deletions(-)
--- a/src/jtag/core.c
+++ b/src/jtag/core.c
@@ -892,7 +892,15 @@ static bool jtag_examine_chain_check(uin
}
/* if there wasn't a single non-zero bit or if all bits were one,
-* the scan is not valid */
+* the scan is not valid. We wrote a mix of both values; either
+*
+* - There's a hardware issue (most likely):
+* + all-zeroes can mean a target stuck in JTAG reset
+* + all-ones tends to mean no target
+* - The scan chain is WAY longer than we can handle, *AND* either
+* + there are several hundreds of TAPs in bypass, or
+* + at least a few dozen TAPs all have an all-ones IDCODE
+*/
if (zero_check == 0x00 || one_check == 0xff)
{
LOG_ERROR("JTAG scan chain interrogation failed: all %s",
@@ -988,11 +996,14 @@ static int jtag_examine_chain(void)
{
uint8_t idcode_buffer[JTAG_MAX_CHAIN_SIZE * 4];
unsigned bit_count;
+ int retval;
/* DR scan to collect BYPASS or IDCODE register contents.
* Then make sure the scan data has both ones and zeroes.
*/
- jtag_examine_chain_execute(idcode_buffer, JTAG_MAX_CHAIN_SIZE);
+ retval = jtag_examine_chain_execute(idcode_buffer, JTAG_MAX_CHAIN_SIZE);
+ if (retval != ERROR_OK)
+ return retval;
if (!jtag_examine_chain_check(idcode_buffer, JTAG_MAX_CHAIN_SIZE))
return ERROR_JTAG_INIT_FAILED;
@@ -1012,7 +1023,7 @@ static int jtag_examine_chain(void)
if ((idcode & 1) == 0)
{
- /* LSB must not be 0, this indicates a device in bypass
*/
+ /* Zero for LSB indicates a device in bypass */
LOG_WARNING("TAP %s does not have IDCODE",
tap->dotted_name);
idcode = 0;
@@ -1024,7 +1035,8 @@ static int jtag_examine_chain(void)
{
/* Friendly devices support IDCODE */
tap->hasidcode = true;
- jtag_examine_chain_display(LOG_LVL_INFO, "tap/device
found",
+ jtag_examine_chain_display(LOG_LVL_INFO,
+ "tap/device found",
tap->dotted_name, idcode);
bit_count += 32;
@@ -1033,7 +1045,7 @@ static int jtag_examine_chain(void)
/* ensure the TAP ID matches what was expected */
if (!jtag_examine_chain_match_tap(tap))
- return ERROR_JTAG_INIT_FAILED;
+ retval = ERROR_JTAG_INIT_SOFT_FAIL;
}
/* Fail if too many TAPs were enabled for us to verify them all. */
@@ -1049,11 +1061,14 @@ static int jtag_examine_chain(void)
if (jtag_examine_chain_end(idcode_buffer, bit_count,
8 * sizeof(idcode_buffer))) {
LOG_ERROR("double-check your JTAG setup (interface, "
- "speed, TAPs, ...)");
+ "speed, missing TAPs, ...)");
return ERROR_JTAG_INIT_FAILED;
}
- return ERROR_OK;
+ /* Return success or, for backwards compatibility if only
+* some IDCODE values mismatched, a soft/continuable fault.
+*/
+ return retval;
}
/*
@@ -1255,18 +1270,37 @@ int jtag_init_inner(struct command_conte
if ((retval = jtag_execute_queue()) != ERROR_OK)
return retval;
- /* examine chain first, as this could discover the real chain layout */
- if (jtag_examine_chain() != ERROR_OK)
- {
+ /* Examine DR values first. This discovers problems which will
+* prevent communication ... hardware issues like TDO stuck, or
+* configuring the wrong number of (enabled) TAPs.
+*/
+ retval = jtag_examine_chain();
+ switch (retval) {
+ case ERROR_OK:
+ /* complete success */
+ break;
+ case ERROR_JTAG_INIT_SOFT_FAIL:
+ /* For backward compatibility reasons, try coping with
+* configuration errors involving only ID mismatches.
+* We might be able to talk to the devices.
+
Re: [Openocd-development] jtag_init changes
On Tuesday 06 October 2009, Øyvind Harboe wrote: > >> if (jtag_init_inner(cmd_ctx) == ERROR_OK) > > > > What would you think about changing init_inner() so it > > actually *fails* when significant errors are detected? > > Now that there is a tcl proc that can be changed for > a particular target if need be, I think that makes sense > as a default. OK, patch forthcoming. Seems to have improved behavior in several respects. - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Eclipse git gui
I'm using the Eclipse git GUI now. It feels pretty awkward and minimalistic, but is robust so far and can probably cope with some of the most common operations. It seems to behave well if I do some tasks in shell and some in Eclipse. Note, I'm running Ubuntu/Linux. I shudder at the thought of trying to pull that off w/Cygwin... The awkward bit is also because it will take quite a bit of time before my brain immune system stops rejecting git concepts :-) http://www.eclipse.org/egit/ Checking out a project is a bit different than svn obviously: - Use File->Import to import the repository - Create empty project - Use Team->Share this project to the git repository Clearly these guys have some way to go to make this intuitive, but that's as much due to the very different nature of git as anything... -- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Stop GDB when polling fails, srst assert or powerdropout is detected
Committed.
--
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer
From 38c9ee7b4fcae126b05fb4ddbaec5fb0362a0b01 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?=C3=98yvind=20Harboe?=
Date: Thu, 8 Oct 2009 14:53:25 +0200
Subject: [PATCH] Stop GDB when polling fails, srst assert or powerdropout is detected
---
src/server/gdb_server.c |2 +-
src/target/target.c | 18 --
src/target/target.h | 10 --
3 files changed, 25 insertions(+), 5 deletions(-)
diff --git a/src/server/gdb_server.c b/src/server/gdb_server.c
index 44d9de8..a0077e9 100644
--- a/src/server/gdb_server.c
+++ b/src/server/gdb_server.c
@@ -714,7 +714,7 @@ int gdb_target_callback_event_handler(struct target_s *target, enum target_event
target_handle_event(target, event);
switch (event)
{
- case TARGET_EVENT_EARLY_HALTED:
+ case TARGET_EVENT_GDB_HALT:
gdb_frontend_halted(target, connection);
break;
case TARGET_EVENT_HALTED:
diff --git a/src/target/target.c b/src/target/target.c
index 0040ba0..253a7e4 100644
--- a/src/target/target.c
+++ b/src/target/target.c
@@ -157,7 +157,7 @@ static const Jim_Nvp nvp_target_event[] = {
{ .value = TARGET_EVENT_OLD_gdb_program_config , .name = "old-gdb_program_config" },
{ .value = TARGET_EVENT_OLD_pre_resume , .name = "old-pre_resume" },
- { .value = TARGET_EVENT_EARLY_HALTED, .name = "early-halted" },
+ { .value = TARGET_EVENT_GDB_HALT, .name = "gdb-halt" },
{ .value = TARGET_EVENT_HALTED, .name = "halted" },
{ .value = TARGET_EVENT_RESUMED, .name = "resumed" },
{ .value = TARGET_EVENT_RESUME_START, .name = "resume-start" },
@@ -821,7 +821,7 @@ int target_call_event_callbacks(target_t *target, enum target_event event)
if (event == TARGET_EVENT_HALTED)
{
/* execute early halted first */
- target_call_event_callbacks(target, TARGET_EVENT_EARLY_HALTED);
+ target_call_event_callbacks(target, TARGET_EVENT_GDB_HALT);
}
LOG_DEBUG("target event %i (%s)",
@@ -1658,6 +1658,15 @@ static int sense_handler(void)
return ERROR_OK;
}
+static void target_call_event_callbacks_all(enum target_event e) {
+ target_t *target;
+ target = all_targets;
+ while (target) {
+ target_call_event_callbacks(target, e);
+ target = target->next;
+ }
+}
+
/* process target state changes */
int handle_target(void *priv)
{
@@ -1676,6 +1685,7 @@ int handle_target(void *priv)
int did_something = 0;
if (runSrstAsserted)
{
+ target_call_event_callbacks_all(TARGET_EVENT_GDB_HALT);
Jim_Eval(interp, "srst_asserted");
did_something = 1;
}
@@ -1686,6 +1696,7 @@ int handle_target(void *priv)
}
if (runPowerDropout)
{
+ target_call_event_callbacks_all(TARGET_EVENT_GDB_HALT);
Jim_Eval(interp, "power_dropout");
did_something = 1;
}
@@ -1726,7 +1737,10 @@ int handle_target(void *priv)
{
/* polling may fail silently until the target has been examined */
if ((retval = target_poll(target)) != ERROR_OK)
+ {
+target_call_event_callbacks(target, TARGET_EVENT_GDB_HALT);
return retval;
+ }
}
}
diff --git a/src/target/target.h b/src/target/target.h
index 0ff2258..6547d4d 100644
--- a/src/target/target.h
+++ b/src/target/target.h
@@ -163,8 +163,14 @@ enum target_event
/* allow GDB to do stuff before others handle the halted event,
* this is in lieu of defining ordering of invocation of events,
- * which would be more complicated */
- TARGET_EVENT_EARLY_HALTED,
+ * which would be more complicated
+ *
+ * Telling GDB to halt does not mean that the target stopped running,
+ * simply that we're dropping out of GDB's waiting for step or continue.
+ *
+ * This can be useful when e.g. detecting power dropout.
+ */
+ TARGET_EVENT_GDB_HALT,
TARGET_EVENT_HALTED, /* target entered debug state from normal execution or reset */
TARGET_EVENT_RESUMED, /* target resumed to normal execution */
TARGET_EVENT_RESUME_START,
--
1.6.0.4
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Do not check ir capture if no IDCODE
I've tested git head today and it works w/iMX35 -- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] retiring old services
On Wed, 2009-10-07 at 22:32 -0700, Zach Welch wrote: > Hi all, > > Some off-list discussion during the recent outage brought up the idea of > streamlining the BerliOS project site. Here are the list of services > that the maintainers want to deactivate, with suggested alternatives: > > - Disable Bug Tracker and Bug Dependency List, Support, Forums, > Patch Manager, and Feature Requests: post to the mailing list > - Disable Screenshots: we can put such content on the web site > - Disable Doc Manager: we provide access to such with Doxygen+web > - Disable Donations: this appears to be a "WONT FIX" with BerliOS > > This leaves BerliOS with Mailing Lists, File Releases, and WordPress. > I will be sure to migrate any useful content into the repository, if any > still needs it. Are there any strong objections to these plans? Here is the content that seems to deserve to be merged into the repository. Could others verify that these have not been addressed and deserve to be merged? The first seems easy and relatively acceptable, but the others may have been handled in other ways. Bugs, Features, and Patches: - Flash Shevaplug U-Boot: - https://developer.berlios.de/bugs/?func=detailbug&bug_id=16028&group_id=4148 - https://developer.berlios.de/patch/?func=detailpatch&patch_id=2792&group_id=4148 - Resume after breakpoint on X-Scale: - https://developer.berlios.de/bugs/?func=detailbug&bug_id=15867&group_id=4148 - Improve interactive support (e.g. 'pause', etc.). - https://developer.berlios.de/feature/?func=detailfeature&feature_id=4086&group_id=4148 Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
