[U-Boot] [PATCH v2 1/1] fs: fat/ext4/sandbox: Deal with files 2GB

2014-10-27 Thread Suriyan Ramasami
The commands fatls/ext4ls give -ve values when dealing with files  2GB.
The commands fatsize/ext4size do not update the variable filesize for
these files.

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

Signed-off-by: Suriyan Ramasami suriya...@gmail.com

---
v2:
* Added test case for fat/ext4 in test/fs/testfs.sh
* md5sum: call map_sysmem() for buffer that md5_wd will work on

v1:
* First try.
---
 arch/sandbox/cpu/os.c |  11 +-
 arch/sandbox/cpu/state.c  |   6 +-
 common/board_f.c  |   6 +-
 common/cmd_fat.c  |   9 +-
 common/cmd_md5sum.c   |   7 +-
 fs/ext4/ext4_common.c |  24 ++--
 fs/ext4/ext4_common.h |   4 +-
 fs/ext4/ext4fs.c  |  37 +++---
 fs/fat/fat.c  | 124 ++-
 fs/fat/fat_write.c|  48 
 fs/fat/file.c |   7 +-
 fs/fs.c   |  63 +-
 fs/sandbox/sandboxfs.c|  25 ++--
 include/configs/sandbox.h |   1 +
 include/ext4fs.h  |  11 +-
 include/fat.h |  19 +--
 include/fs.h  |   8 +-
 include/os.h  |   2 +-
 include/sandboxfs.h   |   8 +-
 test/fs/testfs.sh | 306 ++
 20 files changed, 541 insertions(+), 185 deletions(-)
 create mode 100644 test/fs/testfs.sh

diff --git a/arch/sandbox/cpu/os.c b/arch/sandbox/cpu/os.c
index 1c4aa3f..43872e8 100644
--- a/arch/sandbox/cpu/os.c
+++ b/arch/sandbox/cpu/os.c
@@ -385,7 +385,7 @@ const char *os_dirent_get_typename(enum os_dirent_t type)
return os_dirent_typename[OS_FILET_UNKNOWN];
 }
 
-ssize_t os_get_filesize(const char *fname)
+int os_get_filesize(const char *fname, loff_t *size)
 {
struct stat buf;
int ret;
@@ -393,7 +393,8 @@ ssize_t os_get_filesize(const char *fname)
ret = stat(fname, buf);
if (ret)
return ret;
-   return buf.st_size;
+   *size = buf.st_size;
+   return 0;
 }
 
 void os_putc(int ch)
