Re: [U-Boot] [PATCH v4] arm:exynos4:samsung:nuri Support for NURI target.

[Lukasz Majewski]

Hello Marek,

Thanks for your feedback,

> > +   ldr r0, =0x1015
> > +   mov r1, #0x0
> > +   str r1, [r0]
> > +   mov r1, #0xff
> > +   str r1, [r0, #0x0804]
> > +   str r1, [r0, #0x0810]
> > +   str r1, [r0, #0x081C]
> > +   str r1, [r0, #0x0828]
> > +
> > +   mov pc, lr  
> 
> Why not use arch_cpu_init for all this. Or even better, put the uart
> init into uart driver etc .. ?

Hmm... good point.

This low level code is common for some Samsung boards (Origen, Nuri,
Universal_C210) and shall be put to ./board/samsung/lowlevel_init/
directory and be included to all those boards.

Another question is switching to FDT framework, which we will face
sooner than later. 

Those boards are also good candidates for FDT, but I don't have an idea
when would be a good moment for this switch.


> > +int dram_init(void)
> > +{
> > +   gd->ram_size = \
> > +   get_ram_size((long *)PHYS_SDRAM_1,
> > PHYS_SDRAM_1_SIZE) +
> > +   get_ram_size((long *)PHYS_SDRAM_2,
> > PHYS_SDRAM_2_SIZE) +
> > +   get_ram_size((long *)PHYS_SDRAM_3,
> > PHYS_SDRAM_3_SIZE) +
> > +   get_ram_size((long *)PHYS_SDRAM_4,
> > PHYS_SDRAM_4_SIZE); +
> > +   return 0;
> > +}
> > +
> > +void dram_init_banksize(void)
> > +{
> > +   gd->bd->bi_dram[0].start = PHYS_SDRAM_1;
> > +   gd->bd->bi_dram[0].size = get_ram_size((long
> > *)PHYS_SDRAM_1, \
> > +
> > PHYS_SDRAM_1_SIZE); +
> > +   gd->bd->bi_dram[1].start = PHYS_SDRAM_2;
> > +   gd->bd->bi_dram[1].size = get_ram_size((long
> > *)PHYS_SDRAM_2, \
> > +
> > PHYS_SDRAM_2_SIZE); +
> > +   gd->bd->bi_dram[2].start = PHYS_SDRAM_3;
> > +   gd->bd->bi_dram[2].size = get_ram_size((long
> > *)PHYS_SDRAM_3, \
> > +
> > PHYS_SDRAM_3_SIZE); +
> > +   gd->bd->bi_dram[3].start = PHYS_SDRAM_4;
> > +   gd->bd->bi_dram[3].size = get_ram_size((long
> > *)PHYS_SDRAM_4, \
> > +
> > PHYS_SDRAM_4_SIZE); +}
> 
> The board has discontiguous memory ?

Why do you think so? The board has four banks starting from 0x4000.

Those definitely form a continuous memory.
 

-- 
Best regards,

Lukasz Majewski

Samsung Poland R&D Center
Platform Group
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V2 3/6] i.mx: mxc_gpio: add the i.mx6q support

[Jason Hui]

2011/11/18 Lv Terry-R65388 :
> Hi Jason,
>
>        What about using
>
> #ifdef GPIO4_BASE_ADDR
>        [3] = GPIO4_BASE_ADDR,
> #endif
[...]

>
>        Then we can avoid adding SOC compile options in future.
>

Terry, please don't top-post. As for your comments, I don't think so,
first, we should not simply use GPIOx_BASE_ADDR, and second,
it will introduce a lot of other platforms changes.

Jason Liu

> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] checkpatch compliance

[Gerlando Falauto]

On 11/17/2011 09:54 PM, Wolfgang Denk wrote:

Dear Gerlando Falauto,

In message<4ec56a2e.2000...@keymile.com>  you wrote:


What is wrong with something like:

ERROR: do not initialise statics to 0 or NULL
#35: FILE: serial.c:32:
+static struct serial_device *serial_devices = NULL;

>

Why?  Why don't you just follow the advise and remove the redundant
initializers?


Sorry, I didn't realize it had to do with redundancy, the message was 
somewhat unclear to me.
I thought the complaint meant something like "you should initialize 
statics somewhere else", which, in fact, would not make any sense, in 
ANY context.


I personally would prefer an explicit initialization though, like mama 
told me to ALWAYS do... wash your hands before you eat, brush your teeth 
after. (I also like to believe I'm not the only one who had never read 
ISO/IEC 9899 §6.7.8#2). :-)


Thanks,
Gerlando Falauto
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH V2 5/6] i.mx: fsl_esdhc: add the i.mx6q support

[Jason Liu]

The mmc host controller on the i.mx6q is called usdhc which
is redesigned based on the freescale esdhc controller.

The usdhc controller is almost compatible with esdhc except
it adds one mix register to support debug/SD3.0 and move
the low bit 0-6 of XFERTYP register to the mix control reg
low bit 0-6. Thus on i.mx6q, we have the following compared
with the previous soc: (can refer to RM of chapter 56.3.3)

i.mx6q:
mix control:
bit 31 - bit 7: Added for debug/SD3.0 support
bit 6  - bit 0: move in the XFERTYP register bit 6-0 on previous soc
XFERTYP register:
bit 31 - bit 7: the same as before,
bit 6  - bit 0: no-use

previous soc
mix control: no
XFERTYP register:
bit 31 - bit 0: xfertype information

Signed-off-by: Jason Liu 
CC:Stefano Babic 
Acked-by: Stefano Babic 
---
v2: extend the commit message by adding mix/xtertype register change
remove one #ifdef as Marek suggested
change the print of USDHC/ESDHC to SDHC
---
 drivers/mmc/fsl_esdhc.c |   12 +---
 1 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
index ec953f0..ddd1b4c 100644
--- a/drivers/mmc/fsl_esdhc.c
+++ b/drivers/mmc/fsl_esdhc.c
@@ -58,7 +58,8 @@ struct fsl_esdhc {
uintautoc12err;
uinthostcapblt;
uintwml;
-   charreserved1[8];
+   uintmixctrl;
+   charreserved1[4];
uintfevt;
charreserved2[168];
uinthostver;
@@ -298,8 +299,13 @@ esdhc_send_cmd(struct mmc *mmc, struct mmc_cmd *cmd, 
struct mmc_data *data)
 
/* Send the command */
esdhc_write32(®s->cmdarg, cmd->cmdarg);
+#if defined(CONFIG_FSL_USDHC)
+   esdhc_write32(®s->mixctrl,
+   (esdhc_read32(®s->mixctrl) & 0xFF80) | (xfertyp & 0x7F));
+   esdhc_write32(®s->xfertyp, xfertyp & 0x);
+#else
esdhc_write32(®s->xfertyp, xfertyp);
-
+#endif
/* Wait for the command to complete */
while (!(esdhc_read32(®s->irqstat) & IRQSTAT_CC))
;
@@ -482,7 +488,7 @@ int fsl_esdhc_initialize(bd_t *bis, struct fsl_esdhc_cfg 
*cfg)
 
mmc = malloc(sizeof(struct mmc));
 
-   sprintf(mmc->name, "FSL_ESDHC");
+   sprintf(mmc->name, "FSL_SDHC");
regs = (struct fsl_esdhc *)cfg->esdhc_base;
 
/* First reset the eSDHC controller */
-- 
1.7.4.1


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH V2 6/6] i.mx: i.mx6q: add the initial support for i.mx6q ARM2 board

[Jason Liu]

Add the initial support for Freescale i.MX6Q Armadillo2 board
Support: MMC boot from slot 0/1, debug UART(UART4), usdhc.

There is two MMC slots on the boards:
mmc dev 0 -> connect USDHC3 -> the lower slot on the board,
mmc dev 1 -> connect USDHC4 -> the upper slot on the board,

Signed-off-by: Jason Liu 
Cc: Stefano Babic 
Tested-by: Dirk Behme 
---
v2:fix sd3 card detection GPIO
   remove unneeded parentheses such as (IRAM_SIZE)
   remove clean and distclean targets in Makefile
   remove CONFIG_MACH_TYPE setup since linux use DT
   some cleanup/improvement for the config file from Dirk
   remove imx_iomux_v3_init call since assign the base in iomux-v3.c
   improve the commit message to add the mmc slot description
---
 MAINTAINERS   |1 +
 board/freescale/mx6qarm2/Makefile |   42 
 board/freescale/mx6qarm2/imximage.cfg |  167 +
 board/freescale/mx6qarm2/mx6qarm2.c   |  155 ++
 boards.cfg|1 +
 include/configs/mx6qarm2.h|  162 
 6 files changed, 528 insertions(+), 0 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 030fe4a..4eab903 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -572,6 +572,7 @@ Jason Liu 
 
mx53evk i.MX53
mx53locoi.MX53
+   mx6qarm2i.MX6Q
 
 Enric Balletbo i Serra 
 
diff --git a/board/freescale/mx6qarm2/Makefile 
b/board/freescale/mx6qarm2/Makefile
new file mode 100644
index 000..79bc315
--- /dev/null
+++ b/board/freescale/mx6qarm2/Makefile
@@ -0,0 +1,42 @@
+#
+# Copyright (C) 2007, Guennadi Liakhovetski 
+#
+# (C) Copyright 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
+#
+
+include $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(BOARD).o
+
+COBJS  := mx6qarm2.o
+
+SRCS   := $(SOBJS:.o=.S) $(COBJS:.o=.c)
+OBJS   := $(addprefix $(obj),$(COBJS))
+SOBJS  := $(addprefix $(obj),$(SOBJS))
+
+$(LIB):$(obj).depend $(OBJS) $(SOBJS)
+   $(call cmd_link_o_target, $(OBJS) $(SOBJS))
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/freescale/mx6qarm2/imximage.cfg 
b/board/freescale/mx6qarm2/imximage.cfg
new file mode 100644
index 000..ffac1b4
--- /dev/null
+++ b/board/freescale/mx6qarm2/imximage.cfg
@@ -0,0 +1,167 @@
+# Copyright (C) 2011 Freescale Semiconductor, Inc.
+# Jason Liu 
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not write to the Free Software
+# Foundation Inc. 51 Franklin Street Fifth Floor Boston,
+# MA 02110-1301 USA
+#
+# Refer docs/README.imxmage for more details about how-to configure
+# and create imximage boot image
+#
+# The syntax is taken as close as possible with the kwbimage
+
+# image version
+
+IMAGE_VERSION 2
+
+# Boot Device : one of
+# spi, sd (the board has no nand neither onenand)
+
+BOOT_FROM  sd
+
+# Device Configuration Data (DCD)
+#
+# Each entry must have the format:
+# Addr-type   AddressValue
+#
+# where:
+#  Addr-type register length (1,2 or 4 bytes)
+#  Address   absolute address of the register
+#  value value to be stored in the register
+DATA 4 0x020e05a8 0x0030
+DATA 4 0x020e05b0 0x0030
+DATA 4 0x020e0524 0x0030
+DATA 4 0x020e051c 0x0030
+
+DATA 4 0x020e0518 0x0030
+DATA 4 0x020e050c 0x0030
+DATA 4 0x020e05b8 0x0030
+DATA 4 0x020e05c0 0x0030
+
+DATA 4 0x020e05ac 0x00020030
+DATA 4 0x020e05b4 0x00020030
+DATA 4 0x020e0528 0x0

[U-Boot] [PATCH V2 4/6] i.mx: serial_mxc: add the i.mx6q support

[Jason Liu]

Signed-off-by: Jason Liu 
Cc: Stefano Babic 
---
v2: Cc Stefano
---
 drivers/serial/serial_mxc.c |   10 +++---
 1 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/serial/serial_mxc.c b/drivers/serial/serial_mxc.c
index dcb4bd1..7d0f288 100644
--- a/drivers/serial/serial_mxc.c
+++ b/drivers/serial/serial_mxc.c
@@ -47,14 +47,18 @@
 #elif defined(CONFIG_SYS_MX27_UART6)
 #define UART_PHYS 0x1001c000
 #elif defined(CONFIG_SYS_MX35_UART1) || defined(CONFIG_SYS_MX51_UART1) || \
-   defined(CONFIG_SYS_MX53_UART1)
+   defined(CONFIG_SYS_MX53_UART1) || defined(CONFIG_MX6Q_UART1)
 #define UART_PHYS UART1_BASE_ADDR
 #elif defined(CONFIG_SYS_MX35_UART2) || defined(CONFIG_SYS_MX51_UART2) || \
-   defined(CONFIG_SYS_MX53_UART2)
+   defined(CONFIG_SYS_MX53_UART2) || defined(CONFIG_MX6Q_UART2)
 #define UART_PHYS UART2_BASE_ADDR
 #elif defined(CONFIG_SYS_MX35_UART3) || defined(CONFIG_SYS_MX51_UART3) || \
-   defined(CONFIG_SYS_MX53_UART3)
+   defined(CONFIG_SYS_MX53_UART3) || defined(CONFIG_MX6Q_UART3)
 #define UART_PHYS UART3_BASE_ADDR
+#elif defined(CONFIG_MX6Q_UART4)
+#define UART_PHYS UART4_BASE_ADDR
+#elif defined(CONFIG_MX6Q_UART5)
+#define UART_PHYS UART5_BASE_ADDR
 #else
 #error "define CONFIG_SYS_MXxx_UARTx to use the MXC UART driver"
 #endif
-- 
1.7.4.1


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH V2 0/6] i.mx: add the initial i.mx6q core/board support

[Jason Liu]

This patch-set add the initial support for freescale i.mx6q support.
freescale i.mx6q is a quad core built on arm cortex_a9 complex.

The patch-set has been tested ok on freescale i.mx6q Armadillo2 board and also
make sure it does not break i.mx5 support

The v1 patch-set has also been tested Ok by: Dirk Behme
Tested-by: Dirk Behme 

Jason Liu (6):
  i.mx: introduce the armv7/imx-common folder
  i.mx: add the initial support for freescale i.MX6Q processor
  i.mx: mxc_gpio: add the i.mx6q support
  i.mx: serial_mxc: add the i.mx6q support
  i.mx: fsl_esdhc: add the i.mx6q support
  i.mx: i.mx6q: add the initial support for i.mx6q ARM2 board
---
v2: see detailed change log in each commit

 MAINTAINERS|1 +
 Makefile   |7 +
 arch/arm/cpu/armv7/imx-common/Makefile |   47 +
 arch/arm/cpu/armv7/imx-common/cpu.c|  108 ++
 arch/arm/cpu/armv7/{mx5 => imx-common}/speed.c |0
 arch/arm/cpu/armv7/{mx5 => imx-common}/timer.c |   17 +-
 arch/arm/cpu/armv7/mx5/Makefile|2 +-
 arch/arm/cpu/armv7/mx5/soc.c   |   77 -
 arch/arm/cpu/armv7/mx6/Makefile|   48 +
 arch/arm/cpu/armv7/mx6/clock.c |  366 +
 arch/arm/cpu/armv7/mx6/iomux-v3.c  |   71 +
 .../cpu/armv7/{mx5/speed.c => mx6/lowlevel_init.S} |   27 +-
 arch/arm/cpu/armv7/mx6/soc.c   |   93 ++
 arch/arm/include/asm/arch-mx6/ccm_regs.h   |  894 +++
 .../mx5/speed.c => include/asm/arch-mx6/clock.h}   |   45 +-
 .../mx5/speed.c => include/asm/arch-mx6/gpio.h}|   30 +-
 arch/arm/include/asm/arch-mx6/imx-regs.h   |  234 +++
 arch/arm/include/asm/arch-mx6/iomux-v3.h   |  103 ++
 arch/arm/include/asm/arch-mx6/mx6x_pins.h  | 1683 
 .../speed.c => include/asm/arch-mx6/sys_proto.h}   |   31 +-
 board/freescale/mx6qarm2/Makefile  |   42 +
 board/freescale/mx6qarm2/imximage.cfg  |  167 ++
 board/freescale/mx6qarm2/mx6qarm2.c|  155 ++
 boards.cfg |1 +
 drivers/gpio/mxc_gpio.c|4 +-
 drivers/mmc/fsl_esdhc.c|   12 +-
 drivers/serial/serial_mxc.c|   10 +-
 include/configs/mx6qarm2.h |  162 ++
 28 files changed, 4268 insertions(+), 169 deletions(-)
 create mode 100644 arch/arm/cpu/armv7/imx-common/Makefile
 create mode 100644 arch/arm/cpu/armv7/imx-common/cpu.c
 copy arch/arm/cpu/armv7/{mx5 => imx-common}/speed.c (100%)
 rename arch/arm/cpu/armv7/{mx5 => imx-common}/timer.c (84%)
 mode change 100644 => 100755
 create mode 100644 arch/arm/cpu/armv7/mx6/Makefile
 create mode 100644 arch/arm/cpu/armv7/mx6/clock.c
 create mode 100644 arch/arm/cpu/armv7/mx6/iomux-v3.c
 copy arch/arm/cpu/armv7/{mx5/speed.c => mx6/lowlevel_init.S} (58%)
 create mode 100644 arch/arm/cpu/armv7/mx6/soc.c
 create mode 100644 arch/arm/include/asm/arch-mx6/ccm_regs.h
 copy arch/arm/{cpu/armv7/mx5/speed.c => include/asm/arch-mx6/clock.h} (59%)
 copy arch/arm/{cpu/armv7/mx5/speed.c => include/asm/arch-mx6/gpio.h} (64%)
 create mode 100644 arch/arm/include/asm/arch-mx6/imx-regs.h
 create mode 100644 arch/arm/include/asm/arch-mx6/iomux-v3.h
 create mode 100644 arch/arm/include/asm/arch-mx6/mx6x_pins.h
 rename arch/arm/{cpu/armv7/mx5/speed.c => include/asm/arch-mx6/sys_proto.h} 
(65%)
 create mode 100644 board/freescale/mx6qarm2/Makefile
 create mode 100644 board/freescale/mx6qarm2/imximage.cfg
 create mode 100644 board/freescale/mx6qarm2/mx6qarm2.c
 create mode 100644 include/configs/mx6qarm2.h

-- 
1.7.4.1


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH V2 3/6] i.mx: mxc_gpio: add the i.mx6q support

[Jason Liu]

Signed-off-by: Jason Liu 
Cc: Stefano Babic 
Acked-by: Stefano Babic 
---
V2: add Stefano's ack
---
 drivers/gpio/mxc_gpio.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpio/mxc_gpio.c b/drivers/gpio/mxc_gpio.c
index a7f36b2..908808d 100644
--- a/drivers/gpio/mxc_gpio.c
+++ b/drivers/gpio/mxc_gpio.c
@@ -40,10 +40,10 @@ static unsigned long gpio_ports[] = {
[0] = GPIO1_BASE_ADDR,
[1] = GPIO2_BASE_ADDR,
[2] = GPIO3_BASE_ADDR,
-#if defined(CONFIG_MX51) || defined(CONFIG_MX53)
+#if defined(CONFIG_MX51) || defined(CONFIG_MX53) || defined(CONFIG_MX6Q)
[3] = GPIO4_BASE_ADDR,
 #endif
-#if defined(CONFIG_MX53)
+#if defined(CONFIG_MX53) || defined(CONFIG_MX6Q)
[4] = GPIO5_BASE_ADDR,
[5] = GPIO6_BASE_ADDR,
[6] = GPIO7_BASE_ADDR,
-- 
1.7.4.1


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH V2 1/6] i.mx: introduce the armv7/imx-common folder

[Jason Liu]

In order to support the coming MX6 platform and to reducde
the duplicated code, we had better move some common files
or functions to the imx-common folder for sharing.

This patch does the following:
- move speed.c file from armv7/mx5/speed.c to armv7/imx-common/speed.c
- move armv7/mx5/timer.c to armv7/imx-common/timer.c, no any new feature
  added but just fix the checkpatch errors in the old file and remove
  the CONFIG_SYS_MX5_CLK32 reference in the file
- create one new file cpu.c file to store the common function with i.mx5/6

Signed-off-by: Jason Liu 
Cc:Stefano Babic 
---
V2:extend the commit message to reflect all the changes in the patch
   rename cpu_info.c to cpu.c file under imx-common as Stefano comments
