[U-Boot] [PATCH 00/10] ARM: socfpga: Add minimal support for Arria10

[U-Boot] [PATCH 00/10] ARM: socfpga: Add minimal support for Arria10

[dinguyen at opensource.altera.com]

From: Dinh Nguyen <dinguyen@opensource.altera.com>

Hi,

This patchset adds the foundation support for Arria10. The series builds for
the Altera Arria10 SoCDK, but is not entirely functional on the hardware yet.
This series really just add the defines, build and Kconfig layout for Arria10.

There are few TODO after this series:
- Add DTS file for the devkit
- Add clock manager
- The Arria10 Pin Mux requires the FPGA to get programmed before the SDRAM
  controller can be usable. So another patch is needed to make use of the fpga
  manager to program the FPGA within the limited size of the OCRAM.

Thanks,
Dinh

Dinh Nguyen (10):
  ARM: socfpga: arria10: add base address map for Arria10
  ARM: socfpga: arria10: add system manager defines
  ARM: socfpga: arria10: add reset manager for Arria10
  ARM: socfpga: arria10: add stub sdram init for Arria10
  ARM: socfpga: arria10: add misc functions for Arria10
  ARM: socfpga: arria10: add socfpga_arria10_socdk config
  ARM: socfpga: arria10: add board files for the Arria10 SoCDK
  ARM: socfpga: arria10: add socfpga_arria10_defconfig
  ARM: socfpga: arria10: add config option build for arria10
  ARM: socfpga: arria10: add support for building Arria10

 arch/arm/Kconfig                                   |   4 +-
 arch/arm/mach-socfpga/Kconfig                      |  10 +
 arch/arm/mach-socfpga/Makefile                     |   7 +-
 arch/arm/mach-socfpga/arria10/Makefile             |   7 +
 arch/arm/mach-socfpga/arria10/misc_a10.c           | 138 ++++++++
 arch/arm/mach-socfpga/arria10/reset_manager_a10.c  |  83 +++++
 arch/arm/mach-socfpga/arria10/sdram_a10.c          |  15 +
 .../mach-socfpga/include/mach/reset_manager_a10.h  | 162 +++++++++
 arch/arm/mach-socfpga/include/mach/sdram_a10.h     | 371 +++++++++++++++++++++
 .../include/mach/socfpga_a10_base_addrs.h          |  45 +++
 .../mach-socfpga/include/mach/system_manager_a10.h | 157 +++++++++
 board/altera/arria10-socdk/Kconfig                 |  18 +
 board/altera/arria10-socdk/Makefile                |   9 +
 board/altera/arria10-socdk/socfpga.c               |  24 ++
 configs/socfpga_arria10_defconfig                  |  11 +
 include/configs/socfpga_arria10_socdk.h            | 292 ++++++++++++++++
 16 files changed, 1349 insertions(+), 4 deletions(-)
 create mode 100644 arch/arm/mach-socfpga/arria10/Makefile
 create mode 100644 arch/arm/mach-socfpga/arria10/misc_a10.c
 create mode 100644 arch/arm/mach-socfpga/arria10/reset_manager_a10.c
 create mode 100644 arch/arm/mach-socfpga/arria10/sdram_a10.c
 create mode 100644 arch/arm/mach-socfpga/include/mach/reset_manager_a10.h
 create mode 100644 arch/arm/mach-socfpga/include/mach/sdram_a10.h
 create mode 100644 arch/arm/mach-socfpga/include/mach/socfpga_a10_base_addrs.h
 create mode 100644 arch/arm/mach-socfpga/include/mach/system_manager_a10.h
 create mode 100644 board/altera/arria10-socdk/Kconfig
 create mode 100644 board/altera/arria10-socdk/Makefile
 create mode 100644 board/altera/arria10-socdk/socfpga.c
 create mode 100644 configs/socfpga_arria10_defconfig
 create mode 100644 include/configs/socfpga_arria10_socdk.h

-- 
2.6.2

[U-Boot] [PATCH 01/10] ARM: socfpga: arria10: add base address map for Arria10

[dinguyen at opensource.altera.com]

From: Dinh Nguyen <dinguyen@opensource.altera.com>

Add the base address map for Arria10.

Signed-off-by: Dinh Nguyen <dinguyen@opensource.altera.com>
---
 .../include/mach/socfpga_a10_base_addrs.h          | 45 ++++++++++++++++++++++
 1 file changed, 45 insertions(+)
 create mode 100644 arch/arm/mach-socfpga/include/mach/socfpga_a10_base_addrs.h

diff --git a/arch/arm/mach-socfpga/include/mach/socfpga_a10_base_addrs.h b/arch/arm/mach-socfpga/include/mach/socfpga_a10_base_addrs.h
new file mode 100644
index 0000000..a7056d4
--- /dev/null
+++ b/arch/arm/mach-socfpga/include/mach/socfpga_a10_base_addrs.h
@@ -0,0 +1,45 @@
+/*
+ * Copyright (C) 2014 Altera Corporation <www.altera.com>
+ *
+ * SPDX-License-Identifier:	GPL-2.0+
+ */
+
+#ifndef _SOCFPGA_A10_BASE_HARDWARE_H_
+#define _SOCFPGA_A10_BASE_HARDWARE_H_
+
+#define SOCFPGA_EMAC0_ADDRESS			0xff800000
+#define SOCFPGA_EMAC1_ADDRESS			0xff802000
+#define SOCFPGA_EMAC2_ADDRESS			0xff804000
+#define SOCFPGA_SDMMC_ADDRESS			0xff808000
+#define SOCFPGA_QSPIREGS_ADDRESS		0xff809000
+#define SOCFPGA_QSPIDATA_ADDRESS		0xffa00000
+#define SOCFPGA_UART1_ADDRESS			0xffc02100
+#define SOCFPGA_HMC_MMR_IO48_ADDRESS		0xffcfa000
+#define SOCFPGA_FPGAMGRDATA_ADDRESS		0xffcfe400
+#define SOCFPGA_FPGAMGRREGS_ADDRESS		0xffd03000
+#define SOCFPGA_L4WD0_ADDRESS			0xffd00200
+#define SOCFPGA_SYSMGR_ADDRESS			0xffd06000
+#define SOCFPGA_PINMUX_SHARED_3V_IO_ADDRESS	0xffd07000
+#define SOCFPGA_PINMUX_DEDICATED_IO_ADDRESS	0xffd07200
+#define SOCFPGA_PINMUX_DEDICATED_IO_CFG_ADDRESS	0xffd07300
+#define SOCFPGA_PINMUX_FPGA_INTERFACE_ADDRESS	0xffd07400
+#define SOCFPGA_DMANONSECURE_ADDRESS		0xffda0000
+#define SOCFPGA_DMASECURE_ADDRESS		0xffda1000
+#define SOCFPGA_MPUSCU_ADDRESS			0xffffc000
+#define SOCFPGA_MPUL2_ADDRESS			0xfffff000
+#define SOCFPGA_I2C0_ADDRESS			0xffc02200
+#define SOCFPGA_I2C1_ADDRESS			0xffc02300
+
+#define SOCFPGA_ECC_OCRAM_ADDRESS		0xff8c3000
+#define SOCFPGA_UART0_ADDRESS			0xffc02000
+#define SOCFPGA_OSC1TIMER0_ADDRESS		0xffd00000
+#define SOCFPGA_CLKMGR_ADDRESS			0xffd04000
+#define SOCFPGA_RSTMGR_ADDRESS			0xffd05000
+
+#define SOCFPGA_SDR_ADDRESS			0xffcfb000
+#define SOCFPGA_SDR_SCHEDULER_ADDRESS		0xffd12400
+#define SOCFPGA_SDR_FIREWALL_OCRAM_ADDRESS	0xffd13200
+#define SOCFPGA_SDR_FIREWALL_MPU_FPGA_ADDRESS	0xffd13300
+#define SOCFPGA_SDR_FIREWALL_L3_ADDRESS		0xffd13400
+
+#endif /* _SOCFPGA_A10_BASE_HARDWARE_H_ */
-- 
2.6.2

[U-Boot] [PATCH 01/10] ARM: socfpga: arria10: add base address map for Arria10

[Marek Vasut]

On Thursday, November 19, 2015 at 10:35:38 PM, dinguyen at opensource.altera.com 
wrote:
> From: Dinh Nguyen <dinguyen@opensource.altera.com>
> 
> Add the base address map for Arria10.
> 
> Signed-off-by: Dinh Nguyen <dinguyen@opensource.altera.com>
> ---
>  .../include/mach/socfpga_a10_base_addrs.h          | 45

Reviewed-by: Marek Vasut <marex@denx.de>

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 ?

Best regards,
Marek Vasut

[U-Boot] [PATCH 01/10] ARM: socfpga: arria10: add base address map for Arria10

[Dinh Nguyen]

On 11/19/2015 04:26 PM, Marek Vasut wrote:
> On Thursday, November 19, 2015 at 10:35:38 PM, dinguyen at opensource.altera.com 
> wrote:
>> From: Dinh Nguyen <dinguyen@opensource.altera.com>
>>
>> Add the base address map for Arria10.
>>
>> Signed-off-by: Dinh Nguyen <dinguyen@opensource.altera.com>
>> ---
>>  .../include/mach/socfpga_a10_base_addrs.h          | 45
> 
> Reviewed-by: Marek Vasut <marex@denx.de>
> 
> 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 ?
> 

Yes, I agree. I'll send a patch to rename the socfpga_base_addr.h for
ac5 along with v2 of this.

Dinh

[U-Boot] [PATCH 02/10] ARM: socfpga: arria10: add system manager defines

[dinguyen at opensource.altera.com]

From: Dinh Nguyen <dinguyen@opensource.altera.com>

Add system manager defines for Arria10.

Signed-off-by: Dinh Nguyen <dinguyen@opensource.altera.com>
---
 .../mach-socfpga/include/mach/system_manager_a10.h | 157 +++++++++++++++++++++
 1 file changed, 157 insertions(+)
 create mode 100644 arch/arm/mach-socfpga/include/mach/system_manager_a10.h

