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

[Wolfgang Denk]

Dear Tom,

The following changes since commit cddb6b8304bfbc34f43920051256de7fe6c4c0ab:

  Prepare v2014.01-rc3 (2014-01-13 14:36:17 -0500)

are available in the git repository at:

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

for you to fetch changes up to 91167bdaec8470360bc424eccc5ec6d7620e14d4:

  PPC: remove support for MPC82xx processors (2014-01-15 08:11:22 +0100)

Note:   I did a full build test for all (remaining) Power
Architecture boards, and sample builds for some ARM and MIPS
boards.

Note 2: Patch # 2 has been truncated on the ML due to it's size; the
full version is available at [1], or from the aforementioned
git repository, of course.

[1] 
http://www.denx.de/wiki/pub/U-Boot/TooBigPatches/0002-PPC-remove-support-for-MPC82xx-processors.patch


Wolfgang Denk (2):
  doc/README.scrapyard: update commit IDs, use TAB for indentation
  PPC: remove support for MPC82xx processors

 MAKEALL  |   12 -
 Makefile |1 -
 README   |   70 +-
 api/api_platform-powerpc.c   |2 +-
 arch/powerpc/cpu/mpc824x/Makefile|   11 -
 arch/powerpc/cpu/mpc824x/config.mk   |8 -
 arch/powerpc/cpu/mpc824x/cpu.c   |  262 -
 arch/powerpc/cpu/mpc824x/cpu_init.c  |  399 
 arch/powerpc/cpu/mpc824x/drivers/epic.h  |1 -
 arch/powerpc/cpu/mpc824x/drivers/epic/README |  102 --
 arch/powerpc/cpu/mpc824x/drivers/epic/epic.h |  163 ---
 arch/powerpc/cpu/mpc824x/drivers/epic/epic1.c|  517 --
 arch/powerpc/cpu/mpc824x/drivers/epic/epic2.S|  196 
 arch/powerpc/cpu/mpc824x/drivers/epic/epicutil.S |   57 --
 arch/powerpc/cpu/mpc824x/drivers/errors.h|  212 
 arch/powerpc/cpu/mpc824x/drivers/i2c/i2c.c   |  254 -
 arch/powerpc/cpu/mpc824x/drivers/i2c_export.h|  103 --
 arch/powerpc/cpu/mpc824x/interrupts.c|   77 --
 arch/powerpc/cpu/mpc824x/pci.c   |   75 --
 arch/powerpc/cpu/mpc824x/speed.c |  102 --
 arch/powerpc/cpu/mpc824x/start.S |  729 --
 arch/powerpc/cpu/mpc824x/traps.c |  194 
 arch/powerpc/cpu/mpc824x/u-boot.lds  |   76 --
 arch/powerpc/cpu/mpc8260/Makefile|   13 -
 arch/powerpc/cpu/mpc8260/bedbug_603e.c   |  236 -
 arch/powerpc/cpu/mpc8260/commproc.c  |  178 
 arch/powerpc/cpu/mpc8260/config.mk   |9 -
 arch/powerpc/cpu/mpc8260/cpu.c   |  321 --
 arch/powerpc/cpu/mpc8260/cpu_init.c  |  276 -
 arch/powerpc/cpu/mpc8260/ether_fcc.c | 1172 --
 arch/powerpc/cpu/mpc8260/ether_scc.c |  367 ---
 arch/powerpc/cpu/mpc8260/i2c.c   |  740 --
 arch/powerpc/cpu/mpc8260/interrupts.c|  263 -
 arch/powerpc/cpu/mpc8260/kgdb.S  |   56 --
 arch/powerpc/cpu/mpc8260/pci.c   |  450 -
 arch/powerpc/cpu/mpc8260/serial_scc.c|  492 -
 arch/powerpc/cpu/mpc8260/serial_smc.c|  461 -
 arch/powerpc/cpu/mpc8260/speed.c |  228 -
 arch/powerpc/cpu/mpc8260/speed.h |   38 -
 arch/powerpc/cpu/mpc8260/spi.c   |  415 
 arch/powerpc/cpu/mpc8260/start.S |  992 --
 arch/powerpc/cpu/mpc8260/traps.c |  248 -
 arch/powerpc/cpu/mpc8260/u-boot.lds  |   75 --
 arch/powerpc/cpu/mpc83xx/start.S |2 +-
 arch/powerpc/include/asm/cpm_8260.h  |  795 ---
 arch/powerpc/include/asm/global_data.h   |2 -
 arch/powerpc/include/asm/immap_8260.h|  604 ---
 arch/powerpc/include/asm/iopin_8260.h|  168 
 arch/powerpc/include/asm/m8260_pci.h |  165 ---
 arch/powerpc/include/asm/mpc8349_pci.h   |6 +-
 arch/powerpc/include/asm/processor.h |8 -
 arch/powerpc/include/asm/status_led.h|4 +-
 arch/powerpc/include/asm/u-boot.h|2 +-
 arch/powerpc/lib/board.c |6 +-
 arch/powerpc/lib/kgdb.c  |   50 -
 board/a3000/Makefile |8 -
 board/a3000/README   |   17 -
 board/a3000/a3000.c  |  101 --
 board/a3000/flash.c  |  438 
 board/atc/Makefile   |8 -
 board/atc/atc.c  |  382 ---
 board/atc/flash.c|  647 
 board/atc/ti113x.c   |  620 
 board/cogent/kbm.c  

[U-Boot] [PATCH 2/2] PPC: remove support for MPC82xx processors

[Wolfgang Denk]

This commit removes support for the Freescale MPC82xx Power
Architecture processors, i. e. MPC8240, MPC8245, MPC8247, MPC8248,
MPC8250, MPC8255, MPC8260, MPC8265, MPC8266, MPC8272, MPC8280, ...

They have been out of production for years, and no active users left
here.  As some boards start causing problems, let's drop the obsolete
and now dead code.

Signed-off-by: Wolfgang Denk 
Cc: Brad Kemp 
Cc: Frank Panno 
Cc: Greg Allen 
Cc: Heiko Schocher 
Cc: Holger Brunck 
Cc: Jerry Van Baren 
Cc: Jim Thompson 
Cc: Josef Wagner 
Cc: Murray Jensen 
Cc: Oliver Brown 
Cc: Rune Torgersen 
Cc: Sangmoon Kim 
Cc: Torsten Demke 
Cc: Wolfgang Grandegger 
Cc: Yuli Barcohen 
Cc: Yusdi Santoso 
---

Due to it's size (2.3 MB) only the header of this patch is presented
here.  The full patch is available here:

http://www.denx.de/wiki/pub/U-Boot/TooBigPatches/0002-PPC-remove-support-for-MPC82xx-processors.patch

 MAKEALL  |   12 -
 Makefile |1 -
 README   |   70 +-
 api/api_platform-powerpc.c   |2 +-
 arch/powerpc/cpu/mpc824x/Makefile|   11 -
 arch/powerpc/cpu/mpc824x/config.mk   |8 -
 arch/powerpc/cpu/mpc824x/cpu.c   |  262 -
 arch/powerpc/cpu/mpc824x/cpu_init.c  |  399 
 arch/powerpc/cpu/mpc824x/drivers/epic.h  |1 -
 arch/powerpc/cpu/mpc824x/drivers/epic/README |  102 --
 arch/powerpc/cpu/mpc824x/drivers/epic/epic.h |  163 ---
 arch/powerpc/cpu/mpc824x/drivers/epic/epic1.c|  517 --
 arch/powerpc/cpu/mpc824x/drivers/epic/epic2.S|  196 
 arch/powerpc/cpu/mpc824x/drivers/epic/epicutil.S |   57 --
 arch/powerpc/cpu/mpc824x/drivers/errors.h|  212 
 arch/powerpc/cpu/mpc824x/drivers/i2c/i2c.c   |  254 -
 arch/powerpc/cpu/mpc824x/drivers/i2c_export.h|  103 --
 arch/powerpc/cpu/mpc824x/interrupts.c|   77 --
 arch/powerpc/cpu/mpc824x/pci.c   |   75 --
 arch/powerpc/cpu/mpc824x/speed.c |  102 --
 arch/powerpc/cpu/mpc824x/start.S |  729 --
 arch/powerpc/cpu/mpc824x/traps.c |  194 
 arch/powerpc/cpu/mpc824x/u-boot.lds  |   76 --
 arch/powerpc/cpu/mpc8260/Makefile|   13 -
 arch/powerpc/cpu/mpc8260/bedbug_603e.c   |  236 -
 arch/powerpc/cpu/mpc8260/commproc.c  |  178 
 arch/powerpc/cpu/mpc8260/config.mk   |9 -
 arch/powerpc/cpu/mpc8260/cpu.c   |  321 --
 arch/powerpc/cpu/mpc8260/cpu_init.c  |  276 -
 arch/powerpc/cpu/mpc8260/ether_fcc.c | 1172 --
 arch/powerpc/cpu/mpc8260/ether_scc.c |  367 ---
 arch/powerpc/cpu/mpc8260/i2c.c   |  740 --
 arch/powerpc/cpu/mpc8260/interrupts.c|  263 -
 arch/powerpc/cpu/mpc8260/kgdb.S  |   56 --
 arch/powerpc/cpu/mpc8260/pci.c   |  450 -
 arch/powerpc/cpu/mpc8260/serial_scc.c|  492 -
 arch/powerpc/cpu/mpc8260/serial_smc.c|  461 -
 arch/powerpc/cpu/mpc8260/speed.c |  228 -
 arch/powerpc/cpu/mpc8260/speed.h |   38 -
 arch/powerpc/cpu/mpc8260/spi.c   |  415 
 arch/powerpc/cpu/mpc8260/start.S |  992 --
 arch/powerpc/cpu/mpc8260/traps.c |  248 -
 arch/powerpc/cpu/mpc8260/u-boot.lds  |   75 --
 arch/powerpc/cpu/mpc83xx/start.S |2 +-
 arch/powerpc/include/asm/cpm_8260.h  |  795 ---
 arch/powerpc/include/asm/global_data.h   |2 -
 arch/powerpc/include/asm/immap_8260.h|  604 ---
 arch/powerpc/include/asm/iopin_8260.h|  168 
 arch/powerpc/include/asm/m8260_pci.h |  165 ---
 arch/powerpc/include/asm/mpc8349_pci.h   |6 +-
 arch/powerpc/include/asm/processor.h |8 -
 arch/powerpc/include/asm/status_led.h|4 +-
 arch/powerpc/include/asm/u-boot.h|2 +-
 arch/powerpc/lib/board.c |6 +-
 arch/powerpc/lib/kgdb.c  |   50 -
 board/a3000/Makefile |8 -
 board/a3000/README   |   17 -
 board/a3000/a3000.c  |  101 --
 board/a3000/flash.c  |  438 
 board/atc/Makefile   |8 -
 board/atc/atc.c  |  382 ---
 board/atc/flash.c|  647 
 board/atc/ti113x.c   |  620 
 board/cogent/kbm.c   |3 -
 board/cogent/kbm.h   |   79 --
 board/cogent/

Re: [U-Boot] [PATCH 2/2] PPC: remove support for MPC82xx processors

[Holger Brunck]

Hi Wolfgang,

On 01/15/2014 08:48 AM, Wolfgang Denk wrote:
> This commit removes support for the Freescale MPC82xx Power
> Architecture processors, i. e. MPC8240, MPC8245, MPC8247, MPC8248,
> MPC8250, MPC8255, MPC8260, MPC8265, MPC8266, MPC8272, MPC8280, ...
> 
> They have been out of production for years, and no active users left
> here.  As some boards start causing problems, let's drop the obsolete
> and now dead code.
> 

thats not valid for us. Our mgcoge3ne target which comes with a MPC8247 is still
in production and maintained. If you look at the git log of
include/configs/km82xx.h you will see that there were still commits in 2013.
Even if there are no further changes expected yet, it's still possible that we
need to adapt something e.g. if the SDRAM needs to be replaced in the future.

So isn't it possible to remove only the broken boards and keep the generic 
parts?

Best regards
Holger

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

Re: [U-Boot] [PATCH v5 03/12] samsung: common: Add misc file and common function misc_init_r().

[Piotr Wilczek]

Dear Przemyslaw,

> -Original Message-
> From: Przemyslaw Marczak [mailto:p.marc...@samsung.com]
> Sent: Wednesday, January 15, 2014 8:51 AM
> To: Minkyu Kang
> Cc: u-boot@lists.denx.de; jh80.ch...@samsung.com;
> human.hw...@samsung.com; dh09@samsung.com; ideal.s...@samsung.com;
> Piotr Wilczek; Lukasz Majewski
> Subject: Re: [PATCH v5 03/12] samsung: common: Add misc file and common
> function misc_init_r().
> 
> Hello,
> 
> On 01/15/2014 08:35 AM, Minkyu Kang wrote:
> > On 14/01/14 22:55, Przemyslaw Marczak wrote:
> >> Hello,
> >> In case of discussion with Piotr Wilczek maybe it is better to make
> some changes in this patch.
> >>
> >> On 01/10/2014 03:31 PM, Przemyslaw Marczak wrote:
> >>> Config: CONFIG_MISC_INIT_R enables implementation of misc_init_r()
> >>> in common file::
> >>> - board/samsung/common/misc.c
> >>>
> >>> Signed-off-by: Przemyslaw Marczak 
> >>> Acked-by: Jaehoon Chung 
> >>> ---
> >>> Changes v2:
> >>> - change CONFIG_SAMSUNG to CONFIG_MISC_INIT_R
> >>>
> >>> Changes v3:
> >>> - fix merge conflict in board/samsung/common/Makefile
> >>>
> >>> Changes v4:
> >>> - none
> >>>
> >>> Changes v5:
> >>> - add acked-by
> >>>
> >>>board/samsung/common/Makefile |1 +
> >>>board/samsung/common/misc.c   |   14 ++
> >>>2 files changed, 15 insertions(+)
> >>>create mode 100644 board/samsung/common/misc.c
> >>>
> >>> diff --git a/board/samsung/common/Makefile
> >>> b/board/samsung/common/Makefile index 22bd6b1..79547a3 100644
> >>> --- a/board/samsung/common/Makefile
> >>> +++ b/board/samsung/common/Makefile
> >>> @@ -8,6 +8,7 @@
> >>>obj-$(CONFIG_SOFT_I2C_MULTI_BUS) += multi_i2c.o
> >>>obj-$(CONFIG_THOR_FUNCTION) += thor.o
> >>>obj-$(CONFIG_CMD_USB_MASS_STORAGE) += ums.o
> >>> +obj-$(CONFIG_MISC_INIT_R) += misc.o
> >> here change to:
> >> obj-y += misc.o
> >>
> >>>
> >>>ifndef CONFIG_SPL_BUILD
> >>>obj-$(CONFIG_BOARD_COMMON)+= board.o
> >>> diff --git a/board/samsung/common/misc.c
> >>> b/board/samsung/common/misc.c new file mode 100644 index
> >>> 000..3764d12
> >>> --- /dev/null
> >>> +++ b/board/samsung/common/misc.c
> >>> @@ -0,0 +1,14 @@
> >>> +/*
> >>> + * Copyright (C) 2013 Samsung Electronics
> >>> + * Przemyslaw Marczak 
> >>> + *
> >>> + * SPDX-License-Identifier:GPL-2.0+
> >>> + */
> >>> +
> >>> +#include 
> >>> +
> >>
> >> and here:
> >> #ifdef CONFIG_MISC_INIT_R
> >>
> >>> +/* Common for Samsung boards */
> >>> +int misc_init_r(void)
> >>> +{
> >>> +return 0;
> >>> +}
> >>>
> >> #endif
> >>
> >> In this way we can add other functions in the future even without
> CONFIG_MISC_INIT_R.
> >
> > partly agree.
> > But, I doubt what is the role of misc.c file.
> > because of the meaning of miscellaneous is ambiguous, this file have
> > possibility to be messy.
> > So, please let me know what is your plan to this file.
> >
> 
> I first planned put there only implementation of misc_init_r() and it's
> subfunctions - as the easy way to display logo and menu for Samsung
> boards.
> Piotr has suggested to change the purpose of this file as misc not only
> for misc_init_r implementation...
Przemyslaw, I asked you question: what is the misc.c file for?
If for misc_init_r only then I think the file name "misc.c" is confusing.
If also other common functions can be put there, then the define MISC_INIT_R
to compile this file is wrong.

> 
> >>
> >> Is it better solution?
> >>
> >> Thank you,
> >
> > Thanks,
> > Minkyu Kang.
> >
> 
> Thank you,
> --
> Przemyslaw Marczak
> Samsung R&D Institute Poland
> Samsung Electronics
> p.marc...@samsung.com

Best regards,
Piotr Wilczek



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

[U-Boot] [PATCH] arm64 patch: gicv3 support

[fenghua]

From: David Feng 

This patch add gicv3 support to uboot armv8 platform.
Modifications cover 4 source files, as follows:
  gic.S: gicv3 initialization and sgi interrupt raising.
  goc.h: gicv3 register definitions.
  vexpress_aemv8a.h: add CONFIG_GICV2/CONFIG_GICV3 switch.
  start.S: set SCR_EL3.NS bit to 1, gicv3 register of ICC_SRE_EL2
   could be accessed only when SCR_EL3.NS=1.
   set SCR_EL3.IRQ|FIQ|EA bits, reroute all interrupts to
   el3 at all cores, slaves could be waken up by interrupt
   only when the interrupt is routed to it when running
   at el3.
Note: please use the latest gcc 4.8 compiler from linaro 
  which support gicv3 system register assembling.

Signed-off-by: David Feng 
---
 arch/arm/cpu/armv8/gic.S  |   84 -
 arch/arm/cpu/armv8/start.S|5 ++-
 arch/arm/include/asm/gic.h|   56 +
 include/configs/vexpress_aemv8a.h |7 
 4 files changed, 150 insertions(+), 2 deletions(-)

diff --git a/arch/arm/cpu/armv8/gic.S b/arch/arm/cpu/armv8/gic.S
index 599aa8f..a08939a 100644
--- a/arch/arm/cpu/armv8/gic.S
+++ b/arch/arm/cpu/armv8/gic.S
@@ -23,6 +23,74 @@
  *
  */
 WEAK(gic_init)
+#if defined(CONFIG_GICV3)
+   branch_if_slave x0, 3f
+
+   /* Initialize Distributor */
+   ldr x1, =GICD_BASE
+   mov w0, #0x37   /* EnableGrp0 | EnableGrp1NS */
+   /* EnableGrp1S | ARE_S | ARE_NS */
+   str w0, [x1, GICD_CTLR] /* Secure GICD_CTLR */
+   ldr w0, [x1, GICD_TYPER]
+   and w2, w0, #0x1f   /* ITLinesNumber */
+   cbz w2, 1f  /* No SPIs */
+   add x3, x1, (GICD_IGROUPRn + 4)
+   add x4, x1, (GICD_IGROUPMODRn + 4)
+   mov w5, #~0
+0: str w5, [x3], #0x4
+   str wzr, [x4], #0x4 /* Config SPIs as Group1NS */
+   sub w2, w2, #0x1
+   cbnzw2, 0b
+
+   /* Initialize All ReDistributors */
+1: ldr x1, =GICR_BASE
+2: mov w0, #~0x2
+   ldr w2, [x1, GICR_WAKER]
+   and w2, w2, w0  /* Clear ProcessorSleep */
+   str w2, [x1, GICR_WAKER]
+   dsb st
+   isb
+0: ldr w0, [x1, GICR_WAKER]
+   tbnzw0, #2, 0b  /* Wait Children be Alive */
+
+   add x2, x1, #(1 << 16)  /* SGI_Base */
+   mov w5, #~0
+   str w5, [x2, GICR_IGROUPRn]
+   str wzr, [x2, GICR_IGROUPMODRn] /* SGIs|PPIs Group1NS */
+   mov w0, #0x1/* Enable SGI 0 */
+   str w0, [x2, GICR_ISENABLERn]
+
+   ldr w0, [x1, GICR_TYPER]
+   add x1, x1, #(2 << 16)
+   tbz w0, #4, 2b  /* Next ReDistributor if Exist */
+
+   /* Initialize Cpu Interface */
+3: mrs x0, ICC_SRE_EL3
+   orr x0, x0, #0xf/* SRE & Disable IRQ/FIQ Bypass & */
+   /* Allow EL2 access to ICC_SRE_EL2 */
+   msr ICC_SRE_EL3, x0
+   isb
+
+   mrs x0, ICC_SRE_EL2
+   orr x0, x0, #0xf/* SRE & Disable IRQ/FIQ Bypass & */
+   /* Allow EL1 access to ICC_SRE_EL1 */
+   msr ICC_SRE_EL2, x0
+   isb
+
+   mov x0, #0x3/* EnableGrp1NS | EnableGrp1S */
+   msr ICC_IGRPEN1_EL3, x0
+   isb
+
+   msr ICC_CTLR_EL3, xzr
+   isb
+
+   msr ICC_CTLR_EL1, xzr   /* NonSecure ICC_CTLR_EL1 */
+   isb
+
+   mov x0, #0x1 << 7   /* Non-Secure access to ICC_PMR_EL1 */
+   msr ICC_PMR_EL1, x0
+   isb
+#elif defined(CONFIG_GICV2)
branch_if_slave x0, 2f
 
/* Initialize Distributor and SPIs */
@@ -54,7 +122,7 @@ WEAK(gic_init)
 
mov w0, #0x1 << 7   /* Non-Secure access to GICC_PMR */
str w0, [x1, GICC_PMR]
-
+#endif
ret
 ENDPROC(gic_init)
 
@@ -65,11 +133,18 @@ ENDPROC(gic_init)
  *
  */
 WEAK(gic_send_sgi)
+#if defined(CONFIG_GICV3)
+   mov x1, #(1 << 40)
+   orr x1, x1, x0, lsl #24
+   msr ICC_ASGI1R_EL1, x1
+   isb
+#elif defined(CONFIG_GICV2)
ldr x1, =GICD_BASE
mov w2, #0x8000
movkw2, #0x100, lsl #16
orr w2, w2, w0
str w2, [x1, GICD_SGIR]
+#endif
ret
 ENDPROC(gic_send_sgi)
 
@@ -82,11 +157,18 @@ ENDPROC(gic_send_sgi)
  *
  */
 WEAK(wait_for_wakeup)
+#if defined(CONFIG_GICV3)
+0: wfi
+   mrs x0, ICC_IAR1_EL1
+   msr ICC_EOIR1_EL1, x0
+   cbnzx0, 0b
+#elif defined(CONFIG_GICV2)
ldr x1, =GICC_BASE
 0: wfi
ldr w0, [x1, GICC_AIAR]
str w0,

Re: [U-Boot] [PATCH v5 03/12] samsung: common: Add misc file and common function misc_init_r().

[Przemyslaw Marczak]

Hello Piotr,

On 01/15/2014 09:08 AM, Piotr Wilczek wrote:

Dear Przemyslaw,


-Original Message-
From: Przemyslaw Marczak [mailto:p.marc...@samsung.com]
Sent: Wednesday, January 15, 2014 8:51 AM
To: Minkyu Kang
Cc: u-boot@lists.denx.de; jh80.ch...@samsung.com;
human.hw...@samsung.com; dh09@samsung.com; ideal.s...@samsung.com;
Piotr Wilczek; Lukasz Majewski
Subject: Re: [PATCH v5 03/12] samsung: common: Add misc file and common
function misc_init_r().

Hello,

On 01/15/2014 08:35 AM, Minkyu Kang wrote:

On 14/01/14 22:55, Przemyslaw Marczak wrote:

Hello,
In case of discussion with Piotr Wilczek maybe it is better to make

some changes in this patch.


On 01/10/2014 03:31 PM, Przemyslaw Marczak wrote:

Config: CONFIG_MISC_INIT_R enables implementation of misc_init_r()
in common file::
- board/samsung/common/misc.c

Signed-off-by: Przemyslaw Marczak 
Acked-by: Jaehoon Chung 
---
Changes v2:
- change CONFIG_SAMSUNG to CONFIG_MISC_INIT_R

Changes v3:
- fix merge conflict in board/samsung/common/Makefile

Changes v4:
- none

Changes v5:
- add acked-by

board/samsung/common/Makefile |1 +
board/samsung/common/misc.c   |   14 ++
2 files changed, 15 insertions(+)
create mode 100644 board/samsung/common/misc.c

diff --git a/board/samsung/common/Makefile
b/board/samsung/common/Makefile index 22bd6b1..79547a3 100644
--- a/board/samsung/common/Makefile
+++ b/board/samsung/common/Makefile
@@ -8,6 +8,7 @@
obj-$(CONFIG_SOFT_I2C_MULTI_BUS) += multi_i2c.o
obj-$(CONFIG_THOR_FUNCTION) += thor.o
obj-$(CONFIG_CMD_USB_MASS_STORAGE) += ums.o
+obj-$(CONFIG_MISC_INIT_R) += misc.o

here change to:
obj-y += misc.o



ifndef CONFIG_SPL_BUILD
obj-$(CONFIG_BOARD_COMMON)+= board.o
diff --git a/board/samsung/common/misc.c
b/board/samsung/common/misc.c new file mode 100644 index
000..3764d12
--- /dev/null
+++ b/board/samsung/common/misc.c
@@ -0,0 +1,14 @@
+/*
+ * Copyright (C) 2013 Samsung Electronics
+ * Przemyslaw Marczak 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+


and here:
#ifdef CONFIG_MISC_INIT_R


+/* Common for Samsung boards */
+int misc_init_r(void)
+{
+return 0;
+}


#endif

In this way we can add other functions in the future even without

CONFIG_MISC_INIT_R.


partly agree.
But, I doubt what is the role of misc.c file.
because of the meaning of miscellaneous is ambiguous, this file have
possibility to be messy.
So, please let me know what is your plan to this file.



I first planned put there only implementation of misc_init_r() and it's
subfunctions - as the easy way to display logo and menu for Samsung
boards.
Piotr has suggested to change the purpose of this file as misc not only
for misc_init_r implementation...

Przemyslaw, I asked you question: what is the misc.c file for?
If for misc_init_r only then I think the file name "misc.c" is confusing.
If also other common functions can be put there, then the define MISC_INIT_R
to compile this file is wrong.



Yes, and next I said that maybe I will change this config dependency, 
and now I try to do it.






Is it better solution?

Thank you,


Thanks,
Minkyu Kang.



Thank you,
--
Przemyslaw Marczak
Samsung R&D Institute Poland
Samsung Electronics
p.marc...@samsung.com


Best regards,
Piotr Wilczek






Thank you,
--
Przemyslaw Marczak
Samsung R&D Institute Poland
Samsung Electronics
p.marc...@samsung.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] doc/README.scrapyard: update commit IDs, use TAB for indentation

[Masahiro Yamada]

Hello Wolfgang


>  Over time, support for more and more boards gets added to U-Boot -
>  while other board support code dies a silent death caused by
> -negligence in combination with ordinary bitrot.  Sometimes this goes
> +negligence in combination with ordinary bitrot.   Sometimes this goes
>  by unnoticed, but often build errors will result.  If nobody cares any
>  more to resolve such problems, then the code is really dead and will
> -be removed from the U-Boot source tree.  The remainders rest in piece
> -in the imperishable depths of the git history.  This document tries to
> +be removed from the U-Boot source tree.   The remainders rest in piece
> +in the imperishable depths of the git history.   This document tries to
>  maintain a list of such former fellows, so archeologists can check
>  easily if here is something they might want to dig for...

Why did you insert TABs here?



>  
> -BoardArchCPUCommit  Removed Last 
> known maintainer/contact
> +BoardArchCPU Commit  Removed 
> Last known maintainer/contact
  <>
> +A3000powerpc mpc824x -   -
> +CU824powerpc mpc824x -   -   
> Wolfgang Denk 
> +debris   powerpc mpc824x -   -   
> Sangmoon Kim 
> +eXalion  powerpc mpc824x -   -   
> Torsten Demke 


You are using TABs and SPACEs mixed-up.

"ARCH" field is aligned by TAB. There are TABs between A3000 and powerpc.
Whereas, "CPU" field is aligned by SPACE. There are some SPACEs between
powerpc and mpc824x.

If you do this refactoring, I'd like to request that only TABs are used
consistently.


And another thing , this series can not applied on the current
u-boot/master.
(I think Tom can resolve the conflict.)


Best Regards
Masahiro Yamada

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

[U-Boot] [PATCH] board: delete meaningless serial.h

[Masahiro Yamada]

Delete some serial.h files, whole code in which is surrounded by
  #if 0 ... #endif

Signed-off-by: Masahiro Yamada 
---

 board/Marvell/common/serial.c |  1 -
 board/Marvell/common/serial.h | 73 ---
 board/esd/cpci750/serial.c|  1 -
 board/esd/cpci750/serial.h| 73 ---
 board/evb64260/serial.c   |  2 --
 board/evb64260/serial.h   | 63 -
 board/prodrive/p3mx/serial.c  |  1 -
 board/prodrive/p3mx/serial.h  | 73 ---
 8 files changed, 287 deletions(-)
 delete mode 100644 board/Marvell/common/serial.h
 delete mode 100644 board/esd/cpci750/serial.h
 delete mode 100644 board/evb64260/serial.h
 delete mode 100644 board/prodrive/p3mx/serial.h

