[U-Boot] [PATCH] [v2] p1022ds: allow for board-specific ngPIXIS functions
The ngPIXIS is an FPGA used on the reference boards of most Freescale PowerPC
SOCs. Although programming the ngPIXIS is mostly standard on all boards that
have it, the P1022DS is unique in that the ngPIXIS needs to be programmed in
indirect mode whenever the video display (DIU) is active.
To support indirect mode, and to make it easier to support other quirks on
future reference boards, the low-level ngPIXIS functions are all marked as
weak, so that board-specific code can override any of them. We take advantage
of this feature on the P1022DS, so that we can properly reset the board when
the DIU is active.
Signed-off-by: Timur Tabi ti...@freescale.com
---
board/freescale/common/ngpixis.c | 56
board/freescale/common/ngpixis.h |8 -
board/freescale/p1022ds/diu.c| 66 --
3 files changed, 112 insertions(+), 18 deletions(-)
diff --git a/board/freescale/common/ngpixis.c b/board/freescale/common/ngpixis.c
index a135fbe..4e01e5a 100644
--- a/board/freescale/common/ngpixis.c
+++ b/board/freescale/common/ngpixis.c
@@ -1,5 +1,5 @@
/**
- * Copyright 2010 Freescale Semiconductor
+ * Copyright 2010-2011 Freescale Semiconductor
* Author: Timur Tabi ti...@freescale.com
*
* This program is free software; you can redistribute it and/or modify it
@@ -35,61 +35,89 @@
#include common.h
#include command.h
-#include watchdog.h
-#include asm/cache.h
#include asm/io.h
#include ngpixis.h
+static u8 __pixis_read(unsigned int reg)
+{
+ void *p = (void *)PIXIS_BASE;
+
+ return in_8(p + reg);
+}
+u8 pixis_read(unsigned int reg) __attribute__((weak, alias(__pixis_read)));
+
+static void __pixis_write(unsigned int reg, u8 value)
+{
+ void *p = (void *)PIXIS_BASE;
+
+ out_8(p + reg, value);
+}
+void pixis_write(unsigned int reg, u8 value)
+ __attribute__((weak, alias(__pixis_write)));
+
/*
* Reset the board. This ignores the ENx registers.
*/
-void pixis_reset(void)
+void __pixis_reset(void)
{
- out_8(pixis-rst, 0);
+ PIXIS_WRITE(rst, 0);
while (1);
}
+void pixis_reset(void) __attribute__((weak, alias(__pixis_reset)));
/*
* Reset the board. Like pixis_reset(), but it honors the ENx registers.
*/
-void pixis_bank_reset(void)
+void __pixis_bank_reset(void)
{
- out_8(pixis-vctl, 0);
- out_8(pixis-vctl, 1);
+ PIXIS_WRITE(vctl, 0);
+ PIXIS_WRITE(vctl, 1);
while (1);
}
+void pixis_bank_reset(void) __attribute__((weak, alias(__pixis_bank_reset)));
/**
* Set the boot bank to the power-on default bank
*/
-void clear_altbank(void)
+void __clear_altbank(void)
{
+ u8 reg;
+
/* Tell the ngPIXIS to use this the bits in the physical switch for the
* boot bank value, instead of the SWx register. We need to be careful
* only to set the bits in SWx that correspond to the boot bank.
*/
- clrbits_8(PIXIS_EN(PIXIS_LBMAP_SWITCH), PIXIS_LBMAP_MASK);
+ reg = PIXIS_READ(s[PIXIS_LBMAP_SWITCH - 1].en);
+ reg = ~PIXIS_LBMAP_MASK;
+ PIXIS_WRITE(s[PIXIS_LBMAP_SWITCH - 1].en, reg);
}
+void clear_altbank(void) __attribute__((weak, alias(__clear_altbank)));
/**
* Set the boot bank to the alternate bank
*/
-void set_altbank(void)
+void __set_altbank(void)
{
+ u8 reg;
+
/* Program the alternate bank number into the SWx register.
*/
- clrsetbits_8(PIXIS_SW(PIXIS_LBMAP_SWITCH), PIXIS_LBMAP_MASK,
-PIXIS_LBMAP_ALTBANK);
+ reg = PIXIS_READ(s[PIXIS_LBMAP_SWITCH - 1].sw);
+ reg = (reg ~PIXIS_LBMAP_MASK) | PIXIS_LBMAP_ALTBANK;
+ PIXIS_WRITE(s[PIXIS_LBMAP_SWITCH - 1].sw, reg);
/* Tell the ngPIXIS to use this the bits in the SWx register for the
* boot bank value, instead of the physical switch. We need to be
* careful only to set the bits in SWx that correspond to the boot bank.
*/
- setbits_8(PIXIS_EN(PIXIS_LBMAP_SWITCH), PIXIS_LBMAP_MASK);
+ reg = PIXIS_READ(s[PIXIS_LBMAP_SWITCH - 1].en);
+ reg |= PIXIS_LBMAP_MASK;
+ PIXIS_WRITE(s[PIXIS_LBMAP_SWITCH - 1].en, reg);
}
+void set_altbank(void) __attribute__((weak, alias(__set_altbank)));
int pixis_reset_cmd(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
diff --git a/board/freescale/common/ngpixis.h b/board/freescale/common/ngpixis.h
index 089408b..681b0d0 100644
--- a/board/freescale/common/ngpixis.h
+++ b/board/freescale/common/ngpixis.h
@@ -1,5 +1,5 @@
/**
- * Copyright 2010 Freescale Semiconductor
+ * Copyright 2010-2011 Freescale Semiconductor
* Author: Timur Tabi ti...@freescale.com
*
* This program is free software; you can redistribute it and/or modify it
@@ -55,3 +55,9 @@ typedef struct ngpixis {
/* The PIXIS EN register that corresponds to board switch X, where x = 1 */
#define PIXIS_EN(x)(pixis-s[(x) - 1].en)
+
+u8 pixis_read(unsigned int reg);
+void pixis_write
[U-Boot] powerpc-linux-gnu-ld: Warning: lib_powerpc/fpu/libpostpowerpcfpu.o uses hard float, libpost.o uses soft float
I'm trying to build Kumar's repository, and I'm getting this error. Is anyone
else seeing this?
$ make P4080DS_config
awk '(NF $1 !~ /^#/) { print $1 : $1 _config; $(MAKE) }' boards.cfg
.boards.depend
Configuring for P4080DS board...
$ make -s
powerpc-linux-gnu-ld: Warning: lib_powerpc/fpu/libpostpowerpcfpu.o uses hard
float, libpost.o uses soft float
--
Timur Tabi
Linux kernel developer at Freescale
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] powerpc-linux-gnu-ld: Warning: lib_powerpc/fpu/libpostpowerpcfpu.o uses hard float, libpost.o uses soft float
Scott Wood wrote: I'm not sure what you mean by Kumar's repository (u-boot-mpc85xx.git?), Yes. but there hasn't been a lib_powerpc for a while now. Then what's this: http://git.denx.de/?p=u-boot/u-boot-mpc85xx.git;a=tree;f=post/lib_powerpc;h=0cccba6be270011a259aef734f2637e8d72ec7a1;hb=master Assuming you're trying to build a current tree in a workspace that hasn't been used in a while, try make clean, or possbly git clean -f -x -d to be really sure. This is from a freshly cloned tree. I'm running git bisect now. 2010.12-rc1 works -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH][v1] Fix wrong CONFIG_SYS_MPC85xx_SERDES1_ADDR
On Mon, Jan 17, 2011 at 12:40 AM, Prabhakar prabha...@freescale.com wrote: CONFIG_SYS_MPC85xx_SERDES1_ADDR was defined wrong as CONFIG_SYS_IMMR + CONFIG_SYS_MPC85xx_SERDES2_OFFSET. It should be as CONFIG_SYS_IMMR + CONFIG_SYS_MPC85xx_SERDES1_OFFSET. Signed-off-by: Prabhakar prabha...@freescale.com Please resubmit this patch using your full name in the signed-off-by line. -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] p1022ds: allow for board-specific ngPIXIS functions
The ngPIXIS is an FPGA used on the reference boards of most Freescale PowerPC
SOCs. Although programming the ngPIXIS is mostly standard on all boards that
have it, the P1022DS is unique in that the ngPIXIS needs to be programmed in
indirect mode whenever the video display (DIU) is active.
To support indirect mode, and to make it easier to support other quirks on
future reference boards, the low-level ngPIXIS functions are all marked as
weak, so that board-specific code can override any of them. We take advantage
of this feature on the P1022DS, so that we can properly reset the board when
the DIU is active.
Signed-off-by: Timur Tabi ti...@freescale.com
---
board/freescale/common/ngpixis.c | 54
board/freescale/common/ngpixis.h |6 +++
board/freescale/p1022ds/diu.c| 64 -
3 files changed, 109 insertions(+), 15 deletions(-)
diff --git a/board/freescale/common/ngpixis.c b/board/freescale/common/ngpixis.c
index a135fbe..a432e33 100644
--- a/board/freescale/common/ngpixis.c
+++ b/board/freescale/common/ngpixis.c
@@ -35,61 +35,89 @@
#include common.h
#include command.h
-#include watchdog.h
-#include asm/cache.h
#include asm/io.h
#include ngpixis.h
+static u8 __pixis_read(unsigned int reg)
+{
+ void *p = (void *)PIXIS_BASE;
+
+ return in_8(p + reg);
+}
+u8 pixis_read(unsigned int reg) __attribute__((weak, alias(__pixis_read)));
+
+static void __pixis_write(unsigned int reg, u8 value)
+{
+ void *p = (void *)PIXIS_BASE;
+
+ out_8(p + reg, value);
+}
+void pixis_write(unsigned int reg, u8 value)
+ __attribute__((weak, alias(__pixis_write)));
+
/*
* Reset the board. This ignores the ENx registers.
*/
-void pixis_reset(void)
+void __pixis_reset(void)
{
- out_8(pixis-rst, 0);
+ PIXIS_WRITE(rst, 0);
while (1);
}
+void pixis_reset(void) __attribute__((weak, alias(__pixis_reset)));
/*
* Reset the board. Like pixis_reset(), but it honors the ENx registers.
*/
-void pixis_bank_reset(void)
+void __pixis_bank_reset(void)
{
- out_8(pixis-vctl, 0);
- out_8(pixis-vctl, 1);
+ PIXIS_WRITE(vctl, 0);
+ PIXIS_WRITE(vctl, 1);
while (1);
}
+void pixis_bank_reset(void) __attribute__((weak, alias(__pixis_bank_reset)));
/**
* Set the boot bank to the power-on default bank
*/
-void clear_altbank(void)
+void __clear_altbank(void)
{
+ u8 reg;
+
/* Tell the ngPIXIS to use this the bits in the physical switch for the
* boot bank value, instead of the SWx register. We need to be careful
* only to set the bits in SWx that correspond to the boot bank.
*/
- clrbits_8(PIXIS_EN(PIXIS_LBMAP_SWITCH), PIXIS_LBMAP_MASK);
+ reg = PIXIS_READ(s[PIXIS_LBMAP_SWITCH - 1].en);
+ reg = ~PIXIS_LBMAP_MASK;
+ PIXIS_WRITE(s[PIXIS_LBMAP_SWITCH - 1].en, reg);
}
+void clear_altbank(void) __attribute__((weak, alias(__clear_altbank)));
/**
* Set the boot bank to the alternate bank
*/
-void set_altbank(void)
+void __set_altbank(void)
{
+ u8 reg;
+
/* Program the alternate bank number into the SWx register.
*/
- clrsetbits_8(PIXIS_SW(PIXIS_LBMAP_SWITCH), PIXIS_LBMAP_MASK,
-PIXIS_LBMAP_ALTBANK);
+ reg = PIXIS_READ(s[PIXIS_LBMAP_SWITCH - 1].sw);
+ reg = (reg ~PIXIS_LBMAP_MASK) | PIXIS_LBMAP_ALTBANK;
+ PIXIS_WRITE(s[PIXIS_LBMAP_SWITCH - 1].sw, reg);
/* Tell the ngPIXIS to use this the bits in the SWx register for the
* boot bank value, instead of the physical switch. We need to be
* careful only to set the bits in SWx that correspond to the boot bank.
*/
- setbits_8(PIXIS_EN(PIXIS_LBMAP_SWITCH), PIXIS_LBMAP_MASK);
+ reg = PIXIS_READ(s[PIXIS_LBMAP_SWITCH - 1].en);
+ reg |= PIXIS_LBMAP_MASK;
+ PIXIS_WRITE(s[PIXIS_LBMAP_SWITCH - 1].en, reg);
}
+void set_altbank(void) __attribute__((weak, alias(__set_altbank)));
int pixis_reset_cmd(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
diff --git a/board/freescale/common/ngpixis.h b/board/freescale/common/ngpixis.h
index 089408b..8a7ddfa 100644
--- a/board/freescale/common/ngpixis.h
+++ b/board/freescale/common/ngpixis.h
@@ -55,3 +55,9 @@ typedef struct ngpixis {
/* The PIXIS EN register that corresponds to board switch X, where x = 1 */
#define PIXIS_EN(x)(pixis-s[(x) - 1].en)
+
+u8 pixis_read(unsigned int reg);
+void pixis_write(unsigned int reg, u8 value);
+
+#define PIXIS_READ(reg) pixis_read(offsetof(ngpixis_t, reg))
+#define PIXIS_WRITE(reg, value) pixis_write(offsetof(ngpixis_t, reg), value)
diff --git a/board/freescale/p1022ds/diu.c b/board/freescale/p1022ds/diu.c
index 8f5305c..61679ac 100644
--- a/board/freescale/p1022ds/diu.c
+++ b/board/freescale/p1022ds/diu.c
@@ -139,8 +139,6 @@ int platform_diu_init(unsigned int *xres, unsigned int
*yres)
return fsl_diu_init(*xres
Re: [U-Boot] [PATCH] powerpc/85xx: Bump up the CONFIG_SYS_BOOTM_LEN to 16M on FSL 85xx boards
On Tue, Jan 11, 2011 at 12:44 AM, Kumar Gala ga...@kernel.crashing.org wrote: CONFIG_SYS_BOOTMAPSZ has been 16M on these boards for some time so we should also allow the kernel image to be up to 16M decompressed. Signed-off-by: Kumar Gala ga...@kernel.crashing.org --- include/configs/MPC8536DS.h | 3 ++- include/configs/MPC8540ADS.h | 3 ++- include/configs/MPC8541CDS.h | 3 ++- include/configs/MPC8544DS.h | 3 ++- include/configs/MPC8548CDS.h | 3 ++- include/configs/MPC8555CDS.h | 3 ++- include/configs/MPC8560ADS.h | 3 ++- include/configs/MPC8568MDS.h | 3 ++- include/configs/MPC8569MDS.h | 6 +++--- include/configs/MPC8572DS.h | 3 ++- include/configs/P1022DS.h | 3 ++- include/configs/P1_P2_RDB.h | 3 ++- include/configs/P2020DS.h | 3 ++- include/configs/corenet_ds.h | 3 ++- 14 files changed, 29 insertions(+), 16 deletions(-) Wouldn't it be simpler to do this in arch/powerpc/include/asm/config.h? -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc: fix register usage in some inline assembly code
Kumar Gala wrote: I doubt we disagree that the change is a good one, just trying to understand if it was because of an actual issue you where seeing or just because of some code review that you made it. Just a code review. ie, is this needed in v2010.12 or goes into 'next' Definitely 'next'. -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] powerpc: fix register usage in some inline assembly code
In some usages of inline assembly, hard-coded registers were specified when a
scratch register should have been used instead.
Signed-off-by: Timur Tabi ti...@freescale.com
---
I can't test the kgdb changes, but the rest appears to be okay.
arch/powerpc/lib/kgdb.c | 25 +++--
arch/powerpc/lib/time.c |5 -
2 files changed, 19 insertions(+), 11 deletions(-)
diff --git a/arch/powerpc/lib/kgdb.c b/arch/powerpc/lib/kgdb.c
index 1ec6818..19a56db 100644
--- a/arch/powerpc/lib/kgdb.c
+++ b/arch/powerpc/lib/kgdb.c
@@ -12,11 +12,13 @@ void breakinst(void);
int
kgdb_setjmp(long *buf)
{
- asm (mflr 0; stw 0,0(%0);
-stw 1,4(%0); stw 2,8(%0);
-mfcr 0; stw 0,12(%0);
-stmw 13,16(%0)
-: : r (buf));
+ unsigned long temp;
+
+ asm volatile(mflr %0; stw %0,0(%1);
+stw %%r1,4(%1); stw %%r2,8(%1);
+mfcr %0; stw %0,12(%1);
+stmw %%r13,16(%1)
+: =r(temp) : r (buf));
/* XXX should save fp regs as well */
return 0;
}
@@ -24,13 +26,16 @@ kgdb_setjmp(long *buf)
void
kgdb_longjmp(long *buf, int val)
{
+ unsigned long temp;
+
if (val == 0)
val = 1;
- asm (lmw 13,16(%0);
-lwz 0,12(%0); mtcrf 0x38,0;
-lwz 0,0(%0); lwz 1,4(%0); lwz 2,8(%0);
-mtlr 0; mr 3,%1
-: : r (buf), r (val));
+
+ asm volatile(lmw %%r13,16(%1);
+lwz %0,12(%1); mtcrf 0x38,%0;
+lwz %0,0(%1); lwz %%r1,4(%1); lwz %%r2,8(%1);
+mtlr %0; mr %%r3,%2
+: =r(temp) : r (buf), r (val));
}
static inline unsigned long
diff --git a/arch/powerpc/lib/time.c b/arch/powerpc/lib/time.c
index 2909961..34633c3 100644
--- a/arch/powerpc/lib/time.c
+++ b/arch/powerpc/lib/time.c
@@ -78,6 +78,8 @@ unsigned long ticks2usec(unsigned long ticks)
int init_timebase (void)
{
+ unsigned long temp;
+
#if defined(CONFIG_5xx) || defined(CONFIG_8xx)
volatile immap_t *immap = (immap_t *) CONFIG_SYS_IMMR;
@@ -86,7 +88,8 @@ int init_timebase (void)
#endif
/* reset */
- asm (li 3,0 ; mttbu 3 ; mttbl 3 ;);
+ asm volatile(li %0,0 ; mttbu %0 ; mttbl %0;
+: =r(temp) );
#if defined(CONFIG_5xx) || defined(CONFIG_8xx)
/* enable */
--
1.7.2.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] powerpc: fix implementation of out_8 to match the other out_XX functions
Signed-off-by: Timur Tabi ti...@freescale.com
---
arch/powerpc/include/asm/io.h |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/include/asm/io.h b/arch/powerpc/include/asm/io.h
index 4ddad26..56ac9fe 100644
--- a/arch/powerpc/include/asm/io.h
+++ b/arch/powerpc/include/asm/io.h
@@ -175,7 +175,10 @@ extern inline int in_8(const volatile unsigned char
__iomem *addr)
extern inline void out_8(volatile unsigned char __iomem *addr, int val)
{
- __asm__ __volatile__(stb%U0%X0 %1,%0; eieio : =m (*addr) : r
(val));
+ __asm__ __volatile__(sync;\n
+stb%U0%X0 %1,%0;\n
+: =m (*addr)
+: r (val));
}
extern inline int in_le16(const volatile unsigned short __iomem *addr)
--
1.7.2.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] [v2] p1022ds: fix switching of DIU/LBC signals
On the P1022, the pins which drive the video display (DIU) are muxed with the
local bus controller (LBC), so if the DIU is active, the pins need to be
temporarily muxed to LBC whenever accessing NOR flash.
The code which handled this transition is checking and changing the wrong
bits in PMUXCR.
Also add a follow-up read after a write to NOR flash if we're going to
mux back to DIU after the write, as described in the P1022 RM.
Signed-off-by: Timur Tabi ti...@freescale.com
---
I have no idea how this ever worked before, but without this fix, video on
the P1022DS is completely broken.
board/freescale/p1022ds/diu.c | 67 ++--
1 files changed, 57 insertions(+), 10 deletions(-)
diff --git a/board/freescale/p1022ds/diu.c b/board/freescale/p1022ds/diu.c
index 12b40a0..8f5305c 100644
--- a/board/freescale/p1022ds/diu.c
+++ b/board/freescale/p1022ds/diu.c
@@ -32,6 +32,7 @@
#define PMUXCR_ELBCDIU_MASK0xc000
#define PMUXCR_ELBCDIU_NOR16 0x8000
+#define PMUXCR_ELBCDIU_DIU 0x4000
/*
* DIU Area Descriptor
@@ -131,9 +132,8 @@ int platform_diu_init(unsigned int *xres, unsigned int
*yres)
px_brdcfg0 = in_8(lbc_lcs1_ba);
out_8(lbc_lcs1_ba, px_brdcfg0 | PX_BRDCFG0_ELBC_DIU);
- /* Setting PMUXCR to switch to DVI from ELBC */
- clrsetbits_be32(gur-pmuxcr,
- PMUXCR_ELBCDIU_MASK, PMUXCR_ELBCDIU_NOR16);
+ /* Set PMUXCR to switch the muxed pins from the LBC to the DIU */
+ clrsetbits_be32(gur-pmuxcr, PMUXCR_ELBCDIU_MASK, PMUXCR_ELBCDIU_DIU);
pmuxcr = in_be32(gur-pmuxcr);
return fsl_diu_init(*xres, pixel_format, 0);
@@ -161,7 +161,7 @@ static int set_mux_to_lbc(void)
ccsr_gur_t *gur = (void *)CONFIG_SYS_MPC85xx_GUTS_ADDR;
/* Switch the muxes only if they're currently set to DIU mode */
- if ((in_be32(gur-pmuxcr) PMUXCR_ELBCDIU_MASK) ==
+ if ((in_be32(gur-pmuxcr) PMUXCR_ELBCDIU_MASK) !=
PMUXCR_ELBCDIU_NOR16) {
/*
* In DIU mode, the PIXIS can only be accessed indirectly
@@ -216,8 +216,17 @@ void flash_write8(u8 value, void *addr)
int sw = set_mux_to_lbc();
__raw_writeb(value, addr);
- if (sw)
+ if (sw) {
+ /*
+* To ensure the post-write is completed to eLBC, software must
+* perform a dummy read from one valid address from eLBC space
+* before changing the eLBC_DIU from NOR mode to DIU mode.
+* set_mux_to_diu() includes a sync that will ensure the
+* __raw_readb() completes before it switches the mux.
+*/
+ __raw_readb(addr);
set_mux_to_diu();
+ }
}
void flash_write16(u16 value, void *addr)
@@ -225,8 +234,17 @@ void flash_write16(u16 value, void *addr)
int sw = set_mux_to_lbc();
__raw_writew(value, addr);
- if (sw)
+ if (sw) {
+ /*
+* To ensure the post-write is completed to eLBC, software must
+* perform a dummy read from one valid address from eLBC space
+* before changing the eLBC_DIU from NOR mode to DIU mode.
+* set_mux_to_diu() includes a sync that will ensure the
+* __raw_readb() completes before it switches the mux.
+*/
+ __raw_readb(addr);
set_mux_to_diu();
+ }
}
void flash_write32(u32 value, void *addr)
@@ -234,18 +252,47 @@ void flash_write32(u32 value, void *addr)
int sw = set_mux_to_lbc();
__raw_writel(value, addr);
- if (sw)
+ if (sw) {
+ /*
+* To ensure the post-write is completed to eLBC, software must
+* perform a dummy read from one valid address from eLBC space
+* before changing the eLBC_DIU from NOR mode to DIU mode.
+* set_mux_to_diu() includes a sync that will ensure the
+* __raw_readb() completes before it switches the mux.
+*/
+ __raw_readb(addr);
set_mux_to_diu();
+ }
}
void flash_write64(u64 value, void *addr)
{
int sw = set_mux_to_lbc();
+ uint32_t *p = addr;
- /* There is no __raw_writeq(), so do the write manually */
- *(volatile u64 *)addr = value;
- if (sw)
+ /*
+* There is no __raw_writeq(), so do the write manually. We don't trust
+* the compiler, so we use inline assembly.
+*/
+ __asm__ __volatile__(
+ stw%U0%X0 %2,%0;\n
+ stw%U1%X1 %3,%1;\n
+ : =m (*p), =m (*(p + 1))
+ : r ((uint32_t) (value 32)), r ((uint32_t) (value)));
+
+ if (sw) {
+ /*
+* To ensure the post-write is completed to eLBC, software must
+* perform a dummy read from one valid address from eLBC space
Re: [U-Boot] [PATCH] p1022ds: fix switching of DIU/LBC signals
Scott Wood wrote: If you were to immediately follow it with out_8 as currently defined, yes. But setbits_8 should be OK. I don't want my flash_writeX functions to make any assumptions about what set_mux_to_diu() does. Can I just replace the __raw_readb() with an in_8()? -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 08/13] SBC8560: #define CONFIG_SYS_LBC_NO_SDRAM_INIT
On Thu, Dec 2, 2010 at 5:45 PM, Becky Bruce bec...@kernel.crashing.org wrote: This is for boards that use the SDRAM mode on the LBC but don't require any additional setup. I'm merging all the initdram() calls into a single function for 85xx, and have to be able to distinguish between boards that require an sdram_init() function, and those that do not. We could have defined an empty sdram_init() but I hate doing that. Would a weak function be a better way to do this? -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] p1022ds: fix switching of DIU/LBC signals
Wood Scott-B07421 wrote: Careful with the barriers. You've got a raw readback, which means it's not going to wait for completion with the twi/isync hack. You told me that since I'm doing a read following a write to uncached memory, that I don't need a sync. And what twi/isync hack are you talking about? The one in in_8? Ordinarily that would be OK, since you only need ordering between the readb and the first access in set_mux_to_diu(). Unfortunately, that first access is an 8-bit access, which for some strange reason does sync differently than 16/32-bit accesses. The latter do sync+write, but 8-bit does write+eieio. So there's no barrier between the read and the write. Wait, I don't understand. Where are you getting this from? What do you mean by 16-bit accesses does sync+write vs. write+eieio? Where is the sync/eieio coming from? As for why I don't use in_8, etc, it's because I'm trying to optimize this code. Unlike Dave's code, this stuff needs to be as fast as possible. Although, I wonder if an extra sync will make a difference considering the overhead of switching the muxes. -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] p1022ds: fix switching of DIU/LBC signals
Scott Wood wrote: You told me that since I'm doing a read following a write to uncached memory, that I don't need a sync. No, I was talking about a write followed by a read, to the same location. That's what I said. Read following write == write followed by read. out_8 should be fixed to behave like the other accessors. Ok, but I'm not using any of the I/O accessors, so this doesn't affect me. I just need to make sure that the read is executed after the write, and that the read completes before I continue. So I should I put an isync between the write and the read, and a sync after the read? -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] hwconfig: Fix handling of env_hwconfig, board_hwconfig, and cpu_hwconfig
On Tue, Nov 30, 2010 at 3:58 PM, Kumar Gala ga...@kernel.crashing.org wrote: The handling of env_hwconfig, board_hwconfig, and cpu_hwconfig got broken when we removed the boards defining dummy board_hwconfig cpu_hwconfig values. We fix this by handling the various strings in priority order. If hwconfig_parse returns NULL for a given string we check the next one in order (env_hwconfig, board_hwconfig, followed by cpu_hwconfig). Signed-off-by: Kumar Gala ga...@kernel.crashing.org I think the P1022DS is broken without this fix, but I can't get this patch to apply. Is there a pre-requisite patch that I'm missing? -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] p1022ds: fix switching of DIU/LBC signals
On the P1022, the pins which drive the video display (DIU) are muxed with the
local bus controller (LBC), so if the DIU is active, the pins need to be
temporarily muxed to LBC whenever accessing NOR flash.
The code which handled this transition is checking and changing the wrong
bits in PMUXCR.
Also add a follow-up read after a write to NOR flash if we're going to
mux back to DIU after the write, as described in the P1022 RM.
Signed-off-by: Timur Tabi ti...@freescale.com
---
I have no idea how this ever worked before. It's a complete mystery to me.
board/freescale/p1022ds/diu.c | 45 +---
1 files changed, 37 insertions(+), 8 deletions(-)
diff --git a/board/freescale/p1022ds/diu.c b/board/freescale/p1022ds/diu.c
index 12b40a0..2259384 100644
--- a/board/freescale/p1022ds/diu.c
+++ b/board/freescale/p1022ds/diu.c
@@ -32,6 +32,7 @@
#define PMUXCR_ELBCDIU_MASK0xc000
#define PMUXCR_ELBCDIU_NOR16 0x8000
+#define PMUXCR_ELBCDIU_DIU 0x4000
/*
* DIU Area Descriptor
@@ -131,9 +132,8 @@ int platform_diu_init(unsigned int *xres, unsigned int
*yres)
px_brdcfg0 = in_8(lbc_lcs1_ba);
out_8(lbc_lcs1_ba, px_brdcfg0 | PX_BRDCFG0_ELBC_DIU);
- /* Setting PMUXCR to switch to DVI from ELBC */
- clrsetbits_be32(gur-pmuxcr,
- PMUXCR_ELBCDIU_MASK, PMUXCR_ELBCDIU_NOR16);
+ /* Set PMUXCR to switch the muxed pins from the LBC to the DIU */
+ clrsetbits_be32(gur-pmuxcr, PMUXCR_ELBCDIU_MASK, PMUXCR_ELBCDIU_DIU);
pmuxcr = in_be32(gur-pmuxcr);
return fsl_diu_init(*xres, pixel_format, 0);
@@ -161,7 +161,7 @@ static int set_mux_to_lbc(void)
ccsr_gur_t *gur = (void *)CONFIG_SYS_MPC85xx_GUTS_ADDR;
/* Switch the muxes only if they're currently set to DIU mode */
- if ((in_be32(gur-pmuxcr) PMUXCR_ELBCDIU_MASK) ==
+ if ((in_be32(gur-pmuxcr) PMUXCR_ELBCDIU_MASK) !=
PMUXCR_ELBCDIU_NOR16) {
/*
* In DIU mode, the PIXIS can only be accessed indirectly
@@ -216,8 +216,16 @@ void flash_write8(u8 value, void *addr)
int sw = set_mux_to_lbc();
__raw_writeb(value, addr);
- if (sw)
+
+ if (sw) {
+ /*
+* To ensure the post-write is completed to eLBC, software must
+* perform a dummy read from one valid address from eLBC space
+* before changing the eLBC_DIU from NOR mode to DIU mode.
+*/
+ __raw_readb(addr);
set_mux_to_diu();
+ }
}
void flash_write16(u16 value, void *addr)
@@ -225,8 +233,15 @@ void flash_write16(u16 value, void *addr)
int sw = set_mux_to_lbc();
__raw_writew(value, addr);
- if (sw)
+ if (sw) {
+ /*
+* To ensure the post-write is completed to eLBC, software must
+* perform a dummy read from one valid address from eLBC space
+* before changing the eLBC_DIU from NOR mode to DIU mode.
+*/
+ __raw_readb(addr);
set_mux_to_diu();
+ }
}
void flash_write32(u32 value, void *addr)
@@ -234,8 +249,15 @@ void flash_write32(u32 value, void *addr)
int sw = set_mux_to_lbc();
__raw_writel(value, addr);
- if (sw)
+ if (sw) {
+ /*
+* To ensure the post-write is completed to eLBC, software must
+* perform a dummy read from one valid address from eLBC space
+* before changing the eLBC_DIU from NOR mode to DIU mode.
+*/
+ __raw_readb(addr);
set_mux_to_diu();
+ }
}
void flash_write64(u64 value, void *addr)
@@ -244,8 +266,15 @@ void flash_write64(u64 value, void *addr)
/* There is no __raw_writeq(), so do the write manually */
*(volatile u64 *)addr = value;
- if (sw)
+ if (sw) {
+ /*
+* To ensure the post-write is completed to eLBC, software must
+* perform a dummy read from one valid address from eLBC space
+* before changing the eLBC_DIU from NOR mode to DIU mode.
+*/
+ __raw_readb(addr);
set_mux_to_diu();
+ }
}
u8 flash_read8(void *addr)
--
1.7.2.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] 512x: Cleanup for partial linking and --gc-sections
Wolfgang Denk wrote: I'm not happy about the CONFIG_FSL_DIU_FB hacking I had to do in Makefile and arch/powerpc/cpu/mpc512x/Makefile to make the fsl_diu_fb driver usable for boards where VENDOR is not set or != 'freescale'. Can we not move the fsl_diu_fb driver to a place with better global visibility, like drivers/video/ ? I'm okay with that. -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] 4 PiB left unmapped
On Thu, Nov 18, 2010 at 9:02 AM, DUNDA Matthias matthias.du...@thalesgroup.com wrote: Well, it's actually 2 Gig, just like u-boot recognizes above... There's something wrong with the parameter you're passing to print_size(). -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] [v2] powerpc/85xx: introduce 'fdt verify' command
Introduce the 'fdt verify' command, which verifies some of the physical
addresses in the device tree.
U-Boot uses macros to determine where devices should be located in physical
memory, and Linux uses the device tree to determine where the devices are
actually located. However, U-Boot does not update the device tree with those
addresses when it boots the operating system. This means that it's possible
to use a device tree with the wrong addresses, and U-Boot won't complain.
This frequently happens when U-Boot is compiled for 32-bit physical addresses,
but the device tree uses 36-bit addresses.
It's not safe or practical to have U-Boot update the addresses in the device
tree, mostly because U-Boot is not aware of all the devices. We can, however,
spot-check a few common devices to see if the addresses match, and then display
a warning if they do not.
Signed-off-by: Timur Tabi ti...@freescale.com
---
arch/powerpc/cpu/mpc85xx/fdt.c | 168
common/cmd_fdt.c | 19 +
common/fdt_support.c | 165 +++
include/fdt_support.h | 28 +++
4 files changed, 380 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/cpu/mpc85xx/fdt.c b/arch/powerpc/cpu/mpc85xx/fdt.c
index 53e0596..91ffbc3 100644
--- a/arch/powerpc/cpu/mpc85xx/fdt.c
+++ b/arch/powerpc/cpu/mpc85xx/fdt.c
@@ -393,6 +393,174 @@ static void ft_fixup_qe_snum(void *blob)
}
#endif
+/*
+ * For some CCSR devices, we only have the virtual address, not the physical
+ * address. This is because we map CCSR as a whole, so we typically don't need
+ * a macro for the physical address of any device within CCSR. In this case,
+ * we calculate the physical address of that device using it's the difference
+ * between the virtual address of the device and the virtual address of the
+ * beginning of CCSR.
+ */
+#define CCSR_VIRT_TO_PHYS(x) \
+ (CONFIG_SYS_CCSRBAR_PHYS + ((x) - CONFIG_SYS_CCSRBAR))
+
+#ifdef CONFIG_PCI
+
+/*
+ * Verify the addresses for all of the PCI controllers
+ *
+ * PCI is complicated because there is no correlation between the numbering
+ * of the controllers by U-Boot and the numbering the device tree. So we need
+ * to search all of the aliases until we find a patch
+ */
+static void fdt_verify_pci_aliases(void *blob)
+{
+ int off;
+
+ for (off = fdt_next_pci_node(blob, -1); off != -FDT_ERR_NOTFOUND;
+off = fdt_next_pci_node(blob, off)) {
+ const u32 *reg;
+ u64 addr;
+
+ reg = fdt_getprop(blob, off, reg, NULL);
+ if (!reg || !*reg)
+ continue;
+
+ addr = fdt_translate_address(blob, off, reg);
+ if (!addr)
+ /* We can't determine the base address, so skip it */
+ continue;
+
+#ifdef CONFIG_SYS_PCI1_MEM_PHYS
+ if (addr == CCSR_VIRT_TO_PHYS(CONFIG_SYS_PCI1_ADDR)) {
+ fdt_check_pci_addresses(blob, off,
+ CONFIG_SYS_PCI1_MEM_PHYS,
+ CONFIG_SYS_PCI1_MEM_SIZE, 0);
+ fdt_check_pci_addresses(blob, off,
+ CONFIG_SYS_PCI1_IO_PHYS,
+ CONFIG_SYS_PCI1_IO_SIZE, 1);
+ continue;
+ }
+#endif
+#ifdef CONFIG_SYS_PCI2_MEM_PHYS
+ if (addr == CCSR_VIRT_TO_PHYS(CONFIG_SYS_PCI2_ADDR)) {
+ fdt_check_pci_addresses(blob, off,
+ CONFIG_SYS_PCI2_MEM_PHYS,
+ CONFIG_SYS_PCI2_MEM_SIZE, 0);
+ fdt_check_pci_addresses(blob, off,
+ CONFIG_SYS_PCI2_IO_PHYS,
+ CONFIG_SYS_PCI2_IO_SIZE, 1);
+ continue;
+ }
+#endif
+#ifdef CONFIG_SYS_PCIE1_MEM_PHYS
+ if (addr == CCSR_VIRT_TO_PHYS(CONFIG_SYS_PCIE1_ADDR)) {
+ fdt_check_pci_addresses(blob, off,
+ CONFIG_SYS_PCIE1_MEM_PHYS,
+ CONFIG_SYS_PCIE1_MEM_SIZE, 0);
+ fdt_check_pci_addresses(blob, off,
+ CONFIG_SYS_PCIE1_IO_PHYS,
+ CONFIG_SYS_PCIE1_IO_SIZE, 1);
+ continue;
+ }
+#endif
+#ifdef CONFIG_SYS_PCIE2_MEM_PHYS
+ if (addr == CCSR_VIRT_TO_PHYS(CONFIG_SYS_PCIE2_ADDR)) {
+ fdt_check_pci_addresses(blob, off,
+ CONFIG_SYS_PCIE2_MEM_PHYS,
+ CONFIG_SYS_PCIE2_MEM_SIZE, 0);
+ fdt_check_pci_addresses(blob, off,
+ CONFIG_SYS_PCIE2_IO_PHYS,
+ CONFIG_SYS_PCIE2_IO_SIZE, 1);
+ continue;
+ }
+#endif
+#ifdef
Re: [U-Boot] [PATCH] [v2] powerpc/85xx: introduce 'fdt verify' command
Wolfgang Denk wrote:
struct fdt_header *working_fdt;
@@ -436,6 +450,10 @@ int do_fdt (cmd_tbl_t * cmdtp, int flag, int argc,
char * const argv[])
else if (strncmp(argv[1], re, 2) == 0) {
fdt_resize(working_fdt);
}
+ /* verify the addresses in the fdt */
+ else if (argv[1][0] == 'v') {
+ fdt_verify_addresses(working_fdt);
+ }
else {
2x incorrect coding style - the else goes on the saame line with the
'}' and the '{'
Ah, the bottom half of the switch statement uses this style:
}
else if
But the top half uses this style:
} else if
And the top half is correct.
--
Timur Tabi
Linux kernel developer at Freescale
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] [v3] powerpc/85xx: introduce 'fdt verify' command
Introduce the 'fdt verify' command, which verifies some of the physical
addresses in the device tree.
U-Boot uses macros to determine where devices should be located in physical
memory, and Linux uses the device tree to determine where the devices are
actually located. However, U-Boot does not update the device tree with those
addresses when it boots the operating system. This means that it's possible
to use a device tree with the wrong addresses, and U-Boot won't complain.
This frequently happens when U-Boot is compiled for 32-bit physical addresses,
but the device tree uses 36-bit addresses.
It's not safe or practical to have U-Boot update the addresses in the device
tree, mostly because U-Boot is not aware of all the devices. We can, however,
spot-check a few common devices to see if the addresses match, and then display
a warning if they do not.
Signed-off-by: Timur Tabi ti...@freescale.com
---
arch/powerpc/cpu/mpc85xx/fdt.c | 170
common/cmd_fdt.c | 21 +-
common/fdt_support.c | 170
include/fdt_support.h | 28 +++
4 files changed, 387 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/cpu/mpc85xx/fdt.c b/arch/powerpc/cpu/mpc85xx/fdt.c
index 53e0596..ede33e7 100644
--- a/arch/powerpc/cpu/mpc85xx/fdt.c
+++ b/arch/powerpc/cpu/mpc85xx/fdt.c
@@ -393,6 +393,176 @@ static void ft_fixup_qe_snum(void *blob)
}
#endif
+/*
+ * For some CCSR devices, we only have the virtual address, not the physical
+ * address. This is because we map CCSR as a whole, so we typically don't need
+ * a macro for the physical address of any device within CCSR. In this case,
+ * we calculate the physical address of that device using it's the difference
+ * between the virtual address of the device and the virtual address of the
+ * beginning of CCSR.
+ */
+#define CCSR_VIRT_TO_PHYS(x) \
+ (CONFIG_SYS_CCSRBAR_PHYS + ((x) - CONFIG_SYS_CCSRBAR))
+
+#ifdef CONFIG_PCI
+
+/*
+ * Verify the addresses for all of the PCI controllers
+ *
+ * PCI is complicated because there is no correlation between the numbering
+ * of the controllers by U-Boot and the numbering the device tree. So we need
+ * to search all of the aliases until we find a patch
+ */
+static void fdt_verify_pci_aliases(void *blob)
+{
+ int off;
+
+ for (off = fdt_next_pci_node(blob, -1); off != -FDT_ERR_NOTFOUND;
+off = fdt_next_pci_node(blob, off)) {
+ const u32 *reg;
+ u64 addr;
+
+ reg = fdt_getprop(blob, off, reg, NULL);
+ if (!reg || !*reg)
+ continue;
+
+ addr = fdt_translate_address(blob, off, reg);
+ if (!addr) {
+ /* We can't determine the base address, so skip it */
+ continue;
+ }
+
+#ifdef CONFIG_SYS_PCI1_MEM_PHYS
+ if (addr == CCSR_VIRT_TO_PHYS(CONFIG_SYS_PCI1_ADDR)) {
+ fdt_check_pci_addresses(blob, off,
+ CONFIG_SYS_PCI1_MEM_PHYS,
+ CONFIG_SYS_PCI1_MEM_SIZE, 0);
+ fdt_check_pci_addresses(blob, off,
+ CONFIG_SYS_PCI1_IO_PHYS,
+ CONFIG_SYS_PCI1_IO_SIZE, 1);
+ continue;
+ }
+#endif
+#ifdef CONFIG_SYS_PCI2_MEM_PHYS
+ if (addr == CCSR_VIRT_TO_PHYS(CONFIG_SYS_PCI2_ADDR)) {
+ fdt_check_pci_addresses(blob, off,
+ CONFIG_SYS_PCI2_MEM_PHYS,
+ CONFIG_SYS_PCI2_MEM_SIZE, 0);
+ fdt_check_pci_addresses(blob, off,
+ CONFIG_SYS_PCI2_IO_PHYS,
+ CONFIG_SYS_PCI2_IO_SIZE, 1);
+ continue;
+ }
+#endif
+#ifdef CONFIG_SYS_PCIE1_MEM_PHYS
+ if (addr == CCSR_VIRT_TO_PHYS(CONFIG_SYS_PCIE1_ADDR)) {
+ fdt_check_pci_addresses(blob, off,
+ CONFIG_SYS_PCIE1_MEM_PHYS,
+ CONFIG_SYS_PCIE1_MEM_SIZE, 0);
+ fdt_check_pci_addresses(blob, off,
+ CONFIG_SYS_PCIE1_IO_PHYS,
+ CONFIG_SYS_PCIE1_IO_SIZE, 1);
+ continue;
+ }
+#endif
+#ifdef CONFIG_SYS_PCIE2_MEM_PHYS
+ if (addr == CCSR_VIRT_TO_PHYS(CONFIG_SYS_PCIE2_ADDR)) {
+ fdt_check_pci_addresses(blob, off,
+ CONFIG_SYS_PCIE2_MEM_PHYS,
+ CONFIG_SYS_PCIE2_MEM_SIZE, 0);
+ fdt_check_pci_addresses(blob, off,
+ CONFIG_SYS_PCIE2_IO_PHYS,
+ CONFIG_SYS_PCIE2_IO_SIZE, 1);
+ continue
Re: [U-Boot] [PATCH] powerpc/85xx: compare actual device addresses with the device tree
Wolfgang Denk wrote: If we agree that this is adebug help, then please provide a separate command to perform this operation. Make this command optional (feel free to add it to the default list, but it must be possible to disable it if wanted). Then users who want this feature can add it to their boot command sequence, and others, who are interested in fast boot times can omit it. Would fdt verify be a good place? Yes, sounds good to me. There is one problem -- a lot of the code is 85xx-specific. I'm not sure how to reasonably make this feature available to all fdt-capable architectures. Would you be okay with I enclosed it in an #ifdef CONFIG_MPC85xx, like this: U_BOOT_CMD( fdt,255,0, do_fdt, flattened device tree utility commands, addr addr [length]- Set the fdt location to addr\n #ifdef CONFIG_OF_BOARD_SETUP fdt boardsetup - Do board-specific set up\n #endif fdt move fdt newaddr length - Copy the fdt to addr and make it active\n ... #ifdef CONFIG_MPC85xx fdt verify - Verify the addresses in the device tree\n #endif NOTE: Dereference aliases by omiting the leading '/', e.g. fdt print ethernet0. ); -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/85xx: compare actual device addresses with the device tree
Wolfgang Denk wrote: No, I don't like this. The parts that are not specific to 85xx should be available to all, and CPU specific (and eventually board specific?) parts should be possible by calling into respective functions (which might, for example, have weak dummy implementations). Ok, I can do it this way, but 99% of the code will be CPU-specific. The whole point behind the function is to compare the device tree numbers with the physical addresses of the actual devices in hardware. Do you want the default weak functions to say something like not implemented, or just do nothing at all? -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-mpc85xx.git (updated)
On Fri, Nov 12, 2010 at 9:49 AM, Kumar Gala ga...@kernel.crashing.org wrote: powerpc/8xxx: Enable e1000 driver on some FSL boards I have an objection to this patch that I asked you about earlier, and you never answered my question. -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] MPC8377: USB breaks board
On Thu, Nov 11, 2010 at 6:24 AM, Andre Schwarz andre.schw...@matrix-vision.de wrote: - Activating USB support within U-Boot leads to *very* early crash : No console output - not even PCI clocks enabled. I don't know anything about USB or the 8377, but it could be that you're U-Boot image is too large. Try disabling some other large feature (like PCI and Ethernet support) and booting that image. -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] MPC8377: USB breaks board
On Thu, Nov 11, 2010 at 2:11 PM, Schwarz,Andre andre.schw...@matrix-vision.de wrote: I'm at 300KiB at the moment with plenty of flash. Is there anything specific you're thinking about ? No, it's just wild speculation. -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/8xxx: Enable e1000 driver on some FSL boards
On Wed, Nov 10, 2010 at 8:09 AM, Kumar Gala ga...@kernel.crashing.org wrote: Signed-off-by: Kumar Gala ga...@kernel.crashing.org --- include/configs/MPC8569MDS.h | 1 + include/configs/MPC8572DS.h | 1 + include/configs/P1022DS.h | 1 + There's nothing wrong with the on-board Ethernet of the P1022DS, so why are you enabling the E1000 by default? -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/85xx: compare actual device addresses with the device tree
Wolfgang Denk wrote:
I understand that you can reasonably check these addresses only in
this specific case (i. e. a 36 bit DT and a 32 bit U-Boot) ?
That was just an example, albeit a very common one. This code can check for any
mismatch in CCSR device physical addresses between the U-Boot configuration and
the device tree.
What is the actualk woth of such a check when it covers only one out
of 4 possible combinations?
It's more than that. Any mismatch in the CCSR base address, serial device
offsets, or PCI addresses will be caught. For instance, if you put the PCIE1
memory range at ff80 in the device tree, but ff600 in U-Boot, it will
catch that.
And should that not be made optional? There are enough 85xx boards
which don;t even have 36 bit configurations in Linux, so why waste
memory and runtime on these?
Because the problem shows up when you least expect it. It's designed to
eliminate debug problems. If we make this enabled only when people define a
macro that isn't normally defined, then people won't know about it. We have so
many problems with customers and other developers getting the device tree wrong,
and immediately contacting us for help without doing even the slightest
debugging. I'm sure you're familiar with that.
I can add a macro that needs to be defined in order to *disable* it, so that on
finalized systems where the device tree is known to be correct, this check can
be skipped. But I really would prefer to have this feature enabled by default.
+for (i = 0; i count; i++) {
+/* Parse one line of the 'ranges' property */
+attr = *ranges;
+if (parent_address_cells == 1)
+dt_addr = be32_to_cpup(ranges + address_cells);
+else
+/* parent_address_cells == 2 */
+dt_addr = be64_to_cpup(ranges + address_cells);
+if (size_cells == 1)
+dt_size = be32_to_cpup(ranges + address_cells +
+ parent_address_cells);
+else
+/* size_cells == 2 */
+dt_size = be64_to_cpup(ranges + address_cells +
+ parent_address_cells);
Braces needed for multiline statements. Please fix globally.
So you're saying you want to see this:
if (parent_address_cells == 1)
dt_addr = be32_to_cpup(ranges + address_cells);
else {
/* parent_address_cells == 2 */
dt_addr = be64_to_cpup(ranges + address_cells);
}
if (size_cells == 1) {
dt_size = be32_to_cpup(ranges + address_cells +
parent_address_cells);
} else {
/* size_cells == 2 */
dt_size = be64_to_cpup(ranges + address_cells +
parent_address_cells);
}
wrong_type is referenced only once, so please move the code and get
rid of the goto.
Ok.
--
Timur Tabi
Linux kernel developer at Freescale
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/85xx: compare actual device addresses with the device tree
Wolfgang Denk wrote:
Dear Timur Tabi,
In message 4cdafc37.40...@freescale.com you wrote:
It's more than that. Any mismatch in the CCSR base address, serial device
offsets, or PCI addresses will be caught. For instance, if you put the PCIE1
memory range at ff80 in the device tree, but ff600 in U-Boot, it will
catch that.
Would that hurt? I though Linux does it's own initialization of the
PCI system anyway, so does it matter what we did in U-Boot?
Well, it probably isn't an *error* technically, but it might be unexpected. But
I will consider removing that code, if there's some kind of consensus that it's
not worthwhile.
Because the problem shows up when you least expect it. It's designed to
eliminate debug problems. If we make this enabled only when people define a
macro that isn't normally defined, then people won't know about it. We have
so
many problems with customers and other developers getting the device tree
wrong,
and immediately contacting us for help without doing even the slightest
debugging. I'm sure you're familiar with that.
Hey, you are not supposed to bring us out of work. Rather help to make
the code complex and difficult to understand ;-)
Heh.
I can add a macro that needs to be defined in order to *disable* it, so that
on
finalized systems where the device tree is known to be correct, this check
can
be skipped. But I really would prefer to have this feature enabled by
default.
I understand what you want to do, and why you want to do it, but then
I also feel thatit is inherently wrong. It cannot be U-Boot's taks to
validate the correctness of the device tree on every boot.
Well, I really do think it should be done at every boot by default, but I would
be willing to consider an fdt verify command. Would you be willing to buy me
a beer every time someone forgets to run fdt verify and emails me instead?
If we agree that this is adebug help, then please provide a separate
command to perform this operation. Make this command optional (feel
free to add it to the default list, but it must be possible to disable
it if wanted). Then users who want this feature can add it to their
boot command sequence, and others, who are interested in fast boot
times can omit it.
Would fdt verify be a good place?
So you're saying you want to see this:
if (parent_address_cells == 1)
dt_addr = be32_to_cpup(ranges + address_cells);
else {
Yes, at least. Actually I prefer to use braces for the then branch
as well if the else branch needs them.
Ok.
--
Timur Tabi
Linux kernel developer at Freescale
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/85xx: compare actual device addresses with the device tree
Wolfgang Denk wrote: Definitely not. I'm afraid you'd never be sober again, and while this might deem a desirable state to you I would not want to see you submitting U-Boot patches then :-) I guess you don't know about the U-Boot patch submission drinking game? :-) -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mpc83xx: Make it boot again
Wood Scott-B07421 wrote: To be totally safe, we probably want to do a readback plus twi (to turn a data dependency into a flow dependency) before the isync. twi == trap word immediate? If so, I don't see how that will turn a data dependency into a flow dependency. Is that some sort of side effect of twi? -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mmc: new legacy MMC/SPI driver
On Wed, Oct 27, 2010 at 8:23 PM, Mike Frysinger vap...@gentoo.org wrote: + * Licensed under the GPL-2 or later. Could you include the normal GPL license text instead? We have in-house tools that scan for the strings in that text to determine the license of the file. -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mmc: new legacy MMC/SPI driver
On Wed, Oct 27, 2010 at 8:38 PM, Mike Frysinger vap...@gentoo.org wrote: Could you include the normal GPL license text instead? We have in-house tools that scan for the strings in that text to determine the license of the file. update your tools then Come on, Mike, that's not fair. I'm asking for a simple change that doesn't inconvenience you, and this is how you respond? Are you having a bad day or something? -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 1/4] Add linux framebuffer header include/linux/fb.h
Stefano Babic wrote: I have checked now and I see that some other drivers are requiring these kind of stuctures: the fsl_diu.c for mpc512x has a custom header file (board/freescale/common/fsl_diu_fb.h), where a couple of these structures are defined from Linux and that are part of fb.h. Really there is nothing in this header that is suitable only for Freescale's board, but it points to the fact that a general header is required. So would you expect fsl_diu.c to be modified to use the new header files? -- Timur Tabi Linux kernel developer ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] 36-bits U-Boot
On Fri, Oct 22, 2010 at 5:57 AM, Leif Sörman leif.sor...@enea.com wrote: I want to have ram memory above 4G on a freescale p4080 board since I want to test that 36-bits physical addressing is working, my board has two 2G dimm mounted. We've tested up to 8GB on a P4080DS. The standard 32-bits u-boot on the board says that it can only handle memory less than 4G. I have managed to flashed a 36-bits u-boot to the board and now I realized that the 36-bits u-boot put the two gigs memory below 4G. The purpose of a 36-bit U-Boot is so that you can have more than 2GB of RAM. I/O devices are placed above 4GB. Is it possible to change something in u-boot so it put one of the memory device above 4G? Not really. U-Boot's internal design has quite a few dependencies on having memory starting at address 0. Also, getting the Linux kernel to boot at an address other than 0 is difficult. Also, even if you have 8GB of memory, it's hard to get Linux to allocate memory above the 4GB range. I think a better solution for me would be to replace the two memory devices with two 4 gigs devices. Yes, I agree. Does u-boot support larger devices? Yes. The latest upstream U-Boot supports 4GB DDR and maybe even 8GB DDR. Maybe it's only to put the larger memory in and everything works. It should. This message, including attachments, is CONFIDENTIAL. It may also be privileged or otherwise protected by law. If you received this email by mistake please let us know by reply and then delete it from your system; you should not copy it or disclose its contents to anyone. You really should not include messages like these when you send email to a public mailing list. -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 1/4] Add linux framebuffer header include/linux/fb.h
On Wed, Oct 13, 2010 at 5:14 AM, Stefano Babic sba...@denx.de wrote: [port of linux 2.6.34 commit 6a9ee8af344e3bd7dbd61e67037096cdf7f83289] Signed-off-by: Stefano Babic sba...@denx.de --- Changes since V1: - added precise reference to the kernel version used for porting in the commit message Why are we adding this header file? -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] MPC8377: SVR wrong ?
André Schwarz wrote: It's a hardware issue - the 837x are distinguished by ID Pins. Unfortunately they are buried within the listing of power pins and are not named exclusively ... bloody documentation. I can't talk about the MPC8377CVRALG specifically, but using pin configs to change the ID of the chip is not unusual. A dip switch setting on the P1022DS board will change the P1022 into a P1013, and the SVR will change accordingly. Perhaps your pin config is not set to the default for the chip you ordered, which is why it looks like a different chip? -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] always relocate fdt into an lmb-allocated memory block
On Mon, May 24, 2010 at 3:10 PM, Timur Tabi ti...@freescale.com wrote: The device tree (fdt) must always exist in within the bootmap (usually the first 16MB of RAM). If it doesn't, then boot_relocate_fdt() will allocate an LMB region in the bootmap and copy the fdt into that region. It will also increase the size of the fdt. If the fdt is already in the bootmap, then previously the memory was just reserved. There was no contingency if the reservation failed, however. By always allocating an lmb region and copying/resizing the fdt into that region, the code is simplified and the memory region is always allocated properly. Also change the types of some variables to avoid some typecasts. Signed-off-by: Timur Tabi ti...@freescale.com --- Why was this patch not merged into U-Boot during the merge window? I've been waiting since May for this patch to be applied, and it's been tested and verified. -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] always relocate fdt into an lmb-allocated memory block
On Fri, Aug 20, 2010 at 2:12 PM, Timur Tabi ti...@freescale.com wrote: On Sat, Aug 7, 2010 at 6:36 PM, Wolfgang Denk w...@denx.de wrote: I would like to see any ACK or Tested-by: from actual users of this code. Kumar, who should ack this patch? This patch has been tested and acked by Ira Synder: http://lists.denx.de/pipermail/u-boot/2010-September/076946.html Kumar, please apply this patch for -next -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] MPC8377 system bring up
André Schwarz wrote: Are you using HRCW from Nor on your MPC837x based systems or are you actually using Nand, SPI or I2C PROM ? I've only worked on boards that load the RCW from NOR flash, but some of our BSPs support loading the RCW from other sources, like NAND flash or I2C. -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 01/17] XPedite5500 board support
On Wed, Sep 29, 2010 at 2:05 PM, Peter Tyser pty...@xes-inc.com wrote: From: John Schmoller jschmol...@xes-inc.com Initial support for Extreme Engineering Solutions XPedite5500 - a P2020-based PMC/XMC single board computer. Signed-off-by: John Schmoller jschmol...@xes-inc.com Signed-off-by: Peter Tyser pty...@xes-inc.com CC: Kumar Gala ga...@kernel.crashing.org 17-patch series: Tested-by: Timur Tabi ti...@freescale.com With these patches, the 8610 still compiles and boots. -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] fsl: add support for NXID v1 EEPROM format
Freescale application note AN3638 describes an update to the NXID format, which
stores MAC addresses and related data on an on-board EEPROM. The new version
adds support for up to 23 MAC addresses, instead of just 8. Since the initial
implementation of NXID had a 0 in the 'version' field, this new version is
called v1.
Boards that are shipped with EEPROMs in the NXID v1 format should define
CONFIG_SYS_I2C_EEPROM_NXID_1 instead of CONFIG_SYS_I2C_EEPROM_NXID.
Signed-off-by: Timur Tabi ti...@freescale.com
---
board/freescale/common/sys_eeprom.c | 26 +-
1 files changed, 17 insertions(+), 9 deletions(-)
diff --git a/board/freescale/common/sys_eeprom.c
b/board/freescale/common/sys_eeprom.c
index 3929ad0..7621b91 100644
--- a/board/freescale/common/sys_eeprom.c
+++ b/board/freescale/common/sys_eeprom.c
@@ -28,13 +28,21 @@
#include i2c.h
#include linux/ctype.h
+#ifdef CONFIG_SYS_I2C_EEPROM_CCID
#include ../common/eeprom.h
+#define MAX_NUM_PORTS 8
+#endif
-#if !defined(CONFIG_SYS_I2C_EEPROM_CCID)
!defined(CONFIG_SYS_I2C_EEPROM_NXID)
-#error Please define either CONFIG_SYS_I2C_EEPROM_CCID or
CONFIG_SYS_I2C_EEPROM_NXID
+#ifdef CONFIG_SYS_I2C_EEPROM_NXID
+#define MAX_NUM_PORTS 8
+#define NXID_VERSION 0
#endif
-#define MAX_NUM_PORTS 8 /* This value must be 8 as defined in doc */
+#ifdef CONFIG_SYS_I2C_EEPROM_NXID_1
+#define CONFIG_SYS_I2C_EEPROM_NXID
+#define MAX_NUM_PORTS 23
+#define NXID_VERSION 1
+#endif
/**
* static eeprom: EEPROM layout for CCID or NXID formats
@@ -68,8 +76,8 @@ static struct __attribute__ ((__packed__)) eeprom {
u8 res_1[21]; /* 0x2b - 0x3f Reserved */
u8 mac_count; /* 0x40Number of MAC addresses */
u8 mac_flag; /* 0x41MAC table flags */
- u8 mac[MAX_NUM_PORTS][6]; /* 0x42 - 0x71 MAC addresses */
- u32 crc; /* 0x72CRC32 checksum */
+ u8 mac[MAX_NUM_PORTS][6]; /* 0x42 - x MAC addresses */
+ u32 crc; /* x+1 CRC32 checksum */
#endif
} e;
@@ -300,7 +308,7 @@ static void set_mac_address(unsigned int index, const char
*string)
char *p = (char *) string;
unsigned int i;
- if (!string) {
+ if ((index = MAX_NUM_PORTS) || !string) {
printf(Usage: mac n XX:XX:XX:XX:XX:XX\n);
return;
}
@@ -333,7 +341,7 @@ int do_mac(cmd_tbl_t *cmdtp, int flag, int argc, char *
const argv[])
if (cmd == 'i') {
#ifdef CONFIG_SYS_I2C_EEPROM_NXID
memcpy(e.id, NXID, sizeof(e.id));
- e.version = 0;
+ e.version = NXID_VERSION;
#else
memcpy(e.id, CCID, sizeof(e.id));
#endif
@@ -382,8 +390,8 @@ int do_mac(cmd_tbl_t *cmdtp, int flag, int argc, char *
const argv[])
e.mac_count = simple_strtoul(argv[2], NULL, 16);
update_crc();
break;
- case '0' ... '7': /* mac 0 through mac 7 */
- set_mac_address(cmd - '0', argv[2]);
+ case '0' ... '9': /* mac 0 through mac 22 */
+ set_mac_address(simple_strtoul(argv[1], NULL, 10), argv[2]);
break;
case 'h': /* help */
default:
--
1.7.2.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ppc44x - watchdog timers reboots during the image loading
On Thu, Sep 30, 2010 at 3:15 PM, ame ay...@phx1-ss-2-lb.cnet.com wrote: On my 460ex board, i've tried to add CONFIG_WATCHDOG to the config and it appears to work until the board tries to boot. At that point I can count down about 10 seconds and the reboot happens. The 10s correlates with what I think the watchdog is being set to. I've inserted some WATCHDOG_RESET() invocations wrapping memmove_wd (which admittedly should not be needed), but it does not have an effect. Looks to me like your implementation of WATCHDOG_RESET() is broken. It's not actually resetting the watchdog. That's what you should debug. -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ppc44x - watchdog timers reboots during the image loading
ame wrote: Finally reset_4xx_watchdog does mtspr(tsr, 0xc000) where tsr is 0x150 IIRC. My guess is that this code doesn't actually reset the watchdog. Perhaps your value of TSR is wrong, or 0xc000 is wrong, or perhaps there's some other watchdog active that you're ignoring. -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 15/17] 86xx: Create common linker script
On Wed, Sep 29, 2010 at 2:05 PM, Peter Tyser pty...@xes-inc.com wrote: Signed-off-by: Peter Tyser pty...@xes-inc.com CC: Kumar Gala ga...@kernel.crashing.org --- arch/powerpc/cpu/mpc86xx/config.mk | 3 + .../powerpc/cpu/mpc86xx}/u-boot.lds | 0 board/freescale/mpc8610hpcd/u-boot.lds | 132 --- Have you actually tested this on an 8610? If not, I can test it for you. -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fsl_diu_fb: further refactoring of FLS DIU code
Anatolij Gustschin wrote: This is the first patch version for testing on HW I do not have (mpc8610hpcd, p1022ds). Tested on pdm360ng board. The patch will be modified to fix board config files as needed in the final version. We probably should also move fsl_diu_fb.c file to 'drivers/video'. This works, except the default should be CONFIG_VIDEO is undefined. It's unlikely the customer will have a monitor connected to the DVI port. So ... diff --git a/include/configs/MPC8610HPCD.h b/include/configs/MPC8610HPCD.h index 58d3d99..9f3f843 100644 --- a/include/configs/MPC8610HPCD.h +++ b/include/configs/MPC8610HPCD.h @@ -22,7 +22,9 @@ #define CONFIG_FSL_DIU_FB1 /* FSL DIU */ /* video */ -#undef CONFIG_VIDEO +#ifdef CONFIG_FSL_DIU_FB +#define CONFIG_VIDEO +#endif leave this undefined, and ... diff --git a/include/configs/P1022DS.h b/include/configs/P1022DS.h index 8e0117f..523494d 100644 --- a/include/configs/P1022DS.h +++ b/include/configs/P1022DS.h @@ -178,7 +178,7 @@ #define CONFIG_SYS_PROMPT_HUSH_PS2 /* Video */ -#undef CONFIG_FSL_DIU_FB +#define CONFIG_FSL_DIU_FB don't make this change. -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] p1022ds: add video support
Detlev Zundel wrote: This but there are other examples doing just the same! arguing is getting tiresome. Please accept that this is not an argument capable of convincing people - the opposite is true. It's also very frustrating when developers look at the way U-Boot does things, then spend countless hours or days implementing something similar, only be told, Well, we know this is how it's done, but it's wrong, so you need to rewrite your code. Frankly, I think *that* is way more tiresome. Is there a technical reason why the initialization has to be in U-Boot? I'll have to re-examine the code. There may be a way to eliminate any such initialization. -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] [v2] p1022ds: add video support
Add support for the DIU controller. If CONFIG_VIDEO is defined, then the
console will appear on a DVI monitor instead of the serial port.
Signed-off-by: Timur Tabi ti...@freescale.com
---
board/freescale/p1022ds/Makefile |2 +
board/freescale/p1022ds/diu.c| 148 ++
include/configs/P1022DS.h| 13 ++--
3 files changed, 158 insertions(+), 5 deletions(-)
create mode 100644 board/freescale/p1022ds/diu.c
diff --git a/board/freescale/p1022ds/Makefile b/board/freescale/p1022ds/Makefile
index 8ede2d6..678eb2a 100644
--- a/board/freescale/p1022ds/Makefile
+++ b/board/freescale/p1022ds/Makefile
@@ -16,6 +16,8 @@ COBJS-y += ddr.o
COBJS-y+= law.o
COBJS-y+= tlb.o
+COBJS-$(CONFIG_FSL_DIU_FB) += diu.o
+
SRCS := $(SOBJS:.o=.S) $(COBJS-y:.o=.c)
OBJS := $(addprefix $(obj),$(COBJS-y))
SOBJS := $(addprefix $(obj),$(SOBJS))
diff --git a/board/freescale/p1022ds/diu.c b/board/freescale/p1022ds/diu.c
new file mode 100644
index 000..5cf74ba
--- /dev/null
+++ b/board/freescale/p1022ds/diu.c
@@ -0,0 +1,148 @@
+/*
+ * Copyright 2010 Freescale Semiconductor, Inc.
+ * Authors: Timur Tabi ti...@freescale.com
+ *
+ * FSL DIU Framebuffer driver
+ *
+ * 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 command.h
+#include asm/io.h
+#include stdio_dev.h
+#include video_fb.h
+#include ../common/ngpixis.h
+#include ../common/fsl_diu_fb.h
+
+#define PX_BRDCFG0_ELBC_DIU0x02
+
+#define PX_BRDCFG1_DVIEN 0x80
+#define PX_BRDCFG1_DFPEN 0x40
+#define PX_BRDCFG1_BACKLIGHT 0x20
+
+/*
+ * DIU Area Descriptor
+ *
+ * Note that we need to byte-swap the value before it's written to the AD
+ * register. So even though the registers don't look like they're in the same
+ * bit positions as they are on the MPC8610, the same value is written to the
+ * AD register on the MPC8610 and on the P1022.
+ */
+#define AD_BYTE_F 0x1000
+#define AD_ALPHA_C_SHIFT 25
+#define AD_BLUE_C_SHIFT23
+#define AD_GREEN_C_SHIFT 21
+#define AD_RED_C_SHIFT 19
+#define AD_PIXEL_S_SHIFT 16
+#define AD_COMP_3_SHIFT12
+#define AD_COMP_2_SHIFT8
+#define AD_COMP_1_SHIFT4
+#define AD_COMP_0_SHIFT0
+
+static int xres, yres;
+
+void diu_set_pixel_clock(unsigned int pixclock)
+{
+ ccsr_gur_t *gur = (void *)(CONFIG_SYS_MPC85xx_GUTS_ADDR);
+ unsigned long speed_ccb, temp;
+ u32 pixval;
+
+ speed_ccb = get_bus_freq(0);
+ temp = 10 / pixclock;
+ temp *= 1000;
+ pixval = speed_ccb / temp;
+ debug(DIU pixval = %lu\n, pixval);
+
+ /* Modify PXCLK in GUTS CLKDVDR */
+ temp = in_be32(gur-clkdvdr) 0x2000;
+ out_be32(gur-clkdvdr, temp); /* turn off clock */
+ out_be32(gur-clkdvdr, temp | 0x8000 | ((pixval 0x1F) 16));
+}
+
+static int p1022ds_diu_init(void)
+{
+ ccsr_gur_t *gur = (void *)(CONFIG_SYS_MPC85xx_GUTS_ADDR);
+ char *monitor_port;
+ u32 pixel_format;
+ u8 temp;
+
+ pixel_format = cpu_to_le32(AD_BYTE_F | (3 AD_ALPHA_C_SHIFT) |
+ (0 AD_BLUE_C_SHIFT) | (1 AD_GREEN_C_SHIFT) |
+ (2 AD_RED_C_SHIFT) | (8 AD_COMP_3_SHIFT) |
+ (8 AD_COMP_2_SHIFT) | (8 AD_COMP_1_SHIFT) |
+ (8 AD_COMP_0_SHIFT) | (3 AD_PIXEL_S_SHIFT));
+
+ temp = in_8(pixis-brdcfg1);
+
+ monitor_port = getenv(monitor);
+ if (!strncmp(monitor_port, 1, 1)) { /* 1 - Single link LVDS */
+ xres = 1024;
+ yres = 768;
+ /* Enable the DFP port, disable the DVI and the backlight */
+ temp = ~(PX_BRDCFG1_DVIEN | PX_BRDCFG1_BACKLIGHT);
+ temp |= PX_BRDCFG1_DFPEN;
+ } else {/* DVI */
+ xres = 1280;
+ yres = 1024;
+ /* Enable the DVI port, disable the DFP and the backlight */
+ temp = ~(PX_BRDCFG1_DFPEN | PX_BRDCFG1_BACKLIGHT);
+ temp |= PX_BRDCFG1_DVIEN;
+ }
+
+ out_8(pixis-brdcfg1, temp);
+
+ /*
+* Route the LAD pins to the DIU. This will disable access to the eLBC,
+* which means we won't be able to read/write any NOR flash addresses!
+*/
+ out_8(pixis-brdcfg0, in_8(pixis-brdcfg0) | PX_BRDCFG0_ELBC_DIU);
+ /* we must do the dummy read from eLBC to sync the write as above */
+ in_8(pixis-brdcfg0);
+
+ /* Setting PMUXCR to switch to DVI from ELBC */
+ /* Set pmuxcr to allow both i2c1 and i2c2 */
+ clrsetbits_be32(gur-pmuxcr, 0xc000, 0x4000);
+ in_be32(gur-pmuxcr);
+
+ return fsl_diu_init(xres, pixel_format, 0
Re: [U-Boot] [PATCH] p1022ds: add video support
Anatolij Gustschin wrote: +#define AD_BYTE_F 0x1000 +#define AD_ALPHA_C_MASK 0x0E00 +#define AD_ALPHA_C_SHIFT25 +#define AD_BLUE_C_MASK 0x0180 +#define AD_BLUE_C_SHIFT 23 +#define AD_GREEN_C_MASK 0x0060 +#define AD_GREEN_C_SHIFT21 +#define AD_RED_C_MASK 0x0018 +#define AD_RED_C_SHIFT 19 +#define AD_PALETTE 0x0004 +#define AD_PIXEL_S_MASK 0x0003 +#define AD_PIXEL_S_SHIFT16 +#define AD_COMP_3_MASK 0xF000 +#define AD_COMP_3_SHIFT 12 +#define AD_COMP_2_MASK 0x0F00 +#define AD_COMP_2_SHIFT 8 +#define AD_COMP_1_MASK 0x00F0 +#define AD_COMP_1_SHIFT 4 +#define AD_COMP_0_MASK 0x000F +#define AD_COMP_0_SHIFT 0 + +#define AD_DEFAULT Some of the defines above are not used (*_MASK, AD_PALETTE, AD_DEFAULT), please drop them, too. Does it really matter? These are all in a .c file, so it's not like I'm polluting the name space. Also, I thought it would be better to provide some sort of completeness for the bits I am using. CONFIG_VIDEO definition should depend on CONFIG_FSL_DIU_FB, I think. Otherwise the building won't succeed if CONFIG_FSL_DIU_FB is not defined (due to absence of video_hw_init()). We need the DIU initialized, even if U-Boot doesn't use it. This is what CONFIG_FSL_DIU_FB does. CONFIG_VIDEO then tells U-Boot to actually use the DIU. -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] p1022ds: add video support
Anatolij Gustschin wrote: Also, I thought it would be better to provide some sort of completeness for the bits I am using. We do not add unused code. Well, I don't see how macros are unused code, but I'll delete those lines. CONFIG_VIDEO definition should depend on CONFIG_FSL_DIU_FB, I think. Otherwise the building won't succeed if CONFIG_FSL_DIU_FB is not defined (due to absence of video_hw_init()). We need the DIU initialized, even if U-Boot doesn't use it. This is what CONFIG_FSL_DIU_FB does. CONFIG_VIDEO then tells U-Boot to actually use the DIU. I understand it. I didn't say you should make CONFIG_FSL_DIU_FB dependent on CONFIG_VIDEO, but the opposite. Ok. On the other site, one of the design principles states: initialize devices only when they are needed within U-Boot. Well, I'll try to work toward that, but I'm pretty sure there are plenty of devices that are initialized but not used in U-Boot already. -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] p1022ds: use weak CFI flash accessors when DIU is enabled
On the Freescale P1022, the DIU and the LBC share address pins, which means
that when the DIU is active (e.g. the console is on the DVI display), NOR flash
cannot be accessed. So we use the weak accessor function feature of the CFI
flash code to temporarily switch the pin mux from LBC to DIU whenever we want
to read or write flash. This has a significant performance penalty, but it's
the only way to make it work.
This change allows the 'saveenv' command to work when the video display is
enabled. Writing to flash with the 'cp' command works, but reading from flash
with the 'md' and 'cp' commands does not. Also, while flash is being written
to, the video display will be blank.
Signed-off-by: Timur Tabi ti...@freescale.com
---
board/freescale/p1022ds/diu.c | 205 +++--
include/configs/P1022DS.h |6 +
2 files changed, 203 insertions(+), 8 deletions(-)
diff --git a/board/freescale/p1022ds/diu.c b/board/freescale/p1022ds/diu.c
index be6e9a8..1d50ed2 100644
--- a/board/freescale/p1022ds/diu.c
+++ b/board/freescale/p1022ds/diu.c
@@ -14,8 +14,6 @@
#include command.h
#include asm/io.h
-#ifdef CONFIG_FSL_DIU_FB
-
#include ../common/ngpixis.h
#include ../common/fsl_diu_fb.h
@@ -24,7 +22,13 @@
#include video_fb.h
#endif
-#define PX_BRDCFG0_ELBC_DIU0x02
+/* The CTL register is called 'csr' in the ngpixis_t structure */
+#define PX_CTL_ALTACC 0x80
+
+#define PX_BRDCFG0_ELBC_SPI_MASK 0xc0
+#define PX_BRDCFG0_ELBC_SPI_ELBC 0x00
+#define PX_BRDCFG0_ELBC_SPI_NULL 0xc0
+#define PX_BRDCFG0_ELBC_DIU0x02
#define PX_BRDCFG1_DVIEN 0x80
#define PX_BRDCFG1_DFPEN 0x40
@@ -63,6 +67,15 @@
#define AD_DEFAULT
static int xres, yres;
+/* Variables used by the DIU/LBC switching code. It's safe to makes these
+ * global, because the DIU requires DDR, so we'll only run this code after
+ * relocation.
+ */
+static u8 px_brdcfg0;
+static u32 pmuxcr;
+static void *lbc_lcs0_ba;
+static void *lbc_lcs1_ba;
+
void diu_set_pixel_clock(unsigned int pixclock)
{
ccsr_gur_t *gur = (void *)(CONFIG_SYS_MPC85xx_GUTS_ADDR);
@@ -88,6 +101,10 @@ int p1022ds_diu_init(void)
u32 pixel_format;
u8 temp;
+ /* Save the LBC LCS0 and LCS1 addresses for the DIU mux functions */
+ lbc_lcs0_ba = (void *)(get_lbc_br(0) get_lbc_or(0) 0x8000);
+ lbc_lcs1_ba = (void *)(get_lbc_br(1) get_lbc_or(1) 0x8000);
+
pixel_format = cpu_to_le32(AD_BYTE_F | (3 AD_ALPHA_C_SHIFT) |
(0 AD_BLUE_C_SHIFT) | (1 AD_GREEN_C_SHIFT) |
(2 AD_RED_C_SHIFT) | (8 AD_COMP_3_SHIFT) |
@@ -114,17 +131,23 @@ int p1022ds_diu_init(void)
out_8(pixis-brdcfg1, temp);
/*
+* Enable PIXIS indirect access mode. This is a hack that allows us to
+* access PIXIS registers even when the LBC pins have been muxed to the
+* DIU.
+*/
+ setbits_8(pixis-csr, PX_CTL_ALTACC);
+
+ /*
* Route the LAD pins to the DIU. This will disable access to the eLBC,
* which means we won't be able to read/write any NOR flash addresses!
*/
- out_8(pixis-brdcfg0, in_8(pixis-brdcfg0) | PX_BRDCFG0_ELBC_DIU);
- /* we must do the dummy read from eLBC to sync the write as above */
- in_8(pixis-brdcfg0);
+ out_8(lbc_lcs0_ba, offsetof(ngpixis_t, brdcfg0));
+ px_brdcfg0 = in_8(lbc_lcs1_ba);
+ out_8(lbc_lcs1_ba, px_brdcfg0 | PX_BRDCFG0_ELBC_DIU);
/* Setting PMUXCR to switch to DVI from ELBC */
- /* Set pmuxcr to allow both i2c1 and i2c2 */
clrsetbits_be32(gur-pmuxcr, 0xc000, 0x4000);
- in_be32(gur-pmuxcr);
+ pmuxcr = in_be32(gur-pmuxcr);
return fsl_diu_init(xres, pixel_format, 0);
}
@@ -169,4 +192,170 @@ void *video_hw_init(void)
#endif
+#ifdef CONFIG_CFI_FLASH_USE_WEAK_ACCESSORS
+
+#define PMUXCR_ELBCDIU_MASK0xc000
+#define PMUXCR_ELBCDIU_NOR16 0x8000
+/**
+ * set_mux_to_lbc - disable the DIU so that we can read/write to elbc
+ *
+ * On the Freescale P1022, the DIU video signal and the LBC address/data lines
+ * share the same pins, which means that when the DIU is active (e.g. the
+ * console is on the DVI display), NOR flash cannot be accessed. So we use the
+ * weak accessor feature of the CFI flash code to temporarily switch the pin
+ * mux from DIU to LBC whenever we want to read or write flash. This has a
+ * significant performance penalty, but it's the only way to make it work.
+ *
+ * There are two muxes: one on the chip, and one on the board. The chip mux
+ * controls whether the pins are used for the DIU or the LBC, and it is
+ * set via PMUXCR. The board mux controls whether those signals go to
+ * the video connector or the NOR flash chips, and it is set via the ngPIXIS.
+ */
+static int set_mux_to_lbc(void)
+{
+ ccsr_gur_t *gur = (void *)CONFIG_SYS_MPC85xx_GUTS_ADDR;
+
+ /* Switch the muxes only
[U-Boot] [PATCH] [v2] p1022ds: use weak CFI flash accessors when DIU is enabled
On the Freescale P1022, the DIU and the LBC share address pins, which means
that when the DIU is active (e.g. the console is on the DVI display), NOR flash
cannot be accessed. So we use the weak accessor function feature of the CFI
flash code to temporarily switch the pin mux from LBC to DIU whenever we want
to read or write flash. This has a significant performance penalty, but it's
the only way to make it work.
This change allows the 'saveenv' command to work when the video display is
enabled. Writing to flash with the 'cp' command works, but reading from flash
with the 'md' and 'cp' commands does not. Also, while flash is being written
to, the video display will be blank.
Signed-off-by: Timur Tabi ti...@freescale.com
---
v2: found another place to use the PMUXCR_ELBCDIU_xxx macros
board/freescale/p1022ds/diu.c | 208 +++--
include/configs/P1022DS.h |6 +
2 files changed, 205 insertions(+), 9 deletions(-)
diff --git a/board/freescale/p1022ds/diu.c b/board/freescale/p1022ds/diu.c
index be6e9a8..b6be1a5 100644
--- a/board/freescale/p1022ds/diu.c
+++ b/board/freescale/p1022ds/diu.c
@@ -14,8 +14,6 @@
#include command.h
#include asm/io.h
-#ifdef CONFIG_FSL_DIU_FB
-
#include ../common/ngpixis.h
#include ../common/fsl_diu_fb.h
@@ -24,13 +22,22 @@
#include video_fb.h
#endif
-#define PX_BRDCFG0_ELBC_DIU0x02
+/* The CTL register is called 'csr' in the ngpixis_t structure */
+#define PX_CTL_ALTACC 0x80
+
+#define PX_BRDCFG0_ELBC_SPI_MASK 0xc0
+#define PX_BRDCFG0_ELBC_SPI_ELBC 0x00
+#define PX_BRDCFG0_ELBC_SPI_NULL 0xc0
+#define PX_BRDCFG0_ELBC_DIU0x02
#define PX_BRDCFG1_DVIEN 0x80
#define PX_BRDCFG1_DFPEN 0x40
#define PX_BRDCFG1_BACKLIGHT 0x20
#define PX_BRDCFG1_DDCEN 0x10
+#define PMUXCR_ELBCDIU_MASK0xc000
+#define PMUXCR_ELBCDIU_NOR16 0x8000
+
/*
* DIU Area Descriptor
*
@@ -63,6 +70,15 @@
#define AD_DEFAULT
static int xres, yres;
+/* Variables used by the DIU/LBC switching code. It's safe to makes these
+ * global, because the DIU requires DDR, so we'll only run this code after
+ * relocation.
+ */
+static u8 px_brdcfg0;
+static u32 pmuxcr;
+static void *lbc_lcs0_ba;
+static void *lbc_lcs1_ba;
+
void diu_set_pixel_clock(unsigned int pixclock)
{
ccsr_gur_t *gur = (void *)(CONFIG_SYS_MPC85xx_GUTS_ADDR);
@@ -88,6 +104,10 @@ int p1022ds_diu_init(void)
u32 pixel_format;
u8 temp;
+ /* Save the LBC LCS0 and LCS1 addresses for the DIU mux functions */
+ lbc_lcs0_ba = (void *)(get_lbc_br(0) get_lbc_or(0) 0x8000);
+ lbc_lcs1_ba = (void *)(get_lbc_br(1) get_lbc_or(1) 0x8000);
+
pixel_format = cpu_to_le32(AD_BYTE_F | (3 AD_ALPHA_C_SHIFT) |
(0 AD_BLUE_C_SHIFT) | (1 AD_GREEN_C_SHIFT) |
(2 AD_RED_C_SHIFT) | (8 AD_COMP_3_SHIFT) |
@@ -114,17 +134,23 @@ int p1022ds_diu_init(void)
out_8(pixis-brdcfg1, temp);
/*
+* Enable PIXIS indirect access mode. This is a hack that allows us to
+* access PIXIS registers even when the LBC pins have been muxed to the
+* DIU.
+*/
+ setbits_8(pixis-csr, PX_CTL_ALTACC);
+
+ /*
* Route the LAD pins to the DIU. This will disable access to the eLBC,
* which means we won't be able to read/write any NOR flash addresses!
*/
- out_8(pixis-brdcfg0, in_8(pixis-brdcfg0) | PX_BRDCFG0_ELBC_DIU);
- /* we must do the dummy read from eLBC to sync the write as above */
- in_8(pixis-brdcfg0);
+ out_8(lbc_lcs0_ba, offsetof(ngpixis_t, brdcfg0));
+ px_brdcfg0 = in_8(lbc_lcs1_ba);
+ out_8(lbc_lcs1_ba, px_brdcfg0 | PX_BRDCFG0_ELBC_DIU);
/* Setting PMUXCR to switch to DVI from ELBC */
- /* Set pmuxcr to allow both i2c1 and i2c2 */
- clrsetbits_be32(gur-pmuxcr, 0xc000, 0x4000);
- in_be32(gur-pmuxcr);
+ clrsetbits_be32(gur-pmuxcr, PMUXCR_ELBCDIU_MASK,
PMUXCR_ELBCDIU_NOR16);
+ pmuxcr = in_be32(gur-pmuxcr);
return fsl_diu_init(xres, pixel_format, 0);
}
@@ -169,4 +195,168 @@ void *video_hw_init(void)
#endif
+#ifdef CONFIG_CFI_FLASH_USE_WEAK_ACCESSORS
+
+/**
+ * set_mux_to_lbc - disable the DIU so that we can read/write to elbc
+ *
+ * On the Freescale P1022, the DIU video signal and the LBC address/data lines
+ * share the same pins, which means that when the DIU is active (e.g. the
+ * console is on the DVI display), NOR flash cannot be accessed. So we use the
+ * weak accessor feature of the CFI flash code to temporarily switch the pin
+ * mux from DIU to LBC whenever we want to read or write flash. This has a
+ * significant performance penalty, but it's the only way to make it work.
+ *
+ * There are two muxes: one on the chip, and one on the board. The chip mux
+ * controls whether the pins are used for the DIU or the LBC, and it is
+ * set via PMUXCR. The board mux
Re: [U-Boot] [PATCH] p1022ds: use weak CFI flash accessors when DIU is enabled
Wolfgang Denk wrote: I think the description is wrong - don't you switch from DIU to LBC for flash access? Ugh, yes. I was getting bug-eyed working on this code. +/* Variables used by the DIU/LBC switching code. It's safe to makes these + * global, because the DIU requires DDR, so we'll only run this code after + * relocation. + */ Incorrect multiline comment format. +/** + * set_mux_to_lbc - disable the DIU so that we can read/write to elbc Incorrect multiline comment format. Please check and fix globally. Can you be more specific? Is it the **? +#define CONFIG_CFI_FLASH_USE_WEAK_ACCESSORS +/* + * With CONFIG_CFI_FLASH_USE_WEAK_ACCESSORS, flash I/O is really slow, so + * disable empty flash sector detection, which is I/O-intensive. + */ +#undef CONFIG_SYS_FLASH_EMPTY_INFO #ifdef CONFIG_CFI_FLASH_USE_WEAK_ACCESSORS / #endif arount the #undef ? Why? CONFIG_CFI_FLASH_USE_WEAK_ACCESSORS is only defined if CONFIG_VIDEO is defined. It's just one block of macros. -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] [v3] p1022ds: use weak CFI flash accessors when DIU is enabled
On the Freescale P1022, the DIU and the LBC share address pins, which means
that when the DIU is active (e.g. the console is on the DVI display), NOR flash
cannot be accessed. So we use the weak accessor function feature of the CFI
flash code to temporarily switch the pin mux from DIU to LBC whenever we want
to read or write flash. This has a significant performance penalty, but it's
the only way to make it work.
This change allows the 'saveenv' command to work when the video display is
enabled. Erasing flash and writing to flash (with the 'cp' command) works,
but reading from flash (with the 'md' and 'cp' commands) does not. Also, while
flash is being written, the video display will be blank.
Signed-off-by: Timur Tabi ti...@freescale.com
---
v3: changes as requested
board/freescale/p1022ds/diu.c | 208 +++--
include/configs/P1022DS.h |6 +
2 files changed, 205 insertions(+), 9 deletions(-)
diff --git a/board/freescale/p1022ds/diu.c b/board/freescale/p1022ds/diu.c
index be6e9a8..c8bfdf0 100644
--- a/board/freescale/p1022ds/diu.c
+++ b/board/freescale/p1022ds/diu.c
@@ -14,8 +14,6 @@
#include command.h
#include asm/io.h
-#ifdef CONFIG_FSL_DIU_FB
-
#include ../common/ngpixis.h
#include ../common/fsl_diu_fb.h
@@ -24,13 +22,22 @@
#include video_fb.h
#endif
-#define PX_BRDCFG0_ELBC_DIU0x02
+/* The CTL register is called 'csr' in the ngpixis_t structure */
+#define PX_CTL_ALTACC 0x80
+
+#define PX_BRDCFG0_ELBC_SPI_MASK 0xc0
+#define PX_BRDCFG0_ELBC_SPI_ELBC 0x00
+#define PX_BRDCFG0_ELBC_SPI_NULL 0xc0
+#define PX_BRDCFG0_ELBC_DIU0x02
#define PX_BRDCFG1_DVIEN 0x80
#define PX_BRDCFG1_DFPEN 0x40
#define PX_BRDCFG1_BACKLIGHT 0x20
#define PX_BRDCFG1_DDCEN 0x10
+#define PMUXCR_ELBCDIU_MASK0xc000
+#define PMUXCR_ELBCDIU_NOR16 0x8000
+
/*
* DIU Area Descriptor
*
@@ -63,6 +70,16 @@
#define AD_DEFAULT
static int xres, yres;
+/*
+ * Variables used by the DIU/LBC switching code. It's safe to makes these
+ * global, because the DIU requires DDR, so we'll only run this code after
+ * relocation.
+ */
+static u8 px_brdcfg0;
+static u32 pmuxcr;
+static void *lbc_lcs0_ba;
+static void *lbc_lcs1_ba;
+
void diu_set_pixel_clock(unsigned int pixclock)
{
ccsr_gur_t *gur = (void *)(CONFIG_SYS_MPC85xx_GUTS_ADDR);
@@ -88,6 +105,10 @@ int p1022ds_diu_init(void)
u32 pixel_format;
u8 temp;
+ /* Save the LBC LCS0 and LCS1 addresses for the DIU mux functions */
+ lbc_lcs0_ba = (void *)(get_lbc_br(0) get_lbc_or(0) 0x8000);
+ lbc_lcs1_ba = (void *)(get_lbc_br(1) get_lbc_or(1) 0x8000);
+
pixel_format = cpu_to_le32(AD_BYTE_F | (3 AD_ALPHA_C_SHIFT) |
(0 AD_BLUE_C_SHIFT) | (1 AD_GREEN_C_SHIFT) |
(2 AD_RED_C_SHIFT) | (8 AD_COMP_3_SHIFT) |
@@ -114,17 +135,24 @@ int p1022ds_diu_init(void)
out_8(pixis-brdcfg1, temp);
/*
+* Enable PIXIS indirect access mode. This is a hack that allows us to
+* access PIXIS registers even when the LBC pins have been muxed to the
+* DIU.
+*/
+ setbits_8(pixis-csr, PX_CTL_ALTACC);
+
+ /*
* Route the LAD pins to the DIU. This will disable access to the eLBC,
* which means we won't be able to read/write any NOR flash addresses!
*/
- out_8(pixis-brdcfg0, in_8(pixis-brdcfg0) | PX_BRDCFG0_ELBC_DIU);
- /* we must do the dummy read from eLBC to sync the write as above */
- in_8(pixis-brdcfg0);
+ out_8(lbc_lcs0_ba, offsetof(ngpixis_t, brdcfg0));
+ px_brdcfg0 = in_8(lbc_lcs1_ba);
+ out_8(lbc_lcs1_ba, px_brdcfg0 | PX_BRDCFG0_ELBC_DIU);
/* Setting PMUXCR to switch to DVI from ELBC */
- /* Set pmuxcr to allow both i2c1 and i2c2 */
- clrsetbits_be32(gur-pmuxcr, 0xc000, 0x4000);
- in_be32(gur-pmuxcr);
+ clrsetbits_be32(gur-pmuxcr,
+ PMUXCR_ELBCDIU_MASK, PMUXCR_ELBCDIU_NOR16);
+ pmuxcr = in_be32(gur-pmuxcr);
return fsl_diu_init(xres, pixel_format, 0);
}
@@ -169,4 +197,166 @@ void *video_hw_init(void)
#endif
+#ifdef CONFIG_CFI_FLASH_USE_WEAK_ACCESSORS
+
+/*
+ * set_mux_to_lbc - disable the DIU so that we can read/write to elbc
+ *
+ * On the Freescale P1022, the DIU video signal and the LBC address/data lines
+ * share the same pins, which means that when the DIU is active (e.g. the
+ * console is on the DVI display), NOR flash cannot be accessed. So we use the
+ * weak accessor feature of the CFI flash code to temporarily switch the pin
+ * mux from DIU to LBC whenever we want to read or write flash. This has a
+ * significant performance penalty, but it's the only way to make it work.
+ *
+ * There are two muxes: one on the chip, and one on the board. The chip mux
+ * controls whether the pins are used for the DIU or the LBC, and it is
+ * set via PMUXCR. The board mux
[U-Boot] Summary of my patches for v2010.12 merge window
Kumar, Since the merge window for v2010.12 will be open soon, I want to make sure that all of my pending patches are included. Here's a list of all the U-Boot patches I've submitted that I think should be in your next pull request: 1. [v2] p1022ds: add audclk hwconfig setting to enable codec reference clock 2. fsl: verify writes to the MAC address EEPROM 3. always relocate fdt into an lmb-allocated memory block 4. logos: add Freescale logo 5. [v3] fsl: refactor MPC8610 and MPC5121 DIU code to use existing bitmap and logo features 6. p1022ds: add video support Please note that Wolfgang has asked for someone else to test always relocate fdt into an lmb-allocated memory block, but no one has done so yet, and you have no indicated that anyone will. Also, this patch is not 85xx-specific, but should be included anyway. Wolfgang, please check to see if it's being handled by the proper maintainer: 1. video: cfb_console: add support for 4bpp bitmaps with GDF_32BIT_X888RGB Thanks. -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] MPC8536 custom board without SPD EEPROM configured DDR
On Thursday, September 2, 2010, Carlos Roberto Moratelli carlos.morate...@digitel.com.br wrote: My question is why this happens to the MPC8536ds target? I suppose I must configure law and tbl entries in a similar way like MPC8540ads. It happens because once we get SPD working on a board, the non-SPD code usually succumbs to bit rot. -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] p1022ds: add video support
Add support for the DIU controller. If CONFIG_VIDEO is defined, then the
console will appear on a DVI monitor instead of the serial port.
Signed-off-by: Timur Tabi ti...@freescale.com
---
This patch depends on:
[v3] fsl: refactor MPC8610 and MPC5121 DIU code to use existing bitmap and logo
features
board/freescale/p1022ds/Makefile |2 +
board/freescale/p1022ds/diu.c| 172 ++
include/configs/P1022DS.h|7 ++-
3 files changed, 180 insertions(+), 1 deletions(-)
create mode 100644 board/freescale/p1022ds/diu.c
diff --git a/board/freescale/p1022ds/Makefile b/board/freescale/p1022ds/Makefile
index 8ede2d6..678eb2a 100644
--- a/board/freescale/p1022ds/Makefile
+++ b/board/freescale/p1022ds/Makefile
@@ -16,6 +16,8 @@ COBJS-y += ddr.o
COBJS-y+= law.o
COBJS-y+= tlb.o
+COBJS-$(CONFIG_FSL_DIU_FB) += diu.o
+
SRCS := $(SOBJS:.o=.S) $(COBJS-y:.o=.c)
OBJS := $(addprefix $(obj),$(COBJS-y))
SOBJS := $(addprefix $(obj),$(SOBJS))
diff --git a/board/freescale/p1022ds/diu.c b/board/freescale/p1022ds/diu.c
new file mode 100644
index 000..be6e9a8
--- /dev/null
+++ b/board/freescale/p1022ds/diu.c
@@ -0,0 +1,172 @@
+/*
+ * Copyright 2010 Freescale Semiconductor, Inc.
+ * Authors: Timur Tabi ti...@freescale.com
+ *
+ * FSL DIU Framebuffer driver
+ *
+ * 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 command.h
+#include asm/io.h
+
+#ifdef CONFIG_FSL_DIU_FB
+
+#include ../common/ngpixis.h
+#include ../common/fsl_diu_fb.h
+
+#ifdef CONFIG_VIDEO
+#include stdio_dev.h
+#include video_fb.h
+#endif
+
+#define PX_BRDCFG0_ELBC_DIU0x02
+
+#define PX_BRDCFG1_DVIEN 0x80
+#define PX_BRDCFG1_DFPEN 0x40
+#define PX_BRDCFG1_BACKLIGHT 0x20
+#define PX_BRDCFG1_DDCEN 0x10
+
+/*
+ * DIU Area Descriptor
+ *
+ * Note that we need to byte-swap the value before it's written to the AD
+ * register. So even though the registers don't look like they're in the same
+ * bit positions as they are on the MPC8610, the same value is written to the
+ * AD register on the MPC8610 and on the P1022.
+ */
+#define AD_BYTE_F 0x1000
+#define AD_ALPHA_C_MASK0x0E00
+#define AD_ALPHA_C_SHIFT 25
+#define AD_BLUE_C_MASK 0x0180
+#define AD_BLUE_C_SHIFT23
+#define AD_GREEN_C_MASK0x0060
+#define AD_GREEN_C_SHIFT 21
+#define AD_RED_C_MASK 0x0018
+#define AD_RED_C_SHIFT 19
+#define AD_PALETTE 0x0004
+#define AD_PIXEL_S_MASK0x0003
+#define AD_PIXEL_S_SHIFT 16
+#define AD_COMP_3_MASK 0xF000
+#define AD_COMP_3_SHIFT12
+#define AD_COMP_2_MASK 0x0F00
+#define AD_COMP_2_SHIFT8
+#define AD_COMP_1_MASK 0x00F0
+#define AD_COMP_1_SHIFT4
+#define AD_COMP_0_MASK 0x000F
+#define AD_COMP_0_SHIFT0
+
+#define AD_DEFAULT
+static int xres, yres;
+
+void diu_set_pixel_clock(unsigned int pixclock)
+{
+ ccsr_gur_t *gur = (void *)(CONFIG_SYS_MPC85xx_GUTS_ADDR);
+ unsigned long speed_ccb, temp;
+ u32 pixval;
+
+ speed_ccb = get_bus_freq(0);
+ temp = 10 / pixclock;
+ temp *= 1000;
+ pixval = speed_ccb / temp;
+ debug(DIU pixval = %lu\n, pixval);
+
+ /* Modify PXCLK in GUTS CLKDVDR */
+ temp = in_be32(gur-clkdvdr) 0x2000;
+ out_be32(gur-clkdvdr, temp); /* turn off clock */
+ out_be32(gur-clkdvdr, temp | 0x8000 | ((pixval 0x1F) 16));
+}
+
+int p1022ds_diu_init(void)
+{
+ ccsr_gur_t *gur = (void *)(CONFIG_SYS_MPC85xx_GUTS_ADDR);
+ char *monitor_port;
+ u32 pixel_format;
+ u8 temp;
+
+ pixel_format = cpu_to_le32(AD_BYTE_F | (3 AD_ALPHA_C_SHIFT) |
+ (0 AD_BLUE_C_SHIFT) | (1 AD_GREEN_C_SHIFT) |
+ (2 AD_RED_C_SHIFT) | (8 AD_COMP_3_SHIFT) |
+ (8 AD_COMP_2_SHIFT) | (8 AD_COMP_1_SHIFT) |
+ (8 AD_COMP_0_SHIFT) | (3 AD_PIXEL_S_SHIFT));
+
+ temp = in_8(pixis-brdcfg1);
+
+ monitor_port = getenv(monitor);
+ if (!strncmp(monitor_port, 1, 1)) { /* 1 - Single link LVDS */
+ xres = 1024;
+ yres = 768;
+ /* Enable the DFP port, disable the DVI and the backlight */
+ temp = ~(PX_BRDCFG1_DVIEN | PX_BRDCFG1_BACKLIGHT);
+ temp |= PX_BRDCFG1_DFPEN;
+ } else {/* DVI */
+ xres = 1280;
+ yres = 1024;
+ /* Enable the DVI port, disable the DFP and the backlight */
+ temp = ~(PX_BRDCFG1_DFPEN | PX_BRDCFG1_BACKLIGHT);
+ temp
Re: [U-Boot] warning: dereferencing pointer '({anonymous})' does break strict-aliasing rules
On Wed, Sep 1, 2010 at 12:01 PM, Mike Frysinger vap...@gentoo.org wrote: On Tuesday, August 31, 2010 18:30:39 Timur Tabi wrote: I ran Software Update on my Fedora 13 system, and now whenever I build U-Boot, I get a bunch of warnings like this: what version of u-boot exactly ? Any recent version. Every version I've tried has this problem. for what board/architecture ? It appears to be any PowerPC board. what is your host gcc version and your target gcc version ? $ gcc --version gcc (GCC) 4.4.4 20100630 (Red Hat 4.4.4-10) $ powerpc-linux-gnu-gcc --version powerpc-linux-gnu-gcc (Sourcery G++ Lite 4.4-194) 4.4.1 what is the exact compile line that causes this warning to be displayed ? powerpc-linux-gnu-gcc -g -Os -mrelocatable -fPIC -meabi -D__KERNEL__ -DTEXT_BASE=0xeff8 -DRESET_VECTOR_ADDRESS=0xeffc -I/home/b04825/git/u-boot.diu/include -fno-builtin -ffreestanding -nostdinc -isystem /opt/freescale/usr/local/gcc-4.4.194-eglibc-2.11.194/powerpc-linux-gnu/lib/gcc/powerpc-linux-gnu/4.4.1/include -pipe -DCONFIG_PPC -D__powerpc__ -ffixed-r2 -Wa,-me500 -msoft-float -mno-string -mspe=yes -mno-spe -Wall -Wstrict-prototypes -fno-stack-protector \ -o dlmalloc.o dlmalloc.c -c this is a pretty information-less bug report ... It's not a bug report. I was hoping that other people had already seen this, since I'm not doing anything special. -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] [v2] mpc8610: refactor DIU initialization code to use existing bitmap and logo features
The Freescale MPC8610 DIU code had re-implement two features that already
existed in U-Boot: bitmap drawing and top-of-screen logo (CONFIG_VIDEO_LOGO).
So delete the 8610-specific code and use the built-in features instead.
Signed-off-by: Timur Tabi ti...@freescale.com
---
This patch depends on the patch, logos: add Freescale logo
board/freescale/common/fsl_diu_fb.c | 132 +
board/freescale/common/fsl_diu_fb.h | 12 +--
board/freescale/mpc8610hpcd/mpc8610hpcd.c |6 +-
board/freescale/mpc8610hpcd/mpc8610hpcd_diu.c | 44 +---
include/configs/MPC8610HPCD.h |7 +-
5 files changed, 15 insertions(+), 186 deletions(-)
diff --git a/board/freescale/common/fsl_diu_fb.c
b/board/freescale/common/fsl_diu_fb.c
index e740ad8..394b71f 100644
--- a/board/freescale/common/fsl_diu_fb.c
+++ b/board/freescale/common/fsl_diu_fb.c
@@ -208,10 +208,7 @@ static int fsl_diu_disable_panel(struct fb_info *info);
static int allocate_buf(struct diu_addr *buf, u32 size, u32 bytes_align);
void diu_set_pixel_clock(unsigned int pixclock);
-int fsl_diu_init(int xres,
-unsigned int pixel_format,
-int gamma_fix,
-unsigned char *splash_bmp)
+int fsl_diu_init(int xres, unsigned int pixel_format, int gamma_fix)
{
struct fb_videomode *fsl_diu_mode_db;
struct diu_ad *ad = fsl_diu_fb_ad;
@@ -288,8 +285,6 @@ int fsl_diu_init(int xres,
var-sync = fsl_diu_mode_db-sync;
var-vmode = fsl_diu_mode_db-vmode;
info-line_length = var-xres * var-bits_per_pixel / 8;
- info-logo_size = 0;
- info-logo_height = 0;
ad-pix_fmt = pixel_format;
ad-addr= cpu_to_le32((unsigned int)info-screen_base);
@@ -358,13 +353,6 @@ int fsl_diu_init(int xres,
fb_initialized = 1;
- if (splash_bmp) {
- info-logo_height = fsl_diu_display_bmp(splash_bmp, 0, 0, 0);
- info-logo_size = info-logo_height * info-line_length;
- debug(logo height %d, logo_size 0x%x\n,
- info-logo_height,info-logo_size);
- }
-
/* Enable the DIU */
fsl_diu_enable_panel(info);
enable_lcdc();
@@ -375,8 +363,7 @@ int fsl_diu_init(int xres,
char *fsl_fb_open(struct fb_info **info)
{
*info = fsl_fb_info;
- return (char *) ((unsigned int)(*info)-screen_base
-+ (*info)-logo_size);
+ return fsl_fb_info.screen_base;
}
void fsl_diu_close(void)
@@ -485,118 +472,3 @@ static int allocate_buf(struct diu_addr *buf, u32 size,
u32 bytes_align)
buf-offset = 0;
return 0;
}
-
-int fsl_diu_display_bmp(unsigned char *bmp,
- int xoffset,
- int yoffset,
- int transpar)
-{
- struct fb_info *info = fsl_fb_info;
- unsigned char r, g, b;
- unsigned int *fb_t, val;
- unsigned char *bitmap;
- unsigned int palette[256];
- int width, height, bpp, ncolors, raster, offset, x, y, i, k, cpp;
-
- if (!bmp) {
- printf(Must supply a bitmap address\n);
- return 0;
- }
-
- raster = bmp[10] + (bmp[11] 8) + (bmp[12] 16) + (bmp[13] 24);
- width = (bmp[21] 24) | (bmp[20] 16) | (bmp[19] 8) | bmp[18];
- height = (bmp[25] 24) | (bmp[24] 16) | (bmp[23] 8) | bmp[22];
- bpp = (bmp[29] 8) | (bmp[28]);
- ncolors = bmp[46] + (bmp[47] 8) + (bmp[48] 16) + (bmp[49] 24);
- bitmap = bmp + raster;
- cpp = info-var.bits_per_pixel / 8;
-
- debug(bmp = 0x%08x\n, (unsigned int)bmp);
- debug(bitmap = 0x%08x\n, (unsigned int)bitmap);
- debug(width = %d\n, width);
- debug(height = %d\n, height);
- debug(bpp = %d\n, bpp);
- debug(ncolors = %d\n, ncolors);
-
- debug(xres = %d\n, info-var.xres);
- debug(yres = %d\n, info-var.yres);
- debug(Screen_base = 0x%x\n, (unsigned int)info-screen_base);
-
- if (((width+xoffset) info-var.xres) ||
- ((height+yoffset) info-var.yres)) {
- printf(bitmap is out of range, image too large or too much
offset\n);
- return 0;
- }
- if (bpp 24) {
- for (i = 0, offset = 54; i ncolors; i++, offset += 4)
- palette[i] = (bmp[offset+2] 16)
- + (bmp[offset+1] 8) + bmp[offset];
- }
-
- switch (bpp) {
- case 1:
- for (y = height - 1; y = 0; y--) {
- fb_t = (unsigned int *) ((unsigned
int)info-screen_base + (((y+yoffset) * info-var.xres) + xoffset)*cpp);
- for (x = 0; x width; x += 8) {
- b = *bitmap++;
- for (k = 0; k 8; k++) {
- if (b 0x80)
- *fb_t++ = palette[1
[U-Boot] warning: dereferencing pointer '({anonymous})' does break strict-aliasing rules
I ran Software Update on my Fedora 13 system, and now whenever I build
U-Boot, I get a bunch of warnings like this:
dlmalloc.c: In function 'malloc':
dlmalloc.c:2252: warning: dereferencing pointer '({anonymous})' does break
strict-aliasing rules
dlmalloc.c:2252: note: initialized from here
dlmalloc.c:2261: warning: dereferencing pointer '({anonymous})' does break
strict-aliasing rules
dlmalloc.c:2261: warning: dereferencing pointer '({anonymous})' does break
strict-aliasing rules
dlmalloc.c:2261: warning: dereferencing pointer '({anonymous})' does break
strict-aliasing rules
dlmalloc.c:2261: note: initialized from here
dlmalloc.c:2268: warning: dereferencing pointer '({anonymous})' does break
strict-aliasing rules
dlmalloc.c:2268: warning: dereferencing pointer '({anonymous})' does break
strict-aliasing rules
dlmalloc.c:2268: warning: dereferencing pointer '({anonymous})' does break
strict-aliasing rules
dlmalloc.c:2268: note: initialized from here
dlmalloc.c:2325: warning: dereferencing pointer '({anonymous})' does break
strict-aliasing rules
dlmalloc.c:2325: warning: dereferencing pointer '({anonymous})' does break
strict-aliasing rules
dlmalloc.c:2325: warning: dereferencing pointer '({anonymous})' does break
strict-aliasing rules
dlmalloc.c:2325: note: initialized from here
Can anyone explain why this is happening? I don't understand how a Fedora
update would change anything, since my cross-compile toolchain is not
distributed with Fedora, so it shouldn't have changed.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Why does logo_plot() not use video_display_bitmap()?
On Sun, Aug 29, 2010 at 3:56 AM, Wolfgang Denk w...@denx.de wrote: Because logo_plot() predates video_display_bitmap(), and the implementors of the latter function did not bother to clean up existing code? Ok, I just wanted to make sure there wasn't some technical limitations I didn't notice. I'll look into merging the two functions together. -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] video: cfb_console: fix definition and usage of CURSOR_xxx macros
The CURSOR_ON, CURSOR_OFF, and CURSOR_SET macros are defined incorrectly. If
cursor support is disabled, then these macros are defined to nothing, but
then they are used like this:
if (console_col CONSOLE_COLS)
CURSOR_OFF
console_row++;
which was compiled like this:
if (console_col CONSOLE_COLS)
console_row++;
This is obviously not what was intended.
Signed-off-by: Timur Tabi ti...@freescale.com
---
This patch depends on
video: cfb_console: add support for 4bpp bitmaps with GDF_32BIT_X888RGB
drivers/video/cfb_console.c | 24 ++--
1 files changed, 14 insertions(+), 10 deletions(-)
diff --git a/drivers/video/cfb_console.c b/drivers/video/cfb_console.c
index 1d52819..52e7fb4 100644
--- a/drivers/video/cfb_console.c
+++ b/drivers/video/cfb_console.c
@@ -230,8 +230,8 @@ CONFIG_VIDEO_HW_CURSOR: - Uses the hardware cursor
capability of the
#error only one of
CONFIG_CONSOLE_CURSOR,CONFIG_VIDEO_SW_CURSOR,CONFIG_VIDEO_HW_CURSOR can be
defined
#endif
void console_cursor (int state);
-#define CURSOR_ON console_cursor(1);
-#define CURSOR_OFF console_cursor(0);
+#define CURSOR_ON console_cursor(1)
+#define CURSOR_OFF console_cursor(0)
#define CURSOR_SET
#ifndef CONFIG_I8042_KBD
#warning Cursor drawing on/off needs timer function s.a. drivers/input/i8042.c
@@ -248,8 +248,8 @@ voidconsole_cursor (int state);
#endif
#define CURSOR_ON
#define CURSOR_OFF video_putchar(console_col * VIDEO_FONT_WIDTH,\
-console_row * VIDEO_FONT_HEIGHT, ' ');
-#define CURSOR_SET video_set_cursor();
+console_row * VIDEO_FONT_HEIGHT, ' ')
+#define CURSOR_SET video_set_cursor()
#endif /* CONFIG_VIDEO_SW_CURSOR */
@@ -260,7 +260,7 @@ voidconsole_cursor (int state);
#define CURSOR_ON
#define CURSOR_OFF
#define CURSOR_SET video_set_hw_cursor(console_col * VIDEO_FONT_WIDTH, \
- (console_row * VIDEO_FONT_HEIGHT) + video_logo_height);
+ (console_row * VIDEO_FONT_HEIGHT) + video_logo_height)
#endif /* CONFIG_VIDEO_HW_CURSOR */
#ifdef CONFIG_VIDEO_LOGO
@@ -651,7 +651,8 @@ static void console_scrollup (void)
static void console_back (void)
{
- CURSOR_OFF console_col--;
+ CURSOR_OFF;
+ console_col--;
if (console_col 0) {
console_col = CONSOLE_COLS - 1;
@@ -674,7 +675,7 @@ static void console_newline (void)
is = CONSOLE_COLS
*/
if (console_col CONSOLE_COLS)
- CURSOR_OFF
+ CURSOR_OFF;
console_row++;
console_col = 0;
@@ -690,7 +691,8 @@ static void console_newline (void)
static void console_cr (void)
{
- CURSOR_OFF console_col = 0;
+ CURSOR_OFF;
+ console_col = 0;
}
/*/
@@ -711,7 +713,8 @@ void video_putc (const char c)
break;
case 9: /* tab 8 */
- CURSOR_OFF console_col |= 0x0008;
+ CURSOR_OFF;
+ console_col |= 0x0008;
console_col = ~0x0007;
if (console_col = CONSOLE_COLS)
@@ -734,7 +737,8 @@ void video_putc (const char c)
nl = 0;
}
}
-CURSOR_SET}
+ CURSOR_SET;
+}
/*/
--
1.7.2.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] cmp_bmp: allow negative X, Y values for display command
I'm rescinding this patch. I have some new code that doesn't need this hack. On Wed, Aug 25, 2010 at 4:36 PM, Timur Tabi ti...@freescale.com wrote: The 'bmp display' command accepts optional X and Y values for the position of the image to be displayed. Change the code which parses the command line to accept negative values. This feature is useful if you want to use a frame buffer for the console, and you want a banner displayed on the top of the screen that never scrolls off. This can be accomplished by declaring that the width and height of the video screen is smaller than it really is, and then drawing an image in the undeclared area. For example, if you have 1280x1024 monitor, and you want to display a banner on the top of the screen that's 100 pixels tall, then video_hw_init() should say that display is really 1280x924, and then the banner should be drawn at position (0, -100). Signed-off-by: Timur Tabi ti...@freescale.com -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] mpc8610: refactor DIU initialization code to use existing bitmap function
I'm rescinding this patch. I'll have v2 some time next week. On Thu, Aug 26, 2010 at 3:59 PM, Timur Tabi ti...@freescale.com wrote: The Freescale MPC8610 DIU code has its own bitmap-drawing function, fsl_diu_display_bmp(), which is redundant. Instead, use the existing function video_display_bitmap(). Replacing fsl_diu_display_bmp() with video_display_bitmap() also requires refactoring the DIU initialization code. Signed-off-by: Timur Tabi ti...@freescale.com -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Why does logo_plot() not use video_display_bitmap()?
logo_plot() has its own code for rendering a bitmap, but this code is much less capable than video_display_bitmap(). Why doesn't logo_plot() just call video_display_bitmap() to draw the actual bitmap? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/3] mpc8610: refactor DIU initialization code to use existing bitmap function
The Freescale MPC8610 DIU code has its own bitmap-drawing function,
fsl_diu_display_bmp(), which is redundant. Instead, use the existing function
video_display_bitmap(). Replacing fsl_diu_display_bmp() with
video_display_bitmap() also requires refactoring the DIU initialization code.
Signed-off-by: Timur Tabi ti...@freescale.com
---
This patch requires this other patch:
video: cfb_console: add support for 4bpp bitmaps with GDF_32BIT_X888RGB
board/freescale/common/fsl_diu_fb.c | 155 +++-
board/freescale/common/fsl_diu_fb.h |7 +-
board/freescale/mpc8610hpcd/mpc8610hpcd.c | 16 ++-
board/freescale/mpc8610hpcd/mpc8610hpcd_diu.c | 100 ++--
include/configs/MPC8610HPCD.h |6 +-
5 files changed, 76 insertions(+), 208 deletions(-)
diff --git a/board/freescale/common/fsl_diu_fb.c
b/board/freescale/common/fsl_diu_fb.c
index e740ad8..e0ff466 100644
--- a/board/freescale/common/fsl_diu_fb.c
+++ b/board/freescale/common/fsl_diu_fb.c
@@ -27,6 +27,9 @@
#include i2c.h
#include malloc.h
#include asm/io.h
+#include bmp_layout.h
+#include stdio_dev.h
+#include video_fb.h
#include fsl_diu_fb.h
@@ -359,10 +362,15 @@ int fsl_diu_init(int xres,
fb_initialized = 1;
if (splash_bmp) {
- info-logo_height = fsl_diu_display_bmp(splash_bmp, 0, 0, 0);
+ /*
+* If we want a banner on top of the screen, we want to remember
+* its size here, so that video_hw_init() can set the right
+* display height.
+*/
+ bmp_header_t *bmp = (bmp_header_t *)splash_bmp;
+
+ info-logo_height = le32_to_cpu(bmp-height);
info-logo_size = info-logo_height * info-line_length;
- debug(logo height %d, logo_size 0x%x\n,
- info-logo_height,info-logo_size);
}
/* Enable the DIU */
@@ -486,117 +494,44 @@ static int allocate_buf(struct diu_addr *buf, u32 size,
u32 bytes_align)
return 0;
}
-int fsl_diu_display_bmp(unsigned char *bmp,
- int xoffset,
- int yoffset,
- int transpar)
+/*
+ * The Graphic Device
+ */
+static GraphicDevice ctfb;
+
+/* Board-specific video initialization */
+void __board_diu_init(void)
{
- struct fb_info *info = fsl_fb_info;
- unsigned char r, g, b;
- unsigned int *fb_t, val;
- unsigned char *bitmap;
- unsigned int palette[256];
- int width, height, bpp, ncolors, raster, offset, x, y, i, k, cpp;
-
- if (!bmp) {
- printf(Must supply a bitmap address\n);
- return 0;
- }
+}
+int board_diu_init(void) __attribute__((weak, alias(__board_diu_init)));
- raster = bmp[10] + (bmp[11] 8) + (bmp[12] 16) + (bmp[13] 24);
- width = (bmp[21] 24) | (bmp[20] 16) | (bmp[19] 8) | bmp[18];
- height = (bmp[25] 24) | (bmp[24] 16) | (bmp[23] 8) | bmp[22];
- bpp = (bmp[29] 8) | (bmp[28]);
- ncolors = bmp[46] + (bmp[47] 8) + (bmp[48] 16) + (bmp[49] 24);
- bitmap = bmp + raster;
- cpp = info-var.bits_per_pixel / 8;
-
- debug(bmp = 0x%08x\n, (unsigned int)bmp);
- debug(bitmap = 0x%08x\n, (unsigned int)bitmap);
- debug(width = %d\n, width);
- debug(height = %d\n, height);
- debug(bpp = %d\n, bpp);
- debug(ncolors = %d\n, ncolors);
-
- debug(xres = %d\n, info-var.xres);
- debug(yres = %d\n, info-var.yres);
- debug(Screen_base = 0x%x\n, (unsigned int)info-screen_base);
-
- if (((width+xoffset) info-var.xres) ||
- ((height+yoffset) info-var.yres)) {
- printf(bitmap is out of range, image too large or too much
offset\n);
- return 0;
- }
- if (bpp 24) {
- for (i = 0, offset = 54; i ncolors; i++, offset += 4)
- palette[i] = (bmp[offset+2] 16)
- + (bmp[offset+1] 8) + bmp[offset];
- }
+void *video_hw_init(void)
+{
+ struct fb_info *info;
- switch (bpp) {
- case 1:
- for (y = height - 1; y = 0; y--) {
- fb_t = (unsigned int *) ((unsigned
int)info-screen_base + (((y+yoffset) * info-var.xres) + xoffset)*cpp);
- for (x = 0; x width; x += 8) {
- b = *bitmap++;
- for (k = 0; k 8; k++) {
- if (b 0x80)
- *fb_t++ = palette[1];
- else
- *fb_t++ = palette[0];
- b = b 1;
- }
- }
- for (i = (width / 2) % 4; i 0; i--)
- bitmap
[U-Boot] [PATCH 2/2] cmp_bmp: allow negative X, Y values for display command
The 'bmp display' command accepts optional X and Y values for the position of the image to be displayed. Change the code which parses the command line to accept negative values. This feature is useful if you want to use a frame buffer for the console, and you want a banner displayed on the top of the screen that never scrolls off. This can be accomplished by declaring that the width and height of the video screen is smaller than it really is, and then drawing an image in the undeclared area. For example, if you have 1280x1024 monitor, and you want to display a banner on the top of the screen that's 100 pixels tall, then video_hw_init() should say that display is really 1280x924, and then the banner should be drawn at position (0, -100). Signed-off-by: Timur Tabi ti...@freescale.com --- common/cmd_bmp.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/common/cmd_bmp.c b/common/cmd_bmp.c index d51cc55..06c1547 100644 --- a/common/cmd_bmp.c +++ b/common/cmd_bmp.c @@ -122,8 +122,8 @@ static int do_bmp_display(cmd_tbl_t * cmdtp, int flag, int argc, char * const ar break; case 4: addr = simple_strtoul(argv[1], NULL, 16); - x = simple_strtoul(argv[2], NULL, 10); - y = simple_strtoul(argv[3], NULL, 10); + x = simple_strtol(argv[2], NULL, 10); + y = simple_strtol(argv[3], NULL, 10); break; default: return cmd_usage(cmdtp); -- 1.7.2.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] video: cfb_console: add support for 4bpp bitmaps with GDF_32BIT_X888RGB
Add support for 4bpp bitmaps, but only when writing to a GDF_32BIT_X888RGB.
Signed-off-by: Timur Tabi ti...@freescale.com
---
I only added support for GDF_32BIT_X888RGB because that's the only mode
that my video device supports in U-Boot. I wouldn't be able to test any
other mode, and it took a lot of trial and error to get this one mode working
correctly.
drivers/video/cfb_console.c | 26 +-
1 files changed, 25 insertions(+), 1 deletions(-)
diff --git a/drivers/video/cfb_console.c b/drivers/video/cfb_console.c
index fae5417..1d52819 100644
--- a/drivers/video/cfb_console.c
+++ b/drivers/video/cfb_console.c
@@ -1114,8 +1114,32 @@ int video_display_bitmap (ulong bmp_image, int x, int y)
}
#endif
- /* We handle only 8bpp or 24 bpp bitmap */
+ /* We handle only 4, 8, or 24 bpp bitmaps */
switch (le16_to_cpu (bmp-header.bit_count)) {
+ case 4:
+ padded_line -= width / 2;
+ ycount = height;
+
+ switch (VIDEO_DATA_FORMAT) {
+ case GDF_32BIT_X888RGB:
+ while (ycount--) {
+ WATCHDOG_RESET ();
+ /* Don't assume that 'width' is an even number
*/
+ for (xcount = 0; xcount width; xcount++) {
+ if (xcount 1) {
+ cte = bmp-color_table[*bmap
0xF];
+ bmap++;
+ } else
+ cte = bmp-color_table[*bmap
4];
+ FILL_32BIT_X888RGB(cte.red, cte.green,
cte.blue);
+ }
+ bmap += padded_line;
+ fb -= (VIDEO_VISIBLE_COLS + width) *
VIDEO_PIXEL_SIZE;
+ }
+ break;
+ }
+ break;
+
case 8:
padded_line -= width;
if (VIDEO_DATA_FORMAT == GDF__8BIT_INDEX) {
--
1.7.0.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] always relocate fdt into an lmb-allocated memory block
On Sat, Aug 7, 2010 at 6:36 PM, Wolfgang Denk w...@denx.de wrote: I would like to see any ACK or Tested-by: from actual users of this code. Kumar, who should ack this patch? -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-mpc85xx.git
/MPC8548CDS.h | 3 +- include/configs/MPC8555CDS.h | 3 +- include/configs/MPC8560ADS.h | 3 +- include/configs/MPC8568MDS.h | 3 +- include/configs/MPC8569MDS.h | 5 +- include/configs/MPC8572DS.h | 3 +- include/configs/MPC8641HPCN.h | 2 + include/configs/P1022DS.h | 1 + include/configs/P1_P2_RDB.h | 1 + include/configs/P2020DS.h | 21 +- include/configs/P4080DS.h | 35 + include/configs/TQM85xx.h | 1 + include/configs/XPEDITE5200.h | 1 + include/configs/XPEDITE5370.h | 1 + include/configs/corenet_ds.h | 673 include/configs/sbc8548.h | 1 + include/configs/socrates.h | 1 + include/configs/stxssa.h | 1 + include/ddr_spd.h | 14 + include/fdt_support.h | 1 + 71 files changed, 3933 insertions(+), 245 deletions(-) create mode 100644 arch/powerpc/cpu/mpc85xx/fsl_corenet_serdes.c create mode 100644 arch/powerpc/cpu/mpc85xx/fsl_corenet_serdes.h create mode 100644 arch/powerpc/cpu/mpc85xx/liodn.c create mode 100644 arch/powerpc/cpu/mpc85xx/p4080_ids.c create mode 100644 arch/powerpc/cpu/mpc85xx/p4080_serdes.c create mode 100644 arch/powerpc/cpu/mpc85xx/portals.c create mode 100644 arch/powerpc/include/asm/fsl_fman.h create mode 100644 arch/powerpc/include/asm/fsl_liodn.h create mode 100644 arch/powerpc/include/asm/fsl_portals.h create mode 100644 board/freescale/corenet_ds/Makefile create mode 100644 board/freescale/corenet_ds/config.mk create mode 100644 board/freescale/corenet_ds/corenet_ds.c create mode 100644 board/freescale/corenet_ds/ddr.c create mode 100644 board/freescale/corenet_ds/law.c create mode 100644 board/freescale/corenet_ds/pci.c create mode 100644 board/freescale/corenet_ds/tlb.c create mode 100644 include/configs/P4080DS.h create mode 100644 include/configs/corenet_ds.h ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-mpc85xx.git
Wolfgang Denk wrote: Dear Timur Tabi, In message aanlktino-ay_v0homz6vgp-vyyfehpsd3irvjdsf1...@mail.gmail.com you wrote: I have a patch that enables audio on the 1022, can you pick up that one too ? This is not exactly a bug fix, right? Audio is broken in Linux without this patch. It's something I neglected to incorporate when in my initial P1022DS patch. Perhaps enable is the wrong word, since the Linux audio driver doesn't detect the problem and just fails if U-Boot hasn't set up the signal routing correctly. And the merge window is closed. 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 Life is a garment we continuously alter, but which never seems to fit. - David McCord ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] always relocate fdt into an lmb-allocated memory block
Kumar, do you have any issues with this patch? I submitted it in May, but you never picked it up. On Mon, May 24, 2010 at 3:10 PM, Timur Tabi ti...@freescale.com wrote: The device tree (fdt) must always exist in within the bootmap (usually the first 16MB of RAM). If it doesn't, then boot_relocate_fdt() will allocate an LMB region in the bootmap and copy the fdt into that region. It will also increase the size of the fdt. If the fdt is already in the bootmap, then previously the memory was just reserved. There was no contingency if the reservation failed, however. By always allocating an lmb region and copying/resizing the fdt into that region, the code is simplified and the memory region is always allocated properly. Also change the types of some variables to avoid some typecasts. Signed-off-by: Timur Tabi -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] fsl: verify writes to the MAC address EEPROM
Update the code which writes to the on-board EEPROM so that it can detect if
the write failed because the EEPROM is write-protected. Most of the 8xxx-class
Freescale reference boards use an AT24C02 EEPROM to store MAC addresses and
similar information. With this patch, if the EEPROM is protected, the
mac save command will display an error message indicating that the write
has not succeeded.
Signed-off-by: Timur Tabi ti...@freescale.com
---
board/freescale/common/sys_eeprom.c | 18 +-
1 files changed, 17 insertions(+), 1 deletions(-)
diff --git a/board/freescale/common/sys_eeprom.c
b/board/freescale/common/sys_eeprom.c
index 5a8f4f5..c5f1c06 100644
--- a/board/freescale/common/sys_eeprom.c
+++ b/board/freescale/common/sys_eeprom.c
@@ -204,7 +204,7 @@ static void update_crc(void)
*/
static int prog_eeprom(void)
{
- int ret = 0; /* shut up gcc */
+ int ret = 0;
int i;
void *p;
#ifdef CONFIG_SYS_EEPROM_BUS_NUM
@@ -225,6 +225,11 @@ static int prog_eeprom(void)
i2c_set_bus_num(CONFIG_SYS_EEPROM_BUS_NUM);
#endif
+ /*
+* The AT24C02 datasheet says that data can only be written in page
+* mode, which means 8 bytes at a time, and it takes up to 5ms to
+* complete a given write.
+*/
for (i = 0, p = e; i sizeof(e); i += 8, p += 8) {
ret = i2c_write(CONFIG_SYS_I2C_EEPROM_ADDR, i,
CONFIG_SYS_I2C_EEPROM_ADDR_LEN,
p, min((sizeof(e) - i), 8));
@@ -233,12 +238,23 @@ static int prog_eeprom(void)
udelay(5000); /* 5ms write cycle timing */
}
+ if (!ret) {
+ /* Verify the write by reading back the EEPROM and comparing */
+ struct eeprom e2;
+
+ ret = i2c_read(CONFIG_SYS_I2C_EEPROM_ADDR, 0,
+ CONFIG_SYS_I2C_EEPROM_ADDR_LEN, (void *)e2,
sizeof(e2));
+ if (!ret memcmp(e, e2, sizeof(e)))
+ ret = -1;
+ }
+
#ifdef CONFIG_SYS_EEPROM_BUS_NUM
i2c_set_bus_num(bus);
#endif
if (ret) {
printf(Programming failed.\n);
+ has_been_read = 0;
return -1;
}
--
1.7.0.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fsl: verify writes to the MAC address EEPROM
Wolfgang Denk wrote: Why is this i2c_read() needed or actually useful? Should the error return code from the i2c_write() above not be sufficient indication that the writing failed? If that was the case, then some other parts of the code need fixing. That's just the way the EEPROM chip works. When it's set into write-protect mode, it cheerfully accepts all of the I2C write commands, and acknowledges them appropriately, but it doesn't actually store the data into the EEPROM. The read-back is the only way I've found to verify that the write has actually occurred. This patch fixes a real problem with all of our boards that use this EEPROM chip, which is almost all of our 83xx, 85xx, and 86xx boards. Some of our boards would be shipped with EEPROM write-protected. The current code caches the EEPROM contents in memory. After using the mac save command, the code would think that the EEPROM was updated. Issuing the mac read command again would *not* re-read from the EEPROM, because the code would think that the cached value is up-to-date. The only way you would know if the EEPROM write failed is to reboot the board. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-mpc85xx.git
Wolfgang Denk wrote: Without this patch, audio support on the P1022DS is completely broken. We don't have audio support in U-Boot, do we? But we do have P1022DS board support, and my understanding is that part of the function of U-Boot is to prepare the board so that it can be used by Linux, or whatever OS it boots. Besides, there's tons of hardware that is not supported by U-Boot but must be initialized by U-Boot anyway. Once there was a good old tradition that a driver in an OS makes sure to initialize the hardware as it needs it for reliable operation. I think I remember to have seen this requested for Linux drivers not so long ago. Well, now we're talking about a very old issue that always raises disagreement -- exactly what should U-Boot be doing vs. Linux. And this is something that changes over time. For example, QE pin muxing used to be done in U-Boot, but now it's done in Linux. Well, except for the QE features that U-Boot uses. In that case, it's done in U-Boot *and* Linux. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-mpc85xx.git
Wolfgang Denk wrote: Audio is broken in Linux without this patch. It's something I neglected to incorporate when in my initial P1022DS patch. Well, this is U-Boot, not Linux. I supposed it depends on your definition of a bug. If it's not doing something that it's supposed to be doing, and something else is broken because of it, is that a bug? Without this patch, audio support on the P1022DS is completely broken. Perhaps enable is the wrong word, since the Linux audio driver doesn't detect the problem and just fails if U-Boot hasn't set up the signal routing correctly. Sounds as if this should be fixed in Linux (too) ? This has to do with enabling clock signals and pin muxing, something which is (IMHO) handled better in U-Boot than in Linux. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fsl: verify writes to the MAC address EEPROM
Wolfgang Denk wrote: Is it correct to assume the the WP signal is connected to some GPIO pin which can be set / unset in software? No, it's a dip switch on the board. You have to physically set the dip switch in order write protect or unprotect the EEPROM. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fsl: verify writes to the MAC address EEPROM
Wolfgang Denk wrote: And the setting cannot be read back through some GPIO pin eitheer? Technically, the FPGA (on ngPIXIS boards, of which there are only a few) reads all of the switches and allows software to set and read the values. But I've found it to be unreliable. For example, on one board, SW7 is set to 1101, but the ngPIXIS shows . And even if it were reliable, it wouldn't help, because the ngPIXIS reads the software-programmable settings only on boot time. So in order for me to override the dip switch, I would need to program the right value and then reboot the board. And that assumes that the board doesn't have a broken FPGA firmware. I believe the current version is 11, or maybe 13. The version on my board is 4. The majority of our boards that use this EEPROM don't have an ngPIXIS, they have the old-style PIXIS, which definitely does not allow software to read/set any dip switches. And this isn't the worst part of our designs. On the P1022, for example, the same pins are used for the DVI signals and the local bus (used for NOR flash), so it's not possible to use flash memory while the video display is active. That means we can't turn on the video until after relocation, and when we do, we lose the ability to update flash. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] p1022ds: add audclk hwconfig setting enable codec reference clock
The Freescale P1022DS can use either a 12.288MHz or a 11.2896MHz reference
clock for the audio codec, but by default both are disabled. Add a 'audclk'
hwconfig option that allows the user to choose which clock he wants.
The 12.288MHz clock allows the codec to use sampling rates of 16, 24, 32, 48,
64, and 96KHz. The 11.2896 clock allows 14700, 22050, 29400, 44100, 58800, and
88200Hz.
Also configure a pin muxing to select some SSI signals, which will disable
I2C1.
Signed-off-by: Timur Tabi ti...@freescale.com
---
board/freescale/p1022ds/p1022ds.c | 67 -
include/configs/P1022DS.h |1 +
2 files changed, 59 insertions(+), 9 deletions(-)
diff --git a/board/freescale/p1022ds/p1022ds.c
b/board/freescale/p1022ds/p1022ds.c
index be692cb..e75f864 100644
--- a/board/freescale/p1022ds/p1022ds.c
+++ b/board/freescale/p1022ds/p1022ds.c
@@ -27,6 +27,7 @@
#include asm/mp.h
#include netdev.h
#include i2c.h
+#include hwconfig.h
#include ../common/ngpixis.h
@@ -90,34 +91,58 @@ phys_size_t initdram(int board_type)
#define CONFIG_TFP410_I2C_ADDR 0x38
+/* Masks for the SSI_TDM and AUDCLK bits of the ngPIXIS BRDCFG1 register. */
+#define CONFIG_PIXIS_BRDCFG1_SSI_TDM_MASK 0x0c
+#define CONFIG_PIXIS_BRDCFG1_AUDCLK_MASK 0x03
+
+/* Route the I2C1 pins to the SSI port instead. */
+#define CONFIG_PIXIS_BRDCFG1_SSI_TDM_SSI 0x08
+
+/* Choose the 12.288Mhz codec reference clock */
+#define CONFIG_PIXIS_BRDCFG1_AUDCLK_12 0x02
+
+/* Choose the 11.2896Mhz codec reference clock */
+#define CONFIG_PIXIS_BRDCFG1_AUDCLK_11 0x01
+
int misc_init_r(void)
{
u8 temp;
+ const char *audclk;
+ size_t arglen;
- /* Enable the TFP410 Encoder */
+ /* For DVI, enable the TFP410 Encoder. */
temp = 0xBF;
if (i2c_write(CONFIG_TFP410_I2C_ADDR, 0x08, 1, temp, sizeof(temp)) 0)
return -1;
-
- /* Verify if enabled */
- temp = 0;
if (i2c_read(CONFIG_TFP410_I2C_ADDR, 0x08, 1, temp, sizeof(temp)) 0)
return -1;
-
debug(DVI Encoder Read: 0x%02x\n, temp);
temp = 0x10;
if (i2c_write(CONFIG_TFP410_I2C_ADDR, 0x0A, 1, temp, sizeof(temp)) 0)
return -1;
-
- /* Verify if enabled */
- temp = 0;
if (i2c_read(CONFIG_TFP410_I2C_ADDR, 0x0A, 1, temp, sizeof(temp)) 0)
return -1;
-
debug(DVI Encoder Read: 0x%02x\n,temp);
+ /*
+* Enable the reference clock for the WM8776 codec, and route the MUX
+* pins for SSI. The default is the 12.288 MHz clock
+*/
+
+ temp = in_8(pixis-brdcfg1) ~(CONFIG_PIXIS_BRDCFG1_SSI_TDM_MASK |
+ CONFIG_PIXIS_BRDCFG1_AUDCLK_MASK);
+ temp |= CONFIG_PIXIS_BRDCFG1_SSI_TDM_SSI;
+
+ audclk = hwconfig_arg(audclk, arglen);
+ /* Check the first two chars only */
+ if (audclk (strncmp(audclk, 11, 2) == 0))
+ temp |= CONFIG_PIXIS_BRDCFG1_AUDCLK_11;
+ else
+ temp |= CONFIG_PIXIS_BRDCFG1_AUDCLK_12;
+ out_8(pixis-brdcfg1, temp);
+
return 0;
}
@@ -310,6 +335,27 @@ int board_eth_init(bd_t *bis)
}
#ifdef CONFIG_OF_BOARD_SETUP
+/**
+ * ft_codec_setup - fix up the clock-frequency property of the codec node
+ *
+ * Update the clock-frequency property based on the value of the 'audclk'
+ * hwconfig option. If audclk is not specified, then default to 12.288MHz.
+ */
+static void ft_codec_setup(void *blob, const char *compatible)
+{
+ const char *audclk;
+ size_t arglen;
+ u32 freq;
+
+ audclk = hwconfig_arg(audclk, arglen);
+ if (audclk (strncmp(audclk, 11, 2) == 0))
+ freq = 11289600;
+ else
+ freq = 12288000;
+
+ do_fixup_by_compat_u32(blob, compatible, clock-frequency, freq, 1);
+}
+
void ft_board_setup(void *blob, bd_t *bd)
{
phys_addr_t base;
@@ -343,6 +389,9 @@ void ft_board_setup(void *blob, bd_t *bd)
#ifdef CONFIG_FSL_SGMII_RISER
fsl_sgmii_riser_fdt_fixup(blob);
#endif
+
+ /* Update the WM8776 node's clock frequency property */
+ ft_codec_setup(blob, wlf,wm8776);
}
#endif
diff --git a/include/configs/P1022DS.h b/include/configs/P1022DS.h
index b42b5d0..0f7aca2 100644
--- a/include/configs/P1022DS.h
+++ b/include/configs/P1022DS.h
@@ -137,6 +137,7 @@
#define CONFIG_BOARD_EARLY_INIT_F
#define CONFIG_BOARD_EARLY_INIT_R
#define CONFIG_MISC_INIT_R
+#define CONFIG_HWCONFIG
#define CONFIG_FSL_NGPIXIS
#define PIXIS_BASE 0xffdf /* PIXIS registers */
--
1.7.0.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] [v2] p1022ds: add audclk hwconfig setting enable codec reference clock
The Freescale P1022DS can use either a 12.288MHz or a 11.2896MHz reference
clock for the audio codec, but by default both are disabled. Add a 'audclk'
hwconfig option that allows the user to choose which clock he wants.
The 12.288MHz clock allows the codec to use sampling rates of 16, 24, 32, 48,
64, and 96KHz. The 11.2896 clock allows 14700, 22050, 29400, 44100, 58800, and
88200Hz.
Also configure a pin muxing to select some SSI signals, which will disable
I2C1.
Signed-off-by: Timur Tabi ti...@freescale.com
---
board/freescale/p1022ds/p1022ds.c | 67 -
doc/README.fsl-hwconfig | 21 +++
include/configs/P1022DS.h |1 +
3 files changed, 80 insertions(+), 9 deletions(-)
create mode 100644 doc/README.fsl-hwconfig
diff --git a/board/freescale/p1022ds/p1022ds.c
b/board/freescale/p1022ds/p1022ds.c
index be692cb..e75f864 100644
--- a/board/freescale/p1022ds/p1022ds.c
+++ b/board/freescale/p1022ds/p1022ds.c
@@ -27,6 +27,7 @@
#include asm/mp.h
#include netdev.h
#include i2c.h
+#include hwconfig.h
#include ../common/ngpixis.h
@@ -90,34 +91,58 @@ phys_size_t initdram(int board_type)
#define CONFIG_TFP410_I2C_ADDR 0x38
+/* Masks for the SSI_TDM and AUDCLK bits of the ngPIXIS BRDCFG1 register. */
+#define CONFIG_PIXIS_BRDCFG1_SSI_TDM_MASK 0x0c
+#define CONFIG_PIXIS_BRDCFG1_AUDCLK_MASK 0x03
+
+/* Route the I2C1 pins to the SSI port instead. */
+#define CONFIG_PIXIS_BRDCFG1_SSI_TDM_SSI 0x08
+
+/* Choose the 12.288Mhz codec reference clock */
+#define CONFIG_PIXIS_BRDCFG1_AUDCLK_12 0x02
+
+/* Choose the 11.2896Mhz codec reference clock */
+#define CONFIG_PIXIS_BRDCFG1_AUDCLK_11 0x01
+
int misc_init_r(void)
{
u8 temp;
+ const char *audclk;
+ size_t arglen;
- /* Enable the TFP410 Encoder */
+ /* For DVI, enable the TFP410 Encoder. */
temp = 0xBF;
if (i2c_write(CONFIG_TFP410_I2C_ADDR, 0x08, 1, temp, sizeof(temp)) 0)
return -1;
-
- /* Verify if enabled */
- temp = 0;
if (i2c_read(CONFIG_TFP410_I2C_ADDR, 0x08, 1, temp, sizeof(temp)) 0)
return -1;
-
debug(DVI Encoder Read: 0x%02x\n, temp);
temp = 0x10;
if (i2c_write(CONFIG_TFP410_I2C_ADDR, 0x0A, 1, temp, sizeof(temp)) 0)
return -1;
-
- /* Verify if enabled */
- temp = 0;
if (i2c_read(CONFIG_TFP410_I2C_ADDR, 0x0A, 1, temp, sizeof(temp)) 0)
return -1;
-
debug(DVI Encoder Read: 0x%02x\n,temp);
+ /*
+* Enable the reference clock for the WM8776 codec, and route the MUX
+* pins for SSI. The default is the 12.288 MHz clock
+*/
+
+ temp = in_8(pixis-brdcfg1) ~(CONFIG_PIXIS_BRDCFG1_SSI_TDM_MASK |
+ CONFIG_PIXIS_BRDCFG1_AUDCLK_MASK);
+ temp |= CONFIG_PIXIS_BRDCFG1_SSI_TDM_SSI;
+
+ audclk = hwconfig_arg(audclk, arglen);
+ /* Check the first two chars only */
+ if (audclk (strncmp(audclk, 11, 2) == 0))
+ temp |= CONFIG_PIXIS_BRDCFG1_AUDCLK_11;
+ else
+ temp |= CONFIG_PIXIS_BRDCFG1_AUDCLK_12;
+ out_8(pixis-brdcfg1, temp);
+
return 0;
}
@@ -310,6 +335,27 @@ int board_eth_init(bd_t *bis)
}
#ifdef CONFIG_OF_BOARD_SETUP
+/**
+ * ft_codec_setup - fix up the clock-frequency property of the codec node
+ *
+ * Update the clock-frequency property based on the value of the 'audclk'
+ * hwconfig option. If audclk is not specified, then default to 12.288MHz.
+ */
+static void ft_codec_setup(void *blob, const char *compatible)
+{
+ const char *audclk;
+ size_t arglen;
+ u32 freq;
+
+ audclk = hwconfig_arg(audclk, arglen);
+ if (audclk (strncmp(audclk, 11, 2) == 0))
+ freq = 11289600;
+ else
+ freq = 12288000;
+
+ do_fixup_by_compat_u32(blob, compatible, clock-frequency, freq, 1);
+}
+
void ft_board_setup(void *blob, bd_t *bd)
{
phys_addr_t base;
@@ -343,6 +389,9 @@ void ft_board_setup(void *blob, bd_t *bd)
#ifdef CONFIG_FSL_SGMII_RISER
fsl_sgmii_riser_fdt_fixup(blob);
#endif
+
+ /* Update the WM8776 node's clock frequency property */
+ ft_codec_setup(blob, wlf,wm8776);
}
#endif
diff --git a/doc/README.fsl-hwconfig b/doc/README.fsl-hwconfig
new file mode 100644
index 000..03fea74
--- /dev/null
+++ b/doc/README.fsl-hwconfig
@@ -0,0 +1,21 @@
+Freescale-specific 'hwconfig' options.
+
+This file documents Freescale-specific key:value pairs for the 'hwconfig'
+option. See README.hwconfig for general information about 'hwconfig'.
+
+audclk
+ Specific to the P1022DS reference board.
+
+ This option specifies which of the two oscillator frequencies should be
+ routed to the Wolfson WM8776 codec. The ngPIXIS can be programmed to
+ route either a 11.2896MHz or a 12.288MHz clock. The default is
+ 12.288MHz. This option has two
Re: [U-Boot] [PATCH] p1022ds: add audclk hwconfig setting enable codec reference clock
BTW, the subject line should read: add audclk hwconfig setting to enable codec reference clock Sorry about that. On Wed, Jul 21, 2010 at 4:26 PM, Timur Tabi ti...@freescale.com wrote: The Freescale P1022DS can use either a 12.288MHz or a 11.2896MHz reference clock for the audio codec, but by default both are disabled. Add a 'audclk' hwconfig option that allows the user to choose which clock he wants. -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] p1022ds: fix indentation of case statement
Signed-off-by: Timur Tabi ti...@freescale.com
---
board/freescale/p1022ds/p1022ds.c | 20 ++--
1 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/board/freescale/p1022ds/p1022ds.c
b/board/freescale/p1022ds/p1022ds.c
index 8cc73ed..be692cb 100644
--- a/board/freescale/p1022ds/p1022ds.c
+++ b/board/freescale/p1022ds/p1022ds.c
@@ -60,16 +60,16 @@ int checkboard(void)
sw = in_8(PIXIS_SW(PIXIS_LBMAP_SWITCH));
switch ((sw PIXIS_LBMAP_MASK) 6) {
- case 0:
- printf (vBank: %u\n, ((sw 0x30) 4));
- break;
- case 1:
- printf (NAND\n);
- break;
- case 2:
- case 3:
- puts (Promjet\n);
- break;
+ case 0:
+ printf (vBank: %u\n, ((sw 0x30) 4));
+ break;
+ case 1:
+ printf (NAND\n);
+ break;
+ case 2:
+ case 3:
+ puts (Promjet\n);
+ break;
}
return 0;
--
1.7.0.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 8/8] powerpc/85xx: Add memory test feature for mpc85xx.
On Wed, Jul 14, 2010 at 3:16 PM, Wolfgang Denk w...@denx.de wrote: NAK. Please do not reinvent the wheel and add yet another meory test. Use one of the existing memory tests we already have - post/drivers/memory.c comes to mind. That code is not capable of testing more than 2GB of RAM. It assumes that memory has already been initialized, but on PowerPC parts, we only ever map 2GB of DDR. We need a memory test that covers all of DDR, but that requries PowerPC-specific code to create sliding TLB windows during the memory test. -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] fdt: Add function to alloc phandle values
On Sat, Jul 10, 2010 at 8:25 AM, Kumar Gala ga...@kernel.crashing.org wrote: If we are creating reference (handles) to nodes in a device tree we need to first create a new phandle in node and this needs a new phandle value. So we search through the whole dtb to find the max phandle value and return the next greater value for a new phandle allocation. Signed-off-by: Kumar Gala ga...@kernel.crashing.org I still think you should merge my fdt_get_max_phandle() function into this patch. The two functions are related and can share code. -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] at91sam9g20 MAC address in EEPROM?
On Sat, Jul 10, 2010 at 7:53 AM, Jim Sheldon j...@russound.com wrote: Hello everyone, I am working on a product based on Atmel's sam9g20. Atmel's flashing procedure stores the MAC address as a u-boot environment variable (ethaddr). We are not comfortable with storing the MAC address this way, and would rather keep it in EEPROM. Does anyone have experience with this? Not on that chip, but we do it for Freescale PowerPC SOCs. Take a look at board/freescale/common/sys_eeprom.c -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] powerpc/86xx: Rename PCI1/2 to PCIE1/2 on MPC8641HPCN SBC8641
On Fri, Jul 9, 2010 at 12:18 AM, Kumar Gala ga...@kernel.crashing.org wrote: The MPC8641 boards actually only have PCIE not PCI. Rename so we are uniform with regards to names so we can replace this code with templated code. The subject line of this patch is backwards. It should be Rename PCIE1/2 to PCI1/2. Personally, I would drop the 1/2 as well. -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] powerpc/86xx: Rename PCI1/2 to PCIE1/2 on MPC8641HPCN SBC8641
On Fri, Jul 9, 2010 at 9:20 AM, Kumar Gala ga...@kernel.crashing.org wrote: Huh, I'm going from PCI1 - PCIE1 Sorry, I got confused. I really should stop reading patches before I had my coffee. -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fdt: Add function to alloc phandle values
On Fri, Jul 9, 2010 at 4:22 PM, Kumar Gala ga...@kernel.crashing.org wrote:
+int fdt_alloc_phandle(void *blob)
+{
+ int offset, len, phandle = 0;
+ const u32 *val;
+ for (offset = fdt_next_node(blob, -1, NULL); offset = 0;
+ offset = fdt_next_node(blob, offset, NULL)) {
+ val = fdt_getprop(blob, offset, linux,phandle, len);
+ if (val) phandle = max(*val, phandle);
+ }
+ return phandle + 1;
+}
If you incorporate my patch titled, libfdt: introduce function
fdt_get_max_phandle, you can simplify this function.
Wolfgang rejected that patch because I didn't include any code that
called fdt_get_max_phandle(). I see you're doing the same thing here
with fdt_alloc_phandle(). It will be interesting to see if Wolfgang
rejects your patch.
--
Timur Tabi
Linux kernel developer at Freescale
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] fdt_resize() bug caused WARNING: could not set linux, initrd-start FDT_ERR_NOSPACE.
On Wed, Jun 23, 2010 at 1:20 PM, Wang, Feng fwan...@harris.com wrote: My fix is in fdt_resize(), leave at least 4 fdt_reserve_entry for initrd. So instead of 2*sizeof(struct fdt_reserve_entry) for actual_totalsize, use 5*sizeof(struc fdt_reserve_entry). You could also use the -R parameter when building the device tree. -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] [v3] powerpc: add support for the Freescale P1022DS reference board
Kumar, please don't forget this patch. On Mon, Jun 14, 2010 at 3:28 PM, Timur Tabi ti...@freescale.com wrote: Add basic suport for the Freescale P1022DS reference board. Specifics: 1) 36-bit only 2) Booting from NOR flash only 3) Environment stored in NOR flash only 4) No SPI support 5) No DIU support Signed-off-by: Timur Tabi ti...@freescale.com -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] [v3] powerpc: add support for the Freescale P1022DS reference board
On Wed, Jun 30, 2010 at 9:02 AM, Kumar Gala ga...@kernel.crashing.org wrote: On Jun 30, 2010, at 8:55 AM, Timur Tabi wrote: Kumar, please don't forget this patch. It applies against Wolfgang's 'next' branch. Have you updated your branch to pull in the new Makefile code? -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] examples/standalone: Remove relocation compile flags for PowerPC
On Tue, Jun 15, 2010 at 10:37 PM, Peter Tyser pty...@xes-inc.com wrote: It looks like the -fno-toplevel-reorder flag is only available in gcc = 4.2 (http://gcc.gnu.org/gcc-4.2/changes.html released May 2007). So, do we add support to U-Boot to conditionally check for the gcc version like Linux to know when to use -fno-toplevel-reorder? Or do we use a linker script that would support more versions of gcc at the cost of more complexity? What happens if you use the flag on earlier versions of gcc? If the flag is just silently ignored, then maybe it's not such a big deal to always include it, and just add a comment saying that it only works on gcc 4.2 or higher? -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] examples/standalone: Remove relocation compile flags for PowerPC
Peter Tyser wrote: Previously, standalone applications were compiled with gcc flags that produced relocatable executables on the PowerPC architecture (eg with the -mrelocatable and -fPIC flags). There's no reason for these applications to be fully relocatable at this time since no relocation fixups are performed on standalone applications. This didn't work for me. The entry point for my application in 401b4. Here's the build output: make[1]: Entering directory `/home/b04825/git/u-boot.4737/examples/standalone' powerpc-linux-gnu-gcc -g -Os -mrelocatable -fPIC -ffixed-r14 -meabi -D__KERNEL__ -DTEXT_BASE=0xeff8 -DRESET_VECTOR_ADDRESS=0xeffc -I/home/b04825/git/u-boot.4737/include -fno-builtin -ffreestanding -nostdinc -isystem /opt/freescale/usr/local/gcc-4.3.74-eglibc-2.8.74-6/powerpc-linux-gnu/bin/../lib/gcc/powerpc-linux-gnu/4.3.2/include -pipe -DCONFIG_PPC -D__powerpc__ -ffixed-r2 -Wa,-me500 -msoft-float -mno-string -mspe=yes -mno-spe -Wall -Wstrict-prototypes -fno-stack-protector -o flash_wp.o flash_wp.c -c powerpc-linux-gnu-ar crv libstubs.a ppc_longjmp.o ppc_setjmp.o stubs.o r - ppc_longjmp.o r - ppc_setjmp.o r - stubs.o powerpc-linux-gnu-ld -g -Ttext 0x4 \ -o hello_world -e hello_world hello_world.o libstubs.a \ -L/opt/freescale/usr/local/gcc-4.3.74-eglibc-2.8.74-6/powerpc-linux-gnu/bin/../lib/gcc/powerpc-linux-gnu/4.3.2 -lgcc powerpc-linux-gnu-objcopy -O srec hello_world hello_world.srec 2/dev/null powerpc-linux-gnu-ld -g -Ttext 0x4 \ -o flash_wp -e flash_wp flash_wp.o libstubs.a \ -L/opt/freescale/usr/local/gcc-4.3.74-eglibc-2.8.74-6/powerpc-linux-gnu/bin/../lib/gcc/powerpc-linux-gnu/4.3.2 -lgcc powerpc-linux-gnu-objcopy -O srec flash_wp flash_wp.srec 2/dev/null powerpc-linux-gnu-ld -g -Ttext 0x4 \ -o sched -e sched sched.o libstubs.a \ -L/opt/freescale/usr/local/gcc-4.3.74-eglibc-2.8.74-6/powerpc-linux-gnu/bin/../lib/gcc/powerpc-linux-gnu/4.3.2 -lgcc powerpc-linux-gnu-objcopy -O srec sched sched.srec 2/dev/null powerpc-linux-gnu-objcopy -O binary hello_world hello_world.bin 2/dev/null powerpc-linux-gnu-objcopy -O binary flash_wp flash_wp.bin 2/dev/null powerpc-linux-gnu-objcopy -O binary sched sched.bin 2/dev/null make[1]: Leaving directory `/home/b04825/git/u-boot.4737/examples/standalone' ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] examples/standalone: Remove relocation compile flags for PowerPC
Timur Tabi wrote: Peter Tyser wrote: Previously, standalone applications were compiled with gcc flags that produced relocatable executables on the PowerPC architecture (eg with the -mrelocatable and -fPIC flags). There's no reason for these applications to be fully relocatable at this time since no relocation fixups are performed on standalone applications. This didn't work for me. The entry point for my application in 401b4. So if I comment-out the ifeq, like this: #ifeq ($(ARCH),powerpc) CFLAGS := $(filter-out $(RELFLAGS),$(CFLAGS)) #endif and build, I get these errors: powerpc-linux-gnu-ld: libstubs.a(ppc_longjmp.o): compiled with -mrelocatable and linked with modules compiled normally powerpc-linux-gnu-ld: failed to merge target specific data of file libstubs.a(ppc_longjmp.o) powerpc-linux-gnu-ld: libstubs.a(ppc_setjmp.o): compiled with -mrelocatable and linked with modules compiled normally powerpc-linux-gnu-ld: failed to merge target specific data of file libstubs.a(ppc_setjmp.o) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] examples/standalone: Remove relocation compile flags for PowerPC
Peter Tyser wrote: Can you do a 'make clean', then recompile? That *was* with a 'make clean'. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] examples/standalone: Remove relocation compile flags for PowerPC
Wolfgang Denk wrote:
I think the timer code is sufficient to show the problem, and that
your fix helps. If Timur confirms it's working for his secret code
too we should apply this.
Doing this at the top of my source file:
static int __flash_wp(int argc, char *argv[]);
int flash_wp(int argc, char *argv[])
{
return __flash_wp(argc, argv);
}
and then adding this line:
CFLAGS += -fno-toplevel-reorder
was all I needed to get my entry point to appear at 4 without needing to
define any more forward references or caring about the order of the
functions in the file.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] examples/standalone: Remove relocation compile flags for PowerPC
Wolfgang Denk wrote: I think the static int __flash_wp() thing is not even needed assuming that flash_wp() is the first function in your file. That's the thing -- I don't want flash_wp() to be the first function in my file. I would then need a forward reference to all the other functions in my file, and I hate doing that. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] [v3] powerpc: add support for the Freescale P1022DS reference board
Add basic suport for the Freescale P1022DS reference board.
Specifics:
1) 36-bit only
2) Booting from NOR flash only
3) Environment stored in NOR flash only
4) No SPI support
5) No DIU support
Signed-off-by: Timur Tabi ti...@freescale.com
---
This patch is for the 'next' branch.
v3: Fixed minor issues, ported to new makefile format
v2: addresses most of Wolfgang's concerns.
DIU support removed so that it can be reworked later
This depends on the following patches:
Move ICS CLK chip frequenty calculation code into a common board library
fsl: add LAW target to fsl_pci_info structure
MAINTAINERS |1 +
MAKEALL |1 +
arch/powerpc/cpu/mpc85xx/Makefile |1 +
arch/powerpc/cpu/mpc85xx/p1022_serdes.c | 166 +++
arch/powerpc/include/asm/fsl_serdes.h |2 +
board/freescale/common/Makefile |1 +
board/freescale/p1022ds/Makefile| 39 +++
board/freescale/p1022ds/config.mk | 14 +
board/freescale/p1022ds/ddr.c | 106 +++
board/freescale/p1022ds/law.c | 21 ++
board/freescale/p1022ds/p1022ds.c | 285 +++
board/freescale/p1022ds/tlb.c | 76 +
boards.cfg |1 +
include/configs/P1022DS.h | 470 +++
14 files changed, 1184 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/cpu/mpc85xx/p1022_serdes.c
create mode 100644 board/freescale/p1022ds/Makefile
create mode 100644 board/freescale/p1022ds/config.mk
create mode 100644 board/freescale/p1022ds/ddr.c
create mode 100644 board/freescale/p1022ds/law.c
create mode 100644 board/freescale/p1022ds/p1022ds.c
create mode 100644 board/freescale/p1022ds/tlb.c
create mode 100644 include/configs/P1022DS.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 7a13d28..d702f0d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -437,6 +437,7 @@ Timur Tabi ti...@freescale.com
MPC8349E-mITX MPC8349
MPC8349E-mITX-GP MPC8349
+ P1022DS P1022
Erik Theisen ethei...@mindspring.com
diff --git a/MAKEALL b/MAKEALL
index 2527352..858f7d4 100755
--- a/MAKEALL
+++ b/MAKEALL
@@ -406,6 +406,7 @@ LIST_85xx= \
MPC8569MDS_NAND \
MPC8572DS \
MPC8572DS_36BIT \
+ P1022DS \
P2020DS \
P2020DS_36BIT \
P1011RDB\
diff --git a/arch/powerpc/cpu/mpc85xx/Makefile
b/arch/powerpc/cpu/mpc85xx/Makefile
index f064fee..a481326 100644
--- a/arch/powerpc/cpu/mpc85xx/Makefile
+++ b/arch/powerpc/cpu/mpc85xx/Makefile
@@ -63,6 +63,7 @@ COBJS-$(CONFIG_CPM2) += ether_fcc.o
COBJS-$(CONFIG_OF_LIBFDT) += fdt.o
COBJS-$(CONFIG_MP) += mp.o
COBJS-$(CONFIG_MPC8536) += mpc8536_serdes.o
+COBJS-$(CONFIG_P1022) += p1022_serdes.o
COBJS-$(CONFIG_PCI)+= pci.o
COBJS-$(CONFIG_QE) += qe_io.o
COBJS-$(CONFIG_CPM2) += serial_scc.o
diff --git a/arch/powerpc/cpu/mpc85xx/p1022_serdes.c
b/arch/powerpc/cpu/mpc85xx/p1022_serdes.c
new file mode 100644
index 000..52e109b
--- /dev/null
+++ b/arch/powerpc/cpu/mpc85xx/p1022_serdes.c
@@ -0,0 +1,166 @@
+/*
+ * Copyright 2010 Freescale Semiconductor, Inc.
+ * Author: Timur Tabi ti...@freescale.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.
+ */
+
+#include config.h
+#include common.h
+#include asm/io.h
+#include asm/immap_85xx.h
+#include asm/fsl_serdes.h
+
+#define SRDS1_MAX_LANES4
+#define SRDS2_MAX_LANES2
+
+static const u8 serdes1_cfg_tbl[][SRDS1_MAX_LANES] = {
+ [0x00] = {NONE, NONE, NONE, NONE},
+ [0x01] = {NONE, NONE, NONE, NONE},
+ [0x02] = {NONE, NONE, NONE, NONE},
+ [0x03] = {NONE, NONE, NONE, NONE},
+ [0x04] = {NONE, NONE, NONE, NONE},
+ [0x06] = {PCIE1, PCIE3, SGMII_TSEC1, PCIE2},
+ [0x07] = {PCIE1, PCIE3, SGMII_TSEC1, PCIE2},
+ [0x09] = {PCIE1, NONE, NONE, NONE},
+ [0x0a] = {PCIE1, PCIE3, SGMII_TSEC1, SGMII_TSEC2},
+ [0x0b] = {PCIE1, PCIE3, SGMII_TSEC1, SGMII_TSEC2},
+ [0x0d] = {PCIE1, PCIE1, SGMII_TSEC1, SGMII_TSEC2},
+ [0x0e] = {PCIE1, PCIE1, SGMII_TSEC1, SGMII_TSEC2},
+ [0x0f] = {PCIE1, PCIE1, SGMII_TSEC1, SGMII_TSEC2},
+ [0x15] = {PCIE1, PCIE3, PCIE2, PCIE2},
+ [0x16] = {PCIE1, PCIE3, PCIE2, PCIE2},
+ [0x17] = {PCIE1, PCIE3, PCIE2, PCIE2},
+ [0x18] = {PCIE1, PCIE1, PCIE2, PCIE2},
+ [0x19] = {PCIE1, PCIE1, PCIE2, PCIE2},
+ [0x1a] = {PCIE1, PCIE1, PCIE2, PCIE2},
+ [0x1b] = {PCIE1, PCIE1, PCIE2, PCIE2},
+ [0x1c] = {PCIE1, PCIE1, PCIE1, PCIE1},
+ [0x1d] = {PCIE1, PCIE1, PCIE2, PCIE2},
+ [0x1e] = {PCIE1, PCIE1, PCIE2, PCIE2},
+ [0x1f] = {PCIE1, PCIE1, PCIE2, PCIE2},
+};
+
+static const u8
Re: [U-Boot] [PATCH] display the entry point when compiling a stand-alone program
Detlev Zundel wrote: We should concentrate on creating a correct linker script so that the entry point ends up where we want it to be, namely at STANDALONE_LOAD_ADDR. Can you have a look at this and maybe solve the problem for good then? I have no idea how to do that. I don't know diddly about linker scripts. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] display the entry point when compiling a stand-alone program
Contrary to popular belief, the entry point for a stand-alone program is not consistent. The only way to know for sure is to use the nm program and search for the entry point function. So we update the Makefile build rule to display this entry point after the ELF image is created. Signed-off-by: Timur Tabi ti...@freescale.com --- examples/standalone/Makefile |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/examples/standalone/Makefile b/examples/standalone/Makefile index 6ea3b93..d6a01ea 100644 --- a/examples/standalone/Makefile +++ b/examples/standalone/Makefile @@ -83,6 +83,7 @@ $(obj)%: $(obj)%.o $(LIB) $(LD) -g -Ttext $(STANDALONE_LOAD_ADDR) \ -o $@ -e $(SYM_PREFIX)$(notdir $(:.o=)) $ $(LIB) \ -L$(gcclibdir) -lgcc + $(NM) $@ | grep $@ $(SREC): $(obj)%.srec: $(obj)% -- 1.7.0.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