diff --git a/arch/arm/mach-socfpga/include/mach/system_manager_a10.h b/arch/arm/mach-socfpga/include/mach/system_manager_a10.h
new file mode 100644
index 0000000..d01b837
--- /dev/null
+++ b/arch/arm/mach-socfpga/include/mach/system_manager_a10.h
@@ -0,0 +1,157 @@
+/*
+ * Copyright (C) 2014 Altera Corporation <www.altera.com>
+ *
+ * SPDX-License-Identifier:	GPL-2.0+
+ */
+
+#ifndef	_SOCFPGA_SYSTEM_MANAGER_A10_H_
+#define	_SOCFPGA_SYSTEM_MANAGER_A10_H_
+
+#ifndef __ASSEMBLY__
+struct socfpga_system_manager {
+	u32  siliconid1;
+	u32  siliconid2;
+	u32  wddbg;
+	u32  bootinfo;
+	u32  mpu_ctrl_l2_ecc;
+	u32  _pad_0x14_0x1f[3];
+	u32  dma;
+	u32  dma_periph;
+	u32  sdmmcgrp_ctrl;
+	u32  sdmmc_l3master;
+	u32  nand_bootstrap;
+	u32  nand_l3master;
+	u32  usb0_l3master;
+	u32  usb1_l3master;
+	u32  emac_global;
+	u32  emac0;
+	u32  emac1;
+	u32  emac2;
+	u32  _pad_0x50_0x5f[4];
+	u32  fpgaintf_en_global;
+	u32  fpgaintf_en_0;
+	u32  fpgaintf_en_1;
+	u32  fpgaintf_en_2;
+	u32  fpgaintf_en_3;
+	u32  _pad_0x74_0x7f[3];
+	u32  noc_addr_remap_value;
+	u32  noc_addr_remap_set;
+	u32  noc_addr_remap_clear;
+	u32  _pad_0x8c_0x8f;
+	u32  ecc_intmask_value;
+	u32  ecc_intmask_set;
+	u32  ecc_intmask_clr;
+	u32  ecc_intstatus_serr;
+	u32  ecc_intstatus_derr;
+	u32  mpu_status_l2_ecc;
+	u32  mpu_clear_l2_ecc;
+	u32  mpu_status_l1_parity;
+	u32  mpu_clear_l1_parity;
+	u32  mpu_set_l1_parity;
+	u32  _pad_0xb8_0xbf[2];
+	u32  noc_timeout;
+	u32  noc_idlereq_set;
+	u32  noc_idlereq_clr;
+	u32  noc_idlereq_value;
+	u32  noc_idleack;
+	u32  noc_idlestatus;
+	u32  fpga2soc_ctrl;
+	u32  _pad_0xdc_0xff[9];
+	u32  tsmc_tsel_0;
+	u32  tsmc_tsel_1;
+	u32  tsmc_tsel_2;
+	u32  tsmc_tsel_3;
+	u32  _pad_0x110_0x200[60];
+	u32  romhw_ctrl;
+	u32  romcode_ctrl;
+	u32  romcode_cpu1startaddr;
+	u32  romcode_initswstate;
+	u32  romcode_initswlastld;
+	u32  _pad_0x214_0x217;
+	u32  warmram_enable;
+	u32  warmram_datastart;
+	u32  warmram_length;
+	u32  warmram_execution;
+	u32  warmram_crc;
+	u32  _pad_0x22c_0x22f;
+	u32  isw_handoff[8];
+	u32  romcode_bootromswstate[8];
+};
+#endif /* __ASSEMBLY__ */
+
+/* bit fields */
+#define SYSMGR_ROMCODEGRP_CTRL_WARMRSTCFGPINMUX		(1<<0)
+#define SYSMGR_ROMCODEGRP_CTRL_WARMRSTCFGIO		(1<<1)
+#define SYSMGR_ECC_OCRAM_EN		(1<<0)
+#define SYSMGR_ECC_OCRAM_SERR		(1<<3)
+#define SYSMGR_ECC_OCRAM_DERR		(1<<4)
+#define SYSMGR_FPGAINTF_USEFPGA		0x1
+#define SYSMGR_FPGAINTF_SPIM0		(1<<0)
+#define SYSMGR_FPGAINTF_SPIM1		(1<<1)
+#define SYSMGR_FPGAINTF_EMAC0		(1<<2)
+#define SYSMGR_FPGAINTF_EMAC1		(1<<3)
+#define SYSMGR_FPGAINTF_NAND		(1<<4)
+#define SYSMGR_FPGAINTF_SDMMC		(1<<5)
+
+/* Enumeration: sysmgr::emacgrp::ctrl::physel::enum                        */
+#define SYSMGR_EMACGRP_CTRL_PHYSEL_ENUM_GMII_MII 0x0
+#define SYSMGR_EMACGRP_CTRL_PHYSEL_ENUM_RGMII 0x1
+#define SYSMGR_EMACGRP_CTRL_PHYSEL_ENUM_RMII 0x2
+#define SYSMGR_EMACGRP_CTRL_PHYSEL0_LSB 0
+#define SYSMGR_EMACGRP_CTRL_PHYSEL1_LSB 2
+#define SYSMGR_EMACGRP_CTRL_PHYSEL_MASK 0x00000003
+
+/* For dedicated IO configuration */
+/* Voltage select enums */
+#define VOLTAGE_SEL_3V		0x0
+#define VOLTAGE_SEL_1P8V	0x1
+#define VOLTAGE_SEL_2P5V	0x2
+
+/* Input buffer enable */
+#define INPUT_BUF_DISABLE	(0)
+#define INPUT_BUF_1P8V		(1)
+#define INPUT_BUF_2P5V3V	(2)
+
+/* 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
+#define ALT_SYSMGR_NOC_F2SDR0_SET_MSK	0x00010000
+#define ALT_SYSMGR_NOC_F2SDR1_SET_MSK	0x00100000
+#define ALT_SYSMGR_NOC_F2SDR2_SET_MSK	0x01000000
+#define ALT_SYSMGR_NOC_TMO_EN_SET_MSK	0x00000001
+
+#define ALT_SYSMGR_ECC_INTSTAT_SERR_OCRAM_SET_MSK    0x00000002
+#define ALT_SYSMGR_ECC_INTSTAT_DERR_OCRAM_SET_MSK    0x00000002
+
+#define SYSMGR_A10_SDMMC_CTRL_SET(smplsel, drvsel)	\
+	((drvsel << 0) & 0x7) | ((smplsel << 4) & 0x70)
+
+#endif /* _SOCFPGA_SYSTEM_MANAGER_A10_H_ */
-- 
2.6.2

[U-Boot] [PATCH 02/10] ARM: socfpga: arria10: add system manager defines

[Marek Vasut]

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

Hi!

[...]

> +/* Input buffer enable */
> +#define INPUT_BUF_DISABLE	(0)
> +#define INPUT_BUF_1P8V		(1)
> +#define INPUT_BUF_2P5V3V	(2)

You can drop those parenthesis around the number

> +/* 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
> +#define ALT_SYSMGR_NOC_F2SDR0_SET_MSK	0x00010000
> +#define ALT_SYSMGR_NOC_F2SDR1_SET_MSK	0x00100000
> +#define ALT_SYSMGR_NOC_F2SDR2_SET_MSK	0x01000000
> +#define ALT_SYSMGR_NOC_TMO_EN_SET_MSK	0x00000001
> +
> +#define ALT_SYSMGR_ECC_INTSTAT_SERR_OCRAM_SET_MSK    0x00000002
> +#define ALT_SYSMGR_ECC_INTSTAT_DERR_OCRAM_SET_MSK    0x00000002
> +
> +#define SYSMGR_A10_SDMMC_CTRL_SET(smplsel, drvsel)	\
> +	((drvsel << 0) & 0x7) | ((smplsel << 4) & 0x70)

You should use parenthesis around the variables in the macro.

> +#endif /* _SOCFPGA_SYSTEM_MANAGER_A10_H_ */

[U-Boot] [PATCH 03/10] ARM: socfpga: arria10: add reset manager for Arria10

[dinguyen at opensource.altera.com]

From: Dinh Nguyen <dinguyen@opensource.altera.com>

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

Signed-off-by: Dinh Nguyen <dinguyen@opensource.altera.com>
---
 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

diff --git a/arch/arm/mach-socfpga/arria10/reset_manager_a10.c b/arch/arm/mach-socfpga/arria10/reset_manager_a10.c
new file mode 100644
index 0000000..e2d315a
--- /dev/null
+++ b/arch/arm/mach-socfpga/arria10/reset_manager_a10.c
@@ -0,0 +1,83 @@
+/*
+ * Copyright (C) 2014 Altera Corporation <www.altera.com>
+ *
+ * SPDX-License-Identifier:	GPL-2.0+
+ */
+
+#include <common.h>
+#include <asm/io.h>
+#include <asm/arch/reset_manager_a10.h>
+#include <asm/arch/system_manager_a10.h>
+#include <fdtdec.h>
+
+DECLARE_GLOBAL_DATA_PTR;
+
+static const struct socfpga_reset_manager *reset_manager_base =
+		(void *)SOCFPGA_RSTMGR_ADDRESS;
+
+/*
+ * Assert or de-assert SoCFPGA reset manager reset.
+ */
+void socfpga_per_reset(u32 reset, int set)
+{
+	const void *reg;
+
+	if (RSTMGR_BANK(reset) == 0)
+		reg = &reset_manager_base->mpu_mod_rst;
+	else if (RSTMGR_BANK(reset) == 1)
+		reg = &reset_manager_base->per0_mod_rst;
+	else if (RSTMGR_BANK(reset) == 2)
+		reg = &reset_manager_base->per1_mod_rst;
+	else if (RSTMGR_BANK(reset) == 3)
+		reg = &reset_manager_base->brg_mod_rst;
+	else if (RSTMGR_BANK(reset) == 4)
+		reg = &reset_manager_base->sys_mod_rst;
+	else    /* Invalid reset register, do nothing */
+		return;
+
+	if (set)
+		setbits_le32(reg, 1 << RSTMGR_RESET(reset));
+	else
+		clrbits_le32(reg, 1 << RSTMGR_RESET(reset));
+}
+
+/*
+ * Write the reset manager register to cause reset.
+ */
+void reset_cpu(ulong addr)
+{
+	/* request a warm reset */
+	writel(ALT_RSTMGR_CTL_SWWARMRSTREQ_SET_MSK,
+	       &reset_manager_base->ctrl);
+	/*
+	 * infinite loop here as watchdog will trigger and reset
+	 * the processor
+	 */
+	while (1)
+		;
+}
+
+/*
+ * Disable all the peripherals except L4 watchdog0 and L4 Timer 0.
+ */
+void reset_assert_all_peripherals_except_l4wd0_l4timer0(void)
+{
+	unsigned mask_ecc_ocp =
+		ALT_RSTMGR_PER0MODRST_EMACECC0_SET_MSK |
+		ALT_RSTMGR_PER0MODRST_EMACECC1_SET_MSK |
+		ALT_RSTMGR_PER0MODRST_EMACECC2_SET_MSK |
+		ALT_RSTMGR_PER0MODRST_USBECC0_SET_MSK |
+		ALT_RSTMGR_PER0MODRST_USBECC1_SET_MSK |
+		ALT_RSTMGR_PER0MODRST_NANDECC_SET_MSK |
+		ALT_RSTMGR_PER0MODRST_QSPIECC_SET_MSK |
+		ALT_RSTMGR_PER0MODRST_SDMMCECC_SET_MSK;
+
+	/* disable all components except ECC_OCP, L4 Timer0 and L4 WD0 */
+	writel(~(ALT_RSTMGR_PER1MODRST_WD0_SET_MSK |
+	       ALT_RSTMGR_PER1MODRST_L4SYSTMR0_SET_MSK),
+	       &reset_manager_base->per1_mod_rst);
+	setbits_le32(&reset_manager_base->per0_mod_rst, ~mask_ecc_ocp);
+
+	/* Finally disable the ECC_OCP */
+	setbits_le32(&reset_manager_base->per0_mod_rst, mask_ecc_ocp);
+}
diff --git a/arch/arm/mach-socfpga/include/mach/reset_manager_a10.h b/arch/arm/mach-socfpga/include/mach/reset_manager_a10.h
new file mode 100644
index 0000000..3075abf
--- /dev/null
+++ b/arch/arm/mach-socfpga/include/mach/reset_manager_a10.h
@@ -0,0 +1,162 @@
+/*
+ * Copyright (C) 2014 Altera Corporation <www.altera.com>
+ *
+ * SPDX-License-Identifier:	GPL-2.0+
+ */
+
+#ifndef	_SOCFPGA_RESET_MANAGER_A10_H_
+#define	_SOCFPGA_RESET_MANAGER_A10_H_
+
+#ifndef __ASSEMBLY__
+void reset_assert_all_peripherals_except_l4wd0_l4timer0(void);
+void socfpga_per_reset(u32 reset, int set);
+#endif /* __ASSEMBLY__ */
+
+struct socfpga_reset_manager {
+	u32 stat;
+	u32 ramstat;
+	u32 miscstat;
+	u32 ctrl;
+	u32 hdsken;
+	u32 hdskreq;
+	u32 hdskack;
+	u32 counts;
+	u32 mpu_mod_rst;
+	u32 per0_mod_rst;
+	u32 per1_mod_rst;
+	u32 brg_mod_rst;
+	u32 sys_mod_rst;
+	u32 coldmodrst;
+	u32 nrstmodrst;
+	u32 dbgmodrst;
+	u32 mpuwarmmask;
+	u32 per0warmmask;
+	u32 per1warmmask;
+	u32 brgwarmmask;
+	u32 syswarmmask;
+	u32 nrstwarmmask;
+	u32 l3warmmask;
+	u32 tststa;
+	u32 tstscratch;
+	u32 hdsktimeout;
+	u32 hmcintr;
+	u32 hmcintren;
+	u32 hmcintrens;
+	u32 hmcintrenr;
+	u32 hmcgpout;
+	u32 hmcgpin;
+};
+
+#define ALT_RSTMGR_CTL_SWWARMRSTREQ_SET_MSK	0x00000002
+#define ALT_RSTMGR_PER0MODRST_EMAC0_SET_MSK	0x00000001
+#define ALT_RSTMGR_PER0MODRST_EMAC1_SET_MSK	0x00000002
+#define ALT_RSTMGR_PER0MODRST_EMAC2_SET_MSK	0x00000004
+#define ALT_RSTMGR_PER0MODRST_USB0_SET_MSK	0x00000008
+#define ALT_RSTMGR_PER0MODRST_USB1_SET_MSK	0x00000010
+#define ALT_RSTMGR_PER0MODRST_NAND_SET_MSK	0x00000020
+#define ALT_RSTMGR_PER0MODRST_QSPI_SET_MSK	0x00000040
+#define ALT_RSTMGR_PER0MODRST_SDMMC_SET_MSK	0x00000080
+#define ALT_RSTMGR_PER0MODRST_EMACECC0_SET_MSK	0x00000100
+#define ALT_RSTMGR_PER0MODRST_EMACECC1_SET_MSK	0x00000200
+#define ALT_RSTMGR_PER0MODRST_EMACECC2_SET_MSK	0x00000400
+#define ALT_RSTMGR_PER0MODRST_USBECC0_SET_MSK	0x00000800
+#define ALT_RSTMGR_PER0MODRST_USBECC1_SET_MSK	0x00001000
+#define ALT_RSTMGR_PER0MODRST_NANDECC_SET_MSK	0x00002000
+#define ALT_RSTMGR_PER0MODRST_QSPIECC_SET_MSK	0x00004000
+#define ALT_RSTMGR_PER0MODRST_SDMMCECC_SET_MSK	0x00008000
+#define ALT_RSTMGR_PER0MODRST_DMA_SET_MSK	0x00010000
+#define ALT_RSTMGR_PER0MODRST_SPIM0_SET_MSK	0x00020000
+#define ALT_RSTMGR_PER0MODRST_SPIM1_SET_MSK	0x00040000
+#define ALT_RSTMGR_PER0MODRST_SPIS0_SET_MSK	0x00080000
+#define ALT_RSTMGR_PER0MODRST_SPIS1_SET_MSK	0x00100000
+#define ALT_RSTMGR_PER0MODRST_DMAECC_SET_MSK	0x00200000
+#define ALT_RSTMGR_PER0MODRST_EMACPTP_SET_MSK	0x00400000
+#define ALT_RSTMGR_PER0MODRST_DMAIF0_SET_MSK	0x01000000
+#define ALT_RSTMGR_PER0MODRST_DMAIF1_SET_MSK	0x02000000
+#define ALT_RSTMGR_PER0MODRST_DMAIF2_SET_MSK	0x04000000
+#define ALT_RSTMGR_PER0MODRST_DMAIF3_SET_MSK	0x08000000
+#define ALT_RSTMGR_PER0MODRST_DMAIF4_SET_MSK	0x10000000
+#define ALT_RSTMGR_PER0MODRST_DMAIF5_SET_MSK	0x20000000
+#define ALT_RSTMGR_PER0MODRST_DMAIF6_SET_MSK	0x40000000
+#define ALT_RSTMGR_PER0MODRST_DMAIF7_SET_MSK	0x80000000
+
+#define ALT_RSTMGR_PER1MODRST_WD0_SET_MSK	0x00000001
+#define ALT_RSTMGR_PER1MODRST_WD1_SET_MSK	0x00000002
+#define ALT_RSTMGR_PER1MODRST_L4SYSTMR0_SET_MSK	0x00000004
+#define ALT_RSTMGR_PER1MODRST_L4SYSTMR1_SET_MSK	0x00000008
+#define ALT_RSTMGR_PER1MODRST_SPTMR0_SET_MSK	0x00000010
+#define ALT_RSTMGR_PER1MODRST_SPTMR1_SET_MSK	0x00000020
+#define ALT_RSTMGR_PER1MODRST_I2C0_SET_MSK	0x00000100
+#define ALT_RSTMGR_PER1MODRST_I2C1_SET_MSK	0x00000200
+#define ALT_RSTMGR_PER1MODRST_I2C2_SET_MSK	0x00000400
+#define ALT_RSTMGR_PER1MODRST_I2C3_SET_MSK	0x00000800
+#define ALT_RSTMGR_PER1MODRST_I2C4_SET_MSK	0x00001000
+#define ALT_RSTMGR_PER1MODRST_UART0_SET_MSK	0x00010000
+#define ALT_RSTMGR_PER1MODRST_UART1_SET_MSK	0x00020000
+#define ALT_RSTMGR_PER1MODRST_GPIO0_SET_MSK	0x01000000
+#define ALT_RSTMGR_PER1MODRST_GPIO1_SET_MSK	0x02000000
+#define ALT_RSTMGR_PER1MODRST_GPIO2_SET_MSK	0x04000000
+
+#define ALT_RSTMGR_BRGMODRST_H2F_SET_MSK	0x00000001
+#define ALT_RSTMGR_BRGMODRST_LWH2F_SET_MSK	0x00000002
+#define ALT_RSTMGR_BRGMODRST_F2H_SET_MSK	0x00000004
+#define ALT_RSTMGR_BRGMODRST_F2SSDRAM0_SET_MSK	0x00000008
+#define ALT_RSTMGR_BRGMODRST_F2SSDRAM1_SET_MSK	0x00000010
+#define ALT_RSTMGR_BRGMODRST_F2SSDRAM2_SET_MSK	0x00000020
+#define ALT_RSTMGR_BRGMODRST_DDRSCH_SET_MSK	0x00000040
+
+#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)
+
+/* Extract reset ID from the reset identifier. */
+#define RSTMGR_RESET(_reset)			\
+	(((_reset) >> RSTMGR_RESET_OFFSET) & RSTMGR_RESET_MASK)
+
+/* Extract bank ID from the reset identifier. */
+#define RSTMGR_BANK(_reset)			\
+(((_reset) >> RSTMGR_BANK_OFFSET) & RSTMGR_BANK_MASK)
+
+/*
+ * SocFPGA Cyclone V/Arria V reset IDs, bank mapping is as follows:
+ * 0 ... mpumodrst
+ * 1 ... per0modrst
+ * 2 ... per1modrst
+ * 3 ... brgmodrst
+ * 4 ... sysmodrst
+ */
+#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_ */
-- 
2.6.2

