xc3sprog-users — Generic user and developer list

Re: [Xc3sprog-users] Coding style for xc3sprog

[Sidney C. <si...@ji...>]

On a related note, wouldn't this be a good time to transfer xc3sprog
to github altogether?

Regards,
  Sidney

Re: [Xc3sprog-users] Coding style for xc3sprog

[Uffe J. <uf...@uf...>]

Hi Uwe,

Thanks for your reply

On 2015-05-27 11:18, Uwe Bonnes wrote:
>>>>>> "Uffe" == Uffe Jakobsen <uf...@uf...> writes:
>
>      Uffe> Hello,
>
>      Uffe> First of all thanks for a quite useful utility
>
>      Uffe> I'm sorry to write this - but the coding style of xc3sprog is
>      Uffe> quite messy.
>
> I fully agree.
>
>      Uffe> Lots of the src files have: different indentation (mixed spaces
>      Uffe> and tabs) and different bracing style etc...
>
>      Uffe> What is the "official" coding style for xc3sprog contributions ?
>
> There is no "official" coding style yet.
>
>      Uffe> Would you accept patches that fixed the xc3sprog source to a
>      Uffe> common style ?
>
> If we can aggree on a coding style and if clean-up and other work is
> strictly decoupled I will gladly do. Do you already have project admin
> access on sourceforge?

Sure - agree, clean-up and other work should not be mixed.

My idea was to break the clean-up into a couple of "transactions" (commits).
Each of these transactions dealing with a separate issue - eg 
indentation, bracing etc.
The reason for this approach is that the number of changes will be quite 
big for each of these changes - and fixing one thing at a time would be 
easier to review (I think).

My sourceforge prj-user is "uffejakobsen"

>
> I do much work on Nut O/S now. Can you have a look at
> http://www.ethernut.de/en/documents/programming-style-guide.html ?
>

Did a quick scan of the style guide - looks ok to me :-)

> Beside the restriction caused by the many arch NutOS has to bear with, I now
> try to follow the NutOS style.
>
> If you want, I can send you my .git repository of sourceforge SVN. I locally
> work with git-svn. Branching is easy with git/svn.
>

That would be great.

I started my clean-up work on a svn extract - and missed the local 
branching features of git - so I also did an git/svn clone  :-)

Does this mean that you have changes locally that are now yet pushed to 
sourceforge svn ?

Kind regards Uffe

Re: [Xc3sprog-users] Coding style for xc3sprog

[Uwe B. <bo...@el...>]

>>>>> "Uffe" == Uffe Jakobsen <uf...@uf...> writes:

    Uffe> Hello,

    Uffe> First of all thanks for a quite useful utility

    Uffe> I'm sorry to write this - but the coding style of xc3sprog is
    Uffe> quite messy.

I fully agree.

    Uffe> Lots of the src files have: different indentation (mixed spaces
    Uffe> and tabs) and different bracing style etc...

    Uffe> What is the "official" coding style for xc3sprog contributions ?

There is no "official" coding style yet.

    Uffe> Would you accept patches that fixed the xc3sprog source to a
    Uffe> common style ?

If we can aggree on a coding style and if clean-up and other work is
strictly decoupled I will gladly do. Do you already have project admin
access on sourceforge?

I do much work on Nut O/S now. Can you have a look at
http://www.ethernut.de/en/documents/programming-style-guide.html ?

Beside the restriction caused by the many arch NutOS has to bear with, I now
try to follow the NutOS style.

If you want, I can send you my .git repository of sourceforge SVN. I locally
work with git-svn. Branching is easy with git/svn.

Cheers
-- 
Uwe Bonnes                bo...@el...

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

[Xc3sprog-users] Coding style for xc3sprog

[Uffe J. <uf...@uf...>]

Hello,

First of all thanks for a quite useful utility

I'm sorry to write this - but the coding style of xc3sprog is quite messy.

Lots of the src files have: different indentation (mixed spaces and 
tabs) and different bracing style etc...

What is the "official" coding style for xc3sprog contributions ?

Would you accept patches that fixed the xc3sprog source to a common style ?

Thanks in advance

Kind regards Uffe Jakobsen

Re: [Xc3sprog-users] Virtex 7 V2000T series support

[Uwe B. <bo...@el...>]

>>>>> "William" == William Kolment <kol...@gm...> writes:

    William> Hi Lyf, I was wondering if you had any success getting xc3sprog
    William> to work with an IR length of 24? I'm attempting to program a
    William> Virtex 7 XC7VH580T which has a IR length of 22 and I think I am
    William> hitting a lot of the same problems you were.

    William> If by any chance you were able to get it working would you mind
    William> sharing your solution and or executable?

What is going wrong? What works and what does not work?

Do you have a logic analyzer? Are the signals all right?

More info needed as I don't have such a part.

Bye
-- 
Uwe Bonnes                bo...@el...

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

[Xc3sprog-users] Virtex 7 V2000T series support

[William K. <kol...@gm...>]

Hi Lyf,

I was wondering if you had any success getting xc3sprog to work with an IR
length of 24? I'm attempting to program a Virtex 7 XC7VH580T which has a IR
length of 22 and I think I am hitting a lot of the same problems you were.

If by any chance you were able to get it working would you mind sharing
your solution and or executable?

Thanks in advance,

William

Re: [Xc3sprog-users] [PATCH] bitfile: Support for BPI files

