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

[Marek Vasut]

On 08/14/2017 05:58 AM, Chee, Tien Fong wrote:
> On Sab, 2017-08-12 at 18:49 +0200, Marek Vasut wrote:
>> On 08/12/2017 10:03 AM, Chee, Tien Fong wrote:
>> [...]
>>>

>
> 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.
>> This looks more like caches are not enabled ... sort of problem ?
>>
> It is because SDRAM size large enough to store whole rbf file and
> reduce significantly of the repetitive block transfer. It requires one
> time block transfer from SDRAM to FPGA compare to OCRAM which require
> more than that.

OK, do that as a subsequent optimization.

>>>

>
> 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.
>> You can use $filesize instead of reimplementing this functionality
>> yourself though ?
>>
> I'am sorry to have confused you. What i trying to say is user no longer
> require to specify the file size and location when calling fpga loadfs.
> So, this would keep the thing simple. The driver in cff.c would handle
> all these troublesome things and deciding the best route for good
> performance.

OK, separate patch

>>>

>
> 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.
>> If the code needs to extract some information from the RBF to
>> correctly
>> configure something in the FPGA manager, then that's where this
>> should
>> go then.
>>
> Those functions for extracting info from RBF and configuring the FPGA
> are actually come from fpga driver which i have submited as in previous
> patchset. The actualy implementation is in cff.c, as i try to explain
> cff.c drivers are mainly to handle all activities of loading rbf from
> flashes to program FPGA.

Such functionality should be generic and split between fpga loadfs and
the driver.

>>>

>
> 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 .
>> Or the FPGA manager driver .
>>
> This integrity checking is implemented during RBF loading from flash to
> SDRAM before calling the functions from fpga driver to program FPGA. So
> cff.c which is designed for handling these operation and it should
> be appropriate place for checksum.

Add a checksum hook into the FPGA framework ?

>>>

>
> 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.
>> By common code I mean the stuff around FPGA LOADFS , so other FPGAs
>> can
>> also benefit from that.
>>
> But the raw flash to FPGA implementation is designed fully tied to
> common codes in cff.c. FPGA loadfs would be acted like a wrapper to it,
> so i am not sure it can be shared by other FPGA.

I do not want any ad-hoc wrapper, implement it properly be extending
fpga loadfs or the fpga framework.

>>>

>
> 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.
>> And why don't you rather apply some FPGA LOADFS if this property is
>> detected in the DT instead of reimplementing it ?
>>
> We need to program the FPGA IO ring buffer from very early phase in SPL
> before SDRAM can be initialized. So we need the peripheral rbf file
> name from DTS, which is defined by user in our BSP tool. I don't think
> FPGA loadfs would be available in SPL by that time. So, i think FPGA
> loadfs is suitable for reprogramming FPGA in U-boot console, and
> filename is passed as parameter to fpga loadfs command.

Then just call the required bits from fpga loadfs during SPL . Extract
them into some fpga-loadfs-common and make both fpga loadfs 

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

[Chee, Tien Fong]

