Excerpts from Øyvind Harboe's message of Tue Apr 05 07:25:36 +0100 2011:
> Are these ready to be merged?
I say yes, but comments from the list would be useful.
I haven't implemented as was suggested an instance struct for the
driver, choosing to use a global buffer, as is used in other drivers.
I
Excerpts from Peter Stuge's message of Sun Apr 03 13:24:39 +0100 2011:
> > > Your implementation seems extremely dangerous to me. You add a global
> > > buffer, which will get corrupted if more than one device is being
> > > used. Is there a "contract" from openocd core that there will never
> > >
On Apr 3, 2011 12:45 AM, "Peter Stuge" wrote:
>
> Ali Lown wrote:
> > Aah. After failing once by committing too early, I then did it again!!
>
> Look up the interactive rebase feature of git. I use it a lot to
> rework commits which are intentionally or unintentio
Aah. After failing once by committing too early, I then did it again!!
Scrap the 2 previous patches.
The one attached below (usb_blaster.patch) implements those 2 rolled
into 1, and then corrects a compile error too.
usb_blaster.patch
Description: Binary data
___
Attached are 2 patches.
Both need to be applied to enable compilation. (I commited the first
too early).
Together they implement:
-Significant speed improvements by commiting 64 jtag states to each usb
packet, instead of 1!
-Support for the LED (exists on my clone version. I assume it exists on
th
Excerpts from Tormod Volden's message of Tue Mar 29 21:58:30 +0100 2011:
> I would suggest shipping a HACKING or README.patches file that shows
> the "real" commands to do the above steps. Teach a man to fish...
I have to admit that in the long run that is a better suggestion.
If they are wishing
> How about adding a "contribute" script which did the following:
>
> - fetch from origin
> - commit changes from user, bringing up a text editor with
> a template commit message.
> - rebase origin to the master branch, abort if there are conflicts
>
I think it should make a new branch for them, t
Hmm, this looks like a case of WOMM, because given we are both testing
against the same file (the one you attached), and are both using the
git master, we should both/neither get this crash.
Looks like one of the buffers is becoming corrupt somehow, yet they are
all malloc'ing correctly.
Given it
Your svf file does fail with my patch. I had to increase it from 8x the
normal buffer size to 32x the normal buffer size, before it stopped
reporting buffer-to-small errors.
Then I simply get the:
Error: tdo check error at line 33
Error: read = 0x0, want = 0xF2618093, mask = 0xFFF
Error: fail
Noted with Xilinx svf files, (once my other patch is applied to let it
read the whole line), programming is _very_ slow.
I have adjusted usb_blaster.c to allow it to send a larger buffer all at
once when written (see attached patch), but this is not the main issue.
(Only tested with a CY7C68013A b
Hmm, well I can report that that patch alone let me successfully program
my FPGA.
> https://lists.berlios.de/pipermail/openocd-development/2011-February/018217.html
I am unable to download the attachment here, tar reports it isn't an
archive, so not sure what changes were made to try to emulate a
Xilinx ISE 13.1 produces svf files for Spartan XC3S50AN that are too
large for the buffer to hold -> causing it to fail to program.
Attached is a patch that simply increases the buffer size - I tried a
variety of sized buffers - they had no effect on the speed of
programming.
-Ali
buffer.patch
12 matches
Mail list logo