---
 Makefile   |7 ++
 arch/arm/cpu/armv7/imx-common/Makefile |   47 ++
 arch/arm/cpu/armv7/imx-common/cpu.c|  108 
 arch/arm/cpu/armv7/{mx5 => imx-common}/speed.c |0
 arch/arm/cpu/armv7/{mx5 => imx-common}/timer.c |   17 ++--
 arch/arm/cpu/armv7/mx5/Makefile|2 +-
 arch/arm/cpu/armv7/mx5/soc.c   |   77 -
 7 files changed, 172 insertions(+), 86 deletions(-)

diff --git a/Makefile b/Makefile
index 294c762..9672a10 100644
--- a/Makefile
+++ b/Makefile
@@ -300,6 +300,13 @@ ifeq ($(SOC),omap4)
 LIBS += $(CPUDIR)/omap-common/libomap-common.o
 endif
 
+ifeq ($(SOC),mx5)
+LIBS += $(CPUDIR)/imx-common/libimx-common.o
+endif
+ifeq ($(SOC),mx6)
+LIBS += $(CPUDIR)/imx-common/libimx-common.o
+endif
+
 ifeq ($(SOC),s5pc1xx)
 LIBS += $(CPUDIR)/s5p-common/libs5p-common.o
 endif
diff --git a/arch/arm/cpu/armv7/imx-common/Makefile 
b/arch/arm/cpu/armv7/imx-common/Makefile
new file mode 100644
index 000..e5ff375
--- /dev/null
+++ b/arch/arm/cpu/armv7/imx-common/Makefile
@@ -0,0 +1,47 @@
+#
+# (C) Copyright 2000-2006
+# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+#
+# (C) Copyright 2011 Freescale Semiconductor, Inc.
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+# MA 02111-1307 USA
+#
+
+include $(TOPDIR)/config.mk
+
+LIB = $(obj)libimx-common.o
+
+COBJS  = timer.o cpu.o speed.o
+
+SRCS   := $(SOBJS:.o=.S) $(COBJS:.o=.c)
+OBJS   := $(addprefix $(obj),$(SOBJS) $(COBJS))
+
+all:   $(obj).depend $(LIB)
+
+$(LIB):$(OBJS)
+   $(call cmd_link_o_target, $(OBJS))
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/arch/arm/cpu/armv7/imx-common/cpu.c 
b/arch/arm/cpu/armv7/imx-common/cpu.c
new file mode 100644
index 000..1e30ae5
--- /dev/null
+++ b/arch/arm/cpu/armv7/imx-common/cpu.c
@@ -0,0 +1,108 @@
+/*
+ * (C) Copyright 2007
+ * Sascha Hauer, Pengutronix
+ *
+ * (C) Copyright 2009 Freescale Semiconductor, Inc.
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#ifdef CONFIG_FSL_ESDHC
+#include 
+#endif
+
+static char *get_reset_cause(void)
+{
+   u32 cause;
+   struct src *src_regs = (struct src *)SRC_BASE_ADDR;
+
+   cause = readl(&src_regs->srsr);
+   writel(cause, &src_regs->srsr);
+
+   switch (cause) {
+   case 0x1:
+   return "POR";
+   case 0x4:
+   return "CSU";
+   case 0x8:
+   return "IPP USER";
+   case 0x00

Re: [U-Boot] [PATCH] tegra2: Fix out-of-tree build for Ventana.

[Thierry Reding]

* Mike Frysinger wrote:
> On Thursday 17 November 2011 04:48:22 Thierry Reding wrote:
> > Since Ventana is derived from Seaboard and requires seaboard.c to build,
> > make sure board/nvidia/seaboard is created in the build tree.
> > 
> > --- a/board/nvidia/ventana/Makefile
> > +++ b/board/nvidia/ventana/Makefile
> > 
> >  ifneq ($(OBJTREE),$(SRCTREE))
> > +$(shell mkdir -p $(obj)../seaboard)
> >  $(shell mkdir -p $(obj)../common)
> >  endif
> 
> mkdir takes multiple paths.  thus my proposal:
> -$(shell mkdir -p $(obj)../common)
> +$(shell mkdir -p $(obj)../common $(obj)../seaboard)
> -mike

Heh, right. =)

Thierry


pgp61mEZuqL3s.pgp
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] sbc8548 build broken?

[Wolfgang Denk]

Dear Marek Vasut,

In message <20180601.20086.marek.va...@gmail.com> you wrote:
>
> > >   When I make using the following:
> > > make CROSS_COMPILE=ppc_85xx- sbc8548_PCI_33_PCIE_config
> > > make CROSS_COMPILE=ppc_85xx- OPTFLAGS=-O2 all
> > > 
> > > I am still having the same undefined reference above.
> > > 
> > > Should I be building with ppc_8xx instead?  If yes, why?
> > >   
> > >   Thanks,
> > 
> > This appears to be due to you trying to build with OPTFLAGS=-O2.  Remove
> > that and see what happens.
> > 
> 
> That seems to be a bug in the compiler, if you want -O2, try ELDK5.1 (which 
> has 
> newer compiler).

No.  He is using CROSS_COMPILE=ppc_85xx- which means ELDK 4.2 or
similar.  And there is no such compiler problem with any of these.
The "-O2" is just inappropriate here.

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
He who hesitates is not only lost, but miles from the next exit.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] sbc8548 build broken?

[Marek Vasut]

> On Nov 17, 2011, at 5:33 PM, Robert Hurdle wrote:
> > Hello Mr. Denk,
> > 
> > You wrote:
> >> you wrote:
> >>>   I downloaded the ELDK 4.2 and installed it.  I got the u-boot
> >>>   source from git://git.denx.de/u-boot-mpc85xx.git.
> >>>   
> >>>   When I try to build u-boot for sbc8548 I get the following error:
> >>>   
> >>>   "arch/powerpc/cpu/mpc8xxx/ddr/libddr.o: In function
> >>>   `fsl_ddr_compute':"
> >>>   "/home/rhurdle/proj/u-boot/arch/powerpc/cpu/mpc8xxx/ddr/main.c:375:
> >>>   undefined reference to `fsl_ddr_get_dimm_params'" "make: *** [u-boot]
> >>>   Error 1"
> >> 
> >> I cannot confirm this - using current top of tree I get:
> >> 
> >> + MAKEALL_LOGDIR=/work/wd/tmp-ppc-LOG
> >> + BUILD_DIR=/work/wd/tmp-ppc
> >> + ./MAKEALL sbc8548
> >> Configuring for sbc8548 board...
> >> 
> >>  textdata bss dec hex filename
> >> 
> >> 1999288956   24576  233460   38ff4 /work/wd/tmp-ppc/u-boot
> >> 
> >> - SUMMARY  Boards
> >> compiled: 1 --
> >> 
> > I have obtained the source from the current top of the tree.
> > 
> > When I make using the following:
> > make CROSS_COMPILE=ppc_85xx- sbc8548_PCI_33_PCIE_config
> > make CROSS_COMPILE=ppc_85xx- OPTFLAGS=-O2 all
> > 
> > I am still having the same undefined reference above.
> > 
> > Should I be building with ppc_8xx instead?  If yes, why?
> > 
> > Thanks,
> 
> This appears to be due to you trying to build with OPTFLAGS=-O2.  Remove
> that and see what happens.
> 

That seems to be a bug in the compiler, if you want -O2, try ELDK5.1 (which has 
newer compiler).

M
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] sbc8548 build broken?

[Kumar Gala]

On Nov 17, 2011, at 5:33 PM, Robert Hurdle wrote:

> Hello Mr. Denk,
> 
> You wrote:
>> you wrote:
>>> 
>>> I downloaded the ELDK 4.2 and installed it.  I got the u-boot
>>> source from git://git.denx.de/u-boot-mpc85xx.git.
>>> 
>>> When I try to build u-boot for sbc8548 I get the following error:
>>> 
>>> "arch/powerpc/cpu/mpc8xxx/ddr/libddr.o: In function `fsl_ddr_compute':"
>>> "/home/rhurdle/proj/u-boot/arch/powerpc/cpu/mpc8xxx/ddr/main.c:375: 
>>> undefined reference to `fsl_ddr_get_dimm_params'"
>>> "make: *** [u-boot] Error 1"
>> 
>> I cannot confirm this - using current top of tree I get:
>> 
>> + MAKEALL_LOGDIR=/work/wd/tmp-ppc-LOG
>> + BUILD_DIR=/work/wd/tmp-ppc
>> + ./MAKEALL sbc8548
>> Configuring for sbc8548 board...
>>  textdata bss dec hex filename
>> 1999288956   24576  233460   38ff4 /work/wd/tmp-ppc/u-boot
>> 
>> - SUMMARY  Boards compiled: 1
>> --
> 
> I have obtained the source from the current top of the tree.
> 
>   When I make using the following:
> 
> make CROSS_COMPILE=ppc_85xx- sbc8548_PCI_33_PCIE_config
> make CROSS_COMPILE=ppc_85xx- OPTFLAGS=-O2 all
> 
> I am still having the same undefined reference above.
> 
> Should I be building with ppc_8xx instead?  If yes, why?
> 
>   Thanks,

This appears to be due to you trying to build with OPTFLAGS=-O2.  Remove that 
and see what happens.

- k
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] Fix warnings in arch/arm/cpu/arm920t/s3c24x0/usb_ohci.c

[Marek Vasut]

> On Wednesday 16 November 2011 16:16:49 Simon Glass wrote:
> > On Wed, Nov 16, 2011 at 8:03 AM, Mike Frysinger wrote:
> > > On Tuesday 15 November 2011 23:17:06 Simon Glass wrote:
> > >> --- a/arch/arm/cpu/arm920t/s3c24x0/usb_ohci.c
> > >> +++ b/arch/arm/cpu/arm920t/s3c24x0/usb_ohci.c
> > >> 
> > >> - __u32 datab[4];
> > >> - __u8 *data_buf = (__u8 *) datab;
> > >> + union {
> > >> + __u32 word[4];
> > >> + __u16 hword[8];
> > >> + __u8 byte[16];
> > >> + } datab;
> > >> + __u8 *data_buf = datab.byte;
> > > 
> > > i thought someone posted this fix to the list before.  but maybe it was
> > > for a different controller.  perhaps this code has been copied/pasted
> > > all over ... -mike
> > 
> > Yes I found Marek's patch to another file with the same name, and much
> > of the same code :-( But I don't think we currently have a patch for
> > this file. It issues warnings in about 10 ARM builds from memory.
> 
> np.  i know much of the u-boot arm tree (like Linux) has crappy cross-SoC
> integration.
> 
> Acked-by: Mike Frysinger 
> -mike

Well it kinda looks like this OHCI is copy of the drivers/usb/host/ohci-hcd.c ?

M
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] sbc8548 build broken?

[Marek Vasut]

> Hello Mr. Denk,
> 
> You wrote:
> >you wrote:
> >>I downloaded the ELDK 4.2 and installed it.  I got the u-boot
> >>source from git://git.denx.de/u-boot-mpc85xx.git.
> >>
> >>When I try to build u-boot for sbc8548 I get the following error:
> >>
> >>"arch/powerpc/cpu/mpc8xxx/ddr/libddr.o: In function `fsl_ddr_compute':"
> >>"/home/rhurdle/proj/u-boot/arch/powerpc/cpu/mpc8xxx/ddr/main.c:375:
> >>undefined reference to `fsl_ddr_get_dimm_params'" "make: *** [u-boot]
> >>Error 1"
> >
> >I cannot confirm this - using current top of tree I get:
> >
> >+ MAKEALL_LOGDIR=/work/wd/tmp-ppc-LOG
> >+ BUILD_DIR=/work/wd/tmp-ppc
> >+ ./MAKEALL sbc8548
> >Configuring for sbc8548 board...
> >
> >   textdata bss dec hex filename
> > 
> > 1999288956   24576  233460   38ff4 /work/wd/tmp-ppc/u-boot
> >
> >- SUMMARY  Boards
> >compiled: 1 --
> 
>  I have obtained the source from the current top of the tree.
> 
>   When I make using the following:
> 
>  make CROSS_COMPILE=ppc_85xx- sbc8548_PCI_33_PCIE_config
>  make CROSS_COMPILE=ppc_85xx- OPTFLAGS=-O2 all
> 
>  I am still having the same undefined reference above.
> 
>  Should I be building with ppc_8xx instead?  If yes, why?
> 
>   Thanks,
> 
>  Robert Hurdle
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot

$ CROSS_COMPILE=powerpc-linux- ARCH=powerpc ./MAKEALL sbc8548_PCI_33_PCIE
Configuring for sbc8548_PCI_33_PCIE - Board: sbc8548, Options: PCI,33,PCIE
   textdata bss dec hex filename
 224622   19288   25000  268910   41a6e ./u-boot

- SUMMARY 
Boards compiled: 1
--

So can you try MAKEALL ?

M
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v5] x86: Initial commit for running as a coreboot payload

[Gabe Black]

Add a target for running u-boot as a coreboot payload in boards.cfg, a
board, CPU and a config. This is a skeleton implementation which always
reports the size of memory as 64 MB.

Signed-off-by: Gabe Black 
---
Changes in v5:
Merge several smaller commits into this single commit.

 arch/x86/cpu/coreboot/Makefile   |   55 ++
 arch/x86/cpu/coreboot/asm-offsets.c  |   25 +++
 arch/x86/cpu/coreboot/coreboot_car.S |   29 +++
 arch/x86/cpu/coreboot/sdram.c|   39 
 board/chromebook-x86/coreboot/Makefile   |   53 +
 board/chromebook-x86/coreboot/coreboot.c |   77 
 board/chromebook-x86/coreboot/coreboot_pci.c |   30 +++
 board/chromebook-x86/coreboot/coreboot_start.S   |   29 +++
 board/chromebook-x86/coreboot/coreboot_start16.S |   46 +
 boards.cfg   |1 +
 include/configs/coreboot.h   |  225 ++
 include/serial.h |2 +-
 12 files changed, 610 insertions(+), 1 deletions(-)
 create mode 100644 arch/x86/cpu/coreboot/Makefile
 create mode 100644 arch/x86/cpu/coreboot/asm-offsets.c
 create mode 100644 arch/x86/cpu/coreboot/coreboot_car.S
 create mode 100644 arch/x86/cpu/coreboot/sdram.c
 create mode 100644 board/chromebook-x86/coreboot/Makefile
 create mode 100644 board/chromebook-x86/coreboot/coreboot.c
 create mode 100644 board/chromebook-x86/coreboot/coreboot_pci.c
 create mode 100644 board/chromebook-x86/coreboot/coreboot_start.S
 create mode 100644 board/chromebook-x86/coreboot/coreboot_start16.S
 create mode 100644 include/configs/coreboot.h

diff --git a/arch/x86/cpu/coreboot/Makefile b/arch/x86/cpu/coreboot/Makefile
new file mode 100644
index 000..0444399
--- /dev/null
+++ b/arch/x86/cpu/coreboot/Makefile
@@ -0,0 +1,55 @@
+#
+# Copyright (c) 2011 The Chromium OS Authors.
+#
+# (C) Copyright 2008
+# Graeme Russ, graeme.r...@gmail.com.
+#
+# (C) Copyright 2006
+# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+#
+# (C) Copyright 2002
+# Daniel Engström, Omicron Ceti AB, dan...@omicron.se.
+#
+# 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$(SOC).o
+
+COBJS-$(CONFIG_SYS_COREBOOT) += sdram.o
+
+SOBJS-$(CONFIG_SYS_COREBOOT) += coreboot_car.o
+
+SRCS   := $(SOBJS-y:.o=.S) $(COBJS-y:.o=.c)
+OBJS   := $(addprefix $(obj),$(SOBJS-y) $(COBJS-y))
+
+all: $(obj).depend $(LIB)
+
+$(LIB):$(OBJS)
+   $(call cmd_link_o_target, $(OBJS))
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/arch/x86/cpu/coreboot/asm-offsets.c 
b/arch/x86/cpu/coreboot/asm-offsets.c
new file mode 100644
index 000..97937da
--- /dev/null
+++ b/arch/x86/cpu/coreboot/asm-offsets.c
@@ -0,0 +1,25 @@
+/*
+ * Adapted from Linux v2.6.36 kernel: arch/powerpc/kernel/asm-offsets.c
+ *
+ * This program is used to generate definitions needed by
+ * assembly language modules.
+ *
+ * We use the technique used in the OSF Mach kernel code:
+ * generate asm statements containing #defines,
+ * compile this file to assembler, and then extract the
+ * #defines from the assembly-language output.
+ *
+ * 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.
+ */
+
+#include 
+#include 
+
+int main(void)
+{
+   DEFINE(GENERATED_GD_RELOC_OFF, offsetof(gd_t, reloc_off));
+   return 0;
+}
diff --git a/arch/x86/cpu/coreboot/coreboot_car.S 
b/arch/x86/cpu/coreboot/coreboot_car.S
new file mode 100644
index 000..3cc2575
--- /dev/null
+++ b/arch/x86/cpu/coreboot/coreboot_car.S
@@ -0,0 +1,29 @@
+/*
+ * Copyright (c) 2011 The Chromium OS Authors.
+ * (C) Copyright 2010-2011
+ * Graeme Russ, 
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modif

[U-Boot] sbc8548 build broken?

[Robert Hurdle]

Hello Mr. Denk,

You wrote:
>you wrote:
>> 
>>  I downloaded the ELDK 4.2 and installed it.  I got the u-boot
>>  source from git://git.denx.de/u-boot-mpc85xx.git.
>> 
>>  When I try to build u-boot for sbc8548 I get the following error:
>> 
>>  "arch/powerpc/cpu/mpc8xxx/ddr/libddr.o: In function `fsl_ddr_compute':"
>>  "/home/rhurdle/proj/u-boot/arch/powerpc/cpu/mpc8xxx/ddr/main.c:375: 
>> undefined reference to `fsl_ddr_get_dimm_params'"
>>  "make: *** [u-boot] Error 1"
>
>I cannot confirm this - using current top of tree I get:
>
>+ MAKEALL_LOGDIR=/work/wd/tmp-ppc-LOG
>+ BUILD_DIR=/work/wd/tmp-ppc
>+ ./MAKEALL sbc8548
>Configuring for sbc8548 board...
>   textdata bss dec hex filename
> 1999288956   24576  233460   38ff4 /work/wd/tmp-ppc/u-boot
>
>- SUMMARY  Boards compiled: 1
>--

 I have obtained the source from the current top of the tree.

When I make using the following:

 make CROSS_COMPILE=ppc_85xx- sbc8548_PCI_33_PCIE_config
 make CROSS_COMPILE=ppc_85xx- OPTFLAGS=-O2 all

 I am still having the same undefined reference above.

 Should I be building with ppc_8xx instead?  If yes, why?

Thanks,

 Robert Hurdle
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 4/4] tegra2: Add Avionic Design Medcom support.

[Simon Glass]

On Thu, Nov 17, 2011 at 2:10 AM, Thierry Reding
 wrote:
> The Medcom is a 16:9 15" terminal that is used for patient infotainment
> in hospitals.
>
> Changes in v3:
>  * Remove unused implementation of gpio_config_uart().
>  * Implement MMC/SD card detection.
>  * Drop board_mmc_getcd() which is now implemented by common Tegra2
>    code.
>  * Add MAINTAINERS entry.
>
> Changes in v2:
>  * No longer override the default CONFIG_SYS_TEXT_BASE setting.
>
> Signed-off-by: Thierry Reding 

Acked-by: Simon Glass 

> ---
>  MAINTAINERS                          |    1 +
>  board/avionic-design/medcom/Makefile |   50 +++
>  board/avionic-design/medcom/medcom.c |   45 
>  boards.cfg                           |    1 +
>  include/configs/medcom.h             |   62 
> ++
>  5 files changed, 159 insertions(+), 0 deletions(-)
>  create mode 100644 board/avionic-design/medcom/Makefile
>  create mode 100644 board/avionic-design/medcom/medcom.c
>  create mode 100644 include/configs/medcom.h
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 3/4] tegra2: Add Avionic Design Plutux support.

[Simon Glass]

On Thu, Nov 17, 2011 at 2:10 AM, Thierry Reding
 wrote:
> The Plutux is a set-top box device based on the Tamonten processor
> module. It can be connected to a display via an HDMI output.
>
> Changes in v3:
>  * Remove unused implementation of gpio_config_uart().
>  * Implement MMC/SD card detection.
>  * Drop board_mmc_getcd() which is now implemented by common Tegra2
>    code.
>  * Add MAINTAINERS entry.
>
> Changes in v2:
>  * No longer override the default CONFIG_SYS_TEXT_BASE setting.
>
> Signed-off-by: Thierry Reding 

Acked-by: Simon Glass 

> ---
>  MAINTAINERS                          |    4 ++
>  board/avionic-design/plutux/Makefile |   50 +++
>  board/avionic-design/plutux/plutux.c |   45 
>  boards.cfg                           |    1 +
>  include/configs/plutux.h             |   62 
> ++
>  5 files changed, 162 insertions(+), 0 deletions(-)
>  create mode 100644 board/avionic-design/plutux/Makefile
>  create mode 100644 board/avionic-design/plutux/plutux.c
>  create mode 100644 include/configs/plutux.h
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 2/4] tegra2: Add common Avionic Design Tamonten support.

[Simon Glass]

On Thu, Nov 17, 2011 at 2:10 AM, Thierry Reding
 wrote:
> Tamonten is an NVIDIA Tegra2-based SO-DIMM processor module that is
> derived from the Harmony reference design.
>
> Changes in v3:
>  * Remove unused gpio_config_uart().
>  * Remove call to tegra2_start().
>  * Use new tegra2_mmc_init().
>
> Signed-off-by: Thierry Reding 

The SPI patch set cleans up this UART code, but it isn't applied yet,
so we will clean this up later.

Acked-by: Simon Glass 

> ---
>  board/avionic-design/common/tamonten.c |  160 
> 
>  board/avionic-design/common/tamonten.h |   32 +++
>  2 files changed, 192 insertions(+), 0 deletions(-)
>  create mode 100644 board/avionic-design/common/tamonten.c
>  create mode 100644 board/avionic-design/common/tamonten.h
>
> diff --git a/board/avionic-design/common/tamonten.c 
> b/board/avionic-design/common/tamonten.c
> new file mode 100644
> index 000..98aa0f8
> --- /dev/null
> +++ b/board/avionic-design/common/tamonten.c
> @@ -0,0 +1,160 @@
> +/*
> + *  (C) Copyright 2010,2011
> + *  NVIDIA Corporation 
> + *  (C) Copyright 2011
> + *  Avionic Design GmbH 
> + *
> + * See file CREDITS for list of people who contributed to this
> + * project.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of
> + * the License, or (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
> + * MA 02111-1307 USA
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include "tamonten.h"
> +
> +#ifdef CONFIG_TEGRA2_MMC
> +#include 
> +#endif
> +
> +DECLARE_GLOBAL_DATA_PTR;
> +
> +const struct tegra2_sysinfo sysinfo = {
> +       CONFIG_TEGRA2_BOARD_STRING
> +};
> +
> +/*
> + * Routine: timer_init
> + * Description: init the timestamp and lastinc value
> + */
> +int timer_init(void)
> +{
> +       return 0;
> +}
> +
> +static void enable_uart(enum periph_id pid)
> +{
> +       /* Assert UART reset and enable clock */
> +       reset_set_enable(pid, 1);
> +       clock_enable(pid);
> +       clock_ll_set_source(pid, 0);    /* UARTx_CLK_SRC = 00, PLLP_OUT0 */
> +
> +       /* wait for 2us */
> +       udelay(2);
> +
> +       /* De-assert reset to UART */
> +       reset_set_enable(pid, 0);
> +}
> +
> +/*
> + * Routine: clock_init_uart
> + * Description: init the PLL and clock for the UART(s)
> + */
> +static void clock_init_uart(void)
> +{
> +#if defined(CONFIG_TEGRA2_ENABLE_UARTD)
> +       enable_uart(PERIPH_ID_UART4);
> +#endif /* CONFIG_TEGRA2_ENABLE_UARTD */
> +}
> +
> +/*
> + * Routine: pin_mux_uart
> + * Description: setup the pin muxes/tristate values for the UART(s)
> + */
> +static void pin_mux_uart(void)
> +{
> +#if defined(CONFIG_TEGRA2_ENABLE_UARTD)
> +       pinmux_set_func(PINGRP_GMC, PMUX_FUNC_UARTD);
> +
> +       pinmux_tristate_disable(PINGRP_GMC);
> +#endif /* CONFIG_TEGRA2_ENABLE_UARTD */
> +}
> +
> +#ifdef CONFIG_TEGRA2_MMC
> +/*
> + * Routine: pin_mux_mmc
> + * Description: setup the pin muxes/tristate values for the SDMMC(s)
> + */
> +static void pin_mux_mmc(void)
> +{
> +       /* SDMMC4: config 3, x8 on 2nd set of pins */
> +       pinmux_set_func(PINGRP_ATB, PMUX_FUNC_SDIO4);
> +       pinmux_set_func(PINGRP_GMA, PMUX_FUNC_SDIO4);
> +       pinmux_set_func(PINGRP_GME, PMUX_FUNC_SDIO4);
> +
> +       pinmux_tristate_disable(PINGRP_ATB);
> +       pinmux_tristate_disable(PINGRP_GMA);
> +       pinmux_tristate_disable(PINGRP_GME);
> +}
> +#endif
> +
> +/*
> + * Routine: board_init
> + * Description: Early hardware init.
> + */
> +int board_init(void)
> +{
> +       clock_init();
> +       clock_verify();
> +
> +       /* boot param addr */
> +       gd->bd->bi_boot_params = (NV_PA_SDRAM_BASE + 0x100);
> +
> +       return 0;
> +}
> +
> +#ifdef CONFIG_TEGRA2_MMC
> +/* this is a weak define that we are overriding */
> +int board_mmc_init(bd_t *bd)
> +{
> +       debug("board_mmc_init called\n");
> +       /* Enable muxes, etc. for SDMMC controllers */
> +       pin_mux_mmc();
> +       gpio_config_mmc();
> +
> +       debug("board_mmc_init: init eMMC\n");
> +       /* init dev 0, eMMC chip, with 4-bit bus */
> +       tegra2_mmc_init(0, 4, -1, GPIO_PH2);
> +
> +       return 0;
> +}
> +#endif
> +
> +#ifdef CONFIG_BOARD_EARLY_INIT_F
> +int board_early_init_f(void)
> +{
> +       /* Initialize essential common plls */
> +       clock_early_init();
> +
>

Re: [U-Boot] [PATCH v3 1/4] tegra2: Move tegra2_mmc_init() prototype to public header.

[Simon Glass]

On Thu, Nov 17, 2011 at 10:10 AM, Stephen Warren  wrote:
> Thierry Reding wrote at Thursday, November 17, 2011 3:10 AM:
>> tegra2_mmc_init() is implemented by the Tegra2 MMC driver. Since most of
>> the Tegra2-based boards will need to call it, this commit exports it in
>> the new public asm/arch/mmc.h header file to prevent each board from
>> providing its own prototype.
>>
>> Signed-off-by: Thierry Reding 
>
> This 1 patch,
>
> Acked-by: Stephen Warren 
> Tested-by: Stephen Warren 

Thanks!

Acked-by: Simon Glass 

>
> Thanks for cleaning this up.
>
> --
> nvpublic
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] tegra2: Always build with USE_PRIVATE_LIBGCC=yes.

