ARM: socfpga: Add minimal support for Arria10

From: Dinh Nguyen <[email protected]>

Add the base address map for Arria10.

Signed-off-by Dinh Nguyen <[email protected]>

---
 .../include/mach/socfpga_a10_base_addrs.h          | 45

Quoted 7 lines · dinguyen at opensource.altera.com

From: Dinh Nguyen <[email protected]>

Add the base address map for Arria10.

Signed-off-by Dinh Nguyen <[email protected]>

---
 .../include/mach/socfpga_a10_base_addrs.h          | 45

Reviewed-by Marek Vasut <[email protected]>

btw. it'd be nice if we could rename the socfpga_base_addrs.h to just plain base_addr_ca5.h

and then call this file
base_addr_a10.h

This might be more systematic, don't you think ?

arch/arm/mach-socfpga/include/mach/system_manager_a10.h new file +31 -0

+/* Weak pull up enable */
+#define WK_PU_DISABLE		(0)
+#define WK_PU_ENABLE		(1)
+
+/* Pull up slew rate control */
+#define PU_SLW_RT_SLOW		(0)
+#define PU_SLW_RT_FAST		(1)
+#define PU_SLW_RT_DEFAULT	PU_SLW_RT_SLOW
+
+/* Pull down slew rate control */
+#define PD_SLW_RT_SLOW		(0)
+#define PD_SLW_RT_FAST		(1)
+#define PD_SLW_RT_DEFAULT	PD_SLW_RT_SLOW
+
+/* Drive strength control */
+#define PU_DRV_STRG_DEFAULT	(0x10)
+#define PD_DRV_STRG_DEFAULT	(0x10)
+
+/* bit position */
+#define PD_DRV_STRG_LSB		(0)
+#define PD_SLW_RT_LSB		(5)
+#define PU_DRV_STRG_LSB		(8)
+#define PU_SLW_RT_LSB		(13)
+#define WK_PU_LSB		(16)
+#define INPUT_BUF_LSB		(17)
+#define BIAS_TRIM_LSB		(19)
+#define VOLTAGE_SEL_LSB		(0)
+
+#define ALT_SYSMGR_NOC_H2F_SET_MSK	0x00000001
+#define ALT_SYSMGR_NOC_LWH2F_SET_MSK	0x00000010
+#define ALT_SYSMGR_NOC_F2H_SET_MSK	0x00000100

+#endif /* _SOCFPGA_SYSTEM_MANAGER_A10_H_ */

From: Dinh Nguyen <[email protected]>

Add the defines for the reset manager and some basic reset functionality.

Signed-off-by Dinh Nguyen <[email protected]>

---
 arch/arm/mach-socfpga/arria10/reset_manager_a10.c  |  83 +++++++++++
 .../mach-socfpga/include/mach/reset_manager_a10.h  | 162
+++++++++++++++++++++ 2 files changed, 245 insertions(+)
 create mode 100644 arch/arm/mach-socfpga/arria10/reset_manager_a10.c
 create mode 100644 arch/arm/mach-socfpga/include/mach/reset_manager_a10.h

(quoted diff) +0 -0

b/arch/arm/mach-socfpga/arria10/reset_manager_a10.c new file mode 100644 index 0000000..e2d315a

arch/arm/mach-socfpga/arria10/reset_manager_a10.c new file +3 -0

@@ -0,0 +1,83 @@
+/*
+ * Copyright (C) 2014 Altera Corporation <www.altera.com>
+ *

arch/arm/mach-socfpga/arria10/reset_manager_a10.c new file +3 -0

+static const struct socfpga_reset_manager *reset_manager_base =
+		(void *)SOCFPGA_RSTMGR_ADDRESS;
+

arch/arm/mach-socfpga/arria10/reset_manager_a10.c new file +17 -0

+#define ALT_RSTMGR_HDSKEN_SDRSELFREFEN_SET_MSK	0x00000001
+#define ALT_RSTMGR_HDSKEN_FPGAMGRHSEN_SET_MSK	0x00000002
+#define ALT_RSTMGR_HDSKEN_FPGAHSEN_SET_MSK	0x00000004
+#define ALT_RSTMGR_HDSKEN_ETRSTALLEN_SET_MSK	0x00000008
+
+/*
+ * Define a reset identifier, from which a permodrst bank ID
+ * and reset ID can be extracted using the subsequent macros
+ * RSTMGR_RESET() and RSTMGR_BANK().
+ */
+#define RSTMGR_BANK_OFFSET	8
+#define RSTMGR_BANK_MASK	0x7
+#define RSTMGR_RESET_OFFSET	0
+#define RSTMGR_RESET_MASK	0x1f
+#define RSTMGR_DEFINE(_bank, _offset)		\
+	((_bank) << RSTMGR_BANK_OFFSET) | ((_offset) << RSTMGR_RESET_OFFSET)
+

+ * 0 ... mpumodrst
+ * 1 ... per0modrst
+ * 2 ... per1modrst
+ * 3 ... brgmodrst
+ * 4 ... sysmodrst
+ */

arch/arm/mach-socfpga/arria10/reset_manager_a10.c new file +22 -0

+#define RSTMGR_EMAC0		RSTMGR_DEFINE(1, 0)
+#define RSTMGR_EMAC1		RSTMGR_DEFINE(1, 1)
+#define RSTMGR_EMAC2		RSTMGR_DEFINE(1, 2)
+#define RSTMGR_WD0		RSTMGR_DEFINE(2, 0)
+#define RSTMGR_WD1		RSTMGR_DEFINE(2, 1)
+#define RSTMGR_L4SYSTIMER0	RSTMGR_DEFINE(2, 2)
+#define RSTMGR_L4SYSTIMER1	RSTMGR_DEFINE(2, 3)
+#define RSTMGR_SPTIMER0		RSTMGR_DEFINE(2, 4)
+#define RSTMGR_SPTIMER1		RSTMGR_DEFINE(2, 5)
+#define RSTMGR_UART0		RSTMGR_DEFINE(2, 16)
+#define RSTMGR_UART1		RSTMGR_DEFINE(2, 17)
+#define RSTMGR_SPIM0		RSTMGR_DEFINE(1, 17)
+#define RSTMGR_SPIM1		RSTMGR_DEFINE(1, 18)
+#define RSTMGR_QSPI		RSTMGR_DEFINE(1, 6)
+#define RSTMGR_SDMMC		RSTMGR_DEFINE(1, 7)
+#define RSTMGR_DMA		RSTMGR_DEFINE(1, 16)
+#define RSTMGR_DDRSCH		RSTMGR_DEFINE(3, 6)
+
+/* Create a human-readable reference to SoCFPGA reset. */
+#define SOCFPGA_RESET(_name)	RSTMGR_##_name
+
+#endif /* _SOCFPGA_RESET_MANAGER_A10_H_ */

Hi!

arch/arm/mach-socfpga/include/mach/sdram_a10.h line 218

Quoted 11 lines

arch/arm/mach-socfpga/include/mach/sdram_a10.h new file +11 -0

+union dramaddrw_reg {
+	struct {
+		u32 cfg_col_addr_width:5;
+		u32 cfg_row_addr_width:5;
+		u32 cfg_bank_addr_width:4;
+		u32 cfg_bank_group_addr_width:2;
+		u32 cfg_cs_addr_width:3;
+		u32 reserved:13;
+	};
+	u32 word;
+};

Umm. Are you sure this is good idea? Is gcc allowed to do something funny and reorder bitfields in unexpected way?

From: Dinh Nguyen <[email protected]>

Add miscellaneous functions(arch_early_init_r, print_cpuinfo, overwrite_console, enable_caches, and cpu_mmc_init). Also, the Arria10 has a firewall protection around the SDRAM and OCRAM. These firewalls are to be disabled in order for U-Boot to function.

Signed-off-by Dinh Nguyen <[email protected]>

---

arch/arm/mach-socfpga/arria10/misc_a10.c new file +7 -0

+/* FPGA programming support for SoC FPGA Arria 10 */
+static Altera_desc altera_fpga[] = {
+	{
+		/* Family */
+		Altera_SoCFPGA,
+		/* Interface type */
+		fast_passive_parallel,

arch/arm/mach-socfpga/arria10/misc_a10.c new file +19 -0

+/* add device descriptor to FPGA device table */
+static void socfpga_fpga_add(void)
+{
+	int i;
+	fpga_init();
+	for (i = 0; i < ARRAY_SIZE(altera_fpga); i++)
+		fpga_add(fpga_altera, &altera_fpga[i]);
+}
+
+void v7_outer_cache_enable(void)
+{
+	/* disable the L2 cache */
+	writel(0, &pl310_regs_base->pl310_ctrl);
+
+	/* enable BRESP, instruction and data prefetch, full line of zeroes */
+	setbits_le32(&pl310_regs_base->pl310_aux_ctrl,
+		     L310_AUX_CTRL_DATA_PREFETCH_MASK |
+		     L310_AUX_CTRL_INST_PREFETCH_MASK);
+}

From: Dinh Nguyen <[email protected]>

Add config for the Arria10 SoC Development Kit.

Signed-off-by Dinh Nguyen <[email protected]>

---
 include/configs/socfpga_arria10_socdk.h | 292
++++++++++++++++++++++++++++++++ 1 file changed, 292 insertions(+)
 create mode 100644 include/configs/socfpga_arria10_socdk.h

include/configs/socfpga_arria10_socdk.h new file +14 -0

+/* SP location before relocation, must use scratch RAM */
+#define CONFIG_SYS_INIT_RAM_ADDR	CONFIG_SYS_TEXT_BASE
+/* Reserving 0x400 space at back of scratch RAM for debug info */
+#define CONFIG_SYS_INIT_RAM_SIZE	(256 * 1024)
+/* Stack pointer at on-chip RAM, leave 16kB behind for page table */
+#define CONFIG_SYS_INIT_SP_ADDR		(CONFIG_SYS_INIT_RAM_ADDR + \
+					 CONFIG_SYS_INIT_RAM_SIZE  - 0x4000)
+/* Default load address */
+#define CONFIG_SYS_LOAD_ADDR		0x8000
+
+/*
+ * Display CPU and Board Info
+ */
+#define CONFIG_DISPLAY_CPUINFO

include/configs/socfpga_arria10_socdk.h new file +4 -0

+/* Initial Memory map size for Linux, minus 4k alignment for DFT blob */
+#define CONFIG_SYS_BOOTMAPSZ		(32 * 1024 * 1024)
+
+/*

include/configs/socfpga_arria10_socdk.h new file +4 -0

+/*
+ * Can't poll in semihosting; so turn off automatic boot command
+ */
+#define CONFIG_BOOTCOMMAND "run callscript; run mmcload;" \

(quoted diff) +2 -0

+#if ((CONFIG_SYS_DTB_ADDR + MAX_DTB_SIZE_IN_RAM) > CONFIG_SYS_LOAD_ADDR)
+#error "MAX_DTB_SIZE_IN_RAM is too big. It will overwrite zImage in

memory." +#endif

include/configs/socfpga_arria10_socdk.h new file +51 -0

+
+#define CONFIG_EXTRA_ENV_SETTINGS \
+	"verify=y\0" \
+	"loadaddr=" __stringify(CONFIG_SYS_LOAD_ADDR) "\0" \
+	"fdtaddr=" __stringify(CONFIG_SYS_DTB_ADDR) "\0" \
+	"bootimage=zImage\0" \
+	"bootimagesize=0x600000\0" \
+	"fdtimage=socfpga_arria10_socdk.dtb\0" \
+	"fdtimagesize=" __stringify(MAX_DTB_SIZE_IN_RAM) "\0" \
+	"fdt_high=0x2000000\0" \
+	"mmcloadcmd=fatload\0" \
+	"mmcloadpart=1\0" \
+	"mmcroot=/dev/mmcblk0p2\0" \
+	"qspiloadcs=0\0" \
+	"qspibootimageaddr=0x120000\0" \
+	"qspifdtaddr=0x100000\0" \
+	"qspiroot=/dev/mtdblock1\0" \
+	"qspirootfstype=jffs2\0" \
+	"mmcload=mmc rescan;" \
+		"${mmcloadcmd} mmc 0:${mmcloadpart} ${loadaddr} ${bootimage};" \
+		"${mmcloadcmd} mmc 0:${mmcloadpart} ${fdtaddr} ${fdtimage}\0" \
+	"mmcboot=setenv bootargs " CONFIG_BOOTARGS \
+		" root=${mmcroot} rw rootwait;" \
+		"fpgabr 1;" \
+		"bootz ${loadaddr} - ${fdtaddr}\0" \
+	"netboot=dhcp ${bootimage} ; " \
+		"tftp ${fdtaddr} ${fdtimage} ; run ramboot\0" \
+	"qspiload=sf probe ${qspiloadcs};" \
+		"sf read ${loadaddr} ${qspibootimageaddr} ${bootimagesize};" \
+		"sf read ${fdtaddr} ${qspifdtaddr} ${fdtimagesize};\0" \
+	"qspiboot=setenv bootargs " CONFIG_BOOTARGS \
+		" root=${qspiroot} rw rootfstype=${qspirootfstype};"\
+		"fpgabr 1;" \
+		"bootz ${loadaddr} - ${fdtaddr}\0" \
+	"nandload=nand read ${loadaddr} ${nandbootimageaddr} ${bootimagesize};"\
+		"nand read ${fdtaddr} ${nandfdtaddr} ${fdtimagesize}\0" \
+	"nandboot=setenv bootargs " CONFIG_BOOTARGS \
+		" root=${nandroot} rw rootfstype=${nandrootfstype};"\
+		"fpgabr 1;" \
+		"bootz ${loadaddr} - ${fdtaddr}\0" \
+	"bootcmd=" CONFIG_BOOTCOMMAND "\0" \
+	"u-boot_swstate_reg=0xffd0620c\0" \
+	"u-boot_image_valid=0x49535756\0" \
+	"fpga=0\0" \
+	"fpgadata=0x2000000\0" \
+	"fpgadatasize=0x700000\0" \
+	"scriptfile=u-boot.scr\0" \
+	"callscript=if fatload mmc 0:1 $fpgadata $scriptfile;" \
+			"then source $fpgadata; " \
+		"else " \
+			"echo Optional boot script not found. " \

include/configs/socfpga_arria10_socdk.h new file +8 -0

+/*
+ * Memory configurations
+ */
+#define CONFIG_NR_DRAM_BANKS		1
+#define CONFIG_SYS_SDRAM_BASE		0x00000000
+#define PHYS_SDRAM_1_SIZE		0x2000000
+#define PHYS_SDRAM_1			CONFIG_SYS_SDRAM_BASE
+#define CONFIG_SYS_MALLOC_LEN		(64 * 1024 * 1024)

include/configs/socfpga_arria10_socdk.h new file +11 -0

+/*
+ * MMC support
+ */
+#ifdef CONFIG_CMD_MMC
+#define CONFIG_MMC
+
+#define CONFIG_ENV_IS_IN_MMC
+#define CONFIG_SYS_MMC_ENV_DEV		0/* device 0 */
+#define CONFIG_ENV_OFFSET		512/* just after the MBR */
+
+#define CONFIG_CMD_FAT

include/configs/socfpga_arria10_socdk.h new file +6 -0

+#define CONFIG_DWMMC
+#define CONFIG_SOCFPGA_DWMMC
+#define CONFIG_SOCFPGA_DWMMC_DRVSEL     3
+#define CONFIG_SOCFPGA_DWMMC_SMPSEL     0
+#define CONFIG_SOCFPGA_DWMMC_FIFO_DEPTH	1024
+/* using smaller max blk cnt to avoid flooding the limited stack we have

*/ +#define CONFIG_SOCFPGA_DWMMC_BUS_HZ CONFIG_HPS_CLK_SDMMC_HZ

include/configs/socfpga_arria10_socdk.h new file +30 -0

+#define CONFIG_SOCFPGA_DWMMC_BUS_WIDTH	4
+/* requird for dw_mmc driver */
+#define CONFIG_BOUNCE_BUFFER
+#else
+#define CONFIG_ENV_IS_NOWHERE
+#endif /* CONFIG_MMC */
+
+/*
+ * NAND
+ */
+#ifdef CONFIG_NAND_DENALI
+#define CONFIG_CMD_NAND
+#define CONFIG_SYS_MAX_NAND_DEVICE	1
+#define CONFIG_SYS_NAND_USE_FLASH_BBT
+#define CONFIG_SYS_NAND_REGS_BASE	0xff200000
+#define CONFIG_SYS_NAND_DATA_BASE	0xff300000
+#define CONFIG_SYS_NAND_BASE		0xff400000
+#define CONFIG_SYS_NAND_ONFI_DETECTION
+/* The ECC size which either 512 or 1024 */
+#define CONFIG_NAND_DENALI_ECC_SIZE			(512)
+#endif /* CONFIG_NAND_DENALI */
+
+/*
+ * FPGA support
+ */
+#define CONFIG_FPGA
+#define CONFIG_FPGA_ALTERA
+#define CONFIG_FPGA_COUNT		1
+#define CONFIG_CMD_FPGA_LOADFS
+#endif	/* __CONFIG_H */

board/altera/arria10-socdk/Makefile new file +4 -0

+# SPDX-License-Identifier:	GPL-2.0+
+#
+
+obj-y	:= socfpga.o

From: Dinh Nguyen <[email protected]>

Update Makefile to build Arria 10.

Signed-off-by Dinh Nguyen <[email protected]>

---
 arch/arm/mach-socfpga/Makefile         | 7 +++++--
 arch/arm/mach-socfpga/arria10/Makefile | 7 +++++++
 2 files changed, 12 insertions(+), 2 deletions(-)
 create mode 100644 arch/arm/mach-socfpga/arria10/Makefile

(quoted diff) +0 -0

b/arch/arm/mach-socfpga/Makefile index 316b326..0dbe9bb 100644

arch/arm/mach-socfpga/Makefile +2 -0

+endif
+
 CFLAGS_wrap_iocsr_config.o	+= -I$(srctree)/board/$(BOARDDIR)
 CFLAGS_wrap_pinmux_config.o	+= -I$(srctree)/board/$(BOARDDIR)
 CFLAGS_wrap_pll_config.o	+= -I$(srctree)/board/$(BOARDDIR)

(quoted diff) +0 -0

b/arch/arm/mach-socfpga/arria10/Makefile new file mode 100644 index 0000000..f5e4b7d

Quoted 16 lines · dinguyen at opensource.altera.com

From: Dinh Nguyen <[email protected]>

Update Makefile to build Arria 10.

Signed-off-by Dinh Nguyen <[email protected]>

---
 arch/arm/mach-socfpga/Makefile         | 7 +++++--
 arch/arm/mach-socfpga/arria10/Makefile | 7 +++++++
 2 files changed, 12 insertions(+), 2 deletions(-)
 create mode 100644 arch/arm/mach-socfpga/arria10/Makefile

(quoted diff) +0 -0

b/arch/arm/mach-socfpga/Makefile index 316b326..0dbe9bb 100644

arch/arm/mach-socfpga/Makefile line 10

Quoted 6 lines

arch/arm/mach-socfpga/Makefile +1 -1

@@ -6,15 +6,18 @@
 #
 # SPDX-License-Identifier:	GPL-2.0+
 #
-
+ifneq ($(CONFIG_TARGET_SOCFPGA_ARRIA10),y)
 obj-y	+= misc.o timer.o reset_manager.o system_manager.o 

clock_manager.o \

arch/arm/mach-socfpga/Makefile line 18

Quoted 9 lines

arch/arm/mach-socfpga/Makefile +2 -1

 	   fpga_manager.o scan_manager.o
 obj-$(CONFIG_SPL_BUILD) += spl.o freeze_controller.o
-
 # QTS-generated config file wrappers
 obj-y	+= wrap_pll_config.o
 obj-$(CONFIG_SPL_BUILD) += wrap_iocsr_config.o wrap_pinmux_config.o	\
 			   wrap_sdram_config.o
+else
+obj-y	+= arria10/

So why exactly does A10 have it's own dedicated dir if most of the code is probably shared between A10 and AV/CV ?

Quoted 43 lines · Marek Vasut

On Thursday, November 19, 2015 at 10:35:47 PM,
dinguyen at opensource.altera.com

Quoted 17 lines · wrote:

From: Dinh Nguyen <[email protected]>

Update Makefile to build Arria 10.

Signed-off-by Dinh Nguyen <[email protected]>

---

 arch/arm/mach-socfpga/Makefile         | 7 +++++--
 arch/arm/mach-socfpga/arria10/Makefile | 7 +++++++
 2 files changed, 12 insertions(+), 2 deletions(-)
 create mode 100644 arch/arm/mach-socfpga/arria10/Makefile

(quoted diff) +0 -0

b/arch/arm/mach-socfpga/Makefile index 316b326..0dbe9bb 100644

arch/arm/mach-socfpga/Makefile line 13

Quoted 9 lines

arch/arm/mach-socfpga/Makefile +1 -1

@@ -6,15 +6,18 @@
 
 #
 # SPDX-License-Identifier:	GPL-2.0+
 #
 
-
+ifneq ($(CONFIG_TARGET_SOCFPGA_ARRIA10),y)
 
 obj-y	+= misc.o timer.o reset_manager.o system_manager.o

clock_manager.o \

Quoted 10 lines

arch/arm/mach-socfpga/Makefile +0 -1

 	   fpga_manager.o scan_manager.o
 
 obj-$(CONFIG_SPL_BUILD) += spl.o freeze_controller.o
 
-
 
 # QTS-generated config file wrappers
 obj-y	+= wrap_pll_config.o
 obj-$(CONFIG_SPL_BUILD) += wrap_iocsr_config.o wrap_pinmux_config.o	\

Quoted 7 lines

arch/arm/mach-socfpga/Makefile line 18

Quoted 4 lines

arch/arm/mach-socfpga/Makefile +2 -0

 			   wrap_sdram_config.o
 
+else
+obj-y	+= arria10/

So why exactly does A10 have it's own dedicated dir if most of the code is probably shared between A10 and AV/CV ?

Yes, there are some sharing. But I think that there will be enough differences that will ultimately warrant it's own directory. I think with it's own directory, the Makefile changes stay a bit cleaner. I

One of the biggest differences is that the A10's SDRAM support is going to be a bit ugly.

The main point is that we need to program the FPGA
during U-Boot booting up with a ~>10 MB rbf file while being limited to the OCRAM's size. I would like to contain this ugliness in it's own directory.

Quoted 52 lines · Dinh Nguyen

Quoted 43 lines · Marek Vasut

On Thursday, November 19, 2015 at 10:35:47 PM,
dinguyen at opensource.altera.com

Quoted 17 lines · wrote:

From: Dinh Nguyen <[email protected]>

Update Makefile to build Arria 10.

Signed-off-by Dinh Nguyen <[email protected]>

---

 arch/arm/mach-socfpga/Makefile         | 7 +++++--
 arch/arm/mach-socfpga/arria10/Makefile | 7 +++++++
 2 files changed, 12 insertions(+), 2 deletions(-)
 create mode 100644 arch/arm/mach-socfpga/arria10/Makefile

(quoted diff) +0 -0

b/arch/arm/mach-socfpga/Makefile index 316b326..0dbe9bb 100644

arch/arm/mach-socfpga/Makefile line 13

Quoted 9 lines

arch/arm/mach-socfpga/Makefile +1 -1

@@ -6,15 +6,18 @@
 
 #
 # SPDX-License-Identifier:	GPL-2.0+
 #
 
-
+ifneq ($(CONFIG_TARGET_SOCFPGA_ARRIA10),y)
 
 obj-y	+= misc.o timer.o reset_manager.o system_manager.o

clock_manager.o \

Quoted 10 lines

arch/arm/mach-socfpga/Makefile +0 -1

 	   fpga_manager.o scan_manager.o
 
 obj-$(CONFIG_SPL_BUILD) += spl.o freeze_controller.o
 
-
 
 # QTS-generated config file wrappers
 obj-y	+= wrap_pll_config.o
 obj-$(CONFIG_SPL_BUILD) += wrap_iocsr_config.o wrap_pinmux_config.o	\

Quoted 7 lines

arch/arm/mach-socfpga/Makefile line 18

Quoted 4 lines

arch/arm/mach-socfpga/Makefile +2 -0

 			   wrap_sdram_config.o
 
+else
+obj-y	+= arria10/

So why exactly does A10 have it's own dedicated dir if most of the code is probably shared between A10 and AV/CV ?

Quoted 3 lines

Yes, there are some sharing. But I think that there will be enough differences that will ultimately warrant it's own directory. I think with it's own directory, the Makefile changes stay a bit cleaner. I

Linux doesn't seem to require a separate directory though, does it ? I'm not convinced we need one either.

Quoted 2 lines

One of the biggest differences is that the A10's SDRAM support is going to be a bit ugly.

The SDRAM code goes into drivers/ddr/ , no problem.

Quoted 4 lines

The main point is that we need to program the FPGA
during U-Boot booting up with a ~>10 MB rbf file while being limited to the OCRAM's size. I would like to contain this ugliness in it's own directory.

What's the problem with this ? We already support loading files from storage in SPL, so just compile the FPGA manager into SPL as well and use it.

Quoted 70 lines · Marek Vasut

Quoted 52 lines · Dinh Nguyen

Quoted 43 lines · Marek Vasut

On Thursday, November 19, 2015 at 10:35:47 PM,
dinguyen at opensource.altera.com

Quoted 17 lines · wrote:

From: Dinh Nguyen <[email protected]>

Update Makefile to build Arria 10.

Signed-off-by Dinh Nguyen <[email protected]>

---

 arch/arm/mach-socfpga/Makefile         | 7 +++++--
 arch/arm/mach-socfpga/arria10/Makefile | 7 +++++++
 2 files changed, 12 insertions(+), 2 deletions(-)
 create mode 100644 arch/arm/mach-socfpga/arria10/Makefile

(quoted diff) +0 -0

b/arch/arm/mach-socfpga/Makefile index 316b326..0dbe9bb 100644

arch/arm/mach-socfpga/Makefile line 13

Quoted 9 lines

arch/arm/mach-socfpga/Makefile +1 -1

@@ -6,15 +6,18 @@
 
 #
 # SPDX-License-Identifier:	GPL-2.0+
 #
 
-
+ifneq ($(CONFIG_TARGET_SOCFPGA_ARRIA10),y)
 
 obj-y	+= misc.o timer.o reset_manager.o system_manager.o

clock_manager.o \

Quoted 10 lines

arch/arm/mach-socfpga/Makefile +0 -1

 	   fpga_manager.o scan_manager.o
 
 obj-$(CONFIG_SPL_BUILD) += spl.o freeze_controller.o
 
-
 
 # QTS-generated config file wrappers
 obj-y	+= wrap_pll_config.o
 obj-$(CONFIG_SPL_BUILD) += wrap_iocsr_config.o wrap_pinmux_config.o	\

Quoted 7 lines

arch/arm/mach-socfpga/Makefile line 18

Quoted 4 lines

arch/arm/mach-socfpga/Makefile +2 -0

 			   wrap_sdram_config.o
 
+else
+obj-y	+= arria10/

So why exactly does A10 have it's own dedicated dir if most of the code is probably shared between A10 and AV/CV ?

Quoted 3 lines

Yes, there are some sharing. But I think that there will be enough differences that will ultimately warrant it's own directory. I think with it's own directory, the Makefile changes stay a bit cleaner. I

Linux doesn't seem to require a separate directory though, does it ? I'm not convinced we need one either.

Quoted 2 lines

One of the biggest differences is that the A10's SDRAM support is going to be a bit ugly.

The SDRAM code goes into drivers/ddr/ , no problem.

Quoted 4 lines

The main point is that we need to program the FPGA
during U-Boot booting up with a ~>10 MB rbf file while being limited to the OCRAM's size. I would like to contain this ugliness in it's own directory.

Quoted 3 lines

What's the problem with this ? We already support loading files from storage in SPL, so just compile the FPGA manager into SPL as well and use it.

Ok, let me re-work it all under the c5/a5 directory. Thanks for reviewing.

Quoted 71 lines · Dinh Nguyen

Quoted 70 lines · Marek Vasut

Quoted 52 lines · Dinh Nguyen

Quoted 43 lines · Marek Vasut

On Thursday, November 19, 2015 at 10:35:47 PM,
dinguyen at opensource.altera.com

Quoted 17 lines · wrote:

From: Dinh Nguyen <[email protected]>

Update Makefile to build Arria 10.

Signed-off-by Dinh Nguyen <[email protected]>

---

 arch/arm/mach-socfpga/Makefile         | 7 +++++--
 arch/arm/mach-socfpga/arria10/Makefile | 7 +++++++
 2 files changed, 12 insertions(+), 2 deletions(-)
 create mode 100644 arch/arm/mach-socfpga/arria10/Makefile

(quoted diff) +0 -0

b/arch/arm/mach-socfpga/Makefile index 316b326..0dbe9bb 100644

arch/arm/mach-socfpga/Makefile line 13

Quoted 9 lines

arch/arm/mach-socfpga/Makefile +1 -1

@@ -6,15 +6,18 @@
 
 #
 # SPDX-License-Identifier:	GPL-2.0+
 #
 
-
+ifneq ($(CONFIG_TARGET_SOCFPGA_ARRIA10),y)
 
 obj-y	+= misc.o timer.o reset_manager.o system_manager.o

clock_manager.o \

Quoted 10 lines

arch/arm/mach-socfpga/Makefile +0 -1

 	   fpga_manager.o scan_manager.o
 
 obj-$(CONFIG_SPL_BUILD) += spl.o freeze_controller.o
 
-
 
 # QTS-generated config file wrappers
 obj-y	+= wrap_pll_config.o
 obj-$(CONFIG_SPL_BUILD) += wrap_iocsr_config.o wrap_pinmux_config.o	\

Quoted 7 lines

arch/arm/mach-socfpga/Makefile line 18

Quoted 4 lines

arch/arm/mach-socfpga/Makefile +2 -0

 			   wrap_sdram_config.o
 
+else
+obj-y	+= arria10/

So why exactly does A10 have it's own dedicated dir if most of the code is probably shared between A10 and AV/CV ?

Quoted 3 lines

Yes, there are some sharing. But I think that there will be enough differences that will ultimately warrant it's own directory. I think with it's own directory, the Makefile changes stay a bit cleaner. I

Linux doesn't seem to require a separate directory though, does it ? I'm not convinced we need one either.

Quoted 2 lines

One of the biggest differences is that the A10's SDRAM support is going to be a bit ugly.

The SDRAM code goes into drivers/ddr/ , no problem.

Quoted 4 lines

The main point is that we need to program the FPGA
during U-Boot booting up with a ~>10 MB rbf file while being limited to the OCRAM's size. I would like to contain this ugliness in it's own directory.

Quoted 5 lines

Quoted 3 lines

What's the problem with this ? We already support loading files from storage in SPL, so just compile the FPGA manager into SPL as well and use it.

Ok, let me re-work it all under the c5/a5 directory. Thanks for reviewing.

But you didn't really answer my question -- what is the problem with the FPGA loader in SPL ?

Quoted 12 lines

Quoted 11 lines

Quoted 8 lines

Quoted 4 lines

The main point is that we need to program the FPGA
during U-Boot booting up with a ~>10 MB rbf file while being limited to the OCRAM's size. I would like to contain this ugliness in it's own directory.

What's the problem with this ? We already support loading files from storage in SPL, so just compile the FPGA manager into SPL as well and use it.

Ok, let me re-work it all under the c5/a5 directory. Thanks for reviewing.

Quoted 2 lines

But you didn't really answer my question -- what is the problem with the FPGA loader in SPL ?

I thought you've already answered your own question. For whatever reason, the downstream A10 is re-doing the FPGA manager just for this purpose.

On Monday, November 23, 2015 at 11:32:27 PM, Dinh Nguyen wrote:
[...]

Quoted 12 lines

Quoted 12 lines

Quoted 11 lines

Quoted 8 lines

Quoted 4 lines

The main point is that we need to program the FPGA
during U-Boot booting up with a ~>10 MB rbf file while being limited to the OCRAM's size. I would like to contain this ugliness in it's own directory.

What's the problem with this ? We already support loading files from storage in SPL, so just compile the FPGA manager into SPL as well and use it.

Ok, let me re-work it all under the c5/a5 directory. Thanks for reviewing.

Quoted 6 lines

Quoted 2 lines

But you didn't really answer my question -- what is the problem with the FPGA loader in SPL ?

I thought you've already answered your own question. For whatever reason, the downstream A10 is re-doing the FPGA manager just for this purpose.

Could the reason be that the FPGA manager in it's current state expects one big buffer with the entire FPGA bitstream ? When you're in SPL and you still don't have DRAM running, you cannot create such buffer anywhere. Thus, what you need to do is to have some sort of code which loads a bit of the bitstream file at time and feeds it into the FPGA manager, piece by piece. This should be doable pretty easily, what do you think ?

Quoted 22 lines · Marek Vasut

On Monday, November 23, 2015 at 11:32:27 PM, Dinh Nguyen wrote:
[...]

Quoted 12 lines

Quoted 12 lines

Quoted 11 lines

Quoted 8 lines

Quoted 4 lines

The main point is that we need to program the FPGA
during U-Boot booting up with a ~>10 MB rbf file while being limited to the OCRAM's size. I would like to contain this ugliness in it's own directory.

What's the problem with this ? We already support loading files from storage in SPL, so just compile the FPGA manager into SPL as well and use it.

Ok, let me re-work it all under the c5/a5 directory. Thanks for reviewing.

Quoted 6 lines

Quoted 2 lines

But you didn't really answer my question -- what is the problem with the FPGA loader in SPL ?

I thought you've already answered your own question. For whatever reason, the downstream A10 is re-doing the FPGA manager just for this purpose.

Quoted 7 lines

Could the reason be that the FPGA manager in it's current state expects one big buffer with the entire FPGA bitstream ? When you're in SPL and you still don't have DRAM running, you cannot create such buffer anywhere. Thus, what you need to do is to have some sort of code which loads a bit of the bitstream file at time and feeds it into the FPGA manager, piece by piece. This should be doable pretty easily, what do you think ?

That's exactly what is being in the mach-socfpga directory.

Yes, but should that code go into mach-socfpga or drivers?

Quoted 31 lines · Dinh Nguyen

Quoted 29 lines · Marek Vasut

On Monday, November 23, 2015 at 11:32:27 PM, Dinh Nguyen wrote:
[...]

Quoted 12 lines

Quoted 12 lines

Quoted 11 lines

Quoted 8 lines

Quoted 4 lines

The main point is that we need to program the FPGA
during U-Boot booting up with a ~>10 MB rbf file while being limited to the OCRAM's size. I would like to contain this ugliness in it's own directory.

What's the problem with this ? We already support loading files from storage in SPL, so just compile the FPGA manager into SPL as well and use it.

Ok, let me re-work it all under the c5/a5 directory. Thanks for reviewing.

Quoted 6 lines

Quoted 2 lines

But you didn't really answer my question -- what is the problem with the FPGA loader in SPL ?

I thought you've already answered your own question. For whatever reason, the downstream A10 is re-doing the FPGA manager just for this purpose.

Could the reason be that the FPGA manager in it's current state expects one big buffer with the entire FPGA bitstream ? When you're in SPL and you still don't have DRAM running, you cannot create such buffer anywhere. Thus, what you need to do is to have some sort of code which loads a bit of the bitstream file at time and feeds it into the FPGA manager, piece by piece. This should be doable pretty easily, what do you think ?

Quoted 1 line

That's exactly what is being in the mach-socfpga directory.

Um, am I missing it in this patchset ?

Quoted 1 line

Yes, but should that code go into mach-socfpga or drivers?

The FPGA manager bits are already in drivers/fpga/ , so that's where the improvements should go. If you need some special handling in the SPL, that should be in mach-socfpga . In case it's too much change to the current SPL, moving the spl.c to spl-gen5.c and creating new spl-gen10.c might make sense ... or something like that, possibly even with some spl-common.c .

Quoted 32 lines · Marek Vasut

Quoted 31 lines · Dinh Nguyen

Quoted 29 lines · Marek Vasut

On Monday, November 23, 2015 at 11:32:27 PM, Dinh Nguyen wrote:
[...]

Quoted 12 lines

Quoted 12 lines

Quoted 11 lines

Quoted 8 lines

Quoted 4 lines

The main point is that we need to program the FPGA during U-Boot booting up with a ~>10 MB rbf file while being limited to the OCRAM's size. I would like to contain this ugliness in it's own directory.

What's the problem with this ? We already support loading files from storage in SPL, so just compile the FPGA manager into SPL as well and use it.

Ok, let me re-work it all under the c5/a5 directory. Thanks for reviewing.

Quoted 6 lines

Quoted 2 lines

But you didn't really answer my question -- what is the problem with the FPGA loader in SPL ?

I thought you've already answered your own question. For whatever reason, the downstream A10 is re-doing the FPGA manager just for this purpose.

Could the reason be that the FPGA manager in it's current state expects one big buffer with the entire FPGA bitstream ? When you're in SPL and you still don't have DRAM running, you cannot create such buffer anywhere. Thus, what you need to do is to have some sort of code which loads a bit of the bitstream file at time and feeds it into the FPGA manager, piece by piece. This should be doable pretty easily, what do you think ?

Quoted 3 lines

Quoted 1 line

That's exactly what is being in the mach-socfpga directory.

Um, am I missing it in this patchset ?

No, you're not missing it, I have not sent it up yet. That support is in the downstream, but also with the fpga-manager driver re-written. I need to clean this up before I can send it.

Quoted 8 lines

Quoted 1 line

Yes, but should that code go into mach-socfpga or drivers?

The FPGA manager bits are already in drivers/fpga/ , so that's where the improvements should go. If you need some special handling in the SPL, that should be in mach-socfpga . In case it's too much change to the current SPL, moving the spl.c to spl-gen5.c and creating new spl-gen10.c might make sense ... or something like that, possibly even with some spl-common.c .

Ok. BTW, Arria10 is not using SPL. It has 256K of OCRAM that U-Boot can use to setup the SDRAM.

Quoted 33 lines · Dinh Nguyen

Quoted 32 lines · Marek Vasut

Quoted 31 lines · Dinh Nguyen

Quoted 29 lines · Marek Vasut

On Monday, November 23, 2015 at 11:32:27 PM, Dinh Nguyen wrote:
[...]

Quoted 12 lines

Quoted 12 lines

Quoted 11 lines

Quoted 8 lines

Quoted 4 lines

The main point is that we need to program the FPGA during U-Boot booting up with a ~>10 MB rbf file while being limited to the OCRAM's size. I would like to contain this ugliness in it's own directory.

What's the problem with this ? We already support loading files from storage in SPL, so just compile the FPGA manager into SPL as well and use it.

Ok, let me re-work it all under the c5/a5 directory. Thanks for reviewing.

Quoted 6 lines

Quoted 2 lines

But you didn't really answer my question -- what is the problem with the FPGA loader in SPL ?

I thought you've already answered your own question. For whatever reason, the downstream A10 is re-doing the FPGA manager just for this purpose.

Could the reason be that the FPGA manager in it's current state expects one big buffer with the entire FPGA bitstream ? When you're in SPL and you still don't have DRAM running, you cannot create such buffer anywhere. Thus, what you need to do is to have some sort of code which loads a bit of the bitstream file at time and feeds it into the FPGA manager, piece by piece. This should be doable pretty easily, what do you think ?

Quoted 7 lines

Quoted 3 lines

Quoted 1 line

That's exactly what is being in the mach-socfpga directory.

Um, am I missing it in this patchset ?

No, you're not missing it, I have not sent it up yet. That support is in the downstream, but also with the fpga-manager driver re-written. I need to clean this up before I can send it.

OK, thanks :)