@@ -427,10 +428,10 @@ int os_read_ram_buf(const char *fname)
 {
struct sandbox_state *state = state_get_current();
int fd, ret;
-   int size;
+   loff_t size;
 
-   size = os_get_filesize(fname);
-   if (size  0)
+   ret = os_get_filesize(fname, size);
+   if (ret  0)
return -ENOENT;
if (size != state-ram_size)
return -ENOSPC;
diff --git a/arch/sandbox/cpu/state.c b/arch/sandbox/cpu/state.c
index 59adad6..07d2aea 100644
--- a/arch/sandbox/cpu/state.c
+++ b/arch/sandbox/cpu/state.c
@@ -49,12 +49,12 @@ static int state_ensure_space(int extra_size)
 
 static int state_read_file(struct sandbox_state *state, const char *fname)
 {
-   int size;
+   loff_t size;
int ret;
int fd;
 
-   size = os_get_filesize(fname);
-   if (size  0) {
+   ret = os_get_filesize(fname, size);
+   if (ret  0) {
printf(Cannot find sandbox state file '%s'\n, fname);
return -ENOENT;
}
diff --git a/common/board_f.c b/common/board_f.c
index e6aa298..a1ac8fe 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -291,7 +291,7 @@ static int read_fdt_from_file(void)
struct sandbox_state *state = state_get_current();
const char *fname = state-fdt_fname;
void *blob;
-   ssize_t size;
+   loff_t size;
int err;
int fd;
 
@@ -304,8 +304,8 @@ static int read_fdt_from_file(void)
return -EINVAL;
}
 
-   size = os_get_filesize(fname);
-   if (size  0) {
+   err = os_get_filesize(fname, size);
+   if (err  0) {
printf(Failed to file FDT file '%s'\n, fname);
return -ENOENT;
}
diff --git a/common/cmd_fat.c b/common/cmd_fat.c
index 633fbf1..efba9da 100644
--- a/common/cmd_fat.c
+++ b/common/cmd_fat.c
@@ -100,7 +100,8 @@ U_BOOT_CMD(
 static int do_fat_fswrite(cmd_tbl_t *cmdtp, int flag,
int argc, char * const argv[])
 {
-   long size;
+   loff_t size;
+   int ret;
unsigned long addr;
unsigned long count;
block_dev_desc_t *dev_desc = NULL;
@@ -127,15 +128,15 @@ static int do_fat_fswrite(cmd_tbl_t *cmdtp, int flag,
count = simple_strtoul(argv[5], NULL, 16);
 
buf = map_sysmem(addr, count);
-   size = file_fat_write(argv[4], buf, count);
+   ret = file_fat_write(argv[4], buf, count, size);
unmap_sysmem(buf);
-   if (size == -1) {
+   if (ret == -1) {
printf(\n** Unable to write \%s\ from %s %d:%d **\n,
argv[4], argv[1], dev, part);
return 1;
}
 
-   printf(%ld bytes written\n, size);
+   printf(%llu bytes written\n, size);
 
return 0;
 }
diff --git a/common/cmd_md5sum.c b/common/cmd_md5sum.c
index 3ac8cc4..bd6defd 100644
--- 

[U-Boot] [PATCH v3 1/1] fs: fat/ext4/sandbox: Deal with files 2GB

2014-10-27 Thread Suriyan Ramasami
The commands fatls/ext4ls give -ve values when dealing with files  2GB.
The commands fatsize/ext4size do not update the variable filesize for
these files.

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

Signed-off-by: Suriyan Ramasami suriya...@gmail.com
---

v3:
* Added testcase to test writes
* Correct function set_contents() in fs/fat/fat_write.c

v2:
* Added test case for fat/ext4 in test/fs/testfs.sh
* md5sum: call map_sysmem() for buffer that md5_wd will work on

v1:
* First try.
---
 arch/sandbox/cpu/os.c |  11 +-
 arch/sandbox/cpu/state.c  |   6 +-
 common/board_f.c  |   6 +-
 common/cmd_fat.c  |   9 +-
 common/cmd_md5sum.c   |   7 +-
 common/env_fat.c  |   4 +-
 fs/ext4/ext4_common.c |  24 ++--
 fs/ext4/ext4_common.h |   4 +-
 fs/ext4/ext4fs.c  |  37 ++---
 fs/fat/fat.c  | 124 +
 fs/fat/fat_write.c|  54 
 fs/fat/file.c |   7 +-
 fs/fs.c   |  63 +
 fs/sandbox/sandboxfs.c|  25 ++--
 include/configs/sandbox.h |   2 +
 include/ext4fs.h  |  11 +-
 include/fat.h |  19 +--
 include/fs.h  |   8 +-
 include/os.h  |   2 +-
 include/sandboxfs.h   |   8 +-
 test/fs/testfs.sh | 339 ++
 21 files changed, 581 insertions(+), 189 deletions(-)
 create mode 100644 test/fs/testfs.sh

diff --git a/arch/sandbox/cpu/os.c b/arch/sandbox/cpu/os.c
index 1c4aa3f..43872e8 100644
--- a/arch/sandbox/cpu/os.c
+++ b/arch/sandbox/cpu/os.c
@@ -385,7 +385,7 @@ const char *os_dirent_get_typename(enum os_dirent_t type)
return os_dirent_typename[OS_FILET_UNKNOWN];
 }
 
-ssize_t os_get_filesize(const char *fname)
+int os_get_filesize(const char *fname, loff_t *size)
 {
struct stat buf;
int ret;
@@ -393,7 +393,8 @@ ssize_t os_get_filesize(const char *fname)
ret = stat(fname, buf);
if (ret)
return ret;
-   return buf.st_size;
+   *size = buf.st_size;
+   return 0;
 }
 
 void os_putc(int ch)
@@ -427,10 +428,10 @@ int os_read_ram_buf(const char *fname)
 {
struct sandbox_state *state = state_get_current();
int fd, ret;
-   int size;
+   loff_t size;
 
-   size = os_get_filesize(fname);
-   if (size  0)
+   ret = os_get_filesize(fname, size);
+   if (ret  0)
return -ENOENT;
if (size != state-ram_size)
return -ENOSPC;
diff --git a/arch/sandbox/cpu/state.c b/arch/sandbox/cpu/state.c
index 59adad6..07d2aea 100644
--- a/arch/sandbox/cpu/state.c
+++ b/arch/sandbox/cpu/state.c
@@ -49,12 +49,12 @@ static int state_ensure_space(int extra_size)
 
 static int state_read_file(struct sandbox_state *state, const char *fname)
 {
-   int size;
+   loff_t size;
int ret;
int fd;
 
-   size = os_get_filesize(fname);
-   if (size  0) {
+   ret = os_get_filesize(fname, size);
+   if (ret  0) {
printf(Cannot find sandbox state file '%s'\n, fname);
return -ENOENT;
}
diff --git a/common/board_f.c b/common/board_f.c
index e6aa298..a1ac8fe 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -291,7 +291,7 @@ static int read_fdt_from_file(void)
struct sandbox_state *state = state_get_current();
const char *fname = state-fdt_fname;
void *blob;
-   ssize_t size;
+   loff_t size;
int err;
int fd;
 
@@ -304,8 +304,8 @@ static int read_fdt_from_file(void)
return -EINVAL;
}
 
-   size = os_get_filesize(fname);
-   if (size  0) {
+   err = os_get_filesize(fname, size);
+   if (err  0) {
printf(Failed to file FDT file '%s'\n, fname);
return -ENOENT;
}
diff --git a/common/cmd_fat.c b/common/cmd_fat.c
index 633fbf1..efba9da 100644
--- a/common/cmd_fat.c
+++ b/common/cmd_fat.c
@@ -100,7 +100,8 @@ U_BOOT_CMD(
 static int do_fat_fswrite(cmd_tbl_t *cmdtp, int flag,
int argc, char * const argv[])
 {
-   long size;
+   loff_t size;
+   int ret;
unsigned long addr;
unsigned long count;
block_dev_desc_t *dev_desc = NULL;
@@ -127,15 +128,15 @@ static int do_fat_fswrite(cmd_tbl_t *cmdtp, int flag,
count = simple_strtoul(argv[5], NULL, 16);
 
buf = map_sysmem(addr, count);
-   size = file_fat_write(argv[4], buf, count);
+   ret = file_fat_write(argv[4], buf, count, size);
unmap_sysmem(buf);
-   if (size == -1) {
+   if (ret == -1) {
printf(\n** Unable to write \%s\ from %s %d:%d **\n,
argv[4], argv[1], dev, part);
return 1;
}
 
-   printf(%ld bytes written\n, size);
+   printf(%llu bytes 

Re: [U-Boot] [U-Boot, v4, 14/20] arm: armada-xp: Add basic support for the Marvell DB-MV784MP-GP board

2014-10-27 Thread Albert ARIBAUD
Hello Tom,

On Sun, 26 Oct 2014 20:37:44 -0400, Tom Rini tr...@ti.com wrote:
 On Mon, Oct 27, 2014 at 01:01:07AM +0100, Albert ARIBAUD wrote:
  On Thu, 23 Oct 2014 11:05:46 -0400, Tom Rini tr...@ti.com a
  écrit :
  
   On Wed, Oct 22, 2014 at 12:13:18PM +0200, Stefan Roese wrote:
   
This patch adds basic support for the Marvell DB-MV784MP-GP
evaulation board. This is the first board that uses the recently
created Armada XP 78460 SoC support.

Signed-off-by: Stefan Roese s...@denx.de
Tested-by: Luka Perkov l...@openwrt.org
   
   Applied to u-boot/master, thanks!
  
  I am getting an error here with this board:
  
  Didn't find the file 'board/Marvell/db-mv784mp-gp/binary.0' in
  'build/current/.bm-work/00/build' which is mandatory to generate the
  image
  This file generally contains the DDR3 training code, and should be
  extracted from an existing bootable
  image for your board. See 'kwbimage -x' to extract it from an
  existing image.
  Could not create image
  
  Am I missing something?
 
 Yes, we need http://patchwork.ozlabs.org/patch/402556/ and/or the
 follow-up that implements proper DDR config.

Ok -- I guess I'll live with a broken ARM build for a while.

 -- 
 Tom

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


Re: [U-Boot] [PATCH 2/2] tools/kwbimage.c: fix build on darwin

2014-10-27 Thread Stefan Roese

On 24.10.2014 23:39, andreas.de...@googlemail.com wrote:

From: Andreas Bießmann andreas.de...@googlemail.com

kwbimage uses get_current_dir_name(3) which is a gnu extension and not
available on darwin host. Fix this by converting to portable getcwd(3)
function.

This patch fixes the following error:
---8---
   HOSTCC  tools/kwbimage.o
tools/kwbimage.c:399:16: warning: implicit declaration of function 
'get_current_dir_name' is invalid in C99 [-Wimplicit-function-declaration]
 char *cwd = get_current_dir_name();
 ^
tools/kwbimage.c:399:10: warning: incompatible integer to pointer conversion 
initializing 'char *' with an expression of type 'int' [-Wint-conversion]
 char *cwd = get_current_dir_name();
   ^ ~~
2 warnings generated.
...
Undefined symbols for architecture x86_64:
   _get_current_dir_name, referenced from:
   _image_headersz_v1 in kwbimage.o
ld: symbol(s) not found for architecture x86_64
---8---

Signed-off-by: Andreas Bießmann andreas.de...@googlemail.com
Cc: Stefan Roese s...@denx.de


Acked-by: Stefan Roese s...@denx.de

Thanks,
Stefan

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


Re: [U-Boot] [BUG] kwimage v0 broken

2014-10-27 Thread Stefan Roese

Hi!

On 25.10.2014 07:59, drEagle wrote:

With the latest u-boot mainline from denx git, the kirkwood image old 
version/format are broken;
Sheevaplug u-boot.kwb is no more flahsable and brick the plug.

Using an older mkimage version still work with the same u-boot binary.

u-boot (in elf loading mode) still work well also.

If I can help by some tests, please feel free to ask.

PS: I'm not on the list, thans to cc me.


Hmmm. I have no access to a mainlined Kirkwood board right now. So I 
can't really test right now. I added Luka to Cc, as he did some testing 
on this patch series a few weeks ago. And IIRC, he didn't experience any 
such problems with the kwimage tool.


Luka, could you perhaps take another look at it? And give the current 
mainline version a try on your board?


Thanks,
Stefan

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


Re: [U-Boot] [PATCH 0/6] MIPS Kconfig updates

2014-10-27 Thread Stefan Roese

Hi Daniel,

On 26.10.2014 14:37, Daniel Schwierzeck wrote:

This patch series introduce Kconfig symbols for various MIPS
specific config options. It also add Kconfig symbols for board
specific config options on vct and dbau1x00. With this series the
option CONFIG_SYS_EXTRA_OPTIONS becomes obsolete for existing
MIPS boards.

This series is also available at
git://git.denx.de/u-boot-mips.git mips_kconfig_v1


Daniel Schwierzeck (6):
   MIPS: kconfig: add options for endianess select
   MIPS: kconfig: add options for CPU type select
   MIPS: kconfig: globally define CONFIG_SYS_CPU for MIPS
   MIPS: kconfig: merge targets qemu_mips and qemu_mips64
   MIPS: kconfig: add options for dbau1x00 board variant select
   MIPS: kconfig: add options for vct board variant select


Thanks for working on this. Please add my:

Acked-by: Stefan Roese s...@denx.de

to all VCT related patches.

Thanks,
Stefan

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


Re: [U-Boot] [PATCH 3/8] ARMv8/fsl-lsch3: Refactor spin-table code

2014-10-27 Thread arnab.b...@freescale.com
Hi Albert

 -Original Message-
 From: Albert ARIBAUD [mailto:albert.u.b...@aribaud.net]
 Sent: Monday, October 27, 2014 2:36 AM
 To: Basu Arnab-B45036
 Cc: marc.zyng...@arm.com; mark.rutl...@arm.com; Sun York-R58495; Yoder
 Stuart-B08248; u-boot@lists.denx.de
 Subject: Re: [U-Boot] [PATCH 3/8] ARMv8/fsl-lsch3: Refactor spin-table
 code
 
 Hello Arnab,
 
 On Thu, 28 Aug 2014 01:59:56 +0530, Arnab Basu arnab.b...@freescale.com
 wrote:
  This creates the function cpu_update_dt for ARMv8 which currently
  patches the cpu node in the device table and sets enable-method to
  spin-table.
 
  Signed-off-by: Arnab Basu arnab.b...@freescale.com
  Reviewed-by: Bhupesh Sharma bhupesh.sha...@freescale.com
  Cc: York Sun york...@freescale.com
  ---
 
 This patch fails to apply cleanly. Can you please rebase the series on
 top of current u-boot/master?

Yes, in fact I need to rework some of the other patches in the series too.
I got a little side tracked, hence the delay. I will get on this..

Thanks
Arnab

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


Re: [U-Boot] [U-Boot, v4, 14/20] arm: armada-xp: Add basic support for the Marvell DB-MV784MP-GP board

2014-10-27 Thread Stefan Roese

Hi Albert, Hi Tom!

On 27.10.2014 07:32, Albert ARIBAUD wrote:

Applied to u-boot/master, thanks!


I am getting an error here with this board:

Didn't find the file 'board/Marvell/db-mv784mp-gp/binary.0' in
'build/current/.bm-work/00/build' which is mandatory to generate the
image
This file generally contains the DDR3 training code, and should be
extracted from an existing bootable
image for your board. See 'kwbimage -x' to extract it from an
existing image.
Could not create image

Am I missing something?


Yes, we need http://patchwork.ozlabs.org/patch/402556/ and/or the
follow-up that implements proper DDR config.


Ok -- I guess I'll live with a broken ARM build for a while.


I plan to send the patch series with full DDR support later this week, 
but it might take a bit until its available in mainline. I really 
suggest to add this patch that Tom mentioned above to fix building for now.


Thanks,
Stefan

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


Re: [U-Boot] [PATCH v3 1/1] fs: fat/ext4/sandbox: Deal with files 2GB

2014-10-27 Thread Albert ARIBAUD
Hello Suriyan,

On Sun, 26 Oct 2014 21:42:52 -0700, Suriyan Ramasami
suriya...@gmail.com wrote:

 Subject: [PATCH v3 1/1] fs: fat/ext4/sandbox: Deal with files  2GB

Could you repost using the full 'negative' word instead of an
abbreviation? Otherwise people looking for issues by keywords might
miss this one.

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


[U-Boot] [PATCH] arm: mvebu: maxbcm: Fix compilation warning and add Spansion SPI NOR support

2014-10-27 Thread Stefan Roese
This patch fixes the following compilation warning for maxbcm:

Building maxbcm board...
   textdata bss dec hex filename
 1600756596   38240  204911   3206f ./u-boot
board/maxbcm/maxbcm.c: In function 'reset_phy':
board/maxbcm/maxbcm.c:68:6: warning: unused variable 'reg' [-Wunused-variable]
  u16 reg;
  ^
board/maxbcm/maxbcm.c:66:6: warning: unused variable 'devadr' 
[-Wunused-variable]
  u16 devadr = CONFIG_PHY_BASE_ADDR;
  ^

Additionally support Spansion SPI NOR flash is added. With larger SPI device
support via the CONFIG_SPI_FLASH_BAR define.

Signed-off-by: Stefan Roese s...@denx.de
---
 board/maxbcm/maxbcm.c| 2 --
 include/configs/maxbcm.h | 2 ++
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/board/maxbcm/maxbcm.c b/board/maxbcm/maxbcm.c
index 7fc83ee..94c688f 100644
--- a/board/maxbcm/maxbcm.c
+++ b/board/maxbcm/maxbcm.c
@@ -63,9 +63,7 @@ int checkboard(void)
 /* Configure and enable MV88E6185 switch */
 void reset_phy(void)
 {
-   u16 devadr = CONFIG_PHY_BASE_ADDR;
char *name = neta0;
-   u16 reg;
 
if (miiphy_set_current_dev(name))
return;
diff --git a/include/configs/maxbcm.h b/include/configs/maxbcm.h
index 72217bd..005e136 100644
--- a/include/configs/maxbcm.h
+++ b/include/configs/maxbcm.h
@@ -43,6 +43,8 @@
 #define CONFIG_SF_DEFAULT_SPEED100
 #define CONFIG_SF_DEFAULT_MODE SPI_MODE_3
 #define CONFIG_SPI_FLASH_STMICRO
+#define CONFIG_SPI_FLASH_SPANSION
+#define CONFIG_SPI_FLASH_BAR
 
 /* Environment in SPI NOR flash */
 #define CONFIG_ENV_IS_IN_SPI_FLASH
-- 
2.1.2

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


Re: [U-Boot] [PATCH 1/2] ARM: Add arch/arm/cpu/armv7/Kconfig with non-secure and virt options

2014-10-27 Thread Hans de Goede
Hi,

On 10/27/2014 01:35 AM, Tom Rini wrote:
 On Fri, Oct 24, 2014 at 08:34:15PM +0200, Hans de Goede wrote:
 
 Add arch/arm/cpu/armv7/Kconfig with non-secure and virt options, so that
 we can have CONFIG_ARMV7_SEC_BY_DEFAULT as a proper Kconfig option.

 Signed-off-by: Hans de Goede hdego...@redhat.com
 ---
  arch/arm/Kconfig|  2 ++
  arch/arm/cpu/armv7/Kconfig  | 20 
  include/configs/arndale.h   |  2 --
  include/configs/sun7i.h |  2 --
  include/configs/vexpress_ca15_tc2.h |  2 --
 
 The only problem I see is you aren't also updating the defconfigs for
 the boards in question, which results in a behavior change which we
 don't want.

The new Kconfig options have default y, and the boards where using
those settings before.

Or are you referring to the fact that CONFIG_ARMV7_NONSEC is getting
set for arndale and vexpress_ca15_tc2 now too ? That is intentional
ARMV7_VIRT depends on CONFIG_ARMV7_NONSEC.

So far this has been somewhat unelegantly solved by writing every
#ifdef CONFIG_ARMV7_NONSEC as:

#if defined(CONFIG_ARMV7_NONSEC) || defined(CONFIG_ARMV7_VIRT)

So that setting CONFIG_ARMV7_VIRT automatically also includes all the
NONSEC bits, note that after this patch we could simply these to just:

#ifdef CONFIG_ARMV7_NONSEC

Which would also more correctly reflect when the code should be enabled.

Regards,

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


Re: [U-Boot] [PATCH] power_spi.c: Rewrite pmic_reg function

2014-10-27 Thread Stefano Babic
Hi Tom.

On 25/10/2014 13:38, Tom Rini wrote:
 The pmic_spi_free function isn't ever used, and as the frameworks stand
 today, cannot be, so remove it.

That's right - it was originally implemented to have a symmetric
interface, but never used.

  Integrate the probe function into
 pmic_reg as it's not really a probe today.  Finally, add an err label
 for the common failure cases.
 
 Cc: Lukasz Majewski l.majew...@samsung.com
 Cc: Przemyslaw Marczak p.marc...@samsung.com
 Cc: Stefano Babic sba...@denx.de
 Signed-off-by: Tom Rini tr...@ti.com
 ---
  drivers/power/power_spi.c |   33 ++---
  1 file changed, 10 insertions(+), 23 deletions(-)
 
 diff --git a/drivers/power/power_spi.c b/drivers/power/power_spi.c
 index fb455a00..1e55446 100644
 --- a/drivers/power/power_spi.c
 +++ b/drivers/power/power_spi.c
 @@ -17,27 +17,14 @@
  
  static struct spi_slave *slave;
  
 -void pmic_spi_free(struct spi_slave *slave)
 -{
 - if (slave)
 - spi_free_slave(slave);
 -}
 -
 -struct spi_slave *pmic_spi_probe(struct pmic *p)
 -{
 - return spi_setup_slave(p-bus,
 - p-hw.spi.cs,
 - p-hw.spi.clk,
 - p-hw.spi.mode);
 -}
 -
  static u32 pmic_reg(struct pmic *p, u32 reg, u32 *val, u32 write)
  {
   u32 pmic_tx, pmic_rx;
   u32 tmp;
  
   if (!slave) {
 - slave = pmic_spi_probe(p);
 + slave = spi_setup_slave(p-bus, p-hw.spi.cs, p-hw.spi.clk,
 + p-hw.spi.mode);
  
   if (!slave)
   return -1;
 @@ -54,25 +41,25 @@ static u32 pmic_reg(struct pmic *p, u32 reg, u32 *val, 
 u32 write)
   tmp = cpu_to_be32(pmic_tx);
  
   if (spi_xfer(slave, pmic_spi_bitlen, tmp, pmic_rx,
 - pmic_spi_flags)) {
 - spi_release_bus(slave);
 - return -1;
 - }
 + pmic_spi_flags))
 + goto err;
  
   if (write) {
   pmic_tx = p-hw.spi.prepare_tx(reg, val, 0);
   tmp = cpu_to_be32(pmic_tx);
   if (spi_xfer(slave, pmic_spi_bitlen, tmp, pmic_rx,
 - pmic_spi_flags)) {
 - spi_release_bus(slave);
 - return -1;
 - }
 + pmic_spi_flags))
 + goto err;
   }
  
   spi_release_bus(slave);
   *val = cpu_to_be32(pmic_rx);
  
   return 0;
 +
 +err:
 + spi_release_bus(slave);
 + return -1;
  }
  
  int pmic_reg_write(struct pmic *p, u32 reg, u32 val)
 

Acked-by: Stefano Babic sba...@denx.de

Best regards,
Stefano Babic

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


[U-Boot] Buildman cookbook

2014-10-27 Thread Wolfgang Denk
Hello,

it would be nice if we could add a buildman cookbok with hints how to
get started quickly with the most frequent use cases (or add some
quickstart section to the README).

Things that I would like to have better documented include:

- dependencies on external tools:

- tools/buildman/buildman --list-tool-chains
Traceback (most recent call last):
  File tools/buildman/buildman, line 10, in module
import multiprocessing
ImportError: No module named multiprocessing

  It would be nice if we could list such dependencies.

  Actually we should probably provide such dependencies for U-Boot in
  general - other tools have similar issues, like:

- tools/genboardscfg.py 
Traceback (most recent call last):
  File tools/genboardscfg.py, line 19, in module
import fnmatch
ImportError: No module named fnmatch

- It would be nice if we could include a sample .buildman file,
  and add documentation what the sections ([toolchain],
  [toolchain-alias]) and entries (root, rest, eldk, arm,
  aarch64) actually mena, which other options exist, and how the
  tool selects a specific tool chain from this list if multiple
  options are present.

- I work a lot with local branches, and regularly run into this:

  - tools/buildman/buildman -n -b tq-generic-board
  No section: 'make-flags'
  Branch 'tq-generic-board' not found or has no upstream

  Can we not avoid this?  Or add a default to master?

  The README recommends to use git branch --set-upstream ..., but
  actually I don't want to do that - it is simply not needed.
  Furthermore, git complains;

  - git branch --set-upstream tq-generic-board master
  The --set-upstream flag is deprecated and will be removed. Consider using 
--track or --set-upstream-to
  Branch tq-generic-board set up to track local branch master.


Thanks.


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
Man braucht zwei Jahre, um sprechen zu lernen,  und fünfzig Jahre, um
schweigen zu lernen.   - Ernest Hemingway
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v4 19/20] tools: kwbimage: Add image version 1 support for Armada XP / 370

2014-10-27 Thread Wolfgang Denk
Dear Stefan,

In message 1413972804-24250-20-git-send-email...@denx.de you wrote:
 This patch integrates the Barebox version of this kwbimage.c file into
 U-Boot. As this version supports the image version 1 type for the
 Armada XP / 370 SoCs.

This commit causes the following build warning on all boards:

tools/kwbimage.c: In function ‘kwbimage_set_header’:
tools/kwbimage.c:784:8: warning: ‘headersz’ may be used uninitialized in this 
function [-Wmaybe-uninitialized]
  memcpy(ptr, image, headersz);
^

The problem is here:


 +static void kwbimage_set_header(void *ptr, struct stat *sbuf, int ifd,
   struct image_tool_params *params)
  {
...
 + size_t headersz;
...
 + version = image_get_version();
 + /* Fallback to version 0 is no version is provided in the cfg file */
 + if (version == -1)
 + version = 0;
 +
 + if (version == 0)
 + image = image_create_v0(headersz, params, sbuf-st_size);
 + else if (version == 1)
 + image = image_create_v1(headersz, params, sbuf-st_size);

If for some reason image_get_version() should return any other result
than -1, 0 or 1, then headersz will remain uninitialized.

Please fix.


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 easiest way to figure the cost of living is to take  your  income
and add ten percent.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 1/2] ARM: Add arch/arm/cpu/armv7/Kconfig with non-secure and virt options

2014-10-27 Thread Ian Campbell
On Fri, 2014-10-24 at 20:34 +0200, Hans de Goede wrote:
 diff --git a/arch/arm/cpu/armv7/Kconfig b/arch/arm/cpu/armv7/Kconfig
 new file mode 100644
 index 000..84e3edb
 --- /dev/null
 +++ b/arch/arm/cpu/armv7/Kconfig
 @@ -0,0 +1,20 @@
 +# FIXME, Once overything in u-boot is properly Kconfig-ified

everything

 +# this entire file should be if ARMV7
 +if ARCH_SUNXI 

Should this not be FOO_SUN7I (FOO depending on when this series lands
wrt my sunxi Kconfig changes). I think we don't want this for any of the
other sun?i, do we?

Ian.


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


Re: [U-Boot] [PATCH 00/14] Set of fixes for Exynos4xxx boards

2014-10-27 Thread Przemyslaw Marczak

Hello,

On 10/24/2014 05:44 PM, Przemyslaw Marczak wrote:

Hello Simon, Tom,

The last driver-model changes was merged too fast and I was not able
to test it well on all my boards. It was worked well for the first
look, but after deep testing - it required some additional work to do.

So this is a set of fixes required for Exynos4xxx boards.
I am not sure what about the Origen.

The patchset was rebased on the top of u-boot-dm/master, which is now:
c2ded96 serial: remove uniphier_serial_initialize() call

Tested on:
- Trats (E4210)
- UniversalC210 (E4210)
- Trats2 (E4412)
- Odroid U3 (E4412)
- Odroid X2 (E4412)

Best Regards,
Przemyslaw Marczak

Przemyslaw Marczak (14):
   mmc: s5p: set SD detection pin as input
   exynos: common: enable generic fs operations
   exynos4/4x12: cpu: add extra gpio base addresses
   exynos4/4x12: gpio: use gpio extra base addresses
   exynos4412: dts: fix bad gpio order in pinctrl
   exynos4412: dts: adjust pinctrl-uboot to changed gpio order
   exynos4210: dts: fix gpio offset in pinctrl-uboot
   universal: request soft i2c gpio
   universal: dts: adjust gpio numbers to new api
   trats: dts: adjust gpio numbers to new api
   trats2: dts: adjust gpio numbers after gpio rework
   odroid: dts: adjust sd cd-gpios for SD Card
   odroid: dts: fix name of included dtsi
   odroid: adjust gpio calls to dm gpio api

  arch/arm/dts/exynos4210-pinctrl-uboot.dtsi |  2 +-
  arch/arm/dts/exynos4210-trats.dts  |  4 +-
  arch/arm/dts/exynos4210-universal_c210.dts |  4 +-
  arch/arm/dts/exynos4412-odroid.dts |  4 +-
  arch/arm/dts/exynos4412-trats2.dts |  6 +--
  arch/arm/dts/exynos4x12-pinctrl-uboot.dtsi |  5 +--
  arch/arm/dts/exynos4x12-pinctrl.dtsi   | 54 +--
  arch/arm/include/asm/arch-exynos/cpu.h |  9 +
  arch/arm/include/asm/arch-exynos/gpio.h| 59 --
  board/samsung/odroid/odroid.c  | 17 -
  board/samsung/universal_c210/universal.c   |  9 +
  drivers/mmc/s5p_sdhci.c|  2 +-
  include/configs/exynos-common.h|  1 +
  13 files changed, 113 insertions(+), 63 deletions(-)


The patchset is also available on github:

https://github.com/bobenstein/u-boot.git
branch: dm_exynos_gpio_fix

Best regards,
--
Przemyslaw Marczak
Samsung RD Institute Poland
Samsung Electronics
p.marc...@samsung.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v3 4/8] common: spl: Add interactive DDR debugger support for SPL image

2014-10-27 Thread Albert ARIBAUD
Hello Alison,

On Fri, 17 Oct 2014 16:00:30 +0800, Alison Wang b18...@freescale.com
wrote:
 To support interactive DDR debugger, cli_simple.o, cli.o, cli_readline.o,
 command.o, s_record.o, xyzModem.o and cmd_disk.o are all needed for
 drivers/ddr/fsl/interactive.c.
 
 In current common/Makefile, the above .o files are only produced when
 CONFIG_SPL_BUILD is disabled.
 
 For LS102xA, interactive DDR debugger is needed in SD/NAND boot too, and
 I enabled CONFIG_FSL_DDR_INTERACTIVE. But according to the current
 common/Makfile, all the above .o files are not produced in SPL part
 because CONFIG_SPL_BUILD is enabled in SPL part, the following error
 will be shown,
 
 drivers/ddr/fsl/built-in.o: In function `fsl_ddr_interactive':
 /home/wangh/layerscape/u-boot/drivers/ddr/fsl/interactive.c:1871:
 undefined reference to `cli_readline_into_buffer'
 /home/wangh/layerscape/u-boot/drivers/ddr/fsl/interactive.c:1873:
 undefined reference to `cli_simple_parse_line'
 make[1]: *** [spl/u-boot-spl] Error 1
 make: *** [spl/u-boot-spl] Error 2
 
 So this patch fixed this issue and the above .o files will be produced
 no matter CONFIG_SPL_BUILD is enabled or disabled.
 
 Signed-off-by: Alison Wang alison.w...@freescale.com
 ---
 Change log:
  v3: Gave more explaination in the commit.
  v2: No change.

This does not apply cleanly. Could you rebase and resubmit?

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


Re: [U-Boot] [PATCH V3 2/3] usb: eth: add ASIX AX88179 DRIVER

2014-10-27 Thread René Griessl

Hello Andy,

 today I'm back from holiday.
There is a lot of different work waiting for me, so I think it will be 
submitted by the end of next week.


Did you try the V3 Patch?

br
  René

Am 06.10.2014 19:45, schrieb Andy Pont:

Hello Rene,


Subject: [U-Boot] [PATCH V3 2/3] usb: eth: add ASIX AX88179 DRIVER

changes in v3:
-added all compatible devices from linux driver
-fixed issues from review

changes in v2:
 -added usb_ether.h to change list
 -added 2nd patch to enable driver for arndale board

Following the additional comments that came from Marek do you know when you
will be submitted a v4 of this patch?

Thanks for your effort on this.

Regards,

Andy.



--



Dipl.-Ing. René Griessl
Universität Bielefeld
AG Kognitronik  Sensorik
Exzellenzcluster Cognitive Interaction Technology (CITEC)
Inspiration 1 (Zehlendorfer Damm 199)
33615 Bielefeld

Telefon : +49 521-106-67362
Fax : +49 521-106-12348
eMail   : rgrie...@cit-ec.uni-bielefeld.de
Internet: http://www.ks.cit-ec.uni-bielefeld.de/

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


Re: [U-Boot] [PATCH 2/4] ARM: HYP/non-sec: Make armv7_init_nonsec() usable before relocation

2014-10-27 Thread Albert ARIBAUD
Hello Yuantian,

On Thu, 16 Oct 2014 04:42:06 +, Yuantian Tang
yuantian.t...@freescale.com wrote:
   Wouldn't it be better to declare gic_dist_base as a local variable?
  It is only used  once outside function armv7_switch_nonsec(). It could
  be replaced with
   get_gicd_base_address() call.
  
  I am with you. That's what I did in the first version of this patch.
  Patch links is at: http://patchwork.ozlabs.org/patch/391065/
  But Albert seems have some concerns. The attached is what we discussed.

FTR, I only had concerns with the patch subject / commit summary.
Regarding the patch itself, I just asked whether the global was not
used as some means of coordination which would have been broken by
turning it into a local, but you had checked, so that was fine.

  Now on the second thought, I prefer the way this patch proposed because
  if we define gic_dist_base as local variable, That means function
  get_gicd_base_address() should be usable at any time in any mode. Can
  we make sure of that in the future?
  
  I don't strongly object introducing a new local variable. But I don't see 
  how the
  global variable is useful. Function get_gicd_base_address() should be 
  available all
  the time. It reads PERIPHBASE register, or return a macro. It hasn't changed
  since the first patch added it in 2013. Not sure if the original author 
  Andre
  Przywara is available to comments.
  
 Thanks for your comments.
 If no one objects the original patch, I like to resubmit it.

 Hi Albert, what's your opinion on this?


Which 'original patch' do you mean?

If it is http://patchwork.ozlabs.org/patch/391065/ then I'm fine with
it and will apply it.
 
 Regards,
 Yuantian
 
  York
  

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


Re: [U-Boot] [PATCH] arm: mvebu: maxbcm: Fix compilation warning and add Spansion SPI NOR support

2014-10-27 Thread Jagan Teki
On 27 October 2014 14:04, Stefan Roese s...@denx.de wrote:
 This patch fixes the following compilation warning for maxbcm:

 Building maxbcm board...
textdata bss dec hex filename
  1600756596   38240  204911   3206f ./u-boot
 board/maxbcm/maxbcm.c: In function 'reset_phy':
 board/maxbcm/maxbcm.c:68:6: warning: unused variable 'reg' [-Wunused-variable]
   u16 reg;
   ^
 board/maxbcm/maxbcm.c:66:6: warning: unused variable 'devadr' 
 [-Wunused-variable]
   u16 devadr = CONFIG_PHY_BASE_ADDR;
   ^

 Additionally support Spansion SPI NOR flash is added. With larger SPI device
 support via the CONFIG_SPI_FLASH_BAR define.

 Signed-off-by: Stefan Roese s...@denx.de
 ---
  board/maxbcm/maxbcm.c| 2 --
  include/configs/maxbcm.h | 2 ++
  2 files changed, 2 insertions(+), 2 deletions(-)

 diff --git a/board/maxbcm/maxbcm.c b/board/maxbcm/maxbcm.c
 index 7fc83ee..94c688f 100644
 --- a/board/maxbcm/maxbcm.c
 +++ b/board/maxbcm/maxbcm.c
 @@ -63,9 +63,7 @@ int checkboard(void)
  /* Configure and enable MV88E6185 switch */
  void reset_phy(void)
  {
 -   u16 devadr = CONFIG_PHY_BASE_ADDR;
 char *name = neta0;
 -   u16 reg;

 if (miiphy_set_current_dev(name))
 return;
 diff --git a/include/configs/maxbcm.h b/include/configs/maxbcm.h
 index 72217bd..005e136 100644
 --- a/include/configs/maxbcm.h
 +++ b/include/configs/maxbcm.h
 @@ -43,6 +43,8 @@
  #define CONFIG_SF_DEFAULT_SPEED100
  #define CONFIG_SF_DEFAULT_MODE SPI_MODE_3
  #define CONFIG_SPI_FLASH_STMICRO
 +#define CONFIG_SPI_FLASH_SPANSION
 +#define CONFIG_SPI_FLASH_BAR

  /* Environment in SPI NOR flash */
  #define CONFIG_ENV_IS_IN_SPI_FLASH

Reviewed-by: Jagannadha Sutradharudu Teki jagannadh.t...@gmail.com

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


Re: [U-Boot] [PATCH v2 3/3] arm: odroid: usb: add support for usb host including ethernet

2014-10-27 Thread Przemyslaw Marczak

Hello Suriyan,

On 10/24/2014 06:08 PM, Suriyan Ramasami wrote:

Hello Minkyu Kang,


On Thu, Oct 23, 2014 at 9:58 PM, Minkyu Kang mk7.k...@samsung.com wrote:

Dear Suriyan Ramasami,

On 21/10/14 02:52, Suriyan Ramasami wrote:

This change adds support for enabling the USB host features of the board.
This includes the USB3503A hub and the SMC LAN9730 ethernet controller
as well.

Credit goes to Tushar Berara for the function set_usb_ethaddr().

Signed-off-by: Suriyan Ramasami suriya...@gmail.com

---
v2:
  * Removed an unneeded header file from ehci-exynos.c
  * Fix indentation in the dts file
---
  arch/arm/dts/exynos4412-odroid.dts  | 11 +++
  arch/arm/include/asm/arch-exynos/cpu.h  |  2 ++
  arch/arm/include/asm/arch-exynos/ehci.h | 13 
  board/samsung/odroid/odroid.c   | 55 +
  drivers/usb/host/ehci-exynos.c  | 51 +-
  include/configs/odroid.h| 13 
  6 files changed, 137 insertions(+), 8 deletions(-)

diff --git a/arch/arm/dts/exynos4412-odroid.dts 
b/arch/arm/dts/exynos4412-odroid.dts
index 24d0bf1..ac5fece 100644
--- a/arch/arm/dts/exynos4412-odroid.dts
+++ b/arch/arm/dts/exynos4412-odroid.dts
@@ -67,4 +67,15 @@
   div = 0x3;
   index = 4;
   };
+
+ ehci@1258 {
+ compatible = samsung,exynos-ehci;
+ reg = 0x1258 0x100;
+ #address-cells = 1;
+ #size-cells = 1;
+ phy {
+ compatible = samsung,exynos-usb-phy;
+ reg = 0x125B 0x100;
+ };
+ };
  };
diff --git a/arch/arm/include/asm/arch-exynos/cpu.h 
b/arch/arm/include/asm/arch-exynos/cpu.h
index ba71714..fda21fb 100644
--- a/arch/arm/include/asm/arch-exynos/cpu.h
+++ b/arch/arm/include/asm/arch-exynos/cpu.h
@@ -18,6 +18,8 @@

  #define EXYNOS4_GPIO_PART3_BASE  0x0386
  #define EXYNOS4_PRO_ID   0x1000
+#define EXYNOS4_GUID_LOW 0x1014
+#define EXYNOS4_GUID_HIGH0x1018
  #define EXYNOS4_SYSREG_BASE  0x1001
  #define EXYNOS4_POWER_BASE   0x1002
  #define EXYNOS4_SWRESET  0x10020400
diff --git a/arch/arm/include/asm/arch-exynos/ehci.h 
b/arch/arm/include/asm/arch-exynos/ehci.h
index d2d70bd..3800fa9 100644
--- a/arch/arm/include/asm/arch-exynos/ehci.h
+++ b/arch/arm/include/asm/arch-exynos/ehci.h
@@ -12,6 +12,13 @@

  #define CLK_24MHZ5

+#define PHYPWR_NORMAL_MASK_PHY0 (0x39  0)
+#define PHYPWR_NORMAL_MASK_PHY1 (0x7  6)
+#define PHYPWR_NORMAL_MASK_HSIC0(0x7  9)
+#define PHYPWR_NORMAL_MASK_HSIC1(0x7  12)
+#define RSTCON_HOSTPHY_SWRST(0xf  3)
+#define RSTCON_SWRST(0x1  0)
+
  #define HOST_CTRL0_PHYSWRSTALL   (1  31)
  #define HOST_CTRL0_COMMONON_N(1  9)
  #define HOST_CTRL0_SIDDQ (1  6)
@@ -61,6 +68,12 @@ struct exynos_usb_phy {
   unsigned int usbotgtune;
  };

+struct exynos4412_usb_phy {
+ unsigned int usbphyctrl;
+ unsigned int usbphyclk;
+ unsigned int usbphyrstcon;
+};
+
  /* Switch on the VBUS power. */
  int board_usb_vbus_init(void);

diff --git a/board/samsung/odroid/odroid.c b/board/samsung/odroid/odroid.c
index 5edb250..6c78b67 100644
--- a/board/samsung/odroid/odroid.c
+++ b/board/samsung/odroid/odroid.c
@@ -453,9 +453,64 @@ struct s3c_plat_otg_data s5pc210_otg_data = {
   .usb_phy_ctrl   = EXYNOS4X12_USBPHY_CONTROL,
   .usb_flags  = PHY0_SLEEP,
  };
+#endif
+
+#if defined(CONFIG_USB_GADGET) || defined(CONFIG_CMD_USB)
+
+#ifdef CONFIG_CMD_USB
+static void set_usb_ethaddr(void)
+{
+ int i;
+ uchar mac[6];
+ unsigned int guid_high = readl(EXYNOS4_GUID_HIGH);
+ unsigned int guid_low = readl(EXYNOS4_GUID_LOW);


We don't allow direct access.
Is it special register? I can't find this register on TRM.
If so you can make inline function at cpu.h instead.



This register is not in the TRM. This register is possibly documented
in the TRM for the Exynos5250. Through experimentation I found that it
behaves the same on Exynos4412 prime as well - I checked this with one
X2, 1 U2 and 2 U3s, and they do indeed do the job of being unique and
hence can be used to generate the mac address which will be unique
across all U2s/U3s/X2s and possibly other Exynos SoCs like Exynos4212
etc.



Those register addresses are not documented anywhere. So use of them is 
not a good idea and can cause unpredictable results, even if was tested 
on a few devices.



Regarding direct access, I am a bit confused. In odroid.c I see quite
a many places which is doing a readl() of registers. Here we are
readl(addr) into guid_* similarly, and cooking up a mac address in a
local char array.

I fail to see your point. Can you please elaborate more, so I can comprehend?



The 

Re: [U-Boot] [PATCH v2 1/3] arm: odroid: pmic77686: allow bucket voltage settings

2014-10-27 Thread Przemyslaw Marczak

Hello Suriyan,

On 10/24/2014 05:53 PM, Suriyan Ramasami wrote:

Hello Jaehoon Chung,


On Thu, Oct 23, 2014 at 11:52 PM, Jaehoon Chung jh80.ch...@samsung.com wrote:

Hi.

On 10/21/2014 02:52 AM, Suriyan Ramasami wrote:

Allow to set the bucket voltage for the max77686.
This will be used to reset the SMC LAN9730 ethernet on the odroids.

Signed-off-by: Suriyan Ramasami suriya...@gmail.com
---
  drivers/power/pmic/pmic_max77686.c | 48 +-
  include/power/max77686_pmic.h  |  3 +++
  2 files changed, 50 insertions(+), 1 deletion(-)

diff --git a/drivers/power/pmic/pmic_max77686.c 
b/drivers/power/pmic/pmic_max77686.c
index df1fd91..1aeadb4 100644
--- a/drivers/power/pmic/pmic_max77686.c
+++ b/drivers/power/pmic/pmic_max77686.c
@@ -42,6 +42,25 @@ static unsigned int max77686_ldo_volt2hex(int ldo, ulong uV)
   return 0;
  }

+static unsigned int max77686_buck_volt2hex(int buck, ulong uV)
+{
+ unsigned int hex = 0;
+
+ if (buck  5 || buck  9) {
+ debug(%s: buck %d is not supported\n, __func__, buck);
+ return 0;


Here, I should return MAX77686_BUCK_VOLT_MAX_HEX + 1 instead of 0 to
signal an error condition, as 0 is a valid non error value.

He 'hex' value has at most 1 byte of len, so you can return the 'int' 
value and use the negative errno numbers - and there is no value conflicts.



+ }
+
+ hex = (uV - 75) / 5;
+
+ if (hex = 0  hex = MAX77686_BUCK_VOLT_MAX_HEX)
+ return hex;
+
+ debug(%s: %ld is wrong voltage value for BUCK%d\n,
+   __func__, uV, buck);
+ return MAX77686_BUCK_VOLT_MAX_HEX + 1;
+}
+
  int max77686_set_ldo_voltage(struct pmic *p, int ldo, ulong uV)
  {
   unsigned int val, ret, hex, adr;
@@ -68,6 +87,33 @@ int max77686_set_ldo_voltage(struct pmic *p, int ldo, ulong 
uV)
   return ret;
  }

+int max77686_set_buck_voltage(struct pmic *p, int buck, ulong uV)
+{
+ unsigned int val, ret, hex, adr;
+
+ if (buck  5  buck  9) {
+ printf(%s: %d is an unsupported bucket number\n,
+__func__, buck);
+ return -1;


How about using error number instead of -1?


Could you please elaborate on this? This function always returns -1 on
failure just like the function max77686_set_ldo_voltate() which I have
tried to mimic as much as I can.
I am guessing that you want me to return -EINVAL in this case? Please
let me know, and I am OK to change it, just that this function will
deviate from the rest of the functions in this file.


Yes, this will be better.



+ }
+
+ adr = max77686_buck_addr[buck] + 1;
+ hex = max77686_buck_volt2hex(buck, uV);
+


if (hex  0)
return hex;


+ if (hex == MAX77686_BUCK_VOLT_MAX_HEX + 1)
+ return -1;


Ditto.


I believe, I return -EINVAL here, but please look at my reasoning above.




+
+ ret = pmic_reg_read(p, adr, val);
+ if (ret)
+ return ret;
+
+ val = ~MAX77686_BUCK_VOLT_MASK;
+ val |= hex;
+ ret |= pmic_reg_write(p, adr, val);


ret |= pmic_reg_write(p, addr, val | hex); ?



OK, will change that. Again, this was done to be as close to
max77686_set_ldo_voltate()

Thanks and Regards!
- Suriyan


Best Regards,
Jaehoon Chung

+
+ return ret;
+}
+
  int max77686_set_ldo_mode(struct pmic *p, int ldo, char opmode)
  {
   unsigned int val, ret, adr, mode;
@@ -157,7 +203,7 @@ int max77686_set_buck_mode(struct pmic *p, int buck, char 
opmode)
   /* mode */
   switch (opmode) {
   case OPMODE_OFF:
- mode = MAX77686_BUCK_MODE_OFF;
+ mode = MAX77686_BUCK_MODE_OFF  mode_shift;
   break;
   case OPMODE_STANDBY:
   switch (buck) {
diff --git a/include/power/max77686_pmic.h b/include/power/max77686_pmic.h
index c2a772a..b0e4255 100644
--- a/include/power/max77686_pmic.h
+++ b/include/power/max77686_pmic.h
@@ -150,6 +150,7 @@ enum {

  int max77686_set_ldo_voltage(struct pmic *p, int ldo, ulong uV);
  int max77686_set_ldo_mode(struct pmic *p, int ldo, char opmode);
+int max77686_set_buck_voltage(struct pmic *p, int buck, ulong uV);
  int max77686_set_buck_mode(struct pmic *p, int buck, char opmode);

  #define MAX77686_LDO_VOLT_MAX_HEX0x3f
@@ -159,6 +160,8 @@ int max77686_set_buck_mode(struct pmic *p, int buck, char 
opmode);
  #define MAX77686_LDO_MODE_STANDBY(0x01  0x06)
  #define MAX77686_LDO_MODE_LPM(0x02  0x06)
  #define MAX77686_LDO_MODE_ON (0x03  0x06)
+#define MAX77686_BUCK_VOLT_MAX_HEX   0x3f
+#define MAX77686_BUCK_VOLT_MASK  0x3f
  #define MAX77686_BUCK_MODE_MASK  0x03
  #define MAX77686_BUCK_MODE_SHIFT_1   0x00
  #define MAX77686_BUCK_MODE_SHIFT_2   0x04





Best regards,
--
Przemyslaw Marczak
Samsung RD Institute Poland
Samsung Electronics
p.marc...@samsung.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v2 7/7] sunxi: kconfig: Add %_felconfig rule to enable FEL build of sunxi platforms.

2014-10-27 Thread Hans de Goede
Hi,

On 10/24/2014 10:20 PM, Ian Campbell wrote:
 $ make BOARD_felconfig
 is more convenient than
 $ make BOARD_defconfig
 $ echo CONFIG_SPL_FEL=y  .config
 $ echo CONFIG_SPL_FEL=y  spl/.config
 
 Signed-off-by: Ian Campbell i...@hellion.org.uk
 ---
 v2: New patch.
 
 Is this a good idea?

Yes!

All patches look good to me and are:

Reviewed-by: Hans de Goede hdego...@redhat.com

I've pushed this series to u-boot-sunxi/next

Regards,

Hans



 ---
  scripts/multiconfig.sh | 12 
  1 file changed, 12 insertions(+)
 
 diff --git a/scripts/multiconfig.sh b/scripts/multiconfig.sh
 index 3e3040b..70f3a5d 100644
 --- a/scripts/multiconfig.sh
 +++ b/scripts/multiconfig.sh
 @@ -162,6 +162,16 @@ do_defconfig () {
   fi
  }
  
 +do_board_felconfig () {
 +do_board_defconfig ${1%%_felconfig}_defconfig
 +if ! grep -q CONFIG_ARCH_SUNXI=y .config || ! grep -q CONFIG_SPL=y 
 .config ; then
 + echo $progname: Cannot felconfig a non-sunxi or non-SPL platform 2
 + exit 1
 +fi
 +sed -i -e 's/\# CONFIG_SPL_FEL is not set/CONFIG_SPL_FEL=y/g' \
 + .config spl/.config
 +}
 +
  do_savedefconfig () {
   if [ -r $KCONFIG_CONFIG ]; then
   subimages=$(get_enabled_subimages)
 @@ -323,6 +333,8 @@ target=$1
  case $target in
  *_defconfig)
   do_board_defconfig $target;;
 +*_felconfig)
 + do_board_felconfig $target;;
  *_config)
   # backward compatibility
   do_board_defconfig ${target%_config}_defconfig;;
 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 1/5] imx: gpt: Add 24Mhz OSC clock source support for GPT

2014-10-27 Thread Stefano Babic
Hi Ye,

On 27/10/2014 05:10, Li Ye-B37916 wrote:
 
 The patch is used to add a choice for GPT clock source to provide high 
 frequency clock.  The configuration CONFIG_MXC_GPT_HCLK is not dependent on 
 the chip version. Even it is i.MX28, it is ok to set the configuration.

Ok, thanks for clarification.

 
 The implementation has handled the differences between the chips.
 Most of i.MX6 series supports to use 24Mhz OSC as its high clock source 
 (except MX6Q/D Rev 1.0 and MX6SL).  So for i.MX6, the implementation uses the 
 24Mhz OSC.
 For others (the time.c only compiles for i.MX5 and i.MX6, so the other is 
 i.MX5),  they don't have 24Mhz OSC source for GPT. When the configuration is 
 set, we use perclk instead.

It should be not bad if you check for MX5 and CONFIG_MXC_GPT_HCLK and
raise an error at compile time. This configuration is wrong and the
error should be reported and not hidden at runtime.

 
 I feel the patch subject need to modify, like add HCLK clock source for 
 GPT, then people may not confuse.

Agree, do it.

 
 MX6Q/D Rev 1.0 and MX6SL can't use the 24Mhz OSC clock source option,
 so select the perclk for them. For MX6SL, we will set the OSC 24Mhz to
 perclk in CCM, so eventually the clock comes from OSC 24Mhz.

 I am trying to understand. The explanation here does not reflect in the
 implementation.  From the implementation, it is possible to set it even
 with wrong revision.
 
 As explained above, the implementation has handled the differences. Users 
 does not need to care the revision. For example, when the image runs on a  
 MX6Q/D Rev 1.0 chip, the perclk will be selected not the 24Mhz OSC.
 
 Anyway, I do not think it is correct to put it as a configuration
 option. This makes that we need different binaries for different
 revisions of the SOC. It should be checked at runtime if the revision is
 correct to set this clock as source. gpt_has_clk_source_osc has a check,
 but does it make sense that CONFIG_MXC_GPT_HCLK can be set in any case ?
 Only i.MX5 and i.MX6 uses the GPT driver. I think the CONFIG_MXC_GPT_HCLK can 
 be set in any case.

Well, but if does not make sense for i.MX5, why do we have to accept it ?

 
 Signed-off-by: Ye.Li b37...@freescale.com
 ---
 Is this a second version of the patchset ? What are the changes ? Please
 add version number to your patchset and write a history about changes. I
 can suggest to use Simon's patman to post your patches.
 
 I met a email problem last Friday. I can't get any email from 
 u-boot@lists.denx.de for a long time. So I mistakenly thought
 the first patches are failed and send out second.

Never mind ;-)

 
  arch/arm/imx-common/timer.c |   76 
 +--
  1 files changed, 66 insertions(+), 10 deletions(-)

 diff --git a/arch/arm/imx-common/timer.c b/arch/arm/imx-common/timer.c
 index c63f78f..f7e49bd 100644
 --- a/arch/arm/imx-common/timer.c
 +++ b/arch/arm/imx-common/timer.c
 @@ -2,7 +2,7 @@
   * (C) Copyright 2007
   * Sascha Hauer, Pengutronix
   *
 - * (C) Copyright 2009 Freescale Semiconductor, Inc.
 + * (C) Copyright 2009-2014 Freescale Semiconductor, Inc.
 I have already complain about this. There are a lot of commits after the
 file was merged into u-boot, and a lot of them not directly by
 Freescale. I do not think it is legally correct to change the Copyright.
 
 Will fix this.

Thanks

 
   *
   * SPDX-License-Identifier:GPL-2.0+
   */
 @@ -12,6 +12,7 @@
  #include div64.h
  #include asm/arch/imx-regs.h
  #include asm/arch/clock.h
 +#include asm/arch/sys_proto.h
  
  /* General purpose timers registers */
  struct mxc_gpt {
 @@ -26,23 +27,60 @@ static struct mxc_gpt *cur_gpt = (struct mxc_gpt 
 *)GPT1_BASE_ADDR;
  
  /* General purpose timers bitfields */
  #define GPTCR_SWR  (1  15)   /* Software reset */
 +#define GPTCR_24MEN(1  10)   /* Enable 24MHz clock input 
 from crystal */
  #define GPTCR_FRR  (1  9)/* Freerun / restart */
 -#define GPTCR_CLKSOURCE_32 (4  6)/* Clock source */
 +#define GPTCR_CLKSOURCE_32 (4  6)/* Clock source 32khz */
 +#define GPTCR_CLKSOURCE_OSC(5  6)/* Clock source OSC */
 +#define GPTCR_CLKSOURCE_PRE(1  6)/* Clock source PRECLK 
 */
 +#define GPTCR_CLKSOURCE_MASK (0x7  6)
  #define GPTCR_TEN  1   /* Timer enable */
  
 +#define GPTPR_PRESCALER24M_SHIFT 12
 +#define GPTPR_PRESCALER24M_MASK (0xF  GPTPR_PRESCALER24M_SHIFT)
 +
  DECLARE_GLOBAL_DATA_PTR;
  
 +static inline int gpt_has_clk_source_osc(void)
 +{
 +#if defined(CONFIG_MX6)
 +   if (((is_cpu_type(MXC_CPU_MX6Q) || is_cpu_type(MXC_CPU_MX6D))
 +(is_soc_rev(CHIP_REV_1_0)  0))
 +   || is_cpu_type(MXC_CPU_MX6DL) || is_cpu_type(MXC_CPU_MX6SOLO)
 +   || is_cpu_type(MXC_CPU_MX6SX))
 +   return 1;
 +
 +   return 0;
 +#else
 +   return 0;
 +#endif
 We are generally trying to get rid of #ifdef, but it seems we are not
 going in the right direction. 

Re: [U-Boot] [PATCH v1 1/1] odroid: Turn blue LED on in u-boot

2014-10-27 Thread Przemyslaw Marczak

Hello Suriyan,

On 10/10/2014 12:20 AM, Suriyan Ramasami wrote:

To indicate that u-boot is active turn on the blue LED.

Signed-off-by: Suriyan Ramasami suriya...@gmail.com
---
  board/samsung/odroid/odroid.c | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/board/samsung/odroid/odroid.c b/board/samsung/odroid/odroid.c
index fd5d2d2..391a287 100644
--- a/board/samsung/odroid/odroid.c
+++ b/board/samsung/odroid/odroid.c
@@ -374,6 +374,9 @@ static void board_gpio_init(void)
gpio_set_pull(EXYNOS4X12_GPIO_X31, S5P_GPIO_PULL_UP);
gpio_set_drv(EXYNOS4X12_GPIO_X31, S5P_GPIO_DRV_4X);
gpio_direction_input(EXYNOS4X12_GPIO_X31);
+
+   /* Enable blue LED */


Here you will need to add gpio_request() call, e.g.
http://patchwork.ozlabs.org/patch/403197/



+   gpio_direction_output(EXYNOS4X12_GPIO_C10, 0);
  }

  static int pmic_init_max77686(void)



This looks good, but please wait until the patch series merge:
http://patchwork.ozlabs.org/patch/403186/ (starts from this commit)

Best regards,
--
Przemyslaw Marczak
Samsung RD Institute Poland
Samsung Electronics
p.marc...@samsung.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] tools/kwbimage.c: fix parser error handling

2014-10-27 Thread Jeroen Hofstee

Hello Andreas,

On 24-10-14 23:25, andreas.de...@googlemail.com wrote:

From: Andreas Bießmann andreas.de...@googlemail.com

The two error checks for image_boot_mode_id and image_nand_ecc_mode_id where
wrong and would never fail, fix that!

This was detected by Apple's clang compiler:
---8---
   HOSTCC  tools/kwbimage.o
tools/kwbimage.c:553:20: warning: comparison of unsigned expression  0 is 
always false [-Wtautological-compare]
 if (el-bootfrom  0) {
  ^ ~
tools/kwbimage.c:571:23: warning: comparison of unsigned expression  0 is 
always false [-Wtautological-compare]
 if (el-nandeccmode  0) {
 ~~~ ^ ~
2 warnings generated.
---8---

Signed-off-by: Andreas Bießmann andreas.de...@googlemail.com
---

  tools/kwbimage.c | 14 --
  1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/tools/kwbimage.c b/tools/kwbimage.c
index 42870ed..8fd70ef 100644
--- a/tools/kwbimage.c
+++ b/tools/kwbimage.c
@@ -548,13 +548,14 @@ static int image_create_config_parse_oneline(char *line,
el-version = atoi(value);
} else if (!strcmp(keyword, BOOT_FROM)) {
char *value = strtok_r(NULL, deliminiters, saveptr);
-   el-type = IMAGE_CFG_BOOT_FROM;
-   el-bootfrom = image_boot_mode_id(value);
-   if (el-bootfrom  0) {
+   int ret = image_boot_mode_id(value);
+   if (ret  0) {
fprintf(stderr,
Invalid boot media '%s'\n, value);
return -1;
}
+   el-type = IMAGE_CFG_BOOT_FROM;
+   el-bootfrom = ret;
} else if (!strcmp(keyword, NAND_BLKSZ)) {
char *value = strtok_r(NULL, deliminiters, saveptr);
el-type = IMAGE_CFG_NAND_BLKSZ;
@@ -566,13 +567,14 @@ static int image_create_config_parse_oneline(char *line,
strtoul(value, NULL, 16);
} else if (!strcmp(keyword, NAND_ECC_MODE)) {
char *value = strtok_r(NULL, deliminiters, saveptr);
-   el-type = IMAGE_CFG_NAND_ECC_MODE;
-   el-nandeccmode = image_nand_ecc_mode_id(value);
-   if (el-nandeccmode  0) {
+   int ret = image_nand_ecc_mode_id(value);


Thanks for fixing this. Could you move the int ret declaration before
actual code though?

Regards,
Jeroen


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


[U-Boot] [PATCH 1/8] powerpc/mpc85xx: Add T1024/T1023 SoC support

2014-10-27 Thread Shengzhou Liu
Add support for Freescale T1024/T1023 SoC.

The T1024 SoC includes the following function and features:
- Two 64-bit Power architecture e5500 cores, up to 1.4GHz
- private 256KB L2 cache each core and shared 256KB CoreNet platform cache (CPC)
- 32-/64-bit DDR3L/DDR4 SDRAM memory controller with ECC and interleaving 
support
- Data Path Acceleration Architecture (DPAA) incorporating acceleration
- Four MAC for 1G/2.5G/10G network interfaces (RGMII, SGMII, QSGMII, XFI)
- High-speed peripheral interfaces
  - Three PCI Express 2.0 controllers
- Additional peripheral interfaces
  - One SATA 2.0 controller
  - Two USB 2.0 controllers with integrated PHY
  - Enhanced secure digital host controller (SD/eSDHC/eMMC)
  - Enhanced serial peripheral interface (eSPI)
  - Four I2C controllers
  - Four 2-pin UARTs or two 4-pin UARTs
  - Integrated Flash Controller supporting NAND and NOR flash
- Two 8-channel DMA engines
- Multicore programmable interrupt controller (PIC)
- LCD interface (DIU) with 12 bit dual data rate
- QUICC Engine block supporting TDM, HDLC, and UART
- Deep Sleep power implementaion (wakeup from GPIO/Timer/Ethernet/USB)
- Support for hardware virtualization and partitioning enforcement
- QorIQ Platform's Trust Architecture 2.0

Differences between T1024 and T1023:
  Feature T1024  T1023
  QUICC Engine:   yesno
  DIU:yesno
  Deep Sleep: yesno
  I2C controller: 4  3
  DDR:64-bit 32-bit
  IFC:32-bit 28-bit

Signed-off-by: Shengzhou Liu shengzhou@freescale.com
---
 arch/powerpc/cpu/mpc85xx/Makefile  |  4 ++
 arch/powerpc/cpu/mpc85xx/speed.c   | 12 +++-
 arch/powerpc/cpu/mpc85xx/t1024_ids.c   | 82 
 arch/powerpc/cpu/mpc85xx/t1024_serdes.c| 50 +
 arch/powerpc/cpu/mpc8xxx/cpu.c |  4 ++
 arch/powerpc/include/asm/config_mpc85xx.h  | 45 +++
 arch/powerpc/include/asm/fsl_secure_boot.h |  4 +-
 arch/powerpc/include/asm/immap_85xx.h  | 14 +
 arch/powerpc/include/asm/processor.h   |  4 ++
 drivers/net/fm/Makefile|  2 +
 drivers/net/fm/t1024.c | 88 ++
 11 files changed, 307 insertions(+), 2 deletions(-)
 create mode 100644 arch/powerpc/cpu/mpc85xx/t1024_ids.c
 create mode 100644 arch/powerpc/cpu/mpc85xx/t1024_serdes.c
 create mode 100644 drivers/net/fm/t1024.c

diff --git a/arch/powerpc/cpu/mpc85xx/Makefile 
b/arch/powerpc/cpu/mpc85xx/Makefile
index ad26b43..b93158b 100644
--- a/arch/powerpc/cpu/mpc85xx/Makefile
+++ b/arch/powerpc/cpu/mpc85xx/Makefile
@@ -51,6 +51,8 @@ obj-$(CONFIG_PPC_T1040) += t1040_ids.o
 obj-$(CONFIG_PPC_T1042)+= t1040_ids.o
 obj-$(CONFIG_PPC_T1020)+= t1040_ids.o
 obj-$(CONFIG_PPC_T1022)+= t1040_ids.o
+obj-$(CONFIG_PPC_T1023) += t1024_ids.o
+obj-$(CONFIG_PPC_T1024) += t1024_ids.o
 obj-$(CONFIG_PPC_T2080) += t2080_ids.o
 obj-$(CONFIG_PPC_T2081) += t2080_ids.o
 
@@ -97,6 +99,8 @@ obj-$(CONFIG_PPC_T1040) += t1040_serdes.o
 obj-$(CONFIG_PPC_T1042)+= t1040_serdes.o
 obj-$(CONFIG_PPC_T1020)+= t1040_serdes.o
 obj-$(CONFIG_PPC_T1022)+= t1040_serdes.o
+obj-$(CONFIG_PPC_T1023) += t1024_serdes.o
+obj-$(CONFIG_PPC_T1024) += t1024_serdes.o
 obj-$(CONFIG_PPC_T2080) += t2080_serdes.o
 obj-$(CONFIG_PPC_T2081) += t2080_serdes.o
 
diff --git a/arch/powerpc/cpu/mpc85xx/speed.c b/arch/powerpc/cpu/mpc85xx/speed.c
index 3236f6a..ac46f6b 100644
--- a/arch/powerpc/cpu/mpc85xx/speed.c
+++ b/arch/powerpc/cpu/mpc85xx/speed.c
@@ -168,6 +168,9 @@ void get_sys_info(sys_info_t *sys_info)
defined(CONFIG_PPC_T2080) || defined(CONFIG_PPC_T2081)
 #define FM1_CLK_SEL0xe000
 #define FM1_CLK_SHIFT  29
+#elif defined(CONFIG_PPC_T1024) || defined(CONFIG_PPC_T1023)
+#define FM1_CLK_SEL0x0007
+#define FM1_CLK_SHIFT  0
 #else
 #define PME_CLK_SEL0xe000
 #define PME_CLK_SHIFT  29
@@ -175,8 +178,12 @@ void get_sys_info(sys_info_t *sys_info)
 #define FM1_CLK_SHIFT  26
 #endif
 #if !defined(CONFIG_FM_PLAT_CLK_DIV) || !defined(CONFIG_PME_PLAT_CLK_DIV)
+#if defined(CONFIG_PPC_T1024) || defined(CONFIG_PPC_T1023)
+   rcw_tmp = in_be32(gur-rcwsr[15]) - 4;
+#else
rcw_tmp = in_be32(gur-rcwsr[7]);
 #endif
+#endif
 
 #ifdef CONFIG_SYS_DPAA_PME
 #ifndef CONFIG_PME_PLAT_CLK_DIV
@@ -213,7 +220,10 @@ void get_sys_info(sys_info_t *sys_info)
 #endif
 
 #ifdef CONFIG_SYS_DPAA_QBMAN
-   sys_info-freq_qman = sys_info-freq_systembus / 2;
+#ifndef CONFIG_QBMAN_CLK_DIV
+#define CONFIG_QBMAN_CLK_DIV   2
+#endif
+   sys_info-freq_qman = sys_info-freq_systembus / CONFIG_QBMAN_CLK_DIV;
 #endif
 
 #ifdef CONFIG_SYS_DPAA_FMAN
diff --git a/arch/powerpc/cpu/mpc85xx/t1024_ids.c 
b/arch/powerpc/cpu/mpc85xx/t1024_ids.c
new file mode 100644
index 000..5f24c15
--- /dev/null
+++ b/arch/powerpc/cpu/mpc85xx/t1024_ids.c
@@ -0,0 +1,82 @@
+/*
+ * Copyright 2014 Freescale Semiconductor, Inc.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+

[U-Boot] [PATCH 4/8] net/fman: tune fman 10G driver to fit different SoC

2014-10-27 Thread Shengzhou Liu
- 10GEC1 uses mEMAC1 on T1024.
- 10GEC1/10GEC2 use mEMAC9/mEMAC10 on T2080/T4240.
- 10GEC3/10GEC4 use mEMAC1/mEMAC2 on T2080.
As there are anomalous naming for 10GEC on earlier SoCs(e.g. T2080/T4240),
now we introduce macro CONFIG_FSL_FM_TGEC_NORMAL_NAMING for those SoC
(e.g. T1024) with inerratic naming for 10GEC to fit different SoC.

Signed-off-by: Shengzhou Liu shengzhou@freescale.com
---
 arch/powerpc/include/asm/config_mpc85xx.h |  1 +
 arch/powerpc/include/asm/immap_85xx.h |  5 +
 drivers/net/fm/eth.c  |  7 +--
 drivers/net/fm/init.c |  2 ++
 include/fm_eth.h  | 15 +++
 5 files changed, 28 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/include/asm/config_mpc85xx.h 
b/arch/powerpc/include/asm/config_mpc85xx.h
index 73c28da..704a388 100644
--- a/arch/powerpc/include/asm/config_mpc85xx.h
+++ b/arch/powerpc/include/asm/config_mpc85xx.h
@@ -809,6 +809,7 @@ defined(CONFIG_PPC_T1014) || defined(CONFIG_PPC_T1013)
 #define CONFIG_SYS_NUM_FMAN1
 #define CONFIG_SYS_NUM_FM1_DTSEC   4
 #define CONFIG_SYS_NUM_FM1_10GEC   1
+#define CONFIG_FSL_FM_TGEC_NORMAL_NAMING
 #define CONFIG_NUM_DDR_CONTROLLERS 1
 #define CONFIG_USB_MAX_CONTROLLER_COUNT2
 #define CONFIG_SYS_FSL_DDR_VER  FSL_DDR_VER_5_0
diff --git a/arch/powerpc/include/asm/immap_85xx.h 
b/arch/powerpc/include/asm/immap_85xx.h
index c267da9..2128999 100644
--- a/arch/powerpc/include/asm/immap_85xx.h
+++ b/arch/powerpc/include/asm/immap_85xx.h
@@ -1625,10 +1625,15 @@ typedef struct ccsr_gur {
 #define FSL_CORENET_DEVDISR2_DTSEC1_6  0x0400
 #define FSL_CORENET_DEVDISR2_DTSEC1_9  0x0080
 #define FSL_CORENET_DEVDISR2_DTSEC1_10 0x0040
+#ifdef CONFIG_FSL_FM_TGEC_NORMAL_NAMING
+#define FSL_CORENET_DEVDISR2_10GEC1_1   0x8000
+#define FSL_CORENET_DEVDISR2_10GEC1_2   0x4000
+#else
 #define FSL_CORENET_DEVDISR2_10GEC1_1  0x0080
 #define FSL_CORENET_DEVDISR2_10GEC1_2  0x0040
 #define FSL_CORENET_DEVDISR2_10GEC1_3  0x8000
 #define FSL_CORENET_DEVDISR2_10GEC1_4  0x4000
+#endif
 #define FSL_CORENET_DEVDISR2_DTSEC2_1  0x0008
 #define FSL_CORENET_DEVDISR2_DTSEC2_2  0x0004
 #define FSL_CORENET_DEVDISR2_DTSEC2_3  0x0002
diff --git a/drivers/net/fm/eth.c b/drivers/net/fm/eth.c
index 137886c..5ebc775 100644
--- a/drivers/net/fm/eth.c
+++ b/drivers/net/fm/eth.c
@@ -565,9 +565,11 @@ static int fm_eth_init_mac(struct fm_eth *fm_eth, struct 
ccsr_fman *reg)
num = fm_eth-num;
 
 #ifdef CONFIG_SYS_FMAN_V3
+#ifndef CONFIG_FSL_FM_TGEC_NORMAL_NAMING
if (fm_eth-type == FM_ETH_10G_E) {
-   /* 10GEC1/10GEC2 use mEMAC9/mEMAC10
-* 10GEC3/10GEC4 use mEMAC1/mEMAC2
+   /* 10GEC1/10GEC2 use mEMAC9/mEMAC10 on T2080/T4240.
+* 10GEC3/10GEC4 use mEMAC1/mEMAC2 on T2080.
+* 10GEC1 uses mEMAC1 on T1024.
 * so it needs to change the num.
 */
if (fm_eth-num = 2)
@@ -575,6 +577,7 @@ static int fm_eth_init_mac(struct fm_eth *fm_eth, struct 
ccsr_fman *reg)
else
num += 8;
}
+#endif
base = reg-memac[num].fm_memac;
phyregs = reg-memac[num].fm_memac_mdio;
 #else
diff --git a/drivers/net/fm/init.c b/drivers/net/fm/init.c
index 6cf21c6..5d82f29 100644
--- a/drivers/net/fm/init.c
+++ b/drivers/net/fm/init.c
@@ -254,8 +254,10 @@ static void ft_fixup_port(void *blob, struct fm_eth_info 
*info, char *prop)
 */
if (((info-port == FM1_DTSEC9)  (PORT_IS_ENABLED(FM1_10GEC1)))  ||
((info-port == FM1_DTSEC10)  (PORT_IS_ENABLED(FM1_10GEC2))) ||
+   ((info-port == FM1_DTSEC1)  (PORT_IS_ENABLED(FM1_10GEC1)))  ||
((info-port == FM1_DTSEC1)  (PORT_IS_ENABLED(FM1_10GEC3)))  ||
((info-port == FM1_DTSEC2)  (PORT_IS_ENABLED(FM1_10GEC4)))  ||
+   ((info-port == FM1_10GEC1)  (PORT_IS_ENABLED(FM1_DTSEC1)))  ||
((info-port == FM1_10GEC1)  (PORT_IS_ENABLED(FM1_DTSEC9)))  ||
((info-port == FM1_10GEC2)  (PORT_IS_ENABLED(FM1_DTSEC10))) ||
((info-port == FM1_10GEC3)  (PORT_IS_ENABLED(FM1_DTSEC1)))  ||
diff --git a/include/fm_eth.h b/include/fm_eth.h
index e46a684..5cd1895 100644
--- a/include/fm_eth.h
+++ b/include/fm_eth.h
@@ -75,6 +75,20 @@ enum fm_eth_type {
offsetof(struct ccsr_fman, memac[n-1]),\
 }
 
+#ifdef CONFIG_FSL_FM_TGEC_NORMAL_NAMING
+#define FM_TGEC_INFO_INITIALIZER(idx, n) \
+{  \
+   FM_ETH_INFO_INITIALIZER(idx, CONFIG_SYS_FM1_TGEC_MDIO_ADDR) \
+   .index  = idx,  \
+   .num= n - 1,\
+   .type   = FM_ETH_10G_E, \
+   .port   = FM##idx##_10GEC##n,   \
+   

[U-Boot] [PATCH 2/8] powerpc/t1024qds: Add T1024 QDS board support

2014-10-27 Thread Shengzhou Liu
T1024QDS is a high-performance computing evaluation, development and
test platform for T1024 QorIQ Power Architecture processor.

T1024QDS board Overview
---
- T1024 SoC integrating two 64-bit e5500 cores up to 1.4GHz
- CoreNet fabric supporting coherent and noncoherent transactions with
  prioritization and bandwidth allocation
- 32-/64-bit DDR3L/DDR4 SDRAM memory controller with ECC and interleaving 
support
- Accelerator: DPAA components consist of FMan, BMan, QMan, PME, DCE and SEC
- Ethernet interfaces:
  - Two 10M/100M/1G RGMII ports on-board
  - Three 1G/2.5Gbps SGMII ports
  - Four 1Gbps QSGMII ports
  - one 10Gbps XFI or 10Base-KR interface
- SerDes: 4 lanes up to 10.3125GHz Supporting SGMII/QSGMII, XFI, PCIe, SATA and 
Aurora
- PCIe: Three PCI Express controllers with five PCIe slots.
- IFC: 128MB NOR Flash, 2GB NAND Flash, PromJet debug port and Qixis FPGA
- Video: DIU supports video up to 1280x1024x32 bpp.
  - Chrontel CH7201 for HDMI connection.
  - TI DS90C387R for direct LCD connection.
  - Raw (not encoded) video connector for testing or other encoders.
- QUICC Engine block
  - 32-bit RISC controller for flexible support of the communications 
peripherals
  - Serial DMA channel for receive and transmit on all serial channels
  - Two universal communication controllers, supporting TDM, HDLC, and UART
- Deep Sleep power implementaion (wakeup from GPIO/Timer/Ethernet/USB)
- eSPI: Three SPI flash devices.
- SATA: one SATA 2.O.
- USB: Two USB2.0 ports with internal PHY (one Type-A + one micro Type mini-AB)
- eSDHC: Support SD, SDHC, SDXC and MMC/eMMC.
- I2C: Four I2C controllers.
- UART: Two UART on board.

Signed-off-by: Shengzhou Liu shengzhou@freescale.com
---
 arch/powerpc/cpu/mpc85xx/Kconfig  |   4 +
 board/freescale/t102xqds/Kconfig  |  12 +
 board/freescale/t102xqds/MAINTAINERS  |  17 +
 board/freescale/t102xqds/Makefile |  17 +
 board/freescale/t102xqds/README   | 328 +++
 board/freescale/t102xqds/ddr.c| 170 ++
 board/freescale/t102xqds/diu.c| 217 +++
 board/freescale/t102xqds/eth_t102xqds.c   | 442 ++
 board/freescale/t102xqds/law.c|  32 +
 board/freescale/t102xqds/pci.c|  23 +
 board/freescale/t102xqds/spl.c| 151 +
 board/freescale/t102xqds/t1024_pbi.cfg|  26 +
 board/freescale/t102xqds/t1024_rcw.cfg|  10 +
 board/freescale/t102xqds/t102xqds.c   | 319 ++
 board/freescale/t102xqds/t102xqds.h   |  14 +
 board/freescale/t102xqds/t102xqds_qixis.h |  61 ++
 board/freescale/t102xqds/tlb.c| 117 
 configs/T1024QDS_D4_SECURE_BOOT_defconfig |   4 +
 configs/T1024QDS_NAND_defconfig   |   5 +
 configs/T1024QDS_SDCARD_defconfig |   5 +
 configs/T1024QDS_SECURE_BOOT_defconfig|   4 +
 configs/T1024QDS_SPIFLASH_defconfig   |   5 +
 include/configs/T102xQDS.h| 935 ++
 23 files changed, 2918 insertions(+)
 create mode 100644 board/freescale/t102xqds/Kconfig
 create mode 100644 board/freescale/t102xqds/MAINTAINERS
 create mode 100644 board/freescale/t102xqds/Makefile
 create mode 100644 board/freescale/t102xqds/README
 create mode 100644 board/freescale/t102xqds/ddr.c
 create mode 100644 board/freescale/t102xqds/diu.c
 create mode 100644 board/freescale/t102xqds/eth_t102xqds.c
 create mode 100644 board/freescale/t102xqds/law.c
 create mode 100644 board/freescale/t102xqds/pci.c
 create mode 100644 board/freescale/t102xqds/spl.c
 create mode 100644 board/freescale/t102xqds/t1024_pbi.cfg
 create mode 100644 board/freescale/t102xqds/t1024_rcw.cfg
 create mode 100644 board/freescale/t102xqds/t102xqds.c
 create mode 100644 board/freescale/t102xqds/t102xqds.h
 create mode 100644 board/freescale/t102xqds/t102xqds_qixis.h
 create mode 100644 board/freescale/t102xqds/tlb.c
 create mode 100644 configs/T1024QDS_D4_SECURE_BOOT_defconfig
 create mode 100644 configs/T1024QDS_NAND_defconfig
 create mode 100644 configs/T1024QDS_SDCARD_defconfig
 create mode 100644 configs/T1024QDS_SECURE_BOOT_defconfig
 create mode 100644 configs/T1024QDS_SPIFLASH_defconfig
 create mode 100644 include/configs/T102xQDS.h

diff --git a/arch/powerpc/cpu/mpc85xx/Kconfig b/arch/powerpc/cpu/mpc85xx/Kconfig
index 8c1c01c..64331de 100644
--- a/arch/powerpc/cpu/mpc85xx/Kconfig
+++ b/arch/powerpc/cpu/mpc85xx/Kconfig
@@ -100,6 +100,9 @@ config TARGET_P2041RDB
 config TARGET_QEMU_PPCE500
bool Support qemu-ppce500
 
+config TARGET_T102XQDS
+   bool Support T102xQDS
+
 config TARGET_T1040QDS
bool Support T1040QDS
 
@@ -170,6 +173,7 @@ source board/freescale/p2020come/Kconfig
 source board/freescale/p2020ds/Kconfig
 source board/freescale/p2041rdb/Kconfig
 source board/freescale/qemu-ppce500/Kconfig
+source board/freescale/t102xqds/Kconfig
 source board/freescale/t1040qds/Kconfig
 source board/freescale/t104xrdb/Kconfig
 source board/freescale/t208xqds/Kconfig
diff --git 

[U-Boot] [PATCH 7/8] t1024: increase IO drive strength

2014-10-27 Thread Shengzhou Liu
Increase IO drive strength to fix FCS error on RGMII ports
on T1024QDS and T1024RDB.

Signed-off-by: Shengzhou Liu shengzhou@freescale.com
---
 arch/powerpc/include/asm/immap_85xx.h | 3 +++
 board/freescale/t102xqds/t102xqds.c   | 4 
 board/freescale/t102xrdb/t102xrdb.c   | 3 +++
 3 files changed, 10 insertions(+)

diff --git a/arch/powerpc/include/asm/immap_85xx.h 
b/arch/powerpc/include/asm/immap_85xx.h
index 2128999..bf3adc7 100644
--- a/arch/powerpc/include/asm/immap_85xx.h
+++ b/arch/powerpc/include/asm/immap_85xx.h
@@ -1802,6 +1802,7 @@ defined(CONFIG_PPC_T1020) || defined(CONFIG_PPC_T1022)
 #define FSL_CORENET_RCWSR13_EC20x0c00
 #define FSL_CORENET_RCWSR13_EC2_RGMII  0x0800
 #define CONFIG_SYS_FSL_SCFG_PIXCLKCR_OFFSET0x28
+#define CONFIG_SYS_FSL_SCFG_IODSECR1_OFFSET0xd00
 #define PXCKEN_MASK0x8000
 #define PXCK_MASK  0x00FF
 #define PXCK_BITS_START16
@@ -3051,6 +3052,8 @@ struct ccsr_sfp_regs {
(CONFIG_SYS_CCSRBAR + CONFIG_SYS_FSL_SCFG_OFFSET)
 #define CONFIG_SYS_FSL_SCFG_PIXCLK_ADDR\
(CONFIG_SYS_FSL_SCFG_ADDR + CONFIG_SYS_FSL_SCFG_PIXCLKCR_OFFSET)
+#define CONFIG_SYS_FSL_SCFG_IODSECR1_ADDR \
+   (CONFIG_SYS_FSL_SCFG_ADDR + CONFIG_SYS_FSL_SCFG_IODSECR1_OFFSET)
 #define CONFIG_SYS_FSL_QMAN_ADDR \
(CONFIG_SYS_IMMR + CONFIG_SYS_FSL_QMAN_OFFSET)
 #define CONFIG_SYS_FSL_BMAN_ADDR \
diff --git a/board/freescale/t102xqds/t102xqds.c 
b/board/freescale/t102xqds/t102xqds.c
index f7fc869..013024e 100644
--- a/board/freescale/t102xqds/t102xqds.c
+++ b/board/freescale/t102xqds/t102xqds.c
@@ -220,6 +220,10 @@ int board_early_init_r(void)
 #endif
select_i2c_ch_pca9547(I2C_MUX_CH_DEFAULT);
board_mux_lane_to_slot();
+
+   /* Increase IO drive strength to address FCS error on RGMII */
+   out_be32((unsigned *)CONFIG_SYS_FSL_SCFG_IODSECR1_ADDR, 0xbfdb7800);
+
return 0;
 }
 
diff --git a/board/freescale/t102xrdb/t102xrdb.c 
b/board/freescale/t102xrdb/t102xrdb.c
index b1211d7..f1e19c4 100644
--- a/board/freescale/t102xrdb/t102xrdb.c
+++ b/board/freescale/t102xrdb/t102xrdb.c
@@ -87,6 +87,9 @@ int board_early_init_r(void)
setup_portals();
 #endif
 
+   /* Increase IO drive strength to address FCS error on RGMII */
+   out_be32((unsigned *)CONFIG_SYS_FSL_SCFG_IODSECR1_ADDR, 0xbfdb7800);
+
return 0;
 }
 
-- 
2.1.0.27.g96db324

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


[U-Boot] [PATCH 5/8] board/t1024qds: some update for pin mux

2014-10-27 Thread Shengzhou Liu
1. add fdt_fixup_spi_mux() for spi mux between SPI flash and TDM riser.
2. if adaptor=sdxc is set in hwconfig, route spi pin to SDHC slot.
3. if pin_mux=tdm is set in hwconfig, route spi pin to TDM Riser Card.

Signed-off-by: Shengzhou Liu shengzhou@freescale.com
Signed-off-by: Xie Xiaobo x@freescale.com
Signed-off-by: Zhao Qiang b45...@freescale.com
---
 board/freescale/t102xqds/t102xqds.c   | 26 ++
 board/freescale/t102xqds/t102xqds_qixis.h |  7 +--
 2 files changed, 31 insertions(+), 2 deletions(-)

diff --git a/board/freescale/t102xqds/t102xqds.c 
b/board/freescale/t102xqds/t102xqds.c
index f7af332..f7fc869 100644
--- a/board/freescale/t102xqds/t102xqds.c
+++ b/board/freescale/t102xqds/t102xqds.c
@@ -165,6 +165,8 @@ static void board_mux_setup(void)
/* Route QE_TDM multiplexed signals to TDM Riser slot */
QIXIS_WRITE(brdcfg[15], brdcfg15 | BRDCFG15_DIUSEL_TDM);
QIXIS_WRITE(brdcfg[13], BRDCFG13_TDM_INTERFACE  2);
+   QIXIS_WRITE(brdcfg[5], (QIXIS_READ(brdcfg[5]) 
+   ~BRDCFG5_SPIRTE_MASK) | BRDCFG5_SPIRTE_TDM);
} else if (hwconfig_arg_cmp(pin_mux, ucc)) {
/* to UCC (ProfiBus) interface */
QIXIS_WRITE(brdcfg[15], brdcfg15 | BRDCFG15_DIUSEL_UCC);
@@ -176,6 +178,11 @@ static void board_mux_setup(void)
QIXIS_WRITE(brdcfg[15], brdcfg15 | BRDCFG15_LCDFM |
BRDCFG15_LCDPD | BRDCFG15_DIUSEL_LCD);
}
+
+   if (hwconfig_arg_cmp(adaptor, sdxc))
+   /* Route SPI_CS multiplexed signals to SD slot */
+   QIXIS_WRITE(brdcfg[5], (QIXIS_READ(brdcfg[5]) 
+   ~BRDCFG5_SPIRTE_MASK) | BRDCFG5_SPIRTE_SDHC);
 }
 #endif
 
@@ -265,6 +272,24 @@ int misc_init_r(void)
return 0;
 }
 
+void fdt_fixup_spi_mux(void *blob)
+{
+   int nodeoff = 0;
+
+   if (hwconfig_arg_cmp(pin_mux, tdm)) {
+   while ((nodeoff = fdt_node_offset_by_compatible(blob, 0,
+   eon,en25s64)) = 0) {
+   fdt_del_node(blob, nodeoff);
+   }
+   } else {
+   /* remove tdm node */
+   while ((nodeoff = fdt_node_offset_by_compatible(blob, 0,
+   maxim,ds26522)) = 0) {
+   fdt_del_node(blob, nodeoff);
+   }
+   }
+}
+
 void ft_board_setup(void *blob, bd_t *bd)
 {
phys_addr_t base;
@@ -291,6 +316,7 @@ void ft_board_setup(void *blob, bd_t *bd)
fdt_fixup_fman_ethernet(blob);
fdt_fixup_board_enet(blob);
 #endif
+   fdt_fixup_spi_mux(blob);
 }
 
 void qixis_dump_switch(void)
diff --git a/board/freescale/t102xqds/t102xqds_qixis.h 
b/board/freescale/t102xqds/t102xqds_qixis.h
index ad83f03..a429fb7 100644
--- a/board/freescale/t102xqds/t102xqds_qixis.h
+++ b/board/freescale/t102xqds/t102xqds_qixis.h
@@ -17,6 +17,9 @@
 #define BRDCFG5_IMX_MASK   0xC0
 #define BRDCFG5_IMX_DIU0x80
 
+#define BRDCFG5_SPIRTE_MASK0x07
+#define BRDCFG5_SPIRTE_TDM 0x01
+#define BRDCFG5_SPIRTE_SDHC0x02
 #define BRDCFG9_XFI_TX_DISABLE 0x10
 
 /* BRDCFG13[0:5] TDM configuration and setup */
@@ -35,8 +38,8 @@
 #define BRDCFG15_DIUSEL_MASK   0x03
 #define BRDCFG15_DIUSEL_HDMI   0x00
 #define BRDCFG15_DIUSEL_LCD0x01
-#define BRDCFG15_DIUSEL_UCC0x10
-#define BRDCFG15_DIUSEL_TDM0x11
+#define BRDCFG15_DIUSEL_UCC0x02
+#define BRDCFG15_DIUSEL_TDM0x03
 
 /* SYSCLK */
 #define QIXIS_SYSCLK_660x0
-- 
2.1.0.27.g96db324

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


[U-Boot] [PATCH 8/8] board/t1024qds: add retimer support on t1024qds

2014-10-27 Thread Shengzhou Liu
Initialize retimer for XFI on t1024qds.

Signed-off-by: Shengzhou Liu shengzhou@freescale.com
---
 board/freescale/t102xqds/t102xqds.c | 57 +
 include/configs/T102xQDS.h  |  5 +++-
 2 files changed, 61 insertions(+), 1 deletion(-)

diff --git a/board/freescale/t102xqds/t102xqds.c 
b/board/freescale/t102xqds/t102xqds.c
index 013024e..1398663 100644
--- a/board/freescale/t102xqds/t102xqds.c
+++ b/board/freescale/t102xqds/t102xqds.c
@@ -186,6 +186,62 @@ static void board_mux_setup(void)
 }
 #endif
 
+void board_retimer_init(void)
+{
+   u8 reg;
+
+   /* Retimer is connected to I2C1_CH7_CH5 */
+   reg = I2C_MUX_CH7;
+   i2c_write(I2C_MUX_PCA_ADDR_PRI, 0, 1, reg, 1);
+   reg = I2C_MUX_CH5;
+   i2c_write(I2C_MUX_PCA_ADDR_SEC, 0, 1, reg, 1);
+
+   /* Access to Control/Shared register */
+   reg = 0x0;
+   i2c_write(I2C_RETIMER_ADDR, 0xff, 1, reg, 1);
+
+   /* Read device revision and ID */
+   i2c_read(I2C_RETIMER_ADDR, 1, 1, reg, 1);
+   debug(Retimer version id = 0x%x\n, reg);
+
+   /* Enable Broadcast. All writes target all channel register sets */
+   reg = 0x0c;
+   i2c_write(I2C_RETIMER_ADDR, 0xff, 1, reg, 1);
+
+   /* Reset Channel Registers */
+   i2c_read(I2C_RETIMER_ADDR, 0, 1, reg, 1);
+   reg |= 0x4;
+   i2c_write(I2C_RETIMER_ADDR, 0, 1, reg, 1);
+
+   /* Enable override divider select and Enable Override Output Mux */
+   i2c_read(I2C_RETIMER_ADDR, 9, 1, reg, 1);
+   reg |= 0x24;
+   i2c_write(I2C_RETIMER_ADDR, 9, 1, reg, 1);
+
+   /* Select VCO Divider to full rate (000) */
+   i2c_read(I2C_RETIMER_ADDR, 0x18, 1, reg, 1);
+   reg = 0x8f;
+   i2c_write(I2C_RETIMER_ADDR, 0x18, 1, reg, 1);
+
+   /* Selects active PFD MUX Input as Re-timed Data (001) */
+   i2c_read(I2C_RETIMER_ADDR, 0x1e, 1, reg, 1);
+   reg = 0x3f;
+   reg |= 0x20;
+   i2c_write(I2C_RETIMER_ADDR, 0x1e, 1, reg, 1);
+
+   /* Set data rate as 10.3125 Gbps */
+   reg = 0x0;
+   i2c_write(I2C_RETIMER_ADDR, 0x60, 1, reg, 1);
+   reg = 0xb2;
+   i2c_write(I2C_RETIMER_ADDR, 0x61, 1, reg, 1);
+   reg = 0x90;
+   i2c_write(I2C_RETIMER_ADDR, 0x62, 1, reg, 1);
+   reg = 0xb3;
+   i2c_write(I2C_RETIMER_ADDR, 0x63, 1, reg, 1);
+   reg = 0xcd;
+   i2c_write(I2C_RETIMER_ADDR, 0x64, 1, reg, 1);
+}
+
 int board_early_init_r(void)
 {
 #ifdef CONFIG_SYS_FLASH_BASE
@@ -220,6 +276,7 @@ int board_early_init_r(void)
 #endif
select_i2c_ch_pca9547(I2C_MUX_CH_DEFAULT);
board_mux_lane_to_slot();
+   board_retimer_init();
 
/* Increase IO drive strength to address FCS error on RGMII */
out_be32((unsigned *)CONFIG_SYS_FSL_SCFG_IODSECR1_ADDR, 0xbfdb7800);
diff --git a/include/configs/T102xQDS.h b/include/configs/T102xQDS.h
index 5f8f749..fe24181 100644
--- a/include/configs/T102xQDS.h
+++ b/include/configs/T102xQDS.h
@@ -554,11 +554,14 @@ unsigned long get_board_ddr_clk(void);
 
 #define I2C_MUX_PCA_ADDR   0x77
 #define I2C_MUX_PCA_ADDR_PRI   0x77 /* Primary Mux*/
-
+#define I2C_MUX_PCA_ADDR_SEC0x76 /* Secondary multiplexer */
+#define I2C_RETIMER_ADDR   0x18
 
 /* I2C bus multiplexer */
 #define I2C_MUX_CH_DEFAULT  0x8
 #define I2C_MUX_CH_DIU 0xC
+#define I2C_MUX_CH50xD
+#define I2C_MUX_CH70xF
 
 /* LDI/DVI Encoder for display */
 #define CONFIG_SYS_I2C_LDI_ADDR 0x38
-- 
2.1.0.27.g96db324

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


[U-Boot] [PATCH 6/8] net/phy: enable serdes autonegotiation for vsc8514 phy

2014-10-27 Thread Shengzhou Liu
QSGMII doesn't work without enabling serdes auto-negotiation.

Signed-off-by: Shengzhou Liu shengzhou@freescale.com
---
 drivers/net/phy/vitesse.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/net/phy/vitesse.c b/drivers/net/phy/vitesse.c
index 2b29cd8..5b2e11a 100644
--- a/drivers/net/phy/vitesse.c
+++ b/drivers/net/phy/vitesse.c
@@ -50,6 +50,7 @@
 #define MIIM_VSC8574_18G_CMDSTAT   0x8000
 
 /* Vitesse VSC8514 control register */
+#define MIIM_VSC8514_MAC_SERDES_CON 0x10
 #define MIIM_VSC8514_GENERAL18 0x12
 #define MIIM_VSC8514_GENERAL19 0x13
 #define MIIM_VSC8514_GENERAL23 0x17
@@ -246,6 +247,14 @@ static int vsc8514_config(struct phy_device *phydev)
val = (val  0xf8ff);
phy_write(phydev, MDIO_DEVAD_NONE, MIIM_VSC8514_GENERAL23, val);
 
+   /* Enable Serdes Auto-negotiation */
+   phy_write(phydev, MDIO_DEVAD_NONE, PHY_EXT_PAGE_ACCESS,
+ PHY_EXT_PAGE_ACCESS_EXTENDED3);
+   val = phy_read(phydev, MDIO_DEVAD_NONE, MIIM_VSC8514_MAC_SERDES_CON);
+   val = val | MIIM_VSC8574_MAC_SERDES_ANEG;
+   phy_write(phydev, MDIO_DEVAD_NONE, MIIM_VSC8514_MAC_SERDES_CON, val);
+   phy_write(phydev, MDIO_DEVAD_NONE, PHY_EXT_PAGE_ACCESS, 0);
+
genphy_config_aneg(phydev);
 
return 0;
-- 
2.1.0.27.g96db324

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


[U-Boot] [PATCH 3/8] powerpc/t1024rdb: Add T1024 RDB board support

2014-10-27 Thread Shengzhou Liu
T1024RDB is a Freescale Reference Design Board that hosts the T1024 SoC.

T1024RDB board Overview
---
- T1024 SoC integrating two 64-bit e5500 cores up to 1.4GHz
- CoreNet fabric supporting coherent and noncoherent transactions with
  prioritization and bandwidth allocation
- 32-/64-bit DDR3L SDRAM memory controller with ECC and interleaving support
- Accelerator: DPAA components consist of FMan, BMan, QMan, DCE and SEC
- Ethernet interfaces:
  - Two 10M/100M/1G RGMII ports on-board
  - one 10Gbps XFI interface
- PCIe: Three PCIe controllers: one PCIe Slot and two Mini-PCIe connectors.
- SerDes: 4 lanes up to 10.3125GHz
- IFC: 128MB NOR Flash, 512MB NAND Flash and CPLD
- eSPI: 64MB N25Q512 SPI flash.
- Deep Sleep power implementaion (wakeup from GPIO/Timer/Ethernet/USB)
- USB: Two  Type-A USB2.0 ports with internal PHY
- eSDHC: Support SD, SDHC, SDXC and MMC/eMMC
- I2C: Four I2C controllers
- UART: Two UART serial ports

Signed-off-by: Shengzhou Liu shengzhou@freescale.com
---
 arch/powerpc/cpu/mpc85xx/Kconfig|   4 +
 board/freescale/t102xrdb/Kconfig|  12 +
 board/freescale/t102xrdb/MAINTAINERS|  14 +
 board/freescale/t102xrdb/Makefile   |  17 +
 board/freescale/t102xrdb/README | 258 +
 board/freescale/t102xrdb/cpld.c | 103 
 board/freescale/t102xrdb/cpld.h |  45 ++
 board/freescale/t102xrdb/ddr.c  | 154 ++
 board/freescale/t102xrdb/eth_t102xrdb.c | 100 
 board/freescale/t102xrdb/law.c  |  32 ++
 board/freescale/t102xrdb/pci.c  |  23 +
 board/freescale/t102xrdb/spl.c  | 107 
 board/freescale/t102xrdb/t1024_pbi.cfg  |  26 +
 board/freescale/t102xrdb/t1024_rcw.cfg  |   8 +
 board/freescale/t102xrdb/t102xrdb.c | 142 +
 board/freescale/t102xrdb/t102xrdb.h |  13 +
 board/freescale/t102xrdb/tlb.c  | 117 +
 configs/T1024RDB_NAND_defconfig |   5 +
 configs/T1024RDB_SDCARD_defconfig   |   5 +
 configs/T1024RDB_SECURE_BOOT_defconfig  |   4 +
 configs/T1024RDB_SPIFLASH_defconfig |   5 +
 configs/T1024RDB_defconfig  |   4 +
 include/configs/T102xRDB.h  | 896 
 23 files changed, 2094 insertions(+)
 create mode 100644 board/freescale/t102xrdb/Kconfig
 create mode 100644 board/freescale/t102xrdb/MAINTAINERS
 create mode 100644 board/freescale/t102xrdb/Makefile
 create mode 100644 board/freescale/t102xrdb/README
 create mode 100644 board/freescale/t102xrdb/cpld.c
 create mode 100644 board/freescale/t102xrdb/cpld.h
 create mode 100644 board/freescale/t102xrdb/ddr.c
 create mode 100644 board/freescale/t102xrdb/eth_t102xrdb.c
 create mode 100644 board/freescale/t102xrdb/law.c
 create mode 100644 board/freescale/t102xrdb/pci.c
 create mode 100644 board/freescale/t102xrdb/spl.c
 create mode 100644 board/freescale/t102xrdb/t1024_pbi.cfg
 create mode 100644 board/freescale/t102xrdb/t1024_rcw.cfg
 create mode 100644 board/freescale/t102xrdb/t102xrdb.c
 create mode 100644 board/freescale/t102xrdb/t102xrdb.h
 create mode 100644 board/freescale/t102xrdb/tlb.c
 create mode 100644 configs/T1024RDB_NAND_defconfig
 create mode 100644 configs/T1024RDB_SDCARD_defconfig
 create mode 100644 configs/T1024RDB_SECURE_BOOT_defconfig
 create mode 100644 configs/T1024RDB_SPIFLASH_defconfig
 create mode 100644 configs/T1024RDB_defconfig
 create mode 100644 include/configs/T102xRDB.h

diff --git a/arch/powerpc/cpu/mpc85xx/Kconfig b/arch/powerpc/cpu/mpc85xx/Kconfig
index 64331de..74b9b7d 100644
--- a/arch/powerpc/cpu/mpc85xx/Kconfig
+++ b/arch/powerpc/cpu/mpc85xx/Kconfig
@@ -103,6 +103,9 @@ config TARGET_QEMU_PPCE500
 config TARGET_T102XQDS
bool Support T102xQDS
 
+config TARGET_T102XRDB
+   bool Support T102xRDB
+
 config TARGET_T1040QDS
bool Support T1040QDS
 
@@ -174,6 +177,7 @@ source board/freescale/p2020ds/Kconfig
 source board/freescale/p2041rdb/Kconfig
 source board/freescale/qemu-ppce500/Kconfig
 source board/freescale/t102xqds/Kconfig
+source board/freescale/t102xrdb/Kconfig
 source board/freescale/t1040qds/Kconfig
 source board/freescale/t104xrdb/Kconfig
 source board/freescale/t208xqds/Kconfig
diff --git a/board/freescale/t102xrdb/Kconfig b/board/freescale/t102xrdb/Kconfig
new file mode 100644
index 000..10d49f5
--- /dev/null
+++ b/board/freescale/t102xrdb/Kconfig
@@ -0,0 +1,12 @@
+if TARGET_T102XRDB
+
+config SYS_BOARD
+   default t102xrdb
+
+config SYS_VENDOR
+   default freescale
+
+config SYS_CONFIG_NAME
+   default T102xRDB
+
+endif
diff --git a/board/freescale/t102xrdb/MAINTAINERS 
b/board/freescale/t102xrdb/MAINTAINERS
new file mode 100644
index 000..ab1ecca
--- /dev/null
+++ b/board/freescale/t102xrdb/MAINTAINERS
@@ -0,0 +1,14 @@
+T102XRDB BOARD
+M: Shengzhou Liu  shengzhou@freescale.com
+S: Maintained
+F: board/freescale/t102xrdb/
+F: include/configs/T102xRDB.h
+F: configs/T1024RDB_defconfig
+F: configs/T1024RDB_NAND_defconfig
+F: 

[U-Boot] [PATCH] tools/kwbimage: Fix compilation warning

2014-10-27 Thread Stefan Roese
This patch fixes a compilation warning of kwbimage.c:

tools/kwbimage.c: In function ‘kwbimage_set_header’:
tools/kwbimage.c:784:8: warning: ‘headersz’ may be used uninitialized in this 
function [-Wmaybe-uninitialized]
  memcpy(ptr, image, headersz);
^
Instead of using multiple if statements, use a switch statement with
a default entry. And return with error if the VERSION field is
missing in the cfg file.

Signed-off-by: Stefan Roese s...@denx.de
---
 tools/kwbimage.c | 24 ++--
 1 file changed, 18 insertions(+), 6 deletions(-)

diff --git a/tools/kwbimage.c b/tools/kwbimage.c
index 1120e9b..91db5d7 100644
--- a/tools/kwbimage.c
+++ b/tools/kwbimage.c
@@ -752,14 +752,26 @@ static void kwbimage_set_header(void *ptr, struct stat 
*sbuf, int ifd,
}
 
version = image_get_version();
-   /* Fallback to version 0 is no version is provided in the cfg file */
-   if (version == -1)
-   version = 0;
-
-   if (version == 0)
+   switch (version) {
+   /*
+* Fallback to version 0 is no version is provided in the
+* cfg file
+*/
+   case -1:
+   case 0:
image = image_create_v0(headersz, params, sbuf-st_size);
-   else if (version == 1)
+   break;
+
+   case 1:
image = image_create_v1(headersz, params, sbuf-st_size);
+   break;
+
+   default:
+   fprintf(stderr, File %s does not have the VERSION field\n,
+   params-imagename);
+   free(image_cfg);
+   exit(EXIT_FAILURE);
+   }
 
if (!image) {
fprintf(stderr, Could not create image\n);
-- 
2.1.2

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


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

2014-10-27 Thread Stefano Babic
Hi Tom,

please pull from u-boot-imx, thanks !

The following changes since commit c43fd23cf619856b0763a64a6a3bcf3663058c49:

  Prepare v2014.10 (2014-10-14 04:47:15 -0400)

are available in the git repository at:

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

for you to fetch changes up to 3f97af5302ee15530411232b464d255eb2ff2ffb:

  ot1200: add sata support (2014-10-23 10:04:26 +0200)


Christian Gmeiner (3):
  ot1200: remove superfluous string tag
  ot1200: fix sf detection
  ot1200: add sata support

Eric Nelson (4):
  ARM: prevent compiler warnings from bootm.c
  ARM: i.MX6: include prototype for get_board_rev()
  ARM: i.MX: provide declaration for board_spi_cs_gpio
  ARM: i.MX video: declare displays and display_count publicly

Fabio Estevam (2):
  mx6qsabreauto: Add HDMI support
  mx6sabre_common: Add HDMI config to common code

 arch/arm/cpu/armv7/mx6/soc.c  |  1 +
 arch/arm/imx-common/video.c   |  3 --
 arch/arm/include/asm/imx-common/spi.h | 17 
 arch/arm/include/asm/imx-common/video.h   |  5 +++
 arch/arm/lib/bootm.c  |  5 ++-
 board/bachmann/ot1200/Kconfig |  5 ---
 board/bachmann/ot1200/ot1200.c| 10 +
 board/boundary/nitrogen6x/nitrogen6x.c|  1 +
 board/compulab/cm_fx6/common.c|  1 +
 board/embest/mx6boards/mx6boards.c|  1 +
 board/freescale/mx6qsabreauto/mx6qsabreauto.c | 61
++-
 board/freescale/mx6slevk/mx6slevk.c   |  1 +
 board/gateworks/gw_ventana/gw_ventana.c   |  1 +
 board/genesi/mx51_efikamx/efikamx.c   |  1 +
 board/ttcontrol/vision2/vision2.c |  1 +
 drivers/spi/mxc_spi.c |  1 +
 include/configs/mx6sabre_common.h | 17 
 include/configs/mx6sabresd.h  | 17 
 include/configs/ot1200.h  |  2 +-
 19 files changed, 123 insertions(+), 28 deletions(-)
 create mode 100644 arch/arm/include/asm/imx-common/spi.h


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


Re: [U-Boot] [PATCH 00/19] [RFC] Power(full) framework based on Driver Model

2014-10-27 Thread Przemyslaw Marczak

Hello Tom,

On 10/22/2014 05:31 PM, Tom Rini wrote:

On Wed, Oct 08, 2014 at 10:48:36PM +0200, Przemyslaw Marczak wrote:


Hello,
This piece of code was a base for prepare my presentation talk
for the U-Boot Mini Summit, which taking place at ELCE2014 conference,
13-th October 2014 Dusseldorf, Germany.

The tittle of talk: Power(full) framework based on Driver Model

The presentation will be shared after the Summit.

This patchset introduces the new one PMIC framework for the U-Boot.
It is still under the construction, but the basic functionality was
achieved and tested. Please feel free to comment and share the opinion.

I think that each patch is described full enough, but for some more design
details, please look into the documentation file. It includes some basic
examples for the PMIC drivers.

Quick summary of:
Framework:
- The new approach - UCLASS_PMIC - simple and designed for device I/O only
- Add new uclass types: UCLASS_PMIC and UCLASS_PMIC_REGULATOR
- Two uclass drivers for above types
- A common regulator operations - will easy cover the real devices design

Drivers:
- Introduce new PMIC API for drivers - now everything base on struct udevice
- Introduce Regulator Voltage descriptors and Operation Mode descriptors
   which are usually taken from the device tree (board dependent data)
- Two uclass device drivers for MAX77686(PMIC+REGULATOR)

User Interface:
- command pmic, unchanged functionality and ported to the driver model
- command regulator(NEW) for safe regulator setup from commandline,
   - now can check output Voltage and operation mode of the regulators,
   - also can check the board Voltage limits and driver available modes

The future plans:
- Wait for the I2c Driver Model implementation
- Introduce a common way to bind pmic devices - now done by alias pmic
- Add additional uclass types: MUIC, CHARGER, BATTERY, MFD and maybe more.
- Introduce optimal operations for new uclasses
- Port all U-Boot drivers to the new Framework
- Remove the old drivers and the old PMIC Framework code

The assumptions of this work is:
- Add new code to independent files
- Keep two Frameworks as independent and without conflicts
- Don't mix OLD/NEW Framework code - for the readability
- Port all drivers using new API
- Remove the old Framework and the old drivers

A disadvantage:
- some parts of the present code is duplicated

Need help:
- After merge this, it is welcome to help with driver porting.
- Everything should be tested

The extra feature:
The first commit introduces errno_str() function.
It is a common function which I hope will be usefull for commands and not only.
If any visible error says: -19 or some other magic number, then it means that
this function should be used.

U-Boot Mini Summit members:
This code is maybe not as good as it could be, but the time was limited,
and the conference is comming soon. I don't expects a code review of this
now, but it would be nice if you take a look of this piece of code before
our U-Boot Mini Summit. Of course it depends on you.


Per the mini-summit, please add a patch adding yourself as pmic
custodian (so something to doc/git-mailrc, shoot me your patchwork
username and Detlev an ssh key so we can get a repo setup).  For this
series, I'm going to review/ack and I want Simon to pick it up for the
DM tree since I think that makes the most sense, yes?  Thanks!

And for all the patches in the series I don't reply to, they seem fine
but aren't for me to ack (being board specific stuff, that looked fine
but I don't have the HW) or I just agree with Simon's comments.



Ok, so this code will be rebased on to u-boot-dm/i2c-working.
And I will send the required informations to you and Detlev.

Best Regards,
--
Przemyslaw Marczak
Samsung RD Institute Poland
Samsung Electronics
p.marc...@samsung.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH] gic: fixed compilation error in GICv2 wait for interrupt macro

2014-10-27 Thread Yehuda Yitschak
a hexadicemal value was missing the 0x prefix which caused
assembler error

Signed-off-by: Yehuda Yitschak yehu...@marvell.com
---
 arch/arm/include/asm/macro.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/macro.h b/arch/arm/include/asm/macro.h
index 541b443..1c8c425 100644
--- a/arch/arm/include/asm/macro.h
+++ b/arch/arm/include/asm/macro.h
@@ -193,7 +193,7 @@ lr  .reqx30
 0 :wfi
ldr \wreg2, [\xreg1, GICC_AIAR]
str \wreg2, [\xreg1, GICC_AEOIR]
-   and \wreg2, \wreg2, #3ff
+   and \wreg2, \wreg2, #0x3ff
cbnz\wreg2, 0b
 .endm
 #endif
-- 
1.8.1.2

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


Re: [U-Boot] [PATCH] tools/kwbimage: Fix compilation warning

2014-10-27 Thread Wolfgang Denk
Dear Stefan,

In message 1414412953-25615-1-git-send-email...@denx.de you wrote:
 This patch fixes a compilation warning of kwbimage.c:
 
 tools/kwbimage.c: In function ‘kwbimage_set_header’:
 tools/kwbimage.c:784:8: warning: ‘headersz’ may be used uninitialized in this 
 function [-Wmaybe-uninitialized]
   memcpy(ptr, image, headersz);
 ^
 Instead of using multiple if statements, use a switch statement with
 a default entry. And return with error if the VERSION field is
 missing in the cfg file.

Thanks, but...

 + switch (version) {
 + /*
 +  * Fallback to version 0 is no version is provided in the
 +  * cfg file
 +  */
 + case -1:
 + case 0:
   image = image_create_v0(headersz, params, sbuf-st_size);
 + break;
 +
 + case 1:
   image = image_create_v1(headersz, params, sbuf-st_size);
 + break;
 +
 + default:
 + fprintf(stderr, File %s does not have the VERSION field\n,
 + params-imagename);
 + free(image_cfg);
 + exit(EXIT_FAILURE);
 + }

What exactly is the difference between return code -1 (no version is
provided and you fall back to using version 0), and the default case?

To me these look the same?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Wenn Du ein' weise Antwort verlangst, Mußt Du vernünftig fragen.
-- Goethe, Invektiven
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 2/8] powerpc/t1024qds: Add T1024 QDS board support

2014-10-27 Thread Wolfgang Denk
Dear Shengzhou Liu,

In message 1414411583-45090-2-git-send-email-shengzhou@freescale.com you 
wrote:
 T1024QDS is a high-performance computing evaluation, development and
 test platform for T1024 QorIQ Power Architecture processor.
...
 diff --git a/board/freescale/t102xqds/MAINTAINERS 
 b/board/freescale/t102xqds/MAINTAINERS
 new file mode 100644
 index 000..fc09c00
 --- /dev/null
 +++ b/board/freescale/t102xqds/MAINTAINERS
 @@ -0,0 +1,17 @@
 +T102XQDS BOARD
 +M:   Shengzhou Liu  shengzhou@freescale.com

Please do not add trailing white space.


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
Any fool can make things bigger, more complex, and more  violent.  It
takes  a  touch  of  genius  -  and a lot of courage - to move in the
opposite direction. - Albert Einstein
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 3/8] powerpc/t1024rdb: Add T1024 RDB board support

2014-10-27 Thread Wolfgang Denk
Dear Shengzhou Liu,

In message 1414411583-45090-3-git-send-email-shengzhou@freescale.com you 
wrote:
 T1024RDB is a Freescale Reference Design Board that hosts the T1024 SoC.
...
 --- /dev/null
 +++ b/board/freescale/t102xrdb/MAINTAINERS
 @@ -0,0 +1,14 @@
 +T102XRDB BOARD
 +M:   Shengzhou Liu  shengzhou@freescale.com

Please do not add trailing white space.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
I think it's a new feature. Don't tell anyone it was an accident. :-)
  -- Larry Wall on s/foo/bar/eieio in 10...@jpl-devvax.jpl.nasa.gov
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v2 3/3] arm: odroid: usb: add support for usb host including ethernet

2014-10-27 Thread Minkyu Kang
Dear Suriyan Ramasami,

On 25/10/14 01:08, Suriyan Ramasami wrote:
 Hello Minkyu Kang,
 
 
 On Thu, Oct 23, 2014 at 9:58 PM, Minkyu Kang mk7.k...@samsung.com wrote:
 Dear Suriyan Ramasami,

 On 21/10/14 02:52, Suriyan Ramasami wrote:
 This change adds support for enabling the USB host features of the board.
 This includes the USB3503A hub and the SMC LAN9730 ethernet controller
 as well.

 Credit goes to Tushar Berara for the function set_usb_ethaddr().

 Signed-off-by: Suriyan Ramasami suriya...@gmail.com

 ---
 v2:
  * Removed an unneeded header file from ehci-exynos.c
  * Fix indentation in the dts file
 ---
  arch/arm/dts/exynos4412-odroid.dts  | 11 +++
  arch/arm/include/asm/arch-exynos/cpu.h  |  2 ++
  arch/arm/include/asm/arch-exynos/ehci.h | 13 
  board/samsung/odroid/odroid.c   | 55 
 +
  drivers/usb/host/ehci-exynos.c  | 51 +-
  include/configs/odroid.h| 13 
  6 files changed, 137 insertions(+), 8 deletions(-)

 diff --git a/arch/arm/dts/exynos4412-odroid.dts 
 b/arch/arm/dts/exynos4412-odroid.dts
 index 24d0bf1..ac5fece 100644
 --- a/arch/arm/dts/exynos4412-odroid.dts
 +++ b/arch/arm/dts/exynos4412-odroid.dts
 @@ -67,4 +67,15 @@
   div = 0x3;
   index = 4;
   };
 +
 + ehci@1258 {
 + compatible = samsung,exynos-ehci;
 + reg = 0x1258 0x100;
 + #address-cells = 1;
 + #size-cells = 1;
 + phy {
 + compatible = samsung,exynos-usb-phy;
 + reg = 0x125B 0x100;
 + };
 + };
  };
 diff --git a/arch/arm/include/asm/arch-exynos/cpu.h 
 b/arch/arm/include/asm/arch-exynos/cpu.h
 index ba71714..fda21fb 100644
 --- a/arch/arm/include/asm/arch-exynos/cpu.h
 +++ b/arch/arm/include/asm/arch-exynos/cpu.h
 @@ -18,6 +18,8 @@

  #define EXYNOS4_GPIO_PART3_BASE  0x0386
  #define EXYNOS4_PRO_ID   0x1000
 +#define EXYNOS4_GUID_LOW 0x1014
 +#define EXYNOS4_GUID_HIGH0x1018
  #define EXYNOS4_SYSREG_BASE  0x1001
  #define EXYNOS4_POWER_BASE   0x1002
  #define EXYNOS4_SWRESET  0x10020400
 diff --git a/arch/arm/include/asm/arch-exynos/ehci.h 
 b/arch/arm/include/asm/arch-exynos/ehci.h
 index d2d70bd..3800fa9 100644
 --- a/arch/arm/include/asm/arch-exynos/ehci.h
 +++ b/arch/arm/include/asm/arch-exynos/ehci.h
 @@ -12,6 +12,13 @@

  #define CLK_24MHZ5

 +#define PHYPWR_NORMAL_MASK_PHY0 (0x39  0)
 +#define PHYPWR_NORMAL_MASK_PHY1 (0x7  6)
 +#define PHYPWR_NORMAL_MASK_HSIC0(0x7  9)
 +#define PHYPWR_NORMAL_MASK_HSIC1(0x7  12)
 +#define RSTCON_HOSTPHY_SWRST(0xf  3)
 +#define RSTCON_SWRST(0x1  0)
 +
  #define HOST_CTRL0_PHYSWRSTALL   (1  31)
  #define HOST_CTRL0_COMMONON_N(1  9)
  #define HOST_CTRL0_SIDDQ (1  6)
 @@ -61,6 +68,12 @@ struct exynos_usb_phy {
   unsigned int usbotgtune;
  };

 +struct exynos4412_usb_phy {
 + unsigned int usbphyctrl;
 + unsigned int usbphyclk;
 + unsigned int usbphyrstcon;
 +};
 +
  /* Switch on the VBUS power. */
  int board_usb_vbus_init(void);

 diff --git a/board/samsung/odroid/odroid.c b/board/samsung/odroid/odroid.c
 index 5edb250..6c78b67 100644
 --- a/board/samsung/odroid/odroid.c
 +++ b/board/samsung/odroid/odroid.c
 @@ -453,9 +453,64 @@ struct s3c_plat_otg_data s5pc210_otg_data = {
   .usb_phy_ctrl   = EXYNOS4X12_USBPHY_CONTROL,
   .usb_flags  = PHY0_SLEEP,
  };
 +#endif
 +
 +#if defined(CONFIG_USB_GADGET) || defined(CONFIG_CMD_USB)
 +
 +#ifdef CONFIG_CMD_USB
 +static void set_usb_ethaddr(void)
 +{
 + int i;
 + uchar mac[6];
 + unsigned int guid_high = readl(EXYNOS4_GUID_HIGH);
 + unsigned int guid_low = readl(EXYNOS4_GUID_LOW);

 We don't allow direct access.
 Is it special register? I can't find this register on TRM.
 If so you can make inline function at cpu.h instead.

 
 This register is not in the TRM. This register is possibly documented
 in the TRM for the Exynos5250. Through experimentation I found that it
 behaves the same on Exynos4412 prime as well - I checked this with one
 X2, 1 U2 and 2 U3s, and they do indeed do the job of being unique and
 hence can be used to generate the mac address which will be unique
 across all U2s/U3s/X2s and possibly other Exynos SoCs like Exynos4212
 etc.
 
 Regarding direct access, I am a bit confused. In odroid.c I see quite
 a many places which is doing a readl() of registers. Here we are
 readl(addr) into guid_* similarly, and cooking up a mac address in a
 local char array.
 
 I fail to see your point. Can you please elaborate more, so I can comprehend?
 

Samsung SoCs always get the address of register using accessor 

Re: [U-Boot] [PATCH] gic: fixed compilation error in GICv2 wait for interrupt macro

2014-10-27 Thread Albert ARIBAUD
Hello Yehuda,

On Mon, 27 Oct 2014 14:07:16 +0200, Yehuda Yitschak
yehu...@marvell.com wrote:
   a hexadicemal value was missing the 0x prefix which caused
   assembler error
 
 Signed-off-by: Yehuda Yitschak yehu...@marvell.com
 ---
  arch/arm/include/asm/macro.h | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/arch/arm/include/asm/macro.h b/arch/arm/include/asm/macro.h
 index 541b443..1c8c425 100644
 --- a/arch/arm/include/asm/macro.h
 +++ b/arch/arm/include/asm/macro.h
 @@ -193,7 +193,7 @@ lr.reqx30
  0 :  wfi
   ldr \wreg2, [\xreg1, GICC_AIAR]
   str \wreg2, [\xreg1, GICC_AEOIR]
 - and \wreg2, \wreg2, #3ff
 + and \wreg2, \wreg2, #0x3ff
   cbnz\wreg2, 0b
  .endm
  #endif
 -- 
 1.8.1.2

Which board(s) does this error show up in?

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


Re: [U-Boot] [PATCH] tools/kwbimage: Fix compilation warning

2014-10-27 Thread Stefan Roese

Hi Wolfgang,

On 27.10.2014 13:57, Wolfgang Denk wrote:

tools/kwbimage.c: In function ‘kwbimage_set_header’:
tools/kwbimage.c:784:8: warning: ‘headersz’ may be used uninitialized in this 
function [-Wmaybe-uninitialized]
   memcpy(ptr, image, headersz);
 ^
Instead of using multiple if statements, use a switch statement with
a default entry. And return with error if the VERSION field is
missing in the cfg file.


Thanks, but...


+   switch (version) {
+   /*
+* Fallback to version 0 is no version is provided in the
+* cfg file
+*/
+   case -1:
+   case 0:
image = image_create_v0(headersz, params, sbuf-st_size);
+   break;
+
+   case 1:
image = image_create_v1(headersz, params, sbuf-st_size);
+   break;
+
+   default:
+   fprintf(stderr, File %s does not have the VERSION field\n,
+   params-imagename);
+   free(image_cfg);
+   exit(EXIT_FAILURE);
+   }


What exactly is the difference between return code -1 (no version is
provided and you fall back to using version 0), and the default case?

To me these look the same?


Perhaps the error message is a bit misleading. The default: case is 
for unsupported versions. E.g. if VERSION 3 would have been provided 
in the cfg file.


Should I rephrase the error message in the next patch version? To 
something like this:


fprintf(stderr, Unsupported VERSION %d\n, version);

Thanks,
Stefan

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


[U-Boot] [PATCH] git-mailrc: add pmic custodian

2014-10-27 Thread Przemyslaw Marczak
This adds custodian to the pmic subsystem.

Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com
Cc: Tom Rini tr...@ti.com
---
 doc/git-mailrc | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/doc/git-mailrc b/doc/git-mailrc
index 35f2eb2..ad22763 100644
--- a/doc/git-mailrc
+++ b/doc/git-mailrc
@@ -31,6 +31,7 @@ alias masahiro   Masahiro Yamada 
yamad...@jp.panasonic.com
 alias monstr Michal Simek mon...@monstr.eu
 alias panto  Pantelis Antoniou pa...@antoniou-consulting.com
 alias prafulla   Prafulla Wadaskar prafu...@marvell.com
+alias bobenstein Przemyslaw Marczak p.marc...@samsung.com
 alias prom   Minkyu Kang mk7.k...@samsung.com
 alias rbohmerRemy Bohmer li...@bohmer.net
 alias reinhardm  Reinhard Meyer u-b...@emk-elektronik.de
@@ -122,3 +123,4 @@ alias usbuboot, marex
 alias video  uboot, ag
 alias patman uboot, sjg
 alias buildman   uboot, sjg
+alias pmic   uboot, bobenstein
-- 
1.9.1

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


[U-Boot] [PATCH 2/2] powerpc: TQM5200: convert to generic board

2014-10-27 Thread Wolfgang Denk
Signed-off-by: Wolfgang Denk w...@denx.de
---
 include/configs/TQM5200.h | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/include/configs/TQM5200.h b/include/configs/TQM5200.h
index 69c0336..cdccbef 100644
--- a/include/configs/TQM5200.h
+++ b/include/configs/TQM5200.h
@@ -1,5 +1,5 @@
 /*
- * (C) Copyright 2003-2005
+ * (C) Copyright 2003-2014
  * Wolfgang Denk, DENX Software Engineering, w...@denx.de.
  *
  * (C) Copyright 2004-2006
@@ -19,6 +19,8 @@
 #define CONFIG_MPC5200 1   /* This is an MPC5200 CPU   
*/
 #define CONFIG_TQM5200 1   /* ... on TQM5200 module
*/
 #undef CONFIG_TQM5200_REV100   /*  define for revision 100 modules 
*/
+#define CONFIG_SYS_GENERIC_BOARD
+#define CONFIG_DISPLAY_BOARDINFO
 
 /*
  * Valid values for CONFIG_SYS_TEXT_BASE are:
-- 
1.8.3.1

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


[U-Boot] [PATCH 1/2] powerpc: tqm8xx*: convert to generic board

2014-10-27 Thread Wolfgang Denk
This converts all TQM8xx boards (MPC8xx based) to generic board.

Signed-off-by: Wolfgang Denk w...@denx.de
---
 include/configs/TQM823L.h | 4 +++-
 include/configs/TQM823M.h | 4 +++-
 include/configs/TQM850L.h | 4 +++-
 include/configs/TQM850M.h | 4 +++-
 include/configs/TQM855L.h | 4 +++-
 include/configs/TQM855M.h | 4 +++-
 include/configs/TQM860L.h | 4 +++-
 include/configs/TQM860M.h | 4 +++-
 include/configs/TQM862L.h | 4 +++-
 include/configs/TQM862M.h | 4 +++-
 include/configs/TQM866M.h | 4 +++-
 include/configs/TQM885D.h | 4 +++-
 12 files changed, 36 insertions(+), 12 deletions(-)

diff --git a/include/configs/TQM823L.h b/include/configs/TQM823L.h
index cc22045..0d5a2b9 100644
--- a/include/configs/TQM823L.h
+++ b/include/configs/TQM823L.h
@@ -1,5 +1,5 @@
 /*
- * (C) Copyright 2000-2008
+ * (C) Copyright 2000-2014
  * Wolfgang Denk, DENX Software Engineering, w...@denx.de.
  *
  * SPDX-License-Identifier:GPL-2.0+
@@ -19,6 +19,8 @@
 
 #define CONFIG_MPC823  1   /* This is a MPC823 CPU */
 #define CONFIG_TQM823L 1   /* ...on a TQM8xxL module   */
+#define CONFIG_SYS_GENERIC_BOARD
+#define CONFIG_DISPLAY_BOARDINFO
 
 #defineCONFIG_SYS_TEXT_BASE0x4000
 
diff --git a/include/configs/TQM823M.h b/include/configs/TQM823M.h
index 4fd070f..e765a03 100644
--- a/include/configs/TQM823M.h
+++ b/include/configs/TQM823M.h
@@ -1,5 +1,5 @@
 /*
- * (C) Copyright 2000-2008
+ * (C) Copyright 2000-2014
  * Wolfgang Denk, DENX Software Engineering, w...@denx.de.
  *
  * SPDX-License-Identifier:GPL-2.0+
@@ -19,6 +19,8 @@
 
 #define CONFIG_MPC823  1   /* This is a MPC823 CPU */
 #define CONFIG_TQM823M 1   /* ...on a TQM8xxM module   */
+#define CONFIG_SYS_GENERIC_BOARD
+#define CONFIG_DISPLAY_BOARDINFO
 
 #defineCONFIG_SYS_TEXT_BASE0x4000
 
diff --git a/include/configs/TQM850L.h b/include/configs/TQM850L.h
index ca3750d..bbdc3f8 100644
--- a/include/configs/TQM850L.h
+++ b/include/configs/TQM850L.h
@@ -1,5 +1,5 @@
 /*
- * (C) Copyright 2000-2008
+ * (C) Copyright 2000-2014
  * Wolfgang Denk, DENX Software Engineering, w...@denx.de.
  *
  * SPDX-License-Identifier:GPL-2.0+
@@ -19,6 +19,8 @@
 
 #define CONFIG_MPC850  1   /* This is a MPC850 CPU */
 #define CONFIG_TQM850L 1   /* ...on a TQM8xxL module   */
+#define CONFIG_SYS_GENERIC_BOARD
+#define CONFIG_DISPLAY_BOARDINFO
 
 #defineCONFIG_SYS_TEXT_BASE0x4000
 
diff --git a/include/configs/TQM850M.h b/include/configs/TQM850M.h
index 659c9ad..5fc87f2 100644
--- a/include/configs/TQM850M.h
+++ b/include/configs/TQM850M.h
@@ -1,5 +1,5 @@
 /*
- * (C) Copyright 2000-2008
+ * (C) Copyright 2000-2014
  * Wolfgang Denk, DENX Software Engineering, w...@denx.de.
  *
  * SPDX-License-Identifier:GPL-2.0+
@@ -19,6 +19,8 @@
 
 #define CONFIG_MPC850  1   /* This is a MPC850 CPU */
 #define CONFIG_TQM850M 1   /* ...on a TQM8xxM module   */
+#define CONFIG_SYS_GENERIC_BOARD
+#define CONFIG_DISPLAY_BOARDINFO
 
 #defineCONFIG_SYS_TEXT_BASE0x4000
 
diff --git a/include/configs/TQM855L.h b/include/configs/TQM855L.h
index 906d79b..589d168 100644
--- a/include/configs/TQM855L.h
+++ b/include/configs/TQM855L.h
@@ -1,5 +1,5 @@
 /*
- * (C) Copyright 2000-2008
+ * (C) Copyright 2000-2014
  * Wolfgang Denk, DENX Software Engineering, w...@denx.de.
  *
  * SPDX-License-Identifier:GPL-2.0+
@@ -19,6 +19,8 @@
 
 #define CONFIG_MPC855  1   /* This is a MPC855 CPU */
 #define CONFIG_TQM855L 1   /* ...on a TQM8xxL module   */
+#define CONFIG_SYS_GENERIC_BOARD
+#define CONFIG_DISPLAY_BOARDINFO
 
 #defineCONFIG_SYS_TEXT_BASE0x4000
 
diff --git a/include/configs/TQM855M.h b/include/configs/TQM855M.h
index 44d456e..60acb56 100644
--- a/include/configs/TQM855M.h
+++ b/include/configs/TQM855M.h
@@ -1,5 +1,5 @@
 /*
- * (C) Copyright 2000-2008
+ * (C) Copyright 2000-2014
  * Wolfgang Denk, DENX Software Engineering, w...@denx.de.
  *
  * SPDX-License-Identifier:GPL-2.0+
@@ -19,6 +19,8 @@
 
 #define CONFIG_MPC855  1   /* This is a MPC855 CPU */
 #define CONFIG_TQM855M 1   /* ...on a TQM8xxM module   */
+#define CONFIG_SYS_GENERIC_BOARD
+#define CONFIG_DISPLAY_BOARDINFO
 
 #defineCONFIG_SYS_TEXT_BASE0x4000
 
diff --git a/include/configs/TQM860L.h b/include/configs/TQM860L.h
index 855b0cd..ebc5571 100644
--- a/include/configs/TQM860L.h
+++ b/include/configs/TQM860L.h
@@ -1,5 +1,5 @@
 /*
- * (C) Copyright 2000-2008
+ * (C) Copyright 2000-2014
  * Wolfgang Denk, DENX Software Engineering, w...@denx.de.
  *
  * SPDX-License-Identifier:GPL-2.0+
@@ -19,6 +19,8 @@
 
 #define CONFIG_MPC860  1   /* This is a MPC860 CPU */
 #define CONFIG_TQM860L 1   /* ...on a TQM8xxL module   */
+#define CONFIG_SYS_GENERIC_BOARD
+#define CONFIG_DISPLAY_BOARDINFO
 
 #define 

Re: [U-Boot] [PATCH] tools/kwbimage: Fix compilation warning

2014-10-27 Thread Wolfgang Denk
Dear Stefan,

In message 544e4412.60...@denx.de you wrote:
 
  +  switch (version) {
  +  /*
  +   * Fallback to version 0 is no version is provided in the
  +   * cfg file
  +   */
  +  case -1:
...

  What exactly is the difference between return code -1 (no version is
  provided and you fall back to using version 0), and the default case?
 
  To me these look the same?
 
 Perhaps the error message is a bit misleading. The default: case is 
 for unsupported versions. E.g. if VERSION 3 would have been provided 
 in the cfg file.
 
 Should I rephrase the error message in the next patch version? To 
 something like this:

In this case not the error message is incorrect, but the comment
above is misleading.  Instead of no version is provided it should
probably read if no supported version is provided (note: please
also fix the typo, i.e. if instead of is).

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
Anything free is worth what you pay for it.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 1/5] imx: gpt: Add 24Mhz OSC clock source support for GPT

2014-10-27 Thread Li Ye-B37916
Hi Stefano,

On 10/27/2014 7:18 PM, Stefano Babic wrote:
 Hi Ye,

 On 27/10/2014 05:10, Li Ye-B37916 wrote:
 The patch is used to add a choice for GPT clock source to provide high 
 frequency clock.  The configuration CONFIG_MXC_GPT_HCLK is not dependent 
 on the chip version. Even it is i.MX28, it is ok to set the configuration.
 Ok, thanks for clarification.

 The implementation has handled the differences between the chips.
 Most of i.MX6 series supports to use 24Mhz OSC as its high clock source 
 (except MX6Q/D Rev 1.0 and MX6SL).  So for i.MX6, the implementation uses 
 the 24Mhz OSC.
 For others (the time.c only compiles for i.MX5 and i.MX6, so the other is 
 i.MX5),  they don't have 24Mhz OSC source for GPT. When the configuration is 
 set, we use perclk instead.
 It should be not bad if you check for MX5 and CONFIG_MXC_GPT_HCLK and
 raise an error at compile time. This configuration is wrong and the
 error should be reported and not hidden at runtime.

No, this configuration is not wrong for MX5. When it is set on MX5, the 
implementation uses preclk as the clock source to generate a high frequency 
GPT.  

 I feel the patch subject need to modify, like add HCLK clock source for 
 GPT, then people may not confuse.
 Agree, do it.

 MX6Q/D Rev 1.0 and MX6SL can't use the 24Mhz OSC clock source option,
 so select the perclk for them. For MX6SL, we will set the OSC 24Mhz to
 perclk in CCM, so eventually the clock comes from OSC 24Mhz.

 I am trying to understand. The explanation here does not reflect in the
 implementation.  From the implementation, it is possible to set it even
 with wrong revision.
 As explained above, the implementation has handled the differences. Users 
 does not need to care the revision. For example, when the image runs on a  
 MX6Q/D Rev 1.0 chip, the perclk will be selected not the 24Mhz OSC.

 Anyway, I do not think it is correct to put it as a configuration
 option. This makes that we need different binaries for different
 revisions of the SOC. It should be checked at runtime if the revision is
 correct to set this clock as source. gpt_has_clk_source_osc has a check,
 but does it make sense that CONFIG_MXC_GPT_HCLK can be set in any case ?
 Only i.MX5 and i.MX6 uses the GPT driver. I think the CONFIG_MXC_GPT_HCLK 
 can be set in any case.
 Well, but if does not make sense for i.MX5, why do we have to accept it ?

The MX5 can also have a high frequency GPT. The difference is it uses another 
clock source preclk than the 24Mhz OSC used for iMX6.


 Signed-off-by: Ye.Li b37...@freescale.com
 ---
 Is this a second version of the patchset ? What are the changes ? Please
 add version number to your patchset and write a history about changes. I
 can suggest to use Simon's patman to post your patches.
 I met a email problem last Friday. I can't get any email from 
 u-boot@lists.denx.de for a long time. So I mistakenly thought
 the first patches are failed and send out second.
 Never mind ;-)

  arch/arm/imx-common/timer.c |   76 
 +--
  1 files changed, 66 insertions(+), 10 deletions(-)

 diff --git a/arch/arm/imx-common/timer.c b/arch/arm/imx-common/timer.c
 index c63f78f..f7e49bd 100644
 --- a/arch/arm/imx-common/timer.c
 +++ b/arch/arm/imx-common/timer.c
 @@ -2,7 +2,7 @@
   * (C) Copyright 2007
   * Sascha Hauer, Pengutronix
   *
 - * (C) Copyright 2009 Freescale Semiconductor, Inc.
 + * (C) Copyright 2009-2014 Freescale Semiconductor, Inc.
 I have already complain about this. There are a lot of commits after the
 file was merged into u-boot, and a lot of them not directly by
 Freescale. I do not think it is legally correct to change the Copyright.
 Will fix this.
 Thanks

   *
   * SPDX-License-Identifier:   GPL-2.0+
   */
 @@ -12,6 +12,7 @@
  #include div64.h
  #include asm/arch/imx-regs.h
  #include asm/arch/clock.h
 +#include asm/arch/sys_proto.h
  
  /* General purpose timers registers */
  struct mxc_gpt {
 @@ -26,23 +27,60 @@ static struct mxc_gpt *cur_gpt = (struct mxc_gpt 
 *)GPT1_BASE_ADDR;
  
  /* General purpose timers bitfields */
  #define GPTCR_SWR (1  15)   /* Software reset */
 +#define GPTCR_24MEN   (1  10)   /* Enable 24MHz clock input 
 from crystal */
  #define GPTCR_FRR (1  9)/* Freerun / restart */
 -#define GPTCR_CLKSOURCE_32(4  6)/* Clock source */
 +#define GPTCR_CLKSOURCE_32(4  6)/* Clock source 32khz */
 +#define GPTCR_CLKSOURCE_OSC   (5  6)/* Clock source OSC */
 +#define GPTCR_CLKSOURCE_PRE   (1  6)/* Clock source PRECLK 
 */
 +#define GPTCR_CLKSOURCE_MASK (0x7  6)
  #define GPTCR_TEN 1   /* Timer enable */
  
 +#define GPTPR_PRESCALER24M_SHIFT 12
 +#define GPTPR_PRESCALER24M_MASK (0xF  GPTPR_PRESCALER24M_SHIFT)
 +
  DECLARE_GLOBAL_DATA_PTR;
  
 +static inline int gpt_has_clk_source_osc(void)
 +{
 +#if defined(CONFIG_MX6)
 +  if (((is_cpu_type(MXC_CPU_MX6Q) || is_cpu_type(MXC_CPU_MX6D))
 +

[U-Boot] Regression with ubifs initialization

2014-10-27 Thread Andrew Ruder
Hey all,

It appears that 2014.10 has some issues with UBIFS initialization
(details at bottom).  git-bisect results in one of the following commits
being broken.  Surely it is the mtd one, but its parent commit
(compat.h) does not compile.

[ff94bc40af3] mtd, ubi, ubifs: resync with Linux-3.14
[0c06db59836] lib, linux: move linux specific defines to linux/compat.h

A little background for the errors below.  My MTD table:

device nor0 0.flash, # parts = 5
#: namesizeoffset  mask_flags
0: uboot   0x0008  0x  0
1: env 0x0002  0x0008  0
2: env_redund  0x0002  0x000a  0
3: env_factory 0x0002  0x000c  0
4: data0x0040  0x000e  0

=
Older (2014.07) U-Boot, I can do something like this:

$ erase nor0,4
Erase Flash Partition nor0,4, bank 0, 0x000e - 0x004d 
 done
Erased 32 sectors
$ ubi part data
UBI: attaching mtd1 to ubi0
UBI: physical eraseblock size:   131072 bytes (128 KiB)
UBI: logical eraseblock size:130944 bytes
UBI: smallest flash I/O unit:1
UBI: VID header offset:  64 (aligned 64)
UBI: data offset:128
UBI: empty MTD device detected
UBI: create volume table (copy #1)
UBI: create volume table (copy #2)
UBI: attached mtd1 to ubi0
UBI: MTD device name:mtd=4
UBI: MTD device size:4 MiB
UBI: number of good PEBs:32
UBI: number of bad PEBs: 0
UBI: max. allowed volumes:   128
UBI: wear-leveling threshold:4096
UBI: number of internal volumes: 1
UBI: number of user volumes: 0
UBI: available PEBs: 28
UBI: total number of reserved PEBs: 4
UBI: number of PEBs reserved for bad PEB handling: 0
UBI: max/mean erase counter: 1/0
$

=
Newer (2014.10) U-Boot, I get the following

$ erase nor0,4
Erase Flash Partition nor0,4, bank 0, 0x000e - 0x004d 
 done
Erased 32 sectors
$ ubi part data
UBI: attaching mtd1 to ubi0
$ ubi info
UBI: MTD device name:(a
UBI: MTD device size:18446742253448744536 MiB
UBI: physical eraseblock size:   -443412400 bytes (-433020 KiB)
UBI: logical eraseblock size:-442945536 bytes
UBI: number of good PEBs:-494718944
UBI: number of bad PEBs: -444399596
UBI: smallest flash I/O unit:-452780024
UBI: VID header offset:  -444391424 (aligned -390234000)
UBI: data offset:-443207680
UBI: max. allowed volumes:   -509550577
UBI: wear-leveling threshold:4096
UBI: number of internal volumes: 1
UBI: number of user volumes: 479
UBI: available PEBs: -443686912
UBI: total number of reserved PEBs: -450899448
UBI: number of PEBs reserved for bad PEB handling: -514859008
UBI: max/mean erase counter: -450944464/-393084916

- Andy

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


Re: [U-Boot] [PATCH v2 04/11] fdt: Add device tree memory bindings

2014-10-27 Thread Tom Rini
On Fri, Oct 24, 2014 at 02:04:00PM -0600, Simon Glass wrote:
 Hi Tom,
 
 On 24 October 2014 12:49, Tom Rini tr...@ti.com wrote:
  On Thu, Oct 23, 2014 at 06:58:50PM -0600, Simon Glass wrote:
 
  From: Michael Pratt mpr...@chromium.org
 
  Support a default memory bank, specified in reg, as well as
  board-specific memory banks in subtree board-id nodes.
 
  This allows memory information to be provided in the device tree,
  rather than hard-coded in, which will make it simpler to handle
  similar devices with different memory banks, as the board-id values
  or masks can be used to match devices.
  [snip]
  +++ b/doc/device-tree-bindings/memory/memory.txt
  @@ -0,0 +1,67 @@
  +* Memory binding
  +
  +The memory binding for U-Boot is as in the ePAPR with the following 
  additions:
 
  I am wary of being different from ePAPR / Linux Kernel.  What do we need
  this for / when do we use it?
 
 This extends the existing binding. It allows the location and size of
 memory to be set by a board ID. Unfortunately on sopme hardware you
 get a hang if you try to access memory that doesn't exist, so this
 allows the range of available memory to be defined - or at least the
 maximum bound since we still probe the memory size within that range.
 
 This feature is used on several Exynos Chromebooks.

So that you can use the same DT on several disjoint boards?  How does
this work with the kernel, does U-Boot then pass along only the correct
map?  Patches to the kernel to also deal with this?

-- 
Tom


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


Re: [U-Boot] [PATCH 1/5] imx: gpt: Add 24Mhz OSC clock source support for GPT

2014-10-27 Thread Stefano Babic
Hi Ye,

On 27/10/2014 14:58, Li Ye-B37916 wrote:
 Hi Stefano,
 
 On 10/27/2014 7:18 PM, Stefano Babic wrote:
 Hi Ye,

 On 27/10/2014 05:10, Li Ye-B37916 wrote:
 The patch is used to add a choice for GPT clock source to provide high 
 frequency clock.  The configuration CONFIG_MXC_GPT_HCLK is not dependent 
 on the chip version. Even it is i.MX28, it is ok to set the configuration.
 Ok, thanks for clarification.

 The implementation has handled the differences between the chips.
 Most of i.MX6 series supports to use 24Mhz OSC as its high clock source 
 (except MX6Q/D Rev 1.0 and MX6SL).  So for i.MX6, the implementation uses 
 the 24Mhz OSC.
 For others (the time.c only compiles for i.MX5 and i.MX6, so the other is 
 i.MX5),  they don't have 24Mhz OSC source for GPT. When the configuration 
 is set, we use perclk instead.
 It should be not bad if you check for MX5 and CONFIG_MXC_GPT_HCLK and
 raise an error at compile time. This configuration is wrong and the
 error should be reported and not hidden at runtime.
 
 No, this configuration is not wrong for MX5. When it is set on MX5, the 
 implementation uses preclk as the clock source to generate a high frequency 
 GPT.  

I see - in this case you defined GPTCR_CLKSOURCE_PRE. Ok, got it.

 
 I feel the patch subject need to modify, like add HCLK clock source for 
 GPT, then people may not confuse.
 Agree, do it.

 MX6Q/D Rev 1.0 and MX6SL can't use the 24Mhz OSC clock source option,
 so select the perclk for them. For MX6SL, we will set the OSC 24Mhz to
 perclk in CCM, so eventually the clock comes from OSC 24Mhz.

 I am trying to understand. The explanation here does not reflect in the
 implementation.  From the implementation, it is possible to set it even
 with wrong revision.
 As explained above, the implementation has handled the differences. Users 
 does not need to care the revision. For example, when the image runs on a  
 MX6Q/D Rev 1.0 chip, the perclk will be selected not the 24Mhz OSC.

 Anyway, I do not think it is correct to put it as a configuration
 option. This makes that we need different binaries for different
 revisions of the SOC. It should be checked at runtime if the revision is
 correct to set this clock as source. gpt_has_clk_source_osc has a check,
 but does it make sense that CONFIG_MXC_GPT_HCLK can be set in any case ?
 Only i.MX5 and i.MX6 uses the GPT driver. I think the CONFIG_MXC_GPT_HCLK 
 can be set in any case.
 Well, but if does not make sense for i.MX5, why do we have to accept it ?
 
 The MX5 can also have a high frequency GPT. The difference is it uses another 
 clock source preclk than the 24Mhz OSC used for iMX6.

Fine.


Best regards,
Stefano Babic

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


Re: [U-Boot] Card doesn't support part_switch

2014-10-27 Thread Tom Rini
On Fri, Oct 24, 2014 at 09:44:50PM -0400, Brandon Williams wrote:
 Hi there,
 
 I'm trying to switch to the second partition of my SD card and I'm running
 into this error:
 
 U-Boot mmc dev 0 2
 Card doesn't support part_switch
 switch to partitions #2, ERROR
 
 Is this a limitation of my SD card? Is it a partition configuration
 problem? I looked around and couldn't find much about it.

This refers to physical partitions.  SD cards do not have them but
eMMC does.  If you want to use partition 2 of your SD card, you want say
'load mmc 0:2 ...'

-- 
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] [PULL] u-boot-mpc5xxx / master

2014-10-27 Thread Wolfgang Denk
Dear Tom,

The following changes since commit d0796defbe8eff6fc3c27c893dcbc47af59d4764:

  Merge http://git.denx.de/u-boot-sunxi (2014-10-26 14:13:24 -0400)

are available in the git repository at:


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

for you to fetch changes up to f06f9a1fb1cd332435b9e8660355f57d7d3f98d8:

  ppc: Zap TQM8272 board (2014-10-27 14:35:56 +0100)


Anatolij Gustschin (8):
  powerpc: mpc512x: fix boot breakage
  powerpc: mpc5121ads: convert to generic board
  powerpc: pdm360ng: convert to generic board
  powerpc: aria: convert to generic board
  powerpc: ac14xx: convert to generic board
  powerpc: mecp5123: convert to generic board
  powerpc: digsy_mtc: convert to generic board
  powerpc: mpc5121ads: update board config info in README

Marek Vasut (7):
  ppc: Zap ICU862 board
  ppc: Zap MHPC board
  ppc: Zap Hymod board
  ppc: Zap HWW1U1A board
  ppc: Zap IDS8247 board
  ppc: Zap TQM8260 board
  ppc: Zap TQM8272 board

Wolfgang Denk (2):
  README.scrapyard: update commit IDs
  PowerPC: drop some 74xx_7xx boards and related code

 arch/powerpc/cpu/74xx_7xx/Kconfig |   16 -
 arch/powerpc/cpu/74xx_7xx/start.S |   13 +-
 arch/powerpc/cpu/mpc8260/Kconfig  |   16 -
 arch/powerpc/cpu/mpc8260/ether_fcc.c  |   27 +-
 arch/powerpc/cpu/mpc8260/interrupts.c |   10 +-
 arch/powerpc/cpu/mpc8260/pci.c|2 -
 arch/powerpc/cpu/mpc8260/start.S  |   14 -
 arch/powerpc/cpu/mpc83xx/start.S  |   11 -
 arch/powerpc/cpu/mpc85xx/Kconfig  |4 -
 arch/powerpc/cpu/mpc8xx/Kconfig   |8 -
 arch/powerpc/cpu/mpc8xx/cpu_init.c|2 -
 arch/powerpc/cpu/mpc8xx/fec.c |   40 +-
 arch/powerpc/include/asm/immap_512x.h |1 +
 arch/powerpc/include/asm/u-boot.h |3 -
 board/Marvell/common/flash.c  | 1056 ---
 board/Marvell/common/i2c.c|  521 --
 board/Marvell/common/intel_flash.c|  253 ---
 board/Marvell/common/misc.S   |  235 ---
 board/Marvell/common/serial.c |8 -
 board/Marvell/db64360/64360.h |   36 -
 board/Marvell/db64360/Kconfig |   12 -
 board/Marvell/db64360/MAINTAINERS |6 -
 board/Marvell/db64360/Makefile|   13 -
 board/Marvell/db64360/README  |  105 --
 board/Marvell/db64360/db64360.c   |  922 -
 board/Marvell/db64360/eth.h   |   28 -
 board/Marvell/db64360/mpsc.c  | 1001 --
 board/Marvell/db64360/mpsc.h  |  140 --
 board/Marvell/db64360/mv_eth.c| 3128 ---
 board/Marvell/db64360/mv_eth.h|  818 
 board/Marvell/db64360/mv_regs.h   | 1108 ---
 board/Marvell/db64360/pci.c   |  923 -
 board/Marvell/db64360/sdram_init.c| 1945 ---
 board/Marvell/db64460/64460.h |   36 -
 board/Marvell/db64460/Kconfig |   12 -
 board/Marvell/db64460/MAINTAINERS |6 -
 board/Marvell/db64460/Makefile|   13 -
 board/Marvell/db64460/README  |  105 --
 board/Marvell/db64460/db64460.c   |  922 -
 board/Marvell/db64460/eth.h   |   27 -
 board/Marvell/db64460/mpsc.c  | 1001 --
 board/Marvell/db64460/mpsc.h  |  140 --
 board/Marvell/db64460/mv_eth.c| 3127 ---
 board/Marvell/db64460/mv_eth.h|  815 
 board/Marvell/db64460/mv_regs.h   | 1108 ---
 board/Marvell/db64460/pci.c   |  923 -
 board/Marvell/db64460/sdram_init.c| 1950 ---
 board/Marvell/include/core.h  |  236 ---
 board/Marvell/include/mv_gen_reg.h| 2296 ---
 board/eltec/mhpc/Kconfig  |   12 -
 board/eltec/mhpc/MAINTAINERS  |6 -
 board/eltec/mhpc/Makefile |8 -
 board/eltec/mhpc/flash.c  |  414 -
 board/eltec/mhpc/mhpc.c   |  465 -
 board/eltec/mhpc/u-boot.lds.debug |  121 --
 board/esd/cpci750/64360.h |   37 -
 board/esd/cpci750/Kconfig |   12 -
 board/esd/cpci750/MAINTAINERS |6 -
 board/esd/cpci750/Makefile|   14 -
 board/esd/cpci750/cpci750.c   | 1088 ---
 board/esd/cpci750/eth.h   |   28 -
 board/esd/cpci750/i2c.c   |  475 -
 board/esd/cpci750/i2c.h   |   16 -
 board/esd/cpci750/ide.c   |   74 -
 board/esd/cpci750/local.h |   69 -
 board/esd/cpci750/misc.S  |  245 ---
 board/esd/cpci750/mpsc.c  | 1002 --
 board/esd/cpci750/mpsc.h  |  140 --
 board/esd/cpci750/mv_eth.c| 3131 ---
 board/esd/cpci750/mv_eth.h|  819 
 board/esd/cpci750/mv_regs.h   | 1108 ---
 board/esd/cpci750/pci.c   | 1028 --
 

Re: [U-Boot] [PATCH] gic: fixed compilation error in GICv2 wait for interrupt macro

2014-10-27 Thread Yehuda Yitschak
Hello Albert

 -Original Message-
 From: Albert ARIBAUD [mailto:albert.u.b...@aribaud.net]
 Sent: Monday, October 27, 2014 15:05
 To: Yehuda Yitschak
 Cc: u-boot@lists.denx.de; arnab.b...@freescale.com;
 feng...@phytium.com.cn; york...@freescale.com;
 scottw...@freescale.com
 Subject: Re: [PATCH] gic: fixed compilation error in GICv2 wait for interrupt
 macro
 
 Hello Yehuda,
 
 On Mon, 27 Oct 2014 14:07:16 +0200, Yehuda Yitschak
 yehu...@marvell.com wrote:
  a hexadicemal value was missing the 0x prefix which caused
  assembler error
 
  Signed-off-by: Yehuda Yitschak yehu...@marvell.com
  ---
   arch/arm/include/asm/macro.h | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)
 
  diff --git a/arch/arm/include/asm/macro.h
  b/arch/arm/include/asm/macro.h index 541b443..1c8c425 100644
  --- a/arch/arm/include/asm/macro.h
  +++ b/arch/arm/include/asm/macro.h
  @@ -193,7 +193,7 @@ lr  .reqx30
   0 :wfi
  ldr \wreg2, [\xreg1, GICC_AIAR]
  str \wreg2, [\xreg1, GICC_AEOIR]
  -   and \wreg2, \wreg2, #3ff
  +   and \wreg2, \wreg2, #0x3ff
  cbnz\wreg2, 0b
   .endm
   #endif
  --
  1.8.1.2
 
 Which board(s) does this error show up in?

There is no board in u-boot 2014.01 that use GICv2. I guess this is why it went 
under radar
I use mainline u-boot for one of my platforms so I noticed the bug once I 
rebased to 2014.10

Yehuda 

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


Re: [U-Boot] [PULL] u-boot-socfpga/master

2014-10-27 Thread Tom Rini
On Mon, Oct 27, 2014 at 02:28:36AM +0100, Marek Vasut wrote:

 The following changes since commit 5b3ee386fde82a1ba42ff09b95247842c9a1585e:
 
   kbuild: clear VENDOR variable to fix build error on tcsh (2014-10-23 
 16:35:12 
 -0400)
 
 are available in the git repository at:
 
   git://git.denx.de/u-boot-socfpga.git master
 
 for you to fetch changes up to 20cadbbe2e0425783855f6ae90ef82aa0db63155:
 
   arm: socfpga: config: Add USB support example (2014-10-27 02:26:24 +0100)
 

Applied to u-boot/master, thanks!

-- 
Tom


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


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

2014-10-27 Thread Tom Rini
On Thu, Oct 23, 2014 at 01:17:16PM -0400, Tom Rini wrote:

 Hi me,
 
 The following changes since commit 68e80fdda1336068f40915388bbdacfd2b75233a:
 
   Merge git://git.denx.de/u-boot-dm (2014-10-22 13:51:45 -0400)
 
 are available in the git repository at:
 
 
   git://git.denx.de/u-boot-ti.git master
 
 for you to fetch changes up to b5ff205cdb0da6eff8a02653bf5192ea8d661faa:
 
   omap3/am33xx: mux: fix several checkpatch issues (2014-10-23 11:53:02 -0400)
 

Applied to u-boot/master, thanks!

-- 
Tom


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


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

2014-10-27 Thread Tom Rini
On Mon, Oct 27, 2014 at 01:32:23PM +0100, Stefano Babic wrote:

 Hi Tom,
 
 please pull from u-boot-imx, thanks !
 
 The following changes since commit c43fd23cf619856b0763a64a6a3bcf3663058c49:
 
   Prepare v2014.10 (2014-10-14 04:47:15 -0400)
 
 are available in the git repository at:
 
   git://www.denx.de/git/u-boot-imx.git master
 
 for you to fetch changes up to 3f97af5302ee15530411232b464d255eb2ff2ffb:
 
   ot1200: add sata support (2014-10-23 10:04:26 +0200)
 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] Regression with ubifs initialization

2014-10-27 Thread Wolfgang Denk
Dear Andrew,

In message 20141027140241.GA7726@og3k you wrote:
 
 It appears that 2014.10 has some issues with UBIFS initialization
 (details at bottom).  git-bisect results in one of the following commits
 being broken.  Surely it is the mtd one, but its parent commit
 (compat.h) does not compile.

Which board are you talking about?

And which toolchain(s) are/have you been using to build U-Boot?

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
Most people would like to be delivered  from  temptation  but  would
like it to keep in touch. - Robert Orben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] Regression with ubifs initialization

2014-10-27 Thread Andrew Ruder
On Mon, Oct 27, 2014 at 03:33:00PM +0100, Wolfgang Denk wrote:
  It appears that 2014.10 has some issues with UBIFS initialization
  (details at bottom).  git-bisect results in one of the following commits
  being broken.  Surely it is the mtd one, but its parent commit
  (compat.h) does not compile.
 
 Which board are you talking about?

I have a board with a PXA270 and NOR flash.  I am happy to submit the
patches which add the board support, but they aren't really ready and
cleaned up for submission.

 And which toolchain(s) are/have you been using to build U-Boot?

A crosstools-ng compiled gcc 4.8.2.

Would be interested to know if this is expected behavior:

a.) erase flash partition
b.) Call out erased partition as a ubi partition
c.) ubi triggers a initialization.

Because if so, that seems to no longer happen and it blindly attempts to
use the erased flash as valid ubi data.

- Andy


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


Re: [U-Boot] [PATCH] tftp: Displace check for server ip

2014-10-27 Thread Tom Rini
On Sun, Oct 05, 2014 at 06:39:07PM +0200, Maxime Hadjinlian wrote:

 If for some reason, 'serverip' is not set, and you are passing the
 remote IP on the command line, the tftp command will fail, stating that
 the 'serverip' is not set.
 
 By displacing this check, it fixes the issues.
 
 Signed-off-by: Maxime Hadjinlian maxime.hadjinl...@gmail.com
 ---
 
  net/net.c  | 6 --
  net/tftp.c | 4 
  2 files changed, 4 insertions(+), 6 deletions(-)
 
 diff --git a/net/net.c b/net/net.c
 index 722089f..044ee71 100644
 --- a/net/net.c
 +++ b/net/net.c
 @@ -1235,12 +1235,6 @@ static int net_check_prereq(enum proto_t protocol)
  #if defined(CONFIG_CMD_NFS)
   case NFS:
  #endif
 - case TFTPGET:
 - case TFTPPUT:
 - if (NetServerIP == 0) {
 - puts(*** ERROR: `serverip' not set\n);
 - return 1;
 - }

Moving the check to TftpServer() seems fine but right here you've also
removed the check from the NFS cmd which is wrong.  This needs to be
re-worked so that the current check is under #if defined(CONFIG_CMD_NFS)
and we continue case'ing TFTPGET/TFTPPUT through the common part that
follows and so forth.  Thanks!

  #if  defined(CONFIG_CMD_PING) || defined(CONFIG_CMD_SNTP) || \
   defined(CONFIG_CMD_DNS)
  common:
 diff --git a/net/tftp.c b/net/tftp.c
 index 966d1cf..eb93df5 100644
 --- a/net/tftp.c
 +++ b/net/tftp.c
 @@ -736,6 +736,10 @@ void TftpStart(enum proto_t protocol)
   tftp_filename[MAX_LEN-1] = 0;
   }
   }
 + if (TftpRemoteIP == 0) {
 + printf(*** ERRROR: No server IP found.\n);
 + return;
 + }
  
   printf(Using %s device\n, eth_get_name());
   printf(TFTP %s server %pI4; our IP address is %pI4,
 -- 
 2.1.1
 
 ___
 U-Boot mailing list
 U-Boot@lists.denx.de
 http://lists.denx.de/mailman/listinfo/u-boot

-- 
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] tools/kwbimage: Fix compilation warning

2014-10-27 Thread Stefan Roese

Hi Wolfgang,

On 27.10.2014 14:34, Wolfgang Denk wrote:

+   switch (version) {
+   /*
+* Fallback to version 0 is no version is provided in the
+* cfg file
+*/
+   case -1:

...


What exactly is the difference between return code -1 (no version is
provided and you fall back to using version 0), and the default case?

To me these look the same?


Perhaps the error message is a bit misleading. The default: case is
for unsupported versions. E.g. if VERSION 3 would have been provided
in the cfg file.

Should I rephrase the error message in the next patch version? To
something like this:


In this case not the error message is incorrect, but the comment
above is misleading.  Instead of no version is provided it should
probably read if no supported version is provided (note: please
also fix the typo, i.e. if instead of is).


The fallback in the comment above refers to version == -1. As the 
function image_get_version() returns -1 if no VERSION string is found in 
the config file. So I think the comment is quite accurate.


Thanks,
Stefan

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


Re: [U-Boot] [PATCH v3 1/4] kconfig: arm: introduce symbol for ARM CPUs

2014-10-27 Thread Masahiro YAMADA
Hi Georges,

This patch is really appreciated, but I found some mistakes.
Please see below:



2014-10-27 7:25 GMT+09:00 Georges Savoundararadj savou...@gmail.com:

 +config SYS_CPU
 +default arm720t if CPU_ARM720T
 +default arm920t if CPU_ARM920T
 +default arm926ejs if CPU_ARM926EJS
 +default arm946es if CPU_ARM946ES
 +default arm1136 if CPU_ARM113
 +default arm1176 if CPU_ARM1176
 +default armv7 if CPU_V7
 +default pxa if CPU_PXA
 +default sa1100 if CPU_SA1100
 +


[1] Typo.

s/CPU_ARM113/CPU_ARM1136/


 @@ -472,6 +664,7 @@ config TEGRA

  config TARGET_VEXPRESS_AEMV8A
 bool Support vexpress_aemv8a
 +   select CPU_V7
 select ARM64


[2]
Your are changing this board from armv8 to armv7.
Please remove select CPU_V7.



[3]
I thought you were trying to add only CPU_V7 and CPU_ARM1176
but it is very nice to make extra efforts for our community.
One problem is, if you add CPU_PXA, you need to fix common/lcd.c.
Otherwise, you will get a new warning for such boards as palmld, palmtc,
because CONFIG_CPU_PXA is defined and used in common/lcd.c,

  #if defined(CONFIG_CPU_PXA25X) || defined(CONFIG_CPU_PXA27X) || \
  defined(CONFIG_CPU_MONAHANS)
  #define CONFIG_CPU_PXA   -- remove
  #include asm/byteorder.h
  #endif

I think this change will *probably* produce the same output
although I have not checked it closely yet.





[4]
This patch is not applicable on the current master
(commit d0796defbe8eff6fc3c27c893dcbc47af59d4764)
You also need to add select CPU_V7 to
the new entry TARGET_SUN6I in arch/arm/Kconfig.




Could you fix [1] thru [4], please?


Before sending it, please do a quick test at least;
it's very easy.


  1.  Check out master branch
  2.  Run tools/genboardscfg.py
  3.  Run mv  boards.cfg   boards.cfg.org
  4.  Apply your patch
  5.  Run  tools/genboardscfg.py again
  6.  Run  diff  boards.cfg.org  boards.cfg

If you get code diff,  something is wrong with your patch.
You will easily see which board is corrupted.




Tom and Albert,

If Georges fixes those problems, is it possible to apply it shortly on
the mainline?
(directly u-boot/master? or via u-boot-arm/master?)

Since this patch easily causes conflicts, it should not get stuck for
a long time.



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


Re: [U-Boot] [RFC] MW rule and its period

2014-10-27 Thread Tom Rini
On Tue, Oct 21, 2014 at 09:34:11PM +0200, Wolfgang Denk wrote:
 Dear Masahiro,
 
 In message 
 CAMhH57R2eBf26ONYD4fnLRWDQ=bjy_0crlm_yoprzgdmwoq...@mail.gmail.com you 
 wrote:
  
  Even Linux needs 7 weeks to be stabilized
  in spite of much more commits than U-Boot.
  
  Do we really need 10 weeks?
 
 I think a fundamental difference between Linux and U-Boot is that in
 Linux the actual core is not changing so heavily, and the individual
 subsystems are much better isolated.  In U-Boot, we have a large
 number commits with architecture-wide impact, not to mention
 system-wide ones like the Kconfig / Kbuild or DM restructuring.
 So a bug introduced in Linux will often affect only a relatively small
 group of developers, while the rest can continue working basically
 unaffected.  In U-Boot it's easy to break all ARM, which will bring
 the majority of developers to a full stop.
 
 Also I think reducing the MW makes things indeed faster, which means
 more frequent release cycles, and I'm afraid in the end the custodians
 will not find their days easier, but more loaded.

Well, here's what I've noticed.  We have a relative flury of activity
around the merge window, then we have a period of both bending the
window and having some folks be frustrated about their patches not being
anywhere followed by a release.  It's true we're making changes which
can break more core areas, but just how much testing are people doing on
top of tree? rc releaes?

I wonder about for 2015 if having some shorter merge window and release
schedule might not help, especially with planning peoples time.  If say
releases were the last Friday of even numbered months (Feb 27, Apr 24,
June 26, Aug 28, Oct 30, Dec 25 (eep, OK, re-jigger that one..)), final
RC Monday 2 weeks prior, RC every 2 weeks before then, only final RC is
bug fix (here's how to trigger, here's fix kind), everything else is
best judgement.  Or even first week of the month is for big scary
changes, last week is bug fixes, rest is best judgement monthly release
cycle.  It wouldn't be terrible for $SOC to have patches miss the April
release since May is right around the corner.  Custodians would know if
they can focus some time the second week of the month of U-Boot for
regular patches they can then come around the last week of the month,
run test a few boards and be Good to Go.

-- 
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 v3 1/4] kconfig: arm: introduce symbol for ARM CPUs

2014-10-27 Thread Albert ARIBAUD
Hello Masahiro,

On Tue, 28 Oct 2014 01:50:31 +0900, Masahiro YAMADA
yamad...@jp.panasonic.com wrote:
 Hi Georges,
 
 This patch is really appreciated, but I found some mistakes.
 Please see below:
 
 
 
 2014-10-27 7:25 GMT+09:00 Georges Savoundararadj savou...@gmail.com:
 
  +config SYS_CPU
  +default arm720t if CPU_ARM720T
  +default arm920t if CPU_ARM920T
  +default arm926ejs if CPU_ARM926EJS
  +default arm946es if CPU_ARM946ES
  +default arm1136 if CPU_ARM113
  +default arm1176 if CPU_ARM1176
  +default armv7 if CPU_V7
  +default pxa if CPU_PXA
  +default sa1100 if CPU_SA1100
  +
 
 
 [1] Typo.
 
 s/CPU_ARM113/CPU_ARM1136/
 
 
  @@ -472,6 +664,7 @@ config TEGRA
 
   config TARGET_VEXPRESS_AEMV8A
  bool Support vexpress_aemv8a
  +   select CPU_V7
  select ARM64
 
 
 [2]
 Your are changing this board from armv8 to armv7.
 Please remove select CPU_V7.
 
 
 
 [3]
 I thought you were trying to add only CPU_V7 and CPU_ARM1176
 but it is very nice to make extra efforts for our community.
 One problem is, if you add CPU_PXA, you need to fix common/lcd.c.
 Otherwise, you will get a new warning for such boards as palmld, palmtc,
 because CONFIG_CPU_PXA is defined and used in common/lcd.c,
 
   #if defined(CONFIG_CPU_PXA25X) || defined(CONFIG_CPU_PXA27X) || \
   defined(CONFIG_CPU_MONAHANS)
   #define CONFIG_CPU_PXA   -- remove
   #include asm/byteorder.h
   #endif
 
 I think this change will *probably* produce the same output
 although I have not checked it closely yet.
 
 
 
 
 
 [4]
 This patch is not applicable on the current master
 (commit d0796defbe8eff6fc3c27c893dcbc47af59d4764)
 You also need to add select CPU_V7 to
 the new entry TARGET_SUN6I in arch/arm/Kconfig.
 
 
 
 
 Could you fix [1] thru [4], please?
 
 
 Before sending it, please do a quick test at least;
 it's very easy.
 
 
   1.  Check out master branch
   2.  Run tools/genboardscfg.py
   3.  Run mv  boards.cfg   boards.cfg.org
   4.  Apply your patch
   5.  Run  tools/genboardscfg.py again
   6.  Run  diff  boards.cfg.org  boards.cfg
 
 If you get code diff,  something is wrong with your patch.
 You will easily see which board is corrupted.
 
 
 
 
 Tom and Albert,
 
 If Georges fixes those problems, is it possible to apply it shortly on
 the mainline?
 (directly u-boot/master? or via u-boot-arm/master?)

I'm ok with this patch going in (through either tree). However:

 Since this patch easily causes conflicts, it should not get stuck for
 a long time.

I'm not sure I'm getting this right. Do yo mean that once the patch is
in, it should be easy to detect and iron out issues because if some
boards are broken, their users will react promptly?

 Best Regards
 Masahiro Yamada

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


Re: [U-Boot] [PATCH 7/7] spi: altera: Move the config options to the top

2014-10-27 Thread Jagan Teki
On 23 October 2014 01:26, Marek Vasut ma...@denx.de wrote:
 Just move the configuration options scattered all over the driver
 to the top of the source file. No functional change.

 Signed-off-by: Marek Vasut ma...@denx.de
 Cc: Chin Liang See cl...@altera.com
 Cc: Dinh Nguyen dingu...@altera.com
 Cc: Albert Aribaud albert.u.b...@aribaud.net
 Cc: Pavel Machek pa...@denx.de
 Cc: Jagannadha Sutradharudu Teki jagannadh.t...@gmail.com
 ---
  drivers/spi/altera_spi.c | 16 
  1 file changed, 8 insertions(+), 8 deletions(-)

 diff --git a/drivers/spi/altera_spi.c b/drivers/spi/altera_spi.c
 index 93365c2..8f31507 100644
 --- a/drivers/spi/altera_spi.c
 +++ b/drivers/spi/altera_spi.c
 @@ -13,6 +13,14 @@
  #include malloc.h
  #include spi.h

 +#ifndef CONFIG_ALTERA_SPI_IDLE_VAL
 +#define CONFIG_ALTERA_SPI_IDLE_VAL 0xff
 +#endif
 +
 +#ifndef CONFIG_SYS_ALTERA_SPI_LIST
 +#define CONFIG_SYS_ALTERA_SPI_LIST { CONFIG_SYS_SPI_BASE }
 +#endif
 +
  struct altera_spi_regs {
 u32 rxdata;
 u32 txdata;
 @@ -36,10 +44,6 @@ struct altera_spi_regs {
  #define ALTERA_SPI_CONTROL_IE_MSK  (1  8)
  #define ALTERA_SPI_CONTROL_SSO_MSK (1  10)

 -#ifndef CONFIG_SYS_ALTERA_SPI_LIST
 -#define CONFIG_SYS_ALTERA_SPI_LIST { CONFIG_SYS_SPI_BASE }
 -#endif
 -
  static ulong altera_spi_base_list[] = CONFIG_SYS_ALTERA_SPI_LIST;

  struct altera_spi_slave {
 @@ -118,10 +122,6 @@ void spi_release_bus(struct spi_slave *slave)
 writel(0, altspi-regs-slave_sel);
  }

 -#ifndef CONFIG_ALTERA_SPI_IDLE_VAL
 -# define CONFIG_ALTERA_SPI_IDLE_VAL 0xff
 -#endif
 -
  int spi_xfer(struct spi_slave *slave, unsigned int bitlen, const void *dout,
  void *din, unsigned long flags)
  {
 --
 2.0.0


Series missing's - cover letter and v2 change log.

Applied to u-boot-spi/master

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


Re: [U-Boot] [PATCH v2 0/2] SPI: mxc_spi: slave initialisation fixes

2014-10-27 Thread Jagan Teki
On 23 October 2014 19:39, Markus Niebel list-09_u-b...@tqsc.de wrote:
 From: Markus Niebel markus.nie...@tq-group.com

 current implementation of the mxc_spi host driver gives issues,
 if using more than one slave on the same bus. These patches try
 to improve this use case.

 They were tested on a TQMa6S (i.MX6S) with a custom mainboard
 using two slave devices in SPI MODE 0 and 3, on of the devices
 uses gpio based chip select the other hardware base chip select.

 Markus Niebel (2):
   SPI: mxc_spi: remove second reset from ECSPI config handler
   SPI: mxc_spi: delay initialisation until claim bus

  drivers/spi/mxc_spi.c | 40 +---
  1 file changed, 21 insertions(+), 19 deletions(-)

Applied to u-boot-spi/master

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


Re: [U-Boot] [PATCH] gic: fixed compilation error in GICv2 wait for interrupt macro

2014-10-27 Thread Albert ARIBAUD
Hello Yehuda,

On Mon, 27 Oct 2014 14:29:09 +, Yehuda Yitschak
yehu...@marvell.com wrote:
 Hello Albert

  Which board(s) does this error show up in?
 
 There is no board in u-boot 2014.01 that use GICv2. I guess this is why it 
 went under radar
 I use mainline u-boot for one of my platforms so I noticed the bug once I 
 rebased to 2014.10

Thanks for the explanation.

 Yehuda 

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


[U-Boot] [RFC] How to move lots of CONFIGs from header files to Kconfig

2014-10-27 Thread Masahiro YAMADA
Hi.

I've been thinking how to move so many CONFIGs to Kconfig.

First, I want to move many boolean macros such as CONFIG_CMD_*,
because it seems easier than string, int, hex configs.

Roughly, we have two options, I think.



[1] I do this work for all the boards

I will prepare many entries in Kconfigs and
also move lots of configs options by a tool.

 Pros:
- Possible to move many options at one time

 Cons:
- Cause lots of conflicts
- It is pointless to touch lots of unmaintained boards
  that might be removed by the end of this year
- Hard work for me


[2] Each board maintainer takes care of boards he is responsible for.

Procedure:

1.  I will create many entries in Kconfigs
without dependencies (depends on and select)

2.  Each board maintainer will move config options
from his board headers to defconfigs  (*)
(I expect most of active boards will be switched at this step.)

3.  Many of unmaintained boards ( = not converted to generic board)
will be removed by the end of this year.

4.  I will forcibly convert left-over boards.
These boards are almost inactive, so this conversion
will not produce much conflicts.

 5.  Implement depends on and select correctly

   (*)  You can edit  directly configs/foo_defconfig.
   Or you can use Kconfig functions in case you may introduce a typo.

Run make foo_defconfig
Run make menuconfig
Enable config options you like
Select Save.
Run  make savedefconfig
Run  mv defconfig configs/foo_defconfig
Remove unnecessay CONFIGs from your board header files


  Pros:
 - Reduce the possibility of significant conflicts
 - Avoid needless efforts for unmaintained boards

  Cons:
 - Patch for each board will fly around
 - Take longer time


At first, I was planning to do [1] but it would disturb the
development on SoC subsystems.
I see SUNXI custodians are touching their Kconfigs and defconfigs very often.
[1] would cause conflicts between u-boot/master and u-boot-sunxi/{master,next}.
I also many boards are being dropped these days, which increase the conflicts.



I am thinking [2] is better.
Comments are welcome.



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


Re: [U-Boot] [PATCH v3 1/4] kconfig: arm: introduce symbol for ARM CPUs

2014-10-27 Thread Masahiro YAMADA
Hi Albert,


2014-10-28 2:09 GMT+09:00 Albert ARIBAUD albert.u.b...@aribaud.net:
 Tom and Albert,

 If Georges fixes those problems, is it possible to apply it shortly on
 the mainline?
 (directly u-boot/master? or via u-boot-arm/master?)

 I'm ok with this patch going in (through either tree). However:

 Since this patch easily causes conflicts, it should not get stuck for
 a long time.

 I'm not sure I'm getting this right. Do yo mean that once the patch is
 in, it should be easy to detect and iron out issues because if some
 boards are broken, their users will react promptly?

Yes.

If some conflicts happen, CONFIG_SYS_CPU will not be set correctly
and those boards will fail to build.
User will notice the issue soon.



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


Re: [U-Boot] [RFC] How to move lots of CONFIGs from header files to Kconfig

2014-10-27 Thread Nikita Kiryanov

Hi Masahiro,

On 27/10/14 19:13, Masahiro YAMADA wrote:

Hi.

I've been thinking how to move so many CONFIGs to Kconfig.

First, I want to move many boolean macros such as CONFIG_CMD_*,
because it seems easier than string, int, hex configs.

Roughly, we have two options, I think.



[1] I do this work for all the boards

 I will prepare many entries in Kconfigs and
 also move lots of configs options by a tool.

  Pros:
 - Possible to move many options at one time

  Cons:
 - Cause lots of conflicts
 - It is pointless to touch lots of unmaintained boards
   that might be removed by the end of this year
 - Hard work for me

[2] Each board maintainer takes care of boards he is responsible for.

 Procedure:

 1.  I will create many entries in Kconfigs
 without dependencies (depends on and select)

 2.  Each board maintainer will move config options
 from his board headers to defconfigs  (*)
 (I expect most of active boards will be switched at this step.)

 3.  Many of unmaintained boards ( = not converted to generic board)
 will be removed by the end of this year.

 4.  I will forcibly convert left-over boards.
 These boards are almost inactive, so this conversion
 will not produce much conflicts.

  5.  Implement depends on and select correctly

(*)  You can edit  directly configs/foo_defconfig.
Or you can use Kconfig functions in case you may introduce a typo.

 Run make foo_defconfig
 Run make menuconfig
 Enable config options you like
 Select Save.
 Run  make savedefconfig
 Run  mv defconfig configs/foo_defconfig
 Remove unnecessay CONFIGs from your board header files


   Pros:
  - Reduce the possibility of significant conflicts
  - Avoid needless efforts for unmaintained boards

   Cons:
  - Patch for each board will fly around
  - Take longer time


At first, I was planning to do [1] but it would disturb the
development on SoC subsystems.
I see SUNXI custodians are touching their Kconfigs and defconfigs very often.
[1] would cause conflicts between u-boot/master and u-boot-sunxi/{master,next}.
I also many boards are being dropped these days, which increase the conflicts.



I am thinking [2] is better.
Comments are welcome.



I recently tried to do [1] for a bunch of SPL #defines, and the attempt
ended in me git stashing the whole thing and putting it off for a later
date. The amount of work this approach requires feels very prohibitive,
and I agree that it is likely to be disruptive, so I'm in favour of
[2] as well.

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


Re: [U-Boot] [PATCH 3/5] spi: sf: Support byte program for sst spi flash

2014-10-27 Thread Jagan Teki
On 23 October 2014 19:06, Bin Meng bmeng...@gmail.com wrote:
 Currently if SST flash advertises SST_WP flag in the params table
 the word program command (ADh) with auto address increment will be
 used for the flash write op. However some SPI controllers do not
 support the word program command (like the Intel ICH 7), the byte
 programm command (02h) has to be used.

 A new TX operation mode SPI_OPM_TX_BP is introduced for such SPI
 controller to use byte program op for SST flash.

 Signed-off-by: Bin Meng bmeng...@gmail.com
 ---
  drivers/mtd/spi/sf_internal.h |  2 ++
  drivers/mtd/spi/sf_ops.c  | 31 +++
  drivers/mtd/spi/sf_probe.c|  8 ++--
  drivers/spi/ich.c |  9 +++--
  include/spi.h |  1 +
  5 files changed, 47 insertions(+), 4 deletions(-)

 diff --git a/drivers/mtd/spi/sf_internal.h b/drivers/mtd/spi/sf_internal.h
 index 19d4914..c185e04 100644
 --- a/drivers/mtd/spi/sf_internal.h
 +++ b/drivers/mtd/spi/sf_internal.h
 @@ -77,6 +77,8 @@

  int sst_write_wp(struct spi_flash *flash, u32 offset, size_t len,
 const void *buf);
 +int sst_write_bp(struct spi_flash *flash, u32 offset, size_t len,
 +   const void *buf);
  #endif

I believe byte write is already been used within the sst_write_wp -
please check.


  /* Send a single-byte command to the device and read the response */
 diff --git a/drivers/mtd/spi/sf_ops.c b/drivers/mtd/spi/sf_ops.c
 index 85cf22d..3703acb 100644
 --- a/drivers/mtd/spi/sf_ops.c
 +++ b/drivers/mtd/spi/sf_ops.c
 @@ -516,4 +516,35 @@ int sst_write_wp(struct spi_flash *flash, u32 offset, 
 size_t len,
 spi_release_bus(flash-spi);
 return ret;
  }
 +
 +int sst_write_bp(struct spi_flash *flash, u32 offset, size_t len,
 +   const void *buf)

This function is simply calling existing sst_byte_write().

 +{
 +   size_t actual;
 +   int ret;
 +
 +   ret = spi_claim_bus(flash-spi);
 +   if (ret) {
 +   debug(SF: Unable to claim SPI bus\n);
 +   return ret;
 +   }
 +
 +   for (actual = 0; actual  len; actual++) {
 +   ret = sst_byte_write(flash, offset, buf + actual);
 +   if (ret) {
 +   debug(SF: sst byte program failed\n);
 +   break;
 +   }
 +   offset++;
 +   }
 +
 +   if (!ret)
 +   ret = spi_flash_cmd_write_disable(flash);
 +
 +   debug(SF: sst: program %s %zu bytes @ 0x%zx\n,
 + ret ? failure : success, len, offset - actual);
 +
 +   spi_release_bus(flash-spi);
 +   return ret;
 +}
  #endif
 diff --git a/drivers/mtd/spi/sf_probe.c b/drivers/mtd/spi/sf_probe.c
 index 4d148d1..1b48955 100644
 --- a/drivers/mtd/spi/sf_probe.c
 +++ b/drivers/mtd/spi/sf_probe.c
 @@ -138,8 +138,12 @@ static struct spi_flash 
 *spi_flash_validate_params(struct spi_slave *spi,
 /* Assign spi_flash ops */
 flash-write = spi_flash_cmd_write_ops;
  #ifdef CONFIG_SPI_FLASH_SST
 -   if (params-flags  SST_WP)
 -   flash-write = sst_write_wp;
 +   if (params-flags  SST_WP) {
 +   if (flash-spi-op_mode_tx  SPI_OPM_TX_BP)
 +   flash-write = sst_write_bp;
 +   else
 +   flash-write = sst_write_wp;
 +   }
  #endif
 flash-erase = spi_flash_cmd_erase_ops;
 flash-read = spi_flash_cmd_read_ops;
 diff --git a/drivers/spi/ich.c b/drivers/spi/ich.c
 index b356411..16730ec 100644
 --- a/drivers/spi/ich.c
 +++ b/drivers/spi/ich.c
 @@ -141,9 +141,14 @@ struct spi_slave *spi_setup_slave(unsigned int bus, 
 unsigned int cs,
 ich-slave.max_write_size = ctlr.databytes;
 ich-speed = max_hz;

 -   /* ICH 7 SPI controller only supports array read command */
 -   if (ctlr.ich_version == 7)
 +   /*
 +* ICH 7 SPI controller only supports array read command
 +* and byte program command for SST flash
 +*/
 +   if (ctlr.ich_version == 7) {
 ich-slave.op_mode_rx = SPI_OPM_RX_AS;
 +   ich-slave.op_mode_tx = SPI_OPM_TX_BP;
 +   }

SST commands(write) is different than normal flash commands,  I don't like
to change the controller driver to know the flash command usage.

May be this part can think later, try to see above comments.


 return ich-slave;
  }
 diff --git a/include/spi.h b/include/spi.h
 index ffd6647..a4d3f5f 100644
 --- a/include/spi.h
 +++ b/include/spi.h
 @@ -34,6 +34,7 @@

  /* SPI TX operation modes */
  #define SPI_OPM_TX_QPP 1  0
 +#define SPI_OPM_TX_BP  1  1

  /* SPI RX operation modes */
  #define SPI_OPM_RX_AS  1  0
 --
 1.8.2.1


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


Re: [U-Boot] [PATCH 4/5] sf: Update SST25* flash params of supported read commands

2014-10-27 Thread Jagan Teki
On 23 October 2014 19:07, Bin Meng bmeng...@gmail.com wrote:
 Explicitly list supported read commands in the flash prarmas table
 for SST25* flash parts.

 Signed-off-by: Bin Meng bmeng...@gmail.com
 ---
  drivers/mtd/spi/sf_params.c | 20 ++--
  include/spi_flash.h |  3 ++-
  2 files changed, 12 insertions(+), 11 deletions(-)

 diff --git a/drivers/mtd/spi/sf_params.c b/drivers/mtd/spi/sf_params.c
 index 453edf0..d5f3597 100644
 --- a/drivers/mtd/spi/sf_params.c
 +++ b/drivers/mtd/spi/sf_params.c
 @@ -88,16 +88,16 @@ const struct spi_flash_params spi_flash_params_table[] = {
 {N25Q1024A,  0x20bb21, 0x0,   64 * 1024,  2048, RD_FULL, 
 WR_QPP | E_FSR | SECT_4K},
  #endif
  #ifdef CONFIG_SPI_FLASH_SST/* SST */
 -   {SST25VF040B,0xbf258d, 0x0,   64 * 1024, 8,   0,
   SECT_4K | SST_WP},
 -   {SST25VF080B,0xbf258e, 0x0,   64 * 1024,16,   0,
   SECT_4K | SST_WP},
 -   {SST25VF016B,0xbf2541, 0x0,   64 * 1024,32,   0,
   SECT_4K | SST_WP},
 -   {SST25VF032B,0xbf254a, 0x0,   64 * 1024,64,   0,
   SECT_4K | SST_WP},
 -   {SST25VF064C,0xbf254b, 0x0,   64 * 1024,   128,   0,
SECT_4K},
 -   {SST25WF512, 0xbf2501, 0x0,   64 * 1024, 1,   0,
   SECT_4K | SST_WP},
 -   {SST25WF010, 0xbf2502, 0x0,   64 * 1024, 2,   0,
   SECT_4K | SST_WP},
 -   {SST25WF020, 0xbf2503, 0x0,   64 * 1024, 4,   0,
   SECT_4K | SST_WP},
 -   {SST25WF040, 0xbf2504, 0x0,   64 * 1024, 8,   0,
   SECT_4K | SST_WP},
 -   {SST25WF080, 0xbf2505, 0x0,   64 * 1024,16,   0,
   SECT_4K | SST_WP},
 +   {SST25VF040B,0xbf258d, 0x0,   64 * 1024, 8, RD_SLOW,
   SECT_4K | SST_WP},
 +   {SST25VF080B,0xbf258e, 0x0,   64 * 1024,16, RD_SLOW,
   SECT_4K | SST_WP},
 +   {SST25VF016B,0xbf2541, 0x0,   64 * 1024,32, RD_SLOW,
   SECT_4K | SST_WP},
 +   {SST25VF032B,0xbf254a, 0x0,   64 * 1024,64, RD_SLOW,
   SECT_4K | SST_WP},
 +   {SST25VF064C,0xbf254b, 0x0,   64 * 1024,   128, RD_EXTN,
SECT_4K},
 +   {SST25WF512, 0xbf2501, 0x0,   64 * 1024, 1, RD_SLOW,
   SECT_4K | SST_WP},
 +   {SST25WF010, 0xbf2502, 0x0,   64 * 1024, 2, RD_SLOW,
   SECT_4K | SST_WP},
 +   {SST25WF020, 0xbf2503, 0x0,   64 * 1024, 4, RD_SLOW,
   SECT_4K | SST_WP},
 +   {SST25WF040, 0xbf2504, 0x0,   64 * 1024, 8, RD_SLOW,
   SECT_4K | SST_WP},
 +   {SST25WF080, 0xbf2505, 0x0,   64 * 1024,16, RD_SLOW,
   SECT_4K | SST_WP},
  #endif
  #ifdef CONFIG_SPI_FLASH_WINBOND/* WINBOND */
 {W25P80, 0xef2014, 0x0,   64 * 1024,16,   0,
  0},
 diff --git a/include/spi_flash.h b/include/spi_flash.h
 index 408a5b4..a75e030 100644
 --- a/include/spi_flash.h
 +++ b/include/spi_flash.h
 @@ -46,7 +46,8 @@ enum spi_read_cmds {
 QUAD_OUTPUT_FAST = 1  3,
 QUAD_IO_FAST = 1  4,
  };
 -#define RD_EXTNARRAY_SLOW | DUAL_OUTPUT_FAST | DUAL_IO_FAST
 +#define RD_SLOWARRAY_SLOW
 +#define RD_EXTNRD_SLOW | DUAL_OUTPUT_FAST | DUAL_IO_FAST
  #define RD_FULLRD_EXTN | QUAD_OUTPUT_FAST | QUAD_IO_FAST

  /* Dual SPI flash memories */
 --
 1.8.2.1


What is this, by defining RD_EXTN the fastest read cmd will pick based
on controller mode_rx
Why this RD_SLOW again? does this means the specific flash part will
only support slow read?

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


[U-Boot] [U-BOOT PATCH] zynq: Use GPLed files for SPL

2014-10-27 Thread Soren Brinkmann
The latest Xilinx tools generate ps7_init files that are explicitly
available under GPL. Change the makefile to allow drop in of those files
for building the SPL.

Signed-off-by: Soren Brinkmann soren.brinkm...@xilinx.com
---
 board/xilinx/zynq/Makefile | 6 +++---
 board/xilinx/zynq/xil_io.h | 2 +-
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/board/xilinx/zynq/Makefile b/board/xilinx/zynq/Makefile
index 71c0c351f929..f71b272e7e7c 100644
--- a/board/xilinx/zynq/Makefile
+++ b/board/xilinx/zynq/Makefile
@@ -7,9 +7,9 @@
 
 obj-y  := board.o
 
-# Please copy ps7_init.c/h from hw project to this directory
+# Please copy ps7_init_gpl.c/h from hw project to this directory
 obj-$(CONFIG_SPL_BUILD) += \
-   $(if $(wildcard $(srctree)/$(src)/ps7_init.c), ps7_init.o)
+   $(if $(wildcard $(srctree)/$(src)/ps7_init_gpl.c), 
ps7_init_gpl.o)
 
 # Suppress warning: function declaration isn't a prototype
-CFLAGS_REMOVE_ps7_init.o := -Wstrict-prototypes
+CFLAGS_REMOVE_ps7_init_gpl.o := -Wstrict-prototypes
diff --git a/board/xilinx/zynq/xil_io.h b/board/xilinx/zynq/xil_io.h
index e59a977eb174..1eccf8d91d09 100644
--- a/board/xilinx/zynq/xil_io.h
+++ b/board/xilinx/zynq/xil_io.h
@@ -6,7 +6,7 @@
 #define XIL_IO_H
 
 /*
- * This empty file is here because ps7_init.c exported by hw project
+ * This empty file is here because ps7_init_gpl.c exported by hw project
  * has #include xil_io.h line.
  */
 
-- 
2.1.2.1.g5e69ed6

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


Re: [U-Boot] [ 1/2] tqma6: fix sf detection

2014-10-27 Thread Jagan Teki
On 23 October 2014 19:17, Markus Niebel list-09_u-b...@tqsc.de wrote:
 From: Markus Niebel markus.nie...@tq-group.com

 Commit 155fa9af95ac5be857a7327e7a968a296e60d4c8 changed the way
 to define a GPIO line, which can be used to force CS high
 across multiple transactions. In order to fix sf detection
 change board code to make use of board_spi_cs_gpio(..).

 Signed-off-by: Markus Niebel markus.nie...@tq-group.com
 ---
  board/tqc/tqma6/tqma6.c | 10 +-
  include/configs/tqma6.h | 19 ---
  2 files changed, 25 insertions(+), 4 deletions(-)

 diff --git a/board/tqc/tqma6/tqma6.c b/board/tqc/tqma6/tqma6.c
 index b552bb8..fd1bd59 100644
 --- a/board/tqc/tqma6/tqma6.c
 +++ b/board/tqc/tqma6/tqma6.c
 @@ -138,8 +138,10 @@ static iomux_v3_cfg_t const tqma6_ecspi1_pads[] = {
 NEW_PAD_CTRL(MX6_PAD_EIM_D18__ECSPI1_MOSI, SPI_PAD_CTRL),
  };

 +#define TQMA6_SF_CS_GPIO IMX_GPIO_NR(3, 19)
 +
  static unsigned const tqma6_ecspi1_cs[] = {
 -   IMX_GPIO_NR(3, 19),
 +   TQMA6_SF_CS_GPIO,
  };

  static void tqma6_iomuxc_spi(void)
 @@ -152,6 +154,12 @@ static void tqma6_iomuxc_spi(void)
  ARRAY_SIZE(tqma6_ecspi1_pads));
  }

 +int board_spi_cs_gpio(unsigned bus, unsigned cs)
 +{
 +   return ((bus == CONFIG_SF_DEFAULT_BUS) 
 +   (cs == CONFIG_SF_DEFAULT_CS)) ? TQMA6_SF_CS_GPIO : -1;
 +}
 +

This always be a puzzle to me, (spi flash, here) driver controlled
stuff is validating in board entries.
Which I couldn't see a correct idea.

  static struct i2c_pads_info tqma6_i2c3_pads = {
 /* I2C3: on board LM75, M24C64,  */
 .scl = {
 diff --git a/include/configs/tqma6.h b/include/configs/tqma6.h
 index 2705d2c..9ba0155 100644
 --- a/include/configs/tqma6.h
 +++ b/include/configs/tqma6.h
 @@ -9,13 +9,26 @@
  #ifndef __CONFIG_H
  #define __CONFIG_H

 +#define CONFIG_MX6
 +
 +/* SPL */
 +/* #if defined(CONFIG_SPL_BUILD) */
 +
 +#define CONFIG_SPL_MMC_SUPPORT
 +#define CONFIG_SPL_SPI_SUPPORT
 +#define CONFIG_SPL_FAT_SUPPORT
 +#define CONFIG_SPL_EXT_SUPPORT
 +
 +/* common IMX6 SPL configuration */
 +#include imx6_spl.h
 +
 +/* #endif */
 +
  #include mx6_common.h
  #include asm/arch/imx-regs.h
  #include asm/imx-common/gpio.h
  #include linux/sizes.h

 -#define CONFIG_MX6
 -
  #if defined(CONFIG_MX6DL) || defined(CONFIG_MX6S)
  #define PHYS_SDRAM_SIZE(512u * SZ_1M)
  #elif defined(CONFIG_MX6Q) || defined(CONFIG_MX6D)
 @@ -57,7 +70,7 @@

  #define CONFIG_CMD_SF
  #define CONFIG_SF_DEFAULT_BUS  0
 -#define CONFIG_SF_DEFAULT_CS   (0 | (IMX_GPIO_NR(3, 19)  8))
 +#define CONFIG_SF_DEFAULT_CS   0
  #define CONFIG_SF_DEFAULT_SPEED5000
  #define CONFIG_SF_DEFAULT_MODE (SPI_MODE_0)

 --
 2.1.1

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


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


[U-Boot] [PATCH 1/2] mpc85xx/t208xqds: Adjust DDR timing parameters

2014-10-27 Thread York Sun
Adjust timing for dual-rank UDIMM, verified on M3CQ-8GHS3C0E for speed of
1066, 1333, 1600, 1866MT/s. The 1866 timing is copied to 2133 timing in
case such DIMM comes available.

Also update single-rank 1866 timing. Enable interactive debugging as well.

Signed-off-by: York Sun york...@freescale.com
CC: Shengzhou Liu shengzhou@freescale.com
---
 board/freescale/t208xqds/ddr.h |   15 +++
 include/configs/T208xQDS.h |2 +-
 2 files changed, 8 insertions(+), 9 deletions(-)

diff --git a/board/freescale/t208xqds/ddr.h b/board/freescale/t208xqds/ddr.h
index ed52fef6..9c26fdf 100644
--- a/board/freescale/t208xqds/ddr.h
+++ b/board/freescale/t208xqds/ddr.h
@@ -28,17 +28,16 @@ static const struct board_specific_parameters udimm0[] = {
 *   num|  hi| rank|  clk| wrlvl | wrlvl | wrlvl |
 * ranks| mhz| GB  |adjst| start | ctl2  | ctl3  |
 */
-   {2,  1200,  0,  5,  7,  0x0808090a,  0x0b0c0c0a},
-   {2,  1500,  0,  5,  6,  0x07070809,  0x0a0b0b09},
-   {2,  1600,  0,  5,  8,  0x090b0b0d,  0x0d0e0f0b},
-   {2,  1700,  0,  4,  7,  0x080a0a0c,  0x0c0d0e0a},
-   {2,  1900,  0,  5,  9,  0x0a0b0c0e,  0x0f10120c},
-   {2,  2140,  0,  4,  8,  0x090a0b0d,  0x0e0f110b},
+   {2,  1200,  0,  5,  7,  0x0708090a,  0x0b0c0d09},
+   {2,  1400,  0,  5,  7,  0x08090a0c,  0x0d0e0f0a},
+   {2,  1700,  0,  5,  8,  0x090a0b0c,  0x0e10110c},
+   {2,  1900,  0,  5,  8,  0x090b0c0f,  0x1012130d},
+   {2,  2140,  0,  5,  8,  0x090b0c0f,  0x1012130d},
{1,  1200,  0,  5,  7,  0x0808090a,  0x0b0c0c0a},
{1,  1500,  0,  5,  6,  0x07070809,  0x0a0b0b09},
{1,  1600,  0,  5,  8,  0x090b0b0d,  0x0d0e0f0b},
-   {1,  1700,  0,  4,  7,  0x080a0a0c,  0x0c0d0e0a},
-   {1,  1900,  0,  5,  9,  0x0a0b0c0e,  0x0f10120c},
+   {1,  1700,  0,  4,  8,  0x080a0a0c,  0x0c0d0e0a},
+   {1,  1900,  0,  5,  8,  0x090a0c0d,  0x0e0f110c},
{1,  2140,  0,  4,  8,  0x090a0b0d,  0x0e0f110b},
{}
 };
diff --git a/include/configs/T208xQDS.h b/include/configs/T208xQDS.h
index 2733358..3426b55 100644
--- a/include/configs/T208xQDS.h
+++ b/include/configs/T208xQDS.h
@@ -234,7 +234,7 @@ unsigned long get_board_ddr_clk(void);
 #define CONFIG_FSL_DDR_FIRST_SLOT_QUAD_CAPABLE
 #define CONFIG_DDR_SPD
 #define CONFIG_SYS_FSL_DDR3
-#undef CONFIG_FSL_DDR_INTERACTIVE
+#define CONFIG_FSL_DDR_INTERACTIVE
 #define CONFIG_SYS_SPD_BUS_NUM 0
 #define CONFIG_SYS_SDRAM_SIZE  2048/* for fixed parameter use */
 #define SPD_EEPROM_ADDRESS10x51
-- 
1.7.9.5

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


[U-Boot] [PATCH 2/2] mpc85xx/t2080: Fix parsing DDR ratio for new revision

2014-10-27 Thread York Sun
T2080 rev 1.1 changes MEM_RAT in RCW, which requires new parsing for ratio,
the same way as T4240 rev 2.0.

Signed-off-by: York Sun york...@freescale.com
CC: Shengzhou Liu shengzhou@freescale.com
---
 arch/powerpc/cpu/mpc85xx/speed.c |   23 ---
 1 file changed, 20 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/cpu/mpc85xx/speed.c b/arch/powerpc/cpu/mpc85xx/speed.c
index 3236f6a..9d2a3b9 100644
--- a/arch/powerpc/cpu/mpc85xx/speed.c
+++ b/arch/powerpc/cpu/mpc85xx/speed.c
@@ -37,6 +37,7 @@ void get_sys_info(sys_info_t *sys_info)
 #ifdef CONFIG_SYS_FSL_QORIQ_CHASSIS2
int cc_group[12] = CONFIG_SYS_FSL_CLUSTER_CLOCKS;
 #endif
+   __maybe_unused u32 svr;
 
const u8 core_cplx_PLL[16] = {
[ 0] = 0,   /* CC1 PPL / 1 */
@@ -122,11 +123,27 @@ void get_sys_info(sys_info_t *sys_info)
/* T4240/T4160 Rev2.0 MEM_PLL_RAT uses a value which is half of
 * T4240/T4160 Rev1.0. eg. It's 12 in Rev1.0, however, for Rev2.0
 * it uses 6.
+* T2080 rev 1.1 and later also use half mem_pll comparing with rev 1.0
 */
 #if defined(CONFIG_PPC_T4240) || defined(CONFIG_PPC_T4160) || \
-   defined(CONFIG_PPC_T4080)
-   if (SVR_MAJ(get_svr()) = 2)
-   mem_pll_rat *= 2;
+   defined(CONFIG_PPC_T4080) || defined(CONFIG_PPC_T2080)
+   svr = get_svr();
+   switch (SVR_SOC_VER(svr)) {
+   case SVR_T4240:
+   case SVR_T4160:
+   case SVR_T4120:
+   case SVR_T4080:
+   if (SVR_MAJ(svr) = 2)
+   mem_pll_rat *= 2;
+   break;
+   case SVR_T2080:
+   case SVR_T2081:
+   if ((SVR_MAJ(svr)  1) || (SVR_MIN(svr) = 1))
+   mem_pll_rat *= 2;
+   break;
+   default:
+   break;
+   }
 #endif
if (mem_pll_rat  2)
sys_info-freq_ddrbus *= mem_pll_rat;
-- 
1.7.9.5

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


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

2014-10-27 Thread Jagannadha Sutradharudu Teki
Hi Tom,

Please pull this PR.

thanks!
--
Jagan.

The following changes since commit 0ce4af99c07acebf4fce9a91f1099d2460629293:

  Merge branch 'master' of git://git.denx.de/u-boot-imx (2014-10-27 09:08:42 
-0400)

are available in the git repository at:


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

for you to fetch changes up to 027a9a002455a1175b0f5b7c7c5350afab2b4421:

  SPI: mxc_spi: delay initialisation until claim bus (2014-10-27 22:37:03 +0530)


Marek Vasut (7):
  spi: altera: Use struct-based register access
  spi: altera: Clean up bit definitions
  spi: altera: Clean up most checkpatch issues
  spi: altera: Zap endless loop
  spi: altera: Clean up the use of variable d
  spi: altera: Add short note about EPCS/EPCQx1
  spi: altera: Move the config options to the top

Markus Niebel (2):
  SPI: mxc_spi: remove second reset from ECSPI config handler
  SPI: mxc_spi: delay initialisation until claim bus

 doc/SPI/README.altera_spi |   6 +++
 drivers/spi/altera_spi.c  | 132 ++
 drivers/spi/mxc_spi.c |  40 +++---
 3 files changed, 101 insertions(+), 77 deletions(-)
 create mode 100644 doc/SPI/README.altera_spi
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH] powerpc/t1040qds: Update DDR option

2014-10-27 Thread York Sun
Enable interactive debugging by default. Remove DDR controller interleaving
because this SoC only has one controller. Use auto chip-select interleaving
to detect number of ranks.

Signed-off-by: York Sun york...@freescale.com
CC: Poonam Aggrwal poonam.aggr...@freescale.com
---
 include/configs/T1040QDS.h |5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/include/configs/T1040QDS.h b/include/configs/T1040QDS.h
index 1d0664d..0a82fd5 100644
--- a/include/configs/T1040QDS.h
+++ b/include/configs/T1040QDS.h
@@ -176,8 +176,8 @@ unsigned long get_board_ddr_clk(void);
 #define CONFIG_DDR_SPD
 #ifndef CONFIG_SYS_FSL_DDR4
 #define CONFIG_SYS_FSL_DDR3
-#define CONFIG_FSL_DDR_INTERACTIVE
 #endif
+#define CONFIG_FSL_DDR_INTERACTIVE
 
 #define CONFIG_SYS_SPD_BUS_NUM 0
 #define SPD_EEPROM_ADDRESS 0x51
@@ -769,8 +769,7 @@ unsigned long get_board_ddr_clk(void);
 #define __USB_PHY_TYPE utmi
 
 #defineCONFIG_EXTRA_ENV_SETTINGS   \
-   hwconfig=fsl_ddr:ctlr_intlv=cacheline,\
-   bank_intlv=cs0_cs1;   \
+   hwconfig=fsl_ddr:bank_intlv=auto; \
usb1:dr_mode=host,phy_type= __stringify(__USB_PHY_TYPE) \0\
netdev=eth0\0 \
video-mode=fslfb:1024x768-32@60,monitor=dvi\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 00/14] Set of fixes for Exynos4xxx boards

2014-10-27 Thread Simon Glass
Hi Przemyslaw,

On 24 October 2014 09:44, Przemyslaw Marczak p.marc...@samsung.com wrote:
 Hello Simon, Tom,

 The last driver-model changes was merged too fast and I was not able
 to test it well on all my boards. It was worked well for the first
 look, but after deep testing - it required some additional work to do.

 So this is a set of fixes required for Exynos4xxx boards.
 I am not sure what about the Origen.

 The patchset was rebased on the top of u-boot-dm/master, which is now:
 c2ded96 serial: remove uniphier_serial_initialize() call

 Tested on:
 - Trats (E4210)
 - UniversalC210 (E4210)
 - Trats2 (E4412)
 - Odroid U3 (E4412)
 - Odroid X2 (E4412)

Actually I never did update the device tree numbering so I suspect
this series has been incorrect since version 1! Since exynos5 was
always sequential I somehow missing thinking about it. This is great,
thanks for straightening it all out and testing. Particularly I am
pleased about Universal since the soft SPI was a bit of a poke in the
dark.

I'll go through this soon. I was also planning to send a patch to
clean up some of the gpio_name_num_table stuff since it shouldn't be
needed any more.

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


Re: [U-Boot] [PATCH v2 04/11] fdt: Add device tree memory bindings

2014-10-27 Thread Simon Glass
Hi Tom,

On 27 October 2014 08:24, Tom Rini tr...@ti.com wrote:
 On Fri, Oct 24, 2014 at 02:04:00PM -0600, Simon Glass wrote:
 Hi Tom,

 On 24 October 2014 12:49, Tom Rini tr...@ti.com wrote:
  On Thu, Oct 23, 2014 at 06:58:50PM -0600, Simon Glass wrote:
 
  From: Michael Pratt mpr...@chromium.org
 
  Support a default memory bank, specified in reg, as well as
  board-specific memory banks in subtree board-id nodes.
 
  This allows memory information to be provided in the device tree,
  rather than hard-coded in, which will make it simpler to handle
  similar devices with different memory banks, as the board-id values
  or masks can be used to match devices.
  [snip]
  +++ b/doc/device-tree-bindings/memory/memory.txt
  @@ -0,0 +1,67 @@
  +* Memory binding
  +
  +The memory binding for U-Boot is as in the ePAPR with the following 
  additions:
 
  I am wary of being different from ePAPR / Linux Kernel.  What do we need
  this for / when do we use it?

 This extends the existing binding. It allows the location and size of
 memory to be set by a board ID. Unfortunately on sopme hardware you
 get a hang if you try to access memory that doesn't exist, so this
 allows the range of available memory to be defined - or at least the
 maximum bound since we still probe the memory size within that range.

 This feature is used on several Exynos Chromebooks.

 So that you can use the same DT on several disjoint boards?  How does
 this work with the kernel, does U-Boot then pass along only the correct
 map?  Patches to the kernel to also deal with this?

Typically a board may have variants with different amounts of memory,
detected at run-time by GPIOs. We want the option of using the same DT
for these, similar to what the Compulab people were talking about -
otherwise we have something of an explosion of combinations.

Yes U-Boot (already) puts the correct memory map together for the
kernel, so it all works from start to finish.

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


Re: [U-Boot] Regression with ubifs initialization

2014-10-27 Thread Andrew Ruder
On Mon, Oct 27, 2014 at 09:45:16AM -0500, Andrew Ruder wrote:
 On Mon, Oct 27, 2014 at 03:33:00PM +0100, Wolfgang Denk wrote:
   It appears that 2014.10 has some issues with UBIFS initialization
   (details at bottom).  git-bisect results in one of the following commits
   being broken.  Surely it is the mtd one, but its parent commit
   (compat.h) does not compile.
  
  Which board are you talking about?
 
 I have a board with a PXA270 and NOR flash.  I am happy to submit the
 patches which add the board support, but they aren't really ready and
 cleaned up for submission.
 
  And which toolchain(s) are/have you been using to build U-Boot?
 
 A crosstools-ng compiled gcc 4.8.2.

Wolfgang and I talked quite a bit on IRC and just catching up anyone
else looking at this with a few additional details that came out of
this.

The problem appears to stem from 'ubi part data' completing with no
errors while also not filling in any of the ubi_devices[] array.  This
in turn results in the global 'ubi' variable being NULL (on PXA270 this
is u-boot in flash).  At this point display_ubi_info() gets passed NULL
and ends up printing compiler-dependent junk for all the values.

That being said, I tried 4.9.1 and had the same issue
(display_ubi_info() being passed NULL) with different symptoms (complete
lock up because it ends up hitting data alignment issues when it starts
treating opcodes as pointers).

- Andy


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


Re: [U-Boot] [PATCH v1 1/1] odroid: Turn blue LED on in u-boot

2014-10-27 Thread Suriyan Ramasami
Hello Przemyslaw Marczak,

On Mon, Oct 27, 2014 at 4:35 AM, Przemyslaw Marczak
p.marc...@samsung.com wrote:
 Hello Suriyan,

 On 10/10/2014 12:20 AM, Suriyan Ramasami wrote:

 To indicate that u-boot is active turn on the blue LED.

 Signed-off-by: Suriyan Ramasami suriya...@gmail.com
 ---
   board/samsung/odroid/odroid.c | 3 +++
   1 file changed, 3 insertions(+)

 diff --git a/board/samsung/odroid/odroid.c b/board/samsung/odroid/odroid.c
 index fd5d2d2..391a287 100644
 --- a/board/samsung/odroid/odroid.c
 +++ b/board/samsung/odroid/odroid.c
 @@ -374,6 +374,9 @@ static void board_gpio_init(void)
 gpio_set_pull(EXYNOS4X12_GPIO_X31, S5P_GPIO_PULL_UP);
 gpio_set_drv(EXYNOS4X12_GPIO_X31, S5P_GPIO_DRV_4X);
 gpio_direction_input(EXYNOS4X12_GPIO_X31);
 +
 +   /* Enable blue LED */


 Here you will need to add gpio_request() call, e.g.
 http://patchwork.ozlabs.org/patch/403197/


OK, I shall do that.


 +   gpio_direction_output(EXYNOS4X12_GPIO_C10, 0);
   }

   static int pmic_init_max77686(void)


 This looks good, but please wait until the patch series merge:
 http://patchwork.ozlabs.org/patch/403186/ (starts from this commit)


OK, I shall send a v2 with the gpio_request() call after the patch
series you have mentioned merges.
Thanks!
- Suriyan

 Best regards,
 --
 Przemyslaw Marczak
 Samsung RD Institute Poland
 Samsung Electronics
 p.marc...@samsung.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] MKIMAGE u-boot.imx build error

2014-10-27 Thread Kucharczyk, David
Hi, I am in the middle of upgrading u-boot-2009.08 to u-boot-2014.07. Our 
resident u-boot expert is on vacation and I'm running into some issues. After 
working through a ton of compile errors I think I'm getting close.

Our system is based on the Freescale iMX53.

I am able to build and run on a mx53loco development board just fine, but for 
some reason I'm getting the below error when building for our custom board, 
which is similar to the development board.

I've compared the development board files to our files and I can't pinpoint why 
mkimage is giving a problem.


  LD  u-boot
  OBJCOPY u-boot.bin
  CFGSboard/freescale/mx53_gogo/imximage.cfg.cfgtmp
  MKIMAGE u-boot.imx
Usage: /home/dk/linux-upgrade/bootloader/u-boot-2014.07/tools/mkimage -l image
  -l == list image header information
   /home/dk/linux-upgrade/bootloader/u-boot-2014.07/tools/mkimage [-x] -A 
arch -O os -T type -C comp -a addr -e ep -n name -d data_file[:data_file...] 
image
  -A == set architecture to 'arch'
  -O == set operating system to 'os'
  -T == set image type to 'type'
  -C == set compression type 'comp'
  -a == set load address to 'addr' (hex)
  -e == set entry point to 'ep' (hex)
  -n == set image name to 'name'
  -d == use image data from 'datafile'
  -x == set XIP (execute in place)
   /home/dk/linux-upgrade/bootloader/u-boot-2014.07/tools/mkimage [-D 
dtc_options] [-f fit-image.its|-F] fit-image
  -D = set options for device tree compiler
  -f = input filename for FIT source
Signing / verified boot not supported (CONFIG_FIT_SIGNATURE undefined)
   /home/dk/linux-upgrade/bootloader/u-boot-2014.07/tools/mkimage -V == 
print version information and exit
make[1]: *** [u-boot.imx] Error 1
make: *** [u-boot.imx] Error 2
gogo build failed

If I set #define CONFIG_FIT_SIGNATURE in the config file then I get a ton of 
other build errors so I'm not sure if that's the correct path to take. Besides, 
the development board doesn't have CONFIG_FIT_SIGNATURE defined in its config 
file.

Any help would be greatly appreciated.

Thanks,
Dave

Please be advised that this email may contain confidential information. If you 
are not the intended recipient, please notify us by email by replying to the 
sender and delete this message. The sender disclaims that the content of this 
email constitutes an offer to enter into, or the acceptance of, any agreement; 
provided that the foregoing does not invalidate the binding effect of any 
digital or other electronic reproduction of a manual signature that is included 
in any attachment.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v2 1/3] arm: odroid: pmic77686: allow bucket voltage settings

2014-10-27 Thread Suriyan Ramasami
Hello Przemyslaw Marczak,

On Mon, Oct 27, 2014 at 4:08 AM, Przemyslaw Marczak
p.marc...@samsung.com wrote:
 Hello Suriyan,


 On 10/24/2014 05:53 PM, Suriyan Ramasami wrote:

 Hello Jaehoon Chung,


 On Thu, Oct 23, 2014 at 11:52 PM, Jaehoon Chung jh80.ch...@samsung.com
 wrote:

 Hi.

 On 10/21/2014 02:52 AM, Suriyan Ramasami wrote:

 Allow to set the bucket voltage for the max77686.
 This will be used to reset the SMC LAN9730 ethernet on the odroids.

 Signed-off-by: Suriyan Ramasami suriya...@gmail.com
 ---
   drivers/power/pmic/pmic_max77686.c | 48
 +-
   include/power/max77686_pmic.h  |  3 +++
   2 files changed, 50 insertions(+), 1 deletion(-)

 diff --git a/drivers/power/pmic/pmic_max77686.c
 b/drivers/power/pmic/pmic_max77686.c
 index df1fd91..1aeadb4 100644
 --- a/drivers/power/pmic/pmic_max77686.c
 +++ b/drivers/power/pmic/pmic_max77686.c
 @@ -42,6 +42,25 @@ static unsigned int max77686_ldo_volt2hex(int ldo,
 ulong uV)
return 0;
   }

 +static unsigned int max77686_buck_volt2hex(int buck, ulong uV)
 +{
 + unsigned int hex = 0;
 +
 + if (buck  5 || buck  9) {
 + debug(%s: buck %d is not supported\n, __func__, buck);
 + return 0;


 Here, I should return MAX77686_BUCK_VOLT_MAX_HEX + 1 instead of 0 to
 signal an error condition, as 0 is a valid non error value.

 He 'hex' value has at most 1 byte of len, so you can return the 'int' value
 and use the negative errno numbers - and there is no value conflicts.


OK, Shall use negative errno values.


 + }
 +
 + hex = (uV - 75) / 5;
 +
 + if (hex = 0  hex = MAX77686_BUCK_VOLT_MAX_HEX)
 + return hex;
 +
 + debug(%s: %ld is wrong voltage value for BUCK%d\n,
 +   __func__, uV, buck);
 + return MAX77686_BUCK_VOLT_MAX_HEX + 1;
 +}
 +
   int max77686_set_ldo_voltage(struct pmic *p, int ldo, ulong uV)
   {
unsigned int val, ret, hex, adr;
 @@ -68,6 +87,33 @@ int max77686_set_ldo_voltage(struct pmic *p, int ldo,
 ulong uV)
return ret;
   }

 +int max77686_set_buck_voltage(struct pmic *p, int buck, ulong uV)
 +{
 + unsigned int val, ret, hex, adr;
 +
 + if (buck  5  buck  9) {
 + printf(%s: %d is an unsupported bucket number\n,
 +__func__, buck);
 + return -1;


 How about using error number instead of -1?


 Could you please elaborate on this? This function always returns -1 on
 failure just like the function max77686_set_ldo_voltate() which I have
 tried to mimic as much as I can.
 I am guessing that you want me to return -EINVAL in this case? Please
 let me know, and I am OK to change it, just that this function will
 deviate from the rest of the functions in this file.

 Yes, this will be better.

OK, shall do so.



 + }
 +
 + adr = max77686_buck_addr[buck] + 1;
 + hex = max77686_buck_volt2hex(buck, uV);
 +


 if (hex  0)
 return hex;



OK, will do so.

 + if (hex == MAX77686_BUCK_VOLT_MAX_HEX + 1)
 + return -1;


 Ditto.


 I believe, I return -EINVAL here, but please look at my reasoning above.


 +
 + ret = pmic_reg_read(p, adr, val);
 + if (ret)
 + return ret;
 +
 + val = ~MAX77686_BUCK_VOLT_MASK;
 + val |= hex;
 + ret |= pmic_reg_write(p, adr, val);


 ret |= pmic_reg_write(p, addr, val | hex); ?


 OK, will change that. Again, this was done to be as close to
 max77686_set_ldo_voltate()

 Thanks and Regards!
 - Suriyan

 Best Regards,
 Jaehoon Chung

 +
 + return ret;
 +}
 +
   int max77686_set_ldo_mode(struct pmic *p, int ldo, char opmode)
   {
unsigned int val, ret, adr, mode;
 @@ -157,7 +203,7 @@ int max77686_set_buck_mode(struct pmic *p, int buck,
 char opmode)
/* mode */
switch (opmode) {
case OPMODE_OFF:
 - mode = MAX77686_BUCK_MODE_OFF;
 + mode = MAX77686_BUCK_MODE_OFF  mode_shift;
break;
case OPMODE_STANDBY:
switch (buck) {
 diff --git a/include/power/max77686_pmic.h
 b/include/power/max77686_pmic.h
 index c2a772a..b0e4255 100644
 --- a/include/power/max77686_pmic.h
 +++ b/include/power/max77686_pmic.h
 @@ -150,6 +150,7 @@ enum {

   int max77686_set_ldo_voltage(struct pmic *p, int ldo, ulong uV);
   int max77686_set_ldo_mode(struct pmic *p, int ldo, char opmode);
 +int max77686_set_buck_voltage(struct pmic *p, int buck, ulong uV);
   int max77686_set_buck_mode(struct pmic *p, int buck, char opmode);

   #define MAX77686_LDO_VOLT_MAX_HEX0x3f
 @@ -159,6 +160,8 @@ int max77686_set_buck_mode(struct pmic *p, int buck,
 char opmode);
   #define MAX77686_LDO_MODE_STANDBY(0x01  0x06)
   #define MAX77686_LDO_MODE_LPM(0x02  0x06)
   #define MAX77686_LDO_MODE_ON (0x03  0x06)
 +#define MAX77686_BUCK_VOLT_MAX_HEX   0x3f
 +#define MAX77686_BUCK_VOLT_MASK  0x3f
   #define MAX77686_BUCK_MODE_MASK  0x03
   #define MAX77686_BUCK_MODE_SHIFT_1   

[U-Boot] [PATCH v2, rebased 0/3] reduce warnings with W=1

2014-10-27 Thread Jeroen Hofstee
When compiling u-boot with W=1 there are numerous of warnings.
This patchset attempts to reduce it a bit. One source of false
warnings are the aliases missing a prototype, most of them are
replaced with __weak functions. Others are cause by missing
includes / local functions not be marked as such. At last some
actual missing prototypes are added. These are (hopefully) just
trivial patches, some less than trial is ahead of us.

v2:
  - rebase on master (most of this serie is applied, so remaining
patches are numbered differently.
  - drop PATCH 25/49 spi: make local functions static. Tom posted
a more complete cleanup.
  - Drop common/cmd_elf.c: add missing include (a slightly adjusted
version was applied).
  - split i2c: use __weak (included i2c and l2_cache)
  - redo serial: add prototypes for init functions

Jeroen Hofstee (3):
  i2c: use __weak
  arm926ejs: cache: use __weak
  serial: add prototypes for init functions

 arch/arm/cpu/arm926ejs/cache.c |   5 +-
 drivers/i2c/i2c_core.c |   4 +-
 drivers/serial/serial.c| 140 -
 include/serial.h   |  49 +++
 4 files changed, 121 insertions(+), 77 deletions(-)

-- 
2.1.0

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


[U-Boot] [PATCH v2, rebased 1/3] i2c: use __weak

2014-10-27 Thread Jeroen Hofstee
Acked-by: Heiko Schocher h...@denx.de
Signed-off-by: Jeroen Hofstee jer...@myspectrum.nl
---
 drivers/i2c/i2c_core.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/i2c/i2c_core.c b/drivers/i2c/i2c_core.c
index 18d6736..7f63987 100644
--- a/drivers/i2c/i2c_core.c
+++ b/drivers/i2c/i2c_core.c
@@ -395,9 +395,7 @@ void i2c_reg_write(uint8_t addr, uint8_t reg, uint8_t val)
i2c_write(addr, reg, 1, val, 1);
 }
 
-void __i2c_init(int speed, int slaveaddr)
+__weak void i2c_init(int speed, int slaveaddr)
 {
i2c_init_bus(i2c_get_bus_num(), speed, slaveaddr);
 }
-void i2c_init(int speed, int slaveaddr)
-   __attribute__((weak, alias(__i2c_init)));
-- 
2.1.0

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


[U-Boot] [PATCH v2, rebased 2/3] arm926ejs: cache: use __weak

2014-10-27 Thread Jeroen Hofstee
Cc: Albert Aribaud albert.u.b...@aribaud.net
Signed-off-by: Jeroen Hofstee jer...@myspectrum.nl
---
 arch/arm/cpu/arm926ejs/cache.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/arch/arm/cpu/arm926ejs/cache.c b/arch/arm/cpu/arm926ejs/cache.c
index e86c2ed..8d7873c 100644
--- a/arch/arm/cpu/arm926ejs/cache.c
+++ b/arch/arm/cpu/arm926ejs/cache.c
@@ -99,7 +99,4 @@ void flush_cache(unsigned long start, unsigned long size)
 /*
  * Stub implementations for l2 cache operations
  */
-void __l2_cache_disable(void) {}
-
-void l2_cache_disable(void)
-   __attribute__((weak, alias(__l2_cache_disable)));
+__weak void l2_cache_disable(void) {}
-- 
2.1.0

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


[U-Boot] [PATCH v2, rebased 3/3] serial: add prototypes for init functions

2014-10-27 Thread Jeroen Hofstee
While at it, sort them.

Cc: Tom Rini tr...@ti.com
Cc: Simon Glass s...@chromium.org
Signed-off-by: Jeroen Hofstee jer...@myspectrum.nl
---
 drivers/serial/serial.c | 140 
 include/serial.h|  49 +
 2 files changed, 119 insertions(+), 70 deletions(-)

diff --git a/drivers/serial/serial.c b/drivers/serial/serial.c
index 18e41b2..95c992a 100644
--- a/drivers/serial/serial.c
+++ b/drivers/serial/serial.c
@@ -109,54 +109,54 @@ U_BOOT_ENV_CALLBACK(baudrate, on_baudrate);
void name(void) \
__attribute__((weak, alias(serial_null)));
 
-serial_initfunc(mpc8xx_serial_initialize);
-serial_initfunc(ns16550_serial_initialize);
-serial_initfunc(pxa_serial_initialize);
-serial_initfunc(s3c24xx_serial_initialize);
-serial_initfunc(s5p_serial_initialize);
-serial_initfunc(zynq_serial_initialize);
-serial_initfunc(bfin_serial_initialize);
-serial_initfunc(bfin_jtag_initialize);
-serial_initfunc(mpc512x_serial_initialize);
-serial_initfunc(uartlite_serial_initialize);
-serial_initfunc(au1x00_serial_initialize);
-serial_initfunc(asc_serial_initialize);
-serial_initfunc(jz_serial_initialize);
-serial_initfunc(mpc5xx_serial_initialize);
-serial_initfunc(mpc8260_scc_serial_initialize);
-serial_initfunc(mpc8260_smc_serial_initialize);
-serial_initfunc(mpc85xx_serial_initialize);
-serial_initfunc(iop480_serial_initialize);
-serial_initfunc(leon2_serial_initialize);
-serial_initfunc(leon3_serial_initialize);
-serial_initfunc(marvell_serial_initialize);
+serial_initfunc(altera_jtag_serial_initialize);
+serial_initfunc(altera_serial_initialize);
 serial_initfunc(amirix_serial_initialize);
+serial_initfunc(arc_serial_initialize);
+serial_initfunc(arm_dcc_initialize);
+serial_initfunc(asc_serial_initialize);
+serial_initfunc(atmel_serial_initialize);
+serial_initfunc(au1x00_serial_initialize);
+serial_initfunc(bfin_jtag_initialize);
+serial_initfunc(bfin_serial_initialize);
 serial_initfunc(bmw_serial_initialize);
+serial_initfunc(clps7111_serial_initialize);
 serial_initfunc(cogent_serial_initialize);
 serial_initfunc(cpci750_serial_initialize);
 serial_initfunc(evb64260_serial_initialize);
-serial_initfunc(ml2_serial_initialize);
-serial_initfunc(sconsole_serial_initialize);
-serial_initfunc(p3mx_serial_initialize);
-serial_initfunc(altera_jtag_serial_initialize);
-serial_initfunc(altera_serial_initialize);
-serial_initfunc(atmel_serial_initialize);
-serial_initfunc(lpc32xx_serial_initialize);
-serial_initfunc(mcf_serial_initialize);
-serial_initfunc(oc_serial_initialize);
-serial_initfunc(sandbox_serial_initialize);
-serial_initfunc(clps7111_serial_initialize);
 serial_initfunc(imx_serial_initialize);
+serial_initfunc(iop480_serial_initialize);
+serial_initfunc(jz_serial_initialize);
 serial_initfunc(ks8695_serial_initialize);
+serial_initfunc(leon2_serial_initialize);
+serial_initfunc(leon3_serial_initialize);
 serial_initfunc(lh7a40x_serial_initialize);
+serial_initfunc(lpc32xx_serial_initialize);
+serial_initfunc(marvell_serial_initialize);
 serial_initfunc(max3100_serial_initialize);
+serial_initfunc(mcf_serial_initialize);
+serial_initfunc(ml2_serial_initialize);
+serial_initfunc(mpc512x_serial_initialize);
+serial_initfunc(mpc5xx_serial_initialize);
+serial_initfunc(mpc8260_scc_serial_initialize);
+serial_initfunc(mpc8260_smc_serial_initialize);
+serial_initfunc(mpc85xx_serial_initialize);
+serial_initfunc(mpc8xx_serial_initialize);
 serial_initfunc(mxc_serial_initialize);
+serial_initfunc(mxs_auart_initialize);
+serial_initfunc(ns16550_serial_initialize);
+serial_initfunc(oc_serial_initialize);
+serial_initfunc(p3mx_serial_initialize);
 serial_initfunc(pl01x_serial_initialize);
+serial_initfunc(pxa_serial_initialize);
+serial_initfunc(s3c24xx_serial_initialize);
+serial_initfunc(s5p_serial_initialize);
 serial_initfunc(sa1100_serial_initialize);
+serial_initfunc(sandbox_serial_initialize);
+serial_initfunc(sconsole_serial_initialize);
 serial_initfunc(sh_serial_initialize);
-serial_initfunc(arm_dcc_initialize);
-serial_initfunc(mxs_auart_initialize);
-serial_initfunc(arc_serial_initialize);
+serial_initfunc(uartlite_serial_initialize);
+serial_initfunc(zynq_serial_initialize);
 
 /**
  * serial_register() - Register serial driver with serial driver core
@@ -202,54 +202,54 @@ void serial_register(struct serial_device *dev)
  */
 void serial_initialize(void)
 {
-   mpc8xx_serial_initialize();
-   ns16550_serial_initialize();
-   pxa_serial_initialize();
-   s3c24xx_serial_initialize();
-   s5p_serial_initialize();
-   mpc512x_serial_initialize();
-   bfin_serial_initialize();
-   bfin_jtag_initialize();
-   uartlite_serial_initialize();
-   zynq_serial_initialize();
-   au1x00_serial_initialize();
-   asc_serial_initialize();
-   jz_serial_initialize();
-   mpc5xx_serial_initialize();
-   mpc8260_scc_serial_initialize();
-   

Re: [U-Boot] [PATCH 04/49] i2c: use __weak

2014-10-27 Thread Jeroen Hofstee

Hello Tom,

On 27-10-14 01:31, Tom Rini wrote:

On Thu, Oct 09, 2014 at 08:14:40PM +0200, Jeroen Hofstee wrote:


Hello Heiko,

On 09-10-14 07:00, Heiko Schocher wrote:

Am 08.10.2014 22:57, schrieb Jeroen Hofstee:

Signed-off-by: Jeroen Hofsteejer...@myspectrum.nl
---
  arch/arm/cpu/arm926ejs/cache.c | 5 +

This change seems to have nothing to do with the subject ...
could you please split this?


No problem, I likely accidentally squashed them.
I will repost this patch with out it and append a new one.

Did I miss it?  Thanks!




Thanks for applying most of them. I reposted the remaining ones.

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


Re: [U-Boot] [PATCH v2 3/3] arm: odroid: usb: add support for usb host including ethernet

2014-10-27 Thread Suriyan Ramasami
Hello Przemyslaw Marczak,

On Mon, Oct 27, 2014 at 4:08 AM, Przemyslaw Marczak
p.marc...@samsung.com wrote:
 Hello Suriyan,


 On 10/24/2014 06:08 PM, Suriyan Ramasami wrote:

 Hello Minkyu Kang,


 On Thu, Oct 23, 2014 at 9:58 PM, Minkyu Kang mk7.k...@samsung.com wrote:

 Dear Suriyan Ramasami,

 On 21/10/14 02:52, Suriyan Ramasami wrote:

 This change adds support for enabling the USB host features of the
 board.
 This includes the USB3503A hub and the SMC LAN9730 ethernet controller
 as well.

 Credit goes to Tushar Berara for the function set_usb_ethaddr().

 Signed-off-by: Suriyan Ramasami suriya...@gmail.com

 ---
 v2:
   * Removed an unneeded header file from ehci-exynos.c
   * Fix indentation in the dts file
 ---
   arch/arm/dts/exynos4412-odroid.dts  | 11 +++
   arch/arm/include/asm/arch-exynos/cpu.h  |  2 ++
   arch/arm/include/asm/arch-exynos/ehci.h | 13 
   board/samsung/odroid/odroid.c   | 55
 +
   drivers/usb/host/ehci-exynos.c  | 51
 +-
   include/configs/odroid.h| 13 
   6 files changed, 137 insertions(+), 8 deletions(-)

 diff --git a/arch/arm/dts/exynos4412-odroid.dts
 b/arch/arm/dts/exynos4412-odroid.dts
 index 24d0bf1..ac5fece 100644
 --- a/arch/arm/dts/exynos4412-odroid.dts
 +++ b/arch/arm/dts/exynos4412-odroid.dts
 @@ -67,4 +67,15 @@
div = 0x3;
index = 4;
};
 +
 + ehci@1258 {
 + compatible = samsung,exynos-ehci;
 + reg = 0x1258 0x100;
 + #address-cells = 1;
 + #size-cells = 1;
 + phy {
 + compatible = samsung,exynos-usb-phy;
 + reg = 0x125B 0x100;
 + };
 + };
   };
 diff --git a/arch/arm/include/asm/arch-exynos/cpu.h
 b/arch/arm/include/asm/arch-exynos/cpu.h
 index ba71714..fda21fb 100644
 --- a/arch/arm/include/asm/arch-exynos/cpu.h
 +++ b/arch/arm/include/asm/arch-exynos/cpu.h
 @@ -18,6 +18,8 @@

   #define EXYNOS4_GPIO_PART3_BASE  0x0386
   #define EXYNOS4_PRO_ID   0x1000
 +#define EXYNOS4_GUID_LOW 0x1014
 +#define EXYNOS4_GUID_HIGH0x1018
   #define EXYNOS4_SYSREG_BASE  0x1001
   #define EXYNOS4_POWER_BASE   0x1002
   #define EXYNOS4_SWRESET  0x10020400
 diff --git a/arch/arm/include/asm/arch-exynos/ehci.h
 b/arch/arm/include/asm/arch-exynos/ehci.h
 index d2d70bd..3800fa9 100644
 --- a/arch/arm/include/asm/arch-exynos/ehci.h
 +++ b/arch/arm/include/asm/arch-exynos/ehci.h
 @@ -12,6 +12,13 @@

   #define CLK_24MHZ5

 +#define PHYPWR_NORMAL_MASK_PHY0 (0x39  0)
 +#define PHYPWR_NORMAL_MASK_PHY1 (0x7  6)
 +#define PHYPWR_NORMAL_MASK_HSIC0(0x7  9)
 +#define PHYPWR_NORMAL_MASK_HSIC1(0x7  12)
 +#define RSTCON_HOSTPHY_SWRST(0xf  3)
 +#define RSTCON_SWRST(0x1  0)
 +
   #define HOST_CTRL0_PHYSWRSTALL   (1  31)
   #define HOST_CTRL0_COMMONON_N(1  9)
   #define HOST_CTRL0_SIDDQ (1  6)
 @@ -61,6 +68,12 @@ struct exynos_usb_phy {
unsigned int usbotgtune;
   };

 +struct exynos4412_usb_phy {
 + unsigned int usbphyctrl;
 + unsigned int usbphyclk;
 + unsigned int usbphyrstcon;
 +};
 +
   /* Switch on the VBUS power. */
   int board_usb_vbus_init(void);

 diff --git a/board/samsung/odroid/odroid.c
 b/board/samsung/odroid/odroid.c
 index 5edb250..6c78b67 100644
 --- a/board/samsung/odroid/odroid.c
 +++ b/board/samsung/odroid/odroid.c
 @@ -453,9 +453,64 @@ struct s3c_plat_otg_data s5pc210_otg_data = {
.usb_phy_ctrl   = EXYNOS4X12_USBPHY_CONTROL,
.usb_flags  = PHY0_SLEEP,
   };
 +#endif
 +
 +#if defined(CONFIG_USB_GADGET) || defined(CONFIG_CMD_USB)
 +
 +#ifdef CONFIG_CMD_USB
 +static void set_usb_ethaddr(void)
 +{
 + int i;
 + uchar mac[6];
 + unsigned int guid_high = readl(EXYNOS4_GUID_HIGH);
 + unsigned int guid_low = readl(EXYNOS4_GUID_LOW);


 We don't allow direct access.
 Is it special register? I can't find this register on TRM.
 If so you can make inline function at cpu.h instead.


 This register is not in the TRM. This register is possibly documented
 in the TRM for the Exynos5250. Through experimentation I found that it
 behaves the same on Exynos4412 prime as well - I checked this with one
 X2, 1 U2 and 2 U3s, and they do indeed do the job of being unique and
 hence can be used to generate the mac address which will be unique
 across all U2s/U3s/X2s and possibly other Exynos SoCs like Exynos4212
 etc.


 Those register addresses are not documented anywhere. So use of them is not
 a good idea and can cause unpredictable results, even if was tested on a few
 devices.


OK, fair enough. I thought somehow it would be documented in the
Samsung internal user 

Re: [U-Boot] [PATCH v2 3/3] arm: odroid: usb: add support for usb host including ethernet

2014-10-27 Thread Suriyan Ramasami
Hello Minkyu Kang,


On Mon, Oct 27, 2014 at 6:03 AM, Minkyu Kang mk7.k...@samsung.com wrote:
 Dear Suriyan Ramasami,

 On 25/10/14 01:08, Suriyan Ramasami wrote:
 Hello Minkyu Kang,


 On Thu, Oct 23, 2014 at 9:58 PM, Minkyu Kang mk7.k...@samsung.com wrote:
 Dear Suriyan Ramasami,

 On 21/10/14 02:52, Suriyan Ramasami wrote:
 This change adds support for enabling the USB host features of the board.
 This includes the USB3503A hub and the SMC LAN9730 ethernet controller
 as well.

 Credit goes to Tushar Berara for the function set_usb_ethaddr().

 Signed-off-by: Suriyan Ramasami suriya...@gmail.com

 ---
 v2:
  * Removed an unneeded header file from ehci-exynos.c
  * Fix indentation in the dts file
 ---
  arch/arm/dts/exynos4412-odroid.dts  | 11 +++
  arch/arm/include/asm/arch-exynos/cpu.h  |  2 ++
  arch/arm/include/asm/arch-exynos/ehci.h | 13 
  board/samsung/odroid/odroid.c   | 55 
 +
  drivers/usb/host/ehci-exynos.c  | 51 
 +-
  include/configs/odroid.h| 13 
  6 files changed, 137 insertions(+), 8 deletions(-)

 diff --git a/arch/arm/dts/exynos4412-odroid.dts 
 b/arch/arm/dts/exynos4412-odroid.dts
 index 24d0bf1..ac5fece 100644
 --- a/arch/arm/dts/exynos4412-odroid.dts
 +++ b/arch/arm/dts/exynos4412-odroid.dts
 @@ -67,4 +67,15 @@
   div = 0x3;
   index = 4;
   };
 +
 + ehci@1258 {
 + compatible = samsung,exynos-ehci;
 + reg = 0x1258 0x100;
 + #address-cells = 1;
 + #size-cells = 1;
 + phy {
 + compatible = samsung,exynos-usb-phy;
 + reg = 0x125B 0x100;
 + };
 + };
  };
 diff --git a/arch/arm/include/asm/arch-exynos/cpu.h 
 b/arch/arm/include/asm/arch-exynos/cpu.h
 index ba71714..fda21fb 100644
 --- a/arch/arm/include/asm/arch-exynos/cpu.h
 +++ b/arch/arm/include/asm/arch-exynos/cpu.h
 @@ -18,6 +18,8 @@

  #define EXYNOS4_GPIO_PART3_BASE  0x0386
  #define EXYNOS4_PRO_ID   0x1000
 +#define EXYNOS4_GUID_LOW 0x1014
 +#define EXYNOS4_GUID_HIGH0x1018
  #define EXYNOS4_SYSREG_BASE  0x1001
  #define EXYNOS4_POWER_BASE   0x1002
  #define EXYNOS4_SWRESET  0x10020400
 diff --git a/arch/arm/include/asm/arch-exynos/ehci.h 
 b/arch/arm/include/asm/arch-exynos/ehci.h
 index d2d70bd..3800fa9 100644
 --- a/arch/arm/include/asm/arch-exynos/ehci.h
 +++ b/arch/arm/include/asm/arch-exynos/ehci.h
 @@ -12,6 +12,13 @@

  #define CLK_24MHZ5

 +#define PHYPWR_NORMAL_MASK_PHY0 (0x39  0)
 +#define PHYPWR_NORMAL_MASK_PHY1 (0x7  6)
 +#define PHYPWR_NORMAL_MASK_HSIC0(0x7  9)
 +#define PHYPWR_NORMAL_MASK_HSIC1(0x7  12)
 +#define RSTCON_HOSTPHY_SWRST(0xf  3)
 +#define RSTCON_SWRST(0x1  0)
 +
  #define HOST_CTRL0_PHYSWRSTALL   (1  31)
  #define HOST_CTRL0_COMMONON_N(1  9)
  #define HOST_CTRL0_SIDDQ (1  6)
 @@ -61,6 +68,12 @@ struct exynos_usb_phy {
   unsigned int usbotgtune;
  };

 +struct exynos4412_usb_phy {
 + unsigned int usbphyctrl;
 + unsigned int usbphyclk;
 + unsigned int usbphyrstcon;
 +};
 +
  /* Switch on the VBUS power. */
  int board_usb_vbus_init(void);

 diff --git a/board/samsung/odroid/odroid.c b/board/samsung/odroid/odroid.c
 index 5edb250..6c78b67 100644
 --- a/board/samsung/odroid/odroid.c
 +++ b/board/samsung/odroid/odroid.c
 @@ -453,9 +453,64 @@ struct s3c_plat_otg_data s5pc210_otg_data = {
   .usb_phy_ctrl   = EXYNOS4X12_USBPHY_CONTROL,
   .usb_flags  = PHY0_SLEEP,
  };
 +#endif
 +
 +#if defined(CONFIG_USB_GADGET) || defined(CONFIG_CMD_USB)
 +
 +#ifdef CONFIG_CMD_USB
 +static void set_usb_ethaddr(void)
 +{
 + int i;
 + uchar mac[6];
 + unsigned int guid_high = readl(EXYNOS4_GUID_HIGH);
 + unsigned int guid_low = readl(EXYNOS4_GUID_LOW);

 We don't allow direct access.
 Is it special register? I can't find this register on TRM.
 If so you can make inline function at cpu.h instead.


 This register is not in the TRM. This register is possibly documented
 in the TRM for the Exynos5250. Through experimentation I found that it
 behaves the same on Exynos4412 prime as well - I checked this with one
 X2, 1 U2 and 2 U3s, and they do indeed do the job of being unique and
 hence can be used to generate the mac address which will be unique
 across all U2s/U3s/X2s and possibly other Exynos SoCs like Exynos4212
 etc.

 Regarding direct access, I am a bit confused. In odroid.c I see quite
 a many places which is doing a readl() of registers. Here we are
 readl(addr) into guid_* similarly, and cooking up a mac address in a
 local char array.

 I fail to see your point. Can you please elaborate more, so I can 

[U-Boot] [PATCH 1/2] am335x_evm: Add NOR to Kconfig

2014-10-27 Thread Tom Rini
Make enabling support for NOR (and describe where it's seen) be done via
Kconfig.

Signed-off-by: Tom Rini tr...@ti.com
---
 board/ti/am335x/Kconfig  |7 +++
 configs/am335x_evm_nor_defconfig |3 ++-
 configs/am335x_evm_norboot_defconfig |3 ++-
 3 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/board/ti/am335x/Kconfig b/board/ti/am335x/Kconfig
index d8958ef..0ba00bf 100644
--- a/board/ti/am335x/Kconfig
+++ b/board/ti/am335x/Kconfig
@@ -25,4 +25,11 @@ config CONS_INDEX
  board you may want something other than UART0 as for example the IDK
  uses UART3 so enter 4 here.
 
+config NOR
+   bool Support for NOR flash
+   help
+ The AM335x SoC supports having a NOR flash connected to the GPMC.
+ In practice this is seen as a NOR flash module connected to the
+ memory cape for the BeagleBone family.
+
 endif
diff --git a/configs/am335x_evm_nor_defconfig b/configs/am335x_evm_nor_defconfig
index 41f31cc02..be90163 100644
--- a/configs/am335x_evm_nor_defconfig
+++ b/configs/am335x_evm_nor_defconfig
@@ -1,5 +1,6 @@
 CONFIG_SPL=y
-CONFIG_SYS_EXTRA_OPTIONS=NAND,NOR
+CONFIG_SYS_EXTRA_OPTIONS=NAND
 CONFIG_CONS_INDEX=1
 +S:CONFIG_ARM=y
 +S:CONFIG_TARGET_AM335X_EVM=y
+CONFIG_NOR=y
diff --git a/configs/am335x_evm_norboot_defconfig 
b/configs/am335x_evm_norboot_defconfig
index 7dbfa27..d2d3ba2 100644
--- a/configs/am335x_evm_norboot_defconfig
+++ b/configs/am335x_evm_norboot_defconfig
@@ -1,4 +1,5 @@
-CONFIG_SYS_EXTRA_OPTIONS=NOR,NOR_BOOT
+CONFIG_SYS_EXTRA_OPTIONS=NOR_BOOT
 CONFIG_CONS_INDEX=1
 CONFIG_ARM=y
 CONFIG_TARGET_AM335X_EVM=y
+CONFIG_NOR=y
-- 
1.7.9.5

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


[U-Boot] [PATCH 2/2] am335x_evm: Convert NOR_BOOT to Kconfig

2014-10-27 Thread Tom Rini
Signed-off-by: Tom Rini tr...@ti.com
---
 board/ti/am335x/Kconfig  |8 
 configs/am335x_evm_norboot_defconfig |2 +-
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/board/ti/am335x/Kconfig b/board/ti/am335x/Kconfig
index 0ba00bf..883ff45 100644
--- a/board/ti/am335x/Kconfig
+++ b/board/ti/am335x/Kconfig
@@ -32,4 +32,12 @@ config NOR
  In practice this is seen as a NOR flash module connected to the
  memory cape for the BeagleBone family.
 
+config NOR_BOOT
+   bool Support for booting from NOR flash
+   depends on NOR
+   help
+ Enabling this will make a U-Boot binary that is capable of being
+ booted via NOR.  In this case we will enable certain pinmux early
+ as the ROM only partially sets up pinmux.  We also default to using
+ NOR for environment.
 endif
diff --git a/configs/am335x_evm_norboot_defconfig 
b/configs/am335x_evm_norboot_defconfig
index d2d3ba2..47ff6cd 100644
--- a/configs/am335x_evm_norboot_defconfig
+++ b/configs/am335x_evm_norboot_defconfig
@@ -1,5 +1,5 @@
-CONFIG_SYS_EXTRA_OPTIONS=NOR_BOOT
 CONFIG_CONS_INDEX=1
 CONFIG_ARM=y
 CONFIG_TARGET_AM335X_EVM=y
 CONFIG_NOR=y
+CONFIG_NOR_BOOT=y
-- 
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] e1000: fix sw fw sync on igb i210/i211

2014-10-27 Thread Tim Harvey
On Sun, Oct 26, 2014 at 2:57 PM, Marcel Ziswiler mar...@ziswiler.com wrote:
 On Thu, 2014-10-23 at 01:12 -0700, Tim Harvey wrote:
 I've never been able to get e1000_swfw_sync_acquire() to not timeout
 on the boards with i210 devices that I have (IMX6 with 2x i210
 programmed as 8086:1533 using int phys).

 Ah, OK. I see. We do use them in flash less aka iNVM only mode as
 8086:157b.

  In my case with your patch
 below as well as York's patch
 (https://patchwork.ozlabs.org/patch/400628/) I still see failures. The
 I210_SW_FW_SYNC reg returns swfw_sync=0x03, fwmask=0x2, and
 swmask=0x2 which results in:

 Driver can't access resource, SW_FW_SYNC timeout.
 Unable to acquire swfw sync
 Error Resetting the PHY
 e1000: e1000#0: ERROR: Hardware Initialization Failed

 As follows my results:

 unprogrammed i210
01:00.0- 8086:1531 - Network controller
 swfw_sync=0x0, fwmask=0x2, swmask=0x2
 e1000: e1000#0: ERROR: Hardware Initialization Failed

 programmed i210
01:00.0- 8086:157b - Network controller
 swfw_sync=0x0, fwmask=0x2, swmask=0x2
 working

 unprogrammed i211
01:00.0- 8086:1532 - Network controller
 swfw_sync=0x0, fwmask=0x2, swmask=0x2
 working

 programmed i211
01:00.0- 8086:1539 - Network controller
 swfw_sync=0x0, fwmask=0x2, swmask=0x2
 working


Marcel,

What is the configuration of your i210 - is it using an external PHY
or internal?

I noticed in e1000.c SWSM is 0x5B50 which is the same reg your adding
in your patch here. I think at least you should fix that (use the
register definition already created).

It looks like bit0 of SWSM which is set in my case and clear in yours
is used as a flag in the driver in a few places and perhaps has
nothing to do with hardware state. I'll have to add some debugging to
see whats going on.

Tim

 I've always had to ignore the return value from e1000_reset() to avoid
 this issue and use the devices.

 As mentioned before for me only the unprogrammed i210 gives me grief as
 it does not assert the CFG_DONE bit in the EEMNGCTL register upon PHY
 reset. However the e1000_swfw_sync_acquire() always works just fine.

 Any ideas?

 Maybe the flash less aka iNVM only i210 behaves differently.

 Let me enquire Intel about this as well, I anyway need to ask our rep
 about the latest eepromARM programming tool as we have an upcoming
 production lot of a few thousand units arrive any minute now.

 I don't have any i211's but I'll see if I can get hold of an
 unprogrammed i210 to test with.

 Sure, would be interesting to see whether yours behave equally.

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


Re: [U-Boot] [PATCH v3 1/1] fs: fat/ext4/sandbox: Deal with files 2GB

2014-10-27 Thread Suriyan Ramasami
Hello Albert,

On Sun, Oct 26, 2014 at 11:35 PM, Albert ARIBAUD
albert.u.b...@aribaud.net wrote:
 Hello Suriyan,

 On Sun, 26 Oct 2014 21:42:52 -0700, Suriyan Ramasami
 suriya...@gmail.com wrote:

 Subject: [PATCH v3 1/1] fs: fat/ext4/sandbox: Deal with files  2GB

 Could you repost using the full 'negative' word instead of an
 abbreviation? Otherwise people looking for issues by keywords might
 miss this one.


I shall do so in version 4.

Thanks!
- Suriyan

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


[U-Boot] [PATCH v4 1/1] fs: fat/ext4/sandbox: Deal with files greater than 2GB

2014-10-27 Thread Suriyan Ramasami
The commands fatls/ext4ls give negative values when dealing with files
greater than 2GB.
The commands fatsize/ext4size do not update the variable filesize for
these files.

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

Signed-off-by: Suriyan Ramasami suriya...@gmail.com

---
v4:
* Support generic fs write commands
* Sync up behavior of fs load vs fatload and ext4load
* albert - change -ve to negative in commit message

v3:
* Added testcase to test writes
* Correct function set_contents() in fs/fat/fat_write.c

v2:
* Added test case for fat/ext4 in test/fs/testfs.sh
* md5sum: call map_sysmem() for buffer that md5_wd will work on

v1:
* First try.
---
 arch/sandbox/cpu/os.c |  11 +-
 arch/sandbox/cpu/state.c  |   6 +-
 common/board_f.c  |   6 +-
 common/cmd_ext4.c |  61 ++---
 common/cmd_fat.c  |   9 +-
 common/cmd_fs.c   |  17 +++
 common/cmd_md5sum.c   |  12 +-
 common/env_fat.c  |   4 +-
 fs/ext4/ext4_common.c |  24 ++--
 fs/ext4/ext4_common.h |   4 +-
 fs/ext4/ext4_write.c  |  32 +
 fs/ext4/ext4fs.c  |  37 ++---
 fs/fat/fat.c  | 124 +
 fs/fat/fat_write.c|  59 
 fs/fat/file.c |   7 +-
 fs/fs.c   |  77 ++-
 fs/sandbox/sandboxfs.c|  25 ++--
 include/configs/sandbox.h |   2 +
 include/ext4fs.h  |  13 +-
 include/fat.h |  19 +--
 include/fs.h  |   8 +-
 include/os.h  |   2 +-
 include/sandboxfs.h   |   8 +-
 test/fs/testfs.sh | 334 ++
 24 files changed, 655 insertions(+), 246 deletions(-)
 create mode 100755 test/fs/testfs.sh

diff --git a/arch/sandbox/cpu/os.c b/arch/sandbox/cpu/os.c
index 1c4aa3f..43872e8 100644
--- a/arch/sandbox/cpu/os.c
+++ b/arch/sandbox/cpu/os.c
@@ -385,7 +385,7 @@ const char *os_dirent_get_typename(enum os_dirent_t type)
return os_dirent_typename[OS_FILET_UNKNOWN];
 }
 
-ssize_t os_get_filesize(const char *fname)
+int os_get_filesize(const char *fname, loff_t *size)
 {
struct stat buf;
int ret;
@@ -393,7 +393,8 @@ ssize_t os_get_filesize(const char *fname)
ret = stat(fname, buf);
if (ret)
return ret;
-   return buf.st_size;
+   *size = buf.st_size;
+   return 0;
 }
 
 void os_putc(int ch)
@@ -427,10 +428,10 @@ int os_read_ram_buf(const char *fname)
 {
struct sandbox_state *state = state_get_current();
int fd, ret;
-   int size;
+   loff_t size;
 
-   size = os_get_filesize(fname);
-   if (size  0)
+   ret = os_get_filesize(fname, size);
+   if (ret  0)
return -ENOENT;
if (size != state-ram_size)
return -ENOSPC;
diff --git a/arch/sandbox/cpu/state.c b/arch/sandbox/cpu/state.c
index 59adad6..07d2aea 100644
--- a/arch/sandbox/cpu/state.c
+++ b/arch/sandbox/cpu/state.c
@@ -49,12 +49,12 @@ static int state_ensure_space(int extra_size)
 
 static int state_read_file(struct sandbox_state *state, const char *fname)
 {
-   int size;
+   loff_t size;
int ret;
int fd;
 
-   size = os_get_filesize(fname);
-   if (size  0) {
+   ret = os_get_filesize(fname, size);
+   if (ret  0) {
printf(Cannot find sandbox state file '%s'\n, fname);
return -ENOENT;
}
diff --git a/common/board_f.c b/common/board_f.c
index b5bebc9..1fae112 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -285,7 +285,7 @@ static int read_fdt_from_file(void)
struct sandbox_state *state = state_get_current();
const char *fname = state-fdt_fname;
void *blob;
-   ssize_t size;
+   loff_t size;
int err;
int fd;
 
@@ -298,8 +298,8 @@ static int read_fdt_from_file(void)
return -EINVAL;
}
 
-   size = os_get_filesize(fname);
-   if (size  0) {
+   err = os_get_filesize(fname, size);
+   if (err  0) {
printf(Failed to file FDT file '%s'\n, fname);
return -ENOENT;
}
diff --git a/common/cmd_ext4.c b/common/cmd_ext4.c
index ecfc6d3..19423d1 100644
--- a/common/cmd_ext4.c
+++ b/common/cmd_ext4.c
@@ -61,61 +61,16 @@ int do_ext4_ls(cmd_tbl_t *cmdtp, int flag, int argc, char 
*const argv[])
 
 #if defined(CONFIG_CMD_EXT4_WRITE)
 int do_ext4_write(cmd_tbl_t *cmdtp, int flag, int argc,
-   char *const argv[])
+ char *const argv[])
 {
-   const char *filename = /;
-   int dev, part;
-   unsigned long ram_address;
-   unsigned long file_size;
-   disk_partition_t info;
-   block_dev_desc_t *dev_desc;
-
-   if (argc  6)
-   return cmd_usage(cmdtp);
-
-   part = get_device_and_partition(argv[1], 

[U-Boot] [PATCH v3 0/3] reduce warnings with W=1

2014-10-27 Thread Jeroen Hofstee
When compiling u-boot with W=1 there are numerous of warnings.
This patchset attempts to reduce it a bit. One source of false
warnings are the aliases missing a prototype, most of them are
replaced with __weak functions. Others are cause by missing
includes / local functions not be marked as such. At last some
actual missing prototypes are added. These are (hopefully) just
trivial patches, some less than trial is ahead of us.

v3:
  - i2c did contain another alias function, i2c_init_board. This
time the correct patch is squashed with it. Only this patch
resend (1/3).

v2:
  - rebase on master (most of this serie is applied, so remaining
patches are numbered differently.
  - drop PATCH 25/49 spi: make local functions static. Tom posted
a more complete cleanup.
  - Drop common/cmd_elf.c: add missing include (a slightly adjusted
version was applied).
  - split i2c: use __weak (included i2c and l2_cache)
  - redo serial: add prototypes for init functions

Jeroen Hofstee (3):
  i2c: use __weak
  arm926ejs: cache: use __weak
  serial: add prototypes for init functions

 arch/arm/cpu/arm926ejs/cache.c |   5 +-
 drivers/i2c/i2c_core.c |   8 +--
 drivers/serial/serial.c| 140 -
 include/serial.h   |  49 +++
 4 files changed, 122 insertions(+), 80 deletions(-)

-- 
2.1.0

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


[U-Boot] [PATCH v3 1/3] i2c: use __weak

2014-10-27 Thread Jeroen Hofstee
Cc: Heiko Schocher h...@denx.de
Signed-off-by: Jeroen Hofstee jer...@myspectrum.nl
---
 drivers/i2c/i2c_core.c | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/i2c/i2c_core.c b/drivers/i2c/i2c_core.c
index 18d6736..d34b749 100644
--- a/drivers/i2c/i2c_core.c
+++ b/drivers/i2c/i2c_core.c
@@ -229,11 +229,9 @@ static void i2c_init_bus(unsigned int bus_no, int speed, 
int slaveaddr)
 }
 
 /* implement possible board specific board init */
-static void __def_i2c_init_board(void)
+__weak void i2c_init_board(void)
 {
 }
-void i2c_init_board(void)
-   __attribute__((weak, alias(__def_i2c_init_board)));
 
 /*
  * i2c_init_all():
@@ -395,9 +393,7 @@ void i2c_reg_write(uint8_t addr, uint8_t reg, uint8_t val)
i2c_write(addr, reg, 1, val, 1);
 }
 
-void __i2c_init(int speed, int slaveaddr)
+__weak void i2c_init(int speed, int slaveaddr)
 {
i2c_init_bus(i2c_get_bus_num(), speed, slaveaddr);
 }
-void i2c_init(int speed, int slaveaddr)
-   __attribute__((weak, alias(__i2c_init)));
-- 
2.1.0

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


Re: [U-Boot] e1000: add i211 and unprogrammed i210/i211 support

2014-10-27 Thread Tom Rini
On Mon, Sep 08, 2014 at 12:03:50AM +0200, Marcel Ziswiler wrote:

 This patch adds support for i211 as well as unprogrammed aka tools only
 i210/i211 chip support.
 
 Signed-off-by: Marcel Ziswiler mar...@ziswiler.com

Applied to u-boot/master, thanks!

-- 
Tom


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


  1   2   >