Re: [U-Boot] [PATCH 1/1 v3] console: USB: KBD: Fix incorrect autoboot timeout

[Jim Lin]

Thanks for pointing out the potential issue.

-Original Message-
From: Jon Hunter [mailto:jon-hun...@ti.com] 
Sent: Thursday, March 21, 2013 7:57 AM
To: Jim Lin
Cc: u-boot@lists.denx.de; ma...@denx.de; w...@denx.de; tr...@ti.com; Tom Warren
Subject: Re: [U-Boot] [PATCH 1/1 v3] console: USB: KBD: Fix incorrect autoboot 
timeout


On 01/24/2013 05:05 AM, Jim Lin wrote:
 Autoboot timeout defined by CONFIG_BOOTDELAY will not be accurate if 
 CONFIG_USB_KEYBOARD and CONFIG_SYS_USB_EVENT_POLL are defined in 
 configuration file and when tstc() function for checking key pressed 
 takes longer time than 10 ms (e.g., 50 ms) to finish.
 
 Signed-off-by: Jim Lin ji...@nvidia.com
 ---
 Changes in v2:
- use do-while and get_timer to count timeout.
 Changes in v3:
- revert original udelay(1); for safety.
 
  common/main.c |   10 +-
  1 files changed, 5 insertions(+), 5 deletions(-)
 
 diff --git a/common/main.c b/common/main.c index b145f85..dcd2a42 
 100644
 --- a/common/main.c
 +++ b/common/main.c
 @@ -225,6 +225,7 @@ static inline
  int abortboot(int bootdelay)
  {
   int abort = 0;
 + unsigned long ts;
  
  #ifdef CONFIG_MENUPROMPT
   printf(CONFIG_MENUPROMPT);
 @@ -248,11 +249,10 @@ int abortboot(int bootdelay)  #endif
  
   while ((bootdelay  0)  (!abort)) {
 - int i;
 -
   --bootdelay;
 - /* delay 100 * 10ms */
 - for (i=0; !abort  i100; ++i) {
 + /* delay 1000 ms */
 + ts = get_timer(0);
 + do {
   if (tstc()) {   /* we got a key press   */
   abort  = 1; /* don't auto boot  */
   bootdelay = 0;  /* no more delay*/
 @@ -264,7 +264,7 @@ int abortboot(int bootdelay)
   break;
   }
   udelay(1);
 - }
 + } while (!abort  get_timer(ts)  1000);
  
   printf(\b\b\b%2d , bootdelay);
   }

This change is causing problems with auto-delay on one of my boards by making 
it inaccurate :-(

The question is what should get_timer() be returning? If it is meant to be 
milliseconds then I guess I need to fix get_timer() for my board.
However, if it is just meant to be timer ticks at the SYS_HZ rate then I don't 
see how the above change guarantees the do-while loop waits 1000 ms per 
iteration without normalising to SYS_HZ.

For my board I made the following change to make it work ...

diff --git a/common/main.c b/common/main.c index a15f020..32c4f8a 100644
--- a/common/main.c
+++ b/common/main.c
@@ -264,7 +264,7 @@ int abortboot(int bootdelay)
break;
}
udelay(1);
-   } while (!abort  get_timer(ts)  1000);
+   } while (!abort  !(get_timer(ts) / CONFIG_SYS_HZ));

printf(\b\b\b%2d , bootdelay);

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

Re: [U-Boot] [PATCH 1/1 v3] console: USB: KBD: Fix incorrect autoboot timeout

[Stephen Warren]

On 03/20/2013 05:56 PM, Jon Hunter wrote:
 
 On 01/24/2013 05:05 AM, Jim Lin wrote:
 Autoboot timeout defined by CONFIG_BOOTDELAY will not be accurate if
 CONFIG_USB_KEYBOARD and CONFIG_SYS_USB_EVENT_POLL are defined in
 configuration file and when tstc() function for checking key pressed
 takes longer time than 10 ms (e.g., 50 ms) to finish.
...
 This change is causing problems with auto-delay on one of my boards by
 making it inaccurate :-(

Interesting. I just noticed the same problem, and posted the following
patch to fix it:

http://lists.denx.de/pipermail/u-boot/2013-March/149625.html

This was on the Raspberry Pi.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 0/4 v8] Add ACE HW support for SHA256 and SHA1

[Akshay Saraswat]

This patch set adds hardware acceleration for SHA 256
with the help of ACE.

Changes since v1:
- Patch-1: Fixed few nits.
- Patch-2: Removed not required config.
- Patch-3: Added sha256 to hash command instead of new sha256 command.

Changes since v2:
- Patch-1: 
- Added falling back to software sha256 in case length exceeds 
buffer limit.
- Reduced one tab at lines 533, 559 and 571 in the patch.
- Removed space after a cast at line 506 in the patch.
- Removed blank line at line 561 in the patch.
- Removed space before semicolon at line 576 in the patch.
- Patch-2: 
- Added SHA1 in the comment for config.
- Patch-3: 
- Added new nodes for SHA1 and SHA256 in struct hash_algo for 
the case when
  ACE is enabled.
- Added new declaration for function pointer hash_func_ws with 
different
  return type.
- Patch-4: 
- New patch to enable config for hash command.

Changes since v3:
- Patch-1:
- Removed buffer limit since there are 2 regs for address 
hash_msg_size_high
  and low.
  That means buffer length could go upto 2^64 bits which is 
practically 
- Removed falling back to software sha256 because there is no 
buffer limit.
- Removed / 4 to sha1 and sha256 lengths and added increment 
to 4 in for
  loop at line 573.
- Timed out still kept to be 100 ms since this is enough for 
hardware to
  switch status to idle from busy.
  In case it couldn't that means h/w is faulty.
- Patch-2:
- Added Acked-by: Simon Glass s...@chromium.org.
- Patch-3:
- New patch.
- Patch-4:
- Changed command names to lower case in algo struct.
- Added generic ace_sha config.
- Patch-5: Added acked-by Simon Glass
- Added new generic config for ace_sha to enable ace support in 
hash.c.

Changes since v4:
- Patch-1:
- Added include for clk.h.
- Added define for MAX_FREQ.
- Added timeout calculation as per frequency.
- Changed i+=4 to i++ and len to len/4 in for loop at 
line 591
  in this patch.
- Added two new functions ace_sha256 and ace_sha1.
- Patch-2: None.
- Patch-3:
- Changed function names in struct algo.
- Replaced ACE_SHA_TYPE to CHUNSZ in struct algo.
- Patch-4: Added Acked-by: Simon Glass s...@chromium.org.

Changes since v5:
- Patch-1:
- Removed ace_sha.h.
- Renamed ace_sfr.h as ace_sha.h.
- Removed timeout and checking for PRNG_ERROR bit in 
HASH_STATUS register.
  PRNG_ERROR bit high means setup was not done properly. Since 
there is no
  way to detect faulty h/w, we consider the possible fact that 
h/w should
  not be able to setup feed properly if it's faulty.
- Renamed function name ace_sha256 to hw_sha256 and ace_sha1 to 
hw_sha1.
- Patch-2: None.
- Patch-3:
- Added file hw_sha.h.
- Changed CONFIG_ACE_SHA to CONFIG_SHA_HW_ACCEL.
- Renamed function names ace_sha1 and ace_sha256 to hw_sha1 and 
hw_sha256
  respectively.
- Patch-4:
- Removed Acked-by: Simon Glass s...@chromium.org because 
of a change.
- Changed CONFIG_ACE_SHA to CONFIG_SHA_HW_ACCEL.

Changes since v6:
- Patch-1: Added Acked-by: Simon Glass s...@chromium.org.
- Patch-2: None.
- Patch-3:
- Changed position of hw_sha.h among includes (alpha order).
- Rebased patch.
- Patch-4: Added Acked-by: Simon Glass s...@chromium.org.

Changes since v7:
- Patch-1:
- Moved ace_sha.h to drivers/crypto.
- Removed parantheses where not required in ace_sha.h.
- Removed leftover time limit comment in ace_sha.c.
- Replaced break with return -EBUSY in PRNGERROR check.
- Patch-2: None.
- Patch-3: Added Acked-by: Simon Glass s...@chromium.org.
- Patch-4: None.

Akshay Saraswat (4):
  Exynos: Add hardware accelerated SHA256 and SHA1
  Exynos: config: Enable ACE HW for SHA 256 for Exynos
  gen: Add sha h/w acceleration to hash
  Exynos: config: Enable hash command

 Makefile   |   1 +
 arch/arm/include/asm/arch-exynos/cpu.h |   4 +
 common/hash.c  |  18 ++
 drivers/crypto/Makefile|  47 +
 drivers/crypto/ace_sha.c   | 126 +
 drivers/crypto/ace_sha.h   

[U-Boot] [PATCH 4/4 v8] Exynos: config: Enable hash command

[Akshay Saraswat]

This enables hash command.

Tested with command hash sha256 0x40008000 0x2B 0x40009000.
Used mm and md to write a standard string to memory location
0x40008000 and ran the above command to verify the output.

Signed-off-by: ARUN MANKUZHI aru...@samsung.com
Signed-off-by: Akshay Saraswat aksha...@samsung.com
Acked-by: Simon Glass s...@chromium.org
---
Changes since v2:
- New patch to enable config for hash command.

Changes since v3:
- Added new generic config for ace_sha to enable ace support in hash.c.

Changes since v4:
- Added Acked-by: Simon Glass s...@chromium.org.

Changes since v5:
- Removed Acked-by: Simon Glass s...@chromium.org because of a 
change.
- Changed CONFIG_ACE_SHA to CONFIG_SHA_HW_ACCEL.

Changes since v6:
- Added Acked-by: Simon Glass s...@chromium.org.

Changes since v7:
- None.

 include/configs/exynos5250-dt.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/configs/exynos5250-dt.h b/include/configs/exynos5250-dt.h
index 1fb47a0..9680b9d 100644
--- a/include/configs/exynos5250-dt.h
+++ b/include/configs/exynos5250-dt.h
@@ -48,6 +48,7 @@
 
 /* Enable ACE acceleration for SHA1 and SHA256 */
 #define CONFIG_EXYNOS_ACE_SHA
+#define CONFIG_SHA_HW_ACCEL
 
 #define CONFIG_SYS_SDRAM_BASE  0x4000
 #define CONFIG_SYS_TEXT_BASE   0x43E0
@@ -117,6 +118,7 @@
 #define CONFIG_CMD_EXT2
 #define CONFIG_CMD_FAT
 #define CONFIG_CMD_NET
+#define CONFIG_CMD_HASH
 
 #define CONFIG_BOOTDELAY   3
 #define CONFIG_ZERO_BOOTDELAY_CHECK
-- 
1.8.0

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

[U-Boot] [PATCH 1/4 v8] Exynos: Add hardware accelerated SHA256 and SHA1

[Akshay Saraswat]

SHA-256 and SHA-1 accelerated using ACE hardware.

Signed-off-by: ARUN MANKUZHI aru...@samsung.com
Signed-off-by: Akshay Saraswat aksha...@samsung.com
Acked-by: Simon Glass s...@chromium.org
---
Changes since v1:
- Moved code to drivers/crypto.
- Fixed few other nits.

Changes since v2:
- Added falling back to software sha256 in case length exceeds buffer 
limit.
- Reduced one tab at lines 533, 559 and 571 in this patch.
- Removed space after a cast at line 506 in this patch.
- Removed blank line at line 561 in this patch.
- Removed space before semicolon at line 576 in this patch.

Changes since v3:
- Removed buffer limit since there are 2 regs for address 
hash_msg_size_high and low.
  That means buffer length could go upto 2^64 bits which is practically
- Removed falling back to software sha256 because there is no buffer 
limit.
- Removed / 4 to sha1 and sha256 lengths and added increment to 4 in 
for
  loop at line 573.
- Timed out still kept to be 100 ms since this is enough for hardware 
to switch
  status to idle from busy.
  In case it couldn't that means h/w is faulty.

Changes since v4:
- Added include for clk.h.
- Added define for MAX_FREQ.
- Added timeout calculation as per frequency.
- Changed i+=4 to i++ and len to len/4 in for loop at line 591 
in this patch.
- Added two new functions ace_sha256 and ace_sha1.

Changes since v5:
- Removed ace_sha.h.
- Renamed ace_sfr.h as ace_sha.h.
- Removed timeout and checking for PRNG_ERROR bit in HASH_STATUS 
register.
  PRNG_ERROR bit high means setup was not done properly. Since there is 
no
  way to detect faulty h/w, we consider the possible fact that h/w 
should
  not be able to setup feed properly if it's faulty.
- Renamed function name ace_sha256 to hw_sha256 and ace_sha1 to hw_sha1.

Changes since v6:
- Added Acked-by: Simon Glass s...@chromium.org.

Changes since v7:
- Moved ace_sha.h to drivers/crypto.
- Removed parantheses where not required in ace_sha.h.
- Removed leftover time limit comment in ace_sha.c.
- Replaced break with return -EBUSY in PRNGERROR check.

 Makefile   |   1 +
 arch/arm/include/asm/arch-exynos/cpu.h |   4 +
 drivers/crypto/Makefile|  47 +
 drivers/crypto/ace_sha.c   | 126 +
 drivers/crypto/ace_sha.h   | 325 +
 5 files changed, 503 insertions(+)
 create mode 100644 drivers/crypto/Makefile
 create mode 100644 drivers/crypto/ace_sha.c
 create mode 100644 drivers/crypto/ace_sha.h

diff --git a/Makefile b/Makefile
index 12763ce..2583f7f 100644
--- a/Makefile
+++ b/Makefile
@@ -273,6 +273,7 @@ LIBS-y += disk/libdisk.o
 LIBS-y += drivers/bios_emulator/libatibiosemu.o
 LIBS-y += drivers/block/libblock.o
 LIBS-$(CONFIG_BOOTCOUNT_LIMIT) += drivers/bootcount/libbootcount.o
+LIBS-y += drivers/crypto/libcrypto.o
 LIBS-y += drivers/dma/libdma.o
 LIBS-y += drivers/fpga/libfpga.o
 LIBS-y += drivers/gpio/libgpio.o
diff --git a/arch/arm/include/asm/arch-exynos/cpu.h 
b/arch/arm/include/asm/arch-exynos/cpu.h
index eb34422..2a20558 100644
--- a/arch/arm/include/asm/arch-exynos/cpu.h
+++ b/arch/arm/include/asm/arch-exynos/cpu.h
@@ -62,6 +62,7 @@
 #define EXYNOS4_GPIO_PART4_BASEDEVICE_NOT_AVAILABLE
 #define EXYNOS4_DP_BASEDEVICE_NOT_AVAILABLE
 #define EXYNOS4_SPI_ISP_BASE   DEVICE_NOT_AVAILABLE
+#define EXYNOS4_ACE_SFR_BASE   DEVICE_NOT_AVAILABLE
 
 /* EXYNOS4X12 */
 #define EXYNOS4X12_GPIO_PART3_BASE 0x0386
@@ -95,6 +96,7 @@
 #define EXYNOS4X12_I2S_BASEDEVICE_NOT_AVAILABLE
 #define EXYNOS4X12_SPI_BASEDEVICE_NOT_AVAILABLE
 #define EXYNOS4X12_SPI_ISP_BASEDEVICE_NOT_AVAILABLE
+#define EXYNOS4X12_ACE_SFR_BASEDEVICE_NOT_AVAILABLE
 
 /* EXYNOS5 Common*/
 #define EXYNOS5_I2C_SPACING0x1
@@ -106,6 +108,7 @@
 #define EXYNOS5_SWRESET0x10040400
 #define EXYNOS5_SYSREG_BASE0x1005
 #define EXYNOS5_WATCHDOG_BASE  0x101D
+#define EXYNOS5_ACE_SFR_BASE0x1083
 #define EXYNOS5_DMC_PHY0_BASE  0x10C0
 #define EXYNOS5_DMC_PHY1_BASE  0x10C1
 #define EXYNOS5_GPIO_PART3_BASE0x10D1
@@ -205,6 +208,7 @@ static inline unsigned int samsung_get_base_##device(void)  
\
 
 SAMSUNG_BASE(adc, ADC_BASE)
 SAMSUNG_BASE(clock, CLOCK_BASE)
+SAMSUNG_BASE(ace_sfr, ACE_SFR_BASE)
 SAMSUNG_BASE(dp, DP_BASE)
 SAMSUNG_BASE(sysreg, SYSREG_BASE)
 SAMSUNG_BASE(fimd, FIMD_BASE)
diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile
new file mode 100644
index 000..2c54793
--- /dev/null
+++ b/drivers/crypto/Makefile
@@ -0,0 +1,47 @@
+#
+# Copyright (c) 2013 Samsung 

[U-Boot] [PATCH 3/4 v8] gen: Add sha h/w acceleration to hash

[Akshay Saraswat]

Adding H/W acceleration support to hash which can be used
to test SHA 256 hash algorithm.

Signed-off-by: ARUN MANKUZHI aru...@samsung.com
Signed-off-by: Akshay Saraswat aksha...@samsung.com
Acked-by: Simon Glass s...@chromium.org
---
Changes since v1:
- Added sha256 support to hash command instead of new sha256 command.

Changes sice v2:
- Added new nodes for SHA1 and SHA256 in struct hash_algo for the case 
when ACE is enabled.
- Added new declaration for function pointer hash_func_ws with 
different return type.

Changes sice v3:
- Changed command names to lower case in algo struct.
- Added generic ace_sha config.

Changes sice v4:
- Changed function names in struct algo.
- Replaced ACE_SHA_TYPE to CHUNSZ in struct algo.

Changes sice v5:
- Added file hw_sha.h.
- Changed CONFIG_ACE_SHA to CONFIG_SHA_HW_ACCEL.
- Renamed function names ace_sha1 and ace_sha256 to hw_sha1 and 
hw_sha256 respectively.

Changes sice v6:
- Changed position of hw_sha.h among includes (alpha order).
- Rebased patch.

Changes sice v7:
- Added Acked-by: Simon Glass s...@chromium.org.

 common/hash.c| 18 ++
 include/hw_sha.h | 50 ++
 2 files changed, 68 insertions(+)
 create mode 100644 include/hw_sha.h

diff --git a/common/hash.c b/common/hash.c
index f5badcb..c9ac33e 100644
--- a/common/hash.c
+++ b/common/hash.c
@@ -25,6 +25,7 @@
 
 #include common.h
 #include command.h
+#include hw_sha.h
 #include hash.h
 #include sha1.h
 #include sha256.h
@@ -37,6 +38,23 @@
  */
 static struct hash_algo hash_algo[] = {
/*
+* CONFIG_SHA_HW_ACCEL is defined if hardware acceleration is
+* available.
+*/
+#ifdef CONFIG_SHA_HW_ACCEL
+   {
+   sha1,
+   SHA1_SUM_LEN,
+   hw_sha1,
+   CHUNKSZ_SHA1,
+   }, {
+   sha256,
+   SHA256_SUM_LEN,
+   hw_sha256,
+   CHUNKSZ_SHA256,
+   },
+#endif
+   /*
 * This is CONFIG_CMD_SHA1SUM instead of CONFIG_SHA1 since otherwise
 * it bloats the code for boards which use SHA1 but not the 'hash'
 * or 'sha1sum' commands.
diff --git a/include/hw_sha.h b/include/hw_sha.h
new file mode 100644
index 000..264936c
--- /dev/null
+++ b/include/hw_sha.h
@@ -0,0 +1,50 @@
+/*
+ * Header file for SHA hardware acceleration
+ *
+ * Copyright (c) 2012  Samsung Electronics
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ *
+ */
+#ifndef __HW_SHA_H
+#define __HW_SHA_H
+
+
+/**
+ * Computes hash value of input pbuf using h/w acceleration
+ *
+ * @param in_addr  A pointer to the input buffer
+ * @param bufleni  Byte length of input buffer
+ * @param out_addr A pointer to the output buffer. When complete
+ * 32 bytes are copied to pout[0]...pout[31]. Thus, a user
+ * should allocate at least 32 bytes at pOut in advance.
+ * @param chunk_size   chunk size for sha256
+ */
+void hw_sha256(const uchar * in_addr, uint buflen,
+   uchar * out_addr, uint chunk_size);
+
+/**
+ * Computes hash value of input pbuf using h/w acceleration
+ *
+ * @param in_addr  A pointer to the input buffer
+ * @param bufleni  Byte length of input buffer
+ * @param out_addr A pointer to the output buffer. When complete
+ * 32 bytes are copied to pout[0]...pout[31]. Thus, a user
+ * should allocate at least 32 bytes at pOut in advance.
+ * @param chunk_size   chunk_size for sha1
+ */
+void hw_sha1(const uchar * in_addr, uint buflen,
+   uchar * out_addr, uint chunk_size);
+#endif
-- 
1.8.0

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

[U-Boot] [PATCH 2/4 v8] Exynos: config: Enable ACE HW for SHA 256 for Exynos

[Akshay Saraswat]

This enables SHA 256 for exynos.

Signed-off-by: ARUN MANKUZHI aru...@samsung.com
Signed-off-by: Akshay Saraswat aksha...@samsung.com
Acked-by: Simon Glass s...@chromium.org
---
Changes since v1:
- Removed not required config.

Changes sice v2:
- Added SHA1 in the comment for config.

Changes sice v3:
- Added Acked-by: Simon Glass s...@chromium.org.

Changes sice v4:
- None.

Changes sice v5:
- None.

Changes sice v6:
- None.

Changes since v7:
- None.

 include/configs/exynos5250-dt.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/include/configs/exynos5250-dt.h b/include/configs/exynos5250-dt.h
index 1c624d4..1fb47a0 100644
--- a/include/configs/exynos5250-dt.h
+++ b/include/configs/exynos5250-dt.h
@@ -46,6 +46,9 @@
 /* Keep L2 Cache Disabled */
 #define CONFIG_SYS_DCACHE_OFF
 
+/* Enable ACE acceleration for SHA1 and SHA256 */
+#define CONFIG_EXYNOS_ACE_SHA
+
 #define CONFIG_SYS_SDRAM_BASE  0x4000
 #define CONFIG_SYS_TEXT_BASE   0x43E0
 
-- 
1.8.0

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

Re: [U-Boot] [PATCH 1/4 v7] Exynos: Add hardware accelerated SHA256 and SHA1

[Akshay Saraswat]

Hi Kim,

On Mon, 18 Mar 2013 02:06:15 -0400
Akshay Saraswat aksha...@samsung.com wrote:

 SHA-256 and SHA-1 accelerated using ACE hardware.
 
 Signed-off-by: ARUN MANKUZHI aru...@samsung.com
 Signed-off-by: Akshay Saraswat aksha...@samsung.com
 Acked-by: Simon Glass s...@chromium.org
 ---
 +++ b/arch/arm/include/asm/arch-exynos/ace_sha.h

ace_sha.h belongs in drivers/crypto/

 +#define ACE_FC_SELBC_AES(0  2)/* AES */
 +#define ACE_FC_SELBC_DES(1  2)/* DES */

nit: comments seem a bit redundant

Few comments look same but they differ.

For example:
Feed control - BTDMA control and Feed control - BRDMA control


 +#define ACE_FC_BRDMACARPROT_OFS (2)
 +#define ACE_FC_BRDMACARCACHE_OFS(5)
 +#define ACE_FC_BTDMACAWPROT_OFS (2)
 +#define ACE_FC_BTDMACAWCACHE_OFS(5)
 +#define ACE_FC_HRDMACARPROT_OFS (2)
 +#define ACE_FC_HRDMACARCACHE_OFS(5)
 +#define ACE_FC_SRAMOFFSET_MASK  (0xfff)

no parens.

 +/**
 + * Computes hash value of input pbuf using ACE
 + *
 + * @param in_addr   A pointer to the input buffer
 + * @param bufleni   Byte length of input buffer
 + * @param out_addr  A pointer to the output buffer. When complete
 + *  32 bytes are copied to pout[0]...pout[31]. Thus, a user
 + *  should allocate at least 32 bytes at pOut in advance.
 + * @param hash_type SHA1 or SHA256
 + *
 + * @return  0 on Success, -1 on Failure (Timeout)
...
 +/* Check if status changes within given time limit */

leftovers from timeout implementation?

 +while ((readl(ace_sha_reg-hash_status)  ACE_HASH_MSGDONE_MASK) ==
 +ACE_HASH_MSGDONE_OFF) {
 +/*
 + * PRNG error bit goes HIGH if a PRNG request occurs without
 + * a complete seed setup. We are using this bit to check h/w
 + * because proper setup is not expected in that case.
 + */
 +if ((readl(ace_sha_reg-hash_status)
 + ACE_HASH_PRNGERROR_MASK) == ACE_HASH_PRNGERROR_ON)
 +break;
 +}

so we have:

whilst (not_done)
   if (PRNGERROR_ON)
   break;

...and then success-assuming code flow continues after this.  What
value is this check for PRNGERROR_ON, if the code isn't going to do
anything differently?  And what does the status of the RNG have to
do with keyless hashing?  It sounds like a check for proper
initialization (RNG got seeded) is in order here, but only if it's
required for the given hash operations (I doubt it, but the h/w
might be fussy).

Kim


PRNG ERROR means setup was not proper which should be the case
when h/w is faulty because driver does everything in order.
Earlier break was happening which was not correct so changing it to
return -EBUSY which means code flow should not be the same as
the one being successfull.


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

[U-Boot] [PATCH] ARM: OMAP5: Set fdt_high to enable booting with Device tree

[Sricharan R]

While booting with dtblob, if fdt_high is not set to
0x, the dt blob is relocated to a higher address,
which the kernel is not able to use without HIGHMEM.

So set it to 0x to avoid the issue.

Signed-off-by: Sricharan R r.sricha...@ti.com
---
 include/configs/omap5_common.h |1 +
 1 file changed, 1 insertion(+)

diff --git a/include/configs/omap5_common.h b/include/configs/omap5_common.h
index af97564..f0416df 100644
--- a/include/configs/omap5_common.h
+++ b/include/configs/omap5_common.h
@@ -143,6 +143,7 @@
 #define CONFIG_EXTRA_ENV_SETTINGS \
loadaddr=0x8200\0 \
console=ttyO2,115200n8\0 \
+   fdt_high=0x\0 \
usbtty=cdc_acm\0 \
vram=16M\0 \
mmcdev=0\0 \
-- 
1.7.9.5

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

Re: [U-Boot] [PATCH] Fix bootdelay timeout calculation when SYS_HZ!=1000

[Wolfgang Denk]

Dear Stephen Warren,

In message 1363842874-8286-1-git-send-email-swar...@wwwdotorg.org you wrote:
 Commit b2f3e0e console: USB: KBD: Fix incorrect autoboot timeout
 re-wrote the bootdelay timeout loop. However, it hard-coded the value
 that get_delay() was expected to increment in one second, rather than
 calculating it based on CONFIG_SYS_HZ. On systems where SYS_HZ != 1000,
 this caused bootdelay timeout to be incorrect. Fix this.

Are there any such systems left?  I agree with your patch, but if you
know of systems that use incorrect values of CONFIG_SYS_HZ then please
point these out so they can be fixed!

A system with CONFIG_SYS_HZ != 1000 is _broken_.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
It is dangerous to be right on a subject  on  which  the  established
authorities are wrong.-- Voltaire
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/1 v3] console: USB: KBD: Fix incorrect autoboot timeout

