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

Laurent Pinchart laurentp at cse-semaphore.com
Tue Aug 21 10:59:44 CEST 2007


Hi Matthias,

On Monday 20 August 2007 17:46, Matthias Fuchs wrote:
> 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'm calling fpga_load directly from board-specific code, using PROMgen 
generated data (with bit mirroring applied).

Bit mirroring might not be needed in slave serial mode, but is needed in slave 
parallel mode. Bytes in the .bit file are stored with the LSB on the left 
side. The bytes must then be reversed before being written in slave parallel 
mode, as the FPGA expects the LSB on D0, not on D7.

In slave serial mode, you can choose the shift direction, so mirroring is not 
required.

> I still vote for removing the bit mirror :-)

Without mirroring, bitstreams won't load in slave parallel mode. You should 
keep mirroring, and change the slave serial code to shift bits the other way 
around.

> > > 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?

I don't use the fpga commands, but call fpga_load() directly from board 
specific code. This is roughly equivalent to "fpga load". The data come from 
a bit-mirrored PROM file. I used to use a .bit file, which required "fpga 
loadb" to be loaded correctly.

-- 
Laurent Pinchart
CSE Semaphore Belgium

Chaussée de Bruxelles, 732A
B-1410 Waterloo
Belgium

T +32 (2) 387 42 59
F +32 (2) 387 42 75




More information about the U-Boot mailing list