Re: [U-Boot] [PATCH 03/71] serial: Properly spell out the structure member names of serial_driver
On 09/17/2012 01:20 AM, Marek Vasut wrote: Properly spell out the whole structure member names when an initialized varible is instantiated from the struct serial_driver. In case the structure definition for struct serial_driver undergoes reordering, there will be no impact on variables defined based on this structure. Signed-off-by: Marek Vasut ma...@denx.de Cc: Marek Vasut marek.va...@gmail.com Cc: Tom Rini tr...@ti.com Cc: Anatolij Gustschin ag...@denx.de Cc: Stefan Roese s...@denx.de Cc: Mike Frysinger vap...@gentoo.org Cc: C Nauman cnau...@diagraph.com Cc: Minkyu Kang mk7.k...@samsung.com Cc: Michal Simek mon...@monstr.eu --- arch/powerpc/cpu/mpc512x/serial.c | 18 +- arch/powerpc/cpu/mpc5xxx/serial.c | 32 arch/powerpc/cpu/mpc8xx/serial.c | 32 board/logicpd/zoom2/zoom2_serial.h | 16 drivers/serial/serial.c| 19 ++- drivers/serial/serial_pxa.c| 16 drivers/serial/serial_s3c24x0.c| 18 +- drivers/serial/serial_s5p.c| 19 ++- drivers/serial/serial_xuartlite.c | 19 ++- 9 files changed, 96 insertions(+), 93 deletions(-) Uartlite part looks good to me. Acked-by: Michal Simek mon...@monstr.eu Thanks, Michal -- Michal Simek, Ing. (M.Eng) w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/ Microblaze U-BOOT custodian ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 13/71] serial: microblaze: Move serial registration from serial_initialize()
On 09/17/2012 01:20 AM, Marek Vasut wrote:
Move the registration of xuartlite_serialN_device ports from
default serial_initialize() into driver specific function called from
serial_initialize(). This slims down the serial_initialize() call
to a bare tracker of all possible serial port registration routines
in U-Boot.
The newly implemented xuartlite_serial_initialize() function, which is
implemented inside of the serial_xuartlite driver allows encapsulation
of xuartlite_serialN_device within the serial_xuartlite driver itself.
Also, remove the exports of xuartlite_serialN_device from include/serial.h
as they are no longer needed. This is simply because the implementation of
default_serial_console() is wrapped into the serial_xuartlite driver and
the default console is picked by CONFIG_SERIALN macro in config file.
Signed-off-by: Marek Vasut ma...@denx.de
Cc: Marek Vasut marek.va...@gmail.com
Cc: Tom Rini tr...@ti.com
Cc: Michal Simek mon...@monstr.eu
---
common/serial.c | 16 ++--
drivers/serial/serial_xuartlite.c | 16
include/serial.h |7 ---
3 files changed, 18 insertions(+), 21 deletions(-)
diff --git a/common/serial.c b/common/serial.c
index c021c3f..e19a17f 100644
--- a/common/serial.c
+++ b/common/serial.c
@@ -44,6 +44,7 @@ serial_initfunc(mpc8xx_serial_initialize);
serial_initfunc(pxa_serial_initialize);
serial_initfunc(s3c24xx_serial_initialize);
serial_initfunc(s5p_serial_initialize);
+serial_initfunc(uartlite_serial_initialize);
void serial_register(struct serial_device *dev)
{
@@ -97,20 +98,7 @@ void serial_initialize(void)
#if defined(CONFIG_SYS_BFIN_UART)
serial_register_bfin_uart();
#endif
-#if defined(CONFIG_XILINX_UARTLITE)
-# ifdef XILINX_UARTLITE_BASEADDR
- serial_register(uartlite_serial0_device);
-# endif /* XILINX_UARTLITE_BASEADDR */
-# ifdef XILINX_UARTLITE_BASEADDR1
- serial_register(uartlite_serial1_device);
-# endif /* XILINX_UARTLITE_BASEADDR1 */
-# ifdef XILINX_UARTLITE_BASEADDR2
- serial_register(uartlite_serial2_device);
-# endif /* XILINX_UARTLITE_BASEADDR2 */
-# ifdef XILINX_UARTLITE_BASEADDR3
- serial_register(uartlite_serial3_device);
-# endif /* XILINX_UARTLITE_BASEADDR3 */
-#endif /* CONFIG_XILINX_UARTLITE */
+ uartlite_serial_initialize();
serial_assign(default_serial_console()-name);
}
diff --git a/drivers/serial/serial_xuartlite.c
b/drivers/serial/serial_xuartlite.c
index 2b869c1..d90c42d 100644
--- a/drivers/serial/serial_xuartlite.c
+++ b/drivers/serial/serial_xuartlite.c
@@ -177,4 +177,20 @@ __weak struct serial_device *default_serial_console(void)
return uartlite_serial3_device;
# endif /* XILINX_UARTLITE_BASEADDR3 */
}
+
+void uartlite_serial_initialize(void)
+{
+#ifdef XILINX_UARTLITE_BASEADDR
+ serial_register(uartlite_serial0_device);
+#endif /* XILINX_UARTLITE_BASEADDR */
+#ifdef XILINX_UARTLITE_BASEADDR1
+ serial_register(uartlite_serial1_device);
+#endif /* XILINX_UARTLITE_BASEADDR1 */
+#ifdef XILINX_UARTLITE_BASEADDR2
+ serial_register(uartlite_serial2_device);
+#endif /* XILINX_UARTLITE_BASEADDR2 */
+#ifdef XILINX_UARTLITE_BASEADDR3
+ serial_register(uartlite_serial3_device);
+#endif /* XILINX_UARTLITE_BASEADDR3 */
+}
#endif /* CONFIG_SERIAL_MULTI */
diff --git a/include/serial.h b/include/serial.h
index 08a9287..73991a6 100644
--- a/include/serial.h
+++ b/include/serial.h
@@ -49,13 +49,6 @@ extern struct serial_device serial4_device;
extern struct serial_device serial6_device;
#endif
-#if defined(CONFIG_XILINX_UARTLITE)
-extern struct serial_device uartlite_serial0_device;
-extern struct serial_device uartlite_serial1_device;
-extern struct serial_device uartlite_serial2_device;
-extern struct serial_device uartlite_serial3_device;
-#endif
-
#if defined(CONFIG_OMAP3_ZOOM2)
extern struct serial_device zoom2_serial_device0;
extern struct serial_device zoom2_serial_device1;
Acked-by: Michal Simek mon...@monstr.eu
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Exynos5250: Enable PXE Support
ping On 5 September 2012 16:08, Chander Kashyap chander.kash...@linaro.org wrote: Add PXE support for the Exynos5250. Signed-off-by: Chander Kashyap chander.kash...@linaro.org --- include/configs/smdk5250.h |6 ++ 1 file changed, 6 insertions(+) diff --git a/include/configs/smdk5250.h b/include/configs/smdk5250.h index 27dab76..2029ad3 100644 --- a/include/configs/smdk5250.h +++ b/include/configs/smdk5250.h @@ -216,6 +216,12 @@ #define CONFIG_ENV_SROM_BANK 1 #endif /*CONFIG_CMD_NET*/ +/* Enable PXE Support */ +#ifdef CONFIG_CMD_NET +#define CONFIG_CMD_PXE +#define CONFIG_MENU +#endif + /* Enable devicetree support */ #define CONFIG_OF_LIBFDT -- 1.7.9.5 -- with warm regards, Chander Kashyap ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[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 tmshl...@gmail.com
---
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 fdtdec.h
#include post.h
#include logbuff.h
+#include dmmalloc.h
#ifdef CONFIG_BITBANGMII
#include miiphy.h
@@ -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 stdio_dev.h
#include version.h
#include net.h
+#include dmmalloc.h
#ifdef CONFIG_BITBANGMII
#include miiphy.h
@@ -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
[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 puneet.sha...@moschip.com 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 eric.nel...@boundarydevices.com
---
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 micrel.h
#include miiphy.h
#include netdev.h
+#include linux/fb.h
+#include ipu_pixfmt.h
+#include asm/arch/crm_regs.h
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 |= (3MXC_CCM_CS2CDR_LDB_DI0_CLK_SEL_OFFSET)
+ |(3MXC_CCM_CS2CDR_LDB_DI1_CLK_SEL_OFFSET);
+ 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
+ MXC_CCM_CHSCCDR_IPU1_DI0_CLK_SEL_OFFSET)
+ |(CHSCCDR_PODF_DIVIDE_BY_3
+
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 fabio.este...@freescale.com --- 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 linux/linkage.h - -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 puneet.sha...@moschip.com 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 benoit.thebaud...@advansee.com Cc: Scott Wood scottw...@freescale.com Cc: Stefano Babic sba...@denx.de --- 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 ilya.ya...@cogentembedded.com --- 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 ilya.ya...@gmail.com + * + * See file CREDITS for list of people who contributed to this + * project. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of + * the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc. + */ +#include common.h +#include net.h +#include asm/omap_common.h + +DECLARE_GLOBAL_DATA_PTR; +
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 tr...@ti.com 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 common.h +#ifdef CONFIG_SPL_BUILD +#undef
CONFIG_CMD_TFTPPUT +#undef CONFIG_CMD_TFTPSRV +#endif #include
command.h #include net.h #include tftp.h
Missed this.
Yes, sorry.
Also I saw a few manual inclusions of config_uncmd_spl.h, 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 tmshl...@gmail.com
---
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 common.h /* for ROUND_UP */
+#include asm/u-boot.h
+#include asm/global_data.h /* for gd_t and gd */
+#include asm/types.h /* for phys_addr_t and size_addt_t */
+
+#include dmmalloc.h
+#include malloc.h
+
+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 linux/compiler.h):
__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 dirk.be...@de.bosch.com 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/vendor/board_name/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 Vasutma...@denx.de 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 Nelsoneric.nel...@boundarydevices.com
---
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 @@
#includemicrel.h
#includemiiphy.h
#includenetdev.h
+#includelinux/fb.h
+#includeipu_pixfmt.h
+#includeasm/arch/crm_regs.h
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 |= (3MXC_CCM_CS2CDR_LDB_DI0_CLK_SEL_OFFSET)
+ |(3MXC_CCM_CS2CDR_LDB_DI1_CLK_SEL_OFFSET);
+ 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);
+
Re: [U-Boot] [PATCH] mx51evk: Add CONFIG_REVISION_TAG
Hi Greg,
On Tue, Sep 18, 2012 at 10:00 AM, Greg Topmiller
greg.topmil...@jdsu.com 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
benoit.thebaud...@advansee.com 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 Vasutma...@denx.de 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 benoit.thebaud...@advansee.com 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 benoit.thebaud...@advansee.com 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=MCIMX51EVKJparentCode=i.MX515fpsp=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 benoit.thebaud...@advansee.com 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=MCIMX51EVKJparentCode=i.MX515fpsp=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
eric.nel...@boundarydevices.com 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 feste...@gmail.com 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 Vasutma...@denx.de 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
greg.topmil...@jdsu.com 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
benoit.thebaud...@advansee.com 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 greg.topmil...@jdsu.com
Signed-off-by: Benoît Thébaudeau benoit.thebaud...@advansee.com
Cc: Stefano Babic sba...@denx.de
Cc: Fabio Estevam feste...@gmail.com
---
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 thierry.red...@avionic-design.de 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 thierry.red...@avionic-design.de 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 ma...@denx.de 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 only warning that I've seen. I guess a new member could be added to the struct mmc_data. Alternatively maybe an extra flag would be better, something like MMC_DATA_CACHE_ALIGNED. It could be passed anywhere where it is known that the buffer is properly sized but not a full cache line is transferred. Thierry pgp6TcN6pZpZV.pgp Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
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 benoit.thebaud...@advansee.com 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 greg.topmil...@jdsu.com Signed-off-by: Benoît Thébaudeau benoit.thebaud...@advansee.com Cc: Stefano Babic sba...@denx.de Cc: Fabio Estevam feste...@gmail.com Acked-by: Fabio Estevam fabio.este...@freescale.com ___ 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
benoit.thebaud...@advansee.com 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] 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 ma...@denx.de
Cc: Marek Vasut marek.va...@gmail.com
Cc: Tom Rini tr...@ti.com
---
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 post.h
#include linux/compiler.h
+/* 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 fabio.este...@freescale.com
---
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
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 ma...@denx.de
Cc: Marek Vasut marek.va...@gmail.com
Cc: Tom Rini tr...@ti.com
---
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 post.h
#include linux/compiler.h
+/* 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 jose.goncal...@inov.pt
---
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 jose.goncal...@inov.pt --- 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 jose.goncal...@inov.pt
---
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 jose.goncal...@inov.pt
---
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 jose.goncal...@inov.pt
---
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 jose.goncal...@inov.pt
---
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 jose.goncal...@inov.pt
---
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, ga...@denx.de
*
+ * (C) Copyright 2012 INOV - INESC Inovacao
+ * Jose Goncalves jose.goncal...@inov.pt
+ *
* 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 asm/io.h
@@ -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 jose.goncal...@inov.pt
---
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 jose.goncal...@inov.pt
---
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 jose.goncal...@inov.pt
+ *
+ * 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 common.h
+#include nand.h
+#include asm/io.h
+#include asm/errno.h
+#include asm/arch/s3c24xx_cpu.h
+
+#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.
[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 jose.goncal...@inov.pt --- 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 fabio.este...@freescale.com mx53ard i.MX53 mx53smd i.MX53 +José Gonçalves jose.goncal...@inov.pt + + mini2416ARM926EJS (S3C2416 SoC) + Daniel Gorsulowski daniel.gorsulow...@esd.eu 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 jose.goncal...@inov.pt +# +# 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 jose.goncal...@inov.pt + * + * 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
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 ma...@denx.de
Cc: Marek Vasut marek.va...@gmail.com
Cc: Tom Rini tr...@ti.com
---
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 post.h
#include linux/compiler.h
+/* 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 ma...@denx.de Cc: Marek Vasut
marek.va...@gmail.com Cc: Tom Rini tr...@ti.com ---
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 post.h #include linux/compiler.h
+/* 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 ma...@denx.de Cc: Marek Vasut
marek.va...@gmail.com Cc: Tom Rini tr...@ti.com ---
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 post.h #include linux/compiler.h
+/* 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 jose.goncal...@inov.pt
---
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 jose.goncal...@inov.pt
+ *
+ * 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 common.h
+#include nand.h
+#include asm/io.h
+#include asm/errno.h
+#include asm/arch/s3c24xx_cpu.h
+
+#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
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 ma...@denx.de
Cc: Marek Vasut marek.va...@gmail.com
Cc: Tom Rini tr...@ti.com
---
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 post.h
#include linux/compiler.h
+/* 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 swar...@nvidia.com
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 uma.shan...@samsung.com
Cc: Manjunatha C Achar a.manjuna...@samsung.com
Cc: Iqbal Shareef iqbal@samsung.com
Cc: Hakgoo Lee goodguy@samsung.com
Cc: Wolfgang Denk w...@denx.de
Cc: Tom Rini tr...@ti.com
Signed-off-by: Stephen Warren swar...@nvidia.com
---
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 iwama...@nigauri.org 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 ma...@denx.de Cc: Marek Vasut
marek.va...@gmail.com Cc: Tom Rini tr...@ti.com ---
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 post.h #include linux/compiler.h
+/* 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 benoit.thebaud...@advansee.com
Cc: Tom Rini tr...@ti.com
Cc: Wolfgang Denk w...@denx.de
---
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 interface dev[:part]
- addr filename [bytes]\n);
+ addr filename [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,
- interface dev[:part] addr filename [bytes]\n
- - load binary file 'filename' from 'dev' on 'interface'\n
- to address 'addr' from dos filesystem
+ interface dev[:part] addr filename [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 */
Re: [U-Boot] [PATCH 1/2] patman: Use reverse order for changelog
On Sat, Aug 18, 2012 at 10:46 AM, Otavio Salvador ota...@ossystems.com.br 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 ota...@ossystems.com.br Acked-by: Simon Glass s...@chromium.org --- 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 benoit.thebaud...@advansee.com Cc: Scott Wood scottw...@freescale.com Cc: Stefano Babic sba...@denx.de --- 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 jose.goncal...@inov.pt
---
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 jose.goncal...@inov.pt
+ *
+ * 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 common.h
+#include nand.h
+#include asm/io.h
+#include asm/errno.h
+#include asm/arch/s3c24xx_cpu.h
+
+#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,
Re: [U-Boot] Cache alignment warnings on Tegra (ARM)
Hi Thierry, On Tue, Sep 18, 2012 at 7:54 AM, Thierry Reding thierry.red...@avionic-design.de 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 thierry.red...@avionic-design.de 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 thierry.red...@avionic-design.de 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 ma...@denx.de 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 only warning that I've seen. I guess a new member could be added to the struct mmc_data. Alternatively maybe an extra flag would be better, something like MMC_DATA_CACHE_ALIGNED. It could be passed anywhere where it is known that the buffer is properly sized but not a full cache line is transferred. Yes a flag sounds reasonable. Some will argue that this is messing with low-level hardware features in a driver, but really it is just a hint that no bounce buffer is needed. The driver is free to do what it likes. Regards,
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 ma...@denx.de Cc: Marek Vasut
marek.va...@gmail.com Cc: Tom Rini tr...@ti.com ---
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 post.h #include linux/compiler.h
+/* 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 ma...@denx.de
Cc: Marek Vasut marek.va...@gmail.com
Cc: Tom Rini tr...@ti.com
---
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 post.h
#include linux/compiler.h
+/* 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 ma...@denx.de Cc: Marek
Vasut marek.va...@gmail.com Cc: Tom Rini
tr...@ti.com ---
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 post.h #include linux/compiler.h
+/* 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 ma...@denx.de
Cc: Marek Vasut marek.va...@gmail.com
Cc: Tom Rini tr...@ti.com
---
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 post.h
#include linux/compiler.h
+/* 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 thierry.red...@avionic-design.de 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 thierry.red...@avionic-design.de 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 thierry.red...@avionic-design.de 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 ma...@denx.de 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 only warning that I've seen. I guess a new member could be added to the struct mmc_data. Alternatively maybe an extra flag would be better, something like MMC_DATA_CACHE_ALIGNED. It could be passed anywhere where it is known that the buffer is properly sized but not a full cache line is transferred. Yes a flag sounds reasonable. Some will argue that this is messing with low-level hardware features in a driver, but really it is just a hint that no
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/nand/nand_spl_simple.c calls
board_nand_init() with a
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 thierry.red...@avionic-design.de 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 thierry.red...@avionic-design.de 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 thierry.red...@avionic-design.de 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 ma...@denx.de 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 only warning that I've seen. I guess a new member could be added to the struct mmc_data. Alternatively maybe an extra flag would be better, something like MMC_DATA_CACHE_ALIGNED. It could be passed anywhere where it is known that the buffer is properly sized but not a full cache
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 interface dev[:part] [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 ma...@denx.de Cc: Joe Hershberger joe.hershber...@gmail.com Cc: Daniel Hellstrom dan...@gaisler.com 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 tie-fei.z...@freescale.com
---
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 ma...@denx.de Cc: Daniel Hellstrom dan...@gaisler.com 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 ma...@denx.de Cc: Daniel Hellstrom dan...@gaisler.com 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 tyler.j.olmst...@gmail.com Acked-by: Tom Rini tr...@ti.com 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 benoit.thebaud...@advansee.com Cc: Wolfgang Denk w...@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,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 benoit.thebaud...@advansee.com Cc: Wolfgang Denk w...@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/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 benoit.thebaud...@advansee.com Cc: Wolfgang Denk w...@denx.de Acked-by: Mike Frysinger vap...@gentoo.org 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 gerlando.fala...@keymile.com Reviewed-by: Marek Vasut ma...@denx.de 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 ma...@denx.de Cc: Albert Aribaud albert.u.b...@aribaud.net Cc: Kyungmin Park kyungmin.p...@samsung.com Cc: Tom Rini tr...@ti.com 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 ma...@denx.de Cc: Albert Aribaud albert.u.b...@aribaud.net Cc: Minkyu Kang proms...@gmail.com Cc: Tom Rini tr...@ti.com Acked-by: Minkyu Kang mk7.k...@samsung.com 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 swar...@nvidia.com 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 prabhakar.cse...@gmail.com Signed-off-by: Stephen Warren swar...@nvidia.com Reported-by: Prabhakar Lad prabhakar@ti.com 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