Quoted 9 lines

Quoted 8 lines

Quoted 1 line

Yes, but should that code go into mach-socfpga or drivers?

The FPGA manager bits are already in drivers/fpga/ , so that's where the improvements should go. If you need some special handling in the SPL, that should be in mach-socfpga . In case it's too much change to the current SPL, moving the spl.c to spl-gen5.c and creating new spl-gen10.c might make sense ... or something like that, possibly even with some spl-common.c .

Quoted 2 lines

Ok. BTW, Arria10 is not using SPL. It has 256K of OCRAM that U-Boot can use to setup the SDRAM.

So what do I do if I want to boot arria10 from NAND ? UBI and UBIFS won't fit into 256kiB, so I think using SPL might be the sensible thing afterall, since you would be able to use arbitrarily-sized U-Boot.

Quoted 80 lines · Marek Vasut

Quoted 51 lines · Dinh Nguyen

Quoted 50 lines · Marek Vasut

Quoted 48 lines · Dinh Nguyen

Quoted 32 lines · Marek Vasut

On Monday, November 23, 2015 at 11:32:27 PM, Dinh Nguyen wrote:
[...]

Quoted 22 lines

Quoted 14 lines

Quoted 14 lines

Quoted 13 lines

Quoted 7 lines

The main point is that we need to program the
FPGA
during U-Boot booting up with a ~>10 MB rbf file
while being
limited to the OCRAM's size. I would like to
contain this
ugliness in it's own directory.

What's the problem with this ? We already support
loading files
from storage in SPL, so just compile the FPGA
manager into SPL as
well and use it.

Quoted 7 lines

Quoted 3 lines

Ok, let me re-work it all under the c5/a5 directory. Thanks for
reviewing.

But you didn't really answer my question -- what is the problem with
the FPGA loader in SPL ?

Quoted 5 lines

I thought you've already answered your own question. For whatever
reason, the downstream A10 is re-doing the FPGA manager just for this
purpose.

Quoted 13 lines

Could the reason be that the FPGA manager in it's current state expects
one big buffer with the entire FPGA bitstream ? When you're in SPL and
you still don't have DRAM running, you cannot create such buffer
anywhere. Thus, what you need to do is to have some sort of code which
loads a bit of the bitstream file at time and feeds it into the FPGA
manager, piece by piece. This should be doable pretty easily, what do
you think ?

That's exactly what is being in the mach-socfpga directory.

Quoted 7 lines

Quoted 1 line

Um, am I missing it in this patchset ?

No, you're not missing it, I have not sent it up yet. That support is in
the downstream, but also with the fpga-manager driver re-written. I need
to clean this up before I can send it.

OK, thanks :)

Quoted 14 lines

Quoted 13 lines

Quoted 1 line

Yes, but should that code go into mach-socfpga or drivers?

