[U-Boot] [PATCH 00/10] ARM: socfpga: Add minimal support for Arria10
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
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_ */
On Thursday, November 19, 2015 at 10:35:38 PM, dinguyen@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
On 11/19/2015 04:26 PM, Marek Vasut wrote:
On Thursday, November 19, 2015 at 10:35:38 PM, dinguyen@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
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_ */
On Thursday, November 19, 2015 at 10:35:39 PM, dinguyen@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_ */
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_ */
On Thursday, November 19, 2015 at 10:35:40 PM, dinguyen@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_ */
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_ */
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
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
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 +}
On Thursday, November 19, 2015 at 10:35:42 PM, dinguyen@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/ .
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 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 +/* 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 */
On Thursday, November 19, 2015 at 10:35:43 PM, dinguyen@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 at 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 */
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@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; +}
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@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
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
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
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
On Thursday, November 19, 2015 at 10:35:47 PM, dinguyen@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.oobj-$(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
On 11/19/2015 04:45 PM, Marek Vasut wrote:
On Thursday, November 19, 2015 at 10:35:47 PM, dinguyen@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.oobj-$(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
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@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.oobj-$(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
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@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.oobj-$(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
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@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.oobj-$(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 ?
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@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.oobj-$(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
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
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
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
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
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
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
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
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
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@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
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@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
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@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
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
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
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
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
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
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
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.
- BootROM load minimal U-Boot to OCRAM
- Minimal U-Boot initialize all the critical HW such as clocks, DDR
- Minimal U-Boot load larger U-Boot to SDRAM
- Larger U-Boot will then load Linux
- Linux boot
Well replace the "minimal U-Boot" with SPL, that should be much simpler task to implement.
Best regards, Marek Vasut
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@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.oobj-$(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
participants (6)
-
Chin Liang See -
dinguyen＠opensource.altera.com -
Dinh Nguyen
-
Heiko Schocher -
Marek Vasut -
Pavel Machek