[U-Boot] [PATCH 03/10] ARM: socfpga: arria10: add reset manager for Arria10

[Marek Vasut]

On Thursday, November 19, 2015 at 10:35:40 PM, dinguyen at opensource.altera.com 
wrote:
> From: Dinh Nguyen <dinguyen@opensource.altera.com>
> 
> Add the defines for the reset manager and some basic reset functionality.
> 
> Signed-off-by: Dinh Nguyen <dinguyen@opensource.altera.com>
> ---
>  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
> 
> diff --git a/arch/arm/mach-socfpga/arria10/reset_manager_a10.c
> b/arch/arm/mach-socfpga/arria10/reset_manager_a10.c new file mode 100644
> index 0000000..e2d315a
> --- /dev/null
> +++ b/arch/arm/mach-socfpga/arria10/reset_manager_a10.c
> @@ -0,0 +1,83 @@
> +/*
> + * Copyright (C) 2014 Altera Corporation <www.altera.com>
> + *
> + * SPDX-License-Identifier:	GPL-2.0+
> + */
> +
> +#include <common.h>
> +#include <asm/io.h>
> +#include <asm/arch/reset_manager_a10.h>
> +#include <asm/arch/system_manager_a10.h>
> +#include <fdtdec.h>
> +
> +DECLARE_GLOBAL_DATA_PTR;

This whole file looks pretty similar to the CV/AV reset manager, can't we
just merge those two into a single file ?

btw. I dont think you need the DECLARE_GLOBAL_DATA_PTR here.

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

[...]

> +#define ALT_RSTMGR_BRGMODRST_H2F_SET_MSK	0x00000001
> +#define ALT_RSTMGR_BRGMODRST_LWH2F_SET_MSK	0x00000002
> +#define ALT_RSTMGR_BRGMODRST_F2H_SET_MSK	0x00000004
> +#define ALT_RSTMGR_BRGMODRST_F2SSDRAM0_SET_MSK	0x00000008
> +#define ALT_RSTMGR_BRGMODRST_F2SSDRAM1_SET_MSK	0x00000010
> +#define ALT_RSTMGR_BRGMODRST_F2SSDRAM2_SET_MSK	0x00000020
> +#define ALT_RSTMGR_BRGMODRST_DDRSCH_SET_MSK	0x00000040

All these are probably just bits, so please use 1 << n here.

> +#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)
> +
> +/* Extract reset ID from the reset identifier. */
> +#define RSTMGR_RESET(_reset)			\
> +	(((_reset) >> RSTMGR_RESET_OFFSET) & RSTMGR_RESET_MASK)
> +
> +/* Extract bank ID from the reset identifier. */
> +#define RSTMGR_BANK(_reset)			\
> +(((_reset) >> RSTMGR_BANK_OFFSET) & RSTMGR_BANK_MASK)
> +
> +/*
> + * SocFPGA Cyclone V/Arria V reset IDs, bank mapping is as follows:

Oh yeah ? Looks arria10-ish to me :-)

> + * 0 ... mpumodrst
> + * 1 ... per0modrst
> + * 2 ... per1modrst
> + * 3 ... brgmodrst
> + * 4 ... sysmodrst
> + */
> +#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_ */

[U-Boot] [PATCH 04/10] ARM: socfpga: arria10: add stub sdram init for Arria10

[dinguyen at opensource.altera.com]

From: Dinh Nguyen <dinguyen@opensource.altera.com>

For now, sdram_a10.c will only have sdram_init() function, but this
will get populated in the near future with more functionality.

Also add the structures for the SDRAM controller on Arria10.

Signed-off-by: Dinh Nguyen <dinguyen@opensource.altera.com>
---
 arch/arm/mach-socfpga/arria10/sdram_a10.c      |  15 +
 arch/arm/mach-socfpga/include/mach/sdram_a10.h | 371 +++++++++++++++++++++++++
 2 files changed, 386 insertions(+)
 create mode 100644 arch/arm/mach-socfpga/arria10/sdram_a10.c
 create mode 100644 arch/arm/mach-socfpga/include/mach/sdram_a10.h

