[U-Boot] [PATCH 03/19] arm: socfpga: Add driver for flash to program FPGA

Marek Vasut marex at denx.de
Mon Sep 4 09:39:46 UTC 2017


On 09/04/2017 09:08 AM, Chee, Tien Fong wrote:
> On Rab, 2017-08-30 at 10:52 +0200, Marek Vasut wrote:
>> On 08/30/2017 10:05 AM, Chee, Tien Fong wrote:
>>>
>>> On Sel, 2017-08-29 at 13:55 +0200, Marek Vasut wrote:
>>>>
>>>> On 08/29/2017 12:45 PM, tien.fong.chee at intel.com wrote:
>>>>>
>>>>>
>>>>> From: Tien Fong Chee <tien.fong.chee at intel.com>
>>>>>
>>>>> This driver handles FPGA program operation from flash loading
>>>>> RBF to memory and then to program FPGA.
>>>>>
>>>>> Signed-off-by: Tien Fong Chee <tien.fong.chee at intel.com>
>>>>> ---
>>>>>  .../include/mach/fpga_manager_arria10.h            |   27 ++
>>>>>  drivers/fpga/socfpga_arria10.c                     |  386
>>>>> +++++++++++++++++++-
>>>>>  include/altera.h                                   |    6 +
>>>>>  include/configs/socfpga_common.h                   |    4 +
>>>>>  4 files changed, 422 insertions(+), 1 deletions(-)
>>>>>
>>>>> diff --git a/arch/arm/mach-
>>>>> socfpga/include/mach/fpga_manager_arria10.h b/arch/arm/mach-
>>>>> socfpga/include/mach/fpga_manager_arria10.h
>>>>> index 9cbf696..93a9122 100644
>>>>> --- a/arch/arm/mach-socfpga/include/mach/fpga_manager_arria10.h
>>>>> +++ b/arch/arm/mach-socfpga/include/mach/fpga_manager_arria10.h
>>>>> @@ -8,6 +8,8 @@
>>>>>  #ifndef _FPGA_MANAGER_ARRIA10_H_
>>>>>  #define _FPGA_MANAGER_ARRIA10_H_
>>>>>  
>>>>> +#include <asm/cache.h>
>>>>> +
>>>>>  #define ALT_FPGAMGR_IMGCFG_STAT_F2S_CRC_ERROR_SET_MSK		
>>>>> BIT(0)
>>>>>  #define ALT_FPGAMGR_IMGCFG_STAT_F2S_EARLY_USERMODE_SET_MSK	
>>>>> BIT(1)
>>>>>  #define ALT_FPGAMGR_IMGCFG_STAT_F2S_USERMODE_SET_MSK 		
>>>>> BIT(2)
>>>>> @@ -89,11 +91,36 @@ struct socfpga_fpga_manager {
>>>>>  	u32  imgcfg_fifo_status;
>>>>>  };
>>>>>  
>>>>> +#if defined(CONFIG_CMD_FPGA_LOADFS)
>>>>> +enum rbf_type {unknown, periph_section, core_section};
>>>>> +enum rbf_security {invalid, unencrypted, encrypted};
>>>>> +
>>>>> +struct rbf_info {
>>>>> +	enum rbf_type section;
>>>>> +	enum rbf_security security;
>>>>> +};
>>>>> +
>>>>> +struct flash_info {
>>>>> +	char *interface;
>>>>> +	char *dev_part;
>>>>> +	char *filename;
>>>>> +	int fstype;
>>>>> +	u32 remaining;
>>>>> +	u32 flash_offset;
>>>>> +	struct rbf_info rbfinfo;
>>>>> +	struct image_header header;
>>>>> +};
>>>>> +#endif
>>>>> +
>>>>>  /* Functions */
>>>>>  int fpgamgr_program_init(u32 * rbf_data, size_t rbf_size);
>>>>>  int fpgamgr_program_finish(void);
>>>>>  int is_fpgamgr_user_mode(void);
>>>>>  int fpgamgr_wait_early_user_mode(void);
>>>>> +#if defined(CONFIG_CMD_FPGA_LOADFS)
>>>>> +const char *get_cff_filename(const void *fdt, int *len, u32
>>>>> core);
>>>>> +const char *get_cff_devpart(const void *fdt, int *len);
>>>>> +#endif
>>>>>  
>>>>>  #endif /* __ASSEMBLY__ */
>>>>>  
>>>>> diff --git a/drivers/fpga/socfpga_arria10.c
>>>>> b/drivers/fpga/socfpga_arria10.c
>>>>> index 5c1a68a..90c55e5 100644
>>>>> --- a/drivers/fpga/socfpga_arria10.c
>>>>> +++ b/drivers/fpga/socfpga_arria10.c
>>>>> @@ -13,6 +13,12 @@
>>>>>  #include <altera.h>
>>>>>  #include <common.h>
>>>>>  #include <errno.h>
>>>>> +#include <fat.h>
>>>>> +#include <fs.h>
>>>>> +#include <fdtdec.h>
>>>>> +#include <malloc.h>
>>>>> +#include <part.h>
>>>>> +#include <spl.h>
>>>>>  #include <wait_bit.h>
>>>>>  #include <watchdog.h>
>>>>>  
>>>>> @@ -22,6 +28,10 @@
>>>>>  #define COMPRESSION_OFFSET	229
>>>>>  #define FPGA_TIMEOUT_MSEC	1000  /* timeout in ms */
>>>>>  #define FPGA_TIMEOUT_CNT	0x1000000
>>>>> +#define RBF_UNENCRYPTED		0xa65c
>>>>> +#define RBF_ENCRYPTED		0xa65d
>>>>> +#define ARRIA10RBF_PERIPH	0x0001
>>>>> +#define ARRIA10RBF_CORE		0x8001
>>>>>  
>>>>>  DECLARE_GLOBAL_DATA_PTR;
>>>>>  
>>>>> @@ -118,7 +128,7 @@ static int
>>>>> wait_for_nconfig_pin_and_nstatus_pin(void)
>>>>>  	return wait_for_bit(__func__,
>>>>>  			    &fpga_manager_base->imgcfg_stat,
>>>>>  			    mask,
>>>>> -			    false, FPGA_TIMEOUT_MSEC, false);
>>>>> +			    true, FPGA_TIMEOUT_MSEC, false);
>>>>>  }
>>>>>  
>>>>>  static int wait_for_f2s_nstatus_pin(unsigned long value)
>>>>> @@ -453,6 +463,281 @@ int fpgamgr_program_finish(void)
>>>>>  	return 0;
>>>>>  }
>>>>>  
>>>>> +#if defined(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);
>>>> This should be a property of the FPGA , not the system . You can
>>>> have
>>>> multiple FPGAs and then this would become a problem.
>>>>
>>> This setting is for the only one FPGA inside our SoCFPGA.
>> You just said it yourself, it is for the only FPGA in your SOCFPGA ,
>> thus it is a property of the FPGA , not a chosen .
>>
> Okay, what i trying to tell is that there is no multiple FPGAs in our
> SOCFPGA. The filename is not any hardware properties, it is just a info
> to tell SPL and U-boot which file to look for programming FPGA.

What would happen if you attached an FPGA over ie. SPI or PCIe ?
Then you have two FPGAs in the system and you need to describe them in
the DT and your "chosen" approach breaks down.

> According to chosen node document, chosen node doesn't represent a real
> HW, but serves as place for passing data. This is why our BSP tool put
> the filename info here, the file is named by user in our tool, and this
> info would be consumed by SPL to program FPGA.
> What do you think?

Your BSP tool is broken.

[...]

>>>> How can a generic FPGA driver depend on random FS functionality ?
>>>> This is broken ...
>>>>
>>> random FS? There would having FAT FS for SDMMC, and UBI FS for QSPI
>>> and
>>> NAND(implement later).
>> Driver should not depend on specific FS.
>>
> I afraid to use fs_read, need to enable more FS features, which would
> take a lot memory, could be run out of it in SPL. Do you think it is
> good to try in SPL?

Don't you have like 256k for the SPL on Gen10 ?

[...]

-- 
Best regards,
Marek Vasut


More information about the U-Boot mailing list