[U-Boot] [PATCH v3 2/2] EXYNOS4: Add ORIGEN_QUAD board support

[Jeong-Hyeon Kim]

ORIGEN_QUAD board is based on Samsung's Exynos4412 SoC.

Signed-off-by: Jeong-Hyeon Kim 
---
 MAINTAINERS   |4 +
 Makefile  |2 +-
 board/samsung/origen_quad/Makefile|   59 
 board/samsung/origen_quad/boot.c  |   77 +
 board/samsung/origen_quad/clock.c |  117 +++
 board/samsung/origen_quad/dmc.c   |  121 
 board/samsung/origen_quad/lowlevel_init.S |  150 +
 board/samsung/origen_quad/origen_quad.c   |  167 ++
 board/samsung/origen_quad/setup.h |  476 +
 boards.cfg|1 +
 include/configs/origen_quad.h |  188 
 tools/Makefile|2 +
 12 files changed, 1363 insertions(+), 1 deletion(-)
 create mode 100644 board/samsung/origen_quad/Makefile
 create mode 100644 board/samsung/origen_quad/boot.c
 create mode 100644 board/samsung/origen_quad/clock.c
 create mode 100644 board/samsung/origen_quad/dmc.c
 create mode 100644 board/samsung/origen_quad/lowlevel_init.S
 create mode 100644 board/samsung/origen_quad/origen_quad.c
 create mode 100644 board/samsung/origen_quad/setup.h
 create mode 100644 include/configs/origen_quad.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 36b47b7..ce6cdc9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -736,6 +736,10 @@ Lukasz Majewski 
 
trats   ARM ARMV7 (EXYNOS4210 SoC)
 
+Jeong-Hyeon Kim 
+
+   origen_quad ARM ARMV7 (EXYNOS4412 SoC)
+
 Torsten Koschorrek 
scb9328 ARM920T (i.MXL)
 
diff --git a/Makefile b/Makefile
index 44db889..c69f740 100644
--- a/Makefile
+++ b/Makefile
@@ -823,7 +823,7 @@ clean:
   $(obj)tools/gdb/{astest,gdbcont,gdbsend}   \
   $(obj)tools/gen_eth_addr$(obj)tools/img2srec   \
   $(obj)tools/mk{env,}image   $(obj)tools/mpc86x_clk \
-  $(obj)tools/mk{smdk5250,}spl   \
+  $(obj)tools/mk{$(SOC),$(BOARD),}spl\
   $(obj)tools/mxsboot\
   $(obj)tools/ncb $(obj)tools/ubsha1 \
   $(obj)tools/kernel-doc/docproc
diff --git a/board/samsung/origen_quad/Makefile 
b/board/samsung/origen_quad/Makefile
new file mode 100644
index 000..c24c921
--- /dev/null
+++ b/board/samsung/origen_quad/Makefile
@@ -0,0 +1,59 @@
+#
+# Copyright (C) 2012 Samsung Electronics
+#
+# Copyright (C) 2012 Insignal
+#
+# Makefile for the Insignal OrigenQUAD board (Exynos4x12)
+#
+# 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
+
+SOBJS  := lowlevel_init.o
+
+COBJS  := clock.o
+COBJS  += dmc.o
+
+ifndef CONFIG_SPL_BUILD
+COBJS  += origen_quad.o
+else
+COBJS  += boot.o
+endif
+
+SRCS   := $(SOBJS:.o=.S) $(COBJS:.o=.c)
+OBJS   := $(addprefix $(obj),$(COBJS) $(SOBJS))
+
+ALL:= $(obj).depend $(LIB)
+
+all:   $(ALL)
+
+$(LIB):$(OBJS)
+   $(call cmd_link_o_target, $(OBJS))
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
\ No newline at end of file
diff --git a/board/samsung/origen_quad/boot.c b/board/samsung/origen_quad/boot.c
new file mode 100644
index 000..0b67c3b
--- /dev/null
+++ b/board/samsung/origen_quad/boot.c
@@ -0,0 +1,77 @@
+/*
+ * Copyright (C) 2012 Samsung Electronics
+ *
+ * Copyright (C) 2012 Insignal
+ *
+ * Board initialize for the Insignal OrigenQUAD board (Exynos4x12)
+ *
+ * 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 

[U-Boot] [PATCH v3 1/2] EXYNOS4: Add pinmux support for UART

[Jeong-Hyeon Kim]

This patch adds pinmux support for UART channels

Signed-off-by: Jeong-Hyeon Kim 
---
 arch/arm/cpu/armv7/exynos/pinmux.c |   41 
 1 file changed, 41 insertions(+)

diff --git a/arch/arm/cpu/armv7/exynos/pinmux.c 
b/arch/arm/cpu/armv7/exynos/pinmux.c
index f02f441..364ee2a 100644
--- a/arch/arm/cpu/armv7/exynos/pinmux.c
+++ b/arch/arm/cpu/armv7/exynos/pinmux.c
@@ -366,6 +366,41 @@ static int exynos4_mmc_config(int peripheral, int flags)
return 0;
 }
 
+static void exynos4_uart_config(int peripheral)
+{
+   struct exynos4_gpio_part1 *gpio1 =
+   (struct exynos4_gpio_part1 *) samsung_get_base_gpio_part1();
+   struct s5p_gpio_bank *bank;
+   int i, start, count;
+
+   switch (peripheral) {
+   case PERIPH_ID_UART0:
+   bank = &gpio1->a0;
+   start = 0;
+   count = 4;
+   break;
+   case PERIPH_ID_UART1:
+   bank = &gpio1->a0;
+   start = 4;
+   count = 4;
+   break;
+   case PERIPH_ID_UART2:
+   bank = &gpio1->a1;
+   start = 0;
+   count = 4;
+   break;
+   case PERIPH_ID_UART3:
+   bank = &gpio1->a1;
+   start = 4;
+   count = 2;
+   break;
+   }
+   for (i = start; i < start + count; i++) {
+   s5p_gpio_set_pull(bank, i, GPIO_PULL_NONE);
+   s5p_gpio_cfg_pin(bank, i, GPIO_FUNC(0x2));
+   }
+}
+
 static int exynos4_pinmux_config(int peripheral, int flags)
 {
switch (peripheral) {
@@ -377,6 +412,12 @@ static int exynos4_pinmux_config(int peripheral, int flags)
case PERIPH_ID_SDMMC4:
printf("SDMMC device %d not implemented\n", peripheral);
return -1;
+   case PERIPH_ID_UART0:
+   case PERIPH_ID_UART1:
+   case PERIPH_ID_UART2:
+   case PERIPH_ID_UART3:
+   exynos4_uart_config(peripheral);
+   break;
default:
debug("%s: invalid peripheral %d", __func__, peripheral);
return -1;
-- 
1.7.9.5

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

Re: [U-Boot] [U-Boot, v2 2/6] cmd_sf: Add print messages on flash read/write commands

[Jagan Teki]

Hi Wolfgang Denk,

On Thu, Dec 20, 2012 at 4:48 AM, Wolfgang Denk  wrote:
> Dear Jagannadha Sutradharudu Teki,
>
> In message <1355934463-24319-2-git-send-email-jagannadh.t...@gmail.com> you 
> wrote:
>> This patch adds a print messages while using 'sf read' and
>> 'sf write' commands to make sure that how many bytes read/written
>> from/into flash device.
>>
>> Signed-off-by: Jagannadha Sutradharudu Teki 
>> ---
>> Changes in v2:
>> Move print messages from spi_flash.c into cmd_sf.c
>
> Please see previous comments, especially
>
> http://article.gmane.org/gmane.comp.boot-loaders.u-boot/149663
> http://article.gmane.org/gmane.comp.boot-loaders.u-boot/149665
>
> I object against adding more and more verbosity and code size, and in
> an inconsistent way.

Please see my comments on previous patch.
http://article.gmane.org/gmane.comp.boot-loaders.u-boot/149698

Thanks,
Jagan.

>
> 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
> F u cn rd ths u cnt spl wrth a dm!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot, v2 1/6] cmd_sf: Add print messages on flash erase command

[Jagan Teki]

Hi Wolfgang Denk,

On Thu, Dec 20, 2012 at 4:46 AM, Wolfgang Denk  wrote:
> Dear Jagannadha Sutradharudu Teki,
>
> In message <1355934463-24319-1-git-send-email-jagannadh.t...@gmail.com> you 
> wrote:
>> This patch adds a print messages while using 'sf erase' command
>> to make sure that how many bytes erased in flash device.
>>
>> Signed-off-by: Jagannadha Sutradharudu Teki 
>> ---
>> Changes in v2:
>>   Move print messages from spi_flash.c into cmd_sf.c
>
> This makes little sense to me.  Please see all comments here:
>
> http://article.gmane.org/gmane.comp.boot-loaders.u-boot/149663
>
> and here:
>
> http://article.gmane.org/gmane.comp.boot-loaders.u-boot/149665

I thought these are useful verbose prints for sf read/write/erase commands as
there is no verbose support before.

Like NOR, NAND and SD have some verbose prints while executing respective
commands
This is the only way to know the user whether these commands are
- executed properly
- what is the status after executing (success/fail, how many bytes
read/write/erase. etc)

Due to the above reasons I have added these verbose support.

Apart from this sometimes (very rare) due to the slowness of UART or SPI flash
even if we run the sf commands it will not execute the actual code
just terminate with showing
u-boot prompt, so the user assumes that this command is happen
properly. [but actually command is not done]

I thought these verbose prints will help such wild scenarios.

Correct me if am wrong with my thinking.

Thanks,
Jagan.

>
>
>
> 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
> Programmer's Lament: (Shakespeare, Macbeth, Act I, Scene vii)
> "That we but teach bloody instructions,
> which, being taught, return to plague the inventor..."
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Pull request for u-boot-marvell.git

[Prafulla Wadaskar]

Dear Albert,

Please pull
The following changes since commit b8a7c467960ffb4d5a5e1eef5f7783fb6f594542:
  Albert ARIBAUD (1):
Merge branch 'u-boot-imx/master' into 'u-boot-arm/master'

are available in the git repository at:

  u-boot-marvell.git master branch.

Albert ARIBAUD (3):
  mv88e61xx: refactor PHY and SWITCH level-code
  kirkwood: make MPP arrays static const
  ARM: lacie_kw: add support for WIRELESS_SPACE

Holger Brunck (3):
  arm/km: fix memory settings
  km/common: drop unneeded std* environment variables
  km/common: cosmetic change reported from checkpatch

Valentin Longchamp (1):
  arm/km: remove duplicate code

 arch/arm/cpu/arm926ejs/kirkwood/mpp.c   |2 +-
 arch/arm/include/asm/arch-kirkwood/mpp.h|2 +-
 board/LaCie/net2big_v2/net2big_v2.c |2 +-
 board/LaCie/netspace_v2/netspace_v2.c   |2 +-
 board/LaCie/wireless_space/Makefile |   46 +++
 board/LaCie/wireless_space/kwbimage.cfg |   82 
 board/LaCie/wireless_space/wireless_space.c |  176 
 board/Marvell/dreamplug/dreamplug.c |2 +-
 board/Marvell/guruplug/guruplug.c   |2 +-
 board/Marvell/mv88f6281gtw_ge/mv88f6281gtw_ge.c |2 +-
 board/Marvell/openrd/openrd.c   |2 +-
 board/Marvell/rd6281a/rd6281a.c |2 +-
 board/Marvell/sheevaplug/sheevaplug.c   |2 +-
 board/Seagate/dockstar/dockstar.c   |2 +-
 board/buffalo/lsxl/lsxl.c   |2 +-
 board/cloudengines/pogo_e02/pogo_e02.c  |2 +-
 board/d-link/dns325/dns325.c|2 +-
 board/iomega/iconnect/iconnect.c|2 +-
 board/karo/tk71/tk71.c  |2 +-
 board/keymile/common/common.c   |2 +-
 board/keymile/km_arm/km_arm.c   |   16 +-
 board/keymile/km_arm/kwbimage-memphis.cfg   |6 +-
 board/keymile/km_arm/kwbimage.cfg   |6 +-
 board/keymile/km_arm/kwbimage_128M16_1.cfg  |   25 +-
 board/keymile/km_arm/kwbimage_256M8_1.cfg   |   25 +-
 board/raidsonic/ib62x0/ib62x0.c |2 +-
 boards.cfg  |1 +
 drivers/net/phy/mv88e61xx.c |  495 ++
 drivers/net/phy/mv88e61xx.h |   39 ++-
 drivers/spi/kirkwood_spi.c  |   12 +-
 include/configs/km/keymile-common.h |3 -
 include/configs/wireless_space.h|  194 +
 include/netdev.h|   21 +-
 33 files changed, 891 insertions(+), 292 deletions(-)
 create mode 100644 board/LaCie/wireless_space/Makefile
 create mode 100644 board/LaCie/wireless_space/kwbimage.cfg
 create mode 100644 board/LaCie/wireless_space/wireless_space.c
 create mode 100644 include/configs/wireless_space.h

Regards...
Prafulla . . .

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

Re: [U-Boot] [PATCH v5 0/3] Add support for the LaCie Wireless Space

[Prafulla Wadaskar]

> -Original Message-
> From: Albert ARIBAUD [mailto:albert.u.b...@aribaud.net]
> Sent: 27 November 2012 02:58
> To: U-Boot
> Cc: Prafulla Wadaskar; Simon Guinot; Albert ARIBAUD
> Subject: [PATCH v5 0/3] Add support for the LaCie Wireless Space
> 
> This series adds support to the LaCie Wireless Space,
> a Marvell Kirkwood-based product featuring USB, SATA,
> Ethernet and an integrated mv88e6161 Ethernet switch.
> 
> Note 1: up to v4, this series had changes to mvgbe
> for supporting non-sequential PHY addresses on egiga0
> and egiga1. This proved unneeded for switch support,
> and was dropped in v5.
> 
> Note 2: up to v3, this series made the Wireless Space
> a variant of the Net Space V2. Starting from v4, the
> Wireless Space is not based on Net Space V2 any more
> and the changes to Net Space V2 related code have been
> dropped.
> 
> Changes in v5:
> - Fixes to the initialization sequence
> - Added a configurable read/write command
> - made fan, usb, HDD powered on at boot
> - fixed NAND env and Ethernet configs
> - general "ws" command with support for buttons
> - made netconsole accessible before boot delay
> 
> Changes in v4:
> - switched from netspace_V2-based to standalone board
> - added support for mv88e61xx switch
> - corrected some kwbimage.cfg values
> 
> Changes in v3:
> - fix broken support for NETSPACE_(MINI|LITE)_V2
> 
> Changes in v2:
> - split the patch in two: mvgbe phy/port changes and WS support.
> - removed spurious DEBUG define
> - fixed various checkpatch errors/warnings/typos
> 
> Albert ARIBAUD (3):
>   mv88e61xx: refactor PHY and SWITCH level-code
>   kirkwood: make MPP arrays static const
>   ARM: lacie_kw: add support for WIRELESS_SPACE
> 
>  arch/arm/cpu/arm926ejs/kirkwood/mpp.c   |2 +-
>  arch/arm/include/asm/arch-kirkwood/mpp.h|2 +-
>  board/LaCie/net2big_v2/net2big_v2.c |2 +-
>  board/LaCie/netspace_v2/netspace_v2.c   |2 +-
>  board/LaCie/wireless_space/Makefile |   46 +++
>  board/LaCie/wireless_space/kwbimage.cfg |   82 
>  board/LaCie/wireless_space/wireless_space.c |  176 
>  board/Marvell/dreamplug/dreamplug.c |2 +-
>  board/Marvell/guruplug/guruplug.c   |2 +-
>  board/Marvell/mv88f6281gtw_ge/mv88f6281gtw_ge.c |2 +-
>  board/Marvell/openrd/openrd.c   |2 +-
>  board/Marvell/rd6281a/rd6281a.c |2 +-
>  board/Marvell/sheevaplug/sheevaplug.c   |2 +-
>  board/Seagate/dockstar/dockstar.c   |2 +-
>  board/buffalo/lsxl/lsxl.c   |2 +-
>  board/cloudengines/pogo_e02/pogo_e02.c  |2 +-
>  board/d-link/dns325/dns325.c|2 +-
>  board/iomega/iconnect/iconnect.c|2 +-
>  board/karo/tk71/tk71.c  |2 +-
>  board/keymile/km_arm/km_arm.c   |2 +-
>  board/raidsonic/ib62x0/ib62x0.c |2 +-
>  boards.cfg  |1 +
>  drivers/net/phy/mv88e61xx.c |  495
> ++-
>  drivers/net/phy/mv88e61xx.h |   39 +-
>  drivers/spi/kirkwood_spi.c  |   12 +-
>  include/configs/wireless_space.h|  194 +
>  include/netdev.h|   21 +-
>  27 files changed, 880 insertions(+), 222 deletions(-)
>  create mode 100644 board/LaCie/wireless_space/Makefile
>  create mode 100644 board/LaCie/wireless_space/kwbimage.cfg
>  create mode 100644 board/LaCie/wireless_space/wireless_space.c
>  create mode 100644 include/configs/wireless_space.h
> 
> --
> 1.7.10.4

Applied this patch series to u-boot-marvell.git master branch

Regards...
Prafulla . . .

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

Re: [U-Boot] [PATCH 1/4] Optimized nand_read_buf for kirkwood

[Prafulla Wadaskar]

> -Original Message-
> From: u-boot-boun...@lists.denx.de [mailto:u-boot-
> boun...@lists.denx.de] On Behalf Of Scott Wood
> Sent: 27 November 2012 05:09
> To: Phil Sutter
> Cc: u-boot@lists.denx.de; Nico Erfurth
> Subject: Re: [U-Boot] [PATCH 1/4] Optimized nand_read_buf for kirkwood
> 
> On 11/26/2012 04:33:08 AM, Phil Sutter wrote:
> > The basic idea is taken from the linux-kernel, but further
> optimized.
> >
> > First align the buffer to 8 bytes, then use ldrd/strd to read and
> > store
> > in 8 byte quantities, then do the final bytes.
> >
> > Tested using: 'date ; nand read.raw 0xE0 0x0 0x1 ; date'.
> > Without this patch, NAND read of 132MB took 49s (~2.69MB/s). With
> this
> > patch in place, reading the same amount of data was done in 27s
> > (~4.89MB/s). So read performance is increased by ~80%!
> >
> > Signed-off-by: Nico Erfurth 
> > Tested-by: Phil Sutter 
> > Cc: Prafulla Wadaskar 
> > ---
> >  drivers/mtd/nand/kirkwood_nand.c |   29
> +
> >  1 files changed, 29 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/mtd/nand/kirkwood_nand.c
> > b/drivers/mtd/nand/kirkwood_nand.c
> > index bdab5aa..e04a59f 100644
> > --- a/drivers/mtd/nand/kirkwood_nand.c
> > +++ b/drivers/mtd/nand/kirkwood_nand.c
> > @@ -38,6 +38,34 @@ struct kwnandf_registers {
> >  static struct kwnandf_registers *nf_reg =
> > (struct kwnandf_registers *)KW_NANDF_BASE;
> >
> > +
> > +/* The basic idea is stolen from the linux kernel, but the inner
> > loop is optimized a bit more */
> > +static void kw_nand_read_buf(struct mtd_info *mtd, uint8_t *buf,
> int
> > len)
> > +{
> > +   struct nand_chip *chip = mtd->priv;
> > +
> > +   while (len && (unsigned long)buf & 7)
> > +   {
> 
> Brace goes on the previous line.
> 
> > +   *buf++ = readb(chip->IO_ADDR_R);
> > +   len--;
> > +   };
> > +
> > +   asm volatile (
> > +   ".LFlashLoop:\n"
> > +   "  subs\t%0, #8\n"
> > +   "  ldrpld\tr2, [%2]\n" // Read 2 words
> > +   "  strpld\tr2, [%1], #8\n" // Read 2 words
> > +   "  bpl\t.LFlashLoop\n" // This results in one
> > additional loop if len%8 <> 0
> > +   "  addne\t%0, #8\n"
> > +   : "+&r" (len), "+&r" (buf)
> > +   : "r" (chip->IO_ADDR_R)
> > +   : "r2", "r3", "memory", "cc"
> > +   );
> 
> Use a real tab (or a space) rather than \t (which only helps
> readability in the asm output, rather than the C source that people
> actually look at).
> 
> Should probably use a numeric label to avoid any possibility of
> conflict.
> 
> Would this make more sense as a more generic optimized memcpy_fromio()
> or similar?

Hi Phil

For your next post of this patch, please do not forget to add version info and 
changlog to the patch.

Regards...
Prafulla . . .
 
> 
> -Scott
> ___
> 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 3/4] km/common: cosmetic change reported from checkpatch

[Prafulla Wadaskar]

