Re: [U-Boot] [PATCH 1/2] usb: ehci: rmobile: Add support R8A7793

[Marek Vasut]

On Tuesday, November 04, 2014 at 08:10:30 AM, Nobuhiro Iwamatsu wrote:
> Hi!

Hi!

[...]

> > btw. just an idea, but you don't need to explicitly use
> > usb_base_address[CONFIG_USB_MAX_CONTROLLER_COUNT], you can
> > just use usb_base_address[] in the array definition. Then,
> > in the code, you can just use "ARRAY_SIZE(usb_base_address) - 1"
> > instead of CONFIG_USB_MAX_CONTROLLER_COUNT . This rids you of
> > one annoying macro in that driver ;-) If you want to implement
> > this, then please do so, but in a separate patch.
> 
> Indeed. I will create a patch which fix your point.
> 
> > I'll pick these two patches now.
> 
> Thanks!

Thank you, I will queue it for the next PR, since I sent this one out
already.

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

[U-Boot] [PATCH 1/4] imx: mx6: Add support for MX6 plugin images

[Ye . Li]

Plugin image is a firmware which can be executed by boot ROM to do
device initialization, custom settings, delay assertion, etc.

The boot ROM detects the image type using the plugin flag of the boot
data structure. If the plugin flag is 1, then the ROM uses the image
as a plugin function. The function must initialize the boot device and
copy the program image to the final location. At the end the plugin
function must return with the program image parameters.

This patch supports generating plugin images and implement a framework
for plugin code entry and exit. For any board to generate the plugin
image, the macros below must be implemented:
  imx6_ddr_setting
  imx6_clock_gating
  imx6_qos_setting

Signed-off-by: Ye.Li 
---
 arch/arm/include/asm/arch-mx6/mx6_plugin.S |  145 +++
 tools/imximage.c   |  263 ++--
 tools/imximage.h   |   10 +-
 3 files changed, 366 insertions(+), 52 deletions(-)
 create mode 100644 arch/arm/include/asm/arch-mx6/mx6_plugin.S