diff --git a/arch/arm/mach-socfpga/arria10/sdram_a10.c b/arch/arm/mach-socfpga/arria10/sdram_a10.c
new file mode 100644
index 0000000..2b99b0f
--- /dev/null
+++ b/arch/arm/mach-socfpga/arria10/sdram_a10.c
@@ -0,0 +1,15 @@
+/*
+ * Copyright (C) 2014 Altera Corporation <www.altera.com>
+ *
+ * SPDX-License-Identifier:	GPL-2.0+
+ */
+
+#include <common.h>
+
+DECLARE_GLOBAL_DATA_PTR;
+
+/* Initialise the DRAM by telling the DRAM Size */
+int dram_init(void)
+{
+	return 0;
+}
diff --git a/arch/arm/mach-socfpga/include/mach/sdram_a10.h b/arch/arm/mach-socfpga/include/mach/sdram_a10.h
new file mode 100644
index 0000000..5799c47
--- /dev/null
+++ b/arch/arm/mach-socfpga/include/mach/sdram_a10.h
@@ -0,0 +1,371 @@
+/*
+ * Copyright (C) 2014 Altera Corporation <www.altera.com>
+ *
+ * SPDX-License-Identifier:	GPL-2.0+
+ */
+
+#ifndef	_SOCFPGA_SDRAM_A10_H_
+#define	_SOCFPGA_SDRAM_A10_H_
+
+#ifndef __ASSEMBLY__
+
+struct socfpga_ecc_hmc {
+	u32 ip_rev_id;
+	u32 _pad_0x4_0x7;
+	u32 ddrioctrl;
+	u32 ddrcalstat;
+	u32 mpr_0beat1;
+	u32 mpr_1beat1;
+	u32 mpr_2beat1;
+	u32 mpr_3beat1;
+	u32 mpr_4beat1;
+	u32 mpr_5beat1;
+	u32 mpr_6beat1;
+	u32 mpr_7beat1;
+	u32 mpr_8beat1;
+	u32 mpr_0beat2;
+	u32 mpr_1beat2;
+	u32 mpr_2beat2;
+	u32 mpr_3beat2;
+	u32 mpr_4beat2;
+	u32 mpr_5beat2;
+	u32 mpr_6beat2;
+	u32 mpr_7beat2;
+	u32 mpr_8beat2;
+	u32 _pad_0x58_0x5f[2];
+	u32 auto_precharge;
+	u32 _pad_0x64_0xff[39];
+	u32 eccctrl;
+	u32 eccctrl2;
+	u32 _pad_0x108_0x10f[2];
+	u32 errinten;
+	u32 errintens;
+	u32 errintenr;
+	u32 intmode;
+	u32 intstat;
+	u32 diaginttest;
+	u32 modstat;
+	u32 derraddra;
+	u32 serraddra;
+	u32 _pad_0x134_0x137;
+	u32 autowb_corraddr;
+	u32 serrcntreg;
+	u32 autowb_drop_cntreg;
+	u32 _pad_0x144_0x147;
+	u32 ecc_reg2wreccdatabus;
+	u32 ecc_rdeccdata2regbus;
+	u32 ecc_reg2rdeccdatabus;
+	u32 _pad_0x154_0x15f[3];
+	u32 ecc_diagon;
+	u32 ecc_decstat;
+	u32 _pad_0x168_0x16f[2];
+	u32 ecc_errgenaddr_0;
+	u32 ecc_errgenaddr_1;
+	u32 ecc_errgenaddr_2;
+	u32 ecc_errgenaddr_3;
+};
+
+struct socfpga_noc_ddr_scheduler {
+	u32 ddr_t_main_scheduler_id_coreid;
+	u32 ddr_t_main_scheduler_id_revisionid;
+	u32 ddr_t_main_scheduler_ddrconf;
+	u32 ddr_t_main_scheduler_ddrtiming;
+	u32 ddr_t_main_scheduler_ddrmode;
+	u32 ddr_t_main_scheduler_readlatency;
+	u32 _pad_0x20_0x34[8];
+	u32 ddr_t_main_scheduler_activate;
+	u32 ddr_t_main_scheduler_devtodev;
+};
+
+/*
+ * OCRAM firewall
+ */
+struct socfpga_noc_fw_ocram {
+	u32 enable;
+	u32 enable_set;
+	u32 enable_clear;
+	u32 region0;
+	u32 region1;
+	u32 region2;
+	u32 region3;
+	u32 region4;
+	u32 region5;
+};
+
+/* for master such as MPU and FPGA */
+struct socfpga_noc_fw_ddr_mpu_fpga2sdram {
+	u32 enable;
+	u32 enable_set;
+	u32 enable_clear;
+	u32 _pad_0xc_0xf;
+	u32 mpuregion0addr;
+	u32 mpuregion1addr;
+	u32 mpuregion2addr;
+	u32 mpuregion3addr;
+	u32 fpga2sdram0region0addr;
+	u32 fpga2sdram0region1addr;
+	u32 fpga2sdram0region2addr;
+	u32 fpga2sdram0region3addr;
+	u32 fpga2sdram1region0addr;
+	u32 fpga2sdram1region1addr;
+	u32 fpga2sdram1region2addr;
+	u32 fpga2sdram1region3addr;
+	u32 fpga2sdram2region0addr;
+	u32 fpga2sdram2region1addr;
+	u32 fpga2sdram2region2addr;
+	u32 fpga2sdram2region3addr;
+};
+
+/* for L3 master */
+struct socfpga_noc_fw_ddr_l3 {
+	u32 enable;
+	u32 enable_set;
+	u32 enable_clear;
+	u32 hpsregion0addr;
+	u32 hpsregion1addr;
+	u32 hpsregion2addr;
+	u32 hpsregion3addr;
+	u32 hpsregion4addr;
+	u32 hpsregion5addr;
+	u32 hpsregion6addr;
+	u32 hpsregion7addr;
+};
+
+struct socfpga_io48_mmr {
+	u32 dbgcfg0;
+	u32 dbgcfg1;
+	u32 dbgcfg2;
+	u32 dbgcfg3;
+	u32 dbgcfg4;
+	u32 dbgcfg5;
+	u32 dbgcfg6;
+	u32 reserve0;
+	u32 reserve1;
+	u32 reserve2;
+	u32 ctrlcfg0;
+	u32 ctrlcfg1;
+	u32 ctrlcfg2;
+	u32 ctrlcfg3;
+	u32 ctrlcfg4;
+	u32 ctrlcfg5;
+	u32 ctrlcfg6;
+	u32 ctrlcfg7;
+	u32 ctrlcfg8;
+	u32 ctrlcfg9;
+	u32 dramtiming0;
+	u32 dramodt0;
+	u32 dramodt1;
+	u32 sbcfg0;
+	u32 sbcfg1;
+	u32 sbcfg2;
+	u32 sbcfg3;
+	u32 sbcfg4;
+	u32 sbcfg5;
+	u32 sbcfg6;
+	u32 sbcfg7;
+	u32 caltiming0;
+	u32 caltiming1;
+	u32 caltiming2;
+	u32 caltiming3;
+	u32 caltiming4;
+	u32 caltiming5;
+	u32 caltiming6;
+	u32 caltiming7;
+	u32 caltiming8;
+	u32 caltiming9;
+	u32 caltiming10;
+	u32 dramaddrw;
+	u32 sideband0;
+	u32 sideband1;
+	u32 sideband2;
+	u32 sideband3;
+	u32 sideband4;
+	u32 sideband5;
+	u32 sideband6;
+	u32 sideband7;
+	u32 sideband8;
+	u32 sideband9;
+	u32 sideband10;
+	u32 sideband11;
+	u32 sideband12;
+	u32 sideband13;
+	u32 sideband14;
+	u32 sideband15;
+	u32 dramsts;
+	u32 dbgdone;
+	u32 dbgsignals;
+	u32 dbgreset;
+	u32 dbgmatch;
+	u32 counter0mask;
+	u32 counter1mask;
+	u32 counter0match;
+	u32 counter1match;
+	u32 niosreserve0;
+	u32 niosreserve1;
+	u32 niosreserve2;
+};
+
+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;
+};
+
+union ctrlcfg0_reg {
+	struct {
+		u32 cfg_mem_type:4;
+		u32 cfg_dimm_type:3;
+		u32 cfg_ac_pos:2;
+		u32 cfg_ctrl_burst_len:5;
+		u32 reserved:18;	/* Other fields unused */
+	};
+	u32 word;
+};
+
+union ctrlcfg1_reg {
+	struct {
+		u32 cfg_dbc3_burst_len:5;
+		u32 cfg_addr_order:2;
+		u32 cfg_ctrl_enable_ecc:1;
+		u32 reserved:24;	/* Other fields unused */
+	};
+	u32 word;
+};
+
+union caltiming0_reg {
+	struct {
+		u32 cfg_act_to_rdwr:6;
+		u32 cfg_act_to_pch:6;
+		u32 cfg_act_to_act:6;
+		u32 cfg_act_to_act_db:6;
+		u32 reserved:8;	/* Other fields unused */
+	};
+	u32 word;
+};
+
+union caltiming1_reg {
+	struct {
+		u32 cfg_rd_to_rd:6;
+		u32 cfg_rd_to_rd_dc:6;
+		u32 cfg_rd_to_rd_db:6;
+		u32 cfg_rd_to_wr:6;
+		u32 cfg_rd_to_wr_dc:6;
+		u32 reserved:2;
+	};
+	u32 word;
+};
+
+union caltiming2_reg {
+	struct {
+		u32 cfg_rd_to_wr_db:6;
+		u32 cfg_rd_to_pch:6;
+		u32 cfg_rd_ap_to_valid:6;
+		u32 cfg_wr_to_wr:6;
+		u32 cfg_wr_to_wr_dc:6;
+		u32 reserved:2;
+	};
+	u32 word;
+};
+
+union caltiming3_reg {
+	struct {
+		u32 cfg_wr_to_wr_db:6;
+		u32 cfg_wr_to_rd:6;
+		u32 cfg_wr_to_rd_dc:6;
+		u32 cfg_wr_to_rd_db:6;
+		u32 cfg_wr_to_pch:6;
+		u32 reserved:2;
+	};
+	u32 word;
+};
+
+union caltiming4_reg {
+	struct {
+		u32 cfg_wr_ap_to_valid:6;
+		u32 cfg_pch_to_valid:6;
+		u32 cfg_pch_all_to_valid:6;
+		u32 cfg_arf_to_valid:8;
+		u32 cfg_pdn_to_valid:6;
+	};
+	u32 word;
+};
+
+union caltiming9_reg {
+	struct {
+		u32 cfg_4_act_to_act:8;
+		u32 reserved:24;
+	};
+	u32 word;
+};
+
+#endif /* __ASSEMBLY__ */
+
+#define ALT_ECC_HMC_OCP_DDRIOCTRL_IO_SIZE_MSK		0x00000003
+
+#define ALT_ECC_HMC_OCP_INTSTAT_SERRPENA_SET_MSK	0x00000001
+#define ALT_ECC_HMC_OCP_INTSTAT_DERRPENA_SET_MSK	0x00000002
+#define ALT_ECC_HMC_OCP_ERRINTEN_SERRINTEN_SET_MSK	0x00000001
+#define ALT_ECC_HMC_OCP_ERRINTEN_DERRINTEN_SET_MSK	0x00000002
+#define ALT_ECC_HMC_OCP_INTMOD_INTONCMP_SET_MSK		0x00010000
+#define ALT_ECC_HMC_OCP_ECCCTL_AWB_CNT_RST_SET_MSK	0x00010000
+#define ALT_ECC_HMC_OCP_ECCCTL_CNT_RST_SET_MSK		0x00000100
+#define ALT_ECC_HMC_OCP_ECCCTL_ECC_EN_SET_MSK		0x00000001
+#define ALT_ECC_HMC_OCP_ECCCTL2_RMW_EN_SET_MSK		0x00000100
+#define ALT_ECC_HMC_OCP_ECCCTL2_AWB_EN_SET_MSK		0x00000001
+
+#define ALT_ECC_HMC_OCP_SERRCNTREG_VALUE		8
+
+#define ALT_NOC_MPU_DDR_T_SCHED_DDRTIMING_ACTTOACT_LSB	0
+#define ALT_NOC_MPU_DDR_T_SCHED_DDRTIMING_RDTOMISS_LSB	6
+#define ALT_NOC_MPU_DDR_T_SCHED_DDRTIMING_WRTOMISS_LSB	12
+#define ALT_NOC_MPU_DDR_T_SCHED_DDRTIMING_BURSTLEN_LSB	18
+#define ALT_NOC_MPU_DDR_T_SCHED_DDRTIMING_RDTOWR_LSB	21
+#define ALT_NOC_MPU_DDR_T_SCHED_DDRTIMING_WRTORD_LSB	26
+#define ALT_NOC_MPU_DDR_T_SCHED_DDRTIMING_BWRATIO_LSB	31
+
+#define ALT_NOC_MPU_DDR_T_SCHED_DDRMOD_AUTOPRECHARGE_LSB	0
+#define ALT_NOC_MPU_DDR_T_SCHED_DDRMOD_BWRATIOEXTENDED_LSB	1
+
+#define ALT_NOC_MPU_DDR_T_SCHED_ACTIVATE_RRD_LSB	0
+#define ALT_NOC_MPU_DDR_T_SCHED_ACTIVATE_FAW_LSB	4
+#define ALT_NOC_MPU_DDR_T_SCHED_ACTIVATE_FAWBANK_LSB	10
+
+#define ALT_NOC_MPU_DDR_T_SCHED_DEVTODEV_BUSRDTORD_LSB	0
+#define ALT_NOC_MPU_DDR_T_SCHED_DEVTODEV_BUSRDTOWR_LSB	2
+#define ALT_NOC_MPU_DDR_T_SCHED_DEVTODEV_BUSWRTORD_LSB	4
+
+#define ALT_NOC_FW_DDR_END_ADDR_LSB	16
+#define ALT_NOC_FW_DDR_ADDR_MASK	0xFFFF
+#define ALT_NOC_FW_DDR_SCR_EN_HPSREG0EN_SET_MSK		0x00000001
+#define ALT_NOC_FW_DDR_SCR_EN_HPSREG1EN_SET_MSK		0x00000002
+#define ALT_NOC_FW_DDR_SCR_EN_HPSREG2EN_SET_MSK		0x00000004
+#define ALT_NOC_FW_DDR_SCR_EN_HPSREG3EN_SET_MSK		0x00000008
+#define ALT_NOC_FW_DDR_SCR_EN_HPSREG4EN_SET_MSK		0x00000010
+#define ALT_NOC_FW_DDR_SCR_EN_HPSREG5EN_SET_MSK		0x00000020
+#define ALT_NOC_FW_DDR_SCR_EN_HPSREG6EN_SET_MSK		0x00000040
+#define ALT_NOC_FW_DDR_SCR_EN_HPSREG7EN_SET_MSK		0x00000080
+#define ALT_NOC_FW_DDR_SCR_EN_MPUREG0EN_SET_MSK		0x00000001
+#define ALT_NOC_FW_DDR_SCR_EN_MPUREG1EN_SET_MSK		0x00000002
+#define ALT_NOC_FW_DDR_SCR_EN_MPUREG2EN_SET_MSK		0x00000004
+#define ALT_NOC_FW_DDR_SCR_EN_MPUREG3EN_SET_MSK		0x00000008
+#define ALT_NOC_FW_DDR_SCR_EN_F2SDR0REG0EN_SET_MSK	0x00000010
+#define ALT_NOC_FW_DDR_SCR_EN_F2SDR0REG1EN_SET_MSK	0x00000020
+#define ALT_NOC_FW_DDR_SCR_EN_F2SDR0REG2EN_SET_MSK	0x00000040
+#define ALT_NOC_FW_DDR_SCR_EN_F2SDR0REG3EN_SET_MSK	0x00000080
+#define ALT_NOC_FW_DDR_SCR_EN_F2SDR1REG0EN_SET_MSK	0x00000100
+#define ALT_NOC_FW_DDR_SCR_EN_F2SDR1REG1EN_SET_MSK	0x00000200
+#define ALT_NOC_FW_DDR_SCR_EN_F2SDR1REG2EN_SET_MSK	0x00000400
+#define ALT_NOC_FW_DDR_SCR_EN_F2SDR1REG3EN_SET_MSK	0x00000800
+#define ALT_NOC_FW_DDR_SCR_EN_F2SDR2REG0EN_SET_MSK	0x00001000
+#define ALT_NOC_FW_DDR_SCR_EN_F2SDR2REG1EN_SET_MSK	0x00002000
+#define ALT_NOC_FW_DDR_SCR_EN_F2SDR2REG2EN_SET_MSK	0x00004000
+#define ALT_NOC_FW_DDR_SCR_EN_F2SDR2REG3EN_SET_MSK	0x00008000
+
+#define ALT_IO48_DRAMTIME_MEM_READ_LATENCY_MASK		0x0000003F
+#endif /* _SOCFPGA_SDRAM_A10_H_ */
-- 
2.6.2

[U-Boot] [PATCH 04/10] ARM: socfpga: arria10: add stub sdram init for Arria10

[Pavel Machek]

Hi!

> +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?
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[U-Boot] [PATCH 04/10] ARM: socfpga: arria10: add stub sdram init for Arria10

[Marek Vasut]

On Monday, November 23, 2015 at 01:25:39 PM, Pavel Machek wrote:
> Hi!
> 
> > +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?

GCC won't do anything, but I cannot say I'm a big fan of those bitfields.
Let's just drop them and use the BIT() macro.

Best regards,
Marek Vasut

[U-Boot] [PATCH 05/10] ARM: socfpga: arria10: add misc functions for Arria10

[dinguyen at opensource.altera.com]

From: Dinh Nguyen <dinguyen@opensource.altera.com>

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 <dinguyen@opensource.altera.com>
---
 arch/arm/mach-socfpga/arria10/misc_a10.c | 138 +++++++++++++++++++++++++++++++
 1 file changed, 138 insertions(+)
 create mode 100644 arch/arm/mach-socfpga/arria10/misc_a10.c

