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
>>>>> Sorry, i'm not getting you. How functionality be scripted?
>>>>> 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
>>> Currently, we already have fpga load commands in fpga driver, fpga
>>> is loaded to memory, and programmed to fpga from memory, where
>>> location would be decided by user, it could be OCRAM or SDRAM.
>>> for fpga loadfs command, i plan to implement it after having
>>> boot to U-boot console, since this is quite complex and involving
>>> hardware workaround issue, and some use case scenarios need to be
>> 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.
>>> We still need cff.c, because most functionality in cff.c are
>>> by fpga loadfs command.
>> It seems a lot of stuff from this is common code, so why does it have
>> 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 ?
> 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 ?
> 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.
> 4: It supports the checksum.
What checksum ? Can we have a generic hook into the FPGA framework ?
> 5: support raw flash without fs.
This should go into common code.
> 6: support the file name defined in DTS and U-boot environment
I think you should extend the FPGA LOADFS here instead.
>> 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
Can the FPGA LOADFS be extended generically ?
U-Boot mailing list