Re: [U-Boot] [PATCH] OMAP3 Remove unneeded boot_flash_* declarations
Hi Tom, Tom Rix wrote: Only the boot_flash_* variables that are used by #defines in the OMAP3 config files should have declarations. This patch removes the unneeded declarations. Not all of the boot_flash_* declarations are needed by all of the boards. The set for each board was minimized by keeping the declaration of variable used is part of a #define in the config file. After closer inspection it seems that board_flash_* variables can be removed completely. What do you think about this: [PATCH] OMAP3 Remove unneeded boot_flash_* variables The boot_flash_* variables can be completely replaced by static definitions and therefore are not needed. Signed-off-by: Mike Rapoport m...@compulab.co.il --- cpu/arm_cortexa8/omap3/mem.c| 27 --- include/configs/devkit8000.h| 10 +- include/configs/omap3_beagle.h | 12 ++-- include/configs/omap3_evm.h | 16 include/configs/omap3_overo.h | 14 +++--- include/configs/omap3_pandora.h | 14 +++--- include/configs/omap3_sdp3430.h | 10 -- include/configs/omap3_zoom1.h | 14 +++--- include/configs/omap3_zoom2.h | 14 +++--- 9 files changed, 19 insertions(+), 112 deletions(-) diff --git a/cpu/arm_cortexa8/omap3/mem.c b/cpu/arm_cortexa8/omap3/mem.c index dfb7e4c..bf36c96 100644 --- a/cpu/arm_cortexa8/omap3/mem.c +++ b/cpu/arm_cortexa8/omap3/mem.c @@ -35,11 +35,6 @@ * Only One NAND allowed on board at a time. * The GPMC CS Base for the same */ -unsigned int boot_flash_base; -unsigned int boot_flash_off; -unsigned int boot_flash_sec; -unsigned int boot_flash_type; -volatile unsigned int boot_flash_env_addr; struct gpmc *gpmc_cfg; @@ -224,10 +219,6 @@ void gpmc_init(void) const u32 *gpmc_config = NULL; u32 base = 0; u32 size = 0; -#if defined(CONFIG_ENV_IS_IN_NAND) || defined(CONFIG_ENV_IS_IN_ONENAND) - u32 f_off = CONFIG_SYS_MONITOR_LEN; - u32 f_sec = 0; -#endif #endif u32 config = 0; @@ -252,15 +243,6 @@ void gpmc_init(void) base = PISMO1_NAND_BASE; size = PISMO1_NAND_SIZE; enable_gpmc_cs_config(gpmc_config, gpmc_cfg-cs[0], base, size); -#if defined(CONFIG_ENV_IS_IN_NAND) - f_off = SMNAND_ENV_OFFSET; - f_sec = (128 10);/* 128 KiB */ - /* env setup */ - boot_flash_base = base; - boot_flash_off = f_off; - boot_flash_sec = f_sec; - boot_flash_env_addr = f_off; -#endif #endif #if defined(CONFIG_CMD_ONENAND) @@ -268,14 +250,5 @@ void gpmc_init(void) base = PISMO1_ONEN_BASE; size = PISMO1_ONEN_SIZE; enable_gpmc_cs_config(gpmc_config, gpmc_cfg-cs[0], base, size); -#if defined(CONFIG_ENV_IS_IN_ONENAND) - f_off = ONENAND_ENV_OFFSET; - f_sec = (128 10);/* 128 KiB */ - /* env setup */ - boot_flash_base = base; - boot_flash_off = f_off; - boot_flash_sec = f_sec; - boot_flash_env_addr = f_off; -#endif #endif } diff --git a/include/configs/devkit8000.h b/include/configs/devkit8000.h index 7487bb7..66cb00a 100644 --- a/include/configs/devkit8000.h +++ b/include/configs/devkit8000.h @@ -296,14 +296,6 @@ #define CONFIG_ENV_IS_IN_NAND 1 #define SMNAND_ENV_OFFSET 0x26 /* environment starts here */ -#define CONFIG_ENV_OFFSET boot_flash_off - -#ifndef __ASSEMBLY__ -extern unsigned int boot_flash_base; -extern volatile unsigned int boot_flash_env_addr; -extern unsigned int boot_flash_off; -extern unsigned int boot_flash_sec; -extern unsigned int boot_flash_type; -#endif +#define CONFIG_ENV_OFFSET SMNAND_ENV_OFFSET #endif /* __CONFIG_H */ diff --git a/include/configs/omap3_beagle.h b/include/configs/omap3_beagle.h index 70186ce..dc18ad2 100644 --- a/include/configs/omap3_beagle.h +++ b/include/configs/omap3_beagle.h @@ -294,8 +294,8 @@ #define ONENAND_ENV_OFFSET 0x26 /* environment starts here */ #define SMNAND_ENV_OFFSET 0x26 /* environment starts here */ -#define CONFIG_SYS_ENV_SECT_SIZE boot_flash_sec -#define CONFIG_ENV_OFFSET boot_flash_off +#define CONFIG_SYS_ENV_SECT_SIZE (1 128) +#define CONFIG_ENV_OFFSET SMNAND_ENV_OFFSET #define CONFIG_ENV_ADDRSMNAND_ENV_OFFSET /*--- @@ -313,12 +313,4 @@ #define CONFIG_SYS_JFFS2_FIRST_BANKCONFIG_SYS_MAX_FLASH_BANKS #define CONFIG_SYS_JFFS2_NUM_BANKS 1 -#ifndef __ASSEMBLY__ -extern unsigned int boot_flash_base; -extern volatile unsigned int boot_flash_env_addr; -extern unsigned int boot_flash_off; -extern unsigned int boot_flash_sec; -extern unsigned int boot_flash_type; -#endif - #endif /* __CONFIG_H */ diff --git a/include/configs/omap3_evm.h b/include/configs/omap3_evm.h index 162bfea..37e4ee8 100644 --- a/include/configs/omap3_evm.h +++ b/include/configs/omap3_evm.h @@
Re: [U-Boot] [PATCH] fix flash_sect_erase() to display correct message
Hi Wolfgang, On Tuesday 17 November 2009 22:22:23 Wolfgang Denk wrote: flash_sect_erase() displays message Erased #N sectors even when there are some protected sectors found and command erase fail. Applied to u-boot-cfi-flash/master. Thanks. Sory, but you were too fast for me. Please put this commit on hold. Yes, removed from master again. Cheers, Stefan -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: off...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] why is the compilation of cmd_pcmcia.c hardcoded?
i'm curious as to why common/Makefile hardcodes the compilation of
cmd_pcmcia.c thusly:
COBJS-y += cmd_pcmcia.o
since i'm interested in building for a beagleboard, i have no interest
in PCMCIA support, yet that source file will be compiled for me, even
though the selection macro CONFIG_CMD_PCMCIA does exist and is defined
by a number of other board configurations.
what seems stranger is that, even though that config macro exists,
it isn't used in the Makefile but *is* tested in the source file
itself to determine whether the pinit command will be compiled:
=
#if defined(CONFIG_CMD_PCMCIA)
extern int pcmcia_on (void);
extern int pcmcia_off (void);
int do_pinit (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
{
...
}
U_BOOT_CMD(
pinit, 2, 0, do_pinit,
PCMCIA sub-system,
on - power on PCMCIA socket\n
pinit off - power off PCMCIA socket
);
#endif
=
so the pinit command *won't* be compiled into my image, but the
remainder of that file will still be compiled. if the rest of that
file truly needs to be built for every board, would it not make more
sense to break the pinit code into a separate file, and have the
Makefile look something like:
ifdef CONFIG_CMD_PCMCIA
COBJS-$(CONFIG_CMD_PCMCIA) += cmd_pcmcia.o
endif
or is there something else happening there that i'm missing?
rday
p.s. based on the obvious naming convention of those files, i would
have imagined a file by the name of cmd_pinit.c.
--
Robert P. J. Day Waterloo, Ontario, CANADA
Linux Consulting, Training and Kernel Pedantry.
Web page: http://crashcourse.ca
Twitter: http://twitter.com/rpjday
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/1 v2] ARM Add New Board GEC2410
This patch add a S3C2410-based ARM study platform GEC2410 support. Signed-off-by: Hui.Tang zetal...@gmail.com --- total: 0 errors, 0 warnings, 1302 lines checked 0001-ARM-Add-New-Board-GEC2410.patch has no obvious style problems and is ready for submission. MAINTAINERS |4 + MAKEALL |1 + Makefile |3 + board/gec/gec2410/Makefile| 54 ++ board/gec/gec2410/README | 85 + board/gec/gec2410/config.mk | 32 board/gec/gec2410/gec2410.c | 306 + board/gec/gec2410/gec2410_mem.h | 118 + board/gec/gec2410/lowlevel_init.S | 93 ++ board/gec/gec2410/u-boot.lds | 61 +++ cpu/arm920t/s3c24x0/timer.c |6 +- cpu/arm920t/start.S | 19 ++ include/configs/gec2410.h | 249 +++ nand_spl/board/gec/gec2410/Makefile | 105 +++ nand_spl/board/gec/gec2410/config.mk | 32 nand_spl/board/gec/gec2410/u-boot.lds | 60 +++ 16 files changed, 1225 insertions(+), 3 deletions(-) create mode 100644 board/gec/gec2410/Makefile create mode 100644 board/gec/gec2410/README create mode 100644 board/gec/gec2410/config.mk create mode 100644 board/gec/gec2410/gec2410.c create mode 100644 board/gec/gec2410/gec2410_mem.h create mode 100644 board/gec/gec2410/lowlevel_init.S create mode 100644 board/gec/gec2410/u-boot.lds create mode 100644 include/configs/gec2410.h create mode 100644 nand_spl/board/gec/gec2410/Makefile create mode 100644 nand_spl/board/gec/gec2410/config.mk create mode 100644 nand_spl/board/gec/gec2410/u-boot.lds diff --git a/MAINTAINERS b/MAINTAINERS index d70a9d2..6ecba41 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -429,6 +429,10 @@ Timur Tabi ti...@freescale.com MPC8349E-mITX MPC8349 MPC8349E-mITX-GP MPC8349 +Hui Tang zetal...@gmail.com + + gec2410 ARM920T + Erik Theisen ethei...@mindspring.com W7OLMC PPC4xx diff --git a/MAKEALL b/MAKEALL index d63c5c2..fffa58a 100755 --- a/MAKEALL +++ b/MAKEALL @@ -548,6 +548,7 @@ LIST_ARM9= \ cp926ejs\ cp946es \ cp966 \ + gec2410 \ imx27lite \ lpd7a400\ mv88f6281gtw_ge \ diff --git a/Makefile b/Makefile index bcb3fe9..9979974 100644 --- a/Makefile +++ b/Makefile @@ -2951,6 +2951,9 @@ davinci_dm365evm_config : unconfig davinci_dm6467evm_config : unconfig @$(MKCONFIG) $(@:_config=) arm arm926ejs dm6467evm davinci davinci +gec2410_config : unconfig + @$(MKCONFIG) $(@:_config=) arm arm920t gec2410 gec s3c24x0 + imx27lite_config: unconfig @$(MKCONFIG) $(@:_config=) arm arm926ejs imx27lite logicpd mx27 diff --git a/board/gec/gec2410/Makefile b/board/gec/gec2410/Makefile new file mode 100644 index 000..052f600 --- /dev/null +++ b/board/gec/gec2410/Makefile @@ -0,0 +1,54 @@ +# +# (C) Copyright 2000-2006 +# Wolfgang Denk, DENX Software Engineering, w...@denx.de. +# +# (C) Copyright 2009 +# Hui Tang zetal...@gmail.com +# +# See file CREDITS for list of people who contributed to this +# project. +# +# This program is free software; you can redistribute it and/or +# modify it under the terms of the GNU General Public License as +# published by the Free Software Foundation; either version 2 of +# the License, or (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 59 Temple Place, Suite 330, Boston, +# MA 02111-1307 USA +# + +include $(TOPDIR)/config.mk + +LIB= $(obj)lib$(BOARD).a + +COBJS := gec2410.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 --git a/board/gec/gec2410/README b/board/gec/gec2410/README new file mode 100644 index 000..952aae8 --- /dev/null +++ b/board/gec/gec2410/README @@ -0,0 +1,85 @@ +U-Boot for GEC2410 +
Re: [U-Boot] [PATCH] OMAP3EVM: Added NAND support
-Original Message-
From: Dirk Behme [mailto:dirk.be...@googlemail.com]
Sent: Wednesday, November 18, 2009 1:01 PM
To: Hiremath, Vaibhav
Cc: u-boot@lists.denx.de
Subject: Re: [U-Boot] [PATCH] OMAP3EVM: Added NAND support
hvaib...@ti.com wrote:
From: Vaibhav Hiremath hvaib...@ti.com
User can now choose between NAND and ONENAND support in
omap3_evm.h
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
---
include/configs/omap3_evm.h | 27 ++-
1 files changed, 26 insertions(+), 1 deletions(-)
diff --git a/include/configs/omap3_evm.h
b/include/configs/omap3_evm.h
index a5514ae..3434306 100644
--- a/include/configs/omap3_evm.h
+++ b/include/configs/omap3_evm.h
@@ -110,7 +110,8 @@
#define CONFIG_CMD_I2C /* I2C serial bus support */
#define CONFIG_CMD_MMC /* MMC support */
-#define CONFIG_CMD_ONENAND /* ONENAND support */
+/*#define CONFIG_CMD_ONENAND*/ /* ONENAND support */
+#define CONFIG_CMD_NAND/* NAND support */
Is it okay to switch the default from ONENAND to NAND here?
[Hiremath, Vaibhav] Most EVM's which I have seen comes with NAND support, so I
have chosen NAND as a default. And anyway here user can select ONENAND also.
Do you see any issues with moving NAND as a default?
#define CONFIG_CMD_DHCP
#define CONFIG_CMD_PING
@@ -141,6 +142,7 @@
/* to access */
/* nand at CS0 */
+
?
#define CONFIG_SYS_MAX_NAND_DEVICE 1 /* Max number
of */
/* NAND devices */
#define CONFIG_SYS_64BIT_VSPRINTF /* needed for
nand_util.c */
@@ -268,7 +270,13 @@
#define CONFIG_SYS_MONITOR_BASECONFIG_SYS_FLASH_BASE
#define CONFIG_SYS_ONENAND_BASEONENAND_MAP
+#if defined(CONFIG_CMD_NAND)
+#define CONFIG_NAND_OMAP_GPMC
+#define GPMC_NAND_ECC_LP_x16_LAYOUT1
+#define CONFIG_ENV_IS_IN_NAND 1
+#elif defined(CONFIG_CMD_ONENAND)
#define CONFIG_ENV_IS_IN_ONENAND 1
+#endif
#define ONENAND_ENV_OFFSET 0x26 /* environment starts
here */
#define SMNAND_ENV_OFFSET 0x26 /* environment starts
here */
@@ -300,6 +308,23 @@ extern unsigned int boot_flash_sec;
extern unsigned int boot_flash_type;
#endif
+
+#define WRITE_NAND_COMMAND(d, adr)\
+ writel(d, nand_cs_base-nand_cmd)
+#define WRITE_NAND_ADDRESS(d, adr)\
+ writel(d, nand_cs_base-nand_adr)
+#define WRITE_NAND(d, adr) writew(d, nand_cs_base-nand_dat)
+#define READ_NAND(adr) readl(nand_cs_base-nand_dat)
+
+/* Other NAND Access APIs */
+#define NAND_WP_OFF() do {readl(gpmc_cfg_base-config) |=
GPMC_CONFIG_WP; } \
+ while (0)
+#define NAND_WP_ON() do {readl(gpmc_cfg_base-config) =
~GPMC_CONFIG_WP; } \
+ while (0)
+#define NAND_DISABLE_CE(nand)
+#define NAND_ENABLE_CE(nand)
+#define NAND_WAIT_READY(nand) udelay(10)
Would encapsulating this with
#if defined(CONFIG_CMD_NAND)
#endif
make sense here?
[Hiremath, Vaibhav] Opps. Sorry, by mistake I have sent old patch, sending you
the cleaned one.
Thanks,
Vaibhav
Best regards
Dirk
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] OMAP3EVM: Added NAND support
From: Vaibhav Hiremath hvaib...@ti.com Signed-off-by: Vaibhav Hiremath hvaib...@ti.com --- include/configs/omap3_evm.h | 10 +- 1 files changed, 9 insertions(+), 1 deletions(-) diff --git a/include/configs/omap3_evm.h b/include/configs/omap3_evm.h index a5514ae..fbc45dc 100644 --- a/include/configs/omap3_evm.h +++ b/include/configs/omap3_evm.h @@ -110,7 +110,8 @@ #define CONFIG_CMD_I2C /* I2C serial bus support */ #define CONFIG_CMD_MMC /* MMC support */ -#define CONFIG_CMD_ONENAND /* ONENAND support */ +/*#define CONFIG_CMD_ONENAND*/ /* ONENAND support */ +#define CONFIG_CMD_NAND/* NAND support */ #define CONFIG_CMD_DHCP #define CONFIG_CMD_PING @@ -141,6 +142,7 @@ /* to access */ /* nand at CS0 */ + #define CONFIG_SYS_MAX_NAND_DEVICE 1 /* Max number of */ /* NAND devices */ #define CONFIG_SYS_64BIT_VSPRINTF /* needed for nand_util.c */ @@ -268,7 +270,13 @@ #define CONFIG_SYS_MONITOR_BASECONFIG_SYS_FLASH_BASE #define CONFIG_SYS_ONENAND_BASEONENAND_MAP +#if defined(CONFIG_CMD_NAND) +#define CONFIG_NAND_OMAP_GPMC +#define GPMC_NAND_ECC_LP_x16_LAYOUT1 +#define CONFIG_ENV_IS_IN_NAND 1 +#elif defined(CONFIG_CMD_ONENAND) #define CONFIG_ENV_IS_IN_ONENAND 1 +#endif #define ONENAND_ENV_OFFSET 0x26 /* environment starts here */ #define SMNAND_ENV_OFFSET 0x26 /* environment starts here */ -- 1.6.2.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] OMAP3EVM: Added NAND support
It would have been nice if subject had a 'v2' now. hvaib...@ti.com wrote: From: Vaibhav Hiremath hvaib...@ti.com Patch description missing here now. And if you re-add, it would be good to mention that you switch from ONENAND to NAND, too. Signed-off-by: Vaibhav Hiremath hvaib...@ti.com --- include/configs/omap3_evm.h | 10 +- 1 files changed, 9 insertions(+), 1 deletions(-) diff --git a/include/configs/omap3_evm.h b/include/configs/omap3_evm.h index a5514ae..fbc45dc 100644 --- a/include/configs/omap3_evm.h +++ b/include/configs/omap3_evm.h @@ -110,7 +110,8 @@ #define CONFIG_CMD_I2C /* I2C serial bus support */ #define CONFIG_CMD_MMC /* MMC support */ -#define CONFIG_CMD_ONENAND /* ONENAND support */ +/*#define CONFIG_CMD_ONENAND*/ /* ONENAND support */ +#define CONFIG_CMD_NAND /* NAND support */ Often it can be irritating for users if default changes silently. But EVM people have to discuss about this, I can't say what the preferred NAND support is. #define CONFIG_CMD_DHCP #define CONFIG_CMD_PING @@ -141,6 +142,7 @@ /* to access */ /* nand at CS0 */ + What's this? Best regards Dirk #define CONFIG_SYS_MAX_NAND_DEVICE 1 /* Max number of */ /* NAND devices */ #define CONFIG_SYS_64BIT_VSPRINTF/* needed for nand_util.c */ @@ -268,7 +270,13 @@ #define CONFIG_SYS_MONITOR_BASE CONFIG_SYS_FLASH_BASE #define CONFIG_SYS_ONENAND_BASE ONENAND_MAP +#if defined(CONFIG_CMD_NAND) +#define CONFIG_NAND_OMAP_GPMC +#define GPMC_NAND_ECC_LP_x16_LAYOUT 1 +#define CONFIG_ENV_IS_IN_NAND1 +#elif defined(CONFIG_CMD_ONENAND) #define CONFIG_ENV_IS_IN_ONENAND 1 +#endif #define ONENAND_ENV_OFFSET 0x26 /* environment starts here */ #define SMNAND_ENV_OFFSET0x26 /* environment starts here */ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/1] S3C2410 NAND Flash Add Missing Function
This patch add nand_read_buf() for S3C2410 NAND SPL.
In nand_spl/nand_boot.c, nand_boot() will check nand-select_chip,
so nand-select_chip should also be initialized.
Signed-off-by: Hui.Tang zetal...@gmail.com
---
drivers/mtd/nand/s3c2410_nand.c | 31 +++
1 files changed, 27 insertions(+), 4 deletions(-)
diff --git a/drivers/mtd/nand/s3c2410_nand.c b/drivers/mtd/nand/s3c2410_nand.c
index f2f3e72..815c78e 100644
--- a/drivers/mtd/nand/s3c2410_nand.c
+++ b/drivers/mtd/nand/s3c2410_nand.c
@@ -36,6 +36,21 @@
#define S3C2410_ADDR_NALE 4
#define S3C2410_ADDR_NCLE 8
+#ifdef CONFIG_NAND_SPL
+
+/* in the early stage of NAND flash booting, printf() is not available */
+#define printf(fmt, args...)
+
+static void nand_read_buf(struct mtd_info *mtd, u_char *buf, int len)
+{
+ int i;
+ struct nand_chip *this = mtd-priv;
+
+ for (i = 0; i len; i++)
+ buf[i] = readb(this-IO_ADDR_R);
+}
+#endif
+
static void s3c2410_hwcontrol(struct mtd_info *mtd, int cmd, unsigned int ctrl)
{
struct nand_chip *chip = mtd-priv;
@@ -83,9 +98,10 @@ void s3c2410_nand_enable_hwecc(struct mtd_info *mtd, int
mode)
static int s3c2410_nand_calculate_ecc(struct mtd_info *mtd, const u_char *dat,
u_char *ecc_code)
{
- ecc_code[0] = NFECC0;
- ecc_code[1] = NFECC1;
- ecc_code[2] = NFECC2;
+ struct s3c2410_nand *nand = s3c2410_get_base_nand();
+ ecc_code[0] = readb(nand-NFECC);
+ ecc_code[1] = readb(nand-NFECC + 1);
+ ecc_code[2] = readb(nand-NFECC + 2);
debugX(1, s3c2410_nand_calculate_hwecc(%p,): 0x%02x 0x%02x 0x%02x\n,
mtd , ecc_code[0], ecc_code[1], ecc_code[2]);
@@ -130,8 +146,13 @@ int board_nand_init(struct nand_chip *nand)
/* initialize nand_chip data structure */
nand-IO_ADDR_R = nand-IO_ADDR_W = (void *)nand_reg-NFDATA;
+ nand-select_chip = NULL;
+
/* read_buf and write_buf are default */
/* read_byte and write_byte are default */
+#ifdef CONFIG_NAND_SPL
+ nand-read_buf = nand_read_buf;
+#endif
/* hwcontrol always must be implemented */
nand-cmd_ctrl = s3c2410_hwcontrol;
@@ -142,7 +163,9 @@ int board_nand_init(struct nand_chip *nand)
nand-ecc.hwctl = s3c2410_nand_enable_hwecc;
nand-ecc.calculate = s3c2410_nand_calculate_ecc;
nand-ecc.correct = s3c2410_nand_correct_data;
- nand-ecc.mode = NAND_ECC_HW3_512;
+ nand-ecc.mode = NAND_ECC_HW;
+ nand-ecc.size = CONFIG_SYS_NAND_ECCSIZE;
+ nand-ecc.bytes = CONFIG_SYS_NAND_ECCBYTES;
#else
nand-ecc.mode = NAND_ECC_SOFT;
#endif
--
1.6.3.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V5 1/4] add TI DA8xx support: DA8xx includes
On 17/11/09 23:10, Wolfgang Denk wrote: Dear Paulraj, Sandeep, In message 0554bef07d437848af01b9c9b5f0bc5d93f2f...@dlee01.ent.ti.com you wrote: Provides initial support for TI OMAP-L1x/DA8xx SoC devices. See http://www.ti.com The DA8xx devices are similar to DaVinci devices but have a differing memory map and updated peripheral versions. Signed-off-by: Nick Thompson nick.thomp...@gefanuc.com Signed-off-by: Sekhar Nori nsek...@ti.com --- Applies to u-boot-ti include/asm-arm/arch-davinci/hardware.h | 237 +++ include/asm-arm/arch-davinci/i2c_defs.h |5 + 2 files changed, 242 insertions(+), 0 deletions(-) Pushed to u-boot-ti/master http://git.denx.de/?p=u-boot/u-boot-ti.git;a=commit;h=32c39e2da8483093dea29858a234ab2ec54e75bd modified the patch header a little. Argh... Please do not push stuff to the master branch of the poublic repository so quickly. Please allow for a few days reviewing first. I just NAKed this patch. Wolfgang, I'm happy to submit a new patch to lowercase these enums if you think that would be a good idea. It might be inviting trouble, but I'm not aware of any outstanding patches that rely on these values directly. I'm not thinking of process here, but we can catch if before it propagates anywhere. Nick. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Condense some lines in common/Makefile for readability.
Collect object files corresponding to the same CONFIG variable on the same line for better readability. Signed-off-by: Robert P. J. Day rpj...@crashcourse.ca --- clearly no *functional* difference but it follows the standard set out in the rest of the file. compile tested for a beagle, for what it's worth. diff --git a/common/Makefile b/common/Makefile index 3781738..c471f38 100644 --- a/common/Makefile +++ b/common/Makefile @@ -50,15 +50,12 @@ COBJS-y += cmd_nvedit.o # environment COBJS-y += env_common.o COBJS-$(CONFIG_ENV_IS_IN_DATAFLASH) += env_dataflash.o -COBJS-$(CONFIG_ENV_IS_IN_EEPROM) += env_eeprom.o +COBJS-$(CONFIG_ENV_IS_IN_EEPROM) += env_embedded.o env_eeprom.o COBJS-$(CONFIG_ENV_IS_EMBEDDED) += env_embedded.o -COBJS-$(CONFIG_ENV_IS_IN_EEPROM) += env_embedded.o -COBJS-$(CONFIG_ENV_IS_IN_FLASH) += env_embedded.o -COBJS-$(CONFIG_ENV_IS_IN_NVRAM) += env_embedded.o -COBJS-$(CONFIG_ENV_IS_IN_FLASH) += env_flash.o +COBJS-$(CONFIG_ENV_IS_IN_FLASH) += env_embedded.o env_flash.o +COBJS-$(CONFIG_ENV_IS_IN_NVRAM) += env_embedded.o env_nvram.o COBJS-$(CONFIG_ENV_IS_IN_MG_DISK) += env_mgdisk.o COBJS-$(CONFIG_ENV_IS_IN_NAND) += env_nand.o -COBJS-$(CONFIG_ENV_IS_IN_NVRAM) += env_nvram.o COBJS-$(CONFIG_ENV_IS_IN_ONENAND) += env_onenand.o COBJS-$(CONFIG_ENV_IS_IN_SPI_FLASH) += env_sf.o COBJS-$(CONFIG_ENV_IS_NOWHERE) += env_nowhere.o Robert P. J. Day Waterloo, Ontario, CANADA Linux Consulting, Training and Kernel Pedantry. Web page: http://crashcourse.ca Twitter: http://twitter.com/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] Condense some lines in common/Makefile for readability.
Collect object files corresponding to the same CONFIG variable on the same line for better readability. Signed-off-by: Robert P. J. Day rpj...@crashcourse.ca --- clearly no *functional* difference but it follows the standard set out in the rest of the file. compile tested for a beagle, for what it's worth. and the slight change to this version is that a duplicate and redundant check for ENV_IS_IN_EEPROM further down the file was also removed. diff --git a/common/Makefile b/common/Makefile index 3781738..b3d66aa 100644 --- a/common/Makefile +++ b/common/Makefile @@ -50,15 +50,12 @@ COBJS-y += cmd_nvedit.o # environment COBJS-y += env_common.o COBJS-$(CONFIG_ENV_IS_IN_DATAFLASH) += env_dataflash.o -COBJS-$(CONFIG_ENV_IS_IN_EEPROM) += env_eeprom.o +COBJS-$(CONFIG_ENV_IS_IN_EEPROM) += env_embedded.o env_eeprom.o COBJS-$(CONFIG_ENV_IS_EMBEDDED) += env_embedded.o -COBJS-$(CONFIG_ENV_IS_IN_EEPROM) += env_embedded.o -COBJS-$(CONFIG_ENV_IS_IN_FLASH) += env_embedded.o -COBJS-$(CONFIG_ENV_IS_IN_NVRAM) += env_embedded.o -COBJS-$(CONFIG_ENV_IS_IN_FLASH) += env_flash.o +COBJS-$(CONFIG_ENV_IS_IN_FLASH) += env_embedded.o env_flash.o +COBJS-$(CONFIG_ENV_IS_IN_NVRAM) += env_embedded.o env_nvram.o COBJS-$(CONFIG_ENV_IS_IN_MG_DISK) += env_mgdisk.o COBJS-$(CONFIG_ENV_IS_IN_NAND) += env_nand.o -COBJS-$(CONFIG_ENV_IS_IN_NVRAM) += env_nvram.o COBJS-$(CONFIG_ENV_IS_IN_ONENAND) += env_onenand.o COBJS-$(CONFIG_ENV_IS_IN_SPI_FLASH) += env_sf.o COBJS-$(CONFIG_ENV_IS_NOWHERE) += env_nowhere.o @@ -84,7 +81,6 @@ COBJS-$(CONFIG_CMD_DIAG) += cmd_diag.o endif COBJS-$(CONFIG_CMD_DISPLAY) += cmd_display.o COBJS-$(CONFIG_CMD_DTT) += cmd_dtt.o -COBJS-$(CONFIG_ENV_IS_IN_EEPROM) += cmd_eeprom.o COBJS-$(CONFIG_CMD_EEPROM) += cmd_eeprom.o COBJS-$(CONFIG_CMD_ELF) += cmd_elf.o COBJS-$(CONFIG_CMD_EXT2) += cmd_ext2.o Robert P. J. Day Waterloo, Ontario, CANADA Linux Consulting, Training and Kernel Pedantry. Web page: http://crashcourse.ca Twitter: http://twitter.com/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] u-boot: Not enough room for program headers (allocated 3, need 4)
Hi, I am compiling latest u-boot code for ppc440x5. My board is having 16MB nor flash, have I modified following parameter. CONFIG_SYS_FLASH_BASE 0xfc00 TEXT_BASE 0xfcfc bootpg 0xfcfff000 With these changes I am getting following error. ../gcc-4.2.4-glibc-2.3.6/powerpc-440-linux-gnu/bin/powerpc-440-linux-gnu-ld: u-boot: Not enough room for program headers (allocated 3, need 4) ../gcc-4.2.4-glibc-2.3.6/powerpc-440-linux-gnu/bin/powerpc-440-linux-gnu-ld: final link failed: Bad value make: *** [u-boot] Error 1 Help me on this error. ~Anu ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] OMAP3EVM: Added NAND support
-Original Message- From: Dirk Behme [mailto:dirk.be...@googlemail.com] Sent: Wednesday, November 18, 2009 2:07 PM To: Hiremath, Vaibhav Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH] OMAP3EVM: Added NAND support It would have been nice if subject had a 'v2' now. [Hiremath, Vaibhav] Ok. hvaib...@ti.com wrote: From: Vaibhav Hiremath hvaib...@ti.com Patch description missing here now. And if you re-add, it would be good to mention that you switch from ONENAND to NAND, too. [Hiremath, Vaibhav] Will add the description accordingly and submit 'v3'. Signed-off-by: Vaibhav Hiremath hvaib...@ti.com --- include/configs/omap3_evm.h | 10 +- 1 files changed, 9 insertions(+), 1 deletions(-) diff --git a/include/configs/omap3_evm.h b/include/configs/omap3_evm.h index a5514ae..fbc45dc 100644 --- a/include/configs/omap3_evm.h +++ b/include/configs/omap3_evm.h @@ -110,7 +110,8 @@ #define CONFIG_CMD_I2C /* I2C serial bus support */ #define CONFIG_CMD_MMC /* MMC support */ -#define CONFIG_CMD_ONENAND /* ONENAND support */ +/*#define CONFIG_CMD_ONENAND*/ /* ONENAND support */ +#define CONFIG_CMD_NAND/* NAND support */ Often it can be irritating for users if default changes silently. But EVM people have to discuss about this, I can't say what the preferred NAND support is. [Hiremath, Vaibhav] If we don't get any objection/comments for this change, then I think it should be safe to change to NAND support by default. #define CONFIG_CMD_DHCP #define CONFIG_CMD_PING @@ -141,6 +142,7 @@ /* to access */ /* nand at CS0 */ + What's this? [Hiremath, Vaibhav] Will remove in next version. Thanks Dirk for reviewing this patch. Thanks, Vaibhav Best regards Dirk #define CONFIG_SYS_MAX_NAND_DEVICE 1 /* Max number of */ /* NAND devices */ #define CONFIG_SYS_64BIT_VSPRINTF /* needed for nand_util.c */ @@ -268,7 +270,13 @@ #define CONFIG_SYS_MONITOR_BASECONFIG_SYS_FLASH_BASE #define CONFIG_SYS_ONENAND_BASEONENAND_MAP +#if defined(CONFIG_CMD_NAND) +#define CONFIG_NAND_OMAP_GPMC +#define GPMC_NAND_ECC_LP_x16_LAYOUT1 +#define CONFIG_ENV_IS_IN_NAND 1 +#elif defined(CONFIG_CMD_ONENAND) #define CONFIG_ENV_IS_IN_ONENAND 1 +#endif #define ONENAND_ENV_OFFSET 0x26 /* environment starts here */ #define SMNAND_ENV_OFFSET 0x26 /* environment starts here */ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ppc4xx: Remove confusing comment
This is not the sequoia board. Signed-off-by: Matthias Fuchs matthias.fu...@esd.eu --- board/esd/pmc440/config.mk |4 1 files changed, 0 insertions(+), 4 deletions(-) diff --git a/board/esd/pmc440/config.mk b/board/esd/pmc440/config.mk index 0c4d582..91e65ec 100644 --- a/board/esd/pmc440/config.mk +++ b/board/esd/pmc440/config.mk @@ -20,10 +20,6 @@ # Foundation, Inc., 59 Temple Place, Suite 330, Boston, # MA 02111-1307 USA # -# -# AMCC 440EPx Reference Platform (Sequoia) board -# - sinclude $(OBJTREE)/board/$(BOARDDIR)/config.tmp ifndef TEXT_BASE -- 1.6.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Servizi finanziari offerti da Gruppo Retefin
Newsletter Retefin Servizi finanziari offerti da Gruppo Retefin GENTILE UTENTE, CON LA PRESENTE MAIL PROPONIAMO ALLA SUA CORTESE ATTENZIONE IL NOSTRO INVITO PER RICHIEDERLE CORTESE CONSENSO ALL' INVIO DI SUCCESSIVE MAIL INFORMATIVE RELATIVE AL NOSTRO PORTALE WEB: SE NON CONFERMA L'ISCRIZIONE LA SUA MAIL SARA' AUTOMATICAMENTE CANCELLATA Ringraziandola per la sua cortese attenzione le porgiamo i nostri saluti 1.jpg2.jpg___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] why is the compilation of cmd_pcmcia.c hardcoded?
Robert, Robert P. J. Day wrote: i'm curious as to why common/Makefile hardcodes the compilation of cmd_pcmcia.c thusly: COBJS-y += cmd_pcmcia.o since i'm interested in building for a beagleboard, i have no interest in PCMCIA support, yet that source file will be compiled for me, even though the selection macro CONFIG_CMD_PCMCIA does exist and is defined by a number of other board configurations. what seems stranger is that, even though that config macro exists, it isn't used in the Makefile but *is* tested in the source file itself to determine whether the pinit command will be compiled: = #if defined(CONFIG_CMD_PCMCIA) If you look at the source code tree from a couple of years ago you'll see that the pattern you've discovered used to be the norm. Over time, people have been removing the source file wrappers and moving conditionality to the Makefiles. It's a work in progress, and help fixing things up is always appreciated. regards, Ben ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V5 1/4] add TI DA8xx support: DA8xx includes
On Wed, Nov 18, 2009 at 12:09:46AM +0100, Wolfgang Denk wrote:
In message 4af9823c.8090...@gefanuc.com you wrote:
Provides initial support for TI OMAP-L1x/DA8xx SoC devices.
See http://www.ti.com
The DA8xx devices are similar to DaVinci devices but have a differing
memory map and updated peripheral versions.
Signed-off-by: Nick Thompson nick.thomp...@gefanuc.com
Signed-off-by: Sekhar Nori nsek...@ti.com
...
+enum davinci_lpsc_ids {
+ DAVINCI_LPSC_TPCC = 0,
+ DAVINCI_LPSC_TPTC0,
+ DAVINCI_LPSC_TPTC1,
+ DAVINCI_LPSC_AEMIF,
+ DAVINCI_LPSC_SPI0,
+ DAVINCI_LPSC_MMC_SD,
[snip]
+ DAVINCI_LPSC_eQEP,
+ DAVINCI_LPSC_SCR_P0,
+ DAVINCI_LPSC_SCR_P1,
+ DAVINCI_LPSC_CR_P3,
+ DAVINCI_LPSC_L3_CBA_RAM
+};
Variable names must be lower case. Please fix.
I suspect the compiler would take issue if you tried to vary those
constants...
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Clarify applicable licensing terms in COPYING file.
On Wed, Nov 18, 2009 at 10:29:17AM +0100, Wolfgang Denk wrote: Signed-off-by: Wolfgang Denk w...@denx.de --- COPYING |9 - 1 files changed, 8 insertions(+), 1 deletions(-) diff --git a/COPYING b/COPYING index f616ab9..9930863 100644 --- a/COPYING +++ b/COPYING @@ -1,4 +1,11 @@ - NOTE! This copyright does *not* cover the so-called standalone + U-Boot is free software. It is copyrighted by Wolfgang Denk and +many others who contributed code (see the actual source code for +details). You can redistribute U-Boot 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 (see text +below), or (at your option) any later version. But there is code in U-Boot that cannot be distributed under later versions of the GPL... -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] OMAP3EVM: Added NAND support
On Wed, Nov 18, 2009 at 12:58 AM, hvaib...@ti.com wrote:
From: Vaibhav Hiremath hvaib...@ti.com
User can now choose between NAND and ONENAND support in omap3_evm.h
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
---
include/configs/omap3_evm.h | 27 ++-
1 files changed, 26 insertions(+), 1 deletions(-)
diff --git a/include/configs/omap3_evm.h b/include/configs/omap3_evm.h
index a5514ae..3434306 100644
--- a/include/configs/omap3_evm.h
+++ b/include/configs/omap3_evm.h
@@ -110,7 +110,8 @@
#define CONFIG_CMD_I2C /* I2C serial bus support */
#define CONFIG_CMD_MMC /* MMC support */
-#define CONFIG_CMD_ONENAND /* ONENAND support */
+/*#define CONFIG_CMD_ONENAND*/ /* ONENAND support */
do you wish to use #undef instead of commented code? also adding a
comment on top saying this is an option might help..
This patch opens up a chain for me: how do we have the same build of
u-boot boot accross nand, onenand, mmc type devices?
current u-boot looks constrainted in that respect.
+#define CONFIG_CMD_NAND /* NAND support */
#define CONFIG_CMD_DHCP
#define CONFIG_CMD_PING
@@ -141,6 +142,7 @@
/* to access */
/* nand at CS0 */
+
#define CONFIG_SYS_MAX_NAND_DEVICE 1 /* Max number of */
/* NAND devices */
#define CONFIG_SYS_64BIT_VSPRINTF /* needed for nand_util.c */
@@ -268,7 +270,13 @@
#define CONFIG_SYS_MONITOR_BASE CONFIG_SYS_FLASH_BASE
#define CONFIG_SYS_ONENAND_BASE ONENAND_MAP
+#if defined(CONFIG_CMD_NAND)
+#define CONFIG_NAND_OMAP_GPMC
+#define GPMC_NAND_ECC_LP_x16_LAYOUT 1
+#define CONFIG_ENV_IS_IN_NAND 1
+#elif defined(CONFIG_CMD_ONENAND)
#define CONFIG_ENV_IS_IN_ONENAND 1
+#endif
what if a user decided to enable NAND and ONENAND?
#define ONENAND_ENV_OFFSET 0x26 /* environment starts here */
#define SMNAND_ENV_OFFSET 0x26 /* environment starts here */
@@ -300,6 +308,23 @@ extern unsigned int boot_flash_sec;
extern unsigned int boot_flash_type;
#endif
+
+#define WRITE_NAND_COMMAND(d, adr)\
+ writel(d, nand_cs_base-nand_cmd)
writel? i thought u had 16 bit nand device.
+#define WRITE_NAND_ADDRESS(d, adr)\
+ writel(d, nand_cs_base-nand_adr)
+#define WRITE_NAND(d, adr) writew(d, nand_cs_base-nand_dat)
+#define READ_NAND(adr) readl(nand_cs_base-nand_dat)
readl?? should'nt you be using readw?
Why these functions? does'nt mtd layer handle this? look at beagle -
it does not use that..
+
+/* Other NAND Access APIs */
+#define NAND_WP_OFF() do {readl(gpmc_cfg_base-config) |= GPMC_CONFIG_WP; }
\
+ while (0)
+#define NAND_WP_ON() do {readl(gpmc_cfg_base-config) = ~GPMC_CONFIG_WP; }
\
+ while (0)
+#define NAND_DISABLE_CE(nand)
+#define NAND_ENABLE_CE(nand)
+#define NAND_WAIT_READY(nand) udelay(10)
+
are these really needed?
/*
* SMSC9115 Ethernet from SMSC9118 family
*
--
1.6.2.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] OMAP3EVM: Added NAND support
Nishanth Menon wrote:
+
+#define WRITE_NAND_COMMAND(d, adr)\
+ writel(d, nand_cs_base-nand_cmd)
writel? i thought u had 16 bit nand device.
+#define WRITE_NAND_ADDRESS(d, adr)\
+ writel(d, nand_cs_base-nand_adr)
+#define WRITE_NAND(d, adr) writew(d, nand_cs_base-nand_dat)
+#define READ_NAND(adr) readl(nand_cs_base-nand_dat)
readl?? should'nt you be using readw?
Why these functions? does'nt mtd layer handle this? look at beagle -
it does not use that..
+
+/* Other NAND Access APIs */
+#define NAND_WP_OFF() do {readl(gpmc_cfg_base-config) |= GPMC_CONFIG_WP;
} \
+ while (0)
+#define NAND_WP_ON() do {readl(gpmc_cfg_base-config) = ~GPMC_CONFIG_WP;
} \
+ while (0)
+#define NAND_DISABLE_CE(nand)
+#define NAND_ENABLE_CE(nand)
+#define NAND_WAIT_READY(nand) udelay(10)
+
are these really needed?
No, they're not needed. That is the legacy NAND interface that has been
superseded and removed.
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] OMAP3EVM: Added NAND support
-Original Message-
From: Nishanth Menon [mailto:menon.nisha...@gmail.com]
Sent: Wednesday, November 18, 2009 11:38 PM
To: Hiremath, Vaibhav
Cc: u-boot@lists.denx.de
Subject: Re: [U-Boot] [PATCH] OMAP3EVM: Added NAND support
On Wed, Nov 18, 2009 at 12:58 AM, hvaib...@ti.com wrote:
From: Vaibhav Hiremath hvaib...@ti.com
User can now choose between NAND and ONENAND support in
omap3_evm.h
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
---
include/configs/omap3_evm.h | 27 ++-
1 files changed, 26 insertions(+), 1 deletions(-)
diff --git a/include/configs/omap3_evm.h
b/include/configs/omap3_evm.h
index a5514ae..3434306 100644
--- a/include/configs/omap3_evm.h
+++ b/include/configs/omap3_evm.h
@@ -110,7 +110,8 @@
#define CONFIG_CMD_I2C /* I2C serial bus support */
#define CONFIG_CMD_MMC /* MMC support */
-#define CONFIG_CMD_ONENAND /* ONENAND support */
+/*#define CONFIG_CMD_ONENAND*/ /* ONENAND support */
do you wish to use #undef instead of commented code? also adding a
comment on top saying this is an option might help..
[Hiremath, Vaibhav] Good point, I will add this.
This patch opens up a chain for me: how do we have the same build of
u-boot boot accross nand, onenand, mmc type devices?
current u-boot looks constrainted in that respect.
[Hiremath, Vaibhav] Atleast for NAND and MMC we are using same build for
obvious reasons, but I am not sure about onenand though. I need to look at it.
+#define CONFIG_CMD_NAND /* NAND support
*/
#define CONFIG_CMD_DHCP
#define CONFIG_CMD_PING
@@ -141,6 +142,7 @@
/* to
access */
/* nand at
CS0 */
+
#define CONFIG_SYS_MAX_NAND_DEVICE 1 /* Max
number of */
/* NAND
devices */
#define CONFIG_SYS_64BIT_VSPRINTF /* needed for
nand_util.c */
@@ -268,7 +270,13 @@
#define CONFIG_SYS_MONITOR_BASE
CONFIG_SYS_FLASH_BASE
#define CONFIG_SYS_ONENAND_BASE ONENAND_MAP
+#if defined(CONFIG_CMD_NAND)
+#define CONFIG_NAND_OMAP_GPMC
+#define GPMC_NAND_ECC_LP_x16_LAYOUT 1
+#define CONFIG_ENV_IS_IN_NAND 1
+#elif defined(CONFIG_CMD_ONENAND)
#define CONFIG_ENV_IS_IN_ONENAND 1
+#endif
what if a user decided to enable NAND and ONENAND?
#define ONENAND_ENV_OFFSET 0x26 /* environment
starts here */
#define SMNAND_ENV_OFFSET 0x26 /* environment
starts here */
@@ -300,6 +308,23 @@ extern unsigned int boot_flash_sec;
extern unsigned int boot_flash_type;
#endif
+
+#define WRITE_NAND_COMMAND(d, adr)\
+ writel(d, nand_cs_base-nand_cmd)
writel? i thought u had 16 bit nand device.
+#define WRITE_NAND_ADDRESS(d, adr)\
+ writel(d, nand_cs_base-nand_adr)
+#define WRITE_NAND(d, adr) writew(d, nand_cs_base-nand_dat)
+#define READ_NAND(adr) readl(nand_cs_base-nand_dat)
readl?? should'nt you be using readw?
Why these functions? does'nt mtd layer handle this? look at beagle -
it does not use that..
+
+/* Other NAND Access APIs */
+#define NAND_WP_OFF() do {readl(gpmc_cfg_base-config) |=
GPMC_CONFIG_WP; } \
+ while (0)
+#define NAND_WP_ON() do {readl(gpmc_cfg_base-config) =
~GPMC_CONFIG_WP; } \
+ while (0)
+#define NAND_DISABLE_CE(nand)
+#define NAND_ENABLE_CE(nand)
+#define NAND_WAIT_READY(nand) udelay(10)
+
are these really needed?
[Hiremath, Vaibhav] Nishant, you are looking at old patchset which I sent by
mistake. Please review new V3 version of patch.
Thanks,
Vaibhav
/*---
-
* SMSC9115 Ethernet from SMSC9118 family
*
--
1.6.2.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Clarify applicable licensing terms in COPYING file.
Dear Scott Wood, In message 20091118180115.gb15...@loki.buserror.net you wrote: + U-Boot is free software. It is copyrighted by Wolfgang Denk and +many others who contributed code (see the actual source code for +details). You can redistribute U-Boot 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 (see text +below), or (at your option) any later version. But there is code in U-Boot that cannot be distributed under later versions of the GPL... Indeed. We need to work on this. If you propose to use a different wording, please don't hesitate to make suggestions. 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 reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. - George Bernard Shaw ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Clarify applicable licensing terms in COPYING file.
Wolfgang Denk wrote: Dear Scott Wood, In message 20091118180115.gb15...@loki.buserror.net you wrote: + U-Boot is free software. It is copyrighted by Wolfgang Denk and +many others who contributed code (see the actual source code for +details). You can redistribute U-Boot 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 (see text +below), or (at your option) any later version. But there is code in U-Boot that cannot be distributed under later versions of the GPL... Indeed. We need to work on this. If you propose to use a different wording, please don't hesitate to make suggestions. How about: U-Boot is free software. It is copyrighted by Wolfgang Denk and many others who contributed code (see the actual source code for details). You can redistribute U-Boot and/or modify it under the terms of version 2 of the GNU General Public License as published by the Free Software Foundation. Most of it can also be distributed, at your option, under any later version of the GNU General Public License -- see individual files for exceptions. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Davinci: Configurable NAND chip selects
On Mon, Nov 16, 2009 at 05:49:55PM +, Nick Thompson wrote:
static void nand_davinci_enable_hwecc(struct mtd_info *mtd, int mode)
{
- int dummy;
+ u_int32_t val;
- dummy = emif_regs-NANDF1ECC;
+ val = readl(emif_regs-NANDF1ECC);
val = can be omitted, which would keep it clear that it is a dummy read.
- /* FIXME: only chipselect 0 is supported for now */
- emif_regs-NANDFCR |= 1 8;
+ val = readl(emif_regs-NANDFCR);
+ val |= DAVINCI_NANDFCR_1BIT_ECC_START(CONFIG_SYS_NAND_CS);
+ writel(val, emif_regs-NANDFCR);
Do you need to clear the bit corresponding to the previous chipselect?
Otherwise, ACK.
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] NAND: Update read_read_subpage API check
On Mon, Nov 16, 2009 at 01:32:01PM -0500, s-paul...@ti.com wrote: From: Sandeep Paulraj s-paul...@ti.com This patch updates a check condition in the NAND driver. The check condition is similat to what is in linux/next. Hmm, even in Linux all other invocations of ecc.correct check 0 rather than == -1. I've applied it for consistency with upstream, though. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] NAND:Extending the nand_ecclayout structure
On Mon, Nov 16, 2009 at 01:31:47PM -0500, s-paul...@ti.com wrote: From: Sandeep Paulraj s-paul...@ti.com NANDs with page size of lesser than and equal to 2K are reaching EOL. They are bing replaced with NANDs of page size 4K and above. To support this we have to extend the eccpos field Signed-off-by: Sandeep Paulraj s-paul...@ti.com --- I believe a patch was submitted to linux-mtd to update this. But this change was rejected to the best of my knowledge because it will break user space IOCTL's, i.e. when we we run some tests from the mtd-utils. I can't see an solution to the issue addressed in the kernel or mtd-utils. I think this can be added to u-boot. Applied. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Davinci: Configurable NAND chip selects
On Mon, Nov 16, 2009 at 05:49:55PM +, Nick Thompson wrote:
static void nand_davinci_enable_hwecc(struct mtd_info *mtd, int mode)
{
- int dummy;
+ u_int32_t val;
- dummy = emif_regs-NANDF1ECC;
+ val = readl(emif_regs-NANDF1ECC);
val = can be omitted, which would keep it clear that it is a dummy read.
- /* FIXME: only chipselect 0 is supported for now */
- emif_regs-NANDFCR |= 1 8;
+ val = readl(emif_regs-NANDFCR);
+ val |= DAVINCI_NANDFCR_1BIT_ECC_START(CONFIG_SYS_NAND_CS);
+ writel(val, emif_regs-NANDFCR);
Do you need to clear the bit corresponding to the previous chipselect?
Otherwise, ACK.
-Scott
Scott,
Can you give me some time to test it out on my DaVinci SOC's.
I want to test it with all the other updates that I have just pulled in from
Wolfgang's next
Thanks,
Sandeep
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] S3C2410 NAND Flash Add Missing Function
On Wed, Nov 18, 2009 at 04:24:04PM +0800, Hui.Tang wrote: This patch add nand_read_buf() for S3C2410 NAND SPL. In nand_spl/nand_boot.c, nand_boot() will check nand-select_chip, so nand-select_chip should also be initialized. Signed-off-by: Hui.Tang zetal...@gmail.com Applied to u-boot-nand-flash/next. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Davinci: Configurable NAND chip selects
Dear Scott Wood,
In message 20091118202216.ga15...@loki.buserror.net you wrote:
On Mon, Nov 16, 2009 at 05:49:55PM +, Nick Thompson wrote:
static void nand_davinci_enable_hwecc(struct mtd_info *mtd, int mode)
{
- int dummy;
+ u_int32_t val;
- dummy = emif_regs-NANDF1ECC;
+ val = readl(emif_regs-NANDF1ECC);
val = can be omitted, which would keep it clear that it is a dummy read.
For a little more emphasis one can even write
(void)readl(emif_regs-NANDF1ECC);
which really makes it clear that the return value is ignored
intentionally.
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 software required `Windows 95 or better', so I installed Linux.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 1/3] Initial support for Marvell Orion5x SoC
Dear Albert Aribaud,
In message 1258239796-21528-2-git-send-email-albert.arib...@free.fr you wrote:
This patch adds support for the Marvell Orion5x SoC.
It has no use alone, and must be followed by a patch
to add Orion5x support for serial, then support for
the ED Mini V2, an Orion5x-based board from LaCie.
...
diff --git a/cpu/arm926ejs/orion5x/timer.c b/cpu/arm926ejs/orion5x/timer.c
new file mode 100644
...
+#define READ_TIMER \
+ (readl(CNTMR_VAL_REG(UBOOT_CNTR)) / (CONFIG_SYS_TCLK / 1000))
...
+ /* reset time */
+ lastdec = READ_TIMER;
Macros resembling functions should look like functions, i. e. have
parens. Also please note that generally, inline functions are
preferable to macros resembling functions.
...
+#define UBOOT_CNTR_VAL readl(CNTMR_VAL_REG(UBOOT_CNTR))
Ditto.
+void udelay(unsigned long usec)
+{
+ uint current;
+ ulong delayticks;
+
+ current = readl(CNTMR_VAL_REG(UBOOT_CNTR));
Why do you add the #define above when you then don't use it?
+ delayticks = (usec * (CONFIG_SYS_TCLK / 100));
+
+ if (current delayticks) {
+ delayticks -= current;
+ while (readl(CNTMR_VAL_REG(UBOOT_CNTR)) current)
Ditto.
diff --git a/cpu/arm926ejs/orion5x/mpp.c b/cpu/arm926ejs/orion5x/mpp.c
new file mode 100644
index 000..f341747
--- /dev/null
+++ b/cpu/arm926ejs/orion5x/mpp.c
...
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed as is without any
+ * warranty of any kind, whether express or implied.
NAK. License must be v2 or any later version. Ditto for some other
files.
diff --git a/include/asm-arm/arch-orion5x/88f5182.h
b/include/asm-arm/arch-orion5x/88f5182.h
new file mode 100644
index 000..b16b23f
--- /dev/null
+++ b/include/asm-arm/arch-orion5x/88f5182.h
88f5182 is a terrible file name. Can you not come up with something
more descriptive, please?
diff --git a/include/asm-arm/arch-orion5x/gpio.h
b/include/asm-arm/arch-orion5x/gpio.h
new file mode 100644
index 000..58592ad
--- /dev/null
+++ b/include/asm-arm/arch-orion5x/gpio.h
...
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed as is without any
+ * warranty of any kind, whether express or implied.
NAK. See above.
+#define GPIO_MAX 26
+#define GPIO_OUT(pin)(ORION5X_GPIO0_BASE + 0x00)
+#define GPIO_IO_CONF(pin)(ORION5X_GPIO0_BASE + 0x04)
+#define GPIO_BLINK_EN(pin) (ORION5X_GPIO0_BASE + 0x08)
+#define GPIO_IN_POL(pin) (ORION5X_GPIO0_BASE + 0x0c)
+#define GPIO_DATA_IN(pin)(ORION5X_GPIO0_BASE + 0x10)
+#define GPIO_EDGE_CAUSE(pin) (ORION5X_GPIO0_BASE + 0x14)
+#define GPIO_EDGE_MASK(pin) (ORION5X_GPIO0_BASE + 0x18)
+#define GPIO_LEVEL_MASK(pin) (ORION5X_GPIO0_BASE + 0x1c)
NAK. Please make this a C struct.
+/*
+ * Orion5x-specific GPIO API
+ */
Why do we need an Orion5x-specific GPIO API? Can't we use something
that is more general?
diff --git a/include/asm-arm/arch-orion5x/mpp.h
b/include/asm-arm/arch-orion5x/mpp.h
new file mode 100644
index 000..31fade7
--- /dev/null
+++ b/include/asm-arm/arch-orion5x/mpp.h
...
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed as is without any
+ * warranty of any kind, whether express or implied.
NAK. See above.
+#define MPP(_num, _sel, _in, _out, _F5182, _F5281) ( \
+ /* MPP number */((_num) 0xff) | \
+ /* MPP select value */ (((_sel) 0xf) 8) | \
+ /* may be input signal */ ((!!(_in)) 12) | \
+ /* may be output signal */ ((!!(_out)) 13) | \
+ /* available on F5182 */((!!(_F5182)) 14) | \
+ /* available on F5281 */((!!(_F5182)) 15))
Comments follow the code, not vice versa.
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 night sky over the planet Krikkit is the least interesting sight
in the entire Universe.
- Douglas Adams _Life, the Universe, and Everything_
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 3/3] Add support for the LaCie ED Mini V2 board
Dear Albert Aribaud,
In message 1258239796-21528-4-git-send-email-albert.arib...@free.fr you wrote:
This board is based on the Marvell Orion5x SoC.
Current support is limited to console and Flash.
Flash support uses LEGACY as the Macronix 29LV400
used on ED Mini V2 is not 100% CFI compliant.
And the differences are really so big that we cannot tweak the CFI
driver?
+int dram_init(void)
+{
+ int i;
+
+ for (i = 0; i CONFIG_NR_DRAM_BANKS; i++) {
+ gd-bd-bi_dram[i].start = orion5x_sdram_bar(i);
+ gd-bd-bi_dram[i].size = orion5x_sdram_bs(i);
+ }
+ return 0;
+}
Cannot you use get_ram_size() for auto-sizing and checking?
diff --git a/include/configs/edminiv2.h b/include/configs/edminiv2.h
new file mode 100644
index 000..31de164
--- /dev/null
+++ b/include/configs/edminiv2.h
...
+#define CONFIG_SYS_BAUDRATE_TABLE \
+{ 9600, 19200, 38400, 57600, 115200, 230400, 460800, 921600 }
Indentation by a TAB, please.
+#define CONFIG_SYS_FLASH_SECTSZ \
+{16384, 8192, 8192, 32768, 65536, 65536, 65536, 65536, 65536, 65536, 65536}
Ditto. And be careful about the line length.
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
You get a wonderful view from the point of no return.
- Terry Pratchett, _Making_Money_
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4 v2] DA8xx: Add MUSB host support
Dear Sandeep, In message 0554bef07d437848af01b9c9b5f0bc5d94158...@dlee01.ent.ti.com you wrote: Sorry for asking stupid questions - but which sort of conflict do you see in this text? The licensing seems to be OK with me (reference to COPYING file in the top level directory), and the exclusion of warranty is not a problem either. Am I missing something? GPL 2 and at option later version is missing. Well, there was a reference to the COPYING file, which should be sufficient. I sent a patch to make this clear. + * THIS PACKAGE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR + * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED + * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE. I am referring to this AS IS part. I believe I discussed offline with you and Tom quite some time back and IIRC you had said that modifying this header to suit our needs was not allowed. I see no problem with this part. It corresponds mostly with the NO WARRANTY of the GPL; the wording may be different, but I see no conflicts (of course, IANAL). 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 Anything free is worth what you pay for it. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] flash.h: pull in common.h for types
Dear Mike Frysinger, In message 200911171918.39290.vap...@gentoo.org you wrote: I don't know whether Linux has a specific policy on this, but I haven't noticed many problems in this regard, and when I did find one in the kernel a few years back I didn't get any argument when I submitted a patch to fix it. ive semi-frequently post fixes to linux headers so that you can include just that header and have it work. i have yet to hear anyone complain; rather every one has been merged (ignoring issues unrelated to the original purpose). Note that I don't complain. Your patch just made me aware that I don;t know if there is any official poicy for this anywhere, and my initial search was not really successfull. Are you aware of any such official declarations for Linux, or glibc, or similar? 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 EMACS belongs in sys/errno.h: Editor too big! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fix flash_sect_erase() to display correct message
Dear =?UTF-8?B?IlNldW5naHllb24gUmhlZSAo7J207Iq57ZiEKSI=?=, In message 4b035ee8.90...@lpmtec.com you wrote: I think this patch is not an improvement. Now it prints Not erased even when sectors _have_ successfully been earased, which is at least as wrong als the old behaviour. ... As you can see, we _always_ print a warning message. Actually, we usually print the warning message but not _always_. That depends on the flash implementation (*flash.c) of each board. Ah! So you are talking about a custom flash driver. At least 20 implementations currently do nothing and return with ERR_PROTECTED if they found any protected sectors. I was porting U-Boot Well, in this case we should consider this flash driver incomplete or broken and fix that one first. to my board and found the artifact. Unfortunately (or fortunately in some respect), I chose smdk2410's flash.c as a template which belongs to the _irregular_ case. So I suggest you dump your copy of that driver code, and use the CFI driver instead - it seems the smdk2410 flash driver supports only CFI conformant flashes anyway, so it could/should be removed. If you want, and if you can find a clean way to implement it, it might make sense to change the output into something like Erased 4 (instead of 7 requested) sectors or the like. I think we need to first make all of them consistent. My suggestion is: OK, then please start by removing obsolete and redundant driver code and use the CFI driver wherever possible. - display a warning message in flash_erase() that there are some protected sectors and erase unprotected sectors like now. OK. - remove the number indicating how manny sectors are erased from the message in flash_sect_erase() or any caller of flash_erase(). A simple message like done would be enough. I disagree. I find the number of erased sectors a pretty useful information (for example when it comes to calculate ease timings). 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 Alles Gescheite ist schon gedacht worden, man muß nur versuchen, es noch einmal zu denken. -- Goethe, Maximen und Reflexionen ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] README: Add an example of adding a new board.
Dear Robert P. J. Day, In message alpine.lfd.2.00.0911180024280.13...@localhost you wrote: p.s. is there a trivial patch email address for simple things like typoes, just to keep this main list for more important stuff? No. All patches shall go though a central place (i. e. this list). 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 Weekends were made for programming. - Karl Lehenbauer ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] ARM Add New Board GEC2410
Dear Hui Tang, In message f9f0f3cf0911172255n73b44b41if851e7f9cc052...@mail.gmail.com you wrote: Dear Wolfgang, +PLATFORM_CPPFLAGS += -I$(TOPDIR)/board/gec/gec2410 Why is this needed? in /board/gec/gec2410/lowlevel_init.S, it includes gec2410_mem.h, which is at $(TOPDIR)/board/gec/gec2410. So it's in the same directory? Then this should not be needed. diff --git a/nand_spl/board/gec/gec2410/u-boot.lds b/nand_spl/board/gec/gec2410/u-boot.lds new file mode 100644 index 000..5871f7e --- /dev/null +++ b/nand_spl/board/gec/gec2410/u-boot.lds This file seems to be unused. Why add it? /nand_spl/board/gec/gec2410/Makefile needs it to generate /nand_spl/board/u-boot.lds I see no reference in the Makefile? 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 There were meetings. There were always meetings. And they were dull, which is part of the reason they were meetings. Dull likes company. - Terry Pratchett, _Making_Money_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V5 1/4] add TI DA8xx support: DA8xx includes
Dear Nick Thompson, In message 4b03bd0c.7080...@gefanuc.com you wrote: I'm happy to submit a new patch to lowercase these enums if you think that would be a good idea. It might be inviting trouble, but I'm not aware of any outstanding patches that rely on these values directly. I'm sorry, but I was actually wrong here. I missed the fact that it was an enum. And the CodingStyle says: Names of macros defining constants and labels in enums are capitalized.' Sorry, my fault. I hereby withdraw my complaint and apologize for not being more careful. 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 would we be without rhetorical questions? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] crc32: Make crc32 build on non Linux too
Dear Joakim Tjernlund, In message offb1b0130.66ea-onc1257672.00315799-c1257672.003a0...@transmode.se you wrote: This was a reply for Mikes comment on [PATCH v2] crc32: Impl. linux optimized crc32() If it was a reply to [PATCH v2] crc32: ... then why didn't the Subject read Re: [PATCH v2] crc32: ? Would it been better for you if I just included the patch in a normal email reply? Sorry, I fail to understand what you mean here. And PLEASE keep the In-reply-to: and References: headers so threading of the messages works. Since this was a new email sent with git, I don't In-reply-to: and References: should be there? You do reply to this thread. And git send-email asks you to provide the message Id's: Message-ID to be used as In-Reply-To for the first email? Please do not ignore this. Anyhow, I can send a V3 version with everything in it to sum it up? Yes, please do, with clean commit message, s-o-b etc. 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 Our universe is a fragile house of atoms, held together by the mortar of cause-and-effect. One magician would be two too many. - Terry Pratchett, _The Dark Side of the Sun_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 1/3] Initial support for Marvell Orion5x SoC
Hi Wolfgang, Wolfgang Denk a écrit : 88f5182 is a terrible file name. Can you not come up with something more descriptive, please? Actually, the name is based on the actual name of the Marvell SoC variant. Why do we need an Orion5x-specific GPIO API? Can't we use something that is more general? If there is such a general API, I'm willing to use it. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] crc32: Make crc32 build on non Linux too
Wolfgang Denk w...@denx.de wrote on 18/11/2009 23:45:56: Dear Joakim Tjernlund, In message OFFB1B0130.66EA-ONC1257672.00315799-C1257672. 003a0...@transmode.se you wrote: This was a reply for Mikes comment on [PATCH v2] crc32: Impl. linux optimized crc32() If it was a reply to [PATCH v2] crc32: ... then why didn't the Subject read Re: [PATCH v2] crc32: ? Would it been better for you if I just included the patch in a normal email reply? Sorry, I fail to understand what you mean here. Hit the reply button for Mike's mail and just include the patch last in the reply. And PLEASE keep the In-reply-to: and References: headers so threading of the messages works. Since this was a new email sent with git, I don't In-reply-to: and References: should be there? You do reply to this thread. And git send-email asks you to provide the message Id's: Message-ID to be used as In-Reply-To for the first email? Please do not ignore this. I familiar on when it is appropriate to use In-reply-to:/References: You mean even if a send a new mail(a git patch in this case) with a new subject, I should still add those two headers? Getting those headers is another story, our crappy mail system don't let me see headers easily :( Anyhow, I can send a V3 version with everything in it to sum it up? Yes, please do, with clean commit message, s-o-b etc. Will do. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] flash.h: pull in common.h for types
On Wednesday 18 November 2009 17:28:46 Wolfgang Denk wrote: Mike Frysinger wrote: I don't know whether Linux has a specific policy on this, but I haven't noticed many problems in this regard, and when I did find one in the kernel a few years back I didn't get any argument when I submitted a patch to fix it. ive semi-frequently post fixes to linux headers so that you can include just that header and have it work. i have yet to hear anyone complain; rather every one has been merged (ignoring issues unrelated to the original purpose). Note that I don't complain. Your patch just made me aware that I don;t know if there is any official poicy for this anywhere, and my initial search was not really successfull. Are you aware of any such official declarations for Linux, or glibc, or similar? in terms of public headers that random end users include, i'm not aware of any standard and/or official declaration for either project, or any large important open source project for that matter -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] crc32: Make crc32 build on non Linux too
On Wednesday 18 November 2009 17:59:59 Joakim Tjernlund wrote: Wolfgang Denk wrote on 18/11/2009 23:45:56: Joakim Tjernlund wrote: And PLEASE keep the In-reply-to: and References: headers so threading of the messages works. Since this was a new email sent with git, I don't In-reply-to: and References: should be there? You do reply to this thread. And git send-email asks you to provide the message Id's: Message-ID to be used as In-Reply-To for the first email? Please do not ignore this. I familiar on when it is appropriate to use In-reply-to:/References: You mean even if a send a new mail(a git patch in this case) with a new subject, I should still add those two headers? yes Getting those headers is another story, our crappy mail system don't let me see headers easily :( it should be relatively easy to obtain via gmane. but i'm pretty sure every MS based e-mail system has support for 'view source', and certainly every open source e-mail client does. -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] crc32: Make crc32 build on non Linux too
Mike Frysinger vap...@gentoo.org wrote on 19/11/2009 00:45:16: On Wednesday 18 November 2009 17:59:59 Joakim Tjernlund wrote: Wolfgang Denk wrote on 18/11/2009 23:45:56: Joakim Tjernlund wrote: And PLEASE keep the In-reply-to: and References: headers so threading of the messages works. Since this was a new email sent with git, I don't In-reply-to: and References: should be there? You do reply to this thread. And git send-email asks you to provide the message Id's: Message-ID to be used as In-Reply-To for the first email? Please do not ignore this. I familiar on when it is appropriate to use In-reply-to:/References: You mean even if a send a new mail(a git patch in this case) with a new subject, I should still add those two headers? yes I see, thanks. Getting those headers is another story, our crappy mail system don't let me see headers easily :( it should be relatively easy to obtain via gmane. but i'm pretty sure every I will not go to such length to get these. MS based e-mail system has support for 'view source', and certainly every open source e-mail client does. If I only had one of those :( However, Lotus/Domino does have a view source too and sometimes it even works :) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] Condense some lines in common/Makefile for readability.
On Wednesday 18 November 2009 06:01:52 Robert P. J. Day wrote: Collect object files corresponding to the same CONFIG variable on the same line for better readability. clearly no *functional* difference but it follows the standard set out in the rest of the file. compile tested for a beagle, for what it's worth. and the slight change to this version is that a duplicate and redundant check for ENV_IS_IN_EEPROM further down the file was also removed. diff --git a/common/Makefile b/common/Makefile index 3781738..b3d66aa 100644 --- a/common/Makefile +++ b/common/Makefile @@ -50,15 +50,12 @@ COBJS-y += cmd_nvedit.o # environment COBJS-y += env_common.o COBJS-$(CONFIG_ENV_IS_IN_DATAFLASH) += env_dataflash.o -COBJS-$(CONFIG_ENV_IS_IN_EEPROM) += env_eeprom.o +COBJS-$(CONFIG_ENV_IS_IN_EEPROM) += env_embedded.o env_eeprom.o COBJS-$(CONFIG_ENV_IS_EMBEDDED) += env_embedded.o -COBJS-$(CONFIG_ENV_IS_IN_EEPROM) += env_embedded.o -COBJS-$(CONFIG_ENV_IS_IN_FLASH) += env_embedded.o -COBJS-$(CONFIG_ENV_IS_IN_NVRAM) += env_embedded.o -COBJS-$(CONFIG_ENV_IS_IN_FLASH) += env_flash.o +COBJS-$(CONFIG_ENV_IS_IN_FLASH) += env_embedded.o env_flash.o +COBJS-$(CONFIG_ENV_IS_IN_NVRAM) += env_embedded.o env_nvram.o COBJS-$(CONFIG_ENV_IS_IN_MG_DISK) += env_mgdisk.o COBJS-$(CONFIG_ENV_IS_IN_NAND) += env_nand.o -COBJS-$(CONFIG_ENV_IS_IN_NVRAM) += env_nvram.o COBJS-$(CONFIG_ENV_IS_IN_ONENAND) += env_onenand.o COBJS-$(CONFIG_ENV_IS_IN_SPI_FLASH) += env_sf.o COBJS-$(CONFIG_ENV_IS_NOWHERE) += env_nowhere.o @@ -84,7 +81,6 @@ COBJS-$(CONFIG_CMD_DIAG) += cmd_diag.o endif COBJS-$(CONFIG_CMD_DISPLAY) += cmd_display.o COBJS-$(CONFIG_CMD_DTT) += cmd_dtt.o -COBJS-$(CONFIG_ENV_IS_IN_EEPROM) += cmd_eeprom.o COBJS-$(CONFIG_CMD_EEPROM) += cmd_eeprom.o COBJS-$(CONFIG_CMD_ELF) += cmd_elf.o COBJS-$(CONFIG_CMD_EXT2) += cmd_ext2.o the env_embedded.o lines are kept sep on purpose and i'd prefer to keep it this way seeing as how i have patches to simply delete these. -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] why is the compilation of cmd_pcmcia.c hardcoded?
On Wednesday 18 November 2009 03:17:21 Robert P. J. Day wrote: i'm curious as to why common/Makefile hardcodes the compilation of cmd_pcmcia.c thusly: COBJS-y += cmd_pcmcia.o since i'm interested in building for a beagleboard, i have no interest in PCMCIA support, yet that source file will be compiled for me, even though the selection macro CONFIG_CMD_PCMCIA does exist and is defined by a number of other board configurations. what seems stranger is that, even though that config macro exists, it isn't used in the Makefile but *is* tested in the source file itself to determine whether the pinit command will be compiled: you didnt read enough of the code. specifically, you missed the fact that other config options can compile code in this file even if CONFIG_CMD_PCMCIA is disabled. if you feel like re-architecting and splitting the code to take this into consideration, that's one thing. but it isnt a simple 'move the config option into the makefile' fix. -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] bootm: Fix help message's sub-command ordering
The help message for the 'bootm' command listed the 'cmdline' and 'bdt'
sub-commands in the wrong order which resulted in the error below when
following the 'help' command's instructions:
Trying to execute a command out of order
Signed-off-by: Peter Tyser pty...@xes-inc.com
---
Feel free to apply this for the upcoming release or -next. I don't think
its a big problem as most users don't currently use the bootm
sub-commands.
common/cmd_bootm.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
index 8f83598..9496f5c 100644
--- a/common/cmd_bootm.c
+++ b/common/cmd_bootm.c
@@ -453,8 +453,8 @@ cmd_tbl_t cmd_bootm_sub[] = {
#ifdef CONFIG_OF_LIBFDT
U_BOOT_CMD_MKENT(fdt, 0, 1, (void *)BOOTM_STATE_FDT, , ),
#endif
- U_BOOT_CMD_MKENT(bdt, 0, 1, (void *)BOOTM_STATE_OS_BD_T, , ),
U_BOOT_CMD_MKENT(cmdline, 0, 1, (void *)BOOTM_STATE_OS_CMDLINE, , ),
+ U_BOOT_CMD_MKENT(bdt, 0, 1, (void *)BOOTM_STATE_OS_BD_T, , ),
U_BOOT_CMD_MKENT(prep, 0, 1, (void *)BOOTM_STATE_OS_PREP, , ),
U_BOOT_CMD_MKENT(go, 0, 1, (void *)BOOTM_STATE_OS_GO, , ),
};
@@ -1000,8 +1000,8 @@ U_BOOT_CMD(
#if defined(CONFIG_OF_LIBFDT)
\tfdt - relocate flat device tree\n
#endif
- \tbdt - OS specific bd_t processing\n
\tcmdline - OS specific command line processing/setup\n
+ \tbdt - OS specific bd_t processing\n
\tprep- OS specific prep before relocation or go\n
\tgo - start OS
);
--
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 3/7] fec_imx27: driver for FEC ethernet controller on i.MX27
On Mon, Nov 16, 2009 at 8:59 PM, Ben Warren biggerbadder...@gmail.com wrote: Hi Alfred, alfred steele wrote: Thanks for your submission! What is the current design on the mxc fec interface's attainment of a MAC address. From the kernel driver it looks like it looks at the IIM(IC identification registers) on the MXC platform(like mx51/35) to look for a programmed mac address and then the set the fec mac to the same . Looks like with the current mxc_fec driver there is not support for the same. I am thinking of a mechanism to hardcode a fake MAC which would subsequently be picked up by the kernel without using the bd_info structure. Any comments/suggestions? -Alfred. I don't know much about this driver, but it appears to be doing things incorrectly. The correct flow is as follows. It is documented in 'doc/README.enetaddr': 1. The driver's initialize() function read from NVRAM if available. MAC address is stuffed into dev-enetaddr. The initialize() function should not try to get the address from the environment, which is where the imx27 driver goes wrong. 2. After all drivers have been initialized, eth_initialize() ( in net/eth.c) reads from the environment. If the value in the environment is valid and the value in dev-enetaddr is valid and both are different, the user is warned. The value in the environment overwrites the value in dev-enetaddr 3. When a network operation is performed, the driver's init() function is called, which is where the address is programmed into the device. As you can see, if the device is never used, step 3 is never exected and the device is never programmed. This is how it's supposed to work, since the U-boot design philosophy dictates that hardware is never touched unless it is used in U-boot. I'm pretty sure hard-coding a fake MAC address would run afoul of this rule. Is there a way to pass the information to kernel using either the dev-enetaddr without programming the IIM module register. Would i have to use bd_info structure or can we do without it.? This problem is specific to the mx27 i guess. -Alfred ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/7] fec_imx27: driver for FEC ethernet controller on i.MX27
Alfred, On Wed, Nov 18, 2009 at 5:54 PM, alfred steele alfred.jaq...@gmail.comwrote: On Mon, Nov 16, 2009 at 8:59 PM, Ben Warren biggerbadder...@gmail.com wrote: Hi Alfred, alfred steele wrote: Thanks for your submission! What is the current design on the mxc fec interface's attainment of a MAC address. From the kernel driver it looks like it looks at the IIM(IC identification registers) on the MXC platform(like mx51/35) to look for a programmed mac address and then the set the fec mac to the same . Looks like with the current mxc_fec driver there is not support for the same. I am thinking of a mechanism to hardcode a fake MAC which would subsequently be picked up by the kernel without using the bd_info structure. Any comments/suggestions? -Alfred. I don't know much about this driver, but it appears to be doing things incorrectly. The correct flow is as follows. It is documented in 'doc/README.enetaddr': 1. The driver's initialize() function read from NVRAM if available. MAC address is stuffed into dev-enetaddr. The initialize() function should not try to get the address from the environment, which is where the imx27 driver goes wrong. 2. After all drivers have been initialized, eth_initialize() ( in net/eth.c) reads from the environment. If the value in the environment is valid and the value in dev-enetaddr is valid and both are different, the user is warned. The value in the environment overwrites the value in dev-enetaddr 3. When a network operation is performed, the driver's init() function is called, which is where the address is programmed into the device. As you can see, if the device is never used, step 3 is never exected and the device is never programmed. This is how it's supposed to work, since the U-boot design philosophy dictates that hardware is never touched unless it is used in U-boot. I'm pretty sure hard-coding a fake MAC address would run afoul of this rule. Is there a way to pass the information to kernel using either the dev-enetaddr without programming the IIM module register. Would i have to use bd_info structure or can we do without it.? This problem is specific to the mx27 i guess. -Alfred I'm pretty sure it's a much-discussed ARM peculiarity. Not at all my area of expertise, so I'll leave it to others to suggest options. regards, Ben ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Database of emergency medicine physicians and many more specialties
Special Package for this week Board Certified Physicians in America 788,445 in total * 17,710 emails Many popular specialties like Emergency Medicine, Plastic Surgery, OBGYN, Oncology, Pediatrics and more 16 different sortable fields Pharmaceutical Companies in the USA Personal email addresses (47,000 in total) and names for top level executives Hospital Facilities in the United States Complete contact information for the important jobs held at the hospitals Complete and Accurate Database for Dental Service Providers A complete List or dentists and related services (valued at $399) Database of US Chiropractors Over than 100k chiropractors practicing in the United States This week's special price = $397 for all listed above send us an email: nes...@bestmarketlists.be Offer ENDS TODAY Forward email to e...@bestmarketlists.be to purge you from our records ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] help on a compiler error in include/asm/system.h
Hi u-boot experts,
Now our arm board is based on u-boot v2009.08 and I need to use
ubifs.
So I replace some files from u-boot's latest version.
They are:
fs/ubifs/ubifs.c
fs/ubifs/ubifs.h
include/asm-arm/bitops.h
include/linux/bitops.h
and define the following configs in config file:
#define CONFIG_CMD_UBI
#define CONFIG_CMD_UBIFS
#define CONFIG_RBTREE
#define CONFIG_LZO
When compiling, I encountered an error:
/opt/freescale/usr/local/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnuea
bi/bin/arm-none-linux-gnueabi-gcc -g -O0 -fno-strict-aliasing
-fno-common -ffixed-r8 -msoft-float -D__KERNEL__ -DTEXT_BASE=0x9780
-I/home/r65388/uboot-v2009.08/uboot-imx/include -fno-builtin
-ffreestanding -nostdinc -isystem
/opt/freescale/usr/local/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnuea
bi/lib/gcc/arm-none-linux-gnueabi/4.1.2/include -pipe -DCONFIG_ARM
-D__ARM__ -marm -mabi=aapcs-linux -mno-thumb-interwork -march=armv5
-Wall -Wstrict-prototypes -fno-stack-protector -o cpu.o cpu.c -c
In file included from cpu.c:36:
/home/r65388/uboot-v2009.08/uboot-imx/include/asm/system.h:71: error:
expected identifier or '(' before 'asm'
make[1]: *** [cpu.o] Error 1
make[1]: Leaving directory
`/home/r65388/uboot-v2009.08/uboot-imx/cpu/arm_cortexa8'
make: *** [cpu/arm_cortexa8/libarm_cortexa8.a] Error 2
Is there any other files I need to merge to resolve this error?
Thanks~~
Yours
Terry
General Business Information
Freescale Internal Use Only
Freescale Confidential Proprietary
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4 v5] DA8xx: Add MUSB host support
Remy,
-Original Message-
From: u-boot-boun...@lists.denx.de
[mailto:u-boot-boun...@lists.denx.de] On Behalf Of Gupta, Ajay Kumar
Sent: Tuesday, November 17, 2009 7:35 PM
To: u-boot@lists.denx.de
Subject: Re: [U-Boot] [PATCH 3/4 v5] DA8xx: Add MUSB host support
Remy,
Any comment on DA8xx USB support patches?
These patch set depends on DA8xx base support patches which
are available only on uboot-ti tree.
Any comment ?
Regards,
Ajay
Regards,
Ajay
-Original Message-
From: u-boot-boun...@lists.denx.de
[mailto:u-boot-boun...@lists.denx.de]
On Behalf Of Gupta, Ajay Kumar
Sent: Sunday, November 15, 2009 11:19 AM
To: u-boot@lists.denx.de
Subject: Re: [U-Boot] [PATCH 3/4 v5] DA8xx: Add MUSB host support
Hi,
Tested USB host functionality on DA830 EVM.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
Signed-off-by: Swaminathan S swami.i...@ti.com
---
drivers/usb/musb/Makefile |1 +
drivers/usb/musb/da8xx.c | 139
+
drivers/usb/musb/da8xx.h | 103
+
include/usb.h |3 +-
4 files changed, 245 insertions(+), 1 deletions(-) create mode
100644 drivers/usb/musb/da8xx.c create mode 100644
drivers/usb/musb/da8xx.h
diff --git a/drivers/usb/musb/Makefile
b/drivers/usb/musb/Makefile
index 09e0a5f..eb4d8fd 100644
--- a/drivers/usb/musb/Makefile
+++ b/drivers/usb/musb/Makefile
snip..
+
+ /* reset the controller */
+ writel(0x1, da8xx_usb_regs-control);
+ udelay(5000);
+
+ /* start the on-chip usb phy and its pll */
+ if (phy_on() == 0)
+ return -1;
+
+ /* Returns zero if e.g. not clocked */
+ revision = readl(da8xx_usb_regs-revision);
'' is missing, will resubmit the patch set.
Regards,
Ajay
+ if (revision == 0)
+ return -1;
+
+ /* Disable all interrupts */
+ writel((DA8XX_USB_USBINT_MASK | DA8XX_USB_TXINT_MASK |
+ DA8XX_USB_RXINT_MASK), da8xx_usb_regs-intmsk_set);
+ return 0;
+}
+
+/*
+ * This function performs DA8xx platform specific
deinitialization
+for
usb0.
+ */
+void musb_platform_deinit(void)
+{
+ /* Turn of the phy */
+ phy_off();
+
+ /* flush any interrupts */
+ writel((DA8XX_USB_USBINT_MASK | DA8XX_USB_TXINT_MASK |
+ DA8XX_USB_RXINT_MASK), da8xx_usb_regs-intmsk_clr);
+ writel(0, da8xx_usb_regs-eoi);
+}
diff --git a/drivers/usb/musb/da8xx.h
b/drivers/usb/musb/da8xx.h new
file mode 100644 index 000..93234f0
--- /dev/null
+++ b/drivers/usb/musb/da8xx.h
@@ -0,0 +1,103 @@
+/*
+ * da8xx.h -- TI's DA8xx platform specific usb wrapper
definitions.
+ *
+ * Author: Ajay Kumar Gupta ajay.gu...@ti.com
+ *
+ * Based on drivers/usb/musb/davinci.h
+ *
+ * Copyright (C) 2009 Texas Instruments Incorporated
+ *
+ * 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., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+#ifndef __DA8XX_MUSB_H__
+#define __DA8XX_MUSB_H__
+
+#include asm/arch/hardware.h
+#include asm/arch/gpio_defs.h
+#include musb_core.h
+
+/* Base address of da8xx usb0 wrapper */ #define
DA8XX_USB_OTG_BASE
+0x01E0
+
+/* Base address of da8xx musb core */ #define
+DA8XX_USB_OTG_CORE_BASE (DA8XX_USB_OTG_BASE + 0x400)
+
+/* Timeout for DA8xx usb module */
+#define DA8XX_USB_OTG_TIMEOUT 0x3FF
+
+/*
+ * DA8xx platform USB wrapper register overlay.
+ */
+struct da8xx_usb_regs {
+ dv_reg revision;
+ dv_reg control;
+ dv_reg status;
+ dv_reg emulation;
+ dv_reg mode;
+ dv_reg autoreq;
+ dv_reg srpfixtime;
+ dv_reg teardown;
+ dv_reg intsrc;
+ dv_reg intsrc_set;
+ dv_reg intsrc_clr;
+ dv_reg intmsk;
+ dv_reg intmsk_set;
+ dv_reg intmsk_clr;
+ dv_reg intsrcmsk;
+ dv_reg eoi;
+ dv_reg intvector;
+ dv_reg grndis_size[4];
+};
+
+#define da8xx_usb_regs ((struct da8xx_usb_regs
+*)DA8XX_USB_OTG_BASE)
+
+/* DA8XX interrupt bits definitions */
+#define DA8XX_USB_TX_ENDPTS_MASK 0x1f /* ep0 + 4 tx */
+#define DA8XX_USB_RX_ENDPTS_MASK 0x1e /* 4 rx */
+#define DA8XX_USB_TXINT_SHIFT
[U-Boot] mtest issue
Hello everyone, I have a LPC2468 board and currently play with u-boot. U-boot version is 1.1.6 from Embedded Artists. I've already made u-boot loading and executing user commands. Everything seems works fine, except the memory test (mtest) command: lpc-board# mtest Pattern Writing... Reading... Mem error @ 0xA075AB74: found A078, expected 001D6ADD Mem error @ 0xA075AB78: found 001D6ADD, expected 001D6ADE Pattern Writing... After the mtest started to check RAM with 0x pattern the system stops to respond. In case with CFG_ALT_MEMTEST defined mtest also fails with error: Testing a000 ... a078: Iteration: 1 FAILURE (read/write) @ 0xa075ab68: expected 0x001d6adb, actual 0xffe29525) You can see the ram dump made with md a075ab40 command: a075ab30: ffe29532 ffe29531 ffe29530 ffe2952f 2...1...0.../... a075ab40: a075ab68 a0788b64 a079ad7c a079ad7ch.u.d.x.|.y.|.y. a075ab50: 000d 000d a075ab68 a075ab74h.u.t.u. a075ab60: 0040 0040@...@... a075ab70: 0040 a079decc 0002 This segment of RAM (addresses from 0xa075ab40) seems already initialized and used somehow by u-boot. I've checked second board in the same way. The result is the same, so any hardware problems are excepted. The question is: what is it? Is it stack or something else? Should i pay attention on that or just don't mind. Is it possible to make mtest pass? As you may see, i'm totally new to u-boot and have no experience at all, that's why maybe my question will make you laugh. Anyway, could you please, help me to find the shortest way to fix this issue. Thank you for your time wasted on me, Alexey Goncharov, Russia ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Save environment data to mmc.
This patch is to save environment data to mmc card.
It uses interfaces defined in generic mmc.
Signed-off-by: Terry Lv r65...@freescale.com
---
common/Makefile |1 +
common/cmd_nvedit.c |3 +-
common/env_mmc.c | 166 +
include/environment.h | 18 +
lib_arm/board.c | 10 ++--
lib_ppc/board.c | 12 ++--
6 files changed, 198 insertions(+), 12 deletions(-)
create mode 100644 common/env_mmc.c
diff --git a/common/Makefile b/common/Makefile
index a92a75f..5f953b1 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -54,6 +54,7 @@ COBJS-$(CONFIG_ENV_IS_IN_EEPROM) += env_eeprom.o
COBJS-$(CONFIG_ENV_IS_EMBEDDED) += env_embedded.o
COBJS-$(CONFIG_ENV_IS_IN_FLASH) += env_flash.o
COBJS-$(CONFIG_ENV_IS_IN_MG_DISK) += env_mgdisk.o
+COBJS-$(CONFIG_ENV_IS_IN_MMC) += env_mmc.o
COBJS-$(CONFIG_ENV_IS_IN_NAND) += env_nand.o
COBJS-$(CONFIG_ENV_IS_IN_NVRAM) += env_nvram.o
COBJS-$(CONFIG_ENV_IS_IN_ONENAND) += env_onenand.o
diff --git a/common/cmd_nvedit.c b/common/cmd_nvedit.c
index 9f8d531..9168241 100644
--- a/common/cmd_nvedit.c
+++ b/common/cmd_nvedit.c
@@ -60,9 +60,10 @@ DECLARE_GLOBAL_DATA_PTR;
!defined(CONFIG_ENV_IS_IN_NVRAM)\
!defined(CONFIG_ENV_IS_IN_ONENAND) \
!defined(CONFIG_ENV_IS_IN_SPI_FLASH)\
+!defined(CONFIG_ENV_IS_IN_MMC) \
!defined(CONFIG_ENV_IS_NOWHERE)
# error Define one of CONFIG_ENV_IS_IN_{EEPROM|FLASH|DATAFLASH|ONENAND|\
-SPI_FLASH|MG_DISK|NVRAM|NOWHERE}
+SPI_FLASH|MG_DISK|NVRAM|MMC|NOWHERE}
#endif
#define XMK_STR(x) #x
diff --git a/common/env_mmc.c b/common/env_mmc.c
new file mode 100644
index 000..5742db0
--- /dev/null
+++ b/common/env_mmc.c
@@ -0,0 +1,166 @@
+/*
+ * (C) Copyright 2008-2009 Freescale Semiconductor, Inc.
+
+ * (C) Copyright 2000-2006
+ * Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+ *
+ * (C) Copyright 2001 Sysgo Real-Time Solutions, GmbH www.elinos.com
+ * Andreas Heppel ahep...@sysgo.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
+ */
+
+/* #define DEBUG */
+
+#include common.h
+
+#include command.h
+#include environment.h
+#include linux/stddef.h
+#include malloc.h
+#include mmc.h
+
+#if defined(CONFIG_CMD_ENV) defined(CONFIG_CMD_MMC)
+#define CMD_SAVEENV
+#elif defined(CONFIG_ENV_OFFSET_REDUND)
+#error Cannot use CONFIG_ENV_OFFSET_REDUND without CONFIG_CMD_ENV
CONFIG_CMD_MMC
+#endif
+
+#if defined(CONFIG_ENV_SIZE_REDUND) (CONFIG_ENV_SIZE_REDUND
CONFIG_ENV_SIZE)
+#error CONFIG_ENV_SIZE_REDUND should not be less then CONFIG_ENV_SIZE
+#endif
+
+/* references to names in env_common.c */
+extern uchar default_environment[];
+
+char *env_name_spec = MMC;
+
+#ifdef ENV_IS_EMBEDDED
+extern uchar environment[];
+env_t *env_ptr = (env_t *)(environment[0]);
+#else /* ! ENV_IS_EMBEDDED */
+env_t *env_ptr;
+#endif /* ENV_IS_EMBEDDED */
+
+/* local functions */
+#if !defined(ENV_IS_EMBEDDED)
+static void use_default(void);
+#endif
+
+DECLARE_GLOBAL_DATA_PTR;
+
+uchar env_get_char_spec(int index)
+{
+ return *((uchar *)(gd-env_addr + index));
+}
+
+int env_init(void)
+{
+ /* use default */
+ gd-env_addr = (ulong)default_environment[0];
+ gd-env_valid = 1;
+
+ return 0;
+}
+
+inline int init_mmc_for_env(struct mmc *mmc)
+{
+ if (!mmc) {
+ puts(No MMC card found\n);
+ return -1;
+ }
+
+ if (mmc_init(mmc)) {
+ puts(MMC init failed\n);
+ return -1;
+ }
+
+ return 0;
+}
+
+#ifdef CMD_SAVEENV
+
+inline int write_env(struct mmc *mmc, unsigned long size,
+ unsigned long offset, const
void *buffer)
+{
+ uint blk_start = 0, blk_cnt = 0, n = 0;
+
+ blk_start = (offset % 512) ? ((offset / 512) + 1) : (offset / 512);
+ blk_cnt = (size % 512) ? ((size / 512) + 1) : (size / 512);
+ n = mmc-block_dev.block_write(0, blk_start , blk_cnt, (u_char
*)buffer);
+
+ return (n == blk_cnt) ? 0 : -1;
+}
+
+int saveenv(void)
+{
+ struct mmc *mmc = find_mmc_device(0);
+
+ if (init_mmc_for_env(mmc))
+ return 1;
+
+ puts(Writing to MMC... );
+ if (write_env(mmc,
Re: [U-Boot] [PATCH V2 3/3] Add support for the LaCie ED Mini V2 board
Hi Albert, On Wednesday 18 November 2009 23:21:58 Wolfgang Denk wrote: This board is based on the Marvell Orion5x SoC. Current support is limited to console and Flash. Flash support uses LEGACY as the Macronix 29LV400 used on ED Mini V2 is not 100% CFI compliant. And the differences are really so big that we cannot tweak the CFI driver? It's not CFI compliant. But you can use the legacy infrastructure in this driver, which meant to support such chips. Please take a look at the following driver: drivers/mtd/jedec_flash.c Your board config header would need something like this: /* Use common CFI driver */ #define CONFIG_SYS_FLASH_CFI #define CONFIG_FLASH_CFI_DRIVER /* board provides its own flash_init code */ #define CONFIG_FLASH_CFI_LEGACY 1 #define CONFIG_SYS_FLASH_CFI_WIDTH FLASH_CFI_8BIT #define CONFIG_SYS_FLASH_LEGACY_512Kx8 1 ... Taken from include/configs/hcu4.h. This should give you an idea... Cheers, Stefan -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: off...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