[Wolfgang Denk]

Dear Stephen Warren,

In message 514aa642.3090...@wwwdotorg.org you wrote:

 Interesting. I just noticed the same problem, and posted the following
 patch to fix it:
 
 http://lists.denx.de/pipermail/u-boot/2013-March/149625.html
 
 This was on the Raspberry Pi.

You mean the Raspberry Pi uses SYS_HZ != 1000 ???

This needs fixing!!

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
There are two ways of constructing a software design. One way  is  to
make  it  so  simple that there are obviously no deficiencies and the
other is to make it so complicated that there are  no  obvious  defi-
ciencies. - Charles Anthony Richard Hoare
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] spi: mxc_spi: Fix ECSPI reset handling

[Dirk Behme]

Reviewing the ECSPI reset handling shows two issues:

1. For the enable/reset bit (MXC_CSPICTRL_EN) in the control reg
   (ECSPIx_CONGREG) the i.MX6 technical reference manual states:

   -- cut --
   ECSPIx_CONREG[0]: EN: Writing zero to this bit disables the block
   and resets the internal logic with the exception of the ECSPI_CONREG.
   -- cut --

   Note the exception mentioned: The CONREG itself isn't reset.

   Fix this by manually writing the reset value 0 to the whole register.
   This sets the EN bit to zero, too (i.e. includes the old
   ~MXC_CSPICTRL_EN).

2. We want to reset the whole SPI block here. So it makes no sense
   to first read the old value of the CONREG and write it back, later.
   This will give us the old (historic/random) value of the CONREG back.
   And doesn't reset the CONREG.

   To get a clean CONREG after the reset of the block, too, don't use
   the old (historic/random) value of the CONREG while doing the reset.
   And read the clean CONREG after the reset.

This was found while working on a SPI boot device where the i.MX6 boot
ROM has already initialized the SPI block. The initialization by the
boot ROM might be different to what the U-Boot driver wants to configure.
I.e. we need a clean reset of SPI block, including the CONREG.

Signed-off-by: Dirk Behme dirk.be...@de.bosch.com
CC: Stefano Babic sba...@denx.de
CC: Fabio Estevam fabio.este...@freescale.com
---
 drivers/spi/mxc_spi.c |8 
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/spi/mxc_spi.c b/drivers/spi/mxc_spi.c
index d792d8d..cb48019 100644
--- a/drivers/spi/mxc_spi.c
+++ b/drivers/spi/mxc_spi.c
@@ -137,11 +137,11 @@ static s32 spi_cfg_mxc(struct mxc_spi_slave *mxcs, 
unsigned int cs,
return -1;
}
 
-   reg_ctrl = reg_read(regs-ctrl);
-
/* Reset spi */
-   reg_write(regs-ctrl, (reg_ctrl  ~MXC_CSPICTRL_EN));
-   reg_write(regs-ctrl, (reg_ctrl | MXC_CSPICTRL_EN));
+   reg_write(regs-ctrl, 0);
+   reg_write(regs-ctrl, MXC_CSPICTRL_EN);
+
+   reg_ctrl = reg_read(regs-ctrl);
 
/*
 * The following computation is taken directly from Freescale's code.
-- 
1.7.0.4

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

[U-Boot] [PATCH] mmc: mx6qsabrelite: fsl_esdhc: Define maximum bus width supported by SabreLite board

[Abbas Raza]

From: Abbas Raza abbas_r...@mentor.com

Maximum bus width supported by SabreLite board is not 8bit like
all other mx6q specific boards. In case where both host controller
and card support 8bit transfers, they agree to communicate on 8bit
interface while boards like the SabreLite support only 4bit interface.
Due to this reason the mmc 8bit default mode fails on the SabreLite.
To rectify this, define maximum bus width supported by this board (4bit).
If max_bus_width is not defined, it is 0 by default and 8bit width support
will be enabled in host capabilities otherwise host capabilities are modified
accordingly.

It is tested with a MMCplus card.

Signed-off-by: Abbas Raza abbas_r...@mentor.com
cc: stefano Babic sba...@denx.de
cc: Andy Fleming aflem...@gmail.com
Acked-by: Dirk Behme dirk.be...@de.bosch.com
Acked-by: Andrew Gabbasov andrew_gabba...@mentor.com
---
 board/freescale/mx6qsabrelite/mx6qsabrelite.c | 3 +++
 drivers/mmc/fsl_esdhc.c   | 7 +++
 include/fsl_esdhc.h   | 1 +
 3 files changed, 11 insertions(+)

diff --git a/board/freescale/mx6qsabrelite/mx6qsabrelite.c 
b/board/freescale/mx6qsabrelite/mx6qsabrelite.c
index d563464..14c299b 100644
--- a/board/freescale/mx6qsabrelite/mx6qsabrelite.c
+++ b/board/freescale/mx6qsabrelite/mx6qsabrelite.c
@@ -110,6 +110,9 @@ int board_mmc_init(bd_t *bis)
usdhc_cfg[0].sdhc_clk = mxc_get_clock(MXC_ESDHC3_CLK);
usdhc_cfg[1].sdhc_clk = mxc_get_clock(MXC_ESDHC4_CLK);
 
+   usdhc_cfg[0].max_bus_width = 4;
+   usdhc_cfg[1].max_bus_width = 4;
+
for (index = 0; index  CONFIG_SYS_FSL_USDHC_NUM; ++index)
status |= fsl_esdhc_initialize(bis, usdhc_cfg[index]);
 
diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
index 3d5c9c0..d2a505e 100644
--- a/drivers/mmc/fsl_esdhc.c
+++ b/drivers/mmc/fsl_esdhc.c
@@ -579,6 +579,13 @@ int fsl_esdhc_initialize(bd_t *bis, struct fsl_esdhc_cfg 
*cfg)
 
mmc-host_caps = MMC_MODE_4BIT | MMC_MODE_8BIT | MMC_MODE_HC;
 
+   if (cfg-max_bus_width  0) {
+   if (cfg-max_bus_width  8)
+   mmc-host_caps = ~MMC_MODE_8BIT;
+   if (cfg-max_bus_width  4)
+   mmc-host_caps = ~MMC_MODE_4BIT;
+   }
+
if (caps  ESDHC_HOSTCAPBLT_HSS)
mmc-host_caps |= MMC_MODE_HS_52MHz | MMC_MODE_HS;
 
diff --git a/include/fsl_esdhc.h b/include/fsl_esdhc.h
index 47d2fe4..0a1a071 100644
--- a/include/fsl_esdhc.h
+++ b/include/fsl_esdhc.h
@@ -168,6 +168,7 @@
 struct fsl_esdhc_cfg {
u32 esdhc_base;
u32 sdhc_clk;
+   u8  max_bus_width;
 };
 
 /* Select the correct accessors depending on endianess */
-- 
1.8.2

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

Re: [U-Boot] [PATCH v2 1/2] omap_hsmmc: Check wp and cd GPIO for valid GPIO first

[Nikita Kiryanov]

Hi Tom,
a few style comments:

On 03/20/2013 08:46 PM, Tom Rini wrote:

When we cannot check write protect or card change via GPIO (and have
been passed -1 in omap_mmc_init), only even try the gpio_is_valid is
true.


That last part needs rephrasing: only try if gpio_is_valid() is true.


This prevents invalid GPIO messages from being seen on the
console when doing MMC operations

Signed-off-by: Tom Rini tr...@ti.com



[...]


+if (gpio_is_valid(cd_gpio))
+return gpio_get_value(cd_gpio);
+else
+return -1;


Also, the else word is not necessary (in both checks).

Aside from that,
Acked-by: Nikita Kiryanov nik...@compulab.co.il

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

[U-Boot] Micron MT29F8G Internal 4 BIT ECC

[Plenty, Richard]

Hi,
I was wondering if anyone has had experience of enabling the internal 4 BIT ECC 
used on the Micron MT29F8G08ADADAH4-IT and the Freescale QorIQ.
I'm particularly keen to see the modifications you may have done to the Special 
programme loader (nand_boot_fsl_elbc.c) so that the FCM error correction is 
replaced by the internal ECC of the Micron device once the initial stage 0 
loader has completed.

Thanks in advance.



*** Confidentiality Notice: This e-mail, including any associated or attached 
files, is intended solely for the individual or entity to which it is 
addressed. This e-mail is confidential and may well also be legally privileged. 
If you have received it in error, you are on notice of its status. Please 
notify the sender immediately by reply e-mail and then delete this message from 
your system. Please do not copy it or use it for any purposes, or disclose its 
contents to any other person. This email comes from a division of the Invensys 
Group, owned by Invensys plc, which is a company registered in England and 
Wales with its registered office at 3rd Floor, 40 Grosvenor Place, London, SW1X 
7AW (Registered number 166023). For a list of European legal entities within 
the Invensys Group, please select the Legal Entities link at invensys.com.


You may contact Invensys plc on +44 (0)20 3155 1200 or e-mail 
recept...@invensys.com. This e-mail and any attachments thereto may be subject 
to the terms of any agreements between Invensys (and/or its subsidiaries and 
affiliates) and the recipient (and/or its subsidiaries and affiliates).

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

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

[Minkyu Kang]

Dear Albert,

The following changes since commit 9f024f62e4604274a23213dcee30016092e32e7b:

  Merge branch 'fixes' of git://git.denx.de/u-boot-mips (2013-02-15 12:23:42 
-0500)

are available in the git repository at:


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

for you to fetch changes up to ce0c1bc13556fbf1bdfa2a4a27ca6744e7beb32a:

  mmc:sdhci:fix: Change default interrupts enabled at SDHCI initialization 
(2013-03-12 19:50:49 +0900)


Akshay Saraswat (8):
  Exynos5: TMU: Add driver for Thermal Management Unit
  Exynos5: FDT: Add TMU device node values
  Exynos5: TMU: Add TMU init and status check
  Exynos5: Config: Enable support for Exynos TMU driver
  TMU: Add TMU support in dtt command
  Exynos5: Config: Enable dtt command for TMU
  Exynos5: TMU: Add hardware tripping
  Exynos5: FDT: Add a H/W-trip member to TMU node

Rajeshwari Shinde (11):
  EXYNOS5: Add function to setup set ps hold
  SMDK5250: Add PMIC voltage settings
  EXYNOS5: Add function to enable XXTI clock source
  Sound: MAX98095: Add the driver for codec
  Sound: Support for MAX98095 codec in driver
  EXYNOS5: GPIO to enable MAX98095
  EXYNOS5: FDT: Add compatible strings for MAX98095
  config: Snow: Enable MAX98095 codec
  SMDK5250: FDT: Retrieve board model via DT
  EXYNOS5: Add initial DTS file for Snow.
  EXYNOS5: Snow: Add a configuration file

Simon Glass (1):
  EXYNOS: Correct ordering of SPL machine_params

Łukasz Majewski (1):
  mmc:sdhci:fix: Change default interrupts enabled at SDHCI initialization

 MAINTAINERS   |4 +
 arch/arm/cpu/armv7/exynos/power.c |   45 +++
 arch/arm/dts/exynos5250.dtsi  |5 +
 arch/arm/include/asm/arch-exynos/power.h  |   24 ++
 arch/arm/include/asm/arch-exynos/spl.h|3 +-
 arch/arm/include/asm/arch-exynos/tmu.h|   58 +++
 board/samsung/dts/exynos5250-smdk5250.dts |   13 +
 board/samsung/dts/exynos5250-snow.dts |   58 +++
 board/samsung/smdk5250/smdk5250.c |  178 +-
 boards.cfg|1 +
 common/cmd_dtt.c  |   32 +-
 doc/device-tree-bindings/exynos/tmu.txt   |   44 +++
 drivers/mmc/sdhci.c   |8 +-
 drivers/power/Makefile|1 +
 drivers/power/exynos-tmu.c|  319 +
 drivers/sound/Makefile|1 +
 drivers/sound/max98095.c  |  550 +
 drivers/sound/max98095.h  |  311 
 drivers/sound/sound.c |9 +-
 include/configs/exynos5250-dt.h   |6 +
 include/configs/snow.h|   33 ++
 include/fdtdec.h  |2 +
 include/power/max77686_pmic.h |   32 ++
 include/sound.h   |1 +
 include/tmu.h |   46 +++
 lib/fdtdec.c  |2 +
 26 files changed, 1776 insertions(+), 10 deletions(-)
 create mode 100644 arch/arm/include/asm/arch-exynos/tmu.h
 create mode 100644 board/samsung/dts/exynos5250-snow.dts
 create mode 100644 doc/device-tree-bindings/exynos/tmu.txt
 create mode 100644 drivers/power/exynos-tmu.c
 create mode 100644 drivers/sound/max98095.c
 create mode 100644 drivers/sound/max98095.h
 create mode 100644 include/configs/snow.h
 create mode 100644 include/tmu.h

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

Re: [U-Boot] Booting zImage from UBOOT

[Ritu Sharma]

 Thanks for the info. But I checked the version supported by the vendor of
board does not have bootz command implemented.
And I am just a user for UBOOT.

Thus could anyone just let me know that the hack I am using is correct and
if I jump at offset 0x40 in uImage then it is equilant of using zImage
directly?
I use bootm command since it already satisfies all the kernel requirements
mentioned at here:
http://www.arm.linux.org.uk/developer/booting.php

Best Regards
Ritu

On Thu, Mar 21, 2013 at 3:10 AM, Fabio Estevam feste...@gmail.com wrote:

  On Wed, Mar 20, 2013 at 6:02 PM, Stephen Warren swar...@wwwdotorg.org
 wrote:
  On 03/20/2013 01:27 PM, Ritu Sharma wrote:
  ...
  I read that uImage is nothing more than (64byte header + zImage). I've
 been
  studying decompression code so it suited me to tweak UBOOT code to boot
  zImage rather than writing my own bootcode. Just a small modification in
  do_bootm_linux function did the job:
 
  In recent versions of U-Boot, you can simply enable the bootz command,
  which boots a raw zImage.

 And in order to enable the bootz command, you need to add:
 #define CONFIG_CMD_BOOTZ

 ,in your board config file (include/configs/)

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

[U-Boot] [PATCH 0/3 V4] EXYNOS5: Add GPIO numbering feature

[Rajeshwari Shinde]

Changes in V2:
- Enabled CMD_GPIO as suggested by Simon Glass and
supported same for EXYNOS5
Changes in V3:
- New patch added to rename S5P GPIO definitions to
S5P_GPIO
- GPIO Table added to calculate the base address
of input gpio bank.
Changes in V4:
- To have consistent 0..n-1 GPIO numbering the banks are divided
into different parts where ever they have holes in them.
- Function and table to support gpio command moved to s5p-gpio driver
- Rebased on latest u-boot-samsung tree 

Rajeshwari Shinde (3):
  EXYNOS5: Add gpio pin numbering feature
  S5P: Rename GPIO definitions
  EXYNOS5: GPIO: Enable GPIO Command for EXYNOS5

 arch/arm/cpu/armv7/exynos/pinmux.c   |  206 +++-
 arch/arm/include/asm/arch-exynos/cpu.h   |   10 +-
 arch/arm/include/asm/arch-exynos/gpio.h  |  410 --
 arch/arm/include/asm/arch-s5pc1xx/gpio.h |   26 +-
 board/samsung/goni/goni.c|4 +-
 board/samsung/origen/origen.c|8 +-
 board/samsung/smdk5250/smdk5250.c|   24 +--
 board/samsung/smdkc100/smdkc100.c|2 +-
 board/samsung/smdkv310/smdkv310.c|   10 +-
 board/samsung/trats/trats.c  |   16 +-
 board/samsung/universal_c210/universal.c |   36 ++--
 drivers/gpio/s5p_gpio.c  |  134 +-
 include/configs/exynos5250-dt.h  |1 +
 13 files changed, 669 insertions(+), 218 deletions(-)

-- 
1.7.4.4

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

[U-Boot] [PATCH 1/3 V4] EXYNOS5: Add gpio pin numbering feature

[Rajeshwari Shinde]

This patch adds support for gpio pin numbering support on
EXYNOS5250
To have consistent 0..n-1 GPIO numbering the banks are divided
into different parts where ever they have holes in them.

Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com
Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com
---
Changes in V2:
- none.
Changes in V3:
- none.
Changes in V4:
- To have consistent 0..n-1 GPIO numbering the banks are divided
into different parts where ever they have holes in them.
- Combined previous patch 1 and 2 into single patch.
 arch/arm/cpu/armv7/exynos/pinmux.c  |  148 +---
 arch/arm/include/asm/arch-exynos/cpu.h  |   10 +-
 arch/arm/include/asm/arch-exynos/gpio.h |  376 ++-
 board/samsung/smdk5250/smdk5250.c   |   24 +--
 drivers/gpio/s5p_gpio.c |   65 ++-
 5 files changed, 508 insertions(+), 115 deletions(-)