[Simon Glass]

On Thu, Nov 17, 2011 at 2:04 AM, Thierry Reding
 wrote:
> The AVP on Tegra2 doesn't boot properly when U-Boot is linked against
> the GCC provided libgcc. To work around this, always build and link
> against a private libgcc for Tegra2-based boards.
>
> Signed-off-by: Thierry Reding 

Tested-by: Simon Glass 

> ---
>  arch/arm/cpu/armv7/tegra2/config.mk |    2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/cpu/armv7/tegra2/config.mk 
> b/arch/arm/cpu/armv7/tegra2/config.mk
> index 8f9bdc9..2303dba 100644
> --- a/arch/arm/cpu/armv7/tegra2/config.mk
> +++ b/arch/arm/cpu/armv7/tegra2/config.mk
> @@ -29,3 +29,5 @@
>  ifdef CONFIG_TEGRA2
>  CFLAGS_arch/arm/lib/board.o += -march=armv4t
>  endif
> +
> +USE_PRIVATE_LIBGCC = yes
> --
> 1.7.7.3
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] Add PR1 Appliance - ISDN PRI board

[Dimitar Penev]

Hello,

I am supporting Switchfin GPL software (www.switchfin.org) which contains 
supports of PR1 Appliance - Asterisk based ISDN PRI PBX.

This board is Blackfin BF537 based. The schematics is not fully opened.

The following patch adds PR1 Appliance support in u-boot.
It is based on u-boot-2011.09 from the ADI u-boot git repository

My email client is folding the patch line so I dare to post the link to the 
patch instead.


Signed-off-by: Dimitar Penev 
Cc: Mike Frysinger  

www.switchfin.org/patches/uBoot-pr1.patch

Best Regards
Dimitar Penev

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2] mvgbe: remove setting of ethaddr within the driver

[Michael Walle]

A network driver should not touch the environment at all. This patch fixes
this behaviour by removing the code for setting a default/randomized MAC
address.

Signed-off-by: Michael Walle 
Acked-by: Mike Frysinger 
Acked-by: Prafulla Wadaskar 
Cc: Mike Frysinger 
Cc: Prafulla Wadaskar 
Cc: Valentin Longchamp 
Cc: Eric Cooper 
Cc: Jason Cooper 
Cc: Siddarth Gore 
Cc: Albert ARIBAUD 
Cc: Simon Guinot 
---
 drivers/net/mvgbe.c |   23 ---
 1 files changed, 0 insertions(+), 23 deletions(-)

diff --git a/drivers/net/mvgbe.c b/drivers/net/mvgbe.c
index c7f7446..21be642 100644
--- a/drivers/net/mvgbe.c
+++ b/drivers/net/mvgbe.c
@@ -647,7 +647,6 @@ int mvgbe_initialize(bd_t *bis)
struct mvgbe_device *dmvgbe;
struct eth_device *dev;
int devnum;
-   char *s;
u8 used_ports[MAX_MVGBE_DEVS] = CONFIG_MVGBE_PORTS;
 
for (devnum = 0; devnum < MAX_MVGBE_DEVS; devnum++) {
@@ -702,16 +701,13 @@ error1:
/* must be less than NAMESIZE (16) */
sprintf(dev->name, "egiga%d", devnum);
 
-   /* Extract the MAC address from the environment */
switch (devnum) {
case 0:
dmvgbe->regs = (void *)MVGBE0_BASE;
-   s = "ethaddr";
break;
 #if defined(MVGBE1_BASE)
case 1:
dmvgbe->regs = (void *)MVGBE1_BASE;
-   s = "eth1addr";
break;
 #endif
default:/* this should never happen */
@@ -720,25 +716,6 @@ error1:
return -1;
}
 
-   while (!eth_getenv_enetaddr(s, dev->enetaddr)) {
-   /* Generate Private MAC addr if not set */
-   dev->enetaddr[0] = 0x02;
-   dev->enetaddr[1] = 0x50;
-   dev->enetaddr[2] = 0x43;
-#if defined (CONFIG_SKIP_LOCAL_MAC_RANDOMIZATION)
-   /* Generate fixed lower MAC half using devnum */
-   dev->enetaddr[3] = 0;
-   dev->enetaddr[4] = 0;
-   dev->enetaddr[5] = devnum;
-#else
-   /* Generate random lower MAC half */
-   dev->enetaddr[3] = get_random_hex();
-   dev->enetaddr[4] = get_random_hex();
-   dev->enetaddr[5] = get_random_hex();
-#endif
-   eth_setenv_enetaddr(s, dev->enetaddr);
-   }
-
dev->init = (void *)mvgbe_init;
dev->halt = (void *)mvgbe_halt;
dev->send = (void *)mvgbe_send;
-- 
1.7.2.5

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 08/12] OMAP3 SPL: Add identify_nand_chip function

[Tom Rini]

On 11/09/2011 11:25 PM, Heiko Schocher wrote:
> Hello Tom,
> 
> Tom Rini wrote:
>> A number of boards are populated with a PoP chip for both DDR and NAND
>> memory.  Other boards may simply use this as an easy way to identify
>> board revs.  So we provide a function that can be called early to reset
>> the NAND chip and return the result of NAND_CMD_READID.  All of this
>> code is put into spl_id_nand.c and controlled via CONFIG_SPL_OMAP3_ID_NAND.
>>
>> Signed-off-by: Tom Rini 
>> ---
>>  arch/arm/cpu/armv7/omap3/Makefile   |3 +
>>  arch/arm/cpu/armv7/omap3/spl_id_nand.c  |   83 
>> +++
>>  arch/arm/include/asm/arch-omap3/sys_proto.h |1 +
>>  3 files changed, 87 insertions(+), 0 deletions(-)
>>  create mode 100644 arch/arm/cpu/armv7/omap3/spl_id_nand.c
>>
>> diff --git a/arch/arm/cpu/armv7/omap3/spl_id_nand.c 
>> b/arch/arm/cpu/armv7/omap3/spl_id_nand.c
>> new file mode 100644
>> index 000..edf3ded
>> --- /dev/null
>> +++ b/arch/arm/cpu/armv7/omap3/spl_id_nand.c
>> @@ -0,0 +1,83 @@
> [...]
>> +void identify_nand_chip(int *mfr, int *id)
>> +{
>> +/* Make sure that we have setup GPMC for NAND correctly. */
>> +writel(M_NAND_GPMC_CONFIG1, &gpmc_config->cs[0].config1);
>> +writel(M_NAND_GPMC_CONFIG2, &gpmc_config->cs[0].config2);
>> +writel(M_NAND_GPMC_CONFIG3, &gpmc_config->cs[0].config3);
>> +writel(M_NAND_GPMC_CONFIG4, &gpmc_config->cs[0].config4);
>> +writel(M_NAND_GPMC_CONFIG5, &gpmc_config->cs[0].config5);
>> +writel(M_NAND_GPMC_CONFIG6, &gpmc_config->cs[0].config6);
>> +
>> +/* Enable the GPMC Mapping */
>> +writelGPMC_SIZE_128M & 0xF) << 8) | ((NAND_BASE >> 24) & 0x3F) |
>  ^ ^ ^
>> +(1 << 6)), &gpmc_config->cs[0].config7);
> 
> 
> Please substitute this magic values through defines.

OK, I've clarified the original code and then done the same to this code.

-- 
Tom
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Pull request: u-boot-arm/master

[Simon Glass]

Hi,

On Thu, Nov 17, 2011 at 2:03 PM, Tom Warren  wrote:
> Wolfgang,
>
>> -Original Message-
>> From: Stephen Warren
>> Sent: Thursday, November 17, 2011 2:59 PM
>> To: Wolfgang Denk; Mike Frysinger
>> Cc: Albert ARIBAUD; Simon Glass; Marek Vasut; u-boot@lists.denx.de; Tom
>> Warren
>> Subject: RE: [U-Boot] Pull request: u-boot-arm/master
>>
>> Wolfgang Denk wrote at Thursday, November 17, 2011 2:57 PM:
>> > In message <20171639.19645.vap...@gentoo.org> you wrote:
>> > >
>> > > i think we need Wolfgang's support for setting up the repo.  i don't
>> > > think
>> >
>> > No problem with that.  u-boot-tegra ? u-boot-tegra2 ? or ... ?
>>
>> u-boot-tegra would be better than u-boot-tegra2; there's already Tegra 3,
>> and I hope that's not /too/ far off going upstream.
>
> u-boot-tegra. Tegra3 to follow before EOY (I hope), and others after that ...

u-boot-tegra it is!

Regards,
Simon

>
> Make me the custodian for now. I'll give you more names of other NVidians 
> that will need push access later, if that's alright.
>
> Thanks,
>
> Tom
>>
>> --
>> nvpublic
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Pull request: u-boot-arm/master

[Albert ARIBAUD]

Hi Wolfgang, Mike,

Le 17/11/2011 22:56, Wolfgang Denk a écrit :

Dear Mike Frysinger,

In message<20171639.19645.vap...@gentoo.org>  you wrote:


i think we need Wolfgang's support for setting up the repo.  i don't think


No problem with that.  u-boot-tegra ? u-boot-tegra2 ? or ... ?


Simon will probably be better placed for answering. Personally I prefer 
boot-tegra if tegra and tegra2 have much in common.



Best regards,

Wolfgang Denk


Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Pull request: u-boot-arm/master

[Wolfgang Denk]

Dear Mike Frysinger,

In message <20171639.19645.vap...@gentoo.org> you wrote:
>
> i think we need Wolfgang's support for setting up the repo.  i don't think 

No problem with that.  u-boot-tegra ? u-boot-tegra2 ? or ... ?

> denx is running anything like gitolite for people to admin repos via ssh.

No.

> we need one name i think as the goto guy for the repo.  i don't know of any 
> other repo that allows more than one person to push to it, but i don't see a 
> problem with allowing more than one ...

Actually there are a few, even though this is not broadly announced -
except for u-boot-staging, where all custodians have access.

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
Overflow on /dev/null, please empty the bit bucket.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 06/12] OMAP3: Suffix all Micron memory timing parts with their speed

[Tom Rini]

On 11/09/2011 11:23 PM, Heiko Schocher wrote:
> Hello Tom,
> 
> Tom Rini wrote:
[snip]
>> +#define MICRON_V_MCFG_165   ((MICRON_LOCKSTATUS_165 << 30) | \
>^
> Please substitute this magic values in this patch by an define.

OK, what I've got now is a macro to calculate the MCFG values based on a
few inputs.  What I don't think helps readability is doing:

#define V_MCFG_CASWIDTH_SHIFT 20
#define V_MCFG_CASWIDTH (0x3 << V_MCFG_CASWIDTH_SHIFT)
when
#define V_MCFG_CASWIDTH (0x3 << 20) /* 20:23 */

will do.

It can make sense in places where it's not otherwise clear why you're
doing a shift but in these cases

-- 
Tom
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 05/12] OMAP3: Add optimal SDRC autorefresh control values

[Tom Rini]

On 11/09/2011 11:20 PM, Heiko Schocher wrote:
> Hello Tom,
> 
> Tom Rini wrote:
>> This adds the optimal SDRC autorefresh control register values for
>> 100Mhz, 133MHz, 165MHz and 200MHz clocks.  We switch to using this
>> to provide the default 165MHz value.
[snip]
>> +#define SDP_3430_SDRC_RFR_CTRL_133MHz   0x0003de01 /* 7.8us/7.5ns - 
>> 50=0x3de */
>> +#define SDP_3430_SDRC_RFR_CTRL_165MHz   0x0004e201 /* 7.8us/6ns - 
>> 50=0x4e2 */
>> +#define SDP_3430_SDRC_RFR_CTRL_200MHz   0x0005e601 /* 7.8us/5ns - 
>> 50=0x5e6 */
> 
> You should use something like that here:
> 
> #define OMAP3_SDP_SDRC_xx_SHIFT   8
> #define OMAP3_SDP_SDRC_yy (1 << 0)
> 
> #define SDP_3430_SDRC_RFR_CTRL_200MHz ((0x5e6 << OMAP3_SDP_SDRC_xx_SHIFT) |
>   OMAP3_SDP_SDRC_yy)

OK, I hadn't forgotten about this, I've just been a bit busy.  I broke
out the TRM, split these values out into binary and, breaking it out
into shifts won't help make it more understandable.  It needs a better
comment, which I will happily do.  Bits 1:0 are autofresh enable is 0x1
and 0x2/0x3 are bursts.  7:2 are reserved (as are 24:31) and 8:23 are
autorefresh counter value.

-- 
Tom
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Pull request: u-boot-arm/master

[Mike Frysinger]

