[U-Boot] [PATCHv4] [RFC] DM: early_malloc for DM added.
early_malloc for DM with support for more heaps and lightweight
first heap on stack.
Adaptation layer for seamless calling of early_malloc or dlmalloc from
DM based on init stage added (dmmalloc() and related functions).
Signed-off-by: Tomas Hlavacek
---
arch/arm/include/asm/config.h |3 +
arch/arm/include/asm/global_data.h|1 +
arch/arm/lib/board.c |7 ++
arch/avr32/include/asm/global_data.h |1 +
arch/avr32/lib/board.c|6 ++
arch/blackfin/include/asm/global_data.h |1 +
arch/blackfin/lib/board.c |7 ++
arch/m68k/include/asm/global_data.h |1 +
arch/m68k/lib/board.c |7 ++
arch/microblaze/include/asm/global_data.h |1 +
arch/microblaze/lib/board.c |8 ++
arch/mips/include/asm/global_data.h |1 +
arch/mips/lib/board.c |7 ++
arch/nds32/include/asm/global_data.h |1 +
arch/nds32/lib/board.c|6 ++
arch/nios2/include/asm/global_data.h |1 +
arch/nios2/lib/board.c|6 ++
arch/openrisc/include/asm/global_data.h |1 +
arch/openrisc/lib/board.c |6 ++
arch/powerpc/include/asm/global_data.h|1 +
arch/powerpc/lib/board.c |6 ++
arch/sandbox/include/asm/global_data.h|1 +
arch/sandbox/lib/board.c |6 ++
arch/sh/include/asm/global_data.h |1 +
arch/sh/lib/board.c |6 ++
arch/sparc/include/asm/global_data.h |1 +
arch/sparc/lib/board.c|6 ++
arch/x86/include/asm/global_data.h|1 +
arch/x86/lib/board.c | 14
common/Makefile |1 +
common/dmmalloc.c | 128 +
include/configs/zipitz2.h | 12 ++-
include/dmmalloc.h| 51
33 files changed, 306 insertions(+), 1 deletion(-)
create mode 100644 common/dmmalloc.c
create mode 100644 include/dmmalloc.h
diff --git a/arch/arm/include/asm/config.h b/arch/arm/include/asm/config.h
index c60dba2..8e2f67b 100644
--- a/arch/arm/include/asm/config.h
+++ b/arch/arm/include/asm/config.h
@@ -23,4 +23,7 @@
#define CONFIG_LMB
#define CONFIG_SYS_BOOT_RAMDISK_HIGH
+
+#define CONFIG_SYS_EARLY_MALLOC
#endif
+
diff --git a/arch/arm/include/asm/global_data.h
b/arch/arm/include/asm/global_data.h
index c3ff789..8563d49 100644
--- a/arch/arm/include/asm/global_data.h
+++ b/arch/arm/include/asm/global_data.h
@@ -84,6 +84,7 @@ typedef struct global_data {
unsigned long post_log_res; /* success of POST test */
unsigned long post_init_f_time; /* When post_init_f started */
#endif
+ void*early_heap_first; /* early heap for early_malloc */
} gd_t;
/*
diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c
index 500e216..33e74da 100644
--- a/arch/arm/lib/board.c
+++ b/arch/arm/lib/board.c
@@ -52,6 +52,7 @@
#include
#include
#include
+#include
#ifdef CONFIG_BITBANGMII
#include
@@ -273,6 +274,12 @@ void board_init_f(ulong bootflag)
memset((void *)gd, 0, sizeof(gd_t));
+
+#ifdef CONFIG_SYS_EARLY_MALLOC
+ /* Initialize early_malloc */
+ gd->early_heap_first = early_brk(CONFIG_SYS_EARLY_HEAP_SIZE);
+#endif /* CONFIG_SYS_EARLY_MALLOC */
+
gd->mon_len = _bss_end_ofs;
#ifdef CONFIG_OF_EMBED
/* Get a pointer to the FDT */
diff --git a/arch/avr32/include/asm/global_data.h
b/arch/avr32/include/asm/global_data.h
index 5c654bd..9ae7c5e 100644
--- a/arch/avr32/include/asm/global_data.h
+++ b/arch/avr32/include/asm/global_data.h
@@ -50,6 +50,7 @@ typedef struct global_data {
#endif
void**jt; /* jump table */
charenv_buf[32];/* buffer for getenv() before reloc. */
+ void*early_heap_first; /* early heap for early_malloc */
} gd_t;
/*
diff --git a/arch/avr32/lib/board.c b/arch/avr32/lib/board.c
index 63fe297..6c97ef7 100644
--- a/arch/avr32/lib/board.c
+++ b/arch/avr32/lib/board.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#ifdef CONFIG_BITBANGMII
#include
@@ -149,6 +150,11 @@ void board_init_f(ulong board_type)
memset(&gd_data, 0, sizeof(gd_data));
gd = &gd_data;
+#ifdef CONFIG_SYS_EARLY_MALLOC
+ /* Initialize early_malloc */
+ gd->early_heap_first = early_brk(CONFIG_SYS_EARLY_HEAP_SIZE);
+#endif /* CONFIG_SYS_EARLY_MALLOC */
+
/* Perform initialization sequence */
board_early_init_f();
cpu_init();
diff --git a/arch/blackfin/include/asm/global_data.h
b/arch/blackfin/include/asm/global_data.h
index 67aa30f..33d3cec 100644
--- a/arch/blackfin/include/asm/global_data.h
+++ b/arch/blackfin/include/asm/global_data.h
@@ -59,6 +59,7 @@ typedef struct global_data {
[U-Boot] USB ehci driver query
Hello, I am new to u-boot code. I am reading the usb host controller code for root hub configuration. I have some queries regarding some code. If anyone has got understanding about it pls explain it to me. In usb.c the core calls the usb controller driver (ehci-hcd.c) by issuing command GET_DESCRIPTOR to know the maximum packet size the endpoint supports. It than once again calls the driver by issuing command SET_ADDRESS to give address 1 to root hub. Than it issues command GET_DESCRIPTOR second time and this time creates a queue head and associated queue transfer descriptors. The code for this is in function ehci_submit_async() (drivers/usb/host/ehci-hcd.c). I am not getting the purpose of calling this function and what the usb core is achieving by calling it. If anyone can throw some light on it. Regards -- Puneet Sharma The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 2/2] i.MX6: mx6qsabrelite: Add splash screen support
On 18/09/2012 01:14, Eric Nelson wrote:
Hi Eric,
> Adds support for the Hannstar 1024 x 768 LVDS panel (Freescale part
> number MCIMX-LVDS1) to SABRE-Lite board.
>
> This commit is a rebase Fabio Estevan's patch from 5/31 to
> u-boot-video/master:
> http://patchwork.ozlabs.org/patch/162206/
>
> Modifications include:
> removal of i2c setup (unneeded)
> cleanup of lcd_iomux to use struct mxc_ccm_reg and anatop_regs
> and associated constants
>
All this stuff should not be part of the commit message, because it is
more or less a changelog. Should you also include Fabio's signed-off ?
> Signed-off-by: Eric Nelson
> ---
> arch/arm/include/asm/arch-mx6/crm_regs.h |4 +
> board/freescale/mx6qsabrelite/mx6qsabrelite.c | 90
> +
> include/configs/mx6qsabrelite.h | 14 -
> 3 files changed, 107 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/include/asm/arch-mx6/crm_regs.h
> b/arch/arm/include/asm/arch-mx6/crm_regs.h
> index 8388e38..cffc0a1 100644
> --- a/arch/arm/include/asm/arch-mx6/crm_regs.h
> +++ b/arch/arm/include/asm/arch-mx6/crm_regs.h
> @@ -294,6 +294,10 @@ struct mxc_ccm_reg {
> #define MXC_CCM_CHSCCDR_IPU1_DI0_CLK_SEL_MASK(0x7)
> #define MXC_CCM_CHSCCDR_IPU1_DI0_CLK_SEL_OFFSET 0
>
> +#define CHSCCDR_CLK_SEL_LDB_DI0 3
> +#define CHSCCDR_PODF_DIVIDE_BY_3 2
> +#define CHSCCDR_IPU_PRE_CLK_540M_PFD 5
> +
> /* Define the bits in register CSCDR2 */
> #define MXC_CCM_CSCDR2_ECSPI_CLK_PODF_MASK (0x3F << 19)
> #define MXC_CCM_CSCDR2_ECSPI_CLK_PODF_OFFSET 19
> diff --git a/board/freescale/mx6qsabrelite/mx6qsabrelite.c
> b/board/freescale/mx6qsabrelite/mx6qsabrelite.c
> index 4b4e89b..1632e7b 100644
> --- a/board/freescale/mx6qsabrelite/mx6qsabrelite.c
> +++ b/board/freescale/mx6qsabrelite/mx6qsabrelite.c
> @@ -36,6 +36,9 @@
> #include
> #include
> #include
> +#include
> +#include
> +#include
> DECLARE_GLOBAL_DATA_PTR;
>
> #define UART_PAD_CTRL (PAD_CTL_PKE | PAD_CTL_PUE | \
> @@ -195,6 +198,10 @@ static iomux_v3_cfg_t button_pads[] = {
> MX6Q_PAD_GPIO_18__GPIO_7_13 | MUX_PAD_CTRL(BUTTON_PAD_CTRL),
> };
>
> +iomux_v3_cfg_t lcd_gpio[] = {
> + MX6Q_PAD_SD1_CMD__GPIO_1_18 | MUX_PAD_CTRL(NO_PAD_CTRL),
> +};
> +
> static void setup_iomux_enet(void)
> {
> gpio_direction_output(IMX_GPIO_NR(3, 23), 0);
> @@ -372,10 +379,84 @@ int setup_sata(void)
> }
> #endif
>
> +static struct fb_videomode lvds_xga = {
> + .name = "Hannstar-XGA",
> + .refresh= 60,
> + .xres = 1024,
> + .yres = 768,
> + .pixclock = 15385,
> + .left_margin= 220,
> + .right_margin = 40,
> + .upper_margin = 21,
> + .lower_margin = 7,
> + .hsync_len = 60,
> + .vsync_len = 10,
> + .sync = FB_SYNC_EXT,
> + .vmode = FB_VMODE_NONINTERLACED
> +};
> +
> +void lcd_iomux(void)
> +{
> + struct mxc_ccm_reg *mxc_ccm = (struct mxc_ccm_reg *)CCM_BASE_ADDR;
> + struct anatop_regs *anatop = (struct anatop_regs *)ANATOP_BASE_ADDR;
> +
> + int reg;
> + /* Turn on GPIO backlight */
> + imx_iomux_v3_setup_multiple_pads(lcd_gpio, ARRAY_SIZE(lcd_gpio));
> + gpio_direction_output(18, 1);
> +
> + /* Turn on LDB0,IPU,IPU DI0 clocks */
> + reg = __raw_readl(&mxc_ccm->CCGR3);
> + reg |= 0x300F;
> + writel(reg, &mxc_ccm->CCGR3);
I think we can add constants for these - at least for these constants,
you could drop the not useful defines with offset like
MXC_CCM_CCGR5_CGx_OFFSET. There is already a patch (not yet merged) for
MX5, we should then doing the same for MX6.
> +
> + /* set PFD3_FRAC to 0x13 == 455 MHz (480*18)/0x13 */
> + writel(0x3F00, &anatop->pfd_480_clr);
> + writel(0x1300, &anatop->pfd_480_set);
Add constants for these. They are not already defined, but they are
added when needed, see for example ehci-mx6.c
> +
> + /* set LDB0, LDB1 clk select to 011/011 */
> + reg = readl(&mxc_ccm->cs2cdr);
> + reg &= ~(MXC_CCM_CS2CDR_LDB_DI0_CLK_SEL_MASK
> + |MXC_CCM_CS2CDR_LDB_DI1_CLK_SEL_MASK);
> + reg |= (3< + |(3< + writel(reg, &mxc_ccm->cs2cdr);
> +
> + reg = readl(&mxc_ccm->cscmr2);
> + reg |= MXC_CCM_CSCMR2_LDB_DI0_IPU_DIV;
> + writel(reg, &mxc_ccm->cscmr2);
> +
> + reg = readl(&mxc_ccm->chsccdr);
> + reg &= ~(MXC_CCM_CHSCCDR_IPU1_DI0_PRE_CLK_SEL_MASK
> + |MXC_CCM_CHSCCDR_IPU1_DI0_PODF_MASK
> + |MXC_CCM_CHSCCDR_IPU1_DI0_CLK_SEL_MASK);
> + /* derive clock from LDB_DI0 */
> + /* divide by 3 */
> + /* derive clock from 540M PFD */
Wrong style for a multiline comment
> + reg |= (CHSCCDR_CLK_SEL_LDB_DI0
> + < + |(CHSCCDR_PODF_DIVIDE_BY_3
> + < + |(CHSCCDR_IPU_PRE_CLK_540M_PFD
> +
Re: [U-Boot] [PATCH] mx6: Remove lowlevel_init.S
On 17.09.2012 18:34, Fabio Estevam wrote: lowlevel_init.S is not used on mx6, Yes, but ... We use lowlevel_init.S on a not yet public custom board to do some early, custom specific initialization. So I would vote to keep this. But most probably non-mainline code isn't a reason to keep this? Best regards Dirk so remove the file and the associated calls. Signed-off-by: Fabio Estevam --- arch/arm/cpu/armv7/mx6/Makefile|1 - arch/arm/cpu/armv7/mx6/lowlevel_init.S | 25 - arch/arm/cpu/armv7/start.S | 24 3 files changed, 50 deletions(-) delete mode 100644 arch/arm/cpu/armv7/mx6/lowlevel_init.S diff --git a/arch/arm/cpu/armv7/mx6/Makefile b/arch/arm/cpu/armv7/mx6/Makefile index cbce411..4f9ca68 100644 --- a/arch/arm/cpu/armv7/mx6/Makefile +++ b/arch/arm/cpu/armv7/mx6/Makefile @@ -28,7 +28,6 @@ include $(TOPDIR)/config.mk LIB= $(obj)lib$(SOC).o COBJS = soc.o clock.o -SOBJS = lowlevel_init.o SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c) OBJS := $(addprefix $(obj),$(SOBJS) $(COBJS)) diff --git a/arch/arm/cpu/armv7/mx6/lowlevel_init.S b/arch/arm/cpu/armv7/mx6/lowlevel_init.S deleted file mode 100644 index acadef2..000 --- a/arch/arm/cpu/armv7/mx6/lowlevel_init.S +++ /dev/null @@ -1,25 +0,0 @@ -/* - * Copyright (C) 2010-2011 Freescale Semiconductor, Inc. - * - * 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 - */ -.section ".text.init", "x" - -#include - -ENTRY(lowlevel_init) - mov pc, lr -ENDPROC(lowlevel_init) diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S index 32658eb..4c7c385 100644 --- a/arch/arm/cpu/armv7/start.S +++ b/arch/arm/cpu/armv7/start.S @@ -152,7 +152,6 @@ reset: /* the mask ROM code should have PLL and others stable */ #ifndef CONFIG_SKIP_LOWLEVEL_INIT bl cpu_init_cp15 - bl cpu_init_crit #endif /* Set stackpointer in internal RAM to call board_init_f */ @@ -353,29 +352,6 @@ ENTRY(cpu_init_cp15) mov pc, lr @ back to my caller ENDPROC(cpu_init_cp15) -#ifndef CONFIG_SKIP_LOWLEVEL_INIT -/* - * - * CPU_init_critical registers - * - * setup important registers - * setup memory timing - * - */ -ENTRY(cpu_init_crit) - /* -* Jump to board specific initialization... -* The Mask ROM will have already initialized -* basic memory. Go here to bump up clock rate and handle -* wake up conditions. -*/ - mov ip, lr @ persevere link reg across call - bl lowlevel_init @ go setup pll,mux,memory - mov lr, ip @ restore link - mov pc, lr @ back to my caller -ENDPROC(cpu_init_crit) -#endif - #ifndef CONFIG_SPL_BUILD /* * ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] USB ehci driver query
Hello, I am new to u-boot code. I am reading the usb host controller code for root hub configuration. I have some queries regarding some code. If anyone has got understanding about it pls explain it to me. In usb.c the core calls the usb controller driver (ehci-hcd.c) by issuing command GET_DESCRIPTOR to know the maximum packet size the endpoint supports. It than once again calls the driver by issuing command SET_ADDRESS to give address 1 to root hub. Than it issues command GET_DESCRIPTOR second time and this time creates a queue head(QH) and associated queue transfer descriptors(qTD). The code for this is in function ehci_submit_async() (drivers/usb/host/ehci-hcd.c). I am not getting the purpose of calling this function and what the usb core is achieving by calling it. If anyone can throw some light on it. Regards -- Puneet Sharma The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 13/13] mxc nand: Add support for i.MX5
Hi Scott, On Tuesday, September 18, 2012 3:01:58 AM, Scott Wood wrote: > On Tue, Aug 21, 2012 at 11:04:14PM +0200, Benoît Thébaudeau wrote: > > Signed-off-by: Benoît Thébaudeau > > Cc: Scott Wood > > Cc: Stefano Babic > > --- > > Changes for v2: > > - Fix warning for unused tmp variable in board_nand_init() for NFC > > V1. > > > > .../arch/arm/include/asm/arch-mx5/imx-regs.h |9 + > > .../drivers/mtd/nand/mxc_nand.c| 219 > > +++- > > .../include/fsl_nfc.h | 149 > > - > > .../nand_spl/nand_boot_fsl_nfc.c | 114 > > +++--- > > 4 files changed, 365 insertions(+), 126 deletions(-) > > Is there a board that uses this? I have one, but it's not yet ready for mainline. Some of the current mx51 and mx53 mainline boards could also probably use that as an alternate boot option, but I don't have them to test. Best regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v7 3/4] OMAP: networking support for SPL
This patch adds support for networking in SPL. Some devices are
capable of loading SPL via network so it makes sense to load the
main U-Boot binary via network too. This patch tries to use
existing network code as much as possible. Unfortunately, it depends
on environment which in turn depends on other code so SPL size
is increased significantly. No effort was done to decouple network
code and environment so far.
Signed-off-by: Ilya Yanok
---
Changes in v3:
- use BOOTP in SPL regardless of CONFIG_CMD_DHCP
- add support for setting different VCI in SPL
Changes in v4:
- fix compilation of SPL's libcommon with CONFIG_HUSH_PARSER
and CONFIG_BOOTD defined
- rename spl_eth.c to spl_net.c
- set ethact variable if device name is passed
Changes in v5:
- set up guards in cmd_nvedit.c more carefully
- now we don't need command.c and only need main.c for
show_boot_progress() so defined it to be noop and remove
both files from SPL sources
- SPL guards in command.c and main.c are no longer needed
- add some guards in env_common.c
- qsort.c is no longer needed
- add guard to hashtable.c to save some space
- undefine unneeded CONFIG_CMD_* while building SPL to save space
Changes in v6:
- remove some unneeded changes introduced by earlier versions
- switch clauses and use ifdef instead of ifndef
- create new header config_uncmd_spl.h which undefines CONFIG_CMD_*
options unneeded in SPL and include it last from config.h
- remove explicit undefs from net/net.c and net/bootp.c
Changes in v7:
- remove explicit cmd undef from net/tftp.c also
- add GPLv2 header to config_uncmd_spl.h
- remove CONFIG_SPL_BUILD clause at hang() (not needed)
arch/arm/cpu/armv7/omap-common/Makefile |3 ++
arch/arm/cpu/armv7/omap-common/spl.c |9 ++
arch/arm/cpu/armv7/omap-common/spl_net.c | 52 ++
arch/arm/include/asm/omap_common.h |4 +++
common/Makefile |4 +++
common/cmd_nvedit.c |8 +
common/env_common.c |7 ++--
include/bootstage.h |6 +++-
include/config_uncmd_spl.h | 44 +
lib/Makefile |9 --
lib/hashtable.c |2 ++
mkconfig |1 +
net/bootp.c |7 +++-
spl/Makefile |3 ++
14 files changed, 153 insertions(+), 6 deletions(-)
create mode 100644 arch/arm/cpu/armv7/omap-common/spl_net.c
create mode 100644 include/config_uncmd_spl.h
diff --git a/arch/arm/cpu/armv7/omap-common/Makefile
b/arch/arm/cpu/armv7/omap-common/Makefile
index d37b22d..f042078 100644
--- a/arch/arm/cpu/armv7/omap-common/Makefile
+++ b/arch/arm/cpu/armv7/omap-common/Makefile
@@ -53,6 +53,9 @@ endif
ifdef CONFIG_SPL_YMODEM_SUPPORT
COBJS += spl_ymodem.o
endif
+ifdef CONFIG_SPL_NET_SUPPORT
+COBJS += spl_net.o
+endif
endif
ifndef CONFIG_SPL_BUILD
diff --git a/arch/arm/cpu/armv7/omap-common/spl.c
b/arch/arm/cpu/armv7/omap-common/spl.c
index f0d766c..53b9261 100644
--- a/arch/arm/cpu/armv7/omap-common/spl.c
+++ b/arch/arm/cpu/armv7/omap-common/spl.c
@@ -178,6 +178,15 @@ void board_init_r(gd_t *id, ulong dummy)
spl_ymodem_load_image();
break;
#endif
+#ifdef CONFIG_SPL_ETH_SUPPORT
+ case BOOT_DEVICE_CPGMAC:
+#ifdef CONFIG_SPL_ETH_DEVICE
+ spl_net_load_image(CONFIG_SPL_ETH_DEVICE);
+#else
+ spl_net_load_image(NULL);
+#endif
+ break;
+#endif
default:
printf("SPL: Un-supported Boot Device - %d!!!\n", boot_device);
hang();
diff --git a/arch/arm/cpu/armv7/omap-common/spl_net.c
b/arch/arm/cpu/armv7/omap-common/spl_net.c
new file mode 100644
index 000..cbb3087
--- /dev/null
+++ b/arch/arm/cpu/armv7/omap-common/spl_net.c
@@ -0,0 +1,52 @@
+/*
+ * (C) Copyright 2000-2004
+ * Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+ *
+ * (C) Copyright 2012
+ * Ilya Yanok
+ *
+ * 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.
+ */
+#include
+#include
+#include
+
+DECLARE_GLOBAL_DATA_PTR;
+
+void spl_net_load_image(const char *device)
+{
+ int rv;
+
+ env_init
Re: [U-Boot] [PATCH v6 3/4] OMAP: networking support for SPL
Hi Tom,
On Tue, Sep 18, 2012 at 4:17 AM, Tom Rini wrote:
>
> Please add a GPLv2+ header to the file, thanks.
>
Done.
>
> > diff --git a/lib/vsprintf.c b/lib/vsprintf.c index e38a4b7..6bb819c
> > 100644 --- a/lib/vsprintf.c +++ b/lib/vsprintf.c @@ -784,7 +784,7
> > @@ void panic(const char *fmt, ...) vprintf(fmt, args);
> > putc('\n'); va_end(args); -#if defined (CONFIG_PANIC_HANG) +#if
> > defined (CONFIG_PANIC_HANG) || defined(CONFIG_SPL_BUILD) hang();
> > #else udelay (10);/* allow messages to go out */
>
> Oh no, this change... Do we still really need this?
>
Seems like it's not needed anymore. I've removed it.
>
> > diff --git a/net/tftp.c b/net/tftp.c index 59a8ebb..baba8f3 100644
> > --- a/net/tftp.c +++ b/net/tftp.c @@ -7,6 +7,10 @@ */
> >
> > #include +#ifdef CONFIG_SPL_BUILD +#undef
> > CONFIG_CMD_TFTPPUT +#undef CONFIG_CMD_TFTPSRV +#endif #include
> > #include #include "tftp.h"
>
> Missed this.
>
Yes, sorry.
>
> Also I saw a few manual inclusions of , please fix
> those since mkconfig adds it always. Thanks.
>
Hm, I can't see any.
I reposted only this patch. Hope it's ok now.
Regards, Ilya.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCHv4] [RFC] DM: early_malloc for DM added.
Dear Tomas Hlavacek,
> early_malloc for DM with support for more heaps and lightweight
> first heap on stack.
>
> Adaptation layer for seamless calling of early_malloc or dlmalloc from
> DM based on init stage added (dmmalloc() and related functions).
>
> Signed-off-by: Tomas Hlavacek
> ---
It looks mostly OK, few comments
I'd say, pull out the modification of global data into separate patch and put
it
before this patch. That'd make review of the core code much easier.
[...]
> +
> +#include /* for ROUND_UP */
> +#include
> +#include /* for gd_t and gd */
> +#include /* for phys_addr_t and size_addt_t */
> +
> +#include
> +#include
> +
> +DECLARE_GLOBAL_DATA_PTR;
> +
> +#ifdef CONFIG_SYS_EARLY_MALLOC
> +static struct early_heap_header *def_early_brk(size_t size)
> +{
> + struct early_heap_header *h =
> + (struct early_heap_header *)CONFIG_SYS_EARLY_HEAP_ADDR;
> +
> + h->free_space_pointer = (void *)(roundup(
> + (phys_addr_t)CONFIG_SYS_EARLY_HEAP_ADDR +
> + sizeof(struct early_heap_header),
> + sizeof(phys_addr_t)));
> + h->free_bytes = size - roundup(sizeof(struct early_heap_header),
> + sizeof(phys_addr_t));
> + h->next_early_heap = NULL;
> +
> + return h;
> +}
> +
> +struct early_heap_header *early_brk(size_t size)
> + __attribute__((weak, alias("def_early_brk")));
what about using (it needs ):
__weak struct early_heap_header *early_brk(size_t size)
{
...
body
...
}
> +void *early_malloc(size_t size)
> +{
> + phys_addr_t addr;
> + struct early_heap_header *h;
> +
> + /* Align size. */
> + size = roundup(size, sizeof(phys_addr_t));
> +
> + /* Choose early_heap with enough space. */
> + h = gd->early_heap_first;
> + while ((h->free_bytes < size) && (h->next_early_heap != NULL))
> + h = h->next_early_heap;
> +
> + if (h->free_bytes < size) {
> + debug("Early heap overflow. Heap %p, free %d, required %d.",
> + h, h->free_bytes, size);
> + return NULL;
> + }
> +
> + /* Choose block beginning address and mark next free space. */
> + addr = (phys_addr_t)h->free_space_pointer;
> +
> + h->free_space_pointer += size;
> + h->free_bytes -= size;
> +
> + return (void *)addr;
> +}
> +
> +static int is_early_malloc_active(void)
> +{
> + if (gd->flags & GD_FLG_RELOC)
> + return 0;
> +
> + return 1;
> +}
> +
> +#endif /* CONFIG_SYS_EARLY_MALLOC */
> +
> +void *dmmalloc(size_t size)
> +{
> +#ifdef CONFIG_SYS_EARLY_MALLOC
> + if (is_early_malloc_active())
> + return early_malloc(size);
> +#endif /* CONFIG_SYS_EARLY_MALLOC */
Or you can implement empty prototypes for these functions in case CONFIG_SYS
...
isn't defined to punt this preprocessor bloat.
> + return malloc(size);
> +}
[...]
> diff --git a/include/configs/zipitz2.h b/include/configs/zipitz2.h
> index 26204af..5cd0dcb 100644
> --- a/include/configs/zipitz2.h
> +++ b/include/configs/zipitz2.h
> @@ -176,8 +176,13 @@ unsigned char zipitz2_spi_read(void);
>
> #define CONFIG_SYS_LOAD_ADDRCONFIG_SYS_DRAM_BASE
>
> +#define CONFIG_SYS_EARLY_HEAP_ADDR (GENERATED_GBL_DATA_SIZE + \
> + PHYS_SDRAM_1)
> +#define CONFIG_SYS_EARLY_HEAP_SIZE 256
> +
1) Pull this file into separate patch and order it afterwards this patch.
2) You're putting your early thingie into SDRAM, which works on PXA (sadly) ...
looking through the PXA init code, it needs cleanup, damn
... there's no real hint so far, just a rant.
> #define CONFIG_SYS_SDRAM_BASEPHYS_SDRAM_1
> -#define CONFIG_SYS_INIT_SP_ADDR (GENERATED_GBL_DATA_SIZE +
PHYS_SDRAM_1 +
> 2048) +#define CONFIG_SYS_INIT_SP_ADDR
> (GENERATED_GBL_DATA_SIZE
+ \
> + CONFIG_SYS_EARLY_HEAP_SIZE + PHYS_SDRAM_1 + 2048)
>
> /*
> * NOR FLASH
> @@ -260,4 +265,9 @@ unsigned char zipitz2_spi_read(void);
> #define CONFIG_SYS_MCIO0_VAL 0x0001430f
> #define CONFIG_SYS_MCIO1_VAL 0x0001430f
[...]
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 11/11] S3C24XX: Add support to MINI2416 board
Hi Tom, On 17-09-2012 16:11, Tom Rini wrote: On Mon, Sep 17, 2012 at 03:47:46PM +0100, Jos? Miguel Gon?alves wrote: On 17-09-2012 15:39, Tom Rini wrote: On Sun, Sep 16, 2012 at 10:11:07AM +0100, Jos? Miguel Gon?alves wrote: On 09/14/2012 07:58 PM, Tom Rini wrote: On Fri, Sep 14, 2012 at 06:29:02PM +0100, Jos?? Miguel Gon??alves wrote: The MINI2416 board is based on a Samsung's S3C2416 SoC and has 64MB DDR2 SDRAM, 256MB NAND Flash, a LAN9220 Ethernet Controller and a WM8731 Audio CODEC. This U-Boot port was implemented and tested on a unit bought to Boardcon (http://www.armdesigner.com/) but there are some other chinese providers that can supply it with a selectable NAND chip from 128MB to 1GB. [snip] Can you please try this on top of my SPL framework series? Thanks! I thought I was using the latest SPL framework! Can you please detail on what I should do different? Please see http://www.mail-archive.com/u-boot@lists.denx.de/msg92156.html As this is still not merged, I reckon you only want to check if this new SPL framework works fine with my board. I'm not expected to resubmit my patch to be according with the new framework, correct? v1 of your patches was posted well after the merge window for v2012.10 closed. My SPL series will be merged to mainline shortly (taking care of everyone elses merge requests first). So yes, to get into v2013.01 you will need to update. If you check the archives you can see how the altera soc support changed to adapt to this framework. And if there's a shortcoming in the framework, I really do want to know. Thanks! I already have my board working on the top of this new SPL framework. It was easy to migrate and the interface is easier to use for a new U-Boot developer (like me). Good work! I'll resubmit my new patch later on. Here are my board's SPL sizes for both older and new frameworks: text data bss dec hex filename 4083 8 588 4679 1247 u-boot/spl/u-boot-spl text data bss dec hex filename 3905 160 500 4565 11d5 u-boot-spl-framework/spl/u-boot-spl So I get around 30 bytes of additional IRAM space (text + data). I have a comment, though. As you use memset() to initialize the .bss, wouldn’t be better that CONFIG_SPL_LIBGENERIC_SUPPORT would be automaticaly included when adding CONFIG_SPL_FRAMEWORK to the board config? Best regards, José Gonçalves ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx6: Remove lowlevel_init.S
Hi Dirk, On Tue, Sep 18, 2012 at 5:02 AM, Dirk Behme wrote: > On 17.09.2012 18:34, Fabio Estevam wrote: >> >> lowlevel_init.S is not used on mx6, > > > Yes, but ... > > We use lowlevel_init.S on a not yet public custom board to do some early, > custom specific initialization. So I would vote to keep this. arch/arm/cpu/armv7/mx6/lowlevel_init.S is meant to contain code that is common to all mx6 boards. If you need some specific initialization for your board, I would suggest you to add such code into a C board file, or at least at board///lowlevel_init.S instead. Regards, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] using initrd with U-boot on the imx28evk
Thanks to both of you for following up. Over the weekend, I switched to using the initramfs within the kernel configuration (in the Freescale kernel) and set the source directory to my rootfs that will be the ramdrive and it worked great! So I'll stick with this scenario. It's nice too in that the rootfs (a small one) gets bundled up with the kernel (uImage) so its just one file. So it works out really nice. This is a good way for upgrading firmware from the flash. Best, Bill On 9/17/2012 4:44 PM, Fabio Estevam wrote: Bill, On Mon, Sep 17, 2012 at 6:31 PM, Marek Vasut wrote: Dear Bill, I'm CCing Fabio ... he might have some idea for you. What about starting a thread in linux-arm-kernel for this? Regards, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 2/2] i.MX6: mx6qsabrelite: Add splash screen support
Thanks for the review, Stefano.
On 09/18/2012 12:47 AM, Stefano Babic wrote:
On 18/09/2012 01:14, Eric Nelson wrote:
Hi Eric,
Adds support for the Hannstar 1024 x 768 LVDS panel (Freescale part
number MCIMX-LVDS1) to SABRE-Lite board.
This commit is a rebase Fabio Estevan's patch from 5/31 to
u-boot-video/master:
http://patchwork.ozlabs.org/patch/162206/
Modifications include:
removal of i2c setup (unneeded)
cleanup of lcd_iomux to use struct mxc_ccm_reg and anatop_regs
and associated constants
All this stuff should not be part of the commit message, because it is
more or less a changelog. Should you also include Fabio's signed-off ?
Okay. I'll take it out of V3.
I didn't include Fabio's sign off because he hadn't seen this
yet and I changed a fair amount of code.
Signed-off-by: Eric Nelson
---
arch/arm/include/asm/arch-mx6/crm_regs.h |4 +
board/freescale/mx6qsabrelite/mx6qsabrelite.c | 90 +
include/configs/mx6qsabrelite.h | 14 -
3 files changed, 107 insertions(+), 1 deletions(-)
diff --git a/arch/arm/include/asm/arch-mx6/crm_regs.h
b/arch/arm/include/asm/arch-mx6/crm_regs.h
index 8388e38..cffc0a1 100644
--- a/arch/arm/include/asm/arch-mx6/crm_regs.h
+++ b/arch/arm/include/asm/arch-mx6/crm_regs.h
@@ -294,6 +294,10 @@ struct mxc_ccm_reg {
#define MXC_CCM_CHSCCDR_IPU1_DI0_CLK_SEL_MASK (0x7)
#define MXC_CCM_CHSCCDR_IPU1_DI0_CLK_SEL_OFFSET 0
+#define CHSCCDR_CLK_SEL_LDB_DI03
+#define CHSCCDR_PODF_DIVIDE_BY_3 2
+#define CHSCCDR_IPU_PRE_CLK_540M_PFD 5
+
/* Define the bits in register CSCDR2 */
#define MXC_CCM_CSCDR2_ECSPI_CLK_PODF_MASK(0x3F<< 19)
#define MXC_CCM_CSCDR2_ECSPI_CLK_PODF_OFFSET 19
diff --git a/board/freescale/mx6qsabrelite/mx6qsabrelite.c
b/board/freescale/mx6qsabrelite/mx6qsabrelite.c
index 4b4e89b..1632e7b 100644
--- a/board/freescale/mx6qsabrelite/mx6qsabrelite.c
+++ b/board/freescale/mx6qsabrelite/mx6qsabrelite.c
@@ -36,6 +36,9 @@
#include
#include
#include
+#include
+#include
+#include
DECLARE_GLOBAL_DATA_PTR;
#define UART_PAD_CTRL (PAD_CTL_PKE | PAD_CTL_PUE | \
@@ -195,6 +198,10 @@ static iomux_v3_cfg_t button_pads[] = {
MX6Q_PAD_GPIO_18__GPIO_7_13 | MUX_PAD_CTRL(BUTTON_PAD_CTRL),
};
+iomux_v3_cfg_t lcd_gpio[] = {
+ MX6Q_PAD_SD1_CMD__GPIO_1_18 | MUX_PAD_CTRL(NO_PAD_CTRL),
+};
+
static void setup_iomux_enet(void)
{
gpio_direction_output(IMX_GPIO_NR(3, 23), 0);
@@ -372,10 +379,84 @@ int setup_sata(void)
}
#endif
+static struct fb_videomode lvds_xga = {
+ .name = "Hannstar-XGA",
+ .refresh= 60,
+ .xres = 1024,
+ .yres = 768,
+ .pixclock = 15385,
+ .left_margin= 220,
+ .right_margin = 40,
+ .upper_margin = 21,
+ .lower_margin = 7,
+ .hsync_len = 60,
+ .vsync_len = 10,
+ .sync = FB_SYNC_EXT,
+ .vmode = FB_VMODE_NONINTERLACED
+};
+
+void lcd_iomux(void)
+{
+ struct mxc_ccm_reg *mxc_ccm = (struct mxc_ccm_reg *)CCM_BASE_ADDR;
+ struct anatop_regs *anatop = (struct anatop_regs *)ANATOP_BASE_ADDR;
+
+ int reg;
+ /* Turn on GPIO backlight */
+ imx_iomux_v3_setup_multiple_pads(lcd_gpio, ARRAY_SIZE(lcd_gpio));
+ gpio_direction_output(18, 1);
+
+ /* Turn on LDB0,IPU,IPU DI0 clocks */
+ reg = __raw_readl(&mxc_ccm->CCGR3);
+ reg |= 0x300F;
+ writel(reg,&mxc_ccm->CCGR3);
I think we can add constants for these - at least for these constants,
you could drop the not useful defines with offset like
MXC_CCM_CCGR5_CGx_OFFSET. There is already a patch (not yet merged) for
MX5, we should then doing the same for MX6.
Do you have a reference to the patch so I can follow precedent?
+
+ /* set PFD3_FRAC to 0x13 == 455 MHz (480*18)/0x13 */
+ writel(0x3F00,&anatop->pfd_480_clr);
+ writel(0x1300,&anatop->pfd_480_set);
Add constants for these. They are not already defined, but they are
added when needed, see for example ehci-mx6.c
Ok.
+
+ /* set LDB0, LDB1 clk select to 011/011 */
+ reg = readl(&mxc_ccm->cs2cdr);
+ reg&= ~(MXC_CCM_CS2CDR_LDB_DI0_CLK_SEL_MASK
+|MXC_CCM_CS2CDR_LDB_DI1_CLK_SEL_MASK);
+ reg |= (3cscmr2);
+ reg |= MXC_CCM_CSCMR2_LDB_DI0_IPU_DIV;
+ writel(reg,&mxc_ccm->cscmr2);
+
+ reg = readl(&mxc_ccm->chsccdr);
+ reg&= ~(MXC_CCM_CHSCCDR_IPU1_DI0_PRE_CLK_SEL_MASK
+ |MXC_CCM_CHSCCDR_IPU1_DI0_PODF_MASK
+ |MXC_CCM_CHSCCDR_IPU1_DI0_CLK_SEL_MASK);
+ /* derive clock from LDB_DI0 */
+ /* divide by 3 */
+ /* derive clock from 540M PFD */
Wrong style for a multiline comment
Noted. These are leftovers I used while hand decoding
Re: [U-Boot] [PATCH] mx51evk: Add CONFIG_REVISION_TAG
Hi Greg,
On Tue, Sep 18, 2012 at 10:00 AM, Greg Topmiller
wrote:
> Fabio/Benoit,
>
> I tried the get_board_rev alone and it worked on my mx51evk.
>
> In the FSL u-boot version I am using the set_board_rev is:
> static inline void set_board_rev(int rev)
> {
> system_rev |= (rev & 0xF) << 8;
> }
So you should call it as "set_board_rev(BOARD_REV2)" , where:
#define BOARD_REV2 0x1
I don't think we have boards older than rev2 anymore.
Looking at the FSL kernel, there are are some tests for "if
(board_is_rev(BOARD_REV_2))"
and they should return true from what I can see from the schematics.
841 if (board_is_rev(BOARD_REV_2))
842 /* BB2.5 */
843 ret = gpio_get_value(BABBAGE_SD2_CD_2_5);
844 else
845 /* BB2.0 */
846 ret = gpio_get_value(BABBAGE_SD2_CD_2_0);
847 return ret;
With the original patch from Benoit "board_is_rev(BOARD_REV_2)" would
return falsem which would then assign the wrong SD2 card detect pin,
for example.
Regards,
Fabio Estevam
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx51evk: Add CONFIG_REVISION_TAG
Hi Greg, Fabio,
On Tuesday, September 18, 2012 3:00:58 PM, Greg Topmiller wrote:
> Fabio/Benoit,
>
> I tried the get_board_rev alone and it worked on my mx51evk.
>
> In the FSL u-boot version I am using the set_board_rev is:
> static inline void set_board_rev(int rev)
> {
> system_rev |= (rev & 0xF) << 8;
> }
>
> It is not called for the mx51evk but is used for mx35_3stack.
>
> The set_board_rev code below doesn't make sense when looking at the
> FSL u-boot code or the main line and comparing to the mx51evk
> schematic. I don't see where either the FSL u-boot or the main line
> u-boot set up iomux for GPIO0_22. There are four pin possibilities,
> EIM_EB2, NANDF_CS6, CSPI1_MOSI, and UART3_RXD. On the schematic the
> UART3_RXD is tied low so that would be the only pin to make sense in
> this case. To make the "set_board_rev" code below work the mx51evk
> board specific code would have to set up the UART3_RXD to be
> GPIO0_22 by making its function ALT3. That being said the code
> below would not be a problem since the if logic would most likely be
> positive in any case and the system_rev would be or'd with board rev
> 2.
>
> Let me know if you want the schematic I'm looking at. It's a PDF.
>
> Best Regards,
>
> Greg
>
>
>
> -Original Message-
> From: Fabio Estevam [mailto:feste...@gmail.com]
> Sent: Monday, September 17, 2012 11:25 PM
> To: Benoît Thébaudeau
> Cc: U-Boot-Users ML; Greg Topmiller; Stefano Babic
> Subject: Re: [PATCH] mx51evk: Add CONFIG_REVISION_TAG
>
> Hi Benoît ,
>
> On Mon, Sep 17, 2012 at 4:04 PM, Benoît Thébaudeau
> wrote:
>
> > +u32 get_board_rev(void)
> > +{
> > + return get_cpu_rev();
> > +}
>
> Is this enough? Looking at FSL U-boot there is also a:
>
> static inline void set_board_rev(void)
> {
> if ((__REG(GPIO1_BASE_ADDR + 0x0) & (0x1 << 22)) == 0)
> system_rev |= BOARD_REV_2_0 << BOARD_VER_OFFSET;
>
> }
>
> On mx53loco I had very weird problems when kernel was running and it
> took me sometime to find out that it was due to wrong detection of
> the board revision, so I suggest to double check this to avoid this
> kind of problem on mx51evk too.
>
> Regards,
>
> Fabio Estevam
It looks like there is confusion between the 3stack and Babbage boards here:
Fabio, the code you refer to in FSL U-Boot comes from the Babbage board, while
AFAIK, the mx51evk mainline U-Boot board corresponds to the 3stack board (this
is also FSL's naming for this board on their website).
Best regards,
Benoît
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] using initrd with U-boot on the imx28evk
Dear Bill, > Thanks to both of you for following up. Over the weekend, I switched to > using the initramfs within the kernel configuration (in the Freescale > kernel) and set the source directory to my rootfs that will be the > ramdrive and it worked great! So I'll stick with this scenario. It's > nice too in that the rootfs (a small one) gets bundled up with the > kernel (uImage) so its just one file. So it works out really nice. > This is a good way for upgrading firmware from the flash. Don't you want to check latest linux-next for the mx28 CPU? > Best, > Bill > > On 9/17/2012 4:44 PM, Fabio Estevam wrote: > > Bill, > > > > On Mon, Sep 17, 2012 at 6:31 PM, Marek Vasut wrote: > >> Dear Bill, > >> > >> I'm CCing Fabio ... he might have some idea for you. > > > > What about starting a thread in linux-arm-kernel for this? > > > > Regards, > > > > Fabio Estevam Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx51evk: Add CONFIG_REVISION_TAG
On Tue, Sep 18, 2012 at 10:41 AM, Benoît Thébaudeau wrote: > It looks like there is confusion between the 3stack and Babbage boards here: > Fabio, the code you refer to in FSL U-Boot comes from the Babbage board, while > AFAIK, the mx51evk mainline U-Boot board corresponds to the 3stack board (this > is also FSL's naming for this board on their website). Not really, mx51evk = mx51babbage mx51_3stack is a different board. Regards, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx51evk: Add CONFIG_REVISION_TAG
On Tuesday, September 18, 2012 3:38:02 PM, Fabio Estevam wrote: > On Tue, Sep 18, 2012 at 10:41 AM, Benoît Thébaudeau > wrote: > > > It looks like there is confusion between the 3stack and Babbage > > boards here: > > Fabio, the code you refer to in FSL U-Boot comes from the Babbage > > board, while > > AFAIK, the mx51evk mainline U-Boot board corresponds to the 3stack > > board (this > > is also FSL's naming for this board on their website). > > Not really, > > mx51evk = mx51babbage > > mx51_3stack is a different board. Now, I'm totally confused. FSL's website shows a board that really looks like a "3-stack" board for its i.MX51 EVK: http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=MCIMX51EVKJ&parentCode=i.MX515&fpsp=1 Babbage here, different from i.MX51 EVK: http://ossguy.com/?p=317 So, do you mean that mainline U-Boot board naming is broken for mx51evk? Best regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 2/2] i.MX6: mx6qsabrelite: Add splash screen support
On 18/09/2012 15:28, Eric Nelson wrote: > > Do you have a reference to the patch so I can follow precedent? See http://patchwork.ozlabs.org/patch/177403/ Check changes in .h. 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-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx51evk: Add CONFIG_REVISION_TAG
Hi Benoît, On Tue, Sep 18, 2012 at 10:54 AM, Benoît Thébaudeau wrote: > Now, I'm totally confused. FSL's website shows a board that really looks like > a > "3-stack" board for its i.MX51 EVK: > http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=MCIMX51EVKJ&parentCode=i.MX515&fpsp=1 Yes, the board names are confusing indeed ;-) Let me clarify: This is the official mx51 development board that Freescale makes available. The website calls it mx51evk, which is the name that we use in mainline U-boot. Yes, you can attach a separate LCD and a daughter card to this mx51evk. When the FSL development team started to work on kernel and bootloader for this board, they used the internal name for it: mx51 babbage. The first mx51 board that was designed was called mx51 3stack and it is more of an internal board to the FSL development teams. Looking at FSL u-boot source code, you will see mx51_bbg and mx51_3stack targets. > > Babbage here, different from i.MX51 EVK: > http://ossguy.com/?p=317 This is a mx51evk indeed, but without a WVGA LCD and the daughter card and put in a plastic shell. > So, do you mean that mainline U-Boot board naming is broken for mx51evk? No, the name in U-boot mainline is fine and it matches the name in the website. Hopefully I managed to clarify the board name confusion. But back to the original patch: all you need to do is to pass set_board_rev(BOARD_REV2), so that the kernel can correctly identify the board revision correctly. Regards, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 2/2] i.MX6: mx6qsabrelite: Add splash screen support
On 09/17/2012 04:43 PM, Fabio Estevam wrote:
Hi Eric,
On Mon, Sep 17, 2012 at 8:14 PM, Eric Nelson
wrote:
Adds support for the Hannstar 1024 x 768 LVDS panel (Freescale part
number MCIMX-LVDS1) to SABRE-Lite board.
This commit is a rebase Fabio Estevan's patch from 5/31 to
s/Estevan/Estevam
+int board_late_init(void)
+{
+ setenv("stdout", "serial");
+ return 0;
+}
Please see my previous comment on v1 about this.
Wolfgang nacked this method and Stefano has proposed a nice way for
keeping the console in serial. Check mx53loco and mx51evk.
Hi Fabio and Stefano,
While trying to understand this, I wonder whether the
use of overwrite_console() addresses Wolfgang's original
concern.
I think the suggestion was to set the preboot variable
to change things:
#define CONFIG_PREBOOT "setenv stdout serial"
The has the benefit of allowing saveenv to completely
overwrite the decision.
Am I over-thinking this?
Please advise,
Eric
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx51evk: Add CONFIG_REVISION_TAG
On Tue, Sep 18, 2012 at 11:02 AM, Fabio Estevam wrote: > But back to the original patch: all you need to do is to pass > set_board_rev(BOARD_REV2), so that the kernel can correctly identify > the board revision correctly. To make it clearer: get_board_rev should return 0x51100 , where 0x51 is SoC type and the 8th bit (1 is the board revision). Regards, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] using initrd with U-boot on the imx28evk
Good idea. Best, Bill On 9/18/2012 8:36 AM, Marek Vasut wrote: Dear Bill, Thanks to both of you for following up. Over the weekend, I switched to using the initramfs within the kernel configuration (in the Freescale kernel) and set the source directory to my rootfs that will be the ramdrive and it worked great! So I'll stick with this scenario. It's nice too in that the rootfs (a small one) gets bundled up with the kernel (uImage) so its just one file. So it works out really nice. This is a good way for upgrading firmware from the flash. Don't you want to check latest linux-next for the mx28 CPU? Best, Bill On 9/17/2012 4:44 PM, Fabio Estevam wrote: Bill, On Mon, Sep 17, 2012 at 6:31 PM, Marek Vasut wrote: Dear Bill, I'm CCing Fabio ... he might have some idea for you. What about starting a thread in linux-arm-kernel for this? Regards, Fabio Estevam Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx51evk: Add CONFIG_REVISION_TAG
On Tue, Sep 18, 2012 at 11:16 AM, Greg Topmiller
wrote:
> So how about something like this in the board specific code?
>
> u32 get_board_rev(void)
> {
> u32 myrev = get_cpu_rev();
> myrev |= 0x100; /* BOARD_REV_2 */
> return myrev;
> }
Looks good, Greg.
Regards,
Fabio Estevam
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx51evk: Add CONFIG_REVISION_TAG
On 18/09/2012 15:41, Benoît Thébaudeau wrote:
> Hi Greg, Fabio,
>
> On Tuesday, September 18, 2012 3:00:58 PM, Greg Topmiller wrote:
>> Fabio/Benoit,
>>
>> I tried the get_board_rev alone and it worked on my mx51evk.
>>
>> In the FSL u-boot version I am using the set_board_rev is:
>> static inline void set_board_rev(int rev)
>> {
>> system_rev |= (rev & 0xF) << 8;
>> }
>>
>> It is not called for the mx51evk but is used for mx35_3stack.
>>
>> The set_board_rev code below doesn't make sense when looking at the
>> FSL u-boot code or the main line and comparing to the mx51evk
>> schematic. I don't see where either the FSL u-boot or the main line
>> u-boot set up iomux for GPIO0_22. There are four pin possibilities,
>> EIM_EB2, NANDF_CS6, CSPI1_MOSI, and UART3_RXD. On the schematic the
>> UART3_RXD is tied low so that would be the only pin to make sense in
>> this case. To make the "set_board_rev" code below work the mx51evk
>> board specific code would have to set up the UART3_RXD to be
>> GPIO0_22 by making its function ALT3. That being said the code
>> below would not be a problem since the if logic would most likely be
>> positive in any case and the system_rev would be or'd with board rev
>> 2.
>>
>> Let me know if you want the schematic I'm looking at. It's a PDF.
>>
>> Best Regards,
>>
>> Greg
>>
>>
>>
>> -Original Message-
>> From: Fabio Estevam [mailto:feste...@gmail.com]
>> Sent: Monday, September 17, 2012 11:25 PM
>> To: Benoît Thébaudeau
>> Cc: U-Boot-Users ML; Greg Topmiller; Stefano Babic
>> Subject: Re: [PATCH] mx51evk: Add CONFIG_REVISION_TAG
>>
>> Hi Benoît ,
>>
>> On Mon, Sep 17, 2012 at 4:04 PM, Benoît Thébaudeau
>> wrote:
>>
>>> +u32 get_board_rev(void)
>>> +{
>>> + return get_cpu_rev();
>>> +}
>>
>> Is this enough? Looking at FSL U-boot there is also a:
>>
>> static inline void set_board_rev(void)
>> {
>> if ((__REG(GPIO1_BASE_ADDR + 0x0) & (0x1 << 22)) == 0)
>> system_rev |= BOARD_REV_2_0 << BOARD_VER_OFFSET;
>>
>> }
>>
>> On mx53loco I had very weird problems when kernel was running and it
>> took me sometime to find out that it was due to wrong detection of
>> the board revision, so I suggest to double check this to avoid this
>> kind of problem on mx51evk too.
>>
>> Regards,
>>
>> Fabio Estevam
>
> It looks like there is confusion between the 3stack and Babbage boards here:
> Fabio, the code you refer to in FSL U-Boot comes from the Babbage board, while
> AFAIK, the mx51evk mainline U-Boot board corresponds to the 3stack board (this
> is also FSL's naming for this board on their website).
There has been always confusion about Freescale's names.
Babbage was the internal name for the first mx51 development board. When
this board becomes available, it was referenced on Freescale's website
as "mx51evk". So babbage = mx51evk.
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-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx51evk: Add CONFIG_REVISION_TAG
On 18/09/2012 16:02, Fabio Estevam wrote: > >> So, do you mean that mainline U-Boot board naming is broken for mx51evk? > > No, the name in U-boot mainline is fine and it matches the name in the > website. Right. I dislike if the name is different as the official name. As we can see, this generates a lot of confusion. IMHO we should also align some other boards, such as mx53loco that is officially called mx53qsb. 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-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 2/2] i.MX6: mx6qsabrelite: Add splash screen support
On 18/09/2012 16:02, Eric Nelson wrote: > > Hi Fabio and Stefano, > > While trying to understand this, I wonder whether the > use of overwrite_console() addresses Wolfgang's original > concern. > > I think the suggestion was to set the preboot variable > to change things: Wolfgang's first concern was to avoid to hardcode variable inside the code, as it was done in the original mx51 / mx53 code (and not only in i.MX boards). > > #define CONFIG_PREBOOT "setenv stdout serial" This makes sense if you want maintain the possibility that u-boot output is displayed on the LCD. Is this really the case ? In most cases, we want to display a splashscreen, while the console is still managed by serial line. If this is the case, adding overwrite_console() tells video subsystem to not change the stdout variable, and then it is not required to set it back to serial neither in code nor with the help of the preboot variable. > The has the benefit of allowing saveenv to completely > overwrite the decision. > > Am I over-thinking this? It depends if you want also U-Boot's output on the display or only a picture. 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-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] mx51evk: Add CONFIG_REVISION_TAG
FSL 2.6.35 kernel assumes that the bootloader passes the CONFIG_REVISION_TAG
information.
If this data is not present, the kernel misconfigures the TZIC, which results in
the timer interrupt handler never being called, so the kernel deadlocks while
calibrating its delay.
Suggested-by: Greg Topmiller
Signed-off-by: Benoît Thébaudeau
Cc: Stefano Babic
Cc: Fabio Estevam
---
Changes for v2:
- Add board revision to SoC revision from GPIO1[22] pin information.
.../arch/arm/include/asm/arch-mx5/imx-regs.h |2 ++
.../board/freescale/mx51evk/mx51evk.c |8
.../include/configs/mx51evk.h |1 +
3 files changed, 11 insertions(+)
diff --git u-boot-imx-1d9b033.orig/arch/arm/include/asm/arch-mx5/imx-regs.h
u-boot-imx-1d9b033/arch/arm/include/asm/arch-mx5/imx-regs.h
index d1ef15d..46017f4 100644
--- u-boot-imx-1d9b033.orig/arch/arm/include/asm/arch-mx5/imx-regs.h
+++ u-boot-imx-1d9b033/arch/arm/include/asm/arch-mx5/imx-regs.h
@@ -321,6 +321,8 @@
#define BOARD_REV_1_0 0x0
#define BOARD_REV_2_0 0x1
+#define BOARD_VER_OFFSET 0x8
+
#define IMX_IIM_BASE(IIM_BASE_ADDR)
#if !(defined(__KERNEL_STRICT_NAMES) || defined(__ASSEMBLY__))
diff --git u-boot-imx-1d9b033.orig/board/freescale/mx51evk/mx51evk.c
u-boot-imx-1d9b033/board/freescale/mx51evk/mx51evk.c
index 7a0682a..a94701c 100644
--- u-boot-imx-1d9b033.orig/board/freescale/mx51evk/mx51evk.c
+++ u-boot-imx-1d9b033/board/freescale/mx51evk/mx51evk.c
@@ -60,6 +60,14 @@ int dram_init(void)
return 0;
}
+u32 get_board_rev(void)
+{
+ u32 rev = get_cpu_rev();
+ if (!gpio_get_value(IMX_GPIO_NR(1, 22)))
+ rev |= BOARD_REV_2_0 << BOARD_VER_OFFSET;
+ return rev;
+}
+
static void setup_iomux_uart(void)
{
unsigned int pad = PAD_CTL_HYS_ENABLE | PAD_CTL_PKE_ENABLE |
diff --git u-boot-imx-1d9b033.orig/include/configs/mx51evk.h
u-boot-imx-1d9b033/include/configs/mx51evk.h
index ba4a4a6..7b027b4 100644
--- u-boot-imx-1d9b033.orig/include/configs/mx51evk.h
+++ u-boot-imx-1d9b033/include/configs/mx51evk.h
@@ -44,6 +44,7 @@
#define CONFIG_CMDLINE_TAG /* enable passing of ATAGs */
#define CONFIG_SETUP_MEMORY_TAGS
#define CONFIG_INITRD_TAG
+#define CONFIG_REVISION_TAG
#define CONFIG_OF_LIBFDT
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-mmc.git
On Thu, Sep 06, 2012 at 03:37:22PM -0500, Andy Fleming wrote: > Merge branch 'master' of git://git.denx.de/u-boot-avr32 (2012-09-04 > 09:17:27 +0200) > > are available in the git repository at: > > > git://www.denx.de/git/u-boot-mmc.git master > > for you to fetch changes up to 95b01c47ed97a7ca8b59308e35fb8c21e8d996a5: > > mmc: Remove incorrect cmd->flags usage (2012-09-06 15:23:13 -0500) > > > Andy Fleming (1): > mmc: Remove incorrect cmd->flags usage > > Beno??t Th??baudeau (2): > mmc_get_dev: Return error if mmc_init fails > mmcinfo: Fix help message > > Jaehoon Chung (3): > mmc: s5p_sdhci: set the SDHCI_QUIRK_BROKEN_R1B > mmc: s5p_sdhci: fixed wrong function argument > mmc: s5p_sdhci: add the set_mmc_clk for cmu control > > Joe Hershberger (2): > mmc: Fix version check for clock API in sdhci driver > mmc: Add a SDHCI quirk for boards that have no CD > > Jongman Heo (1): > mmc: fix wrong timeout check in mmc_send_status() > > Mikhail Kshevetskiy (1): > MMC: u-boot-spl may be compiled without partition support > > Stephen Warren (3): > mmc: detect boot sectors using EXT_CSD_BOOT_MULT too > env_mmc: allow environment to be in an eMMC partition > tegra: put eMMC environment into the boot sectors > > Yoshihiro Shimoda (2): > mmc: sh_mmcif: enable MMC_MODE_HC > mmc: fix capacity calculation when EXT_CSD_SEC_CNT is used > > arch/arm/include/asm/arch-exynos/mmc.h |4 +- > arch/arm/include/asm/arch-s5pc1xx/mmc.h |4 +- > common/cmd_mmc.c|3 +- > common/env_mmc.c| 64 > +++ > drivers/mmc/arm_pl180_mmci.c|2 +- > drivers/mmc/mmc.c | 20 +- > drivers/mmc/pxa_mmc_gen.c |8 ++-- > drivers/mmc/s5p_sdhci.c | 18 - > drivers/mmc/sdhci.c | 30 +++ > drivers/mmc/sh_mmcif.c |2 +- > include/configs/paz00.h |3 +- > include/configs/seaboard.h |3 +- > include/configs/trats.h |1 + > include/configs/ventana.h |3 +- > include/configs/whistler.h |3 +- > include/mmc.h |1 + > include/sdhci.h |9 - > 17 files changed, 129 insertions(+), 49 deletions(-) Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-ubi/master
On Mon, Sep 10, 2012 at 11:41:49AM +0200, Stefan Roese wrote: > The following changes since commit a6f0c4faa4c65a7b7048b12c9d180d7e1aad1721: > > Merge branch 'master' of git://git.denx.de/u-boot-avr32 (2012-09-04 > 09:17:27 +0200) > > are available in the git repository at: > > > git://www.denx.de/git/u-boot-ubi.git master > > for you to fetch changes up to 8044c1387f7f8acb2a82f64f1b087848395deb15: > > ubifs: Fix ubifsload when using ZLIB (2012-09-10 11:37:42 +0200) > > > Veli-Pekka Peltola (1): > ubifs: Fix ubifsload when using ZLIB > > fs/ubifs/ubifs.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request - microblaze
On Wed, Sep 12, 2012 at 12:13:17PM +0200, Michal Simek wrote: > Dear Wolfgang, > > please pull the following changes to your tree. > > Thanks, > Michal > > > The following changes since commit a6f0c4faa4c65a7b7048b12c9d180d7e1aad1721: > Wolfgang Denk (1): > Merge branch 'master' of git://git.denx.de/u-boot-avr32 > > are available in the git repository at: > > git://www.denx.de/git/u-boot-microblaze.git master > > Michal Simek (10): > block: systemace: Simplify base and width initialization > serial: Support serial multi for Microblaze > serial: uartlite: Init all uartlites for serial multi > microblaze: Add support for device tree driven board configuration > microblaze: board: Remove compilation warning > microblaze: intc: Registering interrupt should return value > microblaze: intc: Coding style cleanup > microblaze: timer: Prepare for device-tree initialization > microblaze: Clean microblaze initialization > microblaze: board: Use bi_flashstart instead of CONFIG_SYS_FLASH_BASE > > Stephan Linz (1): > spi: xilinx: Remove unused variable > > arch/microblaze/config.mk |2 + > arch/microblaze/cpu/interrupts.c | 42 ++-- > arch/microblaze/cpu/start.S|2 +- > arch/microblaze/cpu/timer.c| 69 ++- > arch/microblaze/cpu/u-boot.lds |1 + > arch/microblaze/include/asm/global_data.h |1 + > arch/microblaze/include/asm/microblaze_intc.h | 11 +++- > arch/microblaze/include/asm/microblaze_timer.h |3 + > arch/microblaze/include/asm/processor.h|3 + > arch/microblaze/lib/board.c| 59 ++--- > .../xilinx/microblaze-generic/microblaze-generic.c |9 +++ > drivers/block/systemace.c | 38 +++ > drivers/serial/serial_xuartlite.c | 34 ++ > drivers/spi/xilinx_spi.c |1 - > include/configs/microblaze-generic.h | 12 +--- > include/serial.h |3 +- > 16 files changed, 171 insertions(+), 119 deletions(-) Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PULL] Please pull u-boot-avr32/master
On Thu, Sep 13, 2012 at 01:38:33PM +0200, Andreas Bie??mann wrote: > Dear Tom Rini, > > these two patches should go into this release. The 'Fix strict-aliasing' is a > very old patch which was a long time untested. The new board was posted way > before merge window close but required a patch that came through u-boot-arm, > therefore it is so late. > > The following changes since commit a6f0c4faa4c65a7b7048b12c9d180d7e1aad1721: > > Merge branch 'master' of git://git.denx.de/u-boot-avr32 (2012-09-04 > 09:17:27 +0200) > > are available in the git repository at: > > > git://git.denx.de/u-boot-avr32.git master > > for you to fetch changes up to a420dfe2b017db321ad9b4058d38e216b756465f: > > avr32: add atngw100mkii board (2012-09-13 13:33:11 +0200) > > > Andreas Bie??mann (1): > avr32: add atngw100mkii board > > Simon Glass (1): > Fix strict-aliasing warning in dlmalloc > > MAINTAINERS |1 + > board/atmel/atngw100mkii/Makefile | 40 ++ > board/atmel/atngw100mkii/atngw100mkii.c | 156 +++ > boards.cfg |1 + > common/dlmalloc.c | 10 +- > include/configs/atngw100mkii.h | 209 > +++ > 6 files changed, 412 insertions(+), 5 deletions(-) > create mode 100644 board/atmel/atngw100mkii/Makefile > create mode 100644 board/atmel/atngw100mkii/atngw100mkii.c > create mode 100644 include/configs/atngw100mkii.h Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-mips/master
On Fri, Sep 14, 2012 at 04:04:36AM +0200, Daniel Schwierzeck wrote: > Hi Tom, > > this one is without qemu_mips64 support and without any warnings. > > > The following changes since commit e66443fdb5355e68cfdbbdd37248c4b7eb4968f5: > > Makefile: fix HAVE_VENDOR_COMMON_LIB (2012-08-17 18:07:12 +0200) > > are available in the git repository at: > > git://git.denx.de/u-boot-mips.git master > > for you to fetch changes up to 748fd4a621a870d378e4e4f54df76a38fd5d3cba: > > MIPS: add support for qemu for little endian MIPS32 CPUs (2012-08-24 > 00:34:47 +0200) > > > Daniel Schwierzeck (3): > MIPS: factor out endianess flag handling to arch config.mk > MIPS: move CONFIG_STANDALONE_LOAD_ADDR to CPU config makefiles > MIPS: add support for qemu for little endian MIPS32 CPUs > > Marek Vasut (4): > dm: mips: Fix lb60 WDT control > dm: mips: Fix lb60 timer code > dm: mips: Fix warnings in lb60 board > dm: mips: Import libgcc components from Linux > > arch/mips/config.mk| 20 +--- > arch/mips/cpu/mips32/config.mk | 19 ++- > arch/mips/cpu/xburst/config.mk |5 +++-- > arch/mips/cpu/xburst/cpu.c |2 +- > arch/mips/cpu/xburst/timer.c | 12 ++-- > arch/mips/lib/Makefile | 20 > arch/mips/lib/ashldi3.c| 25 + > arch/mips/lib/ashrdi3.c| 27 +++ > arch/mips/lib/libgcc.h | 25 + > arch/mips/lib/lshrdi3.c| 25 + > board/qi/qi_lb60/qi_lb60.c |4 ++-- > boards.cfg |3 ++- > include/configs/qemu-mips.h|7 ++- > include/configs/qi_lb60.h |1 + > 14 files changed, 162 insertions(+), 33 deletions(-) > create mode 100644 arch/mips/lib/ashldi3.c > create mode 100644 arch/mips/lib/ashrdi3.c > create mode 100644 arch/mips/lib/libgcc.h > create mode 100644 arch/mips/lib/lshrdi3.c Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-fdt
On Sat, Sep 15, 2012 at 09:54:14AM -0400, Jerry Van Baren wrote: > Dear Tom, > > Please pull u-boot-fdt. This contains the FDT null address bug fix from > Marek. > > Thanks, > gvb > > P.S. Tom - Resent because I sent to the list from the wrong email account. > > The following changes since commit a6f0c4faa4c65a7b7048b12c9d180d7e1aad1721: > > Merge branch 'master' of git://git.denx.de/u-boot-avr32 (2012-09-04 > 09:17:27 +0200) > > are available in the git repository at: > > > git://git.denx.de/u-boot-fdt.git master > > for you to fetch changes up to e02c9458748a59e5d80649deb5e40f96ed992bb5: > > fdt: Check if the FDT address is configured (2012-09-15 09:16:08 -0400) > > > Marek Vasut (1): > fdt: Check if the FDT address is configured > > common/cmd_fdt.c | 13 - > 1 file changed, 12 insertions(+), 1 deletion(-) Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [i2c] Pull request
On Mon, Sep 17, 2012 at 12:03:44PM +0200, Heiko Schocher wrote: > Hello Tom, > > The following changes since commit a6f0c4faa4c65a7b7048b12c9d180d7e1aad1721: > > Merge branch 'master' of git://git.denx.de/u-boot-avr32 (2012-09-04 > 09:17:27 +0200) > > are available in the git repository at: > > git://git.denx.de/u-boot-i2c.git master > > Koen Kooi (1): > omap4 i2c: add support for i2c bus 4 > > ??ukasz Majewski (2): > i2c:soft:multi: Support for multiple soft I2C buses at Samsung boards > i2c:soft:multi: Enable soft I2C multibus at Trats development board > > arch/arm/include/asm/arch-omap4/cpu.h |1 + > arch/arm/include/asm/arch-omap4/i2c.h |2 +- > board/samsung/common/Makefile | 43 ++ > board/samsung/common/multi_i2c.c | 65 > + > board/samsung/trats/trats.c | 15 > drivers/i2c/omap24xx_i2c.c|8 > include/configs/trats.h | 24 + > include/i2c.h | 12 ++ > 8 files changed, 162 insertions(+), 8 deletions(-) > create mode 100644 board/samsung/common/Makefile > create mode 100644 board/samsung/common/multi_i2c.c Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Cache alignment warnings on Tegra (ARM)
On Mon, Sep 17, 2012 at 02:39:01PM -0700, Simon Glass wrote: > Hi Thierry, > > On Sat, Sep 15, 2012 at 11:49 PM, Thierry Reding > wrote: > > On Sat, Sep 15, 2012 at 07:45:30PM -0700, Simon Glass wrote: > >> Hi, > >> > >> On Sat, Sep 15, 2012 at 1:41 PM, Thierry Reding > >> wrote: > >> > On Sat, Sep 15, 2012 at 10:11:54PM +0200, Marek Vasut wrote: > >> >> Dear Thierry Reding, > >> >> > >> >> > On Fri, Sep 14, 2012 at 08:53:32AM -0700, Simon Glass wrote: > >> >> > > Hi, > >> >> > > > >> >> > > On Wed, Sep 12, 2012 at 4:42 PM, Marek Vasut wrote: > >> >> > > > Dear Stephen Warren, > >> >> > > > > >> >> > > >> On 09/12/2012 04:38 PM, Marek Vasut wrote: > >> >> > > >> > Dear Stephen Warren, > >> >> > > >> > > >> >> > > >> >> On 09/12/2012 10:19 AM, Tom Warren wrote: > >> >> > > >> >>> Folks, > >> >> > > >> >>> > >> >> > > >> >>> Stephen Warren has posted an internal bug regarding the cache > >> >> > > >> >>> alignment 'warnings' seen on Tegra20 boards when accessing > >> >> > > >> >>> MMC. > >> >> > > >> >>> Here's the gist: > >> >> > > >> >>> > >> >> > > >> >>> Executing "mmc dev 0" still yields cache warnings: > >> >> > > >> >>> > >> >> > > >> >>> Tegra20 (Harmony) # mmc dev 0 > >> >> > > >> >>> ERROR: v7_dcache_inval_range- stop address is not aligned- > >> >> > > >> >>> 0x3fb69908 mmc0 is current device > >> >> > > >> >> > >> >> > > >> >> ... > >> >> > > >> >> > >> >> > > >> >>> There have been patches in the past (IIRC) that have tried to > >> >> > > >> >>> ensure all callers (FS, MMC driver, USB driver, etc.) force > >> >> > > >> >>> their > >> >> > > >> >>> buffers to the appropriate alignment, but I don't know that > >> >> > > >> >>> we > >> >> > > >> >>> can ever correct every instance, now or in the future. > >> >> > > >> >>> > >> >> > > >> >>> Can we start a discussion about what we can do about this > >> >> > > >> >>> warning? > >> >> > > >> >>> Adding an appropriate #ifdef > >> >> > > >> >>> (CONFIG_SYS_NO_CACHE_ALIGNMENT_WARNINGS, etc.) where Stephen > >> >> > > >> >>> put > >> >> > > >> >>> his #if 0's would be one approach, or changing the printf() > >> >> > > >> >>> to a > >> >> > > >> >>> debug(), perhaps. As far as I can tell, these alignment > >> >> > > >> >>> 'errors' > >> >> > > >> >>> don't seem to produce bad data in the transfer. > >> >> > > >> >> > >> >> > > >> >> I don't think simply turning off the warning is the correct > >> >> > > >> >> approach; I believe they represent real problems that can in > >> >> > > >> >> fact > >> >> > > >> >> cause data corruption. I don't believe we have any choice > >> >> > > >> >> other > >> >> > > >> >> than to fully solve the root-cause. > >> >> > > > >> >> > > Yes I agree, and I think it is pretty close - certainly much better > >> >> > > than it used to be. The good thing about them being annoying is that > >> >> > > they will likely get fixed :-) > >> >> > > >> >> > I think I traced this to the copying of CSD a while back. The problem > >> >> > is > >> >> > that the transferred buffer is 8 bytes, so there's no way to make it > >> >> > aligned properly. Unfortunately the entailing discussion did not > >> >> > yield a > >> >> > solution at the time. > >> >> > >> >> And how exactly does the MMC bounce buffer not help here? > >> > > >> > The problem solved by the bounce buffer is that it is properly cache- > >> > line aligned. However the issue here is not that the buffer is not > >> > properly aligned but rather that the transfer is too small. > >> > > >> > When the MMC core transfers the SCR, it requests 8 bytes. The buffer > >> > used to store these 8 bytes is properly allocated. However, those 8 > >> > bytes eventually end up as the size of the range that is to be > >> > invalidated. This is the reason for the warning. Address x of the buffer > >> > is cache-line aligned, but x + 8 is never properly aligned and therefore > >> > the code complains. > >> > >> Would it be too dreadful to define a minimum MMC transfer size, and > >> set that to the cache line size? > > > > I did try setting the data size to the cache line size back then, but > > that resulted in an error. After that I gave up. I think what we really > > need to do is separate the invalidation size from the transfer size in > > order to properly handle these situations. Or alternatively pass an > > additional buffer size so the code knows how much needs to be > > invalidated. AFAICT this is the only location where this actually > > happens. All other transfers are typically block sized so they'll be a > > multiple of the cache line anyway. > > I suppose the requirement is that the buffer size is large enough, and > is aligned. Even if fewer bytes are transferred than the size of the > buffer, that still solves the problem. As you say, if we had a way of > saying 'here is a 64-byte buffer but only 16 bytes need to be > transferred' then we would be good. If this is really just an MMC > problem then perhaps the fix can be localised there. At least on Tegra that is the on
Re: [U-Boot] [GIT PULL] mpc83xx: mpc8308rdb enhancements
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/17/12 20:09, Ira W. Snyder wrote: > On Mon, Sep 17, 2012 at 06:18:12PM -0700, Tom Rini wrote: >> On Mon, Sep 17, 2012 at 06:36:56PM -0500, Kim Phillips wrote: >>> Hi Tom, >>> >>> Ira improved mpc8308rdb h/w support by making it more >>> comprehensive. Please pull: >>> >>> The following changes since commit >>> a6f0c4faa4c65a7b7048b12c9d180d7e1aad1721: >>> >>> Merge branch 'master' of git://git.denx.de/u-boot-avr32 >>> (2012-09-04 09:17:27 +0200) >>> >>> are available in the git repository at: >>> >>> >>> git://git.denx.de/u-boot-mpc83xx.git master >>> >>> for you to fetch changes up to >>> 014d1dfc669ab2295d7fa4ec4b9f00a4004917a0: >>> >>> mpc8308rdb: add support for eSDHC MMC controller (2012-09-17 >>> 17:47:12 -0500) >>> >>> >>> >>> Ira W. Snyder (5): >>> mpc8xxx_spi: fix SPI support on MPC8308RDB mpc8308rdb: add >>> support for Spansion SPI flash on header J8 spansion: add >>> support for S25FL256S1 mpc8308rdb: add support for FIT images >>> mpc8308rdb: add support for eSDHC MMC controller >>> >>> board/freescale/mpc8308rdb/mpc8308rdb.c | 58 >>> + drivers/mtd/spi/spansion.c >>> | 8 + drivers/spi/mpc8xxx_spi.c | 4 +++ >>> include/configs/MPC8308RDB.h| 31 >>> ++ 4 files changed, 101 insertions(+) >> >> A number of boards (P2020RDB-PC_36BIT is the one I looked at the >> log in) now fail: spansion.c:74:3: error: unknown field >> 'page_size' specified in initializer >> >> Rejected, please fix, sorry. >> >> -- Tom > > Tom, > > Go ahead and drop the patch "spansion: add support for S25FL256S1" > from the series. The rest should apply without any trouble. > > Michal Simek beat me to it in "sf: spansion: Add support for > S25FL256S" (4a4cb4e1114). He got the idcode1 wrong (it should be > 0x0219 instead of 0x2019), but I saw a followup patch on the > mailing list to fix it. This is good to know. My preference however is for a new pull request with whatever corrections Kim deems necessary. Thanks! - -- Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQIcBAEBAgAGBQJQWIvDAAoJENk4IS6UOR1WJ28P/1Kg3p/mTJdkgDFjKjzKURer Nv9IGEMYEF5VxA7DY7CVDutCMGeeZIf+/oiU7gsBH0Qk/NxgOmn9GYzr/IDfAuQu 69DKyQ6M0n01yk9C4/w5GjT+cAfrp9oz30Y1hKaq7TOVp79pRDX/CRfxVp/Mk8RL QkDq/QghCzIhC5VH/JP3544VbpSIKdMkTdOoTrzG7319YYZgvYrvEh0w4vBAnqtK SB6zaIQZYelVFKsl5EnhcB2WCnwRc6jM23nd+wRycd/VsQanrQsr8xlTo11apvBm JmXcNUNeVuRgZFpwISuzsaAdxgsUw9TifP2Di854RzG8GoVhUlcvKCV0KWD8Q2WA 5/9O2sl7fKYmAsYCQWrjdpHBjSJZpFOwA3E0K+aohCCPX840i5imOZZWlyOr2VTF k20dUpcIkmi1c8gaJGkHJzsRYhragY8pWTpIxBN3PFjc/MGSWB8loRseg/rJ2BDi fb2KAVbcp9j/vF60FDc4LSuSIaIdw3tbsAlC/mk4NLRCqPdFJUYYm0pwyAoZycFK eFb+73i+vVSUkBThQuJrGW+t9EdVgy8xO2Be7dDjqgAeD166YnQynaicfSfe6Eck lkE5ExuW3ehUDU7ooEMApYXMKkP+m6YrlGBkoN/ShzLsCHbaBejEDtYJfWp1WYaI 3pTd7PFAQM+CnuAZjLK9 =/6OP -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Weekly status
On Mon, Sep 17, 2012 at 07:31:32AM -0700, Tom Rini wrote: > Hey all, > > I had intended to send this last thing Friday but it slipped my mind. > But with my intention to do -rc1 this Friday, this works too. That > said... > > Here's where I'm at so far: > - Locally, I believe I have all outstanding pull requets queued up and > MAKEALL'd when there's an ELDK toolchain. > - Working out the access issues with Detlev. We've worked this out today (as the batch of applied merge request emails hint at). I'm looking for any further pull requests I missed then moving onto individual patches (didn't want to queue up too much in the tree before pushing). Looking on-track for Friday. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] mx51evk: Add CONFIG_REVISION_TAG
On Tue, Sep 18, 2012 at 11:48 AM, Benoît Thébaudeau wrote: > FSL 2.6.35 kernel assumes that the bootloader passes the CONFIG_REVISION_TAG > information. > > If this data is not present, the kernel misconfigures the TZIC, which results > in > the timer interrupt handler never being called, so the kernel deadlocks while > calibrating its delay. > > Suggested-by: Greg Topmiller > Signed-off-by: Benoît Thébaudeau > Cc: Stefano Babic > Cc: Fabio Estevam Acked-by: Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 2/2] i.MX6: mx6qsabrelite: Add splash screen support
Thanks Stefano, On 09/18/2012 07:42 AM, Stefano Babic wrote: On 18/09/2012 16:02, Eric Nelson wrote: Hi Fabio and Stefano, While trying to understand this, I wonder whether the use of overwrite_console() addresses Wolfgang's original concern. I think the suggestion was to set the preboot variable to change things: Wolfgang's first concern was to avoid to hardcode variable inside the code, as it was done in the original mx51 / mx53 code (and not only in i.MX boards). #define CONFIG_PREBOOT "setenv stdout serial" This makes sense if you want maintain the possibility that u-boot output is displayed on the LCD. Is this really the case ? Sometimes it is. We have customers of SABRE Lite that are new to embedded who have had to purchase serial adapters upon receiving their boards, though this is rare. The other main use case is simpler: a serial port isn't hooked up during boot (i.e. in a production environment). In production, it would be more convenient to hook up a USB keyboard if needed. In most cases, we want to display a splashscreen, while the console is still managed by serial line. If this is the case, adding overwrite_console() tells video subsystem to not change the stdout variable, and then it is not required to set it back to serial neither in code nor with the help of the preboot variable. The has the benefit of allowing saveenv to completely overwrite the decision. Am I over-thinking this? It depends if you want also U-Boot's output on the display or only a picture. I'll rework the patch with overwrite_console() and keep these options in mind. Thanks for the tips. Regards, Eric ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx51evk: Add CONFIG_REVISION_TAG
Fabio,
On Tuesday, September 18, 2012 5:24:57 AM, Fabio Estevam wrote:
> Hi Benoît ,
>
> On Mon, Sep 17, 2012 at 4:04 PM, Benoît Thébaudeau
> wrote:
>
> > +u32 get_board_rev(void)
> > +{
> > + return get_cpu_rev();
> > +}
>
> Is this enough? Looking at FSL U-boot there is also a:
>
> static inline void set_board_rev(void)
> {
> if ((__REG(GPIO1_BASE_ADDR + 0x0) & (0x1 << 22)) == 0)
> system_rev |= BOARD_REV_2_0 << BOARD_VER_OFFSET;
>
> }
I have a question regarding this code: Is it normal that it does not enable a
weak pull-up (100 k) on UART3_RXD's pad? According to the schematic history, the
pull-down R6001 (10 k) has been added to UART3_RXD for revision 2. By default,
the pad of this pin has its keeper enabled, not its pull, so everything is fine
with this code for revision 2, but what about revision 1?
To reformulate my question: Was there anything on this board before R6001
inputting a high level on UART3_RXD, or does the pad keeper guarantee some
default init level by design if the pin is externally left floating?
Best regards,
Benoît
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx51evk: Add CONFIG_REVISION_TAG
Benoît, On Tue, Sep 18, 2012 at 1:01 PM, Benoît Thébaudeau wrote: > I have a question regarding this code: Is it normal that it does not enable a > weak pull-up (100 k) on UART3_RXD's pad? According to the schematic history, > the > pull-down R6001 (10 k) has been added to UART3_RXD for revision 2. By default, > the pad of this pin has its keeper enabled, not its pull, so everything is > fine > with this code for revision 2, but what about revision 1? I don't know the history about this change between rev1 versus rev2. I would need to check with the board designer. Regards, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: nand flash
On Mon, Sep 17, 2012 at 08:21:14PM -0500, Scott Wood wrote: > The following changes since commit a6f0c4faa4c65a7b7048b12c9d180d7e1aad1721: > > Merge branch 'master' of git://git.denx.de/u-boot-avr32 (2012-09-04 > 09:17:27 +0200) > > are available in the git repository at: > > > git://git.denx.de/u-boot-nand-flash.git master > > for you to fetch changes up to 9c60e75e05dab5a0197728b6a940aaac02762936: > > mxc nand: Homogenize IP revisions with Linux (2012-09-17 19:51:45 -0500) > > > Beno?t Th?baudeau (12): [snip] > mtd mxc nand: Use _mxc_nand_enable_hwecc() On mxc platforms this introduced: mxc_nand.c: In function 'board_nand_init': mxc_nand.c:1170:11: warning: unused variable 'tmp' [-Wunused-variable] I've done the trivial fixup and committed that as well. The whole request is applied, with the above note, to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/71] serial: Massive rework of the serial subsystem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/17/12 16:12, Marek Vasut wrote: > Dear Tom Rini, > >> On Mon, Sep 17, 2012 at 01:20:25AM +0200, Marek Vasut wrote: >>> This patchset is a STAGE 1 of preparation of the stdio and >>> serial subsys for the driver model. >> >> [snip] >> >>> 6) Remove unused code used for the non-multi operation >>> >>> Remove code that was used when CONFIG_SERIAL_MULTI was not >>> selected. Also remove all occurances of CONFIG_SERIAL_MULTI >>> throughout the source tree. Some parts of the code must have >>> been adjusted to cope with this since they were initially only >>> written for non-multi operation. These were minor adjustments >>> mostly in macros though. >> >> So we've simplified the code in that now we only have one way of >> talking with the serial ports. And the drivers are a bit more >> uniform as well. Making the difference between drivers be "here >> is how you poke the hardware" rather than "here is how I >> implemented a serial driver and oh, here is how you poke the >> hardware" is good. > > Correct > >> But what's the next step? > > So... > > 2) Rework stdio, make the creation of struct stdio_dev static > instead of dynamic 3) struct serial_device is superset of struct > stdio_dev ... make use of it, make stdio and serial subsystems > closer 4) The massive list of callbacks in serial.c is stupid, > pull out the linker section maker thingie (thing used to make > driver lists there, similar to command lists from u-boot) from the > DM tree and allow generation of list of serial drivers > automagically. === 5) Flip over to DM, it's only one step away > >> Have you any thoughts on trying to be clever and in the case of >> only one port anyways getting the size back? > > This has been on my mind for a while after seeing those extra 3k > of code all around. Yet, I'm afraid this won't play well with the > DM's pile of pointers. > > On the other hand, my stdio rework (step 2) managed to trim down > the size a bit, so that might be small compensation. Can you give us a current example, both to help make sure everyone understands we won't have too big a growth overall and so that if you don't shrink it down I can pin you about it later? Thanks! - -- Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQIcBAEBAgAGBQJQWKR9AAoJENk4IS6UOR1WvdAP/jAoFi6gJXzg4fso5230f4Kq nZwtvRJ+gJT4ycUTZvTK0YY6KD0fmKPNgah3xVfAUlSNdnAMz/G/B2yOGekLr801 3MuV1h5BXwKotxbhFBPm1bfoIsCPwBi5nZRJTxuFjVihKhihR0VhHt0sSp5WwGkT RCNpiDKahj99ZhsKlE9AkTMHZ8xQ+EXgy/WeMeVN5s0sgyG8clIfScKTmCHGIzD6 v0AbVsSyMX3Nm/qX8Mh35mMq6Zc6fQ7lszIzWATjY/9Rg6k40Qb7EH60N79namWh THyRhDes3OU3KzS1qmEL1wK/AO3YF+2/4xWIniaZZKuB87g5BeG8DCrlGCGXeHpF s/7sBZ1VOwoRevEaCQnFT2pV5J+i0PNHV3IXfukYFClxfcoK1VxfO7bLDhrmbz+h xYUDAjJ+9Ytx+aayZi8sOnE4tmPs2ZqBZhw6wjN3VRyxeTgwCbxJN317UsSd5drq XHuX9/00w7EVcER4NoDsqC8Catos3qVwQdjkkvdWrm3yRlvAgLU4zhCXKunUi+ZZ BBPEllxOcv3mHSPijyokJNcaezL3T7R7qgIpcoViSU6xt7vaxLQoqSuw4qHSeboC WJSAKS7F4N5WTtosF4GiQNCQgshFt3xMdG+1GIQNZmRNbug/KWx3G2lXZfCTMPOU pTjdMe6FIS4E2awXhyOw =/TmM -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 62/71] serial: spl: Implement empty functions for SPL
On Mon, Sep 17, 2012 at 01:21:27AM +0200, Marek Vasut wrote:
> Implement empty serial_* functions for SPL without serial
> support enabled. This is imperative to haave once serial
> multi is enabled unconditionally.
>
> Signed-off-by: Marek Vasut
> Cc: Marek Vasut
> Cc: Tom Rini
> ---
> common/serial.c | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/common/serial.c b/common/serial.c
> index 631af65..cef4ba8 100644
> --- a/common/serial.c
> +++ b/common/serial.c
> @@ -27,6 +27,16 @@
> #include
> #include
>
> +/* Implement prototypes for SPL without serial support */
> +#if defined(CONFIG_SPL_BUILD) && !defined(CONFIG_SPL_SERIAL_SUPPORT)
> +int serial_init(void) { return 0; }
> +void serial_setbrg(void) {}
> +int serial_getc(void) { return 0; }
> +int serial_tstc(void) { return 0; }
> +void serial_putc(const char c) {}
> +void serial_puts(const char *s) {}
This isn't quite right. We need to allow for:
- No output SPL, strings collected (so #defined to do{} while (0))
- puts + printf SPL (CONFIG_SPL_SERIAL_SUPPORT +
CONFIG_SPL_LIBCOMMON_SUPPORT)
- puts only SPL (CONFIG_SPL_SERIAL_SUPPORT + #define puts
serial_puts/putc).
I'm not asking you to do that, but you will have to adapt to it once
Jose is done with it. What that means, off the top of my head, is we
can just drop this patch as in the first and last case serial.o will be
garbage-collected (or not built) and in the middle case, this will be
fully used.
--
Tom
signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC] mx6qsabresd: Add Ethernet support
Add Ethernet support.
Signed-off-by: Fabio Estevam
---
Hi,
As far as I can see mx6qarm2 and mx6qsabresd has the same circuitry related to
AR8031 Ethernet PHY.
However, with this patch I still get 25MHz instead of 125MHz in the AR8031 CLKO
pin and Ethernet is not functional.
Any ideas are appreciated.
Thanks!
board/freescale/mx6qsabresd/mx6qsabresd.c | 84 +
include/configs/mx6qsabresd.h | 13 -
2 files changed, 95 insertions(+), 2 deletions(-)
diff --git a/board/freescale/mx6qsabresd/mx6qsabresd.c
b/board/freescale/mx6qsabresd/mx6qsabresd.c
index c86b51b..4f47fd3 100644
--- a/board/freescale/mx6qsabresd/mx6qsabresd.c
+++ b/board/freescale/mx6qsabresd/mx6qsabresd.c
@@ -56,6 +56,24 @@ iomux_v3_cfg_t uart1_pads[] = {
MX6Q_PAD_CSI0_DAT11__UART1_RXD | MUX_PAD_CTRL(UART_PAD_CTRL),
};
+iomux_v3_cfg_t enet_pads[] = {
+ MX6Q_PAD_KEY_COL1__ENET_MDIO| MUX_PAD_CTRL(ENET_PAD_CTRL),
+ MX6Q_PAD_KEY_COL2__ENET_MDC | MUX_PAD_CTRL(ENET_PAD_CTRL),
+ MX6Q_PAD_RGMII_TXC__ENET_RGMII_TXC | MUX_PAD_CTRL(ENET_PAD_CTRL),
+ MX6Q_PAD_RGMII_TD0__ENET_RGMII_TD0 | MUX_PAD_CTRL(ENET_PAD_CTRL),
+ MX6Q_PAD_RGMII_TD1__ENET_RGMII_TD1 | MUX_PAD_CTRL(ENET_PAD_CTRL),
+ MX6Q_PAD_RGMII_TD2__ENET_RGMII_TD2 | MUX_PAD_CTRL(ENET_PAD_CTRL),
+ MX6Q_PAD_RGMII_TD3__ENET_RGMII_TD3 | MUX_PAD_CTRL(ENET_PAD_CTRL),
+ MX6Q_PAD_RGMII_TX_CTL__RGMII_TX_CTL | MUX_PAD_CTRL(ENET_PAD_CTRL),
+ MX6Q_PAD_ENET_REF_CLK__ENET_TX_CLK | MUX_PAD_CTRL(ENET_PAD_CTRL),
+ MX6Q_PAD_RGMII_RXC__ENET_RGMII_RXC | MUX_PAD_CTRL(ENET_PAD_CTRL),
+ MX6Q_PAD_RGMII_RD0__ENET_RGMII_RD0 | MUX_PAD_CTRL(ENET_PAD_CTRL),
+ MX6Q_PAD_RGMII_RD1__ENET_RGMII_RD1 | MUX_PAD_CTRL(ENET_PAD_CTRL),
+ MX6Q_PAD_RGMII_RD2__ENET_RGMII_RD2 | MUX_PAD_CTRL(ENET_PAD_CTRL),
+ MX6Q_PAD_RGMII_RD3__ENET_RGMII_RD3 | MUX_PAD_CTRL(ENET_PAD_CTRL),
+ MX6Q_PAD_RGMII_RX_CTL__RGMII_RX_CTL | MUX_PAD_CTRL(ENET_PAD_CTRL),
+};
+
iomux_v3_cfg_t usdhc3_pads[] = {
MX6Q_PAD_SD3_CLK__USDHC3_CLK | MUX_PAD_CTRL(USDHC_PAD_CTRL),
MX6Q_PAD_SD3_CMD__USDHC3_CMD | MUX_PAD_CTRL(USDHC_PAD_CTRL),
@@ -71,6 +89,11 @@ static void setup_iomux_uart(void)
imx_iomux_v3_setup_multiple_pads(uart1_pads, ARRAY_SIZE(uart1_pads));
}
+static void setup_iomux_enet(void)
+{
+ imx_iomux_v3_setup_multiple_pads(enet_pads, ARRAY_SIZE(enet_pads));
+}
+
#ifdef CONFIG_FSL_ESDHC
struct fsl_esdhc_cfg usdhc_cfg[1] = {
{USDHC3_BASE_ADDR},
@@ -95,9 +118,70 @@ u32 get_board_rev(void)
return 0x63000;
}
+
+#define MII_MMD_ACCESS_CTRL_REG0xd
+#define MII_MMD_ACCESS_ADDR_DATA_REG 0xe
+#define MII_DBG_PORT_REG 0x1d
+#define MII_DBG_PORT2_REG 0x1e
+
+int fecmxc_mii_postcall(int phy)
+{
+ unsigned short val;
+
+ /*
+* Due to the i.MX6Q SabreSD board HW design,there is
+* no 125Mhz clock input from SOC. In order to use RGMII,
+* We need enable AR8031 ouput a 125MHz clk from CLK_25M
+*/
+ miiphy_write("FEC", phy, MII_MMD_ACCESS_CTRL_REG, 0x7);
+ miiphy_write("FEC", phy, MII_MMD_ACCESS_ADDR_DATA_REG, 0x8016);
+ miiphy_write("FEC", phy, MII_MMD_ACCESS_CTRL_REG, 0x4007);
+ miiphy_read("FEC", phy, MII_MMD_ACCESS_ADDR_DATA_REG, &val);
+ val &= 0xffe3;
+ val |= 0x18;
+ miiphy_write("FEC", phy, MII_MMD_ACCESS_ADDR_DATA_REG, val);
+
+ /* For the RGMII phy, we need enable tx clock delay */
+ miiphy_write("FEC", phy, MII_DBG_PORT_REG, 0x5);
+ miiphy_read("FEC", phy, MII_DBG_PORT2_REG, &val);
+ val |= 0x0100;
+ miiphy_write("FEC", phy, MII_DBG_PORT2_REG, val);
+
+ miiphy_write("FEC", phy, MII_BMCR, 0xa100);
+
+ return 0;
+}
+
+int board_eth_init(bd_t *bis)
+{
+ struct eth_device *dev;
+ int ret;
+
+ ret = cpu_eth_init(bis);
+ if (ret) {
+ printf("FEC MXC: %s:failed\n", __func__);
+ return ret;
+ }
+
+ dev = eth_get_dev_by_name("FEC");
+ if (!dev) {
+ printf("FEC MXC: Unable to get FEC device entry\n");
+ return -EINVAL;
+ }
+
+ ret = fecmxc_register_mii_postcall(dev, fecmxc_mii_postcall);
+ if (ret) {
+ printf("FEC MXC: Unable to register FEC mii postcall\n");
+ return ret;
+ }
+
+ return 0;
+}
+
int board_early_init_f(void)
{
setup_iomux_uart();
+ setup_iomux_enet();
return 0;
}
diff --git a/include/configs/mx6qsabresd.h b/include/configs/mx6qsabresd.h
index 448ce28..0f8bcf6 100644
--- a/include/configs/mx6qsabresd.h
+++ b/include/configs/mx6qsabresd.h
@@ -33,9 +33,8 @@
#define CONFIG_REVISION_TAG
/* Size of malloc() pool */
-#define CONFIG_SYS_MALLOC_LEN CONFIG_ENV_SIZE
+#define CONFIG_SYS_MALLOC_LEN (CONFIG_ENV_SIZE + 2 * 1024 * 1024)
-#define CONFIG_ARCH_CPU_INIT
#define CONFI
Re: [U-Boot] [PATCH 00/71] serial: Massive rework of the serial subsystem
Dear Tom Rini, [...] > > On the other hand, my stdio rework (step 2) managed to trim down > > the size a bit, so that might be small compensation. > > Can you give us a current example, both to help make sure everyone > understands we won't have too big a growth overall and so that if you > don't shrink it down I can pin you about it later? Thanks! You're definitelly going to poke me about it later, since the DM will cause a size growth. There's no discussion about it and it's a simple fact we have to face and accept. If we're going to hunt every kb of growth, we can flat out stop the DM and give up, sorry. Here are some measurements, but they're not final. Something grew a bit and something did not grew: Configuring for omap3_beagle board... textdata bss dec hex filename 3269128648 266944 602504 93188 ./u-boot 3266578764 266792 602213 93065 ./u-boot 457941860 198020 245674 3bfaa ./spl/u-boot-spl 458171868 198020 245705 3bfc9 ./spl/u-boot-spl You see the SPL grew, U-Boot shrunk. But the size difference is of tens of bytes magnitude. Configuring for sandbox board... textdata bss dec hex filename 1386746456 28504 173634 2a642 ./u-boot 1390026512 28424 173938 2a772 ./u-boot Configuring for grsim_leon2 board... textdata bss dec hex filename 9705833842640 103082 192aa ./u-boot 9710634482592 103146 192ea ./u-boot Configuring for P1020RDB-PC_36BIT_SPIFLASH - Board: p1_p2_rdb_pc, Options: P1020RDB,36BIT,SPIFLASH textdata bss dec hex filename 394550 30940 267600 693090 a9362 ./u-boot 394601 31068 267536 693205 a93d5 ./u-boot Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 62/71] serial: spl: Implement empty functions for SPL
Dear Tom Rini,
> On Mon, Sep 17, 2012 at 01:21:27AM +0200, Marek Vasut wrote:
> > Implement empty serial_* functions for SPL without serial
> > support enabled. This is imperative to haave once serial
> > multi is enabled unconditionally.
> >
> > Signed-off-by: Marek Vasut
> > Cc: Marek Vasut
> > Cc: Tom Rini
> > ---
> >
> > common/serial.c | 12
> > 1 file changed, 12 insertions(+)
> >
> > diff --git a/common/serial.c b/common/serial.c
> > index 631af65..cef4ba8 100644
> > --- a/common/serial.c
> > +++ b/common/serial.c
> > @@ -27,6 +27,16 @@
> >
> > #include
> > #include
> >
> > +/* Implement prototypes for SPL without serial support */
> > +#if defined(CONFIG_SPL_BUILD) && !defined(CONFIG_SPL_SERIAL_SUPPORT)
> > +int serial_init(void) { return 0; }
> > +void serial_setbrg(void) {}
> > +int serial_getc(void) { return 0; }
> > +int serial_tstc(void) { return 0; }
> > +void serial_putc(const char c) {}
> > +void serial_puts(const char *s) {}
>
> This isn't quite right. We need to allow for:
> - No output SPL, strings collected (so #defined to do{} while (0))
Which is not type-checked and will drag in bugs.
> - puts + printf SPL (CONFIG_SPL_SERIAL_SUPPORT +
> CONFIG_SPL_LIBCOMMON_SUPPORT)
> - puts only SPL (CONFIG_SPL_SERIAL_SUPPORT + #define puts
> serial_puts/putc).
>
> I'm not asking you to do that, but you will have to adapt to it once
> Jose is done with it. What that means, off the top of my head, is we
> can just drop this patch as in the first and last case serial.o will be
> garbage-collected (or not built) and in the middle case, this will be
> fully used.
I can't drop this patch as it will break all of SPL when CONFIG_SERIAL_MULTI is
unconditionally enabled.
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] using initrd with U-boot on the imx28evk
Dear Bill, In message <505875a7.3040...@techsi.com> you wrote: > Thanks to both of you for following up. Over the weekend, I switched to > using the initramfs within the kernel configuration (in the Freescale > kernel) and set the source directory to my rootfs that will be the > ramdrive and it worked great! So I'll stick with this scenario. It's > nice too in that the rootfs (a small one) gets bundled up with the > kernel (uImage) so its just one file. So it works out really nice. > This is a good way for upgrading firmware from the flash. Actually it's a way that is limited in many respects, and nearly always there are better solutions. If just having one file is important to you, there are other approaches to acchieve the same. Using a FIT image with U-Boot would be a very flexible and powerful way (see doc/uImage.FIT/*), but even a simple multi-file image would do that, and probably better. 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 human race is faced with a cruel choice: work or daytime tele- vision. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 08/71] serial: Implement serial_initfunc() macro
On Mon, Sep 17, 2012 at 01:20:33AM +0200, Marek Vasut wrote:
> This macro simplifies declaration of weak aliases for per-driver
> functions, which register these drivers with the serial subsystem.
> The idea here is to push serial_register() calls from serial.c into
> the drivers. To avoid pile of ifdef construct as it is now, create
> weak aliases to these functions, which in case the driver is not
> present alias onto an empty function, which is in turn optimized out
> altogether.
So, did you consider and throw out the idea of something like:
common/serial.c:
void serial_initalize(void) {
platform_serial_register();
serial_assign(default_serial_console()->name);
}
And then every serial driver, instead of having to add a new weak
function to common/serial.c and a new function call just defines
platform_serial_register.
Or do you run into platforms that want two different serial drivers AND
you couldn't solve that with a combination of weak functions and
board-specific platform_serial_register?
--
Tom
signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 01/11] Add configuration option to select printf() inclusion on SPL
The printf() implementation needs 4~5KB of storage space which may not be
available when building an SPL for SoCs with scarce internal RAM
(8KB or less). This patch adds a new option, CONFIG_SPL_PRINTF_SUPPORT,
to deal with this.
Signed-off-by: José Miguel Gonçalves
---
Changes for v3:
- new patch
---
README |3 +++
include/common.h | 11 +++
2 files changed, 14 insertions(+)
diff --git a/README b/README
index 016d8bc..988812c 100644
--- a/README
+++ b/README
@@ -2576,6 +2576,9 @@ FIT uImage format:
CONFIG_SPL_LIBCOMMON_SUPPORT
Support for common/libcommon.o in SPL binary
+ CONFIG_SPL_PRINTF_SUPPORT
+ Enable printf() support in common/libcommon.o
+
CONFIG_SPL_LIBDISK_SUPPORT
Support for disk/libdisk.o in SPL binary
diff --git a/include/common.h b/include/common.h
index 55025c0..c10d745 100644
--- a/include/common.h
+++ b/include/common.h
@@ -805,9 +805,20 @@ inttstc(void);
/* stdout */
void putc(const char c);
void puts(const char *s);
+/*
+ * The printf() implementation needs 4~5KB of storage space which may not be
+ * available when building an SPL for SoCs with scarce internal RAM
+ * (8KB or less). To force printf() inclusion on an SPL we must define
+ * CONFIG_SPL_LIBCOMMON_SUPPORT and CONFIG_SPL_PRINTF_SUPPORT.
+ */
+#if !defined(CONFIG_SPL_BUILD) || defined(CONFIG_SPL_PRINTF_SUPPORT)
intprintf(const char *fmt, ...)
__attribute__ ((format (__printf__, 1, 2)));
intvprintf(const char *fmt, va_list args);
+#else
+#define printf(fmt...) do {} while (0)
+#define vprintf(fmt, args) do {} while (0)
+#endif
/* stderr */
#define eputc(c) fputc(stderr, c)
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 05/11] serial: Remove unnecessary delay in serial_s3c24x0
The loop used to make a delay after baudrate setting is not necessary. Moreover it is removed by the GCC optimizer (at least with GCC 4.6). Signed-off-by: José Miguel Gonçalves --- Changes for v2: - New patch Changes for v3: - None --- drivers/serial/serial_s3c24x0.c |3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/serial/serial_s3c24x0.c b/drivers/serial/serial_s3c24x0.c index c9bc121..ec5d1cb 100644 --- a/drivers/serial/serial_s3c24x0.c +++ b/drivers/serial/serial_s3c24x0.c @@ -111,15 +111,12 @@ void _serial_setbrg(const int dev_index) struct s3c24x0_uart *uart = s3c24x0_get_base_uart(dev_index); u32 pclk; u32 baudrate; - int i; pclk = get_PCLK(); baudrate = gd->baudrate; writel((pclk / baudrate / 16) - 1, &uart->ubrdiv); writel(udivslot[(pclk / baudrate) % 16], &uart->udivslot); - for (i = 0; i < 100; i++) - /* Delay */ ; } #if defined(CONFIG_SERIAL_MULTI) -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 07/11] rtc: Fix rtc_reset() on s3c24x0_rtc
rtc_reset() must set the RTC date to the UNIX Epoch.
Signed-off-by: José Miguel Gonçalves
---
Changes for v2:
- New patch
Changes for v3:
- None
---
drivers/rtc/s3c24x0_rtc.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/rtc/s3c24x0_rtc.c b/drivers/rtc/s3c24x0_rtc.c
index b31dc53..3fd5cec 100644
--- a/drivers/rtc/s3c24x0_rtc.c
+++ b/drivers/rtc/s3c24x0_rtc.c
@@ -167,10 +167,17 @@ int rtc_set(struct rtc_time *tmp)
void rtc_reset(void)
{
- struct s3c24x0_rtc *rtc = s3c24x0_get_base_rtc();
-
- writeb((readb(&rtc->rtccon) & ~0x06) | 0x08, &rtc->rtccon);
- writeb(readb(&rtc->rtccon) & ~(0x08 | 0x01), &rtc->rtccon);
+ static struct rtc_time tmp = {
+ .tm_year = 1970,
+ .tm_mon = 1,
+ .tm_mday = 1,
+ .tm_wday = 4,
+ .tm_hour = 0,
+ .tm_min = 0,
+ .tm_sec = 0,
+ };
+
+ rtc_set(&tmp);
}
#endif
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 04/11] serial: Use a more precise baud rate generation for serial_s3c24x0
The values stored in the baud rate divisor register (UBRDIVn) and dividing
slot register (UDIVSLOTn), are used to determine the serial baudrate.
Previously only UBRDIVn was set. This patch initializes also UDIVSLOTn
which allows to obtain a more precise baudrate.
Signed-off-by: José Miguel Gonçalves
---
Changes for v2:
- New patch
Changes for v3:
- Verbose patch description
---
drivers/serial/serial_s3c24x0.c | 24
1 file changed, 20 insertions(+), 4 deletions(-)
diff --git a/drivers/serial/serial_s3c24x0.c b/drivers/serial/serial_s3c24x0.c
index 280cd2d..c9bc121 100644
--- a/drivers/serial/serial_s3c24x0.c
+++ b/drivers/serial/serial_s3c24x0.c
@@ -92,16 +92,32 @@ DECLARE_GLOBAL_DATA_PTR;
static int hwflow;
#endif
+/*
+ * The values stored in the baud rate divisor register (UBRDIVn) and dividing
+ * slot register (UDIVSLOTn), are used to determine the serial Tx/Rx clock rate
+ * (baud rate) as follows:
+ * DIV_VAL = UBRDIVn + (num of 1’s in UDIVSLOTn) / 16
+ * Using UDIVSLOT, which is the factor of floating point divisor, you can make
+ * more accurate baud rate. Section 2.1.10 of the S3C2416 User's Manual
suggests
+ * using the constants on the following table.
+ */
+static const int udivslot[] = {
+ 0x, 0x0080, 0x0808, 0x0888, 0x, 0x4924, 0x4A52, 0x54AA,
+ 0x, 0xD555, 0xD5D5, 0xDDD5, 0x, 0xDFDD, 0xDFDF, 0xFFDF,
+};
+
void _serial_setbrg(const int dev_index)
{
struct s3c24x0_uart *uart = s3c24x0_get_base_uart(dev_index);
- unsigned int reg = 0;
+ u32 pclk;
+ u32 baudrate;
int i;
- /* value is calculated so : (int)(PCLK/16./baudrate) -1 */
- reg = get_PCLK() / (16 * gd->baudrate) - 1;
+ pclk = get_PCLK();
+ baudrate = gd->baudrate;
- writel(reg, &uart->ubrdiv);
+ writel((pclk / baudrate / 16) - 1, &uart->ubrdiv);
+ writel(udivslot[(pclk / baudrate) % 16], &uart->udivslot);
for (i = 0; i < 100; i++)
/* Delay */ ;
}
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 00/11] S3C24XX: Add support to MINI2416 board
Support for the MINI2416 board based on a Samsung's S3C2416 SoC with 64MB DDR2 SDRAM, 256MB NAND Flash, a LAN9220 Ethernet Controller and a WM8731 Audio CODEC. Changes for v2: - Coding style cleanup - Removed new serial and rtc drivers - Use of in-tree serial and rtc drivers Changes for v3: - Rebased on new SPL framework: http://github.com/trini/u-boot WIP/spl-improvements - Removed patch "ARM: fix relocation on ARM926EJS" - Add patch to configure printf() inclusion on SPL - Changed new binary target name from u-boot-ubl.bin to u-boot-pad.bin - Removed magic numbers - Checkpatch clean except: - False positive: ERROR: spaces required around that ':' (ctx:VxV) #692: FILE: include/configs/mini2416.h:165: +#define CONFIG_ETHADDR FE:11:22:33:44:55 - Following preexistent coding style: WARNING: please, no spaces at the start of a line #1716: FILE: include/common.h:631: +defined(CONFIG_S3C24XX) || \$ José Miguel Gonçalves (11): Add configuration option to select printf() inclusion on SPL S3C24XX: Add core support for Samsung's S3C24XX SoCs serial: Add support to 4 ports in serial_s3c24x0 serial: Use a more precise baud rate generation for serial_s3c24x0 serial: Remove unnecessary delay in serial_s3c24x0 rtc: Improve rtc_get() on s3c24x0_rtc rtc: Fix rtc_reset() on s3c24x0_rtc rtc: Don't allow setting unsuported years on s3c24x0_rtc S3C24XX: Add NAND Flash driver Add u-boot-pad.bin target to the Makefile S3C24XX: Add support to MINI2416 board MAINTAINERS |4 + Makefile| 11 +- README |3 + arch/arm/cpu/arm926ejs/s3c24xx/Makefile | 56 +++ arch/arm/cpu/arm926ejs/s3c24xx/cpu.c| 57 +++ arch/arm/cpu/arm926ejs/s3c24xx/cpu_info.c | 57 +++ arch/arm/cpu/arm926ejs/s3c24xx/s3c2412_speed.c | 114 + arch/arm/cpu/arm926ejs/s3c24xx/s3c2416_speed.c | 116 + arch/arm/cpu/arm926ejs/s3c24xx/timer.c | 152 ++ arch/arm/include/asm/arch-s3c24xx/s3c2412.h | 130 + arch/arm/include/asm/arch-s3c24xx/s3c2416.h | 183 +++ arch/arm/include/asm/arch-s3c24xx/s3c24x0_cpu.h | 41 ++ arch/arm/include/asm/arch-s3c24xx/s3c24xx.h | 615 +++ arch/arm/include/asm/arch-s3c24xx/s3c24xx_cpu.h | 30 ++ arch/arm/include/asm/arch-s3c24xx/spl.h | 29 ++ board/boardcon/mini2416/Makefile| 47 ++ board/boardcon/mini2416/config.mk |4 + board/boardcon/mini2416/mini2416.c | 104 board/boardcon/mini2416/mini2416_spl.c | 203 board/boardcon/mini2416/u-boot-spl.lds | 63 +++ boards.cfg |1 + drivers/mtd/nand/Makefile |1 + drivers/mtd/nand/s3c24xx_nand.c | 246 + drivers/rtc/s3c24x0_rtc.c | 30 +- drivers/serial/serial_s3c24x0.c | 52 +- include/common.h| 12 + include/configs/VCMA9.h |2 +- include/configs/mini2416.h | 202 include/configs/smdk2410.h |2 +- 29 files changed, 2540 insertions(+), 27 deletions(-) create mode 100644 arch/arm/cpu/arm926ejs/s3c24xx/Makefile create mode 100644 arch/arm/cpu/arm926ejs/s3c24xx/cpu.c create mode 100644 arch/arm/cpu/arm926ejs/s3c24xx/cpu_info.c create mode 100644 arch/arm/cpu/arm926ejs/s3c24xx/s3c2412_speed.c create mode 100644 arch/arm/cpu/arm926ejs/s3c24xx/s3c2416_speed.c create mode 100644 arch/arm/cpu/arm926ejs/s3c24xx/timer.c create mode 100644 arch/arm/include/asm/arch-s3c24xx/s3c2412.h create mode 100644 arch/arm/include/asm/arch-s3c24xx/s3c2416.h create mode 100644 arch/arm/include/asm/arch-s3c24xx/s3c24x0_cpu.h create mode 100644 arch/arm/include/asm/arch-s3c24xx/s3c24xx.h create mode 100644 arch/arm/include/asm/arch-s3c24xx/s3c24xx_cpu.h create mode 100644 arch/arm/include/asm/arch-s3c24xx/spl.h create mode 100644 board/boardcon/mini2416/Makefile create mode 100644 board/boardcon/mini2416/config.mk create mode 100644 board/boardcon/mini2416/mini2416.c create mode 100644 board/boardcon/mini2416/mini2416_spl.c create mode 100644 board/boardcon/mini2416/u-boot-spl.lds create mode 100644 drivers/mtd/nand/s3c24xx_nand.c create mode 100644 include/configs/mini2416.h -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 08/11] rtc: Don't allow setting unsuported years on s3c24x0_rtc
This RTC only supports a 100 years range so rtc_set() should not allow setting
years bellow 1970 or above 2069.
Signed-off-by: José Miguel Gonçalves
---
Changes for v2:
- New patch
Changes for v3:
- None
---
drivers/rtc/s3c24x0_rtc.c |5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/rtc/s3c24x0_rtc.c b/drivers/rtc/s3c24x0_rtc.c
index 3fd5cec..bcd6d44 100644
--- a/drivers/rtc/s3c24x0_rtc.c
+++ b/drivers/rtc/s3c24x0_rtc.c
@@ -139,6 +139,11 @@ int rtc_set(struct rtc_time *tmp)
tmp->tm_year, tmp->tm_mon, tmp->tm_mday, tmp->tm_wday,
tmp->tm_hour, tmp->tm_min, tmp->tm_sec);
#endif
+ if (tmp->tm_year < 1970 || tmp->tm_year > 2069) {
+ puts("ERROR: year should be between 1970 and 2069!\n");
+ return -1;
+ }
+
year = bin2bcd(tmp->tm_year % 100);
mon = bin2bcd(tmp->tm_mon);
wday = bin2bcd(tmp->tm_wday);
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 06/11] rtc: Improve rtc_get() on s3c24x0_rtc
A better approach to avoid reading the RTC during updates, as sugested in
the S3C2416 User's Manual.
Signed-off-by: José Miguel Gonçalves
---
Changes for v2:
- New patch
Changes for v3:
- Removed unneeded parenthesis
---
drivers/rtc/s3c24x0_rtc.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/rtc/s3c24x0_rtc.c b/drivers/rtc/s3c24x0_rtc.c
index c16ff2e..b31dc53 100644
--- a/drivers/rtc/s3c24x0_rtc.c
+++ b/drivers/rtc/s3c24x0_rtc.c
@@ -65,20 +65,26 @@ int rtc_get(struct rtc_time *tmp)
uchar sec, min, hour, mday, wday, mon, year;
__maybe_unused uchar a_sec, a_min, a_hour, a_date,
a_mon, a_year, a_armed;
+ int have_retried = 0;
/* enable access to RTC registers */
SetRTC_Access(RTC_ENABLE);
/* read RTC registers */
do {
- sec = readb(&rtc->bcdsec);
min = readb(&rtc->bcdmin);
hour = readb(&rtc->bcdhour);
mday = readb(&rtc->bcddate);
wday = readb(&rtc->bcdday);
mon = readb(&rtc->bcdmon);
year = readb(&rtc->bcdyear);
- } while (sec != readb(&rtc->bcdsec));
+ sec = readb(&rtc->bcdsec);
+ /*
+* The only way to work out whether the RTC was mid-update
+* when we read it is to check the seconds counter.
+* If it's zero, then we re-try the entire read.
+*/
+ } while (sec == 0 && !have_retried++);
/* read ALARM registers */
a_sec = readb(&rtc->almsec);
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 03/11] serial: Add support to 4 ports in serial_s3c24x0
S3C2416 and S3C2450 have 4 UARTs insted of 3 found on older chips.
This patch adds support to the additional UART port and changes the
mapping between CONFIG_SERIAL? and S3C24X0_UART? in order they have
a direct correspondence.
Signed-off-by: José Miguel Gonçalves
---
Changes for v2:
- New patch
Changes for v3:
- None
---
drivers/serial/serial_s3c24x0.c | 25 ++---
include/configs/VCMA9.h |2 +-
include/configs/smdk2410.h |2 +-
3 files changed, 20 insertions(+), 9 deletions(-)
diff --git a/drivers/serial/serial_s3c24x0.c b/drivers/serial/serial_s3c24x0.c
index 12bcdd3..280cd2d 100644
--- a/drivers/serial/serial_s3c24x0.c
+++ b/drivers/serial/serial_s3c24x0.c
@@ -2,6 +2,9 @@
* (C) Copyright 2002
* Gary Jennejohn, DENX Software Engineering,
*
+ * (C) Copyright 2012 INOV - INESC Inovacao
+ * Jose Goncalves
+ *
* 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
@@ -24,17 +27,20 @@
DECLARE_GLOBAL_DATA_PTR;
-#ifdef CONFIG_SERIAL1
+#if defined(CONFIG_SERIAL0)
#define UART_NRS3C24X0_UART0
-#elif defined(CONFIG_SERIAL2)
+#elif defined(CONFIG_SERIAL1)
#define UART_NRS3C24X0_UART1
-#elif defined(CONFIG_SERIAL3)
+#elif defined(CONFIG_SERIAL2)
#define UART_NRS3C24X0_UART2
+#elif defined(CONFIG_SERIAL3)
+#define UART_NRS3C24X0_UART3
+
#else
-#error "Bad: you didn't configure serial ..."
+#error "You didn't configure serial."
#endif
#include
@@ -310,15 +316,20 @@ INIT_S3C_SERIAL_STRUCTURE(1, "s3ser1");
DECLARE_S3C_SERIAL_FUNCTIONS(2);
struct serial_device s3c24xx_serial2_device =
INIT_S3C_SERIAL_STRUCTURE(2, "s3ser2");
+DECLARE_S3C_SERIAL_FUNCTIONS(3);
+struct serial_device s3c24xx_serial3_device =
+INIT_S3C_SERIAL_STRUCTURE(3, "s3ser3");
__weak struct serial_device *default_serial_console(void)
{
-#if defined(CONFIG_SERIAL1)
+#if defined(CONFIG_SERIAL0)
return &s3c24xx_serial0_device;
-#elif defined(CONFIG_SERIAL2)
+#elif defined(CONFIG_SERIAL1)
return &s3c24xx_serial1_device;
-#elif defined(CONFIG_SERIAL3)
+#elif defined(CONFIG_SERIAL2)
return &s3c24xx_serial2_device;
+#elif defined(CONFIG_SERIAL3)
+ return &s3c24xx_serial3_device;
#else
#error "CONFIG_SERIAL? missing."
#endif
diff --git a/include/configs/VCMA9.h b/include/configs/VCMA9.h
index 6ad4a6b..82db58f 100644
--- a/include/configs/VCMA9.h
+++ b/include/configs/VCMA9.h
@@ -122,7 +122,7 @@
* select serial console configuration
*/
#define CONFIG_S3C24X0_SERIAL
-#define CONFIG_SERIAL1 1 /* we use SERIAL 1 on VCMA9 */
+#define CONFIG_SERIAL0 1 /* we use SERIAL 0 on VCMA9 */
/* USB support (currently only works with D-cache off) */
#define CONFIG_USB_OHCI
diff --git a/include/configs/smdk2410.h b/include/configs/smdk2410.h
index 8792c85..ea05f16 100644
--- a/include/configs/smdk2410.h
+++ b/include/configs/smdk2410.h
@@ -62,7 +62,7 @@
* select serial console configuration
*/
#define CONFIG_S3C24X0_SERIAL
-#define CONFIG_SERIAL1 1 /* we use SERIAL 1 on SMDK2410 */
+#define CONFIG_SERIAL0 1 /* we use SERIAL 0 on SMDK2410 */
/
* USB support (currently only works with D-cache off)
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 10/11] Add u-boot-pad.bin target to the Makefile
Samsung's S3C24XX SoCs need this in order to generate a binary image
with a padded SPL concatenated with U-Boot.
Signed-off-by: José Miguel Gonçalves
---
Changes for v2:
- None
Changes for v3:
- Changed new binary target name from u-boot-ubl.bin to u-boot-pad.bin
---
Makefile | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/Makefile b/Makefile
index 8738d55..86dedca 100644
--- a/Makefile
+++ b/Makefile
@@ -433,14 +433,15 @@ $(obj)u-boot.sha1:$(obj)u-boot.bin
$(obj)u-boot.dis: $(obj)u-boot
$(OBJDUMP) -d $< > $@
-$(obj)u-boot.ubl: $(obj)spl/u-boot-spl.bin $(obj)u-boot.bin
+$(obj)u-boot-pad.bin: $(obj)spl/u-boot-spl.bin $(obj)u-boot.bin
$(OBJCOPY) ${OBJCFLAGS} --pad-to=$(PAD_TO) -O binary
$(obj)spl/u-boot-spl $(obj)spl/u-boot-spl-pad.bin
- cat $(obj)spl/u-boot-spl-pad.bin $(obj)u-boot.bin >
$(obj)u-boot-ubl.bin
- $(obj)tools/mkimage -n $(UBL_CONFIG) -T ublimage \
- -e $(CONFIG_SYS_TEXT_BASE) -d $(obj)u-boot-ubl.bin
$(obj)u-boot.ubl
- rm $(obj)u-boot-ubl.bin
+ cat $(obj)spl/u-boot-spl-pad.bin $(obj)u-boot.bin >
$(obj)u-boot-pad.bin
rm $(obj)spl/u-boot-spl-pad.bin
+$(obj)u-boot.ubl: $(obj)spl/u-boot-pad.bin
+ $(obj)tools/mkimage -n $(UBL_CONFIG) -T ublimage \
+ -e $(CONFIG_SYS_TEXT_BASE) -d $(obj)u-boot-pad.bin
$(obj)u-boot.ubl
+
$(obj)u-boot.ais: $(obj)spl/u-boot-spl.bin $(obj)u-boot.img
$(obj)tools/mkimage -s -n /dev/null -T aisimage \
-e $(CONFIG_SPL_TEXT_BASE) \
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 09/11] S3C24XX: Add NAND Flash driver
NAND Flash driver with HW ECC for the S3C24XX SoCs.
Currently it only supports SLC NAND chips.
Signed-off-by: José Miguel Gonçalves
---
Changes for v2:
- Coding style cleanup
- Use of clrsetbits_le32()
- Use of register bit macros instead of magic numbers
Changes for v3:
- Removed magic numbers
- Removed a macro to declare a void printf()
- Replaced one printf() with a puts()
---
drivers/mtd/nand/Makefile |1 +
drivers/mtd/nand/s3c24xx_nand.c | 246 +++
2 files changed, 247 insertions(+)
create mode 100644 drivers/mtd/nand/s3c24xx_nand.c
diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
index 29dc20e..791ec44 100644
--- a/drivers/mtd/nand/Makefile
+++ b/drivers/mtd/nand/Makefile
@@ -60,6 +60,7 @@ COBJS-$(CONFIG_NAND_MXS) += mxs_nand.o
COBJS-$(CONFIG_NAND_NDFC) += ndfc.o
COBJS-$(CONFIG_NAND_NOMADIK) += nomadik.o
COBJS-$(CONFIG_NAND_S3C2410) += s3c2410_nand.o
+COBJS-$(CONFIG_NAND_S3C24XX) += s3c24xx_nand.o
COBJS-$(CONFIG_NAND_S3C64XX) += s3c64xx.o
COBJS-$(CONFIG_NAND_SPEAR) += spr_nand.o
COBJS-$(CONFIG_NAND_OMAP_GPMC) += omap_gpmc.o
diff --git a/drivers/mtd/nand/s3c24xx_nand.c b/drivers/mtd/nand/s3c24xx_nand.c
new file mode 100644
index 000..3c13709
--- /dev/null
+++ b/drivers/mtd/nand/s3c24xx_nand.c
@@ -0,0 +1,246 @@
+/*
+ * (C) Copyright 2012 INOV - INESC Inovacao
+ * Jose Goncalves
+ *
+ * Based on drivers/mtd/nand/s3c64xx.c and U-Boot 1.3.4 from Samsung.
+ * Supports only SLC NAND Flash chips.
+ *
+ * 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
+#include
+#include
+#include
+
+#define TACLS_VAL 7 /* CLE & ALE duration setting (0~7) */
+#defineTWRPH0_VAL 7 /* TWRPH0 duration setting (0~7) */
+#define TWRPH1_VAL 7 /* TWRPH1 duration setting (0~7) */
+
+#define MAX_CHIPS 2
+static int nand_cs[MAX_CHIPS] = { 0, 1 };
+
+static void s3c_nand_select_chip(struct mtd_info *mtd, int chip)
+{
+ struct s3c24xx_nand *const nand = s3c24xx_get_base_nand();
+ u_long nfcont;
+
+ nfcont = readl(&nand->nfcont);
+
+ switch (chip) {
+ case -1:
+ nfcont |= NFCONT_NCE1 | NFCONT_NCE0;
+ break;
+ case 0:
+ nfcont &= ~NFCONT_NCE0;
+ break;
+ case 1:
+ nfcont &= ~NFCONT_NCE1;
+ break;
+ default:
+ return;
+ }
+
+ writel(nfcont, &nand->nfcont);
+}
+
+/*
+ * Hardware specific access to control-lines function
+ */
+static void s3c_nand_hwcontrol(struct mtd_info *mtd, int cmd, unsigned int
ctrl)
+{
+ struct s3c24xx_nand *const nand = s3c24xx_get_base_nand();
+ struct nand_chip *this = mtd->priv;
+
+ if (ctrl & NAND_CTRL_CHANGE) {
+ if (ctrl & NAND_CLE)
+ this->IO_ADDR_W = &nand->nfcmmd;
+ else if (ctrl & NAND_ALE)
+ this->IO_ADDR_W = &nand->nfaddr;
+ else
+ this->IO_ADDR_W = &nand->nfdata;
+ if (ctrl & NAND_NCE)
+ s3c_nand_select_chip(mtd, *(int *)this->priv);
+ else
+ s3c_nand_select_chip(mtd, -1);
+ }
+
+ if (cmd != NAND_CMD_NONE)
+ writeb(cmd, this->IO_ADDR_W);
+}
+
+/*
+ * Function for checking device ready pin
+ */
+static int s3c_nand_device_ready(struct mtd_info *mtdinfo)
+{
+ struct s3c24xx_nand *const nand = s3c24xx_get_base_nand();
+
+ return readl(&nand->nfstat) & NFSTAT_RNB;
+}
+
+#ifdef CONFIG_S3C24XX_NAND_HWECC
+/*
+ * This function is called before encoding ECC codes to ready ECC engine.
+ */
+static void s3c_nand_enable_hwecc(struct mtd_info *mtd, int mode)
+{
+ struct s3c24xx_nand *const nand = s3c24xx_get_base_nand();
+
+ /* Set 1-bit ECC */
+ clrsetbits_le32(&nand->nfconf, NFCONF_ECCTYPE_MASK,
+ NFCONF_ECCTYPE_1BIT);
+
+ /* Initialize & unlock ECC */
+ clrsetbits_le32(&nand->nfcont, NFCONT_MECCLOCK, NFCONT_INITMECC);
+}
+
+/*
+ * This function is called immediately after encoding ECC codes.
+ * This function returns encoded ECC codes.
+ */
+static int s3c_nan
[U-Boot] [PATCH v3 11/11] S3C24XX: Add support to MINI2416 board
The MINI2416 board is based on a Samsung's S3C2416 SoC and has 64MB DDR2 SDRAM, 256MB NAND Flash, a LAN9220 Ethernet Controller and a WM8731 Audio CODEC. This U-Boot port was implemented and tested on a unit bought to Boardcon (http://www.armdesigner.com/) but there are some other chinese providers that can supply it with a selectable NAND chip from 128MB to 1GB. Signed-off-by: José Miguel Gonçalves --- Changes for v2: - Coding style cleanup - Use of Use of clrbits_le32(), setbits_le32() and clrsetbits_le32() - Use of register bit macros instead of magic numbers - Use of serial and rtc drivers implemented for s3c24x0 Changes for v3: - Changed target name from u-boot-ubl.bin to u-boot-pad.bin - Removed magic numbers - Changes to support new SPL framework --- MAINTAINERS|4 + board/boardcon/mini2416/Makefile | 47 board/boardcon/mini2416/config.mk |4 + board/boardcon/mini2416/mini2416.c | 104 board/boardcon/mini2416/mini2416_spl.c | 202 board/boardcon/mini2416/u-boot-spl.lds | 63 ++ boards.cfg |1 + include/configs/mini2416.h | 202 +++ 8 files changed, 627 insertions(+) create mode 100644 board/boardcon/mini2416/Makefile create mode 100644 board/boardcon/mini2416/config.mk create mode 100644 board/boardcon/mini2416/mini2416.c create mode 100644 board/boardcon/mini2416/mini2416_spl.c create mode 100644 board/boardcon/mini2416/u-boot-spl.lds create mode 100644 include/configs/mini2416.h diff --git a/MAINTAINERS b/MAINTAINERS index c5a6f2f..80ad29e 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -653,6 +653,10 @@ Fabio Estevam mx53ard i.MX53 mx53smd i.MX53 +José Gonçalves + + mini2416ARM926EJS (S3C2416 SoC) + Daniel Gorsulowski meesc ARM926EJS (AT91SAM9263 SoC) diff --git a/board/boardcon/mini2416/Makefile b/board/boardcon/mini2416/Makefile new file mode 100644 index 000..bf92ba1 --- /dev/null +++ b/board/boardcon/mini2416/Makefile @@ -0,0 +1,47 @@ +# +# (C) Copyright 2012 INOV - INESC Inovacao +# Jose Goncalves +# +# 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).o + +ifdef CONFIG_SPL_BUILD +COBJS += mini2416_spl.o +else +COBJS += mini2416.o +endif + +SRCS := $(COBJS:.o=.c) +OBJS := $(addprefix $(obj),$(COBJS)) + +$(LIB):$(obj).depend $(OBJS) + $(call cmd_link_o_target, $(OBJS)) + +# + +# defines $(obj).depend target +include $(SRCTREE)/rules.mk + +sinclude $(obj).depend + +# diff --git a/board/boardcon/mini2416/config.mk b/board/boardcon/mini2416/config.mk new file mode 100644 index 000..ff08568 --- /dev/null +++ b/board/boardcon/mini2416/config.mk @@ -0,0 +1,4 @@ +PAD_TO := 0x2000 +ifndef CONFIG_SPL_BUILD +ALL-y += $(obj)u-boot-pad.bin +endif diff --git a/board/boardcon/mini2416/mini2416.c b/board/boardcon/mini2416/mini2416.c new file mode 100644 index 000..b2c049b --- /dev/null +++ b/board/boardcon/mini2416/mini2416.c @@ -0,0 +1,104 @@ +/* + * (C) Copyright 2012 INOV - INESC Inovacao + * Jose Goncalves + * + * 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 +#include +#i
Re: [U-Boot] [PATCH 62/71] serial: spl: Implement empty functions for SPL
On 09/18/2012 12:13:57 PM, Marek Vasut wrote:
Dear Tom Rini,
> On Mon, Sep 17, 2012 at 01:21:27AM +0200, Marek Vasut wrote:
> > Implement empty serial_* functions for SPL without serial
> > support enabled. This is imperative to haave once serial
> > multi is enabled unconditionally.
> >
> > Signed-off-by: Marek Vasut
> > Cc: Marek Vasut
> > Cc: Tom Rini
> > ---
> >
> > common/serial.c | 12
> > 1 file changed, 12 insertions(+)
> >
> > diff --git a/common/serial.c b/common/serial.c
> > index 631af65..cef4ba8 100644
> > --- a/common/serial.c
> > +++ b/common/serial.c
> > @@ -27,6 +27,16 @@
> >
> > #include
> > #include
> >
> > +/* Implement prototypes for SPL without serial support */
> > +#if defined(CONFIG_SPL_BUILD) &&
!defined(CONFIG_SPL_SERIAL_SUPPORT)
> > +int serial_init(void) { return 0; }
> > +void serial_setbrg(void) {}
> > +int serial_getc(void) { return 0; }
> > +int serial_tstc(void) { return 0; }
> > +void serial_putc(const char c) {}
> > +void serial_puts(const char *s) {}
>
> This isn't quite right. We need to allow for:
> - No output SPL, strings collected (so #defined to do{} while (0))
Which is not type-checked and will drag in bugs.
Not all that likely, since most code will either be built with printf
enabled some of the time, or not contain printf (i.e. it's not quite
the same situation as debug prints which may be rarely enabled).
An inline function would be fine, but has to be done at the same place
that normal printf is declared -- whereas a macro could be done after
the fact. Unless you use a macro to redirect it to an inline function
of a different name...
I do not understand why you want to put these stubs in a C file instead
of a header file, though -- you're preventing code from being optimized
away, which is important in some SPLs.
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 62/71] serial: spl: Implement empty functions for SPL
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/18/12 10:13, Marek Vasut wrote:
> Dear Tom Rini,
>
>> On Mon, Sep 17, 2012 at 01:21:27AM +0200, Marek Vasut wrote:
>>> Implement empty serial_* functions for SPL without serial
>>> support enabled. This is imperative to haave once serial multi
>>> is enabled unconditionally.
>>>
>>> Signed-off-by: Marek Vasut Cc: Marek Vasut
>>> Cc: Tom Rini ---
>>>
>>> common/serial.c | 12 1 file changed, 12
>>> insertions(+)
>>>
>>> diff --git a/common/serial.c b/common/serial.c index
>>> 631af65..cef4ba8 100644 --- a/common/serial.c +++
>>> b/common/serial.c @@ -27,6 +27,16 @@
>>>
>>> #include #include
>>>
>>> +/* Implement prototypes for SPL without serial support */
>>> +#if defined(CONFIG_SPL_BUILD) &&
>>> !defined(CONFIG_SPL_SERIAL_SUPPORT) +int serial_init(void) {
>>> return 0; } +void serial_setbrg(void) {} +int
>>> serial_getc(void) { return 0; } +int serial_tstc(void) { return
>>> 0; } +void serial_putc(const char c) {} +void serial_puts(const
>>> char *s) {}
>>
>> This isn't quite right. We need to allow for: - No output SPL,
>> strings collected (so #defined to do{} while (0))
>
> Which is not type-checked and will drag in bugs.
Scott has addressed this.
>> - puts + printf SPL (CONFIG_SPL_SERIAL_SUPPORT +
>> CONFIG_SPL_LIBCOMMON_SUPPORT) - puts only SPL
>> (CONFIG_SPL_SERIAL_SUPPORT + #define puts serial_puts/putc).
>>
>> I'm not asking you to do that, but you will have to adapt to it
>> once Jose is done with it. What that means, off the top of my
>> head, is we can just drop this patch as in the first and last
>> case serial.o will be garbage-collected (or not built) and in
>> the middle case, this will be fully used.
>
> I can't drop this patch as it will break all of SPL when
> CONFIG_SERIAL_MULTI is unconditionally enabled.
Why is it breaking _all_ of SPL? Have you run-tested this anywhere,
especially with SPL? In most cases it should be used and real
functions provided or garbage collected away.
- --
Tom
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
iQIcBAEBAgAGBQJQWLUQAAoJENk4IS6UOR1WxoAP/3Lto025hWPgi7obJR1nrl63
r84gfCPkVsjqWHmYJl+vFOlyTuEiXaW9K5PWNxRA7xXbm5GbBe90fZBdYVxCSh+f
7KuSJ5jBEItmma9eeva7Af8FRtoC487yM9MpAOUKQ2pKsOiPR7lbiGQamHvWUssA
1BQfALQSlWgdlsk93EHXwxRoQD97ojAfCWPybObpd0C3oYUHVPhOYHS9NtLiRr8e
L58e7XhPksxNEyx29qrbmSwFGE8a4zSeu9SHjCfVk9Z2j2cD0zXpgqbwTe8/U259
31KUoRoLpqbSfOl4jcmZ54lyWZNbh1p45cyZAtOy4JJE99YkE951p342wC7sseQM
AtGqWQidKvHszpiSFkhu2pbTHQbTZfnYA4cvKL4x5S6zXKLEk/Ybfn9RTXQpdnaQ
6yUeYLjHl3bXeVb/JhtD5oouzyCfQmDyVnS4CUTAD4rVBS1CNpjpLa/mDoAcZNJr
zFLtkBW/72toOV7Xy2YsLtiWvw3bL6gKeKueegX5vHRBIx9csHWB3SZc7qMCZyIW
xk3CIhJEru/RsWMAqynCX5lfRSuw2+Zflnq5YJnqeVRY2mdasXewLsvhW2iRRn7n
C/Wf43wU782RK/8KbBYlokiDjV5egipxccW3lOIAr1HtvSQNfQgUDrum4opx+Jrw
nbA1JTydUvu0YSzId43A
=Lc/6
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 08/71] serial: Implement serial_initfunc() macro
Dear Tom Rini,
> On Mon, Sep 17, 2012 at 01:20:33AM +0200, Marek Vasut wrote:
> > This macro simplifies declaration of weak aliases for per-driver
> > functions, which register these drivers with the serial subsystem.
> > The idea here is to push serial_register() calls from serial.c into
> > the drivers. To avoid pile of ifdef construct as it is now, create
> > weak aliases to these functions, which in case the driver is not
> > present alias onto an empty function, which is in turn optimized out
> > altogether.
>
> So, did you consider and throw out the idea of something like:
> common/serial.c:
> void serial_initalize(void) {
> platform_serial_register();
> serial_assign(default_serial_console()->name);
> }
>
> And then every serial driver, instead of having to add a new weak
> function to common/serial.c and a new function call just defines
> platform_serial_register.
Yes
> Or do you run into platforms that want two different serial drivers AND
> you couldn't solve that with a combination of weak functions and
> board-specific platform_serial_register?
The point is to allow compiling in any possible combination of serial drivers,
thus the per-driver separate init call. I'd like to get rid of this once the DM
is present, since there'll be a method of generating the driver list
automagically, thus dissolving this all.
So this is pretty much temporary. Yet, you are right, there are a few boards
(really minor amount, some PPC ancient goo) that do need two drivers in.
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 62/71] serial: spl: Implement empty functions for SPL
Dear Tom Rini,
> On 09/18/12 10:13, Marek Vasut wrote:
> > Dear Tom Rini,
> >
> >> On Mon, Sep 17, 2012 at 01:21:27AM +0200, Marek Vasut wrote:
> >>> Implement empty serial_* functions for SPL without serial
> >>> support enabled. This is imperative to haave once serial multi
> >>> is enabled unconditionally.
> >>>
> >>> Signed-off-by: Marek Vasut Cc: Marek Vasut
> >>> Cc: Tom Rini ---
> >>>
> >>> common/serial.c | 12 1 file changed, 12
> >>> insertions(+)
> >>>
> >>> diff --git a/common/serial.c b/common/serial.c index
> >>> 631af65..cef4ba8 100644 --- a/common/serial.c +++
> >>> b/common/serial.c @@ -27,6 +27,16 @@
> >>>
> >>> #include #include
> >>>
> >>> +/* Implement prototypes for SPL without serial support */
> >>> +#if defined(CONFIG_SPL_BUILD) &&
> >>> !defined(CONFIG_SPL_SERIAL_SUPPORT) +int serial_init(void) {
> >>> return 0; } +void serial_setbrg(void) {} +int
> >>> serial_getc(void) { return 0; } +int serial_tstc(void) { return
> >>> 0; } +void serial_putc(const char c) {} +void serial_puts(const
> >>> char *s) {}
> >>
> >> This isn't quite right. We need to allow for: - No output SPL,
> >> strings collected (so #defined to do{} while (0))
> >
> > Which is not type-checked and will drag in bugs.
>
> Scott has addressed this.
>
> >> - puts + printf SPL (CONFIG_SPL_SERIAL_SUPPORT +
> >> CONFIG_SPL_LIBCOMMON_SUPPORT) - puts only SPL
> >> (CONFIG_SPL_SERIAL_SUPPORT + #define puts serial_puts/putc).
> >>
> >> I'm not asking you to do that, but you will have to adapt to it
> >> once Jose is done with it. What that means, off the top of my
> >> head, is we can just drop this patch as in the first and last
> >> case serial.o will be garbage-collected (or not built) and in
> >> the middle case, this will be fully used.
> >
> > I can't drop this patch as it will break all of SPL when
> > CONFIG_SERIAL_MULTI is unconditionally enabled.
>
> Why is it breaking _all_ of SPL? Have you run-tested this anywhere,
> especially with SPL? In most cases it should be used and real
> functions provided or garbage collected away.
Yes, try compiling m28evk without this patch for example, it's going to break
it. Because CONFIG_SPL_SERIAL_SUPPORT is disabled, yet it uses code that
contains references to puts() etc.
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 09/11] S3C24XX: Add NAND Flash driver
On 09/18/2012 12:40:36 PM, José Miguel Gonçalves wrote:
NAND Flash driver with HW ECC for the S3C24XX SoCs.
Currently it only supports SLC NAND chips.
Signed-off-by: José Miguel Gonçalves
---
Changes for v2:
- Coding style cleanup
- Use of clrsetbits_le32()
- Use of register bit macros instead of magic numbers
Changes for v3:
- Removed magic numbers
- Removed a macro to declare a void printf()
- Replaced one printf() with a puts()
---
drivers/mtd/nand/Makefile |1 +
drivers/mtd/nand/s3c24xx_nand.c | 246
+++
2 files changed, 247 insertions(+)
create mode 100644 drivers/mtd/nand/s3c24xx_nand.c
diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
index 29dc20e..791ec44 100644
--- a/drivers/mtd/nand/Makefile
+++ b/drivers/mtd/nand/Makefile
@@ -60,6 +60,7 @@ COBJS-$(CONFIG_NAND_MXS) += mxs_nand.o
COBJS-$(CONFIG_NAND_NDFC) += ndfc.o
COBJS-$(CONFIG_NAND_NOMADIK) += nomadik.o
COBJS-$(CONFIG_NAND_S3C2410) += s3c2410_nand.o
+COBJS-$(CONFIG_NAND_S3C24XX) += s3c24xx_nand.o
COBJS-$(CONFIG_NAND_S3C64XX) += s3c64xx.o
COBJS-$(CONFIG_NAND_SPEAR) += spr_nand.o
COBJS-$(CONFIG_NAND_OMAP_GPMC) += omap_gpmc.o
diff --git a/drivers/mtd/nand/s3c24xx_nand.c
b/drivers/mtd/nand/s3c24xx_nand.c
new file mode 100644
index 000..3c13709
--- /dev/null
+++ b/drivers/mtd/nand/s3c24xx_nand.c
@@ -0,0 +1,246 @@
+/*
+ * (C) Copyright 2012 INOV - INESC Inovacao
+ * Jose Goncalves
+ *
+ * Based on drivers/mtd/nand/s3c64xx.c and U-Boot 1.3.4 from Samsung.
+ * Supports only SLC NAND Flash chips.
+ *
+ * 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
+#include
+#include
+#include
+
+#define TACLS_VAL 7 /* CLE & ALE duration setting (0~7) */
+#define TWRPH0_VAL 7 /* TWRPH0 duration setting
(0~7) */
+#define TWRPH1_VAL 7 /* TWRPH1 duration setting (0~7) */
Please use space, not tab, as a word separator (after the second
#define).
+
+#define MAX_CHIPS 2
+static int nand_cs[MAX_CHIPS] = { 0, 1 };
This needs explanation (and const). Better would be to use a priv
struct, as discussed before.
+static void s3c_nand_select_chip(struct mtd_info *mtd, int chip)
+{
+ struct s3c24xx_nand *const nand = s3c24xx_get_base_nand();
+ u_long nfcont;
s/u_long/u32/
+
+ nfcont = readl(&nand->nfcont);
+
+ switch (chip) {
+ case -1:
+ nfcont |= NFCONT_NCE1 | NFCONT_NCE0;
+ break;
+ case 0:
+ nfcont &= ~NFCONT_NCE0;
+ break;
+ case 1:
+ nfcont &= ~NFCONT_NCE1;
+ break;
+ default:
+ return;
error message on default?
+ }
+
+ writel(nfcont, &nand->nfcont);
+}
+
+/*
+ * Hardware specific access to control-lines function
+ */
+static void s3c_nand_hwcontrol(struct mtd_info *mtd, int cmd,
unsigned int ctrl)
+{
+ struct s3c24xx_nand *const nand = s3c24xx_get_base_nand();
+ struct nand_chip *this = mtd->priv;
+
+ if (ctrl & NAND_CTRL_CHANGE) {
+ if (ctrl & NAND_CLE)
+ this->IO_ADDR_W = &nand->nfcmmd;
+ else if (ctrl & NAND_ALE)
+ this->IO_ADDR_W = &nand->nfaddr;
+ else
+ this->IO_ADDR_W = &nand->nfdata;
+ if (ctrl & NAND_NCE)
+ s3c_nand_select_chip(mtd, *(int *)this->priv);
+ else
+ s3c_nand_select_chip(mtd, -1);
+ }
+
+ if (cmd != NAND_CMD_NONE)
+ writeb(cmd, this->IO_ADDR_W);
+}
As discussed earlier, do you really need to mess with IO_ADDR_W or can
you do it the way ndfc.c does?
I.e.:
static void s3c_nand_hwcontrol(struct mtd_info *mtd, int cmd, unsigned
int ctrl)
{
struct s3c24xx_nand *const nand = s3c24xx_get_base_nand();
struct nand_chip *this = mtd->priv;
if (cmd == NAND_CMD_NONE)
return;
if (ctrl & NAND_CLE)
writeb(cmd, &nand->nfcmmd);
else
writeb(cmd, &nand->nfaddr);
}
+/*
+ * Board-specific NAND initialization.
+ */
+int board_nand_init(struct nand_chip *nand)
+{
+
Re: [U-Boot] [PATCH 62/71] serial: spl: Implement empty functions for SPL
Dear Scott Wood,
> On 09/18/2012 12:13:57 PM, Marek Vasut wrote:
> > Dear Tom Rini,
> >
> > > On Mon, Sep 17, 2012 at 01:21:27AM +0200, Marek Vasut wrote:
> > > > Implement empty serial_* functions for SPL without serial
> > > > support enabled. This is imperative to haave once serial
> > > > multi is enabled unconditionally.
> > > >
> > > > Signed-off-by: Marek Vasut
> > > > Cc: Marek Vasut
> > > > Cc: Tom Rini
> > > > ---
> > > >
> > > > common/serial.c | 12
> > > > 1 file changed, 12 insertions(+)
> > > >
> > > > diff --git a/common/serial.c b/common/serial.c
> > > > index 631af65..cef4ba8 100644
> > > > --- a/common/serial.c
> > > > +++ b/common/serial.c
> > > > @@ -27,6 +27,16 @@
> > > >
> > > > #include
> > > > #include
> > > >
> > > > +/* Implement prototypes for SPL without serial support */
> > > > +#if defined(CONFIG_SPL_BUILD) &&
> >
> > !defined(CONFIG_SPL_SERIAL_SUPPORT)
> >
> > > > +int serial_init(void) { return 0; }
> > > > +void serial_setbrg(void) {}
> > > > +int serial_getc(void) { return 0; }
> > > > +int serial_tstc(void) { return 0; }
> > > > +void serial_putc(const char c) {}
> > > > +void serial_puts(const char *s) {}
> > >
> > > This isn't quite right. We need to allow for:
> > > - No output SPL, strings collected (so #defined to do{} while (0))
> >
> > Which is not type-checked and will drag in bugs.
>
> Not all that likely, since most code will either be built with printf
> enabled some of the time, or not contain printf (i.e. it's not quite
> the same situation as debug prints which may be rarely enabled).
>
> An inline function would be fine, but has to be done at the same place
> that normal printf is declared -- whereas a macro could be done after
> the fact. Unless you use a macro to redirect it to an inline function
> of a different name...
>
> I do not understand why you want to put these stubs in a C file instead
> of a header file, though -- you're preventing code from being optimized
> away, which is important in some SPLs.
I'd say the GCC must optimize it out anyway.
And if not, what solution do you suggest, move these into include/serial.h and
compile serial.c in conditionally?
> -Scott
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ext4: cache-align buffers so the invalidation works
From: Stephen Warren
DMA buffer cache invalidation requires that buffers have cache-aligned
buffer locations and sizes. Use memalign() and ALLOC_CACHE_ALIGN_BUFFER()
to ensure this.
On Tegra at least, without this fix, the following fail commands fail in
u-boot-master/ext4, but succeeded at the branch's branch point in
u-boot/master. With this fix, the commands work again:
ext2ls mmc 0:1 /
ext2load mmc 0:1 /boot/zImage
Cc: Uma Shankar
Cc: Manjunatha C Achar
Cc: Iqbal Shareef
Cc: Hakgoo Lee
Cc: Wolfgang Denk
Cc: Tom Rini
Signed-off-by: Stephen Warren
---
This patch is for branch u-boot/ext4.
fs/ext4/dev.c |4 ++--
fs/ext4/ext4_common.c |2 +-
fs/ext4/ext4_common.h |7 ++-
3 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/fs/ext4/dev.c b/fs/ext4/dev.c
index fb62f24..9e85228 100644
--- a/fs/ext4/dev.c
+++ b/fs/ext4/dev.c
@@ -62,7 +62,7 @@ int ext4fs_set_blk_dev(block_dev_desc_t *rbdd, int part)
int ext4fs_devread(int sector, int byte_offset, int byte_len, char *buf)
{
- char sec_buf[SECTOR_SIZE];
+ ALLOC_CACHE_ALIGN_BUFFER(char, sec_buf, SECTOR_SIZE);
unsigned block_len;
/* Check partition boundaries */
@@ -107,7 +107,7 @@ int ext4fs_devread(int sector, int byte_offset, int
byte_len, char *buf)
block_len = byte_len & ~(SECTOR_SIZE - 1);
if (block_len == 0) {
- u8 p[SECTOR_SIZE];
+ ALLOC_CACHE_ALIGN_BUFFER(u8, p, SECTOR_SIZE);
block_len = SECTOR_SIZE;
ext4fs_block_dev_desc->block_read(ext4fs_block_dev_desc->dev,
diff --git a/fs/ext4/ext4_common.c b/fs/ext4/ext4_common.c
index 083e45e..3deffd5 100644
--- a/fs/ext4/ext4_common.c
+++ b/fs/ext4/ext4_common.c
@@ -71,7 +71,7 @@ void put_ext4(uint64_t off, void *buf, uint32_t size)
uint64_t startblock;
uint64_t remainder;
unsigned char *temp_ptr = NULL;
- unsigned char sec_buf[SECTOR_SIZE];
+ ALLOC_CACHE_ALIGN_BUFFER(unsigned char, sec_buf, SECTOR_SIZE);
struct ext_filesystem *fs = get_fs();
startblock = off / (uint64_t)SECTOR_SIZE;
diff --git a/fs/ext4/ext4_common.h b/fs/ext4/ext4_common.h
index 801b8b8..0af625d 100644
--- a/fs/ext4/ext4_common.h
+++ b/fs/ext4/ext4_common.h
@@ -55,7 +55,12 @@
#define SUPERBLOCK_SIZE1024
#define F_FILE 1
-#define zalloc(size) calloc(1, size)
+static inline void *zalloc(size_t size)
+{
+ void *p = memalign(ARCH_DMA_MINALIGN, size);
+ memset(p, 0, size);
+ return p;
+}
extern unsigned long part_offset;
int ext4fs_read_inode(struct ext2_data *data, int ino,
--
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] net: sh_eth: Add support R8A7740 of rmobile (arm core)
Hi Nobuhiro Iwamatsu, On Mon, Sep 17, 2012 at 8:11 PM, Nobuhiro Iwamatsu wrote: > Hi, Joe. > > Could you pick this patch to your repository? This is in my backlog. Thanks, -Joe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 62/71] serial: spl: Implement empty functions for SPL
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/18/12 11:01, Marek Vasut wrote:
> Dear Tom Rini,
>
>> On 09/18/12 10:13, Marek Vasut wrote:
>>> Dear Tom Rini,
>>>
On Mon, Sep 17, 2012 at 01:21:27AM +0200, Marek Vasut wrote:
> Implement empty serial_* functions for SPL without serial
> support enabled. This is imperative to haave once serial
> multi is enabled unconditionally.
>
> Signed-off-by: Marek Vasut Cc: Marek Vasut
> Cc: Tom Rini ---
>
> common/serial.c | 12 1 file changed, 12
> insertions(+)
>
> diff --git a/common/serial.c b/common/serial.c index
> 631af65..cef4ba8 100644 --- a/common/serial.c +++
> b/common/serial.c @@ -27,6 +27,16 @@
>
> #include #include
>
> +/* Implement prototypes for SPL without serial support */
> +#if defined(CONFIG_SPL_BUILD) &&
> !defined(CONFIG_SPL_SERIAL_SUPPORT) +int serial_init(void)
> { return 0; } +void serial_setbrg(void) {} +int
> serial_getc(void) { return 0; } +int serial_tstc(void) {
> return 0; } +void serial_putc(const char c) {} +void
> serial_puts(const char *s) {}
This isn't quite right. We need to allow for: - No output
SPL, strings collected (so #defined to do{} while (0))
>>>
>>> Which is not type-checked and will drag in bugs.
>>
>> Scott has addressed this.
>>
- puts + printf SPL (CONFIG_SPL_SERIAL_SUPPORT +
CONFIG_SPL_LIBCOMMON_SUPPORT) - puts only SPL
(CONFIG_SPL_SERIAL_SUPPORT + #define puts serial_puts/putc).
I'm not asking you to do that, but you will have to adapt to
it once Jose is done with it. What that means, off the top
of my head, is we can just drop this patch as in the first
and last case serial.o will be garbage-collected (or not
built) and in the middle case, this will be fully used.
>>>
>>> I can't drop this patch as it will break all of SPL when
>>> CONFIG_SERIAL_MULTI is unconditionally enabled.
>>
>> Why is it breaking _all_ of SPL? Have you run-tested this
>> anywhere, especially with SPL? In most cases it should be used
>> and real functions provided or garbage collected away.
>
> Yes, try compiling m28evk without this patch for example, it's
> going to break it. Because CONFIG_SPL_SERIAL_SUPPORT is disabled,
> yet it uses code that contains references to puts() etc.
Progress! Now, why isn't this file being garbage collected? m28evk
is fitting into the first category I said (no output) but now it's not
discarding things that it should be discarding.
- --
Tom
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
iQIcBAEBAgAGBQJQWLifAAoJENk4IS6UOR1WyiIP/1h3r1OBQ8sxHCq6nuWT7cvQ
6taDBU6780uOY+YsbNgjlImp7lSM30HYxXou2j2kykPcRjUPMzLoYDRZio+8d8RW
ETQcMld8I/OMz52HT6lnjIaqVBOpK42vlRW86LNcxIFOasYlK4qxO3kjKmshu5aC
ct7b5xcHFaqfxLp2EjkUOgmoyPXhNTdsnDVdOTaXG7qGKAffDFCeUHTsBB3kc/S6
w5HwDNTBWZYVMWuTXKXLXh+3h4x+VL1LCxCsnu8R88cEkj7b9DkqGUsUrCDPFqc/
YAqiUqacTa0V9h9XeE/OdZUo7uS04FibPHzvho91LcnBdjOJ7jPLY7k/IJ7guhqp
aRC9UrB/AAPkpLExo32Ksx+7wAJThsfWY6DL5oI76E4FYZP2WaqygBM/WDCbcOK7
6HIGItjGwFpXBCDbawKob395Kt5gK2J43qXR2E7CR4p3ic8liMqsWu5J+TCUVF6b
jxjLZ22Bw5zolUkhUE5u+M+O/rxCjYG0HNTssC1ymYR/jU36p1m6oGqxVN8Voi0R
1ARQB2yY3uuQOqR1URZMzuA94d1Qffnhg3LwSm3cJRH825WNDkxEXq/hvK/4hLbH
DXb79+zRqv7f80jPUEk60sKFI3YzJMvRBaaxjXqOkMFywaNMQjbsnXCmvztoqRqG
A1gmJGTWixOQbrN56DjF
=wRYN
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3] FAT: Make it possible to read from any file position
When storage devices contain files larger than the embedded RAM, it is useful to
be able to read these files by chunks, e.g. for a software update to the
embedded NAND Flash from an external storage device (USB stick, SD card, etc.).
Hence, this patch makes it possible by adding a new FAT API to read files from a
given position. This patch also adds this feature to the fatload command.
Signed-off-by: Benoît Thébaudeau
Cc: Tom Rini
Cc: Wolfgang Denk
---
Changes for v2:
- Add missing variable renaming to fat_write.c.
Changes for v3:
- Make this new feature available through the fatload command.
.../common/cmd_fat.c | 25 +++--
.../fs/fat/fat.c | 98
.../fs/fat/fat_write.c | 18 ++--
.../include/fat.h |2 +
4 files changed, 105 insertions(+), 38 deletions(-)
diff --git u-boot-037e9d3.orig/common/cmd_fat.c u-boot-037e9d3/common/cmd_fat.c
index 559a16d..2e34c54 100644
--- u-boot-037e9d3.orig/common/cmd_fat.c
+++ u-boot-037e9d3/common/cmd_fat.c
@@ -37,7 +37,8 @@ int do_fat_fsload (cmd_tbl_t *cmdtp, int flag, int argc, char
* const argv[])
{
long size;
unsigned long offset;
- unsigned long count;
+ unsigned long count = 0;
+ unsigned long pos = 0;
char buf [12];
block_dev_desc_t *dev_desc=NULL;
int dev=0;
@@ -46,7 +47,7 @@ int do_fat_fsload (cmd_tbl_t *cmdtp, int flag, int argc, char
* const argv[])
if (argc < 5) {
printf( "usage: fatload "
- " [bytes]\n");
+ " [bytes [pos]]\n");
return 1;
}
@@ -69,11 +70,11 @@ int do_fat_fsload (cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
return 1;
}
offset = simple_strtoul(argv[3], NULL, 16);
- if (argc == 6)
+ if (argc >= 6)
count = simple_strtoul(argv[5], NULL, 16);
- else
- count = 0;
- size = file_fat_read(argv[4], (unsigned char *)offset, count);
+ if (argc >= 7)
+ pos = simple_strtoul(argv[6], NULL, 16);
+ size = file_fat_read_at(argv[4], pos, (unsigned char *)offset, count);
if(size==-1) {
printf("\n** Unable to read \"%s\" from %s %d:%d **\n",
@@ -91,11 +92,15 @@ int do_fat_fsload (cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
U_BOOT_CMD(
- fatload,6, 0, do_fat_fsload,
+ fatload,7, 0, do_fat_fsload,
"load binary file from a dos filesystem",
- " [bytes]\n"
- "- load binary file 'filename' from 'dev' on 'interface'\n"
- " to address 'addr' from dos filesystem"
+ " [bytes [pos]]\n"
+ "- Load binary file 'filename' from 'dev' on 'interface'\n"
+ " to address 'addr' from dos filesystem.\n"
+ " 'pos' gives the file position to start loading from.\n"
+ " If 'pos' is omitted, 0 is used. 'pos' requires 'bytes'.\n"
+ " 'bytes' gives the size to load. If 'bytes' is 0 or omitted,\n"
+ " the load stops on end of file."
);
int do_fat_ls (cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
diff --git u-boot-037e9d3.orig/fs/fat/fat.c u-boot-037e9d3/fs/fat/fat.c
index f7bb1da..c8beb30 100644
--- u-boot-037e9d3.orig/fs/fat/fat.c
+++ u-boot-037e9d3/fs/fat/fat.c
@@ -328,13 +328,16 @@ get_cluster(fsdata *mydata, __u32 clustnum, __u8 *buffer,
unsigned long size)
}
/*
- * Read at most 'maxsize' bytes from the file associated with 'dentptr'
+ * Read at most 'maxsize' bytes from 'pos' in the file associated with
'dentptr'
* into 'buffer'.
* Return the number of bytes read or -1 on fatal errors.
*/
+__u8 get_contents_vfatname_block[MAX_CLUSTSIZE]
+ __aligned(ARCH_DMA_MINALIGN);
+
static long
-get_contents(fsdata *mydata, dir_entry *dentptr, __u8 *buffer,
-unsigned long maxsize)
+get_contents(fsdata *mydata, dir_entry *dentptr, unsigned long pos,
+__u8 *buffer, unsigned long maxsize)
{
unsigned long filesize = FAT2CPU32(dentptr->size), gotsize = 0;
unsigned int bytesperclust = mydata->clust_size * mydata->sect_size;
@@ -344,12 +347,59 @@ get_contents(fsdata *mydata, dir_entry *dentptr, __u8
*buffer,
debug("Filesize: %ld bytes\n", filesize);
- if (maxsize > 0 && filesize > maxsize)
- filesize = maxsize;
+ if (pos >= filesize) {
+ debug("Read position past EOF: %lu\n", pos);
+ return gotsize;
+ }
+
+ if (maxsize > 0 && filesize > pos + maxsize)
+ filesize = pos + maxsize;
debug("%ld bytes\n", filesize);
actsize = bytesperclust;
+
+ /* go to cluster at pos */
+ while (actsize <= pos) {
+ curclust = get_fatent(mydata, curclust);
+
Re: [U-Boot] [PATCH 1/2] patman: Use reverse order for changelog
On Sat, Aug 18, 2012 at 10:46 AM, Otavio Salvador wrote: > Specially when many revisions are need for a patchset, the most > interesting information is about the last set of changes so we output > the changelog in reverse order to easy identification of most recent > change set. > > Signed-off-by: Otavio Salvador Acked-by: Simon Glass > --- > tools/patman/series.py |8 > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/tools/patman/series.py b/tools/patman/series.py > index 7829dc7..dddfab4 100644 > --- a/tools/patman/series.py > +++ b/tools/patman/series.py > @@ -145,18 +145,18 @@ class Series(dict): > Return: > The change log as a list of strings, one per line > > +Changes in v2: > +- Jog the dial back closer to the widget > + > Changes in v1: > - Fix the widget > - Jog the dial > > -Changes in v2: > -- Jog the dial back closer to the widget > - > etc. > """ > final = [] > need_blank = False > -for change in sorted(self.changes): > +for change in sorted(self.changes, reverse=True): > out = [] > for this_commit, text in self.changes[change]: > if commit and this_commit != commit: > -- > 1.7.10.4 > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 13/13] mxc nand: Add support for i.MX5
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/17/12 17:36, Scott Wood wrote: > On Tue, Aug 21, 2012 at 11:04:14PM +0200, Benoît Thébaudeau wrote: >> Signed-off-by: Benoît Thébaudeau >> Cc: Scott Wood >> Cc: Stefano Babic --- >> Changes for v2: - Fix warning for unused tmp variable in >> board_nand_init() for NFC V1. >> >> .../arch/arm/include/asm/arch-mx5/imx-regs.h |9 + >> .../drivers/mtd/nand/mxc_nand.c| 219 >> +++- .../include/fsl_nfc.h >> | 149 - .../nand_spl/nand_boot_fsl_nfc.c >> | 114 +++--- 4 files changed, 365 insertions(+), 126 >> deletions(-) > > Unless Tom or Wolfgang object, I'm inclined to drop the objection > to adding new hardware support to nand_spl in this case. I'd > rather see the support be merged rather than ignored because a > contributor has time for a small job but not a large one. Plus, > this code will likely be reused by the new SPL support, if this > platform is space constrained, so it's not dead-end effort. I'm OK with pulling this in while providing an on-the-record prod to please find some time to do a conversion or two in time for v2013.01. - -- Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQIcBAEBAgAGBQJQWLlIAAoJENk4IS6UOR1WjL8P/Rj2jUnLXeMCgn4FJu7KfrXt 3g5HHGgvupmkiPXalwb5/MhID3Jpl+hjpt2Qw+TNqASU36kyqUXi/tx+G143Y+Jp v3hYpwfrCQJLBvC5TI9Bq8gcW7DosggNlyfGtdXPtn8XjxIi+13NDONnL4VOIRHc GsJAnPofFhFtxtKoHcHAZe5hFIi/7davYUhmAPxCOZduPkUpwZNkc8XJJid+sSvt C5/PLIeQqaYcDiaXbw4TE8t/y1ju7ovCzkLsGlLh1yT8QAjxgh+wtuArYz+fpK7p q7zHlcOcLmAKc2mkOMdpOV/iLgC+kFKxJQ7DKANb5dL9wFtRBVR8jRhjGMqfySsp LgsbhdUBHg0dhP4M8CgDCbO53vOYAp/5cV8qhbB3sAAKEVbFM+ZSjXJNAy7Ty6hJ 09QCcPhcmXf7THgDm5r0j6eudcAfAMNyoP0pvFWdBqfzNLpnXoUwBGo58pM1yErw ZWLIlSgnU7rtG6IXQH3RHj0Jy706KellkVFlc/Mp+21OYkhaUJDelEaXWWXrJYYl VdlfgE98fXgJR3NxyMwHBzu1wDDidTLxNiMss/kW+O+718eHSq6OQUVmsCjhNJ4P HoLeV8Cr8oGlThVJw3TQfvY7y2MK4cmD0F8pRxAJGvvH7WSFw+KoBo38477+0Tpc yYKh71HPQ3IbnmGXADmI =0DGS -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 09/11] S3C24XX: Add NAND Flash driver
On 18-09-2012 19:02, Scott Wood wrote:
On 09/18/2012 12:40:36 PM, José Miguel Gonçalves wrote:
NAND Flash driver with HW ECC for the S3C24XX SoCs.
Currently it only supports SLC NAND chips.
Signed-off-by: José Miguel Gonçalves
---
Changes for v2:
- Coding style cleanup
- Use of clrsetbits_le32()
- Use of register bit macros instead of magic numbers
Changes for v3:
- Removed magic numbers
- Removed a macro to declare a void printf()
- Replaced one printf() with a puts()
---
drivers/mtd/nand/Makefile |1 +
drivers/mtd/nand/s3c24xx_nand.c | 246 +++
2 files changed, 247 insertions(+)
create mode 100644 drivers/mtd/nand/s3c24xx_nand.c
diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
index 29dc20e..791ec44 100644
--- a/drivers/mtd/nand/Makefile
+++ b/drivers/mtd/nand/Makefile
@@ -60,6 +60,7 @@ COBJS-$(CONFIG_NAND_MXS) += mxs_nand.o
COBJS-$(CONFIG_NAND_NDFC) += ndfc.o
COBJS-$(CONFIG_NAND_NOMADIK) += nomadik.o
COBJS-$(CONFIG_NAND_S3C2410) += s3c2410_nand.o
+COBJS-$(CONFIG_NAND_S3C24XX) += s3c24xx_nand.o
COBJS-$(CONFIG_NAND_S3C64XX) += s3c64xx.o
COBJS-$(CONFIG_NAND_SPEAR) += spr_nand.o
COBJS-$(CONFIG_NAND_OMAP_GPMC) += omap_gpmc.o
diff --git a/drivers/mtd/nand/s3c24xx_nand.c b/drivers/mtd/nand/s3c24xx_nand.c
new file mode 100644
index 000..3c13709
--- /dev/null
+++ b/drivers/mtd/nand/s3c24xx_nand.c
@@ -0,0 +1,246 @@
+/*
+ * (C) Copyright 2012 INOV - INESC Inovacao
+ * Jose Goncalves
+ *
+ * Based on drivers/mtd/nand/s3c64xx.c and U-Boot 1.3.4 from Samsung.
+ * Supports only SLC NAND Flash chips.
+ *
+ * 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
+#include
+#include
+#include
+
+#define TACLS_VAL7/* CLE & ALE duration setting (0~7) */
+#defineTWRPH0_VAL7/* TWRPH0 duration setting (0~7) */
+#define TWRPH1_VAL7/* TWRPH1 duration setting (0~7) */
Please use space, not tab, as a word separator (after the second #define).
OK.
+
+#define MAX_CHIPS2
+static int nand_cs[MAX_CHIPS] = { 0, 1 };
This needs explanation (and const). Better would be to use a priv struct, as
discussed before.
+static void s3c_nand_select_chip(struct mtd_info *mtd, int chip)
+{
+struct s3c24xx_nand *const nand = s3c24xx_get_base_nand();
+u_long nfcont;
s/u_long/u32/
Didn't catch this...
+
+nfcont = readl(&nand->nfcont);
+
+switch (chip) {
+case -1:
+nfcont |= NFCONT_NCE1 | NFCONT_NCE0;
+break;
+case 0:
+nfcont &= ~NFCONT_NCE0;
+break;
+case 1:
+nfcont &= ~NFCONT_NCE1;
+break;
+default:
+return;
error message on default?
OK.
+}
+
+writel(nfcont, &nand->nfcont);
+}
+
+/*
+ * Hardware specific access to control-lines function
+ */
+static void s3c_nand_hwcontrol(struct mtd_info *mtd, int cmd, unsigned int
ctrl)
+{
+struct s3c24xx_nand *const nand = s3c24xx_get_base_nand();
+struct nand_chip *this = mtd->priv;
+
+if (ctrl & NAND_CTRL_CHANGE) {
+if (ctrl & NAND_CLE)
+this->IO_ADDR_W = &nand->nfcmmd;
+else if (ctrl & NAND_ALE)
+this->IO_ADDR_W = &nand->nfaddr;
+else
+this->IO_ADDR_W = &nand->nfdata;
+if (ctrl & NAND_NCE)
+s3c_nand_select_chip(mtd, *(int *)this->priv);
+else
+s3c_nand_select_chip(mtd, -1);
+}
+
+if (cmd != NAND_CMD_NONE)
+writeb(cmd, this->IO_ADDR_W);
+}
As discussed earlier, do you really need to mess with IO_ADDR_W or can you do it
the way ndfc.c does?
I will take a look at ndfc.c. Most of this driver was copy-paste from s3c64xx.c
driver and an older patched U-Boot sources from Samsung, so I did not make any
real code examination after it started to work...
I.e.:
static void s3c_nand_hwcontrol(struct mtd_info *mtd, int cmd, unsigned int ctrl)
{
struct s3c24xx_nand *const nand = s3c24xx_get_base_nand();
struct nand_chip *this = mtd->priv;
if (cmd == NAND_CMD_NONE)
return;
if (ctrl & NAND_CLE)
writeb(cmd, &nand->nfcmmd);
else
writeb(cmd, &nand->nfaddr);
}
+/*
+ * Board-specific NAND initialization.
+ */
+int board_na
Re: [U-Boot] Cache alignment warnings on Tegra (ARM)
Hi Thierry, On Tue, Sep 18, 2012 at 7:54 AM, Thierry Reding wrote: > On Mon, Sep 17, 2012 at 02:39:01PM -0700, Simon Glass wrote: >> Hi Thierry, >> >> On Sat, Sep 15, 2012 at 11:49 PM, Thierry Reding >> wrote: >> > On Sat, Sep 15, 2012 at 07:45:30PM -0700, Simon Glass wrote: >> >> Hi, >> >> >> >> On Sat, Sep 15, 2012 at 1:41 PM, Thierry Reding >> >> wrote: >> >> > On Sat, Sep 15, 2012 at 10:11:54PM +0200, Marek Vasut wrote: >> >> >> Dear Thierry Reding, >> >> >> >> >> >> > On Fri, Sep 14, 2012 at 08:53:32AM -0700, Simon Glass wrote: >> >> >> > > Hi, >> >> >> > > >> >> >> > > On Wed, Sep 12, 2012 at 4:42 PM, Marek Vasut wrote: >> >> >> > > > Dear Stephen Warren, >> >> >> > > > >> >> >> > > >> On 09/12/2012 04:38 PM, Marek Vasut wrote: >> >> >> > > >> > Dear Stephen Warren, >> >> >> > > >> > >> >> >> > > >> >> On 09/12/2012 10:19 AM, Tom Warren wrote: >> >> >> > > >> >>> Folks, >> >> >> > > >> >>> >> >> >> > > >> >>> Stephen Warren has posted an internal bug regarding the >> >> >> > > >> >>> cache >> >> >> > > >> >>> alignment 'warnings' seen on Tegra20 boards when accessing >> >> >> > > >> >>> MMC. >> >> >> > > >> >>> Here's the gist: >> >> >> > > >> >>> >> >> >> > > >> >>> Executing "mmc dev 0" still yields cache warnings: >> >> >> > > >> >>> >> >> >> > > >> >>> Tegra20 (Harmony) # mmc dev 0 >> >> >> > > >> >>> ERROR: v7_dcache_inval_range- stop address is not aligned- >> >> >> > > >> >>> 0x3fb69908 mmc0 is current device >> >> >> > > >> >> >> >> >> > > >> >> ... >> >> >> > > >> >> >> >> >> > > >> >>> There have been patches in the past (IIRC) that have tried >> >> >> > > >> >>> to >> >> >> > > >> >>> ensure all callers (FS, MMC driver, USB driver, etc.) force >> >> >> > > >> >>> their >> >> >> > > >> >>> buffers to the appropriate alignment, but I don't know that >> >> >> > > >> >>> we >> >> >> > > >> >>> can ever correct every instance, now or in the future. >> >> >> > > >> >>> >> >> >> > > >> >>> Can we start a discussion about what we can do about this >> >> >> > > >> >>> warning? >> >> >> > > >> >>> Adding an appropriate #ifdef >> >> >> > > >> >>> (CONFIG_SYS_NO_CACHE_ALIGNMENT_WARNINGS, etc.) where >> >> >> > > >> >>> Stephen put >> >> >> > > >> >>> his #if 0's would be one approach, or changing the printf() >> >> >> > > >> >>> to a >> >> >> > > >> >>> debug(), perhaps. As far as I can tell, these alignment >> >> >> > > >> >>> 'errors' >> >> >> > > >> >>> don't seem to produce bad data in the transfer. >> >> >> > > >> >> >> >> >> > > >> >> I don't think simply turning off the warning is the correct >> >> >> > > >> >> approach; I believe they represent real problems that can in >> >> >> > > >> >> fact >> >> >> > > >> >> cause data corruption. I don't believe we have any choice >> >> >> > > >> >> other >> >> >> > > >> >> than to fully solve the root-cause. >> >> >> > > >> >> >> > > Yes I agree, and I think it is pretty close - certainly much better >> >> >> > > than it used to be. The good thing about them being annoying is >> >> >> > > that >> >> >> > > they will likely get fixed :-) >> >> >> > >> >> >> > I think I traced this to the copying of CSD a while back. The >> >> >> > problem is >> >> >> > that the transferred buffer is 8 bytes, so there's no way to make it >> >> >> > aligned properly. Unfortunately the entailing discussion did not >> >> >> > yield a >> >> >> > solution at the time. >> >> >> >> >> >> And how exactly does the MMC bounce buffer not help here? >> >> > >> >> > The problem solved by the bounce buffer is that it is properly cache- >> >> > line aligned. However the issue here is not that the buffer is not >> >> > properly aligned but rather that the transfer is too small. >> >> > >> >> > When the MMC core transfers the SCR, it requests 8 bytes. The buffer >> >> > used to store these 8 bytes is properly allocated. However, those 8 >> >> > bytes eventually end up as the size of the range that is to be >> >> > invalidated. This is the reason for the warning. Address x of the buffer >> >> > is cache-line aligned, but x + 8 is never properly aligned and therefore >> >> > the code complains. >> >> >> >> Would it be too dreadful to define a minimum MMC transfer size, and >> >> set that to the cache line size? >> > >> > I did try setting the data size to the cache line size back then, but >> > that resulted in an error. After that I gave up. I think what we really >> > need to do is separate the invalidation size from the transfer size in >> > order to properly handle these situations. Or alternatively pass an >> > additional buffer size so the code knows how much needs to be >> > invalidated. AFAICT this is the only location where this actually >> > happens. All other transfers are typically block sized so they'll be a >> > multiple of the cache line anyway. >> >> I suppose the requirement is that the buffer size is large enough, and >> is aligned. Even if fewer bytes are transferred than the size of the >> buffer, that still solves the problem. As you say, if we had a w
Re: [U-Boot] [PATCH 62/71] serial: spl: Implement empty functions for SPL
Dear Tom Rini,
> On 09/18/12 11:01, Marek Vasut wrote:
> > Dear Tom Rini,
> >
> >> On 09/18/12 10:13, Marek Vasut wrote:
> >>> Dear Tom Rini,
> >>>
> On Mon, Sep 17, 2012 at 01:21:27AM +0200, Marek Vasut wrote:
> > Implement empty serial_* functions for SPL without serial
> > support enabled. This is imperative to haave once serial
> > multi is enabled unconditionally.
> >
> > Signed-off-by: Marek Vasut Cc: Marek Vasut
> > Cc: Tom Rini ---
> >
> > common/serial.c | 12 1 file changed, 12
> > insertions(+)
> >
> > diff --git a/common/serial.c b/common/serial.c index
> > 631af65..cef4ba8 100644 --- a/common/serial.c +++
> > b/common/serial.c @@ -27,6 +27,16 @@
> >
> > #include #include
> >
> > +/* Implement prototypes for SPL without serial support */
> > +#if defined(CONFIG_SPL_BUILD) &&
> > !defined(CONFIG_SPL_SERIAL_SUPPORT) +int serial_init(void)
> > { return 0; } +void serial_setbrg(void) {} +int
> > serial_getc(void) { return 0; } +int serial_tstc(void) {
> > return 0; } +void serial_putc(const char c) {} +void
> > serial_puts(const char *s) {}
>
> This isn't quite right. We need to allow for: - No output
> SPL, strings collected (so #defined to do{} while (0))
> >>>
> >>> Which is not type-checked and will drag in bugs.
> >>
> >> Scott has addressed this.
> >>
> - puts + printf SPL (CONFIG_SPL_SERIAL_SUPPORT +
> CONFIG_SPL_LIBCOMMON_SUPPORT) - puts only SPL
> (CONFIG_SPL_SERIAL_SUPPORT + #define puts serial_puts/putc).
>
> I'm not asking you to do that, but you will have to adapt to
> it once Jose is done with it. What that means, off the top
> of my head, is we can just drop this patch as in the first
> and last case serial.o will be garbage-collected (or not
> built) and in the middle case, this will be fully used.
> >>>
> >>> I can't drop this patch as it will break all of SPL when
> >>> CONFIG_SERIAL_MULTI is unconditionally enabled.
> >>
> >> Why is it breaking _all_ of SPL? Have you run-tested this
> >> anywhere, especially with SPL? In most cases it should be used
> >> and real functions provided or garbage collected away.
> >
> > Yes, try compiling m28evk without this patch for example, it's
> > going to break it. Because CONFIG_SPL_SERIAL_SUPPORT is disabled,
> > yet it uses code that contains references to puts() etc.
>
> Progress! Now, why isn't this file being garbage collected?
What file?
> m28evk
> is fitting into the first category I said (no output) but now it's not
> discarding things that it should be discarding.
What is not discarding things and what things should be discarded? I believe if
you're missing symbols, the compiler will error-out. Always.
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 62/71] serial: spl: Implement empty functions for SPL
On 09/18/2012 01:03:17 PM, Marek Vasut wrote:
Dear Scott Wood,
> On 09/18/2012 12:13:57 PM, Marek Vasut wrote:
> > Dear Tom Rini,
> >
> > > On Mon, Sep 17, 2012 at 01:21:27AM +0200, Marek Vasut wrote:
> > > > Implement empty serial_* functions for SPL without serial
> > > > support enabled. This is imperative to haave once serial
> > > > multi is enabled unconditionally.
> > > >
> > > > Signed-off-by: Marek Vasut
> > > > Cc: Marek Vasut
> > > > Cc: Tom Rini
> > > > ---
> > > >
> > > > common/serial.c | 12
> > > > 1 file changed, 12 insertions(+)
> > > >
> > > > diff --git a/common/serial.c b/common/serial.c
> > > > index 631af65..cef4ba8 100644
> > > > --- a/common/serial.c
> > > > +++ b/common/serial.c
> > > > @@ -27,6 +27,16 @@
> > > >
> > > > #include
> > > > #include
> > > >
> > > > +/* Implement prototypes for SPL without serial support */
> > > > +#if defined(CONFIG_SPL_BUILD) &&
> >
> > !defined(CONFIG_SPL_SERIAL_SUPPORT)
> >
> > > > +int serial_init(void) { return 0; }
> > > > +void serial_setbrg(void) {}
> > > > +int serial_getc(void) { return 0; }
> > > > +int serial_tstc(void) { return 0; }
> > > > +void serial_putc(const char c) {}
> > > > +void serial_puts(const char *s) {}
> > >
> > > This isn't quite right. We need to allow for:
> > > - No output SPL, strings collected (so #defined to do{} while
(0))
> >
> > Which is not type-checked and will drag in bugs.
>
> Not all that likely, since most code will either be built with
printf
> enabled some of the time, or not contain printf (i.e. it's not quite
> the same situation as debug prints which may be rarely enabled).
>
> An inline function would be fine, but has to be done at the same
place
> that normal printf is declared -- whereas a macro could be done
after
> the fact. Unless you use a macro to redirect it to an inline
function
> of a different name...
>
> I do not understand why you want to put these stubs in a C file
instead
> of a header file, though -- you're preventing code from being
optimized
> away, which is important in some SPLs.
I'd say the GCC must optimize it out anyway.
I think I got some wires crossed and was thinking about printf/puts.
We want those to be optimized away at compile time (not pointed to a
stub at link time) on an SPL that has no output support, but once
that's done the low level serial functions shouldn't be referenced
anymore, right?
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 09/11] S3C24XX: Add NAND Flash driver
On 09/18/2012 01:22:58 PM, José Miguel Gonçalves wrote:
On 18-09-2012 19:02, Scott Wood wrote:
On 09/18/2012 12:40:36 PM, José Miguel Gonçalves wrote:
+#define TACLS_VAL7/* CLE & ALE duration setting (0~7) */
+#defineTWRPH0_VAL7/* TWRPH0 duration setting (0~7) */
+#define TWRPH1_VAL7/* TWRPH1 duration setting (0~7) */
Please use space, not tab, as a word separator (after the second
#define).
OK.
+
+#define MAX_CHIPS2
+static int nand_cs[MAX_CHIPS] = { 0, 1 };
This needs explanation (and const). Better would be to use a priv
struct, as discussed before.
+static void s3c_nand_select_chip(struct mtd_info *mtd, int chip)
+{
+struct s3c24xx_nand *const nand = s3c24xx_get_base_nand();
+u_long nfcont;
s/u_long/u32/
Didn't catch this...
Replace u_long with u32.
+nfcont = readl(&nand->nfcont);
+
+switch (chip) {
+case -1:
+nfcont |= NFCONT_NCE1 | NFCONT_NCE0;
+break;
+case 0:
+nfcont &= ~NFCONT_NCE0;
+break;
+case 1:
+nfcont &= ~NFCONT_NCE1;
+break;
+default:
+return;
error message on default?
OK.
+}
+
+writel(nfcont, &nand->nfcont);
+}
+
+/*
+ * Hardware specific access to control-lines function
+ */
+static void s3c_nand_hwcontrol(struct mtd_info *mtd, int cmd,
unsigned int ctrl)
+{
+struct s3c24xx_nand *const nand = s3c24xx_get_base_nand();
+struct nand_chip *this = mtd->priv;
+
+if (ctrl & NAND_CTRL_CHANGE) {
+if (ctrl & NAND_CLE)
+this->IO_ADDR_W = &nand->nfcmmd;
+else if (ctrl & NAND_ALE)
+this->IO_ADDR_W = &nand->nfaddr;
+else
+this->IO_ADDR_W = &nand->nfdata;
+if (ctrl & NAND_NCE)
+s3c_nand_select_chip(mtd, *(int *)this->priv);
+else
+s3c_nand_select_chip(mtd, -1);
+}
+
+if (cmd != NAND_CMD_NONE)
+writeb(cmd, this->IO_ADDR_W);
+}
As discussed earlier, do you really need to mess with IO_ADDR_W or
can you do it the way ndfc.c does?
I will take a look at ndfc.c.
Most of this driver was copy-paste from s3c64xx.c driver and an older
patched U-Boot sources from Samsung, so I did not make any real code
examination after it started to work...
I.e.:
static void s3c_nand_hwcontrol(struct mtd_info *mtd, int cmd,
unsigned int ctrl)
{
struct s3c24xx_nand *const nand = s3c24xx_get_base_nand();
struct nand_chip *this = mtd->priv;
if (cmd == NAND_CMD_NONE)
return;
if (ctrl & NAND_CLE)
writeb(cmd, &nand->nfcmmd);
else
writeb(cmd, &nand->nfaddr);
}
Oh sorry -- the above is missing the NCE part. Before the
NAND_CMD_NONE check insert:
if (ctrl & NAND_CTRL_CHANGE) {
if (ctrl & NAND_NCE)
s3c_nand_select_chip(mtd, *(const int
*)this->priv);
else
s3c_nand_select_chip(mtd, -1);
}
+/*
+ * Board-specific NAND initialization.
+ */
+int board_nand_init(struct nand_chip *nand)
+{
+static int chip_n;
+struct s3c24xx_nand *const nand_reg = s3c24xx_get_base_nand();
+
+if (chip_n == 0) {
+/* Extend NAND timings to the maximum */
+clrsetbits_le32(&nand_reg->nfconf,
+NFCONF_TACLS_MASK | NFCONF_TWRPH0_MASK |
+NFCONF_TWRPH1_MASK,
+NFCONF_TACLS(TACLS_VAL) |
+NFCONF_TWRPH0(TWRPH0_VAL) |
+NFCONF_TWRPH1(TWRPH1_VAL));
+
+/* Disable chip selects and soft lock, enable controller */
+clrsetbits_le32(&nand_reg->nfcont, NFCONT_WP,
+NFCONT_NCE1 | NFCONT_NCE0 | NFCONT_ENABLE);
+} else if (chip_n >= MAX_CHIPS) {
+return -ENODEV;
+}
+
+nand->IO_ADDR_R = &nand_reg->nfdata;
+nand->IO_ADDR_W = &nand_reg->nfdata;
+nand->cmd_ctrl = s3c_nand_hwcontrol;
+nand->dev_ready = s3c_nand_device_ready;
+nand->select_chip = s3c_nand_select_chip;
+nand->options = 0;
+#ifdef CONFIG_SPL_BUILD
+nand->read_buf = nand_read_buf;
+#endif
+
+#ifdef CONFIG_S3C24XX_NAND_HWECC
+nand->ecc.hwctl = s3c_nand_enable_hwecc;
+nand->ecc.calculate = s3c_nand_calculate_ecc;
+nand->ecc.correct = s3c_nand_correct_data;
+nand->ecc.mode = NAND_ECC_HW_OOB_FIRST;
+nand->ecc.size = CONFIG_SYS_NAND_ECCSIZE;
+nand->ecc.bytes = CONFIG_SYS_NAND_ECCBYTES;
+#else
+nand->ecc.mode = NAND_ECC_SOFT;
+#endif /* ! CONFIG_S3C24XX_NAND_HWECC */
+
+nand->priv = nand_cs + chip_n++;
+
+return 0;
+}
Please consider using the new SELF_INIT mechanism.
Can you explain and/or point_to_resources for what this means (I'm a
U-Boot newbie)...
See CONFIG_SYS_NAND_SELF_INIT in doc/README.nand
I'd like the old way to be removed at some point.
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 62/71] serial: spl: Implement empty functions for SPL
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/18/12 11:24, Marek Vasut wrote:
> Dear Tom Rini,
>
>> On 09/18/12 11:01, Marek Vasut wrote:
>>> Dear Tom Rini,
>>>
On 09/18/12 10:13, Marek Vasut wrote:
> Dear Tom Rini,
>
>> On Mon, Sep 17, 2012 at 01:21:27AM +0200, Marek Vasut
>> wrote:
>>> Implement empty serial_* functions for SPL without
>>> serial support enabled. This is imperative to haave
>>> once serial multi is enabled unconditionally.
>>>
>>> Signed-off-by: Marek Vasut Cc: Marek
>>> Vasut Cc: Tom Rini
>>> ---
>>>
>>> common/serial.c | 12 1 file changed, 12
>>> insertions(+)
>>>
>>> diff --git a/common/serial.c b/common/serial.c index
>>> 631af65..cef4ba8 100644 --- a/common/serial.c +++
>>> b/common/serial.c @@ -27,6 +27,16 @@
>>>
>>> #include #include
>>>
>>> +/* Implement prototypes for SPL without serial support
>>> */ +#if defined(CONFIG_SPL_BUILD) &&
>>> !defined(CONFIG_SPL_SERIAL_SUPPORT) +int
>>> serial_init(void) { return 0; } +void
>>> serial_setbrg(void) {} +int serial_getc(void) { return
>>> 0; } +int serial_tstc(void) { return 0; } +void
>>> serial_putc(const char c) {} +void serial_puts(const
>>> char *s) {}
>>
>> This isn't quite right. We need to allow for: - No
>> output SPL, strings collected (so #defined to do{} while
>> (0))
>
> Which is not type-checked and will drag in bugs.
Scott has addressed this.
>> - puts + printf SPL (CONFIG_SPL_SERIAL_SUPPORT +
>> CONFIG_SPL_LIBCOMMON_SUPPORT) - puts only SPL
>> (CONFIG_SPL_SERIAL_SUPPORT + #define puts
>> serial_puts/putc).
>>
>> I'm not asking you to do that, but you will have to adapt
>> to it once Jose is done with it. What that means, off
>> the top of my head, is we can just drop this patch as in
>> the first and last case serial.o will be
>> garbage-collected (or not built) and in the middle case,
>> this will be fully used.
>
> I can't drop this patch as it will break all of SPL when
> CONFIG_SERIAL_MULTI is unconditionally enabled.
Why is it breaking _all_ of SPL? Have you run-tested this
anywhere, especially with SPL? In most cases it should be
used and real functions provided or garbage collected away.
>>>
>>> Yes, try compiling m28evk without this patch for example, it's
>>> going to break it. Because CONFIG_SPL_SERIAL_SUPPORT is
>>> disabled, yet it uses code that contains references to puts()
>>> etc.
>>
>> Progress! Now, why isn't this file being garbage collected?
>
> What file?
common/serial.o since as you point out, m28evk doesn't define any way
to do output.
>> m28evk is fitting into the first category I said (no output) but
>> now it's not discarding things that it should be discarding.
>
> What is not discarding things and what things should be discarded?
> I believe if you're missing symbols, the compiler will error-out.
> Always.
Nope. This is fine:
gc_this_function(void) {
never_define_this_at_link();
return;
}
And nothing calling gc_this_function means that it's fine that
never_define_this_at_link isn't seen by the linker.
- --
Tom
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
iQIcBAEBAgAGBQJQWL7QAAoJENk4IS6UOR1W+KgP/jjDmO3c+WfYqEjuEjLMjSAW
qTLZOLdsmsU7HoFa+/fWNgmvvmcJlTgqzo0z5izku2d0xx8TO3R6rpZa9weHXhr1
yuKs+CzP/6A1Kntd8VC0SRUU+Rb4onPPoY0kw0QDL01zug5DBEu+saI08CJRrtki
DLzayRPNoTcppffp1r2nstyAJJWvuYcFO4A3wzR3h5U1lQNHK7Yt8KRtmCFQW1d1
Y98ikHi75PDcSZDjj60OHVhNtaDDcLUu2NWAXrf4gI13WLPxcNXHRTq1uufY38Pv
fNd5wqrC7qDq7I6uomwuy+b6aDYYPqsrh9T/h/tjWO235mA+7Dnkl2qvHrYOOcV6
1zBef8M+vuawVWYZnsJO4k1Cg2Ci9Gl4sPqJVYaSnhhXjQawZbztQpT1P4tN1DEG
8r7mpt6bWGG1nnEgiNWvFZvv798sj2Lh/T0yxAsnX9CgnlxZ7lh+uqirMmUJeUKB
aWiuDJIMqQORXcJIO1tDwtL+2EA5CxofLa11Y0tpT0r2G0cOsQQQfJTQ6K9p4KhB
gkOhRmlPQs12WV+9r6LWuUqDRuIbMjOUHfNOf9eZfKTvptMMRhwT1zCVBdMVwbwO
3e/WpNTDjRLpqj08bs6OHOVO7GvXXtZJGHJJGlJ3a49pHMnqNUjBGSajDYJyHL0O
/75PPDTIXSrUJw1anFC8
=yREs
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 62/71] serial: spl: Implement empty functions for SPL
Dear Scott Wood,
> On 09/18/2012 01:03:17 PM, Marek Vasut wrote:
> > Dear Scott Wood,
> >
> > > On 09/18/2012 12:13:57 PM, Marek Vasut wrote:
> > > > Dear Tom Rini,
> > > >
> > > > > On Mon, Sep 17, 2012 at 01:21:27AM +0200, Marek Vasut wrote:
> > > > > > Implement empty serial_* functions for SPL without serial
> > > > > > support enabled. This is imperative to haave once serial
> > > > > > multi is enabled unconditionally.
> > > > > >
> > > > > > Signed-off-by: Marek Vasut
> > > > > > Cc: Marek Vasut
> > > > > > Cc: Tom Rini
> > > > > > ---
> > > > > >
> > > > > > common/serial.c | 12
> > > > > > 1 file changed, 12 insertions(+)
> > > > > >
> > > > > > diff --git a/common/serial.c b/common/serial.c
> > > > > > index 631af65..cef4ba8 100644
> > > > > > --- a/common/serial.c
> > > > > > +++ b/common/serial.c
> > > > > > @@ -27,6 +27,16 @@
> > > > > >
> > > > > > #include
> > > > > > #include
> > > > > >
> > > > > > +/* Implement prototypes for SPL without serial support */
> > > > > > +#if defined(CONFIG_SPL_BUILD) &&
> > > >
> > > > !defined(CONFIG_SPL_SERIAL_SUPPORT)
> > > >
> > > > > > +int serial_init(void) { return 0; }
> > > > > > +void serial_setbrg(void) {}
> > > > > > +int serial_getc(void) { return 0; }
> > > > > > +int serial_tstc(void) { return 0; }
> > > > > > +void serial_putc(const char c) {}
> > > > > > +void serial_puts(const char *s) {}
> > > > >
> > > > > This isn't quite right. We need to allow for:
> > > > > - No output SPL, strings collected (so #defined to do{} while
> >
> > (0))
> >
> > > > Which is not type-checked and will drag in bugs.
> > >
> > > Not all that likely, since most code will either be built with
> >
> > printf
> >
> > > enabled some of the time, or not contain printf (i.e. it's not quite
> > > the same situation as debug prints which may be rarely enabled).
> > >
> > > An inline function would be fine, but has to be done at the same
> >
> > place
> >
> > > that normal printf is declared -- whereas a macro could be done
> >
> > after
> >
> > > the fact. Unless you use a macro to redirect it to an inline
> >
> > function
> >
> > > of a different name...
> > >
> > > I do not understand why you want to put these stubs in a C file
> >
> > instead
> >
> > > of a header file, though -- you're preventing code from being
> >
> > optimized
> >
> > > away, which is important in some SPLs.
> >
> > I'd say the GCC must optimize it out anyway.
>
> I think I got some wires crossed and was thinking about printf/puts.
> We want those to be optimized away at compile time (not pointed to a
> stub at link time) on an SPL that has no output support, but once
> that's done the low level serial functions shouldn't be referenced
> anymore, right?
But if you point them to stubs, that's OK. The compiler will GC these useless
stubs anyway. But wait, we're getting to LTO here, right?
So the safest bet really is macro in serial.h ?
> -Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Cache alignment warnings on Tegra (ARM)
Dear Simon Glass, > Hi Thierry, > > On Tue, Sep 18, 2012 at 7:54 AM, Thierry Reding > > wrote: > > On Mon, Sep 17, 2012 at 02:39:01PM -0700, Simon Glass wrote: > >> Hi Thierry, > >> > >> On Sat, Sep 15, 2012 at 11:49 PM, Thierry Reding > >> > >> wrote: > >> > On Sat, Sep 15, 2012 at 07:45:30PM -0700, Simon Glass wrote: > >> >> Hi, > >> >> > >> >> On Sat, Sep 15, 2012 at 1:41 PM, Thierry Reding > >> >> > >> >> wrote: > >> >> > On Sat, Sep 15, 2012 at 10:11:54PM +0200, Marek Vasut wrote: > >> >> >> Dear Thierry Reding, > >> >> >> > >> >> >> > On Fri, Sep 14, 2012 at 08:53:32AM -0700, Simon Glass wrote: > >> >> >> > > Hi, > >> >> >> > > > >> >> >> > > On Wed, Sep 12, 2012 at 4:42 PM, Marek Vasut wrote: > >> >> >> > > > Dear Stephen Warren, > >> >> >> > > > > >> >> >> > > >> On 09/12/2012 04:38 PM, Marek Vasut wrote: > >> >> >> > > >> > Dear Stephen Warren, > >> >> >> > > >> > > >> >> >> > > >> >> On 09/12/2012 10:19 AM, Tom Warren wrote: > >> >> >> > > >> >>> Folks, > >> >> >> > > >> >>> > >> >> >> > > >> >>> Stephen Warren has posted an internal bug regarding the > >> >> >> > > >> >>> cache alignment 'warnings' seen on Tegra20 boards when > >> >> >> > > >> >>> accessing MMC. Here's the gist: > >> >> >> > > >> >>> > >> >> >> > > >> >>> Executing "mmc dev 0" still yields cache warnings: > >> >> >> > > >> >>> > >> >> >> > > >> >>> Tegra20 (Harmony) # mmc dev 0 > >> >> >> > > >> >>> ERROR: v7_dcache_inval_range- stop address is not > >> >> >> > > >> >>> aligned- 0x3fb69908 mmc0 is current device > >> >> >> > > >> >> > >> >> >> > > >> >> ... > >> >> >> > > >> >> > >> >> >> > > >> >>> There have been patches in the past (IIRC) that have > >> >> >> > > >> >>> tried to ensure all callers (FS, MMC driver, USB > >> >> >> > > >> >>> driver, etc.) force their buffers to the appropriate > >> >> >> > > >> >>> alignment, but I don't know that we can ever correct > >> >> >> > > >> >>> every instance, now or in the future. > >> >> >> > > >> >>> > >> >> >> > > >> >>> Can we start a discussion about what we can do about > >> >> >> > > >> >>> this warning? Adding an appropriate #ifdef > >> >> >> > > >> >>> (CONFIG_SYS_NO_CACHE_ALIGNMENT_WARNINGS, etc.) where > >> >> >> > > >> >>> Stephen put his #if 0's would be one approach, or > >> >> >> > > >> >>> changing the printf() to a debug(), perhaps. As far as > >> >> >> > > >> >>> I can tell, these alignment 'errors' don't seem to > >> >> >> > > >> >>> produce bad data in the transfer. > >> >> >> > > >> >> > >> >> >> > > >> >> I don't think simply turning off the warning is the > >> >> >> > > >> >> correct approach; I believe they represent real > >> >> >> > > >> >> problems that can in fact cause data corruption. I > >> >> >> > > >> >> don't believe we have any choice other than to fully > >> >> >> > > >> >> solve the root-cause. > >> >> >> > > > >> >> >> > > Yes I agree, and I think it is pretty close - certainly much > >> >> >> > > better than it used to be. The good thing about them being > >> >> >> > > annoying is that they will likely get fixed :-) > >> >> >> > > >> >> >> > I think I traced this to the copying of CSD a while back. The > >> >> >> > problem is that the transferred buffer is 8 bytes, so there's > >> >> >> > no way to make it aligned properly. Unfortunately the entailing > >> >> >> > discussion did not yield a solution at the time. > >> >> >> > >> >> >> And how exactly does the MMC bounce buffer not help here? > >> >> > > >> >> > The problem solved by the bounce buffer is that it is properly > >> >> > cache- line aligned. However the issue here is not that the buffer > >> >> > is not properly aligned but rather that the transfer is too small. > >> >> > > >> >> > When the MMC core transfers the SCR, it requests 8 bytes. The > >> >> > buffer used to store these 8 bytes is properly allocated. However, > >> >> > those 8 bytes eventually end up as the size of the range that is > >> >> > to be invalidated. This is the reason for the warning. Address x > >> >> > of the buffer is cache-line aligned, but x + 8 is never properly > >> >> > aligned and therefore the code complains. > >> >> > >> >> Would it be too dreadful to define a minimum MMC transfer size, and > >> >> set that to the cache line size? > >> > > >> > I did try setting the data size to the cache line size back then, but > >> > that resulted in an error. After that I gave up. I think what we > >> > really need to do is separate the invalidation size from the transfer > >> > size in order to properly handle these situations. Or alternatively > >> > pass an additional buffer size so the code knows how much needs to be > >> > invalidated. AFAICT this is the only location where this actually > >> > happens. All other transfers are typically block sized so they'll be > >> > a multiple of the cache line anyway. > >> > >> I suppose the requirement is that the buffer size is large enough, and > >> is aligned. Even if fewer bytes are transferred than the size of the > >> buffer, that stil
Re: [U-Boot] [PATCH 62/71] serial: spl: Implement empty functions for SPL
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/18/12 11:33, Marek Vasut wrote:
> Dear Scott Wood,
[snip]
>> I think I got some wires crossed and was thinking about
>> printf/puts. We want those to be optimized away at compile time
>> (not pointed to a stub at link time) on an SPL that has no output
>> support, but once that's done the low level serial functions
>> shouldn't be referenced anymore, right?
>
> But if you point them to stubs, that's OK. The compiler will GC
> these useless stubs anyway. But wait, we're getting to LTO here,
> right?
>
> So the safest bet really is macro in serial.h ?
Due to the gcc bug I've mentioned before, yes. Dummy functions will,
I bet, keep the string constants around. do {} while(0) will drop
them out entirely.
- --
Tom
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
iQIcBAEBAgAGBQJQWL/mAAoJENk4IS6UOR1WwXQQAJXFmoGOjTxtuq1PMDYIEUSg
mGwZUgjTDy3wrzVl8xkzuSeRYtqL/vFbThHDVoAiWXcQ2/4Mrcunl3v3UW+QV2ye
KwESGqd05CIUEDxFqihOIKCR2KZHpUkt45Uf6SPOXfB4A0O7N9CuvyxPl2ZFHGxx
ePFwopmX9gL7xO3u1cjAtxtmiCS22ulztW3ROU3+NTsVKA3k4AXW617tjpsPmQzJ
L9N2LX49Z+UGDxh7YW/M4wcD50GlZFyIUY1COyhxeAQXmCXRMeDJdqxU1f3+SG1G
fnWsBPoVdIJEv8XBr+ABNd4DYDZCWsTA7uklvkt2NDh64Lp+Nge5dD92fZJfrKoc
NUWLhXN1U9ko9xbflxlBK94zkmtJfLfvtboK58frjv/H7MlSIuUzbgH4ixq/5ZOM
g5pKFQ2YynrZ0yrjqH8I/v50GsziT+LpAiQnE62Yt2EQMkNCIC1zDz9ikg3MhL63
sxiZPi0mpcbvao6f6l0JIllMkvEWBnM4fGQCWMGGOkjbCqvkSnBNt4BhgAK2ZXuC
kcLkdeOhszdWZxhfK+V0d5U+XQdIJoHdYyVC+6hAEd5iO4++gXgx+8feQV+ZQvSS
8iCdnobNp6XfM6agNOpkJto0+ROqEIyDSUzBAOb3+474fSWBjhhY7ievGxZiKikx
mhsHRYG6ziEdOt4bkQ5H
=m9GH
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 09/11] S3C24XX: Add NAND Flash driver
On 18-09-2012 19:30, Scott Wood wrote:
On 09/18/2012 01:22:58 PM, José Miguel Gonçalves wrote:
On 18-09-2012 19:02, Scott Wood wrote:
On 09/18/2012 12:40:36 PM, José Miguel Gonçalves wrote:
+#define TACLS_VAL7/* CLE & ALE duration setting (0~7) */
+#defineTWRPH0_VAL7/* TWRPH0 duration setting (0~7) */
+#define TWRPH1_VAL7/* TWRPH1 duration setting (0~7) */
Please use space, not tab, as a word separator (after the second #define).
OK.
+
+#define MAX_CHIPS2
+static int nand_cs[MAX_CHIPS] = { 0, 1 };
This needs explanation (and const). Better would be to use a priv struct, as
discussed before.
+static void s3c_nand_select_chip(struct mtd_info *mtd, int chip)
+{
+struct s3c24xx_nand *const nand = s3c24xx_get_base_nand();
+u_long nfcont;
s/u_long/u32/
Didn't catch this...
Replace u_long with u32.
OK (didn't expected a regex expression in that context...)
+nfcont = readl(&nand->nfcont);
+
+switch (chip) {
+case -1:
+nfcont |= NFCONT_NCE1 | NFCONT_NCE0;
+break;
+case 0:
+nfcont &= ~NFCONT_NCE0;
+break;
+case 1:
+nfcont &= ~NFCONT_NCE1;
+break;
+default:
+return;
error message on default?
OK.
+}
+
+writel(nfcont, &nand->nfcont);
+}
+
+/*
+ * Hardware specific access to control-lines function
+ */
+static void s3c_nand_hwcontrol(struct mtd_info *mtd, int cmd, unsigned int
ctrl)
+{
+struct s3c24xx_nand *const nand = s3c24xx_get_base_nand();
+struct nand_chip *this = mtd->priv;
+
+if (ctrl & NAND_CTRL_CHANGE) {
+if (ctrl & NAND_CLE)
+this->IO_ADDR_W = &nand->nfcmmd;
+else if (ctrl & NAND_ALE)
+this->IO_ADDR_W = &nand->nfaddr;
+else
+this->IO_ADDR_W = &nand->nfdata;
+if (ctrl & NAND_NCE)
+s3c_nand_select_chip(mtd, *(int *)this->priv);
+else
+s3c_nand_select_chip(mtd, -1);
+}
+
+if (cmd != NAND_CMD_NONE)
+writeb(cmd, this->IO_ADDR_W);
+}
As discussed earlier, do you really need to mess with IO_ADDR_W or can you do
it the way ndfc.c does?
I will take a look at ndfc.c.
Most of this driver was copy-paste from s3c64xx.c driver and an older patched
U-Boot sources from Samsung, so I did not make any real code examination after
it started to work...
I.e.:
static void s3c_nand_hwcontrol(struct mtd_info *mtd, int cmd, unsigned int ctrl)
{
struct s3c24xx_nand *const nand = s3c24xx_get_base_nand();
struct nand_chip *this = mtd->priv;
if (cmd == NAND_CMD_NONE)
return;
if (ctrl & NAND_CLE)
writeb(cmd, &nand->nfcmmd);
else
writeb(cmd, &nand->nfaddr);
}
Oh sorry -- the above is missing the NCE part. Before the NAND_CMD_NONE check
insert:
if (ctrl & NAND_CTRL_CHANGE) {
if (ctrl & NAND_NCE)
s3c_nand_select_chip(mtd, *(const int *)this->priv);
else
s3c_nand_select_chip(mtd, -1);
}
+/*
+ * Board-specific NAND initialization.
+ */
+int board_nand_init(struct nand_chip *nand)
+{
+static int chip_n;
+struct s3c24xx_nand *const nand_reg = s3c24xx_get_base_nand();
+
+if (chip_n == 0) {
+/* Extend NAND timings to the maximum */
+clrsetbits_le32(&nand_reg->nfconf,
+NFCONF_TACLS_MASK | NFCONF_TWRPH0_MASK |
+NFCONF_TWRPH1_MASK,
+NFCONF_TACLS(TACLS_VAL) |
+NFCONF_TWRPH0(TWRPH0_VAL) |
+NFCONF_TWRPH1(TWRPH1_VAL));
+
+/* Disable chip selects and soft lock, enable controller */
+clrsetbits_le32(&nand_reg->nfcont, NFCONT_WP,
+NFCONT_NCE1 | NFCONT_NCE0 | NFCONT_ENABLE);
+} else if (chip_n >= MAX_CHIPS) {
+return -ENODEV;
+}
+
+nand->IO_ADDR_R = &nand_reg->nfdata;
+nand->IO_ADDR_W = &nand_reg->nfdata;
+nand->cmd_ctrl = s3c_nand_hwcontrol;
+nand->dev_ready = s3c_nand_device_ready;
+nand->select_chip = s3c_nand_select_chip;
+nand->options = 0;
+#ifdef CONFIG_SPL_BUILD
+nand->read_buf = nand_read_buf;
+#endif
+
+#ifdef CONFIG_S3C24XX_NAND_HWECC
+nand->ecc.hwctl = s3c_nand_enable_hwecc;
+nand->ecc.calculate = s3c_nand_calculate_ecc;
+nand->ecc.correct = s3c_nand_correct_data;
+nand->ecc.mode = NAND_ECC_HW_OOB_FIRST;
+nand->ecc.size = CONFIG_SYS_NAND_ECCSIZE;
+nand->ecc.bytes = CONFIG_SYS_NAND_ECCBYTES;
+#else
+nand->ecc.mode = NAND_ECC_SOFT;
+#endif /* ! CONFIG_S3C24XX_NAND_HWECC */
+
+nand->priv = nand_cs + chip_n++;
+
+return 0;
+}
Please consider using the new SELF_INIT mechanism.
Can you explain and/or point_to_resources for what this means (I'm a U-Boot
newbie)...
See CONFIG_SYS_NAND_SELF_INIT in doc/README.nand
I'd like the old way to be removed at some point.
From what I've seen there is an incompatibility between the SPL simple nand
driver and the SELF_INIT mechanism.
The nand_init() function in drivers/mtd/nan
Re: [U-Boot] [PATCH 62/71] serial: spl: Implement empty functions for SPL
Dear Tom Rini,
> On 09/18/12 11:33, Marek Vasut wrote:
> > Dear Scott Wood,
>
> [snip]
>
> >> I think I got some wires crossed and was thinking about
> >> printf/puts. We want those to be optimized away at compile time
> >> (not pointed to a stub at link time) on an SPL that has no output
> >> support, but once that's done the low level serial functions
> >> shouldn't be referenced anymore, right?
> >
> > But if you point them to stubs, that's OK. The compiler will GC
> > these useless stubs anyway. But wait, we're getting to LTO here,
> > right?
> >
> > So the safest bet really is macro in serial.h ?
>
> Due to the gcc bug I've mentioned before, yes. Dummy functions will,
> I bet, keep the string constants around. do {} while(0) will drop
> them out entirely.
Yea ... the GCC bug, what a crap :-(
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Cache alignment warnings on Tegra (ARM)
On Tue, Sep 18, 2012 at 08:37:44PM +0200, Marek Vasut wrote: > Dear Simon Glass, > > > Hi Thierry, > > > > On Tue, Sep 18, 2012 at 7:54 AM, Thierry Reding > > > > wrote: > > > On Mon, Sep 17, 2012 at 02:39:01PM -0700, Simon Glass wrote: > > >> Hi Thierry, > > >> > > >> On Sat, Sep 15, 2012 at 11:49 PM, Thierry Reding > > >> > > >> wrote: > > >> > On Sat, Sep 15, 2012 at 07:45:30PM -0700, Simon Glass wrote: > > >> >> Hi, > > >> >> > > >> >> On Sat, Sep 15, 2012 at 1:41 PM, Thierry Reding > > >> >> > > >> >> wrote: > > >> >> > On Sat, Sep 15, 2012 at 10:11:54PM +0200, Marek Vasut wrote: > > >> >> >> Dear Thierry Reding, > > >> >> >> > > >> >> >> > On Fri, Sep 14, 2012 at 08:53:32AM -0700, Simon Glass wrote: > > >> >> >> > > Hi, > > >> >> >> > > > > >> >> >> > > On Wed, Sep 12, 2012 at 4:42 PM, Marek Vasut > wrote: > > >> >> >> > > > Dear Stephen Warren, > > >> >> >> > > > > > >> >> >> > > >> On 09/12/2012 04:38 PM, Marek Vasut wrote: > > >> >> >> > > >> > Dear Stephen Warren, > > >> >> >> > > >> > > > >> >> >> > > >> >> On 09/12/2012 10:19 AM, Tom Warren wrote: > > >> >> >> > > >> >>> Folks, > > >> >> >> > > >> >>> > > >> >> >> > > >> >>> Stephen Warren has posted an internal bug regarding the > > >> >> >> > > >> >>> cache alignment 'warnings' seen on Tegra20 boards when > > >> >> >> > > >> >>> accessing MMC. Here's the gist: > > >> >> >> > > >> >>> > > >> >> >> > > >> >>> Executing "mmc dev 0" still yields cache warnings: > > >> >> >> > > >> >>> > > >> >> >> > > >> >>> Tegra20 (Harmony) # mmc dev 0 > > >> >> >> > > >> >>> ERROR: v7_dcache_inval_range- stop address is not > > >> >> >> > > >> >>> aligned- 0x3fb69908 mmc0 is current device > > >> >> >> > > >> >> > > >> >> >> > > >> >> ... > > >> >> >> > > >> >> > > >> >> >> > > >> >>> There have been patches in the past (IIRC) that have > > >> >> >> > > >> >>> tried to ensure all callers (FS, MMC driver, USB > > >> >> >> > > >> >>> driver, etc.) force their buffers to the appropriate > > >> >> >> > > >> >>> alignment, but I don't know that we can ever correct > > >> >> >> > > >> >>> every instance, now or in the future. > > >> >> >> > > >> >>> > > >> >> >> > > >> >>> Can we start a discussion about what we can do about > > >> >> >> > > >> >>> this warning? Adding an appropriate #ifdef > > >> >> >> > > >> >>> (CONFIG_SYS_NO_CACHE_ALIGNMENT_WARNINGS, etc.) where > > >> >> >> > > >> >>> Stephen put his #if 0's would be one approach, or > > >> >> >> > > >> >>> changing the printf() to a debug(), perhaps. As far as > > >> >> >> > > >> >>> I can tell, these alignment 'errors' don't seem to > > >> >> >> > > >> >>> produce bad data in the transfer. > > >> >> >> > > >> >> > > >> >> >> > > >> >> I don't think simply turning off the warning is the > > >> >> >> > > >> >> correct approach; I believe they represent real > > >> >> >> > > >> >> problems that can in fact cause data corruption. I > > >> >> >> > > >> >> don't believe we have any choice other than to fully > > >> >> >> > > >> >> solve the root-cause. > > >> >> >> > > > > >> >> >> > > Yes I agree, and I think it is pretty close - certainly much > > >> >> >> > > better than it used to be. The good thing about them being > > >> >> >> > > annoying is that they will likely get fixed :-) > > >> >> >> > > > >> >> >> > I think I traced this to the copying of CSD a while back. The > > >> >> >> > problem is that the transferred buffer is 8 bytes, so there's > > >> >> >> > no way to make it aligned properly. Unfortunately the entailing > > >> >> >> > discussion did not yield a solution at the time. > > >> >> >> > > >> >> >> And how exactly does the MMC bounce buffer not help here? > > >> >> > > > >> >> > The problem solved by the bounce buffer is that it is properly > > >> >> > cache- line aligned. However the issue here is not that the buffer > > >> >> > is not properly aligned but rather that the transfer is too small. > > >> >> > > > >> >> > When the MMC core transfers the SCR, it requests 8 bytes. The > > >> >> > buffer used to store these 8 bytes is properly allocated. However, > > >> >> > those 8 bytes eventually end up as the size of the range that is > > >> >> > to be invalidated. This is the reason for the warning. Address x > > >> >> > of the buffer is cache-line aligned, but x + 8 is never properly > > >> >> > aligned and therefore the code complains. > > >> >> > > >> >> Would it be too dreadful to define a minimum MMC transfer size, and > > >> >> set that to the cache line size? > > >> > > > >> > I did try setting the data size to the cache line size back then, but > > >> > that resulted in an error. After that I gave up. I think what we > > >> > really need to do is separate the invalidation size from the transfer > > >> > size in order to properly handle these situations. Or alternatively > > >> > pass an additional buffer size so the code knows how much needs to be > > >> > invalidated. AFAICT this is the only location where this actually > > >> > happens. All other transfers are
Re: [U-Boot] [PATCH v2 5/8] FAT: Fix file contents listed as directory
On Mon, Sep 03, 2012 at 04:08:02PM +0200, Beno??t Th??baudeau wrote: > Dear Wolfgang Denk, > > On Sunday, September 2, 2012 5:21:15 PM, Wolfgang Denk wrote: > > Dear Beno??t Th??baudeau, > > > > In message > > <2017658963.332562.1342790429735.javamail.r...@advansee.com> you > > wrote: > > > With: > > > fatls mmc 0 /dir/file > > > dir: regular directory > > > file: regular file > > > > > > The previous code read the contents of file as if it were directory > > > entries to > > > list. This patch refuses to list file contents as if it were a > > > folder. > > > > But this means that "fatls" on a plain file stops working? > > > > This doesn't make sense to me. Or what am I missing? > > This already did not work before, because "fatls" is supposed to support only > directories: > > $ help fatls > fatls - list files in a directory (default /) > > Usage: > fatls [directory] > - list files from 'dev' on 'interface' in a 'directory' Note that ext2ls _also_ fails to ls files so we're being consistent as I believe Wolfgang was expecting that *ls of a file would work like real ls does, but that's not the case. Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, 1/3] dm: sparc: net: Fixup greth compile warnings
On Fri, Jul 27, 2012 at 08:04:32AM -, Marek Vasut wrote: > greth.c: In function ???greth_recv???: > greth.c:507:3: warning: format ???%lx??? expects argument of type ???long > unsigned int???, but argument 2 has type ???unsigned int??? [-Wformat] > greth.c:507:3: warning: format ???%lx??? expects argument of type ???long > unsigned int???, but argument 3 has type ???unsigned int??? [-Wformat] > greth.c:541:6: warning: pointer targets in assignment differ in signedness > [-Wpointer-sign] > greth.c: In function ???greth_initialize???: > greth.c:623:2: warning: format ???%lx??? expects argument of type ???long > unsigned int???, but argument 2 has type ???struct greth_regs *??? [-Wformat] > greth.c:655:3: warning: format ???%x??? expects argument of type ???unsigned > int???, but argument 2 has type ???struct greth_regs *??? [-Wformat] > greth.c:684:2: warning: format ???%x??? expects argument of type ???unsigned > int???, but argument 2 has type ???struct greth_regs *??? [-Wformat] > > Signed-off-by: Marek Vasut > Cc: Joe Hershberger > Cc: Daniel Hellstrom > Cc: u-boot...@lists.denx.de Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] P4080/esdhc: make the P4080 ESDHC13 errata workaround conditional
P4080 Rev3.0 fixes ESDHC13 errata, so update the code to make the
workaround conditional.
In formal release document, the errata number should be ESDHC13 instead
of ESDHC136.
Signed-off-by: Roy Zang
---
for sdk1.3. fix defect ENGR180745
arch/powerpc/cpu/mpc85xx/cmd_errata.c |5 +++--
arch/powerpc/cpu/mpc85xx/cpu_init.c | 10 ++
arch/powerpc/include/asm/config_mpc85xx.h |2 +-
3 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/cpu/mpc85xx/cmd_errata.c
b/arch/powerpc/cpu/mpc85xx/cmd_errata.c
index 38e23c8..acc3b83 100644
--- a/arch/powerpc/cpu/mpc85xx/cmd_errata.c
+++ b/arch/powerpc/cpu/mpc85xx/cmd_errata.c
@@ -79,8 +79,9 @@ static int do_errata(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
#if defined(CONFIG_SYS_FSL_ERRATUM_ESDHC135)
puts("Work-around for Erratum ESDHC135 enabled\n");
#endif
-#if defined(CONFIG_SYS_FSL_ERRATUM_ESDHC136)
- puts("Work-around for Erratum ESDHC136 enabled\n");
+#if defined(CONFIG_SYS_FSL_ERRATUM_ESDHC13)
+ if (SVR_MAJ(svr) < 3)
+ puts("Work-around for Erratum ESDHC13 enabled\n");
#endif
#if defined(CONFIG_SYS_FSL_ERRATUM_ESDHC_A001)
puts("Work-around for Erratum ESDHC-A001 enabled\n");
diff --git a/arch/powerpc/cpu/mpc85xx/cpu_init.c
b/arch/powerpc/cpu/mpc85xx/cpu_init.c
index 2397547..fe4b39e 100644
--- a/arch/powerpc/cpu/mpc85xx/cpu_init.c
+++ b/arch/powerpc/cpu/mpc85xx/cpu_init.c
@@ -495,11 +495,13 @@ skip_l2:
setup_mp();
#endif
-#ifdef CONFIG_SYS_FSL_ERRATUM_ESDHC136
+#ifdef CONFIG_SYS_FSL_ERRATUM_ESDHC13
{
- void *p;
- p = (void *)CONFIG_SYS_DCSRBAR + 0x20520;
- setbits_be32(p, 1 << (31 - 14));
+ if (SVR_MAJ(svr) < 3) {
+ void *p;
+ p = (void *)CONFIG_SYS_DCSRBAR + 0x20520;
+ setbits_be32(p, 1 << (31 - 14));
+ }
}
#endif
diff --git a/arch/powerpc/include/asm/config_mpc85xx.h
b/arch/powerpc/include/asm/config_mpc85xx.h
index fab01d5..ddd6557 100644
--- a/arch/powerpc/include/asm/config_mpc85xx.h
+++ b/arch/powerpc/include/asm/config_mpc85xx.h
@@ -387,7 +387,7 @@
#define CONFIG_SYS_FSL_ERRATUM_ELBC_A001
#define CONFIG_SYS_FSL_ERRATUM_ESDHC111
#define CONFIG_SYS_FSL_ERRATUM_ESDHC135
-#define CONFIG_SYS_FSL_ERRATUM_ESDHC136
+#define CONFIG_SYS_FSL_ERRATUM_ESDHC13
#define CONFIG_SYS_P4080_ERRATUM_CPU22
#define CONFIG_SYS_FSL_ERRATUM_NMG_CPU_A011
#define CONFIG_SYS_P4080_ERRATUM_SERDES8
--
1.7.8.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, 2/3] dm: sparc: common: Fixup cmd_bdinfo warnings
On Fri, Jul 27, 2012 at 08:04:33AM -, Marek Vasut wrote: > cmd_bdinfo.c: In function ???do_bdinfo???: > cmd_bdinfo.c:220:9: warning: format ???%lx??? expects argument of type > ???long unsigned int???, but argument 2 has type ???int??? [-Wformat] > cmd_bdinfo.c:222:9: warning: format ???%lx??? expects argument of type > ???long unsigned int???, but argument 2 has type ???int??? [-Wformat] > cmd_bdinfo.c:224:9: warning: format ???%lx??? expects argument of type > ???long unsigned int???, but argument 2 has type ???int??? [-Wformat] > cmd_bdinfo.c:226:9: warning: format ???%lx??? expects argument of type > ???long unsigned int???, but argument 2 has type ???int??? [-Wformat] > cmd_bdinfo.c:228:9: warning: format ???%lx??? expects argument of type > ???long unsigned int???, but argument 2 has type ???int??? [-Wformat] > > Signed-off-by: Marek Vasut > Cc: Daniel Hellstrom > Cc: u-boot...@lists.denx.de Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, 3/3] dm: sparc: Fixup the compile warnings in sparc code
On Fri, Jul 27, 2012 at 08:04:34AM -, Marek Vasut wrote: > Signed-off-by: Marek Vasut > Cc: Daniel Hellstrom > Cc: u-boot...@lists.denx.de Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] spl: remove forced linking of commands into SPL
On Wed, Aug 08, 2012 at 04:24:13PM -, Tyler Olmstead wrote: > Remove linker command line options from the SPL makefile > that force the inclusion of unreferenced command code from > linked object files. As commands are not used in the SPL, > these options resulted in an unnecessary increase in the > image size, in addition to introducing the possibility of > tricky link errors in the case where the command code > contained symbols that were not resolved by linking in the > limited objects compiled in the SPL build. > > Signed-off-by: Tyler Olmstead > Acked-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, 1/5] fw_env: Add env vars describing U-Boot target board
On Fri, Aug 10, 2012 at 07:45:15AM -, Beno?t Th?baudeau wrote: > Commit 5e724ca did the same thing for env_common and env_embedded, but forgot > fw_env. > > Signed-off-by: Beno?t Th?baudeau > Cc: Wolfgang Denk Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot,2/5] env_common: Add missing ethprime
On Fri, Aug 10, 2012 at 07:45:31AM -, Beno?t Th?baudeau wrote: > The ethprime env var was missing from env_common. > > Signed-off-by: Beno?t Th?baudeau > Cc: Wolfgang Denk Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, 3/5] env import/export: Remove from help if disabled
On Fri, Aug 10, 2012 at 07:45:44AM -, Beno?t Th?baudeau wrote: > Signed-off-by: Beno?t Th?baudeau > Cc: Wolfgang Denk > Acked-by: Mike Frysinger Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v4, 1/7] env: cosmetic: drop assignment i = iomux_doenv()
On Fri, Aug 24, 2012 at 12:11:36AM -, Gerlando Falauto wrote: > iomux_doenv() can only return 0 or 1. > So there is no need to save its return value in variable i, as checking > its truth value within an if statement is enough. > > Signed-off-by: Gerlando Falauto > Reviewed-by: Marek Vasut Along with the rest of the series, applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot,1/2,V2] ARM: Remove apollon board
On Wed, Sep 05, 2012 at 05:16:55PM -, Marek Vasut wrote: > This board is the only board that still sticks to OneNAND IPL. > Remove this board, since we have SPL around for a while and > OneNAND is well supported in the SPL framework. The board can > be revived if necessary. > > Signed-off-by: Marek Vasut > Cc: Albert Aribaud > Cc: Kyungmin Park > Cc: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot,2/2] IPL: Remove remains of OneNAND IPL
On Wed, Sep 05, 2012 at 05:09:08PM -, Marek Vasut wrote: > After removing the Apollon board, remove the OneNAND IPL too. > There are no users for it any more. > > Signed-off-by: Marek Vasut > Cc: Albert Aribaud > Cc: Minkyu Kang > Cc: Tom Rini > Acked-by: Minkyu Kang Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] env_nand: fix incorrect size parameter to ALLOC_CACHE_ALIGN_BUFFER
On Fri, Sep 07, 2012 at 09:15:33AM -, Stephen Warren wrote: > From: Stephen Warren > > The third parameter to ALLOC_CACHE_ALIGN_BUFFER is not size (as named), > but rather count (number of elements of the type to allocate). The > current code ends up allocating one copy of env_t for each byte in its > size, which quite possibly ends up overflowing RAM. > > This fixes a bug in commit 3801a15 "env_nand: align NAND buffers". > > Reported-by: Prabhakar Lad > Signed-off-by: Stephen Warren > Reported-by: Prabhakar Lad Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Subject: [PATCH] Fix for bug in memory sizing code
On Sun, Sep 09, 2012 at 08:16:58PM -, Iwo Mergler wrote: > The original memory sizing code in get_ram_size clobbers the word > at the base address, but forgets to restore it. > > Signed-off-by: Iwo Mergler Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] env_nand: fix incorrect size parameter to ALLOC_CACHE_ALIGN_BUFFER
On Fri, Sep 07, 2012 at 09:15:33AM -, Stephen Warren wrote: > From: Stephen Warren > > The third parameter to ALLOC_CACHE_ALIGN_BUFFER is not size (as named), > but rather count (number of elements of the type to allocate). The > current code ends up allocating one copy of env_t for each byte in its > size, which quite possibly ends up overflowing RAM. > > This fixes a bug in commit 3801a15 "env_nand: align NAND buffers". > > Reported-by: Prabhakar Lad > Signed-off-by: Stephen Warren > Reported-by: Prabhakar Lad Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