diff --git a/arch/arm/mach-socfpga/arria10/misc_a10.c b/arch/arm/mach-socfpga/arria10/misc_a10.c
new file mode 100644
index 0000000..f245bae
--- /dev/null
+++ b/arch/arm/mach-socfpga/arria10/misc_a10.c
@@ -0,0 +1,138 @@
+/*
+ * Copyright (C) 2014 Altera Corporation <www.altera.com>
+ *
+ * SPDX-License-Identifier:	GPL-2.0+
+ */
+
+#include <common.h>
+#include <asm/io.h>
+#include <asm/arch/reset_manager_a10.h>
+#include <asm/arch/sdram_a10.h>
+#include <asm/arch/dwmmc.h>
+#include <asm/pl310.h>
+#include <altera.h>
+#include <dwmmc.h>
+#include <fpga.h>
+#include <mmc.h>
+
+DECLARE_GLOBAL_DATA_PTR;
+
+static const struct pl310_regs *pl310_regs_base = (void *)CONFIG_SYS_PL310_BASE;
+static const struct socfpga_noc_fw_ocram *noc_fw_ocram_base =
+		(void *)SOCFPGA_SDR_FIREWALL_OCRAM_ADDRESS;
+static const struct socfpga_noc_fw_ddr_l3 *noc_fw_ddr_l3_base =
+		(void *)SOCFPGA_SDR_FIREWALL_L3_ADDRESS;
+
+/* FPGA programming support for SoC FPGA Arria 10 */
+static Altera_desc altera_fpga[] = {
+	{
+		/* Family */
+		Altera_SoCFPGA,
+		/* Interface type */
+		fast_passive_parallel,
+		/* No limitation as additional data will be ignored */
+		-1,
+		/* No device function table */
+		NULL,
+		/* Base interface address specified in driver */
+		NULL,
+		/* No cookie implementation */
+		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);
+}
+
+/*
+ * This function initializes security policies to be consistent across
+ * all logic units in the Arria 10.
+ *
+ * The idea is to set all security policies to be normal, nonsecure
+ * for all units.
+ */
+static void initialize_security_policies(void)
+{
+	/* Put OCRAM in non-secure */
+	writel(0x003f0000, &noc_fw_ocram_base->region0);
+	writel(0x1, &noc_fw_ocram_base->enable);
+
+	/* Put DDR in non-secure */
+	writel(0xffff0000, &noc_fw_ddr_l3_base->hpsregion0addr);
+	writel(0x1, &noc_fw_ddr_l3_base->enable);
+}
+
+int arch_early_init_r(void)
+{
+	initialize_security_policies();
+
+	/* Configure the L2 controller to make SDRAM start at 0 */
+	writel(0x1, &pl310_regs_base->pl310_addr_filter_start);
+
+	/* assert reset to all except L4WD0 and L4TIMER0 */
+	reset_assert_all_peripherals_except_l4wd0_l4timer0();
+
+	/* configuring the clock based on handoff */
+	/* TODO: Add call to cm_basic_init() */
+
+	/* Add device descriptor to FPGA device table */
+	socfpga_fpga_add();
+	return 0;
+}
+
+/*
+ * Print CPU information
+ */
+#if defined(CONFIG_DISPLAY_CPUINFO)
+int print_cpuinfo(void)
+{
+	puts("CPU   : Altera SOCFPGA Arria 10 Platform\n");
+	return 0;
+}
+#endif
+
+#if defined(CONFIG_SYS_CONSOLE_IS_IN_ENV) && \
+defined(CONFIG_SYS_CONSOLE_OVERWRITE_ROUTINE)
+int overwrite_console(void)
+{
+	return 0;
+}
+#endif
+
+#ifdef CONFIG_DWMMC
+/*
+ * Initializes MMC controllers.
+ * to override, implement board_mmc_init()
+ */
+int cpu_mmc_init(bd_t *bis)
+{
+	return socfpga_dwmmc_init(gd->fdt_blob);
+}
+#endif
+
+void enable_caches(void)
+{
+#ifndef CONFIG_SYS_ICACHE_OFF
+	icache_enable();
+#endif
+#ifndef CONFIG_SYS_DCACHE_OFF
+	dcache_enable();
+#endif
+}
-- 
2.6.2

[U-Boot] [PATCH 05/10] ARM: socfpga: arria10: add misc functions for Arria10

[Marek Vasut]

On Thursday, November 19, 2015 at 10:35:42 PM, dinguyen at opensource.altera.com 
wrote:
> From: Dinh Nguyen <dinguyen@opensource.altera.com>
> 
> 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 <dinguyen@opensource.altera.com>
> ---

Hi!

[..]

> +/* FPGA programming support for SoC FPGA Arria 10 */
> +static Altera_desc altera_fpga[] = {
> +	{
> +		/* Family */
> +		Altera_SoCFPGA,
> +		/* Interface type */
> +		fast_passive_parallel,
> +		/* No limitation as additional data will be ignored */
> +		-1,
> +		/* No device function table */
> +		NULL,
> +		/* Base interface address specified in driver */
> +		NULL,
> +		/* No cookie implementation */
> +		0
> +	},
> +};

Looks like AV/CV misc.c , so we should definitelly make this into common code.

> +/* 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);
> +}

[...]

> +#ifdef CONFIG_DWMMC
> +/*
> + * Initializes MMC controllers.
> + * to override, implement board_mmc_init()
> + */
> +int cpu_mmc_init(bd_t *bis)
> +{
> +	return socfpga_dwmmc_init(gd->fdt_blob);
> +}
> +#endif

This part needs fixing for Cyclone V / Arria V and also for Arria 10. The DWMMC
should probe from DT automatically and this bit should not be needed at all. The
socfpga_dwmmc_init() function should also be removed from the socfpga dwmmc shim
in drivers/mmc/ .

[U-Boot] [PATCH 06/10] ARM: socfpga: arria10: add socfpga_arria10_socdk config

[dinguyen at opensource.altera.com]

From: Dinh Nguyen <dinguyen@opensource.altera.com>

Add config for the Arria10 SoC Development Kit.

Signed-off-by: Dinh Nguyen <dinguyen@opensource.altera.com>
---
 include/configs/socfpga_arria10_socdk.h | 292 ++++++++++++++++++++++++++++++++
 1 file changed, 292 insertions(+)
 create mode 100644 include/configs/socfpga_arria10_socdk.h

diff --git a/include/configs/socfpga_arria10_socdk.h b/include/configs/socfpga_arria10_socdk.h
new file mode 100644
index 0000000..68aa736
--- /dev/null
+++ b/include/configs/socfpga_arria10_socdk.h
@@ -0,0 +1,292 @@
+/*
+ *  Copyright (C) 2014 Altera Corporation <www.altera.com>
+ *
+ * SPDX-License-Identifier:	GPL-2.0+
+ */
+
+#ifndef __CONFIG_SOCFGPA_ARRIA10_H__
+#define __CONFIG_SOCFGPA_ARRIA10_H__
+
+#include <asm/arch/socfpga_a10_base_addrs.h>
+/* U-Boot Commands */
+#define CONFIG_SYS_NO_FLASH
+#define CONFIG_DOS_PARTITION
+#define CONFIG_FAT_WRITE
+#define CONFIG_HW_WATCHDOG
+
+#define CONFIG_CMD_ASKENV
+#define CONFIG_CMD_BOOTZ
+#define CONFIG_CMD_CACHE
+#define CONFIG_CMD_DHCP
+#define CONFIG_CMD_EXT4
+#define CONFIG_CMD_EXT4_WRITE
+#define CONFIG_CMD_FAT
+#define CONFIG_CMD_FS_GENERIC
+#define CONFIG_CMD_GPIO
+#define CONFIG_CMD_GREPENV
+#define CONFIG_CMD_PING
+
+#define CONFIG_SYS_CACHELINE_SIZE	32
+#define CONFIG_SYS_L2_PL310
+#define CONFIG_SYS_PL310_BASE		SOCFPGA_MPUL2_ADDRESS
+
+#define CONFIG_SYS_TEXT_BASE		0xFFE00000
+/* using linker to check all image sections fit OCRAM */
+#define CONFIG_U_BOOT_BINARY_MAX_SIZE	(200 * 1024)
+
+/*
+ * Stack and malloc setup
+ */
+/* IRQ stack */
+#define CONFIG_STACKSIZE_IRQ		(1 << 10)
+/* FIQ stack */
+#define CONFIG_STACKSIZE_FIQ		(1 << 10)
+/* 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@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
+#define CONFIG_DISPLAY_BOARDINFO
+#define CONFIG_DISPLAY_BOARDINFO_LATE
+
+/*
+ * Kernel Info
+ */
+/* flat device tree */
+#define CONFIG_OF_LIBFDT
+/* skip updating the FDT blob */
+#define CONFIG_FDT_BLOB_SKIP_UPDATE
+/* Initial Memory map size for Linux, minus 4k alignment for DFT blob */
+#define CONFIG_SYS_BOOTMAPSZ		(32 * 1024 * 1024)
+
+/*
+ * Environment setup
+ */
+#define CONFIG_ENV_SIZE			4096
+#define CONFIG_BOOTDELAY		5
+#define CONFIG_ENV_OVERWRITE
+#define CONFIG_AUTO_COMPLETE
+#define CONFIG_CMDLINE_EDITING
+#define CONFIG_SYS_LONGHELP
+#define CONFIG_SYS_HUSH_PARSER
+#define CONFIG_SYS_PROMPT_HUSH_PS2	"> "
+
+/*
+ * Can't poll in semihosting; so turn off automatic boot command
+ */
+#define CONFIG_BOOTCOMMAND "run callscript; run mmcload;" \
+	"run set_initswstate; run mmcboot"
+
+/*
+ * arguments passed to the bootz command. The value of
+ * CONFIG_BOOTARGS goes into the environment value "bootargs".
+ * Do note the value will overide also the chosen node in FDT blob.
+ */
+#define CONFIG_BOOTARGS "console=ttyS0," __stringify(CONFIG_BAUDRATE)
+#define CONFIG_SYS_DTB_ADDR 0x100
+#define MAX_DTB_SIZE_IN_RAM 0x7f00
+#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
+
+#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. " \
+			"Continuing to boot normally; " \
+		"fi;\0"
+
+/*
+ * Environment setup
+ */
+#define CONFIG_SYS_CONSOLE_IS_IN_ENV
+#define CONFIG_SYS_CONSOLE_OVERWRITE_ROUTINE
+#define CONFIG_SYS_CONSOLE_ENV_OVERWRITE
+#undef CONFIG_CMD_IMPORTENV
+
+/*
+ * Console setup
+ */
+#define CONFIG_SYS_CBSIZE		256
+#define CONFIG_SYS_PBSIZE		(CONFIG_SYS_CBSIZE + \
+					sizeof(CONFIG_SYS_PROMPT) + 16)
+/* max number of command args */
+#define CONFIG_SYS_MAXARGS		16
+
+/* Boot Argument Buffer Size */
+#define CONFIG_SYS_BARGSIZE		CONFIG_SYS_CBSIZE
+
+/*
+ * 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)
+
+/*
+ * NS16550 Configuration
+ */
+#define CONFIG_SYS_NS16550
+#define CONFIG_SYS_NS16550_SERIAL
+/* always write in 32 bit manner */
+#define CONFIG_SYS_NS16550_MEM32
+#define CONFIG_SYS_NS16550_REG_SIZE	-4
+#define CONFIG_CONS_INDEX               1
+#define CONFIG_SYS_NS16550_COM1		SOCFPGA_UART1_ADDRESS
+#define CONFIG_SYS_NS16550_CLK		10000000
+#define CONFIG_BAUDRATE			115200
+
+/*
+ * L4 OSC1 Timer 0
+ */
+#define CONFIG_SYS_TIMERBASE		SOCFPGA_OSC1TIMER0_ADDRESS
+#define CONFIG_SYS_TIMER_COUNTS_DOWN
+#define CONFIG_SYS_TIMER_COUNTER	(CONFIG_SYS_TIMERBASE + 0x4)
+#define CONFIG_TIMER_CLOCK_HZ		100000000
+#define CONFIG_TIMER_CLOCK_KHZ		(CONFIG_TIMER_CLOCK_HZ/1000)
+#define CONFIG_SYS_TIMER_RATE		100000000
+
+/*
+ * L4 Watchdog
+ */
+#ifdef CONFIG_HW_WATCHDOG
+#define CONFIG_DESIGNWARE_WATCHDOG
+#define CONFIG_DW_WDT_BASE		SOCFPGA_L4WD0_ADDRESS
+#define CONFIG_HW_WATCHDOG_TIMEOUT_MS	2000
+#define CONFIG_DW_WDT_CLOCK_KHZ		25000
+#endif
+
+/*
+ * network support
+ */
+#define CONFIG_DESIGNWARE_ETH
+#ifdef CONFIG_DESIGNWARE_ETH
+#define CONFIG_NET_MULTI
+#define CONFIG_DW_ALTDESCRIPTOR
+#define CONFIG_DW_SEARCH_PHY
+#define CONFIG_PHY_GIGE
+#define CONFIG_DW_AUTONEG
+#define CONFIG_PHYLIB
+#define CONFIG_PHY_MICREL
+/* phy */
+#define CONFIG_EPHY0_PHY_ADDR		7
+#define CONFIG_PHY_MICREL
+#define CONFIG_PHY_MICREL_KSZ9031
+#endif	/* CONFIG_DESIGNWARE_ETH */
+
+
+/*
+ * 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
+#define CONFIG_CMD_MMC
+/* Enable FAT write support */
+#define CONFIG_FAT_WRITE
+
+/* configure a clustsize smaller than the default 64k */
+#define CONFIG_FS_FAT_MAX_CLUSTSIZE 16384
+/* MMC support */
+#define CONFIG_SDMMC_BASE		(SOCFPGA_SDMMC_ADDRESS)
+#define CONFIG_GENERIC_MMC
+#define CONFIG_SYS_MMC_MAX_BLK_COUNT    256
+#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
+#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 */
-- 
2.6.2