On Thursday 17 November 2011 08:45:21 Albert ARIBAUD wrote:
> Le 16/11/2011 04:53, Mike Frysinger a écrit :
> > i thought Albert said he didn't want this last time we explicitly asked
> > about creating an arm/tegra sub-arch tree ...
> > 
> > i think there should be one
> 
> Uhm, no, I don't think I said I was against creating a Tegra U-Boot
> repo. What I may have said is that I don't want to fetch from a repo
> located somewhere else that on the Denx git server. If a u-boot-tegra
> repo is created on the Denx server, I'll be happy to pull from it.

i don't think we ever suggested the repo would be anywhere other than on the 
denx site, and i don't recall your response including "external to denx" 
qualifiers.  but let's skip the semantics and on to the end game.

i think we need Wolfgang's support for setting up the repo.  i don't think 
denx is running anything like gitolite for people to admin repos via ssh.

we need one name i think as the goto guy for the repo.  i don't know of any 
other repo that allows more than one person to push to it, but i don't see a 
problem with allowing more than one ...
-mike


signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] tegra2: Fix out-of-tree build for Ventana.

[Mike Frysinger]

On Thursday 17 November 2011 04:48:22 Thierry Reding wrote:
> Since Ventana is derived from Seaboard and requires seaboard.c to build,
> make sure board/nvidia/seaboard is created in the build tree.
> 
> --- a/board/nvidia/ventana/Makefile
> +++ b/board/nvidia/ventana/Makefile
> 
>  ifneq ($(OBJTREE),$(SRCTREE))
> +$(shell mkdir -p $(obj)../seaboard)
>  $(shell mkdir -p $(obj)../common)
>  endif

mkdir takes multiple paths.  thus my proposal:
-$(shell mkdir -p $(obj)../common)
+$(shell mkdir -p $(obj)../common $(obj)../seaboard)
-mike


signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] checkpatch compliance

[Mike Frysinger]

On Thursday 17 November 2011 15:10:22 Gerlando Falauto wrote:
> On 10/08/2011 12:28 AM, Joe Hershberger wrote:
> > Hi Wolfgang,
> > 
> > I'm attempting to make the files I touched in several recent
> > patch-series chechkpatch.pl compliant.
> > 
> > I've hit several cases which fail and probably shouldn't.  For each of
> > these cases, should the warning / error just be ignored or reported to
> > checkpatch maintainers or altered some other way?
> 
> What is wrong with something like:
> 
> ERROR: do not initialise statics to 0 or NULL
> #35: FILE: serial.c:32:
> +static struct serial_device *serial_devices = NULL;
> 
> ERROR: do not initialise statics to 0 or NULL
> #36: FILE: serial.c:33:
> +static struct serial_device *serial_current = NULL;

newer gcc is smart enough to put these into .bss.  i think older ones were not 
and put these into .data.  in either case, the initialization is redundant (by 
virtue of the "static"), so i'd just drop the "= NULL".
-mike


signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v4 1/5] x86: Add a target for running as a coreboot payload

[Gabe Black]

On Thu, Nov 17, 2011 at 2:26 AM, Graeme Russ  wrote:

> Hi Gabe,
>
> On 17/11/11 21:11, Gabe Black wrote:
> >
> >
> > On Thu, Nov 17, 2011 at 1:43 AM, Graeme Russ  > > wrote:
> >
> > Hi Gabe,
> >
> > On 17/11/11 11:27, Gabe Black wrote:
> > > Add a target for running u-boot as a coreboot payload in
> boards.cfg.
> > >
> > > Signed-off-by: Gabe Black 
> [snip]
>
> >
> > As mentioned by others before, there is no reason to have these as
> discrete
> > patches - Please merge into a single 'Add coreboot payload'
> >
> >
> >
> > Ok. Since there are more patches here than I sent out previously and one
> > big patch seemed like it was more than "exactly one complete logical
> > change" I wanted to find out how these should be merged. If they should
> all
> > be merged, then that answers the question.
>
> Well, if a given patch is meaningless without another, they really should
> be combined. Of course there are exceptions, like adding a new driver - The
> code for it gets added in one patch, and the usage in a board in another
>
> > Is there any real reason to reference 'chromebook-x86'?
> >
> > I don't follow. I'm not referencing it, that's what we're calling our
> board
> > since it's an x86 chromebook.
>
> I mean, if this is 'generic', why is there a reference to the chromebook?
>


The way it's ended up, the coreboot "CPU" is generic to coreboot, the
"board" is generic to chromebooks, and the config is either generic to
chromebooks or, if we decide we need it to be, specialized per specific
chromebook.



>
> > And finally, what is the plan for motherboard specific coreboot
> variants?
> >
> >
> >
> > We haven't worked out all the details, but our current working plan is
> that
> > coreboot itself will be specialized per board and that U-Boot will stay
> > fairly generic and be specialized as needed using the device tree. We may
> > find that a single version of U-Boot with a superset of drivers is too
> big
> > and we need to have different configs for each variant.
>
> This probably won't work in and of itself without a major overhaul of the
> U-Boot driver architecture :)
>
> Boards will need their own config for Ethernet drivers for example
>


This is working just fine so far, actually. It may not scale and we won't
be able to have more than one kind of certain things, but in the mean time
it's working for us. We are aware of these potential/eventual problems
though.

Gabe
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [STATUS] Custodians - please lend a hand

[Wolfgang Denk]

Dear Andy,

In message  
you wrote:
>
> Might I humbly suggest that the custodians just push changes to a
> separate branch in their own trees? It should be effectively the same,

I'd prefer to have it in one central location.  This also makes it
easier for others to check what's already present there.

> but without everyone possibly hitting the same repository at the same
> time...

On the day where you see performance problems because too many
custodians try to push too many patches to u-boot-staging
simultaneously I will rent a faster server.  Promised :-)

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
As a general rule, the freedom of any people can  be  judged  by  the
volume of their laughter.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] checkpatch compliance

[Wolfgang Denk]

Dear Gerlando Falauto,

In message <4ec56a2e.2000...@keymile.com> you wrote:
>
> What is wrong with something like:
> 
> ERROR: do not initialise statics to 0 or NULL
> #35: FILE: serial.c:32:
> +static struct serial_device *serial_devices = NULL;
> 
> ERROR: do not initialise statics to 0 or NULL
> #36: FILE: serial.c:33:
> +static struct serial_device *serial_current = NULL;
> 
> Since it's a bootloader, should we also ignore it with:

Why?  Why don't you just follow the advise and remove the redundant
initializers?

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
Don't you know anything? I should have thought anyone knows that  who
knows anything about anything...  - Terry Pratchett, _Soul Music_
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [STATUS] Custodians - please lend a hand

[Andy Fleming]

On Thu, Nov 17, 2011 at 12:19 PM, Detlev Zundel  wrote:
> Hi Stefano,
>
>> On 11/16/2011 07:51 PM, Wolfgang Denk wrote:
>>
>> Wolfgang,
>>

 Please let's try if this works.  If you have any suggestions how to
 help better, please don't hesitate to tell us.
>>
>> I have tried with a couple of patches (network related), and then I
>> wanted to test if push works. As u-boot-staging should be open for all
>> custodians, I was expecting I should use the same mechanism, and then I
>> tried with:
>>
>>
>> git push ssh://gu-...@git.denx.de/u-boot-staging sba...@denx.de
>>
>> ...but the new branch sba...@denx.de is now part of u-boot-imx, not
>> u-boot-staging ! Where is the mistake ?
>
> Indeed - this is because of the setup of the custodian trees.  The git
> action is directly coupled to the user account so the account gu-imx
> will _only_ be able to work inside that tree.  Effectively, the
> directory part of the URL is discarded...
>
> The correct usage is of course as Wolfgang points out through the
> gu-staging user.
>

Might I humbly suggest that the custodians just push changes to a
separate branch in their own trees? It should be effectively the same,
but without everyone possibly hitting the same repository at the same
time...

Andy
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Question about baud rate

[Detlev Zundel]

Hi Dan,

>> Why doe you want to setup this parameters "from the outside"?  Really
>> only the serial device used for a console needs to be setup by
>> firmware.  All other serial devices should be initialized by the user
>> space programs using them.
>
> I would like my startup script to cat messages to ttyS1, as well as to
> the console (ttyS0). Basically for the purpose of informing users that
> the firmware cannot execute for some reason (we don't like to give
> access to the console). I was trying to avoid including stty or
> setserial, but if this is the accepted way to configure the serial
> port it's not a big deal ;-)

Personally I believe that every software task should setup as much as
possible from what it knows to be needed for its own work.  For a serial
program this includes setting the baud rate and the communications
parameter like 8/n/1.

>>> For each of the three uarts, the device tree has the following line:
>>>
>>> current-speed = <0>; /* Filled in by U-Boot */
>>
>> Checking current U-Boot code, I believe this comment is simply
>> wrong. I
>> cannot see any part in the canyonlands / or generic 4xx
>> infrastructure
>> that fixes up these properties.  Maybe Stefan can comment on this
>> though.
>>
>
> Interesting...I also tried manually entering a value here, but it
> didn't seem to have any effect. Maybe it just isn't used?

This may very well be the case.  An answer can probably be found on the
linux ppc mailing list[1] ;)

>>> Sorry for the silly question!
>>
>> I don;t think its a silly question, but I also think that you do not
>> need the configuration ;)
>>
>> Cheers
>>   Detlev
>
> Thanks for your response!

You're welcome!
  Detlev

[1] http://dir.gmane.org/gmane.linux.ports.ppc64.devel
"PowerPC developers ML" 

-- 
Every time history repeats itself the price goes up.
--
DENX Software Engineering GmbH,  MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] checkpatch compliance

[Gerlando Falauto]

On 10/08/2011 12:28 AM, Joe Hershberger wrote:

Hi Wolfgang,

I'm attempting to make the files I touched in several recent
patch-series chechkpatch.pl compliant.

I've hit several cases which fail and probably shouldn't.  For each of
these cases, should the warning / error just be ignored or reported to
checkpatch maintainers or altered some other way?



What is wrong with something like:

ERROR: do not initialise statics to 0 or NULL
#35: FILE: serial.c:32:
+static struct serial_device *serial_devices = NULL;

ERROR: do not initialise statics to 0 or NULL
#36: FILE: serial.c:33:
+static struct serial_device *serial_current = NULL;

Since it's a bootloader, should we also ignore it with:

--ignore INITIALISED_STATIC

Or maybe not?

Thanks,
Gerlando
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 2/3] board/amcc/yucca/flash.c: Fix GCC 4.6 build warnings

[Wolfgang Denk]

Fix:
flash.c: In function 'flash_erase_1':
flash.c:425:24: warning: variable 'l_sect' set but not used
[-Wunused-but-set-variable]
flash.c: In function 'flash_erase_2':
flash.c:834:24: warning: variable 'l_sect' set but not used
[-Wunused-but-set-variable]

Signed-off-by: Wolfgang Denk 
Cc: Stefan Roese 
---
total: 0 errors, 0 warnings, 46 lines checked
NOTE: Ignored message types: COMPLEX_MACRO CONSIDER_KSTRTO MINMAX 
MULTISTATEMENT_MACRO_USE_DO_WHILE
0002-board-amcc-yucca-flash.c-Fix-GCC-4.6-build-warnings.patch has no obvious 
style problems and is ready for submission.

 board/amcc/yucca/flash.c |   10 ++
 1 files changed, 2 insertions(+), 8 deletions(-)

diff --git a/board/amcc/yucca/flash.c b/board/amcc/yucca/flash.c
index 20b6af9..ab513f9 100644
--- a/board/amcc/yucca/flash.c
+++ b/board/amcc/yucca/flash.c
@@ -422,7 +422,7 @@ int flash_erase(flash_info_t * info, int s_first, int 
s_last)
 {
volatile CONFIG_SYS_FLASH_WORD_SIZE *addr = (CONFIG_SYS_FLASH_WORD_SIZE 
*) (info->start[0]);
volatile CONFIG_SYS_FLASH_WORD_SIZE *addr2;
-   int flag, prot, sect, l_sect;
+   int flag, prot, sect;
int i;
 
if ((s_first < 0) || (s_first > s_last)) {
@@ -449,8 +449,6 @@ int flash_erase(flash_info_t * info, int s_first, int 
s_last)
 
printf("\n");
 
-   l_sect = -1;
-
/* Disable interrupts which might cause a timeout here */
flag = disable_interrupts();
 
@@ -476,7 +474,6 @@ int flash_erase(flash_info_t * info, int s_first, int 
s_last)
addr[CONFIG_SYS_FLASH_ADDR1] = 
(CONFIG_SYS_FLASH_WORD_SIZE) 0x00550055;
addr2[0] = (CONFIG_SYS_FLASH_WORD_SIZE) 
0x00300030; /* sector erase */
}
-   l_sect = sect;
/*
 * Wait for each sector to complete, it's more
 * reliable.  According to AMD Spec, you must
@@ -831,7 +828,7 @@ static int flash_erase_2(flash_info_t * info, int s_first, 
int s_last)
 {
volatile CONFIG_SYS_FLASH_WORD_SIZE *addr = (CONFIG_SYS_FLASH_WORD_SIZE 
*) (info->start[0]);
volatile CONFIG_SYS_FLASH_WORD_SIZE *addr2;
-   int flag, prot, sect, l_sect;
+   int flag, prot, sect;
int i;
 
if ((s_first < 0) || (s_first > s_last)) {
@@ -858,8 +855,6 @@ static int flash_erase_2(flash_info_t * info, int s_first, 
int s_last)
 
printf("\n");
 
-   l_sect = -1;
-
/* Disable interrupts which might cause a timeout here */
flag = disable_interrupts();
 
@@ -885,7 +880,6 @@ static int flash_erase_2(flash_info_t * info, int s_first, 
int s_last)
addr[CONFIG_SYS_FLASH_ADDR1] = 
(CONFIG_SYS_FLASH_WORD_SIZE) 0x00550055;
addr2[0] = (CONFIG_SYS_FLASH_WORD_SIZE) 
0x00300030; /* sector erase */
}
-   l_sect = sect;
/*
 * Wait for each sector to complete, it's more
 * reliable.  According to AMD Spec, you must
-- 
1.7.6.4

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 1/3] board/amcc/common/flash.c: Fix GCC 4.6 build warning

[Wolfgang Denk]

Fix:
In file included from flash.c:45:0:
../common/flash.c: In function 'flash_erase':
../common/flash.c:399:24: warning: variable 'l_sect' set but not used
[-Wunused-but-set-variable]

Signed-off-by: Wolfgang Denk 
Cc: Stefan Roese 
---
total: 0 errors, 0 warnings, 46 lines checked
NOTE: Ignored message types: COMPLEX_MACRO CONSIDER_KSTRTO MINMAX 
MULTISTATEMENT_MACRO_USE_DO_WHILE
0001-board-amcc-common-flash.c-Fix-GCC-4.6-build-warning.patch has no obvious 
style problems and is ready for submission.

 board/amcc/common/flash.c |   10 ++
 1 files changed, 2 insertions(+), 8 deletions(-)

diff --git a/board/amcc/common/flash.c b/board/amcc/common/flash.c
index 8f23375..1960fc1 100644
--- a/board/amcc/common/flash.c
+++ b/board/amcc/common/flash.c
@@ -396,7 +396,7 @@ int flash_erase(flash_info_t * info, int s_first, int 
s_last)
 {
volatile CONFIG_SYS_FLASH_WORD_SIZE *addr = (CONFIG_SYS_FLASH_WORD_SIZE 
*) (info->start[0]);
volatile CONFIG_SYS_FLASH_WORD_SIZE *addr2;
-   int flag, prot, sect, l_sect;
+   int flag, prot, sect;
int i;
 
if ((s_first < 0) || (s_first > s_last)) {
@@ -427,8 +427,6 @@ int flash_erase(flash_info_t * info, int s_first, int 
s_last)
printf("\n");
}
 
-   l_sect = -1;
-
/* Disable interrupts which might cause a timeout here */
flag = disable_interrupts();
 
@@ -454,7 +452,6 @@ int flash_erase(flash_info_t * info, int s_first, int 
s_last)
addr[CONFIG_SYS_FLASH_ADDR1] = 
(CONFIG_SYS_FLASH_WORD_SIZE) 0x00550055;
addr2[0] = (CONFIG_SYS_FLASH_WORD_SIZE) 
0x00300030; /* sector erase */
}
-   l_sect = sect;
/*
 * Wait for each sector to complete, it's more
 * reliable.  According to AMD Spec, you must
@@ -825,7 +822,7 @@ static int flash_erase_2(flash_info_t * info, int s_first, 
int s_last)
 {
volatile CONFIG_SYS_FLASH_WORD_SIZE *addr = (CONFIG_SYS_FLASH_WORD_SIZE 
*) (info->start[0]);
volatile CONFIG_SYS_FLASH_WORD_SIZE *addr2;
-   int flag, prot, sect, l_sect;
+   int flag, prot, sect;
int i;
 
if ((s_first < 0) || (s_first > s_last)) {
@@ -856,8 +853,6 @@ static int flash_erase_2(flash_info_t * info, int s_first, 
int s_last)
printf("\n");
}
 
-   l_sect = -1;
-
/* Disable interrupts which might cause a timeout here */
flag = disable_interrupts();
 
@@ -883,7 +878,6 @@ static int flash_erase_2(flash_info_t * info, int s_first, 
int s_last)
addr[CONFIG_SYS_FLASH_ADDR1] = 
(CONFIG_SYS_FLASH_WORD_SIZE) 0x00550055;
addr2[0] = (CONFIG_SYS_FLASH_WORD_SIZE) 
0x00300030; /* sector erase */
}
-   l_sect = sect;
/*
 * Wait for each sector to complete, it's more
 * reliable.  According to AMD Spec, you must
-- 
1.7.6.4

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 3/3] board/amcc/taihu/flash.c: Fix GCC 4.6 build warnings

[Wolfgang Denk]

Fix:
flash.c: In function 'flash_erase_1':
flash.c:514:24: warning: variable 'l_sect' set but not used
[-Wunused-but-set-variable]
flash.c: In function 'flash_erase_2':
flash.c:956:24: warning: variable 'l_sect' set but not used
[-Wunused-but-set-variable]

Signed-off-by: Wolfgang Denk 
Cc: Stefan Roese 
---
total: 0 errors, 0 warnings, 46 lines checked
NOTE: Ignored message types: COMPLEX_MACRO CONSIDER_KSTRTO MINMAX 
MULTISTATEMENT_MACRO_USE_DO_WHILE
0003-board-amcc-taihu-flash.c-Fix-GCC-4.6-build-warnings.patch has no obvious 
style problems and is ready for submission.

 board/amcc/taihu/flash.c |   10 ++
 1 files changed, 2 insertions(+), 8 deletions(-)

diff --git a/board/amcc/taihu/flash.c b/board/amcc/taihu/flash.c
index e9fbbb1..63968a4 100644
--- a/board/amcc/taihu/flash.c
+++ b/board/amcc/taihu/flash.c
@@ -511,7 +511,7 @@ int flash_erase(flash_info_t * info, int s_first, int 
s_last)
 {
volatile CONFIG_SYS_FLASH_WORD_SIZE *addr = (CONFIG_SYS_FLASH_WORD_SIZE 
*) (info->start[0]);
volatile CONFIG_SYS_FLASH_WORD_SIZE *addr2;
-   int flag, prot, sect, l_sect;
+   int flag, prot, sect;
int i;
 
if ((s_first < 0) || (s_first > s_last)) {
@@ -542,8 +542,6 @@ int flash_erase(flash_info_t * info, int s_first, int 
s_last)
printf("\n");
}
 
-   l_sect = -1;
-
/* Disable interrupts which might cause a timeout here */
flag = disable_interrupts();
 