On Sab, 2017-08-12 at 18:49 +0200, Marek Vasut wrote:
> On 08/12/2017 10:03 AM, Chee, Tien Fong wrote:
> [...]
> > 
> > > 
> > > > 
> > > > 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.
> This looks more like caches are not enabled ... sort of problem ?
> 
It is because SDRAM size large enough to store whole rbf file and
reduce significantly of the repetitive block transfer. It requires one
time block transfer from SDRAM to FPGA compare to OCRAM which require
more than that.
> > 
> > > 
> > > > 
> > > > 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.
> You can use $filesize instead of reimplementing this functionality
> yourself though ?
> 
I'am sorry to have confused you. What i trying to say is user no longer
require to specify the file size and location when calling fpga loadfs.
So, this would keep the thing simple. The driver in cff.c would handle
all these troublesome things and deciding the best route for good
performance.
> > 
> > > 
> > > > 
> > > > 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.
> If the code needs to extract some information from the RBF to
> correctly
> configure something in the FPGA manager, then that's where this
> should
> go then.
> 
Those functions for extracting info from RBF and configuring the FPGA
are actually come from fpga driver which i have submited as in previous
patchset. The actualy implementation is in cff.c, as i try to explain
cff.c drivers are mainly to handle all activities of loading rbf from
flashes 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 .
> Or the FPGA manager driver .
> 
This integrity checking is implemented during RBF loading from flash to
SDRAM before calling the functions from fpga driver to program FPGA. So
cff.c which is designed for handling these operation and it should
be appropriate place for checksum.
> > 
> > > 
> > > > 
> > > > 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.
> By common code I mean the stuff around FPGA LOADFS , so other FPGAs
> can
> also benefit from that.
> 
But the raw flash to FPGA implementation is designed fully tied to
common codes in cff.c. FPGA loadfs would be acted like a wrapper to it,
so i am not sure it can be shared by other 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.
> And why don't you rather apply some FPGA LOADFS if this property is
> detected in the DT instead of reimplementing it ?
> 
We need to program the FPGA IO ring buffer from very early phase in SPL
before SDRAM can be initialized. So we need the peripheral rbf file
name from DTS, which is defined by user in our BSP tool. I don't think
FPGA loadfs would be available in SPL by that time. So, i think FPGA
loadfs is suitable for reprogramming FPGA in U-boot console, and
filename is passed as parameter to fpga loadfs command.
> > 
> > > 
> > > > 
> > > > 
> > > > > 
> > > > > 
> > > > >  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. 
> > > 

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

[Marek Vasut]

On 08/12/2017 10:03 AM, Chee, Tien Fong wrote:
[...]
>>> 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.

This looks more like caches are not enabled ... sort of problem ?

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

You can use $filesize instead of reimplementing this functionality
yourself though ?

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

If the code needs to extract some information from the RBF to correctly
configure something in the FPGA manager, then that's where this should
go then.

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

Or the FPGA manager driver .

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

By common code I mean the stuff around FPGA LOADFS , so other FPGAs can
also benefit from that.

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

And why don't you rather apply some FPGA LOADFS if this property is
detected in the DT instead of reimplementing 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.

Does that mean the Arria10 is still not even capable of booting into
U-Boot console ?

cff.c is unlikely to hit mainline unless there's compelling argument
that it is needed . Thus far, I see most of the functionality should be
added elsewhere or is already there (fpga loadfs).

