[U-Boot] [PATCH V2 5/6] ARM: AM43xx: Add build support
Add AM43xx support in the required places
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
arch/arm/cpu/armv7/Makefile |2 +-
arch/arm/cpu/armv7/omap-common/boot-common.c |3 ++-
drivers/serial/ns16550.c |5 +++--
3 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/arch/arm/cpu/armv7/Makefile b/arch/arm/cpu/armv7/Makefile
index 2ba88d0..8f27507 100644
--- a/arch/arm/cpu/armv7/Makefile
+++ b/arch/arm/cpu/armv7/Makefile
@@ -16,7 +16,7 @@ COBJS += cache_v7.o
COBJS += cpu.o
COBJS += syslib.o
-ifneq
($(CONFIG_AM33XX)$(CONFIG_OMAP44XX)$(CONFIG_OMAP54XX)$(CONFIG_TEGRA)$(CONFIG_MX6)$(CONFIG_TI814X),)
+ifneq
($(CONFIG_AM43XX)$(CONFIG_AM33XX)$(CONFIG_OMAP44XX)$(CONFIG_OMAP54XX)$(CONFIG_TEGRA)$(CONFIG_MX6)$(CONFIG_TI814X),)
SOBJS += lowlevel_init.o
endif
diff --git a/arch/arm/cpu/armv7/omap-common/boot-common.c
b/arch/arm/cpu/armv7/omap-common/boot-common.c
index 6b9ce36..6b4772b 100644
--- a/arch/arm/cpu/armv7/omap-common/boot-common.c
+++ b/arch/arm/cpu/armv7/omap-common/boot-common.c
@@ -40,7 +40,8 @@ void save_omap_boot_params(void)
if ((boot_device = MMC_BOOT_DEVICES_START)
(boot_device = MMC_BOOT_DEVICES_END)) {
-#if !defined(CONFIG_AM33XX) !defined(CONFIG_TI81XX)
+#if !defined(CONFIG_AM33XX) !defined(CONFIG_TI81XX) \
+ !defined(CONFIG_AM43XX)
if ((omap_hw_init_context() ==
OMAP_INIT_CONTEXT_UBOOT_AFTER_SPL)) {
gd-arch.omap_boot_params.omap_bootmode =
diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c
index d77c25f..bc976ba 100644
--- a/drivers/serial/ns16550.c
+++ b/drivers/serial/ns16550.c
@@ -57,7 +57,8 @@ void NS16550_init(NS16550_t com_port, int baud_divisor)
serial_out(CONFIG_SYS_NS16550_IER, com_port-ier);
#if (defined(CONFIG_OMAP) !defined(CONFIG_OMAP3_ZOOM2)) || \
- defined(CONFIG_AM33XX) || defined(CONFIG_TI814X)
+ defined(CONFIG_AM33XX) || defined(CONFIG_TI814X) || \
+ defined(CONFIG_AM43XX)
serial_out(0x7, com_port-mdr1); /* mode select reset TL16C750*/
#endif
serial_out(UART_LCR_BKSE | UART_LCRVAL, com_port-lcr);
@@ -72,7 +73,7 @@ void NS16550_init(NS16550_t com_port, int baud_divisor)
serial_out(UART_LCRVAL, com_port-lcr);
#if (defined(CONFIG_OMAP) !defined(CONFIG_OMAP3_ZOOM2)) || \
defined(CONFIG_AM33XX) || defined(CONFIG_SOC_DA8XX) || \
- defined(CONFIG_TI814X)
+ defined(CONFIG_TI814X) || defined(CONFIG_AM43XX)
/* /16 is proper to hit 115200 with 48MHz */
serial_out(0, com_port-mdr1);
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2 0/6] ARM: AM43xx: Add Support for AM43xx Soc's
AM43xx is a low cost Cortex-A9 based application processor
targets higher performance applications and new specific end
equipments like Point of Sale requiring stringent security requirements.
This series add support for AM43xx Soc's.
Data for the following is not added:
- SDRAM
- DPLL Dividers and post dividers
- Pin mux data(only uart data added).
Once this data is available Ill add them.
Config file is kept minimal for now, ll add the corresponding configs when
they are validated.
This is on top of u-boot-ti + V2 of AM33xx cleanup series.
http://u-boot.10912.n7.nabble.com/PATCH-V2-0-4-ARM-AM33xx-Cleanup-clocks-and-hwinit-tt160272.html
Testing:
Tested on pre-silicon platform
verified ./MAKEALL --cpu=armv7
./MAKEALL -s am33xx
Changes Since V1:
- Rebased on top of u-boot-ti + V2 of AM33xx Cleanup
- Updated License header for new files.
Lokesh Vutla (6):
ARM: AM43xx: Add Board files
ARM: AM43xx: Add header files
ARM: AM43xx: clocks: Add dpll and clock data
ARM: OMAP: Add CONFIG_OMAP_COMMON
ARM: AM43xx: Add build support
ARM: AM43xx: Add config file
Makefile |2 +-
arch/arm/config.mk |2 +-
arch/arm/cpu/armv7/Makefile|2 +-
arch/arm/cpu/armv7/am33xx/Makefile |7 +-
arch/arm/cpu/armv7/am33xx/clock_am43xx.c | 110 +
arch/arm/cpu/armv7/omap-common/Makefile|2 +-
arch/arm/cpu/armv7/omap-common/boot-common.c |3 +-
arch/arm/include/asm/arch-am33xx/cpu.h | 164 +++-
arch/arm/include/asm/arch-am33xx/hardware.h|8 +-
arch/arm/include/asm/arch-am33xx/hardware_am33xx.h |9 ++
.../{hardware_am33xx.h = hardware_am43xx.h} | 18 ++-
arch/arm/include/asm/arch-am33xx/hardware_ti814x.h |9 ++
arch/arm/include/asm/arch-am33xx/mux.h |2 +
arch/arm/include/asm/arch-am33xx/mux_am43xx.h | 143 +
arch/arm/include/asm/arch-am33xx/omap.h|9 +-
arch/arm/include/asm/arch-am33xx/spl.h |4 +-
board/ti/am43xx/Makefile | 38 +
board/ti/am43xx/board.c| 57 +++
board/ti/am43xx/board.h| 17 ++
board/ti/am43xx/mux.c | 27
boards.cfg |1 +
drivers/serial/ns16550.c |5 +-
include/configs/am335x_evm.h |1 +
include/configs/am3517_crane.h |1 +
include/configs/am3517_evm.h |1 +
include/configs/am43xx_evm.h | 135
include/configs/cm_t35.h |1 +
include/configs/devkit8000.h |1 +
include/configs/dig297.h |1 +
include/configs/igep0033.h |1 +
include/configs/igep00x0.h |1 +
include/configs/mcx.h |1 +
include/configs/nokia_rx51.h |1 +
include/configs/omap3_beagle.h |1 +
include/configs/omap3_evm_common.h |1 +
include/configs/omap3_logic.h |1 +
include/configs/omap3_mvblx.h |1 +
include/configs/omap3_overo.h |1 +
include/configs/omap3_pandora.h|1 +
include/configs/omap3_sdp3430.h|1 +
include/configs/omap3_zoom1.h |1 +
include/configs/omap3_zoom2.h |1 +
include/configs/omap4_common.h |1 +
include/configs/omap5_common.h |1 +
include/configs/pcm051.h |1 +
include/configs/tam3517-common.h |1 +
include/configs/ti814x_evm.h |1 +
include/configs/tricorder.h|1 +
spl/Makefile |2 +-
49 files changed, 766 insertions(+), 35 deletions(-)
create mode 100644 arch/arm/cpu/armv7/am33xx/clock_am43xx.c
copy arch/arm/include/asm/arch-am33xx/{hardware_am33xx.h = hardware_am43xx.h}
(69%)
create mode 100644 arch/arm/include/asm/arch-am33xx/mux_am43xx.h
create mode 100644 board/ti/am43xx/Makefile
create mode 100644 board/ti/am43xx/board.c
create mode 100644 board/ti/am43xx/board.h
create mode 100644 board/ti/am43xx/mux.c
create mode 100644 include/configs/am43xx_evm.h
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2 2/6] ARM: AM43xx: Add header files
Adding the following data:
- Prcm structure
- Base addresses
- Pin mux structure.
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
arch/arm/include/asm/arch-am33xx/cpu.h | 164 +++-
arch/arm/include/asm/arch-am33xx/hardware.h|8 +-
arch/arm/include/asm/arch-am33xx/hardware_am33xx.h |9 ++
.../{hardware_am33xx.h = hardware_am43xx.h} | 18 ++-
arch/arm/include/asm/arch-am33xx/hardware_ti814x.h |9 ++
arch/arm/include/asm/arch-am33xx/mux.h |2 +
arch/arm/include/asm/arch-am33xx/mux_am43xx.h | 143 +
arch/arm/include/asm/arch-am33xx/omap.h|9 +-
arch/arm/include/asm/arch-am33xx/spl.h |4 +-
9 files changed, 340 insertions(+), 26 deletions(-)
copy arch/arm/include/asm/arch-am33xx/{hardware_am33xx.h = hardware_am43xx.h}
(69%)
create mode 100644 arch/arm/include/asm/arch-am33xx/mux_am43xx.h
diff --git a/arch/arm/include/asm/arch-am33xx/cpu.h
b/arch/arm/include/asm/arch-am33xx/cpu.h
index bcb4c50..10b56e0 100644
--- a/arch/arm/include/asm/arch-am33xx/cpu.h
+++ b/arch/arm/include/asm/arch-am33xx/cpu.h
@@ -43,13 +43,6 @@
#define SYSBOOT_MASK (BIT(0) | BIT(1) | BIT(2)\
| BIT(3) | BIT(4))
-/* Reset control */
-#ifdef CONFIG_AM33XX
-#define PRM_RSTCTRL(PRCM_BASE + 0x0F00)
-#elif defined(CONFIG_TI814X)
-#define PRM_RSTCTRL(PRCM_BASE + 0x00A0)
-#endif
-#define PRM_RSTST (PRM_RSTCTRL + 8)
#define PRM_RSTCTRL_RESET 0x01
#define PRM_RSTST_WARM_RESET_MASK 0x232
@@ -108,6 +101,7 @@ struct gpmc {
/* Used for board specific gpmc initialization */
extern struct gpmc *gpmc_cfg;
+#ifndef CONFIG_AM43XX
/* Encapsulating core pll registers */
struct cm_wkuppll {
unsigned int wkclkstctrl; /* offset 0x00 */
@@ -211,6 +205,162 @@ struct cm_perpll {
unsigned int resv10[8];
unsigned int cpswclkstctrl; /* offset 0x144 */
};
+#else
+/* Encapsulating core pll registers */
+struct cm_wkuppll {
+ unsigned int resv0[136];
+ unsigned int wkl4wkclkctrl; /* offset 0x220 */
+ unsigned int resv1[55];
+ unsigned int wkclkstctrl; /* offset 0x300 */
+ unsigned int resv2[15];
+ unsigned int wkup_i2c0ctrl; /* offset 0x340 */
+ unsigned int resv3;
+ unsigned int wkup_uart0ctrl;/* offset 0x348 */
+ unsigned int resv4[5];
+ unsigned int wkctrlclkctrl; /* offset 0x360 */
+ unsigned int resv5;
+ unsigned int wkgpio0clkctrl;/* offset 0x368 */
+
+ unsigned int resv6[109];
+ unsigned int clkmoddpllcore;/* offset 0x520 */
+ unsigned int idlestdpllcore;/* offset 0x524 */
+ unsigned int resv61;
+ unsigned int clkseldpllcore;/* offset 0x52C */
+ unsigned int resv7[2];
+ unsigned int divm4dpllcore; /* offset 0x538 */
+ unsigned int divm5dpllcore; /* offset 0x53C */
+ unsigned int divm6dpllcore; /* offset 0x540 */
+
+ unsigned int resv8[7];
+ unsigned int clkmoddpllmpu; /* offset 0x560 */
+ unsigned int idlestdpllmpu; /* offset 0x564 */
+ unsigned int resv9;
+ unsigned int clkseldpllmpu; /* offset 0x56c */
+ unsigned int divm2dpllmpu; /* offset 0x570 */
+
+ unsigned int resv10[11];
+ unsigned int clkmoddpllddr; /* offset 0x5A0 */
+ unsigned int idlestdpllddr; /* offset 0x5A4 */
+ unsigned int resv11;
+ unsigned int clkseldpllddr; /* offset 0x5AC */
+ unsigned int divm2dpllddr; /* offset 0x5B0 */
+
+ unsigned int resv12[11];
+ unsigned int clkmoddpllper; /* offset 0x5E0 */
+ unsigned int idlestdpllper; /* offset 0x5E4 */
+ unsigned int resv13;
+ unsigned int clkseldpllper; /* offset 0x5EC */
+ unsigned int divm2dpllper; /* offset 0x5F0 */
+ unsigned int resv14[8];
+ unsigned int clkdcoldodpllper; /* offset 0x614 */
+
+ unsigned int resv15[2];
+ unsigned int clkmoddplldisp;/* offset 0x620 */
+ unsigned int resv16[2];
+ unsigned int clkseldplldisp;/* offset 0x62C */
+ unsigned int divm2dplldisp; /* offset 0x630 */
+};
+
+/*
+ * Encapsulating peripheral functional clocks
+ * pll registers
+ */
+struct cm_perpll {
+ unsigned int l3clkstctrl; /* offset 0x00 */
+ unsigned int resv0[7];
+ unsigned int l3clkctrl; /* Offset 0x20 */
+ unsigned int resv1[7];
+ unsigned int l3instrclkctrl;/* offset 0x40 */
+ unsigned int resv2[3];
+ unsigned int ocmcramclkctrl;/* offset 0x50 */
+ unsigned int resv3[9];
+ unsigned int tpccclkctrl; /* offset 0x78 */
+ unsigned int resv4;
+ unsigned int tptc0clkctrl; /* offset 0x80 */
+
+ unsigned int resv5[7];
+ unsigned int l4hsclkctrl;
[U-Boot] [PATCH V2 4/6] ARM: OMAP: Add CONFIG_OMAP_COMMON
Adding a new CONFIG_OMAP_COMMON which is included by all boards that needs to build cpu/armv7/omap-common folder. Signed-off-by: Lokesh Vutla lokeshvu...@ti.com --- Makefile|2 +- arch/arm/config.mk |2 +- arch/arm/cpu/armv7/omap-common/Makefile |2 +- include/configs/am335x_evm.h|1 + include/configs/am3517_crane.h |1 + include/configs/am3517_evm.h|1 + include/configs/cm_t35.h|1 + include/configs/devkit8000.h|1 + include/configs/dig297.h|1 + include/configs/igep0033.h |1 + include/configs/igep00x0.h |1 + include/configs/mcx.h |1 + include/configs/nokia_rx51.h|1 + include/configs/omap3_beagle.h |1 + include/configs/omap3_evm_common.h |1 + include/configs/omap3_logic.h |1 + include/configs/omap3_mvblx.h |1 + include/configs/omap3_overo.h |1 + include/configs/omap3_pandora.h |1 + include/configs/omap3_sdp3430.h |1 + include/configs/omap3_zoom1.h |1 + include/configs/omap3_zoom2.h |1 + include/configs/omap4_common.h |1 + include/configs/omap5_common.h |1 + include/configs/pcm051.h|1 + include/configs/tam3517-common.h|1 + include/configs/ti814x_evm.h|1 + include/configs/tricorder.h |1 + spl/Makefile|2 +- 29 files changed, 29 insertions(+), 4 deletions(-) diff --git a/Makefile b/Makefile index 7206aba..5461a21 100644 --- a/Makefile +++ b/Makefile @@ -322,7 +322,7 @@ LIBS-y += api/libapi.o LIBS-y += post/libpost.o LIBS-y += test/libtest.o -ifneq ($(CONFIG_AM33XX)$(CONFIG_OMAP34XX)$(CONFIG_OMAP44XX)$(CONFIG_OMAP54XX)$(CONFIG_TI814X),) +ifneq ($(CONFIG_OMAP_COMMON),) LIBS-y += $(CPUDIR)/omap-common/libomap-common.o endif diff --git a/arch/arm/config.mk b/arch/arm/config.mk index 540a119..ce3903b 100644 --- a/arch/arm/config.mk +++ b/arch/arm/config.mk @@ -8,7 +8,7 @@ CROSS_COMPILE ?= arm-linux- ifndef CONFIG_STANDALONE_LOAD_ADDR -ifneq ($(CONFIG_AM33XX)$(CONFIG_OMAP34XX)$(CONFIG_OMAP44XX)$(CONFIG_OMAP54XX)$(CONFIG_TI814X),) +ifneq ($(CONFIG_OMAP_COMMON),) CONFIG_STANDALONE_LOAD_ADDR = 0x8030 else CONFIG_STANDALONE_LOAD_ADDR = 0xc10 diff --git a/arch/arm/cpu/armv7/omap-common/Makefile b/arch/arm/cpu/armv7/omap-common/Makefile index 98f29d4..75b3753 100644 --- a/arch/arm/cpu/armv7/omap-common/Makefile +++ b/arch/arm/cpu/armv7/omap-common/Makefile @@ -21,7 +21,7 @@ COBJS += vc.o COBJS += abb.o endif -ifneq ($(CONFIG_AM33XX)$(CONFIG_OMAP44XX)$(CONFIG_OMAP54XX)$(CONFIG_TI814X),) +ifeq ($(CONFIG_OMAP34XX),) COBJS += boot-common.o SOBJS += lowlevel_init.o endif diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h index e32066d..dcc3d68 100644 --- a/include/configs/am335x_evm.h +++ b/include/configs/am335x_evm.h @@ -18,6 +18,7 @@ #define CONFIG_AM33XX #define CONFIG_OMAP +#define CONFIG_OMAP_COMMON #include asm/arch/omap.h diff --git a/include/configs/am3517_crane.h b/include/configs/am3517_crane.h index 9bf283a..1fd2508 100644 --- a/include/configs/am3517_crane.h +++ b/include/configs/am3517_crane.h @@ -19,6 +19,7 @@ #define CONFIG_OMAP1 /* in a TI OMAP core */ #define CONFIG_OMAP34XX1 /* which is a 34XX */ #define CONFIG_OMAP3_AM3517CRANE 1 /* working with CRANEBOARD */ +#define CONFIG_OMAP_COMMON #define CONFIG_EMIF4 /* The chip has EMIF4 controller */ diff --git a/include/configs/am3517_evm.h b/include/configs/am3517_evm.h index 5c61697..6500878 100644 --- a/include/configs/am3517_evm.h +++ b/include/configs/am3517_evm.h @@ -19,6 +19,7 @@ #define CONFIG_OMAP1 /* in a TI OMAP core */ #define CONFIG_OMAP34XX1 /* which is a 34XX */ #define CONFIG_OMAP3_AM3517EVM 1 /* working with AM3517EVM */ +#define CONFIG_OMAP_COMMON #define CONFIG_EMIF4 /* The chip has EMIF4 controller */ diff --git a/include/configs/cm_t35.h b/include/configs/cm_t35.h index 39a216e..bc5b66c 100644 --- a/include/configs/cm_t35.h +++ b/include/configs/cm_t35.h @@ -24,6 +24,7 @@ #define CONFIG_OMAP34XX/* which is a 34XX */ #define CONFIG_OMAP_GPIO #define CONFIG_CM_T3X /* working with CM-T35 and CM-T3730 */ +#define CONFIG_OMAP_COMMON #define CONFIG_SYS_TEXT_BASE 0x80008000 diff --git a/include/configs/devkit8000.h b/include/configs/devkit8000.h index 513121a..cb79b4e 100644 --- a/include/configs/devkit8000.h +++ b/include/configs/devkit8000.h @@ -21,6 +21,7 @@ #define CONFIG_OMAP3_DEVKIT80001 /* working with DevKit8000 */ #define CONFIG_MACH_TYPE MACH_TYPE_DEVKIT8000 #define CONFIG_OMAP_GPIO +#define CONFIG_OMAP_COMMON /* * 1MB
[U-Boot] [PATCH V2 3/6] ARM: AM43xx: clocks: Add dpll and clock data
Add dpll and clock data for AM43xx
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
arch/arm/cpu/armv7/am33xx/Makefile |7 +-
arch/arm/cpu/armv7/am33xx/clock_am43xx.c | 110 ++
board/ti/am43xx/board.c |3 +-
3 files changed, 118 insertions(+), 2 deletions(-)
create mode 100644 arch/arm/cpu/armv7/am33xx/clock_am43xx.c
diff --git a/arch/arm/cpu/armv7/am33xx/Makefile
b/arch/arm/cpu/armv7/am33xx/Makefile
index 7fd21af..bd8e752 100644
--- a/arch/arm/cpu/armv7/am33xx/Makefile
+++ b/arch/arm/cpu/armv7/am33xx/Makefile
@@ -10,7 +10,12 @@ LIB = $(obj)lib$(SOC).o
COBJS-$(CONFIG_AM33XX) += clock_am33xx.o
COBJS-$(CONFIG_TI814X) += clock_ti814x.o
-COBJS-$(CONFIG_AM33XX) += clock.o
+COBJS-$(CONFIG_AM43XX) += clock_am43xx.o
+
+ifneq ($(CONFIG_AM43XX)$(CONFIG_AM33XX),)
+COBJS += clock.o
+endif
+
COBJS += sys_info.o
COBJS += mem.o
COBJS += ddr.o
diff --git a/arch/arm/cpu/armv7/am33xx/clock_am43xx.c
b/arch/arm/cpu/armv7/am33xx/clock_am43xx.c
new file mode 100644
index 000..c4890f2
--- /dev/null
+++ b/arch/arm/cpu/armv7/am33xx/clock_am43xx.c
@@ -0,0 +1,110 @@
+/*
+ * clock_am43xx.c
+ *
+ * clocks for AM43XX based boards
+ * Derived from AM33XX based boards
+ *
+ * Copyright (C) 2013, Texas Instruments, Incorporated - http://www.ti.com/
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include common.h
+#include asm/arch/cpu.h
+#include asm/arch/clock.h
+#include asm/arch/hardware.h
+#include asm/arch/sys_proto.h
+#include asm/io.h
+
+struct cm_perpll *const cmper = (struct cm_perpll *)CM_PER;
+struct cm_wkuppll *const cmwkup = (struct cm_wkuppll *)CM_WKUP;
+
+const struct dpll_regs dpll_mpu_regs = {
+ .cm_clkmode_dpll= CM_WKUP + 0x560,
+ .cm_idlest_dpll = CM_WKUP + 0x564,
+ .cm_clksel_dpll = CM_WKUP + 0x56c,
+ .cm_div_m2_dpll = CM_WKUP + 0x570,
+};
+
+const struct dpll_regs dpll_core_regs = {
+ .cm_clkmode_dpll= CM_WKUP + 0x520,
+ .cm_idlest_dpll = CM_WKUP + 0x524,
+ .cm_clksel_dpll = CM_WKUP + 0x52C,
+ .cm_div_m4_dpll = CM_WKUP + 0x538,
+ .cm_div_m5_dpll = CM_WKUP + 0x53C,
+ .cm_div_m6_dpll = CM_WKUP + 0x540,
+};
+
+const struct dpll_regs dpll_per_regs = {
+ .cm_clkmode_dpll= CM_WKUP + 0x5E0,
+ .cm_idlest_dpll = CM_WKUP + 0x5E4,
+ .cm_clksel_dpll = CM_WKUP + 0x5EC,
+ .cm_div_m2_dpll = CM_WKUP + 0x5F0,
+};
+
+const struct dpll_regs dpll_ddr_regs = {
+ .cm_clkmode_dpll= CM_WKUP + 0x5A0,
+ .cm_idlest_dpll = CM_WKUP + 0x5A4,
+ .cm_clksel_dpll = CM_WKUP + 0x5AC,
+ .cm_div_m2_dpll = CM_WKUP + 0x5B0,
+};
+
+const struct dpll_params dpll_mpu = {
+ -1, -1, -1, -1, -1, -1, -1};
+const struct dpll_params dpll_core = {
+ -1, -1, -1, -1, -1, -1, -1};
+const struct dpll_params dpll_per = {
+ -1, -1, -1, -1, -1, -1, -1};
+
+void setup_clocks_for_console(void)
+{
+ /* Do not add any spl_debug prints in this function */
+ clrsetbits_le32(cmwkup-wkclkstctrl, CD_CLKCTRL_CLKTRCTRL_MASK,
+ CD_CLKCTRL_CLKTRCTRL_SW_WKUP
+ CD_CLKCTRL_CLKTRCTRL_SHIFT);
+
+ /* Enable UART0 */
+ clrsetbits_le32(cmwkup-wkup_uart0ctrl,
+ MODULE_CLKCTRL_MODULEMODE_MASK,
+ MODULE_CLKCTRL_MODULEMODE_SW_EXPLICIT_EN
+ MODULE_CLKCTRL_MODULEMODE_SHIFT);
+}
+
+void enable_basic_clocks(void)
+{
+ u32 *const clk_domains[] = {
+ cmper-l3clkstctrl,
+ cmper-l3sclkstctrl,
+ cmper-l4lsclkstctrl,
+ cmwkup-wkclkstctrl,
+ cmper-emifclkstctrl,
+ 0
+ };
+
+ u32 *const clk_modules_explicit_en[] = {
+ cmper-l3clkctrl,
+ cmper-l4lsclkctrl,
+ cmper-l4fwclkctrl,
+ cmwkup-wkl4wkclkctrl,
+ cmper-l3instrclkctrl,
+ cmper-l4hsclkctrl,
+ cmwkup-wkgpio0clkctrl,
+ cmwkup-wkctrlclkctrl,
+ cmper-timer2clkctrl,
+ cmper-gpmcclkctrl,
+ cmper-elmclkctrl,
+ cmper-mmc0clkctrl,
+ cmper-mmc1clkctrl,
+ cmwkup-wkup_i2c0ctrl,
+ cmper-gpio1clkctrl,
+ cmper-gpio2clkctrl,
+ cmper-gpio3clkctrl,
+ cmper-i2c1clkctrl,
+ cmper-emiffwclkctrl,
+ cmper-emifclkctrl,
+ cmper-otfaemifclkctrl,
+ 0
+ };
+
+ do_enable_clocks(clk_domains, clk_modules_explicit_en, 1);
+}
diff --git a/board/ti/am43xx/board.c b/board/ti/am43xx/board.c
index f5b9100..51b2576 100644
--- a/board/ti/am43xx/board.c
+++ b/board/ti/am43xx/board.c
@@ -10,6 +10,7 @@
#include common.h
#include spl.h
+#include asm/arch/clock.h
#include
[U-Boot] [PATCH V2 1/6] ARM: AM43xx: Add Board files
Add board specific information for AM43xx.
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
board/ti/am43xx/Makefile | 38 +++
board/ti/am43xx/board.c | 56 ++
board/ti/am43xx/board.h | 17 ++
board/ti/am43xx/mux.c| 27 ++
4 files changed, 138 insertions(+)
create mode 100644 board/ti/am43xx/Makefile
create mode 100644 board/ti/am43xx/board.c
create mode 100644 board/ti/am43xx/board.h
create mode 100644 board/ti/am43xx/mux.c
diff --git a/board/ti/am43xx/Makefile b/board/ti/am43xx/Makefile
new file mode 100644
index 000..4a1bb7c
--- /dev/null
+++ b/board/ti/am43xx/Makefile
@@ -0,0 +1,38 @@
+#
+# Makefile
+#
+# Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+include $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(BOARD).o
+
+ifdef CONFIG_SPL_BUILD
+COBJS := mux.o
+endif
+
+COBJS += board.o
+SRCS := $(COBJS:.o=.c)
+OBJS := $(addprefix $(obj),$(COBJS))
+SOBJS := $(addprefix $(obj),$(SOBJS))
+
+$(LIB):$(obj).depend $(OBJS) $(SOBJS)
+ $(call cmd_link_o_target, $(OBJS) $(SOBJS))
+
+clean:
+ rm -f $(SOBJS) $(OBJS)
+
+distclean: clean
+ rm -f $(LIB) core *.bak $(obj).depend
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/ti/am43xx/board.c b/board/ti/am43xx/board.c
new file mode 100644
index 000..f5b9100
--- /dev/null
+++ b/board/ti/am43xx/board.c
@@ -0,0 +1,56 @@
+/*
+ * board.c
+ *
+ * Board functions for TI AM43XX based boards
+ *
+ * Copyright (C) 2013, Texas Instruments, Incorporated - http://www.ti.com/
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include common.h
+#include spl.h
+#include asm/arch/sys_proto.h
+#include asm/arch/mux.h
+#include board.h
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#ifdef CONFIG_SPL_BUILD
+
+const struct dpll_params dpll_ddr = {
+ 266, OSC-1, 1, -1, -1, -1, -1};
+
+const struct dpll_params *get_dpll_ddr_params(void)
+{
+ return dpll_ddr;
+}
+
+void set_uart_mux_conf(void)
+{
+ enable_uart0_pin_mux();
+}
+
+void set_mux_conf_regs(void)
+{
+ enable_board_pin_mux();
+}
+
+void sdram_init(void)
+{
+}
+#endif
+
+int board_init(void)
+{
+ gd-bd-bi_boot_params = PHYS_DRAM_1 + 0x100;
+
+ return 0;
+}
+
+#ifdef CONFIG_BOARD_LATE_INIT
+int board_late_init(void)
+{
+ return 0;
+}
+#endif
diff --git a/board/ti/am43xx/board.h b/board/ti/am43xx/board.h
new file mode 100644
index 000..8ca098b
--- /dev/null
+++ b/board/ti/am43xx/board.h
@@ -0,0 +1,17 @@
+/*
+ * board.h
+ *
+ * TI AM437x boards information header
+ * Derived from AM335x board.
+ *
+ * Copyright (C) 2013, Texas Instruments, Incorporated - http://www.ti.com/
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef _BOARD_H_
+#define _BOARD_H_
+
+void enable_uart0_pin_mux(void);
+void enable_board_pin_mux(void);
+#endif
diff --git a/board/ti/am43xx/mux.c b/board/ti/am43xx/mux.c
new file mode 100644
index 000..700e9a7
--- /dev/null
+++ b/board/ti/am43xx/mux.c
@@ -0,0 +1,27 @@
+/*
+ * mux.c
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include common.h
+#include asm/arch/sys_proto.h
+#include asm/arch/mux.h
+#include board.h
+
+static struct module_pin_mux uart0_pin_mux[] = {
+ {OFFSET(uart0_rxd), (MODE(0) | RXACTIVE)}, /* UART0_RXD */
+ {OFFSET(uart0_txd), (MODE(0))}, /* UART0_TXD */
+ {-1},
+};
+
+void enable_uart0_pin_mux(void)
+{
+ configure_module_pin_mux(uart0_pin_mux);
+}
+
+void enable_board_pin_mux(void)
+{
+}
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2 6/6] ARM: AM43xx: Add config file
Add config file
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
boards.cfg |1 +
include/configs/am43xx_evm.h | 135 ++
2 files changed, 136 insertions(+)
create mode 100644 include/configs/am43xx_evm.h
diff --git a/boards.cfg b/boards.cfg
index 211ed58..8d86a1b 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -252,6 +252,7 @@ am335x_evm_uart4 arm armv7 am335x
ti
am335x_evm_uart5 arm armv7 am335x ti
am33xx am335x_evm:SERIAL6,CONS_INDEX=1,NAND
am335x_evm_usbsplarm armv7 am335x ti
am33xx am335x_evm:SERIAL1,CONS_INDEX=1,NAND,SPL_USBETH_SUPPORT
am335x_boneblack arm armv7 am335x ti
am33xx am335x_evm:SERIAL1,CONS_INDEX=1,EMMC_BOOT
+am43xx_evm arm armv7 am43xx ti
am33xx am43xx_evm:SERIAL1,CONS_INDEX=1
ti814x_evm arm armv7 ti814x ti
am33xx
pcm051 arm armv7 pcm051
phytec am33xx pcm051
sama5d3xek_mmc arm armv7 sama5d3xek atmel
at91sama5d3xek:SAMA5D3,SYS_USE_MMC
diff --git a/include/configs/am43xx_evm.h b/include/configs/am43xx_evm.h
new file mode 100644
index 000..5c802a1
--- /dev/null
+++ b/include/configs/am43xx_evm.h
@@ -0,0 +1,135 @@
+/*
+ * am43xx_evm.h
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef __CONFIG_AM43XX_EVM_H
+#define __CONFIG_AM43XX_EVM_H
+
+#define CONFIG_AM43XX
+#define CONFIG_OMAP
+#define CONFIG_OMAP_COMMON
+
+#include asm/arch/omap.h
+
+#define CONFIG_DMA_COHERENT
+#define CONFIG_DMA_COHERENT_SIZE (1 20)
+
+#define CONFIG_ENV_SIZE(128 10) /* 128 KiB */
+#define CONFIG_SYS_MALLOC_LEN (1024 10)
+#define CONFIG_SYS_LONGHELP/* undef to save memory */
+#define CONFIG_SYS_HUSH_PARSER /* use hush command parser */
+#define CONFIG_SYS_PROMPT U-Boot#
+#define CONFIG_SYS_NO_FLASH
+
+#define CONFIG_OF_LIBFDT
+#define CONFIG_CMD_BOOTZ
+#define CONFIG_CMDLINE_TAG /* enable passing of ATAGs */
+#define CONFIG_CMDLINE_EDITING
+#define CONFIG_SETUP_MEMORY_TAGS
+#define CONFIG_INITRD_TAG
+
+/* commands to include */
+#include config_cmd_default.h
+
+#define CONFIG_CMD_ASKENV
+#define CONFIG_VERSION_VARIABLE
+
+/* set to negative value for no autoboot */
+#define CONFIG_BOOTDELAY 1
+#define CONFIG_ENV_VARS_UBOOT_CONFIG
+#define CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
+
+/* Clock Defines */
+#define V_OSCK 2400 /* Clock output from T2 */
+#define V_SCLK (V_OSCK)
+
+#define CONFIG_CMD_ECHO
+
+/* max number of command args */
+#define CONFIG_SYS_MAXARGS 64
+
+/* Console I/O Buffer Size */
+#define CONFIG_SYS_CBSIZE 512
+
+/* Print Buffer Size */
+#define CONFIG_SYS_PBSIZE (CONFIG_SYS_CBSIZE \
+ + sizeof(CONFIG_SYS_PROMPT) + 16)
+
+/* Boot Argument Buffer Size */
+#define CONFIG_SYS_BARGSIZECONFIG_SYS_CBSIZE
+
+ /* Physical Memory Map */
+#define CONFIG_NR_DRAM_BANKS 1 /* 1 bank of DRAM */
+#define PHYS_DRAM_10x8000 /* DRAM Bank #1 */
+#define CONFIG_MAX_RAM_BANK_SIZE (1024 20)/* 1GB */
+
+#define CONFIG_SYS_SDRAM_BASE PHYS_DRAM_1
+#define CONFIG_SYS_INIT_SP_ADDR (NON_SECURE_SRAM_END - \
+ GENERATED_GBL_DATA_SIZE)
+/* Platform/Board specific defs */
+#define CONFIG_SYS_LOAD_ADDR 0x8100 /* Default load address */
+
+#define CONFIG_SYS_TIMERBASE 0x4804 /* Use Timer2 */
+#define CONFIG_SYS_PTV 2 /* Divisor: 2^(PTV+1) = 8 */
+#define CONFIG_SYS_HZ 1000
+
+/* NS16550 Configuration */
+#define CONFIG_SYS_NS16550
+#define CONFIG_SYS_NS16550_SERIAL
+#define CONFIG_SYS_NS16550_REG_SIZE(-4)
+#define CONFIG_SYS_NS16550_CLK (4800)
+#define CONFIG_SYS_NS16550_COM10x44e09000 /* Base EVM has
UART0 */
+
+#define CONFIG_BAUDRATE115200
+#define CONFIG_SYS_BAUDRATE_TABLE { 110, 300, 600, 1200, 2400, \
+4800, 9600, 14400, 19200, 28800, 38400, 56000, 57600, 115200 }
+
+/* CPU */
+#define CONFIG_ARCH_CPU_INIT
+
+#define CONFIG_ENV_OVERWRITE 1
+#define CONFIG_SYS_CONSOLE_INFO_QUIET
+
+#define CONFIG_ENV_IS_NOWHERE
+
+/*
+ * 1MB into the SDRAM to allow for SPL's bss at the beginning of SDRAM
+ * 64 bytes before this address should be set aside for u-boot.img's
+ * header. That is 0x800FFFC0--0x8010 should not be used for any
Re: [U-Boot] Falcon Mode implemented version
Hi Stefano, As in the case of NAND, u-boot_spl.bin is generated in u-boot/spl_nand/ directory, In case of NOR, where exactly the separate spl image will be generated? or Will u-boot.bin contain the whole spl + secondary u-boot? Please help me with these, Thanks in advance, Rajdeep Vaghasia On Mon, Jul 29, 2013 at 5:50 PM, Stefano Babic sba...@denx.de wrote: Hi Rajdeep, On 29/07/2013 14:04, Rajdeep Vaghasia wrote: Hi all, I have the following queries. 1) Can anyone suggest me the exact version of u-boot in which falcon mode is implemented? There is no exact version - falcon mode was merged more as one year ago. Take simply 2013.07 or u-boot TOT. I also wanted to know, if is there any readme available for that implementation. doc/README.falcon Please also tell me, where exactly in the u-boot code it is implemented. There is no exact the code - to speed up the boot, several parts were changed. You can check for code surrounded by CONFIG_CMD_SPL and CONFIG_SPL_OS_BOOT. 2) The u-boot version in which SPL for NOR flash is implemented. There is at least a couple of boards supporting SPL and booting form NOR: woodburn (MX35) and a3m071(MPC 5200). Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Falcon Mode implemented version
Hi Rajdeep, On 30/07/2013 08:16, Rajdeep Vaghasia wrote: Hi Stefano, As in the case of NAND, u-boot_spl.bin is generated in u-boot/spl_nand/ directory, You're wrong: spl_nand is the old legacy spl. It is maintained for old boards, but it should not be used for new projects. Setting CONFIG_SPL, u-boot is generated into the spl/ directory. Please try to compile the boards I have mentioned - you can then check how production runs. In case of NOR, where exactly the separate spl image will be generated? or Will u-boot.bin contain the whole spl + secondary u-boot? No, but there is an option to concatenate automatically SPL and u-boot if desired. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/3] arm, am335x: add support for 3 siemens boards
Hello Lokesh,
Am 30.07.2013 07:39, schrieb Lokesh Vutla:
Hi Heiko,
On Tuesday 30 July 2013 10:39 AM, Heiko Schocher wrote:
add support for the am335x based boards from siemens:
[...]
- [U-Boot] net, phy, cpsw: fix gigabit register access
http://patchwork.ozlabs.org/patch/261087/
I have just posted a V2 of AM33xx cleanup series, Can you rebase on top of that.
There was a bug in my series. Multiplier for DDR DPLL was hard coded for all
the boards.
IN V2, the common file expects a function which returns ddr_dpll_parms.
So can you add the following code in your board files:
#define OSC (V_OSCK/100)
const struct dpll_params dpll_ddr = {
DXR2_PLL_FREQ, OSC-1, 1, -1, -1, -1, -1};
const struct dpll_params *get_dpll_ddr_params(void)
{
returndpll_ddr;
}
The M value we pass in config_ddr is not used(should be cleaned up)
Please let me know if I am not clear.
Sorry for the noise...
No problem, thanks for the info... Hmm.. just rebased against
top of u-boot-ti and your patches, but ethernet is not longer
working :-( I get:
U-Boot# ping 192.168.1.1
link up on port 0, speed 1000, full duplex
data abort
MAYBE you should read doc/README.arm-unaligned-accesses
pc : [9ff6ed7c] lr : [9ff6f810]
sp : 9ef40d50 ip : 0019010c fp :
r10: 33221100 r9 : 002e r8 : 9ef40f38
r7 : 9ffed56c r6 : 9ef45db0 r5 : 0004 r4 : 9ef45d50
r3 : 05ee r2 : 9ffee2c0 r1 : 9ef45db0 r0 : 9ef45d50
Flags: nzCv IRQs off FIQs on Mode SVC_32
Resetting CPU ...
resetting ...
U-Boot SPL 2013.07-00098-g2b19a9e (Jul 30 2013 - 09:00:03)
Digging in this ...
Hmm... @tom:
My patch:
[U-Boot] net, phy, cpsw: fix gigabit register access
http://patchwork.ozlabs.org/patch/261087/
has the following diff:
drivers/net/cpsw.c| 2 +-
drivers/net/phy/phy.c | 6 +-
2 Dateien geändert, 6 Zeilen hinzugefügt(+), 2 Zeilen entfernt(-)
Looking in u-boot-ti tree it has:
http://git.denx.de/?p=u-boot/u-boot-ti.git;a=commitdiff;h=7614ef78db2edcfb174da6a21a6756f5de08cc8e
it changes also boards.cfg !? There went something wrong while applying
this patch ... Could you have a look at this issue?
Thanks.
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/3] arm, am335x: add support for 3 siemens boards
Hello Lokesh, tom,
Am 30.07.2013 09:13, schrieb Heiko Schocher:
Hello Lokesh,
Am 30.07.2013 07:39, schrieb Lokesh Vutla:
Hi Heiko,
On Tuesday 30 July 2013 10:39 AM, Heiko Schocher wrote:
add support for the am335x based boards from siemens:
[...]
- [U-Boot] net, phy, cpsw: fix gigabit register access
http://patchwork.ozlabs.org/patch/261087/
I have just posted a V2 of AM33xx cleanup series, Can you rebase on top of that.
There was a bug in my series. Multiplier for DDR DPLL was hard coded for all
the boards.
IN V2, the common file expects a function which returns ddr_dpll_parms.
So can you add the following code in your board files:
#define OSC (V_OSCK/100)
const struct dpll_params dpll_ddr = {
DXR2_PLL_FREQ, OSC-1, 1, -1, -1, -1, -1};
const struct dpll_params *get_dpll_ddr_params(void)
{
returndpll_ddr;
}
The M value we pass in config_ddr is not used(should be cleaned up)
Please let me know if I am not clear.
Sorry for the noise...
No problem, thanks for the info... Hmm.. just rebased against
top of u-boot-ti and your patches, but ethernet is not longer
working :-( I get:
U-Boot# ping 192.168.1.1
link up on port 0, speed 1000, full duplex
data abort
MAYBE you should read doc/README.arm-unaligned-accesses
pc : [9ff6ed7c] lr : [9ff6f810]
sp : 9ef40d50 ip : 0019010c fp :
r10: 33221100 r9 : 002e r8 : 9ef40f38
r7 : 9ffed56c r6 : 9ef45db0 r5 : 0004 r4 : 9ef45d50
r3 : 05ee r2 : 9ffee2c0 r1 : 9ef45db0 r0 : 9ef45d50
Flags: nzCv IRQs off FIQs on Mode SVC_32
Resetting CPU ...
resetting ...
U-Boot SPL 2013.07-00098-g2b19a9e (Jul 30 2013 - 09:00:03)
Digging in this ...
Fixed. reason was commit 2bf36ac638ab2db9f0295aa47064976eeebf80c1
which introduced bd_ram_ofs field to struct cpsw_platform_data
I rebased my patches on Lokeshs patches and repost my series on
top of it.
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 1/4] ARM: AM33xx: Cleanup dplls data
Hello LOkesh, Am 30.07.2013 07:18, schrieb Lokesh Vutla: Locking sequence for all the dplls is same. In the current code same sequence is done repeatedly for each dpll. Instead have a generic function for locking dplls and pass dpll data to that function. This is derived from OMAP4 boards. Signed-off-by: Lokesh Vutlalokeshvu...@ti.com --- arch/arm/cpu/armv7/am33xx/Makefile |1 + arch/arm/cpu/armv7/am33xx/clock.c| 111 + arch/arm/cpu/armv7/am33xx/clock_am33xx.c | 220 +- arch/arm/cpu/armv7/am33xx/emif4.c|4 + arch/arm/include/asm/arch-am33xx/clock.h | 70 arch/arm/include/asm/arch-am33xx/ddr_defs.h |2 + arch/arm/include/asm/arch-am33xx/sys_proto.h |1 + board/isee/igep0033/board.c | 10 ++ board/phytec/pcm051/board.c |9 ++ board/ti/am335x/board.c | 27 10 files changed, 273 insertions(+), 182 deletions(-) create mode 100644 arch/arm/cpu/armv7/am33xx/clock.c Tested-by: Heiko Schocher h...@denx.de Acked-by: Heiko Schocher h...@denx.de Thanks! bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 2/4] ARM: AM33xx: Cleanup clocks layer
Hello Lokesh, Am 30.07.2013 07:18, schrieb Lokesh Vutla: Cleaning up the clocks layer. This helps in addition of new Soc with minimal changes. This is derived from OMAP4 boards. Signed-off-by: Lokesh Vutlalokeshvu...@ti.com --- arch/arm/cpu/armv7/am33xx/board.c |6 - arch/arm/cpu/armv7/am33xx/clock.c | 62 +- arch/arm/cpu/armv7/am33xx/clock_am33xx.c| 275 --- arch/arm/cpu/armv7/am33xx/clock_ti814x.c| 19 +- arch/arm/cpu/armv7/am33xx/emif4.c |1 - arch/arm/include/asm/arch-am33xx/clock.h| 28 ++- arch/arm/include/asm/arch-am33xx/ddr_defs.h |2 - board/isee/igep0033/board.c | 11 +- board/ti/am335x/board.c | 13 +- board/ti/ti814x/evm.c | 12 +- 10 files changed, 193 insertions(+), 236 deletions(-) Tested-by: Heiko Schocher h...@denx.de Acked-by: Heiko Schocher h...@denx.de Thanks! bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 3/4] ARM: AM33xx: Move s_init to a common place
Hello Lokesh, Am 30.07.2013 07:18, schrieb Lokesh Vutla: From: Heiko Schocherh...@denx.de s_init has the same outline for all the AM33xx based board. So making it generic. This also helps in addition of new Soc with minimal changes. Signed-off-by: Lokesh Vutlalokeshvu...@ti.com Signed-off-by: Heiko Schocherh...@denx.de Signed-off-by: Tom Rinitr...@ti.com --- arch/arm/cpu/armv7/am33xx/board.c| 62 +++-- arch/arm/cpu/armv7/am33xx/clock_ti814x.c |6 ++ arch/arm/include/asm/arch-am33xx/clocks_am33xx.h |6 +- arch/arm/include/asm/arch-am33xx/sys_proto.h |8 ++- board/isee/igep0033/board.c | 50 +++--- board/phytec/pcm051/board.c | 48 +++-- board/ti/am335x/board.c | 80 -- board/ti/am335x/mux.c| 19 + board/ti/ti814x/evm.c| 67 +++--- 9 files changed, 128 insertions(+), 218 deletions(-) Tested-by: Heiko Schocher h...@denx.de Acked-by: Heiko Schocher h...@denx.de Thanks! bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 4/4] musb: Disable extra prints
Hello Lokesh, Am 30.07.2013 07:18, schrieb Lokesh Vutla: There are many musb prints in SPL and U-Boot log. These prints are required only during musb debug. So replacing printk with pr_debug in musb_core. Signed-off-by: Lokesh Vutlalokeshvu...@ti.com --- drivers/usb/musb-new/musb_core.c | 20 1 file changed, 8 insertions(+), 12 deletions(-) Tested-by: Heiko Schocher h...@denx.de Acked-by: Heiko Schocher h...@denx.de Thanks! bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 0/4] arm, am335x: add support for siemens boards
add support for the am335x based boards from siemens: dxr2: - DDR3 128MiB - NAND 256MiB - Ethernet with external Switch SMSC LAN9303 - no PMIC - internal Watchdog - DFU support pxm2: - DDR2 512 MiB - NAND 1024 MiB - PMIC - PHY atheros ar803x - USB Host - internal Watchdog - DFU support rut: - DDR3 256 MiB - NAND 256 MiB - PMIC - PHY natsemi dp83630 - external Watchdog - DFU support - changes for v2: - add a more detailed comment, from where the files are based - add missing (C) - changes for v3: - rebased against u-boot-ti commit bb2a5d8f87fffb4fadfb205837decbd1b3e75f88 - rebased against lokeshs v2 patches - rebased arm, am33xx: add defines for gmii_sel_register bits patch, and therefore added to this patchserie - add bd_ram_ofs to cpsw_data in board code needed since commit 2bf36ac638ab2db9f0295aa47064976eeebf80c1 Needed patches: - [U-Boot] arm, spl: add watchdog library to SPL http://patchwork.ozlabs.org/patch/248503/ reposted with this patchserie - [U-Boot] arm, arm335x: add watchdog support http://patchwork.ozlabs.org/patch/248504/ reposted with this patchserie - [U-Boot,v2] arm, am33xx: add defines for gmii_sel_register bits http://patchwork.ozlabs.org/patch/248916/ added in v3 to this patchseries as rebased against u-boot-ti - patches from Lokesh Vutla: [U-Boot,V2,1/4] ARM: AM33xx: Cleanup dplls data http://patchwork.ozlabs.org/patch/263175/ [U-Boot,V2,2/4] ARM: AM33xx: Cleanup clocks layer http://patchwork.ozlabs.org/patch/263176/ [U-Boot,V2,3/4] ARM: AM33xx: Move s_init to a common place http://patchwork.ozlabs.org/patch/263177/ [U-Boot,V2,4/4] musb: Disable extra prints http://patchwork.ozlabs.org/patch/263174/ - [U-Boot,v5] dfu, nand, ubi: add partubi alt settings for updating ubi partition http://patchwork.ozlabs.org/patch/261583/ - [U-Boot] net, phy, cpsw: fix gigabit register access http://patchwork.ozlabs.org/patch/261087/ Tested patches with this patch: - [U-Boot] dfu: Implementation of target reset after communication with dfu-util's -R switch http://patchwork.ozlabs.org/patch/260041/ - [U-Boot] ARM: OMAP: GPIO: Fix valid range and enable usage of all GPIOs on OMAP5 http://patchwork.ozlabs.org/patch/253185/ Heiko Schocher (4): arm, am33xx: add defines for gmii_sel_register bits arm, spl: add watchdog library to SPL arm, am335x: add watchdog support arm, am335x: add support for 3 siemens boards MAINTAINERS| 5 + arch/arm/include/asm/arch-am33xx/cpu.h | 41 +++ board/isee/igep0033/board.c| 6 +- board/phytec/pcm051/board.c| 2 - board/siemens/common/board.c | 167 board/siemens/common/factoryset.c | 268 +++ board/siemens/common/factoryset.h | 21 ++ board/siemens/dxr2/Makefile| 49 board/siemens/dxr2/board.c | 241 + board/siemens/dxr2/board.h | 69 + board/siemens/dxr2/mux.c | 112 board/siemens/pxm2/Makefile| 49 board/siemens/pxm2/board.c | 238 + board/siemens/pxm2/board.h | 22 ++ board/siemens/pxm2/mux.c | 140 ++ board/siemens/pxm2/pmic.h | 71 + board/siemens/rut/Makefile | 49 board/siemens/rut/board.c | 180 + board/siemens/rut/board.h | 22 ++ board/siemens/rut/mux.c| 341 board/ti/am335x/board.c| 6 +- boards.cfg | 3 + doc/README.SPL | 2 +- drivers/watchdog/Makefile | 1 + drivers/watchdog/omap_wdt.c| 121 + include/configs/dxr2.h | 94 +++ include/configs/pxm2.h | 134 ++ include/configs/rut.h | 135 ++ include/configs/siemens-am33x-common.h | 464 + spl/Makefile | 1 + 30 Dateien geändert, 3042 Zeilen hinzugefügt(+), 12 Zeilen entfernt(-) create mode 100644 board/siemens/common/board.c create mode 100644 board/siemens/common/factoryset.c create mode 100644 board/siemens/common/factoryset.h create mode 100644 board/siemens/dxr2/Makefile create mode 100644 board/siemens/dxr2/board.c create mode 100644 board/siemens/dxr2/board.h create mode 100644 board/siemens/dxr2/mux.c create mode 100644 board/siemens/pxm2/Makefile create mode 100644 board/siemens/pxm2/board.c create mode 100644 board/siemens/pxm2/board.h create mode 100644 board/siemens/pxm2/mux.c create mode 100644 board/siemens/pxm2/pmic.h create mode 100644 board/siemens/rut/Makefile create mode 100644 board/siemens/rut/board.c create mode 100644 board/siemens/rut/board.h create mode 100644 board/siemens/rut/mux.c create mode 100644 drivers/watchdog/omap_wdt.c create mode
[U-Boot] [PATCH v3 2/4] arm, spl: add watchdog library to SPL
Signed-off-by: Heiko Schocher h...@denx.de Cc: Tom Rini tr...@ti.com --- - changes for v2: none - changes for v3: rebased against u-boot-ti commit bb2a5d8f87fffb4fadfb205837decbd1b3e75f88 --- doc/README.SPL | 2 +- spl/Makefile | 1 + 2 Dateien geändert, 2 Zeilen hinzugefügt(+), 1 Zeile entfernt(-) diff --git a/doc/README.SPL b/doc/README.SPL index ac9a213..312a6a6 100644 --- a/doc/README.SPL +++ b/doc/README.SPL @@ -67,7 +67,7 @@ CONFIG_SPL_POST_MEM_SUPPORT (post/drivers/memory.o) CONFIG_SPL_NAND_LOAD (drivers/mtd/nand/nand_spl_load.o) CONFIG_SPL_SPI_LOAD (drivers/mtd/spi/spi_spl_load.o) CONFIG_SPL_RAM_DEVICE (common/spl/spl.c) - +CONFIG_SPL_WATCHDOG_SUPPORT (drivers/watchdog/libwatchdog.o) Normally CPU is assumed to be the same between the SPL and normal u-boot build. However it is possible to specify a different CPU for diff --git a/spl/Makefile b/spl/Makefile index 6e5299b..9a46e7e 100644 --- a/spl/Makefile +++ b/spl/Makefile @@ -82,6 +82,7 @@ LIBS-$(CONFIG_SPL_ETH_SUPPORT) += drivers/net/libnet.o LIBS-$(CONFIG_SPL_ETH_SUPPORT) += drivers/net/phy/libphy.o LIBS-$(CONFIG_SPL_MUSB_NEW_SUPPORT) += drivers/usb/musb-new/libusb_musb-new.o LIBS-$(CONFIG_SPL_USBETH_SUPPORT) += drivers/usb/gadget/libusb_gadget.o +LIBS-$(CONFIG_SPL_WATCHDOG_SUPPORT) += drivers/watchdog/libwatchdog.o ifneq ($(CONFIG_AM33XX)$(CONFIG_OMAP34XX)$(CONFIG_OMAP44XX)$(CONFIG_OMAP54XX)$(CONFIG_TI814X),) LIBS-y += $(CPUDIR)/omap-common/libomap-common.o -- 1.7.11.7 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 1/4] arm, am33xx: add defines for gmii_sel_register bits
Signed-off-by: Heiko Schocher h...@denx.de
---
- changes for v2:
defined all bits used in the gmii_sel register as
Tom Rini suggested
- changes for v3:
rebased against u-boot-ti commit bb2a5d8f87fffb4fadfb205837decbd1b3e75f88
---
arch/arm/include/asm/arch-am33xx/cpu.h | 21 +
board/isee/igep0033/board.c| 6 ++
board/phytec/pcm051/board.c| 2 --
board/ti/am335x/board.c| 6 +-
4 Dateien geändert, 24 Zeilen hinzugefügt(+), 11 Zeilen entfernt(-)
diff --git a/arch/arm/include/asm/arch-am33xx/cpu.h
b/arch/arm/include/asm/arch-am33xx/cpu.h
index bcb4c50..945a09b 100644
--- a/arch/arm/include/asm/arch-am33xx/cpu.h
+++ b/arch/arm/include/asm/arch-am33xx/cpu.h
@@ -336,6 +336,27 @@ struct ctrl_dev {
unsigned int resv4[4];
unsigned int miisel;/* offset 0x50 */
};
+
+/* gmii_sel register defines */
+#define GMII1_SEL_MII 0x0
+#define GMII1_SEL_RMII 0x1
+#define GMII1_SEL_RGMII0x2
+#define GMII1_SEL_NOTUSED 0x3
+#define GMII2_SEL_MII 0x0
+#define GMII2_SEL_RMII 0x4
+#define GMII2_SEL_RGMII0x8
+#define GMII2_SEL_NOTUSED 0xc
+#define RGMII1_IDMODE BIT(4)
+#define RGMII2_IDMODE BIT(5)
+#define RMII1_IO_CLK_ENBIT(6)
+#define RMII2_IO_CLK_ENBIT(7)
+
+#define MII_MODE_ENABLE(GMII1_SEL_MII | GMII2_SEL_MII)
+#define RMII_MODE_ENABLE(GMII1_SEL_RMII | GMII2_SEL_RMII)
+#define RGMII_MODE_ENABLE (GMII1_SEL_RGMII | GMII2_SEL_RGMII)
+#define RGMII_INT_DELAY(RGMII1_IDMODE | RGMII2_IDMODE)
+#define RMII_CHIPCKL_ENABLE (RMII1_IO_CLK_EN | RMII2_IO_CLK_EN)
+
#endif /* __ASSEMBLY__ */
#endif /* __KERNEL_STRICT_NAMES */
diff --git a/board/isee/igep0033/board.c b/board/isee/igep0033/board.c
index f71aaa0..bdb4745 100644
--- a/board/isee/igep0033/board.c
+++ b/board/isee/igep0033/board.c
@@ -27,9 +27,6 @@
DECLARE_GLOBAL_DATA_PTR;
-/* MII mode defines */
-#define RMII_MODE_ENABLE 0x4D
-
static struct ctrl_dev *cdev = (struct ctrl_dev *)CTRL_DEVICE_BASE;
#ifdef CONFIG_SPL_BUILD
@@ -158,7 +155,8 @@ int board_eth_init(bd_t *bis)
eth_setenv_enetaddr(ethaddr, mac_addr);
}
- writel(RMII_MODE_ENABLE, cdev-miisel);
+ writel((GMII1_SEL_RMII | GMII2_SEL_NOTUSED | RMII1_IO_CLK_EN),
+ cdev-miisel);
rv = cpsw_register(cpsw_data);
if (rv 0)
diff --git a/board/phytec/pcm051/board.c b/board/phytec/pcm051/board.c
index f3bad76..275fe82 100644
--- a/board/phytec/pcm051/board.c
+++ b/board/phytec/pcm051/board.c
@@ -31,8 +31,6 @@
DECLARE_GLOBAL_DATA_PTR;
/* MII mode defines */
-#define MII_MODE_ENABLE0x0
-#define RGMII_MODE_ENABLE 0xA
#define RMII_RGMII2_MODE_ENABLE0x49
static struct ctrl_dev *cdev = (struct ctrl_dev *)CTRL_DEVICE_BASE;
diff --git a/board/ti/am335x/board.c b/board/ti/am335x/board.c
index eac9cc9..b2bec34 100644
--- a/board/ti/am335x/board.c
+++ b/board/ti/am335x/board.c
@@ -30,10 +30,6 @@
DECLARE_GLOBAL_DATA_PTR;
-/* MII mode defines */
-#define MII_MODE_ENABLE0x0
-#define RGMII_MODE_ENABLE 0x3A
-
/* GPIO that controls power to DDR on EVM-SK */
#define GPIO_DDR_VTT_EN7
@@ -460,7 +456,7 @@ int board_eth_init(bd_t *bis)
cpsw_slaves[0].phy_if = cpsw_slaves[1].phy_if =
PHY_INTERFACE_MODE_MII;
} else {
- writel(RGMII_MODE_ENABLE, cdev-miisel);
+ writel((RGMII_MODE_ENABLE | RGMII_INT_DELAY), cdev-miisel);
cpsw_slaves[0].phy_if = cpsw_slaves[1].phy_if =
PHY_INTERFACE_MODE_RGMII;
}
--
1.7.11.7
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 3/4] arm, am335x: add watchdog support
Add TI OMAP 16xx 24xx/34xx 32KHz (non-secure) watchdog support.
Signed-off-by: Heiko Schocher h...@denx.de
Reviewed-by: Tom Rini tr...@ti.com
Cc: Albert Aribaud albert.u.b...@aribaud.net
---
- changes for v2:
- add Reviedwed-by from Tom Rini
- fixed subject
- add SPDX-License-Identifier
- changes for v3:
- add a more detailed comment, from where this file is based
- fixed SPDX-License-Identifier to GPL-2.0
- changes for v4:
rebased against u-boot-ti commit bb2a5d8f87fffb4fadfb205837decbd1b3e75f88
---
arch/arm/include/asm/arch-am33xx/cpu.h | 20 ++
drivers/watchdog/Makefile | 1 +
drivers/watchdog/omap_wdt.c| 121 +
3 Dateien geändert, 142 Zeilen hinzugefügt(+)
create mode 100644 drivers/watchdog/omap_wdt.c
diff --git a/arch/arm/include/asm/arch-am33xx/cpu.h
b/arch/arm/include/asm/arch-am33xx/cpu.h
index 945a09b..ce24080 100644
--- a/arch/arm/include/asm/arch-am33xx/cpu.h
+++ b/arch/arm/include/asm/arch-am33xx/cpu.h
@@ -53,6 +53,26 @@
#define PRM_RSTCTRL_RESET 0x01
#define PRM_RSTST_WARM_RESET_MASK 0x232
+/*
+ * Watchdog:
+ * Using the prescaler, the OMAP watchdog could go for many
+ * months before firing. These limits work without scaling,
+ * with the 60 second default assumed by most tools and docs.
+ */
+#define TIMER_MARGIN_MAX (24 * 60 * 60) /* 1 day */
+#define TIMER_MARGIN_DEFAULT 60 /* 60 secs */
+#define TIMER_MARGIN_MIN 1
+
+#define PTV0 /* prescale */
+#define GET_WLDR_VAL(secs) (0x - ((secs) * (32768/(1PTV))) + 1)
+#define WDT_WWPS_PEND_WCLR BIT(0)
+#define WDT_WWPS_PEND_WLDR BIT(2)
+#define WDT_WWPS_PEND_WTGR BIT(3)
+#define WDT_WWPS_PEND_WSPR BIT(4)
+
+#define WDT_WCLR_PRE BIT(5)
+#define WDT_WCLR_PTV_OFF 2
+
#ifndef __KERNEL_STRICT_NAMES
#ifndef __ASSEMBLY__
struct gpmc_cs {
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 7e255ce..3ade624 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -18,6 +18,7 @@ COBJS-$(CONFIG_TNETV107X_WATCHDOG) += tnetv107x_wdt.o
COBJS-$(CONFIG_S5P) += s5p_wdt.o
COBJS-$(CONFIG_XILINX_TB_WATCHDOG) += xilinx_tb_wdt.o
COBJS-$(CONFIG_BFIN_WATCHDOG) += bfin_wdt.o
+COBJS-$(CONFIG_OMAP_WATCHDOG) += omap_wdt.o
COBJS := $(COBJS-y)
SRCS := $(COBJS:.o=.c)
diff --git a/drivers/watchdog/omap_wdt.c b/drivers/watchdog/omap_wdt.c
new file mode 100644
index 000..7ea4b60
--- /dev/null
+++ b/drivers/watchdog/omap_wdt.c
@@ -0,0 +1,121 @@
+/*
+ * omap_wdt.c
+ *
+ * (C) Copyright 2013
+ * Heiko Schocher, DENX Software Engineering, h...@denx.de.
+ *
+ * SPDX-License-Identifier:GPL-2.0
+ *
+ * Based on:
+ *
+ * Watchdog driver for the TI OMAP 16xx 24xx/34xx 32KHz (non-secure) watchdog
+ *
+ * commit 2d991a164a61858012651e13c59521975504e260
+ * Author: Bill Pemberton wf...@virginia.edu
+ * Date: Mon Nov 19 13:21:41 2012 -0500
+ *
+ * watchdog: remove use of __devinit
+ *
+ * CONFIG_HOTPLUG is going away as an option so __devinit is no longer
+ * needed.
+ *
+ * Author: MontaVista Software, Inc.
+ * gda...@mvista.com or sou...@mvista.com
+ *
+ * History:
+ *
+ * 20030527: George G. Davis gda...@mvista.com
+ * Initially based on linux-2.4.19-rmk7-pxa1/drivers/char/sa1100_wdt.c
+ * (c) Copyright 2000 Oleg Drokin gr...@crimea.edu
+ * Based on SoftDog driver by Alan Cox a...@lxorguk.ukuu.org.uk
+ *
+ * Copyright (c) 2004 Texas Instruments.
+ * 1. Modified to support OMAP1610 32-KHz watchdog timer
+ * 2. Ported to 2.6 kernel
+ *
+ * Copyright (c) 2005 David Brownell
+ * Use the driver model and standard identifiers; handle bigger timeouts.
+ */
+
+#include common.h
+#include watchdog.h
+#include asm/arch/hardware.h
+#include asm/io.h
+#include asm/processor.h
+#include asm/arch/cpu.h
+
+/* Hardware timeout in seconds */
+#define WDT_HW_TIMEOUT 60
+
+static unsigned int wdt_trgr_pattern = 0x1234;
+
+void hw_watchdog_reset(void)
+{
+ struct wd_timer *wdt = (struct wd_timer *)WDT_BASE;
+
+ /* wait for posted write to complete */
+ while ((readl(wdt-wdtwwps)) WDT_WWPS_PEND_WTGR)
+ ;
+
+ wdt_trgr_pattern = ~wdt_trgr_pattern;
+ writel(wdt_trgr_pattern, wdt-wdtwtgr);
+
+ /* wait for posted write to complete */
+ while ((readl(wdt-wdtwwps) WDT_WWPS_PEND_WTGR))
+ ;
+}
+
+static int omap_wdt_set_timeout(unsigned int timeout)
+{
+ struct wd_timer *wdt = (struct wd_timer *)WDT_BASE;
+ u32 pre_margin = GET_WLDR_VAL(timeout);
+
+ /* just count up at 32 KHz */
+ while (readl(wdt-wdtwwps) WDT_WWPS_PEND_WLDR)
+ ;
+
+ writel(pre_margin, wdt-wdtwldr);
+ while (readl(wdt-wdtwwps) WDT_WWPS_PEND_WLDR)
+ ;
+
+ return 0;
+}
+
+void hw_watchdog_init(void)
+{
+ struct wd_timer *wdt = (struct wd_timer *)WDT_BASE;
+
+ /* initialize prescaler */
+ while
Re: [U-Boot] [PATCH 3/5] SPDX-License-Identifier: convert PIBS licensed files
On 07/28/2013 10:12 PM, Wolfgang Denk wrote: This commit adapts the files that were derived from PIBS (PowerPC Initialization and Boot Software) codeto using SPDX License Identifiers. So far, SPDX has not assigned an official License ID for the PIBS license yet, so this should be considered preliminary. Note that the following files contained incorrect license information: arch/powerpc/cpu/ppc4xx/4xx_uart.c arch/powerpc/cpu/ppc4xx/start.S arch/powerpc/include/asm/ppc440.h These files included, in addition to the GPL-2.0 / ibm-pibs dual license as inherited from PIBS, a GPL-2.0+ license header which was obviously incorrect. This has been removed. Signed-off-by: Wolfgang Denk w...@denx.de Cc: Stefan Roese s...@denx.de Signed-off-by: Wolfgang Denk w...@denx.de Acked-by: Stefan Roese s...@denx.de Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/5] board/esd/cpci750/mv_eth.c: Fix license
On 07/28/2013 10:12 PM, Wolfgang Denk wrote: The file header indicated that this file was GPL-2.0+, but actually the code was derived from (Marvell based) Linux source code which is only GPL-2.0. Fix this. Signed-off-by: Wolfgang Denk w...@denx.de Cc: Stefan Roese s...@denx.de Cc: Matthias Fuchs matthias.fu...@esd-electronics.com Acked-by: Stefan Roese s...@denx.de Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] cfi_flash: Add prototypes of overridable functions
On 07/30/2013 07:36 AM, Masahiro Yamada wrote: Is this patch still needed? Yes, I think so. Okay: Applied to u-boot-cfi-flash. Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Please pull u-boot-cfi-flash
Hi Tim, please pull this CFI patch: The following changes since commit 9fab4bf4cc077c21e43941866f3f2c196f28670d: powerpc/ppc4xx: Convert new gdsys files to SPDX license tags (2013-07-26 15:32:59 -0400) are available in the git repository at: git://www.denx.de/git/u-boot-cfi-flash.git master for you to fetch changes up to 6a19cc9df0ff76273cecd3cd72323a73ff44e8de: cfi_flash: Add prototypes of overridable functions (2013-07-30 09:11:54 +0200) Masahiro Yamada (1): cfi_flash: Add prototypes of overridable functions include/mtd/cfi_flash.h | 14 ++ 1 file changed, 14 insertions(+) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/4] arm, am33xx: add defines for gmii_sel_register bits
On 7/30/2013 1:23 PM, Heiko Schocher wrote:
Signed-off-by: Heiko Schocher h...@denx.de
---
- changes for v2:
defined all bits used in the gmii_sel register as
Tom Rini suggested
- changes for v3:
rebased against u-boot-ti commit bb2a5d8f87fffb4fadfb205837decbd1b3e75f88
---
arch/arm/include/asm/arch-am33xx/cpu.h | 21 +
board/isee/igep0033/board.c| 6 ++
board/phytec/pcm051/board.c| 2 --
board/ti/am335x/board.c| 6 +-
4 Dateien geändert, 24 Zeilen hinzugefügt(+), 11 Zeilen entfernt(-)
diff --git a/arch/arm/include/asm/arch-am33xx/cpu.h
b/arch/arm/include/asm/arch-am33xx/cpu.h
index bcb4c50..945a09b 100644
--- a/arch/arm/include/asm/arch-am33xx/cpu.h
+++ b/arch/arm/include/asm/arch-am33xx/cpu.h
@@ -336,6 +336,27 @@ struct ctrl_dev {
unsigned int resv4[4];
unsigned int miisel;/* offset 0x50 */
};
+
+/* gmii_sel register defines */
+#define GMII1_SEL_MII0x0
+#define GMII1_SEL_RMII 0x1
+#define GMII1_SEL_RGMII 0x2
+#define GMII1_SEL_NOTUSED0x3
NOTUSED not needed as it is not supposed to be used.
+#define GMII2_SEL_MII0x0
+#define GMII2_SEL_RMII 0x4
+#define GMII2_SEL_RGMII 0x8
+#define GMII2_SEL_NOTUSED0xc
NOTUSED not needed as it is not supposed to be used.
+#define RGMII1_IDMODEBIT(4)
+#define RGMII2_IDMODEBIT(5)
+#define RMII1_IO_CLK_EN BIT(6)
+#define RMII2_IO_CLK_EN BIT(7)
+
+#define MII_MODE_ENABLE (GMII1_SEL_MII | GMII2_SEL_MII)
+#define RMII_MODE_ENABLE(GMII1_SEL_RMII | GMII2_SEL_RMII)
+#define RGMII_MODE_ENABLE(GMII1_SEL_RGMII | GMII2_SEL_RGMII)
+#define RGMII_INT_DELAY (RGMII1_IDMODE | RGMII2_IDMODE)
+#define RMII_CHIPCKL_ENABLE (RMII1_IO_CLK_EN | RMII2_IO_CLK_EN)
+
#endif /* __ASSEMBLY__ */
#endif /* __KERNEL_STRICT_NAMES */
diff --git a/board/isee/igep0033/board.c b/board/isee/igep0033/board.c
index f71aaa0..bdb4745 100644
--- a/board/isee/igep0033/board.c
+++ b/board/isee/igep0033/board.c
@@ -27,9 +27,6 @@
DECLARE_GLOBAL_DATA_PTR;
-/* MII mode defines */
-#define RMII_MODE_ENABLE 0x4D
-
static struct ctrl_dev *cdev = (struct ctrl_dev *)CTRL_DEVICE_BASE;
#ifdef CONFIG_SPL_BUILD
@@ -158,7 +155,8 @@ int board_eth_init(bd_t *bis)
eth_setenv_enetaddr(ethaddr, mac_addr);
}
- writel(RMII_MODE_ENABLE, cdev-miisel);
+ writel((GMII1_SEL_RMII | GMII2_SEL_NOTUSED | RMII1_IO_CLK_EN),
+cdev-miisel);
rv = cpsw_register(cpsw_data);
if (rv 0)
diff --git a/board/phytec/pcm051/board.c b/board/phytec/pcm051/board.c
index f3bad76..275fe82 100644
--- a/board/phytec/pcm051/board.c
+++ b/board/phytec/pcm051/board.c
@@ -31,8 +31,6 @@
DECLARE_GLOBAL_DATA_PTR;
/* MII mode defines */
-#define MII_MODE_ENABLE 0x0
-#define RGMII_MODE_ENABLE0xA
#define RMII_RGMII2_MODE_ENABLE 0x49
static struct ctrl_dev *cdev = (struct ctrl_dev *)CTRL_DEVICE_BASE;
diff --git a/board/ti/am335x/board.c b/board/ti/am335x/board.c
index eac9cc9..b2bec34 100644
--- a/board/ti/am335x/board.c
+++ b/board/ti/am335x/board.c
@@ -30,10 +30,6 @@
DECLARE_GLOBAL_DATA_PTR;
-/* MII mode defines */
-#define MII_MODE_ENABLE 0x0
-#define RGMII_MODE_ENABLE0x3A
-
/* GPIO that controls power to DDR on EVM-SK */
#define GPIO_DDR_VTT_EN 7
@@ -460,7 +456,7 @@ int board_eth_init(bd_t *bis)
cpsw_slaves[0].phy_if = cpsw_slaves[1].phy_if =
PHY_INTERFACE_MODE_MII;
} else {
- writel(RGMII_MODE_ENABLE, cdev-miisel);
+ writel((RGMII_MODE_ENABLE | RGMII_INT_DELAY), cdev-miisel);
cpsw_slaves[0].phy_if = cpsw_slaves[1].phy_if =
PHY_INTERFACE_MODE_RGMII;
}
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-ti/master
Hi Tom, On 07/30/2013 04:21 AM, Tom Rini wrote: Hey, The following changes since commit 8b485ba12b0defa0c4ed3559789250238f8331a8: Merge branch 'u-boot/master' into u-boot-arm/master (2013-07-25 17:57:46 +0200) are available in the git repository at: git://git.denx.de/u-boot-ti.git master for you to fetch changes up to bb2a5d8f87fffb4fadfb205837decbd1b3e75f88: gpio: omap5-uevm: Configure the tca6424 gpio expander (2013-07-29 18:09:26 -0400) Andreas Bießmann (1): omap3/sys_info: fix printout of OMAP36XX L3 freqency Christian Riesch (1): da850evm: Use clrbits function with correct endianess Dan Murphy (2): gpio: tca642x: Add the tca642x gpio expander driver gpio: omap5-uevm: Configure the tca6424 gpio expander Heiko Schocher (1): net, phy, cpsw: fix gigabit register access Justin Waters (6): am335x_evm: Make NAND support modular am335x_evm: Add command line editing am335x_evm: Rework bootcmd to handle two MMC devs Add additional MLO images to .gitignore am335x_evm: Add support for eMMC environment am335x_evm: Add am335x_boneblack variant Lokesh Vutla (1): ARM: DRA7xx: Lock DPLL_GMAC Mugunthan V N (6): drivers: net: cpsw: remove hard coding bd ram for cpsw drivers: net: cpsw: Enable statistics for all port ARM: DRA7xx: Enable GMAC clock control ARM: DRA7xx: Add CPSW support to DRA7xx EVM ARM: DRA7xx: Add CPSW and MDIO pinmux support ARM: DRA7xx: Enable CPSW Ethernet support Nishanth Menon (6): omap3_beagle: remove JFFS2 support. omap3_beagle: replace uImage.beagle with generic uImage beagleboard: remove RevB support for BeagleBoard Xm omap3_beagle: enable CMD_FS_GENERIC and simplify load of image/ramdisk omap3_beagle: support findfdt and loadfdt for devicetree support omap3_beagle: support booting from zImage and device tree as last option Stefan Roese (1): arm: omap3: spl: Fix problem with 8bit NAND devices Any reason why you didn't include this patch? http://patchwork.ozlabs.org/patch/251864/ [PATCH v2 3/3] arm: omap3: Add SPL support to cm_t35 Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [IMPORTANT NOTE] License handling
Hello, Wolfgang. - New files being added to U-Boot should no longer include a multi-line license header; instead, they shall contain a single line Unique Lincense Identifier, i. e. a line like this: SPDX-License-Identifier:GPL-2.0+ I have a question about this. Does this rule apply to files imported from other projects? For example, when adding files that originate from the Linux Kernel with modification for U-Boot, should we replace the legacy license block with SPDX-License-Identifer? Or can we keep the license block untouched? Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 3/3] arm: omap3: Add SPL support to cm_t35
Add SPL U-Boot support to replace x-loader on the Compulab cm_t35
board. Currently only the 256MiB SDRAM board versions are supported.
Tested by booting via MMC and NAND.
Signed-off-by: Stefan Roese s...@denx.de
Cc: Tom Rini tr...@ti.com
Cc: Igor Grinberg grinb...@compulab.co.il
---
v3:
- Some instability of this SDRAM setup has been detected while running
Linux. Comparison with the x-loader setup showed that mcfg is configured
slightly differently here. CM_T35 needs RAS-width of 14 instead of
13. So use the define MICRON_V_MCFG_200 which implements this 14
as RAS width.
v2:
- Change CONFIG_SYS_TEXT_BASE back to 0x80008000 for x-loader
compatibility
- Change CONFIG_SPL_BSS_START_ADDR to 0x8010 to not overlap
with TEXT_BASE now
board/compulab/cm_t35/cm_t35.c | 18 +++-
include/configs/cm_t35.h | 64 --
2 files changed, 79 insertions(+), 3 deletions(-)
diff --git a/board/compulab/cm_t35/cm_t35.c b/board/compulab/cm_t35/cm_t35.c
index 3caa5be..c3d064c 100644
--- a/board/compulab/cm_t35/cm_t35.c
+++ b/board/compulab/cm_t35/cm_t35.c
@@ -105,6 +105,22 @@ static inline int splash_load_from_nand(void)
}
#endif /* CONFIG_CMD_NAND */
+#ifdef CONFIG_SPL_BUILD
+/*
+ * Routine: get_board_mem_timings
+ * Description: If we use SPL then there is no x-loader nor config header
+ * so we have to setup the DDR timings ourself on both banks.
+ */
+void get_board_mem_timings(struct board_sdrc_timings *timings)
+{
+ timings-mr = MICRON_V_MR_165;
+ timings-mcfg = MICRON_V_MCFG_200(256 20); /* raswidth 14 needed */
+ timings-ctrla = MICRON_V_ACTIMA_165;
+ timings-ctrlb = MICRON_V_ACTIMB_165;
+ timings-rfr_ctrl = SDP_3430_SDRC_RFR_CTRL_165MHz;
+}
+#endif
+
int splash_screen_prepare(void)
{
char *env_splashimage_value;
@@ -428,7 +444,7 @@ void set_muxconf_regs(void)
cm_t3730_set_muxconf();
}
-#ifdef CONFIG_GENERIC_MMC
+#if defined(CONFIG_GENERIC_MMC) !defined(CONFIG_SPL_BUILD)
int board_mmc_getcd(struct mmc *mmc)
{
u8 val;
diff --git a/include/configs/cm_t35.h b/include/configs/cm_t35.h
index 39a216e..1eb57ba 100644
--- a/include/configs/cm_t35.h
+++ b/include/configs/cm_t35.h
@@ -25,8 +25,6 @@
#define CONFIG_OMAP_GPIO
#define CONFIG_CM_T3X /* working with CM-T35 and CM-T3730 */
-#define CONFIG_SYS_TEXT_BASE 0x80008000
-
#define CONFIG_SDRC/* The chip has SDRC controller */
#include asm/arch/cpu.h /* get chip and board defs */
@@ -325,4 +323,66 @@
#define CONFIG_CMD_BMP
#define CONFIG_BMP_16BPP
+/* Defines for SPL */
+#define CONFIG_SPL
+#define CONFIG_SPL_FRAMEWORK
+#define CONFIG_SPL_NAND_SIMPLE
+
+#define CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR0x300 /* address
0x6 */
+#define CONFIG_SYS_U_BOOT_MAX_SIZE_SECTORS 0x200 /* 256 KB */
+#define CONFIG_SYS_MMC_SD_FAT_BOOT_PARTITION 1
+#define CONFIG_SPL_FAT_LOAD_PAYLOAD_NAME u-boot.img
+
+#define CONFIG_SPL_BOARD_INIT
+#define CONFIG_SPL_LIBCOMMON_SUPPORT
+#define CONFIG_SPL_LIBDISK_SUPPORT
+#define CONFIG_SPL_I2C_SUPPORT
+#define CONFIG_SPL_LIBGENERIC_SUPPORT
+#define CONFIG_SPL_MMC_SUPPORT
+#define CONFIG_SPL_FAT_SUPPORT
+#define CONFIG_SPL_SERIAL_SUPPORT
+#define CONFIG_SPL_NAND_SUPPORT
+#define CONFIG_SPL_NAND_BASE
+#define CONFIG_SPL_NAND_DRIVERS
+#define CONFIG_SPL_NAND_ECC
+#define CONFIG_SPL_GPIO_SUPPORT
+#define CONFIG_SPL_POWER_SUPPORT
+#define CONFIG_SPL_OMAP3_ID_NAND
+#define CONFIG_SPL_LDSCRIPT$(CPUDIR)/omap-common/u-boot-spl.lds
+
+/* NAND boot config */
+#define CONFIG_SYS_NAND_5_ADDR_CYCLE
+#define CONFIG_SYS_NAND_PAGE_COUNT 64
+#define CONFIG_SYS_NAND_PAGE_SIZE 2048
+#define CONFIG_SYS_NAND_OOBSIZE64
+#define CONFIG_SYS_NAND_BLOCK_SIZE (128 * 1024)
+#define CONFIG_SYS_NAND_BAD_BLOCK_POS NAND_LARGE_BADBLOCK_POS
+/*
+ * Use the ECC/OOB layout from omap_gpmc.h that matches your chip:
+ * SP vs LP, 8bit vs 16bit: GPMC_NAND_HW_ECC_LAYOUT
+ */
+#define CONFIG_SYS_NAND_ECCPOS { 1, 2, 3, 4, 5, 6, 7, 8, 9, \
+10, 11, 12 }
+#define CONFIG_SYS_NAND_ECCSIZE512
+#define CONFIG_SYS_NAND_ECCBYTES 3
+
+#define CONFIG_SYS_NAND_U_BOOT_START CONFIG_SYS_TEXT_BASE
+#define CONFIG_SYS_NAND_U_BOOT_OFFS0x8
+
+#define CONFIG_SPL_TEXT_BASE 0x40200800
+#define CONFIG_SPL_MAX_SIZE(54 * 1024) /* 8 KB for stack */
+#define CONFIG_SPL_STACK LOW_LEVEL_SRAM_STACK
+
+/*
+ * Use 0x80008000 as TEXT_BASE here for compatibility reasons with the
+ * older x-loader implementations. And move the BSS area so that it
+ * doesn't overlap with TEXT_BASE.
+ */
+#define CONFIG_SYS_TEXT_BASE 0x80008000
+#define CONFIG_SPL_BSS_START_ADDR 0x8010
+#define CONFIG_SPL_BSS_MAX_SIZE0x8 /* 512 KB */
+
+#define CONFIG_SYS_SPL_MALLOC_START0x80208000
+#define CONFIG_SYS_SPL_MALLOC_SIZE 0x10
+
#endif /*
Re: [U-Boot] [IMPORTANT NOTE] License handling
Dear Masahiro Yamada, In message 20130730195026.79dc.aa925...@jp.panasonic.com you wrote: Does this rule apply to files imported from other projects? Yes, it does. The whole process only makes sense when all files in the U-Boot source tree can be identified based on the SPDX ID strings. For example, when adding files that originate from the Linux Kernel with modification for U-Boot, should we replace the legacy license block with SPDX-License-Identifer? Yes, please do. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Real programmers don't comment their code. It was hard to write, it should be hard to understand. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [IMPORTANT NOTE] License handling
Hi Masahiro On Tue, Jul 30, 2013 at 8:50 PM, Masahiro Yamada yamad...@jp.panasonic.comwrote: Hello, Wolfgang. - New files being added to U-Boot should no longer include a multi-line license header; instead, they shall contain a single line Unique Lincense Identifier, i. e. a line like this: SPDX-License-Identifier:GPL-2.0+ I have a question about this. Does this rule apply to files imported from other projects? For example, when adding files that originate from the Linux Kernel with modification for U-Boot, should we replace the legacy license block with SPDX-License-Identifer? Or can we keep the license block untouched I kind of raised this before - SPDX is not only a way of simplifying the license text, but also to provide a 'chain of authenticity'. The idea would be to reduce the license text in U-Boot to just the SPDX-License-Identifier, but we should also provide details on where the original file came from. I guess this is the next (harder) step. Wolfgang: How do you think this should be best handled? I still haven't found a definitive reference for the use of SPDX-License-Identifier - are there other identifiers which can be used to specify the original source of the file? Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 4/7] ARM: switch to non-secure state during bootm execution
On 07/30/2013 12:02 AM, Christoffer Dall wrote:
On Wed, Jul 10, 2013 at 01:54:16AM +0200, Andre Przywara wrote:
[...]
diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c
index 1b6e0ac..7b0619e 100644
--- a/arch/arm/lib/bootm.c
+++ b/arch/arm/lib/bootm.c
@@ -34,6 +34,10 @@
#include asm/bootm.h
#include linux/compiler.h
+#ifdef CONFIG_ARMV7_NONSEC
+#include asm/armv7.h
+#endif
+
DECLARE_GLOBAL_DATA_PTR;
static struct tag *params;
@@ -186,6 +190,29 @@ static void setup_end_tag(bd_t *bd)
__weak void setup_board_tags(struct tag **in_params) {}
+static void do_nonsec_virt_switch(void)
+{
+#ifdef CONFIG_ARMV7_NONSEC
+ int ret;
+
+ ret = armv7_switch_nonsec();
+ switch (ret) {
+ case NONSEC_VIRT_SUCCESS:
+ debug(entered non-secure state\n);
+ break;
+ case NONSEC_ERR_NO_SEC_EXT:
+ printf(nonsec: Security extensions not implemented.\n);
+ break;
+ case NONSEC_ERR_NO_GIC_ADDRESS:
+ printf(nonsec: could not determine GIC address.\n);
+ break;
+ case NONSEC_ERR_GIC_ADDRESS_ABOVE_4GB:
+ printf(nonsec: PERIPHBASE is above 4 GB, no access.\n);
+ break;
+ }
+#endif
+}
I still don't get why you just don't make armv7_switch_nonsec a void and
print the error when they occur... ???
My apologies for not elaborating on these comments I didn't incorporate:
So, I don't like the idea of marrying a low-level routine with high
level output. I don't want to constraint the usage of the routine by
requiring an output channel. Also some parts may not be fatal for all
users - someone could just try to switch and then behave differently if
that failed - without bothering the user.
May seem a bit over-engineered, but I like it better this way ;-)
If that is a show-stopper for you, I can change it, of course.
Regards,
Andre.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 2/7] ARM: add secure monitor handler to switch to non-secure state
On 07/30/2013 12:02 AM, Christoffer Dall wrote: n Wed, Jul 10, 2013 at 01:54:14AM +0200, Andre Przywara wrote: A prerequisite for using virtualization is to be in HYP mode, which requires the CPU to be in non-secure state first. Add new file in arch/arm/cpu/armv7 to hold a monitor handler routine which switches the CPU to non-secure state by setting the NS and associated bits. According to the ARM architecture reference manual this should not be done in SVC mode, so we have to setup a SMC handler for this. We create a new vector table to avoid interference with other boards. The MVBAR register will be programmed later just before the smc call. Signed-off-by: Andre Przywara andre.przyw...@linaro.org --- arch/arm/cpu/armv7/Makefile | 4 +++ arch/arm/cpu/armv7/nonsec_virt.S | 54 2 files changed, 58 insertions(+) create mode 100644 arch/arm/cpu/armv7/nonsec_virt.S diff --git a/arch/arm/cpu/armv7/Makefile b/arch/arm/cpu/armv7/Makefile index 7a8c2d0..5d75077 100644 --- a/arch/arm/cpu/armv7/Makefile +++ b/arch/arm/cpu/armv7/Makefile @@ -36,6 +36,10 @@ ifneq ($(CONFIG_AM33XX)$(CONFIG_OMAP44XX)$(CONFIG_OMAP54XX)$(CONFIG_TEGRA)$(CONF SOBJS += lowlevel_init.o endif +ifneq ($(CONFIG_ARMV7_NONSEC),) +SOBJS += nonsec_virt.o +endif + SRCS := $(START:.o=.S) $(COBJS:.o=.c) OBJS := $(addprefix $(obj),$(COBJS) $(SOBJS)) START := $(addprefix $(obj),$(START)) diff --git a/arch/arm/cpu/armv7/nonsec_virt.S b/arch/arm/cpu/armv7/nonsec_virt.S new file mode 100644 index 000..68a6b38 --- /dev/null +++ b/arch/arm/cpu/armv7/nonsec_virt.S @@ -0,0 +1,54 @@ +/* + * code for switching cores into non-secure state + * + * Copyright (c) 2013 Andre Przywara andre.przyw...@linaro.org + * + * See file CREDITS for list of people who contributed to this + * project. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of + * the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, + * MA 02111-1307 USA + */ + +#include config.h + +/* the vector table for secure state */ +_monitor_vectors: + .word 0 /* reset */ + .word 0 /* undef */ + adr pc, _secure_monitor + .word 0 + .word 0 + .word 0 + .word 0 + .word 0 + .word 0 /* pad */ + +/* + * software interrupt aka. secure monitor handler a software interrupt is not aka. a secure monitor handler, this is misleading, it's just the smc handler. I agree, but I wanted to stick to the u-boot nomenclature which uses software interrupt for that exception in arch/arm/cpu/armv7/start.S. So I used both names to make it more clear to the u-boot reader. If I make a newer version, I will fix it in there. Regards, Andre. + * This is executed on a smc instruction, we use a smc #0 to switch + * to non-secure state. + * We use only r0 and r1 here, due to constraints in the caller. + */ + .align 5 +_secure_monitor: + mrc p15, 0, r1, c1, c1, 0 @ read SCR + bic r1, r1, #0x4e @ clear IRQ, FIQ, EA, nET bits + orr r1, r1, #0x31 @ enable NS, AW, FW bits + + mcr p15, 0, r1, c1, c1, 0 @ write SCR (with NS bit set) + + movspc, lr @ return to non-secure SVC + -- 1.7.12.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 5/7] ARM: add SMP support for non-secure switch
On 07/30/2013 12:02 AM, Christoffer Dall wrote:
On Wed, Jul 10, 2013 at 01:54:17AM +0200, Andre Przywara wrote:
Currently the non-secure switch is only done for the boot processor.
To enable full SMP support, we have to switch all secondary cores
into non-secure state also.
So we add an entry point for secondary CPUs coming out of low-power
state and make sure we put them into WFI again after having switched
to non-secure state.
For this we acknowledge and EOI the wake-up IPI, then go into WFI.
Once being kicked out of it later, we sanity check that the start
address has actually been changed (since another attempt to switch
to non-secure would block the core) and jump to the new address.
The actual CPU kick is done by sending an inter-processor interrupt
via the GIC to all CPU interfaces except the requesting processor.
The secondary cores will then setup their respective GIC CPU
interface.
The address secondary cores jump to is board specific, we provide
the value here for the Versatile Express board.
Signed-off-by: Andre Przywara andre.przyw...@linaro.org
---
arch/arm/cpu/armv7/nonsec_virt.S| 27 +++
arch/arm/cpu/armv7/virt-v7.c| 19 ++-
arch/arm/include/asm/armv7.h| 1 +
arch/arm/include/asm/gic.h | 2 ++
include/configs/vexpress_ca15_tc2.h | 3 +++
5 files changed, 51 insertions(+), 1 deletion(-)
diff --git a/arch/arm/cpu/armv7/nonsec_virt.S b/arch/arm/cpu/armv7/nonsec_virt.S
index e9ee831..f9b6b39 100644
--- a/arch/arm/cpu/armv7/nonsec_virt.S
+++ b/arch/arm/cpu/armv7/nonsec_virt.S
@@ -58,6 +58,33 @@ _secure_monitor:
movspc, lr @ return to non-secure SVC
/*
+ * Secondary CPUs start here and call the code for the core specific parts
+ * of the non-secure and HYP mode transition. The GIC distributor specific
+ * code has already been executed by a C function before.
+ * Then they go back to wfi and wait to be woken up by the kernel again.
+ */
+ENTRY(_smp_pen)
+ mrs r0, cpsr
+ orr r0, r0, #0xc0
+ msr cpsr, r0@ disable interrupts
+ ldr r1, =_start
+ mcr p15, 0, r1, c12, c0, 0 @ set VBAR
+
+ bl _nonsec_init
+
+ ldr r1, [r0, #GICC_IAR] @ acknowledge IPI
+ str r1, [r0, #GICC_EOIR]@ signal end of interrupt
+ adr r1, _smp_pen
+waitloop:
+ wfi
+ ldr r0, =CONFIG_SYSFLAGS_ADDR @ load start address
You seem to have ignored my comment about using the sysflags name?
As I understand, the sysflags name is a versatile express specific
register name that just happens to be used for the SMP boot address as
well...
Therefore, this should really be CONFIG_SMP_BOOT_ADDR or something like
that, at the very least.
+ ldr r0, [r0]
+ cmp r0, r1 @ make sure we dont execute this code
+ beq waitloop@ again (due to a spurious wakeup)
+ mov pc, r0
+ENDPROC(_smp_pen)
+
+/*
* Switch a core to non-secure state.
*
* 1. initialize the GIC per-core interface
diff --git a/arch/arm/cpu/armv7/virt-v7.c b/arch/arm/cpu/armv7/virt-v7.c
index 54f9746..a0d0b34 100644
--- a/arch/arm/cpu/armv7/virt-v7.c
+++ b/arch/arm/cpu/armv7/virt-v7.c
@@ -77,6 +77,21 @@ static int get_gicd_base_address(unsigned int *gicdaddr)
#endif
}
+static void kick_secondary_cpus(unsigned int gicdaddr)
+{
+ unsigned int *secondary_boot_addr;
+
+ secondary_boot_addr = (void *)CONFIG_SYSFLAGS_ADDR;
+#ifdef CONFIG_SYSFLAGS_NEED_CLEAR_BITS
+ secondary_boot_addr[1] = (unsigned)-1;
+#endif
again, if you disagreed with my previous comment, please comment on it
and rationalize your choice.
I am sorry, I thought I reasoned that already in an earlier mail:
I don't want to introduce abstraction prematurely, so I wanted to
refactor the code as soon as a second board gets supported. Which will
probably be the Arndale, and also probably done by me ...
I still feel you're wrapping board specific logic into generic code, and
that you should call out to a more generic function. Imagine an SOC
that uses an implementation defined control register for this instead of
a memory address...
Well, I can imagine quite some ways to do this, but in fact I'd like to
focus on things that really exist ;-)
My fear is that any abstraction I introduce now will not suffice for a
future board and needs to be refactored then anyway.
Regards,
Andre.
perhaps what you need is:
void set_board_smp_boot_addr(unsigned long addr);
unsigned long get_board_smp_boot_addr(void);
and call these instead of your direct use of sysflags addr here...?
+ *secondary_boot_addr = (uintptr_t)_smp_pen;
+ dmb();
+
+ /* now kick all CPUs (except this one) by writing to GICD_SGIR */
+ writel(1U 24, gicdaddr + GICD_SGIR);
+}
+
enum nonsec_virt_errors armv7_switch_nonsec(void)
{
Re: [U-Boot] [PATCH v3 6/7] ARM: extend non-secure switch to also go into HYP mode
On 07/30/2013 12:02 AM, Christoffer Dall wrote: On Wed, Jul 10, 2013 at 01:54:18AM +0200, Andre Przywara wrote: For the KVM and XEN hypervisors to be usable, we need to enter the kernel in HYP mode. Now that we already are in non-secure state, HYP mode switching is within short reach. While doing the non-secure switch, we have to enable the HVC instruction and setup the HYP mode HVBAR (while still secure). The actual switch is done by dropping back from a HYP mode handler without actually leaving HYP mode, so we introduce a new handler routine in our new secure exception vector table. In the assembly switching routine we save and restore the banked LR and SP registers around the hypercall to do the actual HYP mode switch. The C routine first checks whether we are in HYP mode already and also whether the virtualization extensions are available. It also checks whether the HYP mode switch was finally successful. The bootm command part only adds and adjusts some error reporting. Signed-off-by: Andre Przywara andre.przyw...@linaro.org --- arch/arm/cpu/armv7/Makefile | 2 +- arch/arm/cpu/armv7/nonsec_virt.S | 43 +++- arch/arm/cpu/armv7/virt-v7.c | 31 + arch/arm/include/asm/armv7.h | 9 +++-- arch/arm/lib/bootm.c | 19 +++--- 5 files changed, 93 insertions(+), 11 deletions(-) diff --git a/arch/arm/cpu/armv7/Makefile b/arch/arm/cpu/armv7/Makefile index b59f59e..e5eaa56 100644 --- a/arch/arm/cpu/armv7/Makefile +++ b/arch/arm/cpu/armv7/Makefile @@ -36,7 +36,7 @@ ifneq ($(CONFIG_AM33XX)$(CONFIG_OMAP44XX)$(CONFIG_OMAP54XX)$(CONFIG_TEGRA)$(CONF SOBJS += lowlevel_init.o endif -ifneq ($(CONFIG_ARMV7_NONSEC),) +ifneq ($(CONFIG_ARMV7_NONSEC)$(CONFIG_ARMV7_VIRT),) SOBJS += nonsec_virt.o COBJS += virt-v7.o endif diff --git a/arch/arm/cpu/armv7/nonsec_virt.S b/arch/arm/cpu/armv7/nonsec_virt.S index f9b6b39..895c3b0 100644 --- a/arch/arm/cpu/armv7/nonsec_virt.S +++ b/arch/arm/cpu/armv7/nonsec_virt.S @@ -1,5 +1,5 @@ /* - * code for switching cores into non-secure state + * code for switching cores into non-secure state and into HYP mode * * Copyright (c) 2013 Andre Przywara andre.przyw...@linaro.org * @@ -28,15 +28,16 @@ #include asm/armv7.h .arch_extension sec +.arch_extension virt -/* the vector table for secure state */ +/* the vector table for secure state and HYP mode */ _monitor_vectors: .word 0 /* reset */ .word 0 /* undef */ adr pc, _secure_monitor .word 0 .word 0 - .word 0 + adr pc, _hyp_trap .word 0 .word 0 .word 0 /* pad */ @@ -53,10 +54,27 @@ _secure_monitor: bic r1, r1, #0x4e @ clear IRQ, FIQ, EA, nET bits orr r1, r1, #0x31 @ enable NS, AW, FW bits +#ifdef CONFIG_ARMV7_VIRT + mrc p15, 0, r0, c0, c1, 1 @ read ID_PFR1 + and r0, r0, #CPUID_ARM_VIRT_MASK@ mask virtualization bits + cmp r0, #(1 CPUID_ARM_VIRT_SHIFT) + orreq r1, r1, #0x100 @ allow HVC instruction +#endif + mcr p15, 0, r1, c1, c1, 0 @ write SCR (with NS bit set) +#ifdef CONFIG_ARMV7_VIRT + mrceq p15, 0, r0, c12, c0, 1 @ get MVBAR value + mcreq p15, 4, r0, c12, c0, 0 @ write HVBAR +#endif + movspc, lr @ return to non-secure SVC +_hyp_trap: + mrs lr, elr_hyp @ for older asm: .byte 0x00, 0xe3, 0x0e, 0xe1 this comment just confuses: either make it intelligent to support an older compiler or just get rid of these byte encodings. You can always disassemble the file and lookup the byte code with a modern compiler to get back to the byte encoding. Well, I used a Debian 6 cross compiler before, which didn't support these instructions. After your remark I updated the system to Debian 7, but found it not appropriate to ask any user to do the same just to use a fixed, non-parametrized assembly instruction. I have the feeling that there are quite some users out there who cannot and don't want to easily update their compiler. So I decided to leave the workaround in the comment to give a hint to a quick fix. By making it intelligent you mean a macro which does some version checking and inserts the .byte sequence if needed? Are there any archetypes of such code? Regards, Andre. + mov pc, lr @ do no switch modes, but + @ return to caller + /* * Secondary CPUs start here and call the code for the core specific parts * of the non-secure and HYP mode transition. The GIC distributor specific @@ -71,9 +89,13 @@ ENTRY(_smp_pen) mcr p15, 0, r1, c12, c0, 0 @ set VBAR bl _nonsec_init + mov r12, r0 @ save GICC address +#ifdef
Re: [U-Boot] [PATCH] config.mk: Add -Wundef to CFLAGS
Hi Masahiro, On Tue, 30 Jul 2013 11:57:05 +0900, Masahiro Yamada yamad...@jp.panasonic.com wrote: In U-boot source, some '#if' directives evaluate undefined identifiers. To find and fix them, this commit adds -Wundef to CFLAGS. Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com --- config.mk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/config.mk b/config.mk index f71e145..7a92ae3 100644 --- a/config.mk +++ b/config.mk @@ -259,7 +259,7 @@ CPPFLAGS += -I$(TOPDIR)/include CPPFLAGS += -fno-builtin -ffreestanding -nostdinc\ -isystem $(gccincdir) -pipe $(PLATFORM_CPPFLAGS) -CFLAGS := $(CPPFLAGS) -Wall -Wstrict-prototypes +CFLAGS := $(CPPFLAGS) -Wall -Wstrict-prototypes -Wundef ifdef BUILD_TAG CFLAGS += -DBUILD_TAG='$(BUILD_TAG)' Will the patch cause some targets to break? If so, then I personally would prefer that fixes be provided for at least the trivial cases. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/3] arm: omap3: Add SPL support to cm_t35
Hi Stefan, On Tue, 30 Jul 2013 12:52:10 +0200, Stefan Roese s...@denx.de wrote: Add SPL U-Boot support to replace x-loader on the Compulab cm_t35 board. Currently only the 256MiB SDRAM board versions are supported. Tested by booting via MMC and NAND. Signed-off-by: Stefan Roese s...@denx.de Cc: Tom Rini tr...@ti.com Cc: Igor Grinberg grinb...@compulab.co.il --- v3: - Some instability of this SDRAM setup has been detected while running Linux. Comparison with the x-loader setup showed that mcfg is configured slightly differently here. CM_T35 needs RAS-width of 14 instead of 13. So use the define MICRON_V_MCFG_200 which implements this 14 as RAS width. v2: I assume this means that your request to Tom about PRing V2 is withdrawn and I can apply his PR as-is. Correct? Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [IMPORTANT NOTE] License handling
Dear Graeme Russ, In message CALButCK063=8_5pw8fdkhgo8v4wc7sukdolpasovs-dop_k...@mail.gmail.com you wrote: The idea would be to reduce the license text in U-Boot to just the SPDX-License-Identifier, but we should also provide details on where the original file came from. I guess this is the next (harder) step. Full agreement here. But actually this has been a requirement for some time already, see section Attributing Code, Copyrights, Signing (and especially bullet # 4 there) at [1] [1] http://www.denx.de/wiki/view/U-Boot/Patches#Attributing_Code_Copyrights_Sign OK, this records such information in the git history, but that's better than nothing. Wolfgang: How do you think this should be best handled? I still haven't found a definitive reference for the use of SPDX-License-Identifier - are there other identifiers which can be used to specify the original source of the file? Well, in my (definitely limited) understanding of the SPDX specification the sourceInfo property appears to be the best fit for such information - so we could for example define entries SPDX-Source-Info which could contain this - in a T.B.D. format ? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de You can't depend on your eyes when your imagination is out of focus. - Mark Twain ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/3] arm: omap3: Add SPL support to cm_t35
Hi Albert, On 07/30/2013 02:10 PM, Albert ARIBAUD wrote: Add SPL U-Boot support to replace x-loader on the Compulab cm_t35 board. Currently only the 256MiB SDRAM board versions are supported. Tested by booting via MMC and NAND. Signed-off-by: Stefan Roese s...@denx.de Cc: Tom Rini tr...@ti.com Cc: Igor Grinberg grinb...@compulab.co.il --- v3: - Some instability of this SDRAM setup has been detected while running Linux. Comparison with the x-loader setup showed that mcfg is configured slightly differently here. CM_T35 needs RAS-width of 14 instead of 13. So use the define MICRON_V_MCFG_200 which implements this 14 as RAS width. v2: I assume this means that your request to Tom about PRing V2 is withdrawn and I can apply his PR as-is. Correct? Yes. Please go ahead and pull. We can apply this patch at a later time. Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] RNG implementation fails
HI,
I wanted to include a RNG implementation of the Mersenne-Twister into
the SPL part of u-boot. However, although the (standalone) code compiles
and runs fine on my linux box, u-boot stops to boot and I am not sure
why. I am sure I am missing a rather basic design principle of the
u-boot code but I can't figure which.
SPL stops booting at the twisted feedback line in function genrand_int32().
Here is the code of the hwinit-common.h in arch/arm/cpu/armv7/omap-common/:
#include common.h
#include asm/io.h
#include asm/arch/sys_proto.h
#include asm/sizes.h
#include asm/emif.h
#include asm/omap_common.h
/* Period parameters */
#define N 624
#define M 397
#define MATRIX_A 0x9908b0dfUL /* constant vector a */
#define UPPER_MASK 0x8000UL /* most significant w-r bits */
#define LOWER_MASK 0x7fffUL /* least significant r bits */
static unsigned long x[N]; /* the array for the state vector */
static unsigned long *p0, *p1, *pm;
DECLARE_GLOBAL_DATA_PTR;
/*
initialize MT with a seed
*/
void init_genrand(unsigned long s)
{
int i;
x[0] = s 0xUL;
for (i = 1; i N; ++i) {
x[i] = (1812433253UL * (x[i - 1] ^ (x[i - 1] 30)) + i)
0xUL; /* for 32 bit machines */
}
p0 = x;
p1 = x + 1;
pm = x + M;
}
/*
initialize by an array with array-length
init_key is the array for initializing keys
key_length is its length
*/
void init_by_array(unsigned long init_key[], int key_length)
{
int i, j, k;
init_genrand(19650218UL);
i = 1;
j = 0;
for (k = (N key_length ? N : key_length); k; --k) {
/* non linear */
x[i] = ((x[i] ^ ((x[i - 1] ^ (x[i - 1] 30)) * 1664525UL))
+ init_key[j] + j) 0xUL; /* for WORDSIZE 32
machines */
if (++i = N) {
x[0] = x[N - 1];
i = 1;
}
if (++j = key_length) {
j = 0;
}
}
for (k = N - 1; k; --k) {
/* non linear */
x[i] = ((x[i] ^ ((x[i - 1] ^ (x[i - 1] 30)) * 1566083941UL)) - i)
0xUL; /* for WORDSIZE 32 machines */
if (++i = N) {
x[0] = x[N - 1];
i = 1;
}
}
x[0] = 0x8000UL; /* MSB is 1; assuring non-zero initial
array */
}
/* generates a random number on the interval [0,0x] */
unsigned long genrand_int32(void)
{
unsigned long y;
if (!p0) {
/* Default seed */
init_genrand(5489UL);
}
/* Twisted feedback -- HERE WE GET STUCK*/
y = *p0 = *pm++ ^ (((*p0 UPPER_MASK) | (*p1 LOWER_MASK)) 1)
^ (-(*p1 1) MATRIX_A);
p0 = p1++;
if (pm == x + N) {
pm = x;
}
if (p1 == x + N) {
p1 = x;
}
/* Temper */
y ^= y 11;
y ^= y 7 0x9d2c5680UL;
y ^= y 15 0xefc6UL;
y ^= y 18;
return y;
}
void do_set_mux(u32 base, struct pad_conf_entry const *array, int size)
{
int i;
struct pad_conf_entry *pad = (struct pad_conf_entry *) array;
for (i = 0; i size; i++, pad++)
writew(pad-val, base + pad-offset);
}
static void set_mux_conf_regs(void)
{
switch (omap_hw_init_context()) {
case OMAP_INIT_CONTEXT_SPL:
set_muxconf_regs_essential();
break;
case OMAP_INIT_CONTEXT_UBOOT_AFTER_SPL:
#ifdef CONFIG_SYS_ENABLE_PADS_ALL
set_muxconf_regs_non_essential();
#endif
break;
case OMAP_INIT_CONTEXT_UBOOT_FROM_NOR:
case OMAP_INIT_CONTEXT_UBOOT_AFTER_CH:
set_muxconf_regs_essential();
#ifdef CONFIG_SYS_ENABLE_PADS_ALL
set_muxconf_regs_non_essential();
#endif
break;
}
}
u32 cortex_rev(void)
{
unsigned int rev;
/* Read Main ID Register (MIDR) */
asm (mrc p15, 0, %0, c0, c0, 0 : =r (rev));
return rev;
}
void omap_rev_string(void)
{
u32 omap_rev = omap_revision();
u32 omap_variant = (omap_rev 0x) 16;
u32 major_rev = (omap_rev 0x0F00) 8;
u32 minor_rev = (omap_rev 0x00F0) 4;
printf(OMAP%x ES%x.%x\n, omap_variant, major_rev,
minor_rev);
}
#ifdef CONFIG_SPL_BUILD
static void init_boot_params(void)
{
boot_params_ptr = (u32 *) boot_params;
}
#endif
/*
* Routine: s_init
* Description: Does early system init of watchdog, muxing, andclocks
* Watchdog disable is done always. For the rest what gets done
* depends on the boot mode in which this function is executed
* 1. s_init of SPL running from SRAM
* 2. s_init of U-Boot running from FLASH
* 3. s_init of U-Boot loaded to SDRAM by SPL
* 4. s_init of U-Boot loaded to SDRAM by ROM code using the
*Configuration Header feature
* Please have a look at the respective functions to see what gets
* done in each of these cases
* This function is called with SRAM stack.
*/
void s_init(void)
{
init_omap_revision();
watchdog_init();
set_mux_conf_regs();
#ifdef CONFIG_SPL_BUILD
setup_clocks_for_console();
preloader_console_init();
unsigned char current_rn_char;
unsigned long current_rn;
int i = 0;
unsigned long init[4] = { 0x123, 0x234, 0x345, 0x456 }, length = 4;
// Start PRNG
Re: [U-Boot] [PATCH v2 0/6] Enhance support for BeagleBone Black
On Thu, Jul 11, 2013 at 09:54:57AM -0400, Justin Waters wrote: There are a number of differences between the BeagleBone Black and other AM335x boards that require some modification of the default AM335x EVM configuration. In particular, it lacks NAND flash, has multiple MMC interfaces, and can store its environment in an unused eMMC partition. The following patch set improves the out-of-box experience on the BeagleBone Black by making the AM335x EVM configuration more modular, and adding a few additional features. Changes from v1: * Reordered the patches * Broke out the beagleboard target addition into a seperate patch so that it is independent of the other changes * Reversed the NAND logic- rather than using a new token, NO_NAND, I simply define NAND in the configurations for the other boards. * Fixed some bugs introduced by my mmcboot modifications Justin Waters (6): am335x_evm: Make NAND support modular am335x_evm: Add command line editing am335x_evm: Rework bootcmd to handle two MMC devs Add additional MLO images to .gitignore am335x_evm: Add support for eMMC environment am335x_evm: Add am335x_boneblack variant .gitignore |2 +- boards.cfg | 17 +++ include/configs/am335x_evm.h | 101 ++ 3 files changed, 72 insertions(+), 48 deletions(-) Applied to u-boot-ti/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, 2/3] arm: omap3: spl: Fix problem with 8bit NAND devices
On Fri, Jun 14, 2013 at 10:55:00AM +0200, Stefan Roese wrote: Currently in OMAP3 SPL, the GPMC for NAND is configured for 16bit access. This patch adds support for 8bit NAND devices as well. Signed-off-by: Stefan Roese s...@denx.de Cc: Tom Rini tr...@ti.com Applied to u-boot-ti/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] da850evm: Use clrbits function with correct endianess
On Fri, Jun 14, 2013 at 02:22:36PM +0200, Christian Riesch wrote: The current code uses clrbits_be32 which is incorrect since we are on a little endian machine here. This patch fixes this issue and also removes some unnecessary code: Reading the current GPIO bank state is not required if we are using the SET and CLEAR GPIO registers for setting/clearing bits. Signed-off-by: Christian Riesch christian.rie...@omicron.at Cc: Nagabhushana Netagunte nagabhushana.netagu...@ti.com Cc: Rajashekhara, Sudhakar sudhakar@ti.com Applied to u-boot-ti/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] spl_mmc.c: Detect missing kernel image in RAW MMC
On Fri, Jun 28, 2013 at 02:43:01PM -0400, Tom Rini wrote: Currently, we assume that if we can read from MMC correctly, we have found a valid image. This is not the case as an empty area will read just fine. Add a check for a valid IH_MAGIC. Signed-off-by: Tom Rini tr...@ti.com Reviewed-by: Peter Korsgaard jac...@sunsite.dk Applied to u-boot-ti/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/7] Ethernet bringup patchset for DRA7xx EVM
On Mon, Jul 08, 2013 at 04:04:36PM +0530, Mugunthan V N wrote: This patch series brings up the CPSW ethernet in DRA7xx EVM and it is based on the master branch on git://git.denx.de/u-boot.git This patch is also tested with basic boot of Omap 5 and tftp download test with AM335x EVM. Lokesh Vutla (1): ARM: DRA7xx: Lock DPLL_GMAC Mugunthan V N (6): drivers: net: cpsw: remove hard coding bd ram for cpsw drivers: net: cpsw: Enable statistics for all port ARM: DRA7xx: Enable GMAC clock control ARM: DRA7xx: Add CPSW support to DRA7xx EVM ARM: DRA7xx: Add CPSW and MDIO pinmux support ARM: DRA7xx: Enable CPSW Ethernet support arch/arm/cpu/armv7/omap-common/clocks-common.c | 18 +++ arch/arm/cpu/armv7/omap5/hw_data.c | 18 ++- arch/arm/cpu/armv7/omap5/prcm-regs.c |7 ++ arch/arm/include/asm/arch-omap5/cpu.h |6 + arch/arm/include/asm/arch-omap5/omap.h | 26 arch/arm/include/asm/omap_common.h | 10 ++ board/ti/am335x/board.c|1 + board/ti/dra7xx/evm.c | 150 +++- board/ti/dra7xx/mux_data.h | 14 +++ board/ti/ti814x/evm.c |1 + drivers/net/cpsw.c |5 +- include/configs/dra7xx_evm.h | 19 +++ include/cpsw.h |1 + 13 files changed, 267 insertions(+), 9 deletions(-) Applied to u-boot-ti/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/5] Improve falcon mode and am335x_evm docs
On Mon, Jul 08, 2013 at 12:15:13PM -0400, Tom Rini wrote: Hey all, The following 5 patches update docs for falcon mode, and am335x_evm. The first adds a quick general note about how failure is decided in falcon mode and we drop back to U-Boot. The rest update slightly, and then document, falcon mode for am335x_evm by providing examples for eMMC or raw SD cards, FAT SD cards and NAND and provide some general information setting up falcon mode. In the updates side, the DFU info to be able to write the falcon mode areas is added and corrects a small bug in the NAND configuration for falcon mode. I did this in part because while I found doc/README.falcon helpful we still want to provide board-specific examples when possible I believe. And, as has been pointed out to me on IRC, this isn't a huge boot time win (and may be a loss) until we have dcache configured correctly. This is on my TODO list, but a separate patch. Changes in v2: - Add Peter's Reviewed-by to #1 - Split the previous #2 into 4 patches Applied to u-boot-ti/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] net, phy, cpsw: fix gigabit register access
On Tue, Jul 23, 2013 at 03:32:36PM +0200, Heiko Schocher wrote: accessing a lan9303 switch with the cpsw driver results in wrong speed detection, as the switch sets the BMSR_ERCAP in BMSR register, and follow read of the MII_STAT1000 register fails, as the switch does not support it. Current code did not check, if a phy_read() fails ... fix this. Signed-off-by: Heiko Schocher h...@denx.de Cc: Joe Hershberger joe.hershber...@gmail.com Acked-by: Mugunthan V N mugunthan...@ti.com Applied to u-boot-ti/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] board/ti/am335x/README: Document NAND programming
On Wed, Jul 17, 2013 at 12:24:30PM -0400, Tom Rini wrote: The AM335x GP EVM ships with NAND. Document programming of the chip including the redundant locations that the ROM will check. Signed-off-by: Tom Rini tr...@ti.com Applied to u-boot-ti/master with Scott's comment fixed. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 0/8] am335x: NOR support
On Thu, Jul 18, 2013 at 03:12:57PM -0400, Tom Rini wrote: Hey all, This series adds NOR support to am335x_evm, along with a few generic changes to make gpmc clearer (for per-board things like different NOR chips, etc). This series depends on the last go-round of the am335x falcon mode docs as that adds the README that I add more content to. And while I say this in 3/8, to be clear, I expect to drop 3/8 in favor of Justin Waters' way of doing this instead, I just include this here for completeness and will get it all happy together when I assemble things in u-boot-ti. The big changes in v4 are: - Apply again to master which includes a few non-trivial updates, so the linker script got re-synced. - After checking what's going on, and testing with NAND again, we can be common with gpmc_cfg-irqstatus/enable, and only set documented bits in gpmc_cfg-config Applied to u-boot-ti/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] omap3/sys_info: fix printout of OMAP36XX L3 freqency
On Mon, Jul 08, 2013 at 03:21:34PM +0200, Andreas Bie??mann wrote: The OMAP36xx/OMAP37xx family uses L3 frequency of 200MHz instead of 165MHz used by OMAP34xx/OMAP35xx. Also fix checkpatch warning about alignment. Signed-off-by: Andreas Bie??mann andreas.de...@googlemail.com Applied to u-boot-ti/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/2] gpio: tca642x: Add the tca642x gpio expander driver
On Thu, Jul 11, 2013 at 01:10:27PM -0500, Dan Murphy wrote: Add the tca642x gpio expander driver Datasheet: http://www.ti.com/product/tca6424a Signed-off-by: Dan Murphy dmur...@ti.com Applied to u-boot-ti/master along with 2/2, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Please pull u-boot-ti/master
Hello, The following changes since commit 8b485ba12b0defa0c4ed3559789250238f8331a8: Merge branch 'u-boot/master' into u-boot-arm/master (2013-07-25 17:57:46 +0200) are available in the git repository at: git://git.denx.de/u-boot-ti.git master for you to fetch changes up to fdce7b633a1de24456226b18527cc7900c34282a: gpio: omap5-uevm: Configure the tca6424 gpio expander (2013-07-30 09:21:42 -0400) Andreas Bie??mann (1): omap3/sys_info: fix printout of OMAP36XX L3 freqency Christian Riesch (1): da850evm: Use clrbits function with correct endianess Dan Murphy (2): gpio: tca642x: Add the tca642x gpio expander driver gpio: omap5-uevm: Configure the tca6424 gpio expander Heiko Schocher (1): net, phy, cpsw: fix gigabit register access Justin Waters (6): am335x_evm: Make NAND support modular am335x_evm: Add command line editing am335x_evm: Rework bootcmd to handle two MMC devs Add additional MLO images to .gitignore am335x_evm: Add support for eMMC environment am335x_evm: Add am335x_boneblack variant Lokesh Vutla (1): ARM: DRA7xx: Lock DPLL_GMAC Mugunthan V N (6): drivers: net: cpsw: remove hard coding bd ram for cpsw drivers: net: cpsw: Enable statistics for all port ARM: DRA7xx: Enable GMAC clock control ARM: DRA7xx: Add CPSW support to DRA7xx EVM ARM: DRA7xx: Add CPSW and MDIO pinmux support ARM: DRA7xx: Enable CPSW Ethernet support Nishanth Menon (6): omap3_beagle: remove JFFS2 support. omap3_beagle: replace uImage.beagle with generic uImage beagleboard: remove RevB support for BeagleBoard Xm omap3_beagle: enable CMD_FS_GENERIC and simplify load of image/ramdisk omap3_beagle: support findfdt and loadfdt for devicetree support omap3_beagle: support booting from zImage and device tree as last option Stefan Roese (1): arm: omap3: spl: Fix problem with 8bit NAND devices Steve Kipisz (2): am335x_evm: Add support for the NOR module on the memory cape am335x_evm: Add support to boot from NOR. Tom Rini (12): spl_mmc.c: Detect missing kernel image in RAW MMC README.falcon: Note how we determine if we can boot the OS or not am335x_evm: Correct DFU ALT settings for falcon mode am335x_evm: Update eMMC falcon mode locations am335x_evm: Correct CONFIG_CMD_SPL_WRITE_SIZE am335x_evm: Add basic README board/ti/am335x/README: Document NAND programming am335x_evm: Drop useless CONFIG_ENV_IS_NOWHERE am335x_evm: Update SPI_BOOT support, add MTDPARTS info am335x_evm: Rework board_is_foo() checks am33xx: Correct gpmc_cfg-irqstatus/enable board/ti/am335x/README: Document NOR programming .gitignore |2 +- arch/arm/cpu/armv7/am33xx/board.c |2 +- arch/arm/cpu/armv7/am33xx/emif4.c |6 +- arch/arm/cpu/armv7/am33xx/mem.c|8 +- arch/arm/cpu/armv7/omap-common/clocks-common.c | 18 ++ arch/arm/cpu/armv7/omap3/mem.c | 12 + arch/arm/cpu/armv7/omap3/sys_info.c|6 +- arch/arm/cpu/armv7/omap5/hw_data.c | 18 +- arch/arm/cpu/armv7/omap5/prcm-regs.c |7 + arch/arm/include/asm/arch-am33xx/mem.h |9 + arch/arm/include/asm/arch-omap5/cpu.h |6 + arch/arm/include/asm/arch-omap5/omap.h | 26 ++ arch/arm/include/asm/omap_common.h | 10 + board/davinci/da8xxevm/da850evm.c | 14 +- board/ti/am335x/Makefile |2 +- board/ti/am335x/README | 160 board/ti/am335x/board.c| 121 + board/ti/am335x/board.h| 31 +++ board/ti/am335x/mux.c | 65 - board/ti/am335x/u-boot.lds | 117 + board/ti/beagle/beagle.c | 28 +- board/ti/beagle/beagle.h |3 +- board/ti/dra7xx/evm.c | 150 ++- board/ti/dra7xx/mux_data.h | 14 + board/ti/omap5_uevm/evm.c | 22 ++ board/ti/omap5_uevm/mux_data.h |2 + board/ti/ti814x/evm.c |1 + boards.cfg | 17 +- common/spl/spl_mmc.c |4 + doc/README.falcon |2 + drivers/gpio/Makefile |1 + drivers/gpio/tca642x.c | 333 drivers/net/cpsw.c |7 +- drivers/net/phy/phy.c |6 +- include/configs/am335x_evm.h | 225 ++-- include/configs/dra7xx_evm.h | 19 ++
Re: [U-Boot] [PATCH V3 0/6] omap3_beagle: configs: improve BOOT_CMD options
On Mon, Jul 15, 2013 at 07:11:27AM -0500, Nishanth Menon wrote: With the latest transition to device tree, there is a need to simplify the load of device tree depending on board type etc. While at it, simplify few other changes as well. Testing: with a uEnv.txt as: bootdir=/ bootpart=0:1 The following were the boot results: Beagle (rev C1D): http://pastebin.com/fMdsKkgr Beagle XM (rev C1): http://pastebin.com/p1zp9AhG Changes in V3 since v2: - Minor fixes for RevB beagleboard DVIpup handling http://marc.info/?t=13735797054r=1w=2 - Picked up acked-by from http://marc.info/?t=13735797077r=1w=2 V2: http://marc.info/?l=u-bootm=137358206228251w=2 V1: http://marc.info/?l=u-bootm=137357963227510w=2 Nishanth Menon (6): omap3_beagle: remove JFFS2 support. omap3_beagle: replace uImage.beagle with generic uImage beagleboard: remove RevB support for BeagleBoard Xm omap3_beagle: enable CMD_FS_GENERIC and simplify load of image/ramdisk omap3_beagle: support findfdt and loadfdt for devicetree support omap3_beagle: support booting from zImage and device tree as last option board/ti/beagle/beagle.c | 28 +++-- board/ti/beagle/beagle.h |3 +-- include/configs/omap3_beagle.h | 44 3 files changed, 39 insertions(+), 36 deletions(-) Applied to u-boot-ti/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-ti/master
On Mon, Jul 29, 2013 at 10:21:06PM -0400, Tom Rini wrote: Hey, The following changes since commit 8b485ba12b0defa0c4ed3559789250238f8331a8: Merge branch 'u-boot/master' into u-boot-arm/master (2013-07-25 17:57:46 +0200) are available in the git repository at: git://git.denx.de/u-boot-ti.git master for you to fetch changes up to bb2a5d8f87fffb4fadfb205837decbd1b3e75f88: gpio: omap5-uevm: Configure the tca6424 gpio expander (2013-07-29 18:09:26 -0400) Andreas Bie??mann (1): omap3/sys_info: fix printout of OMAP36XX L3 freqency Christian Riesch (1): da850evm: Use clrbits function with correct endianess Dan Murphy (2): gpio: tca642x: Add the tca642x gpio expander driver gpio: omap5-uevm: Configure the tca6424 gpio expander Heiko Schocher (1): net, phy, cpsw: fix gigabit register access Justin Waters (6): am335x_evm: Make NAND support modular am335x_evm: Add command line editing am335x_evm: Rework bootcmd to handle two MMC devs Add additional MLO images to .gitignore am335x_evm: Add support for eMMC environment am335x_evm: Add am335x_boneblack variant Lokesh Vutla (1): ARM: DRA7xx: Lock DPLL_GMAC Mugunthan V N (6): drivers: net: cpsw: remove hard coding bd ram for cpsw drivers: net: cpsw: Enable statistics for all port ARM: DRA7xx: Enable GMAC clock control ARM: DRA7xx: Add CPSW support to DRA7xx EVM ARM: DRA7xx: Add CPSW and MDIO pinmux support ARM: DRA7xx: Enable CPSW Ethernet support Nishanth Menon (6): omap3_beagle: remove JFFS2 support. omap3_beagle: replace uImage.beagle with generic uImage beagleboard: remove RevB support for BeagleBoard Xm omap3_beagle: enable CMD_FS_GENERIC and simplify load of image/ramdisk omap3_beagle: support findfdt and loadfdt for devicetree support omap3_beagle: support booting from zImage and device tree as last option Stefan Roese (1): arm: omap3: spl: Fix problem with 8bit NAND devices Steve Kipisz (2): am335x_evm: Add support for the NOR module on the memory cape am335x_evm: Add support to boot from NOR. Tom Rini (12): spl_mmc.c: Detect missing kernel image in RAW MMC README.falcon: Note how we determine if we can boot the OS or not am335x_evm: Correct DFU ALT settings for falcon mode am335x_evm: Update eMMC falcon mode locations am335x_evm: Correct CONFIG_CMD_SPL_WRITE_SIZE am335x_evm: Add basic README board/ti/am335x/README: Document NAND programming am335x_evm: Drop useless CONFIG_ENV_IS_NOWHERE am335x_evm: Update SPI_BOOT support, add MTDPARTS info am335x_evm: Rework board_is_foo() checks am33xx: Correct gpmc_cfg-irqstatus/enable board/ti/am335x/README: Document NOR programming .gitignore |2 +- arch/arm/cpu/armv7/am33xx/board.c |2 +- arch/arm/cpu/armv7/am33xx/emif4.c |6 +- arch/arm/cpu/armv7/am33xx/mem.c|8 +- arch/arm/cpu/armv7/omap-common/clocks-common.c | 18 ++ arch/arm/cpu/armv7/omap3/mem.c | 12 + arch/arm/cpu/armv7/omap3/sys_info.c|6 +- arch/arm/cpu/armv7/omap5/hw_data.c | 18 +- arch/arm/cpu/armv7/omap5/prcm-regs.c |7 + arch/arm/include/asm/arch-am33xx/mem.h |9 + arch/arm/include/asm/arch-omap5/cpu.h |6 + arch/arm/include/asm/arch-omap5/omap.h | 26 ++ arch/arm/include/asm/omap_common.h | 10 + board/davinci/da8xxevm/da850evm.c | 14 +- board/ti/am335x/Makefile |2 +- board/ti/am335x/README | 161 board/ti/am335x/board.c| 121 + board/ti/am335x/board.h| 31 +++ board/ti/am335x/mux.c | 65 - board/ti/am335x/u-boot.lds | 117 + board/ti/beagle/beagle.c | 28 +- board/ti/beagle/beagle.h |3 +- board/ti/dra7xx/evm.c | 150 ++- board/ti/dra7xx/mux_data.h | 14 + board/ti/omap5_uevm/evm.c | 22 ++ board/ti/omap5_uevm/mux_data.h |2 + board/ti/ti814x/evm.c |1 + boards.cfg | 17 +- common/spl/spl_mmc.c |4 + doc/README.falcon |2 + drivers/gpio/Makefile |1 + drivers/gpio/tca642x.c | 333 drivers/net/cpsw.c |7 +- drivers/net/phy/phy.c
Re: [U-Boot] Please pull u-boot-ti/master
On Tue, Jul 30, 2013 at 11:45:43AM +0200, Stefan Roese wrote: Hi Tom, On 07/30/2013 04:21 AM, Tom Rini wrote: Hey, The following changes since commit 8b485ba12b0defa0c4ed3559789250238f8331a8: Merge branch 'u-boot/master' into u-boot-arm/master (2013-07-25 17:57:46 +0200) are available in the git repository at: git://git.denx.de/u-boot-ti.git master for you to fetch changes up to bb2a5d8f87fffb4fadfb205837decbd1b3e75f88: gpio: omap5-uevm: Configure the tca6424 gpio expander (2013-07-29 18:09:26 -0400) Andreas Bie?mann (1): omap3/sys_info: fix printout of OMAP36XX L3 freqency Christian Riesch (1): da850evm: Use clrbits function with correct endianess Dan Murphy (2): gpio: tca642x: Add the tca642x gpio expander driver gpio: omap5-uevm: Configure the tca6424 gpio expander Heiko Schocher (1): net, phy, cpsw: fix gigabit register access Justin Waters (6): am335x_evm: Make NAND support modular am335x_evm: Add command line editing am335x_evm: Rework bootcmd to handle two MMC devs Add additional MLO images to .gitignore am335x_evm: Add support for eMMC environment am335x_evm: Add am335x_boneblack variant Lokesh Vutla (1): ARM: DRA7xx: Lock DPLL_GMAC Mugunthan V N (6): drivers: net: cpsw: remove hard coding bd ram for cpsw drivers: net: cpsw: Enable statistics for all port ARM: DRA7xx: Enable GMAC clock control ARM: DRA7xx: Add CPSW support to DRA7xx EVM ARM: DRA7xx: Add CPSW and MDIO pinmux support ARM: DRA7xx: Enable CPSW Ethernet support Nishanth Menon (6): omap3_beagle: remove JFFS2 support. omap3_beagle: replace uImage.beagle with generic uImage beagleboard: remove RevB support for BeagleBoard Xm omap3_beagle: enable CMD_FS_GENERIC and simplify load of image/ramdisk omap3_beagle: support findfdt and loadfdt for devicetree support omap3_beagle: support booting from zImage and device tree as last option Stefan Roese (1): arm: omap3: spl: Fix problem with 8bit NAND devices Any reason why you didn't include this patch? http://patchwork.ozlabs.org/patch/251864/ [PATCH v2 3/3] arm: omap3: Add SPL support to cm_t35 Because that platform shows off the problem that 1/3 was intended to fix, but we haven't yet done what Albert suggested (s/s_init/system_init/ call from board_init_f). -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-cfi-flash
On Tue, Jul 30, 2013 at 10:36:32AM +0200, Stefan Roese wrote: Hi Tim, please pull this CFI patch: The following changes since commit 9fab4bf4cc077c21e43941866f3f2c196f28670d: powerpc/ppc4xx: Convert new gdsys files to SPDX license tags (2013-07-26 15:32:59 -0400) are available in the git repository at: git://www.denx.de/git/u-boot-cfi-flash.git master for you to fetch changes up to 6a19cc9df0ff76273cecd3cd72323a73ff44e8de: cfi_flash: Add prototypes of overridable functions (2013-07-30 09:11:54 +0200) Masahiro Yamada (1): cfi_flash: Add prototypes of overridable functions include/mtd/cfi_flash.h | 14 ++ 1 file changed, 14 insertions(+) Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 5/7] ARM: add SMP support for non-secure switch
On Tue, Jul 30, 2013 at 01:51:33PM +0200, Andre Przywara wrote:
On 07/30/2013 12:02 AM, Christoffer Dall wrote:
On Wed, Jul 10, 2013 at 01:54:17AM +0200, Andre Przywara wrote:
Currently the non-secure switch is only done for the boot processor.
To enable full SMP support, we have to switch all secondary cores
into non-secure state also.
So we add an entry point for secondary CPUs coming out of low-power
state and make sure we put them into WFI again after having switched
to non-secure state.
For this we acknowledge and EOI the wake-up IPI, then go into WFI.
Once being kicked out of it later, we sanity check that the start
address has actually been changed (since another attempt to switch
to non-secure would block the core) and jump to the new address.
The actual CPU kick is done by sending an inter-processor interrupt
via the GIC to all CPU interfaces except the requesting processor.
The secondary cores will then setup their respective GIC CPU
interface.
The address secondary cores jump to is board specific, we provide
the value here for the Versatile Express board.
Signed-off-by: Andre Przywara andre.przyw...@linaro.org
---
arch/arm/cpu/armv7/nonsec_virt.S| 27 +++
arch/arm/cpu/armv7/virt-v7.c| 19 ++-
arch/arm/include/asm/armv7.h| 1 +
arch/arm/include/asm/gic.h | 2 ++
include/configs/vexpress_ca15_tc2.h | 3 +++
5 files changed, 51 insertions(+), 1 deletion(-)
diff --git a/arch/arm/cpu/armv7/nonsec_virt.S
b/arch/arm/cpu/armv7/nonsec_virt.S
index e9ee831..f9b6b39 100644
--- a/arch/arm/cpu/armv7/nonsec_virt.S
+++ b/arch/arm/cpu/armv7/nonsec_virt.S
@@ -58,6 +58,33 @@ _secure_monitor:
movspc, lr @ return to non-secure SVC
/*
+ * Secondary CPUs start here and call the code for the core specific parts
+ * of the non-secure and HYP mode transition. The GIC distributor specific
+ * code has already been executed by a C function before.
+ * Then they go back to wfi and wait to be woken up by the kernel again.
+ */
+ENTRY(_smp_pen)
+ mrs r0, cpsr
+ orr r0, r0, #0xc0
+ msr cpsr, r0@ disable interrupts
+ ldr r1, =_start
+ mcr p15, 0, r1, c12, c0, 0 @ set VBAR
+
+ bl _nonsec_init
+
+ ldr r1, [r0, #GICC_IAR] @ acknowledge IPI
+ str r1, [r0, #GICC_EOIR]@ signal end of interrupt
+ adr r1, _smp_pen
+waitloop:
+ wfi
+ ldr r0, =CONFIG_SYSFLAGS_ADDR @ load start address
You seem to have ignored my comment about using the sysflags name?
As I understand, the sysflags name is a versatile express specific
register name that just happens to be used for the SMP boot address as
well...
Therefore, this should really be CONFIG_SMP_BOOT_ADDR or something like
that, at the very least.
+ ldr r0, [r0]
+ cmp r0, r1 @ make sure we dont execute this code
+ beq waitloop@ again (due to a spurious wakeup)
+ mov pc, r0
+ENDPROC(_smp_pen)
+
+/*
* Switch a core to non-secure state.
*
* 1. initialize the GIC per-core interface
diff --git a/arch/arm/cpu/armv7/virt-v7.c b/arch/arm/cpu/armv7/virt-v7.c
index 54f9746..a0d0b34 100644
--- a/arch/arm/cpu/armv7/virt-v7.c
+++ b/arch/arm/cpu/armv7/virt-v7.c
@@ -77,6 +77,21 @@ static int get_gicd_base_address(unsigned int *gicdaddr)
#endif
}
+static void kick_secondary_cpus(unsigned int gicdaddr)
+{
+ unsigned int *secondary_boot_addr;
+
+ secondary_boot_addr = (void *)CONFIG_SYSFLAGS_ADDR;
+#ifdef CONFIG_SYSFLAGS_NEED_CLEAR_BITS
+ secondary_boot_addr[1] = (unsigned)-1;
+#endif
again, if you disagreed with my previous comment, please comment on it
and rationalize your choice.
I am sorry, I thought I reasoned that already in an earlier mail:
I don't want to introduce abstraction prematurely, so I wanted to
refactor the code as soon as a second board gets supported. Which
will probably be the Arndale, and also probably done by me ...
Hmm, a big motivation for doing this is to make it clear what new boards
need to do to support Hyp mode, and make it as easy as possible. We
have already made the choice to make this code generic in virt-v7.c as
opposed to vexpress.c (or whatever that file would be called), so I
don't really understand your argument about being premature, to be
completely honest.
I still feel you're wrapping board specific logic into generic code, and
that you should call out to a more generic function. Imagine an SOC
that uses an implementation defined control register for this instead of
a memory address...
Well, I can imagine quite some ways to do this, but in fact I'd like
to focus on things that really exist ;-)
My fear is that any abstraction I introduce now will not suffice for
a future board and needs to be refactored then anyway.
Sorry,
Re: [U-Boot] [PATCH v3 6/7] ARM: extend non-secure switch to also go into HYP mode
On Tue, Jul 30, 2013 at 01:59:29PM +0200, Andre Przywara wrote: On 07/30/2013 12:02 AM, Christoffer Dall wrote: On Wed, Jul 10, 2013 at 01:54:18AM +0200, Andre Przywara wrote: [...] +_hyp_trap: + mrs lr, elr_hyp @ for older asm: .byte 0x00, 0xe3, 0x0e, 0xe1 this comment just confuses: either make it intelligent to support an older compiler or just get rid of these byte encodings. You can always disassemble the file and lookup the byte code with a modern compiler to get back to the byte encoding. Well, I used a Debian 6 cross compiler before, which didn't support these instructions. After your remark I updated the system to Debian 7, but found it not appropriate to ask any user to do the same just to use a fixed, non-parametrized assembly instruction. I have the feeling that there are quite some users out there who cannot and don't want to easily update their compiler. So I decided to leave the workaround in the comment to give a hint to a quick fix. ok, so if Debian's built-in cross compilers are indeed that old and we want to support those (that's ok with me), then let's fix it properly. By making it intelligent you mean a macro which does some version checking and inserts the .byte sequence if needed? Are there any archetypes of such code? Yes, see arch/arm/include/asm/opcodes-*.h -Christoffer ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 4/7] ARM: switch to non-secure state during bootm execution
On Tue, Jul 30, 2013 at 01:32:14PM +0200, Andre Przywara wrote:
On 07/30/2013 12:02 AM, Christoffer Dall wrote:
On Wed, Jul 10, 2013 at 01:54:16AM +0200, Andre Przywara wrote:
[...]
diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c
index 1b6e0ac..7b0619e 100644
--- a/arch/arm/lib/bootm.c
+++ b/arch/arm/lib/bootm.c
@@ -34,6 +34,10 @@
#include asm/bootm.h
#include linux/compiler.h
+#ifdef CONFIG_ARMV7_NONSEC
+#include asm/armv7.h
+#endif
+
DECLARE_GLOBAL_DATA_PTR;
static struct tag *params;
@@ -186,6 +190,29 @@ static void setup_end_tag(bd_t *bd)
__weak void setup_board_tags(struct tag **in_params) {}
+static void do_nonsec_virt_switch(void)
+{
+#ifdef CONFIG_ARMV7_NONSEC
+ int ret;
+
+ ret = armv7_switch_nonsec();
+ switch (ret) {
+ case NONSEC_VIRT_SUCCESS:
+ debug(entered non-secure state\n);
+ break;
+ case NONSEC_ERR_NO_SEC_EXT:
+ printf(nonsec: Security extensions not implemented.\n);
+ break;
+ case NONSEC_ERR_NO_GIC_ADDRESS:
+ printf(nonsec: could not determine GIC address.\n);
+ break;
+ case NONSEC_ERR_GIC_ADDRESS_ABOVE_4GB:
+ printf(nonsec: PERIPHBASE is above 4 GB, no access.\n);
+ break;
+ }
+#endif
+}
I still don't get why you just don't make armv7_switch_nonsec a void and
print the error when they occur... ???
My apologies for not elaborating on these comments I didn't incorporate:
So, I don't like the idea of marrying a low-level routine with high
level output. I don't want to constraint the usage of the routine by
requiring an output channel. Also some parts may not be fatal for
all users - someone could just try to switch and then behave
differently if that failed - without bothering the user.
May seem a bit over-engineered, but I like it better this way ;-)
If that is a show-stopper for you, I can change it, of course.
I won't hold back my ack for the patch series based on this, but I do
think it's over-engineered. I think at least just returning -1 for
error and 0 for success (or even make it a bool) and just printing a
generic error message is cleaner - the level of details as to why the
switch to hyp/nonsec didn't work could then be debug statements that a
board developer could enable with a #define DEBUG 1 in the
corresponding file.
But ok, we've had the conversation, if you still feel this is better and
necessary, then I'll let it be.
-Christoffer
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] KVM on ARM Chromebook
Hello all, Since there was much interest, as of late, to see KVM/ARM running on Samsung's Exynos5250 Chromebook, and given the fact that we are not aware of any current work done on this, we take the opportunity to inform you that you can test KVM on the ARM Chromebook by following this guide: http://www.virtualopensystems.com/media/chromebook/chromebook.pdf The method used to boot a kernel in HYP mode is with a chained u-boot, while the laptop is in developer mode. Parts of the work are based on v3 of Andre Pryzawa's Add HYP mode switching support patch series. Source code for a working u-boot for this purpose can be also found at: https://github.com/virtualopensystems/u-boot Please let us know of any comments. Best regards. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PULL] u-boot-usb/master
The following changes since commit 9fab4bf4cc077c21e43941866f3f2c196f28670d: powerpc/ppc4xx: Convert new gdsys files to SPDX license tags (2013-07-26 15:32:59 -0400) are available in the git repository at: git://git.denx.de/u-boot-usb.git master for you to fetch changes up to 8bc3603675f7bf4dfa4eb6bdaf2aa0a8ddce9fa6: ehci-hcd: fix memory leak in lowlevel init (2013-07-29 23:01:33 +0200) Lukasz Majewski (1): dfu: Implementation of target reset after communication with dfu-util's -R switch Marek Vasut (17): usb: mv_udc: Unbreak the mv_udc driver usb: mv_udc: Clean up mv_udc.h usb: mv_udc: Move endpoint array into driver data usb: mv_udc: Clean up the EP initialization usb: ehci: Split out struct ehci_ctrl definition usb: mv_udc: Make use of struct ehci_ctrl usb: mv_udc: Clean up the initial variable check usb: mv_udc: Remove QH_MAXNUM macro usb: mv_udc: Init mv_drv.gadget.ops statically usb: mv_udc: Move QH and qTD into mv_drv usb: mv_udc: Properly align the endpoint QH and qTD list usb: mv_udc: Add cacheline length check usb: mv_udc: Implement better QH accessor usb: mv_udc: Improve allocation of qTD items usb: mv_udc: Implement better qTD item accessor usb: mv_udc: Add proper cache management usb: mv_udc: Add bounce buffer Nikita Kiryanov (2): usb_hub: fix power cycling logic ehci-hcd: fix memory leak in lowlevel init Roger Quadros (1): usb: ehci-omap: Don't softreset USB High-speed Host (UHH) Module common/cmd_dfu.c | 14 - common/usb_hub.c |4 +- drivers/dfu/dfu.c | 11 drivers/serial/usbtty.h |2 + drivers/usb/gadget/f_dfu.c|2 + drivers/usb/gadget/gadget_chips.h |2 +- drivers/usb/gadget/mv_udc.c | 401 ++--- drivers/usb/host/ehci-hcd.c | 15 ++--- drivers/usb/host/ehci-omap.c | 27 + drivers/usb/host/ehci.h | 13 + include/dfu.h |2 + include/usb/mv_udc.h | 88 ++--- 12 files changed, 423 insertions(+), 158 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 8/9] tegra: i2c: Enable new CONFIG_SYS_I2C framework
On 07/29/2013 10:28 PM, Heiko Schocher wrote: Hello Stephen, Am 29.07.2013 18:12, schrieb Stephen Warren: On 05/04/2013 06:01 AM, Heiko Schocher wrote: From: Simon Glasss...@chromium.org This enables CONFIG_SYS_I2C on Tegra, updating existing boards and the Tegra i2c driver to support this. Heiko, the latest U-Boot tree hangs during boot on Tegra, and git :-( Could you enable debug printf? bisect points at this patch. Olof reported the issue to me. Thanks! Can you take a look at the code and see what might be wrong? Thanks. Yep. I suspect some kind of initialization ordering issue, since the boot messages are: - U-Boot SPL 2013.07-rc3-00038-g880540d (Jul 29 2013 - 10:04:37) U-Boot 2013.07-rc3-00038-g880540d (Jul 29 2013 - 10:04:37) TEGRA30 Board: NVIDIA Beaver I2C: Caller requested bad clock: periph=-49, parent=2 - ... and that bad clock message implies to me that the I2C driver is initializing before it has parsed the correct clock ID out of device tree. Hmm... looking in the patch ... I can see nothing which changes some initializing order ... @Simon: Do you have an idea? just found some wrong settings for tegra30: In include/configs/tegra30-common.h: /* Total I2C ports on Tegra30 */ #define TEGRA_I2C_NUM_CONTROLLERS 5 README says: - drivers/i2c/tegra_i2c.c: - activate this driver with CONFIG_SYS_I2C_TEGRA - This driver adds 4 i2c buses with a fix speed from 10 and the slave addr 0! I think that's just stale documentation; Tegra20 had just 4 I2C controllers, and the docs probably weren't updated for Tegra30 which has 5. end yes, in the i2c driver are only 4 ports activated ... this I don't see any limit in the driver; everything seems to use TEGRA_I2C_NUM_CONTROLLERS. should be changed ... but I think, this has nothing to do with your problem ... but try to add in the i2c driver one more i2c adapter for the case TEGRA_I2C_NUM_CONTROLLERS 4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 8/9] tegra: i2c: Enable new CONFIG_SYS_I2C framework
On 07/29/2013 10:28 PM, Heiko Schocher wrote: Hello Stephen, Am 29.07.2013 18:12, schrieb Stephen Warren: On 05/04/2013 06:01 AM, Heiko Schocher wrote: From: Simon Glasss...@chromium.org This enables CONFIG_SYS_I2C on Tegra, updating existing boards and the Tegra i2c driver to support this. Heiko, the latest U-Boot tree hangs during boot on Tegra, and git bisect points at this patch. Olof reported the issue to me. Can you take a look at the code and see what might be wrong? Thanks. I suspect some kind of initialization ordering issue, since the boot messages are: - U-Boot SPL 2013.07-rc3-00038-g880540d (Jul 29 2013 - 10:04:37) U-Boot 2013.07-rc3-00038-g880540d (Jul 29 2013 - 10:04:37) TEGRA30 Board: NVIDIA Beaver I2C: Caller requested bad clock: periph=-49, parent=2 - ... and that bad clock message implies to me that the I2C driver is initializing before it has parsed the correct clock ID out of device tree. Hmm... looking in the patch ... I can see nothing which changes some initializing order ... Yes, there's some initialization order issue; before this patch, I see the I2C controller initialization, followed by some usage of it: -- U-Boot SPL 2013.07-rc3-00036-gd84eb85-dirty (Jul 30 2013 - 13:04:47) U-Boot 2013.07-rc3-00036-gd84eb85-dirty (Jul 30 2013 - 13:04:47) TEGRA30 Board: NVIDIA Beaver DRAM: 2 GiB i2c: controller bus 0 at 7000d000, periph_id 47, speed 10: ok i2c: controller bus 1 at 7000c000, periph_id 12, speed 10: ok i2c: controller bus 2 at 7000c400, periph_id 54, speed 10: ok i2c: controller bus 3 at 7000c500, periph_id 67, speed 10: ok i2c: controller bus 4 at 7000c700, periph_id 103, speed 10: ok MMC: i2c_write: chip=0x2d, addr=0x32, len=0x1 -- However with this patch applied, something starts using the controller immediately, without it having been probed from device-tree: -- U-Boot SPL 2013.07-rc3-00037-g1f2ba72-dirty (Jul 30 2013 - 13:08:28) U-Boot 2013.07-rc3-00037-g1f2ba72-dirty (Jul 30 2013 - 13:08:28) TEGRA30 Board: NVIDIA Beaver I2C: i2c_init(speed=10, slaveaddr=0xfe) -- i2c_init touches HW, but since process_nodes() hasn't run, none of the parameters like register address or clock ID are yet known. I think this call comes from init_sequence_f[] - init_func_i2c() - i2c_init() - i2c_init() == __i2c_init() - i2c_init_bus() - I2C_ADAP-init(), although I didn't validate that in the running code, just by code inspection. The issue here is that the I2C core and/or Tegra driver seems to be statically registering the I2C device objects, even though they should be dynamically registered from device tree. Should Tegra move its call of i2c_init_board() out of board_init() to board_init_f(), and/or override __i2c_init() to call i2c_init_board()? I think when init_sequence_f[] is running, there may be no serial console to report errors. If so, moving the I2C initialization to that early point sounds like a really bad idea. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-ti/master
Hi Tom, On Tue, 30 Jul 2013 09:29:55 -0400, Tom Rini tr...@ti.com wrote: Hello, The following changes since commit 8b485ba12b0defa0c4ed3559789250238f8331a8: Merge branch 'u-boot/master' into u-boot-arm/master (2013-07-25 17:57:46 +0200) are available in the git repository at: git://git.denx.de/u-boot-ti.git master for you to fetch changes up to fdce7b633a1de24456226b18527cc7900c34282a: gpio: omap5-uevm: Configure the tca6424 gpio expander (2013-07-30 09:21:42 -0400) Andreas Bießmann (1): omap3/sys_info: fix printout of OMAP36XX L3 freqency Christian Riesch (1): da850evm: Use clrbits function with correct endianess Dan Murphy (2): gpio: tca642x: Add the tca642x gpio expander driver gpio: omap5-uevm: Configure the tca6424 gpio expander Heiko Schocher (1): net, phy, cpsw: fix gigabit register access Justin Waters (6): am335x_evm: Make NAND support modular am335x_evm: Add command line editing am335x_evm: Rework bootcmd to handle two MMC devs Add additional MLO images to .gitignore am335x_evm: Add support for eMMC environment am335x_evm: Add am335x_boneblack variant Lokesh Vutla (1): ARM: DRA7xx: Lock DPLL_GMAC Mugunthan V N (6): drivers: net: cpsw: remove hard coding bd ram for cpsw drivers: net: cpsw: Enable statistics for all port ARM: DRA7xx: Enable GMAC clock control ARM: DRA7xx: Add CPSW support to DRA7xx EVM ARM: DRA7xx: Add CPSW and MDIO pinmux support ARM: DRA7xx: Enable CPSW Ethernet support Nishanth Menon (6): omap3_beagle: remove JFFS2 support. omap3_beagle: replace uImage.beagle with generic uImage beagleboard: remove RevB support for BeagleBoard Xm omap3_beagle: enable CMD_FS_GENERIC and simplify load of image/ramdisk omap3_beagle: support findfdt and loadfdt for devicetree support omap3_beagle: support booting from zImage and device tree as last option Stefan Roese (1): arm: omap3: spl: Fix problem with 8bit NAND devices Steve Kipisz (2): am335x_evm: Add support for the NOR module on the memory cape am335x_evm: Add support to boot from NOR. Tom Rini (12): spl_mmc.c: Detect missing kernel image in RAW MMC README.falcon: Note how we determine if we can boot the OS or not am335x_evm: Correct DFU ALT settings for falcon mode am335x_evm: Update eMMC falcon mode locations am335x_evm: Correct CONFIG_CMD_SPL_WRITE_SIZE am335x_evm: Add basic README board/ti/am335x/README: Document NAND programming am335x_evm: Drop useless CONFIG_ENV_IS_NOWHERE am335x_evm: Update SPI_BOOT support, add MTDPARTS info am335x_evm: Rework board_is_foo() checks am33xx: Correct gpmc_cfg-irqstatus/enable board/ti/am335x/README: Document NOR programming .gitignore |2 +- arch/arm/cpu/armv7/am33xx/board.c |2 +- arch/arm/cpu/armv7/am33xx/emif4.c |6 +- arch/arm/cpu/armv7/am33xx/mem.c|8 +- arch/arm/cpu/armv7/omap-common/clocks-common.c | 18 ++ arch/arm/cpu/armv7/omap3/mem.c | 12 + arch/arm/cpu/armv7/omap3/sys_info.c|6 +- arch/arm/cpu/armv7/omap5/hw_data.c | 18 +- arch/arm/cpu/armv7/omap5/prcm-regs.c |7 + arch/arm/include/asm/arch-am33xx/mem.h |9 + arch/arm/include/asm/arch-omap5/cpu.h |6 + arch/arm/include/asm/arch-omap5/omap.h | 26 ++ arch/arm/include/asm/omap_common.h | 10 + board/davinci/da8xxevm/da850evm.c | 14 +- board/ti/am335x/Makefile |2 +- board/ti/am335x/README | 160 board/ti/am335x/board.c| 121 + board/ti/am335x/board.h| 31 +++ board/ti/am335x/mux.c | 65 - board/ti/am335x/u-boot.lds | 117 + board/ti/beagle/beagle.c | 28 +- board/ti/beagle/beagle.h |3 +- board/ti/dra7xx/evm.c | 150 ++- board/ti/dra7xx/mux_data.h | 14 + board/ti/omap5_uevm/evm.c | 22 ++ board/ti/omap5_uevm/mux_data.h |2 + board/ti/ti814x/evm.c |1 + boards.cfg | 17 +- common/spl/spl_mmc.c |4 + doc/README.falcon |2 + drivers/gpio/Makefile |1 + drivers/gpio/tca642x.c | 333 drivers/net/cpsw.c |7 +-
Re: [U-Boot] [PATCH v3 8/9] tegra: i2c: Enable new CONFIG_SYS_I2C framework
On 07/30/2013 01:22 PM, Stephen Warren wrote: On 07/29/2013 10:28 PM, Heiko Schocher wrote: Hello Stephen, Am 29.07.2013 18:12, schrieb Stephen Warren: On 05/04/2013 06:01 AM, Heiko Schocher wrote: From: Simon Glasss...@chromium.org This enables CONFIG_SYS_I2C on Tegra, updating existing boards and the Tegra i2c driver to support this. Heiko, the latest U-Boot tree hangs during boot on Tegra, and git bisect points at this patch. Olof reported the issue to me. Can you take a look at the code and see what might be wrong? Thanks. I suspect some kind of initialization ordering issue, since the boot messages are: - U-Boot SPL 2013.07-rc3-00038-g880540d (Jul 29 2013 - 10:04:37) U-Boot 2013.07-rc3-00038-g880540d (Jul 29 2013 - 10:04:37) TEGRA30 Board: NVIDIA Beaver I2C: Caller requested bad clock: periph=-49, parent=2 - ... and that bad clock message implies to me that the I2C driver is initializing before it has parsed the correct clock ID out of device tree. Hmm... looking in the patch ... I can see nothing which changes some initializing order ... Yes, there's some initialization order issue; before this patch, I see the I2C controller initialization, followed by some usage of it: -- U-Boot SPL 2013.07-rc3-00036-gd84eb85-dirty (Jul 30 2013 - 13:04:47) U-Boot 2013.07-rc3-00036-gd84eb85-dirty (Jul 30 2013 - 13:04:47) TEGRA30 Board: NVIDIA Beaver DRAM: 2 GiB i2c: controller bus 0 at 7000d000, periph_id 47, speed 10: ok i2c: controller bus 1 at 7000c000, periph_id 12, speed 10: ok i2c: controller bus 2 at 7000c400, periph_id 54, speed 10: ok i2c: controller bus 3 at 7000c500, periph_id 67, speed 10: ok i2c: controller bus 4 at 7000c700, periph_id 103, speed 10: ok MMC: i2c_write: chip=0x2d, addr=0x32, len=0x1 -- However with this patch applied, something starts using the controller immediately, without it having been probed from device-tree: -- U-Boot SPL 2013.07-rc3-00037-g1f2ba72-dirty (Jul 30 2013 - 13:08:28) U-Boot 2013.07-rc3-00037-g1f2ba72-dirty (Jul 30 2013 - 13:08:28) TEGRA30 Board: NVIDIA Beaver I2C: i2c_init(speed=10, slaveaddr=0xfe) -- i2c_init touches HW, but since process_nodes() hasn't run, none of the parameters like register address or clock ID are yet known. I think this call comes from init_sequence_f[] - init_func_i2c() - i2c_init() - i2c_init() == __i2c_init() - i2c_init_bus() - I2C_ADAP-init(), although I didn't validate that in the running code, just by code inspection. Oh, with the options Tegra has enabled, perhaps the call sequence is: board_init_f() (which uses init_sequence_f[]) - init_func_i2c() - i2c_init_all(), which then calls: * i2c_init_board(), which is supposed to parse DT * i2c_set_bus_num(), which will call I2C_ADAP-init However, according to the comments near the top of arch/arm/lib/crt0.S, board_init_f() is called in an environment where variable data (.data, .bss) is not available, hence i2c_init_board() cannot possibly operate correctly since its whole purpose is to fill in variable data structures from DT. I think the only way to solve this is not to use DT to instantiate devices, or to move the I2C initialization after relocation etc., although the latter won't work on boards that need I2C up in order to initialize DRAM. It seems like much of U-Boot's initialization architecture simply wasn't designed to accommodate dynamically initializing devices from DT. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] getline prototype issue
Simon, Your patch commit 669dfc2ed8d853d6bcdcafa1de6aca22929465e5 Author: Simon Glass s...@chromium.org Date: Mon Mar 11 06:30:27 2013 + fdt: Ensure that libfdt_env.h comes from U-Boot adds libfdt_env.h to HOSTCPPFLAGS. The causes a problem with one of our older hosts. On the old hosts, getline prototype is protected by #ifdef __USE_GNU This should be OK if the C file has #define _GNU_SOURCE. However, because of your patch, the stdio.h is included before _GNU_SOURCE is defined. The result is warnings like this aisimage.c: In function ‘aisimage_generate’: aisimage.c:313: warning: implicit declaration of function ‘getline’ kwbimage.c: In function ‘kwdimage_set_ext_header’: kwbimage.c:236: warning: implicit declaration of function ‘getline’ imximage.c: In function ‘parse_cfg_file’: imximage.c:430: warning: implicit declaration of function ‘getline’ pblimage.c: In function ‘pbl_parser’: pblimage.c:137: warning: implicit declaration of function ‘getline’ ublimage.c: In function ‘parse_cfg_file’: ublimage.c:179: warning: implicit declaration of function ‘getline’ York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] getline prototype issue
Hi York, On Tue, Jul 30, 2013 at 3:12 PM, York Sun york...@freescale.com wrote: Simon, Your patch commit 669dfc2ed8d853d6bcdcafa1de6aca22929465e5 Author: Simon Glass s...@chromium.org Date: Mon Mar 11 06:30:27 2013 + fdt: Ensure that libfdt_env.h comes from U-Boot adds libfdt_env.h to HOSTCPPFLAGS. The causes a problem with one of our older hosts. On the old hosts, getline prototype is protected by #ifdef __USE_GNU This should be OK if the C file has #define _GNU_SOURCE. However, because of your patch, the stdio.h is included before _GNU_SOURCE is defined. The result is warnings like this aisimage.c: In function ‘aisimage_generate’: aisimage.c:313: warning: implicit declaration of function ‘getline’ kwbimage.c: In function ‘kwdimage_set_ext_header’: kwbimage.c:236: warning: implicit declaration of function ‘getline’ imximage.c: In function ‘parse_cfg_file’: imximage.c:430: warning: implicit declaration of function ‘getline’ pblimage.c: In function ‘pbl_parser’: pblimage.c:137: warning: implicit declaration of function ‘getline’ ublimage.c: In function ‘parse_cfg_file’: ublimage.c:179: warning: implicit declaration of function ‘getline’ I took a quick look at this. It seems that many of the host C files in tools/ define _GNU_SOURCE. Should we just move that #define to the Makefile? Regards, Simon York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 8/9] tegra: i2c: Enable new CONFIG_SYS_I2C framework
Hi Stephen, On Tue, Jul 30, 2013 at 1:22 PM, Stephen Warren swar...@wwwdotorg.orgwrote: On 07/29/2013 10:28 PM, Heiko Schocher wrote: Hello Stephen, Am 29.07.2013 18:12, schrieb Stephen Warren: On 05/04/2013 06:01 AM, Heiko Schocher wrote: From: Simon Glasss...@chromium.org This enables CONFIG_SYS_I2C on Tegra, updating existing boards and the Tegra i2c driver to support this. Heiko, the latest U-Boot tree hangs during boot on Tegra, and git bisect points at this patch. Olof reported the issue to me. Can you take a look at the code and see what might be wrong? Thanks. I suspect some kind of initialization ordering issue, since the boot messages are: - U-Boot SPL 2013.07-rc3-00038-g880540d (Jul 29 2013 - 10:04:37) U-Boot 2013.07-rc3-00038-g880540d (Jul 29 2013 - 10:04:37) TEGRA30 Board: NVIDIA Beaver I2C: Caller requested bad clock: periph=-49, parent=2 - ... and that bad clock message implies to me that the I2C driver is initializing before it has parsed the correct clock ID out of device tree. Hmm... looking in the patch ... I can see nothing which changes some initializing order ... Yes, there's some initialization order issue; before this patch, I see the I2C controller initialization, followed by some usage of it: -- U-Boot SPL 2013.07-rc3-00036-gd84eb85-dirty (Jul 30 2013 - 13:04:47) U-Boot 2013.07-rc3-00036-gd84eb85-dirty (Jul 30 2013 - 13:04:47) TEGRA30 Board: NVIDIA Beaver DRAM: 2 GiB i2c: controller bus 0 at 7000d000, periph_id 47, speed 10: ok i2c: controller bus 1 at 7000c000, periph_id 12, speed 10: ok i2c: controller bus 2 at 7000c400, periph_id 54, speed 10: ok i2c: controller bus 3 at 7000c500, periph_id 67, speed 10: ok i2c: controller bus 4 at 7000c700, periph_id 103, speed 10: ok MMC: i2c_write: chip=0x2d, addr=0x32, len=0x1 -- However with this patch applied, something starts using the controller immediately, without it having been probed from device-tree: -- U-Boot SPL 2013.07-rc3-00037-g1f2ba72-dirty (Jul 30 2013 - 13:08:28) U-Boot 2013.07-rc3-00037-g1f2ba72-dirty (Jul 30 2013 - 13:08:28) TEGRA30 Board: NVIDIA Beaver I2C: i2c_init(speed=10, slaveaddr=0xfe) -- i2c_init touches HW, but since process_nodes() hasn't run, none of the parameters like register address or clock ID are yet known. I think this call comes from init_sequence_f[] - init_func_i2c() - i2c_init() - i2c_init() == __i2c_init() - i2c_init_bus() - I2C_ADAP-init(), although I didn't validate that in the running code, just by code inspection. The issue here is that the I2C core and/or Tegra driver seems to be statically registering the I2C device objects, even though they should be dynamically registered from device tree. Should Tegra move its call of i2c_init_board() out of board_init() to board_init_f(), and/or override __i2c_init() to call i2c_init_board()? Something like that. We need i2c_init_board() to be called earlier, now that the init sequence is doing i2c on ARM. I think when init_sequence_f[] is running, there may be no serial console to report errors. If so, moving the I2C initialization to that early point sounds like a really bad idea. Not really - when you see the U-Boot banner the console is working, and we clearly see the U-Boot banner before i2c init happens. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 8/9] tegra: i2c: Enable new CONFIG_SYS_I2C framework
On 07/30/2013 03:19 PM, Simon Glass wrote: Hi Stephen, On Tue, Jul 30, 2013 at 1:22 PM, Stephen Warren swar...@wwwdotorg.org mailto:swar...@wwwdotorg.org wrote: ... I think when init_sequence_f[] is running, there may be no serial console to report errors. If so, moving the I2C initialization to that early point sounds like a really bad idea. Not really - when you see the U-Boot banner the console is working, and we clearly see the U-Boot banner before i2c init happens. I thought it got buffered up and only actually sent to the UART much later, and not in the case when something failed since U-Boot wouldn't get that far? Or, did that proposal get shot down? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 8/9] tegra: i2c: Enable new CONFIG_SYS_I2C framework
Hi Stephen, On Tue, Jul 30, 2013 at 2:00 PM, Stephen Warren swar...@wwwdotorg.orgwrote: On 07/30/2013 01:22 PM, Stephen Warren wrote: On 07/29/2013 10:28 PM, Heiko Schocher wrote: Hello Stephen, Am 29.07.2013 18:12, schrieb Stephen Warren: On 05/04/2013 06:01 AM, Heiko Schocher wrote: From: Simon Glasss...@chromium.org This enables CONFIG_SYS_I2C on Tegra, updating existing boards and the Tegra i2c driver to support this. Heiko, the latest U-Boot tree hangs during boot on Tegra, and git bisect points at this patch. Olof reported the issue to me. Can you take a look at the code and see what might be wrong? Thanks. I suspect some kind of initialization ordering issue, since the boot messages are: - U-Boot SPL 2013.07-rc3-00038-g880540d (Jul 29 2013 - 10:04:37) U-Boot 2013.07-rc3-00038-g880540d (Jul 29 2013 - 10:04:37) TEGRA30 Board: NVIDIA Beaver I2C: Caller requested bad clock: periph=-49, parent=2 - ... and that bad clock message implies to me that the I2C driver is initializing before it has parsed the correct clock ID out of device tree. Hmm... looking in the patch ... I can see nothing which changes some initializing order ... Yes, there's some initialization order issue; before this patch, I see the I2C controller initialization, followed by some usage of it: -- U-Boot SPL 2013.07-rc3-00036-gd84eb85-dirty (Jul 30 2013 - 13:04:47) U-Boot 2013.07-rc3-00036-gd84eb85-dirty (Jul 30 2013 - 13:04:47) TEGRA30 Board: NVIDIA Beaver DRAM: 2 GiB i2c: controller bus 0 at 7000d000, periph_id 47, speed 10: ok i2c: controller bus 1 at 7000c000, periph_id 12, speed 10: ok i2c: controller bus 2 at 7000c400, periph_id 54, speed 10: ok i2c: controller bus 3 at 7000c500, periph_id 67, speed 10: ok i2c: controller bus 4 at 7000c700, periph_id 103, speed 10: ok MMC: i2c_write: chip=0x2d, addr=0x32, len=0x1 -- However with this patch applied, something starts using the controller immediately, without it having been probed from device-tree: -- U-Boot SPL 2013.07-rc3-00037-g1f2ba72-dirty (Jul 30 2013 - 13:08:28) U-Boot 2013.07-rc3-00037-g1f2ba72-dirty (Jul 30 2013 - 13:08:28) TEGRA30 Board: NVIDIA Beaver I2C: i2c_init(speed=10, slaveaddr=0xfe) -- i2c_init touches HW, but since process_nodes() hasn't run, none of the parameters like register address or clock ID are yet known. I think this call comes from init_sequence_f[] - init_func_i2c() - i2c_init() - i2c_init() == __i2c_init() - i2c_init_bus() - I2C_ADAP-init(), although I didn't validate that in the running code, just by code inspection. Oh, with the options Tegra has enabled, perhaps the call sequence is: board_init_f() (which uses init_sequence_f[]) - init_func_i2c() - i2c_init_all(), which then calls: * i2c_init_board(), which is supposed to parse DT * i2c_set_bus_num(), which will call I2C_ADAP-init However, according to the comments near the top of arch/arm/lib/crt0.S, board_init_f() is called in an environment where variable data (.data, .bss) is not available, hence i2c_init_board() cannot possibly operate correctly since its whole purpose is to fill in variable data structures from DT. I suppose you could mark i2c_controllers so that it is in the data section with __attribute__((section(.data))). That's what eynos does, for example. It is valid since SPL or BCT has set up the SDRAM. I think the only way to solve this is not to use DT to instantiate devices, or to move the I2C initialization after relocation etc., although the latter won't work on boards that need I2C up in order to initialize DRAM. It seems like much of U-Boot's initialization architecture simply wasn't designed to accommodate dynamically initializing devices from DT. True, although remember that very little init happens before relocation. Here, I2C has moved to pre-reloc. But the vast majority of it happens after reloc, so the actual impact of this problem is small, and there is a workaround (above). Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/5] SPDX-License-Identifier: coverting more files
Hi Wolfgang, Quoting Wolfgang Denk w...@denx.de: The following patch series converts some more files to the new SPDX License Identifier scheme. Note that some of the patches are non-trivial, i. e. these should be reviewed carefully. This patch series assumes that Roger Meier's previous patch libfdt: SPDX-License-Identifier: GPL-2.0+ BSD-2-Clause (see [1]) has already been applied. [1] http://article.gmane.org/gmane.comp.boot-loaders.u-boot/166531 Wolfgang Denk (5): SPDX-License-Identifier: convert GPL-2.0+ / BSD-2-Clause dual-licensed files SPDX-License-Identifier: fixing some problematic GPL-2.0 files SPDX-License-Identifier: convert PIBS licensed files board/esd/cpci750/mv_eth.c: Fix license SPDX-License-Identifier: convert BSD-3-Clause files Licenses/README| 5 +- Licenses/bsd-3-clause.txt | 24 ++ Licenses/ibm-pibs.txt | 17 +++ arch/arm/include/asm/arch-omap3/gpio.h | 19 +--- arch/arm/include/asm/arch-omap4/gpio.h | 19 +--- arch/arm/include/asm/arch-omap5/gpio.h | 19 +--- arch/arm/include/asm/omap_gpio.h | 19 +--- arch/powerpc/cpu/ppc4xx/4xx_pci.c | 25 +- arch/powerpc/cpu/ppc4xx/4xx_uart.c | 25 +- arch/powerpc/cpu/ppc4xx/miiphy.c | 25 ++ arch/powerpc/cpu/ppc4xx/start.S| 41 + arch/powerpc/include/asm/ppc405.h | 25 ++ arch/powerpc/include/asm/ppc440.h | 25 +- arch/powerpc/include/asm/ppc4xx-emac.h | 25 ++ arch/powerpc/include/asm/ppc4xx-mal.h | 25 ++ arch/powerpc/include/asm/ppc4xx.h | 25 ++ arch/x86/cpu/coreboot/tables.c | 23 +- arch/x86/include/asm/arch-coreboot/sysinfo.h | 23 +- arch/x86/include/asm/arch-coreboot/tables.h| 23 +- board/chromebook-x86/coreboot/config.mk| 32 + board/cray/L1/init.S | 27 ++- board/csb272/init.S| 26 ++- board/csb472/init.S| 26 ++- board/esd/cpci750/mv_eth.c | 17 +-- board/esd/pci405/writeibm.S| 28 ++-- board/jse/init.S | 28 ++-- board/mpl/common/pci.c | 25 ++ board/mpl/mip405/init.S| 26 ++- board/mpl/pip405/init.S| 26 ++- board/sc3/init.S | 31 ++--- board/scb9328/intel.h | 23 +- board/w7o/init.S | 26 ++- common/cmd_ini.c | 25 +- drivers/gpio/omap_gpio.c | 19 +--- drivers/net/4xx_enet.c | 25 ++ drivers/net/npe/IxEthAcc.c | 26 +-- drivers/net/npe/IxEthAccCommon.c | 26 +-- drivers/net/npe/IxEthAccControlInterface.c | 26 +-- drivers/net/npe/IxEthAccDataPlane.c| 26 +-- drivers/net/npe/IxEthAccMac.c | 26 +-- drivers/net/npe/IxEthAccMii.c | 26 +-- drivers/net/npe/IxEthDBAPI.c | 26 +-- drivers/net/npe/IxEthDBAPISupport.c| 26 +-- drivers/net/npe/IxEthDBCore.c | 26 +-- drivers/net/npe/IxEthDBEvents.c| 26 +-- drivers/net/npe/IxEthDBFeatures.c | 26 +-- drivers/net/npe/IxEthDBFirewall.c | 26 +-- drivers/net/npe/IxEthDBHashtable.c | 26 +-- drivers/net/npe/IxEthDBLearning.c | 26 +-- drivers/net/npe/IxEthDBMem.c | 26 +-- drivers/net/npe/IxEthDBNPEAdaptor.c| 26 +-- drivers/net/npe/IxEthDBPortUpdate.c| 26 +-- drivers/net/npe/IxEthDBReports.c | 26 +-- drivers/net/npe/IxEthDBSearch.c| 26 +-- drivers/net/npe/IxEthDBSpanningTree.c | 26 +-- drivers/net/npe/IxEthDBUtil.c | 26 +-- drivers/net/npe/IxEthDBVlan.c | 26 +-- drivers/net/npe/IxEthDBWiFi.c | 26 +-- drivers/net/npe/IxEthMii.c | 26 +-- drivers/net/npe/IxFeatureCtrl.c| 26 +-- drivers/net/npe/IxNpeDl.c | 26 +-- drivers/net/npe/IxNpeDlImageMgr.c
Re: [U-Boot] getline prototype issue
On 07/30/2013 02:17 PM, Simon Glass wrote: Hi York, On Tue, Jul 30, 2013 at 3:12 PM, York Sun york...@freescale.com mailto:york...@freescale.com wrote: Simon, Your patch commit 669dfc2ed8d853d6bcdcafa1de6aca22929465e5 Author: Simon Glass s...@chromium.org mailto:s...@chromium.org Date: Mon Mar 11 06:30:27 2013 + fdt: Ensure that libfdt_env.h comes from U-Boot adds libfdt_env.h to HOSTCPPFLAGS. The causes a problem with one of our older hosts. On the old hosts, getline prototype is protected by #ifdef __USE_GNU This should be OK if the C file has #define _GNU_SOURCE. However, because of your patch, the stdio.h is included before _GNU_SOURCE is defined. The result is warnings like this aisimage.c: In function ‘aisimage_generate’: aisimage.c:313: warning: implicit declaration of function ‘getline’ kwbimage.c: In function ‘kwdimage_set_ext_header’: kwbimage.c:236: warning: implicit declaration of function ‘getline’ imximage.c: In function ‘parse_cfg_file’: imximage.c:430: warning: implicit declaration of function ‘getline’ pblimage.c: In function ‘pbl_parser’: pblimage.c:137: warning: implicit declaration of function ‘getline’ ublimage.c: In function ‘parse_cfg_file’: ublimage.c:179: warning: implicit declaration of function ‘getline’ I took a quick look at this. It seems that many of the host C files in tools/ define _GNU_SOURCE. Should we just move that #define to the Makefile? Adding -D_GNU_SOURCE in Makefile can fix this problem. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 8/9] tegra: i2c: Enable new CONFIG_SYS_I2C framework
On 07/30/2013 03:21 PM, Simon Glass wrote: On Tue, Jul 30, 2013 at 2:00 PM, Stephen Warren swar...@wwwdotorg.org mailto:swar...@wwwdotorg.org wrote: ... Oh, with the options Tegra has enabled, perhaps the call sequence is: board_init_f() (which uses init_sequence_f[]) - init_func_i2c() - i2c_init_all(), which then calls: * i2c_init_board(), which is supposed to parse DT * i2c_set_bus_num(), which will call I2C_ADAP-init However, according to the comments near the top of arch/arm/lib/crt0.S, board_init_f() is called in an environment where variable data (.data, .bss) is not available, hence i2c_init_board() cannot possibly operate correctly since its whole purpose is to fill in variable data structures from DT. I suppose you could mark i2c_controllers so that it is in the data section with __attribute__((section(.data))). That's what eynos does, for example. It is valid since SPL or BCT has set up the SDRAM. Neither .data nor .bss is available. Only .rodata and .text are. In practice, perhaps we can assume that it will work on Tegra because we know the DRAM is already set up, but then that makes Tegra work in some strange special-case way, and completely violates the constraints described in crt0.S. We should be striving to unify how all the different chips work, rather than adding yet more strange special-cases to the initialization sequence to hack around systemic problems. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 03/11] video: Add System-Mode configuration hook into mxsfb
Add hook that allow configuring SmartLCD attached the MXS LCDIF
controller operating in System-Mode. This hook can be overriden
by a platform-specific SmartLCD programming routine, which writes
the SmartLCD specific values into it's registers.
Also, this patch makes sure the SYNC signals are off for the
SmartLCD case.
Signed-off-by: Marek Vasut ma...@denx.de
Cc: Anatolij Gustschin ag...@denx.de
Cc: Fabio Estevam fabio.este...@freescale.com
Cc: Otavio Salvador ota...@ossystems.com.br
Cc: Stefano Babic sba...@denx.de
---
drivers/video/mxsfb.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/video/mxsfb.c b/drivers/video/mxsfb.c
index dbc63a6..78709dd 100644
--- a/drivers/video/mxsfb.c
+++ b/drivers/video/mxsfb.c
@@ -34,6 +34,17 @@
static GraphicDevice panel;
+/**
+ * mxsfb_system_setup() - Fine-tune LCDIF configuration
+ *
+ * This function is used to adjust the LCDIF configuration. This is usually
+ * needed when driving the controller in System-Mode to operate an 8080 or
+ * 6800 connected SmartLCD.
+ */
+__weak void mxsfb_system_setup(void)
+{
+}
+
/*
* DENX M28EVK:
* setenv videomode
@@ -88,6 +99,9 @@ static void mxs_lcd_init(GraphicDevice *panel,
writel(valid_data LCDIF_CTRL1_BYTE_PACKING_FORMAT_OFFSET,
regs-hw_lcdif_ctrl1);
+
+ mxsfb_system_setup();
+
writel((mode-yres LCDIF_TRANSFER_COUNT_V_COUNT_OFFSET) | mode-xres,
regs-hw_lcdif_transfer_count);
@@ -115,8 +129,10 @@ static void mxs_lcd_init(GraphicDevice *panel,
/* Flush FIFO first */
writel(LCDIF_CTRL1_FIFO_CLEAR, regs-hw_lcdif_ctrl1_set);
+#ifndef CONFIG_VIDEO_MXS_MODE_SYSTEM
/* Sync signals ON */
setbits_le32(regs-hw_lcdif_vdctrl4, LCDIF_VDCTRL4_SYNC_SIGNALS_ON);
+#endif
/* FIFO cleared */
writel(LCDIF_CTRL1_FIFO_CLEAR, regs-hw_lcdif_ctrl1_clr);
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 04/11] video: Implement continuous screen refresh for SmartLCD into mxsfb
The LCDIF interface doesn't give us any means to do continuous refresh when driving a SmartLCD. To work this around, we produce a special circular DMA descriptor, which only writes the HW_LCDIF_CTRL0 register and sets the RUN bit. Signed-off-by: Marek Vasut ma...@denx.de Cc: Anatolij Gustschin ag...@denx.de Cc: Fabio Estevam fabio.este...@freescale.com Cc: Otavio Salvador ota...@ossystems.com.br Cc: Stefano Babic sba...@denx.de --- drivers/video/mxsfb.c | 26 ++ 1 file changed, 26 insertions(+) diff --git a/drivers/video/mxsfb.c b/drivers/video/mxsfb.c index 78709dd..98d5264 100644 --- a/drivers/video/mxsfb.c +++ b/drivers/video/mxsfb.c @@ -28,11 +28,14 @@ #include asm/errno.h #include asm/io.h +#include asm/imx-common/dma.h + #include videomodes.h #definePS2KHZ(ps) (10UL / (ps)) static GraphicDevice panel; +struct mxs_dma_desc desc; /** * mxsfb_system_setup() - Fine-tune LCDIF configuration @@ -207,5 +210,28 @@ void *video_hw_init(void) /* Start framebuffer */ mxs_lcd_init(panel, mode, bpp); +#ifdef CONFIG_VIDEO_MXS_MODE_SYSTEM + /* +* If the LCD runs in system mode, the LCD refresh has to be triggered +* manually by setting the RUN bit in HW_LCDIF_CTRL register. To avoid +* having to set this bit manually after every single change in the +* framebuffer memory, we set up specially crafted circular DMA, which +* sets the RUN bit, then waits until it gets cleared and repeats this +* infinitelly. This way, we get smooth continuous updates of the LCD. +*/ + struct mxs_lcdif_regs *regs = (struct mxs_lcdif_regs *)MXS_LCDIF_BASE; + + memset(desc, 0, sizeof(struct mxs_dma_desc)); + desc.address = (dma_addr_t)desc; + desc.cmd.data = MXS_DMA_DESC_COMMAND_NO_DMAXFER | MXS_DMA_DESC_CHAIN | + MXS_DMA_DESC_WAIT4END | + (1 MXS_DMA_DESC_PIO_WORDS_OFFSET); + desc.cmd.pio_words[0] = readl(regs-hw_lcdif_ctrl) | LCDIF_CTRL_RUN; + desc.cmd.next = (uint32_t)desc.cmd; + + /* Execute the DMA chain. */ + mxs_dma_circ_start(MXS_DMA_CHANNEL_AHB_APBH_LCDIF, desc); +#endif + return (void *)panel; } -- 1.7.10.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 00/11] ARM: mxs: Various MX23 adjustments
This patchset implements support for two boards which I have. They have some specific hardware requirements, so they are a nice benchmark for U-Boot on MXS. The patchset can be broken into two parts: First six patches add support for SanDisk Sansa Fuze+ and Creative X-Fi3, both boards based on STMP3780. Note that the i.MX23 is a rebranded STMP3780 with updated BootROM. The second part, consisting of five patches, adds smaller 4x6 font pulled from Linux kernel and fixes CFB console to handle this font correctly. NOTE: This patchset depends on http://patchwork.ozlabs.org/patch/263488/ , which will hopefully be applied shortly. Marek Vasut (11): dma: apbh: Add special circular mode for LCD video: Allocate the MXSFB framebuffer aligned video: Add System-Mode configuration hook into mxsfb video: Implement continuous screen refresh for SmartLCD into mxsfb ARM: mxs: Add Creative ZEN XFi3 board ARM: mxs: Add SanDisk Sansa Fuze+ board video: Encapsulate font in video_font_data.h video: Add small 4x6 font from Linux video: Fix cfb_console for 4-bit wide font ARM: mxs: Enable 4x6 font for X-Fi3 ARM: mxs: Enable 4x6 font for Fuze+ MAINTAINERS |2 + arch/arm/include/asm/imx-common/dma.h|2 + arch/powerpc/cpu/mpc8xx/video.c |1 - board/creative/xfi3/Makefile | 47 + board/creative/xfi3/spl_boot.c | 150 +++ board/creative/xfi3/xfi3.c | 221 +++ board/sandisk/sansa_fuze_plus/Makefile | 47 + board/sandisk/sansa_fuze_plus/sfp.c | 386 ++ board/sandisk/sansa_fuze_plus/spl_boot.c | 155 +++ boards.cfg |2 + common/lcd.c |1 - drivers/dma/apbh_dma.c | 22 + drivers/video/cfb_console.c | 22 +- drivers/video/mxsfb.c| 45 +- drivers/video/sed156x.c |1 - include/configs/sansa_fuze_plus.h| 84 ++ include/configs/xfi3.h | 83 ++ include/video_font.h |9 +- include/video_font_4x6.h | 2154 ++ include/video_font_data.h|5 + 20 files changed, 3430 insertions(+), 9 deletions(-) create mode 100644 board/creative/xfi3/Makefile create mode 100644 board/creative/xfi3/spl_boot.c create mode 100644 board/creative/xfi3/xfi3.c create mode 100644 board/sandisk/sansa_fuze_plus/Makefile create mode 100644 board/sandisk/sansa_fuze_plus/sfp.c create mode 100644 board/sandisk/sansa_fuze_plus/spl_boot.c create mode 100644 include/configs/sansa_fuze_plus.h create mode 100644 include/configs/xfi3.h create mode 100644 include/video_font_4x6.h Cc: Anatolij Gustschin ag...@denx.de Cc: Fabio Estevam fabio.este...@freescale.com Cc: Otavio Salvador ota...@ossystems.com.br Cc: Stefano Babic sba...@denx.de -- 1.7.10.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 02/11] video: Allocate the MXSFB framebuffer aligned
Allocate the framebuffer aligned so it can be flushed
and the flush_dcache_range() function won't complain.
Signed-off-by: Marek Vasut ma...@denx.de
Cc: Anatolij Gustschin ag...@denx.de
Cc: Fabio Estevam fabio.este...@freescale.com
Cc: Otavio Salvador ota...@ossystems.com.br
Cc: Stefano Babic sba...@denx.de
---
drivers/video/mxsfb.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/video/mxsfb.c b/drivers/video/mxsfb.c
index b0f7ef8..dbc63a6 100644
--- a/drivers/video/mxsfb.c
+++ b/drivers/video/mxsfb.c
@@ -174,7 +174,8 @@ void *video_hw_init(void)
panel.memSize = mode.xres * mode.yres * panel.gdfBytesPP;
/* Allocate framebuffer */
- fb = malloc(panel.memSize);
+ fb = memalign(ARCH_DMA_MINALIGN,
+ roundup(panel.memSize, ARCH_DMA_MINALIGN));
if (!fb) {
printf(MXSFB: Error allocating framebuffer!\n);
return NULL;
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 05/11] ARM: mxs: Add Creative ZEN XFi3 board
Add STMP3780-based XFi3 board. This board is a small PMP device
sporting a CPU which was later rebranded to i.MX233 . Currently
supported is USB gadget mode and both external SD and internal
Phison SD-NAND bridge .
Signed-off-by: Marek Vasut ma...@denx.de
Cc: Fabio Estevam fabio.este...@freescale.com
Cc: Otavio Salvador ota...@ossystems.com.br
Cc: Stefano Babic sba...@denx.de
---
MAINTAINERS|1 +
board/creative/xfi3/Makefile | 47 +
board/creative/xfi3/spl_boot.c | 150 +++
board/creative/xfi3/xfi3.c | 221
boards.cfg |1 +
include/configs/xfi3.h | 82 +++
6 files changed, 502 insertions(+)
create mode 100644 board/creative/xfi3/Makefile
create mode 100644 board/creative/xfi3/spl_boot.c
create mode 100644 board/creative/xfi3/xfi3.c
create mode 100644 include/configs/xfi3.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 0a900dc..84c1f61 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -968,6 +968,7 @@ Marek Vasut marek.va...@gmail.com
vpac270 xscale/pxa
zipitz2 xscale/pxa
mx23_olinuxino i.MX23
+ xfi3i.MX23
m28evk i.MX28
sc_sps_1i.MX28
m53evk i.MX53
diff --git a/board/creative/xfi3/Makefile b/board/creative/xfi3/Makefile
new file mode 100644
index 000..c793bfb
--- /dev/null
+++ b/board/creative/xfi3/Makefile
@@ -0,0 +1,47 @@
+#
+# (C) Copyright 2000-2006
+# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+# MA 02111-1307 USA
+#
+
+include $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(BOARD).o
+
+ifndef CONFIG_SPL_BUILD
+COBJS := xfi3.o
+else
+COBJS := spl_boot.o
+endif
+
+SRCS := $(COBJS:.o=.c)
+OBJS := $(addprefix $(obj),$(COBJS))
+
+$(LIB):$(obj).depend $(OBJS)
+ $(call cmd_link_o_target, $(OBJS))
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/creative/xfi3/spl_boot.c b/board/creative/xfi3/spl_boot.c
new file mode 100644
index 000..2d7cb4e
--- /dev/null
+++ b/board/creative/xfi3/spl_boot.c
@@ -0,0 +1,150 @@
+/*
+ * Creative ZEN X-Fi3 setup
+ *
+ * Copyright (C) 2013 Marek Vasut ma...@denx.de
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include common.h
+#include config.h
+#include asm/io.h
+#include asm/arch/iomux-mx23.h
+#include asm/arch/imx-regs.h
+#include asm/arch/sys_proto.h
+
+#defineMUX_CONFIG_EMI (MXS_PAD_1V8 | MXS_PAD_12MA | MXS_PAD_PULLUP)
+#defineMUX_CONFIG_SSP (MXS_PAD_3V3 | MXS_PAD_8MA | MXS_PAD_PULLUP)
+#defineMUX_CONFIG_LCD (MXS_PAD_3V3 | MXS_PAD_4MA | MXS_PAD_NOPULL)
+
+const iomux_cfg_t iomux_setup[] = {
+ /* EMI */
+ MX23_PAD_EMI_D00__EMI_D00 | MUX_CONFIG_EMI,
+ MX23_PAD_EMI_D01__EMI_D01 | MUX_CONFIG_EMI,
+ MX23_PAD_EMI_D02__EMI_D02 | MUX_CONFIG_EMI,
+ MX23_PAD_EMI_D03__EMI_D03 | MUX_CONFIG_EMI,
+ MX23_PAD_EMI_D04__EMI_D04 | MUX_CONFIG_EMI,
+ MX23_PAD_EMI_D05__EMI_D05 | MUX_CONFIG_EMI,
+ MX23_PAD_EMI_D06__EMI_D06 | MUX_CONFIG_EMI,
+ MX23_PAD_EMI_D07__EMI_D07 | MUX_CONFIG_EMI,
+ MX23_PAD_EMI_D08__EMI_D08 | MUX_CONFIG_EMI,
+ MX23_PAD_EMI_D09__EMI_D09 | MUX_CONFIG_EMI,
+
[U-Boot] [PATCH 09/11] video: Fix cfb_console for 4-bit wide font
The cfb_console can't handle 4-bit wide font properly, since with 4-bit wide font, all 8 bits are drawn. Unbreak the video_drawchars() function to correctly render 4-bits only on such fonts. Signed-off-by: Marek Vasut ma...@denx.de Cc: Anatolij Gustschin ag...@denx.de --- drivers/video/cfb_console.c | 21 + 1 file changed, 21 insertions(+) diff --git a/drivers/video/cfb_console.c b/drivers/video/cfb_console.c index edac91c..9110eb5 100644 --- a/drivers/video/cfb_console.c +++ b/drivers/video/cfb_console.c @@ -467,6 +467,10 @@ static void video_drawchars(int xx, int yy, unsigned char *s, int count) ((u32 *) dest)[0] = (video_font_draw_table8[bits 4] eorx) ^ bgx; + + if (VIDEO_FONT_WIDTH == 4) + continue; + ((u32 *) dest)[1] = (video_font_draw_table8[bits 15] eorx) ^ bgx; @@ -492,6 +496,10 @@ static void video_drawchars(int xx, int yy, unsigned char *s, int count) SHORTSWAP32((video_font_draw_table15 [bits 4 3] eorx) ^ bgx); + + if (VIDEO_FONT_WIDTH == 4) + continue; + ((u32 *) dest)[2] = SHORTSWAP32((video_font_draw_table15 [bits 2 3] eorx) ^ @@ -522,6 +530,10 @@ static void video_drawchars(int xx, int yy, unsigned char *s, int count) SHORTSWAP32((video_font_draw_table16 [bits 4 3] eorx) ^ bgx); + + if (VIDEO_FONT_WIDTH == 4) + continue; + ((u32 *) dest)[2] = SHORTSWAP32((video_font_draw_table16 [bits 2 3] eorx) ^ @@ -556,6 +568,11 @@ static void video_drawchars(int xx, int yy, unsigned char *s, int count) ((u32 *) dest)[3] = SWAP32((video_font_draw_table32 [bits 4][3] eorx) ^ bgx); + + + if (VIDEO_FONT_WIDTH == 4) + continue; + ((u32 *) dest)[4] = SWAP32((video_font_draw_table32 [bits 15][0] eorx) ^ bgx); @@ -591,6 +608,10 @@ static void video_drawchars(int xx, int yy, unsigned char *s, int count) ((u32 *) dest)[2] = (video_font_draw_table24[bits 4][2] eorx) ^ bgx; + + if (VIDEO_FONT_WIDTH == 4) + continue; + ((u32 *) dest)[3] = (video_font_draw_table24[bits 15][0] eorx) ^ bgx; -- 1.7.10.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 01/11] dma: apbh: Add special circular mode for LCD
Add special function that executes a specially crafted circular
DMA descriptor. The function doesn't wait for the descriptor to
finish the transfer, since the descritor never finishes. This is
useful when operating a SmartLCD through the LCDIF interface, as
the LCDIF does not give us any means to have continuous refresh
of the SmartLCD. Instead, the RUN bit in the LCDIF CTRL register
must be triggered manually. This can be worked around by starting
an DMA transfer which continuously sets the RUN bit. This function
allows starting exactly such transfer.
Signed-off-by: Marek Vasut ma...@denx.de
Cc: Anatolij Gustschin ag...@denx.de
Cc: Fabio Estevam fabio.este...@freescale.com
Cc: Otavio Salvador ota...@ossystems.com.br
Cc: Stefano Babic sba...@denx.de
---
arch/arm/include/asm/imx-common/dma.h |2 ++
drivers/dma/apbh_dma.c| 22 ++
2 files changed, 24 insertions(+)
diff --git a/arch/arm/include/asm/imx-common/dma.h
b/arch/arm/include/asm/imx-common/dma.h
index cb74528..435aa94 100644
--- a/arch/arm/include/asm/imx-common/dma.h
+++ b/arch/arm/include/asm/imx-common/dma.h
@@ -174,4 +174,6 @@ void mxs_dma_init(void);
int mxs_dma_init_channel(int chan);
int mxs_dma_release(int chan);
+void mxs_dma_circ_start(int chan, struct mxs_dma_desc *pdesc);
+
#endif /* __DMA_H__ */
diff --git a/drivers/dma/apbh_dma.c b/drivers/dma/apbh_dma.c
index 510cb28..f55fbc5 100644
--- a/drivers/dma/apbh_dma.c
+++ b/drivers/dma/apbh_dma.c
@@ -557,6 +557,28 @@ int mxs_dma_go(int chan)
}
/*
+ * Execute a continuously running circular DMA descriptor.
+ * NOTE: This is not intended for general use, but rather
+ * for the LCD driver in Smart-LCD mode. It allows
+ * continuous triggering of the RUN bit there.
+ */
+void mxs_dma_circ_start(int chan, struct mxs_dma_desc *pdesc)
+{
+ struct mxs_apbh_regs *apbh_regs =
+ (struct mxs_apbh_regs *)MXS_APBH_BASE;
+
+ mxs_dma_flush_desc(pdesc);
+
+ mxs_dma_enable_irq(chan, 1);
+
+ writel(mxs_dma_cmd_address(pdesc),
+ apbh_regs-ch[chan].hw_apbh_ch_nxtcmdar);
+ writel(1, apbh_regs-ch[chan].hw_apbh_ch_sema);
+ writel(1 (chan + APBH_CTRL0_CLKGATE_CHANNEL_OFFSET),
+ apbh_regs-hw_apbh_ctrl0_clr);
+}
+
+/*
* Initialize the DMA hardware
*/
void mxs_dma_init(void)
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 11/11] ARM: mxs: Enable 4x6 font for Fuze+
This device has a very small screen and thus can benefit from using smaller font. Enable it. Signed-off-by: Marek Vasut ma...@denx.de Cc: Fabio Estevam fabio.este...@freescale.com Cc: Otavio Salvador ota...@ossystems.com.br Cc: Stefano Babic sba...@denx.de --- include/configs/sansa_fuze_plus.h |1 + 1 file changed, 1 insertion(+) diff --git a/include/configs/sansa_fuze_plus.h b/include/configs/sansa_fuze_plus.h index 05d282d..d950034 100644 --- a/include/configs/sansa_fuze_plus.h +++ b/include/configs/sansa_fuze_plus.h @@ -59,6 +59,7 @@ /* LCD */ #ifdef CONFIG_VIDEO +#define CONFIG_VIDEO_FONT_4X6 #define CONFIG_VIDEO_MXS_MODE_SYSTEM #define CONFIG_SYS_BLACK_IN_WRITE #define LCD_BPPLCD_COLOR16 -- 1.7.10.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 06/11] ARM: mxs: Add SanDisk Sansa Fuze+ board
Add STMP3780-based Sansa Fuze+ board. This board is a small PMP
device sporting a CPU which was later rebranded to i.MX233 .
Currently supported is USB gadget mode and MMC .
Signed-off-by: Marek Vasut ma...@denx.de
Cc: Fabio Estevam fabio.este...@freescale.com
Cc: Otavio Salvador ota...@ossystems.com.br
Cc: Stefano Babic sba...@denx.de
---
MAINTAINERS |1 +
board/sandisk/sansa_fuze_plus/Makefile | 47
board/sandisk/sansa_fuze_plus/sfp.c | 386 ++
board/sandisk/sansa_fuze_plus/spl_boot.c | 155
boards.cfg |1 +
include/configs/sansa_fuze_plus.h| 83 +++
6 files changed, 673 insertions(+)
create mode 100644 board/sandisk/sansa_fuze_plus/Makefile
create mode 100644 board/sandisk/sansa_fuze_plus/sfp.c
create mode 100644 board/sandisk/sansa_fuze_plus/spl_boot.c
create mode 100644 include/configs/sansa_fuze_plus.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 84c1f61..750d6ec 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -969,6 +969,7 @@ Marek Vasut marek.va...@gmail.com
zipitz2 xscale/pxa
mx23_olinuxino i.MX23
xfi3i.MX23
+ sansa_fuze_plus i.MX23
m28evk i.MX28
sc_sps_1i.MX28
m53evk i.MX53
diff --git a/board/sandisk/sansa_fuze_plus/Makefile
b/board/sandisk/sansa_fuze_plus/Makefile
new file mode 100644
index 000..5e46e4c
--- /dev/null
+++ b/board/sandisk/sansa_fuze_plus/Makefile
@@ -0,0 +1,47 @@
+#
+# (C) Copyright 2000-2006
+# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+# MA 02111-1307 USA
+#
+
+include $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(BOARD).o
+
+ifndef CONFIG_SPL_BUILD
+COBJS := sfp.o
+else
+COBJS := spl_boot.o
+endif
+
+SRCS := $(COBJS:.o=.c)
+OBJS := $(addprefix $(obj),$(COBJS))
+
+$(LIB):$(obj).depend $(OBJS)
+ $(call cmd_link_o_target, $(OBJS))
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/sandisk/sansa_fuze_plus/sfp.c
b/board/sandisk/sansa_fuze_plus/sfp.c
new file mode 100644
index 000..a854c7f
--- /dev/null
+++ b/board/sandisk/sansa_fuze_plus/sfp.c
@@ -0,0 +1,386 @@
+/*
+ * SanDisk Sansa Fuze Plus board
+ *
+ * Copyright (C) 2013 Marek Vasut ma...@denx.de
+ *
+ * Hardware investigation done by:
+ *
+ * Amaury Pouly amaury.po...@gmail.com
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include common.h
+#include errno.h
+#include asm/gpio.h
+#include asm/io.h
+#include asm/arch/iomux-mx23.h
+#include asm/arch/imx-regs.h
+#include asm/arch/clock.h
+#include asm/arch/sys_proto.h
+
+DECLARE_GLOBAL_DATA_PTR;
+
+/*
+ * Functions
+ */
+int board_early_init_f(void)
+{
+ /* IO0 clock at 480MHz */
+ mxs_set_ioclk(MXC_IOCLK0, 48);
+
+ /* SSP0 clock at 96MHz */
+ mxs_set_sspclk(MXC_SSPCLK0, 96000, 0);
+
+ return 0;
+}
+
+int dram_init(void)
+{
+ return mxs_dram_init();
+}
+
+#ifdef CONFIG_CMD_MMC
+static int xfi3_mmc_cd(int id)
+{
+ switch (id) {
+ case 0:
+ /* The SSP_DETECT is inverted on this board. */
+ return gpio_get_value(MX23_PAD_SSP1_DETECT__GPIO_2_1);
+ case 1:
+ /* Internal eMMC always
[U-Boot] [PATCH 07/11] video: Encapsulate font in video_font_data.h
This patch moves all the font configuration values into video_font_data.h
so they are all in the right place with the font. The video_font.h now only
includes video_font_data.h and will allow us to select and include different
font once more fonts are added.
Signed-off-by: Marek Vasut ma...@denx.de
Cc: Anatolij Gustschin ag...@denx.de
---
arch/powerpc/cpu/mpc8xx/video.c |1 -
common/lcd.c|1 -
drivers/video/cfb_console.c |1 -
drivers/video/sed156x.c |1 -
include/video_font.h|5 +
include/video_font_data.h |5 +
6 files changed, 6 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/cpu/mpc8xx/video.c b/arch/powerpc/cpu/mpc8xx/video.c
index 1bbf4cc..7725c67 100644
--- a/arch/powerpc/cpu/mpc8xx/video.c
+++ b/arch/powerpc/cpu/mpc8xx/video.c
@@ -125,7 +125,6 @@ DECLARE_GLOBAL_DATA_PTR;
//
#include video_font.h/* Get font data, width and
height */
-#include video_font_data.h
#ifdef CONFIG_VIDEO_LOGO
#include video_logo.h/* Get logo data, width and
height */
diff --git a/common/lcd.c b/common/lcd.c
index 50ea4d6..c886641 100644
--- a/common/lcd.c
+++ b/common/lcd.c
@@ -67,7 +67,6 @@
/* ** FONT DATA
*/
//
#include video_font.h/* Get font data, width and height
*/
-#include video_font_data.h
//
/* ** LOGO DATA
*/
diff --git a/drivers/video/cfb_console.c b/drivers/video/cfb_console.c
index e384b71..edac91c 100644
--- a/drivers/video/cfb_console.c
+++ b/drivers/video/cfb_console.c
@@ -213,7 +213,6 @@
#include linux/types.h
#include stdio_dev.h
#include video_font.h
-#include video_font_data.h
#if defined(CONFIG_CMD_DATE)
#include rtc.h
diff --git a/drivers/video/sed156x.c b/drivers/video/sed156x.c
index a610b74..707250d 100644
--- a/drivers/video/sed156x.c
+++ b/drivers/video/sed156x.c
@@ -41,7 +41,6 @@
/* include the font data */
#include video_font.h
-#include video_font_data.h
#if VIDEO_FONT_WIDTH != 8 || VIDEO_FONT_HEIGHT != 16
#error Expecting VIDEO_FONT_WIDTH == 8 VIDEO_FONT_HEIGHT == 16
diff --git a/include/video_font.h b/include/video_font.h
index 47957c4..bbe62a3 100644
--- a/include/video_font.h
+++ b/include/video_font.h
@@ -24,9 +24,6 @@
#ifndef _VIDEO_FONT_
#define _VIDEO_FONT_
-#define VIDEO_FONT_CHARS 256
-#define VIDEO_FONT_WIDTH 8
-#define VIDEO_FONT_HEIGHT 16
-#define VIDEO_FONT_SIZE(VIDEO_FONT_CHARS * VIDEO_FONT_HEIGHT)
+#include video_font_data.h
#endif /* _VIDEO_FONT_ */
diff --git a/include/video_font_data.h b/include/video_font_data.h
index c7a8b9b..f9e30aa 100644
--- a/include/video_font_data.h
+++ b/include/video_font_data.h
@@ -24,6 +24,11 @@
#ifndef _VIDEO_FONT_DATA_
#define _VIDEO_FONT_DATA_
+#define VIDEO_FONT_CHARS 256
+#define VIDEO_FONT_WIDTH 8
+#define VIDEO_FONT_HEIGHT 16
+#define VIDEO_FONT_SIZE(VIDEO_FONT_CHARS * VIDEO_FONT_HEIGHT)
+
static unsigned char video_fontdata[VIDEO_FONT_SIZE] = {
/* 0 0x00 '^@' */
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 10/11] ARM: mxs: Enable 4x6 font for X-Fi3
This device has a very small screen and thus can benefit from using smaller font. Enable it. Signed-off-by: Marek Vasut ma...@denx.de Cc: Fabio Estevam fabio.este...@freescale.com Cc: Otavio Salvador ota...@ossystems.com.br Cc: Stefano Babic sba...@denx.de --- include/configs/xfi3.h |1 + 1 file changed, 1 insertion(+) diff --git a/include/configs/xfi3.h b/include/configs/xfi3.h index 10facd9..18467f6 100644 --- a/include/configs/xfi3.h +++ b/include/configs/xfi3.h @@ -58,6 +58,7 @@ /* LCD */ #ifdef CONFIG_VIDEO +#define CONFIG_VIDEO_FONT_4X6 #define CONFIG_VIDEO_MXS_MODE_SYSTEM #define CONFIG_SYS_BLACK_IN_WRITE #define LCD_BPPLCD_COLOR16 -- 1.7.10.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] getline prototype issue
On 07/30/2013 02:29 PM, York Sun wrote: On 07/30/2013 02:17 PM, Simon Glass wrote: Hi York, On Tue, Jul 30, 2013 at 3:12 PM, York Sun york...@freescale.com mailto:york...@freescale.com wrote: Simon, Your patch commit 669dfc2ed8d853d6bcdcafa1de6aca22929465e5 Author: Simon Glass s...@chromium.org mailto:s...@chromium.org Date: Mon Mar 11 06:30:27 2013 + fdt: Ensure that libfdt_env.h comes from U-Boot adds libfdt_env.h to HOSTCPPFLAGS. The causes a problem with one of our older hosts. On the old hosts, getline prototype is protected by #ifdef __USE_GNU This should be OK if the C file has #define _GNU_SOURCE. However, because of your patch, the stdio.h is included before _GNU_SOURCE is defined. The result is warnings like this aisimage.c: In function ‘aisimage_generate’: aisimage.c:313: warning: implicit declaration of function ‘getline’ kwbimage.c: In function ‘kwdimage_set_ext_header’: kwbimage.c:236: warning: implicit declaration of function ‘getline’ imximage.c: In function ‘parse_cfg_file’: imximage.c:430: warning: implicit declaration of function ‘getline’ pblimage.c: In function ‘pbl_parser’: pblimage.c:137: warning: implicit declaration of function ‘getline’ ublimage.c: In function ‘parse_cfg_file’: ublimage.c:179: warning: implicit declaration of function ‘getline’ I took a quick look at this. It seems that many of the host C files in tools/ define _GNU_SOURCE. Should we just move that #define to the Makefile? Adding -D_GNU_SOURCE in Makefile can fix this problem. Are you going to send out a patch soon? York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 8/9] tegra: i2c: Enable new CONFIG_SYS_I2C framework
On Tue, Jul 30, 2013 at 3:21 PM, Stephen Warren swar...@wwwdotorg.orgwrote: On 07/30/2013 03:19 PM, Simon Glass wrote: Hi Stephen, On Tue, Jul 30, 2013 at 1:22 PM, Stephen Warren swar...@wwwdotorg.org mailto:swar...@wwwdotorg.org wrote: ... I think when init_sequence_f[] is running, there may be no serial console to report errors. If so, moving the I2C initialization to that early point sounds like a really bad idea. Not really - when you see the U-Boot banner the console is working, and we clearly see the U-Boot banner before i2c init happens. I thought it got buffered up and only actually sent to the UART much later, and not in the case when something failed since U-Boot wouldn't get that far? Or, did that proposal get shot down? There is an option to buffer output until console_init_f() is called, but that is called very early... ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 03/11] video: Add System-Mode configuration hook into mxsfb
On Tue, Jul 30, 2013 at 6:37 PM, Marek Vasut ma...@denx.de wrote:
Add hook that allow configuring SmartLCD attached the MXS LCDIF
controller operating in System-Mode. This hook can be overriden
by a platform-specific SmartLCD programming routine, which writes
the SmartLCD specific values into it's registers.
Also, this patch makes sure the SYNC signals are off for the
SmartLCD case.
Signed-off-by: Marek Vasut ma...@denx.de
Cc: Anatolij Gustschin ag...@denx.de
Cc: Fabio Estevam fabio.este...@freescale.com
Cc: Otavio Salvador ota...@ossystems.com.br
Cc: Stefano Babic sba...@denx.de
---
drivers/video/mxsfb.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/video/mxsfb.c b/drivers/video/mxsfb.c
index dbc63a6..78709dd 100644
--- a/drivers/video/mxsfb.c
+++ b/drivers/video/mxsfb.c
@@ -34,6 +34,17 @@
static GraphicDevice panel;
+/**
+ * mxsfb_system_setup() - Fine-tune LCDIF configuration
+ *
+ * This function is used to adjust the LCDIF configuration. This is usually
+ * needed when driving the controller in System-Mode to operate an 8080 or
+ * 6800 connected SmartLCD.
+ */
+__weak void mxsfb_system_setup(void)
+{
+}
+
/*
* DENX M28EVK:
* setenv videomode
@@ -88,6 +99,9 @@ static void mxs_lcd_init(GraphicDevice *panel,
writel(valid_data LCDIF_CTRL1_BYTE_PACKING_FORMAT_OFFSET,
regs-hw_lcdif_ctrl1);
+
+ mxsfb_system_setup();
+
writel((mode-yres LCDIF_TRANSFER_COUNT_V_COUNT_OFFSET) |
mode-xres,
regs-hw_lcdif_transfer_count);
@@ -115,8 +129,10 @@ static void mxs_lcd_init(GraphicDevice *panel,
/* Flush FIFO first */
writel(LCDIF_CTRL1_FIFO_CLEAR, regs-hw_lcdif_ctrl1_set);
+#ifndef CONFIG_VIDEO_MXS_MODE_SYSTEM
Mode system or System mode?
/* Sync signals ON */
setbits_le32(regs-hw_lcdif_vdctrl4, LCDIF_VDCTRL4_SYNC_SIGNALS_ON);
+#endif
/* FIFO cleared */
writel(LCDIF_CTRL1_FIFO_CLEAR, regs-hw_lcdif_ctrl1_clr);
--
1.7.10.4
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://projetos.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] getline prototype issue
On Tue, Jul 30, 2013 at 3:38 PM, York Sun york...@freescale.com wrote: On 07/30/2013 02:29 PM, York Sun wrote: On 07/30/2013 02:17 PM, Simon Glass wrote: Hi York, On Tue, Jul 30, 2013 at 3:12 PM, York Sun york...@freescale.com mailto:york...@freescale.com wrote: Simon, Your patch commit 669dfc2ed8d853d6bcdcafa1de6aca22929465e5 Author: Simon Glass s...@chromium.org mailto:s...@chromium.org Date: Mon Mar 11 06:30:27 2013 + fdt: Ensure that libfdt_env.h comes from U-Boot adds libfdt_env.h to HOSTCPPFLAGS. The causes a problem with one of our older hosts. On the old hosts, getline prototype is protected by #ifdef __USE_GNU This should be OK if the C file has #define _GNU_SOURCE. However, because of your patch, the stdio.h is included before _GNU_SOURCE is defined. The result is warnings like this aisimage.c: In function ‘aisimage_generate’: aisimage.c:313: warning: implicit declaration of function ‘getline’ kwbimage.c: In function ‘kwdimage_set_ext_header’: kwbimage.c:236: warning: implicit declaration of function ‘getline’ imximage.c: In function ‘parse_cfg_file’: imximage.c:430: warning: implicit declaration of function ‘getline’ pblimage.c: In function ‘pbl_parser’: pblimage.c:137: warning: implicit declaration of function ‘getline’ ublimage.c: In function ‘parse_cfg_file’: ublimage.c:179: warning: implicit declaration of function ‘getline’ I took a quick look at this. It seems that many of the host C files in tools/ define _GNU_SOURCE. Should we just move that #define to the Makefile? Adding -D_GNU_SOURCE in Makefile can fix this problem. Are you going to send out a patch soon? No, but if you do a patch and cc me I will Ack it :-) Sorry but I can't actually test this case here. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 8/9] tegra: i2c: Enable new CONFIG_SYS_I2C framework
On Tue, Jul 30, 2013 at 3:32 PM, Stephen Warren swar...@wwwdotorg.orgwrote: On 07/30/2013 03:21 PM, Simon Glass wrote: On Tue, Jul 30, 2013 at 2:00 PM, Stephen Warren swar...@wwwdotorg.org mailto:swar...@wwwdotorg.org wrote: ... Oh, with the options Tegra has enabled, perhaps the call sequence is: board_init_f() (which uses init_sequence_f[]) - init_func_i2c() - i2c_init_all(), which then calls: * i2c_init_board(), which is supposed to parse DT * i2c_set_bus_num(), which will call I2C_ADAP-init However, according to the comments near the top of arch/arm/lib/crt0.S, board_init_f() is called in an environment where variable data (.data, .bss) is not available, hence i2c_init_board() cannot possibly operate correctly since its whole purpose is to fill in variable data structures from DT. I suppose you could mark i2c_controllers so that it is in the data section with __attribute__((section(.data))). That's what eynos does, for example. It is valid since SPL or BCT has set up the SDRAM. Neither .data nor .bss is available. Only .rodata and .text are. .data is available, honest. We rely on it. During relocation it gets copied. In practice, perhaps we can assume that it will work on Tegra because we know the DRAM is already set up, but then that makes Tegra work in some strange special-case way, and completely violates the constraints described in crt0.S. We should be striving to unify how all the different chips work, rather than adding yet more strange special-cases to the initialization sequence to hack around systemic problems. Sure, this is up to you. I was just suggesting something that works and requires little effort. It isn't pure, agreed. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 05/11] ARM: mxs: Add Creative ZEN XFi3 board
On Tue, Jul 30, 2013 at 6:37 PM, Marek Vasut ma...@denx.de wrote:
Add STMP3780-based XFi3 board. This board is a small PMP device
sporting a CPU which was later rebranded to i.MX233 . Currently
supported is USB gadget mode and both external SD and internal
Phison SD-NAND bridge .
Signed-off-by: Marek Vasut ma...@denx.de
Cc: Fabio Estevam fabio.este...@freescale.com
Cc: Otavio Salvador ota...@ossystems.com.br
Cc: Stefano Babic sba...@denx.de
---
MAINTAINERS|1 +
board/creative/xfi3/Makefile | 47 +
board/creative/xfi3/spl_boot.c | 150 +++
board/creative/xfi3/xfi3.c | 221
boards.cfg |1 +
include/configs/xfi3.h | 82 +++
6 files changed, 502 insertions(+)
create mode 100644 board/creative/xfi3/Makefile
create mode 100644 board/creative/xfi3/spl_boot.c
create mode 100644 board/creative/xfi3/xfi3.c
create mode 100644 include/configs/xfi3.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 0a900dc..84c1f61 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -968,6 +968,7 @@ Marek Vasut marek.va...@gmail.com
vpac270 xscale/pxa
zipitz2 xscale/pxa
mx23_olinuxino i.MX23
+ xfi3i.MX23
m28evk i.MX28
sc_sps_1i.MX28
m53evk i.MX53
diff --git a/board/creative/xfi3/Makefile b/board/creative/xfi3/Makefile
new file mode 100644
index 000..c793bfb
--- /dev/null
+++ b/board/creative/xfi3/Makefile
@@ -0,0 +1,47 @@
+#
+# (C) Copyright 2000-2006
+# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+# MA 02111-1307 USA
+#
+
+include $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(BOARD).o
+
+ifndef CONFIG_SPL_BUILD
+COBJS := xfi3.o
+else
+COBJS := spl_boot.o
+endif
+
+SRCS := $(COBJS:.o=.c)
+OBJS := $(addprefix $(obj),$(COBJS))
+
+$(LIB):$(obj).depend $(OBJS)
+ $(call cmd_link_o_target, $(OBJS))
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/creative/xfi3/spl_boot.c b/board/creative/xfi3/spl_boot.c
new file mode 100644
index 000..2d7cb4e
--- /dev/null
+++ b/board/creative/xfi3/spl_boot.c
@@ -0,0 +1,150 @@
+/*
+ * Creative ZEN X-Fi3 setup
+ *
+ * Copyright (C) 2013 Marek Vasut ma...@denx.de
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include common.h
+#include config.h
+#include asm/io.h
+#include asm/arch/iomux-mx23.h
+#include asm/arch/imx-regs.h
+#include asm/arch/sys_proto.h
+
+#defineMUX_CONFIG_EMI (MXS_PAD_1V8 | MXS_PAD_12MA | MXS_PAD_PULLUP)
+#defineMUX_CONFIG_SSP (MXS_PAD_3V3 | MXS_PAD_8MA | MXS_PAD_PULLUP)
+#defineMUX_CONFIG_LCD (MXS_PAD_3V3 | MXS_PAD_4MA | MXS_PAD_NOPULL)
+
+const iomux_cfg_t iomux_setup[] = {
+ /* EMI */
+ MX23_PAD_EMI_D00__EMI_D00 | MUX_CONFIG_EMI,
+ MX23_PAD_EMI_D01__EMI_D01 | MUX_CONFIG_EMI,
+ MX23_PAD_EMI_D02__EMI_D02 | MUX_CONFIG_EMI,
+ MX23_PAD_EMI_D03__EMI_D03 | MUX_CONFIG_EMI,
+ MX23_PAD_EMI_D04__EMI_D04 | MUX_CONFIG_EMI,
+ MX23_PAD_EMI_D05__EMI_D05 | MUX_CONFIG_EMI,
+
Re: [U-Boot] [PATCH v3 8/9] tegra: i2c: Enable new CONFIG_SYS_I2C framework
On 07/30/2013 03:46 PM, Simon Glass wrote: On Tue, Jul 30, 2013 at 3:32 PM, Stephen Warren swar...@wwwdotorg.org mailto:swar...@wwwdotorg.org wrote: On 07/30/2013 03:21 PM, Simon Glass wrote: On Tue, Jul 30, 2013 at 2:00 PM, Stephen Warren swar...@wwwdotorg.org mailto:swar...@wwwdotorg.org mailto:swar...@wwwdotorg.org mailto:swar...@wwwdotorg.org wrote: ... Oh, with the options Tegra has enabled, perhaps the call sequence is: board_init_f() (which uses init_sequence_f[]) - init_func_i2c() - i2c_init_all(), which then calls: * i2c_init_board(), which is supposed to parse DT * i2c_set_bus_num(), which will call I2C_ADAP-init However, according to the comments near the top of arch/arm/lib/crt0.S, board_init_f() is called in an environment where variable data (.data, .bss) is not available, hence i2c_init_board() cannot possibly operate correctly since its whole purpose is to fill in variable data structures from DT. I suppose you could mark i2c_controllers so that it is in the data section with __attribute__((section(.data))). That's what eynos does, for example. It is valid since SPL or BCT has set up the SDRAM. Neither .data nor .bss is available. Only .rodata and .text are. .data is available, honest. We rely on it. During relocation it gets copied. It gets copied so that it ends up in RAM. It is assumed that before relocation, all .text/.rodata/.data is in ROM and can't be modified, and .bss in inaccessible. Technically that means we could read .data before relocation, but certainly not write to it. Now in practice yes, it does work to write to .data before relocation on platforms where the U-Boot binary isn't actually in flash, but is already in ROM. However as I mention, code cannot rely on that. If any of this isn't true, then the documentation in crt0.S is wrong. I'm CC'ing Albert to see if that's the case. In practice, perhaps we can assume that it will work on Tegra because we know the DRAM is already set up, but then that makes Tegra work in some strange special-case way, and completely violates the constraints described in crt0.S. We should be striving to unify how all the different chips work, rather than adding yet more strange special-cases to the initialization sequence to hack around systemic problems. Sure, this is up to you. I was just suggesting something that works and requires little effort. It isn't pure, agreed. The simplest approach is probably to revert the patch in question, since it clearly violates how U-Boot is supposed to work. It's not really up to me; I think someone like Albert should make the decision since he controls the ARM U-Boot architecture, or Tom as Tegra maintainer, or perhaps you as your patch broke the code. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 8/9] tegra: i2c: Enable new CONFIG_SYS_I2C framework
Hi Stephen, On Tue, Jul 30, 2013 at 3:51 PM, Stephen Warren swar...@wwwdotorg.orgwrote: On 07/30/2013 03:46 PM, Simon Glass wrote: On Tue, Jul 30, 2013 at 3:32 PM, Stephen Warren swar...@wwwdotorg.org mailto:swar...@wwwdotorg.org wrote: On 07/30/2013 03:21 PM, Simon Glass wrote: On Tue, Jul 30, 2013 at 2:00 PM, Stephen Warren swar...@wwwdotorg.org mailto:swar...@wwwdotorg.org mailto:swar...@wwwdotorg.org mailto:swar...@wwwdotorg.org wrote: ... Oh, with the options Tegra has enabled, perhaps the call sequence is: board_init_f() (which uses init_sequence_f[]) - init_func_i2c() - i2c_init_all(), which then calls: * i2c_init_board(), which is supposed to parse DT * i2c_set_bus_num(), which will call I2C_ADAP-init However, according to the comments near the top of arch/arm/lib/crt0.S, board_init_f() is called in an environment where variable data (.data, .bss) is not available, hence i2c_init_board() cannot possibly operate correctly since its whole purpose is to fill in variable data structures from DT. I suppose you could mark i2c_controllers so that it is in the data section with __attribute__((section(.data))). That's what eynos does, for example. It is valid since SPL or BCT has set up the SDRAM. Neither .data nor .bss is available. Only .rodata and .text are. .data is available, honest. We rely on it. During relocation it gets copied. It gets copied so that it ends up in RAM. It is assumed that before relocation, all .text/.rodata/.data is in ROM and can't be modified, and .bss in inaccessible. Technically that means we could read .data before relocation, but certainly not write to it. Now in practice yes, it does work to write to .data before relocation on platforms where the U-Boot binary isn't actually in flash, but is already in ROM. However as I mention, code cannot rely on that. If any of this isn't true, then the documentation in crt0.S is wrong. I'm CC'ing Albert to see if that's the case. In practice in the SPL case (which tegra sort-of uses) there is earlier step before U-Boot which sets up SDRAM, so it is (I think) always true that U-Boot is running from RAM. I guess the longer term plan is to allow some sort of pre-reloc malloc(), which would work for any machine, but I'm not sure if anyone is working on it. In practice, perhaps we can assume that it will work on Tegra because we know the DRAM is already set up, but then that makes Tegra work in some strange special-case way, and completely violates the constraints described in crt0.S. We should be striving to unify how all the different chips work, rather than adding yet more strange special-cases to the initialization sequence to hack around systemic problems. Sure, this is up to you. I was just suggesting something that works and requires little effort. It isn't pure, agreed. The simplest approach is probably to revert the patch in question, since it clearly violates how U-Boot is supposed to work. It's not really up to me; I think someone like Albert should make the decision since he controls the ARM U-Boot architecture, or Tom as Tegra maintainer, or perhaps you as your patch broke the code. My '(just for illustration, please don't merge)' patch from last October? :-) I did offer to look at this for seaboard if it helps, once we agree on a solution, but if you have a solution in mind, please go ahead. Regards, SImon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 8/9] tegra: i2c: Enable new CONFIG_SYS_I2C framework
Hi Stephen, On Tue, 30 Jul 2013 15:51:44 -0600, Stephen Warren swar...@wwwdotorg.org wrote: On 07/30/2013 03:46 PM, Simon Glass wrote: On Tue, Jul 30, 2013 at 3:32 PM, Stephen Warren swar...@wwwdotorg.org mailto:swar...@wwwdotorg.org wrote: On 07/30/2013 03:21 PM, Simon Glass wrote: On Tue, Jul 30, 2013 at 2:00 PM, Stephen Warren swar...@wwwdotorg.org mailto:swar...@wwwdotorg.org mailto:swar...@wwwdotorg.org mailto:swar...@wwwdotorg.org wrote: ... Oh, with the options Tegra has enabled, perhaps the call sequence is: board_init_f() (which uses init_sequence_f[]) - init_func_i2c() - i2c_init_all(), which then calls: * i2c_init_board(), which is supposed to parse DT * i2c_set_bus_num(), which will call I2C_ADAP-init However, according to the comments near the top of arch/arm/lib/crt0.S, board_init_f() is called in an environment where variable data (.data, .bss) is not available, hence i2c_init_board() cannot possibly operate correctly since its whole purpose is to fill in variable data structures from DT. I suppose you could mark i2c_controllers so that it is in the data section with __attribute__((section(.data))). That's what eynos does, for example. It is valid since SPL or BCT has set up the SDRAM. Neither .data nor .bss is available. Only .rodata and .text are. .data is available, honest. We rely on it. During relocation it gets copied. It gets copied so that it ends up in RAM. It is assumed that before relocation, all .text/.rodata/.data is in ROM and can't be modified, and .bss in inaccessible. Technically that means we could read .data before relocation, but certainly not write to it. Indeed, initialized data happens to be readable before relocation, but writing to data, on the other hand, is strictly forbidden. Before relocation, that is, while within board_init_f() the only writable area is GD. Now in practice yes, it does work to write to .data before relocation on platforms where the U-Boot binary isn't actually in flash, but is already in ROM. However as I mention, code cannot rely on that. Already in RAM, not ROM -- and indeed, one should not rely on this. If any of this isn't true, then the documentation in crt0.S is wrong. I'm CC'ing Albert to see if that's the case. In practice, perhaps we can assume that it will work on Tegra because we know the DRAM is already set up, but then that makes Tegra work in some strange special-case way, and completely violates the constraints described in crt0.S. We should be striving to unify how all the different chips work, rather than adding yet more strange special-cases to the initialization sequence to hack around systemic problems. Sure, this is up to you. I was just suggesting something that works and requires little effort. It isn't pure, agreed. The simplest approach is probably to revert the patch in question, since it clearly violates how U-Boot is supposed to work. It's not really up to me; I think someone like Albert should make the decision since he controls the ARM U-Boot architecture, or Tom as Tegra maintainer, or perhaps you as your patch broke the code. board_init_f() is supposed to initialize just enough of the system to allow relocation. Is initializing i2c necessary in this context? Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 8/9] tegra: i2c: Enable new CONFIG_SYS_I2C framework
Hi Albert, On Tue, Jul 30, 2013 at 4:09 PM, Albert ARIBAUD albert.u.b...@aribaud.netwrote: Hi Stephen, On Tue, 30 Jul 2013 15:51:44 -0600, Stephen Warren swar...@wwwdotorg.org wrote: On 07/30/2013 03:46 PM, Simon Glass wrote: On Tue, Jul 30, 2013 at 3:32 PM, Stephen Warren swar...@wwwdotorg.org mailto:swar...@wwwdotorg.org wrote: On 07/30/2013 03:21 PM, Simon Glass wrote: On Tue, Jul 30, 2013 at 2:00 PM, Stephen Warren swar...@wwwdotorg.org mailto:swar...@wwwdotorg.org mailto:swar...@wwwdotorg.org mailto:swar...@wwwdotorg.org wrote: ... Oh, with the options Tegra has enabled, perhaps the call sequence is: board_init_f() (which uses init_sequence_f[]) - init_func_i2c() - i2c_init_all(), which then calls: * i2c_init_board(), which is supposed to parse DT * i2c_set_bus_num(), which will call I2C_ADAP-init However, according to the comments near the top of arch/arm/lib/crt0.S, board_init_f() is called in an environment where variable data (.data, .bss) is not available, hence i2c_init_board() cannot possibly operate correctly since its whole purpose is to fill in variable data structures from DT. I suppose you could mark i2c_controllers so that it is in the data section with __attribute__((section(.data))). That's what eynos does, for example. It is valid since SPL or BCT has set up the SDRAM. Neither .data nor .bss is available. Only .rodata and .text are. .data is available, honest. We rely on it. During relocation it gets copied. It gets copied so that it ends up in RAM. It is assumed that before relocation, all .text/.rodata/.data is in ROM and can't be modified, and .bss in inaccessible. Technically that means we could read .data before relocation, but certainly not write to it. Indeed, initialized data happens to be readable before relocation, but writing to data, on the other hand, is strictly forbidden. Before relocation, that is, while within board_init_f() the only writable area is GD. Now in practice yes, it does work to write to .data before relocation on platforms where the U-Boot binary isn't actually in flash, but is already in ROM. However as I mention, code cannot rely on that. Already in RAM, not ROM -- and indeed, one should not rely on this. If any of this isn't true, then the documentation in crt0.S is wrong. I'm CC'ing Albert to see if that's the case. In practice, perhaps we can assume that it will work on Tegra because we know the DRAM is already set up, but then that makes Tegra work in some strange special-case way, and completely violates the constraints described in crt0.S. We should be striving to unify how all the different chips work, rather than adding yet more strange special-cases to the initialization sequence to hack around systemic problems. Sure, this is up to you. I was just suggesting something that works and requires little effort. It isn't pure, agreed. The simplest approach is probably to revert the patch in question, since it clearly violates how U-Boot is supposed to work. It's not really up to me; I think someone like Albert should make the decision since he controls the ARM U-Boot architecture, or Tom as Tegra maintainer, or perhaps you as your patch broke the code. board_init_f() is supposed to initialize just enough of the system to allow relocation. Is initializing i2c necessary in this context? I'm not sure. There must be some reason for those i2c_init calls in board_init_f() - or are they purely historical? Amicalement, -- Albert. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] tools/Makefile: Move _GNU_SOURCE to Makefile
Commit 669dfc2e adds libfdt_env.h to HOSTCPPFLAGS. It causes stdio.h to be included before _GNU_SOURCE is defined in C files. On some old hosts some prototypes are protected by #ifdef __USE_GNU, which is set when _GNU_SOURCE is defined. Signed-off-by: York Sun york...@freescale.com --- Compiled on powerpc 83xx, 85xx, 86xx paltforms. tools/Makefile |4 +++- tools/aisimage.c |3 --- tools/imximage.c |3 --- tools/kwbimage.c |3 --- tools/mkenvimage.c |3 --- tools/omapimage.c |3 --- tools/pblimage.c |2 -- tools/ublimage.c |3 --- 8 files changed, 3 insertions(+), 21 deletions(-) diff --git a/tools/Makefile b/tools/Makefile index 33fad6b..6d45656 100644 --- a/tools/Makefile +++ b/tools/Makefile @@ -154,6 +154,7 @@ NOPEDOBJS := $(addprefix $(obj),$(NOPED_OBJ_FILES-y)) # # Use native tools and options # Define __KERNEL_STRICT_NAMES to prevent typedef overlaps +# Define _GNU_SOURCE to obtain the getline prototype from stdio.h # HOSTCPPFLAGS = -include $(SRCTREE)/include/libfdt_env.h \ -idirafter $(SRCTREE)/include \ @@ -163,7 +164,8 @@ HOSTCPPFLAGS = -include $(SRCTREE)/include/libfdt_env.h \ -I $(SRCTREE)/tools \ -DCONFIG_SYS_TEXT_BASE=$(CONFIG_SYS_TEXT_BASE) \ -DUSE_HOSTCC \ - -D__KERNEL_STRICT_NAMES + -D__KERNEL_STRICT_NAMES \ + -D_GNU_SOURCE all: $(obj).depend $(BINS) $(LOGO-y) subdirs diff --git a/tools/aisimage.c b/tools/aisimage.c index cd89145..980bf2e 100644 --- a/tools/aisimage.c +++ b/tools/aisimage.c @@ -5,9 +5,6 @@ * SPDX-License-Identifier:GPL-2.0+ */ -/* Required to obtain the getline prototype from stdio.h */ -#define _GNU_SOURCE - #include mkimage.h #include aisimage.h #include image.h diff --git a/tools/imximage.c b/tools/imximage.c index c8a9ad5..cab208b 100644 --- a/tools/imximage.c +++ b/tools/imximage.c @@ -9,9 +9,6 @@ * SPDX-License-Identifier:GPL-2.0+ */ -/* Required to obtain the getline prototype from stdio.h */ -#define _GNU_SOURCE - #include mkimage.h #include image.h #include imximage.h diff --git a/tools/kwbimage.c b/tools/kwbimage.c index d08e498..1df6b20 100644 --- a/tools/kwbimage.c +++ b/tools/kwbimage.c @@ -6,9 +6,6 @@ * SPDX-License-Identifier:GPL-2.0+ */ -/* Required to obtain the getline prototype from stdio.h */ -#define _GNU_SOURCE - #include mkimage.h #include image.h #include kwbimage.h diff --git a/tools/mkenvimage.c b/tools/mkenvimage.c index f685ff2..bbd3041 100644 --- a/tools/mkenvimage.c +++ b/tools/mkenvimage.c @@ -9,9 +9,6 @@ * SPDX-License-Identifier:GPL-2.0+ */ -/* We want the GNU version of basename() */ -#define _GNU_SOURCE - #include errno.h #include fcntl.h #include stdio.h diff --git a/tools/omapimage.c b/tools/omapimage.c index d4d77d8..00853dd 100644 --- a/tools/omapimage.c +++ b/tools/omapimage.c @@ -14,9 +14,6 @@ * SPDX-License-Identifier:GPL-2.0+ */ -/* Required to obtain the getline prototype from stdio.h */ -#define _GNU_SOURCE - #include mkimage.h #include image.h #include omapimage.h diff --git a/tools/pblimage.c b/tools/pblimage.c index 4542a9c..bac5faf 100644 --- a/tools/pblimage.c +++ b/tools/pblimage.c @@ -3,8 +3,6 @@ * * SPDX-License-Identifier:GPL-2.0+ */ -#define _GNU_SOURCE - #include mkimage.h #include image.h #include pblimage.h diff --git a/tools/ublimage.c b/tools/ublimage.c index 6495db6..b4ef7f0 100644 --- a/tools/ublimage.c +++ b/tools/ublimage.c @@ -13,9 +13,6 @@ * SPDX-License-Identifier:GPL-2.0+ */ -/* Required to obtain the getline prototype from stdio.h */ -#define _GNU_SOURCE - #include mkimage.h #include image.h #include ublimage.h -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tools/Makefile: Move _GNU_SOURCE to Makefile
On Tue, Jul 30, 2013 at 4:26 PM, York Sun york...@freescale.com wrote: Commit 669dfc2e adds libfdt_env.h to HOSTCPPFLAGS. It causes stdio.h to be included before _GNU_SOURCE is defined in C files. On some old hosts some prototypes are protected by #ifdef __USE_GNU, which is set when _GNU_SOURCE is defined. Signed-off-by: York Sun york...@freescale.com Acked-by: Simon Glass s...@chromium.org This seems safe enough to me. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 03/11] video: Add System-Mode configuration hook into mxsfb
Dear Otavio Salvador,
On Tue, Jul 30, 2013 at 6:37 PM, Marek Vasut ma...@denx.de wrote:
Add hook that allow configuring SmartLCD attached the MXS LCDIF
controller operating in System-Mode. This hook can be overriden
by a platform-specific SmartLCD programming routine, which writes
the SmartLCD specific values into it's registers.
Also, this patch makes sure the SYNC signals are off for the
SmartLCD case.
Signed-off-by: Marek Vasut ma...@denx.de
Cc: Anatolij Gustschin ag...@denx.de
Cc: Fabio Estevam fabio.este...@freescale.com
Cc: Otavio Salvador ota...@ossystems.com.br
Cc: Stefano Babic sba...@denx.de
---
drivers/video/mxsfb.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/video/mxsfb.c b/drivers/video/mxsfb.c
index dbc63a6..78709dd 100644
--- a/drivers/video/mxsfb.c
+++ b/drivers/video/mxsfb.c
@@ -34,6 +34,17 @@
static GraphicDevice panel;
+/**
+ * mxsfb_system_setup() - Fine-tune LCDIF configuration
+ *
+ * This function is used to adjust the LCDIF configuration. This is
usually + * needed when driving the controller in System-Mode to operate
an 8080 or + * 6800 connected SmartLCD.
+ */
+__weak void mxsfb_system_setup(void)
+{
+}
+
/*
* DENX M28EVK:
* setenv videomode
@@ -88,6 +99,9 @@ static void mxs_lcd_init(GraphicDevice *panel,
writel(valid_data LCDIF_CTRL1_BYTE_PACKING_FORMAT_OFFSET,
regs-hw_lcdif_ctrl1);
+
+ mxsfb_system_setup();
+
writel((mode-yres LCDIF_TRANSFER_COUNT_V_COUNT_OFFSET) |
mode-xres,
regs-hw_lcdif_transfer_count);
@@ -115,8 +129,10 @@ static void mxs_lcd_init(GraphicDevice *panel,
/* Flush FIFO first */
writel(LCDIF_CTRL1_FIFO_CLEAR, regs-hw_lcdif_ctrl1_set);
+#ifndef CONFIG_VIDEO_MXS_MODE_SYSTEM
Mode system or System mode?
This is a name of configuration macro, CONFIG_VIDEO_MXS_MODE_SYSTEM . Otherwise
I do not understand what you are asking about.
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 05/11] ARM: mxs: Add Creative ZEN XFi3 board
Dear Otavio Salvador, [...] + mxsfb_write_register(0x36, 0xaf); + mxsfb_write_register(0x37, 0); + mxsfb_write_register(0x38, 0xdb); + mxsfb_write_register(0x39, 0); + mxsfb_write_register(0x20, 0); + mxsfb_write_register(0x21, 0); + /* Turn on Framebuffer Upload Mode */ + mxsfb_write_byte(0x22, 0); Where does those values come from? The panel datasheet and from Amaury. [...] It'd be nice if you learnt to cut down the email to the relevant part only when replying. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 03/11] video: Add System-Mode configuration hook into mxsfb
On Tue, Jul 30, 2013 at 7:45 PM, Marek Vasut ma...@denx.de wrote:
Dear Otavio Salvador,
On Tue, Jul 30, 2013 at 6:37 PM, Marek Vasut ma...@denx.de wrote:
Add hook that allow configuring SmartLCD attached the MXS LCDIF
controller operating in System-Mode. This hook can be overriden
by a platform-specific SmartLCD programming routine, which writes
the SmartLCD specific values into it's registers.
Also, this patch makes sure the SYNC signals are off for the
SmartLCD case.
Signed-off-by: Marek Vasut ma...@denx.de
Cc: Anatolij Gustschin ag...@denx.de
Cc: Fabio Estevam fabio.este...@freescale.com
Cc: Otavio Salvador ota...@ossystems.com.br
Cc: Stefano Babic sba...@denx.de
---
drivers/video/mxsfb.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/video/mxsfb.c b/drivers/video/mxsfb.c
index dbc63a6..78709dd 100644
--- a/drivers/video/mxsfb.c
+++ b/drivers/video/mxsfb.c
@@ -34,6 +34,17 @@
static GraphicDevice panel;
+/**
+ * mxsfb_system_setup() - Fine-tune LCDIF configuration
+ *
+ * This function is used to adjust the LCDIF configuration. This is
usually + * needed when driving the controller in System-Mode to operate
an 8080 or + * 6800 connected SmartLCD.
+ */
+__weak void mxsfb_system_setup(void)
+{
+}
+
/*
* DENX M28EVK:
* setenv videomode
@@ -88,6 +99,9 @@ static void mxs_lcd_init(GraphicDevice *panel,
writel(valid_data LCDIF_CTRL1_BYTE_PACKING_FORMAT_OFFSET,
regs-hw_lcdif_ctrl1);
+
+ mxsfb_system_setup();
+
writel((mode-yres LCDIF_TRANSFER_COUNT_V_COUNT_OFFSET) |
mode-xres,
regs-hw_lcdif_transfer_count);
@@ -115,8 +129,10 @@ static void mxs_lcd_init(GraphicDevice *panel,
/* Flush FIFO first */
writel(LCDIF_CTRL1_FIFO_CLEAR, regs-hw_lcdif_ctrl1_set);
+#ifndef CONFIG_VIDEO_MXS_MODE_SYSTEM
Mode system or System mode?
This is a name of configuration macro, CONFIG_VIDEO_MXS_MODE_SYSTEM .
Otherwise
I do not understand what you are asking about.
I got this but accordingly to your commitlog it should be
CONFIG_VIDEO_MXS_SYSTEM_MODE to match the description. Any reason to
not use this name?
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://projetos.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 05/11] ARM: mxs: Add Creative ZEN XFi3 board
On Tue, Jul 30, 2013 at 7:46 PM, Marek Vasut ma...@denx.de wrote: Dear Otavio Salvador, [...] + mxsfb_write_register(0x36, 0xaf); + mxsfb_write_register(0x37, 0); + mxsfb_write_register(0x38, 0xdb); + mxsfb_write_register(0x39, 0); + mxsfb_write_register(0x20, 0); + mxsfb_write_register(0x21, 0); + /* Turn on Framebuffer Upload Mode */ + mxsfb_write_byte(0x22, 0); Where does those values come from? The panel datasheet and from Amaury. [...] It'd be nice if you learnt to cut down the email to the relevant part only when replying. Couldn't this use macros to make it easier to read or at least a comment informing where to find those? -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://projetos.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 03/11] video: Add System-Mode configuration hook into mxsfb
Dear Otavio Salvador,
On Tue, Jul 30, 2013 at 7:45 PM, Marek Vasut ma...@denx.de wrote:
Dear Otavio Salvador,
On Tue, Jul 30, 2013 at 6:37 PM, Marek Vasut ma...@denx.de wrote:
Add hook that allow configuring SmartLCD attached the MXS LCDIF
controller operating in System-Mode. This hook can be overriden
by a platform-specific SmartLCD programming routine, which writes
the SmartLCD specific values into it's registers.
Also, this patch makes sure the SYNC signals are off for the
SmartLCD case.
Signed-off-by: Marek Vasut ma...@denx.de
Cc: Anatolij Gustschin ag...@denx.de
Cc: Fabio Estevam fabio.este...@freescale.com
Cc: Otavio Salvador ota...@ossystems.com.br
Cc: Stefano Babic sba...@denx.de
---
drivers/video/mxsfb.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/video/mxsfb.c b/drivers/video/mxsfb.c
index dbc63a6..78709dd 100644
--- a/drivers/video/mxsfb.c
+++ b/drivers/video/mxsfb.c
@@ -34,6 +34,17 @@
static GraphicDevice panel;
+/**
+ * mxsfb_system_setup() - Fine-tune LCDIF configuration
+ *
+ * This function is used to adjust the LCDIF configuration. This is
usually + * needed when driving the controller in System-Mode to
operate an 8080 or + * 6800 connected SmartLCD.
+ */
+__weak void mxsfb_system_setup(void)
+{
+}
+
/*
* DENX M28EVK:
* setenv videomode
@@ -88,6 +99,9 @@ static void mxs_lcd_init(GraphicDevice *panel,
writel(valid_data LCDIF_CTRL1_BYTE_PACKING_FORMAT_OFFSET,
regs-hw_lcdif_ctrl1);
+
+ mxsfb_system_setup();
+
writel((mode-yres LCDIF_TRANSFER_COUNT_V_COUNT_OFFSET) |
mode-xres,
regs-hw_lcdif_transfer_count);
@@ -115,8 +129,10 @@ static void mxs_lcd_init(GraphicDevice *panel,
/* Flush FIFO first */
writel(LCDIF_CTRL1_FIFO_CLEAR, regs-hw_lcdif_ctrl1_set);
+#ifndef CONFIG_VIDEO_MXS_MODE_SYSTEM
Mode system or System mode?
This is a name of configuration macro, CONFIG_VIDEO_MXS_MODE_SYSTEM .
Otherwise I do not understand what you are asking about.
I got this but accordingly to your commitlog it should be
CONFIG_VIDEO_MXS_SYSTEM_MODE to match the description. Any reason to
not use this name?
Sorry, is this name of the macro mentioned in the commit log anywhere? I don't
see it there. I believe grepping for CONFIG_VIDEO_MXS_MODE will make it easier
in the future -- if we were to support more modes -- to find all occurances of
such conditionals.
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 05/11] ARM: mxs: Add Creative ZEN XFi3 board
Dear Otavio Salvador, On Tue, Jul 30, 2013 at 7:46 PM, Marek Vasut ma...@denx.de wrote: Dear Otavio Salvador, [...] + mxsfb_write_register(0x36, 0xaf); + mxsfb_write_register(0x37, 0); + mxsfb_write_register(0x38, 0xdb); + mxsfb_write_register(0x39, 0); + mxsfb_write_register(0x20, 0); + mxsfb_write_register(0x21, 0); + /* Turn on Framebuffer Upload Mode */ + mxsfb_write_byte(0x22, 0); Where does those values come from? The panel datasheet and from Amaury. [...] It'd be nice if you learnt to cut down the email to the relevant part only when replying. Couldn't this use macros to make it easier to read What kind of macros ? Using function call allows the compiler to do type- checking on the data, so no, using macro would be sub-par. or at least a comment informing where to find those? See OTM2201A datasheet for the finer details, yet it will be useless for you since this is rather device-specific configuration. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