The FPGA manager bits are already in drivers/fpga/ , so that's where the
improvements should go. If you need some special handling in the SPL,
that should be in mach-socfpga . In case it's too much change to the
current SPL, moving the spl.c to spl-gen5.c and creating new spl-gen10.c
might make sense ... or something like that, possibly even with some
spl-common.c .

Quoted 3 lines

Ok. BTW, Arria10 is not using SPL. It has 256K of OCRAM that U -Boot can
use to setup the SDRAM.

Quoted 6 lines

So what do I do if I want to boot arria10 from NAND ? UBI and UBIFS won't
fit into 256kiB, so I think using SPL might be the sensible thing afterall,
since you would be able to use arbitrarily-sized U-Boot.

I hope Chin Liang can chime here, I know that we have support for NAND,
but I haven't been part of that task, so I don't know how it's being done.

Dinh

Quoted 87 lines · Dinh Nguyen

Quoted 85 lines · Marek Vasut

Quoted 51 lines · Dinh Nguyen

Quoted 50 lines · Marek Vasut

Quoted 48 lines · Dinh Nguyen

Quoted 32 lines · Marek Vasut

On Monday, November 23, 2015 at 11:32:27 PM, Dinh Nguyen wrote:
[...]

Quoted 22 lines

Quoted 14 lines

Quoted 14 lines

Quoted 13 lines

Quoted 7 lines

The main point is that we need to program the
FPGA
during U-Boot booting up with a ~>10 MB rbf file
while being
limited to the OCRAM's size. I would like to
contain this
ugliness in it's own directory.

What's the problem with this ? We already support
loading files
from storage in SPL, so just compile the FPGA
manager into SPL as
well and use it.

Quoted 7 lines

Quoted 3 lines

Ok, let me re-work it all under the c5/a5 directory. Thanks for
reviewing.

But you didn't really answer my question -- what is the problem with
the FPGA loader in SPL ?

Quoted 5 lines

