Re: [U-Boot] [PATCH] ARM: OMAP4/5: Change omap4_sdp/panda and omap5_uevm maintainer
On Wednesday 09 July 2014 05:32 PM, Lokesh Vutla wrote: Updating omap4_sdp/panda and omap5_uevm maintainer. Signed-off-by: Lokesh Vutla lokeshvu...@ti.com --- boards.cfg |6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/boards.cfg b/boards.cfg index f16a0e6..1c426e6 100644 --- a/boards.cfg +++ b/boards.cfg @@ -363,13 +363,13 @@ Active arm armv7 omap3 ti evm Active arm armv7 omap3 ti sdp3430 omap3_sdp3430 - Nishanth Menon n...@ti.com Active arm armv7 omap3 timll devkit8000 devkit8000- Thomas Weber we...@corscience.de Active arm armv7 omap4 gumstix duovero duovero - Ash Charles a...@gumstix.com -Active arm armv7 omap4 ti panda omap4_panda - Sricharan R r.sricha...@ti.com -Active arm armv7 omap4 ti sdp4430 omap4_sdp4430 - Sricharan R r.sricha...@ti.com +Active arm armv7 omap4 ti panda omap4_panda - Lokesh Vutla lokeshvu...@ti.com +Active arm armv7 omap4 ti sdp4430 omap4_sdp4430 - Lokesh Vutla lokeshvu...@ti.com Active arm armv7 omap5 compulabcm_t54 cm_t54- Dmitry Lifshitz lifsh...@compulab.co.il Active arm armv7 omap5 ti dra7xx dra7xx_evmdra7xx_evm:CONS_INDEX=1 Lokesh Vutla lokeshvu...@ti.com Active arm armv7 omap5 ti dra7xx dra7xx_evm_qspiboot dra7xx_evm:CONS_INDEX=1,QSPI_BOOT Lokesh Vutla lokeshvu...@ti.com Active arm armv7 omap5 ti dra7xx dra7xx_evm_uart3 dra7xx_evm:CONS_INDEX=3,SPL_YMODEM_SUPPORT Lokesh Vutla lokeshvu...@ti.com -Active arm armv7 omap5 ti omap5_uevm omap5_uevm- - +Active arm armv7 omap5 ti omap5_uevm omap5_uevm- Lokesh Vutla lokeshvu...@ti.com Active arm armv7 rmobile atmark-techno armadillo-800evaarmadillo-800eva - Nobuhiro Iwamatsu nobuhiro.iwamatsu...@renesas.com Active arm armv7 rmobile kmc kzm9g kzm9g - Nobuhiro Iwamatsu nobuhiro.iwamatsu...@renesas.com:Tetsuyuki Kobayashi k...@kmckk.co.jp Active arm armv7 rmobile renesas koelsch koelsch
Re: [U-Boot] [PATCH] DRA7: Add support for ES1.1 silicon ID code
) {
*regs = dra_ddr3_ext_phy_ctrl_const_base_es1_emif1;
*size =
@@ -626,6 +629,7 @@ const struct read_write_regs *get_bug_regs(u32
*iterations)
sizeof(omap5_bug_00339_regs[0]);
break;
case DRA752_ES1_0:
+ case DRA752_ES1_1:
bug_00339_regs_ptr = dra_bug_00339_regs;
*iterations = sizeof(dra_bug_00339_regs)/
sizeof(dra_bug_00339_regs[0]);
diff --git a/arch/arm/include/asm/arch-omap5/omap.h
b/arch/arm/include/asm/arch-omap5/omap.h
index 5be2dee..19fdece 100644
--- a/arch/arm/include/asm/arch-omap5/omap.h
+++ b/arch/arm/include/asm/arch-omap5/omap.h
@@ -44,6 +44,7 @@
#define OMAP5432_CONTROL_ID_CODE_ES1_0 0x0B99802F
#define OMAP5432_CONTROL_ID_CODE_ES2_0 0x1B99802F
#define DRA752_CONTROL_ID_CODE_ES1_0 0x0B99002F
+#define DRA752_CONTROL_ID_CODE_ES1_1 0x1B99002F
/* UART */
#define UART1_BASE (OMAP54XX_L4_PER_BASE + 0x6a000)
diff --git a/arch/arm/include/asm/omap_common.h
b/arch/arm/include/asm/omap_common.h
index a78f990..9b1f495 100644
--- a/arch/arm/include/asm/omap_common.h
+++ b/arch/arm/include/asm/omap_common.h
@@ -643,6 +643,7 @@ static inline u8 is_dra7xx(void)
/* DRA7XX */
#define DRA752_ES1_0 0x07520100
+#define DRA752_ES1_1 0x07520110
/*
* SRAM scratch space entries
Reviewed By: Sricharan R r.sricha...@ti.com
Regards,
Sricharan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] omap4_common: config: remove I2C for SPL mode
Hi Nishanth, On Wednesday 08 January 2014 07:36 AM, Nishanth Menon wrote: Commit 6789e84ecaa8f45d053084e08c381284a04abff7 (i2c, omap24xx: convert driver to new mutlibus/mutliadapter framework) intended to make I2C driver compatible with latest changes. It unfortunately has had a impact on size on SPL as well. For example on SDP4430, 32032 bytes before/MLO 35416 bytes after/MLO With this mentioned commit, MLO stops booting on SDP4430 as only 32K is accessible for non-secure (bootloader) s/w on GP devices and the size increase to 56K fails boot. On the latest u-boot commit e7be18225fbea76d1f0034b224f0d1e60f07cfcf, MLO is now at size 35592 bytes, However, I2C is not necessary for SPL to function as we use SR_I2C for controlling the PMIC. Disabling I2C reduces MLO to 32224 bytes which allows OMAP4 GP platform to boot up. Since this is common for all OMAP4 platforms, remove the need for I2C for SPL builds in the common config. Signed-off-by: Nishanth Menon n...@ti.com --- Though I originally reported this for SDP4430[1], a test on PandaBoard-ES also indicated fail to boot! Tested on PandaBoard-ES and SDP4430 Build result: http://pastebin.mozilla.org/3963101 Test log: SDP4430: http://pastebin.mozilla.org/3963123 PandaBoard-ES: http://pastebin.mozilla.org/3963134 [1] http://marc.info/?l=u-bootm=138914031918099w=2 include/configs/omap4_common.h |6 ++ 1 file changed, 6 insertions(+) diff --git a/include/configs/omap4_common.h b/include/configs/omap4_common.h index ea56eeb..7cfd471 100644 --- a/include/configs/omap4_common.h +++ b/include/configs/omap4_common.h @@ -154,4 +154,10 @@ #define CONFIG_SPL_DISPLAY_PRINT #define CONFIG_SPL_LDSCRIPT $(CPUDIR)/omap-common/u-boot-spl.lds +#ifdef CONFIG_SPL_BUILD +/* No need for i2c in SPL mode as we will use SRI2C for PMIC access on OMAP4 */ +#undef CONFIG_SYS_I2C +#undef CONFIG_SYS_I2C_OMAP24XX +#endif + #endif /* __CONFIG_OMAP4_COMMON_H */ correct. Thanks for the fix. Also with size remaining still as 32224 bytes OMAP4 HS devices might not boot up. Anyways thats separate and something more like this patch has to be removed. Reviewed-by: Sricharan R r.sricha...@ti.com Regards, Sricharan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2 0/3] OMAP5/DRA7: EMIF fixes for lowpower usecases
1) Currently the DDR3 memory on DRA7 ES1.0 evm board is enabled using software leveling. This was done since hardware leveling was not working. Now that the right sequence to do hw leveling is identified, use it. This is required for EMIF clockdomain to idle and come back during lowpower usecases 2) When core power domain hits oswr, then DDR3 memories does not come back while resuming. This is because when EMIF registers are lost, then the controller takes care of copying the values from the shadow registers. If the shadow registers are not updated with the right values, then this results in incorrect settings while resuming. So updating the shadow registers with the corresponding status registers here during the boot. Sricharan R (3): ARM: DRA7: Add is_dra7xx cpu check definition ARM: DRA: EMIF: Change DDR3 settings to use hw leveling ARM: DRA7/OMAP5: EMIF: Add workaround for bug 0039 arch/arm/cpu/armv7/omap-common/emif-common.c | 142 + arch/arm/cpu/armv7/omap5/hw_data.c |9 +- arch/arm/cpu/armv7/omap5/hwinit.c| 12 +- arch/arm/cpu/armv7/omap5/sdram.c | 214 ++ arch/arm/include/asm/arch-omap5/omap.h |1 + arch/arm/include/asm/emif.h | 14 +- arch/arm/include/asm/omap_common.h |8 + 7 files changed, 301 insertions(+), 99 deletions(-) -- 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 1/3] ARM: DRA7: Add is_dra7xx cpu check definition
A generic is_dra7xx cpu check is useful for grouping
all the revisions under that. This is used in the
subsequent patches.
Signed-off-by: Sricharan R r.sricha...@ti.com
---
arch/arm/include/asm/omap_common.h |8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/include/asm/omap_common.h
b/arch/arm/include/asm/omap_common.h
index 3a998cc..3655e5a 100644
--- a/arch/arm/include/asm/omap_common.h
+++ b/arch/arm/include/asm/omap_common.h
@@ -600,6 +600,14 @@ static inline u8 is_omap54xx(void)
extern u32 *const omap_si_rev;
return ((*omap_si_rev 0xFF00) == OMAP54xx);
}
+
+#define DRA7XX 0x0700
+
+static inline u8 is_dra7xx(void)
+{
+ extern u32 *const omap_si_rev;
+ return ((*omap_si_rev 0xFF00) == DRA7XX);
+}
#endif
/*
--
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/3] OMAP5/DRA7: EMIF fixes for lowpower usecases
1) Currently the DDR3 memory on DRA7 ES1.0 evm board is enabled using software leveling. This was done since hardware leveling was not working. Now that the right sequence to do hw leveling is identified, use it. This is required for EMIF clockdomain to idle and come back during lowpower usecases 2) When core power domain hits oswr, then DDR3 memories does not come back while resuming. This is because when EMIF registers are lost, then the controller takes care of copying the values from the shadow registers. If the shadow registers are not updated with the right values, then this results in incorrect settings while resuming. So updating the shadow registers with the corresponding status registers here during the boot. Sricharan R (3): ARM: DRA7: Add is_dra7xx cpu check definition ARM: DRA: EMIF: Change DDR3 settings to use hw leveling ARM: DRA7/OMAP5: EMIF: Add workaround for bug 0039 arch/arm/cpu/armv7/omap-common/emif-common.c | 142 + arch/arm/cpu/armv7/omap5/hw_data.c |9 +- arch/arm/cpu/armv7/omap5/hwinit.c| 12 +- arch/arm/cpu/armv7/omap5/sdram.c | 214 ++ arch/arm/include/asm/arch-omap5/omap.h |1 + arch/arm/include/asm/emif.h | 14 +- arch/arm/include/asm/omap_common.h |8 + 7 files changed, 301 insertions(+), 99 deletions(-) -- 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 3/3] ARM: DRA7/OMAP5: EMIF: Add workaround for bug 0039
When core power domain hits oswr, then DDR3 memories does not come back
while resuming. This is because when EMIF registers are lost, then the
controller takes care of copying the values from the shadow registers.
If the shadow registers are not updated with the right values, then this
results in incorrect settings while resuming. So updating the shadow registers
with the corresponding status registers here during the boot.
Signed-off-by: Sricharan R r.sricha...@ti.com
---
arch/arm/cpu/armv7/omap-common/emif-common.c | 42
arch/arm/cpu/armv7/omap4/sdram_elpida.c |5 ++
arch/arm/cpu/armv7/omap5/sdram.c | 68 ++
arch/arm/include/asm/emif.h | 10 +++-
4 files changed, 124 insertions(+), 1 deletion(-)
diff --git a/arch/arm/cpu/armv7/omap-common/emif-common.c
b/arch/arm/cpu/armv7/omap-common/emif-common.c
index dc1ea1d..5a3f285 100644
--- a/arch/arm/cpu/armv7/omap-common/emif-common.c
+++ b/arch/arm/cpu/armv7/omap-common/emif-common.c
@@ -1286,6 +1286,42 @@ void dmm_init(u32 base)
}
+static void do_bug0039_workaround(u32 base)
+{
+ u32 val, i, clkctrl;
+ struct emif_reg_struct *emif_base = (struct emif_reg_struct *)base;
+ const struct read_write_regs *bug_00339_regs;
+ u32 iterations;
+ u32 *phy_status_base = emif_base-emif_ddr_phy_status[0];
+ u32 *phy_ctrl_base = emif_base-emif_ddr_ext_phy_ctrl_1;
+
+ if (is_dra7xx())
+ phy_status_base++;
+
+ bug_00339_regs = get_bug_regs(iterations);
+
+ /* Put EMIF in to idle */
+ clkctrl = __raw_readl((*prcm)-cm_memif_clkstctrl);
+ __raw_writel(0x0, (*prcm)-cm_memif_clkstctrl);
+
+ /* Copy the phy status registers in to phy ctrl shadow registers */
+ for (i = 0; i iterations; i++) {
+ val = __raw_readl(phy_status_base +
+ bug_00339_regs[i].read_reg - 1);
+
+ __raw_writel(val, phy_ctrl_base +
+((bug_00339_regs[i].write_reg - 1) 1));
+
+ __raw_writel(val, phy_ctrl_base +
+(bug_00339_regs[i].write_reg 1) - 1);
+ }
+
+ /* Disable leveling */
+ writel(0x0, emif_base-emif_rd_wr_lvl_rmp_ctl);
+
+ __raw_writel(clkctrl, (*prcm)-cm_memif_clkstctrl);
+}
+
/*
* SDRAM initialization:
* SDRAM initialization has two parts:
@@ -1361,5 +1397,11 @@ void sdram_init(void)
debug(get_ram_size() successful);
}
+ if (sdram_type == EMIF_SDRAM_TYPE_DDR3
+ (!in_sdram !warm_reset())) {
+ do_bug0039_workaround(EMIF1_BASE);
+ do_bug0039_workaround(EMIF2_BASE);
+ }
+
debug(sdram_init()\n);
}
diff --git a/arch/arm/cpu/armv7/omap4/sdram_elpida.c
b/arch/arm/cpu/armv7/omap4/sdram_elpida.c
index e4c8316..811e776 100644
--- a/arch/arm/cpu/armv7/omap4/sdram_elpida.c
+++ b/arch/arm/cpu/armv7/omap4/sdram_elpida.c
@@ -321,3 +321,8 @@ void get_lpddr2_mr_regs(const struct lpddr2_mr_regs **regs)
{
*regs = mr_regs;
}
+
+__weak const struct read_write_regs *get_bug_regs(u32 *iterations)
+{
+ return 0;
+}
diff --git a/arch/arm/cpu/armv7/omap5/sdram.c b/arch/arm/cpu/armv7/omap5/sdram.c
index 2aae3ef..2e18706 100644
--- a/arch/arm/cpu/armv7/omap5/sdram.c
+++ b/arch/arm/cpu/armv7/omap5/sdram.c
@@ -569,6 +569,74 @@ static const struct lpddr2_device_timings
dev_4G_S4_timings = {
.min_tck= min_tck,
};
+/*
+ * List of status registers to be controlled back to control registers
+ * after initial leveling
+ * readreg, writereg
+ */
+const struct read_write_regs omap5_bug_00339_regs[] = {
+ { 8, 5 },
+ { 9, 6 },
+ { 10, 7 },
+ { 14, 8 },
+ { 15, 9 },
+ { 16, 10 },
+ { 11, 2 },
+ { 12, 3 },
+ { 13, 4 },
+ { 17, 11 },
+ { 18, 12 },
+ { 19, 13 },
+};
+
+const struct read_write_regs dra_bug_00339_regs[] = {
+ { 7, 7 },
+ { 8, 8 },
+ { 9, 9 },
+ { 10, 10 },
+ { 11, 11 },
+ { 12, 2 },
+ { 13, 3 },
+ { 14, 4 },
+ { 15, 5 },
+ { 16, 6 },
+ { 17, 12 },
+ { 18, 13 },
+ { 19, 14 },
+ { 20, 15 },
+ { 21, 16 },
+ { 22, 17 },
+ { 23, 18 },
+ { 24, 19 },
+ { 25, 20 },
+ { 26, 21}
+};
+
+const struct read_write_regs *get_bug_regs(u32 *iterations)
+{
+ const struct read_write_regs *bug_00339_regs_ptr = NULL;
+
+ switch (omap_revision()) {
+ case OMAP5430_ES1_0:
+ case OMAP5430_ES2_0:
+ case OMAP5432_ES1_0:
+ case OMAP5432_ES2_0:
+ bug_00339_regs_ptr = omap5_bug_00339_regs;
+ *iterations = sizeof(omap5_bug_00339_regs)/
+sizeof(omap5_bug_00339_regs[0]);
+ break;
+ case DRA752_ES1_0:
+ bug_00339_regs_ptr = dra_bug_00339_regs;
+ *iterations
[U-Boot] [PATCH V2 2/3] ARM: DRA: EMIF: Change DDR3 settings to use hw leveling
Currently the DDR3 memory on DRA7 ES1.0 evm board is enabled using
software leveling. This was done since hardware leveling was not
working. Now that the right sequence to do hw leveling is identified,
use it. This is required for EMIF clockdomain to idle and come back
during lowpower usecases.
Signed-off-by: Sricharan R r.sricha...@ti.com
---
arch/arm/cpu/armv7/omap-common/emif-common.c | 100 +-
arch/arm/cpu/armv7/omap5/hw_data.c |9 +-
arch/arm/cpu/armv7/omap5/hwinit.c| 12 ++-
arch/arm/cpu/armv7/omap5/sdram.c | 146 +++---
arch/arm/include/asm/arch-omap5/omap.h |1 +
arch/arm/include/asm/emif.h |4 +-
6 files changed, 174 insertions(+), 98 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap-common/emif-common.c
b/arch/arm/cpu/armv7/omap-common/emif-common.c
index b0e1caa..dc1ea1d 100644
--- a/arch/arm/cpu/armv7/omap-common/emif-common.c
+++ b/arch/arm/cpu/armv7/omap-common/emif-common.c
@@ -206,7 +206,7 @@ void emif_update_timings(u32 base, const struct emif_regs
*regs)
}
}
-static void ddr3_leveling(u32 base, const struct emif_regs *regs)
+static void omap5_ddr3_leveling(u32 base, const struct emif_regs *regs)
{
struct emif_reg_struct *emif = (struct emif_reg_struct *)base;
@@ -217,47 +217,86 @@ static void ddr3_leveling(u32 base, const struct
emif_regs *regs)
/*
* Set invert_clkout (if activated)--DDR_PHYCTRL_1
-* Invert clock adds an additional half cycle delay on the command
-* interface. The additional half cycle, is usually meant to enable
-* leveling in the situation that DQS is later than CK on the board.It
-* also helps provide some additional margin for leveling.
+* Invert clock adds an additional half cycle delay on the
+* command interface. The additional half cycle, is usually
+* meant to enable leveling in the situation that DQS is later
+* than CK on the board.It also helps provide some additional
+* margin for leveling.
*/
- writel(regs-emif_ddr_phy_ctlr_1, emif-emif_ddr_phy_ctrl_1);
- writel(regs-emif_ddr_phy_ctlr_1, emif-emif_ddr_phy_ctrl_1_shdw);
+ writel(regs-emif_ddr_phy_ctlr_1,
+ emif-emif_ddr_phy_ctrl_1);
+
+ writel(regs-emif_ddr_phy_ctlr_1,
+ emif-emif_ddr_phy_ctrl_1_shdw);
__udelay(130);
writel(((LP_MODE_DISABLE EMIF_REG_LP_MODE_SHIFT)
-EMIF_REG_LP_MODE_MASK), emif-emif_pwr_mgmt_ctrl);
+ EMIF_REG_LP_MODE_MASK), emif-emif_pwr_mgmt_ctrl);
/* Launch Full leveling */
writel(DDR3_FULL_LVL, emif-emif_rd_wr_lvl_ctl);
/* Wait till full leveling is complete */
readl(emif-emif_rd_wr_lvl_ctl);
- __udelay(130);
+ __udelay(130);
/* Read data eye leveling no of samples */
config_data_eye_leveling_samples(base);
- /* Launch 8 incremental WR_LVL- to compensate for PHY limitation */
- writel(0x2 EMIF_REG_WRLVLINC_INT_SHIFT, emif-emif_rd_wr_lvl_ctl);
+ /*
+* Launch 8 incremental WR_LVL- to compensate for
+* PHY limitation.
+*/
+ writel(0x2 EMIF_REG_WRLVLINC_INT_SHIFT,
+ emif-emif_rd_wr_lvl_ctl);
+
__udelay(130);
/* Launch Incremental leveling */
writel(DDR3_INC_LVL, emif-emif_rd_wr_lvl_ctl);
- __udelay(130);
+ __udelay(130);
}
-static void ddr3_sw_leveling(u32 base, const struct emif_regs *regs)
+static void dra7_ddr3_leveling(u32 base, const struct emif_regs *regs)
{
struct emif_reg_struct *emif = (struct emif_reg_struct *)base;
- writel(regs-emif_ddr_phy_ctlr_1, emif-emif_ddr_phy_ctrl_1);
- writel(regs-emif_ddr_phy_ctlr_1, emif-emif_ddr_phy_ctrl_1_shdw);
+ u32 fifo_reg;
+
+ fifo_reg = readl(emif-emif_ddr_fifo_misaligned_clear_1);
+ writel(fifo_reg | 0x0100,
+ emif-emif_ddr_fifo_misaligned_clear_1);
+
+ fifo_reg = readl(emif-emif_ddr_fifo_misaligned_clear_2);
+ writel(fifo_reg | 0x0100,
+ emif-emif_ddr_fifo_misaligned_clear_2);
+
+ /* Launch Full leveling */
+ writel(DDR3_FULL_LVL, emif-emif_rd_wr_lvl_ctl);
+
+ /* Wait till full leveling is complete */
+ readl(emif-emif_rd_wr_lvl_ctl);
+ __udelay(130);
+
+ /* Read data eye leveling no of samples */
config_data_eye_leveling_samples(base);
- writel(regs-emif_rd_wr_lvl_ctl, emif-emif_rd_wr_lvl_ctl);
- writel(regs-sdram_config, emif-emif_sdram_config);
+ /*
+* Disable leveling. This is because if leveling is kept
+* enabled, then PHY triggers a false leveling during
+* EMIF-idle scenario which results in wrong delay
+* values getting updated. After this the EMIF becomes
+* unaccessible. So disable it after the first time
[U-Boot] [PATCH 0/2] OMAP5/DRA7: EMIF fixes for lowpower usecases
1) Currently the DDR3 memory on DRA7 ES1.0 evm board is enabled using software leveling. This was done since hardware leveling was not working. Now that the right sequence to do hw leveling is identified, use it. This is required for EMIF clockdomain to idle and come back during lowpower usecases 2) When core power domain hits oswr, then DDR3 memories does not come back while resuming. This is because when EMIF registers are lost, then the controller takes care of copying the values from the shadow registers. If the shadow registers are not updated with the right values, then this results in incorrect settings while resuming. So updating the shadow registers with the corresponding status registers here during the boot. Sricharan R (2): ARM: DRA: EMIF: Change DDR3 settings to use hw leveling ARM: DRA7/OMAP5: EMIF: Add workaround for bug 0039 arch/arm/cpu/armv7/omap-common/emif-common.c | 174 ++--- arch/arm/cpu/armv7/omap5/hw_data.c |9 +- arch/arm/cpu/armv7/omap5/hwinit.c| 12 +- arch/arm/cpu/armv7/omap5/sdram.c | 215 ++ arch/arm/include/asm/arch-omap5/omap.h |1 + arch/arm/include/asm/emif.h | 14 +- 6 files changed, 301 insertions(+), 124 deletions(-) -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] ARM: DRA7/OMAP5: EMIF: Add workaround for bug 0039
When core power domain hits oswr, then DDR3 memories does not come back
while resuming. This is because when EMIF registers are lost, then the
controller takes care of copying the values from the shadow registers.
If the shadow registers are not updated with the right values, then this
results in incorrect settings while resuming. So updating the shadow registers
with the corresponding status registers here during the boot.
Signed-off-by: Sricharan R r.sricha...@ti.com
---
arch/arm/cpu/armv7/omap-common/emif-common.c | 41 +++
arch/arm/cpu/armv7/omap5/sdram.c | 69 ++
arch/arm/include/asm/emif.h | 10 +++-
3 files changed, 119 insertions(+), 1 deletion(-)
diff --git a/arch/arm/cpu/armv7/omap-common/emif-common.c
b/arch/arm/cpu/armv7/omap-common/emif-common.c
index c1f5838..cad6ffe 100644
--- a/arch/arm/cpu/armv7/omap-common/emif-common.c
+++ b/arch/arm/cpu/armv7/omap-common/emif-common.c
@@ -1269,6 +1269,42 @@ void dmm_init(u32 base)
}
+static void do_bug0039_workaround(u32 base)
+{
+ u32 val, i, clkctrl;
+ struct emif_reg_struct *emif_base = (struct emif_reg_struct *)base;
+ const struct read_write_regs *bug_00339_regs;
+ u32 iterations;
+ u32 *phy_status_base = emif_base-emif_ddr_phy_status[0];
+ u32 *phy_ctrl_base = emif_base-emif_ddr_ext_phy_ctrl_1;
+
+ if (omap_revision() == DRA752_ES1_0)
+ phy_status_base++;
+
+ bug_00339_regs = get_bug_regs(iterations);
+
+ /* Put EMIF in to idle */
+ clkctrl = __raw_readl((*prcm)-cm_memif_clkstctrl);
+ __raw_writel(0x0, (*prcm)-cm_memif_clkstctrl);
+
+ /* Copy the phy status registers in to phy ctrl shadow registers */
+ for (i = 0; i iterations; i++) {
+ val = __raw_readl(phy_status_base +
+ bug_00339_regs[i].read_reg - 1);
+
+ __raw_writel(val, phy_ctrl_base +
+((bug_00339_regs[i].write_reg - 1) 1));
+
+ __raw_writel(val, phy_ctrl_base +
+(bug_00339_regs[i].write_reg 1) - 1);
+ }
+
+ /* Disable leveling */
+ writel(0x0, emif_base-emif_rd_wr_lvl_rmp_ctl);
+
+ __raw_writel(clkctrl, (*prcm)-cm_memif_clkstctrl);
+}
+
/*
* SDRAM initialization:
* SDRAM initialization has two parts:
@@ -1344,5 +1380,10 @@ void sdram_init(void)
debug(get_ram_size() successful);
}
+ if (!in_sdram !warm_reset()) {
+ do_bug0039_workaround(EMIF1_BASE);
+ do_bug0039_workaround(EMIF2_BASE);
+ }
+
debug(sdram_init()\n);
}
diff --git a/arch/arm/cpu/armv7/omap5/sdram.c b/arch/arm/cpu/armv7/omap5/sdram.c
index 2aae3ef..b5bf196 100644
--- a/arch/arm/cpu/armv7/omap5/sdram.c
+++ b/arch/arm/cpu/armv7/omap5/sdram.c
@@ -569,6 +569,75 @@ static const struct lpddr2_device_timings
dev_4G_S4_timings = {
.min_tck= min_tck,
};
+/*
+ * List of status registers to be controlled back to control registers
+ * after initial leveling
+ * readreg, writereg
+ */
+const struct read_write_regs omap5_bug_00339_regs[] = {
+ { 8, 5 },
+ { 9, 6 },
+ { 10, 7 },
+ { 14, 8 },
+ { 15, 9 },
+ { 16, 10 },
+ { 11, 2 },
+ { 12, 3 },
+ { 13, 4 },
+ { 17, 11 },
+ { 18, 12 },
+ { 19, 13 },
+};
+
+const struct read_write_regs dra_bug_00339_regs[] = {
+ { 7, 7 },
+ { 8, 8 },
+ { 9, 9 },
+ { 10, 10 },
+ { 11, 11 },
+ { 12, 2 },
+ { 13, 3 },
+ { 14, 4 },
+ { 15, 5 },
+ { 16, 6 },
+ { 17, 12 },
+ { 18, 13 },
+ { 19, 14 },
+ { 20, 15 },
+ { 21, 16 },
+ { 22, 17 },
+ { 23, 18 },
+ { 24, 19 },
+ { 25, 20 },
+ { 26, 21}
+};
+
+const struct read_write_regs *get_bug_regs(u32 *iterations)
+{
+ const struct read_write_regs *bug_00339_regs_ptr = NULL;
+
+ switch (omap_revision()) {
+ case OMAP5430_ES1_0:
+ case OMAP5430_ES2_0:
+ case OMAP5432_ES1_0:
+ case OMAP5432_ES2_0:
+ bug_00339_regs_ptr = omap5_bug_00339_regs;
+ *iterations = sizeof(omap5_bug_00339_regs)/
+sizeof(omap5_bug_00339_regs[0]);
+ break;
+ case DRA752_ES1_0:
+ bug_00339_regs_ptr = dra_bug_00339_regs;
+ *iterations = sizeof(dra_bug_00339_regs)/
+sizeof(dra_bug_00339_regs[0]);
+ printf(\n DRA iterations=%d, *iterations);
+ break;
+ default:
+ printf(\n Error: UnKnown SOC);
+ }
+
+ return bug_00339_regs_ptr;
+}
+
void emif_get_device_timings_sdp(u32 emif_nr,
const struct lpddr2_device_timings **cs0_device_timings,
const struct lpddr2_device_timings **cs1_device_timings)
diff --git a/arch/arm/include/asm
[U-Boot] [PATCH 1/2] ARM: DRA: EMIF: Change DDR3 settings to use hw leveling
Currently the DDR3 memory on DRA7 ES1.0 evm board is enabled using
software leveling. This was done since hardware leveling was not
working. Now that the right sequence to do hw leveling is identified,
use it. This is required for EMIF clockdomain to idle and come back
during lowpower usecases.
Signed-off-by: Sricharan R r.sricha...@ti.com
---
arch/arm/cpu/armv7/omap-common/emif-common.c | 133 +--
arch/arm/cpu/armv7/omap5/hw_data.c |9 +-
arch/arm/cpu/armv7/omap5/hwinit.c| 12 ++-
arch/arm/cpu/armv7/omap5/sdram.c | 146 +++---
arch/arm/include/asm/arch-omap5/omap.h |1 +
arch/arm/include/asm/emif.h |4 +-
6 files changed, 182 insertions(+), 123 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap-common/emif-common.c
b/arch/arm/cpu/armv7/omap-common/emif-common.c
index b0e1caa..c1f5838 100644
--- a/arch/arm/cpu/armv7/omap-common/emif-common.c
+++ b/arch/arm/cpu/armv7/omap-common/emif-common.c
@@ -210,54 +210,76 @@ static void ddr3_leveling(u32 base, const struct
emif_regs *regs)
{
struct emif_reg_struct *emif = (struct emif_reg_struct *)base;
- /* keep sdram in self-refresh */
- writel(((LP_MODE_SELF_REFRESH EMIF_REG_LP_MODE_SHIFT)
-EMIF_REG_LP_MODE_MASK), emif-emif_pwr_mgmt_ctrl);
- __udelay(130);
-
- /*
-* Set invert_clkout (if activated)--DDR_PHYCTRL_1
-* Invert clock adds an additional half cycle delay on the command
-* interface. The additional half cycle, is usually meant to enable
-* leveling in the situation that DQS is later than CK on the board.It
-* also helps provide some additional margin for leveling.
-*/
- writel(regs-emif_ddr_phy_ctlr_1, emif-emif_ddr_phy_ctrl_1);
- writel(regs-emif_ddr_phy_ctlr_1, emif-emif_ddr_phy_ctrl_1_shdw);
- __udelay(130);
-
- writel(((LP_MODE_DISABLE EMIF_REG_LP_MODE_SHIFT)
-EMIF_REG_LP_MODE_MASK), emif-emif_pwr_mgmt_ctrl);
-
- /* Launch Full leveling */
- writel(DDR3_FULL_LVL, emif-emif_rd_wr_lvl_ctl);
+ if (omap_revision() != DRA752_ES1_0){
+ /* keep sdram in self-refresh */
+ writel(((LP_MODE_SELF_REFRESH EMIF_REG_LP_MODE_SHIFT)
+EMIF_REG_LP_MODE_MASK), emif-emif_pwr_mgmt_ctrl);
+ __udelay(130);
+
+ /*
+* Set invert_clkout (if activated)--DDR_PHYCTRL_1
+* Invert clock adds an additional half cycle delay on the
+* command interface. The additional half cycle, is usually
+* meant to enable leveling in the situation that DQS is later
+* than CK on the board.It also helps provide some additional
+* margin for leveling.
+*/
+ writel(regs-emif_ddr_phy_ctlr_1,
+ emif-emif_ddr_phy_ctrl_1);
+
+ writel(regs-emif_ddr_phy_ctlr_1,
+ emif-emif_ddr_phy_ctrl_1_shdw);
+ __udelay(130);
+
+ writel(((LP_MODE_DISABLE EMIF_REG_LP_MODE_SHIFT)
+EMIF_REG_LP_MODE_MASK), emif-emif_pwr_mgmt_ctrl);
+
+ /* Launch Full leveling */
+ writel(DDR3_FULL_LVL, emif-emif_rd_wr_lvl_ctl);
+
+ /* Wait till full leveling is complete */
+ readl(emif-emif_rd_wr_lvl_ctl);
+ __udelay(130);
+
+ /* Read data eye leveling no of samples */
+ config_data_eye_leveling_samples(base);
+
+ /*
+* Launch 8 incremental WR_LVL- to compensate for
+* PHY limitation.
+*/
+ writel(0x2 EMIF_REG_WRLVLINC_INT_SHIFT,
+ emif-emif_rd_wr_lvl_ctl);
+
+ __udelay(130);
+
+ /* Launch Incremental leveling */
+ writel(DDR3_INC_LVL, emif-emif_rd_wr_lvl_ctl);
+ __udelay(130);
+ } else {
+ u32 fifo_reg;
- /* Wait till full leveling is complete */
- readl(emif-emif_rd_wr_lvl_ctl);
- __udelay(130);
+ fifo_reg = readl(emif-emif_ddr_fifo_misaligned_clear_1);
+ writel(fifo_reg | 0x0100,
+ emif-emif_ddr_fifo_misaligned_clear_1);
- /* Read data eye leveling no of samples */
- config_data_eye_leveling_samples(base);
+ fifo_reg = readl(emif-emif_ddr_fifo_misaligned_clear_2);
+ writel(fifo_reg | 0x0100,
+ emif-emif_ddr_fifo_misaligned_clear_2);
- /* Launch 8 incremental WR_LVL- to compensate for PHY limitation */
- writel(0x2 EMIF_REG_WRLVLINC_INT_SHIFT, emif-emif_rd_wr_lvl_ctl);
- __udelay(130);
+ /* Launch Full leveling */
+ writel(DDR3_FULL_LVL, emif-emif_rd_wr_lvl_ctl);
- /* Launch Incremental
Re: [U-Boot] [PATCH 1/2] ARM: DRA: EMIF: Change DDR3 settings to use hw leveling
Hi Tom,
On Thursday 07 November 2013 08:33 PM, Tom Rini wrote:
On Thu, Nov 07, 2013 at 08:17:39PM +0530, Sricharan R wrote:
Currently the DDR3 memory on DRA7 ES1.0 evm board is enabled using
software leveling. This was done since hardware leveling was not
working. Now that the right sequence to do hw leveling is identified,
use it. This is required for EMIF clockdomain to idle and come back
during lowpower usecases.
[snip]
@@ -210,54 +210,76 @@ static void ddr3_leveling(u32 base, const struct
emif_regs *regs)
{
struct emif_reg_struct *emif = (struct emif_reg_struct *)base;
-/* keep sdram in self-refresh */
[snip]
+if (omap_revision() != DRA752_ES1_0){
+/* keep sdram in self-refresh */
[snip]
+} else {
+u32 fifo_reg;
[snip]
+/* Disable leveling */
+writel(0x0, emif-emif_rd_wr_lvl_rmp_ctl);
+}
Two things here. First, it seems that now ddr3_leveling has one
sequence for not DRA752_ES1_0 (so likely to get wrong when used on
DRA752 whatever comes after ES1.0) and another for DRA752_ES1_0. This
would be because the it's different EMIF blocks and related HW, so it's
a different sequence, yes? Second, the comment at the end of this
function about Disable leveling seems misleading, but maybe it's just
me. We're saying leveling sequence is complete now, yes?
For the second issue, we can expand / clarify the comment. For the
first issue, maybe we shouldn't have a single ddr3_leveling function
but per family ones? There's nothing in common between the two cases
here, so we're just gaining an indentation level when we could be
excluding code from the final binary instead (either ifdef or maybe just
separate files?).
Yes, i also thought about having a separate function for OMAP5/DRA.
I will do that. For the point about disable leveling, it was intentional.
After we are done with a leveling once during boot, we do not intend to
enable it anymore. We see that the PHY misbehaves by triggering a wrong
leveling sequence when EMIF hits idle, which results in wrong delay values
if it is left enabled. I will add this comment in V2
Regards,
Sricharan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: OMAP5: DDR3: Change io settings
Hi Brad, On Thursday 17 October 2013 08:05 AM, Griffis, Brad wrote: First, Sricharan, thanks for putting together these patches and getting them posted so quickly. I approve of the code but wanted to comment on the commit message. Our previous (internal) thread had a hodge podge of issues, so I think there was some confusion there. In particular this comment was not 100% accurate: 1) The first change from 0x64656465 to 0x64646464 removes the weak pull on the DQ lines. Otherwise the DQ line was not staying at Vref when IDLE (retreats to ground) and because of this there were extra transitions and noise. It removes the weak pullup, yes. However, the DQ line not staying at VREF during IDLE was a different thing altogether and is not affected by this change. That's actually something that is hard-coded as part of the integration of the PHY into the SoC and is not configurable... This particular pullup affects both DQS and nDQS. We don't want to pull differential signals in the same direction. So, bottom line, disabling that weak pullup will improve the signal integrity. (I think I would leave the commit message at that.) 2) The second change was to enable internal VREF_DQ_OUT which otherwise was at 0V. The above description is entirely accurate and I would agree is suitable for the commit message. Here's a bit more detail for the archives... On the uEVM there are 4 DDR3 devices. The VREF for 2 of the devices is powered by the OMAP's VREF_CA_OUT pins. The VREF on the other 2 devices is powered by the OMAP's VREF_DQ_OUT pins. So the net effect here is that only half of the DDR3 devices were being supplied a VREF! This was clearly a mistake. This patch improves the robustness of the interface and was specifically seen to cure corruption observed at high temperatures on some boards. Thanks for the accurate explanation, i will reword it with your suggestions above. Regards, Sricharan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V3] ARM: OMAP5: DDR3: Change io settings
The change from 0x64656465 to 0x64646464 is to remove the weak pull
enabled on DQS, nDQS lines. This pulls the differential signals in the
same direction which is not intended. So disabling the weak pulls improves
signal integrity.
On the uEVM there are 4 DDR3 devices. The VREF for 2 of the devices is powered
by
the OMAP's VREF_CA_OUT pins. The VREF on the other 2 devices is powered by the
OMAP's
VREF_DQ_OUT pins. So the net effect here is that only half of the DDR3 devices
were being
supplied a VREF! This was clearly a mistake. The second change improves the
robustness of
the interface and was specifically seen to cure corruption observed at high
temperatures
on some boards.
With the above two changes better memory stability was observed with extended
temperature ranges around 100C.
Signed-off-by: Sricharan R r.sricha...@ti.com
---
[V3] Added more precise change log as per Griffis Brad bgrif...@ti.com
arch/arm/include/asm/arch-omap5/omap.h |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/arch-omap5/omap.h
b/arch/arm/include/asm/arch-omap5/omap.h
index 414d37a..3c2306f 100644
--- a/arch/arm/include/asm/arch-omap5/omap.h
+++ b/arch/arm/include/asm/arch-omap5/omap.h
@@ -145,9 +145,9 @@ struct s32ktimer {
#define DDR_IO_2_VREF_CELLS_DDR3_VALUE 0x0
#define DDR_IO_I_40OHM_SR_SLOWEST_WD_DQ_NO_PULL_DQS_NO_PULL_ES2 0x7C7C7C7C
-#define DDR_IO_I_40OHM_SR_FAST_WD_DQ_NO_PULL_DQS_NO_PULL_ES2 0x64656465
+#define DDR_IO_I_40OHM_SR_FAST_WD_DQ_NO_PULL_DQS_NO_PULL_ES2 0x64646464
#define DDR_IO_0_VREF_CELLS_DDR3_VALUE_ES2 0xBAE8C631
-#define DDR_IO_1_VREF_CELLS_DDR3_VALUE_ES2 0xB46318D8
+#define DDR_IO_1_VREF_CELLS_DDR3_VALUE_ES2 0xBC6318DC
#define DDR_IO_2_VREF_CELLS_DDR3_VALUE_ES2 0x8421
#define EFUSE_1 0x45145100
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ARM: OMAP5: DDR3: Change io settings
Changing the IO settings to turn on VREF_DQ and
disable weak pullup for DQS/nDQS.
Signed-off-by: Sricharan R r.sricha...@ti.com
---
arch/arm/include/asm/arch-omap5/omap.h |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/arch-omap5/omap.h
b/arch/arm/include/asm/arch-omap5/omap.h
index 414d37a..3c2306f 100644
--- a/arch/arm/include/asm/arch-omap5/omap.h
+++ b/arch/arm/include/asm/arch-omap5/omap.h
@@ -145,9 +145,9 @@ struct s32ktimer {
#define DDR_IO_2_VREF_CELLS_DDR3_VALUE 0x0
#define DDR_IO_I_40OHM_SR_SLOWEST_WD_DQ_NO_PULL_DQS_NO_PULL_ES2 0x7C7C7C7C
-#define DDR_IO_I_40OHM_SR_FAST_WD_DQ_NO_PULL_DQS_NO_PULL_ES2 0x64656465
+#define DDR_IO_I_40OHM_SR_FAST_WD_DQ_NO_PULL_DQS_NO_PULL_ES2 0x64646464
#define DDR_IO_0_VREF_CELLS_DDR3_VALUE_ES2 0xBAE8C631
-#define DDR_IO_1_VREF_CELLS_DDR3_VALUE_ES2 0xB46318D8
+#define DDR_IO_1_VREF_CELLS_DDR3_VALUE_ES2 0xBC6318DC
#define DDR_IO_2_VREF_CELLS_DDR3_VALUE_ES2 0x8421
#define EFUSE_1 0x45145100
--
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] ARM: OMAP5: DDR3: Change io settings
Hi,
On Wednesday 16 October 2013 06:03 PM, Tom Rini wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/16/2013 07:34 AM, Enric Balletbo Serra wrote:
Hi Sricharan,
2013/10/16 Sricharan R r.sricha...@ti.com:
Changing the IO settings to turn on VREF_DQ and
disable weak pullup for DQS/nDQS.
Signed-off-by: Sricharan R r.sricha...@ti.com
---
arch/arm/include/asm/arch-omap5/omap.h |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/arch-omap5/omap.h
b/arch/arm/include/asm/arch-omap5/omap.h
index 414d37a..3c2306f 100644
--- a/arch/arm/include/asm/arch-omap5/omap.h
+++ b/arch/arm/include/asm/arch-omap5/omap.h
@@ -145,9 +145,9 @@ struct s32ktimer {
#define DDR_IO_2_VREF_CELLS_DDR3_VALUE 0x0
#define DDR_IO_I_40OHM_SR_SLOWEST_WD_DQ_NO_PULL_DQS_NO_PULL_ES2 0x7C7C7C7C
-#define DDR_IO_I_40OHM_SR_FAST_WD_DQ_NO_PULL_DQS_NO_PULL_ES2 0x64656465
+#define DDR_IO_I_40OHM_SR_FAST_WD_DQ_NO_PULL_DQS_NO_PULL_ES2 0x64646464
#define DDR_IO_0_VREF_CELLS_DDR3_VALUE_ES2 0xBAE8C631
-#define DDR_IO_1_VREF_CELLS_DDR3_VALUE_ES2 0xB46318D8
+#define DDR_IO_1_VREF_CELLS_DDR3_VALUE_ES2 0xBC6318DC
#define DDR_IO_2_VREF_CELLS_DDR3_VALUE_ES2 0x8421
#define EFUSE_1 0x45145100
Sorry for my ignorance, I just want to know more ...
What's the purpose of this patch ? Solves any DDR3 problem on OMAP5 ?
Improves ?
I suspect I know what this is about, but can we please have a more
verbose commit message here?
Above the two changes improved DDR3 stability at extended temperature
ranges above 83C.
1) The first change from 0x64656465 to 0x64646464 removes the weak pull
on the DQ lines. Otherwise the DQ line was not staying at Vref when IDLE
(retreats
to ground) and because of this there were extra transitions and noise.
2) The second change was to enable internal VREF_DQ_OUT which otherwise was at
0V.
Hope this helps. BTW, i will repost with a better commit log. Sorry.
Regards,
Sricharan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2] ARM: OMAP5: DDR3: Change io settings
The DDR DQ lines are enabled with weak pull. So the DQ line was not staying at
Vref
when IDLE (retreats to ground) and because of this there were extra transitions
and noise. So change from 0x64656465 to 0x64646464 to remove the weak pull.
Also internal VREF_DQOUT is set to 0. This has to enabled as well.
With the above two changes better memory stability was observed with extended
temperature ranges around 100C
Signed-off-by: Sricharan R r.sricha...@ti.com
---
[V2] Added more descriptive commit log
arch/arm/include/asm/arch-omap5/omap.h |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/arch-omap5/omap.h
b/arch/arm/include/asm/arch-omap5/omap.h
index 414d37a..3c2306f 100644
--- a/arch/arm/include/asm/arch-omap5/omap.h
+++ b/arch/arm/include/asm/arch-omap5/omap.h
@@ -145,9 +145,9 @@ struct s32ktimer {
#define DDR_IO_2_VREF_CELLS_DDR3_VALUE 0x0
#define DDR_IO_I_40OHM_SR_SLOWEST_WD_DQ_NO_PULL_DQS_NO_PULL_ES2 0x7C7C7C7C
-#define DDR_IO_I_40OHM_SR_FAST_WD_DQ_NO_PULL_DQS_NO_PULL_ES2 0x64656465
+#define DDR_IO_I_40OHM_SR_FAST_WD_DQ_NO_PULL_DQS_NO_PULL_ES2 0x64646464
#define DDR_IO_0_VREF_CELLS_DDR3_VALUE_ES2 0xBAE8C631
-#define DDR_IO_1_VREF_CELLS_DDR3_VALUE_ES2 0xB46318D8
+#define DDR_IO_1_VREF_CELLS_DDR3_VALUE_ES2 0xBC6318DC
#define DDR_IO_2_VREF_CELLS_DDR3_VALUE_ES2 0x8421
#define EFUSE_1 0x45145100
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL binary too large for OMAP4460 OCM
On Wednesday 04 September 2013 01:01 PM, bin4ry wrote: Hi everybody, I need to add functionality to the SPL code. I tried to implement in a memory-saving way, however, the SPL is about 45 kB after compilation. To get compilation working, I had to set CONFIG_SPL_MAX_SIZE to (45 * 1024). Now, the SPL as well as u-boot won't boot. After the device' (PandaBoard ES - OMAP4460) reset, nothing happens regarding it's output on terminal. My question: is it theoretically possible to to establish a successfully booting SPL with ~45 kB in size for this device? The device' on-chip-memory is 56kB so it could fit in there. If so, what needs to be configured / tuned to get it working? Are there any other features I could omit from the binary to make it smaller? Thanks a lot, -b ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot Do you have a Secure device or GP ? Regards, Sricharan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL binary too large for OMAP4460 OCM
On Wednesday 04 September 2013 02:18 PM, Michael Trimarchi wrote: Hi On Wed, Sep 4, 2013 at 10:44 AM, Sricharan R r.sricha...@ti.com wrote: On Wednesday 04 September 2013 01:01 PM, bin4ry wrote: Hi everybody, I need to add functionality to the SPL code. I tried to implement in a memory-saving way, however, the SPL is about 45 kB after compilation. To get compilation working, I had to set CONFIG_SPL_MAX_SIZE to (45 * 1024). Now, the SPL as well as u-boot won't boot. After the device' (PandaBoard ES - OMAP4460) reset, nothing happens regarding it's output on terminal. My question: is it theoretically possible to to establish a successfully booting SPL with ~45 kB in size for this device? The device' on-chip-memory is 56kB so it could fit in there. If so, what needs to be configured / tuned to get it working? Are there any other features I could omit from the binary to make it smaller? Thanks a lot, -b ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot Do you have a Secure device or GP ? if it is Pandaboard? No he has not. I have increased up to 40Kb and it works with serial boot and sdcard/emmc boot. Sorry i missed to read PANDA. So it is anyways GP. and you changed the CONFIG_SPL_TEXT_BASE as well right ? Regards, Sricharan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL binary too large for OMAP4460 OCM
On Wednesday 04 September 2013 02:34 PM, bin4ry wrote: Am 04.09.2013 10:56, schrieb Sricharan R: On Wednesday 04 September 2013 02:18 PM, Michael Trimarchi wrote: Hi On Wed, Sep 4, 2013 at 10:44 AM, Sricharan R r.sricha...@ti.com wrote: On Wednesday 04 September 2013 01:01 PM, bin4ry wrote: Hi everybody, I need to add functionality to the SPL code. I tried to implement in a memory-saving way, however, the SPL is about 45 kB after compilation. To get compilation working, I had to set CONFIG_SPL_MAX_SIZE to (45 * 1024). Now, the SPL as well as u-boot won't boot. After the device' (PandaBoard ES - OMAP4460) reset, nothing happens regarding it's output on terminal. My question: is it theoretically possible to to establish a successfully booting SPL with ~45 kB in size for this device? The device' on-chip-memory is 56kB so it could fit in there. If so, what needs to be configured / tuned to get it working? Are there any other features I could omit from the binary to make it smaller? Thanks a lot, -b ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot Do you have a Secure device or GP ? if it is Pandaboard? No he has not. I have increased up to 40Kb and it works with serial boot and sdcard/emmc boot. Sorry i missed to read PANDA. So it is anyways GP. and you changed the CONFIG_SPL_TEXT_BASE as well right ? Regards, Sricharan First off, sorry for double-posting to this list. No, the PandaBoard is no HS but a GP device. This is my configuration: /* Defines for SPL */ #define CONFIG_SPL #define CONFIG_SPL_TEXT_BASE0x40303000 #define CONFIG_SPL_MAX_SIZE(45 * 1024) #define CONFIG_SPL_STACKLOW_LEVEL_SRAM_STACK The MLO binary has 46094 Bytes. Actually I should have enough space (from 0x4030 - 0x4030bfff - ~49 kB). However, the device does not start. Right now I am reviewing the code to check, whether it is because of the code and not because of the size that makes u-boot does not start. Can you try by setting CONFIG_SPL_TEXT_BASE 0x40300350 ? Regards, Sricharan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL binary too large for OMAP4460 OCM
On Wednesday 04 September 2013 06:48 PM, Tom Rini wrote: On Wed, Sep 04, 2013 at 11:43:01AM +0300, Oleg Kosheliev wrote: Hi, Andr? From: u-boot-boun...@lists.denx.de [u-boot-boun...@lists.denx.de] on behalf of Andr? Schaller [an.sch...@googlemail.com] Sent: Wednesday, September 04, 2013 10:09 AM To: u-boot@lists.denx.de Subject: [U-Boot] SPL binary too large for OMAP4460 OCM Hi everybody, I need to add functionality to the SPL code. I tried to implement in a memory-saving way, however, the SPL is about 45 kB after compilation. To get compilation working, I had to set CONFIG_SPL_MAX_SIZE to (45 * 1024). Now, the SPL as well as u-boot won't boot. After the device' (PandaBoard ES - OMAP4460) reset, nothing happens regarding it's output on terminal. My question: is it theoretically possible to to establish a successfully booting SPL with ~45 kB in size for this device? The device' on-chip-memory is 56kB so it could fit in there. If so, what needs to be configured / tuned to get it working? Are there any other features I could omit from the binary to make it smaller? Thanks a lot, Andr? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot We can use the area 0x4030 - 0x4030bfff for downloading the SPL image. If the image exceed this - it leads to corrupting the ROM code stack and the device hangs up. See my patch [U-Boot] [RFC PATCH] armv7:omap4-common: Correct check of the SPL image size. (It's not in mainline. I'll do some corrections and send v2 soon.) For HS devices the SPL image is loaded from the address 0x40304350. So we have 0x4030bfff - 0x40304350 = 0x7CAF = 31,919 bytes for SPL. The area from 0x4030 till 0x40304350 in HS devices is used for security data. FWIW, this issue is one reason I think we need to stop trying to make GP devices work kinda-sorta like the HS devices do and instead add a CONFIG for HS devices that sets things correctly. Yes, correct for OMAP4. Regards, Sricharan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] am33xx: Enable D-CACHE on !CONFIG_SYS_DCACHE_OFF
Hi Tom,
On Friday 23 August 2013 09:56 PM, Tom Rini wrote:
Test on Beaglebone white over cpsw, usb ether and SD card (read and
write), performance increased, crc32 of data matches.
Signed-off-by: Tom Rini tr...@ti.com
---
arch/arm/cpu/armv7/am33xx/board.c |8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/cpu/armv7/am33xx/board.c
b/arch/arm/cpu/armv7/am33xx/board.c
index 2ea3d69..c261af5 100644
--- a/arch/arm/cpu/armv7/am33xx/board.c
+++ b/arch/arm/cpu/armv7/am33xx/board.c
@@ -225,3 +225,11 @@ void s_init(void)
sdram_init();
#endif
}
+
+#ifndef CONFIG_SYS_DCACHE_OFF
+void enable_caches(void)
+{
+ /* Enable D-cache. I-cache is already enabled in start.S */
+ dcache_enable();
+}
+#endif /* !CONFIG_SYS_DCACHE_OFF */
This is fine. Do we have secure devices here ?
If so, we should take care of setting the domains permissions for
avoiding prefetch aborts. As it was done for OMAP using
arm_init_domains. So that function and the above should be executed on
am33xx as well.
Thanks to Lokesh for reminding this.
Regards,
Sricharan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: DRA: EMIF: Change DDR3 settings to use hw leveling
Hi Tom, On Wednesday 21 August 2013 09:52 AM, Sricharan R wrote: Hi Tom, On Wednesday 21 August 2013 01:08 AM, Tom Rini wrote: On Tue, Aug 20, 2013 at 06:47:36PM +0530, Sricharan R wrote: Currently the DDR3 memory on DRA7 ES1.0 evm board is enabled using software leveling. This was done since hardware leveling was not working. Now that the right sequence to do hw leveling is identified, use it. This is required for EMIF clockdomain to idle and come back during lowpower usecases. [snip] #ifndef CONFIG_SYS_EMIF_PRECALCULATED_TIMING_REGS OK, so this reminds me, should we be printing out something more now then, when we're calculating timings, rather than using precalculated ones? Or is that a different issue I'm thinking of? This is not something to do with precalculated timings or auto config. This patch is specific only to DDR3 memory and EMIF supports auto leveling feature for DDR3. This feature was disabled for DRA7 till now, but this patch enables that. I want to add one more change in patch. So will send V2 for this. Regards, Sricharan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ARM: DRA: EMIF: Change DDR3 settings to use hw leveling
Currently the DDR3 memory on DRA7 ES1.0 evm board is enabled using
software leveling. This was done since hardware leveling was not
working. Now that the right sequence to do hw leveling is identified,
use it. This is required for EMIF clockdomain to idle and come back
during lowpower usecases.
Boot tested on DRA7 evm, OMAP5 uevm, OMAP4 panda
Signed-off-by: Sricharan R r.sricha...@ti.com
---
arch/arm/cpu/armv7/omap-common/emif-common.c | 96 +
arch/arm/cpu/armv7/omap5/hw_data.c |9 +-
arch/arm/cpu/armv7/omap5/hwinit.c| 12 ++-
arch/arm/cpu/armv7/omap5/sdram.c | 146 +++---
arch/arm/include/asm/arch-omap5/omap.h |1 +
arch/arm/include/asm/emif.h |4 +-
6 files changed, 153 insertions(+), 115 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap-common/emif-common.c
b/arch/arm/cpu/armv7/omap-common/emif-common.c
index 9ede3f5..8ff796a 100644
--- a/arch/arm/cpu/armv7/omap-common/emif-common.c
+++ b/arch/arm/cpu/armv7/omap-common/emif-common.c
@@ -226,24 +226,40 @@ static void ddr3_leveling(u32 base, const struct
emif_regs *regs)
{
struct emif_reg_struct *emif = (struct emif_reg_struct *)base;
- /* keep sdram in self-refresh */
- writel(((LP_MODE_SELF_REFRESH EMIF_REG_LP_MODE_SHIFT)
-EMIF_REG_LP_MODE_MASK), emif-emif_pwr_mgmt_ctrl);
- __udelay(130);
+ if (omap_revision() != DRA752_ES1_0){
+ /* keep sdram in self-refresh */
+ writel(((LP_MODE_SELF_REFRESH EMIF_REG_LP_MODE_SHIFT)
+EMIF_REG_LP_MODE_MASK), emif-emif_pwr_mgmt_ctrl);
+ __udelay(130);
+
+ /*
+* Set invert_clkout (if activated)--DDR_PHYCTRL_1
+* Invert clock adds an additional half cycle delay on the
+* command interface. The additional half cycle, is usually
+* meant to enable leveling in the situation that DQS is later
+* than CK on the board.It also helps provide some additional
+* margin for leveling.
+*/
+ writel(regs-emif_ddr_phy_ctlr_1,
+ emif-emif_ddr_phy_ctrl_1);
+
+ writel(regs-emif_ddr_phy_ctlr_1,
+ emif-emif_ddr_phy_ctrl_1_shdw);
+ __udelay(130);
+
+ writel(((LP_MODE_DISABLE EMIF_REG_LP_MODE_SHIFT)
+EMIF_REG_LP_MODE_MASK), emif-emif_pwr_mgmt_ctrl);
+ } else {
+ u32 fifo_reg;
- /*
-* Set invert_clkout (if activated)--DDR_PHYCTRL_1
-* Invert clock adds an additional half cycle delay on the command
-* interface. The additional half cycle, is usually meant to enable
-* leveling in the situation that DQS is later than CK on the board.It
-* also helps provide some additional margin for leveling.
-*/
- writel(regs-emif_ddr_phy_ctlr_1, emif-emif_ddr_phy_ctrl_1);
- writel(regs-emif_ddr_phy_ctlr_1, emif-emif_ddr_phy_ctrl_1_shdw);
- __udelay(130);
+ fifo_reg = readl(emif-emif_ddr_fifo_misaligned_clear_1);
+ writel(fifo_reg | 0x0100,
+ emif-emif_ddr_fifo_misaligned_clear_1);
- writel(((LP_MODE_DISABLE EMIF_REG_LP_MODE_SHIFT)
-EMIF_REG_LP_MODE_MASK), emif-emif_pwr_mgmt_ctrl);
+ fifo_reg = readl(emif-emif_ddr_fifo_misaligned_clear_2);
+ writel(fifo_reg | 0x0100,
+ emif-emif_ddr_fifo_misaligned_clear_2);
+ }
/* Launch Full leveling */
writel(DDR3_FULL_LVL, emif-emif_rd_wr_lvl_ctl);
@@ -255,25 +271,19 @@ static void ddr3_leveling(u32 base, const struct
emif_regs *regs)
/* Read data eye leveling no of samples */
config_data_eye_leveling_samples(base);
- /* Launch 8 incremental WR_LVL- to compensate for PHY limitation */
- writel(0x2 EMIF_REG_WRLVLINC_INT_SHIFT, emif-emif_rd_wr_lvl_ctl);
- __udelay(130);
-
- /* Launch Incremental leveling */
- writel(DDR3_INC_LVL, emif-emif_rd_wr_lvl_ctl);
- __udelay(130);
-}
-
-static void ddr3_sw_leveling(u32 base, const struct emif_regs *regs)
-{
- struct emif_reg_struct *emif = (struct emif_reg_struct *)base;
-
- writel(regs-emif_ddr_phy_ctlr_1, emif-emif_ddr_phy_ctrl_1);
- writel(regs-emif_ddr_phy_ctlr_1, emif-emif_ddr_phy_ctrl_1_shdw);
- config_data_eye_leveling_samples(base);
-
- writel(regs-emif_rd_wr_lvl_ctl, emif-emif_rd_wr_lvl_ctl);
- writel(regs-sdram_config, emif-emif_sdram_config);
+ if (omap_revision() == DRA752_ES1_0) {
+ /*
+* Launch 8 incremental WR_LVL- to compensate
+* for PHY limitation
+*/
+ writel(0x2 EMIF_REG_WRLVLINC_INT_SHIFT,
+ emif-emif_rd_wr_lvl_ctl);
+ __udelay(130
Re: [U-Boot] [PATCH] ARM: DRA: EMIF: Change DDR3 settings to use hw leveling
Hi Tom, On Wednesday 21 August 2013 01:08 AM, Tom Rini wrote: On Tue, Aug 20, 2013 at 06:47:36PM +0530, Sricharan R wrote: Currently the DDR3 memory on DRA7 ES1.0 evm board is enabled using software leveling. This was done since hardware leveling was not working. Now that the right sequence to do hw leveling is identified, use it. This is required for EMIF clockdomain to idle and come back during lowpower usecases. [snip] #ifndef CONFIG_SYS_EMIF_PRECALCULATED_TIMING_REGS OK, so this reminds me, should we be printing out something more now then, when we're calculating timings, rather than using precalculated ones? Or is that a different issue I'm thinking of? This is not something to do with precalculated timings or auto config. This patch is specific only to DDR3 memory and EMIF supports auto leveling feature for DDR3. This feature was disabled for DRA7 till now, but this patch enables that. Regards, Sricharan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 03/12] omap5: Expand CONFIG_SPL_MAX_SIZE and comment upon SRAM_SCRATCH_SPACE_ADDR
Hi Tom,
On Tuesday 20 August 2013 06:23 PM, Tom Rini wrote:
After examining both TRMs and doing some experimentation, we can rely on
using the start of the download area for CONFIG_SPL_TEXT_BASE and then
move SRAM_SCRATCH_SPACE_ADDR up, just like am335x. This is required for
peripheral boot modes such as UART.
Signed-off-by: Tom Rini tr...@ti.com
---
arch/arm/include/asm/arch-omap5/omap.h | 11 ++-
include/configs/omap5_common.h |4 ++--
2 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/arch/arm/include/asm/arch-omap5/omap.h
b/arch/arm/include/asm/arch-omap5/omap.h
index 597c692..e9a51d3 100644
--- a/arch/arm/include/asm/arch-omap5/omap.h
+++ b/arch/arm/include/asm/arch-omap5/omap.h
@@ -153,6 +153,15 @@ struct s32ktimer {
#define EFUSE_4 0x45145100
#endif /* __ASSEMBLY__ */
+/*
+ * In all cases, the TRM defines the RAM Memory Map for the processor
+ * and indicates the area for the downloaded image. We use all of that
+ * space for download and once up and running may use other parts of the
+ * map for our needs. We set a scratch space that is at the end of the
+ * OMAP5 download area, but within the DRA7xx download area (as it is
+ * much larger) and do not, at this time, make use of the additional
+ * space.
+ */
#ifdef CONFIG_DRA7XX
#define NON_SECURE_SRAM_START0x4030
#define NON_SECURE_SRAM_END 0x4038 /* Not inclusive */
@@ -160,7 +169,7 @@ struct s32ktimer {
#define NON_SECURE_SRAM_START0x4030
#define NON_SECURE_SRAM_END 0x4032 /* Not inclusive */
#endif
-#define SRAM_SCRATCH_SPACE_ADDR NON_SECURE_SRAM_START
+#define SRAM_SCRATCH_SPACE_ADDR 0x4031E000
/* base address for indirect vectors (internal boot mode) */
#define SRAM_ROM_VECT_BASE 0x4031F000
diff --git a/include/configs/omap5_common.h b/include/configs/omap5_common.h
index 8e82fed..0345c57 100644
--- a/include/configs/omap5_common.h
+++ b/include/configs/omap5_common.h
@@ -128,8 +128,8 @@
/* Defines for SPL */
-#define CONFIG_SPL_TEXT_BASE 0x40300350
-#define CONFIG_SPL_MAX_SIZE 0x19000 /* 100K */
+#define CONFIG_SPL_TEXT_BASE 0x4030
+#define CONFIG_SPL_MAX_SIZE (0x4031E000 - CONFIG_SPL_TEXT_BASE)
#define CONFIG_SPL_DISPLAY_PRINT
#define CONFIG_SPL_LDSCRIPT $(CPUDIR)/omap-common/u-boot-spl.lds
Ok, we keep the SPL stack at
#define CONFIG_SYS_INIT_SP_ADDR (NON_SECURE_SRAM_END -
GENERATED_GBL_DATA_SIZE)
So does this now create any possiblity of STACK overlap with the SCRATCH PAD
area ? or
since we have 8K at TOP, this is enough to avoid overlap ?
Is it good to keep NON_SECURE_SRAM_END 0x4031E000 otherwise ?
Also with the base address change to 0x4030, wanted to check this once on
HS devices.
I can check this and let you know.
Regards,
Sricharan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [[PATCH v2 3/6] ARM: OMAP5: USB: Add OMAP5 common USB EHCI information
On Thursday 11 July 2013 01:28 PM, Roger Quadros wrote: On 07/11/2013 06:51 AM, Lokesh Vutla wrote: On Thursday 11 July 2013 01:35 AM, Dan Murphy wrote: * Enable the OMAP5 EHCI host clocks * Add OMAP5 EHCI register definitions * Add OMAP5 ES2 host revision Signed-off-by: Dan Murphy dmur...@ti.com --- arch/arm/cpu/armv7/omap5/hw_data.c | 13 ++ arch/arm/include/asm/arch-omap5/clock.h |6 + arch/arm/include/asm/arch-omap5/ehci.h | 43 +++ arch/arm/include/asm/ehci-omap.h|1 + drivers/usb/host/ehci-omap.c|2 +- 5 files changed, 64 insertions(+), 1 deletion(-) create mode 100644 arch/arm/include/asm/arch-omap5/ehci.h diff --git a/arch/arm/cpu/armv7/omap5/hw_data.c b/arch/arm/cpu/armv7/omap5/hw_data.c index 56cf1f8..055f058 100644 --- a/arch/arm/cpu/armv7/omap5/hw_data.c +++ b/arch/arm/cpu/armv7/omap5/hw_data.c @@ -412,6 +412,8 @@ void enable_basic_clocks(void) (*prcm)-cm_l4per_gpio4_clkctrl, (*prcm)-cm_l4per_gpio5_clkctrl, (*prcm)-cm_l4per_gpio6_clkctrl, + (*prcm)-cm_clksel_usb_60mhz, + (*prcm)-cm_l3init_hsusbtll_clkctrl, guard this with CONFIG_USB_EHCI please or it ll throw an error for DRA7xx boards. why is DRA7xx using omap5/hw_data.c? doesn't it qualify for its own SoC directory? We tried to keep common things for OMAP5/DRA intact and added the difference. The above clocks list was same for both. In fact there is no armv7/dra directory at all. Regards, Sricharan 0 }; cheers, -roger ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [[PATCH v2 3/6] ARM: OMAP5: USB: Add OMAP5 common USB EHCI information
On Thursday 11 July 2013 02:25 PM, Roger Quadros wrote: On 07/11/2013 11:35 AM, Sricharan R wrote: On Thursday 11 July 2013 01:28 PM, Roger Quadros wrote: On 07/11/2013 06:51 AM, Lokesh Vutla wrote: On Thursday 11 July 2013 01:35 AM, Dan Murphy wrote: * Enable the OMAP5 EHCI host clocks * Add OMAP5 EHCI register definitions * Add OMAP5 ES2 host revision Signed-off-by: Dan Murphy dmur...@ti.com --- arch/arm/cpu/armv7/omap5/hw_data.c | 13 ++ arch/arm/include/asm/arch-omap5/clock.h |6 + arch/arm/include/asm/arch-omap5/ehci.h | 43 +++ arch/arm/include/asm/ehci-omap.h|1 + drivers/usb/host/ehci-omap.c|2 +- 5 files changed, 64 insertions(+), 1 deletion(-) create mode 100644 arch/arm/include/asm/arch-omap5/ehci.h diff --git a/arch/arm/cpu/armv7/omap5/hw_data.c b/arch/arm/cpu/armv7/omap5/hw_data.c index 56cf1f8..055f058 100644 --- a/arch/arm/cpu/armv7/omap5/hw_data.c +++ b/arch/arm/cpu/armv7/omap5/hw_data.c @@ -412,6 +412,8 @@ void enable_basic_clocks(void) (*prcm)-cm_l4per_gpio4_clkctrl, (*prcm)-cm_l4per_gpio5_clkctrl, (*prcm)-cm_l4per_gpio6_clkctrl, + (*prcm)-cm_clksel_usb_60mhz, + (*prcm)-cm_l3init_hsusbtll_clkctrl, guard this with CONFIG_USB_EHCI please or it ll throw an error for DRA7xx boards. why is DRA7xx using omap5/hw_data.c? doesn't it qualify for its own SoC directory? We tried to keep common things for OMAP5/DRA intact and added the difference. The above clocks list was same for both. In fact there is no armv7/dra directory at all. If there is no directory, it could be created I suppose. IMHO it would become ugly soon if it doesn't have its own hw_data. I am not much against it, it might look clean but would result in some code duplication. I feel we should do it if we add another DRA variant. Regards, Sricharan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] arm, arm335x: save_omap_boot_params question
On Wednesday 12 June 2013 06:19 PM, Tom Rini wrote: On Wed, Jun 12, 2013 at 02:39:13PM +0200, Heiko Schocher wrote: Hello Tom, Am 12.06.2013 14:28, schrieb Tom Rini: On Wed, Jun 12, 2013 at 10:56:01AM +0200, Heiko Schocher wrote: Hello tom, your commit 4596dcc1d4ea5763e0f92cf5becd9fc7d4c6e674 Author: Tom Rini tr...@ti.com Date: Fri May 31 12:31:59 2013 -0400 am33xx/omap: Move save_omap_boot_params to omap-common/boot-common.c introduced, that all am335x based boards must call save_omap_boot_params() from the board specific s_init function. I just stumbled over it, as I updated to current head and my upcoming am335x based siemens boards didn't boot anymore ... should we think about to move this s_init() to a common place, and extract board specific things? Maybe arch/arm/cpu/armv7/omap-common/boot-common.c is a place for it? I think the first non-am335x_evm board pulled the code we need in board/ a bit too far in the board-specific direction. Whacking the WDT (which could be done differently I imagine based on your other patches), calling save_omap_boot_params and UART stuff is common. Figuring out which DDR and how is not. I think we can learn from omap-common/hwinit-common.c::s_init but need to have our own in arch/arm/cpu/armv7/am33xx/board.c and declared __weak or wrapped with CONFIG_AM33XX since TI814x (and TI816x) are different. Or maybe some more thinking share still. Do you have time for this? Thanks! I try to find some ;-) Maybe something like this: add in arch/arm/cpu/armv7/am33xx/board.c a weak s_init(), which all am35xx boards use, and call in this s_init() a s_init_board() which all am335x boards must have defined? s/s_init_board/sdram_init/ and yes. If we whack the UART stuff out into uart_enable (ala ti814x) and add a board_enable_early_pinmux (for the muxes needed, and put this right after save_omap_...) we might not need to make s_init __weak. Just curious here, why the save_omap_boot_params is breaking things in first place for your SOC. Was it not used before ?? Also regarding DDR, is it emif and DDR3 in all those boards ? Regards, Sricharan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] arm, arm335x: save_omap_boot_params question
On Thursday 13 June 2013 10:49 AM, Heiko Schocher wrote: Hello Sricharan, Am 13.06.2013 07:08, schrieb Sricharan R: On Wednesday 12 June 2013 06:19 PM, Tom Rini wrote: On Wed, Jun 12, 2013 at 02:39:13PM +0200, Heiko Schocher wrote: Hello Tom, Am 12.06.2013 14:28, schrieb Tom Rini: On Wed, Jun 12, 2013 at 10:56:01AM +0200, Heiko Schocher wrote: Hello tom, your commit 4596dcc1d4ea5763e0f92cf5becd9fc7d4c6e674 Author: Tom Rini tr...@ti.com Date: Fri May 31 12:31:59 2013 -0400 am33xx/omap: Move save_omap_boot_params to omap-common/boot-common.c introduced, that all am335x based boards must call save_omap_boot_params() from the board specific s_init function. I just stumbled over it, as I updated to current head and my upcoming am335x based siemens boards didn't boot anymore ... should we think about to move this s_init() to a common place, and extract board specific things? Maybe arch/arm/cpu/armv7/omap-common/boot-common.c is a place for it? I think the first non-am335x_evm board pulled the code we need in board/ a bit too far in the board-specific direction. Whacking the WDT (which could be done differently I imagine based on your other patches), calling save_omap_boot_params and UART stuff is common. Figuring out which DDR and how is not. I think we can learn from omap-common/hwinit-common.c::s_init but need to have our own in arch/arm/cpu/armv7/am33xx/board.c and declared __weak or wrapped with CONFIG_AM33XX since TI814x (and TI816x) are different. Or maybe some more thinking share still. Do you have time for this? Thanks! I try to find some ;-) Maybe something like this: add in arch/arm/cpu/armv7/am33xx/board.c a weak s_init(), which all am35xx boards use, and call in this s_init() a s_init_board() which all am335x boards must have defined? s/s_init_board/sdram_init/ and yes. If we whack the UART stuff out into uart_enable (ala ti814x) and add a board_enable_early_pinmux (for the muxes needed, and put this right after save_omap_...) we might not need to make s_init __weak. Just curious here, why the save_omap_boot_params is breaking things in first place for your SOC. Was it not used before ?? Also regarding DDR, is it emif and DDR3 in all those boards ? I am currently porting 3 am335x boards to mainline and worked with a few weeks old tree, where the save_omap_boot_params() patch was not in mainline. I am more or less finished the porting and just did a rebase to current head ... and due to missing save_omap_boot_params() in my board file, spl not found u-boot img in nand ... In the meantime I posted a patch, which moves save_omap_boot_params() to a common place, see here: [U-Boot] arm, am33xx: move s_init to a common place http://patchwork.ozlabs.org/patch/250973/ bye, Heiko oh ok, understood.. Thanks.. Regards, Sricharan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 0/5] ARM: OMAP: Cleanup save_boot_params function
Hi Tom, On Friday 31 May 2013 07:52 PM, Tom Rini wrote: On Fri, May 31, 2013 at 10:18:46AM -0400, Tom Rini wrote: On Wed, Apr 24, 2013 at 04:11:20PM +0530, Sricharan R wrote: The save_boot_params function does not store the data in a always writable area. So the code is broken for a 'XIP' boot. This series corrects this by storing it in 'gd' and also adds a 'C' equivalent function for the same. The essential cleanups for the same are added in this. Tested this on omap5 uevm board with SD/EMMC boot. omap4/5 boards does not have a XIP flash. So yet to test XIP with this series. Also verfied a MAKEALL for armv7. OK, do you have a beaglebone or am335x_evm around? This switch up breaks them, and I'm not sure what's going on. Part of the issue is that the NON_SECURE_SRAM_START/END weren't quite right, but they weren't so wrong as to be a problem (END wasn't quite the end, and start was in the middle of our image, but we didn't reference it). I'm going to keep poking at this as well. Thanks! Answered my own question now, am33xx (andti81xx) doesn't opt-in for omap-common/hwinit-common.c Ok, Thanks for the pointer. So i will add this in the series. and boot test once on am33xx Regards, Sricharan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] am33xx/omap: Move save_omap_boot_params to omap-common/boot-common.c
On Friday 31 May 2013 11:48 PM, Tom Rini wrote:
We need to call the save_omap_boot_params function on am33xx/ti81xx and
other newer TI SoCs, so move the function to boot-common. Only OMAP4+
has the omap_hw_init_context function so add ifdefs to not call it on
am33xx/ti81xx. Call save_omap_boot_params from s_init on am33xx/ti81xx
boards.
Signed-off-by: Tom Rini tr...@ti.com
---
arch/arm/cpu/armv7/omap-common/boot-common.c | 39
arch/arm/cpu/armv7/omap-common/hwinit-common.c | 36 --
arch/arm/include/asm/arch-am33xx/sys_proto.h |1 +
arch/arm/include/asm/arch-omap4/sys_proto.h|1 +
arch/arm/include/asm/arch-omap5/sys_proto.h|1 +
board/isee/igep0033/board.c|9 ++
board/phytec/pcm051/board.c|9 ++
board/ti/am335x/board.c|9 ++
board/ti/ti814x/evm.c |9 ++
9 files changed, 78 insertions(+), 36 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap-common/boot-common.c
b/arch/arm/cpu/armv7/omap-common/boot-common.c
index bff7e9c..76ae1b6 100644
--- a/arch/arm/cpu/armv7/omap-common/boot-common.c
+++ b/arch/arm/cpu/armv7/omap-common/boot-common.c
@@ -25,6 +25,45 @@
DECLARE_GLOBAL_DATA_PTR;
+void save_omap_boot_params(void)
+{
+ u32 rom_params = *((u32 *)OMAP_SRAM_SCRATCH_BOOT_PARAMS);
+ u8 boot_device;
+ u32 dev_desc, dev_data;
+
+ if ((rom_params NON_SECURE_SRAM_START) ||
+ (rom_params NON_SECURE_SRAM_END))
+ return;
+
+ /*
+ * rom_params can be type casted to omap_boot_parameters and
+ * used. But it not correct to assume that romcode structure
+ * encoding would be same as u-boot. So use the defined offsets.
+ */
+ gd-arch.omap_boot_params.omap_bootdevice = boot_device =
+*((u8 *)(rom_params + BOOT_DEVICE_OFFSET));
+
+ gd-arch.omap_boot_params.ch_flags =
+ *((u8 *)(rom_params + CH_FLAGS_OFFSET));
+
+ if ((boot_device = MMC_BOOT_DEVICES_START)
+ (boot_device = MMC_BOOT_DEVICES_END)) {
+#if !defined(CONFIG_AM33XX) !defined(CONFIG_TI81XX)
+ if ((omap_hw_init_context() ==
+ OMAP_INIT_CONTEXT_UBOOT_AFTER_SPL)) {
+ gd-arch.omap_boot_params.omap_bootmode =
+ *((u8 *)(rom_params + BOOT_MODE_OFFSET));
+ } else
+#endif
This is fine, as long as omap_bootmode is not required in u-boot,
which i think is the case now.
+ {
+ dev_desc = *((u32 *)(rom_params + DEV_DESC_PTR_OFFSET));
+ dev_data = *((u32 *)(dev_desc + DEV_DATA_PTR_OFFSET));
+ gd-arch.omap_boot_params.omap_bootmode =
+ *((u32 *)(dev_data + BOOT_MODE_OFFSET));
+ }
+ }
+}
+
#ifdef CONFIG_SPL_BUILD
u32 spl_boot_device(void)
{
diff --git a/arch/arm/cpu/armv7/omap-common/hwinit-common.c
b/arch/arm/cpu/armv7/omap-common/hwinit-common.c
index e614641..0776d5c 100644
--- a/arch/arm/cpu/armv7/omap-common/hwinit-common.c
+++ b/arch/arm/cpu/armv7/omap-common/hwinit-common.c
@@ -111,42 +111,6 @@ void __weak srcomp_enable(void)
{
}
-static void save_omap_boot_params(void)
-{
- u32 rom_params = *((u32 *)OMAP_SRAM_SCRATCH_BOOT_PARAMS);
- u8 boot_device;
- u32 dev_desc, dev_data;
-
- if ((rom_params NON_SECURE_SRAM_START) ||
- (rom_params NON_SECURE_SRAM_END))
- return;
-
- /*
- * rom_params can be type casted to omap_boot_parameters and
- * used. But it not correct to assume that romcode structure
- * encoding would be same as u-boot. So use the defined offsets.
- */
- gd-arch.omap_boot_params.omap_bootdevice = boot_device =
-*((u8 *)(rom_params + BOOT_DEVICE_OFFSET));
-
- gd-arch.omap_boot_params.ch_flags =
- *((u8 *)(rom_params + CH_FLAGS_OFFSET));
-
- if ((boot_device = MMC_BOOT_DEVICES_START)
- (boot_device = MMC_BOOT_DEVICES_END)) {
- if ((omap_hw_init_context() ==
- OMAP_INIT_CONTEXT_UBOOT_AFTER_SPL)) {
- gd-arch.omap_boot_params.omap_bootmode =
- *((u8 *)(rom_params + BOOT_MODE_OFFSET));
- } else {
- dev_desc = *((u32 *)(rom_params + DEV_DESC_PTR_OFFSET));
- dev_data = *((u32 *)(dev_desc + DEV_DATA_PTR_OFFSET));
- gd-arch.omap_boot_params.omap_bootmode =
- *((u32 *)(dev_data + BOOT_MODE_OFFSET));
- }
- }
-}
-
#ifdef CONFIG_ARCH_CPU_INIT
/*
* SOC specific cpu init
diff --git a/arch/arm/include/asm/arch-am33xx/sys_proto.h
Re: [U-Boot] [PATCH V2 0/5] ARM: OMAP: Cleanup save_boot_params function
On Monday 03 June 2013 11:39 AM, Sricharan R wrote: Hi Tom, On Friday 31 May 2013 07:52 PM, Tom Rini wrote: On Fri, May 31, 2013 at 10:18:46AM -0400, Tom Rini wrote: On Wed, Apr 24, 2013 at 04:11:20PM +0530, Sricharan R wrote: The save_boot_params function does not store the data in a always writable area. So the code is broken for a 'XIP' boot. This series corrects this by storing it in 'gd' and also adds a 'C' equivalent function for the same. The essential cleanups for the same are added in this. Tested this on omap5 uevm board with SD/EMMC boot. omap4/5 boards does not have a XIP flash. So yet to test XIP with this series. Also verfied a MAKEALL for armv7. OK, do you have a beaglebone or am335x_evm around? This switch up breaks them, and I'm not sure what's going on. Part of the issue is that the NON_SECURE_SRAM_START/END weren't quite right, but they weren't so wrong as to be a problem (END wasn't quite the end, and start was in the middle of our image, but we didn't reference it). I'm going to keep poking at this as well. Thanks! Answered my own question now, am33xx (andti81xx) doesn't opt-in for omap-common/hwinit-common.c Ok, Thanks for the pointer. So i will add this in the series. and boot test once on am33xx Ok, you have already addressed this . Thanks a lot.. Regards, Sricharan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] ARM: OMAP5: clocks: Do not enable sgx clocks
On Wednesday 29 May 2013 06:10 PM, Tom Rini wrote: On Wed, May 29, 2013 at 03:39:54PM +0530, Lokesh Vutla wrote: From: Sricharan R r.sricha...@ti.com SGX clocks should be enabled only for OMAP5 ES1.0. So this can be removed. Signed-off-by: Sricharan R r.sricha...@ti.com --- arch/arm/cpu/armv7/omap5/hw_data.c |6 -- 1 file changed, 6 deletions(-) diff --git a/arch/arm/cpu/armv7/omap5/hw_data.c b/arch/arm/cpu/armv7/omap5/hw_data.c index 604fa42..842cf27 100644 --- a/arch/arm/cpu/armv7/omap5/hw_data.c +++ b/arch/arm/cpu/armv7/omap5/hw_data.c @@ -383,12 +383,6 @@ void enable_basic_clocks(void) clk_modules_explicit_en_essential, 1); -/* Select 384Mhz for GPU as its the POR for ES1.0 */ -setbits_le32((*prcm)-cm_sgx_sgx_clkctrl, -CLKSEL_GPU_HYD_GCLK_MASK); -setbits_le32((*prcm)-cm_sgx_sgx_clkctrl, -CLKSEL_GPU_CORE_GCLK_MASK); - /* Enable SCRM OPT clocks for PER and CORE dpll */ setbits_le32((*prcm)-cm_wkupaon_scrm_clkctrl, OPTFCLKEN_SCRM_PER_MASK); Wait, will everyone with ES1.0 be updating to ES2.0 and be OK with this? Lubomir's board is ES1.0, currently. Thanks! Even if so, these clocks should/need not be enabled in boot loader. It should not have been enabled in, but earlier we had the habit enabling unnessecary things.. Regards, Sricharan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 08/12] ARM: DRA7xx: Correct SRAM END address
On Wednesday 29 May 2013 06:36 PM, Tom Rini wrote: On Wed, May 29, 2013 at 04:32:43PM +0530, Lokesh Vutla wrote: From: Sricharan R r.sricha...@ti.com NON SECURE SRAM is 512KB in DRA7xx devices. So fixing it here. Signed-off-by: Sricharan R r.sricha...@ti.com --- arch/arm/include/asm/arch-omap5/omap.h |7 --- include/configs/dra7xx_evm.h |3 +++ include/configs/omap5_uevm.h |3 +++ No, we need to handle this in the include files, not the config files. Ok.. The only concern was headers were shared between OMAP5/DRA and this results in #ifdef CONFIG_XX checks. Just thinking how to handle this better. Regards, Sricharan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH RFC] OMAP5: uEVM: Enable USB EHCI functionality (preliminary, not tested)
Hi, On Thursday 16 May 2013 08:59 PM, Tom Rini wrote: On Thu, May 16, 2013 at 05:56:57PM +0300, Lubomir Popov wrote: [snip] The same U-Boot (yesterday's u-boot-ti/master), just configured for my SOM5_EVB board: U-Boot SPL 2013.04-11569-ge3db066-dirty (May 16 2013 - 16:14:17) OMAP5430 ES1.0 U-Boot SPL 2013.04-11569-ge3db066-dirty (May 16 2013 - 16:14:17) OMAP5430 ES1.0 OMAP SD/MMC: 0 reading u-boot.img reading u-boot.img U-Boot 2013.04-11569-ge3db066-dirty (May 16 2013 - 16:14:17) [snip] Also please notice that the SPL now seems to be executed twice (on both boards). This was not the case until recently, at least with the mainline. Anything to do with all those relocation discussions/patches? Can you bisect and see when something changed? It looks like it's printing the same string twice, not loading SPL loading SPL loading U-Boot, but I could be wrong.. I tried SD and EMMC boot on the latest mainline on my 5432 ES2.0 and did not see any issue. What boot are you trying ? U-Boot SPL 2013.04-00237-g9d32686 (May 17 2013 - 10:54:15) OMAP5432 ES2.0 OMAP SD/MMC: 0 reading u-boot.img reading u-boot.img U-Boot 2013.04-00237-g9d32686 (May 17 2013 - 10:54:15) CPU : OMAP5432 ES2.0 Board: OMAP5430 EVM I2C: ready DRAM: 2 GiB MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 Using default environment In:serial Out: serial Err: serial Hit any key to stop autoboot: 0 OMAP5430 EVM # Regards, Sricharan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] OMAP5: Add support for the SOM5_EVB board (OMAP5430-based)
Hi, On Wednesday 15 May 2013 01:25 PM, Lubomir Popov wrote: Hi Sricharan, On 15/05/13 08:11, Sricharan R wrote: Hi, On Tuesday 14 May 2013 10:11 PM, Tom Rini wrote: On Tue, May 14, 2013 at 07:09:33PM +0300, Lubomir Popov wrote: Hi Tom, On 14/05/13 17:52, Tom Rini wrote: On Tue, May 14, 2013 at 01:24:41PM +0300, Lubomir Popov wrote: Hi Tom, I'm currently busy with other work; on the other hand, careful rebasing shall require some time, especially the Palmas stuff. What would be the deadline for a V2 submission? Meanwhile could you please have a look at the (already old) http://patchwork.ozlabs.org/patch/232743/? A simple patch, shall be needed if we enable USB (for the uEVM along with our board). In general, what are your plans regarding USB (.../patch/232742/)? Thanks for the reminder, I'll grab 232743 soon. 232742 looks OK, but do you have a patch around for uEVM still? Not yet (didn't have the opportunity to test, although some uEVMs should be around at MMS). As you know, a patch shall be needed in the uEVM board file along with the common USB stuff. Yeah, I can test it as well if you write it up, and may find the time if you point me in the right direction. And again on I2C (.../patch/233823/): what is you final opinion? I'm confident that this patch is a major improvement for OMAP4/5 at least. I'm inclined to go with it, just need to mentally unswap the i2c notes in my brain and think it over one more time. Just applied 233823 to current u-boot-ti master. Works fine. OK, thanks. [snip] + * TODO: Replace this ugly hardcoding with proper defines + */ + writel(0x0100, 0x4ae0a310); Again, do please. This should be (*scrm)-auxclk0. The problem is that the omap5_scrm_regs struct (holding the auxclk0 member) has to be defined somewhere in the common OMAP5 headers. Sricharan? Or should I hack around? Add it to the most likely struct in the headers. The entire struct (I call it omap5_scrm_regs in theory, similar to the corresponding omap4_scrm_regs for OMAP4) is not defined anywhere. Of course I could define only the member that I need, but I guess it is a (responsible) TI job to define hardware descriptors. Or I'm wrong? Please advise. If I have time, I could do it myself - it's some 27 registers, almost identical to the OMAP4, and should go into arch/arm/include/asm/arch-omap5/clocks.h. Whomever uses / needs it should do it. I gave the TRM a quick read and I don't see any conflicts per-se just some reserved areas being named and vice versa. So rename it to omap_scrm_regs and move to asm/omap_common.h. Thanks! I would argue that this is not very appropriate. Those regs that are reserved on the OMAP5 are related to altclkscr and auxclk5 on the OMAP4; on the other hand the OMAP5 has some modem clock regs that are reserved on OMAP4. We shall probably have ugly #ifdefs again. And what about OMAP3 and below? We don't need to use ifdefs since there's no conflicts, things are either reserved in one case and used in the other. And we can make sure we don't try and use the omap5 bits on omap4 and vice versa. I don't see scrm in the first omap3 TRM I pulled up, so we don't need to worry there. Currently the scrm struct is defined for OMAP4 in the asm/arch-omap4/clocks.h file and I have already done the same for OMAP5 by analogy. I must admit however that this approach does not correspond to the latest way by which groups of OMAP hardware regs are defined, prcm in particular - a struct in omap_common.h, holding only the required regs, no padding and such garbage, and an init with the physical addresses in a .c file for the particular SoC (prcm-regs.c). But still the Panda board, for example, uses the old way for scrm. Therefore I did it the same for OMAP5, which was easier (I'm old and lazy ;) ). Yes, I'm OK starting off with moving things into omap_common.h as-is and then updating them a bit later ala pcrm-regs.c. I am sorry for the very late response on this. Now then, why not add this register in to omap5_es2_prcm ??. That is how the TRM sees it as well.. Of course, this is cleanup stuff for OMAP4 panda as you pointed out.. Yes, you are right in respect to fluent software integration and consistency with current implementation. My only concern is that from architectural point of view the SCRM, although related to the PRCM, is a separate module (described correspondingly as such in the TRM). If we go this way, the SCRM regs shall have to be referenced via the prcm pointer: (*prcm)-x, and this might be confusing. I'm OK to do it as above, that is, add the SCRM regs (for both OMAP4 and OMAP5) to the prcm_regs declaration in omap_common.h, and the required init to the appropriate omap5_esx_prcm in prcm-regs.c, but would suggest that for improved clarity the SCRM register names, as they now exist in .../arch-omap4/clocks.h, start with a scrm_ prefix. Alternatively, a new scrm_regs struct could
Re: [U-Boot] [PATCH] OMAP5: Add support for the SOM5_EVB board (OMAP5430-based)
On Wednesday 15 May 2013 04:16 PM, Lubomir Popov wrote: Hi Sricharan, On 15/05/13 12:04, Sricharan R wrote: Hi, On Wednesday 15 May 2013 01:25 PM, Lubomir Popov wrote: Hi Sricharan, On 15/05/13 08:11, Sricharan R wrote: Hi, On Tuesday 14 May 2013 10:11 PM, Tom Rini wrote: On Tue, May 14, 2013 at 07:09:33PM +0300, Lubomir Popov wrote: Hi Tom, On 14/05/13 17:52, Tom Rini wrote: On Tue, May 14, 2013 at 01:24:41PM +0300, Lubomir Popov wrote: Hi Tom, I'm currently busy with other work; on the other hand, careful rebasing shall require some time, especially the Palmas stuff. What would be the deadline for a V2 submission? Meanwhile could you please have a look at the (already old) http://patchwork.ozlabs.org/patch/232743/? A simple patch, shall be needed if we enable USB (for the uEVM along with our board). In general, what are your plans regarding USB (.../patch/232742/)? Thanks for the reminder, I'll grab 232743 soon. 232742 looks OK, but do you have a patch around for uEVM still? Not yet (didn't have the opportunity to test, although some uEVMs should be around at MMS). As you know, a patch shall be needed in the uEVM board file along with the common USB stuff. Yeah, I can test it as well if you write it up, and may find the time if you point me in the right direction. And again on I2C (.../patch/233823/): what is you final opinion? I'm confident that this patch is a major improvement for OMAP4/5 at least. I'm inclined to go with it, just need to mentally unswap the i2c notes in my brain and think it over one more time. Just applied 233823 to current u-boot-ti master. Works fine. OK, thanks. [snip] + * TODO: Replace this ugly hardcoding with proper defines + */ + writel(0x0100, 0x4ae0a310); Again, do please. This should be (*scrm)-auxclk0. The problem is that the omap5_scrm_regs struct (holding the auxclk0 member) has to be defined somewhere in the common OMAP5 headers. Sricharan? Or should I hack around? Add it to the most likely struct in the headers. The entire struct (I call it omap5_scrm_regs in theory, similar to the corresponding omap4_scrm_regs for OMAP4) is not defined anywhere. Of course I could define only the member that I need, but I guess it is a (responsible) TI job to define hardware descriptors. Or I'm wrong? Please advise. If I have time, I could do it myself - it's some 27 registers, almost identical to the OMAP4, and should go into arch/arm/include/asm/arch-omap5/clocks.h. Whomever uses / needs it should do it. I gave the TRM a quick read and I don't see any conflicts per-se just some reserved areas being named and vice versa. So rename it to omap_scrm_regs and move to asm/omap_common.h. Thanks! I would argue that this is not very appropriate. Those regs that are reserved on the OMAP5 are related to altclkscr and auxclk5 on the OMAP4; on the other hand the OMAP5 has some modem clock regs that are reserved on OMAP4. We shall probably have ugly #ifdefs again. And what about OMAP3 and below? We don't need to use ifdefs since there's no conflicts, things are either reserved in one case and used in the other. And we can make sure we don't try and use the omap5 bits on omap4 and vice versa. I don't see scrm in the first omap3 TRM I pulled up, so we don't need to worry there. Currently the scrm struct is defined for OMAP4 in the asm/arch-omap4/clocks.h file and I have already done the same for OMAP5 by analogy. I must admit however that this approach does not correspond to the latest way by which groups of OMAP hardware regs are defined, prcm in particular - a struct in omap_common.h, holding only the required regs, no padding and such garbage, and an init with the physical addresses in a .c file for the particular SoC (prcm-regs.c). But still the Panda board, for example, uses the old way for scrm. Therefore I did it the same for OMAP5, which was easier (I'm old and lazy ;) ). Yes, I'm OK starting off with moving things into omap_common.h as-is and then updating them a bit later ala pcrm-regs.c. I am sorry for the very late response on this. Now then, why not add this register in to omap5_es2_prcm ??. That is how the TRM sees it as well.. Of course, this is cleanup stuff for OMAP4 panda as you pointed out.. Yes, you are right in respect to fluent software integration and consistency with current implementation. My only concern is that from architectural point of view the SCRM, although related to the PRCM, is a separate module (described correspondingly as such in the TRM). If we go this way, the SCRM regs shall have to be referenced via the prcm pointer: (*prcm)-x, and this might be confusing. I'm OK to do it as above, that is, add the SCRM regs (for both OMAP4 and OMAP5) to the prcm_regs declaration in omap_common.h, and the required init to the appropriate omap5_esx_prcm in prcm-regs.c, but would suggest that for improved clarity the SCRM
Re: [U-Boot] [PATCH] OMAP5: Add support for the SOM5_EVB board (OMAP5430-based)
Hi, On Tuesday 14 May 2013 10:11 PM, Tom Rini wrote: On Tue, May 14, 2013 at 07:09:33PM +0300, Lubomir Popov wrote: Hi Tom, On 14/05/13 17:52, Tom Rini wrote: On Tue, May 14, 2013 at 01:24:41PM +0300, Lubomir Popov wrote: Hi Tom, I'm currently busy with other work; on the other hand, careful rebasing shall require some time, especially the Palmas stuff. What would be the deadline for a V2 submission? Meanwhile could you please have a look at the (already old) http://patchwork.ozlabs.org/patch/232743/? A simple patch, shall be needed if we enable USB (for the uEVM along with our board). In general, what are your plans regarding USB (.../patch/232742/)? Thanks for the reminder, I'll grab 232743 soon. 232742 looks OK, but do you have a patch around for uEVM still? Not yet (didn't have the opportunity to test, although some uEVMs should be around at MMS). As you know, a patch shall be needed in the uEVM board file along with the common USB stuff. Yeah, I can test it as well if you write it up, and may find the time if you point me in the right direction. And again on I2C (.../patch/233823/): what is you final opinion? I'm confident that this patch is a major improvement for OMAP4/5 at least. I'm inclined to go with it, just need to mentally unswap the i2c notes in my brain and think it over one more time. Just applied 233823 to current u-boot-ti master. Works fine. OK, thanks. [snip] + * TODO: Replace this ugly hardcoding with proper defines + */ + writel(0x0100, 0x4ae0a310); Again, do please. This should be (*scrm)-auxclk0. The problem is that the omap5_scrm_regs struct (holding the auxclk0 member) has to be defined somewhere in the common OMAP5 headers. Sricharan? Or should I hack around? Add it to the most likely struct in the headers. The entire struct (I call it omap5_scrm_regs in theory, similar to the corresponding omap4_scrm_regs for OMAP4) is not defined anywhere. Of course I could define only the member that I need, but I guess it is a (responsible) TI job to define hardware descriptors. Or I'm wrong? Please advise. If I have time, I could do it myself - it's some 27 registers, almost identical to the OMAP4, and should go into arch/arm/include/asm/arch-omap5/clocks.h. Whomever uses / needs it should do it. I gave the TRM a quick read and I don't see any conflicts per-se just some reserved areas being named and vice versa. So rename it to omap_scrm_regs and move to asm/omap_common.h. Thanks! I would argue that this is not very appropriate. Those regs that are reserved on the OMAP5 are related to altclkscr and auxclk5 on the OMAP4; on the other hand the OMAP5 has some modem clock regs that are reserved on OMAP4. We shall probably have ugly #ifdefs again. And what about OMAP3 and below? We don't need to use ifdefs since there's no conflicts, things are either reserved in one case and used in the other. And we can make sure we don't try and use the omap5 bits on omap4 and vice versa. I don't see scrm in the first omap3 TRM I pulled up, so we don't need to worry there. Currently the scrm struct is defined for OMAP4 in the asm/arch-omap4/clocks.h file and I have already done the same for OMAP5 by analogy. I must admit however that this approach does not correspond to the latest way by which groups of OMAP hardware regs are defined, prcm in particular - a struct in omap_common.h, holding only the required regs, no padding and such garbage, and an init with the physical addresses in a .c file for the particular SoC (prcm-regs.c). But still the Panda board, for example, uses the old way for scrm. Therefore I did it the same for OMAP5, which was easier (I'm old and lazy ;) ). Yes, I'm OK starting off with moving things into omap_common.h as-is and then updating them a bit later ala pcrm-regs.c. I am sorry for the very late response on this. Now then, why not add this register in to omap5_es2_prcm ??. That is how the TRM sees it as well.. Of course, this is cleanup stuff for OMAP4 panda as you pointed out.. Regards, Sricharan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 0/5] ARM: OMAP: Cleanup save_boot_params function
Hi Tom, On Wednesday 08 May 2013 11:26 PM, Tom Rini wrote: On Wed, May 08, 2013 at 02:50:14PM +0530, Sricharan R wrote: Tom, On Wednesday 24 April 2013 04:11 PM, Sricharan R wrote: The save_boot_params function does not store the data in a always writable area. So the code is broken for a 'XIP' boot. This series corrects this by storing it in 'gd' and also adds a 'C' equivalent function for the same. The essential cleanups for the same are added in this. Tested this on omap5 uevm board with SD/EMMC boot. omap4/5 boards does not have a XIP flash. So yet to test XIP with this series. Also verfied a MAKEALL for armv7. Sricharan R (5): ARM: OMAP: Make omap_boot_parameters common across socs ARM: OMAP4/5: Make OMAPx_SRAM_SCRATCH_ defines common ARM: OMAP: Correct save_boot_params and replace with 'C' function ARM: OMAP: Cleanup boot parameters usage ARM: OMAP: Add arch_cpu_init function arch/arm/cpu/armv7/lowlevel_init.S |8 +++- arch/arm/cpu/armv7/omap-common/boot-common.c | 20 ++-- arch/arm/cpu/armv7/omap-common/hwinit-common.c | 61 +--- arch/arm/cpu/armv7/omap-common/lowlevel_init.S | 50 +-- arch/arm/cpu/armv7/omap4/emif.c|4 +- arch/arm/cpu/armv7/omap4/hw_data.c |2 +- arch/arm/cpu/armv7/omap4/hwinit.c |3 +- arch/arm/cpu/armv7/omap5/emif.c|4 +- arch/arm/cpu/armv7/omap5/hw_data.c |2 +- arch/arm/cpu/armv7/omap5/hwinit.c |3 +- arch/arm/include/asm/arch-am33xx/omap.h| 25 -- arch/arm/include/asm/arch-omap4/omap.h | 36 -- arch/arm/include/asm/arch-omap4/sys_proto.h| 11 ++--- arch/arm/include/asm/arch-omap5/omap.h | 36 -- arch/arm/include/asm/arch-omap5/sys_proto.h| 12 ++--- arch/arm/include/asm/global_data.h |8 arch/arm/include/asm/omap_boot.h | 50 +++ arch/arm/include/asm/omap_common.h | 19 common/spl/spl.c | 12 +++-- include/configs/am335x_evm.h |4 ++ include/configs/omap4_common.h |4 ++ include/configs/omap5_common.h |3 ++ include/configs/pcm051.h |4 ++ include/configs/ti814x_evm.h |4 ++ include/spl.h |1 - 25 files changed, 187 insertions(+), 199 deletions(-) create mode 100644 arch/arm/include/asm/omap_boot.h Does this look ok, go to get in ? With the posted changes to 4 and 5 (for platforms that are new to u-boot-ti/master), applied, thanks for the reminder! Thanks for it !! Regards, Sricharan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Reading uninitialized SDRAM values on OMAP4460 (PandaBoard)
On Wednesday 08 May 2013 06:54 PM, An Schall wrote: Hi there, my task is to output the uninitialized SDRAM values over UART during device startup. Therefore, I first searched for the code that handles the SDRAM initialization since I have to put my code in front of it. After digging through the code and reading some mailing list entries, I guess it takes place either in: arch/arm/cpu/armv7/start.S: after line 159 (after CPU was set to SVC3232 mode) or arch/arm/cpu/armv7/omap-common/lowlevel_init.S (which is quiet confusing to me). I guess it takes place in start.S. If you could confirm this, it would be very helpful.ti Next, I need to configure UART so I can iterate over the SDRAM and put each single byte on UART. Do you have any information where I can find info on how to write ASM to configure UART? ARM helpcenter is way too huge to find info in reasonable time. Thanks in advance, André ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot If your task is print the the uninitialised EMIF registers, then just add prints before the function sdram_init() in s_init arch/arm/cpu/armv7/omap-common/hwinit-common.c Regards, Sricharan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 0/5] ARM: OMAP: Cleanup save_boot_params function
Tom, On Wednesday 24 April 2013 04:11 PM, Sricharan R wrote: The save_boot_params function does not store the data in a always writable area. So the code is broken for a 'XIP' boot. This series corrects this by storing it in 'gd' and also adds a 'C' equivalent function for the same. The essential cleanups for the same are added in this. Tested this on omap5 uevm board with SD/EMMC boot. omap4/5 boards does not have a XIP flash. So yet to test XIP with this series. Also verfied a MAKEALL for armv7. Sricharan R (5): ARM: OMAP: Make omap_boot_parameters common across socs ARM: OMAP4/5: Make OMAPx_SRAM_SCRATCH_ defines common ARM: OMAP: Correct save_boot_params and replace with 'C' function ARM: OMAP: Cleanup boot parameters usage ARM: OMAP: Add arch_cpu_init function arch/arm/cpu/armv7/lowlevel_init.S |8 +++- arch/arm/cpu/armv7/omap-common/boot-common.c | 20 ++-- arch/arm/cpu/armv7/omap-common/hwinit-common.c | 61 +--- arch/arm/cpu/armv7/omap-common/lowlevel_init.S | 50 +-- arch/arm/cpu/armv7/omap4/emif.c|4 +- arch/arm/cpu/armv7/omap4/hw_data.c |2 +- arch/arm/cpu/armv7/omap4/hwinit.c |3 +- arch/arm/cpu/armv7/omap5/emif.c|4 +- arch/arm/cpu/armv7/omap5/hw_data.c |2 +- arch/arm/cpu/armv7/omap5/hwinit.c |3 +- arch/arm/include/asm/arch-am33xx/omap.h| 25 -- arch/arm/include/asm/arch-omap4/omap.h | 36 -- arch/arm/include/asm/arch-omap4/sys_proto.h| 11 ++--- arch/arm/include/asm/arch-omap5/omap.h | 36 -- arch/arm/include/asm/arch-omap5/sys_proto.h| 12 ++--- arch/arm/include/asm/global_data.h |8 arch/arm/include/asm/omap_boot.h | 50 +++ arch/arm/include/asm/omap_common.h | 19 common/spl/spl.c | 12 +++-- include/configs/am335x_evm.h |4 ++ include/configs/omap4_common.h |4 ++ include/configs/omap5_common.h |3 ++ include/configs/pcm051.h |4 ++ include/configs/ti814x_evm.h |4 ++ include/spl.h |1 - 25 files changed, 187 insertions(+), 199 deletions(-) create mode 100644 arch/arm/include/asm/omap_boot.h Does this look ok, go to get in ? Regards, Sricharan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2 0/5] ARM: OMAP: Cleanup save_boot_params function
The save_boot_params function does not store the data in a always writable area. So the code is broken for a 'XIP' boot. This series corrects this by storing it in 'gd' and also adds a 'C' equivalent function for the same. The essential cleanups for the same are added in this. Tested this on omap5 uevm board with SD/EMMC boot. omap4/5 boards does not have a XIP flash. So yet to test XIP with this series. Also verfied a MAKEALL for armv7. Sricharan R (5): ARM: OMAP: Make omap_boot_parameters common across socs ARM: OMAP4/5: Make OMAPx_SRAM_SCRATCH_ defines common ARM: OMAP: Correct save_boot_params and replace with 'C' function ARM: OMAP: Cleanup boot parameters usage ARM: OMAP: Add arch_cpu_init function arch/arm/cpu/armv7/lowlevel_init.S |8 +++- arch/arm/cpu/armv7/omap-common/boot-common.c | 20 ++-- arch/arm/cpu/armv7/omap-common/hwinit-common.c | 61 +--- arch/arm/cpu/armv7/omap-common/lowlevel_init.S | 50 +-- arch/arm/cpu/armv7/omap4/emif.c|4 +- arch/arm/cpu/armv7/omap4/hw_data.c |2 +- arch/arm/cpu/armv7/omap4/hwinit.c |3 +- arch/arm/cpu/armv7/omap5/emif.c|4 +- arch/arm/cpu/armv7/omap5/hw_data.c |2 +- arch/arm/cpu/armv7/omap5/hwinit.c |3 +- arch/arm/include/asm/arch-am33xx/omap.h| 25 -- arch/arm/include/asm/arch-omap4/omap.h | 36 -- arch/arm/include/asm/arch-omap4/sys_proto.h| 11 ++--- arch/arm/include/asm/arch-omap5/omap.h | 36 -- arch/arm/include/asm/arch-omap5/sys_proto.h| 12 ++--- arch/arm/include/asm/global_data.h |8 arch/arm/include/asm/omap_boot.h | 50 +++ arch/arm/include/asm/omap_common.h | 19 common/spl/spl.c | 12 +++-- include/configs/am335x_evm.h |4 ++ include/configs/omap4_common.h |4 ++ include/configs/omap5_common.h |3 ++ include/configs/pcm051.h |4 ++ include/configs/ti814x_evm.h |4 ++ include/spl.h |1 - 25 files changed, 187 insertions(+), 199 deletions(-) create mode 100644 arch/arm/include/asm/omap_boot.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/5] ARM: OMAP4/5: Make OMAPx_SRAM_SCRATCH_ defines common
These defines are same across OMAP4/5. So move them to
omap_common.h. This is required for the patches that
follow.
Signed-off-by: Sricharan R r.sricha...@ti.com
---
[V2] Rebased on mainline.
arch/arm/cpu/armv7/omap4/emif.c|4 ++--
arch/arm/cpu/armv7/omap4/hw_data.c |2 +-
arch/arm/cpu/armv7/omap4/hwinit.c |3 ++-
arch/arm/cpu/armv7/omap5/emif.c|4 ++--
arch/arm/cpu/armv7/omap5/hw_data.c |2 +-
arch/arm/cpu/armv7/omap5/hwinit.c |3 ++-
arch/arm/include/asm/arch-omap4/omap.h | 12
arch/arm/include/asm/arch-omap5/omap.h | 13 -
arch/arm/include/asm/omap_common.h | 14 ++
9 files changed, 24 insertions(+), 33 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap4/emif.c b/arch/arm/cpu/armv7/omap4/emif.c
index 53f6063..0ddf35f 100644
--- a/arch/arm/cpu/armv7/omap4/emif.c
+++ b/arch/arm/cpu/armv7/omap4/emif.c
@@ -31,8 +31,8 @@
#include asm/utils.h
#ifndef CONFIG_SYS_EMIF_PRECALCULATED_TIMING_REGS
-u32 *const T_num = (u32 *)OMAP4_SRAM_SCRATCH_EMIF_T_NUM;
-u32 *const T_den = (u32 *)OMAP4_SRAM_SCRATCH_EMIF_T_DEN;
+u32 *const T_num = (u32 *)OMAP_SRAM_SCRATCH_EMIF_T_NUM;
+u32 *const T_den = (u32 *)OMAP_SRAM_SCRATCH_EMIF_T_DEN;
#endif
#ifdef CONFIG_SYS_DEFAULT_LPDDR2_TIMINGS
diff --git a/arch/arm/cpu/armv7/omap4/hw_data.c
b/arch/arm/cpu/armv7/omap4/hw_data.c
index 04977b4..06a2fc8 100644
--- a/arch/arm/cpu/armv7/omap4/hw_data.c
+++ b/arch/arm/cpu/armv7/omap4/hw_data.c
@@ -40,7 +40,7 @@ struct dplls const **dplls_data =
struct vcores_data const **omap_vcores =
(struct vcores_data const **) OMAP_SRAM_SCRATCH_VCORES_PTR;
struct omap_sys_ctrl_regs const **ctrl =
- (struct omap_sys_ctrl_regs const **)OMAP4_SRAM_SCRATCH_SYS_CTRL;
+ (struct omap_sys_ctrl_regs const **)OMAP_SRAM_SCRATCH_SYS_CTRL;
/*
* The M N values in the following tables are created using the
diff --git a/arch/arm/cpu/armv7/omap4/hwinit.c
b/arch/arm/cpu/armv7/omap4/hwinit.c
index 2db517b..81f5a48 100644
--- a/arch/arm/cpu/armv7/omap4/hwinit.c
+++ b/arch/arm/cpu/armv7/omap4/hwinit.c
@@ -34,10 +34,11 @@
#include asm/sizes.h
#include asm/emif.h
#include asm/arch/gpio.h
+#include asm/omap_common.h
DECLARE_GLOBAL_DATA_PTR;
-u32 *const omap_si_rev = (u32 *)OMAP4_SRAM_SCRATCH_OMAP4_REV;
+u32 *const omap_si_rev = (u32 *)OMAP_SRAM_SCRATCH_OMAP_REV;
static const struct gpio_bank gpio_bank_44xx[6] = {
{ (void *)OMAP44XX_GPIO1_BASE, METHOD_GPIO_24XX },
diff --git a/arch/arm/cpu/armv7/omap5/emif.c b/arch/arm/cpu/armv7/omap5/emif.c
index 3f37abd..b4c1319 100644
--- a/arch/arm/cpu/armv7/omap5/emif.c
+++ b/arch/arm/cpu/armv7/omap5/emif.c
@@ -32,8 +32,8 @@
#ifndef CONFIG_SYS_EMIF_PRECALCULATED_TIMING_REGS
#define print_timing_reg(reg) debug(#reg - 0x%08x\n, (reg))
-static u32 *const T_num = (u32 *)OMAP5_SRAM_SCRATCH_EMIF_T_NUM;
-static u32 *const T_den = (u32 *)OMAP5_SRAM_SCRATCH_EMIF_T_DEN;
+static u32 *const T_num = (u32 *)OMAP_SRAM_SCRATCH_EMIF_T_NUM;
+static u32 *const T_den = (u32 *)OMAP_SRAM_SCRATCH_EMIF_T_DEN;
#endif
#ifdef CONFIG_SYS_DEFAULT_LPDDR2_TIMINGS
diff --git a/arch/arm/cpu/armv7/omap5/hw_data.c
b/arch/arm/cpu/armv7/omap5/hw_data.c
index ced274e..e29803d 100644
--- a/arch/arm/cpu/armv7/omap5/hw_data.c
+++ b/arch/arm/cpu/armv7/omap5/hw_data.c
@@ -41,7 +41,7 @@ struct dplls const **dplls_data =
struct vcores_data const **omap_vcores =
(struct vcores_data const **) OMAP_SRAM_SCRATCH_VCORES_PTR;
struct omap_sys_ctrl_regs const **ctrl =
- (struct omap_sys_ctrl_regs const **)OMAP5_SRAM_SCRATCH_SYS_CTRL;
+ (struct omap_sys_ctrl_regs const **)OMAP_SRAM_SCRATCH_SYS_CTRL;
/* OPP HIGH FREQUENCY for ES2.0 */
static const struct dpll_params mpu_dpll_params_1_5ghz[NUM_SYS_CLKS] = {
diff --git a/arch/arm/cpu/armv7/omap5/hwinit.c
b/arch/arm/cpu/armv7/omap5/hwinit.c
index 2f4b247..e93f403 100644
--- a/arch/arm/cpu/armv7/omap5/hwinit.c
+++ b/arch/arm/cpu/armv7/omap5/hwinit.c
@@ -37,10 +37,11 @@
#include asm/utils.h
#include asm/arch/gpio.h
#include asm/emif.h
+#include asm/omap_common.h
DECLARE_GLOBAL_DATA_PTR;
-u32 *const omap_si_rev = (u32 *)OMAP5_SRAM_SCRATCH_OMAP5_REV;
+u32 *const omap_si_rev = (u32 *)OMAP_SRAM_SCRATCH_OMAP_REV;
static struct gpio_bank gpio_bank_54xx[6] = {
{ (void *)OMAP54XX_GPIO1_BASE, METHOD_GPIO_24XX },
diff --git a/arch/arm/include/asm/arch-omap4/omap.h
b/arch/arm/include/asm/arch-omap4/omap.h
index 9ad1e82..e9a6ffe 100644
--- a/arch/arm/include/asm/arch-omap4/omap.h
+++ b/arch/arm/include/asm/arch-omap4/omap.h
@@ -143,16 +143,4 @@ struct s32ktimer {
#define NON_SECURE_SRAM_END0x4030E000 /* Not inclusive */
/* base address for indirect vectors (internal boot mode) */
#define SRAM_ROM_VECT_BASE 0x4030D000
-/* Temporary SRAM stack used while low level init is done */
-#define SRAM_SCRATCH_SPACE_ADDRNON_SECURE_SRAM_START
-/* SRAM scratch space entries */
-#define
[U-Boot] [PATCH V2 1/5] ARM: OMAP: Make omap_boot_parameters common across socs
omap_boot_parameters is same and defined for each
soc. So move this to a common place to reuse it
across socs.
Signed-off-by: Sricharan R r.sricha...@ti.com
---
[V2] Rebased on mainline.
arch/arm/include/asm/arch-am33xx/omap.h | 25
arch/arm/include/asm/arch-omap4/omap.h | 24 ---
arch/arm/include/asm/arch-omap5/omap.h | 23 ---
arch/arm/include/asm/omap_boot.h| 49 +++
4 files changed, 49 insertions(+), 72 deletions(-)
create mode 100644 arch/arm/include/asm/omap_boot.h
diff --git a/arch/arm/include/asm/arch-am33xx/omap.h
b/arch/arm/include/asm/arch-am33xx/omap.h
index d28f9a8..7e3bb9c 100644
--- a/arch/arm/include/asm/arch-am33xx/omap.h
+++ b/arch/arm/include/asm/arch-am33xx/omap.h
@@ -35,29 +35,4 @@
#define NON_SECURE_SRAM_START 0x4030
#define NON_SECURE_SRAM_END0x4032
#endif
-
-/* ROM code defines */
-/* Boot device */
-#define BOOT_DEVICE_MASK 0xFF
-#define BOOT_DEVICE_OFFSET 0x8
-#define DEV_DESC_PTR_OFFSET0x4
-#define DEV_DATA_PTR_OFFSET0x18
-#define BOOT_MODE_OFFSET 0x8
-#define RESET_REASON_OFFSET0x9
-#define CH_FLAGS_OFFSET0xA
-
-#define CH_FLAGS_CHSETTINGS(0x1 0)
-#define CH_FLAGS_CHRAM (0x1 1)
-#define CH_FLAGS_CHFLASH (0x1 2)
-#define CH_FLAGS_CHMMCSD (0x1 3)
-
-#ifndef __ASSEMBLY__
-struct omap_boot_parameters {
- char *boot_message;
- unsigned int mem_boot_descriptor;
- unsigned char omap_bootdevice;
- unsigned char reset_reason;
- unsigned char ch_flags;
-};
-#endif
#endif
diff --git a/arch/arm/include/asm/arch-omap4/omap.h
b/arch/arm/include/asm/arch-omap4/omap.h
index ad984da..9ad1e82 100644
--- a/arch/arm/include/asm/arch-omap4/omap.h
+++ b/arch/arm/include/asm/arch-omap4/omap.h
@@ -155,28 +155,4 @@ struct s32ktimer {
#define OMAP4_SRAM_SCRATCH_SYS_CTRL(SRAM_SCRATCH_SPACE_ADDR + 0x20)
#define OMAP4_SRAM_SCRATCH_SPACE_END (SRAM_SCRATCH_SPACE_ADDR + 0x24)
-/* ROM code defines */
-/* Boot device */
-#define BOOT_DEVICE_MASK 0xFF
-#define BOOT_DEVICE_OFFSET 0x8
-#define DEV_DESC_PTR_OFFSET0x4
-#define DEV_DATA_PTR_OFFSET0x18
-#define BOOT_MODE_OFFSET 0x8
-#define RESET_REASON_OFFSET0x9
-#define CH_FLAGS_OFFSET0xA
-
-#define CH_FLAGS_CHSETTINGS(0x1 0)
-#define CH_FLAGS_CHRAM (0x1 1)
-#define CH_FLAGS_CHFLASH (0x1 2)
-#define CH_FLAGS_CHMMCSD (0x1 3)
-
-#ifndef __ASSEMBLY__
-struct omap_boot_parameters {
- char *boot_message;
- unsigned int mem_boot_descriptor;
- unsigned char omap_bootdevice;
- unsigned char reset_reason;
- unsigned char ch_flags;
-};
-#endif
#endif
diff --git a/arch/arm/include/asm/arch-omap5/omap.h
b/arch/arm/include/asm/arch-omap5/omap.h
index 887fcaa..3bf5afa 100644
--- a/arch/arm/include/asm/arch-omap5/omap.h
+++ b/arch/arm/include/asm/arch-omap5/omap.h
@@ -214,21 +214,6 @@ struct s32ktimer {
#define OMAP4460_ES1_0 0x44600100
#define OMAP4460_ES1_1 0x44600110
-/* ROM code defines */
-/* Boot device */
-#define BOOT_DEVICE_MASK 0xFF
-#define BOOT_DEVICE_OFFSET 0x8
-#define DEV_DESC_PTR_OFFSET0x4
-#define DEV_DATA_PTR_OFFSET0x18
-#define BOOT_MODE_OFFSET 0x8
-#define RESET_REASON_OFFSET 0x9
-#define CH_FLAGS_OFFSET 0xA
-
-#define CH_FLAGS_CHSETTINGS(0x1 0)
-#defineCH_FLAGS_CHRAM (0x1 1)
-#define CH_FLAGS_CHFLASH (0x1 2)
-#define CH_FLAGS_CHMMCSD (0x1 3)
-
/* CONTROL_SRCOMP_XXX_SIDE */
#define OVERRIDE_XS_SHIFT 30
#define OVERRIDE_XS_MASK (1 30)
@@ -249,14 +234,6 @@ struct srcomp_params {
s8 multiply_factor;
};
-struct omap_boot_parameters {
- char *boot_message;
- unsigned int mem_boot_descriptor;
- unsigned char omap_bootdevice;
- unsigned char reset_reason;
- unsigned char ch_flags;
-};
-
struct ctrl_ioregs {
u32 ctrl_ddrch;
u32 ctrl_lpddr2ch;
diff --git a/arch/arm/include/asm/omap_boot.h b/arch/arm/include/asm/omap_boot.h
new file mode 100644
index 000..87a9530
--- /dev/null
+++ b/arch/arm/include/asm/omap_boot.h
@@ -0,0 +1,49 @@
+/*
+ * (C) Copyright 2013
+ * Texas Instruments, www.ti.com
+ *
+ * Sricharan R r.sricha...@ti.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
[U-Boot] [PATCH V2 5/5] ARM: OMAP: Add arch_cpu_init function
The boot parameters passed from SPL to UBOOT
must be saved as a part of uboot's gd data
as early as possible, before we will inadvertently
overwrite it. So adding a arch_cpu_init for the required
Socs to save it.
Signed-off-by: Sricharan R r.sricha...@ti.com
---
[V2] Rebased on mainline.
arch/arm/cpu/armv7/omap-common/hwinit-common.c | 11 +++
include/configs/am335x_evm.h |3 +++
include/configs/omap4_common.h |4
include/configs/omap5_common.h |3 +++
include/configs/pcm051.h |3 +++
include/configs/ti814x_evm.h |3 +++
6 files changed, 27 insertions(+)
diff --git a/arch/arm/cpu/armv7/omap-common/hwinit-common.c
b/arch/arm/cpu/armv7/omap-common/hwinit-common.c
index c710784..1645120 100644
--- a/arch/arm/cpu/armv7/omap-common/hwinit-common.c
+++ b/arch/arm/cpu/armv7/omap-common/hwinit-common.c
@@ -147,6 +147,17 @@ static void save_omap_boot_params(void)
}
}
+#ifdef CONFIG_ARCH_CPU_INIT
+/*
+ * SOC specific cpu init
+ */
+int arch_cpu_init(void)
+{
+ save_omap_boot_params();
+ return 0;
+}
+#endif /* CONFIG_ARCH_CPU_INIT */
+
/*
* Routine: s_init
* Description: Does early system init of watchdog, muxing, andclocks
diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h
index ddfd52e..e5da51c 100644
--- a/include/configs/am335x_evm.h
+++ b/include/configs/am335x_evm.h
@@ -296,6 +296,9 @@
#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
diff --git a/include/configs/omap4_common.h b/include/configs/omap4_common.h
index 1fd3097..2871d87 100644
--- a/include/configs/omap4_common.h
+++ b/include/configs/omap4_common.h
@@ -87,6 +87,10 @@
#define CONFIG_BAUDRATE115200
#define CONFIG_SYS_BAUDRATE_TABLE {4800, 9600, 19200, 38400, 57600,\
115200}
+
+/* CPU */
+#define CONFIG_ARCH_CPU_INIT
+
/* I2C */
#define CONFIG_HARD_I2C1
#define CONFIG_SYS_I2C_SPEED 10
diff --git a/include/configs/omap5_common.h b/include/configs/omap5_common.h
index c21c387..32c113e 100644
--- a/include/configs/omap5_common.h
+++ b/include/configs/omap5_common.h
@@ -86,6 +86,9 @@
#define CONFIG_BAUDRATE115200
+/* CPU */
+#define CONFIG_ARCH_CPU_INIT
+
/* I2C */
#define CONFIG_HARD_I2C
#define CONFIG_SYS_I2C_SPEED 10
diff --git a/include/configs/pcm051.h b/include/configs/pcm051.h
index 5e5fab1..9614f70 100644
--- a/include/configs/pcm051.h
+++ b/include/configs/pcm051.h
@@ -195,6 +195,9 @@
#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
#define CONFIG_SYS_CONSOLE_INFO_QUIET
diff --git a/include/configs/ti814x_evm.h b/include/configs/ti814x_evm.h
index 68a7307..8ba1e1b 100644
--- a/include/configs/ti814x_evm.h
+++ b/include/configs/ti814x_evm.h
@@ -163,6 +163,9 @@
#define CONFIG_BAUDRATE115200
+/* CPU */
+#define CONFIG_ARCH_CPU_INIT
+
#define CONFIG_ENV_OVERWRITE
#define CONFIG_CONS_INDEX 1
#define CONFIG_SYS_CONSOLE_INFO_QUIET
--
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 3/5] ARM: OMAP: Correct save_boot_params and replace with 'C' function
Currently save_boot_params saves the boot parameters passed
from romcode. But this is not stored in a writable location
consistently. So the current code would not work for a
'XIP' boot. Change this by saving the boot parameters in
'gd' which is always writable. Also add a 'C' function
instead of an assembly code that is more readable.
Signed-off-by: Sricharan R r.sricha...@ti.com
---
[V2] Fixed comments and rebased on mainline
There is a checkpatch warning because of multiple
assignments in the below mainline.
gd-arch.omap_boot_params.omap_bootdevice = boot_device =
. But the code is better readable this way
arch/arm/cpu/armv7/omap-common/hwinit-common.c | 50 +---
arch/arm/include/asm/global_data.h |8
arch/arm/include/asm/omap_boot.h |1 +
arch/arm/include/asm/omap_common.h |4 +-
4 files changed, 56 insertions(+), 7 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap-common/hwinit-common.c
b/arch/arm/cpu/armv7/omap-common/hwinit-common.c
index 70d16a8..c710784 100644
--- a/arch/arm/cpu/armv7/omap-common/hwinit-common.c
+++ b/arch/arm/cpu/armv7/omap-common/hwinit-common.c
@@ -101,11 +101,6 @@ void omap_rev_string(void)
}
#ifdef CONFIG_SPL_BUILD
-static void init_boot_params(void)
-{
- boot_params_ptr = (u32 *) boot_params;
-}
-
void spl_display_print(void)
{
omap_rev_string();
@@ -116,6 +111,42 @@ void __weak srcomp_enable(void)
{
}
+static void save_omap_boot_params(void)
+{
+ u32 rom_params = *((u32 *)OMAP_SRAM_SCRATCH_BOOT_PARAMS);
+ u8 boot_device;
+ u32 dev_desc, dev_data;
+
+ if ((rom_params NON_SECURE_SRAM_START) ||
+ (rom_params NON_SECURE_SRAM_END))
+ return;
+
+ /*
+* rom_params can be type casted to omap_boot_parameters and
+* used. But it not correct to assume that romcode structure
+* encoding would be same as u-boot. So use the defined offsets.
+*/
+ gd-arch.omap_boot_params.omap_bootdevice = boot_device =
+ *((u8 *)(rom_params + BOOT_DEVICE_OFFSET));
+
+ gd-arch.omap_boot_params.ch_flags =
+ *((u8 *)(rom_params + CH_FLAGS_OFFSET));
+
+ if ((boot_device = MMC_BOOT_DEVICES_START)
+ (boot_device = MMC_BOOT_DEVICES_END)) {
+ if ((omap_hw_init_context() ==
+ OMAP_INIT_CONTEXT_UBOOT_AFTER_SPL)) {
+ gd-arch.omap_boot_params.omap_bootmode =
+ *((u8 *)(rom_params + BOOT_MODE_OFFSET));
+ } else {
+ dev_desc = *((u32 *)(rom_params + DEV_DESC_PTR_OFFSET));
+ dev_data = *((u32 *)(dev_desc + DEV_DATA_PTR_OFFSET));
+ gd-arch.omap_boot_params.omap_bootmode =
+ *((u32 *)(dev_data + BOOT_MODE_OFFSET));
+ }
+ }
+}
+
/*
* Routine: s_init
* Description: Does early system init of watchdog, muxing, andclocks
@@ -132,6 +163,14 @@ void __weak srcomp_enable(void)
*/
void s_init(void)
{
+ /*
+* Save the boot parameters passed from romcode.
+* We cannot delay the saving further than this,
+* to prevent overwrites.
+*/
+#ifdef CONFIG_SPL_BUILD
+ save_omap_boot_params();
+#endif
init_omap_revision();
hw_data_init();
@@ -156,7 +195,6 @@ void s_init(void)
/* For regular u-boot sdram_init() is called from dram_init() */
sdram_init();
- init_boot_params();
#endif
}
diff --git a/arch/arm/include/asm/global_data.h
b/arch/arm/include/asm/global_data.h
index 37ac0da..7611d0a 100644
--- a/arch/arm/include/asm/global_data.h
+++ b/arch/arm/include/asm/global_data.h
@@ -24,6 +24,10 @@
#ifndef__ASM_GBL_DATA_H
#define __ASM_GBL_DATA_H
+#ifdef CONFIG_OMAP
+#include asm/omap_boot.h
+#endif
+
/* Architecture-specific global data */
struct arch_global_data {
#if defined(CONFIG_FSL_ESDHC)
@@ -51,6 +55,10 @@ struct arch_global_data {
unsigned long tlb_addr;
unsigned long tlb_size;
#endif
+
+#ifdef CONFIG_OMAP
+ struct omap_boot_parameters omap_boot_params;
+#endif
};
#include asm-generic/global_data.h
diff --git a/arch/arm/include/asm/omap_boot.h b/arch/arm/include/asm/omap_boot.h
index 87a9530..a803965 100644
--- a/arch/arm/include/asm/omap_boot.h
+++ b/arch/arm/include/asm/omap_boot.h
@@ -45,5 +45,6 @@ struct omap_boot_parameters {
unsigned char omap_bootdevice;
unsigned char reset_reason;
unsigned char ch_flags;
+ unsigned long omap_bootmode;
};
#endif
diff --git a/arch/arm/include/asm/omap_common.h
b/arch/arm/include/asm/omap_common.h
index 6b70dbb..6b73d86 100644
--- a/arch/arm/include/asm/omap_common.h
+++ b/arch/arm/include/asm/omap_common.h
@@ -596,5 +596,7 @@ static inline u32 omap_revision(void)
#define
[U-Boot] [PATCH V2 4/5] ARM: OMAP: Cleanup boot parameters usage
The boot parameters are read from individual variables
assigned for each of them. This been corrected and now
they are stored as a part of the global data 'gd'
structure. So read them from 'gd' instead.
Signed-off-by: Sricharan R r.sricha...@ti.com
---
[V2] Addressed comments and rebased on mainline.
arch/arm/cpu/armv7/lowlevel_init.S |8 +++-
arch/arm/cpu/armv7/omap-common/boot-common.c | 31 +++
arch/arm/cpu/armv7/omap-common/lowlevel_init.S | 50 +---
arch/arm/include/asm/arch-omap4/sys_proto.h| 11 ++
arch/arm/include/asm/arch-omap5/sys_proto.h| 12 ++
arch/arm/include/asm/omap_common.h |3 ++
common/spl/spl.c | 10 ++---
include/configs/am335x_evm.h |1 +
include/configs/pcm051.h |1 +
include/configs/ti814x_evm.h |1 +
include/spl.h |1 -
11 files changed, 38 insertions(+), 91 deletions(-)
diff --git a/arch/arm/cpu/armv7/lowlevel_init.S
b/arch/arm/cpu/armv7/lowlevel_init.S
index 0d45528..0a15aa4 100644
--- a/arch/arm/cpu/armv7/lowlevel_init.S
+++ b/arch/arm/cpu/armv7/lowlevel_init.S
@@ -37,7 +37,13 @@ ENTRY(lowlevel_init)
*/
ldr sp, =CONFIG_SYS_INIT_SP_ADDR
bic sp, sp, #7 /* 8-byte alignment for ABI compliance */
-
+#ifdef CONFIG_SPL_BUILD
+ ldr r8, =gdata
+#else
+ sub sp, #GD_SIZE
+ bic sp, sp, #7
+ mov r8, sp
+#endif
/*
* Save the old lr(passed in ip) and the current lr to stack
*/
diff --git a/arch/arm/cpu/armv7/omap-common/boot-common.c
b/arch/arm/cpu/armv7/omap-common/boot-common.c
index 24cbe2d..bff7e9c 100644
--- a/arch/arm/cpu/armv7/omap-common/boot-common.c
+++ b/arch/arm/cpu/armv7/omap-common/boot-common.c
@@ -23,31 +23,17 @@
#include asm/arch/mmc_host_def.h
#include asm/arch/sys_proto.h
-/*
- * This is used to verify if the configuration header
- * was executed by rom code prior to control of transfer
- * to the bootloader. SPL is responsible for saving and
- * passing the boot_params pointer to the u-boot.
- */
-struct omap_boot_parameters boot_params __attribute__ ((section(.data)));
+DECLARE_GLOBAL_DATA_PTR;
#ifdef CONFIG_SPL_BUILD
-/*
- * We use static variables because global data is not ready yet.
- * Initialized data is available in SPL right from the beginning.
- * We would not typically need to save these parameters in regular
- * U-Boot. This is needed only in SPL at the moment.
- */
-u32 omap_bootmode = MMCSD_MODE_FAT;
-
u32 spl_boot_device(void)
{
- return (u32) (boot_params.omap_bootdevice);
+ return (u32) (gd-arch.omap_boot_params.omap_bootdevice);
}
u32 spl_boot_mode(void)
{
- return omap_bootmode;
+ return gd-arch.omap_boot_params.omap_bootmode;
}
void spl_board_init(void)
@@ -73,4 +59,15 @@ int board_mmc_init(bd_t *bis)
}
return 0;
}
+
+void __noreturn jump_to_image_no_args(struct spl_image_info *spl_image)
+{
+ typedef void __noreturn (*image_entry_noargs_t)(u32 *);
+ image_entry_noargs_t image_entry =
+ (image_entry_noargs_t) spl_image-entry_point;
+
+ debug(image entry point: 0x%X\n, spl_image-entry_point);
+ /* Pass the saved boot_params from rom code */
+ image_entry((u32 *)gd-arch.omap_boot_params);
+}
#endif
diff --git a/arch/arm/cpu/armv7/omap-common/lowlevel_init.S
b/arch/arm/cpu/armv7/omap-common/lowlevel_init.S
index 90b3c8a..c489536 100644
--- a/arch/arm/cpu/armv7/omap-common/lowlevel_init.S
+++ b/arch/arm/cpu/armv7/omap-common/lowlevel_init.S
@@ -28,59 +28,13 @@
#include config.h
#include asm/arch/omap.h
+#include asm/omap_common.h
#include asm/arch/spl.h
#include linux/linkage.h
ENTRY(save_boot_params)
- /*
-* See if the rom code passed pointer is valid:
-* It is not valid if it is not in non-secure SRAM
-* This may happen if you are booting with the help of
-* debugger
-*/
- ldr r2, =NON_SECURE_SRAM_START
- cmp r2, r0
- bgt 1f
- ldr r2, =NON_SECURE_SRAM_END
- cmp r2, r0
- blt 1f
-
- /*
-* store the boot params passed from rom code or saved
-* and passed by SPL
-*/
- cmp r0, #0
- beq 1f
- ldr r1, =boot_params
+ ldr r1, =OMAP_SRAM_SCRATCH_BOOT_PARAMS
str r0, [r1]
-#ifdef CONFIG_SPL_BUILD
- /* Store the boot device in spl_boot_device */
- ldrbr2, [r0, #BOOT_DEVICE_OFFSET] @ r1 - value of boot device
- and r2, #BOOT_DEVICE_MASK
- ldr r3, =boot_params
- strbr2, [r3, #BOOT_DEVICE_OFFSET] @ spl_boot_device - r1
-
- /*
-* boot mode is only valid for device that can be raw or FAT booted.
-* in other cases it may be fatal to look. While platforms differ
Re: [U-Boot] [PATCH] omap5_common: Add optargs variable for kernel command line args
On Thursday 11 April 2013 08:52 PM, Tom Rini wrote:
Add 'optargs' variable to be set to additional kernel arguments, similar
to omap3*/am3* usage.
Cc: Sricharan R r.sricha...@ti.com
Signed-off-by: Tom Rini tr...@ti.com
---
include/configs/omap5_common.h |2 ++
1 file changed, 2 insertions(+)
diff --git a/include/configs/omap5_common.h b/include/configs/omap5_common.h
index 2751627..5384a55 100644
--- a/include/configs/omap5_common.h
+++ b/include/configs/omap5_common.h
@@ -150,10 +150,12 @@
usbtty=cdc_acm\0 \
vram=16M\0 \
partitions= PARTS_DEFAULT \0 \
+ optargs=\0 \
mmcdev=0\0 \
mmcroot=/dev/mmcblk0p2 rw\0 \
mmcrootfstype=ext3 rootwait\0 \
mmcargs=setenv bootargs console=${console} \
+ ${optargs} \
Sorry, what is this used for ?
Regards,
Sricharan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 5/5] ARM: OMAP: Add arch_cpu_init function
The boot parameters passed from SPL to UBOOT
must be saved as a part of uboot's gd data
as early as possible, before we will inadvertently
overwrite it. So adding a arch_cpu_init for the required
Socs to save it.
Signed-off-by: Sricharan R r.sricha...@ti.com
---
arch/arm/cpu/armv7/omap-common/hwinit-common.c | 11 +++
include/configs/am335x_evm.h |3 +++
include/configs/omap4_common.h |4
include/configs/omap5_common.h |4
include/configs/pcm051.h |3 +++
include/configs/ti814x_evm.h |3 +++
6 files changed, 28 insertions(+)
diff --git a/arch/arm/cpu/armv7/omap-common/hwinit-common.c
b/arch/arm/cpu/armv7/omap-common/hwinit-common.c
index 602e76e..c82208c 100644
--- a/arch/arm/cpu/armv7/omap-common/hwinit-common.c
+++ b/arch/arm/cpu/armv7/omap-common/hwinit-common.c
@@ -147,6 +147,17 @@ static void save_omap_boot_params(void)
}
}
+#ifdef CONFIG_ARCH_CPU_INIT
+/*
+ * SOC specific cpu init
+ */
+int arch_cpu_init(void)
+{
+ save_omap_boot_params();
+ return 0;
+}
+#endif /* CONFIG_ARCH_CPU_INIT */
+
/*
* Routine: s_init
* Description: Does early system init of watchdog, muxing, andclocks
diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h
index 976f4d1..f207f66 100644
--- a/include/configs/am335x_evm.h
+++ b/include/configs/am335x_evm.h
@@ -256,6 +256,9 @@
#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
diff --git a/include/configs/omap4_common.h b/include/configs/omap4_common.h
index 6ae6a0f..7b7cc99 100644
--- a/include/configs/omap4_common.h
+++ b/include/configs/omap4_common.h
@@ -87,6 +87,10 @@
#define CONFIG_BAUDRATE115200
#define CONFIG_SYS_BAUDRATE_TABLE {4800, 9600, 19200, 38400, 57600,\
115200}
+
+/* CPU */
+#define CONFIG_ARCH_CPU_INIT
+
/* I2C */
#define CONFIG_HARD_I2C1
#define CONFIG_SYS_I2C_SPEED 10
diff --git a/include/configs/omap5_common.h b/include/configs/omap5_common.h
index af97564..28a74ae 100644
--- a/include/configs/omap5_common.h
+++ b/include/configs/omap5_common.h
@@ -87,6 +87,10 @@
#define CONFIG_BAUDRATE115200
#define CONFIG_SYS_BAUDRATE_TABLE {4800, 9600, 19200, 38400, 57600,\
115200}
+
+/* CPU */
+#define CONFIG_ARCH_CPU_INIT
+
/* I2C */
#define CONFIG_HARD_I2C
#define CONFIG_SYS_I2C_SPEED 10
diff --git a/include/configs/pcm051.h b/include/configs/pcm051.h
index 5e5fab1..9614f70 100644
--- a/include/configs/pcm051.h
+++ b/include/configs/pcm051.h
@@ -195,6 +195,9 @@
#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
#define CONFIG_SYS_CONSOLE_INFO_QUIET
diff --git a/include/configs/ti814x_evm.h b/include/configs/ti814x_evm.h
index 68a7307..8ba1e1b 100644
--- a/include/configs/ti814x_evm.h
+++ b/include/configs/ti814x_evm.h
@@ -163,6 +163,9 @@
#define CONFIG_BAUDRATE115200
+/* CPU */
+#define CONFIG_ARCH_CPU_INIT
+
#define CONFIG_ENV_OVERWRITE
#define CONFIG_CONS_INDEX 1
#define CONFIG_SYS_CONSOLE_INFO_QUIET
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/5] ARM: OMAP: Correct save_boot_params and replace with 'C' function
Currently save_boot_params saves the boot parameters passed
from romcode. But this is not stored in a writable location
consistently. So the current code would not work for a
'XIP' boot. Change this by saving the boot parameters in
'gd' which is always writable. Also add a 'C' function
instead of an assembly code that is more readable.
Signed-off-by: Sricharan R r.sricha...@ti.com
---
There is a checkpatch warning because of multiple
assignments. The code looks readable this way.
arch/arm/cpu/armv7/omap-common/hwinit-common.c | 50 +---
arch/arm/include/asm/global_data.h |8
arch/arm/include/asm/omap_boot.h |1 +
arch/arm/include/asm/omap_common.h |4 +-
4 files changed, 56 insertions(+), 7 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap-common/hwinit-common.c
b/arch/arm/cpu/armv7/omap-common/hwinit-common.c
index 70d16a8..602e76e 100644
--- a/arch/arm/cpu/armv7/omap-common/hwinit-common.c
+++ b/arch/arm/cpu/armv7/omap-common/hwinit-common.c
@@ -101,11 +101,6 @@ void omap_rev_string(void)
}
#ifdef CONFIG_SPL_BUILD
-static void init_boot_params(void)
-{
- boot_params_ptr = (u32 *) boot_params;
-}
-
void spl_display_print(void)
{
omap_rev_string();
@@ -116,6 +111,42 @@ void __weak srcomp_enable(void)
{
}
+static void save_omap_boot_params(void)
+{
+ u32 rom_params = *((u32 *)OMAP_SRAM_SCRATCH_BOOT_PARAMS);
+ u8 boot_device;
+ u32 dev_desc, dev_data;
+
+ if ((rom_params NON_SECURE_SRAM_START) ||
+ (rom_params NON_SECURE_SRAM_END))
+ return;
+
+ /*
+* rom_params can be type casted to omap_boot_parameters and
+* used. But it not correct to assume that romcode structure
+* encoding would be same as u-boot. So use the defined offsets.
+*/
+ gd-arch.omap_boot_params.omap_bootdevice = boot_device =
+ *((u8 *)(rom_params + BOOT_DEVICE_OFFSET));
+
+ gd-arch.omap_boot_params.ch_flags =
+ *((u8 *)(rom_params + CH_FLAGS_OFFSET));
+
+ if ((boot_device = BOOT_DEVICE_XIP)
+ (boot_device = BOOT_DEVICE_MMC2)) {
+ if (!(omap_hw_init_context() ==
+ OMAP_INIT_CONTEXT_UBOOT_AFTER_SPL)) {
+ dev_desc = *((u32 *)(rom_params + DEV_DESC_PTR_OFFSET));
+ dev_data = *((u32 *)(dev_desc + DEV_DATA_PTR_OFFSET));
+ gd-arch.omap_boot_params.omap_bootmode =
+ *((u32 *)(dev_data + BOOT_MODE_OFFSET));
+ } else {
+ gd-arch.omap_boot_params.omap_bootmode =
+ *((u8 *)(rom_params + BOOT_MODE_OFFSET));
+ }
+ }
+}
+
/*
* Routine: s_init
* Description: Does early system init of watchdog, muxing, andclocks
@@ -132,6 +163,14 @@ void __weak srcomp_enable(void)
*/
void s_init(void)
{
+ /*
+* Save the boot parameters passed from romcode.
+* We cannot delay the saving further than this,
+* to prevent overwrites.
+*/
+#ifdef CONFIG_SPL_BUILD
+ save_omap_boot_params();
+#endif
init_omap_revision();
hw_data_init();
@@ -156,7 +195,6 @@ void s_init(void)
/* For regular u-boot sdram_init() is called from dram_init() */
sdram_init();
- init_boot_params();
#endif
}
diff --git a/arch/arm/include/asm/global_data.h
b/arch/arm/include/asm/global_data.h
index 37ac0da..7611d0a 100644
--- a/arch/arm/include/asm/global_data.h
+++ b/arch/arm/include/asm/global_data.h
@@ -24,6 +24,10 @@
#ifndef__ASM_GBL_DATA_H
#define __ASM_GBL_DATA_H
+#ifdef CONFIG_OMAP
+#include asm/omap_boot.h
+#endif
+
/* Architecture-specific global data */
struct arch_global_data {
#if defined(CONFIG_FSL_ESDHC)
@@ -51,6 +55,10 @@ struct arch_global_data {
unsigned long tlb_addr;
unsigned long tlb_size;
#endif
+
+#ifdef CONFIG_OMAP
+ struct omap_boot_parameters omap_boot_params;
+#endif
};
#include asm-generic/global_data.h
diff --git a/arch/arm/include/asm/omap_boot.h b/arch/arm/include/asm/omap_boot.h
index 87a9530..a803965 100644
--- a/arch/arm/include/asm/omap_boot.h
+++ b/arch/arm/include/asm/omap_boot.h
@@ -45,5 +45,6 @@ struct omap_boot_parameters {
unsigned char omap_bootdevice;
unsigned char reset_reason;
unsigned char ch_flags;
+ unsigned long omap_bootmode;
};
#endif
diff --git a/arch/arm/include/asm/omap_common.h
b/arch/arm/include/asm/omap_common.h
index 6b70dbb..6b73d86 100644
--- a/arch/arm/include/asm/omap_common.h
+++ b/arch/arm/include/asm/omap_common.h
@@ -596,5 +596,7 @@ static inline u32 omap_revision(void)
#define OMAP_SRAM_SCRATCH_DPLLS_PTR (SRAM_SCRATCH_SPACE_ADDR + 0x18)
#define OMAP_SRAM_SCRATCH_VCORES_PTR(SRAM_SCRATCH_SPACE_ADDR + 0x1C)
#define OMAP_SRAM_SCRATCH_SYS_CTRL
[U-Boot] [PATCH 0/5] ARM: OMAP: Cleanup save_boot_params function
The save_boot_params function does not store the data in a always writable area. So the code is broken for a 'XIP' boot. This series corrects this by storing it in 'gd' and also adds a 'C' equivalent function for the same. The essential cleanups for the same are added in this. Tested this on omap5 uevm board with SD boot. omap4/5 boards does not have a XIP flash. So yet to test XIP with this series. Also verfied a MAKEALL for armv7. Sricharan R (5): ARM: OMAP: Make omap_boot_parameters common across socs ARM: OMAP4/5: Make OMAPx_SRAM_SCRATCH_ defines common ARM: OMAP: Correct save_boot_params and replace with 'C' function ARM: OMAP: Cleanup boot parameters usage ARM: OMAP: Add arch_cpu_init function arch/arm/cpu/armv7/lowlevel_init.S |8 +++- arch/arm/cpu/armv7/omap-common/boot-common.c | 20 ++-- arch/arm/cpu/armv7/omap-common/hwinit-common.c | 61 +--- arch/arm/cpu/armv7/omap-common/lowlevel_init.S | 46 +- arch/arm/cpu/armv7/omap4/emif.c|6 +-- arch/arm/cpu/armv7/omap4/hw_data.c |2 +- arch/arm/cpu/armv7/omap4/hwinit.c |3 +- arch/arm/cpu/armv7/omap5/emif.c|6 +-- arch/arm/cpu/armv7/omap5/hw_data.c |2 +- arch/arm/cpu/armv7/omap5/hwinit.c |3 +- arch/arm/include/asm/arch-am33xx/omap.h| 25 -- arch/arm/include/asm/arch-omap4/omap.h | 37 -- arch/arm/include/asm/arch-omap4/sys_proto.h| 11 ++--- arch/arm/include/asm/arch-omap5/omap.h | 37 -- arch/arm/include/asm/arch-omap5/sys_proto.h| 12 ++--- arch/arm/include/asm/global_data.h |8 arch/arm/include/asm/omap_boot.h | 50 +++ arch/arm/include/asm/omap_common.h | 19 common/spl/spl.c | 12 +++-- include/configs/am335x_evm.h |1 + include/configs/omap4_common.h |4 ++ include/configs/omap5_common.h |4 ++ include/configs/pcm051.h |1 + include/configs/ti814x_evm.h |1 + include/spl.h |1 - 25 files changed, 181 insertions(+), 199 deletions(-) create mode 100644 arch/arm/include/asm/omap_boot.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 1/5] ARM: OMAP: Make omap_boot_parameters common across socs
omap_boot_parameters is same and defined for each
soc. So move this to a common place to reuse it
across socs.
Signed-off-by: Sricharan R r.sricha...@ti.com
---
arch/arm/include/asm/arch-am33xx/omap.h | 25
arch/arm/include/asm/arch-omap4/omap.h | 24 ---
arch/arm/include/asm/arch-omap5/omap.h | 23 ---
arch/arm/include/asm/omap_boot.h| 49 +++
4 files changed, 49 insertions(+), 72 deletions(-)
create mode 100644 arch/arm/include/asm/omap_boot.h
diff --git a/arch/arm/include/asm/arch-am33xx/omap.h
b/arch/arm/include/asm/arch-am33xx/omap.h
index d28f9a8..7e3bb9c 100644
--- a/arch/arm/include/asm/arch-am33xx/omap.h
+++ b/arch/arm/include/asm/arch-am33xx/omap.h
@@ -35,29 +35,4 @@
#define NON_SECURE_SRAM_START 0x4030
#define NON_SECURE_SRAM_END0x4032
#endif
-
-/* ROM code defines */
-/* Boot device */
-#define BOOT_DEVICE_MASK 0xFF
-#define BOOT_DEVICE_OFFSET 0x8
-#define DEV_DESC_PTR_OFFSET0x4
-#define DEV_DATA_PTR_OFFSET0x18
-#define BOOT_MODE_OFFSET 0x8
-#define RESET_REASON_OFFSET0x9
-#define CH_FLAGS_OFFSET0xA
-
-#define CH_FLAGS_CHSETTINGS(0x1 0)
-#define CH_FLAGS_CHRAM (0x1 1)
-#define CH_FLAGS_CHFLASH (0x1 2)
-#define CH_FLAGS_CHMMCSD (0x1 3)
-
-#ifndef __ASSEMBLY__
-struct omap_boot_parameters {
- char *boot_message;
- unsigned int mem_boot_descriptor;
- unsigned char omap_bootdevice;
- unsigned char reset_reason;
- unsigned char ch_flags;
-};
-#endif
#endif
diff --git a/arch/arm/include/asm/arch-omap4/omap.h
b/arch/arm/include/asm/arch-omap4/omap.h
index 5f321fe..555d0f6 100644
--- a/arch/arm/include/asm/arch-omap4/omap.h
+++ b/arch/arm/include/asm/arch-omap4/omap.h
@@ -156,28 +156,4 @@ struct s32ktimer {
#define OMAP4_SRAM_SCRATCH_SYS_CTRL(SRAM_SCRATCH_SPACE_ADDR + 0x20)
#define OMAP4_SRAM_SCRATCH_SPACE_END (SRAM_SCRATCH_SPACE_ADDR + 0x24)
-/* ROM code defines */
-/* Boot device */
-#define BOOT_DEVICE_MASK 0xFF
-#define BOOT_DEVICE_OFFSET 0x8
-#define DEV_DESC_PTR_OFFSET0x4
-#define DEV_DATA_PTR_OFFSET0x18
-#define BOOT_MODE_OFFSET 0x8
-#define RESET_REASON_OFFSET0x9
-#define CH_FLAGS_OFFSET0xA
-
-#define CH_FLAGS_CHSETTINGS(0x1 0)
-#define CH_FLAGS_CHRAM (0x1 1)
-#define CH_FLAGS_CHFLASH (0x1 2)
-#define CH_FLAGS_CHMMCSD (0x1 3)
-
-#ifndef __ASSEMBLY__
-struct omap_boot_parameters {
- char *boot_message;
- unsigned int mem_boot_descriptor;
- unsigned char omap_bootdevice;
- unsigned char reset_reason;
- unsigned char ch_flags;
-};
-#endif
#endif
diff --git a/arch/arm/include/asm/arch-omap5/omap.h
b/arch/arm/include/asm/arch-omap5/omap.h
index b632635..a06a300 100644
--- a/arch/arm/include/asm/arch-omap5/omap.h
+++ b/arch/arm/include/asm/arch-omap5/omap.h
@@ -215,21 +215,6 @@ struct s32ktimer {
#define OMAP4460_ES1_0 0x44600100
#define OMAP4460_ES1_1 0x44600110
-/* ROM code defines */
-/* Boot device */
-#define BOOT_DEVICE_MASK 0xFF
-#define BOOT_DEVICE_OFFSET 0x8
-#define DEV_DESC_PTR_OFFSET0x4
-#define DEV_DATA_PTR_OFFSET0x18
-#define BOOT_MODE_OFFSET 0x8
-#define RESET_REASON_OFFSET 0x9
-#define CH_FLAGS_OFFSET 0xA
-
-#define CH_FLAGS_CHSETTINGS(0x1 0)
-#defineCH_FLAGS_CHRAM (0x1 1)
-#define CH_FLAGS_CHFLASH (0x1 2)
-#define CH_FLAGS_CHMMCSD (0x1 3)
-
/* CONTROL_SRCOMP_XXX_SIDE */
#define OVERRIDE_XS_SHIFT 30
#define OVERRIDE_XS_MASK (1 30)
@@ -250,14 +235,6 @@ struct srcomp_params {
s8 multiply_factor;
};
-struct omap_boot_parameters {
- char *boot_message;
- unsigned int mem_boot_descriptor;
- unsigned char omap_bootdevice;
- unsigned char reset_reason;
- unsigned char ch_flags;
-};
-
struct ctrl_ioregs {
u32 ctrl_ddrch;
u32 ctrl_lpddr2ch;
diff --git a/arch/arm/include/asm/omap_boot.h b/arch/arm/include/asm/omap_boot.h
new file mode 100644
index 000..87a9530
--- /dev/null
+++ b/arch/arm/include/asm/omap_boot.h
@@ -0,0 +1,49 @@
+/*
+ * (C) Copyright 2013
+ * Texas Instruments, www.ti.com
+ *
+ * Sricharan R r.sricha...@ti.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
[U-Boot] [PATCH 2/5] ARM: OMAP4/5: Make OMAPx_SRAM_SCRATCH_ defines common
These defines are same across OMAP4/5. So move them to
omap_common.h. This is required for the patches that
follow.
Signed-off-by: Sricharan R r.sricha...@ti.com
---
arch/arm/cpu/armv7/omap4/emif.c|6 +++---
arch/arm/cpu/armv7/omap4/hw_data.c |2 +-
arch/arm/cpu/armv7/omap4/hwinit.c |3 ++-
arch/arm/cpu/armv7/omap5/emif.c|6 +++---
arch/arm/cpu/armv7/omap5/hw_data.c |2 +-
arch/arm/cpu/armv7/omap5/hwinit.c |3 ++-
arch/arm/include/asm/arch-omap4/omap.h | 13 -
arch/arm/include/asm/arch-omap5/omap.h | 14 --
arch/arm/include/asm/omap_common.h | 14 ++
9 files changed, 26 insertions(+), 37 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap4/emif.c b/arch/arm/cpu/armv7/omap4/emif.c
index ca4823d..81da9c9 100644
--- a/arch/arm/cpu/armv7/omap4/emif.c
+++ b/arch/arm/cpu/armv7/omap4/emif.c
@@ -31,9 +31,9 @@
#include asm/utils.h
#ifndef CONFIG_SYS_EMIF_PRECALCULATED_TIMING_REGS
-u32 *const T_num = (u32 *)OMAP4_SRAM_SCRATCH_EMIF_T_NUM;
-u32 *const T_den = (u32 *)OMAP4_SRAM_SCRATCH_EMIF_T_DEN;
-u32 *const emif_sizes = (u32 *)OMAP4_SRAM_SCRATCH_EMIF_SIZE;
+u32 *const T_num = (u32 *)OMAP_SRAM_SCRATCH_EMIF_T_NUM;
+u32 *const T_den = (u32 *)OMAP_SRAM_SCRATCH_EMIF_T_DEN;
+u32 *const emif_sizes = (u32 *)OMAP_SRAM_SCRATCH_EMIF_SIZE;
#endif
#ifdef CONFIG_SYS_DEFAULT_LPDDR2_TIMINGS
diff --git a/arch/arm/cpu/armv7/omap4/hw_data.c
b/arch/arm/cpu/armv7/omap4/hw_data.c
index 7551b98..ab1d487 100644
--- a/arch/arm/cpu/armv7/omap4/hw_data.c
+++ b/arch/arm/cpu/armv7/omap4/hw_data.c
@@ -40,7 +40,7 @@ struct dplls const **dplls_data =
struct vcores_data const **omap_vcores =
(struct vcores_data const **) OMAP_SRAM_SCRATCH_VCORES_PTR;
struct omap_sys_ctrl_regs const **ctrl =
- (struct omap_sys_ctrl_regs const **)OMAP4_SRAM_SCRATCH_SYS_CTRL;
+ (struct omap_sys_ctrl_regs const **)OMAP_SRAM_SCRATCH_SYS_CTRL;
/*
* The M N values in the following tables are created using the
diff --git a/arch/arm/cpu/armv7/omap4/hwinit.c
b/arch/arm/cpu/armv7/omap4/hwinit.c
index 2db517b..81f5a48 100644
--- a/arch/arm/cpu/armv7/omap4/hwinit.c
+++ b/arch/arm/cpu/armv7/omap4/hwinit.c
@@ -34,10 +34,11 @@
#include asm/sizes.h
#include asm/emif.h
#include asm/arch/gpio.h
+#include asm/omap_common.h
DECLARE_GLOBAL_DATA_PTR;
-u32 *const omap_si_rev = (u32 *)OMAP4_SRAM_SCRATCH_OMAP4_REV;
+u32 *const omap_si_rev = (u32 *)OMAP_SRAM_SCRATCH_OMAP_REV;
static const struct gpio_bank gpio_bank_44xx[6] = {
{ (void *)OMAP44XX_GPIO1_BASE, METHOD_GPIO_24XX },
diff --git a/arch/arm/cpu/armv7/omap5/emif.c b/arch/arm/cpu/armv7/omap5/emif.c
index 8019ffe..e7176d4 100644
--- a/arch/arm/cpu/armv7/omap5/emif.c
+++ b/arch/arm/cpu/armv7/omap5/emif.c
@@ -32,9 +32,9 @@
#ifndef CONFIG_SYS_EMIF_PRECALCULATED_TIMING_REGS
#define print_timing_reg(reg) debug(#reg - 0x%08x\n, (reg))
-static u32 *const T_num = (u32 *)OMAP5_SRAM_SCRATCH_EMIF_T_NUM;
-static u32 *const T_den = (u32 *)OMAP5_SRAM_SCRATCH_EMIF_T_DEN;
-static u32 *const emif_sizes = (u32 *)OMAP5_SRAM_SCRATCH_EMIF_SIZE;
+static u32 *const T_num = (u32 *)OMAP_SRAM_SCRATCH_EMIF_T_NUM;
+static u32 *const T_den = (u32 *)OMAP_SRAM_SCRATCH_EMIF_T_DEN;
+static u32 *const emif_sizes = (u32 *)OMAP_SRAM_SCRATCH_EMIF_SIZE;
#endif
#ifdef CONFIG_SYS_DEFAULT_LPDDR2_TIMINGS
diff --git a/arch/arm/cpu/armv7/omap5/hw_data.c
b/arch/arm/cpu/armv7/omap5/hw_data.c
index ced274e..e29803d 100644
--- a/arch/arm/cpu/armv7/omap5/hw_data.c
+++ b/arch/arm/cpu/armv7/omap5/hw_data.c
@@ -41,7 +41,7 @@ struct dplls const **dplls_data =
struct vcores_data const **omap_vcores =
(struct vcores_data const **) OMAP_SRAM_SCRATCH_VCORES_PTR;
struct omap_sys_ctrl_regs const **ctrl =
- (struct omap_sys_ctrl_regs const **)OMAP5_SRAM_SCRATCH_SYS_CTRL;
+ (struct omap_sys_ctrl_regs const **)OMAP_SRAM_SCRATCH_SYS_CTRL;
/* OPP HIGH FREQUENCY for ES2.0 */
static const struct dpll_params mpu_dpll_params_1_5ghz[NUM_SYS_CLKS] = {
diff --git a/arch/arm/cpu/armv7/omap5/hwinit.c
b/arch/arm/cpu/armv7/omap5/hwinit.c
index 2f4b247..e93f403 100644
--- a/arch/arm/cpu/armv7/omap5/hwinit.c
+++ b/arch/arm/cpu/armv7/omap5/hwinit.c
@@ -37,10 +37,11 @@
#include asm/utils.h
#include asm/arch/gpio.h
#include asm/emif.h
+#include asm/omap_common.h
DECLARE_GLOBAL_DATA_PTR;
-u32 *const omap_si_rev = (u32 *)OMAP5_SRAM_SCRATCH_OMAP5_REV;
+u32 *const omap_si_rev = (u32 *)OMAP_SRAM_SCRATCH_OMAP_REV;
static struct gpio_bank gpio_bank_54xx[6] = {
{ (void *)OMAP54XX_GPIO1_BASE, METHOD_GPIO_24XX },
diff --git a/arch/arm/include/asm/arch-omap4/omap.h
b/arch/arm/include/asm/arch-omap4/omap.h
index 555d0f6..e9a6ffe 100644
--- a/arch/arm/include/asm/arch-omap4/omap.h
+++ b/arch/arm/include/asm/arch-omap4/omap.h
@@ -143,17 +143,4 @@ struct s32ktimer {
#define NON_SECURE_SRAM_END0x4030E000 /* Not inclusive */
/* base address for indirect vectors (internal boot mode
[U-Boot] [PATCH 4/5] ARM: OMAP: Cleanup boot parameters usage
The boot parameters are read from individual variables
assigned for each of them. This been corrected and now
they are stored as a part of the global data 'gd'
structure. So read them from 'gd' instead.
Signed-off-by: Sricharan R r.sricha...@ti.com
---
arch/arm/cpu/armv7/lowlevel_init.S |8 -
arch/arm/cpu/armv7/omap-common/boot-common.c | 20 ++-
arch/arm/cpu/armv7/omap-common/lowlevel_init.S | 46 ++--
arch/arm/include/asm/arch-omap4/sys_proto.h| 11 ++
arch/arm/include/asm/arch-omap5/sys_proto.h| 12 ++-
arch/arm/include/asm/omap_common.h |3 ++
common/spl/spl.c | 12 ---
include/configs/am335x_evm.h |1 +
include/configs/pcm051.h |1 +
include/configs/ti814x_evm.h |1 +
include/spl.h |1 -
11 files changed, 32 insertions(+), 84 deletions(-)
diff --git a/arch/arm/cpu/armv7/lowlevel_init.S
b/arch/arm/cpu/armv7/lowlevel_init.S
index 0d45528..0a15aa4 100644
--- a/arch/arm/cpu/armv7/lowlevel_init.S
+++ b/arch/arm/cpu/armv7/lowlevel_init.S
@@ -37,7 +37,13 @@ ENTRY(lowlevel_init)
*/
ldr sp, =CONFIG_SYS_INIT_SP_ADDR
bic sp, sp, #7 /* 8-byte alignment for ABI compliance */
-
+#ifdef CONFIG_SPL_BUILD
+ ldr r8, =gdata
+#else
+ sub sp, #GD_SIZE
+ bic sp, sp, #7
+ mov r8, sp
+#endif
/*
* Save the old lr(passed in ip) and the current lr to stack
*/
diff --git a/arch/arm/cpu/armv7/omap-common/boot-common.c
b/arch/arm/cpu/armv7/omap-common/boot-common.c
index 24cbe2d..6561957 100644
--- a/arch/arm/cpu/armv7/omap-common/boot-common.c
+++ b/arch/arm/cpu/armv7/omap-common/boot-common.c
@@ -23,31 +23,17 @@
#include asm/arch/mmc_host_def.h
#include asm/arch/sys_proto.h
-/*
- * This is used to verify if the configuration header
- * was executed by rom code prior to control of transfer
- * to the bootloader. SPL is responsible for saving and
- * passing the boot_params pointer to the u-boot.
- */
-struct omap_boot_parameters boot_params __attribute__ ((section(.data)));
+DECLARE_GLOBAL_DATA_PTR;
#ifdef CONFIG_SPL_BUILD
-/*
- * We use static variables because global data is not ready yet.
- * Initialized data is available in SPL right from the beginning.
- * We would not typically need to save these parameters in regular
- * U-Boot. This is needed only in SPL at the moment.
- */
-u32 omap_bootmode = MMCSD_MODE_FAT;
-
u32 spl_boot_device(void)
{
- return (u32) (boot_params.omap_bootdevice);
+ return (u32) (gd-arch.omap_boot_params.omap_bootdevice);
}
u32 spl_boot_mode(void)
{
- return omap_bootmode;
+ return gd-arch.omap_boot_params.omap_bootmode;
}
void spl_board_init(void)
diff --git a/arch/arm/cpu/armv7/omap-common/lowlevel_init.S
b/arch/arm/cpu/armv7/omap-common/lowlevel_init.S
index b933fe8..c489536 100644
--- a/arch/arm/cpu/armv7/omap-common/lowlevel_init.S
+++ b/arch/arm/cpu/armv7/omap-common/lowlevel_init.S
@@ -28,55 +28,13 @@
#include config.h
#include asm/arch/omap.h
+#include asm/omap_common.h
#include asm/arch/spl.h
#include linux/linkage.h
ENTRY(save_boot_params)
- /*
-* See if the rom code passed pointer is valid:
-* It is not valid if it is not in non-secure SRAM
-* This may happen if you are booting with the help of
-* debugger
-*/
- ldr r2, =NON_SECURE_SRAM_START
- cmp r2, r0
- bgt 1f
- ldr r2, =NON_SECURE_SRAM_END
- cmp r2, r0
- blt 1f
-
- /*
-* store the boot params passed from rom code or saved
-* and passed by SPL
-*/
- cmp r0, #0
- beq 1f
- ldr r1, =boot_params
+ ldr r1, =OMAP_SRAM_SCRATCH_BOOT_PARAMS
str r0, [r1]
-#ifdef CONFIG_SPL_BUILD
- /* Store the boot device in spl_boot_device */
- ldrbr2, [r0, #BOOT_DEVICE_OFFSET] @ r1 - value of boot device
- and r2, #BOOT_DEVICE_MASK
- ldr r3, =boot_params
- strbr2, [r3, #BOOT_DEVICE_OFFSET] @ spl_boot_device - r1
-
- /* boot mode is passed only for devices that can raw/fat mode */
- cmp r2, #BOOT_DEVICE_XIP
- blt 2f
- cmp r2, #BOOT_DEVICE_MMC2
- bgt 2f
- /* Store the boot mode (raw/FAT) in omap_bootmode */
- ldr r2, [r0, #DEV_DESC_PTR_OFFSET] @ get the device descriptor ptr
- ldr r2, [r2, #DEV_DATA_PTR_OFFSET] @ get the pDeviceData ptr
- ldr r2, [r2, #BOOT_MODE_OFFSET] @ get the boot mode
- ldr r3, =omap_bootmode
- str r2, [r3]
-#endif
-2:
- ldrbr2, [r0, #CH_FLAGS_OFFSET]
- ldr r3, =boot_params
- strbr2, [r3, #CH_FLAGS_OFFSET]
-1:
bx lr
ENDPROC(save_boot_params)
diff --git a/arch/arm/include/asm
Re: [U-Boot] [PATCH 3/5] ARM: OMAP: Correct save_boot_params and replace with 'C' function
On Monday 15 April 2013 08:58 PM, Tom Rini wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/15/2013 11:08 AM, Sricharan R wrote:
Currently save_boot_params saves the boot parameters passed from
romcode. But this is not stored in a writable location
consistently. So the current code would not work for a 'XIP' boot.
Change this by saving the boot parameters in 'gd' which is always
writable. Also add a 'C' function instead of an assembly code that
is more readable.
Signed-off-by: Sricharan R r.sricha...@ti.com --- There is a
checkpatch warning because of multiple assignments. The code looks
readable this way.
What/where?
In the below line pf the patch.
gd-arch.omap_boot_params.omap_bootdevice = boot_device =
[snip]
+if ((boot_device = BOOT_DEVICE_XIP) + (boot_device =
BOOT_DEVICE_MMC2)) {
This will need to be rebased to use MMC_BOOT_DEVICES_START/END and I
know you didn't test from eMMC on omap5_uevm then.
Yes, i was aware of this. Infact i saw before this series that
emmc was broken and your patch was fixing that. When i started this
series, your patch was not merged then. I can rebase on V2.
Regards,
Sricharan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/5] ARM: OMAP: Cleanup boot parameters usage
On Monday 15 April 2013 09:05 PM, Tom Rini wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/15/2013 11:08 AM, Sricharan R wrote:
The boot parameters are read from individual variables assigned
for each of them. This been corrected and now they are stored as a
part of the global data 'gd' structure. So read them from 'gd'
instead.
Signed-off-by: Sricharan R r.sricha...@ti.com ---
arch/arm/cpu/armv7/lowlevel_init.S |8 -
arch/arm/cpu/armv7/omap-common/boot-common.c | 20 ++-
arch/arm/cpu/armv7/omap-common/lowlevel_init.S | 46
++--
arch/arm/include/asm/arch-omap4/sys_proto.h| 11 ++
arch/arm/include/asm/arch-omap5/sys_proto.h| 12 ++-
arch/arm/include/asm/omap_common.h |3 ++
common/spl/spl.c | 12 ---
include/configs/am335x_evm.h |1 +
include/configs/pcm051.h |1 +
include/configs/ti814x_evm.h |1 +
include/spl.h |1 - 11 files
changed, 32 insertions(+), 84 deletions(-)
I can live with adding CONFIG_OMAP to the am335/ti81* parts.
Thanks. I was suspicious about this.
BTW, does am335/ti81 devices get the bootparams from romcode
in the same as OMAP ?
Also are there any am335 boards with XIP where i can test this ?
[snip]
diff --git a/common/spl/spl.c b/common/spl/spl.c index
6715e0d..4a7ce42 100644 --- a/common/spl/spl.c +++
b/common/spl/spl.c @@ -125,17 +125,21 @@ void
spl_parse_image_header(const struct image_header *header)
__weak void __noreturn jump_to_image_no_args(struct spl_image_info
*spl_image) { +#ifdef CONFIG_OMAP typedef void __noreturn
(*image_entry_noargs_t)(u32 *); +#else + typedef void __noreturn
(*image_entry_noargs_t)(void); +#endif image_entry_noargs_t
image_entry = (image_entry_noargs_t) spl_image-entry_point;
debug(image entry point: 0x%X\n, spl_image-entry_point); /*
Pass the saved boot_params from rom code */ -#if
defined(CONFIG_VIRTIO) || defined(CONFIG_ZEBU) - image_entry =
(image_entry_noargs_t)0x8010; +#ifdef CONFIG_OMAP +
image_entry((u32 *)gd-arch.omap_boot_params); +#else +
image_entry(); #endif - u32 boot_params_ptr_addr =
(u32)boot_params_ptr; - image_entry((u32 *)boot_params_ptr_addr);
}
We must correct jump_to_image_no_args to really be, in the default
case here just image_entry() and have omap-common override the weak
function with one that passes along our params, and comment what's
going on.
ok, that looks cleaner. This change in V2.
Regards,
Sricharan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/5] ARM: OMAP: Cleanup boot parameters usage
On Monday 15 April 2013 09:13 PM, Tom Rini wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/15/2013 11:39 AM, Sricharan R wrote: On Monday 15 April 2013 09:05 PM, Tom Rini wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/15/2013 11:08 AM, Sricharan R wrote: The boot parameters are read from individual variables assigned for each of them. This been corrected and now they are stored as a part of the global data 'gd' structure. So read them from 'gd' instead. Signed-off-by: Sricharan R r.sricha...@ti.com --- arch/arm/cpu/armv7/lowlevel_init.S |8 - arch/arm/cpu/armv7/omap-common/boot-common.c | 20 ++- arch/arm/cpu/armv7/omap-common/lowlevel_init.S | 46 ++-- arch/arm/include/asm/arch-omap4/sys_proto.h| 11 ++ arch/arm/include/asm/arch-omap5/sys_proto.h| 12 ++- arch/arm/include/asm/omap_common.h |3 ++ common/spl/spl.c | 12 --- include/configs/am335x_evm.h |1 + include/configs/pcm051.h |1 + include/configs/ti814x_evm.h |1 + include/spl.h |1 - 11 files changed, 32 insertions(+), 84 deletions(-) I can live with adding CONFIG_OMAP to the am335/ti81* parts. Thanks. I was suspicious about this. BTW, does am335/ti81 devices get the bootparams from romcode in the same as OMAP ? Yes, that's some common code we all share now. Also are there any am335 boards with XIP where i can test this ? am335x can have NOR, and there is a NOR cape for beaglebone, but we don't have everything for that in mainline just yet. Once that gets closer I will check it out. Ok, thanks for that. Regards, Sricharan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/5] ARM: OMAP: Correct save_boot_params and replace with 'C' function
On Monday 15 April 2013 09:52 PM, Michael Cashwell wrote:
Hi Sricharan,
I very much like how you've structured this. A vast improvement!
I haven't yet tried to apply the whole series but have one quick comment. In
the new function:
static void save_omap_boot_params(void)
{
...
if (!(omap_hw_init_context() ==
OMAP_INIT_CONTEXT_UBOOT_AFTER_SPL)) {
...
} else {
...
}
wouldn't it be clearer to drop the boolean negation ! and exchange the
if/else bodies?
hmm, will do and add a comment as well.
Regards,
Sricharan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] OMAP5: USB: hsusbtll_clkctrl has to be in hw_auto for USB to work
Hi Lubomir,
On Monday 08 April 2013 03:05 PM, Lubomir Popov wrote:
Hello Sricharan,
On 08/04/13 09:05, Sricharan R wrote:
On Thursday 04 April 2013 09:21 PM, Lubomir Popov wrote:
V2 fixes line wrap issue of the patch itself.
This fix is needed (but not sufficient) for USB EHCI operation.
Signed-off-by: Lubomir Popov lpo...@mm-sol.com
---
arch/arm/cpu/armv7/omap5/hw_data.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/cpu/armv7/omap5/hw_data.c
b/arch/arm/cpu/armv7/omap5/hw_data.c
index ced274e..e5e41fd 100644
--- a/arch/arm/cpu/armv7/omap5/hw_data.c
+++ b/arch/arm/cpu/armv7/omap5/hw_data.c
@@ -403,6 +403,7 @@ void enable_basic_uboot_clocks(void)
};
u32 const clk_modules_hw_auto_essential[] = {
+ (*prcm)-cm_l3init_hsusbtll_clkctrl,
0
};
@@ -411,7 +412,6 @@ void enable_basic_uboot_clocks(void)
(*prcm)-cm_l4per_i2c2_clkctrl,
(*prcm)-cm_l4per_i2c3_clkctrl,
(*prcm)-cm_l4per_i2c4_clkctrl,
- (*prcm)-cm_l3init_hsusbtll_clkctrl,
(*prcm)-cm_l3init_hsusbhost_clkctrl,
(*prcm)-cm_l3init_fsusb_clkctrl,
0
No, how is this helping you. Are you using EHCI at SPL ?
Those usb clocks are anyways getting enabled at u-boot.
Regards,
Sricharan
Hmm, i get it. The actual problem was usb_tll clocks does not support
'explicit en essential'. It supports only 'hw_auto' control.
That's why moving it to the hw_auto array makes it to work.
Acked-by: R Sricharan r.sricha...@ti.com
Regards,
Sricharan
Why SPL? This is in the enable_basic_uboot_clocks() function. The problem
seems to be
_when_ are they enabled.
This fix (moving cm_l3init_hsusbtll_clkctrl from the
clk_modules_explicit_en_essential[]
array to clk_modules_hw_auto_essential[]) is something confirmed empirically
(apart from
the fact that it is so for the OMAP4, which gave me the hint why USB was not
working).
The following dump is for the SOM5 EVB
(http://patchwork.ozlabs.org/patch/232739/) with all
needed patches applied (this one, as well as
http://patchwork.ozlabs.org/patch/232742/).
Functional clocks are enabled/disabled in the board file. The boot script
just sets a MAC
address for the USB Ethernet controller to env.
U-Boot SPL 2013.04-rc1-00400-g7f594d9 (Apr 02 2013 - 14:55:24)
OMAP5430 ES1.0
OMAP SD/MMC: 0
reading u-boot.img
reading u-boot.img
U-Boot 2013.04-rc1-00400-g7f594d9 (Apr 02 2013 - 14:55:24)
CPU : OMAP5430 ES1.0
Board: MM Solutions SOM5 EVB
I2C: ready
DRAM: 2 GiB
MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1
Using default environment
In:serial
Out: serial
Err: serial
Net: No ethernet found.
Hit any key to stop autoboot: 0
mmc0 is current device
reading boot.scr
109 bytes read in 3 ms (35.2 KiB/s)
Running bootscript from mmc0 ...
## Executing script at 8200
SOM5_EVB #
SOM5_EVB # usb start
(Re)start USB...
USB0: USB EHCI 1.00
scanning bus 0 for devices... 6 USB Device(s) found
scanning usb for storage devices... 3 Storage Device(s) found
scanning usb for ethernet devices... 1 Ethernet Device(s) found
SOM5_EVB # usb tree
USB device tree:
1 Hub (480 Mb/s, 0mA)
| u-boot EHCI Host Controller
|
+-2 Mass Storage (480 Mb/s, 200mA)
|FSC MEMORYBIRD USB2 C157040817120315AA
|
+-3 Hub (480 Mb/s, 2mA)
| |
| +-4 Mass Storage (480 Mb/s, 96mA)
| |Generic Ultra Fast Media Reader 00264001
| |
| +-5 Mass Storage (480 Mb/s, 100mA)
| Generic Mass Storage C88BB2CE
|
+-6 Vendor specific (480 Mb/s, 500mA)
SOM5_EVB #
Now, for the experiment, I just moved cm_l3init_hsusbtll_clkctrl back to
clk_modules_explicit_en_essential[] and built again. As you can see, the
result is a Data Abort exception:
U-Boot SPL 2013.04-rc2-00020-g6b29a25-dirty (Apr 08 2013 - 11:14:14)
OMAP5430 ES1.0
OMAP SD/MMC: 0
reading u-boot.img
reading u-boot.img
U-Boot 2013.04-rc2-00020-g6b29a25-dirty (Apr 08 2013 - 11:14:14)
CPU : OMAP5430 ES1.0
Board: MM Solutions SOM5 EVB
I2C: ready
DRAM: 2 GiB
MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1
Using default environment
In:serial
Out: serial
Err: serial
Net: No ethernet found.
Hit any key to stop autoboot: 0
mmc0 is current device
reading boot.scr
109 bytes read in 3 ms (35.2 KiB/s)
Running bootscript from mmc0 ...
## Executing script at 8200
SOM5_EVB #
SOM5_EVB # usb start
(Re)start USB...
USB0: data abort
MAYBE you should read doc/README.arm-unaligned-accesses
pc : [fef8f32c] lr : [fef738b4]
sp : feef2d50 ip : 0034 fp : feef2dc4
r10: r9 : fefbc0c4 r8 : feef2f40
r7 : 0680 r6 : fefbc0c0 r5 : 27da r4 : 4a062000
r3 : r2 : 27da r1 : 27da r0 : 27da
Flags: nZcv IRQs off FIQs off Mode SVC_32
Resetting CPU
Re: [U-Boot] [PATCH v2] OMAP5: I2C: Enable i2c5 clocks
Hi Lubomir, On Monday 08 April 2013 03:05 PM, Lubomir Popov wrote: Hi Sricharan, On 08/04/13 09:09, Sricharan R wrote: On Thursday 04 April 2013 09:22 PM, Lubomir Popov wrote: V2 fixes line wrap issue of the patch itself. I2C5 is used on all known OMAP5 hardware platforms, therefore enable. Signed-off-by: Lubomir Popov lpo...@mm-sol.com --- arch/arm/cpu/armv7/omap5/hw_data.c |1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/cpu/armv7/omap5/hw_data.c b/arch/arm/cpu/armv7/omap5/hw_data.c index e5e41fd..5698876 100644 --- a/arch/arm/cpu/armv7/omap5/hw_data.c +++ b/arch/arm/cpu/armv7/omap5/hw_data.c @@ -412,6 +412,7 @@ void enable_basic_uboot_clocks(void) (*prcm)-cm_l4per_i2c2_clkctrl, (*prcm)-cm_l4per_i2c3_clkctrl, (*prcm)-cm_l4per_i2c4_clkctrl, + (*prcm)-cm_l4per_i2c5_clkctrl, This is fine. Can you also mention what device is connected on them ? and how you are using it ? Also can you add these in a series. Regards, Sricharan On our board we have an I/O expander on I2C5 - the same chip that is used on the TI sEVM (the handset) and uEVM (the PandaBoard5) platforms (on both of which it is also connected to I2C5). Therefore it seems reasonable to have I2C5 enabled in the mainline. This requires that the base address is defined, and that I2C_BUS_MAX is set to 5 (please see related patches). I shall do make a new series on I2C5 support. One more thing I would like to clarify to myself: in your patch series of Apr. 1 you rename the omap5_evm to omap5_uevm. On the other hand, uEVM was the TI-internal name for the PandaBoard5, and the evm was known as sEVM. Doesn't this cause confusion? After all, these are two quite different hardware platforms. Thanks for the explanation. It would good to have the reasoning in the original commit log. For the next one,Tom already answered this. So uEVM is the and also the only official. Regards, Sricharan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3 1/3] OMAP5: I2C: Enable i2c5 clocks
Hi Lubomir, On Monday 08 April 2013 04:03 PM, Lubomir Popov wrote: Signed-off-by: Lubomir Popov lpo...@mm-sol.com --- V3 consolidates this patch into a series. arch/arm/cpu/armv7/omap5/hw_data.c |1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/cpu/armv7/omap5/hw_data.c b/arch/arm/cpu/armv7/omap5/hw_data.c index e5e41fd..5698876 100644 --- a/arch/arm/cpu/armv7/omap5/hw_data.c +++ b/arch/arm/cpu/armv7/omap5/hw_data.c @@ -412,6 +412,7 @@ void enable_basic_uboot_clocks(void) (*prcm)-cm_l4per_i2c2_clkctrl, (*prcm)-cm_l4per_i2c3_clkctrl, (*prcm)-cm_l4per_i2c4_clkctrl, + (*prcm)-cm_l4per_i2c5_clkctrl, (*prcm)-cm_l3init_hsusbhost_clkctrl, (*prcm)-cm_l3init_fsusb_clkctrl, 0 Please note that whatever is above the '' gets committed. So now all the 3 patches will not have any commit message. Regards, Sricharan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3 1/3] OMAP5: I2C: Enable i2c5 clocks
On Tuesday 09 April 2013 12:09 PM, Lubomir Popov wrote: Hi Sricharan, On 09/04/13 09:34, Sricharan R wrote: Hi Lubomir, On Monday 08 April 2013 04:03 PM, Lubomir Popov wrote: Signed-off-by: Lubomir Popov lpo...@mm-sol.com --- V3 consolidates this patch into a series. arch/arm/cpu/armv7/omap5/hw_data.c |1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/cpu/armv7/omap5/hw_data.c b/arch/arm/cpu/armv7/omap5/hw_data.c index e5e41fd..5698876 100644 --- a/arch/arm/cpu/armv7/omap5/hw_data.c +++ b/arch/arm/cpu/armv7/omap5/hw_data.c @@ -412,6 +412,7 @@ void enable_basic_uboot_clocks(void) (*prcm)-cm_l4per_i2c2_clkctrl, (*prcm)-cm_l4per_i2c3_clkctrl, (*prcm)-cm_l4per_i2c4_clkctrl, + (*prcm)-cm_l4per_i2c5_clkctrl, (*prcm)-cm_l3init_hsusbhost_clkctrl, (*prcm)-cm_l3init_fsusb_clkctrl, 0 Please note that whatever is above the '' gets committed. So now all the 3 patches will not have any commit message. Ooops... So much work, so little time... Should I do a V4? ya, because a patch without a commit log would look really blank :) Regards, Sricharan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] OMAP5: USB: hsusbtll_clkctrl has to be in hw_auto for USB to work
On Thursday 04 April 2013 09:21 PM, Lubomir Popov wrote:
V2 fixes line wrap issue of the patch itself.
This fix is needed (but not sufficient) for USB EHCI operation.
Signed-off-by: Lubomir Popov lpo...@mm-sol.com
---
arch/arm/cpu/armv7/omap5/hw_data.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/cpu/armv7/omap5/hw_data.c
b/arch/arm/cpu/armv7/omap5/hw_data.c
index ced274e..e5e41fd 100644
--- a/arch/arm/cpu/armv7/omap5/hw_data.c
+++ b/arch/arm/cpu/armv7/omap5/hw_data.c
@@ -403,6 +403,7 @@ void enable_basic_uboot_clocks(void)
};
u32 const clk_modules_hw_auto_essential[] = {
+ (*prcm)-cm_l3init_hsusbtll_clkctrl,
0
};
@@ -411,7 +412,6 @@ void enable_basic_uboot_clocks(void)
(*prcm)-cm_l4per_i2c2_clkctrl,
(*prcm)-cm_l4per_i2c3_clkctrl,
(*prcm)-cm_l4per_i2c4_clkctrl,
- (*prcm)-cm_l3init_hsusbtll_clkctrl,
(*prcm)-cm_l3init_hsusbhost_clkctrl,
(*prcm)-cm_l3init_fsusb_clkctrl,
0
No, how is this helping you. Are you using EHCI at SPL ?
Those usb clocks are anyways getting enabled at u-boot.
Regards,
Sricharan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] OMAP: Fix copy-paste bug that did not enable UART4 clock
On Thursday 04 April 2013 09:21 PM, Lubomir Popov wrote:
V2 fixes line wrap issue of the patch itself.
UART3 was enabled twice instead of UART4.
One more cosmetic change in a comment on EMIF clock.
Signed-off-by: Lubomir Popov lpo...@mm-sol.com
---
arch/arm/cpu/armv7/omap-common/clocks-common.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap-common/clocks-common.c
b/arch/arm/cpu/armv7/omap-common/clocks-common.c
index 9ed1899..2b955c7 100644
--- a/arch/arm/cpu/armv7/omap-common/clocks-common.c
+++ b/arch/arm/cpu/armv7/omap-common/clocks-common.c
@@ -612,7 +612,7 @@ void freq_update_core(void)
/*
* Putting EMIF in HW_AUTO is seen to be causing issues with
- * EMIF clocks and the master DLL. Put EMIF in SW_WKUP
+ * EMIF clocks and the master DLL. Keep EMIF in SW_WKUP
* in OMAP5430 ES1.0 silicon
*/
if (omap_rev != OMAP5430_ES1_0) {
@@ -659,7 +659,7 @@ void setup_clocks_for_console(void)
MODULE_CLKCTRL_MODULEMODE_SW_EXPLICIT_EN
MODULE_CLKCTRL_MODULEMODE_SHIFT);
- clrsetbits_le32((*prcm)-cm_l4per_uart3_clkctrl,
+ clrsetbits_le32((*prcm)-cm_l4per_uart4_clkctrl,
hmm, Thanks for catch.
Reviewed-by: R Sricharan r.sricha...@ti.com
Regards,
Sricharan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] OMAP5: I2C: Enable i2c5 clocks
On Thursday 04 April 2013 09:22 PM, Lubomir Popov wrote: V2 fixes line wrap issue of the patch itself. I2C5 is used on all known OMAP5 hardware platforms, therefore enable. Signed-off-by: Lubomir Popov lpo...@mm-sol.com --- arch/arm/cpu/armv7/omap5/hw_data.c |1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/cpu/armv7/omap5/hw_data.c b/arch/arm/cpu/armv7/omap5/hw_data.c index e5e41fd..5698876 100644 --- a/arch/arm/cpu/armv7/omap5/hw_data.c +++ b/arch/arm/cpu/armv7/omap5/hw_data.c @@ -412,6 +412,7 @@ void enable_basic_uboot_clocks(void) (*prcm)-cm_l4per_i2c2_clkctrl, (*prcm)-cm_l4per_i2c3_clkctrl, (*prcm)-cm_l4per_i2c4_clkctrl, + (*prcm)-cm_l4per_i2c5_clkctrl, This is fine. Can you also mention what device is connected on them ? and how you are using it ? Also can you add these in a series. Regards, Sricharan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] OMAP (4) boot_params
Hi Mike Cashwell, On Thursday 04 April 2013 07:48 PM, Michael Cashwell wrote: On Apr 4, 2013, at 1:52 AM, Wolfgang Denk w...@denx.de wrote: Dear Tom, On Apr 3, 2013, at 11:34 AM, Albert ARIBAUD albert.u.b...@aribaud.net wrote: ... except, as I said above, at this point your code should not write at all, be it in BSS or data, until the C environment is set up. So... But we have to save this ROM-passed information before we overwrite it ourselves (by accident or purpose). Thete are two official places for data storage before the full C runtime environment is available: the stack, and the global data structure. I thought there were more levels than just pre and post CRT. Specifically, the global_data struct's comment says it is intended to be used until we have set up the memory controller so that we can use RAM. To me that suggests once we have RAM any further data storage should go there instead of bloating global_data. I thought this distinction was embodied in the bss/data section difference with the former being zeroed during CRT init and the latter not. And I'm clearly not the only one who thought this. The change I proposed in common/spl/spl.c that Albert doesn't like: -u32 *boot_params_ptr = NULL; +u32 *boot_params_ptr __attribute__ ((section(.data))); is already immediately followed by exactly the same pattern: static bd_t bdata __attribute__ ((section(.data))); The only reason I can think of to put bdata explicitly in .data instead of the default .bss is so it can avoid the CRT zeroing of .bss. If that's wrong then why have both sections? How are they different? ... after that we can talk about moving things that can't be in the BSS out of the data section and into another section. Adding another section makes things more complicated, but not really better. My proposal does not add another section. The needed section already exists and seemingly for precisely the purpose under discussion. If you can provide writable storage, then you could also use it in a more regular way, say for a writable data segment, or bigger stack, or malloc space, or ... so it is generally useful instead of only this special case here. This is exactly my concern. I see no justification for a special case. If never writing to any linker-defined section (.data or .bss) before CRT init really is the design rule then there are quite a few other violations that need to be fixed. Rolling an ad hoc solution for each can't be the right approach. Sorry for the late feedback. The **only** reason for passing the boot_params from SPL to U-BOOT was when somebody uses a CONFIGURATION HEADER + SPL + U-BOOT, which was never a case. But the broken code that you pointed was trying to help such a scenario. I guess nobody would have used this combination. save_boot_params ideally should not write in to either .data or .bss. Because this would break a XIP kind of a boot. The only place where it can write is the GD or some reserved SRAM area that is always 'writable'. We did not have a XIP in OMAP4/5 and thus this went unnoticed. I will post a patch today to address this. Regards, Sricharan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] OMAP3/4/5/AM33xx: Correct logic for checking FAT or RAW MMC
Hi Tom, On Friday 05 April 2013 09:51 PM, Tom Rini wrote: In the case of booting from certain peripherals, such as UART, we must not see what the device descriptor says for RAW or FAT mode because in addition to being nonsensical, it leads to a hang. This is why we have a test currently for the boot mode being within range. The problem however is that on some platforms we get MMC2_2 as the boot mode and not the defined value for MMC2, and in others we get the value for MMC2_2. This is required to fix eMMC booting on omap5_uevm. Tested on am335x_evm (UART, NAND, SD), omap3_beagle (NAND, SD on classic, SD only on xM rev C5) and omap5_uevm (SD, eMMC). Signed-off-by: Tom Rini tr...@ti.com --- arch/arm/cpu/armv7/omap-common/lowlevel_init.S | 10 +++--- arch/arm/include/asm/arch-am33xx/spl.h |3 +++ arch/arm/include/asm/arch-omap3/spl.h |3 +++ arch/arm/include/asm/arch-omap4/spl.h |2 ++ arch/arm/include/asm/arch-omap5/spl.h |2 ++ 5 files changed, 17 insertions(+), 3 deletions(-) diff --git a/arch/arm/cpu/armv7/omap-common/lowlevel_init.S b/arch/arm/cpu/armv7/omap-common/lowlevel_init.S index b933fe8..90b3c8a 100644 --- a/arch/arm/cpu/armv7/omap-common/lowlevel_init.S +++ b/arch/arm/cpu/armv7/omap-common/lowlevel_init.S @@ -60,10 +60,14 @@ ENTRY(save_boot_params) ldr r3, =boot_params strbr2, [r3, #BOOT_DEVICE_OFFSET] @ spl_boot_device - r1 - /* boot mode is passed only for devices that can raw/fat mode */ - cmp r2, #BOOT_DEVICE_XIP + /* + * boot mode is only valid for device that can be raw or FAT booted. + * in other cases it may be fatal to look. While platforms differ + * in the values used for each MMC slot, they are contiguous. + */ + cmp r2, #MMC_BOOT_DEVICES_START blt 2f - cmp r2, #BOOT_DEVICE_MMC2 + cmp r2, #MMC_BOOT_DEVICES_END bgt 2f /* Store the boot mode (raw/FAT) in omap_bootmode */ ldr r2, [r0, #DEV_DESC_PTR_OFFSET] @ get the device descriptor ptr diff --git a/arch/arm/include/asm/arch-am33xx/spl.h b/arch/arm/include/asm/arch-am33xx/spl.h index f60b086..14a2c7c 100644 --- a/arch/arm/include/asm/arch-am33xx/spl.h +++ b/arch/arm/include/asm/arch-am33xx/spl.h @@ -37,4 +37,7 @@ #define BOOT_DEVICE_USBETH 68 #define BOOT_DEVICE_CPGMAC 70 #define BOOT_DEVICE_MMC2_2 0xFF + +#define MMC_BOOT_DEVICES_START BOOT_DEVICE_MMC1 +#define MMC_BOOT_DEVICES_END BOOT_DEVICE_MMC2 #endif diff --git a/arch/arm/include/asm/arch-omap3/spl.h b/arch/arm/include/asm/arch-omap3/spl.h index dec4dac..84e6d7b 100644 --- a/arch/arm/include/asm/arch-omap3/spl.h +++ b/arch/arm/include/asm/arch-omap3/spl.h @@ -31,4 +31,7 @@ #define BOOT_DEVICE_MMC1 6 #define BOOT_DEVICE_XIPWAIT 7 #define BOOT_DEVICE_MMC2_2 0xFF + +#define MMC_BOOT_DEVICES_START BOOT_DEVICE_MMC2 +#define MMC_BOOT_DEVICES_END BOOT_DEVICE_MMC1 #endif diff --git a/arch/arm/include/asm/arch-omap4/spl.h b/arch/arm/include/asm/arch-omap4/spl.h index 4e094f9..f61627f 100644 --- a/arch/arm/include/asm/arch-omap4/spl.h +++ b/arch/arm/include/asm/arch-omap4/spl.h @@ -32,4 +32,6 @@ #define BOOT_DEVICE_MMC2 6 #define BOOT_DEVICE_MMC2_2 0xFF +#define MMC_BOOT_DEVICES_START BOOT_DEVICE_MMC1 +#define MMC_BOOT_DEVICES_END BOOT_DEVICE_MMC2 #endif diff --git a/arch/arm/include/asm/arch-omap5/spl.h b/arch/arm/include/asm/arch-omap5/spl.h index 323cd63..d4d353c 100644 --- a/arch/arm/include/asm/arch-omap5/spl.h +++ b/arch/arm/include/asm/arch-omap5/spl.h @@ -32,4 +32,6 @@ #define BOOT_DEVICE_MMC26 #define BOOT_DEVICE_MMC2_2 7 +#define MMC_BOOT_DEVICES_START BOOT_DEVICE_MMC1 +#define MMC_BOOT_DEVICES_END BOOT_DEVICE_MMC2_2 #endif Acked-by: R Sricharan r.sricha...@ti.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 5/5] ARM: OMAP4/5: Make bootz as the default boot command
Hi Albert, On Friday 05 April 2013 12:36 PM, Albert ARIBAUD wrote: Hi Sricharan, On Fri, 5 Apr 2013 11:24:34 +0530, Sricharan R r.sricha...@ti.com wrote: So with OMAP added to multi platform kernel, the uImage no more contains a valid load address. With the uboot already supporting zImage, change the default boot command to bootz instead. Acked-by: Nishanth Menon n...@ti.com Signed-off-by: Sricharan R r.sricha...@ti.com Tested-by: Nishanth Menon n...@ti.com --- include/configs/omap4_common.h |4 ++-- include/configs/omap5_common.h |4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) Is there a reason why this patch does not have history? Amicalement, I had a minor change only in these two from the series. So reposted only these two with 'in-reply-to' threads. If this is not the right etiquette, then should it be update/appended in the original patch ? Regards, Sricharan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 5/5] ARM: OMAP4/5: Make bootz as the default boot command
On Friday 05 April 2013 01:38 PM, Albert ARIBAUD wrote: Hi Sricharan, On Fri, 5 Apr 2013 12:44:45 +0530, Sricharan R r.sricha...@ti.com wrote: Hi Albert, On Friday 05 April 2013 12:36 PM, Albert ARIBAUD wrote: Hi Sricharan, On Fri, 5 Apr 2013 11:24:34 +0530, Sricharan R r.sricha...@ti.com wrote: So with OMAP added to multi platform kernel, the uImage no more contains a valid load address. With the uboot already supporting zImage, change the default boot command to bootz instead. Acked-by: Nishanth Menon n...@ti.com Signed-off-by: Sricharan R r.sricha...@ti.com Tested-by: Nishanth Menon n...@ti.com --- include/configs/omap4_common.h |4 ++-- include/configs/omap5_common.h |4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) Is there a reason why this patch does not have history? Amicalement, I had a minor change only in these two from the series. So reposted only these two with 'in-reply-to' threads. If this is not the right etiquette, then should it be update/appended in the original patch ? My question is not about the series but only about 5/5 which has no patch history after the commit message delimiter (---) whereas 4/5 has history. If 5/5 has a minor change in V4, then it should have a history log indicating which minor change it was. ok. 5/5 was just rebase on 4/5. Will add it though. Sorry for the miss. Regards, Sricharan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V4 4/5] ARM: OMAP4/5: Change the default boot command to work with device tree
Now with kernel moving to all device tree, the default
boot command is changed to pass the device tree blob.
Also, adding the findfdt command to get the dt-blob
based on the board.
Thanks to Tom Rini tr...@ti.com for suggesting this.
Signed-off-by: Sricharan R r.sricha...@ti.com
---
[V4] Added environment variables bootdir, bootpart
and added loadimage, loadfdt commands as per
Tom's suggestion.
include/configs/omap4_common.h | 22 +++---
include/configs/omap5_common.h | 20 +---
2 files changed, 36 insertions(+), 6 deletions(-)
diff --git a/include/configs/omap4_common.h b/include/configs/omap4_common.h
index 6ae6a0f..7af3989 100644
--- a/include/configs/omap4_common.h
+++ b/include/configs/omap4_common.h
@@ -138,6 +138,10 @@
*/
#define CONFIG_BOOTDELAY 3
+#define CONFIG_ENV_VARS_UBOOT_CONFIG
+#define CONFIG_CMD_FS_GENERIC
+#define CONFIG_CMD_EXT2
+#define CONFIG_CMD_EXT4
#define CONFIG_ENV_OVERWRITE
@@ -145,6 +149,10 @@
loadaddr=0x8200\0 \
console=ttyO2,115200n8\0 \
fdt_high=0x\0 \
+ fdtaddr=0x80f8\0 \
+ bootpart=0:2\0 \
+ bootdir=/boot\0 \
+ bootfile=uImage\0 \
usbtty=cdc_acm\0 \
vram=16M\0 \
mmcdev=0\0 \
@@ -160,12 +168,19 @@
loadbootenv=fatload mmc ${mmcdev} ${loadaddr} uEnv.txt\0 \
importbootenv=echo Importing environment from mmc${mmcdev} ...; \
env import -t ${loadaddr} ${filesize}\0 \
- loaduimage=fatload mmc ${mmcdev} ${loadaddr} uImage\0 \
+ loadimage=load mmc ${bootpart} ${loadaddr} ${bootdir}/${bootfile}\0 \
mmcboot=echo Booting from mmc${mmcdev} ...; \
run mmcargs; \
- bootm ${loadaddr}\0 \
+ bootm ${loadaddr} - ${fdtaddr}\0 \
+ findfdt=\
+ if test $board_name = sdp4430; then \
+ setenv fdtfile omap4-sdp.dtb; fi; \
+ if test $board_name = panda; then \
+ setenv fdtfile omap4-panda-es.dtb; fi\0 \
+ loadfdt=load mmc ${bootpart} ${fdtaddr} ${bootdir}/${fdtfile}\0 \
#define CONFIG_BOOTCOMMAND \
+ run findfdt; \
mmc dev ${mmcdev}; if mmc rescan; then \
echo SD/MMC found on device ${mmcdev}; \
if run loadbootscript; then \
@@ -179,7 +194,8 @@
run uenvcmd; \
fi; \
fi; \
- if run loaduimage; then \
+ if run loadimage; then \
+ run loadfdt; \
run mmcboot; \
fi; \
fi
diff --git a/include/configs/omap5_common.h b/include/configs/omap5_common.h
index 6d7aa7b..6fb0253 100644
--- a/include/configs/omap5_common.h
+++ b/include/configs/omap5_common.h
@@ -137,6 +137,10 @@
*/
#define CONFIG_BOOTDELAY 3
+#define CONFIG_ENV_VARS_UBOOT_CONFIG
+#define CONFIG_CMD_FS_GENERIC
+#define CONFIG_CMD_EXT2
+#define CONFIG_CMD_EXT4
#define CONFIG_ENV_OVERWRITE
@@ -144,6 +148,10 @@
loadaddr=0x8200\0 \
console=ttyO2,115200n8\0 \
fdt_high=0x\0 \
+ fdtaddr=0x80f8\0 \
+ bootpart=0:2\0 \
+ bootdir=/boot\0 \
+ bootfile=uImage\0 \
usbtty=cdc_acm\0 \
vram=16M\0 \
mmcdev=0\0 \
@@ -159,12 +167,17 @@
loadbootenv=fatload mmc ${mmcdev} ${loadaddr} uEnv.txt\0 \
importbootenv=echo Importing environment from mmc${mmcdev} ...; \
env import -t ${loadaddr} ${filesize}\0 \
- loaduimage=fatload mmc ${mmcdev} ${loadaddr} uImage\0 \
+ loadimage=load mmc ${bootpart} ${loadaddr} ${bootdir}/${bootfile}\0 \
mmcboot=echo Booting from mmc${mmcdev} ...; \
run mmcargs; \
- bootm ${loadaddr}\0 \
+ bootm ${loadaddr} - ${fdtaddr}\0 \
+ findfdt=\
+ if test $board_name = omap5_uevm; then \
+ setenv fdtfile omap5-uevm.dtb; fi;\0 \
+ loadfdt=load mmc ${bootpart} ${fdtaddr} ${bootdir}/${fdtfile};\0 \
#define CONFIG_BOOTCOMMAND \
+ run findfdt; \
mmc dev ${mmcdev}; if mmc rescan; then \
if run loadbootscript; then \
run bootscript; \
@@ -177,7 +190,8 @@
run uenvcmd; \
fi; \
fi; \
- if run loaduimage; then \
+ if run loadimage; then \
+ run loadfdt; \
run mmcboot; \
fi; \
fi
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V4 5/5] ARM: OMAP4/5: Make bootz as the default boot command
So with OMAP added to multi platform kernel,
the uImage no more contains a valid load address.
With the uboot already supporting zImage,
change the default boot command to bootz
instead.
Acked-by: Nishanth Menon n...@ti.com
Signed-off-by: Sricharan R r.sricha...@ti.com
Tested-by: Nishanth Menon n...@ti.com
---
[V4] Just rebased on top of 4/5 th patch.
include/configs/omap4_common.h |4 ++--
include/configs/omap5_common.h |4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/include/configs/omap4_common.h b/include/configs/omap4_common.h
index 7af3989..1fd3097 100644
--- a/include/configs/omap4_common.h
+++ b/include/configs/omap4_common.h
@@ -152,7 +152,7 @@
fdtaddr=0x80f8\0 \
bootpart=0:2\0 \
bootdir=/boot\0 \
- bootfile=uImage\0 \
+ bootfile=zImage\0 \
usbtty=cdc_acm\0 \
vram=16M\0 \
mmcdev=0\0 \
@@ -171,7 +171,7 @@
loadimage=load mmc ${bootpart} ${loadaddr} ${bootdir}/${bootfile}\0 \
mmcboot=echo Booting from mmc${mmcdev} ...; \
run mmcargs; \
- bootm ${loadaddr} - ${fdtaddr}\0 \
+ bootz ${loadaddr} - ${fdtaddr}\0 \
findfdt=\
if test $board_name = sdp4430; then \
setenv fdtfile omap4-sdp.dtb; fi; \
diff --git a/include/configs/omap5_common.h b/include/configs/omap5_common.h
index 6fb0253..da0ead9 100644
--- a/include/configs/omap5_common.h
+++ b/include/configs/omap5_common.h
@@ -151,7 +151,7 @@
fdtaddr=0x80f8\0 \
bootpart=0:2\0 \
bootdir=/boot\0 \
- bootfile=uImage\0 \
+ bootfile=zImage\0 \
usbtty=cdc_acm\0 \
vram=16M\0 \
mmcdev=0\0 \
@@ -170,7 +170,7 @@
loadimage=load mmc ${bootpart} ${loadaddr} ${bootdir}/${bootfile}\0 \
mmcboot=echo Booting from mmc${mmcdev} ...; \
run mmcargs; \
- bootm ${loadaddr} - ${fdtaddr}\0 \
+ bootz ${loadaddr} - ${fdtaddr}\0 \
findfdt=\
if test $board_name = omap5_uevm; then \
setenv fdtfile omap5-uevm.dtb; fi;\0 \
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V4 4/5] ARM: OMAP4/5: Change the default boot command to work with device tree
Now with kernel moving to all device tree, the default
boot command is changed to pass the device tree blob.
Also, adding the findfdt command to get the dt-blob
based on the board.
Thanks to Tom Rini tr...@ti.com for suggesting this.
Signed-off-by: Sricharan R r.sricha...@ti.com
---
[V4] Added environment variables bootdir, bootpart
and added loadimage, loadfdt commands as per
Tom's suggestion.
include/configs/omap4_common.h | 22 +++---
include/configs/omap5_common.h | 20 +---
2 files changed, 36 insertions(+), 6 deletions(-)
diff --git a/include/configs/omap4_common.h b/include/configs/omap4_common.h
index 6ae6a0f..7af3989 100644
--- a/include/configs/omap4_common.h
+++ b/include/configs/omap4_common.h
@@ -138,6 +138,10 @@
*/
#define CONFIG_BOOTDELAY 3
+#define CONFIG_ENV_VARS_UBOOT_CONFIG
+#define CONFIG_CMD_FS_GENERIC
+#define CONFIG_CMD_EXT2
+#define CONFIG_CMD_EXT4
#define CONFIG_ENV_OVERWRITE
@@ -145,6 +149,10 @@
loadaddr=0x8200\0 \
console=ttyO2,115200n8\0 \
fdt_high=0x\0 \
+ fdtaddr=0x80f8\0 \
+ bootpart=0:2\0 \
+ bootdir=/boot\0 \
+ bootfile=uImage\0 \
usbtty=cdc_acm\0 \
vram=16M\0 \
mmcdev=0\0 \
@@ -160,12 +168,19 @@
loadbootenv=fatload mmc ${mmcdev} ${loadaddr} uEnv.txt\0 \
importbootenv=echo Importing environment from mmc${mmcdev} ...; \
env import -t ${loadaddr} ${filesize}\0 \
- loaduimage=fatload mmc ${mmcdev} ${loadaddr} uImage\0 \
+ loadimage=load mmc ${bootpart} ${loadaddr} ${bootdir}/${bootfile}\0 \
mmcboot=echo Booting from mmc${mmcdev} ...; \
run mmcargs; \
- bootm ${loadaddr}\0 \
+ bootm ${loadaddr} - ${fdtaddr}\0 \
+ findfdt=\
+ if test $board_name = sdp4430; then \
+ setenv fdtfile omap4-sdp.dtb; fi; \
+ if test $board_name = panda; then \
+ setenv fdtfile omap4-panda-es.dtb; fi\0 \
+ loadfdt=load mmc ${bootpart} ${fdtaddr} ${bootdir}/${fdtfile}\0 \
#define CONFIG_BOOTCOMMAND \
+ run findfdt; \
mmc dev ${mmcdev}; if mmc rescan; then \
echo SD/MMC found on device ${mmcdev}; \
if run loadbootscript; then \
@@ -179,7 +194,8 @@
run uenvcmd; \
fi; \
fi; \
- if run loaduimage; then \
+ if run loadimage; then \
+ run loadfdt; \
run mmcboot; \
fi; \
fi
diff --git a/include/configs/omap5_common.h b/include/configs/omap5_common.h
index 6d7aa7b..6fb0253 100644
--- a/include/configs/omap5_common.h
+++ b/include/configs/omap5_common.h
@@ -137,6 +137,10 @@
*/
#define CONFIG_BOOTDELAY 3
+#define CONFIG_ENV_VARS_UBOOT_CONFIG
+#define CONFIG_CMD_FS_GENERIC
+#define CONFIG_CMD_EXT2
+#define CONFIG_CMD_EXT4
#define CONFIG_ENV_OVERWRITE
@@ -144,6 +148,10 @@
loadaddr=0x8200\0 \
console=ttyO2,115200n8\0 \
fdt_high=0x\0 \
+ fdtaddr=0x80f8\0 \
+ bootpart=0:2\0 \
+ bootdir=/boot\0 \
+ bootfile=uImage\0 \
usbtty=cdc_acm\0 \
vram=16M\0 \
mmcdev=0\0 \
@@ -159,12 +167,17 @@
loadbootenv=fatload mmc ${mmcdev} ${loadaddr} uEnv.txt\0 \
importbootenv=echo Importing environment from mmc${mmcdev} ...; \
env import -t ${loadaddr} ${filesize}\0 \
- loaduimage=fatload mmc ${mmcdev} ${loadaddr} uImage\0 \
+ loadimage=load mmc ${bootpart} ${loadaddr} ${bootdir}/${bootfile}\0 \
mmcboot=echo Booting from mmc${mmcdev} ...; \
run mmcargs; \
- bootm ${loadaddr}\0 \
+ bootm ${loadaddr} - ${fdtaddr}\0 \
+ findfdt=\
+ if test $board_name = omap5_uevm; then \
+ setenv fdtfile omap5-uevm.dtb; fi;\0 \
+ loadfdt=load mmc ${bootpart} ${fdtaddr} ${bootdir}/${fdtfile};\0 \
#define CONFIG_BOOTCOMMAND \
+ run findfdt; \
mmc dev ${mmcdev}; if mmc rescan; then \
if run loadbootscript; then \
run bootscript; \
@@ -177,7 +190,8 @@
run uenvcmd; \
fi; \
fi; \
- if run loaduimage; then \
+ if run loadimage; then \
+ run loadfdt; \
run mmcboot; \
fi; \
fi
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V4 5/5] ARM: OMAP4/5: Make bootz as the default boot command
So with OMAP added to multi platform kernel,
the uImage no more contains a valid load address.
With the uboot already supporting zImage,
change the default boot command to bootz
instead.
Acked-by: Nishanth Menon n...@ti.com
Signed-off-by: Sricharan R r.sricha...@ti.com
Tested-by: Nishanth Menon n...@ti.com
---
include/configs/omap4_common.h |4 ++--
include/configs/omap5_common.h |4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/include/configs/omap4_common.h b/include/configs/omap4_common.h
index 7af3989..1fd3097 100644
--- a/include/configs/omap4_common.h
+++ b/include/configs/omap4_common.h
@@ -152,7 +152,7 @@
fdtaddr=0x80f8\0 \
bootpart=0:2\0 \
bootdir=/boot\0 \
- bootfile=uImage\0 \
+ bootfile=zImage\0 \
usbtty=cdc_acm\0 \
vram=16M\0 \
mmcdev=0\0 \
@@ -171,7 +171,7 @@
loadimage=load mmc ${bootpart} ${loadaddr} ${bootdir}/${bootfile}\0 \
mmcboot=echo Booting from mmc${mmcdev} ...; \
run mmcargs; \
- bootm ${loadaddr} - ${fdtaddr}\0 \
+ bootz ${loadaddr} - ${fdtaddr}\0 \
findfdt=\
if test $board_name = sdp4430; then \
setenv fdtfile omap4-sdp.dtb; fi; \
diff --git a/include/configs/omap5_common.h b/include/configs/omap5_common.h
index 6fb0253..da0ead9 100644
--- a/include/configs/omap5_common.h
+++ b/include/configs/omap5_common.h
@@ -151,7 +151,7 @@
fdtaddr=0x80f8\0 \
bootpart=0:2\0 \
bootdir=/boot\0 \
- bootfile=uImage\0 \
+ bootfile=zImage\0 \
usbtty=cdc_acm\0 \
vram=16M\0 \
mmcdev=0\0 \
@@ -170,7 +170,7 @@
loadimage=load mmc ${bootpart} ${loadaddr} ${bootdir}/${bootfile}\0 \
mmcboot=echo Booting from mmc${mmcdev} ...; \
run mmcargs; \
- bootm ${loadaddr} - ${fdtaddr}\0 \
+ bootz ${loadaddr} - ${fdtaddr}\0 \
findfdt=\
if test $board_name = omap5_uevm; then \
setenv fdtfile omap5-uevm.dtb; fi;\0 \
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Potential issue with recent OMAP PRCM struct unification
Hi Mike Cashwell, On Monday 01 April 2013 09:12 PM, Michael Cashwell wrote: Greetings, I think http://patchwork.ozlabs.org/patch/218063/ or something related to it has confused OMAP4 clock init. I haven't entirely unraveled the onion but wanted to ping the list to see if this is known or I'm off in the weeds. Using u-boot master at commit a268170 in DEBUG mode the SPL says (in part): Enable clock module - 4a008e20 Enable clock module - 4a008e28 Enable clock module - 4a008e40 later builds omit Enable clock module - 4a009338 these two clocks Enable clock module - 4a004528 Enable clock module - 4a004530 Enable clock module - 4a004538 That build works. But by commit 417c558 the 2 clocks noted are omitted and the later call to get_ram_size() hangs. In tracing this I found that the prcm structure initializes one field (cm_l3instr_intrconn_wp1_clkct) but then enable_non_essential_clocks() passes an array populated using a different field (cm_l3instr_intrconn_wp1_clkctrl) to do_enable_clocks(). That latter uninitialized field is zero which terminates that clock init array and results in the two clock omissions above. Searching for this and leaving out omap5 for clarity I see: cashwell.ubuntu:u-boot$ rgrep cm_l3instr_intrconn_wp1_clkct | grep -v omap5 ./arch/arm/cpu/armv7/omap4/prcm-regs.c: .cm_l3instr_intrconn_wp1_clkct = 0x4a008e40, ./arch/arm/cpu/armv7/omap4/hw_data.c: (*prcm)-cm_l3instr_intrconn_wp1_clkctrl, ./arch/arm/include/asm/omap_common.h: u32 cm_l3instr_intrconn_wp1_clkctrl; ./arch/arm/include/asm/omap_common.h: u32 cm_l3instr_intrconn_wp1_clkct; On first blush, it looks like having both cm_l3instr_intrconn_wp1_clkct and cm_l3instr_intrconn_wp1_clkctrl is a mistake. If that's true can anyone say which should be eliminated and whether or not the order of fields in struct prcm_regs matters? First, on which board are you testing ?. I tested the mainline on my 4460 ES1.1 PANDA and it booted. Also why are you enabling the non-essential clocks ? Now enabling non-essential clocks is deprecated and they are **not** by enabled by default. As you said the unnecessary entry in omap_common.h should be removed and typo in prcm-regs.c I can correct this, but does correcting this gets you working again ? Enabling these two clocks should have nothing to do with boot. Regards, Sricharan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Potential issue with recent OMAP PRCM struct unification
On Tuesday 02 April 2013 05:59 PM, Michael Cashwell wrote: On Apr 2, 2013, at 5:32 AM, Sricharan R r.sricha...@ti.com wrote: On first blush, it looks like having both cm_l3instr_intrconn_wp1_clkct and cm_l3instr_intrconn_wp1_clkctrl is a mistake. First, on which board are you testing ?. I tested the mainline on my 4460 ES1.1 PANDA and it booted. One custom board still under development and also on the same Pandaboard you have. But further testing showed that CONFIG_SYS_AUTOMATIC_SDRAM_DETECTION (and the related EMIF defines) stopped working somewhere between commits a268170 and 417c558. Returning to the pre-canned SDRAM modes allowed booting to work again. The reason I suspected the clocks was that they were the *only* difference in the entire debug log between the working and hanging cases. I don't know why the SDRAM state difference which was the real cause did not produce even a single difference in the log. Yes, i think AUTOMATIC_SDRAM_DETECTION is broken. I am having some patches to fix and will post shortly. Sorry,that you hit this issue. But these were any not because of the PRCM changes, it was much before that. As you said the unnecessary entry in omap_common.h should be removed and typo in prcm-regs.c I can correct this, but does correcting this gets you working again ? Enabling these two clocks should have nothing to do with boot. Correct. As I later found, the clocks in question are non-essential for u-boot and were not causing the hang. Also why are you enabling the non-essential clocks ? Because I must be able to boot Linux kernels as far back as 3.0.8 which predates this paradigm shift. Now enabling non-essential clocks is deprecated and they are **not** by enabled by default. As a point of clarification, are you asserting that CONFIG_SYS_CLOCKS_ENABLE_ALL and CONFIG_SYS_ENABLE_PADS_ALL have been officially deprecated (e.g.: is planned for removal from u-boot)? There is no mention of this anywhere within the source tree, including in any documentation or README and, IMO, it would be very premature given that at least 4 Linux kernel lines needing these inits are still within their longterm support window. But clearly until such removal happens dropping any that were previously handled is a regression. Thanks for the assistance! Yes, thats why we still have kept it for testing. But now, there are already patches to fix this in the kernel being posted, and probably all of them should be fixed shortly. Once that is done, all of this can be removed. Regards, Sricharan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 4/5] ARM: OMAP4/5: Change the default boot command to work with device tree
Hi Tom, On Tuesday 02 April 2013 12:50 AM, Tom Rini wrote: On Mon, Apr 01, 2013 at 09:22:41PM +0530, Sricharan R wrote: Now with kernel moving to all device tree, the default boot command is changed to pass the device tree blob. Also, adding the findfdt command to get the dt-blob based on the board. Thanks to Tom Rini tr...@ti.com for suggesting this. Signed-off-by: Sricharan R r.sricha...@ti.com [snip] @@ -145,6 +149,10 @@ loadaddr=0x8200\0 \ console=ttyO2,115200n8\0 \ fdt_high=0x\0 \ +fdtaddr=0x80f8\0 \ +bootpart=0:1\0 \ +bootdir=\0 \ +bootfile=uImage\0 \ What about 0:2 and /boot, ala am335x_evm as well? I'm not aware of any distributions being really clever and mounting the FAT partition to /boot and I know some that have been expecting and using their ext*-located kernels for a while for various TI platforms. And wer're moving in that latter direction too :) Thanks! Sorry, i am not clear here. You mean default partition should be '2' and not '1'. why ?. Is there any ordering like FAT-1, EXT2-2, etc ? The reason i added 0:1, was we generally have boot FAT as partition '1' and directly take images from there, without any hierarchies (/boot) Regards, Sricharan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Potential issue with recent OMAP PRCM struct unification
On Tuesday 02 April 2013 08:47 PM, Tom Rini wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/02/2013 11:06 AM, Sricharan R wrote: On Tuesday 02 April 2013 05:59 PM, Michael Cashwell wrote: On Apr 2, 2013, at 5:32 AM, Sricharan R r.sricha...@ti.com wrote: [snip] Also why are you enabling the non-essential clocks ? Because I must be able to boot Linux kernels as far back as 3.0.8 which predates this paradigm shift. Now enabling non-essential clocks is deprecated and they are **not** by enabled by default. As a point of clarification, are you asserting that CONFIG_SYS_CLOCKS_ENABLE_ALL and CONFIG_SYS_ENABLE_PADS_ALL have been officially deprecated (e.g.: is planned for removal from u-boot)? There is no mention of this anywhere within the source tree, including in any documentation or README and, IMO, it would be very premature given that at least 4 Linux kernel lines needing these inits are still within their longterm support window. But clearly until such removal happens dropping any that were previously handled is a regression. Thanks for the assistance! Yes, thats why we still have kept it for testing. But now, there are already patches to fix this in the kernel being posted, and probably all of them should be fixed shortly. Once that is done, all of this can be removed. So, here's my 2 cents on this. We can't up and drop these options from U-Boot until there's a complete / viable kernel tthhat doesn't need them. I'm _not_ saying we need to test every patchset vs an old kernel or anything, but we shouldn't intentionally make life harder on folks, until we can just pull the option all together (and say use a new kernel, or an older u-boot). Hmm, Agree this should not be broken unintentionally. But because we purposefully deprecated this, kernel is now getting fixed. Fixing any thing towards this deprecated one, will again introduce the luxury of not addressing in kernel, which is not good. If we propose of removing this in U-BOOT after every thing is fixed in kernel, we still will have of need of supporting for older kernels.. Regards, Sricharan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 4/5] ARM: OMAP4/5: Change the default boot command to work with device tree
On Tuesday 02 April 2013 09:43 PM, Tom Rini wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/02/2013 11:33 AM, Sricharan R wrote: Hi Tom, On Tuesday 02 April 2013 12:50 AM, Tom Rini wrote: On Mon, Apr 01, 2013 at 09:22:41PM +0530, Sricharan R wrote: Now with kernel moving to all device tree, the default boot command is changed to pass the device tree blob. Also, adding the findfdt command to get the dt-blob based on the board. Thanks to Tom Rini tr...@ti.com for suggesting this. Signed-off-by: Sricharan R r.sricha...@ti.com [snip] @@ -145,6 +149,10 @@ loadaddr=0x8200\0 \ console=ttyO2,115200n8\0 \ fdt_high=0x\0 \ + fdtaddr=0x80f8\0 \ + bootpart=0:1\0 \ +bootdir=\0 \ + bootfile=uImage\0 \ What about 0:2 and /boot, ala am335x_evm as well? I'm not aware of any distributions being really clever and mounting the FAT partition to /boot and I know some that have been expecting and using their ext*-located kernels for a while for various TI platforms. And wer're moving in that latter direction too :) Thanks! Sorry, i am not clear here. You mean default partition should be '2' and not '1'. why ?. Is there any ordering like FAT-1, EXT2-2, etc ? The reason i added 0:1, was we generally have boot FAT as partition '1' and directly take images from there, without any hierarchies (/boot) Right. I'm saying we should be pulling from the Linux filesystem for our kernel / device tree and move people toward pulling from EXT* (where the distro or vendor has provided them with a reasonable kernel, or they've updated their own there) and away from FAT. ok, get it. Will change then. Regards, Sricharan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Potential issue with recent OMAP PRCM struct unification
On Tuesday 02 April 2013 10:12 PM, Tom Rini wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/02/2013 11:55 AM, Sricharan R wrote: On Tuesday 02 April 2013 08:47 PM, Tom Rini wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/02/2013 11:06 AM, Sricharan R wrote: On Tuesday 02 April 2013 05:59 PM, Michael Cashwell wrote: On Apr 2, 2013, at 5:32 AM, Sricharan R r.sricha...@ti.com wrote: [snip] Also why are you enabling the non-essential clocks ? Because I must be able to boot Linux kernels as far back as 3.0.8 which predates this paradigm shift. Now enabling non-essential clocks is deprecated and they are **not** by enabled by default. As a point of clarification, are you asserting that CONFIG_SYS_CLOCKS_ENABLE_ALL and CONFIG_SYS_ENABLE_PADS_ALL have been officially deprecated (e.g.: is planned for removal from u-boot)? There is no mention of this anywhere within the source tree, including in any documentation or README and, IMO, it would be very premature given that at least 4 Linux kernel lines needing these inits are still within their longterm support window. But clearly until such removal happens dropping any that were previously handled is a regression. Thanks for the assistance! Yes, thats why we still have kept it for testing. But now, there are already patches to fix this in the kernel being posted, and probably all of them should be fixed shortly. Once that is done, all of this can be removed. So, here's my 2 cents on this. We can't up and drop these options from U-Boot until there's a complete / viable kernel tthhat doesn't need them. I'm _not_ saying we need to test every patchset vs an old kernel or anything, but we shouldn't intentionally make life harder on folks, until we can just pull the option all together (and say use a new kernel, or an older u-boot). Hmm, Agree this should not be broken unintentionally. But because we purposefully deprecated this, kernel is now getting fixed. Fixing any thing towards this deprecated one, will again introduce the luxury of not addressing in kernel, which is not good. If we propose of removing this in U-BOOT after every thing is fixed in kernel, we still will have of need of supporting for older kernels.. Yes, I'm assuming the kernel folks to continue with adding clocks they need in the right places now that the main event has happened and we aren't enabling more things until / unless we need them. And since I think that's going at reasonable speed, I don't think we need to draw a dated line in the sand, just one that says we shall remove the option, once a reasonable (read: most IO works) kernel tree is available that doesn't need this, we can remove it. Maybe we can set a hope to remove date? How about v2013.07? Yes, sounds good. Hopefully kernel fixed by then Regards, Sricharan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V4 2/5] ARM: OMAP5: Set fdt_high to enable booting with Device tree
While booting with dt blob, if fdt_high is not set to 0x, the dt blob gets relocated to a high ram address, which the kernel is not able to use without HIGHMEM. So set it to 0x to avoid the issue. Acked-by: Nishanth Menon n...@ti.com Signed-off-by: Sricharan R r.sricha...@ti.com Tested-by: Nishanth Menon n...@ti.com --- include/configs/omap5_common.h |1 + 1 file changed, 1 insertion(+) diff --git a/include/configs/omap5_common.h b/include/configs/omap5_common.h index af97564..f0416df 100644 --- a/include/configs/omap5_common.h +++ b/include/configs/omap5_common.h @@ -143,6 +143,7 @@ #define CONFIG_EXTRA_ENV_SETTINGS \ loadaddr=0x8200\0 \ console=ttyO2,115200n8\0 \ + fdt_high=0x\0 \ usbtty=cdc_acm\0 \ vram=16M\0 \ mmcdev=0\0 \ -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V4 1/5] ARM: OMAP5: Rename omap5_evm to omap5_uevm
The omap5-uevm is the reference board name for OMAP5 soc
based platform. So rename it accordingly.
Acked-by: Nishanth Menon n...@ti.com
Signed-off-by: Sricharan R r.sricha...@ti.com
Tested-by: Nishanth Menon n...@ti.com
---
board/ti/{omap5_evm = omap5_uevm}/Makefile |0
board/ti/{omap5_evm = omap5_uevm}/evm.c |0
board/ti/{omap5_evm = omap5_uevm}/mux_data.h |0
boards.cfg|2 +-
include/configs/{omap5_evm.h = omap5_uevm.h} |0
5 files changed, 1 insertion(+), 1 deletion(-)
rename board/ti/{omap5_evm = omap5_uevm}/Makefile (100%)
rename board/ti/{omap5_evm = omap5_uevm}/evm.c (100%)
rename board/ti/{omap5_evm = omap5_uevm}/mux_data.h (100%)
rename include/configs/{omap5_evm.h = omap5_uevm.h} (100%)
diff --git a/board/ti/omap5_evm/Makefile b/board/ti/omap5_uevm/Makefile
similarity index 100%
rename from board/ti/omap5_evm/Makefile
rename to board/ti/omap5_uevm/Makefile
diff --git a/board/ti/omap5_evm/evm.c b/board/ti/omap5_uevm/evm.c
similarity index 100%
rename from board/ti/omap5_evm/evm.c
rename to board/ti/omap5_uevm/evm.c
diff --git a/board/ti/omap5_evm/mux_data.h b/board/ti/omap5_uevm/mux_data.h
similarity index 100%
rename from board/ti/omap5_evm/mux_data.h
rename to board/ti/omap5_uevm/mux_data.h
diff --git a/boards.cfg b/boards.cfg
index ee68fdd..c9ad3ff 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -291,7 +291,7 @@ twister arm armv7
twister technex
nokia_rx51 arm armv7 rx51nokia
omap3
omap4_panda arm armv7 panda ti
omap4
omap4_sdp4430arm armv7 sdp4430 ti
omap4
-omap5_evmarm armv7 omap5_evm ti
omap5
+omap5_uevm arm armv7 omap5_uevm ti
omap5
dra7xx_evm arm armv7 dra7xx ti
omap5
s5p_goni arm armv7 goni
samsungs5pc1xx
smdkc100 arm armv7 smdkc100
samsungs5pc1xx
diff --git a/include/configs/omap5_evm.h b/include/configs/omap5_uevm.h
similarity index 100%
rename from include/configs/omap5_evm.h
rename to include/configs/omap5_uevm.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 V4 3/5] omap5: Allow use of a plain text env file
From: Nishanth Menon n...@ti.com
For production systems it is better to use script images since
they are protected by checksums and carry valuable information
like name and timestamp. Also, you can't validate the content
passed to env import.
But for development, it is easier to use the env import command and
plain text files instead of script-images.
Since both OMAP5evm/uevm boards are used primarily for development,
we allow U-Boot to load env var from a text file in case that an
boot.scr script-image is not present.
The variable uenvcmd (if existent) will be executed (using run) after
uEnv.txt was loaded. If uenvcmd doesn't exist the default boot sequence
will be started.
Inspired by commit: d70f54808dfa83b574e1239c3eccbcf3317343e1
(omap4: allow the use of a plain text env file instead boot scripts)
Signed-off-by: Sricharan R r.sricha...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
Tested-by: Sricharan R r.sricha...@ti.com
---
include/configs/omap5_common.h | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/include/configs/omap5_common.h b/include/configs/omap5_common.h
index f0416df..6d7aa7b 100644
--- a/include/configs/omap5_common.h
+++ b/include/configs/omap5_common.h
@@ -156,6 +156,9 @@
loadbootscript=fatload mmc ${mmcdev} ${loadaddr} boot.scr\0 \
bootscript=echo Running bootscript from mmc${mmcdev} ...; \
source ${loadaddr}\0 \
+ loadbootenv=fatload mmc ${mmcdev} ${loadaddr} uEnv.txt\0 \
+ importbootenv=echo Importing environment from mmc${mmcdev} ...; \
+ env import -t ${loadaddr} ${filesize}\0 \
loaduimage=fatload mmc ${mmcdev} ${loadaddr} uImage\0 \
mmcboot=echo Booting from mmc${mmcdev} ...; \
run mmcargs; \
@@ -166,9 +169,16 @@
if run loadbootscript; then \
run bootscript; \
else \
- if run loaduimage; then \
- run mmcboot; \
- fi; \
+ if run loadbootenv; then \
+ run importbootenv; \
+ fi; \
+ if test -n ${uenvcmd}; then \
+ echo Running uenvcmd ...; \
+ run uenvcmd; \
+ fi; \
+ fi; \
+ if run loaduimage; then \
+ run mmcboot; \
fi; \
fi
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V4 5/5] ARM: OMAP4/5: Make bootz as the default boot command
So with OMAP added to multi platform kernel,
the uImage no more contains a valid load address.
With the uboot already supporting zImage,
change the default boot command to bootz
instead.
Acked-by: Nishanth Menon n...@ti.com
Signed-off-by: Sricharan R r.sricha...@ti.com
Tested-by: Nishanth Menon n...@ti.com
---
include/configs/omap4_common.h |4 ++--
include/configs/omap5_common.h |4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/include/configs/omap4_common.h b/include/configs/omap4_common.h
index 18cd98f..5ad606e 100644
--- a/include/configs/omap4_common.h
+++ b/include/configs/omap4_common.h
@@ -152,7 +152,7 @@
fdtaddr=0x80f8\0 \
bootpart=0:1\0 \
bootdir=\0 \
- bootfile=uImage\0 \
+ bootfile=zImage\0 \
usbtty=cdc_acm\0 \
vram=16M\0 \
mmcdev=0\0 \
@@ -171,7 +171,7 @@
loadimage=load mmc ${bootpart} ${loadaddr} ${bootdir}/${bootfile}\0 \
mmcboot=echo Booting from mmc${mmcdev} ...; \
run mmcargs; \
- bootm ${loadaddr} - ${fdtaddr}\0 \
+ bootz ${loadaddr} - ${fdtaddr}\0 \
findfdt=\
if test $board_name = sdp4430; then \
setenv fdtfile omap4-sdp.dtb; fi; \
diff --git a/include/configs/omap5_common.h b/include/configs/omap5_common.h
index 24c9ecc..44c35b1 100644
--- a/include/configs/omap5_common.h
+++ b/include/configs/omap5_common.h
@@ -151,7 +151,7 @@
fdtaddr=0x80f8\0 \
bootpart=0:1\0 \
bootdir=\0 \
- bootfile=uImage\0 \
+ bootfile=zImage\0 \
usbtty=cdc_acm\0 \
vram=16M\0 \
mmcdev=0\0 \
@@ -170,7 +170,7 @@
loadimage=load mmc ${bootpart} ${loadaddr} ${bootdir}/${bootfile}\0 \
mmcboot=echo Booting from mmc${mmcdev} ...; \
run mmcargs; \
- bootm ${loadaddr} - ${fdtaddr}\0 \
+ bootz ${loadaddr} - ${fdtaddr}\0 \
findfdt=\
if test $board_name = omap5_uevm; then \
setenv fdtfile omap5-uevm.dtb; fi;\0 \
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V4 4/5] ARM: OMAP4/5: Change the default boot command to work with device tree
Now with kernel moving to all device tree, the default
boot command is changed to pass the device tree blob.
Also, adding the findfdt command to get the dt-blob
based on the board.
Thanks to Tom Rini tr...@ti.com for suggesting this.
Signed-off-by: Sricharan R r.sricha...@ti.com
---
[V4] Added environment variables bootdir, bootpart
and added loadimage, loadfdt commands as per
Tom's suggestion.
include/configs/omap4_common.h | 22 +++---
include/configs/omap5_common.h | 20 +---
2 files changed, 36 insertions(+), 6 deletions(-)
diff --git a/include/configs/omap4_common.h b/include/configs/omap4_common.h
index 6ae6a0f..18cd98f 100644
--- a/include/configs/omap4_common.h
+++ b/include/configs/omap4_common.h
@@ -138,6 +138,10 @@
*/
#define CONFIG_BOOTDELAY 3
+#define CONFIG_ENV_VARS_UBOOT_CONFIG
+#define CONFIG_CMD_FS_GENERIC
+#define CONFIG_CMD_EXT2
+#define CONFIG_CMD_EXT4
#define CONFIG_ENV_OVERWRITE
@@ -145,6 +149,10 @@
loadaddr=0x8200\0 \
console=ttyO2,115200n8\0 \
fdt_high=0x\0 \
+ fdtaddr=0x80f8\0 \
+ bootpart=0:1\0 \
+ bootdir=\0 \
+ bootfile=uImage\0 \
usbtty=cdc_acm\0 \
vram=16M\0 \
mmcdev=0\0 \
@@ -160,12 +168,19 @@
loadbootenv=fatload mmc ${mmcdev} ${loadaddr} uEnv.txt\0 \
importbootenv=echo Importing environment from mmc${mmcdev} ...; \
env import -t ${loadaddr} ${filesize}\0 \
- loaduimage=fatload mmc ${mmcdev} ${loadaddr} uImage\0 \
+ loadimage=load mmc ${bootpart} ${loadaddr} ${bootdir}/${bootfile}\0 \
mmcboot=echo Booting from mmc${mmcdev} ...; \
run mmcargs; \
- bootm ${loadaddr}\0 \
+ bootm ${loadaddr} - ${fdtaddr}\0 \
+ findfdt=\
+ if test $board_name = sdp4430; then \
+ setenv fdtfile omap4-sdp.dtb; fi; \
+ if test $board_name = panda; then \
+ setenv fdtfile omap4-panda-es.dtb; fi\0 \
+ loadfdt=load mmc ${bootpart} ${fdtaddr} ${bootdir}/${fdtfile}\0 \
#define CONFIG_BOOTCOMMAND \
+ run findfdt; \
mmc dev ${mmcdev}; if mmc rescan; then \
echo SD/MMC found on device ${mmcdev}; \
if run loadbootscript; then \
@@ -179,7 +194,8 @@
run uenvcmd; \
fi; \
fi; \
- if run loaduimage; then \
+ if run loadimage; then \
+ run loadfdt; \
run mmcboot; \
fi; \
fi
diff --git a/include/configs/omap5_common.h b/include/configs/omap5_common.h
index 6d7aa7b..24c9ecc 100644
--- a/include/configs/omap5_common.h
+++ b/include/configs/omap5_common.h
@@ -137,6 +137,10 @@
*/
#define CONFIG_BOOTDELAY 3
+#define CONFIG_ENV_VARS_UBOOT_CONFIG
+#define CONFIG_CMD_FS_GENERIC
+#define CONFIG_CMD_EXT2
+#define CONFIG_CMD_EXT4
#define CONFIG_ENV_OVERWRITE
@@ -144,6 +148,10 @@
loadaddr=0x8200\0 \
console=ttyO2,115200n8\0 \
fdt_high=0x\0 \
+ fdtaddr=0x80f8\0 \
+ bootpart=0:1\0 \
+ bootdir=\0 \
+ bootfile=uImage\0 \
usbtty=cdc_acm\0 \
vram=16M\0 \
mmcdev=0\0 \
@@ -159,12 +167,17 @@
loadbootenv=fatload mmc ${mmcdev} ${loadaddr} uEnv.txt\0 \
importbootenv=echo Importing environment from mmc${mmcdev} ...; \
env import -t ${loadaddr} ${filesize}\0 \
- loaduimage=fatload mmc ${mmcdev} ${loadaddr} uImage\0 \
+ loadimage=load mmc ${bootpart} ${loadaddr} ${bootdir}/${bootfile}\0 \
mmcboot=echo Booting from mmc${mmcdev} ...; \
run mmcargs; \
- bootm ${loadaddr}\0 \
+ bootm ${loadaddr} - ${fdtaddr}\0 \
+ findfdt=\
+ if test $board_name = omap5_uevm; then \
+ setenv fdtfile omap5-uevm.dtb; fi;\0 \
+ loadfdt=load mmc ${bootpart} ${fdtaddr} ${bootdir}/${fdtfile};\0 \
#define CONFIG_BOOTCOMMAND \
+ run findfdt; \
mmc dev ${mmcdev}; if mmc rescan; then \
if run loadbootscript; then \
run bootscript; \
@@ -177,7 +190,8 @@
run uenvcmd; \
fi; \
fi; \
- if run loaduimage; then \
+ if run loadimage; then \
+ run loadfdt; \
run mmcboot; \
fi; \
fi
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V4 0/5] ARM: OMAP4/5: Add support to boot with device tree as default
With the kernel moving all towards device tree, this series
adds support to make the device tree boot as the default
for OMAP4/5 platforms.
Nishanth Menon (1):
omap5: Allow use of a plain text env file
Sricharan R (4):
ARM: OMAP5: Rename omap5_evm to omap5_uevm
ARM: OMAP5: Set fdt_high to enable booting with Device tree
ARM: OMAP4/5: Change the default boot command to work with device
tree
ARM: OMAP4/5: Make bootz as the default boot command
board/ti/{omap5_evm = omap5_uevm}/Makefile |0
board/ti/{omap5_evm = omap5_uevm}/evm.c |0
board/ti/{omap5_evm = omap5_uevm}/mux_data.h |0
boards.cfg|2 +-
include/configs/omap4_common.h| 22 +---
include/configs/omap5_common.h| 35 +
include/configs/{omap5_evm.h = omap5_uevm.h} |0
7 files changed, 50 insertions(+), 9 deletions(-)
rename board/ti/{omap5_evm = omap5_uevm}/Makefile (100%)
rename board/ti/{omap5_evm = omap5_uevm}/evm.c (100%)
rename board/ti/{omap5_evm = omap5_uevm}/mux_data.h (100%)
rename include/configs/{omap5_evm.h = omap5_uevm.h} (100%)
--
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 V3 4/5] ARM: OMAP4/5: Change the default boot command to work with device tree
On Wednesday 27 March 2013 09:15 PM, Tom Rini wrote:
On Tue, Mar 26, 2013 at 09:57:35AM +0530, Sricharan R wrote:
Now with kernel moving to all device tree, the default
boot command is changed to pass the device tree blob.
Also, adding the findfdt command to get the dt-blob
based on the board.
[snip]
@@ -153,7 +155,9 @@
mmcargs=setenv bootargs console=${console} \
vram=${vram} \
root=${mmcroot} \
-rootfstype=${mmcrootfstype}\0 \
+rootfstype=${mmcrootfstype}; \
+run findfdt; \
+fatload mmc ${mmcdev} ${fdtaddr} ${fdtfile}\0 \
I missed this part before, sorry. What we do on am335x_evm to allow
for easier overrides is:
- bootcmd runs findfdt (since we'll need it in all cases).
- Enable CONFIG_CMD_FS_GENERIC
- Add a 'loadfdt' command that can be called out ala loaduimage
- Use 'load' in loadfdt/loaduimage so that we don't care what the
underlying filesystem type is.
- Use bootdir to help with overrides as well:
loaduimage=load mmc ${bootpart} ${loadaddr} ${bootdir}/${bootfile}
loadfdt=load mmc ${bootpart} ${fdtaddr} ${bootdir}/${fdtfile}
So that we can easily grab from the first partition (FAT) or another
partition (ext3/4/etc).
Yeah, liked this. Thanks for detailed explanation. Will add this
then for better.
Regards,
Sricharan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 0/9] OMAP3-5: TWL[46]03[05]: cleanup register access and misc minimal cleanups
Hi Nishanth, On Monday 25 March 2013 11:50 PM, Nishanth Menon wrote: Hi Sricharan, On Mon, Mar 25, 2013 at 12:47 PM, Sricharan R r.sricha...@ti.com wrote: All of TWL[46]03[05]_i2c_[write/read]_u8 is doing the same. (ie) i2c_write(chip_no, reg, 1, val, 1); i2c_read(chip_no, reg, 1, val, 1); We always seem to use 1 byte addresses and length. Then why can't we move to to twl_common.h and use just one function every where ? Otherwise, this is a required cleanup. I had initially considered that, but then having twl6030, 6035, 4030 as API names help us to know from readability angle which register is being accessed and if it the right one. Further, the PMICs are drastically different that using a twl_read_write_u8 might end up confusing reviewer/readability. + the fact that they are inline allows us to have no overhead. Now, while adding support for VAYU which has TPS659038, in the current approach we will end up creating a new tps659038.h which does exactly the same thing. This does not feel correct. Can't we differentiate using register names that are passed instead ? Regards, Sricharan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 0/9] OMAP3-5: TWL[46]03[05]: cleanup register access and misc minimal cleanups
On Tuesday 26 March 2013 06:55 PM, Nishanth Menon wrote: On 15:01-20130326, Sricharan R wrote: approach we will end up creating a new tps659038.h which does exactly the same thing. This does not feel correct. Can't we differentiate using register names that are passed instead ? tps659038/twl6035/twl6037 all belong to palmas family of PMICs. So, how about renaming the file to palmas.c and use palmas_i2c_read/write functions? Yes, sounds good. Regards, Sricharan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3 00/10] OMAP3-5: TWL[46]03[05]: cleanup register access and misc minimal cleanups
Hi Nishanth,
On Tuesday 26 March 2013 08:50 PM, Nishanth Menon wrote:
This series helps standardize register parameters for TWL4030, 6030 and 6035
used in various OMAP3,4,5 based platforms.
For historical reasons, we have been following val, reg as the order of
parameters while we have reg, val in every other i2c apis including i2c
mw/mr command @ u-boot cmd line, with kernel APIs, i2cget, i2cset utilities.
Instead of maintaining this forked implementation, it is never too late to
fix them.
Since TPS659038/TWL6035/TWL6037 all belong to the Palmas family of TI PMICs
and are mostly compatible among each other, we rename twl6035 to palmas as
part
of this cleanup.
Build tested (MAKEALL) platforms-at least these seem to be be impacted ones:
cm_t35
devkit8000
dig297
igep0020
igep0020_nand
igep0030
igep0030_nand
nokia_rx51
omap3_beagle
omap3_evm
omap3_evm_quick_mmc
omap3_evm_quick_nand
omap3_logic
omap3_mvblx
omap3_overo
omap3_pandora
omap3_sdp3430
omap3_zoom1
omap3_zoom2
omap4_panda
omap4_sdp4430
omap5_evm
tricorder
dra7xx_evm
Boot tested platforms (upto kernel+shell with dtb):
omap3_beagle - tested on beagle XM (C1), beagle(C1D) - TWL4030
omap4_panda - tested on PandaBoard(A3) and PandaBoard-ES(EB3) - TWL6030
omap5_evm - OMAP5 uEVM - TWL6035
twl4030 changes are little wider in scope, so I have split them
into two patches to help review
Series is based on u-boot master:
master 8b906a9 Merge branch 'spi' of git://git.denx.de/u-boot-x86
(rationale being the changes if done on v2013.04-rc1 have much changes to
allow this series to apply cleanly on the latest)
NOTE: the series tries to cleanup existing indentation style to allow the
new code to be in sync with checkpatch suggestions.
V2: http://marc.info/?t=13639881686r=1w=2
V1: http://patchwork.ozlabs.org/patch/227112/
Changes since V2 in this series:
- rename of twl6035 to palmas and associated changes
- minor updates to cleaup checkpatch warnings
Nishanth Menon (10):
twl4030: make twl4030_i2c_write_u8 prototype consistent
twl4030: make twl4030_i2c_read_u8 prototype consistent
twl6030: twl6030_i2c_[read|write]_u8 prototype consistent
twl6030: move twl6030 register access functions to common header file
twl6030: add header guard
twl6035: rename to palmas
palmas: rename init_settings to an generic palmas init
palmas: rename twl6035_mmc1_poweron_ldo with an palmas generic
function
palmas: use palmas_i2c_[read|write]_u8
palmas: add header guard
board/cm_t35/cm_t35.c | 24 +--
board/nokia/rx51/rx51.c | 52 +++
board/pandora/pandora.c |3 +-
board/ti/dra7xx/evm.c |2 +-
board/ti/omap5_evm/evm.c |6 +--
drivers/misc/twl4030_led.c|4 +-
drivers/mmc/omap_hsmmc.c |8 ++--
drivers/power/Makefile|2 +-
drivers/power/{twl6035.c = palmas.c} | 34 +++
drivers/power/twl4030.c | 16 +++
drivers/power/twl6030.c | 75
++---
drivers/usb/phy/twl4030.c | 48 ++---
include/configs/omap5_evm.h |2 +-
include/{twl6035.h = palmas.h} | 28 +---
include/twl4030.h |4 +-
include/twl6030.h | 16 +++
16 files changed, 162 insertions(+), 162 deletions(-)
rename drivers/power/{twl6035.c = palmas.c} (61%)
rename include/{twl6035.h = palmas.h} (68%)
Regards,
Nishanth Menon
Acked-by: R Sricharan r.sricha...@ti.com for the series
Regards,
Sricharan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: omap: emif: Support for ddr3 after warm reset
On Wednesday 27 March 2013 09:55 AM, Lokesh Vutla wrote:
EMIF supports a global warm reset mode, during which the
EMIF keeps the SDRAM content. But if leveling is enabled
at the time of warm reset for DDR3, the following steps
needs to be done after warm reset:
1) Keep EMIF in self refresh mode.
2) Reset PHY to bring back the PHY to a known state.
3) Start Levelling procedure.
Doing the same.
And also enabling DLL lock and code output after warm reset.
Should the $subject be something like
Fix DDR3 initialisation after warm reset ?
Tested on OMAP5432 ES2.0
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
arch/arm/cpu/armv7/omap-common/emif-common.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap-common/emif-common.c
b/arch/arm/cpu/armv7/omap-common/emif-common.c
index 9eb1279..8811958 100644
--- a/arch/arm/cpu/armv7/omap-common/emif-common.c
+++ b/arch/arm/cpu/armv7/omap-common/emif-common.c
@@ -1072,6 +1072,12 @@ static void do_sdram_init(u32 base)
else
ddr3_init(base, regs);
}
+ if (!in_sdram warm_reset()
+ (emif_sdram_type() == EMIF_SDRAM_TYPE_DDR3)) {
+ set_lpmode_selfrefresh(base);
+ emif_reset_phy(base);
+ ddr3_leveling(base, regs);
+ }
Why do we need !in_sdram check here ?. Otherwise, good..
Reviewed-by: R Sricharan r.sricha...@ti.com
Regards,
Sricharan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/5] ARM: OMAP4/5: Add support to boot with device tree as default
On Monday 25 March 2013 09:31 PM, Nishanth Menon wrote:
On 13:54-20130323, Sricharan R wrote:
With the kernel moving all towards device tree, this series
adds support to make the device tree boot as the default
for OMAP4/5 platforms.
Sricharan R (5):
ARM: OMAP5: Rename omap5_evm.h to omap5_uevm.h
ARM: OMAP5: Set fdt_high to enable booting with Device tree
ARM: OMAP5: Support loading environment variables from txt file
ARM: OMAP4/5: Change the default boot command to work with device
tree
ARM: OMAP4/5: Make bootz as the default boot command
board/ti/omap5_evm/Makefile| 49 ---
board/ti/omap5_evm/evm.c | 101 -
board/ti/omap5_evm/mux_data.h | 304
board/ti/omap5_uevm/Makefile | 49 +++
board/ti/omap5_uevm/evm.c | 101 +
board/ti/omap5_uevm/mux_data.h | 304
boards.cfg |2 +-
include/configs/omap4_common.h | 16 ++-
include/configs/omap5_common.h | 30 +++-
include/configs/omap5_evm.h| 40 --
include/configs/omap5_uevm.h | 40 ++
11 files changed, 531 insertions(+), 505 deletions(-)
delete mode 100644 board/ti/omap5_evm/Makefile
delete mode 100644 board/ti/omap5_evm/evm.c
delete mode 100644 board/ti/omap5_evm/mux_data.h
create mode 100644 board/ti/omap5_uevm/Makefile
create mode 100644 board/ti/omap5_uevm/evm.c
create mode 100644 board/ti/omap5_uevm/mux_data.h
delete mode 100644 include/configs/omap5_evm.h
create mode 100644 include/configs/omap5_uevm.h
Series:
Tested-by: Nishanth Menon n...@ti.com
{assuming change stated in http://patchwork.ozlabs.org/patch/230283/
Acked-by: Nishanth Menon n...@ti.com
Thanks Nishanth.
Posting V3 to include your patch.
Regards,
Sricharan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 0/9] OMAP3-5: TWL[46]03[05]: cleanup register access and misc minimal cleanups
Hi Nishanth, On Saturday 23 March 2013 03:03 AM, Nishanth Menon wrote: V1: http://patchwork.ozlabs.org/patch/227112/ This series helps standardize register parameters for TWL4030, 6030 and 6035 used in various OMAP3,4,5 based platforms. For historical reasons, we have been following val, reg as the order of parameters while we have reg, val in every other i2c apis including i2c mw/mr command @ u-boot cmd line, with kernel APIs, i2cget, i2cset utilities. Instead of maintaining this forked implementation, it is never too late to fix them. Build tested (MAKEALL) platforms-at least these seem to be be impacted ones: cm_t35 devkit8000 dig297 igep0020 igep0020_nand igep0030 igep0030_nand nokia_rx51 omap3_beagle omap3_evm omap3_evm_quick_mmc omap3_evm_quick_nand omap3_logic omap3_mvblx omap3_overo omap3_pandora omap3_sdp3430 omap3_zoom1 omap3_zoom2 omap4_panda omap4_sdp4430 omap5_evm tricorder Boot tested platforms (upto kernel+shell with dtb): omap3_beagle - tested on beagle XM (C1), beagle(C1D) - TWL4030 omap4_panda - tested on PandaBoard(A3) and PandaBoard-ES(EB3) - TWL6030 omap5_evm - OMAP5 uEVM - TWL6035 twl4030 changes are little wider in scope, so I have split them into two patches to help review Series is based on u-boot master: master 8b906a9 Merge branch 'spi' of git://git.denx.de/u-boot-x86 (rationale being the changes if done on v2013.04-rc1 have much changes to allow this series to apply cleanly on the latest) NOTE: the series tries to maintain existing indentation style to allow the code to stay in sync with legacy code. Nishanth Menon (9): twl4030: make twl4030_i2c_write_u8 prototype consistent twl4030: make twl4030_i2c_read_u8 prototype consistent twl6030: twl6030_i2c_[read|write]_u8 prototype consistent twl6030: move twl6030 register access functions to common header file twl6030: add header guard twl6035: make twl6030_i2c_[read|write]_u8 static inline twl6035: twl6035_i2c_[read|write]_u8 prototype consistent twl6035: remove redundant palmas_[read|write]_u8 twl6035: add header guard board/cm_t35/cm_t35.c | 24 +++--- board/nokia/rx51/rx51.c| 52 +++--- board/pandora/pandora.c|3 +- drivers/misc/twl4030_led.c |4 +-- drivers/power/twl4030.c| 16 +- drivers/power/twl6030.c| 75 +++- drivers/power/twl6035.c| 26 ++- drivers/usb/phy/twl4030.c | 48 ++-- include/twl4030.h |4 +-- include/twl6030.h | 16 ++ include/twl6035.h | 18 +-- 11 files changed, 142 insertions(+), 144 deletions(-) Regards, Nishanth Menon All of TWL[46]03[05]_i2c_[write/read]_u8 is doing the same. (ie) i2c_write(chip_no, reg, 1, val, 1); i2c_read(chip_no, reg, 1, val, 1); We always seem to use 1 byte addresses and length. Then why can't we move to to twl_common.h and use just one function every where ? Otherwise, this is a required cleanup. Reviewed-by: R Sricharan r.sricha...@ti.com Regards, Sricharan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V3 5/5] ARM: OMAP4/5: Make bootz as the default boot command
So with OMAP added to multi platform kernel,
the uImage no more contains a valid load address.
With the uboot already supporting zImage,
change the default boot command to bootz
instead.
Acked-by: Nishanth Menon n...@ti.com
Signed-off-by: Sricharan R r.sricha...@ti.com
Tested-by: Nishanth Menon n...@ti.com
---
include/configs/omap4_common.h |6 +++---
include/configs/omap5_common.h |6 +++---
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/include/configs/omap4_common.h b/include/configs/omap4_common.h
index f34c130..ce32ecd 100644
--- a/include/configs/omap4_common.h
+++ b/include/configs/omap4_common.h
@@ -164,10 +164,10 @@
loadbootenv=fatload mmc ${mmcdev} ${loadaddr} uEnv.txt\0 \
importbootenv=echo Importing environment from mmc${mmcdev} ...; \
env import -t ${loadaddr} ${filesize}\0 \
- loaduimage=fatload mmc ${mmcdev} ${loadaddr} uImage\0 \
+ loadzimage=fatload mmc ${mmcdev} ${loadaddr} zImage\0 \
mmcboot=echo Booting from mmc${mmcdev} ...; \
run mmcargs; \
- bootm ${loadaddr} - ${fdtaddr}\0 \
+ bootz ${loadaddr} - ${fdtaddr}\0 \
findfdt=\
if test $board_name = sdp4430; then \
setenv fdtfile omap4-sdp.dtb; fi; \
@@ -188,7 +188,7 @@
run uenvcmd; \
fi; \
fi; \
- if run loaduimage; then \
+ if run loadzimage; then \
run mmcboot; \
fi; \
fi
diff --git a/include/configs/omap5_common.h b/include/configs/omap5_common.h
index bcbf9cc..535265a 100644
--- a/include/configs/omap5_common.h
+++ b/include/configs/omap5_common.h
@@ -163,10 +163,10 @@
loadbootenv=fatload mmc ${mmcdev} ${loadaddr} uEnv.txt\0 \
importbootenv=echo Importing environment from mmc${mmcdev} ...; \
env import -t ${loadaddr} ${filesize}\0 \
- loaduimage=fatload mmc ${mmcdev} ${loadaddr} uImage\0 \
+ loadzimage=fatload mmc ${mmcdev} ${loadaddr} zImage\0 \
mmcboot=echo Booting from mmc${mmcdev} ...; \
run mmcargs; \
- bootm ${loadaddr} - ${fdtaddr}\0 \
+ bootz ${loadaddr} - ${fdtaddr}\0 \
findfdt=\
if test $board_name = omap5_uevm; then \
setenv fdtfile omap5-uevm.dtb; fi;\0 \
@@ -184,7 +184,7 @@
run uenvcmd; \
fi; \
fi; \
- if run loaduimage; then \
+ if run loadzimage; then \
run mmcboot; \
fi; \
fi
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V3 2/5] ARM: OMAP5: Set fdt_high to enable booting with Device tree
While booting with dt blob, if fdt_high is not set to 0x, the dt blob gets relocated to a high ram address, which the kernel is not able to use without HIGHMEM. So set it to 0x to avoid the issue. Acked-by: Nishanth Menon n...@ti.com Signed-off-by: Sricharan R r.sricha...@ti.com Tested-by: Nishanth Menon n...@ti.com --- include/configs/omap5_common.h |1 + 1 file changed, 1 insertion(+) diff --git a/include/configs/omap5_common.h b/include/configs/omap5_common.h index af97564..f0416df 100644 --- a/include/configs/omap5_common.h +++ b/include/configs/omap5_common.h @@ -143,6 +143,7 @@ #define CONFIG_EXTRA_ENV_SETTINGS \ loadaddr=0x8200\0 \ console=ttyO2,115200n8\0 \ + fdt_high=0x\0 \ usbtty=cdc_acm\0 \ vram=16M\0 \ mmcdev=0\0 \ -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V3 1/5] ARM: OMAP5: Rename omap5_evm to omap5_uevm
The omap5-uevm is the reference board name for OMAP5 soc
based platform. So rename it accordingly.
Acked-by: Nishanth Menon n...@ti.com
Signed-off-by: Sricharan R r.sricha...@ti.com
Tested-by: Nishanth Menon n...@ti.com
---
[V2] Formatted the patch using -M option to detect renames
and edited the subject
[V3] No change
board/ti/{omap5_evm = omap5_uevm}/Makefile |0
board/ti/{omap5_evm = omap5_uevm}/evm.c |0
board/ti/{omap5_evm = omap5_uevm}/mux_data.h |0
boards.cfg|2 +-
include/configs/{omap5_evm.h = omap5_uevm.h} |0
5 files changed, 1 insertion(+), 1 deletion(-)
rename board/ti/{omap5_evm = omap5_uevm}/Makefile (100%)
rename board/ti/{omap5_evm = omap5_uevm}/evm.c (100%)
rename board/ti/{omap5_evm = omap5_uevm}/mux_data.h (100%)
rename include/configs/{omap5_evm.h = omap5_uevm.h} (100%)
diff --git a/board/ti/omap5_evm/Makefile b/board/ti/omap5_uevm/Makefile
similarity index 100%
rename from board/ti/omap5_evm/Makefile
rename to board/ti/omap5_uevm/Makefile
diff --git a/board/ti/omap5_evm/evm.c b/board/ti/omap5_uevm/evm.c
similarity index 100%
rename from board/ti/omap5_evm/evm.c
rename to board/ti/omap5_uevm/evm.c
diff --git a/board/ti/omap5_evm/mux_data.h b/board/ti/omap5_uevm/mux_data.h
similarity index 100%
rename from board/ti/omap5_evm/mux_data.h
rename to board/ti/omap5_uevm/mux_data.h
diff --git a/boards.cfg b/boards.cfg
index ee68fdd..c9ad3ff 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -291,7 +291,7 @@ twister arm armv7
twister technex
nokia_rx51 arm armv7 rx51nokia
omap3
omap4_panda arm armv7 panda ti
omap4
omap4_sdp4430arm armv7 sdp4430 ti
omap4
-omap5_evmarm armv7 omap5_evm ti
omap5
+omap5_uevm arm armv7 omap5_uevm ti
omap5
dra7xx_evm arm armv7 dra7xx ti
omap5
s5p_goni arm armv7 goni
samsungs5pc1xx
smdkc100 arm armv7 smdkc100
samsungs5pc1xx
diff --git a/include/configs/omap5_evm.h b/include/configs/omap5_uevm.h
similarity index 100%
rename from include/configs/omap5_evm.h
rename to include/configs/omap5_uevm.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 V3 4/5] ARM: OMAP4/5: Change the default boot command to work with device tree
Now with kernel moving to all device tree, the default
boot command is changed to pass the device tree blob.
Also, adding the findfdt command to get the dt-blob
based on the board.
Thanks to Tom Rini tr...@ti.com for suggesting this.
Acked-by: Nishanth Menon n...@ti.com
Signed-off-by: Sricharan R r.sricha...@ti.com
Tested-by: Nishanth Menon n...@ti.com
---
[V2] Corrected the board file name for omap4 boards
in findfdt command
[V3] Changed fdtaddr as per Tom Rini's comments
include/configs/omap4_common.h | 13 +++--
include/configs/omap5_common.h | 11 +--
2 files changed, 20 insertions(+), 4 deletions(-)
diff --git a/include/configs/omap4_common.h b/include/configs/omap4_common.h
index 6ae6a0f..f34c130 100644
--- a/include/configs/omap4_common.h
+++ b/include/configs/omap4_common.h
@@ -138,6 +138,7 @@
*/
#define CONFIG_BOOTDELAY 3
+#define CONFIG_ENV_VARS_UBOOT_CONFIG
#define CONFIG_ENV_OVERWRITE
@@ -145,6 +146,7 @@
loadaddr=0x8200\0 \
console=ttyO2,115200n8\0 \
fdt_high=0x\0 \
+ fdtaddr=0x80f8\0 \
usbtty=cdc_acm\0 \
vram=16M\0 \
mmcdev=0\0 \
@@ -153,7 +155,9 @@
mmcargs=setenv bootargs console=${console} \
vram=${vram} \
root=${mmcroot} \
- rootfstype=${mmcrootfstype}\0 \
+ rootfstype=${mmcrootfstype}; \
+ run findfdt; \
+ fatload mmc ${mmcdev} ${fdtaddr} ${fdtfile}\0 \
loadbootscript=fatload mmc ${mmcdev} ${loadaddr} boot.scr\0 \
bootscript=echo Running bootscript from mmc${mmcdev} ...; \
source ${loadaddr}\0 \
@@ -163,7 +167,12 @@
loaduimage=fatload mmc ${mmcdev} ${loadaddr} uImage\0 \
mmcboot=echo Booting from mmc${mmcdev} ...; \
run mmcargs; \
- bootm ${loadaddr}\0 \
+ bootm ${loadaddr} - ${fdtaddr}\0 \
+ findfdt=\
+ if test $board_name = sdp4430; then \
+ setenv fdtfile omap4-sdp.dtb; fi; \
+ if test $board_name = panda; then \
+ setenv fdtfile omap4-panda-es.dtb; fi\0 \
#define CONFIG_BOOTCOMMAND \
mmc dev ${mmcdev}; if mmc rescan; then \
diff --git a/include/configs/omap5_common.h b/include/configs/omap5_common.h
index 6d7aa7b..bcbf9cc 100644
--- a/include/configs/omap5_common.h
+++ b/include/configs/omap5_common.h
@@ -137,6 +137,7 @@
*/
#define CONFIG_BOOTDELAY 3
+#define CONFIG_ENV_VARS_UBOOT_CONFIG
#define CONFIG_ENV_OVERWRITE
@@ -144,6 +145,7 @@
loadaddr=0x8200\0 \
console=ttyO2,115200n8\0 \
fdt_high=0x\0 \
+ fdtaddr=0x80f8\0 \
usbtty=cdc_acm\0 \
vram=16M\0 \
mmcdev=0\0 \
@@ -152,7 +154,9 @@
mmcargs=setenv bootargs console=${console} \
vram=${vram} \
root=${mmcroot} \
- rootfstype=${mmcrootfstype}\0 \
+ rootfstype=${mmcrootfstype}; \
+ run findfdt; \
+ fatload mmc ${mmcdev} ${fdtaddr} ${fdtfile}\0 \
loadbootscript=fatload mmc ${mmcdev} ${loadaddr} boot.scr\0 \
bootscript=echo Running bootscript from mmc${mmcdev} ...; \
source ${loadaddr}\0 \
@@ -162,7 +166,10 @@
loaduimage=fatload mmc ${mmcdev} ${loadaddr} uImage\0 \
mmcboot=echo Booting from mmc${mmcdev} ...; \
run mmcargs; \
- bootm ${loadaddr}\0 \
+ bootm ${loadaddr} - ${fdtaddr}\0 \
+ findfdt=\
+ if test $board_name = omap5_uevm; then \
+ setenv fdtfile omap5-uevm.dtb; fi;\0 \
#define CONFIG_BOOTCOMMAND \
mmc dev ${mmcdev}; if mmc rescan; then \
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V3 0/5] ARM: OMAP4/5: Add support to boot with device tree as default
With the kernel moving all towards device tree, this series
adds support to make the device tree boot as the default
for OMAP4/5 platforms.
Nishanth Menon (1):
omap5: Allow use of a plain text env file
Sricharan R (4):
ARM: OMAP5: Rename omap5_evm to omap5_uevm
ARM: OMAP5: Set fdt_high to enable booting with Device tree
ARM: OMAP4/5: Change the default boot command to work with device
tree
ARM: OMAP4/5: Make bootz as the default boot command
board/ti/{omap5_evm = omap5_uevm}/Makefile |0
board/ti/{omap5_evm = omap5_uevm}/evm.c |0
board/ti/{omap5_evm = omap5_uevm}/mux_data.h |0
boards.cfg|2 +-
include/configs/omap4_common.h| 17 ++
include/configs/omap5_common.h| 30 -
include/configs/{omap5_evm.h = omap5_uevm.h} |0
7 files changed, 38 insertions(+), 11 deletions(-)
rename board/ti/{omap5_evm = omap5_uevm}/Makefile (100%)
rename board/ti/{omap5_evm = omap5_uevm}/evm.c (100%)
rename board/ti/{omap5_evm = omap5_uevm}/mux_data.h (100%)
rename include/configs/{omap5_evm.h = omap5_uevm.h} (100%)
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V3 3/5] ARM: OMAP5: Allow use of a plain text env file
From: Nishanth Menon n...@ti.com
For production systems it is better to use script images since
they are protected by checksums and carry valuable information
like name and timestamp. Also, you can't validate the content
passed to env import.
But for development, it is easier to use the env import command and
plain text files instead of script-images.
Since both OMAP5evm/uevm boards are used primarily for development,
we allow U-Boot to load env var from a text file in case that an
boot.scr script-image is not present.
The variable uenvcmd (if existent) will be executed (using run) after
uEnv.txt was loaded. If uenvcmd doesn't exist the default boot sequence
will be started.
Inspired by commit: d70f54808dfa83b574e1239c3eccbcf3317343e1
(omap4: allow the use of a plain text env file instead boot scripts)
Signed-off-by: Sricharan R r.sricha...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
Tested-by: Sricharan R r.sricha...@ti.com
---
include/configs/omap5_common.h | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/include/configs/omap5_common.h b/include/configs/omap5_common.h
index f0416df..6d7aa7b 100644
--- a/include/configs/omap5_common.h
+++ b/include/configs/omap5_common.h
@@ -156,6 +156,9 @@
loadbootscript=fatload mmc ${mmcdev} ${loadaddr} boot.scr\0 \
bootscript=echo Running bootscript from mmc${mmcdev} ...; \
source ${loadaddr}\0 \
+ loadbootenv=fatload mmc ${mmcdev} ${loadaddr} uEnv.txt\0 \
+ importbootenv=echo Importing environment from mmc${mmcdev} ...; \
+ env import -t ${loadaddr} ${filesize}\0 \
loaduimage=fatload mmc ${mmcdev} ${loadaddr} uImage\0 \
mmcboot=echo Booting from mmc${mmcdev} ...; \
run mmcargs; \
@@ -166,9 +169,16 @@
if run loadbootscript; then \
run bootscript; \
else \
- if run loaduimage; then \
- run mmcboot; \
- fi; \
+ if run loadbootenv; then \
+ run importbootenv; \
+ fi; \
+ if test -n ${uenvcmd}; then \
+ echo Running uenvcmd ...; \
+ run uenvcmd; \
+ fi; \
+ fi; \
+ if run loaduimage; then \
+ run mmcboot; \
fi; \
fi
--
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/5] ARM: OMAP4/5: Add support to boot with device tree as default
With the kernel moving all towards device tree, this series
adds support to make the device tree boot as the default
for OMAP4/5 platforms.
Sricharan R (5):
ARM: OMAP5: Rename omap5_evm to omap5_uevm
ARM: OMAP5: Set fdt_high to enable booting with Device tree
ARM: OMAP5: Support loading environment variables from txt file
ARM: OMAP4/5: Change the default boot command to work with device
tree
ARM: OMAP4/5: Make bootz as the default boot command
board/ti/{omap5_evm = omap5_uevm}/Makefile |0
board/ti/{omap5_evm = omap5_uevm}/evm.c |0
board/ti/{omap5_evm = omap5_uevm}/mux_data.h |0
boards.cfg|2 +-
include/configs/omap4_common.h| 17 ++
include/configs/omap5_common.h| 30 -
include/configs/{omap5_evm.h = omap5_uevm.h} |0
7 files changed, 38 insertions(+), 11 deletions(-)
rename board/ti/{omap5_evm = omap5_uevm}/Makefile (100%)
rename board/ti/{omap5_evm = omap5_uevm}/evm.c (100%)
rename board/ti/{omap5_evm = omap5_uevm}/mux_data.h (100%)
rename include/configs/{omap5_evm.h = omap5_uevm.h} (100%)
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