[U-Boot] [PATCH 06/10] ARM: socfpga: arria10: add socfpga_arria10_socdk config

[Marek Vasut]

On Thursday, November 19, 2015 at 10:35:43 PM, dinguyen at opensource.altera.com 
wrote:
> From: Dinh Nguyen <dinguyen@opensource.altera.com>
> 
> Add config for the Arria10 SoC Development Kit.
> 
> Signed-off-by: Dinh Nguyen <dinguyen@opensource.altera.com>
> ---
>  include/configs/socfpga_arria10_socdk.h | 292
> ++++++++++++++++++++++++++++++++ 1 file changed, 292 insertions(+)
>  create mode 100644 include/configs/socfpga_arria10_socdk.h

[...]

> +#define CONFIG_SYS_TEXT_BASE		0xFFE00000
> +/* using linker to check all image sections fit OCRAM */
> +#define CONFIG_U_BOOT_BINARY_MAX_SIZE	(200 * 1024)

You mean SPL here ?

> +/*
> + * Stack and malloc setup
> + */
> +/* IRQ stack */
> +#define CONFIG_STACKSIZE_IRQ		(1 << 10)
> +/* FIQ stack */
> +#define CONFIG_STACKSIZE_FIQ		(1 << 10)

Is this needed@all ?

> +/* 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
> +#define CONFIG_DISPLAY_BOARDINFO
> +#define CONFIG_DISPLAY_BOARDINFO_LATE
> +
> +/*
> + * Kernel Info
> + */
> +/* flat device tree */
> +#define CONFIG_OF_LIBFDT
> +/* skip updating the FDT blob */
> +#define CONFIG_FDT_BLOB_SKIP_UPDATE

Why do we need this?

> +/* Initial Memory map size for Linux, minus 4k alignment for DFT blob */
> +#define CONFIG_SYS_BOOTMAPSZ		(32 * 1024 * 1024)
> +
> +/*
> + * Environment setup
> + */
> +#define CONFIG_ENV_SIZE			4096
> +#define CONFIG_BOOTDELAY		5
> +#define CONFIG_ENV_OVERWRITE
> +#define CONFIG_AUTO_COMPLETE
> +#define CONFIG_CMDLINE_EDITING
> +#define CONFIG_SYS_LONGHELP
> +#define CONFIG_SYS_HUSH_PARSER
> +#define CONFIG_SYS_PROMPT_HUSH_PS2	"> "

Looks like this is duplicated from socfpga_common.h , no ? Why don't you just
include socfpga_common.h ?

> +/*
> + * Can't poll in semihosting; so turn off automatic boot command
> + */
> +#define CONFIG_BOOTCOMMAND "run callscript; run mmcload;" \
> +	"run set_initswstate; run mmcboot"
> +
> +/*
> + * arguments passed to the bootz command. The value of
> + * CONFIG_BOOTARGS goes into the environment value "bootargs".
> + * Do note the value will overide also the chosen node in FDT blob.
> + */
> +#define CONFIG_BOOTARGS "console=ttyS0," __stringify(CONFIG_BAUDRATE)
> +#define CONFIG_SYS_DTB_ADDR 0x100
> +#define MAX_DTB_SIZE_IN_RAM 0x7f00

Please don't invent new ad-hoc config options which will permeate the U-Boot
build. Just put these as a variable into the extra environment if needed.

> +#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
> +
> +#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. " \
> +			"Continuing to boot normally; " \
> +		"fi;\0"
> +
> +/*
> + * Environment setup
> + */
> +#define CONFIG_SYS_CONSOLE_IS_IN_ENV
> +#define CONFIG_SYS_CONSOLE_OVERWRITE_ROUTINE
> +#define CONFIG_SYS_CONSOLE_ENV_OVERWRITE
> +#undef CONFIG_CMD_IMPORTENV

Why do you disable env import ?

> +/*
> + * Console setup
> + */
> +#define CONFIG_SYS_CBSIZE		256
> +#define CONFIG_SYS_PBSIZE		(CONFIG_SYS_CBSIZE + \
> +					sizeof(CONFIG_SYS_PROMPT) + 16)
> +/* max number of command args */
> +#define CONFIG_SYS_MAXARGS		16
> +
> +/* Boot Argument Buffer Size */
> +#define CONFIG_SYS_BARGSIZE		CONFIG_SYS_CBSIZE

Again, this is just a copy-paste from socfpga_common.h, no?

> +/*
> + * 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)

[...]

> +/*
> + * 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
> +#define CONFIG_CMD_MMC
> +/* Enable FAT write support */
> +#define CONFIG_FAT_WRITE
> +
> +/* configure a clustsize smaller than the default 64k */
> +#define CONFIG_FS_FAT_MAX_CLUSTSIZE 16384
> +/* MMC support */
> +#define CONFIG_SDMMC_BASE		(SOCFPGA_SDMMC_ADDRESS)
> +#define CONFIG_GENERIC_MMC
> +#define CONFIG_SYS_MMC_MAX_BLK_COUNT    256

Is this limit really needed?

> +#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
> +#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 */

[U-Boot] [PATCH 07/10] ARM: socfpga: arria10: add board files for the Arria10 SoCDK

[dinguyen at opensource.altera.com]

From: Dinh Nguyen <dinguyen@opensource.altera.com>

Add minimal support for the Arria10 SoCDK.

Signed-off-by: Dinh Nguyen <dinguyen@opensource.altera.com>
---
 board/altera/arria10-socdk/Kconfig   | 18 ++++++++++++++++++
 board/altera/arria10-socdk/Makefile  |  9 +++++++++
 board/altera/arria10-socdk/socfpga.c | 24 ++++++++++++++++++++++++
 3 files changed, 51 insertions(+)
 create mode 100644 board/altera/arria10-socdk/Kconfig
 create mode 100644 board/altera/arria10-socdk/Makefile
 create mode 100644 board/altera/arria10-socdk/socfpga.c

diff --git a/board/altera/arria10-socdk/Kconfig b/board/altera/arria10-socdk/Kconfig
new file mode 100644
index 0000000..b80cc6d
--- /dev/null
+++ b/board/altera/arria10-socdk/Kconfig
@@ -0,0 +1,18 @@
+if TARGET_SOCFPGA_ARRIA10
+
+config SYS_CPU
+	default "armv7"
+
+config SYS_BOARD
+	default "socfpga_arria10"
+
+config SYS_VENDOR
+	default "altera"
+
+config SYS_SOC
+	default "socfpga_arria10"
+
+config SYS_CONFIG_NAME
+	default "socfpga_arria10"
+
+endif
diff --git a/board/altera/arria10-socdk/Makefile b/board/altera/arria10-socdk/Makefile
new file mode 100644
index 0000000..86f9b78
--- /dev/null
+++ b/board/altera/arria10-socdk/Makefile
@@ -0,0 +1,9 @@
+#
+# (C) Copyright 2001-2006
+# Wolfgang Denk, DENX Software Engineering, wd at denx.de.
+# (C) Copyright 2010, Thomas Chou <thomas@wytron.com.tw>
+#
+# SPDX-License-Identifier:	GPL-2.0+
+#
+
+obj-y	:= socfpga.o
diff --git a/board/altera/arria10-socdk/socfpga.c b/board/altera/arria10-socdk/socfpga.c
new file mode 100644
index 0000000..bd00728
--- /dev/null
+++ b/board/altera/arria10-socdk/socfpga.c
@@ -0,0 +1,24 @@
+/*
+ * Copyright (C) 2014 Altera Corporation <www.altera.com>
+ *
+ * SPDX-License-Identifier:	GPL-2.0+
+ */
+
+#include <common.h>
+#include <asm/io.h>
+
+DECLARE_GLOBAL_DATA_PTR;
+
+void s_init(void)
+{
+}
+
+/*
+ * Miscellaneous platform dependent initialisations
+ */
+int board_init(void)
+{
+	/* Address of boot parameters for ATAG (if ATAG is used) */
+	gd->bd->bi_boot_params = CONFIG_SYS_SDRAM_BASE + 0x100;
+	return 0;
+}
-- 
2.6.2

[U-Boot] [PATCH 07/10] ARM: socfpga: arria10: add board files for the Arria10 SoCDK

[Pavel Machek]

Hi!

> index 0000000..86f9b78
> --- /dev/null
> +++ b/board/altera/arria10-socdk/Makefile
> @@ -0,0 +1,9 @@
> +#
> +# (C) Copyright 2001-2006
> +# Wolfgang Denk, DENX Software Engineering, wd at denx.de.
> +# (C) Copyright 2010, Thomas Chou <thomas@wytron.com.tw>
> +#

You can delete these. There's nothing left of the old Makefile here.

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


-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[U-Boot] [PATCH 08/10] ARM: socfpga: arria10: add socfpga_arria10_defconfig

[dinguyen at opensource.altera.com]

From: Dinh Nguyen <dinguyen@opensource.altera.com>

Add a defconfig file for Arria10, which does not include enabling SPL.

Signed-off-by: Dinh Nguyen <dinguyen@opensource.altera.com>
---
 configs/socfpga_arria10_defconfig | 11 +++++++++++
 1 file changed, 11 insertions(+)
 create mode 100644 configs/socfpga_arria10_defconfig

diff --git a/configs/socfpga_arria10_defconfig b/configs/socfpga_arria10_defconfig
new file mode 100644
index 0000000..22722a9
--- /dev/null
+++ b/configs/socfpga_arria10_defconfig
@@ -0,0 +1,11 @@
+CONFIG_ARM=y
+CONFIG_ARCH_SOCFPGA=y
+CONFIG_TARGET_SOCFPGA_ARRIA10=y
+CONFIG_DM_GPIO=y
+CONFIG_TARGET_SOCFPGA_ARRIA10_SOCDK=y
+CONFIG_DEFAULT_DEVICE_TREE="socfpga_arria10_socdk"
+# CONFIG_CMD_IMLS is not set
+# CONFIG_CMD_FLASH is not set
+CONFIG_DWAPB_GPIO=y
+CONFIG_DM_ETH=y
+CONFIG_ETH_DESIGNWARE=y
-- 
2.6.2

[U-Boot] [PATCH 09/10] ARM: socfpga: arria10: add config option build for arria10

[dinguyen at opensource.altera.com]

From: Dinh Nguyen <dinguyen@opensource.altera.com>

Signed-off-by: Dinh Nguyen <dinguyen@opensource.altera.com>
---
 arch/arm/Kconfig              |  4 ++--
 arch/arm/mach-socfpga/Kconfig | 10 ++++++++++
 2 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 5ab0254..1d78e40 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -499,9 +499,9 @@ config RMOBILE
 config ARCH_SOCFPGA
 	bool "Altera SOCFPGA family"
 	select CPU_V7
-	select SUPPORT_SPL
+	select SUPPORT_SPL if !TARGET_SOCFPGA_ARRIA10
 	select OF_CONTROL
-	select SPL_OF_CONTROL
+	select SPL_OF_CONTROL if !TARGET_SOCFPGA_ARRIA10
 	select DM
 	select DM_SPI_FLASH
 	select DM_SPI
diff --git a/arch/arm/mach-socfpga/Kconfig b/arch/arm/mach-socfpga/Kconfig
index a413ea4..82d69ec 100644
--- a/arch/arm/mach-socfpga/Kconfig
+++ b/arch/arm/mach-socfpga/Kconfig
@@ -1,5 +1,8 @@
 if ARCH_SOCFPGA
 
+config TARGET_SOCFPGA_ARRIA10
+	bool
+
 config TARGET_SOCFPGA_ARRIA5
 	bool
 
@@ -18,6 +21,10 @@ config TARGET_SOCFPGA_CYCLONE5_SOCDK
 	bool "Altera SOCFPGA SoCDK (Cyclone V)"
 	select TARGET_SOCFPGA_CYCLONE5
 
+config TARGET_SOCFPGA_ARRIA10_SOCDK
+	bool "Altera SOCFPGA SoCDK (Arria 10)"
+	select TARGET_SOCFPGA_ARRIA10
+
 config TARGET_SOCFPGA_DENX_MCVEVK
 	bool "DENX MCVEVK (Cyclone V)"
 	select TARGET_SOCFPGA_CYCLONE5
@@ -34,6 +41,7 @@ endchoice
 
 config SYS_BOARD
 	default "arria5-socdk" if TARGET_SOCFPGA_ARRIA5_SOCDK
