[U-Boot-Users] Some RFCs about U-Boot's the generic FPGA support

[Matthias Fuchs]

Hi Laurent,

On Monday 20 August 2007 15:47, Laurent Pinchart wrote:
> Hi Matthias,
> 
> On Monday 20 August 2007 15:13, Matthias Fuchs wrote:
> > Hi,
> >
> > I am currently setting up a new board that will use U-Boot's generic
> > FPGA support to boot zwi different Xilinx FPGA in slave serial mode.
> > While grep'ing through the U-Boot board config files I noticed that
> > nearly nobody uses this code.
> >
> > I made a couple of changes to the code. Some of them changes the
> > current behavior a little bit, so I like to request for comments
> > before submitting a final patch.
> >
> > Since nobody uses this code I see nothing that speaks against these
> > changes:
> >
> > 1) Make the 'size' parameter obsolete for the 'fpga loadb' command.
> > The actual bitstream size is taken from the bitstream.
> >
> > 2) Do not bit-swap the bytes in the xilinx bitstream. When using the
> > slave serial code the bits may not be swapped. I can imagine that this
> > swapping requirement comes from a special board layout. So is should
> > be done in board specific code. When removing the swapping code, we
> > can get rid of the complete malloc/free stuff in fpga_loadbitstream().
> 
> Bit-swapping is required when dealing with .bit files. The Development System 
> Reference Guide, Chapter 16 (PROMgen) states that:
> 
> "In a bitstream contained in a BIT file, the Least Significant Bit (LSB) is 
> always on the left side of a byte. But when a PROM programmer or a 
> microprocessor reads a data byte, it identifies the LSB on the right side of 
> the byte. In order for the PROM programmer or microprocessor to read the 
> bitstream correctly, the bits in each byte must first be swapped so they are 
> read in the correct order."
Yes and no. The U-Boot FPGA sub system provides two ways to boot FPGAs: 
'load' and 'loadb'. The first one takes the FPGA data stream and shifts
it out left/MSBit first (slave serial mode). 
This works fine for me with bitgen generated .bit file.

The loadb option does nearly the same, but it also dumps information from
the bitstream (creation date, size, device etc.), then it mirrors the bits
and finally calls the same code as the load option. You are right, when you 
say that prom files (generated by xilinx' promgen) are bitwise mirrored
against the .bit files, but they do not contain the bitstream information
that is parsed by the loadb option. Without the swapping of bits
I can use 'load' or 'loadb' with .bit files/images. I dare to say that
'loadb' will never programm prom files that are incompatible to .bit files.

So what option are you using for and which bitsteam format/file are you using?

I still vote for removing the bit mirror :-)

> 
> > 3) Fix a signed/unsigned issue in slave serial download code.
> >
> > 4) Make post() and pre() callback optional in relocation. So do
> > not relocate NULL-pointers. This has been discussed a short time ago
> > on the list.
> 
> Ack. I ran into the same issue and fixed the relocation issue, but found later 
> that I actually needed pre() and post() methods, so I never submitted a 
> patch.
> 
> > 5) Add a post() configuration callback for Spartan II devices in slave
> > serial mode.
> >
> > 6) Add some more devices.
> >
> > 7) Minor typo fixes.
> >
> > Any comments?
> 
> You should probably split your patch. Point 6 is a good candidate for a 
> standalone patch.
Of course. This was only for comments.
> 
> > BTW: Are there any boards that use the FPGA stuff and that are not
> > made public ?:-)
> 
> Yes. I use slave-parallel loading with a Spartan-3E.
Are you using .bit Images, PROM files and which fpga command option
do you use? load or loadb?

Matthias