diff --git a/arch/arm/include/asm/arch-mx6/mx6_plugin.S 
b/arch/arm/include/asm/arch-mx6/mx6_plugin.S
new file mode 100644
index 000..1f5ae83
--- /dev/null
+++ b/arch/arm/include/asm/arch-mx6/mx6_plugin.S
@@ -0,0 +1,145 @@
+/*
+ * Copyright (C) 2012-2014 Freescale Semiconductor, Inc.
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+
+#ifdef CONFIG_ROM_UNIFIED_SECTIONS
+#define ROM_API_TABLE_BASE_ADDR_LEGACY 0x180
+#define ROM_VERSION_OFFSET 0x80
+#else
+#define ROM_API_TABLE_BASE_ADDR_LEGACY 0xC0
+#define ROM_VERSION_OFFSET 0x48
+#endif
+#define ROM_API_TABLE_BASE_ADDR_MX6DQ_TO15 0xC4
+#define ROM_API_TABLE_BASE_ADDR_MX6DL_TO12 0xC4
+#define ROM_API_HWCNFG_SETUP_OFFSET0x08
+#define ROM_VERSION_TO10   0x10
+#define ROM_VERSION_TO12   0x12
+#define ROM_VERSION_TO15   0x15
+
+plugin_start:
+
+   push{r0-r4, lr}
+
+   imx6_ddr_setting
+   imx6_clock_gating
+   imx6_qos_setting
+
+/*
+ * The following is to fill in those arguments for this ROM function
+ * pu_irom_hwcnfg_setup(void **start, size_t *bytes, const void *boot_data)
+ * This function is used to copy data from the storage media into DDR.
+ * start - Initial (possibly partial) image load address on entry.
+ * Final image load address on exit.
+ * bytes - Initial (possibly partial) image size on entry.
+ * Final image size on exit.
+ * boot_data - Initial @ref ivt Boot Data load address.
+ */
+   adr r0, boot_data2
+   adr r1, image_len2
+   adr r2, boot_data2
+
+#ifdef CONFIG_SYS_BOOT_EIMNOR
+#ifdef CONFIG_MX6SX
+   ldr r3, =ROM_VERSION_OFFSET
+   ldr r4, [r3]
+   cmp r4, #ROM_VERSION_TO10
+   bgt before_calling_rom___pu_irom_hwcnfg_setup
+   ldr r3, =0x00900b00
+   ldr r4, =0x5000
+   str r4, [r3, #0x5c]
+#else
+   ldr r3, =0x00900800
+   ldr r4, =0x0800
+   str r4, [r3, #0xc0]
+#endif
+#endif
+
+/*
+ * check the _pu_irom_api_table for the address
+ */
+before_calling_rom___pu_irom_hwcnfg_setup:
+   ldr r3, =ROM_VERSION_OFFSET
+   ldr r4, [r3]
+#if defined(CONFIG_MX6SOLO) || defined(CONFIG_MX6DL)
+   ldr r3, =ROM_VERSION_TO12
+   cmp r4, r3
+   ldrge r3, =ROM_API_TABLE_BASE_ADDR_MX6DL_TO12
+   ldrlt r3, =ROM_API_TABLE_BASE_ADDR_LEGACY
+#elif defined(CONFIG_MX6Q)
+   ldr r3, =ROM_VERSION_TO15
+   cmp r4, r3
+   ldrge r3, =ROM_API_TABLE_BASE_ADDR_MX6DQ_TO15
+   ldrlt r3, =ROM_API_TABLE_BASE_ADDR_LEGACY
+#else
+   ldr r3, =ROM_API_TABLE_BASE_ADDR_LEGACY
+#endif
+   ldr r4, [r3, #ROM_API_HWCNFG_SETUP_OFFSET]
+   blx r4
+after_calling_rom___pu_irom_hwcnfg_setup:
+
+
+/* To return to ROM from plugin, we need to fill in these argument.
+ * Here is what need to do:
+ * Need to construct the paramters for this function before return to ROM:
+ * plugin_download(void **start, size_t *bytes, UINT32 *ivt_offset)
+ */
+   pop {r0-r4, lr}
+   push {r5}
+   ldr r5, boot_data2
+   str r5, [r0]
+   ldr r5, image_len2
+   str r5, [r1]
+   ldr r5, second_ivt_offset
+   str r5, [r2]
+   mov r0, #1
+   pop {r5}
+
+   /* return back to ROM code */
+   bx lr
+
+/* make the following data right in the end of the output*/
+.ltorg
+
+#if (defined(CONFIG_SYS_BOO

[U-Boot] [PATCH 2/4] imx: mx6q/dlarm2: Add support for building plugin image

[Ye . Li]

Update "cfg" script to build for plugin image. This default plugin
image supports the boot devices as DCD image.

To enable the plugin, must define the CONFIG_USE_PLUGIN in "mx6qarm2.h"

Signed-off-by: Ye.Li 
---
 board/freescale/mx6qarm2/Makefile   |4 +
 board/freescale/mx6qarm2/imximage.cfg   |9 +
 board/freescale/mx6qarm2/imximage_mx6dl.cfg |9 +
 board/freescale/mx6qarm2/plugin.S   |  943 +++
 4 files changed, 965 insertions(+), 0 deletions(-)
 create mode 100644 board/freescale/mx6qarm2/plugin.S

diff --git a/board/freescale/mx6qarm2/Makefile 
b/board/freescale/mx6qarm2/Makefile
index 79401f4..ed08acd 100644
--- a/board/freescale/mx6qarm2/Makefile
+++ b/board/freescale/mx6qarm2/Makefile
@@ -7,3 +7,7 @@
 #
 
 obj-y  := mx6qarm2.o
+
+extra-$(CONFIG_USE_PLUGIN) :=  plugin.bin
+$(obj)/plugin.bin: $(obj)/plugin.o
+   $(OBJCOPY) -O binary --gap-fill 0xff $< $@
diff --git a/board/freescale/mx6qarm2/imximage.cfg 
b/board/freescale/mx6qarm2/imximage.cfg
index c85bde5..c5b927a 100644
--- a/board/freescale/mx6qarm2/imximage.cfg
+++ b/board/freescale/mx6qarm2/imximage.cfg
@@ -10,6 +10,9 @@
  * The syntax is taken as close as possible with the kwbimage
  */
 
+#define __ASSEMBLY__
+#include 
+
 /* image version */
 IMAGE_VERSION 2
 
@@ -19,6 +22,11 @@ IMAGE_VERSION 2
  */
 BOOT_FROM  sd
 
+#ifdef CONFIG_USE_PLUGIN
+/*PLUGINplugin-binary-fileIRAM_FREE_START_ADDR*/
+PLUGIN board/freescale/mx6qarm2/plugin.bin 0x00907000
+#else
+
 /*
  * Device Configuration Data (DCD)
  *
@@ -336,3 +344,4 @@ DATA 4 0x020e0018 0x007F007F
 DATA 4 0x020e001c 0x007F007F
 
 #endif /* CONFIG_MX6DQ_LPDDR2 */
+#endif
diff --git a/board/freescale/mx6qarm2/imximage_mx6dl.cfg 
b/board/freescale/mx6qarm2/imximage_mx6dl.cfg
index ae8dcc6..0f4048d 100644
--- a/board/freescale/mx6qarm2/imximage_mx6dl.cfg
+++ b/board/freescale/mx6qarm2/imximage_mx6dl.cfg
@@ -10,6 +10,9 @@
  * The syntax is taken as close as possible with the kwbimage
  */
 
+#define __ASSEMBLY__
+#include 
+
 /* image version */
 IMAGE_VERSION 2
 
@@ -19,6 +22,11 @@ IMAGE_VERSION 2
  */
 BOOT_FROM  sd
 
+#ifdef CONFIG_USE_PLUGIN
+/*PLUGINplugin-binary-fileIRAM_FREE_START_ADDR*/
+PLUGIN board/freescale/mx6qarm2/plugin.bin 0x00907000
+#else
+
 /*
  * Device Configuration Data (DCD)
  *
@@ -460,3 +468,4 @@ DATA 4 0x020e0010 0xF0CF
 DATA 4 0x020e0018 0x007F007F
 DATA 4 0x020e001c 0x007F007F
 #endif /* CONFIG_MX6DL_LPDDR2 */
+#endif
diff --git a/board/freescale/mx6qarm2/plugin.S 
b/board/freescale/mx6qarm2/plugin.S
new file mode 100644
index 000..dded80a
--- /dev/null
+++ b/board/freescale/mx6qarm2/plugin.S
@@ -0,0 +1,943 @@
+/*
+ * Copyright (C) 2012-2014 Freescale Semiconductor, Inc.
+ *
+ * Author: Fabio Estevam 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+
+.macro imx6dlarm2_ddr_setting
+   ldr r0, =CCM_BASE_ADDR
+   ldr r1, =0x
+   str r1, [r0, #0x068]
+   ldr r1, =0x
+   str r1, [r0, #0x06c]
+   ldr r1, =0x
+   str r1, [r0, #0x070]
+   ldr r1, =0x
+   str r1, [r0, #0x074]
+   ldr r1, =0x
+   str r1, [r0, #0x078]
+   ldr r1, =0x
+   str r1, [r0, #0x07c]
+   ldr r1, =0x
+   str r1, [r0, #0x080]
+   ldr r1, =0x
+   str r1, [r0, #0x084]
+
+   ldr r0, =IOMUXC_BASE_ADDR
+   ldr r1, =0x000c
+   str r1, [r0, #0x798]
+   ldr r1, =0x
+   str r1, [r0, #0x758]
+
+   ldr r1, =0x0030
+   str r1, [r0, #0x588]
+   str r1, [r0, #0x594]
+   str r1, [r0, #0x56c]
+   str r1, [r0, #0x578]
+   str r1, [r0, #0x74c]
+   str r1, [r0, #0x57c]
+
+   ldr r1, =0x3000
+   str r1, [r0, #0x590]
+   str r1, [r0, #0x598]
+
+   ldr r1, =0x
+   str r1, [r0, #0x58c]
+
+   ldr r1, =0x3030
+   str r1, [r0, #0x59c]
+   str r1, [r0, #0x5a0]
+
+   ldr r1, =0x0030
+   str r1, [r0, #0x78c]
+
+   ldr r1, =0x0002
+   str r1, [r0, #0x750]
+
+   ldr r1, =0x0030
+   str r1, [r0, #0x5a8]
+   str r1, [r0, #0x5b0]
+   str r1, [r0, #0x524]
+   str r1, [r0, #0x51c]
+   str r1, [r0, #0x518]
+   str r1, [r0, #0x50c]
+   str r1, [r0, #0x5b8]
+   str r1, [r0, #0x5c0]
+
+   ldr r1, =0x0002
+   str r1, [r0, #0x774]
+
+   ldr r1, =0x0030
+   str r1, [r0, #0x784]
+   str r1, [r0, #0x788]
+   str r1, [r0, #0x794]
+   str r1, [r0, #0x79c]
+   str r1, [r0, #0x7a0]
+   str r1, [r0, #0x7a4]
+   str r1, [r0, #0x7a8]
+   str r1, [r0, #0x748]
+   str r1, [r0, #0x5ac]
+   str r1, [r0, #0x5b4]
+   str r1, [r0, #0x528]
+   str r1, [r0, #0x520]
+   str r1, [r0, #0x514]
+   str r1, [r0, #0x510]
+   str r1, [r0, #0x5bc]
+   str r1, [r0, #0x5c4]
+
+   ldr r0, =MMDC_P0_BASE_ADDR
+   ldr r1, =MMDC_P1_BASE_ADDR
+   ldr r2, =0xa1390003
+   str r2, [r0,

[U-Boot] [PATCH 3/4] imx: mx6slevk: Add support for building plugin image

[Ye . Li]

Update "cfg" script to build for plugin image. This default plugin
image supports the boot devices as DCD image.

To enable the plugin, must define the CONFIG_USE_PLUGIN in "mx6slevk.h"

Signed-off-by: Ye.Li 
---
 board/freescale/mx6slevk/Makefile |4 +
 board/freescale/mx6slevk/imximage.cfg |9 ++
 board/freescale/mx6slevk/plugin.S |  187 +
 3 files changed, 200 insertions(+), 0 deletions(-)
 create mode 100644 board/freescale/mx6slevk/plugin.S

diff --git a/board/freescale/mx6slevk/Makefile 
b/board/freescale/mx6slevk/Makefile
index 6e1971e..fb44826 100644
--- a/board/freescale/mx6slevk/Makefile
+++ b/board/freescale/mx6slevk/Makefile
@@ -4,3 +4,7 @@
 #
 
 obj-y  := mx6slevk.o
+
+extra-$(CONFIG_USE_PLUGIN) :=  plugin.bin
+$(obj)/plugin.bin: $(obj)/plugin.o
+   $(OBJCOPY) -O binary --gap-fill 0xff $< $@
diff --git a/board/freescale/mx6slevk/imximage.cfg 
b/board/freescale/mx6slevk/imximage.cfg
index 16ea597..b574357 100644
--- a/board/freescale/mx6slevk/imximage.cfg
+++ b/board/freescale/mx6slevk/imximage.cfg
@@ -9,6 +9,9 @@
  * The syntax is taken as close as possible with the kwbimage
  */
 
+#define __ASSEMBLY__
+#include 
+
 /* image version */
 
 IMAGE_VERSION 2
@@ -20,6 +23,11 @@ IMAGE_VERSION 2
 
 BOOT_FROM  sd
 
+#ifdef CONFIG_USE_PLUGIN
+/*PLUGINplugin-binary-fileIRAM_FREE_START_ADDR*/
+PLUGIN board/freescale/mx6slevk/plugin.bin 0x00907000
+#else
+
 /*
  * Device Configuration Data (DCD)
  *
@@ -113,3 +121,4 @@ DATA 4 0x021b08b8 0x0800
 DATA 4 0x021b0004 0x00025564
 DATA 4 0x021b0404 0x00011006
 DATA 4 0x021b001c 0x
+#endif
diff --git a/board/freescale/mx6slevk/plugin.S 
b/board/freescale/mx6slevk/plugin.S
new file mode 100644
index 000..287dfed
--- /dev/null
+++ b/board/freescale/mx6slevk/plugin.S
@@ -0,0 +1,187 @@
+/*
+ * Copyright (C) 2014 Freescale Semiconductor, Inc.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+
+/* DDR script */
+.macro imx6slevk_ddr_setting
+   ldr r0, =CCM_BASE_ADDR
+   ldr r1, =0x00260324
+   str r1, [r0, #0x018]
+
+   ldr r0, =IOMUXC_BASE_ADDR
+   ldr r1, =0x0002
+   str r1, [r0, #0x5c0]
+   ldr r1, =0x
+   str r1, [r0, #0x5b4]
+
+   ldr r1, =0x0028
+   str r1, [r0, #0x338]
+
+   ldr r1, =0x0030
+   str r1, [r0, #0x300]
+   str r1, [r0, #0x31c]
+   str r1, [r0, #0x320]
+
+   ldr r1, =0x
+   str r1, [r0, #0x32c]
+
+   ldr r1, =0x0030
+   str r1, [r0, #0x5ac]
+   str r1, [r0, #0x5c8]
+
+   ldr r1, =0x0002
+   str r1, [r0, #0x5b0]
+
+   ldr r1, =0x3030
+   str r1, [r0, #0x344]
+   str r1, [r0, #0x348]
+   str r1, [r0, #0x34c]
+   str r1, [r0, #0x350]
+
+   ldr r1, =0x0008
+   str r1, [r0, #0x5d0]
+
+   ldr r1, =0x0030
+   str r1, [r0, #0x5c4]
+   str r1, [r0, #0x5cc]
+   str r1, [r0, #0x5d4]
+   str r1, [r0, #0x5d8]
+
+   str r1, [r0, #0x30c]
+   str r1, [r0, #0x310]
+   str r1, [r0, #0x314]
+   str r1, [r0, #0x318]
+
+   ldr r0, =MMDC_P0_BASE_ADDR
+   ldr r2, =0x8000
+   str r2, [r0, #0x01c]
+
+   ldr r2, =0x1b4700c7
+   str r2, [r0, #0x85c]
+
+   ldr r2, =0xa1390003
+   str r2, [r0, #0x800]
+
+   ldr r2, =0x0030
+   str r2, [r0, #0x890]
+
+   ldr r2, =0x0800
+   str r2, [r0, #0x8b8]
+
+   ldr r2, =0x
+   str r2, [r0, #0x81c]
+   str r2, [r0, #0x820]
+   str r2, [r0, #0x824]
+   str r2, [r0, #0x828]
+   str r2, [r0, #0x82c]
+   str r2, [r0, #0x830]
+   str r2, [r0, #0x834]
+   str r2, [r0, #0x838]
+
+   ldr r2, =0x4241444a
+   str r2, [r0, #0x848]
+
+   ldr r2, =0x3030312b
+   str r2, [r0, #0x850]
+
+   ldr r2, =0x2000
+   str r2, [r0, #0x83c]
+
+   ldr r2, =0x
+   str r2, [r0, #0x840]
+
+   ldr r2, =0x0800
+   str r2, [r0, #0x8b8]
+
+   ldr r2, =0x33374133
+   str r2, [r0, #0x00c]
+
+   ldr r2, =0x00020024
+   str r2, [r0, #0x004]
+
+   ldr r2, =0x00100A82
+   str r2, [r0, #0x010]
+   ldr r2, =0x0093
+   str r2, [r0, #0x014]
+   ldr r2, =0x1688
+   str r2, [r0, #0x018]
+   ldr r2, =0x0F9F26D2
+   str r2, [r0, #0x02c]
+
+   ldr r2, =0x020E
+   str r2, [r0, #0x030]
+   ldr r2, =0x00190778
+   str r2, [r0, #0x038]
+   ldr r2, =0x
+   str r2, [r0, #0x008]
+   ldr r2, =0x004F
+   str r2, [r0, #0x040]
+   ldr r2, =0xC311
+   str r2, [r0, #0x000]
+
+   ldr r2, =0x003F8030
+   str r2, [r0, #0x01c]
+   ldr r2, =0xFF0A8030
+   str r2, [r0, #0x01c]
+   ldr r2, =0x82018030
+   str r2, [r0, #0x01c]
+   ldr r2, =0x04028030
+   str r2, [r0, #0x01c]
+   ldr r2, =0x02038030
+   str r2, [r0, #0x01c]
+   ldr r2, =0xFF0A8038
+   str r2, [r0, #0x01c]
+   ldr r2, =0x82018038
+   str 

[U-Boot] [PATCH 4/4] imx: mx6sxsabresd: Add support for building plugin image

[Ye . Li]

Update "cfg" script to build for plugin image. This default plugin
image supports the boot devices as DCD image.

To enable the plugin, must define the CONFIG_USE_PLUGIN in "mx6sxsabresd.h"

Signed-off-by: Ye.Li 
---
 board/freescale/mx6sxsabresd/Makefile |4 +
 board/freescale/mx6sxsabresd/imximage.cfg |6 ++
 board/freescale/mx6sxsabresd/plugin.S |  135 +
 3 files changed, 145 insertions(+), 0 deletions(-)
 create mode 100644 board/freescale/mx6sxsabresd/plugin.S

diff --git a/board/freescale/mx6sxsabresd/Makefile 
b/board/freescale/mx6sxsabresd/Makefile
index 97dbfda..bd9ac6f 100644
--- a/board/freescale/mx6sxsabresd/Makefile
+++ b/board/freescale/mx6sxsabresd/Makefile
@@ -4,3 +4,7 @@
 #
 
 obj-y  := mx6sxsabresd.o
+
+extra-$(CONFIG_USE_PLUGIN) :=  plugin.bin
+$(obj)/plugin.bin: $(obj)/plugin.o
+   $(OBJCOPY) -O binary --gap-fill 0xff $< $@
diff --git a/board/freescale/mx6sxsabresd/imximage.cfg 
b/board/freescale/mx6sxsabresd/imximage.cfg
index c862617..9a99208 100644
--- a/board/freescale/mx6sxsabresd/imximage.cfg
+++ b/board/freescale/mx6sxsabresd/imximage.cfg
@@ -18,6 +18,11 @@ IMAGE_VERSION 2
 
 BOOT_FROM  sd
 
+#ifdef CONFIG_USE_PLUGIN
+/*PLUGINplugin-binary-fileIRAM_FREE_START_ADDR*/
+PLUGIN board/freescale/mx6sxsabresd/plugin.bin 0x00907000
+#else
+
 /*
  * Device Configuration Data (DCD)
  *
@@ -130,3 +135,4 @@ DATA 4 0x021b001c 0x04008040
 DATA 4 0x021b0020 0x0800
 DATA 4 0x021b0818 0x0007
 DATA 4 0x021b001c 0x
+#endif
diff --git a/board/freescale/mx6sxsabresd/plugin.S 
b/board/freescale/mx6sxsabresd/plugin.S
new file mode 100644
index 000..667095f
--- /dev/null
+++ b/board/freescale/mx6sxsabresd/plugin.S
@@ -0,0 +1,135 @@
+/*
+ * Copyright (C) 2013-2014 Freescale Semiconductor, Inc.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+
+/* DDR script */
+.macro imx6sx_sabresd_ddr_setting
+   ldr r0, =IOMUXC_BASE_ADDR
+   ldr r1, =0x000c
+   str r1, [r0, #0x618]
+   ldr r1, =0x
+   str r1, [r0, #0x5fc]
+   ldr r1, =0x0030
+   str r1, [r0, #0x32c]
+
+   ldr r1, =0x0020
+   str r1, [r0, #0x300]
+   str r1, [r0, #0x2fc]
+   str r1, [r0, #0x5f4]
+   str r1, [r0, #0x340]
+
+   ldr r1, =0x
+   str r1, [r0, #0x320]
+   ldr r1, =0x0020
+   str r1, [r0, #0x310]
+   str r1, [r0, #0x314]
+   str r1, [r0, #0x614]
+
+   ldr r1, =0x0002
+   str r1, [r0, #0x5f8]
+   ldr r1, =0x0028
+   str r1, [r0, #0x330]
+   str r1, [r0, #0x334]
+   str r1, [r0, #0x338]
+   str r1, [r0, #0x33c]
+   ldr r1, =0x0002
+   str r1, [r0, #0x608]
+   ldr r1, =0x0028
+   str r1, [r0, #0x60c]
+   str r1, [r0, #0x610]
+   str r1, [r0, #0x61c]
+   str r1, [r0, #0x620]
+   str r1, [r0, #0x2ec]
+   str r1, [r0, #0x2f0]
+   str r1, [r0, #0x2f4]
+   str r1, [r0, #0x2f8]
+
+   ldr r0, =MMDC_P0_BASE_ADDR
+   ldr r2, =0xa1390003
+   str r2, [r0, #0x800]
+   ldr r2, =0x00290025
+   str r2, [r0, #0x80c]
+   ldr r2, =0x00220022
+   str r2, [r0, #0x810]
+   ldr r2, =0x41480144
+   str r2, [r0, #0x83c]
+   ldr r2, =0x01340130
+   str r2, [r0, #0x840]
+   ldr r2, =0x3C3E4244
+   str r2, [r0, #0x848]
+   ldr r2, =0x34363638
+   str r2, [r0, #0x850]
+
+   ldr r2, =0x
+   str r2, [r0, #0x81c]
+   str r2, [r0, #0x820]
+   str r2, [r0, #0x824]
+   str r2, [r0, #0x828]
+
+   ldr r2, =0x0800
+   str r2, [r0, #0x8b8]
+   ldr r2, =0x0002002d
+   str r2, [r0, #0x004]
+   ldr r2, =0x00333030
+   str r2, [r0, #0x008]
+   ldr r2, =0x676b52f3
+   str r2, [r0, #0x00c]
+   ldr r2, =0xb66d8b63
+   str r2, [r0, #0x010]
+   ldr r2, =0x01ff00db
+   str r2, [r0, #0x014]
+   ldr r2, =0x00011740
+   str r2, [r0, #0x018]
+   ldr r2, =0x8000
+   str r2, [r0, #0x01c]
+   ldr r2, =0x26d2
+   str r2, [r0, #0x02c]
+   ldr r2, =0x006b1023
+   str r2, [r0, #0x030]
+   ldr r2, =0x005f
+   str r2, [r0, #0x040]
+   ldr r2, =0x8419
+   str r2, [r0, #0x000]
+   ldr r2, =0x04008032
+   str r2, [r0, #0x01c]
+   ldr r2, =0x8033
+   str r2, [r0, #0x01c]
+   ldr r2, =0x00048031
+   str r2, [r0, #0x01c]
+   ldr r2, =0x05208030
+   str r2, [r0, #0x01c]
+   ldr r2, =0x04008040
+   str r2, [r0, #0x01c]
+   ldr r2, =0x0800
+   str r2, [r0, #0x020]
+   ldr r2, =0x0007
+   str r2, [r0, #0x818]
+   ldr r2, =0x
+   str r2, [r0, #0x01c]
+.endm
+.macro imx6_clock_gating
+   ldr r0, =CCM_BASE_ADDR
+   ldr r1, =0x
+   str r1, [r0, #0x068]
+   str r1, [r0, #0x06c]
+   str r1, [r0, #0x070]
+   str r1, [r0, #0x074]
+   str r1, [r0, #0x078]
+   str r1, [r0, #0x07c]
+   str r1, [r0, #0x080]
+   str r1

Re: [U-Boot] [PATCH v2 3/4] odroid: make some macros common

[Lukasz Majewski]

Hi Hyungwon,

> On Mon, 03 Nov 2014 09:51:25 +0100
> Lukasz Majewski  wrote:
> 
> > Hi Hyungwon,
> > 
> > > Some macros are used commonly for odroid series boards. This patch
> > > makes a common header file to congregate that kinds of macros.
> > > Even though there are more macros which can be common, they are
> > > not become common. Because they are a part of a register, the
> > > readability is better when they are defined at a place.
> > > 
> > > Signed-off-by: Hyungwon Hwang 
> > > ---
> > >  board/samsung/odroid/odroid.c | 1 +
> > >  board/samsung/odroid/setup.h  | 8 
> > >  2 files changed, 1 insertion(+), 8 deletions(-)
> > > 
> > 
> > I suspect that you have not added the new file to git repository -
> > since you only removed lines from board/samsung/odroid/setup.h
> > 
> > I also guess that odroid U3 will not build anymore. That is a very
> > good use case for buildman script.
> 
> Oh. It is my mistake. I will include the common header in next
> version.
> 
> > 
> > > diff --git a/board/samsung/odroid/odroid.c
> > > b/board/samsung/odroid/odroid.c index 5edb250..ccbb3a0 100644
> > > --- a/board/samsung/odroid/odroid.c
> > > +++ b/board/samsung/odroid/odroid.c
> > > @@ -18,6 +18,7 @@
> > >  #include 
> > >  #include 
> > >  #include 
> > > +#include "../setup.h"
> > 
> > Relative path is not a good idea IMHO.
> > 
> > It would be better to place it at ./include/samsung/ with a self
> > explanatory name (like exynos4-pll.h or/and exynos4-{other excluded
> > defines for an IP blocks}).
> > 
> > In this way other boards could use those defines too.
> 
> I think that your idea is better than mine.
> 
> > 
> > >  #include "setup.h"
> > >  
> > >  DECLARE_GLOBAL_DATA_PTR;
> > > diff --git a/board/samsung/odroid/setup.h
> > > b/board/samsung/odroid/setup.h index 3e48dad..35f7af5 100644
> > > --- a/board/samsung/odroid/setup.h
> > > +++ b/board/samsung/odroid/setup.h
> > > @@ -8,14 +8,6 @@
> > >  #ifndef __ODROIDU3_SETUP__
> > >  #define __ODROIDU3_SETUP__
> > >  
> > > -/* A/M PLL_CON0 */
> > > -#define SDIV(x) ((x) & 0x7)
> > > -#define PDIV(x) (((x) & 0x3f) << 8)
> > > -#define MDIV(x) (((x) & 0x3ff) << 16)
> > > -#define FSEL(x) (((x) & 0x1) << 27)
> > > -#define PLL_LOCKED_BIT  (0x1 << 29)
> > > -#define PLL_ENABLE(x)   (((x) & 0x1) << 31)
> > > -
> > 
> > The above data is common for Exynos U3 and XU3, but is it the only
> > one? Aren't there any more defines to be extracted?
> > 
> > >  /* CLK_SRC_CPU */
> > >  #define MUX_APLL_SEL(x) ((x) & 0x1)
> > >  #define MUX_CORE_SEL(x) (((x) & 0x1) << 16)
> > 
> > 
> > 
> 
> You're right. I found some other common macros more now. I will
> reflect it in next version. But I have a doubt about MUX_APLL_SEL or
> something else which consist of a register with different macros in
> different processors. They can be extracted to common file. But is it
> good to do it? For example, MUX_APLL_SEL exists both in Exynos4 and
> Exynos5's CLK_SRC_CPU.
> 
> Exynos 4412
> /* CLK_SRC_CPU */
> #define MUX_APLL_SEL(x)   ((x) & 0x1)
> #define MUX_CORE_SEL(x)   (((x) & 0x1) << 16)
> 
> Exynos 5800
> /* CLK_SRC_CPU */
> #define MUX_APLL_SEL(x) ((x) & 0x1)
> #define MUX_CORE_SEL(x) (((x) & 0x1)
> #define MUX_HPM_SEL(x)  (((x) & 0x1) << 20)
> #define MUX_MPLL_USER_SEL_C(x)  (((x) & 0x1) << 24)

It is always a matter of pragmatism.  In the above case you could only
extract MUX_APLL_SEL(x). But is it worth to add a separate header file
for only one line? In my opinion not.

> 
> If MUX_APLL_SEL and MUX_CORE_SEL are extracted to the common file, it
> will be harder to see what consist of CLK_SRC_CPU at a glance. Isn't
> it? This situation is worse in the case of APLL_RATIO. (Please see
> the below.) I want to hear your opinion about it.
> 
> Exynos 4412
> /* CLK_DIV_CPU0 */
> #define ARM_RATIO(x)   ((x) & 0x7)
> #define CPUD_RATIO(x) (((x) & 0x7) << 4)
> #define ATB_RATIO(x) (((x) & 0x7) << 16)
> #define PCLK_DBG_RATIO(x)   (((x) & 0x7) << 20)
> #define APLL_RATIO(x)   (((x) & 0x7) << 24)
> #define ARM2_RATIO(x) (((x) & 0x7) << 28)
> 
> Exynos 5800
> /* CLK_DIV_CPU0 */
> #define CORE_RATIO(x)   ((x) & 0x7)
> #define COREM0_RATIO(x) (((x) & 0x7) << 4)
> #define COREM1_RATIO(x) (((x) & 0x7) << 8)
> #define PERIPH_RATIO(x) (((x) & 0x7) << 12)
> #define ATB_RATIO(x)(((x) & 0x7) << 16)
> #define PCLK_DBG_RATIO(x)   (((x) & 0x7) << 20)
> #define APLL_RATIO(x)   (((x) & 0x7) << 24)
> #define CORE2_RATIO(x)  (((x) & 0x7) << 28)

Readability is important. Also please pay a note that ARM2_RATIO() is
the same as CORE2_RATIO(). Frankly I don't know why those defines have
different names.

To sum up:

When you see a potential to extract a common data and it justifies the
need for creating a new file, then go for it.

Is the setup.h the 

[U-Boot] [PATCH] board/freescale: use generic board architecture for p1025-twr

[ying.zhang]

From: Ying Zhang 

Use generic board architecture for p1025-twr, tested with NOR
boot and NAND boot on p1025-twr.

Signed-off-by: Ying Zhang 
---
 include/configs/p1_twr.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/configs/p1_twr.h b/include/configs/p1_twr.h
index 911203d..b98c71e 100644
--- a/include/configs/p1_twr.h
+++ b/include/configs/p1_twr.h
@@ -10,6 +10,8 @@
 #ifndef __CONFIG_H
 #define __CONFIG_H
 
+#defineCONFIG_SYS_GENERIC_BOARD
+#defineCONFIG_DISPLAY_BOARDINFO
 #if defined(CONFIG_TWR_P1025)
 #define CONFIG_BOARDNAME "TWR-P1025"
 #define CONFIG_P1025
-- 
1.8.4.1

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

Re: [U-Boot] [PATCH] MAINTAINERS: add me as a maintainer of MTD

[Scott Wood]

On Fri, 2014-10-31 at 11:26 +0100, Heiko Schocher wrote:
> Add MAINTAINERS and doc/git-mailrc entry.
> 
> Signed-off-by: Heiko Schocher 
> 
> ---
> as discussed this step here and there first of all with Scott Wood
> for example here:
> http://lists.denx.de/pipermail/u-boot/2014-August/186005.html
> 
> I am now ready for taking over the ownership for MTD ...
> 
> @Scott: I would be happy, if you can still have a look in nand patches ;-)
> please inform me, if you have no longer time for it, so
> we can set u-boot-nand into not maintained state

If you're only looking to be custodian for mtd infrastructure and not
NAND, I guess I'll continue to do it...  I hope there won't be any more
from-scratch updates of the NAND code, though. :-)

-Scott


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

Re: [U-Boot] verifying & signing

[Srinivasan S]

Hi Simon,

Good Morning!

Many Thanks a lot for all your support so far,

1. With respect to the verified boot , I want to put the images onto NAND 
FLASH, Could you please let me know what is the procedure of flashing  the 
verified boot images onto NAND instead of micro-SD

2.Does dm-verity works only on read-only rootfs?.. or it works on read-write 
rootfs?.. because as of  now we are looking out only for a bare minimal rootfs 
, could you please suggest me if any rootfs with minimal support where 
dm-verity can be applied & verified apart from android

 I want to implement the automatic software update & recovery feature (ie., 
firmware update of uboot, kernel & rootfs) in ti-sdk-am335x-evm-07.00.00.00 
BSP's , if in case if it bricks to unbrick by itself,
 Could you please help me with suitable pointers & source code links for 
implementing this feature

Awaiting for your replies
Many Thanks in advance again,

Srinivasan S



From: s...@google.com  on behalf of Simon Glass 

Sent: Monday, November 3, 2014 5:08 AM
To: srinivasan
Cc: U-Boot Mailing List; Srinivasan S
Subject: Re: verifying & signing

Hi,

On 2 November 2014 07:06, srinivasan  wrote:
>
>
>
>
> Hi Simon,
>
> http://lists.denx.de/pipermail/u-boot/2014-June/180845.html
>
> As the above link explains the Signing of kernel & verifying with uboot,
>
> Could you please let me know do you have any methods of signing & verifying
> the linux kernel with root file system ie., am using
> ti-sdk-am335x-evm-07.00.00.00 BSP's where linux kernel is from this BSP only
> & would be planning to use rootfs as my Angstrom filesystem or any others

If you use dm-verity you can verify your root disk using a hash which
is stored in the verified part of U-Boot. This is the method used by
Chrome OS. This requires a read-only rootfs though. Is that
acceptable?

See this page for some info on how Android does this:

https://source.android.com/devices/tech/security/dm-verity.html

>
> Could you please let me know how do we sign & verify the kernel with rootfs
> with detailed steps as am using beaglebone black as my development board
> with ti-sdk-am335x-evm-07.00.00.00 BSP's

I don't have details steps of this part sorry. An overview is here:

http://events.linuxfoundation.org/sites/events/files/slides/chromeos_and_diy_vboot_0.pdf


>
> Awaiting for your replies
> Many Thanks in advance
>
>
>

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

Re: [U-Boot] [linux-sunxi] [PATCH 5/9] sun4i: Rename dram files to dram_sun4i.x

[Julian Calaby]

Hi Hans,

On Tue, Nov 4, 2014 at 2:34 AM, Hans de Goede  wrote:
> In preparation for adding sun6i dram support.
>
> Signed-off-by: Hans de Goede 
> ---
>  arch/arm/cpu/armv7/sunxi/Makefile|   6 +-
>  arch/arm/cpu/armv7/sunxi/dram.c  | 750 
> ---
>  arch/arm/cpu/armv7/sunxi/dram_sun4i.c| 750 
> +++
>  arch/arm/include/asm/arch-sunxi/dram.h   | 171 +-
>  arch/arm/include/asm/arch-sunxi/dram_sun4i.h | 182 +++
>  5 files changed, 941 insertions(+), 918 deletions(-)
>  delete mode 100644 arch/arm/cpu/armv7/sunxi/dram.c
>  create mode 100644 arch/arm/cpu/armv7/sunxi/dram_sun4i.c
>  create mode 100644 arch/arm/include/asm/arch-sunxi/dram_sun4i.h
>
> diff --git a/arch/arm/include/asm/arch-sunxi/dram.h 
> b/arch/arm/include/asm/arch-sunxi/dram.h
> index 1945f75..9072e68 100644
> --- a/arch/arm/include/asm/arch-sunxi/dram.h
> +++ b/arch/arm/include/asm/arch-sunxi/dram.h
> @@ -14,172 +14,13 @@
>
>  #include 
>
> -struct sunxi_dram_reg {
> -   u32 ccr;/* 0x00 controller configuration register */
> -   u32 dcr;/* 0x04 dram configuration register */
> -   u32 iocr;   /* 0x08 i/o configuration register */
> -   u32 csr;/* 0x0c controller status register */
> -   u32 drr;/* 0x10 dram refresh register */
> -   u32 tpr0;   /* 0x14 dram timing parameters register 0 */
> -   u32 tpr1;   /* 0x18 dram timing parameters register 1 */
> -   u32 tpr2;   /* 0x1c dram timing parameters register 2 */
> -   u32 gdllcr; /* 0x20 global dll control register */
> -   u8 res0[0x28];
> -   u32 rslr0;  /* 0x4c rank system latency register */
> -   u32 rslr1;  /* 0x50 rank system latency register */
> -   u8 res1[0x8];
> -   u32 rdgr0;  /* 0x5c rank dqs gating register */
> -   u32 rdgr1;  /* 0x60 rank dqs gating register */
> -   u8 res2[0x34];
> -   u32 odtcr;  /* 0x98 odt configuration register */
> -   u32 dtr0;   /* 0x9c data training register 0 */
> -   u32 dtr1;   /* 0xa0 data training register 1 */
> -   u32 dtar;   /* 0xa4 data training address register */
> -   u32 zqcr0;  /* 0xa8 zq control register 0 */
> -   u32 zqcr1;  /* 0xac zq control register 1 */
> -   u32 zqsr;   /* 0xb0 zq status register */
> -   u32 idcr;   /* 0xb4 initializaton delay configure reg */
> -   u8 res3[0x138];
> -   u32 mr; /* 0x1f0 mode register */
> -   u32 emr;/* 0x1f4 extended mode register */
> -   u32 emr2;   /* 0x1f8 extended mode register */
> -   u32 emr3;   /* 0x1fc extended mode register */
> -   u32 dllctr; /* 0x200 dll control register */
> -   u32 dllcr[5];   /* 0x204 dll control register 0(byte 0) */
> -   /* 0x208 dll control register 1(byte 1) */
> -   /* 0x20c dll control register 2(byte 2) */
> -   /* 0x210 dll control register 3(byte 3) */
> -   /* 0x214 dll control register 4(byte 4) */
> -   u32 dqtr0;  /* 0x218 dq timing register */
> -   u32 dqtr1;  /* 0x21c dq timing register */
> -   u32 dqtr2;  /* 0x220 dq timing register */
> -   u32 dqtr3;  /* 0x224 dq timing register */
> -   u32 dqstr;  /* 0x228 dqs timing register */
> -   u32 dqsbtr; /* 0x22c dqsb timing register */
> -   u32 mcr;/* 0x230 mode configure register */
> -   u8 res[0x8];
> -   u32 ppwrsctl;   /* 0x23c pad power save control */
> -   u32 apr;/* 0x240 arbiter period register */
> -   u32 pldtr;  /* 0x244 priority level data threshold reg */
> -   u8 res5[0x8];
> -   u32 hpcr[32];   /* 0x250 host port configure register */
> -   u8 res6[0x10];
> -   u32 csel;   /* 0x2e0 controller select register */
> -};
> -
> -struct dram_para {
> -   u32 clock;
> -   u32 mbus_clock;
> -   u32 type;
> -   u32 rank_num;
> -   u32 density;
> -   u32 io_width;
> -   u32 bus_width;
> -   u32 cas;
> -   u32 zq;
> -   u32 odt_en;
> -   u32 size;
> -   u32 tpr0;
> -   u32 tpr1;
> -   u32 tpr2;
> -   u32 tpr3;
> -   u32 tpr4;
> -   u32 tpr5;
> -   u32 emr1;
> -   u32 emr2;
> -   u32 emr3;
> -   u32 dqs_gating_delay;
> -   u32 active_windowing;
> -};
> -
> -#define DRAM_CCR_COMMAND_RATE_1T (0x1 << 5)
> -#define DRAM_CCR_DQS_GATE (0x1 << 14)
> -#define DRAM_CCR_DQS_DRIFT_COMP (0x1 << 17)
> -#define DRAM_CCR_ITM_OFF (0x1 << 28)
> -#define DRAM_CCR_DATA_TRAINING (0x1 << 30)
> -#define DRAM_CCR_INIT (0x1 << 31)
> -
> -#define DRAM_MEMORY_TYP

Re: [U-Boot] verified boot of beaglebone black

[Srinivasan S]

Hi,

Thanks a lot for your replies,
When I was executing the below  ie., Step 5: Sign the kernel from 
http://lists.denx.de/pipermail/u-boot/2014-June/180845.html

When I was using the mkimage tools for sigining am facing the below errors, 
could you please do the needful in resolving the below errors as early as 
possible

srinivasan@tata-HP-Elite-7100-Microtower-PC:~/TUNSTALL$ echo $PATH
/home/srinivasan/bin:/home/srinivasan/TUNSTALL/board-support/u-boot-2014.07/b/am335x_boneblack_vboot/tools/:/home/srinivasan/TUNSTALL/board-support/u-boot-2014.07/dtc/:/opt/ti-sdk-am335x-evm-07.00.00.00/linux-devkit/sysroots/i686-arago-linux/usr/bin/:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games

srinivasan@tata-HP-Elite-7100-Microtower-PC:~/TUNSTALL/board-support/linux-3.12.10-ti2013.12.01/work$
 ls
am335x-boneblack.dtb  am335x-boneblack-pubkey.dtb  Image  keys  sign.its  
u-boot-dtb.img
srinivasan@tata-HP-Elite-7100-Microtower-PC:~/TUNSTALL/board-support/linux-3.12.10-ti2013.12.01/work$
 mkimage -f sign.its -K am335x-boneblack-pubkey.dtb -k keys -r image.fit
Error: sign.its:7.15-16 syntax error
FATAL ERROR: Unable to parse input tree
mkimage: Can't read image.fit.tmp: Invalid argument
mkimage Can't add hashes to FIT blob
srinivasan@tata-HP-Elite-7100-Microtower-PC:~/TUNSTALL/board-support/linux-3.12.10-ti2013.12.01/work$

Many Thanks in advance,
Srinivasan S

From: Jagan Teki 
Sent: Friday, October 31, 2014 12:29 PM
To: Srinivasan S
Cc: Simon Glass; U-Boot Mailing List
Subject: Re: [U-Boot] verified boot of beaglebone black

On 31 October 2014 10:48, Srinivasan S  wrote:
> Hi Simon
>
>
> Once again thanks a lot for your confirmation
>
>
> As you suggested, I have downloaded 
> u-boot-2014.07.tar.bz2 & 
> when I was trying to build the same , I was facing the below errors
>
>
> srinivasan@tata-HP-Elite-7100-Microtower-PC:~/TUNSTALL/board-support/u-boot-2014.07$
>  make O=b/am335x_boneblack_vboot CROSS_COMPILE=arm-linux-gnueabihf- ARCH=arm 
> am335x_boneblack_vboot_config all
>
>
>
>
> /home/srinivasan/TUNSTALL/board-support/u-boot-2014.07/scripts/dtc-version.sh:
>  line 17: dtc: command not found
> /home/srinivasan/TUNSTALL/board-support/u-boot-2014.07/scripts/dtc-version.sh:
>  line 18: dtc: command not found
> *** Your dtc is too old, please upgrade to dtc 1.4 or newer
> make[2]: *** [checkdtc] Error 1
> make[1]: *** [build-one-by-one] Error 2
> make: *** [sub-make] Error 2

Looks like dtc is not your your bash path, try to build the same and export it.

$ git clone git://git.kernel.org/pub/scm/utils/dtc/dtc.git
$ cd dtc
$ make
$ sudo make install

See doc/README.fdt-control for more info.

>
>
>
> Please do the needful in resolving this issue
>
>
>
> Thanks in advance,
>
> srinivasan S
>
>
> 
> From: s...@google.com  on behalf of Simon Glass 
> 
> Sent: Friday, October 31, 2014 9:57 AM
> To: Srinivasan S
> Cc: U-Boot Mailing List
> Subject: Re: verified boot of beaglebone black
>
>
> Hi,
>
> On 30 Oct 2014 21:50, "Srinivasan S" 
> mailto:srinivasa...@tataelxsi.co.in>> wrote:
>>
>> Thanks a lot for your replies Simon,
>>
>> 1. Could you please confirm whether the beaglebone black support exists in 
>> that  U-Boot 2014.07 & can I use  linux-3.12.10-ti2013.12.01 kernel 
>> (provided  by ti-sdk-am335x-evm-07.00.00.00 )on top of this U-Boot 2014.07
>>
>
> That should work ok.
>
>> 2. Could you please provide me the link for syncing U-Boot 2014.07 for 
>> beaglebone black
>
> See here:
>
> ftp://ftp.denx.de/pub/u-boot/
>
> Regards,
> Simon
>
>> Many Thanks in Advance,
>> Srinivasan S
>> 
>> From: s...@google.com 
>> mailto:s...@google.com>> on behalf of Simon Glass 
>> mailto:s...@chromium.org>>
>> Sent: Thursday, October 30, 2014 8:30 PM
>> To: Srinivasan S
>> Cc: U-Boot Mailing List
>> Subject: Re: verified boot of beaglebone black
>>
>> Hi,
>>
>> On 30 October 2014 01:15, Srinivasan S 
>> mailto:srinivasa...@tataelxsi.co.in>> wrote:
>> > Hi Simon,
>> >
>> > Extremely Sorry to push you Hard, Could you please provide any updates 
>> > w.r.t the below issue
>>
>> I think you missed my reply, am removing context...
>>
>> >
>> Please use the latest mainline, or at least U-Boot 2014.07. That board
>> does not exist in older versions.

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

[U-Boot] Displaying splash screen on BeagleBone Black and LCD

[Tamás Bondár]

Hi,

I'm trying to display a splash screen on a BeagleBone Black with the 
Chipsee 7" LCD expansion board. I'm wondering how difficult this is with 
the latest U-Boot? I can see that there are some framebuffer drivers 
available (am335x-fb.c and da8xx-fb.c) but it's not clear how to 
configure U-Boot to use them. Could somebody give some hints or an 
example, please?


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

Re: [U-Boot] verified boot of beaglebone black

[Srinivasan S]

Thanks a lot for your replies 
The issue was where at symbol was supposed to be changed to @

+   kernel at 1 {
+   data = /incbin/("Image.lzo");
+   type = "kernel";
+   arch = "arm";
+   os = "linux";
+   compression = "lzo";
+   load = <0x80008000>;
+   entry = <0x80008000>;
+   hash at 1 {
+   algo = "sha1";
+   };

When I was generating the keys ie., Step 4: Create a key pair

Am facing one more error while generating private key & certificate containing 
public key used for verification when I execute the below openssl commands it 
is saying can't open  config file:

srinivasan@tata-HP-Elite-7100-Microtower-PC:~/TUNSTALL/board-support/linux-3.12.10-ti2013.12.01/work$
 openssl genrsa -F4 -out keys/dev.key 2048
WARNING: can't open config file: 
/tmp///sysroots/i686-arago-linux/usr/lib/ssl/openssl.cnf
Generating RSA private key, 2048 bit long modulus
+++
...+++
e is 65537 (0x10001)
srinivasan@tata-HP-Elite-7100-Microtower-PC:~/TUNSTALL/board-support/linux-3.12.10-ti2013.12.01/work$
 openssl req -batch -new -x509 -key keys/dev.key -out keys/dev.crt
WARNING: can't open config file: 
/tmp///sysroots/i686-arago-linux/usr/lib/ssl/openssl.cnf
Unable to load config info from 
/tmp///sysroots/i686-arago-linux/usr/lib/ssl/openssl.cnf

Could you pls do the needful in resolving this errors cz of which am not able 
to proceed further
Many Thanks in advance

From: s...@google.com  on behalf of Simon Glass 

Sent: Tuesday, November 4, 2014 11:42 AM
To: Srinivasan S
Cc: Jagan Teki; U-Boot Mailing List
Subject: Re: [U-Boot] verified boot of beaglebone black

Hi,

On 3 November 2014 23:09, Srinivasan S  wrote:
> Hi,
>
> Thanks a lot for your replies,
> When I was executing the below  ie., Step 5: Sign the kernel from 
> http://lists.denx.de/pipermail/u-boot/2014-June/180845.html
>
> When I was using the mkimage tools for sigining am facing the below errors, 
> could you please do the needful in resolving the below errors as early as 
> possible
>
> srinivasan@tata-HP-Elite-7100-Microtower-PC:~/TUNSTALL$ echo $PATH
> /home/srinivasan/bin:/home/srinivasan/TUNSTALL/board-support/u-boot-2014.07/b/am335x_boneblack_vboot/tools/:/home/srinivasan/TUNSTALL/board-support/u-boot-2014.07/dtc/:/opt/ti-sdk-am335x-evm-07.00.00.00/linux-devkit/sysroots/i686-arago-linux/usr/bin/:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
>
> srinivasan@tata-HP-Elite-7100-Microtower-PC:~/TUNSTALL/board-support/linux-3.12.10-ti2013.12.01/work$
>  ls
> am335x-boneblack.dtb  am335x-boneblack-pubkey.dtb  Image  keys  sign.its  
> u-boot-dtb.img
> srinivasan@tata-HP-Elite-7100-Microtower-PC:~/TUNSTALL/board-support/linux-3.12.10-ti2013.12.01/work$
>  mkimage -f sign.its -K am335x-boneblack-pubkey.dtb -k keys -r image.fit
> Error: sign.its:7.15-16 syntax error
> FATAL ERROR: Unable to parse input tree

You should check that line of the file (line 7).

> mkimage: Can't read image.fit.tmp: Invalid argument
> mkimage Can't add hashes to FIT blob
> srinivasan@tata-HP-Elite-7100-Microtower-PC:~/TUNSTALL/board-support/linux-3.12.10-ti2013.12.01/work$

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

[U-Boot] [PATCH v6 0/6] fs: fat/ext4/sandbox - Deal with files greater than 2GB

[Suriyan Ramasami]

The commands fatls/ext4ls give negative values when dealing with files
greater than 2GB.
The commands fatsize/ext4size do not update the variable filesize for
these files.

To deal with this, the fs functions have been modified to take an additional
parameter of type "* loff_t" which is then populated. The return value of the
fs functions are used only for error conditions.

Changes in v6:
* Update expected results in comments
* Simon comments -
*  Remove README file and add it in start of script
*  Drop blank lines in top of functions
*  Put repeating constants in lower case variables
*  Refer to U-Boot as U-Boot
*  Move settings to top of file and code in functions or otherwise at bottom
*  Create check_prereq function
*  Use mkfs -t  -F  for ext4, but modify for fat
* Simon - Split this into a separate patch
* Simon - Split this into a separate patch
* Simon - Split this into a separate patch
* Simon - Split this into a separate patch
* Simon - Split this into a separate patch

Changes in v5:
* Simon comments -
*   Add README file to document how to run it
*   Generate output in a sandbox environment
*   Add one line comments on shell variables used
*   Avoid camel case through out
*   Path to UBOOT is variable at top
*   Print PASSED or FAILED at end, and set return code, 0 if OK, 1 otherwise
* Simon - update fs.h with comments for fs_read/fs_write/fs_size

Suriyan Ramasami (6):
  sandbox: script for testing sandbox/ext4/fat/fs commands
  fs: interface changes to accomodate files greater than 2GB
  fat: interface changes to accomodate files greater than 2GB
  ext4: interface changes to accomodate files greater than 2GB
  sandbox: Use md5sum and fatwrite to enable testing of fs commands
  sandbox: interface changes to accomodate files greater than 2GB

 arch/sandbox/cpu/os.c |  13 +-
 arch/sandbox/cpu/state.c  |   8 +-
 common/board_f.c  |   8 +-
 common/cmd_ext4.c |  61 +
 common/cmd_fat.c  |   9 +-
 common/cmd_fs.c   |  17 ++
 common/cmd_md5sum.c   |  12 +-
 common/env_fat.c  |   4 +-
 fs/ext4/ext4_common.c |  24 +-
 fs/ext4/ext4_common.h |   4 +-
 fs/ext4/ext4_write.c  |  32 +++
 fs/ext4/ext4fs.c  |  37 +--
 fs/fat/fat.c  | 122 +-
 fs/fat/fat_write.c|  61 ++---
 fs/fat/file.c |   7 +-
 fs/fs.c   |  77 ---
 fs/sandbox/sandboxfs.c|  73 --
 include/configs/sandbox.h |   2 +
 include/ext4fs.h  |  13 +-
 include/fat.h |  19 +-
 include/fs.h  |  41 ++--
 include/os.h  |   5 +-
 include/sandboxfs.h   |  14 +-
 test/fs/fs-test.sh| 562 ++
 24 files changed, 943 insertions(+), 282 deletions(-)
 create mode 100755 test/fs/fs-test.sh

-- 
1.9.1

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

Re: [U-Boot] [PATCH 2/4] imx: mx6slevk: Add PMIC Pfuze support

[Li Ye-B37916]

Hi Przemyslaw,


On 10/30/2014 6:36 PM, Stefano Babic wrote:
> Hi Ye,
>
> On 10/09/2014 11:08, Ye.Li wrote:
>> Initialize the Pfuze on I2C1 at board late init. The mx6slevk board
>> has Pfuze100 or Pfuze200, print the chip type by parsing the ID.
>>
>> Signed-off-by: Ye.Li 
>> ---
> Slowly (sorry for that..) I am checking again all PMIC related patches
> you sent last month. However, these patches do not fit very well in the
> current development.
>
> In the last U-Boot mini summit we get the decision to post new PMIC
> drivers according to the Device Model rules. Przemyslaw is the new
> custodian for PMICs, and he will take care of all related issues
> regarding power management.

Can you share me more information about the new PMIC drivers development that 
Stefano mentioned above.
1. Have you completed the APIs define for new PMIC drivers?  If yes, where I 
can get them.
2. When will the new PMIC drivers deliver?
3. Will the PMIC devices already supported in current release stay supported by 
new PMIC drivers?

Best regards,
Ye Li
> Please rethink your patches and post them again, not forgetting to add
> Przemyslaw in CC.
>
> Best regards,
> Stefano Babic
>
>>  board/freescale/mx6slevk/mx6slevk.c |   57 
>> +++
>>  include/configs/mx6slevk.h  |7 
>>  2 files changed, 64 insertions(+), 0 deletions(-)
>>
>> diff --git a/board/freescale/mx6slevk/mx6slevk.c 
>> b/board/freescale/mx6slevk/mx6slevk.c
>> index fedd5c3..8b6a79c 100644
>> --- a/board/freescale/mx6slevk/mx6slevk.c
>> +++ b/board/freescale/mx6slevk/mx6slevk.c
>> @@ -21,6 +21,8 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>> +#include 
>>  
>>  DECLARE_GLOBAL_DATA_PTR;
>>  
>> @@ -48,6 +50,8 @@ DECLARE_GLOBAL_DATA_PTR;
>>  
>>  #define PC MUX_PAD_CTRL(I2C_PAD_CTRL)
>>  
>> +#define I2C_PMIC0
>> +
>>  /* I2C1 for PMIC */
>>  struct i2c_pads_info i2c_pad_info0 = {
>>  .sda = {
>> @@ -191,6 +195,59 @@ int board_init(void)
>>  return 0;
>>  }
>>  
>> +static int pfuze_init(void)
>> +{
>> +struct pmic *p;
>> +int ret;
>> +unsigned int reg;
>> +
>> +ret = power_pfuze100_init(I2C_PMIC);
>> +if (ret)
>> +return ret;
>> +
>> +p = pmic_get("PFUZE100");
>> +ret = pmic_probe(p);
>> +if (ret)
>> +return ret;
>> +
>> +pmic_reg_read(p, PFUZE100_DEVICEID, ®);
>> +printf("PMIC:  PFUZE%s ID=0x%02x\n",
>> +((reg & 0xf) == 0) ? "100" : "200", reg);
>> +
>> +/* Set SW1AB stanby volage to 0.975V */
>> +pmic_reg_read(p, PFUZE100_SW1ABSTBY, ®);
>> +reg &= ~0x3f;
>> +reg |= 0x1b;
>> +pmic_reg_write(p, PFUZE100_SW1ABSTBY, reg);
>> +
>> +/* Set SW1AB/VDDARM step ramp up time from 16us to 4us/25mV */
>> +pmic_reg_read(p, PUZE_100_SW1ABCONF, ®);
>> +reg &= ~0xc0;
>> +reg |= 0x40;
>> +pmic_reg_write(p, PUZE_100_SW1ABCONF, reg);
>> +
>> +/* Set SW1C standby voltage to 0.975V */
>> +pmic_reg_read(p, PFUZE100_SW1CSTBY, ®);
>> +reg &= ~0x3f;
>> +reg |= 0x1b;
>> +pmic_reg_write(p, PFUZE100_SW1CSTBY, reg);
>> +
>> +/* Set SW1C/VDDSOC step ramp up time from 16us to 4us/25mV */
>> +pmic_reg_read(p, PFUZE100_SW1CCONF, ®);
>> +reg &= ~0xc0;
>> +reg |= 0x40;
>> +pmic_reg_write(p, PFUZE100_SW1CCONF, reg);
>> +
>> +return 0;
>> +}
>> +
>> +int board_late_init(void)
>> +{
>> +pfuze_init();
>> +
>> +return 0;
>> +}
>> +
>>  u32 get_board_rev(void)
>>  {
>>  return get_cpu_rev();
>> diff --git a/include/configs/mx6slevk.h b/include/configs/mx6slevk.h
>> index bf5066f..09d0896 100644
>> --- a/include/configs/mx6slevk.h
>> +++ b/include/configs/mx6slevk.h
>> @@ -30,6 +30,7 @@
>>  #define CONFIG_SYS_MALLOC_LEN   (3 * SZ_1M)
>>  
>>  #define CONFIG_BOARD_EARLY_INIT_F
>> +#define CONFIG_BOARD_LATE_INIT
>>  #define CONFIG_MXC_GPIO
>>  
>>  #define CONFIG_MXC_UART
>> @@ -66,6 +67,12 @@
>>  #define CONFIG_SYS_I2C_MXC
>>  #define CONFIG_SYS_I2C_SPEED  10
>>  
>> +/* PMIC */
>> +#define CONFIG_POWER
>> +#define CONFIG_POWER_I2C
>> +#define CONFIG_POWER_PFUZE100
>> +#define CONFIG_POWER_PFUZE100_I2C_ADDR  0x08
>> +
>>  /* allow to overwrite serial and ethaddr */
>>  #define CONFIG_ENV_OVERWRITE
>>  #define CONFIG_CONS_INDEX   1
>>
>

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

Re: [U-Boot] [PATCH 2/3] exynos4/4x12: gpio: use gpio extra base addresses

[Przemyslaw Marczak]

Hello Minkyu,

On 10/30/2014 02:54 PM, Minkyu Kang wrote:

On 29/10/14 01:31, Przemyslaw Marczak wrote:

This patch adds extra gpio part addresses to exynos4
and exynos4x12_gpio_data arrays, which are required
since the gpio enum lists are linear

Signed-off-by: Przemyslaw Marczak 
---
  arch/arm/include/asm/arch-exynos/gpio.h | 59 ++---
  1 file changed, 39 insertions(+), 20 deletions(-)



applied to u-boot-samsung.

Thanks,
Minkyu Kang.



I thought that those patches will go through u-boot-dm, since it was a 
second version of some not merged V1 patches.


Now, the u-boot-dm/master and u-boot/master are broken for exynos4 
because of missing those few patches.


Could you please make a pull request with those patches asap?

Best regards,
--
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 2/4] imx: mx6slevk: Add PMIC Pfuze support

[Li Ye-B37916]

Hi Przemyslaw,

On 11/4/2014 5:24 PM, Li Ye-B37916 wrote:
> Hi Przemyslaw,
>
>
> On 10/30/2014 6:36 PM, Stefano Babic wrote:
>> Hi Ye,
>>
>> On 10/09/2014 11:08, Ye.Li wrote:
>>> Initialize the Pfuze on I2C1 at board late init. The mx6slevk board
>>> has Pfuze100 or Pfuze200, print the chip type by parsing the ID.
>>>
>>> Signed-off-by: Ye.Li 
>>> ---
>> Slowly (sorry for that..) I am checking again all PMIC related patches
>> you sent last month. However, these patches do not fit very well in the
>> current development.
>>
>> In the last U-Boot mini summit we get the decision to post new PMIC
>> drivers according to the Device Model rules. Przemyslaw is the new
>> custodian for PMICs, and he will take care of all related issues
>> regarding power management.
> Can you share me more information about the new PMIC drivers development that 
> Stefano mentioned above.
> 1. Have you completed the APIs define for new PMIC drivers?  If yes, where I 
> can get them.
> 2. When will the new PMIC drivers deliver?
> 3. Will the PMIC devices already supported in current release stay supported 
> by new PMIC drivers?
>
> Best regards,
> Ye Li
>> Please rethink your patches and post them again, not forgetting to add
>> Przemyslaw in CC.
>>
>> Best regards,
>> Stefano Babic
>>
>>>  board/freescale/mx6slevk/mx6slevk.c |   57 
>>> +++
>>>  include/configs/mx6slevk.h  |7 
>>>  2 files changed, 64 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/board/freescale/mx6slevk/mx6slevk.c 
>>> b/board/freescale/mx6slevk/mx6slevk.c
>>> index fedd5c3..8b6a79c 100644
>>> --- a/board/freescale/mx6slevk/mx6slevk.c
>>> +++ b/board/freescale/mx6slevk/mx6slevk.c
>>> @@ -21,6 +21,8 @@
>>>  #include 
>>>  #include 
>>>  #include 
>>> +#include 
>>> +#include 
>>>  
>>>  DECLARE_GLOBAL_DATA_PTR;
>>>  
>>> @@ -48,6 +50,8 @@ DECLARE_GLOBAL_DATA_PTR;
>>>  
>>>  #define PC MUX_PAD_CTRL(I2C_PAD_CTRL)
>>>  
>>> +#define I2C_PMIC   0
>>> +
>>>  /* I2C1 for PMIC */
>>>  struct i2c_pads_info i2c_pad_info0 = {
>>> .sda = {
>>> @@ -191,6 +195,59 @@ int board_init(void)
>>> return 0;
>>>  }
>>>  
>>> +static int pfuze_init(void)
>>> +{
>>> +   struct pmic *p;
>>> +   int ret;
>>> +   unsigned int reg;
>>> +
>>> +   ret = power_pfuze100_init(I2C_PMIC);
>>> +   if (ret)
>>> +   return ret;
>>> +
>>> +   p = pmic_get("PFUZE100");
>>> +   ret = pmic_probe(p);
>>> +   if (ret)
>>> +   return ret;
>>> +
>>> +   pmic_reg_read(p, PFUZE100_DEVICEID, ®);
>>> +   printf("PMIC:  PFUZE%s ID=0x%02x\n",
>>> +   ((reg & 0xf) == 0) ? "100" : "200", reg);
>>> +
>>> +   /* Set SW1AB stanby volage to 0.975V */
>>> +   pmic_reg_read(p, PFUZE100_SW1ABSTBY, ®);
>>> +   reg &= ~0x3f;
>>> +   reg |= 0x1b;
>>> +   pmic_reg_write(p, PFUZE100_SW1ABSTBY, reg);
>>> +
>>> +   /* Set SW1AB/VDDARM step ramp up time from 16us to 4us/25mV */
>>> +   pmic_reg_read(p, PUZE_100_SW1ABCONF, ®);
>>> +   reg &= ~0xc0;
>>> +   reg |= 0x40;
>>> +   pmic_reg_write(p, PUZE_100_SW1ABCONF, reg);
>>> +
>>> +   /* Set SW1C standby voltage to 0.975V */
>>> +   pmic_reg_read(p, PFUZE100_SW1CSTBY, ®);
>>> +   reg &= ~0x3f;
>>> +   reg |= 0x1b;
>>> +   pmic_reg_write(p, PFUZE100_SW1CSTBY, reg);
>>> +
>>> +   /* Set SW1C/VDDSOC step ramp up time from 16us to 4us/25mV */
>>> +   pmic_reg_read(p, PFUZE100_SW1CCONF, ®);
>>> +   reg &= ~0xc0;
>>> +   reg |= 0x40;
>>> +   pmic_reg_write(p, PFUZE100_SW1CCONF, reg);
>>> +
>>> +   return 0;
>>> +}
>>> +
>>> +int board_late_init(void)
>>> +{
>>> +   pfuze_init();
>>> +
>>> +   return 0;
>>> +}
>>> +
>>>  u32 get_board_rev(void)
>>>  {
>>> return get_cpu_rev();
>>> diff --git a/include/configs/mx6slevk.h b/include/configs/mx6slevk.h
>>> index bf5066f..09d0896 100644
>>> --- a/include/configs/mx6slevk.h
>>> +++ b/include/configs/mx6slevk.h
>>> @@ -30,6 +30,7 @@
>>>  #define CONFIG_SYS_MALLOC_LEN  (3 * SZ_1M)
>>>  
>>>  #define CONFIG_BOARD_EARLY_INIT_F
>>> +#define CONFIG_BOARD_LATE_INIT
>>>  #define CONFIG_MXC_GPIO
>>>  
>>>  #define CONFIG_MXC_UART
>>> @@ -66,6 +67,12 @@
>>>  #define CONFIG_SYS_I2C_MXC
>>>  #define CONFIG_SYS_I2C_SPEED 10
>>>  
>>> +/* PMIC */
>>> +#define CONFIG_POWER
>>> +#define CONFIG_POWER_I2C
>>> +#define CONFIG_POWER_PFUZE100
>>> +#define CONFIG_POWER_PFUZE100_I2C_ADDR 0x08
>>> +
>>>  /* allow to overwrite serial and ethaddr */
>>>  #define CONFIG_ENV_OVERWRITE
>>>  #define CONFIG_CONS_INDEX  1
>>>

Please help to answer my questions in the emails thread.  A incorrect email 
address was given, so I resend the email now.

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

Re: [U-Boot] verifying & signing

[Srinivasan S]

Hi Simon,

When I was generating the keys ie., Step 4: Create a key pair

Am facing one more error while generating private key & certificate containing 
public key used for verification when I execute the below openssl commands it 
is saying can't open  config file:

srinivasan@tata-HP-Elite-7100-Microtower-PC:~/TUNSTALL/board-support/linux-3.12.10-ti2013.12.01/work$
 openssl genrsa -F4 -out keys/dev.key 2048
WARNING: can't open config file: 
/tmp///sysroots/i686-arago-linux/usr/lib/ssl/openssl.cnf
Generating RSA private key, 2048 bit long modulus
+++
...+++
e is 65537 (0x10001)
srinivasan@tata-HP-Elite-7100-Microtower-PC:~/TUNSTALL/board-support/linux-3.12.10-ti2013.12.01/work$
 openssl req -batch -new -x509 -key keys/dev.key -out keys/dev.crt
WARNING: can't open config file: 
/tmp///sysroots/i686-arago-linux/usr/lib/ssl/openssl.cnf
Unable to load config info from 
/tmp///sysroots/i686-arago-linux/usr/lib/ssl/openssl.cnf

Could you pls do the needful in resolving this errors cz of which am not able 
to proceed further

Many Thanks in advance


From: s...@google.com  on behalf of Simon Glass 

Sent: Tuesday, November 4, 2014 12:07 PM
To: Srinivasan S
Cc: srinivasan; U-Boot Mailing List
Subject: Re: verifying & signing

Hi,

On 3 November 2014 20:01, Srinivasan S  wrote:
> Hi Simon,
>
> Good Morning!
>
> Many Thanks a lot for all your support so far,
>
> 1. With respect to the verified boot , I want to put the images onto NAND 
> FLASH, Could you please let me know what is the procedure of flashing  the 
> verified boot images onto NAND instead of micro-SD

One option would be to use UBI to provide a consistent block interface
and then sit verity on top of that. But there may be other options,
I'm not sure.

>
> 2.Does dm-verity works only on read-only rootfs?.. or it works on read-write 
> rootfs?.. because as of  now we are looking out only for a bare minimal 
> rootfs , could you please suggest me if any rootfs with minimal support where 
> dm-verity can be applied & verified apart from android

It requires a read-only rootfs. You can enable it on a filesystem
fairly easily - you need to run a tool to generate the hashes and root
hash, then pass that to the kernel on boot. You don't need to use
Android or Chrome OS - it is available in mainline Linux. I'm not sure
if there is a cogent guide somewhere though.

>
>  I want to implement the automatic software update & recovery feature (ie., 
> firmware update of uboot, kernel & rootfs) in ti-sdk-am335x-evm-07.00.00.00 
> BSP's , if in case if it bricks to unbrick by itself,
>  Could you please help me with suitable pointers & source code links for 
> implementing this feature

This is one way.

http://www.chromium.org/chromium-os/u-boot-porting-guide/2-concepts

So ensure there can be no bricking you probably need to have a U-Boot
that you never update. It can then check the signature of a secondary
updateable U-Boot, and jump to it if it is OK. This is what Chrome OS
does.

BTW as this is a mailing list you should normally put the replies
below the text, not above.

Regards,
Simon


>
> Awaiting for your replies
> Many Thanks in advance again,
>
> Srinivasan S
>
>
> 
> From: s...@google.com  on behalf of Simon Glass 
> 
> Sent: Monday, November 3, 2014 5:08 AM
> To: srinivasan
> Cc: U-Boot Mailing List; Srinivasan S
> Subject: Re: verifying & signing
>
> Hi,
>
> On 2 November 2014 07:06, srinivasan  wrote:
>>
>>
>>
>>
>> Hi Simon,
>>
>> http://lists.denx.de/pipermail/u-boot/2014-June/180845.html
>>
>> As the above link explains the Signing of kernel & verifying with uboot,
>>
>> Could you please let me know do you have any methods of signing & verifying
>> the linux kernel with root file system ie., am using
>> ti-sdk-am335x-evm-07.00.00.00 BSP's where linux kernel is from this BSP only
>> & would be planning to use rootfs as my Angstrom filesystem or any others
>
> If you use dm-verity you can verify your root disk using a hash which
> is stored in the verified part of U-Boot. This is the method used by
> Chrome OS. This requires a read-only rootfs though. Is that
> acceptable?
>
> See this page for some info on how Android does this:
>
> https://source.android.com/devices/tech/security/dm-verity.html
>
>>
>> Could you please let me know h

Re: [U-Boot] verifying & signing

[Srinivasan S]

Hi Simon,



From: s...@google.com  on behalf of Simon Glass 

Sent: Tuesday, November 4, 2014 12:07 PM
To: Srinivasan S
Cc: srinivasan; U-Boot Mailing List
Subject: Re: verifying & signing

Hi,

On 3 November 2014 20:01, Srinivasan S  wrote:
> Hi Simon,
>
> Good Morning!
>
> Many Thanks a lot for all your support so far,
>
> 1. With respect to the verified boot , I want to put the images onto NAND 
> FLASH, Could you please let me know what is the procedure of flashing  the 
> verified boot images onto NAND instead of micro-SD

One option would be to use UBI to provide a consistent block interface
and then sit verity on top of that. But there may be other options,
I'm not sure.

>
> 2.Does dm-verity works only on read-only rootfs?.. or it works on read-write 
> rootfs?.. because as of  now we are looking out only for a bare minimal 
> rootfs , could you please suggest me if any rootfs with minimal support where 
> dm-verity can be applied & verified apart from android

It requires a read-only rootfs. You can enable it on a filesystem
fairly easily - you need to run a tool to generate the hashes and root
hash, then pass that to the kernel on boot. You don't need to use
Android or Chrome OS - it is available in mainline Linux. I'm not sure
if there is a cogent guide somewhere though.

>
>  I want to implement the automatic software update & recovery feature (ie., 
> firmware update of uboot, kernel & rootfs) in ti-sdk-am335x-evm-07.00.00.00 
> BSP's , if in case if it bricks to unbrick by itself,
>  Could you please help me with suitable pointers & source code links for 
> implementing this feature

This is one way.

http://www.chromium.org/chromium-os/u-boot-porting-guide/2-concepts

So ensure there can be no bricking you probably need to have a U-Boot
that you never update. It can then check the signature of a secondary
updateable U-Boot, and jump to it if it is OK. This is what Chrome OS
does.

BTW as this is a mailing list you should normally put the replies
below the text, not above.

Regards,
Simon


>
> Awaiting for your replies
> Many Thanks in advance again,
>
> Srinivasan S
>
>
> 
> From: s...@google.com  on behalf of Simon Glass 
> 
> Sent: Monday, November 3, 2014 5:08 AM
> To: srinivasan
> Cc: U-Boot Mailing List; Srinivasan S
> Subject: Re: verifying & signing
>
> Hi,
>
> On 2 November 2014 07:06, srinivasan  wrote:
>>
>>
>>
>>
>> Hi Simon,
>>
>> http://lists.denx.de/pipermail/u-boot/2014-June/180845.html
>>
>> As the above link explains the Signing of kernel & verifying with uboot,
>>
>> Could you please let me know do you have any methods of signing & verifying
>> the linux kernel with root file system ie., am using
>> ti-sdk-am335x-evm-07.00.00.00 BSP's where linux kernel is from this BSP only
>> & would be planning to use rootfs as my Angstrom filesystem or any others
>
> If you use dm-verity you can verify your root disk using a hash which
> is stored in the verified part of U-Boot. This is the method used by
> Chrome OS. This requires a read-only rootfs though. Is that
> acceptable?
>
> See this page for some info on how Android does this:
>
> https://source.android.com/devices/tech/security/dm-verity.html
>
>>
>> Could you please let me know how do we sign & verify the kernel with rootfs
>> with detailed steps as am using beaglebone black as my development board
>> with ti-sdk-am335x-evm-07.00.00.00 BSP's
>
> I don't have details steps of this part sorry. An overview is here:
>
> http://events.linuxfoundation.org/sites/events/files/slides/chromeos_and_diy_vboot_0.pdf
>
>
>>
>> Awaiting for your replies
>> Many Thanks in advance
>>
>>
>>
>
> Regards,
> Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] wrong uboot type in uboot binary

[pegasus711]

I cross compiled u-boot's latest version 2014-10 using buildroot's built-in
cross compiler and generated uboot.bin.

When I try to invoke it like so:



it throws an error complaining wrong image format:


I've checked qemu's sources and as per the following file , the only valid
type numbers are from 0 through to 8. I am unable to understand the number
52 here. Any pointers?

Is there a way to hex dump the contents of the binary to find out its image
type to make sure if my image is indeed having an unknown type 52 or is the
problem something else?



--
View this message in context: 
http://u-boot.10912.n7.nabble.com/wrong-uboot-type-in-uboot-binary-tp194499.html
Sent from the U-Boot mailing list archive at Nabble.com.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 1/3] usb:ehci-mx6 add board_ehci_usb_mode function

[Marek Vasut]

On Tuesday, November 04, 2014 at 08:50:00 AM, Peng Fan wrote:
> Include a weak function board_ehci_usb_mode to gives board code
> a choice.

What choice?

> If the board want the otg port work in host mode but not
> device mode, this should be handled.

How?

Also, isn't usb_phy_enable() supposed to do exactly this kind of selection
between device and host mode ?

> Signed-off-by: Peng Fan 
> Signed-off-by: Ye Li 
> ---
> 
> Changes v2:
>  Introduce a new weak function to let board have a choice to decide which
> mode to work at.
> 
>  drivers/usb/host/ehci-mx6.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/usb/host/ehci-mx6.c b/drivers/usb/host/ehci-mx6.c
> index 9ec5a0a..3662a80 100644
> --- a/drivers/usb/host/ehci-mx6.c
> +++ b/drivers/usb/host/ehci-mx6.c
> @@ -193,6 +193,11 @@ static void usb_oc_config(int index)
>   __raw_writel(val, ctrl);
>  }
> 
> +int __weak board_ehci_usb_mode(int index, enum usb_init_type *type)
> +{
> + return 0;
> +}
> +
>  int __weak board_ehci_hcd_init(int port)
>  {
>   return 0;
> @@ -223,6 +228,8 @@ int ehci_hcd_init(int index, enum usb_init_type init,
>   usb_internal_phy_clock_gate(index, 1);
>   type = usb_phy_enable(index, ehci) ? USB_INIT_DEVICE : USB_INIT_HOST;
> 
> + board_ehci_usb_mode(index, &type);
> +
>   *hccr = (struct ehci_hccr *)((uint32_t)&ehci->caplength);
>   *hcor = (struct ehci_hcor *)((uint32_t)*hccr +
>   HC_LENGTH(ehci_readl(&(*hccr)->cr_capbase)));

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 v2 0/3] imx:mx6 add usb support

[Marek Vasut]

On Tuesday, November 04, 2014 at 08:49:59 AM, Peng Fan wrote:

So uh, what exactly does this patchset do ? It's not clear at all from the
subject and any description is completely missing.

To my knowledge, i.MX6 already does have USB support in U-Boot, so the subject
is misleading as well.

> Changes v2:
>  - move pinmux setting into board_init
>  - add otg polarity setting in board_ehci_hcd_init
>  - Introduce a new weak function to give board a choice to decide the work
> mode of the otg port, since a otg port can also work in host mode without
> touch ID pin.
> 
> Peng Fan (3):
>   usb:ehci-mx6 add board_ehci_usb_mode function
>   imx:mx6sxsabresd add usb support
>   imx:mx6slevk add usb support
> 
>  arch/arm/include/asm/arch-mx6/mx6sl_pins.h  |  5 +++
>  board/freescale/mx6slevk/mx6slevk.c | 51
> + board/freescale/mx6sxsabresd/mx6sxsabresd.c
> | 51 + drivers/usb/host/ehci-mx6.c
> |  7 
>  include/configs/mx6slevk.h  | 14 
>  include/configs/mx6sxsabresd.h  | 14 
>  6 files changed, 142 insertions(+)

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 2/3] exynos4/4x12: gpio: use gpio extra base addresses

[Minkyu Kang]

On 04/11/14 18:29, Przemyslaw Marczak wrote:
> Hello Minkyu,
> 
> On 10/30/2014 02:54 PM, Minkyu Kang wrote:
>> On 29/10/14 01:31, Przemyslaw Marczak wrote:
>>> This patch adds extra gpio part addresses to exynos4
>>> and exynos4x12_gpio_data arrays, which are required
>>> since the gpio enum lists are linear
>>>
>>> Signed-off-by: Przemyslaw Marczak 
>>> ---
>>>   arch/arm/include/asm/arch-exynos/gpio.h | 59 
>>> ++---
>>>   1 file changed, 39 insertions(+), 20 deletions(-)
>>>
>>
>> applied to u-boot-samsung.
>>
>> Thanks,
>> Minkyu Kang.
>>
> 
> I thought that those patches will go through u-boot-dm, since it was a second 
> version of some not merged V1 patches.
> 
> Now, the u-boot-dm/master and u-boot/master are broken for exynos4 because of 
> missing those few patches.
> 
> Could you please make a pull request with those patches asap?
> 
> Best regards,

ok.

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

Re: [U-Boot] [PATCH v2 1/3] usb:ehci-mx6 add board_ehci_usb_mode function

[Peng Fan]

在 11/4/2014 6:33 PM, Marek Vasut 写道:

On Tuesday, November 04, 2014 at 08:50:00 AM, Peng Fan wrote:

Include a weak function board_ehci_usb_mode to gives board code
a choice.


What choice?


If the board want the otg port work in host mode but not
device mode, this should be handled.


How?

Also, isn't usb_phy_enable() supposed to do exactly this kind of selection
between device and host mode ?


In mx6sxsabresd board, there are two usb port, one used for otg, the 
other used for host. However they are connected to SOC USB controller 
otg1 core and otg2 core respectively. Like following:


OTG1 CORE <> board otg port
OTG2 CORE <> board host port

However the board do not have ID pin set for board host port. If just 
use usb_phy_enable, the board host port will not work, because
"type = usb_phy_enable(index, ehci) ? USB_INIT_DEVICE : USB_INIT_HOST;" 
will always set type with USB_INIT_DEVICE.


Because i did not find way to handle this situation in 
board/freescale/mx6sxsabresd/mx6sxsabresd.c, add this function to let 
board level code handle handle 'type', if board level code want to set 
it's own 'type'.





Signed-off-by: Peng Fan 
Signed-off-by: Ye Li 
---

Changes v2:
  Introduce a new weak function to let board have a choice to decide which
mode to work at.

  drivers/usb/host/ehci-mx6.c | 7 +++
  1 file changed, 7 insertions(+)

diff --git a/drivers/usb/host/ehci-mx6.c b/drivers/usb/host/ehci-mx6.c
index 9ec5a0a..3662a80 100644
--- a/drivers/usb/host/ehci-mx6.c
+++ b/drivers/usb/host/ehci-mx6.c
@@ -193,6 +193,11 @@ static void usb_oc_config(int index)
__raw_writel(val, ctrl);
  }

+int __weak board_ehci_usb_mode(int index, enum usb_init_type *type)
+{
+   return 0;
+}
+
  int __weak board_ehci_hcd_init(int port)
  {
return 0;
@@ -223,6 +228,8 @@ int ehci_hcd_init(int index, enum usb_init_type init,
usb_internal_phy_clock_gate(index, 1);
type = usb_phy_enable(index, ehci) ? USB_INIT_DEVICE : USB_INIT_HOST;

+   board_ehci_usb_mode(index, &type);
+
*hccr = (struct ehci_hccr *)((uint32_t)&ehci->caplength);
*hcor = (struct ehci_hcor *)((uint32_t)*hccr +
HC_LENGTH(ehci_readl(&(*hccr)->cr_capbase)));


Best regards,
Marek Vasut


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

Re: [U-Boot] [PATCH v2 3/4] odroid: make some macros common

[Minkyu Kang]

Dear Hyungwon Hwang,

On 04/11/14 17:29, Lukasz Majewski wrote:
> Hi Hyungwon,
> 
>> On Mon, 03 Nov 2014 09:51:25 +0100
>> Lukasz Majewski  wrote:
>>
>>> Hi Hyungwon,
>>>
 Some macros are used commonly for odroid series boards. This patch
 makes a common header file to congregate that kinds of macros.
 Even though there are more macros which can be common, they are
 not become common. Because they are a part of a register, the
 readability is better when they are defined at a place.

 Signed-off-by: Hyungwon Hwang 
 ---
  board/samsung/odroid/odroid.c | 1 +
  board/samsung/odroid/setup.h  | 8 
  2 files changed, 1 insertion(+), 8 deletions(-)

>>>
>>> I suspect that you have not added the new file to git repository -
>>> since you only removed lines from board/samsung/odroid/setup.h
>>>
>>> I also guess that odroid U3 will not build anymore. That is a very
>>> good use case for buildman script.
>>
>> Oh. It is my mistake. I will include the common header in next
>> version.
>>
>>>
 diff --git a/board/samsung/odroid/odroid.c
 b/board/samsung/odroid/odroid.c index 5edb250..ccbb3a0 100644
 --- a/board/samsung/odroid/odroid.c
 +++ b/board/samsung/odroid/odroid.c
 @@ -18,6 +18,7 @@
  #include 
  #include 
  #include 
 +#include "../setup.h"
>>>
>>> Relative path is not a good idea IMHO.
>>>
>>> It would be better to place it at ./include/samsung/ with a self
>>> explanatory name (like exynos4-pll.h or/and exynos4-{other excluded
>>> defines for an IP blocks}).
>>>
>>> In this way other boards could use those defines too.
>>
>> I think that your idea is better than mine.
>>
>>>
  #include "setup.h"
  
  DECLARE_GLOBAL_DATA_PTR;
 diff --git a/board/samsung/odroid/setup.h
 b/board/samsung/odroid/setup.h index 3e48dad..35f7af5 100644
 --- a/board/samsung/odroid/setup.h
 +++ b/board/samsung/odroid/setup.h
 @@ -8,14 +8,6 @@
  #ifndef __ODROIDU3_SETUP__
  #define __ODROIDU3_SETUP__
  
 -/* A/M PLL_CON0 */
 -#define SDIV(x) ((x) & 0x7)
 -#define PDIV(x) (((x) & 0x3f) << 8)
 -#define MDIV(x) (((x) & 0x3ff) << 16)
 -#define FSEL(x) (((x) & 0x1) << 27)
 -#define PLL_LOCKED_BIT  (0x1 << 29)
 -#define PLL_ENABLE(x)   (((x) & 0x1) << 31)
 -
>>>
>>> The above data is common for Exynos U3 and XU3, but is it the only
>>> one? Aren't there any more defines to be extracted?
>>>
  /* CLK_SRC_CPU */
  #define MUX_APLL_SEL(x) ((x) & 0x1)
  #define MUX_CORE_SEL(x) (((x) & 0x1) << 16)
>>>
>>>
>>>
>>
>> You're right. I found some other common macros more now. I will
>> reflect it in next version. But I have a doubt about MUX_APLL_SEL or
>> something else which consist of a register with different macros in
>> different processors. They can be extracted to common file. But is it
>> good to do it? For example, MUX_APLL_SEL exists both in Exynos4 and
>> Exynos5's CLK_SRC_CPU.
>>
>> Exynos 4412
>> /* CLK_SRC_CPU */
>> #define MUX_APLL_SEL(x)  ((x) & 0x1)
>> #define MUX_CORE_SEL(x)  (((x) & 0x1) << 16)
>>
>> Exynos 5800
>> /* CLK_SRC_CPU */
>> #define MUX_APLL_SEL(x) ((x) & 0x1)
>> #define MUX_CORE_SEL(x) (((x) & 0x1)
>> #define MUX_HPM_SEL(x)  (((x) & 0x1) << 20)
>> #define MUX_MPLL_USER_SEL_C(x)  (((x) & 0x1) << 24)
> 
> It is always a matter of pragmatism.  In the above case you could only
> extract MUX_APLL_SEL(x). But is it worth to add a separate header file
> for only one line? In my opinion not.
> 
>>
>> If MUX_APLL_SEL and MUX_CORE_SEL are extracted to the common file, it
>> will be harder to see what consist of CLK_SRC_CPU at a glance. Isn't
>> it? This situation is worse in the case of APLL_RATIO. (Please see
>> the below.) I want to hear your opinion about it.
>>
>> Exynos 4412
>> /* CLK_DIV_CPU0 */
>> #define ARM_RATIO(x)   ((x) & 0x7)
>> #define CPUD_RATIO(x) (((x) & 0x7) << 4)
>> #define ATB_RATIO(x) (((x) & 0x7) << 16)
>> #define PCLK_DBG_RATIO(x)   (((x) & 0x7) << 20)
>> #define APLL_RATIO(x)   (((x) & 0x7) << 24)
>> #define ARM2_RATIO(x) (((x) & 0x7) << 28)
>>
>> Exynos 5800
>> /* CLK_DIV_CPU0 */
>> #define CORE_RATIO(x)   ((x) & 0x7)
>> #define COREM0_RATIO(x) (((x) & 0x7) << 4)
>> #define COREM1_RATIO(x) (((x) & 0x7) << 8)
>> #define PERIPH_RATIO(x) (((x) & 0x7) << 12)
>> #define ATB_RATIO(x)(((x) & 0x7) << 16)
>> #define PCLK_DBG_RATIO(x)   (((x) & 0x7) << 20)
>> #define APLL_RATIO(x)   (((x) & 0x7) << 24)
>> #define CORE2_RATIO(x)  (((x) & 0x7) << 28)
> 
> Readability is important. Also please pay a note that ARM2_RATIO() is
> the same as CORE2_RATIO(). Frankly I don't know why those defines have
> different names.
> 
> To sum up:
> 
> When you see a potential to extract a common data and it jus

[U-Boot] please pull u-boot-samsung master

[Minkyu Kang]

Dear Tom,

The following changes since commit 571bdf16a78e9e116a93d46f4809c4f8a3f2adb6:

  arm: interrupt_init: set sp in IRQ/FIQ modes (2014-10-29 09:03:28 -0400)

are available in the git repository at:

  http://git.denx.de/u-boot-samsung 

for you to fetch changes up to 4aa97312f7147b68b8b7c731d7bb01cff8dda2d6:

  odroid: adjust gpio calls to dm gpio api (2014-10-30 19:56:16 +0900)


Przemyslaw Marczak (3):
  exynos4/4x12: cpu: add extra gpio base addresses
  exynos4/4x12: gpio: use gpio extra base addresses
  odroid: adjust gpio calls to dm gpio api

 arch/arm/include/asm/arch-exynos/cpu.h  |9 +
 arch/arm/include/asm/arch-exynos/gpio.h |   59 ---
 board/samsung/odroid/odroid.c   |   11 +-
 3 files changed, 58 insertions(+), 21 deletions(-)
-- 
Thanks,
Minkyu Kang.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 1/3] usb:ehci-mx6 add board_ehci_usb_mode function

[Marek Vasut]

On Tuesday, November 04, 2014 at 11:50:29 AM, Peng Fan wrote:
> 在 11/4/2014 6:33 PM, Marek Vasut 写道:
> > On Tuesday, November 04, 2014 at 08:50:00 AM, Peng Fan wrote:
> >> Include a weak function board_ehci_usb_mode to gives board code
> >> a choice.
> > 
> > What choice?
> > 
> >> If the board want the otg port work in host mode but not
> >> device mode, this should be handled.
> > 
> > How?
> > 
> > Also, isn't usb_phy_enable() supposed to do exactly this kind of
> > selection between device and host mode ?
> 
> In mx6sxsabresd board, there are two usb port, one used for otg, the
> other used for host. However they are connected to SOC USB controller
> otg1 core and otg2 core respectively. Like following:
> 
> OTG1 CORE <> board otg port
> OTG2 CORE <> board host port
> 
> However the board do not have ID pin set for board host port. If just
> use usb_phy_enable, the board host port will not work, because
> "type = usb_phy_enable(index, ehci) ? USB_INIT_DEVICE : USB_INIT_HOST;"
> will always set type with USB_INIT_DEVICE.
> 
> Because i did not find way to handle this situation in
> board/freescale/mx6sxsabresd/mx6sxsabresd.c, add this function to let
> board level code handle handle 'type', if board level code want to set
> it's own 'type'.

This part in usb_phy_enable()

163 return val & USBPHY_CTRL_OTG_ID;

should be replaced by some kind of a board-specific callback then, with
default implmentation being the above (reading the phy ctrl register).

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

[U-Boot] [PATCH] doc: fix documentation of output directory

[Timo Ketola]

Correct environment variable is KBUILD_OUTPUT.

Signed-off-by: Timo Ketola 
---
 README  |6 +++---
 doc/README.kwbimage |4 ++--
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/README b/README
index 7b5538e..c3a9dfc 100644
--- a/README
+++ b/README
@@ -5012,14 +5012,14 @@ this behavior and build U-Boot to some external 
directory:
make O=/tmp/build NAME_defconfig
make O=/tmp/build all
 
-2. Set environment variable BUILD_DIR to point to the desired location:
+2. Set environment variable KBUILD_OUTPUT to point to the desired location:
 
-   export BUILD_DIR=/tmp/build
+   export KBUILD_OUTPUT=/tmp/build
make distclean
make NAME_defconfig
make all
 
-Note that the command line "O=" setting overrides the BUILD_DIR environment
+Note that the command line "O=" setting overrides the KBUILD_OUTPUT environment
 variable.
 
 
diff --git a/doc/README.kwbimage b/doc/README.kwbimage
index 13f6f92..8c02298 100644
--- a/doc/README.kwbimage
+++ b/doc/README.kwbimage
@@ -30,10 +30,10 @@ kwbimage support available with mkimage utility will 
generate kirkwood boot
 image that can be flashed on the board NAND/SPI flash.  The make target
 which uses mkimage to produce such an image is "u-boot.kwb".  For example:
 
-  export BUILD_DIR=/tmp/build
+  export KBUILD_OUTPUT=/tmp/build
   make distclean
   make yourboard_config
-  make $BUILD_DIR/u-boot.kwb
+  make $KBUILD_OUTPUT/u-boot.kwb
 
 
 Board specific configuration file specifications:
-- 
1.7.9.5

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

[U-Boot] [PATCH 2/6] include/common.h: remove DIV_ROUND definition

[Masahiro Yamada]

All the references of DIV_ROUND have been replaced with
DIV_ROUND_CLOSEST.  Remove DIV_ROUND.

Signed-off-by: Masahiro Yamada 
---

 include/common.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/include/common.h b/include/common.h
index ecf7fca..c9fe386 100644
--- a/include/common.h
+++ b/include/common.h
@@ -950,7 +950,6 @@ static inline phys_addr_t map_to_sysmem(const void *ptr)
 #define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))
 
 #define ROUND(a,b) (((a) + (b) - 1) & ~((b) - 1))
-#define DIV_ROUND(n,d) (((n) + ((d)/2)) / (d))
 #define DIV_ROUND_UP(n,d)  (((n) + (d) - 1) / (d))
 #define roundup(x, y)  x) + ((y) - 1)) / (y)) * (y))
 
-- 
1.9.1

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

[U-Boot] [PATCH 4/6] linux/kernel.h: import more macros

[Masahiro Yamada]

These macros seem to be useful for U-Boot too (or at least
harmless).  Imported from Linux 3.18-rc2.

Signed-off-by: Masahiro Yamada 
---

 include/linux/kernel.h | 104 +
 1 file changed, 104 insertions(+)

diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index 28276bd..f84a764 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -4,16 +4,41 @@
 
 #include 
 
+#define USHRT_MAX  ((u16)(~0U))
+#define SHRT_MAX   ((s16)(USHRT_MAX>>1))
+#define SHRT_MIN   ((s16)(-SHRT_MAX - 1))
 #define INT_MAX((int)(~0U>>1))
 #define INT_MIN(-INT_MAX - 1)
+#define UINT_MAX   (~0U)
+#define LONG_MAX   ((long)(~0UL>>1))
+#define LONG_MIN   (-LONG_MAX - 1)
+#define ULONG_MAX  (~0UL)
 #define LLONG_MAX  ((long long)(~0ULL>>1))
+#define LLONG_MIN  (-LLONG_MAX - 1)
+#define ULLONG_MAX (~0ULL)
+#define SIZE_MAX   (~(size_t)0)
 
 #define U8_MAX ((u8)~0U)
+#define S8_MAX ((s8)(U8_MAX>>1))
+#define S8_MIN ((s8)(-S8_MAX - 1))
+#define U16_MAX((u16)~0U)
+#define S16_MAX((s16)(U16_MAX>>1))
+#define S16_MIN((s16)(-S16_MAX - 1))
 #define U32_MAX((u32)~0U)
+#define S32_MAX((s32)(U32_MAX>>1))
+#define S32_MIN((s32)(-S32_MAX - 1))
 #define U64_MAX((u64)~0ULL)
+#define S64_MAX((s64)(U64_MAX>>1))
+#define S64_MIN((s64)(-S64_MAX - 1))
+
+#define STACK_MAGIC0xdeadbeef
+
+#define REPEAT_BYTE(x) ((~0ul / 0xff) * (x))
 
 #define ALIGN(x,a) __ALIGN_MASK((x),(typeof(x))(a)-1)
 #define __ALIGN_MASK(x,mask)   (((x)+(mask))&~(mask))
+#define PTR_ALIGN(p, a)((typeof(p))ALIGN((unsigned long)(p), 
(a)))
+#define IS_ALIGNED(x, a)   (((x) & ((typeof(x))(a) - 1)) == 0)
 
 #define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))
 
@@ -27,10 +52,24 @@
 #define round_up(x, y) x)-1) | __round_mask(x, y))+1)
 #define round_down(x, y) ((x) & ~__round_mask(x, y))
 
+#define FIELD_SIZEOF(t, f) (sizeof(((t*)0)->f))
 #define DIV_ROUND_UP(n,d) (((n) + (d) - 1) / (d))
 
+#if BITS_PER_LONG == 32
+# define DIV_ROUND_UP_SECTOR_T(ll,d) DIV_ROUND_UP_ULL(ll, d)
+#else
+# define DIV_ROUND_UP_SECTOR_T(ll,d) DIV_ROUND_UP(ll,d)
+#endif
+
 #define roundup(x, y)  x) + ((y) - 1)) / (y)) * (y))
 
+#define rounddown(x, y) (  \
+{  \
+   typeof(x) __x = (x);\
+   __x - (__x % (y));  \
+}  \
+)
+
 /*
  * Divide positive or negative dividend by positive divisor and round
  * to closest integer. Result is undefined for negative divisors and
@@ -47,6 +86,18 @@
 }  \
 )
 
+/*
+ * Multiplies an integer by a fraction, while avoiding unnecessary
+ * overflow or loss of precision.
+ */
+#define mult_frac(x, numer, denom)(\
+{  \
+   typeof(x) quot = (x) / (denom); \
+   typeof(x) rem  = (x) % (denom); \
+   (quot * (numer)) + ((rem * (numer)) / (denom)); \
+}  \
+)
+
 /**
  * upper_32_bits - return bits 32-63 of a number
  * @n: the number we're accessing
@@ -115,6 +166,27 @@
_max1 > _max2 ? (_max1 > _max3 ? _max1 : _max3) : \
(_max2 > _max3 ? _max2 : _max3); })
 
+/**
+ * min_not_zero - return the minimum that is _not_ zero, unless both are zero
+ * @x: value1
+ * @y: value2
+ */
+#define min_not_zero(x, y) ({  \
+   typeof(x) __x = (x);\
+   typeof(y) __y = (y);\
+   __x == 0 ? __y : ((__y == 0) ? __x : min(__x, __y)); })
+
+/**
+ * clamp - return a value clamped to a given range with strict typechecking
+ * @val: current value
+ * @lo: lowest allowable value
+ * @hi: highest allowable value
+ *
+ * This macro does strict typechecking of lo/hi to make sure they are of the
+ * same type as val.  See the unnecessary pointer comparisons.
+ */
+#define clamp(val, lo, hi) min((typeof(val))max(val, lo), hi)
+
 /*
  * ..and if you can't take the strict
  * types, you can specify one yourself.
@@ -132,6 +204,38 @@
__max1 > __max2 ? __max1: __max2; })
 
 /**
+ * clamp_t - return a value clamped to a given range using a given type
+ * @type: the type of variable to use
+ * @val: current value
+ * @lo: minimum allowable value
+ * @hi: maximum allowable value
+ *
+ * This macro does no typechecking and uses temporary variables of type
+ * 'type' to make all the comparisons.
+ */
+#define clamp_t(type, val, lo, hi) min_t(type, max_t(type, val, lo), hi)
+
+/**
+ * clamp_val - return a value clamped to a given range using val's type
+ * 

[U-Boot] [PATCH 5/6] linux/kernel.h: add typechecking to roundup macro

[Masahiro Yamada]

This commit replaces roundup macro with the one from Linux Kernel.

DEFINE_ALIGN_BUFFER must be fixed because typechecking can not
be used in this context.

Signed-off-by: Masahiro Yamada 
---

 include/common.h   | 2 +-
 include/linux/kernel.h | 9 +++--
 2 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/include/common.h b/include/common.h
index c1bdaec..ce0a734 100644
--- a/include/common.h
+++ b/include/common.h
@@ -967,7 +967,7 @@ static inline phys_addr_t map_to_sysmem(const void *ptr)
  * Usage of this macro shall be avoided or used with extreme care!
  */
 #define DEFINE_ALIGN_BUFFER(type, name, size, align)   \
-   static char __##name[roundup(size * sizeof(type), align)]   \
+   static char __##name[ALIGN(size * sizeof(type), align)] \
__aligned(align);   \
\
static type *name = (type *)__##name
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index f84a764..0e838de 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -61,8 +61,13 @@
 # define DIV_ROUND_UP_SECTOR_T(ll,d) DIV_ROUND_UP(ll,d)
 #endif
 
-#define roundup(x, y)  x) + ((y) - 1)) / (y)) * (y))
-
+/* The `const' in roundup() prevents gcc-3.3 from calling __divdi3 */
+#define roundup(x, y) (\
+{  \
+   const typeof(y) __y = y;\
+   (((x) + (__y - 1)) / __y) * __y;\
+}  \
+)
 #define rounddown(x, y) (  \
 {  \
typeof(x) __x = (x);\
-- 
1.9.1

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

[U-Boot] [PATCH 1/6] replace DIV_ROUND with DIV_ROUND_CLOSEST

[Masahiro Yamada]

The Linux-compatible macro DIV_ROUND_CLOSEST is a bit more flexible
and safer than DIV_ROUND.

For example,
  foo = DIV_ROUND_CLOSEST(x, y++)
works expectedly, but
  foo = DIV_ROUND(x, y++)
does not. (y is incremented twice.)

Signed-off-by: Masahiro Yamada 
---

 arch/arm/cpu/arm926ejs/mxs/spl_power_init.c | 3 ++-
 arch/arm/cpu/armv7/omap-common/abb.c| 6 +++---
 drivers/misc/mxc_ocotp.c| 4 ++--
 lib/strmhz.c| 4 ++--
 4 files changed, 9 insertions(+), 8 deletions(-)

diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c 
b/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c
index d25019a..1c54ab7 100644
--- a/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c
+++ b/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c
@@ -1002,7 +1002,8 @@ static void mxs_power_set_vddx(const struct mxs_vddx_cfg 
*cfg,
uint32_t powered_by_linreg = 0;
int adjust_up, tmp;
 
-   new_brownout = DIV_ROUND(new_target - new_brownout, cfg->step_mV);
+   new_brownout = DIV_ROUND_CLOSEST(new_target - new_brownout,
+cfg->step_mV);
 
cur_target = readl(cfg->reg);
cur_target &= cfg->trg_mask;
diff --git a/arch/arm/cpu/armv7/omap-common/abb.c 
b/arch/arm/cpu/armv7/omap-common/abb.c
index 423aeb9..a0add66 100644
--- a/arch/arm/cpu/armv7/omap-common/abb.c
+++ b/arch/arm/cpu/armv7/omap-common/abb.c
@@ -48,9 +48,9 @@ static void abb_setup_timings(u32 setup)
 */
 
/* calculate SR2_WTCNT_VALUE */
-   sys_rate = DIV_ROUND(V_OSCK, 100);
-   clk_cycles = DIV_ROUND(OMAP_ABB_CLOCK_CYCLES * 10, sys_rate);
-   sr2_cnt = DIV_ROUND(OMAP_ABB_SETTLING_TIME * 10, clk_cycles);
+   sys_rate = DIV_ROUND_CLOSEST(V_OSCK, 100);
+   clk_cycles = DIV_ROUND_CLOSEST(OMAP_ABB_CLOCK_CYCLES * 10, sys_rate);
+   sr2_cnt = DIV_ROUND_CLOSEST(OMAP_ABB_SETTLING_TIME * 10, clk_cycles);
 
setbits_le32(setup,
 sr2_cnt << (ffs(OMAP_ABB_SETUP_SR2_WTCNT_VALUE_MASK) - 1));
diff --git a/drivers/misc/mxc_ocotp.c b/drivers/misc/mxc_ocotp.c
index 3de1245..89737af 100644
--- a/drivers/misc/mxc_ocotp.c
+++ b/drivers/misc/mxc_ocotp.c
@@ -122,8 +122,8 @@ static void set_timing(struct ocotp_regs *regs)
relax = DIV_ROUND_UP(ipg_clk * BV_TIMING_RELAX_NS, 10) - 1;
strobe_read = DIV_ROUND_UP(ipg_clk * BV_TIMING_STROBE_READ_NS,
10) + 2 * (relax + 1) - 1;
-   strobe_prog = DIV_ROUND(ipg_clk * BV_TIMING_STROBE_PROG_US, 100) +
-   2 * (relax + 1) - 1;
+   strobe_prog = DIV_ROUND_CLOSEST(ipg_clk * BV_TIMING_STROBE_PROG_US,
+   100) + 2 * (relax + 1) - 1;
 
timing = BF(strobe_read, TIMING_STROBE_READ) |
BF(relax, TIMING_RELAX) |
diff --git a/lib/strmhz.c b/lib/strmhz.c
index f9a1772..5c16cc4 100644
--- a/lib/strmhz.c
+++ b/lib/strmhz.c
@@ -11,11 +11,11 @@ char *strmhz (char *buf, unsigned long hz)
long l, n;
long m;
 
-   n = DIV_ROUND(hz, 1000) / 1000L;
+   n = DIV_ROUND_CLOSEST(hz, 1000) / 1000L;
l = sprintf (buf, "%ld", n);
 
hz -= n * 100L;
-   m = DIV_ROUND(hz, 1000L);
+   m = DIV_ROUND_CLOSEST(hz, 1000L);
if (m != 0)
sprintf (buf + l, ".%03ld", m);
return (buf);
-- 
1.9.1

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

Re: [U-Boot] [PATCH 2/4] imx: mx6q/dlarm2: Add support for building plugin image

[Otavio Salvador]

On Tue, Nov 4, 2014 at 6:27 AM, Ye.Li  wrote:
> Update "cfg" script to build for plugin image. This default plugin
> image supports the boot devices as DCD image.
>
> To enable the plugin, must define the CONFIG_USE_PLUGIN in "mx6qarm2.h"
>
> Signed-off-by: Ye.Li 

I'd prefer:

CONFIG_IMX_BOOTROM_PLUGIN

This makes it easier to spot when looking at the config option.

-- 
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 1/3] usb:ehci-mx6 add board_ehci_usb_mode function

[Jeroen Hofstee]

Hello Peng,

On 04-11-14 08:50, Peng Fan wrote:

Include a weak function board_ehci_usb_mode to gives board code
a choice. If the board want the otg port work in host mode but not
device mode, this should be handled.

Signed-off-by: Peng Fan 
Signed-off-by: Ye Li 
---

Changes v2:
  Introduce a new weak function to let board have a choice to decide which mode
  to work at.

  drivers/usb/host/ehci-mx6.c | 7 +++
  1 file changed, 7 insertions(+)

diff --git a/drivers/usb/host/ehci-mx6.c b/drivers/usb/host/ehci-mx6.c
index 9ec5a0a..3662a80 100644
--- a/drivers/usb/host/ehci-mx6.c
+++ b/drivers/usb/host/ehci-mx6.c
@@ -193,6 +193,11 @@ static void usb_oc_config(int index)
__raw_writel(val, ctrl);
  }
  
+int __weak board_ehci_usb_mode(int index, enum usb_init_type *type)

+{
+   return 0;
+}
+
  int __weak board_ehci_hcd_init(int port)
  {
return 0;
@@ -223,6 +228,8 @@ int ehci_hcd_init(int index, enum usb_init_type init,
usb_internal_phy_clock_gate(index, 1);
type = usb_phy_enable(index, ehci) ? USB_INIT_DEVICE : USB_INIT_HOST;
  
+	board_ehci_usb_mode(index, &type);

+
*hccr = (struct ehci_hccr *)((uint32_t)&ehci->caplength);
*hcor = (struct ehci_hcor *)((uint32_t)*hccr +
HC_LENGTH(ehci_readl(&(*hccr)->cr_capbase)));


Can you add a prototype type as well and make sure it is included?

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

Re: [U-Boot] [PATCH v2 0/3] imx:mx6 add usb support

[Peng Fan]

在 11/4/2014 6:31 PM, Marek Vasut 写道:

On Tuesday, November 04, 2014 at 08:49:59 AM, Peng Fan wrote:

So uh, what exactly does this patchset do ? It's not clear at all from the
subject and any description is completely missing.

To my knowledge, i.MX6 already does have USB support in U-Boot, so the subject
is misleading as well.
mx6sxsasbresd board and mx6slevk board does not have board level support 
for usb. This patchset is mainly to add pinmux and implement 
board_ehci_hcd_init and board_echi_power and add USB CONFIG in header 
file to make usb work fine.


I'll send another patch for review, if "usb:ehci-mx6 add 
board_ehci_usb_mode function" is fine.



Changes v2:
  - move pinmux setting into board_init
  - add otg polarity setting in board_ehci_hcd_init
  - Introduce a new weak function to give board a choice to decide the work
mode of the otg port, since a otg port can also work in host mode without
touch ID pin.

Peng Fan (3):
   usb:ehci-mx6 add board_ehci_usb_mode function
   imx:mx6sxsabresd add usb support
   imx:mx6slevk add usb support

  arch/arm/include/asm/arch-mx6/mx6sl_pins.h  |  5 +++
  board/freescale/mx6slevk/mx6slevk.c | 51
+ board/freescale/mx6sxsabresd/mx6sxsabresd.c
| 51 + drivers/usb/host/ehci-mx6.c
 |  7 
  include/configs/mx6slevk.h  | 14 
  include/configs/mx6sxsabresd.h  | 14 
  6 files changed, 142 insertions(+)


Best regards,
Marek Vasut


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

Re: [U-Boot] [PATCH v2 0/3] imx:mx6 add usb support

[Marek Vasut]

On Tuesday, November 04, 2014 at 01:05:44 PM, Peng Fan wrote:
> 在 11/4/2014 6:31 PM, Marek Vasut 写道:
> > On Tuesday, November 04, 2014 at 08:49:59 AM, Peng Fan wrote:
> > 
> > So uh, what exactly does this patchset do ? It's not clear at all from
> > the subject and any description is completely missing.
> > 
> > To my knowledge, i.MX6 already does have USB support in U-Boot, so the
> > subject is misleading as well.
> 
> mx6sxsasbresd board and mx6slevk board does not have board level support
> for usb. This patchset is mainly to add pinmux and implement
> board_ehci_hcd_init and board_echi_power and add USB CONFIG in header
> file to make usb work fine.
> 
> I'll send another patch for review, if "usb:ehci-mx6 add
> board_ehci_usb_mode function" is fine.

Please see my comment to that patch before you re-submit.

Thanks!

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

[U-Boot] [PATCH] powerpc/P5040DS: enable SATA support

[shh.xie]

From: Shaohui Xie 

The define CONFIG_FSL_SATA_V2 is missing, so SATA is not available
in U-boot.

Signed-off-by: Shaohui Xie 
---
 include/configs/P5040DS.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/configs/P5040DS.h b/include/configs/P5040DS.h
index 371485f..e4a031a 100644
--- a/include/configs/P5040DS.h
+++ b/include/configs/P5040DS.h
@@ -17,6 +17,7 @@
 #define CONFIG_MMC
 #define CONFIG_NAND_FSL_ELBC
 #define CONFIG_PCIE3
+#define CONFIG_FSL_SATA_V2
 #define CONFIG_SYS_FSL_RAID_ENGINE
 
 #define CONFIG_ICS307_REFCLK_HZ2500  /* ICS307 ref clk 
freq */
-- 
2.1.0.27.g96db324

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

Re: [U-Boot] [RFC PATCH v1 1/2] kgdb: add breakpoint support

[Peng Fan]

Hi Simon,

在 11/4/2014 2:46 PM, Simon Glass 写道:

Hi Peng,

On 31 October 2014 23:12, Peng Fan  wrote:

Add Z/z protocal support for breakpoint set/remove.

Signed-off-by: Peng Fan 


This looks good to me - I just have a few bits below.


---
  common/kgdb.c  | 273 +
  include/kgdb.h |  35 
  2 files changed, 308 insertions(+)

diff --git a/common/kgdb.c b/common/kgdb.c
index d357463..fd83ccd 100644
--- a/common/kgdb.c
+++ b/common/kgdb.c
@@ -92,6 +92,8 @@
  #include 
  #include 

+#include 


#include  would do

Ok.



+
  #undef KGDB_DEBUG


Where is this used?


You mean KGDB_DEBUG?


  /*
@@ -111,6 +113,17 @@ static int longjmp_on_fault = 0;
  static int kdebug = 1;
  #endif

+struct kgdb_bkpt kgdb_break[KGDB_MAX_BREAKPOINTS] = {
+   [0 ... KGDB_MAX_BREAKPOINTS-1] = { .state = BP_UNDEFINED }
+};
+
+#ifdef CONFIG_ARM
+unsigned char gdb_bpt_instr[4] = {0xfe, 0xde, 0xff, 0xe7};
+#else
+#error "Please implement gdb_bpt_instr!"
+#endif
+
+
  static const char hexchars[]="0123456789abcdef";

  /* Convert ch from a hex digit to an int */
@@ -309,6 +322,200 @@ putpacket(unsigned char *buffer)
 } while ((recv & 0x7f) != '+');
  }

+int kgdb_validate_break_address(unsigned addr)
+{
+   /* Need More */


?
I'll remove the comment. Actually i just want to validate whether the 
add parameter is fine or not using this function.



+   return 0;
+}
+
+static int probe_kernel_read(unsigned char *dst, void *src, size_t size)
+{
+   int i;
+   unsigned char *dst_ptr = dst;
+   unsigned char *src_ptr = src;
+
+   for (i = 0; i < size; i++)
+   *dst_ptr++ = *src_ptr++;
+
+   return 0;
+}
+
+static int probe_kernel_write(char *dst, void *src, size_t size)


These two above are strange function names - why 'kernel' - what does
it mean in this context? Also could you must use memcpy(), either in
the functions or instead of them?
Ok. memcpy is better. I just use the function name in linux kernel, 
maybe misleading here. how about probe_mem_read?



+{
+   int i;
+   char *dst_ptr = dst;
+   char *src_ptr = src;
+
+   for (i = 0; i < size; i++)
+   *dst_ptr++ = *src_ptr++;
+
+   return 0;
+}
+
+__weak int kgdb_arch_set_breakpoint(struct kgdb_bkpt *bpt)
+{
+   int err;
+
+   err = probe_kernel_read(bpt->saved_instr, (char *)bpt->bpt_addr,
+   BREAK_INSTR_SIZE);
+   if (err)
+   return err;
+
+   err = probe_kernel_write((char *)bpt->bpt_addr, gdb_bpt_instr,
+BREAK_INSTR_SIZE);
+
+   return err;
+}
+
+/*
+ * Set the breakpoints whose state is BP_SET to BP_ACTIVE
+ */
+int kgdb_active_sw_breakpoints(void)
+{
+   int err;
+   int ret = 0;
+   int i;
+
+   for (i = 0; i < KGDB_MAX_BREAKPOINTS; i++) {
+   if (kgdb_break[i].state != BP_SET)
+   continue;
+
+   err = kgdb_arch_set_breakpoint(&kgdb_break[i]);
+   if (err) {
+   ret = err;
+   printf("KGDB: BP install failed: %lx\n",
+  kgdb_break[i].bpt_addr);
+   continue;
+   }
+
+   kgdb_break[i].state = BP_ACTIVE;
+
+   /*
+* kgdb_arch_set_breakpoint touched dcache and memory.
+* cache should be flushed to let icache can see the updated
+* inst.


instruction


+*/
+   /* flush work is done in do_exit */
+   kgdb_flush_cache_all();
+   }
+
+   return ret;
+}
+
+/*
+ * Set state from BP_SET to BP_REMOVED
+ */
+int kgdb_remove_sw_breakpoint(unsigned int addr)
+{
+   int i;
+
+   for (i = 0; i < KGDB_MAX_BREAKPOINTS; i++) {
+   if ((kgdb_break[i].state == BP_SET) &&
+   (kgdb_break[i].bpt_addr == addr)) {
+   kgdb_break[i].state = BP_REMOVED;
+   return 0;
+   }
+   }
+
+   return -ENOENT;
+}
+
+int kgdb_set_sw_breakpoint(unsigned int addr)
+{
+   int err = kgdb_validate_break_address(addr);
+   int breakno = -1;
+   int i;
+
+   if (err)
+   return err;
+
+   for (i = 0; i < KGDB_MAX_BREAKPOINTS; i++) {
+   if ((kgdb_break[i].state == BP_SET) &&
+   (kgdb_break[i].bpt_addr == addr))
+   return -EEXIST;
+   }
+
+   for (i = 0; i < KGDB_MAX_BREAKPOINTS; i++) {
+   /* removed or unused, use it */
+   if ((kgdb_break[i].state == BP_REMOVED) ||
+   (kgdb_break[i].state == BP_UNDEFINED)) {
+   breakno = i;
+   break;
+   }
+   }
+
+   if (breakno == -1)
+   return -E2BIG;
+
+   kgdb_break[breakno].state = BP_SET;
+   kgdb_break[breakno].type = BP_BREAKPOINT;
+   kg

Re: [U-Boot] [RFC PATCH v1 2/2] arm:kgdb add KGDB support for arm platform

[Peng Fan]

Hi Simon,

在 11/4/2014 2:58 PM, Simon Glass 写道:

HI Peng,

On 31 October 2014 23:12, Peng Fan  wrote:

The register save/restore:
Use get_bad_stack and bad_save_user_regs to save regs.
Introduce und_restore_regs to restore the previous regs before
trigger a breakpoint.

Signed-off-by: Peng Fan 


Looks good so far as I understand it. A few nits below and maybe you
can integrate better with the ptrace register numbering.


---
  arch/arm/include/asm/proc-armv/ptrace.h |   2 +-
  arch/arm/include/asm/signal.h   |   1 +
  arch/arm/lib/Makefile   |   3 +
  arch/arm/lib/crt0.S |   4 +
  arch/arm/lib/interrupts.c   |  24 
  arch/arm/lib/kgdb/kgdb.c| 231 
  arch/arm/lib/kgdb/setjmp.S  |  20 +++
  arch/arm/lib/vectors.S  |  28 
  8 files changed, 312 insertions(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/proc-armv/ptrace.h 
b/arch/arm/include/asm/proc-armv/ptrace.h
index 71df5a9..33fe587 100644
--- a/arch/arm/include/asm/proc-armv/ptrace.h
+++ b/arch/arm/include/asm/proc-armv/ptrace.h
@@ -58,7 +58,7 @@ struct pt_regs {
 stack during a system call. */

  struct pt_regs {
-   long uregs[18];
+   unsigned long uregs[18];
  };

  #define ARM_cpsr   uregs[16]
diff --git a/arch/arm/include/asm/signal.h b/arch/arm/include/asm/signal.h
new file mode 100644
index 000..7b1573c
--- /dev/null
+++ b/arch/arm/include/asm/signal.h
@@ -0,0 +1 @@
+#include 
diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile
index 1ef2400..c543563 100644
--- a/arch/arm/lib/Makefile
+++ b/arch/arm/lib/Makefile
@@ -52,3 +52,6 @@ endif
  ifneq (,$(findstring -mabi=aapcs-linux,$(PLATFORM_CPPFLAGS)))
  extra-y+= eabi_compat.o
  endif
+
+obj-$(CONFIG_CMD_KGDB) += kgdb/setjmp.o
+obj-$(CONFIG_CMD_KGDB) += kgdb/kgdb.o
diff --git a/arch/arm/lib/crt0.S b/arch/arm/lib/crt0.S
index 29cdad0..d96e70b 100644
--- a/arch/arm/lib/crt0.S
+++ b/arch/arm/lib/crt0.S
@@ -99,9 +99,13 @@ clr_gd:
 sub r9, r9, #GD_SIZE/* new GD is below bd */

 adr lr, here
+#ifndef CONFIG_CMD_KGDB
 ldr r0, [r9, #GD_RELOC_OFF] /* r0 = gd->reloc_off */
 add lr, lr, r0
 ldr r0, [r9, #GD_RELOCADDR] /* r0 = gd->relocaddr */
+#else
+  ldr r0, =__image_copy_start
+#endif
 b   relocate_code
  here:

diff --git a/arch/arm/lib/interrupts.c b/arch/arm/lib/interrupts.c
index 4dacfd9..d16bd58 100644
--- a/arch/arm/lib/interrupts.c
+++ b/arch/arm/lib/interrupts.c
@@ -22,6 +22,7 @@
  #include 
  #include 
  #include 
+#include 

  DECLARE_GLOBAL_DATA_PTR;

@@ -160,9 +161,32 @@ void show_regs (struct pt_regs *regs)

  void do_undefined_instruction (struct pt_regs *pt_regs)
  {
+#if defined(CONFIG_CMD_KGDB)
+   unsigned long *tmp_pc = NULL;
+
+   pt_regs->ARM_pc -= 4;
+   tmp_pc = (unsigned long *)pt_regs->ARM_pc;
+
+   if (*tmp_pc == 0xe7ffdeff) {
+   pt_regs->ARM_pc += 4;
+   if (debugger_exception_handler &&
+   debugger_exception_handler(pt_regs)) {
+   return;
+   }
+   } else if (*tmp_pc == 0xe7ffdefe) {
+   if (debugger_exception_handler &&
+   debugger_exception_handler(pt_regs)) {
+   return;
+   }
+   } else {
+   printf("DCache/ICACHE May need flush\n");
+   return;
+   }
+#else
 printf ("undefined instruction\n");
 show_regs (pt_regs);
 bad_mode ();
+#endif
  }

  void do_software_interrupt (struct pt_regs *pt_regs)
diff --git a/arch/arm/lib/kgdb/kgdb.c b/arch/arm/lib/kgdb/kgdb.c
new file mode 100644
index 000..6b2e542
--- /dev/null
+++ b/arch/arm/lib/kgdb/kgdb.c
@@ -0,0 +1,231 @@
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define KGDB_ARM_GP_REGS   16
+#define KGDB_ARM_FP_REGS   8
+#define KGDB_ARM_EXTRA_REGS2
+#define KGDB_ARM_MAX_REGS  (KGDB_ARM_GP_REGS +\
+(KGDB_ARM_FP_REGS * 3) +\
+ KGDB_ARM_EXTRA_REGS)
+#define KGDB_NUMREGBYTES   (KGDB_ARM_MAX_REGS << 2)
+
+enum arm_regs {
+   KGDB_ARM_R0,
+   KGDB_ARM_R1,
+   KGDB_ARM_R2,
+   KGDB_ARM_R3,
+   KGDB_ARM_R4,
+   KGDB_ARM_R5,
+   KGDB_ARM_R6,
+   KGDB_ARM_R7,
+   KGDB_ARM_R8,
+   KGDB_ARM_R9,
+   KGDB_ARM_R10,
+   KGDB_ARM_FP,
+   KGDB_ARM_IP,
+   KGDB_ARM_SP,
+   KGDB_ARM_LR,
+   KGDB_ARM_PC,


So in here there are the FP and EXTRA regs? If you added them to this
enum it would be clearer.
I did not test FP and other extra regs. Actually in uboot, the FP and 
extra regs are used? I am not sure.


Also these mirror the numbers in ptrace.h so I wonder if somehow they
could be linked?

hmm, I'll try this.



+   KGDB_ARM_CPSR = KGDB_ARM_MAX_REGS - 1
+};
+
+void kgdb_enter(struct pt_regs *re

Re: [U-Boot] [PATCH v2 1/3] usb:ehci-mx6 add board_ehci_usb_mode function

[Peng Fan]

Hi Marek,

在 11/4/2014 7:01 PM, Marek Vasut 写道:

On Tuesday, November 04, 2014 at 11:50:29 AM, Peng Fan wrote:

在 11/4/2014 6:33 PM, Marek Vasut 写道:

On Tuesday, November 04, 2014 at 08:50:00 AM, Peng Fan wrote:

Include a weak function board_ehci_usb_mode to gives board code
a choice.


What choice?


If the board want the otg port work in host mode but not
device mode, this should be handled.


How?

Also, isn't usb_phy_enable() supposed to do exactly this kind of
selection between device and host mode ?


In mx6sxsabresd board, there are two usb port, one used for otg, the
other used for host. However they are connected to SOC USB controller
otg1 core and otg2 core respectively. Like following:

OTG1 CORE <> board otg port
OTG2 CORE <> board host port

However the board do not have ID pin set for board host port. If just
use usb_phy_enable, the board host port will not work, because
"type = usb_phy_enable(index, ehci) ? USB_INIT_DEVICE : USB_INIT_HOST;"
will always set type with USB_INIT_DEVICE.

Because i did not find way to handle this situation in
board/freescale/mx6sxsabresd/mx6sxsabresd.c, add this function to let
board level code handle handle 'type', if board level code want to set
it's own 'type'.


This part in usb_phy_enable()

163 return val & USBPHY_CTRL_OTG_ID;

should be replaced by some kind of a board-specific callback then, with
default implmentation being the above (reading the phy ctrl register).



How about using the following piece of code?
in ehci-mx6.c

unsigned int __weak board_usb_phy_mode(int index, unsigned int val)
{
return val & USBPHY_CTRL_OTG_ID;
}

replace "return val & USBPHY_CTRL_OTG_ID;" using "
return board_usb_phy_mode(index, val);"

In board file,
unsigned int board_usb_phy_mode(int index, unsigned int val)
{
if (index == 1)
return 0; /* HOST */
else
return 1; /* DEVICE */
}


Best regards,
Marek Vasut


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

Re: [U-Boot] [PATCH v2 1/3] usb:ehci-mx6 add board_ehci_usb_mode function

[Peng Fan]

Hi Jeroen,

在 11/4/2014 7:40 PM, Jeroen Hofstee 写道:

Hello Peng,

On 04-11-14 08:50, Peng Fan wrote:

Include a weak function board_ehci_usb_mode to gives board code
a choice. If the board want the otg port work in host mode but not
device mode, this should be handled.

Signed-off-by: Peng Fan 
Signed-off-by: Ye Li 
---

Changes v2:
   Introduce a new weak function to let board have a choice to decide which mode
   to work at.

   drivers/usb/host/ehci-mx6.c | 7 +++
   1 file changed, 7 insertions(+)

diff --git a/drivers/usb/host/ehci-mx6.c b/drivers/usb/host/ehci-mx6.c
index 9ec5a0a..3662a80 100644
--- a/drivers/usb/host/ehci-mx6.c
+++ b/drivers/usb/host/ehci-mx6.c
@@ -193,6 +193,11 @@ static void usb_oc_config(int index)
__raw_writel(val, ctrl);
   }

+int __weak board_ehci_usb_mode(int index, enum usb_init_type *type)
+{
+   return 0;
+}
+
   int __weak board_ehci_hcd_init(int port)
   {
return 0;
@@ -223,6 +228,8 @@ int ehci_hcd_init(int index, enum usb_init_type init,
usb_internal_phy_clock_gate(index, 1);
type = usb_phy_enable(index, ehci) ? USB_INIT_DEVICE : USB_INIT_HOST;

+   board_ehci_usb_mode(index, &type);
+
*hccr = (struct ehci_hccr *)((uint32_t)&ehci->caplength);
*hcor = (struct ehci_hcor *)((uint32_t)*hccr +
HC_LENGTH(ehci_readl(&(*hccr)->cr_capbase)));


Can you add a prototype type as well and make sure it is included?
I did not find a good place for the prototype type. I think ehci.h is 
not fine to include this prototype. Any suggestions?


Thanks,
Jeroen


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

Re: [U-Boot] [PATCH 2/4] imx: mx6slevk: Add PMIC Pfuze support

[Przemyslaw Marczak]

Hello Ye Li,

On 11/04/2014 10:37 AM, Li Ye-B37916 wrote:


Hi Przemyslaw,

On 11/4/2014 5:24 PM, Li Ye-B37916 wrote:

Hi Przemyslaw,


On 10/30/2014 6:36 PM, Stefano Babic wrote:

Hi Ye,

On 10/09/2014 11:08, Ye.Li wrote:

Initialize the Pfuze on I2C1 at board late init. The mx6slevk board
has Pfuze100 or Pfuze200, print the chip type by parsing the ID.

Signed-off-by: Ye.Li 
---

Slowly (sorry for that..) I am checking again all PMIC related patches
you sent last month. However, these patches do not fit very well in the
current development.

In the last U-Boot mini summit we get the decision to post new PMIC
drivers according to the Device Model rules. Przemyslaw is the new
custodian for PMICs, and he will take care of all related issues
regarding power management.

Can you share me more information about the new PMIC drivers development that 
Stefano mentioned above.
1. Have you completed the APIs define for new PMIC drivers?  If yes, where I 
can get them.
2. When will the new PMIC drivers deliver?
3. Will the PMIC devices already supported in current release stay supported by 
new PMIC drivers?



The work on new PMIC framework was temporary on hold.
Now I'm working on it, but the basic functionality is actually done.
The first version you can check here:
https://github.com/bobenstein/u-boot.git
I need to make some rework, since the i2c is going to support the driver 
model.


I can now focus on this work. And this will be merged through u-boot-dm 
- since i2c support is added.


The plan is simple:
1) Add new drivers to the present PMIC framework - before merge the new one.
2) Add new PMIC framework as a separated piece of code.
3) Migrate old drivers and boards to the new framework.
4) Remove the old framework without any conflicts.

So it's not a problem if you want add this driver, we add this to the 
current framework - the migration should be simple and will not cause 
conflicts.


If you are interested in the new PMIC framework design, please read the 
doc file added by the patches from the link above.


You can implement just one class(UCLASS_PMIC), and if you need user 
friendly interface it is welcome to implement also UCLASS_PMIC_REGULATOR.


Please follow the list, maybe I will send the patches at the end of this 
week.


... [ snip ] ...


Best regards,
--
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

[U-Boot] [U-boot] [Patch 0/2] keystone2: config: customize uboot environment

[Ivan Khoronzhuk]

Customize default uboot environment in order to simplify it's support
and to align with current MCSDK.

Based on "[U-boot] [Patch 0/2] keystone2: change default boot mode to ubi"
https://www.mail-archive.com/u-boot@lists.denx.de/msg152442.html

Ivan Khoronzhuk (1):
  keystone2: config: align names of images with MCSDK

Murali Karicheri (1):
  keystone2: config: restructure handling of default env settings

 include/configs/k2e_evm.h  | 17 +
 include/configs/k2hk_evm.h | 17 +
 include/configs/k2l_evm.h  | 17 +
 include/configs/ks2_evm.h  | 10 ++
 4 files changed, 29 insertions(+), 32 deletions(-)

-- 
1.9.1

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

[U-Boot] [U-boot] [Patch 2/2] keystone2: config: align names of images with MCSDK

[Ivan Khoronzhuk]

The Multicore Software Development Kit (MCSDK) provides foundational
software for TI KeyStone II device platforms. It's supposed to be used
with uboot, and it's convenient to have the same names for images, so
correct environment image names according to the last MCSDK3.

Signed-off-by: Ivan Khoronzhuk 
---
 include/configs/k2e_evm.h  | 5 +++--
 include/configs/k2hk_evm.h | 5 +++--
 include/configs/k2l_evm.h  | 5 +++--
 include/configs/ks2_evm.h  | 3 +--
 4 files changed, 10 insertions(+), 8 deletions(-)

diff --git a/include/configs/k2e_evm.h b/include/configs/k2e_evm.h
index 6b87f6c..d83e07e 100644
--- a/include/configs/k2e_evm.h
+++ b/include/configs/k2e_evm.h
@@ -21,10 +21,11 @@
"addr_mon=0x0c14\0" \
"args_ubi=setenv bootargs ${bootargs} rootfstype=ubifs "\
"root=ubi0:rootfs rootflags=sync rw ubi.mtd=2,2048\0"   \
-   "name_fdt=k2e-evm.dtb\0"\
+   "name_fdt=uImage-k2e-evm.dtb\0" \
"name_mon=skern-k2e-evm.bin\0"  \
"name_ubi=k2e-evm-ubifs.ubi\0"  \
-   "name_uboot=u-boot-spi-k2e-evm.gph\0"
+   "name_uboot=u-boot-spi-k2e-evm.gph\0"   \
+   "name_fs=arago-console-image-k2e-evm.cpio.gz\0"
 
 #include 
 
diff --git a/include/configs/k2hk_evm.h b/include/configs/k2hk_evm.h
index 33e43eb..ffddf13 100644
--- a/include/configs/k2hk_evm.h
+++ b/include/configs/k2hk_evm.h
@@ -21,10 +21,11 @@
"addr_mon=0x0c5f\0" \
"args_ubi=setenv bootargs ${bootargs} rootfstype=ubifs "\
"root=ubi0:rootfs rootflags=sync rw ubi.mtd=2,2048\0"   \
-   "name_fdt=k2hk-evm.dtb\0"   \
+   "name_fdt=uImage-k2hk-evm.dtb\0"\
"name_mon=skern-k2hk-evm.bin\0" \
"name_ubi=k2hk-evm-ubifs.ubi\0" \
-   "name_uboot=u-boot-spi-k2hk-evm.gph\0"
+   "name_uboot=u-boot-spi-k2hk-evm.gph\0"  \
+   "name_fs=arago-console-image-k2hk-evm.cpio.gz\0"
 
 #include 
 
diff --git a/include/configs/k2l_evm.h b/include/configs/k2l_evm.h
index 07326fc..805164a 100644
--- a/include/configs/k2l_evm.h
+++ b/include/configs/k2l_evm.h
@@ -21,10 +21,11 @@
"addr_mon=0x0c14\0" \
"args_ubi=setenv bootargs ${bootargs} rootfstype=ubifs "\
"root=ubi0:rootfs rootflags=sync rw ubi.mtd=2,4096\0"   \
-   "name_fdt=k2l-evm.dtb\0"\
+   "name_fdt=uImage-k2l-evm.dtb\0" \
"name_mon=skern-k2l-evm.bin\0"  \
"name_ubi=k2l-evm-ubifs.ubi\0"  \
-   "name_uboot=u-boot-spi-k2l-evm.gph\0"
+   "name_uboot=u-boot-spi-k2l-evm.gph\0"   \
+   "name_fs=arago-console-image-k2l-evm.cpio.gz\0"
 
 #include 
 
diff --git a/include/configs/ks2_evm.h b/include/configs/ks2_evm.h
index 19273d9..e4890ba 100644
--- a/include/configs/ks2_evm.h
+++ b/include/configs/ks2_evm.h
@@ -260,8 +260,7 @@
"addr_ubi=0x8200\0" \
"addr_secdb_key=0xc00\0"\
"fdt_high=0x\0" \
-   "name_fs=arago-console-image.cpio.gz\0" \
-   "name_kern=uImage\0"\
+   "name_kern=uImage-keystone-evm.bin\0"   \
"run_mon=mon_install ${addr_mon}\0" \
"run_kern=bootm ${addr_kern} - ${addr_fdt}\0"   \
"init_net=run args_all args_net\0"  \
-- 
1.9.1

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

Re: [U-Boot] [U-boot] [Patch] ks2_evm: config: enable fatload command

[Tom Rini]

On Wed, Oct 29, 2014 at 04:28:56PM +0200, Ivan Khoronzhuk wrote:

> The keystone2 evm can boot from USB partition with FAT32 FS, so
> enable fatload command usage.
> 
> Acked-by: Murali Karicheri 
> Signed-off-by: Ivan Khoronzhuk 
> ---
>  include/configs/ks2_evm.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/include/configs/ks2_evm.h b/include/configs/ks2_evm.h
> index b30e72f..e5e628f 100644
> --- a/include/configs/ks2_evm.h
> +++ b/include/configs/ks2_evm.h
> @@ -225,6 +225,7 @@
>  #define CONFIG_CMD_SF
>  #define CONFIG_CMD_EEPROM
>  #define CONFIG_CMD_USB
> +#define CONFIG_CMD_FAT

Please also add CONFIG_CMD_FS_GENERIC so that you can just use 'load',
etc and it just works with various fs types.

-- 
Tom


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

Re: [U-Boot] [U-boot] [Patch] ks2_evm: config: enable fatload command

[Ivan Khoronzhuk]

On 11/04/2014 04:54 PM, Tom Rini wrote:

On Wed, Oct 29, 2014 at 04:28:56PM +0200, Ivan Khoronzhuk wrote:


The keystone2 evm can boot from USB partition with FAT32 FS, so
enable fatload command usage.

Acked-by: Murali Karicheri 
Signed-off-by: Ivan Khoronzhuk 
---
  include/configs/ks2_evm.h | 1 +
  1 file changed, 1 insertion(+)

diff --git a/include/configs/ks2_evm.h b/include/configs/ks2_evm.h
index b30e72f..e5e628f 100644
--- a/include/configs/ks2_evm.h
+++ b/include/configs/ks2_evm.h
@@ -225,6 +225,7 @@
  #define CONFIG_CMD_SF
  #define CONFIG_CMD_EEPROM
  #define CONFIG_CMD_USB
+#define CONFIG_CMD_FAT

Please also add CONFIG_CMD_FS_GENERIC so that you can just use 'load',
etc and it just works with various fs types.


Ok
Thanks.

--
Regards,
Ivan Khoronzhuk

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

[U-Boot] [PATCH 2/4] x86: Do TSC MSR calibration only for known/supported CPUs

[Bin Meng]

Using MSR_PLATFORM_INFO (0xCE) to calibrate TSR will cause #GP on
processors which do not have this MSR. Instead only doing the MSR
calibration for known/supported CPUs.

Signed-off-by: Bin Meng 
---
 arch/x86/lib/tsc_timer.c | 116 ---
 1 file changed, 109 insertions(+), 7 deletions(-)

diff --git a/arch/x86/lib/tsc_timer.c b/arch/x86/lib/tsc_timer.c
index 8b38702..fafbbfc 100644
--- a/arch/x86/lib/tsc_timer.c
+++ b/arch/x86/lib/tsc_timer.c
@@ -1,6 +1,9 @@
 /*
  * Copyright (c) 2012 The Chromium OS Authors.
  *
+ * TSC calibration codes are adapted from Linux kernel
+ * arch/x86/kernel/tsc_msr.c and arch/x86/kernel/tsc.c
+ *
  * SPDX-License-Identifier:GPL-2.0+
  */
 
@@ -12,8 +15,108 @@
 #include 
 #include 
 
+/* CPU reference clock frequency: in KHz */
+#define FREQ_8383200
+#define FREQ_100   99840
+#define FREQ_133   133200
+#define FREQ_166   166400
+
+#define MAX_NUM_FREQS  8
+
 DECLARE_GLOBAL_DATA_PTR;
 
+/*
+ * According to Intel 64 and IA-32 System Programming Guide,
+ * if MSR_PERF_STAT[31] is set, the maximum resolved bus ratio can be
+ * read in MSR_PLATFORM_ID[12:8], otherwise in MSR_PERF_STAT[44:40].
+ * Unfortunately some Intel Atom SoCs aren't quite compliant to this,
+ * so we need manually differentiate SoC families. This is what the
+ * field msr_plat does.
+ */
+struct freq_desc {
+   u8 x86_family;  /* CPU family */
+   u8 x86_model;   /* model */
+   u8 msr_plat;/* 1: use MSR_PLATFORM_INFO, 0: MSR_IA32_PERF_STATUS */
+   u32 freqs[MAX_NUM_FREQS];
+};
+
+static struct freq_desc freq_desc_tables[] = {
+   /* PNW */
+   { 6, 0x27, 0, { 0, 0, 0, 0, 0, FREQ_100, 0, FREQ_83 } },
+   /* CLV+ */
+   { 6, 0x35, 0, { 0, FREQ_133, 0, 0, 0, FREQ_100, 0, FREQ_83 } },
+   /* TNG */
+   { 6, 0x4a, 1, { 0, FREQ_100, FREQ_133, 0, 0, 0, 0, 0 } },
+   /* VLV2 */
+   { 6, 0x37, 1, { FREQ_83, FREQ_100, FREQ_133, FREQ_166, 0, 0, 0, 0 } },
+   /* ANN */
+   { 6, 0x5a, 1, { FREQ_83, FREQ_100, FREQ_133, FREQ_100, 0, 0, 0, 0 } },
+};
+
+static int match_cpu(u8 family, u8 model)
+{
+   int i;
+
+   for (i = 0; i < ARRAY_SIZE(freq_desc_tables); i++) {
+   if ((family == freq_desc_tables[i].x86_family) &&
+   (model == freq_desc_tables[i].x86_model))
+   return i;
+   }
+
+   return -1;
+}
+
+/* Map CPU reference clock freq ID(0-7) to CPU reference clock freq(KHz) */
+#define id_to_freq(cpu_index, freq_id) \
+   (freq_desc_tables[cpu_index].freqs[freq_id])
+
+/*
+ * Do MSR calibration only for known/supported CPUs.
+ *
+ * Returns the calibration value or 0 if MSR calibration failed.
+ */
+static unsigned long try_msr_calibrate_tsc(void)
+{
+   u32 lo, hi, ratio, freq_id, freq;
+   unsigned long res;
+   int cpu_index;
+
+   cpu_index = match_cpu(gd->arch.x86, gd->arch.x86_model);
+   if (cpu_index < 0)
+   return 0;
+
+   if (freq_desc_tables[cpu_index].msr_plat) {
+   rdmsr(MSR_PLATFORM_INFO, lo, hi);
+   ratio = (lo >> 8) & 0x1f;
+   } else {
+   rdmsr(MSR_IA32_PERF_STATUS, lo, hi);
+   ratio = (hi >> 8) & 0x1f;
+   }
+   debug("Maximum core-clock to bus-clock ratio: 0x%x\n", ratio);
+
+   if (!ratio)
+   goto fail;
+
+   /* Get FSB FREQ ID */
+   rdmsr(MSR_FSB_FREQ, lo, hi);
+   freq_id = lo & 0x7;
+   freq = id_to_freq(cpu_index, freq_id);
+   debug("Resolved frequency ID: %u, frequency: %u KHz\n",
+   freq_id, freq);
+   if (!freq)
+   goto fail;
+
+   /* TSC frequency = maximum resolved freq * maximum resolved bus ratio */
+   res = freq * ratio / 1000;
+   debug("TSC runs at %lu MHz\n", res);
+
+   return res;
+
+fail:
+   debug("Fast TSC calibration using MSR failed\n");
+   return 0;
+}
+
 void timer_set_base(u64 base)
 {
gd->arch.tsc_base = base;
@@ -34,17 +137,16 @@ u64 __attribute__((no_instrument_function)) get_ticks(void)
return now_tick - gd->arch.tsc_base;
 }
 
-#define PLATFORM_INFO_MSR 0xce
-
 /* Get the speed of the TSC timer in MHz */
 unsigned __attribute__((no_instrument_function)) long get_tbclk_mhz(void)
 {
-   u32 ratio;
-   u64 platform_info = native_read_msr(PLATFORM_INFO_MSR);
+   unsigned long fast_calibrate;
+
+   fast_calibrate = try_msr_calibrate_tsc();
+   if (!fast_calibrate)
+   panic("TSC frequency is ZERO");
 
-   /* 100MHz times Max Non Turbo ratio */
-   ratio = (platform_info >> 8) & 0xff;
-   return 100 * ratio;
+   return fast_calibrate;
 }
 
 unsigned long get_tbclk(void)
-- 
1.8.2.1

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

[U-Boot] [PATCH 1/4] x86: Display more detailed CPU information on boot

[Bin Meng]

Currently only basic CPU information (x86 or x86_64) is displayed
on boot. This commit adds more detailed information output including
CPU vendor name, device id, family, model and stepping as well as
the CPU brand string, all of which are extracted from CPUID result.

The CPU identification happens in x86_cpu_init_f() and corresponding
fields are saved in the global data. Later print_cpuinfo() just uses
these fields to display CPU information without the need to probe
again in real time.

Signed-off-by: Bin Meng 
---
 arch/x86/cpu/cpu.c | 282 +++--
 arch/x86/include/asm/cpu.h | 142 +++
 arch/x86/include/asm/global_data.h |   5 +
 3 files changed, 385 insertions(+), 44 deletions(-)

diff --git a/arch/x86/cpu/cpu.c b/arch/x86/cpu/cpu.c
index 2e25253..e9058f7 100644
--- a/arch/x86/cpu/cpu.c
+++ b/arch/x86/cpu/cpu.c
@@ -13,6 +13,9 @@
  * Sysgo Real-Time Solutions, GmbH 
  * Alex Zuepke 
  *
+ * Part of this file is adapted from coreboot
+ * src/arch/x86/lib/cpu.c
+ *
  * SPDX-License-Identifier:GPL-2.0+
  */
 
@@ -27,6 +30,8 @@
 #include 
 #include 
 
+DECLARE_GLOBAL_DATA_PTR;
+
 /*
  * Constructor for a conventional segment GDT (or LDT) entry
  * This is a macro so it can be used in initialisers
@@ -43,6 +48,51 @@ struct gdt_ptr {
u32 ptr;
 } __packed;
 
+struct cpu_device_id {
+   unsigned vendor;
+   unsigned device;
+};
+
+struct cpuinfo_x86 {
+uint8_tx86;/* CPU family */
+uint8_tx86_vendor; /* CPU vendor */
+uint8_tx86_model;
+uint8_tx86_mask;
+};
+
+/* List of cpu vendor strings along with their normalized
+ * id values.
+ */
+static struct {
+   int vendor;
+   const char *name;
+} x86_vendors[] = {
+   { X86_VENDOR_INTEL, "GenuineIntel", },
+   { X86_VENDOR_CYRIX, "CyrixInstead", },
+   { X86_VENDOR_AMD,   "AuthenticAMD", },
+   { X86_VENDOR_UMC,   "UMC UMC UMC ", },
+   { X86_VENDOR_NEXGEN,"NexGenDriven", },
+   { X86_VENDOR_CENTAUR,   "CentaurHauls", },
+   { X86_VENDOR_RISE,  "RiseRiseRise", },
+   { X86_VENDOR_TRANSMETA, "GenuineTMx86", },
+   { X86_VENDOR_TRANSMETA, "TransmetaCPU", },
+   { X86_VENDOR_NSC,   "Geode by NSC", },
+   { X86_VENDOR_SIS,   "SiS SiS SiS ", },
+};
+
+static const char *x86_vendor_name[] = {
+   [X86_VENDOR_INTEL] = "Intel",
+   [X86_VENDOR_CYRIX] = "Cyrix",
+   [X86_VENDOR_AMD]   = "AMD",
+   [X86_VENDOR_UMC]   = "UMC",
+   [X86_VENDOR_NEXGEN]= "NexGen",
+   [X86_VENDOR_CENTAUR]   = "Centaur",
+   [X86_VENDOR_RISE]  = "Rise",
+   [X86_VENDOR_TRANSMETA] = "Transmeta",
+   [X86_VENDOR_NSC]   = "NSC",
+   [X86_VENDOR_SIS]   = "SiS",
+};
+
 static void load_ds(u32 segment)
 {
asm volatile("movl %0, %%ds" : : "r" (segment * X86_GDT_ENTRY_SIZE));
@@ -115,6 +165,131 @@ int __weak x86_cleanup_before_linux(void)
return 0;
 }
 
+/*
+ * Cyrix CPUs without cpuid or with cpuid not yet enabled can be detected
+ * by the fact that they preserve the flags across the division of 5/2.
+ * PII and PPro exhibit this behavior too, but they have cpuid available.
+ */
+
+/*
+ * Perform the Cyrix 5/2 test. A Cyrix won't change
+ * the flags, while other 486 chips will.
+ */
+static inline int test_cyrix_52div(void)
+{
+   unsigned int test;
+
+   __asm__ __volatile__(
+"sahf\n\t" /* clear flags (%eax = 0x0005) */
+"div %b2\n\t"  /* divide 5 by 2 */
+"lahf" /* store flags into %ah */
+: "=a" (test)
+: "0" (5), "q" (2)
+: "cc");
+
+   /* AH is 0x02 on Cyrix after the divide.. */
+   return (unsigned char) (test >> 8) == 0x02;
+}
+
+/*
+ * Detect a NexGen CPU running without BIOS hypercode new enough
+ * to have CPUID. (Thanks to Herbert Oppmann)
+ */
+
+static int deep_magic_nexgen_probe(void)
+{
+   int ret;
+
+   __asm__ __volatile__ (
+   "   movw$0x, %%ax\n"
+   "   xorw%%dx,%%dx\n"
+   "   movw$2, %%cx\n"
+   "   divw%%cx\n"
+   "   movl$0, %%eax\n"
+   "   jnz 1f\n"
+   "   movl$1, %%eax\n"
+   "1:\n"
+   : "=a" (ret) : : "cx", "dx" );
+   return  ret;
+}
+
+static bool has_cpuid(void)
+{
+   return flag_is_changeable_p(X86_EFLAGS_ID);
+}
+
+static void identify_cpu(struct cpu_device_id *cpu)
+{
+   char vendor_name[16];
+   int i;
+
+   vendor_name[0] = '\0'; /* Unset */
+
+   /* Find the id and vendor_name */
+   if (!has_cpuid()) {
+   /* Its a 486 if we can modify the AC flag */
+   if (flag_is_changeable_p(X86_EFLAGS_AC)) {
+   cpu->device = 0x0400; /* 486 */
+   } else {
+  

[U-Boot] [PATCH 3/4] x86: Add quick TSC calibration via PIT

[Bin Meng]

Use the same way that Linux does for quick TSC calibration via PIT
when calibration via MSR fails.

Signed-off-by: Bin Meng 
---
 arch/x86/include/asm/i8254.h |   3 +
 arch/x86/lib/tsc_timer.c | 155 +++
 2 files changed, 158 insertions(+)

diff --git a/arch/x86/include/asm/i8254.h b/arch/x86/include/asm/i8254.h
index c3ccd4f..4116de1 100644
--- a/arch/x86/include/asm/i8254.h
+++ b/arch/x86/include/asm/i8254.h
@@ -36,4 +36,7 @@
 #define PIT_CMD_MODE4  0x08/* Select mode 4 */
 #define PIT_CMD_MODE5  0x0A/* Select mode 5 */
 
+/* The clock frequency of the i8253/i8254 PIT */
+#define PIT_TICK_RATE  1193182ul
+
 #endif
diff --git a/arch/x86/lib/tsc_timer.c b/arch/x86/lib/tsc_timer.c
index fafbbfc..8a0abde 100644
--- a/arch/x86/lib/tsc_timer.c
+++ b/arch/x86/lib/tsc_timer.c
@@ -117,6 +117,157 @@ fail:
return 0;
 }
 
+/*
+ * This reads the current MSB of the PIT counter, and
+ * checks if we are running on sufficiently fast and
+ * non-virtualized hardware.
+ *
+ * Our expectations are:
+ *
+ *  - the PIT is running at roughly 1.19MHz
+ *
+ *  - each IO is going to take about 1us on real hardware,
+ *but we allow it to be much faster (by a factor of 10) or
+ *_slightly_ slower (ie we allow up to a 2us read+counter
+ *update - anything else implies a unacceptably slow CPU
+ *or PIT for the fast calibration to work.
+ *
+ *  - with 256 PIT ticks to read the value, we have 214us to
+ *see the same MSB (and overhead like doing a single TSC
+ *read per MSB value etc).
+ *
+ *  - We're doing 2 reads per loop (LSB, MSB), and we expect
+ *them each to take about a microsecond on real hardware.
+ *So we expect a count value of around 100. But we'll be
+ *generous, and accept anything over 50.
+ *
+ *  - if the PIT is stuck, and we see *many* more reads, we
+ *return early (and the next caller of pit_expect_msb()
+ *then consider it a failure when they don't see the
+ *next expected value).
+ *
+ * These expectations mean that we know that we have seen the
+ * transition from one expected value to another with a fairly
+ * high accuracy, and we didn't miss any events. We can thus
+ * use the TSC value at the transitions to calculate a pretty
+ * good value for the TSC frequencty.
+ */
+static inline int pit_verify_msb(unsigned char val)
+{
+   /* Ignore LSB */
+   inb(0x42);
+   return inb(0x42) == val;
+}
+
+static inline int pit_expect_msb(unsigned char val, u64 *tscp, unsigned long 
*deltap)
+{
+   int count;
+   u64 tsc = 0, prev_tsc = 0;
+
+   for (count = 0; count < 5; count++) {
+   if (!pit_verify_msb(val))
+   break;
+   prev_tsc = tsc;
+   tsc = rdtsc();
+   }
+   *deltap = rdtsc() - prev_tsc;
+   *tscp = tsc;
+
+   /*
+* We require _some_ success, but the quality control
+* will be based on the error terms on the TSC values.
+*/
+   return count > 5;
+}
+
+/*
+ * How many MSB values do we want to see? We aim for
+ * a maximum error rate of 500ppm (in practice the
+ * real error is much smaller), but refuse to spend
+ * more than 50ms on it.
+ */
+#define MAX_QUICK_PIT_MS 50
+#define MAX_QUICK_PIT_ITERATIONS (MAX_QUICK_PIT_MS * PIT_TICK_RATE / 1000 / 
256)
+
+static unsigned long quick_pit_calibrate(void)
+{
+   int i;
+   u64 tsc, delta;
+   unsigned long d1, d2;
+
+   /* Set the Gate high, disable speaker */
+   outb((inb(0x61) & ~0x02) | 0x01, 0x61);
+
+   /*
+* Counter 2, mode 0 (one-shot), binary count
+*
+* NOTE! Mode 2 decrements by two (and then the
+* output is flipped each time, giving the same
+* final output frequency as a decrement-by-one),
+* so mode 0 is much better when looking at the
+* individual counts.
+*/
+   outb(0xb0, 0x43);
+
+   /* Start at 0x */
+   outb(0xff, 0x42);
+   outb(0xff, 0x42);
+
+   /*
+* The PIT starts counting at the next edge, so we
+* need to delay for a microsecond. The easiest way
+* to do that is to just read back the 16-bit counter
+* once from the PIT.
+*/
+   pit_verify_msb(0);
+
+   if (pit_expect_msb(0xff, &tsc, &d1)) {
+   for (i = 1; i <= MAX_QUICK_PIT_ITERATIONS; i++) {
+   if (!pit_expect_msb(0xff-i, &delta, &d2))
+   break;
+
+   /*
+* Iterate until the error is less than 500 ppm
+*/
+   delta -= tsc;
+   if (d1+d2 >= delta >> 11)
+   continue;
+
+   /*
+* Check the PIT one more time to verify that
+* all TSC reads were stable wrt the PIT.
+*
+* Th

[U-Boot] [PATCH 4/4] x86: Save TSC frequency in the global data

[Bin Meng]

Return the saved TSC frequency in get_tbclk_mhz().

Signed-off-by: Bin Meng 
---
 arch/x86/include/asm/global_data.h | 1 +
 arch/x86/lib/tsc_timer.c   | 4 
 2 files changed, 5 insertions(+)

diff --git a/arch/x86/include/asm/global_data.h 
b/arch/x86/include/asm/global_data.h
index 721e7dc..7f22336 100644
--- a/arch/x86/include/asm/global_data.h
+++ b/arch/x86/include/asm/global_data.h
@@ -21,6 +21,7 @@ struct arch_global_data {
uint64_t tsc_base;  /* Initial value returned by rdtsc() */
uint32_t tsc_base_kclocks;  /* Initial tsc as a kclocks value */
uint32_t tsc_prev;  /* For show_boot_progress() */
+   uint32_t tsc_mhz;   /* TSC frequency in MHz */
void *new_fdt;  /* Relocated FDT */
 };
 
diff --git a/arch/x86/lib/tsc_timer.c b/arch/x86/lib/tsc_timer.c
index 8a0abde..b5f0458 100644
--- a/arch/x86/lib/tsc_timer.c
+++ b/arch/x86/lib/tsc_timer.c
@@ -293,6 +293,9 @@ unsigned __attribute__((no_instrument_function)) long 
get_tbclk_mhz(void)
 {
unsigned long fast_calibrate;
 
+   if (gd->arch.tsc_mhz)
+   return gd->arch.tsc_mhz;
+
fast_calibrate = try_msr_calibrate_tsc();
if (fast_calibrate)
return fast_calibrate;
@@ -301,6 +304,7 @@ unsigned __attribute__((no_instrument_function)) long 
get_tbclk_mhz(void)
if (!fast_calibrate)
panic("TSC frequency is ZERO");
 
+   gd->arch.tsc_mhz = fast_calibrate;
return fast_calibrate;
 }
 
-- 
1.8.2.1

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

[U-Boot] [U-boot] [Patch 1/2] keystone2: config: restructure handling of default env settings

[Ivan Khoronzhuk]

From: Murali Karicheri 

Currently to customize env for various ks2 boards, individual
variables such as NAME_FS etc are defined and included in the
common config.h to define CONFIG_EXTRA_ENV_SETTINGS. This
doesn't scale well if a variable is not applicable on a
specific board. Using this scheme, we have to define variables
with empty value and it's ugly. Instead, to allow board specific
customization of default env variable, define a common
CONFIG_EXTRA_ENV_KS2_SETTINGS for all common variables and define
board specific variables in individual board specific config.h
using CONFIG_EXTRA_ENV_KS2_BOARD_SETTINGS. Use the common and board
specific variables to define CONFIG_EXTRA_ENV_SETTINGS. This way
more variables can be added in future for individual boards
without affecting the other config.h files.

Signed-off-by: Murali Karicheri 
Signed-off-by: Ivan Khoronzhuk 
---
 include/configs/k2e_evm.h  | 16 
 include/configs/k2hk_evm.h | 16 
 include/configs/k2l_evm.h  | 16 
 include/configs/ks2_evm.h  |  7 +--
 4 files changed, 25 insertions(+), 30 deletions(-)

diff --git a/include/configs/k2e_evm.h b/include/configs/k2e_evm.h
index 8c3a0c0..6b87f6c 100644
--- a/include/configs/k2e_evm.h
+++ b/include/configs/k2e_evm.h
@@ -17,14 +17,14 @@
 /* U-Boot general configuration */
 #define CONFIG_SYS_PROMPT   "K2E EVM # "
 
-#define KS2_ARGS_UBI   "args_ubi=setenv bootargs ${bootargs} rootfstype=ubifs 
"\
-  "root=ubi0:rootfs rootflags=sync rw ubi.mtd=2,2048\0"
-
-#define KS2_FDT_NAME   "name_fdt=k2e-evm.dtb\0"
-#define KS2_ADDR_MON   "addr_mon=0x0c14\0"
-#define KS2_NAME_MON   "name_mon=skern-k2e-evm.bin\0"
-#define NAME_UBOOT "name_uboot=u-boot-spi-k2e-evm.gph\0"
-#define NAME_UBI   "name_ubi=k2e-evm-ubifs.ubi\0"
+#define CONFIG_EXTRA_ENV_KS2_BOARD_SETTINGS\
+   "addr_mon=0x0c14\0" \
+   "args_ubi=setenv bootargs ${bootargs} rootfstype=ubifs "\
+   "root=ubi0:rootfs rootflags=sync rw ubi.mtd=2,2048\0"   \
+   "name_fdt=k2e-evm.dtb\0"\
+   "name_mon=skern-k2e-evm.bin\0"  \
+   "name_ubi=k2e-evm-ubifs.ubi\0"  \
+   "name_uboot=u-boot-spi-k2e-evm.gph\0"
 
 #include 
 
diff --git a/include/configs/k2hk_evm.h b/include/configs/k2hk_evm.h
index ebf4630..33e43eb 100644
--- a/include/configs/k2hk_evm.h
+++ b/include/configs/k2hk_evm.h
@@ -17,14 +17,14 @@
 /* U-Boot general configuration */
 #define CONFIG_SYS_PROMPT   "K2HK EVM # "
 
-#define KS2_ARGS_UBI   "args_ubi=setenv bootargs ${bootargs} rootfstype=ubifs 
"\
-  "root=ubi0:rootfs rootflags=sync rw ubi.mtd=2,2048\0"
-
-#define KS2_FDT_NAME   "name_fdt=k2hk-evm.dtb\0"
-#define KS2_ADDR_MON   "addr_mon=0x0c5f\0"
-#define KS2_NAME_MON   "name_mon=skern-k2hk-evm.bin\0"
-#define NAME_UBOOT "name_uboot=u-boot-spi-k2hk-evm.gph\0"
-#define NAME_UBI   "name_ubi=k2hk-evm-ubifs.ubi\0"
+#define CONFIG_EXTRA_ENV_KS2_BOARD_SETTINGS\
+   "addr_mon=0x0c5f\0" \
+   "args_ubi=setenv bootargs ${bootargs} rootfstype=ubifs "\
+   "root=ubi0:rootfs rootflags=sync rw ubi.mtd=2,2048\0"   \
+   "name_fdt=k2hk-evm.dtb\0"   \
+   "name_mon=skern-k2hk-evm.bin\0" \
+   "name_ubi=k2hk-evm-ubifs.ubi\0" \
+   "name_uboot=u-boot-spi-k2hk-evm.gph\0"
 
 #include 
 
diff --git a/include/configs/k2l_evm.h b/include/configs/k2l_evm.h
index ec0d543..07326fc 100644
--- a/include/configs/k2l_evm.h
+++ b/include/configs/k2l_evm.h
@@ -17,14 +17,14 @@
 /* U-Boot general configuration */
 #define CONFIG_SYS_PROMPT  "K2L EVM # "
 
-#define KS2_ARGS_UBI   "args_ubi=setenv bootargs ${bootargs} rootfstype=ubifs 
"\
-  "root=ubi0:rootfs rootflags=sync rw ubi.mtd=2,4096\0"
-
-#define KS2_FDT_NAME   "name_fdt=k2l-evm.dtb\0"
-#define KS2_ADDR_MON   "addr_mon=0x0c14\0"
-#define KS2_NAME_MON   "name_mon=skern-k2l-evm.bin\0"
-#define NAME_UBOOT "name_uboot=u-boot-spi-k2l-evm.gph\0"
-#define NAME_UBI   "name_ubi=k2l-evm-ubifs.ubi\0"
+#define CONFIG_EXTRA_ENV_KS2_BOARD_SETTINGS\
+   "addr_mon=0x0c14\0" \
+   "args_ubi=setenv bootargs ${bootargs} rootfstype=ubifs "\
+   "root=ubi0:rootfs rootflags=sync rw ubi.mtd=2,4096\0"   \
+   "name_fdt=k2l-evm.dtb\0"\
+   "name_mon=skern-k2l-evm.bin\0"  \
+   "name_ubi=k2l-evm-ubifs.ubi\0"  \
+   "name_uboot=u-boot-spi-k2l-evm.gph\0"
 
 #include 
 
diff --git a/in

Re: [U-Boot] [PATCH v6 0/6] fs: fat/ext4/sandbox - Deal with files greater than 2GB

[Suriyan Ramasami]

Hello Simon,

On Mon, Nov 3, 2014 at 10:26 PM, Simon Glass  wrote:
> (trimming the CC list a bit)
>
> Hi Suriyan,
>
> On 3 November 2014 19:49, Suriyan Ramasami  wrote:
>>
>> The commands fatls/ext4ls give negative values when dealing with files
>> greater than 2GB.
>> The commands fatsize/ext4size do not update the variable filesize for
>> these files.
>>
>> To deal with this, the fs functions have been modified to take an additional
>> parameter of type "* loff_t" which is then populated. The return value of the
>> fs functions are used only for error conditions.
>
> Thanks for the new series. Can you please post the expected output of
> this with all patches applied?
>

I have summarized the output in the top of the fs-test.sh file as well.
Here, I am posting the full output:

suriyan@suriyanT430:~/git/u-boot-main.fs$ ./test/fs/fs-test.sh
  HOSTCC  scripts/basic/fixdep
  GEN /home/suriyan/git/u-boot-main.fs/sandbox/Makefile
  HOSTCC  scripts/kconfig/conf.o
  SHIPPED scripts/kconfig/zconf.tab.c
  SHIPPED scripts/kconfig/zconf.lex.c
  SHIPPED scripts/kconfig/zconf.hash.c
  HOSTCC  scripts/kconfig/zconf.tab.o
  HOSTLD  scripts/kconfig/conf
#
# configuration written to .config
#
Creating ext4 image if not already present.
Creating files in ext4 image if not already present.
[sudo] password for suriyan:
** Start sandbox/test/fs/fs-test.sb.ext4.out
pass - TC1: ls of 2.5GB.file
pass - TC1: ls of 1MB.file
FAIL - TC2: size of 1MB.file
FAIL - TC3: size of 2.5GB.file
pass - TC4: load of 1MB.file size
pass - TC4: load from 1MB.file
pass - TC5: load of 1st MB from 2.5GB.file size
pass - TC5: load of 1st MB from 2.5GB.file
pass - TC6: load of last MB from 2.5GB.file size
pass - TC6: load of last MB from 2.5GB.file
pass - TC7: load of last 1mb chunk of 2GB from 2.5GB.file size
pass - TC7: load of last 1mb chunk of 2GB from 2.5GB.file
pass - TC8: load 1st MB chunk after 2GB from 2.5GB.file size
pass - TC8: load 1st MB chunk after 2GB from 2.5GB.file
pass - TC9: load 1MB chunk crossing 2GB boundary from 2.5GB.file size
pass - TC9: load 1MB chunk crossing 2GB boundary from 2.5GB.file
pass - TC10: load 2MB from the last 1MB of 2.5GB.file - generic fail case
pass - TC11: 1MB write to  - write succeeded
pass - TC11: 1MB write to  - content verified
** End sandbox/test/fs/fs-test.sb.ext4.out
Summary: PASS: 17 FAIL: 2

Creating files in ext4 image if not already present.
** Start sandbox/test/fs/fs-test.ext4.out
pass - TC1: ls of 2.5GB.file
pass - TC1: ls of 1MB.file
pass - TC2: size of 1MB.file
pass - TC3: size of 2.5GB.file
pass - TC4: load of 1MB.file size
pass - TC4: load from 1MB.file
pass - TC5: load of 1st MB from 2.5GB.file size
pass - TC5: load of 1st MB from 2.5GB.file
FAIL - TC6: load of last MB from 2.5GB.file size
FAIL - TC6: load of last MB from 2.5GB.file
FAIL - TC7: load of last 1mb chunk of 2GB from 2.5GB.file size
FAIL - TC7: load of last 1mb chunk of 2GB from 2.5GB.file
FAIL - TC8: load 1st MB chunk after 2GB from 2.5GB.file size
FAIL - TC8: load 1st MB chunk after 2GB from 2.5GB.file
FAIL - TC9: load 1MB chunk crossing 2GB boundary from 2.5GB.file size
FAIL - TC9: load 1MB chunk crossing 2GB boundary from 2.5GB.file
pass - TC10: load 2MB from the last 1MB of 2.5GB.file - generic fail case
pass - TC11: 1MB write to  - write succeeded
pass - TC11: 1MB write to  - content verified
** End sandbox/test/fs/fs-test.ext4.out
Summary: PASS: 11 FAIL: 8

Creating files in ext4 image if not already present.
** Start sandbox/test/fs/fs-test.fs.ext4.out
pass - TC1: ls of 2.5GB.file
pass - TC1: ls of 1MB.file
pass - TC2: size of 1MB.file
pass - TC3: size of 2.5GB.file
pass - TC4: load of 1MB.file size
pass - TC4: load from 1MB.file
pass - TC5: load of 1st MB from 2.5GB.file size
pass - TC5: load of 1st MB from 2.5GB.file
FAIL - TC6: load of last MB from 2.5GB.file size
FAIL - TC6: load of last MB from 2.5GB.file
FAIL - TC7: load of last 1mb chunk of 2GB from 2.5GB.file size
FAIL - TC7: load of last 1mb chunk of 2GB from 2.5GB.file
FAIL - TC8: load 1st MB chunk after 2GB from 2.5GB.file size
FAIL - TC8: load 1st MB chunk after 2GB from 2.5GB.file
FAIL - TC9: load 1MB chunk crossing 2GB boundary from 2.5GB.file size
FAIL - TC9: load 1MB chunk crossing 2GB boundary from 2.5GB.file
pass - TC10: load 2MB from the last 1MB of 2.5GB.file - generic fail case
pass - TC11: 1MB write to  - write succeeded
pass - TC11: 1MB write to  - content verified
** End sandbox/test/fs/fs-test.fs.ext4.out
Summary: PASS: 11 FAIL: 8

Creating fat image if not already present.
Creating files in fat image if not already present.
** Start sandbox/test/fs/fs-test.sb.fat.out
pass - TC1: ls of 2.5GB.file
pass - TC1: ls of 1MB.file
FAIL - TC2: size of 1MB.file
FAIL - TC3: size of 2.5GB.file
pass - TC4: load of 1MB.file size
pass - TC4: load from 1MB.file
pass - TC5: load of 1st MB from 2.5GB.file size
pass - TC5: load o

Re: [U-Boot] [PATCH 0/6] kbuild, kconfig: sync with Linux 3.18-rc1

[Tom Rini]

On Thu, Oct 30, 2014 at 10:50:45AM +0900, Masahiro Yamada wrote:

> Masahiro Yamada (5):
>   kbuild: bug fixes and cleanups of Makefile.host
>   kbuild: improve multi-objs dependency and cleanups
>   kbuild: sync top Makefile with Linux 3.18-rc1
>   kconfig: sync kconfig files with Linux 3.18-rc1
>   kbuild: sync misc scripts with Linux 3.18-rc1
> 
> Michal Marek (1):
>   kbuild: Make scripts executable

So, I kinda sorta thought that we had talked about lagging behind a
kernel release on these things, to make sure bugs get sorted out
uptsream.  On the other hand, the kernel is up to -rc3 now, so perhaps
we should sync to that for now and play it by ear for future syncs for
this release?

-- 
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] [RFC] Removal of CREDITS

[Tom Rini]

On Thu, Oct 30, 2014 at 06:58:16AM +0100, Wolfgang Denk wrote:
> Dear Masahiro,
> 
> In message <20141030125733.259b.aa925...@jp.panasonic.com> you wrote:
> > 
> > The "CREDITS" file at the top directory does not seem
> > to be used these days.
> 
> Agreed.  Actually it has never been systematically maintained.
> 
> > I think we do not need the CREDITS file any more.
> 
> That's OK with me.

Done (when buildman finishes up testing these other PRs it's building
right now).

-- 
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] Inconsistency between $filesize and commands which accept numeric params

[Tom Rini]

On Thu, Oct 30, 2014 at 03:32:58PM +, Ian Campbell wrote:
> On Thu, 2014-10-30 at 16:21 +0100, Wolfgang Denk wrote:
> > Dear Ian,
> > 
> > In message <1414677435.2064.34.ca...@hellion.org.uk> you wrote:
> > > It seems there is some inconsistency wrt number base between commands
> > > which set $filesize in the env and the commands which might consume
> > > them.
> > 
> > That would be bugs, then.
> > 
> > > 
> > > sun7i# load scsi 0 $fdt_addr_r dtbs/$fdtfile
> > > 21639 bytes read in 191 ms (110.4 KiB/s)
> > > sun7i# printenv filesize
> > > filesize=5487
> > > 
> > > So filesize is in hex, but without an 0x prefix. But:
> > 
> > This is normal.  U-Boot uses hex input base by default.  All commands
> > should take hex input; the only inglorious exception is the "sleep"
> > command which takes decimal; numbers as arguments.
> > 
> > > sun7i# fdt addr $fdt_addr_r 0x1 
> > > sun7i# fdt set /chosen foo <$filesize>
> > > sun7i# fdt print /chosen foo  
> > > foo = <0x156f>
> > > 
> > > IOW the parameter to fdt set has been interpreted as a decimal.
> > 
> > That's a bug.
> > 
> > > So I'm not sure if the bug is that setenv_hex doesn't include the 0x, or
> > 
> > No 0x prefix should be needed anywhere.
> > 
> > > that fdt set interprets things as decimal by default instead of hex. Or
> > > maybe there is no bug at all?
> > 
> > The bug is in fdt set, then.
> > 
> > 
> > Thanks for pointing out!
> 
> Thanks for pointing me in the right direction. CCing the folks who
> get_maintainers.pl tells me might be involved with common/cmd_fdt.c
> 
> Looks like the function which does this is fdt_parse_prop, which is
> documented with:
> /*
>  * Parse the user's input, partially heuristic.  Valid formats:
>  * <0x00112233 4 05>  - an array of cells.  Numbers follow standard
>  *C conventions.
>  * [00 11 22 .. nn] - byte stream
>  * "string"   - If the the value doesn't start with "<" or "[", it is
>  *treated as a string.  Note that the quotes are
>  *stripped by the parser before we get the string.
> 
> which is inconsistent with the "U-Boot uses hex input base by default"
> mantra.

Because this is FDT centric and not U-Boot centric, yes?  Since  is a valid thing to do in an entry here.  I think the right
answer is the more hacky sounding one of when you script using 'fdt set'
you need to be mindful of the constraints on input that are imposed upon
us by FDT.   is invalid but <0xhex> is what is expected.

-- 
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 1/4] imx: mx6: Add support for MX6 plugin images

[Fabio Estevam]

Hi Ye Li,

On Tue, Nov 4, 2014 at 6:27 AM, Ye.Li  wrote:
> Plugin image is a firmware which can be executed by boot ROM to do
> device initialization, custom settings, delay assertion, etc.

Could you please elaborate a bit mode about the usage of the 'plugin image'?

When does it become useful? When should we make use of it instead of
the current DCD table?

Thanks,

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

Re: [U-Boot] Inconsistency between $filesize and commands which accept numeric params

[Ian Campbell]

On Tue, 2014-11-04 at 10:44 -0500, Tom Rini wrote:
> On Thu, Oct 30, 2014 at 03:32:58PM +, Ian Campbell wrote:
> > On Thu, 2014-10-30 at 16:21 +0100, Wolfgang Denk wrote:
> > > Dear Ian,
> > > 
> > > In message <1414677435.2064.34.ca...@hellion.org.uk> you wrote:
> > > > It seems there is some inconsistency wrt number base between commands
> > > > which set $filesize in the env and the commands which might consume
> > > > them.
> > > 
> > > That would be bugs, then.
> > > 
> > > > 
> > > > sun7i# load scsi 0 $fdt_addr_r dtbs/$fdtfile
> > > > 21639 bytes read in 191 ms (110.4 KiB/s)
> > > > sun7i# printenv filesize
> > > > filesize=5487
> > > > 
> > > > So filesize is in hex, but without an 0x prefix. But:
> > > 
> > > This is normal.  U-Boot uses hex input base by default.  All commands
> > > should take hex input; the only inglorious exception is the "sleep"
> > > command which takes decimal; numbers as arguments.
> > > 
> > > > sun7i# fdt addr $fdt_addr_r 0x1 
> > > > sun7i# fdt set /chosen foo <$filesize>
> > > > sun7i# fdt print /chosen foo  
> > > > foo = <0x156f>
> > > > 
> > > > IOW the parameter to fdt set has been interpreted as a decimal.
> > > 
> > > That's a bug.
> > > 
> > > > So I'm not sure if the bug is that setenv_hex doesn't include the 0x, or
> > > 
> > > No 0x prefix should be needed anywhere.
> > > 
> > > > that fdt set interprets things as decimal by default instead of hex. Or
> > > > maybe there is no bug at all?
> > > 
> > > The bug is in fdt set, then.
> > > 
> > > 
> > > Thanks for pointing out!
> > 
> > Thanks for pointing me in the right direction. CCing the folks who
> > get_maintainers.pl tells me might be involved with common/cmd_fdt.c
> > 
> > Looks like the function which does this is fdt_parse_prop, which is
> > documented with:
> > /*
> >  * Parse the user's input, partially heuristic.  Valid formats:
> >  * <0x00112233 4 05>- an array of cells.  Numbers follow standard
> >  *  C conventions.
> >  * [00 11 22 .. nn] - byte stream
> >  * "string" - If the the value doesn't start with "<" or "[", it is
> >  *  treated as a string.  Note that the quotes are
> >  *  stripped by the parser before we get the string.
> > 
> > which is inconsistent with the "U-Boot uses hex input base by default"
> > mantra.
> 
> Because this is FDT centric and not U-Boot centric, yes?

I guess?

>   Since  numbers> is a valid thing to do in an entry here.  I think the right
> answer is the more hacky sounding one of when you script using 'fdt set'
> you need to be mindful of the constraints on input that are imposed upon
> us by FDT.   is invalid but <0xhex> is what is expected.

The 0x prefix hack/trick is what I'm actually doing, but the maintainer
of our test system wanted some assurances that u-boot wasn't going to
change under our feet if someone fixed a bug.

Sounds like you are saying this is all working as designed, and there is
no bug, but I'll let Wolfgang and you thrash that out ;-).

Ian.

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

Re: [U-Boot] [PATCH v2 1/2] mmc: Board-specific MMC power initializations

[Tom Rini]

On Sat, Nov 01, 2014 at 11:35:43AM +0100, Paul Kocialkowski wrote:

> Some devices may use non-standard combinations of regulators to power MMC:
> this allows these devices to provide a board-specific MMC power init function
> to set everything up in their own way.
> 
> Signed-off-by: Paul Kocialkowski 
> ---
>  drivers/mmc/mmc.c | 8 
>  include/mmc.h | 2 ++
>  2 files changed, 10 insertions(+)
> 
> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> index 44a4feb..125f347 100644
> --- a/drivers/mmc/mmc.c
> +++ b/drivers/mmc/mmc.c
> @@ -1277,6 +1277,12 @@ block_dev_desc_t *mmc_get_dev(int dev)
>  }
>  #endif
>  
> +/* board-specific MMC power initializations. */
> +__weak int board_mmc_power_init(void)
> +{
> + return -1;
> +}

Since we don't check error return here which I think is fine just make
this a void?  Thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH v2 2/2] omap_hsmmc: Board-specific TWL4030 MMC power initializations

[Tom Rini]

On Sat, Nov 01, 2014 at 11:35:44AM +0100, Paul Kocialkowski wrote:

> Boards using the TWL4030 regulator may not all use the LDOs the same way
> (e.g. MMC2 power can be controlled by another LDO than VMMC2).
> This delegates TWL4030 MMC power initializations to board-specific functions,
> that may still call twl4030_power_mmc_init for the default behavior.
[snip]
> +int board_mmc_power_init(void)
> +{
> +#if defined(CONFIG_TWL4030_POWER)
> + twl4030_power_mmc_init();
> + mdelay(100);/* ramp-up delay from Linux code */
> +#endif
> + return 0;
> +}
>  #endif

I think we can do away with the #if defined(CONFIG_TWL4030_POWER) part
here since all of these boards will fail pretty spectacularly without
that being set and if someone does remove that a link error is better
than a crazy runtime problem.

[snip]
> diff --git a/drivers/mmc/omap_hsmmc.c b/drivers/mmc/omap_hsmmc.c
> index 5b0c302..6e93a07 100644
> --- a/drivers/mmc/omap_hsmmc.c
> +++ b/drivers/mmc/omap_hsmmc.c
> @@ -130,12 +130,7 @@ static unsigned char mmc_board_init(struct mmc *mmc)
>   pbias_lite = readl(&t2_base->pbias_lite);
>   pbias_lite &= ~(PBIASLITEPWRDNZ1 | PBIASLITEPWRDNZ0);
>   writel(pbias_lite, &t2_base->pbias_lite);
> -#endif
> -#if defined(CONFIG_TWL4030_POWER)
> - twl4030_power_mmc_init();
> - mdelay(100);/* ramp-up delay from Linux code */
> -#endif
> -#if defined(CONFIG_OMAP34XX)
> +
>   writel(pbias_lite | PBIASLITEPWRDNZ1 |
>   PBIASSPEEDCTRL0 | PBIASLITEPWRDNZ0,
>   &t2_base->pbias_lite);

Since it's not clear from the context here, it's OK to drop the check on
CONFIG_OMAP34XX here since there's already a test on it above where diff
cut us off?  Thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH 2/4] imx: mx6slevk: Add PMIC Pfuze support

[Przemyslaw Marczak]

Hello Ye Li,

On 09/10/2014 11:08 AM, Ye.Li wrote:

Initialize the Pfuze on I2C1 at board late init. The mx6slevk board
has Pfuze100 or Pfuze200, print the chip type by parsing the ID.

Signed-off-by: Ye.Li 
---
  board/freescale/mx6slevk/mx6slevk.c |   57 +++
  include/configs/mx6slevk.h  |7 
  2 files changed, 64 insertions(+), 0 deletions(-)

diff --git a/board/freescale/mx6slevk/mx6slevk.c 
b/board/freescale/mx6slevk/mx6slevk.c
index fedd5c3..8b6a79c 100644
--- a/board/freescale/mx6slevk/mx6slevk.c
+++ b/board/freescale/mx6slevk/mx6slevk.c
@@ -21,6 +21,8 @@
  #include 
  #include 
  #include 
+#include 
+#include 

  DECLARE_GLOBAL_DATA_PTR;

@@ -48,6 +50,8 @@ DECLARE_GLOBAL_DATA_PTR;

  #define PC MUX_PAD_CTRL(I2C_PAD_CTRL)

+#define I2C_PMIC   0
+
  /* I2C1 for PMIC */
  struct i2c_pads_info i2c_pad_info0 = {
.sda = {
@@ -191,6 +195,59 @@ int board_init(void)
return 0;
  }

+static int pfuze_init(void)
+{
+   struct pmic *p;
+   int ret;
+   unsigned int reg;
+
+   ret = power_pfuze100_init(I2C_PMIC);
+   if (ret)
+   return ret;
+
+   p = pmic_get("PFUZE100");
+   ret = pmic_probe(p);
+   if (ret)
+   return ret;
+
+   pmic_reg_read(p, PFUZE100_DEVICEID, ®);
+   printf("PMIC:  PFUZE%s ID=0x%02x\n",
+   ((reg & 0xf) == 0) ? "100" : "200", reg);
+
+   /* Set SW1AB stanby volage to 0.975V */
+   pmic_reg_read(p, PFUZE100_SW1ABSTBY, ®);
+   reg &= ~0x3f;
+   reg |= 0x1b;
+   pmic_reg_write(p, PFUZE100_SW1ABSTBY, reg);
+
+   /* Set SW1AB/VDDARM step ramp up time from 16us to 4us/25mV */
+   pmic_reg_read(p, PUZE_100_SW1ABCONF, ®);
+   reg &= ~0xc0;
+   reg |= 0x40;
+   pmic_reg_write(p, PUZE_100_SW1ABCONF, reg);
+
+   /* Set SW1C standby voltage to 0.975V */
+   pmic_reg_read(p, PFUZE100_SW1CSTBY, ®);
+   reg &= ~0x3f;
+   reg |= 0x1b;
+   pmic_reg_write(p, PFUZE100_SW1CSTBY, reg);
+
+   /* Set SW1C/VDDSOC step ramp up time from 16us to 4us/25mV */
+   pmic_reg_read(p, PFUZE100_SW1CCONF, ®);
+   reg &= ~0xc0;
+   reg |= 0x40;
+   pmic_reg_write(p, PFUZE100_SW1CCONF, reg);
+
+   return 0;
+}
+
+int board_late_init(void)
+{
+   pfuze_init();
+
+   return 0;
+}


Why not use power_init_board()?
It's dedicated and called at common/board_r.c.


+
  u32 get_board_rev(void)
  {
return get_cpu_rev();
diff --git a/include/configs/mx6slevk.h b/include/configs/mx6slevk.h
index bf5066f..09d0896 100644
--- a/include/configs/mx6slevk.h
+++ b/include/configs/mx6slevk.h
@@ -30,6 +30,7 @@
  #define CONFIG_SYS_MALLOC_LEN (3 * SZ_1M)

  #define CONFIG_BOARD_EARLY_INIT_F
+#define CONFIG_BOARD_LATE_INIT
  #define CONFIG_MXC_GPIO

  #define CONFIG_MXC_UART
@@ -66,6 +67,12 @@
  #define CONFIG_SYS_I2C_MXC
  #define CONFIG_SYS_I2C_SPEED10

+/* PMIC */
+#define CONFIG_POWER
+#define CONFIG_POWER_I2C
+#define CONFIG_POWER_PFUZE100
+#define CONFIG_POWER_PFUZE100_I2C_ADDR 0x08


I assume that the I2C addr is const, if yes then it should be moved to 
the PFUZE100 header.



+
  /* allow to overwrite serial and ethaddr */
  #define CONFIG_ENV_OVERWRITE
  #define CONFIG_CONS_INDEX 1



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] power: LP8720 regulator support

[Tom Rini]

On Sat, Nov 01, 2014 at 12:01:37PM +0100, Paul Kocialkowski wrote:
> Le mardi 28 octobre 2014 à 18:32 +0100, Paul Kocialkowski a écrit :
> > This adds support for the LP8720 i2c regulator, as found in e.g. the LG
> > Optimus Black (P970), codename sniper. This code supports setting up and
> > enabling one of the 5 LDOs that the IC provides.
> > Other more advanced features are unsupported.
> > 
> > Signed-off-by: Paul Kocialkowski 
> > ---
> >  drivers/power/Makefile |1 +
> >  drivers/power/lp8720.c |  107 
> > 
> >  include/lp8720.h   |   93 +
> >  3 files changed, 201 insertions(+)
> >  create mode 100644 drivers/power/lp8720.c
> >  create mode 100644 include/lp8720.h
> > 
> > diff --git a/drivers/power/Makefile b/drivers/power/Makefile
> > index dc64e4d..65be5a0 100644
> > --- a/drivers/power/Makefile
> > +++ b/drivers/power/Makefile
> > @@ -9,6 +9,7 @@ obj-$(CONFIG_AXP152_POWER)  += axp152.o
> >  obj-$(CONFIG_AXP209_POWER) += axp209.o
> >  obj-$(CONFIG_EXYNOS_TMU)   += exynos-tmu.o
> >  obj-$(CONFIG_FTPMU010_POWER)   += ftpmu010.o
> > +obj-$(CONFIG_LP8720_POWER) += lp8720.o
> >  obj-$(CONFIG_TPS6586X_POWER)   += tps6586x.o
> >  obj-$(CONFIG_TWL4030_POWER)+= twl4030.o
> >  obj-$(CONFIG_TWL6030_POWER)+= twl6030.o
> > diff --git a/drivers/power/lp8720.c b/drivers/power/lp8720.c
> > new file mode 100644
> > index 000..ac7fc11
> > --- /dev/null
> > +++ b/drivers/power/lp8720.c
> > @@ -0,0 +1,107 @@
> > +/*
> > + * Copyright (C) 2014 Paul Kocialkowski 
> > + *
> > + * SPDX-License-Identifier:GPL-2.0+
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +static struct lp8720_info lp8720_info;
> > +
> > +static int lp8720_write(u8 reg, u8 val)
> > +{
> > +   return i2c_write(lp8720_info.chip_idsel, reg, 1, &val, 1);
> > +}
> > +
> > +static int lp8720_read(u8 reg, u8 *val)
> > +{
> > +   return i2c_read(lp8720_info.chip_idsel, reg, 1, val, 1);
> > +}
> 
> Should I ifdef for I2C and GPIO support? It seems that GPIO support only
> has board-sepcific config options, so this may be hard. There is
> CONFIG_DM_GPIO for driver model, but it is apparently not always used,
> especially not on SPL.

Don't code for what you can't test.  Which way are you using this on the
Optimus?  And in general, any comments here Przemyslaw?  Thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH 4/4] imx: mx6: Set Pfuze mode to decrease power number for DSM

[Przemyslaw Marczak]

Hello Ye Li,

On 09/10/2014 11:08 AM, Ye.Li wrote:

Set all switches APS mode in normal and PFM mode in standby. So when
mx6 entering DSM mode, the power number can be decreased. There is
no impact for mx6 in run mode.

Changes for boards:
-mx6 sabreauto
-mx6 sabresd
-mx6slevk
-mx6sxsabresd

Signed-off-by: Ye.Li 
---
  board/freescale/mx6qsabreauto/mx6qsabreauto.c |   36 +
  board/freescale/mx6sabresd/mx6sabresd.c   |   36 +
  board/freescale/mx6slevk/mx6slevk.c   |   36 +
  board/freescale/mx6sxsabresd/mx6sxsabresd.c   |   36 +
  4 files changed, 144 insertions(+), 0 deletions(-)

diff --git a/board/freescale/mx6qsabreauto/mx6qsabreauto.c 
b/board/freescale/mx6qsabreauto/mx6qsabreauto.c
index 76b024b..9e79915 100644
--- a/board/freescale/mx6qsabreauto/mx6qsabreauto.c
+++ b/board/freescale/mx6qsabreauto/mx6qsabreauto.c
@@ -263,6 +263,37 @@ int board_init(void)
return 0;
  }

+/* set all switches APS in normal and PFM mode in standby */


I think that the "chip" is quite misleading.
Just use chipid and check the real value instead of using it as bool.
And the PF100 DEVICEID should be defined in pf100 header.


+static int pfuze_setup_mode(struct pmic *p, int chip)
+{
+   unsigned char offset, i, switch_num, value;
+
+   if (!chip) {
+   /* pfuze100 */
+   switch_num = 6;
+   offset = 0x31;
+   } else {
+   /* pfuze200 */
+   switch_num = 4;
+   offset = 0x38;
+   }
+
+   value = 0xc;


If you change "magic" values (e.g. 0xc) with proper defines in pmic 
header, then it could be reused in the future and the code will be more 
readable.



+   if (pmic_reg_write(p, 0x23, value)) {
+   printf("Set SW1AB mode error!\n");
+   return -1;
+   }
+
+   for (i = 0; i < switch_num - 1; i++) {
+   if (pmic_reg_write(p, offset + i * 7, value)) {
+   printf("Set switch%x mode error!\n", offset);
+   return -1;
+   }
+   }
+
+   return 0;
+}


The function above is duplicated few times in each board code.
Why not make it common and just one?


+
  static int pfuze_init(void)
  {
struct pmic *p;
@@ -281,6 +312,11 @@ static int pfuze_init(void)
pmic_reg_read(p, PFUZE100_DEVICEID, ®);
printf("PMIC:  PFUZE100 ID=0x%02x\n", reg);

+   if (pfuze_setup_mode(p, (reg & 0xf))) {
+   printf("setup pfuze mode error!\n");
+   return -1;
+   }
+
/* Set SW1AB stanby volage to 0.975V */
pmic_reg_read(p, PFUZE100_SW1ABSTBY, ®);
reg &= ~0x3f;
diff --git a/board/freescale/mx6sabresd/mx6sabresd.c 
b/board/freescale/mx6sabresd/mx6sabresd.c
index 72d6562..810fe13 100644
--- a/board/freescale/mx6sabresd/mx6sabresd.c
+++ b/board/freescale/mx6sabresd/mx6sabresd.c
@@ -456,6 +456,37 @@ int board_init(void)
return 0;
  }

+/* set all switches APS in normal and PFM mode in standby */
+static int pfuze_setup_mode(struct pmic *p, int chip)
+{
+   unsigned char offset, i, switch_num, value;
+
+   if (!chip) {
+   /* pfuze100 */
+   switch_num = 6;
+   offset = 0x31;
+   } else {
+   /* pfuze200 */
+   switch_num = 4;
+   offset = 0x38;
+   }
+
+   value = 0xc;
+   if (pmic_reg_write(p, 0x23, value)) {
+   printf("Set SW1AB mode error!\n");
+   return -1;
+   }
+
+   for (i = 0; i < switch_num - 1; i++) {
+   if (pmic_reg_write(p, offset + i * 7, value)) {
+   printf("Set switch%x mode error!\n", offset);
+   return -1;
+   }
+   }
+
+   return 0;
+}
+
  static int pfuze_init(void)
  {
struct pmic *p;
@@ -475,6 +506,11 @@ static int pfuze_init(void)
printf("PMIC:  PFUZE%s ID=0x%02x\n",
((reg & 0xf) == 0) ? "100" : "200", reg);

+   if (pfuze_setup_mode(p, (reg & 0xf))) {
+   printf("setup pfuze mode error!\n");
+   return -1;
+   }
+
/* Increase VGEN3 from 2.5 to 2.8V */
pmic_reg_read(p, PFUZE100_VGEN3VOL, ®);
reg &= ~0xf;
diff --git a/board/freescale/mx6slevk/mx6slevk.c 
b/board/freescale/mx6slevk/mx6slevk.c
index 8b6a79c..fe5e37d 100644
--- a/board/freescale/mx6slevk/mx6slevk.c
+++ b/board/freescale/mx6slevk/mx6slevk.c
@@ -195,6 +195,37 @@ int board_init(void)
return 0;
  }

+/* set all switches APS in normal and PFM mode in standby */
+static int pfuze_setup_mode(struct pmic *p, int chip)
+{
+   unsigned char offset, i, switch_num, value;
+
+   if (!chip) {
+   /* pfuze100 */
+   switch_num = 6;
+   offset = 0x31;
+   } else {
+   /* pfuze200 */
+   switch_num = 4;
+   offset = 0x3

Re: [U-Boot] Building fw_printenv (e.g. make env) failing

[Tom Rini]

On Sun, Nov 02, 2014 at 11:05:04AM +0100, Jeroen Hofstee wrote:
> Hello Marcel,
> 
> On 02-11-14 02:46, Marcel Ziswiler wrote:
> >Quick question: How does one actually go about building fw_printenv
> >nowadays? At lest just doing 'make env' fails for me:
> >
> >[user@host u-boot.git]$ make env
> >   HOSTCC  tools/env/aes.o
> >   HOSTCC  tools/env/crc32.o
> >   HOSTCC  tools/env/ctype.o
> >   HOSTCC  tools/env/env_attr.o
> >   HOSTCC  tools/env/env_flags.o
> >   HOSTCC  tools/env/fw_env.o
> >In file included from tools/env/fw_env.c:117:0:
> >include/env_default.h:110:11: error: expected ‘}’ before
> >‘CONFIG_SYS_ARCH’
> >make[1]: *** [tools/env/fw_env.o] Error 1
> >make: *** [env] Error 2
> >
> >I suspect some generated/autoconf.h discrepancy but am unsure how to
> >properly fix that. Any suggestions?
> >
> >
> 
> make sandbox_config
> make env
> 
> Should do the job.

Yes.  I forget if I spelled this out in the release notes but now that
we support CONFIG_LOCALVERSION we cannot build tools without a valid
config.  For distro build support doing a "make sandbox_config ; make
env" will be a valid thing to do for some far'ish time back as well.

-- 
Tom


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

[U-Boot] [RFC PATCH] tricorder: rewrite tricordereeprom command

[Andreas Bießmann]

This rewrite uses lately promoted eeprom_init(int) function to choose the
right I2C bus when writing data to the EEPROM.

Signed-off-by: Andreas Bießmann 
Cc: Marek Vasut 

---

Hi Marek,

works this for you? I can't kill the i2c_read() cause eeprom_read() will blow
up my SPL size.
While you are on it, there are some other eeprom implementations (freescale)
not yet covered by your removal.

regards

Andreas Bießmann

 board/corscience/tricorder/tricorder-eeprom.c | 36 +++
 1 file changed, 9 insertions(+), 27 deletions(-)

diff --git a/board/corscience/tricorder/tricorder-eeprom.c 
b/board/corscience/tricorder/tricorder-eeprom.c
index 1c74a0f..340a009 100644
--- a/board/corscience/tricorder/tricorder-eeprom.c
+++ b/board/corscience/tricorder/tricorder-eeprom.c
@@ -77,17 +77,13 @@ static int handle_eeprom_v1(struct tricorder_eeprom *eeprom)
 
 int tricorder_get_eeprom(int addr, struct tricorder_eeprom *eeprom)
 {
-#ifdef CONFIG_SYS_EEPROM_BUS_NUM
unsigned int bus = i2c_get_bus_num();
i2c_set_bus_num(CONFIG_SYS_EEPROM_BUS_NUM);
-#endif
 
memset(eeprom, 0, TRICORDER_EEPROM_SIZE);
 
i2c_read(addr, 0, 2, (unsigned char *)eeprom, TRICORDER_EEPROM_SIZE);
-#ifdef CONFIG_SYS_EEPROM_BUS_NUM
i2c_set_bus_num(bus);
-#endif
 
if (be32_to_cpu(eeprom->magic) != TRICORDER_EEPROM_MAGIC) {
warn_wrong_value("magic", TRICORDER_EEPROM_MAGIC,
@@ -138,9 +134,6 @@ int tricorder_eeprom_write(unsigned devaddr, const char 
*name,
int ret;
unsigned char *p;
int i;
-#ifdef CONFIG_SYS_EEPROM_BUS_NUM
-   unsigned int bus;
-#endif
 
memset(eeprom, 0, TRICORDER_EEPROM_SIZE);
memset(eeprom_verify, 0, TRICORDER_EEPROM_SIZE);
@@ -172,33 +165,23 @@ int tricorder_eeprom_write(unsigned devaddr, const char 
*name,
print_buffer(0, &eeprom, 1, sizeof(eeprom), 16);
 #endif
 
-#ifdef CONFIG_SYS_EEPROM_BUS_NUM
-   bus = i2c_get_bus_num();
-   i2c_set_bus_num(CONFIG_SYS_EEPROM_BUS_NUM);
-#endif
+   eeprom_init(CONFIG_SYS_EEPROM_BUS_NUM);
 
-   /* do page write to the eeprom */
-   for (i = 0, p = (unsigned char *)&eeprom;
-i < sizeof(eeprom);
-i += 32, p += 32) {
-   ret = i2c_write(devaddr, i, CONFIG_SYS_I2C_EEPROM_ADDR_LEN,
-   p, min(sizeof(eeprom) - i, 32));
-   if (ret)
-   break;
-   udelay(5000); /* 5ms write cycle timing */
-   }
+   ret = eeprom_write(devaddr, 0, (unsigned char *)&eeprom,
+   TRICORDER_EEPROM_SIZE);
+   if (ret)
+   printf("Tricorder: Could not write EEPROM content!\n");
 
-   ret = i2c_read(devaddr, 0, 2, (unsigned char *)&eeprom_verify,
+   ret = eeprom_read(devaddr, 0, (unsigned char *)&eeprom_verify,
TRICORDER_EEPROM_SIZE);
+   if (ret)
+   printf("Tricorder: Could not read EEPROM content!\n");
 
if (memcmp(&eeprom, &eeprom_verify, sizeof(eeprom)) != 0) {
printf("Tricorder: Could not verify EEPROM content!\n");
ret = 1;
}
 
-#ifdef CONFIG_SYS_EEPROM_BUS_NUM
-   i2c_set_bus_num(bus);
-#endif
return ret;
 }
 
@@ -206,7 +189,7 @@ int do_tricorder_eeprom(cmd_tbl_t *cmdtp, int flag, int 
argc, char *argv[])
 {
if (argc == 3) {
ulong dev_addr = simple_strtoul(argv[2], NULL, 16);
-   eeprom_init();
+
if (strcmp(argv[1], "read") == 0) {
int rcode;
 
@@ -220,7 +203,6 @@ int do_tricorder_eeprom(cmd_tbl_t *cmdtp, int flag, int 
argc, char *argv[])
char *version = argv[4];
char *serial = argv[5];
char *interface = NULL;
-   eeprom_init();
 
if (argc == 7)
interface = argv[6];
-- 
2.1.1

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

[U-Boot] [U-boot] [Patch v2] ks2_evm: config: enable fatload command

[Ivan Khoronzhuk]

The keystone2 evm can boot from USB partition with FAT32 FS, so
enable generic load command and fatload command usage.

Acked-by: Murali Karicheri 
Signed-off-by: Ivan Khoronzhuk 
---

v2..v1:
- enabled generic load command

 include/configs/ks2_evm.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/configs/ks2_evm.h b/include/configs/ks2_evm.h
index b30e72f..bddbb1c 100644
--- a/include/configs/ks2_evm.h
+++ b/include/configs/ks2_evm.h
@@ -225,6 +225,8 @@
 #define CONFIG_CMD_SF
 #define CONFIG_CMD_EEPROM
 #define CONFIG_CMD_USB
+#define CONFIG_CMD_FAT
+#define CONFIG_CMD_FS_GENERIC
 
 /* U-Boot general configuration */
 #define CONFIG_SYS_GENERIC_BOARD
-- 
1.9.1

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

[U-Boot] [PATCH 2/2] mtd: nor: initialize writebufsize field

[Andrew Ruder]

UBI drivers error out if writebufsize is not filled in correctly.  Grab
this information from the CFI flash_info struct.

Signed-off-by: Andrew Ruder 
Cc: Wolfgang Denk 
Cc: Heiko Schocher 
Cc: Stefan Roese 
---
 drivers/mtd/cfi_mtd.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/mtd/cfi_mtd.c b/drivers/mtd/cfi_mtd.c
index ac805ff..d4c9609 100644
--- a/drivers/mtd/cfi_mtd.c
+++ b/drivers/mtd/cfi_mtd.c
@@ -226,6 +226,7 @@ int cfi_mtd_init(void)
mtd->flags  = MTD_CAP_NORFLASH;
mtd->size   = fi->size;
mtd->writesize  = 1;
+   mtd->writebufsize   = fi->buffer_size;
 
mtd->_erase = cfi_mtd_erase;
mtd->_read  = cfi_mtd_read;
-- 
2.1.1

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

[U-Boot] [PATCH 1/2] ubi: enable error reporting in initialization

[Andrew Ruder]

The UBI layer will disable much of its error reporting when it is
compiled into the linux kernel to avoid stopping boot.  We want this
error reporting in U-Boot since we don't initialize the UBI layer until
it is used and want the error reporting.

We force this by telling the UBI layer we are building as a module.

Signed-off-by: Andrew Ruder 
Cc: Wolfgang Denk 
Cc: Heiko Schocher 
Cc: Kyungmin Park 
---
 include/ubi_uboot.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/ubi_uboot.h b/include/ubi_uboot.h
index 1fd15f4..6ff0e23 100644
--- a/include/ubi_uboot.h
+++ b/include/ubi_uboot.h
@@ -51,6 +51,8 @@
 
 #undef CONFIG_MTD_UBI_BLOCK
 
+#define CONFIG_MTD_UBI_MODULE
+
 #if !defined(CONFIG_MTD_UBI_BEB_LIMIT)
 #define CONFIG_MTD_UBI_BEB_LIMIT   20
 #endif
-- 
2.1.1

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

[U-Boot] [PATCH] ext4: goni: Modify dfu_alt_info's file names to have absolute path

[Lukasz Majewski]

After the clean up performed in the commit 1151b7ac10b81ecbb the DFU
subsystem requires absolute patch for correct operation.

Signed-off-by: Lukasz Majewski 
---
 include/configs/s5p_goni.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/configs/s5p_goni.h b/include/configs/s5p_goni.h
index 0c6e9c7..8ae3e64 100644
--- a/include/configs/s5p_goni.h
+++ b/include/configs/s5p_goni.h
@@ -121,8 +121,8 @@
 
 #define CONFIG_DFU_ALT \
"u-boot raw 0x80 0x400;" \
-   "uImage ext4 0 2;" \
-   "exynos3-goni.dtb ext4 0 2;" \
+   "/uImage ext4 0 2;" \
+   "/exynos3-goni.dtb ext4 0 2;" \
""PARTS_ROOT" part 0 5\0"
 
 #define PARTS_DEFAULT \
-- 
2.0.0.rc2

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

[U-Boot] [PATCH] dfu: thor: fix: Modify dfu_get_alt() function to support absolute paths

[Lukasz Majewski]

Recently the ext4 file system imposed passing absolute path with its file
name parameter.
As a result dfu_alt_info env variable has been modified to provide absolute
path when ext4 file system is accessed (e.g. /uImage ext4 0 2;).

Unfortunately, lthor flashing program provides plain file name (like uImage)
and hence those two file names do not match anymore.

Presented commit also allows lthor to write files to sub directories (like
/boot/bin/uImage).

Signed-off-by: Lukasz Majewski 
---
 drivers/dfu/dfu.c | 29 +++--
 1 file changed, 27 insertions(+), 2 deletions(-)

diff --git a/drivers/dfu/dfu.c b/drivers/dfu/dfu.c
index 55e6a83..1e9ccdc 100644
--- a/drivers/dfu/dfu.c
+++ b/drivers/dfu/dfu.c
@@ -544,10 +544,35 @@ struct dfu_entity *dfu_get_entity(int alt)
 int dfu_get_alt(char *name)
 {
struct dfu_entity *dfu;
+   char *str;
 
list_for_each_entry(dfu, &dfu_list, list) {
-   if (!strncmp(dfu->name, name, strlen(dfu->name)))
-   return dfu->alt;
+   if (dfu->name[0] != '/') {
+   if (!strncmp(dfu->name, name, strlen(dfu->name)))
+   return dfu->alt;
+   } else {
+   /*
+* One must also consider absolute path
+* (/boot/bin/uImage) available at dfu->name when
+* compared "plain" file name (uImage)
+*
+* It is the case for e.g. thor gadget where lthor SW
+* sends only the file name, so only the very last part
+* of patch must be checked for equality
+*/
+
+   str = strstr(dfu->name, name);
+   if (!str)
+   continue;
+
+   /*
+* Check if matching substring is the last element of
+* dfu->name (uImage)
+*/
+   if (strlen(dfu->name) ==
+   ((str - dfu->name) + strlen(name)))
+   return dfu->alt;
+   }
}
 
return -ENODEV;
-- 
2.0.0.rc2

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

Re: [U-Boot] Query on the ci_udc driver for USB client implementation

[Lukasz Majewski]

Hi Sanchayan,

> On Tuesday 04 November 2014 10:25 AM, Marek Vasut wrote:
> > On Monday, November 03, 2014 at 04:46:48 PM, Fabio Estevam wrote:
> >> On Mon, Nov 3, 2014 at 3:33 AM, Sanchayan Maity
> >>
> >>  wrote:
> >>> Hello,
> >>>
> >>> Any pointers?
> >>
> >> Adding Marek and Stefan on Cc in case they can provide some help.
> >>
> >> Regards,
> >>
> >> Fabio Estevam
> >>
> >>> Thanks & Regards,
> >>> Sanchayan Maity.
> >>>
> >>> On Thursday 30 October 2014 11:14 AM, Sanchayan Maity wrote:
>  Hello,
> 
>  I am currently implementing USB Host and client support for
>  Freescale Vybrid platform in u-boot. I managed to get the host
>  implementation working.
> 
>  For the host side, usb start calls usb_init(), which in turns
>  call, usb_lowlevel_init(), from there into the ehic_hcd_init()
>  of my implementation. So, setting up the necessary clocks and
>  plls for USB in my implementation and then setting up the
>  usb_ehci, ehci_hccr and echi_hcor structures was all. The flow
>  and setup required i was able to trace.
> 
>  The USB client part is not clear to me. I was thinking i can use
>  the ci_udc driver somehow to implement the client part. How can
>  i use the ci_udc driver to implement client functionality?. From
>  what i could see, the usb_gadget_driver_register() is suppose to
>  be the first call. But, i couldn't trace from where this gets
>  called or the flow and setup is suppose to be. OR Is a separate
>  client driver required and nothing generic can be used akin to
>  how it could be done for host?
> > 
> > See include/configs/sansa_fuze_plus.h , you need the gadget driver
> > for the function you want to implement , in this case it's ethernet
> > for example (selected via CONFIG_USB_ETH_CDC ).
> > 
> > An example of DFU/UMS can be found in
> > include/configs/exynos4-common.h and to activate those, you need to
> > use the 'dfu' or 'ums' commands.
> 
> Thank you Marek. I had enabled usb ether options already and was
> trying to test USB client functionality with RNDIS. For some reason
> it was not working and i was not able to trace the issue and
> subsequently was not sure about the client part. Your inputs cleared
> my doubts. I tried UMS and DFU. UMS is working just fine and i can
> download the respective images through DFU. Though this DFU is not
> working full proof, but, i can figure that out now i feel. 

I'm very happy that UMS is working seamlessly. What kind of trouble do
you have with DFU?

> 
> Thanks again for your inputs. Cheers!
> 
> Best Regards,
> Sanchayan.
> 
> > 
>  Sorry if i am asking this question in the wrong place. I
>  couldn't find anyone in the u-boot IRC channel nor find
>  something similar to the kernel-newbies mailing list.
> > 
> > There isn't any, so ask away ;-)
> > 
>  Hope i am asking the right questions.
> > [...]
> > 
> > Best regards,
> > Marek Vasut
> > 



-- 
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 01/11] am335x: make get_board_rev() function weak

[Tom Rini]

On Mon, Nov 03, 2014 at 11:32:17AM +0200, Igor Grinberg wrote:

> Current get_board_rev() function returns a hard coded value which is
> obviously incorrect for the majority of boards.
> Allow boards to provide a correct implementation by making this
> function weak.
> 
> Signed-off-by: Igor Grinberg 
> ---
>  arch/arm/cpu/armv7/am33xx/sys_info.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/cpu/armv7/am33xx/sys_info.c 
> b/arch/arm/cpu/armv7/am33xx/sys_info.c
> index 2ce682f..c297fd8 100644
> --- a/arch/arm/cpu/armv7/am33xx/sys_info.c
> +++ b/arch/arm/cpu/armv7/am33xx/sys_info.c
> @@ -18,6 +18,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  struct ctrl_stat *cstat = (struct ctrl_stat *)CTRL_BASE;
>  
> @@ -53,7 +54,7 @@ u32 get_cpu_type(void)
>   * get_board_rev() - setup to pass kernel board revision information
>   * returns:(bit[0-3] sub version, higher bit[7-4] is higher version)
>   */
> -u32 get_board_rev(void)
> +u32 __weak get_board_rev(void)
>  {
>   return BOARD_REV_ID;
>  }

Which is a hard-coded 0 anyhow.  Can you please update the comment to
say something along the lines of "Return 0 for the ATAG REVISION tag
value" along with making it weak and nuke BOARD_REV_ID from the header
as well?  Thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH 03/11] omap3: cm-t35: move the USB hub reset code

[Tom Rini]

On Mon, Nov 03, 2014 at 11:32:19AM +0200, Igor Grinberg wrote:

> Extract the USB hub reset code to a common location where it can be
> reused by other compulab boards.
> 
> Signed-off-by: Igor Grinberg 

Reviewed-by: Tom Rini 

-- 
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 05/11] omap3: cm-t35: move the SMC911x code

[Tom Rini]

On Mon, Nov 03, 2014 at 11:32:21AM +0200, Igor Grinberg wrote:

> Extract the SMC911x initialization code to a common location where it
> can be reused by other compulab omap3 based boards.
> 
> Signed-off-by: Igor Grinberg 

Reviewed-by: Tom Rini 

-- 
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 02/11] compulab: refactor board revision handling

[Tom Rini]

On Mon, Nov 03, 2014 at 11:32:18AM +0200, Igor Grinberg wrote:
> Move board revision handling code to a common location
> for further reuse.
> 
> Signed-off-by: Igor Grinberg 

Reviewed-by: Tom Rini 

-- 
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 04/11] omap3: cm-t35: extract the splash code from board

[Tom Rini]

On Mon, Nov 03, 2014 at 11:32:20AM +0200, Igor Grinberg wrote:

> The splash screen loading code can be reused by other compulab boards.
> For now extract it to a common location for further reuse.
> 
> This also switches the splash code dependency from CONFIG_LCD to
> CONFIG_SPLASH_SCREEN as it should normally be.
> 
> In addition this patch fixes the accidental dependency of the
> get_board_mem_timings() function on CONFIG_LCD, by just moving the
> splash code and leaving the above function intact.
> 
> Signed-off-by: Igor Grinberg 

Reviewed-by: Tom Rini 

-- 
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 06/11] omap3: cm-t35: move get_board_serial() fallback

[Tom Rini]

On Mon, Nov 03, 2014 at 11:32:22AM +0200, Igor Grinberg wrote:

> The fallback is used for cases when CONFIG_SERIAL_TAG defined, but the
> eeprom is not used.
> The fallback is useful for more than one CompuLab board, so move it to a
> common location.
> 
> Signed-off-by: Igor Grinberg 

Reviewed-by: Tom Rini 

-- 
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 09/11] omap3: cm-t3517: add USB support

[Tom Rini]

On Mon, Nov 03, 2014 at 11:32:25AM +0200, Igor Grinberg wrote:

> Add both host and mUSB support.
> Currently, the selection between host USB and mUSB is done through the
> config file.
> 
> Signed-off-by: Igor Grinberg 

Reviewed-by: Tom Rini 

-- 
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 08/11] omap3: cm-t3517: add basic board support

[Tom Rini]

On Mon, Nov 03, 2014 at 11:32:24AM +0200, Igor Grinberg wrote:

> CompuLab cm-t3517 is Computer on Module (CoM) based on AM3517 SoC.
> Features: up to 256MB DDR2, up to 512MB NAND, USB hub, mUSB, WiFi, BT,
> Analog audio codec, touch screen controller, LED.
> 
> Add basic support including:
> LED, Serial console, NAND, MMC, GPIO, I2C, 256MB DRAM.
> 
> Signed-off-by: Igor Grinberg 
[snip]
> +/*
> + * The early kernel mapping on ARM currently only maps from the base of DRAM
> + * to the end of the kernel image.  The kernel is loaded at DRAM base + 
> 0x8000.
> + * The early kernel pagetable uses DRAM base + 0x4000 to DRAM base + 0x8000,
> + * so that leaves DRAM base to DRAM base + 0x4000 available.
> + */
> +#define CONFIG_SYS_BOOTMAPSZ 0x4000

The big comment about layout at the top of
include/configs/ti_armv7_common.h applies to omap3 too, are you sure you
want to go in the direction instead?  In fact, are you sure you can't /
don't want to leverage that file?

> +#define CONFIG_SYS_BAUDRATE_TABLE{4800, 9600, 19200, 38400, 57600,\
> + 115200}

Use the default table?

> +#define CONFIG_SYS_MEMTEST_START (OMAP34XX_SDRC_CS0) /* memtest */
> + /* works on */
> +#define CONFIG_SYS_MEMTEST_END   (OMAP34XX_SDRC_CS0 + \
> + 0x01F0) /* 31MB */

Really want this on?  See doc/README.memory-test

-- 
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 2/2] ARM: TI: omap3: remove raw initrd support in omap3_igep00x0 config file since it is now in ti_armv7_common.h

[Tom Rini]

On Mon, Nov 03, 2014 at 02:26:18PM +0100, Guillaume GARDET wrote:

> Signed-off-by: Guillaume GARDET 
> Cc: Tom Rini 

Reviewed-by: Tom Rini 

-- 
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 07/11] omap: hsmmc: assume cd gpio is active low

[Tom Rini]

On Mon, Nov 03, 2014 at 11:32:23AM +0200, Igor Grinberg wrote:

> Switch the default CD GPIO polarity to active low.
> 
> The current hsmmc driver assumption that the CD GPIO is active high, but
> in the real hardware, usually the opposite holds.
> The usual SD card socket has a mechanical switch which is grounded as
> soon as a card is inserted.
> Of course there might be some board logic which inverts the signal, but
> as far as current users are concerned, there is no such logic.
> 
> Current U-Boot users either not using the CD functionality, or have a
> different way (e.g. external to SoC GPIO controller) for checking the
> card presence.
> 
> This patch also brings the polarity assumption in line with the Linux
> kernel and adds appropriate comments.
> 
> This patch also might spare issues once the TWL GPIO driver will be
> converted to the DM.
> 
> Signed-off-by: Igor Grinberg 
> Cc: Pantelis Antoniou 
> Cc: Dmitry Lifshitz 

Reviewed-by: Tom Rini 

-- 
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 10/11] omap3: cm-t3517: add Ethernet support

[Tom Rini]

On Mon, Nov 03, 2014 at 11:32:26AM +0200, Igor Grinberg wrote:

> Add both EMAC and SMC911x support.
> 
> Signed-off-by: Igor Grinberg 

Reviewed-by: Tom Rini 

-- 
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 11/11] omap3: cm-t3517: add LCD/DVI and splash support

[Tom Rini]

On Mon, Nov 03, 2014 at 11:32:27AM +0200, Igor Grinberg wrote:

> Add support for splash screen on both DVI and SCF0403 LCD.
> 
> Signed-off-by: Igor Grinberg 

Reviewed-by: Tom Rini 

-- 
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 1/2] ARM: TI: Enable raw initrd support

[Tom Rini]

On Mon, Nov 03, 2014 at 02:26:17PM +0100, Guillaume GARDET wrote:

> Signed-off-by: Guillaume GARDET 
> Cc: Tom Rini 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [U-boot] [Patch] dma: keystone_nav: remove spurious qm_cfg verification

[Tom Rini]

On Tue, Nov 04, 2014 at 01:39:27AM +0200, Ivan Khoronzhuk wrote:

> The verification qm_cfg existence is done at ksnav_init().
> So, there is no need to verify it after initialization.
> 
> Signed-off-by: Ivan Khoronzhuk 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [U-boot] [Patch 2/2] keystone2: change default boot mode to ubi

[Tom Rini]

On Mon, Nov 03, 2014 at 06:09:52PM +0200, Ivan Khoronzhuk wrote:

> From: Murali Karicheri 
> 
> To allow out of box demo, change default boot mode to ubi
> boot now that NAND is functional in latest EVMs.
> 
> Signed-off-by: Murali Karicheri 
> Signed-off-by: Ivan Khoronzhuk 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [U-boot] [Patch 1/2] ks2_evm: configs: fix UBI volume name

[Tom Rini]

On Mon, Nov 03, 2014 at 06:09:51PM +0200, Ivan Khoronzhuk wrote:

> The UBI volume name has to be prefixed with "ubi:".
> 
> Signed-off-by: Ivan Khoronzhuk 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [U-boot] [Patch 2/2] keystone2: config: align names of images with MCSDK

[Tom Rini]

On Tue, Nov 04, 2014 at 04:52:35PM +0200, Ivan Khoronzhuk wrote:

> The Multicore Software Development Kit (MCSDK) provides foundational
> software for TI KeyStone II device platforms. It's supposed to be used
> with uboot, and it's convenient to have the same names for images, so
> correct environment image names according to the last MCSDK3.
> 
> Signed-off-by: Ivan Khoronzhuk 

Reviewed-by: Tom Rini 

-- 
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] [RFC] Removal of CREDITS

[Tom Rini]

On Tue, Nov 04, 2014 at 10:17:07AM -0500, Tom Rini wrote:
> On Thu, Oct 30, 2014 at 06:58:16AM +0100, Wolfgang Denk wrote:
> > Dear Masahiro,
> > 
> > In message <20141030125733.259b.aa925...@jp.panasonic.com> you wrote:
> > > 
> > > The "CREDITS" file at the top directory does not seem
> > > to be used these days.
> > 
> > Agreed.  Actually it has never been systematically maintained.
> > 
> > > I think we do not need the CREDITS file any more.
> > 
> > That's OK with me.
> 
> Done (when buildman finishes up testing these other PRs it's building
> right now).

... I see this got done with a patch and I just skimmed over the PR,
nevermind.

-- 
Tom


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

Re: [U-Boot] [U-boot] [Patch v2] ks2_evm: config: enable fatload command

[Tom Rini]

On Tue, Nov 04, 2014 at 06:06:27PM +0200, Ivan Khoronzhuk wrote:

> The keystone2 evm can boot from USB partition with FAT32 FS, so
> enable generic load command and fatload command usage.
> 
> Acked-by: Murali Karicheri 
> Signed-off-by: Ivan Khoronzhuk 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [U-boot] [Patch 1/2] keystone2: config: restructure handling of default env settings

[Tom Rini]

On Tue, Nov 04, 2014 at 04:52:34PM +0200, Ivan Khoronzhuk wrote:

> From: Murali Karicheri 
> 
> Currently to customize env for various ks2 boards, individual
> variables such as NAME_FS etc are defined and included in the
> common config.h to define CONFIG_EXTRA_ENV_SETTINGS. This
> doesn't scale well if a variable is not applicable on a
> specific board. Using this scheme, we have to define variables
> with empty value and it's ugly. Instead, to allow board specific
> customization of default env variable, define a common
> CONFIG_EXTRA_ENV_KS2_SETTINGS for all common variables and define
> board specific variables in individual board specific config.h
> using CONFIG_EXTRA_ENV_KS2_BOARD_SETTINGS. Use the common and board
> specific variables to define CONFIG_EXTRA_ENV_SETTINGS. This way
> more variables can be added in future for individual boards
> without affecting the other config.h files.
> 
> Signed-off-by: Murali Karicheri 
> Signed-off-by: Ivan Khoronzhuk 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [U-boot] [Patch] keystone2: replace printf on puts where it's possible

[Tom Rini]

On Tue, Nov 04, 2014 at 01:44:53AM +0200, Ivan Khoronzhuk wrote:

> It is better to use simple puts() function instead of printf()
> when it's possible. Also remove redundant sprintf().
> 
> Signed-off-by: Ivan Khoronzhuk 

One of the outcomes of the mini-summit and I think was summarized on the
list as well was that we're going to stop with the "use puts instead of
printf!" thing as it ends up being more annoying to contributors than
useful in terms of functionality and code size.

> diff --git a/board/ti/ks2_evm/board.c b/board/ti/ks2_evm/board.c
> index 4029493..ff7bc4b 100644
> --- a/board/ti/ks2_evm/board.c
> +++ b/board/ti/ks2_evm/board.c
> @@ -122,7 +122,6 @@ void ft_board_setup(void *blob, bd_t *bd)
>   int nbanks;
>   u64 size[2];
>   u64 start[2];
> - char name[32];
>   int nodeoffset;
>   u32 ddr3a_size;
>   int unitrd_fixup = 0;
> @@ -158,15 +157,13 @@ void ft_board_setup(void *blob, bd_t *bd)
>   }
>  
>   /* reserve memory at start of bank */
> - sprintf(name, "mem_reserve_head");
> - env = getenv(name);
> + env = getenv("mem_reserve_head");
>   if (env) {
>   start[0] += ustrtoul(env, &endp, 0);
>   size[0] -= ustrtoul(env, &endp, 0);
>   }
>  
> - sprintf(name, "mem_reserve");
> - env = getenv(name);
> + env = getenv("mem_reserve");
>   if (env)
>   size[0] -= ustrtoul(env, &endp, 0);

This is good to fix however.

-- 
Tom


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

Re: [U-Boot] [U-boot] [Patch] keystone2: replace printf on puts where it's possible

[Ivan Khoronzhuk]

On 11/04/2014 06:46 PM, Tom Rini wrote:

On Tue, Nov 04, 2014 at 01:44:53AM +0200, Ivan Khoronzhuk wrote:


It is better to use simple puts() function instead of printf()
when it's possible. Also remove redundant sprintf().

Signed-off-by: Ivan Khoronzhuk 

One of the outcomes of the mini-summit and I think was summarized on the
list as well was that we're going to stop with the "use puts instead of
printf!" thing as it ends up being more annoying to contributors than
useful in terms of functionality and code size.


diff --git a/board/ti/ks2_evm/board.c b/board/ti/ks2_evm/board.c
index 4029493..ff7bc4b 100644
--- a/board/ti/ks2_evm/board.c
+++ b/board/ti/ks2_evm/board.c
@@ -122,7 +122,6 @@ void ft_board_setup(void *blob, bd_t *bd)
int nbanks;
u64 size[2];
u64 start[2];
-   char name[32];
int nodeoffset;
u32 ddr3a_size;
int unitrd_fixup = 0;
@@ -158,15 +157,13 @@ void ft_board_setup(void *blob, bd_t *bd)
}
  
  	/* reserve memory at start of bank */

-   sprintf(name, "mem_reserve_head");
-   env = getenv(name);
+   env = getenv("mem_reserve_head");
if (env) {
start[0] += ustrtoul(env, &endp, 0);
size[0] -= ustrtoul(env, &endp, 0);
}
  
-	sprintf(name, "mem_reserve");

-   env = getenv(name);
+   env = getenv("mem_reserve");
if (env)
size[0] -= ustrtoul(env, &endp, 0);

This is good to fix however.



Ok,
Reject this patch.
I will send new patch that delete only sprintf.
Thanks!

--
Regards,
Ivan Khoronzhuk

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

Re: [U-Boot] [PATCH] dfu: thor: fix: Modify dfu_get_alt() function to support absolute paths

[Marek Vasut]

On Tuesday, November 04, 2014 at 05:25:43 PM, Lukasz Majewski wrote:
> Recently the ext4 file system imposed passing absolute path with its file
> name parameter.
> As a result dfu_alt_info env variable has been modified to provide absolute
> path when ext4 file system is accessed (e.g. /uImage ext4 0 2;).
> 
> Unfortunately, lthor flashing program provides plain file name (like
> uImage) and hence those two file names do not match anymore.
> 
> Presented commit also allows lthor to write files to sub directories (like
> /boot/bin/uImage).
> 
> Signed-off-by: Lukasz Majewski 
> ---
>  drivers/dfu/dfu.c | 29 +++--
>  1 file changed, 27 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/dfu/dfu.c b/drivers/dfu/dfu.c
> index 55e6a83..1e9ccdc 100644
> --- a/drivers/dfu/dfu.c
> +++ b/drivers/dfu/dfu.c
> @@ -544,10 +544,35 @@ struct dfu_entity *dfu_get_entity(int alt)
>  int dfu_get_alt(char *name)
>  {
>   struct dfu_entity *dfu;
> + char *str;
> 
>   list_for_each_entry(dfu, &dfu_list, list) {
> - if (!strncmp(dfu->name, name, strlen(dfu->name)))
> - return dfu->alt;
> + if (dfu->name[0] != '/') {
> + if (!strncmp(dfu->name, name, strlen(dfu->name)))
> + return dfu->alt;
> + } else {
> + /*
> +  * One must also consider absolute path
> +  * (/boot/bin/uImage) available at dfu->name when
> +  * compared "plain" file name (uImage)
> +  *
> +  * It is the case for e.g. thor gadget where lthor SW
> +  * sends only the file name, so only the very last part
> +  * of patch must be checked for equality

I think this patch needs patching using s/patch/path/ ;-)

Otherwise I don't see much issues.

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] power: LP8720 regulator support

[Przemyslaw Marczak]

Hello,

On 11/04/2014 04:58 PM, Tom Rini wrote:

On Sat, Nov 01, 2014 at 12:01:37PM +0100, Paul Kocialkowski wrote:

Le mardi 28 octobre 2014 à 18:32 +0100, Paul Kocialkowski a écrit :

This adds support for the LP8720 i2c regulator, as found in e.g. the LG
Optimus Black (P970), codename sniper. This code supports setting up and
enabling one of the 5 LDOs that the IC provides.
Other more advanced features are unsupported.

Signed-off-by: Paul Kocialkowski 
---
  drivers/power/Makefile |1 +
  drivers/power/lp8720.c |  107 
  include/lp8720.h   |   93 +
  3 files changed, 201 insertions(+)
  create mode 100644 drivers/power/lp8720.c
  create mode 100644 include/lp8720.h

diff --git a/drivers/power/Makefile b/drivers/power/Makefile
index dc64e4d..65be5a0 100644
--- a/drivers/power/Makefile
+++ b/drivers/power/Makefile
@@ -9,6 +9,7 @@ obj-$(CONFIG_AXP152_POWER)  += axp152.o
  obj-$(CONFIG_AXP209_POWER)+= axp209.o
  obj-$(CONFIG_EXYNOS_TMU)  += exynos-tmu.o
  obj-$(CONFIG_FTPMU010_POWER)  += ftpmu010.o
+obj-$(CONFIG_LP8720_POWER) += lp8720.o
  obj-$(CONFIG_TPS6586X_POWER)  += tps6586x.o
  obj-$(CONFIG_TWL4030_POWER)   += twl4030.o
  obj-$(CONFIG_TWL6030_POWER)   += twl6030.o
diff --git a/drivers/power/lp8720.c b/drivers/power/lp8720.c
new file mode 100644
index 000..ac7fc11
--- /dev/null
+++ b/drivers/power/lp8720.c
@@ -0,0 +1,107 @@
+/*
+ * Copyright (C) 2014 Paul Kocialkowski 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+static struct lp8720_info lp8720_info;
+
+static int lp8720_write(u8 reg, u8 val)
+{
+   return i2c_write(lp8720_info.chip_idsel, reg, 1, &val, 1);
+}
+
+static int lp8720_read(u8 reg, u8 *val)
+{
+   return i2c_read(lp8720_info.chip_idsel, reg, 1, val, 1);
+}


Should I ifdef for I2C and GPIO support? It seems that GPIO support only
has board-sepcific config options, so this may be hard. There is
CONFIG_DM_GPIO for driver model, but it is apparently not always used,
especially not on SPL.


Don't code for what you can't test.  Which way are you using this on the
Optimus?  And in general, any comments here Przemyslaw?  Thanks!



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



Thanks for cc Tom, I have some comments in a next message.

Paul,
there are no patches for the board, which you mentioned about. Usually 
we don't add dead code to U-Boot. If you are going to add new board - 
just add it with all required drivers in a one patchset - then it is 
consistent and easy to review.


Best regards,
--
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] power: LP8720 regulator support

[Przemyslaw Marczak]

Hello Paul,

On 11/01/2014 12:01 PM, Paul Kocialkowski wrote:

Le mardi 28 octobre 2014 à 18:32 +0100, Paul Kocialkowski a écrit :

This adds support for the LP8720 i2c regulator, as found in e.g. the LG
Optimus Black (P970), codename sniper. This code supports setting up and
enabling one of the 5 LDOs that the IC provides.
Other more advanced features are unsupported.

Signed-off-by: Paul Kocialkowski 
---
  drivers/power/Makefile |1 +
  drivers/power/lp8720.c |  107 
  include/lp8720.h   |   93 +
  3 files changed, 201 insertions(+)
  create mode 100644 drivers/power/lp8720.c
  create mode 100644 include/lp8720.h

diff --git a/drivers/power/Makefile b/drivers/power/Makefile
index dc64e4d..65be5a0 100644
--- a/drivers/power/Makefile
+++ b/drivers/power/Makefile
@@ -9,6 +9,7 @@ obj-$(CONFIG_AXP152_POWER)  += axp152.o
  obj-$(CONFIG_AXP209_POWER)+= axp209.o
  obj-$(CONFIG_EXYNOS_TMU)  += exynos-tmu.o
  obj-$(CONFIG_FTPMU010_POWER)  += ftpmu010.o
+obj-$(CONFIG_LP8720_POWER) += lp8720.o
  obj-$(CONFIG_TPS6586X_POWER)  += tps6586x.o
  obj-$(CONFIG_TWL4030_POWER)   += twl4030.o
  obj-$(CONFIG_TWL6030_POWER)   += twl6030.o
diff --git a/drivers/power/lp8720.c b/drivers/power/lp8720.c
new file mode 100644
index 000..ac7fc11
--- /dev/null
+++ b/drivers/power/lp8720.c
@@ -0,0 +1,107 @@
+/*
+ * Copyright (C) 2014 Paul Kocialkowski 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+static struct lp8720_info lp8720_info;
+
+static int lp8720_write(u8 reg, u8 val)
+{
+   return i2c_write(lp8720_info.chip_idsel, reg, 1, &val, 1);
+}
+
+static int lp8720_read(u8 reg, u8 *val)
+{
+   return i2c_read(lp8720_info.chip_idsel, reg, 1, val, 1);
+}


At present we have API for the PMIC drivers.
It's located here: drivers/power/
and for i2c operations, you can use this: drivers/power/power_i2c.c
Please look at some pmic drivers, some simple is: 
drivers/power/pmic/pmic_pfuze100.c and some more complicated with 
device-tree:  drivers/power/pmic/pmic_max77686.c


We have also some drivers without the pmic framework support - but we 
are going to keep clean code, rather than introducing api for each driver.




Should I ifdef for I2C and GPIO support? It seems that GPIO support only
has board-sepcific config options, so this may be hard. There is
CONFIG_DM_GPIO for driver model, but it is apparently not always used,
especially not on SPL.


+int lp8720_init(int enable_gpio, int chip_idsel)
+{
+   int ret;
+
+   if (enable_gpio) {


I'm guessing that in the case of a provided negative GPIO, this will
return -1, which is not appropriate behavior (the regulator can still be
used without an enable GPIO). I should probbaly directly go with
gpio_is_valid.


+   if (!gpio_is_valid(enable_gpio))
+   return -1;
+
+   ret = gpio_request(enable_gpio, "lp8720_en");
+   if (ret)
+   return ret;
+
+   ret = gpio_direction_output(enable_gpio, 0);
+   if (ret)
+   return ret;
+   }
+
+   lp8720_info.enable_gpio = enable_gpio;
+   lp8720_info.chip_idsel = chip_idsel;
+
+   return 0;
+}
+
+int lp8720_enable(void)
+{
+   int ret;
+
+   if (lp8720_info.enable_gpio) {
+   ret = gpio_set_value(lp8720_info.enable_gpio, 1);
+   if (ret)
+   return ret;
+   }
+
+   return 0;
+}
+
+int lp8720_is_enabled(void)
+{
+   if (lp8720_info.enable_gpio)
+   return gpio_get_value(lp8720_info.enable_gpio);
+
+   /* Assume LP8720 enabled when there is no enable GPIO */
+   return 1;
+}
+


This function is quite unclean. The argument and the function name 
suggests that you enable one ldo, but you modify all ldo bits.

Please modify this code with getting "ldo" argument as chosen LDO number.

int lp8720_ldo_enable(int ldo)


+int lp8720_ldo_enable(u8 ldo_enable)
+{
+   u8 val;
+   int ret;
+
+   ret = lp8720_read(LP8720_ENABLE_BITS, &val);
+   if (ret)
+   return ret;
+
+   val |= ldo_enable;


what about:

val |= (1 << (ldo - 1)); (for ldo number starting from "1")

Here you should also add LP8720_ENABLE_BITS_MASK


+
+   ret = lp8720_write(LP8720_ENABLE_BITS, val);
+   if (ret)
+   return ret;
+
+   /* Enable the IC */
+   if (!lp8720_is_enabled())
+   lp8720_enable();
+
+   return 0;
+}
+


Please use u32 for register as pmic api uses.
int lp8720_ldo_voltage(u32 ldo_reg, u32 voltage)


+int lp8720_ldo_voltage(u8 ldo_reg, u8 voltage, u8 delay)


Setting the delay is a different operation than setting the voltage, and 
it not fits to the pmic api.


So you should add additional function like:
int lp8720_ldo_startup_delay(u32 ldo_reg, u32 delay)


+{
+   u8 val;
+   int ret;
+
+   /* Regis

Re: [U-Boot] [PATCH v2 1/2] mmc: Board-specific MMC power initializations

[Igor Grinberg]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Tom,

On 11/04/14 17:56, Tom Rini wrote:
> On Sat, Nov 01, 2014 at 11:35:43AM +0100, Paul Kocialkowski wrote:
> 
>> Some devices may use non-standard combinations of regulators to power MMC:
>> this allows these devices to provide a board-specific MMC power init function
>> to set everything up in their own way.
>>
>> Signed-off-by: Paul Kocialkowski 
>> ---
>>  drivers/mmc/mmc.c | 8 
>>  include/mmc.h | 2 ++
>>  2 files changed, 10 insertions(+)
>>
>> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
>> index 44a4feb..125f347 100644
>> --- a/drivers/mmc/mmc.c
>> +++ b/drivers/mmc/mmc.c
>> @@ -1277,6 +1277,12 @@ block_dev_desc_t *mmc_get_dev(int dev)
>>  }
>>  #endif
>>  
>> +/* board-specific MMC power initializations. */
>> +__weak int board_mmc_power_init(void)
>> +{
>> +return -1;
>> +}
> 
> Since we don't check error return here which I think is fine just make
> this a void?  Thanks!

There is v3 posted a while ago...
We have also agreed on v4..


- -- 
Regards,
Igor.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBAgAGBQJUWRPOAAoJEBDE8YO64EfafPsP/iow4r72B6oCuDDh7g9+BWYg
bO17RVU3PM14YgWQpybf/MXPgBSxyW3/4d69xrH5+TqEi9lOsHA/5X7ZW9r+xJh1
/JW1qwPKvqN9NdtGyPJppS0umoQoV77CzeTlLIdZ9emtozGSB/PpevAYK89HmrGl
g5XYzeX/uPPE9MrJ1GdeEk+bGSq3N7rSEAzWIiJ50Ai7A4t1RTYRtNAqMbf4q/Ip
WMO/MPiJk6Ybugk5vd91pJQkPtLIuFFEipUnIC8TSO7U8vWiOXKGgjH+aRvFhaLm
8YfU4Ym2vYZzIvpYbgHO6e2tKH0OhyzE/zZIDIGhOaXwPUsMbJquAvVEKz07XNu/
nOAeiBBhvTeMPehUe7jYaCymhxHJb3ZM29MOfz33a/GBskdMCNBtb/XoaibWbG1k
ZfIMktv0SDObRmd/eUCNvl09YWj8JB7aTzFg20ZoeLoyfW7S1aJ1L0AymaOY20n0
A7MXpEVU1ddPu1rIh9hKm8G86i04aarQJ0kJ4vooCZI+qPLndwH+6Go0Zny3Vbj5
v1SudRROl0KUIoJd/Lt5nmJgCsFsas9xXgJsQNuK3avRrwlPcTykJv1eHbYFlNTq
iFCjDAP7IU1iH0NBuJo7T2qPwPw9UMb3AQmo1JY/rFXopTVt2r0mkulZlAoMfWwy
L2cveucMAOGnEIFxhngN
=acIT
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 1/2] mmc: Board-specific MMC power initializations

[Tom Rini]

On Tue, Nov 04, 2014 at 07:58:38PM +0200, Igor Grinberg wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Hi Tom,
> 
> On 11/04/14 17:56, Tom Rini wrote:
> > On Sat, Nov 01, 2014 at 11:35:43AM +0100, Paul Kocialkowski wrote:
> > 
> >> Some devices may use non-standard combinations of regulators to power MMC:
> >> this allows these devices to provide a board-specific MMC power init 
> >> function
> >> to set everything up in their own way.
> >>
> >> Signed-off-by: Paul Kocialkowski 
> >> ---
> >>  drivers/mmc/mmc.c | 8 
> >>  include/mmc.h | 2 ++
> >>  2 files changed, 10 insertions(+)
> >>
> >> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> >> index 44a4feb..125f347 100644
> >> --- a/drivers/mmc/mmc.c
> >> +++ b/drivers/mmc/mmc.c
> >> @@ -1277,6 +1277,12 @@ block_dev_desc_t *mmc_get_dev(int dev)
> >>  }
> >>  #endif
> >>  
> >> +/* board-specific MMC power initializations. */
> >> +__weak int board_mmc_power_init(void)
> >> +{
> >> +  return -1;
> >> +}
> > 
> > Since we don't check error return here which I think is fine just make
> > this a void?  Thanks!
> 
> There is v3 posted a while ago...
> We have also agreed on v4..

Yeah, oops, didn't delete these after catch-up.  I'm still not sure we
should continue adding more unchecked return values "just because".

-- 
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] fs: make it possible to read the filesystem UUID

[Simon Glass]

Hi Christian,

On 3 November 2014 02:47, Christian Gmeiner  wrote:
> Hi Simon,

[snip]

>>> +
>>> +   if (argc == 4)
>>> +   setenv(argv[3], uuid);
>>> +   else
>>> +   printf("%s\n", uuid);
>>> +
>>> +   return 0;
>>> +}
>>> diff --git a/include/ext4fs.h b/include/ext4fs.h
>>> index 6c419f3..19816de 100644
>>> --- a/include/ext4fs.h
>>> +++ b/include/ext4fs.h
>>> @@ -137,6 +137,7 @@ void ext4fs_reinit_global(void);
>>>  int ext4fs_ls(const char *dirname);
>>>  int ext4fs_exists(const char *filename);
>>>  int ext4fs_size(const char *filename);
>>> +int ext4fs_uuid(char *uuid_str);
>>>  void ext4fs_free_node(struct ext2fs_node *node, struct ext2fs_node 
>>> *currroot);
>>>  int ext4fs_devread(lbaint_t sector, int byte_offset, int byte_len, char 
>>> *buf);
>>>  void ext4fs_set_blk_dev(block_dev_desc_t *rbdd, disk_partition_t *info);
>>> diff --git a/include/fs.h b/include/fs.h
>>> index 06a45f2..41082b3 100644
>>> --- a/include/fs.h
>>> +++ b/include/fs.h
>>> @@ -92,5 +92,7 @@ int file_exists(const char *dev_type, const char 
>>> *dev_part, const char *file,
>>> int fstype);
>>>  int do_save(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[],
>>> int fstype);
>>> +int do_fs_uuid(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[],
>>> +   int fstype);
>>
>> Can you please add a function comment for this?
>
> Yes I will add one  - directly here in the .h file?

Yes I think so - this is where the API is

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

[U-Boot] [U-boot] [Patch] ks2_evm: board: remove sprintf for simple string

[Ivan Khoronzhuk]

There is no reason to sprintf simple string.

Signed-off-by: Ivan Khoronzhuk 
---
 board/ti/ks2_evm/board.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/board/ti/ks2_evm/board.c b/board/ti/ks2_evm/board.c
index 4029493..ff7bc4b 100644
--- a/board/ti/ks2_evm/board.c
+++ b/board/ti/ks2_evm/board.c
@@ -122,7 +122,6 @@ void ft_board_setup(void *blob, bd_t *bd)
int nbanks;
u64 size[2];
u64 start[2];
-   char name[32];
int nodeoffset;
u32 ddr3a_size;
int unitrd_fixup = 0;
@@ -158,15 +157,13 @@ void ft_board_setup(void *blob, bd_t *bd)
}
 
/* reserve memory at start of bank */
-   sprintf(name, "mem_reserve_head");
-   env = getenv(name);
+   env = getenv("mem_reserve_head");
if (env) {
start[0] += ustrtoul(env, &endp, 0);
size[0] -= ustrtoul(env, &endp, 0);
}
 
-   sprintf(name, "mem_reserve");
-   env = getenv(name);
+   env = getenv("mem_reserve");
if (env)
size[0] -= ustrtoul(env, &endp, 0);
 
-- 
1.9.1

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

Re: [U-Boot] [PATCH v6 2/6] fs: interface changes to accomodate files greater than 2GB

[Pavel Machek]

On Mon 2014-11-03 18:49:58, Suriyan Ramasami wrote:
> Change the interface for the generic FS functions to take in an extra
> parameter of type "loff_t *" to return the size. The return values of
> these funtions now serve as an indicator of error conditions alone.
> 
> Signed-off-by: Suriyan Ramasami 
> ---
> 
> Changes in v6:
> * Simon - Split this into a separate patch
> 
> Changes in v5:
> * Simon - update fs.h with comments for fs_read/fs_write/fs_size
> 
>  common/cmd_fs.c | 17 +
>  fs/fs.c | 77 
> ++---
>  include/fs.h| 41 ++
>  3 files changed, 88 insertions(+), 47 deletions(-)
> 
> diff --git a/common/cmd_fs.c b/common/cmd_fs.c
> index 6754340..f70cb8a 100644
> --- a/common/cmd_fs.c
> +++ b/common/cmd_fs.c
> @@ -51,6 +51,23 @@ U_BOOT_CMD(
>   "  If 'pos' is 0 or omitted, the file is read from the start."
>  )
>  
> +static int do_save_wrapper(cmd_tbl_t *cmdtp, int flag, int argc,
> + char * const argv[])
> +{
> + return do_save(cmdtp, flag, argc, argv, FS_TYPE_ANY);
> +}
> +
> +U_BOOT_CMD(
> + save,   7,  0,  do_save_wrapper,
> + "save file to a filesystem",
> + " [ [ [ [bytes [pos]\n"

That's not correct, AFAICT.

int do_save(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[],
int fstype)
{
unsigned long addr;
const char *filename;
unsigned long bytes;
unsigned long pos;
int len;
unsigned long time;

if (argc < 6 || argc > 7)
return CMD_RET_USAGE;

More arguments are mandatory then you describe here.

> + "- Save binary file 'filename' to partition 'part' on device\n"
> + "  type 'interface' instance 'dev' from addr 'addr' in memory.\n"
> + "  'bytes' gives the size to save in bytes and is mandatory.\n"
> + "  'pos' gives the file byte position to start writing to.\n"
> + "  If 'pos' is 0 or omitted, the file is written from the start."

Plus maybe note if it can extend existing files and create files if
they don't exit would be nice here?

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot