[U-Boot] [PATCH 3/6] ARM: socfpga: Add the configuration for FPGA SoCFPGA A10 SoCDK

Marek Vasut marex at denx.de
Thu Jan 3 20:15:49 UTC 2019


On 1/3/19 6:36 AM, Chee, Tien Fong wrote:
> On Tue, 2019-01-01 at 21:29 +0100, Marek Vasut wrote:
>> On 1/1/19 4:32 AM, Chee, Tien Fong wrote:
>>>
>>> On Sun, 2018-12-30 at 16:47 +0100, Marek Vasut wrote:
>>>>
>>>> On 12/30/18 9:13 AM, tien.fong.chee at intel.com wrote:
>>>>>
>>>>>
>>>>> From: Tien Fong Chee <tien.fong.chee at intel.com>
>>>>>
>>>>> Update the default configuration file to enable the necessary
>>>>> functionality
>>>>> to get the SoCFPGA loadfs driver support. This would enable the
>>>>> implementation of programming bitstream into FPGA from MMC.
>>>>>
>>>>> Signed-off-by: Tien Fong Chee <tien.fong.chee at intel.com>
>>>>> ---
>>>>>  configs/socfpga_arria10_defconfig |    8 ++++++++
>>>>>  1 files changed, 8 insertions(+), 0 deletions(-)
>>>>>
>>>>> diff --git a/configs/socfpga_arria10_defconfig
>>>>> b/configs/socfpga_arria10_defconfig
>>>>> index 6ebda81..8158dbb 100644
>>>>> --- a/configs/socfpga_arria10_defconfig
>>>>> +++ b/configs/socfpga_arria10_defconfig
>>>>> @@ -27,8 +27,16 @@ CONFIG_MTDIDS_DEFAULT="nor0=ff705000.spi.0"
>>>>>  # CONFIG_EFI_PARTITION is not set
>>>>>  CONFIG_DEFAULT_DEVICE_TREE="socfpga_arria10_socdk_sdmmc"
>>>>>  CONFIG_ENV_IS_IN_MMC=y
>>>>> +CONFIG_SPL_ENV_SUPPORT=y
>>>>>  CONFIG_SPL_DM=y
>>>>>  CONFIG_SPL_DM_SEQ_ALIAS=y
>>>>> +CONFIG_SPL_DM_MMC=y
>>>>> +CONFIG_SPL_MMC_SUPPORT=y
>>>>> +CONFIG_SPL_EXT_SUPPORT=y
>>>>> +CONFIG_SPL_FAT_SUPPORT=y
>>>>> +CONFIG_SPL_DRIVERS_MISC_SUPPORT=y
>>>>> +CONFIG_FS_FAT_MAX_CLUSTSIZE=16384
>>>> This breaks systems with large FAT clusters. Why is this needed
>>>> for
>>>> programming the FPGA from MMC ?
>>> This is final tuning in term of getting balance between performance
>>> and
>>> SPL image size for the socdk devkit. User can change that if they
>>> need
>>> large FAT cluster in their design, right?
>> I think it'd rather make sense to fix the FAT driver to avoid
>> statically
>> allocating those massive buffers for big clusters. I think that can
>> be
>> done by allocating those on stack instead ... or mallocating them.
> I need to explore 1st as i'm not familiar with FAT driver. Or can we
> temporary keeping this patch 1st until FAT issue is separately fixed?

Please explore this, it'll be beneficial in the long run.

-- 
Best regards,
Marek Vasut


More information about the U-Boot mailing list