[U-Boot] [PATCH v2 4/5] arm: socfpga: Add intermediate driver between flash and FPGA manager

[Chee, Tien Fong]

On Jum, 2017-08-11 at 17:09 +0200, Marek Vasut wrote:
> On 08/10/2017 06:43 AM, Chee, Tien Fong wrote:
> > 
> > On Rab, 2017-08-09 at 10:29 +0200, Marek Vasut wrote:
> > > 
> > > On 08/09/2017 06:50 AM, Chee, Tien Fong wrote:
> > > [...]
> > > 
> > > > 
> > > > 
> > > > > 
> > > > > 
> > > > > > 
> > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > If this is for some FPGA loading, can this functionality
> > > > > > > be
> > > > > > > scripted
> > > > > > > instead?
> > > > > > > 
> > > > > > Sorry, i'm not getting you. How functionality be scripted?
> > > > > > Could
> > > > > > you
> > > > > > provide some example or details explanation?
> > > > > ie. "load" (from fs) + "fpga load" (program FPGA) commands ?
> > > > > I think the fpga command already has some support for loading
> > > > > from FS
> > > > > too.
> > > > > 
> > > > Currently, we already have fpga load commands in fpga driver,
> > > > fpga
> > > > rbf
> > > > is loaded to memory, and programmed to fpga from memory, where
> > > > memory
> > > > location would be decided by user, it could be OCRAM or SDRAM.
> > > > 
> > > > for fpga loadfs command, i plan to implement it after having
> > > > complete
> > > > boot to U-boot console, since this is quite complex and
> > > > involving
> > > > some
> > > > hardware workaround issue, and some use case scenarios need to
> > > > be
> > > > considerd.
> > > So the arria10 u-boot port is still unable to boot to console ?
> > > 
> > Still need 2 to 3 more patchsets to get it boot to console.
> > > 
> > > > 
> > > > 
> > > > For example reconfiguring fpga with periperal rbf can
> > > > corrupt the sdram since sdram IOs is part of the fpga periph
> > > > rbf. I
> > > > need console to run a lot different scenarios testing.
> > > OK
> > > 
> > > > 
> > > > 
> > > > We still need cff.c, because most functionality in cff.c are
> > > > required
> > > > by fpga loadfs command.
> > > It seems a lot of stuff from this is common code, so why does it
> > > have
> > > to
> > > be in this driver again ?
> > This driver contains a lot "smart" functionality such as:
> I start to cringe when I read "smart functionality".
> 
> > 
> > 1: It having ability to the right memory(OCRAM or SDRAM) to achieve
> > the
> > best FPGA programing performance.
> Did you find significant throughput difference ?
> 
80% performance improvement with SDRAM.
> > 
> > 2: It can determine the right size buffer for the fpga rbf without
> > info
> > of buffer size defined by user.
> You mean like $filesize variable in the command prompt ?
> 
Yeah. No filesize is required.
> > 
> > 3: It has ability to know what kind of fpga rbf type, and security
> > type, such as peripheral, core, combined rbf, encryption and
> > unencryption based on any fpga file user pass in .
> Is this information used for anything ? I was under the impression
> that
> the user just needs to load in the correct RBF file into the FPGA.
> 
Yeah, the driver would decode the RBF image to know what type of RBF
user loading, and applying correct method(buffer allocation, which
memory to use and configuration on FPGA manager) to program FPGA.
> > 
> > 4: It supports the checksum.
> What checksum ? Can we have a generic hook into the FPGA framework ?
> 
This checksum is to ensure integrity of RBF file after loading from
flash into SDRAM. This can help to prevent possibility system
instability caused by programming corrupt rbf into FPGA. So, this
should be implemented in cff.c .
> > 
> > 5: support raw flash without fs.
> This should go into common code.
> 
raw flash is part of common codes in cff.c because it is part of
mechanism like fs to determine how loading rbf from flash and program
into fpga.
> > 
> > 6: support the file name defined in DTS and U-boot environment
> > variable.
> I think you should extend the FPGA LOADFS here instead.
> 
The peripheral rbf filename and DTS are generated from our bsp tool.
But user can run fpga loadfs to reconfigure FPGA in U-boot console
after i have supported it.
> > 
> > > 
> > >  Also, the ifdeffery is awful and the explicit
> > > depedence on VFAT when loading from FS is real bad.
> > > 
> > It is because a lot functions is common to sdmmc, nand and qspi in
> > different fs such as vfat, ubi and raw. It is unavoidable to have
> > some
> > ifdeffery if we want to keep the function common to all flashes and
> > fs. 
> Can the FPGA LOADFS be extended generically ?
> 
Yeah, FPGA loadfs is considered when design cff.c. But, i plan to to
support FPGA loadfs after having complete boot to U-boot console.
> > 
> > > 
> > > [...]
>