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

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().

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.

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?

BTW: Are there any boards that use the FPGA stuff and that are not made public ?:-)

Hi Matthias,

Quoted 14 lines · Matthias Fuchs

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:

Quoted 8 lines

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."

Quoted 6 lines

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.

Quoted 3 lines

5) Add a post() configuration callback for Spartan II devices in slave serial mode.

Quoted 5 lines

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.

Quoted 3 lines

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.

Hi Laurent,

Quoted 29 lines · Laurent Pinchart

Hi Matthias,

Quoted 14 lines · Matthias Fuchs

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:

Quoted 8 lines

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:

Quoted 6 lines

"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 :-)

Quoted 13 lines

Quoted 5 lines

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.

Quoted 3 lines

5) Add a post() configuration callback for Spartan II devices in slave serial mode.

Quoted 8 lines

Quoted 5 lines

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.

Quoted 4 lines

Quoted 2 lines

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?

Quoted 2 lines

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.

Quoted 1 line

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.

Quoted 2 lines

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,

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.

Bruce suggested a CONFIG option to turn on/off mirroring. This is not the right way. It should be handled by the FPGA subsystem.

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.

For Slave serial mode the _load funtion can use the correct shift direction and so swapping is needed.

Quoted 27 lines

Quoted 2 lines

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.

Quoted 1 line

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.

Quoted 2 lines

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.

Quoted 10 lines · Matthias Fuchs

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).

Quoted 3 lines

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.

Quoted 4 lines

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.

Quoted 3 lines

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.

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 ?

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

side. The bytes must then be reversed before being written in slave

mode, as the FPGA expects the LSB on D0, not on D7.

Without mirroring, bitstreams won't load in slave parallel mode. You

keep mirroring, and change the slave serial code to shift bits the other

around.

Quoted 4 lines

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.

Again, it depends on the processor you are using and how it's hooked up to the FPGA. BTW, according to the Spartan 3 data sheet "data bit D0 is the MOST-significant (msb) bit and D7 is the least-significant bit (lsb)" (pg 167, Xilinx UG332 Spartan-3 Generation confiuration User Guide). Maybe you are refering to a different FPGA?

Quoted 3 lines

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.

I must respectfully disagree. In my design, if I mirror in the code the FPGA does NOT load. In a PPC, D0 is the MSB, NOT the LSB. In a Spartan 3 FPGA, D0 is the MSB, NOT the LSB. Therefore if you connect your bus straight across between the PPC and the Spartan 3 FPGA, AND do mirroring in the code, your FPGA will not load.

Quoted 5 lines

I must respectfully disagree. In my design, if I mirror in the code the FPGA does NOT load. In a PPC, D0 is the MSB, NOT the LSB. In a Spartan 3 FPGA, D0 is the MSB, NOT the LSB. Therefore if you connect your bus straight across between the PPC and the Spartan 3 FPGA, AND do mirroring in the code, your FPGA will not load.

I got a similar design, except that D0-D7 on the PPC are connected to D7-D0 on the FPGA. I'll go scold our hardware engineer :-)

With a properly connected bus between the processor and the FPGA, bit reversal is thus not needed when loading a .bit file (fpga loadb) or a non mirrored PROM file (fpga load).

For hardware with bit mirroring on the bus, I suggest either using a mirrored PROM file or mirroring the bit in the data write callback. I thus vote for

removing bit mirroring in fpga_loadbitstream() and adding an explanation of

this issue (either in the code or in the documentation) to prevent hardware mistakes in future designs.

Hi Laurent,

you cannot imagine how many grey hair this bit naming and numbering convention cost me. I learned to never use D0/7 when meaning MSB/LSB:-)

Quoted 8 lines · Laurent Pinchart

Quoted 5 lines

I must respectfully disagree. In my design, if I mirror in the code the FPGA does NOT load. In a PPC, D0 is the MSB, NOT the LSB. In a Spartan 3 FPGA, D0 is the MSB, NOT the LSB. Therefore if you connect your bus straight across between the PPC and the Spartan 3 FPGA, AND do mirroring in the code, your FPGA will not load.

I got a similar design, except that D0-D7 on the PPC are connected to D7-D0 on the FPGA. I'll go scold our hardware engineer :-)

Sometimes it's even worth as softwa/orkers to review schematics when you know that you will get the board on your desk for writing software :-) (But do not sign anything or the hardware engineer will scold you afterwards.)

Quoted 3 lines

With a properly connected bus between the processor and the FPGA, bit reversal is thus not needed when loading a .bit file (fpga loadb) or a non mirrored PROM file (fpga load).

BTW, you can even load a .bit file using fpga load because the FPGA will discard the header.

Quoted 3 lines

For hardware with bit mirroring on the bus, I suggest either using a mirrored PROM file or mirroring the bit in the data write callback. I thus vote for

Ack

Quoted 2 lines

removing bit mirroring in fpga_loadbitstream() and adding an explanation of

Ack. So all the malloc and the timeconsuming loop code will disappear. Yippi!

Quoted 2 lines

this issue (either in the code or in the documentation) to prevent hardware mistakes in future designs.

Good idea. But do you think that hardware engineers will read through the cmd_fpga.c file?

I will cleanup my changes and submit a patch soon.

Sometimes it's even worth as softwa/orkers to review schematics when you

