[U-Boot-Users] [PATCH] Spartan3 family support

[U-Boot-Users] [PATCH] Spartan3 family support

[Kurt Stremerch]

Hi all.

This small patch, against current cvs, adds Xilinx Spartan3 support. Only
the bitstream size differs from the Spartan2 family, the configuration
method stays the same.

Regards
Kurt

CHANGELOG:
* Patch by Kurt Stremerch, 14 February 2005:
  Add Xilinx Spartan3 family fpga support
-------------- next part --------------
A non-text attachment was scrubbed...
Name: spartan3.patch.gz
Type: application/octet-stream
Size: 5188 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20050214/84173a0f/attachment.obj 

[U-Boot-Users] [PATCH] Spartan3 family support

[llandre]

Hi Kurt,

I've just applied your patch to add Spartan III support on my custom
hardware (PPChameleon AMCC405EP).
To write the board-specific functions I used the file board/gen860t/fpga.c
as starting point. I work with cross GCC 2.95.4 provided by ELDK 2.0.2.
The programming technique is slave serial.
To make the code to work I had to apply some slight changes:

1) In function Spartan3_ss_load I had to replace this line

         (*fn->wr) ((val < 0), TRUE, cookie);

with
         if (val & 0x80) {
                 (*fn->wr) (1, TRUE, cookie);
         } else {
                 (*fn->wr) (0, TRUE, cookie);
         }

It seems the compiler does not like the expression (val < 0) because
it is always evaluated to 0.

2) It seems the board-specific function fpga_done_fn in board/gen860t/fpga.c
is wrong because it returns the error codes (either FPGA_SUCCESS or 
FPGA_FAIL). In my
understanding it must return the state of the pin (0 when the DONE
pin is low, 1 when it is high).

3) I tried to use both the "fpga load" and "fpga loadb" commands
respectively with the .bin and .bit files. The first one runs succesfully
while the latter fails. In this case the header is parsed correctly
but the FPGA is not programmed and the DONE does not go high.




Best regards,
llandre

DAVE Electronics System House - R&D Department
web:   http://www.dave-tech.it
email: r&d2@dave-tech.it



>Hi all.
>
>This small patch, against current cvs, adds Xilinx Spartan3 support. Only
>the bitstream size differs from the Spartan2 family, the configuration
>method stays the same.
>
>Regards
>Kurt
>
>CHANGELOG:
>* Patch by Kurt Stremerch, 14 February 2005:
>   Add Xilinx Spartan3 family fpga support

[U-Boot-Users] [PATCH] Spartan3 family support

[Kurt Stremerch]

> I've just applied your patch to add Spartan III support on my custom
> hardware (PPChameleon AMCC405EP).
> To write the board-specific functions I used the file
board/gen860t/fpga.c
> as starting point. I work with cross GCC 2.95.4 provided by ELDK
2.0.2.
> The programming technique is slave serial.
> To make the code to work I had to apply some slight changes:
> 
> 1) In function Spartan3_ss_load I had to replace this line
> 
>          (*fn->wr) ((val < 0), TRUE, cookie);
> 
> with
>          if (val & 0x80) {
>                  (*fn->wr) (1, TRUE, cookie);
>          } else {
>                  (*fn->wr) (0, TRUE, cookie);
>          }
> 
> It seems the compiler does not like the expression (val < 0) because
> it is always evaluated to 0.
> 
> 2) It seems the board-specific function fpga_done_fn in
> board/gen860t/fpga.c
> is wrong because it returns the error codes (either FPGA_SUCCESS or
> FPGA_FAIL). In my
> understanding it must return the state of the pin (0 when the DONE
> pin is low, 1 when it is high).

I can't commit my own fpga.c (spartan3) because this patch is not
commited. The gen860t isn't my board but if they should make the changes
to the gen860t code as you suggested, it wouldn't work. That's because
the gen860t uses the parallel mode of configuring its Virtex2, if you
check Virtex2_ssm_load(), Spartan3_sp_load() or Spartan2_sp_load() you
can see that the while condition that checks the DONE pin state is:

while ((*fn->done) (cookie) == FPGA_FAIL) {
in stead of:
while (! (*fn->done) (cookie)) { 

I tried to keep the code as compatibel with Spartan2 as I mentioned in
the patch mail. Also by comparing with a fpga state here, it becomes
more clear. Therefore it's maybe better to change the while condition in
the Spartan3_ss_load() function. I can be wrong, don't hesitate to
correct me if you disagree.

> 3) I tried to use both the "fpga load" and "fpga loadb" commands
> respectively with the .bin and .bit files. The first one runs
succesfully
> while the latter fails. In this case the header is parsed correctly
> but the FPGA is not programmed and the DONE does not go high.

The loadb function is a wrapper around the load function that converts
your bitstream file first. Could you check what the difference is
between your manually converted bitsteam file and the data that loadb
creates? Imagine that the fpga startup clock configuration is set to the
JTAG clock. Your conversion tool could change this automatically into
the config clock. But the loadb doesn't make any change to your
bitstream before the conversion takes place. This results in a
successful configuration in "fpga load" but not in "fpga loadb".

Kind regards
Kurt

[U-Boot-Users] [PATCH] Spartan3 family support

[Andrew Dyer]

On 4/27/05, Kurt Stremerch <kurt.stremerch@exys.be> wrote:

> > 3) I tried to use both the "fpga load" and "fpga loadb" commands
> > respectively with the .bin and .bit files. The first one runs
> succesfully
> > while the latter fails. In this case the header is parsed correctly
> > but the FPGA is not programmed and the DONE does not go high.
> 
> The loadb function is a wrapper around the load function that converts
> your bitstream file first. Could you check what the difference is
> between your manually converted bitsteam file and the data that loadb
> creates? Imagine that the fpga startup clock configuration is set to the
> JTAG clock. Your conversion tool could change this automatically into
> the config clock. But the loadb doesn't make any change to your
> bitstream before the conversion takes place. This results in a
> successful configuration in "fpga load" but not in "fpga loadb".

I posted a patch to change the loadb command on Jan 11 (see the
archives) that's not yet into cvs.  Here's the issue:

1) fixes a bug with the 'fpga loadb' command

The bug is in calculating the config data size - 4 bytes of length info were
being read as signed chars, casted to long, shifted and added.  The cast to
long was doing sign extension and causing an incorrect result if a byte was
greater than 0x80.  For me this caused the fpga load to end early and time out
waiting for the hardware completion.

There's some other stuff in the patch, too.  I think the file has changed since
I posted my patch, so there might be some breakage in applying it, but
it's pretty simple and I'm sure you can do it by hand :-)

-- 
Hardware, n.:
        The parts of a computer system that can be kicked.

[U-Boot-Users] [PATCH] Spartan3 family support

[llandre]

Hello guys,

thanks a lot for your support.
I've just retrieved Andrew's patch and I'll try to apply it in order
to make loadb to work too.


Best regards,
llandre

DAVE Electronics System House - R&D Department
web:   http://www.dave-tech.it
email: r&d2 at dave-tech.it




>On 4/27/05, Kurt Stremerch <kurt.stremerch@exys.be> wrote:
>
> > > 3) I tried to use both the "fpga load" and "fpga loadb" commands
> > > respectively with the .bin and .bit files. The first one runs
> > succesfully
> > > while the latter fails. In this case the header is parsed correctly
> > > but the FPGA is not programmed and the DONE does not go high.
> >
> > The loadb function is a wrapper around the load function that converts
> > your bitstream file first. Could you check what the difference is
> > between your manually converted bitsteam file and the data that loadb
> > creates? Imagine that the fpga startup clock configuration is set to the
> > JTAG clock. Your conversion tool could change this automatically into
> > the config clock. But the loadb doesn't make any change to your
> > bitstream before the conversion takes place. This results in a
> > successful configuration in "fpga load" but not in "fpga loadb".
>
>I posted a patch to change the loadb command on Jan 11 (see the
>archives) that's not yet into cvs.  Here's the issue:
>
>1) fixes a bug with the 'fpga loadb' command
>
>The bug is in calculating the config data size - 4 bytes of length info were
>being read as signed chars, casted to long, shifted and added.  The cast to
>long was doing sign extension and causing an incorrect result if a byte was
>greater than 0x80.  For me this caused the fpga load to end early and time out
>waiting for the hardware completion.
>
>There's some other stuff in the patch, too.  I think the file has changed 
>since
>I posted my patch, so there might be some breakage in applying it, but
>it's pretty simple and I'm sure you can do it by hand :-)

[U-Boot-Users] [PATCH] Spartan3 family support

[Wolfgang Denk]

In message <IBEKLCLJABNPKPBCGAHICEFNCLAA.kurt.stremerch@exys.be> you wrote:
> 
> CHANGELOG:
> * Patch by Kurt Stremerch, 14 February 2005:
>   Add Xilinx Spartan3 family fpga support

Added,thanks.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Madness has no purpose.  Or reason.  But it may have a goal.
	-- Spock, "The Alternative Factor", stardate 3088.7