[Ricardo R. D. <ric...@gm...>]

Hello?

On Thu, Jun 12, 2014 at 12:07 PM, Ricardo Ribalda Delgado
<ric...@gm...> wrote:
> BPI files are generated with:
>
> promgen -p bin -u 0 in.bit
>
> They are the equivalent of the BIN files for Parallel flash devices
>
> This patch add support for such files
>
> Signed-off-by: Ricardo Ribalda Delgado <ric...@gm...>
> ---
>  bitfile.cpp   | 19 ++++++++++++++++---
>  bitfile.h     |  4 ++--
>  bitparse.cpp  |  4 ++--
>  xc2c_warp.cpp |  4 ++--
>  xc3sprog.1    |  1 +
>  xc3sprog.cpp  |  3 ++-
>  6 files changed, 25 insertions(+), 10 deletions(-)
>
> diff --git a/bitfile.cpp b/bitfile.cpp
> index e6e3198..1cae4d3 100644
> --- a/bitfile.cpp
> +++ b/bitfile.cpp
> @@ -88,7 +88,7 @@ int BitFile::readBitfile(FILE *fp)
>
>  /* Read in whole file with bitflip */
>
> -int  BitFile::readBIN(FILE *fp)
> +int  BitFile::readBIN(FILE *fp, bool do_bitrev)
>  {
>      unsigned int i;
>
> @@ -100,6 +100,10 @@ int  BitFile::readBIN(FILE *fp)
>      if (buffer == 0)
>          return 1;
>      fread(buffer,1, length, fp);
> +
> +    if (!do_bitrev)
> +           return 0;
> +
>      for(i=0; i<length; i++)
>      {
>          unsigned char data = buffer[i];
> @@ -318,7 +322,9 @@ int BitFile::readFile(FILE *fp, FILE_STYLE in_style)
>      case STYLE_HEX_RAW:
>          return readHEXRAW(fp);
>      case STYLE_BIN:
> -        return readBIN(fp);
> +        return readBIN(fp, true);
> +    case STYLE_BPI:
> +        return readBIN(fp, false);
>      default: fprintf(stderr, " Unhandled style %s\n",styleToString(in_style));
>        return 1;
>      }
> @@ -477,6 +483,7 @@ uint32_t BitFile::saveAs(FILE_STYLE style, const char  *device,
>      {
>      case STYLE_BIT:
>      case STYLE_BIN:
> +    case STYLE_BPI:
>        if(style == STYLE_BIT)
>         {
>           uint8_t buffer[256] = {0x00, 0x09, 0x0f, 0xf0, 0x0f, 0xf0, 0x0f, 0xf0,
> @@ -522,7 +529,11 @@ uint32_t BitFile::saveAs(FILE_STYLE style, const char  *device,
>         }
>        for(i=0; i<clip; i++)
>         {
> -         byte b=bitRevTable[buffer[i]]; // Reverse bit order
> +         byte b;
> +         if (style != STYLE_BPI)
> +                 b = bitRevTable[buffer[i]]; // Reverse bit order
> +         else
> +                 b = buffer[i];
>           fwrite(&b,1,1,fp);
>         }
>        break;
> @@ -678,6 +689,8 @@ int BitFile::styleFromString(const char *stylestr, FILE_STYLE *style)
>         *style = STYLE_BIT;
>      else if (!strncasecmp(stylestr, "BIN", len))
>         *style = STYLE_BIN;
> +    else if (!strncasecmp(stylestr, "BPI", len))
> +       *style = STYLE_BPI;
>      else if (!strncasecmp(stylestr, "HEX", len))
>         *style = STYLE_HEX;
>      else if (!strncasecmp(stylestr, "HEXRAW", len))
> diff --git a/bitfile.h b/bitfile.h
> index 8d45f83..1cfbf4c 100644
> --- a/bitfile.h
> +++ b/bitfile.h
> @@ -72,7 +72,7 @@ word. */
>
>  typedef unsigned char byte;
>
> -enum FILE_STYLE { STYLE_BIT, STYLE_BIN, STYLE_HEX, STYLE_HEX_RAW,
> +enum FILE_STYLE { STYLE_BIT, STYLE_BIN, STYLE_BPI, STYLE_HEX, STYLE_HEX_RAW,
>                    STYLE_MCS, STYLE_IHEX , STYLE_JEDEC, STYLE_AUTO};
>
>  class BitFile
> @@ -96,7 +96,7 @@ class BitFile
>    void readField(std::string &field, FILE *fp);
>    void processData(FILE *fp);
>    int  readBitfile(FILE *fp);
> -  int  readBIN(FILE *fp);
> +  int  readBIN(FILE *fp, bool do_bitrev);
>    int  readHEXRAW(FILE *fp);
>    int  readMCSfile(FILE *fp);
>    unsigned char checksum(char * buf);
> diff --git a/bitparse.cpp b/bitparse.cpp
> index 30e75f6..d28c6a5 100644
> --- a/bitparse.cpp
> +++ b/bitparse.cpp
> @@ -36,8 +36,8 @@ void usage() {
>           "\nUsage:bitparse [-i input format] [-o output format ][-O outfile] infile\n"   "   -h\t\tprint this help\n"
>           "   -v\t\tverbose output\n"
>           "   -O\t\toutput file (parse input file only if not given\n"
> -         "   -i\t\tinput  file format (BIT|BIN|HEX|MCS|IHEX)\n"
> -         "   -o\t\toutput file format (BIT|BIN|HEX|MCS|IHEX)\n");
> +         "   -i\t\tinput  file format (BIT|BIN|BPI|HEX|MCS|IHEX)\n"
> +         "   -o\t\toutput file format (BIT|BIN|BPI|HEX|MCS|IHEX)\n");
>    exit(255);
>  }
>
> diff --git a/xc2c_warp.cpp b/xc2c_warp.cpp
> index c2c8eec..0b3a55f 100644
> --- a/xc2c_warp.cpp
> +++ b/xc2c_warp.cpp
> @@ -14,8 +14,8 @@ void usage() {
>           "   -v\t\tverbose output\n"
>           "   -m\t\tDirectory containg Map files\n"
>           "   -O\t\toutput file (parse input file only if not given\n"
> -         "   -i\t\tintput file format (BIT|BIN|HEX)\n"
> -         "   -o\t\toutput file format (BIT|BIN|HEX)\n");
> +         "   -i\t\tintput file format (BIT|BIN|BPI|HEX)\n"
> +         "   -o\t\toutput file format (BIT|BIN|BPI|HEX)\n");
>     exit(255);
>  }
>
> diff --git a/xc3sprog.1 b/xc3sprog.1
> index d3fce4d..686c83c 100644
> --- a/xc3sprog.1
> +++ b/xc3sprog.1
> @@ -208,6 +208,7 @@ Xilinx \.BIT file format.
>  Default for FPGA, XCF and SPI devices.
>  T}
>  BIN@Raw binary file.
> +BPI@Raw binary file not bit reversed.
>  MCS@Xilinx .MCS file format.
>  IHEX@T{
>  Intel HEX format.
> diff --git a/xc3sprog.cpp b/xc3sprog.cpp
> index 129ebd3..e6eabca 100644
> --- a/xc3sprog.cpp
> +++ b/xc3sprog.cpp
> @@ -346,9 +346,10 @@ void usage(bool all_options)
>    fprintf(stderr, "\tR: Read from device and write to file, overwrite existing file\n");
>    fprintf(stderr, "\tDefault action is 'w'\n\n");
>    fprintf(stderr, "\tDefault offset is 0\n\n");
> -  fprintf(stderr, "\tstyle: One of BIT|BIN|MCS|IHEX|HEX\n");
> +  fprintf(stderr, "\tstyle: One of BIT|BIN|BPI|MCS|IHEX|HEX\n");
>    fprintf(stderr, "\tBIT: Xilinx .bit format\n");
>    fprintf(stderr, "\tBIN: Binary format\n");
> +  fprintf(stderr, "\tBPI: Binary format not bit reversed\n");
>    fprintf(stderr, "\tMCS: Intel Hex File, LSB first\n");
>    fprintf(stderr, "\tIHEX: INTEL Hex format, MSB first (Use for Xilinx .mcs files!)\n");
>    fprintf(stderr, "\tHEX:  Hex dump format\n");
> --
> 2.0.0
>



-- 
Ricardo Ribalda

Re: [Xc3sprog-users] Virtex 7 V2000T series support

[Uwe B. <bo...@el...>]

>>>>> "lyf4" == lyf4 Science <ly...@gm...> writes:

    lyf4> Hi Owe, yes it is 24 bit.

    lyf4> The bsd file is available at Xilinx site.

    lyf4> I have few queries with xc3sprog source.

    lyf4> 1. What does the variable tck_len and array_transfer_len stands
    lyf4> for ?

    lyf4> I consider it as, tck_len = IR length and array_transfer_len is
    lyf4> default 32.

    lyf4> 2. After every shitIR() invoked there invoked a function 
    lyf4> jtag->cycleTCK (<cycle_values>). What it is used for ?

    lyf4> 3. jtag->shiftDR() denotes the 3rd argument as length which was in
    lyf4> bits or bytes ?

    lyf4> 4. What is the difference between flow_program_legacy() and the
    lyf4> flow_array_program() functions ?

    lyf4> 5. Is flow_enable() and flow_disable() mandatory for the
    lyf4> programming sequence ?

These names and values are from the 1532 bsd files, like
Xilinx/14.6/ISE_DS/ISE/spartan6/data/xc6slx4_1532.bsd

Try to understand how the values given in xc3sprog are determined from the
values in the 1532 file,  minus eventual errors not yet noticed.

14.6 doesn't contain a 1532 file for V2000. Does vivado contain a 1532 file?
If not, look at a e.g. V7 1532 file, like
.../ISE/virtex7/data/xc7vx415t_1532.bsd

Transfer for your device.

And please send diffs.

Bye
-- 
Uwe Bonnes                bo...@el...

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Re: [Xc3sprog-users] Virtex 7 V2000T series support

[Uwe B. <bo...@el...>]

>>>>> "lyf4" == lyf4 Science <ly...@gm...> writes:
...
    lyf4> - Changed the instructions like JPROGRAM JSTART ... defined in the
    lyf4> array [2] to [3] since IR is 24 bit here.

Is the IR really that long?

...

    lyf4> Does .bsd file contains the algorithm to program or where it could
    lyf4> be obtained ?

Some bsd files had infos that made sense, for some others the bsd file info
was useless without further information I looked hard and finally found on
the net.

If you send me in private mail a BSD file of the device under investigation,
I can have a look at it.

Byr
-- 
Uwe Bonnes                bo...@el...

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Re: [Xc3sprog-users] Virtex 7 V2000T series support

[Uwe B. <bo...@el...>]

>>>>> "lyf4" == lyf4 Science <ly...@gm...> writes:

    lyf4> Hi Experts, How to modify the xc3sprog to support the V2000T
    lyf4> series FPGA boards ?

    lyf4> It has IR length of 24.

    lyf4> When I tried programming with the latest Xc3sprog software it
    lyf4> doesn't show up but it has support for other boards of Virtex 7
    lyf4> which has IR length of 10 to 14.

    lyf4> It will be great to get the information on this.

First, you need to find out the JTAG ID of the device and its IR-Len. Enter
these values in devlist.txt and make xc3sprog read your changef file, either
by recompiling or by putting the file in the default places or by setting up
an environment variable to that file. Read the doc for more information.

The second, probably bigger step is to check the algorithms used for the new
device. Probably it is similar to older devices, but maybe some subtile or
bigger changes are needed. You have to extend the algorithm or in case of
bigger incompatibilies write a new algorithm. This will need testing and
probaby debugging with a real device. As I don't have such a device, I can't
write these changes, but I can try to help you by explaining.

Hope this helps

PS: Also mailing to the mailing list for later reference...
-- 
Uwe Bonnes                bo...@el...

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

[Xc3sprog-users] Virtex 7 V2000T series support

[lyf4 S. <ly...@gm...>]

Hi Experts,

How to modify the xc3sprog to support the V2000T series FPGA boards ?

It has IR length of 24.

When I tried programming with the latest Xc3sprog software it doesn't show
up but it has support for other boards of Virtex 7 which has IR length of
10 to 14.

It will be great to get the information on this.

Regards,
Lyf

Re: [Xc3sprog-users] No-Dongle found when xc3sprog -c xpc

[Uwe B. <bo...@el...>]

>>>>> "William" == William Kolment <kol...@gm...> writes:

    William> Hi Guys, I am trying  to get  xc3sprog working  with :

    William> Xilinx Virtex-7: Xilinx Platform Cable USB II Windows 8

    William> I am trying to follow the  1st  step detailed on the
    William>  site http:// xc3sprog.sourceforge.net/guide.php and run the
    William> "xc3sprog -c pp" command.

    William> In my case, we want to run "xc3sprog -c xpc" because we are
    William> using a "Xilinx Platform Cable USB II"

xc3sprog on windows relies in libusb for windows. There are some hints in
the source how to get libusb for windows going.  A winusb backend would fit
fine, but I am short on time.

Bye
-- 
Uwe Bonnes                bo...@el...

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

[Xc3sprog-users] No-Dongle found when xc3sprog -c xpc

[William K. <kol...@gm...>]

Hi Guys,

I am trying  to get  xc3sprog working  with :

Xilinx Virtex-7:
Xilinx Platform Cable USB II
Windows 8


I am trying to follow the  1st  step detailed on the  site
http://xc3sprog.sourceforge.net/guide.php and run the "xc3sprog -c pp"
command.

In my case, we want to run "xc3sprog -c xpc" because we are using a "Xilinx
Platform Cable USB II"


When i run that command it  returns  "No Dongle Found"

Anyone  having  this problem?

Regards,


William

Re: [Xc3sprog-users] All output are sent to "stderr"!!

[Joris v. R. <jor...@jo...>]

On 2014-12-17, Fahad wrote:
> I am working on GUI wrapper for xc3sprog and noticed that all output
> from the program is sent to stderr even if it is not an error!.

When stdout is used for data, all non-data must be send to stderr.
For example, gzip running in verbose mode must send all messages to
stderr, even non-error messages. Because stdout is reserved for the
compressed data stream.

Similarly, I could imagine xc3sprog reading data from a PROM, sending
the binary data to stdout and messages to stderr. But I don't think
xc3sprog is often used that way.

As far as I know, there are no clear guidelines for cases where stdout
is not used for data. It is a bit arbitrary where you draw the line.
When xc3sprog runs in chain detection mode, one might expect the list
of JTAG devices on stdout but the progress messages on stderr. It
depends on how you look at it, and what use cases you want to support.

Joris.

Please ignore the following advertisement:

[Xc3sprog-users] All output are sent to "stderr"!!

[Fahad <fa...@gm...>]

I am working on GUI wrapper for xc3sprog and noticed that all output
from the program is sent to stderr even if it is not an error!.

Is there a valid reason behind doing it this way instead of sending
normal output to "stdout"?

[Xc3sprog-users] xc3sprog releases

[Uffe J. <uf...@uf...>]

Hi,

Could you be persuaded to create "semi-"releases of xc3sprog on a 
regular basis ?

It is a kind of hard to maintain ports of xc3sprog for various OS's 
without a tag and a tar.gz file of the source.

/Uffe

[Xc3sprog-users] [PATCH] bitfile: Support for BPI files

[Ricardo R. D. <ric...@gm...>]

BPI files are generated with:

promgen -p bin -u 0 in.bit

They are the equivalent of the BIN files for Parallel flash devices

This patch add support for such files

Signed-off-by: Ricardo Ribalda Delgado <ric...@gm...>
---
 bitfile.cpp   | 19 ++++++++++++++++---
 bitfile.h     |  4 ++--
 bitparse.cpp  |  4 ++--
 xc2c_warp.cpp |  4 ++--
 xc3sprog.1    |  1 +
 xc3sprog.cpp  |  3 ++-
 6 files changed, 25 insertions(+), 10 deletions(-)

diff --git a/bitfile.cpp b/bitfile.cpp
index e6e3198..1cae4d3 100644
--- a/bitfile.cpp
+++ b/bitfile.cpp
@@ -88,7 +88,7 @@ int BitFile::readBitfile(FILE *fp)
 
 /* Read in whole file with bitflip */
 
-int  BitFile::readBIN(FILE *fp)
+int  BitFile::readBIN(FILE *fp, bool do_bitrev)
 {
     unsigned int i;
 
@@ -100,6 +100,10 @@ int  BitFile::readBIN(FILE *fp)
     if (buffer == 0)
         return 1;
     fread(buffer,1, length, fp);
+
+    if (!do_bitrev)
+	    return 0;
+
     for(i=0; i<length; i++)
     {
         unsigned char data = buffer[i];
@@ -318,7 +322,9 @@ int BitFile::readFile(FILE *fp, FILE_STYLE in_style)
     case STYLE_HEX_RAW:
         return readHEXRAW(fp);
     case STYLE_BIN:
-        return readBIN(fp);
+        return readBIN(fp, true);
+    case STYLE_BPI:
+        return readBIN(fp, false);
     default: fprintf(stderr, " Unhandled style %s\n",styleToString(in_style));
       return 1;
     }
@@ -477,6 +483,7 @@ uint32_t BitFile::saveAs(FILE_STYLE style, const char  *device,
     {
     case STYLE_BIT:
     case STYLE_BIN:
+    case STYLE_BPI:
       if(style == STYLE_BIT)
 	{
 	  uint8_t buffer[256] = {0x00, 0x09, 0x0f, 0xf0, 0x0f, 0xf0, 0x0f, 0xf0,
@@ -522,7 +529,11 @@ uint32_t BitFile::saveAs(FILE_STYLE style, const char  *device,
 	}
       for(i=0; i<clip; i++)
 	{
-	  byte b=bitRevTable[buffer[i]]; // Reverse bit order
+	  byte b;
+	  if (style != STYLE_BPI)
+		  b = bitRevTable[buffer[i]]; // Reverse bit order
+	  else
+		  b = buffer[i];
 	  fwrite(&b,1,1,fp);
 	}
       break;
@@ -678,6 +689,8 @@ int BitFile::styleFromString(const char *stylestr, FILE_STYLE *style)
 	*style = STYLE_BIT;
     else if (!strncasecmp(stylestr, "BIN", len))
 	*style = STYLE_BIN;
+    else if (!strncasecmp(stylestr, "BPI", len))
+	*style = STYLE_BPI;
     else if (!strncasecmp(stylestr, "HEX", len))
 	*style = STYLE_HEX;
     else if (!strncasecmp(stylestr, "HEXRAW", len))
diff --git a/bitfile.h b/bitfile.h
index 8d45f83..1cfbf4c 100644
--- a/bitfile.h
+++ b/bitfile.h
@@ -72,7 +72,7 @@ word. */
 
 typedef unsigned char byte;
 
-enum FILE_STYLE { STYLE_BIT, STYLE_BIN, STYLE_HEX, STYLE_HEX_RAW, 
+enum FILE_STYLE { STYLE_BIT, STYLE_BIN, STYLE_BPI, STYLE_HEX, STYLE_HEX_RAW,
                   STYLE_MCS, STYLE_IHEX , STYLE_JEDEC, STYLE_AUTO};
 
 class BitFile
@@ -96,7 +96,7 @@ class BitFile
   void readField(std::string &field, FILE *fp);
   void processData(FILE *fp);
   int  readBitfile(FILE *fp);
-  int  readBIN(FILE *fp);
+  int  readBIN(FILE *fp, bool do_bitrev);
   int  readHEXRAW(FILE *fp);
   int  readMCSfile(FILE *fp);
   unsigned char checksum(char * buf);
diff --git a/bitparse.cpp b/bitparse.cpp
index 30e75f6..d28c6a5 100644
--- a/bitparse.cpp
+++ b/bitparse.cpp
@@ -36,8 +36,8 @@ void usage() {
 	  "\nUsage:bitparse [-i input format] [-o output format ][-O outfile] infile\n"	  "   -h\t\tprint this help\n"
 	  "   -v\t\tverbose output\n"
 	  "   -O\t\toutput file (parse input file only if not given\n"
-	  "   -i\t\tinput  file format (BIT|BIN|HEX|MCS|IHEX)\n"
-	  "   -o\t\toutput file format (BIT|BIN|HEX|MCS|IHEX)\n");
+	  "   -i\t\tinput  file format (BIT|BIN|BPI|HEX|MCS|IHEX)\n"
+	  "   -o\t\toutput file format (BIT|BIN|BPI|HEX|MCS|IHEX)\n");
   exit(255);
 }
 
diff --git a/xc2c_warp.cpp b/xc2c_warp.cpp
index c2c8eec..0b3a55f 100644
--- a/xc2c_warp.cpp
+++ b/xc2c_warp.cpp
@@ -14,8 +14,8 @@ void usage() {
 	  "   -v\t\tverbose output\n"
 	  "   -m\t\tDirectory containg Map files\n"
 	  "   -O\t\toutput file (parse input file only if not given\n"
-	  "   -i\t\tintput file format (BIT|BIN|HEX)\n"
-	  "   -o\t\toutput file format (BIT|BIN|HEX)\n");
+	  "   -i\t\tintput file format (BIT|BIN|BPI|HEX)\n"
+	  "   -o\t\toutput file format (BIT|BIN|BPI|HEX)\n");
    exit(255);
 }
 
diff --git a/xc3sprog.1 b/xc3sprog.1
index d3fce4d..686c83c 100644
--- a/xc3sprog.1
+++ b/xc3sprog.1
@@ -208,6 +208,7 @@ Xilinx \.BIT file format.
 Default for FPGA, XCF and SPI devices.
 T}
 BIN@Raw binary file.
+BPI@Raw binary file not bit reversed.
 MCS@Xilinx .MCS file format.
 IHEX@T{
 Intel HEX format.
diff --git a/xc3sprog.cpp b/xc3sprog.cpp
index 129ebd3..e6eabca 100644
--- a/xc3sprog.cpp
+++ b/xc3sprog.cpp
@@ -346,9 +346,10 @@ void usage(bool all_options)
   fprintf(stderr, "\tR: Read from device and write to file, overwrite existing file\n");
   fprintf(stderr, "\tDefault action is 'w'\n\n");
   fprintf(stderr, "\tDefault offset is 0\n\n");
-  fprintf(stderr, "\tstyle: One of BIT|BIN|MCS|IHEX|HEX\n");
+  fprintf(stderr, "\tstyle: One of BIT|BIN|BPI|MCS|IHEX|HEX\n");
   fprintf(stderr, "\tBIT: Xilinx .bit format\n");
   fprintf(stderr, "\tBIN: Binary format\n");
+  fprintf(stderr, "\tBPI: Binary format not bit reversed\n");
   fprintf(stderr, "\tMCS: Intel Hex File, LSB first\n");
   fprintf(stderr, "\tIHEX: INTEL Hex format, MSB first (Use for Xilinx .mcs files!)\n");
   fprintf(stderr, "\tHEX:  Hex dump format\n");
-- 
2.0.0

Re: [Xc3sprog-users] Board XUPV5

[Adrien Prost-B. <adr...@la...>]

> > I also run Valgrind on the recompiled xc3sprog, and the errors still
> > appear! So there something else not linked to devices not found.
> > "Conditional jump or move depends on uninitialised value(s)"
> 
> Yes, it looks like an uninitialized member variable in class IOXPC.
> I don't dare touch that code unless I have an actual XPC board on my
> desk to test with.
> 
> It would be great if you can fix these issues on your setup. The JTAG
> cable drivers are mostly talking to scarcely documented reverse
> engineered firmware. So any change must be carefully tested to make
> sure it doesn't break stuff.

I investigated these Valgrind errors. All are related to the field
"subtype" of class "IOXPC" being uninitialized.

In all the source files, this field is only used to test if its value is
XPC_INTERNAL (defined to 1 at ioxpc.h:37). And it is the only value this
field is set to in all source files.
So the intended behaviour is without doubt an initialization at zero.
The solution is to add the initialization "subtype(0)" to ioxpc.cpp:40

I recompiled and successfully programming the XUPV5 board. Valgrind is
happy now. I don't have more HW available to test, but given the low
criticality of the fix this should be enough ?

Adrien

Re: [Xc3sprog-users] Board XUPV5

[Joris v. R. <jor...@jo...>]

On 2014-05-15, Adrien Prost-Boucle wrote:
> I added this line to devlist.txt and recompiled:
> 0a001093      8    0x0 SystemACE

> I've tried to program the board ant it seems all works well. Great!

Good, thanks for testing.
I added SystemACE to the devlist.txt in SVN.
Incorrect labeling of the XC5VLX110T should also be fixed now.

> I also run Valgrind on the recompiled xc3sprog, and the errors still
> appear! So there something else not linked to devices not found.
> "Conditional jump or move depends on uninitialised value(s)"

Yes, it looks like an uninitialized member variable in class IOXPC.
I don't dare touch that code unless I have an actual XPC board on my
desk to test with.

It would be great if you can fix these issues on your setup. The JTAG
cable drivers are mostly talking to scarcely documented reverse
engineered firmware. So any change must be carefully tested to make
sure it doesn't break stuff.

Joris.

Re: [Xc3sprog-users] Board XUPV5

[Joris v. R. <jor...@jo...>]

On 2014-05-15, Adrien Prost-Boucle wrote:
> My devlist.txt file is traight from VPN repo.
> I have this for the device:
> line 84:
> 02ad6093     10  0x3c9 XC5VLX110T
> 
> The ID of the corresponding jtag loc. 4 is:
> 0x72ad6093

Right. It turns out that the incorrect labeling of your FPGA as XCF32P
is indeed a bug in xc3sprog, triggered by the unknown device in your
JTAG chain. I will try to fix it this weekend.

> BTW, why all IDs in devlist.txt begin by '0'? Reserved usage?

The first nibble is a revision number. It is ignored for IDCODE
matching.

> JTAG loc.:   4  IDCODE: 0x72ad6093  Desc: XC5VLX110T Rev: G  IR length: 10
> There we have the FPGA :)

Excellent. If you add the systemace device to devlist.txt, you should
be able to access the FPGA with xc3sprog.

Joris.

Re: [Xc3sprog-users] Board XUPV5

[Adrien Prost-B. <adr...@la...>]

Aaaargh.
You should really have a look at the Valgrind report (attached)...
Adrien

On Thu, 2014-05-15 at 19:12 +0200, Joris van Rantwijk wrote:
> On 2014-05-15, Adrien Prost-Boucle wrote:
> > JTAG loc.:   0  IDCODE: 0xf5059093  Desc: XCF32P Rev: O  IR length: 16
> > JTAG loc.:   1  IDCODE: 0xf5059093  Desc: XCF32P Rev: O  IR length: 16
> > JTAG loc.:   2  IDCODE: 0x59608093  Desc: XC95144XL Rev: E  IR length:  8
> 
> Ok, two flash PROMs and one CPLD.
> 
> > JTAG loc.:   3  IDCODE: 0x0a001093  not found in 'built-in device list'.
> 
> This is a SystemACE controller. It is not supported by xc3sprog.
> You probably don't need to talk to it, but an unrecognized device
> in the JTAG chain makes it impossible for xc3sprog to talk to the
> other device.
> 
> To solve that, you could add an entry to devlist.txt with the 
> correct IDcode, instruction length and description.
> Instruction length should be 8 according to xccace.bsd.
> 
> > JTAG loc.:   4  IDCODE: 0x72ad6093   Desc: XCF32P Rev: G  IR length: 10
> 
> This is the FPGA. It should be recognized as XC5VLX110T.
> It is very strange that xc3sprog would label it as XCF32P; that
> must be a weird bug in xc3sprog or something wrong with your devlist.txt
> file.
> 
> Joris.

Re: [Xc3sprog-users] Board XUPV5

[Adrien Prost-B. <adr...@la...>]

On Thu, 2014-05-15 at 19:12 +0200, Joris van Rantwijk wrote:
> On 2014-05-15, Adrien Prost-Boucle wrote:
> > JTAG loc.:   0  IDCODE: 0xf5059093  Desc: XCF32P Rev: O  IR length: 16
> > JTAG loc.:   1  IDCODE: 0xf5059093  Desc: XCF32P Rev: O  IR length: 16
> > JTAG loc.:   2  IDCODE: 0x59608093  Desc: XC95144XL Rev: E  IR length:  8
> 
> Ok, two flash PROMs and one CPLD.
> 
> > JTAG loc.:   3  IDCODE: 0x0a001093  not found in 'built-in device list'.
> 
> This is a SystemACE controller. It is not supported by xc3sprog.
> You probably don't need to talk to it, but an unrecognized device
> in the JTAG chain makes it impossible for xc3sprog to talk to the
> other device.
> 
> To solve that, you could add an entry to devlist.txt with the 
> correct IDcode, instruction length and description.
> Instruction length should be 8 according to xccace.bsd.


> > JTAG loc.:   4  IDCODE: 0x72ad6093   Desc: XCF32P Rev: G  IR length: 10
> 
> This is the FPGA. It should be recognized as XC5VLX110T.
> It is very strange that xc3sprog would label it as XCF32P; that
> must be a weird bug in xc3sprog or something wrong with your devlist.txt
> file.

My devlist.txt file is traight from VPN repo.
I have this for the device:

http://sourceforge.net/p/xc3sprog/code/HEAD/tree/trunk/devlist.txt
line 84:

02ad6093     10  0x3c9 XC5VLX110T

The ID of the corresponding jtag loc. 4 is:
0x72ad6093
BTW, why all IDs in devlist.txt begin by '0'? Reserved usage?

Also in devlist.txt:
05059093     16   0xfe XCF32P
Only the last 3 digits match... IMHO there is a potentially serious
issue somewhere.

I noticed there is a program 'detetchain' shipped with xc3sprog. So i
run it:

[adrien] > detectchain -c xpc
JTAG loc.:   0  IDCODE: 0xf5059093  Desc:                         XCF32P
Rev: O  IR length: 16
JTAG loc.:   1  IDCODE: 0xf5059093  Desc:                         XCF32P
Rev: O  IR length: 16
JTAG loc.:   2  IDCODE: 0x59608093  Desc:                      XC95144XL
Rev: E  IR length:  8
JTAG loc.:   3  IDCODE: 0x0a001093  not found in 'built-in device list'.
JTAG loc.:   4  IDCODE: 0x72ad6093  Desc:                     XC5VLX110T
Rev: G  IR length: 10

There we have the FPGA :)

Adrien.

Re: [Xc3sprog-users] Board XUPV5

[Joris v. R. <jor...@jo...>]

On 2014-05-15, Adrien Prost-Boucle wrote:
> JTAG loc.:   0  IDCODE: 0xf5059093  Desc: XCF32P Rev: O  IR length: 16
> JTAG loc.:   1  IDCODE: 0xf5059093  Desc: XCF32P Rev: O  IR length: 16
> JTAG loc.:   2  IDCODE: 0x59608093  Desc: XC95144XL Rev: E  IR length:  8

Ok, two flash PROMs and one CPLD.

> JTAG loc.:   3  IDCODE: 0x0a001093  not found in 'built-in device list'.

This is a SystemACE controller. It is not supported by xc3sprog.
You probably don't need to talk to it, but an unrecognized device
in the JTAG chain makes it impossible for xc3sprog to talk to the
other device.

To solve that, you could add an entry to devlist.txt with the 
correct IDcode, instruction length and description.
Instruction length should be 8 according to xccace.bsd.

> JTAG loc.:   4  IDCODE: 0x72ad6093   Desc: XCF32P Rev: G  IR length: 10

This is the FPGA. It should be recognized as XC5VLX110T.
It is very strange that xc3sprog would label it as XCF32P; that
must be a weird bug in xc3sprog or something wrong with your devlist.txt
file.

Joris.

Re: [Xc3sprog-users] Board XUPV5

[Adrien Prost-B. <adr...@la...>]

Compiled from SVN today. The FPGA is not recognized. The xc3sprog output
is at the end of this message.

All docs about this board are here:
http://www.xilinx.com/products/boards/ml505/docs.htm
In the board user guide there is an image showing the JTAG chain (p 53).
The FPGA could be hidden behind the SystemACE controller ?

Adrien


==================================
[adrien] > xc3sprog -c xpc -j -v
XC3SPROG (c) 2004-2011 xc3sprog project $Rev: 760 $ 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 built-in device list
Using built-in cable list
firmware version = 0x0012 (18)
CPLD version = 0x0012 (18)
Cannot find device having IDCODE=a001093 Revision A
JTAG loc.:   0  IDCODE: 0xf5059093  Desc:                         XCF32P
Rev: O  IR length: 16
JTAG loc.:   1  IDCODE: 0xf5059093  Desc:                         XCF32P
Rev: O  IR length: 16
JTAG loc.:   2  IDCODE: 0x59608093  Desc:                      XC95144XL
Rev: E  IR length:  8
JTAG loc.:   3  IDCODE: 0x0a001093  not found in 'built-in device list'.
JTAG loc.:   4  IDCODE: 0x72ad6093  Desc:                         XCF32P
Rev: G  IR length: 10
USB Read Transactions: 6 Write Transactions: 9 Control Transaction 17

On Thu, 2014-05-15 at 00:03 +0200, Jiri Gaisler wrote:
> The XUPV5 board uses a XC5VLX110T device, which is supported in SVN.
> Re-build from head and it should work OK.
> 
> Jiri.
> 
> On 2014-05-14 22:15, Adrien Prost-Boucle wrote:
> > Thanks for your answer. I'll recheck all that tomorrow because I don't
> > have the board right now. And I'll rebuild from SVN.
> > Adrien
> > 
> > On Wed, 2014-05-14 at 21:07 +0200, Joris van Rantwijk wrote:
> >> On 2014-05-14, Adrien Prost-Boucle wrote:
> >>> I'm using the FPGA board XUPV5. I tried to use the tool xc3sprog to
> >>> program it, but it failed to regognize the IDs of 2 devices on the
> >>> board, one of them being the FPGA -_-
> >>
> >> Virtex 5 should be supported by Xc3sprog. At the very least the FPGA
> >> type should be recognized and reported.
> >>
> >> Which version of Xc3sprog do you use?
> >> What kind of JTAG cable?
> >>
> >> Can you post the complete output of xc3sprog with verbose flag?
> >>
> >>> - Is adding support for a board a complex task?
> >>
> >> Depends on how similar the board is to already supported boards.
> >>
> >>> - What information do I need to have about the board chips?
> >>
> >> - FPGA type
> >> - Type of flash PROM chip (for FPGA power-on configuration)
> >> - Wiring between flash PROM and FPGA
> >> - JTAG chain layout
> >> - In case of an on-board JTAG programmer (USB), type of JTAG/USB chip
> >>   and possibly some reverse engineering of the USB communication.
> >>
> >> Joris.
> > 

Re: [Xc3sprog-users] Board XUPV5

[Jiri G. <ji...@ga...>]

The XUPV5 board uses a XC5VLX110T device, which is supported in SVN.
Re-build from head and it should work OK.

Jiri.

On 2014-05-14 22:15, Adrien Prost-Boucle wrote:
> Thanks for your answer. I'll recheck all that tomorrow because I don't
> have the board right now. And I'll rebuild from SVN.
> Adrien
> 
> On Wed, 2014-05-14 at 21:07 +0200, Joris van Rantwijk wrote:
>> On 2014-05-14, Adrien Prost-Boucle wrote:
>>> I'm using the FPGA board XUPV5. I tried to use the tool xc3sprog to
>>> program it, but it failed to regognize the IDs of 2 devices on the
>>> board, one of them being the FPGA -_-
>>
>> Virtex 5 should be supported by Xc3sprog. At the very least the FPGA
>> type should be recognized and reported.
>>
>> Which version of Xc3sprog do you use?
>> What kind of JTAG cable?
>>
>> Can you post the complete output of xc3sprog with verbose flag?
>>
>>> - Is adding support for a board a complex task?
>>
>> Depends on how similar the board is to already supported boards.
>>
>>> - What information do I need to have about the board chips?
>>
>> - FPGA type
>> - Type of flash PROM chip (for FPGA power-on configuration)
>> - Wiring between flash PROM and FPGA
>> - JTAG chain layout
>> - In case of an on-board JTAG programmer (USB), type of JTAG/USB chip
>>   and possibly some reverse engineering of the USB communication.
>>
>> Joris.
> 
> 
> 
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos.
> Get unparalleled scalability from the best Selenium testing platform available
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
> _______________________________________________
> Xc3sprog-users mailing list
> Xc3...@li...
> https://lists.sourceforge.net/lists/listinfo/xc3sprog-users
>