diff --git a/arch/arm/cpu/armv7/exynos/pinmux.c 
b/arch/arm/cpu/armv7/exynos/pinmux.c
index bd499b4..02a4d88 100644
--- a/arch/arm/cpu/armv7/exynos/pinmux.c
+++ b/arch/arm/cpu/armv7/exynos/pinmux.c
@@ -29,89 +29,77 @@
 
 static void exynos5_uart_config(int peripheral)
 {
-   struct exynos5_gpio_part1 *gpio1 =
-   (struct exynos5_gpio_part1 *) samsung_get_base_gpio_part1();
-   struct s5p_gpio_bank *bank;
int i, start, count;
 
switch (peripheral) {
case PERIPH_ID_UART0:
-   bank = gpio1-a0;
-   start = 0;
+   start = EXYNOS5_GPIO_A00;
count = 4;
break;
case PERIPH_ID_UART1:
-   bank = gpio1-d0;
-   start = 0;
+   start = EXYNOS5_GPIO_D00;
count = 4;
break;
case PERIPH_ID_UART2:
-   bank = gpio1-a1;
-   start = 0;
+   start = EXYNOS5_GPIO_A10;
count = 4;
break;
case PERIPH_ID_UART3:
-   bank = gpio1-a1;
-   start = 4;
+   start = EXYNOS5_GPIO_A14;
count = 2;
break;
}
for (i = start; i  start + count; i++) {
-   s5p_gpio_set_pull(bank, i, GPIO_PULL_NONE);
-   s5p_gpio_cfg_pin(bank, i, GPIO_FUNC(0x2));
+   gpio_set_pull(i, GPIO_PULL_NONE);
+   gpio_cfg_pin(i, GPIO_FUNC(0x2));
}
 }
 
 static int exynos5_mmc_config(int peripheral, int flags)
 {
-   struct exynos5_gpio_part1 *gpio1 =
-   (struct exynos5_gpio_part1 *) samsung_get_base_gpio_part1();
-   struct s5p_gpio_bank *bank, *bank_ext;
-   int i, start = 0, gpio_func = 0;
+   int i, start, start_ext, gpio_func = 0;
 
switch (peripheral) {
case PERIPH_ID_SDMMC0:
-   bank = gpio1-c0;
-   bank_ext = gpio1-c1;
-   start = 0;
+   start = EXYNOS5_GPIO_C00;
+   start_ext = EXYNOS5_GPIO_C10;
gpio_func = GPIO_FUNC(0x2);
break;
case PERIPH_ID_SDMMC1:
-   bank = gpio1-c2;
-   bank_ext = NULL;
+   start = EXYNOS5_GPIO_C20;
+   start_ext = 0;
break;
case PERIPH_ID_SDMMC2:
-   bank = gpio1-c3;
-   bank_ext = gpio1-c4;
-   start = 3;
+   start = EXYNOS5_GPIO_C30;
+   start_ext = EXYNOS5_GPIO_C43;
gpio_func = GPIO_FUNC(0x3);
break;
case PERIPH_ID_SDMMC3:
-   bank = gpio1-c4;
-   bank_ext = NULL;
+   start = EXYNOS5_GPIO_C40;
+   start_ext = 0;
break;
}
-   if ((flags  PINMUX_FLAG_8BIT_MODE)  !bank_ext) {
+   if ((flags  PINMUX_FLAG_8BIT_MODE)  !start_ext) {
debug(SDMMC device %d does not support 8bit mode,
peripheral);
return -1;
}
if (flags  PINMUX_FLAG_8BIT_MODE) {
-   for (i = start; i = (start + 3); i++) {
-   s5p_gpio_cfg_pin(bank_ext, i, gpio_func);
-   s5p_gpio_set_pull(bank_ext, i, GPIO_PULL_UP);
-   s5p_gpio_set_drv(bank_ext, i, GPIO_DRV_4X);
+   for (i = start_ext; i = (start_ext + 3); i++) {
+   gpio_cfg_pin(i, gpio_func);
+   gpio_set_pull(i, GPIO_PULL_UP);
+   gpio_set_drv(i, GPIO_DRV_4X);
}
}
for (i = 0; i  2; i++) {
-   s5p_gpio_cfg_pin(bank, i, GPIO_FUNC(0x2));
-   s5p_gpio_set_pull(bank, i, GPIO_PULL_NONE);
-   s5p_gpio_set_drv(bank, i, GPIO_DRV_4X);
+   gpio_cfg_pin(start + i, GPIO_FUNC(0x2));
+   gpio_set_pull(start + i, GPIO_PULL_NONE);
+   gpio_set_drv(start + i, GPIO_DRV_4X);
}
for (i = 3; i = 6; 

[U-Boot] [PATCH 2/3 V4] S5P: Rename GPIO definitions

[Rajeshwari Shinde]

This patch rename GPIO definitions from GPIO_... to S5P_GPIO_...
This changes was done to enable cmd_gpio for EXYNOS and
cmd_gpio has GPIO_INPUT same as s5p_gpio driver and hence
getting a error during compilation.

Build tested for s5p_goni, origen, smdk5250, s5pc210_universal,
trats, smdkc100, smdkv310 config files.

Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com
---
Chnages in V3:
- New Patch
Changes in V4:
- None
 arch/arm/cpu/armv7/exynos/pinmux.c   |  134 +++---
 arch/arm/include/asm/arch-exynos/gpio.h  |   26 +++---
 arch/arm/include/asm/arch-s5pc1xx/gpio.h |   26 +++---
 board/samsung/goni/goni.c|4 +-
 board/samsung/origen/origen.c|8 +-
 board/samsung/smdk5250/smdk5250.c|8 +-
 board/samsung/smdkc100/smdkc100.c|2 +-
 board/samsung/smdkv310/smdkv310.c|   10 +-
 board/samsung/trats/trats.c  |   16 ++--
 board/samsung/universal_c210/universal.c |   36 
 drivers/gpio/s5p_gpio.c  |   20 ++--
 11 files changed, 145 insertions(+), 145 deletions(-)

diff --git a/arch/arm/cpu/armv7/exynos/pinmux.c 
b/arch/arm/cpu/armv7/exynos/pinmux.c
index 02a4d88..1e7d14c 100644
--- a/arch/arm/cpu/armv7/exynos/pinmux.c
+++ b/arch/arm/cpu/armv7/exynos/pinmux.c
@@ -50,8 +50,8 @@ static void exynos5_uart_config(int peripheral)
break;
}
for (i = start; i  start + count; i++) {
-   gpio_set_pull(i, GPIO_PULL_NONE);
-   gpio_cfg_pin(i, GPIO_FUNC(0x2));
+   gpio_set_pull(i, S5P_GPIO_PULL_NONE);
+   gpio_cfg_pin(i, S5P_GPIO_FUNC(0x2));
}
 }
 
@@ -63,7 +63,7 @@ static int exynos5_mmc_config(int peripheral, int flags)
case PERIPH_ID_SDMMC0:
start = EXYNOS5_GPIO_C00;
start_ext = EXYNOS5_GPIO_C10;
-   gpio_func = GPIO_FUNC(0x2);
+   gpio_func = S5P_GPIO_FUNC(0x2);
break;
case PERIPH_ID_SDMMC1:
start = EXYNOS5_GPIO_C20;
@@ -72,7 +72,7 @@ static int exynos5_mmc_config(int peripheral, int flags)
case PERIPH_ID_SDMMC2:
start = EXYNOS5_GPIO_C30;
start_ext = EXYNOS5_GPIO_C43;
-   gpio_func = GPIO_FUNC(0x3);
+   gpio_func = S5P_GPIO_FUNC(0x3);
break;
case PERIPH_ID_SDMMC3:
start = EXYNOS5_GPIO_C40;
@@ -87,19 +87,19 @@ static int exynos5_mmc_config(int peripheral, int flags)
if (flags  PINMUX_FLAG_8BIT_MODE) {
for (i = start_ext; i = (start_ext + 3); i++) {
gpio_cfg_pin(i, gpio_func);
-   gpio_set_pull(i, GPIO_PULL_UP);
-   gpio_set_drv(i, GPIO_DRV_4X);
+   gpio_set_pull(i, S5P_GPIO_PULL_UP);
+   gpio_set_drv(i, S5P_GPIO_DRV_4X);
}
}
for (i = 0; i  2; i++) {
-   gpio_cfg_pin(start + i, GPIO_FUNC(0x2));
-   gpio_set_pull(start + i, GPIO_PULL_NONE);
-   gpio_set_drv(start + i, GPIO_DRV_4X);
+   gpio_cfg_pin(start + i, S5P_GPIO_FUNC(0x2));
+   gpio_set_pull(start + i, S5P_GPIO_PULL_NONE);
+   gpio_set_drv(start + i, S5P_GPIO_DRV_4X);
}
for (i = 3; i = 6; i++) {
-   gpio_cfg_pin(start + i, GPIO_FUNC(0x2));
-   gpio_set_pull(start + i, GPIO_PULL_UP);
-   gpio_set_drv(start + i, GPIO_DRV_4X);
+   gpio_cfg_pin(start + i, S5P_GPIO_FUNC(0x2));
+   gpio_set_pull(start + i, S5P_GPIO_PULL_UP);
+   gpio_set_drv(start + i, S5P_GPIO_DRV_4X);
}
 
return 0;
@@ -125,12 +125,12 @@ static void exynos5_sromc_config(int flags)
 * GPY1[3]  EBI_DATA_RDn(2)
 */
gpio_cfg_pin(EXYNOS5_GPIO_Y00 + (flags  PINMUX_FLAG_BANK),
-   GPIO_FUNC(2));
-   gpio_cfg_pin(EXYNOS5_GPIO_Y04, GPIO_FUNC(2));
-   gpio_cfg_pin(EXYNOS5_GPIO_Y05, GPIO_FUNC(2));
+   S5P_GPIO_FUNC(2));
+   gpio_cfg_pin(EXYNOS5_GPIO_Y04, S5P_GPIO_FUNC(2));
+   gpio_cfg_pin(EXYNOS5_GPIO_Y05, S5P_GPIO_FUNC(2));
 
for (i = 0; i  4; i++)
-   gpio_cfg_pin(EXYNOS5_GPIO_Y10 + i, GPIO_FUNC(2));
+   gpio_cfg_pin(EXYNOS5_GPIO_Y10 + i, S5P_GPIO_FUNC(2));
 
/*
 * EBI: 8 Addrss Lines
@@ -165,14 +165,14 @@ static void exynos5_sromc_config(int flags)
 * GPY6[7]  EBI_DATA[15](2)
 */
for (i = 0; i  8; i++) {
-   gpio_cfg_pin(EXYNOS5_GPIO_Y30 + i, GPIO_FUNC(2));
-   gpio_set_pull(EXYNOS5_GPIO_Y30 + i, GPIO_PULL_UP);
+   gpio_cfg_pin(EXYNOS5_GPIO_Y30 + i, S5P_GPIO_FUNC(2));
+   gpio_set_pull(EXYNOS5_GPIO_Y30 + i, S5P_GPIO_PULL_UP);
 
-   gpio_cfg_pin(EXYNOS5_GPIO_Y50 + i, GPIO_FUNC(2));
-   

[U-Boot] [PATCH 3/3 V4] EXYNOS5: GPIO: Enable GPIO Command for EXYNOS5

[Rajeshwari Shinde]

This patch enables GPIO Command for EXYNOS5.
Function has been added to asm/gpio.h to decode the
input gpio name to gpio number.
example: gpio set gpa00

Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com
---
Changes in V2:
- New patch
Changes in V3:
- Created a table to know the base address of input bank.
Changes in V4:
- Moved the function name_to_gpio to s5p gpio driver and 
renamed to s5p_name_to_gpio.
 arch/arm/include/asm/arch-exynos/gpio.h |8 +
 drivers/gpio/s5p_gpio.c |   49 +++
 include/configs/exynos5250-dt.h |1 +
 3 files changed, 58 insertions(+), 0 deletions(-)

diff --git a/arch/arm/include/asm/arch-exynos/gpio.h 
b/arch/arm/include/asm/arch-exynos/gpio.h
index 0b8e35e..7c0df0b 100644
--- a/arch/arm/include/asm/arch-exynos/gpio.h
+++ b/arch/arm/include/asm/arch-exynos/gpio.h
@@ -668,6 +668,14 @@ static inline unsigned int s5p_gpio_part_max(int nr)
return 0;
 }
 
+struct gpio_name_num_table {
+   char bank;
+   unsigned int base;
+};
+
+int s5p_name_to_gpio(const char *name);
+#define name_to_gpio(n) s5p_name_to_gpio(n)
+
 void gpio_cfg_pin(int gpio, int cfg);
 void gpio_set_pull(int gpio, int mode);
 void gpio_set_drv(int gpio, int mode);
diff --git a/drivers/gpio/s5p_gpio.c b/drivers/gpio/s5p_gpio.c
index a503137..312d352 100644
--- a/drivers/gpio/s5p_gpio.c
+++ b/drivers/gpio/s5p_gpio.c
@@ -57,6 +57,21 @@ static const struct gpio_info 
gpio_data[EXYNOS5_GPIO_NUM_PARTS] = {
 #define HAVE_GENERIC_GPIO
 #endif
 
+struct gpio_name_num_table exynos5_gpio_table[] = {
+   { 'a', EXYNOS5_GPIO_A00 },
+   { 'b', EXYNOS5_GPIO_B00 },
+   { 'c', EXYNOS5_GPIO_C00 },
+   { 'd', EXYNOS5_GPIO_D00 },
+   { 'y', EXYNOS5_GPIO_Y00 },
+   { 'x', EXYNOS5_GPIO_X00 },
+   { 'e', EXYNOS5_GPIO_E00 },
+   { 'f', EXYNOS5_GPIO_F00 },
+   { 'g', EXYNOS5_GPIO_G00 },
+   { 'h', EXYNOS5_GPIO_H00 },
+   { 'v', EXYNOS5_GPIO_V00 },
+   { 'z', EXYNOS5_GPIO_Z0 },
+};
+
 void s5p_gpio_cfg_pin(struct s5p_gpio_bank *bank, int gpio, int cfg)
 {
unsigned int value;
@@ -259,3 +274,37 @@ void gpio_cfg_pin(int gpio, int cfg)
s5p_gpio_cfg_pin(s5p_gpio_get_bank(gpio),
s5p_gpio_get_pin(gpio), cfg);
 }
+
+int s5p_name_to_gpio(const char *name)
+{
+   unsigned int num, i;
+
+   name++;
+
+   if (*name == 'p')
+   ++name;
+
+   for (i = 0; i  ARRAY_SIZE(exynos5_gpio_table); i++) {
+   if (*name == exynos5_gpio_table[i].bank) {
+   if (*name == 'c') {
+   name++;
+   num = simple_strtoul(name, NULL, 10);
+   if (num = 40) {
+   num = EXYNOS5_GPIO_C40 + (num - 40);
+   } else {
+   num = simple_strtoul(name, NULL, 8);
+   num = exynos5_gpio_table[i].base + num;
+   }
+   } else {
+   name++;
+   num = simple_strtoul(name, NULL, 8);
+   num = exynos5_gpio_table[i].base + num;
+   }
+   break;
+   }
+   }
+
+   if (i == ARRAY_SIZE(exynos5_gpio_table))
+   return -1;
+   return num;
+}
diff --git a/include/configs/exynos5250-dt.h b/include/configs/exynos5250-dt.h
index 9fab0fb..5a8a2fb 100644
--- a/include/configs/exynos5250-dt.h
+++ b/include/configs/exynos5250-dt.h
@@ -115,6 +115,7 @@
 #define CONFIG_CMD_EXT2
 #define CONFIG_CMD_FAT
 #define CONFIG_CMD_NET
+#define CONFIG_CMD_GPIO
 
 #define CONFIG_BOOTDELAY   3
 #define CONFIG_ZERO_BOOTDELAY_CHECK
-- 
1.7.4.4

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

[U-Boot] [PATCH] Exynos5: clock: Fix a typo bug in exynos clock init

[Akshay Saraswat]

We intended to clear the bits of CLK_SRC_TOP2 register, instead we were
writing on the reserved bits of src_core1 register. Since the default
value of clk_src_top2 register were itself zero, this typo was not
creating any big issue. But it is better to fix this error for better
readability of the code.

Signed-off-by: Hatim Ali hatim...@samsung.com
Signed-off-by: Akshay Saraswat aksha...@samsung.com
---
 board/samsung/smdk5250/clock_init.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/board/samsung/smdk5250/clock_init.c 
b/board/samsung/smdk5250/clock_init.c
index c009ae5..0ee65ae 100644
--- a/board/samsung/smdk5250/clock_init.c
+++ b/board/samsung/smdk5250/clock_init.c
@@ -434,10 +434,10 @@ void system_clock_init()
val = readl(clk-mux_stat_core1);
} while ((val | MUX_MPLL_SEL_MASK) != val);
 
-   clrbits_le32(clk-src_core1, MUX_CPLL_SEL_MASK);
-   clrbits_le32(clk-src_core1, MUX_EPLL_SEL_MASK);
-   clrbits_le32(clk-src_core1, MUX_VPLL_SEL_MASK);
-   clrbits_le32(clk-src_core1, MUX_GPLL_SEL_MASK);
+   clrbits_le32(clk-src_top2, MUX_CPLL_SEL_MASK);
+   clrbits_le32(clk-src_top2, MUX_EPLL_SEL_MASK);
+   clrbits_le32(clk-src_top2, MUX_VPLL_SEL_MASK);
+   clrbits_le32(clk-src_top2, MUX_GPLL_SEL_MASK);
tmp = MUX_CPLL_SEL_MASK | MUX_EPLL_SEL_MASK | MUX_VPLL_SEL_MASK
| MUX_GPLL_SEL_MASK;
do {
-- 
1.8.0

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

Re: [U-Boot] [PATCH] ARM: OMAP5: Set fdt_high to enable booting with Device tree

[Tom Rini]

On Thu, Mar 21, 2013 at 12:25:17PM +0530, Sricharan R wrote:

 While booting with dtblob, if fdt_high is not set to
 0x, the dt blob is relocated to a higher address,
 which the kernel is not able to use without HIGHMEM.
 
 So set it to 0x to avoid the issue.
 
 Signed-off-by: Sricharan R r.sricha...@ti.com

That's fine, but while we're making this DT-happy, lets add fdtaddr to
the env (so there's a good default and safe address to load the DT to)
and make the default boot commands load and pass the DT.  That means
that we need to make sure that you probably need to enable
CONFIG_ENV_VARS_UBOOT_CONFIG and perhaps
CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG (and see board/ti/am335x/board.c
for an example) so that we pick out the right DT file to load.

-- 
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 1/1] console: Improve TFTP booting performance

[Wolfgang Denk]

Dear Jim Lin,

In message 1363861408-21042-1-git-send-email-ji...@nvidia.com you wrote:
 TFTP booting is observed a little bit slow, especially when a USB
 keyboard is installed.
 The fix is to check whether Ctrl-C key is pressed every
 CONFIG_CTRLC_POLL_S second.
 
 Signed-off-by: Jim Lin ji...@nvidia.com
 ---
 Changes in V2:
  1. Change configuration name from CONFIG_CTRLC_POLL_MS to 
 CONFIG_CTRLC_POLL_S.
  2. New code will be executed only when CONFIG_CTRLC_POLL_S is defined in
 configuration header file.
  3. Add description in README.console.
 
  common/console.c   |   16 
  doc/README.console |   10 ++
  2 files changed, 26 insertions(+), 0 deletions(-)

NAK.

You modify not only the TFTP related code, but the general behaviour
everywhere.  For you, and for TFTP operation, it might be sufficient
to check for ^C only every few seconds, but in general this is not the
case.

You write your problem comes from using a USB keyboard, where tstc()
appears to be a slow operation.

In this case it would be best to fix the problem at the root, i. e.
improve the performance of tstc() so it doesn't hurt any more.

What you are doing here is just paperingover a problem which may (and
will) hit you in other places as well.  Do not do that.  Fix the root
problem.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
As usual, this being a 1.3.x release, I haven't  even  compiled  this
kernel yet. So if it works, you should be doubly impressed.
  - Linus Torvalds in 199506181536.saa10...@keos.cs.helsinki.fi
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v3 1/2] omap_hsmmc: Check wp and cd GPIO for valid GPIO first

[Tom Rini]

When we cannot check write protect or card change via GPIO (and have
been passed -1 in omap_mmc_init), only try if gpio_is_valid is
true.  This prevents invalid GPIO messages from being seen on the
console when doing MMC operations

Signed-off-by: Tom Rini tr...@ti.com

---
Changes in v3:
- Style comments from Nikita Kiryanov

Changes in v2:
- Use gpio_is_valid not just a check for = 0 (Fabio Estevam)
---
 drivers/mmc/omap_hsmmc.c |   12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/omap_hsmmc.c b/drivers/mmc/omap_hsmmc.c
index 67cfcc2..d599482 100644
--- a/drivers/mmc/omap_hsmmc.c
+++ b/drivers/mmc/omap_hsmmc.c
@@ -73,13 +73,21 @@ static int omap_mmc_setup_gpio_in(int gpio, const char 
*label)
 static int omap_mmc_getcd(struct mmc *mmc)
 {
int cd_gpio = ((struct omap_hsmmc_data *)mmc-priv)-cd_gpio;
-   return gpio_get_value(cd_gpio);
+
+   if (gpio_is_valid(cd_gpio))
+   return gpio_get_value(cd_gpio);
+
+   return -1;
 }
 
 static int omap_mmc_getwp(struct mmc *mmc)
 {
int wp_gpio = ((struct omap_hsmmc_data *)mmc-priv)-wp_gpio;
-   return gpio_get_value(wp_gpio);
+
+   if (gpio_is_valid(wp_gpio))
+   return gpio_get_value(wp_gpio);
+
+   return -1;
 }
 #else
 static inline int omap_mmc_setup_gpio_in(int gpio, const char *label)
-- 
1.7.9.5

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

[U-Boot] [PATCH v3 2/2] omap_hsmmc: Use -EINVAL not -1 for errors

[Tom Rini]

Signed-off-by: Tom Rini tr...@ti.com

---
Changes in v3:
- Reapply with style changes in previous patch
- Add missing asm/errno.h

Changes in v2:
- New patch, use -EINVAL in the driver
---
 drivers/mmc/omap_hsmmc.c |   15 ---
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/drivers/mmc/omap_hsmmc.c b/drivers/mmc/omap_hsmmc.c
index d599482..53aa2bd 100644
--- a/drivers/mmc/omap_hsmmc.c
+++ b/drivers/mmc/omap_hsmmc.c
@@ -34,6 +34,7 @@
 #include asm/io.h
 #include asm/arch/mmc_host_def.h
 #include asm/arch/sys_proto.h
+#include asm/errno.h
 
 /* common definitions for all OMAPs */
 #define SYSCTL_SRC (1  25)
@@ -59,13 +60,13 @@ static struct omap_hsmmc_data hsmmc_dev_data[3];
 static int omap_mmc_setup_gpio_in(int gpio, const char *label)
 {
if (!gpio_is_valid(gpio))
-   return -1;
+   return -EINVAL;
 
if (gpio_request(gpio, label)  0)
-   return -1;
+   return -EINVAL;
 
if (gpio_direction_input(gpio)  0)
-   return -1;
+   return -EINVAL;
 
return gpio;
 }
@@ -77,7 +78,7 @@ static int omap_mmc_getcd(struct mmc *mmc)
if (gpio_is_valid(cd_gpio))
return gpio_get_value(cd_gpio);
 
-   return -1;
+   return -EINVAL;
 }
 
 static int omap_mmc_getwp(struct mmc *mmc)
@@ -87,12 +88,12 @@ static int omap_mmc_getwp(struct mmc *mmc)
if (gpio_is_valid(wp_gpio))
return gpio_get_value(wp_gpio);
 
-   return -1;
+   return -EINVAL;
 }
 #else
 static inline int omap_mmc_setup_gpio_in(int gpio, const char *label)
 {
-   return -1;
+   return -EINVAL;
 }
 
 #define omap_mmc_getcd NULL
@@ -401,7 +402,7 @@ static int mmc_send_cmd(struct mmc *mmc, struct mmc_cmd 
*cmd,
mmc_reset_controller_fsm(mmc_base, SYSCTL_SRC);
return TIMEOUT;
} else if ((mmc_stat  ERRI_MASK) != 0)
-   return -1;
+   return -EINVAL;
 
if (mmc_stat  CC_MASK) {
writel(CC_MASK, mmc_base-stat);
-- 
1.7.9.5

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

Re: [U-Boot] [RFC] command/cache: Add flush_cache command

[Tom Rini]

On Thu, Mar 21, 2013 at 06:39:31AM +0100, Wolfgang Denk wrote:
 Dear Tom Rini,
 
 In message 20130320195919.GR25919@bill-the-cat you wrote:
  
  OK, so this does sound like a real need / use for it, and if we added
  the granularity of CONFIG_CMD_CACHE_FLUSH or similar, it would be
  reasonable to turn it on to a large number of boards for a small space
  savings (so lets not).  My next concern is that this needs build testing
 
 Not really. Only a tiny fraction of users will ever run any standalone
 applications, so please let's save the memory footprint for the
 overwhelming majority of users who do not need that.

Well, can we run into this problem on ARM (v7 or v8) systems 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

Re: [U-Boot] [RFC] command/cache: Add flush_cache command

[Wolfgang Denk]

Dear Tom,

In message 20130321122923.GB26945@bill-the-cat you wrote:
 
  Not really. Only a tiny fraction of users will ever run any standalone
  applications, so please let's save the memory footprint for the
  overwhelming majority of users who do not need that.
 
 Well, can we run into this problem on ARM (v7 or v8) systems as well?

Probably.

But I wonder what the exact usage szenario is that will trigger the
problem.  If I understand correctly, this can only happen when you
perform a (manual) memory copy (either between different locations in
RAM, or from parallel NOR flash to RAM) of the code you are going to
run.

As far as I understand all other ways to load any such code (over the
network or from storage devices) already make sure to run flush_cache()
after any such load operation.


Scott: is my understanding correct that you only need this because
you are performing such memory copy ops manually?  From where / to
where are you copying, and why?


Thinking about alternatives:

- eventually we should discourage the use of go; it may be
  conveniend when you know what you are doing, but if it's casuing
  such problems we might be better off recommending to use 
  proper IH_TYPE_STANDALONE legacy images in combination with the
  bootm command instead.

- Also, instead of adding a new command, this could probably be
  scripted; I guess this should be roughly equivalent?

setenv flush_cache 'dc off;ic off;dc on;ic on'

  ??

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
If the hours are long enough and the pay  is  short  enough,  someone
will say it's women's work.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] Fix bootdelay timeout calculation when SYS_HZ!=1000

[Tom Rini]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 03/21/2013 02:55 AM, Wolfgang Denk wrote:
 Dear Stephen Warren,
 
 In message 1363842874-8286-1-git-send-email-swar...@wwwdotorg.org
 you wrote:
 Commit b2f3e0e console: USB: KBD: Fix incorrect autoboot
 timeout re-wrote the bootdelay timeout loop. However, it
 hard-coded the value that get_delay() was expected to increment
 in one second, rather than calculating it based on CONFIG_SYS_HZ.
 On systems where SYS_HZ != 1000, this caused bootdelay timeout to
 be incorrect. Fix this.
 
 Are there any such systems left?  I agree with your patch, but if
 you know of systems that use incorrect values of CONFIG_SYS_HZ then
 please point these out so they can be fixed!
 
 A system with CONFIG_SYS_HZ != 1000 is _broken_.

So, RPi is going higher, and Jon hit this on I suspect omap2420h4
which is also higher (after mathing that all out).  If we no longer
support CONFIG_SYS_HZ != 1000 we need to make that clear (and explain
why).

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

iQIcBAEBAgAGBQJRSxA2AAoJENk4IS6UOR1WPzwP/3f+BiTw3s9cWGZKOb4gDza3
n0ke0rZdqLkwixK3Ugl5IqcquTLEh5QZcZb37cGgWQ0N0YvUoIxcBR73mWSHhQgy
VMlVU0vtlrGQsFmN0kbouO+qpzyoAkaDidt6T/WxDazgd+CoCuHguXki1peEB/HQ
ryQ6yNOog5dFUux85cL+AmWZYRkGXRWJfrIqKHZ9MPvz3TxXjhFBZ4lR+8JwMWgS
wPIFhNMTWnIHvXCfbcumFXV0Lgyn0DYnCbKIMLM/NucRKcHX8ZYnX1L8UOGvRzZn
jjqKFm95dNvPhZLLAaZI2TmVu5YMR9VZmmZpst0VC3eACkcQ+70G8CA+3ApmTC2C
3FcLnQQnWlG83/3qj23Qc6trLsk17spEIN0GaSy5ow261sbsXotLEsw0K7luaZPM
Y6KF5cZSyqQZ9TdnIbVxtcsI0Vwk5lLvtB91qleAJDrqn9o4ugEl0IWcRlwN9t9a
DQM0t/P+DotOlLdVQ6elVcimVxBvKLJEMIcdJVyKqsnOQIs9ct9fPm9j03ZRpS9S
YlvegCU/n0J25RVtZL6+hpOQa2ZkZOyFg3sZwSLx42jDilvIYemYcGaH21C64prJ
HJ7+rnxPvK1lC4DPVP0QoIrQEpgABnTZfDaLsts/z3sq2m4+S9uZHqiwyBJ4luoa
ua2LQXAovkSF1FA2kV1I
=VTCE
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 1/2] mmc: mmc_getcd/getwp: use sensible defaults

[Peter Korsgaard]

Let mmc_getcd() return true and mmc_getwp() false if mmc driver doesn't
provide handlers for them.

Signed-off-by: Peter Korsgaard peter.korsga...@barco.com
---
 drivers/mmc/mmc.c |   14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index 7b5fdd9..54d23eb 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -51,8 +51,11 @@ int mmc_getwp(struct mmc *mmc)
 
wp = board_mmc_getwp(mmc);
 
-   if ((wp  0)  mmc-getwp)
-   wp = mmc-getwp(mmc);
+   if (wp  0)
+   if (mmc-getwp)
+   wp = mmc-getwp(mmc);
+   else
+   wp = 0;
 
return wp;
 }
@@ -692,8 +695,11 @@ int mmc_getcd(struct mmc *mmc)
 
cd = board_mmc_getcd(mmc);
 
-   if ((cd  0)  mmc-getcd)
-   cd = mmc-getcd(mmc);
+   if (cd  0)
+   if (mmc-getcd)
+   cd = mmc-getcd(mmc);
+   else
+   cd = 1;
 
return cd;
 }
-- 
1.7.10.4

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

[U-Boot] [PATCH 2/2] mmc: omap_hsmmc.c: only register getcd/getwp callbacks if gpio could be used

[Peter Korsgaard]

Gets rid of warnings from omap_gpio:
ERROR : check_gpio: invalid GPIO -1

(and undefined behaviour as the -1 error code is interpreted as gpio value)

Signed-off-by: Peter Korsgaard peter.korsga...@barco.com
---
 drivers/mmc/omap_hsmmc.c |8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/omap_hsmmc.c b/drivers/mmc/omap_hsmmc.c
index 67cfcc2..166744c 100644
--- a/drivers/mmc/omap_hsmmc.c
+++ b/drivers/mmc/omap_hsmmc.c
@@ -593,8 +593,6 @@ int omap_mmc_init(int dev_index, uint host_caps_mask, uint 
f_max, int cd_gpio,
mmc-send_cmd = mmc_send_cmd;
mmc-set_ios = mmc_set_ios;
mmc-init = mmc_init_setup;
-   mmc-getcd = omap_mmc_getcd;
-   mmc-getwp = omap_mmc_getwp;
mmc-priv = priv_data;
 
switch (dev_index) {
@@ -616,7 +614,13 @@ int omap_mmc_init(int dev_index, uint host_caps_mask, uint 
f_max, int cd_gpio,
return 1;
}
priv_data-cd_gpio = omap_mmc_setup_gpio_in(cd_gpio, mmc_cd);
+   if (priv_data-cd_gpio != -1)
+   mmc-getcd = omap_mmc_getcd;
+
priv_data-wp_gpio = omap_mmc_setup_gpio_in(wp_gpio, mmc_wp);
+   if (priv_data-wp_gpio != -1)
+   mmc-getwp = omap_mmc_getwp;
+
mmc-voltages = MMC_VDD_32_33 | MMC_VDD_33_34 | MMC_VDD_165_195;
mmc-host_caps = (MMC_MODE_4BIT | MMC_MODE_HS_52MHz | MMC_MODE_HS |
MMC_MODE_HC)  ~host_caps_mask;
-- 
1.7.10.4

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

[U-Boot] [PATCH RESEND] Introduced btrfs file-system with btrload command

[Adnan Ali]

Introduces btrfs file-system to read file from
volume/sub-volumes with btrload command. This
implementation has read-only support.
This btrfs implementation is based on syslinux btrfs
code, commit 269ebc845ebc8b46ef4b0be7fa0005c7fdb95b8d.

v9: patch problem reworked.
v8: patch problem reworked.
v5: merged with master.
v4: btrls command added.

Signed-off-by: Adnan Ali adnan@codethink.co.uk
---
 Makefile   |1 +
 common/Makefile|1 +
 common/cmd_btr.c   |   65 +++
 fs/btrfs/Makefile  |   51 ++
 fs/btrfs/btrfs.c   | 1336 
 fs/fs.c|   10 +
 include/btrfs.h|  416 ++
 include/config_fallbacks.h |4 +
 include/crc.h  |8 +
 include/fs.h   |1 +
 lib/Makefile   |1 +
 lib/crc32_c.c  |   40 ++
 12 files changed, 1934 insertions(+)
 create mode 100644 common/cmd_btr.c
 create mode 100644 fs/btrfs/Makefile
 create mode 100644 fs/btrfs/btrfs.c
 create mode 100644 include/btrfs.h
 create mode 100644 lib/crc32_c.c

diff --git a/Makefile b/Makefile
index 55bd55c..bd7981d 100644
--- a/Makefile
+++ b/Makefile
@@ -257,6 +257,7 @@ endif
 LIBS-$(CONFIG_OF_EMBED) += dts/libdts.o
 LIBS-y += arch/$(ARCH)/lib/lib$(ARCH).o
 LIBS-y += fs/libfs.o \
+   fs/btrfs/libbtrfs.o \
fs/cbfs/libcbfs.o \
fs/cramfs/libcramfs.o \
fs/ext4/libext4fs.o \
diff --git a/common/Makefile b/common/Makefile
index 719fc23..d1fae56 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -73,6 +73,7 @@ COBJS-$(CONFIG_CMD_BEDBUG) += bedbug.o cmd_bedbug.o
 COBJS-$(CONFIG_CMD_BMP) += cmd_bmp.o
 COBJS-$(CONFIG_CMD_BOOTLDR) += cmd_bootldr.o
 COBJS-$(CONFIG_CMD_BOOTSTAGE) += cmd_bootstage.o
+COBJS-$(CONFIG_CMD_BTR) += cmd_btr.o
 COBJS-$(CONFIG_CMD_CACHE) += cmd_cache.o
 COBJS-$(CONFIG_CMD_CBFS) += cmd_cbfs.o
 COBJS-$(CONFIG_CMD_CONSOLE) += cmd_console.o
diff --git a/common/cmd_btr.c b/common/cmd_btr.c
new file mode 100644
index 000..e22154d
--- /dev/null
+++ b/common/cmd_btr.c
@@ -0,0 +1,65 @@
+/*
+ * (C) Copyright 2013 Codethink Limited
+ * Btrfs port to Uboot by
+ * Adnan Ali adnan@codethink.co.uk
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+/*
+ * Boot support
+ */
+#include fs.h
+#include btrfs.h
+
+char subvolname[BTRFS_MAX_SUBVOL_NAME];
+
+int do_btr_fsload(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
+{
+   if (argc  5)
+   strcpy(subvolname, argv[5]);
+   else
+   subvolname[0] = '\0';
+
+   return do_load(cmdtp, flag, argc, argv, FS_TYPE_BTR, 16);
+}
+
+
+U_BOOT_CMD(
+btrload,7,  0,  do_btr_fsload,
+   load binary file from a btr filesystem,
+   interface [dev[:part]]  addr filename [subvol_name]\n
+   - Load binary file 'filename' from 'dev' on 'interface'\n
+ to address 'addr' from better filesystem.\n
+ the load stops on end of file.\n
+ subvol_name is used read that file from this subvolume.\n
+ All numeric parameters are assumed to be hex.
+);
+
+static int do_btr_ls(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
+{
+   return do_ls(cmdtp, flag, argc, argv, FS_TYPE_BTR);
+}
+
+U_BOOT_CMD(
+   btrls,  4,  1,  do_btr_ls,
+   list files in a directory (default /),
+   interface [dev[:part]] [directory]\n
+   - list files from 'dev' on 'interface' in a 'directory'
+);
+
diff --git a/fs/btrfs/Makefile b/fs/btrfs/Makefile
new file mode 100644
index 000..a9e2021
--- /dev/null
+++ b/fs/btrfs/Makefile
@@ -0,0 +1,51 @@
+#
+# (C) Copyright 2006
+# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+#
+# (C) Copyright 2003
+# Pavel Bartusek, Sysgo Real-Time Solutions AG, p...@sysgo.de
+#
+#
+# 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 

Re: [U-Boot] [PATCH 2/2] mmc: omap_hsmmc.c: only register getcd/getwp callbacks if gpio could be used

[Tom Rini]

On Thu, Mar 21, 2013 at 03:00:04PM +0100, Peter Korsgaard wrote:

 Gets rid of warnings from omap_gpio:
 ERROR : check_gpio: invalid GPIO -1
 
 (and undefined behaviour as the -1 error code is interpreted as gpio value)
 
 Signed-off-by: Peter Korsgaard peter.korsga...@barco.com
 ---
  drivers/mmc/omap_hsmmc.c |8 ++--
  1 file changed, 6 insertions(+), 2 deletions(-)
 
 diff --git a/drivers/mmc/omap_hsmmc.c b/drivers/mmc/omap_hsmmc.c
 index 67cfcc2..166744c 100644
 --- a/drivers/mmc/omap_hsmmc.c
 +++ b/drivers/mmc/omap_hsmmc.c
 @@ -593,8 +593,6 @@ int omap_mmc_init(int dev_index, uint host_caps_mask, 
 uint f_max, int cd_gpio,
   mmc-send_cmd = mmc_send_cmd;
   mmc-set_ios = mmc_set_ios;
   mmc-init = mmc_init_setup;
 - mmc-getcd = omap_mmc_getcd;
 - mmc-getwp = omap_mmc_getwp;
   mmc-priv = priv_data;
  
   switch (dev_index) {
 @@ -616,7 +614,13 @@ int omap_mmc_init(int dev_index, uint host_caps_mask, 
 uint f_max, int cd_gpio,
   return 1;
   }
   priv_data-cd_gpio = omap_mmc_setup_gpio_in(cd_gpio, mmc_cd);
 + if (priv_data-cd_gpio != -1)
 + mmc-getcd = omap_mmc_getcd;
 +
   priv_data-wp_gpio = omap_mmc_setup_gpio_in(wp_gpio, mmc_wp);
 + if (priv_data-wp_gpio != -1)
 + mmc-getwp = omap_mmc_getwp;
 +

OK, but this should be gpio_is_valid rather than != -1, and then this is
probably a better way than my series.

-- 
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] mmc: mmc_getcd/getwp: use sensible defaults

[Tom Rini]

On Thu, Mar 21, 2013 at 03:00:03PM +0100, Peter Korsgaard wrote:

 Let mmc_getcd() return true and mmc_getwp() false if mmc driver doesn't
 provide handlers for them.
 
 Signed-off-by: Peter Korsgaard peter.korsga...@barco.com

Do we really need to do this?  It seems like we should be working
correctly here already, or we also need to fixup the weak function
and/or the callers too.

-- 
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] Patches for this merge window

[Tom Rini]

On Wed, Mar 20, 2013 at 07:27:24PM -0700, Simon Glass wrote:
 Hi Tom,
 
 On Wed, Mar 20, 2013 at 12:28 PM, Tom Rini tr...@ti.com wrote:
  On Sun, Feb 10, 2013 at 09:09:29PM -0800, Simon Glass wrote:
 
  [take 2, sorry]
 
  Hi Tom,
 
  I see quite a lot of non-x86 patches in my todo list - does that mean
  that I should pick them up if I am happy with them, or just assign
  them back to you once I've taken a look?
 
  I'm keen to get the sandbox fs and memory stuff in fairly early if
  possible, since I fear breakages and the longer people have to test
  the better. No one has screamed about map_sysmem() but I'm not sure if
  anyone noticed. So I could pull these in, build and send a pull if
  that suits? Perhaps one series at a time Also if Mike is having a
  break should I pull in the SPI ones assigned to me?
 
  There is also buildman, and I'm not sure what to do about that. It
  would be nice to have some feedback if people have tried it - I have
  had a few private emails only. I think it's a great help, but it still
  has some rough edges.
 
  Looking back at this, I think only buildman is left.  Did all of the
  other patman related changes get submitted cleanly?  I think the answer
  is we'll take in buildman now so it's easier to get folks to try it in
  their workflows and see where it takes us.
 
 Yes that's right. I can set up a bundle, along with the patman
 additions, but actually I have found some problems with patman in the
 latest mainline - checkpatch has changed. There are quite a few things
 collected now that need fixing - e.g. Doug's fix to stop removing
 Reviewed-by: tags.
 
 I will start by getting some patches out and we can take a look. Until
 then is it OK to hold off on buildman?

Sounds good to me, thanks!

-- 
Tom


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

[U-Boot] [PATCH] am335x_evm: Add better timings for the new BeagleBoard DDR3 part

[Tom Rini]

Tested-by: Rao Bodapati r...@circuitco.com
Signed-off-by: Tom Rini tr...@ti.com
---
 arch/arm/include/asm/arch-am33xx/ddr_defs.h |   17 
 board/ti/am335x/board.c |   39 ++-
 2 files changed, 55 insertions(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/arch-am33xx/ddr_defs.h 
b/arch/arm/include/asm/arch-am33xx/ddr_defs.h
index ae43ef8..6689825 100644
--- a/arch/arm/include/asm/arch-am33xx/ddr_defs.h
+++ b/arch/arm/include/asm/arch-am33xx/ddr_defs.h
@@ -82,6 +82,23 @@
 #define MT41J256M8HX15E_PHY_FIFO_WE0x100
 #define MT41J256M8HX15E_IOCTRL_VALUE   0x18B
 
+/* Micron MT41K256M16HA-125E */
+#define MT41K256M16HA125E_EMIF_READ_LATENCY0x16
+#define MT41K256M16HA125E_EMIF_TIM10x0888A39B
+#define MT41K256M16HA125E_EMIF_TIM20x26517FDA
+#define MT41K256M16HA125E_EMIF_TIM30x501F84EF
+#define MT41K256M16HA125E_EMIF_SDCFG   0x61C04BB2
+#define MT41K256M16HA125E_EMIF_SDREF   0x093B
+#define MT41K256M16HA125E_ZQ_CFG   0x50074BE4
+#define MT41K256M16HA125E_DLL_LOCK_DIFF0x1
+#define MT41K256M16HA125E_RATIO0x40
+#define MT41K256M16HA125E_INVERT_CLKOUT0x0
+#define MT41K256M16HA125E_RD_DQS   0x3C
+#define MT41K256M16HA125E_WR_DQS   0x45
+#define MT41K256M16HA125E_PHY_WR_DATA  0x7F
+#define MT41K256M16HA125E_PHY_FIFO_WE  0x9B
+#define MT41K256M16HA125E_IOCTRL_VALUE 0x18B
+
 /* Micron MT41J512M8RH-125 on EVM v1.5 */
 #define MT41J512M8RH125_EMIF_READ_LATENCY  0x06
 #define MT41J512M8RH125_EMIF_TIM1  0x0888A39B
diff --git a/board/ti/am335x/board.c b/board/ti/am335x/board.c
index f4b972b..53c0357 100644
--- a/board/ti/am335x/board.c
+++ b/board/ti/am335x/board.c
@@ -208,6 +208,14 @@ static const struct ddr_data ddr3_data = {
.datadldiff0 = PHY_DLL_LOCK_DIFF,
 };
 
+static const struct ddr_data ddr3_beagleblack_data = {
+   .datardsratio0 = MT41K256M16HA125E_RD_DQS,
+   .datawdsratio0 = MT41K256M16HA125E_WR_DQS,
+   .datafwsratio0 = MT41K256M16HA125E_PHY_FIFO_WE,
+   .datawrsratio0 = MT41K256M16HA125E_PHY_WR_DATA,
+   .datadldiff0 = PHY_DLL_LOCK_DIFF,
+};
+
 static const struct ddr_data ddr3_evm_data = {
.datardsratio0 = MT41J512M8RH125_RD_DQS,
.datawdsratio0 = MT41J512M8RH125_WR_DQS,
@@ -230,6 +238,20 @@ static const struct cmd_control ddr3_cmd_ctrl_data = {
.cmd2iclkout = MT41J128MJT125_INVERT_CLKOUT,
 };
 
+static const struct cmd_control ddr3_beagleblack_cmd_ctrl_data = {
+   .cmd0csratio = MT41K256M16HA125E_RATIO,
+   .cmd0dldiff = MT41K256M16HA125E_DLL_LOCK_DIFF,
+   .cmd0iclkout = MT41K256M16HA125E_INVERT_CLKOUT,
+
+   .cmd1csratio = MT41K256M16HA125E_RATIO,
+   .cmd1dldiff = MT41K256M16HA125E_DLL_LOCK_DIFF,
+   .cmd1iclkout = MT41K256M16HA125E_INVERT_CLKOUT,
+
+   .cmd2csratio = MT41K256M16HA125E_RATIO,
+   .cmd2dldiff = MT41K256M16HA125E_DLL_LOCK_DIFF,
+   .cmd2iclkout = MT41K256M16HA125E_INVERT_CLKOUT,
+};
+
 static const struct cmd_control ddr3_evm_cmd_ctrl_data = {
.cmd0csratio = MT41J512M8RH125_RATIO,
.cmd0dldiff = MT41J512M8RH125_DLL_LOCK_DIFF,
@@ -254,6 +276,16 @@ static struct emif_regs ddr3_emif_reg_data = {
.emif_ddr_phy_ctlr_1 = MT41J128MJT125_EMIF_READ_LATENCY,
 };
 
+static struct emif_regs ddr3_beagleblack_emif_reg_data = {
+   .sdram_config = MT41K256M16HA125E_EMIF_SDCFG,
+   .ref_ctrl = MT41K256M16HA125E_EMIF_SDREF,
+   .sdram_tim1 = MT41K256M16HA125E_EMIF_TIM1,
+   .sdram_tim2 = MT41K256M16HA125E_EMIF_TIM2,
+   .sdram_tim3 = MT41K256M16HA125E_EMIF_TIM3,
+   .zq_config = MT41K256M16HA125E_ZQ_CFG,
+   .emif_ddr_phy_ctlr_1 = MT41K256M16HA125E_EMIF_READ_LATENCY,
+};
+
 static struct emif_regs ddr3_evm_emif_reg_data = {
.sdram_config = MT41J512M8RH125_EMIF_SDCFG,
.ref_ctrl = MT41J512M8RH125_EMIF_SDREF,
@@ -341,9 +373,14 @@ void s_init(void)
gpio_direction_output(GPIO_DDR_VTT_EN, 1);
}
 
-   if (board_is_evm_sk() || board_is_bone_lt())
+   if (board_is_evm_sk())
config_ddr(303, MT41J128MJT125_IOCTRL_VALUE, ddr3_data,
   ddr3_cmd_ctrl_data, ddr3_emif_reg_data);
+   else if (board_is_bone_lt())
+   config_ddr(303, MT41K256M16HA125E_IOCTRL_VALUE,
+  ddr3_beagleblack_data,
+  ddr3_beagleblack_cmd_ctrl_data,
+  ddr3_beagleblack_emif_reg_data);
else if (board_is_evm_15_or_later())
config_ddr(303, MT41J512M8RH125_IOCTRL_VALUE, ddr3_evm_data,
   ddr3_evm_cmd_ctrl_data, ddr3_evm_emif_reg_data);
-- 
1.7.9.5

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

Re: [U-Boot] [PATCH] Fix bootdelay timeout calculation when SYS_HZ!=1000

[Wolfgang Denk]

Dear Tom,

In message 514b1036.3090...@ti.com you wrote:

  A system with CONFIG_SYS_HZ != 1000 is _broken_.
 
 So, RPi is going higher, and Jon hit this on I suspect omap2420h4
 which is also higher (after mathing that all out).  If we no longer
 support CONFIG_SYS_HZ != 1000 we need to make that clear (and explain
 why).

It has never been supported, so this is not a case of no longer.
There are several longish threads (about the timer code, especially
on ARM) in the archives.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
The whole world is about three drinks behind. - Humphrey Bogart
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

[Tom Rini]

On Tue, Feb 26, 2013 at 08:10:53AM -0800, Simon Glass wrote:

 Many parts of the U-Boot code base are sprinkled with #ifdefs. This makes
 different boards compile different versions of the source code, meaning
 that we must build all boards to check for failures. It is easy to misspell
 an #ifdef and there is not as much checking of this by the compiler. Multiple
 dependent #ifdefs are harder to do than with if..then..else. Variable
 declarations must be #idefed as well as the code that uses them, often much
 later in the file/function. #ifdef indents don't match code indents and
 have their own separate indent feature. Overall, excessive use of #idef
 hurts readability and makes the code harder to modify and refactor. For
 people coming newly into the code base, #ifdefs can be a big barrier.
 
 The use of #ifdef in U-Boot has possibly got a little out of hand. In an
 attempt to turn the tide, this series includes a patch which provides a way
 to make CONFIG macros available to C code without using the preprocessor.
 This makes it possible to use standard C conditional features such as
 if/then instead of #ifdef. A README update exhorts compliance.

OK, this is true.  Looking over the series, a number of the patches are
just general fixes / improvements that don't depend on the autoconf_...
work.  Lets split this out now and take them in now as they seem like
reviewable by inspection code.

For the approach itself, I'm not sure which is best here.  In a lot of
cases we're trading an #ifdef for adding a level of indent to already
pretty indented code and that feels like a wash, in terms of readability
to me.  We probably need to re-factor some of the code in question there
too for readability, then see about using autoconf_... type things, or
maybe something else.

-- 
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] Fix bootdelay timeout calculation when SYS_HZ!=1000

[Tom Rini]

On Thu, Mar 21, 2013 at 03:35:40PM +0100, Wolfgang Denk wrote:
 Dear Tom,
 
 In message 514b1036.3090...@ti.com you wrote:
 
   A system with CONFIG_SYS_HZ != 1000 is _broken_.
  
  So, RPi is going higher, and Jon hit this on I suspect omap2420h4
  which is also higher (after mathing that all out).  If we no longer
  support CONFIG_SYS_HZ != 1000 we need to make that clear (and explain
  why).
 
 It has never been supported, so this is not a case of no longer.
 There are several longish threads (about the timer code, especially
 on ARM) in the archives.

OK, then we need to do something about these platforms today.  I'm
guessing RPi can just be tuned down to 1000 but for omap2420h4 it's an
interesting value and I don't know about the platform well enough to say
what we'd need to do to adapt it.  Jon?

-- 
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] mmc: omap_hsmmc.c: only register getcd/getwp callbacks if gpio could be used

[Peter Korsgaard]

 Tom == Tom Rini tr...@ti.com writes:

 priv_data- cd_gpio = omap_mmc_setup_gpio_in(cd_gpio, mmc_cd);
  +   if (priv_data-cd_gpio != -1)
  +   mmc-getcd = omap_mmc_getcd;
  +
 priv_data- wp_gpio = omap_mmc_setup_gpio_in(wp_gpio, mmc_wp);
  +   if (priv_data-wp_gpio != -1)
  +   mmc-getwp = omap_mmc_getwp;
  +

 Tom OK, but this should be gpio_is_valid rather than != -1, and then this is
 Tom probably a better way than my series.

Well, omap_mmc_setup_gpio_in() explicitly return -1 on errors (could be
a valid gpio, just already reserved or unable to make input).


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

Re: [U-Boot] [PATCH 1/2] mmc: mmc_getcd/getwp: use sensible defaults

[Peter Korsgaard]

 Tom == Tom Rini tr...@ti.com writes:

 Tom On Thu, Mar 21, 2013 at 03:00:03PM +0100, Peter Korsgaard wrote:
  Let mmc_getcd() return true and mmc_getwp() false if mmc driver doesn't
  provide handlers for them.
  
  Signed-off-by: Peter Korsgaard peter.korsga...@barco.com

 Tom Do we really need to do this?  It seems like we should be working
 Tom correctly here already, or we also need to fixup the weak function
 Tom and/or the callers too.

Well, for omap_hsmmc we currently return -1, which is kind of okay for
getcd(), but if getwp() ever gets used it means we cannot write to
cards.

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

Re: [U-Boot] [PATCH 2/2] mmc: omap_hsmmc.c: only register getcd/getwp callbacks if gpio could be used

[Tom Rini]

On Thu, Mar 21, 2013 at 03:43:46PM +0100, Peter Korsgaard wrote:
  Tom == Tom Rini tr...@ti.com writes:
 
  priv_data- cd_gpio = omap_mmc_setup_gpio_in(cd_gpio, mmc_cd);
   + if (priv_data-cd_gpio != -1)
   + mmc-getcd = omap_mmc_getcd;
   +
  priv_data- wp_gpio = omap_mmc_setup_gpio_in(wp_gpio, mmc_wp);
   + if (priv_data-wp_gpio != -1)
   + mmc-getwp = omap_mmc_getwp;
   +
 
  Tom OK, but this should be gpio_is_valid rather than != -1, and then this is
  Tom probably a better way than my series.
 
 Well, omap_mmc_setup_gpio_in() explicitly return -1 on errors (could be
 a valid gpio, just already reserved or unable to make input).

Ah, OK, that works.

-- 
Tom


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

[U-Boot] [PATCH] spl_mmc: cleanup variable types

[Peter Korsgaard]

block_read returns unsigned long, so it doesn't make sense to check for
 0. and neither does marking the header structure as const and then
casting away the constness to load data into it.

Also cleanup some unneeded pointer casting while we're at it.

Signed-off-by: Peter Korsgaard peter.korsga...@barco.com
---
 drivers/mmc/spl_mmc.c |   17 +
 1 file changed, 9 insertions(+), 8 deletions(-)

diff --git a/drivers/mmc/spl_mmc.c b/drivers/mmc/spl_mmc.c
index 753c6a0..7efdcb8 100644
--- a/drivers/mmc/spl_mmc.c
+++ b/drivers/mmc/spl_mmc.c
@@ -34,8 +34,9 @@ DECLARE_GLOBAL_DATA_PTR;
 
 static void mmc_load_image_raw(struct mmc *mmc)
 {
-   u32 image_size_sectors, err;
-   const struct image_header *header;
+   unsigned long err;
+   u32 image_size_sectors;
+   struct image_header *header;
 
header = (struct image_header *)(CONFIG_SYS_TEXT_BASE -
sizeof(struct image_header));
@@ -43,9 +44,9 @@ static void mmc_load_image_raw(struct mmc *mmc)
/* read image header to find the image size  load address */
err = mmc-block_dev.block_read(0,
CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR, 1,
-   (void *)header);
+   header);
 
-   if (err = 0)
+   if (err == 0)
goto end;
 
spl_parse_image_header(header);
@@ -60,8 +61,8 @@ static void mmc_load_image_raw(struct mmc *mmc)
image_size_sectors, (void *)spl_image.load_addr);
 
 end:
-   if (err = 0) {
-   printf(spl: mmc blk read err - %d\n, err);
+   if (err == 0) {
+   printf(spl: mmc blk read err - %lu\n, err);
hang();
}
 }
@@ -69,7 +70,7 @@ end:
 #ifdef CONFIG_SPL_FAT_SUPPORT
 static void mmc_load_image_fat(struct mmc *mmc)
 {
-   s32 err;
+   int err;
struct image_header *header;
 
header = (struct image_header *)(CONFIG_SYS_TEXT_BASE -
@@ -83,7 +84,7 @@ static void mmc_load_image_fat(struct mmc *mmc)
}
 
err = file_fat_read(CONFIG_SPL_FAT_LOAD_PAYLOAD_NAME,
-   (u8 *)header, sizeof(struct image_header));
+   header, sizeof(struct image_header));
if (err = 0)
goto end;
 
-- 
1.7.10.4

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

Re: [U-Boot] [PATCH 1/1 v3] console: USB: KBD: Fix incorrect autoboot timeout

[Jon Hunter]

On 03/21/2013 01:57 AM, Wolfgang Denk wrote:
 Dear Stephen Warren,
 
 In message 514aa642.3090...@wwwdotorg.org you wrote:

 Interesting. I just noticed the same problem, and posted the following
 patch to fix it:

 http://lists.denx.de/pipermail/u-boot/2013-March/149625.html

 This was on the Raspberry Pi.
 
 You mean the Raspberry Pi uses SYS_HZ != 1000 ???
 
 This needs fixing!!

I understand that you may wish to have SYS_HZ == 1000, but shouldn't the
code still normalise the get_timer() value to SYS_HZ?

If I grep through the u-boot source I see a lot of instances where
get_timer() is normalised to SYS_HZ.

grep -r get_timer * | grep SYS_HZ

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

Re: [U-Boot] [PATCH 1/1 v3] console: USB: KBD: Fix incorrect autoboot timeout

[Jon Hunter]

Hi Marek,

On 03/20/2013 07:19 PM, Marek Vasut wrote:
 Dear Jon Hunter,
 
 On 01/24/2013 05:05 AM, Jim Lin wrote:
 Autoboot timeout defined by CONFIG_BOOTDELAY will not be accurate if
 CONFIG_USB_KEYBOARD and CONFIG_SYS_USB_EVENT_POLL are defined in
 configuration file and when tstc() function for checking key pressed
 takes longer time than 10 ms (e.g., 50 ms) to finish.

 Signed-off-by: Jim Lin ji...@nvidia.com
 ---

 Changes in v2:
- use do-while and get_timer to count timeout.

 Changes in v3:
- revert original udelay(1); for safety.
  
  common/main.c |   10 +-
  1 files changed, 5 insertions(+), 5 deletions(-)

 diff --git a/common/main.c b/common/main.c
 index b145f85..dcd2a42 100644
 --- a/common/main.c
 +++ b/common/main.c
 @@ -225,6 +225,7 @@ static inline

  int abortboot(int bootdelay)
  {
  
 int abort = 0;

 +   unsigned long ts;

  #ifdef CONFIG_MENUPROMPT
  
 printf(CONFIG_MENUPROMPT);

 @@ -248,11 +249,10 @@ int abortboot(int bootdelay)

  #endif
  
 while ((bootdelay  0)  (!abort)) {

 -   int i;
 -

 --bootdelay;

 -   /* delay 100 * 10ms */
 -   for (i=0; !abort  i100; ++i) {
 +   /* delay 1000 ms */
 +   ts = get_timer(0);
 +   do {

 if (tstc()) {   /* we got a key press   */
 
 abort  = 1; /* don't auto boot  */
 bootdelay = 0;  /* no more delay*/

 @@ -264,7 +264,7 @@ int abortboot(int bootdelay)

 break;
 
 }
 udelay(1);

 -   }
 +   } while (!abort  get_timer(ts)  1000);

 printf(\b\b\b%2d , bootdelay);
 
 }

 This change is causing problems with auto-delay on one of my boards by
 making it inaccurate :-(

 The question is what should get_timer() be returning? If it is meant to
 be milliseconds then I guess I need to fix get_timer() for my board.
 However, if it is just meant to be timer ticks at the SYS_HZ rate then I
 don't see how the above change guarantees the do-while loop waits 1000
 ms per iteration without normalising to SYS_HZ.
 
 What board is it ?

It is an OMAP2420-H4 board (ARM11). The timer is using a very odd SYS_HZ
value of ~46875 (I believe this is because this is the most they can
divide down the 12MHz clock source by). The timer could be switched to
use a 32kHz clock source instead of the 12MHz clock source and get
something closer to 1ms. However, I would need to test to see if this
causes any other problems.

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

Re: [U-Boot] [PATCH] Fix bootdelay timeout calculation when SYS_HZ!=1000

[Jon Hunter]

On 03/21/2013 09:41 AM, Tom Rini wrote:
 On Thu, Mar 21, 2013 at 03:35:40PM +0100, Wolfgang Denk wrote:
 Dear Tom,

 In message 514b1036.3090...@ti.com you wrote:

 A system with CONFIG_SYS_HZ != 1000 is _broken_.

 So, RPi is going higher, and Jon hit this on I suspect omap2420h4
 which is also higher (after mathing that all out).  If we no longer
 support CONFIG_SYS_HZ != 1000 we need to make that clear (and explain
 why).

 It has never been supported, so this is not a case of no longer.
 There are several longish threads (about the timer code, especially
 on ARM) in the archives.
 
 OK, then we need to do something about these platforms today.  I'm
 guessing RPi can just be tuned down to 1000 but for omap2420h4 it's an
 interesting value and I don't know about the platform well enough to say
 what we'd need to do to adapt it.  Jon?

For OMAP2420, we have a choice of using either a 12MHz or 32kHz clock to
drive the timer. With the 32kHz clock we can get close to 1000Hz tick
but we cannot get it dead on. That's why OMAP has been using 128Hz tick
in the kernel as opposed to 100Hz tick in the kernel for years (although
that was changed recently).

Cheers
Jon

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

Re: [U-Boot] [PATCH] Fix bootdelay timeout calculation when SYS_HZ!=1000

[Tom Rini]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 03/21/2013 11:25 AM, Jon Hunter wrote:
 
 On 03/21/2013 09:41 AM, Tom Rini wrote:
 On Thu, Mar 21, 2013 at 03:35:40PM +0100, Wolfgang Denk wrote:
 Dear Tom,
 
 In message 514b1036.3090...@ti.com you wrote:
 
 A system with CONFIG_SYS_HZ != 1000 is _broken_.
 
 So, RPi is going higher, and Jon hit this on I suspect
 omap2420h4 which is also higher (after mathing that all out).
 If we no longer support CONFIG_SYS_HZ != 1000 we need to make
 that clear (and explain why).
 
 It has never been supported, so this is not a case of no
 longer. There are several longish threads (about the timer
 code, especially on ARM) in the archives.
 
 OK, then we need to do something about these platforms today.
 I'm guessing RPi can just be tuned down to 1000 but for
 omap2420h4 it's an interesting value and I don't know about the
 platform well enough to say what we'd need to do to adapt it.
 Jon?
 
 For OMAP2420, we have a choice of using either a 12MHz or 32kHz
 clock to drive the timer. With the 32kHz clock we can get close to
 1000Hz tick but we cannot get it dead on. That's why OMAP has been
 using 128Hz tick in the kernel as opposed to 100Hz tick in the
 kernel for years (although that was changed recently).

The rest of the OMAP/related platforsm in U-Boot accept that as good
enough I guess since they've been setting to 1000 for a while / since
they went in (depending on the platform in particular).  So if you
have time to whack 2420 over and give it some quick testing I'd
appreciate it.  Thanks!

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

iQIcBAEBAgAGBQJRSycGAAoJENk4IS6UOR1WXIQQAIZOPSG04jMTavV8rBykXnjL
WQAvUmnGeAs7A2sMXfq+1HhXkLK/hMKHYR5IRLEx0asYuOXZ+sls9oPBxwpXHYQq
zMRcoEZRbWkz/Ell0Pe6gyN4LesCvTd+Zt+nV/Rs+oO0o3ITtqYOzTNOfaNwyftC
xXBUCXi9ecMnKhJb00IrAuELvU1kyb54v9tuJQNkw6ML0cWxTQiQFgzfMT8lRf/E
DwSaDxdQEi4+CzmXDE7VClx0P5R5GDd3NhtaQ8lz9w6mPoJ/GyFmYI4PIWAqsscO
ryRyrJlPx0KusmMZrtVMdBJqeXi4rU1vsrAqHsbntPWTt7WznyHOdELDtSoUbwHE
WotIW3+xqckNKNYjPYpWU1syRlWUqPK+wbHfB0bEVEtdPNQCBJ/jT34c/Ur4V7fn
aAJkhaimH/oWKtBiZD2hEUKZzsILrUpH0mk0S4xra5mHVDacypaeJ6xK1h0vkZTw
CoRHXH05JZlLJf1NXP3lRg/b8NUEH4Z/nGvQpmHUOySgPiGYs1CQx6f+3A8P2Rrd
W9TQ+fSWxtRzRUuHf18QdYFP5MCvWwgRuvquxsqlUAULzWYbisSb66TUY4vOyYZG
6htN9/wZEinsbmGlx6yTA6RBijSMP3kpSswwyN/Y1AHNP04MQO+Gflii9NvdtsRM
1jQ6as+M3YHCh7jAdINj
=yJ2h
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] musb: set MUSB speed based on CONFIG

[Bin Liu]

Do not config MUSB to highspeed mode if CONFIG_USB_GADGET_DUALSPEED
is not set, in which case Ether gadget only operates in fullspeed.

Reviewed-by: Tom Rini tr...@ti.com
Signed-off-by: Bin Liu b-...@ti.com
---
 drivers/usb/musb-new/musb_core.c  |2 ++
 drivers/usb/musb-new/musb_uboot.c |2 +-
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/musb-new/musb_core.c b/drivers/usb/musb-new/musb_core.c
index aa647e6..da93571 100644
--- a/drivers/usb/musb-new/musb_core.c
+++ b/drivers/usb/musb-new/musb_core.c
@@ -943,7 +943,9 @@ void musb_start(struct musb *musb)
 
/* put into basic highspeed mode and start session */
musb_writeb(regs, MUSB_POWER, MUSB_POWER_ISOUPDATE
+#ifdef CONFIG_USB_GADGET_DUALSPEED
| MUSB_POWER_HSENAB
+#endif
/* ENSUSPEND wedges tusb */
/* | MUSB_POWER_ENSUSPEND */
);
diff --git a/drivers/usb/musb-new/musb_uboot.c 
b/drivers/usb/musb-new/musb_uboot.c
index 096c4f4..ee3e6c5 100644
--- a/drivers/usb/musb-new/musb_uboot.c
+++ b/drivers/usb/musb-new/musb_uboot.c
@@ -174,7 +174,7 @@ int usb_gadget_register_driver(struct usb_gadget_driver 
*driver)
 {
int ret;
 
-   if (!driver || driver-speed  USB_SPEED_HIGH || !driver-bind ||
+   if (!driver || driver-speed  USB_SPEED_FULL || !driver-bind ||
!driver-setup) {
printf(bad parameter.\n);
return -EINVAL;
-- 
1.7.9.5

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

[U-Boot] [PATCH] musb: am335x: disable bulk split-combine feature

[Bin Liu]

On TI AM335x devices, MUSB has bulk split/combine feature enabled
in the ConfigData register, but the current MUSB driver does not
support it yet. Therefore, disable the feature for now, until the
driver adds the support.

One usecase which is broken because of this feature is that Ether
gadget stops working in Fullspeed mode (by un-defining
CONFIG_USB_GADGET_DUALSPEED)

After desabled this feature, MUSB driver send packets in proper size
(no more than 64 bytes) in Fullspeed mode.

This has been validated with Ether gadget in Fullspeed mode on AM335x
EVM.

Signed-off-by: Bin Liu b-...@ti.com
---
 drivers/usb/musb-new/musb_core.c |5 +
 include/configs/am335x_evm.h |1 +
 2 files changed, 6 insertions(+)

diff --git a/drivers/usb/musb-new/musb_core.c b/drivers/usb/musb-new/musb_core.c
index 040a5c0..aa647e6 100644
--- a/drivers/usb/musb-new/musb_core.c
+++ b/drivers/usb/musb-new/musb_core.c
@@ -1421,6 +1421,7 @@ static int __devinit musb_core_init(u16 musb_type, struct 
musb *musb)
strcat(aInfo, , dyn FIFOs);
musb-dyn_fifo = true;
}
+#ifndef CONFIG_MUSB_DISABLE_BULK_COMBINE_SPLIT
if (reg  MUSB_CONFIGDATA_MPRXE) {
strcat(aInfo, , bulk combine);
musb-bulk_combine = true;
@@ -1429,6 +1430,10 @@ static int __devinit musb_core_init(u16 musb_type, 
struct musb *musb)
strcat(aInfo, , bulk split);
musb-bulk_split = true;
}
+#else
+   musb-bulk_combine = false;
+   musb-bulk_split = false;
+#endif
if (reg  MUSB_CONFIGDATA_HBRXE) {
strcat(aInfo, , HB-ISO Rx);
musb-hb_iso_rx = true;
diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h
index 74a70ee..faf9581 100644
--- a/include/configs/am335x_evm.h
+++ b/include/configs/am335x_evm.h
@@ -450,6 +450,7 @@
 #define CONFIG_ARCH_MISC_INIT
 #define CONFIG_MUSB_GADGET
 #define CONFIG_MUSB_PIO_ONLY
+#define CONFIG_MUSB_DISABLE_BULK_COMBINE_SPLIT
 #define CONFIG_USB_GADGET_DUALSPEED
 #define CONFIG_USB_GADGET_VBUS_DRAW2
 #define CONFIG_MUSB_HOST
-- 
1.7.9.5

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

Re: [U-Boot] [PATCH] Fix bootdelay timeout calculation when SYS_HZ!=1000

[Stephen Warren]

On 03/21/2013 12:55 AM, Wolfgang Denk wrote:
 Dear Stephen Warren,
 
 In message 1363842874-8286-1-git-send-email-swar...@wwwdotorg.org you wrote:
 Commit b2f3e0e console: USB: KBD: Fix incorrect autoboot timeout
 re-wrote the bootdelay timeout loop. However, it hard-coded the value
 that get_delay() was expected to increment in one second, rather than
 calculating it based on CONFIG_SYS_HZ. On systems where SYS_HZ != 1000,
 this caused bootdelay timeout to be incorrect. Fix this.
 
 Are there any such systems left?  I agree with your patch, but if you
 know of systems that use incorrect values of CONFIG_SYS_HZ then please
 point these out so they can be fixed!
 
 A system with CONFIG_SYS_HZ != 1000 is _broken_.

Then why does the config option still exist; surely it should be
removed, or defined somewhere other than the per-board config file?

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

Re: [U-Boot] [PATCH] mmc: mx6qsabrelite: fsl_esdhc: Define maximum bus width supported by SabreLite board

[Eric Nelson]

Thanks Abbas,

On 03/20/2013 11:38 PM, Abbas Raza wrote:

From: Abbas Raza abbas_r...@mentor.com

Maximum bus width supported by SabreLite board is not 8bit like
all other mx6q specific boards. In case where both host controller
and card support 8bit transfers, they agree to communicate on 8bit
interface while boards like the SabreLite support only 4bit interface.
Due to this reason the mmc 8bit default mode fails on the SabreLite.
To rectify this, define maximum bus width supported by this board (4bit).
If max_bus_width is not defined, it is 0 by default and 8bit width support
will be enabled in host capabilities otherwise host capabilities are modified
accordingly.

It is tested with a MMCplus card.

Signed-off-by: Abbas Raza abbas_r...@mentor.com
cc: stefano Babic sba...@denx.de
cc: Andy Fleming aflem...@gmail.com
Acked-by: Dirk Behme dirk.be...@de.bosch.com
Acked-by: Andrew Gabbasov andrew_gabba...@mentor.com
---
  board/freescale/mx6qsabrelite/mx6qsabrelite.c | 3 +++
  drivers/mmc/fsl_esdhc.c   | 7 +++
  include/fsl_esdhc.h   | 1 +
  3 files changed, 11 insertions(+)



Tested-by: Eric Nelson eric.nel...@boundarydevices.com

Note that the board settings also apply to nitrogen6x and wandboard
if you want to expand the patch a bit:


http://git.denx.de/u-boot.git/?p=u-boot/u-boot-imx.git;a=blob;f=board/boundary/nitrogen6x/nitrogen6x.c;h=229c2378396d43a365d6682af35c0e519ccd69d4;hb=HEAD#l304

http://git.denx.de/u-boot.git/?p=u-boot/u-boot-imx.git;a=blob;f=board/wandboard/wandboard.c;h=d95189f77de4c3573ec30c53e04fe1b083c1d2b5;hb=HEAD#l107

I also tested against a custom board with 8-bit eMMC.

Regards,


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

Re: [U-Boot] [PATCH 1/2] ARM: implement erratum 716044 workaround

[Tom Warren]

Albert,

 -Original Message-
 From: Stephen Warren [mailto:swar...@wwwdotorg.org]
 Sent: Monday, March 04, 2013 4:30 PM
 To: u-boot@lists.denx.de; Albert Aribaud
 Cc: Simon Glass; Tom Warren; Stephen Warren
 Subject: [PATCH 1/2] ARM: implement erratum 716044 workaround

This patchset from Stephen (includes 2/2 ARM: tegra: enable workaround for ARM 
erratum 716044) are both assigned to you in PatchWork, but haven't been 
applied yet to ARM/master AFAICT. I found them when I was searching for 
unapplied Tegra patches.

Could you please take this in thru the ARM tree ASAP?

Thanks,

Tom
 
 From: Stephen Warren swar...@nvidia.com
 
 Add common code to enable the workaround for ARM erratum 716044. This
 will be enabled for Tegra.
 
 Signed-off-by: Stephen Warren swar...@nvidia.com
 ---
 This depends on my previous ARM errata series. I found out we needed
 another one after I wrote the first series.
 
  README |1 +
  arch/arm/cpu/armv7/start.S |6 ++
  2 files changed, 7 insertions(+)
 
 diff --git a/README b/README
 index f2b1c88..97ef9f0 100644
 --- a/README
 +++ b/README
 @@ -485,6 +485,7 @@ The following options need to be configured:
   Thumb2 this flag will result in Thumb2 code generated by
   GCC.
 
 + CONFIG_ARM_ERRATA_716044
   CONFIG_ARM_ERRATA_742230
   CONFIG_ARM_ERRATA_743622
   CONFIG_ARM_ERRATA_751472
 diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S index
 30f02d3..6834ffe 100644
 --- a/arch/arm/cpu/armv7/start.S
 +++ b/arch/arm/cpu/armv7/start.S
 @@ -310,6 +310,12 @@ ENTRY(cpu_init_cp15)  #endif
   mcr p15, 0, r0, c1, c0, 0
 
 +#ifdef CONFIG_ARM_ERRATA_716044
 + mrc p15, 0, r0, c1, c0, 0   @ read system control register
 + orr r0, r0, #1  11@ set bit #11
 + mcr p15, 0, r0, c1, c0, 0   @ write system control register
 +#endif
 +
  #ifdef CONFIG_ARM_ERRATA_742230
   mrc p15, 0, r0, c15, c0, 1  @ read diagnostic register
   orr r0, r0, #1  4 @ set bit #4
 --
 1.7.10.4
--
nvpublic

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

Re: [U-Boot] [PATCH 1/8] patman: Fix up checkpatch parsing to deal with 'CHECK' lines

[Doug Anderson]

Simon,

On Wed, Mar 20, 2013 at 7:42 PM, Simon Glass s...@chromium.org wrote:
 checkpatch has a new type of warning, a 'CHECK'. At present patman fails
 with these, which makes it less than useful.

 Add support for checks, making it backwards compatible with the old
 checkpatch.

There are also a few other minor fixups in this:
* Cleanup formatting of the CheckPatches() output.
* Fix erroneous internal error if multiple patches have warnings.
* Be more robust to new types of problems.


 @@ -64,10 +64,14 @@ def CheckPatch(fname, verbose=False):
  'msg': text message
  'file' : filename
  'line': line number
 +error_count: Number of errors
 +warning_count: Number of warnings
 +check_count: Number of checks
  lines: Number of lines
 +stdout: Full output of checkpatch

nit: Right above this it says you're returning a 4-tuple.  That's no
longer true.  Could just remove the 4-.

optional: I've found that returning big tuples like this is
problematic.  Whenever you change the number of things returned you've
got to modify any callers that call like:

a, b, c, d = CheckPatch(...)

to now be:

a, b, c, d, e = CheckPatch(...)

...or never use the above syntax and use:

result = CheckPatch(...)
blah = result[0]

Maybe use a namedtuple so that callers can use the result more cleanly?


  if match:
  error_count = int(match.group(1))
  warning_count = int(match.group(2))
 -lines = int(match.group(3))
 +match_count = int(match.group(3))
 +if len(match.groups()) == 4:
 +   check_count = match_count
 +   lines = int(match.group(4))

I'm confused about match_count here.  What is it supposed to contain?
I can't tell from the name of it.  It looks like a temporary variable
holding either check_count or lines.  ...but you forget to assign
lines = match_count in an else case so things are broken with old
versions of checkpatch, right?


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

Re: [U-Boot] [PATCH] Exynos5: clock: Fix a typo bug in exynos clock init

[Simon Glass]

On Thu, Mar 21, 2013 at 5:13 AM, Akshay Saraswat aksha...@samsung.com wrote:
 We intended to clear the bits of CLK_SRC_TOP2 register, instead we were
 writing on the reserved bits of src_core1 register. Since the default
 value of clk_src_top2 register were itself zero, this typo was not
 creating any big issue. But it is better to fix this error for better
 readability of the code.

 Signed-off-by: Hatim Ali hatim...@samsung.com
 Signed-off-by: Akshay Saraswat aksha...@samsung.com

Acked-by: Simon Glass s...@chromium.org
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/8] patman: Don't look for tags inside quotes

[Doug Anderson]

Simon,

On Wed, Mar 20, 2013 at 7:42 PM, Simon Glass s...@chromium.org wrote:
  # Separates a tag: at the beginning of the subject from the rest of it
 -re_subject_tag = re.compile('([^:]*):\s*(.*)')
 +re_subject_tag = re.compile('([^:]*):\s*(.*)')

I'd go further and prevent all spaces.
  re_subject_tag = re.compile('([^:\s]*):\s*(.*)')

I ran into a similar problem with my patch I sent up earlier:

  patman: Add Cover-letter-cc: tag to Cc cover letter to people

I fixed that by removing the extra colon, but that was sorta lame.
We shouldn't have tags with spaces in them anyway...

  patman: Add Cover-letter-cc tag to Cc cover letter to people


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

[U-Boot] U-Boot mini-summit at ELCE 2013 in Edinburgh - call for participation!

[Detlev Zundel]

Hi fellow U-Boot developers,

people meeting us at our booth at the Embedded World trade show in
Nürnberg this year may already have heard rumours about it but now it is
official - there will be an U-Boot mini-summit at the Emdedd Linux
Conference Europe in Edinburgh, UK [1].

Thanks to the wonderful people at the Linux Foundation, we will have
some space in the afternoon of thursday 24th that we can use to present
and discuss topics of interest for the immediate future of the project.

Currently we believe that it makes sense to plan for 4-5 short talks in
the range of 20-30 minutes with following QA.  The audience will very
likely be tech level and the presentations are thus allowed to have
indecent technical content :)

Of course everybody is invited to suggest a presentation, but an
informal poll turned up these topics of interest:

- Driver model
- Kconfig
- Patman tutorial
- U-Boot configuration through device tree
- Falcon boot for everybody
- DFU
- Android fastboot

The organization of the mini-summit is up to our discretion and thus
somewhat less formal than the regular ELCE tracks, but we would like
to encourage people to also submit U-Boot related talks through the
regular CFP[2] if they are of wide interest.

Having agreed on our schedule, we will be able to get it included in the
official conference schedule and thus hopefully get a broader
visibility.  To make this work we should finalize our schedule around
the end of the official CFP which is July 21st, but of course the
sooner, the better.

Please inform us if you would like to attend in order to get an idea
of the expected presence.  If neccessary we will have to look for a
larger place early on.

Next to the official program I'm sure that we will be able to find a
place in the evening to taste local culinary specialities (in solid and
liquid form), so be sure to book your return flight no sooner than
friday evening ;)

Thanks
  Detlev

[1] http://events.linuxfoundation.org/events/embedded-linux-conference-europe
[2] 
http://events.linuxfoundation.org/events/embedded-linux-conference-europe/cfp

-- 
The only thing worse than generalizing from one example is generalizing
from no examples at all.
--
DENX Software Engineering GmbH,  MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/8] patman: Minor help message/README fixes

[Doug Anderson]

Simon,

On Wed, Mar 20, 2013 at 7:42 PM, Simon Glass s...@chromium.org wrote:
 A few of the help messages are not quite right, and there is a typo
 in the README. Fix these.

 Signed-off-by: Simon Glass s...@chromium.org
 ---
  tools/patman/README| 2 +-
  tools/patman/patman.py | 4 ++--
  2 files changed, 3 insertions(+), 3 deletions(-)

Reviewed-by: Doug Anderson diand...@chromium.org
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 4/8] patman: Fix the comment in CheckTags to mention multiple tags

[Doug Anderson]

Simon,

On Wed, Mar 20, 2013 at 7:42 PM, Simon Glass s...@chromium.org wrote:
 This comment is less than helpful. Since multiple tags are supported, add
 an example of how multiple tags work.

 Signed-off-by: Simon Glass s...@chromium.org
 ---
  tools/patman/commit.py | 5 +++--
  1 file changed, 3 insertions(+), 2 deletions(-)

Reviewed-by: Doug Anderson diand...@chromium.org
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 1/7] cros: add cros_ec driver

[Simon Glass]

On Mon, Mar 18, 2013 at 9:22 AM, Hung-ying Tyan ty...@chromium.org wrote:
 This patch adds the cros_ec driver that implements the protocol for
 communicating with Google's ChromeOS embedded controller.

 Signed-off-by: Bernie Thompson bhthomp...@chromium.org
 Signed-off-by: Bill Richardson wfric...@chromium.org
 Signed-off-by: Che-Liang Chiou clch...@chromium.org
 Signed-off-by: Doug Anderson diand...@chromium.org
 Signed-off-by: Gabe Black gabebl...@chromium.org
 Signed-off-by: Hung-ying Tyan ty...@chromium.org
 Signed-off-by: Louis Yung-Chieh Lo yj...@chromium.org
 Signed-off-by: Randall Spangler rspang...@chromium.org
 Signed-off-by: Sean Paul seanp...@chromium.org
 Signed-off-by: Simon Glass s...@chromium.org
 Signed-off-by: Vincent Palatin vpala...@chromium.org

Acked-by: Simon Glass s...@chromium.org
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 2/7] cros: add I2C support for cros_ec

[Simon Glass]

On Mon, Mar 18, 2013 at 9:22 AM, Hung-ying Tyan ty...@chromium.org wrote:
 This patch adds I2C support for carrying out the cros_ec protocol.

 Signed-off-by: Randall Spangler rspang...@chromium.org
 Signed-off-by: Simon Glass s...@chromium.org
 Signed-off-by: Hung-ying Tyan ty...@chromium.org

 ---
 Changes in v2:
 - Wrapped lines to comply with the 80-char rule.

  drivers/misc/Makefile  |   1 +
  drivers/misc/cros_ec_i2c.c | 199 
 +
  2 files changed, 200 insertions(+)
  create mode 100644 drivers/misc/cros_ec_i2c.c

Acked-by: Simon Glass s...@chromium.org
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 3/7] cros: add SPI support for cros_ec

