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

Matthias Fuchs matthias.fuchs at esd-electronics.com
Tue Aug 21 14:53:28 CEST 2007


Laurent,

On Tuesday 21 August 2007 13:33, Laurent Pinchart wrote:
> On Tuesday 21 August 2007 12:46, Matthias Fuchs wrote:
> > Laurent,
> >
> > now things are getting clearer.
> > All this sounds to me that the shift direction in
> > slave serial mode is not compatible to the parallel download
> > code. When we say that fpga_load (and the fpga load command) should only
> > work for promgen files with mirrored bits and fpga_loadbitstream()
> > (and the fpga loadb command) should be used for .bit files, I
> > would like to get rid of the mirroring at least for slave serial mode
> > because changing the shift order is much more efficient.
> 
> If I understand things well, you would like to get rid of the bit mirroring 
> code to optimize slave serial loading (where changing the shift direction has 
> no performance impact).
yes.
> 
> > Bruce suggested a CONFIG option to turn on/off mirroring. This is
> > not the right way. It should be handled by the FPGA subsystem.
> 
> Agreed.
> 
> > What about passing a bitorder flag down to the load functions?
> > So we get rid of the huge malloc in loadbitstream and we can
> > just swap bits in parallel mode just before writing it to the
> > FPGA port.
> 
> Would it have an impact on slave parallel performances ? Mirroring each byte 
> separately in the slave parallel code might slow things down. I personally 
> don't use the bitstream mirroring code (I use PROM files, so the bitstream is 
> mirrored on the host before loading it to the target flash memory), but it 
> might affect other users.
Well, there is only one public board that uses the FPGA code.

> 
> > For Slave serial mode the _load funtion can use 
> > the correct shift direction and so swapping is needed.
> 
> I suppose you mean "swapping is not needed", as the load function would choose 
> the shift direction depending on the bitorder flag.
yes, of course.
> 
> it seemed cleaner to me to handler mirroring at the high level, so lower-level 
> layers wouldn't have to care about it. If you want to optimize performances, 
> why don't you use a PROM file instead of a .bit file ?
We never used prom files before:-) And as you have noticed I was not aware of this
mirroring issues before. I also do not want to miss the informational header of the 
.bit files.

In the end I will starting fixing the current implementation keeping the swapping
in 'loadb' but this means that the shift direction of the serial slave functions
must be changed.

Matthias





More information about the U-Boot mailing list