I've given some thought on how users can figure out if a part
is supported by OpenOCD.
There are thousands of flash/target types & combinations out there.
The user may have the part number or some other string to describe
his flash or target.
There are two things that I'd like to see:
- the use
Ironically, resisting the CMake patch, might the best
way to get people to stand up and report their interst ;-)
I'm starting to be more convinced that having both
committed to svn is not detrimental to OpenOCD,
the crowd is growing and you're getting some good
names on board.
Magnus worded my at
W.r.t. testing, please note that Michael Fischer recently
ran through his testsuite and it all passed...
He didn't commit the test results to the testing folder though...
--
Øyvind Harboe
Embedded software and hardware consulting services
http://consulting.zylin.com
___
Magnus Lundin wrote:
> Dick Hollenbeck wrote:
>
>> Magnus Lundin wrote:
>>
>>> The tap state engine will not change any time soon.
>>>
>>> Hopefully the statenumbers will stay.
>>>
>>> But there will probably be work on shortest path tables, path
>>> transition tables with fixed mumber of
Magnus Lundin escreveu:
Alain M. wrote:
Zach Welch escreveu:
I am new to this list and the second motive that I am here is this:
When I use OpenOCD to write a flash (CortexM3) the second Serial port of
the FT2232D has it's baudrate changed. (OpenOCD 1.0, FTDI's lib, on Linux)
This is
Alain M. wrote:
> Zach Welch escreveu:
>
>> Hi all,
>>
>> Here is the current list of outstanding tasks for the OpenOCD project.
>>
>
> I am new to this list and the second motive that I am here is this:
>
> When I use OpenOCD to write a flash (CortexM3) the second Serial port of
> the FT2
Dick Hollenbeck wrote:
> Magnus Lundin wrote:
>> The tap state engine will not change any time soon.
>>
>> Hopefully the statenumbers will stay.
>>
>> But there will probably be work on shortest path tables, path
>> transition tables with fixed mumber of tap transition etc. For this
>> type of wo
Zach Welch escreveu:
> Hi all,
>
> Here is the current list of outstanding tasks for the OpenOCD project.
I am new to this list and the second motive that I am here is this:
When I use OpenOCD to write a flash (CortexM3) the second Serial port of
the FT2232D has it's baudrate changed. (OpenOCD
Jeff Williams a écrit :
> If MC1322x standard then good luck getting it to work. Trust me, this
> is not a trivial matter. It took me almost a month to figure it out,
> and this is after smart, seasoned people had already broken their
> picks on it.
>
> But there's no point in debating - th
Magnus Lundin wrote:
> The tap state engine will not change any time soon.
>
> Hopefully the statenumbers will stay.
>
> But there will probably be work on shortest path tables, path transition
> tables with fixed mumber of tap transition etc. For this type of work I
> think an array is a better
Magnus Lundin wrote:
> OK, I am a developer, I am lazy and my only strong feelings about build
> systems is "I dont care, I dont want to know, and a do not want to
> learn". Sure, sometimes we have to do this and perfect builds with
> clean installations for every platform is an art to admire a
I think there should be proper attribution for the B8_ macros, after
searching a bit this seems to be the original author.
/*
B8__ macros from the public domain contributions of
*/
OR
/* Binary constant generator macro
By Tom Torfs - donated to the public domain
*/
http://cprog.tomsweb.ne
On Wed, Apr 22, 2009 at 7:52 PM, Øyvind Harboe wrote:
> One annoying problem is that all target hardware is
> not available to all OpenOCD developers.
You said testing, and my mind just jumped to the test cases from the
testing folder. There has been about a year since the last
modification. I do
On Wed, Apr 22, 2009 at 12:03:30PM -0700, Zach Welch wrote:
> On Wed, 2009-04-22 at 11:50 -0700, Zach Welch wrote:
> > Hi all,
> >
> > This is the second of the two patches provided by Jeff Williams,
> > re-based against r1509. I have barely glanced through it for now, as
> > the old patch simply
OK, I am a developer, I am lazy and my only strong feelings about build
systems is "I dont care, I dont want to know, and a do not want to
learn". Sure, sometimes we have to do this and perfect builds with
clean installations for every platform is an art to admire and respect.
I have tried to
Zach Welch wrote:
> On Wed, 2009-04-22 at 16:04 -0500, Dick Hollenbeck wrote:
>
>> Zach Welch wrote:
>>
>>> On Wed, 2009-04-22 at 14:51 -0500, Dick Hollenbeck wrote:
>>>
>>>
>> Nice work Zach.
>>
>>
>>
> Thanks Dick. But nothing else
This was posted to another project and it lists some nice things about
CMake:
1) you can run ccmake (yes, extra c in front) to fine tune the
configuration options interactively if your first choices are wrong,
inside a nice GUI.
2) you can run cmake to do out of tree builds. This is
nice
On Wed, 2009-04-22 at 16:04 -0500, Dick Hollenbeck wrote:
> Zach Welch wrote:
> > On Wed, 2009-04-22 at 14:51 -0500, Dick Hollenbeck wrote:
> >
> Nice work Zach.
>
>
> >>> Thanks Dick. But nothing else for me to add? :)
> >>>
> >>>
> >> Yes, I would ask th
On Wed, 2009-04-22 at 23:17 +0200, Piotr Esden-Tempski wrote:
> Hi!
>
> On Apr 22, 2009, at 10:34 PM, Zach Welch wrote:
>
> > On Wed, 2009-04-22 at 20:08 +0200, Piotr Esden-Tempski wrote:
> > [snip]
> >> In earlier versions of the tree this file was generated
> >> automatically.
> >> Using the
Dick Hollenbeck wrote:
>> That could be worked around by using C99 initializers. I am not fond of
>> replacing a small amount of static data with a bigger chunk of code.
>>
>
> Are you thinking it is bigger because it looks bigger in your editor,
> or bigger because it generates more code?Sw
The tap state engine will not change any time soon.
Hopefully the statenumbers will stay.
But there will probably be work on shortest path tables, path transition
tables with fixed mumber of tap transition etc. For this type of work I
think an array is a better and less error prone representati
Michael Schwingen wrote:
> Dick Hollenbeck wrote:
>
>> I nak the arrays. I hate them, they are a crash waiting to happen.
>>
>>
> Why?
>
>
>> Put the same logic into a series of switches please, nested if necessary.
>>
>> Switches reads better, and are less subject to breakage. We j
On Wed, 2009-04-22 at 22:40 +0200, Øyvind Harboe wrote:
> On Wed, Apr 22, 2009 at 10:34 PM, Zach Welch wrote:
> > On Wed, 2009-04-22 at 14:51 -0500, Dick Hollenbeck wrote:
> >> >> Nice work Zach.
> >> >>
> >> >
> >> > Thanks Dick. But nothing else for me to add? :)
> >> >
> >>
> >>
> >> Yes, I wo
On Wed, 22 Apr 2009 22:59:31 +0200
Michael Schwingen wrote:
> Zach Welch wrote:
> > I love it. Positively love it.
> >
> Mee Too!
> > Of course, you say that you want to do this for remote development over
> > the internet. Ummm I have to reach over and physically reset my
> > target
Hi!
On Apr 22, 2009, at 10:34 PM, Zach Welch wrote:
On Wed, 2009-04-22 at 20:08 +0200, Piotr Esden-Tempski wrote:
[snip]
In earlier versions of the tree this file was generated
automatically.
Using the ./configure option --enable-maintainer-mode one can force
the generation of doc/version.te
Dick Hollenbeck wrote:
> I nak the arrays. I hate them, they are a crash waiting to happen.
>
Why?
> Put the same logic into a series of switches please, nested if necessary.
>
> Switches reads better, and are less subject to breakage. We just
> changes the values of the #defines in the last
Zach Welch wrote:
> On Wed, 2009-04-22 at 14:51 -0500, Dick Hollenbeck wrote:
>
Nice work Zach.
>>> Thanks Dick. But nothing else for me to add? :)
>>>
>>>
>> Yes, I would ask that folks *try* out the CMake support.
>>
>>
>> I think they have the potentia
Zach Welch wrote:
> I love it. Positively love it.
>
Mee Too!
> Of course, you say that you want to do this for remote development over
> the internet. Ummm I have to reach over and physically reset my
> target or JTAG interface on occasion. I love the enthusiasm, but there
> are some
On Apr 22, 2009, at 1:34 PM, Zach Welch wrote:
On Wed, 2009-04-22 at 20:08 +0200, Piotr Esden-Tempski wrote:
[snip]
In earlier versions of the tree this file was generated
automatically.
Using the ./configure option --enable-maintainer-mode one can force
the generation of doc/version.texi. I
On Wed, Apr 22, 2009 at 10:34 PM, Zach Welch wrote:
> On Wed, 2009-04-22 at 14:51 -0500, Dick Hollenbeck wrote:
>> >> Nice work Zach.
>> >>
>> >
>> > Thanks Dick. But nothing else for me to add? :)
>> >
>>
>>
>> Yes, I would ask that folks *try* out the CMake support.
>>
>>
>> I think they have t
On Wed, 2009-04-22 at 20:08 +0200, Piotr Esden-Tempski wrote:
[snip]
> In earlier versions of the tree this file was generated automatically.
> Using the ./configure option --enable-maintainer-mode one can force
> the generation of doc/version.texi. I am not sure what the right fix
> here should be
On Wed, 2009-04-22 at 14:51 -0500, Dick Hollenbeck wrote:
> >> Nice work Zach.
> >>
> >
> > Thanks Dick. But nothing else for me to add? :)
> >
>
>
> Yes, I would ask that folks *try* out the CMake support.
>
>
> I think they have the potential to help some Windows folks who might
>
On Wed, 2009-04-22 at 14:31 -0500, Dick Hollenbeck wrote:
> Zach Welch wrote:
> > On Wed, 2009-04-22 at 11:07 -0700, Rick Altherr wrote:
> > [snip]
> >
> >> This is an interesting idea, but I think it skips an important step.
> >> There seem to be a number of problems solely within the JTAG a
On Wed, 2009-04-22 at 14:35 -0500, Dick Hollenbeck wrote:
> Zach Welch wrote:
> > Hi all,
> >
> > Unless I accidentally missed something, the attached patches provide the
> > last _functional_ changes in Jeff Williams' J-Link patch; my final task
[snip]
> I nak the arrays. I hate them, they are a
>> Nice work Zach.
>>
>
> Thanks Dick. But nothing else for me to add? :)
>
Yes, I would ask that folks *try* out the CMake support.
I think they have the potential to help some Windows folks who might
get roadblocked at cygwin requirements.
>
>> Maybe this file can be put int
Zach Welch wrote:
> Hi all,
>
> Unless I accidentally missed something, the attached patches provide the
> last _functional_ changes in Jeff Williams' J-Link patch; my final task
> will be to extract and apply the debugging improvements that he made, as
> it looks like they will then need to be imm
Zach Welch wrote:
> On Wed, 2009-04-22 at 11:07 -0700, Rick Altherr wrote:
> [snip]
>
>> This is an interesting idea, but I think it skips an important step.
>> There seem to be a number of problems solely within the JTAG and
>> interface layers. It would be great if someone constructed so
Zach Welch wrote:
> On Wed, 2009-04-22 at 19:52 +0200, Øyvind Harboe wrote:
>
>> One annoying problem is that all target hardware is
>> not available to all OpenOCD developers.
>>
>> For development purposes, this could perhaps be
>> addressed by creating a JTAG over TCP/IP protocol.
>>
>> The i
> I love it. Positively love it.
>
> I have a strong networking background, so I could whip up an example
> some free afternoon. I do not see why it would be slow.
JTAG needs *fast* roundtrip times
> Of course, you say that you want to do this for remote development over
> the internet. Um
"SimonQian" writes:
>Hi,
>
>How about adding support to other microcontrollers for example AVR and
>C8051F.
It would of course be great to extend openocd to other architectures.
For AVR programming there is already the excellent open source avrdude project.
But it would be nice to
> If AVR programming support comes to exists in OpenOCD, someone might
> then be motivated to find a way to then support the debugging protocol.
To add these support is not difficult, just as what I did to svf player.
Svf player is originally implemented in vsprog.
There is only one way to get thes
On Wed, 2009-04-22 at 11:50 -0700, Zach Welch wrote:
> Hi all,
>
> This is the second of the two patches provided by Jeff Williams,
> re-based against r1509. I have barely glanced through it for now, as
> the old patch simply had some fuzz in it. I thought I should try to
> re-post it to see if
Hi all,
This is the second of the two patches provided by Jeff Williams,
re-based against r1509. I have barely glanced through it for now, as
the old patch simply had some fuzz in it. I thought I should try to
re-post it to see if the community will start to do something with it
(e.g. review it
Hi all,
Unless I accidentally missed something, the attached patches provide the
last _functional_ changes in Jeff Williams' J-Link patch; my final task
will be to extract and apply the debugging improvements that he made, as
it looks like they will then need to be immediately put into use.
The
On Wed, 2009-04-22 at 11:07 -0700, Rick Altherr wrote:
[snip]
> This is an interesting idea, but I think it skips an important step.
> There seem to be a number of problems solely within the JTAG and
> interface layers. It would be great if someone constructed some
> infrastructure for a re
On Wed, 2009-04-22 at 19:52 +0200, Øyvind Harboe wrote:
> One annoying problem is that all target hardware is
> not available to all OpenOCD developers.
>
> For development purposes, this could perhaps be
> addressed by creating a JTAG over TCP/IP protocol.
>
> The idea is that OpenOCD adds a TCP
Committed.
Thanks!
--
Øyvind Harboe
Embedded software and hardware consulting services
http://consulting.zylin.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
- restore indentation that was flattened by a previous commit
- disable IRQs while stepping
- add "arm11 step_irq_enable true/false" command that enables IRQs
during stepping
- add "arm11 no_increment true/false" command to allow reading/writing
data blocks from/to a fixed address (for example a
Hi!
There seems to be a problem with the current svn version of openocd
(revision 1509). The file doc/version.texi is not being generated.
Here is the error log:
Making all in doc
restore=: && backupdir=".am$$" && \
am__cwd=`pwd` && cd . && \
rm -rf $backupdir && mkdir $back
On Wed, Apr 22, 2009 at 10:55:06AM -0700, Rick Altherr wrote:
>
> git makes the merging easier, but there is still the people problem of
> finding the development branch to try it out.
Then in that case I highly recommend to anyone who wants to use open
tools with the mc1322x series of parts to
On Apr 22, 2009, at 10:52 AM, Øyvind Harboe wrote:
One annoying problem is that all target hardware is
not available to all OpenOCD developers.
For development purposes, this could perhaps be
addressed by creating a JTAG over TCP/IP protocol.
The idea is that OpenOCD adds a TCP/IP server
that
On Apr 22, 2009, at 10:24 AM, Mariano Alvira wrote:
On Wed, Apr 22, 2009 at 10:19:06AM -0700, Rick Altherr wrote:
Can we just open a branch in the main OpenOCD repo instead? Having
separate repos just make it more difficult to track things down and
do
merges.
I think git makes this eas
One annoying problem is that all target hardware is
not available to all OpenOCD developers.
For development purposes, this could perhaps be
addressed by creating a JTAG over TCP/IP protocol.
The idea is that OpenOCD adds a TCP/IP server
that accepts JTAG commands.
Those with target hardware can
On Wed, Apr 22, 2009 at 10:19:06AM -0700, Rick Altherr wrote:
>
> Can we just open a branch in the main OpenOCD repo instead? Having
> separate repos just make it more difficult to track things down and do
> merges.
>
I think git makes this easy. This way you can do your thing and I can
do mi
Committed.
Thanks!
--
Øyvind Harboe
Embedded software and hardware consulting services
http://consulting.zylin.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
The attached file fixes a signed/unsigned incompatibility in server.c on cygwin.
The 3rd parameter to accept uses a pointer to the type socklen_t.
socklen_t is defined as int on cygwin, the invalid code uses unsigned instead.
Michael
server-socklen_t-r1509
Description: Binary data
On Apr 22, 2009, at 8:56 AM, Alain M. wrote:
Hi, I am nnew here and it seems that I landed in the middle of a
turnmoil... not uncommon in OpenSource and better handled then most :)
I am here for 2 primary reasons, let's start:
Øyvind Harboe escreveu:
We have discussed adding release branches
On Apr 22, 2009, at 9:46 AM, Mariano Alvira wrote:
On Tue, Apr 21, 2009 at 07:55:46PM -0700, Zach Welch wrote:
* MC1322x target support
- integrate and test support from Jeff and Duane
- get working with a known good interface (i.e. not today's jlink)
I plan to be working on this (hi every
On Tue, Apr 21, 2009 at 07:55:46PM -0700, Zach Welch wrote:
>
> * MC1322x target support
> - integrate and test support from Jeff and Duane
> - get working with a known good interface (i.e. not today's jlink)
>
I plan to be working on this (hi everyone. I haven't posted yet, but
have been li
On Wed, 2009-04-22 at 11:41 -0500, Dick Hollenbeck wrote:
> Zach Welch wrote:
> > Here is the current list of outstanding tasks for the OpenOCD project.
> >
>
>
> Nice work Zach.
Thanks Dick. But nothing else for me to add? :)
> Maybe this file can be put into the top dir of the repository
I was wondering if it makes sense to utilize the facilities on the
berliOS developer site that includes a section for bugs, features, and
patches. It might help to not only inform people curious about the
project what is being developed, but it will also aid in managing
features and bugs as th
On Wed, 2009-04-22 at 23:52 +0800, SimonQian wrote:
> Hi,
> How about adding support to other microcontrollers for example AVR and
> C8051F.
> Although debugging protocol is not open, but programming protocol is.
I hereby propose the mission statement for the OpenOCD project to be:
"OpenOCD will
Zach Welch wrote:
> Here is the current list of outstanding tasks for the OpenOCD project.
>
Nice work Zach.
Maybe this file can be put into the top dir of the repository so it can
evolve more easily than it can by reworking deleted email messages.
Is this a good idea? The problem then is
Hi, I am nnew here and it seems that I landed in the middle of a
turnmoil... not uncommon in OpenSource and better handled then most :)
I am here for 2 primary reasons, let's start:
Øyvind Harboe escreveu:
> We have discussed adding release branches though. Release
> branches never happened becau
Great work!
I think it is important to point out that although there
is something akin to an official wish-list, the thing that
really drives things forward is quality patches.
If someone posts a patch that moves OpenOCD in the
right general direction without breaking anybody, then
that patch is
Hi,
How about adding support to other microcontrollers for example AVR and C8051F.
Although debugging protocol is not open, but programming protocol is.
I implement AVR_JTAG and C8051F_JTAG in my project vsprog.
Actually vsprog can support many other MCUs, but OpenOCD can currently only
handle wi
Hi all,
Here is the current list of outstanding tasks for the OpenOCD project.
In this revision, I have tried to incorporate all of the feedback from
the group since my last posting ("my tech proposal"). I reorganized the
order and updated items to improve both clarity and brevity (though that
c
On Wed, 2009-04-22 at 09:01 -0500, Dick Hollenbeck wrote:
> Magnus Lundin wrote:
> > The only reason I can think of for a specic numbering is that it might
> > optimize the gate design in a hardware implementation of the tap state
> > engine. But this is not a problem for us so thats OK. If we w
Nico Coesel wrote:
> Zach,
>
>> CC: Openocd-Dev
>> Onderwerp: Re: [Openocd-development] my tech proposal
>>
>> On Wed, 2009-04-22 at 10:35 +0200, Nico Coesel wrote:
>>> Zach,
>>> There are a few things missing on your list which I think
>> are important:
>>> - Coldfire support (which is basically
Magnus Lundin wrote:
> The only reason I can think of for a specic numbering is that it might
> optimize the gate design in a hardware implementation of the tap state
> engine. But this is not a problem for us so thats OK. If we want to
> follow JTAG documentation standards (ARM ane IEEE) in ou
Hi all,
This patch removes the code that adds TMS padding, based on bits from
Jeff Williams' patch. It does not appear to break (or fix) anything.
Please apply.
Cheers,
Zach
Index: src/jtag/jlink.c
===
--- src/jtag/jlink.c (revisio
On Wed, Apr 22, 2009 at 2:17 PM, Zach Welch wrote:
> On Wed, 2009-04-22 at 13:00 +0200, Øyvind Harboe wrote:
>> >> - New targets?
>> >
>> > Any that you have in mind? Coldfire and Cortex are on thanks to Nico.
>> > MC1322x from Jeff. I have added an "insert your target here" item.
>>
>> arm11 ha
On Wed, 2009-04-22 at 13:00 +0200, Øyvind Harboe wrote:
> >> - New targets?
> >
> > Any that you have in mind? Coldfire and Cortex are on thanks to Nico.
> > MC1322x from Jeff. I have added an "insert your target here" item.
>
> arm11 has a lot of support already, but could need more love...
Ca
On Wed, 2009-04-22 at 17:34 +0600, Alexei Babich wrote:
> Hello everybody.
> Does OpenOCD support such OEM version of JLink JTAG stub as following:
> SAM-ICE, version 5.2; blue-box, made for Atmel; USB ID 1366:0101
Hi Alexei,
I am actively working on fixing outstanding bugs in the OpenOCD J-Link
Hello everybody.
Does OpenOCD support such OEM version of JLink JTAG stub as following:
SAM-ICE, version 5.2; blue-box, made for Atmel; USB ID 1366:0101
Thanks.
--
Regards,
Alexei Babich, circuit design engineer, Rezonans plc., Chelyabinsk, Russia
http://www.rez.ru
Jabber ID: imp...@jabber.ru
___
Committed.
Thanks!
--
Øyvind Harboe
Embedded software and hardware consulting services
http://consulting.zylin.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
On Wed, 2009-04-22 at 01:29 -0700, Zach Welch wrote:
> Hi all,
>
> This one-liner comes from Jeff Williams' patch. It simply calls
> jlink_speed at the end of jlink_init. Please apply.
Did this patch get overlooked?
--Z
___
Openocd-development mailin
On Wed, 2009-04-22 at 12:59 +0200, Nico Coesel wrote:
[snip]
> I looked at the BDM project Xiaofan posted. It seems like a good
> starting point. It also has routines for external flash. Maybe its worth
> to look into it to get some fresh ideas on the cfi implementation as
> well. I used to have a
>> - New targets?
>
> Any that you have in mind? Coldfire and Cortex are on thanks to Nico.
> MC1322x from Jeff. I have added an "insert your target here" item.
arm11 has a lot of support already, but could need more love...
--
Øyvind Harboe
Embedded software and hardware consulting service
Committed.
Thanks!
--
Øyvind Harboe
Embedded software and hardware consulting services
http://consulting.zylin.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Zach,
> CC: Openocd-Dev
> Onderwerp: Re: [Openocd-development] my tech proposal
>
> On Wed, 2009-04-22 at 10:35 +0200, Nico Coesel wrote:
> > Zach,
> > There are a few things missing on your list which I think
> are important:
> >
> > - Coldfire support (which is basically an enhanced 68000
>
On Wed, 2009-04-22 at 08:04 +0200, Øyvind Harboe wrote:
> Great posting! Can I suggest that you create this as a patch against
> svn so we can match up the todo.txt list against an actual version of
> the OpenOCD svn history?
Can't I simply claim that it's on The List? ;) I definitely agree that
On Wed, Apr 22, 2009 at 10:41 AM, Magnus Lundin wrote:
> The only reason I can think of for a specic numbering is that it might
> optimize the gate design in a hardware implementation of the tap state
> engine.
As long as the symbols are used then either a conversion table or some
other tinkering
Hi all,
The attached patch (part of Jeff Williams' work) improves the reset
functionality. It appears to do no harm when combined with the speed
init and state reordering patches; it does not get us out of the woods.
Please apply.
Cheers,
Zach
Index: src/jtag/jlink.c
===
Committed.
Thanks!
--
Øyvind Harboe
Embedded software and hardware consulting services
http://consulting.zylin.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Confirmed,
tmp is used as u32 in the following for loop.
The bug breaks the reg command and drscan out values (from
Jim_Command_drscan ) but it should not affect an idcode scan.
Patch applied.
Regards,
Magnus
Andy chenee wrote:
> hi:
>
> 1. for my test,the latest OpneOCD could not work well w
On Wed, 2009-04-22 at 17:43 +0800, Xiaofan Chen wrote:
> On Wed, Apr 22, 2009 at 5:33 PM, Zach Welch wrote:
> > These will appear in the next revision of my list. I have been thinking
> > about what I want my next "hobby" board to be, and the Cortex A8 has
> > been one possible choice. [[I am no
On Wed, Apr 22, 2009 at 5:33 PM, Zach Welch wrote:
> These will appear in the next revision of my list. I have been thinking
> about what I want my next "hobby" board to be, and the Cortex A8 has
> been one possible choice. [[I am now hoping a board vendor reads this,
> recognizes their opportun
On Wed, 2009-04-22 at 10:35 +0200, Nico Coesel wrote:
> Zach,
> There are a few things missing on your list which I think are important:
>
> - Coldfire support (which is basically an enhanced 68000 core) would be
> nice. There is no open source solution out there to program Coldfire
> controllers
On Wed, 2009-04-22 at 10:41 +0200, Magnus Lundin wrote:
> The only reason I can think of for a specic numbering is that it might
> optimize the gate design in a hardware implementation of the tap state
> engine. But this is not a problem for us so thats OK. If we want to
> follow JTAG documenta
The only reason I can think of for a specic numbering is that it might
optimize the gate design in a hardware implementation of the tap state
engine. But this is not a problem for us so thats OK. If we want to
follow JTAG documentation standards (ARM ane IEEE) in our code then the
state names
Zach,
There are a few things missing on your list which I think are important:
- Coldfire support (which is basically an enhanced 68000 core) would be
nice. There is no open source solution out there to program Coldfire
controllers which is a shame because the Coldfire controllers are
actually qui
Hi all,
This one-liner comes from Jeff Williams' patch. It simply calls
jlink_speed at the end of jlink_init. Please apply.
Cheers,
Zach
Index: src/jtag/jlink.c
===
--- src/jtag/jlink.c (revision 1504)
+++ src/jtag/jlink.c (workin
Hi all,
This patch -- also derived from Jeff Williams' work -- reorders the enum
tap_state symbols to reflect the states used by most/all ARM parts.
I verified that these states match the documentation that I have here,
and I tested that nothing appears immediately broken. If I am right in
say t
On Apr 22, 2009, at 12:22 AM, Zach Welch wrote:
Hi all,
This is another easy to extract portion of patch Jeff Williams' patch.
It reduces the buffers to the 2KB specified in the specification.
I have not tested it, but I verified that the specification says 2KB.
It does, so this seems like it
On Apr 15, 2009, at 1:01 AM, Piotr Esden-Tempski wrote:
Hi,
Here is a patch adding support for the ftdichip.com ftd2xx library
under MAC OS X. I tested it on my machine, but still something may
break. This still are autotools and they love to misbehave. ^^
Cheers Esden
--
My blog: http:/
Hi all,
This is another easy to extract portion of patch Jeff Williams' patch.
It reduces the buffers to the 2KB specified in the specification.
I have not tested it, but I verified that the specification says 2KB.
It does, so this seems like it has the potential to have an impact.
Cheers,
Zach
On Wed, 2009-04-22 at 00:05 -0700, Rick Altherr wrote:
[snip]
> I'm going to hold off on this one. We don't have an established
> standard for comment-based navigational aids. I've used a few
> different styles over the years and each project seems to have a
> different preferred form. I'm
On Apr 21, 2009, at 11:34 PM, Zach Welch wrote:
Hi all,
This trivial patch adds comment rulers to aid navigation. It will
apply
cleanly on top of the previous patch to factor jlink_execute_queue.
This is my last cosmetic improvement for now, as I have started to
pull
out the pieces fro
99 matches
Mail list logo
