[Openocd-development] Berlios outage
Berlios has been down for several days. There has previously been some talk about switching to git as a source control for all sorts of other reasons, but there never was a reason to do the work. While we are thankful for the hosting service Berlios has provided, the OpenOCD maintainers are seriously considering moving to sourceforge + git at this point. Fortunately Berlios is now up and running again and we have a communication channel to the community to enable a much smoother transition. Stay tuned for more info. -- Ø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] [PATCH] jtag "setup" event; DaVinci ICEpick updates
Add a new "jtag-setup" event; use for better DaVinci ICEpick support.
The model is that this fires after scanchain verification, when it's
safe to call "jtag tapenable $TAPNAME". So it will fire as part of
non-error paths of "init" and "reset" command processing. However it
will *NOT* trigger during "jtag_reset" processing, which skips all
scan chain verification, or after verification errors.
ALSO: unify "enum jtag_event" scripted event notifications; and remove
JTAG_TAP_EVENT_POST_RESET, we already have JTAG_TRST_ASSERTED which
means the same thing.
---
NOTE: the dm355 now makes a good example of how an OMAP3 might
get setup ... since I changed the default EMU0/EMU1 settings to
match TI's defaults, and thus how OMAP3 behaves. (Though OMAP3
won't set its ETB up like this. Not that we have support for
ETM/ETB through ADIv5 yet!)
Before this merges, I'll verify this behaves on dm365 and dm6446
boards too ... but I can't imagine any ICEpick problems there.
Those boards will need some "there's no SRST here!" solution that
Beagle boards also need.
doc/openocd.texi | 28 ++--
src/jtag/core.c | 15 ---
src/jtag/jtag.h | 33 +
src/jtag/tcl.c | 12 ++--
tcl/target/ti_dm355.cfg |7 +--
tcl/target/ti_dm365.cfg |3 +++
tcl/target/ti_dm6446.cfg |4
7 files changed, 73 insertions(+), 29 deletions(-)
--- a/doc/openocd.texi
+++ b/doc/openocd.texi
@@ -2428,12 +2428,18 @@ The TAP events currently defined are:
@itemize @bullet
@item @b{post-reset}
@* The TAP has just completed a JTAG reset.
-For the first such handler called, the tap is still
-in the JTAG @sc{reset} state.
+The tap may still be in the JTAG @sc{reset} state.
+Handlers for these events might perform initialization sequences
+such as issuing TCK cycles, TMS sequences to ensure
+exit from the ARM SWD mode, and more.
+
Because the scan chain has not yet been verified, handlers for these events
@emph{should not issue commands which scan the JTAG IR or DR registers}
of any particular target.
@b{NOTE:} As this is written (September 2009), nothing prevents such access.
+...@item @b{setup}
+...@* The scan chain has been reset and verified.
+This handler may enable TAPs as needed.
@item @b{tap-disable}
@* The TAP needs to be disabled. This handler should
implement @command{jtag tapdisable}
@@ -2450,7 +2456,7 @@ contents to be accurate), you might:
@example
jtag configure CHIP.jrc -event post-reset @{
- echo "Reset done"
+ echo "JTAG Reset done"
... non-scan jtag operations to be done after reset
@}
@end example
@@ -2493,20 +2499,30 @@ does include a kind of JTAG router funct
In OpenOCD, tap enabling/disabling is invoked by the Tcl commands
shown below, and is implemented using TAP event handlers.
So for example, when defining a TAP for a CPU connected to
-a JTAG router, you should define TAP event handlers using
+a JTAG router, your @file{target.cfg} file
+should define TAP event handlers using
code that looks something like this:
@example
jtag configure CHIP.cpu -event tap-enable @{
- echo "Enabling CPU TAP"
... jtag operations using CHIP.jrc
@}
jtag configure CHIP.cpu -event tap-disable @{
- echo "Disabling CPU TAP"
... jtag operations using CHIP.jrc
@}
@end example
+Then you might want that CPU's TAP enabled almost all the time:
+
+...@example
+jtag configure $CHIP.jrc -event setup "jtag tapenable $CHIP.cpu"
+...@end example
+
+Note how that particular setup event handler declaration
+uses quotes to evaluate @code{$CHIP} when the event is configured.
+Using brackets @{ @} would cause it to be evaluated later,
+at runtime, when it might have a different value.
+
@deffn Command {jtag tapdisable} dotted.name
If necessary, disables the tap
by sending it a @option{tap-disable} event.
--- a/src/jtag/core.c
+++ b/src/jtag/core.c
@@ -61,8 +61,8 @@ static int jtag_error = ERROR_OK;
static const char *jtag_event_strings[] =
{
[JTAG_TRST_ASSERTED] = "TAP reset",
+ [JTAG_TAP_EVENT_SETUP] = "TAP setup",
[JTAG_TAP_EVENT_ENABLE] = "TAP enabled",
- [JTAG_TAP_EVENT_POST_RESET] = "TAP post reset",
[JTAG_TAP_EVENT_DISABLE] = "TAP disabled",
};
@@ -489,7 +489,7 @@ void jtag_add_tlr(void)
/* NOTE: order here matches TRST path in jtag_add_reset() */
jtag_call_event_callbacks(JTAG_TRST_ASSERTED);
- jtag_notify_reset();
+ jtag_notify_event(JTAG_TRST_ASSERTED);
}
void jtag_add_pathmove(int num_states, const tap_state_t *path)
@@ -704,7 +704,7 @@ void jtag_add_reset(int req_tlr_or_trst,
* sequence must match jtag_add_tlr().
*/
jtag_call_event_callbacks(JTAG_TRST_ASSERTED);
- jtag_notify_reset();
+ jtag_notify_event(JTAG_TRST_ASSERTED);
}
}
}
@@ -1232,6 +1232,7 @@ static int jtag
Re: [Openocd-development] [PATCH] Updated omap3530 .cfg with improved reset handling
On Friday 02 October 2009, David Brownell wrote: > My previous proposal here is twofold: > > 1 - First, to make sure the TAP will have been > enabled! Add a new "post-verify" method to > kick in after the scan chain verification, > which can "jtag tapenable $TAPNAME". And for the record -- that patch is ready; works on one DaVinci so I expect it's OK on other ICEpicks too. Once Berlios.de is online again you'll see it ... > 2 - Then second, to call out to an optional Tcl > event method instead of relying on arp_reset > being able to kick in SRST. For OMAP3 it > could write PRM_RSTCTRL; on DaVinci boards > it might force a watchdog reset, assuming > no better docs appear. And boards with SRST > would of course want to use that... > > But there are two things that also need to be teased > out. One is the register cache, as you note. The > other is setting whatever hardware debug hooks are > needed to ensure that the $halt happens if needed. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] srst state on init again
Here is the patch on jtag_reset_on_init (again).
This fixes the problem with Olimex dongle (on power-on it drives srst
low) but will also fix libftd2xx.so library (asserts srst for > 250ms).
On Thu, 2009-10-01 at 07:32 +0200, Øyvind Harboe wrote:
> > 1. put reset_on_init patch that I submitted earlier and make it
> > dependent on hardware used to access JTAG.
>
> Where is this patch?
>
> > 2. put in udev rules a small program that will de-assert srst. I am not
> > sure if would be committed to openocd tree?
> >
> > Comments or ideas?
>
> Remove the initial scan of JTAG in OpenOCD?
>
> When and how to scan the JTAG chain should be more under the
> control of the config script I think.
>
> E.g. we've been talking about autoconfig and at that point it makes
> a LOT more sense to scan the JTAG chain in the config script.
>
Index: src/jtag/core.c
===
--- src/jtag/core.c (revision 2796)
+++ src/jtag/core.c (working copy)
@@ -95,6 +95,7 @@
static int jtag_ntrst_delay = 0; /* default to no nTRST delay */
static int jtag_nsrst_assert_width = 0; /* width of assertion */
static int jtag_ntrst_assert_width = 0; /* width of assertion */
+static bool jtag_reset_on_init = false; /* reset JTAG on init */
typedef struct jtag_event_callback_s
{
@@ -1323,6 +1324,8 @@
int retval;
if ((retval = jtag_interface_init(cmd_ctx)) != ERROR_OK)
return retval;
+ if (jtag_reset_on_init)
+ return jtag_init_reset(cmd_ctx);
if (jtag_init_inner(cmd_ctx) == ERROR_OK)
{
return ERROR_OK;
@@ -1507,3 +1510,11 @@
{
return jtag_ntrst_assert_width;
}
+void jtag_set_reset_on_init(bool state)
+{
+ jtag_reset_on_init = state;
+}
+bool jtag_get_reset_on_init(void)
+{
+ return jtag_reset_on_init;
+}
Index: src/jtag/jtag.h
===
--- src/jtag/jtag.h (revision 2796)
+++ src/jtag/jtag.h (working copy)
@@ -295,6 +295,9 @@
void jtag_set_ntrst_assert_width(unsigned delay);
unsigned jtag_get_ntrst_assert_width(void);
+void jtag_set_reset_on_init(bool state);
+bool jtag_get_reset_on_init(void);
+
/// @returns The current state of TRST.
int jtag_get_trst(void);
/// @returns The current state of SRST.
Index: src/jtag/tcl.c
===
--- src/jtag/tcl.c (revision 2796)
+++ src/jtag/tcl.c (working copy)
@@ -63,7 +63,8 @@
static int handle_jtag_ntrst_delay_command(struct command_context_s *cmd_ctx, char *cmd, char **args, int argc);
static int handle_jtag_nsrst_assert_width_command(struct command_context_s *cmd_ctx, char *cmd, char **args, int argc);
static int handle_jtag_ntrst_assert_width_command(struct command_context_s *cmd_ctx, char *cmd, char **args, int argc);
-
+static int handle_jtag_reset_on_init_command(struct command_context_s *cmd_ctx, char *cmd, char **args, int argc);
+
static int handle_scan_chain_command(struct command_context_s *cmd_ctx, char *cmd, char **args, int argc);
static int handle_jtag_reset_command(struct command_context_s *cmd_ctx, char *cmd, char **args, int argc);
@@ -625,7 +626,9 @@
COMMAND_ANY, "jtag_nsrst_assert_width - delay after asserting srst in ms");
register_command(cmd_ctx, NULL, "jtag_ntrst_assert_width", handle_jtag_ntrst_assert_width_command,
COMMAND_ANY, "jtag_ntrst_assert_width - delay after asserting trst in ms");
-
+ register_command(cmd_ctx, NULL, "jtag_reset_on_init", handle_jtag_reset_on_init_command,
+ COMMAND_ANY, "jtag_reset_on_init true/false - reset JTAG chain before initializing.");
+
register_command(cmd_ctx, NULL, "scan_chain", handle_scan_chain_command,
COMMAND_EXEC, "print current scan chain configuration");
@@ -1019,6 +1022,28 @@
return ERROR_OK;
}
+static int handle_jtag_reset_on_init_command(struct command_context_s *cmd_ctx,
+ char *cmd, char **args, int argc)
+{
+ if (argc > 1)
+return ERROR_COMMAND_SYNTAX_ERROR;
+ if (argc == 1)
+{
+ bool state;
+ if (strcmp(args[0], "true") == 0)
+ state = true;
+ else if (strcmp(args[0], "false") == 0)
+ state = false;
+ else
+ return ERROR_COMMAND_SYNTAX_ERROR;
+ jtag_set_reset_on_init(state);
+}
+ command_print(cmd_ctx, "reset_on_init is %s",
+ jtag_get_reset_on_init() ? "true": "false");
+ return ERROR_OK;
+}
+
+
static int handle_jtag_speed_command(struct command_context_s *cmd_ctx, char *cmd, char **args, int argc)
{
int retval = ERROR_OK;
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] srst state on init again
I've changed my mind. It helps if I read through the patch. :-) This patch makes it possible for a config script to skip the reset on starting up OpenOCD. This makes a lot of sense to me. How and when to start communicating with the target after launching OpenOCD *should* be under the target configuration scripts control. I would have committed this patch already, but BerliOS seems to be acting up tonight... -- Ø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] need help with config file
David, Thanks for the info. I'm slowly making progress. On Fri, Oct 2, 2009 at 4:58 AM, David Brownell wrote: .. > > I'm not sure why that diagnostic > > Error: imx25.cpu: IR capture error; saw 0x3E1011 not 0x..1 > > is there; it looks bizarre, that *is* an LSB of b0001, it's > the next bits that are odd. > This diagnostic is misleading. It does not give the position where it was expecting the 01. The string is the entire captured data. The right most 1 is the first tap. The next is the second tap and the 0 is the funky whatchamacallit tap. Your patch on 9/29 removed code that ignored bad capture codes for taps with no idcodes: - Remove the oddball limitation that invalid capture LSBs trigger errors only for TAPs that support IDCODE. The i.mx31 has the same issue so I guess this should be reverted or some different way of ignoring this should be added. John > - Dave > ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] need help with config file
David,
You were right about the ir lengths, but I also had to put back in the code
that ignores non b01 for taps with 0 ids. The i.mx31 has the same weird tap
with no id and no b01 in the capture. The i.mx25 config and patch are
attached.
John
On Sat, Oct 3, 2009 at 6:03 PM, David Brownell wrote:
> On Saturday 03 October 2009, John Rigby wrote:
> > > is there; it looks bizarre, that *is* an LSB of b0001, it's
> > > the next bits that are odd.
> >
> > This diagnostic is misleading. It does not give the position where it
> was
> > expecting the 01. The string is the entire captured data. The right
> most 1
> > is the first tap.
>
> Ah, that needs to be fixed then.
>
>
> > The next is the second tap and the 0 is the funky
> > whatchamacallit tap. Your patch on 9/29 removed code that ignored bad
> > capture codes for taps with no idcodes:
> >
> > - Remove the oddball limitation that invalid capture LSBs
> >trigger errors only for TAPs that support IDCODE.
>
> I'd not be so sure. Let's try fixing at least the known bad
> IR length in your config, and the bad message, first.
>
> We don't actually *know* that you've got a bad IR capture
> in the picture ... where we *do* know that some of your IR
> lengths are very wrong.
>
>
> > The i.mx31 has the same issue so I guess this should be reverted or some
> > different way of ignoring this should be added.
>
> Which issue is it that the iM31 has?
>
>
diff --git a/src/jtag/core.c b/src/jtag/core.c
index 6177c1d..4601443 100644
--- a/src/jtag/core.c
+++ b/src/jtag/core.c
@@ -1115,12 +1115,16 @@ static int jtag_validate_ircapture(void)
if (val != 1) {
char *cbuf = buf_to_str(ir_test, total_ir_length, 16);
- LOG_ERROR("%s: IR capture error; saw 0x%s not 0x..1",
- jtag_tap_name(tap), cbuf);
-
- free(cbuf);
- retval = ERROR_JTAG_INIT_FAILED;
- goto done;
+ /* Fail only if we have IDCODE for this device.
+ * This is needed for bogus taps on i.mx31 and i.mx25
+ */
+ if (tap->hasidcode) {
+LOG_ERROR("%s: IR capture error; saw 0x%s pos %d not 0x..1",
+ jtag_tap_name(tap), cbuf, chain_pos);
+free(cbuf);
+retval = ERROR_JTAG_INIT_FAILED;
+goto done;
+ }
}
chain_pos += tap->ir_length;
}
imx25.cfg
Description: Binary data
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Outage test
Does this mail reach the list? (Do not respond, I'll see it in the archives :-) -- Ø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] srst gates trst patch
On Wednesday 16 September 2009, Øyvind Harboe wrote:
> --- src/target/arm7_9_common.c(revision 2714)
> +++ src/target/arm7_9_common.c(working copy)
> @@ -1021,6 +1021,17 @@
> return ERROR_FAIL;
> }
>
> + /* at this point trst has been asserted/deasserted once. We want to
> + * program embedded ice while SRST is asserted, but some CPUs gate
> + * the JTAG clock while SRST is asserted
> + */
> + bool srst_asserted = false;
> + if (((jtag_reset_config & RESET_SRST_PULLS_TRST) == 0) &&
> ((jtag_reset_config & RESET_SRST_GATES_JTAG) == 0))
In short, *change the default* to assume JTAG is available during SRST.
I suspect the default should get reverted before 0.3 ships. It's
easy to see how chips might *not* have a clock available with SRST
active ... and I know that many of them are explicit about needing
time to stabilize clocks after reset, so even if it's available it
may not work well for non-adaptive JTAG clocking.
In fact, I need to go back and verify ... but disabling that check
seemed to make one board work again. I suspect this change will
cause a lot of subtle *avoidable* breakage.
Any objection if I restore the previous default, while still
ensuring that the "reset_config" command can control this?
- Dave
> + {
> + jtag_add_reset(0, 1);
> + srst_asserted = true;
> + }
> +
> if (target->reset_halt)
> {
> /*
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] need help with config file
On Saturday 03 October 2009, John Rigby wrote: > > is there; it looks bizarre, that *is* an LSB of b0001, it's > > the next bits that are odd. > > This diagnostic is misleading. It does not give the position where it was > expecting the 01. The string is the entire captured data. The right most 1 > is the first tap. Ah, that needs to be fixed then. > The next is the second tap and the 0 is the funky > whatchamacallit tap. Your patch on 9/29 removed code that ignored bad > capture codes for taps with no idcodes: > > - Remove the oddball limitation that invalid capture LSBs > trigger errors only for TAPs that support IDCODE. I'd not be so sure. Let's try fixing at least the known bad IR length in your config, and the bad message, first. We don't actually *know* that you've got a bad IR capture in the picture ... where we *do* know that some of your IR lengths are very wrong. > The i.mx31 has the same issue so I guess this should be reverted or some > different way of ignoring this should be added. Which issue is it that the iM31 has? ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] srst state on init again
The problem I have with this patch is the concept that the interface is in a particular sate when OpenOCD is not running where it is possible to "smoothly" transition into the "OpenOCD state". How about allowing scripts to override the "init" of OpenOCD to e.g. add a sleep after the device is initialized? Others will have to comment on ft2232 in general as I know very little about that driver. -- Ø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] cannot halt CPU
On Tuesday 29 September 2009, jie zeng wrote: > I cannot halt it but after type `regs' command it shows me almost > registers are 0x. > "debug_ctrl" is not zero(no log now). Others I'm not sure. You would need to type "reg debug_ctrl" to check; it won't read that otherwise Another thing to check: "reset_config srst_gates_jtag" in your setup script. A default was changed and I suspect it ought to go back to how it was ... ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] NEWS file for 0.3.x
I updated it a bit more, mostly to catch user-visible changes that made it into the User's Guide but not yet into NEWS. My two cents: if it's a user-visible change beyond a trivial bugfix, it's worth having in NEWS. So please scan the appended text to see if it's missing much of significance... - Dave CUT HERE This file should include highlights of the changes made in the OpenOCD openocd-0.3.0 source archive release. See the repository history for details about what changed, including bugfixes and other issues not mentioned here. JTAG Layer: FT2232H (high speed USB) support doesn't need separate configuration 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 Target Layer: New commands for use with Cortex-M3 processors: "cortex_m3 disassemble" ... Thumb2 disassembly (UAL format) "cortex_m3 vector_catch" ... traps certain hardware faults without tying up breakpoint resources If you're willing to help debug it VERY EARLY Cortex-A8 and ARMv7A support Updated BeagleBoard.org hardware support New commands for use with XScale processors: "xscale vector_table" ARM11 single stepping support for i.MX31 bugfix for missing "arm11" prefix on "arm11 memwrite ..." ETM support Unavailable registers are not listed Flash Layer: The lpc2000 driver handles the new NXP LPC1700 (Cortex-M3) chips New lpc2900 driver for NXP LPC2900 chips (ARM968 based) New "last" flag for NOR "flash erase_sector" and "flash protect" The "nand erase N" command now erases all of bank N Board, Target, and Interface Configuration Scripts: Amontec JTAGkey2 support Cleanup and additions for the TI/Luminary Stellaris scripts LPC1768 target (and flash) support Keil MCB1700 eval board Samsung s3c2450 Mini2440 board Numeric TAP and Target identifiers now trigger warnings Documentation: Capture more debugging and setup advice Notes on target source code changes that may help debugging Build and Release: For more details about what has changed since the last release, see the ChangeLog associated with this source archive. For older NEWS, see the NEWS files associated with each release (i.e. NEWS-). For more information about contributing test reports, bug fixes, or new features and device support, please read the new Developer Manual (or the BUGS and PATCHES files in the source archive). ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] srst gates trst patch
> Any objection if I restore the previous default, while still > ensuring that the "reset_config" command can control this? Sounds good to me. Thanks for spotting this and pitching in. -- Ø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] jtag_init changes
During the "init" command jtag_init() is invoked.
I'm thinking that how and when to handle jtag_init_inner() and
jtag_init_reset() should be under target script control, if they
are invoked at all.
When and how the target device becomes able to communicate
can be quite involved as we know from the less straightforward
targets.
Suggestion:
- split out jtag_init_inner() and jtag_init_reset() as commands
- add new command tcl "jtag_init". This tcl command simply invokes
jtag_init_inner and jtag_init_reset.
- target configuration scripts can override the implementation of
jtag_init to e.g. do nothing.
int jtag_init(struct command_context_s *cmd_ctx)
{
int retval;
if ((retval = jtag_interface_init(cmd_ctx)) != ERROR_OK)
return retval;
if (jtag_init_inner(cmd_ctx) == ERROR_OK)
{
return ERROR_OK;
}
return jtag_init_reset(cmd_ctx);
}
--
Ø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] srst state on init again
I've started a new thread on how jtag_init() should be handled to give the target script much more control. Your patch allows for a particular type of change, but I'd rather make it much more general. -- Ø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] Berlios outage
Øyvind Harboe wrote: > Berlios has been down for several days. > > There has previously been some talk about switching to git > as a source control for all sorts of other reasons, but there > never was a reason to do the work. > > While we are thankful for the hosting service Berlios has provided, > the OpenOCD maintainers are seriously considering moving > to sourceforge + git at this point. What's about staying with all we have at Berlios (mailing list, home page etc) and just switching the source code to git, e.g. at gitorious? Best regards Dirk ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Berlios outage
On Monday 05 October 2009, Dirk Behme wrote: > What's about staying with all we have at Berlios (mailing list, home > page etc) and just switching the source code to git, e.g. at gitorious? We already have a GIT tree at SourceForge, it's been there for a month or two now ... see the fairly stone-age webpage: http://openocd.sourceforge.net As of a few minutes ago it's fully synced with SVN. Right now I think there seems to be general agreement to switch to that GIT repository in the next couple of days. (So I encourage everyone to switch ASAP ...) As for the rest ... there aren't many project resources we really use at Berlios. Discounting the obsolete wiki bits, there is SVN, release downloads, some web stuff, and the mailing list. I think it makes sense to move to GIT first, and make sure the docs mention the migration and list both sites. The 0.3.x release can be distributed at both sites. - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Beagleboard extra clocks in reset
[ RESEND -- got a bounce from the Berlios list outage ] On Sunday 06 September 2009, Øyvind Harboe wrote: > > Public ICEpick docs are incomplete, but the ones I found > > were not clear on whether the state mattered ... maybe the > > issue is that it *does* matter somewhat, and clocking in > > JTAG idle state is better. > > If this is the case, then an event would be better than some > fixed functionality. For the record, there seems to be another TCK-related issue with some chips, coupled to nTRST instead of the JTAG Reset state (which can of course be entered without nTRST). Specifically, that releasing an nTRST assertion won't always be effective until after a TCK cycle triggers the rest of the JTAG reset: nTRST is synchronous, not asynch. I'm thinking that the simplest way around such issues might be to _always_ add a clock after releasing nTRST. Right now this issue is probably swallowed by the fact that releasing nTRST is *usually* followed by a verification of the scan chain, which always starts with five TMS=1 clocks. The first could be swallowed, the rest are NOPs. But I'd feel safer if we didn't rely on that "usually". - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Berlios outage
> What's about staying with all we have at Berlios (mailing list, home page > etc) and just switching the source code to git, e.g. at gitorious? Berlios does not have the track record that I'm looking for w.r.t. availability, posting public list of outages, etc. I want to see the main git server at sourceforge and mirrors elsewhere. The nice thing about git is that we can even commit and push/pull to mirrors if all hell breaks looks w/sourceforge. Sourceforge is "too big to fail" though :-) -- Ø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
Typed up patch attached that gives target script more control over
how OpenOCD sets up the interface + target before
examining.
Not tested. Feedback needed!
Change jtag_init to avoid the init without a prior reset:
proc jtag_init {} {
#Make sure we reset the hardware before we talk to it
jtag arp_init-reset
}
--
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer
### Eclipse Workspace Patch 1.0
#P openocd
Index: src/jtag/jtag.h
===
--- src/jtag/jtag.h (revision 2801)
+++ src/jtag/jtag.h (working copy)
@@ -335,8 +335,9 @@
extern int jtag_init(struct command_context_s* cmd_ctx);
/// reset, then initialize JTAG chain
-extern int jtag_init_reset(struct command_context_s* cmd_ctx);
-extern int jtag_register_commands(struct command_context_s* cmd_ctx);
+extern int jtag_init_reset(struct command_context_s* cmd_ctx);
+extern int jtag_register_commands(struct command_context_s* cmd_ctx);
+extern int jtag_init_inner(struct command_context_s *cmd_ctx);
/**
* @file
Index: src/helper/startup.tcl
===
--- src/helper/startup.tcl (revision 2801)
+++ src/helper/startup.tcl (working copy)
@@ -359,3 +359,13 @@
} result
return $result
}
+
+
+# Executed during "init". Can be implemented by target script
+# tar
+proc jtag_init {} {
+ if {[catch {jtag arp_init} err]!=0} {
+ # try resetting additionally
+ jtag arp_init-reset
+ }
+}
\ No newline at end of file
Index: src/jtag/core.c
===
--- src/jtag/core.c (revision 2801)
+++ src/jtag/core.c (working copy)
@@ -1,16 +1,16 @@
/***
- * Copyright (C) 2005 by Dominic Rath*
- * dominic.r...@gmx.de *
+ * Copyright (C) 2009 Zachary T Welch*
+ * z...@superlucidity.net *
* *
- * Copyright (C) 2007,2008 Øyvind Harboe *
+ * Copyright (C) 2007,2008,2009 Øyvind Harboe*
* oyvind.har...@zylin.com *
* *
* Copyright (C) 2009 SoftPLC Corporation*
* http://softplc.com*
* d...@softplc.com *
* *
- * Copyright (C) 2009 Zachary T Welch*
- * z...@superlucidity.net *
+ * Copyright (C) 2005 by Dominic Rath*
+ * dominic.r...@gmx.de *
* *
* This program is free software; you can redistribute it and/or modify *
* it under the terms of the GNU General Public License as published by *
@@ -1230,7 +1230,7 @@
return ERROR_OK;
}
-static int jtag_init_inner(struct command_context_s *cmd_ctx)
+int jtag_init_inner(struct command_context_s *cmd_ctx)
{
jtag_tap_t *tap;
int retval;
@@ -1334,11 +1334,11 @@
int retval;
if ((retval = jtag_interface_init(cmd_ctx)) != ERROR_OK)
return retval;
- if (jtag_init_inner(cmd_ctx) == ERROR_OK)
- {
- return ERROR_OK;
- }
- return jtag_init_reset(cmd_ctx);
+
+ if (Jim_Eval_Named(interp, "jtag_init", __FILE__, __LINE__) != JIM_OK)
+ return ERROR_FAIL;
+
+ return ERROR_OK;
}
unsigned jtag_get_speed_khz(void)
Index: src/jtag/tcl.c
===
--- src/jtag/tcl.c (revision 2801)
+++ src/jtag/tcl.c (working copy)
@@ -410,6 +410,7 @@
enum {
JTAG_CMD_INTERFACE,
+ JTAG_CMD_INIT,
JTAG_CMD_INIT_RESET,
JTAG_CMD_NEWTAP,
JTAG_CMD_TAPENABLE,
@@ -422,6 +423,7 @@
const Jim_Nvp jtag_cmds[] = {
{ .name = "interface" , .value = JTAG_CMD_INTERFACE },
+ { .name = "arp_init" , .value = JTAG_CMD_INIT },
{ .name = "arp_init-reset", .value = JTAG_CMD_INIT_RESET },
{ .name = "newtap", .value = JTAG_CMD_NEWTAP },
{ .name = "tapisenabled" , .value = JTAG_CMD_TAPISENABLED },
@@ -455,6 +457,1
Re: [Openocd-development] Berlios outage
Hi David, > Right now I think there seems to be general agreement to > switch to that GIT repository in the next couple of days. > (So I encourage everyone to switch ASAP ...) > I felt encouraged immediately, but now I'm stuck... Has anyone solved the problem of git access from behind a strict HTTP proxy? Various recipes circulate the net, but none of them has helped me so far. My only way out is through the HTTP proxy. I assume that the proxy doesn't accept the git port, and I have no possibility to change that. Can Sourceforge be configured for HTTP access, or is the git protocol the only option? Regards, Rolf ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Berlios outage
David Brownell wrote: > On Monday 05 October 2009, Dirk Behme wrote: >> What's about staying with all we have at Berlios (mailing list, home >> page etc) and just switching the source code to git, e.g. at gitorious? > > We already have a GIT tree at SourceForge, it's been there > for a month or two now ... see the fairly stone-age webpage: > > http://openocd.sourceforge.net > > As of a few minutes ago it's fully synced with SVN. > > Right now I think there seems to be general agreement to > switch to that GIT repository in the next couple of days. > (So I encourage everyone to switch ASAP ...) Switching to git: Yes. > As for the rest ... there aren't many project resources > we really use at Berlios. Discounting the obsolete wiki > bits, there is SVN, release downloads, some web stuff, > and the mailing list. Yes. There is a lot of other stuff which has to be handled carefully, see below. > I think it makes sense to move to GIT first, Yes. > and make > sure the docs mention the migration and list both sites. > The 0.3.x release can be distributed at both sites. I'm not sure if we really want SourceForge, though. Especially for mailing lists. U-Boot moved away from it because of pain: http://lists.denx.de/pipermail/u-boot/2008-August/038001.html (not mentioned there: Spam handling) Best regards Dirk ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Berlios outage
> I'm not sure if we really want SourceForge, though. Especially for mailing > lists. U-Boot moved away from it because of pain: > > http://lists.denx.de/pipermail/u-boot/2008-August/038001.html > > (not mentioned there: Spam handling) What other free viable options are there? sourceforge mailing lists is the least inconvenient at this point. Setting up a special OpenOCD server is a non-starter without some funding(OpenOCD foundation again...) -- Ø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] Berlios outage
> Can Sourceforge be configured for HTTP access, or is the git > protocol the only option? With git mirrors are trivial. You can use any protocol, even usb sticks... -- Ø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] Berlios outage
Øyvind Harboe wrote: >> I'm not sure if we really want SourceForge, though. Especially for mailing >> lists. U-Boot moved away from it because of pain: >> >> http://lists.denx.de/pipermail/u-boot/2008-August/038001.html >> >> (not mentioned there: Spam handling) > > What other free viable options are there? As far as I can see as a user, I'm fine with Berlios mailing list and archive (except the outage the last days). Best regards Dirk ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Berlios outage
Hi, On Mon, Oct 5, 2009 at 17:02, Øyvind Harboe wrote: >> I'm not sure if we really want SourceForge, though. Especially for mailing >> lists. U-Boot moved away from it because of pain: >> >> http://lists.denx.de/pipermail/u-boot/2008-August/038001.html >> >> (not mentioned there: Spam handling) > > What other free viable options are there? Google groups? -- WBR, Igor ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Berlios outage
On Monday 05 October 2009, Rolf Meeser wrote: > Hi David, > > > Right now I think there seems to be general agreement to > > switch to that GIT repository in the next couple of days. > > (So I encourage everyone to switch ASAP ...) > > I felt encouraged immediately, Yay! > but now I'm stuck... Boo! > Has anyone solved the problem of git access from behind a > strict HTTP proxy? I thought that had been solved for some time now. As I look at the sourceforge service, I observe that it doesn't support http access though (except gitweb; not "git pull"). And since I don't have that unfortunate problem, I'm not up on the details. I do know there are various drawbacks to HTTP access, including slow speed. > Various recipes circulate the net, but none of them has > helped me so far. My only way out is through the HTTP > proxy. I assume that the proxy doesn't accept the git port, > and I have no possibility to change that. > > Can Sourceforge be configured for HTTP access, or is the > git protocol the only option? For SourceForge, I think it's just HTTP. Did you look around much? I'd hope that would be a FAQ, but ISTR that last year this time SF didn't offer GIT; so their service is evolving. Maybe if we asked, they'd help. :) One option would be to tunnel using SSH through the proxy, something like CorkScrew: http://returnbooleantrue.blogspot.com/2009/06/using-github-through-draconian-proxies.html which I found at http://github.com/guides/dealing-with-firewalls-and-proxies That also lists a Windows-oriented variant. Lacking that, we might want a git mirror at a site which does have easier HTTP access. We'll have to leave the important details here up to the folk who will be using the solutions though... - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Berlios outage
> Lacking that, we might want a git mirror at a site which > does have easier HTTP access. Like http://repo.or.cz/m/regproj.cgi ? You can also clone/pull a repository to a usb stick from outside a firewall. -- Ø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] Berlios outage
On Monday 05 October 2009, Dirk Behme wrote: > As far as I can see as a user, I'm fine with Berlios mailing list and > archive (except the outage the last days). Yeah, I'm mostly OK with it ... except for it being a closed list, which completely eliminates "casual" contact (not just spam) and removes many opportunities for community growth. As you noted, sf.net mailing lists have problems. I don't want the main list hosted there either. Thing about Berlios though ... its service levels didn't even hit the "two nines" level (via their own monitors, over the last year). Switching mailing list servers is IMO something to do only when we have a clearly better alternative lined up. Switching is such a PITA that I think we're better off with Berlios for now. - Dave > I'm not sure if we really want SourceForge, though. Especially for > mailing lists. U-Boot moved away from it because of pain: > > http://lists.denx.de/pipermail/u-boot/2008-August/038001.html ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Berlios outage
David Brownell wrote: ... >> Has anyone solved the problem of git access from behind a >> strict HTTP proxy? ... > Lacking that, we might want a git mirror at a site which > does have easier HTTP access. Rolf, could you try if git clone http://git.gitorious.org/u-boot-omap3/mainline.git works for you? This totally OpenOCD off-topic, but that's the only example I have atm to test if http access to gitorious works ;) Most probably you have to set export http_proxy=http://:@: for this. Good luck Dirk ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Berlios outage
> Switching mailing list servers is IMO something to do only when > we have a clearly better alternative lined up. Switching is such > a PITA that I think we're better off with Berlios for now. What alternative is better, short of running your own server? Even with a free server, we don't have the resources and dedication to run it... -- Ø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] Moving to git
Zach, David and I as maintainers constitute the committee to move OpenOCD to sourceforge and make some choices about how things will be moved on behalf of the community. We want input from the community, but we also need a bit of leadership to execute the steps. In short, the following will happen: 1. The source will be held in git. https://sourceforge.net/projects/openocd/ 2. Zach, David and I are managers for the OpenOCD project at sourceforge. 3. There is already a mailing list set up for OpenOCD at sourceforge 4. The top web pages will be very slightly reworked so that web pages are in fact kept under git and generated by doxygen, phasing out wordpress. Schedule: Thursday October 8. 2009 08:00 EST: 1. Berlios svn will be made read only and the svn head will be "deleted", leaving behind only a README w/reference to the openocd project at sourceforge. The entire svn history will remain available on Berlios indefinitely. 2. The Berlios web page will be changed into a stub pointing to sourceforge. 3. the mailing list will be disabled and all openocd subscribers will receive an invitation to subscribe to the openocd mailing list at sourceforge. The sourceforge mailing list is the least sucky alternative for hosting mailinglists at this point. -- Ø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] Berlios outage
On Monday 05 October 2009, Øyvind Harboe wrote: > > Lacking that, we might want a git mirror at a site which > > does have easier HTTP access. > > Like > > http://repo.or.cz/m/regproj.cgi > > ? Looks like it; yes. Will you set that up? IMO having a public mirror is a Good Thing in any case. That one seems to have a nice "give me a snapshot of that version as a tarball" feature, too. > You can also clone/pull a repository to a usb stick from outside > a firewall. Also known as the "support your local independent coffee shops!" solution. Time to clone/pull is a LOT less than the time it takes to drink the coffee, note! ;) - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Berlios outage
On Mon, Oct 5, 2009 at 8:12 PM, David Brownell wrote: > On Monday 05 October 2009, Øyvind Harboe wrote: >> > Lacking that, we might want a git mirror at a site which >> > does have easier HTTP access. >> >> Like >> >> http://repo.or.cz/m/regproj.cgi >> >> ? > > Looks like it; yes. Will you set that up? Yes. We can also have a link from the sourceforge pages of the official mirror... > IMO having a public mirror is a Good Thing in any case. > > That one seems to have a nice "give me a snapshot of > that version as a tarball" feature, too. It's very nice. I use it for the zpu project. -- Ø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] Moving to git
Øyvind Harboe wrote: > Zach, David and I as maintainers constitute the committee > to move OpenOCD to sourceforge and make some choices > about how things will be moved on behalf of the community. > > We want input from the community, but we also need a bit > of leadership to execute the steps. > > In short, the following will happen: > > 1. The source will be held in git. > > https://sourceforge.net/projects/openocd/ > > 2. Zach, David and I are managers for the OpenOCD project at > sourceforge. > > 3. There is already a mailing list set up for OpenOCD at sourceforge > > 4. The top web pages will be very slightly reworked so that web pages > are in fact kept under git and generated by doxygen, phasing out > wordpress. > > Schedule: > > Thursday October 8. 2009 08:00 EST: > > 1. Berlios svn will be made read only and the svn head will be "deleted", > leaving behind only a README w/reference to the openocd project at > sourceforge. The entire svn history will remain available on Berlios > indefinitely. > > 2. The Berlios web page will be changed into a stub pointing > to sourceforge. It is my understanding that there are at least two votes for not doing this immediately. > 3. the mailing list will be disabled and all openocd subscribers will > receive an invitation to subscribe to the openocd mailing list at > sourceforge. The sourceforge mailing list is the least sucky > alternative for hosting mailinglists at this point. It is my understanding that there are at least two votes for not switching to sourceforge mailing list. Best regards Dirk ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Moving to git
>> 2. The Berlios web page will be changed into a stub pointing >> to sourceforge. > > It is my understanding that there are at least two votes for not doing this > immediately. We need more time to discuss web page + mailing list, but I don't think there is anybody who has any objections to moving to git on sourceforge Thursday. The web page has two aspects: how do we generate the pages and where do we host them. I don't think anybody is against hosting them on sourceforge. Phasing out Berlios is a significant goal in itself. >> 3. the mailing list will be disabled and all openocd subscribers will >> receive an invitation to subscribe to the openocd mailing list at >> sourceforge. The sourceforge mailing list is the least sucky >> alternative for hosting mailinglists at this point. > > It is my understanding that there are at least two votes for not switching > to sourceforge mailing list. Staying on Berlios w/the mailing list is an interim solution. Nobody has proposed an alternative to sourceforge yet. -- Ø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] Moving to git
> > >> 3. the mailing list will be disabled and all openocd subscribers will > >> receive an invitation to subscribe to the openocd mailing list at > >> sourceforge. The sourceforge mailing list is the least sucky > >> alternative for hosting mailinglists at this point. > > > > It is my understanding that there are at least two votes for not > switching > > to sourceforge mailing list. > > Staying on Berlios w/the mailing list is an interim solution. Nobody has > proposed an alternative to sourceforge yet. > There was a suggestion for using Google groups to host the mailing list. I've had success with it in the past with projects like Symfony. As long as the mailing list isn't hosted on Yahoo groups, I won't complain (LEON3 people do this and I don't like it). // Dean Glazeski ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Moving to git
> There was a suggestion for using Google groups to host the mailing list. > I've had success with it in the past with projects like Symfony. As long as > the mailing list isn't hosted on Yahoo groups, I won't complain (LEON3 > people do this and I don't like it). OK. Google groups is one alternative. I don't know anything about it, so I'm not excited :-) Are those mailing lists? Any downsides? Why is it better than sourceforge? Doesn't google offer open source project hosting? -- Ø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] Berlios outage
> >> http://repo.or.cz/m/regproj.cgi > > > > Looks like it; yes. Will you set that up? > > Yes. We can also have a link from the sourceforge pages of > the official mirror... Let me know as soon as you've done that; I'm prepping a patch to switch all the source tree references from SVN to GIT, and I want that mirror included. > > IMO having a public mirror is a Good Thing in any case. > > > > That one seems to have a nice "give me a snapshot of > > that version as a tarball" feature, too. > > It's very nice. I use it for the zpu project. Actually I notice SourceForge has the snapshot stuff too. - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Berlios outage
On Monday 05 October 2009, Øyvind Harboe wrote: > > Switching mailing list servers is IMO something to do only when > > we have a clearly better alternative lined up. Switching is such > > a PITA that I think we're better off with Berlios for now. > > What alternative is better, short of running your own server? Good question. There's the Google Groups suggestion. And there are other sites which can maybe help ... some of which have more active anti-spam in place. Keep in mind that switching to SourceForge for email would IMO not be an improvement... ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Moving to git
On Monday 05 October 2009, Øyvind Harboe wrote: > > In short, the following will happen: > > 1. The source will be held in git. > > https://sourceforge.net/projects/openocd/ !!! And if anyone objects to GIT, please speak up ASAP !!! So far the only issue raised with $SUBJECT seems to be that we need to make sure we have an HTTP-accessible mirror. That seems to be nearly in hand. And the only particular issue anyone's raised with using SourceForge is that its email sucks. Which is OK, since we don't need to use their email. But as I'm sure folk have noted, there's also a "move from Berlios to more reliable services" subtext. Using what SourceForge provides has sort of a leg up in that race... > 2. Zach, David and I are managers for the OpenOCD project at > sourceforge. Actually "project administrators". > 3. There is already a mailing list set up for OpenOCD at sourceforge Which IMO we should *NOT* be using at all. (Let me suggest that someone create a new thread specifically about mailing list alternatives and what we want improved... no point in $SUBJECT going further astray.) > 4. The top web pages will be very slightly reworked so that web pages > are in fact kept under git and generated by doxygen, phasing out > wordpress. And eventually moved to SourceForge. ** 5. The 0.3.0 release downloads will be available at SourceForge. > Schedule: > > Thursday October 8. 2009 08:00 EST: > > 1. Berlios svn will be made read only and the svn head will be "deleted", > leaving behind only a README w/reference to the openocd project at > sourceforge. The entire svn history will remain available on Berlios > indefinitely. And I've got a patch in the works updating the source tree to reference GIT not SVN. I'll commit it around then. > 2. The Berlios web page will be changed into a stub pointing > to sourceforge. I was not anticipating this happening so soon. It's not at all related to the GIT move, for example. Note that I'm not at all opposed to moving or changing the website. It's just that it's a different issue entirely, and should not be tied to the GIT switchover for the repository. > 3. the mailing list will be disabled and all openocd subscribers will > receive an invitation to subscribe to the openocd mailing list at > sourceforge. The sourceforge mailing list is the least sucky > alternative for hosting mailinglists at this point. As noted previously ... I'm not in favor of that at all. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Moving to git
So the only thing we need to agree on *now* is to move git to sourceforge. No dissent heard so far on that one. I also believe there is a consensus that Berlios does not have the qualities we're looking for and that we need to either move away now or get a plan in place asap for migrating away. We obviously need more time to discuss how to deal with the web and even more so on what to do with the mailing lists. I'll be breaking out a separate thread for the mailing list problem. -- Ø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] Switch to non-Berlios mailing list
"Migrate away from Berlios" committe wants an alternative to Berlios mailing lists. Some alternatives so far: - Set up seperate openocd.org server => not going to happen. We don't have the resources and dedication to run it. - sourceforge mailing lists apparently suck more than Berlios mailing lists. I don't know why - Google mailing lists are apparently better but I don't know why - Yahoo is worse than google Other? Can someone do some research on what would be good to use and explain a bit? -- Ø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] Mirror of sourceforge git
I was going to set up a mirror of the sourceforge git at http://repo.or.cz/, except that it does not support mirroring anything but http:// url's and sourceforge uses git:// for public url's. G. Other than that http://repo.or.cz/ looks *great*. No fluff, just a mirror that's updated every hour. -- Ø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] Moving to git
Since many people seem to not be fond of sourceforge, have you considered GitHub? Just put a README.markdown in the project and it will become a nice webpage front for the project. They already provide source browsing and snapshots available via HTTP, and make it trivially easy for anyone to (a) fork the project and (b) make changes in forks available to the original project. Plus, we could always use their Wiki for a project page. - Alex -Original Message- From: openocd-development-boun...@lists.berlios.de [mailto:openocd-development-boun...@lists.berlios.de] On Behalf Of Øyvind Harboe Sent: Monday, October 05, 2009 12:57 PM To: openocd-development@lists.berlios.de Subject: [Openocd-development] Moving to git Zach, David and I as maintainers constitute the committee to move OpenOCD to sourceforge and make some choices about how things will be moved on behalf of the community. We want input from the community, but we also need a bit of leadership to execute the steps. In short, the following will happen: 1. The source will be held in git. https://sourceforge.net/projects/openocd/ 2. Zach, David and I are managers for the OpenOCD project at sourceforge. 3. There is already a mailing list set up for OpenOCD at sourceforge 4. The top web pages will be very slightly reworked so that web pages are in fact kept under git and generated by doxygen, phasing out wordpress. Schedule: Thursday October 8. 2009 08:00 EST: 1. Berlios svn will be made read only and the svn head will be "deleted", leaving behind only a README w/reference to the openocd project at sourceforge. The entire svn history will remain available on Berlios indefinitely. 2. The Berlios web page will be changed into a stub pointing to sourceforge. 3. the mailing list will be disabled and all openocd subscribers will receive an invitation to subscribe to the openocd mailing list at sourceforge. The sourceforge mailing list is the least sucky alternative for hosting mailinglists at this point. -- Ø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] Switch to non-Berlios mailing list
Hello Øyvind, Monday, October 5, 2009, 11:28:45 PM, you wrote: ØH> "Migrate away from Berlios" committe wants an alternative ØH> to Berlios mailing lists. ØH> Some alternatives so far: ØH> - Set up seperate openocd.org server => not going to happen. We ØH> don't have the resources and dedication to run it. ØH> - sourceforge mailing lists apparently suck more than Berlios ØH> mailing lists. I don't know why ØH> - Google mailing lists are apparently better but I don't know why ØH> - Yahoo is worse than google ØH> Can someone do some research on what would be good to ØH> use and explain a bit? I guess I'll bite. Some of this can be wrong. 1) SF.net (info is kinda old, haven't been subscribed to any lists recently): software: mailman 2.1 email subscribe/unsubscribe: yes footer added: yes, with ads (?) reply-to: list web archive: yes spam: no idea extras: all SF.net stuff It seems at least some time ago it did callback verification, which doesn't work with some emails: http://it.slashdot.org/article.pl?sid=06/10/04/1324214 OTOH, UrJTAG seems to be doing okay. 2) Yahoo groups: software: custom email subscribe/unsubscribe: yes footer added: usage; sometimes ads(?) reply-to: list web archive: yes extras: file area, calendar, links, database, other crap Used to bounce for me quite often a couple of years ago, doesn't seem to happen anymore. Ads seem to be gone, but the large footer with ML links can be annoying. Not sure if it's configurable. 3) Google groups: software: custom email subscribe/unsubscribe: yes footer added: configurable reply-to: configurable web archive: yes extras: pages, files, rss feeds Can't really say much. Seems to work okay. -- WBR, Igormailto:skochin...@mail.ru ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Moving to git
Le 05/10/2009 17:19, Øyvind Harboe a écrit : > So the only thing we need to agree on *now* is to > move git to sourceforge. > > I am supportive of the move to sourceforge. > No dissent heard so far on that one. > > I also believe there is a consensus that Berlios does > not have the qualities we're looking for and that > we need to either move away now or get a plan > in place asap for migrating away. > > We obviously need more time to discuss how to deal > with the web and even more so on what to do with > the mailing lists. I'll be breaking out a separate thread > for the mailing list problem. > Google would be a good alternative to sourceforge 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] Moving to git
On Monday 05 October 2009, Austin, Alex wrote: > Since many people seem to not be fond of sourceforge, AFAIK that's just the email. Which has issues like crappy archives, bad spam filtering, ads, and such. > have you considered GitHub? In terms of GIT support is it significantly better than SourceForge? > Just put a README.markdown in the > project and it will become a nice webpage front for the > project. We need a bit more than that from the web face. Current notions include making the website give better access to the project docs: the User's Guide, and the doxygen Developer's Guide output. > They already provide source browsing and snapshots > available via HTTP, Everyone seems to run "gitweb", so that's not going to be a compelling advantage to any service. > and make it trivially easy for anyone > to (a) fork the project Already easy, courtesy of GIT. :) > and (b) make changes in forks > available to the original project. Plus, we could always use > their Wiki for a project page. We'd need someone to volunteer to manage and evolve a Wiki. And some folk don't like them. That particular change merits a separate discussion. Note that SourceForge supports wiki stuff too. - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Moving to git
On Tue, Oct 6, 2009 at 2:36 AM, Dirk Behme wrote: >> 3. the mailing list will be disabled and all openocd subscribers will >> receive an invitation to subscribe to the openocd mailing list at >> sourceforge. The sourceforge mailing list is the least sucky >> alternative for hosting mailinglists at this point. > > It is my understanding that there are at least two votes for not > switching to sourceforge mailing list. > Sourceforge mailing list is quite bad, one of the worst mailing list server. Last time linux-usb-users and linux-usb-devel were hosted in Sourceforge and they were plagued by spam, very embarrassing actually. Later they switched to vger.kernel.org. -- 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] Moving to git
And in case anyone wants suggestions about how to start learning ... http://git-scm.com/course/svn.html That's addressed to folk more familiar with SVN than GIT. - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Moving to git
On Tue, Oct 6, 2009 at 7:37 AM, David Brownell wrote: > On Monday 05 October 2009, Austin, Alex wrote: >> Since many people seem to not be fond of sourceforge, > > AFAIK that's just the email. Which has issues like > crappy archives, bad spam filtering, ads, and such. > > >> have you considered GitHub? > > In terms of GIT support is it significantly better > than SourceForge? I hear that it is better. Greg KH is using it for libusb mirror, usbutils and usbview. http://github.com/gregkh/ libusb and usbutils were previously using Sourceforge. Now libusb moved to its own server (libusb.org). > Note that SourceForge supports wiki stuff too. SourceForge discontibued the old Wiki sometimes ago and changed to new Wiki interface. SourceForge is also often went inaccessible. But I do not know if there are better alternative for website hosting. -- 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] Moving to git
> -Original Message- > From: David Brownell [mailto:davi...@pacbell.net] > Sent: Monday, October 05, 2009 6:37 PM > To: openocd-development@lists.berlios.de > Cc: Austin, Alex > Subject: Re: [Openocd-development] Moving to git > > On Monday 05 October 2009, Austin, Alex wrote: > > Since many people seem to not be fond of sourceforge, > > AFAIK that's just the email. Which has issues like > crappy archives, bad spam filtering, ads, and such. > > > > have you considered GitHub? > > In terms of GIT support is it significantly better > than SourceForge? Haven't used git on sourceforge, but it wouldn't surprise me. > > > > Just put a README.markdown in the > > project and it will become a nice webpage front for the > > project. > > We need a bit more than that from the web face. > Current notions include making the website give > better access to the project docs: the User's > Guide, and the doxygen Developer's Guide output. http://www.github.com/blog/272-github-pages Put your entire website in a branch on the git repo. That can Include doxygen-generated stuff if need be. > > > > They already provide source browsing and snapshots > > available via HTTP, > > Everyone seems to run "gitweb", so that's not going to > be a compelling advantage to any service. I use gitweb too. Compared to github's interface, it's a mere toy. > > > > and make it trivially easy for anyone > > to (a) fork the project > > Already easy, courtesy of GIT. :) GitHub takes it much further, in that it would be easy for anyone Looking at OpenOCD to find all the forks of it on GitHub, and even see where the history split off. > > > > and (b) make changes in forks > > available to the original project. Plus, we could always use > > their Wiki for a project page. > > We'd need someone to volunteer to manage and evolve > a Wiki. And some folk don't like them. That particular > change merits a separate discussion. > > Note that SourceForge supports wiki stuff too. > > - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Moving to git
On Monday 05 October 2009, Xiaofan Chen wrote: > >> have you considered GitHub? > > > > In terms of GIT support is it significantly better > > than SourceForge? > > I hear that it is better. Greg KH is using it for > libusb mirror, usbutils and usbview. I'm not sure that has anything to do with being better, so much as SourceForge not having had GIT support at the time he picked up usbutils from me. The usbutils stuff had ended up in CVS at sourceforge sort of by default, as an obvious choice once its university home went away. My two cents: I just spent some time browsing the usbutils project, and I don't like those changes they made to "gitweb". > libusb and usbutils were previously using > Sourceforge. Now libusb moved to its own > server (libusb.org). FYI that libusb.org site uses the "trac" Wiki/etc that is also available to SourceForge projects. - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Moving to git
W.r.t. the choice of sourceforge for git: - we already have it running and tested there - there is no obviously superior alternative. If we switch every time we find something that is 10% better, we'll never get stability and a decision in place. Does anyone know a git hosting alternative that is that much better than sourceforge that we *must* consider switching? If someone gave me static web pages, kick-ass mailing lists, git better than http://repo.or.cz/ and an excellent service record all in one site, I would be excited. -- Ø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] Moving to git
On Tue, Oct 6, 2009 at 12:34 AM, Austin, Alex wrote: > Since many people seem to not be fond of sourceforge, have > you considered GitHub? Just put a README.markdown in the > project and it will become a nice webpage front for the > project. I want the web pages to be browsable offline, which is one of the reasons why I like the idea of putting the top web pages for OpenOCD in doxygen & under git. -- Ø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] Switch to non-Berlios mailing list
Øyvind Harboe writes: > Other? Please keep gmane.org mirroring the list where ever it will be :-) -- http://www.iki.fi/~ananaza/ ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Switch to non-Berlios mailing list
On Tue, Oct 6, 2009 at 8:05 AM, Antti P Miettinen wrote: > Øyvind Harboe writes: >> Other? > > Please keep gmane.org mirroring the list where ever it will be :-) Is there such a thing as distributed mailing lists so it won't matter if server go down? (I never looked into good old news... :-) -- Ø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] [patch/rfc] update version handling for better GIT support
The guess-rev.sh script is now a tweaked version of "setlocalversion" as
seen in Linux, U-Boot, and various other projects. When it finds source
control support (git, hg, svn) it uses IDs from there. Else it reports
itself as "-snapshot", e.g. from gitweb.
Also update the generic version strings to be like "0.3.0-dev" (during
development) instead of the very long "0.3.0-in-development". These
also show up in the PDF docs; we might eventually change these strings
to include the version IDs.
Change how the startup banner strings include the guess-rev output.
Development and release versions will be like
Open On-Chip Debugger 0.3.0-dev-svn2801 (2009-10-05-20:57)
Open On-Chip Debugger 0.3.0-dev-00282-g7191a4f-dirty (2009-10-05-20:57)
Open On-Chip Debugger 0.3.0 (2009-10-05-20:57)
instead of the previous SVN-specific (even over git-svn!)
Open On-Chip Debugger 0.3.0-in-development (2009-10-05-01:39) svn2801:2802
Open On-Chip Debugger 0.3.0-in-development (2009-10-05-01:39) svn:exported
Open On-Chip Debugger 0.3.0 (2009-10-05-01:39) Release
I verified this new "guess-rev.sh" script runs under Cygwin.
---
Obviously "svn..." IDs are unusable with GIT; something must change.
configure.in |2 -
doc/manual/release.txt |6 +--
guess-rev.sh | 83 ---
src/Makefile.am|6 ++-
src/openocd.c |2 -
tools/release.sh |8 ++--
6 files changed, 92 insertions(+), 15 deletions(-)
--- a/configure.in
+++ b/configure.in
@@ -1,5 +1,5 @@
AC_PREREQ(2.60)
-AC_INIT([openocd], [0.3.0-in-development],
+AC_INIT([openocd], [0.3.0-dev],
[OpenOCD Mailing List ])
AC_CONFIG_SRCDIR([src/openocd.c])
--- a/doc/manual/release.txt
+++ b/doc/manual/release.txt
@@ -62,9 +62,9 @@ the minor version will @a also be zero (
@subsection releaseversiontags Version Tags
After these required numeric components, the version string may contain
-one or more version tags, such as '-rc1' or '-in-development'.
+one or more version tags, such as '-rc1' or '-dev'.
-The trunk and all branches should have the tag '-in-development' in
+The trunk and all branches should have the tag '-dev' in
their version number. This tag helps developers identify reports
created from the Subversion repository, and it can be detected and
manipulated by the release script. Specifically, this tag will be
@@ -218,7 +218,7 @@ The following steps should be followed t
- This material should be produced during the development cycle.
- Add a new item for each @c NEWS-worthy contribution, when committed.
-# bump library version if our API changed (not yet required)
- -# Remove -in-development tag from package version:
+ -# Remove -dev tag from package version in configure.in:
- For major/minor releases, remove version tag from trunk, @a or
- For bug-fix releases, remove version tag from release branch.
-# Branch or tag the required tree in the Subversion repository:
--- a/guess-rev.sh
+++ b/guess-rev.sh
@@ -1,8 +1,83 @@
-#!/bin/bash
+#!/bin/sh
+#
+# This scripts adds local version information from the version
+# control systems git, mercurial (hg) and subversion (svn).
+#
+# Copied from Linux 2.6.32 scripts/setlocalversion and modified
+# slightly to work better for OpenOCD.
#
-REV=unknown
+usage() {
+ echo "Usage: $0 [srctree]" >&2
+ exit 1
+}
-which svnversion > /dev/null 2>&1 && REV=`svnversion -n "$1"`
+cd "${1:-.}" || usage
-echo -n $REV
+# Check for git and a git repo.
+if head=`git rev-parse --verify --short HEAD 2>/dev/null`; then
+
+ # If we are at a tagged commit (like "v2.6.30-rc6"), we ignore it,
+ # because this version is defined in the top level Makefile.
+ if [ -z "`git describe --exact-match 2>/dev/null`" ]; then
+
+ # If we are past a tagged commit (like
"v2.6.30-rc5-302-g72357d5"),
+ # we pretty print it.
+ if atag="`git describe 2>/dev/null`"; then
+ echo "$atag" | awk -F- '{printf("-%05d-%s",
$(NF-1),$(NF))}'
+
+ # If we don't have a tag at all we print -g{commitish}.
+ else
+ printf '%s%s' -g $head
+ fi
+ fi
+
+ # Is this git on svn?
+ if git config --get svn-remote.svn.url >/dev/null; then
+ printf -- '-svn%s' "`git svn find-rev $head`"
+ fi
+
+ # Update index only on r/w media
+ [ -w . ] && git update-index --refresh --unmerged > /dev/null
+
+ # Check for uncommitted changes
+ if git diff-index --name-only HEAD | grep -v "^scripts/package" \
+ | read dummy; then
+ printf '%s' -dirty
+ fi
+
+ # All done with git
+ exit
+fi
+
+# Check for mercurial and a mercurial repo.
+if hgid=`hg id 2>/dev/null`; then
+ tag=`printf '%s' "$hgid" | cut -d' ' -f2`
+
+ # Do we have an untagged version?
+ if [ -z "$tag" -o "$tag" = tip
Re: [Openocd-development] Moving to git
>!!! And if anyone objects to GIT, please speak up ASAP !!! Why are we moving to GIT anyway? What was wrong with SVN? gr. Ronald ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Moving to git
On Tue, Oct 6, 2009 at 8:23 AM, Ronald Vanschoren wrote: >>!!! And if anyone objects to GIT, please speak up ASAP !!! > > Why are we moving to GIT anyway? What was wrong with SVN? Did you read up on git? http://git.or.cz/gitwiki/GitSvnComparsion -- Ø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] Moving to git
I did not but I have now and tbh I'm not impressed. Sure git has some advantages, but do we really care about the distributed nature, better branch support, higher performance and other things? What I read was: >Also not mentioned are Subversion's support for http(s) and WebDAV, and its excellent support for Windows (in stark contrast to git's) Please keep in mind some people are using Windows here. I hope it's not going to be a mess to get the latest OpenOCD sources or sync with the repository. gr. Ronald Original Message Subject: [Openocd-development] Moving to git From: Øyvind Harboe To: Ronald Vanschoren Cc: openocd-development@lists.berlios.de Date: Tue Oct 06 2009 08:24:34 GMT+0200 (Romance Standard Time) On Tue, Oct 6, 2009 at 8:23 AM, Ronald Vanschoren wrote: !!! And if anyone objects to GIT, please speak up ASAP !!! Why are we moving to GIT anyway? What was wrong with SVN? Did you read up on git? http://git.or.cz/gitwiki/GitSvnComparsion ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Moving to git
> 1. Berlios svn will be made read only and the svn head will be "deleted", > leaving behind only a README w/reference to the openocd project at > sourceforge. The entire svn history will remain available on Berlios > indefinitely. Question from a dumb-ass: Is the entire repository (including all branches and tags) moved to SF or just head? Nico Coesel ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Berlios outage
Hi Dirk, --- Dirk Behme schrieb am Mo, 5.10.2009: > Rolf, could you try if > > git clone http://git.gitorious.org/u-boot-omap3/mainline.git > > works for you? > Yes, that works for me! I can successfully clone this very small project on github, too: http://github.com/tekkub/addontemplate.git > Most probably you have to set > > export > http_proxy=http://:@: > > for this. This seems to be the only required setting to make it work. I run Squid on my local machine, and I have http_proxy=http://localhost:8080 set here. GIT honors that setting, and I don't have to configure it explicitly with 'git config http.proxy'. My vote is for a server that supports http for read-only access :-) Regards, Rolf ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] need help with config file
On Saturday 03 October 2009, John Rigby wrote: > You were right about the ir lengths, but I also had to put back in the code > that ignores non b01 for taps with 0 ids. The i.mx31 has the same weird tap > with no id and no b01 in the capture. Hmm. I changed the diagnostics a bit in a recent patch, and that leaves it in a good position to just switch over to using the value and mask provided with TAP declaration. Doing it that way ... and the i.mx31 and i.mx25 could both just declare a capture value (or mask!) of zero and have it all work OK -- right? If so, could you work up a patch which does it that way? I suspect that could merge in time for the 0.3.x release, then. Thing is, we do have wierd hardware to cope with and so we evidently need to relax that test. But the original code was a hack since it relaxed it for *everything* instead of just for the minority of cases which really needed it. And on top of that, there was no comment explaining what class of wierdness was involved... - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Moving to git
On Monday 05 October 2009, Ronald Vanschoren wrote: > Please keep in mind some people are using Windows here. There are quite a few folk using git from Windows... Not three hours ago I pulled a repository onto an XP machine (via cygwin). The build breakage was completely unrelated to GIT. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Moving to git
On Monday 05 October 2009, Nico Coesel wrote: > Is the entire repository (including all branches and tags) > moved to SF or just head? Right now there are git-svn repositories that have whatever could be imported, but I think just the trunk is at SF. Is there anything in those branches/etc that's of more than historical interest? AFAICT only the Zylin branch has been active for the last year or more. And that can be a branch in their local repository; doesn't need to be in mainline. - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