know that you will get the board on your desk for writing software :-) (But do not sign anything or the hardware engineer will scold you

Hi Bruce,

ordering. UG322 sheds some light on the issue. D0-D7 are indeed MSB-LSB,

making the SelectMAP interface use the big-endian PPC bit ordering convention.

to D7-D0 on
the FPGA. I'll go scold our hardware engineer :-)

With a properly connected bus between the processor and the FPGA, bit reversal
is thus not needed when loading a .bit file (fpga loadb) or a non

PROM file (fpga load).

For hardware with bit mirroring on the bus, I suggest either using

PROM file or mirroring the bit in the data write callback. I thus vote

removing bit mirroring in fpga_loadbitstream() and adding an explanation

this issue (either in the code or in the documentation) to prevent

mistakes in future designs.

Hi Laurent,

Laurent Pinchart <[email protected]> wrote on 08/22/2007 12:28:36 AM:

Quoted 2 lines

Hi Bruce,

Quoted 4 lines

ordering. UG322 sheds some light on the issue. D0-D7 are indeed MSB-LSB,

making the SelectMAP interface use the big-endian PPC bit ordering convention.

I'm with Matthaias, I've learned to refer to them as MSB/LSB on the list :). Avoids confusion.

Quoted 2 lines

to D7-D0 on
the FPGA. I'll go scold our hardware engineer :-)

Don't scold him to hard. It's an easy mistake to make especially if you're used to everything being little endian. (I can say this because I am a HW engineer and I've made this mistake!)

Hi All:

Did anybody use u-boot to load vxWorks? I have sequoia board (NOR flash) and when I tried simply boot vxWorks elf, it hangs.

vxWorks native bootrom.bin works fine, booting the very same vxWorks elf perfectly.

Thanks,

Leonid.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
U-Boot-Users mailing list
U-Boot-Users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Hi All:

Did anybody use u-boot to load vxWorks? I have sequoia board (NOR flash) and when I tried simply boot vxWorks elf, it hangs.

vxWorks native bootrom.bin works fine, booting the very same vxWorks elf perfectly.

Thanks,

Leonid.

----------------------------------------------------------------------
--- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a

Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
U-Boot-Users mailing list
U-Boot-Users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Hi, Chris:

Could you please clarify what 8641D_74K_1 image was? vxWorks elf, binary, or some combination of bootrom and kernel?

Hi, Chris:

Could you please clarify what 8641D_74K_1 image was? vxWorks elf, binary, or some combination of bootrom and kernel?

Hi All:

Did anybody use u-boot to load vxWorks? I have sequoia board (NOR flash)
and when I tried simply boot vxWorks elf, it hangs.

vxWorks native bootrom.bin works fine, booting the very same vxWorks elf
perfectly.

Thanks,

Leonid.

Quoted 1 line

Quoted 1 line

Leonid<[email protected]> schrieb am 22.08.07 um 20:03 in Nachricht

Hi All:

Did anybody use u-boot to load vxWorks? I have sequoia board (NOR flash) and when I tried simply boot vxWorks elf, it hangs.

vxWorks native bootrom.bin works fine, booting the very same vxWorks elf perfectly.

I agree with all of this with the exception of totally removing the bit mirroring in fpga_loadbitstream(). If this were going in only a single product or it was being done for the first timeI would be all over that, however we know for a fact that there's at least one board out in the wild that relies on that bit mirroring to take place (another un-enlightened HW engineer no doubt ;) ). Flat out removing the code will break that board and I'm not inclined to face the wrath of the maintainer. If we can figure out who depends on that and get them to push the bit mirroring down to the call back function where it rightfully belongs than I agree remove the code. Otherwise I think it needs to conditionally stay.

there is only one known board (GEN860) out there that uses the FPGA sub system.
That's why I put Keith as its maintainer on cc.
As Wolfgang stated we should not care about U-Boot ports that not made public and are not part of the U-Boot repository.

BTW: Are there any boards that use the FPGA stuff and that are not made public ?:-)

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().

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.

6) Add some more devices.

BTW: Are there any boards that use the FPGA stuff and that are not made public ?:-)

Quoted 2 lines

1) Make the 'size' parameter obsolete for the 'fpga loadb' command. The actual bitstream size is taken from the bitstream.

Agreed, plus you can remove the check against the size parameter passed in from the command line that doesn't make any sense.

Quoted 7 lines

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().

I would make this optional/configurable as I mentioned in my last post. Doing the bit swapping makes sense for a little endian processor but doesn't make sense for the big endian machines like the PPC.

Quoted 5 lines

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.

Agreed

Quoted 3 lines

6) Add some more devices.

More devices are always good. That way folks in the future have a starting place.

Quoted 1 line

Quoted 3 lines

BTW: Are there any boards that use the FPGA stuff and that are not made public ?:-)

Our board is totally custom and will never be used by anyone but us, but as Wolfgang pointed out that's not the lists problem that's our problem. Folks using u-boot need to be aware that things change and they need to be careful when doing pulls from the repository.

Quoted 2 lines

I would make this optional/configurable as I mentioned in my last

Quoted 2 lines

Doing the bit swapping makes sense for a little endian processor but doesn't make sense for the big endian machines like the PPC.

Why? AFAIK, the _bit_order has nothing to do with die CPU endianess. We are talking about mirrowing the 8 bits in a byte.