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

[Marek Vasut]

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 ?

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

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

Can the FPGA LOADFS be extended generically ?

>> [...]


-- 
Best regards,
Marek Vasut