Re: [U-Boot] [PATCH RFC]: mmc: Add multi-block support
Hi Steve,
On Fri, Oct 15, 2010 at 6:12 AM, Steve Sakoman wrote:
> From: Alagu Sankar
>
> This patch adds multi-block read support for generic MMC. It also modifies
> existing multi-block write to limit the maximum number of blocks per transfer.
> A new member is added in the mmc structure for the host controller to specify
> the maximum number of blocks it supports.
>
> Signed-off-by: Alagu Sankar
> Acked-by: Steve Sakoman
> Tested-by: Steve Sakoman
> ---
>
> This is a re-submission of Alagu's patch, modified only to remove the CONFIG
> option as requested in the earlier discussion of the patch:
>
> http://www.mail-archive.com/u-boot@lists.denx.de/msg32319.html
>
> I tested the patch on OMAP3 and OMAP4 and found no issues. Sadly I did
> not see a performance improvement.
>
> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> index c543d83..55975bb 100644
> --- a/drivers/mmc/mmc.c
> +++ b/drivers/mmc/mmc.c
> @@ -77,26 +77,16 @@ struct mmc *find_mmc_device(int dev_num)
> return NULL;
> }
>
> -static ulong
> -mmc_bwrite(int dev_num, ulong start, lbaint_t blkcnt, const void*src)
> +static int mmc_write_blocks(struct mmc *mmc, const char *src, uint start,
> + uint blkcnt)
> {
> struct mmc_cmd cmd;
> struct mmc_data data;
> int err;
> - int stoperr = 0;
> - struct mmc *mmc = find_mmc_device(dev_num);
> int blklen;
>
> - if (!mmc)
> - return -1;
> -
> blklen = mmc->write_bl_len;
>
> - if ((start + blkcnt) > mmc->block_dev.lba) {
> - printf("MMC: block number 0x%lx exceeds max(0x%lx)",
> - start + blkcnt, mmc->block_dev.lba);
> - return 0;
> - }
You seems don't want this boudary check, but since it was merged as a
seperated patch
before, you should give your reason for remove this warning.
> err = mmc_set_blocklen(mmc, mmc->write_bl_len);
>
> if (err) {
> @@ -134,18 +124,46 @@ mmc_bwrite(int dev_num, ulong start, lbaint_t blkcnt,
> const void*src)
> cmd.cmdarg = 0;
> cmd.resp_type = MMC_RSP_R1b;
> cmd.flags = 0;
> - stoperr = mmc_send_cmd(mmc, &cmd, NULL);
> + err = mmc_send_cmd(mmc, &cmd, NULL);
> + }
> +
> + return err;
> +}
> +
> +static ulong
> +mmc_bwrite(int dev_num, ulong start, lbaint_t blkcnt, const void *src)
> +{
> + int err;
> + int i;
> + struct mmc *mmc = find_mmc_device(dev_num);
> + uint b_max = mmc->b_max;
> +
> + if (!mmc)
> + return 0;
> +
> + for (i = blkcnt; i > 0; i -= b_max) {
> + uint blocks = (i > b_max) ? b_max : i;
> +
> + err = mmc_write_blocks(mmc, src, start, blocks);
> + if (err)
> + return blkcnt - i;
> + start += blocks;
> + src += (mmc->write_bl_len * blocks);
> }
>
> return blkcnt;
> }
>
> -int mmc_read_block(struct mmc *mmc, void *dst, uint blocknum)
> +int mmc_read_blocks(struct mmc *mmc, void *dst, uint blocknum, uint blkcnt)
> {
> + int err;
> struct mmc_cmd cmd;
> struct mmc_data data;
>
> - cmd.cmdidx = MMC_CMD_READ_SINGLE_BLOCK;
> + if (blkcnt > 1)
> + cmd.cmdidx = MMC_CMD_READ_MULTIPLE_BLOCK;
> + else
> + cmd.cmdidx = MMC_CMD_READ_SINGLE_BLOCK;
>
> if (mmc->high_capacity)
> cmd.cmdarg = blocknum;
> @@ -156,62 +174,22 @@ int mmc_read_block(struct mmc *mmc, void *dst, uint
> blocknum)
> cmd.flags = 0;
>
> data.dest = dst;
> - data.blocks = 1;
> + data.blocks = blkcnt;
> data.blocksize = mmc->read_bl_len;
> data.flags = MMC_DATA_READ;
>
> - return mmc_send_cmd(mmc, &cmd, &data);
> -}
> -
> -int mmc_read(struct mmc *mmc, u64 src, uchar *dst, int size)
> -{
> - char *buffer;
> - int i;
> - int blklen = mmc->read_bl_len;
> - int startblock = lldiv(src, mmc->read_bl_len);
> - int endblock = lldiv(src + size - 1, mmc->read_bl_len);
> - int err = 0;
> -
> - /* Make a buffer big enough to hold all the blocks we might read */
> - buffer = malloc(blklen);
> -
> - if (!buffer) {
> - printf("Could not allocate buffer for MMC read!\n");
> - return -1;
> - }
> -
> - /* We always do full block reads from the card */
> - err = mmc_set_blocklen(mmc, mmc->read_bl_len);
> -
> + err = mmc_send_cmd(mmc, &cmd, &data);
> if (err)
> - goto free_buffer;
> -
> - for (i = startblock; i <= endblock; i++) {
> - int segment_size;
> - int offset;
> -
> - err = mmc_read_block(mmc, buffer, i);
> -
> - if (err)
> - goto free_buffer;
> -
> - /*
> - * The first block may not be aligned, so we
> - * copy from the d
[U-Boot] ¡Lee tu mensaje antes de que sea borrado!
¡Lee el mensaje de Ruan Pablo antes de que sea borrado! Para leer el mensaje, haz click en este link: http://us1.badoo.com/01125899210/in/YSBN7LxnooU/?lang_id=7 Más gente que también te está esperando: Juan Camilo (Manizales, Colombia) Antonya mamasita (Manizales, Colombia) Catalina (Manizales, Colombia) http://us1.badoo.com/01125899210/in/YSBN7LxnooU/?lang_id=7 Si al hacer click sobre el enlace, no funciona, copia y pega la dirección en tu barra del navegador. Este email es parte del sistema de envío de mensajes enviados por Ruan Pablo. Si has recibido este email por error, por favor, ignóralo. Será borrado de nuestro sistema en poco tiempo. ¡Diviértete! El Equipo de Badoo Has recibido este email porque un usuario de Badoo te ha dejado un mensaje en Badoo. Este mensaje es automático. Las respuestas a este mensaje no estan controladas y no serán contestadas. Si no quieres recibir más mensajes de Badoo, háznoslo saber: http://us1.badoo.com/impersonation.phtml?lang_id=7&mail_code=65&email=u-boot%40lists.denx.de&secret=&invite_id=229087&user_id=1125899210___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/3] at91rm9200ek: enbable USB support
This patch enables USB for at91rm9200ek board. Signed-off-by: Andreas Bießmann --- include/configs/at91rm9200ek.h | 15 +++ 1 files changed, 15 insertions(+), 0 deletions(-) diff --git a/include/configs/at91rm9200ek.h b/include/configs/at91rm9200ek.h index 8e9db92..d1565be 100644 --- a/include/configs/at91rm9200ek.h +++ b/include/configs/at91rm9200ek.h @@ -125,6 +125,7 @@ #define CONFIG_CMD_FAT #define CONFIG_CMD_MII #define CONFIG_CMD_PING +#define CONFIG_CMD_USB #undef CONFIG_CMD_FPGA #include /* needed for port definitions */ @@ -150,6 +151,20 @@ #define CONFIG_SYS_FLASH_PROTECTION /* + * USB Config + */ +#define CONFIG_USB_ATMEL 1 +#define CONFIG_USB_OHCI_NEW1 +#define CONFIG_USB_KEYBOARD1 +#define CONFIG_USB_STORAGE 1 +#define CONFIG_DOS_PARTITION 1 + +#define CONFIG_SYS_USB_OHCI_CPU_INIT 1 +#define CONFIG_SYS_USB_OHCI_REGS_BASE AT91_USB_HOST_BASE +#define CONFIG_SYS_USB_OHCI_SLOT_NAME "at91rm9200" +#define CONFIG_SYS_USB_OHCI_MAX_ROOT_PORTS 15 + +/* * Environment Settings */ #define CONFIG_ENV_IS_IN_FLASH 1 -- 1.7.3.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/3] at91rm9200: enable USB support
This patch fixes arch-at91/hardware.h to have the relevant defines for at91rm9200 devices to support existing at91 usb driver. Signed-off-by: Andreas Bießmann --- arch/arm/include/asm/arch-at91/hardware.h |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/include/asm/arch-at91/hardware.h b/arch/arm/include/asm/arch-at91/hardware.h index 9f732a7..f5f80e0 100644 --- a/arch/arm/include/asm/arch-at91/hardware.h +++ b/arch/arm/include/asm/arch-at91/hardware.h @@ -18,6 +18,7 @@ #if defined(CONFIG_AT91RM9200) #include +#define AT91_PMC_UHP AT91RM9200_PMC_UHP #elif defined(CONFIG_AT91SAM9260) || defined(CONFIG_AT91SAM9G20) #include #define AT91_BASE_MCI AT91SAM9260_BASE_MCI -- 1.7.3.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3] at91rm9200ek: convert to at91
This patch removes some functionality from at91rm9200ek board but the
remaining functionality does now work with newer at91 code and
arm-relocation.
Currently missing features are:
- dataflash booting (due to missing HW for testing)
- MMC/SD-Card
- first stage bootloader support is completely removed (not needed for
NOR)
Cause this board was (some days ago) reference for all at91rm9200 based
boards this should be a good starting point to convert all remaining
at91rm9200 borads to at91 code. Aside from that this is a good base to
get some drivers between at91sam/at91rm/avr32 merged.
Signed-off-by: Andreas Bießmann
---
MAINTAINERS |4 +
board/atmel/at91rm9200ek/Makefile |1 -
board/atmel/at91rm9200ek/at91rm9200ek.c | 58 +++--
board/atmel/at91rm9200ek/config.mk |3 +-
board/atmel/at91rm9200ek/led.c | 58
board/atmel/at91rm9200ek/misc.c | 50 ---
boards.cfg |2 +-
include/configs/at91rm9200ek.h | 222 ---
8 files changed, 104 insertions(+), 294 deletions(-)
delete mode 100644 board/atmel/at91rm9200ek/misc.c
diff --git a/MAINTAINERS b/MAINTAINERS
index aabd871..38a0dd3 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -568,6 +568,10 @@ Rishi Bhattacharya
omap5912osk ARM926EJS
+Andreas Bie�mann
+
+ at91rm9200ekat91rm9200
+
Cliff Brake
pxa255_idp xscale
diff --git a/board/atmel/at91rm9200ek/Makefile
b/board/atmel/at91rm9200ek/Makefile
index 500ce72..db54a32 100644
--- a/board/atmel/at91rm9200ek/Makefile
+++ b/board/atmel/at91rm9200ek/Makefile
@@ -27,7 +27,6 @@ LIB = $(obj)lib$(BOARD).a
COBJS-y += $(BOARD).o
COBJS-y += led.o
-COBJS-y += misc.o
ifdef CONFIG_HAS_DATAFLASH
COBJS-$(CONFIG_DATAFLASH_MMC_SELECT) += mux.o
COBJS-y += partition.o
diff --git a/board/atmel/at91rm9200ek/at91rm9200ek.c
b/board/atmel/at91rm9200ek/at91rm9200ek.c
index 570a09a..e30212c 100644
--- a/board/atmel/at91rm9200ek/at91rm9200ek.c
+++ b/board/atmel/at91rm9200ek/at91rm9200ek.c
@@ -1,4 +1,8 @@
/*
+ * (C) Copyright 2010 Andreas Bießmann
+ *
+ * derived from older work
+ *
* (C) Copyright 2002
* Sysgo Real-Time Solutions, GmbH
* Marius Groeger
@@ -25,76 +29,46 @@
#include
#include
#include
-#include
+#include
+#include
+#include
#include
-#if defined(CONFIG_DRIVER_ETHER)
-#include
-#include
-#endif
DECLARE_GLOBAL_DATA_PTR;
/* - */
-/*
- * Miscelaneous platform dependent initialisations
- */
-
int board_init (void)
{
+ at91_pio_t *pio = (at91_pio_t *)AT91_PIO_BASE;
+
/* Enable Ctrlc */
- console_init_f ();
+ console_init_f();
/*
* Correct IRDA resistor problem
* Set PA23_TXD in Output
*/
- writel(AT91C_PA23_TXD2, ((AT91PS_PIO) AT91C_BASE_PIOA)->PIO_OER);
-
- /*
-* memory and cpu-speed are setup before relocation
-* so we do _nothing_ here
-*/
+ writel(AT91_PMX_AA_TXD2, &pio->pioa.oer);
/* arch number of AT91RM9200EK-Board */
gd->bd->bi_arch_number = MACH_TYPE_AT91RM9200EK;
/* adress of boot parameters */
- gd->bd->bi_boot_params = PHYS_SDRAM + 0x100;
+ gd->bd->bi_boot_params = CONFIG_SYS_SDRAM_BASE + 0x100;
return 0;
}
int dram_init (void)
{
- gd->bd->bi_dram[0].start = PHYS_SDRAM;
- gd->bd->bi_dram[0].size = PHYS_SDRAM_SIZE;
+ /* dram_init must store complete ramsize in gd->ram_size */
+ gd->ram_size = get_ram_size((volatile long *)CONFIG_SYS_SDRAM_BASE,
+ CONFIG_SYS_SDRAM_SIZE);
return 0;
}
-#if defined(CONFIG_DRIVER_ETHER) && defined(CONFIG_CMD_NET)
-/*
- * Name:
- * at91rm9200_GetPhyInterface
- * Description:
- * Initialise the interface functions to the PHY
- * Arguments:
- * None
- * Return value:
- * None
- */
-void at91rm9200_GetPhyInterface(AT91PS_PhyOps p_phyops)
-{
- p_phyops->Init = dm9161_InitPhy;
- p_phyops->IsPhyConnected = dm9161_IsPhyConnected;
- p_phyops->GetLinkSpeed = dm9161_GetLinkSpeed;
- p_phyops->AutoNegotiate = dm9161_AutoNegotiate;
-}
-#endif
-
#ifdef CONFIG_DRIVER_AT91EMAC
int board_eth_init(bd_t *bis)
{
- int rc = 0;
- rc = at91emac_register(bis, 0);
- return rc;
+ return at91emac_register(bis, (u32) AT91_EMAC_BASE);
}
#endif
diff --git a/board/atmel/at91rm9200ek/config.mk
b/board/atmel/at91rm9200ek/config.mk
index 9ce161e..7b99e02 100644
--- a/board/atmel/at91rm9200ek/config.mk
+++ b/board/atmel/at91rm9200ek/config.mk
@@ -1 +1,2 @@
-TEXT_BASE = 0x21f0
+# currently only NOR flash booting is supported
+TEXT_BASE = 0x1000
diff --git a/board/atmel/at91rm9200ek/led.c b/board/atmel/at91rm9200ek/led.c
index 9464952..8d512e0 100644
--- a/board/atmel/at91rm9200ek/led.c
+++ b/board/atmel/at91rm9200ek/led.c
@@ -3,
[U-Boot] [PATCH 0/3] new BSP for at91rm9200ek
This patch series introduce new board support for at91rm9200ek. The derived code is now converted to new at91 code. Arm relocation is also implemented. There where some tradeoffs regarding device support. Currently the code basis does not support all devices supported before. This includes a) remove support for dataflash since i can not test it (yet, should follow in some weeks) b) preloader support is disabled since NOR booting does not need any first stage loader c) MMC/SD-card is currently not supported (but was not before) Next steps are: - get dataflash running - remove at91rm9200_usart driver (should merge with atmel_usart) - support MMC/SD-Card (also merge with current AT91/AVR32 implementation) - merge emac/macb Andreas Bießmann (3): at91rm9200ek: convert to at91 at91rm9200: enable USB support at91rm9200ek: enbable USB support MAINTAINERS |4 + arch/arm/include/asm/arch-at91/hardware.h |1 + board/atmel/at91rm9200ek/Makefile |1 - board/atmel/at91rm9200ek/at91rm9200ek.c | 58 ++- board/atmel/at91rm9200ek/config.mk|3 +- board/atmel/at91rm9200ek/led.c| 58 board/atmel/at91rm9200ek/misc.c | 50 -- boards.cfg|2 +- include/configs/at91rm9200ek.h| 233 - 9 files changed, 118 insertions(+), 292 deletions(-) delete mode 100644 board/atmel/at91rm9200ek/misc.c -- 1.7.3.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Add sys_proto.h for arch-armv7
Signed-off-by: Alexey Zaytsev --- Hi. U-boot won't build for Versatile Express (ca9x4_ct_vxp) without this patch. I'm not sure why the syslib is made armv7-specific, as it looks quite generic to me, but I'll leave this to the original authors. arch/arm/include/asm/arch-armv7/sys_proto.h | 31 +++ 1 files changed, 31 insertions(+), 0 deletions(-) diff --git a/arch/arm/include/asm/arch-armv7/sys_proto.h b/arch/arm/include/asm/arch-armv7/sys_proto.h index e69de29..d3a7b47 100644 --- a/arch/arm/include/asm/arch-armv7/sys_proto.h +++ b/arch/arm/include/asm/arch-armv7/sys_proto.h @@ -0,0 +1,31 @@ +/* + * (C) Copyright 2008 + * Texas Instruments, + * + * Richard Woodruff + * Syed Mohammed Khasim + * + * 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 + */ + +#ifndef _SYS_PROTO_H_ +#define _SYS_PROTO_H_ + +void sr32(void *, u32, u32, u32); +u32 wait_on_value(u32, u32, void *, u32); +void sdelay(unsigned long); + +#endif ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mtdparts: Call nand_init() during mtdparts_init().
On Sat, 16 Oct 2010 00:48:11 +0200 Wolfgang Denk wrote: > Dear Scott Wood, > > In message <20101015173533.4e1d8...@udp111988uds.am.freescale.net> you wrote: > > > > > This looks like a broken design to me. > > > > What would you rather see in its place? > > Good question. I have to admit that I don't know all this code and > it's embroilments too well. There is this with MTD and that without, > there is this for JFFS2 and that without. I lost track in that maze > long ago. > > Eventually we should have some mtd_init() call which does this, OK, so replace the nand_init() with a call to a new mtd_init(), that currently just calls nand_init()? The parts that access nand_info[] directly rather than using the MTD interface would use nand_init() directly. > but then, I'm not sure if there might not be a case ot mtdparts without > MTD. There's an existing dependency there -- if that dependency is conditionalized/removed in the future, then doing the same to its call to mtd_init() would be part of that. > > > Assume we add this call here; would it then not also be needed in the > > > 'static' version of mtdparts_init() in "common/cmd_jffs2.c" (whatever > > > 'static' is supposed to mean) ? > > > > Yes, it seems so. Is there a good reason why jffs2 has its own > > implementation of this stuff? > > Too many people working on differnt parts of the code, without > looking over their respective rims ? Sorry, I never understood. > I think Stefan spent already some time to clean up parts of the mess, > but this probably needs more effort. > > > yaffs_StartUp is in a similar situation. > > Oh dear. It doesn't come to an end. Some grepping turns up omap_nand_switch_ecc, and lcd_show_board_info in a few boards -- but I think that's it. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mtdparts: Call nand_init() during mtdparts_init().
Dear Scott Wood, In message <20101015173533.4e1d8...@udp111988uds.am.freescale.net> you wrote: > > > This looks like a broken design to me. > > What would you rather see in its place? Good question. I have to admit that I don't know all this code and it's embroilments too well. There is this with MTD and that without, there is this for JFFS2 and that without. I lost track in that maze long ago. Eventually we should have some mtd_init() call which does this, but then, I'm not sure if there might not be a case ot mtdparts without MTD. > > Assume we add this call here; would it then not also be needed in the > > 'static' version of mtdparts_init() in "common/cmd_jffs2.c" (whatever > > 'static' is supposed to mean) ? > > Yes, it seems so. Is there a good reason why jffs2 has its own > implementation of this stuff? Too many people working on differnt parts of the code, without looking over their respective rims ? Sorry, I never understood. I think Stefan spent already some time to clean up parts of the mess, but this probably needs more effort. > yaffs_StartUp is in a similar situation. Oh dear. It doesn't come to an end. 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 What is wanted is not the will to believe, but the will to find out, which is the exact opposite. -- Bertrand Russell, "Skeptical Essays", 1928 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mtdparts: Call nand_init() during mtdparts_init().
On Sat, 16 Oct 2010 00:17:01 +0200 Wolfgang Denk wrote: > Dear Scott Wood, > > In message <20101015164801.3fd03...@udp111988uds.am.freescale.net> you wrote: > > > > > Why do we need an explicit call to nand_init() at all? > > > > > > Why cannot the NAND routines check internally if they have been > > > initialized yet, and run nand_init() if and when needed? > > > > mtdparts doesn't make any calls directly to NAND routines (other than > > this new call to nand_init). It looks for registered MTD devices. > > > > Until nand_init runs, you won't have any NAND mtd devices -- and no > > NAND function will be invoked where such initialization could be done. > > This looks like a broken design to me. What would you rather see in its place? > Assume we add this call here; would it then not also be needed in the > 'static' version of mtdparts_init() in "common/cmd_jffs2.c" (whatever > 'static' is supposed to mean) ? Yes, it seems so. Is there a good reason why jffs2 has its own implementation of this stuff? yaffs_StartUp is in a similar situation. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mtdparts: Call nand_init() during mtdparts_init().
Dear Scott Wood, In message <20101015164801.3fd03...@udp111988uds.am.freescale.net> you wrote: > > > > it makes more sense to me to hide this in the header (which Scott has > > > done)> > > > and let the compiler/code optimize dead crap away. > > > > Why do we need an explicit call to nand_init() at all? > > > > Why cannot the NAND routines check internally if they have been > > initialized yet, and run nand_init() if and when needed? > > mtdparts doesn't make any calls directly to NAND routines (other than > this new call to nand_init). It looks for registered MTD devices. > > Until nand_init runs, you won't have any NAND mtd devices -- and no > NAND function will be invoked where such initialization could be done. This looks like a broken design to me. Assume we add this call here; would it then not also be needed in the 'static' version of mtdparts_init() in "common/cmd_jffs2.c" (whatever 'static' is supposed to mean) ? 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 In the realm of scientific observation, luck is granted only to those who are prepared. - Louis Pasteur ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mtdparts: Call nand_init() during mtdparts_init().
On Fri, 15 Oct 2010 23:39:52 +0200 Wolfgang Denk wrote: > Dear Mike Frysinger, > > > it makes more sense to me to hide this in the header (which Scott has > > done)> > > and let the compiler/code optimize dead crap away. > > Why do we need an explicit call to nand_init() at all? > > Why cannot the NAND routines check internally if they have been > initialized yet, and run nand_init() if and when needed? mtdparts doesn't make any calls directly to NAND routines (other than this new call to nand_init). It looks for registered MTD devices. Until nand_init runs, you won't have any NAND mtd devices -- and no NAND function will be invoked where such initialization could be done. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mtdparts: Call nand_init() during mtdparts_init().
Dear Mike Frysinger, In message <201010151608.30637.vap...@gentoo.org> you wrote: > > > > @@ -1711,6 +1707,7 @@ int mtdparts_init(void) > > > memset(last_ids, 0, MTDIDS_MAXLEN); > > > memset(last_parts, 0, MTDPARTS_MAXLEN); > > > memset(last_partition, 0, PARTITION_MAXLEN); > > > > > > + nand_init(); > > > initialized = 1; > > > } > > > > I don't like this either. I don't want to see a nand_init() for > > systems that have no NAND at all (not even an empty one). > > i disagree ... sprinkling #ifdef's throughout the code makes it a lot harder > to read, maintain, and validate across multiple configurations. you're > suggesting we do: > #ifdef CONFIG_CMD_NAND > nand_init(); > #endif No, I'm not. I did not suggest anything like that. > it makes more sense to me to hide this in the header (which Scott has done)> > and let the compiler/code optimize dead crap away. Why do we need an explicit call to nand_init() at all? Why cannot the NAND routines check internally if they have been initialized yet, and run nand_init() if and when needed? 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 use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense. - E. W. Dijkstra ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [Patch v3] Add support for HP Jornada flashrom boards
This patch adds support for the HP Jornada flashboards
that were made in 2008. Older flashroms should work if
memory registers are adjusted.
Signed-off-by: Kristoffer Ericson
---
Changes for v2:
- Adding myself to MAINTAINERS
- Fixing line lengths
- Fixing comment style
Changes for v3:
- setting MACH_TYPE_JORNADA720
- CONFIG_SYS_HZ = 1000
MAINTAINERS |4 +
board/jornada/Makefile| 53 +++
board/jornada/config.mk |6 ++
board/jornada/jornada.c | 65 ++
board/jornada/setup.S | 210 +
board/jornada/u-boot.lds | 58 +
boards.cfg|1 +
include/configs/jornada.h | 153 +
8 files changed, 550 insertions(+), 0 deletions(-)
create mode 100644 board/jornada/Makefile
create mode 100644 board/jornada/config.mk
create mode 100644 board/jornada/jornada.c
create mode 100644 board/jornada/setup.S
create mode 100644 board/jornada/u-boot.lds
create mode 100644 include/configs/jornada.h
diff --git a/MAINTAINERS b/MAINTAINERS
index aabd871..3eecf79 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -593,6 +593,10 @@ Thomas Elste
modnet50ARM720T (NET+50)
+Kristoffer Ericson
+
+ jornada SA1110
+
Fabio Estevam
mx31pdk i.MX31
diff --git a/board/jornada/Makefile b/board/jornada/Makefile
new file mode 100644
index 000..1b4e192
--- /dev/null
+++ b/board/jornada/Makefile
@@ -0,0 +1,53 @@
+#
+# (C) Copyright 2000-2006
+# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+#
+# 2004 (c) MontaVista Software, Inc.
+#
+# 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 := jornada.o
+SOBJS := setup.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/jornada/config.mk b/board/jornada/config.mk
new file mode 100644
index 000..59968aa
--- /dev/null
+++ b/board/jornada/config.mk
@@ -0,0 +1,6 @@
+#
+# SA-1110 based HP Jornada Flashrom
+#
+# We got 2 x 16 Intel SDRAM in total 128MB
+#
+TEXT_BASE = 0xc1f0
diff --git a/board/jornada/jornada.c b/board/jornada/jornada.c
new file mode 100644
index 000..79d64a4
--- /dev/null
+++ b/board/jornada/jornada.c
@@ -0,0 +1,65 @@
+/*
+ * (C) Copyright 2002
+ * Sysgo Real-Time Solutions, GmbH
+ * Marius Groeger
+ *
+ * 2004 (c) MontaVista Software, Inc.
+ *
+ * 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
+#include
+
+DECLARE_GLOBAL_DATA_PTR;
+
+/* - */
+
+static void jornada_init(void)
+{
+
+}
+
+int board_init(void)
+{
+ gd->bd->bi_arch_number = MACH_TYPE_JORNADA720;
+ gd->bd->bi_boot_params = 0xc100;
+
+
+ /*
+* Turn on flashing.
+* Would be nice to have some protection but
+* that would have to be implemented in the
Re: [U-Boot] [PATCH] mtdparts: Call nand_init() during mtdparts_init().
On Friday, October 15, 2010 15:36:40 Wolfgang Denk wrote: > Scott Wood wrote: > > The mtdparts code depends on the devices referred to by > > partition specs actually existing, both for error checking, > > when the spread feature is used, for bad block checking. > > > > @@ -1711,6 +1707,7 @@ int mtdparts_init(void) > > memset(last_ids, 0, MTDIDS_MAXLEN); > > memset(last_parts, 0, MTDPARTS_MAXLEN); > > memset(last_partition, 0, PARTITION_MAXLEN); > > > > + nand_init(); > > initialized = 1; > > } > > I don't like this either. I don't want to see a nand_init() for > systems that have no NAND at all (not even an empty one). i disagree ... sprinkling #ifdef's throughout the code makes it a lot harder to read, maintain, and validate across multiple configurations. you're suggesting we do: #ifdef CONFIG_CMD_NAND nand_init(); #endif it makes more sense to me to hide this in the header (which Scott has done) and let the compiler/code optimize dead crap away. -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 RFC] ARMV7: OMAP: I2C driver: Reduce excessively long udelay calls
On Fri, 2010-10-15 at 21:27 +0200, Wolfgang Denk wrote: > Dear Steve Sakoman, > > In message <1287158873.7756.66.ca...@quadra> you wrote: > > I've been preparing a patch series for Beagle and Overo that detects > > expansion > > board configuration information by reading a 128 byte I2C EEPROM on each > > expansion board. > > > > Using the OMAP I2C driver in its current form takes about 5-6 seconds to > > read > > this small number of bytes! > > > > Examining the code I see that there are a large number of fairly long > > udelay calls > > throughout the driver (10 - 50 milliseconds). I looked through the linux > > driver > > and did not see equivalent delays in that code. In fact the longest delay > > in the > > linux code was one millisecond. > > Eventually the long delays are needed to make the code work stable > even under rare conditions, which don't happen to often. But this may > be caused by the way the code is written, too... > My feeling is that this driver needs a more thorough rework. Unfortunately I am inclined to agree with you! I'll start work on that. Steve ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mtdparts: Call nand_init() during mtdparts_init().
On Fri, 15 Oct 2010 21:36:40 +0200 Wolfgang Denk wrote: > Dear Scott Wood, > > In message <20101015185902.ga7...@udp111988uds.am.freescale.net> you wrote: > > The mtdparts code depends on the devices referred to by > > partition specs actually existing, both for error checking, > > when the spread feature is used, for bad block checking. > > > > Signed-off-by: Scott Wood > > --- > > common/cmd_mtdparts.c |5 + > > include/nand.h|6 ++ > > 2 files changed, 7 insertions(+), 4 deletions(-) > > > > Applied to u-boot-nand-flash > > > > diff --git a/common/cmd_mtdparts.c b/common/cmd_mtdparts.c > > index 5481c88..8e8ba47 100644 > > --- a/common/cmd_mtdparts.c > > +++ b/common/cmd_mtdparts.c > > @@ -96,15 +96,11 @@ > > #include > > #include > > > > -#if defined(CONFIG_CMD_NAND) > > #include > > #include > > -#endif > > > > -#if defined(CONFIG_CMD_ONENAND) > > #include > > #include > > -#endif > > I don't like this. We should include this stuff only on systems that > really need it. Since when do we ifdef headers? > > /* special size referring to all the remaining space in a partition */ > > #define SIZE_REMAINING 0x > > @@ -1711,6 +1707,7 @@ int mtdparts_init(void) > > memset(last_ids, 0, MTDIDS_MAXLEN); > > memset(last_parts, 0, MTDPARTS_MAXLEN); > > memset(last_partition, 0, PARTITION_MAXLEN); > > + nand_init(); > > initialized = 1; > > } > > I don't like this either. I don't want to see a nand_init() for > systems that have no NAND at all (not even an empty one). What would you suggest instead? -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mtdparts: Call nand_init() during mtdparts_init().
Dear Scott Wood, In message <20101015185902.ga7...@udp111988uds.am.freescale.net> you wrote: > The mtdparts code depends on the devices referred to by > partition specs actually existing, both for error checking, > when the spread feature is used, for bad block checking. > > Signed-off-by: Scott Wood > --- > common/cmd_mtdparts.c |5 + > include/nand.h|6 ++ > 2 files changed, 7 insertions(+), 4 deletions(-) > > Applied to u-boot-nand-flash > > diff --git a/common/cmd_mtdparts.c b/common/cmd_mtdparts.c > index 5481c88..8e8ba47 100644 > --- a/common/cmd_mtdparts.c > +++ b/common/cmd_mtdparts.c > @@ -96,15 +96,11 @@ > #include > #include > > -#if defined(CONFIG_CMD_NAND) > #include > #include > -#endif > > -#if defined(CONFIG_CMD_ONENAND) > #include > #include > -#endif I don't like this. We should include this stuff only on systems that really need it. > /* special size referring to all the remaining space in a partition */ > #define SIZE_REMAINING 0x > @@ -1711,6 +1707,7 @@ int mtdparts_init(void) > memset(last_ids, 0, MTDIDS_MAXLEN); > memset(last_parts, 0, MTDPARTS_MAXLEN); > memset(last_partition, 0, PARTITION_MAXLEN); > + nand_init(); > initialized = 1; > } I don't like this either. I don't want to see a nand_init() for systems that have no NAND at all (not even an empty one). Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de "If you can, help others. If you can't, at least don't hurt others." - the Dalai Lama ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] Ensure gd->ram_size end stays on 4k page boundary when 'hiding' RAM
Dear Gray Remlin, In message <4cb8a35a.7020...@rocketmail.com> you wrote: > Signed-off-by: Gray Remlin > --- > arch/arm/lib/board.c |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c > index 22bd2c9..2f0d5c4 100644 > --- a/arch/arm/lib/board.c > +++ b/arch/arm/lib/board.c > @@ -532,7 +532,7 @@ void board_init_f (ulong bootflag) > * memory size from the SDRAM controller setup will have to > * get fixed. > */ > - gd->ram_size -= CONFIG_SYS_MEM_TOP_HIDE; > + gd->ram_size -= roundup(CONFIG_SYS_MEM_TOP_HIDE, 4096); > #endif > > addr = CONFIG_SYS_SDRAM_BASE + gd->ram_size; If such a change gets implemented, it should be implemented for PowerPC as well, plus the description in the README should be adjusted. On the other hand, I can see no really good reason to implement such a fix, as the description in the README is precise enough about this item, and there is no good reason to assume that this feature would ever be enabled on any other systems but those with this specific PowerPC processor. I recommend to just drop this patch. 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 365 Days of drinking Lo-Cal beer. = 1 Lite-year ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH RFC] ARMV7: OMAP: I2C driver: Reduce excessively long udelay calls
Dear Steve Sakoman,
In message <1287158873.7756.66.ca...@quadra> you wrote:
> I've been preparing a patch series for Beagle and Overo that detects expansion
> board configuration information by reading a 128 byte I2C EEPROM on each
> expansion board.
>
> Using the OMAP I2C driver in its current form takes about 5-6 seconds to read
> this small number of bytes!
>
> Examining the code I see that there are a large number of fairly long udelay
> calls
> throughout the driver (10 - 50 milliseconds). I looked through the linux
> driver
> and did not see equivalent delays in that code. In fact the longest delay in
> the
> linux code was one millisecond.
Eventually the long delays are needed to make the code work stable
even under rare conditions, which don't happen to often. But this may
be caused by the way the code is written, too...
> if (readw (&i2c_base->con) & I2C_CON_EN) {
> writew (0, &i2c_base->con);
> - udelay (5);
> + udelay (1000);
> }
Instead of a simple writew() followed by an eventually long delay it
might make more sense to wait in a (tight) loop for the intended
condition; in this case it looks as if the I2C_CON_EN bit should be
reset (plus some other bits?), so why not wait for it?
For example:
tout = 1000;
while ((tout > 0) && (readw (&i2c_base->con) & I2C_CON_EN)) {
writew(0, &i2c_base->con);
udelay (50);
}
if (!tout)
error handling;
So if the hardware is really slow to respond you still get the fill 50
ms timeout that you had before, but if it's much faster in the regular
case - and you even get a chance to notify the user in case of errors.
[Not sure if the multiple writew() are ok here, but you get the idea.]
> writew(0x2, &i2c_base->sysc); /* for ES2 after soft reset */
> @@ -164,7 +164,7 @@ static int i2c_read_byte (u8 devaddr, u8 regoffset, u8 *
> value)
> if (status & I2C_STAT_XRDY) {
> /* Important: have to use byte access */
> writeb (regoffset, &i2c_base->data);
> - udelay (2);
> + udelay (1000);
> if (readw (&i2c_base->stat) & I2C_STAT_NACK) {
> i2c_error = 1;
> }
Here the harrdware spec should give an indication how quickly the NAK
can be read reliably.
> @@ -176,7 +176,7 @@ static int i2c_read_byte (u8 devaddr, u8 regoffset, u8 *
> value)
> writew (I2C_CON_EN, &i2c_base->con);
> while (readw(&i2c_base->stat) &
> (I2C_STAT_XRDY | I2C_STAT_ARDY)) {
> - udelay (1);
> + udelay (1000);
> /* Have to clear pending interrupt to clear I2C_STAT */
> writew (0x, &i2c_base->stat);
> }
Here I cannot think of good reasons for such a delay at all.
What does the spec say?
> @@ -206,7 +206,7 @@ static int i2c_read_byte (u8 devaddr, u8 regoffset, u8 *
> value)
> writew (I2C_CON_EN, &i2c_base->con);
> while (readw (&i2c_base->stat) &
> (I2C_STAT_RRDY | I2C_STAT_ARDY)) {
> - udelay (1);
> + udelay (1000);
> writew (0x, &i2c_base->stat);
> }
> }
Here we are in a loop anyway - use a much shrter cycle length combined
with a limit on the max number of cycles.
Etc.
My feeling is that this driver needs a more thorough rework.
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
Winners never talk about glorious victories. That's because they're
the ones who see what the battlefield looks like afterwards. It's
only the losers who have glorious victories.
- Terry Pratchett, _Small Gods_
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Pull request u-boot-blackfin.git
The following changes since commit e79f48393dd919079b34f37957c933f8e75c164d: env_mmc: fix cannot save env issue (2010-10-13 22:02:32 +0200) are available in the git repository at: git://www.denx.de/git/u-boot-blackfin.git master Mike Frysinger (2): Blackfin: update anomaly lists to latest sheets Blackfin: workaround anomaly 05000440 arch/blackfin/cpu/initcode.c |6 +- arch/blackfin/include/asm/mach-bf518/anomaly.h |2 ++ arch/blackfin/include/asm/mach-bf527/anomaly.h |4 +++- arch/blackfin/include/asm/mach-bf533/anomaly.h |7 ++- arch/blackfin/include/asm/mach-bf537/anomaly.h |7 ++- arch/blackfin/include/asm/mach-bf538/anomaly.h |7 +-- arch/blackfin/include/asm/mach-bf548/anomaly.h |7 --- arch/blackfin/include/asm/mach-bf561/anomaly.h | 11 +-- 8 files changed, 40 insertions(+), 11 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 1/1] IMX: rename mx51 to mx5
Dear Jason Liu, In message <1287155158-16801-1-git-send-email-r64...@freescale.com> you wrote: ... > - freq = decode_pll(mxc_plls[PLL1_CLOCK], CONFIG_MX51_HCLK_FREQ); > + freq = decode_pll(mxc_plls[PLL1_CLOCK], CONFIG_HCLK_FREQ); ... > - clockinfo, CONFIG_SYS_MAXARGS, 1, do_mx51_showclocks, > - "display mx51 clocks\n", > + clockinfo, CONFIG_SYS_MAXARGS, 1, do_showclocks, > + "display clocks\n", ... > - lastinc = val / (CONFIG_MX51_CLK32 / CONFIG_SYS_HZ); > + lastinc = val / (CONFIG_CLK32 / CONFIG_SYS_HZ); I'm not happy about these changes. The old names, containing "MX51" may have been too narrow in their naming; but the new names are now way too general. "CONFIG_CLK32" or "CONFIG_HCLK_FREQ" look like generic config options that apply to any processor or board, or at least potentially to a wider range. This is kind of name space pollution. I understand that all these names are specific to the mx5 family of processors only, right? Recent submissions to the Linux kernel seem to use a "MX5" string when referring to these processors, like in: - commit messages: ARM: mx5: Add Nand clock support ARM: mx5: dynamically register mxc-nand device ARM: mx5: dynamically register imx-i2c devices - directory names: arch/arm/mach-mx5/ - preprocessor variables: MX5_USBOTHER_REGS_OFFSET MX5_USB_UTMI_PHYCTRL1_PLLDIV_MASK etc. I suggest we do the same. Please add a "mx5" resp. "MX5" to the new identifier names. Please also keep in mind that CONFIG_* options should be documented in the README. Thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de "May your future be limited only by your dreams." - Christa McAuliffe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3 v2] nand: allow demand initialization
On Friday, October 15, 2010 14:56:36 Scott Wood wrote: > Applied to u-boot-nand-flash. awesome > Changed commit message to the one from v1, as this appears to be an > accidental duplication of patch 2/3's commit message. you're right of course ... not sure how i screwed that up. looking at my local git tree, both changesets have the right changes<->commit msg. -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3 v2] nand: introduce CONFIG_NAND_EARLY_INIT and nand_early_init()
On Tue, Oct 12, 2010 at 03:35:32PM -0400, Mike Frysinger wrote: > Add new config options to allow people to control early initialization > of NAND. The current behavior (NAND is initialized early) is unchanged, > but now people may choose to disable this behavior and only initialize > NAND when it would actually be used. > > So that we can change the default in the future to not initialize NAND > early on, we also introduce a CONFIG_MAYBE_NAND_EARLY_INIT option. If > board porters do not make a choice either way, they will get a build > warning. This should encourage board porters to opt in to one of the > two choices by themselves. After a release or two, we can then force > the remaining boards to enable the new config option, delete the compat > option, and have the default behavior match the standard U-Boot policy. > > Signed-off-by: Mike Frysinger > --- > v2 > - appease useless checkpatch warnings > > arch/arm/lib/board.c |5 + > arch/blackfin/lib/board.c| 10 ++ > arch/m68k/lib/board.c|6 +++--- > arch/mips/lib/board.c|5 + > arch/nios2/lib/board.c |9 ++--- > arch/powerpc/lib/board.c |6 +++--- > arch/sh/lib/board.c |3 ++- > doc/feature-removal-schedule.txt | 20 > drivers/mtd/nand/nand.c |4 > include/config_defaults.h|2 ++ > include/nand.h |5 + > 11 files changed, 45 insertions(+), 30 deletions(-) Applied to u-boot-nand-flash. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mtdparts: Call nand_init() during mtdparts_init().
The mtdparts code depends on the devices referred to by
partition specs actually existing, both for error checking,
when the spread feature is used, for bad block checking.
Signed-off-by: Scott Wood
---
common/cmd_mtdparts.c |5 +
include/nand.h|6 ++
2 files changed, 7 insertions(+), 4 deletions(-)
Applied to u-boot-nand-flash
diff --git a/common/cmd_mtdparts.c b/common/cmd_mtdparts.c
index 5481c88..8e8ba47 100644
--- a/common/cmd_mtdparts.c
+++ b/common/cmd_mtdparts.c
@@ -96,15 +96,11 @@
#include
#include
-#if defined(CONFIG_CMD_NAND)
#include
#include
-#endif
-#if defined(CONFIG_CMD_ONENAND)
#include
#include
-#endif
/* special size referring to all the remaining space in a partition */
#define SIZE_REMAINING 0x
@@ -1711,6 +1707,7 @@ int mtdparts_init(void)
memset(last_ids, 0, MTDIDS_MAXLEN);
memset(last_parts, 0, MTDPARTS_MAXLEN);
memset(last_partition, 0, PARTITION_MAXLEN);
+ nand_init();
initialized = 1;
}
diff --git a/include/nand.h b/include/nand.h
index a452411..5ced821 100644
--- a/include/nand.h
+++ b/include/nand.h
@@ -24,7 +24,13 @@
#ifndef _NAND_H_
#define _NAND_H_
+#ifdef CONFIG_CMD_NAND
extern void nand_init(void);
+#else
+static inline void nand_init(void)
+{
+}
+#endif
#include
#include
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3 v2] nand: allow demand initialization
On Tue, Oct 12, 2010 at 03:35:15PM -0400, Mike Frysinger wrote: > Add new config options to allow people to control early initialization > of NAND. The current behavior (NAND is initialized early) is unchanged, > but now people may choose to disable this behavior and only initialize > NAND when it would actually be used. > > So that we can change the default in the future to not initialize NAND > early on, we also introduce a CONFIG_MAYBE_NAND_EARLY_INIT option. If > board porters do not make a choice either way, they will get a build > warning. This should encourage board porters to opt in to one of the > two choices by themselves. After a release or two, we can then force > the remaining boards to enable the new config option, delete the compat > option, and have the default behavior match the standard U-Boot policy. > > Signed-off-by: Mike Frysinger > --- > v2 > - call nand_init() in do_nandboot() too > > common/cmd_nand.c |6 ++ > common/env_nand.c |8 > drivers/mtd/nand/nand.c |7 +++ > 3 files changed, 21 insertions(+), 0 deletions(-) Applied to u-boot-nand-flash. Changed commit message to the one from v1, as this appears to be an accidental duplication of patch 2/3's commit message. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] Ensure gd->ram_size end stays on 4k page boundary when 'hiding' RAM
Signed-off-by: Gray Remlin --- arch/arm/lib/board.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c index 22bd2c9..2f0d5c4 100644 --- a/arch/arm/lib/board.c +++ b/arch/arm/lib/board.c @@ -532,7 +532,7 @@ void board_init_f (ulong bootflag) * memory size from the SDRAM controller setup will have to * get fixed. */ - gd->ram_size -= CONFIG_SYS_MEM_TOP_HIDE; + gd->ram_size -= roundup(CONFIG_SYS_MEM_TOP_HIDE, 4096); #endif addr = CONFIG_SYS_SDRAM_BASE + gd->ram_size; -- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH RFC] ARMV7: OMAP: I2C driver: Reduce excessively long udelay calls
I've been preparing a patch series for Beagle and Overo that detects expansion
board configuration information by reading a 128 byte I2C EEPROM on each
expansion board.
Using the OMAP I2C driver in its current form takes about 5-6 seconds to read
this small number of bytes!
Examining the code I see that there are a large number of fairly long udelay
calls
throughout the driver (10 - 50 milliseconds). I looked through the linux driver
and did not see equivalent delays in that code. In fact the longest delay in
the
linux code was one millisecond.
In looking at the TRM I2C section for OMAP3 and OMAP4 I don't see any
requirement
for delays in the programming model description.
In a series of test builds I found that (at least on OMAP3 and OMAP4) I could
eliminate just about all of these delays.
I don't have access to earlier OMAP family hardware, so I don't know for certain
that they do or do not require these delays.
This patch takes the conservative approach of shortening all the existing delays
to 1 msec, to match the few Linux driver delays. It also modifies the driver's
wait_for_bb routine to timeout after 1 second, again to match the Linux driver
behavior.
Tested on OMAP3 and OMAP4 -- the EEPROM read is now instantaneous, as is the
i2c probe
command, whaich also used to be extremely slow.
Comments welcome, as well as test results from those who might have access to
old OMAP
hardware.
Steve
diff --git a/drivers/i2c/omap24xx_i2c.c b/drivers/i2c/omap24xx_i2c.c
index 3febd1f..c3a25df 100644
--- a/drivers/i2c/omap24xx_i2c.c
+++ b/drivers/i2c/omap24xx_i2c.c
@@ -27,7 +27,7 @@
#include "omap24xx_i2c.h"
-#define I2C_TIMEOUT10
+#define I2C_TIMEOUT1000
static void wait_for_bb (void);
static u16 wait_for_pin (void);
@@ -108,7 +108,7 @@ void i2c_init (int speed, int slaveadd)
if (readw (&i2c_base->con) & I2C_CON_EN) {
writew (0, &i2c_base->con);
- udelay (5);
+ udelay (1000);
}
writew(0x2, &i2c_base->sysc); /* for ES2 after soft reset */
@@ -164,7 +164,7 @@ static int i2c_read_byte (u8 devaddr, u8 regoffset, u8 *
value)
if (status & I2C_STAT_XRDY) {
/* Important: have to use byte access */
writeb (regoffset, &i2c_base->data);
- udelay (2);
+ udelay (1000);
if (readw (&i2c_base->stat) & I2C_STAT_NACK) {
i2c_error = 1;
}
@@ -176,7 +176,7 @@ static int i2c_read_byte (u8 devaddr, u8 regoffset, u8 *
value)
writew (I2C_CON_EN, &i2c_base->con);
while (readw(&i2c_base->stat) &
(I2C_STAT_XRDY | I2C_STAT_ARDY)) {
- udelay (1);
+ udelay (1000);
/* Have to clear pending interrupt to clear I2C_STAT */
writew (0x, &i2c_base->stat);
}
@@ -197,7 +197,7 @@ static int i2c_read_byte (u8 devaddr, u8 regoffset, u8 *
value)
#else
*value = readw (&i2c_base->data);
#endif
- udelay (2);
+ udelay (1000);
} else {
i2c_error = 1;
}
@@ -206,7 +206,7 @@ static int i2c_read_byte (u8 devaddr, u8 regoffset, u8 *
value)
writew (I2C_CON_EN, &i2c_base->con);
while (readw (&i2c_base->stat) &
(I2C_STAT_RRDY | I2C_STAT_ARDY)) {
- udelay (1);
+ udelay (1000);
writew (0x, &i2c_base->stat);
}
}
@@ -256,7 +256,7 @@ static int i2c_write_byte (u8 devaddr, u8 regoffset, u8
value)
writew ((value << 8) + regoffset, &i2c_base->data);
#endif
/* must have enough delay to allow BB bit to go low */
- udelay (5);
+ udelay (1000);
if (readw (&i2c_base->stat) & I2C_STAT_NACK) {
i2c_error = 1;
}
@@ -322,7 +322,7 @@ int i2c_probe (uchar chip)
/* stop bit needed here */
writew (I2C_CON_EN | I2C_CON_MST | I2C_CON_STT | I2C_CON_STP,
&i2c_base->con);
/* enough delay for the NACK bit set */
- udelay (5);
+ udelay (1000);
if (!(readw (&i2c_base->stat) & I2C_STAT_NACK)) {
res = 0; /* success case */
@@ -331,7 +331,7 @@ int i2c_probe (uchar chip)
} else {
writew(0x, &i2c_base->stat); /* failue, clear
sources*/
writew (readw (&i2c_base->con) | I2C_CON_STP, &i2c_base->con);
/* finish up xfer */
- udelay(2);
+ udelay(1000);
wait_for_bb ();
}
flush_fifo();
@@ -392,13 +392,13 @@ int i2c_write (uchar chip, uint addr, int alen, uch
Re: [U-Boot] [PATCH 1/2] Kirkwood: Add support for OpenRD-Client & OpenRD-Ultimate
Le 15/10/2010 15:15, Tanmay Upadhyay a écrit : > This patch modifies existing OpenRD-Base support to deal with all > the three OpenRD boards (OpenRD-Base, OpenRD-Client& OpenRD-Ultimate). > > Signed-off-by: Tanmay Upadhyay > --- Build and boots on an OpenRD-Client. Only two oddities: 1) U-boot announces "DRAM: 640.1 MiB" -- that should be 512 MiB. 2) U-boot also announces "*** Warning - readenv() failed, using default environment" But these are also present when building and running openrd_base before this patchset, so they were not introduced by it. Therefore, FWIW: Tested-By: Albert Aribaud Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Fwd: Help with replacing u-boot and kernel on a released HW...
Hi Naresh, > I am not able to attach the files. But they haven't been changed from > the original versions so hopefully, I still can be helped! Can't you use a different mailer? Attaching files without using base64 isn't all _that_ hard. [...] > Subject: Help with replacing u-boot and kernel on a released HW... > Hi List, > > I have a monta-vista linux based smartphone (Garmin Asus G60). It runs > u-boot and kernel 2.6.21. Since it is a released HW and from the > u-boot code, I can see that there are no ways to stop the existing > u-boot to boot the default kernel installed. There is a possibility to > do a region update from the memory card on boot-up. Looking at the > code, there is also a possibility to do a recover region i.e. > according to the comment it says, download Garmin region from USB. > Both the above methods basically run the same command "tffs_load 3 > 0x80007FC0;bootm 0x80007FC0". The tffs_load is attached in the email. To even start to help you, I'd need to understand better how the "regular" boot process works and what you try to achieve. From the informatino you provide, I cannot infer this. > I have tried to put a bootable .bin file with a modified u-boot and > kernel but it does not seem to get loaded. I have tried loading the > kernel at 0x80007FC0, 0x8000 and 0x0. I am out of ideas on how I > could get the modified u-boot and kernel on the device. Any pointers > would be greatly appreciated. > > Just to be clear on how I create the bootable .bin: > - Compile u-boot for montana board (used for this device) In mainline I cannot find a "montana" board. What sources do you use? > - Compile the kernel with montana_dev_defconfig and some kernel debug > options enabled Also in the Linux kernel I cannot find such a configuration. > - Generate a bootable image from vmlinux with different load address > configurations as described above > - cat u-boot.bin and the bootable image to form a .bin file > - Place the file on the sdcard and re-boot. > > I am now out of ideas. BTW, the HW consists of OMAP2430 and associated > components with an Ericsson U360 modem. I am attaching the montana.h > file for further reference which will give some overview of the G60 > HW. My final goal is to load Android on this device but for that I > need new u-boot and modified kernel to get loaded first. Whoever came up with the "montana.h" file may be in a better position to help you. Do you know who that was? Cheers Detlev -- C hasn't changed much since the 1970s. And let's face it it's ugly. Can't we do better? C++? (Sorry, never mind.) -- Rob Pike -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2 1/1] IMX: rename mx51 to mx5
Rename mx51 to mx5 in order to support more mx51
like-style SOCs such as MX53 and the followings.
Signed-off-by: Jason Liu
---
Changes for v2:
Address the comments from Stefano Babic:
- rebase
- remove CONFIG_CPU_TYPE
- remove copyright change
- change vision2 board config
---
arch/arm/cpu/armv7/{mx51 => mx5}/Makefile |0
arch/arm/cpu/armv7/{mx51 => mx5}/clock.c | 42 ++--
arch/arm/cpu/armv7/{mx51 => mx5}/iomux.c |2 +-
arch/arm/cpu/armv7/{mx51 => mx5}/lowlevel_init.S |0
arch/arm/cpu/armv7/{mx51 => mx5}/soc.c | 28 -
arch/arm/cpu/armv7/{mx51 => mx5}/speed.c |0
arch/arm/cpu/armv7/{mx51 => mx5}/timer.c |8 ++--
arch/arm/cpu/armv7/{mx51 => mx5}/u-boot.lds|0
.../asm/{arch-mx51 => arch-mx5}/asm-offsets.h |0
.../include/asm/{arch-mx51 => arch-mx5}/clock.h|0
.../include/asm/{arch-mx51 => arch-mx5}/crm_regs.h |0
.../include/asm/{arch-mx51 => arch-mx5}/imx-regs.h |0
.../include/asm/{arch-mx51 => arch-mx5}/iomux.h|8 ++--
.../mx51_pins.h => arch-mx5/mx5x_pins.h} |6 +-
.../asm/{arch-mx51 => arch-mx5}/sys_proto.h|4 +-
board/freescale/mx51evk/mx51evk.c |2 +-
board/ttcontrol/vision2/vision2.c |2 +-
boards.cfg |4 +-
include/configs/mx51evk.h |4 +-
include/configs/vision2.h |4 +-
20 files changed, 61 insertions(+), 53 deletions(-)
diff --git a/arch/arm/cpu/armv7/mx51/Makefile b/arch/arm/cpu/armv7/mx5/Makefile
similarity index 100%
rename from arch/arm/cpu/armv7/mx51/Makefile
rename to arch/arm/cpu/armv7/mx5/Makefile
diff --git a/arch/arm/cpu/armv7/mx51/clock.c b/arch/arm/cpu/armv7/mx5/clock.c
similarity index 85%
rename from arch/arm/cpu/armv7/mx51/clock.c
rename to arch/arm/cpu/armv7/mx5/clock.c
index a27227d..a6604c6 100644
--- a/arch/arm/cpu/armv7/mx51/clock.c
+++ b/arch/arm/cpu/armv7/mx5/clock.c
@@ -71,7 +71,7 @@ u32 get_mcu_main_clk(void)
reg = (__raw_readl(&mxc_ccm->cacrr) & MXC_CCM_CACRR_ARM_PODF_MASK) >>
MXC_CCM_CACRR_ARM_PODF_OFFSET;
- freq = decode_pll(mxc_plls[PLL1_CLOCK], CONFIG_MX51_HCLK_FREQ);
+ freq = decode_pll(mxc_plls[PLL1_CLOCK], CONFIG_HCLK_FREQ);
return freq / (reg + 1);
}
@@ -84,14 +84,14 @@ static u32 get_periph_clk(void)
reg = __raw_readl(&mxc_ccm->cbcdr);
if (!(reg & MXC_CCM_CBCDR_PERIPH_CLK_SEL))
- return decode_pll(mxc_plls[PLL2_CLOCK], CONFIG_MX51_HCLK_FREQ);
+ return decode_pll(mxc_plls[PLL2_CLOCK], CONFIG_HCLK_FREQ);
reg = __raw_readl(&mxc_ccm->cbcmr);
switch ((reg & MXC_CCM_CBCMR_PERIPH_CLK_SEL_MASK) >>
MXC_CCM_CBCMR_PERIPH_CLK_SEL_OFFSET) {
case 0:
- return decode_pll(mxc_plls[PLL1_CLOCK], CONFIG_MX51_HCLK_FREQ);
+ return decode_pll(mxc_plls[PLL1_CLOCK], CONFIG_HCLK_FREQ);
case 1:
- return decode_pll(mxc_plls[PLL3_CLOCK], CONFIG_MX51_HCLK_FREQ);
+ return decode_pll(mxc_plls[PLL3_CLOCK], CONFIG_HCLK_FREQ);
default:
return 0;
}
@@ -146,15 +146,15 @@ static u32 get_uart_clk(void)
MXC_CCM_CSCMR1_UART_CLK_SEL_OFFSET) {
case 0x0:
freq = decode_pll(mxc_plls[PLL1_CLOCK],
- CONFIG_MX51_HCLK_FREQ);
+ CONFIG_HCLK_FREQ);
break;
case 0x1:
freq = decode_pll(mxc_plls[PLL2_CLOCK],
- CONFIG_MX51_HCLK_FREQ);
+ CONFIG_HCLK_FREQ);
break;
case 0x2:
freq = decode_pll(mxc_plls[PLL3_CLOCK],
- CONFIG_MX51_HCLK_FREQ);
+ CONFIG_HCLK_FREQ);
break;
default:
return 6650;
@@ -181,7 +181,7 @@ u32 get_lp_apm(void)
u32 ccsr = __raw_readl(&mxc_ccm->ccsr);
if (((ccsr >> 9) & 1) == 0)
- ret_val = CONFIG_MX51_HCLK_FREQ;
+ ret_val = CONFIG_HCLK_FREQ;
else
ret_val = ((32768 * 1024));
@@ -207,17 +207,17 @@ u32 imx_get_cspiclk(void)
switch (clk_sel) {
case 0:
ret_val = decode_pll(mxc_plls[PLL1_CLOCK],
- CONFIG_MX51_HCLK_FREQ) /
+ CONFIG_HCLK_FREQ) /
((pre_pdf + 1) * (pdf + 1));
break;
case 1:
ret_val = decode_pll(mxc_plls[PLL2_CLOCK],
- CONFIG_MX51_HCLK_FREQ) /
+ CONFIG_HCLK_FREQ) /
((pre_pdf + 1) * (pdf + 1));
break
Re: [U-Boot] [PATCH] Ensure gd->ram_size end stays on 4k page boundary when 'hiding' RAM
On Fri, Oct 15, 2010 at 03:51:48PM +0100, Gray Remlin wrote: > Signed-off-by: Gray Remlin > --- > arch/arm/lib/board.c |3 ++- > 1 files changed, 2 insertions(+), 1 deletions(-) > > diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c > index 22bd2c9..c1b21f5 100644 > --- a/arch/arm/lib/board.c > +++ b/arch/arm/lib/board.c > @@ -531,8 +531,9 @@ void board_init_f (ulong bootflag) > * arch/powerpc with bootwrapper support, that recalculate the > * memory size from the SDRAM controller setup will have to > * get fixed. > +* Ensure gd->ram_size end is still on a 4k page boundary. > */ > - gd->ram_size -= CONFIG_SYS_MEM_TOP_HIDE; > + gd->ram_size -= ((CONFIG_SYS_MEM_TOP_HIDE + 0xFFF) & ~(0xFFF)); > #endif How about this easier to read version: gd->ram_size -= roundup(CONFIG_SYS_MEM_TOP_HIDE, 4096); Ira > > addr = CONFIG_SYS_SDRAM_BASE + gd->ram_size; > -- > ___ > 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
[U-Boot] [PATCH] Support sending DHCP client options
Signed-off-by: Gray Remlin
---
common/cmd_nvedit.c |3 ++
net/bootp.c | 52
+++
2 files changed, 55 insertions(+), 0 deletions(-)
diff --git a/common/cmd_nvedit.c b/common/cmd_nvedit.c
index 3d30c32..2094e8e 100644
--- a/common/cmd_nvedit.c
+++ b/common/cmd_nvedit.c
@@ -224,6 +224,9 @@ int _do_env_set (int flag, int argc, char * const
argv[])
if (ep) { /* variable exists */
#ifndef CONFIG_ENV_OVERWRITE
if ((strcmp (name, "serial#") == 0) ||
+#if defined(CONFIG_BOOTP_OPTIONS)
+ (strcmp(name, "dhcp_vendor-class-identifier") == 0) ||
+#endif /* CONFIG_BOOTP_OPTIONS */
((strcmp (name, "ethaddr") == 0)
#if defined(CONFIG_OVERWRITE_ETHADDR_ONCE) && defined(CONFIG_ETHADDR)
&& (strcmp (ep->data,MK_STR(CONFIG_ETHADDR)) != 0)
diff --git a/net/bootp.c b/net/bootp.c
index 1289e3b..9e687b0 100644
--- a/net/bootp.c
+++ b/net/bootp.c
@@ -68,6 +68,54 @@ extern u8 *dhcp_vendorex_prep (u8 *e); /*rtn new e
after add own opts. */
extern u8 *dhcp_vendorex_proc (u8 *e); /*rtn next e if mine,else NULL */
#endif
+#if defined(CONFIG_BOOTP_OPTIONS) /* check environment for dhcp client
options */
+
+/*
+ * The vendor-specifiable options should not be changeable
+ * unless CONFIG_ENV_OVERWRITE has been defined, however
+ * user-specifiable options should be changeable regardless
+ */
+u8 dhcp_options_prep(u8 **ep)
+{
+ u8 *e = *ep;
+ char *ptr;
+
+ debug("DHCP Client options start\n");
+
+ /* vendor-specifiable identification string */
+ if ((ptr = getenv("dhcp_vendor-class-identifier"))) {
+ debug("dhcp_vendor-class-identifier=%s\n",ptr);
+ *e++ = 60;
+ *e++ = strlen(ptr);
+ while (*ptr)
+ *e++ = *ptr++;
+ }
+
+ /* user-specifiable identification string */
+ if ((ptr = getenv("dhcp_dhcp-client-identifier"))) {
+ debug("dhcp_dhcp-client-identifier=%s\n",ptr);
+ *e++ = 61;
+ *e++ = strlen(ptr);
+ while (*ptr)
+ *e++ = *ptr++;
+ }
+
+ /* user-specifiable identification string */
+ if ((ptr = getenv("dhcp_user-class"))) {
+ debug("dhcp_user-class=%s\n",ptr);
+ *e++ = 77;
+ *e++ = strlen(ptr);
+ while (*ptr)
+ *e++ = *ptr++;
+ }
+
+ debug("DHCP Client options end\n");
+ *ep = e;
+ return e;
+}
+
+#endif /* CONFIG_BOOTP_OPTIONS */
+
#endif
static int BootpCheckPkt(uchar *pkt, unsigned dest, unsigned src,
unsigned len)
@@ -412,6 +460,10 @@ static int DhcpExtended (u8 * e, int message_type,
IPaddr_t ServerID, IPaddr_t R
}
#endif
+#if defined(CONFIG_BOOTP_OPTIONS)
+ dhcp_options_prep (&e);
+#endif
+
#if defined(CONFIG_BOOTP_VENDOREX)
if ((x = dhcp_vendorex_prep (e)))
return x - start;
--
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Fix potential empty Parameter Request List
Signed-off-by: Gray Remlin --- net/bootp.c | 16 +++- 1 files changed, 15 insertions(+), 1 deletions(-) diff --git a/net/bootp.c b/net/bootp.c index e679f8b..1289e3b 100644 --- a/net/bootp.c +++ b/net/bootp.c @@ -417,8 +417,21 @@ static int DhcpExtended (u8 * e, int message_type, IPaddr_t ServerID, IPaddr_t R return x - start; #endif +/* + * RFC2132: An empty Parameter Request List is not legitimate, + * it must have at minimum one request. + */ +#if defined(CONFIG_BOOTP_SUBNETMASK) || \ +defined(CONFIG_BOOTP_TIMEOFFSET) || \ +defined(CONFIG_BOOTP_GATEWAY) || \ +defined(CONFIG_BOOTP_DNS) || \ +defined(CONFIG_BOOTP_HOSTNAME) || \ +defined(CONFIG_BOOTP_BOOTFILESIZE) || \ +defined(CONFIG_BOOTP_BOOTPATH) || \ +defined(CONFIG_BOOTP_NISDOMAIN) || \ +defined(CONFIG_BOOTP_NTPSERVER) *e++ = 55; /* Parameter Request List */ -cnt = e++; /* Pointer to count of requested items */ + cnt = e++; /* Pointer to count of requested items */ *cnt = 0; #if defined(CONFIG_BOOTP_SUBNETMASK) *e++ = 1; /* Subnet Mask */ @@ -456,6 +469,7 @@ static int DhcpExtended (u8 * e, int message_type, IPaddr_t ServerID, IPaddr_t R *e++ = 42; *cnt += 1; #endif +#endif *e++ = 255;/* End of the list */ /* Pad to minimal length */ -- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Ensure gd->ram_size end stays on 4k page boundary when 'hiding' RAM
Signed-off-by: Gray Remlin --- arch/arm/lib/board.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c index 22bd2c9..c1b21f5 100644 --- a/arch/arm/lib/board.c +++ b/arch/arm/lib/board.c @@ -531,8 +531,9 @@ void board_init_f (ulong bootflag) * arch/powerpc with bootwrapper support, that recalculate the * memory size from the SDRAM controller setup will have to * get fixed. +* Ensure gd->ram_size end is still on a 4k page boundary. */ - gd->ram_size -= CONFIG_SYS_MEM_TOP_HIDE; + gd->ram_size -= ((CONFIG_SYS_MEM_TOP_HIDE + 0xFFF) & ~(0xFFF)); #endif addr = CONFIG_SYS_SDRAM_BASE + gd->ram_size; -- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] IMX: rename mx51 to mx5
Hi, Stefano,
> -Original Message-
> From: Stefano Babic [mailto:sba...@denx.de]
> Sent: Friday, October 15, 2010 7:40 PM
> To: Liu Hui-R64343
> Cc: sba...@denx.de; u-boot@lists.denx.de
> Subject: Re: [U-Boot][PATCH 1/1] IMX: rename mx51 to mx5
>
> On 10/15/2010 04:22 AM, Jason Liu wrote:
> > Rename mx51 to mx5 in order to support more mx51
> > like-style SOCs such as MX53 and the followings.
> >
> > Signed-off-by: Jason Liu
>
> Hi Jason,
>
> a little feedback. This patch is well-formed and I do not see the
> corruption problems as with the former one.
>
> However, the patch does not apply:
>
> Applying: IMX: rename mx51 to mx5
> error: patch failed: arch/arm/include/asm/arch-mx51/sys_proto.h:24
> error: arch/arm/include/asm/arch-mx51/sys_proto.h: patch does not
apply
> error: patch failed: boards.cfg:46
> error: boards.cfg: patch does not apply
> Patch failed at 0001 IMX: rename mx51 to mx5
>
> Have you applied the patch on the current u-boot.git tree ? It seems
you
> have to to rebase your patch.
Yes, correct.
>
> Please increment the version of your patch to allow everybody to track
> easier the changes. Something like [PATCH V2 1/1] makes the job.
Yes, I will do it.
>
> > @@ -2,7 +2,7 @@
> > * (C) Copyright 2007
> > * Sascha Hauer, Pengutronix
> > *
> > - * (C) Copyright 2009 Freescale Semiconductor, Inc.
> > + * (C) Copyright 2009-2010 Freescale Semiconductor, Inc.
>
> I let someone with more legal experience as me to judge if this change
> is allowed or not. Normally, a new Copyright is added in case there is
> some important improvement that are not covered by the original file.
In
> this case, only a define was changed (CONFIG_MX51_HCLK_FREQ ->
> CONFIG_HCLK_FREQ).
Make sense, I will modify it.
>
> > --- a/arch/arm/cpu/armv7/mx51/soc.c
> > +++ b/arch/arm/cpu/armv7/mx5/soc.c
> > @@ -2,7 +2,7 @@
> > * (C) Copyright 2007
> > * Sascha Hauer, Pengutronix
> > *
> > - * (C) Copyright 2009 Freescale Semiconductor, Inc.
> > + * (C) Copyright 2009-2010 Freescale Semiconductor, Inc.
> > *
> > * See file CREDITS for list of people who contributed to this
> > * project.
> > @@ -35,26 +35,25 @@
> >
> > u32 get_cpu_rev(void)
> > {
> > - int reg;
> > - int system_rev;
> > + int system_rev = CONFIG_CPU_TYPE << 8;
>
> CONFIG_CPU_TYPE is a new CONFIG_ switch, that should be not needed.
See
> my comments later.
Good point.
>
> > diff --git a/boards.cfg b/boards.cfg
> > index 9226424..e144281 100644
> > --- a/boards.cfg
> > +++ b/boards.cfg
> > @@ -46,7 +46,7 @@ pm9263arm arm926ejs -
ronetix
> at91
> > jadecpuarm arm926ejs jadecpu syteco
> mb86r0x
> > suen3 arm arm926ejs km_arm keymile
> kirkwood
> > rd6281aarm arm926ejs - Marvell
> kirkwood
> > -mx51evkarm armv7 mx51evk
freescale mx51
> > +mx51evkarm armv7 mx51evk
freescale mx5
>
> It makes sense to change other boards with MX51 inside this patch and
> not with a separate patch. So add changes for the other board, too.
Agree.
>
> > diff --git a/include/configs/mx51evk.h b/include/configs/mx51evk.h
> > old mode 100644
> > new mode 100755
> > index 86a4731..363af3d
> > --- a/include/configs/mx51evk.h
> > +++ b/include/configs/mx51evk.h
> > @@ -1,7 +1,7 @@
> > /*
> > * Copyright (C) 2007, Guennadi Liakhovetski
> > *
> > - * (C) Copyright 2009 Freescale Semiconductor, Inc.
> > + * (C) Copyright 2009-2010 Freescale Semiconductor, Inc.
> > *
> > * Configuration settings for the MX51EVK Board
> > *
> > @@ -28,10 +28,11 @@
> > /* High Level Configuration Options */
> >
> > #define CONFIG_MX51/* in a mx51 */
> > +#define CONFIG_CPU_TYPE51
>
> Why do we have CONFIG_MX51 and CONFIG_CPU_TYPE ? It seems redundant. A
> board maintainer must set both and this makes no great sense. Can we
> derive CONFIG_CPU_TYPE (or its meaning) from CONFIG_MX51 when we need
?
Good point, I will modify it.
The v2 patch will be sent out for review soon. :)
BR,
Jason
>
> Best regards,
> Stefano Babic
>
> --
> =
> 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] [PATCH v2] ehci-pci: print hccr, hcor and hc_lenght
It is useful to know the EHCI-PCI hccr, hcor and hc_lenght to make sure it was
successfully registered, and at the correct location.
Signed-off-by: Florian Fainelli
---
Changes since v1:
- replaced printf by debug
diff --git a/drivers/usb/host/ehci-pci.c b/drivers/usb/host/ehci-pci.c
index 047902a..cff3438 100644
--- a/drivers/usb/host/ehci-pci.c
+++ b/drivers/usb/host/ehci-pci.c
@@ -53,6 +53,10 @@ int ehci_hcd_init(void)
hcor = (struct ehci_hcor *)((uint32_t) hccr +
HC_LENGTH(ehci_readl(&hccr->cr_capbase)));
+ debug("EHCI-PCI init hccr 0x%x and hcor 0x%x hc_length %d\n",
+ (uint32_t)hccr, (uint32_t)hcor,
+ (uint32_t)HC_LENGTH(ehci_readl(&hccr->cr_capbase)));
+
return 0;
}
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] Kirkwood: OpenRD: Initialize MPPs during early init
This patch adds board_early_init_f function for OpenRD boards. The
function initializes MPPs so that peripherals can work at early
stage.
Signed-off-by: Tanmay Upadhyay
---
board/Marvell/openrd/openrd.c |6 +-
include/configs/openrd.h |2 ++
2 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/board/Marvell/openrd/openrd.c b/board/Marvell/openrd/openrd.c
index 3953282..2d34a24 100644
--- a/board/Marvell/openrd/openrd.c
+++ b/board/Marvell/openrd/openrd.c
@@ -41,7 +41,7 @@
DECLARE_GLOBAL_DATA_PTR;
-int board_init(void)
+int board_early_init_f(void)
{
/*
* default gpio configuration
@@ -108,7 +108,11 @@ int board_init(void)
};
kirkwood_mpp_conf(kwmpp_config);
+ return 0;
+}
+int board_init(void)
+{
/*
* arch number of board
*/
diff --git a/include/configs/openrd.h b/include/configs/openrd.h
index c4dcad6..850dbae 100644
--- a/include/configs/openrd.h
+++ b/include/configs/openrd.h
@@ -110,4 +110,6 @@
#define CONFIG_SYS_ATA_IDE1_OFFSET MV_SATA_PORT1_OFFSET
#endif /*CONFIG_MVSATA_IDE*/
+/* board_early_init_f function in openrd.c initializes all MPP settings */
+#define CONFIG_BOARD_EARLY_INIT_F
#endif /* _CONFIG_OPENRD_H */
--
1.6.6.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] Kirkwood: Add support for OpenRD-Client & OpenRD-Ultimate
This patch modifies existing OpenRD-Base support to deal with all the three OpenRD boards (OpenRD-Base, OpenRD-Client & OpenRD-Ultimate). Signed-off-by: Tanmay Upadhyay --- MAKEALL |2 + board/Marvell/openrd/Makefile | 56 ++ board/Marvell/openrd/config.mk | 33 ++ board/Marvell/openrd/kwbimage.cfg | 168 ++ board/Marvell/openrd/openrd.c | 169 +++ board/Marvell/openrd/openrd.h | 50 + board/Marvell/openrd_base/Makefile | 56 -- board/Marvell/openrd_base/config.mk | 33 -- board/Marvell/openrd_base/kwbimage.cfg | 168 -- board/Marvell/openrd_base/openrd_base.c | 149 --- board/Marvell/openrd_base/openrd_base.h | 46 - boards.cfg |4 +- include/configs/openrd.h| 113 + include/configs/openrd_base.h | 92 +++-- include/configs/openrd_client.h | 50 + include/configs/openrd_ultimate.h | 50 + 16 files changed, 708 insertions(+), 531 deletions(-) create mode 100644 board/Marvell/openrd/Makefile create mode 100644 board/Marvell/openrd/config.mk create mode 100644 board/Marvell/openrd/kwbimage.cfg create mode 100644 board/Marvell/openrd/openrd.c create mode 100644 board/Marvell/openrd/openrd.h delete mode 100644 board/Marvell/openrd_base/Makefile delete mode 100644 board/Marvell/openrd_base/config.mk delete mode 100644 board/Marvell/openrd_base/kwbimage.cfg delete mode 100644 board/Marvell/openrd_base/openrd_base.c delete mode 100644 board/Marvell/openrd_base/openrd_base.h create mode 100644 include/configs/openrd.h create mode 100644 include/configs/openrd_client.h create mode 100644 include/configs/openrd_ultimate.h diff --git a/MAKEALL b/MAKEALL index 1b506d6..11fbf48 100755 --- a/MAKEALL +++ b/MAKEALL @@ -431,6 +431,8 @@ LIST_ARM9=" \ omap5912osk \ omap730p2 \ openrd_base \ + openrd_client \ + openrd_ultimate \ rd6281a \ sbc2410x\ scb9328 \ diff --git a/board/Marvell/openrd/Makefile b/board/Marvell/openrd/Makefile new file mode 100644 index 000..aad05d8 --- /dev/null +++ b/board/Marvell/openrd/Makefile @@ -0,0 +1,56 @@ +# +# (C) Copyright 2009 +# Net Insight +# Written-by: Simon Kagstrom +# +# Based on sheevaplug: +# (C) Copyright 2009 +# Marvell Semiconductor +# Written-by: Prafulla Wadaskar +# +# 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., 51 Franklin Street, Fifth Floor, Boston, +# MA 02110-1301 USA +# + +include $(TOPDIR)/config.mk + +LIB= $(obj)lib$(BOARD).a + +COBJS := openrd.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 .depend + +# + +# defines $(obj).depend target +include $(SRCTREE)/rules.mk + +sinclude $(obj).depend + +# diff --git a/board/Marvell/openrd/config.mk b/board/Marvell/openrd/config.mk new file mode 100644 index 000..8ae355e --- /dev/null +++ b/board/Marvell/openrd/config.mk @@ -0,0 +1,33 @@ +# +# (C) Copyright 2009 +# Net Insight +# Written-by: Simon Kagstrom +# +# Based on sheevaplug: +# (C) Copyright 2009 +# Marvell Semiconductor +# Written-by: Prafulla Wadaskar +# +# 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 war
[U-Boot] [PATCH v2] Kirkwood: bugfix: DRAM size initialization
If start of any DRAM bank is greater than total DDR size, remaining
DDR banks' start address & size were left un-initialized in dram_init
function. This could break other functions who uses array
'gd->bd->bi_dram'. Kirkwood network driver is one example. This also
stops Linux kernel from booting.
v2 - Set start address also to 0. Without this Linux kernel couldn't
boot up
Signed-off-by: Tanmay Upadhyay
---
arch/arm/cpu/arm926ejs/kirkwood/dram.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/kirkwood/dram.c
b/arch/arm/cpu/arm926ejs/kirkwood/dram.c
index 7439c87..a4344b8 100644
--- a/arch/arm/cpu/arm926ejs/kirkwood/dram.c
+++ b/arch/arm/cpu/arm926ejs/kirkwood/dram.c
@@ -81,6 +81,16 @@ int dram_init(void)
gd->ram_size += gd->bd->bi_dram[i].size;
}
+
+ for (; i < CONFIG_NR_DRAM_BANKS; i++) {
+ /* If above loop terminated prematurely, we need to set
+* remaining banks' start address & size as 0. Otherwise other
+* u-boot functions and Linux kernel gets wrong values which
+* could result in crash */
+ gd->bd->bi_dram[i].start = 0;
+ gd->bd->bi_dram[i].size = 0;
+ }
+
return 0;
}
--
1.6.6.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Kirkwood: bugfix: DRAM size initialization
Hi All,
I was a bit hasty in providing the patch. Given patch solves u-boot
stuff, but Linux kernel still has some trouble. I am providing second
version of this patch which takes care of start address also. This fixes
Linux kernel issue.
Please ignore this version.
Sorry,
Tanmay
On 10/14/2010 06:17 PM, Tanmay Upadhyay wrote:
If start of any DRAM bank is greater than total DDR size, remaining
DDR bank sizes were left un-initialized in dram_init function. This
could break other functions who uses array 'gd->bd->bi_dram'.Kirkwood
network driver is one example.
Signed-off-by: Tanmay Upadhyay
---
arch/arm/cpu/arm926ejs/kirkwood/dram.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/kirkwood/dram.c
b/arch/arm/cpu/arm926ejs/kirkwood/dram.c
index 7439c87..cb396d1 100644
--- a/arch/arm/cpu/arm926ejs/kirkwood/dram.c
+++ b/arch/arm/cpu/arm926ejs/kirkwood/dram.c
@@ -81,6 +81,13 @@ int dram_init(void)
gd->ram_size += gd->bd->bi_dram[i].size;
}
+
+ for (; i< CONFIG_NR_DRAM_BANKS; i++) {
+ /* If above loop terminated prematurely, we need to set
+* remaining bank sizes as 0 */
+ gd->bd->bi_dram[i].size = 0;
+ }
+
return 0;
}
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] IMX: rename mx51 to mx5
On 10/15/2010 04:22 AM, Jason Liu wrote:
> Rename mx51 to mx5 in order to support more mx51
> like-style SOCs such as MX53 and the followings.
>
> Signed-off-by: Jason Liu
Hi Jason,
a little feedback. This patch is well-formed and I do not see the
corruption problems as with the former one.
However, the patch does not apply:
Applying: IMX: rename mx51 to mx5
error: patch failed: arch/arm/include/asm/arch-mx51/sys_proto.h:24
error: arch/arm/include/asm/arch-mx51/sys_proto.h: patch does not apply
error: patch failed: boards.cfg:46
error: boards.cfg: patch does not apply
Patch failed at 0001 IMX: rename mx51 to mx5
Have you applied the patch on the current u-boot.git tree ? It seems you
have to to rebase your patch.
Please increment the version of your patch to allow everybody to track
easier the changes. Something like [PATCH V2 1/1] makes the job.
> @@ -2,7 +2,7 @@
> * (C) Copyright 2007
> * Sascha Hauer, Pengutronix
> *
> - * (C) Copyright 2009 Freescale Semiconductor, Inc.
> + * (C) Copyright 2009-2010 Freescale Semiconductor, Inc.
I let someone with more legal experience as me to judge if this change
is allowed or not. Normally, a new Copyright is added in case there is
some important improvement that are not covered by the original file. In
this case, only a define was changed (CONFIG_MX51_HCLK_FREQ ->
CONFIG_HCLK_FREQ).
> --- a/arch/arm/cpu/armv7/mx51/soc.c
> +++ b/arch/arm/cpu/armv7/mx5/soc.c
> @@ -2,7 +2,7 @@
> * (C) Copyright 2007
> * Sascha Hauer, Pengutronix
> *
> - * (C) Copyright 2009 Freescale Semiconductor, Inc.
> + * (C) Copyright 2009-2010 Freescale Semiconductor, Inc.
> *
> * See file CREDITS for list of people who contributed to this
> * project.
> @@ -35,26 +35,25 @@
>
> u32 get_cpu_rev(void)
> {
> - int reg;
> - int system_rev;
> + int system_rev = CONFIG_CPU_TYPE << 8;
CONFIG_CPU_TYPE is a new CONFIG_ switch, that should be not needed. See
my comments later.
> diff --git a/boards.cfg b/boards.cfg
> index 9226424..e144281 100644
> --- a/boards.cfg
> +++ b/boards.cfg
> @@ -46,7 +46,7 @@ pm9263 arm arm926ejs -
> ronetix at91
> jadecpu arm arm926ejs jadecpu syteco
> mb86r0x
> suen3arm arm926ejs km_arm keymile
> kirkwood
> rd6281a arm arm926ejs - Marvell
> kirkwood
> -mx51evk arm armv7 mx51evk freescale
> mx51
> +mx51evk arm armv7 mx51evk freescale
> mx5
It makes sense to change other boards with MX51 inside this patch and
not with a separate patch. So add changes for the other board, too.
> diff --git a/include/configs/mx51evk.h b/include/configs/mx51evk.h
> old mode 100644
> new mode 100755
> index 86a4731..363af3d
> --- a/include/configs/mx51evk.h
> +++ b/include/configs/mx51evk.h
> @@ -1,7 +1,7 @@
> /*
> * Copyright (C) 2007, Guennadi Liakhovetski
> *
> - * (C) Copyright 2009 Freescale Semiconductor, Inc.
> + * (C) Copyright 2009-2010 Freescale Semiconductor, Inc.
> *
> * Configuration settings for the MX51EVK Board
> *
> @@ -28,10 +28,11 @@
> /* High Level Configuration Options */
>
> #define CONFIG_MX51 /* in a mx51 */
> +#define CONFIG_CPU_TYPE 51
Why do we have CONFIG_MX51 and CONFIG_CPU_TYPE ? It seems redundant. A
board maintainer must set both and this makes no great sense. Can we
derive CONFIG_CPU_TYPE (or its meaning) from CONFIG_MX51 when we need ?
Best regards,
Stefano Babic
--
=
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