diff --git a/board/Marvell/common/serial.c b/board/Marvell/common/serial.c
index 56ba0da..752492f 100644
--- a/board/Marvell/common/serial.c
+++ b/board/Marvell/common/serial.c
@@ -20,7 +20,6 @@
 #include 
 
 #include "../include/memory.h"
-#include "serial.h"
 
 #ifdef CONFIG_DB64360
 #include "../db64360/mpsc.h"
diff --git a/board/Marvell/common/serial.h b/board/Marvell/common/serial.h
deleted file mode 100644
index 264e2d2..000
--- a/board/Marvell/common/serial.h
+++ /dev/null
@@ -1,73 +0,0 @@
-/*
- * (C) Copyright 2001
- * Josh Huber , Mission Critical Linux, Inc.
- *
- * modified for marvell db64360 eval board by
- * Ingo Assmus 
- *
- * SPDX-License-Identifier:GPL-2.0+
- */
-
-/* serial.h - mostly useful for DUART serial_init in serial.c */
-
-#ifndef __SERIAL_H__
-#define __SERIAL_H__
-
-#if 0
-
-#define B230400 1
-#define B115200 2
-#define B57600  4
-#define B38400  82
-#define B19200  163
-#define B9600   24
-#define B4800   651
-#define B2400   1302
-#define B1200   2604
-#define B6005208
-#define B30010417
-#define B15020833
-#define B11028409
-#define BDEFAULTB115200
-
-   /* this stuff is important to initialize
-   the DUART channels */
-
-#defineScale   0x01L   /* distance between port 
addresses */
-#defineCOM10x03f8  /* Keyboard */
-#define COM2   0x02f8  /* Host */
-
-
-/* Port Definitions relative to base COM port addresses */
-#define DataIn (0x00*Scale)/* data input port */
-#define DataOut(0x00*Scale)/* data output port */
-#define BaudLsb(0x00*Scale)/* baud rate divisor least significant 
byte */
-#define BaudMsb(0x01*Scale)/* baud rate divisor most significant 
byte */
-#defineIer (0x01*Scale)/* interrupt enable register */
-#defineIir (0x02*Scale)/* interrupt identification register */
-#defineLcr (0x03*Scale)/* line control register */
-#defineMcr (0x04*Scale)/* modem control register */
-#defineLsr (0x05*Scale)/* line status register */
-#defineMsr (0x06*Scale)/* modem status register */
-
-/* Bit Definitions for above ports */
-#define LcrDlab0x80/* b7:   enable baud rate divisor registers */
-#defineLcrDflt 0x03/* b6-0: no parity, 1 stop, 8 data */
-
-#defineMcrRts  0x02/* b1:  request to send (I am ready to xmit) */
-#defineMcrDtr  0x01/* b0:  data terminal ready (I am alive ready 
to rcv) */
-#defineMcrDflt (McrRts|McrDtr)
-
-#define LsrTxD 0x6000  /* b5: transmit holding register empty (i.e. xmit OK!)*/
-   /* b6: transmitter empty */
-#define LsrRxD 0x0100  /* b0: received data ready (i.e. got a byte!) */
-
-#defineMsrRi   0x0040  /* b6: ring indicator (other guy is ready to 
rcv) */
-#defineMsrDsr  0x0020  /* b5: data set ready (other guy is alive ready 
to rcv */
-#defineMsrCts  0x0010  /* b4: clear to send (other guy is ready to 
rcv) */
-
-#define IerRda 0xf /* b0: Enable received data available interrupt */
-
-#endif
-
-#endif /* __SERIAL_H__ */
diff --git a/board/esd/cpci750/serial.c b/board/esd/cpci750/serial.c
index f425105..6c2cf21 100644
--- a/board/esd/cpci750/serial.c
+++ b/board/esd/cpci750/serial.c
@@ -23,7 +23,6 @@
 #include 
 
 #include "../../Marvell/include/memory.h"
-#include "serial.h"
 
 #include "mpsc.h"
 
diff --git a/board/esd/cpci750/serial.h b/board/esd/cpci750/serial.h
deleted file mode 100644
index 264e2d2..000
--- a/board/esd/cpci750/serial.h
+++ /dev/null
@@ -1,73 +0,0 @@
-/*
- * (C) Copyright 2001
- * Josh Huber , Mission Critical Linux, Inc.
- *
- * modified for marvell db64360 eval board by
- * Ingo Assmus 
- *
- * SPDX-License-Identifier:GPL-2.0+
- */
-
-/* serial.h - mostly useful for DUART serial_init in serial.c */
-
-#ifndef __SERIAL_H__
-#define __SERIAL_H__
-
-#if 0
-
-#define B230400 1
-#define B115200 2

[U-Boot] sf: Discussion on quad changes

[Jagan Teki]

Hi All,

This particular discussion is a next level add-on for thread [1]

State of u-boot now:
- Added quad changes on u-boot and will be available in coming release.
- Added commands are
  1) 1-line # Array slow read, Array fast read(available before)
  2) 2-line # Dual fast read, Dual IO read
  3) 3-line # Quad fast read, quad IO read, Quad page program
- The implementation "will determine the fastest command by taking the supported
  commands from the flash and the controller, controller is always
been a priority."
- Suppose we have a flash that supports all types of commands then from driver
  side we have an option to set the particular command and the same option will
  goes to sf and will determine the fastest one.
  ex: if flash supports all, but the driver supports dual fast then
the outcome read
  could be dual fast.

And even Linux will also does the similar implementation, i guess.
The main reason for going maximum or based on controller setting transfer is to
improve sf performance.

But from previous thread of discussion - Gerhard Sittig, identified a
side-effect on this
implementation as per as board to connected flash perceptive.

The question as per my understanding was "If a controller support 1,
2, and 4 lines then
the BoardA is designed to connect a flash with 4-lines, BoardB is
designed to connect
a flash with 2-lines and BoardC is designed to connect a flash with 1-line."

In above scenario - as we have a common controller driver that may set
an option to support
quad then BoardB and BoardC will fail to transfer.

Gerhard Sittig, please add if i miss any points here!

I do agree this scenario and I have few possible inputs.
1) dynamic - auto-detection:
Get the max_nof_lines based on the board to connected flash.
So-that we can configure the transfer mode based on the lines.
no idea yet, how to get the max_nof_lines dynamically - any inputs.
2) static: from user level we may give the max_nof_lines
ex: sf probe probe [[[bus:]cs]:max_nof_line] [hz] [mode]
If user can't input max_nof_line so-that driver will go with single and
the rest case transfer modes assigned based on the given input.
for Linux it can be pdata or dts.

Request for comments!

[1] 
http://u-boot.10912.n7.nabble.com/PATCH-v7-01-17-sf-Add-extended-read-commands-support-td171225.html#a171290

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

Re: [U-Boot] [PATCH v2 2/3] mx6: Add initial support for the Hummingboard solo

[Stefano Babic]

On 03/01/2014 18:55, Fabio Estevam wrote:
> From: Fabio Estevam 
> 
> SolidRun has designed the Hummingboard board based on mx6q/dl/solo.
> 
> Add the initial support for the mx6 solo variant.
> 
> More information about this hardware can be found at:
> http://imx.solid-run.com/wiki/index.php?title=Carrier-One_Hardware
> 
> (Carrier-One was the previous name of Hummingboard).
> 
> Based on the work from Jon Nettleton .
> 
> Signed-off-by: Jon Nettleton 
> Signed-off-by: Fabio Estevam 
> ---


Applied to u-boot-imx, thanks !

Best regards,
Stefano Babic


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

Re: [U-Boot] [PATCH v2 1/3] mx6: clock: Pass the frequency as argument of enable_fec_anatop_clock()

[Stefano Babic]

On 03/01/2014 18:55, Fabio Estevam wrote:
> From: Fabio Estevam 
> 
> Provide an argument to enable_fec_anatop_clock() to specify the clock 
> frequency
> that will be generated.
> 
> No changes are made to mx6slevk, which uses the default 50MHz fec clock.
> 
> Signed-off-by: Fabio Estevam 
> ---

Applied to u-boot-imx, thanks !

Best regards,
Stefano Babic



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

[U-Boot] [PULL] : Please pull u-boot-imx

[Stefano Babic]

Hi Albert,

still a couple of patches for the release. Please pull from u-boot-imx,
thanks !

The following changes since commit a6bbee66197759f790de83181924bf1d2cf482b2:

  mx6slevk: Include "mx6_common.h" (2014-01-13 11:52:28 +0100)

are available in the git repository at:

  git://www.denx.de/git/u-boot-imx.git master

for you to fetch changes up to 3a21773129f6ef218f1978d05a1a5d5cf6801ab6:

  mx6: Add initial support for the Hummingboard solo (2014-01-15
10:33:25 +0100)


Fabio Estevam (2):
  mx6: clock: Pass the frequency as argument of
enable_fec_anatop_clock()
  mx6: Add initial support for the Hummingboard solo

 arch/arm/cpu/armv7/mx6/clock.c |8 +-
 arch/arm/include/asm/arch-mx6/clock.h  |9 +-
 arch/arm/include/asm/arch-mx6/imx-regs.h   |4 +
 board/freescale/mx6slevk/mx6slevk.c|2 +-
 board/solidrun/hummingboard/Makefile   |9 +
 board/solidrun/hummingboard/README |   40 
 board/solidrun/hummingboard/hummingboard.c |  187 
 board/solidrun/hummingboard/solo.cfg   |   25 +++
 board/solidrun/mx6-microsom/800mhz_2x128mx16.cfg   |   74 +++
 board/solidrun/mx6-microsom/clocks.cfg |   33 +++
 .../mx6-microsom/ddr-800mhz-32bit-setup.cfg|   76 +++
 boards.cfg |1 +
 include/configs/hummingboard.h |  226

 13 files changed, 691 insertions(+), 3 deletions(-)
 create mode 100644 board/solidrun/hummingboard/Makefile
 create mode 100644 board/solidrun/hummingboard/README
 create mode 100644 board/solidrun/hummingboard/hummingboard.c
 create mode 100644 board/solidrun/hummingboard/solo.cfg
 create mode 100644 board/solidrun/mx6-microsom/800mhz_2x128mx16.cfg
 create mode 100644 board/solidrun/mx6-microsom/clocks.cfg
 create mode 100644 board/solidrun/mx6-microsom/ddr-800mhz-32bit-setup.cfg
 create mode 100644 include/configs/hummingboard.h


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

Re: [U-Boot] [PATCH v5 04/12] samsung: misc: move display logo function to misc.c file.

[Przemyslaw Marczak]

Hi Minkyu,

On 01/14/2014 09:55 AM, Minkyu Kang wrote:

Dear Przemyslaw Marczak,

On 14/01/14 17:02, Przemyslaw Marczak wrote:

Hello Jaehoon,

On 01/14/2014 04:41 AM, Jaehoon Chung wrote:

Dear Przemyslaw,

On 01/10/2014 11:31 PM, Przemyslaw Marczak wrote:

board/samsung/common/misc.c:
- move draw_logo() function from exynos_fb.c
- add get_tizen_logo_info() function call removed from board files

boards:
- update board files
- add CONFIG_MISC_INIT_R to Universal, Trats and Trats2

Signed-off-by: Przemyslaw Marczak 
Tested-by: Hyungwon Hwang 
---
changes v2:
- configs cleanup
- add check logo address before display

Changes v3:
- none

Changes v4:
- none

Changes v5:
- none

   board/samsung/common/misc.c  |   42 
++
   board/samsung/trats/trats.c  |3 ---
   board/samsung/trats2/trats2.c|4 ---
   board/samsung/universal_c210/universal.c |4 ---
   drivers/video/exynos_fb.c|   28 
   include/configs/s5pc210_universal.h  |3 +++
   include/configs/trats.h  |3 +++
   include/configs/trats2.h |3 +++
   8 files changed, 51 insertions(+), 39 deletions(-)

diff --git a/board/samsung/common/misc.c b/board/samsung/common/misc.c
index 3764d12..6188e29 100644
--- a/board/samsung/common/misc.c
+++ b/board/samsung/common/misc.c
@@ -6,9 +6,51 @@
*/

   #include 
+#include 
+#include 
+
+#ifdef CONFIG_CMD_BMP
+static void draw_logo(void)
+{
+int x, y;
+ulong addr;
+
+#ifdef CONFIG_TIZEN
+get_tizen_logo_info(&panel_info);
+#else
+return;

if CONFIG_TINZE didn't set, draw_logo should be just return, right?
Then I think this point could be changed more readable.

#ifdef CONFIG_TIZEN
 int x, y;
 ulong addr;

 get_tizen_logo_info(...);

 add = panel_info.logo_addr;
 ...
 bmp_display(addr, x, y);
#endif

how about?

Best Regards,
Jaehoon Chung




You know, this file is common for all Samsung platforms,and I think this function should 
not depends only on Tizen logo. In this case user can choose other logo just by adding 
function like "get_logo" instead of the return statement. I also think that 
there is need for some common function which allows set proper logo by board config, but 
maybe not in this patch set?


I agreed with you.

You said that "there is need for some common function which allows set proper logo 
by board config".
At previous version of board files, you already have common function 
(init_panel_info - even though this function is not for the logo but I think, 
it's enough).

@@ -484,10 +484,6 @@ void init_panel_info(vidinfo_t *vid)
vid->resolution  = HD_RESOLUTION;
vid->rgb_mode= MODE_RGB_P;

-#ifdef CONFIG_TIZEN
-   get_tizen_logo_info(vid);
-#endif
-
/* for LD9040. */
vid->pclk_name = 1;  /* MPLL */
vid->sclk_div = 1;

If you remove this change at each boards, then you don't have add ifdef 
CONFIG_TIZEN at draw_logo function.
It can be split common stuffs and board specific stuffs efficiently.
How you think?

Thanks,
Minkyu Kang.



Actually I had something else on my mind but this is more simply, so I 
will change this back.


Thank you,
--
Przemyslaw Marczak
Samsung R&D Institute Poland
Samsung Electronics
p.marc...@samsung.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] board: delete meaningless serial.h

[Stefan Roese]

On 15.01.2014 10:00, Masahiro Yamada wrote:
> Delete some serial.h files, whole code in which is surrounded by
>   #if 0 ... #endif
> 
> Signed-off-by: Masahiro Yamada 

Thanks! Good catch!

Acked-by: Stefan Roese 

Thanks,
Stefan

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

Re: [U-Boot] Bug in TOP860 code with gcc 4.8.1

[Reinhard Meyer]

Hello Jeroen,

Hello Reinhard,

On 01/14/2014 12:33 PM, Reinhard Meyer wrote:

Dear Wolfgang,

Dear Reinhard,

attempting to build the TOP860 code with a GCC 4.8.1 based tool chain
(say ELDK v5.5 or Yocto 1.5) gives the following errors:

-> ./MAKEALL TOP860
Configuring for TOP860 board...
textdata bss dec hex filename
  165471   21020   17316  203807   31c1f ./u-boot
../common/flash.c: In function 'flash_init':
../common/flash.c:336:20: warning: iteration 128u invokes undefined 
behavior [-Waggressive-loop-optimizations]

  info->start[i] = (ulong)addr + 0x1 * i;
 ^
../common/flash.c:334:4: note: containing loop
 for (i = 0; i < info->sector_count; i++)
 ^
...

Can you please provide a fix - or is this old hardware and the code
should be removed from the U-Boot tree?
1. on first and second glance I cannot see where this (simple!!) loop 
might "invoke undefined behaviour". Seems like a compiler/optimizer 
bug to me...


2. should not the same issue arise with TOP5200 (using the same 
flash.c) ??


3. nevertheless TOP860 can be removed.


It is out of bounds:

include/configs/TOP860.h:#define CONFIG_SYS_MAX_FLASH_SECT128 /* 
max number of sectors on one chip*/
include/configs/TOP5200.h:#define CONFIG_SYS_MAX_FLASH_SECT 256 /* max 
num of sects on one chip */


Removing will work as well of course ;)

Regards,
Jeroen
I see. Because of the common code with TOP5200, there is potentially a 
larger flash chip available in the switch, which would cause undefined 
behaviour later. However TOP860 has never seen more than 2MB of flash :) 
so there is no actual danger.


For the next few weeks I do not have the capacity to provide a patch, 
and since the TOP860 U-Boot is frozen to a very old state by the 
customers anyway, it is save to be removed from the current tree.


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

[U-Boot] [PATCH 1/2] env_mmc: make board configurable the partition for the environment

[Hector Palacios]

This complements commit 9404a5fc7cb58 "env_mmc: allow environment to be
in an eMMC partition" by allowing boards to accommodate the partition
to use for the environment in different scenarios (similarly to what is
done with the mmc dev number). Depending on the detected boot media,
boards may decide to store the environment in a different partition.

The __weak function also allows to remove some ifdefs from the code.
If CONFIG_SYS_MMC_ENV_PART is not defined, partition 0 is assumed
(default value for U-Boot when a partition is not provided).

Signed-off-by: Hector Palacios 
CC: Stephen Warren 
CC: Andy Fleming 
---
 common/env_mmc.c | 27 +++
 1 file changed, 15 insertions(+), 12 deletions(-)

diff --git a/common/env_mmc.c b/common/env_mmc.c
index 78c2bc7a1f08..d569b070e005 100644
--- a/common/env_mmc.c
+++ b/common/env_mmc.c
@@ -64,6 +64,13 @@ __weak int mmc_get_env_addr(struct mmc *mmc, int copy, u32 
*env_addr)
 __weak int mmc_get_env_devno(void)
 {
return CONFIG_SYS_MMC_ENV_DEV;
+
+__weak int mmc_get_env_partno(void)
+{
+#ifdef CONFIG_SYS_MMC_ENV_PART
+   return CONFIG_SYS_MMC_ENV_PART;
+#endif
+   return 0;
 }
 
 int env_init(void)
@@ -77,6 +84,9 @@ int env_init(void)
 
 static int init_mmc_for_env(struct mmc *mmc)
 {
+   int mmc_env_devno = mmc_get_env_devno();
+   int mmc_env_partno = mmc_get_env_partno();
+
if (!mmc) {
puts("No MMC card found\n");
return -1;
@@ -87,30 +97,23 @@ static int init_mmc_for_env(struct mmc *mmc)
return -1;
}
 
-#ifdef CONFIG_SYS_MMC_ENV_PART
-   if (CONFIG_SYS_MMC_ENV_PART != mmc->part_num) {
-   int mmc_env_devno = mmc_get_env_devno();
-
-   if (mmc_switch_part(mmc_env_devno,
-   CONFIG_SYS_MMC_ENV_PART)) {
+   if (mmc_env_partno != mmc->part_num) {
+   if (mmc_switch_part(mmc_env_devno, mmc_env_partno)) {
puts("MMC partition switch failed\n");
return -1;
}
}
-#endif
 
return 0;
 }
 
 static void fini_mmc_for_env(struct mmc *mmc)
 {
-#ifdef CONFIG_SYS_MMC_ENV_PART
int mmc_env_devno = mmc_get_env_devno();
+   int mmc_env_partno = mmc_get_env_partno();
 
-   if (CONFIG_SYS_MMC_ENV_PART != mmc->part_num)
-   mmc_switch_part(mmc_env_devno,
-   mmc->part_num);
-#endif
+   if (mmc_env_partno != mmc->part_num)
+   mmc_switch_part(mmc_env_devno, mmc->part_num);
 }
 
 #ifdef CONFIG_CMD_SAVEENV
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 2/2] env_mmc: default to 0 if CONFIG_SYS_MMC_ENV_DEV not defined

[Hector Palacios]

Since function mmc_get_env_devno is __weak and can be overridden by
board code, boards do not necessarily need to define
CONFIG_SYS_MMC_ENV_DEV. If the constant is not defined, return 0 by
default.

Signed-off-by: Hector Palacios 
---
 common/env_mmc.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/common/env_mmc.c b/common/env_mmc.c
index d569b070e005..bd3bc1d50b15 100644
--- a/common/env_mmc.c
+++ b/common/env_mmc.c
@@ -63,7 +63,11 @@ __weak int mmc_get_env_addr(struct mmc *mmc, int copy, u32 
*env_addr)
 
 __weak int mmc_get_env_devno(void)
 {
+#ifdef CONFIG_SYS_MMC_ENV_DEV
return CONFIG_SYS_MMC_ENV_DEV;
+#endif
+   return 0;
+}
 
 __weak int mmc_get_env_partno(void)
 {
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2] PPC: remove support for MPC82xx processors

[Wolfgang Denk]

Dear Holger,

In message <52d64089.6070...@keymile.com> you wrote:
> 
> > This commit removes support for the Freescale MPC82xx Power
> > Architecture processors, i. e. MPC8240, MPC8245, MPC8247, MPC8248,
> > MPC8250, MPC8255, MPC8260, MPC8265, MPC8266, MPC8272, MPC8280, ...
> > 
> > They have been out of production for years, and no active users left
> > here.  As some boards start causing problems, let's drop the obsolete
> > and now dead code.
> 
> thats not valid for us. Our mgcoge3ne target which comes with a MPC8247 is 
> still
> in production and maintained. If you look at the git log of

Argh... Can you foresee how much longer this hardware is likely to be
maintained?

> So isn't it possible to remove only the broken boards and keep the generic 
> parts?

Yes, this would be possible, too.  But then, it appears you are the
only remaining active user of MPC82xx.  OK, MPC8247 is actually still
marked as "active" at Freescale, soory I missed that - the MPC824x
types I checked were in "No Longer Manufactured" state.

The thing is that there are tons of interdependencies an #defines that
need to be checked so we don't leave too many unused #defines and such
around.

I see several options now:

1) We apply the patch as is, and if you really have to modify your
   code you would do this out-of-tree based on the last frozen
   version.

2) I rework the patch to remove only the MPC826x / MPC828x code.

3) I rework the patch to remove only the broken boards - which are
   these actually?


Tom, what is your opinion here?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
>  Is there a way to determine Yesterday's date using Unix utilities?
 echo "what is yesterday's date?" | /bin/mail root
 -- Randal L. Schwartz in 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] env_mmc: make board configurable the partition for the environment

[Otavio Salvador]

Hello Hector,

On Wed, Jan 15, 2014 at 8:53 AM, Hector Palacios
wrote:

> This complements commit 9404a5fc7cb58 "env_mmc: allow environment to be
> in an eMMC partition" by allowing boards to accommodate the partition
> to use for the environment in different scenarios (similarly to what is
> done with the mmc dev number). Depending on the detected boot media,
> boards may decide to store the environment in a different partition.
>
> The __weak function also allows to remove some ifdefs from the code.
> If CONFIG_SYS_MMC_ENV_PART is not defined, partition 0 is assumed
> (default value for U-Boot when a partition is not provided).
>
> Signed-off-by: Hector Palacios 
> CC: Stephen Warren 
> CC: Andy Fleming 
> ---
>  common/env_mmc.c | 27 +++
>  1 file changed, 15 insertions(+), 12 deletions(-)
>
> diff --git a/common/env_mmc.c b/common/env_mmc.c
> index 78c2bc7a1f08..d569b070e005 100644
> --- a/common/env_mmc.c
> +++ b/common/env_mmc.c
> @@ -64,6 +64,13 @@ __weak int mmc_get_env_addr(struct mmc *mmc, int copy,
> u32 *env_addr)
>  __weak int mmc_get_env_devno(void)
>  {
> return CONFIG_SYS_MMC_ENV_DEV;
> +
> +__weak int mmc_get_env_partno(void)
> +{
> +#ifdef CONFIG_SYS_MMC_ENV_PART
> +   return CONFIG_SYS_MMC_ENV_PART;
> +#endif
> +   return 0;
>

Maybe:

#ifndef CONFIG_SYS_MMC_ENV_PART
#define CONFIG_SYS_MMC_ENV_PART 0
#endif

__weak int mmc_get_env_partno(void)
{
return CONFIG_SYS_MMC_ENV_PART;
}

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2] env_mmc: default to 0 if CONFIG_SYS_MMC_ENV_DEV not defined

[Otavio Salvador]

On Wed, Jan 15, 2014 at 8:53 AM, Hector Palacios
wrote:

> Since function mmc_get_env_devno is __weak and can be overridden by
> board code, boards do not necessarily need to define
> CONFIG_SYS_MMC_ENV_DEV. If the constant is not defined, return 0 by
> default.
>
> Signed-off-by: Hector Palacios 
>

Maybe use same default define, if not set?

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] doc/README.scrapyard: update commit IDs, use TAB for indentation

[Wolfgang Denk]

Dear Masahiro,

In message <20140115174127.e118.aa925...@jp.panasonic.com> you wrote:
> 
> Why did you insert TABs here?

Because it requires less typing when adding new entries.

> You are using TABs and SPACEs mixed-up.

Correct.  I decided to go for a minimal-invasive change that would not
result in some very long lines.  So most columns are aligned by TAG,
and two of them by TAB + 4 x SPACE.

> If you do this refactoring, I'd like to request that only TABs are used
> consistently.

I can do this - but then, this will result in very long lines.  Do you
prefer that?

> And another thing , this series can not applied on the current
> u-boot/master.

The patches are against v2014.01-rc3 ; rebasing against current top of
tree is trivial as only the two new entries for mx1ads and mini2440
need fixing.  I can fix this, but let's ait until we see what happens
with the actual 82xx removal patch.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Die meisten Menschen pflegen im Kindesalter vom Zeigen auf Gegenstän-
de (Mausbewegung) und "ga" sagen  (Mausklick)  abzukommen,  zugunsten
eines  mächtigeren  und langwierig zu erlernenden Tools (Sprache).
 -- Achim Linder in de.comp.os.linux.misc
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] board_r - fixup functions table after relocation

[Alexey Brodkin]

"init_sequence_r" is just an array that consists of compile-time
adresses of init functions. Since this is basically an array of integers
(pointers to "void" to be more precise) it won't be modified during
relocation - it will be just copied to new location as it is.

As a consequence on execution after relocation "initcall_run_list" will
be jumping to pre-relocation addresses. As long as we don't overwrite
pre-relocation memory area init calls are executed correctly. But still
it is dangerous because after relocation we don't expect initially used
memory to stay untouched.

Signed-off-by: Alexey Brodkin 

Cc: Tom Rini 
Cc: Simon Glass 
Cc: Masahiro Yamada 
Cc: Doug Anderson 
---
 common/board_r.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/common/board_r.c b/common/board_r.c
index 86ca1cb..8f45943 100644
--- a/common/board_r.c
+++ b/common/board_r.c
@@ -903,9 +903,14 @@ init_fnc_t init_sequence_r[] = {
 
 void board_init_r(gd_t *new_gd, ulong dest_addr)
 {
+   int i;
 #ifndef CONFIG_X86
gd = new_gd;
 #endif
+   /* Fixup table after relocation */
+   for (i = 0; i < sizeof(init_sequence_r)/sizeof(void *); i++)
+   init_sequence_r[i] += gd->reloc_off;
+
if (initcall_run_list(init_sequence_r))
hang();
 
-- 
1.8.4.2

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

Re: [U-Boot] Fat write problem

[Ruud Commandeur]

Hello again,

This week I decided to do some further research and testing regarding
this problem.
With the image I had from the previous time, I could immediately
reproduce it and
by adding more and more debug prints, I tried to find the cause. Sofar,
I have not
succeeded in this yet.

However: later on I started testing with a freshly formatted drive (32
MB FAT partition)
and kept repeating the fatwrite command:

fatwrite mmc 0:1 4200 test-x 200

where x runs from 1, 2,3 and further. And this way I could reproduce it
quite easily.
Writing always fails for the 32nd file. This is with the partition
formatted with a 512 byte
sector size and a cluster size of 4. If the cluster size is 1 (formatted
by Windows),
it already fails at the 8th file.

If I create a subdirectory (from Linux) with already 24 files in it, I
can still write 29 files
and it fails at number 30. Also, if earlier files were deleted from the
root-directory, they
still count in the total number of files here.

If I take out the card where u-boot fails to write new files, I can
still add new files from
my PC with Linux or Windows.

I tested with both long and short filenames (same result), VFAT is
enabled.

I hope this gives you all some more information about this problem and
perhaps it is even a
known problem (limited number of files in the root directory?). I know
it is voor FAT16, but
that was 512 entries if I am correct.

Regards,

Ruud


> -Oorspronkelijk bericht-
> Van: Ruud Commandeur 
> Verzonden: woensdag 23 oktober 2013 17:18
> Aan: U-Boot list
> Onderwerp: Fat write problem
> 
> Hi Everyone,
> 
> After about half a year without problems for fatwrite, I have 
> some new problem.
> The fatwrites for the u-boot are used to write the uimage and 
> dtb file to a 32
> MB FAT16 partition on an SD-card. Since this morning, the 
> writing of a new file
> keeps failing. I still can write files that are already present.
> But if try and write some file with a name that doe not exist 
> yet, it fails. I guess
> this just hasn't been tested for a while, since these 
> filenames don't change.
> Meanwhile some extra files have been copied to the partition 
> from the Linux
> platform. I did check the SD-card partition with fsck and 
> could not find any
> problems.
> 
> I did enable the debug for MMC and FAT to get the following output:
> 
> fatwrite mmc 0:1 4200 test-file 200
> writing test-file
> MMC0: CMD16
> MMC0: CMD17
> MMC0: CMD16
> MMC0: CMD18
> MMC0: CMD12
> get_dentfromdir: test-file
> gc - clustnum: -6, startsect: 132
> MMC0: CMD16
> MMC0: CMD18
> MMC0: CMD12
> vfatname: |uimage|
> Mismatch: |uimage|uimage|
> vfatname: |imx28-evk.dtb|
> Mismatch: |imx28-~1.dtb|imx28-evk.dtb|
> vfatname: |linux-file1.txt|
> Mismatch: |linux-~1.txt|linux-file1.txt|
> Mismatch: |address.ini||
> vfatname: |imx28-clb.dtb|
> Mismatch: |imx28-~2.dtb|imx28-clb.dtb|
> vfatname: |img-copy|
> Mismatch: |img-copy|img-copy|
> vfatname: |tessie|
> Mismatch: |tessie|tessie|
> vfatname: |img-copy2|
> Mismatch: |img-co~1|img-copy2|
> vfatname: |imx-28-clb-37.dtb|
> Mismatch: |imx-28~1.dtb|imx-28-clb-37.dtb|
> vfatname: |hello8000.wav|
> Mismatch: |hello8~1.wav|hello8000.wav|
> vfatname: |versions.ini|
> Mismatch: |versions.ini|versions.ini|
> vfatname: |mx28-310.dtb|
> Mismatch: |mx28-310.dtb|mx28-310.dtb|
> FAT16: entry: 0xfffa = -6, offset: 0x03fa = 1018
> MMC: block number 0x1000806 exceeds max(0x762c00)
> FAT16: ret: , entry: fffa, offset: 03fa
> curclust: 0x0
> Invalid FAT entry
> name.ext : .
> FAT16: entry: 0x0003 = 3, offset: 0x0003 = 3
> error: overflow occurs
> error: writing FAT blocks
> FAT16: entry: 0x0004 = 4, offset: 0x0004 = 4
> error: overflow occurs
> error: writing FAT blocks
> FAT16: entry: 0x0005 = 5, offset: 0x0005 = 5
> error: overflow occurs
> error: writing FAT blocks
> FAT16: entry: 0x0006 = 6, offset: 0x0006 = 6
> ... and this goes on for a long long time...
> 
> It points to get_fatent_value( ) where things go wrong. Or 
> perhaps the call of
> this function with the value 0xfffa (-6). I don't know if 
> that is supposed
> to be possible?
> 
> At the moment I am a bit stuck here, so if anyone would have 
> an idea what
> goes wrong here, please let me know.
> 
> Thanks,
> 
> Ruud
> 
> N.B. It might be that this can be solved by clearing the FAT 
> partition and starting
> with a clean sheet. But I prefer not to lose this error 
> situaion before I know
> what goes wrong here.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] how to get u-boot code with arm64: core support

[Abraham Varricatt]

On Wed, Jan 15, 2014 at 12:07 PM, Wolfgang Denk  wrote:
> Dear tiger...@viatech.com.cn,
>
> In message  
> you wrote:
>>
>> CROSS_COMPILE=/home/lion/ARMv8/gcc-linaro-aarch64/bin/aarch64-linux-gnu-
>
> Side note:
>
> It is always wrong to use an absolute path name for CROSS_COMPILE.
> You should use "CROSS_COMPILE=aarch64-linux-gnu-" and make sure your
> PATH is set correctly.

Actually, I also give the full path name when defining CROSS_COMPILER
variable. This is because I find myself juggling between different
compilers, located in different locations for the same build (personal
experimentation). Is there some dependency on the PATH variable that
I'm missing? Or is this just convention?

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

Re: [U-Boot] [PATCH] board_r - fixup functions table after relocation

[thomas.langer]

Hello Alexey,

Alexey Brodkin wrote on 2014-01-15:
> "init_sequence_r" is just an array that consists of compile-time
> adresses of init functions. Since this is basically an array of integers
> (pointers to "void" to be more precise) it won't be modified during
> relocation - it will be just copied to new location as it is.
> 
> As a consequence on execution after relocation "initcall_run_list" will
> be jumping to pre-relocation addresses. As long as we don't overwrite
> pre-relocation memory area init calls are executed correctly. But still
> it is dangerous because after relocation we don't expect initially used
> memory to stay untouched.
> 
> Signed-off-by: Alexey Brodkin 
> 
> Cc: Tom Rini 
> Cc: Simon Glass 
> Cc: Masahiro Yamada 
> Cc: Doug Anderson 
> ---
>  common/board_r.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/common/board_r.c b/common/board_r.c
> index 86ca1cb..8f45943 100644
> --- a/common/board_r.c
> +++ b/common/board_r.c
> @@ -903,9 +903,14 @@ init_fnc_t init_sequence_r[] = {
> 
>  void board_init_r(gd_t *new_gd, ulong dest_addr)
>  {
> + int i;
>  #ifndef CONFIG_X86
>   gd = new_gd;
>  #endif
> + /* Fixup table after relocation */
> + for (i = 0; i < sizeof(init_sequence_r)/sizeof(void *); i++)
> + init_sequence_r[i] += gd->reloc_off;
> +

I think this is only required/possible for architectures which define
CONFIG_NEEDS_MANUAL_RELOC, others don't have "gd->reloc_off"

>   if (initcall_run_list(init_sequence_r))
>   hang();
> 

Best Regards,
Thomas
---
There are two hard things in computer science: cache invalidation, naming 
things, and off-by-one errors.
---

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

Re: [U-Boot] [PATCH 2/2] PPC: remove support for MPC82xx processors

[Holger Brunck]

Hello Wolfgang,

On 01/15/2014 12:04 PM, Wolfgang Denk wrote:
> Dear Holger,
> 
> In message <52d64089.6070...@keymile.com> you wrote:
>>
>>> This commit removes support for the Freescale MPC82xx Power
>>> Architecture processors, i. e. MPC8240, MPC8245, MPC8247, MPC8248,
>>> MPC8250, MPC8255, MPC8260, MPC8265, MPC8266, MPC8272, MPC8280, ...
>>>
>>> They have been out of production for years, and no active users left
>>> here.  As some boards start causing problems, let's drop the obsolete
>>> and now dead code.
>>
>> thats not valid for us. Our mgcoge3ne target which comes with a MPC8247 is 
>> still
>> in production and maintained. If you look at the git log of
> 
> Argh... Can you foresee how much longer this hardware is likely to be
> maintained?
> 

uhm. There is currently no plan to stop the production of this board. So for the
next two years at least I would expect that they were still produced.

And as a sidenode I still have the request on my desk to integrate the POST
tests for this board, which we already have for our PPC83xx and kirkwood boards.

>> So isn't it possible to remove only the broken boards and keep the generic 
>> parts?
> 
> Yes, this would be possible, too.  But then, it appears you are the
> only remaining active user of MPC82xx.  OK, MPC8247 is actually still
> marked as "active" at Freescale, soory I missed that - the MPC824x
> types I checked were in "No Longer Manufactured" state.
> 
> The thing is that there are tons of interdependencies an #defines that
> need to be checked so we don't leave too many unused #defines and such
> around.
> 

yes I understand the desire to remove as much as unneeded code as possible.

> I see several options now:
> 
> 1) We apply the patch as is, and if you really have to modify your
>code you would do this out-of-tree based on the last frozen
>version.
> 

yes we could do that and keep a seperate branch for this board, but I don't like
this. I guess I don't need to explain why I would like to avoid an additional
branch on our site.

> 2) I rework the patch to remove only the MPC826x / MPC828x code.
> 

honestly this would be my favorite approach.

So if keeping 82xx support would't generate to much overload for u-boot I would
appreciate to keep it. But if it interferes with future u-boot development we
could also move it to a keymile specific branch.

And just out of curiosity. Why do you keep still 8xx board support? Is this more
in use then 82xx? This is suprising to me.

Regards
Holger

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

Re: [U-Boot] how to get u-boot code with arm64: core support

[Wolfgang Denk]

Dear Abraham,

In message  
you wrote:
>
> > It is always wrong to use an absolute path name for CROSS_COMPILE.
> > You should use "CROSS_COMPILE=aarch64-linux-gnu-" and make sure your
> > PATH is set correctly.
> 
> Actually, I also give the full path name when defining CROSS_COMPILER

Then you are also doing it incorrectly. Don't worry, you are not
alone ;-)

> variable. This is because I find myself juggling between different
> compilers, located in different locations for the same build (personal
> experimentation). Is there some dependency on the PATH variable that
> I'm missing? Or is this just convention?

Using a full path name is bad style, and there is actually no
guarantee that it will work correctly.


If you are dealing with multiple tool chains you should always set up
your PATH correctly; there are scripts available that will help doing
that for you (like "eldk-switch" [1] for our ELDK).

[1] http://www.denx.de/wiki/view/ELDK-5/WebHome#Section_1.8.3.

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
"Well I don't see why I have to make one man  miserable  when  I  can
make so many men happy."  - Ellyn Mustard, about marriage
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2] PPC: remove support for MPC82xx processors

[Wolfgang Denk]

Dear Holger,

In message <52d67c60.2040...@keymile.com> you wrote:
> 
> > 1) We apply the patch as is, and if you really have to modify your
> >code you would do this out-of-tree based on the last frozen
> >version.
> > 
> 
> yes we could do that and keep a seperate branch for this board, but I don't 
> like
> this. I guess I don't need to explain why I would like to avoid an additional
> branch on our site.

Fully understood.  If you can foresee another two years of active use
this is a perfectly valid reason not to remove this file.   Sorry I
missed this in the beginning...

> > 2) I rework the patch to remove only the MPC826x / MPC828x code.
> 
> honestly this would be my favorite approach.

Tom - how much time is there left for me to do that?

> So if keeping 82xx support would't generate to much overload for u-boot I 
> would
> appreciate to keep it. But if it interferes with future u-boot development we
> could also move it to a keymile specific branch.

Do you agree with "keeping 824x" support only?

> And just out of curiosity. Why do you keep still 8xx board support? Is this 
> more
> in use then 82xx? This is suprising to me.

You are asking a heretical question! ;-)

8xx is where it all started - U-Boot was anteceded by the PPCBoot
project, which started as 8xxrom - some 15 years ago...  Ripping this
out of U-Boot would just break my heart...

Seriously, when the 8xx code is starting to make similar problems like
82xx is doing now, we will probably come to the same conclusions
(allthough my heart would be bleeding) but so far everything is fine -
individual boards breakage (like TOP860 with gcc 4.8) excluded.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Don't put off for tomorrow what you can  do  today,  because  if  you
enjoy it today you can do it again tomorrow.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] board_r - fixup functions table after relocation

[Alexey Brodkin]

On Wed, 2014-01-15 at 11:27 +, thomas.lan...@lantiq.com wrote:
> I think this is only required/possible for architectures which define
> CONFIG_NEEDS_MANUAL_RELOC, others don't have "gd->reloc_off"
> 
> > if (initcall_run_list(init_sequence_r))
> > hang();

Hi Thomas,

I think it's a generic item for all boards that use "common/board_r.c"
and "common/board_f.c". I.e. have CONFIG_BOARD_EARLY_INIT_F and
CONFIG_BOARD_EARLY_INIT_R defined.

I see that in "common/board_f.c" it is used for example in
"setup_reloc()" and this function is executed regardless platform.

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

Re: [U-Boot] [PATCH 2/2] PPC: remove support for MPC82xx processors

[Tom Rini]

On Wed, Jan 15, 2014 at 12:04:10PM +0100, Wolfgang Denk wrote:
> Dear Holger,
> 
> In message <52d64089.6070...@keymile.com> you wrote:
> > 
> > > This commit removes support for the Freescale MPC82xx Power
> > > Architecture processors, i. e. MPC8240, MPC8245, MPC8247, MPC8248,
> > > MPC8250, MPC8255, MPC8260, MPC8265, MPC8266, MPC8272, MPC8280, ...
> > > 
> > > They have been out of production for years, and no active users left
> > > here.  As some boards start causing problems, let's drop the obsolete
> > > and now dead code.
> > 
> > thats not valid for us. Our mgcoge3ne target which comes with a MPC8247 is 
> > still
> > in production and maintained. If you look at the git log of
> 
> Argh... Can you foresee how much longer this hardware is likely to be
> maintained?
> 
> > So isn't it possible to remove only the broken boards and keep the generic 
> > parts?
> 
> Yes, this would be possible, too.  But then, it appears you are the
> only remaining active user of MPC82xx.  OK, MPC8247 is actually still
> marked as "active" at Freescale, soory I missed that - the MPC824x
> types I checked were in "No Longer Manufactured" state.
> 
> The thing is that there are tons of interdependencies an #defines that
> need to be checked so we don't leave too many unused #defines and such
> around.
> 
> I see several options now:
> 
> 1) We apply the patch as is, and if you really have to modify your
>code you would do this out-of-tree based on the last frozen
>version.
> 
> 2) I rework the patch to remove only the MPC826x / MPC828x code.
> 
> 3) I rework the patch to remove only the broken boards - which are
>these actually?
> 
> 
> Tom, what is your opinion here?

For this release, lets go with #3, which is already done (York grabbed
the patch to drop linkstation_HGLAN and that was the only FTB) and then
for the next release we can do #2 if there's no objections.

-- 
Tom


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

Re: [U-Boot] [PATCH] board_r - fixup functions table after relocation

[thomas.langer]

Alexey Brodkin wrote on 2014-01-15:
> On Wed, 2014-01-15 at 11:27 +, thomas.lan...@lantiq.com wrote:
>> I think this is only required/possible for architectures which define
>> CONFIG_NEEDS_MANUAL_RELOC, others don't have "gd->reloc_off"
>> 
>>> if (initcall_run_list(init_sequence_r))
>>> hang();
> 
> Hi Thomas,
> 
> I think it's a generic item for all boards that use "common/board_r.c"
> and "common/board_f.c". I.e. have CONFIG_BOARD_EARLY_INIT_F and
> CONFIG_BOARD_EARLY_INIT_R defined.
> 
> I see that in "common/board_f.c" it is used for example in
> "setup_reloc()" and this function is executed regardless platform.
> 
Hello Alexey,

it seems that CONFIG_SYS_GENERIC_BOARD is not used by any architecture
without CONFIG_NEEDS_MANUAL_RELOC, so your patch is okay.

Sorry for the noise.

> Regards,
> Alexey

Best Regards,
Thomas
---
There are two hard things in computer science: cache invalidation, naming 
things, and off-by-one errors.
---


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

Re: [U-Boot] [PATCH 2/2] PPC: remove support for MPC82xx processors

[Joakim Tjernlund]

> 
> You are asking a heretical question! ;-)
> 
> 8xx is where it all started - U-Boot was anteceded by the PPCBoot
> project, which started as 8xxrom - some 15 years ago...  Ripping this
> out of U-Boot would just break my heart...

hear,hear :) We started 14 years ago with 8xx and PPCBoot.
8xx have a special place in my heart too.

> 
> Seriously, when the 8xx code is starting to make similar problems like
> 82xx is doing now, we will probably come to the same conclusions
> (allthough my heart would be bleeding) but so far everything is fine -
> individual boards breakage (like TOP860 with gcc 4.8) excluded.
> 
> Best regards,
> 
> Wolfgang Denk
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] sf: Squash the malloc+memset combo

[Marek Vasut]

Squash the malloc()+memset() combo in favor of calloc().

Signed-off-by: Marek Vasut 
Cc: Jagannadha Sutradharudu Teki 
---
 drivers/mtd/spi/sf_probe.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

NOTE: compile-tested only.

diff --git a/drivers/mtd/spi/sf_probe.c b/drivers/mtd/spi/sf_probe.c
index bc3cf6c..e84ab13 100644
--- a/drivers/mtd/spi/sf_probe.c
+++ b/drivers/mtd/spi/sf_probe.c
@@ -123,12 +123,11 @@ static struct spi_flash *spi_flash_validate_params(struct 
spi_slave *spi,
return NULL;
}
 
-   flash = malloc(sizeof(*flash));
+   flash = calloc(1, sizeof(*flash));
if (!flash) {
debug("SF: Failed to allocate spi_flash\n");
return NULL;
}
-   memset(flash, '\0', sizeof(*flash));
 
/* Assign spi data */
flash->spi = spi;
-- 
1.8.5.2

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

Re: [U-Boot] [PATCH 2/2] PPC: remove support for MPC82xx processors

[Pantelis Antoniou]

/me sniffs

High five...

On Jan 15, 2014, at 3:55 PM, Joakim Tjernlund wrote:

>> 
>> You are asking a heretical question! ;-)
>> 
>> 8xx is where it all started - U-Boot was anteceded by the PPCBoot
>> project, which started as 8xxrom - some 15 years ago...  Ripping this
>> out of U-Boot would just break my heart...
> 
> hear,hear :) We started 14 years ago with 8xx and PPCBoot.
> 8xx have a special place in my heart too.
> 
>> 
>> Seriously, when the 8xx code is starting to make similar problems like
>> 82xx is doing now, we will probably come to the same conclusions
>> (allthough my heart would be bleeding) but so far everything is fine -
>> individual boards breakage (like TOP860 with gcc 4.8) excluded.
>> 
>> Best regards,
>> 
>> Wolfgang Denk
> ___
> 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] arm64 patch: gicv3 support

[bhupesh.sha...@freescale.com]

Hi David,

Thanks for the patch.
Please see some comments inline:

> -Original Message-
> From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de]
> On Behalf Of feng...@phytium.com.cn
> Sent: Wednesday, January 15, 2014 1:41 PM
> To: u-boot@lists.denx.de
> Cc: tr...@ti.com
> Subject: [U-Boot] [PATCH] arm64 patch: gicv3 support
> 
> From: David Feng 
> 
> This patch add gicv3 support to uboot armv8 platform.
> Modifications cover 4 source files, as follows:
>   gic.S: gicv3 initialization and sgi interrupt raising.
>   goc.h: gicv3 register definitions.

^^^
Typo - gic.h

>   vexpress_aemv8a.h: add CONFIG_GICV2/CONFIG_GICV3 switch.
>   start.S: set SCR_EL3.NS bit to 1, gicv3 register of ICC_SRE_EL2
>could be accessed only when SCR_EL3.NS=1.
>set SCR_EL3.IRQ|FIQ|EA bits, reroute all interrupts to
>el3 at all cores, slaves could be waken up by interrupt
>only when the interrupt is routed to it when running
>at el3.

Hmmm. This seems a bit suspicious - if we reroute even IRQs and Aborts
to the cores which work in EL3, they will not be visible to Linux or
Hypervisor which work in EL2 or EL1.

Have you tried to launch linux on the ARMv8 foundation model v2 with these 
changes?

> Note: please use the latest gcc 4.8 compiler from linaro
>   which support gicv3 system register assembling.
>

Two generic comments :

- I see in the Foundation model README that the optional GICv3 is supported
with memory-mapped CPU interface and distributor, but I see your patch 
accessing them
via the sytem register interface (via msr and mrs). Is this a BUG in the README?

Did you check this patch on the latest ARMv8 foundation model - v2?

- Also how about sharing the GICv2 coding between ARMv7 and ARMv8 - some of the 
code
may seems like a duplication from the ARMv7 GICv2 content.
 
> Signed-off-by: David Feng 
> ---
>  arch/arm/cpu/armv8/gic.S  |   84
> -
>  arch/arm/cpu/armv8/start.S|5 ++-
>  arch/arm/include/asm/gic.h|   56 +
>  include/configs/vexpress_aemv8a.h |7 
>  4 files changed, 150 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/cpu/armv8/gic.S b/arch/arm/cpu/armv8/gic.S index
> 599aa8f..a08939a 100644
> --- a/arch/arm/cpu/armv8/gic.S
> +++ b/arch/arm/cpu/armv8/gic.S
> @@ -23,6 +23,74 @@
>   *
> 
> *
> /
>  WEAK(gic_init)
> +#if defined(CONFIG_GICV3)
> + branch_if_slave x0, 3f
> +
> + /* Initialize Distributor */
> + ldr x1, =GICD_BASE
> + mov w0, #0x37   /* EnableGrp0 | EnableGrp1NS */
> + /* EnableGrp1S | ARE_S | ARE_NS */
> + str w0, [x1, GICD_CTLR] /* Secure GICD_CTLR */
> + ldr w0, [x1, GICD_TYPER]
> + and w2, w0, #0x1f   /* ITLinesNumber */
> + cbz w2, 1f  /* No SPIs */
> + add x3, x1, (GICD_IGROUPRn + 4)
> + add x4, x1, (GICD_IGROUPMODRn + 4)
> + mov w5, #~0
> +0:   str w5, [x3], #0x4
> + str wzr, [x4], #0x4 /* Config SPIs as Group1NS */
> + sub w2, w2, #0x1
> + cbnzw2, 0b
> +
> + /* Initialize All ReDistributors */
> +1:   ldr x1, =GICR_BASE
> +2:   mov w0, #~0x2
> + ldr w2, [x1, GICR_WAKER]
> + and w2, w2, w0  /* Clear ProcessorSleep */
> + str w2, [x1, GICR_WAKER]
> + dsb st
> + isb
> +0:   ldr w0, [x1, GICR_WAKER]
> + tbnzw0, #2, 0b  /* Wait Children be Alive */
> +
> + add x2, x1, #(1 << 16)  /* SGI_Base */
> + mov w5, #~0
> + str w5, [x2, GICR_IGROUPRn]
> + str wzr, [x2, GICR_IGROUPMODRn] /* SGIs|PPIs Group1NS */
> + mov w0, #0x1/* Enable SGI 0 */
> + str w0, [x2, GICR_ISENABLERn]
> +
> + ldr w0, [x1, GICR_TYPER]
> + add x1, x1, #(2 << 16)
> + tbz w0, #4, 2b  /* Next ReDistributor if Exist */
> +
> + /* Initialize Cpu Interface */
> +3:   mrs x0, ICC_SRE_EL3
> + orr x0, x0, #0xf/* SRE & Disable IRQ/FIQ Bypass & */
> + /* Allow EL2 access to ICC_SRE_EL2 */
> + msr ICC_SRE_EL3, x0
> + isb
> +
> + mrs x0, ICC_SRE_EL2
> + orr x0, x0, #0xf/* SRE & Disable IRQ/FIQ Bypass & */
> + /* Allow EL1 access to ICC_SRE_EL1 */
> + msr ICC_SRE_EL2, x0
> + isb
> +
> + mov x0, #0x3/* EnableGrp1NS | EnableGrp1S */
> + msr ICC_IGRPEN1_EL3, x0
> + isb
> +
> + msr ICC_CTLR_EL3, xzr
> + isb
> +
> + msr ICC_CTLR_EL1, xzr   /* NonSecure ICC_CTLR_EL1 */
> + isb
> +
> + mov x0, #0x1 << 7   /* Non-Secure access to ICC_PMR_EL1
> */
> + msr ICC_PMR_EL1, x0

[U-Boot] [PATCH] sf: Fix entries for S25FL256S_256K and S25FL512S_256K

[Marek Vasut]

Both of these chips have 256kB big sectors, thus the _256K suffix,
compared to their _64K counterparts, which have 64kB sectors. Also,
they have four times less sectors than their _64K counterparts.

Signed-off-by: Marek Vasut 
Cc: Jagannadha Sutradharudu Teki 
---
 drivers/mtd/spi/sf_params.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

Note: Would be nice if someone actually tested this fix as I go by the
  datasheet and by the old code that _was_ in U-Boot before the rework.

diff --git a/drivers/mtd/spi/sf_params.c b/drivers/mtd/spi/sf_params.c
index daf8fe7..5f63023 100644
--- a/drivers/mtd/spi/sf_params.c
+++ b/drivers/mtd/spi/sf_params.c
@@ -55,9 +55,9 @@ const struct spi_flash_params spi_flash_params_table[] = {
{"S25FL032P",  0x010215, 0x4d00,64 * 1024,64, RD_FULL,  
 WR_QPP},
{"S25FL064P",  0x010216, 0x4d00,64 * 1024,   128, RD_FULL,  
 WR_QPP},
{"S25FL128S_64K",  0x012018, 0x4d01,64 * 1024,   256, RD_FULL,  
 WR_QPP},
-   {"S25FL256S_256K", 0x010219, 0x4d00,64 * 1024,   512, RD_FULL,  
 WR_QPP},
+   {"S25FL256S_256K", 0x010219, 0x4d00,   256 * 1024,   128, RD_FULL,  
 WR_QPP},
{"S25FL256S_64K",  0x010219, 0x4d01,64 * 1024,   512, RD_FULL,  
 WR_QPP},
-   {"S25FL512S_256K", 0x010220, 0x4d00,64 * 1024,  1024, RD_FULL,  
 WR_QPP},
+   {"S25FL512S_256K", 0x010220, 0x4d00,   256 * 1024,   256, RD_FULL,  
 WR_QPP},
{"S25FL512S_64K",  0x010220, 0x4d01,64 * 1024,  1024, RD_FULL,  
 WR_QPP},
 #endif
 #ifdef CONFIG_SPI_FLASH_STMICRO/* STMICRO */
-- 
1.8.5.2

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

[U-Boot] [PATCH] sf: Add S25FL128S_256K IDs

[Marek Vasut]

Add IDs for this new chip.

Signed-off-by: Marek Vasut 
Cc: Jagannadha Sutradharudu Teki 
---
 drivers/mtd/spi/sf_params.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/mtd/spi/sf_params.c b/drivers/mtd/spi/sf_params.c
index 5f63023..eb372b7 100644
--- a/drivers/mtd/spi/sf_params.c
+++ b/drivers/mtd/spi/sf_params.c
@@ -54,6 +54,7 @@ const struct spi_flash_params spi_flash_params_table[] = {
{"S25FL128P_64K",  0x012018, 0x0301,64 * 1024,   256, RD_FULL,  
 WR_QPP},
{"S25FL032P",  0x010215, 0x4d00,64 * 1024,64, RD_FULL,  
 WR_QPP},
{"S25FL064P",  0x010216, 0x4d00,64 * 1024,   128, RD_FULL,  
 WR_QPP},
+   {"S25FL128S_256K", 0x012018, 0x4d00,   256 * 1024,64, RD_FULL,  
 WR_QPP},
{"S25FL128S_64K",  0x012018, 0x4d01,64 * 1024,   256, RD_FULL,  
 WR_QPP},
{"S25FL256S_256K", 0x010219, 0x4d00,   256 * 1024,   128, RD_FULL,  
 WR_QPP},
{"S25FL256S_64K",  0x010219, 0x4d01,64 * 1024,   512, RD_FULL,  
 WR_QPP},
-- 
1.8.5.2

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

Re: [U-Boot] [PATCH] sf: Fix entries for S25FL256S_256K and S25FL512S_256K

[Marek Vasut]

On Wednesday, January 15, 2014 at 03:29:43 PM, Marek Vasut wrote:
> Both of these chips have 256kB big sectors, thus the _256K suffix,
> compared to their _64K counterparts, which have 64kB sectors. Also,
> they have four times less sectors than their _64K counterparts.
> 
> Signed-off-by: Marek Vasut 
> Cc: Jagannadha Sutradharudu Teki 
> ---
>  drivers/mtd/spi/sf_params.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> Note: Would be nice if someone actually tested this fix as I go by the
>   datasheet and by the old code that _was_ in U-Boot before the rework.

btw. would be nice to get this one into current release to prevent it being 
broken. But I would _really_ appreciate some real-hardware testing here.

> diff --git a/drivers/mtd/spi/sf_params.c b/drivers/mtd/spi/sf_params.c
> index daf8fe7..5f63023 100644
> --- a/drivers/mtd/spi/sf_params.c
> +++ b/drivers/mtd/spi/sf_params.c
> @@ -55,9 +55,9 @@ const struct spi_flash_params spi_flash_params_table[] =
> { {"S25FL032P",  0x010215, 0x4d00,64 * 1024,64, RD_FULL,  

> WR_QPP}, {"S25FL064P",   0x010216, 0x4d00,64 * 1024,   128,
> RD_FULL,   WR_QPP}, {"S25FL128S_64K",  0x012018, 0x4d01,
> 64 
* 1024,
>   256, RD_FULL,WR_QPP}, - {"S25FL256S_256K", 0x010219, 
0x4d00,   
> 64 * 1024,   512, RD_FULL, WR_QPP}, + {"S25FL256S_256K", 
0x010219,
> 0x4d00,   256 * 1024,   128, RD_FULL,  WR_QPP}, {"S25FL256S_64K", 
> 0x010219, 0x4d01, 64 * 1024,   512, RD_FULL,   WR_QPP},
> - {"S25FL512S_256K", 0x010220, 0x4d00,64 * 1024,  1024, RD_FULL,  

> WR_QPP}, +{"S25FL512S_256K", 0x010220, 0x4d00,   256 * 1024,   256,
> RD_FULL,   WR_QPP}, {"S25FL512S_64K",  0x010220, 0x4d01,
> 64 
* 1024,
>  1024, RD_FULL,WR_QPP}, #endif
>  #ifdef CONFIG_SPI_FLASH_STMICRO  /* STMICRO */

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

Re: [U-Boot] Compiling fw_printenv tool

[Gerhard Sittig]

On Tue, Jan 14, 2014 at 20:47 +0900, Masahiro Yamada wrote:
> 
> Hello Detlev
> 
> 
> > > How do I cross compile it for my embedded system? Do I just set the
> > > HOSTCC environment variable in the Makefile?
> > 
> > No changes in any makefiles are needed, just do
> > 
> > make HOSTCC=arm-none-linuex-gnueabi-gcc env
> 
> It looks weird to me.
> 
> I think HOSTCC should be always "gcc".
> 
> In my understanding,  tools/env/fw_printenv is not a host program
> but a one for the target embedded Linux.

Here is my interpretation (keep in mind that I'm not an authority
on the matter, it's just what I get from looking at the Makefile
and README, and seeing how fw_printenv(1) was used in external
projects).


You may either adjust the builtin environment in the source code
(in the board specific config file).  This is rather inflexible,
pollutes the source with stuff that may be individual to one
specific site instead of the general use of the board, results in
binaries which apply those settings to wherever they run, and is
frowned upon.  Patches of this style outright get rejected these
days.

You may create a default U-Boot executable, start it on a target
(with its builtin environment), get a prompt, interactively
inspect and modify the environment, save it and then grab the
resulting binary image of the environment by arbitrary means, and
transport the binary image back to your development machine for
further deployment.  This is tedious, and requires access to a
target which may not be available at build time.  If you have the
hardware, you may lack ways to control the interactive session.

You may re-invent the wheel, and create a custom tool which runs
on your build machine and duplicates lots of U-Boot's internal
logic to interpret and manipulate the environment and its binary
presentation on media.  This is quite an effort and keeps causing
trouble and maintenance issues.


Then there is the tools/env/ directory which comes with the
U-Boot source.  It knows how to deal with the environment (the
interpretation and manipulation of the data), knows how to
process and update the binary image of the environment, including
often forgotten aspects like redundancy and padding and
endianess(?), and comes with ready instructions to build the tool
from source.

Looking from this perspective, the fw_printenv(1) tool really is
a host tool to get used at build time on your build machine, and
allows the creation and inspection of binary environment images
which you can ship with the U-Boot executable or with mere dumps
that are flashable images, without the need for access to a
target machine or a prompt therein.  The Makefile reflects this
approach, and uses HOSTCC (and other host related settings).

It's a nice byproduct that you can override HOSTCC (and
HOSTSTRIP) and easily receive an fw_printenv(1) tool that can run
on the target as well.  But this is not the primary use.
Depending on your audience/customers, you don't want to suggest
to them that the boot loader's configuration can get tweaked.
And you probably don't want to unconditionally provide the
command line tool to carry out the manipulation.  It's already
bad enough (from the support POV) that the tool is on disk in the
product.  Having "interested" users brick their product is no
fun, and telling them to not fiddle with internals is hard.
Still you may want to have that tool for remote diagnostics, or
to evaluate U-Boot settings at boot time, or to adjust boot
configurations from within a running Linux yet wrap this
manipulation in tested tools that always create working
combinations and refuse to break stuff.


I can't tell how many developers prefer mkimage(1) and scripts
over pre-built binary environment images.  Mind though that
running those scripts which may manipulate the environment still
depend on target access, and involve the task of getting back the
target's binary env image to the development machine.

Other approaches to environment manipulation or deployment could
have made the fw_printenv(1) tool obsolete or less desirable,
too.  But I haven't followed these approaches too closely, so I
can't comment on that.

It really depends on your platform, U-Boot's configuration for
your project, where the environment is stored on media, how often
you change the environment before production or "how individual"
each machine's initial environment is, how you put the initial
software onto blank hardware, how you integrate the Linux system
with the boot loader, how your organization communicates and
deals with external partners and customers, etc, how useful the
fw_printenv(1) tool is for you, whether you see it as a host tool
or a target binary, and how much you value its being accessible
easily in either form.


> Is there any reason that we don't fix tools/env/Makefile?
> 
>   $(obj)fw_printenv:  $(HOSTSRCS) $(HEADERS)
>   $(HOSTCC) $(HOSTCFLAGS_NOPED) $(HOSTLDFLAGS) -o $@ $(HOSTSRCS)
>   $(HOSTSTRIP) $@
> 
> to
> 
>   $(obj)fw

Re: [U-Boot] [PATCH v4 32/37] Makefile: refactor tools-all targets

[Gerhard Sittig]

On Wed, Jan 15, 2014 at 11:23 +0900, Masahiro Yamada wrote:
> 
> I did not know how "env" target have been used.
> Your comments are highly appreciated!
> 
> I will revive "env" target at v5.
> 
> But whan I cannot understand is why HOSTCC must be tweaked.
> (I am also asking this question in "Compiling fw_printenv tool" thread)
> 
> If fw_printenv must be always compiled with cross-tools,
> I'd like to suggest to use $(CC) instead of $(HOSTCC)
> in tools/env/Makefile.

for the record:  I've replied in the other thread, to not clobber
the kbuild review thread and archives with env related discussion


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

[U-Boot] [PATCH] ARM: tegra20: Add a missing entry in the pullid enum

[Alban Bedel]

It seems two entries were merged in one when this file has been
created. The GPSLXAU entries is obviously a mix of GPU and SLXA which
are next to each other according to the datasheet. Moreover it can be
noticed because the APB_MISC_PP_PULLUPDOWN_REG_B_0 register only have
15 entries instead of 16.

Also fix the pin group descriptions that were using these buggy
entries. In particular SLXA that needed to used CRTP to actually
write the SLXA register.

Signed-off-by: Alban Bedel 
---
 arch/arm/cpu/tegra20-common/pinmux.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/cpu/tegra20-common/pinmux.c 
b/arch/arm/cpu/tegra20-common/pinmux.c
index a65e991..5c80ed9 100644
--- a/arch/arm/cpu/tegra20-common/pinmux.c
+++ b/arch/arm/cpu/tegra20-common/pinmux.c
@@ -190,7 +190,8 @@ enum pmux_pullid {
 
PUCTL_SPDI,
PUCTL_SPDO,
-   PUCTL_GPSLXAU,
+   PUCTL_GPU,
+   PUCTL_SLXA,
PUCTL_CRTP,
PUCTL_SLXC,
PUCTL_SLXD,
@@ -333,8 +334,7 @@ const struct tegra_pingroup_desc 
tegra_soc_pingroups[PINGRP_COUNT] = {
PIN(DTD,  VI,RSVD,   SDIO2,  VI,RSVD,RSVD1),
PIN(DTE,  VI,RSVD,   RSVD,   VI,SPI1,RSVD1),
 
-   PINP(GPU, UART,  PWM,UARTA,  GMI,   RSVD,RSVD4,
-   GPSLXAU),
+   PIN(GPU,  UART,  PWM,UARTA,  GMI,   RSVD,RSVD4),
PIN(GPV,  SD,PCIE,   RSVD,   RSVD,  RSVD,PCIE),
PIN(I2CP, SYS,   I2C,RSVD,   RSVD,  RSVD,RSVD4),
PIN(IRTX, UART,  UARTA,  UARTB,  GMI,   SPI4,UARTB),
@@ -356,7 +356,7 @@ const struct tegra_pingroup_desc 
tegra_soc_pingroups[PINGRP_COUNT] = {
PIN(SDC,  SD,PWM,TWC,SDIO3, SPI3,TWC),
PIN(SDD,  SD,UARTA,  PWM,SDIO3, SPI3,PWM),
PIN_RESERVED,
-   PINP(SLXA, SD,   PCIE,   SPI4,   SDIO3, SPI2,PCIE, CRTP),
+   PIN(SLXA, SD,PCIE,   SPI4,   SDIO3, SPI2,PCIE),
PIN(SLXC, SD,SPDIF,  SPI4,   SDIO3, SPI2,SPI4),
PIN(SLXD, SD,SPDIF,  SPI4,   SDIO3, SPI2,SPI4),
PIN(SLXK, SD,PCIE,   SPI4,   SDIO3, SPI2,PCIE),
-- 
1.8.5.2

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

[U-Boot] [PATCH] designware_i2c: Enhance DesignWare I2C driver address support

[Chin Liang See]

Enhance the DesignWare I2C driver to support address length more
than 1 byte. This enhancement is required as some I2C slave
device such as EEPROM chip might have 16 bit address byte.

Signed-off-by: Chin Liang See 
Cc: Alexey Brodkin 
Cc: Tom Rini 
cc: Armando Visconti 
Cc: Stefan Roese 
Cc: Albert ARIBAUD 
Cc: Heiko Schocher 
Cc: Vipin KUMAR 
Cc: Tom Rix 
Cc: Mischa Jonker 
---
 drivers/i2c/designware_i2c.c |   24 +---
 1 file changed, 9 insertions(+), 15 deletions(-)

diff --git a/drivers/i2c/designware_i2c.c b/drivers/i2c/designware_i2c.c
index cb2ac04..c0ac5f7 100644
--- a/drivers/i2c/designware_i2c.c
+++ b/drivers/i2c/designware_i2c.c
@@ -205,27 +205,21 @@ static int check_params(uint addr, int alen, uchar 
*buffer, int len)
return 1;
}
 
-   if (alen > 1) {
-   printf("addr len %d not supported\n", alen);
-   return 1;
-   }
-
-   if (addr + len > 256) {
-   printf("address out of range\n");
-   return 1;
-   }
-
return 0;
 }
 
-static int i2c_xfer_init(uchar chip, uint addr)
+static int i2c_xfer_init(uchar chip, uint addr, int alen)
 {
if (i2c_wait_for_bb())
return 1;
 
i2c_setaddress(chip);
-   writel(addr, &i2c_regs_p->ic_cmd_data);
-
+   while (alen) {
+   alen--;
+   /* high byte address going out first */
+   writel((addr >> (alen * 8)) & 0xff,
+   &i2c_regs_p->ic_cmd_data);
+   }
return 0;
 }
 
@@ -269,7 +263,7 @@ int i2c_read(uchar chip, uint addr, int alen, uchar 
*buffer, int len)
if (check_params(addr, alen, buffer, len))
return 1;
 
-   if (i2c_xfer_init(chip, addr))
+   if (i2c_xfer_init(chip, addr, alen))
return 1;
 
start_time_rx = get_timer(0);
@@ -310,7 +304,7 @@ int i2c_write(uchar chip, uint addr, int alen, uchar 
*buffer, int len)
if (check_params(addr, alen, buffer, len))
return 1;
 
-   if (i2c_xfer_init(chip, addr))
+   if (i2c_xfer_init(chip, addr, alen))
return 1;
 
start_time_tx = get_timer(0);
-- 
1.7.9.5


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

Re: [U-Boot] [PULL] : Please pull u-boot-imx

[Albert ARIBAUD]

Hi Stefano,

On Wed, 15 Jan 2014 10:43:21 +0100, Stefano Babic 
wrote:

> Hi Albert,
> 
> still a couple of patches for the release. Please pull from u-boot-imx,
> thanks !
> 
> The following changes since commit a6bbee66197759f790de83181924bf1d2cf482b2:
> 
>   mx6slevk: Include "mx6_common.h" (2014-01-13 11:52:28 +0100)
> 
> are available in the git repository at:
> 
>   git://www.denx.de/git/u-boot-imx.git master
> 
> for you to fetch changes up to 3a21773129f6ef218f1978d05a1a5d5cf6801ab6:
> 
>   mx6: Add initial support for the Hummingboard solo (2014-01-15
> 10:33:25 +0100)
> 
> 
> Fabio Estevam (2):
>   mx6: clock: Pass the frequency as argument of
> enable_fec_anatop_clock()
>   mx6: Add initial support for the Hummingboard solo
> 
>  arch/arm/cpu/armv7/mx6/clock.c |8 +-
>  arch/arm/include/asm/arch-mx6/clock.h  |9 +-
>  arch/arm/include/asm/arch-mx6/imx-regs.h   |4 +
>  board/freescale/mx6slevk/mx6slevk.c|2 +-
>  board/solidrun/hummingboard/Makefile   |9 +
>  board/solidrun/hummingboard/README |   40 
>  board/solidrun/hummingboard/hummingboard.c |  187 
>  board/solidrun/hummingboard/solo.cfg   |   25 +++
>  board/solidrun/mx6-microsom/800mhz_2x128mx16.cfg   |   74 +++
>  board/solidrun/mx6-microsom/clocks.cfg |   33 +++
>  .../mx6-microsom/ddr-800mhz-32bit-setup.cfg|   76 +++
>  boards.cfg |1 +
>  include/configs/hummingboard.h |  226
> 
>  13 files changed, 691 insertions(+), 3 deletions(-)
>  create mode 100644 board/solidrun/hummingboard/Makefile
>  create mode 100644 board/solidrun/hummingboard/README
>  create mode 100644 board/solidrun/hummingboard/hummingboard.c
>  create mode 100644 board/solidrun/hummingboard/solo.cfg
>  create mode 100644 board/solidrun/mx6-microsom/800mhz_2x128mx16.cfg
>  create mode 100644 board/solidrun/mx6-microsom/clocks.cfg
>  create mode 100644 board/solidrun/mx6-microsom/ddr-800mhz-32bit-setup.cfg
>  create mode 100644 include/configs/hummingboard.h
> 
> 

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

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

Re: [U-Boot] [PATCH v7 01/17] sf: Add extended read commands support

[Gerhard Sittig]

On Mon, Jan 13, 2014 at 18:15 +0530, Jagan Teki wrote:
> 
> On Mon, Jan 13, 2014 at 4:26 PM, Jagan Teki  wrote:
> >
> > Yes the main reason for going maximum or based on controller setting
> > transfer is to improve sf performance. I missed your point as didn't
> > see much use cases from board to connected flash perceptive.
> >
> > I thought we have two options to meet this requirement.
> > 1. dynamic - auto-detection:
> > Get the max_nof_lines based on the board to connected flash.
> > So-that we can configure the transfer mode based on the lines.
> > no idea yet, how to get the max_nof_lines dynamically - any inputs.
> > 2. static: from user level we may give the max_nof_lines
> > ex: sf probe probe [[[bus:]cs]:max_nof_line] [hz] [mode]
> > If user can't input max_nof_line so-that driver will go with single and
> > the rest case transfer modes assigned based on the given input.

As outlined in my previous reply, I'm afraid that the auto
detection will always end up being inferior (unreliable,
potentially dangerous, still not under the user's control).

A simple approach might be to have the user specify the number of
data lines to use (as in your "static" example above).  The
question remains whether this specified number shall be taken as
the exact number or as the maximum number of data lines.

> As this change involves mostly on the driver parts I a thinking
> to go-ahead and try to push this series to master. yes I would
> mark this as my TODO list and will trigger one more thread.
> 
> Hope this idea sounds valid, let me know for any issues.

Agreed, as there are few or no complaints and concerns (yet?),
let's address this limiting the number of data lines at a later
point in time.  Just keep awareness, that was my most important
issue here. :)

Given that Quad-SPI is rather new, I'd expect new designs to be
"consistent" (i.e. always quad capable flash chips attached to
quad capable controllers and connected via the maximum number of
lines known by that time), while only after some more time the
"interesting" combinations crop up (like starting with non-quad
flash chip and only the necessary connections and a quad capable
controller, then dropping in more recent chips without re-rolling
the PCB layout; or upgrading/replacing SoCs and flash chips with
"compatible" devices and not being aware of the software's
"detecting" the maximum while ignoring the wires on board).


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

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

[Albert ARIBAUD]

Hello Tom,

The following changes since commit
6ba2bc8fa9be4bd09ec43e39cb8e666480ef010c:

  arm: use canonical sub mnemonic (2014-01-14 12:38:47 +0100)

are available in the git repository at:

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

for you to fetch changes up to bf46e7d8d134521301ff02b6d97e8998aa10a83d:

  Merge branch 'u-boot-imx/master' into 'u-boot-arm/master' (2014-01-15
  15:18:04 +0100)



Albert ARIBAUD (1):
  Merge branch 'u-boot-imx/master' into 'u-boot-arm/master'

Fabio Estevam (2):
  mx6: clock: Pass the frequency as argument of
enable_fec_anatop_clock() mx6: Add initial support for the Hummingboard
solo

 arch/arm/cpu/armv7/mx6/clock.c |   8 +-
 arch/arm/include/asm/arch-mx6/clock.h  |   9 +-
 arch/arm/include/asm/arch-mx6/imx-regs.h   |   4 +
 board/freescale/mx6slevk/mx6slevk.c|   2 +-
 board/solidrun/hummingboard/Makefile   |   9 +
 board/solidrun/hummingboard/README |  40 
 board/solidrun/hummingboard/hummingboard.c | 187
 + board/solidrun/hummingboard/solo.cfg
 |  25 +++ board/solidrun/mx6-microsom/800mhz_2x128mx16.cfg   |  74
 +++ board/solidrun/mx6-microsom/clocks.cfg |  33 +++
 .../mx6-microsom/ddr-800mhz-32bit-setup.cfg|  76 +++
 boards.cfg |   1 +
 include/configs/hummingboard.h | 226
 + 13 files changed, 691 insertions(+), 3
 deletions(-) create mode 100644 board/solidrun/hummingboard/Makefile
 create mode 100644 board/solidrun/hummingboard/README
 create mode 100644 board/solidrun/hummingboard/hummingboard.c
 create mode 100644 board/solidrun/hummingboard/solo.cfg
 create mode 100644 board/solidrun/mx6-microsom/800mhz_2x128mx16.cfg
 create mode 100644 board/solidrun/mx6-microsom/clocks.cfg
 create mode 100644
 board/solidrun/mx6-microsom/ddr-800mhz-32bit-setup.cfg create mode
 100644 include/configs/hummingboard.h

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

Re: [U-Boot] [PATCH] sf: Fix entries for S25FL256S_256K and S25FL512S_256K

[Jagan Teki]

On Wed, Jan 15, 2014 at 8:06 PM, Marek Vasut  wrote:
> On Wednesday, January 15, 2014 at 03:29:43 PM, Marek Vasut wrote:
>> Both of these chips have 256kB big sectors, thus the _256K suffix,
>> compared to their _64K counterparts, which have 64kB sectors. Also,
>> they have four times less sectors than their _64K counterparts.
>>
>> Signed-off-by: Marek Vasut 
>> Cc: Jagannadha Sutradharudu Teki 
>> ---
>>  drivers/mtd/spi/sf_params.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> Note: Would be nice if someone actually tested this fix as I go by the
>>   datasheet and by the old code that _was_ in U-Boot before the rework.
>
> btw. would be nice to get this one into current release to prevent it being
> broken. But I would _really_ appreciate some real-hardware testing here.

Yes - I'll try it and let us know.

>
>> diff --git a/drivers/mtd/spi/sf_params.c b/drivers/mtd/spi/sf_params.c
>> index daf8fe7..5f63023 100644
>> --- a/drivers/mtd/spi/sf_params.c
>> +++ b/drivers/mtd/spi/sf_params.c
>> @@ -55,9 +55,9 @@ const struct spi_flash_params spi_flash_params_table[] =
>> { {"S25FL032P",  0x010215, 0x4d00,64 * 1024,64, RD_FULL,
>
>> WR_QPP}, {"S25FL064P",   0x010216, 0x4d00,64 * 1024,   128,
>> RD_FULL,   WR_QPP}, {"S25FL128S_64K",  0x012018, 0x4d01,
>> 64
> * 1024,
>>   256, RD_FULL,WR_QPP}, - {"S25FL256S_256K", 0x010219,
> 0x4d00,
>> 64 * 1024,   512, RD_FULL, WR_QPP}, + {"S25FL256S_256K",
> 0x010219,
>> 0x4d00,   256 * 1024,   128, RD_FULL,  WR_QPP}, {"S25FL256S_64K",
>> 0x010219, 0x4d01, 64 * 1024,   512, RD_FULL,   WR_QPP},
>> - {"S25FL512S_256K", 0x010220, 0x4d00,64 * 1024,  1024, RD_FULL,
>
>> WR_QPP}, +{"S25FL512S_256K", 0x010220, 0x4d00,   256 * 1024,   256,
>> RD_FULL,   WR_QPP}, {"S25FL512S_64K",  0x010220, 0x4d01,
>> 64
> * 1024,
>>  1024, RD_FULL,WR_QPP}, #endif
>>  #ifdef CONFIG_SPI_FLASH_STMICRO  /* STMICRO */

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

Re: [U-Boot] [PATCH] designware_i2c: Enhance DesignWare I2C driver address support

[Alexey Brodkin]

On Wed, 2014-01-15 at 08:58 -0600, Chin Liang See wrote:
> Enhance the DesignWare I2C driver to support address length more
> than 1 byte. This enhancement is required as some I2C slave
> device such as EEPROM chip might have 16 bit address byte.
> diff --git a/drivers/i2c/designware_i2c.c b/drivers/i2c/designware_i2c.c
> index cb2ac04..c0ac5f7 100644
> --- a/drivers/i2c/designware_i2c.c
> +++ b/drivers/i2c/designware_i2c.c
> @@ -205,27 +205,21 @@ static int check_params(uint addr, int alen, uchar 
> *buffer, int len)
>   return 1;
>   }
>  
> - if (alen > 1) {
> - printf("addr len %d not supported\n", alen);
> - return 1;
> - }
> -
> - if (addr + len > 256) {
> - printf("address out of range\n");
> - return 1;
> - }
> -
>   return 0;
>  }

Hi Chin,

if you strip down functionality of "check_params()" to one single check
I would recommend you to remove "check_params()" at all and do in-place
check for "buffer" existence.

Moreover you may just use "assert" for this check because this buffer is
passed by u-boot (no need to check every parameter passed to any
function in run-time) so in production/release build it won't exist at
all.

Regards,
Alexey

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

Re: [U-Boot] [PATCH] drivers/designware_i2c - add suppor of CONFIG_SYS_I2C_EEPROM_ADDR_OVERFLOW

[Alexey Brodkin]

On Mon, 2013-12-16 at 15:30 +0400, Alexey Brodkin wrote:
> Since we agreed on legacy implementation of "eeprom_{read|write}"
> (http://patchwork.ozlabs.org/patch/295825/) I had to fix/make it work
> again DesignWare I2C driver for cases when 1 EEPROM IC fake I2C with
> anumber of "built-in" ICs with different chip addresses.

Hi Heiko,

any chance to get this one applied?
Note this is not an enhancement - this is a required fix due to
roll-back (http://patchwork.ozlabs.org/patch/295825/) of my previous fix
in http://patchwork.ozlabs.org/patch/289346/

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

Re: [U-Boot] [PATCH] sf: Fix entries for S25FL256S_256K and S25FL512S_256K

[Marek Vasut]

On Wednesday, January 15, 2014 at 04:17:55 PM, Jagan Teki wrote:
> On Wed, Jan 15, 2014 at 8:06 PM, Marek Vasut  wrote:
> > On Wednesday, January 15, 2014 at 03:29:43 PM, Marek Vasut wrote:
> >> Both of these chips have 256kB big sectors, thus the _256K suffix,
> >> compared to their _64K counterparts, which have 64kB sectors. Also,
> >> they have four times less sectors than their _64K counterparts.
> >> 
> >> Signed-off-by: Marek Vasut 
> >> Cc: Jagannadha Sutradharudu Teki 
> >> ---
> >> 
> >>  drivers/mtd/spi/sf_params.c | 4 ++--
> >>  1 file changed, 2 insertions(+), 2 deletions(-)
> >> 
> >> Note: Would be nice if someone actually tested this fix as I go by the
> >> 
> >>   datasheet and by the old code that _was_ in U-Boot before the
> >>   rework.
> > 
> > btw. would be nice to get this one into current release to prevent it
> > being broken. But I would _really_ appreciate some real-hardware testing
> > here.
> 
> Yes - I'll try it and let us know.

Thanks!

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

Re: [U-Boot] [PATCH] designware_i2c: Enhance DesignWare I2C driver address support

[Chin Liang See]

Hi Alexey,

On Wed, 2014-01-15 at 15:30 +, Alexey Brodkin wrote:
> On Wed, 2014-01-15 at 08:58 -0600, Chin Liang See wrote:
> > Enhance the DesignWare I2C driver to support address length more
> > than 1 byte. This enhancement is required as some I2C slave
> > device such as EEPROM chip might have 16 bit address byte.
> > diff --git a/drivers/i2c/designware_i2c.c b/drivers/i2c/designware_i2c.c
> > index cb2ac04..c0ac5f7 100644
> > --- a/drivers/i2c/designware_i2c.c
> > +++ b/drivers/i2c/designware_i2c.c
> > @@ -205,27 +205,21 @@ static int check_params(uint addr, int alen, uchar 
> > *buffer, int len)
> > return 1;
> > }
> >  
> > -   if (alen > 1) {
> > -   printf("addr len %d not supported\n", alen);
> > -   return 1;
> > -   }
> > -
> > -   if (addr + len > 256) {
> > -   printf("address out of range\n");
> > -   return 1;
> > -   }
> > -
> > return 0;
> >  }
> 
> Hi Chin,
> 
> if you strip down functionality of "check_params()" to one single check
> I would recommend you to remove "check_params()" at all and do in-place
> check for "buffer" existence.
> 
> Moreover you may just use "assert" for this check because this buffer is
> passed by u-boot (no need to check every parameter passed to any
> function in run-time) so in production/release build it won't exist at
> all.

Good suggestion. I agreed that we can strip off the check_params. Let me
send the v2 patch. Thanks and have a nice day!

Chin Liang

> 
> Regards,
> Alexey
> 
> 



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

[U-Boot] [PATCH v2] designware_i2c: Enhance DesignWare I2C driver address support

[Chin Liang See]

Enhance the DesignWare I2C driver to support address length more
than 1 byte. This enhancement is required as some I2C slave
device such as EEPROM chip might have 16 bit address byte.

Signed-off-by: Chin Liang See 
Cc: Alexey Brodkin 
Cc: Tom Rini 
cc: Armando Visconti 
Cc: Stefan Roese 
Cc: Albert ARIBAUD 
Cc: Heiko Schocher 
Cc: Vipin KUMAR 
Cc: Mischa Jonker 
---
Changes for v2
- Removed the function check_params()
---
 drivers/i2c/designware_i2c.c |   41 +
 1 file changed, 9 insertions(+), 32 deletions(-)

diff --git a/drivers/i2c/designware_i2c.c b/drivers/i2c/designware_i2c.c
index cb2ac04..5b8482a 100644
--- a/drivers/i2c/designware_i2c.c
+++ b/drivers/i2c/designware_i2c.c
@@ -197,35 +197,18 @@ static int i2c_wait_for_bb(void)
return 0;
 }
 
-/* check parameters for i2c_read and i2c_write */
-static int check_params(uint addr, int alen, uchar *buffer, int len)
-{
-   if (buffer == NULL) {
-   printf("Buffer is invalid\n");
-   return 1;
-   }
-
-   if (alen > 1) {
-   printf("addr len %d not supported\n", alen);
-   return 1;
-   }
-
-   if (addr + len > 256) {
-   printf("address out of range\n");
-   return 1;
-   }
-
-   return 0;
-}
-
-static int i2c_xfer_init(uchar chip, uint addr)
+static int i2c_xfer_init(uchar chip, uint addr, int alen)
 {
if (i2c_wait_for_bb())
return 1;
 
i2c_setaddress(chip);
-   writel(addr, &i2c_regs_p->ic_cmd_data);
-
+   while (alen) {
+   alen--;
+   /* high byte address going out first */
+   writel((addr >> (alen * 8)) & 0xff,
+   &i2c_regs_p->ic_cmd_data);
+   }
return 0;
 }
 
@@ -266,10 +249,7 @@ int i2c_read(uchar chip, uint addr, int alen, uchar 
*buffer, int len)
 {
unsigned long start_time_rx;
 
-   if (check_params(addr, alen, buffer, len))
-   return 1;
-
-   if (i2c_xfer_init(chip, addr))
+   if (i2c_xfer_init(chip, addr, alen))
return 1;
 
start_time_rx = get_timer(0);
@@ -307,10 +287,7 @@ int i2c_write(uchar chip, uint addr, int alen, uchar 
*buffer, int len)
int nb = len;
unsigned long start_time_tx;
 
-   if (check_params(addr, alen, buffer, len))
-   return 1;
-
-   if (i2c_xfer_init(chip, addr))
+   if (i2c_xfer_init(chip, addr, alen))
return 1;
 
start_time_tx = get_timer(0);
-- 
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 v2] designware_i2c: Enhance DesignWare I2C driver address support

[Alexey Brodkin]

On Wed, 2014-01-15 at 09:45 -0600, Chin Liang See wrote:
> Changes for v2
> - Removed the function check_params()

Ok, so you decided to not add "assert" check instead.
I think it's ok - it's not a requirement. Others don't do it as well so
let's leave it as it is.

Acked-by: Alexey Brodkin 

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

[U-Boot] [PATCH] i.MX6DQ/DLS: rename and fix pad MX6_PAD_RGMII_TX_CTL__ENET_REF_CLK

[Hector Palacios]

Fix incorrect name for iomux 0x7 of MX6_PAD_RGMII_TX_CTL which really
has function ENET_REF_CLK and not ANATOP_REF_OUT.
On imx6q also fix select input value to 1.

Signed-off-by: Hector Palacios 
---
 arch/arm/include/asm/arch-mx6/mx6dl_pins.h | 2 +-
 arch/arm/include/asm/arch-mx6/mx6q_pins.h  | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/include/asm/arch-mx6/mx6dl_pins.h 
b/arch/arm/include/asm/arch-mx6/mx6dl_pins.h
index 3dd3bfe36a4d..1880c0957ae1 100644
--- a/arch/arm/include/asm/arch-mx6/mx6dl_pins.h
+++ b/arch/arm/include/asm/arch-mx6/mx6dl_pins.h
@@ -1430,7 +1430,7 @@ enum {
MX6_PAD_RGMII_TX_CTL__RGMII_TX_CTL = 
IOMUX_PAD(0x06BC, 0x02D4, 1, 0x, 0, 0),
MX6_PAD_RGMII_TX_CTL__GPIO_6_26= 
IOMUX_PAD(0x06BC, 0x02D4, 5, 0x, 0, 0),
MX6_PAD_RGMII_TX_CTL__MIPI_CORE_DPHY_TEST_IN_7 = 
IOMUX_PAD(0x06BC, 0x02D4, 6, 0x, 0, 0),
-   MX6_PAD_RGMII_TX_CTL__ENET_ANATOP_ETHERNET_REF_OUT = 
IOMUX_PAD(0x06BC, 0x02D4, 7, 0x080C, 1, 0),
+   MX6_PAD_RGMII_TX_CTL__ENET_REF_CLK = 
IOMUX_PAD(0x06BC, 0x02D4, 7, 0x080C, 1, 0),
MX6_PAD_RGMII_TXC__USBOH3_H2_DATA  = 
IOMUX_PAD(0x06C0, 0x02D8, 16, 0x, 0, 0),
MX6_PAD_RGMII_TXC__ENET_RGMII_TXC  = 
IOMUX_PAD(0x06C0, 0x02D8, 1, 0x, 0, 0),
MX6_PAD_RGMII_TXC__SPDIF_SPDIF_EXTCLK  = 
IOMUX_PAD(0x06C0, 0x02D8, 2, 0x08F4, 1, 0),
diff --git a/arch/arm/include/asm/arch-mx6/mx6q_pins.h 
b/arch/arm/include/asm/arch-mx6/mx6q_pins.h
index 02a40d4f5c6c..9714dc69fe88 100644
--- a/arch/arm/include/asm/arch-mx6/mx6q_pins.h
+++ b/arch/arm/include/asm/arch-mx6/mx6q_pins.h
@@ -84,7 +84,7 @@ enum {
MX6_PAD_RGMII_TX_CTL__RGMII_TX_CTL  = IOMUX_PAD(0x0388, 0x0074, 1, 
0x, 0, 0),
MX6_PAD_RGMII_TX_CTL__GPIO_6_26 = IOMUX_PAD(0x0388, 0x0074, 5, 0x, 
0, 0),
MX6_PAD_RGMII_TX_CTL__CORE_DPHY_IN_7= IOMUX_PAD(0x0388, 0x0074, 6, 
0x, 0, 0),
-   MX6_PAD_RGMII_TX_CTL__ANATOP_REF_OUT= IOMUX_PAD(0x0388, 0x0074, 7, 
0x083C, 0, 0),
+   MX6_PAD_RGMII_TX_CTL__ENET_REF_CLK  = IOMUX_PAD(0x0388, 0x0074, 7, 
0x083C, 1, 0),
MX6_PAD_RGMII_RD1__MIPI_HSI_CTRL_TX_FL = IOMUX_PAD(0x038C, 0x0078, 0, 
0x, 0, 0),
MX6_PAD_RGMII_RD1__ENET_RGMII_RD1   = IOMUX_PAD(0x038C, 0x0078, 1, 
0x084C, 0, 0),
MX6_PAD_RGMII_RD1__GPIO_6_27= IOMUX_PAD(0x038C, 0x0078, 5, 
0x, 0, 0),
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] sf: Add S25FL128S_256K IDs

[Jagan Teki]

On Wed, Jan 15, 2014 at 8:02 PM, Marek Vasut  wrote:
> Add IDs for this new chip.
>
> Signed-off-by: Marek Vasut 
> Cc: Jagannadha Sutradharudu Teki 
> ---
>  drivers/mtd/spi/sf_params.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/mtd/spi/sf_params.c b/drivers/mtd/spi/sf_params.c
> index 5f63023..eb372b7 100644
> --- a/drivers/mtd/spi/sf_params.c
> +++ b/drivers/mtd/spi/sf_params.c
> @@ -54,6 +54,7 @@ const struct spi_flash_params spi_flash_params_table[] = {
> {"S25FL128P_64K",  0x012018, 0x0301,64 * 1024,   256, RD_FULL,
>WR_QPP},
> {"S25FL032P",  0x010215, 0x4d00,64 * 1024,64, RD_FULL,
>WR_QPP},
> {"S25FL064P",  0x010216, 0x4d00,64 * 1024,   128, RD_FULL,
>WR_QPP},
> +   {"S25FL128S_256K", 0x012018, 0x4d00,   256 * 1024,64, RD_FULL,
>WR_QPP},
> {"S25FL128S_64K",  0x012018, 0x4d01,64 * 1024,   256, RD_FULL,
>WR_QPP},
> {"S25FL256S_256K", 0x010219, 0x4d00,   256 * 1024,   128, RD_FULL,
>WR_QPP},
> {"S25FL256S_64K",  0x010219, 0x4d01,64 * 1024,   512, RD_FULL,
>WR_QPP},
> --
> 1.8.5.2
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot

Reviewed-by: Jagannadha Sutradharudu Teki 

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

Re: [U-Boot] [PATCH] arm: exynos: change to use clrbits macro instead of readl/writel function

[Gerhard Sittig]

On Tue, Jan 14, 2014 at 13:01 +0900, Inha Song wrote:
> 
> Use setbits/clrbits macro instead of readl/writel function
> 
> Signed-off-by: Inha Song 

You can probably trim down the subject line's length by omitting
the "change to" words.  It's obvious that a patch changes
something.


It's true that your replacing open-coded read-modify-write
sequences with bit manipulation macros much better reflects what
actually is happening from the application's POV.  But your patch
does more than that (supported by the "now works for me" reply),
and I feel that your commit message should reflect this so others
can be aware (both of the fix, and of the former bug).

"In bypassing" you fix a few bugs (I noticed those around lines
1114 and 1176, and only because I remembered your other
submission which you don't reference) where random data was
written to clock control registers (either uninitialized data, or
potentially stale data that was set from unrelated sources).

So you may want to followup to your former submission, stating
that it has become obsolete or superseeded.  Or send out a v2
series (or any other appropriate version number) with a reference
to the former patch, when you consider this new patch the
improvement to your earlier submission.  This helps reviewers and
maintainers.


> @@ -1114,16 +1099,13 @@ void exynos4_set_lcd_clk(void)
>* MIPI0_PRE_RATIO  [23:20]
>* set fimd ratio
>*/
> - cfg &= ~(0xf);
> - cfg |= 0x1;
> - writel(cfg, &clk->div_lcd0);
> + clrsetbits_le32(&clk->div_lcd0, 0xe, 0x1);
>  }
>  

There still is the question whether you happen to set individual
bits (and where clearing and setting the very same bit is
unexpected), or whether you are writing an integer value into a
bitfield that only spans part of a register.  And whether using
symbolic identifiers helps readers and fellow developers since
magic numbers obfuscate the motivation.

Please check for those style issues.  I've seen e.g. both "and
0xf, or 0x1" as well as "and 0x9, or 0x6" which is inconsistent.
Unless this is the "bits vs numbers" thing, where comments may
help.  (Ignore this latter concern if there already are those
comments, which just are not in the patch's context.  I haven't
checked the source but only looked at your patch.)


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

Re: [U-Boot] [PATCH 1/3] config: Update envs for trats and trats2 - new entries for new partitions

[Gerhard Sittig]

On Tue, Jan 14, 2014 at 08:02 +0100, Lukasz Majewski wrote:
> 
> diff --git a/include/configs/trats.h b/include/configs/trats.h
> index 6cd15c2..0bdfe86 100644
> --- a/include/configs/trats.h
> +++ b/include/configs/trats.h
> @@ -143,7 +143,10 @@
>   "u-boot mmc 80 400;" \
>   "uImage ext4 0 2;" \
>   "exynos4210-trats.dtb ext4 0 2;" \
> - ""PARTS_ROOT" part 0 5\0"
> + ""PARTS_BOOT" part 0 2;" \
> + ""PARTS_ROOT" part 0 5;" \
> + ""PARTS_DATA" part 0 6;" \
> + ""PARTS_UMS" part 0 7\0"

Have recent compilers become stricter about string concatenation?
ISTR that a space is recommended (which helps human readers as
well).


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

Re: [U-Boot] [PATCH 3/7] board:samsung:common: set envs with board unified information

[Gerhard Sittig]

On Tue, Jan 14, 2014 at 08:59 +0100, Piotr Wilczek wrote:
> 
> This patch enables to set envs that describe board information.
> The following envs are set (but not saved): soc_id, soc_rev, board_rev.

I don't see the "not saved" part in the patch.  How exactly does
a "saveenv" not save those programmatically generated variables?
(Altera SoCFPGA suffers from the same issue, we may not want to
repeat this in mainline U-Boot)

> Based on this information, 'fdtaddr' env is set (not saved) as:
> fdtaddr=${soc_family}${soc_id}-${board}.dtb

An address variable resolves to a DTB filename?  That would be
unexpected.  Or is it a typo in the commit message?


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

Re: [U-Boot] [PATCH v2] powerpc: mpc5xxx: remove redundant CONFIG_MPC5xxx definition

[Gerhard Sittig]

On Tue, Jan 14, 2014 at 17:26 +0900, Masahiro Yamada wrote:
> 
> diff --git a/include/configs/BC3450.h b/include/configs/BC3450.h
> index 377db7b..ad69d33 100644
> --- a/include/configs/BC3450.h
> +++ b/include/configs/BC3450.h
> @@ -22,7 +22,6 @@
>  /*
>   * High Level Configuration Options
>   */
> -#define CONFIG_MPC5xxx   1   /* This is an MPC5xxx CPU   
> */
>  #define CONFIG_MPC5200   1   /* (more precisely a MPC5200 
> CPU)   */
>  #define CONFIG_TQM5200   1   /* ... on a TQM5200 module  
> */
>  

Haven't checked all of the patch, just by coincidence spotted
this one.  The removal of one of the preprocessor lines loses
information in the right hand side comment.  After the patch the
remaining text looks odd.


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

Re: [U-Boot] [PATCH v2] arm: exynos: change to use clrbits macro instead of readl/writel function

[Gerhard Sittig]

On Wed, Jan 15, 2014 at 14:27 +0900, Inha Song wrote:
> 
> Use setbits/clrbits macro instead of readl/writel function

Just saw v2 after replying to v1 (which is only from yesterday).
Please consider the concerns raised there, too.


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

Re: [U-Boot] [PATCH 1/2] env_mmc: make board configurable the partition for the environment

[Hector Palacios]

Hello Otavio,

On 01/15/2014 12:09 PM, Otavio Salvador wrote:

Hello Hector,

On Wed, Jan 15, 2014 at 8:53 AM, Hector Palacios mailto:hector.palac...@digi.com>> wrote:

This complements commit 9404a5fc7cb58 "env_mmc: allow environment to be
in an eMMC partition" by allowing boards to accommodate the partition
to use for the environment in different scenarios (similarly to what is
done with the mmc dev number). Depending on the detected boot media,
boards may decide to store the environment in a different partition.

The __weak function also allows to remove some ifdefs from the code.
If CONFIG_SYS_MMC_ENV_PART is not defined, partition 0 is assumed
(default value for U-Boot when a partition is not provided).

Signed-off-by: Hector Palacios mailto:hector.palac...@digi.com>>
CC: Stephen Warren mailto:swar...@nvidia.com>>
CC: Andy Fleming mailto:aflem...@freescale.com>>
---
  common/env_mmc.c | 27 +++
  1 file changed, 15 insertions(+), 12 deletions(-)

diff --git a/common/env_mmc.c b/common/env_mmc.c
index 78c2bc7a1f08..d569b070e005 100644
--- a/common/env_mmc.c
+++ b/common/env_mmc.c
@@ -64,6 +64,13 @@ __weak int mmc_get_env_addr(struct mmc *mmc, int copy, 
u32
*env_addr)
  __weak int mmc_get_env_devno(void)
  {
 return CONFIG_SYS_MMC_ENV_DEV;
+
+__weak int mmc_get_env_partno(void)
+{
+#ifdef CONFIG_SYS_MMC_ENV_PART
+   return CONFIG_SYS_MMC_ENV_PART;
+#endif
+   return 0;


Maybe:

#ifndef CONFIG_SYS_MMC_ENV_PART
#define CONFIG_SYS_MMC_ENV_PART 0
#endif

__weak int mmc_get_env_partno(void)
{
 return CONFIG_SYS_MMC_ENV_PART;
}


Much better. I'll do this for both patches. Thanks.

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

[U-Boot] [PATCH v2] nand, gpmc: fix reading after switching ecc

[Jeroen Hofstee]

The omap_gpmc allows switching ecc at runtime. Since
the NAND_SUBPAGE_READ flag is only set, it is kept when
switching to hw ecc, which is not correct. This leads to
calling chip->ecc.read_subpage which is not a valid
pointer. Therefore clear the flag when switching ecc so
reading in hw mode works again.

Cc: Scott Wood 
Cc: Pekon Gupta 
Cc: Nikita Kiryanov 
Signed-off-by: Jeroen Hofstee 
---
version 2:
  - clear the flag from the omap_gpmc specific omap_nand_switch_ecc
---
 drivers/mtd/nand/omap_gpmc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/mtd/nand/omap_gpmc.c b/drivers/mtd/nand/omap_gpmc.c
index 790d538..389c4de 100644
--- a/drivers/mtd/nand/omap_gpmc.c
+++ b/drivers/mtd/nand/omap_gpmc.c
@@ -933,6 +933,7 @@ int __maybe_unused omap_nand_switch_ecc(uint32_t hardware, 
uint32_t eccstrength)
mtd = &nand_info[nand_curr_device];
nand = mtd->priv;
nand->options |= NAND_OWN_BUFFERS;
+   nand->options &= ~NAND_SUBPAGE_READ;
/* Setup the ecc configurations again */
if (hardware) {
if (eccstrength == 1) {
-- 
1.8.3.2

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

Re: [U-Boot] [PATCH] board_r - fixup functions table after relocation

[Simon Glass]

Hi Alexey,

On 15 January 2014 04:19, Alexey Brodkin wrote:

> "init_sequence_r" is just an array that consists of compile-time
> adresses of init functions. Since this is basically an array of integers
> (pointers to "void" to be more precise) it won't be modified during
> relocation - it will be just copied to new location as it is.
>
> As a consequence on execution after relocation "initcall_run_list" will
> be jumping to pre-relocation addresses. As long as we don't overwrite
> pre-relocation memory area init calls are executed correctly. But still
> it is dangerous because after relocation we don't expect initially used
> memory to stay untouched.
>
> Signed-off-by: Alexey Brodkin 
>
> Cc: Tom Rini 
> Cc: Simon Glass 
> Cc: Masahiro Yamada 
> Cc: Doug Anderson 
> ---
>  common/board_r.c | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/common/board_r.c b/common/board_r.c
> index 86ca1cb..8f45943 100644
> --- a/common/board_r.c
> +++ b/common/board_r.c
> @@ -903,9 +903,14 @@ init_fnc_t init_sequence_r[] = {
>
>  void board_init_r(gd_t *new_gd, ulong dest_addr)
>  {
> +   int i;
>  #ifndef CONFIG_X86
> gd = new_gd;
>  #endif
> +   /* Fixup table after relocation */
> +   for (i = 0; i < sizeof(init_sequence_r)/sizeof(void *); i++)
> +   init_sequence_r[i] += gd->reloc_off;
> +
>

ARRAY_SIZE() might be better.

I have not checked to make sure that the array contents remains
un-relocated. Did you see this?


if (initcall_run_list(init_sequence_r))
> hang();
>
> --
> 1.8.4.2
>
>
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2] PPC: remove support for MPC82xx processors

[Holger Brunck]

Hi Wolfgang,

On 01/15/2014 01:45 PM, Wolfgang Denk wrote:
>> So if keeping 82xx support would't generate to much overload for u-boot I 
>> would
>> > appreciate to keep it. But if it interferes with future u-boot development 
>> > we
>> > could also move it to a keymile specific branch.
> Do you agree with "keeping 824x" support only?
> 

is this question adressed to myside or to Tom? From myside it's absolutely ok to
keep 824x only.

Regards
Holger

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

Re: [U-Boot] [PATCH v2 6/6] mx6: soc: Disable VDDPU regulator

[Otavio Salvador]

Hello,

On Thu, Jan 9, 2014 at 7:31 PM, Stefano Babic  wrote:
>
> On 09/01/2014 20:11, Otavio Salvador wrote:
>
>> On Thu, Jan 9, 2014 at 5:06 PM, Fabio Estevam > > wrote:
>>
>> On Thu, Jan 9, 2014 at 3:50 PM, Otavio Salvador
>> mailto:ota...@ossystems.com.br>> wrote:
>>
>>  > It seems this patch makes 3.10.17-1.0.0-beta freeze in a customer
>> board;
>>  > reverting this makes this to work again. It freezes when loading
>> Vivante
>>  > module.
>>
>> VDDPU is needed for using the GPU, so the kernel should turn on the
>> VDDPU regulator.
>>
>> Looks like you are getting a kernel bug.
>>
>> It might be but shouldn't we delay this patch for now?
>>
>
> Now or later it does not change. The correct behavior is done with the
> patch, and the kernel must turn power on. If it does not, the patch is
> needed for the kernel, not here.


I've been debugging to make 3.10 to work with this patch, but without
success...

I think this patch should be reverted and be added back to 2014.04 release
so we have more time to debug this.

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 6/6] mx6: soc: Disable VDDPU regulator

[Stefano Babic]

Hi Otavio, hi Fabio,

On 15/01/2014 18:12, Otavio Salvador wrote:

> 
> I've been debugging to make 3.10 to work with this patch, but without
> success...
> 
> I think this patch should be reverted and be added back to 2014.04
> release so we have more time to debug this. 
> 

Generally, I disagree to fix an issue in U-Boot when it is clear that
this should be fixed in another component (in our case, the FSL-3.10
kernel). A patch should be revert if it is buggy - but this patch does
the work and generally U-Boot should not activate what it does not need.

I understand Otavio's reasons to avoid that users by taking the official
releases for U-Boot and FSL-3.10 will get a not working system. But
anyway, IMHO the fix should flow into FSL-3.10 and not here.

Best regards,
Stefano Babic

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

Re: [U-Boot] [PATCH 1/2] env_mmc: make board configurable the partition for the environment

[Stephen Warren]

On 01/15/2014 03:53 AM, Hector Palacios wrote:
> This complements commit 9404a5fc7cb58 "env_mmc: allow environment to be
> in an eMMC partition" by allowing boards to accommodate the partition
> to use for the environment in different scenarios (similarly to what is
> done with the mmc dev number). Depending on the detected boot media,
> boards may decide to store the environment in a different partition.
> 
> The __weak function also allows to remove some ifdefs from the code.
> If CONFIG_SYS_MMC_ENV_PART is not defined, partition 0 is assumed
> (default value for U-Boot when a partition is not provided).

One advantage of the ifdefs is that it means zero code size bloat for
people who haven't defined CONFIG_SYS_MMC_ENV_PART. I'm not that
concerned about the issue for this amount of code, so don't take this as
a nak from me, but I'm sure others will be.

Also, it seems like a good idea to explicitly force people to think
about the partition ID they want the environment stored in, rather than
assume some potentially incorrect default for it?

> diff --git a/common/env_mmc.c b/common/env_mmc.c

> +__weak int mmc_get_env_partno(void)
> +{
> +#ifdef CONFIG_SYS_MMC_ENV_PART
> + return CONFIG_SYS_MMC_ENV_PART;
> +#endif

With this implementation, you'd want that to be #else

> + return 0;

... and the #endif here, so you don't end up with two return statements
back-to-back in the function in one case.

>  }

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

Re: [U-Boot] [PATCH 2/2] env_mmc: default to 0 if CONFIG_SYS_MMC_ENV_DEV not defined

[Stephen Warren]

On 01/15/2014 03:53 AM, Hector Palacios wrote:
> Since function mmc_get_env_devno is __weak and can be overridden by
> board code, boards do not necessarily need to define
> CONFIG_SYS_MMC_ENV_DEV. If the constant is not defined, return 0 by
> default.

Ah, I see that's a better justification for allowing the define not to
be set.


> diff --git a/common/env_mmc.c b/common/env_mmc.c

>  __weak int mmc_get_env_devno(void)
>  {
> +#ifdef CONFIG_SYS_MMC_ENV_DEV
>   return CONFIG_SYS_MMC_ENV_DEV;
> +#endif

Same comment here; need a #else here, and #endif below.
> + return 0;
> +}

Re: Hector's comments: Perhaps the following in
include/config_fallbacks.h would be appropriate?

#ifndef CONFIG_SYS_MMC_ENV_DEV
#define CONFIG_SYS_MMC_ENV_DEV 0
#endif

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

Re: [U-Boot] sf: Discussion on quad changes

[Simon Glass]

Hi Jagan,

On 15 January 2014 02:36, Jagan Teki  wrote:
>
> Hi All,
>
> This particular discussion is a next level add-on for thread [1]
>
> State of u-boot now:
> - Added quad changes on u-boot and will be available in coming release.
> - Added commands are
>   1) 1-line # Array slow read, Array fast read(available before)
>   2) 2-line # Dual fast read, Dual IO read
>   3) 3-line # Quad fast read, quad IO read, Quad page program
> - The implementation "will determine the fastest command by taking the 
> supported
>   commands from the flash and the controller, controller is always
> been a priority."
> - Suppose we have a flash that supports all types of commands then from driver
>   side we have an option to set the particular command and the same option 
> will
>   goes to sf and will determine the fastest one.
>   ex: if flash supports all, but the driver supports dual fast then
> the outcome read
>   could be dual fast.
>
> And even Linux will also does the similar implementation, i guess.
> The main reason for going maximum or based on controller setting transfer is 
> to
> improve sf performance.
>
> But from previous thread of discussion - Gerhard Sittig, identified a
> side-effect on this
> implementation as per as board to connected flash perceptive.
>
> The question as per my understanding was "If a controller support 1,
> 2, and 4 lines then
> the BoardA is designed to connect a flash with 4-lines, BoardB is
> designed to connect
> a flash with 2-lines and BoardC is designed to connect a flash with 1-line."
>
> In above scenario - as we have a common controller driver that may set
> an option to support
> quad then BoardB and BoardC will fail to transfer.
>
> Gerhard Sittig, please add if i miss any points here!
>
> I do agree this scenario and I have few possible inputs.
> 1) dynamic - auto-detection:
> Get the max_nof_lines based on the board to connected flash.
> So-that we can configure the transfer mode based on the lines.
> no idea yet, how to get the max_nof_lines dynamically - any inputs.
> 2) static: from user level we may give the max_nof_lines
> ex: sf probe probe [[[bus:]cs]:max_nof_line] [hz] [mode]
> If user can't input max_nof_line so-that driver will go with single and
> the rest case transfer modes assigned based on the given input.
> for Linux it can be pdata or dts.


I don't have strong opinions on this, but do have a question. How
about board-level configuration? Some boards may use device tree to
indicate which SPI pins / features are available. Perhaps the
configuration could have 'detect' option also. But in many cases I
would expect that the board vendor would know what is supported, and
any 'sf' options should respect that.

>
>
> Request for comments!
>
> [1] 
> http://u-boot.10912.n7.nabble.com/PATCH-v7-01-17-sf-Add-extended-read-commands-support-td171225.html#a171290
>
> --
> Thanks,
> Jagan.


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

Re: [U-Boot] [PATCH v4 0/8] Provide a mechanism to avoid using #ifdef everywhere

[Simon Glass]

Hi Detlev,

On 14 January 2014 03:11, Detlev Zundel  wrote:
> Hi Simon,
>
> as I don't see any follow-up, allow me to jump in here even that late :)
>
>> Hi Wolfgang,
>>
>> On Wed, Nov 6, 2013 at 1:24 AM, Wolfgang Denk  wrote:
>>> Dear Simon Glass,
>>>
>>> In message <1382800457-26608-1-git-send-email-...@chromium.org> you wrote:
 Many parts of the U-Boot code base are sprinkled with #ifdefs. This makes
 different boards compile different versions of the source code, meaning
 that we must build all boards to check for failures. It is easy to
>> misspell
 an #ifdef and there is not as much checking of this by the compiler.
>> Multiple
 dependent #ifdefs are harder to do than with if..then..else. Variable
 declarations must be #idefed as well as the code that uses them, often
>> much
 later in the file/function. #ifdef indents don't match code indents and
 have their own separate indent feature. Overall, excessive use of #idef
 hurts readability and makes the code harder to modify and refactor. For
 people coming newly into the code base, #ifdefs can be a big barrier.

 The use of #ifdef in U-Boot has possibly got a little out of hand. In an
 attempt to turn the tide, this series includes a patch which provides a
>> way
 to make CONFIG macros available to C code without using the preprocessor.
 This makes it possible to use standard C conditional features such as
 if/then instead of #ifdef. A README update exhorts compliance.
>>>
>>> As mentioned before, I'm really interested in seeing something like
>>> this going into mainline, but I have some doubts about the actual
>>> implementation.
>>>
>>> To summarize:  Your current proposal was to convert code snippets
>>> like this:
>>>
>>> #ifdef CONFIG_VERSION_VARIABLE
>>> setenv("ver", version_string);  /* set version variable */
>>> #endif
>>>
>>> into
>>>
>>> if (autoconf_version_variable())
>>> setenv("ver", version_string);  /* set version variable */
>>>
>>> By chance I ran about "include/linux/kconfig.h" in the Linux kernel
>>> tree, which provides (among other things) the IS_ENABLED() macro that
>>> implements essentially the very same feature.  Using this, the same
>>> code would be written as:
>>>
>>> if (IS_ENABLED(CONFIG_VERSION_VARIABLE))
>>> setenv("ver", version_string);  /* set version variable */
>>>
>>> I agree that this does not solve some of the isses that have been
>>> raised about this change (indentation level increses - which may in
>>> turn require reformatting of bigger parts of the code; code becomes
>>> less readable), but on the other hand it avoids the need for a new
>>> autoconf header file, and it should be possible to introduce this
>>> easily step by step.
>>>
>>> And I really like the idea of re-using existing code that is already
>>> known to Linux hackers, especially as we we are currently having our
>>> eyes on the Kconfig stuff anyway.
>>>
>>>
>>> What do you think?
>>
>> Fair enough, sounds reasonable. The relevant kernel code is quite unusual...
>>
>> /*
>>>  * Helper macros to use CONFIG_ options in C/CPP expressions. Note that
>>>  * these only work with boolean and tristate options.
>>>  */
>>> /*
>>>  * Getting something that works in C and CPP for an arg that may or may
>>>  * not be defined is tricky.  Here, if we have "#define CONFIG_BOOGER 1"
>>>  * we match on the placeholder define, insert the "0," for arg1 and
>>> generate
>>>  * the triplet (0, 1, 0).  Then the last step cherry picks the 2nd arg (a
>>> one).
>>>  * When CONFIG_BOOGER is not defined, we generate a (... 1, 0) pair, and
>>> when
>>>  * the last step cherry picks the 2nd arg, we get a zero.
>>>  */
>>> #define __ARG_PLACEHOLDER_1 0,
>>> #define config_enabled(cfg) _config_enabled(cfg)
>>> #define _config_enabled(value) __config_enabled(__ARG_PLACEHOLDER_##value)
>>> #define __config_enabled(arg1_or_junk) ___config_enabled(arg1_or_junk 1, 0)
>>> #define ___config_enabled(__ignored, val, ...) val
>>> /*
>>>  * IS_ENABLED(CONFIG_FOO) evaluates to 1 if CONFIG_FOO is set to 'y' or
>>> 'm',
>>>  * 0 otherwise.
>>>  *
>>>  */
>>> #define IS_ENABLED(option) \
>>> (config_enabled(option) || config_enabled(option##_MODULE))
>>
>
> I think the Linux code has two big advantages - for one, we increase the
> overlap with Linux kernel proper and secondly we keep the 'grep'ability
> of the names which I really missed in your proposal.

Yes that seems reasonable.

>
>> Many of U-Boot's options are not just yes/no, so I'm not sure what will
>> happen with those. Perhaps they just can't be used with this macro? Part of
>> my intent was to allow any option to be used.
>
> In those cases the defines then are a "shortcut" to using a boolean + a
> value and we can make it work by introducing this boolean?  I have no
> idea of how much work this would be, but it might be worthwhile getting
> some real numbers to that.
>
>> So for 

Re: [U-Boot] [PATCH] ARM: tegra20: Add a missing entry in the pullid enum

[Stephen Warren]

On 01/15/2014 07:55 AM, Alban Bedel wrote:
> It seems two entries were merged in one when this file has been
> created. The GPSLXAU entries is obviously a mix of GPU and SLXA which
> are next to each other according to the datasheet. Moreover it can be
> noticed because the APB_MISC_PP_PULLUPDOWN_REG_B_0 register only have
> 15 entries instead of 16.
> 
> Also fix the pin group descriptions that were using these buggy
> entries. In particular SLXA that needed to used CRTP to actually
> write the SLXA register.

This does appear to match the kernel's pinctrl driver, so,
Acked-by: Stephen Warren 

I wonder how many more similar issues there are. Did you check the whole
file for this kind of issue, or just debug a problem with one particular
pin/group?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

[Marek Vasut]

On Monday, January 13, 2014 at 08:42:18 PM, Tom Rini wrote:
> On Tue, Jan 14, 2014 at 12:05:32AM +0530, Jagannadha Sutradharudu Teki wrote:
> > Hi Tom,
> > 
> > PR have quad and dual_flash change set also includes few fixes.
> > Tested these changes on spansion, stmicro and sst flash devices.
> > 
> > --
> > Thanks,
> > Jagan.
> > 
> > The following changes since commit 7f673c99c2d8d1aa21996c5b914f06d784b080ca:
> >   Merge branch 'master' of git://git.denx.de/u-boot-arm (2014-01-10
> >   10:56:00 -0500)
> > 
> > are available in the git repository at:
> >   git://git.denx.de/u-boot-spi.git master
> > 
> > for you to fetch changes up to 35a55fb57fffb615e6b20980fb317e162076adb4:
> >   sf: params: Removed flag SECT_4K for Micron N25Q128 (2014-01-12
> >   21:40:23 +0530)
> > 
> > 
> > 
> > Axel Lin (1):
> >   spi: sh_spi: Use sh_spi_clear_bit() instead of open-coded
> > 
> > Jagannadha Sutradharudu Teki (17):
> >   sf: Add extended read commands support
> >   sf: Add quad read/write commands support
> >   sf: ops: Add configuration register writing support
> >   sf: Set quad enable bit support
> >   sf: probe: Enable RD_FULL and WR_QPP
> >   sf: Separate the flash params table
> >   sf: Add QUAD_IO_FAST read support
> >   sf: Discover read dummy_byte
> >   sf: Add macronix set QEB support
> >   sf: probe: Enable macronix quad read/write cmds support
> >   sf: Divide flash register ops from QEB code
> >   sf: Code cleanups
> >   sf: ops: Unify read_ops bank configuration
> >   sf: Add dual memories support - DUAL_STACKED
> >   sf: Add dual memories support - DUAL_PARALLEL
> >   sf: Add CONFIG_SF_DUAL_FLASH
> >   doc: SPI: Update status.txt

I looked into this patchset and this seems completely misdesigned, sorry.

It seems this patchset aims to accomodate an SPI-NOR controllers within the SPI 
API. The SPI-NOR controllers are a completely separate class of hardware 
though, 
so I disagree with the attempt to integrate them into the SPI framework. I 
cannot use most of the SPI-NOR controllers to drive regular SPI bus (there are 
exceptions), but they are now presented as regular SPI controllers 
indiscriminately.

Instead of going down this path, there should be a completely separate class of 
drivers for the SPI-NOR controllers, same as in Linux [1]. That way, there 
would 
still be an SF command talking to SF core, but the SF core would be delegating 
the calls to either a layer talking to a SPI flash via regular SPI interface or 
a layer talking the SPI-NOR controller.

I also see some flaws in these patches. For example the struct spi_slave {} now 
contains all kinds of new entries used only by the SPI flash driver. The slave 
can now export for example SPI_OPM_RX_QOF and SPI_OPM_RX_QIOF (see 
include/spi.h) flags, which -- if you inspect drivers/mtd/spi/sf_probe.c and 
include/spi_flash.h -- should match up with enum spi_read_cmds . So we now have 
two sets of flags, which needs to be kept in sync, which is wrong. Besides, 
these flags define the capabilities of the SPI-NOR host controller, so why are 
they even in struct spi_slave {} ?

I also observe a big lack of documentation for all those flags, so it's really 
hard to make heads or tails of how it's supposed to work.

Also, I don't see any of these new flags used yet, so we're still at a good 
point to avoid going down the wrong path. I would love to see this patchset 
postponed for next if possible, since my feeling of this is it needs severe 
redesign.

[1] http://www.spinics.net/lists/arm-kernel/msg291891.html

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

Re: [U-Boot] [PATCH 1/3] config: Update envs for trats and trats2 - new entries for new partitions

[Lukasz Majewski]

Hi Gerard,

> On Tue, Jan 14, 2014 at 08:02 +0100, Lukasz Majewski wrote:
> > 
> > diff --git a/include/configs/trats.h b/include/configs/trats.h
> > index 6cd15c2..0bdfe86 100644
> > --- a/include/configs/trats.h
> > +++ b/include/configs/trats.h
> > @@ -143,7 +143,10 @@
> > "u-boot mmc 80 400;" \
> > "uImage ext4 0 2;" \
> > "exynos4210-trats.dtb ext4 0 2;" \
> > -   ""PARTS_ROOT" part 0 5\0"
> > +   ""PARTS_BOOT" part 0 2;" \
> > +   ""PARTS_ROOT" part 0 5;" \
> > +   ""PARTS_DATA" part 0 6;" \
> > +   ""PARTS_UMS" part 0 7\0"
> 
> Have recent compilers become stricter about string concatenation?

I'm using ELDK 5.3 toolchain and this code compiles without warnings.
Also I've tested it with Pengutronix's OSELAS 4.8.2 (OSEALS 2013.12).

> ISTR that a space is recommended (which helps human readers as
> well).

Could you be more specific about the missing space?

Also, since we close the release in a few days, I'd like to ask for
pulling this code as it is.

Those are envs related to DFU/THOR, so probably will be changed in a
near future.

> 
> 
> virtually yours
> Gerhard Sittig

Best regards,
Lukasz Majewski


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

Re: [U-Boot] [PATCH] board_r - fixup functions table after relocation

[Albert ARIBAUD]

Hi Alexey,

On Wed, 15 Jan 2014 15:19:56 +0400, Alexey Brodkin
 wrote:

> "init_sequence_r" is just an array that consists of compile-time
> adresses of init functions. Since this is basically an array of integers
> (pointers to "void" to be more precise) it won't be modified during
> relocation - it will be just copied to new location as it is.

IIRC, in ARM we switched from GOT to ELF relocation precisely so that
data would be relocated as well as code, and I think it actually is,
otherwise we'd have a lot of complains. Therefore I fail to understand
the statements above. Can someone tell me what I'm getting wrong?
 
> As a consequence on execution after relocation "initcall_run_list" will
> be jumping to pre-relocation addresses. As long as we don't overwrite
> pre-relocation memory area init calls are executed correctly. But still
> it is dangerous because after relocation we don't expect initially used
> memory to stay untouched.
> 
> Signed-off-by: Alexey Brodkin 
> 
> Cc: Tom Rini 
> Cc: Simon Glass 
> Cc: Masahiro Yamada 
> Cc: Doug Anderson 
> ---
>  common/board_r.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/common/board_r.c b/common/board_r.c
> index 86ca1cb..8f45943 100644
> --- a/common/board_r.c
> +++ b/common/board_r.c
> @@ -903,9 +903,14 @@ init_fnc_t init_sequence_r[] = {
>  
>  void board_init_r(gd_t *new_gd, ulong dest_addr)
>  {
> + int i;
>  #ifndef CONFIG_X86
>   gd = new_gd;
>  #endif
> + /* Fixup table after relocation */
> + for (i = 0; i < sizeof(init_sequence_r)/sizeof(void *); i++)
> + init_sequence_r[i] += gd->reloc_off;
> +
>   if (initcall_run_list(init_sequence_r))
>   hang();
>  


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

Re: [U-Boot] [PATCH 2/2] PPC: remove support for MPC82xx processors

[Wolfgang Denk]

Dear Holger,

In message <52d6beb7.5010...@keymile.com> you wrote:
> 
> > Do you agree with "keeping 824x" support only?
> 
> is this question adressed to myside or to Tom? From myside it's absolutely ok 
> to
> keep 824x only.

It was directed at you.  But in the meantime I've also been told that
MPC8280 is also still active (and some guys are "probably going to
continue building it for the next 10 years"), so we will keep it all,
and just throw out the offending boards.

Thanks.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
You got to learn three things. What's  real,  what's  not  real,  and
what's the difference."   - Terry Pratchett, _Witches Abroad_
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2] PPC: remove support for MPC82xx processors

[Dan Malek]

On Jan 15, 2014, at 2:11 PM, Wolfgang Denk  wrote:

> …..   so we will keep it all,
> and just throw out the offending boards.

Cool! :)  I'll have to dig out some old boards and see if they still work.

Thanks.

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

[U-Boot] Pull request v2: u-boot-sh/rmobile into u-boot-arm/master

[Nobuhiro Iwamatsu]

Dear Albert Aribaud,

Please pull u-boot-sh/rmobile into u-boot-arm/master.

"spi: sh_qspi: Add header file that defines the address of registers"
is SPI stuff.
But I have permission to take from arm repository directly from Jagan
is the maintainer of SPI.

The following changes since commit bf46e7d8d134521301ff02b6d97e8998aa10a83d:

  Merge branch 'u-boot-imx/master' into 'u-boot-arm/master'
(2014-01-15 15:18:04 +0100)

are available in the git repository at:


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

for you to fetch changes up to c71b4dd2da0dcddabd7c29e6c3dc8a495d4bd928:

  arm: koelsch: Add support QSPI device and enable boot from SPI flash
(2014-01-16 08:07:20 +0900)


Nobuhiro Iwamatsu (6):
  arm: koelsch: Disable TMU0 before OS boot
  arm: lager: Disable TMU0 before OS boot
  arm: rmobile: Add SH QSPI base register address
  spi: sh_qspi: Add header file that defines the address of registers
  arm: lager: Add support QSPI device and enable boot from SPI flash
  arm: koelsch: Add support QSPI device and enable boot from SPI flash

 arch/arm/include/asm/arch-rmobile/r8a7790.h |  1 +
 arch/arm/include/asm/arch-rmobile/r8a7791.h |  1 +
 board/renesas/koelsch/koelsch.c |  6 ++
 board/renesas/lager/lager.c |  6 ++
 drivers/spi/sh_qspi.c   |  3 ++-
 include/configs/koelsch.h   | 32

 include/configs/lager.h | 33
+


-- 
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

Re: [U-Boot] [PATCH 1/2] doc/README.scrapyard: update commit IDs, use TAB for indentation

[Masahiro Yamada]

Hello Wolfgang,


> > Why did you insert TABs here?
> 
> Because it requires less typing when adding new entries.

I do understand you want to use TABs for indentation.
But I don't understand why you want to use them in the
comment block. I think the part will not be changed often.
I'm talking about a TAB between
" U-Boot source tree." and "The remainders rest"

> -be removed from the U-Boot source tree.  The remainders rest in piece
> -in the imperishable depths of the git history.  This document tries to
> +be removed from the U-Boot source tree.   The remainders rest in piece
> +in the imperishable depths of the git history.   This document tries to

I mean, here.





> > You are using TABs and SPACEs mixed-up.
> 
> Correct.  I decided to go for a minimal-invasive change that would not
> result in some very long lines.  So most columns are aligned by TAG,
> and two of them by TAB + 4 x SPACE.

Makes sense.

> > If you do this refactoring, I'd like to request that only TABs are used
> > consistently.
> 
> I can do this - but then, this will result in very long lines.  Do you
> prefer that?

No. Shorter lines are better.
You are right.
(But I a little afraid someone who does not understand "TAB + 4 SPACE"
rule might break the format.)


Best Regards
Masahiro Yamada

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

Re: [U-Boot] [PATCH] arm64 patch: gicv3 support

[FengHua]

hi bhupesh,


> -Original Messages-
> From: "bhupesh.sha...@freescale.com" 
> Sent Time: 2014-01-15 22:19:02 (Wednesday)
> To: "'feng...@phytium.com.cn'" , 
> "u-boot@lists.denx.de" 
> Cc: "tr...@ti.com" , "arnab.b...@freescale.com" 
> 
> Subject: RE: [U-Boot] [PATCH] arm64 patch: gicv3 support
> 
> Hi David,
> 
> Thanks for the patch.
> Please see some comments inline:
> 
> > -Original Message-
> > From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de]
> > On Behalf Of feng...@phytium.com.cn
> > Sent: Wednesday, January 15, 2014 1:41 PM
> > To: u-boot@lists.denx.de
> > Cc: tr...@ti.com
> > Subject: [U-Boot] [PATCH] arm64 patch: gicv3 support
> > 
> > From: David Feng 
> > 
> > This patch add gicv3 support to uboot armv8 platform.
> > Modifications cover 4 source files, as follows:
> >   gic.S: gicv3 initialization and sgi interrupt raising.
> >   goc.h: gicv3 register definitions.
> 
>   ^^^
> Typo - gic.h
> 
> >   vexpress_aemv8a.h: add CONFIG_GICV2/CONFIG_GICV3 switch.
> >   start.S: set SCR_EL3.NS bit to 1, gicv3 register of ICC_SRE_EL2
> >could be accessed only when SCR_EL3.NS=1.
> >set SCR_EL3.IRQ|FIQ|EA bits, reroute all interrupts to
> >el3 at all cores, slaves could be waken up by interrupt
> >only when the interrupt is routed to it when running
> >at el3.
> 
> Hmmm. This seems a bit suspicious - if we reroute even IRQs and Aborts
> to the cores which work in EL3, they will not be visible to Linux or
> Hypervisor which work in EL2 or EL1.
> 
These bits will be cleared when jumping to el2.

> Have you tried to launch linux on the ARMv8 foundation model v2 with these 
> changes?
> 
Yes.

> > Note: please use the latest gcc 4.8 compiler from linaro
> >   which support gicv3 system register assembling.
> >
> 
> Two generic comments :
> 
> - I see in the Foundation model README that the optional GICv3 is supported
> with memory-mapped CPU interface and distributor, but I see your patch 
> accessing them
> via the sytem register interface (via msr and mrs). Is this a BUG in the 
> README?
> 
The document did not describe it clearly, but actually it support.

> Did you check this patch on the latest ARMv8 foundation model - v2?
> 
Yes.

> - Also how about sharing the GICv2 coding between ARMv7 and ARMv8 - some of 
> the code
> may seems like a duplication from the ARMv7 GICv2 content.
>  
Many codes could be shared between armv7 and armv8 such as cache maintenance 
and gic.
These need be rearranged seriously. We'd better wait a period of time before 
the armv8 codes
are more widely acquainted and get more feedback about this.

> > Signed-off-by: David Feng 
> > ---
> >  arch/arm/cpu/armv8/gic.S  |   84
> > -
> >  arch/arm/cpu/armv8/start.S|5 ++-
> >  arch/arm/include/asm/gic.h|   56 +
> >  include/configs/vexpress_aemv8a.h |7 
> >  4 files changed, 150 insertions(+), 2 deletions(-)
> > 
> > diff --git a/arch/arm/cpu/armv8/gic.S b/arch/arm/cpu/armv8/gic.S index
> > 599aa8f..a08939a 100644
> > --- a/arch/arm/cpu/armv8/gic.S
> > +++ b/arch/arm/cpu/armv8/gic.S
> > @@ -23,6 +23,74 @@
> >   *
> > 
> > *
> > /
> >  WEAK(gic_init)
> > +#if defined(CONFIG_GICV3)
> > +   branch_if_slave x0, 3f
> > +
> > +   /* Initialize Distributor */
> > +   ldr x1, =GICD_BASE
> > +   mov w0, #0x37   /* EnableGrp0 | EnableGrp1NS */
> > +   /* EnableGrp1S | ARE_S | ARE_NS */
> > +   str w0, [x1, GICD_CTLR] /* Secure GICD_CTLR */
> > +   ldr w0, [x1, GICD_TYPER]
> > +   and w2, w0, #0x1f   /* ITLinesNumber */
> > +   cbz w2, 1f  /* No SPIs */
> > +   add x3, x1, (GICD_IGROUPRn + 4)
> > +   add x4, x1, (GICD_IGROUPMODRn + 4)
> > +   mov w5, #~0
> > +0: str w5, [x3], #0x4
> > +   str wzr, [x4], #0x4 /* Config SPIs as Group1NS */
> > +   sub w2, w2, #0x1
> > +   cbnzw2, 0b
> > +
> > +   /* Initialize All ReDistributors */
> > +1: ldr x1, =GICR_BASE
> > +2: mov w0, #~0x2
> > +   ldr w2, [x1, GICR_WAKER]
> > +   and w2, w2, w0  /* Clear ProcessorSleep */
> > +   str w2, [x1, GICR_WAKER]
> > +   dsb st
> > +   isb
> > +0: ldr w0, [x1, GICR_WAKER]
> > +   tbnzw0, #2, 0b  /* Wait Children be Alive */
> > +
> > +   add x2, x1, #(1 << 16)  /* SGI_Base */
> > +   mov w5, #~0
> > +   str w5, [x2, GICR_IGROUPRn]
> > +   str wzr, [x2, GICR_IGROUPMODRn] /* SGIs|PPIs Group1NS */
> > +   mov w0, #0x1/* Enable SGI 0 */
> > +   str w0, [x2, GICR_ISENABLERn]
> > +
> > +   ldr w0, [x1, GICR_TYPER]
> > +   add x1, x1, #(2 << 16)
> > +   tbz w0, #4, 2b  /* Next ReDistributor if Exist */
> > +
> > +   /* Initialize Cpu Interface */
>

[U-Boot] [PATCH v3] powerpc: mpc5xxx: remove redundant CONFIG_MPC5xxx definition

[Masahiro Yamada]

We do not have to define CONFIG_MPC5xxx in board config headers
(and start.S) because it is defined in arch/powerpc/cpu/mpc5xxx/config.mk.

Signed-off-by: Masahiro Yamada 
---

Changes in v3:
  - Change also the comments following the deleted lines

Changes in v2:
  - Fix a typo in the subject:  s/redandant/redundant/

 arch/powerpc/cpu/mpc5xxx/start.S   | 2 --
 include/configs/BC3450.h   | 3 +--
 include/configs/IceCube.h  | 3 +--
 include/configs/MVBC_P.h   | 1 -
 include/configs/MVSMR.h| 1 -
 include/configs/PM520.h| 3 +--
 include/configs/TB5200.h   | 3 +--
 include/configs/TOP5200.h  | 3 +--
 include/configs/TQM5200.h  | 3 +--
 include/configs/Total5200.h| 3 +--
 include/configs/a3m071.h   | 3 +--
 include/configs/a4m072.h   | 3 +--
 include/configs/aev.h  | 3 +--
 include/configs/canmb.h| 3 +--
 include/configs/cm5200.h   | 3 +--
 include/configs/cpci5200.h | 3 +--
 include/configs/digsy_mtc.h| 3 +--
 include/configs/galaxy5200.h   | 3 +--
 include/configs/hmi1001.h  | 5 ++---
 include/configs/inka4x0.h  | 5 ++---
 include/configs/ipek01.h   | 5 ++---
 include/configs/jupiter.h  | 3 +--
 include/configs/manroland/mpc5200-common.h | 3 +--
 include/configs/mcc200.h   | 3 +--
 include/configs/mecp5200.h | 3 +--
 include/configs/motionpro.h| 3 +--
 include/configs/munices.h  | 3 +--
 include/configs/o2dnt-common.h | 1 -
 include/configs/pcm030.h   | 3 +--
 include/configs/pf5200.h   | 3 +--
 include/configs/v38b.h | 1 -
 31 files changed, 29 insertions(+), 61 deletions(-)

diff --git a/arch/powerpc/cpu/mpc5xxx/start.S b/arch/powerpc/cpu/mpc5xxx/start.S
index 84ab41e..02c706e 100644
--- a/arch/powerpc/cpu/mpc5xxx/start.S
+++ b/arch/powerpc/cpu/mpc5xxx/start.S
@@ -14,8 +14,6 @@
 #include 
 #include 
 
-#define CONFIG_MPC5xxx 1   /* needed for Linux kernel header files */
-
 #include 
 #include 
 
diff --git a/include/configs/BC3450.h b/include/configs/BC3450.h
index 377db7b..802e9cc 100644
--- a/include/configs/BC3450.h
+++ b/include/configs/BC3450.h
@@ -22,8 +22,7 @@
 /*
  * High Level Configuration Options
  */
-#define CONFIG_MPC5xxx 1   /* This is an MPC5xxx CPU   */
-#define CONFIG_MPC5200 1   /* (more precisely a MPC5200 CPU)   */
+#define CONFIG_MPC5200 1   /* This is a MPC5200 CPU*/
 #define CONFIG_TQM5200 1   /* ... on a TQM5200 module  */
 
 #define CONFIG_BC3450  1   /* ... on a BC3450 mainboard*/
diff --git a/include/configs/IceCube.h b/include/configs/IceCube.h
index 52368f8..1861aa8 100644
--- a/include/configs/IceCube.h
+++ b/include/configs/IceCube.h
@@ -13,8 +13,7 @@
  * (easy to change)
  */
 
-#define CONFIG_MPC5xxx 1   /* This is an MPC5xxx CPU */
-#define CONFIG_MPC5200 1   /* (more precisely a MPC5200 CPU) */
+#define CONFIG_MPC5200 1   /* This is a MPC5200 CPU */
 #define CONFIG_ICECUBE 1   /* ... on IceCube board */
 
 /*
diff --git a/include/configs/MVBC_P.h b/include/configs/MVBC_P.h
index 9d49de7..99e4e90 100644
--- a/include/configs/MVBC_P.h
+++ b/include/configs/MVBC_P.h
@@ -13,7 +13,6 @@
 
 #include 
 
-#define CONFIG_MPC5xxx 1
 #define CONFIG_MPC5200 1
 
 #ifndef CONFIG_SYS_TEXT_BASE
diff --git a/include/configs/MVSMR.h b/include/configs/MVSMR.h
index f69b9a8..bb565b6 100644
--- a/include/configs/MVSMR.h
+++ b/include/configs/MVSMR.h
@@ -13,7 +13,6 @@
 
 #include 
 
-#define CONFIG_MPC5xxx 1
 #define CONFIG_MPC5200 1
 
 #ifndef CONFIG_SYS_TEXT_BASE
diff --git a/include/configs/PM520.h b/include/configs/PM520.h
index 557a8ba..de46216 100644
--- a/include/configs/PM520.h
+++ b/include/configs/PM520.h
@@ -14,8 +14,7 @@
  */
 
 #define CONFIG_MPC5200
-#define CONFIG_MPC5xxx 1   /* This is an MPC5xxx CPU */
-#define CONFIG_PM520   1   /* ... on PM520 board */
+#define CONFIG_PM520   1   /* PM520 board */
 
 #defineCONFIG_SYS_TEXT_BASE0xfff0
 
diff --git a/include/configs/TB5200.h b/include/configs/TB5200.h
index 90f7fc4..b4daedc 100644
--- a/include/configs/TB5200.h
+++ b/include/configs/TB5200.h
@@ -16,8 +16,7 @@
  * (easy to change)
  */
 
-#define CONFIG_MPC5xxx 1   /* This is an MPC5xxx CPU */
-#define CONFIG_MPC5200 1   /* (more precisely an MPC5200 CPU) */
+#define CONFIG_MPC5200 1   /* This is an MPC5200 CPU */
 #define CONFIG_TQM5200 1   /* ... on TQM5200 module */
 #define CONFIG_TB5200  1   /* ... on a TB5200 base board */
 

[U-Boot] [PATCH] cosmetic: uImage.FIT: fix documents

[Masahiro Yamada]

  - Fix the path to source_file_format.txt
  - Fix a minor typo
  - Fix the type for FIT blob: it must be "flat_dt"

Signed-off-by: Masahiro Yamada 
---
 doc/uImage.FIT/howto.txt  | 6 +++---
 doc/uImage.FIT/source_file_format.txt | 2 +-
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/doc/uImage.FIT/howto.txt b/doc/uImage.FIT/howto.txt
index 59e21e9..526be55 100644
--- a/doc/uImage.FIT/howto.txt
+++ b/doc/uImage.FIT/howto.txt
@@ -20,8 +20,8 @@ www.jdl.com for its latest version. mkimage (together with 
dtc) takes as input
 an image source file, which describes the contents of the image and defines
 its various properties used during booting. By convention, image source file
 has the ".its" extension, also, the details of its format are given in
-doc/source_file_format.txt. The actual data that is to be included in the
-uImage (kernel, ramdisk, etc.) is specified in the image source file in the
+doc/uImage.FIT/source_file_format.txt. The actual data that is to be included 
in
+the uImage (kernel, ramdisk, etc.) is specified in the image source file in the
 form of paths to appropriate data files. The outcome of the image creation
 process is a binary file (by convention with the ".itb" extension) that
 contains all the referenced data (kernel, ramdisk, etc.) and other information
@@ -39,7 +39,7 @@ Here's a graphical overview of the image creation and booting 
process:
 
 image source file mkimage + dtc  transfer to target
+---> image file > bootm
-image data files(s)
+image data file(s)
 
 
 Example 1 -- old-style (non-FDT) kernel booting
diff --git a/doc/uImage.FIT/source_file_format.txt 
b/doc/uImage.FIT/source_file_format.txt
index 160b2d0..9ed6f65 100644
--- a/doc/uImage.FIT/source_file_format.txt
+++ b/doc/uImage.FIT/source_file_format.txt
@@ -159,7 +159,7 @@ the '/images' node should have the following layout:
   - description : Textual description of the component sub-image
   - type : Name of component sub-image type, supported types are:
 "standalone", "kernel", "ramdisk", "firmware", "script", "filesystem",
-"fdt".
+"flat_dt".
   - data : Path to the external file which contains this node's binary data.
   - compression : Compression used by included data. Supported compressions
 are "gzip" and "bzip2". If no compression is used compression property
-- 
1.8.3.2

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

Re: [U-Boot] [PATCH v2] powerpc: mpc5xxx: remove redundant CONFIG_MPC5xxx definition

[Masahiro Yamada]

Hello Gerhard,


> >   * High Level Configuration Options
> >   */
> > -#define CONFIG_MPC5xxx 1   /* This is an MPC5xxx CPU   
> > */
> >  #define CONFIG_MPC5200 1   /* (more precisely a MPC5200 
> > CPU)   */
> >  #define CONFIG_TQM5200 1   /* ... on a TQM5200 module  
> > */
> >  
> 
> Haven't checked all of the patch, just by coincidence spotted
> this one.  The removal of one of the preprocessor lines loses
> information in the right hand side comment.  After the patch the
> remaining text looks odd.

Good find!

I posted v3.

I also checked the others and I think this is the only one to be fixed.

Best Regards
Masahiro Yamada

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

Re: [U-Boot] [PATCH 2/2] PPC: remove support for MPC82xx processors

[Scott Wood]

On Wed, 2014-01-15 at 12:04 +0100, Wolfgang Denk wrote:
> Dear Holger,
> 
> In message <52d64089.6070...@keymile.com> you wrote:
> > 
> > > This commit removes support for the Freescale MPC82xx Power
> > > Architecture processors, i. e. MPC8240, MPC8245, MPC8247, MPC8248,
> > > MPC8250, MPC8255, MPC8260, MPC8265, MPC8266, MPC8272, MPC8280, ...
> > > 
> > > They have been out of production for years, and no active users left
> > > here.  As some boards start causing problems, let's drop the obsolete
> > > and now dead code.
> > 
> > thats not valid for us. Our mgcoge3ne target which comes with a MPC8247 is 
> > still
> > in production and maintained. If you look at the git log of
> 
> Argh... Can you foresee how much longer this hardware is likely to be
> maintained?
> 
> > So isn't it possible to remove only the broken boards and keep the generic 
> > parts?
> 
> Yes, this would be possible, too.  But then, it appears you are the
> only remaining active user of MPC82xx.  OK, MPC8247 is actually still
> marked as "active" at Freescale, soory I missed that - the MPC824x
> types I checked were in "No Longer Manufactured" state.

I see plenty of mpc82xx listed as active on freescale.com, e.g.:
http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=MPC8272&tab=Buy_Parametric_Tab&lang_cd=
http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=MPC8280&tab=Buy_Parametric_Tab&lang_cd=
http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=MPC8248&tab=Buy_Parametric_Tab&lang_cd=
http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=MPC8245&tab=Buy_Parametric_Tab&lang_cd=

Likewise for 8xx.

It does appear that MPC8240 is "No Longer Manufactured" and MPC8241 is
"Not Recommended for New Design".

Of course, whether a particular piece of code has anyone willing to
maintain it is a separate question.

-Scott


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

Re: [U-Boot] [PATCH] arm64 patch: gicv3 support

[bhupesh.sha...@freescale.com]

> -Original Message-
> From: FengHua [mailto:feng...@phytium.com.cn]
> Sent: Thursday, January 16, 2014 6:47 AM
> To: Sharma Bhupesh-B45370
> Cc: u-boot@lists.denx.de; tr...@ti.com; Basu Arnab-B45036
> Subject: Re: RE: [U-Boot] [PATCH] arm64 patch: gicv3 support
> 
> 
> hi bhupesh,
> 
> 
> > -Original Messages-
> > From: "bhupesh.sha...@freescale.com" 
> > Sent Time: 2014-01-15 22:19:02 (Wednesday)
> > To: "'feng...@phytium.com.cn'" ,
> > "u-boot@lists.denx.de" 
> > Cc: "tr...@ti.com" , "arnab.b...@freescale.com"
> > 
> > Subject: RE: [U-Boot] [PATCH] arm64 patch: gicv3 support
> >
> > Hi David,
> >
> > Thanks for the patch.
> > Please see some comments inline:
> >
> > > -Original Message-
> > > From: u-boot-boun...@lists.denx.de
> > > [mailto:u-boot-boun...@lists.denx.de]
> > > On Behalf Of feng...@phytium.com.cn
> > > Sent: Wednesday, January 15, 2014 1:41 PM
> > > To: u-boot@lists.denx.de
> > > Cc: tr...@ti.com
> > > Subject: [U-Boot] [PATCH] arm64 patch: gicv3 support
> > >
> > > From: David Feng 
> > >
> > > This patch add gicv3 support to uboot armv8 platform.
> > > Modifications cover 4 source files, as follows:
> > >   gic.S: gicv3 initialization and sgi interrupt raising.
> > >   goc.h: gicv3 register definitions.
> >
> > ^^^
> > Typo - gic.h
> >
> > >   vexpress_aemv8a.h: add CONFIG_GICV2/CONFIG_GICV3 switch.
> > >   start.S: set SCR_EL3.NS bit to 1, gicv3 register of ICC_SRE_EL2
> > >could be accessed only when SCR_EL3.NS=1.
> > >set SCR_EL3.IRQ|FIQ|EA bits, reroute all interrupts to
> > >el3 at all cores, slaves could be waken up by interrupt
> > >only when the interrupt is routed to it when running
> > >at el3.
> >
> > Hmmm. This seems a bit suspicious - if we reroute even IRQs and Aborts
> > to the cores which work in EL3, they will not be visible to Linux or
> > Hypervisor which work in EL2 or EL1.
> >
> These bits will be cleared when jumping to el2.

I seem to be missing this clear operation in your patch. Can you please point 
me to the same.

> > Have you tried to launch linux on the ARMv8 foundation model v2 with
> these changes?
> >
> Yes.

But I thought we still don't have GICv3 driver in Linux. So did you boot linux 
with GICv2 or GICv3?

> 
> > > Note: please use the latest gcc 4.8 compiler from linaro
> > >   which support gicv3 system register assembling.
> > >
> >
> > Two generic comments :
> >
> > - I see in the Foundation model README that the optional GICv3 is
> > supported with memory-mapped CPU interface and distributor, but I see
> > your patch accessing them via the sytem register interface (via msr and
> mrs). Is this a BUG in the README?
> >
> The document did not describe it clearly, but actually it support.

So this seems to be a documentation BUG, did you provide a feedback to the ARM 
support folks regarding the same
- they should probably fix the documentation.
 
> > Did you check this patch on the latest ARMv8 foundation model - v2?
> >
> Yes.
> 
> > - Also how about sharing the GICv2 coding between ARMv7 and ARMv8 -
> > some of the code may seems like a duplication from the ARMv7 GICv2
> content.
> >
> Many codes could be shared between armv7 and armv8 such as cache
> maintenance and gic.
> These need be rearranged seriously. We'd better wait a period of time
> before the armv8 codes are more widely acquainted and get more feedback
> about this.

I agree about the ARMv7/v8 code sharing, but with GICv3 there is an additional 
problem - it can be configured as 
GICv2 as well and for the same it would make sense to move common code b/w the 
CONFIG_GICV2/CONFIG_GICV3 code legs
to a common leg.

> 
> > > Signed-off-by: David Feng 
> > > ---
> > >  arch/arm/cpu/armv8/gic.S  |   84
> > > -
> > >  arch/arm/cpu/armv8/start.S|5 ++-
> > >  arch/arm/include/asm/gic.h|   56 +
> > >  include/configs/vexpress_aemv8a.h |7 
> > >  4 files changed, 150 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/arch/arm/cpu/armv8/gic.S b/arch/arm/cpu/armv8/gic.S
> > > index 599aa8f..a08939a 100644
> > > --- a/arch/arm/cpu/armv8/gic.S
> > > +++ b/arch/arm/cpu/armv8/gic.S
> > > @@ -23,6 +23,74 @@
> > >   *
> > >
> > > 
> > > *
> > > /
> > >  WEAK(gic_init)
> > > +#if defined(CONFIG_GICV3)
> > > + branch_if_slave x0, 3f
> > > +
> > > + /* Initialize Distributor */
> > > + ldr x1, =GICD_BASE
> > > + mov w0, #0x37   /* EnableGrp0 | EnableGrp1NS */
> > > + /* EnableGrp1S | ARE_S | ARE_NS */
> > > + str w0, [x1, GICD_CTLR] /* Secure GICD_CTLR */
> > > + ldr w0, [x1, GICD_TYPER]
> > > + and w2, w0, #0x1f   /* ITLinesNumber */
> > > + cbz w2, 1f  /* No SPIs */
> > > + add x3, x1, (GICD_IGROUPRn + 4)
> > > + add x4, x1, (GICD_IGROUPMODRn +

Re: [U-Boot] [PATCH V4 5/6] exynos: Add a common DT based PMIC driver initialization

[Leela Krishna Amudala]

Hi Minkyu Kang,

Thanks for reviewing the patch, Please check my comments inline.

On 1/7/14, Minkyu Kang  wrote:
> On 06/01/14 20:49, Leela Krishna Amudala wrote:
>> Most of i2c PMIC drivers follow the same initialization sequence,
>> let's generalize it in a common file.
>>
>> The initialization function finds the PMIC in the device tree, and if
>> found - registers it in the list of known PMICs and initializes it,
>> iterating through the table of settings supplied by the caller.
>>
>> Signed-off-by: Vadim Bendebury 
>> Signed-off-by: Leela Krishna Amudala 
>> Reviewed-by: Doug Anderson 
>> Acked-by: Simon Glass 
>> ---
>>  board/samsung/common/board.c |   22 +
>>  drivers/power/pmic/Makefile  |1 +
>>  drivers/power/pmic/pmic_common.c |   97
>> ++
>>  drivers/power/power_core.c   |   14 ++
>>  include/power/pmic.h |   34 +
>>  5 files changed, 168 insertions(+)
>>  create mode 100644 drivers/power/pmic/pmic_common.c
>>
>> diff --git a/board/samsung/common/board.c b/board/samsung/common/board.c
>> index b3b84c1..d23a7a6 100644
>> --- a/board/samsung/common/board.c
>> +++ b/board/samsung/common/board.c
>> @@ -23,6 +23,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>
> Do we need to include those two header files (max77686 and s2mps11)
> together?
>

Okay, I'll make it conditional inclusion

>>
>>  DECLARE_GLOBAL_DATA_PTR;
>>
>> @@ -160,6 +161,25 @@ static int board_init_cros_ec_devices(const void
>> *blob)
>>  }
>>  #endif
>>
>> +#ifdef CONFIG_POWER_S2MPS11
>
> please move this block into "#if defined(CONFIG_POWER)".
>

Okay, will move it

>> +int board_init_s2mps11(void)
>> +{
>> +const struct pmic_init_ops pmic_ops[] = {
>> +{PMIC_REG_WRITE, S2MPS11_BUCK1_CTRL2, S2MPS11_BUCK_CTRL2_1V},
>> +{PMIC_REG_WRITE, S2MPS11_BUCK2_CTRL2,
>> +S2MPS11_BUCK_CTRL2_1_2625V},
>> +{PMIC_REG_WRITE, S2MPS11_BUCK3_CTRL2, S2MPS11_BUCK_CTRL2_1V},
>> +{PMIC_REG_WRITE, S2MPS11_BUCK4_CTRL2, S2MPS11_BUCK_CTRL2_1V},
>> +{PMIC_REG_WRITE, S2MPS11_BUCK6_CTRL2, S2MPS11_BUCK_CTRL2_1V},
>> +{PMIC_REG_UPDATE, S2MPS11_REG_RTC_CTRL,
>> +S2MPS11_RTC_CTRL_32KHZ_CP_EN | S2MPS11_RTC_CTRL_JIT},
>> +{PMIC_REG_BAIL}
>> +};
>> +
>> +return pmic_common_init(COMPAT_SAMSUNG_S2MPS11_PMIC, pmic_ops);
>> +}
>> +#endif
>> +
>>  #if defined(CONFIG_POWER)
>>  #ifdef CONFIG_POWER_MAX77686
>>  static int max77686_init(void)
>> @@ -263,6 +283,8 @@ int power_init_board(void)
>>
>>  #ifdef CONFIG_POWER_MAX77686
>>  ret = max77686_init();
>> +#elif defined(CONFIG_POWER_S2MPS11)
>> +ret = board_init_s2mps11();
>>  #endif
>>
>>  return ret;
>> diff --git a/drivers/power/pmic/Makefile b/drivers/power/pmic/Makefile
>> index 0b45ffa..5e236a3 100644
>> --- a/drivers/power/pmic/Makefile
>> +++ b/drivers/power/pmic/Makefile
>> @@ -11,3 +11,4 @@ obj-$(CONFIG_POWER_MUIC_MAX8997) += muic_max8997.o
>>  obj-$(CONFIG_POWER_MAX77686) += pmic_max77686.o
>>  obj-$(CONFIG_POWER_TPS65217) += pmic_tps65217.o
>>  obj-$(CONFIG_POWER_TPS65910) += pmic_tps65910.o
>> +obj-$(CONFIG_POWER) += pmic_common.o
>> diff --git a/drivers/power/pmic/pmic_common.c
>> b/drivers/power/pmic/pmic_common.c
>> new file mode 100644
>> index 000..3117ae2
>> --- /dev/null
>> +++ b/drivers/power/pmic/pmic_common.c
>> @@ -0,0 +1,97 @@
>> +/*
>> + * Copyright (c) 2013 The Chromium OS Authors. All rights reserved.
>
> Please write on the author of this file.
>

Okay, will do that

>> + *
>> + * SPDX-License-Identifier: GPL-2.0+
>> + */
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>
> Why common driver need specific pmic's header file?
> It is wrong architecture.
>

Here, in this file we are using PMIC compact ID to find the number of
registers in a PMIC (now currently have support for only S2MPS11 and
other PMICs info may added in future), so we need those headers.

>> +
>> +DECLARE_GLOBAL_DATA_PTR;
>> +
>> +static unsigned pmic_number_of_regs(enum fdt_compat_id pmic_compat)
>> +{
>> +switch (pmic_compat) {
>> +case COMPAT_SAMSUNG_S2MPS11_PMIC:
>> +return S2MPS11_NUM_OF_REGS;
>> +default:
>> +break;
>> +}
>> +return 0;
>> +}
>> +
>> +int pmic_common_init(enum fdt_compat_id pmic_compat,
>> + const struct pmic_init_ops *pmic_ops)
>> +{
>> +const void *blob = gd->fdt_blob;
>> +struct pmic *p;
>> +int node, parent, ret;
>> +unsigned number_of_regs = pmic_number_of_regs(pmic_compat);
>> +const char *pmic_name, *comma;
>> +
>> +if (!number_of_regs) {
>> +printf("%s: %s - not a supported PMIC\n",
>> +   __func__, fdtdec_get_compatible(pmic_compat));
>> +return -1;
>> +}
>> +
>> +node = fdtdec_next_compatible(blob, 0, pmic_compat);
>> +if (node < 0) {
>> +debug("PMIC: Error %s. No node 

Re: [U-Boot] [PATCH V4 6/6] config: SMDK5420: Enable S2MPS11 pmic

[Leela Krishna Amudala]

Hi Minkyu Kang,

On 1/7/14, Minkyu Kang  wrote:
> On 06/01/14 20:49, Leela Krishna Amudala wrote:
>> configure S2MPS11 pmic on SMDK5420
>>
>> Signed-off-by: Leela Krishna Amudala 
>> Acked-by: Simon Glass 
>> ---
>>  include/configs/smdk5420.h |4 
>>  1 file changed, 4 insertions(+)
>>
>> diff --git a/include/configs/smdk5420.h b/include/configs/smdk5420.h
>> index 447f8e5..46aeec0 100644
>> --- a/include/configs/smdk5420.h
>> +++ b/include/configs/smdk5420.h
>> @@ -53,4 +53,8 @@
>>
>>  #define CONFIG_MAX_I2C_NUM  11
>>
>> +#define CONFIG_POWER
>> +#define CONFIG_POWER_I2C
>
> already defined at exynos5-dt.h
>

Okay, will remove it.

>> +#define CONFIG_POWER_S2MPS11
>> +
>>  #endif  /* __CONFIG_5420_H */
>>
>
> Thanks,
> Minkyu Kang.
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] vexpress/armv8: Fix incorrect ethernet controller

[Bhupesh Sharma]

This patch enables ethernet support in ARMv8 foundation model. The ARMv8
foundation model supports a SMSC91C111 integrated MAC and PHY module
which is present at base address 0x01A00.

The previous implementation had enabled SMSC9115 ethernet controller
which is not present on the ARMv8 foundation model.

Tested on ARMv8 foundation model v1 and v2 by running ping/tftp
between the foundation model and the host PC via a bridged network.

Signed-off-by: Bhupesh Sharma 
---
To test the ethernet functionality on a ARMv8 foundation model:

- Launch the model with BRIDGED networking option:
--network=bridged

- This will create an ethernet interface (eth0) inside the model and
  an interface ARM0 on the Host PC.

- Assign appropriate IP addresses:
~ On Host:
$ ifconfig ARM0 10.10.10.11
~ On foundation model:
VExpress# setenv ipaddr 10.10.10.10
VExpress# setenv gatewayip 10.10.10.11
VExpress# setenv serverip 10.10.10.11

- Now try out ping/tftp tests.

 include/configs/vexpress_aemv8a.h |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/configs/vexpress_aemv8a.h 
b/include/configs/vexpress_aemv8a.h
index ce5f384..e851702 100644
--- a/include/configs/vexpress_aemv8a.h
+++ b/include/configs/vexpress_aemv8a.h
@@ -102,9 +102,9 @@
 /* Size of malloc() pool */
 #define CONFIG_SYS_MALLOC_LEN  (CONFIG_ENV_SIZE + 128 * 1024)
 
-/* SMSC9115 Ethernet from SMSC9118 family */
-#define CONFIG_SMC9111 1
-#define CONFIG_SMC9111_BASE(0x1a00)
+/* SMSC91C111 Ethernet Configuration */
+#define CONFIG_SMC91
+#define CONFIG_SMC9_BASE   (0x01A00)
 
 /* PL011 Serial Configuration */
 #define CONFIG_PL011_SERIAL
-- 
1.7.10.4


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

Re: [U-Boot] [PATCH V4 5/6] exynos: Add a common DT based PMIC driver initialization

[Minkyu Kang]

On 16/01/14 13:05, Leela Krishna Amudala wrote:
> Hi Minkyu Kang,
> 
> Thanks for reviewing the patch, Please check my comments inline.
> 
> On 1/7/14, Minkyu Kang  wrote:
>> On 06/01/14 20:49, Leela Krishna Amudala wrote:
>>> Most of i2c PMIC drivers follow the same initialization sequence,
>>> let's generalize it in a common file.
>>>
>>> The initialization function finds the PMIC in the device tree, and if
>>> found - registers it in the list of known PMICs and initializes it,
>>> iterating through the table of settings supplied by the caller.
>>>
>>> Signed-off-by: Vadim Bendebury 
>>> Signed-off-by: Leela Krishna Amudala 
>>> Reviewed-by: Doug Anderson 
>>> Acked-by: Simon Glass 
>>> ---
>>>  board/samsung/common/board.c |   22 +
>>>  drivers/power/pmic/Makefile  |1 +
>>>  drivers/power/pmic/pmic_common.c |   97
>>> ++
>>>  drivers/power/power_core.c   |   14 ++
>>>  include/power/pmic.h |   34 +
>>>  5 files changed, 168 insertions(+)
>>>  create mode 100644 drivers/power/pmic/pmic_common.c
>>>
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>
>> Why common driver need specific pmic's header file?
>> It is wrong architecture.
>>
> 
> Here, in this file we are using PMIC compact ID to find the number of
> registers in a PMIC (now currently have support for only S2MPS11 and
> other PMICs info may added in future), so we need those headers.

So, it's a wrong architecture.
It (find the number of registers) is a PMIC specific feature.

> 
>>> +
>>> +DECLARE_GLOBAL_DATA_PTR;
>>> +
>>> +static unsigned pmic_number_of_regs(enum fdt_compat_id pmic_compat)

As I said, this function is not a common feature.

>>> +{
>>> +   switch (pmic_compat) {
>>> +   case COMPAT_SAMSUNG_S2MPS11_PMIC:
>>> +   return S2MPS11_NUM_OF_REGS;
>>> +   default:
>>> +   break;
>>> +   }
>>> +   return 0;
>>> +}
>>> +
>>> +int pmic_common_init(enum fdt_compat_id pmic_compat,
>>> +const struct pmic_init_ops *pmic_ops)
>>> +{
>>> +   const void *blob = gd->fdt_blob;
>>> +   struct pmic *p;
>>> +   int node, parent, ret;
>>> +   unsigned number_of_regs = pmic_number_of_regs(pmic_compat);
>>> +   const char *pmic_name, *comma;
>>> +
>>> +   if (!number_of_regs) {
>>> +   printf("%s: %s - not a supported PMIC\n",
>>> +  __func__, fdtdec_get_compatible(pmic_compat));
>>> +   return -1;
>>> +   }
>>> +
>>> +   node = fdtdec_next_compatible(blob, 0, pmic_compat);
>>> +   if (node < 0) {
>>> +   debug("PMIC: Error %s. No node for %s in device tree\n",
>>> + fdt_strerror(node), fdtdec_get_compatible(pmic_compat));
>>> +   return node;
>>> +   }
>>> +
>>> +   pmic_name = fdtdec_get_compatible(pmic_compat);
>>> +   comma = strchr(pmic_name, ',');
>>> +   if (comma)
>>> +   pmic_name = comma + 1;
>>> +
>>> +   p = pmic_alloc();
>>> +
>>> +   if (!p) {
>>> +   printf("%s: POWER allocation error!\n", __func__);
>>> +   return -ENOMEM;
>>> +   }
>>> +   parent = fdt_parent_offset(blob, node);
>>> +   if (parent < 0) {
>>> +   debug("%s: Cannot find node parent\n", __func__);
>>> +   return -1;
>>> +   }
>>> +
>>> +   p->bus = i2c_get_bus_num_fdt(parent);
>>> +   if (p->bus < 0) {
>>> +   debug("%s: Cannot find I2C bus\n", __func__);
>>> +   return -1;
>>> +   }
>>> +   p->hw.i2c.addr = fdtdec_get_int(blob, node, "reg", 9);
>>> +
>>> +   p->name = pmic_name;
>>> +   p->interface = PMIC_I2C;
>>> +   p->hw.i2c.tx_num = 1;
>>> +   p->number_of_regs = number_of_regs;
>>> +   p->compat_id = pmic_compat;
>>> +
>>> +   ret = 0;
>>> +   while ((pmic_ops->reg_op != PMIC_REG_BAIL) && !ret) {
>>> +   if (pmic_ops->reg_op == PMIC_REG_WRITE)
>>> +   ret = pmic_reg_write(p,
>>> +pmic_ops->reg_addr,
>>> +pmic_ops->reg_value);
>>> +   else
>>> +   ret = pmic_reg_update(p,
>>> +pmic_ops->reg_addr,
>>> +pmic_ops->reg_value);
>>> +   pmic_ops++;
>>> +   }
>>> +
>>> +   if (ret)
>>> +   printf("%s: Failed accessing reg 0x%x of %s\n",
>>> +  __func__, pmic_ops[-1].reg_addr, p->name);
>>
>> pmic_ops[-1].reg_addr, is it right?
>>
> 
> Yes, this is right because if you see the above while() loop we are
> incrementing the pmic_ops pointer after reg_write/reg_update and if
> any of them returns error value ,while() loop will break and the
> pmic_ops pointing to the next instance address. so to print the values
> in the previous instance pointer we are using pmic_ops[-1].

maybe your code will work correctly
but, the point is pmic_ops[-1] is not always right.
please think about it.

If I modify your code, then I'll return error immediately in while loop.

> 
>>> +  

Re: [U-Boot] [PATCH 1/2] doc/README.scrapyard: update commit IDs, use TAB for indentation

[Jesse Larrew]

On 01/15/2014 01:48 AM, Wolfgang Denk wrote:
> To make adding new entries a bit easier, we reformat the file to use
> TABs for indentation.
> 
> Also insert two now known commit IDs.
> 
> Signed-off-by: Wolfgang Denk 
> ---
>  doc/README.scrapyard | 252 
> +++
>  1 file changed, 154 insertions(+), 98 deletions(-)
> 
> diff --git a/doc/README.scrapyard b/doc/README.scrapyard
> index 604de0c..54756f3 100644
> --- a/doc/README.scrapyard
> +++ b/doc/README.scrapyard
> @@ -1,107 +1,163 @@
>  Over time, support for more and more boards gets added to U-Boot -
>  while other board support code dies a silent death caused by
> -negligence in combination with ordinary bitrot.  Sometimes this goes
> +negligence in combination with ordinary bitrot.   Sometimes this goes
>  by unnoticed, but often build errors will result.  If nobody cares any
>  more to resolve such problems, then the code is really dead and will
> -be removed from the U-Boot source tree.  The remainders rest in piece
> -in the imperishable depths of the git history.  This document tries to
> +be removed from the U-Boot source tree.   The remainders rest in piece
> +in the imperishable depths of the git history.   This document tries to
>  maintain a list of such former fellows, so archeologists can check
  ^^^
s/archeologists/archaeologists/

>  easily if here is something they might want to dig for...
 ^^^
s/here/there/

Sincerely,

Jesse Larrew
Open Grid Computing
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V4 5/6] exynos: Add a common DT based PMIC driver initialization

[Leela Krishna Amudala]

Hi,

On 1/16/14, Minkyu Kang  wrote:
> On 16/01/14 13:05, Leela Krishna Amudala wrote:
>> Hi Minkyu Kang,
>>
>> Thanks for reviewing the patch, Please check my comments inline.
>>
>> On 1/7/14, Minkyu Kang  wrote:
>>> On 06/01/14 20:49, Leela Krishna Amudala wrote:
 Most of i2c PMIC drivers follow the same initialization sequence,
 let's generalize it in a common file.

 The initialization function finds the PMIC in the device tree, and if
 found - registers it in the list of known PMICs and initializes it,
 iterating through the table of settings supplied by the caller.

 Signed-off-by: Vadim Bendebury 
 Signed-off-by: Leela Krishna Amudala 
 Reviewed-by: Doug Anderson 
 Acked-by: Simon Glass 
 ---
  board/samsung/common/board.c |   22 +
  drivers/power/pmic/Makefile  |1 +
  drivers/power/pmic/pmic_common.c |   97
 ++
  drivers/power/power_core.c   |   14 ++
  include/power/pmic.h |   34 +
  5 files changed, 168 insertions(+)
  create mode 100644 drivers/power/pmic/pmic_common.c

 +#include 
 +#include 
 +#include 
 +#include 
 +#include 
 +#include 
>>>
>>> Why common driver need specific pmic's header file?
>>> It is wrong architecture.
>>>
>>
>> Here, in this file we are using PMIC compact ID to find the number of
>> registers in a PMIC (now currently have support for only S2MPS11 and
>> other PMICs info may added in future), so we need those headers.
>
> So, it's a wrong architecture.
> It (find the number of registers) is a PMIC specific feature.
>

Okay, Then in that case I'll move this function to a new file or some
suitable location and call it here
or if you have any suggestions please tell me.

>>
 +
 +DECLARE_GLOBAL_DATA_PTR;
 +
 +static unsigned pmic_number_of_regs(enum fdt_compat_id pmic_compat)
>
> As I said, this function is not a common feature.
>

Okay, will move it to suitable location.

 +{
 +  switch (pmic_compat) {
 +  case COMPAT_SAMSUNG_S2MPS11_PMIC:
 +  return S2MPS11_NUM_OF_REGS;
 +  default:
 +  break;
 +  }
 +  return 0;
 +}
 +
 +int pmic_common_init(enum fdt_compat_id pmic_compat,
 +   const struct pmic_init_ops *pmic_ops)
 +{
 +  const void *blob = gd->fdt_blob;
 +  struct pmic *p;
 +  int node, parent, ret;
 +  unsigned number_of_regs = pmic_number_of_regs(pmic_compat);
 +  const char *pmic_name, *comma;
 +
 +  if (!number_of_regs) {
 +  printf("%s: %s - not a supported PMIC\n",
 + __func__, fdtdec_get_compatible(pmic_compat));
 +  return -1;
 +  }
 +
 +  node = fdtdec_next_compatible(blob, 0, pmic_compat);
 +  if (node < 0) {
 +  debug("PMIC: Error %s. No node for %s in device tree\n",
 +fdt_strerror(node), fdtdec_get_compatible(pmic_compat));
 +  return node;
 +  }
 +
 +  pmic_name = fdtdec_get_compatible(pmic_compat);
 +  comma = strchr(pmic_name, ',');
 +  if (comma)
 +  pmic_name = comma + 1;
 +
 +  p = pmic_alloc();
 +
 +  if (!p) {
 +  printf("%s: POWER allocation error!\n", __func__);
 +  return -ENOMEM;
 +  }
 +  parent = fdt_parent_offset(blob, node);
 +  if (parent < 0) {
 +  debug("%s: Cannot find node parent\n", __func__);
 +  return -1;
 +  }
 +
 +  p->bus = i2c_get_bus_num_fdt(parent);
 +  if (p->bus < 0) {
 +  debug("%s: Cannot find I2C bus\n", __func__);
 +  return -1;
 +  }
 +  p->hw.i2c.addr = fdtdec_get_int(blob, node, "reg", 9);
 +
 +  p->name = pmic_name;
 +  p->interface = PMIC_I2C;
 +  p->hw.i2c.tx_num = 1;
 +  p->number_of_regs = number_of_regs;
 +  p->compat_id = pmic_compat;
 +
 +  ret = 0;
 +  while ((pmic_ops->reg_op != PMIC_REG_BAIL) && !ret) {
 +  if (pmic_ops->reg_op == PMIC_REG_WRITE)
 +  ret = pmic_reg_write(p,
 +   pmic_ops->reg_addr,
 +   pmic_ops->reg_value);
 +  else
 +  ret = pmic_reg_update(p,
 +   pmic_ops->reg_addr,
 +   pmic_ops->reg_value);
 +  pmic_ops++;
 +  }
 +
 +  if (ret)
 +  printf("%s: Failed accessing reg 0x%x of %s\n",
 + __func__, pmic_ops[-1].reg_addr, p->name);
>>>
>>> pmic_ops[-1].reg_addr, is it right?
>>>
>>
>> Yes, this is right because if you see the above while() loop we are
>> incrementing the pmic_ops pointer after reg_write/reg_update and if
>> any of them returns error value ,while() loop will break and the
>> pmic_ops pointing to 

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

[Jagan Teki]

Hi Marek,

On Thu, Jan 16, 2014 at 1:08 AM, Marek Vasut  wrote:
> On Monday, January 13, 2014 at 08:42:18 PM, Tom Rini wrote:
>> On Tue, Jan 14, 2014 at 12:05:32AM +0530, Jagannadha Sutradharudu Teki wrote:
>> > Hi Tom,
>> >
>> > PR have quad and dual_flash change set also includes few fixes.
>> > Tested these changes on spansion, stmicro and sst flash devices.
>> >
>> > --
>> > Thanks,
>> > Jagan.
>> >
>> > The following changes since commit 
>> > 7f673c99c2d8d1aa21996c5b914f06d784b080ca:
>> >   Merge branch 'master' of git://git.denx.de/u-boot-arm (2014-01-10
>> >   10:56:00 -0500)
>> >
>> > are available in the git repository at:
>> >   git://git.denx.de/u-boot-spi.git master
>> >
>> > for you to fetch changes up to 35a55fb57fffb615e6b20980fb317e162076adb4:
>> >   sf: params: Removed flag SECT_4K for Micron N25Q128 (2014-01-12
>> >   21:40:23 +0530)
>> >
>> > 
>> >
>> > Axel Lin (1):
>> >   spi: sh_spi: Use sh_spi_clear_bit() instead of open-coded
>> >
>> > Jagannadha Sutradharudu Teki (17):
>> >   sf: Add extended read commands support
>> >   sf: Add quad read/write commands support
>> >   sf: ops: Add configuration register writing support
>> >   sf: Set quad enable bit support
>> >   sf: probe: Enable RD_FULL and WR_QPP
>> >   sf: Separate the flash params table
>> >   sf: Add QUAD_IO_FAST read support
>> >   sf: Discover read dummy_byte
>> >   sf: Add macronix set QEB support
>> >   sf: probe: Enable macronix quad read/write cmds support
>> >   sf: Divide flash register ops from QEB code
>> >   sf: Code cleanups
>> >   sf: ops: Unify read_ops bank configuration
>> >   sf: Add dual memories support - DUAL_STACKED
>> >   sf: Add dual memories support - DUAL_PARALLEL
>> >   sf: Add CONFIG_SF_DUAL_FLASH
>> >   doc: SPI: Update status.txt
>
> I looked into this patchset and this seems completely misdesigned, sorry.
No issues - OK.

Let me explain the journey with (spi_flash)sf since last 8 months. [1]
- We have a individual class of vendor drivers and removed all vendor specific
  stuff and added a common probe.
- Added Bank addr reg stuff
- Tunned sf almost seems like mtd/nand style where sf.c, sf_probe.c,
sf_params.c and sf_ops.c
- Added memory_mapped and quad commands supports
- Done many of cleanups
- maintained doc/SPI which we're trying to update.

Keeping these enhancements on current sf we are in a good shape than before.
>
> It seems this patchset aims to accomodate an SPI-NOR controllers within the 
> SPI
> API. The SPI-NOR controllers are a completely separate class of hardware 
> though,
> so I disagree with the attempt to integrate them into the SPI framework. I
> cannot use most of the SPI-NOR controllers to drive regular SPI bus (there are
> exceptions), but they are now presented as regular SPI controllers
> indiscriminately.
>
> Instead of going down this path, there should be a completely separate class 
> of
> drivers for the SPI-NOR controllers, same as in Linux [1]. That way, there 
> would
> still be an SF command talking to SF core, but the SF core would be delegating
> the calls to either a layer talking to a SPI flash via regular SPI interface 
> or
> a layer talking the SPI-NOR controller.
>
> I also see some flaws in these patches. For example the struct spi_slave {} 
> now
> contains all kinds of new entries used only by the SPI flash driver. The slave
> can now export for example SPI_OPM_RX_QOF and SPI_OPM_RX_QIOF (see
> include/spi.h) flags, which -- if you inspect drivers/mtd/spi/sf_probe.c and
> include/spi_flash.h -- should match up with enum spi_read_cmds . So we now 
> have
> two sets of flags, which needs to be kept in sync, which is wrong. Besides,
> these flags define the capabilities of the SPI-NOR host controller, so why are
> they even in struct spi_slave {} ?

The spi_slave grown with flash stuff with spi driver terminologies,
and the reason
for taking one extra flag for reads in params is like we have couple
of  commands
for 1, 2 and 4-lines I have given a spi driver has a provision to
verify these one by one.
The reason for going this implementation for improving sf performance.
>
> I also observe a big lack of documentation for all those flags, so it's really
> hard to make heads or tails of how it's supposed to work.

Some how disagree this, because we have started doc/SPI [2] these days
which don't have
before and I'm stressing patch contributors to add as many as doc and
test-cases logs.

and Yes- for this quad I'm planning to add test-case logs once our
zynq qspi is ML.
>
> Also, I don't see any of these new flags used yet, so we're still at a good
> point to avoid going down the wrong path. I would love to see this patchset
> postponed for next if possible, since my feeling of this is it needs severe
> redesign.
>
> [1] http://www.spinics.net/lists/arm-kernel/msg291891.html

And finally - I do understand your comments and

Re: [U-Boot] [PATCH 1/2] doc/README.scrapyard: update commit IDs, use TAB for indentation

[Wolfgang Denk]

Dear Masahiro,

In message <20140116095004.e122.aa925...@jp.panasonic.com> you wrote:
> 
> I do understand you want to use TABs for indentation.
> But I don't understand why you want to use them in the
> comment block. I think the part will not be changed often.
> I'm talking about a TAB between
> " U-Boot source tree." and "The remainders rest"
> 
> > -be removed from the U-Boot source tree.  The remainders rest in piece
> > -in the imperishable depths of the git history.  This document tries to
> > +be removed from the U-Boot source tree. The remainders rest in piece
> > +in the imperishable depths of the git history. This document tries to
> 
> I mean, here.

Ah, this was not intentionally.  I was running the whole file through
"unexpand -a", and this replaces multipe spaces at TAB positions by
TABs. I did not notice this.

> No. Shorter lines are better.
> You are right.
> (But I a little afraid someone who does not understand "TAB + 4 SPACE"
> rule might break the format.)

Yes - it is likely that later edits will re-introduce spaces, but the
we can easily re-fix this by piping the file through "unexpand -a".

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
Conceptual integrity in turn dictates that the  design  must  proceed
from  one  mind,  or  from  a  very small number of agreeing resonant
minds.   - Frederick Brooks Jr., "The Mythical Man Month"
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/7] board:samsung:common: set envs with board unified information

[Piotr Wilczek]

> -Original Message-
> From: Gerhard Sittig [mailto:g...@denx.de]
> Sent: Wednesday, January 15, 2014 5:18 PM
> To: Piotr Wilczek
> Cc: u-boot@lists.denx.de; Kyungmin Park
> Subject: Re: [U-Boot] [PATCH 3/7] board:samsung:common: set envs with
> board unified information
> 
> On Tue, Jan 14, 2014 at 08:59 +0100, Piotr Wilczek wrote:
> >
> > This patch enables to set envs that describe board information.
> > The following envs are set (but not saved): soc_id, soc_rev,
> board_rev.
> 
> I don't see the "not saved" part in the patch.  How exactly does a
> "saveenv" not save those programmatically generated variables?
> (Altera SoCFPGA suffers from the same issue, we may not want to repeat
> this in mainline U-Boot)
> 
It means only that I don't save the generated variables to persistent
storage.
I will modify the commit message to be more specific.

> > Based on this information, 'fdtaddr' env is set (not saved) as:
> > fdtaddr=${soc_family}${soc_id}-${board}.dtb
> 
> An address variable resolves to a DTB filename?  That would be
> unexpected.  Or is it a typo in the commit message?
It's a typo, I will fix the commit message.

> 
> 
> virtually yours
> Gerhard Sittig
> --
> DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany
> Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: off...@denx.de

Best regards,
Piotr Wilczek



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

[U-Boot] [PATCH 1/2] serial: opencores_yanu: Fix build error

[Axel Lin]

Fix build error due to missing include of serial.h and a trivial typo.

Signed-off-by: Axel Lin 
---
 drivers/serial/opencores_yanu.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/serial/opencores_yanu.c b/drivers/serial/opencores_yanu.c
index 8de2eca..80e9ae5 100644
--- a/drivers/serial/opencores_yanu.c
+++ b/drivers/serial/opencores_yanu.c
@@ -8,6 +8,7 @@
 #include 
 #include 
 #include 
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -154,7 +155,7 @@ static int oc_serial_tstc(void)
 ((1 << YANU_RFIFO_CHARS_N) - 1)) > 0);
 }
 
-statoc int oc_serial_getc(void)
+static int oc_serial_getc(void)
 {
while (serial_tstc() == 0)
WATCHDOG_RESET ();
-- 
1.8.1.2



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

[U-Boot] [PATCH 2/2] serial: opencores_yanu: Avoid duplicate oc_serial_setbrg() implementation

[Axel Lin]

The implementation of oc_serial_setbrg() for CONFIG_SYS_NIOS_FIXEDBAUD and
!CONFIG_SYS_NIOS_FIXEDBAUD are very similar.
Add a baudrate variable and set it to either CONFIG_BAUDRATE or gd->baudrate.
Then we can unify the code for both cases.

Signed-off-by: Axel Lin 
---
 drivers/serial/opencores_yanu.c | 49 -
 1 file changed, 9 insertions(+), 40 deletions(-)

diff --git a/drivers/serial/opencores_yanu.c b/drivers/serial/opencores_yanu.c
index 80e9ae5..d4ed60c 100644
--- a/drivers/serial/opencores_yanu.c
+++ b/drivers/serial/opencores_yanu.c
@@ -18,62 +18,34 @@ DECLARE_GLOBAL_DATA_PTR;
 
 static yanu_uart_t *uart = (yanu_uart_t *)CONFIG_SYS_NIOS_CONSOLE;
 
-#if defined(CONFIG_SYS_NIOS_FIXEDBAUD)
-
-/* Everything's already setup for fixed-baud PTF assignment*/
-
 static void oc_serial_setbrg(void)
 {
int n, k;
const unsigned max_uns = 0x;
unsigned best_n, best_m, baud;
+   unsigned baudrate;
 
-   /* compute best N and M couple */
-   best_n = YANU_MAX_PRESCALER_N;
-   for (n = YANU_MAX_PRESCALER_N; n >= 0; n--) {
-   if ((unsigned)CONFIG_SYS_CLK_FREQ / (1 << (n + 4)) >=
-   (unsigned)CONFIG_BAUDRATE) {
-   best_n = n;
-   break;
-   }
-   }
-   for (k = 0;; k++) {
-   if ((unsigned)CONFIG_BAUDRATE <= (max_uns >> (15+n-k)))
-   break;
-   }
-   best_m =
-   ((unsigned)CONFIG_BAUDRATE * (1 << (15 + n - k))) /
-   ((unsigned)CONFIG_SYS_CLK_FREQ >> k);
-
-   baud = best_m + best_n * YANU_BAUDE;
-   writel(baud, &uart->baud);
-
-   return;
-}
-
+#if defined(CONFIG_SYS_NIOS_FIXEDBAUD)
+   /* Everything's already setup for fixed-baud PTF assignment */
+   baudrate = CONFIG_BAUDRATE;
 #else
-
-static void oc_serial_setbrg(void)
-{
-   int n, k;
-   const unsigned max_uns = 0x;
-   unsigned best_n, best_m, baud;
-
+   baudrate = gd->baudrate;
+#endif
/* compute best N and M couple */
best_n = YANU_MAX_PRESCALER_N;
for (n = YANU_MAX_PRESCALER_N; n >= 0; n--) {
if ((unsigned)CONFIG_SYS_CLK_FREQ / (1 << (n + 4)) >=
-   gd->baudrate) {
+   baudrate) {
best_n = n;
break;
}
}
for (k = 0;; k++) {
-   if (gd->baudrate <= (max_uns >> (15+n-k)))
+   if (baudrate <= (max_uns >> (15+n-k)))
break;
}
best_m =
-   (gd->baudrate * (1 << (15 + n - k))) /
+   (baudrate * (1 << (15 + n - k))) /
((unsigned)CONFIG_SYS_CLK_FREQ >> k);
 
baud = best_m + best_n * YANU_BAUDE;
@@ -82,9 +54,6 @@ static void oc_serial_setbrg(void)
return;
 }
 
-
-#endif /* CONFIG_SYS_NIOS_FIXEDBAUD */
-
 static int oc_serial_init(void)
 {
unsigned action,control;
-- 
1.8.1.2



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

Re: [U-Boot] [PATCH] DRA7: Add support for ES1.1 silicon ID code

[Sricharan R]

On Tuesday 14 January 2014 10:24 PM, Nishanth Menon wrote:
> ES1.1 silicon is a very minor variant of ES1.0. Add priliminary support
> for ES1.1 IDCODE change.
> 
> Signed-off-by: Nishanth Menon 
> Reviewed-by: Tom Rini 
> ---
> 
>  arch/arm/cpu/armv7/omap-common/clocks-common.c |2 +-
>  arch/arm/cpu/armv7/omap-common/emif-common.c   |5 ++---
>  arch/arm/cpu/armv7/omap5/hw_data.c |2 ++
>  arch/arm/cpu/armv7/omap5/hwinit.c  |3 +++
>  arch/arm/cpu/armv7/omap5/sdram.c   |4 
>  arch/arm/include/asm/arch-omap5/omap.h |1 +
>  arch/arm/include/asm/omap_common.h |1 +
>  7 files changed, 14 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm/cpu/armv7/omap-common/clocks-common.c 
> b/arch/arm/cpu/armv7/omap-common/clocks-common.c
> index dfa3760..2883c1d 100644
> --- a/arch/arm/cpu/armv7/omap-common/clocks-common.c
> +++ b/arch/arm/cpu/armv7/omap-common/clocks-common.c
> @@ -436,7 +436,7 @@ static void setup_non_essential_dplls(void)
>  #ifdef CONFIG_SYS_OMAP_ABE_SYSCK
>   abe_ref_clk = CM_ABE_PLL_REF_CLKSEL_CLKSEL_SYSCLK;
>  
> - if (omap_revision() == DRA752_ES1_0)
> + if (is_dra7xx())
>   /* Select the sys clk for dpll_abe */
>   clrsetbits_le32((*prcm)->cm_abe_pll_sys_clksel,
>   CM_CLKSEL_ABE_PLL_SYS_CLKSEL_MASK,
> diff --git a/arch/arm/cpu/armv7/omap-common/emif-common.c 
> b/arch/arm/cpu/armv7/omap-common/emif-common.c
> index cd6289b..429c4be 100644
> --- a/arch/arm/cpu/armv7/omap-common/emif-common.c
> +++ b/arch/arm/cpu/armv7/omap-common/emif-common.c
> @@ -179,8 +179,7 @@ void emif_update_timings(u32 base, const struct emif_regs 
> *regs)
>   writel(regs->temp_alert_config, &emif->emif_temp_alert_config);
>   writel(regs->emif_ddr_phy_ctlr_1, &emif->emif_ddr_phy_ctrl_1_shdw);
>  
> - if ((omap_revision() >= OMAP5430_ES1_0) ||
> - (omap_revision() == DRA752_ES1_0)) {
> + if ((omap_revision() >= OMAP5430_ES1_0) || is_dra7xx()) {
>   writel(EMIF_L3_CONFIG_VAL_SYS_10_MPU_5_LL_0,
>   &emif->emif_l3_config);
>   } else if (omap_revision() >= OMAP4460_ES1_0) {
> @@ -309,7 +308,7 @@ static void ddr3_init(u32 base, const struct emif_regs 
> *regs)
>* The same sequence should work on OMAP5432 as well. But strange that
>* it is not working
>*/
> - if (omap_revision() == DRA752_ES1_0) {
> + if (is_dra7xx()) {
>   do_ext_phy_settings(base, regs);
>   writel(regs->sdram_config2, &emif->emif_lpddr2_nvm_config);
>   writel(regs->sdram_config_init, &emif->emif_sdram_config);
> diff --git a/arch/arm/cpu/armv7/omap5/hw_data.c 
> b/arch/arm/cpu/armv7/omap5/hw_data.c
> index 5268a1f..e47b454 100644
> --- a/arch/arm/cpu/armv7/omap5/hw_data.c
> +++ b/arch/arm/cpu/armv7/omap5/hw_data.c
> @@ -639,6 +639,7 @@ void hw_data_init(void)
>   break;
>  
>   case DRA752_ES1_0:
> + case DRA752_ES1_1:
>   *prcm = &dra7xx_prcm;
>   *dplls_data = &dra7xx_dplls;
>   *omap_vcores = &dra752_volts;
> @@ -666,6 +667,7 @@ void get_ioregs(const struct ctrl_ioregs **regs)
>   *regs = &ioregs_omap5432_es2;
>   break;
>   case DRA752_ES1_0:
> + case DRA752_ES1_1:
>   *regs = &ioregs_dra7xx_es1;
>   break;
>  
> diff --git a/arch/arm/cpu/armv7/omap5/hwinit.c 
> b/arch/arm/cpu/armv7/omap5/hwinit.c
> index 5386ae0..737d23c 100644
> --- a/arch/arm/cpu/armv7/omap5/hwinit.c
> +++ b/arch/arm/cpu/armv7/omap5/hwinit.c
> @@ -333,6 +333,9 @@ void init_omap_revision(void)
>   case DRA752_CONTROL_ID_CODE_ES1_0:
>   *omap_si_rev = DRA752_ES1_0;
>   break;
> + case DRA752_CONTROL_ID_CODE_ES1_1:
> + *omap_si_rev = DRA752_ES1_1;
> + break;
>   default:
>   *omap_si_rev = OMAP5430_SILICON_ID_INVALID;
>   }
> diff --git a/arch/arm/cpu/armv7/omap5/sdram.c 
> b/arch/arm/cpu/armv7/omap5/sdram.c
> index 2e18706..16a91f9 100644
> --- a/arch/arm/cpu/armv7/omap5/sdram.c
> +++ b/arch/arm/cpu/armv7/omap5/sdram.c
> @@ -245,6 +245,7 @@ static void emif_get_reg_dump_sdp(u32 emif_nr, const 
> struct emif_regs **regs)
>   *regs = &emif_regs_ddr3_532_mhz_1cs_es2;
>   break;
>   case DRA752_ES1_0:
> + case DRA752_ES1_1:
>   switch (emif_nr) {
>   case 1:
>   *regs = &emif_1_regs_ddr3_532_mhz_1cs_dra_es1;
> @@ -273,6 +274,7 @@ static void emif_get_dmm_regs_sdp(const struct 
> dmm_lisa_map_regs
>   *dmm_lisa_regs = &lisa_map_4G_x_2_x_2;
>   break;
>   case DRA752_ES1_0:
> + case DRA752_ES1_1:
>   default:
>   *dmm_lisa_regs = &lisa_map_2G_x_2_x_2_2G_x_1_x_2;
>   }
> @@ -460,6 +462,7 @@ static void emif_get_ext_phy_ctrl_const_regs(u32 emif_nr,
>   *size = ARRAY_SIZE(ddr3_ext_phy_ctrl_const_base_es2

Re: [U-Boot] [PATCH] arm64 patch: gicv3 support

[FengHua]

> -Original Messages-
> From: "bhupesh.sha...@freescale.com" 
> Sent Time: 2014-01-16 11:45:18 (Thursday)
> To: 'FengHua' 
> Cc: "u-boot@lists.denx.de" , "tr...@ti.com" 
> , "arnab.b...@freescale.com" 
> Subject: RE: RE: [U-Boot] [PATCH] arm64 patch: gicv3 support
> 
> > -Original Message-
> > From: FengHua [mailto:feng...@phytium.com.cn]
> > Sent: Thursday, January 16, 2014 6:47 AM
> > To: Sharma Bhupesh-B45370
> > Cc: u-boot@lists.denx.de; tr...@ti.com; Basu Arnab-B45036
> > Subject: Re: RE: [U-Boot] [PATCH] arm64 patch: gicv3 support
> > 
> > 
> > hi bhupesh,
> > 
> > 
> > > -Original Messages-
> > > From: "bhupesh.sha...@freescale.com" 
> > > Sent Time: 2014-01-15 22:19:02 (Wednesday)
> > > To: "'feng...@phytium.com.cn'" ,
> > > "u-boot@lists.denx.de" 
> > > Cc: "tr...@ti.com" , "arnab.b...@freescale.com"
> > > 
> > > Subject: RE: [U-Boot] [PATCH] arm64 patch: gicv3 support
> > >
> > > Hi David,
> > >
> > > Thanks for the patch.
> > > Please see some comments inline:
> > >
> > > > -Original Message-
> > > > From: u-boot-boun...@lists.denx.de
> > > > [mailto:u-boot-boun...@lists.denx.de]
> > > > On Behalf Of feng...@phytium.com.cn
> > > > Sent: Wednesday, January 15, 2014 1:41 PM
> > > > To: u-boot@lists.denx.de
> > > > Cc: tr...@ti.com
> > > > Subject: [U-Boot] [PATCH] arm64 patch: gicv3 support
> > > >
> > > > From: David Feng 
> > > >
> > > > This patch add gicv3 support to uboot armv8 platform.
> > > > Modifications cover 4 source files, as follows:
> > > >   gic.S: gicv3 initialization and sgi interrupt raising.
> > > >   goc.h: gicv3 register definitions.
> > >
> > >   ^^^
> > > Typo - gic.h
> > >
> > > >   vexpress_aemv8a.h: add CONFIG_GICV2/CONFIG_GICV3 switch.
> > > >   start.S: set SCR_EL3.NS bit to 1, gicv3 register of ICC_SRE_EL2
> > > >could be accessed only when SCR_EL3.NS=1.
> > > >set SCR_EL3.IRQ|FIQ|EA bits, reroute all interrupts to
> > > >el3 at all cores, slaves could be waken up by interrupt
> > > >only when the interrupt is routed to it when running
> > > >at el3.
> > >
> > > Hmmm. This seems a bit suspicious - if we reroute even IRQs and Aborts
> > > to the cores which work in EL3, they will not be visible to Linux or
> > > Hypervisor which work in EL2 or EL1.
> > >
> > These bits will be cleared when jumping to el2.
> 
> I seem to be missing this clear operation in your patch. Can you please point 
> me to the same.
> 
armv8_switch_to_el2 routine in transition.S.

> > > Have you tried to launch linux on the ARMv8 foundation model v2 with
> > these changes?
> > >
> > Yes.
> 
> But I thought we still don't have GICv3 driver in Linux. So did you boot 
> linux with GICv2 or GICv3?
> 
GICv3. MAZ's gicv3 kernel git tree contains GICv3 driver.

> > 
> > > > Note: please use the latest gcc 4.8 compiler from linaro
> > > >   which support gicv3 system register assembling.
> > > >
> > >
> > > Two generic comments :
> > >
> > > - I see in the Foundation model README that the optional GICv3 is
> > > supported with memory-mapped CPU interface and distributor, but I see
> > > your patch accessing them via the sytem register interface (via msr and
> > mrs). Is this a BUG in the README?
> > >
> > The document did not describe it clearly, but actually it support.
> 
> So this seems to be a documentation BUG, did you provide a feedback to the 
> ARM support folks regarding the same
> - they should probably fix the documentation.
I have not. Actually, I did not notice this before receiving your mail.

>  
> > > Did you check this patch on the latest ARMv8 foundation model - v2?
> > >
> > Yes.
> > 
> > > - Also how about sharing the GICv2 coding between ARMv7 and ARMv8 -
> > > some of the code may seems like a duplication from the ARMv7 GICv2
> > content.
> > >
> > Many codes could be shared between armv7 and armv8 such as cache
> > maintenance and gic.
> > These need be rearranged seriously. We'd better wait a period of time
> > before the armv8 codes are more widely acquainted and get more feedback
> > about this.
> 
> I agree about the ARMv7/v8 code sharing, but with GICv3 there is an 
> additional problem - it can be configured as 
> GICv2 as well and for the same it would make sense to move common code b/w 
> the CONFIG_GICV2/CONFIG_GICV3 code legs
> to a common leg.
Yes, this need more considerations.

> 
> > 
> > > > Signed-off-by: David Feng 
> > > > ---
> > > >  arch/arm/cpu/armv8/gic.S  |   84
> > > > -
> > > >  arch/arm/cpu/armv8/start.S|5 ++-
> > > >  arch/arm/include/asm/gic.h|   56 +
> > > >  include/configs/vexpress_aemv8a.h |7 
> > > >  4 files changed, 150 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/arch/arm/cpu/armv8/gic.S b/arch/arm/cpu/armv8/gic.S
> > > > index 599aa8f..a08939a 100644
> > > > --- a/arch/arm/cpu/armv8/gic.S
> > > > +++ b/arch/arm/cpu/armv8/gic.S
> > > > @@ -

Re: [U-Boot] UBIFS seeing corrupt blank pages when image flashed via u-boot

[Artem Bityutskiy]

On Wed, 2014-01-15 at 21:29 +, Gupta, Pekon wrote:
> Hi Artem,
> 
> >From: Artem Bityutskiy [mailto:artem.bityuts...@linux.intel.com]
> 
> >Conclusion: all UBIFS needs is a way to ask the driver - is this NAND
> >page blank or not? UBIFS does not really has to compare to all 0xFFs.
> >
> Thanks for details. Yes, I understand the concept in general that you
> want to recover last bit of user-data written on NAND (without corruption).
> 
> Now, as NAND driver itself does differentiation between and erased-page
> v/s programmed-page. Can we use different error codes to pass this
> information to upper layers like;

I thought the ECC is something which could be used to differentiate.


> *For MTD layer*
> 0: data valid, length of data is determined by 'read_len'  (currently)
> -EUCLEAN: correctable bit-flips found, data is valid
> -EBADMSG: un-correctable bit-flips, data *may-be* invalid.
> -ENODATA: detected erased-page. *Actual* data determined by read_len.
> -ENOMSG:  detected erased-page with bit-flips. *Actual* data determined by 
> read_len.

Not sure this is a good idea. If NAND driver cannot do the
differentiation, then it should not be done by the MTD layer, I think.

Then just improve UBI and UBIFS and make the function which compares
buffers with all 0xFFs allow for bit-flips. We know the maximum possible
bit-flips per min. I/O unit, right? Just allow for that amount.

-- 
Best Regards,
Artem Bityutskiy

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

Re: [U-Boot] [PATCH v2] arm: exynos: change to use clrbits macro instead of readl/writel function

[Minkyu Kang]

On 15/01/14 14:27, Inha Song wrote:
> Use setbits/clrbits macro instead of readl/writel function
> 
> Signed-off-by: Inha Song 
> Signed-off-by: Minkyu Kang 
> Tested-by: Przemyslaw Marczak 
> ---
> Changes for v2:
> - Coding Style cleanup
> - add signed-off-by
> 
>  arch/arm/cpu/armv7/exynos/clock.c |   82 
> +
>  1 file changed, 20 insertions(+), 62 deletions(-)
  
>   /*
>* CLK_SRC_LCD0
> @@ -1085,10 +1070,7 @@ void exynos4_set_lcd_clk(void)
>* MIPI0_SEL[12:15]
>* set lcd0 src clock 0x6: SCLK_MPLL
>*/
> - cfg = readl(&clk->src_lcd0);
> - cfg &= ~(0xf);
> - cfg |= 0x6;
> - writel(cfg, &clk->src_lcd0);
> + clrsetbits_le32(&clk->src_lcd0, 0x9, 0x6);

0x9? It seems to be 0xf.

>  
>   /*
>* CLK_GATE_IP_LCD0
> @@ -1100,9 +1082,7 @@ void exynos4_set_lcd_clk(void)
>* CLK_PPMULCD0 [5]
>* Gating all clocks for FIMD0
>*/
> - cfg = readl(&clk->gate_ip_lcd0);
> - cfg |= 1 << 0;
> - writel(cfg, &clk->gate_ip_lcd0);
> + setbits_le32(&clk->gate_ip_lcd0, 1 << 0);
>  
>   /*
>* CLK_DIV_LCD0
> @@ -1114,16 +1094,13 @@ void exynos4_set_lcd_clk(void)
>* MIPI0_PRE_RATIO  [23:20]
>* set fimd ratio
>*/
> - cfg &= ~(0xf);
> - cfg |= 0x1;
> - writel(cfg, &clk->div_lcd0);
> + clrsetbits_le32(&clk->div_lcd0, 0xe, 0x1);

ditto.

>  }
>  
>  void exynos5_set_lcd_clk(void)
>  {
>   struct exynos5_clock *clk =
>   (struct exynos5_clock *)samsung_get_base_clock();
> - unsigned int cfg = 0;
>  
>   /*
>* CLK_GATE_BLOCK
> @@ -1135,9 +1112,7 @@ void exynos5_set_lcd_clk(void)
>* CLK_LCD1 [5]
>* CLK_GPS  [7]
>*/
> - cfg = readl(&clk->gate_block);
> - cfg |= 1 << 4;
> - writel(cfg, &clk->gate_block);
> + setbits_le32(&clk->gate_block, 1 << 4);
>  
>   /*
>* CLK_SRC_LCD0
> @@ -1147,10 +1122,7 @@ void exynos5_set_lcd_clk(void)
>* MIPI0_SEL[12:15]
>* set lcd0 src clock 0x6: SCLK_MPLL
>*/
> - cfg = readl(&clk->src_disp1_0);
> - cfg &= ~(0xf);
> - cfg |= 0x6;
> - writel(cfg, &clk->src_disp1_0);
> + clrsetbits_le32(&clk->src_disp1_0, 0x9, 0x6);

ditto.

>  
>   /*
>* CLK_GATE_IP_LCD0
> @@ -1162,9 +1134,7 @@ void exynos5_set_lcd_clk(void)
>* CLK_PPMULCD0 [5]
>* Gating all clocks for FIMD0
>*/
> - cfg = readl(&clk->gate_ip_disp1);
> - cfg |= 1 << 0;
> - writel(cfg, &clk->gate_ip_disp1);
> + setbits_le32(&clk->gate_ip_disp1, 1 << 0);
>  
>   /*
>* CLK_DIV_LCD0
> @@ -1176,16 +1146,13 @@ void exynos5_set_lcd_clk(void)
>* MIPI0_PRE_RATIO  [23:20]
>* set fimd ratio
>*/
> - cfg &= ~(0xf);
> - cfg |= 0x0;
> - writel(cfg, &clk->div_disp1_0);
> + clrbits_le32(&clk->div_disp1_0, 0xf);
>  }
>  
>  void exynos4_set_mipi_clk(void)
>  {
>   struct exynos4_clock *clk =
>   (struct exynos4_clock *)samsung_get_base_clock();
> - unsigned int cfg = 0;
>  
>   /*
>* CLK_SRC_LCD0
> @@ -1195,10 +1162,7 @@ void exynos4_set_mipi_clk(void)
>* MIPI0_SEL[12:15]
>* set mipi0 src clock 0x6: SCLK_MPLL
>*/
> - cfg = readl(&clk->src_lcd0);
> - cfg &= ~(0xf << 12);
> - cfg |= (0x6 << 12);
> - writel(cfg, &clk->src_lcd0);
> + clrsetbits_le32(&clk->src_lcd0, 0x9 << 12, 0x6 << 12);

ditto.

>  
>   /*
>* CLK_SRC_MASK_LCD0
> @@ -1208,9 +1172,7 @@ void exynos4_set_mipi_clk(void)
>* MIPI0_MASK   [12]
>* set src mask mipi0 0x1: Unmask
>*/
> - cfg = readl(&clk->src_mask_lcd0);
> - cfg |= (0x1 << 12);
> - writel(cfg, &clk->src_mask_lcd0);
> + setbits_le32(&clk->src_mask_lcd0, 0x1 << 12);
>  
>   /*
>* CLK_GATE_IP_LCD0
> @@ -1222,9 +1184,7 @@ void exynos4_set_mipi_clk(void)
>* CLK_PPMULCD0 [5]
>* Gating all clocks for MIPI0
>*/
> - cfg = readl(&clk->gate_ip_lcd0);
> - cfg |= 1 << 3;
> - writel(cfg, &clk->gate_ip_lcd0);
> + setbits_le32(&clk->gate_ip_lcd0, 1 << 3);
>  
>   /*
>* CLK_DIV_LCD0
> @@ -1236,9 +1196,7 @@ void exynos4_set_mipi_clk(void)
>* MIPI0_PRE_RATIO  [23:20]
>* set mipi ratio
>*/
> - cfg &= ~(0xf << 16);
> - cfg |= (0x1 << 16);
> - writel(cfg, &clk->div_lcd0);
> + clrsetbits_le32(&clk->div_lcd0, 0xe << 16, 0x1 << 16);

ditto.

>  }
>  
>  /*
> 

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