I've reverted to not using native end style on guess-rev.sh.
With native line style, Cygwin fails to execute guess-rev.sh if it
has been checked out by a Windows GUI.
oyv...@fury /cygdrive/c/workspace/openocd
$ sh guess-rev.sh
guess-rev.sh: line 3: $'\r': command not found
guess-rev.sh: line 5:
> Windows uses different line endings from Linux.
But Cygwin doesn't!
Consider a *common* situation. Use a Windows GUI to check out svn,
but build under Cygwin.
So if you use native line endings on .sh files, that breaks Cygwin!
Arrrggh!!! That was Arrgh to Cygwin/Windows, not to you :-)
--
On Tue, Jun 9, 2009 at 8:29 AM, Zach Welch wrote:
> On Tue, 2009-06-09 at 07:57 +0200, Øyvind Harboe wrote:
>> How about a clearer policy of using assert()'s?
>>
>> I'm thinking that error()'s should be reserved for "real" runtime errors.
>>
>>
>> > if (!tap_is_state_stable(path[num_states -
On Tue, 2009-06-09 at 07:57 +0200, Øyvind Harboe wrote:
> How about a clearer policy of using assert()'s?
>
> I'm thinking that error()'s should be reserved for "real" runtime errors.
>
>
> >if (!tap_is_state_stable(path[num_states - 1]))
> >{
> >LOG_ERROR("BUG: T
How about a clearer policy of using assert()'s?
I'm thinking that error()'s should be reserved for "real" runtime errors.
> if (!tap_is_state_stable(path[num_states - 1]))
> {
> LOG_ERROR("BUG: TAP path doesn't finish in a stable state");
> - exit(-1);
Øyvind Harboe wrote:
>> Which information do you need to get an idea what the beagle script is
>> expected to do?
>
> I can't dive into the OMAP stuff with the time I have for OpenOCD,
While this is fine (it's not different with me, else I would help more
;) ), I think we could try to improve de
On Mon, 2009-06-08 at 18:13 -0700, Zach Welch wrote:
[snip]
> Does anyone have the hardware for which this target configuration works
> as it is written? Would you like to work with me to factor the STR91x
> support in the tree into smaller pieces, such that we do not have to
> repeat the chip con
Hi all,
First, let me apologize for the mistaken extra changes in r2134.
While I have reverted them in 2135, they do reflect some cleanup and
touch-ups required to support my platform, and I have been meaning to
take some time to figure out how to integrate these properly. Since
this is the secon
On Mon, 2009-06-08 at 17:50 -0700, David Brownell wrote:
> Add configuration for an old AT91rm9200 board, the Cogent CSB 337.
> Worth noting from the OpenOCD perspective:
>
> - It got a real hardware trace port connector; wired up here as
>much as we can, lacking inexpensive trace-aware dongl
Add configuration for an old AT91rm9200 board, the Cogent CSB 337.
Worth noting from the OpenOCD perspective:
- It got a real hardware trace port connector; wired up here as
much as we can, lacking inexpensive trace-aware dongles.
- This is the first in-tree use of the "arm920t cp15" command
oyvind> [make monolithic config files illegal]
laurent> For me, it is a bad idea !
I also dislike it, it is often helpful for debug reasons.
-Duane.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/ma
Rick Altherr wrote:
>
>
>
> On Jun 8, 2009, at 3:03 PM, Gene Smith wrote:
>
>> Gene Smith wrote:
>>> Before trying to build I downloaded and installed the libusb stuff for
>>> win32 (usb.h and the library itself) as directed in the sparkfun faq.
>>>
>>> Also made sure all cygwin parts are up to
On Jun 8, 2009, at 3:03 PM, Gene Smith wrote:
Gene Smith wrote:
Before trying to build I downloaded and installed the libusb stuff
for
win32 (usb.h and the library itself) as directed in the sparkfun faq.
Also made sure all cygwin parts are up to date (make, automake,
autoconf
etc).
T
Gene Smith wrote:
> Before trying to build I downloaded and installed the libusb stuff for
> win32 (usb.h and the library itself) as directed in the sparkfun faq.
>
> Also made sure all cygwin parts are up to date (make, automake, autoconf
> etc).
>
> Then I did:
>
> make distclean
> ./bootstr
[snip]
> ==
>
> I was using it on a windows machine to which I don't have easy access at
> the moment, but I think it was as above. If you have no luck let me know
> I will find out my exact configuration.
>
> --
>
> John Devereux
Øyvind Harboe wrote:
>> Which information do you need to get an idea what the beagle script is
>> expected to do?
>>
>
> I can't dive into the OMAP stuff with the time I have for OpenOCD, so
> I'll await specific feedback. I just know that the endstate command
> was broken in seven different w
One thing that I'd like to see are more target config scripts
being fed back to the community
--
Øyvind Harboe
Embedded software and hardware consulting services
http://consulting.zylin.com
___
Openocd-development mailing list
Openocd-development@l
> Which information do you need to get an idea what the beagle script is
> expected to do?
I can't dive into the OMAP stuff with the time I have for OpenOCD, so
I'll await specific feedback. I just know that the endstate command
was broken in seven different ways.
There was a discussion on the ma
Øyvind Harboe wrote:
> Committed.
> Retired endstate(and updated docs). Background polling would
> overwrite any changes to the endstate. From the command
> line point of with the recent changes to ir/drscan the "endstate" command
> wasn't used anyway.
>
> The best I can do for the beagleboard con
Øyvind Harboe wrote:
> Why do you prefer to have the interface definition inside such
> config files?
>
It makes perfect sense if the interface is on the same board as the
target, as with many of the USB-dongle style evaluation kits
(STR9-comstick etc.).
> Why would you *not* want the interface
Before trying to build I downloaded and installed the libusb stuff for
win32 (usb.h and the library itself) as directed in the sparkfun faq.
Also made sure all cygwin parts are up to date (make, automake, autoconf
etc).
Then I did:
make distclean
./bootstrap
./configure --enable-maintainer-mod
"Thomas A. Moulton" writes:
> I am trying to program the Internal Flash of a ADuC7021
> with OpenOCD and an Olimex OpenOCD JTAG TINY A
>
> If I use the other tool chain (IAR) to program the part
> I can use OpenOCD to 'verify_image file 0 elf'
>
> But if I try to do a
>
> flash write_image file.e
On Monday 08 June 2009, Øyvind Harboe wrote:
> How about making it illegal to have the "interface" command
> together with "target"?
I'd say no, on the general principle that such policy
choices should in user hands.
> This would (strongly) encourage target files to be made independant
> of inte
I am trying to program the Internal Flash of a ADuC7021
with OpenOCD and an Olimex OpenOCD JTAG TINY A
If I use the other tool chain (IAR) to program the part
I can use OpenOCD to 'verify_image file 0 elf'
But if I try to do a
flash write_image file.elf 0 elf
It tells me there is no flash at 0
Øyvind Harboe wrote:
> Why do you prefer to have the interface definition inside such
> config files?
>
> Why would you *not* want the interface config file to come from
> OpenOCD's published configuration files for interaces?
>
>
>
> openocd -f interface/abc.cfg -f customerconfig.cfg
>
>
At th
Why do you prefer to have the interface definition inside such
config files?
Why would you *not* want the interface config file to come from
OpenOCD's published configuration files for interaces?
openocd -f interface/abc.cfg -f customerconfig.cfg
--
Øyvind Harboe
Embedded software and hard
>
> One thing I see on the net are monolithic config files where
> the configuration of the interface is mixed into the target
> configuration.
>
> How about making it illegal to have the "interface" command
> together with "target"?
>
> This would (strongly) encourage target files to be made indep
One thing I see on the net are monolithic config files where
the configuration of the interface is mixed into the target
configuration.
How about making it illegal to have the "interface" command
together with "target"?
This would (strongly) encourage target files to be made independant
of interf
28 matches
Mail list logo
