July 2008 - U-Boot

[U-Boot-Users] (no subject)
by David Saada 07 Jul '08

07 Jul '08

Kumar Gala-3 wrote: > > This is a series of patches that are a work-in-progress towards a new > DDR initialization for the Freescale 8{3,5,6}xxx devices that have a > common DDR controller. > Kumar, Does this RFC also include support for identifying and initializing more than one DDR module? David.

2 1

[U-Boot-Users] [PATCH] Feed the watchdog in u-boot for 8610 board.
by Jason Jin 07 Jul '08

07 Jul '08

The watchdog on 8610 board is enabled by setting sw[6] to on. Once enabled, the watchdog can not be disabled by software. So feed the dog in u-boot is necessary for normal operation. Signed-off-by: Jason Jin <Jason.jin(a)freescale.com> --- cpu/mpc86xx/cpu.c | 14 ++++++++++++++ cpu/mpc86xx/interrupts.c | 1 + include/asm-ppc/immap_86xx.h | 14 +++++++++++++- include/configs/MPC8610HPCD.h | 3 ++- 4 files changed, 30 insertions(+), 2 deletions(-) diff --git a/cpu/mpc86xx/cpu.c b/cpu/mpc86xx/cpu.c index bf4e651..6dd0655 100644 --- a/cpu/mpc86xx/cpu.c +++ b/cpu/mpc86xx/cpu.c @@ -213,6 +213,20 @@ get_tbclk(void) void watchdog_reset(void) { + +#if defined(CONFIG_MPC8610) +/*This actually feed the hard enabled watchdog*/ + volatile immap_t *immap = (immap_t *)CFG_IMMR; + volatile ccsr_wdt_t *wdt = &immap->im_wdt; + volatile ccsr_gur_t *gur = &immap->im_gur; + u32 tmp = gur->pordevsr; + + if(tmp & 0x4000) { + wdt->swsrr = 0x556c; + wdt->swsrr = 0xaa39; + } +#endif + } #endif /* CONFIG_WATCHDOG */ diff --git a/cpu/mpc86xx/interrupts.c b/cpu/mpc86xx/interrupts.c index d9f634f..f16744b 100644 --- a/cpu/mpc86xx/interrupts.c +++ b/cpu/mpc86xx/interrupts.c @@ -36,6 +36,7 @@ #include <command.h> #include <asm/processor.h> #include <ppc_asm.tmpl> +#include <watchdog.h> unsigned long decrementer_count; /* count value for 1e6/HZ microseconds */ unsigned long timestamp; diff --git a/include/asm-ppc/immap_86xx.h b/include/asm-ppc/immap_86xx.h index 7526061..93a4eb7 100644 --- a/include/asm-ppc/immap_86xx.h +++ b/include/asm-ppc/immap_86xx.h @@ -1304,9 +1304,19 @@ typedef struct ccsr_gur { uint lynxdcr1; /* 0xe0f08 - Lynx debug control register 1*/ int res14[6]; uint ddrioovcr; /* 0xe0f24 - DDR IO Overdrive Control register */ - char res15[61656]; + char res15[216]; } ccsr_gur_t; +/*Watchdog register block(0xe_4000-0xe_4fff)*/ +typedef struct ccsr_wdt { + uint res0; + uint swcrr; /* System watchdog control register */ + uint swcnr; /* System watchdog count register */ + char res1[2]; + ushort swsrr; /* System watchdog service register */ + char res2[4080]; +}ccsr_wdt_t; + typedef struct immap { ccsr_local_mcm_t im_local_mcm; ccsr_ddr_t im_ddr1; @@ -1330,6 +1340,8 @@ typedef struct immap { char res5[389120]; ccsr_rio_t im_rio; ccsr_gur_t im_gur; + char res6[12288]; + ccsr_wdt_t im_wdt; } immap_t; extern immap_t *immr; diff --git a/include/configs/MPC8610HPCD.h b/include/configs/MPC8610HPCD.h index 53d6955..4d61a61 100644 --- a/include/configs/MPC8610HPCD.h +++ b/include/configs/MPC8610HPCD.h @@ -486,7 +486,8 @@ #endif -#undef CONFIG_WATCHDOG /* watchdog disabled */ +#define CONFIG_WATCHDOG /* watchdog enabled */ +#define CFG_WATCHDOG_FREQ 5000 /*Feed interval, 5s*/ /*DIU Configuration*/ #define DIU_CONNECT_TO_DVI /* DIU controller connects to DVI encoder*/ -- 1.5.2

2 1

[U-Boot-Users] Christopher Nolan's Knight vision
by humston 07 Jul '08

07 Jul '08

Rating of stolen car for 2007 http://www.banyandecor.com/r.html

1 0

[U-Boot-Users] [RFC][FSL DDR 0/8] Freescale DDR rewrite
by Kumar Gala 07 Jul '08

07 Jul '08

This is a series of patches that are a work-in-progress towards a new DDR initialization for the Freescale 8{3,5,6}xxx devices that have a common DDR controller. These patches are also available at: git://git.kernel.org/pub/scm/boot/u-boot/galak/u-boot.git fsl_ddr and patch 0002 since its large is at: http://gate.crashing.org/~galak/fsl_ddr.20080609/0002-Rewrite-the-FSL-mpc8x… - k

4 13

[U-Boot-Users] variable type issues in LMB code
by Wolfgang Denk 07 Jul '08

07 Jul '08

Hello Andy & Becky & Kumar, there is a general problem of variable types with the LMB code; at the moment, it uses some "u64" (and in lib_ppc/bootm.c actually a mix of "u64" and "uint64_t") declarations where I think we should use phys_addr_t resp. phys_size_t types instead. At the moment, this results in lots of compiler messages: warning: cast from pointer to integer of different size Could you please have a look and try and clean up? Thanks in advance. 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: wd(a)denx.de "There are three principal ways to lose money: wine, women, and engi- neers. While the first two are more pleasant, the third is by far the more certain." - Baron Rothschild, ca. 1800

3 3

[U-Boot-Users] [PATCH] Remove duplicate code introduced by commit 597f6c26a18b389903a64692bacbf9a1ca69355b
by Hugo Villeneuve 07 Jul '08

07 Jul '08

Remove duplicate code introduced by commit 597f6c26a18b389903a64692bacbf9a1ca69355b Signed-off-by: Hugo Villeneuve <hugo.villeneuve(a)lyrtech.com> --- common/main.c | 6 ------ 1 files changed, 0 insertions(+), 6 deletions(-) diff --git a/common/main.c b/common/main.c index a17b60b..046da6f 100644 --- a/common/main.c +++ b/common/main.c @@ -940,12 +940,6 @@ int readline_into_buffer (const char *const prompt, char * buffer) int rc; static int initted = 0; - if (!initted) { - hist_init(); - initted = 1; - } - - /* * History uses a global array which is not * writable until after relocation to RAM.

3 2

[U-Boot-Users] [PATCH] Squash warnings from pointer aliasing in dlmalloc
by Kumar Gala 07 Jul '08

07 Jul '08

When we building with gcc-4.3.x on a ppc host we get the following warnings: dlmalloc.c: In function 'malloc_extend_top': dlmalloc.c:1971: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:1999: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2029: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2031: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2042: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c: In function 'malloc': dlmalloc.c:2245: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2245: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2253: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2258: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2263: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2318: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2327: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2329: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2344: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2356: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2360: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2362: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2363: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c: In function 'free': dlmalloc.c:2431: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2444: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2483: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2483: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c: In function 'realloc': dlmalloc.c:2594: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2599: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2604: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2605: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2637: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2646: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2647: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c: In function 'calloc': dlmalloc.c:2896: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2897: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c: In function 'malloc_trim': dlmalloc.c:2987: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:2997: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:3008: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:3012: warning: dereferencing type-punned pointer will break strict-aliasing rules dlmalloc.c:3021: warning: dereferencing type-punned pointer will break strict-aliasing rules This is due to pointer aliasing that the dlmalloc code does and depends on. Instead of trying trying to work around the warnings, we use the per file CFLAGs to disable the warnings via -fno-strict-aliasing. Signed-off-by: Kumar Gala <galak(a)kernel.crashing.org> --- common/Makefile | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/common/Makefile b/common/Makefile index b425795..5f4959a 100644 --- a/common/Makefile +++ b/common/Makefile @@ -104,6 +104,7 @@ COBJS-y += console.o COBJS-y += cyclon2.o COBJS-y += stratixII.o COBJS-y += devices.o +CFLAGS_dlmalloc.o += -fno-strict-aliasing COBJS-y += dlmalloc.o COBJS-y += docecc.o COBJS-y += environment.o -- 1.5.5.1

2 2

[U-Boot-Users] [PATCH 1/2] fsl_elbc_nand: workaround for hangs during nand write
by Scott Wood 07 Jul '08

07 Jul '08

From: Anton Vorontsov <avorontsov(a)ru.mvista.com> Using current driver elbc sometimes hangs during nand write. Reading back last byte helps though (thanks to Scott Wood for the idea). Signed-off-by: Anton Vorontsov <avorontsov(a)ru.mvista.com> Signed-off-by: Scott Wood <scottwood(a)freescale.com> --- drivers/mtd/nand/fsl_elbc_nand.c | 11 ++++++++++- 1 files changed, 10 insertions(+), 1 deletions(-) diff --git a/drivers/mtd/nand/fsl_elbc_nand.c b/drivers/mtd/nand/fsl_elbc_nand.c index c1644c0..ab3e0fd 100644 --- a/drivers/mtd/nand/fsl_elbc_nand.c +++ b/drivers/mtd/nand/fsl_elbc_nand.c @@ -489,7 +489,7 @@ static void fsl_elbc_write_buf(struct mtd_info *mtd, const u8 *buf, int len) struct fsl_elbc_ctrl *ctrl = priv->ctrl; unsigned int bufsize = mtd->writesize + mtd->oobsize; - if (len < 0) { + if (len <= 0) { printf("write_buf of %d bytes", len); ctrl->status = 0; return; @@ -503,6 +503,15 @@ static void fsl_elbc_write_buf(struct mtd_info *mtd, const u8 *buf, int len) } memcpy_toio(&ctrl->addr[ctrl->index], buf, len); + /* + * This is workaround for the weird elbc hangs during nand write, + * Scott Wood says: "...perhaps difference in how long it takes a + * write to make it through the localbus compared to a write to IMMR + * is causing problems, and sync isn't helping for some reason." + * Reading back the last byte helps though. + */ + in_8(&ctrl->addr[ctrl->index] + len - 1); + ctrl->index += len; } -- 1.5.3

2 2

[U-Boot-Users] [PATCH] mips: Bring over optimized memset() routine from Linux.
by Jason McMullan 07 Jul '08

07 Jul '08

This commit pulls over the memset() MIPS routine from Linux 2.6.26, which provides a 10x to 20x speedup over the generic byte-at-a-time routine. This is especially useful on platforms with manual ECC scrubbing, that require all of memory to be written at least once after a power cycle. --- include/asm-mips/string.h | 2 +- lib_mips/Makefile | 2 +- lib_mips/memset.S | 174 +++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 176 insertions(+), 2 deletions(-) create mode 100644 lib_mips/memset.S diff --git a/include/asm-mips/string.h b/include/asm-mips/string.h index 579a591..0df1463 100644 --- a/include/asm-mips/string.h +++ b/include/asm-mips/string.h @@ -27,7 +27,7 @@ extern int strcmp(__const__ char *__cs, __const__ char *__ct); #undef __HAVE_ARCH_STRNCMP extern int strncmp(__const__ char *__cs, __const__ char *__ct, __kernel_size_t __count); -#undef __HAVE_ARCH_MEMSET +#define __HAVE_ARCH_MEMSET extern void *memset(void *__s, int __c, __kernel_size_t __count); #undef __HAVE_ARCH_MEMCPY diff --git a/lib_mips/Makefile b/lib_mips/Makefile index 8176437..9149039 100644 --- a/lib_mips/Makefile +++ b/lib_mips/Makefile @@ -25,7 +25,7 @@ include $(TOPDIR)/config.mk LIB = $(obj)lib$(ARCH).a -SOBJS-y += +SOBJS-y += memset.o COBJS-y += board.o COBJS-y += bootm.o diff --git a/lib_mips/memset.S b/lib_mips/memset.S new file mode 100644 index 0000000..f1c07d7 --- /dev/null +++ b/lib_mips/memset.S @@ -0,0 +1,174 @@ +/* + * This file is subject to the terms and conditions of the GNU General Public + * License. See the file "COPYING" in the main directory of this archive + * for more details. + * + * Copyright (C) 1998, 1999, 2000 by Ralf Baechle + * Copyright (C) 1999, 2000 Silicon Graphics, Inc. + * Copyright (C) 2007 Maciej W. Rozycki + */ +#include <asm/asm.h> +//#include <asm/asm-offsets.h> +#include <asm/regdef.h> + +#if LONGSIZE == 4 +#define LONG_S_L swl +#define LONG_S_R swr +#else +#define LONG_S_L sdl +#define LONG_S_R sdr +#endif + +#define EX(insn,reg,addr,handler) \ +9: insn reg, addr; \ + .section __ex_table,"a"; \ + PTR 9b, handler; \ + .previous + + .macro f_fill64 dst, offset, val, fixup + EX(LONG_S, \val, (\offset + 0 * LONGSIZE)(\dst), \fixup) + EX(LONG_S, \val, (\offset + 1 * LONGSIZE)(\dst), \fixup) + EX(LONG_S, \val, (\offset + 2 * LONGSIZE)(\dst), \fixup) + EX(LONG_S, \val, (\offset + 3 * LONGSIZE)(\dst), \fixup) + EX(LONG_S, \val, (\offset + 4 * LONGSIZE)(\dst), \fixup) + EX(LONG_S, \val, (\offset + 5 * LONGSIZE)(\dst), \fixup) + EX(LONG_S, \val, (\offset + 6 * LONGSIZE)(\dst), \fixup) + EX(LONG_S, \val, (\offset + 7 * LONGSIZE)(\dst), \fixup) +#if LONGSIZE == 4 + EX(LONG_S, \val, (\offset + 8 * LONGSIZE)(\dst), \fixup) + EX(LONG_S, \val, (\offset + 9 * LONGSIZE)(\dst), \fixup) + EX(LONG_S, \val, (\offset + 10 * LONGSIZE)(\dst), \fixup) + EX(LONG_S, \val, (\offset + 11 * LONGSIZE)(\dst), \fixup) + EX(LONG_S, \val, (\offset + 12 * LONGSIZE)(\dst), \fixup) + EX(LONG_S, \val, (\offset + 13 * LONGSIZE)(\dst), \fixup) + EX(LONG_S, \val, (\offset + 14 * LONGSIZE)(\dst), \fixup) + EX(LONG_S, \val, (\offset + 15 * LONGSIZE)(\dst), \fixup) +#endif + .endm + +/* + * memset(void *s, int c, size_t n) + * + * a0: start of area to clear + * a1: char to fill with + * a2: size of area to clear + */ + .set noreorder + .align 5 +LEAF(memset) + beqz a1, 1f + move v0, a0 /* result */ + + andi a1, 0xff /* spread fillword */ + LONG_SLL t1, a1, 8 + or a1, t1 + LONG_SLL t1, a1, 16 +#if LONGSIZE == 8 + or a1, t1 + LONG_SLL t1, a1, 32 +#endif + or a1, t1 +1: + +FEXPORT(__bzero) + sltiu t0, a2, LONGSIZE /* very small region? */ + bnez t0, .Lsmall_memset + andi t0, a0, LONGMASK /* aligned? */ + +#ifndef CONFIG_CPU_DADDI_WORKAROUNDS + beqz t0, 1f + PTR_SUBU t0, LONGSIZE /* alignment in bytes */ +#else + .set noat + li AT, LONGSIZE + beqz t0, 1f + PTR_SUBU t0, AT /* alignment in bytes */ + .set at +#endif + + R10KCBARRIER(0(ra)) +#ifdef __MIPSEB__ + EX(LONG_S_L, a1, (a0), .Lfirst_fixup) /* make word/dword aligned */ +#endif +#ifdef __MIPSEL__ + EX(LONG_S_R, a1, (a0), .Lfirst_fixup) /* make word/dword aligned */ +#endif + PTR_SUBU a0, t0 /* long align ptr */ + PTR_ADDU a2, t0 /* correct size */ + +1: ori t1, a2, 0x3f /* # of full blocks */ + xori t1, 0x3f + beqz t1, .Lmemset_partial /* no block to fill */ + andi t0, a2, 0x40-LONGSIZE + + PTR_ADDU t1, a0 /* end address */ + .set reorder +1: PTR_ADDIU a0, 64 + R10KCBARRIER(0(ra)) + f_fill64 a0, -64, a1, .Lfwd_fixup + bne t1, a0, 1b + .set noreorder + +.Lmemset_partial: + R10KCBARRIER(0(ra)) + PTR_LA t1, 2f /* where to start */ +#if LONGSIZE == 4 + PTR_SUBU t1, t0 +#else + .set noat + LONG_SRL AT, t0, 1 + PTR_SUBU t1, AT + .set at +#endif + jr t1 + PTR_ADDU a0, t0 /* dest ptr */ + + .set push + .set noreorder + .set nomacro + f_fill64 a0, -64, a1, .Lpartial_fixup /* ... but first do longs ... */ +2: .set pop + andi a2, LONGMASK /* At most one long to go */ + + beqz a2, 1f + PTR_ADDU a0, a2 /* What's left */ + R10KCBARRIER(0(ra)) +#ifdef __MIPSEB__ + EX(LONG_S_R, a1, -1(a0), .Llast_fixup) +#endif +#ifdef __MIPSEL__ + EX(LONG_S_L, a1, -1(a0), .Llast_fixup) +#endif +1: jr ra + move a2, zero + +.Lsmall_memset: + beqz a2, 2f + PTR_ADDU t1, a0, a2 + +1: PTR_ADDIU a0, 1 /* fill bytewise */ + R10KCBARRIER(0(ra)) + bne t1, a0, 1b + sb a1, -1(a0) + +2: jr ra /* done */ + move a2, zero + END(memset) + +.Lfirst_fixup: + jr ra + nop + +.Lfwd_fixup: + andi a2, 0x3f + jr ra + LONG_ADDU a2, t1 + +.Lpartial_fixup: + andi a2, LONGMASK + jr ra + LONG_ADDU a2, t1 + +.Llast_fixup: + jr ra + andi v1, a2, LONGMASK -- 1.5.4.3

4 5

[U-Boot-Users] framebuffer drivers without modesetting support?
by Harald Welte 07 Jul '08

07 Jul '08

Hi! I was wondering if u-boot would also accept the merge of a framebuffer driver that doesn't allow runtime mode-setting. The reason is not that I'm generally too lazy - but much more the fact that most embedded devices with LCM + LCM controller only support one, maybe a really small number of fixed resolutions. Wouldn't it be sufficient for the board-level config to specify e.g. a callback function to do the low-level timing configuration of the video controller? This way there could still be a shared framebuffer driver, and any board+fb_driver combination would work. Only the theoretical case of connecting a different display would not be supported... but that doesn't really happen in the handheld embedded device world (think of smartphones, portable media players, navigation devices, ...) Even inside the Linux kernel e.g. the s3c2410 framebuffer is configured by board-specific platform data. Also, there are many LCM controller parameters that don't fit into the classical modeline from the CRT world. I'm having a hard time imagining how those parameters should be passed around... What do you think? Cheers, -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

2 3