-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [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.
> > 
> > > 
> > > [...]
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [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
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

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

[Chee, Tien Fong]

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:
1: It having ability to the right memory(OCRAM or SDRAM) to achieve the
best FPGA programing performance.
2: It can determine the right size buffer for the fpga rbf without info
of buffer size defined by user.
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 .
4: It supports the checksum.
5: support raw flash without fs.
6: support the file name defined in DTS and U-boot environment
variable.
>  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. 

> [...]
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

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

[Marek Vasut]

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 ?

> 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 ? Also, the ifdeffery is awful and the explicit
depedence on VFAT when loading from FS is real bad.

[...]
-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

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

[Chee, Tien Fong]

On Sel, 2017-08-08 at 12:11 +0200, Marek Vasut wrote:
> On 08/08/2017 12:06 PM, Chee, Tien Fong wrote:
> > 
> > On Sel, 2017-08-08 at 11:32 +0200, Marek Vasut wrote:
> > > 
> > > On 08/08/2017 11:12 AM, tien.fong.c...@intel.com wrote:
> > > > 
> > > > 
> > > > From: Tien Fong Chee 
> > > > 
> > > > Configuration flip-flop driver is mainly used for handling the
> > > > FPGA
> > > > program
> > > > operation where the FPGA image loading from the flash into FPGA
> > > > manager.
> > > I don't understand what this driver is for , sorry.
> > > 
> > this is core driver for handling fpga program operation from flash
> > to
> > fpga manager. I can improve the message. Let me know if you have
> > other
> > comment need to add.
> Yes, it's not clear what this driver is for. It dabbles into multiple
> subsystems , but I don't understand how is this useful.
> 
> > 
> > > 
> > > Coding style issues are present (camel case, wrong comment style,
> > > use
> > > checkpatch).
> > > 
> > Okay, i will run checkpatch.
> You should always run checkpatch before submitting patches.
> 
> > 
> > > 
> > > 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. 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 required
by fpga loadfs command.
> > 
> > Thanks.
> > > 
> > > > 
> > > > 
> > > > Signed-off-by: Tien Fong Chee 
> > > > ---
> > > >  arch/arm/mach-socfpga/cff.c  | 582
> > > > +++
> > > >  arch/arm/mach-socfpga/include/mach/cff.h |  40 +++
> > > >  include/configs/socfpga_arria10_socdk.h  |   6 +
> > > >  3 files changed, 628 insertions(+)
> > > >  create mode 100644 arch/arm/mach-socfpga/cff.c
> > > >  create mode 100644 arch/arm/mach-socfpga/include/mach/cff.h
> > > > 
> > > > diff --git a/arch/arm/mach-socfpga/cff.c b/arch/arm/mach-
> > > > socfpga/cff.c
> > > > new file mode 100644
> > > > index 000..ccee5e9
> > > > --- /dev/null
> > > > +++ b/arch/arm/mach-socfpga/cff.c
> > > > @@ -0,0 +1,582 @@
> > > > +/*
> > > > + * COPYRIGHT (C) 2017 Intel Corporation 
> > > > + *
> > > > + * SPDX-License-Identifier:GPL-2.0
> > > > + */
> > > > +
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +
> > > > +#define RBF_UNENCRYPTED 0xa65c
> > > > +#define RBF_ENCRYPTED 0xa65d
> > > > +#define ARRIA10RBF_PERIPH 0x0001
> > > > +#define ARRIA10RBF_CORE 0x8001
> > > > +
> > > > +DECLARE_GLOBAL_DATA_PTR;
> > > > +
> > > > +static int flash_type = -1;
> > > > +
> > > > +struct mmc *mmc;
> > > > +
> > > > +/* Local functions */
> > > > +static int cff_flash_read(struct cff_flash_info
> > > > *cff_flashinfo,
> > > > u32 *buffer,
> > > > +   u32 *buffer_sizebytes);
> > > > +static int cff_flash_preinit(struct cff_flash_info
> > > > *cff_flashinfo,
> > > > +   fpga_fs_info *fpga_fsinfo, u32 *buffer, u32
> > > > *buffer_sizebytes);
> > > > +#ifdef CONFIG_CMD_FPGA_LOADFS
> > > > +static const char *get_cff_filename(const void *fdt, int *len,
> > > > u32
> > > > core);
> > > > +#else
> > > > +static int get_cff_offset(const void *fdt, u32 core);
> > > > +#endif
> > > > +
> > > > +static struct mmc *init_mmc_device(int dev, bool force_init)
> > > > +{
> > > > +   struct mmc *mmc;
> > > > +
> > > > +   mmc = find_mmc_device(dev);
> > > > +   if (!mmc) {
> > > > +   printf("no mmc device at slot %x\n", dev);
> > > > +   return NULL;
> > > > +   }
> > > > +
> > > > +   if (force_init)
> > > > +   mmc->has_init = 0;
> > > > +   if (mmc_init(mmc))
> > > > +   return NULL;
> > > > +
> > > > +   return mmc;
> > > > +}
> > > > +
> > > > +static int cff_flash_probe(struct cff_flash_info
> > > > *cff_flashinfo)
> > > > +{
> > > > +   int dev = 0;
> > > > +
> > > > +   if(BOOT_DEVICE_MMC1 

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

[Marek Vasut]

On 08/08/2017 12:06 PM, Chee, Tien Fong wrote:
> On Sel, 2017-08-08 at 11:32 +0200, Marek Vasut wrote:
>> On 08/08/2017 11:12 AM, tien.fong.c...@intel.com wrote:
>>>
>>> From: Tien Fong Chee 
>>>
>>> Configuration flip-flop driver is mainly used for handling the FPGA
>>> program
>>> operation where the FPGA image loading from the flash into FPGA
>>> manager.
>> I don't understand what this driver is for , sorry.
>>
> this is core driver for handling fpga program operation from flash to
> fpga manager. I can improve the message. Let me know if you have other
> comment need to add.

Yes, it's not clear what this driver is for. It dabbles into multiple
subsystems , but I don't understand how is this useful.

>> Coding style issues are present (camel case, wrong comment style, use
>> checkpatch).
>>
> Okay, i will run checkpatch.

You should always run checkpatch before submitting patches.

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

> Thanks.
>>>
>>> Signed-off-by: Tien Fong Chee 
>>> ---
>>>  arch/arm/mach-socfpga/cff.c  | 582
>>> +++
>>>  arch/arm/mach-socfpga/include/mach/cff.h |  40 +++
>>>  include/configs/socfpga_arria10_socdk.h  |   6 +
>>>  3 files changed, 628 insertions(+)
>>>  create mode 100644 arch/arm/mach-socfpga/cff.c
>>>  create mode 100644 arch/arm/mach-socfpga/include/mach/cff.h
>>>
>>> diff --git a/arch/arm/mach-socfpga/cff.c b/arch/arm/mach-
>>> socfpga/cff.c
>>> new file mode 100644
>>> index 000..ccee5e9
>>> --- /dev/null
>>> +++ b/arch/arm/mach-socfpga/cff.c
>>> @@ -0,0 +1,582 @@
>>> +/*
>>> + * COPYRIGHT (C) 2017 Intel Corporation 
>>> + *
>>> + * SPDX-License-Identifier:GPL-2.0
>>> + */
>>> +
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +
>>> +#define RBF_UNENCRYPTED 0xa65c
>>> +#define RBF_ENCRYPTED 0xa65d
>>> +#define ARRIA10RBF_PERIPH 0x0001
>>> +#define ARRIA10RBF_CORE 0x8001
>>> +
>>> +DECLARE_GLOBAL_DATA_PTR;
>>> +
>>> +static int flash_type = -1;
>>> +
>>> +struct mmc *mmc;
>>> +
>>> +/* Local functions */
>>> +static int cff_flash_read(struct cff_flash_info *cff_flashinfo,
>>> u32 *buffer,
>>> +   u32 *buffer_sizebytes);
>>> +static int cff_flash_preinit(struct cff_flash_info *cff_flashinfo,
>>> +   fpga_fs_info *fpga_fsinfo, u32 *buffer, u32
>>> *buffer_sizebytes);
>>> +#ifdef CONFIG_CMD_FPGA_LOADFS
>>> +static const char *get_cff_filename(const void *fdt, int *len, u32
>>> core);
>>> +#else
>>> +static int get_cff_offset(const void *fdt, u32 core);
>>> +#endif
>>> +
>>> +static struct mmc *init_mmc_device(int dev, bool force_init)
>>> +{
>>> +   struct mmc *mmc;
>>> +
>>> +   mmc = find_mmc_device(dev);
>>> +   if (!mmc) {
>>> +   printf("no mmc device at slot %x\n", dev);
>>> +   return NULL;
>>> +   }
>>> +
>>> +   if (force_init)
>>> +   mmc->has_init = 0;
>>> +   if (mmc_init(mmc))
>>> +   return NULL;
>>> +
>>> +   return mmc;
>>> +}
>>> +
>>> +static int cff_flash_probe(struct cff_flash_info *cff_flashinfo)
>>> +{
>>> +   int dev = 0;
>>> +
>>> +   if(BOOT_DEVICE_MMC1 == flash_type)
>>> +   {
>>> +   mmc = init_mmc_device(dev, true);
>>> +
>>> +   if (!mmc)
>>> +   return -ENOTBLK;
>>> +
>>> +#ifdef CONFIG_CMD_FPGA_LOADFS
>>> +   /* we are looking at the FAT partition */
>>> +   if (fat_register_device(mmc_get_blk_desc(mmc),
>>> +   cff_flashinfo->sdmmc_flashinfo.dev_part))
>>> {
>>> +   printf("Failed to set filesystem to
>>> FAT.\n");
>>> +   return -EPERM;
>>> +   }
>>> +#endif
>>> +   }
>>> +
>>> +   return flash_type;
>>> +}
>>> +
>>> +static int flash_read(struct cff_flash_info *cff_flashinfo,
>>> +   u32 size_read,
>>> +   u32 *buffer_ptr)
>>> +{
>>> +   size_t ret = EEXIST;
>>> +#ifdef CONFIG_CMD_FPGA_LOADFS
>>> +   loff_t actread;
>>> +#endif
>>> +
>>> +   if(BOOT_DEVICE_MMC1 == flash_type) {
>>> +#ifdef CONFIG_CMD_FPGA_LOADFS
>>> +   ret = fat_read_file(cff_flashinfo-
 sdmmc_flashinfo.filename,
>>> +   buffer_ptr, cff_flashinfo-
 flash_offset,
>>> +size_read, );
>>> +
>>> +   if (ret || actread != size_read) {
>>> +   printf("Failed to read %s from FAT %d ",
>>> +   cff_flashinfo-
 sdmmc_flashinfo.filename,
>>> +ret);
>>> +   printf("!= %d.\n", size_read);
>>> + 

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

[Chee, Tien Fong]

On Sel, 2017-08-08 at 11:32 +0200, Marek Vasut wrote:
> On 08/08/2017 11:12 AM, tien.fong.c...@intel.com wrote:
> > 
> > From: Tien Fong Chee 
> > 
> > Configuration flip-flop driver is mainly used for handling the FPGA
> > program
> > operation where the FPGA image loading from the flash into FPGA
> > manager.
> I don't understand what this driver is for , sorry.
> 
this is core driver for handling fpga program operation from flash to
fpga manager. I can improve the message. Let me know if you have other
comment need to add.

> Coding style issues are present (camel case, wrong comment style, use
> checkpatch).
> 
Okay, i will run checkpatch.

> 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?

Thanks.
> > 
> > Signed-off-by: Tien Fong Chee 
> > ---
> >  arch/arm/mach-socfpga/cff.c  | 582
> > +++
> >  arch/arm/mach-socfpga/include/mach/cff.h |  40 +++
> >  include/configs/socfpga_arria10_socdk.h  |   6 +
> >  3 files changed, 628 insertions(+)
> >  create mode 100644 arch/arm/mach-socfpga/cff.c
> >  create mode 100644 arch/arm/mach-socfpga/include/mach/cff.h
> > 
> > diff --git a/arch/arm/mach-socfpga/cff.c b/arch/arm/mach-
> > socfpga/cff.c
> > new file mode 100644
> > index 000..ccee5e9
> > --- /dev/null
> > +++ b/arch/arm/mach-socfpga/cff.c
> > @@ -0,0 +1,582 @@
> > +/*
> > + * COPYRIGHT (C) 2017 Intel Corporation 
> > + *
> > + * SPDX-License-Identifier:GPL-2.0
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#define RBF_UNENCRYPTED 0xa65c
> > +#define RBF_ENCRYPTED 0xa65d
> > +#define ARRIA10RBF_PERIPH 0x0001
> > +#define ARRIA10RBF_CORE 0x8001
> > +
> > +DECLARE_GLOBAL_DATA_PTR;
> > +
> > +static int flash_type = -1;
> > +
> > +struct mmc *mmc;
> > +
> > +/* Local functions */
> > +static int cff_flash_read(struct cff_flash_info *cff_flashinfo,
> > u32 *buffer,
> > +   u32 *buffer_sizebytes);
> > +static int cff_flash_preinit(struct cff_flash_info *cff_flashinfo,
> > +   fpga_fs_info *fpga_fsinfo, u32 *buffer, u32
> > *buffer_sizebytes);
> > +#ifdef CONFIG_CMD_FPGA_LOADFS
> > +static const char *get_cff_filename(const void *fdt, int *len, u32
> > core);
> > +#else
> > +static int get_cff_offset(const void *fdt, u32 core);
> > +#endif
> > +
> > +static struct mmc *init_mmc_device(int dev, bool force_init)
> > +{
> > +   struct mmc *mmc;
> > +
> > +   mmc = find_mmc_device(dev);
> > +   if (!mmc) {
> > +   printf("no mmc device at slot %x\n", dev);
> > +   return NULL;
> > +   }
> > +
> > +   if (force_init)
> > +   mmc->has_init = 0;
> > +   if (mmc_init(mmc))
> > +   return NULL;
> > +
> > +   return mmc;
> > +}
> > +
> > +static int cff_flash_probe(struct cff_flash_info *cff_flashinfo)
> > +{
> > +   int dev = 0;
> > +
> > +   if(BOOT_DEVICE_MMC1 == flash_type)
> > +   {
> > +   mmc = init_mmc_device(dev, true);
> > +
> > +   if (!mmc)
> > +   return -ENOTBLK;
> > +
> > +#ifdef CONFIG_CMD_FPGA_LOADFS
> > +   /* we are looking at the FAT partition */
> > +   if (fat_register_device(mmc_get_blk_desc(mmc),
> > +   cff_flashinfo->sdmmc_flashinfo.dev_part))
> > {
> > +   printf("Failed to set filesystem to
> > FAT.\n");
> > +   return -EPERM;
> > +   }
> > +#endif
> > +   }
> > +
> > +   return flash_type;
> > +}
> > +
> > +static int flash_read(struct cff_flash_info *cff_flashinfo,
> > +   u32 size_read,
> > +   u32 *buffer_ptr)
> > +{
> > +   size_t ret = EEXIST;
> > +#ifdef CONFIG_CMD_FPGA_LOADFS
> > +   loff_t actread;
> > +#endif
> > +
> > +   if(BOOT_DEVICE_MMC1 == flash_type) {
> > +#ifdef CONFIG_CMD_FPGA_LOADFS
> > +   ret = fat_read_file(cff_flashinfo-
> > >sdmmc_flashinfo.filename,
> > +   buffer_ptr, cff_flashinfo-
> > >flash_offset,
> > +    size_read, );
> > +
> > +   if (ret || actread != size_read) {
> > +   printf("Failed to read %s from FAT %d ",
> > +   cff_flashinfo-
> > >sdmmc_flashinfo.filename,
> > +    ret);
> > +   printf("!= %d.\n", size_read);
> > +   return -EPERM;
> > +   } else
> > +   ret = actread;
> > +#else
> > +   u32 blk = cff_flashinfo->flash_offset/mmc-
> > >read_bl_len;
> > +   u32 cnt = size_read / mmc->read_bl_len;
> > +
> > +   if (!cnt)
> > +   cnt = 1;
> > +
> > +   if((size_read % mmc->read_bl_len) &&
> > +  

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

[Marek Vasut]

On 08/08/2017 11:12 AM, tien.fong.c...@intel.com wrote:
> From: Tien Fong Chee 
> 
> Configuration flip-flop driver is mainly used for handling the FPGA program
> operation where the FPGA image loading from the flash into FPGA manager.

I don't understand what this driver is for , sorry.

Coding style issues are present (camel case, wrong comment style, use
checkpatch).

If this is for some FPGA loading, can this functionality be scripted
instead?

> Signed-off-by: Tien Fong Chee 
> ---
>  arch/arm/mach-socfpga/cff.c  | 582 
> +++
>  arch/arm/mach-socfpga/include/mach/cff.h |  40 +++
>  include/configs/socfpga_arria10_socdk.h  |   6 +
>  3 files changed, 628 insertions(+)
>  create mode 100644 arch/arm/mach-socfpga/cff.c
>  create mode 100644 arch/arm/mach-socfpga/include/mach/cff.h
> 
> diff --git a/arch/arm/mach-socfpga/cff.c b/arch/arm/mach-socfpga/cff.c
> new file mode 100644
> index 000..ccee5e9
> --- /dev/null
> +++ b/arch/arm/mach-socfpga/cff.c
> @@ -0,0 +1,582 @@
> +/*
> + * COPYRIGHT (C) 2017 Intel Corporation 
> + *
> + * SPDX-License-Identifier:GPL-2.0
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define RBF_UNENCRYPTED 0xa65c
> +#define RBF_ENCRYPTED 0xa65d
> +#define ARRIA10RBF_PERIPH 0x0001
> +#define ARRIA10RBF_CORE 0x8001
> +
> +DECLARE_GLOBAL_DATA_PTR;
> +
> +static int flash_type = -1;
> +
> +struct mmc *mmc;
> +
> +/* Local functions */
> +static int cff_flash_read(struct cff_flash_info *cff_flashinfo, u32 *buffer,
> + u32 *buffer_sizebytes);
> +static int cff_flash_preinit(struct cff_flash_info *cff_flashinfo,
> + fpga_fs_info *fpga_fsinfo, u32 *buffer, u32 *buffer_sizebytes);
> +#ifdef CONFIG_CMD_FPGA_LOADFS
> +static const char *get_cff_filename(const void *fdt, int *len, u32 core);
> +#else
> +static int get_cff_offset(const void *fdt, u32 core);
> +#endif
> +
> +static struct mmc *init_mmc_device(int dev, bool force_init)
> +{
> + struct mmc *mmc;
> +
> + mmc = find_mmc_device(dev);
> + if (!mmc) {
> + printf("no mmc device at slot %x\n", dev);
> + return NULL;
> + }
> +
> + if (force_init)
> + mmc->has_init = 0;
> + if (mmc_init(mmc))
> + return NULL;
> +
> + return mmc;
> +}
> +
> +static int cff_flash_probe(struct cff_flash_info *cff_flashinfo)
> +{
> + int dev = 0;
> +
> + if(BOOT_DEVICE_MMC1 == flash_type)
> + {
> + mmc = init_mmc_device(dev, true);
> +
> + if (!mmc)
> + return -ENOTBLK;
> +
> +#ifdef CONFIG_CMD_FPGA_LOADFS
> + /* we are looking at the FAT partition */
> + if (fat_register_device(mmc_get_blk_desc(mmc),
> + cff_flashinfo->sdmmc_flashinfo.dev_part)) {
> + printf("Failed to set filesystem to FAT.\n");
> + return -EPERM;
> + }
> +#endif
> + }
> +
> + return flash_type;
> +}
> +
> +static int flash_read(struct cff_flash_info *cff_flashinfo,
> + u32 size_read,
> + u32 *buffer_ptr)
> +{
> + size_t ret = EEXIST;
> +#ifdef CONFIG_CMD_FPGA_LOADFS
> + loff_t actread;
> +#endif
> +
> + if(BOOT_DEVICE_MMC1 == flash_type) {
> +#ifdef CONFIG_CMD_FPGA_LOADFS
> + ret = fat_read_file(cff_flashinfo->sdmmc_flashinfo.filename,
> + buffer_ptr, cff_flashinfo->flash_offset,
> +  size_read, );
> +
> + if (ret || actread != size_read) {
> + printf("Failed to read %s from FAT %d ",
> + cff_flashinfo->sdmmc_flashinfo.filename,
> +  ret);
> + printf("!= %d.\n", size_read);
> + return -EPERM;
> + } else
> + ret = actread;
> +#else
> + u32 blk = cff_flashinfo->flash_offset/mmc->read_bl_len;
> + u32 cnt = size_read / mmc->read_bl_len;
> +
> + if (!cnt)
> + cnt = 1;
> +
> + if((size_read % mmc->read_bl_len) &&
> + (size_read >= mmc->read_bl_len))
> + cnt++;
> +
> + ret = blk_dread(mmc_get_blk_desc(mmc), blk, cnt,
> +  buffer_ptr);
> +
> + if (cnt != ret)
> + return -EPERM;
> +#endif
> + }
> +
> + return ret;
> +}
> +
> +#ifdef CONFIG_CMD_FPGA_LOADFS
> +const char *get_cff_filename(const void *fdt, int *len, u32 core)
> +{
> + const char *cff_filename = NULL;
> + const char *cell;
> + int nodeoffset;
> + nodeoffset = fdt_subnode_offset(fdt, 0, "chosen");
> +
> + if (nodeoffset >= 0) {
> + if (core)

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

[tien . fong . chee]

From: Tien Fong Chee 

Configuration flip-flop driver is mainly used for handling the FPGA program
operation where the FPGA image loading from the flash into FPGA manager.

Signed-off-by: Tien Fong Chee 
---
 arch/arm/mach-socfpga/cff.c  | 582 +++
 arch/arm/mach-socfpga/include/mach/cff.h |  40 +++
 include/configs/socfpga_arria10_socdk.h  |   6 +
 3 files changed, 628 insertions(+)
 create mode 100644 arch/arm/mach-socfpga/cff.c
 create mode 100644 arch/arm/mach-socfpga/include/mach/cff.h

diff --git a/arch/arm/mach-socfpga/cff.c b/arch/arm/mach-socfpga/cff.c
new file mode 100644
index 000..ccee5e9
--- /dev/null
+++ b/arch/arm/mach-socfpga/cff.c
@@ -0,0 +1,582 @@
+/*
+ * COPYRIGHT (C) 2017 Intel Corporation 
+ *
+ * SPDX-License-Identifier:GPL-2.0
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define RBF_UNENCRYPTED 0xa65c
+#define RBF_ENCRYPTED 0xa65d
+#define ARRIA10RBF_PERIPH 0x0001
+#define ARRIA10RBF_CORE 0x8001
+
+DECLARE_GLOBAL_DATA_PTR;
+
+static int flash_type = -1;
+
+struct mmc *mmc;
+
+/* Local functions */
+static int cff_flash_read(struct cff_flash_info *cff_flashinfo, u32 *buffer,
+   u32 *buffer_sizebytes);
+static int cff_flash_preinit(struct cff_flash_info *cff_flashinfo,
+   fpga_fs_info *fpga_fsinfo, u32 *buffer, u32 *buffer_sizebytes);
+#ifdef CONFIG_CMD_FPGA_LOADFS
+static const char *get_cff_filename(const void *fdt, int *len, u32 core);
+#else
+static int get_cff_offset(const void *fdt, u32 core);
+#endif
+
+static struct mmc *init_mmc_device(int dev, bool force_init)
+{
+   struct mmc *mmc;
+
+   mmc = find_mmc_device(dev);
+   if (!mmc) {
+   printf("no mmc device at slot %x\n", dev);
+   return NULL;
+   }
+
+   if (force_init)
+   mmc->has_init = 0;
+   if (mmc_init(mmc))
+   return NULL;
+
+   return mmc;
+}
+
+static int cff_flash_probe(struct cff_flash_info *cff_flashinfo)
+{
+   int dev = 0;
+
+   if(BOOT_DEVICE_MMC1 == flash_type)
+   {
+   mmc = init_mmc_device(dev, true);
+
+   if (!mmc)
+   return -ENOTBLK;
+
+#ifdef CONFIG_CMD_FPGA_LOADFS
+   /* we are looking at the FAT partition */
+   if (fat_register_device(mmc_get_blk_desc(mmc),
+   cff_flashinfo->sdmmc_flashinfo.dev_part)) {
+   printf("Failed to set filesystem to FAT.\n");
+   return -EPERM;
+   }
+#endif
+   }
+
+   return flash_type;
+}
+
+static int flash_read(struct cff_flash_info *cff_flashinfo,
+   u32 size_read,
+   u32 *buffer_ptr)
+{
+   size_t ret = EEXIST;
+#ifdef CONFIG_CMD_FPGA_LOADFS
+   loff_t actread;
+#endif
+
+   if(BOOT_DEVICE_MMC1 == flash_type) {
+#ifdef CONFIG_CMD_FPGA_LOADFS
+   ret = fat_read_file(cff_flashinfo->sdmmc_flashinfo.filename,
+   buffer_ptr, cff_flashinfo->flash_offset,
+size_read, );
+
+   if (ret || actread != size_read) {
+   printf("Failed to read %s from FAT %d ",
+   cff_flashinfo->sdmmc_flashinfo.filename,
+ret);
+   printf("!= %d.\n", size_read);
+   return -EPERM;
+   } else
+   ret = actread;
+#else
+   u32 blk = cff_flashinfo->flash_offset/mmc->read_bl_len;
+   u32 cnt = size_read / mmc->read_bl_len;
+
+   if (!cnt)
+   cnt = 1;
+
+   if((size_read % mmc->read_bl_len) &&
+   (size_read >= mmc->read_bl_len))
+   cnt++;
+
+   ret = blk_dread(mmc_get_blk_desc(mmc), blk, cnt,
+buffer_ptr);
+
+   if (cnt != ret)
+   return -EPERM;
+#endif
+   }
+
+   return ret;
+}
+
+#ifdef CONFIG_CMD_FPGA_LOADFS
+const char *get_cff_filename(const void *fdt, int *len, u32 core)
+{
+   const char *cff_filename = NULL;
+   const char *cell;
+   int nodeoffset;
+   nodeoffset = fdt_subnode_offset(fdt, 0, "chosen");
+
+   if (nodeoffset >= 0) {
+   if (core)
+   cell = fdt_getprop(fdt,
+   nodeoffset,
+   "cffcore-file",
+   len);
+   else
+   cell = fdt_getprop(fdt, nodeoffset, "cff-file", len);
+
+   if (cell)
+   cff_filename = cell;
+   }
+
+   return cff_filename;
+}
+#else
+static int get_cff_offset(const void *fdt, u32