[Simon Glass]

On Mon, Mar 18, 2013 at 9:22 AM, Hung-ying Tyan ty...@chromium.org wrote:
 This patch adds SPI support for carrying out the cros_ec protocol.

 Signed-off-by: Hung-ying Tyan ty...@chromium.org
 Signed-off-by: Randall Spangler rspang...@chromium.org
 Signed-off-by: Simon Glass s...@chromium.org

 ---
 Changes in v2:
 - Wrapped lines to comply with the 80-char rule.

Acked-by: Simon Glass s...@chromium.org
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 4/7] cros: add LPC support for cros_ec

[Simon Glass]

On Mon, Mar 18, 2013 at 9:22 AM, Hung-ying Tyan ty...@chromium.org wrote:
 This patch adds LPC support for carrying out the cros_ec protocol.

 Signed-off-by: Randall Spangler rspang...@chromium.org
 Signed-off-by: Simon Glass s...@chromium.org
 Signed-off-by: Hung-ying Tyan ty...@chromium.org

 ---
 Changes in v2:
 - Wrapped lines to comply with the 80-char rule.

Acked-by: Simon Glass s...@chromium.org
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] spl_mmc: cleanup variable types

[Tom Rini]

On Thu, Mar 21, 2013 at 03:55:17PM +0100, Peter Korsgaard wrote:

 block_read returns unsigned long, so it doesn't make sense to check for
  0. and neither does marking the header structure as const and then
 casting away the constness to load data into it.
 
 Also cleanup some unneeded pointer casting while we're at it.
 
 Signed-off-by: Peter Korsgaard peter.korsga...@barco.com

