On Monday, November 23, 2015 at 11:50:15 PM, Dinh Nguyen wrote:
On 11/23/2015 04:46 PM, Marek Vasut wrote:
On Monday, November 23, 2015 at 11:32:27 PM, Dinh Nguyen wrote: [...]
> The main point is that we need to program the FPGA > during U-Boot booting up with a ~>10 MB rbf file while being limited > to the OCRAM's size. I would like to contain this ugliness in it's > own directory.
What's the problem with this ? We already support loading files from storage in SPL, so just compile the FPGA manager into SPL as well and use it.
Ok, let me re-work it all under the c5/a5 directory. Thanks for reviewing.
But you didn't really answer my question -- what is the problem with the FPGA loader in SPL ?
I thought you've already answered your own question. For whatever reason, the downstream A10 is re-doing the FPGA manager just for this purpose.
Could the reason be that the FPGA manager in it's current state expects one big buffer with the entire FPGA bitstream ? When you're in SPL and you still don't have DRAM running, you cannot create such buffer anywhere. Thus, what you need to do is to have some sort of code which loads a bit of the bitstream file at time and feeds it into the FPGA manager, piece by piece. This should be doable pretty easily, what do you think ?
That's exactly what is being in the mach-socfpga directory.
Um, am I missing it in this patchset ?
Yes, but should that code go into mach-socfpga or drivers?
The FPGA manager bits are already in drivers/fpga/ , so that's where the improvements should go. If you need some special handling in the SPL, that should be in mach-socfpga . In case it's too much change to the current SPL, moving the spl.c to spl-gen5.c and creating new spl-gen10.c might make sense ... or something like that, possibly even with some spl-common.c .
Best regards, Marek Vasut