Re: [Openocd-development] openocd-svn mailing list retired
On Thu, Oct 8, 2009 at 5:02 AM, Zach Welch z...@superlucidity.net wrote: Hey all, Since we have changed to GIT, we will no longer be using the openocd-svn mailing list to track commits to the repository. I am uncertain as to whether or not equivalent functionality can be provided with GIT, but I thought this topic worth mentioning as I enjoyed the opportunity to review all of changes through that list. Does anyone feel we need to restore this project feature? I would like to have a mailing list w/commit posts. Perhaps this is provided already by e.g. gitweb or somesuch @ sourceforge? -- Ø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] openocd-svn mailing list retired
On Thu, 2009-10-08 at 08:22 +0200, Øyvind Harboe wrote: On Thu, Oct 8, 2009 at 5:02 AM, Zach Welch z...@superlucidity.net wrote: Hey all, Since we have changed to GIT, we will no longer be using the openocd-svn mailing list to track commits to the repository. I am uncertain as to whether or not equivalent functionality can be provided with GIT, but I thought this topic worth mentioning as I enjoyed the opportunity to review all of changes through that list. Does anyone feel we need to restore this project feature? I would like to have a mailing list w/commit posts. Perhaps this is provided already by e.g. gitweb or somesuch @ sourceforge? 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? Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] openocd-svn mailing list retired
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. -- Ø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] [Openocd-svn] r2826 - trunk/src
Modified: trunk/src/openocd.c Log: Refuse to build. Current sources are in GIT, not SVN. See the README for information about where the GIT tree lives. Nice one! Perfect! -- Ø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=detailbugbug_id=16028group_id=4148 - https://developer.berlios.de/patch/?func=detailpatchpatch_id=2792group_id=4148 - Resume after breakpoint on X-Scale: - https://developer.berlios.de/bugs/?func=detailbugbug_id=15867group_id=4148 - Improve interactive support (e.g. 'pause', etc.). - https://developer.berlios.de/feature/?func=detailfeaturefeature_id=4086group_id=4148 Cheers, Zach ___ 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
[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
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] [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
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=detailfeaturefeature_id=4086group_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
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] 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] [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
[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] 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
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, 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 here, code there 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] 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=detailfeaturefeature_id=4086group_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
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 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] 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 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=detailbugbug_id=16028group_id=4148 - https://developer.berlios.de/patch/?func=detailpatchpatch_id=2792group_id=4148 - Resume after breakpoint on X-Scale: - https://developer.berlios.de/bugs/?func=detailbugbug_id=15867group_id=4148 - Improve interactive support (e.g. 'pause', etc.). - https://developer.berlios.de/feature/?func=detailfeaturefeature_id=4086group_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] 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 vectorshere, codethere 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] 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] 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
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] Cross compiler for ARM7 bare metal
On Thu, Oct 8, 2009 at 7:13 PM, Duane Ellis open...@duaneellis.com 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, 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:02 PM, David Brownell davi...@pacbell.net 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 here, code there 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
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 1:01 AM, Jon Smirl jonsm...@gmail.com wrote: On Fri, Oct 9, 2009 at 12:56 AM, David Brownell davi...@pacbell.net 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
[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