Reviewed-by: Tom Rini tr...@ti.com

-- 
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 5/7] cros: adds cros_ec keyboard driver

[Simon Glass]

Hi Hung-ying,

On Mon, Mar 18, 2013 at 9:22 AM, Hung-ying Tyan ty...@chromium.org wrote:
 This patch adds the driver for keyboard that's controlled by ChromeOS EC.

 Signed-off-by: Randall Spangler rspang...@chromium.org
 Signed-off-by: Simon Glass s...@chromium.org
 Signed-off-by: Vincent Palatin vpala...@chromium.org
 Signed-off-by: Hung-ying Tyan ty...@chromium.org

 ---
 Changes in v2:
 - Wrapped lines to comply with the 80-char rule.

  README   |   5 +
  drivers/input/Makefile   |   1 +
  drivers/input/cros_ec_keyb.c | 264 
 +++
  include/fdtdec.h |   1 +
  lib/fdtdec.c |   1 +
  5 files changed, 272 insertions(+)
  create mode 100644 drivers/input/cros_ec_keyb.c

 diff --git a/README b/README
 index 42544ce..769d1bf 100644
 --- a/README
 +++ b/README
 @@ -1371,6 +1371,11 @@ CBFS (Coreboot Filesystem) support
 Export function i8042_kbd_init, i8042_tstc and i8042_getc
 for cfb_console. Supports cursor blinking.

 +   CONFIG_CROS_EC_KEYB
 +   Enables a Chrome OS keyboard using the CROS_EC interface.
 +   This uses CROS_EC to communicate with a second microcontroller
 +   which provides key scans on request.
 +
  - Video support:
 CONFIG_VIDEO

 diff --git a/drivers/input/Makefile b/drivers/input/Makefile
 index 0805e86..4331190 100644
 --- a/drivers/input/Makefile
 +++ b/drivers/input/Makefile
 @@ -27,6 +27,7 @@ LIB   := $(obj)libinput.o

  COBJS-$(CONFIG_I8042_KBD) += i8042.o
  COBJS-$(CONFIG_TEGRA_KEYBOARD) += tegra-kbc.o
 +COBJS-$(CONFIG_CROS_EC_KEYB) += cros_ec_keyb.o
  ifdef CONFIG_PS2KBD
  COBJS-y += keyboard.o pc_keyb.o
  COBJS-$(CONFIG_PS2MULT) += ps2mult.o ps2ser.o
 diff --git a/drivers/input/cros_ec_keyb.c b/drivers/input/cros_ec_keyb.c
 new file mode 100644
 index 000..21fab15
 --- /dev/null
 +++ b/drivers/input/cros_ec_keyb.c
 @@ -0,0 +1,264 @@
 +/*
 + * Chromium OS Matrix Keyboard
 + *
 + * Copyright (c) 2012 The Chromium OS Authors.
 + * See file CREDITS for list of people who contributed to this
 + * project.
 + *
 + * This program is free software; you can redistribute it and/or
 + * modify it under the terms of the GNU General Public License as
 + * published by the Free Software Foundation; either version 2 of
 + * the License, or (at your option) any later version.
 + *
 + * This program is distributed in the hope that it will be useful,
 + * but WITHOUT ANY WARRANTY; without even the implied warranty of
 + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
 + * GNU General Public License for more details.
 + *
 + * You should have received a copy of the GNU General Public License
 + * along with this program; if not, write to the Free Software
 + * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
 + * MA 02111-1307 USA
 + */
 +
 +#include common.h
 +#include fdtdec.h
 +#include input.h
 +#include key_matrix.h
 +#include cros_ec.h

