Michel> The official configuration doesn't work with Linux.
I've just checked in a patch that *should* rectify this problem.
Can you clarify what does and does not work now.
I don't have a linux box to try this against. {My linux box is in my
basement, I connect to it remotely}
-Duane.
__
duane> Fixed - I just committed a patch that automatically attempts both the
duane> "A" and "non-space-A" descriptions.
kees> does that mean we can remove the "with A's " from svn?
I believe so...
Actually the way the patch works is this:
First try "A"
If that fails, then try "A"
The "
Øyvind Harboe a écrit :
>> Ugh. Can we fix this once and for all? Win32 adds the A, Linux and OS X do
>> not. Perhaps we should just introduce a global variable in the TCL that
>> defines the platform type. Similar to __LINUX__, __WIN32__, __DARWIN__ that
>> gcc emits. Then the problematic dev
On Sat, Mar 7, 2009 at 4:55 PM, Duane Ellis wrote:
> ???> I think the attached patch is OK, because it is a variable
> ???> that can take on some carefully defined values. Documentation
> ???> should go with this variable as well...
>
> holger> You still have to change all the interface tcl script
???> I think the attached patch is OK, because it is a variable
???> that can take on some carefully defined values. Documentation
???> should go with this variable as well...
holger> You still have to change all the interface tcl scripts.
Fixed - I just committed a patch that automatically attem
duane> [ patch introducing "HostOS"]
Committed, along with a Documentation patch.
Actual names are shown below.
-Duane.
#if defined( _MSC_VER )
/* WinXX - is generic, the forward
* looking problem is this:
*
* "win32" or "win64"
*
* "winxx" is generic.
*/
On Mar 2, 2009, at 4:48 PM, Duane Ellis wrote:
Rick >> I like the patch already presented. rick >> ... Windows be
represented as "win32".
And then "win64" - and
Hence, WinXX .
It gets messy :-(
-duane
Win32 tends to correspond to the API, not the actual OS running.
People sti
Rick >> I like the patch already presented.
rick >> ... Windows be represented as "win32".
And then "win64" - and
Hence, WinXX .
It gets messy :-(
-duane
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.b
holger> Still this patch exports the OS to tcl. It does by itself
You have a good point.
I suspect this patch will be "useful for other purposes moving forward".
Meanwhile, a simple fix in the ftd2332.c file should be done also.
-Duane.
___
Openocd-d
> Rick Altherr> Can we fix this once and for all?
> [snip]
> Rick Altherr> ... a global variable in the TCL [snip]
> similar to __LINUX__, __WIN32__, __DARWIN__
>
> Oyvind> I don't particularly like the idea of opening up for
> communication between the OS and Tcl.
>
looks good except for b
On Mar 2, 2009, at 6:12 AM, Holger Schurig wrote:
I think the attached patch is OK, because it is a variable
that can take on some carefully defined values. Documentation
should go with this variable as well...
Still this patch exports the OS to tcl. It does by itself
nothing. You still have
> I think the attached patch is OK, because it is a variable
> that can take on some carefully defined values. Documentation
> should go with this variable as well...
Still this patch exports the OS to tcl. It does by itself
nothing. You still have to change all the interface tcl scripts.
In my
Duane Ellis wrote:
> Rick Altherr> Can we fix this once and for all? [snip]
> Rick Altherr> ... a global variable in the TCL [snip] similar to
> __LINUX__, __WIN32__, __DARWIN__
>
> Oyvind> I don't particularly like the idea of opening up for
> communication between the OS and Tcl.
>
> The atta
On Mon, Mar 2, 2009 at 2:55 PM, Duane Ellis wrote:
> Rick Altherr> Can we fix this once and for all? [snip]
> Rick Altherr> ... a global variable in the TCL [snip] similar to __LINUX__,
> __WIN32__, __DARWIN__
>
> Oyvind> I don't particularly like the idea of opening up for communication
> betwe
Rick Altherr> Can we fix this once and for all?
[snip]
Rick Altherr> ... a global variable in the TCL [snip] similar to
__LINUX__, __WIN32__, __DARWIN__
Oyvind> I don't particularly like the idea of opening up for
communication between the OS and Tcl.
The attached patch is really all that
Hi
On Mon, Mar 2, 2009 at 9:18 AM, Holger Schurig
wrote:
> On Sunday 01 March 2009 23:58:35 Rick Altherr wrote:
>> Ugh. Can we fix this once and for all? Win32 adds the A,
>> Linux and OS X do not.
For this specific problem perhaps we should simply rely on the
product/vendor name like
we do fo
On Sunday 01 March 2009 23:58:35 Rick Altherr wrote:
> Ugh. Can we fix this once and for all? Win32 adds the A,
> Linux and OS X do not.
If this is general, why let TCL handle this?
src/jtag/ft2232.c could contain code near
if (ft2232_device_desc)
{
openex_strin
I don't have a strong opinion about this, but I'm not sure how you would
make this work robustly.
Perhaps add a "configure" option with OS name that is visible in a
variable?
Perhaps a cfg file for each OS that is loaded before other config files?
linux.cfg could "set os linux", win32.cfg "set o
On Mar 1, 2009, at 11:19 PM, Øyvind Harboe wrote:
Ugh. Can we fix this once and for all? Win32 adds the A, Linux
and OS X do
not. Perhaps we should just introduce a global variable in the TCL
that
defines the platform type. Similar to __LINUX__, __WIN32__,
__DARWIN__ that
gcc emits. T
> Ugh. Can we fix this once and for all? Win32 adds the A, Linux and OS X do
> not. Perhaps we should just introduce a global variable in the TCL that
> defines the platform type. Similar to __LINUX__, __WIN32__, __DARWIN__ that
> gcc emits. Then the problematic devices can use the appropriate
On Mar 1, 2009, at 1:06 PM, ohar...@mail.berlios.de wrote:
Author: oharboe
Date: 2009-03-01 22:06:06 +0100 (Sun, 01 Mar 2009)
New Revision: 1393
Modified:
trunk/src/target/interface/jtagkey-tiny.cfg
Log:
Kees Jongenburger rename description
field of the jtag-tiny.cfg
Modified: trunk/src
21 matches
Mail list logo