I thought you've already answered your own question. For whatever
reason, the downstream A10 is re-doing the FPGA manager just for this
purpose.

Quoted 13 lines

Could the reason be that the FPGA manager in it's current state expects
one big buffer with the entire FPGA bitstream ? When you're in SPL and
you still don't have DRAM running, you cannot create such buffer
anywhere. Thus, what you need to do is to have some sort of code which
loads a bit of the bitstream file at time and feeds it into the FPGA
manager, piece by piece. This should be doable pretty easily, what do
you think ?

That's exactly what is being in the mach-socfpga directory.

Quoted 7 lines

Quoted 1 line

Um, am I missing it in this patchset ?

No, you're not missing it, I have not sent it up yet. That support is in
the downstream, but also with the fpga-manager driver re-written. I need
to clean this up before I can send it.

OK, thanks :)

Quoted 14 lines

Quoted 13 lines

Quoted 1 line

Yes, but should that code go into mach-socfpga or drivers?

The FPGA manager bits are already in drivers/fpga/ , so that's where the
improvements should go. If you need some special handling in the SPL,
that should be in mach-socfpga . In case it's too much change to the
current SPL, moving the spl.c to spl-gen5.c and creating new spl-gen10.c
might make sense ... or something like that, possibly even with some
spl-common.c .

Quoted 3 lines

Ok. BTW, Arria10 is not using SPL. It has 256K of OCRAM that U -Boot can
use to setup the SDRAM.

So what do I do if I want to boot arria10 from NAND ? UBI and UBIFS won't
fit into 256kiB, so I think using SPL might be the sensible thing afterall,
since you would be able to use arbitrarily-sized U-Boot.

Quoted 4 lines

I hope Chin Liang can chime here, I know that we have support for NAND,
but I haven't been part of that task, so I don't know how it's being done.

Finally my email is back online :)

We do have NAND support but not with UBI and UBIFS.

For this support, user can use U-Boot to load arbitrarily-sized U-Boot that run on SDRAM.

One of the nice thing of U-Boot over SPL is the console support and ability to troubleshoot.
This is possible with Arria 10 SoC as we have larger OCRAM (256kB vs CV SoC 64kB).

Quoted 82 lines · Dinh Nguyen

Quoted 81 lines · Marek Vasut

Quoted 80 lines · Dinh Nguyen

Quoted 51 lines · Marek Vasut

Quoted 50 lines · Dinh Nguyen

Quoted 48 lines · Marek Vasut

Quoted 32 lines

On Monday, November 23, 2015 at 11:32:27 PM, Dinh Nguyen wrote:
[...]

Quoted 22 lines

Quoted 14 lines

Quoted 14 lines

Quoted 13 lines

Quoted 7 lines

The main point is that we need to program the
FPGA
during U-Boot booting up with a ~>10 MB rbf file
while being
limited to the OCRAM's size. I would like to
contain this
ugliness in it's own directory.

What's the problem with this ? We already support
loading files
from storage in SPL, so just compile the FPGA
manager into SPL as
well and use it.

Quoted 7 lines

Quoted 3 lines

Ok, let me re-work it all under the c5/a5 directory. Thanks for
reviewing.

But you didn't really answer my question -- what is the problem with
the FPGA loader in SPL ?

Quoted 5 lines

I thought you've already answered your own question. For whatever
reason, the downstream A10 is re-doing the FPGA manager just for this
purpose.

Quoted 13 lines

Could the reason be that the FPGA manager in it's current state expects
one big buffer with the entire FPGA bitstream ? When you're in SPL and
you still don't have DRAM running, you cannot create such buffer
anywhere. Thus, what you need to do is to have some sort of code which
loads a bit of the bitstream file at time and feeds it into the FPGA
manager, piece by piece. This should be doable pretty easily, what do
you think ?

That's exactly what is being in the mach-socfpga directory.

Quoted 7 lines

Quoted 1 line

Um, am I missing it in this patchset ?

No, you're not missing it, I have not sent it up yet. That support is in
the downstream, but also with the fpga-manager driver re-written. I need
to clean this up before I can send it.

OK, thanks :)

Quoted 17 lines

Quoted 13 lines

Quoted 1 line

Yes, but should that code go into mach-socfpga or drivers?

The FPGA manager bits are already in drivers/fpga/ , so that's where the
improvements should go. If you need some special handling in the SPL,
that should be in mach-socfpga . In case it's too much change to the
current SPL, moving the spl.c to spl-gen5.c and creating new spl-gen10.c
might make sense ... or something like that, possibly even with some
spl-common.c .

Ok. BTW, Arria10 is not using SPL. It has 256K of OCRAM that U -Boot can
use to setup the SDRAM.

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

So what do I do if I want to boot arria10 from NAND ? UBI and UBIFS won't
fit into 256kiB, so I think using SPL might be the sensible thing afterall,
since you would be able to use arbitrarily-sized U-Boot.

Quoted 9 lines

Quoted 5 lines

I hope Chin Liang can chime here, I know that we have support for NAND,
but I haven't been part of that task, so I don't know how it's being done.

Finally my email is back online :)

We do have NAND support but not with UBI and UBIFS.

I just hope you're not using raw NAND and just hoping it will work.

Quoted 7 lines

For this support, user can use U-Boot to load arbitrarily-sized U-Boot that run on SDRAM.

One of the nice thing of U-Boot over SPL is the console support and ability to troubleshoot.
This is possible with Arria 10 SoC as we have larger OCRAM (256kB vs CV SoC 64kB).

OK, that's not really the point here -- the point is, if you compile enough features into U-Boot, it will be bigger than those 256k. What will you do then ?

Best regards,
Marek Vasut
_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Hello Marek, Chin Liang See,

Sorry for digging so late into this topic ...

Am 24.11.2015 um 10:31 schrieb Marek Vasut:

Quoted 108 lines · Chin Liang See

Quoted 107 lines · Dinh Nguyen

Quoted 106 lines · Marek Vasut

Quoted 105 lines

Quoted 67 lines · Dinh Nguyen

Quoted 66 lines · Marek Vasut

Quoted 63 lines · Dinh Nguyen

Quoted 51 lines · Marek Vasut

On Monday, November 23, 2015 at 11:32:27 PM, Dinh
Nguyen
wrote:
[...]

Quoted 28 lines

Quoted 23 lines

Quoted 18 lines

Quoted 17 lines

The main point is that we need to program
the
FPGA
during U-Boot booting up with a ~>10 MB rbf
file
while being
limited to the OCRAM's size. I would like
to
contain this
ugliness in it's own directory.

What's the problem with this ? We already
support
loading files
from storage in SPL, so just compile the FPGA
manager into SPL as
well and use it.

Quoted 4 lines

Ok, let me re-work it all under the c5/a5
directory.
Thanks for
reviewing.

Quoted 4 lines

But you didn't really answer my question -- what
is the
problem with
the FPGA loader in SPL ?

Quoted 7 lines

I thought you've already answered your own
question. For
whatever
reason, the downstream A10 is re-doing the FPGA
manager
just for this
purpose.

Could the reason be that the FPGA manager in it's current
state expects
one big buffer with the entire FPGA bitstream ? When you're
in SPL and
you still don't have DRAM running, you cannot create such
buffer
anywhere. Thus, what you need to do is to have some

Quoted 8 lines

sort of
code which
loads a bit of the bitstream file at time and feeds it into
the FPGA
manager, piece by piece. This should be doable pretty easily, what do
you think ?

That's exactly what is being in the mach-socfpga
directory.

Quoted 8 lines

Quoted 1 line

Um, am I missing it in this patchset ?

No, you're not missing it, I have not sent it up yet. That support is in
the downstream, but also with the fpga-manager driver re -written.
I need
to clean this up before I can send it.

OK, thanks :)

Quoted 24 lines

Quoted 19 lines

Quoted 2 lines

Yes, but should that code go into mach-socfpga or
drivers?

The FPGA manager bits are already in drivers/fpga/ , so that's
where the
improvements should go. If you need some special handling in
the SPL,
that should be in mach-socfpga . In case it's too much change
to the
current SPL, moving the spl.c to spl-gen5.c and creating new
spl-gen10.c
might make sense ... or something like that, possibly even with
some
spl-common.c .

Ok. BTW, Arria10 is not using SPL. It has 256K of OCRAM that U
-Boot can
use to setup the SDRAM.

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

So what do I do if I want to boot arria10 from NAND ? UBI and UBIFS
won't
fit into 256kiB, so I think using SPL might be the sensible thing
afterall,
since you would be able to use arbitrarily-sized U-Boot.

Maybe you can try:
[U-Boot] [patch 0/2] SPL: Lightweight UBI and UBI fastmap support
http://lists.denx.de/pipermail/u-boot/2014-July/183167.html
http://lists.denx.de/pipermail/u-boot/2014-July/183166.html
http://lists.denx.de/pipermail/u-boot/2014-July/183168.html

Its about < 7k

I did not found the time yet, looking into it, but it would be nice to have ;-)

bye,
Heiko

Quoted 38 lines

Quoted 11 lines

Quoted 7 lines

I hope Chin Liang can chime here, I know that we have support for
NAND,
but I haven't been part of that task, so I don't know how it's being
done.

Finally my email is back online :)

We do have NAND support but not with UBI and UBIFS.

I just hope you're not using raw NAND and just hoping it will work.

Quoted 10 lines

For this support, user can use U-Boot to load arbitrarily-sized U -Boot
that run on SDRAM.

One of the nice thing of U-Boot over SPL is the console support and
ability to troubleshoot.
This is possible with Arria 10 SoC as we have larger OCRAM (256kB vs CV
SoC 64kB).

OK, that's not really the point here -- the point is, if you compile enough
features into U-Boot, it will be bigger than those 256k. What will you do
then ?

Best regards,
Marek Vasut
_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Hello Marek, Chin Liang See,

Sorry for digging so late into this topic ...

Am 24.11.2015 um 10:31 schrieb Marek Vasut:

Quoted 108 lines · Chin Liang See

Quoted 107 lines · Dinh Nguyen

Quoted 106 lines · Marek Vasut

Quoted 105 lines

Quoted 67 lines · Dinh Nguyen

Quoted 66 lines · Marek Vasut

Quoted 63 lines · Dinh Nguyen

Quoted 51 lines · Marek Vasut

On Monday, November 23, 2015 at 11:32:27 PM, Dinh
Nguyen
wrote:
[...]

Quoted 28 lines

Quoted 23 lines

Quoted 18 lines

Quoted 17 lines

The main point is that we need to program
the
FPGA
during U-Boot booting up with a ~>10 MB rbf
file
while being
limited to the OCRAM's size. I would like
to
contain this
ugliness in it's own directory.

What's the problem with this ? We already
support
loading files
from storage in SPL, so just compile the FPGA
manager into SPL as
well and use it.

Quoted 4 lines

Ok, let me re-work it all under the c5/a5
directory.
Thanks for
reviewing.

Quoted 4 lines

But you didn't really answer my question -- what
is the
problem with
the FPGA loader in SPL ?

Quoted 7 lines

I thought you've already answered your own
question. For
whatever
reason, the downstream A10 is re-doing the FPGA
manager
just for this
purpose.

Could the reason be that the FPGA manager in it's current
state expects
one big buffer with the entire FPGA bitstream ? When you're
in SPL and
you still don't have DRAM running, you cannot create such
buffer
anywhere. Thus, what you need to do is to have some

Quoted 8 lines

sort of
code which
loads a bit of the bitstream file at time and feeds it into
the FPGA
manager, piece by piece. This should be doable pretty easily, what do
you think ?

That's exactly what is being in the mach-socfpga
directory.

Quoted 8 lines

Quoted 1 line

Um, am I missing it in this patchset ?

No, you're not missing it, I have not sent it up yet. That support is in
the downstream, but also with the fpga-manager driver re -written.
I need
to clean this up before I can send it.

OK, thanks :)

Quoted 24 lines

Quoted 19 lines

Quoted 2 lines

Yes, but should that code go into mach-socfpga or
drivers?

The FPGA manager bits are already in drivers/fpga/ , so that's
where the
improvements should go. If you need some special handling in
the SPL,
that should be in mach-socfpga . In case it's too much change
to the
current SPL, moving the spl.c to spl-gen5.c and creating new
spl-gen10.c
might make sense ... or something like that, possibly even with
some
spl-common.c .

Ok. BTW, Arria10 is not using SPL. It has 256K of OCRAM that U
-Boot can
use to setup the SDRAM.

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

So what do I do if I want to boot arria10 from NAND ? UBI and UBIFS
won't
fit into 256kiB, so I think using SPL might be the sensible thing
afterall,
since you would be able to use arbitrarily-sized U-Boot.

Maybe you can try:
[U-Boot] [patch 0/2] SPL: Lightweight UBI and UBI fastmap support
http://lists.denx.de/pipermail/u-boot/2014-July/183167.html
http://lists.denx.de/pipermail/u-boot/2014-July/183166.html
http://lists.denx.de/pipermail/u-boot/2014-July/183168.html

Its about < 7k

I did not found the time yet, looking into it, but it would be nice to have ;-)

bye,
Heiko

Quoted 37 lines

Quoted 10 lines

Quoted 6 lines

I hope Chin Liang can chime here, I know that we have support for
NAND,
but I haven't been part of that task, so I don't know how it's being
done.

Finally my email is back online :)

We do have NAND support but not with UBI and UBIFS.

I just hope you're not using raw NAND and just hoping it will work.

Quoted 10 lines

For this support, user can use U-Boot to load arbitrarily-sized U -Boot
that run on SDRAM.

One of the nice thing of U-Boot over SPL is the console support and
ability to troubleshoot.
This is possible with Arria 10 SoC as we have larger OCRAM (256kB vs CV
SoC 64kB).

OK, that's not really the point here -- the point is, if you compile enough
features into U-Boot, it will be bigger than those 256k. What will you do
then ?

Best regards,
Marek Vasut
_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Quoted 11 lines

Quoted 10 lines

Quoted 5 lines

So what do I do if I want to boot arria10 from NAND ? UBI and UBIFS won't
fit into 256kiB, so I think using SPL might be the sensible thing afterall,
since you would be able to use arbitrarily-sized U-Boot.

I hope Chin Liang can chime here, I know that we have support for NAND,
but I haven't been part of that task, so I don't know how it's being done.

Quoted 3 lines

Finally my email is back online :)

We do have NAND support but not with UBI and UBIFS.

I just hope you're not using raw NAND and just hoping it will work.

Quoted 2 lines

For this support, user can use U-Boot to load arbitrarily-sized U-Boot that run on SDRAM.

Quoted 4 lines

One of the nice thing of U-Boot over SPL is the console support and ability to troubleshoot.
This is possible with Arria 10 SoC as we have larger OCRAM (256kB vs CV SoC 64kB).

OK, that's not really the point here -- the point is, if you compile enough features into U-Boot, it will be bigger than those 256k. What will you do then ?

Hi!

Quoted 15 lines

Quoted 15 lines

Quoted 14 lines

Quoted 7 lines

So what do I do if I want to boot arria10 from NAND ? UBI and UBIFS
won't
fit into 256kiB, so I think using SPL might be the sensible thing
afterall,
since you would be able to use arbitrarily-sized U-Boot.

I hope Chin Liang can chime here, I know that we have support for
NAND,
but I haven't been part of that task, so I don't know how it's being
done.

Quoted 5 lines

Quoted 3 lines

Finally my email is back online :)

We do have NAND support but not with UBI and UBIFS.

I just hope you're not using raw NAND and just hoping it will work.

HERE:

Quoted 3 lines

Quoted 3 lines

For this support, user can use U-Boot to load arbitrarily-sized U -Boot
that run on SDRAM.

...

Quoted 7 lines

Quoted 6 lines

One of the nice thing of U-Boot over SPL is the console support and
ability to troubleshoot.
This is possible with Arria 10 SoC as we have larger OCRAM (256kB vs CV
SoC 64kB).

Quoted 5 lines

OK, that's not really the point here -- the point is, if you compile enough
features into U-Boot, it will be bigger than those 256k. What will you do
then ?

You'll compile small U-Boot, and use it to load larger U-Boot, as he said in the mark "HERE" above.

And yes, I guess that makes sense, and yes, we should finally make loading U-Boot from U-Boot oficially supported, at least on Socfpga.

Pavel

Hi Pavel,

Quoted 43 lines · Pavel Machek

Hi!

Quoted 15 lines

Quoted 15 lines

Quoted 14 lines

Quoted 7 lines

So what do I do if I want to boot arria10 from NAND ? UBI and UBIFS
won't
fit into 256kiB, so I think using SPL might be the sensible thing
afterall,
since you would be able to use arbitrarily-sized U-Boot.

I hope Chin Liang can chime here, I know that we have support for
NAND,
but I haven't been part of that task, so I don't know how it's being
done.

Quoted 5 lines

Quoted 3 lines

Finally my email is back online :)

We do have NAND support but not with UBI and UBIFS.

I just hope you're not using raw NAND and just hoping it will work.

HERE:

Quoted 3 lines

Quoted 3 lines

For this support, user can use U-Boot to load arbitrarily-sized U -Boot
that run on SDRAM.

...

Quoted 12 lines

Quoted 6 lines

One of the nice thing of U-Boot over SPL is the console support and
ability to troubleshoot.
This is possible with Arria 10 SoC as we have larger OCRAM (256kB vs CV
SoC 64kB).

OK, that's not really the point here -- the point is, if you compile enough
features into U-Boot, it will be bigger than those 256k. What will you do
then ?

Quoted 5 lines

You'll compile small U-Boot, and use it to load larger U-Boot, as he said in the mark "HERE" above.

And yes, I guess that makes sense, and yes, we should finally make loading U-Boot from U-Boot oficially supported, at least on Socfpga.

Yup, you got it :)
Thanks

Quoted 19 lines

Quoted 18 lines

Quoted 7 lines

