[U-Boot] [PATCH 02/14] arm: socfpga: Move firewall code to firewall file
Move firewall related code new firewall.c in order to share
code in Stratix 10 and Agilex.
No functional change.
Signed-off-by: Ley Foon Tan
---
arch/arm/mach-socfpga/Makefile| 1 +
arch/arm/mach-socfpga/firewall.c | 97 +++
.../mach/{firewall_s10.h => firewall.h} | 10 +-
arch/arm/mach-socfpga/spl_s10.c | 84 +---
drivers/ddr/altera/sdram_s10.c| 2 +-
5 files changed, 107 insertions(+), 87 deletions(-)
create mode 100644 arch/arm/mach-socfpga/firewall.c
rename arch/arm/mach-socfpga/include/mach/{firewall_s10.h => firewall.h} (94%)
diff --git a/arch/arm/mach-socfpga/Makefile b/arch/arm/mach-socfpga/Makefile
index e66720447f..11370cf4c4 100644
--- a/arch/arm/mach-socfpga/Makefile
+++ b/arch/arm/mach-socfpga/Makefile
@@ -52,6 +52,7 @@ ifdef CONFIG_TARGET_SOCFPGA_ARRIA10
obj-y += spl_a10.o
endif
ifdef CONFIG_TARGET_SOCFPGA_STRATIX10
+obj-y += firewall.o
obj-y += spl_s10.o
endif
endif
diff --git a/arch/arm/mach-socfpga/firewall.c b/arch/arm/mach-socfpga/firewall.c
new file mode 100644
index 00..c67650158a
--- /dev/null
+++ b/arch/arm/mach-socfpga/firewall.c
@@ -0,0 +1,97 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2016-2019 Intel Corporation
+ *
+ */
+
+#include
+#include
+#include
+
+static void firewall_l4_per_disable(void)
+{
+ const struct socfpga_firwall_l4_per *firwall_l4_per_base =
+ (struct socfpga_firwall_l4_per *)SOCFPGA_FIREWALL_L4_PER;
+ u32 i;
+ const u32 *addr[] = {
+ _l4_per_base->nand,
+ _l4_per_base->nand_data,
+ _l4_per_base->usb0,
+ _l4_per_base->usb1,
+ _l4_per_base->spim0,
+ _l4_per_base->spim1,
+ _l4_per_base->emac0,
+ _l4_per_base->emac1,
+ _l4_per_base->emac2,
+ _l4_per_base->sdmmc,
+ _l4_per_base->gpio0,
+ _l4_per_base->gpio1,
+ _l4_per_base->i2c0,
+ _l4_per_base->i2c1,
+ _l4_per_base->i2c2,
+ _l4_per_base->i2c3,
+ _l4_per_base->i2c4,
+ _l4_per_base->timer0,
+ _l4_per_base->timer1,
+ _l4_per_base->uart0,
+ _l4_per_base->uart1
+ };
+
+ /*
+* The following lines of code will enable non-secure access
+* to nand, usb, spi, emac, sdmmc, gpio, i2c, timers and uart. This
+* is needed as most OS run in non-secure mode. Thus we need to
+* enable non-secure access to these peripherals in order for the
+* OS to use these peripherals.
+*/
+ for (i = 0; i < ARRAY_SIZE(addr); i++)
+ writel(FIREWALL_L4_DISABLE_ALL, addr[i]);
+}
+
+static void firewall_l4_sys_disable(void)
+{
+ const struct socfpga_firwall_l4_sys *firwall_l4_sys_base =
+ (struct socfpga_firwall_l4_sys *)SOCFPGA_FIREWALL_L4_SYS;
+ u32 i;
+ const u32 *addr[] = {
+ _l4_sys_base->dma_ecc,
+ _l4_sys_base->emac0rx_ecc,
+ _l4_sys_base->emac0tx_ecc,
+ _l4_sys_base->emac1rx_ecc,
+ _l4_sys_base->emac1tx_ecc,
+ _l4_sys_base->emac2rx_ecc,
+ _l4_sys_base->emac2tx_ecc,
+ _l4_sys_base->nand_ecc,
+ _l4_sys_base->nand_read_ecc,
+ _l4_sys_base->nand_write_ecc,
+ _l4_sys_base->ocram_ecc,
+ _l4_sys_base->sdmmc_ecc,
+ _l4_sys_base->usb0_ecc,
+ _l4_sys_base->usb1_ecc,
+ _l4_sys_base->clock_manager,
+ _l4_sys_base->io_manager,
+ _l4_sys_base->reset_manager,
+ _l4_sys_base->system_manager,
+ _l4_sys_base->watchdog0,
+ _l4_sys_base->watchdog1,
+ _l4_sys_base->watchdog2,
+ _l4_sys_base->watchdog3
+ };
+
+ for (i = 0; i < ARRAY_SIZE(addr); i++)
+ writel(FIREWALL_L4_DISABLE_ALL, addr[i]);
+}
+
+static void firewall_bridge_disable(void)
+{
+ /* disable lwsocf2fpga and soc2fpga bridge security */
+ writel(FIREWALL_BRIDGE_DISABLE_ALL, SOCFPGA_FIREWALL_SOC2FPGA);
+ writel(FIREWALL_BRIDGE_DISABLE_ALL, SOCFPGA_FIREWALL_LWSOC2FPGA);
+}
+
+void firewall_setup(void)
+{
+ firewall_l4_per_disable();
+ firewall_l4_sys_disable();
+ firewall_bridge_disable();
+}
diff --git a/arch/arm/mach-socfpga/include/mach/firewall_s10.h
b/arch/arm/mach-socfpga/include/mach/firewall.h
similarity
[U-Boot] [PATCH 04/14] arm: socfpga: agilex: Add reset manager support
Add reset manager support for Agilex.
Signed-off-by: Ley Foon Tan
---
.../mach-socfpga/include/mach/reset_manager.h | 5 ++-
.../include/mach/reset_manager_agilex.h | 38 +++
arch/arm/mach-socfpga/reset_manager.c | 9 +++--
3 files changed, 48 insertions(+), 4 deletions(-)
create mode 100644 arch/arm/mach-socfpga/include/mach/reset_manager_agilex.h
diff --git a/arch/arm/mach-socfpga/include/mach/reset_manager.h
b/arch/arm/mach-socfpga/include/mach/reset_manager.h
index e2dce4b4fb..f752f7abb8 100644
--- a/arch/arm/mach-socfpga/include/mach/reset_manager.h
+++ b/arch/arm/mach-socfpga/include/mach/reset_manager.h
@@ -36,7 +36,8 @@ void socfpga_per_reset_all(void);
/* Create a human-readable reference to SoCFPGA reset. */
#define SOCFPGA_RESET(_name) RSTMGR_##_name
-#if defined(CONFIG_TARGET_SOCFPGA_STRATIX10)
+#if defined(CONFIG_TARGET_SOCFPGA_STRATIX10) || \
+ defined(CONFIG_TARGET_SOCFPGA_AGILEX)
void reset_deassert_peripherals_handoff(void);
int cpu_has_been_warmreset(void);
@@ -68,6 +69,8 @@ void socfpga_bridges_reset(int enable);
#include
#elif defined(CONFIG_TARGET_SOCFPGA_STRATIX10)
#include
+#elif defined(CONFIG_TARGET_SOCFPGA_AGILEX)
+#include
#endif
#endif /* _RESET_MANAGER_H_ */
diff --git a/arch/arm/mach-socfpga/include/mach/reset_manager_agilex.h
b/arch/arm/mach-socfpga/include/mach/reset_manager_agilex.h
new file mode 100644
index 00..c209fb439b
--- /dev/null
+++ b/arch/arm/mach-socfpga/include/mach/reset_manager_agilex.h
@@ -0,0 +1,38 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) 2019 Intel Corporation
+ */
+
+#ifndef_RESET_MANAGER_AGILEX_
+#define_RESET_MANAGER_AGILEX_
+
+struct socfpga_reset_manager {
+ u32 status;
+ u32 mpu_rst_stat;
+ u32 misc_stat;
+ u32 padding1;
+ u32 hdsk_en;
+ u32 hdsk_req;
+ u32 hdsk_ack;
+ u32 hdsk_stall;
+ u32 mpumodrst;
+ u32 per0modrst;
+ u32 per1modrst;
+ u32 brgmodrst;
+ u32 padding2;
+ u32 cold_mod_reset;
+ u32 padding3;
+ u32 dbg_mod_reset;
+ u32 padding4;
+ u32 padding5;
+ u32 padding6;
+ u32 brg_warm_mask;
+ u32 padding7[3];
+ u32 tst_stat;
+ u32 padding8;
+ u32 hdsk_timeout;
+ u32 mpul2flushtimeout;
+ u32 dbghdsktimeout;
+};
+
+#endif /* _RESET_MANAGER_AGILEX_ */
diff --git a/arch/arm/mach-socfpga/reset_manager.c
b/arch/arm/mach-socfpga/reset_manager.c
index e0a01ed07a..5dfe303940 100644
--- a/arch/arm/mach-socfpga/reset_manager.c
+++ b/arch/arm/mach-socfpga/reset_manager.c
@@ -8,13 +8,15 @@
#include
#include
-#if defined(CONFIG_TARGET_SOCFPGA_STRATIX10)
+#if defined(CONFIG_TARGET_SOCFPGA_STRATIX10) || \
+ defined(CONFIG_TARGET_SOCFPGA_AGILEX)
#include
#endif
DECLARE_GLOBAL_DATA_PTR;
-#if !defined(CONFIG_TARGET_SOCFPGA_STRATIX10)
+#if !defined(CONFIG_TARGET_SOCFPGA_STRATIX10) && \
+ !defined(CONFIG_TARGET_SOCFPGA_AGILEX)
static const struct socfpga_reset_manager *reset_manager_base =
(void *)SOCFPGA_RSTMGR_ADDRESS;
#endif
@@ -25,7 +27,8 @@ static const struct socfpga_reset_manager *reset_manager_base
=
void reset_cpu(ulong addr)
{
/* request a warm reset */
-#if defined(CONFIG_TARGET_SOCFPGA_STRATIX10)
+#if defined(CONFIG_TARGET_SOCFPGA_STRATIX10) || \
+ defined(CONFIG_TARGET_SOCFPGA_AGILEX)
puts("Mailbox: Issuing mailbox cmd REBOOT_HPS\n");
mbox_reset_cold();
#else
--
2.19.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 06/14] arm: socfpga: agilex: Add system manager support
Add system manager support for Agilex.
Signed-off-by: Ley Foon Tan
---
.../include/mach/system_manager.h | 6 +
.../include/mach/system_manager_agilex.h | 127 ++
2 files changed, 133 insertions(+)
create mode 100644 arch/arm/mach-socfpga/include/mach/system_manager_agilex.h
diff --git a/arch/arm/mach-socfpga/include/mach/system_manager.h
b/arch/arm/mach-socfpga/include/mach/system_manager.h
index 171b79e238..ee693fc7a6 100644
--- a/arch/arm/mach-socfpga/include/mach/system_manager.h
+++ b/arch/arm/mach-socfpga/include/mach/system_manager.h
@@ -6,8 +6,14 @@
#ifndef _SYSTEM_MANAGER_H_
#define _SYSTEM_MANAGER_H_
+#if defined(CONFIG_TARGET_SOCFPGA_STRATIX10) || \
+ defined(CONFIG_TARGET_SOCFPGA_AGILEX)
+
#if defined(CONFIG_TARGET_SOCFPGA_STRATIX10)
#include
+#elif defined(CONFIG_TARGET_SOCFPGA_AGILEX)
+#include
+#endif
void sysmgr_pinmux_init(void);
void populate_sysmgr_fpgaintf_module(void);
diff --git a/arch/arm/mach-socfpga/include/mach/system_manager_agilex.h
b/arch/arm/mach-socfpga/include/mach/system_manager_agilex.h
new file mode 100644
index 00..3b814d67f5
--- /dev/null
+++ b/arch/arm/mach-socfpga/include/mach/system_manager_agilex.h
@@ -0,0 +1,127 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) 2019 Intel Corporation
+ */
+
+#ifndef_SYSTEM_MANAGER_AGILEX_
+#define_SYSTEM_MANAGER_AGILEX_
+
+struct socfpga_system_manager {
+ /* System Manager Module */
+ u32 siliconid1; /* 0x00 */
+ u32 siliconid2;
+ u32 wddbg;
+ u32 _pad_0xc;
+ u32 mpu_status; /* 0x10 */
+ u32 mpu_ace;
+ u32 _pad_0x18_0x1c[2];
+ u32 dma;/* 0x20 */
+ u32 dma_periph;
+ /* SDMMC Controller Group */
+ u32 sdmmcgrp_ctrl;
+ u32 sdmmcgrp_l3master;
+ /* NAND Flash Controller Register Group */
+ u32 nandgrp_bootstrap; /* 0x30 */
+ u32 nandgrp_l3master;
+ /* USB Controller Group */
+ u32 usb0_l3master;
+ u32 usb1_l3master;
+ /* EMAC Group */
+ u32 emac_gbl; /* 0x40 */
+ u32 emac0;
+ u32 emac1;
+ u32 emac2;
+ u32 emac0_ace; /* 0x50 */
+ u32 emac1_ace;
+ u32 emac2_ace;
+ u32 nand_axuser;
+ u32 _pad_0x60_0x64[2]; /* 0x60 */
+ /* FPGA interface Group */
+ u32 fpgaintf_en_1;
+ u32 fpgaintf_en_2;
+ u32 fpgaintf_en_3; /* 0x70 */
+ u32 dma_l3master;
+ u32 etr_l3master;
+ u32 _pad_0x7c;
+ u32 sec_ctrl_slt; /* 0x80 */
+ u32 osc_trim;
+ u32 _pad_0x88_0x8c[2];
+ /* ECC Group */
+ u32 ecc_intmask_value; /* 0x90 */
+ u32 ecc_intmask_set;
+ u32 ecc_intmask_clr;
+ u32 ecc_intstatus_serr;
+ u32 ecc_intstatus_derr; /* 0xa0 */
+ u32 _pad_0xa4_0xac[3];
+ u32 noc_addr_remap; /* 0xb0 */
+ u32 hmc_clk;
+ u32 io_pa_ctrl;
+ u32 _pad_0xbc;
+ /* NOC Group */
+ u32 noc_timeout;/* 0xc0 */
+ u32 noc_idlereq_set;
+ u32 noc_idlereq_clr;
+ u32 noc_idlereq_value;
+ u32 noc_idleack;/* 0xd0 */
+ u32 noc_idlestatus;
+ u32 fpga2soc_ctrl;
+ u32 fpga_config;
+ u32 iocsrclk_gate; /* 0xe0 */
+ u32 gpo;
+ u32 gpi;
+ u32 _pad_0xec;
+ u32 mpu;/* 0xf0 */
+ u32 sdm_hps_spare;
+ u32 hps_sdm_spare;
+ u32 _pad_0xfc_0x1fc[65];
+ /* Boot scratch register group */
+ u32 boot_scratch_cold0; /* store qspi ref clock */
+ u32 boot_scratch_cold1; /* store osc1 clock freq */
+ u32 boot_scratch_cold2; /* store fpga clock freq */
+ u32 boot_scratch_cold3;
+ u32 boot_scratch_cold4; /* store PSCI_CPU_ON value */
+ u32 boot_scratch_cold5; /* store PSCI_CPU_ON value */
+ u32 boot_scratch_cold6; /* store VBAR_EL3 value */
+ u32 boot_scratch_cold7; /* store VBAR_EL3 value */
+ u32 boot_scratch_cold8; /* store ECC DBE register */
+ u32 boot_scratch_cold9; /* store ECC DBE address */
+ u32 mpfe_config;
+ u32 mpfe_status;
+ u32 _pad_0x230_0xffc[884];
+ /* Pin select and pin control group */
+ u32 pinsel0[40];/* 0x1000 */
+ u32 _pad_0x10a0_0x10fc[24];
+ u32 pinsel40[8];
+ u32
[U-Boot] [PATCH 14/14] arm: socfpga: agilex: Enable Agilex SoC build
Add build support for Agilex SoC. Signed-off-by: Ley Foon Tan --- arch/arm/Kconfig | 4 +- arch/arm/mach-socfpga/Kconfig | 13 ++ arch/arm/mach-socfpga/Makefile | 9 + configs/socfpga_agilex_defconfig | 57 +++ include/configs/socfpga_agilex_socdk.h | 220 + 5 files changed, 301 insertions(+), 2 deletions(-) create mode 100644 configs/socfpga_agilex_defconfig create mode 100644 include/configs/socfpga_agilex_socdk.h diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index f91c590f6d..45086ccdfe 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -815,7 +815,7 @@ config ARCH_SOCFPGA bool "Altera SOCFPGA family" select ARCH_EARLY_INIT_R select ARCH_MISC_INIT if !TARGET_SOCFPGA_ARRIA10 - select ARM64 if TARGET_SOCFPGA_STRATIX10 + select ARM64 if TARGET_SOCFPGA_STRATIX10 || TARGET_SOCFPGA_AGILEX select CPU_V7A if TARGET_SOCFPGA_GEN5 || TARGET_SOCFPGA_ARRIA10 select DM select DM_SERIAL @@ -827,7 +827,7 @@ config ARCH_SOCFPGA select SPL_LIBGENERIC_SUPPORT select SPL_NAND_SUPPORT if SPL_NAND_DENALI select SPL_OF_CONTROL - select SPL_SEPARATE_BSS if TARGET_SOCFPGA_STRATIX10 + select SPL_SEPARATE_BSS if TARGET_SOCFPGA_STRATIX10 || TARGET_SOCFPGA_AGILEX select SPL_SERIAL_SUPPORT select SPL_WATCHDOG_SUPPORT select SUPPORT_SPL diff --git a/arch/arm/mach-socfpga/Kconfig b/arch/arm/mach-socfpga/Kconfig index ea316d09d7..5c37583de5 100644 --- a/arch/arm/mach-socfpga/Kconfig +++ b/arch/arm/mach-socfpga/Kconfig @@ -20,6 +20,12 @@ config SYS_TEXT_BASE default 0x0140 if TARGET_SOCFPGA_ARRIA10 default 0x0140 if TARGET_SOCFPGA_GEN5 +config TARGET_SOCFPGA_AGILEX + bool + select ARMV8_MULTIENTRY + select ARMV8_SET_SMPEN + select ARMV8_SPIN_TABLE + config TARGET_SOCFPGA_ARRIA5 bool select TARGET_SOCFPGA_GEN5 @@ -64,6 +70,10 @@ choice prompt "Altera SOCFPGA board select" optional +config TARGET_SOCFPGA_AGILEX_SOCDK + bool "Intel SOCFPGA SoCDK (Agilex)" + select TARGET_SOCFPGA_AGILEX + config TARGET_SOCFPGA_ARRIA10_SOCDK bool "Altera SOCFPGA SoCDK (Arria 10)" select TARGET_SOCFPGA_ARRIA10 @@ -120,6 +130,7 @@ config TARGET_SOCFPGA_TERASIC_SOCKIT endchoice config SYS_BOARD + default "agilex-socdk" if TARGET_SOCFPGA_AGILEX_SOCDK default "arria5-socdk" if TARGET_SOCFPGA_ARRIA5_SOCDK default "arria10-socdk" if TARGET_SOCFPGA_ARRIA10_SOCDK default "cyclone5-socdk" if TARGET_SOCFPGA_CYCLONE5_SOCDK @@ -135,6 +146,7 @@ config SYS_BOARD default "vining_fpga" if TARGET_SOCFPGA_SAMTEC_VINING_FPGA config SYS_VENDOR + default "intel" if TARGET_SOCFPGA_AGILEX_SOCDK default "altera" if TARGET_SOCFPGA_ARRIA5_SOCDK default "altera" if TARGET_SOCFPGA_ARRIA10_SOCDK default "altera" if TARGET_SOCFPGA_CYCLONE5_SOCDK @@ -151,6 +163,7 @@ config SYS_SOC default "socfpga" config SYS_CONFIG_NAME + default "socfpga_agilex_socdk" if TARGET_SOCFPGA_AGILEX_SOCDK 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 diff --git a/arch/arm/mach-socfpga/Makefile b/arch/arm/mach-socfpga/Makefile index 476dcaefff..774d3571ef 100644 --- a/arch/arm/mach-socfpga/Makefile +++ b/arch/arm/mach-socfpga/Makefile @@ -42,6 +42,14 @@ endif ifdef CONFIG_TARGET_SOCFPGA_AGILEX obj-y += clock_manager_agilex.o +obj-y += mailbox_s10.o +obj-y += misc_s10.o +obj-y += mmu-arm64_s10.o +obj-y += reset_manager_s10.o +obj-y += system_manager_s10.o +obj-y += timer_s10.o +obj-y += wrap_pinmux_config_s10.o +obj-y += wrap_pll_config_s10.o endif ifdef CONFIG_SPL_BUILD @@ -61,6 +69,7 @@ obj-y += spl_s10.o endif ifdef CONFIG_TARGET_SOCFPGA_AGILEX obj-y += ccu_agilex.o +obj-y += firewall.o obj-y += spl_agilex.o endif endif diff --git a/configs/socfpga_agilex_defconfig b/configs/socfpga_agilex_defconfig new file mode 100644 index 00..bb09a80db2 --- /dev/null +++ b/configs/socfpga_agilex_defconfig @@ -0,0 +1,57 @@ +CONFIG_ARM=y +CONFIG_ARCH_SOCFPGA=y +CONFIG_SYS_TEXT_BASE=0x1000 +CONFIG_SYS_MALLOC_F_LEN=0x2000 +CONFIG_NR_DRAM_BANKS=2 +CONFIG_TARGET_SOCFPGA_AGILEX_SOCDK=y +CONFIG_IDENT_STRING="socfpga_agilex" +CONFIG_SPL_FS_FAT=y +CONFIG_BOOTDELAY=5 +CONFIG_SPL_TEXT_BASE=0xFFE0 +CONFIG_SPL_SPI_LOAD=y +CONFIG_HUSH_PARSER=y +CONFIG_SYS_PROMPT="SOCFPGA_AGILEX # " +CONFIG_CMD_MEMTEST=y +# CONFIG_CMD_FLASH is not set +CONFIG_CMD_GPIO=y +CONFIG_CMD_I2C=y +CONFIG_CMD_MMC=y +CONFIG_CMD_SF=y +CONFIG_CMD_SPI=y +CONFIG_CMD_USB=y +CONFIG_CMD_DHCP=y +CONFIG_CMD_MII=y +CONFIG_CMD_PING=y +CONFIG_CMD_CACHE=y +CONFIG_CMD_EXT4=y +CONFIG_CMD_FAT=y +CONFIG_CMD_FS_GENERIC=y +CONFIG_OF_EMBED=y
[U-Boot] [PATCH 01/14] arm: socfpga: agilex: Add base address for Intel Agilex SoC
Add base address for Intel Agilex SoC. Signed-off-by: Ley Foon Tan --- .../include/mach/base_addr_agilex.h | 38 +++ 1 file changed, 38 insertions(+) create mode 100644 arch/arm/mach-socfpga/include/mach/base_addr_agilex.h diff --git a/arch/arm/mach-socfpga/include/mach/base_addr_agilex.h b/arch/arm/mach-socfpga/include/mach/base_addr_agilex.h new file mode 100644 index 00..e90b61f29d --- /dev/null +++ b/arch/arm/mach-socfpga/include/mach/base_addr_agilex.h @@ -0,0 +1,38 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +/* + * Copyright (C) 2016-2017 Intel Corporation + */ + +#ifndef _SOCFPGA_AGILEX_BASE_HARDWARE_H_ +#define _SOCFPGA_AGILEX_BASE_HARDWARE_H_ + +#define SOCFPGA_CCU_ADDRESS0xf700 +#define SOCFPGA_FW_MPU_DDR_SCR_ADDRESS 0xf8020200 +#define SOCFPGA_SMMU_ADDRESS 0xfa00 +#define SOCFPGA_MAILBOX_ADDRESS0xffa3 +#define SOCFPGA_SPTIMER0_ADDRESS 0xffc03000 +#define SOCFPGA_SPTIMER1_ADDRESS 0xffc03100 +#define SOCFPGA_SYSTIMER0_ADDRESS 0xffd0 +#define SOCFPGA_SYSTIMER1_ADDRESS 0xffd00100 +#define SOCFPGA_L4WD0_ADDRESS 0xffd00200 +#define SOCFPGA_L4WD1_ADDRESS 0xffd00300 +#define SOCFPGA_L4WD2_ADDRESS 0xffd00400 +#define SOCFPGA_L4WD3_ADDRESS 0xffd00500 +#define SOCFPGA_GTIMER_SEC_ADDRESS 0xffd01000 +#define SOCFPGA_GTIMER_NSEC_ADDRESS0xffd02000 +#define SOCFPGA_CLKMGR_ADDRESS 0xffd1 +#define SOCFPGA_RSTMGR_ADDRESS 0xffd11000 +#define SOCFPGA_SYSMGR_ADDRESS 0xffd12000 +#define SOCFPGA_PINMUX_DEDICATED_IO_ADDRESS0xffd13000 +#define SOCFPGA_FIREWALL_L4_PER0xffd21000 +#define SOCFPGA_FIREWALL_L4_SYS0xffd21100 +#define SOCFPGA_FIREWALL_SOC2FPGA 0xffd21200 +#define SOCFPGA_FIREWALL_LWSOC2FPGA0xffd21300 +#define SOCFPGA_FIREWALL_TCU 0xffd21400 +#define SOCFPGA_DMANONSECURE_ADDRESS 0xffda +#define SOCFPGA_DMASECURE_ADDRESS 0xffda1000 +#define SOCFPGA_OCRAM_ADDRESS 0xffe0 +#define GICD_BASE 0xfffc1000 +#define GICC_BASE 0xfffc2000 + +#endif /* _SOCFPGA_AGILEX_BASE_HARDWARE_H_ */ -- 2.19.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 03/14] arm: socfpga: Move Stratix10 and Agilex reset manager common code
Move Stratix10 and Agilex reset manager common code to reset.h.
Remove unused RSTMGR_XXX defines.
Signed-off-by: Ley Foon Tan
---
.../mach-socfpga/include/mach/reset_manager.h | 26 ++
.../include/mach/reset_manager_s10.h | 80 ---
2 files changed, 26 insertions(+), 80 deletions(-)
diff --git a/arch/arm/mach-socfpga/include/mach/reset_manager.h
b/arch/arm/mach-socfpga/include/mach/reset_manager.h
index 42beaecdd6..e2dce4b4fb 100644
--- a/arch/arm/mach-socfpga/include/mach/reset_manager.h
+++ b/arch/arm/mach-socfpga/include/mach/reset_manager.h
@@ -36,6 +36,32 @@ void socfpga_per_reset_all(void);
/* Create a human-readable reference to SoCFPGA reset. */
#define SOCFPGA_RESET(_name) RSTMGR_##_name
+#if defined(CONFIG_TARGET_SOCFPGA_STRATIX10)
+
+void reset_deassert_peripherals_handoff(void);
+int cpu_has_been_warmreset(void);
+void socfpga_bridges_reset(int enable);
+
+#define RSTMGR_MPUMODRST_CORE0 0
+#define RSTMGR_PER0MODRST_OCP_MASK 0x0020bf00
+#define RSTMGR_BRGMODRST_DDRSCH_MASK 0X0040
+#define RSTMGR_BRGMODRST_FPGA2SOC_MASK 0x0004
+
+/* Watchdogs and MPU warm reset mask */
+#define RSTMGR_L4WD_MPU_WARMRESET_MASK 0x000F0F00
+
+/*
+ * SocFPGA Stratix10 reset IDs, bank mapping is as follows:
+ * 0 ... mpumodrst
+ * 1 ... per0modrst
+ * 2 ... per1modrst
+ * 3 ... brgmodrst
+ */
+#define RSTMGR_L4WD0 RSTMGR_DEFINE(2, 0)
+#define RSTMGR_OSC1TIMER0 RSTMGR_DEFINE(2, 4)
+#define RSTMGR_UART0 RSTMGR_DEFINE(2, 16)
+#endif
+
#if defined(CONFIG_TARGET_SOCFPGA_GEN5)
#include
#elif defined(CONFIG_TARGET_SOCFPGA_ARRIA10)
diff --git a/arch/arm/mach-socfpga/include/mach/reset_manager_s10.h
b/arch/arm/mach-socfpga/include/mach/reset_manager_s10.h
index b93bbaf537..2d78c804c6 100644
--- a/arch/arm/mach-socfpga/include/mach/reset_manager_s10.h
+++ b/arch/arm/mach-socfpga/include/mach/reset_manager_s10.h
@@ -7,15 +7,6 @@
#ifndef_RESET_MANAGER_S10_
#define_RESET_MANAGER_S10_
-void reset_cpu(ulong addr);
-void reset_deassert_peripherals_handoff(void);
-int cpu_has_been_warmreset(void);
-
-void socfpga_bridges_reset(int enable);
-
-void socfpga_per_reset(u32 reset, int set);
-void socfpga_per_reset_all(void);
-
struct socfpga_reset_manager {
u32 status;
u32 mpu_rst_stat;
@@ -45,75 +36,4 @@ struct socfpga_reset_manager {
u32 dbghdsktimeout;
};
-#define RSTMGR_MPUMODRST_CORE0 0
-#define RSTMGR_PER0MODRST_OCP_MASK 0x0020bf00
-#define RSTMGR_BRGMODRST_DDRSCH_MASK 0X0040
-#define RSTMGR_BRGMODRST_FPGA2SOC_MASK 0x0004
-
-/* Watchdogs and MPU warm reset mask */
-#define RSTMGR_L4WD_MPU_WARMRESET_MASK 0x000F0F00
-
-/*
- * 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_OFFSET0
-#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 Stratix10 reset IDs, bank mapping is as follows:
- * 0 ... mpumodrst
- * 1 ... per0modrst
- * 2 ... per1modrst
- * 3 ... brgmodrst
- */
-#define RSTMGR_EMAC0 RSTMGR_DEFINE(1, 0)
-#define RSTMGR_EMAC1 RSTMGR_DEFINE(1, 1)
-#define RSTMGR_EMAC2 RSTMGR_DEFINE(1, 2)
-#define RSTMGR_USB0RSTMGR_DEFINE(1, 3)
-#define RSTMGR_USB1RSTMGR_DEFINE(1, 4)
-#define RSTMGR_NANDRSTMGR_DEFINE(1, 5)
-#define RSTMGR_SDMMC RSTMGR_DEFINE(1, 7)
-#define RSTMGR_EMAC0_OCP RSTMGR_DEFINE(1, 8)
-#define RSTMGR_EMAC1_OCP RSTMGR_DEFINE(1, 9)
-#define RSTMGR_EMAC2_OCP RSTMGR_DEFINE(1, 10)
-#define RSTMGR_USB0_OCPRSTMGR_DEFINE(1, 11)
-#define RSTMGR_USB1_OCPRSTMGR_DEFINE(1, 12)
-#define RSTMGR_NAND_OCPRSTMGR_DEFINE(1, 13)
-#define RSTMGR_SDMMC_OCP RSTMGR_DEFINE(1, 15)
-#define RSTMGR_DMA RSTMGR_DEFINE(1, 16)
-#define RSTMGR_SPIM0 RSTMGR_DEFINE(1, 17)
-#define RSTMGR_SPIM1 RSTMGR_DEFINE(1, 18)
-#define RSTMGR_L4WD0 RSTMGR_DEFINE(2, 0)
-#define RSTMGR_L4WD1 RSTMGR_DEFINE(2, 1)
-#define RSTMGR_L4WD2 RSTMGR_DEFINE(2, 2)
-#define RSTMGR_L4WD3 RSTMGR_DEFINE(2, 3)
-#define RSTMGR_OSC1TIMER0 RSTMGR_DEFINE(2, 4)
-#define RSTMGR_I2C0RSTMGR_DEFINE(2, 8)
-#define RSTMGR_I2C1RSTMGR_DEFINE(2, 9)
-#define RSTMGR_I2C2RSTMGR_DEFINE(2, 10)
-#define RSTMGR_I2C3
[U-Boot] [PATCH 00/14] Add Intel Agilex SoC support
This patchset add Intel Agilex SoC[1] support.
Intel Agilex SoC is with a 64-bit quad core ARM Cortex-A53 MPCore
hard processor system (HPS). New IPs in Agilex are CCU, clock manager and SDRAM,
other IPs have minor changes compared to Stratix 10.
Intel Agilex HPS TRM:
https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/hb/agilex/mnl-1100.pdf
[1]:
https://www.intel.com/content/www/us/en/products/programmable/fpga/agilex.html
Ley Foon Tan (14):
arm: socfpga: agilex: Add base address for Intel Agilex SoC
arm: socfpga: Move firewall code to firewall file
arm: socfpga: Move Stratix10 and Agilex reset manager common code
arm: socfpga: agilex: Add reset manager support
arm: socfpga: Move Stratix10 and Agilex system manager common code
arm: socfpga: agilex: Add system manager support
arm: socfpga: agilex: Add clock manager support
arm: socfpga: agilex: Add CCU support for Agilex
ddr: altera: Restructure Stratix 10 SDRAM driver
ddr: altera: agilex: Add SDRAM driver for Agilex
board: intel: agilex: Add socdk board support for Intel Agilex SoC
arm: socfpga: agilex: Add SPL for Agilex SoC
arm: dts: agilex: Add base dtsi and devkit dts
arm: socfpga: agilex: Enable Agilex SoC build
arch/arm/Kconfig | 4 +-
arch/arm/dts/Makefile | 1 +
arch/arm/dts/socfpga_agilex.dtsi | 459 ++
arch/arm/dts/socfpga_agilex_socdk-u-boot.dtsi | 59 ++
arch/arm/dts/socfpga_agilex_socdk.dts | 131
arch/arm/mach-socfpga/Kconfig | 13 +
arch/arm/mach-socfpga/Makefile| 18 +
arch/arm/mach-socfpga/ccu_agilex.c| 99 +++
arch/arm/mach-socfpga/clock_manager_agilex.c | 582 ++
arch/arm/mach-socfpga/firewall.c | 97 +++
.../include/mach/base_addr_agilex.h | 38 ++
.../mach-socfpga/include/mach/ccu_agilex.h| 67 ++
.../mach-socfpga/include/mach/clock_manager.h | 2 +
.../include/mach/clock_manager_agilex.h | 328 ++
.../mach/{firewall_s10.h => firewall.h} | 10 +-
.../mach-socfpga/include/mach/reset_manager.h | 29 +
.../include/mach/reset_manager_agilex.h | 38 ++
.../include/mach/reset_manager_s10.h | 80 ---
.../include/mach/system_manager.h | 53 ++
..._manager_s10.h => system_manager_agilex.h} | 89 +--
.../include/mach/system_manager_s10.h | 46 --
arch/arm/mach-socfpga/reset_manager.c | 9 +-
arch/arm/mach-socfpga/spl_agilex.c| 105
arch/arm/mach-socfpga/spl_s10.c | 84 +--
board/intel/agilex-socdk/MAINTAINERS | 7 +
board/intel/agilex-socdk/Makefile | 7 +
board/intel/agilex-socdk/socfpga.c| 7 +
configs/socfpga_agilex_defconfig | 57 ++
drivers/ddr/altera/Kconfig| 6 +-
drivers/ddr/altera/Makefile | 3 +-
drivers/ddr/altera/sdram_agilex.c | 158 +
drivers/ddr/altera/sdram_common.c | 308 +
.../altera/{sdram_s10.h => sdram_common.h}| 75 +--
drivers/ddr/altera/sdram_s10.c| 302 +
drivers/ddr/altera/sdram_s10.h| 148 -
include/configs/socfpga_agilex_socdk.h| 220 +++
36 files changed, 2966 insertions(+), 773 deletions(-)
create mode 100644 arch/arm/dts/socfpga_agilex.dtsi
create mode 100644 arch/arm/dts/socfpga_agilex_socdk-u-boot.dtsi
create mode 100644 arch/arm/dts/socfpga_agilex_socdk.dts
create mode 100644 arch/arm/mach-socfpga/ccu_agilex.c
create mode 100644 arch/arm/mach-socfpga/clock_manager_agilex.c
create mode 100644 arch/arm/mach-socfpga/firewall.c
create mode 100644 arch/arm/mach-socfpga/include/mach/base_addr_agilex.h
create mode 100644 arch/arm/mach-socfpga/include/mach/ccu_agilex.h
create mode 100644 arch/arm/mach-socfpga/include/mach/clock_manager_agilex.h
rename arch/arm/mach-socfpga/include/mach/{firewall_s10.h => firewall.h} (94%)
create mode 100644 arch/arm/mach-socfpga/include/mach/reset_manager_agilex.h
copy arch/arm/mach-socfpga/include/mach/{system_manager_s10.h =>
system_manager_agilex.h} (51%)
create mode 100644 arch/arm/mach-socfpga/spl_agilex.c
create mode 100644 board/intel/agilex-socdk/MAINTAINERS
create mode 100644 board/intel/agilex-socdk/Makefile
create mode 100644 board/intel/agilex-socdk/socfpga.c
create mode 100644 configs/socfpga_agilex_defconfig
create mode 100644 drivers/ddr/altera/sdram_agilex.c
create mode 100644 drivers/ddr/altera/sdram_common.c
copy drivers/ddr/altera/{sdram_s10.h => sdram_common.h} (78%)
create mode 100644 include/configs/socfpga_agilex_socdk.h
--
2.19.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3] board/BuR/zynq/brsmarc2: initial commit
This commit adds the first of a few more Xilinx ZYNQ based SoM boards.
The SoM is based on Xilinx Zynq 7000 SoC.
Mainly vxWorks 6.9.4.x is running on the board,
doing some PLC stuff on various carrier boards.
Signed-off-by: Hannes Schmelzer
---
Changes in v3:
- drop silicon version 1/2 from ps7_init_gpl.c (they are obsolete)
- board.c: drop obsolete board_eth_init(...)
- board.c: strip down dram_init(..)
- board.c: drop unused #include
- board.c: cleanup comments
- move CONFIG_ZYNQ_SERIAL from boardheader to Kconfig
- move CONFIG_FPGA_ZYNQPL from boardheader to Kconfig
- fix comments in boardheader
- drop *_SYS_LDSCRIPT from boardheader (defined in Kconfig)
- drop CONFIG_SYS_MALLOC_LEN (defined in Kconfig)
- dop CONFIG_ENV_SPI_MAX_HZ from boardheader (defined in Kconfig)
- dts: split vxWorks specific parts away from dts into separate file
- dts: add compatible string to factory-settings node
- dts: drop invalid (zero)= mac-addresses on gem0/gem1
- dts: fixup style on ethernet_phy1 description
- dts: add comments to phy's
- drop helper-scripts for taking vivado handoff files into tree
Changes in v2:
- fix SDPX tag in Make-files/rules
arch/arm/dts/Makefile | 2 +
arch/arm/dts/zynq-brsmarc2-common.dtsi | 168 +
arch/arm/dts/zynq-brsmarc2-vxworks.dtsi | 123 +
arch/arm/dts/zynq-brsmarc2.dts | 15 ++
arch/arm/dts/zynq-brsmarc2_r512.dts | 15 ++
board/BuR/zynq/.gitignore | 1 +
board/BuR/zynq/MAINTAINERS | 6 +
board/BuR/zynq/Makefile | 16 ++
board/BuR/zynq/brsmarc2/board.c | 63 +++
board/BuR/zynq/brsmarc2/ps7_init_gpl.c | 276
board/BuR/zynq/brsmarc2_r512/board.c| 2 +
board/BuR/zynq/brsmarc2_r512/ps7_init_gpl.c | 276
board/BuR/zynq/config.mk| 49 +
configs/brsmarc2_defconfig | 74
configs/brsmarc2_r512_defconfig | 74
include/configs/brsmarc2.h | 157
16 files changed, 1317 insertions(+)
create mode 100644 arch/arm/dts/zynq-brsmarc2-common.dtsi
create mode 100644 arch/arm/dts/zynq-brsmarc2-vxworks.dtsi
create mode 100644 arch/arm/dts/zynq-brsmarc2.dts
create mode 100644 arch/arm/dts/zynq-brsmarc2_r512.dts
create mode 100644 board/BuR/zynq/.gitignore
create mode 100644 board/BuR/zynq/MAINTAINERS
create mode 100644 board/BuR/zynq/Makefile
create mode 100644 board/BuR/zynq/brsmarc2/board.c
create mode 100644 board/BuR/zynq/brsmarc2/ps7_init_gpl.c
create mode 100644 board/BuR/zynq/brsmarc2_r512/board.c
create mode 100644 board/BuR/zynq/brsmarc2_r512/ps7_init_gpl.c
create mode 100644 board/BuR/zynq/config.mk
create mode 100644 configs/brsmarc2_defconfig
create mode 100644 configs/brsmarc2_r512_defconfig
create mode 100644 include/configs/brsmarc2.h
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index dfa5b02..2b00129 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -208,6 +208,8 @@ dtb-$(CONFIG_ARCH_ZYNQ) += \
zynq-zc770-xm011-x16.dtb \
zynq-zc770-xm012.dtb \
zynq-zc770-xm013.dtb \
+ zynq-brsmarc2.dtb \
+ zynq-brsmarc2_r512.dtb \
zynq-zed.dtb \
zynq-zturn.dtb \
zynq-zybo.dtb \
diff --git a/arch/arm/dts/zynq-brsmarc2-common.dtsi
b/arch/arm/dts/zynq-brsmarc2-common.dtsi
new file mode 100644
index 000..ac6c85a
--- /dev/null
+++ b/arch/arm/dts/zynq-brsmarc2-common.dtsi
@@ -0,0 +1,168 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * common DTS part for B BRSMARC2 boards
+ *
+ * Copyright (C) 2019 B Industrial Automation GmbH
+ */
+
+/dts-v1/;
+#include "zynq-7000.dtsi"
+#include
+#include
+
+/ {
+ model = "BRSMARC2 Zynq SoM";
+ compatible = "xlnx,zynq-7000";
+
+ aliases {
+ ethernet0 =
+ ethernet1 =
+ i2c0 =
+ serial0 =
+ spi0 =
+ mmc0 =
+ can0 =
+ can1 =
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0x0 0x2000>;
+ };
+
+ chosen {
+ bootargs = "console=ttyPS0,115200 earlyprintk";
+ stdout-path = "serial0:115200n8";
+ };
+
+ usb_phy0: phy0 {
+ compatible = "usb-nop-xceiv";
+ #phy-cells = <0>;
+ };
+
+ board_thermal: board-thermal {
+ polling-delay-passive = <1000>; /* milliseconds */
+ polling-delay = <2500>; /* milliseconds */
+
+ thermal-sensors = <_core 0>;
+
+ trips {
+ crit_trip: crit-trip {
+ temperature = <10>; /* millicelsius */
+ hysteresis = <5000>; /* millicelsius */
+ type = "critical";
+
Re: [U-Boot] [PATCH v2] board/BuR/zynq/brsmarc2: initial commit
On 5/9/19 11:49 PM, Michal Simek wrote:
On 08. 05. 19 5:37, Hannes Schmelzer wrote:
On 5/3/19 6:29 PM, Michal Simek wrote:
On 03. 05. 19 6:18, Tom Rini wrote:
On Fri, May 03, 2019 at 01:34:24PM +0200, Hannes Schmelzer wrote:
On 5/2/19 9:03 PM, Tom Rini wrote:
On Thu, May 02, 2019 at 08:34:32PM +0200, Hannes Schmelzer wrote:
On 5/2/19 6:06 PM, Michal Simek wrote:
Hi,
Hi Michal,
On 02. 05. 19 5:14, Hannes Schmelzer wrote:
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index dfa5b02..2b00129 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -208,6 +208,8 @@ dtb-$(CONFIG_ARCH_ZYNQ) += \
zynq-zc770-xm011-x16.dtb \
zynq-zc770-xm012.dtb \
zynq-zc770-xm013.dtb \
+ zynq-brsmarc2.dtb \
+ zynq-brsmarc2_r512.dtb \
Can't you detect it if you have 512M version?
u-boot itself has code for these kind of detection.
long get_ram_size(long *base, long maxsize)
I actually think not,
because i need different ps7_init stuff for the two different RAM
chips.
(timing, adress lines, ...) But i will check if i even can drop
the two
different dts files.
+/ {
+ model = "BRSMARC2 Zynq SoM";
+ compatible = "xlnx,zynq-7000";
+
+ fset: factory-settings {
+ bl-version = " ";
+ order-no = " ";
+ cpu-order-no = " ";
+ hw-revision = " ";
+ serial-no = <0>;
+ device-id = <0x0>;
+ parent-id = <0x0>;
+ hw-variant = <0x0>;
+ hw-platform = <0x0>;
+ fram-offset = <0x0>;
+ fram-size = <0x0>;
+ cache-disable = <0x0>;
+ cpu-clock = <0x0>;
+ };
What's this? No compatible string. This looks quite hacky.
This are factory settings, used by the OS (in this case vxWorks),
to identify on which hardware it runs, and have per device unique
stuff
(serial number).
But you're right, it would be nice to have here some compatible
string,
i will change this. Today we just search for the node
"factory-setting".
A more comfortable ways would be vxFdtNodeOffsetByCompatible()
+
+ aliases {
+ ethernet0 =
+ ethernet1 =
+ i2c0 =
+ serial0 =
+ spi0 =
+ mmc0 =
+ fset =
+ can0 =
+ can1 =
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0x0 0x1000>;
+ };
+
+ board {
+ status = "okay";
+ compatible = "bur,brsmarc2-som";
+ usb0mux-gpios = < 68 GPIO_ACTIVE_HIGH>;
+ usb1mux-gpios = < 69 GPIO_ACTIVE_HIGH>;
+ powerdown-gpios = < 0 GPIO_ACTIVE_LOW>;
+ reset-gpios = < 9 GPIO_ACTIVE_LOW>;
+ };
Where is mainline dt binding for this?
Nowhere, because u-boot nor linux does use this,
this is only for the vxWorks OS.
This is what I kinda figured was the case. We now have some
interesting
times ahead of us as yes, we normally think about DTS reviews in terms
of Linux. But this is all for a board that uses vxWorks. Perhaps the
best thing to do here is note (and for all of the other boards too,
but
you can wait for general feedback before v3'ing them all) in the dts
comment that it's for vxWorks as people tend to assume a DTS file
is for
Linux (even with many counter examples).
OK. Thanks.
would it be fine having it like this ?
/* factory-settings for the vxWorks target */
fset: factory-settings {
compatible = "bur,fsetv1";
bl-version = " ";
.
};
/* misc. peripheral, used in vxWorks */
board {
status = "okay";
...
};
Or might be a general description on top would be more helpful?
I think a general comment at the top saying that this tree is only valid
for vxWorks and U-Boot is enough detail.
Okay, i will do so like this:
/*
* This devicetree is only valid for u-boot and the primary OS (vxWorks
6.9.4.x)
* of this board.
*/
It would be much better to simply put vxworks stuff to one dtsi file and
common stuff to another. That it will be clear what it is vxworks part
and what it is common.
In general i pay attention to describe devices as generic as possible,
meaning that a) syntax is correct, b) some linux or even u-boot isn't
disturbed by this descriptions.
With a look to the paragraph below, the implemented UART in FPGA,
is 16550 compatible, so there might be a chance that it would work
with Linux as well.
wrt the UART, are there specified bindings in vxWorks? That seems like
a case where the DTS needs to be valid for what U-Boot says the binding
is (and in turn, what Linux does). And perhaps there's room for
clarifications to those bindings.
actually i think the UART is described valid in the fdt and can be used
by u-boot or linux as well even i've not tested it yet.
I think we need to get more clarity what exactly vxworks expects and
what are just your
Re: [U-Boot] [PATCH 1/3] net: mscc: luton: Update network driver for pcb90
On Thu, May 9, 2019 at 4:22 PM Horatiu Vultur
wrote:
>
> Hi Joe,
>
> The 05/09/2019 21:03, Joe Hershberger wrote:
> > External E-Mail
> >
> >
> > On Wed, May 1, 2019 at 6:18 AM Horatiu Vultur
> > wrote:
> > >
> > > Update Luton network driver to have support also for pcb90. The pcb90
> > > has 24 ports from which 12 ports are connected to SerDes6G.
> >
> > Can you separate this into a restructuring patch and the patch that
> > adds support for this device? This is a bit hard to read.
>
> Well the patch was already applied on the master. So I am not
> sure what I can do.
Interesting. I don't see any mention of an ack or an applied response.
Maybe a different version was applied? I guess it was good enough for
whoever took it.
Cheers,
-Joe
>
> >
> > Thanks,
> > -Joe
> >
> > >
> > > Signed-off-by: Horatiu Vultur
> > > ---
> > > drivers/net/mscc_eswitch/Makefile | 2 +-
> > > drivers/net/mscc_eswitch/luton_switch.c | 415
> > >
> > > 2 files changed, 258 insertions(+), 159 deletions(-)
> > >
> > > diff --git a/drivers/net/mscc_eswitch/Makefile
> > > b/drivers/net/mscc_eswitch/Makefile
> > > index 9c208d1..02f39a7 100644
> > > --- a/drivers/net/mscc_eswitch/Makefile
> > > +++ b/drivers/net/mscc_eswitch/Makefile
> > > @@ -1,6 +1,6 @@
> > >
> > > obj-$(CONFIG_MSCC_OCELOT_SWITCH) += ocelot_switch.o mscc_xfer.o
> > > mscc_mac_table.o
> > > -obj-$(CONFIG_MSCC_LUTON_SWITCH) += luton_switch.o mscc_miim.o
> > > mscc_xfer.o mscc_mac_table.o
> > > +obj-$(CONFIG_MSCC_LUTON_SWITCH) += luton_switch.o mscc_xfer.o
> > > mscc_mac_table.o
> > > obj-$(CONFIG_MSCC_JR2_SWITCH) += jr2_switch.o mscc_xfer.o
> > > obj-$(CONFIG_MSCC_SERVALT_SWITCH) += servalt_switch.o mscc_xfer.o
> > > obj-$(CONFIG_MSCC_SERVAL_SWITCH) += serval_switch.o mscc_xfer.o
> > > mscc_mac_table.o
> > > diff --git a/drivers/net/mscc_eswitch/luton_switch.c
> > > b/drivers/net/mscc_eswitch/luton_switch.c
> > > index 6667614..94852b0 100644
> > > --- a/drivers/net/mscc_eswitch/luton_switch.c
> > > +++ b/drivers/net/mscc_eswitch/luton_switch.c
> > > @@ -15,10 +15,21 @@
> > > #include
> > > #include
> > >
> > > -#include "mscc_miim.h"
> > > #include "mscc_xfer.h"
> > > #include "mscc_mac_table.h"
> > >
> > > +#define GCB_MIIM_MII_STATUS0x0
> > > +#defineGCB_MIIM_STAT_BUSY BIT(3)
> > > +#define GCB_MIIM_MII_CMD 0x8
> > > +#defineGCB_MIIM_MII_CMD_OPR_WRITE BIT(1)
> > > +#defineGCB_MIIM_MII_CMD_OPR_READ BIT(2)
> > > +#defineGCB_MIIM_MII_CMD_WRDATA(x) ((x) << 4)
> > > +#defineGCB_MIIM_MII_CMD_REGAD(x) ((x) <<
> > > 20)
> > > +#defineGCB_MIIM_MII_CMD_PHYAD(x) ((x) <<
> > > 25)
> > > +#defineGCB_MIIM_MII_CMD_VLDBIT(31)
> > > +#define GCB_MIIM_DATA 0xC
> > > +#defineGCB_MIIM_DATA_ERROR (0x2 <<
> > > 16)
> > > +
> > > #define ANA_PORT_VLAN_CFG(x) (0x00 + 0x80 * (x))
> > > #defineANA_PORT_VLAN_CFG_AWARE_ENA BIT(20)
> > > #defineANA_PORT_VLAN_CFG_POP_CNT(x)((x) << 18)
> > > @@ -136,61 +147,53 @@
> > > #define PGID_UNICAST 29
> > > #define PGID_SRC 80
> > >
> > > -enum luton_target {
> > > - PORT0,
> > > - PORT1,
> > > - PORT2,
> > > - PORT3,
> > > - PORT4,
> > > - PORT5,
> > > - PORT6,
> > > - PORT7,
> > > - PORT8,
> > > - PORT9,
> > > - PORT10,
> > > - PORT11,
> > > - PORT12,
> > > - PORT13,
> > > - PORT14,
> > > - PORT15,
> > > - PORT16,
> > > - PORT17,
> > > - PORT18,
> > > - PORT19,
> > > - PORT20,
> > > - PORT21,
> > > - PORT22,
> > > - PORT23,
> > > - SYS,
> > > +static const char * const regs_names[] = {
> > > + "port0", "port1", "port2", "port3", "port4", "port5", "port6",
> > > "port7",
> > > + "port8", "port9", "port10", "port11", "port12", "port13",
> > > "port14",
> > > + "port15", "port16", "port17", "port18", "port19", "port20",
> > > "port21",
> > > + "port22", "port23",
> > > + "sys", "ana", "rew", "gcb", "qs", "hsio",
> > > +};
> > > +
> > > +#define REGS_NAMES_COUNT ARRAY_SIZE(regs_names) + 1
> > > +#define MAX_PORT 24
> > > +
> > > +enum luton_ctrl_regs {
> > > + SYS = MAX_PORT,
> > > ANA,
> > > REW,
> > > GCB,
> > > QS,
> > > - HSIO,
> > > - TARGET_MAX,
> > > + HSIO
> > > };
> > >
> > > -#define MAX_PORT (PORT23 - PORT0 + 1)
> > > +#define MIN_INT_PORT 0
> > > +#define PORT10 10
> > > +#define PORT11 11
> > > +#define MAX_INT_PORT 12
> > > +#define MIN_EXT_PORT MAX_INT_PORT
> > > +#define MAX_EXT_PORT MAX_PORT
> > >
> > > -#define
[U-Boot] [PATCH u-boot-marvell 6/6] arm: mvebu: turris_omnia: call pci_init from board init code
We always want to enumerate PCIe devices, because withouth this they won't work in Linux. Signed-off-by: Marek Behún --- board/CZ.NIC/turris_omnia/turris_omnia.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/board/CZ.NIC/turris_omnia/turris_omnia.c b/board/CZ.NIC/turris_omnia/turris_omnia.c index cddde50b96..db99db0ccf 100644 --- a/board/CZ.NIC/turris_omnia/turris_omnia.c +++ b/board/CZ.NIC/turris_omnia/turris_omnia.c @@ -412,6 +412,9 @@ int board_late_init(void) set_regdomain(); handle_reset_button(); #endif +#ifdef CONFIG_PCI_MVEBU + pci_init(); +#endif return 0; } -- 2.21.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH u-boot-marvell 5/6] arm: mvebu: turris_omnia: prefer SCSI booting before USB
If SCSI and USB boot options are both available, try to boot from SCSI first. Signed-off-by: Marek Behún --- include/configs/turris_omnia.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/configs/turris_omnia.h b/include/configs/turris_omnia.h index 26f85466a4..edd776ec70 100644 --- a/include/configs/turris_omnia.h +++ b/include/configs/turris_omnia.h @@ -92,8 +92,8 @@ #define BOOT_TARGET_DEVICES(func) \ BOOT_TARGET_DEVICES_MMC(func) \ - BOOT_TARGET_DEVICES_USB(func) \ BOOT_TARGET_DEVICES_SCSI(func) \ + BOOT_TARGET_DEVICES_USB(func) \ func(PXE, pxe, na) \ func(DHCP, dhcp, na) -- 2.21.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH u-boot-marvell 2/6] arm: mvebu: turris_omnia: fix adapters MAC addresses
The board code reads MAC addresses from the ATSHA204A cryptochip.
For compatibility reasons the ethernet adapters on this SOC are not
enumerated in register address order. But when Omnia was first
manufactured this was done differently.
Change setting of MAC addresses to conform to the description on the
stickers sticked on actual Omnias.
Signed-off-by: Marek Behún
---
board/CZ.NIC/turris_omnia/turris_omnia.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/board/CZ.NIC/turris_omnia/turris_omnia.c
b/board/CZ.NIC/turris_omnia/turris_omnia.c
index ad6e29021e..cddde50b96 100644
--- a/board/CZ.NIC/turris_omnia/turris_omnia.c
+++ b/board/CZ.NIC/turris_omnia/turris_omnia.c
@@ -514,17 +514,17 @@ int misc_init_r(void)
mac[5] = mac1[3];
if (is_valid_ethaddr(mac))
- eth_env_set_enetaddr("ethaddr", mac);
+ eth_env_set_enetaddr("eth1addr", mac);
increment_mac(mac);
if (is_valid_ethaddr(mac))
- eth_env_set_enetaddr("eth1addr", mac);
+ eth_env_set_enetaddr("eth2addr", mac);
increment_mac(mac);
if (is_valid_ethaddr(mac))
- eth_env_set_enetaddr("eth2addr", mac);
+ eth_env_set_enetaddr("ethaddr", mac);
out:
return 0;
--
2.21.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH u-boot-marvell 4/6] arm: mvebu: turris_omnia: remove unneeded macro from board config
This is not needed here since Omnia is using DM_PCI now. Signed-off-by: Marek Behún --- include/configs/turris_omnia.h | 5 - 1 file changed, 5 deletions(-) diff --git a/include/configs/turris_omnia.h b/include/configs/turris_omnia.h index 8e3d5cc8cf..26f85466a4 100644 --- a/include/configs/turris_omnia.h +++ b/include/configs/turris_omnia.h @@ -28,11 +28,6 @@ #define PHY_ANEG_TIMEOUT 8000/* PHY needs a longer aneg time */ -/* PCIe support */ -#ifndef CONFIG_SPL_BUILD -#define CONFIG_PCI_SCAN_SHOW -#endif - /* Keep device tree and initrd in lower memory so the kernel can access them */ #define RELOCATION_LIMITS_ENV_SETTINGS \ "fdt_high=0x1000\0" \ -- 2.21.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH u-boot-marvell 3/6] arm: mvebu: turris_omnia: change environment address in SPI flash
The U-Boot partition is 1 MiB and environment is 64 KiB. It does not make sense to have environment at 0xc when it could be at 0xf and we can have more space for U-Boot binary. Signed-off-by: Marek Behún --- include/configs/turris_omnia.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/include/configs/turris_omnia.h b/include/configs/turris_omnia.h index 290828d73e..8e3d5cc8cf 100644 --- a/include/configs/turris_omnia.h +++ b/include/configs/turris_omnia.h @@ -22,9 +22,9 @@ #define CONFIG_EHCI_IS_TDI /* Environment in SPI NOR flash */ -#define CONFIG_ENV_OFFSET (3*(1 << 18)) /* 768KiB in */ #define CONFIG_ENV_SIZE(64 << 10) /* 64KiB */ -#define CONFIG_ENV_SECT_SIZE (256 << 10) /* 256KiB sectors */ +#define CONFIG_ENV_OFFSET ((1 << 20) - CONFIG_ENV_SIZE) +#define CONFIG_ENV_SECT_SIZE (64 << 10) /* 64KiB */ #define PHY_ANEG_TIMEOUT 8000/* PHY needs a longer aneg time */ -- 2.21.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH u-boot-marvell 0/6] More fixes for Turris Omnia
Hi Stefan, I am sending five another fixes for Turris Omnia. Marek Marek Behún (6): arm: mvebu: turris_omnia: set default ethernet adapter arm: mvebu: turris_omnia: fix adapters MAC addresses arm: mvebu: turris_omnia: change environment address in SPI flash arm: mvebu: turris_omnia: remove unneeded macro from board config arm: mvebu: turris_omnia: prefer SCSI booting before USB arm: mvebu: turris_omnia: call pci_init from board init code board/CZ.NIC/turris_omnia/turris_omnia.c | 9 ++--- include/configs/turris_omnia.h | 12 2 files changed, 10 insertions(+), 11 deletions(-) -- 2.21.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH u-boot-marvell 1/6] arm: mvebu: turris_omnia: set default ethernet adapter
Set default value for the ethact variable to the WAN port. Signed-off-by: Marek Behún --- include/configs/turris_omnia.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/configs/turris_omnia.h b/include/configs/turris_omnia.h index 018f54428b..290828d73e 100644 --- a/include/configs/turris_omnia.h +++ b/include/configs/turris_omnia.h @@ -122,6 +122,7 @@ LOAD_ADDRESS_ENV_SETTINGS \ "fdtfile=" CONFIG_DEFAULT_DEVICE_TREE ".dtb\0" \ "console=ttyS0,115200\0" \ + "ethact=ethernet@34000\0" \ BOOTENV #endif /* CONFIG_SPL_BUILD */ -- 2.21.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/1] pci: pci_mvebu: ignore the local device
The local device (host "bridge"?) on pci_mvebu controller reports
PCI_CLASS_MEMORY_OTHER in the class register.
This does not work in U-Boot, because U-Boot then tries to autoconfigure
this device in pci_auto.c. This causes the real connected PCIe device
not to work (in U-Boot nor in Linux).
Linux solves this by emulating PCI bridge device (see
drivers/pci/pci-bridge-emul.c in Linux). The Marvell vendor/device IDs
are used for this pci-bridge-emul device in Linux, but the actual
register accesses are emulated and the value of class register is
PCI_CLASS_BRIDGE_PCI.
The simplest solution here in my opinion is to just ignore the local
device in this driver's read/write methods. This fixes PCIe issues for
me.
Signed-off-by: Marek Behún
Cc: Stefan Roese
Cc: Anton Schubert
Cc: Dirk Eibach
Cc: Mario Six
Cc: Chris Packham
Cc: Phil Sutter
Cc: VlaoMao
---
drivers/pci/pci_mvebu.c | 59 +
1 file changed, 24 insertions(+), 35 deletions(-)
diff --git a/drivers/pci/pci_mvebu.c b/drivers/pci/pci_mvebu.c
index e21dc10c2f..653f445a0f 100644
--- a/drivers/pci/pci_mvebu.c
+++ b/drivers/pci/pci_mvebu.c
@@ -143,31 +143,31 @@ static int mvebu_pcie_read_config(struct udevice *bus,
pci_dev_t bdf,
struct mvebu_pcie *pcie = dev_get_platdata(bus);
int local_bus = PCI_BUS(pcie->dev);
int local_dev = PCI_DEV(pcie->dev);
+ int other_dev;
u32 reg;
u32 data;
debug("PCIE CFG read: (b,d,f)=(%2d,%2d,%2d) ",
PCI_BUS(bdf), PCI_DEV(bdf), PCI_FUNC(bdf));
- /* Only allow one other device besides the local one on the local bus */
- if (PCI_BUS(bdf) == local_bus && PCI_DEV(bdf) != local_dev) {
- if (local_dev == 0 && PCI_DEV(bdf) != 1) {
- debug("- out of range\n");
- /*
-* If local dev is 0, the first other dev can
-* only be 1
-*/
- *valuep = pci_get_ff(size);
- return 0;
- } else if (local_dev != 0 && PCI_DEV(bdf) != 0) {
- debug("- out of range\n");
- /*
-* If local dev is not 0, the first other dev can
-* only be 0
-*/
- *valuep = pci_get_ff(size);
- return 0;
- }
+ /*
+* The local device has PCI_CLASS_MEMORY_OTHER in the class register.
+* This does not work for U-Boot because pci_auto.c tries to configure
+* this as a device. This results in U-Boot/Linux being unable to access
+* PCIe devices.
+*
+* Linux solves this by emulating a bridge (see
+* drivers/pci/pci-bridge-emul.c in Linux).
+*
+* Let's ignore the local device in U-Boot.
+*
+* Also only allow one other device besides the (ignored) local one.
+*/
+
+ other_dev = local_dev ? 0 : 1;
+ if (PCI_BUS(bdf) == local_bus && PCI_DEV(bdf) != other_dev) {
+ *valuep = pci_get_ff(size);
+ return 0;
}
/* write address */
@@ -187,28 +187,17 @@ static int mvebu_pcie_write_config(struct udevice *bus,
pci_dev_t bdf,
struct mvebu_pcie *pcie = dev_get_platdata(bus);
int local_bus = PCI_BUS(pcie->dev);
int local_dev = PCI_DEV(pcie->dev);
+ int other_dev;
u32 data;
debug("PCIE CFG write: (b,d,f)=(%2d,%2d,%2d) ",
PCI_BUS(bdf), PCI_DEV(bdf), PCI_FUNC(bdf));
debug("(addr,val)=(0x%04x, 0x%08lx)\n", offset, value);
- /* Only allow one other device besides the local one on the local bus */
- if (PCI_BUS(bdf) == local_bus && PCI_DEV(bdf) != local_dev) {
- if (local_dev == 0 && PCI_DEV(bdf) != 1) {
- /*
-* If local dev is 0, the first other dev can
-* only be 1
-*/
- return 0;
- } else if (local_dev != 0 && PCI_DEV(bdf) != 0) {
- /*
-* If local dev is not 0, the first other dev can
-* only be 0
-*/
- return 0;
- }
- }
+ /* See the comment in mvebu_pcie_read_config */
+ other_dev = local_dev ? 0 : 1;
+ if (PCI_BUS(bdf) == local_bus && PCI_DEV(bdf) != other_dev)
+ return 0;
writel(PCIE_CONF_ADDR(bdf, offset), pcie->base + PCIE_CONF_ADDR_OFF);
data = pci_conv_size_to_32(0, value, offset, size);
--
2.21.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] x86: ich-spi: Convert driver to spi-mem ops
Hi Bernhard, On Mon, 1 Apr 2019 at 02:33, Bernhard Messerklinger wrote: > > With the introduction of the new spi-mem model operations changed > slightly, which broke the ich-spi driver. The new spi-mem operations > make things a bit easier to handle for ich flash interface. This patch > makes ich-spi work again by using spi-mem operations. > > Signed-off-by: Bernhard Messerklinger > > --- > Unfortunately I only have apollo lake HW so I can't test > with the other boards. Please give feedback if anybody is interested in > this patch or any errors appear. > > drivers/spi/ich.c | 250 +- > drivers/spi/ich.h | 9 +- > 2 files changed, 96 insertions(+), 163 deletions(-) This seems to make read work again. But it does not fix 'sf test'. => sf test 0 1000 SPI flash test: 0 erase: 0 ticks, 4096000 KiB/s 32768.000 Mbps 1 check: 2 ticks, 2000 KiB/s 16.000 Mbps 2 write: 0 ticks, 4096000 KiB/s 32768.000 Mbps 3 read: 2 ticks, 2000 KiB/s 16.000 Mbps Verify failed at 0, good data: : fa fc 0f 20 c0 0d 00 00 00 60 0f 22 c0 0f 09 bb... .`." 0010: 00 00 02 00 bd 00 00 00 00 eb 0c 90 78 56 34 12xV4. 0020: bb 00 00 01 00 89 c5 89 ce b8 18 00 00 00 8e e0 0030: 8e d8 8e e8 8e c0 8e d0 0f 01 1d a1 00 e0 ff e9 Bad data: : ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 0010: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 0020: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 0030: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Test failed Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] fit signature: Add fallback of required keys
On Mon, Apr 22, 2019 at 04:28:01PM -0500, Sam Voss wrote: > Validation of fit image configuration signatures does not seem to do a > "fall-back" mechanism as mentioned in doc/uImage.FIT/signature.txt. > > The current constraints seem to only allow the following: > > - skipping keys not marked "required" (not attempting to validate > with them at all) > - checking a key marked required, but if it does not pass the validation > entirely fails (no fall-back) > > This patch keeps the non-required mechanism, however changes the > required key logic to check all keys until a key that can validate the > configuration is found. If none is found, an error is raised as before > and boot is halted. > > Signed-off-by: Sam Voss This breaks 'make tests' as it doesn't update the tests, please fix, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Pull request v2: u-boot-rockchip/tags/rockchip-for-v2019.07-rc1
On Thu, May 09, 2019 at 06:44:05PM +0800, Kever Yang wrote: > Here is the v2 of second batch of changes for the Rockchip repository. > Drop support for rk3399 neo4, rockpro64, rock-pi boards support since v1. > > Clean bill-of-health in Travis-CI at > > https://travis-ci.org/keveryang/u-boot/builds/529695743 > > And I have test on all evb of Rockchip SoCs. > > Thanks, > - Kever > > The following changes since commit 8d7f06bbbef16f172cd5e9c4923cdcebe16b8980: > > Merge branch 'master' of git://git.denx.de/u-boot-sh (2019-05-07 09:38:00 > -0400) > > are available in the Git repository at: > > git://git.denx.de/u-boot-rockchip.git tags/rockchip-for-v2019.07-rc1 > > for you to fetch changes up to c661c059b9a507baa1704c03f29ff2f79bae2ce2: > > doc: rockchip: Add global doc for rk3399 build/flash (2019-05-09 18:24:31 > +0800) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-marvell/master
On Thu, May 09, 2019 at 12:08:29PM +0200, Stefan Roese wrote: > Hi Tom, > > please pull the following Marvell related patches: > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PULL u-boot] Please pull u-boot-amlogic-20190509
On Thu, May 09, 2019 at 10:42:42AM +0200, Neil Armstrong wrote: > Hi Tom, > > This PR add support for USB on Amlogic G12A, Marek and Lukasz acked me for > sending these patches via the amlogic u-boot tree. > > Thanks, > Neil > > The following changes since commit 504bf790da08db9b4a443566cf6ef577f9c7996a: > > Merge branch 'master' of git://git.denx.de/u-boot-sunxi (2019-05-08 > 16:21:43 -0400) > > are available in the Git repository at: > > git://git.denx.de/u-boot-amlogic.git tags/u-boot-amlogic-20190509 > > for you to fetch changes up to 92d911b2eedec8fee1f494ab961585e253351d4f: > > mach-meson: g12a: add DWC2 peripheral mode support (2019-05-09 10:38:32 > +0200) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-riscv/master
On Thu, May 09, 2019 at 05:08:08PM +0800, ub...@andestech.com wrote: > Hi Tom, > > Please pull some riscv updates: > > - Correct SYS_TEXT_BASE for qemu. > - Support booti. > - Increase SYSBOOTM_LEN for Fedora/RISCV kernel. > - Support SMP booting from flash. > > https://travis-ci.org/rickchen36/u-boot-riscv/builds/530082266 > > Thanks > Rick > > > The following changes since commit 504bf790da08db9b4a443566cf6ef577f9c7996a: > > Merge branch 'master' of git://git.denx.de/u-boot-sunxi (2019-05-08 > 16:21:43 -0400) > > are available in the Git repository at: > > git://git.denx.de/u-boot-riscv.git > > for you to fetch changes up to 3cedc97479ff44cdc00485de7517a833e3dfb630: > > RISCV: image: Add booti support (2019-05-09 16:47:52 +0800) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-net.git master
On Wed, May 08, 2019 at 05:30:11PM -0500, Joe Hershberger wrote: > Hi Tom, > > This is the series with the AR8xxx phy series removed until we figure it out. > > Tested to work fine on your evm. > > The following changes since commit 8d7f06bbbef16f172cd5e9c4923cdcebe16b8980: > > Merge branch 'master' of git://git.denx.de/u-boot-sh (2019-05-07 09:38:00 > -0400) > > are available in the git repository at: > > git://git.denx.de/u-boot-net.git master > > for you to fetch changes up to 6314d1c8c035d1c4d14ea1ffd133f25385edd067: > > net: phy: micrel: Find Micrel PHY node correctly (2019-05-08 17:27:01 -0500) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] board/BuR/zynq/brsmarc2: initial commit
On 08. 05. 19 5:37, Hannes Schmelzer wrote:
>
>
> On 5/3/19 6:29 PM, Michal Simek wrote:
>> On 03. 05. 19 6:18, Tom Rini wrote:
>>> On Fri, May 03, 2019 at 01:34:24PM +0200, Hannes Schmelzer wrote:
On 5/2/19 9:03 PM, Tom Rini wrote:
> On Thu, May 02, 2019 at 08:34:32PM +0200, Hannes Schmelzer wrote:
>> On 5/2/19 6:06 PM, Michal Simek wrote:
>>> Hi,
>> Hi Michal,
>>> On 02. 05. 19 5:14, Hannes Schmelzer wrote:
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index dfa5b02..2b00129 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -208,6 +208,8 @@ dtb-$(CONFIG_ARCH_ZYNQ) += \
zynq-zc770-xm011-x16.dtb \
zynq-zc770-xm012.dtb \
zynq-zc770-xm013.dtb \
+ zynq-brsmarc2.dtb \
+ zynq-brsmarc2_r512.dtb \
>>> Can't you detect it if you have 512M version?
>>> u-boot itself has code for these kind of detection.
>>>
>>> long get_ram_size(long *base, long maxsize)
>> I actually think not,
>> because i need different ps7_init stuff for the two different RAM
>> chips.
>> (timing, adress lines, ...) But i will check if i even can drop
>> the two
>> different dts files.
+/ {
+ model = "BRSMARC2 Zynq SoM";
+ compatible = "xlnx,zynq-7000";
+
+ fset: factory-settings {
+ bl-version = " ";
+ order-no = " ";
+ cpu-order-no = " ";
+ hw-revision = " ";
+ serial-no = <0>;
+ device-id = <0x0>;
+ parent-id = <0x0>;
+ hw-variant = <0x0>;
+ hw-platform = <0x0>;
+ fram-offset = <0x0>;
+ fram-size = <0x0>;
+ cache-disable = <0x0>;
+ cpu-clock = <0x0>;
+ };
>>> What's this? No compatible string. This looks quite hacky.
>> This are factory settings, used by the OS (in this case vxWorks),
>> to identify on which hardware it runs, and have per device unique
>> stuff
>> (serial number).
>> But you're right, it would be nice to have here some compatible
>> string,
>> i will change this. Today we just search for the node
>> "factory-setting".
>> A more comfortable ways would be vxFdtNodeOffsetByCompatible()
+
+ aliases {
+ ethernet0 =
+ ethernet1 =
+ i2c0 =
+ serial0 =
+ spi0 =
+ mmc0 =
+ fset =
+ can0 =
+ can1 =
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0x0 0x1000>;
+ };
+
+ board {
+ status = "okay";
+ compatible = "bur,brsmarc2-som";
+ usb0mux-gpios = < 68 GPIO_ACTIVE_HIGH>;
+ usb1mux-gpios = < 69 GPIO_ACTIVE_HIGH>;
+ powerdown-gpios = < 0 GPIO_ACTIVE_LOW>;
+ reset-gpios = < 9 GPIO_ACTIVE_LOW>;
+ };
>>> Where is mainline dt binding for this?
>> Nowhere, because u-boot nor linux does use this,
>> this is only for the vxWorks OS.
> This is what I kinda figured was the case. We now have some
> interesting
> times ahead of us as yes, we normally think about DTS reviews in terms
> of Linux. But this is all for a board that uses vxWorks. Perhaps the
> best thing to do here is note (and for all of the other boards too,
> but
> you can wait for general feedback before v3'ing them all) in the dts
> comment that it's for vxWorks as people tend to assume a DTS file
> is for
> Linux (even with many counter examples).
OK. Thanks.
would it be fine having it like this ?
/* factory-settings for the vxWorks target */
fset: factory-settings {
compatible = "bur,fsetv1";
bl-version = " ";
.
};
/* misc. peripheral, used in vxWorks */
board {
status = "okay";
...
};
Or might be a general description on top would be more helpful?
>>> I think a general comment at the top saying that this tree is only valid
>>> for vxWorks and U-Boot is enough detail.
> Okay, i will do so like this:
> /*
> * This devicetree is only valid for u-boot and the primary OS (vxWorks
> 6.9.4.x)
> * of this board.
> */
>>
>> It would be much better to simply put vxworks stuff to one dtsi file and
>> common stuff to another. That it will be clear what it is vxworks part
>> and
Re: [U-Boot] [PATCH 1/3] net: mscc: luton: Update network driver for pcb90
Hi Joe,
The 05/09/2019 21:03, Joe Hershberger wrote:
> External E-Mail
>
>
> On Wed, May 1, 2019 at 6:18 AM Horatiu Vultur
> wrote:
> >
> > Update Luton network driver to have support also for pcb90. The pcb90
> > has 24 ports from which 12 ports are connected to SerDes6G.
>
> Can you separate this into a restructuring patch and the patch that
> adds support for this device? This is a bit hard to read.
Well the patch was already applied on the master. So I am not
sure what I can do.
>
> Thanks,
> -Joe
>
> >
> > Signed-off-by: Horatiu Vultur
> > ---
> > drivers/net/mscc_eswitch/Makefile | 2 +-
> > drivers/net/mscc_eswitch/luton_switch.c | 415
> >
> > 2 files changed, 258 insertions(+), 159 deletions(-)
> >
> > diff --git a/drivers/net/mscc_eswitch/Makefile
> > b/drivers/net/mscc_eswitch/Makefile
> > index 9c208d1..02f39a7 100644
> > --- a/drivers/net/mscc_eswitch/Makefile
> > +++ b/drivers/net/mscc_eswitch/Makefile
> > @@ -1,6 +1,6 @@
> >
> > obj-$(CONFIG_MSCC_OCELOT_SWITCH) += ocelot_switch.o mscc_xfer.o
> > mscc_mac_table.o
> > -obj-$(CONFIG_MSCC_LUTON_SWITCH) += luton_switch.o mscc_miim.o mscc_xfer.o
> > mscc_mac_table.o
> > +obj-$(CONFIG_MSCC_LUTON_SWITCH) += luton_switch.o mscc_xfer.o
> > mscc_mac_table.o
> > obj-$(CONFIG_MSCC_JR2_SWITCH) += jr2_switch.o mscc_xfer.o
> > obj-$(CONFIG_MSCC_SERVALT_SWITCH) += servalt_switch.o mscc_xfer.o
> > obj-$(CONFIG_MSCC_SERVAL_SWITCH) += serval_switch.o mscc_xfer.o
> > mscc_mac_table.o
> > diff --git a/drivers/net/mscc_eswitch/luton_switch.c
> > b/drivers/net/mscc_eswitch/luton_switch.c
> > index 6667614..94852b0 100644
> > --- a/drivers/net/mscc_eswitch/luton_switch.c
> > +++ b/drivers/net/mscc_eswitch/luton_switch.c
> > @@ -15,10 +15,21 @@
> > #include
> > #include
> >
> > -#include "mscc_miim.h"
> > #include "mscc_xfer.h"
> > #include "mscc_mac_table.h"
> >
> > +#define GCB_MIIM_MII_STATUS0x0
> > +#defineGCB_MIIM_STAT_BUSY BIT(3)
> > +#define GCB_MIIM_MII_CMD 0x8
> > +#defineGCB_MIIM_MII_CMD_OPR_WRITE BIT(1)
> > +#defineGCB_MIIM_MII_CMD_OPR_READ BIT(2)
> > +#defineGCB_MIIM_MII_CMD_WRDATA(x) ((x) << 4)
> > +#defineGCB_MIIM_MII_CMD_REGAD(x) ((x) << 20)
> > +#defineGCB_MIIM_MII_CMD_PHYAD(x) ((x) << 25)
> > +#defineGCB_MIIM_MII_CMD_VLDBIT(31)
> > +#define GCB_MIIM_DATA 0xC
> > +#defineGCB_MIIM_DATA_ERROR (0x2 << 16)
> > +
> > #define ANA_PORT_VLAN_CFG(x) (0x00 + 0x80 * (x))
> > #defineANA_PORT_VLAN_CFG_AWARE_ENA BIT(20)
> > #defineANA_PORT_VLAN_CFG_POP_CNT(x)((x) << 18)
> > @@ -136,61 +147,53 @@
> > #define PGID_UNICAST 29
> > #define PGID_SRC 80
> >
> > -enum luton_target {
> > - PORT0,
> > - PORT1,
> > - PORT2,
> > - PORT3,
> > - PORT4,
> > - PORT5,
> > - PORT6,
> > - PORT7,
> > - PORT8,
> > - PORT9,
> > - PORT10,
> > - PORT11,
> > - PORT12,
> > - PORT13,
> > - PORT14,
> > - PORT15,
> > - PORT16,
> > - PORT17,
> > - PORT18,
> > - PORT19,
> > - PORT20,
> > - PORT21,
> > - PORT22,
> > - PORT23,
> > - SYS,
> > +static const char * const regs_names[] = {
> > + "port0", "port1", "port2", "port3", "port4", "port5", "port6",
> > "port7",
> > + "port8", "port9", "port10", "port11", "port12", "port13", "port14",
> > + "port15", "port16", "port17", "port18", "port19", "port20",
> > "port21",
> > + "port22", "port23",
> > + "sys", "ana", "rew", "gcb", "qs", "hsio",
> > +};
> > +
> > +#define REGS_NAMES_COUNT ARRAY_SIZE(regs_names) + 1
> > +#define MAX_PORT 24
> > +
> > +enum luton_ctrl_regs {
> > + SYS = MAX_PORT,
> > ANA,
> > REW,
> > GCB,
> > QS,
> > - HSIO,
> > - TARGET_MAX,
> > + HSIO
> > };
> >
> > -#define MAX_PORT (PORT23 - PORT0 + 1)
> > +#define MIN_INT_PORT 0
> > +#define PORT10 10
> > +#define PORT11 11
> > +#define MAX_INT_PORT 12
> > +#define MIN_EXT_PORT MAX_INT_PORT
> > +#define MAX_EXT_PORT MAX_PORT
> >
> > -#define MIN_INT_PORT PORT0
> > -#define MAX_INT_PORT (PORT11 - PORT0 + 1)
> > -#define MIN_EXT_PORT PORT12
> > -#define MAX_EXT_PORT MAX_PORT
> > +#define LUTON_MIIM_BUS_COUNT 2
> >
> > -enum luton_mdio_target {
> > - MIIM,
> > - TARGET_MDIO_MAX,
> > +struct luton_phy_port_t {
> > + size_t phy_addr;
> > + struct mii_dev *bus;
> > + u8 serdes_index;
> > + u8 phy_mode;
> > };
> >
> > -enum luton_phy_id {
> > - INTERNAL,
> > - EXTERNAL,
> > - NUM_PHY,
> > +struct luton_private {
>
Re: [U-Boot] [PATCH 2/5] net: dwc_eth_qos: add Ethernet stm32mp1 support
On Fri, Apr 26, 2019 at 6:16 AM Christophe Roullier
wrote:
>
> Synopsys GMAC 4.20 is used. And Phy mode for eval and disco is RMII
> with PHY Realtek RTL8211 (RGMII)
> We also support some other PHY config on stm32mp157c
> PHY_MODE(MII,GMII, RMII, RGMII) and in normal,
> PHY wo crystal (25Mhz and 50Mhz), No 125Mhz from PHY config
Can you split this into separate logical patches?
Thanks,
-Joe
>
> Signed-off-by: Christophe Roullier
> ---
>
> drivers/net/dwc_eth_qos.c | 435 +-
> 1 file changed, 383 insertions(+), 52 deletions(-)
>
> diff --git a/drivers/net/dwc_eth_qos.c b/drivers/net/dwc_eth_qos.c
> index 9f1c5af46e9..a6546d5e5ce 100644
> --- a/drivers/net/dwc_eth_qos.c
> +++ b/drivers/net/dwc_eth_qos.c
> @@ -26,7 +26,6 @@
> *supports a single RGMII PHY. This configuration also has SW control
> over
> *all clock and reset signals to the HW block.
> */
> -
> #include
> #include
> #include
> @@ -95,6 +94,7 @@ struct eqos_mac_regs {
> #define EQOS_MAC_RXQ_CTRL0_RXQ0EN_MASK 3
> #define EQOS_MAC_RXQ_CTRL0_RXQ0EN_NOT_ENABLED 0
> #define EQOS_MAC_RXQ_CTRL0_RXQ0EN_ENABLED_DCB 2
> +#define EQOS_MAC_RXQ_CTRL0_RXQ0EN_ENABLED_AV 1
>
> #define EQOS_MAC_RXQ_CTRL2_PSRQ0_SHIFT 0
> #define EQOS_MAC_RXQ_CTRL2_PSRQ0_MASK 0xff
> @@ -108,6 +108,7 @@ struct eqos_mac_regs {
> #define EQOS_MAC_MDIO_ADDRESS_RDA_SHIFT16
> #define EQOS_MAC_MDIO_ADDRESS_CR_SHIFT 8
> #define EQOS_MAC_MDIO_ADDRESS_CR_20_35 2
> +#define EQOS_MAC_MDIO_ADDRESS_CR_250_300 5
> #define EQOS_MAC_MDIO_ADDRESS_SKAP BIT(4)
> #define EQOS_MAC_MDIO_ADDRESS_GOC_SHIFT2
> #define EQOS_MAC_MDIO_ADDRESS_GOC_READ 3
> @@ -260,6 +261,29 @@ struct eqos_desc {
>
> struct eqos_config {
> bool reg_access_always_ok;
> + int mdio_wait;
> + int swr_wait;
> + int config_mac;
> + int config_mac_mdio;
> + int (*interface)(struct udevice *dev);
> + struct eqos_ops *ops;
> +};
> +
> +struct eqos_ops {
> + void (*eqos_inval_desc)(void *desc);
> + void (*eqos_flush_desc)(void *desc);
> + void (*eqos_inval_buffer)(void *buf, size_t size);
> + void (*eqos_flush_buffer)(void *buf, size_t size);
> + int (*eqos_probe_resources)(struct udevice *dev);
> + int (*eqos_remove_resources)(struct udevice *dev);
> + int (*eqos_stop_resets)(struct udevice *dev);
> + int (*eqos_start_resets)(struct udevice *dev);
> + void (*eqos_stop_clks)(struct udevice *dev);
> + int (*eqos_start_clks)(struct udevice *dev);
> + int (*eqos_calibrate_pads)(struct udevice *dev);
> + int (*eqos_disable_calibration)(struct udevice *dev);
> + int (*eqos_set_tx_clk_speed)(struct udevice *dev);
> + ulong (*eqos_get_tick_clk_rate)(struct udevice *dev);
> };
>
> struct eqos_priv {
> @@ -276,6 +300,7 @@ struct eqos_priv {
> struct clk clk_rx;
> struct clk clk_ptp_ref;
> struct clk clk_tx;
> + struct clk clk_ck;
> struct clk clk_slave_bus;
> struct mii_dev *mii;
> struct phy_device *phy;
> @@ -327,7 +352,7 @@ static void eqos_free_descs(void *descs)
> #endif
> }
>
> -static void eqos_inval_desc(void *desc)
> +static void eqos_inval_desc_tegra186(void *desc)
> {
> #ifndef CONFIG_SYS_NONCACHED_MEMORY
> unsigned long start = (unsigned long)desc & ~(ARCH_DMA_MINALIGN - 1);
> @@ -338,14 +363,36 @@ static void eqos_inval_desc(void *desc)
> #endif
> }
>
> -static void eqos_flush_desc(void *desc)
> +static void eqos_inval_desc_stm32(void *desc)
> +{
> +#ifndef CONFIG_SYS_NONCACHED_MEMORY
> + unsigned long start = rounddown((unsigned long)desc,
> ARCH_DMA_MINALIGN);
> + unsigned long end = roundup((unsigned long)desc +
> EQOS_DESCRIPTOR_SIZE,
> + ARCH_DMA_MINALIGN);
> +
> + invalidate_dcache_range(start, end);
> +#endif
> +}
> +
> +static void eqos_flush_desc_tegra186(void *desc)
> {
> #ifndef CONFIG_SYS_NONCACHED_MEMORY
> flush_cache((unsigned long)desc, EQOS_DESCRIPTOR_SIZE);
> #endif
> }
>
> -static void eqos_inval_buffer(void *buf, size_t size)
> +static void eqos_flush_desc_stm32(void *desc)
> +{
> +#ifndef CONFIG_SYS_NONCACHED_MEMORY
> + unsigned long start = rounddown((unsigned long)desc,
> ARCH_DMA_MINALIGN);
> + unsigned long end = roundup((unsigned long)desc +
> EQOS_DESCRIPTOR_SIZE,
> + ARCH_DMA_MINALIGN);
> +
> + flush_dcache_range(start, end);
> +#endif
> +}
> +
> +static void eqos_inval_buffer_tegra186(void *buf, size_t size)
> {
> unsigned long start = (unsigned long)buf & ~(ARCH_DMA_MINALIGN - 1);
> unsigned long end = ALIGN(start + size, ARCH_DMA_MINALIGN);
> @@ -353,11 +400,29 @@ static void
Re: [U-Boot] [PATCH 0/6] arm: socfpga: convert drivers to dm livetree
On 5/9/19 10:11 PM, Simon Goldschmidt wrote: > This series converts (hopefully) all drivers used in socfpga to livetree > so that none of them references 'gd' any more (with the exception of > some a10/s10 drivers that should be fixed). > > > Simon Goldschmidt (6): > timer: dw-apb: remove unused DECLARE_GLOBAL_DATA_PTR > spi: cadence_qspi: convert to livetree > spi: designware: convert to livetree > serial: altera_uart: convert to livetree > reset: socfpga: covnert to livetree > gpio: dwapb_gpio: convert to livetree > > drivers/gpio/dwapb_gpio.c | 25 ++ > drivers/reset/reset-socfpga.c | 4 +--- > drivers/serial/altera_uart.c | 5 + > drivers/spi/cadence_qspi.c| 39 +-- > drivers/spi/designware_spi.c | 8 ++- > drivers/timer/dw-apb-timer.c | 2 -- > 6 files changed, 34 insertions(+), 49 deletions(-) > Applied, thanks -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 2/4] sysreset: socfpga: gen5: add sysreset driver
On 5/9/19 8:08 PM, Simon Goldschmidt wrote:
> This adds a UCLASS_SYSRESET sysreset driver for socfgpa gen5.
>
> Signed-off-by: Simon Goldschmidt
> ---
>
> Changes in v3:
> - moved socfpga gen5 sysreset driver to extra patch
>
> Changes in v2: None
[...]
> +static int socfpga_sysreset_request(struct udevice *dev,
> + enum sysreset_t type)
> +{
> + struct socfpga_sysreset_data *data = dev_get_priv(dev);
> +
> + switch (type) {
> + case SYSRESET_WARM:
> + writel(1 << RSTMGR_CTRL_SWWARMRSTREQ_LSB,
> +>rstmgr_base->ctrl);
> + break;
> + case SYSRESET_COLD:
> + writel(1 << RSTMGR_CTRL_SWCOLDRSTREQ_LSB,
BIT(RSTMGR...LSB)
--
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RESEND PATCH 1/2] net: rtl8169: Implement ->hwaddr_write() callback
Hi Thierry, On Thu, Apr 25, 2019 at 8:32 AM Thierry Reding wrote: > > On Tue, Apr 16, 2019 at 04:36:16PM +, Joe Hershberger wrote: > > On Tue, Apr 16, 2019 at 11:21 AM Thierry Reding > > wrote: > > > > > > From: Thierry Reding > > > > > > Implement this callback that allows the MAC address to be set for the > > > Ethernet card. This is necessary in order for the device to be able to > > > receive packets for the MAC address that U-Boot advertises. > > > > > > Signed-off-by: Thierry Reding > > > > Acked-by: Joe Hershberger > > Hi Joe, > > it's not clear to me who you expect to pick this (and patch 2/2) up. I > didn't Cc anyone, so nobody else may consider themselves responsible for > these. > > Did you mean to pick these up yourself or should they go via Simon's DT > tree along with the two eth-uclass patches that I sent? Or perhaps TomR > handles these patches directly? MAINTAINERS clearly identifies you as a > maintainer for the u-boot-net tree, so I was expecting you to pick them > up. Let me know if I should resend these to someone else with your > Acked-by. I just sent a new PR [1] that Tom should accept soon. I'll be pulling in your patches as well as other remaining Acked patches tomorrow to start build testing. Sorry for the inconvenience. It was a bear to track down. -Joe [1] - https://patchwork.ozlabs.org/patch/1097270/ ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 2/4] sysreset: socfpga: gen5: add sysreset driver
On 5/9/19 8:55 PM, Simon Goldschmidt wrote: > > > On 09.05.19 20:08, Simon Goldschmidt wrote: >> This adds a UCLASS_SYSRESET sysreset driver for socfgpa gen5. >> >> Signed-off-by: Simon Goldschmidt >> --- >> >> Changes in v3: >> - moved socfpga gen5 sysreset driver to extra patch >> >> Changes in v2: None >> >> drivers/sysreset/Kconfig | 7 >> drivers/sysreset/Makefile | 1 + >> drivers/sysreset/sysreset_socfpga.c | 56 + >> 3 files changed, 64 insertions(+) >> create mode 100644 drivers/sysreset/sysreset_socfpga.c > > I just noticed patman complained about new files regarding MAINTAINERS. > Should these new drivers be listed in the MAINTAINERS file under the > socfpga section? I noticed other platforms seem to do that but we don't. > How is this handled? I think that's sane. -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: socfpga: fix 3 boards missing env var "socfpga_legacy_reset_compat"
On 5/9/19 8:42 PM, Simon Goldschmidt wrote:
[...]
> diff --git a/include/configs/socfpga_vining_fpga.h
> b/include/configs/socfpga_vining_fpga.h
> index 29a92b9146..737a304217 100644
> --- a/include/configs/socfpga_vining_fpga.h
> +++ b/include/configs/socfpga_vining_fpga.h
> @@ -145,6 +145,7 @@
> "run ubi_ubi ; "\
> "else echo \"Unsupported boot mode: \"${bootmode} ; " \
> "fi\0" \
> + "socfpga_legacy_reset_compat=1\0" \
Drop the trailing backslash please.
> #define CONFIG_SYS_REDUNDAND_ENVIRONMENT
> #define CONFIG_ENV_SIZE_REDUND CONFIG_ENV_SIZE
>
--
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] net: mscc: luton: Update network driver for pcb90
On Wed, May 1, 2019 at 6:18 AM Horatiu Vultur
wrote:
>
> Update Luton network driver to have support also for pcb90. The pcb90
> has 24 ports from which 12 ports are connected to SerDes6G.
Can you separate this into a restructuring patch and the patch that
adds support for this device? This is a bit hard to read.
Thanks,
-Joe
>
> Signed-off-by: Horatiu Vultur
> ---
> drivers/net/mscc_eswitch/Makefile | 2 +-
> drivers/net/mscc_eswitch/luton_switch.c | 415
>
> 2 files changed, 258 insertions(+), 159 deletions(-)
>
> diff --git a/drivers/net/mscc_eswitch/Makefile
> b/drivers/net/mscc_eswitch/Makefile
> index 9c208d1..02f39a7 100644
> --- a/drivers/net/mscc_eswitch/Makefile
> +++ b/drivers/net/mscc_eswitch/Makefile
> @@ -1,6 +1,6 @@
>
> obj-$(CONFIG_MSCC_OCELOT_SWITCH) += ocelot_switch.o mscc_xfer.o
> mscc_mac_table.o
> -obj-$(CONFIG_MSCC_LUTON_SWITCH) += luton_switch.o mscc_miim.o mscc_xfer.o
> mscc_mac_table.o
> +obj-$(CONFIG_MSCC_LUTON_SWITCH) += luton_switch.o mscc_xfer.o
> mscc_mac_table.o
> obj-$(CONFIG_MSCC_JR2_SWITCH) += jr2_switch.o mscc_xfer.o
> obj-$(CONFIG_MSCC_SERVALT_SWITCH) += servalt_switch.o mscc_xfer.o
> obj-$(CONFIG_MSCC_SERVAL_SWITCH) += serval_switch.o mscc_xfer.o
> mscc_mac_table.o
> diff --git a/drivers/net/mscc_eswitch/luton_switch.c
> b/drivers/net/mscc_eswitch/luton_switch.c
> index 6667614..94852b0 100644
> --- a/drivers/net/mscc_eswitch/luton_switch.c
> +++ b/drivers/net/mscc_eswitch/luton_switch.c
> @@ -15,10 +15,21 @@
> #include
> #include
>
> -#include "mscc_miim.h"
> #include "mscc_xfer.h"
> #include "mscc_mac_table.h"
>
> +#define GCB_MIIM_MII_STATUS0x0
> +#defineGCB_MIIM_STAT_BUSY BIT(3)
> +#define GCB_MIIM_MII_CMD 0x8
> +#defineGCB_MIIM_MII_CMD_OPR_WRITE BIT(1)
> +#defineGCB_MIIM_MII_CMD_OPR_READ BIT(2)
> +#defineGCB_MIIM_MII_CMD_WRDATA(x) ((x) << 4)
> +#defineGCB_MIIM_MII_CMD_REGAD(x) ((x) << 20)
> +#defineGCB_MIIM_MII_CMD_PHYAD(x) ((x) << 25)
> +#defineGCB_MIIM_MII_CMD_VLDBIT(31)
> +#define GCB_MIIM_DATA 0xC
> +#defineGCB_MIIM_DATA_ERROR (0x2 << 16)
> +
> #define ANA_PORT_VLAN_CFG(x) (0x00 + 0x80 * (x))
> #defineANA_PORT_VLAN_CFG_AWARE_ENA BIT(20)
> #defineANA_PORT_VLAN_CFG_POP_CNT(x)((x) << 18)
> @@ -136,61 +147,53 @@
> #define PGID_UNICAST 29
> #define PGID_SRC 80
>
> -enum luton_target {
> - PORT0,
> - PORT1,
> - PORT2,
> - PORT3,
> - PORT4,
> - PORT5,
> - PORT6,
> - PORT7,
> - PORT8,
> - PORT9,
> - PORT10,
> - PORT11,
> - PORT12,
> - PORT13,
> - PORT14,
> - PORT15,
> - PORT16,
> - PORT17,
> - PORT18,
> - PORT19,
> - PORT20,
> - PORT21,
> - PORT22,
> - PORT23,
> - SYS,
> +static const char * const regs_names[] = {
> + "port0", "port1", "port2", "port3", "port4", "port5", "port6",
> "port7",
> + "port8", "port9", "port10", "port11", "port12", "port13", "port14",
> + "port15", "port16", "port17", "port18", "port19", "port20", "port21",
> + "port22", "port23",
> + "sys", "ana", "rew", "gcb", "qs", "hsio",
> +};
> +
> +#define REGS_NAMES_COUNT ARRAY_SIZE(regs_names) + 1
> +#define MAX_PORT 24
> +
> +enum luton_ctrl_regs {
> + SYS = MAX_PORT,
> ANA,
> REW,
> GCB,
> QS,
> - HSIO,
> - TARGET_MAX,
> + HSIO
> };
>
> -#define MAX_PORT (PORT23 - PORT0 + 1)
> +#define MIN_INT_PORT 0
> +#define PORT10 10
> +#define PORT11 11
> +#define MAX_INT_PORT 12
> +#define MIN_EXT_PORT MAX_INT_PORT
> +#define MAX_EXT_PORT MAX_PORT
>
> -#define MIN_INT_PORT PORT0
> -#define MAX_INT_PORT (PORT11 - PORT0 + 1)
> -#define MIN_EXT_PORT PORT12
> -#define MAX_EXT_PORT MAX_PORT
> +#define LUTON_MIIM_BUS_COUNT 2
>
> -enum luton_mdio_target {
> - MIIM,
> - TARGET_MDIO_MAX,
> +struct luton_phy_port_t {
> + size_t phy_addr;
> + struct mii_dev *bus;
> + u8 serdes_index;
> + u8 phy_mode;
> };
>
> -enum luton_phy_id {
> - INTERNAL,
> - EXTERNAL,
> - NUM_PHY,
> +struct luton_private {
> + void __iomem *regs[REGS_NAMES_COUNT];
> + struct mii_dev *bus[LUTON_MIIM_BUS_COUNT];
> + struct luton_phy_port_t ports[MAX_PORT];
> };
>
> -struct luton_private {
> - void __iomem *regs[TARGET_MAX];
> - struct mii_dev *bus[NUM_PHY];
> +struct mscc_miim_dev {
> + void __iomem *regs;
> + phys_addr_t miim_base;
> + unsigned long miim_size;
> + struct mii_dev *bus;
> };
>
> static const unsigned long
Re: [U-Boot] [PATCH 6/9] net: sh_eth: Add support for operation without clock framework
On Sat, May 4, 2019 at 12:28 PM Marek Vasut wrote: > > Add ifdeffery to allow operation without the clock framework > enabled. This is required on RZ/A1, as it does not have clock > driver yet. > > Signed-off-by: Marek Vasut > Cc: Chris Brandt > Cc: Joe Hershberger > Cc: Nobuhiro Iwamatsu Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 5/9] net: sh_eth: Add RZ/A1 support
On Sat, May 4, 2019 at 12:28 PM Marek Vasut wrote: > > Add support for RZ/A1 SoC specifics. > > Signed-off-by: Marek Vasut > Cc: Chris Brandt > Cc: Joe Hershberger > Cc: Nobuhiro Iwamatsu Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] net: ravb: Avoid unsupported internal delay mode for R-Car E3/D3
On Wed, May 1, 2019 at 5:36 PM Marek Vasut wrote: > > According to the R-Car Gen3 Hardware Manual Rev 1.50 of Nov 30, 2018, the > TX clock internal delay mode isn't supported on R-Car E3 (r8a77990) or D3 > (r8a77995). > > Avoid setting the APSR:TDM bit on these SoCs. Moreover, only set APSR:TDM > when the DT explicitly specifies RGMII ID or TXID mode instead of setting > it unconditionally when the PHY link speed is 1000 Mbit/s. > > Signed-off-by: Marek Vasut > Cc: Nobuhiro Iwamatsu > Cc: Joe Hershberger Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] net: ravb: Avoid unsupported internal delay mode for R-Car E3/D3
On 5/9/19 10:26 PM, Joe Hershberger wrote: > On Thu, May 9, 2019 at 3:24 PM Marek Vasut wrote: >> >> On 5/9/19 10:18 PM, Joe Hershberger wrote: >>> On Thu, May 9, 2019 at 3:01 PM Marek Vasut wrote: On 5/9/19 8:56 PM, Joe Hershberger wrote: > On Wed, May 1, 2019 at 5:36 PM Marek Vasut wrote: >> >> According to the R-Car Gen3 Hardware Manual Rev 1.50 of Nov 30, 2018, the >> TX clock internal delay mode isn't supported on R-Car E3 (r8a77990) or D3 >> (r8a77995). >> >> Avoid setting the APSR:TDM bit on these SoCs. Moreover, only set APSR:TDM >> when the DT explicitly specifies RGMII ID or TXID mode instead of setting >> it unconditionally when the PHY link speed is 1000 Mbit/s. > > We just ran into an issue with a very similar patch. It blocked my > tree being merged for a few months. Finally got to the bottom of it. > https://patchwork.ozlabs.org/patch/1096572/ > > Are you sure there are no boards depending on the broken DT, like the > 335-evm was? I cannot be sure, but the boards which are supported and tested work fine. If someone runs into any issue. they can raise them, and we'll solve the problem when we come to that bridge. >>> >>> The point that came up is that the DT is considered the ABI, so it >>> shouldn't break / change behavior. Just wanted to make sure you were >>> aware. >> >> I am, but I still prefer for the ethernet to work correctly. > > Is the whole patch required to fix it? The commit log doesn't make > that clear. "Moreover, only set APSR:TDM when the DT explicitly > specifies RGMII ID or TXID mode instead of setting it unconditionally > when the PHY link speed is 1000 Mbit/s." Yep, it's a port of similar patch from Linux. -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] net: ravb: Avoid unsupported internal delay mode for R-Car E3/D3
On Thu, May 9, 2019 at 3:24 PM Marek Vasut wrote: > > On 5/9/19 10:18 PM, Joe Hershberger wrote: > > On Thu, May 9, 2019 at 3:01 PM Marek Vasut wrote: > >> > >> On 5/9/19 8:56 PM, Joe Hershberger wrote: > >>> On Wed, May 1, 2019 at 5:36 PM Marek Vasut wrote: > > According to the R-Car Gen3 Hardware Manual Rev 1.50 of Nov 30, 2018, the > TX clock internal delay mode isn't supported on R-Car E3 (r8a77990) or D3 > (r8a77995). > > Avoid setting the APSR:TDM bit on these SoCs. Moreover, only set APSR:TDM > when the DT explicitly specifies RGMII ID or TXID mode instead of setting > it unconditionally when the PHY link speed is 1000 Mbit/s. > >>> > >>> We just ran into an issue with a very similar patch. It blocked my > >>> tree being merged for a few months. Finally got to the bottom of it. > >>> https://patchwork.ozlabs.org/patch/1096572/ > >>> > >>> Are you sure there are no boards depending on the broken DT, like the > >>> 335-evm was? > >> > >> I cannot be sure, but the boards which are supported and tested work > >> fine. If someone runs into any issue. they can raise them, and we'll > >> solve the problem when we come to that bridge. > > > > The point that came up is that the DT is considered the ABI, so it > > shouldn't break / change behavior. Just wanted to make sure you were > > aware. > > I am, but I still prefer for the ethernet to work correctly. Is the whole patch required to fix it? The commit log doesn't make that clear. "Moreover, only set APSR:TDM when the DT explicitly specifies RGMII ID or TXID mode instead of setting it unconditionally when the PHY link speed is 1000 Mbit/s." Thanks, -Joe > > -- > Best regards, > Marek Vasut > ___ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] net: ravb: Avoid unsupported internal delay mode for R-Car E3/D3
On Thu, May 9, 2019 at 3:01 PM Marek Vasut wrote: > > On 5/9/19 8:56 PM, Joe Hershberger wrote: > > On Wed, May 1, 2019 at 5:36 PM Marek Vasut wrote: > >> > >> According to the R-Car Gen3 Hardware Manual Rev 1.50 of Nov 30, 2018, the > >> TX clock internal delay mode isn't supported on R-Car E3 (r8a77990) or D3 > >> (r8a77995). > >> > >> Avoid setting the APSR:TDM bit on these SoCs. Moreover, only set APSR:TDM > >> when the DT explicitly specifies RGMII ID or TXID mode instead of setting > >> it unconditionally when the PHY link speed is 1000 Mbit/s. > > > > We just ran into an issue with a very similar patch. It blocked my > > tree being merged for a few months. Finally got to the bottom of it. > > https://patchwork.ozlabs.org/patch/1096572/ > > > > Are you sure there are no boards depending on the broken DT, like the > > 335-evm was? > > I cannot be sure, but the boards which are supported and tested work > fine. If someone runs into any issue. they can raise them, and we'll > solve the problem when we come to that bridge. The point that came up is that the DT is considered the ABI, so it shouldn't break / change behavior. Just wanted to make sure you were aware. Thanks, -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] net: ravb: Avoid unsupported internal delay mode for R-Car E3/D3
On 5/9/19 10:18 PM, Joe Hershberger wrote: > On Thu, May 9, 2019 at 3:01 PM Marek Vasut wrote: >> >> On 5/9/19 8:56 PM, Joe Hershberger wrote: >>> On Wed, May 1, 2019 at 5:36 PM Marek Vasut wrote: According to the R-Car Gen3 Hardware Manual Rev 1.50 of Nov 30, 2018, the TX clock internal delay mode isn't supported on R-Car E3 (r8a77990) or D3 (r8a77995). Avoid setting the APSR:TDM bit on these SoCs. Moreover, only set APSR:TDM when the DT explicitly specifies RGMII ID or TXID mode instead of setting it unconditionally when the PHY link speed is 1000 Mbit/s. >>> >>> We just ran into an issue with a very similar patch. It blocked my >>> tree being merged for a few months. Finally got to the bottom of it. >>> https://patchwork.ozlabs.org/patch/1096572/ >>> >>> Are you sure there are no boards depending on the broken DT, like the >>> 335-evm was? >> >> I cannot be sure, but the boards which are supported and tested work >> fine. If someone runs into any issue. they can raise them, and we'll >> solve the problem when we come to that bridge. > > The point that came up is that the DT is considered the ABI, so it > shouldn't break / change behavior. Just wanted to make sure you were > aware. I am, but I still prefer for the ethernet to work correctly. -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 3/6] spi: designware: convert to livetree
Convert 'dw_spi_ofdata_to_platdata' to use 'dev_read_u32_default'
instead of 'fdtdec_get_int' and get rid of DECLARE_GLOBAL_DATA_PTR.
Signed-off-by: Simon Goldschmidt
---
drivers/spi/designware_spi.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/spi/designware_spi.c b/drivers/spi/designware_spi.c
index dadb6fa18b..7d58cfae55 100644
--- a/drivers/spi/designware_spi.c
+++ b/drivers/spi/designware_spi.c
@@ -22,8 +22,6 @@
#include
#include
-DECLARE_GLOBAL_DATA_PTR;
-
/* Register offsets */
#define DW_SPI_CTRL0 0x00
#define DW_SPI_CTRL1 0x04
@@ -155,14 +153,12 @@ static int request_gpio_cs(struct udevice *bus)
static int dw_spi_ofdata_to_platdata(struct udevice *bus)
{
struct dw_spi_platdata *plat = bus->platdata;
- const void *blob = gd->fdt_blob;
- int node = dev_of_offset(bus);
plat->regs = (struct dw_spi *)devfdt_get_addr(bus);
/* Use 500KHz as a suitable default */
- plat->frequency = fdtdec_get_int(blob, node, "spi-max-frequency",
- 50);
+ plat->frequency = dev_read_u32_default(bus, "spi-max-frequency",
+ 50);
debug("%s: regs=%p max-frequency=%d\n", __func__, plat->regs,
plat->frequency);
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/6] spi: cadence_qspi: convert to livetree
Convert 'cadence_spi_ofdata_to_platdata' to use dev_read_* functions to
read driver parameters and 'dev_read_first_subnode'/'ofnode_read_*' to
read flash (child node) parameters.
Tested on socfpga_socrates (socfpga gen5).
Signed-off-by: Simon Goldschmidt
---
drivers/spi/cadence_qspi.c | 39 +++---
1 file changed, 19 insertions(+), 20 deletions(-)
diff --git a/drivers/spi/cadence_qspi.c b/drivers/spi/cadence_qspi.c
index 41c87004d8..e2e54cd277 100644
--- a/drivers/spi/cadence_qspi.c
+++ b/drivers/spi/cadence_qspi.c
@@ -18,8 +18,6 @@
#define CQSPI_INDIRECT_READ2
#define CQSPI_INDIRECT_WRITE 3
-DECLARE_GLOBAL_DATA_PTR;
-
static int cadence_spi_write_speed(struct udevice *bus, uint hz)
{
struct cadence_spi_platdata *plat = bus->platdata;
@@ -295,36 +293,37 @@ static int cadence_spi_xfer(struct udevice *dev, unsigned
int bitlen,
static int cadence_spi_ofdata_to_platdata(struct udevice *bus)
{
struct cadence_spi_platdata *plat = bus->platdata;
- const void *blob = gd->fdt_blob;
- int node = dev_of_offset(bus);
- int subnode;
+ ofnode subnode;
plat->regbase = (void *)devfdt_get_addr_index(bus, 0);
plat->ahbbase = (void *)devfdt_get_addr_index(bus, 1);
- plat->is_decoded_cs = fdtdec_get_bool(blob, node, "cdns,is-decoded-cs");
- plat->fifo_depth = fdtdec_get_uint(blob, node, "cdns,fifo-depth", 128);
- plat->fifo_width = fdtdec_get_uint(blob, node, "cdns,fifo-width", 4);
- plat->trigger_address = fdtdec_get_uint(blob, node,
- "cdns,trigger-address", 0);
+ plat->is_decoded_cs = dev_read_bool(bus, "cdns,is-decoded-cs");
+ plat->fifo_depth = dev_read_u32_default(bus, "cdns,fifo-depth", 128);
+ plat->fifo_width = dev_read_u32_default(bus, "cdns,fifo-width", 4);
+ plat->trigger_address = dev_read_u32_default(bus,
+"cdns,trigger-address",
+0);
/* All other paramters are embedded in the child node */
- subnode = fdt_first_subnode(blob, node);
- if (subnode < 0) {
+ subnode = dev_read_first_subnode(bus);
+ if (!ofnode_valid(subnode)) {
printf("Error: subnode with SPI flash config missing!\n");
return -ENODEV;
}
/* Use 500 KHz as a suitable default */
- plat->max_hz = fdtdec_get_uint(blob, subnode, "spi-max-frequency",
- 50);
+ plat->max_hz = ofnode_read_u32_default(subnode, "spi-max-frequency",
+ 50);
/* Read other parameters from DT */
- plat->page_size = fdtdec_get_uint(blob, subnode, "page-size", 256);
- plat->block_size = fdtdec_get_uint(blob, subnode, "block-size", 16);
- plat->tshsl_ns = fdtdec_get_uint(blob, subnode, "cdns,tshsl-ns", 200);
- plat->tsd2d_ns = fdtdec_get_uint(blob, subnode, "cdns,tsd2d-ns", 255);
- plat->tchsh_ns = fdtdec_get_uint(blob, subnode, "cdns,tchsh-ns", 20);
- plat->tslch_ns = fdtdec_get_uint(blob, subnode, "cdns,tslch-ns", 20);
+ plat->page_size = ofnode_read_u32_default(subnode, "page-size", 256);
+ plat->block_size = ofnode_read_u32_default(subnode, "block-size", 16);
+ plat->tshsl_ns = ofnode_read_u32_default(subnode, "cdns,tshsl-ns",
+200);
+ plat->tsd2d_ns = ofnode_read_u32_default(subnode, "cdns,tsd2d-ns",
+255);
+ plat->tchsh_ns = ofnode_read_u32_default(subnode, "cdns,tchsh-ns", 20);
+ plat->tslch_ns = ofnode_read_u32_default(subnode, "cdns,tslch-ns", 20);
debug("%s: regbase=%p ahbbase=%p max-frequency=%d page-size=%d\n",
__func__, plat->regbase, plat->ahbbase, plat->max_hz,
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 6/6] gpio: dwapb_gpio: convert to livetree
Convert 'gpio_dwapb_bind' to iterate over subnodes using livetree
functions (inspired from mt7621_gpio.c).
Signed-off-by: Simon Goldschmidt
---
drivers/gpio/dwapb_gpio.c | 25 +++--
1 file changed, 11 insertions(+), 14 deletions(-)
diff --git a/drivers/gpio/dwapb_gpio.c b/drivers/gpio/dwapb_gpio.c
index e55fb4ac73..04a2381acd 100644
--- a/drivers/gpio/dwapb_gpio.c
+++ b/drivers/gpio/dwapb_gpio.c
@@ -17,8 +17,6 @@
#include
#include
-DECLARE_GLOBAL_DATA_PTR;
-
#define GPIO_SWPORT_DR(p) (0x00 + (p) * 0xc)
#define GPIO_SWPORT_DDR(p) (0x04 + (p) * 0xc)
#define GPIO_INTEN 0x30
@@ -150,10 +148,10 @@ static int gpio_dwapb_probe(struct udevice *dev)
static int gpio_dwapb_bind(struct udevice *dev)
{
struct gpio_dwapb_platdata *plat = dev_get_platdata(dev);
- const void *blob = gd->fdt_blob;
struct udevice *subdev;
fdt_addr_t base;
- int ret, node, bank = 0;
+ int ret, bank = 0;
+ ofnode node;
/* If this is a child device, there is nothing to do here */
if (plat)
@@ -165,10 +163,9 @@ static int gpio_dwapb_bind(struct udevice *dev)
return -ENXIO;
}
- for (node = fdt_first_subnode(blob, dev_of_offset(dev));
-node > 0;
-node = fdt_next_subnode(blob, node)) {
- if (!fdtdec_get_bool(blob, node, "gpio-controller"))
+ for (node = dev_read_first_subnode(dev); ofnode_valid(node);
+node = dev_read_next_subnode(node)) {
+ if (!ofnode_read_bool(node, "gpio-controller"))
continue;
plat = devm_kcalloc(dev, 1, sizeof(*plat), GFP_KERNEL);
@@ -177,15 +174,15 @@ static int gpio_dwapb_bind(struct udevice *dev)
plat->base = base;
plat->bank = bank;
- plat->pins = fdtdec_get_int(blob, node, "snps,nr-gpios", 0);
- plat->name = fdt_stringlist_get(blob, node, "bank-name", 0,
- NULL);
- if (!plat->name) {
+ plat->pins = ofnode_read_u32_default(node, "snps,nr-gpios", 0);
+
+ if (ofnode_read_string_index(node, "bank-name", 0,
+>name)) {
/*
* Fall back to node name. This means accessing pins
* via bank name won't work.
*/
- plat->name = fdt_get_name(blob, node, NULL);
+ plat->name = ofnode_get_name(node);
}
ret = device_bind(dev, dev->driver, plat->name,
@@ -193,7 +190,7 @@ static int gpio_dwapb_bind(struct udevice *dev)
if (ret)
return ret;
- dev_set_of_offset(subdev, node);
+ dev->node = node;
bank++;
}
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 5/6] reset: socfpga: convert to livetree
Convert 'socfpga_reset_probe' to use 'dev_read_u32_default'
instead of 'fdtdec_get_int'.
Signed-off-by: Simon Goldschmidt
---
drivers/reset/reset-socfpga.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/reset/reset-socfpga.c b/drivers/reset/reset-socfpga.c
index cb8312619f..ee4cbcb02f 100644
--- a/drivers/reset/reset-socfpga.c
+++ b/drivers/reset/reset-socfpga.c
@@ -107,14 +107,12 @@ static const struct reset_ops socfpga_reset_ops = {
static int socfpga_reset_probe(struct udevice *dev)
{
struct socfpga_reset_data *data = dev_get_priv(dev);
- const void *blob = gd->fdt_blob;
- int node = dev_of_offset(dev);
u32 modrst_offset;
void __iomem *membase;
membase = devfdt_get_addr_ptr(dev);
- modrst_offset = fdtdec_get_int(blob, node, "altr,modrst-offset", 0x10);
+ modrst_offset = dev_read_u32_default(dev, "altr,modrst-offset", 0x10);
data->modrst_base = membase + modrst_offset;
return 0;
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/6] timer: dw-apb: remove unused DECLARE_GLOBAL_DATA_PTR
The dw-apb timer does not use 'gd', so remove its declaration.
Signed-off-by: Simon Goldschmidt
---
drivers/timer/dw-apb-timer.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/timer/dw-apb-timer.c b/drivers/timer/dw-apb-timer.c
index cb48801af1..86312b8dc7 100644
--- a/drivers/timer/dw-apb-timer.c
+++ b/drivers/timer/dw-apb-timer.c
@@ -17,8 +17,6 @@
#define DW_APB_CURR_VAL0x4
#define DW_APB_CTRL0x8
-DECLARE_GLOBAL_DATA_PTR;
-
struct dw_apb_timer_priv {
fdt_addr_t regs;
};
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 4/6] serial: altera_uart: convert to livetree
Convert 'altera_uart_ofdata_to_platdata' to use 'dev_read_u32_default' instead of 'fdtdec_get_int' and get rid of DECLARE_GLOBAL_DATA_PTR. Signed-off-by: Simon Goldschmidt --- drivers/serial/altera_uart.c | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/drivers/serial/altera_uart.c b/drivers/serial/altera_uart.c index 67d47199aa..436cf2331d 100644 --- a/drivers/serial/altera_uart.c +++ b/drivers/serial/altera_uart.c @@ -10,8 +10,6 @@ #include #include -DECLARE_GLOBAL_DATA_PTR; - /* status register */ #define ALTERA_UART_TMTBIT(5) /* tx empty */ #define ALTERA_UART_TRDY BIT(6) /* tx ready */ @@ -91,8 +89,7 @@ static int altera_uart_ofdata_to_platdata(struct udevice *dev) plat->regs = map_physmem(devfdt_get_addr(dev), sizeof(struct altera_uart_regs), MAP_NOCACHE); - plat->uartclk = fdtdec_get_int(gd->fdt_blob, dev_of_offset(dev), - "clock-frequency", 0); + plat->uartclk = dev_read_u32_default(dev, "clock-frequency", 0); return 0; } -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 0/6] arm: socfpga: convert drivers to dm livetree
This series converts (hopefully) all drivers used in socfpga to livetree so that none of them references 'gd' any more (with the exception of some a10/s10 drivers that should be fixed). Simon Goldschmidt (6): timer: dw-apb: remove unused DECLARE_GLOBAL_DATA_PTR spi: cadence_qspi: convert to livetree spi: designware: convert to livetree serial: altera_uart: convert to livetree reset: socfpga: covnert to livetree gpio: dwapb_gpio: convert to livetree drivers/gpio/dwapb_gpio.c | 25 ++ drivers/reset/reset-socfpga.c | 4 +--- drivers/serial/altera_uart.c | 5 + drivers/spi/cadence_qspi.c| 39 +-- drivers/spi/designware_spi.c | 8 ++- drivers/timer/dw-apb-timer.c | 2 -- 6 files changed, 34 insertions(+), 49 deletions(-) -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1] net: use block layer in net driver
On Wed, Apr 17, 2019 at 4:02 AM Yinbo Zhu wrote:
>
> From: Yinbo Zhu
>
> At present the MMC subsystem maintains its own list
> of MMC devices. This cannot work with driver model
> when CONFIG_BLK is enabled, use blk_dread to
> replace previous mmc read interface,
>
> Signed-off-by: Yinbo Zhu
> ---
> drivers/net/phy/cortina.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/phy/cortina.c b/drivers/net/phy/cortina.c
> index a04a118f90..2337c3403c 100644
> --- a/drivers/net/phy/cortina.c
> +++ b/drivers/net/phy/cortina.c
> @@ -176,7 +176,7 @@ void cs4340_upload_firmware(struct phy_device *phydev)
> printf("MMC read: dev # %u, block # %u, count %u ...\n",
>dev, blk, cnt);
> mmc_init(mmc);
> - (void)mmc->block_dev.block_read(>block_dev, blk, cnt,
> + (void)blk_dread(mmc_get_blk_desc(mmc), blk, cnt,
> addr);
Should this be switching on CONFIG_BLK or CONFIG_DM_MMC or something.
> }
> #endif
> --
> 2.17.1
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] net: ravb: Avoid unsupported internal delay mode for R-Car E3/D3
On 5/9/19 8:56 PM, Joe Hershberger wrote: > On Wed, May 1, 2019 at 5:36 PM Marek Vasut wrote: >> >> According to the R-Car Gen3 Hardware Manual Rev 1.50 of Nov 30, 2018, the >> TX clock internal delay mode isn't supported on R-Car E3 (r8a77990) or D3 >> (r8a77995). >> >> Avoid setting the APSR:TDM bit on these SoCs. Moreover, only set APSR:TDM >> when the DT explicitly specifies RGMII ID or TXID mode instead of setting >> it unconditionally when the PHY link speed is 1000 Mbit/s. > > We just ran into an issue with a very similar patch. It blocked my > tree being merged for a few months. Finally got to the bottom of it. > https://patchwork.ozlabs.org/patch/1096572/ > > Are you sure there are no boards depending on the broken DT, like the > 335-evm was? I cannot be sure, but the boards which are supported and tested work fine. If someone runs into any issue. they can raise them, and we'll solve the problem when we come to that bridge. -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] net: phy: ti: Use default values for tx/rx delay and fifo size
When not using DM_ETH, these PHY settings are programmed with default values hardcoded into the driver. When using DM_ETH, they should come from the device tree. However, if the device tree does not have the properties, the driver will silent use -1. Which is entirely out of range, programs nonsense into the PHY's registers, and does not work. Change this to use the same defaults as non-DM_ETH if the device tree is lacking the properties. As an alternative, the kernel driver for the phy will display an error message and fail if the device tree is lacking. Cc: Joe Hershberger Cc: Janine Hagemann Cc: Grygorii Strashko Signed-off-by: Trent Piepho --- drivers/net/phy/ti.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/net/phy/ti.c b/drivers/net/phy/ti.c index 6db6edd0d0..33f5687e0e 100644 --- a/drivers/net/phy/ti.c +++ b/drivers/net/phy/ti.c @@ -240,14 +240,14 @@ static int dp83867_of_init(struct phy_device *phydev) dp83867->rxctrl_strap_quirk = true; dp83867->rx_id_delay = ofnode_read_u32_default(node, "ti,rx-internal-delay", - -1); + DEFAULT_RX_ID_DELAY); dp83867->tx_id_delay = ofnode_read_u32_default(node, "ti,tx-internal-delay", - -1); + DEFAULT_TX_ID_DELAY); dp83867->fifo_depth = ofnode_read_u32_default(node, "ti,fifo-depth", - -1); + DEFAULT_FIFO_DEPTH); if (ofnode_read_bool(node, "enet-phy-lane-swap")) dp83867->port_mirroring = DP83867_PORT_MIRRORING_EN; -- 2.14.5 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/2] cmd: mii: Add the standard 1000BASE-T registers
These are standard across gigabit phys. These mostly extend the
auto-negotiation information with gigabit fields.
Signed-off-by: Trent Piepho
---
cmd/mii.c | 34 +-
1 file changed, 29 insertions(+), 5 deletions(-)
diff --git a/cmd/mii.c b/cmd/mii.c
index fcc677b485..1cb0904689 100644
--- a/cmd/mii.c
+++ b/cmd/mii.c
@@ -91,6 +91,28 @@ static const MII_field_desc_t reg_5_desc_tbl[] = {
{ 4, 0, 0x1f, "partner selector" },
};
+static const MII_field_desc_t reg_9_desc_tbl[] = {
+ { 15, 13, 0x07, "test mode"},
+ { 12, 12, 0x01, "manual master/slave enable" },
+ { 11, 11, 0x01, "manual master/slave value"},
+ { 10, 10, 0x01, "multi/single port"},
+ { 9, 9, 0x01, "1000BASE-T full duplex able" },
+ { 8, 8, 0x01, "1000BASE-T half duplex able" },
+ { 7, 7, 0x01, "automatic TDR on link down" },
+ { 6, 6, 0x7f, "(reserved)" },
+};
+
+static const MII_field_desc_t reg_10_desc_tbl[] = {
+ { 15, 15, 0x01, "master/slave config fault"},
+ { 14, 14, 0x01, "master/slave config result" },
+ { 13, 13, 0x01, "local receiver status OK" },
+ { 12, 12, 0x01, "remote receiver status OK"},
+ { 11, 11, 0x01, "1000BASE-T full duplex able" },
+ { 10, 10, 0x01, "1000BASE-T half duplex able" },
+ { 9, 8, 0x03, "(reserved)" },
+ { 7, 0, 0xff, "1000BASE-T idle error counter"},
+};
+
typedef struct _MII_reg_desc_t {
ushort regno;
const MII_field_desc_t *pdesc;
@@ -111,6 +133,10 @@ static const MII_reg_desc_t mii_reg_desc_tbl[] = {
"Autonegotiation advertisement register" },
{ MII_LPA, reg_5_desc_tbl, ARRAY_SIZE(reg_5_desc_tbl),
"Autonegotiation partner abilities register" },
+ { MII_CTRL1000, reg_9_desc_tbl, ARRAY_SIZE(reg_9_desc_tbl),
+ "1000BASE-T control register" },
+ { MII_STAT1000, reg_10_desc_tbl, ARRAY_SIZE(reg_10_desc_tbl),
+ "1000BASE-T status register" },
};
static void dump_reg(
@@ -390,12 +416,10 @@ static int do_mii(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
}
}
} else if (strncmp(op, "du", 2) == 0) {
- ushort regs[6];
+ ushort regs[MII_STAT1000 + 1]; /* Last reg is 0x0a */
int ok = 1;
- if ((reglo > 5) || (reghi > 5)) {
- printf(
- "The MII dump command only formats the "
- "standard MII registers, 0-5.\n");
+ if (reglo > MII_STAT1000 || reghi > MII_STAT1000) {
+ printf("The MII dump command only formats the standard
MII registers, 0-5, 9-a.\n");
return 1;
}
for (addr = addrlo; addr <= addrhi; addr++) {
--
2.14.5
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/2] cmd: mii: Refactor some of the MII reg dump code
Share the code that prints out a register field with the function that
prints out the "special" fields.
There were two arrays the register dump list, one with reg number and
name, another with a pointer to the field table and the table size.
These two arrays had have each entry match what register is referred to.
Combine them into just one table. Now they can't not match and there is
just one table.
Add some missing consts to pointers to string literals.
The dump code was ignoring the regno field in the description table and
assuming register 0 was at index 0, etc. Have it use the field.
Change reg > max+1 into reg >= max, which doesn't fail if max+1 could
overflow, besides just making more sense.
Signed-off-by: Trent Piepho
---
cmd/mii.c | 154 --
1 file changed, 69 insertions(+), 85 deletions(-)
diff --git a/cmd/mii.c b/cmd/mii.c
index c0c42a851f..fcc677b485 100644
--- a/cmd/mii.c
+++ b/cmd/mii.c
@@ -12,25 +12,11 @@
#include
#include
-typedef struct _MII_reg_desc_t {
- ushort regno;
- char * name;
-} MII_reg_desc_t;
-
-static const MII_reg_desc_t reg_0_5_desc_tbl[] = {
- { MII_BMCR, "PHY control register" },
- { MII_BMSR, "PHY status register" },
- { MII_PHYSID1, "PHY ID 1 register" },
- { MII_PHYSID2, "PHY ID 2 register" },
- { MII_ADVERTISE, "Autonegotiation advertisement register" },
- { MII_LPA, "Autonegotiation partner abilities register" },
-};
-
typedef struct _MII_field_desc_t {
ushort hi;
ushort lo;
ushort mask;
- char * name;
+ const char *name;
} MII_field_desc_t;
static const MII_field_desc_t reg_0_desc_tbl[] = {
@@ -87,7 +73,7 @@ static const MII_field_desc_t reg_4_desc_tbl[] = {
{ 7, 7, 0x01, "100BASE-TX able" },
{ 6, 6, 0x01, "10BASE-T full duplex able" },
{ 5, 5, 0x01, "10BASE-T able" },
- { 4, 0, 0x1f, "xxx to do"},
+ { 4, 0, 0x1f, "selector" },
};
static const MII_field_desc_t reg_5_desc_tbl[] = {
@@ -102,50 +88,65 @@ static const MII_field_desc_t reg_5_desc_tbl[] = {
{ 7, 7, 0x01, "100BASE-TX able" },
{ 6, 6, 0x01, "10BASE-T full duplex able"},
{ 5, 5, 0x01, "10BASE-T able"},
- { 4, 0, 0x1f, "xxx to do"},
+ { 4, 0, 0x1f, "partner selector" },
};
-typedef struct _MII_field_desc_and_len_t {
+
+typedef struct _MII_reg_desc_t {
+ ushort regno;
const MII_field_desc_t *pdesc;
ushort len;
-} MII_field_desc_and_len_t;
-
-static const MII_field_desc_and_len_t desc_and_len_tbl[] = {
- { reg_0_desc_tbl, ARRAY_SIZE(reg_0_desc_tbl) },
- { reg_1_desc_tbl, ARRAY_SIZE(reg_1_desc_tbl) },
- { reg_2_desc_tbl, ARRAY_SIZE(reg_2_desc_tbl) },
- { reg_3_desc_tbl, ARRAY_SIZE(reg_3_desc_tbl) },
- { reg_4_desc_tbl, ARRAY_SIZE(reg_4_desc_tbl) },
- { reg_5_desc_tbl, ARRAY_SIZE(reg_5_desc_tbl) },
+ const char *name;
+} MII_reg_desc_t;
+
+static const MII_reg_desc_t mii_reg_desc_tbl[] = {
+ { MII_BMCR, reg_0_desc_tbl, ARRAY_SIZE(reg_0_desc_tbl),
+ "PHY control register" },
+ { MII_BMSR, reg_1_desc_tbl, ARRAY_SIZE(reg_1_desc_tbl),
+ "PHY status register" },
+ { MII_PHYSID1, reg_2_desc_tbl, ARRAY_SIZE(reg_2_desc_tbl),
+ "PHY ID 1 register" },
+ { MII_PHYSID2, reg_3_desc_tbl, ARRAY_SIZE(reg_3_desc_tbl),
+ "PHY ID 2 register" },
+ { MII_ADVERTISE, reg_4_desc_tbl, ARRAY_SIZE(reg_4_desc_tbl),
+ "Autonegotiation advertisement register" },
+ { MII_LPA, reg_5_desc_tbl, ARRAY_SIZE(reg_5_desc_tbl),
+ "Autonegotiation partner abilities register" },
};
static void dump_reg(
ushort regval,
- const MII_reg_desc_t *prd,
- const MII_field_desc_and_len_t *pdl);
-
-static int special_field(
- ushort regno,
- const MII_field_desc_t *pdesc,
- ushort regval);
-
-static void MII_dump_0_to_5(
- ushort regvals[6],
- uchar reglo,
- uchar reghi)
+ const MII_reg_desc_t *prd);
+
+static bool special_field(ushort regno, const MII_field_desc_t *pdesc,
+ ushort regval);
+
+static void MII_dump(const ushort *regvals, uchar reglo, uchar reghi)
{
ulong i;
- for (i = 0; i < 6; i++) {
- if ((reglo <= i) && (i <= reghi))
- dump_reg(regvals[i], _0_5_desc_tbl[i],
- _and_len_tbl[i]);
+ for (i = 0; i < ARRAY_SIZE(mii_reg_desc_tbl); i++) {
+ const uchar reg = mii_reg_desc_tbl[i].regno;
+
+ if (reg >= reglo && reg <= reghi)
+ dump_reg(regvals[reg - reglo], _reg_desc_tbl[i]);
}
}
+/* Print
Re: [U-Boot] [PATCH] arm: socfpga: fix 3 boards missing env var "socfpga_legacy_reset_compat"
Am 09.05.2019 um 21:13 schrieb Wolfgang Grandegger:
Hello Simon,
Am 09.05.19 um 20:42 schrieb Simon Goldschmidt:
This fixes 3 boards that don't use CONFIG_EXTRA_ENV_SETTINGS from
socfpga_common.h. They need to enable reset manager compatibility
mode unless all peripheral drivers in Linux support reset handling.
Fixes: commit 4b2e32efa4e7 ("arm: socfpga: gen5: deassert peripheral reset by
default")
Signed-off-by: Simon Goldschmidt
Reported-by: Wolfgang Grandegger
---
include/configs/socfpga_dbm_soc1.h| 3 ++-
include/configs/socfpga_stratix10_socdk.h | 3 ++-
include/configs/socfpga_vining_fpga.h | 1 +
3 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/include/configs/socfpga_dbm_soc1.h
b/include/configs/socfpga_dbm_soc1.h
index b36d7e56fb..fc1db2442e 100644
--- a/include/configs/socfpga_dbm_soc1.h
+++ b/include/configs/socfpga_dbm_soc1.h
@@ -87,7 +87,8 @@
"echo Running bootscript... ; " \
"source ${kernel_addr_r} ; " \
"fi ; " \
- "fi\0"
+ "fi\0"\
+ "socfpga_legacy_reset_compat=1\0"
/* The rest of the configuration is shared */
#include
diff --git a/include/configs/socfpga_stratix10_socdk.h
b/include/configs/socfpga_stratix10_socdk.h
index 8d2971c6e2..90ad8172e2 100644
--- a/include/configs/socfpga_stratix10_socdk.h
+++ b/include/configs/socfpga_stratix10_socdk.h
@@ -113,7 +113,8 @@ unsigned int cm_get_qspi_controller_clk_hz(void);
"scriptaddr=0x0210\0" \
"scriptfile=u-boot.scr\0" \
"fatscript=if fatload mmc 0:1 ${scriptaddr} ${scriptfile};" \
- "then source ${scriptaddr}; fi\0"
+ "then source ${scriptaddr}; fi\0" \
+ "socfpga_legacy_reset_compat=1\0"
/*
* Generic Interrupt Controller Definitions
diff --git a/include/configs/socfpga_vining_fpga.h
b/include/configs/socfpga_vining_fpga.h
index 29a92b9146..737a304217 100644
--- a/include/configs/socfpga_vining_fpga.h
+++ b/include/configs/socfpga_vining_fpga.h
@@ -145,6 +145,7 @@
"run ubi_ubi ; " \
"else echo \"Unsupported boot mode: \"${bootmode} ; " \
"fi\0"\
+ "socfpga_legacy_reset_compat=1\0" \
#define CONFIG_SYS_REDUNDAND_ENVIRONMENT
#define CONFIG_ENV_SIZE_REDUNDCONFIG_ENV_SIZE
On my board, setting "socfpga_legacy_reset_compat=1" was not enough. It
also needs "bootm_size=0xa00" to boot Linux.
Ok, but that would be a different patch - I wanted this to be a 'fixes'
patch for that one thing. I'd have to check with the socrates board what
happens without that bootm_size thing and why...
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: socfpga: fix 3 boards missing env var "socfpga_legacy_reset_compat"
Hello Simon,
Am 09.05.19 um 20:42 schrieb Simon Goldschmidt:
> This fixes 3 boards that don't use CONFIG_EXTRA_ENV_SETTINGS from
> socfpga_common.h. They need to enable reset manager compatibility
> mode unless all peripheral drivers in Linux support reset handling.
>
> Fixes: commit 4b2e32efa4e7 ("arm: socfpga: gen5: deassert peripheral reset by
> default")
> Signed-off-by: Simon Goldschmidt
> Reported-by: Wolfgang Grandegger
> ---
>
> include/configs/socfpga_dbm_soc1.h| 3 ++-
> include/configs/socfpga_stratix10_socdk.h | 3 ++-
> include/configs/socfpga_vining_fpga.h | 1 +
> 3 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/include/configs/socfpga_dbm_soc1.h
> b/include/configs/socfpga_dbm_soc1.h
> index b36d7e56fb..fc1db2442e 100644
> --- a/include/configs/socfpga_dbm_soc1.h
> +++ b/include/configs/socfpga_dbm_soc1.h
> @@ -87,7 +87,8 @@
> "echo Running bootscript... ; " \
> "source ${kernel_addr_r} ; "\
> "fi ; " \
> - "fi\0"
> + "fi\0" \
> + "socfpga_legacy_reset_compat=1\0"
>
> /* The rest of the configuration is shared */
> #include
> diff --git a/include/configs/socfpga_stratix10_socdk.h
> b/include/configs/socfpga_stratix10_socdk.h
> index 8d2971c6e2..90ad8172e2 100644
> --- a/include/configs/socfpga_stratix10_socdk.h
> +++ b/include/configs/socfpga_stratix10_socdk.h
> @@ -113,7 +113,8 @@ unsigned int cm_get_qspi_controller_clk_hz(void);
> "scriptaddr=0x0210\0" \
> "scriptfile=u-boot.scr\0" \
> "fatscript=if fatload mmc 0:1 ${scriptaddr} ${scriptfile};" \
> -"then source ${scriptaddr}; fi\0"
> +"then source ${scriptaddr}; fi\0" \
> + "socfpga_legacy_reset_compat=1\0"
>
> /*
> * Generic Interrupt Controller Definitions
> diff --git a/include/configs/socfpga_vining_fpga.h
> b/include/configs/socfpga_vining_fpga.h
> index 29a92b9146..737a304217 100644
> --- a/include/configs/socfpga_vining_fpga.h
> +++ b/include/configs/socfpga_vining_fpga.h
> @@ -145,6 +145,7 @@
> "run ubi_ubi ; "\
> "else echo \"Unsupported boot mode: \"${bootmode} ; " \
> "fi\0" \
> + "socfpga_legacy_reset_compat=1\0" \
>
> #define CONFIG_SYS_REDUNDAND_ENVIRONMENT
> #define CONFIG_ENV_SIZE_REDUND CONFIG_ENV_SIZE
>
On my board, setting "socfpga_legacy_reset_compat=1" was not enough. It
also needs "bootm_size=0xa00" to boot Linux.
Wolfgang
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] net: ravb: Avoid unsupported internal delay mode for R-Car E3/D3
On Wed, May 1, 2019 at 5:36 PM Marek Vasut wrote: > > According to the R-Car Gen3 Hardware Manual Rev 1.50 of Nov 30, 2018, the > TX clock internal delay mode isn't supported on R-Car E3 (r8a77990) or D3 > (r8a77995). > > Avoid setting the APSR:TDM bit on these SoCs. Moreover, only set APSR:TDM > when the DT explicitly specifies RGMII ID or TXID mode instead of setting > it unconditionally when the PHY link speed is 1000 Mbit/s. We just ran into an issue with a very similar patch. It blocked my tree being merged for a few months. Finally got to the bottom of it. https://patchwork.ozlabs.org/patch/1096572/ Are you sure there are no boards depending on the broken DT, like the 335-evm was? > > Signed-off-by: Marek Vasut > Cc: Nobuhiro Iwamatsu > Cc: Joe Hershberger > --- > drivers/net/ravb.c | 13 ++--- > 1 file changed, 10 insertions(+), 3 deletions(-) > > diff --git a/drivers/net/ravb.c b/drivers/net/ravb.c > index 749562db96..11abe5e0c9 100644 > --- a/drivers/net/ravb.c > +++ b/drivers/net/ravb.c > @@ -46,6 +46,8 @@ > #define CSR_OPS0x000F > #define CSR_OPS_CONFIG BIT(1) > > +#define APSR_TDM BIT(14) > + > #define TCCR_TSRQ0 BIT(0) > > #define RFLR_RFL_MIN 0x05EE > @@ -389,9 +391,14 @@ static int ravb_dmac_init(struct udevice *dev) > /* FIFO size set */ > writel(0x0010, eth->iobase + RAVB_REG_TGC); > > - /* Delay CLK: 2ns */ > - if (pdata->max_speed == 1000) > - writel(BIT(14), eth->iobase + RAVB_REG_APSR); > + /* Delay CLK: 2ns (not applicable on R-Car E3/D3) */ > + if ((rmobile_get_cpu_type() == RMOBILE_CPU_TYPE_R8A77990) || > + (rmobile_get_cpu_type() == RMOBILE_CPU_TYPE_R8A77995)) > + return 0; > + > + if ((pdata->phy_interface == PHY_INTERFACE_MODE_RGMII_ID) || > + (pdata->phy_interface == PHY_INTERFACE_MODE_RGMII_TXID)) > + writel(APSR_TDM, eth->iobase + RAVB_REG_APSR); > > return 0; > } > -- > 2.20.1 > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 2/4] sysreset: socfpga: gen5: add sysreset driver
On 09.05.19 20:08, Simon Goldschmidt wrote:
This adds a UCLASS_SYSRESET sysreset driver for socfgpa gen5.
Signed-off-by: Simon Goldschmidt
---
Changes in v3:
- moved socfpga gen5 sysreset driver to extra patch
Changes in v2: None
drivers/sysreset/Kconfig| 7
drivers/sysreset/Makefile | 1 +
drivers/sysreset/sysreset_socfpga.c | 56 +
3 files changed, 64 insertions(+)
create mode 100644 drivers/sysreset/sysreset_socfpga.c
I just noticed patman complained about new files regarding MAINTAINERS.
Should these new drivers be listed in the MAINTAINERS file under the
socfpga section? I noticed other platforms seem to do that but we don't.
How is this handled?
Regards,
Simon
diff --git a/drivers/sysreset/Kconfig b/drivers/sysreset/Kconfig
index 8ce3e2e207..066838c106 100644
--- a/drivers/sysreset/Kconfig
+++ b/drivers/sysreset/Kconfig
@@ -36,6 +36,13 @@ config SYSRESET_PSCI
Enable PSCI SYSTEM_RESET function call. To use this, PSCI firmware
must be running on your system.
+config SYSRESET_SOCFPGA
+ bool "Enable support for Intel SOCFPGA family"
+ depends on ARCH_SOCFPGA && (TARGET_SOCFPGA_GEN5 ||
TARGET_SOCFPGA_ARRIA10)
+ help
+ This enables the system reset driver support for Intel SOCFPGA SoCs
+ (Cyclone 5, Arria 5 and Arria 10).
+
config SYSRESET_TI_SCI
bool "TI System Control Interface (TI SCI) system reset driver"
depends on TI_SCI_PROTOCOL
diff --git a/drivers/sysreset/Makefile b/drivers/sysreset/Makefile
index b3728ac17f..0241b0132d 100644
--- a/drivers/sysreset/Makefile
+++ b/drivers/sysreset/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_SYSRESET_GPIO) += sysreset_gpio.o
obj-$(CONFIG_SYSRESET_MCP83XX) += sysreset_mpc83xx.o
obj-$(CONFIG_SYSRESET_MICROBLAZE) += sysreset_microblaze.o
obj-$(CONFIG_SYSRESET_PSCI) += sysreset_psci.o
+obj-$(CONFIG_SYSRESET_SOCFPGA) += sysreset_socfpga.o
obj-$(CONFIG_SYSRESET_TI_SCI) += sysreset-ti-sci.o
obj-$(CONFIG_SYSRESET_SYSCON) += sysreset_syscon.o
obj-$(CONFIG_SYSRESET_WATCHDOG) += sysreset_watchdog.o
diff --git a/drivers/sysreset/sysreset_socfpga.c
b/drivers/sysreset/sysreset_socfpga.c
new file mode 100644
index 00..fc1ba72d5b
--- /dev/null
+++ b/drivers/sysreset/sysreset_socfpga.c
@@ -0,0 +1,56 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2019 Pepperl+Fuchs
+ * Simon Goldschmidt
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct socfpga_sysreset_data {
+ struct socfpga_reset_manager *rstmgr_base;
+};
+
+static int socfpga_sysreset_request(struct udevice *dev,
+ enum sysreset_t type)
+{
+ struct socfpga_sysreset_data *data = dev_get_priv(dev);
+
+ switch (type) {
+ case SYSRESET_WARM:
+ writel(1 << RSTMGR_CTRL_SWWARMRSTREQ_LSB,
+ >rstmgr_base->ctrl);
+ break;
+ case SYSRESET_COLD:
+ writel(1 << RSTMGR_CTRL_SWCOLDRSTREQ_LSB,
+ >rstmgr_base->ctrl);
+ break;
+ default:
+ return -EPROTONOSUPPORT;
+ }
+ return -EINPROGRESS;
+}
+
+static int socfpga_sysreset_probe(struct udevice *dev)
+{
+ struct socfpga_sysreset_data *data = dev_get_priv(dev);
+
+ data->rstmgr_base = devfdt_get_addr_ptr(dev);
+ return 0;
+}
+
+static struct sysreset_ops socfpga_sysreset = {
+ .request = socfpga_sysreset_request,
+};
+
+U_BOOT_DRIVER(sysreset_socfpga) = {
+ .id = UCLASS_SYSRESET,
+ .name = "socfpga_sysreset",
+ .priv_auto_alloc_size = sizeof(struct socfpga_sysreset_data),
+ .ops= _sysreset,
+ .probe = socfpga_sysreset_probe,
+};
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] net: davinci_emac: use driver model (CONFIG_DM_ETH)
On Tue, Apr 30, 2019 at 11:04 AM Bartosz Golaszewski wrote:
>
> From: Bartosz Golaszewski
>
> Add support for CONFIG_DM_ETH to the davinci_emac driver. Optimally
> we should only support DM-enabled platforms but there are several
> non-DT boards that still use it so either we need to keep supporting
> it or drop the boards from u-boot. For now we're stuck with ugly
> ifdefs.
Which boards are still not using DM that you refer to here?
>
> This patch adds support for driver-model to the driver and converts
> all platforms that use the driver model to selecting CONFIG_DM_ETH.
>
> Tested on da850-evm and da850-lcdk.
>
> Signed-off-by: Bartosz Golaszewski
> ---
> NOTE: I'm currently working on modernizing da850 support in u-boot.
> This patch is just the first step - I plan on improving the emac driver
> in general but I'll be OoO until end of next week, so I decided to post
> it already for reviews.
>
> Does anyone know what the status is on boards like twister, ea20 etc.
> that use davinci_emac, but don't use the driver model? Dropping them
> would make it easier to clean up this driver.
>
> This patch applies on top of my previous series[1].
>
> [1] https://lists.denx.de/pipermail/u-boot/2019-April/367236.html
>
> arch/arm/mach-davinci/cpu.c| 13 ---
> arch/arm/mach-omap2/omap3/emac.c | 3 +-
> board/davinci/da8xxevm/da850evm.c | 5 --
> board/davinci/da8xxevm/omapl138_lcdk.c | 14
> board/logicpd/am3517evm/am3517evm.c| 1 -
> board/ti/ti816x/evm.c | 3 +-
> configs/am3517_evm_defconfig | 1 +
> configs/da850_am18xxevm_defconfig | 1 +
> configs/da850evm_defconfig | 1 +
> configs/da850evm_direct_nor_defconfig | 1 +
> configs/omapl138_lcdk_defconfig| 1 +
> configs/ti816x_evm_defconfig | 1 +
> drivers/net/ti/davinci_emac.c | 109 +
> 13 files changed, 100 insertions(+), 54 deletions(-)
>
> diff --git a/arch/arm/mach-davinci/cpu.c b/arch/arm/mach-davinci/cpu.c
> index f97ad3fc74..9fd6564d04 100644
> --- a/arch/arm/mach-davinci/cpu.c
> +++ b/arch/arm/mach-davinci/cpu.c
> @@ -5,7 +5,6 @@
> */
>
> #include
> -#include
> #include
> #include
>
> @@ -90,15 +89,3 @@ int set_cpu_clk_info(void)
> gd->bd->bi_dsp_freq = 0;
> return 0;
> }
> -
> -/*
> - * Initializes on-chip ethernet controllers.
> - * to override, implement board_eth_init()
> - */
> -int cpu_eth_init(bd_t *bis)
> -{
> -#if defined(CONFIG_DRIVER_TI_EMAC)
> - davinci_emac_initialize();
> -#endif
> - return 0;
> -}
> diff --git a/arch/arm/mach-omap2/omap3/emac.c
> b/arch/arm/mach-omap2/omap3/emac.c
> index c79e870183..fb0c9188f5 100644
> --- a/arch/arm/mach-omap2/omap3/emac.c
> +++ b/arch/arm/mach-omap2/omap3/emac.c
> @@ -7,7 +7,6 @@
> */
>
> #include
> -#include
> #include
> #include
>
> @@ -24,5 +23,5 @@ int cpu_eth_init(bd_t *bis)
> reset &= ~CPGMACSS_SW_RST;
> writel(reset, _scm_general_regs->ip_sw_reset);
>
> - return davinci_emac_initialize();
> + return 0;
> }
> diff --git a/board/davinci/da8xxevm/da850evm.c
> b/board/davinci/da8xxevm/da850evm.c
> index 1bc26828bf..0d2bc5fb32 100644
> --- a/board/davinci/da8xxevm/da850evm.c
> +++ b/board/davinci/da8xxevm/da850evm.c
> @@ -13,7 +13,6 @@
> #include
> #include
> #include
> -#include
> #include
> #include
> #include
> @@ -472,10 +471,6 @@ int board_eth_init(bd_t *bis)
> if (rmii_hw_init())
> printf("RMII hardware init failed!!!\n");
> #endif
> - if (!davinci_emac_initialize()) {
> - printf("Error: Ethernet init failed!\n");
> - return -1;
> - }
>
> return 0;
> }
> diff --git a/board/davinci/da8xxevm/omapl138_lcdk.c
> b/board/davinci/da8xxevm/omapl138_lcdk.c
> index 2c2f885d43..ef9656add8 100644
> --- a/board/davinci/da8xxevm/omapl138_lcdk.c
> +++ b/board/davinci/da8xxevm/omapl138_lcdk.c
> @@ -11,7 +11,6 @@
> #include
> #include
> #include
> -#include
> #include
> #include
> #include
> @@ -229,19 +228,6 @@ int board_init(void)
>
> #ifdef CONFIG_DRIVER_TI_EMAC
>
> -/*
> - * Initializes on-board ethernet controllers.
> - */
> -int board_eth_init(bd_t *bis)
> -{
> - if (!davinci_emac_initialize()) {
> - printf("Error: Ethernet init failed!\n");
> - return -1;
> - }
> -
> - return 0;
> -}
> -
> #endif /* CONFIG_DRIVER_TI_EMAC */
>
> #define CFG_MAC_ADDR_SPI_BUS 0
> diff --git a/board/logicpd/am3517evm/am3517evm.c
> b/board/logicpd/am3517evm/am3517evm.c
> index 10031a4801..bfd4e78274 100644
> --- a/board/logicpd/am3517evm/am3517evm.c
> +++ b/board/logicpd/am3517evm/am3517evm.c
> @@ -28,7 +28,6 @@
> #include
> #include
> #include
> -#include
> #include "am3517evm.h"
>
> DECLARE_GLOBAL_DATA_PTR;
> diff --git a/board/ti/ti816x/evm.c b/board/ti/ti816x/evm.c
> index 07a084bab8..240df8cbe1 100644
> ---
[U-Boot] [PATCH] arm: socfpga: fix 3 boards missing env var "socfpga_legacy_reset_compat"
This fixes 3 boards that don't use CONFIG_EXTRA_ENV_SETTINGS from
socfpga_common.h. They need to enable reset manager compatibility
mode unless all peripheral drivers in Linux support reset handling.
Fixes: commit 4b2e32efa4e7 ("arm: socfpga: gen5: deassert peripheral reset by
default")
Signed-off-by: Simon Goldschmidt
Reported-by: Wolfgang Grandegger
---
include/configs/socfpga_dbm_soc1.h| 3 ++-
include/configs/socfpga_stratix10_socdk.h | 3 ++-
include/configs/socfpga_vining_fpga.h | 1 +
3 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/include/configs/socfpga_dbm_soc1.h
b/include/configs/socfpga_dbm_soc1.h
index b36d7e56fb..fc1db2442e 100644
--- a/include/configs/socfpga_dbm_soc1.h
+++ b/include/configs/socfpga_dbm_soc1.h
@@ -87,7 +87,8 @@
"echo Running bootscript... ; " \
"source ${kernel_addr_r} ; "\
"fi ; " \
- "fi\0"
+ "fi\0" \
+ "socfpga_legacy_reset_compat=1\0"
/* The rest of the configuration is shared */
#include
diff --git a/include/configs/socfpga_stratix10_socdk.h
b/include/configs/socfpga_stratix10_socdk.h
index 8d2971c6e2..90ad8172e2 100644
--- a/include/configs/socfpga_stratix10_socdk.h
+++ b/include/configs/socfpga_stratix10_socdk.h
@@ -113,7 +113,8 @@ unsigned int cm_get_qspi_controller_clk_hz(void);
"scriptaddr=0x0210\0" \
"scriptfile=u-boot.scr\0" \
"fatscript=if fatload mmc 0:1 ${scriptaddr} ${scriptfile};" \
- "then source ${scriptaddr}; fi\0"
+ "then source ${scriptaddr}; fi\0" \
+ "socfpga_legacy_reset_compat=1\0"
/*
* Generic Interrupt Controller Definitions
diff --git a/include/configs/socfpga_vining_fpga.h
b/include/configs/socfpga_vining_fpga.h
index 29a92b9146..737a304217 100644
--- a/include/configs/socfpga_vining_fpga.h
+++ b/include/configs/socfpga_vining_fpga.h
@@ -145,6 +145,7 @@
"run ubi_ubi ; "\
"else echo \"Unsupported boot mode: \"${bootmode} ; " \
"fi\0" \
+ "socfpga_legacy_reset_compat=1\0" \
#define CONFIG_SYS_REDUNDAND_ENVIRONMENT
#define CONFIG_ENV_SIZE_REDUND CONFIG_ENV_SIZE
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/6] env: ubi: KConfig: add CONFIG_ENV_UBI_VOLUME_REDUND
âFrom: Markus Klotzbuecher User-Agent: Mutt/1.10.1 (2018-07-13) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - m2731.contabo.net X-AntiAbuse: Original Domain - lists.denx.de X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - mkio.de X-Get-Message-Sender-Via: m2731.contabo.net: authenticated_id: m...@mkio.de X-Authenticated-Sender: m2731.contabo.net: m...@mkio.de X-Source: X-Source-Args: X-Source-Dir: On Thu, May 09, 2019 at 05:49:51PM +0200, Markus Klotzbuecher wrote: ... >I'm now trying to run moveconfig as follows > >$ grep -l "ARCH_OMAP2PLUS\|ARCH_AT91" configs/* | ./tools/moveconfig.py -s >ENV_OFFSET ENV_SIZE ENV_SECT_SIZE -d - > >but the command hangs infinitely. > >If I run it for all boards without "-d", it starts processing and gets >through about 50 configs and then hangs too. > >Any idea what may be the cause? I found it: I didn't add a default to the new KConfig, so the script got stuck when it was asked for the new config options. Sorry for the noise. Markus -- Markus Klotzbuecher Freelancer Embedded, Distributed & Real-time Am See 28, 78465 Konstanz, Germany ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 2/4] sysreset: socfpga: gen5: add sysreset driver
This adds a UCLASS_SYSRESET sysreset driver for socfgpa gen5.
Signed-off-by: Simon Goldschmidt
---
Changes in v3:
- moved socfpga gen5 sysreset driver to extra patch
Changes in v2: None
drivers/sysreset/Kconfig| 7
drivers/sysreset/Makefile | 1 +
drivers/sysreset/sysreset_socfpga.c | 56 +
3 files changed, 64 insertions(+)
create mode 100644 drivers/sysreset/sysreset_socfpga.c
diff --git a/drivers/sysreset/Kconfig b/drivers/sysreset/Kconfig
index 8ce3e2e207..066838c106 100644
--- a/drivers/sysreset/Kconfig
+++ b/drivers/sysreset/Kconfig
@@ -36,6 +36,13 @@ config SYSRESET_PSCI
Enable PSCI SYSTEM_RESET function call. To use this, PSCI firmware
must be running on your system.
+config SYSRESET_SOCFPGA
+ bool "Enable support for Intel SOCFPGA family"
+ depends on ARCH_SOCFPGA && (TARGET_SOCFPGA_GEN5 ||
TARGET_SOCFPGA_ARRIA10)
+ help
+ This enables the system reset driver support for Intel SOCFPGA SoCs
+ (Cyclone 5, Arria 5 and Arria 10).
+
config SYSRESET_TI_SCI
bool "TI System Control Interface (TI SCI) system reset driver"
depends on TI_SCI_PROTOCOL
diff --git a/drivers/sysreset/Makefile b/drivers/sysreset/Makefile
index b3728ac17f..0241b0132d 100644
--- a/drivers/sysreset/Makefile
+++ b/drivers/sysreset/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_SYSRESET_GPIO) += sysreset_gpio.o
obj-$(CONFIG_SYSRESET_MCP83XX) += sysreset_mpc83xx.o
obj-$(CONFIG_SYSRESET_MICROBLAZE) += sysreset_microblaze.o
obj-$(CONFIG_SYSRESET_PSCI) += sysreset_psci.o
+obj-$(CONFIG_SYSRESET_SOCFPGA) += sysreset_socfpga.o
obj-$(CONFIG_SYSRESET_TI_SCI) += sysreset-ti-sci.o
obj-$(CONFIG_SYSRESET_SYSCON) += sysreset_syscon.o
obj-$(CONFIG_SYSRESET_WATCHDOG) += sysreset_watchdog.o
diff --git a/drivers/sysreset/sysreset_socfpga.c
b/drivers/sysreset/sysreset_socfpga.c
new file mode 100644
index 00..fc1ba72d5b
--- /dev/null
+++ b/drivers/sysreset/sysreset_socfpga.c
@@ -0,0 +1,56 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2019 Pepperl+Fuchs
+ * Simon Goldschmidt
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct socfpga_sysreset_data {
+ struct socfpga_reset_manager *rstmgr_base;
+};
+
+static int socfpga_sysreset_request(struct udevice *dev,
+ enum sysreset_t type)
+{
+ struct socfpga_sysreset_data *data = dev_get_priv(dev);
+
+ switch (type) {
+ case SYSRESET_WARM:
+ writel(1 << RSTMGR_CTRL_SWWARMRSTREQ_LSB,
+ >rstmgr_base->ctrl);
+ break;
+ case SYSRESET_COLD:
+ writel(1 << RSTMGR_CTRL_SWCOLDRSTREQ_LSB,
+ >rstmgr_base->ctrl);
+ break;
+ default:
+ return -EPROTONOSUPPORT;
+ }
+ return -EINPROGRESS;
+}
+
+static int socfpga_sysreset_probe(struct udevice *dev)
+{
+ struct socfpga_sysreset_data *data = dev_get_priv(dev);
+
+ data->rstmgr_base = devfdt_get_addr_ptr(dev);
+ return 0;
+}
+
+static struct sysreset_ops socfpga_sysreset = {
+ .request = socfpga_sysreset_request,
+};
+
+U_BOOT_DRIVER(sysreset_socfpga) = {
+ .id = UCLASS_SYSRESET,
+ .name = "socfpga_sysreset",
+ .priv_auto_alloc_size = sizeof(struct socfpga_sysreset_data),
+ .ops= _sysreset,
+ .probe = socfpga_sysreset_probe,
+};
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 1/4] arm: socfpga: rst: add register definition for cold reset
This adds a define for the bit in rstmgr's ctrl regiser that issues a cold reset (we had a define for the warm reset bit only) in preparation for a proper sysrese driver. Signed-off-by: Simon Goldschmidt Series changes: 2 - separate this patch to the register descriptions from the actual sysreset driver patch --- Changes in v3: None Changes in v2: None arch/arm/mach-socfpga/include/mach/reset_manager.h | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/mach-socfpga/include/mach/reset_manager.h b/arch/arm/mach-socfpga/include/mach/reset_manager.h index 42beaecdd6..6ad037e325 100644 --- a/arch/arm/mach-socfpga/include/mach/reset_manager.h +++ b/arch/arm/mach-socfpga/include/mach/reset_manager.h @@ -11,6 +11,7 @@ void reset_cpu(ulong addr); void socfpga_per_reset(u32 reset, int set); void socfpga_per_reset_all(void); +#define RSTMGR_CTRL_SWCOLDRSTREQ_LSB 0 #define RSTMGR_CTRL_SWWARMRSTREQ_LSB 1 /* -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 3/4] sysreset: socfpga: stratix10: add sysreset driver
This adds a UCLASS_SYSRESET sysreset driver for socfgpa stratix10.
Signed-off-by: Simon Goldschmidt
---
Changes in v3:
- moved socfpga stratix sysreset driver to extra patch
Changes in v2: None
drivers/sysreset/Kconfig| 7 ++
drivers/sysreset/Makefile | 1 +
drivers/sysreset/sysreset_socfpga_s10.c | 29 +
3 files changed, 37 insertions(+)
create mode 100644 drivers/sysreset/sysreset_socfpga_s10.c
diff --git a/drivers/sysreset/Kconfig b/drivers/sysreset/Kconfig
index 066838c106..5b8402ccae 100644
--- a/drivers/sysreset/Kconfig
+++ b/drivers/sysreset/Kconfig
@@ -43,6 +43,13 @@ config SYSRESET_SOCFPGA
This enables the system reset driver support for Intel SOCFPGA SoCs
(Cyclone 5, Arria 5 and Arria 10).
+config SYSRESET_SOCFPGA_S10
+ bool "Enable support for Intel SOCFPGA Stratix 10"
+ depends on ARCH_SOCFPGA && TARGET_SOCFPGA_STRATIX10
+ help
+ This enables the system reset driver support for Intel SOCFPGA
+ Stratix SoCs.
+
config SYSRESET_TI_SCI
bool "TI System Control Interface (TI SCI) system reset driver"
depends on TI_SCI_PROTOCOL
diff --git a/drivers/sysreset/Makefile b/drivers/sysreset/Makefile
index 0241b0132d..71291fa2cf 100644
--- a/drivers/sysreset/Makefile
+++ b/drivers/sysreset/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_SYSRESET_MCP83XX) += sysreset_mpc83xx.o
obj-$(CONFIG_SYSRESET_MICROBLAZE) += sysreset_microblaze.o
obj-$(CONFIG_SYSRESET_PSCI) += sysreset_psci.o
obj-$(CONFIG_SYSRESET_SOCFPGA) += sysreset_socfpga.o
+obj-$(CONFIG_SYSRESET_SOCFPGA_S10) += sysreset_socfpga_s10.o
obj-$(CONFIG_SYSRESET_TI_SCI) += sysreset-ti-sci.o
obj-$(CONFIG_SYSRESET_SYSCON) += sysreset_syscon.o
obj-$(CONFIG_SYSRESET_WATCHDOG) += sysreset_watchdog.o
diff --git a/drivers/sysreset/sysreset_socfpga_s10.c
b/drivers/sysreset/sysreset_socfpga_s10.c
new file mode 100644
index 00..9837aadf64
--- /dev/null
+++ b/drivers/sysreset/sysreset_socfpga_s10.c
@@ -0,0 +1,29 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2019 Pepperl+Fuchs
+ * Simon Goldschmidt
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+static int socfpga_sysreset_request(struct udevice *dev,
+ enum sysreset_t type)
+{
+ puts("Mailbox: Issuing mailbox cmd REBOOT_HPS\n");
+ mbox_reset_cold();
+ return -EINPROGRESS;
+}
+
+static struct sysreset_ops socfpga_sysreset = {
+ .request = socfpga_sysreset_request,
+};
+
+U_BOOT_DRIVER(sysreset_socfpga) = {
+ .id = UCLASS_SYSRESET,
+ .name = "socfpga_sysreset",
+ .ops= _sysreset,
+};
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 4/4] sysreset: add support for socfpga sysreset
This moves sysreset support for socfgpa from ad-hoc code in mach-socfpga
to a UCLASS_SYSRESET based dm driver.
A side effect is that gen5 and a10 can now select between cold and warm
reset.
Signed-off-by: Simon Goldschmidt
---
Changes in v3:
- this patch enables the new drivers and drops the ad-hoc code
Changes in v2:
- adapt to patch that separates drivers/sysreset from drivers/misc
for SPL: select SPL_SYSRESET_SUPPORT, not SPL_DRIVERS_MISC_SUPPORT
- separate gen5/a10 driver from s10 driver
- as sysreset is a function of rstmgr, bind the sysreset drivers
from rstmgr to get the base address instead of hardcoding it
arch/arm/Kconfig | 4 +++
arch/arm/mach-socfpga/Makefile| 1 -
arch/arm/mach-socfpga/reset_manager.c | 41 ---
drivers/reset/reset-socfpga.c | 19 +
4 files changed, 23 insertions(+), 42 deletions(-)
delete mode 100644 arch/arm/mach-socfpga/reset_manager.c
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index f91c590f6d..327adbbf0a 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -829,10 +829,14 @@ config ARCH_SOCFPGA
select SPL_OF_CONTROL
select SPL_SEPARATE_BSS if TARGET_SOCFPGA_STRATIX10
select SPL_SERIAL_SUPPORT
+ select SPL_SYSRESET_SUPPORT
select SPL_WATCHDOG_SUPPORT
select SUPPORT_SPL
select SYS_NS16550
select SYS_THUMB_BUILD if TARGET_SOCFPGA_GEN5 || TARGET_SOCFPGA_ARRIA10
+ select SYSRESET
+ select SYSRESET_SOCFPGA if TARGET_SOCFPGA_GEN5 || TARGET_SOCFPGA_ARRIA10
+ select SYSRESET_SOCFPGA_STRATIX10 if TARGET_SOCFPGA_STRATIX10
imply CMD_DM
imply CMD_MTDPARTS
imply CRC32_VERIFY
diff --git a/arch/arm/mach-socfpga/Makefile b/arch/arm/mach-socfpga/Makefile
index e66720447f..fc1181cb27 100644
--- a/arch/arm/mach-socfpga/Makefile
+++ b/arch/arm/mach-socfpga/Makefile
@@ -8,7 +8,6 @@
obj-y += board.o
obj-y += clock_manager.o
obj-y += misc.o
-obj-y += reset_manager.o
ifdef CONFIG_TARGET_SOCFPGA_GEN5
obj-y += clock_manager_gen5.o
diff --git a/arch/arm/mach-socfpga/reset_manager.c
b/arch/arm/mach-socfpga/reset_manager.c
deleted file mode 100644
index e0a01ed07a..00
--- a/arch/arm/mach-socfpga/reset_manager.c
+++ /dev/null
@@ -1,41 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-/*
- * Copyright (C) 2013 Altera Corporation
- */
-
-
-#include
-#include
-#include
-
-#if defined(CONFIG_TARGET_SOCFPGA_STRATIX10)
-#include
-#endif
-
-DECLARE_GLOBAL_DATA_PTR;
-
-#if !defined(CONFIG_TARGET_SOCFPGA_STRATIX10)
-static const struct socfpga_reset_manager *reset_manager_base =
- (void *)SOCFPGA_RSTMGR_ADDRESS;
-#endif
-
-/*
- * Write the reset manager register to cause reset
- */
-void reset_cpu(ulong addr)
-{
- /* request a warm reset */
-#if defined(CONFIG_TARGET_SOCFPGA_STRATIX10)
- puts("Mailbox: Issuing mailbox cmd REBOOT_HPS\n");
- mbox_reset_cold();
-#else
- writel(1 << RSTMGR_CTRL_SWWARMRSTREQ_LSB,
- _manager_base->ctrl);
-#endif
- /*
-* infinite loop here as watchdog will trigger and reset
-* the processor
-*/
- while (1)
- ;
-}
diff --git a/drivers/reset/reset-socfpga.c b/drivers/reset/reset-socfpga.c
index cb8312619f..f49f064574 100644
--- a/drivers/reset/reset-socfpga.c
+++ b/drivers/reset/reset-socfpga.c
@@ -14,6 +14,7 @@
#include
#include
+#include
#include
#include
#include
@@ -132,6 +133,23 @@ static int socfpga_reset_remove(struct udevice *dev)
return 0;
}
+static int socfpga_reset_bind(struct udevice *dev)
+{
+ int ret;
+ struct udevice *sys_child;
+
+ /*
+* The sysreset driver does not have a device node, so bind it here.
+* Bind it to the node, too, so that it can get its base address.
+*/
+ ret = device_bind_driver_to_node(dev, "socfpga_sysreset", "sysreset",
+dev->node, _child);
+ if (ret)
+ debug("Warning: No sysreset driver: ret=%d\n", ret);
+
+ return 0;
+}
+
static const struct udevice_id socfpga_reset_match[] = {
{ .compatible = "altr,rst-mgr" },
{ /* sentinel */ },
@@ -141,6 +159,7 @@ U_BOOT_DRIVER(socfpga_reset) = {
.name = "socfpga-reset",
.id = UCLASS_RESET,
.of_match = socfpga_reset_match,
+ .bind = socfpga_reset_bind,
.probe = socfpga_reset_probe,
.priv_auto_alloc_size = sizeof(struct socfpga_reset_data),
.ops = _reset_ops,
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] wandboard: Don't use I2C speed Kconfig settings with DM_I2C
On Thu, 2019-05-09 at 08:20 +0200, Anatolij Gustschin wrote: > On Wed, 8 May 2019 23:30:01 + > Trent Piepho tpie...@impinj.com wrote: > ... > > diff --git a/board/wandboard/wandboard.c > > b/board/wandboard/wandboard.c > > index 69fbc8b690..9d7a94ff9d 100644 > > --- a/board/wandboard/wandboard.c > > +++ b/board/wandboard/wandboard.c > > @@ -46,6 +46,15 @@ DECLARE_GLOBAL_DATA_PTR; > > #define ETH_PHY_AR8035_POWER IMX_GPIO_NR(7, 13) > > #define REV_DETECTION IMX_GPIO_NR(2, 28) > > > > +/* Speed defined in Kconfig is only applicable when not using > > DM_I2C. */ > > +#ifdef CONFIG_DM_I2C > > +#define I2C1_SPEED_NON_DM 0 > > +#define I2C2_SPEED_NON_DM 0 > > +#else > > +#define I2C1_SPEED_NON_DM CONFIG_SYS_MXC_I2C1_SPEED > > +#define I2C2_SPEED_NON_DM CONFIG_SYS_MXC_I2C2_SPEED > > Shouldn't we change this to > > #ifdef CONFIG_DM_I2C > #define I2C2_SPEED_NON_DM 0 > #define I2C3_SPEED_NON_DM 0 > #else > #define I2C2_SPEED_NON_DM CONFIG_SYS_MXC_I2C2_SPEED > #define I2C3_SPEED_NON_DM CONFIG_SYS_MXC_I2C3_SPEED > #endif > ... > setup_i2c(1, I2C2_SPEED_NON_DM, 0x7f, _i2c2_pad_info); > setup_i2c(2, I2C3_SPEED_NON_DM, 0x7f, _i2c3_pad_info); > ? > > Because the first argument to setup_i2c() is the bus number > which starts counting from 0, but the CONFIG_SYS_MXC_I2C* > start counting from 1. This doesn't affect the actual > configuration since the speed value is currently the same > for all buses. But it is more accurate. Seems like it should have been, but the existing code uses I2C1_SPEED and I2C2_SPEED. Probably a bug. But if I change it here, then it will affect existing config files, which were done when the bug existed. Also I see it calls setup_i2c(1, ...) twice, which seems like another bug. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 13/18] arm: K3: am654: Map common EEPROM data into SRAM scratch space
Andrew, On Thu, May 09, 2019 at 12:03:31PM -0400, Andrew F. Davis wrote: > On 5/8/19 11:52 PM, Lokesh Vutla wrote: > > > > > > On 09/05/19 3:07 AM, Andreas Dannenberg wrote: > >> The board detection scheme employed on various TI EVMs makes use of > >> SRAM scratch space to share data read from an on-board EEPROM between > >> the different bootloading stages. Map the associated definition that's > >> used to locate this data into the SRAM scratch space we use on AM654x. > >> > >> Signed-off-by: Andreas Dannenberg > >> --- > >> arch/arm/mach-k3/include/mach/am6_hardware.h | 3 +++ > >> 1 file changed, 3 insertions(+) > >> > >> diff --git a/arch/arm/mach-k3/include/mach/am6_hardware.h > >> b/arch/arm/mach-k3/include/mach/am6_hardware.h > >> index 3343233aa3..6df7631545 100644 > >> --- a/arch/arm/mach-k3/include/mach/am6_hardware.h > >> +++ b/arch/arm/mach-k3/include/mach/am6_hardware.h > >> @@ -44,4 +44,7 @@ > >> #define CTRLMMR_LOCK_KICK10x0100c > >> #define CTRLMMR_LOCK_KICK1_UNLOCK_VAL 0xd172bc5a > >> > >> +/* MCU SCRATCHPAD usage */ > >> +#define TI_SRAM_SCRATCH_BOARD_EEPROM_START > >> CONFIG_SYS_K3_MCU_SCRATCHPAD_BASE > > > > Won't HS devices fail while accessing this region? We should drop it > > altogether. > > > > HS devices cannot read this before SYSFW is loaded as by default it is > left firewalled by ROM. This read happens after SYSFW loading so it does > work currently, but no guarantee SYSFW will always remove this firewall > by default, we may need a driver that does an explicit device get for > this region to be sure it is powered and accessible (it is on a > different reset domain, it may need special handling). Yes this is understood. For others reading this, this is how it is done in our current production U-Boot tree (upstream U-Boot does not yet have SYSFW loading capability). > I think we should avoid using this scratchpad for a couple other > reasons. After R5 SPL has finished bootloading is handled by A53 cores, > the R5 will be repurposed and other software will run on it, possibly > wiping out the memory here. Anything we want to pass form R5 to A53 > should use a non-R5-local memory, not this scratchpad. We need the same > for passing the original boot media info also. > > A lot of pitfalls for just 512 bytes of RAM.. I don't disagree, this approach is limited, it's just the "easiest" we started using when creating the initial solution. Let's find/align on a different memory region. While at it, there is a need to pass additional data across our three boot stages (R5 SPL -> A53 SPL -> A53 U-Boot); for example I'd at some point like to carry forward peripheral initialization state (so we don't have to re-probe stuff 3 times), amongst other things, for which I was eyeing to use the new CONFIG_BLOBLIST* feature. So if we can identify a new/dedicated memory region for such data it would be a good opportunity to also start making use of the BLOBLIST feature at the same time, creating a more scalable solution. -- Andreas Dannenberg Texas Instruments Inc > Andrew > > > Thanks and regards, > > Lokesh > > > >> + > >> #endif /* __ASM_ARCH_AM6_HARDWARE_H */ > >> > > ___ > > U-Boot mailing list > > U-Boot@lists.denx.de > > https://lists.denx.de/listinfo/u-boot > > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Pull request for UEFI sub-system for v2019.07-rc2 (2)
On Thu, May 09, 2019 at 06:05:57PM +0200, Heinrich Schuchardt wrote:
> On 5/9/19 4:16 PM, Tom Rini wrote:
> > On Thu, May 09, 2019 at 12:03:38AM +0200, Heinrich Schuchardt wrote:
> >> On 5/8/19 7:50 PM, Tom Rini wrote:
> >>> On Wed, May 08, 2019 at 07:57:57AM +0200, Heinrich Schuchardt wrote:
> >>>
> The following changes since commit
> 44237e272f1eac3b026709e76333a07b2d3a3523:
>
> Merge branch 'master' of git://git.denx.de/u-boot-sh (2019-05-06
> 07:19:31 -0400)
>
> are available in the Git repository at:
>
> git://git.denx.de/u-boot-efi.git tags/efi-2019-07-rc2-2
>
> for you to fetch changes up to
> b015ab57bf558daa1c768995a7a7f1df2d40191e:
>
> efi_loader: signature of ExitBootServices() (2019-05-07 21:10:04
> +0200)
>
> Travis CI results are here:
> https://travis-ci.org/xypron2/u-boot/builds/529448555
>
> Primary key fingerprint: 6DC4 F9C7 1F29 A6FA 06B7 6D33 C481 DBBC
> 2C05 1AC4
>
> >>>
> >>> Note that you may want to run ./scripts/checkpatch.pl --git
> >>> origin/master.. or similar as: WARNING: 'follwing' may be misspelled
> >>> - perhaps 'following'?
> >>>
> >>> which I left alone rather than mess up the tag.
> >>
> >> Sorry I missed that one. Typically I run checkpatch.pl.
> >>
> >>>
> >>> Applied to u-boot/master, thanks!
> >>>
> >>> And all of that said, looking over my before/after builds I see a lot
> >>> of size growth, everywhere, due to EFI changes. I assume this is due
> >>> to increasing overall functionality and support, which is good. But
> >>> is there perhaps some way we can split things into a minimal "we
> >>> have enough to support loading ${OS LOADER}" and then "we are aiming
> >>> for large parts of spec compliance" ? Some days I start to wonder
> >>> if "EFI_LOADER on by default" was a bad idea.
> >>>
> >>
> >> The following switches allow to reduce the size of the UEFI subsystem:
> >>
> >> CONFIG_CMD_BOOTEFI_HELLO, default N
> >> CONFIG_CMD_BOOTEFI_SELFTEST, default N except QEMU
> >
> > Note there's 2 non-QEMU platforms enabling it, can you please add a
> > patch turning it off and cc'ing the maintainer as they probably didn't
> > really mean to have that on? It's also not on for riscv QEMU nor
> > sandbox but should be?
> >
> >> CONFIG_EFI_UNICODE_CAPITALIZATION, default Y
> >> CONFIG_EFI_LOADER_HII
> >> (The Makefile does not consider it yet correctly, patch submitted.)
> >> CONFIG_CMD_EFIDEBUG, default N
> >> CONFIG_CMD_NVEDIT_EFI
> >
> > Adding in:
> > commit 7494b7764508332e37a3375fa0b6c328bc34637f
> > Author: Tom Rini
> > Date: Thu May 9 10:06:40 2019 -0400
> >
> > LOCAL: Disable some EFI stuff by default
> >
> > Signed-off-by: Tom Rini
> >
> > diff --git a/cmd/Kconfig b/cmd/Kconfig
> > index 4e11e0f404c8..4ebaf2f5bcb9 100644
> > --- a/cmd/Kconfig
> > +++ b/cmd/Kconfig
> > @@ -238,7 +238,6 @@ config CMD_BOOTEFI
> > config CMD_BOOTEFI_HELLO_COMPILE
> > bool "Compile a standard EFI hello world binary for testing"
> > depends on CMD_BOOTEFI && !CPU_V7M && !SANDBOX
> > - default y
> > help
> > This compiles a standard EFI hello world application with U-Boot so
> > that it can be used with the test/py testing framework. This is useful
> > @@ -434,7 +433,6 @@ config CMD_ENV_FLAGS
> > config CMD_NVEDIT_EFI
> > bool "env [set|print] -e - set/print UEFI variables"
> > depends on EFI_LOADER
> > - default y
> > imply HEXDUMP
> > help
> > UEFI variables are encoded as some form of U-Boot variables.
> > diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
> > index 50b050159c37..bd8fb9be00bc 100644
> > --- a/lib/efi_loader/Kconfig
> > +++ b/lib/efi_loader/Kconfig
> > @@ -19,7 +19,6 @@ config EFI_LOADER
> > config EFI_UNICODE_CAPITALIZATION
> > bool "Support Unicode capitalization"
> > depends on EFI_LOADER
> > - default y
> > help
> > Select this option to enable correct handling of the capitalization of
> > Unicode codepoints in the range 0x-0x. If this option is not
> > @@ -48,7 +47,6 @@ config EFI_LOADER_BOUNCE_BUFFER
> > config EFI_LOADER_HII
> > bool "Expose HII protocols to EFI applications"
> > depends on EFI_LOADER
> > - default y
> > help
> > The Human Interface Infrastructure is a complicated framework that
> > allows UEFI applications to draw fancy menus and hook strings using
> >
> > And note that with the bugfix to the Makefile for EFI_LOADER_HII added,
> > there's either more to be done, or it was already being discarded at
> > link time as applying that patch on top of this didn't result in any
> > size savings. Doing the above saves about 10kb. Which helps, but with
> > the numbers I mentioned earlier still puts us at about 40kb which Alex
> > was hoping it should be closer to 20kb. Is there more we can do here?
> > Thanks!
> >
>
> I already mentioned further areas that possibly can be made customizable
> in this
Re: [U-Boot] Pull request for UEFI sub-system for v2019.07-rc2 (2)
On 5/9/19 4:16 PM, Tom Rini wrote:
> On Thu, May 09, 2019 at 12:03:38AM +0200, Heinrich Schuchardt wrote:
>> On 5/8/19 7:50 PM, Tom Rini wrote:
>>> On Wed, May 08, 2019 at 07:57:57AM +0200, Heinrich Schuchardt wrote:
>>>
The following changes since commit
44237e272f1eac3b026709e76333a07b2d3a3523:
Merge branch 'master' of git://git.denx.de/u-boot-sh (2019-05-06
07:19:31 -0400)
are available in the Git repository at:
git://git.denx.de/u-boot-efi.git tags/efi-2019-07-rc2-2
for you to fetch changes up to
b015ab57bf558daa1c768995a7a7f1df2d40191e:
efi_loader: signature of ExitBootServices() (2019-05-07 21:10:04
+0200)
Travis CI results are here:
https://travis-ci.org/xypron2/u-boot/builds/529448555
Primary key fingerprint: 6DC4 F9C7 1F29 A6FA 06B7 6D33 C481 DBBC
2C05 1AC4
>>>
>>> Note that you may want to run ./scripts/checkpatch.pl --git
>>> origin/master.. or similar as: WARNING: 'follwing' may be misspelled
>>> - perhaps 'following'?
>>>
>>> which I left alone rather than mess up the tag.
>>
>> Sorry I missed that one. Typically I run checkpatch.pl.
>>
>>>
>>> Applied to u-boot/master, thanks!
>>>
>>> And all of that said, looking over my before/after builds I see a lot
>>> of size growth, everywhere, due to EFI changes. I assume this is due
>>> to increasing overall functionality and support, which is good. But
>>> is there perhaps some way we can split things into a minimal "we
>>> have enough to support loading ${OS LOADER}" and then "we are aiming
>>> for large parts of spec compliance" ? Some days I start to wonder
>>> if "EFI_LOADER on by default" was a bad idea.
>>>
>>
>> The following switches allow to reduce the size of the UEFI subsystem:
>>
>> CONFIG_CMD_BOOTEFI_HELLO, default N
>> CONFIG_CMD_BOOTEFI_SELFTEST, default N except QEMU
>
> Note there's 2 non-QEMU platforms enabling it, can you please add a
> patch turning it off and cc'ing the maintainer as they probably didn't
> really mean to have that on? It's also not on for riscv QEMU nor
> sandbox but should be?
>
>> CONFIG_EFI_UNICODE_CAPITALIZATION, default Y
>> CONFIG_EFI_LOADER_HII
>> (The Makefile does not consider it yet correctly, patch submitted.)
>> CONFIG_CMD_EFIDEBUG, default N
>> CONFIG_CMD_NVEDIT_EFI
>
> Adding in:
> commit 7494b7764508332e37a3375fa0b6c328bc34637f
> Author: Tom Rini
> Date: Thu May 9 10:06:40 2019 -0400
>
> LOCAL: Disable some EFI stuff by default
>
> Signed-off-by: Tom Rini
>
> diff --git a/cmd/Kconfig b/cmd/Kconfig
> index 4e11e0f404c8..4ebaf2f5bcb9 100644
> --- a/cmd/Kconfig
> +++ b/cmd/Kconfig
> @@ -238,7 +238,6 @@ config CMD_BOOTEFI
> config CMD_BOOTEFI_HELLO_COMPILE
> bool "Compile a standard EFI hello world binary for testing"
> depends on CMD_BOOTEFI && !CPU_V7M && !SANDBOX
> - default y
> help
> This compiles a standard EFI hello world application with U-Boot so
> that it can be used with the test/py testing framework. This is useful
> @@ -434,7 +433,6 @@ config CMD_ENV_FLAGS
> config CMD_NVEDIT_EFI
> bool "env [set|print] -e - set/print UEFI variables"
> depends on EFI_LOADER
> - default y
> imply HEXDUMP
> help
> UEFI variables are encoded as some form of U-Boot variables.
> diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
> index 50b050159c37..bd8fb9be00bc 100644
> --- a/lib/efi_loader/Kconfig
> +++ b/lib/efi_loader/Kconfig
> @@ -19,7 +19,6 @@ config EFI_LOADER
> config EFI_UNICODE_CAPITALIZATION
> bool "Support Unicode capitalization"
> depends on EFI_LOADER
> - default y
> help
> Select this option to enable correct handling of the capitalization of
> Unicode codepoints in the range 0x-0x. If this option is not
> @@ -48,7 +47,6 @@ config EFI_LOADER_BOUNCE_BUFFER
> config EFI_LOADER_HII
> bool "Expose HII protocols to EFI applications"
> depends on EFI_LOADER
> - default y
> help
> The Human Interface Infrastructure is a complicated framework that
> allows UEFI applications to draw fancy menus and hook strings using
>
> And note that with the bugfix to the Makefile for EFI_LOADER_HII added,
> there's either more to be done, or it was already being discarded at
> link time as applying that patch on top of this didn't result in any
> size savings. Doing the above saves about 10kb. Which helps, but with
> the numbers I mentioned earlier still puts us at about 40kb which Alex
> was hoping it should be closer to 20kb. Is there more we can do here?
> Thanks!
>
I already mentioned further areas that possibly can be made customizable
in this thread.
Alex numbers refer to a state where everything except starting GRUB
would fail in the 1st half of 2017. Even the most simple conceivable
UEFI binary doing nothing but `return EFI_SUCCESS;` resulted in a crash.
My priority is on using the UEFI SCT to identify areas
Re: [U-Boot] [PATCH 13/18] arm: K3: am654: Map common EEPROM data into SRAM scratch space
On 5/8/19 11:52 PM, Lokesh Vutla wrote: > > > On 09/05/19 3:07 AM, Andreas Dannenberg wrote: >> The board detection scheme employed on various TI EVMs makes use of >> SRAM scratch space to share data read from an on-board EEPROM between >> the different bootloading stages. Map the associated definition that's >> used to locate this data into the SRAM scratch space we use on AM654x. >> >> Signed-off-by: Andreas Dannenberg >> --- >> arch/arm/mach-k3/include/mach/am6_hardware.h | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/arch/arm/mach-k3/include/mach/am6_hardware.h >> b/arch/arm/mach-k3/include/mach/am6_hardware.h >> index 3343233aa3..6df7631545 100644 >> --- a/arch/arm/mach-k3/include/mach/am6_hardware.h >> +++ b/arch/arm/mach-k3/include/mach/am6_hardware.h >> @@ -44,4 +44,7 @@ >> #define CTRLMMR_LOCK_KICK1 0x0100c >> #define CTRLMMR_LOCK_KICK1_UNLOCK_VAL 0xd172bc5a >> >> +/* MCU SCRATCHPAD usage */ >> +#define TI_SRAM_SCRATCH_BOARD_EEPROM_START CONFIG_SYS_K3_MCU_SCRATCHPAD_BASE > > Won't HS devices fail while accessing this region? We should drop it > altogether. > HS devices cannot read this before SYSFW is loaded as by default it is left firewalled by ROM. This read happens after SYSFW loading so it does work currently, but no guarantee SYSFW will always remove this firewall by default, we may need a driver that does an explicit device get for this region to be sure it is powered and accessible (it is on a different reset domain, it may need special handling). I think we should avoid using this scratchpad for a couple other reasons. After R5 SPL has finished bootloading is handled by A53 cores, the R5 will be repurposed and other software will run on it, possibly wiping out the memory here. Anything we want to pass form R5 to A53 should use a non-R5-local memory, not this scratchpad. We need the same for passing the original boot media info also. A lot of pitfalls for just 512 bytes of RAM.. Andrew > Thanks and regards, > Lokesh > >> + >> #endif /* __ASM_ARCH_AM6_HARDWARE_H */ >> > ___ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/6] env: ubi: KConfig: add CONFIG_ENV_UBI_VOLUME_REDUND
Hello Heiko On Thu, May 09, 2019 at 01:17:06PM +0200, Heiko Schocher wrote: > >Am 09.05.2019 um 10:59 schrieb Markus Klotzbuecher: >> Hello Heiko >> >> On Tue, Apr 30, 2019 at 06:54:01AM +0200, Heiko Schocher wrote: >> >> > Am 15.04.2019 um 17:32 schrieb Markus Klotzbuecher: >> > > From: Markus Klotzbuecher >> > >> > please add a commit message. >> > >> > > Signed-off-by: Markus Klotzbuecher >> > > Cc: Heiko Schocher >> > > Cc: Kyungmin Park >> > > --- >> > >env/Kconfig | 6 ++ >> > >scripts/config_whitelist.txt | 1 - >> > >2 files changed, 6 insertions(+), 1 deletion(-) >> > > >> > > diff --git a/env/Kconfig b/env/Kconfig >> > > index 78300660c7..44c47220c2 100644 >> > > --- a/env/Kconfig >> > > +++ b/env/Kconfig >> > > @@ -513,6 +513,12 @@ config ENV_UBI_VOLUME >> > > help >> > >Name of the volume that you want to store the environment in. >> > > +config ENV_UBI_VOLUME_REDUND >> > > +string "UBI redundant volume name" >> > > +depends on ENV_IS_IN_UBI >> > > +help >> > > + Name of the redundant volume that you want to store the >> > > environment in. >> > > + >> > >endif >> > >config USE_DEFAULT_ENV_FILE >> > > diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt >> > > index fa98efc24c..5d76c781d3 100644 >> > > --- a/scripts/config_whitelist.txt >> > > +++ b/scripts/config_whitelist.txt >> > > @@ -504,7 +504,6 @@ CONFIG_ENV_SROM_BANK >> > >CONFIG_ENV_TOTAL_SIZE >> > >CONFIG_ENV_UBIFS_OPTION >> > >CONFIG_ENV_UBI_MTD >> > > -CONFIG_ENV_UBI_VOLUME_REDUND >> > >CONFIG_ENV_VERSION >> > >CONFIG_EP9302 >> > >CONFIG_EP9307 >> > > >> > >> > Please move from the config files: >> > >> > ./include/configs/omap3_igep00x0.h >> > ./include/configs/gardena-smart-gateway-at91sam.h >> > ./include/configs/am335x_igep003x.h >> > >> > also the symbols to the defconfig files, thanks. >> >> I have a question: to convert these, I need to make available the >> additional ENV_ configs to OMAP2PLUS and AT91: >> >> diff --git a/env/Kconfig b/env/Kconfig >> index 44c47220c2..1250656d74 100644 >> --- a/env/Kconfig >> +++ b/env/Kconfig >> @@ -470,7 +470,7 @@ config ENV_EXT4_FILE >>It's a string of the EXT4 file name. This file use to store the >>environment (explicit path to the file) >> -if ARCH_ROCKCHIP || ARCH_SUNXI || ARCH_ZYNQ || ARCH_ZYNQMP || ARCH_VERSAL >> || ARC >> +if ARCH_ROCKCHIP || ARCH_SUNXI || ARCH_ZYNQ || ARCH_ZYNQMP || ARCH_VERSAL >> || ARC || ARCH_OMAP2PLUS || ARCH_AT91 >> >> However, this "if" region contains a few other, non UBI settings such >> as ENV_SIZE, which would become visible to a large number of OMAP2PLUS >> and AT91 boards, which still define this in the headers. > >Huch? > >If so, than they are not converted (yet) ... :-( > >> I'm a bit hesitant to touch all of these. What is the suggested way to >> solve this? > >I think, they should be converted too ... OK. >Sorry for the additional work ... I can understand your hesitantion >to do such a conversion... No problem, I just wasn't sure how handle this. I'm now trying to run moveconfig as follows $ grep -l "ARCH_OMAP2PLUS\|ARCH_AT91" configs/* | ./tools/moveconfig.py -s ENV_OFFSET ENV_SIZE ENV_SECT_SIZE -d - but the command hangs infinitely. If I run it for all boards without "-d", it starts processing and gets through about 50 configs and then hangs too. Any idea what may be the cause? I'm using python 2.7.16rc1. >Hmm... I used some year(s) ago tbot for checking, if a config change >did not introduced diffs in created binaries for all boards [1] ... > >In principal I did: > >- build all boards with "SOURCE_DATE_EPOCH=0" > and created a md5sum from each binary >- apply patch(es) >- build again, create md5sums and check if mdsum is the same > >Unfortunately not converted this testcase to the new tbot ... > >But may it is possible to convert this into a script ? Thank you, I'll take a look at it one I get that far. Best regards Markus -- Markus Klotzbuecher Freelancer Embedded, Distributed & Real-time Systems Am See 28, 78465 Konstanz, Germany ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/1] configs: bcm968580 disable CONFIG_CMD_BOOTEFI_SELFTEST
Configuration option CONFIG_CMD_BOOTEFI_SELFTEST is useful for the development of the UEFI sub-system. For production it is not needed. Remove CONFIG_CMD_BOOTEFI_SELFTEST from bcm968580xref_ram_defconfig. Suggested-by: Tom Rini Signed-off-by: Heinrich Schuchardt --- configs/bcm968580xref_ram_defconfig | 1 - 1 file changed, 1 deletion(-) diff --git a/configs/bcm968580xref_ram_defconfig b/configs/bcm968580xref_ram_defconfig index d6509e30bc..d331e4e807 100644 --- a/configs/bcm968580xref_ram_defconfig +++ b/configs/bcm968580xref_ram_defconfig @@ -14,7 +14,6 @@ CONFIG_IMAGE_FORMAT_LEGACY=y CONFIG_SUPPORT_RAW_INITRD=y CONFIG_DISPLAY_BOARDINFO_LATE=y CONFIG_HUSH_PARSER=y -CONFIG_CMD_BOOTEFI_SELFTEST=y CONFIG_CMD_GPIO=y CONFIG_CMD_MTD=y CONFIG_CMD_NAND=y -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 45/50] Revert "pci: Scale MAX_PCI_REGIONS based on CONFIG_NR_DRAM_BANKS"
On Tue, May 07, 2019 at 09:04:16PM -0600, Simon Glass wrote: > Hi Bin, > > On Tue, 7 May 2019 at 03:28, Bin Meng wrote: > > > > Hi Simon, Thierry, > > > > On Fri, May 3, 2019 at 12:22 AM Simon Glass wrote: > > > > > > Hi Thierry, > > > > > > On Thu, 2 May 2019 at 03:25, Thierry Reding wrote: > > > > > > > > On Thu, May 02, 2019 at 12:09:49AM +0800, Bin Meng wrote: > > > > > +Thierry > > > > > > > > > > On Fri, Apr 26, 2019 at 12:00 PM Simon Glass > > > > > wrote: > > > > > > > > > > > > This reverts commit aec4298ccb337106fd0115b91d846a022fdf301d. > > > > > > > > > > > > Unfortunately this has a dramatic impact on the pre-relocation > > > > > > memory > > > > > > used on x86 platforms (increasing it by 2KB) since it increases the > > > > > > overhead for each PCI device from 220 bytes to 412 bytes. > > > > > > > > > > > > The offending line is in UCLASS_DRIVER(pci): > > > > > > > > > > > > .per_device_auto_alloc_size = sizeof(struct pci_controller), > > > > > > > > > > > > This means that all PCI devices have the controller struct > > > > > > associated > > > > > > with them. The solution is to move the regions[] member out of the > > > > > > array, > > > > > > makes its size dynamic, or split UCLASS_PCI into controllers and > > > > > > non-controllers, as the comment suggests. > > > > > > > > > > > > For now, revert the commit to get things running again. > > > > > > > > > > > > Signed-off-by: Simon Glass > > > > > > --- > > > > > > > > > > > > Changes in v2: None > > > > > > > > > > > > include/pci.h | 6 +- > > > > > > 1 file changed, 1 insertion(+), 5 deletions(-) > > > > > > > > > > > > > > > > Reviewed-by: Bin Meng > > > > > > > > Ugh... so we're trading one regression for another? Can we not live with > > > > the 2 KiB increase on x86 until this has been properly fixed? Currently > > > > this will cause Jetson TX2 to crash if it starts using PCI. > > > > > > Unfortunately this breaks several boards since we are out of memory. > > > > > > I think this needs a better solution to reduce the memory usage down > > > to sensible levels. This is something I should have considered when > > > implementing the PCI uclass, but unfortunately I did not. > > > > > > > Could you please suggest whether I should apply this revert patch for now? > > I suggest a temporary revert since this breaks some x86 boards. > > I think the real fix is to reduce the memory used by PCI devices. > Thierry, do you have time to look at this? Not right away. I may get around to this within a couple of weeks maybe. Thierry signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/1] configs: bcm963158 disable CONFIG_CMD_BOOTEFI_SELFTEST
Configuration option CONFIG_CMD_BOOTEFI_SELFTEST is useful for the development of the UEFI sub-system. For production it is not needed. Remove CONFIG_CMD_BOOTEFI_SELFTEST from bcm963158_ram_defconfig. Suggested-by: Tom Rini Signed-off-by: Heinrich Schuchardt --- configs/bcm963158_ram_defconfig | 1 - 1 file changed, 1 deletion(-) diff --git a/configs/bcm963158_ram_defconfig b/configs/bcm963158_ram_defconfig index 321bc22699..dfd69069c7 100644 --- a/configs/bcm963158_ram_defconfig +++ b/configs/bcm963158_ram_defconfig @@ -16,7 +16,6 @@ CONFIG_IMAGE_FORMAT_LEGACY=y CONFIG_SUPPORT_RAW_INITRD=y CONFIG_DISPLAY_BOARDINFO_LATE=y CONFIG_HUSH_PARSER=y -CONFIG_CMD_BOOTEFI_SELFTEST=y # CONFIG_CMD_LZMADEC is not set # CONFIG_CMD_UNZIP is not set # CONFIG_CMD_FLASH is not set -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/7] warp7: include: configs: Differentiate bootscript address from loadaddr
On 08/05/2019 20:33, Pierre-Jean Texier wrote:
Hi Bryan,
Le 08/05/2019 à 20:14, Bryan O'Donoghue a écrit :
Reusing the loadaddr to load the boot script breaks some of the logic we
want to have around the bootscript/FIT load addresses. Making a dedicated
bootscript address allows us to differentiate the bootscript load address
from the Linux Kernel or OPTEE load address, thus ensuring that no matter
what the load sequence the bootscript and Kernel/OPTEE binary load
addresses do not conflict.
Signed-off-by: Bryan O'Donoghue
---
include/configs/warp7.h | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/include/configs/warp7.h b/include/configs/warp7.h
index 95955fd626..0c63050833 100644
--- a/include/configs/warp7.h
+++ b/include/configs/warp7.h
@@ -50,6 +50,7 @@
"script=boot.scr\0" \
"bootscr_fitimage_name=bootscr\0" \
"script_signed=boot.scr.imx-signed\0" \
+ "bootscriptaddr=0x8320\0" \
"image=zImage\0" \
"console=ttymxc0\0" \
"ethact=usb_ether\0" \
@@ -70,16 +71,16 @@
"warp7_auth_or_fail=hab_auth_img_or_fail ${hab_ivt_addr}
${filesize} 0;\0" \
"do_bootscript_hab=" \
"if test ${hab_enabled} -eq 1; then " \
- "setexpr hab_ivt_addr ${loadaddr} - ${ivt_offset}; " \
+ "setexpr hab_ivt_addr ${bootscriptaddr} - ${ivt_offset}; " \
"setenv script ${script_signed}; " \
"load mmc ${mmcdev}:${mmcpart} ${hab_ivt_addr}
${script}; " \
"run warp7_auth_or_fail; " \
"run bootscript; "\
"fi;\0" \
"loadbootscript=" \
- "load mmc ${mmcdev}:${mmcpart} ${loadaddr} ${script};\0" \
+ "load mmc ${mmcdev}:${mmcpart} ${bootscriptaddr} ${script};\0" \
"bootscript=echo Running bootscript from mmc ...; " \
- "source\0" \
+ BOOT_SCR_STRING \
"loadimage=load mmc ${mmcdev}:${mmcpart} ${loadaddr} ${image}\0" \
"loadfdt=load mmc ${mmcdev}:${mmcpart} ${fdt_addr} ${fdt_file}\0" \
"mmcboot=echo Booting from mmc ...; " \
Instead of implementing a new variable (bootscriptaddr), I think (IMHO)
it's time to migrate
to distroboot for the WaRP7 (like pico imx7 for instance >
In fact, in this specific case, this allows to use the common
scriptaddr[1] variable.
FYI, this is a task I am currently working on [2] (work in progress).
Maybe we could integrate this migration into this series ?
Sure.
Let me give it a test later tonight/tomorrow
---
bod
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] test/py: don't use mmc_rd config for other mmc tests
On 5/1/19 4:51 PM, Stephen Warren wrote: On 4/30/19 10:27 AM, Marek Vasut wrote: On 4/30/19 5:29 PM, Stephen Warren wrote: On 4/16/19 4:04 PM, Stephen Warren wrote: From: Stephen Warren Fix test_mmc_dev(), test_mmc_rescan(), test_mmc_info() not to use the same configuration data that test_mmc_rd() does. Doing so causes the following issues: * The new code uncondtionally expects certain keys to exist in the configuration data. These keys do not exist in existing configuration data since they were not previously required, and there was no notification re: a requirement to add these new keys. This causes test failures due to thrown exceptions when accessing the non-existent keys. * The new tests logically operate on different objects. test_mmc_rd() operates on ranges of sectors on an MMC device (which may be the entire set of sectors of a device, or a part of a device), whereas all the new tests operate solely on entire devices. These are separate things, and it's entirely likely that the user will wish to runs the two types of tests on different sets of data; see the example configuration data that this commit adds. Ideally, the new tests would have been added to a separate Python file, since they aren' closely related to the existing tests. FIXME: Marek, can you please replace the "???" in this patch with some reasonable looking data? Thanks. Tom, Marek, any chance of applying this? Right now, every mainline branch is failing 5 tests on every push, which wastes my time having to go through all the logs to manually check that the failures aren't anything new/unknown. Thanks. I'm still overloaded, and didn't have time to look into this. But I'm really not fond of the duplication here -- now we have two big tables describing very much the same thing, which SD/MMC to test . There's no redundancy; the two different tests are semantically entirely different and don't share any configuration. See the patch description above for the full details. Tom, could you please apply this patch to fix the test failures. Thanks. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] U-Boot PXA support
On Thu, May 09, 2019 at 05:12:25PM +0200, Marek Vasut wrote:
> On 5/9/19 5:03 PM, Vasily Khoruzhick wrote:
> > On Thu, May 9, 2019 at 7:56 AM Marek Vasut wrote:
> >>
> >> On 5/9/19 4:02 PM, Tom Rini wrote:
> >>> On Mon, May 06, 2019 at 09:26:04AM -0400, Tom Rini wrote:
> >>>
> Hey folks,
>
> I'm attempting, again, to see what we need to do in order to use gcc-8.x
> for U-Boot and ran into, again:
> https://patchwork.ozlabs.org/patch/920329/ which in short is that when
> using -mcpu=xscale gcc-8.x throws an odd error:
> cc1: error: switch -mcpu=xscale conflicts with -march=armv5te switch
> [-Werror]
>
> Now note, U-Boot isn't passing -march= at all, just -mcpu=xscale which
> suggests perhaps something broke in upstream gcc. Looking at the
> kernel, it's not used -mcpu=xscale ever, just -mtune=xscale but that
> leads to different failures (seen here with gcc-7.3):
> CC drivers/usb/gadget/pxa25x_udc.o
> {standard input}: Assembler messages:
> {standard input}:779: Error: selected processor does not support `pld
> [lr]' in ARM mode
> {standard input}:1201: Error: selected processor does not support `pld
> [r7]' in ARM mode
> {standard input}:2519: Error: selected processor does not support `pld
> [r3]' in ARM mode
> {standard input}:2796: Error: selected processor does not support `pld
> [r3]' in ARM mode
>
> So, what should we do about this? Is there still active interest in
> supporting the PXA platforms? Thanks folks!
> >>>
> >>> ping? Thanks!
> >>
> >> Maybe we should just remove it.
> >
> > +1, almost no one uses it nowadays.
>
> Well, there are still a few users of Zipit Z2 and there was some
> interest in Sharp Zaurus, but ...
I don't see anything for Zipit Z2 that's been updated more recently than
about 5 years ago, sadly. Vasily, do you want to post a patch to drop
that board since it's yours? Thanks!
--
Tom
signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] U-Boot PXA support
On 5/9/19 5:03 PM, Vasily Khoruzhick wrote:
> On Thu, May 9, 2019 at 7:56 AM Marek Vasut wrote:
>>
>> On 5/9/19 4:02 PM, Tom Rini wrote:
>>> On Mon, May 06, 2019 at 09:26:04AM -0400, Tom Rini wrote:
>>>
Hey folks,
I'm attempting, again, to see what we need to do in order to use gcc-8.x
for U-Boot and ran into, again:
https://patchwork.ozlabs.org/patch/920329/ which in short is that when
using -mcpu=xscale gcc-8.x throws an odd error:
cc1: error: switch -mcpu=xscale conflicts with -march=armv5te switch
[-Werror]
Now note, U-Boot isn't passing -march= at all, just -mcpu=xscale which
suggests perhaps something broke in upstream gcc. Looking at the
kernel, it's not used -mcpu=xscale ever, just -mtune=xscale but that
leads to different failures (seen here with gcc-7.3):
CC drivers/usb/gadget/pxa25x_udc.o
{standard input}: Assembler messages:
{standard input}:779: Error: selected processor does not support `pld
[lr]' in ARM mode
{standard input}:1201: Error: selected processor does not support `pld
[r7]' in ARM mode
{standard input}:2519: Error: selected processor does not support `pld
[r3]' in ARM mode
{standard input}:2796: Error: selected processor does not support `pld
[r3]' in ARM mode
So, what should we do about this? Is there still active interest in
supporting the PXA platforms? Thanks folks!
>>>
>>> ping? Thanks!
>>
>> Maybe we should just remove it.
>
> +1, almost no one uses it nowadays.
Well, there are still a few users of Zipit Z2 and there was some
interest in Sharp Zaurus, but ...
--
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] U-Boot PXA support
On Thu, May 9, 2019 at 7:56 AM Marek Vasut wrote:
>
> On 5/9/19 4:02 PM, Tom Rini wrote:
> > On Mon, May 06, 2019 at 09:26:04AM -0400, Tom Rini wrote:
> >
> >> Hey folks,
> >>
> >> I'm attempting, again, to see what we need to do in order to use gcc-8.x
> >> for U-Boot and ran into, again:
> >> https://patchwork.ozlabs.org/patch/920329/ which in short is that when
> >> using -mcpu=xscale gcc-8.x throws an odd error:
> >> cc1: error: switch -mcpu=xscale conflicts with -march=armv5te switch
> >> [-Werror]
> >>
> >> Now note, U-Boot isn't passing -march= at all, just -mcpu=xscale which
> >> suggests perhaps something broke in upstream gcc. Looking at the
> >> kernel, it's not used -mcpu=xscale ever, just -mtune=xscale but that
> >> leads to different failures (seen here with gcc-7.3):
> >> CC drivers/usb/gadget/pxa25x_udc.o
> >> {standard input}: Assembler messages:
> >> {standard input}:779: Error: selected processor does not support `pld
> >> [lr]' in ARM mode
> >> {standard input}:1201: Error: selected processor does not support `pld
> >> [r7]' in ARM mode
> >> {standard input}:2519: Error: selected processor does not support `pld
> >> [r3]' in ARM mode
> >> {standard input}:2796: Error: selected processor does not support `pld
> >> [r3]' in ARM mode
> >>
> >> So, what should we do about this? Is there still active interest in
> >> supporting the PXA platforms? Thanks folks!
> >
> > ping? Thanks!
>
> Maybe we should just remove it.
+1, almost no one uses it nowadays.
> --
> Best regards,
> Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] U-Boot PXA support
On 5/9/19 4:02 PM, Tom Rini wrote:
> On Mon, May 06, 2019 at 09:26:04AM -0400, Tom Rini wrote:
>
>> Hey folks,
>>
>> I'm attempting, again, to see what we need to do in order to use gcc-8.x
>> for U-Boot and ran into, again:
>> https://patchwork.ozlabs.org/patch/920329/ which in short is that when
>> using -mcpu=xscale gcc-8.x throws an odd error:
>> cc1: error: switch -mcpu=xscale conflicts with -march=armv5te switch
>> [-Werror]
>>
>> Now note, U-Boot isn't passing -march= at all, just -mcpu=xscale which
>> suggests perhaps something broke in upstream gcc. Looking at the
>> kernel, it's not used -mcpu=xscale ever, just -mtune=xscale but that
>> leads to different failures (seen here with gcc-7.3):
>> CC drivers/usb/gadget/pxa25x_udc.o
>> {standard input}: Assembler messages:
>> {standard input}:779: Error: selected processor does not support `pld [lr]'
>> in ARM mode
>> {standard input}:1201: Error: selected processor does not support `pld [r7]'
>> in ARM mode
>> {standard input}:2519: Error: selected processor does not support `pld [r3]'
>> in ARM mode
>> {standard input}:2796: Error: selected processor does not support `pld [r3]'
>> in ARM mode
>>
>> So, what should we do about this? Is there still active interest in
>> supporting the PXA platforms? Thanks folks!
>
> ping? Thanks!
Maybe we should just remove it.
--
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Pull request for UEFI sub-system for v2019.07-rc2 (2)
On Thu, May 09, 2019 at 12:03:38AM +0200, Heinrich Schuchardt wrote:
> On 5/8/19 7:50 PM, Tom Rini wrote:
> >On Wed, May 08, 2019 at 07:57:57AM +0200, Heinrich Schuchardt wrote:
> >
> >>The following changes since commit
> >>44237e272f1eac3b026709e76333a07b2d3a3523:
> >>
> >>Merge branch 'master' of git://git.denx.de/u-boot-sh (2019-05-06
> >>07:19:31 -0400)
> >>
> >>are available in the Git repository at:
> >>
> >>git://git.denx.de/u-boot-efi.git tags/efi-2019-07-rc2-2
> >>
> >>for you to fetch changes up to
> >>b015ab57bf558daa1c768995a7a7f1df2d40191e:
> >>
> >>efi_loader: signature of ExitBootServices() (2019-05-07 21:10:04
> >>+0200)
> >>
> >>Travis CI results are here:
> >>https://travis-ci.org/xypron2/u-boot/builds/529448555
> >>
> >>Primary key fingerprint: 6DC4 F9C7 1F29 A6FA 06B7 6D33 C481 DBBC
> >>2C05 1AC4
> >>
> >
> >Note that you may want to run ./scripts/checkpatch.pl --git
> >origin/master.. or similar as: WARNING: 'follwing' may be misspelled
> >- perhaps 'following'?
> >
> >which I left alone rather than mess up the tag.
>
> Sorry I missed that one. Typically I run checkpatch.pl.
>
> >
> >Applied to u-boot/master, thanks!
> >
> >And all of that said, looking over my before/after builds I see a lot
> >of size growth, everywhere, due to EFI changes. I assume this is due
> >to increasing overall functionality and support, which is good. But
> >is there perhaps some way we can split things into a minimal "we
> >have enough to support loading ${OS LOADER}" and then "we are aiming
> >for large parts of spec compliance" ? Some days I start to wonder
> >if "EFI_LOADER on by default" was a bad idea.
> >
>
> The following switches allow to reduce the size of the UEFI subsystem:
>
> CONFIG_CMD_BOOTEFI_HELLO, default N
> CONFIG_CMD_BOOTEFI_SELFTEST, default N except QEMU
Note there's 2 non-QEMU platforms enabling it, can you please add a
patch turning it off and cc'ing the maintainer as they probably didn't
really mean to have that on? It's also not on for riscv QEMU nor
sandbox but should be?
> CONFIG_EFI_UNICODE_CAPITALIZATION, default Y
> CONFIG_EFI_LOADER_HII
> (The Makefile does not consider it yet correctly, patch submitted.)
> CONFIG_CMD_EFIDEBUG, default N
> CONFIG_CMD_NVEDIT_EFI
Adding in:
commit 7494b7764508332e37a3375fa0b6c328bc34637f
Author: Tom Rini
Date: Thu May 9 10:06:40 2019 -0400
LOCAL: Disable some EFI stuff by default
Signed-off-by: Tom Rini
diff --git a/cmd/Kconfig b/cmd/Kconfig
index 4e11e0f404c8..4ebaf2f5bcb9 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -238,7 +238,6 @@ config CMD_BOOTEFI
config CMD_BOOTEFI_HELLO_COMPILE
bool "Compile a standard EFI hello world binary for testing"
depends on CMD_BOOTEFI && !CPU_V7M && !SANDBOX
- default y
help
This compiles a standard EFI hello world application with U-Boot so
that it can be used with the test/py testing framework. This is useful
@@ -434,7 +433,6 @@ config CMD_ENV_FLAGS
config CMD_NVEDIT_EFI
bool "env [set|print] -e - set/print UEFI variables"
depends on EFI_LOADER
- default y
imply HEXDUMP
help
UEFI variables are encoded as some form of U-Boot variables.
diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
index 50b050159c37..bd8fb9be00bc 100644
--- a/lib/efi_loader/Kconfig
+++ b/lib/efi_loader/Kconfig
@@ -19,7 +19,6 @@ config EFI_LOADER
config EFI_UNICODE_CAPITALIZATION
bool "Support Unicode capitalization"
depends on EFI_LOADER
- default y
help
Select this option to enable correct handling of the capitalization of
Unicode codepoints in the range 0x-0x. If this option is not
@@ -48,7 +47,6 @@ config EFI_LOADER_BOUNCE_BUFFER
config EFI_LOADER_HII
bool "Expose HII protocols to EFI applications"
depends on EFI_LOADER
- default y
help
The Human Interface Infrastructure is a complicated framework that
allows UEFI applications to draw fancy menus and hook strings using
And note that with the bugfix to the Makefile for EFI_LOADER_HII added,
there's either more to be done, or it was already being discarded at
link time as applying that patch on top of this didn't result in any
size savings. Doing the above saves about 10kb. Which helps, but with
the numbers I mentioned earlier still puts us at about 40kb which Alex
was hoping it should be closer to 20kb. Is there more we can do here?
Thanks!
--
Tom
signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] armv8: ls1046afrwy: Add support for LS1046AFRWY platform
LS1046AFRWY board supports LS1046A family SoCs. This patch add base support for this board. Board support's 4GB ddr memory, i2c, micro-click module,microSD card, serial console,qspi nor flash,ifc nand flash,qsgmii network interface, usb 3.0 and serdes interface to support two x1gen3 pcie interface. Signed-off-by: Camelia Groza Signed-off-by: Madalin Bucur Signed-off-by: Pankit Garg Signed-off-by: Pramod Kumar Signed-off-by: Rajesh Bhagat Signed-off-by: Vabhav Sharma --- arch/arm/Kconfig | 17 ++ arch/arm/cpu/armv8/Kconfig | 1 + arch/arm/cpu/armv8/fsl-layerscape/ls1046a_serdes.c | 2 + arch/arm/dts/Makefile | 1 + arch/arm/dts/fsl-ls1046a-frwy.dts | 34 +++ board/freescale/ls1046afrwy/Kconfig| 17 ++ board/freescale/ls1046afrwy/MAINTAINERS| 17 ++ board/freescale/ls1046afrwy/Makefile | 9 + board/freescale/ls1046afrwy/README | 76 +++ board/freescale/ls1046afrwy/ddr.c | 24 ++ board/freescale/ls1046afrwy/eth.c | 114 ++ board/freescale/ls1046afrwy/ls1046afrwy.c | 249 + board/freescale/ls1046afrwy/ls1046afrwy_pbi.cfg| 22 ++ .../freescale/ls1046afrwy/ls1046afrwy_qspi_pbi.cfg | 26 +++ .../freescale/ls1046afrwy/ls1046afrwy_rcw_qspi.cfg | 7 + board/freescale/ls1046afrwy/ls1046afrwy_rcw_sd.cfg | 7 + configs/ls1046afrwy_tfa_defconfig | 58 + include/configs/ls1046a_common.h | 13 +- include/configs/ls1046afrwy.h | 204 + include/fm_eth.h | 12 + 20 files changed, 908 insertions(+), 2 deletions(-) create mode 100644 arch/arm/dts/fsl-ls1046a-frwy.dts create mode 100644 board/freescale/ls1046afrwy/Kconfig create mode 100644 board/freescale/ls1046afrwy/MAINTAINERS create mode 100644 board/freescale/ls1046afrwy/Makefile create mode 100644 board/freescale/ls1046afrwy/README create mode 100644 board/freescale/ls1046afrwy/ddr.c create mode 100644 board/freescale/ls1046afrwy/eth.c create mode 100644 board/freescale/ls1046afrwy/ls1046afrwy.c create mode 100644 board/freescale/ls1046afrwy/ls1046afrwy_pbi.cfg create mode 100644 board/freescale/ls1046afrwy/ls1046afrwy_qspi_pbi.cfg create mode 100644 board/freescale/ls1046afrwy/ls1046afrwy_rcw_qspi.cfg create mode 100644 board/freescale/ls1046afrwy/ls1046afrwy_rcw_sd.cfg create mode 100644 configs/ls1046afrwy_tfa_defconfig create mode 100644 include/configs/ls1046afrwy.h diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index f91c590..15699a2 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -1329,6 +1329,22 @@ config TARGET_LS1046ARDB development platform that supports the QorIQ LS1046A Layerscape Architecture processor. +config TARGET_LS1046AFRWY + bool "Support ls1046afrwy" + select ARCH_LS1046A + select ARM64 + select ARMV8_MULTIENTRY + select BOARD_EARLY_INIT_F + select BOARD_LATE_INIT + select DM_SPI_FLASH if DM_SPI + select POWER_MC34VR500 + select SUPPORT_SPL + imply SCSI + help + Support for Freescale LS1046AFRWY platform. + The LS1046A Freeway Board (FRWY) is a high-performance + development platform that supports the QorIQ LS1046A + Layerscape Architecture processor. config TARGET_H2200 bool "Support h2200" select CPU_PXA @@ -1617,6 +1633,7 @@ source "board/freescale/ls1021aiot/Kconfig" source "board/freescale/ls1046aqds/Kconfig" source "board/freescale/ls1043ardb/Kconfig" source "board/freescale/ls1046ardb/Kconfig" +source "board/freescale/ls1046afrwy/Kconfig" source "board/freescale/ls1012aqds/Kconfig" source "board/freescale/ls1012ardb/Kconfig" source "board/freescale/ls1012afrdm/Kconfig" diff --git a/arch/arm/cpu/armv8/Kconfig b/arch/arm/cpu/armv8/Kconfig index 7405c3a..ed31df1 100644 --- a/arch/arm/cpu/armv8/Kconfig +++ b/arch/arm/cpu/armv8/Kconfig @@ -106,6 +106,7 @@ config PSCI_RESET !TARGET_LS1012AFRWY && \ !TARGET_LS1043ARDB && !TARGET_LS1043AQDS && \ !TARGET_LS1046ARDB && !TARGET_LS1046AQDS && \ + !TARGET_LS1046AFRWY && \ !TARGET_LS2081ARDB && !TARGET_LX2160ARDB && \ !TARGET_LX2160AQDS && \ !ARCH_UNIPHIER && !TARGET_S32V234EVB diff --git a/arch/arm/cpu/armv8/fsl-layerscape/ls1046a_serdes.c b/arch/arm/cpu/armv8/fsl-layerscape/ls1046a_serdes.c index f8310f2..caa4862 100644 --- a/arch/arm/cpu/armv8/fsl-layerscape/ls1046a_serdes.c +++ b/arch/arm/cpu/armv8/fsl-layerscape/ls1046a_serdes.c @@ -1,6 +1,7 @@ // SPDX-License-Identifier: GPL-2.0+ /* * Copyright 2016 Freescale Semiconductor, Inc. + * Copyright 2019 NXP */ #include @@ -33,6 +34,7 @@ static struct serdes_config
Re: [U-Boot] [PATCH 8/8] spi: Kconfig: Mark LPC32XX_SSP has BROKEN
Acked-by: Sylvain Lemieux On Tue, Apr 30, 2019 at 4:48 PM Vladimir Zapolskiy wrote: > > Hi Jagan, > > On 04/28/2019 11:48 PM, Jagan Teki wrote: > > Mark LPC32XX_SSP has BROKEN, this so the resulting build shows > > warning for broken configuration enabled and associated code > > will remove in v2019.07 release. > > > > Cc: Vladimir Zapolskiy > > Cc: Albert ARIBAUD > > Signed-off-by: Jagan Teki > > --- > > drivers/spi/Kconfig | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig > > index 55f0d6cf2b..5fbe17bb20 100644 > > --- a/drivers/spi/Kconfig > > +++ b/drivers/spi/Kconfig > > @@ -369,6 +369,7 @@ config KIRKWOOD_SPI > > > > config LPC32XX_SSP > > bool "LPC32XX SPI Driver" > > + select BROKEN > > help > > Enable support for SPI on LPC32xx > > > > > > Acked-by: Vladimir Zapolskiy > > Thank you for the change, as we've discussed earlier I won't have > objections against the driver removal when time is up. > > Thus you can locally prepare a removal change in advance, the one > which you've sent earlier needs a minor update, please also remove > lpc32xx_ssp_init() function and its usage in the board files. > > -- > Best wishes, > Vladimir ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] U-Boot PXA support
On Mon, May 06, 2019 at 09:26:04AM -0400, Tom Rini wrote:
> Hey folks,
>
> I'm attempting, again, to see what we need to do in order to use gcc-8.x
> for U-Boot and ran into, again:
> https://patchwork.ozlabs.org/patch/920329/ which in short is that when
> using -mcpu=xscale gcc-8.x throws an odd error:
> cc1: error: switch -mcpu=xscale conflicts with -march=armv5te switch [-Werror]
>
> Now note, U-Boot isn't passing -march= at all, just -mcpu=xscale which
> suggests perhaps something broke in upstream gcc. Looking at the
> kernel, it's not used -mcpu=xscale ever, just -mtune=xscale but that
> leads to different failures (seen here with gcc-7.3):
> CC drivers/usb/gadget/pxa25x_udc.o
> {standard input}: Assembler messages:
> {standard input}:779: Error: selected processor does not support `pld [lr]'
> in ARM mode
> {standard input}:1201: Error: selected processor does not support `pld [r7]'
> in ARM mode
> {standard input}:2519: Error: selected processor does not support `pld [r3]'
> in ARM mode
> {standard input}:2796: Error: selected processor does not support `pld [r3]'
> in ARM mode
>
> So, what should we do about this? Is there still active interest in
> supporting the PXA platforms? Thanks folks!
ping? Thanks!
--
Tom
signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RESEND PATCH v7 00/11] rockchip: Add new rk3399 boards
Hi Philipp, On Thu, May 9, 2019 at 6:10 PM Philipp Tomsich wrote: > > Jagan, > > On 09.05.2019, at 14:36, Jagan Teki wrote: > > On Thu, May 9, 2019 at 6:01 PM Paul Kocialkowski > wrote: > > > Hi, > > On Thu, 2019-05-09 at 16:15 +0530, Jagan Teki wrote: > > Hi Paul, > > On Thu, May 9, 2019 at 12:38 PM Paul Kocialkowski > wrote: > > Hi, > > On Wed, 2019-05-08 at 11:11 +0530, Jagan Teki wrote: > > (Sorry for the noice, I have missed to send two patches from v7) > > This is v7 resend patchset for New rk3399 boards support wrt previous > version[1] > > Unfortunately initial version of creating rk3399-u-boot.dtsi and > orangepi rk3399 changes are merged, so this is rework on top of > u-boot-rockchip/master. > > Overall this series add support below rk3399 boards > - NanoPI M4 > - NanoPC T4 > - NanoPI NEO4 > - Orangepi RK3399 > - Rock PI 4 > - Rockpro64 > > All the respective dts(i) files are synced from Linux 5.1-rc2 and few > dts(i) from linux-next. > > SoC u-boot specific dtsi rk3399-u-boot.dtsi changes are part of another > series [3]. > > Out of all above boards Rockpor64, Rock-PI and Nanopi NEO4 would support > booting via Rockchip miniloader as of now. > > > Could you send these two boards in a separate series so that we avoid > merging them for now (because SPL support is broken) and then re- > iterate the series later with the DDR bringup? Or maybe find a way to > disable SPL support, but in any case, it's not ok to merge a board with > SPL enabled and broken. > > > I have explained the details about this concern on v2 [1], thought you > would comeback on the same line instead here. > > > Yes, you have already explained the issue, but I don't think it's > enough a justification to merge broken SPL support. If it was only > partial or limited, it would be fine, but here it's just broken. > > Anyway, making SPL as an optional is not an idea to go with Mainline > as we make many decisions with regards to make SPL is mandatory. > > > Yes I think making SPL mandatory is a good idea, so that's why I'm > suggesting that we don't merge the boards until they have SPL support. > > Since the DDR is show stopper here (and it would really need a good > amount of time, since it effect the other boards), I can go with TPL > enabled boot-chain where ddr bin, SPL and U-Boot proper can be part of > booting stages. This way we can avoid skipping SPL usage, and many > config changes to make SPL optional. > > > Honestly I don't really see the point of merging these boards at all if > they don't have SPL support. People who really want to use them with > the rockchip blob can cherry-pick the patches from the list in the > meantime. > > It also creates incentive for people to free the DDR init, since that > becomes a condition to have the board upstream. > > What do you think? > > > I don't know whether you get my point or not? these boards are not > merged yet. What I'm saying is we are going to support them with > TPL-enabled, that was SPL can make use of these boards which still a > valid boot-chain. moreover this way can avoid touching core files and > no specific change require while supporting ddr dtsi. > > > On some boards, there will be no TPL and only a SPL stage that will > initialise DRAM (as the move to having TPL on the RK3399 is optional). True, my suggestion here the same. SPL is mandatory. > > I agree with Paul that the DRAM init should be part of U-Boot whenever > we add new boards and make an open DRAM init a prerequisite. True, I agree this point. Since we have an option of having DRAM init at TPL I'm proposing this boot-chain (along with commitment on dram work). ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RESEND PATCH v7 00/11] rockchip: Add new rk3399 boards
Hi, On Thu, 2019-05-09 at 14:40 +0200, Philipp Tomsich wrote: > Jagan, > > > On 09.05.2019, at 14:36, Jagan Teki wrote: > > > > On Thu, May 9, 2019 at 6:01 PM Paul Kocialkowski > > wrote: > > > Hi, > > > > > > On Thu, 2019-05-09 at 16:15 +0530, Jagan Teki wrote: > > > > Hi Paul, > > > > > > > > On Thu, May 9, 2019 at 12:38 PM Paul Kocialkowski > > > > wrote: > > > > > Hi, > > > > > > > > > > On Wed, 2019-05-08 at 11:11 +0530, Jagan Teki wrote: > > > > > > (Sorry for the noice, I have missed to send two patches from v7) > > > > > > > > > > > > This is v7 resend patchset for New rk3399 boards support wrt > > > > > > previous > > > > > > version[1] > > > > > > > > > > > > Unfortunately initial version of creating rk3399-u-boot.dtsi and > > > > > > orangepi rk3399 changes are merged, so this is rework on top of > > > > > > u-boot-rockchip/master. > > > > > > > > > > > > Overall this series add support below rk3399 boards > > > > > > - NanoPI M4 > > > > > > - NanoPC T4 > > > > > > - NanoPI NEO4 > > > > > > - Orangepi RK3399 > > > > > > - Rock PI 4 > > > > > > - Rockpro64 > > > > > > > > > > > > All the respective dts(i) files are synced from Linux 5.1-rc2 and > > > > > > few > > > > > > dts(i) from linux-next. > > > > > > > > > > > > SoC u-boot specific dtsi rk3399-u-boot.dtsi changes are part of > > > > > > another > > > > > > series [3]. > > > > > > > > > > > > Out of all above boards Rockpor64, Rock-PI and Nanopi NEO4 would > > > > > > support > > > > > > booting via Rockchip miniloader as of now. > > > > > > > > > > Could you send these two boards in a separate series so that we avoid > > > > > merging them for now (because SPL support is broken) and then re- > > > > > iterate the series later with the DDR bringup? Or maybe find a way to > > > > > disable SPL support, but in any case, it's not ok to merge a board > > > > > with > > > > > SPL enabled and broken. > > > > > > > > I have explained the details about this concern on v2 [1], thought you > > > > would comeback on the same line instead here. > > > > > > Yes, you have already explained the issue, but I don't think it's > > > enough a justification to merge broken SPL support. If it was only > > > partial or limited, it would be fine, but here it's just broken. > > > > > > > Anyway, making SPL as an optional is not an idea to go with Mainline > > > > as we make many decisions with regards to make SPL is mandatory. > > > > > > Yes I think making SPL mandatory is a good idea, so that's why I'm > > > suggesting that we don't merge the boards until they have SPL support. > > > > > > > Since the DDR is show stopper here (and it would really need a good > > > > amount of time, since it effect the other boards), I can go with TPL > > > > enabled boot-chain where ddr bin, SPL and U-Boot proper can be part of > > > > booting stages. This way we can avoid skipping SPL usage, and many > > > > config changes to make SPL optional. > > > > > > Honestly I don't really see the point of merging these boards at all if > > > they don't have SPL support. People who really want to use them with > > > the rockchip blob can cherry-pick the patches from the list in the > > > meantime. > > > > > > It also creates incentive for people to free the DDR init, since that > > > becomes a condition to have the board upstream. > > > > > > What do you think? > > > > I don't know whether you get my point or not? these boards are not > > merged yet. What I'm saying is we are going to support them with > > TPL-enabled, that was SPL can make use of these boards which still a > > valid boot-chain. moreover this way can avoid touching core files and > > no specific change require while supporting ddr dtsi. > > On some boards, there will be no TPL and only a SPL stage that will > initialise DRAM (as the move to having TPL on the RK3399 is optional). > > I agree with Paul that the DRAM init should be part of U-Boot whenever > we add new boards and make an open DRAM init a prerequisite. Well, my initial point was to forbid merging broken SPL support, but I am totally in favor of requiring free DRAM init for merging new boards. Sadly it's hard to enforce this as a general rule in U-Boot since some platforms are plagued by non-free first-stage bootloaders because of signature checks, and that's where DRAM init happens. But for RK3399, we can totally have that rule, which directly creates incentive to free the blobs. Cheers, Paul -- Paul Kocialkowski, Bootlin Embedded Linux and kernel engineering https://bootlin.com ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-net.git master
On 09.05.2019 02:05, Vladimir Oltean wrote: > On 5/9/19 1:55 AM, Tom Rini wrote: >> On Wed, May 08, 2019 at 10:52:28PM +, Vladimir Oltean wrote: >>> On 5/9/19 1:48 AM, Tom Rini wrote: On Wed, May 08, 2019 at 10:45:50PM +, Vladimir Oltean wrote: > On 5/9/19 1:42 AM, Tom Rini wrote: >> On Wed, May 08, 2019 at 10:40:57PM +, Vladimir Oltean wrote: >>> On 5/9/19 1:24 AM, Joe Hershberger wrote: On Tue, May 7, 2019 at 5:15 PM Joe Hershberger wrote: > > Hi Tom, > > The following changes since commit > 8d7f06bbbef16f172cd5e9c4923cdcebe16b8980: > > I rebased on your master and built for BB Black. DHCP seems to work > fine. > MLO also now fits again. > >Merge branch 'master' of git://git.denx.de/u-boot-sh > (2019-05-07 09:38:00 -0400) > > are available in the git repository at: > >git://git.denx.de/u-boot-net.git master > > for you to fetch changes up to > 8d0c6858455e89b089222a08d55ff711681ca011: > >net: phy: micrel: Find Micrel PHY node correctly (2019-05-07 > 14:51:55 -0500) > > > Carlo Caione (4): >net: phy: Add generic helpers to access MMD PHY registers >net: phy: ti: use generic helpers to access MMD registers >cmd: mdio: Switch to generic helpers when accessing the > registers >net: phy: realtek: Introduce quirk to mark RXC not > stoppable > > James Byrne (2): >net: phy: micrel: Use correct skew values on KSZ9021 >net: phy: micrel: Find Micrel PHY node correctly > > Murali Karicheri (2): >ARM: k2g-gp-evm: update to rgmii pinmux configuration >ARM: k2g-ice: Add pinmux support for rgmii interface > > Pankaj Bansal (1): >drivers: net: ldpaa_eth: fix resource leak > > Siva Durga Prasad Paladugu (2): >net: phy: Reloc next and prev pointers inside phy_drivers >net: phy: Fix return value check phy_probe > > Valentin-catalin Neacsu (1): >net: phy: aquantia: Set only autoneg on in register 4.c441 > > Vladimir Oltean (6): >net: phy: ar803x: Address packet drops at low traffic rate > due to SmartEEE feature >net: phy: ar803x: Make RGMII Tx delays actually > configurable for AR8035 >net: phy: ar803x: Use common functions for RGMII internal > delays >net: phy: ar803x: Clarify the configuration of the CLK_25M > output pin >net: phy: ar803x: Explicitly disable RGMII delays Tom, this [1] is the patch that is breaking the evm. It doesn't affect BB Black because it uses an SMSC phy, where as this evm uses an AR8031/AR8033. Is it possible the device tree [2] is wrong for the board? It lists 'phy-mode = "rgmii-txid";', so that means that with this patch the RX delay is now being disabled. Any thoughts, Vladimir? Thanks, -Joe [1] b3224e0f7e - "net: phy: ar803x: Explicitly disable RGMII delays" [2] arch/arm/dts/am335x-evm.dts >net: phy: ar803x: Clarify the intention of ar8021_config > > arch/arm/dts/sama5d3xcm.dtsi| 32 +++--- > arch/arm/dts/sama5d3xcm_cmp.dtsi| 32 +++--- > arch/arm/dts/socfpga_arria5_socdk.dts | 4 +- > arch/arm/dts/socfpga_cyclone5_is1.dts | 4 +- > arch/arm/dts/socfpga_cyclone5_socdk.dts | 4 +- > arch/arm/dts/socfpga_cyclone5_sockit.dts| 4 +- > arch/arm/dts/socfpga_cyclone5_vining_fpga.dts | 4 +- > board/ti/ks2_evm/mux-k2g.h | 36 +++ > cmd/mdio.c | 27 +++-- > doc/device-tree-bindings/net/micrel-ksz90x1.txt | 27 + > drivers/net/ldpaa_eth/ldpaa_eth.c | 1 + > drivers/net/phy/Kconfig | 41 > drivers/net/phy/aquantia.c | 7 +- > drivers/net/phy/atheros.c | 128 > --- > drivers/net/phy/micrel_ksz90x1.c| 24 - > drivers/net/phy/phy.c | 21 +++- > drivers/net/phy/realtek.c
Re: [U-Boot] [RESEND PATCH v7 00/11] rockchip: Add new rk3399 boards
On Thu, May 9, 2019 at 6:09 PM Paul Kocialkowski wrote: > > On Thu, 2019-05-09 at 18:06 +0530, Jagan Teki wrote: > > On Thu, May 9, 2019 at 6:01 PM Paul Kocialkowski > > wrote: > > > Hi, > > > > > > On Thu, 2019-05-09 at 16:15 +0530, Jagan Teki wrote: > > > > Hi Paul, > > > > > > > > On Thu, May 9, 2019 at 12:38 PM Paul Kocialkowski > > > > wrote: > > > > > Hi, > > > > > > > > > > On Wed, 2019-05-08 at 11:11 +0530, Jagan Teki wrote: > > > > > > (Sorry for the noice, I have missed to send two patches from v7) > > > > > > > > > > > > This is v7 resend patchset for New rk3399 boards support wrt > > > > > > previous > > > > > > version[1] > > > > > > > > > > > > Unfortunately initial version of creating rk3399-u-boot.dtsi and > > > > > > orangepi rk3399 changes are merged, so this is rework on top of > > > > > > u-boot-rockchip/master. > > > > > > > > > > > > Overall this series add support below rk3399 boards > > > > > > - NanoPI M4 > > > > > > - NanoPC T4 > > > > > > - NanoPI NEO4 > > > > > > - Orangepi RK3399 > > > > > > - Rock PI 4 > > > > > > - Rockpro64 > > > > > > > > > > > > All the respective dts(i) files are synced from Linux 5.1-rc2 and > > > > > > few > > > > > > dts(i) from linux-next. > > > > > > > > > > > > SoC u-boot specific dtsi rk3399-u-boot.dtsi changes are part of > > > > > > another > > > > > > series [3]. > > > > > > > > > > > > Out of all above boards Rockpor64, Rock-PI and Nanopi NEO4 would > > > > > > support > > > > > > booting via Rockchip miniloader as of now. > > > > > > > > > > Could you send these two boards in a separate series so that we avoid > > > > > merging them for now (because SPL support is broken) and then re- > > > > > iterate the series later with the DDR bringup? Or maybe find a way to > > > > > disable SPL support, but in any case, it's not ok to merge a board > > > > > with > > > > > SPL enabled and broken. > > > > > > > > I have explained the details about this concern on v2 [1], thought you > > > > would comeback on the same line instead here. > > > > > > Yes, you have already explained the issue, but I don't think it's > > > enough a justification to merge broken SPL support. If it was only > > > partial or limited, it would be fine, but here it's just broken. > > > > > > > Anyway, making SPL as an optional is not an idea to go with Mainline > > > > as we make many decisions with regards to make SPL is mandatory. > > > > > > Yes I think making SPL mandatory is a good idea, so that's why I'm > > > suggesting that we don't merge the boards until they have SPL support. > > > > > > > Since the DDR is show stopper here (and it would really need a good > > > > amount of time, since it effect the other boards), I can go with TPL > > > > enabled boot-chain where ddr bin, SPL and U-Boot proper can be part of > > > > booting stages. This way we can avoid skipping SPL usage, and many > > > > config changes to make SPL optional. > > > > > > Honestly I don't really see the point of merging these boards at all if > > > they don't have SPL support. People who really want to use them with > > > the rockchip blob can cherry-pick the patches from the list in the > > > meantime. > > > > > > It also creates incentive for people to free the DDR init, since that > > > becomes a condition to have the board upstream. > > > > > > What do you think? > > > > I don't know whether you get my point or not? these boards are not > > merged yet. What I'm saying is we are going to support them with > > TPL-enabled, that was SPL can make use of these boards which still a > > valid boot-chain. moreover this way can avoid touching core files and > > no specific change require while supporting ddr dtsi. > > Ah maybe I missed the point indeed. > > So what you are suggesting is: > rkboot (acts as TPL) -> SPL -> U-Boot? Exactly, to make it confirm. Here is boot-chain on NEO4: DDR Version 1.20 20190314 In Channel 0: DDR3, 800MHz Bus Width=32 Col=10 Bank=8 Row=15 CS=1 Die Bus-Width=16 Size=1024MB no stride ch 0 ddrconfig = 0x101, ddrsize = 0x20 pmugrf_os_reg[2] = 0x10006281, stride = 0x17 OUT U-Boot SPL 2019.07-rc1-00243-gbd57cc7444 (May 09 2019 - 18:10:25 +0530) Trying to boot from MMC1 U-Boot 2019.07-rc1-00243-gbd57cc7444 (May 09 2019 - 18:12:59 +0530) Model: FriendlyARM NanoPi NEO4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RESEND PATCH v7 00/11] rockchip: Add new rk3399 boards
Jagan, > On 09.05.2019, at 14:36, Jagan Teki wrote: > > On Thu, May 9, 2019 at 6:01 PM Paul Kocialkowski > mailto:paul.kocialkow...@bootlin.com>> wrote: >> >> Hi, >> >> On Thu, 2019-05-09 at 16:15 +0530, Jagan Teki wrote: >>> Hi Paul, >>> >>> On Thu, May 9, 2019 at 12:38 PM Paul Kocialkowski >>> wrote: Hi, On Wed, 2019-05-08 at 11:11 +0530, Jagan Teki wrote: > (Sorry for the noice, I have missed to send two patches from v7) > > This is v7 resend patchset for New rk3399 boards support wrt previous > version[1] > > Unfortunately initial version of creating rk3399-u-boot.dtsi and > orangepi rk3399 changes are merged, so this is rework on top of > u-boot-rockchip/master. > > Overall this series add support below rk3399 boards > - NanoPI M4 > - NanoPC T4 > - NanoPI NEO4 > - Orangepi RK3399 > - Rock PI 4 > - Rockpro64 > > All the respective dts(i) files are synced from Linux 5.1-rc2 and few > dts(i) from linux-next. > > SoC u-boot specific dtsi rk3399-u-boot.dtsi changes are part of another > series [3]. > > Out of all above boards Rockpor64, Rock-PI and Nanopi NEO4 would support > booting via Rockchip miniloader as of now. Could you send these two boards in a separate series so that we avoid merging them for now (because SPL support is broken) and then re- iterate the series later with the DDR bringup? Or maybe find a way to disable SPL support, but in any case, it's not ok to merge a board with SPL enabled and broken. >>> >>> I have explained the details about this concern on v2 [1], thought you >>> would comeback on the same line instead here. >> >> Yes, you have already explained the issue, but I don't think it's >> enough a justification to merge broken SPL support. If it was only >> partial or limited, it would be fine, but here it's just broken. >> >>> Anyway, making SPL as an optional is not an idea to go with Mainline >>> as we make many decisions with regards to make SPL is mandatory. >> >> Yes I think making SPL mandatory is a good idea, so that's why I'm >> suggesting that we don't merge the boards until they have SPL support. >> >>> Since the DDR is show stopper here (and it would really need a good >>> amount of time, since it effect the other boards), I can go with TPL >>> enabled boot-chain where ddr bin, SPL and U-Boot proper can be part of >>> booting stages. This way we can avoid skipping SPL usage, and many >>> config changes to make SPL optional. >> >> Honestly I don't really see the point of merging these boards at all if >> they don't have SPL support. People who really want to use them with >> the rockchip blob can cherry-pick the patches from the list in the >> meantime. >> >> It also creates incentive for people to free the DDR init, since that >> becomes a condition to have the board upstream. >> >> What do you think? > > I don't know whether you get my point or not? these boards are not > merged yet. What I'm saying is we are going to support them with > TPL-enabled, that was SPL can make use of these boards which still a > valid boot-chain. moreover this way can avoid touching core files and > no specific change require while supporting ddr dtsi. On some boards, there will be no TPL and only a SPL stage that will initialise DRAM (as the move to having TPL on the RK3399 is optional). I agree with Paul that the DRAM init should be part of U-Boot whenever we add new boards and make an open DRAM init a prerequisite. Thanks, Philipp. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RESEND PATCH v7 00/11] rockchip: Add new rk3399 boards
On Thu, 2019-05-09 at 18:06 +0530, Jagan Teki wrote: > On Thu, May 9, 2019 at 6:01 PM Paul Kocialkowski > wrote: > > Hi, > > > > On Thu, 2019-05-09 at 16:15 +0530, Jagan Teki wrote: > > > Hi Paul, > > > > > > On Thu, May 9, 2019 at 12:38 PM Paul Kocialkowski > > > wrote: > > > > Hi, > > > > > > > > On Wed, 2019-05-08 at 11:11 +0530, Jagan Teki wrote: > > > > > (Sorry for the noice, I have missed to send two patches from v7) > > > > > > > > > > This is v7 resend patchset for New rk3399 boards support wrt previous > > > > > version[1] > > > > > > > > > > Unfortunately initial version of creating rk3399-u-boot.dtsi and > > > > > orangepi rk3399 changes are merged, so this is rework on top of > > > > > u-boot-rockchip/master. > > > > > > > > > > Overall this series add support below rk3399 boards > > > > > - NanoPI M4 > > > > > - NanoPC T4 > > > > > - NanoPI NEO4 > > > > > - Orangepi RK3399 > > > > > - Rock PI 4 > > > > > - Rockpro64 > > > > > > > > > > All the respective dts(i) files are synced from Linux 5.1-rc2 and few > > > > > dts(i) from linux-next. > > > > > > > > > > SoC u-boot specific dtsi rk3399-u-boot.dtsi changes are part of > > > > > another > > > > > series [3]. > > > > > > > > > > Out of all above boards Rockpor64, Rock-PI and Nanopi NEO4 would > > > > > support > > > > > booting via Rockchip miniloader as of now. > > > > > > > > Could you send these two boards in a separate series so that we avoid > > > > merging them for now (because SPL support is broken) and then re- > > > > iterate the series later with the DDR bringup? Or maybe find a way to > > > > disable SPL support, but in any case, it's not ok to merge a board with > > > > SPL enabled and broken. > > > > > > I have explained the details about this concern on v2 [1], thought you > > > would comeback on the same line instead here. > > > > Yes, you have already explained the issue, but I don't think it's > > enough a justification to merge broken SPL support. If it was only > > partial or limited, it would be fine, but here it's just broken. > > > > > Anyway, making SPL as an optional is not an idea to go with Mainline > > > as we make many decisions with regards to make SPL is mandatory. > > > > Yes I think making SPL mandatory is a good idea, so that's why I'm > > suggesting that we don't merge the boards until they have SPL support. > > > > > Since the DDR is show stopper here (and it would really need a good > > > amount of time, since it effect the other boards), I can go with TPL > > > enabled boot-chain where ddr bin, SPL and U-Boot proper can be part of > > > booting stages. This way we can avoid skipping SPL usage, and many > > > config changes to make SPL optional. > > > > Honestly I don't really see the point of merging these boards at all if > > they don't have SPL support. People who really want to use them with > > the rockchip blob can cherry-pick the patches from the list in the > > meantime. > > > > It also creates incentive for people to free the DDR init, since that > > becomes a condition to have the board upstream. > > > > What do you think? > > I don't know whether you get my point or not? these boards are not > merged yet. What I'm saying is we are going to support them with > TPL-enabled, that was SPL can make use of these boards which still a > valid boot-chain. moreover this way can avoid touching core files and > no specific change require while supporting ddr dtsi. Ah maybe I missed the point indeed. So what you are suggesting is: rkboot (acts as TPL) -> SPL -> U-Boot? Then I have no problem what that. Cheers, Paul -- Paul Kocialkowski, Bootlin Embedded Linux and kernel engineering https://bootlin.com ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RESEND PATCH v7 00/11] rockchip: Add new rk3399 boards
On Thu, May 9, 2019 at 6:01 PM Paul Kocialkowski wrote: > > Hi, > > On Thu, 2019-05-09 at 16:15 +0530, Jagan Teki wrote: > > Hi Paul, > > > > On Thu, May 9, 2019 at 12:38 PM Paul Kocialkowski > > wrote: > > > Hi, > > > > > > On Wed, 2019-05-08 at 11:11 +0530, Jagan Teki wrote: > > > > (Sorry for the noice, I have missed to send two patches from v7) > > > > > > > > This is v7 resend patchset for New rk3399 boards support wrt previous > > > > version[1] > > > > > > > > Unfortunately initial version of creating rk3399-u-boot.dtsi and > > > > orangepi rk3399 changes are merged, so this is rework on top of > > > > u-boot-rockchip/master. > > > > > > > > Overall this series add support below rk3399 boards > > > > - NanoPI M4 > > > > - NanoPC T4 > > > > - NanoPI NEO4 > > > > - Orangepi RK3399 > > > > - Rock PI 4 > > > > - Rockpro64 > > > > > > > > All the respective dts(i) files are synced from Linux 5.1-rc2 and few > > > > dts(i) from linux-next. > > > > > > > > SoC u-boot specific dtsi rk3399-u-boot.dtsi changes are part of another > > > > series [3]. > > > > > > > > Out of all above boards Rockpor64, Rock-PI and Nanopi NEO4 would support > > > > booting via Rockchip miniloader as of now. > > > > > > Could you send these two boards in a separate series so that we avoid > > > merging them for now (because SPL support is broken) and then re- > > > iterate the series later with the DDR bringup? Or maybe find a way to > > > disable SPL support, but in any case, it's not ok to merge a board with > > > SPL enabled and broken. > > > > I have explained the details about this concern on v2 [1], thought you > > would comeback on the same line instead here. > > Yes, you have already explained the issue, but I don't think it's > enough a justification to merge broken SPL support. If it was only > partial or limited, it would be fine, but here it's just broken. > > > Anyway, making SPL as an optional is not an idea to go with Mainline > > as we make many decisions with regards to make SPL is mandatory. > > Yes I think making SPL mandatory is a good idea, so that's why I'm > suggesting that we don't merge the boards until they have SPL support. > > > Since the DDR is show stopper here (and it would really need a good > > amount of time, since it effect the other boards), I can go with TPL > > enabled boot-chain where ddr bin, SPL and U-Boot proper can be part of > > booting stages. This way we can avoid skipping SPL usage, and many > > config changes to make SPL optional. > > Honestly I don't really see the point of merging these boards at all if > they don't have SPL support. People who really want to use them with > the rockchip blob can cherry-pick the patches from the list in the > meantime. > > It also creates incentive for people to free the DDR init, since that > becomes a condition to have the board upstream. > > What do you think? I don't know whether you get my point or not? these boards are not merged yet. What I'm saying is we are going to support them with TPL-enabled, that was SPL can make use of these boards which still a valid boot-chain. moreover this way can avoid touching core files and no specific change require while supporting ddr dtsi. Jagan. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RESEND PATCH v7 00/11] rockchip: Add new rk3399 boards
Hi, On Thu, 2019-05-09 at 16:15 +0530, Jagan Teki wrote: > Hi Paul, > > On Thu, May 9, 2019 at 12:38 PM Paul Kocialkowski > wrote: > > Hi, > > > > On Wed, 2019-05-08 at 11:11 +0530, Jagan Teki wrote: > > > (Sorry for the noice, I have missed to send two patches from v7) > > > > > > This is v7 resend patchset for New rk3399 boards support wrt previous > > > version[1] > > > > > > Unfortunately initial version of creating rk3399-u-boot.dtsi and > > > orangepi rk3399 changes are merged, so this is rework on top of > > > u-boot-rockchip/master. > > > > > > Overall this series add support below rk3399 boards > > > - NanoPI M4 > > > - NanoPC T4 > > > - NanoPI NEO4 > > > - Orangepi RK3399 > > > - Rock PI 4 > > > - Rockpro64 > > > > > > All the respective dts(i) files are synced from Linux 5.1-rc2 and few > > > dts(i) from linux-next. > > > > > > SoC u-boot specific dtsi rk3399-u-boot.dtsi changes are part of another > > > series [3]. > > > > > > Out of all above boards Rockpor64, Rock-PI and Nanopi NEO4 would support > > > booting via Rockchip miniloader as of now. > > > > Could you send these two boards in a separate series so that we avoid > > merging them for now (because SPL support is broken) and then re- > > iterate the series later with the DDR bringup? Or maybe find a way to > > disable SPL support, but in any case, it's not ok to merge a board with > > SPL enabled and broken. > > I have explained the details about this concern on v2 [1], thought you > would comeback on the same line instead here. Yes, you have already explained the issue, but I don't think it's enough a justification to merge broken SPL support. If it was only partial or limited, it would be fine, but here it's just broken. > Anyway, making SPL as an optional is not an idea to go with Mainline > as we make many decisions with regards to make SPL is mandatory. Yes I think making SPL mandatory is a good idea, so that's why I'm suggesting that we don't merge the boards until they have SPL support. > Since the DDR is show stopper here (and it would really need a good > amount of time, since it effect the other boards), I can go with TPL > enabled boot-chain where ddr bin, SPL and U-Boot proper can be part of > booting stages. This way we can avoid skipping SPL usage, and many > config changes to make SPL optional. Honestly I don't really see the point of merging these boards at all if they don't have SPL support. People who really want to use them with the rockchip blob can cherry-pick the patches from the list in the meantime. It also creates incentive for people to free the DDR init, since that becomes a condition to have the board upstream. What do you think? Cheers, Paul -- Paul Kocialkowski, Bootlin Embedded Linux and kernel engineering https://bootlin.com ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/2] Fix compilation error if CONFIG_USB is disabled
Hi Ajay, On 09/05/2019 13:26, Ajay Kaher wrote: > > > On 25/04/19, 7:07 PM, "Tom Rini" wrote: > >> On Thu, Apr 25, 2019 at 01:13:24PM +, Ajay Kaher wrote: >> > >> > Tom, [PATCH v2 1/2] reviewed by 'Matthias Brugger'. >> > But no update on [Patch v2 2/2] (includes changes in >> include/configs/rpi.h) >> >> Since Matthias is the Pi custodian, I'm expecting a PR from him with the >> changes. Thanks! > > Matthias, please let me know if you would require any info or detail from > me to review [Patch v2 2/2]. To create the [Patch v2 2/2], I have taken the > reference > of include/configs/rockchip-common.h. Same changes are already present in > include/configs/rockchip-common.h, hope this will help you to do review and > PR. Thanks. > It's on my list. On the first look it seems good for me. Bear with me, I'll take it netxt week and push it out. Regards, Matthias > - Ajay > >> > >> > >> > On 11/04/19, 10:56 AM, "akaher" wrote: >> > >> > Fix compilation error if CONFIG_USB is disabled >> > >> > [Patch v2 1/2]: >> > CONFIG_CMD_USB depends upon CONFIG_USB, so CONFIG_CMD_USB >> > should not be enabled if CONFIG_USB is disabled. >> > >> > [Patch v2 2/2]: >> > This patch is to fix the following compilation error when >> > disabling CONFIG_USB for Rpi3: >> > >> > include/config_distro_bootcmd.h:242:2: error: expected ‘}’ >> > before ‘BOOT_TARGET_DEVICES_references_USB_without_CONFIG_CMD_USB’ >> > BOOT_TARGET_DEVICES_references_USB_without_CONFIG_CMD_USB >> > >> > >> > Changes from v1: >> > Split the patch. >> > >> > >> > cmd/Kconfig | 1 + >> > include/configs/rpi.h | 36 +++- >> > >> > 2 file changed, 32 insertions(+), 5 deletions(-) >> > >> > -- >> > 2.14.2 >> > > > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/2] Fix compilation error if CONFIG_USB is disabled
On 25/04/19, 7:07 PM, "Tom Rini" wrote: > On Thu, Apr 25, 2019 at 01:13:24PM +, Ajay Kaher wrote: > > > > Tom, [PATCH v2 1/2] reviewed by 'Matthias Brugger'. > > But no update on [Patch v2 2/2] (includes changes in include/configs/rpi.h) > > Since Matthias is the Pi custodian, I'm expecting a PR from him with the > changes. Thanks! Matthias, please let me know if you would require any info or detail from me to review [Patch v2 2/2]. To create the [Patch v2 2/2], I have taken the reference of include/configs/rockchip-common.h. Same changes are already present in include/configs/rockchip-common.h, hope this will help you to do review and PR. Thanks. - Ajay > > > > > > On 11/04/19, 10:56 AM, "akaher" wrote: > > > > Fix compilation error if CONFIG_USB is disabled > > > > [Patch v2 1/2]: > > CONFIG_CMD_USB depends upon CONFIG_USB, so CONFIG_CMD_USB > > should not be enabled if CONFIG_USB is disabled. > > > > [Patch v2 2/2]: > > This patch is to fix the following compilation error when > > disabling CONFIG_USB for Rpi3: > > > > include/config_distro_bootcmd.h:242:2: error: expected ‘}’ > > before ‘BOOT_TARGET_DEVICES_references_USB_without_CONFIG_CMD_USB’ > > BOOT_TARGET_DEVICES_references_USB_without_CONFIG_CMD_USB > > > > > > Changes from v1: > > Split the patch. > > > > > > cmd/Kconfig | 1 + > > include/configs/rpi.h | 36 +++- > > > > 2 file changed, 32 insertions(+), 5 deletions(-) > > > > -- > > 2.14.2 > > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Pull request for UEFI sub-system for v2019.07-rc2 (2)
On Thu, May 09, 2019 at 12:15:34AM +0200, Graf, Alexander wrote:
>
> On 09.05.19 00:03, Heinrich Schuchardt wrote:
> >On 5/8/19 7:50 PM, Tom Rini wrote:
> >>On Wed, May 08, 2019 at 07:57:57AM +0200, Heinrich Schuchardt wrote:
> >>
> >>>The following changes since commit
> >>>44237e272f1eac3b026709e76333a07b2d3a3523:
> >>>
> >>>Merge branch 'master' of git://git.denx.de/u-boot-sh (2019-05-06
> >>>07:19:31 -0400)
> >>>
> >>>are available in the Git repository at:
> >>>
> >>>git://git.denx.de/u-boot-efi.git tags/efi-2019-07-rc2-2
> >>>
> >>>for you to fetch changes up to
> >>>b015ab57bf558daa1c768995a7a7f1df2d40191e:
> >>>
> >>>efi_loader: signature of ExitBootServices() (2019-05-07 21:10:04
> >>>+0200)
> >>>
> >>>Travis CI results are here:
> >>>https://travis-ci.org/xypron2/u-boot/builds/529448555
> >>>
> >>>Primary key fingerprint: 6DC4 F9C7 1F29 A6FA 06B7 6D33 C481 DBBC
> >>>2C05 1AC4
> >>>
> >>
> >>Note that you may want to run ./scripts/checkpatch.pl --git
> >>origin/master.. or similar as: WARNING: 'follwing' may be misspelled
> >>- perhaps 'following'?
> >>
> >>which I left alone rather than mess up the tag.
> >
> >Sorry I missed that one. Typically I run checkpatch.pl.
> >
> >>
> >>Applied to u-boot/master, thanks!
> >>
> >>And all of that said, looking over my before/after builds I see a lot
> >>of size growth, everywhere, due to EFI changes. I assume this is due
> >>to increasing overall functionality and support, which is good. But
> >>is there perhaps some way we can split things into a minimal "we
> >>have enough to support loading ${OS LOADER}" and then "we are aiming
> >>for large parts of spec compliance" ? Some days I start to wonder
> >>if "EFI_LOADER on by default" was a bad idea.
> >>
> >
> >The following switches allow to reduce the size of the UEFI subsystem:
> >
> >CONFIG_CMD_BOOTEFI_HELLO, default N
> >CONFIG_CMD_BOOTEFI_SELFTEST, default N except QEMU
> >CONFIG_EFI_UNICODE_CAPITALIZATION, default Y
> >CONFIG_EFI_LOADER_HII
> >(The Makefile does not consider it yet correctly, patch submitted.)
> >CONFIG_CMD_EFIDEBUG, default N
> >CONFIG_CMD_NVEDIT_EFI
> >
> >In doc/README.uefi we describe that we target EBBR compatibility.
> >
> >We have implemented functionality that is not needed for EBBR
> >compatibility but is needed to run the EFI Shell and the conformance
> >tests or iPXE. Here we should think about making it customizable, e.g.
> >
> >lib/efi_loader/efi_bootmgr.c
> >lib/efi_driver/*
> >lib/efi_loader/efi_unicode_collation.c
> >lib/efi_loader/efi_variable.c
> >lib/efi_loader/device_path_to_text.c
> >lib/efi_loader/device_path_utilities.c
> >
> >For the Unicode collation protocol I just sent a patch.
>
>
> Do you have size estimates for how much each of those bits are? Where did we
> see the biggest growth? What eats up the most code/data space?
>
> I think we should aim to ideally incur less than 20kb overhead for an arm
> target. How far are we from that? We used to be at 10kb.
On am335x_evm disabling CONFIG_EFI_LOADER saves 51kb and on pine64-lts
disabling CONFIG_EFI_LOADER saves 75kb.
--
Tom
signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 02/18] arm: omap_i2c: Remove unwanted header file inclusion
Hello Andreas, Am 08.05.2019 um 23:37 schrieb Andreas Dannenberg: From: Vignesh R There is no need for to include this header here, so drop it. Signed-off-by: Vignesh R --- arch/arm/include/asm/omap_i2c.h | 2 -- 1 file changed, 2 deletions(-) Reviewed-by: Heiko Schocher bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 01/18] i2c: omap24xx_i2c: Adapt driver to support K3 devices
Hello Andreas, Am 08.05.2019 um 23:37 schrieb Andreas Dannenberg: From: Vignesh R K3 devices have I2C IP that is same as OMAP2+ family. Allow driver to be compiled for ARCH_K3. Signed-off-by: Vignesh R Signed-off-by: Andreas Dannenberg --- drivers/i2c/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Heiko Schocher bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/6] env: ubi: KConfig: add CONFIG_ENV_UBI_VOLUME_REDUND
Hello Markus, Am 09.05.2019 um 10:59 schrieb Markus Klotzbuecher: Hello Heiko On Tue, Apr 30, 2019 at 06:54:01AM +0200, Heiko Schocher wrote: Am 15.04.2019 um 17:32 schrieb Markus Klotzbuecher: From: Markus Klotzbuecher please add a commit message. Signed-off-by: Markus Klotzbuecher Cc: Heiko Schocher Cc: Kyungmin Park --- env/Kconfig | 6 ++ scripts/config_whitelist.txt | 1 - 2 files changed, 6 insertions(+), 1 deletion(-) diff --git a/env/Kconfig b/env/Kconfig index 78300660c7..44c47220c2 100644 --- a/env/Kconfig +++ b/env/Kconfig @@ -513,6 +513,12 @@ config ENV_UBI_VOLUME help Name of the volume that you want to store the environment in. +config ENV_UBI_VOLUME_REDUND + string "UBI redundant volume name" + depends on ENV_IS_IN_UBI + help + Name of the redundant volume that you want to store the environment in. + endif config USE_DEFAULT_ENV_FILE diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt index fa98efc24c..5d76c781d3 100644 --- a/scripts/config_whitelist.txt +++ b/scripts/config_whitelist.txt @@ -504,7 +504,6 @@ CONFIG_ENV_SROM_BANK CONFIG_ENV_TOTAL_SIZE CONFIG_ENV_UBIFS_OPTION CONFIG_ENV_UBI_MTD -CONFIG_ENV_UBI_VOLUME_REDUND CONFIG_ENV_VERSION CONFIG_EP9302 CONFIG_EP9307 Please move from the config files: ./include/configs/omap3_igep00x0.h ./include/configs/gardena-smart-gateway-at91sam.h ./include/configs/am335x_igep003x.h also the symbols to the defconfig files, thanks. I have a question: to convert these, I need to make available the additional ENV_ configs to OMAP2PLUS and AT91: diff --git a/env/Kconfig b/env/Kconfig index 44c47220c2..1250656d74 100644 --- a/env/Kconfig +++ b/env/Kconfig @@ -470,7 +470,7 @@ config ENV_EXT4_FILE It's a string of the EXT4 file name. This file use to store the environment (explicit path to the file) -if ARCH_ROCKCHIP || ARCH_SUNXI || ARCH_ZYNQ || ARCH_ZYNQMP || ARCH_VERSAL || ARC +if ARCH_ROCKCHIP || ARCH_SUNXI || ARCH_ZYNQ || ARCH_ZYNQMP || ARCH_VERSAL || ARC || ARCH_OMAP2PLUS || ARCH_AT91 However, this "if" region contains a few other, non UBI settings such as ENV_SIZE, which would become visible to a large number of OMAP2PLUS and AT91 boards, which still define this in the headers. Huch? If so, than they are not converted (yet) ... :-( I'm a bit hesitant to touch all of these. What is the suggested way to solve this? I think, they should be converted too ... Sorry for the additional work ... I can understand your hesitantion to do such a conversion... Hmm... I used some year(s) ago tbot for checking, if a config change did not introduced diffs in created binaries for all boards [1] ... In principal I did: - build all boards with "SOURCE_DATE_EPOCH=0" and created a md5sum from each binary - apply patch(es) - build again, create md5sums and check if mdsum is the same Unfortunately not converted this testcase to the new tbot ... But may it is possible to convert this into a script ? bye, Heiko [1] https://github.com/hsdenx/tbot/blob/master/src/tc/uboot/tc_uboot_check_kconfig.py -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] imx: define ARCH_MXC for i.MX8/8M/7ULP
On Thu, May 9, 2019 at 5:33 AM Peng Fan wrote: > > Without this definition, fsl_esdhc will access reserved registers > on i.MX chips, so define ARCH_MXC to fix it. > > Signed-off-by: Peng Fan Reviewed-by: Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] imx: drop imx-regs.h
On Thu, May 9, 2019 at 5:33 AM Peng Fan wrote: > > imx-regs.h under arch-imx has no user, drop it. > > Signed-off-by: Peng Fan Reviewed-by: Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 3/3] doc: rockchip: Add doc for rk3399 TPL build/flash
This patch add documentation for TPL build and flashing steps for rk3399 boards. Add full boot log for future reference. Signed-off-by: Jagan Teki --- doc/README.rockchip | 51 - 1 file changed, 50 insertions(+), 1 deletion(-) diff --git a/doc/README.rockchip b/doc/README.rockchip index ca4d6473b0..264f7e4994 100644 --- a/doc/README.rockchip +++ b/doc/README.rockchip @@ -173,7 +173,10 @@ For example: => make u-boot.itb (Get spl/u-boot-spl-dtb.bin, u-boot.itb images and some boards would get - spl/u-boot-spl.bin since it doesn't enable CONFIG_SPL_OF_CONTROL) + spl/u-boot-spl.bin since it doesn't enable CONFIG_SPL_OF_CONTROL + + If TPL enabled on the target, get tpl/u-boot-tpl-dtb.bin or tpl/u-boot-tpl.bin + if CONFIG_TPL_OF_CONTROL not enabled) Writing to the board with USB = @@ -455,6 +458,52 @@ Net: eth0: ethernet@fe30 Hit any key to stop autoboot: 0 => +Option 3: Package the image with TPL: + + - Prefix rk3399 header to TPL image + +=> cd /path/to/u-boot +=> ./tools/mkimage -n rk3399 -T rksd -d tpl/u-boot-tpl-dtb.bin out + + - Concatinate tpl with spl + +=> cd /path/to/u-boot +=> cat ./spl/u-boot-spl-dtb.bin >> out + + - Write tpl+spl at 64th sector + +=> sudo dd if=out of=/dev/sdc seek=64 + + - Write U-Boot proper at 16384 sector + +=> sudo dd if=u-boot.itb of=/dev/sdc seek=16384 +=> sync + +Put this SD (or micro-SD) card into your board and reset it. You should see +something like: + +U-Boot TPL board init +Trying to boot from BOOTROM +Returning to boot ROM... + +U-Boot SPL board init +Trying to boot from MMC1 + + +U-Boot 2019.07-rc1-00241-g5b3244767a (May 08 2019 - 10:51:06 +0530) + +Model: Orange Pi RK3399 Board +DRAM: 2 GiB +MMC: dwmmc@fe31: 2, dwmmc@fe32: 1, sdhci@fe33: 0 +Loading Environment from MMC... OK +In:serial@ff1a +Out: serial@ff1a +Err: serial@ff1a +Model: Orange Pi RK3399 Board +Net: eth0: ethernet@fe30 +Hit any key to stop autoboot: 0 +=> + Using fastboot on rk3288 - Write GPT partition layout to mmc device which fastboot want to use it to -- 2.18.0.321.gffc6fa0e3 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