+	default "arria10-socdk" if TARGET_SOCFPGA_ARRIA10_SOCDK
 	default "cyclone5-socdk" if TARGET_SOCFPGA_CYCLONE5_SOCDK
 	default "de0-nano-soc" if TARGET_SOCFPGA_TERASIC_DE0_NANO
 	default "mcvevk" if TARGET_SOCFPGA_DENX_MCVEVK
@@ -41,6 +49,7 @@ config SYS_BOARD
 
 config SYS_VENDOR
 	default "altera" if TARGET_SOCFPGA_ARRIA5_SOCDK
+	default "altera" if TARGET_SOCFPGA_ARRIA10_SOCDK
 	default "altera" if TARGET_SOCFPGA_CYCLONE5_SOCDK
 	default "denx" if TARGET_SOCFPGA_DENX_MCVEVK
 	default "terasic" if TARGET_SOCFPGA_TERASIC_DE0_NANO
@@ -51,6 +60,7 @@ config SYS_SOC
 
 config SYS_CONFIG_NAME
 	default "socfpga_arria5_socdk" if TARGET_SOCFPGA_ARRIA5_SOCDK
+	default "socfpga_arria10_socdk" if TARGET_SOCFPGA_ARRIA10_SOCDK
 	default "socfpga_cyclone5_socdk" if TARGET_SOCFPGA_CYCLONE5_SOCDK
 	default "socfpga_de0_nano_soc" if TARGET_SOCFPGA_TERASIC_DE0_NANO
 	default "socfpga_mcvevk" if TARGET_SOCFPGA_DENX_MCVEVK
-- 
2.6.2

[U-Boot] [PATCH 10/10] ARM: socfpga: arria10: add support for building Arria10

[dinguyen at opensource.altera.com]

From: Dinh Nguyen <dinguyen@opensource.altera.com>

Update Makefile to build Arria 10.

Signed-off-by: Dinh Nguyen <dinguyen@opensource.altera.com>
---
 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

diff --git a/arch/arm/mach-socfpga/Makefile b/arch/arm/mach-socfpga/Makefile
index 316b326..0dbe9bb 100644
--- a/arch/arm/mach-socfpga/Makefile
+++ b/arch/arm/mach-socfpga/Makefile
@@ -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 \
 	   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/
+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)
diff --git a/arch/arm/mach-socfpga/arria10/Makefile b/arch/arm/mach-socfpga/arria10/Makefile
new file mode 100644
index 0000000..f5e4b7d
--- /dev/null
+++ b/arch/arm/mach-socfpga/arria10/Makefile
@@ -0,0 +1,7 @@
+#
+# Copyright (C) 2015 Altera Corporation <www.altera.com>
+#
+# SPDX-License-Identifier:	GPL-2.0+
+#
+
+obj-y	:= misc_a10.o reset_manager_a10.o sdram_a10.o
-- 
2.6.2

[U-Boot] [PATCH 10/10] ARM: socfpga: arria10: add support for building Arria10

[Marek Vasut]

On Thursday, November 19, 2015 at 10:35:47 PM, dinguyen at opensource.altera.com 
wrote:
> From: Dinh Nguyen <dinguyen@opensource.altera.com>
> 
> Update Makefile to build Arria 10.
> 
> Signed-off-by: Dinh Nguyen <dinguyen@opensource.altera.com>
> ---
>  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
> 
> diff --git a/arch/arm/mach-socfpga/Makefile
> b/arch/arm/mach-socfpga/Makefile index 316b326..0dbe9bb 100644
> --- a/arch/arm/mach-socfpga/Makefile
> +++ b/arch/arm/mach-socfpga/Makefile
> @@ -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 \
>  	   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 ?

> +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)
> diff --git a/arch/arm/mach-socfpga/arria10/Makefile
> b/arch/arm/mach-socfpga/arria10/Makefile new file mode 100644
> index 0000000..f5e4b7d
> --- /dev/null
> +++ b/arch/arm/mach-socfpga/arria10/Makefile
> @@ -0,0 +1,7 @@
> +#
> +# Copyright (C) 2015 Altera Corporation <www.altera.com>
> +#
> +# SPDX-License-Identifier:	GPL-2.0+
> +#
> +
> +obj-y	:= misc_a10.o reset_manager_a10.o sdram_a10.o

Best regards,
Marek Vasut

[U-Boot] [PATCH 10/10] ARM: socfpga: arria10: add support for building Arria10

[Dinh Nguyen]

On 11/19/2015 04:45 PM, Marek Vasut wrote:
> On Thursday, November 19, 2015 at 10:35:47 PM, dinguyen at opensource.altera.com 
> wrote:
>> From: Dinh Nguyen <dinguyen@opensource.altera.com>
>>
>> Update Makefile to build Arria 10.
>>
>> Signed-off-by: Dinh Nguyen <dinguyen@opensource.altera.com>
>> ---
>>  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
>>
>> diff --git a/arch/arm/mach-socfpga/Makefile
>> b/arch/arm/mach-socfpga/Makefile index 316b326..0dbe9bb 100644
>> --- a/arch/arm/mach-socfpga/Makefile
>> +++ b/arch/arm/mach-socfpga/Makefile
>> @@ -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 \
>>  	   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.

Dinh

[U-Boot] [PATCH 10/10] ARM: socfpga: arria10: add support for building Arria10

[Marek Vasut]

On Friday, November 20, 2015 at 12:28:47 AM, Dinh Nguyen wrote:
> On 11/19/2015 04:45 PM, Marek Vasut wrote:
> > On Thursday, November 19, 2015 at 10:35:47 PM,
> > dinguyen at opensource.altera.com
> > 
> > wrote:
> >> From: Dinh Nguyen <dinguyen@opensource.altera.com>
> >> 
> >> Update Makefile to build Arria 10.
> >> 
> >> Signed-off-by: Dinh Nguyen <dinguyen@opensource.altera.com>
> >> ---
> >> 
> >>  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
> >> 
> >> diff --git a/arch/arm/mach-socfpga/Makefile
> >> b/arch/arm/mach-socfpga/Makefile index 316b326..0dbe9bb 100644
> >> --- a/arch/arm/mach-socfpga/Makefile
> >> +++ b/arch/arm/mach-socfpga/Makefile
> >> @@ -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 \
> > 
> >>  	   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

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

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

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

Best regards,
Marek Vasut

[U-Boot] [PATCH 10/10] ARM: socfpga: arria10: add support for building Arria10

[Dinh Nguyen]

On 11/20/2015 06:49 AM, Marek Vasut wrote:
> On Friday, November 20, 2015 at 12:28:47 AM, Dinh Nguyen wrote:
>> On 11/19/2015 04:45 PM, Marek Vasut wrote:
>>> On Thursday, November 19, 2015 at 10:35:47 PM,
>>> dinguyen at opensource.altera.com
>>>
>>> wrote:
>>>> From: Dinh Nguyen <dinguyen@opensource.altera.com>
>>>>
>>>> Update Makefile to build Arria 10.
>>>>
>>>> Signed-off-by: Dinh Nguyen <dinguyen@opensource.altera.com>
>>>> ---
>>>>
>>>>  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
>>>>
>>>> diff --git a/arch/arm/mach-socfpga/Makefile
>>>> b/arch/arm/mach-socfpga/Makefile index 316b326..0dbe9bb 100644
>>>> --- a/arch/arm/mach-socfpga/Makefile
>>>> +++ b/arch/arm/mach-socfpga/Makefile
>>>> @@ -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 \
>>>
>>>>  	   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
> 
> Linux doesn't seem to require a separate directory though, does it ?
> I'm not convinced we need one either.
> 
>> 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.
> 
>> 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.

Dinh

[U-Boot] [PATCH 10/10] ARM: socfpga: arria10: add support for building Arria10

[Marek Vasut]

On Monday, November 23, 2015 at 03:36:14 PM, Dinh Nguyen wrote:
> On 11/20/2015 06:49 AM, Marek Vasut wrote:
> > On Friday, November 20, 2015 at 12:28:47 AM, Dinh Nguyen wrote:
> >> On 11/19/2015 04:45 PM, Marek Vasut wrote:
> >>> On Thursday, November 19, 2015 at 10:35:47 PM,
> >>> dinguyen at opensource.altera.com
> >>> 
> >>> wrote:
> >>>> From: Dinh Nguyen <dinguyen@opensource.altera.com>
> >>>> 
> >>>> Update Makefile to build Arria 10.
> >>>> 
> >>>> Signed-off-by: Dinh Nguyen <dinguyen@opensource.altera.com>
> >>>> ---
> >>>> 
> >>>>  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
> >>>> 
> >>>> diff --git a/arch/arm/mach-socfpga/Makefile
> >>>> b/arch/arm/mach-socfpga/Makefile index 316b326..0dbe9bb 100644
> >>>> --- a/arch/arm/mach-socfpga/Makefile
> >>>> +++ b/arch/arm/mach-socfpga/Makefile
> >>>> @@ -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 \
> >>> 
> >>>>  	   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
> > 
> > Linux doesn't seem to require a separate directory though, does it ?
> > I'm not convinced we need one either.
> > 
> >> 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.
> > 
> >> 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.

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

[U-Boot] [PATCH 10/10] ARM: socfpga: arria10: add support for building Arria10

[Dinh Nguyen]

On 11/23/2015 09:38 AM, Marek Vasut wrote:
> On Monday, November 23, 2015 at 03:36:14 PM, Dinh Nguyen wrote:
>> On 11/20/2015 06:49 AM, Marek Vasut wrote:
>>> On Friday, November 20, 2015 at 12:28:47 AM, Dinh Nguyen wrote:
>>>> On 11/19/2015 04:45 PM, Marek Vasut wrote:
>>>>> On Thursday, November 19, 2015 at 10:35:47 PM,
>>>>> dinguyen at opensource.altera.com
>>>>>
>>>>> wrote:
>>>>>> From: Dinh Nguyen <dinguyen@opensource.altera.com>
>>>>>>
>>>>>> Update Makefile to build Arria 10.
>>>>>>
>>>>>> Signed-off-by: Dinh Nguyen <dinguyen@opensource.altera.com>
>>>>>> ---
>>>>>>
>>>>>>  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
>>>>>>
>>>>>> diff --git a/arch/arm/mach-socfpga/Makefile
>>>>>> b/arch/arm/mach-socfpga/Makefile index 316b326..0dbe9bb 100644
>>>>>> --- a/arch/arm/mach-socfpga/Makefile
>>>>>> +++ b/arch/arm/mach-socfpga/Makefile
>>>>>> @@ -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 \
>>>>>
>>>>>>  	   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
>>>
>>> Linux doesn't seem to require a separate directory though, does it ?
>>> I'm not convinced we need one either.
>>>
>>>> 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.
>>>
>>>> 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.
> 
> 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.

Dinh

[U-Boot] [PATCH 10/10] ARM: socfpga: arria10: add support for building Arria10

[Marek Vasut]

On Monday, November 23, 2015 at 11:32:27 PM, Dinh Nguyen wrote:
[...]
> >>>> 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.
> > 
> > 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 ?

Best regards,
Marek Vasut

[U-Boot] [PATCH 10/10] ARM: socfpga: arria10: add support for building Arria10

[Dinh Nguyen]

On 11/23/2015 04:46 PM, Marek Vasut wrote:
> On Monday, November 23, 2015 at 11:32:27 PM, Dinh Nguyen wrote:
> [...]
>>>>>> 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.
>>>
>>> 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 ?
> 

That's exactly what is being in the mach-socfpga directory. Yes, but
should that code go into mach-socfpga or drivers?

Dinh

[U-Boot] [PATCH 10/10] ARM: socfpga: arria10: add support for building Arria10

[Marek Vasut]

On Monday, November 23, 2015 at 11:50:15 PM, Dinh Nguyen wrote:
> On 11/23/2015 04:46 PM, Marek Vasut wrote:
> > On Monday, November 23, 2015 at 11:32:27 PM, Dinh Nguyen wrote:
> > [...]
> > 
> >>>>>> 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.
> >>> 
> >>> 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 ?
> 
> That's exactly what is being in the mach-socfpga directory.

Um, am I missing it in this patchset ?

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

Best regards,
Marek Vasut

[U-Boot] [PATCH 10/10] ARM: socfpga: arria10: add support for building Arria10

[Dinh Nguyen]

On 11/23/2015 05:03 PM, Marek Vasut wrote:
> On Monday, November 23, 2015 at 11:50:15 PM, Dinh Nguyen wrote:
>> On 11/23/2015 04:46 PM, Marek Vasut wrote:
>>> On Monday, November 23, 2015 at 11:32:27 PM, Dinh Nguyen wrote:
>>> [...]
>>>
>>>>>>>> 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.
>>>>>
>>>>> 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 ?
>>
>> 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.

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

Dinh

[U-Boot] [PATCH 10/10] ARM: socfpga: arria10: add support for building Arria10

[Marek Vasut]

On Tuesday, November 24, 2015 at 12:04:10 AM, Dinh Nguyen wrote:
> On 11/23/2015 05:03 PM, Marek Vasut wrote:
> > On Monday, November 23, 2015 at 11:50:15 PM, Dinh Nguyen wrote:
> >> On 11/23/2015 04:46 PM, Marek Vasut wrote:
> >>> On Monday, November 23, 2015 at 11:32:27 PM, Dinh Nguyen wrote:
> >>> [...]
> >>> 
> >>>>>>>> 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.
> >>>>> 
> >>>>> 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 ?
> >> 
> >> 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 :)

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

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.

Best regards,
Marek Vasut

[U-Boot] [PATCH 10/10] ARM: socfpga: arria10: add support for building Arria10

[Dinh Nguyen]

On 11/23/2015 05:20 PM, Marek Vasut wrote:
> On Tuesday, November 24, 2015 at 12:04:10 AM, Dinh Nguyen wrote:
>> On 11/23/2015 05:03 PM, Marek Vasut wrote:
>>> On Monday, November 23, 2015 at 11:50:15 PM, Dinh Nguyen wrote:
>>>> On 11/23/2015 04:46 PM, Marek Vasut wrote:
>>>>> On Monday, November 23, 2015 at 11:32:27 PM, Dinh Nguyen wrote:
>>>>> [...]
>>>>>
>>>>>>>>>> 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.
>>>>>>>
>>>>>>> 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 ?
>>>>
>>>> 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 :)
> 
>>>> 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.
> 
> 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

[U-Boot] [PATCH 10/10] ARM: socfpga: arria10: add support for building Arria10

[Chin Liang See]

On Mon, 2015-11-23 at 17:25 -0600, Dinh Nguyen wrote:
> On 11/23/2015 05:20 PM, Marek Vasut wrote:
> > On Tuesday, November 24, 2015 at 12:04:10 AM, Dinh Nguyen wrote:
> > > On 11/23/2015 05:03 PM, Marek Vasut wrote:
> > > > On Monday, November 23, 2015 at 11:50:15 PM, Dinh Nguyen wrote:
> > > > > On 11/23/2015 04:46 PM, Marek Vasut wrote:
> > > > > > On Monday, November 23, 2015 at 11:32:27 PM, Dinh Nguyen
> > > > > > wrote:
> > > > > > [...]
> > > > > > 
> > > > > > > > > > > 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.
> > > > > > > > 
> > > > > > > > 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 ?
> > > > > 
> > > > > 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 :)
> > 
> > > > > 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.
> > 
> > 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.

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

Thanks
Chin Liang

> 
> Dinh
> 
> 

[U-Boot] [PATCH 10/10] ARM: socfpga: arria10: add support for building Arria10

[Marek Vasut]

On Tuesday, November 24, 2015 at 04:17:34 AM, Chin Liang See wrote:
> On Mon, 2015-11-23 at 17:25 -0600, Dinh Nguyen wrote:
> > On 11/23/2015 05:20 PM, Marek Vasut wrote:
> > > On Tuesday, November 24, 2015 at 12:04:10 AM, Dinh Nguyen wrote:
> > > > On 11/23/2015 05:03 PM, Marek Vasut wrote:
> > > > > On Monday, November 23, 2015 at 11:50:15 PM, Dinh Nguyen wrote:
> > > > > > On 11/23/2015 04:46 PM, Marek Vasut wrote:
> > > > > > > On Monday, November 23, 2015 at 11:32:27 PM, Dinh Nguyen
> > > > > > > wrote:
> > > > > > > [...]
> > > > > > > 
> > > > > > > > > > > > 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.
> > > > > > > > > 
> > > > > > > > > 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 ?
> > > > > > 
> > > > > > 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 :)
> > > 
> > > > > > 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.
> > > 
> > > 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.
> 
> 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.

> 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] [PATCH 10/10] ARM: socfpga: arria10: add support for building Arria10

[Heiko Schocher]

Hello Marek, Chin Liang See,

Sorry for digging so late into this topic ...

Am 24.11.2015 um 10:31 schrieb Marek Vasut:
> On Tuesday, November 24, 2015 at 04:17:34 AM, Chin Liang See wrote:
>> On Mon, 2015-11-23 at 17:25 -0600, Dinh Nguyen wrote:
>>> On 11/23/2015 05:20 PM, Marek Vasut wrote:
>>>> On Tuesday, November 24, 2015 at 12:04:10 AM, Dinh Nguyen wrote:
>>>>> On 11/23/2015 05:03 PM, Marek Vasut wrote:
>>>>>> On Monday, November 23, 2015 at 11:50:15 PM, Dinh Nguyen wrote:
>>>>>>> On 11/23/2015 04:46 PM, Marek Vasut wrote:
>>>>>>>> On Monday, November 23, 2015 at 11:32:27 PM, Dinh Nguyen
>>>>>>>> wrote:
>>>>>>>> [...]
>>>>>>>>
>>>>>>>>>>>>> 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.
>>>>>>>>>>
>>>>>>>>>> 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 ?
>>>>>>>
>>>>>>> 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 :)
>>>>
>>>>>>> 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.
>>>>
>>>> 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
>>>
>>> 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.
>
>> 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
>

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

[U-Boot] [PATCH 10/10] ARM: socfpga: arria10: add support for building Arria10

[Chin Liang See]

Hi Heiko,

On Tue, 2015-11-24 at 13:29 +0100, Heiko Schocher wrote:
> Hello Marek, Chin Liang See,
> 
> Sorry for digging so late into this topic ...

No worries as inputs always appreciated.

> 
> Am 24.11.2015 um 10:31 schrieb Marek Vasut:
> > On Tuesday, November 24, 2015 at 04:17:34 AM, Chin Liang See wrote:
> > > On Mon, 2015-11-23 at 17:25 -0600, Dinh Nguyen wrote:
> > > > On 11/23/2015 05:20 PM, Marek Vasut wrote:
> > > > > On Tuesday, November 24, 2015 at 12:04:10 AM, Dinh Nguyen
> > > > > wrote:
> > > > > > On 11/23/2015 05:03 PM, Marek Vasut wrote:
> > > > > > > On Monday, November 23, 2015 at 11:50:15 PM, Dinh Nguyen
> > > > > > > wrote:
> > > > > > > > On 11/23/2015 04:46 PM, Marek Vasut wrote:
> > > > > > > > > On Monday, November 23, 2015 at 11:32:27 PM, Dinh
> > > > > > > > > Nguyen
> > > > > > > > > wrote:
> > > > > > > > > [...]
> > > > > > > > > 
> > > > > > > > > > > > > > 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.
> > > > > > > > > > > 
> > > > > > > > > > > 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 ?
> > > > > > > > 
> > > > > > > > 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 :)
> > > > > 
> > > > > > > > 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.
> > > > > 
> > > > > 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 ;-)
> 

Cool, thanks for sharing on this.
It's always nice to have full features implementation for powerful usertogether with light weight implementation when boot time is concern.

Thanks
Chin Liang

> bye,
> Heiko
> > > > 
> > > > 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.
> > 
> > > 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
> > 
> 

[U-Boot] [PATCH 10/10] ARM: socfpga: arria10: add support for building Arria10

[Chin Liang See]

Hi Heiko,

On Tue, 2015-11-24 at 13:29 +0100, Heiko Schocher wrote:
> Hello Marek, Chin Liang See,
> 
> Sorry for digging so late into this topic ...

No worries as inputs are welcome any time.

> 
> Am 24.11.2015 um 10:31 schrieb Marek Vasut:
> > On Tuesday, November 24, 2015 at 04:17:34 AM, Chin Liang See wrote:
> > > On Mon, 2015-11-23 at 17:25 -0600, Dinh Nguyen wrote:
> > > > On 11/23/2015 05:20 PM, Marek Vasut wrote:
> > > > > On Tuesday, November 24, 2015 at 12:04:10 AM, Dinh Nguyen
> > > > > wrote:
> > > > > > On 11/23/2015 05:03 PM, Marek Vasut wrote:
> > > > > > > On Monday, November 23, 2015 at 11:50:15 PM, Dinh Nguyen
> > > > > > > wrote:
> > > > > > > > On 11/23/2015 04:46 PM, Marek Vasut wrote:
> > > > > > > > > On Monday, November 23, 2015 at 11:32:27 PM, Dinh
> > > > > > > > > Nguyen
> > > > > > > > > wrote:
> > > > > > > > > [...]
> > > > > > > > > 
> > > > > > > > > > > > > > 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.
> > > > > > > > > > > 
> > > > > > > > > > > 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 ?
> > > > > > > > 
> > > > > > > > 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 :)
> > > > > 
> > > > > > > > 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.
> > > > > 
> > > > > 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

Cool, thanks for sharing on this.
It's always nice to have full features
implementation for powerful usertogether with light weight
implementation when boot time is concern.

Thanks
Chin Liang

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

[U-Boot] [PATCH 10/10] ARM: socfpga: arria10: add support for building Arria10

[Pavel Machek]

Hi!

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

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

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
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[U-Boot] [PATCH 10/10] ARM: socfpga: arria10: add support for building Arria10

[Chin Liang See]

Hi Pavel,

On Tue, 2015-11-24 at 14:31 +0100, Pavel Machek wrote:
> Hi!
>
> > > > > 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.
> > >
> > > 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:
>
> > > 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 ?
>
> 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

Chin Liang

>
> Pavel

[U-Boot] [PATCH 10/10] ARM: socfpga: arria10: add support for building Arria10

[Marek Vasut]

On Tuesday, November 24, 2015 at 02:36:13 PM, Chin Liang See wrote:
> Hi Pavel,
> 
> On Tue, 2015-11-24 at 14:31 +0100, Pavel Machek wrote:
> > Hi!
> > 
> > > > > > 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.
> > > > 
> > > > 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:
> > > > 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 ?
> > 
> > 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

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.

Best regards,
Marek Vasut

[U-Boot] [PATCH 10/10] ARM: socfpga: arria10: add support for building Arria10

[Pavel Machek]

Hi!

> > > > > 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 ?
> > > 
> > > 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
> 
> 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".
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[U-Boot] [PATCH 10/10] ARM: socfpga: arria10: add support for building Arria10

[Marek Vasut]

On Tuesday, November 24, 2015 at 03:01:09 PM, Pavel Machek wrote:
> Hi!

Hi!

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

I do not necessarily need this overhead.

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

This can be done by converging SPL to normal U-Boot, but that's not gonna
happen instantaneously.

Best regards,
Marek Vasut

[U-Boot] [PATCH 10/10] ARM: socfpga: arria10: add support for building Arria10

[Chin Liang See]

Hi Marek,

On Tue, 2015-11-24 at 10:31 +0100, Marek Vasut wrote:
> On Tuesday, November 24, 2015 at 04:17:34 AM, Chin Liang See wrote:
> > On Mon, 2015-11-23 at 17:25 -0600, Dinh Nguyen wrote:
> > > On 11/23/2015 05:20 PM, Marek Vasut wrote:
> > > > On Tuesday, November 24, 2015 at 12:04:10 AM, Dinh Nguyen
> > > > wrote:
> > > > > On 11/23/2015 05:03 PM, Marek Vasut wrote:
> > > > > > On Monday, November 23, 2015 at 11:50:15 PM, Dinh Nguyen
> > > > > > wrote:
> > > > > > > On 11/23/2015 04:46 PM, Marek Vasut wrote:
> > > > > > > > On Monday, November 23, 2015 at 11:32:27 PM, Dinh
> > > > > > > > Nguyen
> > > > > > > > wrote:
> > > > > > > > [...]
> > > > > > > > 
> > > > > > > > > > > > > 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.
> > > > > > > > > > 
> > > > > > > > > > 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 ?
> > > > > > > 
> > > > > > > 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 :)
> > > > 
> > > > > > > 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.
> > > > 
> > > > 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.
> > 
> > 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.
> 
> > 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 ?

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

Thanks
Chin Liang


> 
> Best regards,
> Marek Vasut

[U-Boot] [PATCH 10/10] ARM: socfpga: arria10: add support for building Arria10

[Marek Vasut]

On Tuesday, November 24, 2015 at 02:34:11 PM, Chin Liang See wrote:
> Hi Marek,

[...]

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

Well replace the "minimal U-Boot" with SPL, that should be much simpler
task to implement.

Best regards,
Marek Vasut

[U-Boot] [PATCH 10/10] ARM: socfpga: arria10: add support for building Arria10

[Pavel Machek]

On Thu 2015-11-19 17:28:47, Dinh Nguyen wrote:
> On 11/19/2015 04:45 PM, Marek Vasut wrote:
> > On Thursday, November 19, 2015 at 10:35:47 PM, dinguyen at opensource.altera.com 
> > wrote:
> >> From: Dinh Nguyen <dinguyen@opensource.altera.com>
> >>
> >> Update Makefile to build Arria 10.
> >>
> >> Signed-off-by: Dinh Nguyen <dinguyen@opensource.altera.com>
> >> ---
> >>  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
> >>
> >> diff --git a/arch/arm/mach-socfpga/Makefile
> >> b/arch/arm/mach-socfpga/Makefile index 316b326..0dbe9bb 100644
> >> --- a/arch/arm/mach-socfpga/Makefile
> >> +++ b/arch/arm/mach-socfpga/Makefile
> >> @@ -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 \
> >>  	   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.

Well.. so you'll have to optimize memory consuption of the fpga
programming. It may be ugly, but once you are done, you'll want to use
the optimized version for everyone -- not to keep two versions.

Best regards,
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html