Please put this after common.h so it is in alphabetical order.

 +#include stdio_dev.h
 +
 +DECLARE_GLOBAL_DATA_PTR;
 +
 +enum {
 +   KBC_MAX_KEYS= 8,/* Maximum keys held down at once */
 +};
 +
 +static struct keyb {
 +   struct cros_ec_dev *dev;/* The CROS_EC device */
 +   struct input_config input;  /* The input layer */
 +   struct key_matrix matrix;   /* The key matrix layer */
 +   int key_rows;   /* Number of keyboard rows */
 +   int key_cols;   /* Number of keyboard columns */
 +   unsigned int repeat_delay_ms;   /* Time before autorepeat starts */
 +   unsigned int repeat_rate_ms;/* Autorepeat rate in ms */
 +   int ghost_filter;   /* 1 to enable ghost filter, else 0 */
 +   int inited; /* 1 if keyboard is ready */
 +} config;
 +
 +
 +/**
 + * Check the keyboard controller and return a list of key matrix positions
 + * for which a key is pressed
 + *
 + * @param config   Keyboard config
 + * @param keys List of keys that we have detected
 + * @param max_countMaximum number of keys to return
 + * @return number of pressed keys, 0 for none
 + */
 +static int check_for_keys(struct keyb *config,
 +  struct key_matrix_key *keys, int max_count)
 +{
 +   struct key_matrix_key *key;
 +   struct mbkp_keyscan scan;
 +   unsigned int row, col, bit, data;
 +   int num_keys;
 +
 +   if (cros_ec_scan_keyboard(config-dev, scan)) {
 +   debug(%s: keyboard scan failed\n, __func__);
 +   return -1;
 +   }
 +
 +   /* TODO(sjg@chromium,org): Should perhaps optimize this algorithm */

I think we can remove this TODO now.

 +   for (col = num_keys = bit = 0; col  config-matrix.num_cols;
 +   col++) {
 +   for (row = 0; row  config-matrix.num_rows; row++) {
 +   unsigned 

Re: [U-Boot] [PATCH 5/8] patman: Provide option to ignore bad aliases

[Doug Anderson]

Simon,

Nothing critical and this could go in as-is, but a few nits below.


On Wed, Mar 20, 2013 at 7:42 PM, Simon Glass s...@chromium.org wrote:
 -raw += LookupEmail(item, alias)
 +raw += LookupEmail(item, alias, raise_on_error=not ignore_errors)

optional: Change it so functions are consistent about whether it's
raise_on_error or ignore_errors


 + EmailPatches(series, 'cover', ['p1', 'p2'], True, False, 'cc-fname', 
 \
 +False, alias)

Doctest that actually tests the raise_on_error?  See doctests in
gitutil.py for example syntax.


 -def LookupEmail(lookup_name, alias=None, level=0):
 +def LookupEmail(lookup_name, alias=None, raise_on_error=True, level=0):
  If an email address is an alias, look it up and return the full name

  TODO: Why not just use git's own alias feature?

  Args:
  lookup_name: Alias or email address to look up
 +alias: Dictionary containing aliases (None to use settings default)
 +raise_on_error: True to raise an error when an alias fails to match

...and what happens if you pass False?


 + LookupEmail('odd', alias, False)
 +\033[1;31mAlias 'odd' not found\033[0m
 +[]
 + # In this case the loop part will effectively be ignored.
 + LookupEmail('loop', alias, False)
 +\033[1;31mRecursive email alias at 'other'\033[0m
 +\033[1;31mRecursive email alias at 'john'\033[0m
 +\033[1;31mRecursive email alias at 'mary'\033[0m
 +['j.blo...@napier.co.nz', 'm.popp...@cloud.net']

optional nit: for optional args it's nice to specify them with keywords, like
   LookupEmail('loop', alias=alias, raise_on_error=False)

Please test the raise_on_error=True case.


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

Re: [U-Boot] [PATCH 6/8] patman: Add -a option to refrain from test-applying the patches

[Doug Anderson]

Simon,

On Wed, Mar 20, 2013 at 7:42 PM, Simon Glass s...@chromium.org wrote:
 Especially with the Linux kernel, it takes a long time (a minute or more)
 to test-apply the patches, so patman becomes significantly less useful.
 The only real problem that is found with this apply step is trailing spaces.
 Provide a -a option to skip this step, for those working with clean patches.

 Signed-off-by: Simon Glass s...@chromium.org
 ---
  tools/patman/patman.py | 10 +++---
  1 file changed, 7 insertions(+), 3 deletions(-)

Reviewed-by: Doug Anderson diand...@chromium.org
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 6/7] cros: exynos: add cros-ec device nodes to exynos5250-snow.dts

[Simon Glass]

Hi Hung-ying,

On Mon, Mar 18, 2013 at 9:22 AM, Hung-ying Tyan ty...@chromium.org wrote:
 Signed-off-by: Hung-ying Tyan ty...@chromium.org

 ---
 Changes in v2:
 - Add gpio node to exynos5250.dtsi.


Acked-by: Simon Glass s...@chromium.org

This looks right to me. I think we will need to revisit the GPIO
numbers when the exynos GPIO numbering series lands, but for now it
looks right.

  arch/arm/dts/exynos5250.dtsi  |  3 ++
  board/samsung/dts/exynos5250-snow.dts | 82 
 +++
  2 files changed, 85 insertions(+)


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

Re: [U-Boot] [PATCH 8/8] patman: Add Series-process-log tag to sort/uniq change logs

[Doug Anderson]

Simon,

On Wed, Mar 20, 2013 at 7:43 PM, Simon Glass s...@chromium.org wrote:
 For some series with lots of changes it is annoying that duplicate change
 log items are not caught. It is also helpful sometimes to sort the change
 logs.

 Add a Series-process-log tag to enable this, which can be placed in a
 commit to control this.

 The change to the Cc: line is to fix a checkpatch warning.

 Signed-off-by: Simon Glass s...@chromium.org
 ---
  tools/patman/README | 8 +++-
  tools/patman/patchstream.py | 2 +-
  tools/patman/series.py  | 8 ++--
  3 files changed, 14 insertions(+), 4 deletions(-)

Not sure I'd find this terribly useful myself, but I don't see
anything wrong with it.  I think my change log items tend to be more
than one line long for one...

 +if not ('uniq' in process_it and text in out):

optional: My brain had a hard time processing this.  I did the logic
transformation myself:

  if 'uniq' not in process_it or text not in out:


Also: Do you really want the process_it to be so free-form?  That
seems like it might be asking for disaster.  Why not specify that it's
comma-separated and be done.

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

Re: [U-Boot] [PATCH 1/2] ARM: implement erratum 716044 workaround

[Albert ARIBAUD]

Hi Tom,

On Thu, 21 Mar 2013 09:29:14 -0700, Tom Warren twar...@nvidia.com
wrote:

 Albert,
 
  -Original Message-
  From: Stephen Warren [mailto:swar...@wwwdotorg.org]
  Sent: Monday, March 04, 2013 4:30 PM
  To: u-boot@lists.denx.de; Albert Aribaud
  Cc: Simon Glass; Tom Warren; Stephen Warren
  Subject: [PATCH 1/2] ARM: implement erratum 716044 workaround
 
 This patchset from Stephen (includes 2/2 ARM: tegra: enable workaround for 
 ARM erratum 716044) are both assigned to you in PatchWork, but haven't been 
 applied yet to ARM/master AFAICT. I found them when I was searching for 
 unapplied Tegra patches.
 
 Could you please take this in thru the ARM tree ASAP?

Will take them in later today. Want an ARM PR once done?

 Thanks,
 
 Tom

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

Re: [U-Boot] [RFC] command/cache: Add flush_cache command

[Albert ARIBAUD]

Hi Scott,

On Wed, 20 Mar 2013 17:35:51 -0500, Scott Wood
scottw...@freescale.com wrote:

 On 03/20/2013 05:11:57 PM, Albert ARIBAUD wrote:
  Hi Scott,
  
  On Wed, 20 Mar 2013 14:36:05 -0500, Scott Wood
  scottw...@freescale.com wrote:
  
   On 03/20/2013 02:15:19 PM, Tom Rini wrote:
On Wed, Mar 20, 2013 at 11:43:15AM -0500, Scott Wood wrote:
 On 03/20/2013 09:58:36 AM, Wolfgang Denk wrote:
 Dear Albert,
 
 In message 20130320145927.2031b913@lilith you wrote:
 
  I do understand what it does, but I still don't get why it
should be
  done, since precisely payload control transfer happens  
  through
 bootm and
  the like which already properly flush cache.

 It doesn't always happen through bootm.  Standalone apps use the
 go command.
   
So, to try and be a bit more verbose about this, for U-Boot
applications
which use 'go', we still need to ensure cache coherence, which is  
  why
bootm does a cache flush, we need some way to flush in this case.
  
   It's also an issue with using the cpu n release command.
  
And in this case you aren't better served by say bootelf ?
  
   That wouldn't handle the cpu release case.  In any case, go  
  exists
   and is currently the recommended way to launch a standalone  
  application
   in doc/README.standalone.
  
 It's a user command!  How can it be dead code?  I don't know of  
  a
 way to include a human user in a patchset...
   
Can you hightlight what exactly causes the world today to go off  
  and
fail?  Is the hello_world example app sufficient in this case or  
  do we
need something much larger?
  
   A user inside Freescale is running standalone performance test apps,
   using both go and cpu n release (since the test needs to run  
  on
   all CPUs).  They are seeing cache problems running on a T4240 if  
  they
   don't have this flush.  This flush is architecturally required  
  between
   modifying/loading code and running it.
  
  Still, why make it a shell command? Since this user needs a flush with
  go and cpu release, then we should add a programmatic global cache
  flush in the go and cpu release commands.
 
 Why add any new commands?  They could all be subcommands of bootm! :-)

I did not say subcommand, I said programmatic -- precisely, I don't
like the idea that a specific command or command form is needed to
avoid a situation that can be avoided automatically.

 Really, instead of adding one command, you want to modify *two*  
 commands to do the same thing separately, which involves changing the  
 syntax of both commands to accept memory range information?

There is no need to change any syntax.

 -Scott

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

Re: [U-Boot] [PATCH] Fix bootdelay timeout calculation when SYS_HZ!=1000

[Jon Hunter]

On 03/21/2013 10:28 AM, Tom Rini wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 On 03/21/2013 11:25 AM, Jon Hunter wrote:

 On 03/21/2013 09:41 AM, Tom Rini wrote:
 On Thu, Mar 21, 2013 at 03:35:40PM +0100, Wolfgang Denk wrote:
 Dear Tom,

 In message 514b1036.3090...@ti.com you wrote:

 A system with CONFIG_SYS_HZ != 1000 is _broken_.

 So, RPi is going higher, and Jon hit this on I suspect
 omap2420h4 which is also higher (after mathing that all out).
 If we no longer support CONFIG_SYS_HZ != 1000 we need to make
 that clear (and explain why).

 It has never been supported, so this is not a case of no
 longer. There are several longish threads (about the timer
 code, especially on ARM) in the archives.

 OK, then we need to do something about these platforms today.
 I'm guessing RPi can just be tuned down to 1000 but for
 omap2420h4 it's an interesting value and I don't know about the
 platform well enough to say what we'd need to do to adapt it.
 Jon?

 For OMAP2420, we have a choice of using either a 12MHz or 32kHz
 clock to drive the timer. With the 32kHz clock we can get close to
 1000Hz tick but we cannot get it dead on. That's why OMAP has been
 using 128Hz tick in the kernel as opposed to 100Hz tick in the
 kernel for years (although that was changed recently).
 
 The rest of the OMAP/related platforsm in U-Boot accept that as good
 enough I guess since they've been setting to 1000 for a while / since
 they went in (depending on the platform in particular).  So if you
 have time to whack 2420 over and give it some quick testing I'd
 appreciate it.  Thanks!

Looks like the OMAP timers are running faster than 1000Hz but the timer
tick rate is being normalised to 1000Hz by dividing the actual timer
rate by SYS_HZ. I see ...

readl(timer_base-tcrr) / (TIMER_CLOCK / CONFIG_SYS_HZ);

We could do the same for OMAP2420. In fact we could move
arch/arm/cpu/armv7/omap-common/timer.c to arch/arm/omap-common/timer.c
and use this for OMAP2420. The legacy OMAP2420 code is very similar to this.

Jon


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

Re: [U-Boot] [RFC] command/cache: Add flush_cache command

[Scott Wood]

On 03/21/2013 12:58:37 PM, Albert ARIBAUD wrote:

Hi Scott,

On Wed, 20 Mar 2013 17:35:51 -0500, Scott Wood
scottw...@freescale.com wrote:

 On 03/20/2013 05:11:57 PM, Albert ARIBAUD wrote:
  Hi Scott,
 
  On Wed, 20 Mar 2013 14:36:05 -0500, Scott Wood
  scottw...@freescale.com wrote:
 
   On 03/20/2013 02:15:19 PM, Tom Rini wrote:
On Wed, Mar 20, 2013 at 11:43:15AM -0500, Scott Wood wrote:
 On 03/20/2013 09:58:36 AM, Wolfgang Denk wrote:
 Dear Albert,
 
 In message 20130320145927.2031b913@lilith you wrote:
 
  I do understand what it does, but I still don't get why  
it

should be
  done, since precisely payload control transfer happens
  through
 bootm and
  the like which already properly flush cache.

 It doesn't always happen through bootm.  Standalone apps  
use the

 go command.
   
So, to try and be a bit more verbose about this, for U-Boot
applications
which use 'go', we still need to ensure cache coherence,  
which is

  why
bootm does a cache flush, we need some way to flush in this  
case.

  
   It's also an issue with using the cpu n release command.
  
And in this case you aren't better served by say bootelf ?
  
   That wouldn't handle the cpu release case.  In any case, go
  exists
   and is currently the recommended way to launch a standalone
  application
   in doc/README.standalone.
  
 It's a user command!  How can it be dead code?  I don't  
know of

  a
 way to include a human user in a patchset...
   
Can you hightlight what exactly causes the world today to go  
off

  and
fail?  Is the hello_world example app sufficient in this case  
or

  do we
need something much larger?
  
   A user inside Freescale is running standalone performance test  
apps,
   using both go and cpu n release (since the test needs to  
run

  on
   all CPUs).  They are seeing cache problems running on a T4240 if
  they
   don't have this flush.  This flush is architecturally required
  between
   modifying/loading code and running it.
 
  Still, why make it a shell command? Since this user needs a flush  
with
  go and cpu release, then we should add a programmatic global  
cache

  flush in the go and cpu release commands.

 Why add any new commands?  They could all be subcommands of bootm!  
:-)


I did not say subcommand, I said programmatic -- precisely, I  
don't

like the idea that a specific command or command form is needed to
avoid a situation that can be avoided automatically.


bootm subcommands are programmatic in normal use cases.


 Really, instead of adding one command, you want to modify *two*
 commands to do the same thing separately, which involves changing  
the

 syntax of both commands to accept memory range information?

There is no need to change any syntax.


Then how would we know what range to flush?

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

Re: [U-Boot] [RFC] command/cache: Add flush_cache command

[Scott Wood]

On 03/21/2013 08:37:32 AM, Wolfgang Denk wrote:

Dear Tom,

In message 20130321122923.GB26945@bill-the-cat you wrote:

  Not really. Only a tiny fraction of users will ever run any  
standalone

  applications, so please let's save the memory footprint for the
  overwhelming majority of users who do not need that.

 Well, can we run into this problem on ARM (v7 or v8) systems as  
well?


Probably.

But I wonder what the exact usage szenario is that will trigger the
problem.  If I understand correctly, this can only happen when you
perform a (manual) memory copy (either between different locations in
RAM, or from parallel NOR flash to RAM) of the code you are going to
run.


Yes, the person who is seeing this problem is copying code from flash  
to RAM.



As far as I understand all other ways to load any such code (over the
network or from storage devices) already make sure to run  
flush_cache()

after any such load operation.


A lot of places seem to have it, but it seems not everywhere.  I'm not  
aware of such a flush for NAND reads.


We could instead try to make sure everything, including commands like  
cp and mm, flush cache when they're done.  This approach is more  
user friendly, though it has a higher risk of missing some code path.



Scott: is my understanding correct that you only need this because
you are performing such memory copy ops manually?  From where / to
where are you copying, and why?


As above it's from flash (I assume NOR) to RAM.  The why is to be  
able to run the code from RAM. :-P



Thinking about alternatives:

- eventually we should discourage the use of go; it may be
  conveniend when you know what you are doing, but if it's casuing
  such problems we might be better off recommending to use
  proper IH_TYPE_STANDALONE legacy images in combination with the
  bootm command instead.


That or bootelf, sure.  I think there still should be some way to do it  
manually, though.  bootm/bootelf probably wouldn't work for this use  
case because it involves releasing other cores after the image is  
copied/flushed, but before u-boot gives up control on the boot core.



- Also, instead of adding a new command, this could probably be
  scripted; I guess this should be roughly equivalent?

setenv flush_cache 'dc off;ic off;dc on;ic on'


This assumes that we support those cache operations, that they affect  
all relevant caches (on 85xx it only flushes L1, but at least on newer  
chips L2 is relevant as well), and that there are no errata or  
architectural limitations to running with caches off.


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

Re: [U-Boot] [PATCH 1/2] ARM: implement erratum 716044 workaround

[Tom Warren]

Albert,

 -Original Message-
 From: Albert ARIBAUD [mailto:albert.u.b...@aribaud.net]
 Sent: Thursday, March 21, 2013 10:56 AM
 To: Tom Warren
 Cc: u-boot@lists.denx.de; Simon Glass; Stephen Warren; Tom Warren;
 Stephen Warren
 Subject: Re: [PATCH 1/2] ARM: implement erratum 716044 workaround
 
 Hi Tom,
 
 On Thu, 21 Mar 2013 09:29:14 -0700, Tom Warren twar...@nvidia.com
 wrote:
 
  Albert,
 
   -Original Message-
   From: Stephen Warren [mailto:swar...@wwwdotorg.org]
   Sent: Monday, March 04, 2013 4:30 PM
   To: u-boot@lists.denx.de; Albert Aribaud
   Cc: Simon Glass; Tom Warren; Stephen Warren
   Subject: [PATCH 1/2] ARM: implement erratum 716044 workaround
 
  This patchset from Stephen (includes 2/2 ARM: tegra: enable workaround
 for ARM erratum 716044) are both assigned to you in PatchWork, but
 haven't been applied yet to ARM/master AFAICT. I found them when I was
 searching for unapplied Tegra patches.
 
  Could you please take this in thru the ARM tree ASAP?
 
 Will take them in later today. Want an ARM PR once done?
Just a notice that they're in TOT u-boot-arm/master, and I'll rebase 
u-boot-tegra/next against it.

Thanks,

Tom
 
  Thanks,
 
  Tom
 
 Amicalement,
 --
 Albert.
--
nvpublic

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

Re: [U-Boot] [RFC] command/cache: Add flush_cache command

[Scott Wood]

On 03/21/2013 12:02:23 AM, Sricharan R wrote:

On Thursday 21 March 2013 06:01 AM, Scott Wood wrote:
 On 03/20/2013 07:27:29 PM, Michael Cashwell wrote:
 On Mar 20, 2013, at 7:48 PM, Scott Wood scottw...@freescale.com  
wrote:


  On 03/20/2013 06:33:41 PM, Michael Cashwell wrote:
 
  What is the purpose of limiting the memory range to be flushed?  
Is there a reason one might want to NOT flush certain data sitting in  
a dirty cache line out to memory before doing a go or boot command?

 
  Because it would take a while to flush all of RAM?

 Flushing all of RAM is what trips me up. Fundamentally, that  
puts the cart in front of the horse. The goal isn't to flush all of  
RAM but rather to flush all of cache.


 Right, I was just responding to your question of, What is the  
purpose of limiting the memory range to be flushed?


 Iterating over the small thing rather than the large would seem  
reasonably efficient.


 But as you say, if there are architectures where that can't be  
done and you must pass GBs of physical address space (rather than KB  
of cache space) through some process then range limiting it does make  
sense.


 Right.  The range specified is a minimum to be flushed -- if a  
particular architecture finds it easier/quicker to flush everything  
instead, that's fine.


 So in your case, how do you find out the addresses of buffers to be  
flushed from command ?

 Just thinking how this can be used generically ?


I'm not sure what you're asking.  How does the user know what address  
range to pass to the command?  It's whatever covers the program they  
want to run.


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

Re: [U-Boot] [PATCH 1/1 v3] console: USB: KBD: Fix incorrect autoboot timeout

[Wolfgang Denk]

Dear Jon Hunter,

In message 514b2482.5000...@ti.com you wrote:
 
 I understand that you may wish to have SYS_HZ == 1000, but shouldn't the
 code still normalise the get_timer() value to SYS_HZ?
 
 If I grep through the u-boot source I see a lot of instances where
 get_timer() is normalised to SYS_HZ.
 
 grep -r get_timer * | grep SYS_HZ

get_timer() is supposed to work in milliseconds.  

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Die Scheu vor Verantwortung ist die Krankheit unserer Zeit.
 -- Otto von Bismarck
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] Fix bootdelay timeout calculation when SYS_HZ!=1000

[Wolfgang Denk]

Dear Stephen Warren,

In message 514b2f8e.2090...@wwwdotorg.org you wrote:

 Then why does the config option still exist; surely it should be
 removed, or defined somewhere other than the per-board config file?

Removing it requires work, including testing efforts...

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
A year spent in artificial intelligence is enough to make one believe
in God.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/1 v3] console: USB: KBD: Fix incorrect autoboot timeout

[Wolfgang Denk]

Dear Jon Hunter,

In message 514b22fb.1000...@ti.com you wrote:
 
  The question is what should get_timer() be returning? If it is meant to
  be milliseconds then I guess I need to fix get_timer() for my board.
  However, if it is just meant to be timer ticks at the SYS_HZ rate then I

It is ticks at SYS_HZ rate with SYS_HZ==1000, i. e. milliseconds.


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
When the bosses talk about improving  productivity,  they  are  never
talking about themselves.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [RFC] command/cache: Add flush_cache command

[Wolfgang Denk]

Dear Scott Wood,

In message 1363889275.31522.12@snotra you wrote:

  There is no need to change any syntax.
 
 Then how would we know what range to flush?

Use a IH_TYPE_STANDALONE U-Boot image, and bootm?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
IMPORTANT NOTICE TO PURCHASERS: The Entire Physical Universe,  Inclu-
ding  This Product, May One Day Collapse Back into an Infinitesimally
Small Space. Should  Another  Universe  Subsequently  Re-emerge,  the
Existence of This Product in That Universe Cannot Be Guaranteed.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [RFC] command/cache: Add flush_cache command

[Wolfgang Denk]

Dear Scott,

In message 1363890157.31522.14@snotra you wrote:

 As above it's from flash (I assume NOR) to RAM.  The why is to be =20
 able to run the code from RAM. :-P

* Why don't you run it form flash?

* Why do you insist on using the go command (instead of bootm with
  a IH_TYPE_STANDALONE image?

  - eventually we should discourage the use of go; it may be
conveniend when you know what you are doing, but if it's casuing
such problems we might be better off recommending to use
proper IH_TYPE_STANDALONE legacy images in combination with the
bootm command instead.

 That or bootelf, sure.  I think there still should be some way to do it  
 manually, though.  bootm/bootelf probably wouldn't work for this use  
 case because it involves releasing other cores after the image is  
 copied/flushed, but before u-boot gives up control on the boot core.

The releasing other cores would then be a sub-command in the bootm
sequence?

  - Also, instead of adding a new command, this could probably be
scripted; I guess this should be roughly equivalent?
  
  setenv flush_cache 'dc off;ic off;dc on;ic on'

 This assumes that we support those cache operations, that they affect  
 all relevant caches (on 85xx it only flushes L1, but at least on newer  
 chips L2 is relevant as well), and that there are no errata or  
 architectural limitations to running with caches off.

Indeed.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
A lot of good arguments are spoiled by some fool that knows  what  he
is talking about. - Miguel de Unamuno
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [RFC] MAKEALL: Fix case substitution for old bash

[York Sun]

Bash ver 3.x doesn't support the parameter expansion with case
substitution. Use tr instead.

Signed-off-by: York Sun york...@freescale.com
---
I am not sure if using 'tr' is a good idea. Any suggestion is welcomed.

 MAKEALL |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MAKEALL b/MAKEALL
index c1d8957..ac92ef6 100755
--- a/MAKEALL
+++ b/MAKEALL
@@ -664,7 +664,7 @@ build_target() {
export BUILD_DIR=${output_dir}
 
target_arch=$(get_target_arch ${target})
-   eval cross_toolchain=\$CROSS_COMPILE_${target_arch^^}
+   eval cross_toolchain=\$CROSS_COMPILE_`echo $target_arch | tr 
'[:lower:]' '[:upper:]'`
if [ ${cross_toolchain} ] ; then
MAKE=make CROSS_COMPILE=${cross_toolchain}
elif [ ${CROSS_COMPILE} ] ; then
-- 
1.7.9.5


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

Re: [U-Boot] [RFC] MAKEALL: Fix case substitution for old bash

[Allen Martin]

On Thu, Mar 21, 2013 at 12:58:15PM -0700, York Sun wrote:
 Bash ver 3.x doesn't support the parameter expansion with case
 substitution. Use tr instead.
 
 Signed-off-by: York Sun york...@freescale.com
 ---
 I am not sure if using 'tr' is a good idea. Any suggestion is welcomed.
 
  MAKEALL |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/MAKEALL b/MAKEALL
 index c1d8957..ac92ef6 100755
 --- a/MAKEALL
 +++ b/MAKEALL
 @@ -664,7 +664,7 @@ build_target() {
   export BUILD_DIR=${output_dir}
  
   target_arch=$(get_target_arch ${target})
 - eval cross_toolchain=\$CROSS_COMPILE_${target_arch^^}
 + eval cross_toolchain=\$CROSS_COMPILE_`echo $target_arch | tr 
 '[:lower:]' '[:upper:]'`

Looks fine to me.  I'm not sure if there's a preference between using
backtick or $() for shell commands, it looks like both are used in the
script. 

   if [ ${cross_toolchain} ] ; then
   MAKE=make CROSS_COMPILE=${cross_toolchain}
   elif [ ${CROSS_COMPILE} ] ; then
 -- 
 1.7.9.5
 
 

PS: What happened with your bool fixup patch?  I'm a big fan of that
patch :^)

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

Re: [U-Boot] [RFC] command/cache: Add flush_cache command

[Scott Wood]

On 03/21/2013 02:25:10 PM, Wolfgang Denk wrote:

Dear Scott,

In message 1363890157.31522.14@snotra you wrote:

 As above it's from flash (I assume NOR) to RAM.  The why is to be  
=20

 able to run the code from RAM. :-P

* Why don't you run it form flash?


Presumably because it's slow.  As indicated elsewhere in the thread,  
these are performance tests.



* Why do you insist on using the go command (instead of bootm with
  a IH_TYPE_STANDALONE image?


Presumably because of the need to release other cores first.


  - eventually we should discourage the use of go; it may be
conveniend when you know what you are doing, but if it's casuing
such problems we might be better off recommending to use
proper IH_TYPE_STANDALONE legacy images in combination with the
bootm command instead.

 That or bootelf, sure.  I think there still should be some way to  
do it

 manually, though.  bootm/bootelf probably wouldn't work for this use
 case because it involves releasing other cores after the image is
 copied/flushed, but before u-boot gives up control on the boot core.

The releasing other cores would then be a sub-command in the bootm
sequence?


Perhaps it could be, or the application could be altered to release  
secondary cores through the spin table.  I don't think that excuses a  
situation where some ways of putting a blob of bytes into RAM flush the  
cache (to the extent the architecture requires it for the blob of bytes  
to be executable) and others don't, and there's no way to do it  
manually.  Would you remove the go command entirely?  I think that  
would be a mistake.


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

Re: [U-Boot] [RFC] MAKEALL: Fix case substitution for old bash

[York Sun]

On 03/21/2013 01:28 PM, Allen Martin wrote:
 On Thu, Mar 21, 2013 at 12:58:15PM -0700, York Sun wrote:
 Bash ver 3.x doesn't support the parameter expansion with case
 substitution. Use tr instead.

 Signed-off-by: York Sun york...@freescale.com
 ---
 I am not sure if using 'tr' is a good idea. Any suggestion is welcomed.

  MAKEALL |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/MAKEALL b/MAKEALL
 index c1d8957..ac92ef6 100755
 --- a/MAKEALL
 +++ b/MAKEALL
 @@ -664,7 +664,7 @@ build_target() {
  export BUILD_DIR=${output_dir}
  
  target_arch=$(get_target_arch ${target})
 -eval cross_toolchain=\$CROSS_COMPILE_${target_arch^^}
 +eval cross_toolchain=\$CROSS_COMPILE_`echo $target_arch | tr 
 '[:lower:]' '[:upper:]'`
 
 Looks fine to me.  I'm not sure if there's a preference between using
 backtick or $() for shell commands, it looks like both are used in the
 script. 

Let's wait for others to chime in.

 
  if [ ${cross_toolchain} ] ; then
  MAKE=make CROSS_COMPILE=${cross_toolchain}
  elif [ ${CROSS_COMPILE} ] ; then
 -- 
 1.7.9.5


 
 PS: What happened with your bool fixup patch?  I'm a big fan of that
 patch :^)
 

Tom asked on March 4th. I think he will accept it.

York



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

Re: [U-Boot] [PATCH v2 01/13] tegra: remove support for UART SPI switch

[Simon Glass]

Hi Stephen,

On Tue, Mar 19, 2013 at 12:13 PM, Stephen Warren swar...@wwwdotorg.org wrote:
 On 03/19/2013 01:01 PM, Simon Glass wrote:
 Hi Allen,

 On Sat, Mar 16, 2013 at 9:58 PM, Allen Martin amar...@nvidia.com wrote:
 This feature was only used for tegra20 seaboard that had a pinmux
 conflict on the SPI pins.  These boards were never manufactured, so
 remove this support to clean up SPI driver.

 Signed-off-by: Allen Martin amar...@nvidia.com
 ---
  arch/arm/include/asm/arch-tegra/board.h|3 +-
  .../arm/include/asm/arch-tegra20/uart-spi-switch.h |   46 ---
  board/nvidia/common/board.c|3 -
  board/nvidia/common/common.mk  |1 -
  board/nvidia/common/uart-spi-switch.c  |  125 
 
  board/nvidia/seaboard/seaboard.c   |2 +-
  drivers/spi/tegra_spi.c|   25 +---
  7 files changed, 3 insertions(+), 202 deletions(-)
  delete mode 100644 arch/arm/include/asm/arch-tegra20/uart-spi-switch.h
  delete mode 100644 board/nvidia/common/uart-spi-switch.c

 OK, maybe I need to get the T114 booting and stop using the seaboard?

 Seaboard still works perfectly after this patch (or should; I assume
 Allen tested it!). The only issue is that you can't use SPI; the
 assumption being that you store the BCT/bootloader in eMMC rather than
 SPI and hence have no need to use SPI. SPI can be tested on other
 Tegra20 board designs, such as TrimSlice (or perhaps Kaen/Aebl if
 they're still around!)

OK that's no problem I think.

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

Re: [U-Boot] [PATCH v2 06/13] spi: add common fdt SPI driver interface

[Simon Glass]

Hi Stephen,

On Tue, Mar 19, 2013 at 11:24 AM, Stephen Warren swar...@wwwdotorg.org wrote:
 On 03/16/2013 10:58 PM, Allen Martin wrote:
 Add a common interface to fdt based SPI drivers.  Each driver is
 represented by a table entry in fdt_spi_drivers[].  If there are
 multiple SPI drivers in the table, the first driver to return success
 from spi_init() will be registered as the SPI driver.

 diff --git a/drivers/spi/fdt_spi.c b/drivers/spi/fdt_spi.c

 +static struct fdt_spi_driver fdt_spi_drivers[] = {
 +#ifdef CONFIG_TEGRA20_SFLASH
 + {
 + .compat = COMPAT_NVIDIA_TEGRA20_SFLASH,
 + .max_ctrls  = 1,
 + .init   = tegra20_spi_init,
 + .claim_bus  = tegra20_spi_claim_bus,
 + .cs_is_valid= tegra20_spi_cs_is_valid,
 + .setup_slave= tegra20_spi_setup_slave,
 + .free_slave = tegra20_spi_free_slave,
 + .cs_activate= tegra20_spi_cs_activate,
 + .cs_deactivate  = tegra20_spi_cs_deactivate,
 + .xfer   = tegra20_spi_xfer,
 + },
 +#endif
 +#ifdef CONFIG_TEGRA20_SLINK
 + {
 + .compat = COMPAT_NVIDIA_TEGRA20_SLINK,
 + .max_ctrls  = CONFIG_TEGRA_SLINK_CTRLS,
 + .init   = tegra30_spi_init,
 + .claim_bus  = tegra30_spi_claim_bus,
 + .cs_is_valid= tegra30_spi_cs_is_valid,
 + .setup_slave= tegra30_spi_setup_slave,
 + .free_slave = tegra30_spi_free_slave,
 + .cs_activate= tegra30_spi_cs_activate,
 + .cs_deactivate  = tegra30_spi_cs_deactivate,
 + .xfer   = tegra30_spi_xfer,
 + },
 +#endif
 +};

 In the future, it would be nice if we could build up that table
 automatically, with each driver providing its own struct inside the
 driver file, and using e.g. linker scripts to piece together the structs
 into one large table. That would avoid the need to list each one here,
 and to prototype all those functions in a header file.

 It'd also be nice to allow multiple driver to be active at once.

 Still, that's certainly all something that's quite suitable for
 follow-on patches later; not something that needs to be addressed in
 this series.

Agreed. This fits more with the driver model work, where the above
structure could be used as the SPI subsystem interface perhaps.

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

Re: [U-Boot] Beagleboard: SPL hangs on serial init

[Javier Martinez Canillas]

On Thu, Mar 21, 2013 at 12:09 AM, Manfred Huber man.hu...@arcor.de wrote:
 Am 20.03.2013 02:27, schrieb Tom Rini:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 03/19/2013 08:05 PM, Javier Martinez Canillas wrote:

 On Tue, Mar 19, 2013 at 3:49 PM, Tom Rini tr...@ti.com wrote:

 On Sat, Mar 16, 2013 at 02:13:54PM +0100, Manfred Huber wrote:

 I'm surprised that no one is interested in a functioning
 Beagleboard. Has no one tested the Beagleboard since
 2012-09-19?


 I don't see this problem on mine (classic and xM), which is
 probably part of the why.  I'm inclined to accept the patch, but
 can you try two things please: - How reproducible is this
 problem, with the host and beagleboard combination you have?
 100%? - Do you have another beagleboard or another host PC (or
 USB-Serial dongle) you can try?

 Thanks!

 -- Tom


 Hi,

 I had this issue on another TI OMAP3 based board (IGEPv2) which
 use an DM3730 processor. Other IGEP board users reported that
 U-Boot hung on their boards and that a patch to not wait for the
 Transmitter Empty (TEMT) to initialize the serial console fixed
 the issue. So I added the CONFIG_SYS_NS16550_BROKEN_TEMT config
 option and used it for IGEP boards (igep00x0) to make them boot
 again.

 Back then I also tested on a Beagleboard Rev. C4 since it has the
 same ns16550 UART controller than the IGEPv2 as far as I
 understood. I used the exact U-Boot version, USB-Serial cable,
 host PC and terminal emulation program that I used for the IGEPv2
 and the Beagleboard booted correctly. This is the same behavior
 that Tom had on his Beagleboard.

 Since it worked on the Beagle I thought the issue was only present
 on IGEP boards but now Manfred says that he has the same issue on
 his Beagleboard. I now wonder if all IGEPv2 are broken or only my
 board and the ones of the users that cared to report this and
 other IGEPv2 can boot without CONFIG_SYS_NS16550_BROKEN_TEMT.


 Yeah, this is very perplexing.  I'm thinking we need to enable this
 quirk for all of the omap platforms except for OMAP3_ZOOM (which
 iirc has a different uart chip wired up rather than the SoC uart).

 - --
 Tom


 As I described in my first mail the reason is the missing UART_LSR_TEMT bit
 in the line status register. Comparing the UART_LSR_THRE bit instead works
 in my case.

 Maybe Javier can test on his IGEP board if it works for him to compare the
 UART_LSR_THRE bit instead of the UART_LSR_TEMT bit.


I see the same behavior in the IGEPv2. I tested mainline U-boot + your
[PATCH] omap3_beagle: Enable CONFIG_SYS_NS16550_BROKEN_TEMT patch
and SPL boots OK on my board.

 Another solution would be to make a soft reset of the UART as first command
 in the init function. This works also in my case.


I prefer this approach if it doesn't affect other boards.

 On the other hand we can try to identify which OMAP3 has this behavior. The
 module version register of the UART returns version 4.6.

 Best regards,
 Manfred



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

Re: [U-Boot] [PATCH v2 00/13] tegra114 SPI driver

[Simon Glass]

Hi,

On Tue, Mar 19, 2013 at 11:23 AM, Stephen Warren swar...@wwwdotorg.org wrote:
 On 03/16/2013 10:58 PM, Allen Martin wrote:
 This series pulls fdt functionality from the existing tegra20 and
 tegra30 SPI drivers into a new common fdt SPI driver front end,
 then adds a new tegra114 SPI driver as an additional client of
 the fdt SPI driver.

 The series,

 Reviewed-by: Stephen Warren swar...@nvidia.com

 There were quite a few places in commit descriptions and perhaps
 comments where we should s/{t,tegra}(\d+)/Tegra\1/i though.

Just one request - I submitted a series (now in mainline) which adds a
function to allocate a new SPI controller. Could you please check that
your patch applies on top of that? I got a conflict on
tegra20_sflash.c I think.

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

Re: [U-Boot] [PATCH] omap3_beagle: Enable CONFIG_SYS_NS16550_BROKEN_TEMT

[Javier Martinez Canillas]

Hi Manfred,

On Thu, Mar 21, 2013 at 8:03 PM, Manfred Huber man.hu...@arcor.de wrote:
 From: Manfred Huber

 Beagleboard UART (ns16550) doesn't set the Transmitter Empty (TEMT) Bit in
 SPL. Only Transmitter Hold Register Empty (THRE) Bit is set. This makes SPL
 to hang while waiting for TEMT. Adding the CONFIG_SYS_NS16550_BROKEN_TEMT
 config option and waiting for THRE avoid this issue.

 Signed-off-by: Manfred Huber man.hu...@arcor.de
 ---
  drivers/serial/ns16550.c   |5 -
  include/configs/omap3_beagle.h |3 +++
  2 files changed, 7 insertions(+), 1 deletion(-)

 diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c
 index b2da8b3..6379bcc 100644
 --- a/drivers/serial/ns16550.c
 +++ b/drivers/serial/ns16550.c
 @@ -36,7 +36,10 @@

  void NS16550_init(NS16550_t com_port, int baud_divisor)
  {
 -#if (!defined(CONFIG_SYS_NS16550_BROKEN_TEMT))
 +#if defined(CONFIG_SPL_BUILD)  defined(CONFIG_SYS_NS16550_BROKEN_TEMT)
 +   while (!(serial_in(com_port-lsr)  UART_LSR_THRE))
 +   ;
 +#else

I'm not sure to add this behavior under CONFIG_SYS_NS16550_BROKEN_TEMT
since this option just means:

On some broken platforms the Transmitter Empty (TEMT) bit is not set
in SPL making U-Boot to hang while waiting for it

According to your findings it seems that some OMAP3 platforms (at
least DM3730 and 3530) set THRE but I wonder if other broken platforms
will behave the same.

The current CONFIG_SYS_NS16550_BROKEN_TEMT just skips this test so it
can be reused by other platforms, but now your change makes it less
generic since it will only work on platforms that set THRE.

So I would just leave CONFIG_SYS_NS16550_BROKEN_TEMT as is now and be
able to reuse it on other platforms or add a new config option
CONFIG_SYS_NS16550_WAIT_THRE or something that would test for THRE
instead of TEMT and use that for OMAP3 based boards.

I do like your change that adds a test for CONFIG_SPL_BUILD since even
in the README it says that the issue is only present in SPL. So I just
forgot to add this when added the config option.

 while (!(serial_in(com_port-lsr)  UART_LSR_TEMT))
 ;
  #endif
 diff --git a/include/configs/omap3_beagle.h b/include/configs/omap3_beagle.h
 index 48ce4c0..6ab46d5 100644
 --- a/include/configs/omap3_beagle.h
 +++ b/include/configs/omap3_beagle.h
 @@ -82,6 +82,9 @@
  #define CONFIG_SYS_NS16550_REG_SIZE(-4)
  #define CONFIG_SYS_NS16550_CLK V_NS16550_CLK

 +/* define to avoid U-Boot to hang while waiting for TEMT */
 +#define CONFIG_SYS_NS16550_BROKEN_TEMT
 +
  /*
   * select serial console configuration
   */


This part of your patch looks good to me but you should split your
changes in two patches. One to change the ns16550 drvier and another
one to add this config option for the Beagleboard.

Thanks a lot and best regards,
Javier
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v9 25/30] arm: Remove support for smdk6400

[Benoît Thébaudeau]

Hi Lukasz,

On Thursday, March 21, 2013 10:43:49 PM, Lukasz Majewski wrote:
 Hi Benoît
 
  The migration of boards from Makefile to boards.cfg was due for
  v2012.03, but smdk6400 did not follow, and it does not build, so move
  it to scrapyard. It will still be possible to restore it from the Git
  history before fixing it.
  
  Signed-off-by: Benoît Thébaudeau benoit.thebaud...@advansee.com
 
 There were several attempts to convert the smdk64x0 to boards.cfg (in
 the end of 2012). For several reasons they failed.
 
 I was planning to prepare the whole patch series, which would also
 include some improvements (like USB + DFU).
 
 However, now I see that there is a firm deadline, so I will resubmit
 converting patches ASAP.

Will this series also fix the build of the smdk6400 and port it to generic SPL?

I don't know if I should rebase on your series or if you should rebase on mine.
My series could be split at this patch in order to apply its beginning ASAP, but
that would still make a v10 and postpone the end of it.

Albert, Tom, what do you think?

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

Re: [U-Boot] [PATCH 0/3 V4] EXYNOS5: Add GPIO numbering feature

[Simon Glass]

Hi Rajeshwari,

On Thu, Mar 21, 2013 at 4:33 AM, Rajeshwari Shinde
rajeshwar...@samsung.com wrote:
 Changes in V2:
 - Enabled CMD_GPIO as suggested by Simon Glass and
 supported same for EXYNOS5
 Changes in V3:
 - New patch added to rename S5P GPIO definitions to
 S5P_GPIO
 - GPIO Table added to calculate the base address
 of input gpio bank.
 Changes in V4:
 - To have consistent 0..n-1 GPIO numbering the banks are divided
 into different parts where ever they have holes in them.
 - Function and table to support gpio command moved to s5p-gpio driver
 - Rebased on latest u-boot-samsung tree

 Rajeshwari Shinde (3):
   EXYNOS5: Add gpio pin numbering feature
   S5P: Rename GPIO definitions
   EXYNOS5: GPIO: Enable GPIO Command for EXYNOS5

I tested this on snow, using:

# turn on backlight
i2c dev 4; i2c mw 48 f 1; i2c mw 48 15 1; i2c md 48 0 20
gpio set gpx30
gpio set gpb20

This seems to work fine.

I also tested that the cros_ec keyboard works, using interrupt 182
instead of 174) in the FDT:

ec-interrupt = gpio 182 1;

So it all looks good to me, thank you.

Acked-by: Simon Glass s...@chromium.org
Tested-by: Simon Glass s...@chromium.org


  arch/arm/cpu/armv7/exynos/pinmux.c   |  206 +++-
  arch/arm/include/asm/arch-exynos/cpu.h   |   10 +-
  arch/arm/include/asm/arch-exynos/gpio.h  |  410 
 --
  arch/arm/include/asm/arch-s5pc1xx/gpio.h |   26 +-
  board/samsung/goni/goni.c|4 +-
  board/samsung/origen/origen.c|8 +-
  board/samsung/smdk5250/smdk5250.c|   24 +--
  board/samsung/smdkc100/smdkc100.c|2 +-
  board/samsung/smdkv310/smdkv310.c|   10 +-
  board/samsung/trats/trats.c  |   16 +-
  board/samsung/universal_c210/universal.c |   36 ++--
  drivers/gpio/s5p_gpio.c  |  134 +-
  include/configs/exynos5250-dt.h  |1 +
  13 files changed, 669 insertions(+), 218 deletions(-)

 --
 1.7.4.4


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

Re: [U-Boot] [PATCH] omap3_beagle: Enable CONFIG_SYS_NS16550_BROKEN_TEMT

[Tom Rini]

On Thu, Mar 21, 2013 at 08:03:59PM +0100, Manfred Huber wrote:
 From: Manfred Huber
 
 Beagleboard UART (ns16550) doesn't set the Transmitter Empty (TEMT)
 Bit in SPL. Only Transmitter Hold Register Empty (THRE) Bit is set.
 This makes SPL to hang while waiting for TEMT. Adding the
 CONFIG_SYS_NS16550_BROKEN_TEMT config option and waiting for THRE
 avoid this issue.
 
 Signed-off-by: Manfred Huber man.hu...@arcor.de
 ---
  drivers/serial/ns16550.c   |5 -
  include/configs/omap3_beagle.h |3 +++
  2 files changed, 7 insertions(+), 1 deletion(-)
 
 diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c
 index b2da8b3..6379bcc 100644
 --- a/drivers/serial/ns16550.c
 +++ b/drivers/serial/ns16550.c
 @@ -36,7 +36,10 @@
 
  void NS16550_init(NS16550_t com_port, int baud_divisor)
  {
 -#if (!defined(CONFIG_SYS_NS16550_BROKEN_TEMT))
 +#if defined(CONFIG_SPL_BUILD)  defined(CONFIG_SYS_NS16550_BROKEN_TEMT)
 + while (!(serial_in(com_port-lsr)  UART_LSR_THRE))
 + ;
 +#else
   while (!(serial_in(com_port-lsr)  UART_LSR_TEMT))
   ;
  #endif

Scott, do you still have access to the failing systems that made us
introduce this change to start with?  Could we perhaps go with the THRE
test instead in all cases?  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] omap3_beagle: Enable CONFIG_SYS_NS16550_BROKEN_TEMT

[Scott Wood]

On 03/21/2013 05:21:00 PM, Tom Rini wrote:

On Thu, Mar 21, 2013 at 08:03:59PM +0100, Manfred Huber wrote:
 From: Manfred Huber

 Beagleboard UART (ns16550) doesn't set the Transmitter Empty (TEMT)
 Bit in SPL.


The serial port behaves differently based on the stage of U-Boot that  
is running?


Or is it that the bit doesn't get set until the port has been properly  
initialized?  Couldn't that happen in a case where SPL isn't used at  
all?



 Only Transmitter Hold Register Empty (THRE) Bit is set.
 This makes SPL to hang while waiting for TEMT. Adding the
 CONFIG_SYS_NS16550_BROKEN_TEMT config option and waiting for THRE
 avoid this issue.

 Signed-off-by: Manfred Huber man.hu...@arcor.de
 ---
  drivers/serial/ns16550.c   |5 -
  include/configs/omap3_beagle.h |3 +++
  2 files changed, 7 insertions(+), 1 deletion(-)

 diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c
 index b2da8b3..6379bcc 100644
 --- a/drivers/serial/ns16550.c
 +++ b/drivers/serial/ns16550.c
 @@ -36,7 +36,10 @@

  void NS16550_init(NS16550_t com_port, int baud_divisor)
  {
 -#if (!defined(CONFIG_SYS_NS16550_BROKEN_TEMT))
 +#if defined(CONFIG_SPL_BUILD)   
defined(CONFIG_SYS_NS16550_BROKEN_TEMT)

 +  while (!(serial_in(com_port-lsr)  UART_LSR_THRE))
 +  ;
 +#else
while (!(serial_in(com_port-lsr)  UART_LSR_TEMT))
;
  #endif

Scott, do you still have access to the failing systems that made us
introduce this change to start with?


It was an intermittent failure seen on a development tree, so not  
really.  You could try testing it by printing something immediately  
before calling NS16550_init(), either in a situation where you know the  
serial port is already configured (e.g. by SPL) or by calling  
NS16550_init() twice.



Could we perhaps go with the THRE test instead in all cases?  Thanks!


Wouldn't that still allow the last character to possibly be corrupted?

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

Re: [U-Boot] [PATCH 1/4 v7] Exynos: Add hardware accelerated SHA256 and SHA1

[Kim Phillips]

On Thu, 21 Mar 2013 03:12:54 -0400
Akshay Saraswat aksha...@samsung.com wrote:

 On Mon, 18 Mar 2013 02:06:15 -0400
 Akshay Saraswat aksha...@samsung.com wrote:
 
  +  while ((readl(ace_sha_reg-hash_status)  ACE_HASH_MSGDONE_MASK) ==
  +  ACE_HASH_MSGDONE_OFF) {
  +  /*
  +   * PRNG error bit goes HIGH if a PRNG request occurs without
  +   * a complete seed setup. We are using this bit to check h/w
  +   * because proper setup is not expected in that case.
  +   */
  +  if ((readl(ace_sha_reg-hash_status)
  +   ACE_HASH_PRNGERROR_MASK) == ACE_HASH_PRNGERROR_ON)
  +  break;
  +  }
 
 so we have:
 
 whilst (not_done)
  if (PRNGERROR_ON)
  break;
 
 ...and then success-assuming code flow continues after this.  What
 value is this check for PRNGERROR_ON, if the code isn't going to do
 anything differently?  And what does the status of the RNG have to
 do with keyless hashing?  It sounds like a check for proper
 initialization (RNG got seeded) is in order here, but only if it's
 required for the given hash operations (I doubt it, but the h/w
 might be fussy).
 
 PRNG ERROR means setup was not proper which should be the case
 when h/w is faulty because driver does everything in order.

The comment above says:

PRNG error bit goes HIGH if a PRNG request occurs without
a complete seed setup

But a SHA request isn't a PRNG request. The h/w shouldn't need the
PRNG at all to perform a simple SHA.

If this is a general initialization/setup check, then do it then.
If not, can you do it immediately prior to the wait-for-done after
the setup?  A PRNG error shouldn't be going off in the middle of
the wait-for-done loop for a SHA.

 Earlier break was happening which was not correct so changing it to
 return -EBUSY which means code flow should not be the same as
 the one being successfull.

-EBUSY?  that means the h/w was busy, and carries a try again
implication (much like -EAGAIN) - I doubt that's what's intended
here.

What happened to reverting to s/w, btw?

Kim

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

[U-Boot] [PATCH] ARM: bcm2835: fix get_timer() to return mS

[Stephen Warren]

Apparently, CONFIG_SYS_HZ must be 1000. Change this, and fix the timer
driver to conform to this.

Signed-off-by: Stephen Warren swar...@wwwdotorg.org
---
 arch/arm/cpu/arm1176/bcm2835/timer.c |   13 +
 include/configs/rpi_b.h  |2 +-
 2 files changed, 10 insertions(+), 5 deletions(-)

diff --git a/arch/arm/cpu/arm1176/bcm2835/timer.c 
b/arch/arm/cpu/arm1176/bcm2835/timer.c
index d232d7e..f550020 100644
--- a/arch/arm/cpu/arm1176/bcm2835/timer.c
+++ b/arch/arm/cpu/arm1176/bcm2835/timer.c
@@ -23,12 +23,17 @@ int timer_init(void)
return 0;
 }
 
-ulong get_timer(ulong base)
+ulong get_timer_us(void)
 {
struct bcm2835_timer_regs *regs =
(struct bcm2835_timer_regs *)BCM2835_TIMER_PHYSADDR;
 
-   return readl(regs-clo) - base;
+   return readl(regs-clo);
+}
+
+ulong get_timer(ulong base)
+{
+   return (get_timer_us() / 1000) - base;
 }
 
 unsigned long long get_ticks(void)
@@ -46,10 +51,10 @@ void __udelay(unsigned long usec)
ulong endtime;
signed long diff;
 
-   endtime = get_timer(0) + usec;
+   endtime = get_timer_us() + usec;
 
do {
-   ulong now = get_timer(0);
+   ulong now = get_timer_us();
diff = endtime - now;
} while (diff = 0);
 }
diff --git a/include/configs/rpi_b.h b/include/configs/rpi_b.h
index 3d55d36..c18b35b 100644
--- a/include/configs/rpi_b.h
+++ b/include/configs/rpi_b.h
@@ -31,7 +31,7 @@
 #define CONFIG_MACH_TYPE   MACH_TYPE_BCM2708
 
 /* Timer */
-#define CONFIG_SYS_HZ  100
+#define CONFIG_SYS_HZ  1000
 
 /* Memory layout */
 #define CONFIG_NR_DRAM_BANKS   1
-- 
1.7.10.4

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

[U-Boot] [PATCH] README: document the requirements for CONFIG_SYS_HZ

[Stephen Warren]

CONFIG_SYS_HZ must be 1000, and get_timer() must therefore return mS.
Document this.

Signed-off-by: Stephen Warren swar...@wwwdotorg.org
---
 README |6 ++
 1 file changed, 6 insertions(+)

diff --git a/README b/README
index 7f2506a..1871ada 100644
--- a/README
+++ b/README
@@ -495,6 +495,12 @@ The following options need to be configured:
exists, unlike the similar options in the Linux kernel. Do not
set these options unless they apply!
 
+- CPU timer options:
+   CONFIG_SYS_HZ
+
+   The frequency of the timer returned by get_timer(). This value
+   MUST be 1000.
+
 - Linux Kernel Interface:
CONFIG_CLOCKS_IN_MHZ
 
-- 
1.7.10.4

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

[U-Boot] [PATCH] mmc: bcm2835: fix delays in bug workaround

[Stephen Warren]

The back-to-back-writes workaround in the BCM2835 MMC driver assumed
that get_timer() returned uS. Now that it returns mS, the delay is far
too long. Use udelay() directly to avoid this. Dispense with the
last_write code since we now have no way of recording an absolute
time in uS. The difference between two un-averaged tests loading a
zImage is 445 mS vs the original 412 mS, so the difference doesn't
appear too relevant.

Signed-off-by: Stephen Warren swar...@wwwdotorg.org
---
 drivers/mmc/bcm2835_sdhci.c |6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/mmc/bcm2835_sdhci.c b/drivers/mmc/bcm2835_sdhci.c
index b0afc3c..240b5ec 100644
--- a/drivers/mmc/bcm2835_sdhci.c
+++ b/drivers/mmc/bcm2835_sdhci.c
@@ -46,7 +46,6 @@
 struct bcm2835_sdhci_host {
struct sdhci_host host;
uint twoticks_delay;
-   ulong last_write;
 };
 
 static inline struct bcm2835_sdhci_host *to_bcm(struct sdhci_host *host)
@@ -67,11 +66,9 @@ static inline void bcm2835_sdhci_raw_writel(struct 
sdhci_host *host, u32 val,
 * (Which is just as well - otherwise we'd have to nobble the DMA engine
 * too)
 */
-   while (get_timer(bcm_host-last_write)  bcm_host-twoticks_delay)
-   ;
+   udelay(bcm_host-twoticks_delay);
 
writel(val, host-ioaddr + reg);
-   bcm_host-last_write = get_timer(0);
 }
 
 static inline u32 bcm2835_sdhci_raw_readl(struct sdhci_host *host, int reg)
@@ -172,7 +169,6 @@ int bcm2835_sdhci_init(u32 regbase, u32 emmc_freq)
 * +1 for hack rounding.
 */
bcm_host-twoticks_delay = ((2 * 100) / MIN_FREQ) + 1;
-   bcm_host-last_write = 0;
 
host = bcm_host-host;
host-name = bcm2835_sdhci;
-- 
1.7.10.4

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

Re: [U-Boot] [PATCH 1/4 v7] Exynos: Add hardware accelerated SHA256 and SHA1

[Akshay Saraswat]

Hi Kim,

On Thu, 21 Mar 2013 03:12:54 -0400
Akshay Saraswat aksha...@samsung.com wrote:

 On Mon, 18 Mar 2013 02:06:15 -0400
 Akshay Saraswat aksha...@samsung.com wrote:
 
  + while ((readl(ace_sha_reg-hash_status)  ACE_HASH_MSGDONE_MASK) ==
  + ACE_HASH_MSGDONE_OFF) {
  + /*
  +  * PRNG error bit goes HIGH if a PRNG request occurs without
  +  * a complete seed setup. We are using this bit to check h/w
  +  * because proper setup is not expected in that case.
  +  */
  + if ((readl(ace_sha_reg-hash_status)
  +  ACE_HASH_PRNGERROR_MASK) == ACE_HASH_PRNGERROR_ON)
  + break;
  + }
 
 so we have:
 
 whilst (not_done)
 if (PRNGERROR_ON)
 break;
 
 ...and then success-assuming code flow continues after this.  What
 value is this check for PRNGERROR_ON, if the code isn't going to do
 anything differently?  And what does the status of the RNG have to
 do with keyless hashing?  It sounds like a check for proper
 initialization (RNG got seeded) is in order here, but only if it's
 required for the given hash operations (I doubt it, but the h/w
 might be fussy).
 
 PRNG ERROR means setup was not proper which should be the case
 when h/w is faulty because driver does everything in order.

The comment above says:

PRNG error bit goes HIGH if a PRNG request occurs without
a complete seed setup

But a SHA request isn't a PRNG request. The h/w shouldn't need the
PRNG at all to perform a simple SHA.

If this is a general initialization/setup check, then do it then.
If not, can you do it immediately prior to the wait-for-done after
the setup?  A PRNG error shouldn't be going off in the middle of
the wait-for-done loop for a SHA.

 Earlier break was happening which was not correct so changing it to
 return -EBUSY which means code flow should not be the same as
 the one being successfull.

-EBUSY?  that means the h/w was busy, and carries a try again
implication (much like -EAGAIN) - I doubt that's what's intended
here.

What happened to reverting to s/w, btw?


What has to be done:
Step-1: Data input (DMA Mode). Configure the DMA unit to transfer N bytes of 
data.
Step-2: Poll the status register until [6] == 1; OR When MSG_DONE_IRQ is 
asserted, execute further code.

What is being done right now:
No support for interrupt handling in u-boot, hence, while loop.
To be on the safer side wanted to keep a check for h/w malfunction which must 
not happen.

We used timeout earlier, but as per the discussion timeout has to be related to 
frequency.
The PRNG IP is based on the SHA-1 algorithm for generating the random numbers.
Hence, I found it inapt but an alternative to timeout for h/w fault detection.
Other than these two ways there is no way for h/w fault detection in while loop.
Shall I drop the idea of h/w fault detection ?

About s/w fallback:
I think the code calling h/w acceleration for sha should do that, because there 
may be some
situations when developers may need not to do encryption at all instead of 
doing it with s/w.
It's just a driver for h/w acceleration, in my opinion, it should do it's job 
nothing more than that.
If we fallback to s/w, then it might mislead developers in few scenarios.

Please suggest if this is correct or not and also what needs to be done.

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

Re: [U-Boot] [PATCH v9 25/30] arm: Remove support for smdk6400

[Lukasz Majewski]

Hi Benoît 

 The migration of boards from Makefile to boards.cfg was due for
 v2012.03, but smdk6400 did not follow, and it does not build, so move
 it to scrapyard. It will still be possible to restore it from the Git
 history before fixing it.
 
 Signed-off-by: Benoît Thébaudeau benoit.thebaud...@advansee.com

There were several attempts to convert the smdk64x0 to boards.cfg (in
the end of 2012). For several reasons they failed.

I was planning to prepare the whole patch series, which would also
include some improvements (like USB + DFU).

However, now I see that there is a firm deadline, so I will resubmit
converting patches ASAP.


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

Re: [U-Boot] [PATCH v2 3/4][resend] arm: at91: add at91sam9n12ek board support

[Bo Shen]

Hi Josh,
  minor comment as following.

On 3/21/2013 9:52, Josh Wu wrote:

Add support for following features:
   - nand boot, with PMECC 2bit ECC for 512 bytes sector
   - SPI flash boot
   - SD card boot
   - LCD support

Signed-off-by: Josh Wu josh...@atmel.com
---
  MAINTAINERS   |3 +
  arch/arm/cpu/arm926ejs/at91/Makefile  |1 +
  arch/arm/cpu/arm926ejs/at91/at91sam9n12_devices.c |  180 
  arch/arm/cpu/arm926ejs/at91/clock.c   |4 +-
  board/atmel/at91sam9n12ek/Makefile|   52 +
  board/atmel/at91sam9n12ek/at91sam9n12ek.c |  228 
  boards.cfg|3 +
  include/configs/at91sam9n12ek.h   |  232 +
  8 files changed, 701 insertions(+), 2 deletions(-)
  create mode 100644 arch/arm/cpu/arm926ejs/at91/at91sam9n12_devices.c
  create mode 100644 board/atmel/at91sam9n12ek/Makefile
  create mode 100644 board/atmel/at91sam9n12ek/at91sam9n12ek.c
  create mode 100644 include/configs/at91sam9n12ek.h



[snip]


+#ifdef CONFIG_LCD
+void at91_lcd_hw_init(void)
+{
+   struct at91_pmc *pmc = (struct at91_pmc *)ATMEL_BASE_PMC;
+
+   at91_set_a_periph(AT91_PIO_PORTC, 24, 0);   /* LCDDPWR */
+   at91_set_a_periph(AT91_PIO_PORTC, 26, 0);   /* LCDVSYNC */
+   at91_set_a_periph(AT91_PIO_PORTC, 27, 0);   /* LCDHSYNC */
+   at91_set_a_periph(AT91_PIO_PORTC, 28, 0);   /* LCDDOTCK */
+   at91_set_a_periph(AT91_PIO_PORTC, 29, 0);   /* LCDDEN */
+   at91_set_a_periph(AT91_PIO_PORTC, 30, 0);   /* LCDDOTCK */
+
+   at91_set_a_periph(AT91_PIO_PORTC, 0, 0);/* LCDD0 */
+   at91_set_a_periph(AT91_PIO_PORTC, 1, 0);/* LCDD1 */
+   at91_set_a_periph(AT91_PIO_PORTC, 2, 0);/* LCDD2 */
+   at91_set_a_periph(AT91_PIO_PORTC, 3, 0);/* LCDD3 */
+   at91_set_a_periph(AT91_PIO_PORTC, 4, 0);/* LCDD4 */
+   at91_set_a_periph(AT91_PIO_PORTC, 5, 0);/* LCDD5 */
+   at91_set_a_periph(AT91_PIO_PORTC, 6, 0);/* LCDD6 */
+   at91_set_a_periph(AT91_PIO_PORTC, 7, 0);/* LCDD7 */
+   at91_set_a_periph(AT91_PIO_PORTC, 8, 0);/* LCDD8 */
+   at91_set_a_periph(AT91_PIO_PORTC, 9, 0);/* LCDD9 */
+   at91_set_a_periph(AT91_PIO_PORTC, 10, 0);   /* LCDD10 */
+   at91_set_a_periph(AT91_PIO_PORTC, 11, 0);   /* LCDD11 */
+   at91_set_a_periph(AT91_PIO_PORTC, 12, 0);   /* LCDD12 */
+   at91_set_a_periph(AT91_PIO_PORTC, 13, 0);   /* LCDD13 */
+   at91_set_a_periph(AT91_PIO_PORTC, 14, 0);   /* LCDD14 */
+   at91_set_a_periph(AT91_PIO_PORTC, 15, 0);   /* LCDD15 */
+   at91_set_a_periph(AT91_PIO_PORTC, 16, 0);   /* LCDD16 */
+   at91_set_a_periph(AT91_PIO_PORTC, 17, 0);   /* LCDD17 */
+   at91_set_a_periph(AT91_PIO_PORTC, 18, 0);   /* LCDD18 */
+   at91_set_a_periph(AT91_PIO_PORTC, 19, 0);   /* LCDD19 */
+   at91_set_a_periph(AT91_PIO_PORTC, 20, 0);   /* LCDD20 */
+   at91_set_a_periph(AT91_PIO_PORTC, 21, 0);   /* LCDD21 */
+   at91_set_a_periph(AT91_PIO_PORTC, 22, 0);   /* LCDD22 */
+   at91_set_a_periph(AT91_PIO_PORTC, 23, 0);   /* LCDD23 */
+
+   writel(1  ATMEL_ID_LCDC, pmc-pcer);
+}
+#endif
+
+
+


when apply this patch, it will show following warning:

.git/rebase-apply/patch:225: new blank line at EOF.
+
warning: 1 line adds whitespace errors.

Best Regards,
Bo Shen

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