Menu
▾
▴
xc3sprog-users — Generic user and developer list
You can subscribe to this list here.
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(4) |
Sep
|
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2007 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
(1) |
Aug
|
Sep
|
Oct
(2) |
Nov
(6) |
Dec
(1) |
| 2010 |
Jan
(5) |
Feb
(33) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(13) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(25) |
Sep
(8) |
Oct
(2) |
Nov
|
Dec
(3) |
| 2012 |
Jan
(2) |
Feb
(22) |
Mar
(1) |
Apr
(8) |
May
(8) |
Jun
(1) |
Jul
|
Aug
(1) |
Sep
(12) |
Oct
|
Nov
(9) |
Dec
(5) |
| 2013 |
Jan
|
Feb
(3) |
Mar
(5) |
Apr
(5) |
May
(2) |
Jun
(18) |
Jul
|
Aug
(2) |
Sep
(21) |
Oct
|
Nov
|
Dec
(2) |
| 2014 |
Jan
(6) |
Feb
(6) |
Mar
|
Apr
(1) |
May
(11) |
Jun
(1) |
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
(2) |
| 2015 |
Jan
|
Feb
|
Mar
(7) |
Apr
|
May
(6) |
Jun
(6) |
Jul
(2) |
Aug
|
Sep
|
Oct
(1) |
Nov
(6) |
Dec
(1) |
| 2016 |
Jan
|
Feb
|
Mar
|
Apr
(5) |
May
|
Jun
(5) |
Jul
(2) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(6) |
Nov
(1) |
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
(9) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2019 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2022 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Álvaro L. <alv...@al...> - 2011-09-25 18:16:03
|
Hi all, This is my first post to this list, and I'd like to thank all of you for the excellent work you are doing with this project. I've been using it (actually variants of it) for a long time, and I feel it's time to go mainline and contribute my changes for the project benefit. Right now I'm porting SST SPI flash programming algorithms to upstream. They are based on very old source code, and there were significant changes to BSCAN based approach - right now there is no way to do a full transfer (write+read) on same transaction. SST uses AAI programming (Auto Address Increment), and they support busy reply at end of each command. The latest BSCAN approach stores the last scanned-in result in BRAM, and we have to do another request in order to fetch last buffer reply (at least, that's how I understood it from the HDL sources). In order to speed up writes (each AAI command only programs 2 bytes at a time) having to check status register, or do another transaction, has a huge impact on write performance. My first suggestion (and I'll do implementation) is to have two modes when using BSCAN+SPI: one where SPI output is directly mapped to TDO output, and other which uses the current BRAM buffer. This can easily be implemented by a bit-mangling on the 32-bit header. So, at every request, you can specify whether you want the current value to be output, or the last scanned in value (as in current implementation) Questions, thoughts ? And again, thanks for your amazing work! Álvaro |
|
From: Joris v. R. <jo...@sr...> - 2011-09-17 17:22:38
|
Hi, I made a start with a Unix man page for xc3sprog. It's still lacking in detail and completeness. Please tell me what you think. One challenge will be to keep this page up to date while xc3sprog evolves. Some other thoughts: It seems that the -E and -F options currently have no real function. One of the supported file formats is called "MCS". However, the .MCS files that I get from IMPACT are in fact compatible with the "IHEX" style of xc3sprog, which is different from the "MCS" style. Do you know of a use for the "MCS" style? Otherwise it should be removed to avoid confusing users. I'd like to put a list of supported JTAG devices in the man page. As far as I know, all Spartan-3, Virtex-5, Spartan-6, XCFnnS and XCFnnP devices are supposed to work. What more? Virtex-2, Virtex-6, CoolRunner, AVR? Which types of SPI flash? Similarly, I'd like to make a list of supported JTAG cables, with full name and vendor. It would also be good to have such information on the web, so that potential new users can decide whether xc3sprog is suitable for their situation. Greetings, Joris. |
|
From: Uwe B. <bo...@el...> - 2011-08-31 11:02:50
|
>>>>> "Joris" == Joris van Rantwijk <jo...@sr...> writes:
...
Joris> Ok, let's try to fix it then. The attached patch makes
...
Applied. Thanks again for the patch. I tested against the simples case
(single XCF programming), and it works :-)
--
Uwe Bonnes bo...@el...
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
|
|
From: Joris v. R. <jo...@sr...> - 2011-08-30 19:38:32
|
On Sunday 28 August 2011, Uwe Bonnes wrote: > Yes, XCF can only be erased as one block. But with > bitfile.1.bit:W:offset0 and bitfile2.bit:W:offset1, the erase action > is skipped, so partial writing is possible. Ah, right. I was not aware of the difference between 'W' and 'w'. > Again, XCFP knows about revisions, so it's more than a niche feature > for SPI programmed devices alone. programXCF handles both XCF and > XCFP, so getting it right for XCF will fix XFCP too. Not really. The subrange feature is pushed down from programXCF to the actual ProgAlg code. ProgAlgXCF tries to handle subranges, but ProgAlgXCFP simply ignores them. > But a look at the present code may also be worth some effort. The > handling of "current_offset" in the (int i = 0; i < nchainpos; i++) > loop seems dubious... Ok, let's try to fix it then. The attached patch makes multi-PROM programming work again, and also tries to do the right thing about offset/rlength situations. Note that I have not really tested offset/rlength because I don't have a natural test case for it. I took the liberty to change/simplify a few other small things in ProgAlgXCF code; mostly integer signedness I think. Greetings, Joris. |
|
From: Uwe B. <bo...@el...> - 2011-08-30 10:41:33
|
>>>>> "Tomek" == Tomek CEDRO <tom...@gm...> writes:
Tomek> Hello Uwe, thank you for your support :-) Things has changes in
Tomek> xc3sprog since 449 release... :-)
Tomek> On Mon, Aug 29, 2011 at 7:38 PM, Uwe Bonnes
Tomek> <bo...@el...> wrote:
>> Bitrot: You have a working program on your disk, and trying to use it
>> after some time, nothing works any longer: Libraries have changed,
>> compilers get strikter, API changed, etc
>> http://en.wikipedia.org/wiki/Bit_rot#Problems_with_software
Tomek> Ah well this is why I definitely switched to FreeBSD - its not
Tomek> lazy Windows and its not Linux where things never work after week
Tomek> ;]
>> Something is fishy here. Are you sure you don't have some flaky JTAG
>> or SPI connection, a ringing JTAG cable, some heavy noise source, too
>> low supply voltage, a microcontroller addressing the SPI lines after
>> some time or something else?
Tomek> I can program bitfile directly into FPGA with no problem. The
Tomek> only problem is with uploading bitfile into SPI Flash.
>> Test the JTAG chain with the -T0 option, and probably -I -T0 should
>> test both JTAG and SPI.
Tomek> -T0 works fine but -I requires a filename so -I -T0 will not work
Tomek> in 635 release. The connection is fine :-)
So I suspect the SPI connections to be flaky.
Here is how I test the SPI chain of a new board:
load the ISP Bitfile:
> xc3sprog -c ftdijtag -T0 -I \
/spare/bon/xc3sprog/co/xc3sprog/trunk/bscan_spi/xc3s50an.bit
The FPGA should configure.
> xc3sprog -c ftdijtag -T0 -I
XC3SPROG (c) 2004-2011 xc3sprog project $Rev: 635 $ OS: Linux
Free software: If you contribute nothing, expect nothing!
Feedback on success/failure/enhancement requests:
http://sourceforge.net/mail/?group_id=170565
Check Sourceforge for updates:
http://sourceforge.net/projects/xc3sprog/develop
Using Libftdi,
JEDEC: 1f 22 0x00 0x00
status: 8c
Found Atmel Device, Device ID 0x2200: AT45DB011
Unique number:
506078a8b440f8440000c4f0fffffeff0c0c0c0a8c2cac8c500aecffffffffff
dcffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
264 bytes/page, 512 pages = 135168 bytes total
Running 2147483647 times
..........................................................................
Dots mean successfull test. Running for some minutes no error is reported
for my board.
Please try to reproduce for your board. Only if the JTAG and SPI chain work reliable
further errors are worth to look at.
Bye
--
Uwe Bonnes bo...@el...
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
|
|
From: Tomek C. <tom...@gm...> - 2011-08-29 20:19:19
|
On Mon, Aug 29, 2011 at 8:11 PM, Tomek CEDRO <tom...@gm...> wrote: >> Sorry that things work so hard with the end for your diplome work nearing... Naah things always get complicated when time is short and you don't want to use straightforward solution (i.e. closed source and windows) :-) :-) Your solution is the only sensible open-source workaround not to use iMPACT at all so I appreciate your work a lot! This is shame that such large corporation only made it possible to work with their devices on windows, because only on windows i have programmed that flash memory with success (and it had to be replaced first because on official xilinx spartan 3a-dsp board there was flash mounted that is and will be unsupported by xilinx ise!l). I had the same problem with using iMPACT and SVF replayed with UrJTAG, so I thought that this must be this way for the moment, but still fighting for better solution and thank to your support it might be possible! :-) Best regards, Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info |
|
From: Tomek C. <tom...@gm...> - 2011-08-29 20:11:27
|
Hello Uwe, thank you for your support :-) Things has changes in xc3sprog since 449 release... :-) On Mon, Aug 29, 2011 at 7:38 PM, Uwe Bonnes <bo...@el...> wrote: > Bitrot: You have a working program on your disk, and trying to use it after > some time, nothing works any longer: Libraries have changed, compilers get > strikter, API changed, etc > http://en.wikipedia.org/wiki/Bit_rot#Problems_with_software Ah well this is why I definitely switched to FreeBSD - its not lazy Windows and its not Linux where things never work after week ;] > Something is fishy here. > Are you sure you don't have some flaky JTAG or SPI connection, a ringing > JTAG cable, some heavy noise source, too low supply voltage, a > microcontroller addressing the SPI lines after some time or something else? I can program bitfile directly into FPGA with no problem. The only problem is with uploading bitfile into SPI Flash. > Test the JTAG chain with the -T0 option, and probably -I -T0 should test > both JTAG and SPI. -T0 works fine but -I requires a filename so -I -T0 will not work in 635 release. The connection is fine :-) > As explained before, define your cable in cablelist.txt. > > Slow down only helps in rare cases. E.g. a ringing TCK line may show double > clocking even on slowest JTAG frequencies, as ringing happens at the edges, > with edge rates remaining the same. With an on-board connector I didn't see > problems up to the max JTAG frequency of the slowest device, and AVR with 8 > MHz in my case. Cable connected adapters are something different. > > Try > <your cable> ftdi <your VID>:<your PID>: 1500000 This did not work > <your cable> ftdi <your VID>:<your PID>::1:0x00:0x10:0x00:0x0 1500000 This is working! Thank you for help in calbe configuration :-) Now I have problem to upload bitfile into flash. In older release I have first uploaded bscan_spi.bit into FPGA, then again started xc3sprog with -I mybitfile to pass this bitfile into SPI memory using bscan_spi.bit, but in the new release things seems different and I can only upload into FPGA. I have tried xc3sprog -v -c amontec bscan_spi.bit; xc3sprog -v -c amontec -I mybitfile.bit and this did not work, neither xc3sprog -v -c amontec bscan_spi.bit -I mybitfile.bit ... Please advise how to upload mybitfile into spi flash :-P :-) Best regards, Tomek > > The new scheme works better for people with standard cables, and custom > cables are added more easy. > > Sorry that things work so hard with the end for your diplome work nearing... > > Bye > -- > Uwe Bonnes bo...@el... > > Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt > --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- > -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info |
|
From: Uwe B. <bo...@el...> - 2011-08-29 19:39:01
|
>>>>> "Tomek" == Tomek CEDRO <tom...@gm...> writes:
Tomek> Hello Uwe :-) On Mon, Aug 29, 2011 at 4:16 PM, Uwe Bonnes
Tomek> <bo...@el...> wrote:
>> after fighting normal bitrot (see recent SVN checins)
Tomek> ? :-)
Bitrot: You have a working program on your disk, and trying to use it after
some time, nothing works any longer: Libraries have changed, compilers get
strikter, API changed, etc
http://en.wikipedia.org/wiki/Bit_rot#Problems_with_software
>> I can program the flash successfully. I also read back the flash of
>> the s3adspstarter kit, verified and reprogrammed.
Tomek> Uhm, the Amontec JTAGKey2P seems to be working far better and
Tomek> faster than Xilinx "USB Download Cable" (XUP?) because there are
Tomek> no errors during flash write, there are errors however on flash
Tomek> read, also the program does not start so the flashing fails. I
Tomek> have mounted ST 25P64 chip.
Something is fishy here.
Are you sure you don't have some flaky JTAG or SPI connection, a ringing
JTAG cable, some heavy noise source, too low supply voltage, a
microcontroller addressing the SPI lines after some time or something else?
I have seen all on my designs...
Test the JTAG chain with the -T0 option, and probably -I -T0 should test
both JTAG and SPI.
Tomek> Maybe slowing down will help.. but there is no slow-down option
Tomek> in release 449 and the fresh release 635 does have slow down but
Tomek> does not have -c ftdi -V -P switches anymore?! why? how should I
Tomek> select my ftdi cable? -s does not work :-(
As explained before, define your cable in cablelist.txt.
Slow down only helps in rare cases. E.g. a ringing TCK line may show double
clocking even on slowest JTAG frequencies, as ringing happens at the edges,
with edge rates remaining the same. With an on-board connector I didn't see
problems up to the max JTAG frequency of the slowest device, and AVR with 8
MHz in my case. Cable connected adapters are something different.
Try
<your cable> ftdi <your VID>:<your PID>: 1500000
or
<your cable> ftdi <your VID>:<your PID>::1:0x00:0x10:0x00:0x0 1500000
The new scheme works better for people with standard cables, and custom
cables are added more easy.
Sorry that things work so hard with the end for your diplome work nearing...
Bye
--
Uwe Bonnes bo...@el...
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
|
|
From: Uwe B. <bo...@el...> - 2011-08-29 19:15:25
|
>>>>> "Tomek" == Tomek CEDRO <tom...@gm...> writes:
Tomek> The new xc3sprog wants to open some other PID but I have no
Tomek> option to select PID anymore?
Tomek> %./xc3sprog -v -c ftdi -s 53SHWR51 XC3SPROG (c) 2004-2011
Tomek> xc3sprog project $Rev: 635 $ OS: FreeBSD Free software: If you
Tomek> contribute nothing, expect nothing! Feedback on
Tomek> success/failure/enhancement requests:
Tomek> http://sourceforge.net/mail/?group_id=170565 Check Sourceforge
Tomek> for updates: http://sourceforge.net/projects/xc3sprog/develop
Tomek> Cable ftdi type ftdi VID 0x0403 PID 6010 Serial 53SHWR51 dbus
Tomek> data 00 enable 0b cbus data 00 data 00 Could not open FTDI device
Tomek> (using libftdi): device not found Unable to access FTDI device
Tomek> with either libftdi or FTD2XX
Is the cable really there? Check with lsusb or a similar tool.
What was the last version that worked?
Can you also check after changing cablelist.txt
ftdi ftdi 0x0403:0x6010: 1500000
to
ftdi ftdi 0x0403:0x6010::1:0x00:0x10:0x00:0x0 1500000
and either recompiling or setting the environmment variable CABLEDB to
the changed cablelist.txt
Bye
--
Uwe Bonnes bo...@el...
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
|
|
From: Tomek C. <tom...@gm...> - 2011-08-29 17:34:55
|
The new xc3sprog wants to open some other PID but I have no option to select PID anymore? %./xc3sprog -v -c ftdi -s 53SHWR51 XC3SPROG (c) 2004-2011 xc3sprog project $Rev: 635 $ OS: FreeBSD Free software: If you contribute nothing, expect nothing! Feedback on success/failure/enhancement requests: http://sourceforge.net/mail/?group_id=170565 Check Sourceforge for updates: http://sourceforge.net/projects/xc3sprog/develop Cable ftdi type ftdi VID 0x0403 PID 6010 Serial 53SHWR51 dbus data 00 enable 0b cbus data 00 data 00 Could not open FTDI device (using libftdi): device not found Unable to access FTDI device with either libftdi or FTD2XX -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info |
|
From: Tomek C. <tom...@gm...> - 2011-08-29 17:30:06
|
Hello Uwe :-) On Mon, Aug 29, 2011 at 4:16 PM, Uwe Bonnes <bo...@el...> wrote: > after fighting normal bitrot (see recent SVN checins) ? :-) > I can program the flash successfully. > I also read back the flash of the s3adspstarter kit, verified and > reprogrammed. Uhm, the Amontec JTAGKey2P seems to be working far better and faster than Xilinx "USB Download Cable" (XUP?) because there are no errors during flash write, there are errors however on flash read, also the program does not start so the flashing fails. I have mounted ST 25P64 chip. %./flashit_amontec.sh ../pong_top.bit spi Uploading bitfile into SPI Flash (using provided bscan_spi.bit)... XC3SPROG (c) 2004-2010 xc3sprog project $Rev: 449 $ OS: FreeBSD Free software: If you contribute nothing, expect nothing! Feedback on success/failure/enhancement requests: http://sourceforge.net/mail/?group_id=170565 Check Sourceforge for updates: http://sourceforge.net/projects/xc3sprog/develop Using built-in device list JTAG chainpos: 0 Device IDCODE = 0x03840093 Desc: XC3SD1800 Created from NCD file: top.ncd Target device: 3sd1800afg676 Created: 2009/ 5/13 17:10: 5 Bitstream length: 8197280 bits DNA is 0xd14100d5252208ff done. Programming time 1529.1 ms USB transactions: Write 512 read 8 retries 7 XC3SPROG (c) 2004-2010 xc3sprog project $Rev: 449 $ OS: FreeBSD Free software: If you contribute nothing, expect nothing! Feedback on success/failure/enhancement requests: http://sourceforge.net/mail/?group_id=170565 Check Sourceforge for updates: http://sourceforge.net/projects/xc3sprog/develop Using built-in device list JTAG chainpos: 0 Device IDCODE = 0x03840093 Desc: XC3SD1800 Created from NCD file: pong_top.ncd;UserID=0xFFFFFFFF Target device: 3sd1800afg676 Created: 2011/08/25 17:10:44 Bitstream length: 8197280 bits JEDEC: 20 20 0x17 0x10 Found Numonyx Device, Device ID 0x2017 CFI: 0e1268c0004400e44860e0af7fc00c00 256 bytes/page, 32768 pages = 8388608 bytes total Sector 8, Writing page 4002/ 4002... Maximum erase time 716.6 ms, Max PP time 71662 us Verifying page 277 Verify failed at page 277 read:00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 file:00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000080000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 Verifying page 283 Verify failed at page 283 read:00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 file:00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 Verifying page 931 Verify failed at page 931 read:00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 file:00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000ebff45540000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 Verifying page 934 Verify failed at page 934 read:00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 file:000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000090041c0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 Verifying page 939 Verify failed at page 939 read:00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 file:0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000f0007f012b035aaa000000000000000000000000000000000000 Verifying page 942 Verify failed at page 942 read:00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 file:00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000200000404000800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 Trying reconfigure USB transactions: Write 28775 read 26498 retries 0 Maybe slowing down will help.. but there is no slow-down option in release 449 and the fresh release 635 does have slow down but does not have -c ftdi -V -P switches anymore?! why? how should I select my ftdi cable? -s does not work :-( -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info |
|
From: Uwe B. <bo...@el...> - 2011-08-29 16:16:27
|
>>>>> "Tomek" == Tomek CEDRO <tom...@gm...> writes:
Tomek> On Sat, Aug 27, 2011 at 10:15 AM, Uwe Bonnes
Tomek> <bo...@el...> wrote:
>> I will try to reproduce in the next days.
Tomek> Thank you Uwe :-)
Hello,
after fighting normal bitrot (see recent SVN checins)
with a DLC10 loaded with /opt/Xilinx/13.2/ISE_DS/common/bin/lin/xusb_xp2.hex
and a board with a XC3S50AN loaded with
.../xc3sprog/trunk/bscan_spi/xc3s50an.bit
I can program the flash successfully.
I also read back the flash of the s3adspstarter kit, verified and
reprogrammed.
Bye
--
Uwe Bonnes bo...@el...
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
|
|
From: Uwe B. <bo...@el...> - 2011-08-28 18:02:50
|
>>>>> "Tomek" == Tomek CEDRO <tom...@gm...> writes:
...
Tomek> The problem I have is that bitfile does not upload into SPI
Tomek> correctly because there are errors during the flash. I can upload
Tomek> bitfile directly into FPGA with no problem :-) This might be
Tomek> caused by too fast speed of Xilinx cable that cannot be changed,
Tomek> I will try to use FT2232 cable instead and let you know the
Tomek> results :-)
Please test with the FTx232 cable. If it works, this will take the preasure
off and we know that the problem is with xc3sprog/xilinx cable.
To slow down the JTAG frequency, use the -J xxx argument-
If the problem persists, you know that the problem is with your chain.
Bye
--
Uwe Bonnes bo...@el...
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
|
|
From: Tomek C. <tom...@gm...> - 2011-08-28 11:30:48
|
On Sun, Aug 28, 2011 at 11:23 AM, Uwe Bonnes <bo...@el...> wrote: > You can slow down FTx232 based cables. I don't know about the Xilinx download > cables. Those doing the reverse enginnering didn't mention that: > http://sourceforge.net/apps/mediawiki/urjtag/index.php?title=Cable_Xilinx_Platform_Cable_USB Ah, I have also some FT2232 cables, I will try to use them and report the results :-) Thank you :-) > If you are under pressure, why not use impact? Because I am using FreeBSD with Linux binaries of ISE and the support for their cables on platforms other thant Windows is terrible, as you know :-) This is why I use XC3SPROG to avoid using iMPACT - and here once again great thank you for this marvelous tool! :-) You should write on the project website that is totally overcomes iMPACT limitations on open-source platforms, because it is not that obvious for person that did not use it before :-) Ofcourse I can use iMPACT to generate SVF and then replay it in UrJTAG, but using XC3SPROG gives me rapid ability to upload bitfile into FPGA with no use of this terrible iMPACT :-) > If it doesn't work with impact neither, get your JTAG chain setup right. If > it does wrok with impact, it will indicate an error in xc3sprog. The problem I have is that bitfile does not upload into SPI correctly because there are errors during the flash. I can upload bitfile directly into FPGA with no problem :-) This might be caused by too fast speed of Xilinx cable that cannot be changed, I will try to use FT2232 cable instead and let you know the results :-) Best regards, Tomek Cedro -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info |
|
From: Uwe B. <bo...@el...> - 2011-08-28 11:12:25
|
>>>>> "Joris" == Joris van Rantwijk <jo...@sr...> writes:
Joris> On Saturday 27 August 2011, Uwe Bonnes wrote: For example:
Joris> "xc3sprog w:sample.bit:64:BIT:32"
>> It's intended effect would be to take bytes 0..31 of the bitfile and
>> write it starting at PROM position 64 (offset for offset in PROM,
>> rlength for bitfile read length)
Joris> Ok, clear. I think XCF currently does something else, but that
Joris> can be fixed.
>> For xcf, intended command line is like xc3sprog -c xx -p 2,4,... -I
>> w:<multiboot-header.bit>:0 w:<golden.bit>:0x10000
>> w:<normal-image.bit>:0x190000
Arg, I wrote a wrong syntax here. Should be:
<multiboot-header.bit>:w <golden.bit>:w:0x10000
Joris> In the case of XCF, I'm not yet convinced that this would be
Joris> useful. As XC3SPROG processes the bitfiles, it performs an erase
Joris> of the PROM device immediately before programming each bit
Joris> file. Merging two bitfiles into one PROM device is thus not
Joris> possible, because the PROM would be erased after programming the
Joris> first file and before programming the second file.
Yes, XCF can only be erased as one block. But with
bitfile.1.bit:W:offset0 and bitfile2.bit:W:offset1, the erase action is
skipped, so partial writing is possible.
Joris> This could probably be solved as well. But alternatively, you
Joris> could decide that PROM-subranging is not useful for XCF, and then
Joris> we could simply kick it out of the XCF code. What about XCFxxP?
XCFP can be erased in sections to hold design revisions, so at least XCFP
has a use for that option. And for XCF, probably a lot of infrastructure is
already there, but probably also with some hard to find errors.
Joris> I am not (yet) familiar with Spartan-6, so I don't understand
Joris> what is at stake in this decision. Do all Spartan-6 boards use
Joris> SPI flash in practice? In that case I think we should avoid
Joris> burdening the XCF code with a niche feature which can not even be
Joris> tested.
Again, XCFP knows about revisions, so it's more than a niche feature for SPI
programmed devices alone. programXCF handles both XCF and XCFP, so getting
it right for XCF will fix XFCP too.
>> As I intend to have orthogonal arguments, I tried to make XCF behave
>> like serial flash programming, but probably got it wrong. Any help
>> welcome. Multi PROM arrangements will make things more difficult.
Joris> I will look into XCF programming, and I hope to get multi-PROM
Joris> working again. Please advise me on the way forward with
Joris> XCF-subranging, i.e. try to fix or just eliminate.
Just eliminating and getting the basic right will probably make 98% of the
users happy. But give proper error message if a user uses the
xc3sprog ... bitfile.1.bit:W:offset0 bitfile2.bit:W:offset1
syntax on XCF/XFP.
But a look at the present code may also be worth some effort. The handling
of "current_offset" in the (int i = 0; i < nchainpos; i++) loop seems
dubious...
Bye
--
Uwe Bonnes bo...@el...
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
|
|
From: Joris v. R. <jo...@sr...> - 2011-08-27 22:33:08
|
On Saturday 27 August 2011, Uwe Bonnes wrote: > Joris> For example: "xc3sprog w:sample.bit:64:BIT:32" > > It's intended effect would be to take bytes 0..31 of the bitfile and > write it starting at PROM position 64 > (offset for offset in PROM, rlength for bitfile read length) Ok, clear. I think XCF currently does something else, but that can be fixed. > For xcf, intended command line is like > xc3sprog -c xx -p 2,4,... -I w:<multiboot-header.bit>:0 > w:<golden.bit>:0x10000 w:<normal-image.bit>:0x190000 In the case of XCF, I'm not yet convinced that this would be useful. As XC3SPROG processes the bitfiles, it performs an erase of the PROM device immediately before programming each bit file. Merging two bitfiles into one PROM device is thus not possible, because the PROM would be erased after programming the first file and before programming the second file. This could probably be solved as well. But alternatively, you could decide that PROM-subranging is not useful for XCF, and then we could simply kick it out of the XCF code. What about XCFxxP? I am not (yet) familiar with Spartan-6, so I don't understand what is at stake in this decision. Do all Spartan-6 boards use SPI flash in practice? In that case I think we should avoid burdening the XCF code with a niche feature which can not even be tested. > As I intend to have orthogonal arguments, I tried to make XCF behave > like serial flash programming, but probably got it wrong. Any help > welcome. Multi PROM arrangements will make things more difficult. I will look into XCF programming, and I hope to get multi-PROM working again. Please advise me on the way forward with XCF-subranging, i.e. try to fix or just eliminate. Greetings, Joris. |
|
From: Uwe B. <bo...@el...> - 2011-08-27 20:39:17
|
>>>>> "Joris" == Joris van Rantwijk <jo...@sr...> writes:
Joris> Hello Uwe, Thanks for fixing the FTD2XX dependency.
Hello,
thanks for your work!
Joris> Something else: Last week I tried to program a board with one BIT
Joris> file split over two XCFS devices. I noticed that this no longer
Joris> works because some stuff got mixed up between the
Joris> bitfile-splitting logic and the offset/rlength logic.
Joris> I'm trying to fix it, but my problem now is that I don't
Joris> understand what the intended behaviour of the offset/rlength
Joris> logic is.
Joris> For example: "xc3sprog w:sample.bit:64:BIT:32"
Joris> Should this take the complete contents of sample.bit (i.e. bytes
Joris> 0 .. 32 of the file) and program it into bytes 64 .. 95 of the
Joris> flash chip? Or should this take bytes 64 .. 95 from sample.bit
Joris> and program them into bytes 64 .. 95 of the flash chip?
It's intended effect would be to take bytes 0..31 of the bitfile and write
it starting at PROM position 64
(offset for offset in PROM, rlength for bitfile read length)
Joris> Same question for: "xc3sprog r:sample.bit:64:BIT:32"
Joris> This one is especially confusing. It seems that ProgAlgXCF::read
Joris> takes bytes 64 .. 95 and puts them into positions 64 .. 95 of the
Joris> buffer. But then BitFile::saveAs writes buffer positions 0 .. 32
Joris> to disk.
Intended effect when reading is to start reading the PROM at offset for
length bytes
Probably I broke XCF writing. I have done no work on a design with XCF
since long and I don't have any multi-prom design to test at all.
Joris> Also, what is the use case for the offset/rlength feature?
Joris> Understanding that may help me to do the right thing with the
Joris> multi-PROM logic.
The use case is to write a multi-boot pattern to serial flash
xc3sprog -c xx -I w:<multiboot-header.bit>:0 w:<golden.bit>:0x10000 w:<normal-image.bit>:0x190000
For xcf, intended command line is like
xc3sprog -c xx -p 2,4,... -I w:<multiboot-header.bit>:0 w:<golden.bit>:0x10000 w:<normal-image.bit>:0x190000
with PROMs at JTAG chain positions 2,4 for the example above.
An example for a XC6SLX45 multiboot header is in the source. We have this
XC6SLX serial multiboot pattern in a somehow "productive" use here.
The optional length could allow partial overwrite. The main use is to read
back the different images written above to different files against reading
the whole flash image to one file.
As I intend to have orthogonal arguments, I tried to make XCF behave like
serial flash programming, but probably got it wrong. Any help welcome. Multi
PROM arrangements will make things more difficult.
Bye
--
Uwe Bonnes bo...@el...
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
|
|
From: Joris v. R. <jo...@sr...> - 2011-08-27 17:58:01
|
Hello Uwe, Thanks for fixing the FTD2XX dependency. Something else: Last week I tried to program a board with one BIT file split over two XCFS devices. I noticed that this no longer works because some stuff got mixed up between the bitfile-splitting logic and the offset/rlength logic. I'm trying to fix it, but my problem now is that I don't understand what the intended behaviour of the offset/rlength logic is. For example: "xc3sprog w:sample.bit:64:BIT:32" Should this take the complete contents of sample.bit (i.e. bytes 0 .. 32 of the file) and program it into bytes 64 .. 95 of the flash chip? Or should this take bytes 64 .. 95 from sample.bit and program them into bytes 64 .. 95 of the flash chip? Same question for: "xc3sprog r:sample.bit:64:BIT:32" This one is especially confusing. It seems that ProgAlgXCF::read takes bytes 64 .. 95 and puts them into positions 64 .. 95 of the buffer. But then BitFile::saveAs writes buffer positions 0 .. 32 to disk. Also, what is the use case for the offset/rlength feature? Understanding that may help me to do the right thing with the multi-PROM logic. Joris. |
|
From: Tomek C. <tom...@gm...> - 2011-08-27 11:59:05
|
On Sat, Aug 27, 2011 at 10:15 AM, Uwe Bonnes <bo...@el...> wrote: > I will try to reproduce in the next days. Thank you Uwe :-) Best regards, Tomek Cedro -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info |
|
From: Uwe B. <bo...@el...> - 2011-08-27 10:15:19
|
>>>>> "Tomek" == Tomek CEDRO <tom...@gm...> writes:
Tomek> Hello! Thank you Uwe for xc3sprog and thank you Wojciech for
Tomek> making it possible on FreeBSD! This is great alternative for
Tomek> while iMPACT and messy Xilinx USB drivers, although I have FT2232
Tomek> and Xilinx USB cables, I am using Xilinx XPC cable to flash my
Tomek> device with some automation script added :-)
Tomek> I am able to upload bitstream into FPGA, but I cannot program SPI
Tomek> memory with success :-( There are errors during the flash process
Tomek> in random intervals, maybe some buffer is not fast enough, is it
Tomek> possible to slow down the JTAG clock? I am usin replaced Flash
Tomek> chip that is supported by iMPACT - ST 25P64. Please advise.
Tomek> XC3SPROG (c) 2004-2010 xc3sprog project $Rev: 449 $ OS: FreeBSD
Tomek> Free software: If you contribute nothing, expect nothing!
Tomek> Feedback on success/failure/enhancement requests:
Tomek> http://sourceforge.net/mail/?group_id=170565 Check Sourceforge
Tomek> for updates: http://sourceforge.net/projects/xc3sprog/develop
Tomek> firmware version = 0x0404 (1028) CPLD version = 0x0012 (18) DNA
Tomek> is 0xd14100d525220801 XC3SPROG (c) 2004-2010 xc3sprog project
Tomek> $Rev: 449 $ OS: FreeBSD Free software: If you contribute nothing,
Tomek> expect nothing! Feedback on success/failure/enhancement
Tomek> requests: http://sourceforge.net/mail/?group_id=170565 Check
Tomek> Sourceforge for updates:
Tomek> http://sourceforge.net/projects/xc3sprog/develop
Tomek> firmware version = 0x0404 (1028) CPLD version = 0x0012 (18)
Tomek> JEDEC: 20 20 0x17 0x10 Found Numonyx Device, Device ID 0x2017
...
I will try to reproduce in the next days.
--
Uwe Bonnes bo...@el...
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
|
|
From: Tomek C. <tom...@gm...> - 2011-08-26 10:35:37
|
Hello! Thank you Uwe for xc3sprog and thank you Wojciech for making it possible on FreeBSD! This is great alternative for while iMPACT and messy Xilinx USB drivers, although I have FT2232 and Xilinx USB cables, I am using Xilinx XPC cable to flash my device with some automation script added :-) I am able to upload bitstream into FPGA, but I cannot program SPI memory with success :-( There are errors during the flash process in random intervals, maybe some buffer is not fast enough, is it possible to slow down the JTAG clock? I am usin replaced Flash chip that is supported by iMPACT - ST 25P64. Please advise. XC3SPROG (c) 2004-2010 xc3sprog project $Rev: 449 $ OS: FreeBSD Free software: If you contribute nothing, expect nothing! Feedback on success/failure/enhancement requests: http://sourceforge.net/mail/?group_id=170565 Check Sourceforge for updates: http://sourceforge.net/projects/xc3sprog/develop firmware version = 0x0404 (1028) CPLD version = 0x0012 (18) DNA is 0xd14100d525220801 XC3SPROG (c) 2004-2010 xc3sprog project $Rev: 449 $ OS: FreeBSD Free software: If you contribute nothing, expect nothing! Feedback on success/failure/enhancement requests: http://sourceforge.net/mail/?group_id=170565 Check Sourceforge for updates: http://sourceforge.net/projects/xc3sprog/develop firmware version = 0x0404 (1028) CPLD version = 0x0012 (18) JEDEC: 20 20 0x17 0x10 Found Numonyx Device, Device ID 0x2017 CFI: 0e1268c0004400e44860e0af7fc00c00 256 bytes/page, 32768 pages = 8388608 bytes total ........................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................usb_control_msg(0x40.0xa6 0x06) (shift) Unknown error ^C The verbose version is following: XC3SPROG (c) 2004-2010 xc3sprog project $Rev: 449 $ OS: FreeBSD Free software: If you contribute nothing, expect nothing! Feedback on success/failure/enhancement requests: http://sourceforge.net/mail/?group_id=170565 Check Sourceforge for updates: http://sourceforge.net/projects/xc3sprog/develop firmware version = 0x0404 (1028) CPLD version = 0x0012 (18) Using built-in device list JTAG chainpos: 0 Device IDCODE = 0x03840093 Desc: XC3SD1800 Created from NCD file: top.ncd Target device: 3sd1800afg676 Created: 2009/ 5/13 17:10: 5 Bitstream length: 8197280 bits DNA is 0xd14100d525220801 done. Programming time 4274.6 ms USB Read Transactions: 7 Write Transactions: 310 Control Transaction 318 XC3SPROG (c) 2004-2010 xc3sprog project $Rev: 449 $ OS: FreeBSD Free software: If you contribute nothing, expect nothing! Feedback on success/failure/enhancement requests: http://sourceforge.net/mail/?group_id=170565 Check Sourceforge for updates: http://sourceforge.net/projects/xc3sprog/develop firmware version = 0x0404 (1028) CPLD version = 0x0012 (18) Using built-in device list JTAG chainpos: 0 Device IDCODE = 0x03840093 Desc: XC3SD1800 Created from NCD file: pong_top.ncd;UserID=0xFFFFFFFF Target device: 3sd1800afg676 Created: 2011/08/25 17:10:44 Bitstream length: 8197280 bits JEDEC: 20 20 0x17 0x10 Found Numonyx Device, Device ID 0x2017 CFI: 0e1268c0004400e44860e0af7fc00c00 256 bytes/page, 32768 pages = 8388608 bytes total Sector 1, Writing page 29/ 4002usb_control_msg(0x40.0xa6 0x06) (shift) Unknown error ^C Maybe someone will like the automation script that flashes the Xilinx cable and then uploads bitfile directly into FPGA or into SPI based on commandline parameter, so I put initial version below: #!/bin/sh # Xilinx FPGA bitfile upload automation script using fxload and xc3sprog. # (C) 20110826 Tomasz Boleslaw CEDRO (http://www.tomek.cedro.info) CABLEFW=xusb_emb.hex VID=0x03fd PID=0x0007 ALTVID=0x03fd ALTPID=0x0008 DELAY=10 FXLOAD=`whereis -bq fxload` XC3SPROG=`whereis -bq xc3sprog` if [ ! $FXLOAD ]; then echo "You need to install 'fxload' port first..."; exit 1; fi if [ ! $XC3SPROG ]; then echo "You need to install 'xc3sprog' port first..."; exit 1; fi if [ ! $1 ]; then echo "Usage: script <bitfile> [spi]"; exit 1; fi echo "Flashing Xilinx Cable Firmware (you may need to set it up first)..." # First try the cable VID/PID with no firmware. echo "Flashing blank cable..." fxload -D vid=$VID,pid=$PID -t fx2 -s xusbdfwu.hex -I $CABLEFW # Then if necessary try reprogramming existing xilinx cable firmware. if [ $? -ne 0 ]; then echo "Trying to reflash existing xilinx cable firmware..." fxload -D vid=$ALTVID,pid=$ALTPID -t fx2 -s xusbdfwu.hex -I $CABLEFW fi if [ $? -eq 0 ]; then echo "Waiting for jtag interface firmware to settle..." sleep $DELAY if [ "$2" = "spi" ]; then echo "Uploading bitfile into SPI Flash (using provided bscan_spi.bit)..." xc3sprog -v -c xpc bscan_spi.bit xc3sprog -v -c xpc -I $1 else xc3sprog -c xpc $1 fi else echo "Flashing Xilinx JTAG Cable failed, exiting..." exit 0 fi Best regards, Tomek Cedro -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info |
|
From: Uwe B. <bo...@el...> - 2011-08-24 07:45:20
|
>>>>> "Joris" == Joris van Rantwijk <jo...@sr...> writes:
Joris> On Wednesday 17 August 2011, Uwe Bonnes wrote:
>> However the right solution would be configurable with CMAKE...
Joris> Ok, I think I got it.
Joris> FTD2XX can be enabled/disabled with CMake. It's on by default,
Joris> but it turns off if libft2dxx is not found. As before, LibFTDI
Joris> is still alway-on.
Hello Joris,
thanks for the patches. I applied locally, and it worked. I will wait for
feedback from in-house users with the same ftd2xx problem before I update
the sourceforge tree.
Bye
--
Uwe Bonnes bo...@el...
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
|
|
From: Joris v. R. <jo...@sr...> - 2011-08-22 19:57:49
|
On Wednesday 17 August 2011, Uwe Bonnes wrote: > However the right solution would be configurable with CMAKE... Ok, I think I got it. FTD2XX can be enabled/disabled with CMake. It's on by default, but it turns off if libft2dxx is not found. As before, LibFTDI is still alway-on. Joris. |
|
From: Joris v. R. <jo...@sr...> - 2011-08-17 19:27:56
|
On Wednesday 17 August 2011, Uwe Bonnes wrote: > Sorry for the delay, Vacations ;-) I figured. Hope you had a good time. > Joris> Would you consider making the use of D2XX optional again? > Joris> For my own purpose, I have put the "#ifdef USE_FTD2XX" > Joris> conditionals back in place so that I can compile without > Joris> D2XX. I can send you the diff if you like. > Please send the diff. Attached. This only disables D2XX dependencies in the C++ code. A separate change in CMake is needed to skip the actual linking. > However the right solution would be configurable with CMAKE... Right. I will try to clean up a little and put the library decision in the CMake config. That will be a new version of the diff. > If you have any ideas about a better help message or other > ommission, please let me know. Also a man page is needed. Wonderful idea. Once upon a time, nearly every Unix command had a well- written man page. I'll see if I can prepare a draft version. Regards, Joris. |
|
From: Uwe B. <bo...@el...> - 2011-08-17 09:51:22
|
>>>>> "Joris" == Joris van Rantwijk <jo...@sr...> writes:
Joris> Hi Uwe, Thanks again for your excellent work on XC3SPROG. I just
Joris> upgraded to SVN r632, and I'd like to make a few comments.
Sorry for the delay, Vacations ;-)
Joris> There seems to be no way to make xc3sprog read a custom
Joris> cablelist.txt file at run time. I think this is unintentional, so
Joris> I filed a bug report in the SF tracker.
Hopefully fixed now
Joris> Xc3sprog now requires the FTDI D2XX library in order to
Joris> compile. It used to be a compile-time option. I think it is very
Joris> unpractical for a free software project to have a hard dependency
Joris> on a closed-source library. Especially since libD2XX does not
Joris> seem to offer any advantage over libftdi.
Joris> Would you consider making the use of D2XX optional again? For my
Joris> own purpose, I have put the "#ifdef USE_FTD2XX" conditionals back
Joris> in place so that I can compile without D2XX. I can send you the
Joris> diff if you like.
Please send the diff.
Joris> If you are only concerned about the ifdef-mess in the source
Joris> code, I am willing to do some cleanup work. I believe the choice
Joris> between D2XX/libftdi can be isolated in a very small part of
Joris> ioftdi.cpp.
However the right solution would be configurable with CMAKE...
Joris> Lastly, my feeling is that the built-in help message of xc3sprog
Joris> has become a little less user friendly over the last year. In
Joris> particular, the "-p" option is not mentioned. I consider myself
Joris> an experienced user of xc3sprog, yet I had to look in the source
Joris> code to figure out how to run it.
I somehow managed to delete the line or forgot it. Hopefully fixed now,.
If you have any ideas about a better help message or other ommission, please
let me know. Also a man page is needed.
Bye
--
Uwe Bonnes bo...@el...
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
|
4 messages has been excluded from this view by a project administrator.