> -Original Message-
> From: Holger Brunck [mailto:holger.bru...@keymile.com]
> Sent: 02 November 2012 15:45
> To: u-boot@lists.denx.de
> Cc: Holger Brunck; Valentin Longchamp; Prafulla Wadaskar
> Subject: [PATCH 3/4] km/common: cosmetic change reported from
> checkpatch
> 
> Signed-off-by: Holger Brunck 
> cc: Valentin Longchamp 
> cc: Prafulla Wadaskar 
> ---
>  board/keymile/common/common.c |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/board/keymile/common/common.c
> b/board/keymile/common/common.c
> index a90f112..6f407b7 100644
> --- a/board/keymile/common/common.c
> +++ b/board/keymile/common/common.c
> @@ -121,7 +121,7 @@ int i2c_make_abort(void)
>  {
> 
>  #if defined(CONFIG_HARD_I2C) && !defined(MACH_TYPE_KM_KIRKWOOD)
> - immap_t *immap = (immap_t *)CONFIG_SYS_IMMR ;
> + immap_t *immap = (immap_t *)CONFIG_SYS_IMMR;
>   i2c8260_t *i2c  = (i2c8260_t *)&immap->im_i2c;
> 
>   /*
> --
> 1.7.1

Applied to u-boot-marvell.git master branch

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

Re: [U-Boot] [PATCH 4/4] arm/km: remove duplicate code

[Prafulla Wadaskar]

> -Original Message-
> From: Holger Brunck [mailto:holger.bru...@keymile.com]
> Sent: 02 November 2012 15:45
> To: u-boot@lists.denx.de
> Cc: Valentin Longchamp; Holger Brunck; Prafulla Wadaskar
> Subject: [PATCH 4/4] arm/km: remove duplicate code
> 
> From: Valentin Longchamp 
> 
> This patch removes 2 small portions of board specific code that are
> duplicated with common ARM code and thus unnecessary. These 2 portions
> of code concern the mach id that is given by u-boot to the Linux
> kernel
> to identify the system's MACH.
> 
> The first one was the possibility to change the MACH thanks to the
> 'mach_id' enviroment variable. This is possible thanks to the 'machid'
> env variable (see arch/arm/lib/bootm.c:boot_jump_linux()).
> 
> The seconde one is the setting of the bi_arch_number. This is already
> done in arch/arm/lib/board.c:board_init_f() since km_arm.h does
> #define
> CONFIG_MACH_TYPE.
> 
> Signed-off-by: Valentin Longchamp 
> cc: Holger Brunck 
> cc: Prafulla Wadaskar 
> ---
>  board/keymile/km_arm/km_arm.c |   14 --
>  1 files changed, 0 insertions(+), 14 deletions(-)
> 
> diff --git a/board/keymile/km_arm/km_arm.c
> b/board/keymile/km_arm/km_arm.c
> index 0c4dddc..262b8d2 100644
> --- a/board/keymile/km_arm/km_arm.c
> +++ b/board/keymile/km_arm/km_arm.c
> @@ -193,15 +193,6 @@ void set_bootcount_addr(void)
> 
>  int misc_init_r(void)
>  {
> - char *str;
> - int mach_type;
> -
> - str = getenv("mach_type");
> - if (str != NULL) {
> - mach_type = simple_strtoul(str, NULL, 10);
> - printf("Overwriting MACH_TYPE with %d!!!\n", mach_type);
> - gd->bd->bi_arch_number = mach_type;
> - }
>  #if defined(CONFIG_KM_MGCOGE3UN)
>   char *wait_for_ne;
>   wait_for_ne = getenv("waitforne");
> @@ -258,11 +249,6 @@ int board_early_init_f(void)
> 
>  int board_init(void)
>  {
> - /*
> -  * arch number of board
> -  */
> - gd->bd->bi_arch_number = MACH_TYPE_KM_KIRKWOOD;
> -
>   /* address of boot parameters */
>   gd->bd->bi_boot_params = kw_sdram_bar(0) + 0x100;
> 
> --
> 1.7.1

Applied to u-boot-marvell.git master branch

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

Re: [U-Boot] [PATCH 2/4] km/common: drop unneeded std* environment variables

[Prafulla Wadaskar]

> -Original Message-
> From: Holger Brunck [mailto:holger.bru...@keymile.com]
> Sent: 02 November 2012 15:45
> To: u-boot@lists.denx.de
> Cc: Holger Brunck; Valentin Longchamp; Prafulla Wadaskar
> Subject: [PATCH 2/4] km/common: drop unneeded std* environment
> variables
> 
> These variables are only used if CONFIG_SYS_CONSOLE_IS_IN_ENV
> is set. This isn't the case, so we can drop them safely.
> 
> Signed-off-by: Holger Brunck 
> cc: Valentin Longchamp 
> cc: Prafulla Wadaskar 
> ---
>  include/configs/km/keymile-common.h |3 ---
>  1 files changed, 0 insertions(+), 3 deletions(-)
> 
> diff --git a/include/configs/km/keymile-common.h
> b/include/configs/km/keymile-common.h
> index 05480d4..f64748e 100644
> --- a/include/configs/km/keymile-common.h
> +++ b/include/configs/km/keymile-common.h
> @@ -253,9 +253,6 @@
>   "load=tftpboot ${load_addr_r} ${u-boot}\0"  \
>   "mtdids=" MTDIDS_DEFAULT "\0"   \
>   "mtdparts=" MTDPARTS_DEFAULT "\0"   \
> - "stderr=serial\0"   \
> - "stdin=serial\0"\
> - "stdout=serial\0"   \
>   ""
>  #endif /* CONFIG_KM_DEF_ENV */
> 
> --
> 1.7.1

Applied to u-boot-marvell.git master branch

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

Re: [U-Boot] [PATCH 1/4] arm/km: fix memory settings

[Prafulla Wadaskar]

> -Original Message-
> From: Holger Brunck [mailto:holger.bru...@keymile.com]
> Sent: 02 November 2012 15:45
> To: u-boot@lists.denx.de
> Cc: Holger Brunck; Valentin Longchamp; Prafulla Wadaskar
> Subject: [PATCH 1/4] arm/km: fix memory settings
> 
> On kmcoge5un we faced some serious problems with the memory during
> temperature tests. Reason was that we overwrite some registers for
> memory settings which have to leave untouched. These where registers
> 0x20148 , 0x2014c and 0x20154.
> So writing these registers is prohibited and this patch removes them
> from all km related config files. Even if the problem was only
> seen on kmcoge5un.
> 
> Signed-off-by: Holger Brunck 
> Signed-off-by: Valentin Longchamp 
> cc: Prafulla Wadaskar 
> ---
>  board/keymile/km_arm/kwbimage-memphis.cfg  |6 +++---
>  board/keymile/km_arm/kwbimage.cfg  |6 +++---
>  board/keymile/km_arm/kwbimage_128M16_1.cfg |   25 ++-
> --
>  board/keymile/km_arm/kwbimage_256M8_1.cfg  |   25 ++-
> --
>  4 files changed, 10 insertions(+), 52 deletions(-)
> 
> diff --git a/board/keymile/km_arm/kwbimage-memphis.cfg
> b/board/keymile/km_arm/kwbimage-memphis.cfg
> index 6df2ad7..5aa0de2 100644
> --- a/board/keymile/km_arm/kwbimage-memphis.cfg
> +++ b/board/keymile/km_arm/kwbimage-memphis.cfg
> @@ -55,9 +55,9 @@ DATA 0xFFD10008 0x1100  # MPP Control 2
> Register
>  DATA 0xFFD100E0 0x1B1B1B1B   # IO Configuration 0 Register
>  DATA 0xFFD20134 0x   # L2 RAM Timing 0 Register
>  DATA 0xFFD20138 0x   # L2 RAM Timing 1 Register
> -DATA 0xFFD20154 0x0200   # CPU RAM Management Control3 Register
> -DATA 0xFFD2014C 0x1C00   # CPU RAM Management Control1 Register
> -DATA 0xFFD20148 0x0001   # CPU RAM Management Control0 Register
> +
> +# NOTE: Don't write on 0x20148 , 0x2014c and 0x20154, leave them
> untouched!
> +# If not it could cause KW Exceptions during boot in Fast
> Corners/High Voltage
> 
>  #Dram initalization
>  DATA 0xFFD01400 0x430004E0   # SDRAM Configuration Register
> diff --git a/board/keymile/km_arm/kwbimage.cfg
> b/board/keymile/km_arm/kwbimage.cfg
> index b2f5193..e5e9942 100644
> --- a/board/keymile/km_arm/kwbimage.cfg
> +++ b/board/keymile/km_arm/kwbimage.cfg
> @@ -52,9 +52,9 @@ DATA 0xFFD10008 0x1100  # MPP Control 2
> Register
>  DATA 0xFFD100E0 0x1B1B1B1B   # IO Configuration 0 Register
>  DATA 0xFFD20134 0x   # L2 RAM Timing 0 Register
>  DATA 0xFFD20138 0x   # L2 RAM Timing 1 Register
> -DATA 0xFFD20154 0x0200   # CPU RAM Management Control3 Register
> -DATA 0xFFD2014C 0x1C00   # CPU RAM Management Control1 Register
> -DATA 0xFFD20148 0x0001   # CPU RAM Management Control0 Register
> +
> +# NOTE: Don't write on 0x20148 , 0x2014c and 0x20154, leave them
> untouched!
> +# If not it could cause KW Exceptions during boot in Fast
> Corners/High Voltage
> 
>  #Dram initalization
>  DATA 0xFFD01400 0x43000400   # SDRAM Configuration Register
> diff --git a/board/keymile/km_arm/kwbimage_128M16_1.cfg
> b/board/keymile/km_arm/kwbimage_128M16_1.cfg
> index bcce907..5de8df7 100644
> --- a/board/keymile/km_arm/kwbimage_128M16_1.cfg
> +++ b/board/keymile/km_arm/kwbimage_128M16_1.cfg
> @@ -98,29 +98,8 @@ DATA 0xFFD20138 0x # L2 RAM Timing 1
> Register
>  # bit 19-18: 1, ECC RAM WTC RAM0
>  # bit 31-20: ???,Reserve
> 
> -DATA 0xFFD20154 0x0200   # CPU RAM Management Control3 Register
> -# bit 23-0:  0x000200, Addr Config tuning
> -# bit 31-24: 0,Reserved
> -
> -# ??? Missing register # CPU RAM Management Control2 Register
> -
> -DATA 0xFFD2014C 0x1C00   # CPU RAM Management Control1 Register
> -# bit 15-0:  0x1C00, Opmux Tuning
> -# bit 31-16: 0,  Pc Dp Tuning
> -
> -DATA 0xFFD20148 0x0001   # CPU RAM Management Control0 Register
> -# bit 1-0:   1, addr clk tune
> -# bit 3-2:   0, reserved
> -# bit 5-4:   0, dtcmp clk tune
> -# bit 7-6:   0, reserved
> -# bit 9-8:   0, macdrv clk tune
> -# bit 11-10: 0, opmuxgm2 clk tune
> -# bit 15-14: 0, rf clk tune
> -# bit 17-16: 0, rfbypass clk tune
> -# bit 19-18: 0, pc dp clk tune
> -# bit 23-20: 0, icache clk tune
> -# bit 27:24: 0, dcache clk tune
> -# bit 31:28: 0, regfile tunin
> +# NOTE: Don't write on 0x20148 , 0x2014c and 0x20154, leave them
> untouched!
> +# If not it could cause KW Exceptions during boot in Fast
> Corners/High Voltage
> 
>  # SDRAM initalization
>  DATA 0xFFD01400 0x430004E0   # SDRAM Configuration Register
> diff --git a/board/keymile/km_arm/kwbimage_256M8_1.cfg
> b/board/keymile/km_arm/kwbimage_256M8_1.cfg
> index 3e1237b..d0a09f6 100644
> --- a/board/keymile/km_arm/kwbimage_256M8_1.cfg
> +++ b/board/keymile/km_arm/kwbimage_256M8_1.cfg
> @@ -100,29 +100,8 @@ DATA 0xFFD20138 0x   # L2 RAM Timing 1
> Register
>  # bit 19-18: 1, ECC RAM WTC RAM0
>  # bit 31-20: ?,Reserved
> 
> -DATA 0xFFD20154 0x0200   # CPU RAM Management Control3 Register
> -# bit 23-0:  0x000200, Addr Config tuning
> -# bit 31-24: 0,

Re: [U-Boot] please pull u-boot-samsung/resolve

[Stephen Warren]

On 12/19/2012 10:59 PM, Minkyu Kang wrote:
> Dear Albert and Stephen,
> 
> On 20/12/12 01:28, Albert ARIBAUD wrote:
...
>> Can you answer the question Stephen has asked on this list on 11/12 ?
>>
>> 
> 
> Comes from u-boot-arm tree.
> The base of this pull request is u-boot tree, hence some u-boot-arm commits 
> are included.
> But it doesn't matter maybe.. because this pull request is for u-boot-arm 
> tree.

OK, that might explain it, but isn't there a way to list only the new
commits?

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

Re: [U-Boot] [PATCH 1/2] spi: Add progress percentage and write speed to `sf update`

[Wolfgang Denk]

Dear Scott Wood,

In message <1355960533.12062.16@snotra> you wrote:
>
> > Hmmm I suppose that is a good point. The main issue with SPI flash is
> > that it is extremely slow, and writing a few MB can take a minute or
> > so. The 'sf update' command was intended to do a smart update, and the
> > progress is useful for that. Other storage types are not so bad.
> 
> NOR can be pretty slow as well -- and it does have a progress indicator  
> in U-Boot (albeit a simpler one).

Actually even this should be configurable.

Especially the spinning wheel used on some boards is a mess.


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de

"What happened to the crewman?" "The M-5 computer  needed  a  new
power source, the crewman merely got in the way."
-- Kirk and Dr. Richard Daystrom, "The Ultimate Computer",
   stardate 4731.3.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] please pull u-boot-samsung/resolve

[Minkyu Kang]

Dear Albert and Stephen,

On 20/12/12 01:28, Albert ARIBAUD wrote:
> Hi Minkyu,
> 
> On Tue, 18 Dec 2012 00:14:34 +0900, Minkyu Kang 
> wrote:
>> Dear Albert,
>>
>> On Saturday, December 15, 2012, Albert ARIBAUD wrote:
>>
>>> Hi Minkyu,
>>>
>>> On Fri, 14 Dec 2012 09:14:11 +0900, Minkyu Kang 
>>> 

>>> wrote:
 On 14/12/12 04:56, Albert ARIBAUD wrote:
> Hi Minkyu,
>
> On Tue, 11 Dec 2012 20:10:06 +0900, Minkyu Kang 
> wrote:
>> Dear Albert,
>>
>> The following changes since commit
>>> fd4d564b3c80b111f18c93adb14233a6a7ddb0e9:
>>
>>   Merge branch 'master' of git://git.denx.de/u-boot-x86 (2012-12-07
>>> 08:47:59 -0700)
>>
>> are available in the git repository at:
>>
>>
>>   git://git.denx.de/u-boot-samsung resolve
>>
>> for you to fetch changes up to
>>> fbef8e6e7f1233ed20f8c5045e12c9cf31b43540:
>>
>>   universal_c210: check the NULL pointer when get the PMIC
>>> (2012-12-11 17:37:28 +0900)
>>
>> 
>> Albert ARIBAUD (1):
>>   Merge branch 'u-boot-imx/master' into 'u-boot-arm/master'
>>
>> Allen Martin (1):
>>   tegra: add CONSOLE_MUX support to tegra-kbc
>>
>> Ashok Kumar Reddy (1):
>>   ARM: arm1176: Define arch_cpu_init() for s3c64xx
>>
>> Benoît Thébaudeau (17):
>>   arm1136: Fix enable_caches()
>>   mx31: Move EHCI definitions to ehci-fsl.h
>>   ehci-mxc: Clean up
>>   ehci-mx5: Clean up
>>   ehci-mx5: Fix OC_DIS usage
>>   ehci-mx5: Fix OPM usage
>>   ehci-mx5: Fix *PM usage for i.MX53
>>   ehci-mx5: Add missing OC_DIS for i.MX53
>>   ehci-mxc: Make EHCI power/oc polarities configurable
>>   ehci-mxc: Make i.MX25 EHCI configurable
>>   ehci-mxc: Define host offsets
>>   ehci-mxc: Add support for i.MX35
>>   mx35pdk: Add support for OTG
>>   ehci-mx5/6: Make board_ehci_hcd_init() optional
>>   ehci-mxc: Fix host power mask bit for i.MX35
>>   ehci-mxc: Fix host power mask bit for i.MX25
>>   mx5: Mark lowlevel_init board-specific code
>>
>> Chander Kashyap (1):
>>   Exynos5250: Enable PXE Support
>>
>> Fabio Estevam (24):
>>   mx25pdk: Include CONFIG_MX25
>>   mx25pdk: Add esdhc support
>>   pmic_fsl: Introduce FSL_PMIC_I2C_LENGTH
>>   mx25: Place common functions into sys_proto.h
>>   pmic: Add support for mc34704
>>   mx25pdk: Add Ethernet support
>>   mx53loco: Allow booting a zImage kernel
>>   mx25pdk: Allow booting a zImage kernel
>>   mx51evk: Allow booting a zImage kernel
>>   mx35pdk: Allow booting a zImage kernel
>>   mx6qsabre_common: Allow booting a zImage kernel
>>   mx5: Align SPI CS naming with i.MX53 reference manual
>>   mx5: Print CSPI clock in 'clock' command
>>   spi: mxc_spi: Fix handling of chip select
>>   spi: mxc_spi: Fix spi clock glitch durant reset
>>   mx6: clock: Only show CSPI clock if CSPI is enabled
>>   mx28evk: Configure CONFIG_BOOTDELAY to one second
>>   mx53loco: Configure CONFIG_BOOTDELAY to one second
>>   mx6qsabrelite: Configure CONFIG_BOOTDELAY to one second
>>   mx6qsabre_common: Configure CONFIG_BOOTDELAY to one second
>>   mx51evk: Configure CONFIG_BOOTDELAY to one second
>>   mx25pdk: Configure CONFIG_BOOTDELAY to one sYou're right. I was
>>> a bit quick to reply when I read Stephen's
>>> question. Can you please address it too?
>>
>> Address for what?
> 
> Can you answer the question Stephen has asked on this list on 11/12 ?
> 
> 

Comes from u-boot-arm tree.
The base of this pull request is u-boot tree, hence some u-boot-arm commits are 
included.
But it doesn't matter maybe.. because this pull request is for u-boot-arm tree.

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

Re: [U-Boot] [U-Boot,1/3] fw_env: fix type of len

[Joe Hershberger]

Hi Tom,

On Wed, Dec 19, 2012 at 5:00 PM, Tom Rini  wrote:
> On Sat, Nov 10, 2012 at 07:47:45PM -, Mike Frysinger wrote:
>
>> This variable is assigned by a size_t, and is printed that way, but is
>> incorrectly declared as an int.  Which means we get warnings:
>> fw_env.c: In function 'fw_setenv':
>> fw_env.c:409:5: warning: format '%zu' expects argument of type 'size_t',
>>   but argument 3 has type 'int' [-Wformat]
>>
>> Signed-off-by: Mike Frysinger 
>> Acked-by: Joe Hershberger 
>
> For the series, applied to u-boot/master, thanks!

I NACKed the third in this series.  Did you not see it?

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

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

[Nobuhiro Iwamatsu]

Hi Tom,

Please pull u-boot-sh master branch.

Best regards,
  Nobuhiro

The following changes since commit 095728803eedfce850a2f85828f79500cb09979e:

  Merge branch 'master' of git://git.denx.de/u-boot-net (2012-12-17
18:39:50 -0700)

are available in the git repository at:


  git://git.denx.de/u-boot-sh master

for you to fetch changes up to bb474b8187878181493b4ba1d422fb83df9b4335:

  serial_sh: Add support Renesas SH7752 (2012-12-20 13:20:17 +0900)


Yoshihiro Shimoda (2):
  sh: add support for sh7752evb board
  serial_sh: Add support Renesas SH7752

 MAINTAINERS |1 +
 arch/sh/include/asm/cpu_sh4.h   |2 +
 arch/sh/include/asm/cpu_sh7752.h|  211
++
 board/renesas/sh7752evb/Makefile|   36 ++
 board/renesas/sh7752evb/lowlevel_init.S |  460
+
 board/renesas/sh7752evb/sh7752evb.c |  330

 board/renesas/sh7752evb/spi-boot.c  |  116 ++
 board/renesas/sh7752evb/u-boot.lds  |   97 +
 boards.cfg  |1 +
 doc/README.sh7752evb|   67 +
 drivers/serial/serial_sh.h  |2 +-
 include/configs/sh7752evb.h |  153
+++
 12 files changed, 1475 insertions(+), 1 deletion(-)
 create mode 100644 arch/sh/include/asm/cpu_sh7752.h
 create mode 100644 board/renesas/sh7752evb/Makefile
 create mode 100644 board/renesas/sh7752evb/lowlevel_init.S
 create mode 100644 board/renesas/sh7752evb/sh7752evb.c
 create mode 100644 board/renesas/sh7752evb/spi-boot.c
 create mode 100644 board/renesas/sh7752evb/u-boot.lds
 create mode 100644 doc/README.sh7752evb
 create mode 100644 include/configs/sh7752evb.h


-- 
Nobuhiro Iwamatsu
   iwamatsu at {nigauri.org / debian.org}
   GPG ID: 40AD1FA6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] powerpc/t4240qds: Update IFC timing for NOR flash

[Prabhakar Kushwaha]

From: York Sun 

Relax parameters to give address latching more time to setup.
Tighten parameters to make it overall faster.

Signed-off-by: York Sun 
---
 include/configs/t4qds.h |   10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/include/configs/t4qds.h b/include/configs/t4qds.h
index 9e14d88..5d0d48f 100644
--- a/include/configs/t4qds.h
+++ b/include/configs/t4qds.h
@@ -213,14 +213,14 @@ unsigned long get_board_ddr_clk(void);
 /* NOR Flash Timing Params */
 #define CONFIG_SYS_NOR_CSORCSOR_NAND_TRHZ_80
 
-#define CONFIG_SYS_NOR_FTIM0   (FTIM0_NOR_TACSE(0x01) | \
-   FTIM0_NOR_TEADC(0x01) | \
-   FTIM0_NOR_TEAHC(0x20))
+#define CONFIG_SYS_NOR_FTIM0   (FTIM0_NOR_TACSE(0x4) | \
+   FTIM0_NOR_TEADC(0x5) | \
+   FTIM0_NOR_TEAHC(0x5))
 #define CONFIG_SYS_NOR_FTIM1   (FTIM1_NOR_TACO(0x35) | \
FTIM1_NOR_TRAD_NOR(0x1A) |\
FTIM1_NOR_TSEQRAD_NOR(0x13))
-#define CONFIG_SYS_NOR_FTIM2   (FTIM2_NOR_TCS(0x01) | \
-   FTIM2_NOR_TCH(0x0E) | \
+#define CONFIG_SYS_NOR_FTIM2   (FTIM2_NOR_TCS(0x4) | \
+   FTIM2_NOR_TCH(0x4) | \
FTIM2_NOR_TWPH(0x0E) | \
FTIM2_NOR_TWP(0x1c))
 #define CONFIG_SYS_NOR_FTIM3   0x0
-- 
1.7.9.5



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

Re: [U-Boot] [PATCH 9/9] COMMON: MMC: Command to support eMMC booting

[Simon Glass]

Hi Amar,

On Mon, Dec 17, 2012 at 3:19 AM, Amar  wrote:

> This patch adds commands to open, close and create partitions on eMMC
>
> Signed-off-by: Amar 
> ---
>  common/cmd_mmc.c |  101
> +-
>  1 files changed, 100 insertions(+), 1 deletions(-)
>
> diff --git a/common/cmd_mmc.c b/common/cmd_mmc.c
> index 62a1c22..1fd6b94 100644
> --- a/common/cmd_mmc.c
> +++ b/common/cmd_mmc.c
> @@ -248,6 +248,102 @@ static int do_mmcops(cmd_tbl_t *cmdtp, int flag, int
> argc, char * const argv[])
> curr_device, mmc->part_num);
>
> return 0;
> +   } else if (strcmp(argv[1], "open") == 0) {
> +   int dev;
> +   struct mmc *mmc;
> +
> +   if (argc == 2)
> +   dev = curr_device;
> +   else if (argc == 3)
> +   dev = simple_strtoul(argv[2], NULL, 10);
> +   else if (argc == 4)
> +   return 1;
>

Should this be  CMD_RET_USAGE? What is returning 1 for?

> +
> +   else
> +   return CMD_RET_USAGE;
> +
> +   mmc = find_mmc_device(dev);
> +   if (!mmc) {
> +   printf("no mmc device at slot %x\n", dev);
> +   return 1;
> +   }
> +
> +   if (IS_SD(mmc)) {
> +   printf("SD device cannot be opened/closed\n");
> +   return 1;
> +   }
> +
> +   if (!(mmc_boot_open(mmc))) {
> +   printf("eMMC OPEN Success.!!\n");
> +   printf("\t\t\t!!!Notice!!!\n");
> +   printf("!You must close eMMC boot Partition"
> +   "after all image
> writing!\n");
> +   printf("!eMMC boot partition has continuity"
> +   "at image writing
> time.!\n");
> +   printf("!So, Do not close boot partition, Before,"
> +   "all images is
> written.!\n");
>

Maybe:

 So, do not close boot partition before all images are written

+   } else {
> +   printf("eMMC OPEN Failed.!!\n");
>

Is it eMMC or MMC? Lower case or upper case? Your messages should be
consistent. And you don't need the !!! I think.


> +   }
> +   return 0;
> +
> +   } else if (strcmp(argv[1], "close") == 0) {
> +   int dev;
> +   struct mmc *mmc;
> +
> +   if (argc == 2)
> +   dev = curr_device;
> +   else if (argc == 3)
> +   dev = simple_strtoul(argv[2], NULL, 10);
> +   else if (argc == 4)
> +   return 1;
>

Same Q here as above.


> +   else
> +   return CMD_RET_USAGE;
> +
> +   mmc = find_mmc_device(dev);
> +   if (!mmc) {
> +   printf("no mmc device at slot %x\n", dev);
> +   return 1;
> +   }
> +
> +   if (IS_SD(mmc)) {
> +   printf("SD device cannot be opened/closed\n");
> +   return 1;
> +   }
> +
>

Seems the open/close code is almost the same. Can you combine it?


> +   if (!(mmc_boot_close(mmc)))
> +   printf("eMMC CLOSE Success.!!\n");
> +   else
> +   printf("eMMC CLOSE Failed.!!\n");
> +
> +   return 0;
> +
> +   } else if (strcmp(argv[1], "bootpart") == 0) {
> +   int dev;
> +   dev = simple_strtoul(argv[2], NULL, 10);
> +
> +   struct mmc *mmc = find_mmc_device(dev);
> +   u32 bootsize = simple_strtoul(argv[3], NULL, 10);
> +   u32 rpmbsize = simple_strtoul(argv[4], NULL, 10);
> +
> +   if (!mmc) {
> +   printf("no mmc device at slot %x\n", dev);
> +   return 1;
> +   }
> +
> +   if (IS_SD(mmc)) {
> +   printf("It is not a eMMC device\n");
> +   return 1;
> +   }
> +
> +   if (0 == mmc_boot_partition_size_change(mmc,
> +   bootsize, rpmbsize)) {
> +   printf("eMMC boot partition Size %d MB!!\n",
> bootsize);
> +   printf("eMMC RPMB partition Size %d MB!!\n",
> rpmbsize);
> +   } else {
> +   printf("eMMC boot partition Size change
> Failed.!!\n");
>

return 1 here I think


> +   }
> +   return 0;
> }
>
> if (strcmp(argv[1], "read") == 0)
> @@ -318,5 +414,8 @@ U_BOOT_CMD(
> "mmc rescan\n"
> "mmc part - lists available partition on current mmc device\n"
> "mmc dev [de

Re: [U-Boot] [PATCH 8/9] SMDK5250: Enable eMMC booting

[Simon Glass]

Hi Amar,

On Mon, Dec 17, 2012 at 3:19 AM, Amar  wrote:

> This patch adds support for eMMC booting on SMDK5250
>
> Signed-off-by: Amar 
> ---
>  board/samsung/smdk5250/spl_boot.c |   38
> -
>  1 files changed, 37 insertions(+), 1 deletions(-)
>
> diff --git a/board/samsung/smdk5250/spl_boot.c
> b/board/samsung/smdk5250/spl_boot.c
> index d8f3c1e..2648b4e 100644
> --- a/board/samsung/smdk5250/spl_boot.c
> +++ b/board/samsung/smdk5250/spl_boot.c
> @@ -23,15 +23,40 @@
>  #include
>  #include
>
> +#include 
> +#include 
> +
> +#define FSYS1_MMC0_DIV_VAL  0x0701
>

Should go in arch/arm/include/... ?


> +
>  enum boot_mode {
> BOOT_MODE_MMC = 4,
> +   BOOT_MODE_eMMC = 8, /* eMMC44 */
>

I think should you use upper case E, although I'm not completely sure.


> BOOT_MODE_SERIAL = 20,
> /* Boot based on Operating Mode pin settings */
> BOOT_MODE_OM = 32,
> BOOT_MODE_USB,  /* Boot using USB download */
>  };
>
> -   typedef u32 (*spi_copy_func_t)(u32 offset, u32 nblock, u32 dst);
> +typedef u32 (*spi_copy_func_t)(u32 offset, u32 nblock, u32 dst);
>

Should avoid adding typedefs.


> +static void set_emmc_clk(void);
> +
> +/*
> +* Set MMC0 clock divisor value.
> +* So that the mmc0 device operating freq is 50MHz.
>

Do we only support booting from mmc0? That's fine, but I suggest adding a
little comment.


> +*/
> +static void set_emmc_clk(void)
> +{
> +   struct exynos5_clock *clk = (struct exynos5_clock
> *)EXYNOS5_CLOCK_BASE;
> +   unsigned int addr;
> +   unsigned int div_mmc;
> +
> +   addr = (unsigned int) &clk->div_fsys1;
> +
> +   div_mmc = readl(addr) & ~FSYS1_MMC0_DIV_MASK;
> +   div_mmc |= FSYS1_MMC0_DIV_VAL;
> +   writel(div_mmc, addr);
>

Can this function go in clock.c?


> +}
> +
>
>  /*
>  * Copy U-boot from mmc to RAM:
> @@ -43,6 +68,8 @@ void copy_uboot_to_ram(void)
> spi_copy_func_t spi_copy;
> enum boot_mode bootmode;
> u32 (*copy_bl2)(u32, u32, u32);
> +   u32 (*copy_bl2_emmc)(u32, u32);
> +   void (*end_bootop_emmc)(void);
>
> bootmode = readl(EXYNOS5_POWER_BASE) & OM_STAT;
>
> @@ -57,6 +84,15 @@ void copy_uboot_to_ram(void)
> copy_bl2(BL2_START_OFFSET, BL2_SIZE_BLOC_COUNT,
> CONFIG_SYS_TEXT_BASE);
> break;
> +   case BOOT_MODE_eMMC:
> +   set_emmc_clk();
> +   end_bootop_emmc = (void *) *(u32
> *)EMMC44_END_BOOTOP_FNPTR_ADDR;
> +   copy_bl2_emmc = (void *) *(u32
> *)EMMC44_COPY_BL2_FNPTR_ADDR;
>

I think these are pointers to functions in the IROM. Do they have the same
signature? Is it possible to create a table of them somewhere instead of
using defines?


> +
> +   copy_bl2_emmc(BL2_SIZE_BLOC_COUNT, CONFIG_SYS_TEXT_BASE);
> +   end_bootop_emmc();
> +   break;
> +
> default:
> break;
> }
> --
> 1.7.0.4
>
>
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 7/9] MMC: APIs to support creation of boot partition

[Simon Glass]

Hi Amar,

On Mon, Dec 17, 2012 at 3:19 AM, Amar  wrote:

> This pathc adds APIs to open, close and to create boot partiton for eMMC.
>
> Signed-off-by: Amar 
>

I think you should run checkpatch (or patman!) on your patches to get rid
of little errors. Or maybe you need to upgrade your checkpatch.


> ---
>  drivers/mmc/mmc.c |  118
> +
>  include/mmc.h |   16 +++
>  2 files changed, 134 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> index 5ffd8c5..88b0435 100644
> --- a/drivers/mmc/mmc.c
> +++ b/drivers/mmc/mmc.c
> @@ -1302,3 +1302,121 @@ int mmc_initialize(bd_t *bis)
>
> return 0;
>  }
> +
> +int mmc_boot_partition_size_change(struct mmc *mmc, unsigned long
> bootsize,
> +   unsigned long rpmbsize)
> +{
> +   int err;
> +   struct mmc_cmd cmd;
> +
> +   /* Only use this command for raw eMMC moviNAND */
> +   /* Enter backdoor mode */
>

/*
 * line 1
 * line 2
 */

> +   cmd.cmdidx = MMC_CMD_RES_MAN;
> +   cmd.resp_type = MMC_RSP_R1b;
> +   cmd.cmdarg = MMC_CMD62_ARG1;
> +


[snip]

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

Re: [U-Boot] [PATCH 6/9] SMDK5250: Enable DWMMC

[Simon Glass]

Hi Amar,

On Mon, Dec 17, 2012 at 3:19 AM, Amar  wrote:

> This patch enables DWMMC for SMDK5250.
> Support both dt and non-dt versions.
>
> Signed-off-by: Amar 
> ---
>  board/samsung/smdk5250/smdk5250.c |   36
> 
>  include/configs/exynos5250-dt.h   |9 +
>  2 files changed, 41 insertions(+), 4 deletions(-)
>
> diff --git a/board/samsung/smdk5250/smdk5250.c
> b/board/samsung/smdk5250/smdk5250.c
> index 4d24978..7a9c8f6 100644
> --- a/board/samsung/smdk5250/smdk5250.c
> +++ b/board/samsung/smdk5250/smdk5250.c
> @@ -27,6 +27,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -192,16 +193,43 @@ int checkboard(void)
>  #ifdef CONFIG_GENERIC_MMC
>  int board_mmc_init(bd_t *bis)
>  {
> -   int err;
> +   int err = 0, ret = 0;
>
> +#ifdef CONFIG_OF_CONTROL
> +   /* dwmmc initializattion for available channels */
> +   err = exynos_dwmmc_init(gd->fdt_blob);
> +   if (err) {
> +   debug("dwmmc init failed\n");
> +   }
> +   ret |= err;
> +#else
> err = exynos_pinmux_config(PERIPH_ID_SDMMC0,
> PINMUX_FLAG_8BIT_MODE);
> if (err) {
> debug("SDMMC0 not configured\n");
> -   return err;
> }
> +   ret |= err;
>

Perhaps we need an exynos5-dt.c board file instead of using smdk5250? It
seems like you will end up with lots of #ifdefs otherwise.


>
> -   err = s5p_mmc_init(0, 8);
> -   return err;
> +   /*eMMC: dwmmc Channel-0 with 8 bit bus width */
> +   err = exynos_dwmmc_init(0, 8);
> +   if (err) {
> +   debug("dwmmc Channel-0 init failed\n");
>

Don't need {} here.


> +   }
> +   ret |= err;
> +
> +   err = exynos_pinmux_config(PERIPH_ID_SDMMC2, PINMUX_FLAG_NONE);
> +   if (err) {
> +   debug("SDMMC2 not configured\n");
>

and here


> +   }
> +   ret |= err;
> +
> +   /*SD: dwmmc Channel-2 with 4 bit bus width */
> +   err = exynos_dwmmc_init(2, 4);
> +   if (err) {
> +   debug("dwmmc Channel-2 init failed\n");
> +   }
> +   ret |= err;
> +#endif
> +   return ret;
>  }
>  #endif
>
> diff --git a/include/configs/exynos5250-dt.h
> b/include/configs/exynos5250-dt.h
> index 12f555c..3b89e20 100644
> --- a/include/configs/exynos5250-dt.h
> +++ b/include/configs/exynos5250-dt.h
> @@ -84,6 +84,8 @@
>  #define CONFIG_MMC
>  #define CONFIG_SDHCI
>  #define CONFIG_S5P_SDHCI
> +#define CONFIG_DWMMC
>

What does this config enable? Is it in a README somewhere?


> +#define CONFIG_EXYNOS_DWMMC
>
>  #define CONFIG_BOARD_EARLY_INIT_F
>
> @@ -116,6 +118,13 @@
>  #define CONFIG_SPL
>  #define COPY_BL2_FNPTR_ADDR0x02020030
>
> +/* eMMC4.4 SPL */
> +#define EMMC44_COPY_BL2_FNPTR_ADDR 0x02020044
> +#define EMMC44_END_BOOTOP_FNPTR_ADDR   0x02020048
>

What are these for?


> +
> +#define FSYS1_MMC0_DIV_MASK0xff0f
>

This seems like something for the SOC headers, not the board header.


> +
> +
>  /* specific .lds file */
>  #define CONFIG_SPL_LDSCRIPT
>  "board/samsung/smdk5250/smdk5250-uboot-spl.lds"
>  #define CONFIG_SPL_TEXT_BASE   0x02023400
> --
> 1.7.0.4
>
>
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 5/9] EXYNOS5: DWMMC: API to set mmc clock divisor

[Simon Glass]

Hi Amar,

On Mon, Dec 17, 2012 at 3:19 AM, Amar  wrote:

> This API computes the divisor value based on MPLL clock and
> writes it into the FSYS1 register.
>
> Signed-off-by: Amar 
> ---
>  arch/arm/cpu/armv7/exynos/clock.c  |   39
> ++-
>  arch/arm/include/asm/arch-exynos/clk.h |1 +
>  2 files changed, 38 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/cpu/armv7/exynos/clock.c
> b/arch/arm/cpu/armv7/exynos/clock.c
> index 731bbff..6517296 100644
> --- a/arch/arm/cpu/armv7/exynos/clock.c
> +++ b/arch/arm/cpu/armv7/exynos/clock.c
> @@ -379,7 +379,7 @@ static unsigned long exynos4_get_mmc_clk(int dev_index)
> (struct exynos4_clock *)samsung_get_base_clock();
> unsigned long uclk, sclk;
> unsigned int sel, ratio, pre_ratio;
> -   int shift;
> +   int shift = 0;
>
> sel = readl(&clk->src_fsys);
> sel = (sel >> (dev_index << 2)) & 0xf;
> @@ -428,7 +428,7 @@ static unsigned long exynos5_get_mmc_clk(int dev_index)
> (struct exynos5_clock *)samsung_get_base_clock();
> unsigned long uclk, sclk;
> unsigned int sel, ratio, pre_ratio;
> -   int shift;
> +   int shift = 0;
>
> sel = readl(&clk->src_fsys);
> sel = (sel >> (dev_index << 2)) & 0xf;
> @@ -526,6 +526,41 @@ static void exynos5_set_mmc_clk(int dev_index,
> unsigned int div)
> writel(val, addr);
>  }
>
> +/* exynos5: set the mmc clock div ratio in fsys1 */
> +int exynos5_mmc_set_clk_div(int dev_index)
>

Shouldn't this take a periph_id instead of a dev_index?


> +{
> +   struct exynos5_clock *clk =
> +   (struct exynos5_clock *)samsung_get_base_clock();
> +   unsigned int addr;
> +   unsigned int clock;
> +   unsigned int tmp;
> +   unsigned int i;
> +
> +   /* get mpll clock */
> +   clock = get_pll_clk(MPLL) / 100;
> +
> +   /*
> +* CLK_DIV_FSYS1
> +* MMC0_PRE_RATIO [15:8], MMC0_RATIO [3:0]
> +* CLK_DIV_FSYS2
> +* MMC2_PRE_RATIO [15:8], MMC2_RATIO [3:0]
> +*/
> +   if (dev_index < 2) {
> +   addr = (unsigned int)&clk->div_fsys1;
> +   } else {
> +   addr = (unsigned int)&clk->div_fsys2;
> +   }
> +
> +   tmp = readl(addr) & ~FSYS1_MMC0_DIV_MASK;
> +   for (i = 0; i <= 0xf; i++) {
> +   if ((clock / (i + 1)) <= 400) {
> +   writel(tmp | i << 0, addr);
> +   break;
> +   }
> +   }
> +   return 0;
> +}
> +
>  /* get_lcd_clk: return lcd clock frequency */
>  static unsigned long exynos4_get_lcd_clk(void)
>  {
> diff --git a/arch/arm/include/asm/arch-exynos/clk.h
> b/arch/arm/include/asm/arch-exynos/clk.h
> index ff155d8..b0ecdd4 100644
> --- a/arch/arm/include/asm/arch-exynos/clk.h
> +++ b/arch/arm/include/asm/arch-exynos/clk.h
> @@ -36,6 +36,7 @@ unsigned long get_pwm_clk(void);
>  unsigned long get_uart_clk(int dev_index);
>  unsigned long get_mmc_clk(int deV_index);
>  void set_mmc_clk(int dev_index, unsigned int div);
> +int exynos5_mmc_set_clk_div(int dev_index);
>  unsigned long get_lcd_clk(void);
>  void set_lcd_clk(void);
>  void set_mipi_clk(void);
> --
> 1.7.0.4
>
>
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 4/9] EXYNOS5: DWMMC: Added dt support for DWMMC

[Simon Glass]

Hi Amar,

On Mon, Dec 17, 2012 at 3:19 AM, Amar  wrote:

> Signed-off-by: Amar 
>

Good to see this patch! Please can you add a short commit message?


> ---

 arch/arm/include/asm/arch-exynos/dwmmc.h |4 +
>  drivers/mmc/exynos_dw_mmc.c  |  117
> --
>  include/dwmmc.h  |4 +
>  3 files changed, 119 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm/include/asm/arch-exynos/dwmmc.h
> b/arch/arm/include/asm/arch-exynos/dwmmc.h
> index 8acdf9b..92352df 100644
> --- a/arch/arm/include/asm/arch-exynos/dwmmc.h
> +++ b/arch/arm/include/asm/arch-exynos/dwmmc.h
> @@ -27,6 +27,9 @@
>  #define DWMCI_SET_DRV_CLK(x)   ((x) << 16)
>  #define DWMCI_SET_DIV_RATIO(x) ((x) << 24)
>
> +#ifdef CONFIG_OF_CONTROL
> +unsigned int exynos_dwmmc_init(const void *blob);
> +#else
>  int exynos_dwmci_init(u32 regbase, int bus_width, int index);
>
>  static inline unsigned int exynos_dwmmc_init(int index, int bus_width)
> @@ -34,3 +37,4 @@ static inline unsigned int exynos_dwmmc_init(int index,
> int bus_width)
> unsigned int base = samsung_get_base_mmc() + (0x1 * index);
> return exynos_dwmci_init(base, bus_width, index);
>  }
> +#endif
> diff --git a/drivers/mmc/exynos_dw_mmc.c b/drivers/mmc/exynos_dw_mmc.c
> index 72a31b7..3b3e3e5 100644
> --- a/drivers/mmc/exynos_dw_mmc.c
> +++ b/drivers/mmc/exynos_dw_mmc.c
> @@ -19,23 +19,38 @@
>   */
>
>  #include 
> -#include 
>  #include 
> +#include 
> +#include 
> +#include 
>  #include 
>  #include 
> +#include 
> +
> +#defineDWMMC_MAX_CH_NUM4
> +#defineDWMMC_MAX_FREQ  5200
> +#defineDWMMC_MIN_FREQ  40
> +#defineDWMMC_MMC0_CLKSEL_VAL   0x03030001
> +#defineDWMMC_MMC2_CLKSEL_VAL   0x03020001
>

What do these last two values mean? I think clock setting should be done in
clock.c, not here.


>
>  static char *EXYNOS_NAME = "EXYNOS DWMMC";
>
>  static void exynos_dwmci_clksel(struct dwmci_host *host)
>  {
> -   u32 val;
> -   val = DWMCI_SET_SAMPLE_CLK(DWMCI_SHIFT_0) |
> -   DWMCI_SET_DRV_CLK(DWMCI_SHIFT_0) | DWMCI_SET_DIV_RATIO(0);
> +   dwmci_writel(host, DWMCI_CLKSEL, host->clksel_val);
> +}
>
> -   dwmci_writel(host, DWMCI_CLKSEL, val);
> +unsigned int exynos_dwmci_get_clk(int dev_index)
> +{
> +   return get_mmc_clk(dev_index);
>  }
>
> +#ifdef CONFIG_OF_CONTROL
> +static int exynos_dwmci_init(u32 regbase, int bus_width,
> +   int index, u32 *timing)
> +#else
>  int exynos_dwmci_init(u32 regbase, int bus_width, int index)
> +#endif
>

I'm really not keen on having the same function with different signatures.
My first question is whether we need to support operation without
CONFIG_OF_CONTROL. If so, I suggest having an init routine that takes an
FDT blob as a parameter, and a separate add_port function which can be
called by non-FDT-enabled board files. The init routine will call the
add_port function for each port it finds in the FDT.

Also please can you briefly comment non-trivial functions?


>  {
> struct dwmci_host *host = NULL;
> host = malloc(sizeof(struct dwmci_host));
> @@ -44,14 +59,104 @@ int exynos_dwmci_init(u32 regbase, int bus_width, int
> index)
> return 1;
> }
>
> +   /* set the clock divisor - clk_div_fsys for mmc */
> +   if (exynos5_mmc_set_clk_div(index)) {
> +   debug("mmc clock div set failed\n");
> +   return -1;
> +   }
> +
> host->name = EXYNOS_NAME;
> host->ioaddr = (void *)regbase;
> host->buswidth = bus_width;
> +#ifdef CONFIG_OF_CONTROL
> +   host->clksel_val = (DWMCI_SET_SAMPLE_CLK(timing[0]) |
> +   DWMCI_SET_DRV_CLK(timing[1]) |
> +   DWMCI_SET_DIV_RATIO(timing[2]));
> +#else
> +   if (0 == index)
> +   host->clksel_val = DWMMC_MMC0_CLKSEL_VAL;
> +   if (2 == index)
> +   host->clksel_val = DWMMC_MMC2_CLKSEL_VAL;
> +#endif
> host->clksel = exynos_dwmci_clksel;
> host->dev_index = index;
> +   host->mmc_clk = exynos_dwmci_get_clk;
>
> -   add_dwmci(host, 5200, 40);
> +   add_dwmci(host, DWMMC_MAX_FREQ, DWMMC_MIN_FREQ);
>
> return 0;
>  }
>
> +#ifdef CONFIG_OF_CONTROL
> +unsigned int exynos_dwmmc_init(const void *blob)
> +{
> +   u32 base;
> +   int index, bus_width;
> +   int node_list[DWMMC_MAX_CH_NUM];
> +   int err = 0;
> +   int dev_id, flag;
> +   u32 timing[3];
> +   int count, i;
> +
> +   count = fdtdec_find_aliases_for_id(blob, "dwmmc",
> +   COMPAT_SAMSUNG_EXYNOS5_DWMMC, node_list,
> +   DWMMC_MAX_CH_NUM);
> +
> +   for (i = 0; i < count; i++) {
> +   int node = node_list[i];
> +
> +   if (node <= 0)
> +   continue

Re: [U-Boot] [PATCH 2/9] EXYNOS5: FDT: Add DWMMC device node data

[Simon Glass]

Hi Amar,

On Mon, Dec 17, 2012 at 3:19 AM, Amar  wrote:
> Add DWMMC device node data for exynos5
>
> Signed-off-by: Amar 
> ---
>  arch/arm/dts/exynos5250.dtsi  |   32 
> +
>  board/samsung/dts/exynos5250-smdk5250.dts |   24 +

Do you also have a binding file for this please?

>  2 files changed, 56 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/dts/exynos5250.dtsi b/arch/arm/dts/exynos5250.dtsi
> index 1008797..b701ae5 100644
> --- a/arch/arm/dts/exynos5250.dtsi
> +++ b/arch/arm/dts/exynos5250.dtsi
> @@ -138,4 +138,36 @@
> reg = <0x131b 0x30>;
> interrupts = <0 130 0>;
> };
> +
> +   dwmmc@1220 {
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +   compatible = "samsung,exynos5250-dwmmc";
> +   reg = <0x1220 0x1000>;
> +   interrupts = <0 75 0>;
> +   };
> +
> +   dwmmc@1221 {
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +   compatible = "samsung,exynos5250-dwmmc";
> +   reg = <0x1221 0x1000>;
> +   interrupts = <0 76 0>;
> +   };
> +
> +   dwmmc@1222 {
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +   compatible = "samsung,exynos5250-dwmmc";
> +   reg = <0x1222 0x1000>;
> +   interrupts = <0 77 0>;
> +   };
> +
> +   dwmmc@1223 {
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +   compatible = "samsung,exynos5250-dwmmc";
> +   reg = <0x1223 0x1000>;
> +   interrupts = <0 78 0>;
> +   };
>  };
> diff --git a/board/samsung/dts/exynos5250-smdk5250.dts 
> b/board/samsung/dts/exynos5250-smdk5250.dts
> index a8e62da..b1b8d71 100644
> --- a/board/samsung/dts/exynos5250-smdk5250.dts
> +++ b/board/samsung/dts/exynos5250-smdk5250.dts
> @@ -30,6 +30,10 @@
> spi2 = "/spi@12d4";
> spi3 = "/spi@131a";
> spi4 = "/spi@131b";
> +   dwmmc0 = "/dwmmc@1220";
> +   dwmmc1 = "/dwmmc@1221";
> +   dwmmc2 = "/dwmmc@1222";
> +   dwmmc3 = "/dwmmc@1223";
> };
>
> sromc@1225 {
> @@ -59,4 +63,24 @@
> compatible = "wolfson,wm8994-codec";
> };
> };
> +
> +   dwmmc@1220 {
> +   index = <0>;

Do you really need the index? You have the numbering from the aliaes I think.

> +   bus-width = <8>;
> +   timing = <1 3 3>;

Might need a "samsung," prefix on these?

> +   };
> +
> +   dwmmc@1221 {
> +   status = "disabled";
> +   };
> +
> +   dwmmc@1222 {
> +   index = <2>;
> +   bus-width = <4>;
> +   timing = <1 2 3>;
> +   };
> +
> +   dwmmc@1223 {
> +   status = "disabled";
> +   };
>  };
> --
> 1.7.0.4
>

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

Re: [U-Boot] [PATCH 1/9] FDT: Add compatible string for DWMMC

[Simon Glass]

On Mon, Dec 17, 2012 at 3:19 AM, Amar  wrote:
> Add required compatible information for DWMMC driver.
>
> Signed-off-by: Amar 

Acked-by: Simon Glass 

> ---
>  include/fdtdec.h |1 +
>  lib/fdtdec.c |1 +
>  2 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/include/fdtdec.h b/include/fdtdec.h
> index 539bb1b..f09c281 100644
> --- a/include/fdtdec.h
> +++ b/include/fdtdec.h
> @@ -74,6 +74,7 @@ enum fdt_compat_id {
> COMPAT_SAMSUNG_EXYNOS5_SOUND,   /* Exynos Sound */
> COMPAT_WOLFSON_WM8994_CODEC,/* Wolfson WM8994 Sound Codec */
> COMPAT_SAMSUNG_EXYNOS_SPI,  /* Exynos SPI */
> +   COMPAT_SAMSUNG_EXYNOS5_DWMMC,   /* Exynos5 DWMMC controller */
>
> COMPAT_COUNT,
>  };
> diff --git a/lib/fdtdec.c b/lib/fdtdec.c
> index 44c249d..6597661 100644
> --- a/lib/fdtdec.c
> +++ b/lib/fdtdec.c
> @@ -51,6 +51,7 @@ static const char * const compat_names[COMPAT_COUNT] = {
> COMPAT(SAMSUNG_EXYNOS5_SOUND, "samsung,exynos-sound"),
> COMPAT(WOLFSON_WM8994_CODEC, "wolfson,wm8994-codec"),
> COMPAT(SAMSUNG_EXYNOS_SPI, "samsung,exynos-spi"),
> +   COMPAT(SAMSUNG_EXYNOS5_DWMMC, "samsung,exynos5250-dwmmc"),
>  };
>
>  const char *fdtdec_get_compatible(enum fdt_compat_id id)
> --
> 1.7.0.4
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot, 1/2] spi: Add progress percentage and write speed to `sf update`

[Simon Glass]

Hi Tom,

On Wed, Dec 19, 2012 at 5:03 PM, Tom Rini  wrote:
> On Thu, Dec 20, 2012 at 12:14:00AM +0100, Wolfgang Denk wrote:
>> Dear Tom Rini,
>>
>> In message <20121219225945.GF14589@bill-the-cat> you wrote:
>> >
>> ...
>> > With this change, applied to u-boot/master.
>>
>> Argh :-(
>>
>> Can we please undo this somehow?  This does not fit at all
>> conceptually.  U-Boot is supposed to use the good ols UNIX philosophy
>> of being terse by default, and special casing one specific storage
>> device makes no sense at all to me.
>
> We need to fix some of the underlying problems so that we're consistent
> here.  Sometimes we have output (network #), sometimes we don't.
> Sometimes we have a speed (network, filesystem load), sometimes we
> don't.  I'd be quite happy to have a uniform output and a uniform ON/OFF
> switch.

I'm happy to do something like this. Obviously we want a config, but
do we also want an env variable to control it? Could be useful.

And at the risk of killing it with feature creep, perhaps we could
have two levels of verbosity: progress (which repeatedly updates on
the same line) and notice (which does not). That might take care of
Jagannadha's use case also.

Regards,
Simon

>
> --
> Tom
>
> ___
> 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] configuring u-boot for custom board based on beaglebone(am335xx_evm)

[Tom Rini]

On Wed, Dec 19, 2012 at 07:19:03AM -0800, Pavan wrote:

> Hi Yegor,
> 
> Thanks for quick reply,
> 
>   in u-boot source code to change the beagleboard -xM pin mux we
> can change by updating the file board/ti/beagle/beagle.h by changing the
> MUX_BEAGLE() micro ,how can i access the same thing for beaglebone?

You don't.  We intentionally only enable the muxes that are required
rather than every single possible mux.  You need to do the muxing in the
kernel.  And any clocking too, assuming it's not one fo the ones already
enabled.

-- 
Tom


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

Re: [U-Boot] [U-Boot,v2,2/2] spi: Add SPI flash test

[Tom Rini]

On Thu, Dec 20, 2012 at 12:19:24AM +0100, Wolfgang Denk wrote:
> Dear Tom Rini,
> 
> In message <20121219225956.GG14589@bill-the-cat> you wrote:
> > 
> > Applied to u-boot/master, thanks!
> 
> Please see my comment from a few minutes ago.
> 
> We're adding just dead code here.  This makes no sense to me.

I'll add this option to am335x_evm as soon as I can sneak over to the
office, flip the dip switches so that the SPI flash is available and
double check that yes, really, Simon tested the code one point before
posting.  Yeah, -1 to me for adding this before we added a board using
it, but it's a useful thing.  Q/A folks here at least will be all 'oh
boy!' when I tell them that starting with the next release they can use
this.

-- 
Tom


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

Re: [U-Boot] [U-Boot, 1/2] spi: Add progress percentage and write speed to `sf update`

[Tom Rini]

On Thu, Dec 20, 2012 at 12:14:00AM +0100, Wolfgang Denk wrote:
> Dear Tom Rini,
> 
> In message <20121219225945.GF14589@bill-the-cat> you wrote:
> > 
> ...
> > With this change, applied to u-boot/master.
> 
> Argh :-(
> 
> Can we please undo this somehow?  This does not fit at all
> conceptually.  U-Boot is supposed to use the good ols UNIX philosophy
> of being terse by default, and special casing one specific storage
> device makes no sense at all to me.

We need to fix some of the underlying problems so that we're consistent
here.  Sometimes we have output (network #), sometimes we don't.
Sometimes we have a speed (network, filesystem load), sometimes we
don't.  I'd be quite happy to have a uniform output and a uniform ON/OFF
switch.

-- 
Tom


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

Re: [U-Boot] Conflicting commits for seaboard USB keyboard handling

[Allen Martin]

On Wed, Dec 19, 2012 at 02:42:24PM -0800, Albert ARIBAUD wrote:
> Hi Allen,
> 
> > Hi Albert, I did a merge of u-boot/master into u-boot-arm/master and
> > resolved the conflicts and I've pushed the result to:
> > 
> >  git://github.com/arm000/u-boot.git
> >  branch: u-boot-arm-merge-resolved
> > 
> > I resolved all the conflicts, but the only ones I claim I did
> > correctly were the changes to:
> > 
> >  include/configs/seaboard.h
> >  include/configs/tegra-common-post.h
> > 
> > the other conflicts were not related to tegra.
> > 
> > If you want a new pull request, you'll first have to unroll the
> > previously merged tegra patches from u-boot-arm/master so I can give
> > you a conflict free merge request.
> 
> Thanks Allen, this branch is what I wanted exactly -- I don't want to
> ask for a rollback. As soon as I am sure about the samsung branch, I'll
> merge all "fix" branches into ARM.

Ok, let me know if you have any problems resolving and I'll try to
help the best I can.  

Tom, you'll need to rebase u-boot-tegra/next on top of this, and there
will be conflicts when you do.  I've resolved those as well for
reference and pushed to:

  git://github.com/arm000/u-boot.git
  branch: u-boot-tegra-next-rebased

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

Re: [U-Boot] [PATCH 1/3] spl: Change PAD_TO to CONFIG_SPL_PAD_TO

[Kim Phillips]

On Thu, 6 Dec 2012 17:33:16 -0600
Scott Wood  wrote:

> This was already used by some SPL targets, and allows the pad amount to
> be specified by board config headers rather than only in makefile
> fragments.
> 
> Also supply a pad-to of zero if the variable is undefined.  It works
> without this, but this avoids relying on undocumented behavior.
> 
> Signed-off-by: Scott Wood 
> ---
>  Makefile|6 +-
>  README  |4 
>  board/ait/cam_enc_4xx/config.mk |2 +-
>  3 files changed, 10 insertions(+), 2 deletions(-)

Despite this first patch falling outside of my domain, I
applied all 3 patches to u-boot-mpc83xx/next.

Thanks,

Kim

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

Re: [U-Boot] [PATCH 1/2] spi: Add progress percentage and write speed to `sf update`

[Scott Wood]

On 12/19/2012 05:20:07 PM, Simon Glass wrote:

Hi Wolfgang,

On Wed, Dec 19, 2012 at 3:10 PM, Wolfgang Denk  wrote:
> Dear Simon Glass,
>
> In message <1348878482-1730-1-git-send-email-...@chromium.org> you  
wrote:

>> From: James Miller 
>>
>> Output a progress update only at most 10 times per second, to avoid
>> saturating (and waiting on) the console. Make the summary line
>> to fit on a single line. Make sure that cursor sits at the end of
>> each update line instead of the beginning.
>>
>> Sample output:
>>
>> SF: Detected W25Q32 with page size 4 KiB, total 4 MiB
>> Update SPI
>> 1331200 bytes written, 2863104 bytes skipped in 21.912s, speed  
199728 B/s

>
> I dislike making commands more verbose then needed, or helpful.  Of
> course the latter may be considered a matter of taste, but first of
> all you also add code size here for questionable benefit.
>
> I object against this patch:
>
> 1) I cannot see what is so special in the "sf" command that it needs
>such handling, while commands accessing NOR or NAND flash or
>SDCard or any other storage devices don't.
>
>If there is an agreement that this feature should be added, then  
it

>should be done in a general way that can be used everywhere.
>
>[Note that I doubt that "if".]

Hmmm I suppose that is a good point. The main issue with SPI flash is
that it is extremely slow, and writing a few MB can take a minute or
so. The 'sf update' command was intended to do a smart update, and the
progress is useful for that. Other storage types are not so bad.


NOR can be pretty slow as well -- and it does have a progress indicator  
in U-Boot (albeit a simpler one).


NAND has a progress meter on erase, and for larger transfers it could  
probably use one on read/write as well.


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

Re: [U-Boot] [PATCH 1/2] spi: Add progress percentage and write speed to `sf update`

[Simon Glass]

Hi Wolfgang,

On Wed, Dec 19, 2012 at 3:10 PM, Wolfgang Denk  wrote:
> Dear Simon Glass,
>
> In message <1348878482-1730-1-git-send-email-...@chromium.org> you wrote:
>> From: James Miller 
>>
>> Output a progress update only at most 10 times per second, to avoid
>> saturating (and waiting on) the console. Make the summary line
>> to fit on a single line. Make sure that cursor sits at the end of
>> each update line instead of the beginning.
>>
>> Sample output:
>>
>> SF: Detected W25Q32 with page size 4 KiB, total 4 MiB
>> Update SPI
>> 1331200 bytes written, 2863104 bytes skipped in 21.912s, speed 199728 B/s
>
> I dislike making commands more verbose then needed, or helpful.  Of
> course the latter may be considered a matter of taste, but first of
> all you also add code size here for questionable benefit.
>
> I object against this patch:
>
> 1) I cannot see what is so special in the "sf" command that it needs
>such handling, while commands accessing NOR or NAND flash or
>SDCard or any other storage devices don't.
>
>If there is an agreement that this feature should be added, then it
>should be done in a general way that can be used everywhere.
>
>[Note that I doubt that "if".]

Hmmm I suppose that is a good point. The main issue with SPI flash is
that it is extremely slow, and writing a few MB can take a minute or
so. The 'sf update' command was intended to do a smart update, and the
progress is useful for that. Other storage types are not so bad.

Yes it makes sense (if we want this sort of feature) to make it more
general feature so that it can be used by all devices. I think it
could be done, and then enabled by a CONFIG. We could perhaps make it
so that the progress info never appears unless the operation takes at
least a few seconds.

>
> 2) The code size hurts (at least in some cases). Such code should be
>optional. Please make it configurable.

OK see above. I will take a look.

Regards,
Simon

>
>
> 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
> A witty saying proves nothing, but saying  something  pointless  gets
> people's attention.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot,v2,2/2] spi: Add SPI flash test

[Wolfgang Denk]

Dear Tom Rini,

In message <20121219225956.GG14589@bill-the-cat> you wrote:
> 
> Applied to u-boot/master, thanks!

Please see my comment from a few minutes ago.

We're adding just dead code here.  This makes no sense to me.

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
Computers are not intelligent.  They only think they are.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot, v2 2/6] cmd_sf: Add print messages on flash read/write commands

[Wolfgang Denk]

Dear Jagannadha Sutradharudu Teki,

In message <1355934463-24319-2-git-send-email-jagannadh.t...@gmail.com> you 
wrote:
> This patch adds a print messages while using 'sf read' and
> 'sf write' commands to make sure that how many bytes read/written
> from/into flash device.
> 
> Signed-off-by: Jagannadha Sutradharudu Teki 
> ---
> Changes in v2:
> Move print messages from spi_flash.c into cmd_sf.c

Please see previous comments, especially

http://article.gmane.org/gmane.comp.boot-loaders.u-boot/149663
http://article.gmane.org/gmane.comp.boot-loaders.u-boot/149665

I object against adding more and more verbosity and code size, and in
an inconsistent way.

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
F u cn rd ths u cnt spl wrth a dm!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot, v2 1/6] cmd_sf: Add print messages on flash erase command

[Wolfgang Denk]

Dear Jagannadha Sutradharudu Teki,

In message <1355934463-24319-1-git-send-email-jagannadh.t...@gmail.com> you 
wrote:
> This patch adds a print messages while using 'sf erase' command
> to make sure that how many bytes erased in flash device.
> 
> Signed-off-by: Jagannadha Sutradharudu Teki 
> ---
> Changes in v2:
>   Move print messages from spi_flash.c into cmd_sf.c

This makes little sense to me.  Please see all comments here:

http://article.gmane.org/gmane.comp.boot-loaders.u-boot/149663

and here:

http://article.gmane.org/gmane.comp.boot-loaders.u-boot/149665



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
Programmer's Lament: (Shakespeare, Macbeth, Act I, Scene vii)
"That we but teach bloody instructions,
which, being taught, return to plague the inventor..."
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot, 1/2] spi: Add progress percentage and write speed to `sf update`

[Wolfgang Denk]

Dear Tom Rini,

In message <20121219225945.GF14589@bill-the-cat> you wrote:
> 
...
> With this change, applied to u-boot/master.

Argh :-(

Can we please undo this somehow?  This does not fit at all
conceptually.  U-Boot is supposed to use the good ols UNIX philosophy
of being terse by default, and special casing one specific storage
device makes no sense at all to me.

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
I am pleased to see that we have differences.  May we together become
greater than the sum of both of us.
-- Surak of Vulcan, "The Savage Curtain", stardate 5906.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2] spi: Add SPI flash test

[Wolfgang Denk]

Dear Simon Glass,

In message <1348878482-1730-2-git-send-email-...@chromium.org> you wrote:
> It is useful to have a basic SPI flash test, which tests that the SPI chip,
> the SPI bus and the driver are behaving.
> 
> This test erases part of the flash, writes data and reads it back as a
> sanity check that all is well.
> 
> Use CONFIG_SF_TEST to enable it.

Adding dead code ?

Please don't.

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
No, I'm not going to explain it. If you  can't  figure  it  out,  you
didn't want to know anyway... :-)
   - Larry Wall in <1991aug7.180856.2...@netlabs.com>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] spi: Add progress percentage and write speed to `sf update`

[Wolfgang Denk]

Dear Simon Glass,

In message <1348878482-1730-1-git-send-email-...@chromium.org> you wrote:
> From: James Miller 
> 
> Output a progress update only at most 10 times per second, to avoid
> saturating (and waiting on) the console. Make the summary line
> to fit on a single line. Make sure that cursor sits at the end of
> each update line instead of the beginning.
> 
> Sample output:
> 
> SF: Detected W25Q32 with page size 4 KiB, total 4 MiB
> Update SPI
> 1331200 bytes written, 2863104 bytes skipped in 21.912s, speed 199728 B/s

I dislike making commands more verbose then needed, or helpful.  Of
course the latter may be considered a matter of taste, but first of
all you also add code size here for questionable benefit.

I object against this patch:

1) I cannot see what is so special in the "sf" command that it needs
   such handling, while commands accessing NOR or NAND flash or
   SDCard or any other storage devices don't.

   If there is an agreement that this feature should be added, then it
   should be done in a general way that can be used everywhere.

   [Note that I doubt that "if".]

2) The code size hurts (at least in some cases). Such code should be
   optional. Please make it configurable.


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
A witty saying proves nothing, but saying  something  pointless  gets
people's attention.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot,v2] Add a simple load option to setexpr

[Tom Rini]

On Thu, Nov 01, 2012 at 04:21:14PM -, Joe Hershberger wrote:

> Make setexpr accept a 2 parameter variant that will simply load a value
> into a variable.  This is useful for loading a value from memory.
> 
> Signed-off-by: Joe Hershberger 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot,1/3] fw_env: fix type of len

[Tom Rini]

On Sat, Nov 10, 2012 at 07:47:45PM -, Mike Frysinger wrote:

> This variable is assigned by a size_t, and is printed that way, but is
> incorrectly declared as an int.  Which means we get warnings:
> fw_env.c: In function 'fw_setenv':
> fw_env.c:409:5: warning: format '%zu' expects argument of type 'size_t',
>   but argument 3 has type 'int' [-Wformat]
> 
> Signed-off-by: Mike Frysinger 
> Acked-by: Joe Hershberger 

For the series, applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot, 1/2] spi: Add progress percentage and write speed to `sf update`

[Tom Rini]

On Wed, Dec 19, 2012 at 03:59:50PM -0500, Tom Rini wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On 12/19/12 15:46, Simon Glass wrote:
> > Hi Tom,
> > 
> > On Wed, Dec 19, 2012 at 12:43 PM, Tom Rini  wrote:
> >> On Fri, Sep 28, 2012 at 02:28:00PM -, Simon Glass wrote:
> >> 
> >>> From: James Miller 
> >>> 
> >>> Output a progress update only at most 10 times per second, to 
> >>> avoid saturating (and waiting on) the console. Make the
> >>> summary line to fit on a single line. Make sure that cursor
> >>> sits at the end of each update line instead of the beginning.
> >>> 
> >>> Sample output:
> >>> 
> >>> SF: Detected W25Q32 with page size 4 KiB, total 4 MiB Update 
> >>> SPI 1331200 bytes written, 2863104 bytes skipped in 21.912s, 
> >>> speed 199728 B/s
> >>> 
> >>> time: 21.919 seconds, 21919 ticks Skipping verify
> >>> 
> >>> Signed-off-by: Simon Glass  Signed-off-by: 
> >>> James Miller  Signed-off-by: Taylor 
> >>> Hutt 
> >> 
> >> With ELDK 4.2: cmd_sf.c:80: warning: type qualifiers ignored on 
> >> function return type
> > 
> > Interesting...
> > 
> >> 
> >> Unless I'm missing something, this is the right fix: -static 
> >> const ulong bytes_per_second(unsigned int len, ulong start_ms) 
> >> +static ulong bytes_per_second(unsigned int len, ulong start_ms)
> >> 
> >> Because no, we aren't returning a const.  If that sounds right 
> >> I'll fix inline and add my Signed-off-by.
> > 
> > Yes that looks right, thanks for doing that. Did Mike get in touch 
> > re these?
> 
> No, but I've read them again myself and they seem sane enough to grab
> as Mike hasn't been active recently.  And I'll push this shortly then,
> thanks!

With this change, applied to u-boot/master.

-- 
Tom


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

Re: [U-Boot] [U-Boot,v2,2/2] spi: Add SPI flash test

[Tom Rini]

On Mon, Oct 08, 2012 at 01:16:02PM -, Simon Glass wrote:

> It is useful to have a basic SPI flash test, which tests that the SPI chip,
> the SPI bus and the driver are behaving.
> 
> This test erases part of the flash, writes data and reads it back as a
> sanity check that all is well.
> 
> Use CONFIG_SF_TEST to enable it.
> 
> Signed-off-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] coldfire: eb_cpu5282: fix: boot from internal flash

[Tom Rini]

On Tue, Nov 20, 2012 at 02:06:25AM -, e...@bus-elektronik.de wrote:

> From: "Jens Scharsig (BuS Elektronik)" 
> 
> * By a sequence of unfavorable conditions in the config header file, the 
> eb_cpu5282
>   booting from  internal stopped after relocation. Blame it is a faulty value 
> of
>   CONFIG_SYS_MONITOR_BASE. This patch fix this by replace the wrong condition 
> in
>   config header with option in board.cfg
> 
> Signed-off-by: Jens Scharsig (BuS Elektronik) 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] split nand writes

[Scott Wood]

On 12/19/2012 09:43:01 AM, Jaap de Jong wrote:

Hi All,
suppose the image I want to flash is bigger than the available ram in  
the unit.

Is there a way to copy the image f.i. in pieces into the flash?
nand write should have a 'continue on last block' option for that  
purpose.


Something like that would be nice.

These patches are relevant:
http://patchwork.ozlabs.org/patch/204939/
http://patchwork.ozlabs.org/patch/204940/

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

Re: [U-Boot] Conflicting commits for seaboard USB keyboard handling

[Albert ARIBAUD]

Hi Allen,

> Hi Albert, I did a merge of u-boot/master into u-boot-arm/master and
> resolved the conflicts and I've pushed the result to:
> 
>  git://github.com/arm000/u-boot.git
>  branch: u-boot-arm-merge-resolved
> 
> I resolved all the conflicts, but the only ones I claim I did
> correctly were the changes to:
> 
>  include/configs/seaboard.h
>  include/configs/tegra-common-post.h
> 
> the other conflicts were not related to tegra.
> 
> If you want a new pull request, you'll first have to unroll the
> previously merged tegra patches from u-boot-arm/master so I can give
> you a conflict free merge request.

Thanks Allen, this branch is what I wanted exactly -- I don't want to
ask for a rollback. As soon as I am sure about the samsung branch, I'll
merge all "fix" branches into ARM.

> -Allen
> -- 
> nvpublic

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

Re: [U-Boot] [PATCH 03/10] x86: Permit bootstage and timer data to be used prior to relocation

[Graeme Russ]

Hi Simon,

On Wed, Dec 19, 2012 at 12:32 PM, Simon Glass  wrote:
> Hi Graeme,
>
> On Fri, Dec 14, 2012 at 2:35 PM, Simon Glass  wrote:
>>
>> Hi Graeme,
>>
>>
>> On Fri, Dec 14, 2012 at 2:15 PM, Graeme Russ 
>> wrote:
>> > Hi Simon,
>> >
>> > On 15/12/12 08:13, Simon Glass wrote:
>> >> It is useful to be able to access the timer before U-Boot has relocated
>> >> so that we can fully support bootstage.
>> >>
>> >> Move the relevant variables to the data region to support this.
>> >>
>> >> Signed-off-by: Simon Glass 
>> >> ---
>> >>  arch/x86/cpu/coreboot/coreboot.c |4 ++--
>> >>  arch/x86/cpu/interrupts.c|2 +-
>> >>  arch/x86/lib/timer.c |2 +-
>> >>  3 files changed, 4 insertions(+), 4 deletions(-)
>> >>
>> >> diff --git a/arch/x86/cpu/coreboot/coreboot.c
>> >> b/arch/x86/cpu/coreboot/coreboot.c
>> >> index 9c9431e..22474f5 100644
>> >> --- a/arch/x86/cpu/coreboot/coreboot.c
>> >> +++ b/arch/x86/cpu/coreboot/coreboot.c
>> >> @@ -68,8 +68,8 @@ int board_early_init_r(void)
>> >>  void show_boot_progress(int val)
>> >>  {
>> >>  #if MIN_PORT80_KCLOCKS_DELAY
>> >> - static uint32_t prev_stamp;
>> >> - static uint32_t base;
>> >> + static uint32_t prev_stamp __attribute__((section(".data")));
>> >> + static uint32_t base __attribute__((section(".data")));
>> >
>> > NAK
>> >
>> > This may work for coreboot where SDRAM is already initialised and you've
>> > loaded U-Boot into RAM, but it will not work when U-Boot is in Flash as
>> > all
>> > sections (including .data) are read-only until after relocation.
>> >
>> > The stack and Global Data are the only guaranteed read/write locations
>> > prior to relocation
>>
>> Ah yes, I was thinking of your comment that all boards would move to
>> use coreboot. If that is not the case, then I will need to add
>> something to global data for the timer. And I don't want to do that
>> while generic board is in progress since it creates conflicts.

I'm trying to remember the context of my comment regarding only having
coreboot boards. But anyway, not having any writeable data prior to
relocation (other than the stack and gd) is a fundamental principle
that we cannot simply avoid (although I must admit I don't know what
the go is with SPL and U-Boot relocation).

> Any thoughts on this point, please? I presume at least I can use RAM once
> dram_init() is called. But when running from coreboot the RAM is already set
> up...

You will need to use global data to store the static variables. That's
what the other arches do

Regards,

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

Re: [U-Boot] [PATCH 03/10] x86: Permit bootstage and timer data to be used prior to relocation

[Simon Glass]

Hi Graeme,

On Wed, Dec 19, 2012 at 1:39 PM, Graeme Russ  wrote:
> Hi Simon,
>
> On Wed, Dec 19, 2012 at 12:32 PM, Simon Glass  wrote:
>> Hi Graeme,
>>
>> On Fri, Dec 14, 2012 at 2:35 PM, Simon Glass  wrote:
>>>
>>> Hi Graeme,
>>>
>>>
>>> On Fri, Dec 14, 2012 at 2:15 PM, Graeme Russ 
>>> wrote:
>>> > Hi Simon,
>>> >
>>> > On 15/12/12 08:13, Simon Glass wrote:
>>> >> It is useful to be able to access the timer before U-Boot has relocated
>>> >> so that we can fully support bootstage.
>>> >>
>>> >> Move the relevant variables to the data region to support this.
>>> >>
>>> >> Signed-off-by: Simon Glass 
>>> >> ---
>>> >>  arch/x86/cpu/coreboot/coreboot.c |4 ++--
>>> >>  arch/x86/cpu/interrupts.c|2 +-
>>> >>  arch/x86/lib/timer.c |2 +-
>>> >>  3 files changed, 4 insertions(+), 4 deletions(-)
>>> >>
>>> >> diff --git a/arch/x86/cpu/coreboot/coreboot.c
>>> >> b/arch/x86/cpu/coreboot/coreboot.c
>>> >> index 9c9431e..22474f5 100644
>>> >> --- a/arch/x86/cpu/coreboot/coreboot.c
>>> >> +++ b/arch/x86/cpu/coreboot/coreboot.c
>>> >> @@ -68,8 +68,8 @@ int board_early_init_r(void)
>>> >>  void show_boot_progress(int val)
>>> >>  {
>>> >>  #if MIN_PORT80_KCLOCKS_DELAY
>>> >> - static uint32_t prev_stamp;
>>> >> - static uint32_t base;
>>> >> + static uint32_t prev_stamp __attribute__((section(".data")));
>>> >> + static uint32_t base __attribute__((section(".data")));
>>> >
>>> > NAK
>>> >
>>> > This may work for coreboot where SDRAM is already initialised and you've
>>> > loaded U-Boot into RAM, but it will not work when U-Boot is in Flash as
>>> > all
>>> > sections (including .data) are read-only until after relocation.
>>> >
>>> > The stack and Global Data are the only guaranteed read/write locations
>>> > prior to relocation
>>>
>>> Ah yes, I was thinking of your comment that all boards would move to
>>> use coreboot. If that is not the case, then I will need to add
>>> something to global data for the timer. And I don't want to do that
>>> while generic board is in progress since it creates conflicts.
>
> I'm trying to remember the context of my comment regarding only having
> coreboot boards. But anyway, not having any writeable data prior to
> relocation (other than the stack and gd) is a fundamental principle
> that we cannot simply avoid (although I must admit I don't know what
> the go is with SPL and U-Boot relocation).
>
>> Any thoughts on this point, please? I presume at least I can use RAM once
>> dram_init() is called. But when running from coreboot the RAM is already set
>> up...
>
> You will need to use global data to store the static variables. That's
> what the other arches do

That line is blurred a bit now, but OK I will do that. I will put this
series on hold until we see what happens with the arch-specific
global_data series.

Regards,
Simon

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

Re: [U-Boot] [PATCH] NAND: allow custom SW ECC when using nand plat driver

[Scott Wood]

On 12/19/2012 03:40:03 PM, Scott Wood wrote:

I seem to see  other nand drivers setting up ecc
layouts and then calling nand_scan_tail(), I'm not sure how they  
are  getting

around this.


They don't use NAND_ECC_SOFT.


Wait, just layout, not algorithm?  How is that a problem with either  
NAND_ECC_SOFT or nand plat?


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

Re: [U-Boot] [PATCH] NAND: allow custom SW ECC when using nand plat driver

[Scott Wood]

On 12/19/2012 03:16:19 PM, Chris Kiick wrote:

Hi,
  Thanks for the reply. This is my first patch to u-boot. Any advice  
is

appreciated. Comments in-line below.


- Original Message 

> From: Scott Wood 
> To: Chris Kiick 
> Cc: u-boot@lists.denx.de
> Sent: Wed, December 19, 2012 1:02:52 PM
> Subject: Re: [U-Boot] [PATCH] NAND: allow custom SW ECC when using  
nand plat

>driver
>
> On 12/18/2012 05:27:00 PM, Chris Kiick wrote:
> > Allow boards to set their  own ECC layouts and functions in  
NAND_PLAT_INIT

> > without being stomped on  by nand_base.c intialization.
> >
> > Signed-off-by: ckiick 
> > ---
> >  drivers/mtd/nand/nand_base.c |11 +++
> >  drivers/mtd/nand/nand_plat.c |4  ++--
> >  include/configs/qong.h   |2  +-
> >  3 files changed, 10 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/mtd/nand/nand_base.c   
b/drivers/mtd/nand/nand_base.c

> > index a2d06be..614fc72 100644
> > ---  a/drivers/mtd/nand/nand_base.c
> > +++  b/drivers/mtd/nand/nand_base.c
> > @@ -3035,8 +3035,10 @@ int  nand_scan_tail(struct mtd_info *mtd)
> >   chip->ecc.mode = NAND_ECC_SOFT;
> >
> >  case  NAND_ECC_SOFT:
> > -chip->ecc.calculate =  nand_calculate_ecc;
> > -chip->ecc.correct =  nand_correct_data;
> > +if  (!chip->ecc.calculate)
> > + chip->ecc.calculate = nand_calculate_ecc;
> > + if (!chip->ecc.correct)
> > + chip->ecc.correct = nand_correct_data;
> >   chip->ecc.read_page = nand_read_page_swecc;
> >   chip->ecc.read_subpage =  nand_read_subpage;
> >   chip->ecc.write_page = nand_write_page_swecc;
> > @@ -3044,9 +3046,10 @@  int nand_scan_tail(struct mtd_info *mtd)
> >   chip->ecc.write_page_raw = nand_write_page_raw;
> >   chip->ecc.read_oob = nand_read_oob_std;
> >   chip->ecc.write_oob = nand_write_oob_std;
> >  -if (!chip->ecc.size)
> > + if (!chip->ecc.size) {
> >   chip->ecc.size = 256;
> > - chip->ecc.bytes = 3;
> > + chip->ecc.bytes = 3;
> > + }
> >  break;
> >
> >   case NAND_ECC_SOFT_BCH:
>
> How is this part specific to nand  plat?

OK, it's not, but if you are using nand plat, then you are forced to  
go through
this code path with no chance of making any changes after because of  
the way

board_nand_init() is written.


nand plat is meant to be a simple driver for simple hardware that  
follows a certain pattern.  If you have hardware that doesn't fit that,  
don't use nand plat.



I seem to see  other nand drivers setting up ecc
layouts and then calling nand_scan_tail(), I'm not sure how they are   
getting

around this.


They don't use NAND_ECC_SOFT.

I reasoned that the change was safe for existing code because if  
something was
not setting its own ecc layout, it would still use the default, but  
it if was,
then it had to be after the call to nand_scan_tail() and that would  
override

whatever was set there anyway.


It's not a matter of safety, but rather a sign that you're misusing  
things.


> I'm not sure how specifying your own ECC functions fits with the   
purpose of

>either NAND_ECC_SOFT or nand plat.
Well, NAND_ECC_SOFT is the only scheme that does fit with custom ECC  
algorithms.


No, it's the opposite.  NAND_ECC_SOFT is telling the generic code  
"please do ECC for me".  NAND_ECC_HW is telling the generic code "I  
want to do ECC myself", usually because you have hardware that  
implements it.  In your case, it's because you're trying to maintain  
compatibility with something.


You have to pick one of the existing ECC schemes, and SOFT is the  
scheme that
allows you to do your own ECC, if you setup the layout, calculate and  
correct

parts. Looking at the code, that's what I thought it was for.


You just described NAND_ECC_HW. :-)

Is there another way to implement custom ECC algorithms, done in  
software?


As for the plat driver, it shouldn't care what ECC I'm using.  It's  
just running
the low-level byte-bang part of the driver for me, so I don't have to  
duplicate
the code. Isn't that its purpose?  Do I have to re-write a driver  
interface that
does the same thing as nand plat just because my ECC isn't the  
default?


There is very little code in the nand plat driver.  I would not be too  
worried about duplicating that, if the result is more straightforward.


The fact that there's still only one board using it (but three ifdef  
symbols!) makes me wonder if nand plat was a bad idea in general.


If I'm going in the wrong direction, I'd appreciate advice on how  
it's supposed

to be done.

> > diff --git  a/drivers/mtd/nand/nand_plat.c  
b/drivers/mtd/nand/nand_plat.c

> > index  37a0206..b3bda11 100644
> > --- a/drivers/mtd/nand/nand_plat.c
> > +++  b/drivers/mtd/nand/nand_plat.c
> > @@ -8,7 +8,7 @@
> >  /* Your  board must implement the following macros:
> >   *   NAND_PLAT_WRITE_CMD(chip, cmd)
> >   *  NAND_PLAT_WRITE_ADR(chip,  cmd

Re: [U-Boot] Conflicting commits for seaboard USB keyboard handling

[Allen Martin]

On Wed, Dec 19, 2012 at 11:37:26AM -0800, Albert ARIBAUD wrote:
> Hi Stephen,
> 
> On Tue, 18 Dec 2012 23:04:09 -0700, Stephen Warren
>  wrote:
> > On 12/18/2012 06:08 PM, Allen Martin wrote:
> > ...
> > > The other alternative is I could provide the conflict resolved files
> > > or instructions for how to resolve.
> > 
> > Aren't the two sets of files that conflict those that are already in
> > u-boot/master and u-boot-arm/master? If so, only Albert can resolve the
> > conflict, by doing a merge. I already did that merge locally a while
> > back in order to pick up the changes from both branches, and it didn't
> > seem hard; what's the problem here? If Allen can push out a branch for
> > Albert to use as an example to make sure he gets the correct merge
> > result, that seems like a very simple solution.
> 
> There are several sources of conflicts in merging u-boot into
> u-boot-arm. I want all conflicts resolved by the persons who are best
> suited for resolving properly, then I'll merge all resolutions together.
> 

Hi Albert, I did a merge of u-boot/master into u-boot-arm/master and
resolved the conflicts and I've pushed the result to:

 git://github.com/arm000/u-boot.git
 branch: u-boot-arm-merge-resolved

I resolved all the conflicts, but the only ones I claim I did
correctly were the changes to:

 include/configs/seaboard.h
 include/configs/tegra-common-post.h

the other conflicts were not related to tegra.

If you want a new pull request, you'll first have to unroll the
previously merged tegra patches from u-boot-arm/master so I can give
you a conflict free merge request.

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

Re: [U-Boot] [U-Boot, 1/2] spi: Add progress percentage and write speed to `sf update`

[Tom Rini]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/19/12 15:46, Simon Glass wrote:
> Hi Tom,
> 
> On Wed, Dec 19, 2012 at 12:43 PM, Tom Rini  wrote:
>> On Fri, Sep 28, 2012 at 02:28:00PM -, Simon Glass wrote:
>> 
>>> From: James Miller 
>>> 
>>> Output a progress update only at most 10 times per second, to 
>>> avoid saturating (and waiting on) the console. Make the
>>> summary line to fit on a single line. Make sure that cursor
>>> sits at the end of each update line instead of the beginning.
>>> 
>>> Sample output:
>>> 
>>> SF: Detected W25Q32 with page size 4 KiB, total 4 MiB Update 
>>> SPI 1331200 bytes written, 2863104 bytes skipped in 21.912s, 
>>> speed 199728 B/s
>>> 
>>> time: 21.919 seconds, 21919 ticks Skipping verify
>>> 
>>> Signed-off-by: Simon Glass  Signed-off-by: 
>>> James Miller  Signed-off-by: Taylor 
>>> Hutt 
>> 
>> With ELDK 4.2: cmd_sf.c:80: warning: type qualifiers ignored on 
>> function return type
> 
> Interesting...
> 
>> 
>> Unless I'm missing something, this is the right fix: -static 
>> const ulong bytes_per_second(unsigned int len, ulong start_ms) 
>> +static ulong bytes_per_second(unsigned int len, ulong start_ms)
>> 
>> Because no, we aren't returning a const.  If that sounds right 
>> I'll fix inline and add my Signed-off-by.
> 
> Yes that looks right, thanks for doing that. Did Mike get in touch 
> re these?

No, but I've read them again myself and they seem sane enough to grab
as Mike hasn't been active recently.  And I'll push this shortly then,
thanks!

- -- 
Tom
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQIcBAEBAgAGBQJQ0irGAAoJENk4IS6UOR1WVJIQAJfcEUS0JA6+cp5D+aEt+mbC
fnXcNB9iqqTJ+7s4FBrC7Q48MZooiynjbwo9M2/KrtjCtoKwM3pqHcvCZpL1R1l0
nJaGjgDgCU+DvXiWVRSGKYHan+O/EOYbzFxqDvS7y9A3+wJwBf3yvvom5/CavV61
pEzjSxaUdA0Ew4NZ7b3cVXqcDN00dzsuH1BgtRdNsaGauVJNtfi+83fHLZJfl8cY
24hC4iGqQu8hj13pAO4TMmsCYGVeXU+sSoTWzdYt6aYVu9nQUoeOplyUy+9e53Vr
v+1cgqiArqkIPLa0ypLGzR2f1QVzZqndXkRCmGNq0iVSowpfCPrDQO2OowzqmBEl
b9WUzmo3nkEn1pfY8EGYYtYXa8yyjie0qSzgbIiepBJFequPyzq/D2lY2a2buP2g
nUHMBS/fp04KunuY4PPrJoqXhUJFDSdsKhZBQS+hi3hzNpaT8u9D2QyjgiT/3mya
B92T4D9VvuLutpwqfGDiKBc7iwVrARBAxNUU9O82pCrV9l1+P669czqJWfARIdvy
Zpb1DGwudW1L8VEo0gR+wjp/bU2IxSSKBvRGrPENhklM4+121Jf2Wxbc7qq0XRik
8aRKL5cN3pWN2NoIuxEg0F3FRTrw24vqFv6J87jwCOZ7OCRsP47n2nzQXi1766UY
jRvezzCuDRQetEc1Rx1g
=WeUR
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot, 1/2] spi: Add progress percentage and write speed to `sf update`

[Simon Glass]

Hi Tom,

On Wed, Dec 19, 2012 at 12:43 PM, Tom Rini  wrote:
> On Fri, Sep 28, 2012 at 02:28:00PM -, Simon Glass wrote:
>
>> From: James Miller 
>>
>> Output a progress update only at most 10 times per second, to avoid
>> saturating (and waiting on) the console. Make the summary line
>> to fit on a single line. Make sure that cursor sits at the end of
>> each update line instead of the beginning.
>>
>> Sample output:
>>
>> SF: Detected W25Q32 with page size 4 KiB, total 4 MiB
>> Update SPI
>> 1331200 bytes written, 2863104 bytes skipped in 21.912s, speed 199728 B/s
>>
>> time: 21.919 seconds, 21919 ticks
>> Skipping verify
>>
>> Signed-off-by: Simon Glass 
>> Signed-off-by: James Miller 
>> Signed-off-by: Taylor Hutt 
>
> With ELDK 4.2:
> cmd_sf.c:80: warning: type qualifiers ignored on function return type

Interesting...

>
> Unless I'm missing something, this is the right fix:
> -static const ulong bytes_per_second(unsigned int len, ulong start_ms)
> +static ulong bytes_per_second(unsigned int len, ulong start_ms)
>
> Because no, we aren't returning a const.  If that sounds right I'll fix
> inline and add my Signed-off-by.

Yes that looks right, thanks for doing that. Did Mike get in touch re these?

Regards,
Simon

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

Re: [U-Boot] [U-Boot, 1/2] spi: Add progress percentage and write speed to `sf update`

[Tom Rini]

On Fri, Sep 28, 2012 at 02:28:00PM -, Simon Glass wrote:

> From: James Miller 
> 
> Output a progress update only at most 10 times per second, to avoid
> saturating (and waiting on) the console. Make the summary line
> to fit on a single line. Make sure that cursor sits at the end of
> each update line instead of the beginning.
> 
> Sample output:
> 
> SF: Detected W25Q32 with page size 4 KiB, total 4 MiB
> Update SPI
> 1331200 bytes written, 2863104 bytes skipped in 21.912s, speed 199728 B/s
> 
> time: 21.919 seconds, 21919 ticks
> Skipping verify
> 
> Signed-off-by: Simon Glass 
> Signed-off-by: James Miller 
> Signed-off-by: Taylor Hutt 

With ELDK 4.2:
cmd_sf.c:80: warning: type qualifiers ignored on function return type

Unless I'm missing something, this is the right fix:
-static const ulong bytes_per_second(unsigned int len, ulong start_ms)
+static ulong bytes_per_second(unsigned int len, ulong start_ms)

Because no, we aren't returning a const.  If that sounds right I'll fix
inline and add my Signed-off-by.

-- 
Tom


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

Re: [U-Boot] Conflicting commits for seaboard USB keyboard handling

[Albert ARIBAUD]

Hi Stephen,

On Tue, 18 Dec 2012 23:04:09 -0700, Stephen Warren
 wrote:
> On 12/18/2012 06:08 PM, Allen Martin wrote:
> ...
> > The other alternative is I could provide the conflict resolved files
> > or instructions for how to resolve.
> 
> Aren't the two sets of files that conflict those that are already in
> u-boot/master and u-boot-arm/master? If so, only Albert can resolve the
> conflict, by doing a merge. I already did that merge locally a while
> back in order to pick up the changes from both branches, and it didn't
> seem hard; what's the problem here? If Allen can push out a branch for
> Albert to use as an example to make sure he gets the correct merge
> result, that seems like a very simple solution.

There are several sources of conflicts in merging u-boot into
u-boot-arm. I want all conflicts resolved by the persons who are best
suited for resolving properly, then I'll merge all resolutions together.

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

Re: [U-Boot] [PATCH] NAND: allow custom SW ECC when using nand plat driver

[Scott Wood]

On 12/18/2012 05:27:00 PM, Chris Kiick wrote:
Allow boards to set their own ECC layouts and functions in  
NAND_PLAT_INIT

without being stomped on by nand_base.c intialization.

Signed-off-by: ckiick 
---
 drivers/mtd/nand/nand_base.c |   11 +++
 drivers/mtd/nand/nand_plat.c |4 ++--
 include/configs/qong.h   |2 +-
 3 files changed, 10 insertions(+), 7 deletions(-)

diff --git a/drivers/mtd/nand/nand_base.c  
b/drivers/mtd/nand/nand_base.c

index a2d06be..614fc72 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -3035,8 +3035,10 @@ int nand_scan_tail(struct mtd_info *mtd)
 chip->ecc.mode = NAND_ECC_SOFT;

 case NAND_ECC_SOFT:
-chip->ecc.calculate = nand_calculate_ecc;
-chip->ecc.correct = nand_correct_data;
+if (!chip->ecc.calculate)
+chip->ecc.calculate = nand_calculate_ecc;
+if (!chip->ecc.correct)
+chip->ecc.correct = nand_correct_data;
 chip->ecc.read_page = nand_read_page_swecc;
 chip->ecc.read_subpage = nand_read_subpage;
 chip->ecc.write_page = nand_write_page_swecc;
@@ -3044,9 +3046,10 @@ int nand_scan_tail(struct mtd_info *mtd)
 chip->ecc.write_page_raw = nand_write_page_raw;
 chip->ecc.read_oob = nand_read_oob_std;
 chip->ecc.write_oob = nand_write_oob_std;
-if (!chip->ecc.size)
+if (!chip->ecc.size) {
 chip->ecc.size = 256;
-chip->ecc.bytes = 3;
+chip->ecc.bytes = 3;
+}
 break;

 case NAND_ECC_SOFT_BCH:


How is this part specific to nand plat?

I'm not sure how specifying your own ECC functions fits with the  
purpose of either NAND_ECC_SOFT or nand plat.


diff --git a/drivers/mtd/nand/nand_plat.c  
b/drivers/mtd/nand/nand_plat.c

index 37a0206..b3bda11 100644
--- a/drivers/mtd/nand/nand_plat.c
+++ b/drivers/mtd/nand/nand_plat.c
@@ -8,7 +8,7 @@
 /* Your board must implement the following macros:
  *  NAND_PLAT_WRITE_CMD(chip, cmd)
  *  NAND_PLAT_WRITE_ADR(chip, cmd)
- *  NAND_PLAT_INIT()
+ *  NAND_PLAT_INIT(nand)
  *
  * It may also implement the following:
  *  NAND_PLAT_DEV_READY(chip)
@@ -53,7 +53,7 @@ int board_nand_init(struct nand_chip *nand)
 #endif

 #ifdef NAND_PLAT_INIT
-NAND_PLAT_INIT();
+NAND_PLAT_INIT(nand);
 #endif

 nand->cmd_ctrl = plat_cmd_ctrl;
diff --git a/include/configs/qong.h b/include/configs/qong.h
index d9bf201..077cbae 100644
--- a/include/configs/qong.h
+++ b/include/configs/qong.h
@@ -226,7 +226,7 @@ extern int qong_nand_rdy(void *chip);
 #define CONFIG_NAND_PLAT
 #define CONFIG_SYS_MAX_NAND_DEVICE 1
 #define CONFIG_SYS_NAND_BASECS3_BASE
-#define NAND_PLAT_INIT() qong_nand_plat_init(nand)
+#define NAND_PLAT_INIT(nand) qong_nand_plat_init(nand)

 #define QONG_NAND_CLE(chip) ((unsigned long)(chip)->IO_ADDR_W | (1  
<< 24))
 #define QONG_NAND_ALE(chip) ((unsigned long)(chip)->IO_ADDR_W | (1  
<< 23))


This part looks unrelated.

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

Re: [U-Boot] Bricked when trying to attach UBI

[Vikram Narayanan]

On 12/20/2012 12:17 AM, Vikram Narayanan wrote:

On 12/19/2012 11:52 PM, Stefan Roese wrote:


I think its the right time to sync the UBI code with the current kernel
tree. But it seems like a huge work. Any suggestions?


Yes, syncing with the latest UBI/UBIFS code would be the best solution.
Even though a try with an increased malloc area as suggested by Andreas
might be a chance.

And yes, this re-sync with the latest-and-greatest Linux code version is
of course a bigger task. It has been suggest as part of booting from an
UBI volume task to the celinux forum:

http://lists.celinuxforum.org/pipermail/celinux-dev/2012-April/000543.html



Yeah. I had queried sometime back on the activity of this task.


But nothing has happened till now. Any volunteers? But please keep in
mind that intensive testing is required before the current (stable?)
code version can be replaced.



Looks like the MTD layer might needs to be patched up as well at some
places. What do you think?


May be we shall start some discussions and put forth some ideas, which 
might eventually invite some volunteers.


What is your proposal of syncing with the latest code?
* Pick out changes from the Kernel's git (pick out UBI related commits 
right from the point where current u-boot code is)

* Compare and move the code

Both are equally complicated with the second option having very less 
chance to figure out why that was added. Ideas are welcome.


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

Re: [U-Boot] Bricked when trying to attach UBI

[Vikram Narayanan]

On 12/19/2012 11:52 PM, Stefan Roese wrote:


I think its the right time to sync the UBI code with the current kernel
tree. But it seems like a huge work. Any suggestions?


Yes, syncing with the latest UBI/UBIFS code would be the best solution.
Even though a try with an increased malloc area as suggested by Andreas
might be a chance.

And yes, this re-sync with the latest-and-greatest Linux code version is
of course a bigger task. It has been suggest as part of booting from an
UBI volume task to the celinux forum:

http://lists.celinuxforum.org/pipermail/celinux-dev/2012-April/000543.html


Yeah. I had queried sometime back on the activity of this task.


But nothing has happened till now. Any volunteers? But please keep in
mind that intensive testing is required before the current (stable?)
code version can be replaced.



Looks like the MTD layer might needs to be patched up as well at some 
places. What do you think?


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

Re: [U-Boot] Bricked when trying to attach UBI

[Stefan Roese]

On 12/19/2012 06:32 PM, Vikram Narayanan wrote:
>> On "bricked" devices the output of the "ubi part nand0,3" command is:
>>
>> Creating 1 MTD partitions on "nand0":
>> 0x0010-0x1000 : "mtd=3"
>> UBI: attaching mtd1 to ubi0
>> UBI: physical eraseblock size:   131072 bytes (128 KiB)
>> UBI: logical eraseblock size:129024 bytes
>> UBI: smallest flash I/O unit:2048
>> UBI: sub-page size:  512
>> UBI: VID header offset:  512 (aligned 512)
>> UBI: data offset:2048
>> UBI error: ubi_wl_init_scan: no enough physical eraseblocks (0, need 1)
> 
> Just curious, What does the above command say when you try to attach an 
> empty partition. Does it result in the same error?
> 
>> Now the device is totally blocked, and power cycling does not change
>> the result.
>>
>> The interesting thing is that if I load Linux (2.6.37 + OMAP patches +
>> board support patches) via TFTP and boot it with bootm, it correctly
>> attaches UBI (fixing any problem it may have) and boots correctly.
>> After that the board is unbricked: U-Boot can boot again normally from
>> NAND.
>>
>> Without the ambition of understanding all UBI internals, I tried to
>> visually inspect the UBI code around the line where the error is
>> produced and compare it to the corresponding Linux sources. They looked
>> extremely similar, so I haven't and obvious hint of why U-Boot and
>> Linux produce different results.
>>
>> I also tried with an updated U-Boot master, but the error is still
>> there.
>>
>> Obviously I have changed nothing in the UBI and MTD code, both in
>> U-Boot and in Linux.
>>
>> Can you suggest a proper way to track the root of the problem, or to
>> bypass it?
> 
> I think its the right time to sync the UBI code with the current kernel 
> tree. But it seems like a huge work. Any suggestions?

Yes, syncing with the latest UBI/UBIFS code would be the best solution.
Even though a try with an increased malloc area as suggested by Andreas
might be a chance.

And yes, this re-sync with the latest-and-greatest Linux code version is
of course a bigger task. It has been suggest as part of booting from an
UBI volume task to the celinux forum:

http://lists.celinuxforum.org/pipermail/celinux-dev/2012-April/000543.html

But nothing has happened till now. Any volunteers? But please keep in
mind that intensive testing is required before the current (stable?)
code version can be replaced.

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

Re: [U-Boot] Bricked when trying to attach UBI

[Vikram Narayanan]

On 12/19/2012 4:58 PM, Luca Ceresoli wrote:

Hi all,




On "bricked" devices the output of the "ubi part nand0,3" command is:

Creating 1 MTD partitions on "nand0":
0x0010-0x1000 : "mtd=3"
UBI: attaching mtd1 to ubi0
UBI: physical eraseblock size:   131072 bytes (128 KiB)
UBI: logical eraseblock size:129024 bytes
UBI: smallest flash I/O unit:2048
UBI: sub-page size:  512
UBI: VID header offset:  512 (aligned 512)
UBI: data offset:2048
UBI error: ubi_wl_init_scan: no enough physical eraseblocks (0, need 1)


Just curious, What does the above command say when you try to attach an 
empty partition. Does it result in the same error?



Now the device is totally blocked, and power cycling does not change
the result.

The interesting thing is that if I load Linux (2.6.37 + OMAP patches +
board support patches) via TFTP and boot it with bootm, it correctly
attaches UBI (fixing any problem it may have) and boots correctly.
After that the board is unbricked: U-Boot can boot again normally from
NAND.

Without the ambition of understanding all UBI internals, I tried to
visually inspect the UBI code around the line where the error is
produced and compare it to the corresponding Linux sources. They looked
extremely similar, so I haven't and obvious hint of why U-Boot and
Linux produce different results.

I also tried with an updated U-Boot master, but the error is still
there.

Obviously I have changed nothing in the UBI and MTD code, both in
U-Boot and in Linux.

Can you suggest a proper way to track the root of the problem, or to
bypass it?


I think its the right time to sync the UBI code with the current kernel 
tree. But it seems like a huge work. Any suggestions?


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

Re: [U-Boot] Bricked when trying to attach UBI

[Luca Ceresoli]

Hi Andreas,

Andreas Bießmann wrote:

Hi Luca,

On 19.12.2012 16:56, Luca Ceresoli wrote:

Hi Andreas,

Andreas Bießmann wrote:
...

Creating 1 MTD partitions on "nand0":
0x0010-0x1000 : "mtd=3"
UBI: attaching mtd1 to ubi0
UBI: physical eraseblock size:   131072 bytes (128 KiB)
UBI: logical eraseblock size:129024 bytes
UBI: smallest flash I/O unit:2048
UBI: sub-page size:  512
UBI: VID header offset:  512 (aligned 512)
UBI: data offset:2048
UBI error: ubi_wl_init_scan: no enough physical eraseblocks (0, need 1)

Now the device is totally blocked, and power cycling does not change
the result.


have you tried to increase the malloc arena in u-boot
(CONIG_SYS_MALLOC_LEN)?
We had errors like this before [1],[2] and [3], maybe others -
apparently with another error message, but please give it a try. We know
ubi recovery needs some ram and 1MiB may be not enough.


Thanks for your suggestion.

Unfortunately this does not seem to be the cause of my problem: I tried
increasing my CONFIG_SYS_MALLOC_LEN in include/configs/dig297.h from
(1024 << 10) to both (1024 << 12) and (1024 << 14), but without any
difference.


Well, ok ... Malloc arena is always my first thought if I read about
problems with ubi in u-boot.
Have you looked up the differences in drivers/mtd/ubi/ in your u-boot
and linux tree? Maybe you can see something obviously different in the
ubi_wl_init_scan()?


I had some days ago, but I double-checked now as you suggested. Indeed
there is an important difference: attach_by_scanning() (build.c) calls
ubi_wl_init_scan() and ubi_eba_init_scan() just like Linux does, but in
a swapped order!

This swap dates back to:

commit d63894654df72b010de2abb4b3f07d0d755f65b6
Author: Holger Brunck 
Date:   Mon Oct 10 13:08:19 2011 +0200

UBI: init eba tables before wl when attaching a device

This fixes that u-boot gets stuck when a bitflip was detected
during "ubi part ". If a bitflip was detected UBI tries
to copy the PEB to a different place. This needs that the eba table
are initialized, but this was done after the wear levelling worker
detects the bitflip. So changes the initialisation of these two
tasks in u-boot.

This is a u-boot specific patch and not needed in the linux layer,
because due to commit 1b1f9a9d00447d
UBI: Ensure that "background thread" operations are really executed
we schedule these tasks in place and not as in linux after the inital
task which schedule this new task is finished.

Signed-off-by: Holger Brunck 
cc: Stefan Roese 
Signed-off-by: Stefan Roese 

I tried reverting that commit and... surprise! U-Boot can now attach UBI
and boot properly!

But the cited commit actually fixed a bug that bite our board a few
months back, so it should not be reverted without thinking twice. Now
it apparently introduced another bug. :-(

I'm Cc:ing the commit author for comments.

Nonetheless, I have evidence of a different behaviour between U-Boot
and Linux even before the two swapped functions are called.

What attach_by_scanning() does in Linux is (abbreviated):

static int attach_by_scanning(struct ubi_device *ubi)
{
si = ubi_scan(ubi);
...fill ubi->some_fields...;
err = ubi_read_volume_table(ubi, si);
/* MARK */
err = ubi_eba_init_scan(ubi, si); /* swapped in U-Boot */
err = ubi_wl_init_scan(ubi, si);  /* swapped in U-Boot */
ubi_scan_destroy_si(si);
return 0;
}

See the two swapped calls.

At MARK, I printed some of the peb counters in *ubi, and I got
different results for ubi->avail_pebs between U-Boot and Linux:
U-Boot: UBI: POST_TBL: rsvd=2018, avail=21, beb_rsvd_{pebs,level}=0,0
Linux:  UBI: POST_TBL: rsvd=2018, avail=22, beb_rsvd_{pebs,level}=0,0

The printed values were equal before calling ubi_read_volume_table().
I have no idea about where this difference comes from, nor if this
difference can cause my troubles.
I will better investigate tomorrow looking into ubi_read_volume_table().

Luca

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

[U-Boot] [U-Boot, v2 2/6] cmd_sf: Add print messages on flash read/write commands

[Jagannadha Sutradharudu Teki]

This patch adds a print messages while using 'sf read' and
'sf write' commands to make sure that how many bytes read/written
from/into flash device.

Signed-off-by: Jagannadha Sutradharudu Teki 
---
Changes in v2:
Move print messages from spi_flash.c into cmd_sf.c

 common/cmd_sf.c |   26 --
 drivers/mtd/spi/spi_flash.c |3 ---
 2 files changed, 16 insertions(+), 13 deletions(-)

diff --git a/common/cmd_sf.c b/common/cmd_sf.c
index ddb1a65..efdd640 100644
--- a/common/cmd_sf.c
+++ b/common/cmd_sf.c
@@ -196,7 +196,7 @@ static int do_spi_flash_read_write(int argc, char * const 
argv[])
unsigned long len;
void *buf;
char *endp;
-   int ret;
+   int ret = 0;
 
if (argc < 4)
return -1;
@@ -226,19 +226,25 @@ static int do_spi_flash_read_write(int argc, char * const 
argv[])
 
if (strcmp(argv[0], "update") == 0)
ret = spi_flash_update(flash, offset, len, buf);
-   else if (strcmp(argv[0], "read") == 0)
-   ret = spi_flash_read(flash, offset, len, buf);
-   else
-   ret = spi_flash_write(flash, offset, len, buf);
+   else if (strncmp(argv[0], "read", 4) == 0 ||
+   strncmp(argv[0], "write", 5) == 0) {
+   int read;
 
-   unmap_physmem(buf, len);
+   read = strncmp(argv[0], "read", 4) == 0;
+   printf("SF: %s flash... ", read ? "Reading" : "Writing");
 
-   if (ret) {
-   printf("SPI flash %s failed\n", argv[0]);
-   return 1;
+   if (read)
+   ret = spi_flash_read(flash, offset, len, buf);
+   else
+   ret = spi_flash_write(flash, offset, len, buf);
+
+   printf("%zu bytes @ %#x %s: %s\n", (size_t)len, (u32)offset,
+   read ? "read" : "written", ret ? "ERROR" : "OK");
}
 
-   return 0;
+   unmap_physmem(buf, len);
+
+   return ret == 0 ? 0 : 1;
 }
 
 static int do_spi_flash_erase(int argc, char * const argv[])
diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
index 43e0334..9e8939c 100644
--- a/drivers/mtd/spi/spi_flash.c
+++ b/drivers/mtd/spi/spi_flash.c
@@ -115,9 +115,6 @@ int spi_flash_cmd_write_multi(struct spi_flash *flash, u32 
offset,
byte_addr = 0;
}
 
-   debug("SF: program %s %zu bytes @ %#x\n",
- ret ? "failure" : "success", len, offset);
-
spi_release_bus(flash->spi);
return ret;
 }
-- 
1.7.0.4

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

[U-Boot] [U-Boot, v2 4/6] sf: Add configuration register writing support

[Jagannadha Sutradharudu Teki]

This patch provides support to program a flash config register.

Configuration register contains the control bits used to configure
the different configurations and security features of a device.

User need to set these bits through spi_flash_cmd_write_config()
based on their usage.

Signed-off-by: Jagannadha Sutradharudu Teki 
---
Changes in v2:
Improved code logic 

 drivers/mtd/spi/spi_flash.c  |   35 ++
 drivers/mtd/spi/spi_flash_internal.h |3 ++
 2 files changed, 38 insertions(+), 0 deletions(-)

diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
index bf5ec4a..cad6c40 100644
--- a/drivers/mtd/spi/spi_flash.c
+++ b/drivers/mtd/spi/spi_flash.c
@@ -279,6 +279,41 @@ int spi_flash_cmd_read_status(struct spi_flash *flash, 
void *data)
return 0;
 }
 
+int spi_flash_cmd_write_config(struct spi_flash *flash, u8 cr)
+{
+   u8 data[2];
+   u8 cmd;
+   int ret;
+
+   ret = spi_flash_cmd_read_status(flash, (void *)&data[0]);
+   if (ret < 0) {
+   debug("SF: fail to read status register\n");
+   return ret;
+   }
+
+   ret = spi_flash_cmd_write_enable(flash);
+   if (ret < 0) {
+   debug("SF: enabling write failed\n");
+   return ret;
+   }
+
+   cmd = CMD_WRITE_STATUS;
+   data[1] = cr;
+   ret = spi_flash_cmd_write(flash->spi, &cmd, 1, &data, 2);
+   if (ret) {
+   debug("SF: fail to write config register\n");
+   return ret;
+   }
+
+   ret = spi_flash_cmd_wait_ready(flash, SPI_FLASH_PROG_TIMEOUT);
+   if (ret < 0) {
+   debug("SF: write config register timed out\n");
+   return ret;
+   }
+
+   return 0;
+}
+
 /*
  * The following table holds all device probe functions
  *
diff --git a/drivers/mtd/spi/spi_flash_internal.h 
b/drivers/mtd/spi/spi_flash_internal.h
index 8232595..825b398 100644
--- a/drivers/mtd/spi/spi_flash_internal.h
+++ b/drivers/mtd/spi/spi_flash_internal.h
@@ -80,6 +80,9 @@ int spi_flash_cmd_write_status(struct spi_flash *flash, u8 
sr);
 /* Read the status register */
 int spi_flash_cmd_read_status(struct spi_flash *flash, void *data);
 
+/* Program the config register. */
+int spi_flash_cmd_write_config(struct spi_flash *flash, u8 cr);
+
 /*
  * Same as spi_flash_cmd_read() except it also claims/releases the SPI
  * bus. Used as common part of the ->read() operation.
-- 
1.7.0.4

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

Re: [U-Boot] please pull u-boot-samsung/resolve

[Albert ARIBAUD]

Hi Minkyu,

On Tue, 18 Dec 2012 00:14:34 +0900, Minkyu Kang 
wrote:
> Dear Albert,
> 
> On Saturday, December 15, 2012, Albert ARIBAUD wrote:
> 
> > Hi Minkyu,
> >
> > On Fri, 14 Dec 2012 09:14:11 +0900, Minkyu Kang 
> > 
> > >
> > wrote:
> > > On 14/12/12 04:56, Albert ARIBAUD wrote:
> > > > Hi Minkyu,
> > > >
> > > > On Tue, 11 Dec 2012 20:10:06 +0900, Minkyu Kang 
> > > > wrote:
> > > >> Dear Albert,
> > > >>
> > > >> The following changes since commit
> > fd4d564b3c80b111f18c93adb14233a6a7ddb0e9:
> > > >>
> > > >>   Merge branch 'master' of git://git.denx.de/u-boot-x86 (2012-12-07
> > 08:47:59 -0700)
> > > >>
> > > >> are available in the git repository at:
> > > >>
> > > >>
> > > >>   git://git.denx.de/u-boot-samsung resolve
> > > >>
> > > >> for you to fetch changes up to
> > fbef8e6e7f1233ed20f8c5045e12c9cf31b43540:
> > > >>
> > > >>   universal_c210: check the NULL pointer when get the PMIC
> > (2012-12-11 17:37:28 +0900)
> > > >>
> > > >> 
> > > >> Albert ARIBAUD (1):
> > > >>   Merge branch 'u-boot-imx/master' into 'u-boot-arm/master'
> > > >>
> > > >> Allen Martin (1):
> > > >>   tegra: add CONSOLE_MUX support to tegra-kbc
> > > >>
> > > >> Ashok Kumar Reddy (1):
> > > >>   ARM: arm1176: Define arch_cpu_init() for s3c64xx
> > > >>
> > > >> Benoît Thébaudeau (17):
> > > >>   arm1136: Fix enable_caches()
> > > >>   mx31: Move EHCI definitions to ehci-fsl.h
> > > >>   ehci-mxc: Clean up
> > > >>   ehci-mx5: Clean up
> > > >>   ehci-mx5: Fix OC_DIS usage
> > > >>   ehci-mx5: Fix OPM usage
> > > >>   ehci-mx5: Fix *PM usage for i.MX53
> > > >>   ehci-mx5: Add missing OC_DIS for i.MX53
> > > >>   ehci-mxc: Make EHCI power/oc polarities configurable
> > > >>   ehci-mxc: Make i.MX25 EHCI configurable
> > > >>   ehci-mxc: Define host offsets
> > > >>   ehci-mxc: Add support for i.MX35
> > > >>   mx35pdk: Add support for OTG
> > > >>   ehci-mx5/6: Make board_ehci_hcd_init() optional
> > > >>   ehci-mxc: Fix host power mask bit for i.MX35
> > > >>   ehci-mxc: Fix host power mask bit for i.MX25
> > > >>   mx5: Mark lowlevel_init board-specific code
> > > >>
> > > >> Chander Kashyap (1):
> > > >>   Exynos5250: Enable PXE Support
> > > >>
> > > >> Fabio Estevam (24):
> > > >>   mx25pdk: Include CONFIG_MX25
> > > >>   mx25pdk: Add esdhc support
> > > >>   pmic_fsl: Introduce FSL_PMIC_I2C_LENGTH
> > > >>   mx25: Place common functions into sys_proto.h
> > > >>   pmic: Add support for mc34704
> > > >>   mx25pdk: Add Ethernet support
> > > >>   mx53loco: Allow booting a zImage kernel
> > > >>   mx25pdk: Allow booting a zImage kernel
> > > >>   mx51evk: Allow booting a zImage kernel
> > > >>   mx35pdk: Allow booting a zImage kernel
> > > >>   mx6qsabre_common: Allow booting a zImage kernel
> > > >>   mx5: Align SPI CS naming with i.MX53 reference manual
> > > >>   mx5: Print CSPI clock in 'clock' command
> > > >>   spi: mxc_spi: Fix handling of chip select
> > > >>   spi: mxc_spi: Fix spi clock glitch durant reset
> > > >>   mx6: clock: Only show CSPI clock if CSPI is enabled
> > > >>   mx28evk: Configure CONFIG_BOOTDELAY to one second
> > > >>   mx53loco: Configure CONFIG_BOOTDELAY to one second
> > > >>   mx6qsabrelite: Configure CONFIG_BOOTDELAY to one second
> > > >>   mx6qsabre_common: Configure CONFIG_BOOTDELAY to one second
> > > >>   mx51evk: Configure CONFIG_BOOTDELAY to one second
> > > >>   mx25pdk: Configure CONFIG_BOOTDELAY to one sYou're right. I was
> > a bit quick to reply when I read Stephen's
> > question. Can you please address it too?
> 
> Address for what?

Can you answer the question Stephen has asked on this list on 11/12 ?



> Thanks.
> Minkyu Kang.

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

[U-Boot] [U-Boot,v2 6/6] sf: Set QUAD enable bit support

[Jagannadha Sutradharudu Teki]

This patch provides support to set the QUAD enable bit on flash.

QUAD enable bit needs to set before performing any QUAD IO operations
on respective SPI flashes.

User need to use spi_flash_set_quad_enable_bit() to set the
QUAD enable bit based on their usage.

Signed-off-by: Jagannadha Sutradharudu Teki 
---
Changes in v2:
Improved code logic

 drivers/mtd/spi/spi_flash.c  |   31 +++
 drivers/mtd/spi/spi_flash_internal.h |4 
 2 files changed, 35 insertions(+), 0 deletions(-)

diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
index 5bddde4..675a0bf 100644
--- a/drivers/mtd/spi/spi_flash.c
+++ b/drivers/mtd/spi/spi_flash.c
@@ -329,6 +329,37 @@ int spi_flash_cmd_read_config(struct spi_flash *flash, 
void *data)
return 0;
 }
 
+int spi_flash_set_quad_enable_bit(struct spi_flash *flash)
+{
+   u8 data = 0, write_done = 0;
+   int ret, pass;
+
+   for (pass = 0; pass < 2; pass++) {
+   ret = spi_flash_cmd_read_config(flash, (void *)&data);
+   if (ret < 0) {
+   debug("SF: fail to read config register\n");
+   return ret;
+   }
+
+   if (data & STATUS_QEB) {
+   debug("SF: quad enable bit is set.\n");
+   return ret;
+   } else if (write_done != 1) {
+   debug("SF: need to set quad enable bit\n");
+
+   write_done = 1;
+   ret = spi_flash_cmd_write_config(flash, STATUS_QEB);
+   if (ret < 0) {
+   debug("SF: fail to write quad enable bit\n");
+   return ret;
+   }
+   }
+   }
+
+   debug("SF: fail to set quad enable bit\n");
+   return -1;
+}
+
 /*
  * The following table holds all device probe functions
  *
diff --git a/drivers/mtd/spi/spi_flash_internal.h 
b/drivers/mtd/spi/spi_flash_internal.h
index 844e82e..15c7ac4 100644
--- a/drivers/mtd/spi/spi_flash_internal.h
+++ b/drivers/mtd/spi/spi_flash_internal.h
@@ -31,6 +31,7 @@
 
 /* Common status */
 #define STATUS_WIP 0x01
+#define STATUS_QEB 0x02
 
 /* Send a single-byte command to the device and read the response */
 int spi_flash_cmd(struct spi_slave *spi, u8 cmd, void *response, size_t len);
@@ -87,6 +88,9 @@ int spi_flash_cmd_write_config(struct spi_flash *flash, u8 
cr);
 /* Read the config register */
 int spi_flash_cmd_read_config(struct spi_flash *flash, void *data);
 
+/* Set the QUAD enable bit */
+int spi_flash_set_quad_enable_bit(struct spi_flash *flash);
+
 /*
  * Same as spi_flash_cmd_read() except it also claims/releases the SPI
  * bus. Used as common part of the ->read() operation.
-- 
1.7.0.4

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

[U-Boot] [U-Boot,v2 5/6] sf: Add config register reading support

[Jagannadha Sutradharudu Teki]

This patch provides support to read a flash config register.

Config register contains a control bits used to verify
the different configurations and security features of a device.

User need to get the data through spi_flash_cmd_read_config()
based on their usage.

Signed-off-by: Jagannadha Sutradharudu Teki 
---
Changes in v2: none

 drivers/mtd/spi/spi_flash.c  |   15 +++
 drivers/mtd/spi/spi_flash_internal.h |4 
 2 files changed, 19 insertions(+), 0 deletions(-)

diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
index cad6c40..5bddde4 100644
--- a/drivers/mtd/spi/spi_flash.c
+++ b/drivers/mtd/spi/spi_flash.c
@@ -314,6 +314,21 @@ int spi_flash_cmd_write_config(struct spi_flash *flash, u8 
cr)
return 0;
 }
 
+int spi_flash_cmd_read_config(struct spi_flash *flash, void *data)
+{
+   u8 cmd;
+   int ret;
+
+   cmd = CMD_READ_CONFIG;
+   ret = spi_flash_read_common(flash, &cmd, sizeof(cmd), (void *)data, 1);
+   if (ret < 0) {
+   debug("SF: fail to read config register\n");
+   return ret;
+   }
+
+   return 0;
+}
+
 /*
  * The following table holds all device probe functions
  *
diff --git a/drivers/mtd/spi/spi_flash_internal.h 
b/drivers/mtd/spi/spi_flash_internal.h
index 825b398..844e82e 100644
--- a/drivers/mtd/spi/spi_flash_internal.h
+++ b/drivers/mtd/spi/spi_flash_internal.h
@@ -22,6 +22,7 @@
 #define CMD_PAGE_PROGRAM   0x02
 #define CMD_WRITE_DISABLE  0x04
 #define CMD_READ_STATUS0x05
+#define CMD_READ_CONFIG0x35
 #define CMD_WRITE_ENABLE   0x06
 #define CMD_ERASE_4K   0x20
 #define CMD_ERASE_32K  0x52
@@ -83,6 +84,9 @@ int spi_flash_cmd_read_status(struct spi_flash *flash, void 
*data);
 /* Program the config register. */
 int spi_flash_cmd_write_config(struct spi_flash *flash, u8 cr);
 
+/* Read the config register */
+int spi_flash_cmd_read_config(struct spi_flash *flash, void *data);
+
 /*
  * Same as spi_flash_cmd_read() except it also claims/releases the SPI
  * bus. Used as common part of the ->read() operation.
-- 
1.7.0.4

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

[U-Boot] [U-Boot, v2 1/6] cmd_sf: Add print messages on flash erase command

[Jagannadha Sutradharudu Teki]

This patch adds a print messages while using 'sf erase' command
to make sure that how many bytes erased in flash device.

Signed-off-by: Jagannadha Sutradharudu Teki 
---
Changes in v2:
Move print messages from spi_flash.c into cmd_sf.c

 common/cmd_sf.c |   11 ++-
 drivers/mtd/spi/spi_flash.c |2 --
 2 files changed, 6 insertions(+), 7 deletions(-)

diff --git a/common/cmd_sf.c b/common/cmd_sf.c
index 5ac1d0c..ddb1a65 100644
--- a/common/cmd_sf.c
+++ b/common/cmd_sf.c
@@ -266,13 +266,14 @@ static int do_spi_flash_erase(int argc, char * const 
argv[])
return 1;
}
 
+   printf("SF: Erasing flash... ");
+
ret = spi_flash_erase(flash, offset, len);
-   if (ret) {
-   printf("SPI flash %s failed\n", argv[0]);
-   return 1;
-   }
 
-   return 0;
+   printf("%zu bytes @ %#x erased: %s\n", (size_t)len, (u32)offset,
+   ret ? "ERROR" : "OK");
+
+   return ret == 0 ? 0 : 1;
 }
 
 static int do_spi_flash(cmd_tbl_t *cmdtp, int flag, int argc, char * const 
argv[])
diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
index 00aece9..43e0334 100644
--- a/drivers/mtd/spi/spi_flash.c
+++ b/drivers/mtd/spi/spi_flash.c
@@ -235,8 +235,6 @@ int spi_flash_cmd_erase(struct spi_flash *flash, u32 
offset, size_t len)
goto out;
}
 
-   debug("SF: Successfully erased %zu bytes @ %#x\n", len, start);
-
  out:
spi_release_bus(flash->spi);
return ret;
-- 
1.7.0.4

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

[U-Boot] [U-Boot,v2 3/6] sf: Add status register reading support

[Jagannadha Sutradharudu Teki]

This patch provides support to read a flash status register.

Status register contains a control bits used to verify
the progress of flash program and erase operations.

User need to get the data through spi_flash_cmd_read_status()
based on their usage.

Signed-off-by: Jagannadha Sutradharudu Teki 
---
Changes in v2:none

 drivers/mtd/spi/spi_flash.c  |   15 +++
 drivers/mtd/spi/spi_flash_internal.h |3 +++
 2 files changed, 18 insertions(+), 0 deletions(-)

diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
index 9e8939c..bf5ec4a 100644
--- a/drivers/mtd/spi/spi_flash.c
+++ b/drivers/mtd/spi/spi_flash.c
@@ -264,6 +264,21 @@ int spi_flash_cmd_write_status(struct spi_flash *flash, u8 
sr)
return 0;
 }
 
+int spi_flash_cmd_read_status(struct spi_flash *flash, void *data)
+{
+   u8 cmd;
+   int ret;
+
+   cmd = CMD_READ_STATUS;
+   ret = spi_flash_read_common(flash, &cmd, sizeof(cmd), (void *)data, 1);
+   if (ret < 0) {
+   debug("SF: fail to read status register\n");
+   return ret;
+   }
+
+   return 0;
+}
+
 /*
  * The following table holds all device probe functions
  *
diff --git a/drivers/mtd/spi/spi_flash_internal.h 
b/drivers/mtd/spi/spi_flash_internal.h
index 141cfa8..8232595 100644
--- a/drivers/mtd/spi/spi_flash_internal.h
+++ b/drivers/mtd/spi/spi_flash_internal.h
@@ -77,6 +77,9 @@ static inline int spi_flash_cmd_write_disable(struct 
spi_flash *flash)
 /* Program the status register. */
 int spi_flash_cmd_write_status(struct spi_flash *flash, u8 sr);
 
+/* Read the status register */
+int spi_flash_cmd_read_status(struct spi_flash *flash, void *data);
+
 /*
  * Same as spi_flash_cmd_read() except it also claims/releases the SPI
  * bus. Used as common part of the ->read() operation.
-- 
1.7.0.4

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

Re: [U-Boot] Bricked when trying to attach UBI

[Andreas Bießmann]

Hi Luca,

On 19.12.2012 16:56, Luca Ceresoli wrote:
> Hi Andreas,
> 
> Andreas Bießmann wrote:
> ...
>>> Creating 1 MTD partitions on "nand0":
>>> 0x0010-0x1000 : "mtd=3"
>>> UBI: attaching mtd1 to ubi0
>>> UBI: physical eraseblock size:   131072 bytes (128 KiB)
>>> UBI: logical eraseblock size:129024 bytes
>>> UBI: smallest flash I/O unit:2048
>>> UBI: sub-page size:  512
>>> UBI: VID header offset:  512 (aligned 512)
>>> UBI: data offset:2048
>>> UBI error: ubi_wl_init_scan: no enough physical eraseblocks (0, need 1)
>>>
>>> Now the device is totally blocked, and power cycling does not change
>>> the result.
>>
>> have you tried to increase the malloc arena in u-boot
>> (CONIG_SYS_MALLOC_LEN)?
>> We had errors like this before [1],[2] and [3], maybe others -
>> apparently with another error message, but please give it a try. We know
>> ubi recovery needs some ram and 1MiB may be not enough.
> 
> Thanks for your suggestion.
> 
> Unfortunately this does not seem to be the cause of my problem: I tried
> increasing my CONFIG_SYS_MALLOC_LEN in include/configs/dig297.h from
> (1024 << 10) to both (1024 << 12) and (1024 << 14), but without any
> difference.

Well, ok ... Malloc arena is always my first thought if I read about
problems with ubi in u-boot.
Have you looked up the differences in drivers/mtd/ubi/ in your u-boot
and linux tree? Maybe you can see something obviously different in the
ubi_wl_init_scan()?

Best regards

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

Re: [U-Boot] Bricked when trying to attach UBI

[Luca Ceresoli]

Hi Andreas,

Andreas Bießmann wrote:
...

Creating 1 MTD partitions on "nand0":
0x0010-0x1000 : "mtd=3"
UBI: attaching mtd1 to ubi0
UBI: physical eraseblock size:   131072 bytes (128 KiB)
UBI: logical eraseblock size:129024 bytes
UBI: smallest flash I/O unit:2048
UBI: sub-page size:  512
UBI: VID header offset:  512 (aligned 512)
UBI: data offset:2048
UBI error: ubi_wl_init_scan: no enough physical eraseblocks (0, need 1)

Now the device is totally blocked, and power cycling does not change
the result.


have you tried to increase the malloc arena in u-boot
(CONIG_SYS_MALLOC_LEN)?
We had errors like this before [1],[2] and [3], maybe others -
apparently with another error message, but please give it a try. We know
ubi recovery needs some ram and 1MiB may be not enough.


Thanks for your suggestion.

Unfortunately this does not seem to be the cause of my problem: I tried
increasing my CONFIG_SYS_MALLOC_LEN in include/configs/dig297.h from
(1024 << 10) to both (1024 << 12) and (1024 << 14), but without any
difference.

Luca

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

[U-Boot] split nand writes

[Jaap de Jong]

Hi All,
suppose the image I want to flash is bigger than the available ram in 
the unit.

Is there a way to copy the image f.i. in pieces into the flash?
nand write should have a 'continue on last block' option for that purpose.
Thanks!
Jaap
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Bricked when trying to attach UBI

[Andreas Bießmann]

Dear Luca Ceresoli,

On 19.12.2012 12:28, Luca Ceresoli wrote:
> Hi all,
> 
> I am facing a problem with some boards that do not boot after some
> weeks or months of normal usage, being unable to attach UBI. They do
> not boot anymore event after a power cycle, in other words they are
> totally bricked.
> I don't know exactly what problem UBI has, but it is recoverable by
> Linux, but apparently not by U-Boot.
> 
> The boards are DIG297 (dig297 board in mainline U-Boot), based on
> OMAP3530 and equipped with a NAND flash (Micron MT29F2G16ABBEAHC) as
> their unique permanent storage.
> 
> U-Boot v2012.04.01 starts correctly. The bootcmd tries to load the
> kernel from UBI, starting with the following commands:
> 
> echo Booting from nand ...
> setenv bootargs console=ttyO2,115200n8
> mtdparts=omap2-nand.0:768k(uboot),128k(reserved),128k(uboot-env),-(ubi)
> ubi.mtd=3 root=ubi0:rootfs ro rootfstype=ubifs ip=
> ubi part nand0,3
> ...
> 
> On "bricked" devices the output of the "ubi part nand0,3" command is:
> 
> Creating 1 MTD partitions on "nand0":
> 0x0010-0x1000 : "mtd=3"
> UBI: attaching mtd1 to ubi0
> UBI: physical eraseblock size:   131072 bytes (128 KiB)
> UBI: logical eraseblock size:129024 bytes
> UBI: smallest flash I/O unit:2048
> UBI: sub-page size:  512
> UBI: VID header offset:  512 (aligned 512)
> UBI: data offset:2048
> UBI error: ubi_wl_init_scan: no enough physical eraseblocks (0, need 1)
> 
> Now the device is totally blocked, and power cycling does not change
> the result.

have you tried to increase the malloc arena in u-boot
(CONIG_SYS_MALLOC_LEN)?
We had errors like this before [1],[2] and [3], maybe others -
apparently with another error message, but please give it a try. We know
ubi recovery needs some ram and 1MiB may be not enough.

> The interesting thing is that if I load Linux (2.6.37 + OMAP patches +
> board support patches) via TFTP and boot it with bootm, it correctly
> attaches UBI (fixing any problem it may have) and boots correctly.
> After that the board is unbricked: U-Boot can boot again normally from
> NAND.

The fact that linux can recover with a quite old version points for me
towards 'environment constraints' like to few memory in u-boot.
Unfortunately the error messages in u-boots ubi sometimes missing such
details (like -ENOMEM as in [1]).

Best regards

Andreas Bießmann

[1] http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/124769
[2] http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/145526
[3] http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/145655
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] configuring u-boot for custom board based on beaglebone(am335xx_evm)

[Pavan]

Hi Yegor,

Thanks for quick reply,

  in u-boot source code to change the beagleboard -xM pin mux we
can change by updating the file board/ti/beagle/beagle.h by changing the
MUX_BEAGLE() micro ,how can i access the same thing for beaglebone?


Regards
Pavan





--
View this message in context: 
http://u-boot.10912.n7.nabble.com/configuring-u-boot-for-custom-board-based-on-beaglebone-am335xx-evm-tp143228p143231.html
Sent from the U-Boot mailing list archive at Nabble.com.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] configuring u-boot for custom board based on beaglebone(am335xx_evm)

[Yegor Yefremov]

On Wed, Dec 19, 2012 at 3:07 PM, Pavan  wrote:
> Hi,
>
>i need to configure u-boot-2013.01.rc2 for my custom board, that
> is completely based on beaglebone Rev A3,i have mux.h file according to my
> hardware i am not understanding the codeflow of beaglebone for include the
> mux.h.
>
> i have some extra hardware on my board,but first i need to understand the
> codeflow for beaglebone then only i can change the all required files
> according to my hardware.
>
> Can you please tell me which are the files i need to change? or u-boot is
> using pin-mux for baglebone?

No

> I checked the file include/configs/am335x_evm.h and also in board/ti/am335x
> directory the mux.c is there,but i didn't  understand the codeflow properly?

As you can see mux.c provides pinmuxes for dedicated hardware parts
like UART, I2C etc. In  enable_board_pin_mux() u-boot decides what
board it is running on and activates relevant hardware parts. main
line kernel makes the same. This was different for am3517 though.

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

[U-Boot] configuring u-boot for custom board based on beaglebone(am335xx_evm)

[Pavan]

Hi,

   i need to configure u-boot-2013.01.rc2 for my custom board, that
is completely based on beaglebone Rev A3,i have mux.h file according to my
hardware i am not understanding the codeflow of beaglebone for include the
mux.h.

i have some extra hardware on my board,but first i need to understand the
codeflow for beaglebone then only i can change the all required files
according to my hardware.

Can you please tell me which are the files i need to change? or u-boot is
using pin-mux for baglebone?

I checked the file include/configs/am335x_evm.h and also in board/ti/am335x
directory the mux.c is there,but i didn't  understand the codeflow properly?

Please help me out?


Regards
Pavan   




--
View this message in context: 
http://u-boot.10912.n7.nabble.com/configuring-u-boot-for-custom-board-based-on-beaglebone-am335xx-evm-tp143228.html
Sent from the U-Boot mailing list archive at Nabble.com.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] u-boot Makefile Questions

[chuck huang]

Dear all,

I have some questions about u-boot Makefile.

Could you help me ?

Thx!

The below is my question.

First, we do make _depend for those $(SUBDIRS) $(CPUDIR)
$(LDSCRIPT_MAKEFILE_DIR)

depend dep: $(TIMESTAMP_FILE) $(VERSION_FILE) \
$(obj)include/autoconf.mk \
$(obj)include/generated/generic-asm-offsets.h \
$(obj)include/generated/asm-offsets.h
for dir in $(SUBDIRS) $(CPUDIR) $(LDSCRIPT_MAKEFILE_DIR) ;
do \
$(MAKE) -C $$dir _depend ; done

after we already generated the .depend file in those dirs.

$(SUBDIRS): depend
$(MAKE) -C $@ all

That would do make action in SUBDIRS dir.
But why we also sinclude .depend in those Makefile which is base on
those dir ? I regard that we already generated before.

And another questions, how does the other sub-dir(eg, libs) .depend
file generated ? is that generated by rules.mk which is include every
sub-dirs?


Best regards



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

Re: [U-Boot] [PATCH 4/4] sf: Add Quad-input Page Program(32h) instruction support

[Jagan Teki]

Hi Simon,

On Fri, Dec 14, 2012 at 7:06 AM, Simon Glass  wrote:
> +Mike
>
> Hi,
>
> On Thu, Dec 13, 2012 at 8:21 AM, Jagan Teki  wrote:
>> Hi Simon,
>>
>> On Thu, Dec 13, 2012 at 4:08 AM, Simon Glass  wrote:
>>> Hi Jagan,
>>>
>>> On Wed, Dec 12, 2012 at 8:52 AM, Jagan Teki  
>>> wrote:
 Hi Simon,

 On Wed, Dec 12, 2012 at 12:11 PM, Simon Glass  wrote:
> Hi,
>
> On Mon, Dec 10, 2012 at 6:42 AM, Jagannadha Sutradharudu Teki
>  wrote:
>> This patch provides support to program a flash using
>> Quad-input Page Program(32h) instruction.
>>
>> This will effectively increases the data transfer rate
>> by up to four times, as compared to the Page Program(PP) instruction.
>>
>> Respective flash drivers need to use spi_flash_cmd_write_multi_qpp()
>> based on their usage.
>>
>> Signed-off-by: Jagannadha Sutradharudu Teki 
>
> It's great to have this support. A few comments below.

 Thanks.

>
>> ---
>>  README   |1 +
>>  common/cmd_sf.c  |   12 +++-
>>  drivers/mtd/spi/spi_flash.c  |  108 
>> ++
>>  drivers/mtd/spi/spi_flash_internal.h |   13 
>>  include/spi_flash.h  |   12 
>>  5 files changed, 144 insertions(+), 2 deletions(-)
>>
>> diff --git a/README b/README
>> index 5a86ae9..a01de13 100644
>> --- a/README
>> +++ b/README
>> @@ -869,6 +869,7 @@ The following options need to be configured:
>> CONFIG_CMD_SETGETDCR  Support for DCR Register access
>>   (4xx only)
>> CONFIG_CMD_SF   * Read/write/erase SPI NOR flash
>> +   CONFIG_CMD_SF_QPP   * Program SPI flash using 
>> Quad-input Page Program
>> CONFIG_CMD_SHA1SUMprint sha1 memory digest
>>   (requires CONFIG_CMD_MEMORY)
>> CONFIG_CMD_SOURCE "source" command Support
>> diff --git a/common/cmd_sf.c b/common/cmd_sf.c
>> index 5ac1d0c..a449d2c 100644
>> --- a/common/cmd_sf.c
>> +++ b/common/cmd_sf.c
>> @@ -228,6 +228,10 @@ static int do_spi_flash_read_write(int argc, char * 
>> const argv[])
>> ret = spi_flash_update(flash, offset, len, buf);
>> else if (strcmp(argv[0], "read") == 0)
>> ret = spi_flash_read(flash, offset, len, buf);
>> +#ifdef CONFIG_CMD_SF_QPP
>> +   else if (strcmp(argv[0], "write.qpp") == 0)
>> +   ret = spi_flash_write_qpp(flash, offset, len, buf);
>> +#endif
>> else
>> ret = spi_flash_write(flash, offset, len, buf);
>>
>> @@ -300,7 +304,7 @@ static int do_spi_flash(cmd_tbl_t *cmdtp, int flag, 
>> int argc, char * const argv[
>> }
>>
>> if (strcmp(cmd, "read") == 0 || strcmp(cmd, "write") == 0 ||
>> -   strcmp(cmd, "update") == 0)
>> +   strcmp(cmd, "update") == 0 || strcmp(cmd, "write.qpp") == 0)
>> ret = do_spi_flash_read_write(argc, argv);
>> else if (strcmp(cmd, "erase") == 0)
>> ret = do_spi_flash_erase(argc, argv);
>> @@ -327,5 +331,9 @@ U_BOOT_CMD(
>> "sf erase offset [+]len - erase `len' bytes from 
>> `offset'\n"
>> " `+len' round up `len' to block 
>> size\n"
>> "sf update addr offset len  - erase and write `len' bytes 
>> from memory\n"
>> -   " at `addr' to flash at `offset'"
>> +   " at `addr' to flash at 
>> `offset'\n"
>> +#ifdef CONFIG_CMD_SF_QPP
>> +   "sf write.qpp addr offset len   - write `len' bytes from 
>> memory\n"
>> +   " at `addr' to flash at `offset' 
>> using Quad-input Page Program(32h)"
>> +#endif
>>  );
>> diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
>> index a8f0af0..3545f59 100644
>> --- a/drivers/mtd/spi/spi_flash.c
>> +++ b/drivers/mtd/spi/spi_flash.c
>> @@ -122,6 +122,114 @@ int spi_flash_cmd_write_multi(struct spi_flash 
>> *flash, u32 offset,
>> return ret;
>>  }
>>
>> +#ifdef CONFIG_CMD_SF_QPP
>> +int spi_flash_set_quad_enable_bit(struct spi_flash *flash)
>> +{
>> +   u8 cmd = CMD_READ_CONFIG;
>> +   u8 data = 0;
>> +   int ret;
>> +
>> +   ret = spi_flash_read_common(flash,
>> +   &cmd, sizeof(cmd), &data, sizeof(data));
>> +   if (ret < 0) {
>> +   debug("SF: fail to read config register\n");
>> +   return ret;
>> +   }
>> +
>> +   if (da

[U-Boot] Bricked when trying to attach UBI

[Luca Ceresoli]

Hi all,

I am facing a problem with some boards that do not boot after some
weeks or months of normal usage, being unable to attach UBI. They do
not boot anymore event after a power cycle, in other words they are
totally bricked.
I don't know exactly what problem UBI has, but it is recoverable by
Linux, but apparently not by U-Boot.

The boards are DIG297 (dig297 board in mainline U-Boot), based on
OMAP3530 and equipped with a NAND flash (Micron MT29F2G16ABBEAHC) as
their unique permanent storage.

U-Boot v2012.04.01 starts correctly. The bootcmd tries to load the
kernel from UBI, starting with the following commands:

echo Booting from nand ...
setenv bootargs console=ttyO2,115200n8 
mtdparts=omap2-nand.0:768k(uboot),128k(reserved),128k(uboot-env),-(ubi) 
ubi.mtd=3 root=ubi0:rootfs ro rootfstype=ubifs ip=

ubi part nand0,3
...

On "bricked" devices the output of the "ubi part nand0,3" command is:

Creating 1 MTD partitions on "nand0":
0x0010-0x1000 : "mtd=3"
UBI: attaching mtd1 to ubi0
UBI: physical eraseblock size:   131072 bytes (128 KiB)
UBI: logical eraseblock size:129024 bytes
UBI: smallest flash I/O unit:2048
UBI: sub-page size:  512
UBI: VID header offset:  512 (aligned 512)
UBI: data offset:2048
UBI error: ubi_wl_init_scan: no enough physical eraseblocks (0, need 1)

Now the device is totally blocked, and power cycling does not change
the result.

The interesting thing is that if I load Linux (2.6.37 + OMAP patches +
board support patches) via TFTP and boot it with bootm, it correctly
attaches UBI (fixing any problem it may have) and boots correctly.
After that the board is unbricked: U-Boot can boot again normally from
NAND.

Without the ambition of understanding all UBI internals, I tried to
visually inspect the UBI code around the line where the error is
produced and compare it to the corresponding Linux sources. They looked
extremely similar, so I haven't and obvious hint of why U-Boot and
Linux produce different results.

I also tried with an updated U-Boot master, but the error is still
there.

Obviously I have changed nothing in the UBI and MTD code, both in
U-Boot and in Linux.

Can you suggest a proper way to track the root of the problem, or to
bypass it?

Big thanks in advance,

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