@@ -569,7 +567,6 @@ int flash_erase(flash_info_t * info, int s_first, int 
s_last)
addr[CONFIG_SYS_FLASH_ADDR1] = 
(CONFIG_SYS_FLASH_WORD_SIZE) 0x00550055;
addr2[0] = (CONFIG_SYS_FLASH_WORD_SIZE) 
0x00300030; /* sector erase */
}
-   l_sect = sect;
/*
 * Wait for each sector to complete, it's more
 * reliable.  According to AMD Spec, you must
@@ -953,7 +950,7 @@ static int flash_erase_2(flash_info_t * info, int s_first, 
int s_last)
 {
volatile CONFIG_SYS_FLASH_WORD_SIZE *addr = (CONFIG_SYS_FLASH_WORD_SIZE 
*) (info->start[0]);
volatile CONFIG_SYS_FLASH_WORD_SIZE *addr2;
-   int flag, prot, sect, l_sect;
+   int flag, prot, sect;
int i;
 
if ((s_first < 0) || (s_first > s_last)) {
@@ -984,8 +981,6 @@ static int flash_erase_2(flash_info_t * info, int s_first, 
int s_last)
printf("\n");
}
 
-   l_sect = -1;
-
/* Disable interrupts which might cause a timeout here */
flag = disable_interrupts();
 
@@ -1011,7 +1006,6 @@ static int flash_erase_2(flash_info_t * info, int 
s_first, int s_last)
addr[CONFIG_SYS_FLASH_CHAR_ADDR1] = 
(CONFIG_SYS_FLASH_WORD_SIZE) 0x;
addr2[0] = (CONFIG_SYS_FLASH_WORD_SIZE) 
0x30303030; /* sector erase */
}
-   l_sect = sect;
/*
 * Wait for each sector to complete, it's more
 * reliable.  According to AMD Spec, you must
-- 
1.7.6.4

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] sbc8548 build broken?

[Wolfgang Denk]

Dear Robert Hurdle,

please do not top-post / full quote.  And always make sure to keep the
mailing list on cc:

In message 
<5498e86a4a68b14a8a06d0380640d04a016d217a6...@atca01em01.adsi.aitech.ent> you 
wrote:
> 
>   Thank you for checking it.
> 
>   What does "... using current top of tree" mean?

Top of tree of the master branch of the mainline repository, see
http://git.denx.de/?p=u-boot.git;a=summary

So be specific, git commit 0562219   2011-11-17 14:27:11 +0100
tools: checkpatch.pl from Linux added to tools


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 bad reputation UNIX has gotten is totally undeserved, laid on by
people who don't understand, who have not gotten in there  and  tried
anything."  -- Jim Joyce, owner of Jim Joyce's UNIX Bookstore
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] SSBI driver

[Wolfgang Denk]

Dear hanumant,

please always keep the mailing list on Cc:

In message <4ec561a4.8050...@codeaurora.org> you wrote:
> 
> > If you happen to mean "Single-Wire Serial Bus Interface" then you
> > should probably use the more common name "1-wire".
> Thanks. Yes it is Single-Wire Serial Bus Interface.
...
> Yes, now that you suggest this I do think this would be more appropriate.
> Though looking at the u-boot master branch, I don't find any drivers/w1.

We don't have generic 1-wire drivers yet.  The only one I'm aware of
is a custom driver deeply embedded into the code of ESD's CPCI405
board (see board/esd/cpci405/cpci405.c).

> Do you suggest I create a w1 directory based on the linux kernel 
> implementation and add my 1-wire (ssbi) driver to it.

Yes.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
If something is different, it's either better or worse,  and  usually
both.- Larry Wall
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] env: allow to export only selected variables

[Wolfgang Denk]

Dear Gerlando Falauto,

In message <4ec55b4f.4060...@keymile.com> you wrote:
> 
> >   ssize_t hexport_r(struct hsearch_data *htab, const char sep,
> > -char **resp, size_t size)
> > +char **resp, size_t size,
> > +int argc, char * const argv[])
> >   {
> > ENTRY *list[htab->size];
> > char *res, *p;
> 
> What happened to "please indent with TABs only"?
> Have I missed something, perhaps?

Yes, you missed this error in the initial code review :-)

[Unfortunaltely I haven't found yet a way to convince Lindent or
similar to use only TABs in places like that. Hints welcome.]

Please feel free to submit cleanup-patches.

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
Wenn das dann in die Hose geht, nehme ich es auf meine Kappe.
 -- Rudi Völler, 15. Nov 2003
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] SSBI driver

[Wolfgang Denk]

Dear hanumant,

In message <4ec55809.2090...@codeaurora.org> you wrote:
> 
>I am trying to implement a SSBI driver for a board. . The driver is 
> meant to be portable to multiple boards by the same vendor.

Maybe you would get more help if you explained what SSBI might be.
Is it:

SSBISingle Scope Background Investigation
SSBISpecies-Specific Biological Information
SSBISalomon Smith Barney Inc. (bank)
SSBIStichting Stimulering Bedrijfsmatig Imkeren

If you happen to mean "Single-Wire Serial Bus Interface" then you
should probably use the more common name "1-wire".

> 1)Would drivers/misc/ be the right location to implement this driver?

I would expect to find such drivers in  drivers/w1/  as used in Linux.

> 2)If not can I make a ($vendor)-common in the cpu directory to implement 
> the driver given that the driver is going to be applicable for multiple 
> socs by the same vendor. ie have something like the below.

That makes no sense.  If in doubt, look at the organization of the
Linux tree.  There such code is in  drivers/w1/  and I see no reason
why we would have to do different.

Best regards,

Wolfgang Denk

--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
If you're not part of the solution, you're part of the problem.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] env: allow to export only selected variables

[Gerlando Falauto]

Dear Wolfgang Denk,

> --- a/include/search.h
> +++ b/include/search.h
> @@ -91,7 +91,8 @@ extern int hstrstr_r(const char *__match, int __last_idx, 
> ENTRY ** __retval,
>   extern int hdelete_r(const char *__key, struct hsearch_data *__htab);
>
>   extern ssize_t hexport_r(struct hsearch_data *__htab,
> -  const char __sep, char **__resp, size_t __size);
> +  const char __sep, char **__resp, size_t __size,
> +  int argc, char * const argv[]);
>
>   extern int himport_r(struct hsearch_data *__htab,
>const char *__env, size_t __size, const char __sep,
> diff --git a/lib/hashtable.c b/lib/hashtable.c
> index 6895550..b7ba341 100644
> --- a/lib/hashtable.c
> +++ b/lib/hashtable.c
> @@ -478,7 +478,8 @@ static int cmpkey(const void *p1, const void *p2)
>   }
>
>   ssize_t hexport_r(struct hsearch_data *htab, const char sep,
> -  char **resp, size_t size)
> +  char **resp, size_t size,
> +  int argc, char * const argv[])
>   {
>   ENTRY *list[htab->size];
>   char *res, *p;

What happened to "please indent with TABs only"?
Have I missed something, perhaps?

Thank you,
Gerlando Falauto
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] sbc8548 build broken?

[Wolfgang Denk]

Dear Robert Hurdle,

In message 
<5498e86a4a68b14a8a06d0380640d04a016d217a6...@atca01em01.adsi.aitech.ent> you 
wrote:
> 
>   I downloaded the ELDK 4.2 and installed it.  I got the u-boot
>   source from git://git.denx.de/u-boot-mpc85xx.git.
> 
>   When I try to build u-boot for sbc8548 I get the following error:
> 
>   "arch/powerpc/cpu/mpc8xxx/ddr/libddr.o: In function `fsl_ddr_compute':"
>   "/home/rhurdle/proj/u-boot/arch/powerpc/cpu/mpc8xxx/ddr/main.c:375: 
> undefined reference to `fsl_ddr_get_dimm_params'"
>   "make: *** [u-boot] Error 1"

I cannot confirm this - using current top of tree I get:

+ MAKEALL_LOGDIR=/work/wd/tmp-ppc-LOG
+ BUILD_DIR=/work/wd/tmp-ppc
+ ./MAKEALL sbc8548
Configuring for sbc8548 board...
   textdata bss dec hex filename
 1999288956   24576  233460   38ff4 /work/wd/tmp-ppc/u-boot

- SUMMARY 
Boards compiled: 1
--


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
Pig: An animal (Porcus omnivorous) closely allied to the  human  race
by  the splendor and vivacity of its appetite, which, however, is in-
ferior in scope, for it balks at pig.- Ambrose Bierce
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] SSBI driver

[hanumant]

Hi

   I am trying to implement a SSBI driver for a board. . The driver is 
meant to be portable to multiple boards by the same vendor.
Keeping this in mind

1)Would drivers/misc/ be the right location to implement this driver?
2)If not can I make a ($vendor)-common in the cpu directory to implement 
the driver given that the driver is going to be applicable for multiple 
socs by the same vendor. ie have something like the below.
have arch/arm/cpu/armv7/($vendor)-common & arch/arm/cpu/armv7/($SOC).
I believe there is already precedent for this?

Any input is appreciated.

Thanks
Hanumant
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] env: allow to export only selected variables

[Gerlando Falauto]

Dear Wolfgang Denk,

> --- a/common/cmd_nvedit.c
> +++ b/common/cmd_nvedit.c
> @@ -125,7 +125,7 @@ static int env_print(char *name)
>   }
>
>   /* print whole list */
> - len = hexport_r(&env_htab, '\n',&res, 0);
> + len = hexport_r(&env_htab, '\n',&res, 0, 0, NULL);
>
>   if (len>  0) {
>   puts(res);

Here you extended the function signature by adding 2 new arguments and 
therefore you had to touch 12 existing function calls so to add the 
default values for the new args.

In my previous patches, I had renamed the sibling himport_r() function 
to himport_ex() with the 2 extra args and reimplemented himport_r() as a 
wrapper, so to maintain compatibility with the existing code.
Just to realize now that, after some reworking, there is only one 
function call to the original himport_r() left.
I'm going to get rid of this renaming.

I mean: completely opposite approaches... funny, huh?

Best,
Gerlando Falauto
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] sbc8548 build broken?

[Robert Hurdle]

Hello,

I downloaded the ELDK 4.2 and installed it.  I got the u-boot
source from git://git.denx.de/u-boot-mpc85xx.git.

When I try to build u-boot for sbc8548 I get the following error:

"arch/powerpc/cpu/mpc8xxx/ddr/libddr.o: In function `fsl_ddr_compute':"
"/home/rhurdle/proj/u-boot/arch/powerpc/cpu/mpc8xxx/ddr/main.c:375: 
undefined reference to `fsl_ddr_get_dimm_params'"
"make: *** [u-boot] Error 1"

Any help or advice is appreciated.

Thanks,

Robert Hurdle

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] disk: part_efi: Fix parameters passed to is_gpt_valid().

[Thierry Reding]

* Doug Anderson wrote:
> Agreed--I see myself in the CC from the start.

That leaves me really confused.

Thierry


pgptqQ3sZUSiB.pgp
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v4] arm:exynos4:samsung:nuri Support for NURI target.

[Marek Vasut]

> This patch adds support for Samsung's Exynos4 Nuri reference
> board.
> 
> New exynos4_nuri board has been added to boards.cfg
> 
> Signed-off-by: Lukasz Majewski 
> Signed-off-by: Kyungmin Park 
> Cc: Minkyu Kang 
> ---
> Changes for v2:
> - MAINTAINERS file updated
> - CONFIG_MACH_TYPE added
> - hw_revision routine
> Changes for v3:
>   - Entry to MAINTAINERS file added to preserve an alphabethical
> order
>   - Redefinition of MACH_TYPE removed at exynos4_nuri.h
>   - Code cleanup (dead spaces removed)
> Changes for v4:
>   - get_ram_size() check added to dram_init()
>   - Use of MACH_TYPE_NURI defined at ./arch/arm/include/asm/mach-types.h
> instead of a hard coded value
>   - Comments correction
> 
>  ./tools/checkpatch.pl -
> total: 0 errors, 0 warnings, 875 lines checked
> 
> NOTE: Ignored message types: COMPLEX_MACRO CONSIDER_KSTRTO MINMAX
> MULTISTATEMENT_MACRO_USE_DO_WHILE
> 
> ---
>  MAINTAINERS|4 +
>  board/samsung/nuri/Makefile|   45 
>  board/samsung/nuri/lowlevel_init.S |  395
>  board/samsung/nuri/nuri.c  | 
> 208 +++
>  boards.cfg |1 +
>  include/configs/exynos4_nuri.h |  210 +++
>  6 files changed, 863 insertions(+), 0 deletions(-)
>  create mode 100644 board/samsung/nuri/Makefile
>  create mode 100644 board/samsung/nuri/lowlevel_init.S
>  create mode 100644 board/samsung/nuri/nuri.c
>  create mode 100644 include/configs/exynos4_nuri.h
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 576fea8..aa1fc15 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -724,6 +724,10 @@ Valentin Longchamp 
>   km_kirkwood ARM926EJS (Kirkwood SoC)
>   portl2  ARM926EJS (Kirkwood SoC)
> 
> +Łukasz Majewski 
> +
> + exynos4_nuriARM ARMV7 (S5PC210 SoC)
> +
>  Nishanth Menon 
> 
>   omap3_sdp3430   ARM ARMV7 (OMAP3xx SoC)
> diff --git a/board/samsung/nuri/Makefile b/board/samsung/nuri/Makefile
> new file mode 100644
> index 000..27566de
> --- /dev/null
> +++ b/board/samsung/nuri/Makefile
> @@ -0,0 +1,45 @@
> +#
> +# Copyright (C) 2010 Samsung Electronics
> +# Minkyu Kang 
> +#
> +# 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
> +
> +COBJS-y  := nuri.o
> +SOBJS:= lowlevel_init.o
> +
> +SRCS:= $(SOBJS:.o=.S) $(COBJS-y:.o=.c)
> +OBJS := $(addprefix $(obj),$(COBJS-y))
> +SOBJS:= $(addprefix $(obj),$(SOBJS))
> +
> +$(LIB):  $(obj).depend $(SOBJS) $(OBJS)
> + $(call cmd_link_o_target, $(SOBJS) $(OBJS))
> +
> +#
> +
> +# defines $(obj).depend target
> +include $(SRCTREE)/rules.mk
> +
> +sinclude $(obj).depend
> +
> +#
> diff --git a/board/samsung/nuri/lowlevel_init.S
> b/board/samsung/nuri/lowlevel_init.S new file mode 100644
> index 000..67635bb
> --- /dev/null
> +++ b/board/samsung/nuri/lowlevel_init.S
> @@ -0,0 +1,395 @@
> +/*
> + * Lowlevel setup for universal board based on S5PC210
> + *
> + * Copyright (C) 2010 Samsung Electronics
> + * Kyungmin Park 
> + *
> + * See file CREDITS for list of people who contributed to this
> + * project.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of
> + * the License, or (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
> + * MA 02111-1307 USA
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/

Re: [U-Boot] [PATCH] disk: part_efi: Fix parameters passed to is_gpt_valid().

[Detlev Zundel]

Hi Thierry,

> * Stefano Babic wrote:
>> On 11/17/2011 08:56 AM, Thierry Reding wrote:
>> 
>> > I had actually set "Doug Anderson " on Cc 
>> > because he was involved with the initial patch but for some reason 
>> > he got stripped from Cc. Does anybody know why this is happening?
>> 
>> Probably Doug has received the first e-mail. I noted that git
>> send-email strips the CC addresses (maybe to avoid SPAM ?), but the
>> e-mail is sent anyway.
>
> I don't think git send-email is stripping the Cc header because I've seen it
> work properly for other mailing lists. Perhaps the mailing list software is
> the culprit here? Could it be that it strips people that are subscribed (and
> will receive the mails anyway) but not those that aren't subscribed? Not that
> Tom Warren wasn't stripped from Cc.

Actually I know that sometimes there are such phenomena on the mailing
list, but as yet I failed to find a reason for it.  What I saw in the
past is that the CC field of individual mails sent to individual
subscribers has a reduced CC field with respect to the original mail,
i.e. a mail I received had a stripped header compared to what is in the
archives.

I will try to look into this when I find some time.

Cheers
  Detlev

-- 
Whatever you do will be insignificant,
but it is very important that you do it.
-- Mahatma Gandhi
--
DENX Software Engineering GmbH,  MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [u-boot]automatic reset of variables to defaults

[Jerry Van Baren]

On 11/17/2011 10:46 AM, Dennis Borgmann wrote:
> Hello u-boot users list,
>
> I am experiencing a problem concerning variables being set and later
> getting lost.

This sounds like your environment variables in flash got erased or 
corrupted.  The question is why.

Where is your u-boot env being saved?  Normal flash?  I2C-attached 
flash?  Other?  (I2C flash is inherently less robust than we like due to 
weaknesses in the protocol.)

I am assuming normal flash...
* Do you have flash write protection enabled (prevents inadvertent flash 
scribbling, especially a problem if your linux or programs are not stable).

* Do you understand your flash memory layout (can you draw a diagram of 
it)?  Is something like a flash file system inadvertently overlayed on 
top of the u-boot env?  If you have a flash file system inadvertently 
configured to use the same memory space as your u-boot env, it will 
"randomly" overwrite it based on file activity.

* Do you use linux utilities to read/write your u-boot env?

When the failure occurs, what does the memory dump of the actual u-boot 
flash storage area look like?  Quite often the overwrite pattern leaves 
valuable clues as to who did it.

* If it is all 0xFF, someone just erased it.

* If some bits are set to zero that should be ones, someone probably did 
an inadvertent write to the memory (writing a '0' to a '1' bit turns it 
to a '0', writing a '0' or '1' to a '0' bit doesn't change it).

* Does it look like file data?

[snip]

> Annoyingly, I cannot surely reproduce this error. I tried rebooting it
> over 3 days in 2-minute-steps and the error won't occur. In addition, I
> tried giving random input to the console of u-boot for 3 days (again in
> 2-minute-steps) and still the error won't come up.

We've all been there and feel your pain. :-(

> Two questions:
>
> 1. What else might be the cause of this?

Someone (likely software, possibly hardware) is corrupting or erasing 
your u-boot env storage in flash.

> 2. How could I prevent u-boot from resetting to its default value?

Fix whoever is doing the scribbling.  There is no other way.

> I'd be happy for any kind of help.
>
> Best regards,
> Dennis

Good luck,
gvb
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [u-boot]automatic reset of variables to defaults

[Marek Vasut]

> Hello u-boot users list,
> 
> I am experiencing a problem concerning variables being set and later
> getting lost.
> 
> In order to boot a Linux on a quite small plattform (Eddy CPU:
> http://sysbas.en.ec21.com/Embedded_CPU_Module--1904028_1904479.html ), I
> have to reset the variable "OS_SDRAM" from its initial value of
> "0x2000" to "0x2100". If I don't do so, the bootloader reports
> problems extracting my kernel. This must be due to my kernel being
> bigger than expected by u-boot.
> 
> These are the steps, that I take:
> 
> [code]
> setenv OS_SDRAM 0x2100
> saveenv
> reset
> [/code]
> 
> Anyway, this way, it works fine.
> 
> Sometimes, the bootloader looses this configuration and resets its
> variable "OS_SDRAM" back to its default value. Once, the bootloader has
> reset this value, it cannot boot anymore(well, of course not, since I
> had to manually alter this value in order to make it boot my linux).
> 
> Annoyingly, I cannot surely reproduce this error. I tried rebooting it
> over 3 days in 2-minute-steps and the error won't occur. In addition, I
> tried giving random input to the console of u-boot for 3 days (again in
> 2-minute-steps) and still the error won't come up.

Probably something's overwriting your uboot in ram. Anyway, is the board 
supported mainline?

> 
> Two questions:
> 
> 1. What else might be the cause of this?
> 
> 2. How could I prevent u-boot from resetting to its default value?
> 
> I'd be happy for any kind of help.
> 
> Best regards,
> Dennis

Try getting mainline support for the board, that way you'll have the latest 
fixes.

M
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v9 2/4] gpio: Replace ARM gpio.h with the common API in include/asm-generic

[Joe Hershberger]

On Fri, Nov 11, 2011 at 5:07 PM, Kim Phillips
 wrote:
> On Fri, 11 Nov 2011 15:55:36 -0600
> Joe Hershberger  wrote:
>
>> ARM boards should use the generic GPIO API
>> This means changing gpio to unsigned type
>> Remove the unused gpio_toggle() function which is not part of the API
>> Comment that free should not modify pin state
>>
>> Signed-off-by: Joe Hershberger 
>> Cc: Joe Hershberger 
>> Cc: Kim Phillips 
>> Cc: Albert ARIBAUD 
>> ---
>
> I've tested this series on the 8313, and I'm ok with it going in:
>
> Acked-by: Kim Phillips 
>
> I need an ack from the ARM GPIO guys to apply it though (assuming it
> is to go through 83xx).

It has been Acked by ARM guys several times in several forms.  It's
pretty straightforward.  Not sure if Albert was planning to look at
this again.

-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [STATUS] Custodians - please lend a hand

[Detlev Zundel]

Hi Stefano,

> On 11/16/2011 07:51 PM, Wolfgang Denk wrote:
>
> Wolfgang,
>
>>>
>>> Please let's try if this works.  If you have any suggestions how to
>>> help better, please don't hesitate to tell us.
>
> I have tried with a couple of patches (network related), and then I 
> wanted to test if push works. As u-boot-staging should be open for all 
> custodians, I was expecting I should use the same mechanism, and then I 
> tried with:
>
>
> git push ssh://gu-...@git.denx.de/u-boot-staging sba...@denx.de
>
> ...but the new branch sba...@denx.de is now part of u-boot-imx, not 
> u-boot-staging ! Where is the mistake ?

Indeed - this is because of the setup of the custodian trees.  The git
action is directly coupled to the user account so the account gu-imx
will _only_ be able to work inside that tree.  Effectively, the
directory part of the URL is discarded...

The correct usage is of course as Wolfgang points out through the
gu-staging user.

Best wishes
  Detlev

-- 
Due to the change in scope, STUN has also been renamed from "Simple Traversal
of UDP through NAT" to  "Session  Traversal Utilities for NAT".   The acronym
remains STUN, which is all anyone ever remembers anyway.-- rfc5389
--
DENX Software Engineering GmbH,  MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] Efika: Configure additional regulators for HDMI output

[Jana Rapava]

2011/11/17 Marek Vasut 

>
> Jana, you have efikamx and I can get you HDMI cable. Can you recheck
> tomorrow ?
>
> M
>

Ok, I can.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [u-boot]automatic reset of variables to defaults

[Wolfgang Denk]

Dear Dennis Borgmann,

In message <4ec52bd7.2090...@googlemail.com> you wrote:
> 
> I am experiencing a problem concerning variables being set and later 
> getting lost.

It is impossible to comment on this without knowing _anything_ about
your system - which exact version of U-boot you are running
(well, obviously it is an ot-of-tree port, so it's twice impossible to
help), which CPU / SoC tthis is, which board, etc.

> These are the steps, that I take:
> 
> [code]
> setenv OS_SDRAM 0x2100

This makes no sense to me, as none of the mainline versions of U-Boot
uses such a setting.

> Sometimes, the bootloader looses this configuration and resets its 
> variable "OS_SDRAM" back to its default value. Once, the bootloader has 

What are the exact circumstances and especially the exct error
messages when this happens?

Where is the environment stored on your board? [In NOR or NAND flash
or ... ?]

Are you using redundant environment?

> 1. What else might be the cause of this?

We don't know your code, so how could we comment?

> 2. How could I prevent u-boot from resetting to its default value?

We don;t understand the nature of the problem, so how could we
recommend a cure?

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
HANDLE WITH EXTREME CARE:  This Product Contains  Minute Electrically
Charged  Particles  Moving  at  Velocities  in Excess of Five Hundred
Million Miles Per Hour.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Question about baud rate

[djantzen]

> Why doe you want to setup this parameters "from the outside"?  Really
> only the serial device used for a console needs to be setup by
> firmware.  All other serial devices should be initialized by the user
> space programs using them.

I would like my startup script to cat messages to ttyS1, as well as to 
the console (ttyS0). Basically for the purpose of informing users that 
the firmware cannot execute for some reason (we don't like to give 
access to the console). I was trying to avoid including stty or 
setserial, but if this is the accepted way to configure the serial port 
it's not a big deal ;-)

>> For each of the three uarts, the device tree has the following line:
>>
>> current-speed = <0>; /* Filled in by U-Boot */
>
> Checking current U-Boot code, I believe this comment is simply wrong. 
> I
> cannot see any part in the canyonlands / or generic 4xx 
> infrastructure
> that fixes up these properties.  Maybe Stefan can comment on this
> though.
>

Interesting...I also tried manually entering a value here, but it 
didn't seem to have any effect. Maybe it just isn't used?

>> Sorry for the silly question!
>
> I don;t think its a silly question, but I also think that you do not
> need the configuration ;)
>
> Cheers
>   Detlev

Thanks for your response!

Regards,
Dan

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 1/4] tegra2: Move tegra2_mmc_init() prototype to public header.

[Stephen Warren]

Thierry Reding wrote at Thursday, November 17, 2011 3:10 AM:
> tegra2_mmc_init() is implemented by the Tegra2 MMC driver. Since most of
> the Tegra2-based boards will need to call it, this commit exports it in
> the new public asm/arch/mmc.h header file to prevent each board from
> providing its own prototype.
> 
> Signed-off-by: Thierry Reding 

This 1 patch,

Acked-by: Stephen Warren 
Tested-by: Stephen Warren 

Thanks for cleaning this up.

-- 
nvpublic

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/6] arm: Remove jornada link script

[Marek Vasut]

> This link script seems old and incompatible with relocation and its
> own sa1000 start.S file. It isn't used because the CPU's link script
> was picked up in preference to this.
> 
> Signed-off-by: Simon Glass 
> ---
>  board/jornada/u-boot.lds |   58
> -- 1 files changed, 0
> insertions(+), 58 deletions(-)
>  delete mode 100644 board/jornada/u-boot.lds
> 
> diff --git a/board/jornada/u-boot.lds b/board/jornada/u-boot.lds
> deleted file mode 100644
> index c75b21f..000
> --- a/board/jornada/u-boot.lds
> +++ /dev/null
> @@ -1,58 +0,0 @@
> -/*
> - * (C) Copyright 2000-2004
> - * Wolfgang Denk, DENX Software Engineering, w...@denx.de.
> - * 2004 (c) MontaVista Software, Inc.
> - *
> - * See file CREDITS for list of people who contributed to this
> - * project.
> - *
> - * This program is free software; you can redistribute it and/or
> - * modify it under the terms of the GNU General Public License as
> - * published by the Free Software Foundation; either version 2 of
> - * the License, or (at your option) any later version.
> - *
> - * This program is distributed in the hope that it will be useful,
> - * but WITHOUT ANY WARRANTY; without even the implied warranty of
> - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> - * GNU General Public License for more details.
> - *
> - * You should have received a copy of the GNU General Public License
> - * along with this program; if not, write to the Free Software
> - * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
> - * MA 02111-1307 USA
> - */
> -
> -OUTPUT_FORMAT("elf32-littlearm", "elf32-littlearm", "elf32-littlearm")
> -OUTPUT_ARCH(arm)
> -ENTRY(_start)
> -SECTIONS
> -{
> - . = 0x;
> -
> - . = ALIGN(4);
> - .text :
> - {
> - cpu/sa1100/start.o  (.text)
> - *(.text)
> - }
> -
> - . = ALIGN(4);
> - .rodata : { *(SORT_BY_ALIGNMENT(SORT_BY_NAME(.rodata*))) }
> -
> - . = ALIGN(4);
> - .data : { *(.data) }
> -
> - . = ALIGN(4);
> - .got : { *(.got) }
> -
> -
> - . = .;
> - __u_boot_cmd_start = .;
> - .u_boot_cmd : { *(.u_boot_cmd) }
> - __u_boot_cmd_end = .;
> -
> - . = ALIGN(4);
> - __bss_start = .;
> - .bss (NOLOAD) : { *(.bss) . = ALIGN(4); }
> - __bss_end__ = .;
> -}

Please CC jornada guy next time. Anyway, it looks ok to me, but IMO needs some 
testing.

M
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 0/2] tegra2: Fixes for running mainline U-Boot.

[Stephen Warren]

Thierry Reding wrote at Thursday, November 17, 2011 3:04 AM:
> The following series contains two patches that allow mainline U-Boot to
> boot standalone on Tegra2-based boards. It assumes the standard NVIDIA
> flashing tools as provided by the Linux4Tegra package. The series is
> based on patches that have already been reviewed but haven't been merged
> upstream yet. They are available in patchwork here:
> 
>   http://patchwork.ozlabs.org/patch/122888
>   http://patchwork.ozlabs.org/patch/122887
>   http://patchwork.ozlabs.org/patch/122889
>   http://patchwork.ozlabs.org/patch/123845 (9 patches)
> 
> Thierry Reding (2):
>   tegra2: Always build with USE_PRIVATE_LIBGCC=yes.
>   tegra2: Change CONFIG_SYS_TEXT_BASE to 0x00108000.

The series:

Tested-by: Stephen Warren 
Acked-by: Stephen Warren 

(On Seaboard/Springbank, booted a Linux kernel)

Thanks for cleaning this up.

-- 
nvpublic

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] uboot

[Detlev Zundel]

Hi,

> I am trying to boot beagle board by uart
> can anybody help me on this issue?

I am sorry but I do not understand what you are trying to do.  Can you
please explain a bit more on what you want to do and what is not
working?  A good question[1] is the prerequisite for a good answer ;)

Cheers
  Detlev

[1] http://catb.org/~esr/faqs/smart-questions.html

-- 
Due to the change in scope, STUN has also been renamed from "Simple Traversal
of UDP through NAT" to  "Session  Traversal Utilities for NAT".   The acronym
remains STUN, which is all anyone ever remembers anyway.-- rfc5389
--
DENX Software Engineering GmbH,  MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] Efika: Configure additional regulators for HDMI output

[Marek Vasut]

> On 09/28/2011 02:19 PM, Marek Vasut wrote:
> > Signed-off-by: Marek Vasut
> > Cc: Stefano Babic
> > ---
> > 
> >   board/efikamx/efikamx.c |   16 +++-
> >   1 files changed, 11 insertions(+), 5 deletions(-)
> > 
> > diff --git a/board/efikamx/efikamx.c b/board/efikamx/efikamx.c
> > index 29fff72..276753c 100644
> > --- a/board/efikamx/efikamx.c
> > +++ b/board/efikamx/efikamx.c
> > @@ -222,7 +222,7 @@ static void power_init(void)
> 
> Hi Marek,
> 
> sorry, I missed this patch - I rebased myself on the actual u-boot-imx,
> and I applied it. Can you take a look at it to check if it is still ok ?
> 
> Applied to u-boot-imx, thanks.
> Best regards,
> Stefano Babic

Jana, you have efikamx and I can get you HDMI cable. Can you recheck tomorrow ?

M
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 20/20] M28EVK: Enable USB HOST support

[Marek Vasut]

> Marek Vasut wrote:
> >> Marek Vasut wrote:
>  Marek Vasut wrote:
> >> Hi Marek,
> >> 
> >> u-boot-v2011.09 doesn't support for imx28. I need complete support
> >> patch for mx28. where can i get those patches?
> >> 
> >> for which version of u-boot this patches supports..?
> >> 
> >> 
> >> Regards,
> >> Manoj
> > 
> > http://git.denx.de/?p=u-boot/u-boot-imx.git;a=summary
> > 
> > M
>  
>  Thanks Marek,
>  Patches applied..
>  on usb start command i'm getting "scanning bus for devices... New
>  Device 0" then its freezes after  getting the debug message
>  "enabling power on all ports
>  usb_control_msg: request: 0x3, requesttype: 0x23, value 0x8 index 0x1
>  length 0x0"
>  can u help me on this further?
>  
>  Regards,
>  Manoj
> >>> 
> >>> There is a mail with subject "[U-Boot] [PATCH] GCC4.6: Fix common/usb.c
> >>> on xscale" in uboot ML ... apply the patch and retry. What GCC do you
> >>> use?
> >>> 
> >>> M
> >> 
> >> Hello Marek,
> >> 
> >> I'm using
> >> u-boot version : u-boot-imx
> >> 
> >> gcc version:4.3.3
> >> 
> >> When i try to add this Patch "[U-Boot] [PATCH] GCC4.6: Fix common/usb.c
> >> on xscale"
> >> I'm getting:
> >> patching file usb.c
> >> Hunk #1 FAILED at 263.
> >> Hunk #2 FAILED at 313.
> >> 2 out of 2 hunks FAILED -- saving rejects to file usb.c.rej
> >> 
> >> then i made some changes for common/usb.c as per the patch,even it gets
> >> freezes after printing the debug msg.
> >> "enabling power on all ports
> >> usb_control_msg: request: 0x3, requesttype: 0x23, value 0x8 index 0x1
> >> length 0x0"
> >> 
> >> Regards,
> >> Manoj
> > 
> > Are you using top-of-the-tree u-boot-imx/master? You shouldn't need to
> > apply any patches. That'd explain why you're getting errors applying the
> > last USB patch I suggested.
> > 
> > Also, please try ELDK5.0 toolchain.
> > 
> > M
> 
> Marek,
> 
> ya i'm using master code and now its working fine..

Is it because of "[U-Boot] [PATCH] GCC4.6: Fix common/usb.c on xscale" or 
ELDK5.0 or Using u-boot/master ? What did you change?

Anyway, it's good to hear!!

M
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] arm/pxa: fix and cleanup of pxa_mem_setup macro v2

[Marek Vasut]

> WARNING: This macro do not assume the values for K0DB4, KxDB2, KxFREE,
>  K1RUN, K2RUN and APD bits of CONFIG_SYS_MDREFR_VAL as it was
>  done early on many pxa platforms. All pxa developers that plan
>  to use this macro should check the validity of their MDREFR
> values.
> 
> v1:
>   * strict following to section 6.4.10 of Intel PXA27xx Developer's Manual.
>   * use r7 to store CONFIG_SYS_MDREFR_VAL as r6 is used in pxa_wait_ticks.
> 
> v2:
>   * rename pxa_mem_setup macro to pxa2xx_mem_setup
>   * setting of MDREFR[K1RUN] and MDREFR[K2RUN] bits may be optional
>   * skip certain configuration steps if SDRAM is not present/configured
>   * improve/fix comments

Hi, was there any final conclusion on this one ? It seems it was superseded by 
changes in uboot?

M
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Question about baud rate

[Detlev Zundel]

Hi Dan,

> I'm using a board similar to canyonlands with a ppc460ex. The baud rate 
> for ttyS0 is set to 115200 by the console= bootarg, but I'd also like to 
> set ttyS1-3 to 115200 also.

Why doe you want to setup this parameters "from the outside"?  Really
only the serial device used for a console needs to be setup by
firmware.  All other serial devices should be initialized by the user
space programs using them.

> For each of the three uarts, the device tree has the following line:
>
> current-speed = <0>; /* Filled in by U-Boot */

Checking current U-Boot code, I believe this comment is simply wrong.  I
cannot see any part in the canyonlands / or generic 4xx infrastructure
that fixes up these properties.  Maybe Stefan can comment on this
though.

> How do I go about configuring u-boot to fill these with the baud rate I 
> choose?
>
> Sorry for the silly question!

I don;t think its a silly question, but I also think that you do not
need the configuration ;)

Cheers
  Detlev

-- 
One of the main causes of the fall of the Roman Empire was that, lacking zero,
they had no way to indicate successful termination of their C programs.
-- Robert Firth
--
DENX Software Engineering GmbH,  MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] disk: part_efi: Fix parameters passed to is_gpt_valid().

[Doug Anderson]

Agreed--I see myself in the CC from the start.

Thanks for Stephen to pointing to the fix that he already posted.

-Doug

---

On Thu, Nov 17, 2011 at 9:02 AM, Tom Warren  wrote:

> Doug is in the CC field (via Outlook in my 'U-Boot' folder @ work), and
> has been for every message in this thread.
>
> > -Original Message-
> > From: Thierry Reding [mailto:thierry.red...@avionic-design.de]
> > Sent: Thursday, November 17, 2011 8:08 AM
> > To: Stefano Babic
> > Cc: Tom Warren; Doug Anderson; u-boot@lists.denx.de
> > Subject: Re: [U-Boot] [PATCH] disk: part_efi: Fix parameters passed to
> > is_gpt_valid().
> >
> > * PGP Signed by an unknown key
> >
> > * Stefano Babic wrote:
> > > On 11/17/2011 08:56 AM, Thierry Reding wrote:
> > >
> > > > I had actually set "Doug Anderson " on Cc
> > > > because he was involved with the initial patch but for some reason
> > > > he got stripped from Cc. Does anybody know why this is happening?
> > >
> > > Probably Doug has received the first e-mail. I noted that git
> > > send-email strips the CC addresses (maybe to avoid SPAM ?), but the
> > > e-mail is sent anyway.
> >
> > I don't think git send-email is stripping the Cc header because I've
> seen it
> > work properly for other mailing lists. Perhaps the mailing list software
> is
> > the culprit here? Could it be that it strips people that are subscribed
> (and
> > will receive the mails anyway) but not those that aren't subscribed? Not
> > that
> > Tom Warren wasn't stripped from Cc.
> >
> > Thierry
> >
> > * Unknown Key
> > * 0xA2E3269F
>
> ---
> This email message is for the sole use of the intended recipient(s) and
> may contain
> confidential information.  Any unauthorized review, use, disclosure or
> distribution
> is prohibited.  If you are not the intended recipient, please contact the
> sender by
> reply email and destroy all copies of the original message.
>
> ---
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] disk: part_efi: Fix parameters passed to is_gpt_valid().

[Premi, Sanjeev]

> -Original Message-
> From: u-boot-boun...@lists.denx.de 
> [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Thierry Reding
> Sent: Thursday, November 17, 2011 12:35 PM
> To: u-boot@lists.denx.de
> Cc: Tom Warren
> Subject: [U-Boot] [PATCH] disk: part_efi: Fix parameters 
> passed to is_gpt_valid().
> 
> Something apparently went wrong when the patch in commit deb5ca8 was
> applied. Commit f75dd58 changed the type of gpt_head to be a 
> pointer and
> correctly adjusted the calls to is_gpt_valid(). But when deb5ca8 got
> applied, the gpt_head was again reverted to &(gpt_head), which was the
> state before deb5ca8.
> 
> This commit fixes the passing of gpt_head into is_gpt_valid().
> 
> Signed-off-by: Thierry Reding 
> ---
>  disk/part_efi.c |4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/disk/part_efi.c b/disk/part_efi.c
> index e7f2714..ddf80a7 100644
> --- a/disk/part_efi.c
> +++ b/disk/part_efi.c
> @@ -130,7 +130,7 @@ void print_part_efi(block_dev_desc_t * dev_desc)
>   }
>   /* This function validates AND fills in the GPT header 
> and PTE */
>   if (is_gpt_valid(dev_desc, GPT_PRIMARY_PARTITION_TABLE_LBA,
> -  &(gpt_head), &gpt_pte) != 1) {
> +  gpt_head, &gpt_pte) != 1) {
>   printf("%s: *** ERROR: Invalid GPT ***\n", __func__);
>   return;
>   }
> @@ -169,7 +169,7 @@ int 
> get_partition_info_efi(block_dev_desc_t * dev_desc, int part,
>  
>   /* This function validates AND fills in the GPT header 
> and PTE */
>   if (is_gpt_valid(dev_desc, GPT_PRIMARY_PARTITION_TABLE_LBA,
> - &(gpt_head), &gpt_pte) != 1) {
> + gpt_head, &gpt_pte) != 1) {
>   printf("%s: *** ERROR: Invalid GPT ***\n", __func__);
>   return -1;
>   }
> -- 

I had already posted 2 revisions of this patch:

http://lists.denx.de/pipermail/u-boot/2011-November/109791.html
http://lists.denx.de/pipermail/u-boot/2011-November/109899.html

And they are included in this pull request:

http://lists.denx.de/pipermail/u-boot/2011-November/110017.html


> 1.7.7.3
> 
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] tegra2: Fix out-of-tree build for Ventana.

[Stephen Warren]

Thierry Reding wrote at Thursday, November 17, 2011 2:48 AM:
> Since Ventana is derived from Seaboard and requires seaboard.c to build,
> make sure board/nvidia/seaboard is created in the build tree.
> 
> Signed-off-by: Thierry Reding 

Acked-by: Stephen Warren 
Tested-by: Stephen Warren 

-- 
nvpublic

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] disk: part_efi: Fix parameters passed to is_gpt_valid().

[Tom Warren]

Doug is in the CC field (via Outlook in my 'U-Boot' folder @ work), and has 
been for every message in this thread.

> -Original Message-
> From: Thierry Reding [mailto:thierry.red...@avionic-design.de]
> Sent: Thursday, November 17, 2011 8:08 AM
> To: Stefano Babic
> Cc: Tom Warren; Doug Anderson; u-boot@lists.denx.de
> Subject: Re: [U-Boot] [PATCH] disk: part_efi: Fix parameters passed to
> is_gpt_valid().
> 
> * PGP Signed by an unknown key
> 
> * Stefano Babic wrote:
> > On 11/17/2011 08:56 AM, Thierry Reding wrote:
> >
> > > I had actually set "Doug Anderson " on Cc
> > > because he was involved with the initial patch but for some reason
> > > he got stripped from Cc. Does anybody know why this is happening?
> >
> > Probably Doug has received the first e-mail. I noted that git
> > send-email strips the CC addresses (maybe to avoid SPAM ?), but the
> > e-mail is sent anyway.
> 
> I don't think git send-email is stripping the Cc header because I've seen it
> work properly for other mailing lists. Perhaps the mailing list software is
> the culprit here? Could it be that it strips people that are subscribed (and
> will receive the mails anyway) but not those that aren't subscribed? Not
> that
> Tom Warren wasn't stripped from Cc.
> 
> Thierry
> 
> * Unknown Key
> * 0xA2E3269F
---
This email message is for the sole use of the intended recipient(s) and may 
contain
confidential information.  Any unauthorized review, use, disclosure or 
distribution
is prohibited.  If you are not the intended recipient, please contact the 
sender by
reply email and destroy all copies of the original message.
---
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v4] Improve Power Management in SMC911X driver.

[Stefano Babic]

On 11/17/2011 05:21 PM, Igor Grinberg wrote:

>>
>> Agree, this is the correct behavior. However, checkpatch report errors
>> (due to leading white space instead of tabs in the comment you added):
> 
> Are you sure you are testing the right version (v4)?
> Because, I get different errors/warnings on that patch (see below)

The right version, yes. Maybe I have a an old checkpatch.pl, I must
update it.


> 
> 
> Anyway, those need to be fixed.
> 

Right.

-- 
=
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: off...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] disk: part_efi: Fix parameters passed to is_gpt_valid().

[Thierry Reding]

* Stephen Warren wrote:
> Thierry Reding wrote at Thursday, November 17, 2011 12:05 AM:
> > Something apparently went wrong when the patch in commit deb5ca8 was
> > applied. Commit f75dd58 changed the type of gpt_head to be a pointer and
> > correctly adjusted the calls to is_gpt_valid(). But when deb5ca8 got
> > applied, the gpt_head was again reverted to &(gpt_head), which was the
> > state before deb5ca8.
> > 
> > This commit fixes the passing of gpt_head into is_gpt_valid().
> 
> I already posted this patch a while back:
> http://patchwork.ozlabs.org/patch/122485/

I wasn't aware of that. Please ignore then.

Thierry


pgp7j29ElXzll.pgp
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v4] Improve Power Management in SMC911X driver.

[Igor Grinberg]

Hi Stefano, Bertrand,

On 11/17/11 17:52, Stefano Babic wrote:
> On 11/15/2011 02:40 PM, Bertrand Cachet wrote:
>> From datasheet, when READY bit is set inside PM_CTRL register, it means that
>> device is already in *normal* (D0) mode => it doesn't need to be wake-up.
>>
>> With this patch, we only wake-up (writing on TEST_BYTE register) if PM_MODE
>> bits of PM_CTRL register is in sleep (D1/D2) mode.
>>
>> Signed-off-by: Bertrand Cachet 
>> ---
>>  v2: Improve code styling by grouping two narrow comments.
>>  v3: Place versions information under scissors line.
>>  v4: Use tabs instead of spaces (vimrc problem)
>>
>>  drivers/net/smc911x.h |7 +--
>>  1 files changed, 5 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/net/smc911x.h b/drivers/net/smc911x.h
>> index 8ce08a9..a290073 100644
>> --- a/drivers/net/smc911x.h
>> +++ b/drivers/net/smc911x.h
>> @@ -471,8 +471,11 @@ static void smc911x_reset(struct eth_device *dev)
>>  {
>>  int timeout;
>>  
>> -/* Take out of PM setting first */
>> -if (smc911x_reg_read(dev, PMT_CTRL) & PMT_CTRL_READY) {
>> +/*
>> + *  Take out of PM setting first
>> + *  Device is already wake up if PMT_CTRL_READY bit is set
>> + */
>> +if ((smc911x_reg_read(dev, PMT_CTRL) & PMT_CTRL_READY) == 0) {
>>  /* Write to the bytetest will take out of powerdown */
>>  smc911x_reg_write(dev, BYTE_TEST, 0x0);
> 
> Agree, this is the correct behavior. However, checkpatch report errors
> (due to leading white space instead of tabs in the comment you added):

Are you sure you are testing the right version (v4)?
Because, I get different errors/warnings on that patch (see below)

> 
> ERROR: code indent should use tabs where possible
> #29: FILE: drivers/net/smc911x.h:475:
> + ^I *  Take out of PM setting first$
> 
> WARNING: please, no space before tabs
> #29: FILE: drivers/net/smc911x.h:475:
> + ^I *  Take out of PM setting first$
> 
> ERROR: code indent should use tabs where possible
> #30: FILE: drivers/net/smc911x.h:476:
> + ^I *  Device is already wake up if PMT_CTRL_READY bit is set$
> 
> WARNING: please, no space before tabs
> #30: FILE: drivers/net/smc911x.h:476:
> + ^I *  Device is already wake up if PMT_CTRL_READY bit is set$
> 
> total: 2 errors, 2 warnings, 13 lines checked
> 
> NOTE: whitespace errors detected, you may wish to use scripts/cleanpatch or
>   scripts/cleanfile
> 


My checkpatch.pl reports:
cut
ERROR: trailing whitespace
#133: FILE: drivers/net/smc911x.h:474:
+^I/*^M$

ERROR: trailing whitespace
#134: FILE: drivers/net/smc911x.h:475:
+^I *  Take out of PM setting first^M$

ERROR: trailing whitespace
#135: FILE: drivers/net/smc911x.h:476:
+^I *  Device is already wake up if PMT_CTRL_READY bit is set^M$

ERROR: DOS line endings
#136: FILE: drivers/net/smc911x.h:477:
+^I */^M$

ERROR: DOS line endings
#137: FILE: drivers/net/smc911x.h:478:
+^Iif ((smc911x_reg_read(dev, PMT_CTRL) & PMT_CTRL_READY) == 0) {^M$

total: 5 errors, 0 warnings, 13 lines checked
---cut-


Anyway, those need to be fixed.

-- 
Regards,
Igor.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] disk: part_efi: Fix parameters passed to is_gpt_valid().

[Stephen Warren]

Thierry Reding wrote at Thursday, November 17, 2011 12:05 AM:
> Something apparently went wrong when the patch in commit deb5ca8 was
> applied. Commit f75dd58 changed the type of gpt_head to be a pointer and
> correctly adjusted the calls to is_gpt_valid(). But when deb5ca8 got
> applied, the gpt_head was again reverted to &(gpt_head), which was the
> state before deb5ca8.
> 
> This commit fixes the passing of gpt_head into is_gpt_valid().

I already posted this patch a while back:
http://patchwork.ozlabs.org/patch/122485/

-- 
nvpublic

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2 04/17] env: move extern environment[] to environment.h

[Igor Grinberg]

Extract all extern declarations for environment out of c files
into the environment.h header.

Signed-off-by: Igor Grinberg 
---
v2: fix compilation for envcrc.c by including environment.h
(Thanks Stefano)

 common/env_flash.c|4 +---
 common/env_mmc.c  |3 +--
 common/env_nand.c |3 +--
 common/env_onenand.c  |6 +-
 include/environment.h |4 
 tools/envcrc.c|5 +++--
 6 files changed, 11 insertions(+), 14 deletions(-)

diff --git a/common/env_flash.c b/common/env_flash.c
index 1383f3c..a32bfcf 100644
--- a/common/env_flash.c
+++ b/common/env_flash.c
@@ -49,9 +49,7 @@ DECLARE_GLOBAL_DATA_PTR;
 char * env_name_spec = "Flash";
 
 #ifdef ENV_IS_EMBEDDED
-
-extern uchar environment[];
-env_t *env_ptr = (env_t *)(&environment[0]);
+env_t *env_ptr = &environment;
 
 static env_t *flash_addr = (env_t *)CONFIG_ENV_ADDR;
 
diff --git a/common/env_mmc.c b/common/env_mmc.c
index a0c0ece..cb75887 100644
--- a/common/env_mmc.c
+++ b/common/env_mmc.c
@@ -35,8 +35,7 @@
 char *env_name_spec = "MMC";
 
 #ifdef ENV_IS_EMBEDDED
-extern uchar environment[];
-env_t *env_ptr = (env_t *)(&environment[0]);
+env_t *env_ptr = &environment;
 #else /* ! ENV_IS_EMBEDDED */
 env_t *env_ptr = NULL;
 #endif /* ENV_IS_EMBEDDED */
diff --git a/common/env_nand.c b/common/env_nand.c
index 94d4417..d975322 100644
--- a/common/env_nand.c
+++ b/common/env_nand.c
@@ -59,8 +59,7 @@ char *env_name_spec = "NAND";
 
 
 #if defined(ENV_IS_EMBEDDED)
-extern uchar environment[];
-env_t *env_ptr = (env_t *)(&environment[0]);
+env_t *env_ptr = &environment;
 #elif defined(CONFIG_NAND_ENV_DST)
 env_t *env_ptr = (env_t *)CONFIG_NAND_ENV_DST;
 #else /* ! ENV_IS_EMBEDDED */
diff --git a/common/env_onenand.c b/common/env_onenand.c
index b1f266b..c09fdf3 100644
--- a/common/env_onenand.c
+++ b/common/env_onenand.c
@@ -44,10 +44,6 @@ char *env_name_spec = "OneNAND";
 #define ONENAND_MAX_ENV_SIZE   4096
 #define ONENAND_ENV_SIZE(mtd)  (ONENAND_MAX_ENV_SIZE - ENV_HEADER_SIZE)
 
-#ifdef ENV_IS_EMBEDDED
-extern uchar environment[];
-#endif /* ENV_IS_EMBEDDED */
-
 DECLARE_GLOBAL_DATA_PTR;
 
 uchar env_get_char_spec(int index)
@@ -64,7 +60,7 @@ void env_relocate_spec(void)
int rc;
size_t retlen;
 #ifdef ENV_IS_EMBEDDED
-   char *buf = (char *)&environment[0];
+   char *buf = (char *)&environment;
 #else
loff_t env_addr = CONFIG_ENV_ADDR;
char onenand_env[ONENAND_MAX_ENV_SIZE];
diff --git a/include/environment.h b/include/environment.h
index 20775da..951803f 100644
--- a/include/environment.h
+++ b/include/environment.h
@@ -154,6 +154,10 @@ typedef struct environment_s {
unsigned char   data[ENV_SIZE]; /* Environment data */
 } env_t;
 
+#ifdef ENV_IS_EMBEDDED
+extern env_t environment;
+#endif /* ENV_IS_EMBEDDED */
+
 extern const unsigned char default_environment[];
 
 #ifndef DO_DEPS_ONLY
diff --git a/tools/envcrc.c b/tools/envcrc.c
index feebbab..111d9f6 100644
--- a/tools/envcrc.c
+++ b/tools/envcrc.c
@@ -61,6 +61,7 @@
 #endif /* CONFIG_ENV_IS_IN_FLASH */
 
 #if defined(ENV_IS_EMBEDDED) && !defined(CONFIG_BUILD_ENVCRC)
+# include 
 # define CONFIG_BUILD_ENVCRC 1
 #endif
 
@@ -77,7 +78,7 @@ extern uint32_t crc32 (uint32_t, const unsigned char *, 
unsigned int);
 
 #ifdef CONFIG_BUILD_ENVCRC
 extern unsigned int env_size;
-extern unsigned char environment;
+extern env_t environment;
 #endif /* CONFIG_BUILD_ENVCRC */
 
 int main (int argc, char **argv)
@@ -85,7 +86,7 @@ int main (int argc, char **argv)
 #ifdef CONFIG_BUILD_ENVCRC
unsigned char pad = 0x00;
uint32_t crc;
-   unsigned char *envptr = &environment,
+   unsigned char *envptr = (unsigned char *)&environment,
*dataptr = envptr + ENV_HEADER_SIZE;
unsigned int datasize = ENV_SIZE;
unsigned int eoe;
-- 
1.7.3.4

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v4] Improve Power Management in SMC911X driver.

[Stefano Babic]

On 11/15/2011 02:40 PM, Bertrand Cachet wrote:
> From datasheet, when READY bit is set inside PM_CTRL register, it means that
> device is already in *normal* (D0) mode => it doesn't need to be wake-up.
> 
> With this patch, we only wake-up (writing on TEST_BYTE register) if PM_MODE
> bits of PM_CTRL register is in sleep (D1/D2) mode.
> 
> Signed-off-by: Bertrand Cachet 
> ---
>  v2: Improve code styling by grouping two narrow comments.
>  v3: Place versions information under scissors line.
>  v4: Use tabs instead of spaces (vimrc problem)
> 
>  drivers/net/smc911x.h |7 +--
>  1 files changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/smc911x.h b/drivers/net/smc911x.h
> index 8ce08a9..a290073 100644
> --- a/drivers/net/smc911x.h
> +++ b/drivers/net/smc911x.h
> @@ -471,8 +471,11 @@ static void smc911x_reset(struct eth_device *dev)
>  {
>   int timeout;
>  
> - /* Take out of PM setting first */
> - if (smc911x_reg_read(dev, PMT_CTRL) & PMT_CTRL_READY) {
> + /*
> +  *  Take out of PM setting first
> +  *  Device is already wake up if PMT_CTRL_READY bit is set
> +  */
> + if ((smc911x_reg_read(dev, PMT_CTRL) & PMT_CTRL_READY) == 0) {
>   /* Write to the bytetest will take out of powerdown */
>   smc911x_reg_write(dev, BYTE_TEST, 0x0);

Agree, this is the correct behavior. However, checkpatch report errors
(due to leading white space instead of tabs in the comment you added):

ERROR: code indent should use tabs where possible
#29: FILE: drivers/net/smc911x.h:475:
+ ^I *  Take out of PM setting first$

WARNING: please, no space before tabs
#29: FILE: drivers/net/smc911x.h:475:
+ ^I *  Take out of PM setting first$

ERROR: code indent should use tabs where possible
#30: FILE: drivers/net/smc911x.h:476:
+ ^I *  Device is already wake up if PMT_CTRL_READY bit is set$

WARNING: please, no space before tabs
#30: FILE: drivers/net/smc911x.h:476:
+ ^I *  Device is already wake up if PMT_CTRL_READY bit is set$

total: 2 errors, 2 warnings, 13 lines checked

NOTE: whitespace errors detected, you may wish to use scripts/cleanpatch or
  scripts/cleanfile

Can you fix and repost (maybe setting me as CC, I will take care of your
patch).

Thanks,
Stefano Babic

-- 
=
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: off...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [u-boot]automatic reset of variables to defaults

[Dennis Borgmann]

Hello u-boot users list,

I am experiencing a problem concerning variables being set and later 
getting lost.

In order to boot a Linux on a quite small plattform (Eddy CPU: 
http://sysbas.en.ec21.com/Embedded_CPU_Module--1904028_1904479.html ), I 
have to reset the variable "OS_SDRAM" from its initial value of 
"0x2000" to "0x2100". If I don't do so, the bootloader reports 
problems extracting my kernel. This must be due to my kernel being 
bigger than expected by u-boot.

These are the steps, that I take:

[code]
setenv OS_SDRAM 0x2100
saveenv
reset
[/code]

Anyway, this way, it works fine.

Sometimes, the bootloader looses this configuration and resets its 
variable "OS_SDRAM" back to its default value. Once, the bootloader has 
reset this value, it cannot boot anymore(well, of course not, since I 
had to manually alter this value in order to make it boot my linux).

Annoyingly, I cannot surely reproduce this error. I tried rebooting it 
over 3 days in 2-minute-steps and the error won't occur. In addition, I 
tried giving random input to the console of u-boot for 3 days (again in 
2-minute-steps) and still the error won't come up.

Two questions:

1. What else might be the cause of this?

2. How could I prevent u-boot from resetting to its default value?

I'd be happy for any kind of help.

Best regards,
Dennis
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [u-boot]automatic reset of variables to defaults

[Dennis Borgmann]

Hello u-boot users list,

I am experiencing a problem concerning variables being set and later 
getting lost.

In order to boot a Linux on a quite small plattform (Eddy CPU: 
http://sysbas.en.ec21.com/Embedded_CPU_Module--1904028_1904479.html ), I 
have to reset the variable "OS_SDRAM" from its initial value of 
"0x2000" to "0x2100". If I don't do so, the bootloader reports 
problems extracting my kernel. This must be due to my kernel being 
bigger than expected by u-boot.

These are the steps, that I take:

[code]
setenv OS_SDRAM 0x2100
saveenv
reset
[/code]

Anyway, this way, it works fine.

Sometimes, the bootloader looses this configuration and resets its 
variable "OS_SDRAM" back to its default value. Once, the bootloader has 
reset this value, it cannot boot anymore(well, of course not, since I 
had to manually alter this value in order to make it boot my linux).

Annoyingly, I cannot surely reproduce this error. I tried rebooting it 
over 3 days in 2-minute-steps and the error won't occur. In addition, I 
tried giving random input to the console of u-boot for 3 days (again in 
2-minute-steps) and still the error won't come up.

Two questions:

1. What else might be the cause of this?

2. How could I prevent u-boot from resetting to its default value?

I'd be happy for any kind of help.

Best regards,
Dennis
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 03/17] env: move extern default_environment[] to environment.h

[Stefano Babic]

On 11/17/2011 04:14 PM, Igor Grinberg wrote:
> 
> I don't have the ppc cross tool chain at hand, can you tell me which
> ARM board(s) get broken, so I can verify this?
> 
> Also, I think it is not that patch but the next one:
> [PATCH 04/17] env: move extern environment[] to environment.h

You're right, but that was the result bisecting the tree.

> 
> Can you please check if the attached patch fixes the envcrc.c problem?

Yes, it is fixed - it is the missing environment.h. The board is built,
as well as the other powerpc boards (the ones I tested up now). Can you
resend only the [PATCH 04/17] ?

Thanks,
Stefano

-- 
=
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: off...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 03/17] env: move extern default_environment[] to environment.h

[Igor Grinberg]

Hi Stefano,

On 11/17/11 16:12, Stefano Babic wrote:
> On 11/07/2011 12:13 PM, Igor Grinberg wrote:
>> Extract all extern declarations for default_environment[] out of c files
>> into the environment.h header.
>>
>> Signed-off-by: Igor Grinberg 
>> Cc: Stefan Roese 
>> ---
>>  board/zeus/zeus.c  |1 -
>>  common/env_dataflash.c |2 --
>>  common/env_flash.c |2 --
>>  common/env_mgdisk.c|3 ---
>>  common/env_mmc.c   |3 ---
>>  common/env_nand.c  |3 ---
>>  common/env_nowhere.c   |2 --
>>  common/env_nvram.c |2 --
>>  common/env_onenand.c   |3 ---
>>  common/env_sf.c|3 ---
>>  include/environment.h  |2 ++
>>  11 files changed, 2 insertions(+), 24 deletions(-)
>>
> 
> Hi Igor,
> 
> this patch breaks several boards because "tools" cannot be compiled clean:
> 
> gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -idirafter
> /home/stefano/Projects/u-boot-staging/include -idirafter
> /home/stefano/Projects/u-boot-staging/include2 -idirafter
> /home/stefano/Projects/u-boot-staging/include -I
> /home/stefano/Projects/u-boot-staging/lib/libfdt -I
> /home/stefano/Projects/u-boot-staging/tools
> -DCONFIG_SYS_TEXT_BASE=0x0200 -DUSE_HOSTCC -D__KERNEL_STRICT_NAMES
> -pedantic   -o envcrc.o envcrc.c -c
> envcrc.c:80:1: Fehler: unbekannter Typname: »env_t«
> make[1]: *** [envcrc.o] Fehler 1
> 
> You can try with the cmi_mpc5xx board, but it is only an example - I get
> the same errors with several ARM boards, because at the end
> environment.h is not included. Can you take a look at it ?

I don't have the ppc cross tool chain at hand, can you tell me which
ARM board(s) get broken, so I can verify this?

Also, I think it is not that patch but the next one:
[PATCH 04/17] env: move extern environment[] to environment.h

Can you please check if the attached patch fixes the envcrc.c problem?

Thanks.

-- 
Regards,
Igor.
diff --git a/tools/envcrc.c b/tools/envcrc.c
index 12913c2..111d9f6 100644
--- a/tools/envcrc.c
+++ b/tools/envcrc.c
@@ -61,6 +61,7 @@
 #endif	/* CONFIG_ENV_IS_IN_FLASH */
 
 #if defined(ENV_IS_EMBEDDED) && !defined(CONFIG_BUILD_ENVCRC)
+# include 
 # define CONFIG_BUILD_ENVCRC 1
 #endif
 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] disk: part_efi: Fix parameters passed to is_gpt_valid().

[Thierry Reding]

* Stefano Babic wrote:
> On 11/17/2011 08:56 AM, Thierry Reding wrote:
> 
> > I had actually set "Doug Anderson " on Cc 
> > because he was involved with the initial patch but for some reason 
> > he got stripped from Cc. Does anybody know why this is happening?
> 
> Probably Doug has received the first e-mail. I noted that git
> send-email strips the CC addresses (maybe to avoid SPAM ?), but the
> e-mail is sent anyway.

I don't think git send-email is stripping the Cc header because I've seen it
work properly for other mailing lists. Perhaps the mailing list software is
the culprit here? Could it be that it strips people that are subscribed (and
will receive the mails anyway) but not those that aren't subscribed? Not that
Tom Warren wasn't stripped from Cc.

Thierry


pgpT9FB1YOXiL.pgp
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] disk: part_efi: Fix parameters passed to is_gpt_valid().

[Stefano Babic]

On 11/17/2011 08:56 AM, Thierry Reding wrote:

> I had actually set "Doug Anderson " on Cc 
> because he was involved with the initial patch but for some reason 
> he got stripped from Cc. Does anybody know why this is happening?

Probably Doug has received the first e-mail. I noted that git
send-email strips the CC addresses (maybe to avoid SPAM ?), but the
e-mail is sent anyway.

Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: off...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Please pull u-boot-ti/master

[Kumar Gala]

On Nov 17, 2011, at 7:55 AM, Albert ARIBAUD wrote:

> Hi Sandeep,
> 
> Le 16/11/2011 16:24, s-paul...@ti.com a écrit :
>> The following changes since commit 75acc4d7c1c9081e06d1197c6da01361cf1bce92:
>>   Heiko Schocher (1):
>> arm, davinci: add DAVINCI_MMC_CLKID
>> 
>> are available in the git repository at:
>> 
>>   git://git.denx.de/u-boot-ti.git master
>> 
>> Sanjeev Premi (2):
>>   part_efi: Fix compile errors
>>   omap3evm: Add support for EFI partitions
>> 
>>  disk/part_efi.c |6 +++---
>>  include/configs/omap3_evm.h |1 +
>>  2 files changed, 4 insertions(+), 3 deletions(-)
> 
> Applied to u-boot-arm/master, thanks!

Guys, can you please cleanup patchworks for all the ARM patches and other ARM 
sub-maintainers:

http://patchwork.ozlabs.org/project/uboot/list/

- k
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [STATUS] Help needed - urgently

[Kumar Gala]

On Nov 17, 2011, at 8:10 AM, Wolfgang Denk wrote:

> Dear Kumar Gala,
> 
> In message  you 
> wrote:
>> 
>>> As a first step this requires someone who is brave enought oclean up
>>> the existing state, which is indeed a mess.
>> 
>> Can we say no new patches are going into upstream (your tree) until
>> maintainers go cleanup patchworks?  Such that the # of non-delegated
>> patches is only one or two pages worth, rather than 11.
> 
> With "no new patches" you mean that I will stop applying already
> posted patches, or new postings to the ML?
> 
> I'm fine with both...

I meant the stop applying patches… not sure how we'd stop people posting new 
patches to the ML ;)

- k
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] PPC4xx: usbdev.c used at all?

[Matthias Fuchs]

We do not use it or plan to use it.

Matthias

On 17.11.2011 15:04, Stefan Roese wrote:
> Hi Marri,
> 
> I just "touched" the file "arch/powerpc/cpu/ppc4xx/usbdev.c" again to remove 
> some GCC 4.6 compiler warnings. While doing this I wondered (again) if 
> anybody 
> is using this "driver" at all. I definitely never did. And I'm wondering if 
> this code is useful at all.
> 
> So Marri (or anybody else): Do you need this driver in U-Boot?
> 
> If not, I'll just remove it in a short while.
> 
> Thanks.
> 
> Best regards,
> Stefan
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v4] arm:exynos4:samsung:nuri Support for NURI target.

[Lukasz Majewski]

This patch adds support for Samsung's Exynos4 Nuri reference
board.

New exynos4_nuri board has been added to boards.cfg

Signed-off-by: Lukasz Majewski 
Signed-off-by: Kyungmin Park 
Cc: Minkyu Kang 
---
Changes for v2:
- MAINTAINERS file updated
- CONFIG_MACH_TYPE added
- hw_revision routine
Changes for v3:
- Entry to MAINTAINERS file added to preserve an alphabethical
  order
- Redefinition of MACH_TYPE removed at exynos4_nuri.h
- Code cleanup (dead spaces removed)
Changes for v4:
- get_ram_size() check added to dram_init()
- Use of MACH_TYPE_NURI defined at ./arch/arm/include/asm/mach-types.h
  instead of a hard coded value
- Comments correction

 ./tools/checkpatch.pl - 
total: 0 errors, 0 warnings, 875 lines checked

NOTE: Ignored message types: COMPLEX_MACRO CONSIDER_KSTRTO MINMAX 
MULTISTATEMENT_MACRO_USE_DO_WHILE

---
 MAINTAINERS|4 +
 board/samsung/nuri/Makefile|   45 
 board/samsung/nuri/lowlevel_init.S |  395 
 board/samsung/nuri/nuri.c  |  208 +++
 boards.cfg |1 +
 include/configs/exynos4_nuri.h |  210 +++
 6 files changed, 863 insertions(+), 0 deletions(-)
 create mode 100644 board/samsung/nuri/Makefile
 create mode 100644 board/samsung/nuri/lowlevel_init.S
 create mode 100644 board/samsung/nuri/nuri.c
 create mode 100644 include/configs/exynos4_nuri.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 576fea8..aa1fc15 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -724,6 +724,10 @@ Valentin Longchamp 
km_kirkwood ARM926EJS (Kirkwood SoC)
portl2  ARM926EJS (Kirkwood SoC)
 
+Łukasz Majewski 
+
+   exynos4_nuriARM ARMV7 (S5PC210 SoC)
+
 Nishanth Menon 
 
omap3_sdp3430   ARM ARMV7 (OMAP3xx SoC)
diff --git a/board/samsung/nuri/Makefile b/board/samsung/nuri/Makefile
new file mode 100644
index 000..27566de
--- /dev/null
+++ b/board/samsung/nuri/Makefile
@@ -0,0 +1,45 @@
+#
+# Copyright (C) 2010 Samsung Electronics
+# Minkyu Kang 
+#
+# 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
+
+COBJS-y:= nuri.o
+SOBJS  := lowlevel_init.o
+
+SRCS:= $(SOBJS:.o=.S) $(COBJS-y:.o=.c)
+OBJS   := $(addprefix $(obj),$(COBJS-y))
+SOBJS  := $(addprefix $(obj),$(SOBJS))
+
+$(LIB):$(obj).depend $(SOBJS) $(OBJS)
+   $(call cmd_link_o_target, $(SOBJS) $(OBJS))
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/samsung/nuri/lowlevel_init.S 
b/board/samsung/nuri/lowlevel_init.S
new file mode 100644
index 000..67635bb
--- /dev/null
+++ b/board/samsung/nuri/lowlevel_init.S
@@ -0,0 +1,395 @@
+/*
+ * Lowlevel setup for universal board based on S5PC210
+ *
+ * Copyright (C) 2010 Samsung Electronics
+ * Kyungmin Park 
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * Register usages:
+ *
+ * r5 has zero always
+ * r7 has GPIO part1 base 0x1140
+ * r6 has GPIO part2 base 0x1100
+ */
+
+   .globl lowlevel_init
+lowlevel_init:
+   mov r11, lr
+
+   /* r5 has always zero */
+   mov  

Re: [U-Boot] [PATCH 03/17] env: move extern default_environment[] to environment.h

[Stefano Babic]

On 11/07/2011 12:13 PM, Igor Grinberg wrote:
> Extract all extern declarations for default_environment[] out of c files
> into the environment.h header.
> 
> Signed-off-by: Igor Grinberg 
> Cc: Stefan Roese 
> ---
>  board/zeus/zeus.c  |1 -
>  common/env_dataflash.c |2 --
>  common/env_flash.c |2 --
>  common/env_mgdisk.c|3 ---
>  common/env_mmc.c   |3 ---
>  common/env_nand.c  |3 ---
>  common/env_nowhere.c   |2 --
>  common/env_nvram.c |2 --
>  common/env_onenand.c   |3 ---
>  common/env_sf.c|3 ---
>  include/environment.h  |2 ++
>  11 files changed, 2 insertions(+), 24 deletions(-)
> 

Hi Igor,

this patch breaks several boards because "tools" cannot be compiled clean:

gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -idirafter
/home/stefano/Projects/u-boot-staging/include -idirafter
/home/stefano/Projects/u-boot-staging/include2 -idirafter
/home/stefano/Projects/u-boot-staging/include -I
/home/stefano/Projects/u-boot-staging/lib/libfdt -I
/home/stefano/Projects/u-boot-staging/tools
-DCONFIG_SYS_TEXT_BASE=0x0200 -DUSE_HOSTCC -D__KERNEL_STRICT_NAMES
-pedantic   -o envcrc.o envcrc.c -c
envcrc.c:80:1: Fehler: unbekannter Typname: »env_t«
make[1]: *** [envcrc.o] Fehler 1

You can try with the cmi_mpc5xx board, but it is only an example - I get
the same errors with several ARM boards, because at the end
environment.h is not included. Can you take a look at it ?

Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: off...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [STATUS] Help needed - urgently

[Wolfgang Denk]

Dear Kumar Gala,

In message  you wrote:
> 
> > As a first step this requires someone who is brave enought oclean up
> > the existing state, which is indeed a mess.
> 
> Can we say no new patches are going into upstream (your tree) until
> maintainers go cleanup patchworks?  Such that the # of non-delegated
> patches is only one or two pages worth, rather than 11.

With "no new patches" you mean that I will stop applying already
posted patches, or new postings to the ML?

I'm fine with both...

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
Be careful what you wish for. You never know who will be listening.
  - Terry Pratchett, _Soul Music_
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] PPC4xx: usbdev.c used at all?

[Stefan Roese]

Hi Marri,

I just "touched" the file "arch/powerpc/cpu/ppc4xx/usbdev.c" again to remove 
some GCC 4.6 compiler warnings. While doing this I wondered (again) if anybody 
is using this "driver" at all. I definitely never did. And I'm wondering if 
this code is useful at all.

So Marri (or anybody else): Do you need this driver in U-Boot?

If not, I'll just remove it in a short while.

Thanks.

Best regards,
Stefan

--
DENX Software Engineering GmbH,  MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: off...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Please pull u-boot-ti/master

[Albert ARIBAUD]

Hi Sandeep,

Le 16/11/2011 16:24, s-paul...@ti.com a écrit :
> The following changes since commit 75acc4d7c1c9081e06d1197c6da01361cf1bce92:
>Heiko Schocher (1):
>  arm, davinci: add DAVINCI_MMC_CLKID
>
> are available in the git repository at:
>
>git://git.denx.de/u-boot-ti.git master
>
> Sanjeev Premi (2):
>part_efi: Fix compile errors
>omap3evm: Add support for EFI partitions
>
>   disk/part_efi.c |6 +++---
>   include/configs/omap3_evm.h |1 +
>   2 files changed, 4 insertions(+), 3 deletions(-)

Applied to u-boot-arm/master, thanks!

Amicalement,
-- 
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Pull request: u-boot-arm/master

[Albert ARIBAUD]

Hi Mike,

Le 16/11/2011 04:53, Mike Frysinger a écrit :

> i thought Albert said he didn't want this last time we explicitly asked about
> creating an arm/tegra sub-arch tree ...
>
> i think there should be one
> -mike

Uhm, no, I don't think I said I was against creating a Tegra U-Boot 
repo. What I may have said is that I don't want to fetch from a repo 
located somewhere else that on the Denx git server. If a u-boot-tegra 
repo is created on the Denx server, I'll be happy to pull from it.

Amicalement,
-- 
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [STATUS] Help needed - urgently

[Kumar Gala]

On Nov 16, 2011, at 3:35 PM, Wolfgang Denk wrote:

> Dear Kumar Gala,
> 
> In message  you 
> wrote:
>> 
>> 
>>> Please let's try if this works.  If you have any suggestions how to
>>> help better, please don't hesitate to tell us.
>> 
>> On suggestion I'd have is we improve our use of patchworks.  Right now
>> there is way too much 'stale' on patchworks so its difficult to extract
>> what needs to be looked at from what might be owned by existing
>> maintainers.
> 
> As a first step this requires someone who is brave enought oclean up
> the existing state, which is indeed a mess.

Can we say no new patches are going into upstream (your tree) until maintainers 
go cleanup patchworks?  Such that the # of non-delegated patches is only one or 
two pages worth, rather than 11.

- k

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [STATUS] Help needed - urgently

[Kumar Gala]

On Nov 17, 2011, at 6:40 AM, Stefano Babic wrote:

> On 11/16/2011 10:35 PM, Wolfgang Denk wrote:
>> Dear Kumar Gala,
>> 
>> In message  you 
>> wrote:
>>> 
>>> 
 Please let's try if this works.  If you have any suggestions how to
 help better, please don't hesitate to tell us.
>>> 
>>> On suggestion I'd have is we improve our use of patchworks.  Right now
>>> there is way too much 'stale' on patchworks so its difficult to extract
>>> what needs to be looked at from what might be owned by existing
>>> maintainers.
>> 
>> As a first step this requires someone who is brave enought oclean up
>> the existing state, which is indeed a mess.
> 
> Sure, but anyway to avoid conflicts I suggest that who takes care of a
> patch *firstly* sets his name as delegate into patchwork before doing
> something.

Agreed, my thinking was that for the non-maintained patches, the maintainer 
that pulls a patch in to their tree would mark themselves as the delegate of 
the patch.

- k
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2] tools: checkpatch.pl from Linux added to tools

[Wolfgang Denk]

Dear Joe Hershberger,

In message <1318968419-7686-1-git-send-email-joe.hershber...@ni.com> you wrote:
> Added from Linux - commit 30ecad51849ae132dc6ef6ddb62d499c7257515b
> 
> Include config file to ignore common false-positives
> 
> Signed-off-by: Joe Hershberger 
> Cc: Joe Hershberger 
> Cc: Wolfgang Denk 
> ---
> Changes for v2:
>  - Remove exceptions that were needed for CONFIG_ROOTPATH patches
>  - Add exceptions for min/max and simple_strtoul
> 
>  .checkpatch.conf|   15 +
>  tools/checkpatch.pl | 3337 
> +++
>  2 files changed, 3352 insertions(+), 0 deletions(-)
>  create mode 100644 .checkpatch.conf
>  create mode 100755 tools/checkpatch.pl

Applied, thanks.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
The optimum committee has no members.
   - Norman Augustine
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] ARM: davici_emac: Fix condition for number of phy detects

[Heiko Schocher]

Hello prabhakar.cse...@gmail.com

prabhakar.cse...@gmail.com wrote:
> From: Prabhakar Lad 
> 
> Fix the condition for number of phys in
> davinci_eth_phy_detect() function.
> CONFIG_SYS_DAVINCI_EMAC_PHY_COUNT indicates number of
> phys. From this commit id dc02badab480563b0bf9d3908046ea9d6b22ae63
> davinci emac initilazed one less than the number of phy count.
> 
> Signed-off-by: Prabhakar Lad 
> ---
>  drivers/net/davinci_emac.c |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/net/davinci_emac.c b/drivers/net/davinci_emac.c
> index 36c33af..34b6f94 100644
> --- a/drivers/net/davinci_emac.c
> +++ b/drivers/net/davinci_emac.c
> @@ -176,7 +176,7 @@ static int davinci_eth_phy_detect(void)
>   for (i = 0, j = 0; i < 32; i++)
>   if (phy_act_state & (1 << i)) {
>   count++;
> - if (count < CONFIG_SYS_DAVINCI_EMAC_PHY_COUNT) {
> + if (count <= CONFIG_SYS_DAVINCI_EMAC_PHY_COUNT) {
>   active_phy_addr[j++] = i;
>   } else {
>   printf("%s: to many PHYs detected.\n",

good catch!

Acked-by: Heiko Schocher 

bye,
Heiko
-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [RESEND PATCH] ARM: davici_emac: Fix condition for number of phy detects

[prabhakar . csengg]

From: Prabhakar Lad 

Fix the condition for number of phys in
davinci_eth_phy_detect() function.
CONFIG_SYS_DAVINCI_EMAC_PHY_COUNT indicates number of
phys. From this commit id dc02badab480563b0bf9d3908046ea9d6b22ae63
davinci emac initilazed one less than the number of phy count.

Signed-off-by: Prabhakar Lad 
---
 drivers/net/davinci_emac.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/net/davinci_emac.c b/drivers/net/davinci_emac.c
index 36c33af..34b6f94 100644
--- a/drivers/net/davinci_emac.c
+++ b/drivers/net/davinci_emac.c
@@ -176,7 +176,7 @@ static int davinci_eth_phy_detect(void)
for (i = 0, j = 0; i < 32; i++)
if (phy_act_state & (1 << i)) {
count++;
-   if (count < CONFIG_SYS_DAVINCI_EMAC_PHY_COUNT) {
+   if (count <= CONFIG_SYS_DAVINCI_EMAC_PHY_COUNT) {
active_phy_addr[j++] = i;
} else {
printf("%s: to many PHYs detected.\n",
-- 
1.7.0.4

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] ARM: davici_emac: Fix condition for number of phy detects

[prabhakar . csengg]

From: Prabhakar Lad 

Fix the condition for number of phys in
davinci_eth_phy_detect() function.
CONFIG_SYS_DAVINCI_EMAC_PHY_COUNT indicates number of
phys. From this commit id dc02badab480563b0bf9d3908046ea9d6b22ae63
davinci emac initilazed one less than the number of phy count.

Signed-off-by: Prabhakar Lad 
---
 drivers/net/davinci_emac.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/net/davinci_emac.c b/drivers/net/davinci_emac.c
index 36c33af..34b6f94 100644
--- a/drivers/net/davinci_emac.c
+++ b/drivers/net/davinci_emac.c
@@ -176,7 +176,7 @@ static int davinci_eth_phy_detect(void)
for (i = 0, j = 0; i < 32; i++)
if (phy_act_state & (1 << i)) {
count++;
-   if (count < CONFIG_SYS_DAVINCI_EMAC_PHY_COUNT) {
+   if (count <= CONFIG_SYS_DAVINCI_EMAC_PHY_COUNT) {
active_phy_addr[j++] = i;
} else {
printf("%s: to many PHYs detected.\n",
-- 
1.7.0.4

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot