[U-Boot] [PATCH] arm, davinci: Fix setting of the SDRAM configuration register
da850_ddr_setup() expects the BOOTUNLOCK bit to be set in #define CONFIG_SYS_DA850_DDR2_SDBCR ... in include/configs/*.h If BOOTUNLOCK is not set in this define, several configuration bits will not be writeable and the code will not work. Since the BOOTUNLOCK and TIMUNLOCK bits are not configuration options but access control bits, this patch changes the code to work irrespective of the value of these bits in CONFIG_SYS_DA850_DDR2_SDBCR. Signed-off-by: Christian Riesch christian.rie...@omicron.at Cc: Heiko Schocher h...@denx.de Cc: Paulraj Sandeep s-paul...@ti.com --- This patch applies on top of these two patches: [PATCH v3 1/2] arm, davinci: Rename AM1808 lowlevel functions to DA850 [PATCH v3 2/2] arm, davinci: Remove the duplication of LPSC functions in da850_lowlevel.c Best regards, Christian arch/arm/cpu/arm926ejs/davinci/da850_lowlevel.c | 25 +- 1 files changed, 19 insertions(+), 6 deletions(-) diff --git a/arch/arm/cpu/arm926ejs/davinci/da850_lowlevel.c b/arch/arm/cpu/arm926ejs/davinci/da850_lowlevel.c index 490ef8f..6f72491 100644 --- a/arch/arm/cpu/arm926ejs/davinci/da850_lowlevel.c +++ b/arch/arm/cpu/arm926ejs/davinci/da850_lowlevel.c @@ -184,18 +184,31 @@ int da850_ddr_setup(unsigned int freq) clrbits_le32(davinci_syscfg1_regs-ddr_slew, (1 DDR_SLEW_CMOSEN_BIT)); + /* +* SDRAM Configuration Register (SDCR): +* First set the BOOTUNLOCK bit to make configuration bits +* writeable. +*/ setbits_le32(dv_ddr2_regs_ctrl-sdbcr, DV_DDR_BOOTUNLOCK); - writel((CONFIG_SYS_DA850_DDR2_SDBCR ~0xf000) | - (readl(dv_ddr2_regs_ctrl-sdbcr) 0xf000), /*rsv Bytes*/ - dv_ddr2_regs_ctrl-sdbcr); - writel(CONFIG_SYS_DA850_DDR2_SDBCR2, dv_ddr2_regs_ctrl-sdbcr2); + /* +* Write the new value of these bits and clear BOOTUNLOCK. +* At the same time, set the TIMUNLOCK bit to allow changing +* the timing registers +*/ + tmp = CONFIG_SYS_DA850_DDR2_SDBCR; + tmp = ~(0x1 DV_DDR_SDCR_BOOTUNLOCK_SHIFT); + tmp |= (0x1 DV_DDR_SDCR_TIMUNLOCK_SHIFT); + writel(tmp, dv_ddr2_regs_ctrl-sdbcr); + /* write memory configuration and timing */ + writel(CONFIG_SYS_DA850_DDR2_SDBCR2, dv_ddr2_regs_ctrl-sdbcr2); writel(CONFIG_SYS_DA850_DDR2_SDTIMR, dv_ddr2_regs_ctrl-sdtimr); writel(CONFIG_SYS_DA850_DDR2_SDTIMR2, dv_ddr2_regs_ctrl-sdtimr2); - clrbits_le32(dv_ddr2_regs_ctrl-sdbcr, - (1 DV_DDR_SDCR_TIMUNLOCK_SHIFT)); + /* clear the TIMUNLOCK bit and write the value of the CL field */ + tmp = ~(0x1 DV_DDR_SDCR_TIMUNLOCK_SHIFT); + writel(tmp, dv_ddr2_regs_ctrl-sdbcr); /* * LPMODEN and MCLKSTOPEN must be set! -- 1.7.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 10/12] OMAP3: Add SPL support to omap3_evm
On 11/08/11 00:03, Tom Rini wrote:
Add Hynix 200MHz timing information to asm/arch-omap3/mem.h. We
don't calculate the MCFG value here for the Micron parts as the provided
one assumes a memory size which is incorrect.
Signed-off-by: Tom Rini tr...@ti.com
---
arch/arm/include/asm/arch-omap3/mem.h | 38 +
board/ti/evm/config.mk| 33 --
board/ti/evm/evm.c| 42 ++-
include/configs/omap3_evm.h | 58
+++--
4 files changed, 133 insertions(+), 38 deletions(-)
delete mode 100644 board/ti/evm/config.mk
diff --git a/arch/arm/include/asm/arch-omap3/mem.h
b/arch/arm/include/asm/arch-omap3/mem.h
index f467ba9..7b0aaa1 100644
--- a/arch/arm/include/asm/arch-omap3/mem.h
+++ b/arch/arm/include/asm/arch-omap3/mem.h
@@ -60,6 +60,44 @@ enum {
#define SDP_SDRC_DLLAB_CTRL ((DLL_ENADLL 3) | \
(DLL_LOCKDLL 2) | (DLL_DLLPHASE_90 1))
+/* Hynix part of AM/DM37xEVM (200MHz optimized)
+ * ACTIMA
+ * TDAL= 6
+ * TDPL (Twr) = 3
+ * TRRD= 2
+ * TRCD= 4
+ * TRP = 3
+ * TRAS= 8
+ * TRC = 11
+ * TRFC= 18
+ * ACTIMB
+ * TWTR= 2
+ * TCKE= 1
+ * TXP = 1
+ * TXSR= 28
+ */
+#define HYNIX_TDAL_200 6
+#define HYNIX_TDPL_200 3
+#define HYNIX_TRRD_200 2
+#define HYNIX_TRCD_200 4
+#define HYNIX_TRP_2003
+#define HYNIX_TRAS_200 8
+#define HYNIX_TRC_20011
+#define HYNIX_TRFC_200 18
+#define HYNIX_V_ACTIMA_200 ((HYNIX_TRFC_200 27) | \
+ (HYNIX_TRC_200 22) | (HYNIX_TRAS_200 18) | \
+ (HYNIX_TRP_200 15) | (HYNIX_TRCD_200 12) | \
+ (HYNIX_TRRD_200 9) | (HYNIX_TDPL_200 6) | \
+ (HYNIX_TDAL_200))
+
+#define HYNIX_TWTR_200 2
+#define HYNIX_TCKE_200 1
+#define HYNIX_TXP_2001
+#define HYNIX_XSR_20028
+#define HYNIX_V_ACTIMB_200 (((HYNIX_TCKE_200 12) | \
+ (HYNIX_XSR_200 0)) | (HYNIX_TXP_200 8) | \
+ (HYNIX_TWTR_200 16))
+
/* Infineon part of 3430SDP (165MHz optimized) 6.06ns
* ACTIMA
* TDAL = Twr/Tck + Trp/tck = 15/6 + 18/6 = 2.5 + 3 = 5.5 - 6
diff --git a/board/ti/evm/config.mk b/board/ti/evm/config.mk
deleted file mode 100644
index d173eef..000
--- a/board/ti/evm/config.mk
+++ /dev/null
@@ -1,33 +0,0 @@
-#
-# (C) Copyright 2006 - 2008
-# Texas Instruments, www.ti.com
-#
-# EVM uses OMAP3 (ARM-CortexA8) cpu
-# see http://www.ti.com/ for more information on Texas Instruments
-#
-# See file CREDITS for list of people who contributed to this
-# project.
-#
-# This program is free software; you can redistribute it and/or
-# modify it under the terms of the GNU General Public License as
-# published by the Free Software Foundation; either version 2 of
-# the License, or (at your option) any later version.
-#
-# This program is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
-# GNU General Public License for more details.
-#
-# You should have received a copy of the GNU General Public License
-# along with this program; if not, write to the Free Software
-# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
-# MA 02111-1307 USA
-#
-# Physical Address:
-# 8000' (bank0)
-# A000/ (bank1)
-# Linux-Kernel is expected to be at 8000'8000, entry 8000'8000
-# (mem base + reserved)
-
-# For use with external or internal boots.
-CONFIG_SYS_TEXT_BASE = 0x80008000
Does not belong to this patch, is it?
diff --git a/board/ti/evm/evm.c b/board/ti/evm/evm.c
index b17c0fb..debf564 100644
--- a/board/ti/evm/evm.c
+++ b/board/ti/evm/evm.c
@@ -1,5 +1,5 @@
/*
- * (C) Copyright 2004-2008
+ * (C) Copyright 2004-2011
* Texas Instruments, www.ti.com
*
* Author :
@@ -119,6 +119,44 @@ int board_init(void)
return 0;
}
+#ifdef CONFIG_SPL_BUILD
+/*
+ * Routine: get_board_mem_timings
+ * Description: If we use SPL then there is no x-loader nor config header
+ * so we have to setup the DDR timings outself on the first bank. This
+ * provides the timing values back to the function that configures
+ * the memory.
+ */
+void get_board_mem_timings(u32 *mcfg, u32 *ctrla, u32 *ctrlb, u32 *rfr_ctrl,
+ u32 *mr)
+{
+ int pop_mfr, pop_id;
+
+ /*
+ * We need to identify what PoP memory is on the board so that
+ * we know what timings to use. If we can't identify it then
+ * we know it's an xM.
This comment should be slightly adjusted, evm is not beagle...
+ */
[U-Boot] [PATCH v3 0/2] Remove duplicate functions for power and sleep configuration
Hi,
these patches remove the duplicate functions for the power and sleep
controller of the davinci devices.
Since v2, these patches have only been rebased, therefore I kept
the Acked-bys by Heiko Schocher. v2 has been under review since mid of
October so I think they could be applied now. Thank you!
Changes for v3:
- rebased to apply on top of the ti branch (without any prerequisites)
- removed patch arm, davinci: Add function lpsc_syncreset() since
it was already merged.
Changes for v2:
- use -M option of git format-patch to detect the renaming of files
- Removed one patch of the patchset (arm, davinci: Correct the MDSTAT.STATE
mask) since a similar patch was already submitted by Sergei Shtylyov.
The prerequisites list below was updated accordingly.
- Use defines for bitmasks for PSC configuration instead of magic numbers.
The first patch renames the low level configuration functions since they can
not only be used for the AM1808 but for the entire da850 family.
The second patch replaces the PSC related functions in
arch/arm/cpu/arm926ejs/davinci/da850_lowlevel.c by those of psc.c.
Best Regards, Christian
Cc: Heiko Schocher h...@denx.de
Cc: Paulraj Sandeep s-paul...@ti.com
Cc: Albert ARIBAUD albert.u.b...@aribaud.net
Christian Riesch (2):
arm, davinci: Rename AM1808 lowlevel functions to DA850
arm, davinci: Remove the duplication of LPSC functions in
da850_lowlevel.c
arch/arm/cpu/arm926ejs/davinci/Makefile|2 +-
.../{am1808_lowlevel.c = da850_lowlevel.c}| 202 ++--
.../{am1808_lowlevel.h = da850_lowlevel.h}| 26 ++--
3 files changed, 71 insertions(+), 159 deletions(-)
rename arch/arm/cpu/arm926ejs/davinci/{am1808_lowlevel.c = da850_lowlevel.c}
(57%)
rename arch/arm/include/asm/arch-davinci/{am1808_lowlevel.h =
da850_lowlevel.h} (63%)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 2/2] arm, davinci: Remove the duplication of LPSC functions in da850_lowlevel.c
The LPSC functions defined in
arch/arm/cpu/arm926ejs/davinci/da850_lowlevel.c
are replaced by those already defined in
arch/arm/cpu/arm926ejs/davinci/psc.c.
Signed-off-by: Christian Riesch christian.rie...@omicron.at
Cc: Heiko Schocher h...@denx.de
Cc: Paulraj Sandeep s-paul...@ti.com
Cc: Albert ARIBAUD albert.u.b...@aribaud.net
Acked-by: Heiko Schocher h...@denx.de
---
arch/arm/cpu/arm926ejs/davinci/da850_lowlevel.c | 96 +--
1 files changed, 4 insertions(+), 92 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/davinci/da850_lowlevel.c
b/arch/arm/cpu/arm926ejs/davinci/da850_lowlevel.c
index a6f0178..490ef8f 100644
--- a/arch/arm/cpu/arm926ejs/davinci/da850_lowlevel.c
+++ b/arch/arm/cpu/arm926ejs/davinci/da850_lowlevel.c
@@ -153,49 +153,12 @@ int da850_pll_init(struct davinci_pllc_regs *reg,
unsigned long pllmult)
return 0;
}
-void da850_lpc_transition(unsigned char pscnum, unsigned char module,
- unsigned char domain, unsigned char state)
-{
- struct davinci_psc_regs *reg;
- dv_reg_p mdstat, mdctl;
-
- if (pscnum == 0) {
- reg = davinci_psc0_regs;
- mdstat = reg-psc0.mdstat[module];
- mdctl = reg-psc0.mdctl[module];
- } else {
- reg = davinci_psc1_regs;
- mdstat = reg-psc1.mdstat[module];
- mdctl = reg-psc1.mdctl[module];
- }
-
- /* Wait for any outstanding transition to complete */
- while ((readl(reg-ptstat) (0x0001 domain)))
- ;
-
- /* If we are already in that state, just return */
- if ((readl(mdstat) 0x1F) == state)
- return;
-
- /* Perform transition */
- writel((readl(mdctl) 0xFFE0) | state, mdctl);
- setbits_le32(reg-ptcmd, (0x0001 domain));
-
- /* Wait for transition to complete */
- while (readl(reg-ptstat) (0x0001 domain))
- ;
-
- /* Wait and verify the state */
- while ((readl(mdstat) 0x1F) != state)
- ;
-}
-
int da850_ddr_setup(unsigned int freq)
{
unsigned long tmp;
/* Enable the Clock to DDR2/mDDR */
- da850_lpc_transition(1, 6, 0, PSC_ENABLE);
+ lpsc_on(DAVINCI_LPSC_DDR_EMIF);
tmp = readl(davinci_syscfg1_regs-vtpio_ctl);
if ((tmp VTP_POWERDWN) == VTP_POWERDWN) {
@@ -244,9 +207,9 @@ int da850_ddr_setup(unsigned int freq)
dv_ddr2_regs_ctrl-sdrcr);
/* SyncReset the Clock to EMIF3A SDRAM */
- da850_lpc_transition(1, 6, 0, PSC_SYNCRESET);
+ lpsc_syncreset(DAVINCI_LPSC_DDR_EMIF);
/* Enable the Clock to EMIF3A SDRAM */
- da850_lpc_transition(1, 6, 0, PSC_ENABLE);
+ lpsc_on(DAVINCI_LPSC_DDR_EMIF);
/* disable self refresh */
clrbits_le32(dv_ddr2_regs_ctrl-sdrcr, 0xc000);
@@ -255,54 +218,6 @@ int da850_ddr_setup(unsigned int freq)
return 0;
}
-static void da850_set_mdctl(dv_reg_p mdctl)
-{
- if ((readl(mdctl) 0x1F) != PSC_ENABLE)
- writel(((readl(mdctl) 0xFFE0) | PSC_ENABLE), mdctl);
-}
-
-void da850_psc_init(void)
-{
- struct davinci_psc_regs *reg;
- int i;
-
- /* PSC 0 domain 0 init */
- reg = davinci_psc0_regs;
- while ((readl(reg-ptstat) 0x0001))
- ;
-
- for (i = 3; i = 4 ; i++)
- da850_set_mdctl(reg-psc0.mdctl[i]);
-
- for (i = 7; i = 12 ; i++)
- da850_set_mdctl(reg-psc0.mdctl[i]);
-
- /* Do Always-On Power Domain Transitions */
- setbits_le32(reg-ptcmd, 0x0001);
- while (readl(reg-ptstat) 0x0001)
- ;
-
- /* PSC1, domain 1 init */
- reg = davinci_psc1_regs;
- while ((readl(reg-ptstat) 0x0001))
- ;
-
- da850_set_mdctl(reg-psc1.mdctl[3]);
- da850_set_mdctl(reg-psc1.mdctl[6]);
-
- /* UART1 + UART2 */
- for (i = 12 ; i = 13 ; i++)
- da850_set_mdctl(reg-psc1.mdctl[i]);
-
- da850_set_mdctl(reg-psc1.mdctl[26]);
- da850_set_mdctl(reg-psc1.mdctl[31]);
-
- /* Do Always-On Power Domain Transitions */
- setbits_le32(reg-ptcmd, 0x0001);
- while (readl(reg-ptstat) 0x0001)
- ;
-}
-
void da850_pinmux_ctl(unsigned long offset, unsigned long mask,
unsigned long value)
{
@@ -368,9 +283,6 @@ int arch_cpu_init(void)
dv_maskbits(davinci_syscfg_regs-suspsrc,
((1 27) | (1 22) | (1 20) | (1 5) | (1 16)));
- /* System PSC setup - enable all */
- da850_psc_init();
-
/* Setup Pinmux */
da850_pinmux_ctl(0, 0x, CONFIG_SYS_DA850_PINMUX0);
da850_pinmux_ctl(1, 0x, CONFIG_SYS_DA850_PINMUX1);
@@ -404,7 +316,7 @@ int arch_cpu_init(void)
writel(CONFIG_SYS_DA850_CS2CFG, davinci_emif_regs-ab1cr);
writel(CONFIG_SYS_DA850_CS3CFG, davinci_emif_regs-ab2cr);
- da850_lpc_transition(1, 13, 0,
[U-Boot] [PATCH v3 1/2] arm, davinci: Rename AM1808 lowlevel functions to DA850
Rename arch/arm/cpu/arm926ejs/davinci/am1808_lowlevel.c and
arch/arm/include/asm/arch-davinci/am1808_lowlevel.h to da850_lowlevel.c
and da850_lowlevel.h since they apply not only to the AM1808 SoC
but to all DA850 chips. The function names and #defines are changed
likewise.
Signed-off-by: Christian Riesch christian.rie...@omicron.at
Cc: Heiko Schocher h...@denx.de
Cc: Paulraj Sandeep s-paul...@ti.com
Cc: Albert ARIBAUD albert.u.b...@aribaud.net
Acked-by: Heiko Schocher h...@denx.de
---
arch/arm/cpu/arm926ejs/davinci/Makefile|2 +-
.../{am1808_lowlevel.c = da850_lowlevel.c}| 136 ++--
.../{am1808_lowlevel.h = da850_lowlevel.h}| 26 ++--
3 files changed, 82 insertions(+), 82 deletions(-)
rename arch/arm/cpu/arm926ejs/davinci/{am1808_lowlevel.c = da850_lowlevel.c}
(70%)
rename arch/arm/include/asm/arch-davinci/{am1808_lowlevel.h =
da850_lowlevel.h} (63%)
diff --git a/arch/arm/cpu/arm926ejs/davinci/Makefile
b/arch/arm/cpu/arm926ejs/davinci/Makefile
index 98c7e55..aeb058a 100644
--- a/arch/arm/cpu/arm926ejs/davinci/Makefile
+++ b/arch/arm/cpu/arm926ejs/davinci/Makefile
@@ -28,7 +28,7 @@ include $(TOPDIR)/config.mk
LIB= $(obj)lib$(SOC).o
COBJS-y+= cpu.o timer.o psc.o
-COBJS-$(CONFIG_AM18018_LOWLEVEL) += am1808_lowlevel.o
+COBJS-$(CONFIG_DA850_LOWLEVEL) += da850_lowlevel.o
COBJS-$(CONFIG_SOC_DM355) += dm355.o
COBJS-$(CONFIG_SOC_DM365) += dm365.o
COBJS-$(CONFIG_SOC_DM644X) += dm644x.o
diff --git a/arch/arm/cpu/arm926ejs/davinci/am1808_lowlevel.c
b/arch/arm/cpu/arm926ejs/davinci/da850_lowlevel.c
similarity index 70%
rename from arch/arm/cpu/arm926ejs/davinci/am1808_lowlevel.c
rename to arch/arm/cpu/arm926ejs/davinci/da850_lowlevel.c
index 1ea4a9f..a6f0178 100644
--- a/arch/arm/cpu/arm926ejs/davinci/am1808_lowlevel.c
+++ b/arch/arm/cpu/arm926ejs/davinci/da850_lowlevel.c
@@ -1,5 +1,5 @@
/*
- * SoC-specific lowlevel code for AM1808 and similar chips
+ * SoC-specific lowlevel code for DA850
*
* Copyright (C) 2011
* Heiko Schocher, DENX Software Engineering, h...@denx.de.
@@ -25,12 +25,12 @@
#include nand.h
#include ns16550.h
#include post.h
-#include asm/arch/am1808_lowlevel.h
+#include asm/arch/da850_lowlevel.h
#include asm/arch/hardware.h
#include asm/arch/ddr2_defs.h
#include asm/arch/emif_defs.h
-void am1808_waitloop(unsigned long loopcnt)
+void da850_waitloop(unsigned long loopcnt)
{
unsigned long i;
@@ -38,7 +38,7 @@ void am1808_waitloop(unsigned long loopcnt)
asm( NOP);
}
-int am1808_pll_init(struct davinci_pllc_regs *reg, unsigned long pllmult)
+int da850_pll_init(struct davinci_pllc_regs *reg, unsigned long pllmult)
{
if (reg == davinci_pllc0_regs)
/* Unlock PLL registers. */
@@ -55,7 +55,7 @@ int am1808_pll_init(struct davinci_pllc_regs *reg, unsigned
long pllmult)
/* Set PLLEN=0 = PLL BYPASS MODE */
clrbits_le32(reg-pllctl, 0x0001);
- am1808_waitloop(150);
+ da850_waitloop(150);
if (reg == davinci_pllc0_regs) {
/*
@@ -87,10 +87,10 @@ int am1808_pll_init(struct davinci_pllc_regs *reg, unsigned
long pllmult)
/* program the postdiv */
if (reg == davinci_pllc0_regs)
- writel((0x8000 | CONFIG_SYS_AM1808_PLL0_POSTDIV),
+ writel((0x8000 | CONFIG_SYS_DA850_PLL0_POSTDIV),
reg-postdiv);
else
- writel((0x8000 | CONFIG_SYS_AM1808_PLL1_POSTDIV),
+ writel((0x8000 | CONFIG_SYS_DA850_PLL1_POSTDIV),
reg-postdiv);
/*
@@ -101,17 +101,17 @@ int am1808_pll_init(struct davinci_pllc_regs *reg,
unsigned long pllmult)
;
if (reg == davinci_pllc0_regs) {
- writel(CONFIG_SYS_AM1808_PLL0_PLLDIV1, reg-plldiv1);
- writel(CONFIG_SYS_AM1808_PLL0_PLLDIV2, reg-plldiv2);
- writel(CONFIG_SYS_AM1808_PLL0_PLLDIV3, reg-plldiv3);
- writel(CONFIG_SYS_AM1808_PLL0_PLLDIV4, reg-plldiv4);
- writel(CONFIG_SYS_AM1808_PLL0_PLLDIV5, reg-plldiv5);
- writel(CONFIG_SYS_AM1808_PLL0_PLLDIV6, reg-plldiv6);
- writel(CONFIG_SYS_AM1808_PLL0_PLLDIV7, reg-plldiv7);
+ writel(CONFIG_SYS_DA850_PLL0_PLLDIV1, reg-plldiv1);
+ writel(CONFIG_SYS_DA850_PLL0_PLLDIV2, reg-plldiv2);
+ writel(CONFIG_SYS_DA850_PLL0_PLLDIV3, reg-plldiv3);
+ writel(CONFIG_SYS_DA850_PLL0_PLLDIV4, reg-plldiv4);
+ writel(CONFIG_SYS_DA850_PLL0_PLLDIV5, reg-plldiv5);
+ writel(CONFIG_SYS_DA850_PLL0_PLLDIV6, reg-plldiv6);
+ writel(CONFIG_SYS_DA850_PLL0_PLLDIV7, reg-plldiv7);
} else {
- writel(CONFIG_SYS_AM1808_PLL1_PLLDIV1, reg-plldiv1);
- writel(CONFIG_SYS_AM1808_PLL1_PLLDIV2, reg-plldiv2);
- writel(CONFIG_SYS_AM1808_PLL1_PLLDIV3, reg-plldiv3);
+
Re: [U-Boot] [PATCH 2/3 RESEND] devkit3250: add Timll DevKit3250 board initial support
Hi Vladimir,
On 11/07/11 23:58, Vladimir Zapolskiy wrote:
This change adds a basic support for Embest/Timll DevKit3250 board,
NOR and UART are the only supported peripherals for a moment. The board
doesn't require low-level init, because the initial SDRAM and GPIO
configuration is performed during kickstart bootloader execution.
Signed-off-by: Vladimir Zapolskiy v...@mleia.com
---
board/timll/devkit3250/Makefile | 50 ++
board/timll/devkit3250/devkit3250.c | 74 +
boards.cfg |3 +-
include/configs/devkit3250.h| 121
+++
4 files changed, 247 insertions(+), 1 deletions(-)
create mode 100644 board/timll/devkit3250/Makefile
create mode 100644 board/timll/devkit3250/devkit3250.c
create mode 100644 include/configs/devkit3250.h
diff --git a/board/timll/devkit3250/Makefile b/board/timll/devkit3250/Makefile
new file mode 100644
index 000..99cb16f
--- /dev/null
+++ b/board/timll/devkit3250/Makefile
@@ -0,0 +1,50 @@
+#
+# Copyright (C) 2011 by Vladimir Zapolskiy v...@mleia.com
+# Copyright (C) 2008, Guennadi Liakhovetski l...@denx.de
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+# MA 02111-1307 USA
Probably, it will be a good thing to drop the address part globally,
as it can change and you may not be around to look for your
files to change it.
+#
+
+include $(TOPDIR)/config.mk
+
+LIB = $(obj)lib$(BOARD).o
+
+COBJS:= devkit3250.o
+
+SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
+OBJS := $(addprefix $(obj),$(COBJS))
+SOBJS:= $(addprefix $(obj),$(SOBJS))
+
+$(LIB): $(obj).depend $(OBJS) $(SOBJS)
+ $(call cmd_link_o_target, $(OBJS) $(SOBJS))
+
+clean:
+ rm -f $(SOBJS) $(OBJS)
+
+distclean: clean
+ rm -f $(LIB) core *.bak .depend
clean and distclean have no use in this directory level
and have been removed all over by Mike,
so please don't add any new ones.
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/timll/devkit3250/devkit3250.c
b/board/timll/devkit3250/devkit3250.c
new file mode 100644
index 000..b2f7863
--- /dev/null
+++ b/board/timll/devkit3250/devkit3250.c
@@ -0,0 +1,74 @@
+/*
+ * Embest/Timll DevKit3250 board support
+ *
+ * Copyright (C) 2011 Vladimir Zapolskiy v...@mleia.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
+ * MA 02110-1301, USA.
+ */
+
+#include common.h
+#include asm/arch/sys_proto.h
+#include asm/arch/cpu.h
+#include asm/arch/emc.h
+
+DECLARE_GLOBAL_DATA_PTR;
+
+static struct emc_t *emc = (struct emc_t *)EMC_BASE;
+
+int board_early_init_f(void)
+{
+ lpc32xx_uart_init(CONFIG_SYS_LPC32XX_UART);
+
+ return 0;
+}
+
+int board_init(void)
+{
+ /*
+ * It might be necessary to flush data cache, if U-boot is loaded
+ * from kickstart bootloader, e.g. from S1L loader
+ */
+ flush_cache(0, 0);
+
+ /* set machine id of Embest DevKit3250 */
+ gd-bd-bi_arch_number = MACH_TYPE_DEVKIT3250;
You already setup the CONFIG_MACH_TYPE.
The above line should be removed (along with the comment).
+
+ /* adress of boot parameters */
+ gd-bd-bi_boot_params = CONFIG_ENV_ADDR;
+
+#ifdef CONFIG_SYS_FLASH_CFI
+ /* Use 16-bit memory interface for NOR Flash */
+ emc-stat[0].config =
Re: [U-Boot] [PATCH 1/2] ARM: re-add MACH_TYPE_XXXXXX for VCMA9 board and add CONFIG_MACH_TYPE
Hi David, Le 31/10/2011 12:22, David Müller a écrit : Signed-off-by: David Muellerd.muel...@elsoft.ch --- include/configs/VCMA9.h |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/include/configs/VCMA9.h b/include/configs/VCMA9.h index 8b8113d..a370c15 100644 --- a/include/configs/VCMA9.h +++ b/include/configs/VCMA9.h @@ -29,6 +29,9 @@ #ifndef __CONFIG_H #define __CONFIG_H + +#define MACH_TYPE_MPL_VCMA9 227 + /* * High Level Configuration Options * (easy to change) @@ -37,6 +40,7 @@ #define CONFIG_S3C24X0 /* in a SAMSUNG S3C24x0-type SoC */ #define CONFIG_S3C2410 /* specifically a SAMSUNG S3C2410 SoC */ #define CONFIG_VCMA9/* on a MPL VCMA9 Board */ +#define CONFIG_MACH_TYPE MACH_TYPE_MPL_VCMA9 /* Machine type */ #define CONFIG_SYS_TEXT_BASE0x0 Applied to u-boot-arm/master, thanks! Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] fatload accepting wildcard in filename?
Hi, I came across this page http://boundarydevices.com/upgradeU.php where the linked Xenon upgrade package contains a script that does if fatload mmc 0 80008000 u-boot-xenon*.bin ; then ... Their release is from a few years back (2008-06-11); the same fatload + wildcard construct doesn't work with 2011.03. I'm trying to find out how this was implemented, and if it was ever part of mainline or if it was a local hack. (I couldn't find it in the ml archives.) Thanks, Orjan -- Orjan Friberg FlatFrog Laboratories AB ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] netspace_v2: Read Ethernet MAC address from EEPROM
-Original Message- From: Simon Guinot [mailto:si...@sequanux.org] Sent: Saturday, November 05, 2011 6:00 PM To: Prafulla Wadaskar Cc: u-boot@lists.denx.de; Simon Guinot Subject: Re: [U-Boot] [PATCH 3/3] netspace_v2: Read Ethernet MAC address from EEPROM Hi Prafulla, On Mon, Oct 31, 2011 at 02:58:36PM +0100, Simon Guinot wrote: From: Simon Guinot simon.gui...@sequanux.org Signed-off-by: Simon Guinot simon.gui...@sequanux.org --- board/LaCie/netspace_v2/netspace_v2.c | 43 + include/configs/netspace_v2.h |1 + 2 files changed, 44 insertions(+), 0 deletions(-) delete mode 100644 arch/arm/cpu/arm926ejs/kirkwood/asm- offsets.s Do you want me to repost this patch with some modifications ? Since asm-offsets.s is already removed Please resend the patch with re-syncing with u-boot-marvell.git Regards.. Prafulla . . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/3] image: Allow images to indicate they're loadable at any address
Dear Nicolas, may I suggest that you please try to relax for a moment, and try to look at things from a completely unprejudiced point of view? We will come back to your arguments later, promised. In message alpine.lfd.2.02.071840080.3...@xanadu.home you wrote: I understand you are referring here to zImages only. Correct? Correct. Anything else is not relocatable. Or will raw images (without the preloader) be fully relocatable, too? No. OK. So the situation on ARM is basicly not different from what we have on other architectures. The uImage format has been designed to handle this situation: we normally wrap the raw image (eventually after compressing it) into an uImage, and insert the load and entry point addresses that are well known at kernel build time. uImages are not directly executable. zImages on ARM include a preloader, that wraps the the raw image (eventually after compressing it) and packs it together with some code that internally accounts for the fixed load and entry point addresses of the kernel which implements the needed relocation and uncompression routines to form a new executable, position independent format. In both cases the _kernel_ image is not position independent. It must be loaded to a specific address and started at a specific entry point. The exact information where these are is known at built time, and somehow encoded in the images (here in the image header, there in the preloader code). Is this summary correct so far? Why is it so important to load it at specific (different) addresses when it can be started from any address? The kernel code can be started from any address. We want the _code_ to be that way. This is not quite correct. The _kernel_ code has a fixed address. It is the preloader code which can be started from any address. However a particular board may or may not load the kernel at any address. This is a machine specific restriction, not a kernel restriction. Correct. Stephen Warren also writes in 4eb87122.3050...@nvidia.com: Presumably whoever constructed the environment has the most detailed knowledge of the HW's and U-Boot environment's expected memory layout for that particular board. And in 4eb87375.1040...@nvidia.com: The only place that has full knowledge of the board's memory layout is the U-Boot environment for that board, and hence I assert that the U-Boot environment should define where to load the kernel (and initrd and FDT), and if U-Boot must copy them, where to copy them to. In particular, the creator of the uImage can't possibly pick these values and expect them to work everywhere. I mostly agree with this. That's the reason why U-Boot offers to handle this based on a better understanding of the low level hardware details. This seems to me to be an easier way that to handle this in the Linux kernel environment (in the form of the preloader). Maybe this is a key point. I simply fail to understand this. Let me repeat again. We want one single kernel image binary that ARM distributions can use for all their target machines. It is therefore necessary that uImage be free of any hardcoded load address (absolute or relative). If a particular board require a particular load address for the kernel, this must be encoded in its own u-Boot environment and not in the distributed uImage. Failing that, uImage simply cannot be used as a distribution format for the kernel because any address/offset enforced by the uImage format is going to be incompatible with the needs of a particular machine somewhere. uImage is _intented_ to carry a raw OS image and provide the boot loader the information where to load and start it. You do not want to do that, so you should not attempt to assault uImages to make it fit your completely different purposes. If you want to use relocatable zImages which have all the needed information encoded internally then just do so. But do not insist that uImage does things it was not designed for. No. The requirements on raw images are unchanged. you can use them if you wish, but generic ARM distributions can't use that if they want to target more than one SOC. Therefore raw images are not interesting by the use case at hand. They are not interesting for you. But that does not mean that they are not interesting in general. Simon Glass brings up this point, too, in CAPnjgZ1WajMLznSDNDLBys-C3Um2rVvZjOLk3BfSO2M=frw...@mail.gmail.com: | Can I assume that we have (or can have) a 'make uImage' target or | similar in the kernel which can pack together: | | - a compressed kernel (not zImage, I mean something that U-Boot can | decompress), with a rel_offset of 32KB | - a DTB | - a ramdisk | | and that with Stephen's patch (committed to U-Boot) today, we can, in | U-Boot, with a script, load this uImage to somewhere and have U-Boot | decompress the kernel and set the bits out nicely in RAM, no matter | where that RAM is? The kernel will start at 32KB,
Re: [U-Boot] [PATCH v2 3/3] image: Allow images to indicate they're loadable at any address
Dear Nicolas Pitre, In message alpine.lfd.2.02.071942150.3...@xanadu.home you wrote: But as you said yourself, the (raw) kernel is not relocatable. It gets loaded and started at pre-defined (at image build time) addresses. Only the kernel wrapper adds the complexity you are complaining about. Drop it, then. Many of us insist on preserving that complexity. From our point of view, it is u-Boot which is too complex and should drop its uImage complexity. Insisting without giving explanations about the reasons is not exactly a constructive form of a discussion. Actually it is no discussion at all. But instead of asking you to drop u-Boot's complexity, I'm only asking for u-Boot to let both methods to coexist and work. Ok, we can make a deal on such a base. See the suggestion inmy previous message. Given that the zImage complexity is not going away because we insist on keeping it, either we find a middle ground such as Stephen's patches, or we advocate for a different bootloader on ARM. Do you never happend to compromize once in a while? In my understanding, compromize is not a one-sided business. It is actually easy to convince me, but it needs facts and arguments, not mere insisting on preconceived statements or plain extortion. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The shortest unit of time in the multiverse is the News York Second, defined as the period of time between the traffic lights turning green and the cab behind you honking. - Terry Pratchett, _Lords and Ladies_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC PATCH] arm, davinci: Remove board specific code from da850_lowlevel.c
Signed-off-by: Christian Riesch christian.rie...@omicron.at
---
Hello Heiko,
On my board I cannot use your code in arch_cpu_init() in da850_lowlevel.c
since I have different versions of my board with different input
clock frequencies. Here u-boot should first determine the board
revision number and then configure the SoC accordingly. Therefore I would
like to move all board-specific parts (and PLL and memory configuration is
board-specific since it depends on the memory chips and oscillators
deployed on the board) to board_early_init_f which is called right after
arch_cpu_init() and keep only a few initializiation steps in arch_cpu_init().
This patch applies on top of
[U-Boot,v3,1/2] arm, davinci: Rename AM1808 lowlevel functions to DA850
http://patchwork.ozlabs.org/patch/124291/
[U-Boot,v3,2/2] arm, davinci: Remove the duplication of LPSC functions in
da850_lowlevel.c
http://patchwork.ozlabs.org/patch/124290/
[U-Boot] arm, davinci: Fix setting of the SDRAM configuration register
http://patchwork.ozlabs.org/patch/124289/
Thank you for your comments!
Best regards, Christian
arch/arm/cpu/arm926ejs/davinci/da850_lowlevel.c | 71 ---
1 files changed, 0 insertions(+), 71 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/davinci/da850_lowlevel.c
b/arch/arm/cpu/arm926ejs/davinci/da850_lowlevel.c
index 6f72491..04dfa34 100644
--- a/arch/arm/cpu/arm926ejs/davinci/da850_lowlevel.c
+++ b/arch/arm/cpu/arm926ejs/davinci/da850_lowlevel.c
@@ -23,7 +23,6 @@
*/
#include common.h
#include nand.h
-#include ns16550.h
#include post.h
#include asm/arch/da850_lowlevel.h
#include asm/arch/hardware.h
@@ -231,19 +230,6 @@ int da850_ddr_setup(unsigned int freq)
return 0;
}
-void da850_pinmux_ctl(unsigned long offset, unsigned long mask,
- unsigned long value)
-{
- clrbits_le32(davinci_syscfg_regs-pinmux[offset], mask);
- setbits_le32(davinci_syscfg_regs-pinmux[offset], (mask value));
-}
-
-__attribute__((weak))
-void board_gpio_init(void)
-{
- return;
-}
-
#if defined(CONFIG_NAND_SPL)
void nand_boot(void)
{
@@ -260,11 +246,7 @@ void nand_boot(void)
}
#endif
-#if defined(CONFIG_NAND_SPL)
-void board_init_f(ulong bootflag)
-#else
int arch_cpu_init(void)
-#endif
{
/*
* copied from arch/arm/cpu/arm926ejs/start.S
@@ -296,58 +278,5 @@ int arch_cpu_init(void)
dv_maskbits(davinci_syscfg_regs-suspsrc,
((1 27) | (1 22) | (1 20) | (1 5) | (1 16)));
- /* Setup Pinmux */
- da850_pinmux_ctl(0, 0x, CONFIG_SYS_DA850_PINMUX0);
- da850_pinmux_ctl(1, 0x, CONFIG_SYS_DA850_PINMUX1);
- da850_pinmux_ctl(2, 0x, CONFIG_SYS_DA850_PINMUX2);
- da850_pinmux_ctl(3, 0x, CONFIG_SYS_DA850_PINMUX3);
- da850_pinmux_ctl(4, 0x, CONFIG_SYS_DA850_PINMUX4);
- da850_pinmux_ctl(5, 0x, CONFIG_SYS_DA850_PINMUX5);
- da850_pinmux_ctl(6, 0x, CONFIG_SYS_DA850_PINMUX6);
- da850_pinmux_ctl(7, 0x, CONFIG_SYS_DA850_PINMUX7);
- da850_pinmux_ctl(8, 0x, CONFIG_SYS_DA850_PINMUX8);
- da850_pinmux_ctl(9, 0x, CONFIG_SYS_DA850_PINMUX9);
- da850_pinmux_ctl(10, 0x, CONFIG_SYS_DA850_PINMUX10);
- da850_pinmux_ctl(11, 0x, CONFIG_SYS_DA850_PINMUX11);
- da850_pinmux_ctl(12, 0x, CONFIG_SYS_DA850_PINMUX12);
- da850_pinmux_ctl(13, 0x, CONFIG_SYS_DA850_PINMUX13);
- da850_pinmux_ctl(14, 0x, CONFIG_SYS_DA850_PINMUX14);
- da850_pinmux_ctl(15, 0x, CONFIG_SYS_DA850_PINMUX15);
- da850_pinmux_ctl(16, 0x, CONFIG_SYS_DA850_PINMUX16);
- da850_pinmux_ctl(17, 0x, CONFIG_SYS_DA850_PINMUX17);
- da850_pinmux_ctl(18, 0x, CONFIG_SYS_DA850_PINMUX18);
- da850_pinmux_ctl(19, 0x, CONFIG_SYS_DA850_PINMUX19);
-
- /* PLL setup */
- da850_pll_init(davinci_pllc0_regs, CONFIG_SYS_DA850_PLL0_PLLM);
- da850_pll_init(davinci_pllc1_regs, CONFIG_SYS_DA850_PLL1_PLLM);
-
- /* GPIO setup */
- board_gpio_init();
-
- /* setup CSn config */
- writel(CONFIG_SYS_DA850_CS2CFG, davinci_emif_regs-ab1cr);
- writel(CONFIG_SYS_DA850_CS3CFG, davinci_emif_regs-ab2cr);
-
- lpsc_on(DAVINCI_LPSC_UART2);
- NS16550_init((NS16550_t)(CONFIG_SYS_NS16550_COM1),
- CONFIG_SYS_NS16550_CLK / 16 / CONFIG_BAUDRATE);
-
- /*
-* Fix Power and Emulation Management Register
-* see sprufw3a.pdf page 37 Table 24
-*/
- writel(readl((CONFIG_SYS_NS16550_COM1 + 0x30)) | 0x6001,
- (CONFIG_SYS_NS16550_COM1 + 0x30));
-#if defined(CONFIG_NAND_SPL)
- puts(ddr init\n);
- da850_ddr_setup(132);
-
- puts(boot u-boot ...\n);
-
- nand_boot();
-#else
- da850_ddr_setup(132);
return 0;
-#endif
}
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
Re: [U-Boot] [PATCH v2 3/3] image: Allow images to indicate they're loadable at any address
Dear Simon Glass, In message CAPnjgZ2aRP5Hn-3jREa=ofgs0k7ny9b2mwp3pwpbrw5svl3...@mail.gmail.com you wrote: Firstly, there is not just u-Boot out there. And since the layout optimization for Linux when decompressing is by definition Linux specific, this better live in zImage than be duplicated in every bootloaders. Actually I was talking about the case where U-Boot does the decompression. You have said it is supported above. I don't suggest that it be the only option, only that it be an option. Perhaps only U-Boot will use it, but that is fine. U-Boot is a popular boot loader. Thanks a lot for bringing up these arguments. If the boot loader puts the pieces in the right place, decompressed and ready to go, we could presumably avoid this code in the kernel: 1096 4860 27129 arch/arm/boot/compressed/head.S 1353 304 arch/arm/boot/compressed/big-endian.S 50 153 1267 arch/arm/boot/compressed/decompress.c 1096 4860 27129 arch/arm/boot/compressed/head.S 47 214 1238 arch/arm/boot/compressed/head-sa1100.S 139 650 3537 arch/arm/boot/compressed/head-shark.S 150 619 3564 arch/arm/boot/compressed/head-sharpsl.S 53 263 1685 arch/arm/boot/compressed/head-shmobile.S 41 179 992 arch/arm/boot/compressed/head-xscale.S 134 571 2868 arch/arm/boot/compressed/ll_char_wr.S 124 324 3011 arch/arm/boot/compressed/Makefile 208 589 3812 arch/arm/boot/compressed/misc.c 260 604 5289 arch/arm/boot/compressed/ofw-shark.c 610 145 arch/arm/boot/compressed/piggy.gzip.S 610 145 arch/arm/boot/compressed/piggy.lzma.S 610 144 arch/arm/boot/compressed/piggy.lzo.S 70 226 1481 arch/arm/boot/compressed/vmlinux.lds.in 2403 9335 56611 total I think you can even add the actual (de-) compressor routines. That gives the kernel what it wants. How can we give U-Boot what it wants, which is apparently the ability to decompress the kernel itself and arrange everything in memory at the right place? Wolfgang complains that patches to do this have been repeatedly rejected in the kernel. If this is the FIT image, how about adding a 'fitImage' make target? It would not only be FIT images. Why not support old uImage format in a proper way? In most cases people do not need the features provided by FIT images, and they prefer the simplicity of uImages. Thanks again. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Crash programs fail because they are based on the theory that, with nine women pregnant, you can get a baby a month. - Wernher von Braun ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] fatload accepting wildcard in filename?
Dear Orjan Friberg, In message 4eb8e510.6090...@flatfrog.com you wrote: I came across this page http://boundarydevices.com/upgradeU.php where the linked Xenon upgrade package contains a script that does if fatload mmc 0 80008000 u-boot-xenon*.bin ; then ... Their release is from a few years back (2008-06-11); the same fatload + wildcard construct doesn't work with 2011.03. I'm trying to find out how this was implemented, and if it was ever part of mainline or if it was a local hack. (I couldn't find it in the ml archives.) This has never been supported in mainline code. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Question: How does one get fresh air into a Russian church? Answer: One clicks on an icon, and a window opens! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: define CONFIG_MACH_TYPE for all ronetix boards
Hi Asen, Le 31/10/2011 19:54, Asen Chavdarov Dimov a écrit : Signed-off-by: Asen Chavdarov Dimovdi...@ronetix.at --- board/ronetix/pm9261/pm9261.c |3 --- board/ronetix/pm9263/pm9263.c |3 --- board/ronetix/pm9g45/pm9g45.c |2 -- include/configs/pm9261.h |3 +++ include/configs/pm9263.h |3 +++ include/configs/pm9g45.h |3 +++ 6 files changed, 9 insertions(+), 8 deletions(-) diff --git a/board/ronetix/pm9261/pm9261.c b/board/ronetix/pm9261/pm9261.c index 871b94a..b26e33a 100644 --- a/board/ronetix/pm9261/pm9261.c +++ b/board/ronetix/pm9261/pm9261.c @@ -248,9 +248,6 @@ int board_init(void) 1 ATMEL_ID_PIOC, pmc-pcer); - /* arch number of PM9261-Board */ - gd-bd-bi_arch_number = MACH_TYPE_PM9261; - /* adress of boot parameters */ gd-bd-bi_boot_params = PHYS_SDRAM + 0x100; diff --git a/board/ronetix/pm9263/pm9263.c b/board/ronetix/pm9263/pm9263.c index cfc9847..b0f7ea6 100644 --- a/board/ronetix/pm9263/pm9263.c +++ b/board/ronetix/pm9263/pm9263.c @@ -349,9 +349,6 @@ int board_init(void) (1 ATMEL_ID_PIOB), pmc-pcer); - /* arch number of AT91SAM9263EK-Board */ - gd-bd-bi_arch_number = MACH_TYPE_PM9263; - /* adress of boot parameters */ gd-bd-bi_boot_params = PHYS_SDRAM + 0x100; diff --git a/board/ronetix/pm9g45/pm9g45.c b/board/ronetix/pm9g45/pm9g45.c index f3374a4..961d193 100644 --- a/board/ronetix/pm9g45/pm9g45.c +++ b/board/ronetix/pm9g45/pm9g45.c @@ -139,8 +139,6 @@ int board_init(void) (1 ATMEL_ID_PIOC) | (1 ATMEL_ID_PIODE),pmc-pcer); - /* arch number of AT91SAM9M10G45EK-Board */ - gd-bd-bi_arch_number = MACH_TYPE_PM9G45; /* adress of boot parameters */ gd-bd-bi_boot_params = PHYS_SDRAM + 0x100; diff --git a/include/configs/pm9261.h b/include/configs/pm9261.h index 89e17b8..55455e7 100644 --- a/include/configs/pm9261.h +++ b/include/configs/pm9261.h @@ -52,6 +52,9 @@ #undef CONFIG_USE_IRQ /* we don't need IRQ/FIQ stuff */ #define CONFIG_SYS_TEXT_BASE0 +#define MACH_TYPE_PM9261 1187 +#define CONFIG_MACH_TYPE MACH_TYPE_PM9261 + /* clocks */ /* CKGR_MOR - enable main osc. */ #define CONFIG_SYS_MOR_VAL \ diff --git a/include/configs/pm9263.h b/include/configs/pm9263.h index 1f7543c..43104a3 100644 --- a/include/configs/pm9263.h +++ b/include/configs/pm9263.h @@ -52,6 +52,9 @@ #undef CONFIG_USE_IRQ /* we don't need IRQ/FIQ stuff */ #define CONFIG_SYS_TEXT_BASE0 +#define MACH_TYPE_PM9263 1475 +#define CONFIG_MACH_TYPE MACH_TYPE_PM9263 + /* clocks */ #define CONFIG_SYS_MOR_VAL \ (AT91_PMC_MOR_MOSCEN | \ diff --git a/include/configs/pm9g45.h b/include/configs/pm9g45.h index acc1204..d3beaf3 100644 --- a/include/configs/pm9g45.h +++ b/include/configs/pm9g45.h @@ -41,6 +41,9 @@ #define CONFIG_PM9G45 1 /* It's an Ronetix PM9G45 */ #define CONFIG_SYS_AT91_CPU_NAMEAT91SAM9G45 +#define MACH_TYPE_PM9G45 2672 +#define CONFIG_MACH_TYPE MACH_TYPE_PM9G45 + /* ARM asynchronous clock */ #define CONFIG_SYS_AT91_MAIN_CLOCK 1200 /* from 12 MHz crystal */ #define CONFIG_SYS_AT91_SLOW_CLOCK 32768 /* slow clock xtal */ Applied to u-boot-arm/master, thanks! Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] [driver][cfb] Make the software cursor non-destructive
When printing the string \r\n to the framebuffer console, the first
character of the current line was being replaced with a space. The boot
prompt would become the oot prompt. This change makes the cursor
non-destructive so that no matter where it goes on its way to where it's
supposed to be, the end result is that the cursor is where it's supposed to
be with the other text preserved intact.
Signed-off-by: Gabe Black gabebl...@chromium.org
---
drivers/video/cfb_console.c | 92 ++-
1 files changed, 47 insertions(+), 45 deletions(-)
diff --git a/drivers/video/cfb_console.c b/drivers/video/cfb_console.c
index 561883a..06de04e 100644
--- a/drivers/video/cfb_console.c
+++ b/drivers/video/cfb_console.c
@@ -221,8 +221,7 @@
/*
* Cursor definition:
* CONFIG_CONSOLE_CURSOR: Uses a timer function (see drivers/input/i8042.c)
- *to let the cursor blink. Uses the macros
- *CURSOR_OFF and CURSOR_ON.
+ *to let the cursor blink.
* CONFIG_VIDEO_SW_CURSOR: Draws a cursor after the last character. No
*blinking is provided. Uses the macros CURSOR_SET
*and CURSOR_OFF.
@@ -248,9 +247,9 @@
#endif
void console_cursor(int state);
-#define CURSOR_ON console_cursor(1)
+#define CURSOR_ON console_cursor(1)
#define CURSOR_OFF console_cursor(0)
-#define CURSOR_SET
+#define CURSOR_SET video_set_cursor()
#ifndef CONFIG_I8042_KBD
#warning Cursor drawing on/off needs timer function s.a. drivers/input/i8042.c
#endif
@@ -265,9 +264,9 @@ void console_cursor(int state);
#error only one of CONFIG_CONSOLE_CURSOR, CONFIG_VIDEO_SW_CURSOR, \
or CONFIG_VIDEO_HW_CURSOR can be defined
#endif
-#define CURSOR_ON
-#define CURSOR_OFF video_putchar(console_col * VIDEO_FONT_WIDTH,\
-console_row * VIDEO_FONT_HEIGHT, ' ')
+void console_cursor (int state);
+#define CURSOR_ON console_cursor(1)
+#define CURSOR_OFF console_cursor(0)
#define CURSOR_SET video_set_cursor()
#endif /* CONFIG_VIDEO_SW_CURSOR */
@@ -374,6 +373,10 @@ static void *video_console_address;/* console
buffer start address */
static int video_logo_height = VIDEO_LOGO_HEIGHT;
+static int cursor_state = 0;
+static int old_col = 0;
+static int old_row = 0;
+
static int console_col;/* cursor col */
static int console_row;/* cursor row */
@@ -433,6 +436,22 @@ static const int video_font_draw_table32[16][4] = {
};
+static void video_invertchar (int xx, int yy)
+{
+ int firstx = xx * VIDEO_PIXEL_SIZE;
+ int lastx = (xx + VIDEO_FONT_WIDTH) * VIDEO_PIXEL_SIZE;
+ int firsty = yy * VIDEO_LINE_LEN;
+ int lasty = (yy + VIDEO_FONT_HEIGHT) * VIDEO_LINE_LEN;
+ int x, y;
+ for (y = firsty; y lasty; y += VIDEO_LINE_LEN) {
+ for (x = firstx; x lastx; x++) {
+ u8 *dest = (u8 *)(video_fb_address) + x + y;
+ *dest = ~*dest;
+ }
+ }
+}
+
+
static void video_drawchars(int xx, int yy, unsigned char *s, int count)
{
u8 *cdat, *dest, *dest0;
@@ -608,27 +627,15 @@ static void video_putchar(int xx, int yy, unsigned char c)
#if defined(CONFIG_CONSOLE_CURSOR) || defined(CONFIG_VIDEO_SW_CURSOR)
static void video_set_cursor(void)
{
- /* swap drawing colors */
- eorx = fgx;
- fgx = bgx;
- bgx = eorx;
- eorx = fgx ^ bgx;
- /* draw cursor */
- video_putchar(console_col * VIDEO_FONT_WIDTH,
- console_row * VIDEO_FONT_HEIGHT, ' ');
- /* restore drawing colors */
- eorx = fgx;
- fgx = bgx;
- bgx = eorx;
- eorx = fgx ^ bgx;
+ if (cursor_state)
+ console_cursor(0);
+ console_cursor(1);
}
-#endif
-#ifdef CONFIG_CONSOLE_CURSOR
+
+
void console_cursor(int state)
{
- static int last_state = 0;
-
#ifdef CONFIG_CONSOLE_TIME
struct rtc_time tm;
char info[16];
@@ -650,17 +657,20 @@ void console_cursor(int state)
}
#endif
- if (state (last_state != state)) {
- video_set_cursor();
- }
-
- if (!state (last_state != state)) {
- /* clear cursor */
- video_putchar(console_col * VIDEO_FONT_WIDTH,
- console_row * VIDEO_FONT_HEIGHT, ' ');
+ if (cursor_state != state) {
+ if (cursor_state) {
+ /* turn off the cursor */
+ video_invertchar(old_col * VIDEO_FONT_WIDTH,
+old_row * VIDEO_FONT_HEIGHT);
+ } else {
+ /* turn off the cursor and record where it is */
+ video_invertchar(console_col * VIDEO_FONT_WIDTH,
+console_row * VIDEO_FONT_HEIGHT);
+ old_col = console_col;
+
Re: [U-Boot] fatload accepting wildcard in filename?
On 2011-11-08 09:49, Wolfgang Denk wrote: Their release is from a few years back (2008-06-11); the same fatload + wildcard construct doesn't work with 2011.03. I'm trying to find out how this was implemented, and if it was ever part of mainline or if it was a local hack. (I couldn't find it in the ml archives.) This has never been supported in mainline code. Ok, thanks. I'm going to give it a shot and see if I can come up with something sensible. -- Orjan Friberg FlatFrog Laboratories AB ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Add some missing endian conversions in fdt_support.c
Some functions in fdt_support.c use fdt_getprop to read 32 bit values out of the device tree, but then use them directly without doing any endian conversion. Because they check for a value that doesn't actually appear in practice, the functions continued to work even though they're incorrect. This change adds the missing conversions. Signed-off-by: Gabe Black gabebl...@chromium.org --- common/fdt_support.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/common/fdt_support.c b/common/fdt_support.c index bdda64d..c501604 100644 --- a/common/fdt_support.c +++ b/common/fdt_support.c @@ -61,7 +61,7 @@ u32 fdt_getprop_u32_default(void *fdt, const char *path, const char *prop, val = fdt_getprop(fdt, off, prop, NULL); if (val) - return *val; + return fdt32_to_cpu(*val); else return dflt; } @@ -372,7 +372,7 @@ static int get_cells_len(void *blob, char *nr_cells_name) const u32 *cell; cell = fdt_getprop(blob, 0, nr_cells_name, NULL); - if (cell *cell == 2) + if (cell fdt32_to_cpu(*cell) == 2) return 8; return 4; -- 1.7.3.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] [fdt] Fix constness of the fdt void pointer in fdt_getprop_u32_default
The function fdt_getprop_u32_default doesn't modify the fdt, so it can use a
const void * for its fdt argument.
Signed-off-by: Gabe Black gabebl...@chromium.org
---
common/fdt_support.c |4 ++--
include/fdt_support.h |4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/common/fdt_support.c b/common/fdt_support.c
index bdda64d..bd3a014 100644
--- a/common/fdt_support.c
+++ b/common/fdt_support.c
@@ -49,8 +49,8 @@ DECLARE_GLOBAL_DATA_PTR;
* Convenience function to find a node and return it's property or a
* default value if it doesn't exist.
*/
-u32 fdt_getprop_u32_default(void *fdt, const char *path, const char *prop,
- const u32 dflt)
+u32 fdt_getprop_u32_default(const void *fdt, const char *path,
+ const char *prop, const u32 dflt)
{
const u32 *val;
int off;
diff --git a/include/fdt_support.h b/include/fdt_support.h
index c7b4605..cef3c65 100644
--- a/include/fdt_support.h
+++ b/include/fdt_support.h
@@ -28,8 +28,8 @@
#include fdt.h
-u32 fdt_getprop_u32_default(void *fdt, const char *path, const char *prop,
- const u32 dflt);
+u32 fdt_getprop_u32_default(const void *fdt, const char *path,
+ const char *prop, const u32 dflt);
int fdt_chosen(void *fdt, int force);
int fdt_initrd(void *fdt, ulong initrd_start, ulong initrd_end, int force);
void do_fixup_by_path(void *fdt, const char *path, const char *prop,
--
1.7.3.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] [build] Automatically build the device tree if DEV_TREE_SEPARATE is set
This change makes the u-boot all target build the separate device tree if DEV_TREE_SEPARATE is set. This use of DEV_TREE_SEPARATE is consistent with the one other use in the u-boot build system. It's at least expedient and perhaps necessary to build the device tree this way since it's difficult to know the value of $(obj) when invoking make. Signed-off-by: Gabe Black gabebl...@chromium.org --- Makefile |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/Makefile b/Makefile index 294c762..654e07e 100644 --- a/Makefile +++ b/Makefile @@ -371,6 +371,10 @@ $(obj)u-boot.dtb: $(obj)u-boot $(MAKE) -C dts binary mv $(obj)dts/dt.dtb $@ +ifdef DEV_TREE_SEPARATE +all: $(obj)u-boot.dtb +endif + $(obj)u-boot-dtb.bin: $(obj)u-boot.bin $(obj)u-boot.dtb cat $^ $@ -- 1.7.3.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] [MMC] Is the HIGH_SPEED_SUPPORT bit checked wrong in mmc.c?
Hi all,
2011/11/3 馬克泡 macp...@gmail.com:
Hi all,
I have a problem on reading low speed card on my platform.
While high speed card were all correct.
I've reported a problem with FTSDC010 controller last week.
The problem is, when I'm using card SD ver 1.10 on the platform, the hardware
will report CRC_FAIL when doing DATA transaction when it reads more
then 1 block (512bytes).
After debugging into the problem, I found that if force the high speed
card (capability) under low speed mode,
the CRC_FAIL problem won't occur.
But, the high speed card which is SD ver 2.0 and later won't have this
kind of problem.
However, after I've got the SD 3.0 specification this week.
I've checked CSD information and SD_SWITCH_SWITCH (STATUS) information
with the card I've read.
The detecting function of high_speed seems no problem at all.
But controller still report CRC_FAIL when the hardware is doing DATA
transaction.
Some cards will even worse, the hardware will report CRC_FAIL on
SD_SWITCH_CHECK Command.
After comparing to the Linux generic mmc stack.
I've found that when the mmc stack is setting ios (clock) of the card,
even if the card reported it has high speed capability
(SW_SWITCH_STATUS 50Mhz), the mmc stack will still check
the tran_speed (CSD) recorded in mmc card.
However, the u-boot's mmc stack will only check if the clock is
smaller than f_max (this should be the capability
of mmc host controller, correct?) but not the actual speed of the card.
The following is the part of Linux code, drivers/mmc/core/sd.c,
mmc_sd_init_card().
/*
* Compute bus speed.
*/
max_dtr = (unsigned int)-1;
if (mmc_card_highspeed(card)) {
if (max_dtr card-sw_caps.hs_max_dtr) {
max_dtr = card-sw_caps.hs_max_dtr;
printk(KERN_WARNING %s: sw_caps.hs_max_dtr compute bus speed: %08x\n,
__func__, card-sw_caps.hs_max_dtr);
}
} else if (max_dtr card-csd.max_dtr) {
max_dtr = card-csd.max_dtr;
printk(KERN_WARNING %s: csd.max_dtr compute bus speed: %08x\n,
__func__, card-csd.max_dtr);
}
mmc_set_clock(host, max_dtr);
The following is the u-boot code, drivers/mmc/mmc.c, mmc_startup().
if (IS_SD(mmc)) {
[snip]
if (mmc-card_caps MMC_MODE_HS)
mmc_set_clock(mmc, 5000);
else {
mmc_set_clock(mmc, 2500);
The stack will set 50Mhz as the value of the clock to the driver if
MMC_MODE_HS has been detected.
The MODE_HS detecting function are most the same in both Linux's and
u-boot's code.
In my case, the capability of the platform can support clock up to
3300MHz, which is depended
to the AHBBUS_CLOCK.
I'm going to add a piece of code to like the behavior in the Linux.
Please help on comments. Thanks!
--
Best regards,
Macpaul Lin
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] arm: Correct build error introduced by getenv_ulong() patch
Hi Mike,
On Monday 31 October 2011 17:06:46 Simon Glass wrote:
On Sun, Oct 30, 2011 at 5:44 PM, Mike Frysinger wrote:
On Sunday 23 October 2011 23:44:35 Simon Glass wrote:
--- a/arch/arm/lib/board.c
+++ b/arch/arm/lib/board.c
flash_size = flash_init();
if (flash_size 0) {
# ifdef CONFIG_SYS_FLASH_CHECKSUM
+ char *s = getenv(flashchecksum);
+
print_size(flash_size, );
/*
* Compute and print flash CRC if flashchecksum is set to
'y' *
* NOTE: Maybe we should add some WATCHDOG_RESET()? XXX
*/
- s = getenv(flashchecksum);
if (s (*s == 'y')) {
printf( CRC: %08X, crc32(0,
(const unsigned char *)
CONFIG_SYS_FLASH_BASE, @@ -566,9 +567,12 @@ void board_init_r(gd_t *id,
ulong dest_addr) /* Initialize from environment */
load_addr = getenv_ulong(loadaddr, 16, load_addr);
#if defined(CONFIG_CMD_NET)
- s = getenv(bootfile);
- if (s != NULL)
- copy_filename(BootFile, s, sizeof(BootFile));
+ {
+ char *s = getenv(bootfile);
+
+ if (s != NULL)
+ copy_filename(BootFile, s, sizeof(BootFile));
+ }
#endif
seems like a better solution would be to use at the top:
__maybe_unused char *s;
also, shouldn't these be const char *s ?
We can certainly do this and I agree it is easier than #ifdefs. Does
it introduce the possibility that one day the code will stop using the
variable but it will still be declared? Is the fact that we need the
#ifdefs an indication that the function should be too long and should
be refactored? it in fact better to have these explicit so we can see
them for the ugliness they are?
yes, you're right that it does leave the door open to the variable being
declared, never used, and gcc not emitting a warning about it.
both setups suck, but i'd lean towards the less-ifdef state ... wonder if
Wolfgang has a preference.
Personally, I think that the nuisance of a potential unused variable is
less of an issue than the actual _problems_ that ifdefs induce.
Cheers
Detlev
--
The best way to predict the future is to invent it.
-- Alan Kay
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] [x86] [zboot] Change printf to puts to avoid a buffer overflow
printf as currently implemented in u-boot has a problem where it can overflow an internal buffer if it prints an expanded string that's too long. Our command lines are long enough to cause this problem. A fix should be coming, but in the mean time this change replaces a problematic printf with a few calls to puts that have the same effect. This may perform slightly better because it should avoid a copy and scanning for format specifiers. The amount of time it actually takes up is very tiny relative to everything else so in practice that's probably irrelevant. Signed-off-by: Gabe Black gabebl...@chromium.org --- arch/x86/lib/zimage.c |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/arch/x86/lib/zimage.c b/arch/x86/lib/zimage.c index d2dd6fd..a48ae6c 100644 --- a/arch/x86/lib/zimage.c +++ b/arch/x86/lib/zimage.c @@ -78,7 +78,9 @@ static void build_command_line(char *command_line, int auto_boot) } - printf(Kernel command line: \%s\\n, command_line); + puts(Kernel command line: \); + puts(command_line); + puts(\\n); } void *load_zimage(char *image, unsigned long kernel_size, -- 1.7.3.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] [x86] Wrap small helper functions from libgcc to avoid an ABI mismatch
When gcc compiles some 64 bit operations on a 32 bit machine, it generates
calls to small functions instead of instructions which do the job directly.
Those functions are defined in libgcc and transparently provide whatever
functionality was necessary. Unfortunately, u-boot can be built with a
non-standard ABI when libgcc isn't. When the two are linked together, very
confusing bugs can crop up, for instance seemingly normal integer division
or modulus getting the wrong answer or even raising a spurious divide by
zero exception.
This change barrows (steals) a technique and some code from coreboot which
solves this problem by creating wrappers which translate the calling
convention when calling the functions in libgcc. Unfortunately that means that
these instructions which had already been turned into functions have even more
overhead, but more importantly it makes them work properly.
To find all of the functions that needed wrapping, u-boot was compiled without
linking in libgcc. All the symbols the linker complained were undefined were
presumed to be the symbols that are needed from libgcc. These were a subset of
the symbols covered by the coreboot code, so it was used unmodified.
Signed-off-by: Gabe Black gabebl...@chromium.org
---
arch/x86/config.mk|3 +++
arch/x86/lib/Makefile |1 +
arch/x86/lib/gcc.c| 38 ++
3 files changed, 42 insertions(+), 0 deletions(-)
create mode 100644 arch/x86/lib/gcc.c
diff --git a/arch/x86/config.mk b/arch/x86/config.mk
index fe9083f..c38ac70 100644
--- a/arch/x86/config.mk
+++ b/arch/x86/config.mk
@@ -41,3 +41,6 @@ PLATFORM_RELFLAGS += -ffunction-sections -fvisibility=hidden
PLATFORM_LDFLAGS += --emit-relocs -Bsymbolic -Bsymbolic-functions
LDFLAGS_FINAL += --gc-sections -pie
+LDFLAGS_FINAL += --wrap=__divdi3 --wrap=__udivdi3
+LDFLAGS_FINAL += --wrap=__moddi3 --wrap=__umoddi3
+LDSCRIPT := $(SRCTREE)/$(CPUDIR)/u-boot.lds
diff --git a/arch/x86/lib/Makefile b/arch/x86/lib/Makefile
index 71e94f7..210dbbe 100644
--- a/arch/x86/lib/Makefile
+++ b/arch/x86/lib/Makefile
@@ -32,6 +32,7 @@ SOBJS-y += realmode_switch.o
COBJS-y+= bios_setup.o
COBJS-y+= board.o
COBJS-y+= bootm.o
+COBJS-y+= gcc.o
COBJS-y+= interrupts.o
COBJS-$(CONFIG_SYS_PCAT_INTERRUPTS) += pcat_interrupts.o
COBJS-$(CONFIG_SYS_GENERIC_TIMER) += pcat_timer.o
diff --git a/arch/x86/lib/gcc.c b/arch/x86/lib/gcc.c
new file mode 100644
index 000..b11ea5f
--- /dev/null
+++ b/arch/x86/lib/gcc.c
@@ -0,0 +1,38 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright (C) 2009 coresystems GmbH
+ *
+ * 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; version 2 or later of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA, 02110-1301 USA
+ */
+
+#ifdef __GNUC__
+
+/*
+ * GCC's libgcc handling is quite broken. While the libgcc functions
+ * are always regparm(0) the code that calls them uses whatever the
+ * compiler call specifies. Therefore we need a wrapper around those
+ * functions. See gcc bug PR41055 for more information.
+ */
+#define WRAP_LIBGCC_CALL(type, name) \
+ type __real_##name(type a, type b) __attribute__((regparm(0))); \
+ type __wrap_##name(type a, type b); \
+ type __wrap_##name(type a, type b) { return __real_##name(a, b); }
+
+WRAP_LIBGCC_CALL(long long, __divdi3)
+WRAP_LIBGCC_CALL(unsigned long long, __udivdi3)
+WRAP_LIBGCC_CALL(long long, __moddi3)
+WRAP_LIBGCC_CALL(unsigned long long, __umoddi3)
+
+#endif
--
1.7.3.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v0 0/4] env: reworking + default/import individual vars
On 11/06/2011 11:15 PM, Wolfgang Denk wrote: Dear Gerlando Falauto, In message1319647072-17504-1-git-send-email-gerlando.fala...@keymile.com you wrote: This is a resubmission (after removing remove checkpatch errors) of http://lists.denx.de/pipermail/u-boot/2011-September/102875.html Here I am proposing a set of changes in the behaviour of the environment import/set_to_default functions. PATCH 1: Add a new himport_ex() function (reworking of himport_r which is now a wrapper around it), which has 3 new arguments: nvars, vars:, number and list of variables to take into account (0 means ALL) Hmmm I wonder how much testing you did. I tested env import with and without -n. Same for env default. Also tested special variables. For me, env import is broken now. I am not able to see how it's obviously broken. Perhaps you mean that when you don't provide an argument to -n, the following argument (e.g., -t) is interpreted as a variable name (and therefore consumed)? That doesn't look like an error to me. Could you please elaborate and/or provide a test case? Thank you, Gerlando Falauto ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [OT] Re: [PATCH v3] AVR32: fix timer_init() function
Hi Wolfgang, Le 05/10/2011 09:12, Andreas Bießmann a écrit : Dear Sven, Am 04.10.2015 21:53, schrieb Sven Schnelle: Apparently, something went quite wrong with the date for this patch. See http://patchwork.ozlabs.org/patch/117688/, which places it in 2015 (like Andreas' answer does), ignoring Sven's patch mails dates. Wolfgang, maybe this should be mentioned to the patchwork folks. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] [x86] Fix some bugs in the i8402 driver when no controller is present
If no controller is present, the i8402 driver should return immediately and
not attempt to operate on the missing hardware.
In kbd_input_empty, the status register is checked every millisecond to see
whether the input buffer is empty, up to a timeout which is tracked by
decrimenting a counter each time the check is performed. The decrement is
performed with a postfix -- operator, and the value of the counter is
checked in place. That means that when the counter reaches zero and the
loop terminates, it will actually be decrimented one more time and become
-1. That value is returned as the return value of the function. That would
give the right answer if it wasn't for that extra decrement because a
timeout would indicate that the buffer never became empty.
This change fixes both of those bugs.
Signed-off-by: Gabe Black gabebl...@chromium.org
---
drivers/input/i8042.c | 12 +++-
1 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/drivers/input/i8042.c b/drivers/input/i8042.c
index 58094c9..3bdfa7d 100644
--- a/drivers/input/i8042.c
+++ b/drivers/input/i8042.c
@@ -315,6 +315,13 @@ static unsigned char ext_key_map [] =
0x00/* map end */
};
+/**/
+
+static int kbd_controller_present (void)
+{
+return in8(I8042_STATUS_REG) != 0xff;
+}
+
/***
*
* i8042_kbd_init - reset keyboard and init state flags
@@ -324,6 +331,9 @@ int i8042_kbd_init (void)
int keymap, try;
char *penv;
+if (!kbd_controller_present())
+return -1;
+
#ifdef CONFIG_USE_CPCIDVI
if ((penv = getenv (console)) != NULL) {
if (strncmp (penv, serial, 7) == 0) {
@@ -629,7 +639,7 @@ static int kbd_input_empty (void)
while ((in8 (I8042_STATUS_REG) 0x02) kbdTimeout--)
udelay(1000);
-return kbdTimeout;
+return kbdTimeout != -1;
}
/**/
--
1.7.3.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Import the glibc implementation of x86 memset into u-boot
The new implementation is about twice as fast as the old.
Signed-off-by: Gabe Black gabebl...@chromium.org
---
arch/x86/include/asm/string.h |2 +-
arch/x86/lib/Makefile |1 +
arch/x86/lib/string.c | 87 +
3 files changed, 89 insertions(+), 1 deletions(-)
create mode 100644 arch/x86/lib/string.c
diff --git a/arch/x86/include/asm/string.h b/arch/x86/include/asm/string.h
index 3643a79..3aa6c11 100644
--- a/arch/x86/include/asm/string.h
+++ b/arch/x86/include/asm/string.h
@@ -23,7 +23,7 @@ extern void * memmove(void *, const void *, __kernel_size_t);
#undef __HAVE_ARCH_MEMCHR
extern void * memchr(const void *, int, __kernel_size_t);
-#undef __HAVE_ARCH_MEMSET
+#define __HAVE_ARCH_MEMSET
extern void * memset(void *, int, __kernel_size_t);
#undef __HAVE_ARCH_MEMZERO
diff --git a/arch/x86/lib/Makefile b/arch/x86/lib/Makefile
index 71e94f7..d9cabdd 100644
--- a/arch/x86/lib/Makefile
+++ b/arch/x86/lib/Makefile
@@ -38,6 +38,7 @@ COBJS-$(CONFIG_SYS_GENERIC_TIMER) += pcat_timer.o
COBJS-$(CONFIG_PCI) += pci.o
COBJS-$(CONFIG_PCI) += pci_type1.o
COBJS-y+= realmode.o
+COBJS-y+= string.o
COBJS-y+= timer.o
COBJS-y+= video_bios.o
COBJS-y+= video.o
diff --git a/arch/x86/lib/string.c b/arch/x86/lib/string.c
new file mode 100644
index 000..1346173
--- /dev/null
+++ b/arch/x86/lib/string.c
@@ -0,0 +1,87 @@
+/*
+ * Copyright (C) 1991,1992,1993,1997,1998,2003, 2005 Free Software Foundation,
Inc.
+ * This file is part of the GNU C Library.
+ * Copyright (c) 2011 The Chromium OS Authors. All rights reserved.
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+/* From glibc-2.14, sysdeps/i386/memset.c */
+
+#include compiler.h
+#include asm/string.h
+#include linux/types.h
+
+typedef uint32_t op_t;
+
+void *memset(void *dstpp, int c, size_t len)
+{
+ int d0;
+ unsigned long int dstp = (unsigned long int) dstpp;
+
+ /* This explicit register allocation improves code very much indeed. */
+ register op_t x asm(ax);
+
+ x = (unsigned char) c;
+
+ /* Clear the direction flag, so filling will move forward. */
+ asm volatile(cld);
+
+ /* This threshold value is optimal. */
+ if (len = 12) {
+ /* Fill X with four copies of the char we want to fill with. */
+ x |= (x 8);
+ x |= (x 16);
+
+ /* Adjust LEN for the bytes handled in the first loop. */
+ len -= (-dstp) % sizeof(op_t);
+
+ /*
+* There are at least some bytes to set. No need to test for
+* LEN == 0 in this alignment loop.
+*/
+
+ /* Fill bytes until DSTP is aligned on a longword boundary. */
+ asm volatile(
+ rep\n
+ stosb /* %0, %2, %3 */ :
+ =D (dstp), =c (d0) :
+ 0 (dstp), 1 ((-dstp) % sizeof(op_t)), a (x) :
+ memory);
+
+ /* Fill longwords. */
+ asm volatile(
+ rep\n
+ stosl /* %0, %2, %3 */ :
+ =D (dstp), =c (d0) :
+ 0 (dstp), 1 (len / sizeof(op_t)), a (x) :
+ memory);
+ len %= sizeof(op_t);
+ }
+
+ /* Write the last few bytes. */
+ asm volatile(
+ rep\n
+ stosb /* %0, %2, %3 */ :
+ =D (dstp), =c (d0) :
+ 0 (dstp), 1 (len), a (x) :
+ memory);
+
+ return dstpp;
+}
--
1.7.3.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [OT] Re: [PATCH v3] AVR32: fix timer_init() function
Dear Albert, Am 08.11.2011 10:38, schrieb Albert ARIBAUD: Hi Wolfgang, Le 05/10/2011 09:12, Andreas Bießmann a écrit : Dear Sven, Am 04.10.2015 21:53, schrieb Sven Schnelle: Apparently, something went quite wrong with the date for this patch. See http://patchwork.ozlabs.org/patch/117688/, which places it in 2015 (like Andreas' answer does), ignoring Sven's patch mails dates. Sven's MUA has set the 'Date:' field to 'Date: Sun, 4 Oct 2015 21:53:32 +0200' in Mail header. BTW this will also be the date of the patch in git and could lead to problems when merge/rebase in future. Sven, could you please provide another version of the patch _or_ Reinhard could you please adopt the mail header (Date:) before applying this patch? Wolfgang, maybe this should be mentioned to the patchwork folks. I don't think patchwork was wrong here. My MUA acts the same way. best regards Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Continuation line alignment
On 11/08/2011 12:58 AM, Scott Wood wrote:
I like aligning based on which level of nested parens the line break is
in (and removing unnecessary parens when precedence is obvious, to make
it easier to track the relevant ones):
if ((day_of_week() % 2 == 0
(temperature() 14.4 || temperature() 15.3)) ||
(sky_color() == E_BLUE sim_credit() % 100 != 27) ||
uptime() 3600) {
work = 1;
} else if ((received_calls() 1
zenith_angle() == 0) ||
call_is_important()) {
work = 0;
} else {
udelay(rand());
work = ((rand() % 2) == 1);
}
I like that too.
Anyway... Are there are any guidelines for indenting comments on the
right side of the code? Like:
if ((day_of_week() % 2 == 0 /* even days are OK */
(temperature() 14.4 || temperature() 15.3)) ||
/*
* but only outside of a
* certain temp. range
*/
(sky_color() == E_BLUE sim_credit() % 100 != 27) ||
/*
* or, it's a nice a day
* but balance does not
* have 27 cents as
* decimal part
*/
uptime() 3600) { /* work 4 the 1st hr! */
work = 1;
} else if ((received_calls() 1
zenith_angle() == 0) ||
call_is_important()) {
work = 0;
} else {
udelay(rand());
work = ((rand() % 2) == 1);
}
... becuase git-gui will interpret all tabs which are on the right of
some non-whitespace text in a very weird way.
Is using tabs on the right of text forbidden/not recommended for some
reason?
Thanks!
Gerlando Falauto
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] [x86] Fix how the location of the realmode and bios blobs are calculated
Gabe, Can you please change your prefix from '[x86]' to 'x86:' Thanks, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] uboot on devkit8000
Do you have an UART connected? Regards Simon On 11/07/2011 02:18 PM, Mariya Abdul Ghafoor wrote: I configured Angstrom on DevKit8000 (clone of Beagleboard) now the touch screen shows shell prompt i.e. root@DevKit8000~# but there is no uboot console output...I need to port Android on it and without the console output I have no idea how! I am new to embedded systems and is totally confused now! I have very less time left and any help from you could be a life saver! Please. ___ 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] ulpi: add generic ULPI support header file
On 11/02/11 20:42, Jana Rapava wrote:
Add ULPI header file needed by Efika USB support patchset and generic
ULPI support patch, which is to be posted soon.
Signed-off-by: Jana Rapava ferma...@gmail.com
Cc: Marek Vasut marek.va...@gmail.com
Cc: Remy Bohmer li...@bohmer.net
Cc: Stefano Babic sba...@denx.de
Cc: Igor Grinberg grinb...@compulab.co.il
---
Changes for v2:
- whitespace and comment changes
include/usb/ulpi.h | 204
1 files changed, 204 insertions(+), 0 deletions(-)
create mode 100644 include/usb/ulpi.h
diff --git a/include/usb/ulpi.h b/include/usb/ulpi.h
new file mode 100644
index 000..1519cc5
--- /dev/null
+++ b/include/usb/ulpi.h
@@ -0,0 +1,204 @@
+/*
+ * Copyright (C) 2011 Jana Rapava ferma...@gmail.com
+ * Based on:
+ * linux/include/linux/usb/ulpi.h
+ * ULPI defines and function prototypes
+ *
+ * Original Copyrights follow:
+ * Copyright (C) 2010 Nokia Corporation
+ *
+ * This software is distributed under the terms of the GNU General
+ * Public License (GPL) as published by the Free Software Foundation,
+ * version 2 of that License.
+ */
+
+#ifndef __USB_ULPI_H
+#define __USB_ULPI_H
+
+#define ULPI_ID_REGS_COUNT 4
+#define ULPI_TEST_VALUE 0x55
+#define ULPI_TIMEOUT 1000 /* some reasonable value */
+
+/* ULPI viewport control bits */
+#define ULPI_WU (1 31)
+#define ULPI_SS (1 27)
+#define ULPI_RWRUN (1 30)
+#define ULPI_RWCTRL (1 29)
+
+struct ulpi_regs {
+ /* Vendor ID and Product ID: 0x00 - 0x03 Read-only */
+ u8 vendor_id_low;
+ u8 vendor_id_high;
+ u8 product_id_low;
+ u8 product_id_high;
+ /* Function Control: 0x04 - 0x06 Read */
+ u8 function_ctrl_write;/* 0x04 Write */
+ u8 function_ctrl_set; /* 0x05 Set */
+ u8 function_ctrl_clear;/* 0x06 Clear */
+ /* Interface Control: 0x07 - 0x09 Read */
+ u8 iface_ctrl_write; /* 0x07 Write */
+ u8 iface_ctrl_set; /* 0x08 Set */
+ u8 iface_ctrl_clear; /* 0x09 Clear */
+ /* OTG Control: 0x0A - 0x0C Read */
+ u8 otg_ctrl_write; /* 0x0A Write */
+ u8 otg_ctrl_set; /* 0x0B Set */
+ u8 otg_ctrl_clear; /* 0x0C Clear */
+ /* USB Interrupt Enable Rising: 0x0D - 0x0F Read */
+ u8 usb_ie_rising_write;/* 0x0D Write */
+ u8 usb_ie_rising_set; /* 0x0E Set */
+ u8 usb_ie_rising_clear;/* 0x0F Clear */
+ /* USB Interrupt Enable Falling: 0x10 - 0x12 Read */
+ u8 usb_ie_falling_write; /* 0x10 Write */
+ u8 usb_ie_falling_set; /* 0x11 Set */
+ u8 usb_ie_falling_clear; /* 0x12 Clear */
+ /* USB Interrupt Status: 0x13 Read-only */
+ u8 usb_int_status;
+ /* USB Interrupt Latch: 0x14 Read-only with auto-clear */
+ u8 usb_int_latch;
+ /* Debug: 0x15 Read-only */
+ u8 debug;
+ /* Scratch Register: 0x16 - 0x18 Read */
+ u8 scratch_write; /* 0x16 Write */
+ u8 scratch_set;/* 0x17 Set */
+ u8 scratch_clear; /* 0x18 Clear */
+ /*
+ * Optional Carkit registers
+ */
+ /* Carkit Control: 0x19 - 0x1B Read */
+ u8 carkit_ctrl_write; /* 0x19 Write */
+ u8 carkit_ctrl_set;/* 0x1A Set */
+ u8 carkit_ctrl_clear; /* 0x1B Clear */
+ /* Carkit Interrupt Delay: 0x1C Read, Write */
+ u8 carkit_int_delay;
+ /* Carkit Interrupt Enable: 0x1D - 0x1F Read */
+ u8 carkit_ie_write;/* 0x1D Write */
+ u8 carkit_ie_set; /* 0x1E Set */
+ u8 carkit_ie_clear;/* 0x1F Clear */
+ /* Carkit Interrupt Status: 0x20 Read-only */
+ u8 carkit_int_status;
+ /* Carkit Interrupt Latch: 0x21 Read-only with auto-clear */
+ u8 carkit_int_latch;
+ /* Carkit Pulse Control: 0x22 - 0x24 Read */
+ u8 carkit_pulse_ctrl_write;/* 0x22 Write */
+ u8 carkit_pulse_ctrl_set; /* 0x23 Set */
+ u8 carkit_pulse_ctrl_clear;/* 0x24 Clear */
+ /*
+ * Other optional registers
+ */
+ /* Transmit Positive Width: 0x25 Read, Write */
+ u8 transmit_pos_width;
+ /* Transmit Negative Width: 0x26 Read, Write */
+ u8 transmit_neg_width;
+ /* Receive Polarity Recovery: 0x27 Read, Write */
+ u8 recv_pol_recovery;
+ /*
+ * Addresses 0x28 - 0x2E are reserved, so we use offsets
+ * for immediate registers with higher addresses
+ */
+};
Sorry for not spotting this earlier, but it is confusing
to call the *_write registers that way.
Can those be called without the _write suffix?
+
+/* Access Extended Register Set (indicator) */
+#define
Re: [U-Boot] [PATCH] ulpi: add generic ULPI functionality
On 11/06/11 01:32, Jana Rapava wrote:
2011/11/6 Marek Vasut marek.va...@gmail.com mailto:marek.va...@gmail.com
2011/11/5 Marek Vasut marek.va...@gmail.com
mailto:marek.va...@gmail.com
+int ulpi_wait(struct usb_ehci *ehci, u32 ulpi_value, u32 ulpi_mask)
So this works only with EHCI? How generic is it then ?
I thought until now that ULPI is EHCI-dependent, but isn't... Ok, what
else
should be supported? OHCI? I haven't any hardware to test it, but I
could
give it a try.
What about xHCI? I have no idea about OHCI, but why won't you be able to
have
OHCI and ULPI PHY?
I'll look at it.
+void ulpi_iface_ctrl_flags
+ (struct usb_ehci *ehci, struct ulpi_regs *ulpi, int
access_mode,
u32
flags) +{
+ switch (access_mode) {
+ case WRITE:
+ ulpi_write(ehci, (u32)ulpi-iface_ctrl_write, flags);
+ break;
+ case SET:
+ ulpi_write(ehci, (u32)ulpi-iface_ctrl_set, flags);
+ break;
+ case CLEAR:
+ ulpi_write(ehci, (u32)ulpi-iface_ctrl_clear, flags);
+ break;
+ }
+
+}
Is this crap from linux or something?
No, Linux has offset-based access to ULPI registers, some structure
otg_transceiver, where the driver sets the bits which it wants to be
set in
ULPI registers (if I understand it well) and family of functions, which
set
bits according to informations in otg_transceiver.
Ok, you have writel() functions, why do you need this switch stuff ?
I tried to design some interface, which would allow its user care only about
register, access mode and flags and not about the exact way this huge bunch
od u8 fields called ulpi_regs is implemented.
User should neither care about the register, nor the access mode.
User should ask the driver to do something useful
(e.g. put the phy to some mode, enable vbus, etc.),
and that can be done with flags and functional API.
--
Regards,
Igor.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] da8xxevm: fix build error
On Tue, Nov 8, 2011 at 6:02 AM, prabhakar.cse...@gmail.com wrote:
From: Prabhakar Lad prabhakar.cse...@gmail.com
This patch fixes following compile error for da8xx evm
da830evm.c: In function 'board_init':
da830evm.c:222: error: 'DAVINCI_SYSCFG_SUSPSRC_UART2' undeclared (first use
in this function)
da830evm.c:222: error: (Each undeclared identifier is reported only once
da830evm.c:222: error: for each function it appears in.)
make[2]: *** [da830evm.o] Error 1
similarly for da850evm.
Uh, this is really bad... Thanks a lot!
On da850evm:
Tested-by: Christian Riesch christian.rie...@omicron.at
Sandeep Paulraj, can you please take this patch?
Regards, Christian
introduced through commit:
f9fc237f1f07d4e5ff7c9c2da39cabc8d3d7b339
Signed-off-by: Prabhakar Lad prabhakar.cse...@gmail.com
---
arch/arm/include/asm/arch-davinci/hardware.h | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/include/asm/arch-davinci/hardware.h
b/arch/arm/include/asm/arch-davinci/hardware.h
index bea1499..ee8fd43 100644
--- a/arch/arm/include/asm/arch-davinci/hardware.h
+++ b/arch/arm/include/asm/arch-davinci/hardware.h
@@ -468,6 +468,7 @@ struct davinci_syscfg_regs {
#define DAVINCI_SYSCFG_SUSPSRC_SPI0 (1 21)
#define DAVINCI_SYSCFG_SUSPSRC_SPI1 (1 22)
#define DAVINCI_SYSCFG_SUSPSRC_UART0 (1 18)
+#define DAVINCI_SYSCFG_SUSPSRC_UART2 (1 20)
#define DAVINCI_SYSCFG_SUSPSRC_TIMER0 (1 27)
struct davinci_syscfg1_regs {
--
1.7.0.4
___
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] ulpi: add generic ULPI functionality
Hi Jana,
Thanks for porting this.
Several comments below.
On 11/05/11 22:50, Jana Rapava wrote:
Add generic functions for ULPI init and setting bits in
ULPI registers.
Signed-off-by: Jana Rapava ferma...@gmail.com
Cc: Marek Vasut marek.va...@gmail.com
Cc: Remy Bohmer li...@bohmer.net
Cc: Stefano Babic sba...@denx.de
Cc: Igor Grinberg grinb...@compulab.co.il
---
Makefile |1 +
drivers/usb/ulpi/Makefile| 44 ++
drivers/usb/ulpi/ulpi-viewport.c | 87 +++
drivers/usb/ulpi/ulpi.c | 123
++
include/usb/ulpi.h | 16 +
5 files changed, 271 insertions(+), 0 deletions(-)
create mode 100644 drivers/usb/ulpi/Makefile
create mode 100644 drivers/usb/ulpi/ulpi-viewport.c
create mode 100644 drivers/usb/ulpi/ulpi.c
diff --git a/Makefile b/Makefile
index 571c3eb..a475cb9 100644
--- a/Makefile
+++ b/Makefile
@@ -283,6 +283,7 @@ LIBS += drivers/usb/gadget/libusb_gadget.o
LIBS += drivers/usb/host/libusb_host.o
LIBS += drivers/usb/musb/libusb_musb.o
LIBS += drivers/usb/phy/libusb_phy.o
+LIBS += drivers/usb/ulpi/libusb_ulpi.o
LIBS += drivers/video/libvideo.o
LIBS += drivers/watchdog/libwatchdog.o
LIBS += common/libcommon.o
diff --git a/drivers/usb/ulpi/Makefile b/drivers/usb/ulpi/Makefile
new file mode 100644
index 000..f7b6e20
--- /dev/null
+++ b/drivers/usb/ulpi/Makefile
@@ -0,0 +1,44 @@
+#
+# Copyright (C) 2011 Jana Rapava ferma...@gmail.com
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+# MA 02111-1307 USA
+#
+
+include $(TOPDIR)/config.mk
+
+LIB := $(obj)libusb_ulpi.o
+
+COBJS-$(CONFIG_USB_ULPI) += ulpi.o ulpi-viewport.o
This switch is fine for now, but not all viewport
implementations can use the ulpi-viewport.c file.
Please split, so we can have:
COBJS-$(CONFIG_USB_ULPI) += ulpi.o
which is generic and:
COBJS-$(CONFIG_USB_ULPI_VIEWPORT) += ulpi-viewport.o
which is more hardware specific.
+
+COBJS:= $(COBJS-y)
+SRCS := $(COBJS:.o=.c)
+OBJS := $(addprefix $(obj),$(COBJS))
+
+all: $(LIB)
+
+$(LIB): $(obj).depend $(OBJS)
+ $(call cmd_link_o_target, $(OBJS))
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/drivers/usb/ulpi/ulpi-viewport.c
b/drivers/usb/ulpi/ulpi-viewport.c
new file mode 100644
index 000..a0c213e
--- /dev/null
+++ b/drivers/usb/ulpi/ulpi-viewport.c
@@ -0,0 +1,87 @@
+/*
+ * Copyright (C) 2011 Jana Rapava ferma...@gmail.com
+ * Based on:
+ * linux/drivers/usb/otg/ulpi_viewport.c
+ *
+ * Original Copyright follow:
+ * Copyright (C) 2011 Google, Inc.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * 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.
+ *
+ */
+
+#include watchdog.h
+#include asm/io.h
+#include usb/ulpi.h
+#include usb/ehci-fsl.h
+
+/* ULPI viewport control bits */
+#define ULPI_WU (1 31)
+#define ULPI_SS (1 27)
+#define ULPI_RWRUN (1 30)
+#define ULPI_RWCTRL (1 29)
+
+#define ULPI_ADDR_SHIFT 16
+#define ulpi_write_mask(value) ((value) 0xff)
+#define ulpi_read_mask(value)(((value) 8) 0xff)
+
+int ulpi_wait(struct usb_ehci *ehci, u32 ulpi_value, u32 ulpi_mask)
As Marek already stated, ULPI can be used with various interfaces
(e.g. EHCI, OHCI, XHCI), so here I'd suggest having:
u32 *ulpi_viewpoint
which is currently generic enough instead of:
struct usb_ehci *ehci
which is EHCI specific, in all ulpi_*() functions
Also, if this function is not used outside of this file,
please mark it static.
+{
+ int timeout = ULPI_TIMEOUT;
+ u32 tmp;
+
+
Re: [U-Boot] [PATCH v2 3/3] image: Allow images to indicate they're loadable at any address
Dear Nicolas Pitre, In message alpine.lfd.2.02.071942150.3...@xanadu.home you wrote: But as you said yourself, the (raw) kernel is not relocatable. It gets loaded and started at pre-defined (at image build time) addresses. Only the kernel wrapper adds the complexity you are complaining about. Drop it, then. Many of us insist on preserving that complexity. From our point of view, it is u-Boot which is too complex and should drop its uImage complexity. Insisting without giving explanations about the reasons is not exactly a constructive form of a discussion. Actually it is no discussion at all. Ok, so guys ... let me ask a stupid question: Will it be a problem to extend bootm (if not already done) to load zImages directly, with -z option for example ? Won't that satisty both parties -- Wolfgang because the better solution will still be there (uImage) -- and Nico so he can load his worse solution (zImage). And please don't flame me about this worse and better stuff, you get the idea. M But instead of asking you to drop u-Boot's complexity, I'm only asking for u-Boot to let both methods to coexist and work. Ok, we can make a deal on such a base. See the suggestion inmy previous message. Given that the zImage complexity is not going away because we insist on keeping it, either we find a middle ground such as Stephen's patches, or we advocate for a different bootloader on ARM. Do you never happend to compromize once in a while? In my understanding, compromize is not a one-sided business. It is actually easy to convince me, but it needs facts and arguments, not mere insisting on preconceived statements or plain extortion. Best regards, Wolfgang Denk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/3] image: Allow images to indicate they're loadable at any address
Dear Marek Vasut, In message 20081235.05464.marek.va...@gmail.com you wrote: Ok, so guys ... let me ask a stupid question: Not a stupid question at all. Will it be a problem to extend bootm (if not already done) to load zImages directly, with -z option for example ? Won't that satisty both parties -- bootm is for uImage format. I see no sense in extending it. I already suggested to add a new command (bootz ?) that could be used to boot zImage files. I saw that just now. I'd vote for the bootz solution. That way, everyone will be happy and this flame would be over. M ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] arm, davinci: Fix setting of the SDRAM configuration register
da850_ddr_setup() expects the BOOTUNLOCK bit to be set in #define CONFIG_SYS_DA850_DDR2_SDBCR ... in include/configs/*.h If BOOTUNLOCK is not set in this define, several configuration bits will not be writeable and the code will not work. Since the BOOTUNLOCK and TIMUNLOCK bits are not configuration options but access control bits, this patch changes the code to work irrespective of the value of these bits in CONFIG_SYS_DA850_DDR2_SDBCR. Signed-off-by: Christian Riesch christian.rie...@omicron.at Cc: Heiko Schocher h...@denx.de Cc: Paulraj Sandeep s-paul...@ti.com --- This patch applies on top of these two patches: [PATCH v3 1/2] arm, davinci: Rename AM1808 lowlevel functions to DA850 [PATCH v3 2/2] arm, davinci: Remove the duplication of LPSC functions in da850_lowlevel.c Changes for v2: - Removed trailing whitespaces Best regards, Christian arch/arm/cpu/arm926ejs/davinci/da850_lowlevel.c | 25 +- 1 files changed, 19 insertions(+), 6 deletions(-) diff --git a/arch/arm/cpu/arm926ejs/davinci/da850_lowlevel.c b/arch/arm/cpu/arm926ejs/davinci/da850_lowlevel.c index 490ef8f..6f72491 100644 --- a/arch/arm/cpu/arm926ejs/davinci/da850_lowlevel.c +++ b/arch/arm/cpu/arm926ejs/davinci/da850_lowlevel.c @@ -184,19 +184,31 @@ int da850_ddr_setup(unsigned int freq) clrbits_le32(davinci_syscfg1_regs-ddr_slew, (1 DDR_SLEW_CMOSEN_BIT)); + /* +* SDRAM Configuration Register (SDCR): +* First set the BOOTUNLOCK bit to make configuration bits +* writeable. +*/ setbits_le32(dv_ddr2_regs_ctrl-sdbcr, DV_DDR_BOOTUNLOCK); - writel((CONFIG_SYS_DA850_DDR2_SDBCR ~0xf000) | - (readl(dv_ddr2_regs_ctrl-sdbcr) 0xf000), /*rsv Bytes*/ - dv_ddr2_regs_ctrl-sdbcr); - writel(CONFIG_SYS_DA850_DDR2_SDBCR2, dv_ddr2_regs_ctrl-sdbcr2); + /* +* Write the new value of these bits and clear BOOTUNLOCK. +* At the same time, set the TIMUNLOCK bit to allow changing +* the timing registers +*/ + tmp = CONFIG_SYS_DA850_DDR2_SDBCR; + tmp = ~(0x1 DV_DDR_SDCR_BOOTUNLOCK_SHIFT); + tmp |= (0x1 DV_DDR_SDCR_TIMUNLOCK_SHIFT); + writel(tmp, dv_ddr2_regs_ctrl-sdbcr); + /* write memory configuration and timing */ + writel(CONFIG_SYS_DA850_DDR2_SDBCR2, dv_ddr2_regs_ctrl-sdbcr2); writel(CONFIG_SYS_DA850_DDR2_SDTIMR, dv_ddr2_regs_ctrl-sdtimr); writel(CONFIG_SYS_DA850_DDR2_SDTIMR2, dv_ddr2_regs_ctrl-sdtimr2); - clrbits_le32(dv_ddr2_regs_ctrl-sdbcr, - (1 DV_DDR_SDCR_TIMUNLOCK_SHIFT)); + /* clear the TIMUNLOCK bit and write the value of the CL field */ + tmp = ~(0x1 DV_DDR_SDCR_TIMUNLOCK_SHIFT); + writel(tmp, dv_ddr2_regs_ctrl-sdbcr); /* * LPMODEN and MCLKSTOPEN must be set! -- 1.7.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v0 0/4] env: reworking + default/import individual vars
On 11/08/2011 12:46 PM, Wolfgang Denk wrote: Dear Gerlando Falauto, In message4eb8f762.1030...@keymile.com you wrote: I tested env import with and without -n. Same for env default. Also tested special variables. For me, env import is broken now. I am not able to see how it's obviously broken. It just didn't work for me. Honestly, I didn't try it against the latest master branch. Perhaps you mean that when you don't provide an argument to -n, the following argument (e.g., -t) is interpreted as a variable name (and therefore consumed)? That doesn't look like an error to me. Yes, this is a serious bug. Aor design problem. The whole interface is wrong. I have just extendend env export to do a similar thing. The new syntax is: env export [-t | -b | -c] [-s size] addr [var ...] When/where? I can't see that in the latest master branch. We should do exactly the same for env import, i. e. make the size parameter an option to be passed with -s size, and pass the names of any variables to import as additional arguments: env import [-t | -b | -c] [-s size] addr [var ...] This also greatly simplifies the implementation. Totally agree. Question is: won't that break all the existing scripts??? If you agree, I can post an updated patch with the same behavior for import. Although I am bit concerned about our scripts. Best, Gerlando Falauto ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] env: allow to export only selected variables
New syntax:
env export [-t | -b | -c] [-s size] addr [var ...]
With this change it is possible to provide a list of variables names
that shall be exported. Whenno arguments are given, the whole
environment gets exported.
NOTE: The new handling of the size argument means a change to the
user API.
Signed-off-by: Wolfgang Denk w...@denx.de
---
common/cmd_nvedit.c| 33 +
common/env_dataflash.c |2 +-
common/env_eeprom.c|2 +-
common/env_flash.c |4 ++--
common/env_mmc.c |2 +-
common/env_nand.c |4 ++--
common/env_nvram.c |2 +-
common/env_onenand.c |2 +-
common/env_sf.c|4 ++--
include/search.h |3 ++-
lib/hashtable.c| 15 +--
11 files changed, 47 insertions(+), 26 deletions(-)
diff --git a/common/cmd_nvedit.c b/common/cmd_nvedit.c
index 396a171..7194ade 100644
--- a/common/cmd_nvedit.c
+++ b/common/cmd_nvedit.c
@@ -125,7 +125,7 @@ static int env_print(char *name)
}
/* print whole list */
- len = hexport_r(env_htab, '\n', res, 0);
+ len = hexport_r(env_htab, '\n', res, 0, 0, NULL);
if (len 0) {
puts(res);
@@ -647,7 +647,7 @@ static int do_env_delete(cmd_tbl_t *cmdtp, int flag, int
argc, char * const argv
#ifdef CONFIG_CMD_EXPORTENV
/*
- * env export [-t | -b | -c] addr [size]
+ * env export [-t | -b | -c] [-s size] addr [var ...]
* -t: export as text format; if size is given, data will be
* padded with '\0' bytes; if not, one terminating '\0'
* will be added (which is included in the filesize
@@ -657,8 +657,12 @@ static int do_env_delete(cmd_tbl_t *cmdtp, int flag, int
argc, char * const argv
* '\0', list end marked by double \0\0)
* -c: export as checksum protected environment format as
* used for example by saveenv command
+ * -s size:
+ * size of output buffer
* addr: memory address where environment gets stored
- * size: size of output buffer
+ * var... List of variable names that get included into the
+ * export. Without arguments, the whole environment gets
+ * exported.
*
* With -c and size is NOT given, then the export command will
* format the data as currently used for the persistent storage,
@@ -691,7 +695,7 @@ static int do_env_export(cmd_tbl_t *cmdtp, int flag, int
argc, char * const argv
{
charbuf[32];
char*addr, *cmd, *res;
- size_t size;
+ size_t size = 0;
ssize_t len;
env_t *envp;
charsep = '\n';
@@ -715,6 +719,11 @@ static int do_env_export(cmd_tbl_t *cmdtp, int flag, int
argc, char * const argv
sep = '\0';
chk = 1;
break;
+ case 's': /* size given */
+ if (--argc = 0)
+ return cmd_usage(cmdtp);
+ size = simple_strtoul(*++argv, NULL, 16);
+ goto NXTARG;
case 't': /* text format */
if (fmt++)
goto sep_err;
@@ -724,6 +733,7 @@ static int do_env_export(cmd_tbl_t *cmdtp, int flag, int
argc, char * const argv
return cmd_usage(cmdtp);
}
}
+NXTARG:;
}
if (argc 1)
@@ -731,15 +741,14 @@ static int do_env_export(cmd_tbl_t *cmdtp, int flag, int
argc, char * const argv
addr = (char *)simple_strtoul(argv[0], NULL, 16);
- if (argc == 2) {
- size = simple_strtoul(argv[1], NULL, 16);
+ if (size)
memset(addr, '\0', size);
- } else {
- size = 0;
- }
+
+ argc--;
+ argv++;
if (sep) { /* export as text file */
- len = hexport_r(env_htab, sep, addr, size);
+ len = hexport_r(env_htab, sep, addr, size, argc, argv);
if (len 0) {
error(Cannot export environment: errno = %d\n,
errno);
@@ -758,7 +767,7 @@ static int do_env_export(cmd_tbl_t *cmdtp, int flag, int
argc, char * const argv
else/* export as raw binary data */
res = addr;
- len = hexport_r(env_htab, '\0', res, ENV_SIZE);
+ len = hexport_r(env_htab, '\0', res, ENV_SIZE, argc, argv);
if (len 0) {
error(Cannot export environment: errno = %d\n,
errno);
@@ -965,7 +974,7 @@ U_BOOT_CMD(
#if defined(CONFIG_CMD_EDITENV)
env edit name - edit environment variable\n
#endif
- env export [-t | -b | -c] addr [size] - export environment\n
+ env
[U-Boot] [PATCH v3] arm, davinci: Fix setting of the SDRAM configuration register
da850_ddr_setup() expects the BOOTUNLOCK bit to be set in If BOOTUNLOCK is not set in this define, several configuration bits will not be writeable and the code will not work. Since the BOOTUNLOCK and TIMUNLOCK bits are not configuration options but access control bits, this patch changes the code to work irrespective of the value of these bits in CONFIG_SYS_DA850_DDR2_SDBCR. Signed-off-by: Christian Riesch christian.rie...@omicron.at Cc: Heiko Schocher h...@denx.de Cc: Paulraj Sandeep s-paul...@ti.com --- This patch applies on top of these two patches: [PATCH v3 1/2] arm, davinci: Rename AM1808 lowlevel functions to DA850 [PATCH v3 2/2] arm, davinci: Remove the duplication of LPSC functions in da850_lowlevel.c Changes for v2: - Removed trailing whitespaces Changes for v3: - v2 was broken and did not apply, sorry for that! Best regards, Christian arch/arm/cpu/arm926ejs/davinci/da850_lowlevel.c | 25 +- 1 files changed, 19 insertions(+), 6 deletions(-) diff --git a/arch/arm/cpu/arm926ejs/davinci/da850_lowlevel.c b/arch/arm/cpu/arm926ejs/davinci/da850_lowlevel.c index 490ef8f..327ff97 100644 --- a/arch/arm/cpu/arm926ejs/davinci/da850_lowlevel.c +++ b/arch/arm/cpu/arm926ejs/davinci/da850_lowlevel.c @@ -184,18 +184,31 @@ int da850_ddr_setup(unsigned int freq) clrbits_le32(davinci_syscfg1_regs-ddr_slew, (1 DDR_SLEW_CMOSEN_BIT)); + /* +* SDRAM Configuration Register (SDCR): +* First set the BOOTUNLOCK bit to make configuration bits +* writeable. +*/ setbits_le32(dv_ddr2_regs_ctrl-sdbcr, DV_DDR_BOOTUNLOCK); - writel((CONFIG_SYS_DA850_DDR2_SDBCR ~0xf000) | - (readl(dv_ddr2_regs_ctrl-sdbcr) 0xf000), /*rsv Bytes*/ - dv_ddr2_regs_ctrl-sdbcr); - writel(CONFIG_SYS_DA850_DDR2_SDBCR2, dv_ddr2_regs_ctrl-sdbcr2); + /* +* Write the new value of these bits and clear BOOTUNLOCK. +* At the same time, set the TIMUNLOCK bit to allow changing +* the timing registers +*/ + tmp = CONFIG_SYS_DA850_DDR2_SDBCR; + tmp = ~(0x1 DV_DDR_SDCR_BOOTUNLOCK_SHIFT); + tmp |= (0x1 DV_DDR_SDCR_TIMUNLOCK_SHIFT); + writel(tmp, dv_ddr2_regs_ctrl-sdbcr); + /* write memory configuration and timing */ + writel(CONFIG_SYS_DA850_DDR2_SDBCR2, dv_ddr2_regs_ctrl-sdbcr2); writel(CONFIG_SYS_DA850_DDR2_SDTIMR, dv_ddr2_regs_ctrl-sdtimr); writel(CONFIG_SYS_DA850_DDR2_SDTIMR2, dv_ddr2_regs_ctrl-sdtimr2); - clrbits_le32(dv_ddr2_regs_ctrl-sdbcr, - (1 DV_DDR_SDCR_TIMUNLOCK_SHIFT)); + /* clear the TIMUNLOCK bit and write the value of the CL field */ + tmp = ~(0x1 DV_DDR_SDCR_TIMUNLOCK_SHIFT); + writel(tmp, dv_ddr2_regs_ctrl-sdbcr); /* * LPMODEN and MCLKSTOPEN must be set! -- 1.7.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 00/12] x86: Various cosmetic and minor code fixups
NOTE: Due to the way this patchset started life as a two-part series, the threading may seem odd - Each patch is In-reply-to: the original patch from the original corresponding series... This series is the amalgamation of the 7 part 'Various x86 fixups' and 5 part 'x86: Cosmetic cleanup' patch sets This series make x86 *.c files checkpatch clean except for: - x86/cpu/interrupts.c has two function declarations which are picked up as 'extern' - They should ideally be 'static', but the definition of these functions are in macro'd inline assembler, so the compiler complains that the functions are not defined is made static - x86/lib/zimage.c has lines (just) over 80 characters caused by printf() strings which, IMHO, would have reduced readability if split - x86/lib/zimage.c has lines (just) over 80 characters which could be fixed by converting the x86 zImage/bzImage header offsets into a structure - This is a big change prone to the introduction of bugs and will, therefore, be done later after the current x86 backlog stabilises - x86/lib/zimage.c has consider using kstrto* in preference to simple_strtoul warnings Of the patches, patch 4 (cosmetic: checkpatch cleanup of arch/x86/lib/*.c) has 23 checkpatch warnings all associated with asm statements which checkpatch does not know how to deal with, and 3 'line over 80 characters' warnings in x86/lib/zimage.c (see above) Graeme Russ (12): x86: Call hang() on unrecoverable exception cosmetic: checkpatch cleanup of arch/x86/cpu/*.c cosmetic: checkpatch cleanup of arch/x86/cpu/sc520/*.c cosmetic: checkpatch cleanup of arch/x86/lib/*.c cosmetic: checkpatch cleanup of board/eNET/*.c x86: Punt cold- and warm-boot flags sc520: Create arch asm-offsets x86: Add multiboot header x86: Provide more configuration granularity x86: Ensure IDT and GDT remain 16-byte aligned post relocation x86: Misc PCI touchups x86: Misc cleanups arch/x86/cpu/cpu.c | 22 ++-- arch/x86/cpu/interrupts.c | 53 + arch/x86/cpu/sc520/asm-offsets.c| 45 +++ arch/x86/cpu/sc520/sc520.c |2 +- arch/x86/cpu/sc520/sc520_car.S |3 +- arch/x86/cpu/sc520/sc520_pci.c | 28 +++-- arch/x86/cpu/sc520/sc520_sdram.c| 53 arch/x86/cpu/sc520/sc520_ssi.c | 43 arch/x86/cpu/sc520/sc520_timer.c|4 +- arch/x86/cpu/start.S| 30 - arch/x86/cpu/start16.S |3 - arch/x86/include/asm/arch-sc520/sc520.h | 26 arch/x86/include/asm/global_data.h | 21 arch/x86/include/asm/pci.h |5 +- arch/x86/include/asm/realmode.h |4 + arch/x86/include/asm/u-boot-x86.h |8 ++ arch/x86/lib/Makefile | 18 ++-- arch/x86/lib/bios.h | 201 ++- arch/x86/lib/bios_pci.S | 92 ++- arch/x86/lib/bios_setup.c | 93 +++ arch/x86/lib/board.c| 140 -- arch/x86/lib/bootm.c| 27 +++-- arch/x86/lib/interrupts.c | 20 ++-- arch/x86/lib/pcat_interrupts.c |2 +- arch/x86/lib/pcat_timer.c | 37 +++--- arch/x86/lib/pci.c | 99 +++- arch/x86/lib/pci_type1.c| 13 ++- arch/x86/lib/realmode.c | 20 ++-- arch/x86/lib/timer.c| 16 ++-- arch/x86/lib/video.c|6 +- arch/x86/lib/video_bios.c | 130 arch/x86/lib/zimage.c | 94 --- board/eNET/eNET.c |8 +- board/eNET/eNET_pci.c | 19 ++-- board/eNET/eNET_start16.S |5 +- common/cmd_bdinfo.c |3 +- include/configs/eNET.h |5 + 37 files changed, 739 insertions(+), 659 deletions(-) create mode 100644 arch/x86/cpu/sc520/asm-offsets.c -- 1.7.5.2.317.g391b14 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 01/12] x86: Call hang() on unrecoverable exception
Signed-off-by: Graeme Russ graeme.r...@gmail.com --- Changes for v2: - Consolidated patch series arch/x86/cpu/interrupts.c | 20 ++-- 1 files changed, 10 insertions(+), 10 deletions(-) diff --git a/arch/x86/cpu/interrupts.c b/arch/x86/cpu/interrupts.c index c6e72ea..89f39d2 100644 --- a/arch/x86/cpu/interrupts.c +++ b/arch/x86/cpu/interrupts.c @@ -255,7 +255,7 @@ void irq_llsr(struct irq_regs *regs) case 0x00: printf(Divide Error (Division by zero)\n); dump_regs(regs); - while(1); + hang(); break; case 0x01: printf(Debug Interrupt (Single step)\n); @@ -272,32 +272,32 @@ void irq_llsr(struct irq_regs *regs) case 0x04: printf(Overflow\n); dump_regs(regs); - while(1); + hang(); break; case 0x05: printf(BOUND Range Exceeded\n); dump_regs(regs); - while(1); + hang(); break; case 0x06: printf(Invalid Opcode (UnDefined Opcode)\n); dump_regs(regs); - while(1); + hang(); break; case 0x07: printf(Device Not Available (No Math Coprocessor)\n); dump_regs(regs); - while(1); + hang(); break; case 0x08: printf(Double fault\n); dump_regs(regs); - while(1); + hang(); break; case 0x09: printf(Co-processor segment overrun\n); dump_regs(regs); - while(1); + hang(); break; case 0x0a: printf(Invalid TSS\n); @@ -306,12 +306,12 @@ void irq_llsr(struct irq_regs *regs) case 0x0b: printf(Segment Not Present\n); dump_regs(regs); - while(1); + hang(); break; case 0x0c: printf(Stack Segment Fault\n); dump_regs(regs); - while(1); + hang(); break; case 0x0d: printf(General Protection\n); @@ -320,7 +320,7 @@ void irq_llsr(struct irq_regs *regs) case 0x0e: printf(Page fault\n); dump_regs(regs); - while(1); + hang(); break; case 0x0f: printf(Floating-Point Error (Math Fault)\n); -- 1.7.5.2.317.g391b14 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 02/12] cosmetic: checkpatch cleanup of arch/x86/cpu/*.c
Signed-off-by: Graeme Russ graeme.r...@gmail.com
---
Changes for v2:
- Consolidated patch series
arch/x86/cpu/cpu.c| 22 +++---
arch/x86/cpu/interrupts.c | 31 +++
2 files changed, 30 insertions(+), 23 deletions(-)
diff --git a/arch/x86/cpu/cpu.c b/arch/x86/cpu/cpu.c
index cac12c0..48d2f7a 100644
--- a/arch/x86/cpu/cpu.c
+++ b/arch/x86/cpu/cpu.c
@@ -52,7 +52,7 @@
struct gdt_ptr {
u16 len;
u32 ptr;
-} __attribute__((packed));
+} __packed;
static void reload_gdt(void)
{
@@ -115,14 +115,14 @@ int x86_cpu_init_r(void)
reload_gdt();
/* Initialize core interrupt and exception functionality of CPU */
- cpu_init_interrupts ();
+ cpu_init_interrupts();
return 0;
}
int cpu_init_r(void) __attribute__((weak, alias(x86_cpu_init_r)));
int do_reset(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
{
- printf (resetting ...\n);
+ printf(resetting ...\n);
/* wait 50 ms */
udelay(5);
@@ -133,7 +133,7 @@ int do_reset(cmd_tbl_t *cmdtp, int flag, int argc, char *
const argv[])
return 0;
}
-void flush_cache (unsigned long dummy1, unsigned long dummy2)
+void flush_cache(unsigned long dummy1, unsigned long dummy2)
{
asm(wbinvd\n);
}
@@ -142,16 +142,16 @@ void __attribute__ ((regparm(0))) generate_gpf(void);
/* segment 0x70 is an arbitrary segment which does not exist */
asm(.globl generate_gpf\n
-.hidden generate_gpf\n
-.type generate_gpf, @function\n
-generate_gpf:\n
-ljmp $0x70, $0x47114711\n);
+ .hidden generate_gpf\n
+ .type generate_gpf, @function\n
+ generate_gpf:\n
+ ljmp $0x70, $0x47114711\n);
void __reset_cpu(ulong addr)
{
printf(Resetting using x86 Triple Fault\n);
- set_vector(13, generate_gpf); /* general protection fault handler */
- set_vector(8, generate_gpf); /* double fault handler */
- generate_gpf();/* start the show */
+ set_vector(13, generate_gpf); /* general protection fault handler */
+ set_vector(8, generate_gpf);/* double fault handler */
+ generate_gpf(); /* start the show */
}
void reset_cpu(ulong addr) __attribute__((weak, alias(__reset_cpu)));
diff --git a/arch/x86/cpu/interrupts.c b/arch/x86/cpu/interrupts.c
index 89f39d2..e007511 100644
--- a/arch/x86/cpu/interrupts.c
+++ b/arch/x86/cpu/interrupts.c
@@ -31,6 +31,7 @@
#include asm/interrupt.h
#include asm/io.h
#include asm/processor-flags.h
+#include linux/compiler.h
#define DECLARE_INTERRUPT(x) \
.globl irq_#x\n \
@@ -83,22 +84,22 @@ static inline unsigned long get_debugreg(int regno)
switch (regno) {
case 0:
- asm(mov %%db0, %0 :=r (val));
+ asm(mov %%db0, %0 : =r (val));
break;
case 1:
- asm(mov %%db1, %0 :=r (val));
+ asm(mov %%db1, %0 : =r (val));
break;
case 2:
- asm(mov %%db2, %0 :=r (val));
+ asm(mov %%db2, %0 : =r (val));
break;
case 3:
- asm(mov %%db3, %0 :=r (val));
+ asm(mov %%db3, %0 : =r (val));
break;
case 6:
- asm(mov %%db6, %0 :=r (val));
+ asm(mov %%db6, %0 : =r (val));
break;
case 7:
- asm(mov %%db7, %0 :=r (val));
+ asm(mov %%db7, %0 : =r (val));
break;
default:
val = 0;
@@ -120,7 +121,8 @@ void dump_regs(struct irq_regs *regs)
printf(ESI: %08lx EDI: %08lx EBP: %08lx ESP: %08lx\n,
regs-esi, regs-edi, regs-ebp, regs-esp);
printf( DS: %04x ES: %04x FS: %04x GS: %04x SS: %04x\n,
- (u16)regs-xds, (u16)regs-xes, (u16)regs-xfs, (u16)regs-xgs,
(u16)regs-xss);
+ (u16)regs-xds, (u16)regs-xes, (u16)regs-xfs,
+ (u16)regs-xgs, (u16)regs-xss);
cr0 = read_cr0();
cr2 = read_cr2();
@@ -164,13 +166,13 @@ struct idt_entry {
u8 res;
u8 access;
u16 base_high;
-} __attribute__ ((packed));
+} __packed;
struct desc_ptr {
unsigned short size;
unsigned long address;
unsigned short segment;
-} __attribute__((packed));
+} __packed;
struct idt_entry idt[256];
@@ -178,7 +180,7 @@ struct desc_ptr idt_ptr;
static inline void load_idt(const struct desc_ptr *dtr)
{
- asm volatile(cs lidt %0::m (*dtr));
+ asm volatile(cs lidt %0 : : m (*dtr));
}
void set_vector(u8 intnum, void *routine)
@@ -187,6 +189,11 @@ void set_vector(u8 intnum, void *routine)
idt[intnum].base_low = (u16)((u32)(routine) 0x);
}
+/*
+ * Ideally these would be defined static to avoid a checkpatch warning, but
+ * the compiler cannot see them in the inline asm and complains that they
+ * aren't defined
+ */
void irq_0(void);
void
[U-Boot] [PATCH v2 03/12] cosmetic: checkpatch cleanup of arch/x86/cpu/sc520/*.c
Signed-off-by: Graeme Russ graeme.r...@gmail.com
---
Changes for v2:
- Consolidated patch series
- Fixed remaining checkpatch warnings
- Removed references to CONFIG_SYS_SDRAM_ECC_ENABLE - This was never used
and never will be (sc520 is now end-of-life) and was generating
checkpatch errors because of the inline assembler
arch/x86/cpu/sc520/sc520.c |2 +-
arch/x86/cpu/sc520/sc520_pci.c | 24 ++---
arch/x86/cpu/sc520/sc520_sdram.c | 53 --
arch/x86/cpu/sc520/sc520_ssi.c | 43 +++---
arch/x86/cpu/sc520/sc520_timer.c |4 +-
5 files changed, 39 insertions(+), 87 deletions(-)
diff --git a/arch/x86/cpu/sc520/sc520.c b/arch/x86/cpu/sc520/sc520.c
index 4892c01..3fe85e7 100644
--- a/arch/x86/cpu/sc520/sc520.c
+++ b/arch/x86/cpu/sc520/sc520.c
@@ -49,7 +49,7 @@ int cpu_init_f(void)
asm(movl $0x2000, %%ecx\n
0: pushl %%ecx\n
popl %%ecx\n
- loop 0b\n: : : ecx);
+ loop 0b\n : : : ecx);
return x86_cpu_init_f();
}
diff --git a/arch/x86/cpu/sc520/sc520_pci.c b/arch/x86/cpu/sc520/sc520_pci.c
index e26793a..a13798f 100644
--- a/arch/x86/cpu/sc520/sc520_pci.c
+++ b/arch/x86/cpu/sc520/sc520_pci.c
@@ -70,26 +70,28 @@ int pci_sc520_set_irq(int pci_pin, int irq)
debug(set_irq(): map INT%c to IRQ%d\n, pci_pin + 'A', irq);
- if (irq 0 || irq 15) {
+ if (irq 0 || irq 15)
return -1; /* illegal irq */
- }
- if (pci_pin 0 || pci_pin 15) {
+ if (pci_pin 0 || pci_pin 15)
return -1; /* illegal pci int pin */
- }
/* first disable any non-pci interrupt source that use
* this level */
/* PCI interrupt mapping (A through D)*/
- for (i=0; i=3 ;i++) {
- if (readb(sc520_mmcr-pci_int_map[i]) ==
sc520_irq[irq].priority)
+ for (i = 0; i = 3 ; i++) {
+ tmpb = readb(sc520_mmcr-pci_int_map[i]);
+
+ if (tmpb == sc520_irq[irq].priority)
writeb(SC520_IRQ_DISABLED, sc520_mmcr-pci_int_map[i]);
}
/* GP IRQ interrupt mapping */
- for (i=0; i=10 ;i++) {
- if (readb(sc520_mmcr-gp_int_map[i]) ==
sc520_irq[irq].priority)
+ for (i = 0; i = 10 ; i++) {
+ tmpb = readb(sc520_mmcr-gp_int_map[i]);
+
+ if (tmpb == sc520_irq[irq].priority)
writeb(SC520_IRQ_DISABLED, sc520_mmcr-gp_int_map[i]);
}
@@ -102,10 +104,12 @@ int pci_sc520_set_irq(int pci_pin, int irq)
if (pci_pin 4) {
/* PCI INTA-INTD */
/* route the interrupt */
- writeb(sc520_irq[irq].priority,
sc520_mmcr-pci_int_map[pci_pin]);
+ writeb(sc520_irq[irq].priority,
+ sc520_mmcr-pci_int_map[pci_pin]);
} else {
/* GPIRQ0-GPIRQ10 used for additional PCI INTS */
- writeb(sc520_irq[irq].priority, sc520_mmcr-gp_int_map[pci_pin
- 4]);
+ writeb(sc520_irq[irq].priority,
+ sc520_mmcr-gp_int_map[pci_pin - 4]);
/* also set the polarity in this case */
tmpw = readw(sc520_mmcr-intpinpol);
diff --git a/arch/x86/cpu/sc520/sc520_sdram.c b/arch/x86/cpu/sc520/sc520_sdram.c
index 57e4e7d..9dc1334 100644
--- a/arch/x86/cpu/sc520/sc520_sdram.c
+++ b/arch/x86/cpu/sc520/sc520_sdram.c
@@ -40,9 +40,6 @@ static void sc520_set_dram_timing(void);
static void sc520_set_dram_refresh_rate(void);
static void sc520_enable_dram_refresh(void);
static void sc520_enable_sdram(void);
-#if CONFIG_SYS_SDRAM_ECC_ENABLE
-static void sc520_enable_ecc(void)
-#endif
int dram_init_f(void)
{
@@ -51,9 +48,6 @@ int dram_init_f(void)
sc520_set_dram_refresh_rate();
sc520_enable_dram_refresh();
sc520_enable_sdram();
-#if CONFIG_SYS_SDRAM_ECC_ENABLE
- sc520_enable_ecc();
-#endif
return 0;
}
@@ -426,53 +420,6 @@ static void sc520_sizemem(void)
writel(0x, sc520_mmcr-par[4]);
}
-#if CONFIG_SYS_SDRAM_ECC_ENABLE
-static void sc520_enable_ecc(void)
-
- /* A nominal memory test: just a byte at each address line */
- movl%eax, %ecx
- shrl$0x1, %ecx
- movl$0x1, %edi
-memtest0:
- movb$0xa5, (%edi)
- cmpb$0xa5, (%edi)
- jne out
- shrl$0x1, %ecx
- andl%ecx, %ecx
- jz set_ecc
- shll$0x1, %edi
- jmp memtest0
-
-set_ecc:
- /* clear all ram with a memset */
- movl%eax, %ecx
- xorl%esi, %esi
- xorl%edi, %edi
- xorl%eax, %eax
- shrl$0x2, %ecx
- cld
- rep stosl
-
- /* enable read, write buffers */
- movb$0x11, %al
- movl$DBCTL, %edi
- movb%al, (%edi)
-
- /* enable NMI mapping for ECC */
- movl
[U-Boot] [PATCH v2 05/12] cosmetic: checkpatch cleanup of board/eNET/*.c
Signed-off-by: Graeme Russ graeme.r...@gmail.com
---
Changes for v2:
- Consolidated patch series
board/eNET/eNET.c |8
board/eNET/eNET_pci.c | 19 +--
2 files changed, 13 insertions(+), 14 deletions(-)
diff --git a/board/eNET/eNET.c b/board/eNET/eNET.c
index c4ed820..429fe1b 100644
--- a/board/eNET/eNET.c
+++ b/board/eNET/eNET.c
@@ -223,7 +223,7 @@ void setup_pcat_compatibility()
* active low polarity on PIC interrupt pins,
* active high polarity on all other irq pins
*/
- writew(0x,sc520_mmcr-intpinpol);
+ writew(0x, sc520_mmcr-intpinpol);
/*
* PIT 0 - IRQ0
@@ -252,7 +252,7 @@ void setup_pcat_compatibility()
void enet_timer_isr(void)
{
- static long enet_ticks = 0;
+ static long enet_ticks;
enet_ticks++;
@@ -281,9 +281,9 @@ void hw_watchdog_reset(void)
void enet_toggle_run_led(void)
{
- unsigned char leds_state= inb(LED_LATCH_ADDRESS);
+ unsigned char leds_state = inb(LED_LATCH_ADDRESS);
if (leds_state LED_RUN_BITMASK)
- outb(leds_state ~ LED_RUN_BITMASK, LED_LATCH_ADDRESS);
+ outb(leds_state ~LED_RUN_BITMASK, LED_LATCH_ADDRESS);
else
outb(leds_state | LED_RUN_BITMASK, LED_LATCH_ADDRESS);
}
diff --git a/board/eNET/eNET_pci.c b/board/eNET/eNET_pci.c
index 29d13d2..5af4ef7 100644
--- a/board/eNET/eNET_pci.c
+++ b/board/eNET/eNET_pci.c
@@ -38,7 +38,7 @@ static void pci_enet_fixup_irq(struct pci_controller *hose,
pci_dev_t dev)
CONFIG_SYS_THIRD_PCI_IRQ,
CONFIG_SYS_FORTH_PCI_IRQ
};
- static int next_irq_index=0;
+ static int next_irq_index;
uchar tmp_pin;
int pin;
@@ -47,9 +47,8 @@ static void pci_enet_fixup_irq(struct pci_controller *hose,
pci_dev_t dev)
pin = tmp_pin;
pin -= 1; /* PCI config space use 1-based numbering */
- if (pin == -1) {
+ if (pin == -1)
return; /* device use no irq */
- }
/* map device number + pin to a pin on the sc520 */
switch (PCI_DEV(dev)) {
@@ -69,19 +68,19 @@ static void pci_enet_fixup_irq(struct pci_controller *hose,
pci_dev_t dev)
if (sc520_pci_ints[pin] == -1) {
/* re-route one interrupt for us */
- if (next_irq_index 3) {
+ if (next_irq_index 3)
return;
- }
- if (pci_sc520_set_irq(pin, irq_list[next_irq_index])) {
+
+ if (pci_sc520_set_irq(pin, irq_list[next_irq_index]))
return;
- }
+
next_irq_index++;
}
- if (-1 != sc520_pci_ints[pin]) {
- pci_hose_write_config_byte(hose, dev, PCI_INTERRUPT_LINE,
+ if (-1 != sc520_pci_ints[pin])
+ pci_hose_write_config_byte(hose, dev, PCI_INTERRUPT_LINE,
sc520_pci_ints[pin]);
- }
+
printf(fixup_irq: device %d pin %c irq %d\n,
PCI_DEV(dev), 'A' + pin, sc520_pci_ints[pin]);
}
--
1.7.5.2.317.g391b14
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 06/12] x86: Punt cold- and warm-boot flags
Nobody uses them anyway Signed-off-by: Graeme Russ graeme.r...@gmail.com --- Changes for v1: - None (skipped to set single version for consolidated series) Changes for v2: - Consolidated patch series arch/x86/cpu/start.S |2 -- arch/x86/cpu/start16.S |3 --- arch/x86/include/asm/global_data.h |2 -- 3 files changed, 0 insertions(+), 7 deletions(-) diff --git a/arch/x86/cpu/start.S b/arch/x86/cpu/start.S index 306fb49..1634eb1 100644 --- a/arch/x86/cpu/start.S +++ b/arch/x86/cpu/start.S @@ -53,8 +53,6 @@ _x86boot_start: movl%eax, %cr0 wbinvd - /* Tell 32-bit code it is being entered from an in-RAM copy */ - movw$GD_FLG_WARM_BOOT, %bx _start: /* This is the 32-bit cold-reset entry point */ diff --git a/arch/x86/cpu/start16.S b/arch/x86/cpu/start16.S index 9dabff2..33e53cd 100644 --- a/arch/x86/cpu/start16.S +++ b/arch/x86/cpu/start16.S @@ -37,9 +37,6 @@ .code16 .globl start16 start16: - /* Set the Cold Boot / Hard Reset flag */ - movl$GD_FLG_COLD_BOOT, %ebx - /* * First we let the BSP do some early initialization * this code have to map the flash to its final position diff --git a/arch/x86/include/asm/global_data.h b/arch/x86/include/asm/global_data.h index f177a4f..c736549 100644 --- a/arch/x86/include/asm/global_data.h +++ b/arch/x86/include/asm/global_data.h @@ -91,8 +91,6 @@ extern gd_t *gd; #defineGD_FLG_LOGINIT 0x00020 /* Log Buffer has been initialized */ #define GD_FLG_DISABLE_CONSOLE 0x00040 /* Disable console (in out) */ #define GD_FLG_ENV_READY 0x00080 /* Environment imported into hash table */ -#define GD_FLG_COLD_BOOT 0x00100 /* Cold Boot */ -#define GD_FLG_WARM_BOOT 0x00200 /* Warm Boot */ #if 0 #define DECLARE_GLOBAL_DATA_PTR -- 1.7.5.2.317.g391b14 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 04/12] cosmetic: checkpatch cleanup of arch/x86/lib/*.c
Signed-off-by: Graeme Russ graeme.r...@gmail.com --- Changes for v2: - Consolidated patch series - Fixed more warnings This patch has 23 checkpatch errors all associated with asm statements which checkpatch does not know how to deal with This patch has 3 checkpatch warnings, all of which are 'line over 80 characters' which: - One is caused by printf() strings which, IMHO, would have reduced readability if split - Two are due to calculations which could be shortened by converting the x86 zImage/bzImage header offsets into a structure (which should be done on principle anyway) - This is a big change prone to the introduction of bugs and will, therefore, be done later after the current x86 backlog stabilises arch/x86/include/asm/pci.h|3 + arch/x86/include/asm/realmode.h |4 + arch/x86/include/asm/u-boot-x86.h |8 ++ arch/x86/lib/bios.h | 201 ++--- arch/x86/lib/bios_pci.S | 92 -- arch/x86/lib/bios_setup.c | 93 +++-- arch/x86/lib/board.c | 114 ++--- arch/x86/lib/bootm.c | 23 ++-- arch/x86/lib/interrupts.c | 20 ++-- arch/x86/lib/pcat_interrupts.c|2 +- arch/x86/lib/pcat_timer.c | 37 arch/x86/lib/pci.c| 63 ++-- arch/x86/lib/pci_type1.c |9 +- arch/x86/lib/realmode.c | 20 ++-- arch/x86/lib/timer.c | 16 ++-- arch/x86/lib/video.c |6 +- arch/x86/lib/video_bios.c | 143 +++ arch/x86/lib/zimage.c | 94 ++ 18 files changed, 516 insertions(+), 432 deletions(-) diff --git a/arch/x86/include/asm/pci.h b/arch/x86/include/asm/pci.h index 85f60d7..c09078e 100644 --- a/arch/x86/include/asm/pci.h +++ b/arch/x86/include/asm/pci.h @@ -26,6 +26,9 @@ #ifndef _PCI_I386_H_ #define _PCI_I386_H_ 1 +#define DEFINE_PCI_DEVICE_TABLE(_table) \ + const struct pci_device_id _table[] + void pci_setup_type1(struct pci_controller* hose, u32 cfg_addr, u32 cfg_data); int pci_enable_legacy_video_ports(struct pci_controller* hose); int pci_shadow_rom(pci_dev_t dev, unsigned char *dest); diff --git a/arch/x86/include/asm/realmode.h b/arch/x86/include/asm/realmode.h index c62310e..0f12a89 100644 --- a/arch/x86/include/asm/realmode.h +++ b/arch/x86/include/asm/realmode.h @@ -25,6 +25,10 @@ #define __ASM_REALMODE_H_ #include asm/ptrace.h +extern ulong __realmode_start; +extern ulong __realmode_size; +extern char realmode_enter; + int bios_setup(void); int enter_realmode(u16 seg, u16 off, struct pt_regs *in, struct pt_regs *out); int enter_realmode_int(u8 lvl, struct pt_regs *in, struct pt_regs *out); diff --git a/arch/x86/include/asm/u-boot-x86.h b/arch/x86/include/asm/u-boot-x86.h index d3e2f4c..755f88a 100644 --- a/arch/x86/include/asm/u-boot-x86.h +++ b/arch/x86/include/asm/u-boot-x86.h @@ -24,6 +24,14 @@ #ifndef _U_BOOT_I386_H_ #define _U_BOOT_I386_H_1 +/* Exports from the Linker Script */ +extern ulong __text_start; +extern ulong __data_end; +extern ulong __rel_dyn_start; +extern ulong __rel_dyn_end; +extern ulong __bss_start; +extern ulong __bss_end; + /* cpu/.../cpu.c */ int x86_cpu_init_r(void); int cpu_init_r(void); diff --git a/arch/x86/lib/bios.h b/arch/x86/lib/bios.h index 4a9cdb5..a220983 100644 --- a/arch/x86/lib/bios.h +++ b/arch/x86/lib/bios.h @@ -24,69 +24,150 @@ #ifndef _BIOS_H_ #define _BIOS_H_ -#define OFFS_ES 0 /* 16bit */ -#define OFFS_GS 2 /* 16bit */ -#define OFFS_DS 4 /* 16bit */ -#define OFFS_EDI 6 /* 32bit */ -#define OFFS_DI 6 /* low 16 bits of EDI */ -#define OFFS_ESI 10/* 32bit */ -#define OFFS_SI 10/* low 16 bits of ESI */ -#define OFFS_EBP 14/* 32bit */ -#define OFFS_BP 14/* low 16 bits of EBP */ -#define OFFS_ESP 18/* 32bit */ -#define OFFS_SP 18/* low 16 bits of ESP */ -#define OFFS_EBX 22/* 32bit */ -#define OFFS_BX 22/* low 16 bits of EBX */ -#define OFFS_BL 22/* low 8 bits of BX */ -#define OFFS_BH 23/* high 8 bits of BX */ -#define OFFS_EDX 26/* 32bit */ -#define OFFS_DX 26/* low 16 bits of EBX */ -#define OFFS_DL 26/* low 8 bits of BX */ -#define OFFS_DH 27/* high 8 bits of BX */ -#define OFFS_ECX 30/* 32bit */ -#define OFFS_CX 30/* low 16 bits of EBX */ -#define OFFS_CL 30/* low 8 bits of BX */ -#define OFFS_CH 31/* high 8 bits of BX */ -#define OFFS_EAX 34/* 32bit */ -#define OFFS_AX 34/* low 16 bits of EBX */ -#define OFFS_AL 34/* low 8 bits of BX */ -#define OFFS_AH 35/* high 8 bits of BX */ -#define OFFS_VECTOR 38/* 16bit */ -#define OFFS_IP 40/* 16bit */ -#define OFFS_CS 42/* 16bit */ -#define OFFS_FLAGS 44/* 16bit */ +#define
[U-Boot] [PATCH v2 07/12] sc520: Create arch asm-offsets
Signed-off-by: Graeme Russ graeme.r...@gmail.com
---
Changes for v1:
- None (skipped to set single version for consolidated series)
Changes for v2:
- Consolidated patch series
arch/x86/cpu/sc520/asm-offsets.c| 45 +++
arch/x86/cpu/sc520/sc520_car.S |3 +-
arch/x86/cpu/start.S|3 +-
arch/x86/include/asm/arch-sc520/sc520.h | 26 --
arch/x86/include/asm/global_data.h | 19 -
board/eNET/eNET_start16.S |5 ++-
6 files changed, 52 insertions(+), 49 deletions(-)
create mode 100644 arch/x86/cpu/sc520/asm-offsets.c
diff --git a/arch/x86/cpu/sc520/asm-offsets.c b/arch/x86/cpu/sc520/asm-offsets.c
new file mode 100644
index 000..794f00c
--- /dev/null
+++ b/arch/x86/cpu/sc520/asm-offsets.c
@@ -0,0 +1,45 @@
+/*
+ * Adapted from Linux v2.6.36 kernel: arch/powerpc/kernel/asm-offsets.c
+ *
+ * This program is used to generate definitions needed by
+ * assembly language modules.
+ *
+ * We use the technique used in the OSF Mach kernel code:
+ * generate asm statements containing #defines,
+ * compile this file to assembler, and then extract the
+ * #defines from the assembly-language output.
+ *
+ * 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.
+ */
+
+#include common.h
+#include asm/arch/sc520.h
+
+#include linux/kbuild.h
+
+int main(void)
+{
+ DEFINE(GENERATED_GD_RELOC_OFF, offsetof(gd_t, reloc_off));
+
+ DEFINE(GENERATED_SC520_PAR0, offsetof(struct sc520_mmcr, par[0]));
+ DEFINE(GENERATED_SC520_PAR1, offsetof(struct sc520_mmcr, par[1]));
+ DEFINE(GENERATED_SC520_PAR2, offsetof(struct sc520_mmcr, par[2]));
+ DEFINE(GENERATED_SC520_PAR3, offsetof(struct sc520_mmcr, par[3]));
+ DEFINE(GENERATED_SC520_PAR4, offsetof(struct sc520_mmcr, par[4]));
+ DEFINE(GENERATED_SC520_PAR5, offsetof(struct sc520_mmcr, par[5]));
+ DEFINE(GENERATED_SC520_PAR6, offsetof(struct sc520_mmcr, par[6]));
+ DEFINE(GENERATED_SC520_PAR7, offsetof(struct sc520_mmcr, par[7]));
+ DEFINE(GENERATED_SC520_PAR8, offsetof(struct sc520_mmcr, par[8]));
+ DEFINE(GENERATED_SC520_PAR9, offsetof(struct sc520_mmcr, par[9]));
+ DEFINE(GENERATED_SC520_PAR10, offsetof(struct sc520_mmcr, par[10]));
+ DEFINE(GENERATED_SC520_PAR11, offsetof(struct sc520_mmcr, par[11]));
+ DEFINE(GENERATED_SC520_PAR12, offsetof(struct sc520_mmcr, par[12]));
+ DEFINE(GENERATED_SC520_PAR13, offsetof(struct sc520_mmcr, par[13]));
+ DEFINE(GENERATED_SC520_PAR14, offsetof(struct sc520_mmcr, par[14]));
+ DEFINE(GENERATED_SC520_PAR15, offsetof(struct sc520_mmcr, par[15]));
+
+ return 0;
+}
diff --git a/arch/x86/cpu/sc520/sc520_car.S b/arch/x86/cpu/sc520/sc520_car.S
index 7cac4d1..c04cc1f 100644
--- a/arch/x86/cpu/sc520/sc520_car.S
+++ b/arch/x86/cpu/sc520/sc520_car.S
@@ -24,6 +24,7 @@
#include config.h
#include asm/processor-flags.h
#include asm/arch/sc520.h
+#include generated/asm-offsets.h
.section .text
@@ -55,7 +56,7 @@ car_init:
/* Configure Cache-As-RAM PAR */
movl$CONFIG_SYS_SC520_CAR_PAR, %eax
- movl$SC520_PAR2, %edi
+ movl$(SC520_MMCR_BASE + GENERATED_SC520_PAR2), %edi
movl%eax, (%edi)
/* Trash the cache then turn it on */
diff --git a/arch/x86/cpu/start.S b/arch/x86/cpu/start.S
index 1634eb1..5adb387 100644
--- a/arch/x86/cpu/start.S
+++ b/arch/x86/cpu/start.S
@@ -30,6 +30,7 @@
#include version.h
#include asm/global_data.h
#include asm/processor-flags.h
+#include generated/asm-offsets.h
.section .text
.code32
@@ -112,7 +113,7 @@ relocate_code:
/* Setup call address of in-RAM copy of board_init_r() */
movl$board_init_r, %ebp
- addl(GD_RELOC_OFF * 4)(%edx), %ebp
+ addl(GENERATED_GD_RELOC_OFF)(%edx), %ebp
/* Setup parameters to board_init_r() */
movl%edx, %eax
diff --git a/arch/x86/include/asm/arch-sc520/sc520.h
b/arch/x86/include/asm/arch-sc520/sc520.h
index 5ac9bb8..9dc29d3 100644
--- a/arch/x86/include/asm/arch-sc520/sc520.h
+++ b/arch/x86/include/asm/arch-sc520/sc520.h
@@ -259,32 +259,6 @@ extern sc520_mmcr_t *sc520_mmcr;
/* Memory Mapped Control Registers (MMCR) Base Address */
#define SC520_MMCR_BASE0xfffef000
-/* MMCR Addresses (required for assembler code) */
-#define SC520_DRCCTL (SC520_MMCR_BASE + 0x010)
-#define SC520_DRCTMCTL (SC520_MMCR_BASE + 0x012)
-#define SC520_DRCCFG (SC520_MMCR_BASE + 0x014)
-#define SC520_DRCBENDADR (SC520_MMCR_BASE + 0x018)
-#define SC520_ECCCTL (SC520_MMCR_BASE + 0x020)
-#define SC520_DBCTL(SC520_MMCR_BASE + 0x040)
-#define SC520_ECCINT (SC520_MMCR_BASE + 0xd18)
-
-#define SC520_PAR0
[U-Boot] [PATCH v2 08/12] x86: Add multiboot header
By adding a multiboot header, U-Boot can be loaded by GRUB2. Using GRUB2 to bootstrap U-Boot is useful for using an existing BIOS to get an initial U-Boot port up and running before implementing the low-level reset vector code, SDRAM init, etc. and overwriting the BIOS Signed-off-by: Graeme Russ graeme.r...@gmail.com --- Changes for v1: - None (skipped to set single version for consolidated series) Changes for v2: - Consolidated patch series arch/x86/cpu/start.S | 20 1 files changed, 20 insertions(+), 0 deletions(-) diff --git a/arch/x86/cpu/start.S b/arch/x86/cpu/start.S index 5adb387..d099fc9 100644 --- a/arch/x86/cpu/start.S +++ b/arch/x86/cpu/start.S @@ -129,3 +129,23 @@ die: hlt blank_idt_ptr: .word 0 /* limit */ .long 0 /* base */ + + .p2align2 /* force 4-byte alignment */ + +multiboot_header: + /* magic */ + .long 0x1BADB002 + /* flags */ + .long (1 16) + /* checksum */ + .long -0x1BADB002 - (1 16) + /* header addr */ + .long multiboot_header - _x86boot_start + CONFIG_SYS_TEXT_BASE + /* load addr */ + .long CONFIG_SYS_TEXT_BASE + /* load end addr */ + .long 0 + /* bss end addr */ + .long 0 + /* entry addr */ + .long CONFIG_SYS_TEXT_BASE -- 1.7.5.2.317.g391b14 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 09/12] x86: Provide more configuration granularity
Planned future ports requires more granularity for some options
Signed-off-by: Graeme Russ graeme.r...@gmail.com
---
Changes for v1:
- None (skipped to set single version for consolidated series)
Changes for v2:
- Consolidated patch series
- Fixed checkpatch issues
- Removed non x86 modification to common/cmd_bdinfo.c
arch/x86/lib/Makefile | 18 +-
arch/x86/lib/board.c |9 +
arch/x86/lib/bootm.c |4 +++-
arch/x86/lib/pci.c| 36
arch/x86/lib/video_bios.c | 41 -
common/cmd_bdinfo.c |3 ++-
include/configs/eNET.h|5 +
7 files changed, 64 insertions(+), 52 deletions(-)
diff --git a/arch/x86/lib/Makefile b/arch/x86/lib/Makefile
index 71e94f7..eb5fa10 100644
--- a/arch/x86/lib/Makefile
+++ b/arch/x86/lib/Makefile
@@ -25,11 +25,11 @@ include $(TOPDIR)/config.mk
LIB= $(obj)lib$(ARCH).o
-SOBJS-y+= bios.o
-SOBJS-y+= bios_pci.o
-SOBJS-y+= realmode_switch.o
+SOBJS-$(CONFIG_SYS_PC_BIOS)+= bios.o
+SOBJS-$(CONFIG_SYS_PCI_BIOS) += bios_pci.o
+SOBJS-$(CONFIG_SYS_X86_REALMODE) += realmode_switch.o
-COBJS-y+= bios_setup.o
+COBJS-$(CONFIG_SYS_PC_BIOS)+= bios_setup.o
COBJS-y+= board.o
COBJS-y+= bootm.o
COBJS-y+= interrupts.o
@@ -37,11 +37,11 @@ COBJS-$(CONFIG_SYS_PCAT_INTERRUPTS) += pcat_interrupts.o
COBJS-$(CONFIG_SYS_GENERIC_TIMER) += pcat_timer.o
COBJS-$(CONFIG_PCI) += pci.o
COBJS-$(CONFIG_PCI) += pci_type1.o
-COBJS-y+= realmode.o
-COBJS-y+= timer.o
-COBJS-y+= video_bios.o
-COBJS-y+= video.o
-COBJS-y+= zimage.o
+COBJS-$(CONFIG_SYS_X86_REALMODE) += realmode.o
+COBJS-$(CONFIG_SYS_X86_ISR_TIMER) += timer.o
+COBJS-$(CONFIG_VIDEO) += video_bios.o
+COBJS-$(CONFIG_VIDEO) += video.o
+COBJS-$(CONFIG_CMD_ZBOOT) += zimage.o
SRCS := $(SOBJS-y:.o=.S) $(COBJS-y:.o=.c)
OBJS := $(addprefix $(obj),$(SOBJS-y) $(COBJS-y))
diff --git a/arch/x86/lib/board.c b/arch/x86/lib/board.c
index e8227b1..b445179 100644
--- a/arch/x86/lib/board.c
+++ b/arch/x86/lib/board.c
@@ -91,11 +91,13 @@ static int display_dram_config(void)
return 0;
}
+#ifndef CONFIG_SYS_NO_FLASH
static void display_flash_config(ulong size)
{
puts(Flash: );
print_size(size, \n);
}
+#endif
/*
* Breath some life into the board...
@@ -254,8 +256,12 @@ void board_init_f(ulong boot_flags)
void board_init_r(gd_t *id, ulong dest_addr)
{
+#if defined(CONFIG_CMD_NET)
char *s;
+#endif
+#ifndef CONFIG_SYS_NO_FLASH
ulong size;
+#endif
static bd_t bd_data;
static gd_t gd_data;
init_fnc_t **init_fnc_ptr;
@@ -287,10 +293,13 @@ void board_init_r(gd_t *id, ulong dest_addr)
#ifdef CONFIG_SERIAL_MULTI
serial_initialize();
#endif
+
+#ifndef CONFIG_SYS_NO_FLASH
/* configure available FLASH banks */
size = flash_init();
display_flash_config(size);
show_boot_progress(0x24);
+#endif
show_boot_progress(0x25);
diff --git a/arch/x86/lib/bootm.c b/arch/x86/lib/bootm.c
index 836803c..bac7b4f 100644
--- a/arch/x86/lib/bootm.c
+++ b/arch/x86/lib/bootm.c
@@ -35,7 +35,7 @@
int do_bootm_linux(int flag, int argc, char * const argv[],
bootm_headers_t *images)
{
- void*base_ptr;
+ void*base_ptr = NULL;
ulong os_data, os_len;
image_header_t *hdr;
@@ -73,8 +73,10 @@ int do_bootm_linux(int flag, int argc, char * const argv[],
goto error;
}
+#ifdef CONFIG_CMD_ZBOOT
base_ptr = load_zimage((void *)os_data, os_len,
images-rd_start, images-rd_end - images-rd_start, 0);
+#endif
if (NULL == base_ptr) {
printf(## Kernel loading failed ...\n);
diff --git a/arch/x86/lib/pci.c b/arch/x86/lib/pci.c
index f3018b7..286029e 100644
--- a/arch/x86/lib/pci.c
+++ b/arch/x86/lib/pci.c
@@ -151,3 +151,39 @@ int pci_shadow_rom(pci_dev_t dev, unsigned char *dest)
return res;
}
+
+#ifdef PCI_BIOS_DEBUG
+
+void print_bios_bios_stat(void)
+{
+ printf(16 bit functions:\n);
+ printf(pci_bios_present:%d\n,
+ RELOC_16_LONG(0xf000, num_pci_bios_present));
+ printf(pci_bios_find_device:%d\n,
+ RELOC_16_LONG(0xf000, num_pci_bios_find_device));
+ printf(pci_bios_find_class: %d\n,
+ RELOC_16_LONG(0xf000, num_pci_bios_find_class));
+ printf(pci_bios_generate_special_cycle: %d\n,
+ RELOC_16_LONG(0xf000,
+ num_pci_bios_generate_special_cycle));
+ printf(pci_bios_read_cfg_byte: %d\n,
+ RELOC_16_LONG(0xf000, num_pci_bios_read_cfg_byte));
+ printf(pci_bios_read_cfg_word: %d\n,
+
[U-Boot] [PATCH v2 10/12] x86: Ensure IDT and GDT remain 16-byte aligned post relocation
Some CPUs have strict alignment requirements for these tables
Signed-off-by: Graeme Russ graeme.r...@gmail.com
---
Changes for v1:
- None (skipped to set single version for consolidated series)
Changes for v2:
- Consolidated patch series
arch/x86/cpu/interrupts.c |2 +-
arch/x86/lib/board.c | 17 -
2 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/arch/x86/cpu/interrupts.c b/arch/x86/cpu/interrupts.c
index e007511..e0958eb 100644
--- a/arch/x86/cpu/interrupts.c
+++ b/arch/x86/cpu/interrupts.c
@@ -174,7 +174,7 @@ struct desc_ptr {
unsigned short segment;
} __packed;
-struct idt_entry idt[256];
+struct idt_entry idt[256] __attribute__((aligned(16)));
struct desc_ptr idt_ptr;
diff --git a/arch/x86/lib/board.c b/arch/x86/lib/board.c
index b445179..244a021 100644
--- a/arch/x86/lib/board.c
+++ b/arch/x86/lib/board.c
@@ -161,19 +161,26 @@ gd_t *gd;
static int calculate_relocation_address(void)
{
- void *text_start = __text_start;
- void *bss_end = __bss_end;
- void *dest_addr;
+ ulong text_start = (ulong)__text_start;
+ ulong bss_end = (ulong)__bss_end;
+ ulong dest_addr;
ulong rel_offset;
/* Calculate destination RAM Address and relocation offset */
- dest_addr = (void *)gd-ram_size;
+ dest_addr = gd-ram_size;
dest_addr -= CONFIG_SYS_STACK_SIZE;
dest_addr -= (bss_end - text_start);
+
+ /*
+* Round destination address down to 16-byte boundary to keep
+* IDT and GDT 16-byte aligned
+*/
+ dest_addr = ~15;
+
rel_offset = dest_addr - text_start;
gd-start_addr_sp = gd-ram_size;
- gd-relocaddr = (ulong)dest_addr;
+ gd-relocaddr = dest_addr;
gd-reloc_off = rel_offset;
return 0;
--
1.7.5.2.317.g391b14
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] [x86] Wrap small helper functions from libgcc to avoid an ABI mismatch
On Tuesday 08 November 2011 04:27:44 Gabe Black wrote: When gcc compiles some 64 bit operations on a 32 bit machine, it generates calls to small functions instead of instructions which do the job directly. Those functions are defined in libgcc and transparently provide whatever functionality was necessary. Unfortunately, u-boot can be built with a non-standard ABI when libgcc isn't. When the two are linked together, very confusing bugs can crop up, for instance seemingly normal integer division or modulus getting the wrong answer or even raising a spurious divide by zero exception. might be good to explicitly mention that this is due to u-boot using -mregparm --- a/arch/x86/config.mk +++ b/arch/x86/config.mk +LDSCRIPT := $(SRCTREE)/$(CPUDIR)/u-boot.lds looks like some old code sneaked in. bad rebase ? -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 11/12] x86: Misc PCI touchups
Signed-off-by: Graeme Russ graeme.r...@gmail.com
---
Changes for v1:
- None (skipped to set single version for consolidated series)
Changes for v2:
- Consolidated patch series
- Removed non x86 modification to drivers/pci/pci.c
arch/x86/cpu/sc520/sc520_pci.c |4 +---
arch/x86/include/asm/pci.h |2 +-
arch/x86/lib/pci_type1.c | 10 +++---
3 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/arch/x86/cpu/sc520/sc520_pci.c b/arch/x86/cpu/sc520/sc520_pci.c
index a13798f..52d07c1 100644
--- a/arch/x86/cpu/sc520/sc520_pci.c
+++ b/arch/x86/cpu/sc520/sc520_pci.c
@@ -130,9 +130,7 @@ void pci_sc520_init(struct pci_controller *hose)
hose-last_busno = 0xff;
hose-region_count = pci_set_regions(hose);
- pci_setup_type1(hose,
- SC520_REG_ADDR,
- SC520_REG_DATA);
+ pci_setup_type1(hose);
pci_register_hose(hose);
diff --git a/arch/x86/include/asm/pci.h b/arch/x86/include/asm/pci.h
index c09078e..37cc7e3 100644
--- a/arch/x86/include/asm/pci.h
+++ b/arch/x86/include/asm/pci.h
@@ -29,7 +29,7 @@
#define DEFINE_PCI_DEVICE_TABLE(_table) \
const struct pci_device_id _table[]
-void pci_setup_type1(struct pci_controller* hose, u32 cfg_addr, u32 cfg_data);
+void pci_setup_type1(struct pci_controller *hose);
int pci_enable_legacy_video_ports(struct pci_controller* hose);
int pci_shadow_rom(pci_dev_t dev, unsigned char *dest);
void pci_remove_rom_window(struct pci_controller* hose, u32 addr);
diff --git a/arch/x86/lib/pci_type1.c b/arch/x86/lib/pci_type1.c
index 6fc4df4..a25fa05 100644
--- a/arch/x86/lib/pci_type1.c
+++ b/arch/x86/lib/pci_type1.c
@@ -50,7 +50,11 @@ TYPE1_PCI_OP(write, byte, u8, outb, 3)
TYPE1_PCI_OP(write, word, u16, outw, 2)
TYPE1_PCI_OP(write, dword, u32, outl, 0)
-void pci_setup_type1(struct pci_controller *hose, u32 cfg_addr, u32 cfg_data)
+/* bus mapping constants (used for PCI core initialization) */
+#define PCI_REG_ADDR 0x0cf8
+#define PCI_REG_DATA 0x0cfc
+
+void pci_setup_type1(struct pci_controller *hose)
{
pci_set_ops(hose,
type1_read_config_byte,
@@ -60,6 +64,6 @@ void pci_setup_type1(struct pci_controller *hose, u32
cfg_addr, u32 cfg_data)
type1_write_config_word,
type1_write_config_dword);
- hose-cfg_addr = (unsigned int *)cfg_addr;
- hose-cfg_data = (unsigned char *)cfg_data;
+ hose-cfg_addr = (unsigned int *)PCI_REG_ADDR;
+ hose-cfg_data = (unsigned char *)PCI_REG_DATA;
}
--
1.7.5.2.317.g391b14
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 12/12] x86: Misc cleanups
Signed-off-by: Graeme Russ graeme.r...@gmail.com --- Changes for v1: - None (skipped to set single version for consolidated series) Changes for v2: - Consolidated patch series arch/x86/cpu/start.S |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/arch/x86/cpu/start.S b/arch/x86/cpu/start.S index d099fc9..f87633b 100644 --- a/arch/x86/cpu/start.S +++ b/arch/x86/cpu/start.S @@ -48,7 +48,7 @@ _x86boot_start: cli cld - /* Turn of cache (this might require a 486-class CPU) */ + /* Turn off cache (this might require a 486-class CPU) */ movl%cr0, %eax orl $(X86_CR0_NW | X86_CR0_CD), %eax movl%eax, %cr0 @@ -122,7 +122,8 @@ relocate_code: /* Jump to in-RAM copy of board_init_r() */ call*%ebp -die: hlt +die: + hlt jmp die hlt -- 1.7.5.2.317.g391b14 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] [PCI] Update pci_ids.h from current Linux sources
On Tuesday 08 November 2011 04:43:32 Gabe Black wrote: This change copies over the pci_ids.h file from Linux verbatim, plus a few ids that had been added by hand. to be clear, the few ids you refer to are already in u-boot and not something you're adding right ? -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 00/12] x86: Various cosmetic and minor code fixups
Of the patches, patch 4 (cosmetic: checkpatch cleanup of arch/x86/lib/*.c) has 23 checkpatch warnings all associated with asm statements which checkpatch does not know how to deal with, and 3 'line over 80 characters' warnings in x86/lib/zimage.c (see above) Oops, I meant to say all except #4 are checkpatch clean... Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] [driver][cfb] Make the software cursor non-destructive
On Tuesday 08 November 2011 03:59:29 Gabe Black wrote: When printing the string \r\n to the framebuffer console, the first character of the current line was being replaced with a space. The boot prompt would become the oot prompt. This change makes the cursor non-destructive so that no matter where it goes on its way to where it's supposed to be, the end result is that the cursor is where it's supposed to be with the other text preserved intact. preserved intact ... word for word verbose redundant ? ;) --- a/drivers/video/cfb_console.c +++ b/drivers/video/cfb_console.c /* * Cursor definition: * CONFIG_CONSOLE_CURSOR: Uses a timer function (see drivers/input/i8042.c) - * to let the cursor blink. Uses the macros - * CURSOR_OFF and CURSOR_ON. + * to let the cursor blink. is this intentional ? seems like the existing doc strings are fine ... @@ -248,9 +247,9 @@ -#define CURSOR_ON console_cursor(1) +#define CURSOR_ON console_cursor(1) unrelated whitespace change -#define CURSOR_ON -#define CURSOR_OFF video_putchar(console_col * VIDEO_FONT_WIDTH,\ - console_row * VIDEO_FONT_HEIGHT, ' ') +void console_cursor (int state); +#define CURSOR_ON console_cursor(1) +#define CURSOR_OFF console_cursor(0) #define CURSOR_SET video_set_cursor() so now the CONFIG_CONSOLE_CURSOR and CONFIG_VIDEO_SW_CURSOR code paths wrt CURSOR_* definitions are the same. seems like they should be unified. +static void video_invertchar (int xx, int yy) no space before that ( the rest looks fine to me, but let's CC the video maintainer ... -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] [x86] Don't relocate symbols which point to things that aren't relocated
On Tuesday 08 November 2011 02:08:42 Gabe Black wrote: This change adds an upper bound for symbols which are fixed up after u-boot is relocated into RAM. This way portions that are left at their original location can be referred to without having to manually fix up any pointers. i'm not familiar with the u-boot relocation handling on x86, but if a symbol shouldn't be relocated, then why does it have an elf reloc ? shouldn't it be an absolute symbol ? -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v0 0/4] env: reworking + default/import individual vars
Dear Gerlando, In message 4eb91abd.90...@keymile.com you wrote: The whole interface is wrong. I have just extendend env export to do a similar thing. The new syntax is: env export [-t | -b | -c] [-s size] addr [var ...] When/where? I can't see that in the latest master branch. Ah, I didn't actually send it yet. Done now. We should do exactly the same for env import, i. e. make the size parameter an option to be passed with -s size, and pass the names of any variables to import as additional arguments: env import [-t | -b | -c] [-s size] addr [var ...] This also greatly simplifies the implementation. Totally agree. Question is: won't that break all the existing scripts??? Yes. It _is_ an incompatible change of the API. I hate it, but mostly because I didn't chose such a format right from the beginning. My hope is that probably not too many people use these features in scripts - at least so far it's only omap3_beagle and omap3_mvblx that use env import -t $loadaddr $filesize. It is IMO better to change this now, instead of waiting until we have more users and the problem hits us in another place, hard. If you agree, I can post an updated patch with the same behavior for import. Although I am bit concerned about our scripts. We would fix these, too. But agreed, incompatible API changes are always a bad thing. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de About the use of language: it is impossible to sharpen a pencil with a blunt ax. It is equally vain to try to do it with ten blunt axes instead. -- Edsger Dijkstra ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add some missing endian conversions in fdt_support.c
+fdt maintainer On Tuesday 08 November 2011 04:05:32 Gabe Black wrote: Some functions in fdt_support.c use fdt_getprop to read 32 bit values out of the device tree, but then use them directly without doing any endian conversion. Because they check for a value that doesn't actually appear in practice, the functions continued to work even though they're incorrect. This change adds the missing conversions. Signed-off-by: Gabe Black gabebl...@chromium.org --- common/fdt_support.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/common/fdt_support.c b/common/fdt_support.c index bdda64d..c501604 100644 --- a/common/fdt_support.c +++ b/common/fdt_support.c @@ -61,7 +61,7 @@ u32 fdt_getprop_u32_default(void *fdt, const char *path, const char *prop, val = fdt_getprop(fdt, off, prop, NULL); if (val) - return *val; + return fdt32_to_cpu(*val); else return dflt; } @@ -372,7 +372,7 @@ static int get_cells_len(void *blob, char *nr_cells_name) const u32 *cell; cell = fdt_getprop(blob, 0, nr_cells_name, NULL); - if (cell *cell == 2) + if (cell fdt32_to_cpu(*cell) == 2) return 8; return 4; signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] [fdt] Fix constness of the fdt void pointer in fdt_getprop_u32_default
+fdt maintainer
On Tuesday 08 November 2011 04:09:44 Gabe Black wrote:
The function fdt_getprop_u32_default doesn't modify the fdt, so it can use
a const void * for its fdt argument.
Signed-off-by: Gabe Black gabebl...@chromium.org
---
common/fdt_support.c |4 ++--
include/fdt_support.h |4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/common/fdt_support.c b/common/fdt_support.c
index bdda64d..bd3a014 100644
--- a/common/fdt_support.c
+++ b/common/fdt_support.c
@@ -49,8 +49,8 @@ DECLARE_GLOBAL_DATA_PTR;
* Convenience function to find a node and return it's property or a
* default value if it doesn't exist.
*/
-u32 fdt_getprop_u32_default(void *fdt, const char *path, const char *prop,
- const u32 dflt)
+u32 fdt_getprop_u32_default(const void *fdt, const char *path,
+ const char *prop, const u32 dflt)
{
const u32 *val;
int off;
diff --git a/include/fdt_support.h b/include/fdt_support.h
index c7b4605..cef3c65 100644
--- a/include/fdt_support.h
+++ b/include/fdt_support.h
@@ -28,8 +28,8 @@
#include fdt.h
-u32 fdt_getprop_u32_default(void *fdt, const char *path, const char *prop,
- const u32 dflt);
+u32 fdt_getprop_u32_default(const void *fdt, const char *path,
+ const char *prop, const u32 dflt);
int fdt_chosen(void *fdt, int force);
int fdt_initrd(void *fdt, ulong initrd_start, ulong initrd_end, int
force); void do_fixup_by_path(void *fdt, const char *path, const char
*prop,
signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] [x86] [zboot] Change printf to puts to avoid a buffer overflow
Acked-by: Mike Frysinger vap...@gentoo.org -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Import the glibc implementation of x86 memset into u-boot
i'd tweak the summary to be something like: [x86] import the glibc memset implementation otherwise, Acked-by: Mike Frysinger vap...@gentoo.org -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] [build] Automatically build the device tree if DEV_TREE_SEPARATE is set
On Tuesday 08 November 2011 04:15:32 Gabe Black wrote: This change makes the u-boot all target build the separate device tree if DEV_TREE_SEPARATE is set. This use of DEV_TREE_SEPARATE is consistent with the one other use in the u-boot build system. It's at least expedient and perhaps necessary to build the device tree this way since it's difficult to know the value of $(obj) when invoking make. i don't see anyone else using DEV_TREE_SEPARATE. we already have CONFIG_OF_SEPARATE which causes the .dtb to be generated. Simon: any idea what's up ? -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 06/12] x86: Punt cold- and warm-boot flags
Acked-by: Mike Frysinger vap...@gentoo.org -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] mvgbe: fix network device indices
On Tuesday 08 November 2011 02:32:59 Prafulla Wadaskar wrote: On some boards, using mvbge random mac generation is needed since there is no eeprom to hold this. Further practically it is not possible to hardcode mac address and recompile, nor it is suggested to have any mac/ip/server address definition in board config files. Random mac address helps to resolve dhcp issues with more similar boards in the same network in such cases and will be applicable for any board. Your patch is clean to abstract out mac randomization, on the other hand you should not remove the support for other boards which are already using it. May be some more patches on the top to move support in board/arch specific files are needed. (if framework can not be entertained) i'm not the one to convince. i think Wolfgang addressed these already and still said no. -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mvgbe: remove setting of ethaddr within the driver
On Monday 07 November 2011 17:08:09 Michael Walle wrote: drivers/net/mvgbe.c| 23 --- ACK to the changes to this file --- a/include/configs/edminiv2.h +++ b/include/configs/edminiv2.h +#define CONFIG_ETH_ADDR 02:50:43:00:00:01 NAK to this. board configs are not allow to hardcode MACs. -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mvgbe: remove setting of ethaddr within the driver
On Tuesday 08 November 2011 02:18:20 Prafulla Wadaskar wrote: Here are my suggestions- 1. commond/random_mac.c should be added 2. call back function should be provided to generate random number, those should be defined in arch specific code (for Kirkwood arch-kirkwood/cpu.c) 3. mac randomization should be enabled by CONFIG_SYS_LOCAL_MAC_RANDOMIZATION macro 4. For mvgbe uses it should be enabled by default in include/configs/mv-common.h. 5. for corner case like edminiv2, in should be undefed in board config file 6. Some documentation should be supported for this generic framework. i think Wolfgang already NAK-ed this idea. but he'd have to clarify. -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/3] ARM: vexpress: add support for A5 core tile
Hi Albert,
Thanks for looking at my patches.
I'm not sure exactly what you mean, so I'll explain that I am doing
here and see if that help resolve the issue you are seeing, if not,
hopefully you'll have more info to help clarify.
The first patch is simply moving and renaming files in preparation for
me adding A5 support in a later patch. So, the ca9x4_ct_vxp platform
is renamed to vexpress_common. You can still build it, it's just
named funny. You would build it with make ...
vexpress_common_config. I did this because I wanted the first patch
to only contain file moves and renames without changing any code, in
the hope that it would be easier to review. Perhaps I failed in that
goal!
The next patch then adds a new config file so that the board is named
as the more friendly vexpress_ca9x4 and you can no longer build a
vexpress_common board.
The final patch then adds a further config for A5 and makes some
changes for the RS1 memory map.
I hope this clarifies what I've done. Please ask more questions or
make suggestions to help improve my patch sequence.
Regards,
Ryan.
On 5 November 2011 05:57, Albert ARIBAUD albert.u.b...@aribaud.net wrote:
Le 18/10/2011 14:41, Ryan Harkin a écrit :
Add support for the A5 Core Tile on the Versatile Express motherboard.
Ryan Harkin (3):
ARM: vexpress: move files in preparation for adding a new platform
ARM: vexpress: create A9 specific board config
ARM: vexpress: create A5 specific board config
MAINTAINERS | 3 +-
board/armltd/vexpress/Makefile | 2 +-
.../vexpress/{ca9x4_ct_vxp.c = vexpress_common.c} | 29 ++-
boards.cfg | 3 +-
include/configs/ca9x4_ct_vxp.h | 206 -
include/configs/vexpress_ca5x2.h | 34 +++
include/configs/vexpress_ca9x4.h | 34 +++
include/configs/vexpress_common.h | 314
8 files changed, 410 insertions(+), 215 deletions(-)
rename board/armltd/vexpress/{ca9x4_ct_vxp.c = vexpress_common.c} (90%)
delete mode 100644 include/configs/ca9x4_ct_vxp.h
create mode 100644 include/configs/vexpress_ca5x2.h
create mode 100644 include/configs/vexpress_ca9x4.h
create mode 100644 include/configs/vexpress_common.h
The series is not bisectable in that board ca9x4_ct_vxp disappears in patch
1/3 to reappear in patch 2/3. Please reorganize patch set so that common
files are extracted without preventing ca9x4_ct_vxp from building.
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v0 0/4] env: reworking + default/import individual vars
Hi, On 11/08/2011 01:47 PM, Wolfgang Denk wrote: env import [-t | -b | -c] [-s size] addr [var ...] This also greatly simplifies the implementation. Totally agree. Question is: won't that break all the existing scripts??? Yes. It _is_ an incompatible change of the API. I hate it, but mostly because I didn't chose such a format right from the beginning. My hope is that probably not too many people use these features in scripts - at least so far it's only omap3_beagle and omap3_mvblx that use env import -t $loadaddr $filesize. It is IMO better to change this now, instead of waiting until we have more users and the problem hits us in another place, hard. we use it too in keymile-common.h and in the scripts we load with this command e.g. board/keymile/scripts/develop-ppc_82xx.txt The resulting incompatibility is indeed not very nice. I don't see big issues for the command line and keymile-common.h where we can live with different API for different u-boot versions. But the usage in the scripts directory is more complicated, because then we have to make sure that uboot version x loads scripts x and u-boot version y loads scripts y. Ok we could prepare a second scripts directory e.g. scripts_v2 or similar in addition to the current scripts directory in tftpboot, but this is not very nice. Best regards Holger ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] fsl_i2c: Fix compile warning
fsl_i2c.c: In function 'i2c_init':
fsl_i2c.c:245:7: warning: assignment discards qualifiers from pointer target
type
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
drivers/i2c/fsl_i2c.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/i2c/fsl_i2c.c b/drivers/i2c/fsl_i2c.c
index 258be0a..5b017a9 100644
--- a/drivers/i2c/fsl_i2c.c
+++ b/drivers/i2c/fsl_i2c.c
@@ -225,7 +225,7 @@ unsigned int get_i2c_clock(int bus)
void
i2c_init(int speed, int slaveadd)
{
- struct fsl_i2c *dev;
+ const struct fsl_i2c *dev;
unsigned int temp;
int bus_num, i;
--
1.7.3.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mvgbe: remove setting of ethaddr within the driver
Am Di, 8.11.2011, 14:57 schrieb Mike Frysinger: On Monday 07 November 2011 17:08:09 Michael Walle wrote: drivers/net/mvgbe.c| 23 --- ACK to the changes to this file --- a/include/configs/edminiv2.h +++ b/include/configs/edminiv2.h +#define CONFIG_ETH_ADDR 02:50:43:00:00:01 NAK to this. board configs are not allow to hardcode MACs. mh, so why is there a CONFIG_ETH_ADDR macro? is it deprecated? README.enetaddr explicitly refers to that config option. -- michael ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Allow for parallel builds and saved output
On Nov 3, 2011, at 11:22 AM, Simon Glass wrote:
Hi Andy,
On Thu, Nov 3, 2011 at 12:28 AM, Andy Fleming aflem...@freescale.com wrote:
The MAKEALL script cleverly runs make with the appropriate options
to use all of the cores on the system, but your average U-Boot build
can't make much use of more than a few cores. If you happen to have
a many-core server, your builds will leave most of the system idle.
In order to make full use of such a system, we need to build multiple
targets in parallel, and this requires directing make output into
multiple directories. We add a BUILD_NBUILDS variable, which allows
users to specify how many builds to run in parallel. I've found that
16 is too many on my system (fork starts to fail). When BUILD_NBUILDS
is set greater than 1, we redefine BUILD_DIR for each build to be
${BUILD_DIR}/${target}. Also, we make ./build the default BUILD_DIR
when BUILD_NBUILDS is greater than 1.
Once each build finishes, we run make clean on its directory, to reduce
the footprint, and also remove all .depend files.
As a result, we are left with a build directory with all of the built
targets still there for use, which means anyone who wanted to use
MAKEALL as part of a test harness can now do so.
Signed-off-by: Andy Fleming aflem...@freescale.com
---
Inspired by all the MAKEALL improvements, I decided to clean up my old
one for parallel builds. I think this version addresses the concerns
raised last time...
I see an issue if I have a build in working tree already. I think we might
need a distclean before starting
I also it seems this does things in clumps of BUILD_NBUILDS. What I mean is,
if BUILD_NBUILDS is 4, you do 4 and wait for all 4 to finish before starting
the 5th job once the 1st is complete. Anything we can do about that to always
try and have 4 builds going until the end?
- k
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mvgbe: remove setting of ethaddr within the driver
On Tuesday 08 November 2011 08:45:27 Michael Walle wrote: Am Di, 8.11.2011, 14:57 schrieb Mike Frysinger: On Monday 07 November 2011 17:08:09 Michael Walle wrote: --- a/include/configs/edminiv2.h +++ b/include/configs/edminiv2.h +#define CONFIG_ETH_ADDR 02:50:43:00:00:01 NAK to this. board configs are not allow to hardcode MACs. mh, so why is there a CONFIG_ETH_ADDR macro? is it deprecated? README.enetaddr explicitly refers to that config option. it's a useful debug knob -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Please pull u-boot-ti/master
The following changes since commit c686537f34268ffd6d87e3b8b14d1118b221a995:
David Müller (ELSOFT AG) (1):
ARM: re-add MACH_TYPE_XX for VCMA9 board and add CONFIG_MACH_TYPE
are available in the git repository at:
git://git.denx.de/u-boot-ti.git master
Christian Riesch (3):
arm, davinci: Rename AM1808 lowlevel functions to DA850
arm, davinci: Remove the duplication of LPSC functions
arm, davinci: Fix setting of the SDRAM configuration register
Manjunath Hadli (2):
dm646x: add new configuration for dm6467T
dm646x: pass board revision info to kernel
Prabhakar Lad (1):
da8xxevm: fix build error
arch/arm/cpu/arm926ejs/davinci/Makefile|2 +-
.../{am1808_lowlevel.c = da850_lowlevel.c}| 223 +++-
.../{am1808_lowlevel.h = da850_lowlevel.h}| 26 ++--
arch/arm/include/asm/arch-davinci/hardware.h |1 +
board/davinci/dm6467evm/dm6467evm.c| 20 ++
boards.cfg |1 +
include/configs/davinci_dm6467Tevm.h | 163 ++
include/configs/davinci_dm6467evm.h|1 +
8 files changed, 274 insertions(+), 163 deletions(-)
rename arch/arm/cpu/arm926ejs/davinci/{am1808_lowlevel.c = da850_lowlevel.c}
(56%)
rename arch/arm/include/asm/arch-davinci/{am1808_lowlevel.h =
da850_lowlevel.h} (63%)
create mode 100644 include/configs/davinci_dm6467Tevm.h
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mvgbe: remove setting of ethaddr within the driver
Dear Mike Frysinger, In message 20080858.25678.vap...@gentoo.org you wrote: 3. mac randomization should be enabled by CONFIG_SYS_LOCAL_MAC_RANDOMIZATION macro 4. For mvgbe uses it should be enabled by default in include/configs/mv-common.h. 5. for corner case like edminiv2, in should be undefed in board config file 6. Some documentation should be supported for this generic framework. i think Wolfgang already NAK-ed this idea. but he'd have to clarify. Indeed I did NAK this. And I tried to provide an explantion why I consider this an inherently broken approach. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Love your country but never trust its government. - from a hand-painted road sign in central Pennsylvania ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 7/7] omap5: Add omap5_evm board build support.
Hi Tom, One thing it's better to do #define CONFIG_FOO rather than #define CONFIG_FOO 1. Sorry for the late reply, i was on vacation. I agree with your comments. I will send a V2 for this and your other comment. Hi Sricharan, I don't believe I saw a v2... if you do send a v2, please send all your patches including the spl patches. Regards, Sandeep ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 7/7] omap5: Add omap5_evm board build support.
Hi sandeep, I am in the process of making the V2. I will send it with all the patches together. Thanks, Sricharan On Tue, Nov 8, 2011 at 7:49 PM, Paulraj, Sandeep s-paul...@ti.com wrote: Hi Tom, One thing it's better to do #define CONFIG_FOO rather than #define CONFIG_FOO 1. Sorry for the late reply, i was on vacation. I agree with your comments. I will send a V2 for this and your other comment. Hi Sricharan, I don't believe I saw a v2... if you do send a v2, please send all your patches including the spl patches. Regards, Sandeep ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/3] image: Allow images to indicate they're loadable at any address
On Tue, 8 Nov 2011, Wolfgang Denk wrote: In message alpine.lfd.2.02.071840080.3...@xanadu.home you wrote: I understand you are referring here to zImages only. Correct? Correct. Anything else is not relocatable. Or will raw images (without the preloader) be fully relocatable, too? No. OK. So the situation on ARM is basicly not different from what we have on other architectures. The uImage format has been designed to handle this situation: we normally wrap the raw image (eventually after compressing it) into an uImage, and insert the load and entry point addresses that are well known at kernel build time. uImages are not directly executable. zImages on ARM include a preloader, that wraps the the raw image (eventually after compressing it) and packs it together with some code that internally accounts for the fixed load and entry point addresses of the kernel which implements the needed relocation and uncompression routines to form a new executable, position independent format. In both cases the _kernel_ image is not position independent. It must be loaded to a specific address and started at a specific entry point. The exact information where these are is known at built time, and somehow encoded in the images (here in the image header, there in the preloader code). Is this summary correct so far? No. Your statement that says The exact information where these are is known at built time, and somehow encoded in the images (here in the image header, there in the preloader code) is false. None of that information is known at build time nor encoded in the preloader as you call it. Why is it so important to load it at specific (different) addresses when it can be started from any address? The kernel code can be started from any address. We want the _code_ to be that way. This is not quite correct. The _kernel_ code has a fixed address. It is the preloader code which can be started from any address. The preloader is part of the kernel, whether you like it or not, and it is not going away any time soon. That would help the conversation if you accepted it as such. However a particular board may or may not load the kernel at any address. This is a machine specific restriction, not a kernel restriction. Correct. Stephen Warren also writes in 4eb87122.3050...@nvidia.com: Presumably whoever constructed the environment has the most detailed knowledge of the HW's and U-Boot environment's expected memory layout for that particular board. And in 4eb87375.1040...@nvidia.com: The only place that has full knowledge of the board's memory layout is the U-Boot environment for that board, and hence I assert that the U-Boot environment should define where to load the kernel (and initrd and FDT), and if U-Boot must copy them, where to copy them to. In particular, the creator of the uImage can't possibly pick these values and expect them to work everywhere. I mostly agree with this. That's the reason why U-Boot offers to handle this based on a better understanding of the low level hardware details. This seems to me to be an easier way that to handle this in the Linux kernel environment (in the form of the preloader). You are mixing up issues. The bootloader has knowledge of where is the best place to load kernel images on a per machine basis. This is why the zImage code was made to accept and execute from any address in order to give the bootloader any possible flexibility in that regard. However it is the kernel's responsibility to deal with its own environment and change it at will when we see fit, and therefore this is best if the bootloader doesn't take any responsibility here. Maybe this is a key point. I simply fail to understand this. Let me repeat again. We want one single kernel image binary that ARM distributions can use for all their target machines. It is therefore necessary that uImage be free of any hardcoded load address (absolute or relative). If a particular board require a particular load address for the kernel, this must be encoded in its own u-Boot environment and not in the distributed uImage. Failing that, uImage simply cannot be used as a distribution format for the kernel because any address/offset enforced by the uImage format is going to be incompatible with the needs of a particular machine somewhere. uImage is _intented_ to carry a raw OS image and provide the boot loader the information where to load and start it. You do not want to do that, so you should not attempt to assault uImages to make it fit your completely different purposes. If you want to use relocatable zImages which have all the needed information encoded internally then just do so. But do not insist that uImage does things it was not designed for. OK, fine. I don't really care about uImage if it cannot accommodate our needs. I thought that the -1 extension
Re: [U-Boot] [PATCH 7/7] omap5: Add omap5_evm board build support.
Hi sandeep, I am in the process of making the V2. I will send it with all the patches together. Thanks, Sricharan ok ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/3] image: Allow images to indicate they're loadable at any address
On Mon, Nov 07, 2011, Simon Glass wrote: How can we give U-Boot what it wants, which is apparently the ability to decompress the kernel itself and arrange everything in memory at the right place? Wolfgang complains that patches to do this have been repeatedly rejected in the kernel. If this is the FIT image, how about adding a 'fitImage' make target? Looking at this thread from the point of view of distributions (e.g. Debian/Fedora/Ubuntu etc.), I see some integration disadvantages in the FIT image approach and to uImage in general. The format itself is nice and handy, but in an ideal world a distribution would provide a SoC-agnostic image, and even a bootloader-agnostic image. Currently, what Debian and Ubuntu do (didn't check Fedora) is: * ship zImage files (vmlinuz-*) in kernel .deb packages * when kernels or initrd related files are installed, generate: - uImage from the right vmlinuz file with the exact load value - an initrd.gz with initramfs-tools, then an uInitrd from it - a boot script for that board, then a boot.scr from it which is an U-Boot script in uImage format This is painful in at least these ways: a) images are not board-agnostic or even bootloader agnostic (I'd love if a single SD card image would boot on multiple OMAP3 boards, or on OMAP3 and OMAP4, or on i.MX51, i.MX53, OMAP3 and OMAP4, whether the firmware uses U-Boot or is just a boot ROM, or UEFI or whatever) b) distributors keep track of load addresses for uImage/uInitrd/boot.scr as to generate correct uImages c) this wastes space for multiple copies of the boot files (uImage + uInitrd + boot.scr + vmlinuz + initrd.gz) I can see how the proposal to use relative load addresses or to set -1 as load address in uImage help with some of the above, but for sure c) will remain a hard issue with FIT images as some distributors will keep generating an initrd when various packages get installed (e.g. for LVM or mdadm support, or encrypted root etc.). There are advantages to the uImage format such as usage in flash, or choice of compression type (whatever you stuff into it), and these remain valid in other use cases, but it seems sensible to support vmlinuz directly from U-Boot to support a more generic distro image boot protocol. Personally, I also like the separation of layers so that vmlinuz is kept opaque; for instance vmlinuz can embed an initrd or a DTB without the bootloader having to care about them, or it could be compressed with LZO or bzip2 even if the bootloader in firmware doesn't support this or that compression type. I think distros would prefer not using these features and having a DTB-aware bootloader though. -- Loïc Minier ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/5] powerpc/85xx: fix definition of MAS register macros
On Oct 31, 2011, at 1:30 PM, Timur Tabi wrote: Some of the MAS register macros do not protect the parameter with parentheses, which could cause wrong values if the parameter includes operators. Also fix the definition of TSIZE_TO_BYTES() so that it actually uses the parameter. This hasn't caused any problems to date because the parameter was always been 'tsize'. Signed-off-by: Timur Tabi ti...@freescale.com --- arch/powerpc/include/asm/mmu.h | 10 +- 1 files changed, 5 insertions(+), 5 deletions(-) applied to 85xx - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/5] powerpc/85xx: fix some comments in the CCSR relocation code
On Oct 31, 2011, at 1:30 PM, Timur Tabi wrote: Signed-off-by: Timur Tabi ti...@freescale.com --- arch/powerpc/cpu/mpc85xx/start.S |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) applied to 85xx - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/9] powerpc/mpc8548cds: Fix network initialization
On Sep 13, 2011, at 2:15 AM, Zhao Chenhui wrote: From: chenhui zhao chenhui.z...@freescale.com Add board_eth_init(). PCIe network card is also supported. Put RGMII init after tsec_eth_init(). Skip initializing eTSEC3 and eTSEC4 with Carrier boards prior to ver 1.3. Signed-off-by: Ebony Zhu ebony@freescale.com Signed-off-by: Zhao Chenhui chenhui.z...@freescale.com --- board/freescale/mpc8548cds/mpc8548cds.c | 65 +++--- include/configs/MPC8548CDS.h|2 + 2 files changed, 60 insertions(+), 7 deletions(-) applied to 85xx - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/5] powerpc/85xx: verify the current address of CCSR before relocating it
On Oct 31, 2011, at 1:30 PM, Timur Tabi wrote: Verify that CCSR is actually located where it is supposed to be before we relocate it. This is useful in detecting U-Boot configurations that are broken (e.g. an incorrect value for CONFIG_SYS_CCSRBAR_DEFAULT). If the current value is wrong, we enter an infinite loop, which is handy for debuggers. Signed-off-by: Timur Tabi ti...@freescale.com --- arch/powerpc/cpu/mpc85xx/start.S | 27 +++ 1 files changed, 27 insertions(+), 0 deletions(-) applied to 85xx - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/5] powerpc/85xx: resize the boot page TLB before relocating CCSR
On Oct 31, 2011, at 1:30 PM, Timur Tabi wrote: On some Freescale systems (e.g. those booted from the on-chip ROM), the TLB that covers the boot page can also cover CCSR, which breaks the CCSR relocation code. To fix this, we resize the boot page TLB so that it only covers the 4KB boot page. Signed-off-by: Timur Tabi ti...@freescale.com --- arch/powerpc/cpu/mpc85xx/start.S | 49 ++ 1 files changed, 49 insertions(+), 0 deletions(-) applied to 85xx - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/5] powerpc/85xx: add some missing sync instructions in the CCSR relocation code
On Oct 31, 2011, at 1:30 PM, Timur Tabi wrote: Calls to tlbwe and tlbsx should be preceded with an isync/msync pair. Signed-off-by: Timur Tabi ti...@freescale.com --- arch/powerpc/cpu/mpc85xx/start.S |4 1 files changed, 4 insertions(+), 0 deletions(-) applied to 85xx - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/3] image: Make image_get_fdt work like image_get_{ram_disk, kernel}
On Sat, Nov 05, 2011, Marek Vasut wrote: this patchset is good and all, but can we not also introduce cmd_zload to load zImages? Wolfgang, today's ARM hardware will really benefit from that, uImage holds us back a lot these days. Other option is to extend cmd_bootm() to load zImages. Other architectures like x86 and sh seem to use zboot, perhaps we should stick to zboot for all architectures rather than introducing bootm -z or bootz? AFAIK the file formats are slightly different per architecture, but the U-Boot cmdline usage would be the same. -- Loïc Minier ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/9] powerpc/mpc8548: Add workaround for erratum NMG_eTSEC129
On Sep 13, 2011, at 2:15 AM, Zhao Chenhui wrote: From: chenhui zhao chenhui.z...@freescale.com Erratum NMG_eTSEC129 (eTSEC86 in MPC8548 document) applies to some early verion silicons. This workaround detects if the eTSEC Rx logic is properly initialized, and reinitialize the eTSEC Rx logic. Signed-off-by: Gong Chen g.c...@freescale.com Signed-off-by: Zhao Chenhui chenhui.z...@freescale.com --- arch/powerpc/cpu/mpc85xx/cmd_errata.c |4 + arch/powerpc/include/asm/config_mpc85xx.h |1 + drivers/net/tsec.c| 93 + 3 files changed, 98 insertions(+), 0 deletions(-) applied to 85xx - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/85xx: Add support for Book-E MMU Arch v2.0
On Oct 31, 2011, at 10:16 PM, Kumar Gala wrote: A few of the config registers changed definition between MMU v1.0 and MMUv2.0. The new e6500 core from Freescale implements v2.0 of the architecture. Specifically, how we determine the size of TLB entries we support in the variable size (or TLBCAM/TLB1) array is specified in a new register (TLBnPS - TLB n Page size) instead of via TLBnCFG. Signed-off-by: Kumar Gala ga...@kernel.crashing.org --- arch/powerpc/cpu/mpc85xx/tlb.c | 12 arch/powerpc/include/asm/processor.h |6 ++ 2 files changed, 14 insertions(+), 4 deletions(-) applied to 85xx - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fsl_ifc:Fixed a bug in the erratum handling code for IFC_A003399
On Nov 1, 2011, at 8:28 AM, Poonam Aggrwal wrote: Wrong pointer was being used to copy code into L2SRAM. Also removed the unreferenced variable l2srbar. Signed-off-by: Poonam Aggrwal poonam.aggr...@freescale.com --- Thanks Wolfgang and Kumar for identifying the issue. arch/powerpc/cpu/mpc85xx/cpu_init_early.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) applied to 85xx - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] QorIQ: fix network frame manager TBI PHY address settings
On Oct 28, 2011, at 12:15 AM, Roy Zang wrote: TBI PHY address (TBIPA) register has been set in general frame manager phy init funciton dtsec_init_phy() in drivers/net/fm/eth.c So remove the duplicate code on QorIQ frame manager Ethernet related platforms, which include Hydra board, P4080DS board and P2041rdb board. Signed-off-by: Roy Zang tie-fei.z...@freescale.com Cc: Andy Fleming aflem...@freescale.com Cc: Kumar Gala ga...@kernel.crashing.org --- v2: refine the subject and description according to feedback board/freescale/corenet_ds/eth_hydra.c |8 board/freescale/corenet_ds/eth_p4080.c |8 board/freescale/p2041rdb/eth.c |8 3 files changed, 0 insertions(+), 24 deletions(-) applied to 85xx - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/3] image: Allow images to indicate they're loadable at any address
Nicolas,
On Mon, Nov 07, 2011 at 10:51:33PM -0500, Nicolas Pitre wrote:
On Mon, 7 Nov 2011, Simon Glass wrote:
On Mon, Nov 7, 2011 at 4:35 PM, Nicolas Pitre n...@fluxnic.net wrote:
On Tue, 8 Nov 2011, Wolfgang Denk wrote:
Dear Nicolas Pitre,
We don't want any hardcoded architecture specific address anymore.
This is being removed from the kernel as we speak. If I cannot use a
Also for raw images?
No. The requirements on raw images are unchanged. you can use them if
you wish, but generic ARM distributions can't use that if they want to
target more than one SOC. Therefore raw images are not interesting by
the use case at hand.
I will leave you to your discussion, but want to pick up on this point.
Can I assume that we have (or can have) a 'make uImage' target or
similar in the kernel which can pack together:
- a compressed kernel (not zImage, I mean something that U-Boot can
decompress), with a rel_offset of 32KB
Yes.
- a DTB
No.
- a ramdisk
No. However you can provide a set of files which can be included in an
initramfs image linked directly into the kernel. But distributors never
use that facility as they prefer a customized ramdisk created during
kernel installation.
exactly, see my comments below.
and that with Stephen's patch (committed to U-Boot) today, we can, in
U-Boot, with a script, load this uImage to somewhere and have U-Boot
decompress the kernel and set the bits out nicely in RAM, no matter
where that RAM is? The kernel will start at 32KB, and the other bits
will be somewhere above that. Then U-Boot can enter the kernel at 32KB
and all will be well, yes?
Because it seems to me that this approach would work just as well as
the zImage approach (it is perhaps more 'pure' from a boot loader
point of view), and that the code in the kernel zImage header that
figures out where SDRAM is and decompresses the kernel to 32KB could
just as well be in U-Boot.
Firstly, there is not just u-Boot out there. And since the layout
optimization for Linux when decompressing is by definition Linux
specific, this better live in zImage than be duplicated in every
bootloaders.
Secondly, we don't want to pack a DTB with the kernel. For the same
reasons as for the load address, we want a distributable kernel binary
which contains no assumption about any specific board or machine. The
kernel should be generic and be provided a machine specific DTB by the
boot loader.
Then both groups get what they want.
No. For both groups to get what they want, Stephen's latest patches
should be merged. All they do is to allow for -1 as a load address in
uImage to mean never relocate but just use whatever address where
uImage has been loaded. This cannot be simpler than that.
It sounds like you are intending for distributions to provide uImages.
Why can't they provide a generic zImage, and a post-install hook runs
mkimage to add the board specific uImage header? Similar to update-grub
on x86{_64}. This seems _more_ flexible to me, and fitting with
standard conventions distributions are accustomed to.
eg, after a kernel upgrade on a debian system, since I had 'apt-get
install u-boot' there is a post-kernel install hook that would run a
distro provided 'update-uboot' script. This script would read a board
specific config file (or, the u-boot environment), add the u-boot header
to the kernel, and possibly modify the u-boot environment to now load
uImage-3.1-34. The file shipped with the kernel image package was a
generic zImage which will now work on the board.
Or, maybe I'm missing something... I always thought 'make uImage' was
a convenience for developers.
hth,
Jason.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/3] image: Allow images to indicate they're loadable at any address
On Tue, 8 Nov 2011, Wolfgang Denk wrote: In message alpine.lfd.2.02.071840080.3...@xanadu.home you wrote: I understand you are referring here to zImages only. Correct? Correct. Anything else is not relocatable. Or will raw images (without the preloader) be fully relocatable, too? No. OK. So the situation on ARM is basicly not different from what we have on other architectures. [...] I already NAKed these patches, and this discussion has made it clear to me that this was a correct decision. What you want is not uImages. You are therefore denying me the ability to use the kernel according to the use case I care about. Maybe I should reconsider my willingness to let you use raw kernel image then? Because if you are not willing to collaborate for the case I care about, why should I care about yours? Nicolas Nico, will it be OK if we/you implemented bootz command to boot zImages? Will that be satifying for you? I understand Wolfgang isn't oposed to such solution. M ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 07/12] OMAP3 SPL: Rework memory initalization and devkit8000 support
On 11/08/2011 12:06 AM, Igor Grinberg wrote:
Hi Tom,
On 11/07/11 22:05, Tom Rini wrote:
This changes to making the board be responsible for providing the
memory initialization timings in SPL and converts the devkit8000
to this framework. In SPL we try and initialize both CS0 and CS1.
Cc: Frederik Kriewitz frede...@kriewitz.eu
Signed-off-by: Tom Rini tr...@ti.com
---
arch/arm/cpu/armv7/omap3/sdrc.c | 28
++
arch/arm/include/asm/arch-omap3/mem.h | 26 -
arch/arm/include/asm/arch-omap3/sys_proto.h |1 +
board/timll/devkit8000/devkit8000.c | 21
include/configs/devkit8000.h|4 ---
5 files changed, 37 insertions(+), 43 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap3/sdrc.c
b/arch/arm/cpu/armv7/omap3/sdrc.c
index 2756024..a27b4b1 100644
--- a/arch/arm/cpu/armv7/omap3/sdrc.c
+++ b/arch/arm/cpu/armv7/omap3/sdrc.c
@@ -148,6 +148,18 @@ void do_sdrc_init(u32 cs, u32 early)
sdrc_actim_base0 = (struct sdrc_actim *)SDRC_ACTIM_CTRL0_BASE;
sdrc_actim_base1 = (struct sdrc_actim *)SDRC_ACTIM_CTRL1_BASE;
+/*
+ * When called in the early context this may be SPL and we will
+ * need to set all of the timings. This ends up being board
+ * specific so we call a helper function to take care of this
+ * for us. Otherwise, to be safe, we need to copy the settings
+ * from the first bank to the second. We will setup CS0,
+ * then set cs_cfg to the appropriate value then try and
+ * setup CS1.
+ */
+#ifdef CONFIG_SPL_BUILD
+get_board_mem_timings(mcfg, ctrla, ctrlb, rfr_ctrl, mr);
+#endif
if (early) {
/* reset sdrc controller */
writel(SOFTRESET, sdrc_base-sysconfig);
@@ -164,22 +176,12 @@ void do_sdrc_init(u32 cs, u32 early)
writel(ENADLL | DLLPHASE_90, sdrc_base-dlla_ctrl);
sdelay(0x2);
-/* As long as V_MCFG and V_RFR_CTRL is not defined for all OMAP3 boards we
need
- * to prevent this to be build in non-SPL build */
#ifdef CONFIG_SPL_BUILD
-/*
- * If we use a SPL there is no x-loader nor config header so
- * we have to do the job ourselfs
- */
-
-mcfg = V_MCFG;
-ctrla = V_ACTIMA_165;
-ctrlb = V_ACTIMB_165;
-rfr_ctrl = V_RFR_CTRL;
-mr = V_MR;
-
write_sdrc_timings(CS0, sdrc_actim_base0, mcfg, ctrla, ctrlb,
rfr_ctrl, mr);
+make_cs1_contiguous();
+write_sdrc_timings(CS0, sdrc_actim_base1, mcfg, ctrla, ctrlb,
+rfr_ctrl, mr);
#endif
}
diff --git a/arch/arm/include/asm/arch-omap3/mem.h
b/arch/arm/include/asm/arch-omap3/mem.h
index a3c..8c6dc3f 100644
--- a/arch/arm/include/asm/arch-omap3/mem.h
+++ b/arch/arm/include/asm/arch-omap3/mem.h
@@ -198,32 +198,6 @@ enum {
(NUMONYX_XSR_165 0) | (NUMONYX_TXP_165 8) | \
(NUMONYX_TWTR_165 16))
-#ifdef CONFIG_OMAP3_INFINEON_DDR
-#define V_ACTIMA_165 INFINEON_V_ACTIMA_165
-#define V_ACTIMB_165 INFINEON_V_ACTIMB_165
-#endif
-
-#ifdef CONFIG_OMAP3_MICRON_DDR
-#define V_ACTIMA_165MICRON_V_ACTIMA_165
-#define V_ACTIMB_165MICRON_V_ACTIMB_165
-#define V_MCFG MICRON_V_MCFG_165
-#define V_RFR_CTRL SDP_3430_SDRC_RFR_CTRL_165MHz
-#define V_MRMICRON_V_MR_165
-#endif
-
-#ifdef CONFIG_OMAP3_NUMONYX_DDR
-#define V_ACTIMA_165 NUMONYX_V_ACTIMA_165
-#define V_ACTIMB_165 NUMONYX_V_ACTIMB_165
-#endif
-
-#if !defined(V_ACTIMA_165) || !defined(V_ACTIMB_165)
-#error Please choose the right DDR type in config header
-#endif
-
-#if defined(CONFIG_SPL_BUILD) (!defined(V_MCFG) || !defined(V_RFR_CTRL))
-#error Please choose the right DDR type in config header
-#endif
-
/*
* GPMC settings -
* Definitions is as per the following format
diff --git a/arch/arm/include/asm/arch-omap3/sys_proto.h
b/arch/arm/include/asm/arch-omap3/sys_proto.h
index 9e64410..a53d205 100644
--- a/arch/arm/include/asm/arch-omap3/sys_proto.h
+++ b/arch/arm/include/asm/arch-omap3/sys_proto.h
@@ -38,6 +38,7 @@ void per_clocks_enable(void);
void memif_init(void);
void sdrc_init(void);
void do_sdrc_init(u32, u32);
+void get_board_mem_timings(u32 *, u32 *, u32 *, u32 *, u32 *);
This is kind of API declaration, so it is not obvious what
values it takes and what should be the order of values here.
Can this declaration also have variable names, so one would
not have to look at the function call to understand what values
should be supplied and what is the order?
Not a problem, just following existing style, but I'll change it (and
identify_pop_memory()). for v2
--
Tom
___
U-Boot mailing list
U-Boot@lists.denx.de
Re: [U-Boot] [PATCH] mvgbe: remove setting of ethaddr within the driver
Dear Michael Walle, In message 89e599b8867346f857ae2f132e9717a3.squir...@ssl.serverraum.org you wrote: +#define CONFIG_ETH_ADDR 02:50:43:00:00:01 NAK to this. board configs are not allow to hardcode MACs. mh, so why is there a CONFIG_ETH_ADDR macro? is it deprecated? README.enetaddr explicitly refers to that config option. There are situations where it cannot be helped, like when programming the U-Boot image into a ROM (yes, a real ROM that cannot be changed any more by software alone). But in almost all normal situations this must not be used. In any case, we will not accept it into mainline. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Be kind to unkind people - they need it the most. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 08/12] OMAP3 SPL: Add identify_pop_memory function
On 11/08/2011 12:45 AM, Igor Grinberg wrote:
On 11/07/11 22:05, Tom Rini wrote:
A number of boards are populated with a PoP chip for both DDR and NAND
memory. So to determine DDR timings the NAND chip needs to be probed
and mfr/id returned to the board to make decisions with. All of this
code is put into spl_pop_probe.c and controlled via
CONFIG_SPL_OMAP3_POP_PROBE.
I don't see how POP is different from other types of packages
in terms of DRAM.
The same thing can be true also for non-POP packages.
What I'm saying here is, I understand the necessity of that code,
but why call it POP specific?
If it is not POP specific, then please call it some other way
(e.g. ...DRAM_NAND_PROBE).
Also, hypothetically, some other means can be used for DRAM type
identification, so it will be a good thing to split it, but again
it is only hypothetically and it is only my thoughts, so you don't
have to...
Well, that gets at why I called it spl_pop_probe. If you have a POP
package, this is how you would do the probe. I can see in theory
wanting to probe NAND as a way to see board rev on a non-POP package,
but I'd like to see a real example first.
diff --git a/arch/arm/cpu/armv7/omap3/Makefile
b/arch/arm/cpu/armv7/omap3/Makefile
index 8e85891..772f3d4 100644
--- a/arch/arm/cpu/armv7/omap3/Makefile
+++ b/arch/arm/cpu/armv7/omap3/Makefile
@@ -31,6 +31,9 @@ COBJS += board.o
COBJS += clock.o
COBJS += mem.o
COBJS += sys_info.o
+ifdef CONFIG_SPL_BUILD
+COBJS-$(CONFIG_SPL_OMAP3_POP_PROBE) += spl_pop_probe.o
+endif
Can't CONFIG_SPL_OMAP3_..._PROBE symbol default to no
and depend on CONFIG_SPL_BUILD, so you don't need to enclose
it in #ifdef?
But then it would build for both SPL and non-SPL cases.
[snip]
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
The address is subject to change so probably it will be
a good thing to drop the address part (but leave the rest).
Just following existing examples.
+ */
+
+#include common.h
+#include linux/mtd/nand.h
+#include asm/io.h
+#include asm/arch/sys_proto.h
+#include asm/arch/mem.h
+
+#ifdef CONFIG_SPL_BUILD
no need for this #ifdef, the whole file compilation depends
on that symbol being defined.
True, will fix, thanks.
+static struct gpmc *gpmc_config = (struct gpmc *)GPMC_BASE;
+
+/* nand_command: Send a flash command to the flash chip */
+static void nand_command(u8 command)
+{
+writeb(command, gpmc_config-cs[0].nand_cmd);
+
+if (command == NAND_CMD_RESET) {
+unsigned char ret_val;
+nand_command(NAND_CMD_STATUS);
This recursion looks redundant.
Why not just replace it with:
writeb(NAND_CMD_STATUS, gpmc_config-cs[0].nand_cmd);
OK, thanks.
+do {
+/* Wait until ready */
+ret_val = readl(gpmc_config-cs[0].nand_dat);
+} while ((ret_val 0x40) != 0x40);
Can't 0x40 magic be defined to have some more understandable name?
Probably kind of NAND_CMD_READY mask?
I'll see if the datasheet defines this particular bit of magic.
+}
+}
+
+/*
+ * Many boards ship with a PoP chip of both NAND and DDR, so we need
+ * probe the NAND side, very earily, to see what it says and pass this
s/earily/early/
Thanks.
+ * along to the board. The board code will then use this information
+ * to decide what DDR timings to use.
+ */
+void identify_pop_memory(int *mfr, int *id)
+{
+/* Make sure that we have setup GPMC for NAND correctly. */
+writel(M_NAND_GPMC_CONFIG1, gpmc_config-cs[0].config1);
+writel(M_NAND_GPMC_CONFIG2, gpmc_config-cs[0].config2);
+writel(M_NAND_GPMC_CONFIG3, gpmc_config-cs[0].config3);
+writel(M_NAND_GPMC_CONFIG4, gpmc_config-cs[0].config4);
+writel(M_NAND_GPMC_CONFIG5, gpmc_config-cs[0].config5);
+writel(M_NAND_GPMC_CONFIG6, gpmc_config-cs[0].config6);
+
+/* Enable the GPMC Mapping */
+writelGPMC_SIZE_128M 0xF) 8) | ((NAND_BASE 24) 0x3F) |
+(1 6)), gpmc_config-cs[0].config7);
+
+sdelay(2000);
+
+/* Issue a RESET and then READID */
+nand_command(NAND_CMD_RESET);
+nand_command(NAND_CMD_READID);
+
+writeb(0x0, gpmc_config-cs[0].nand_adr);
It would be nice to have a comment, why the above is needed.
OK.
--
Tom
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 09/12] OMAP3: Add SPL support to Beagleboard
On 11/08/2011 12:57 AM, Igor Grinberg wrote:
On 11/07/11 22:05, Tom Rini wrote:
This introduces 200MHz Micron parts timing information based on x-loader
to asm/arch-omap3/mem.h. The memory init logic is also based on what
x-loader does in these cases. Note that while previously u-boot would
be flashed in with SW ECC in this case it now must be flashed with HW
ECC.
[snip]
+#ifdef CONFIG_SPL_BUILD
+/*
+ * Routine: board_early_sdrc_init
s/board_early_sdrc_init/get_board_mem_timings/
+ * Description: If we use SPL then there is no x-loader nor config header
+ * so we have to setup the DDR timings outself on both banks.
s/outself/ourself/
Thanks.
[snip]
+case REVISION_C4:
+if ((pop_mfr == NAND_MFR_STMICRO) (pop_id == 0xba)) {
No need for extra parenthesis.
I'll double check all these cases, thanks.
+*mcfg = 0x04590099;
+*ctrla = NUMONYX_V_ACTIMA_165;
+*ctrlb = NUMONYX_V_ACTIMB_165;
+*rfr_ctrl = SDP_3430_SDRC_RFR_CTRL_165MHz;
This will look much better if it will be aligned.
It's not in CodingStyle tho ;)
[snip]
-# For use with external or internal boots.
-CONFIG_SYS_TEXT_BASE = 0x80008000
Removing needless crap is a very good thing, but does not
belong to this patch, is it?
I thought I said in this commit message, but I know I did for am3517
evm/crane, we change CONFIG_SYS_TEXT_BASE which is why we remove this
file here. It could be done as a two-step if it's a hard objection tho.
--
Tom
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
