[U-Boot] [PATCH v2] ppc: cleanup compilererrors/warnings
actual u-boot top of tree builds with warnings/errors for
the following boards:
ads5121 cpci5200 mecp5200 v38b IAD210 MBX MBX860T NX823
RPXClassic debris PN62
following patch solves this.
Signed-off-by: Heiko Schocher h...@denx.de
---
changes since v1:
- eth_putenv_enetaddr() substituted by eth_setenv_enetaddr()
board/RPXClassic/RPXClassic.c |3 ++-
board/etin/debris/debris.c|1 +
board/mbx8xx/mbx8xx.c |3 ++-
board/nx823/nx823.c |5 +++--
board/pn62/pn62.c |1 +
board/siemens/IAD210/IAD210.c |3 ++-
board/sixnet/sixnet.c |3 ---
board/v38b/v38b.c |3 ++-
common/cmd_elf.c |4 ++--
cpu/mpc512x/cpu.c |1 +
include/configs/MBX860T.h |1 +
11 files changed, 17 insertions(+), 11 deletions(-)
diff --git a/board/RPXClassic/RPXClassic.c b/board/RPXClassic/RPXClassic.c
index 5aa713f..c3d5385 100644
--- a/board/RPXClassic/RPXClassic.c
+++ b/board/RPXClassic/RPXClassic.c
@@ -30,6 +30,7 @@
#include i2c.h
#include config.h
#include mpc8xx.h
+#include net.h
/* - */
@@ -151,7 +152,7 @@ int misc_init_r(void)
if (!eth_getenv_enetaddr(ethaddr, enetaddr)) {
board_get_enetaddr(enetaddr);
- eth_putenv_enetaddr(ethaddr, enetaddr);
+ eth_setenv_enetaddr(ethaddr, enetaddr);
}
return 0;
diff --git a/board/etin/debris/debris.c b/board/etin/debris/debris.c
index a971af3..33efe16 100644
--- a/board/etin/debris/debris.c
+++ b/board/etin/debris/debris.c
@@ -23,6 +23,7 @@
#include common.h
#include mpc824x.h
+#include net.h
#include pci.h
#include i2c.h
#include netdev.h
diff --git a/board/mbx8xx/mbx8xx.c b/board/mbx8xx/mbx8xx.c
index a3bf1f7..255796b 100644
--- a/board/mbx8xx/mbx8xx.c
+++ b/board/mbx8xx/mbx8xx.c
@@ -34,6 +34,7 @@
#include common.h
#include commproc.h
#include mpc8xx.h
+#include net.h
#include dimm.h
#include vpd.h
#include csr.h
@@ -257,7 +258,7 @@ int misc_init_r(void)
if (!eth_getenv_enetaddr(ethaddr, enetaddr)) {
board_get_enetaddr(enetaddr);
- eth_putenv_enetaddr(ethaddr, enetaddr);
+ eth_setenv_enetaddr(ethaddr, enetaddr);
}
return 0;
diff --git a/board/nx823/nx823.c b/board/nx823/nx823.c
index 6ec29dc..15bb2d8 100644
--- a/board/nx823/nx823.c
+++ b/board/nx823/nx823.c
@@ -27,6 +27,7 @@
#include common.h
#include malloc.h
#include mpc8xx.h
+#include net.h
DECLARE_GLOBAL_DATA_PTR;
@@ -366,7 +367,7 @@ int misc_init_r (void)
char tmp[50];
uchar ethaddr[6];
bd_t *bd = gd-bd;
- ulong my_sernum = bd-bi_sernum;
+ ulong *my_sernum = (unsigned long *)bd-bi_sernum;
/* load unique serial number */
for (i = 0; i 8; ++i)
diff --git a/board/pn62/pn62.c b/board/pn62/pn62.c
index 53d7e57..676f8d3 100644
--- a/board/pn62/pn62.c
+++ b/board/pn62/pn62.c
@@ -22,6 +22,7 @@
#include common.h
#include mpc824x.h
+#include net.h
#include pci.h
#include netdev.h
diff --git a/board/siemens/IAD210/IAD210.c b/board/siemens/IAD210/IAD210.c
index 67e5c8f..7325a93 100644
--- a/board/siemens/IAD210/IAD210.c
+++ b/board/siemens/IAD210/IAD210.c
@@ -23,6 +23,7 @@
#include common.h
#include mpc8xx.h
+#include net.h
#include atm.h
#include i2c.h
@@ -291,7 +292,7 @@ int misc_init_r(void)
if (!eth_getenv_enetaddr(ethaddr, enetaddr)) {
board_get_enetaddr(enetaddr);
- eth_putenv_enetaddr(ethaddr, enetaddr);
+ eth_setenv_enetaddr(ethaddr, enetaddr);
}
return 0;
diff --git a/board/sixnet/sixnet.c b/board/sixnet/sixnet.c
index 4fcd84b..6e39b01 100644
--- a/board/sixnet/sixnet.c
+++ b/board/sixnet/sixnet.c
@@ -260,9 +260,6 @@ int misc_init_r (void)
{
volatile immap_t *immap = (immap_t *)CONFIG_SYS_IMMR;
volatile memctl8xx_t *memctl = immap-im_memctl;
- char* s;
- char* e;
- int reg;
bd_t *bd = gd-bd;
uchar enetaddr[6];
diff --git a/board/v38b/v38b.c b/board/v38b/v38b.c
index 9e7c1d7..978ff8d 100644
--- a/board/v38b/v38b.c
+++ b/board/v38b/v38b.c
@@ -26,6 +26,7 @@
#include common.h
#include mpc5xxx.h
+#include net.h
#include asm/processor.h
@@ -230,7 +231,7 @@ int misc_init_r(void)
if (!eth_getenv_enetaddr(ethaddr, enetaddr)) {
board_get_enetaddr(enetaddr);
- eth_putenv_enetaddr(ethaddr, enetaddr);
+ eth_setenv_enetaddr(ethaddr, enetaddr);
}
return 0;
diff --git a/common/cmd_elf.c b/common/cmd_elf.c
index 4a3fff1..83e7589 100644
--- a/common/cmd_elf.c
+++ b/common/cmd_elf.c
@@ -131,11 +131,11 @@ int do_bootvx (cmd_tbl_t *cmdtp, int flag, int argc, char
*argv[])
#if defined(CONFIG_WALNUT)
tmp = (char *) CONFIG_SYS_NVRAM_BASE_ADDR + 0x500;
- eth_getenv_enetaddr(ethaddr, build_buf);
+ eth_getenv_enetaddr(ethaddr,
Re: [U-Boot] [PATCH-ARM] S3C2440: Add support for Embest SBC2440-II Board
On 00:14 Thu 26 Mar , kevin.morf...@fearnside-systems.co.uk wrote: Adds support for the Embest SBC2440-II Board (see http://www.embedinfo.com/english/product/sbc2440-II.asp) with u-boot programmed in NOR flash. Implementation is based on the existing u-boot support for s3C2410-based boards. Where I've copied and modified existing files I've left the style of the original code as it was, including any non-conformance with the u-boot coding style. Where I've added new code I've aimed to use the u-boot coding style. I've run MAKEALL with the LIST_ARM9 targets only as the changes don't affect any other architectures. Signed-off-by: Kevin Morfitt kevin.morf...@fearnside-systems.co.uk diff -uprN u-boot-2009.03/MAKEALL u-boot-2009.03-PATCHED/MAKEALL --- u-boot-2009.03/MAKEALL2009-03-21 21:04:41.0 + +++ u-boot-2009.03-PATCHED/MAKEALL2009-03-25 21:48:14.171875000 + @@ -512,6 +512,7 @@ LIST_ARM9=\ omap5912osk\ omap730p2\ sbc2410x\ +sbc2440ii\ scb9328\ smdk2400\ smdk2410\ diff -uprN u-boot-2009.03/Makefile u-boot-2009.03-PATCHED/Makefile --- u-boot-2009.03/Makefile2009-03-21 21:04:41.0 + +++ u-boot-2009.03-PATCHED/Makefile2009-03-22 09:42:11.078125000 + @@ -2821,6 +2821,9 @@ omap730p2_cs3boot_config :unconfig sbc2410x_config: unconfig @$(MKCONFIG) $(@:_config=) arm arm920t sbc2410x NULL s3c24x0 +sbc2440ii_config: unconfig +@$(MKCONFIG) $(@:_config=) arm arm920t sbc2440ii embest s3c24x0 + scb9328_config:unconfig @$(MKCONFIG) $(@:_config=) arm arm920t scb9328 NULL imx diff -uprN u-boot-2009.03/board/embest/sbc2440ii/Makefile u-boot-2009.03-PATCHED/board/embest/sbc2440ii/Makefile --- u-boot-2009.03/board/embest/sbc2440ii/Makefile1970-01-01 00:00:00.0 + +++ u-boot-2009.03-PATCHED/board/embest/sbc2440ii/Makefile2009-03-22 09:44:24.640625000 + @@ -0,0 +1,51 @@ +# +# (C) Copyright 2000-2006 +# Wolfgang Denk, DENX Software Engineering, w...@denx.de. +# +# See file CREDITS for list of people who contributed to this +# project. +# +# This program is free software; you can redistribute it and/or +# modify it under the terms of the GNU General Public License as +# published by the Free Software Foundation; either version 2 of +# the License, or (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 59 Temple Place, Suite 330, Boston, +# MA 02111-1307 USA +# + +include $(TOPDIR)/config.mk + +LIB= $(obj)lib$(BOARD).a + +COBJS:= sbc2440ii.o flash.o sbc2440ii_cmd.o +SOBJS:= lowlevel_init.o + +SRCS:= $(SOBJS:.o=.S) $(COBJS:.o=.c) +OBJS:= $(addprefix $(obj),$(COBJS)) +SOBJS:= $(addprefix $(obj),$(SOBJS)) + +$(LIB):$(obj).depend $(OBJS) $(SOBJS) +$(AR) $(ARFLAGS) $@ $(OBJS) $(SOBJS) + +clean: +rm -f $(SOBJS) $(OBJS) + +distclean:clean +rm -f $(LIB) core *.bak $(obj).depend + +# + +# defines $(obj).depend target +include $(SRCTREE)/rules.mk + +sinclude $(obj).depend + +# diff -uprN u-boot-2009.03/board/embest/sbc2440ii/config.mk u-boot-2009.03-PATCHED/board/embest/sbc2440ii/config.mk --- u-boot-2009.03/board/embest/sbc2440ii/config.mk1970-01-01 00:00:00.0 + +++ u-boot-2009.03-PATCHED/board/embest/sbc2440ii/config.mk 2009-03-25 21:05:21.28125 + @@ -0,0 +1,25 @@ +# +# (C) Copyright 2002 +# Gary Jennejohn, DENX Software Engineering, g...@denx.de +# David Mueller, ELSOFT AG, d.muel...@elsoft.ch +# +# SAMSUNG SMDK2410 board with S3C2410X (ARM920T) cpu +# +# see http://www.samsung.com/ for more information on SAMSUNG +# +# Modified for EMBEST SBC2440-II board with S3C2440 (ARM920T) cpu by: +# (C) Copyright 2009 +# Kevin Morfitt, Fearnside Systems Ltd, kevin.morf...@fearnside-systems.co.uk please fix + +# +# SBC2440-II has 1 bank of 64 MB DRAM +# +# 3000' to 3800' +# +# Linux-Kernel is expected to be at 3000'8000, entry 3000'8000 +# +# we load ourself to 33F8' +# +# download area is 3000' + +TEXT_BASE = 0x33F8 diff -uprN u-boot-2009.03/board/embest/sbc2440ii/flash.c u-boot-2009.03-PATCHED/board/embest/sbc2440ii/flash.c please use cfi driver --- u-boot-2009.03/board/embest/sbc2440ii/flash.c1970-01-01 00:00:00.0 + +++
[U-Boot] [PATCH 1/3] Add LSDMR (SDRAM Mode Register) definition on localbus
The masks for various bit defines of LSDMR are common and thus we can define them in one place rather than replicating them in each config.h Signed-off-by: Kumar Gala ga...@kernel.crashing.org --- include/asm-ppc/fsl_lbc.h | 27 +++ 1 files changed, 27 insertions(+), 0 deletions(-) diff --git a/include/asm-ppc/fsl_lbc.h b/include/asm-ppc/fsl_lbc.h index 9fa0b65..bc1ebe6 100644 --- a/include/asm-ppc/fsl_lbc.h +++ b/include/asm-ppc/fsl_lbc.h @@ -397,6 +397,33 @@ #define FPAR_LP_CI 0x07FF #define FPAR_LP_CI_SHIFT 0 +/* LSDMR - SDRAM Machine Mode Register + */ +#define LSDMR_RFEN (1 (31 - 1)) +#define LSDMR_BSMA1516 (3 (31 - 10)) +#define LSDMR_BSMA1617 (4 (31 - 10)) +#define LSDMR_RFCR5(3 (31 - 16)) +#define LSDMR_RFCR16 (7 (31 - 16)) +#define LSDMR_PRETOACT3 (3 (31 - 19)) +#define LSDMR_PRETOACT7(7 (31 - 19)) +#define LSDMR_ACTTORW3 (3 (31 - 22)) +#define LSDMR_ACTTORW7 (7 (31 - 22)) +#define LSDMR_ACTTORW6 (6 (31 - 22)) +#define LSDMR_BL8 (1 (31 - 23)) +#define LSDMR_WRC2 (2 (31 - 27)) +#define LSDMR_WRC4 (0 (31 - 27)) +#define LSDMR_BUFCMD (1 (31 - 29)) +#define LSDMR_CL3 (3 (31 - 31)) + +#define LSDMR_OP_NORMAL(0 (31 - 4)) +#define LSDMR_OP_ARFRSH(1 (31 - 4)) +#define LSDMR_OP_SRFRSH(2 (31 - 4)) +#define LSDMR_OP_MRW (3 (31 - 4)) +#define LSDMR_OP_PRECH (4 (31 - 4)) +#define LSDMR_OP_PCHALL(5 (31 - 4)) +#define LSDMR_OP_ACTBNK(6 (31 - 4)) +#define LSDMR_OP_RWINV (7 (31 - 4)) + /* LTESR - Transfer Error Status Register */ #define LTESR_BM 0x8000 -- 1.5.6.6 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/3] 85xx: Use common LSDMR defines from asm/fsl_lbc.h
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
board/freescale/mpc8541cds/mpc8541cds.c | 14
board/freescale/mpc8548cds/mpc8548cds.c | 10 +++---
board/freescale/mpc8555cds/mpc8555cds.c | 14
board/freescale/mpc8560ads/mpc8560ads.c |1 +
board/freescale/mpc8568mds/mpc8568mds.c | 10 +++---
board/sbc8548/sbc8548.c | 10 +++---
include/configs/MPC8540ADS.h| 59 +++
include/configs/MPC8541CDS.h| 37
include/configs/MPC8548CDS.h| 37
include/configs/MPC8555CDS.h| 37
include/configs/MPC8560ADS.h| 59 +++
include/configs/MPC8568MDS.h| 37
include/configs/sbc8548.h | 37
13 files changed, 91 insertions(+), 271 deletions(-)
diff --git a/board/freescale/mpc8541cds/mpc8541cds.c
b/board/freescale/mpc8541cds/mpc8541cds.c
index e6025c8..c30d966 100644
--- a/board/freescale/mpc8541cds/mpc8541cds.c
+++ b/board/freescale/mpc8541cds/mpc8541cds.c
@@ -372,21 +372,21 @@ sdram_init(void)
cpu_board_rev = get_cpu_board_revision();
lsdmr_common = CONFIG_SYS_LBC_LSDMR_COMMON;
if (cpu_board_rev == MPC85XX_CPU_BOARD_REV_1_0) {
- lsdmr_common |= CONFIG_SYS_LBC_LSDMR_BSMA1617;
+ lsdmr_common |= LSDMR_BSMA1617;
} else if (cpu_board_rev == MPC85XX_CPU_BOARD_REV_1_1) {
- lsdmr_common |= CONFIG_SYS_LBC_LSDMR_BSMA1516;
+ lsdmr_common |= LSDMR_BSMA1516;
} else {
/*
* Assume something unable to identify itself is
* really old, and likely has lines 16/17 mapped.
*/
- lsdmr_common |= CONFIG_SYS_LBC_LSDMR_BSMA1617;
+ lsdmr_common |= LSDMR_BSMA1617;
}
/*
* Issue PRECHARGE ALL command.
*/
- lbc-lsdmr = lsdmr_common | CONFIG_SYS_LBC_LSDMR_OP_PCHALL;
+ lbc-lsdmr = lsdmr_common | LSDMR_OP_PCHALL;
asm(sync;msync);
*sdram_addr = 0xff;
ppcDcbf((unsigned long) sdram_addr);
@@ -396,7 +396,7 @@ sdram_init(void)
* Issue 8 AUTO REFRESH commands.
*/
for (idx = 0; idx 8; idx++) {
- lbc-lsdmr = lsdmr_common | CONFIG_SYS_LBC_LSDMR_OP_ARFRSH;
+ lbc-lsdmr = lsdmr_common | LSDMR_OP_ARFRSH;
asm(sync;msync);
*sdram_addr = 0xff;
ppcDcbf((unsigned long) sdram_addr);
@@ -406,7 +406,7 @@ sdram_init(void)
/*
* Issue 8 MODE-set command.
*/
- lbc-lsdmr = lsdmr_common | CONFIG_SYS_LBC_LSDMR_OP_MRW;
+ lbc-lsdmr = lsdmr_common | LSDMR_OP_MRW;
asm(sync;msync);
*sdram_addr = 0xff;
ppcDcbf((unsigned long) sdram_addr);
@@ -415,7 +415,7 @@ sdram_init(void)
/*
* Issue NORMAL OP command.
*/
- lbc-lsdmr = lsdmr_common | CONFIG_SYS_LBC_LSDMR_OP_NORMAL;
+ lbc-lsdmr = lsdmr_common | LSDMR_OP_NORMAL;
asm(sync;msync);
*sdram_addr = 0xff;
ppcDcbf((unsigned long) sdram_addr);
diff --git a/board/freescale/mpc8548cds/mpc8548cds.c
b/board/freescale/mpc8548cds/mpc8548cds.c
index 70320ea..efb2c5b 100644
--- a/board/freescale/mpc8548cds/mpc8548cds.c
+++ b/board/freescale/mpc8548cds/mpc8548cds.c
@@ -185,12 +185,12 @@ sdram_init(void)
*/
cpu_board_rev = get_cpu_board_revision();
lsdmr_common = CONFIG_SYS_LBC_LSDMR_COMMON;
- lsdmr_common |= CONFIG_SYS_LBC_LSDMR_BSMA1516;
+ lsdmr_common |= LSDMR_BSMA1516;
/*
* Issue PRECHARGE ALL command.
*/
- lbc-lsdmr = lsdmr_common | CONFIG_SYS_LBC_LSDMR_OP_PCHALL;
+ lbc-lsdmr = lsdmr_common | LSDMR_OP_PCHALL;
asm(sync;msync);
*sdram_addr = 0xff;
ppcDcbf((unsigned long) sdram_addr);
@@ -200,7 +200,7 @@ sdram_init(void)
* Issue 8 AUTO REFRESH commands.
*/
for (idx = 0; idx 8; idx++) {
- lbc-lsdmr = lsdmr_common | CONFIG_SYS_LBC_LSDMR_OP_ARFRSH;
+ lbc-lsdmr = lsdmr_common | LSDMR_OP_ARFRSH;
asm(sync;msync);
*sdram_addr = 0xff;
ppcDcbf((unsigned long) sdram_addr);
@@ -210,7 +210,7 @@ sdram_init(void)
/*
* Issue 8 MODE-set command.
*/
- lbc-lsdmr = lsdmr_common | CONFIG_SYS_LBC_LSDMR_OP_MRW;
+ lbc-lsdmr = lsdmr_common | LSDMR_OP_MRW;
asm(sync;msync);
*sdram_addr = 0xff;
ppcDcbf((unsigned long) sdram_addr);
@@ -219,7 +219,7 @@ sdram_init(void)
/*
* Issue NORMAL OP command.
*/
- lbc-lsdmr = lsdmr_common | CONFIG_SYS_LBC_LSDMR_OP_NORMAL;
+ lbc-lsdmr = lsdmr_common | LSDMR_OP_NORMAL;
asm(sync;msync);
*sdram_addr = 0xff;
ppcDcbf((unsigned long)
[U-Boot] [PATCH] ads5121: enable instruction cache
From: Wolfgang Denk w...@denx.de Enabling the instruction cache significantly accelerates U-Boot operations like CRC checking, image uncompression, etc. Kudos to Andrea Scian for pointing out. Signed-off-by: Wolfgang Denk w...@denx.de --- include/configs/ads5121.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/configs/ads5121.h b/include/configs/ads5121.h index 8fda3f2..d879024 100644 --- a/include/configs/ads5121.h +++ b/include/configs/ads5121.h @@ -411,7 +411,7 @@ #endif #define CONFIG_SYS_HID0_INIT 0x0 -#define CONFIG_SYS_HID0_FINAL HID0_ENABLE_MACHINE_CHECK +#define CONFIG_SYS_HID0_FINAL (HID0_ENABLE_MACHINE_CHECK | HID0_ICE) #define CONFIG_SYS_HID2HID2_HBE #define CONFIG_HIGH_BATS 1 /* High BATs supported */ -- 1.6.0.6 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] LPC2468 support
Jean-Christophe PLAGNIOL-VILLARD schreef:
No, thumb code is less efficient in terms of performance, but this
single file needs thumb code. See LPC2292.
what is the Difference?
until a real big gap please do not use thumb
IAP entries need thumb code. This is not a problem, they are only used
for programming the internal flash of the processor, so there is no
performance penalty for normal operation.
Yes I do. They are straight from the LPC2292 code, so once they were
considered OK. I checked out the the write{s,l,b} functions in asm/io.h,
but although they look similar, for some reason they simply don't work.
Given the similarities between the write{s,l,b} and the PUT* functions,
what is the problem with those? Furthermore, the ARM architecture
doesn't use any kind of special instructions for accessing registers,
everything is memory mapped.
please use readx/writex
Thanks for the pointer, I'll look into those.
I do understand that you want the best code for U-boot, but I do not
entirely agree on all points. Certainly when I look at the code already
in place in U-boot.
I'm preparing a patch series to clean the arm720t to seprate it as arch
and avoid this borring #ifdef
Can you explain what you mean here?
Kind regards,
Remco Poelstra
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] LPC2468 example board
Jean-Christophe PLAGNIOL-VILLARD schreef: please clean up first before a full review Hi, This patch is outdated. After the part 1 patch is OK, I'll work on this part. I'll include your comments then. Kind regards, Remco Poelstra ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] LPC2468 support
Jean-Christophe PLAGNIOL-VILLARD schreef: I'm not an expert in assembly, but at first I had immap.h included in start.S and it complained about invalid instructions, so if I combine hardware.h and immap.h, then there must be some way of making sure that the assembler ignores the C code in immap.h. Do you know of any such thing? immap.h? immap.h is like hardware.h for the LPC2292, but it contains C structures to define the registers instead of #defines. I based it on the ppc code. See the patch for an explanation. I can remove the file, but than I need to put an #ifdef construct in start.S to only exclude it in the lpc2468 case. The file is used by the other ARM ports. I can also simply empty it, but in this way it is more similar to the other ports. What would you like? no please do not I'll prefer to separate arch file I do not understand what you mean with the last part of your comment. Kind regards, Remco Poelstra ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/7] drivers/twserial: Add protocol driver for three wire serial interface.
Hi Wolfgang, Dear Detlev Zundel, In message 1237998478-18452-4-git-send-email-...@denx.de you wrote: This pretty unintelligent interface is used on some RTC chips. Signed-off-by: Detlev Zundel d...@denx.de ... diff --git a/include/tws.h b/include/tws.h new file mode 100644 index 000..bfa8d58 --- /dev/null +++ b/include/tws.h @@ -0,0 +1,47 @@ ... +#ifndef _TWS_H_ +#define _TWS_H_ + +#ifndef TWS_SOFT_DECLARATIONS +# if defined(CONFIG_MPC5xxx) +# define TWS_SOFT_DECLARATIONS \ + volatile ioport_t *iop = ioport_addr((immap_t *)CONFIG_SYS_IMMR, I2C_PORT); +# else +# define TWS_SOFT_DECLARATIONS +# endif +#endif Indentation not by TAB. Yes, intentionally so. Indenting by TAB exceeds the available line length. Judging by this single line I felt non-breaking the line was more important. Can you please point me to the section in the CodingStyle regarding indentation for macros? I'd be much obliged. Thanks Detlev -- It's amazing I won. I was running against peace, prosperity, and incumbency. -- George H.W. Bush, 06/14/2001, talking to Swedish prime minister Goran Perrson, unaware that a live tv camera was still on -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] cfi_flash and complex address mapping
On Wednesday 25 March 2009, thomas.lan...@infineon.com wrote:
I'm in the process of preparing some code for a new board and want to use
the generic cfi flash driver. The problem is EBU (External Bus Unit) of the
chip, which is internally 32bit.
Which SoC is this btw?
The access to 8/16bit values are always mapped by the EBU, but in a little
endian way, which is bad on a big endian system: On an interface configured
for 16bit, the following conversion from internal address to bus-address is
done: CPU external bus
0x 0x0002
0x0002 0x
0x0004 0x0006
0x0006 0x0004
Arrgh!
If I implement my own flash_read%/flash_write% to do the address mapping,
the data is also swapped. In this functions I cannot decide if the access
is for the flash control or the data to be programmed.
Yes, too bad that this doesn't work for you.
My current solution is the following patch and these definitions in the
board config file (for a 16bit flash):
#define FLASH_FIXUP_ADDR_8(addr) ((void*)((ulong)(addr)^2))
#define FLASH_FIXUP_ADDR_16(addr) ((void*)((ulong)(addr)^2))
My question now is: Would such a change be accepted for the mainline
u-boot? Or does someone has a better idea?
Yes, I think this could be accepted. The overall impact on the driver is not
too big. Let's see if others have some complaints about it. If not, I'll
accept you patch after you changed some minor details.
Please find some more comments below.
Thanks for your comments,
Thomas
PS: The patch is against u-boot-2009.01
You should add your Signed-off-by line to this commit text. Best you generate
and send your patches using the git tools.
--- a/drivers/mtd/cfi_flash.c
+++ b/drivers/mtd/cfi_flash.c
@@ -176,6 +176,23 @@ flash_info_t flash_info[CFI_MAX_FLASH_BA
#define CONFIG_SYS_FLASH_CFI_WIDTH FLASH_CFI_8BIT
#endif
+/*
+ * Check if address fixup macros are defined, define defaults otherwise
+ */
+#ifndef FLASH_FIXUP_ADDR_8
+#define FLASH_FIXUP_ADDR_8(addr) (addr)
+#endif
+#ifndef FLASH_FIXUP_ADDR_16
+#define FLASH_FIXUP_ADDR_16(addr)(addr)
+#endif
+#ifndef FLASH_FIXUP_ADDR_32
+#define FLASH_FIXUP_ADDR_32(addr)(addr)
+#endif
+#ifndef FLASH_FIXUP_ADDR_64
+#define FLASH_FIXUP_ADDR_64(addr)(addr)
+#endif
+
+
/* CFI standard query structure */
struct cfi_qry {
u8 qry[3];
@@ -392,9 +409,9 @@ static inline uchar flash_read_uchar (fl
cp = flash_map (info, 0, offset);
#if defined(__LITTLE_ENDIAN) || defined(CONFIG_SYS_WRITE_SWAPPED_DATA)
- retval = flash_read8(cp);
+ retval = flash_read8(FLASH_FIXUP_ADDR_8(cp));
#else
- retval = flash_read8(cp + info-portwidth - 1);
+ retval = flash_read8(FLASH_FIXUP_ADDR_8(cp) + info-portwidth - 1);
#endif
flash_unmap (info, 0, offset, cp);
return retval;
@@ -408,7 +425,7 @@ static inline ushort flash_read_word (fl
ushort *addr, retval;
addr = flash_map (info, 0, offset);
- retval = flash_read16 (addr);
+ retval = flash_read16 (FLASH_FIXUP_ADDR_16(addr));
flash_unmap (info, 0, offset, addr);
return retval;
}
@@ -433,19 +450,28 @@ static ulong flash_read_long (flash_info
debug (long addr is at %p info-portwidth = %d\n, addr,
info-portwidth);
for (x = 0; x 4 * info-portwidth; x++) {
- debug (addr[%x] = 0x%x\n, x, flash_read8(addr + x));
+ debug (addr[%x] = 0x%x\n, x,
+ flash_read8(FLASH_FIXUP_ADDR_32(addr) + x));
}
#endif
#if defined(__LITTLE_ENDIAN) || defined(CONFIG_SYS_WRITE_SWAPPED_DATA)
- retval = ((flash_read8(addr) 16) |
- (flash_read8(addr + info-portwidth) 24) |
- (flash_read8(addr + 2 * info-portwidth)) |
- (flash_read8(addr + 3 * info-portwidth) 8));
+ retval = ((flash_read8(FLASH_FIXUP_ADDR_8
+ (addr) 16) |
I don't like this line split above and below, where the parameter for
FLASH_FIXUP_ADDR_8 is moved into the 2nd line. But I understand that you did
this because of the line length restrictions, correct? Perhaps we should
introduce a local variable for info-portwidth (e.g. pw) and the statement
will still fit into one line? Or at least the parameter for FLASH_FIXUP...
+ (flash_read8(FLASH_FIXUP_ADDR_8
+ (addr + info-portwidth)) 24) |
+ (flash_read8(FLASH_FIXUP_ADDR_8
+ (addr + 2 * info-portwidth))) |
+ (flash_read8(FLASH_FIXUP_ADDR_8
+ (addr + 3 * info-portwidth)) 8));
#else
- retval = ((flash_read8(addr + 2 * info-portwidth - 1) 24) |
- (flash_read8(addr + info-portwidth - 1) 16) |
- (flash_read8(addr + 4 * info-portwidth - 1) 8) |
- (flash_read8(addr + 3 * info-portwidth - 1)));
+ retval = ((flash_read8(FLASH_FIXUP_ADDR_8
Re: [U-Boot] [PATCH 1/2] LPC2468 support
Remco Poelstra schreef:
Yes I do. They are straight from the LPC2292 code, so once they were
considered OK. I checked out the the write{s,l,b} functions in asm/io.h,
but although they look similar, for some reason they simply don't work.
Given the similarities between the write{s,l,b} and the PUT* functions,
what is the problem with those? Furthermore, the ARM architecture
doesn't use any kind of special instructions for accessing registers,
everything is memory mapped.
please use readx/writex
Thanks for the pointer, I'll look into those.
I can't find these functions/macros, but I think you mean the
write{b,s,l} macros. As I already indicated in a previous e-mail, they
do not work in my code. If I replace, e.g. the PUT32 with writel than
the code doesn't run. I will look into that problem after I've finished
another project at work.
Kind regards,
Remco Poelstra
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] You have won 1.000.000.00. Euro
Confirmation Reference Number: 78-45-2-12-47-66-4 reply to E-mail to:frank.daniels...@gmail.com You have won #128;1.000.000.00. Euro (One million Euro) in the Euro Millions Email Sweepstakes Program Corporation, held on the 16th of March 2009. In London, United Kingdom. Please contact the agency for the claim. contact person:Mr.Frank Daniels TEL: +44-703-1952966 Fax: +44-703-195-2966 reply to E-mail to:frank.daniels...@gmail.com Below are your Winning Information's: Email Ticket Number 15-21-4-19-27-44 Reference Number: 78-45-2-12-47-66-4 Draw Lucky Number:8-17-10-13-37/*5*7 Batch Number :JKPN44521412 Serial Number: HMML235524453 1. Full Name: 2. Full Address: 3. Occupation: 4. Age/Sex: 5. Phone Number/ Fax: 6. Country : Phone Number: Note, All winning must be claim not later than 26th of April 2009. Sincerely, Mrs. Holt, Dillon S. E-mail:frank.daniels...@gmail.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 4/4] Flex-OneNAND boundary setting command
Hi Scott, I believe that typecasting a UL to an int, is OK. Do let me know. The compiler will implicitly cast unsigned long to int. The explicit cast is unnecessary clutter which makes it harder to find casts that aren't OK. Accepted and changed. Thank You Amul. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] minicom garbled
SlinceArm wrote: Hi , Wolfgang Denk Thank for your reply : ) U-Boot 1.1.4 is prehistoric, please use reacent code. And minicom is officially unsupported (see the repective entry in the U-Boot manual). Ok , i will try to install u-boot-2009-03 in my board But , is any other setting cause garbled ?? I get some information about my issue form internet . They say , the issue is caused about my system language I changed it ( export LANG=C and my minicom character encoding ) But the issue still there . Baudrate : 115200 8N1 Maybe that setting is simply wrong? I refer my board manual , it's 115200 8N1 Do you know the u-boot you loaded is configured for your board? Another way for garbling is if your board's baud rate generator (clocking) is not what the u-boot that you loaded is configured for, causing it to generate an oddball baud rate. gvb ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Size of external u-boot commands
My networking hardware needs microcode loaded into it before it will function. What's the best method to load this code? It's 70KB. My current u-boot image is 170KB. I started working with the code in examples and api_examples. But the hello world programs built using those APIs are 65-72KB in size. That's almost half the size of my u-boot image and these programs just print hello world. Why are these programs so big? My goal was to put the loader program and my microcode into a single 128KB erase block. My code for loading the microcode into the hardware is 7KB. Now it looks like I will need to incorporate it into the main u-boot image instead of making it an external command. -- Jon Smirl jonsm...@gmail.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Size of external u-boot commands
Jon Smirl wrote: My networking hardware needs microcode loaded into it before it will function. What's the best method to load this code? It's 70KB. My current u-boot image is 170KB. I started working with the code in examples and api_examples. But the hello world programs built using those APIs are 65-72KB in size. That's almost half the size of my u-boot image and these programs just print hello world. Why are these programs so big? My goal was to put the loader program and my microcode into a single 128KB erase block. My code for loading the microcode into the hardware is 7KB. Now it looks like I will need to incorporate it into the main u-boot image instead of making it an external command. Hi Jon, I suspect the example code is 98% C libraries and 2% nugget. In your example, hello world probably uses the whole printf support tree (strings, formatted printing, possibly floating point...). I would suggest you make a stand-alone application that simply returns and see how big it ends up. Depending on whether that is small or not, check what libraries get linked with it and see how to create your simple test app such that it doesn't use any extraneous libraries. HTH, gvb ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Size of external u-boot commands
On Thu, Mar 26, 2009 at 9:52 AM, Jerry Van Baren gerald.vanba...@ge.com wrote: Jon Smirl wrote: My networking hardware needs microcode loaded into it before it will function. What's the best method to load this code? It's 70KB. My current u-boot image is 170KB. I started working with the code in examples and api_examples. But the hello world programs built using those APIs are 65-72KB in size. That's almost half the size of my u-boot image and these programs just print hello world. Why are these programs so big? My goal was to put the loader program and my microcode into a single 128KB erase block. My code for loading the microcode into the hardware is 7KB. Now it looks like I will need to incorporate it into the main u-boot image instead of making it an external command. Hi Jon, I suspect the example code is 98% C libraries and 2% nugget. In your example, hello world probably uses the whole printf support tree (strings, formatted printing, possibly floating point...). I would suggest you make a stand-alone application that simply returns and see how big it ends up. Depending on whether that is small or not, check what libraries get linked with it and see how to create your simple test app such that it doesn't use any extraneous libraries. Libraries appear to be the problem. A program that just returns is 100 bytes, add a puts(hello world) and it is 65KB. I had expected the u-boot app examples to be smart and use the copy of those libraries in the u-boot image. For example the demo program in api_examples uses printf (65K library) instead of building an api calling into u-boot for printf. HTH, gvb -- Jon Smirl jonsm...@gmail.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] cfi_flash and complex address mapping
In message 200903261103.28452...@denx.de you wrote: #define FLASH_FIXUP_ADDR_8(addr) ((void*)((ulong)(addr)^2)) #define FLASH_FIXUP_ADDR_16(addr) ((void*)((ulong)(addr)^2)) ... Yes, I think this could be accepted. The overall impact on the driver is not too big. Let's see if others have some complaints about it. If not, I'll accept you patch after you changed some minor details. I think that should be an inline function instead of a macro. Best regards, Wolfgang Denk Thanks for the comments. I will take it into account before sending the complete patch series for the board(s). But I have to do some more cleanups before I can do that. I just wanted to check if this is the right way to go. Best regards, Thomas Langer ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] build u-boot and ubl for DM355
Can some one tell how to build u-boot and ubl for DM355 to be located on its NandFlash? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Size of external u-boot commands
On 2009-03-26, at 15:21, Jon Smirl wrote: Libraries appear to be the problem. A program that just returns is 100 bytes, add a puts(hello world) and it is 65KB. I had expected the u-boot app examples to be smart and use the copy of those libraries in the u-boot image. For example the demo program in api_examples uses printf (65K library) instead of building an api calling into u-boot for printf. While I can understand your position, let me explain that the idea behind the API was to provide calls to really elementary operations and printf() wasn't considered as such (we only have print, get and test a single character as far as console ops go); things like pre- formatting should be done in the application... The demo application is just a demo, it links in the same printf- formatting code that U-Boot library uses, but specific standalone applications are supposed to implement their own formatting routines. Rafal ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Size of external u-boot commands
On Thu, Mar 26, 2009 at 10:43 AM, Rafal Jaworowski r...@semihalf.com wrote: On 2009-03-26, at 15:21, Jon Smirl wrote: Libraries appear to be the problem. A program that just returns is 100 bytes, add a puts(hello world) and it is 65KB. I had expected the u-boot app examples to be smart and use the copy of those libraries in the u-boot image. For example the demo program in api_examples uses printf (65K library) instead of building an api calling into u-boot for printf. While I can understand your position, let me explain that the idea behind the API was to provide calls to really elementary operations and printf() wasn't considered as such (we only have print, get and test a single character as far as console ops go); things like pre-formatting should be done in the application... The demo application is just a demo, it links in the same printf-formatting code that U-Boot library uses, but specific standalone applications are supposed to implement their own formatting routines. I'm not sure that the size of the app is caused by libraries. jonsm...@terra:/home/apps/u-boot/api_examples$ ls -l demo.bin -rwxr-xr-x 1 jonsmirl jonsmirl 79060 2009-03-26 10:58 demo.bin now gzip the bin -rwxr-xr-x 1 jonsmirl jonsmirl 7677 2009-03-26 10:58 demo.bin.gz Here's the map file; I'm trying to remember how to read it. There's probably 64K of a data segment being initialized with zeros. Archive member included because of file (symbol) libglue.a(ppcstring.o)demo.o (memset) libglue.a(glue.o) demo.o (ub_dev_get) libglue.a(crc32.o)libglue.a(glue.o) (crc32) libglue.a(libgenwrap.o) demo.o (printf) libglue.a(vsprintf.o) libglue.a(libgenwrap.o) (vsprintf) libglue.a(ctype.o)libglue.a(vsprintf.o) (_ctype) libglue.a(string.o) libglue.a(vsprintf.o) (strnlen) Allocating common symbols Common symbol size file ___strtok 0x4 libglue.a(string.o) Discarded input sections .note.GNU-stack 0x0x0 demo.o .note.GNU-stack 0x0x0 libglue.a(glue.o) .note.GNU-stack 0x0x0 libglue.a(crc32.o) .note.GNU-stack 0x0x0 libglue.a(libgenwrap.o) .note.GNU-stack 0x0x0 libglue.a(vsprintf.o) .note.GNU-stack 0x0x0 libglue.a(ctype.o) .note.GNU-stack 0x0x0 libglue.a(string.o) Memory Configuration Name Origin Length Attributes *default*0x 0x Linker script and memory map LOAD crt0.o Address of section .text set to 0x4 LOAD demo.o LOAD libglue.a 0x1000PROVIDE (__executable_start, 0x1000) 0x1094. = (0x1000 + SIZEOF_HEADERS) .interp *(.interp) .note.gnu.build-id *(.note.gnu.build-id) .hash *(.hash) .gnu.hash *(.gnu.hash) .dynsym *(.dynsym) .dynstr *(.dynstr) .gnu.version *(.gnu.version) .gnu.version_d *(.gnu.version_d) .gnu.version_r *(.gnu.version_r) .rel.dyn *(.rel.init) *(.rel.text .rel.text.* .rel.gnu.linkonce.t.*) *(.rel.fini) *(.rel.rodata .rel.rodata.* .rel.gnu.linkonce.r.*) *(.rel.data.rel.ro* .rel.gnu.linkonce.d.rel.ro.*) *(.rel.data .rel.data.* .rel.gnu.linkonce.d.*) *(.rel.tdata .rel.tdata.* .rel.gnu.linkonce.td.*) *(.rel.tbss .rel.tbss.* .rel.gnu.linkonce.tb.*) *(.rel.ctors) *(.rel.dtors) *(.rel.got) *(.rel.sdata .rel.sdata.* .rel.gnu.linkonce.s.*) *(.rel.sbss .rel.sbss.* .rel.gnu.linkonce.sb.*) *(.rel.sdata2 .rel.sdata2.* .rel.gnu.linkonce.s2.*) *(.rel.sbss2 .rel.sbss2.* .rel.gnu.linkonce.sb2.*) *(.rel.bss .rel.bss.* .rel.gnu.linkonce.b.*) .rela.dyn 0x10940x0 *(.rela.init) *(.rela.text .rela.text.* .rela.gnu.linkonce.t.*) .rela.text 0x0x0 crt0.o *(.rela.fini) *(.rela.rodata .rela.rodata.* .rela.gnu.linkonce.r.*) *(.rela.data .rela.data.* .rela.gnu.linkonce.d.*) *(.rela.tdata .rela.tdata.* .rela.gnu.linkonce.td.*) *(.rela.tbss .rela.tbss.* .rela.gnu.linkonce.tb.*) *(.rela.ctors) *(.rela.dtors) *(.rela.got) *(.rela.got1) *(.rela.got2) .rela.got2 0x0x0 crt0.o *(.rela.sdata .rela.sdata.* .rela.gnu.linkonce.s.*) *(.rela.sbss .rela.sbss.* .rela.gnu.linkonce.sb.*) *(.rela.sdata2 .rela.sdata2.* .rela.gnu.linkonce.s2.*) *(.rela.sbss2 .rela.sbss2.* .rela.gnu.linkonce.sb2.*) *(.rela.bss .rela.bss.* .rela.gnu.linkonce.b.*) .rel.plt *(.rel.plt) .rela.plt *(.rela.plt) .init *(.init) .text 0x0004 0x2930 *(.text .stub .text.* .gnu.linkonce.t.*) .text 0x0004 0x38 crt0.o 0x00040010syscall 0x00040034
Re: [U-Boot] Size of external u-boot commands
On Thu, Mar 26, 2009 at 11:06 AM, Jon Smirl jonsm...@gmail.com wrote: On Thu, Mar 26, 2009 at 10:43 AM, Rafal Jaworowski r...@semihalf.com wrote: On 2009-03-26, at 15:21, Jon Smirl wrote: Libraries appear to be the problem. A program that just returns is 100 bytes, add a puts(hello world) and it is 65KB. I had expected the u-boot app examples to be smart and use the copy of those libraries in the u-boot image. For example the demo program in api_examples uses printf (65K library) instead of building an api calling into u-boot for printf. While I can understand your position, let me explain that the idea behind the API was to provide calls to really elementary operations and printf() wasn't considered as such (we only have print, get and test a single character as far as console ops go); things like pre-formatting should be done in the application... The demo application is just a demo, it links in the same printf-formatting code that U-Boot library uses, but specific standalone applications are supposed to implement their own formatting routines. I'm not sure that the size of the app is caused by libraries. jonsm...@terra:/home/apps/u-boot/api_examples$ ls -l demo.bin -rwxr-xr-x 1 jonsmirl jonsmirl 79060 2009-03-26 10:58 demo.bin now gzip the bin -rwxr-xr-x 1 jonsmirl jonsmirl 7677 2009-03-26 10:58 demo.bin.gz Here's the map file; I'm trying to remember how to read it. There's probably 64K of a data segment being initialized with zeros. What is this doing? Can I turn it off? .gcc_except_table *(.gcc_except_table .gcc_except_table.*) 0x00043290. = (ALIGN (0x1) - ((0x1 - .) 0x)) 0x00053290. = (0x1 DATA_SEGMENT_ALIGN 0x1000) -- Jon Smirl jonsm...@gmail.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] karef/metrobox/xpedite1k: fix eth_setenv_enetaddr typos
The function is called eth_setenv_enetaddr, not eth_putenv_enetaddr.
Signed-off-by: Mike Frysinger vap...@gentoo.org
CC: Ben Warren biggerbadder...@gmail.com
---
board/sandburst/karef/karef.c |8
board/sandburst/metrobox/metrobox.c |8
board/xpedite1k/xpedite1k.c |8
3 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/board/sandburst/karef/karef.c b/board/sandburst/karef/karef.c
index 55310d7..1ad1ae2 100644
--- a/board/sandburst/karef/karef.c
+++ b/board/sandburst/karef/karef.c
@@ -412,28 +412,28 @@ int misc_init_r (void)
#ifdef CONFIG_HAS_ETH0
if (!eth_getenv_enetaddr(ethaddr, enetaddr)) {
board_get_enetaddr(0, enetaddr);
- eth_putenv_enetaddr(ethaddr, enetaddr);
+ eth_setenv_enetaddr(ethaddr, enetaddr);
}
#endif
#ifdef CONFIG_HAS_ETH1
if (!eth_getenv_enetaddr(eth1addr, enetaddr)) {
board_get_enetaddr(1, enetaddr);
- eth_putenv_enetaddr(eth1addr, enetaddr);
+ eth_setenv_enetaddr(eth1addr, enetaddr);
}
#endif
#ifdef CONFIG_HAS_ETH2
if (!eth_getenv_enetaddr(eth2addr, enetaddr)) {
board_get_enetaddr(2, enetaddr);
- eth_putenv_enetaddr(eth2addr, enetaddr);
+ eth_setenv_enetaddr(eth2addr, enetaddr);
}
#endif
#ifdef CONFIG_HAS_ETH3
if (!eth_getenv_enetaddr(eth3addr, enetaddr)) {
board_get_enetaddr(3, enetaddr);
- eth_putenv_enetaddr(eth3addr, enetaddr);
+ eth_setenv_enetaddr(eth3addr, enetaddr);
}
#endif
diff --git a/board/sandburst/metrobox/metrobox.c
b/board/sandburst/metrobox/metrobox.c
index 8bb8c02..bd6be3d 100644
--- a/board/sandburst/metrobox/metrobox.c
+++ b/board/sandburst/metrobox/metrobox.c
@@ -383,28 +383,28 @@ int misc_init_r (void)
#ifdef CONFIG_HAS_ETH0
if (!eth_getenv_enetaddr(ethaddr, enetaddr)) {
board_get_enetaddr(0, enetaddr);
- eth_putenv_enetaddr(ethaddr, enetaddr);
+ eth_setenv_enetaddr(ethaddr, enetaddr);
}
#endif
#ifdef CONFIG_HAS_ETH1
if (!eth_getenv_enetaddr(eth1addr, enetaddr)) {
board_get_enetaddr(1, enetaddr);
- eth_putenv_enetaddr(eth1addr, enetaddr);
+ eth_setenv_enetaddr(eth1addr, enetaddr);
}
#endif
#ifdef CONFIG_HAS_ETH2
if (!eth_getenv_enetaddr(eth2addr, enetaddr)) {
board_get_enetaddr(2, enetaddr);
- eth_putenv_enetaddr(eth2addr, enetaddr);
+ eth_setenv_enetaddr(eth2addr, enetaddr);
}
#endif
#ifdef CONFIG_HAS_ETH3
if (!eth_getenv_enetaddr(eth3addr, enetaddr)) {
board_get_enetaddr(3, enetaddr);
- eth_putenv_enetaddr(eth3addr, enetaddr);
+ eth_setenv_enetaddr(eth3addr, enetaddr);
}
#endif
diff --git a/board/xpedite1k/xpedite1k.c b/board/xpedite1k/xpedite1k.c
index cd1a368..92dc628 100644
--- a/board/xpedite1k/xpedite1k.c
+++ b/board/xpedite1k/xpedite1k.c
@@ -364,27 +364,27 @@ int misc_init_r(void)
if (!eth_getenv_enetaddr(ethaddr, enetaddr)) {
board_get_enetaddr(i2c_enetaddr);
- eth_putenv_enetaddr(ethaddr, i2c_enetaddr);
+ eth_setenv_enetaddr(ethaddr, i2c_enetaddr);
}
#ifdef CONFIG_HAS_ETH1
if (!eth_getenv_enetaddr(eth1addr, enetaddr)) {
board_get_enetaddr(i2c_enetaddr);
- eth_putenv_enetaddr(eth1addr, i2c_enetaddr);
+ eth_setenv_enetaddr(eth1addr, i2c_enetaddr);
}
#endif
#ifdef CONFIG_HAS_ETH2
if (!eth_getenv_enetaddr(eth2addr, enetaddr)) {
board_get_enetaddr(i2c_enetaddr);
- eth_putenv_enetaddr(eth2addr, i2c_enetaddr);
+ eth_setenv_enetaddr(eth2addr, i2c_enetaddr);
}
#endif
#ifdef CONFIG_HAS_ETH3
if (!eth_getenv_enetaddr(eth3addr, enetaddr)) {
board_get_enetaddr(i2c_enetaddr);
- eth_putenv_enetaddr(eth3addr, i2c_enetaddr);
+ eth_setenv_enetaddr(eth3addr, i2c_enetaddr);
}
#endif
--
1.6.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Size of external u-boot commands
On Thursday 26 March 2009 09:47:08 Jon Smirl wrote: My networking hardware needs microcode loaded into it before it will function. What's the best method to load this code? It's 70KB. can the microcode access external memory (i.e. where u-boot lives) ? iirc, the external functions are not linked statically into u-boot applications. the application uses function pointers that get relocated to point to u-boot in external memory. -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] drivers/net/tsec.c - mii_parse_sr does not wait for auto-negotiation completion bug fix
On Tue, Mar 24, 2009 at 9:01 PM, Peter Tyser pty...@xes-inc.com wrote:
Hi Michael,
On Tue, 2009-03-24 at 19:57 +0200, Michael Zaidman wrote:
drivers/net/tsec.c - mii_parse_sr does not wait for auto-negotiation
completion bug fix
In the case when the MIIM_STATUS_LINK is 0 i.e. link is down
and this is the situation immediately after power up,
the code of awaiting for auto-negotiation completion now will be executed.
Signed-off-by: Michael Zaidman michael.zaid...@gmail.com
---
drivers/net/tsec.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/tsec.c b/drivers/net/tsec.c
index 399116f..54279ca 100644
--- a/drivers/net/tsec.c
+++ b/drivers/net/tsec.c
@@ -363,7 +363,7 @@ uint mii_parse_sr(uint mii_reg, struct tsec_private *
priv)
* (ie - we're capable and it's not done)
*/
mii_reg = read_phy_reg(priv, MIIM_STATUS);
- if ((mii_reg MIIM_STATUS_LINK) (mii_reg PHY_BMSR_AUTN_ABLE)
+ if (!(mii_reg MIIM_STATUS_LINK) (mii_reg PHY_BMSR_AUTN_ABLE)
!(mii_reg PHY_BMSR_AUTN_COMP)) {
int i = 0;
This issue has been brought up once before:
http://lists.denx.de/pipermail/u-boot/2009-February/046829.html
There was some concern about adding delay to the boot process in the
case that the primary ethernet port(s) did not achieve link.
There had also been some discussion about performing PHY
auto-negotiation in parallel, but this seems like a much larger can of
worms.
I had proposed this:
http://lists.denx.de/pipermail/u-boot/2009-February/048489.html
Andy/Ben, any feedback on getting a patch such as Michael's or mine
merged in?
Thanks,
Peter
Hi Peter,
Thanks for the reference. I found this thread very interesting.
Before I submitted the patch I also wondered if it is possible for
the link status to be OK while auto-negotiation has not been completed yet.
So I dived into the IEEE-802.3 spec (Clause 28) and figured out that
according to the Arbitration state diagram (Figure 28-16) the
auto-negotiation
completed indication is asserted after the link status became OK.
It contradicts with Marvell’s 88E phy behavior on my mpc8349 based board
where link status OK (register 1.2) always comes at least with 1 tbclk delay
after auto-negotiation completion indication (register 1.5).
It probably explains why the delay of 500 ms “results in faster booting”
as stated in the code - without this delay the CPU leaves the routine with
MIIM_STATUS_LINK still being in the down state.
By replacing the PHY_BMSR_AUTN_CMP with MIIM_STATUS_LINK in loop exiting
condition we eliminate the 500 ms delay.
The spec also specifies auto-negotiation timeout in table 28-9.
Its worst case value can be calculated as:
break_link_timer + autoneg_wait_timer + link_fai_inhibit_timer =
1500 ms + 1000 ms + 1000 ms = 3500 ms.
So I reduced the PHY_AUTONEGOTIATE_TIMEOUT to be 4000 ms.
Here is the updated patch
Signed-off-by: Michael Zaidman michael.zaid...@gmail.com
---
diff --git a/drivers/net/tsec.c b/drivers/net/tsec.c
index 399116f..28e9cc7 100644
--- a/drivers/net/tsec.c
+++ b/drivers/net/tsec.c
@@ -363,12 +363,12 @@ uint mii_parse_sr(uint mii_reg, struct
tsec_private * priv)
* (ie - we're capable and it's not done)
*/
mii_reg = read_phy_reg(priv, MIIM_STATUS);
- if ((mii_reg MIIM_STATUS_LINK) (mii_reg PHY_BMSR_AUTN_ABLE)
+ if (!(mii_reg MIIM_STATUS_LINK) (mii_reg PHY_BMSR_AUTN_ABLE)
!(mii_reg PHY_BMSR_AUTN_COMP)) {
int i = 0;
puts(Waiting for PHY auto negotiation to complete);
- while (!(mii_reg PHY_BMSR_AUTN_COMP)) {
+ while (!(mii_reg MIIM_STATUS_LINK)) {
/*
* Timeout reached ?
*/
@@ -386,7 +386,6 @@ uint mii_parse_sr(uint mii_reg, struct tsec_private * priv)
}
puts( done\n);
priv-link = 1;
- udelay(50); /* another 500 ms (results in faster booting) */
} else {
if (mii_reg MIIM_STATUS_LINK)
priv-link = 1;
diff --git a/include/tsec.h b/include/tsec.h
index 7b52e06..ed4c855 100644
--- a/include/tsec.h
+++ b/include/tsec.h
@@ -56,7 +56,7 @@
#define TSEC_TIMEOUT 1000
#define TOUT_LOOP 100
-#define PHY_AUTONEGOTIATE_TIMEOUT 5000 /* in ms */
+#define PHY_AUTONEGOTIATE_TIMEOUT 4000 /* in ms */
/* TBI register addresses */
#define TBI_CR 0x00
Thanks,
Michael
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ppc4xx: Sequoia: Fix TLB reassignment in NAND booting code
This patch fixes a bug in the Sequoia TLB init code to reconfigure the correct TLB (boot space) after running from RAM. This bug was introduced with patch 4d332dbeb08f5863d1ea69d91a00c5499d3a87ed [ppc4xx: Make Sequoia boot vxWorks] which changed the order of the TLB in the Sequoia init.S file. Signed-off-by: Stefan Roese s...@denx.de --- board/amcc/sequoia/init.S |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/board/amcc/sequoia/init.S b/board/amcc/sequoia/init.S index bd346bf..4452d26 100644 --- a/board/amcc/sequoia/init.S +++ b/board/amcc/sequoia/init.S @@ -103,7 +103,7 @@ tlbtab: reconfig_tlb0: sync isync - addir4,r0,0x/* TLB entry #0 */ + addir4,r0,CONFIG_SYS_TLB_FOR_BOOT_FLASH /* TLB entry # */ lis r5,tl...@h ori r5,r5,tl...@l tlbwe r5,r4,0x/* Save it out */ -- 1.6.2.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/7] drivers/twserial: Add protocol driver for three wire serial interface.
Hi Wolfgang, In message 1237998478-18452-4-git-send-email-...@denx.de you wrote: This pretty unintelligent interface is used on some RTC chips. Signed-off-by: Detlev Zundel d...@denx.de ... diff --git a/include/tws.h b/include/tws.h new file mode 100644 index 000..bfa8d58 --- /dev/null +++ b/include/tws.h @@ -0,0 +1,47 @@ ... +#ifndef _TWS_H_ +#define _TWS_H_ + +#ifndef TWS_SOFT_DECLARATIONS +# if defined(CONFIG_MPC5xxx) +# define TWS_SOFT_DECLARATIONS \ + volatile ioport_t *iop = ioport_addr((immap_t *)CONFIG_SYS_IMMR, I2C_PORT); +# else +# define TWS_SOFT_DECLARATIONS +# endif +#endif Indentation not by TAB. Yes, intentionally so. Indenting by TAB exceeds the available line length. Judging by this single line I felt non-breaking the line was more important. Can you please point me to the section in the CodingStyle regarding indentation for macros? I'd be much obliged. The point is moot. Pondering over this piece of code it suddenly occured to me that the best solution is simply to remove it entirely ;) This really is a leftover from an in-between broken implementation of the interface, so the removal in this case bears no consequences. If no further feedback on the patch series arrive, I'll repost the whole stack tomorrow again. Thanks again Detlev -- If you currently have a 32-bit UNIX system, you are advised to trade it in for a 64-bit one sometime before the year 2106. -- Andrew S. Tanenbaum: Modern Operating Systems, 2nd Edition -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] drivers/net/tsec.c - mii_parse_sr does not wait for auto-negotiation completion bug fix
Hi Michael,
Hi Peter,
Thanks for the reference. I found this thread very interesting.
Before I submitted the patch I also wondered if it is possible for
the link status to be OK while auto-negotiation has not been completed
yet.
So I dived into the IEEE-802.3 spec (Clause 28) and figured out that
according to the Arbitration state diagram (Figure 28-16) the
auto-negotiation
completed indication is asserted after the link status became OK.
It contradicts with Marvell’s 88E phy behavior on my mpc8349 based
board
where link status OK (register 1.2) always comes at least with 1 tbclk
delay
after auto-negotiation completion indication (register 1.5).
It probably explains why the delay of 500 ms “results in faster booting”
as stated in the code - without this delay the CPU leaves the routine with
MIIM_STATUS_LINK still being in the down state.
By replacing the PHY_BMSR_AUTN_CMP with MIIM_STATUS_LINK in loop exiting
condition we eliminate the 500 ms delay.
The spec also specifies auto-negotiation timeout in table 28-9.
Its worst case value can be calculated as:
break_link_timer + autoneg_wait_timer + link_fai_inhibit_timer =
1500 ms + 1000 ms + 1000 ms = 3500 ms.
Thanks for the info. Any chance there's a public link to the IEEE spec
you're referencing? I've looked for the info you provided relatively
hard, it'd be great to finally lay my eyes on something concrete:)
So I reduced the PHY_AUTONEGOTIATE_TIMEOUT to be 4000 ms.
Here is the updated patch
Signed-off-by: Michael Zaidman michael.zaid...@gmail.com
---
diff --git a/drivers/net/tsec.c b/drivers/net/tsec.c
index 399116f..28e9cc7 100644
--- a/drivers/net/tsec.c
+++ b/drivers/net/tsec.c
@@ -363,12 +363,12 @@ uint mii_parse_sr(uint mii_reg, struct
tsec_private * priv)
* (ie - we're capable and it's not done)
*/
mii_reg = read_phy_reg(priv, MIIM_STATUS);
- if ((mii_reg MIIM_STATUS_LINK) (mii_reg PHY_BMSR_AUTN_ABLE)
+ if (!(mii_reg MIIM_STATUS_LINK) (mii_reg PHY_BMSR_AUTN_ABLE)
!(mii_reg PHY_BMSR_AUTN_COMP)) {
int i = 0;
puts(Waiting for PHY auto negotiation to complete);
- while (!(mii_reg PHY_BMSR_AUTN_COMP)) {
+ while (!(mii_reg MIIM_STATUS_LINK)) {
Won't this be a problem for PHYs which do adhere to the spec you
mentioned above? If a PHY has achieved link, but auto-negotiation
hasn't completed, we'll return from this function with auto-negotiation
still not complete, which doesn't seem right. According to the spec, we
shouldn't leave this loop until auto-negotiation is done.
It sounds like the reason that my original patch doesn't work for you is
due to the fact that the 88e PHY doesn't adhere to the spec as far
as the ordering of link up and auto-negotation complete? If that's
the case, perhaps we should either wait for both link up and
auto-negotiation to complete, or the 88e (or Marvel PHYs in general)
should have its own mii_parse_sr()?
/*
* Timeout reached ?
*/
@@ -386,7 +386,6 @@ uint mii_parse_sr(uint mii_reg, struct tsec_private *
priv)
}
puts( done\n);
priv-link = 1;
- udelay(50); /* another 500 ms (results in faster booting)
*/
Agreed that it would be great to get rid of this magic delay.
} else {
if (mii_reg MIIM_STATUS_LINK)
priv-link = 1;
diff --git a/include/tsec.h b/include/tsec.h
index 7b52e06..ed4c855 100644
--- a/include/tsec.h
+++ b/include/tsec.h
@@ -56,7 +56,7 @@
#define TSEC_TIMEOUT 1000
#define TOUT_LOOP 100
-#define PHY_AUTONEGOTIATE_TIMEOUT 5000 /* in ms */
+#define PHY_AUTONEGOTIATE_TIMEOUT 4000 /* in ms */
I'd vote for breaking this out into a separate patch with an explanation
from the IEEE spec you referenced above.
Best,
Peter
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Size of external u-boot commands
On Thu, Mar 26, 2009 at 11:10 AM, Jon Smirl jonsm...@gmail.com wrote:
On Thu, Mar 26, 2009 at 11:06 AM, Jon Smirl jonsm...@gmail.com wrote:
On Thu, Mar 26, 2009 at 10:43 AM, Rafal Jaworowski r...@semihalf.com wrote:
On 2009-03-26, at 15:21, Jon Smirl wrote:
Libraries appear to be the problem. A program that just returns is 100
bytes, add a puts(hello world) and it is 65KB.
I had expected the u-boot app examples to be smart and use the copy of
those libraries in the u-boot image. For example the demo program in
api_examples uses printf (65K library) instead of building an api
calling into u-boot for printf.
While I can understand your position, let me explain that the idea behind
the API was to provide calls to really elementary operations and printf()
wasn't considered as such (we only have print, get and test a single
character as far as console ops go); things like pre-formatting should be
done in the application...
The demo application is just a demo, it links in the same printf-formatting
code that U-Boot library uses, but specific standalone applications are
supposed to implement their own formatting routines.
I'm not sure that the size of the app is caused by libraries.
jonsm...@terra:/home/apps/u-boot/api_examples$ ls -l demo.bin
-rwxr-xr-x 1 jonsmirl jonsmirl 79060 2009-03-26 10:58 demo.bin
now gzip the bin
-rwxr-xr-x 1 jonsmirl jonsmirl 7677 2009-03-26 10:58 demo.bin.gz
Here's the map file; I'm trying to remember how to read it.
There's probably 64K of a data segment being initialized with zeros.
What is this doing? Can I turn it off?
.gcc_except_table
*(.gcc_except_table .gcc_except_table.*)
0x00043290 . = (ALIGN (0x1)
- ((0x1 - .) 0x))
0x00053290 . = (0x1
DATA_SEGMENT_ALIGN 0x1000)
I don't know what I'm doing playing around with the linker scripts but
adding this:
.gcc_except_table : ONLY_IF_RO { KEEP (*(.gcc_except_table))
*(.gcc_except_table.*) }
to the script for api_example/demo makes the binary 50KB smaller.
-rwxr-xr-x 1 jonsmirl jonsmirl 16964 2009-03-26 12:08 demo.bin
--
Jon Smirl
jonsm...@gmail.com
--
Jon Smirl
jonsm...@gmail.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] U-Boot's need for MMU
Hi, I am wondering what the ramifications of not using the MMU in U-Boot are? I have an MPC8360 (e300 core) where it is capable of disabling the MMU via the MSR[IR] and MSR[DR] bits. Before disabling the MMU, I'm just wondering why U-Boot bothers to set up the MMU on CPU's that providing disabling of the MMU. PS I'm not disabling the MMU just for kicks, there are/may be some program-specific scenarios where I may need to use the option of disabling the MMU. Thanks. Christopher M. Fairfax Sr. Software Engineer Rockwell Collins +1 540-428-3344 +1 540-428-3301 cmfai...@rockwellcollins.com This message contains PRIVILEGED AND PROPRIETARY INFORMATION intended solely for the use of the addressee(s) named above. Any disclosure, distribution, copying or use of the information by others is strictly prohibited. If you have received this message in error, please advise the sender by immediate reply and delete the original message. Thank you. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot's need for MMU
cmfai...@rockwellcollins.com wrote: Hi, I am wondering what the ramifications of not using the MMU in U-Boot are? I have an MPC8360 (e300 core) where it is capable of disabling the MMU via the MSR[IR] and MSR[DR] bits. Before disabling the MMU, I'm just wondering why U-Boot bothers to set up the MMU on CPU's that providing disabling of the MMU. A big one is that you can't have certain regions be cached (memory) and others uncached (I/O) -- you'll need to turn the D-cache off altogether. And even then I'm not sure what happens to the guarded bit when the MMU is off. I'm not disabling the MMU just for kicks, there are/may be some program-specific scenarios where I may need to use the option of disabling the MMU. Such as? One should generally lead with the reason they want to do something, and only afterwards ask why not. :-) -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Please pull u-boot-ppc4xx
The following changes since commit 33e88c557b29c84c52039ba05993fa70fe62afe3: Jon Smirl (1): mpc5200: suppress printf until console initialized are available in the git repository at: git://www.denx.de/git/u-boot-ppc4xx.git master Stefan Roese (1): ppc4xx: Sequoia: Fix TLB reassignment in NAND booting code board/amcc/sequoia/init.S |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Problems with ext2ls SD
Hi I am working on a port of 1.3.4 to the LPC313x and I am having some trouble with the ext2fs. U-Boot reads blocks 0x00, 0x02, 0x08, 0x200. I modified the code to dump the block data as it is read verified that the data is correct. The ext2ls command returns nothing, I guess thats because block 0x200 is full of zeros bt that Linux box is quite happy to read the SD card. Can anyone help? LPC3131EA # mmcinit Card Detection Results: CID: 2475 1001 53442020 1a505175 CSD: 964000bb 6db7ff9f 5f5983c4 2f0032 card_type: 1 rca: b368 speed: 2500 block_len: 200 device_size: 3c48 blocknr: 1e2400 LPC3131EA # ext2ls mmc 0:0 get_dev: mmc Using device mmc 0:0, directory: / ext2fs_set_blk_dev 0 s:2, o:0, l:204 mci_read_blocks 2 Read 200 bytes 80 F1 00 00 80 C4 03 00 39 30 00 00 1C B4 03 00 75 F1 00 00 00 00 00 00 02 00 00 00 02 00 00 00 00 80 00 00 00 80 00 00 30 1E 00 00 DF AD C3 49 7A C2 C3 49 04 00 25 00 53 EF 00 00 01 00 00 00 6F AD C3 49 00 4E ED 00 00 00 00 00 01 00 00 00 00 00 00 00 0B 00 00 00 00 01 00 00 38 00 00 00 02 00 00 00 03 00 00 00 22 19 EA 74 80 82 4D 8F 82 A0 37 89 42 C3 79 92 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 3C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 43 4E 34 17 16 16 48 46 A2 FD F2 9D D1 86 47 FB 01 00 00 00 00 00 00 00 00 00 00 00 6F AD C3 49 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1C 00 1C 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ext2fs read inode 1 ext2fs read blockgroup s:8, o:0, l:32 mci_read_blocks 8 Read 200 bytes 3E 00 00 00 3F 00 00 00 40 00 00 00 D7 7D 25 1E 02 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00 3E 80 00 00 3F 80 00 00 40 80 00 00 DD 7D 30 1E 00 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 01 00 01 00 02 00 01 00 1B 7E 30 1E 00 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00 3E 80 01 00 3F 80 01 00 40 80 01 00 DD 7D 30 1E 00 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 00 01 00 02 00 02 00 02 00 1B 7E 30 1E 00 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00 3E 80 02 00 3F 80 02 00 40 80 02 00 DD 7D 30 1E 00 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 03 00 01 00 03 00 02 00 03 00 1B 7E 30 1E 00 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00 3E 80 03 00 3F 80 03 00 40 80 03 00 5D 42 30 1E 00 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ext2fs read inode blkno 0 blkoff 1 s:512, o:128, l:128 mci_read_blocks 200 Read 200 bytes 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Re: [U-Boot] Coldfire: MCF5271: Periodic HW watchdog petting and sleep function does not work.
Richard, I used 6 for most platforms. 1 is lowest priority - 7 - is the highest. Regards, TsiChung On Thu, Mar 19, 2009 at 4:15 PM, Richard Retanubun richardretanu...@ruggedcom.com wrote: Richard Retanubun wrote: Hi TC, TC Liew wrote: Richard, Is there a purpose that you used DTIMER 3 but not 1 or 2? FYI: DTIMER3 is currently used for system time, DTIMER0 is currently used for udelay() in u-boot. You can change the u-boot 5271's system timer in include/asm-m68k/immap.h. #define CONFIG_SYS_TMR_BASE (MMAP_DTMR1) #define CONFIG_SYS_TMRINTR_NO (INT0_LO_DTMR1) #define CONFIG_SYS_TMRINTR_MASK (INTC_IPRL_INT20) Regards, TsiChung Hi TC, Sorry for the long-delay on this issue, I got tasked with other stuff, but thanks to your hint from the last e-mail, I think I might have found the root-cause to the problem. In include/asm-m68k/immap.h. #ifdef CONFIG_M5271 #include asm/immap_5271.h #include asm/m5271.h #define CONFIG_SYS_FEC0_IOBASE (MMAP_FEC) #define CONFIG_SYS_UART_BASE (MMAP_UART0 + (CONFIG_SYS_UART_PORT * 0x40)) /* Timer */ #ifdef CONFIG_MCFTMR #define CONFIG_SYS_UDELAY_BASE (MMAP_DTMR0) #define CONFIG_SYS_TMR_BASE (MMAP_DTMR3) #define CONFIG_SYS_TMRPND_REG (((volatile int0_t *)(CONFIG_SYS_INTR_BASE))-iprl0) #define CONFIG_SYS_TMRINTR_NO (INT0_LO_DTMR3) #define CONFIG_SYS_TMRINTR_MASK (INTC_IPRL_INT22) #define CONFIG_SYS_TMRINTR_PEND (CONFIG_SYS_TMRINTR_MASK) #define CONFIG_SYS_TMRINTR_PRI (0) /* Level must include inorder to work */ ^ #define CONFIG_SYS_TIMER_PRESCALER (((gd-bus_clk / 100) - 1) 8) #endif According to MCF5271 RefMan Rev 2 (07/2006) page 13-12, I think this means that the interrupt, although unmasked, have a level 0, priority 0, which essentially disables it. What should be the proper value? (0x09) will make it level 1, priority 1, is this ok? Or am I chasing the wrong rabbit? Thanks for your time - Richard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Coldfire M5271: Activate u-boot system timer interrupt.
From abd87852f80b84e77ab264acdb36e7814302b097 Mon Sep 17 00:00:00 2001 From: Richard Retanubun richardretanu...@ruggedcom.com Date: Thu, 26 Mar 2009 15:26:01 -0400 Subject: [PATCH] Coldfire M5271: Activate u-boot system timer interrupt. This patch assigns the u-boot system timer interrupt to interrupt level 3, priority 6. Without this patch the interrupt will be a level 0, priority 0, which disables it and cause u-boot functions that relies on the timer (e.g. sleep command) to never return. Signed-off-by: Richard Retanubun richardretanu...@ruggedcom.com --- include/asm-m68k/immap.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/asm-m68k/immap.h b/include/asm-m68k/immap.h index 93f730f..6a3ef03 100644 --- a/include/asm-m68k/immap.h +++ b/include/asm-m68k/immap.h @@ -149,7 +149,7 @@ #define CONFIG_SYS_TMRINTR_NO (INT0_LO_DTMR3) #define CONFIG_SYS_TMRINTR_MASK (INTC_IPRL_INT22) #define CONFIG_SYS_TMRINTR_PEND (CONFIG_SYS_TMRINTR_MASK) -#define CONFIG_SYS_TMRINTR_PRI (0) /* Level must include inorder to work */ +#define CONFIG_SYS_TMRINTR_PRI (0x1E) /* Interrupt level 3, priority 6 */ #define CONFIG_SYS_TIMER_PRESCALER(((gd-bus_clk / 100) - 1) 8) #endif -- 1.5.6.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Size of external u-boot commands
Dear Jon Smirl,
In message 9e4733910903260647w549a97acv7101ea9347a76...@mail.gmail.com you
wrote:
My networking hardware needs microcode loaded into it before it will
function. What's the best method to load this code? It's 70KB.
My current u-boot image is 170KB. I started working with the code in
examples and api_examples. But the hello world programs built using
those APIs are 65-72KB in size. That's almost half the size of my
u-boot image and these programs just print hello world. Why are
these programs so big? My goal was to put the loader program and my
microcode into a single 128KB erase block.
My code for loading the microcode into the hardware is 7KB. Now it
looks like I will need to incorporate it into the main u-boot image
instead of making it an external command.
I'm not sure how you calcualte sizes, or how you link your
applications. Note that classical standalone application do not link
against any libraries, so they are really small:
- size examples/{hello_world,timer}
textdata bss dec hex filename
796 40 0 836 344 examples/hello_world
1556 56 01612 64c examples/timer
As you can see, the hello world demo program just needs a few
hundret bytes.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
The computer can't tell you the emotional story. It can give you the
exact mathematical design, but what's missing is the eyebrows.
- Frank Zappa
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Size of external u-boot commands
On Thu, Mar 26, 2009 at 4:27 PM, Wolfgang Denk w...@denx.de wrote:
Dear Jon Smirl,
In message 9e4733910903260647w549a97acv7101ea9347a76...@mail.gmail.com you
wrote:
My networking hardware needs microcode loaded into it before it will
function. What's the best method to load this code? It's 70KB.
My current u-boot image is 170KB. I started working with the code in
examples and api_examples. But the hello world programs built using
those APIs are 65-72KB in size. That's almost half the size of my
u-boot image and these programs just print hello world. Why are
these programs so big? My goal was to put the loader program and my
microcode into a single 128KB erase block.
My code for loading the microcode into the hardware is 7KB. Now it
looks like I will need to incorporate it into the main u-boot image
instead of making it an external command.
I'm not sure how you calculate sizes, or how you link your
applications. Note that classical standalone application do not link
against any libraries, so they are really small:
The *.bin files are ending up at 60-75K. Adding this to the linker
script fixes it.
.gcc_except_table : ONLY_IF_RO { KEEP (*(.gcc_except_table))
*(.gcc_except_table.*) }
Approximately 60KB of zeros are getting inserted into the *.bin files.
Before:
jonsm...@terra:/home/apps/u-boot/examples$ ls *.bin -l
-rwxr-xr-x 1 jonsmirl jonsmirl 66424 2009-03-26 15:59 hello_world.bin
-rwxr-xr-x 1 jonsmirl jonsmirl 66460 2009-03-26 15:59 interrupt.bin
-rwxr-xr-x 1 jonsmirl jonsmirl 68464 2009-03-26 15:59 sched.bin
After the linker script change:
jonsm...@terra:/home/apps/u-boot/examples$ ls *.bin -l
-rwxr-xr-x 1 jonsmirl jonsmirl 4136 2009-03-26 16:49 hello_world.bin
-rwxr-xr-x 1 jonsmirl jonsmirl 4128 2009-03-26 16:49 interrupt.bin
-rwxr-xr-x 1 jonsmirl jonsmirl 4184 2009-03-26 16:49 sched.bin
jonsm...@terra:/home/apps/u-boot/examples$
- size examples/{hello_world,timer}
text data bss dec hex filename
796 40 0 836 344 examples/hello_world
1556 56 0 1612 64c examples/timer
As you can see, the hello world demo program just needs a few
hundret bytes.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
The computer can't tell you the emotional story. It can give you the
exact mathematical design, but what's missing is the eyebrows.
- Frank Zappa
--
Jon Smirl
jonsm...@gmail.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/3] MPC85xx: Load and enable QE microcode patch in IRAM
For the silicon which doesn't have ROM support in QE, it always needs to load
a pre-built ucode binary to IRAM so that QE can work.
Signed-off-by: Haiying Wang haiying.w...@freescale.com
Signed-off-by: Hillel Avni hillel.a...@freescale.com
---
drivers/qe/qe.c |9 +
drivers/qe/qe.h |1 +
2 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/drivers/qe/qe.c b/drivers/qe/qe.c
index e90a4a5..ea5a14b 100644
--- a/drivers/qe/qe.c
+++ b/drivers/qe/qe.c
@@ -161,6 +161,15 @@ void qe_init(uint qe_base)
/* Init the QE IMMR base */
qe_immr = (qe_map_t *)qe_base;
+#ifdef CONFIG_SYS_QE_FW_ADDR
+/* Upload microcode to IRAM for those SOCs which do not have ROM in QE.
+ */
+qe_upload_firmware((const struct qe_firmware *) CONFIG_SYS_QE_FW_ADDR);
+
+/* enable the microcode in IRAM */
+out_be32(qe_immr-iram.iready,QE_IRAM_READY);
+#endif
+
gd-mp_alloc_base = QE_DATAONLY_BASE;
gd-mp_alloc_top = gd-mp_alloc_base + QE_DATAONLY_SIZE;
diff --git a/drivers/qe/qe.h b/drivers/qe/qe.h
index a5f..d78edba 100644
--- a/drivers/qe/qe.h
+++ b/drivers/qe/qe.h
@@ -230,6 +230,7 @@ typedef enum qe_clock {
/* I-RAM */
#define QE_IRAM_IADD_AIE 0x8000 /* Auto Increment Enable */
#define QE_IRAM_IADD_BADDR 0x0008 /* Base Address */
+#define QE_IRAM_READY 0x8000
/* Structure that defines QE firmware binary files.
*
--
1.6.0.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3] MPC85xx: Add MPC8569 CPU support
There is a workaround for MPC8569 CPU Errata, which needs to set Bit 13 of LBCR
in 4K bootpage. We setup a temp TLB for eLBC controller in bootpage, then
invalidate it after LBCR bit 13 is set.
Signed-off-by: Haiying Wang haiying.w...@freescale.com
---
cpu/mpc85xx/Makefile |1 +
cpu/mpc85xx/cpu.c|2 +
cpu/mpc85xx/start.S | 47 ++
drivers/misc/fsl_law.c |2 +-
include/asm-ppc/immap_85xx.h |9 +++-
include/asm-ppc/immap_qe.h |8 --
include/asm-ppc/processor.h |2 +
7 files changed, 66 insertions(+), 5 deletions(-)
diff --git a/cpu/mpc85xx/Makefile b/cpu/mpc85xx/Makefile
index 99d88a8..8809302 100644
--- a/cpu/mpc85xx/Makefile
+++ b/cpu/mpc85xx/Makefile
@@ -49,6 +49,7 @@ COBJS-$(CONFIG_MPC8544) += ddr-gen2.o
COBJS-$(CONFIG_MPC8572) += ddr-gen3.o
COBJS-$(CONFIG_MPC8536) += ddr-gen3.o
COBJS-$(CONFIG_P2020) += ddr-gen3.o
+COBJS-$(CONFIG_MPC8569)+= ddr-gen3.o
COBJS-$(CONFIG_MPC8536) += mpc8536_serdes.o
COBJS = traps.o cpu.o cpu_init.o speed.o interrupts.o tlb.o \
diff --git a/cpu/mpc85xx/cpu.c b/cpu/mpc85xx/cpu.c
index 5b72fe5..ef976a4 100644
--- a/cpu/mpc85xx/cpu.c
+++ b/cpu/mpc85xx/cpu.c
@@ -61,6 +61,8 @@ struct cpu_type cpu_type_list [] = {
CPU_TYPE_ENTRY(8567, 8567_E),
CPU_TYPE_ENTRY(8568, 8568),
CPU_TYPE_ENTRY(8568, 8568_E),
+ CPU_TYPE_ENTRY(8569, 8569),
+ CPU_TYPE_ENTRY(8569, 8569_E),
CPU_TYPE_ENTRY(8572, 8572),
CPU_TYPE_ENTRY(8572, 8572_E),
CPU_TYPE_ENTRY(P2020, P2020),
diff --git a/cpu/mpc85xx/start.S b/cpu/mpc85xx/start.S
index 80f9677..d6e2d6a 100644
--- a/cpu/mpc85xx/start.S
+++ b/cpu/mpc85xx/start.S
@@ -184,6 +184,53 @@ _start_e500:
mtspr DBCR0,r0
#endif
+#ifdef CONFIG_MPC8569
+#define CONFIG_SYS_LBC_ADDR (CONFIG_SYS_CCSRBAR_DEFAULT + 0x5000)
+#define CONFIG_SYS_LBCR_ADDR (CONFIG_SYS_LBC_ADDR + 0xd0)
+
+ /* MPC8569 Rev.0 silcon needs to set bit 13 of LBCR to allow elBC to
+* use address space which is more than 12bits, and it must be done in
+* the 4K boot page. So we set this bit here.
+*/
+
+ /* create a temp mapping TLB0[0] for LBCR */
+ lis r6,FSL_BOOKE_MAS0(0, 0, 0)@h
+ ori r6,r6,FSL_BOOKE_MAS0(0, 0, 0)@l
+
+ lis r7,FSL_BOOKE_MAS1(1, 0, 0, 0, BOOKE_PAGESZ_4K)@h
+ ori r7,r7,FSL_BOOKE_MAS1(1, 0, 0, 0, BOOKE_PAGESZ_4K)@l
+
+ lis r8,FSL_BOOKE_MAS2(CONFIG_SYS_LBC_ADDR, MAS2_I|MAS2_G)@h
+ ori r8,r8,FSL_BOOKE_MAS2(CONFIG_SYS_LBC_ADDR, MAS2_I|MAS2_G)@l
+
+ lis r9,FSL_BOOKE_MAS3(CONFIG_SYS_LBC_ADDR, 0,
(MAS3_SX|MAS3_SW|MAS3_SR))@h
+ ori r9,r9,FSL_BOOKE_MAS3(CONFIG_SYS_LBC_ADDR, 0,
(MAS3_SX|MAS3_SW|MAS3_SR))@l
+
+ mtspr MAS0,r6
+ mtspr MAS1,r7
+ mtspr MAS2,r8
+ mtspr MAS3,r9
+ isync
+ msync
+ tlbwe
+
+ /* Set LBCR register */
+ lis r4,config_sys_lbcr_a...@h
+ ori r4,r4,config_sys_lbcr_a...@l
+
+ lis r5,config_sys_lbc_l...@h
+ ori r5,r5,config_sys_lbc_l...@l
+ stw r5,0(r4)
+ isync
+
+ /* invalidate this temp TLB */
+ lis r4,config_sys_lbc_a...@h
+ ori r4,r4,config_sys_lbc_a...@l
+ tlbivax 0,r4
+ isync
+
+#endif /* CONFIG_MPC8569 */
+
/* create a temp mapping in AS=1 to the 4M boot window */
lis r6,FSL_BOOKE_MAS0(1, 15, 0)@h
ori r6,r6,FSL_BOOKE_MAS0(1, 15, 0)@l
diff --git a/drivers/misc/fsl_law.c b/drivers/misc/fsl_law.c
index 58340c1..be43a3e 100644
--- a/drivers/misc/fsl_law.c
+++ b/drivers/misc/fsl_law.c
@@ -35,7 +35,7 @@ DECLARE_GLOBAL_DATA_PTR;
defined(CONFIG_MPC8560) || defined(CONFIG_MPC8555)
#define FSL_HW_NUM_LAWS 8
#elif defined(CONFIG_MPC8548) || defined(CONFIG_MPC8544) || \
- defined(CONFIG_MPC8568) || \
+ defined(CONFIG_MPC8568) || defined(CONFIG_MPC8569) || \
defined(CONFIG_MPC8641) || defined(CONFIG_MPC8610)
#define FSL_HW_NUM_LAWS 10
#elif defined(CONFIG_MPC8536) || defined(CONFIG_MPC8572) || \
diff --git a/include/asm-ppc/immap_85xx.h b/include/asm-ppc/immap_85xx.h
index 094fb9c..de78dda 100644
--- a/include/asm-ppc/immap_85xx.h
+++ b/include/asm-ppc/immap_85xx.h
@@ -1609,8 +1609,15 @@ typedef struct ccsr_gur {
charres2[12];
uintgpiocr; /* 0xe0030 - GPIO control register */
charres3[12];
+#if defined(CONFIG_MPC8569)
+ uintplppar1;/* 0xe0040 - Platform port pin assignment
register 1 */
+ uintplppar2;/* 0xe0044 - Platform port pin assignment
register 2 */
+ uintplpdir1;/* 0xe0048 - Platform port pin direction
register 1 */
+ uintplpdir2;/* 0xe004c - Platform port pin direction
register 2 */
+#else
uintgpoutdr;/* 0xe0040 - General-purpose output data
register */
charres4[12];
+#endif
uintgpindr; /*
[U-Boot] [PATCH 3/3] MPC85xx: Add MPC8569MDS board support
This patch adds MPC8569MDS board support. The UART, QE UEC1 and UEC2, BRD EEPROM on I2C2 bus, PCI express and DDR3 SPD are supported in this patch. Signed-off-by: Haiying Wang haiying.w...@freescale.com Signed-off-by: Hillel Avni hillel.a...@freescale.com --- MAKEALL |1 + Makefile|3 + board/freescale/mpc8569mds/Makefile | 55 board/freescale/mpc8569mds/bcsr.c | 49 board/freescale/mpc8569mds/bcsr.h | 82 ++ board/freescale/mpc8569mds/config.mk| 30 ++ board/freescale/mpc8569mds/ddr.c| 86 ++ board/freescale/mpc8569mds/law.c| 59 board/freescale/mpc8569mds/mpc8569mds.c | 325 ++ board/freescale/mpc8569mds/tlb.c| 100 +++ board/freescale/mpc8569mds/u-boot.lds | 143 ++ include/configs/MPC8569MDS.h| 455 +++ 12 files changed, 1388 insertions(+), 0 deletions(-) create mode 100644 board/freescale/mpc8569mds/Makefile create mode 100644 board/freescale/mpc8569mds/bcsr.c create mode 100644 board/freescale/mpc8569mds/bcsr.h create mode 100644 board/freescale/mpc8569mds/config.mk create mode 100644 board/freescale/mpc8569mds/ddr.c create mode 100644 board/freescale/mpc8569mds/law.c create mode 100644 board/freescale/mpc8569mds/mpc8569mds.c create mode 100644 board/freescale/mpc8569mds/tlb.c create mode 100644 board/freescale/mpc8569mds/u-boot.lds create mode 100644 include/configs/MPC8569MDS.h diff --git a/MAKEALL b/MAKEALL index ed9e5ed..7b12d90 100755 --- a/MAKEALL +++ b/MAKEALL @@ -375,6 +375,7 @@ LIST_85xx= \ MPC8555CDS \ MPC8560ADS \ MPC8568MDS \ + MPC8569MDS \ MPC8572DS \ MPC8572DS_36BIT \ PM854 \ diff --git a/Makefile b/Makefile index 61bae6d..16f5c4e 100644 --- a/Makefile +++ b/Makefile @@ -2422,6 +2422,9 @@ MPC8555CDS_config:unconfig MPC8568MDS_config: unconfig @$(MKCONFIG) $(@:_config=) ppc mpc85xx mpc8568mds freescale +MPC8569MDS_config: unconfig + @$(MKCONFIG) $(@:_config=) ppc mpc85xx mpc8569mds freescale + MPC8572DS_36BIT_config \ MPC8572DS_config: unconfig @mkdir -p $(obj)include diff --git a/board/freescale/mpc8569mds/Makefile b/board/freescale/mpc8569mds/Makefile new file mode 100644 index 000..23805ea --- /dev/null +++ b/board/freescale/mpc8569mds/Makefile @@ -0,0 +1,55 @@ +# +# Copyright 2004-2009 Freescale Semiconductor. +# (C) Copyright 2001-2006 +# Wolfgang Denk, DENX Software Engineering, w...@denx.de. +# +# See file CREDITS for list of people who contributed to this +# project. +# +# This program is free software; you can redistribute it and/or +# modify it under the terms of the GNU General Public License as +# published by the Free Software Foundation; either version 2 of +# the License, or (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 59 Temple Place, Suite 330, Boston, +# MA 02111-1307 USA +# + +include $(TOPDIR)/config.mk + +LIB= $(obj)lib$(BOARD).a + +COBJS-y+= $(BOARD).o +COBJS-y+= bcsr.o +COBJS-y+= ddr.o +COBJS-y+= law.o +COBJS-y+= tlb.o + +SRCS := $(SOBJS-y:.o=.S) $(COBJS-y:.o=.c) +OBJS := $(addprefix $(obj),$(COBJS-y)) +SOBJS := $(addprefix $(obj),$(SOBJS-y)) + +$(LIB):$(obj).depend $(OBJS) $(SOBJS) + $(AR) $(ARFLAGS) $@ $(OBJS) + +clean: + rm -f $(OBJS) $(SOBJS) + +distclean: clean + rm -f $(LIB) core *.bak $(obj).depend + +# + +# defines $(obj).depend target +include $(SRCTREE)/rules.mk + +sinclude $(obj).depend + +# diff --git a/board/freescale/mpc8569mds/bcsr.c b/board/freescale/mpc8569mds/bcsr.c new file mode 100644 index 000..5adffc2 --- /dev/null +++ b/board/freescale/mpc8569mds/bcsr.c @@ -0,0 +1,49 @@ +/* + * Copyright (C) 2009 Freescale Semiconductor, Inc. All rights reserved. + * + * See file CREDITS for list of people who contributed to this + * project. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of + * the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or
Re: [U-Boot] Size of external u-boot commands
Dear Jon Smirl,
In message 9e4733910903261350v21bf16c5l5729927048e0d...@mail.gmail.com you
wrote:
I'm not sure how you calculate sizes, or how you link your
applications. Note that classical standalone application do not link
against any libraries, so they are really small:
The *.bin files are ending up at 60-75K. Adding this to the linker
Yes, but that's mostly empty space, due to the alignment requirments
in the linker script.
script fixes it.
.gcc_except_table : ONLY_IF_RO { KEEP (*(.gcc_except_table))
*(.gcc_except_table.*) }
Approximately 60KB of zeros are getting inserted into the *.bin files.
But this is just a gap, it e. it is not used space; if you have
bigger program code, or if you change your alignment requirements, you
will see different (much smaller) values.
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
If a packet hits a pocket on a socket on a port,
And the bus is interrupted as a very last resort,
And the address of the memory makes your floppy disk abort,
Then the socket packet pocket has an error to report! - Ken Burchill?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] AT91 Pull Request
Dear Jean-Christophe PLAGNIOL-VILLARD, In message 20090325213454.gb18...@game.jcrosoft.org you wrote: Hi Wolfgang, Please pull The following changes since commit ee1702d75a30d076139d1841383a1fa7220a0e11: Wolfgang Denk (1): Merge branch 'next' of ../next are available in the git repository at: git://git.denx.de/u-boot-at91.git master Jean-Christophe PLAGNIOL-VILLARD (10): at91sam9/at91cap: move common serial initialisation to cpu at91sam9/at91cap: move common spi initialisation to cpu at91sam9/at91cap: move common led management to cpu at91sam9/at91cap: move common usb host initialisation to cpu at91sam9/at91cap: move common macb initialisation to cpu atmel/at91/boards: compile dataflash partition only when dataflash is at91sam9/at91cap: move nand drivers to drivers/mtd/nand at91sam9xeek: fix soc name cmc_pu2: fix misc_init_r prototype cmc_pu2: fix implicit declaration of function 'eth_setenv_enetaddr' Nicolas Ferre (1): at91: Support for the at91sam9g20 : Atmel 400Mhz ARM 926ej-s SOC. MAKEALL|1 + Makefile | 16 +++- board/afeb9260/Makefile|1 - board/afeb9260/afeb9260.c | 72 ++--- board/atmel/at91cap9adk/Makefile |3 +- board/atmel/at91cap9adk/at91cap9adk.c | 71 ++-- board/atmel/at91cap9adk/led.c | 46 ++- board/atmel/at91cap9adk/nand.c | 72 board/atmel/at91sam9260ek/Makefile |3 +- board/atmel/at91sam9260ek/at91sam9260ek.c | 88 +++- board/atmel/at91sam9260ek/led.c| 31 +-- board/atmel/at91sam9260ek/nand.c | 78 - board/atmel/at91sam9261ek/Makefile |3 +- board/atmel/at91sam9261ek/at91sam9261ek.c | 50 +-- board/atmel/at91sam9261ek/led.c| 47 ++- board/atmel/at91sam9261ek/nand.c | 78 - board/atmel/at91sam9263ek/Makefile |3 +- board/atmel/at91sam9263ek/at91sam9263ek.c | 85 ++- board/atmel/at91sam9263ek/led.c| 46 ++- board/atmel/at91sam9263ek/nand.c | 78 - board/atmel/at91sam9rlek/Makefile |3 +- board/atmel/at91sam9rlek/at91sam9rlek.c| 50 +-- board/atmel/at91sam9rlek/led.c | 46 ++- board/atmel/at91sam9rlek/nand.c| 78 - board/cmc_pu2/load_sernum_ethaddr.c|9 ++- cpu/arm926ejs/at91/Makefile| 32 +++- cpu/arm926ejs/at91/at91cap9_macb.c | 54 cpu/arm926ejs/at91/at91cap9_serial.c | 76 + cpu/arm926ejs/at91/at91cap9_spi.c | 75 + cpu/arm926ejs/at91/at91sam9260_macb.c | 63 ++ cpu/arm926ejs/at91/at91sam9260_serial.c| 76 + cpu/arm926ejs/at91/at91sam9260_spi.c | 75 + cpu/arm926ejs/at91/at91sam9261_serial.c| 76 + cpu/arm926ejs/at91/at91sam9261_spi.c | 75 + cpu/arm926ejs/at91/at91sam9263_macb.c | 54 cpu/arm926ejs/at91/at91sam9263_serial.c| 76 + cpu/arm926ejs/at91/at91sam9263_spi.c | 75 + cpu/arm926ejs/at91/at91sam9263_usb.c | 35 cpu/arm926ejs/at91/at91sam9rl_serial.c | 76 + cpu/arm926ejs/at91/at91sam9rl_spi.c| 52 cpu/arm926ejs/at91/led.c | 64 ++ cpu/arm926ejs/at91/usb.c |4 +- doc/README.at91|2 +- drivers/mtd/nand/Makefile |1 + .../nand.c = drivers/mtd/nand/atmel_nand.c| 32 drivers/net/macb.c |4 +- include/asm-arm/arch-at91/at91_common.h| 38 + include/asm-arm/arch-at91/hardware.h |2 +- include/configs/afeb9260.h |9 ++ include/configs/at91cap9adk.h | 14 +++ include/configs/at91sam9260ek.h| 37 +++- include/configs/at91sam9261ek.h| 15 include/configs/at91sam9263ek.h| 15 include/configs/at91sam9rlek.h | 15 54 files changed, 1288 insertions(+), 992 deletions(-)
Re: [U-Boot] Please pull u-boot-ppc4xx
Dear Stefan Roese, In message 200903261839.54706...@denx.de you wrote: The following changes since commit 33e88c557b29c84c52039ba05993fa70fe62afe3: Jon Smirl (1): mpc5200: suppress printf until console initialized are available in the git repository at: git://www.denx.de/git/u-boot-ppc4xx.git master Stefan Roese (1): ppc4xx: Sequoia: Fix TLB reassignment in NAND booting code board/amcc/sequoia/init.S |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) Applied, thanks. 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 News is what a chap who doesn't care much about anything wants to read. And it's only news until he's read it. After that it's dead. - Evelyn Waugh _Scoop_ (1938) bk. 1, ch. 5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Size of external u-boot commands
On Thu, Mar 26, 2009 at 5:15 PM, Wolfgang Denk w...@denx.de wrote:
Dear Jon Smirl,
In message 9e4733910903261350v21bf16c5l5729927048e0d...@mail.gmail.com you
wrote:
I'm not sure how you calculate sizes, or how you link your
applications. Note that classical standalone application do not link
against any libraries, so they are really small:
The *.bin files are ending up at 60-75K. Adding this to the linker
Yes, but that's mostly empty space, due to the alignment requirments
in the linker script.
script fixes it.
.gcc_except_table : ONLY_IF_RO { KEEP (*(.gcc_except_table))
*(.gcc_except_table.*) }
Approximately 60KB of zeros are getting inserted into the *.bin files.
But this is just a gap, it e. it is not used space; if you have
bigger program code, or if you change your alignment requirements, you
will see different (much smaller) values.
I'm on powerpc.
The *.bin format is not smart enough to encode gaps. It just puts in
60KB of zeros.
My ELF files are 73KB.
-rwxr-xr-x 1 jonsmirl jonsmirl 73290 2009-03-26 16:49 hello_world
Tell me the right way to make these example programs small and I'll
submit a patch.
--
Jon Smirl
jonsm...@gmail.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] 83xx: Use common LSDMR defines from asm/fsl_lbc.h
On Thu, 26 Mar 2009 01:34:39 -0500 Kumar Gala ga...@kernel.crashing.org wrote: Signed-off-by: Kumar Gala ga...@kernel.crashing.org --- include/configs/MPC8323ERDB.h | 26 - include/configs/MPC832XEMDS.h | 26 - include/configs/MPC8349EMDS.h | 62 include/configs/MPC8360EMDS.h | 27 +++-- include/configs/sbc8349.h | 62 5 files changed, 31 insertions(+), 172 deletions(-) ack. to go through Andy, I presume. Thanks, Kim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] drivers/net/tsec.c - mii_parse_sr does not wait for auto-negotiation completion bug fix
Hi Peter,
On Thu, Mar 26, 2009 at 6:26 PM, Peter Tyser pty...@xes-inc.com wrote:
Hi Michael,
Hi Peter,
Thanks for the reference. I found this thread very interesting.
Before I submitted the patch I also wondered if it is possible for
the link status to be OK while auto-negotiation has not been completed
yet.
So I dived into the IEEE-802.3 spec (Clause 28) and figured out that
according to the Arbitration state diagram (Figure 28-16) the
auto-negotiation
completed indication is asserted after the link status became OK.
It contradicts with Marvell’s 88E phy behavior on my mpc8349 based
board
where link status OK (register 1.2) always comes at least with 1 tbclk
delay
after auto-negotiation completion indication (register 1.5).
It probably explains why the delay of 500 ms “results in faster booting”
as stated in the code - without this delay the CPU leaves the routine
with
MIIM_STATUS_LINK still being in the down state.
By replacing the PHY_BMSR_AUTN_CMP with MIIM_STATUS_LINK in loop exiting
condition we eliminate the 500 ms delay.
The spec also specifies auto-negotiation timeout in table 28-9.
Its worst case value can be calculated as:
break_link_timer + autoneg_wait_timer + link_fai_inhibit_timer =
1500 ms + 1000 ms + 1000 ms = 3500 ms.
Thanks for the info. Any chance there's a public link to the IEEE spec
you're referencing? I've looked for the info you provided relatively
hard, it'd be great to finally lay my eyes on something concrete:)
Sure, you can download it from http://standards.ieee.org/getieee802/802.3.html
All auto-negotiation stuff is located in the IEEE 802.3-2005 -- Section Two
So I reduced the PHY_AUTONEGOTIATE_TIMEOUT to be 4000 ms.
Here is the updated patch
Signed-off-by: Michael Zaidman michael.zaid...@gmail.com
---
diff --git a/drivers/net/tsec.c b/drivers/net/tsec.c
index 399116f..28e9cc7 100644
--- a/drivers/net/tsec.c
+++ b/drivers/net/tsec.c
@@ -363,12 +363,12 @@ uint mii_parse_sr(uint mii_reg, struct
tsec_private * priv)
* (ie - we're capable and it's not done)
*/
mii_reg = read_phy_reg(priv, MIIM_STATUS);
- if ((mii_reg MIIM_STATUS_LINK) (mii_reg PHY_BMSR_AUTN_ABLE)
+ if (!(mii_reg MIIM_STATUS_LINK) (mii_reg PHY_BMSR_AUTN_ABLE)
!(mii_reg PHY_BMSR_AUTN_COMP)) {
int i = 0;
puts(Waiting for PHY auto negotiation to complete);
- while (!(mii_reg PHY_BMSR_AUTN_COMP)) {
+ while (!(mii_reg MIIM_STATUS_LINK)) {
Won't this be a problem for PHYs which do adhere to the spec you
mentioned above? If a PHY has achieved link, but auto-negotiation
hasn't completed, we'll return from this function with auto-negotiation
still not complete, which doesn't seem right.
I am not sure if this is the possible situation.
As I understand the auto-negotiation process is prerequisite for the
link state assignment.
And generally both indications should come closely coupled. Probably I
miss-interpreted
the link_status primitive in the state diagram. It gets three values -
FAIL, READY and OK,
whereas the Link status bit in the Status register (1.2) gets UP and
Down. And timing
relationships between them are unclear. (See Figure 24–15 Link Monitor
state diagram)
According to the spec, we
shouldn't leave this loop until auto-negotiation is done.
We are interesting in the link status. This is what the routine returns.
The link status UP indicates that a valid link is established and reliable
reception of signals transmitted from the remote PHY is possible.
It sounds like the reason that my original patch doesn't work for you is
due to the fact that the 88e PHY doesn't adhere to the spec as far
as the ordering of link up and auto-negotation complete?
I assume it would work also. I just did not try it because I was not
aware about it. :-)
If that's the case, perhaps we should either wait for both link up and
auto-negotiation to complete, or the 88e (or Marvel PHYs in general)
should have its own mii_parse_sr()?
It will be interesting to know an assertion order of link up and
auto-negotiation
to complete for another PHY.
/*
* Timeout reached ?
*/
@@ -386,7 +386,6 @@ uint mii_parse_sr(uint mii_reg, struct tsec_private *
priv)
}
puts( done\n);
priv-link = 1;
- udelay(50); /* another 500 ms (results in faster
booting) */
Agreed that it would be great to get rid of this magic delay.
} else {
if (mii_reg MIIM_STATUS_LINK)
priv-link = 1;
diff --git a/include/tsec.h b/include/tsec.h
index 7b52e06..ed4c855 100644
--- a/include/tsec.h
+++ b/include/tsec.h
@@ -56,7 +56,7 @@
#define TSEC_TIMEOUT 1000
#define TOUT_LOOP
Re: [U-Boot] [PATCH] omap3: mmc: mmc2 support
Minkyu Kang wrote:
There are 3 MMC/SD/SDIO host controllers inside the device.
This patch will support mmc2 and mmc3.
By this patch, the MMC controller actually used is configured by
CONFIG_MMC_INDEX at compile time? I.e. setting CONFIG_MMC_INDEX to 1
will use mmc1, 2 will switch to mmc2 and CONFIG_MMC_INDEX 3 will
switch to mmc3?
If I got this right, do you think we can do this at runtime? E.g.
implementing a custom command
select_mmc # of mmc controller to be used
?
With this, we could switch to mmc2 by doing something like
select_mmc 2
and afterwards all mmc read/write access will go to mmc2.
What do you think?
Looking at MMC commands, there is also a device num option available
for mmc commands, e.g.
mmc read device num
Not sure if this could help us here.
Maybe the MMC experts can advice how to do this the best way?
Best regards
Dirk
Signed-off-by: Minkyu Kang mk7.k...@samsung.com
---
drivers/mmc/omap3_mmc.c | 38
++---
include/asm-arm/arch-omap3/mmc_host_def.h | 18 -
include/asm-arm/arch-omap3/omap3.h|3 ++
include/configs/omap3_beagle.h|1 +
include/configs/omap3_evm.h |1 +
include/configs/omap3_overo.h |1 +
include/configs/omap3_pandora.h |1 +
include/configs/omap3_zoom1.h |1 +
8 files changed, 53 insertions(+), 11 deletions(-)
diff --git a/drivers/mmc/omap3_mmc.c b/drivers/mmc/omap3_mmc.c
index e90db7e..edc56fa 100644
--- a/drivers/mmc/omap3_mmc.c
+++ b/drivers/mmc/omap3_mmc.c
@@ -62,10 +62,21 @@ void twl4030_mmc_config(void)
{
unsigned char data;
- data = DEV_GRP_P1;
- i2c_write(PWRMGT_ADDR_ID4, VMMC1_DEV_GRP, 1, data, 1);
- data = VMMC1_VSEL_30;
- i2c_write(PWRMGT_ADDR_ID4, VMMC1_DEDICATED, 1, data, 1);
+ switch (CONFIG_MMC_INDEX) {
+ case 1:
+ data = DEV_GRP_P1;
+ i2c_write(PWRMGT_ADDR_ID4, VMMC1_DEV_GRP, 1, data, 1);
+ data = VMMC1_VSEL_30;
+ i2c_write(PWRMGT_ADDR_ID4, VMMC1_DEDICATED, 1, data, 1);
+ break;
+ case 2:
+ case 3:
+ data = DEV_GRP_P1;
+ i2c_write(PWRMGT_ADDR_ID4, VMMC2_DEV_GRP, 1, data, 1);
+ data = VMMC2_VSEL_185;
+ i2c_write(PWRMGT_ADDR_ID4, VMMC2_DEDICATED, 1, data, 1);
+ break;
+ }
}
unsigned char mmc_board_init(void)
@@ -74,12 +85,21 @@ unsigned char mmc_board_init(void)
twl4030_mmc_config();
- writel(readl(t2_base-pbias_lite) | PBIASLITEPWRDNZ1 |
- PBIASSPEEDCTRL0 | PBIASLITEPWRDNZ0,
- t2_base-pbias_lite);
+ switch (CONFIG_MMC_INDEX) {
+ case 1:
+ writel(readl(t2_base-pbias_lite) | PBIASLITEPWRDNZ1 |
+ PBIASSPEEDCTRL0 | PBIASLITEPWRDNZ0,
+ t2_base-pbias_lite);
- writel(readl(t2_base-devconf0) | MMCSDIO1ADPCLKISEL,
- t2_base-devconf0);
+ writel(readl(t2_base-devconf0) | MMCSDIO1ADPCLKISEL,
+ t2_base-devconf0);
+ break;
+ case 2:
+ case 3:
+ writel(readl(t2_base-devconf1) | MMCSDIO2ADPCLKISEL,
+ t2_base-devconf1);
+ break;
+ }
return 1;
}
diff --git a/include/asm-arm/arch-omap3/mmc_host_def.h
b/include/asm-arm/arch-omap3/mmc_host_def.h
index aa751c9..01884f9 100644
--- a/include/asm-arm/arch-omap3/mmc_host_def.h
+++ b/include/asm-arm/arch-omap3/mmc_host_def.h
@@ -31,7 +31,9 @@
typedef struct t2 {
unsigned char res1[0x274];
unsigned int devconf0; /* 0x274 */
- unsigned char res2[0x2A8];
+ unsigned char res2[0x60];
+ unsigned int devconf1; /* 0x2D8 */
+ unsigned char res3[0x244];
unsigned int pbias_lite;/* 0x520 */
} t2_t;
@@ -41,10 +43,22 @@ typedef struct t2 {
#define PBIASSPEEDCTRL0 (1 2)
#define PBIASLITEPWRDNZ1 (1 9)
+#define MMCSDIO2ADPCLKISEL (1 6)
+
/*
* OMAP HSMMC register definitions
*/
-#define OMAP_HSMMC_BASE 0x4809C000
+#define OMAP_HSMMC_BASE_MMC1 0x4809C000
+#define OMAP_HSMMC_BASE_MMC2 0x480B4000
+#define OMAP_HSMMC_BASE_MMC3 0x480AD000
+
+#if CONFIG_MMC_INDEX == 1
+#define OMAP_HSMMC_BASE OMAP_HSMMC_BASE_MMC1
+#elif CONFIG_MMC_INDEX == 2
+#define OMAP_HSMMC_BASE OMAP_HSMMC_BASE_MMC2
+#elif CONFIG_MMC_INDEX == 3
+#define OMAP_HSMMC_BASE OMAP_HSMMC_BASE_MMC3
+#endif
typedef struct hsmmc {
unsigned char res1[0x10];
diff --git a/include/asm-arm/arch-omap3/omap3.h
b/include/asm-arm/arch-omap3/omap3.h
index 8c9656f..b5b5def 100644
--- a/include/asm-arm/arch-omap3/omap3.h
+++ b/include/asm-arm/arch-omap3/omap3.h
@@ -206,6 +206,8 @@ typedef struct gpio {
#define VAUX3_DEDICATED
Re: [U-Boot] omap3: write to mmc
Minkyu Kang wrote: Hi, I have question or request about omap3 mmc. I want to write the image to mmc. But, omap3_mmc has no function for it. You want to say that OMAP3 MMC driver lacks MMC write support? Yes, looks so ;) Do you have some patches for omap3_mmc? or.. How about implementation generic mmc for omap3? If nobody has a patch for OMAP3 MMC, do you like to help to improve it? Many thanks Dirk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Size of external u-boot commands
Dear Jon Smirl, In message 9e4733910903261435x598055f8m74c5ac03ad16b...@mail.gmail.com you wrote: The *.bin format is not smart enough to encode gaps. It just puts in 60KB of zeros. Yes, of course. A binary image cannot have holes in it. My ELF files are 73KB. -rwxr-xr-x 1 jonsmirl jonsmirl 73290 2009-03-26 16:49 hello_world Tell me the right way to make these example programs small and I'll submit a patch. I don't see a problem that needs fixing. These are example problems. The image size plays no role. If you have any specific requirements for your own code, then adjust the linker script according to your requirements. 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 Where there's no emotion, there's no motive for violence. -- Spock, Dagger of the Mind, stardate 2715.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Size of external u-boot commands
On Thu, Mar 26, 2009 at 7:26 PM, Wolfgang Denk w...@denx.de wrote: Dear Jon Smirl, In message 9e4733910903261435x598055f8m74c5ac03ad16b...@mail.gmail.com you wrote: The *.bin format is not smart enough to encode gaps. It just puts in 60KB of zeros. Yes, of course. A binary image cannot have holes in it. My ELF files are 73KB. -rwxr-xr-x 1 jonsmirl jonsmirl 73290 2009-03-26 16:49 hello_world Tell me the right way to make these example programs small and I'll submit a patch. I don't see a problem that needs fixing. These are example problems. The image size plays no role. If you have any specific requirements for your own code, then adjust the linker script according to your requirements. By providing a sample linker script to make the example programs smaller, you could avoid discussions like this in the future. -- Jon Smirl jonsm...@gmail.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