Quoted 6 lines

One of the nice thing of U-Boot over SPL is the console support and
ability to troubleshoot.
This is possible with Arria 10 SoC as we have larger OCRAM (256kB vs CV
SoC 64kB).

Quoted 5 lines

OK, that's not really the point here -- the point is, if you compile enough
features into U-Boot, it will be bigger than those 256k. What will you do
then ?

You'll compile small U-Boot, and use it to load larger U-Boot, as he said in the mark "HERE" above.

And yes, I guess that makes sense, and yes, we should finally make loading U-Boot from U-Boot oficially supported, at least on Socfpga.

Quoted 2 lines

Yup, you got it :)
Thanks

So why exactly don't we use SPL instead ? The purpose of SPL is to do exactly this without the extra cruft which is part of U-Boot and the unnecessary overhead of the full U-Boot. And you don't need to hack U-Boot to support loading U-Boot.

Hi!

Quoted 19 lines

Quoted 19 lines

Quoted 18 lines

Quoted 7 lines

Quoted 6 lines

One of the nice thing of U-Boot over SPL is the console support and
ability to troubleshoot.
This is possible with Arria 10 SoC as we have larger OCRAM (256kB vs CV
SoC 64kB).

Quoted 5 lines

OK, that's not really the point here -- the point is, if you compile enough
features into U-Boot, it will be bigger than those 256k. What will you do
then ?

You'll compile small U-Boot, and use it to load larger U-Boot, as he said in the mark "HERE" above.

And yes, I guess that makes sense, and yes, we should finally make loading U-Boot from U-Boot oficially supported, at least on Socfpga.

Quoted 7 lines

Quoted 2 lines

Yup, you got it :)
Thanks

So why exactly don't we use SPL instead ? The purpose of SPL is to do exactly this without the extra cruft which is part of U-Boot and the unnecessary overhead of the full U-Boot. And you don't need to hack U-Boot to support loading U-Boot.

You don't need to hack anything, it just works today.

And yes, U-Boot is easier to work with, because it has commandline, etc.

In ideal world, U-Boot SPL would disappear. You'd just compile small "U-Boot 1" and bigger "U-Boot 2". Lets get there... No need for arbitrary limitations like "Full U-Boot can't initialize sdram" or "U-Boot SPL can't have command line".

Quoted 119 lines · Chin Liang See

Quoted 112 lines · Dinh Nguyen

Quoted 103 lines · Marek Vasut

Quoted 65 lines · Dinh Nguyen

Quoted 64 lines · Marek Vasut

Quoted 61 lines · Dinh Nguyen

Quoted 49 lines · Marek Vasut

On Monday, November 23, 2015 at 11:32:27 PM, Dinh
Nguyen
wrote:
[...]

Quoted 26 lines

Quoted 21 lines

Quoted 16 lines

Quoted 9 lines

Quoted 8 lines

The main point is that we need to program the
FPGA
during U-Boot booting up with a ~>10 MB rbf
file
while being
limited to the OCRAM's size. I would like to
contain this
ugliness in it's own directory.

Quoted 6 lines

What's the problem with this ? We already
support
loading files
from storage in SPL, so just compile the FPGA
manager into SPL as
well and use it.

Quoted 4 lines

Ok, let me re-work it all under the c5/a5
directory.
Thanks for
reviewing.

Quoted 4 lines

But you didn't really answer my question -- what is the
problem with
the FPGA loader in SPL ?

Quoted 7 lines

I thought you've already answered your own question. For
whatever
reason, the downstream A10 is re-doing the FPGA manager
just for this
purpose.

Could the reason be that the FPGA manager in it's current
state expects
one big buffer with the entire FPGA bitstream ? When you're
in SPL and
you still don't have DRAM running, you cannot create such
buffer
anywhere. Thus, what you need to do is to have some

Quoted 8 lines

sort of
code which
loads a bit of the bitstream file at time and feeds it into
the FPGA
manager, piece by piece. This should be doable pretty easily, what do
you think ?

That's exactly what is being in the mach-socfpga
directory.

Quoted 8 lines

Quoted 1 line

Um, am I missing it in this patchset ?

No, you're not missing it, I have not sent it up yet. That support is in
the downstream, but also with the fpga-manager driver re -written.
I need
to clean this up before I can send it.

OK, thanks :)

Quoted 20 lines

Quoted 19 lines

Quoted 2 lines

Yes, but should that code go into mach-socfpga or
drivers?

The FPGA manager bits are already in drivers/fpga/ , so that's
where the
improvements should go. If you need some special handling in
the SPL,
that should be in mach-socfpga . In case it's too much change
to the
current SPL, moving the spl.c to spl-gen5.c and creating new
spl-gen10.c
might make sense ... or something like that, possibly even with
some
spl-common.c .

Quoted 4 lines

Ok. BTW, Arria10 is not using SPL. It has 256K of OCRAM that U
-Boot can
use to setup the SDRAM.

Quoted 7 lines

So what do I do if I want to boot arria10 from NAND ? UBI and UBIFS
won't
fit into 256kiB, so I think using SPL might be the sensible thing
afterall,
since you would be able to use arbitrarily-sized U-Boot.

Quoted 5 lines

I hope Chin Liang can chime here, I know that we have support for NAND,
but I haven't been part of that task, so I don't know how it's being
done.

Quoted 3 lines

Finally my email is back online :)

We do have NAND support but not with UBI and UBIFS.

I just hope you're not using raw NAND and just hoping it will work.

Quoted 9 lines

For this support, user can use U-Boot to load arbitrarily-sized U -Boot
that run on SDRAM.

One of the nice thing of U-Boot over SPL is the console support and ability to troubleshoot.
This is possible with Arria 10 SoC as we have larger OCRAM (256kB vs CV
SoC 64kB).

OK, that's not really the point here -- the point is, if you compile enough
features into U-Boot, it will be bigger than those 256k. What will you do
then ?

Best regards,
Marek Vasut

Hi Marek,

Quoted 10 lines

Quoted 9 lines

For this support, user can use U-Boot to load arbitrarily-sized U -Boot
that run on SDRAM.

One of the nice thing of U-Boot over SPL is the console support and ability to troubleshoot.
This is possible with Arria 10 SoC as we have larger OCRAM (256kB vs CV
SoC 64kB).

Quoted 5 lines

OK, that's not really the point here -- the point is, if you compile enough
features into U-Boot, it will be bigger than those 256k. What will you do
then ?

For this case, we will have 4 boot stages where a minimal U-Boot that run on OCRAM to load a larger U-Boot which will run on SDRAM. For better explanation, here are the events for this 4 boot stages.

1. BootROM load minimal U-Boot to OCRAM
2. Minimal U-Boot initialize all the critical HW such as clocks, DDR
3. Minimal U-Boot load larger U-Boot to SDRAM
4. Larger U-Boot will then load Linux
5. Linux boot

Quoted 25 lines · Marek Vasut

Quoted 16 lines · dinguyen at opensource.altera.com

From: Dinh Nguyen <[email protected]>

Update Makefile to build Arria 10.

Signed-off-by Dinh Nguyen <[email protected]>

---
 arch/arm/mach-socfpga/Makefile         | 7 +++++--
 arch/arm/mach-socfpga/arria10/Makefile | 7 +++++++
 2 files changed, 12 insertions(+), 2 deletions(-)
 create mode 100644 arch/arm/mach-socfpga/arria10/Makefile

(quoted diff) +0 -0

b/arch/arm/mach-socfpga/Makefile index 316b326..0dbe9bb 100644

arch/arm/mach-socfpga/Makefile line 10

Quoted 6 lines

arch/arm/mach-socfpga/Makefile +1 -1

@@ -6,15 +6,18 @@
 #
 # SPDX-License-Identifier:	GPL-2.0+
 #
-
+ifneq ($(CONFIG_TARGET_SOCFPGA_ARRIA10),y)
 obj-y	+= misc.o timer.o reset_manager.o system_manager.o 

clock_manager.o \

Quoted 13 lines

arch/arm/mach-socfpga/Makefile line 18

Quoted 9 lines

arch/arm/mach-socfpga/Makefile +2 -1

 	   fpga_manager.o scan_manager.o
 obj-$(CONFIG_SPL_BUILD) += spl.o freeze_controller.o
-
 # QTS-generated config file wrappers
 obj-y	+= wrap_pll_config.o
 obj-$(CONFIG_SPL_BUILD) += wrap_iocsr_config.o wrap_pinmux_config.o	\
 			   wrap_sdram_config.o
+else
+obj-y	+= arria10/

So why exactly does A10 have it's own dedicated dir if most of the code is probably shared between A10 and AV/CV ?

Yes, there are some sharing. But I think that there will be enough differences that will ultimately warrant it's own directory. I think with it's own directory, the Makefile changes stay a bit cleaner. I

One of the biggest differences is that the A10's SDRAM support is going to be a bit ugly. The main point is that we need to program the FPGA during U-Boot booting up with a ~>10 MB rbf file while being limited to the OCRAM's size. I would like to contain this ugliness in it's own directory.