Re: [U-Boot] [PATCH 2/2] wandboard: Add Boot Splash image with Wandboard logo

2013-05-28 Thread Wolfgang Denk
Dear Otavio Salvador,

In message cap9odko_uo4bs1xr3c5mjupmiw+t1t+vzvmzrvjkwpr+igz...@mail.gmail.com 
you wrote:

   --- a/tools/Makefile
   +++ b/tools/Makefile
   @@ -146,6 +146,9 @@ endif
ifeq ($(VENDOR),syteco)
LOGO_BMP= logos/syteco.bmp
endif
   +ifeq ($(VENDOR),wandboard)
   +LOGO_BMP= logos/wandboard.bmp
   +endif
 
  This does not scale; it never did, but now we're running out of
  control.  Can we please fix the logo selection? Thanks.
 
 
 I can work on this but how you think we can make it?
 
 Like check for vendor, than board?

No, this doesn't really work, as the wandboard case shows, where there
is no such thing as a vendor name.

Eventually we should/could change LOGO_BMP into CONFIG_LOGO_BMP
and move the setting of the BMP file name to board / vendor specific
locations.  [But this needs to be thought about, too, as it makes
little sense to edit zillions of board config files for that.]

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
Cleverness and Style have no place in getting a project completed.
  -- Tom Christiansen
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [HELP]: sf: winbond: add W25Q32

2013-05-28 Thread Rajeshwari Birje
Hi Jagan,

Yes you are right it has to be 16.
So you want me to and send a patch correcting it?
Or you want me to revert it and send a new patch?

-- 
Regards,
Rajeshwari Shinde
On Mon, May 27, 2013 at 12:30 PM, Jagan Teki jagannadh.t...@gmail.com wrote:
 Hi Rajeshwari,

 On Mon, May 27, 2013 at 11:59 AM, Jagan Teki jagannadh.t...@gmail.com wrote:
 Hi,

 Thanks for your response.

 On Mon, May 27, 2013 at 11:09 AM, Rajeshwari Birje
 rajeshwari.bi...@gmail.com wrote:
 Hi Jagan,

 Hope following reply answer your query.

 On Sat, May 25, 2013 at 2:08 AM, Jagan Teki jagannadh.t...@gmail.com 
 wrote:
 Hi,

 Any update on this, is this a different part w.r.t what I refer for?

 Thanks,
 Jagan.

 On Thu, May 23, 2013 at 2:22 PM, Jagan Teki jagannadh.t...@gmail.com 
 wrote:
 Hi Rajeshwari,

 +   {
 +   .id = 0x5014,

 is this id code is correct? it seems like 0x4014
 When you see the datasheet of W25Q80BW page 16, the table says its 5014h

 +   .nr_blocks  = 128,

 nr_blocks must be 16 i think?
 We use W25Q80BW which is 8MB, hence it is correct as per following 
 calculation;
 flash-size = 4096 * 16 * params-nr_blocks;

 Yes, it is 8M-BIT so the nr_blocks should be 16 to calculate the flash
 size as 1Mbyte.

 --
 Thanks,
 Jagan.


 +   .name   = W25Q80,
 +   },
  };

 Honestly the commit message itself is wrong, i guess.
 Yes this I agree is my fault, but wonder how it went in through all the 
 reviews.

 1. Can you please revert this patch, as commit message not looks good
 me and also some incorrect nr_blocks
 Please mentioned the exact details on commit message body reason
 for reverting
 2. And also send one more patch with a proper details. [exact name,
 nr_blocks .etc]

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


Re: [U-Boot] dfu: dfu and UBI Volumes

2013-05-28 Thread Heiko Schocher
Hello Wolfgang,

Am 28.05.2013 07:58, schrieb Wolfgang Denk:
 Dear Heiko,
 
 In message 51a42ccd.1020...@denx.de you wrote:

 I would imagine, but testing and implementation might show a better way,
 we do UBI as name ubi ubiN volume-name, ie:
 rootfs ubi ubi0 rootfs
 user ubi ubi0 user-data
 and so forth, and augment dfu_nand.c with UBI knowledge, ala dfu_mmc and
 fat/ext knowledge.

 Yes, I think, thats the way to go ...
 
 I doubt that dfu_nand.c is the right place for this.  What if I start
 using DFU on NOR flash?  The decisions which device type (NAND, MMC,
 NOR, USB mass storage, ...) to habdle on one side, and which partition
 type / image type (raw, UBI volume, file, ...) on the other side are
 fully orthogonal to each other.  They should be handled by independent
 code, and not one of them repeated for all implementations of the
 other.

Yes, exactly ...

bye,
Heiko
-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] powerpc/CoreNet: Allow pbl images to take u-boot images != 512K

2013-05-28 Thread Xie Shaohui-B21989
 On 27/05/13 18:18, Xie Shaohui-B21989 wrote:
  Hi, Chris,
 
  For the init value of next_pbl_cmd, there was a patch at below link
 can be used:
  http://lists.denx.de/pipermail/u-boot/2013-March/150260.html
 
 
 Thanks for the pointer. I did check the main u-boot.git tree but didn't
 search the list.
 
 I don't know if it's a concern for u-boot but the patch linked above
 assumes something that isn't quite true for my usage. My board uses the
 SPI booting option for factory boot-strap. The normal method is booting
 from NOR. When I build a NOR image I prepend a standalone application
 image to the bootloader for convenience of only having to program one
 image to NOR. In my case CONFIG_SYS_TEXT_BASE is not the base address of
 the binary I'm trying to wrap in a pbl image.
 
 Another advantage of my version is that you don't necessarily have to be
 using mkimage/pblimage on the current u-boot configuration. It could be
 an externally built image and we're just using mkimage/pblimage to wrap
 it into something that we can program into SPI.
 
[S.H] OK. I see what is your requirement. 
ACK.

Best Regards, 
Shaohui Xie

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


Re: [U-Boot] [HELP]: sf: winbond: add W25Q32

2013-05-28 Thread Jagan Teki
On Tue, May 28, 2013 at 11:38 AM, Rajeshwari Birje
rajeshwari.bi...@gmail.com wrote:
 Hi Jagan,

 Yes you are right it has to be 16.
 So you want me to and send a patch correcting it?
 Or you want me to revert it and send a new patch?

 --
 Regards,
 Rajeshwari Shinde
 On Mon, May 27, 2013 at 12:30 PM, Jagan Teki jagannadh.t...@gmail.com wrote:
 Hi Rajeshwari,

 On Mon, May 27, 2013 at 11:59 AM, Jagan Teki jagannadh.t...@gmail.com 
 wrote:
 Hi,

 Thanks for your response.

 On Mon, May 27, 2013 at 11:09 AM, Rajeshwari Birje
 rajeshwari.bi...@gmail.com wrote:
 Hi Jagan,

 Hope following reply answer your query.

 On Sat, May 25, 2013 at 2:08 AM, Jagan Teki jagannadh.t...@gmail.com 
 wrote:
 Hi,

 Any update on this, is this a different part w.r.t what I refer for?

 Thanks,
 Jagan.

 On Thu, May 23, 2013 at 2:22 PM, Jagan Teki jagannadh.t...@gmail.com 
 wrote:
 Hi Rajeshwari,

 +   {
 +   .id = 0x5014,

 is this id code is correct? it seems like 0x4014
 When you see the datasheet of W25Q80BW page 16, the table says its 5014h

 +   .nr_blocks  = 128,

 nr_blocks must be 16 i think?
 We use W25Q80BW which is 8MB, hence it is correct as per following 
 calculation;
 flash-size = 4096 * 16 * params-nr_blocks;

 Yes, it is 8M-BIT so the nr_blocks should be 16 to calculate the flash
 size as 1Mbyte.

 --
 Thanks,
 Jagan.


 +   .name   = W25Q80,
 +   },
  };

 Honestly the commit message itself is wrong, i guess.
 Yes this I agree is my fault, but wonder how it went in through all the 
 reviews.

 1. Can you please revert this patch, as commit message not looks good
 me and also some incorrect nr_blocks
 Please mentioned the exact details on commit message body reason
 for reverting
 2. And also send one more patch with a proper details. [exact name,
 nr_blocks .etc]

Not required, i sent it already.

http://patchwork.ozlabs.org/patch/246644/

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


Re: [U-Boot] [PATCH 1/2 V2] SF: Add driver for Gigabyte device GD25LQ and GD25Q64B

2013-05-28 Thread Jagan Teki
Any update on this.
Was this patch refereed for denx tree?

Thanks,
Jagan.

On Tue, May 21, 2013 at 6:40 PM, Jagan Teki jagannadh.t...@gmail.com wrote:
 Hi,

 I think this reviewed already, but have a very few comments.

 On Wed, Jan 23, 2013 at 12:00 PM, Rajeshwari Shinde
 rajeshwar...@samsung.com wrote:
 This patch adds driver for the gigabyte devices
 GD25LQ and GD25Q64B required for Snow Board.

 Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com
 ---
 Changes in V2:
 - Added U-Boot copyright header to gigadevice.c
 - Removed unnecessary blank lines.
  drivers/mtd/spi/Makefile |1 +
  drivers/mtd/spi/gigadevice.c |   81 
 ++
  drivers/mtd/spi/spi_flash.c  |3 +
  drivers/mtd/spi/spi_flash_internal.h |1 +
  4 files changed, 86 insertions(+), 0 deletions(-)
  create mode 100644 drivers/mtd/spi/gigadevice.c

 diff --git a/drivers/mtd/spi/Makefile b/drivers/mtd/spi/Makefile
 index 90f8392..ecbb210 100644
 --- a/drivers/mtd/spi/Makefile
 +++ b/drivers/mtd/spi/Makefile
 @@ -32,6 +32,7 @@ endif
  COBJS-$(CONFIG_SPI_FLASH)  += spi_flash.o
  COBJS-$(CONFIG_SPI_FLASH_ATMEL)+= atmel.o
  COBJS-$(CONFIG_SPI_FLASH_EON)  += eon.o
 +COBJS-$(CONFIG_SPI_FLASH_GIGADEVICE)   += gigadevice.o
  COBJS-$(CONFIG_SPI_FLASH_MACRONIX) += macronix.o
  COBJS-$(CONFIG_SPI_FLASH_SPANSION) += spansion.o
  COBJS-$(CONFIG_SPI_FLASH_SST)  += sst.o
 diff --git a/drivers/mtd/spi/gigadevice.c b/drivers/mtd/spi/gigadevice.c
 new file mode 100644
 index 000..b5e1ebe
 --- /dev/null
 +++ b/drivers/mtd/spi/gigadevice.c
 @@ -0,0 +1,81 @@
 +/*
 + * Gigadevice SPI flash driver
 + * Copyright 2013, Samsung Electronics Co., Ltd.
 + * Author: Banajit Goswami banaji...@samsung.com
 + *
 + * See file CREDITS for list of people who contributed to this
 + * project.
 + *
 + * This program is free software; you can redistribute it and/or
 + * modify it under the terms of the GNU General Public License as
 + * published by the Free Software Foundation; either version 2 of
 + * the License, or (at your option) any later version.
 + *
 + * This program is distributed in the hope that it will be useful,
 + * but WITHOUT ANY WARRANTY; without even the implied warranty of
 + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 + * GNU General Public License for more details.
 + *
 + * You should have received a copy of the GNU General Public License
 + * along with this program; if not, write to the Free Software
 + * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
 + * MA 02111-1307 USA
 + */
 +
 +#include common.h
 +#include malloc.h
 +#include spi_flash.h
 +
 +#include spi_flash_internal.h
 +
 +struct gigadevice_spi_flash_params {
 +   uint16_tid;
 +   uint16_tnr_blocks;

 I think it's better to use u16 instead of uint16_t, uin16_t will get
 back to arch include from include/linux which does u16 for directly
 for first time.

 +   const char  *name;
 +};
 +
 +static const struct gigadevice_spi_flash_params 
 gigadevice_spi_flash_table[] = {
 +   {
 +   .id = 0x6016,
 +   .nr_blocks  = 64,
 +   .name   = GD25LQ,
 +   },
 +   {
 +   .id = 0x4017,
 +   .nr_blocks  = 128,
 +   .name   = GD25Q64B,
 +   },

 Better to use clean code shape like..
 {
.id = 0x60,
.nr_blocks = 64,
.name = GD25LQ,
 }

 +};
 +
 +struct spi_flash *spi_flash_probe_gigadevice(struct spi_slave *spi, u8 
 *idcode)
 +{
 +   const struct gigadevice_spi_flash_params *params;
 +   struct spi_flash *flash;
 +   unsigned int i;
 +
 +   for (i = 0; i  ARRAY_SIZE(gigadevice_spi_flash_table); i++) {
 +   params = gigadevice_spi_flash_table[i];
 +   if (params-id == ((idcode[1]  8) | idcode[2]))
 +   break;
 +   }
 +
 +   if (i == ARRAY_SIZE(gigadevice_spi_flash_table)) {
 +   debug(SF: Unsupported Gigadevice ID %02x%02x\n,
 +   idcode[1], idcode[2]);
 +   return NULL;
 +   }
 +
 +   flash = spi_flash_alloc_base(spi, params-name);
 +   if (!flash) {
 +   debug(SF: Failed to allocate memory\n);
 +   return NULL;
 +   }

 better to add a space here

 +   /* page_size */
 +   flash-page_size = 256;
 +   /* sector_size = page_size * pages_per_sector */
 +   flash-sector_size = flash-page_size * 16;
 +   /* size = sector_size * sector_per_block * number of blocks */
 +   flash-size = flash-sector_size * 16 * params-nr_blocks;

 comments on above size calculations are good, but not that much
 important i guess.

 And also please provide a stand'  link for flash part data sheet on
 commit message, if possible.
 I thought it's a good to refers don't 

Re: [U-Boot] [PATCH] drivers:lcd: fix unaligned access on lcd

2013-05-28 Thread Nikita Kiryanov

Hi Piotr,

On 05/27/2013 02:35 PM, Piotr Wilczek wrote:

Dear Wolfgang Denk,


-Original Message-
From: Wolfgang Denk [mailto:w...@denx.de]
Sent: Friday, May 24, 2013 8:33 PM
To: Piotr Wilczek
Cc: u-boot@lists.denx.de; Kyungmin Park
Subject: Re: [U-Boot] [PATCH] drivers:lcd: fix unaligned access on lcd



[...]



My case is a bmp unzipped to a 4-byte aligned address. The two signature bytes 
of the bmp header make the other fields 4-byte unaligned. We could force unzip 
the bmp to an aligned address + 2.

Is this a better solution?


That is the solution we settled on the last time this was discussed.
See CONFIG_SPLASHIMAGE_GUARD in the README file if your use case
involves user input, or just pick an aligned address + 2 in your code.

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


[U-Boot] [PATCH v2 0/6] Optimize ARM relocation

2013-05-28 Thread Albert ARIBAUD
*** NOTE: this series applies over the 'Factorize
ARM relocate_code instances' series.

This series optimizes relocation by ensuring ARM
binaries only use one type of relocation record,
R_ARM_RELATIVE., then optimizing relocation code
accordingly.

1. A Makefile rule is added that checks that no
other relocation record types are generated except
R_ARM_RELATIVE; build fails if this is the case.

2. All references to dymsym are removed, as this
table is not used for R_ARM_RELATIVE relocations.

3. arch/arm/lib/bss.c is replaced by a more generic
arch/arm/lib/sections.c where all section symbols will
be defined.

4. __image_copy_start and __image_copy_end symbols
are moved from linker scripts to arch/arm/lib/sections.c

5. __rel_dyn_start and __rel_dyn_end are moved from
linker scripts into arch/arm/lib/sections.c

6. relocate_code is optimized based on the fact that
symbol references are now always valid even before
relcation, and that only R_ARM_RELATIVE relocations
will be met.

Changes in v2:
- use $ instead of $(obj)u-boot
- new in V2: remove all dynsym references
- various comment fixes

Albert ARIBAUD (6):
  arm: ensure u-boot only uses relative relocations
  remove all references to .dynsym
  arm: generalize lib/bss.c into lib/sections.c
  arm: make __image_copy_{start,end} compiler-generated
  arm: make __rel_dyn_{start,end} compiler-generated
  arm: optimize relocate_code routine

 Makefile   |7 +++
 arch/arm/config.mk |5 ++
 arch/arm/cpu/arm920t/ep93xx/u-boot.lds |6 ++-
 arch/arm/cpu/arm926ejs/mxs/u-boot-spl.lds  |5 --
 arch/arm/cpu/arm926ejs/spear/u-boot-spl.lds|5 --
 arch/arm/cpu/ixp/u-boot.lds|   20 +---
 arch/arm/cpu/u-boot-spl.lds|6 +--
 arch/arm/cpu/u-boot.lds|   21 +---
 arch/arm/lib/Makefile  |2 +-
 arch/arm/lib/relocate.S|   61 ++--
 arch/arm/lib/{bss.c = sections.c} |8 +++-
 board/actux1/u-boot.lds|   20 +---
 board/actux2/u-boot.lds|   20 +---
 board/actux3/u-boot.lds|   20 +---
 board/ait/cam_enc_4xx/u-boot-spl.lds   |5 --
 board/davinci/da8xxevm/u-boot-spl-da850evm.lds |5 --
 board/davinci/da8xxevm/u-boot-spl-hawk.lds |1 -
 board/dvlhost/u-boot.lds   |   20 +---
 board/freescale/mx31ads/u-boot.lds |   20 +---
 board/vpac270/u-boot-spl.lds   |6 +--
 include/asm-generic/sections.h |3 --
 21 files changed, 139 insertions(+), 127 deletions(-)
 rename arch/arm/lib/{bss.c = sections.c} (79%)

-- 
1.7.10.4

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


[U-Boot] [PATCH v2 2/6] remove all references to .dynsym

2013-05-28 Thread Albert ARIBAUD
Discard all .dynsym sections from linker scripts
Remove all __dynsym_start definitions from linker scripts
Remove all __dynsym_start references from the codebase

Note: this touches include/asm-generic/sections.h, which
is not ARM-specific, but actual uses of __dynsym_start
are only in ARM, so this patch can safely go through
the ARM repository.

Signed-off-by: Albert ARIBAUD albert.u.b...@aribaud.net
---
Changes in v2:
- new in V2: remove all dynsym references

 arch/arm/cpu/arm926ejs/mxs/u-boot-spl.lds  |5 -
 arch/arm/cpu/arm926ejs/spear/u-boot-spl.lds|5 -
 arch/arm/cpu/ixp/u-boot.lds|6 +-
 arch/arm/cpu/u-boot-spl.lds|6 +-
 arch/arm/cpu/u-boot.lds|6 +-
 arch/arm/lib/relocate.S|   13 -
 board/actux1/u-boot.lds|6 +-
 board/actux2/u-boot.lds|6 +-
 board/actux3/u-boot.lds|6 +-
 board/ait/cam_enc_4xx/u-boot-spl.lds   |5 -
 board/davinci/da8xxevm/u-boot-spl-da850evm.lds |5 -
 board/davinci/da8xxevm/u-boot-spl-hawk.lds |1 -
 board/dvlhost/u-boot.lds   |6 +-
 board/freescale/mx31ads/u-boot.lds |6 +-
 board/vpac270/u-boot-spl.lds   |6 +-
 include/asm-generic/sections.h |3 ---
 16 files changed, 9 insertions(+), 82 deletions(-)

diff --git a/arch/arm/cpu/arm926ejs/mxs/u-boot-spl.lds 
b/arch/arm/cpu/arm926ejs/mxs/u-boot-spl.lds
index 673c725..f4e7525 100644
--- a/arch/arm/cpu/arm926ejs/mxs/u-boot-spl.lds
+++ b/arch/arm/cpu/arm926ejs/mxs/u-boot-spl.lds
@@ -57,11 +57,6 @@ SECTIONS
__rel_dyn_end = .;
}
 
-   .dynsym : {
-   __dynsym_start = .;
-   *(.dynsym)
-   }
-
.bss : {
. = ALIGN(4);
__bss_start = .;
diff --git a/arch/arm/cpu/arm926ejs/spear/u-boot-spl.lds 
b/arch/arm/cpu/arm926ejs/spear/u-boot-spl.lds
index 967a135..446d095 100644
--- a/arch/arm/cpu/arm926ejs/spear/u-boot-spl.lds
+++ b/arch/arm/cpu/arm926ejs/spear/u-boot-spl.lds
@@ -57,11 +57,6 @@ SECTIONS
__rel_dyn_end = .;
}
 
-   .dynsym : {
-   __dynsym_start = .;
-   *(.dynsym)
-   }
-
.bss : {
. = ALIGN(4);
__bss_start = .;
diff --git a/arch/arm/cpu/ixp/u-boot.lds b/arch/arm/cpu/ixp/u-boot.lds
index 553589c..5cfff68 100644
--- a/arch/arm/cpu/ixp/u-boot.lds
+++ b/arch/arm/cpu/ixp/u-boot.lds
@@ -62,11 +62,6 @@ SECTIONS
__rel_dyn_end = .;
}
 
-   .dynsym : {
-   __dynsym_start = .;
-   *(.dynsym)
-   }
-
_end = .;
 
 /*
@@ -88,6 +83,7 @@ SECTIONS
KEEP(*(.__bss_end));
}
 
+   /DISCARD/ : { *(.dynsym) }
/DISCARD/ : { *(.dynstr*) }
/DISCARD/ : { *(.dynamic*) }
/DISCARD/ : { *(.plt*) }
diff --git a/arch/arm/cpu/u-boot-spl.lds b/arch/arm/cpu/u-boot-spl.lds
index 1408f03..b6ed25f 100644
--- a/arch/arm/cpu/u-boot-spl.lds
+++ b/arch/arm/cpu/u-boot-spl.lds
@@ -58,11 +58,6 @@ SECTIONS
__rel_dyn_end = .;
}
 
-   .dynsym : {
-   __dynsym_start = .;
-   *(.dynsym)
-   }
-
_end = .;
 
.bss __rel_dyn_start (OVERLAY) : {
@@ -72,6 +67,7 @@ SECTIONS
__bss_end = .;
}
 
+   /DISCARD/ : { *(.dynsym) }
/DISCARD/ : { *(.dynstr*) }
/DISCARD/ : { *(.dynamic*) }
/DISCARD/ : { *(.plt*) }
diff --git a/arch/arm/cpu/u-boot.lds b/arch/arm/cpu/u-boot.lds
index d9bbee3..fe2ca98 100644
--- a/arch/arm/cpu/u-boot.lds
+++ b/arch/arm/cpu/u-boot.lds
@@ -65,11 +65,6 @@ SECTIONS
__rel_dyn_end = .;
}
 
-   .dynsym : {
-   __dynsym_start = .;
-   *(.dynsym)
-   }
-
_end = .;
 
/*
@@ -101,6 +96,7 @@ SECTIONS
KEEP(*(.__bss_end));
}
 
+   /DISCARD/ : { *(.dynsym) }
/DISCARD/ : { *(.dynstr*) }
/DISCARD/ : { *(.dynamic*) }
/DISCARD/ : { *(.plt*) }
diff --git a/arch/arm/lib/relocate.S b/arch/arm/lib/relocate.S
index 4446da9..7a7c4c0 100644
--- a/arch/arm/lib/relocate.S
+++ b/arch/arm/lib/relocate.S
@@ -56,8 +56,6 @@ copy_loop:
/*
 * fix .rel.dyn relocations
 */
-   ldr r10, _dynsym_start_ofs  /* r10 - __dynsym_start local ofs */
-   add r10, r10, r7/* r10 - SRC __dynsym_start */
ldr r2, _rel_dyn_start_ofs  /* r2 - __rel_dyn_start local ofs */
add r2, r2, r7  /* r2 - SRC __rel_dyn_start */
ldr r3, _rel_dyn_end_ofs/* r3 - __rel_dyn_end local ofs */
@@ -69,17 +67,8 @@ fixloop:
and r7, r1, #0xff
cmp r7, #23 /* relative fixup? */
beq fixrel
-   cmp 

[U-Boot] [PATCH v2 1/6] arm: ensure u-boot only uses relative relocations

2013-05-28 Thread Albert ARIBAUD
Add a Makefile target ('checkarmreloc') which
fails of the ELF binary contains relocation records
of types other than R_ARM_RELATIVE.

Signed-off-by: Albert ARIBAUD albert.u.b...@aribaud.net
---
Changes in v2:
- use $ instead of $(obj)u-boot

 Makefile   |7 +++
 arch/arm/config.mk |5 +
 2 files changed, 12 insertions(+)

diff --git a/Makefile b/Makefile
index c52f0f1..70b5183 100644
--- a/Makefile
+++ b/Makefile
@@ -746,6 +746,13 @@ tools: $(VERSION_FILE) $(TIMESTAMP_FILE)
$(MAKE) -C $@ all
 endif  # config.mk
 
+# ARM relocations should all be R_ARM_RELATIVE.
+checkarmreloc: $(obj)u-boot
+   @if test R_ARM_RELATIVE != \
+   `readelf -r $ | cut -d ' ' -f 4 | grep R_ARM | sort -u`; \
+   then echo $ contains relocations other than \
+   R_ARM_RELATIVE; false; fi
+
 $(VERSION_FILE):
@mkdir -p $(dir $(VERSION_FILE))
@( localvers='$(shell $(TOPDIR)/tools/setlocalversion 
$(TOPDIR))' ; \
diff --git a/arch/arm/config.mk b/arch/arm/config.mk
index dc64160..e80e1ed 100644
--- a/arch/arm/config.mk
+++ b/arch/arm/config.mk
@@ -109,3 +109,8 @@ ifeq ($(GAS_BUG_12532),y)
 PLATFORM_RELFLAGS += -fno-optimize-sibling-calls
 endif
 endif
+
+# check that only R_ARM_RELATIVE relocations are generated
+ifneq ($(CONFIG_SPL_BUILD),y)
+ALL-y  += checkarmreloc
+endif
-- 
1.7.10.4

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


[U-Boot] [PATCH v2 4/6] arm: make __image_copy_{start, end} compiler-generated

2013-05-28 Thread Albert ARIBAUD
This change is only done where needed: some linker
scripts may contain __image_copy_{start,end} yet
remain unchanged.

Also, __image_copy_end needs its own section; putting
it in relocation sections changes their flags and makes
relocation breaks.

Signed-off-by: Albert ARIBAUD albert.u.b...@aribaud.net
---
Changes in v2: None

 arch/arm/cpu/arm920t/ep93xx/u-boot.lds |6 +-
 arch/arm/cpu/ixp/u-boot.lds|6 +-
 arch/arm/cpu/u-boot.lds|7 +--
 arch/arm/lib/relocate.S|7 ++-
 arch/arm/lib/sections.c|2 ++
 board/actux1/u-boot.lds|6 +-
 board/actux2/u-boot.lds|6 +-
 board/actux3/u-boot.lds|6 +-
 board/dvlhost/u-boot.lds   |6 +-
 board/freescale/mx31ads/u-boot.lds |6 +-
 10 files changed, 44 insertions(+), 14 deletions(-)

diff --git a/arch/arm/cpu/arm920t/ep93xx/u-boot.lds 
b/arch/arm/cpu/arm920t/ep93xx/u-boot.lds
index cf55bf7..367c805 100644
--- a/arch/arm/cpu/arm920t/ep93xx/u-boot.lds
+++ b/arch/arm/cpu/arm920t/ep93xx/u-boot.lds
@@ -31,6 +31,7 @@ SECTIONS
. = ALIGN(4);
.text  :
{
+   *(.__image_copy_start)
  arch/arm/cpu/arm920t/start.o  (.text*)
/* the EP93xx expects to find the pattern 'CRUS' at 0x1000 */
  . = 0x1000;
@@ -56,7 +57,10 @@ SECTIONS
 
. = ALIGN(4);
 
-   __image_copy_end = .;
+   .image_copy_end :
+   {
+   *(.__image_copy_end)
+   }
 
__bss_start = .;
.bss : { *(.bss*) }
diff --git a/arch/arm/cpu/ixp/u-boot.lds b/arch/arm/cpu/ixp/u-boot.lds
index 5cfff68..9141199 100644
--- a/arch/arm/cpu/ixp/u-boot.lds
+++ b/arch/arm/cpu/ixp/u-boot.lds
@@ -31,6 +31,7 @@ SECTIONS
. = ALIGN(4);
.text :
{
+   *(.__image_copy_start)
arch/arm/cpu/ixp/start.o(.text*)
*(.text*)
}
@@ -54,7 +55,10 @@ SECTIONS
 
. = ALIGN(4);
 
-   __image_copy_end = .;
+   .image_copy_end :
+   {
+   *(.__image_copy_end)
+   }
 
.rel.dyn : {
__rel_dyn_start = .;
diff --git a/arch/arm/cpu/u-boot.lds b/arch/arm/cpu/u-boot.lds
index fe2ca98..d7adf90 100644
--- a/arch/arm/cpu/u-boot.lds
+++ b/arch/arm/cpu/u-boot.lds
@@ -33,7 +33,7 @@ SECTIONS
. = ALIGN(4);
.text :
{
-   __image_copy_start = .;
+   *(.__image_copy_start)
CPUDIR/start.o (.text*)
*(.text*)
}
@@ -57,7 +57,10 @@ SECTIONS
 
. = ALIGN(4);
 
-   __image_copy_end = .;
+   .image_copy_end :
+   {
+   *(.__image_copy_end)
+   }
 
.rel.dyn : {
__rel_dyn_start = .;
diff --git a/arch/arm/lib/relocate.S b/arch/arm/lib/relocate.S
index 7a7c4c0..3767a95 100644
--- a/arch/arm/lib/relocate.S
+++ b/arch/arm/lib/relocate.S
@@ -39,13 +39,12 @@
 ENTRY(relocate_code)
mov r6, r0  /* save addr of destination */
 
-   ldr r0, =_start /* r0 - SRC _start */
+   ldr r0, =__image_copy_start /* r0 - SRC __image_copy_start */
subsr9, r6, r0  /* r9 - relocation offset */
beq relocate_done   /* skip relocation */
mov r1, r6  /* r1 - scratch for copy loop */
adr r7, relocate_code   /* r7 - SRC relocate_code */
-   ldr r3, _image_copy_end_ofs /* r3 - __image_copy_end local ofs */
-   add r2, r7, r3  /* r2 - SRC __image_copy_end */
+   ldr r2, =__image_copy_end   /* r2 - SRC __image_copy_end */
 
 copy_loop:
ldmia   r0!, {r10-r11}  /* copy from source address [r0]*/
@@ -89,8 +88,6 @@ relocate_done:
 bxlr
 #endif
 
-_image_copy_end_ofs:
-   .word __image_copy_end - relocate_code
 _rel_dyn_start_ofs:
.word __rel_dyn_start - relocate_code
 _rel_dyn_end_ofs:
diff --git a/arch/arm/lib/sections.c b/arch/arm/lib/sections.c
index e52fec9..03e846f 100644
--- a/arch/arm/lib/sections.c
+++ b/arch/arm/lib/sections.c
@@ -37,3 +37,5 @@
 
 char __bss_start[0] __attribute__((section(.__bss_start)));
 char __bss_end[0] __attribute__((section(.__bss_end)));
+char __image_copy_start[0] __attribute__((section(.__image_copy_start)));
+char __image_copy_end[0] __attribute__((section(.__image_copy_end)));
diff --git a/board/actux1/u-boot.lds b/board/actux1/u-boot.lds
index 989ad71..531e598 100644
--- a/board/actux1/u-boot.lds
+++ b/board/actux1/u-boot.lds
@@ -30,6 +30,7 @@ SECTIONS
 
. = ALIGN (4);
.text : {
+   *(.__image_copy_start)
arch/arm/cpu/ixp/start.o(.text*)
net/libnet.o(.text*)
board/actux1/libactux1.o(.text*)
@@ -62,7 +63,10 @@ SECTIONS
 
. = ALIGN (4);
 
-   __image_copy_end = .;
+   .image_copy_end :
+   {
+   

[U-Boot] [PATCH v2 5/6] arm: make __rel_dyn_{start, end} compiler-generated

2013-05-28 Thread Albert ARIBAUD
This change is only done where needed: some linker
scripts may contain relocation symbols yet remain
unchanged.

__rel_dyn_start and __rel_dyn_end each requires
its own output section; putting them in relocation
sections changes their flags and breaks relocation.

Signed-off-by: Albert ARIBAUD albert.u.b...@aribaud.net
---
Changes in v2:
- various comment fixes

 arch/arm/cpu/ixp/u-boot.lds|   12 ++--
 arch/arm/cpu/u-boot.lds|   12 ++--
 arch/arm/lib/relocate.S|   11 ++-
 arch/arm/lib/sections.c|2 ++
 board/actux1/u-boot.lds|   12 ++--
 board/actux2/u-boot.lds|   12 ++--
 board/actux3/u-boot.lds|   12 ++--
 board/dvlhost/u-boot.lds   |   12 ++--
 board/freescale/mx31ads/u-boot.lds |   12 ++--
 9 files changed, 74 insertions(+), 23 deletions(-)

diff --git a/arch/arm/cpu/ixp/u-boot.lds b/arch/arm/cpu/ixp/u-boot.lds
index 9141199..54bafda 100644
--- a/arch/arm/cpu/ixp/u-boot.lds
+++ b/arch/arm/cpu/ixp/u-boot.lds
@@ -60,10 +60,18 @@ SECTIONS
*(.__image_copy_end)
}
 
+   .rel_dyn_start :
+   {
+   *(.__rel_dyn_start)
+   }
+
.rel.dyn : {
-   __rel_dyn_start = .;
*(.rel*)
-   __rel_dyn_end = .;
+   }
+
+   .rel_dyn_end :
+   {
+   *(.__rel_dyn_end)
}
 
_end = .;
diff --git a/arch/arm/cpu/u-boot.lds b/arch/arm/cpu/u-boot.lds
index d7adf90..3037885 100644
--- a/arch/arm/cpu/u-boot.lds
+++ b/arch/arm/cpu/u-boot.lds
@@ -62,10 +62,18 @@ SECTIONS
*(.__image_copy_end)
}
 
+   .rel_dyn_start :
+   {
+   *(.__rel_dyn_start)
+   }
+
.rel.dyn : {
-   __rel_dyn_start = .;
*(.rel*)
-   __rel_dyn_end = .;
+   }
+
+   .rel_dyn_end :
+   {
+   *(.__rel_dyn_end)
}
 
_end = .;
diff --git a/arch/arm/lib/relocate.S b/arch/arm/lib/relocate.S
index 3767a95..3f444c1 100644
--- a/arch/arm/lib/relocate.S
+++ b/arch/arm/lib/relocate.S
@@ -55,10 +55,8 @@ copy_loop:
/*
 * fix .rel.dyn relocations
 */
-   ldr r2, _rel_dyn_start_ofs  /* r2 - __rel_dyn_start local ofs */
-   add r2, r2, r7  /* r2 - SRC __rel_dyn_start */
-   ldr r3, _rel_dyn_end_ofs/* r3 - __rel_dyn_end local ofs */
-   add r3, r3, r7  /* r3 - SRC __rel_dyn_end */
+   ldr r2, =__rel_dyn_start/* r2 - SRC __rel_dyn_start */
+   ldr r3, =__rel_dyn_end  /* r3 - SRC __rel_dyn_end */
 fixloop:
ldr r0, [r2]/* r0 - SRC location to fix up */
add r0, r0, r9  /* r0 - DST location to fix up */
@@ -88,9 +86,4 @@ relocate_done:
 bxlr
 #endif
 
-_rel_dyn_start_ofs:
-   .word __rel_dyn_start - relocate_code
-_rel_dyn_end_ofs:
-   .word __rel_dyn_end - relocate_code
-
 ENDPROC(relocate_code)
diff --git a/arch/arm/lib/sections.c b/arch/arm/lib/sections.c
index 03e846f..5921dd8 100644
--- a/arch/arm/lib/sections.c
+++ b/arch/arm/lib/sections.c
@@ -39,3 +39,5 @@ char __bss_start[0] __attribute__((section(.__bss_start)));
 char __bss_end[0] __attribute__((section(.__bss_end)));
 char __image_copy_start[0] __attribute__((section(.__image_copy_start)));
 char __image_copy_end[0] __attribute__((section(.__image_copy_end)));
+char __rel_dyn_start[0] __attribute__((section(.__rel_dyn_start)));
+char __rel_dyn_end[0] __attribute__((section(.__rel_dyn_end)));
diff --git a/board/actux1/u-boot.lds b/board/actux1/u-boot.lds
index 531e598..74aec5f 100644
--- a/board/actux1/u-boot.lds
+++ b/board/actux1/u-boot.lds
@@ -68,10 +68,18 @@ SECTIONS
*(.__image_copy_end)
}
 
+   .rel_dyn_start :
+   {
+   *(.__rel_dyn_start)
+   }
+
.rel.dyn : {
-   __rel_dyn_start = .;
*(.rel*)
-   __rel_dyn_end = .;
+   }
+
+   .rel_dyn_end :
+   {
+   *(.__rel_dyn_end)
}
 
_end = .;
diff --git a/board/actux2/u-boot.lds b/board/actux2/u-boot.lds
index aff773c..c276501 100644
--- a/board/actux2/u-boot.lds
+++ b/board/actux2/u-boot.lds
@@ -68,10 +68,18 @@ SECTIONS
*(.__image_copy_end)
}
 
+   .rel_dyn_start :
+   {
+   *(.__rel_dyn_start)
+   }
+
.rel.dyn : {
-   __rel_dyn_start = .;
*(.rel*)
-   __rel_dyn_end = .;
+   }
+
+   .rel_dyn_end :
+   {
+   *(.__rel_dyn_end)
}
 
_end = .;
diff --git a/board/actux3/u-boot.lds b/board/actux3/u-boot.lds
index 9d43e95..5610644 100644
--- a/board/actux3/u-boot.lds
+++ b/board/actux3/u-boot.lds
@@ -68,10 +68,18 @@ SECTIONS
*(.__image_copy_end)
}
 
+   .rel_dyn_start :
+   {
+   

[U-Boot] [PATCH v2 3/6] arm: generalize lib/bss.c into lib/sections.c

2013-05-28 Thread Albert ARIBAUD
File arch/arm/lib/bss.c was initially defined for BSS only,
but is now going to also contain definitions for other
section-boundary-related symbols, so rename it for better
accuracy.

Also, remove useless 'used' attributes.

Signed-off-by: Albert ARIBAUD albert.u.b...@aribaud.net
---
Changes in v2: None

 arch/arm/lib/Makefile  |2 +-
 arch/arm/lib/{bss.c = sections.c} |4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)
 rename arch/arm/lib/{bss.c = sections.c} (92%)

diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile
index 30e3290..dbad5c1 100644
--- a/arch/arm/lib/Makefile
+++ b/arch/arm/lib/Makefile
@@ -43,7 +43,7 @@ SOBJS-y += relocate.o
 ifndef CONFIG_SYS_GENERIC_BOARD
 COBJS-y+= board.o
 endif
-COBJS-y += bss.o
+COBJS-y += sections.o
 
 COBJS-y+= bootm.o
 COBJS-$(CONFIG_SYS_L2_PL310) += cache-pl310.o
diff --git a/arch/arm/lib/bss.c b/arch/arm/lib/sections.c
similarity index 92%
rename from arch/arm/lib/bss.c
rename to arch/arm/lib/sections.c
index 99eda59..e52fec9 100644
--- a/arch/arm/lib/bss.c
+++ b/arch/arm/lib/sections.c
@@ -35,5 +35,5 @@
  * aliasing warnings.
  */
 
-char __bss_start[0] __attribute__((used, section(.__bss_start)));
-char __bss_end[0] __attribute__((used, section(.__bss_end)));
+char __bss_start[0] __attribute__((section(.__bss_start)));
+char __bss_end[0] __attribute__((section(.__bss_end)));
-- 
1.7.10.4

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


[U-Boot] [PATCH v2 6/6] arm: optimize relocate_code routine

2013-05-28 Thread Albert ARIBAUD
Use section symbols directly
Drop support for R_ARM_ABS32 record types
Eliminate unneeded intermediate registers
Optimize relocation table iteration

Signed-off-by: Albert ARIBAUD albert.u.b...@aribaud.net
---
Changes in v2: None

 arch/arm/lib/relocate.S |   32 
 1 file changed, 12 insertions(+), 20 deletions(-)

diff --git a/arch/arm/lib/relocate.S b/arch/arm/lib/relocate.S
index 3f444c1..949b9e8 100644
--- a/arch/arm/lib/relocate.S
+++ b/arch/arm/lib/relocate.S
@@ -37,19 +37,15 @@
  */
 
 ENTRY(relocate_code)
-   mov r6, r0  /* save addr of destination */
-
-   ldr r0, =__image_copy_start /* r0 - SRC __image_copy_start */
-   subsr9, r6, r0  /* r9 - relocation offset */
+   ldr r1, =__image_copy_start /* r1 - SRC __image_copy_start */
+   subsr9, r0, r1  /* r9 - relocation offset */
beq relocate_done   /* skip relocation */
-   mov r1, r6  /* r1 - scratch for copy loop */
-   adr r7, relocate_code   /* r7 - SRC relocate_code */
ldr r2, =__image_copy_end   /* r2 - SRC __image_copy_end */
 
 copy_loop:
-   ldmia   r0!, {r10-r11}  /* copy from source address [r0]*/
-   stmia   r1!, {r10-r11}  /* copy to   target address [r1]*/
-   cmp r0, r2  /* until source end address [r2]*/
+   ldmia   r1!, {r10-r11}  /* copy from source address [r1]*/
+   stmia   r0!, {r10-r11}  /* copy to   target address [r0]*/
+   cmp r1, r2  /* until source end address [r2]*/
blo copy_loop
 
/*
@@ -58,21 +54,17 @@ copy_loop:
ldr r2, =__rel_dyn_start/* r2 - SRC __rel_dyn_start */
ldr r3, =__rel_dyn_end  /* r3 - SRC __rel_dyn_end */
 fixloop:
-   ldr r0, [r2]/* r0 - SRC location to fix up */
-   add r0, r0, r9  /* r0 - DST location to fix up */
-   ldr r1, [r2, #4]
-   and r7, r1, #0xff
-   cmp r7, #23 /* relative fixup? */
-   beq fixrel
-   /* ignore unknown type of fixup */
-   b   fixnext
-fixrel:
+   ldmia   r2!, {r0-r1}/* (r0,r1) - (SRC location,fixup) */
+   and r1, r1, #0xff
+   cmp r1, #23 /* relative fixup? */
+   bne fixnext
+
/* relative fix: increase location by offset */
+   add r0, r0, r9
ldr r1, [r0]
add r1, r1, r9
-fixnext:
str r1, [r0]
-   add r2, r2, #8  /* each rel.dyn entry is 8 bytes */
+fixnext:
cmp r2, r3
blo fixloop
 
-- 
1.7.10.4

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


Re: [U-Boot] [PATCH v3 1/2] build: Use generic boot logo matching

2013-05-28 Thread Wolfgang Denk
Dear Otavio Salvador,

In message 1369693124-26106-1-git-send-email-ota...@ossystems.com.br you 
wrote:
 The boot logo matching is now done in following way:
 
  - use LOGO_BMP if it is set, or
  - use $(BOARD).bmp if it exists in tools/logos, or
  - use $(VENDOR).bmp if it exists in tools/logos, or
  - use denx.bmp otherwise.
 
 Signed-off-by: Otavio Salvador ota...@ossystems.com.br
 ---
 Changes in v3:
 - New patch, which replaces the 1/2 from v1 and v2

Looks good to me, at least it solves the immediate issues.

Thanks!

Acked-by: Wolfgang Denk w...@denx.de

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'm not a god, I was misquoted. - Lister, Red Dwarf
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] SF: Add Spansion S25FL064P IDs

2013-05-28 Thread Jagan Teki

On 28-08-2012 20:43, Marek Vasut wrote:

This is a S25FL064A successor. It supports up to 104MHz bus
speed.

Signed-off-by: Marek Vasut ma...@denx.de
Cc: Heiko Schocher h...@denx.de
Cc: Mike Frysinger vap...@gentoo.org
Cc: Scott Wood scottw...@freescale.com
Cc: Wolfgang Denk w...@denx.de

---
drivers/mtd/spi/spansion.c |7 +++
  1 file changed, 7 insertions(+)

diff --git a/drivers/mtd/spi/spansion.c b/drivers/mtd/spi/spansion.c
index 9a114ac..faf4414 100644
--- a/drivers/mtd/spi/spansion.c
+++ b/drivers/mtd/spi/spansion.c
@@ -90,6 +90,13 @@ static const struct spansion_spi_flash_params 
spansion_spi_flash_table[] = {
.name = S25FL032P,
},
{
+   .idcode1 = 0x0216,
+   .idcode2 = 0x4d00,
+   .pages_per_sector = 256,
+   .nr_sectors = 128,
+   .name = S25FL064P,
+   },
+   {
.idcode1 = 0x2018,
.idcode2 = 0x4d01,
.pages_per_sector = 256,

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] Wandboard: Add support for Wandboard quad

2013-05-28 Thread Tapani Utriainen
On Mon, 27 May 2013 13:56:30 -0300
Otavio Salvador ota...@ossystems.com.br wrote:

 I have sent two patches for adding the Boot Splash with Wandboard logo.
 Please take a look on them and if you agree please base on this to avoid
 conflicts.
 
 (For easyness: http://patchwork.ozlabs.org/bundle/otavio/wandboard-20130527/
 )
 

Otavio,

while I do agree with the work you are doing (HDMI bootlogo into mainline),
and would not have minded to base my patches on top of yours.
However, the patches you sent seem to have been NAK:ed. The v3 does not apply 
on top of 2013.04 (maybe I am basing on the wrong release!?).

So for now, I am basing the resubmission on the 2013.04 release.

regards,

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


Re: [U-Boot] [PATCH] Wandboard: Add support for Wandboard quad

2013-05-28 Thread Tapani Utriainen
On Mon, 27 May 2013 07:22:42 -0300
Fabio Estevam feste...@gmail.com wrote:

 Hi Tapani,
 
 On Mon, May 27, 2013 at 1:13 AM, Tapani Utriainen tap...@technexion.com 
 wrote:
 
  Add support for the Wandboard quad.
 
  Signed-off-by: Tapani Utriainen tap...@technexion.com
 
  ---
   boards.cfg  | 1 +
   include/configs/wandboard.h | 2 ++
   2 files changed, 3 insertions(+)
 
 It looks good.
 
 Could you also add an entry for the quad version into the README file?
 
 Regards,
 
 Fabio Estevam

Fabio,

thank you, will do (resubmitting a v2). 

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


Re: [U-Boot] [U-Boot, v2] sf: winbond: Add support for W25PXX SPI flash

2013-05-28 Thread Jagan Teki

On 23-05-2013 20:39, Kuo-Jung Su wrote:

From: Kuo-Jung Su dant...@faraday-tech.com

Add support for Winbond's W25PXX SPI flash.
These devices is used on Faraday A369 evaluation board.

Signed-off-by: Kuo-Jung Su dant...@faraday-tech.com
CC: Jagan Teki jagannadh.t...@gmail.com
CC: Tom Rini tr...@ti.com

---
Changes for v2:
- Update commit message header
- Add commit message body

  drivers/mtd/spi/winbond.c |   17 -
  1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/drivers/mtd/spi/winbond.c b/drivers/mtd/spi/winbond.c
index 2716209..2a27837 100644
--- a/drivers/mtd/spi/winbond.c
+++ b/drivers/mtd/spi/winbond.c
@@ -18,6 +18,21 @@ struct winbond_spi_flash_params {
  
  static const struct winbond_spi_flash_params winbond_spi_flash_table[] = {

{
+   .id = 0x2014,
+   .nr_blocks  = 16,
+   .name   = W25P80,
+   },
+   {
+   .id = 0x2015,
+   .nr_blocks  = 32,
+   .name   = W25P16,
+   },
+   {
+   .id = 0x2016,
+   .nr_blocks  = 64,
+   .name   = W25P32,
+   },
+   {
.id = 0x3013,
.nr_blocks  = 8,
.name   = W25X40,
@@ -104,7 +119,7 @@ struct spi_flash *spi_flash_probe_winbond(struct spi_slave 
*spi, u8 *idcode)
}
  
  	flash-page_size = 256;

-   flash-sector_size = 4096;
+   flash-sector_size = (idcode[1] == 0x20) ? 65536 : 4096;
flash-size = 4096 * 16 * params-nr_blocks;
  
  	return flash;

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] [U-Boot,4/4] sf: winbond: Add support for W25Q256

2013-05-28 Thread Jagan Teki

On 23-02-2013 07:09, Jagannadha Sutradharudu Teki wrote:

Add support for Winbond W25Q256 SPI flash.

Signed-off-by: Jagannadha Sutradharudu Teki jaga...@xilinx.com

---
drivers/mtd/spi/winbond.c |5 +
  1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/drivers/mtd/spi/winbond.c b/drivers/mtd/spi/winbond.c
index 4418302..ceec0cb 100644
--- a/drivers/mtd/spi/winbond.c
+++ b/drivers/mtd/spi/winbond.c
@@ -63,6 +63,11 @@ static const struct winbond_spi_flash_params 
winbond_spi_flash_table[] = {
.name   = W25Q128,
},
{
+   .id = 0x4019,
+   .nr_blocks  = 512,
+   .name   = W25Q256,
+   },
+   {
.id = 0x5014,
.nr_blocks  = 128,
.name   = W25Q80,

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 06/10] powerpc/ppc4xx: Use generic FPGA accessors on all gdsys 405ep/ex boards

2013-05-28 Thread Dirk Eibach
Hello Wolfgang,

would you please have a look at this? I need some feedback to get this
finally sorted.

Cheers
Dirk

2013/5/15 Dirk Eibach dirk.eib...@gdsys.cc:
 Hello Wolfgang,

 sorry for the delay, I had to clean some other things on my ToDoList.

 I cleaned up my patchseries and wanted to start implementing your proposal.
 And ran into a problem. Remember, the basic reason for the the generic FPGA
 accessors was, that we have a certain amount of basically identical FPGAs
 which are only connected to the CPU in different ways. The drivers accessing
 those FPGAs should be agnostic of that and simply be able to access those
 FPGAs by index.


 It appears you need both the element address and the offset in your
 fpga_set_reg() code, so you should pass this information, like that
 [note that we no longer need an array of addresses]:

 struct ihs_fpga fpga_ptr = (struct ihs_fpga *)CONFIG_SYS_FPGA_BASE;
 ...

 void fpga_set_reg(u32 fpga, u16 *reg, off_t regoff, u16 data)
 {
 if (fpga)
 return mclink_send(fpga - 1, regoff, data);

 return out_le16(reg, data);
 }

 where mclink_send() is the routine to access the non memory mapped
 FPGAs through the memory mapped FPGA:
int mclink_send(u8 slave, u16 addr, u16 data)
{
 ...
 fpga_set_reg(0, system_fpgas[0].mc_tx_address, addr);
 fpga_set_reg(0, system_fpgas[0].mc_tx_data, data);
 fpga_set_reg(0, system_fpgas[0].mc_tx_cmd, (slave  0x03) 
 14);
}


 And this becomes:

 fpga_set_reg(0,
  fpga_ptr-mc_tx_address,
  offsetof(struct ihs_fpga, mc_tx_address),
  addr);

 etc. Yes, this is long and ugly to write, so you may want to define a
 helper macro like:

 #define FPGA_SET_REG(ix,fld,val)\
 fpga_set_reg((ix),  \
 fpga_ptr-fld, \
 offsetof(struct ihs_fpga, fld), \
 val)

 so this turns into a plain and simple

 FPGA_SET_REG(0, mc_tx_address, addr);
 FPGA_SET_REG(0, mc_tx_data, data);
 FPGA_SET_REG(0, mc_tx_cmd, (slave  0x03)  14);


 This works nicely for our memory mapped FPGA. But how about the other FPGAs?
 I don't have a fpga_ptr for them. Setting it NULL would make FPGA_SET_REG
 dereference a NULL pointer.
 Certainly I might call
 fpga_set_reg(1,
  NULL,
  offsetof(struct ihs_fpga, mc_tx_address),
  addr);
 but that would not be generic any more.

 Do you have any idea how to solve this?


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


Re: [U-Boot] [PATCH v2 06/10] powerpc/ppc4xx: Use generic FPGA accessors on all gdsys 405ep/ex boards

2013-05-28 Thread Dirk Eibach
Hello Wolfgang,

would you please have a look at this? I need some feedback to get this
finally sorted.

Cheers
Dirk

2013/5/15 Dirk Eibach dirk.eib...@gdsys.cc:
 Hello Wolfgang,

 sorry for the delay, I had to clean some other things on my ToDoList.

 I cleaned up my patchseries and wanted to start implementing your proposal.
 And ran into a problem. Remember, the basic reason for the the generic FPGA
 accessors was, that we have a certain amount of basically identical FPGAs
 which are only connected to the CPU in different ways. The drivers accessing
 those FPGAs should be agnostic of that and simply be able to access those
 FPGAs by index.


 It appears you need both the element address and the offset in your
 fpga_set_reg() code, so you should pass this information, like that
 [note that we no longer need an array of addresses]:

 struct ihs_fpga fpga_ptr = (struct ihs_fpga *)CONFIG_SYS_FPGA_BASE;
 ...

 void fpga_set_reg(u32 fpga, u16 *reg, off_t regoff, u16 data)
 {
 if (fpga)
 return mclink_send(fpga - 1, regoff, data);

 return out_le16(reg, data);
 }

 where mclink_send() is the routine to access the non memory mapped
 FPGAs through the memory mapped FPGA:
int mclink_send(u8 slave, u16 addr, u16 data)
{
 ...
 fpga_set_reg(0, system_fpgas[0].mc_tx_address, addr);
 fpga_set_reg(0, system_fpgas[0].mc_tx_data, data);
 fpga_set_reg(0, system_fpgas[0].mc_tx_cmd, (slave  0x03) 
 14);
}


 And this becomes:

 fpga_set_reg(0,
  fpga_ptr-mc_tx_address,
  offsetof(struct ihs_fpga, mc_tx_address),
  addr);

 etc. Yes, this is long and ugly to write, so you may want to define a
 helper macro like:

 #define FPGA_SET_REG(ix,fld,val)\
 fpga_set_reg((ix),  \
 fpga_ptr-fld, \
 offsetof(struct ihs_fpga, fld), \
 val)

 so this turns into a plain and simple

 FPGA_SET_REG(0, mc_tx_address, addr);
 FPGA_SET_REG(0, mc_tx_data, data);
 FPGA_SET_REG(0, mc_tx_cmd, (slave  0x03)  14);


 This works nicely for our memory mapped FPGA. But how about the other FPGAs?
 I don't have a fpga_ptr for them. Setting it NULL would make FPGA_SET_REG
 dereference a NULL pointer.
 Certainly I might call
 fpga_set_reg(1,
  NULL,
  offsetof(struct ihs_fpga, mc_tx_address),
  addr);
 but that would not be generic any more.

 Do you have any idea how to solve this?


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


Re: [U-Boot] minimum bdi config to read flash on 85xx

2013-05-28 Thread Monica
Hi Fabio,

The CPU is imx6 customed processor.

The Prog command shows it passed but the u-boot.bin is not uploaded.

Regards,
Monica.S




From: Fabio Estevam-2 [via U-Boot] 
[mailto:ml-node+s10912n155717...@n7.nabble.com]
Sent: Monday, May 27, 2013 7:08 PM
To: Monica Sampathkumar
Subject: Re: minimum bdi config to read flash on 85xx

Hi Monica,

On Mon, May 27, 2013 at 10:01 AM, Monica [hidden 
email]/user/SendEmail.jtp?type=nodenode=155717i=0 wrote:

 We are using BDI3000 to Burn u-boot.bin to Flash memory. The flash we are
 using is Spansion S29GL512S.

 As per the flash datasheet we tried programming 4 bytes( using telnet mmb
 command) write buffer programming cycle. We succeeded.

 But when we tried programming a binary file ( u-boot.bin) ,it was failing.
 Even though the log shows Flash programming passed but in the location when
 we do a mdh there is no u-boot data.

 Please find the log captured below.

 IMX6#0

Your email subject mentions 85xx, but the prompt above says mx6.

Which CPU does your board have?
___
U-Boot mailing list
[hidden email]/user/SendEmail.jtp?type=nodenode=155717i=1
http://lists.denx.de/mailman/listinfo/u-boot


If you reply to this email, your message will be added to the discussion below:
http://u-boot.10912.n7.nabble.com/minimum-bdi-config-to-read-flash-on-85xx-tp23684p155717.html
To unsubscribe from minimum bdi config to read flash on 85xx, click 
herehttp://u-boot.10912.n7.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_codenode=23684code=bW9uaWNhX3NAaGNsLmNvbXwyMzY4NHw3MDA1NTgxNTM=.
NAMLhttp://u-boot.10912.n7.nabble.com/template/NamlServlet.jtp?macro=macro_viewerid=instant_html%21nabble%3Aemail.namlbase=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespacebreadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml


::DISCLAIMER::


The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only.
E-mail transmission is not guaranteed to be secure or error-free as information 
could be intercepted, corrupted,
lost, destroyed, arrive late or incomplete, or may contain viruses in 
transmission. The e mail and its contents
(with or without referred errors) shall therefore not attach any liability on 
the originator or HCL or its affiliates.
Views or opinions, if any, presented in this email are solely those of the 
author and may not necessarily reflect the
views or opinions of HCL or its affiliates. Any form of reproduction, 
dissemination, copying, disclosure, modification,
distribution and / or publication of this message without the prior written 
consent of authorized representative of
HCL is strictly prohibited. If you have received this email in error please 
delete it and notify the sender immediately.
Before opening any email and/or attachments, please check them for viruses and 
other defects.






--
View this message in context: 
http://u-boot.10912.n7.nabble.com/minimum-bdi-config-to-read-flash-on-85xx-tp23684p155770.html
Sent from the U-Boot mailing list archive at Nabble.com.___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH v2] Add support for Wandboard quad.

2013-05-28 Thread Tapani Utriainen

Add support for Wandboard quad.

Signed-off-by: Tapani Utriainen tap...@technexion.com
---
 Changes from v1:
 - reorganized the board names into alphabetical order
 - added quad entry to the Wandboard README
 
 board/wandboard/README  | 5 +
 boards.cfg  | 1 +
 include/configs/wandboard.h | 2 ++
 3 files changed, 8 insertions(+)

diff --git a/board/wandboard/README b/board/wandboard/README
index e0b0b33..ff43e03 100644
--- a/board/wandboard/README
+++ b/board/wandboard/README
@@ -17,6 +17,11 @@ To build U-Boot for the Wandboard Dual Lite version:
 $ make wanboard_dl_config
 $ make
 
+To build U-Boot for the Wandboard Quad version:
+
+$ make wandboard_quad_config
+$ make
+
 To build U-Boot for the Wandboard Solo version:
 
 $ make wanboard_solo_config
diff --git a/boards.cfg b/boards.cfg
index 98a512e..b510555 100644
--- a/boards.cfg
+++ b/boards.cfg 
@@ -267,6 +267,7 @@ nitrogen6q2g arm armv7   
nitrogen6x  boundar
 nitrogen6s   arm armv7   nitrogen6x  
boundary   mx6
nitrogen6x:IMX_CONFIG=board/boundary/nitrogen6x/nitrogen6s.cfg,MX6S,DDR_MB=512
 nitrogen6s1g arm armv7   nitrogen6x  
boundary   mx6
nitrogen6x:IMX_CONFIG=board/boundary/nitrogen6x/nitrogen6s1g.cfg,MX6S,DDR_MB=1024
 wandboard_dlarm armv7   wandboard   -  
mx6 
wandboard:IMX_CONFIG=board/boundary/nitrogen6x/nitrogen6dl.cfg,MX6DL,DDR_MB=1024
+wandboard_quad  arm armv7   wandboard   -  
mx6 
wandboard:IMX_CONFIG=board/boundary/nitrogen6x/nitrogen6q2g.cfg,MX6Q,DDR_MB=2048
 wandboard_solo  arm armv7   wandboard   -  
mx6 
wandboard:IMX_CONFIG=board/boundary/nitrogen6x/nitrogen6s.cfg,MX6S,DDR_MB=512
 cm_t35   arm armv7   cm_t35  - 
 omap3
 omap3_overo  arm armv7   overo   - 
 omap3
diff --git a/include/configs/wandboard.h b/include/configs/wandboard.h
index 120e3f6..ac86626 100644
--- a/include/configs/wandboard.h
+++ b/include/configs/wandboard.h
@@ -83,6 +83,8 @@
 
 #if defined(CONFIG_MX6DL)
 #define CONFIG_DEFAULT_FDT_FILEimx6dl-wandboard.dtb
+#elif defined(CONFIG_MX6Q)
+#define CONFIG_DEFAULT_FDT_FILEimx6q-wandboard.dtb
 #elif defined(CONFIG_MX6S)
 #define CONFIG_DEFAULT_FDT_FILEimx6s-wandboard.dtb
 #endif
--
1.8.0.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] Wandboard: Add support for Wandboard quad

2013-05-28 Thread Stefano Babic
On 28/05/2013 09:44, Tapani Utriainen wrote:

Hi Tapani,

 Otavio,
 
 while I do agree with the work you are doing (HDMI bootlogo into mainline),
 and would not have minded to base my patches on top of yours.
 However, the patches you sent seem to have been NAK:ed. The v3 does not apply 
 on top of 2013.04 (maybe I am basing on the wrong release!?).
 
 So for now, I am basing the resubmission on the 2013.04 release.
 
 regards,

Even if you are not constrained to take care of underlying patches (this
can maybe discussed in this mailing list if it is strictly required, but
of course it helps to avoid conflicts), it is not correct to stick with
a release. Basis for development is TOT on git.denx.de/u-boot.git, or,
for the i.MXes, git.denx.de/u-boot-imx.

Best regards,
Stefano Babic

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


Re: [U-Boot] [PATCH v3 0/6] arm: mvf600: Add Freescale Vybrid MVF600 CPU and MVF600TWR board support

2013-05-28 Thread Wang Huan-B18965
Hi, Stefano,

 On 24/05/2013 08:18, Wang Huan-B18965 wrote:
 
  [Alison Wang] We usually named the Powerpc(before QorIQ) as MPC and
 ColdFire as MCF, So we generally named the Vybrid as MVF.
  We had some internal discussion for this, and we think we should use
  VF instead of MVF, we will follow the internal suggestions to name
 the soc as VF610. Thanks for your comments.
 
 It is nice if you use the same name everybody finds on Freescale's
 Website. However, I hope you decide that the names will be consistent
 with the kernel, and also the patches that are currently posted to
 linux-arm will change the processor name. The worst thing is if we get
 a name in u-boot and another one in kernel.
 
[Alison Wang] Thanks for your reminder, we have discussed this with the kernel 
maintainer and get agreement to use the SoC name vf610. We'll use the 'vf610' 
in both u-boot and kernel. any comments for the name? Thanks.

Best Regards,
Alison Wang


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


Re: [U-Boot] [PATCH v3 0/6] arm: mvf600: Add Freescale Vybrid MVF600 CPU and MVF600TWR board support

2013-05-28 Thread Wang Huan-B18965
Hi, benoit,

On Tuesday, May 21, 2013 11:02:55 AM, Alison Wang wrote:
 This series contain the support for Freescale Vybrid MVF600 CPU
 and MVF600TWR board.

 Vybird devices are built on an asymmetrical-multiprocessing
 architecture using ARM cores. The families in the Vybrid
  portfolio
 span entry-level, single core Cortex-A class SoCs all the way
 to
 dual heterogeneous core SoCs with multiple communication and
 connectivity
options.

 Part of the Vybrid platform, MVF600 is a dual-core eMPU
 combining the ARM Cortex A5 and Cortex M4 cores.

 MVF600 shares some IPs with i.MX family, such as
 FEC,ESDHC,WATCHDOG,I2C,ASRC and ESAI.
 MVF600 also shares some IPs with ColdFire family, such as eDMA
  and DSPI.
 MVF600 still has its own IPs, such as PIT,SAI,UART,QSPI and DCU.

 More documents for this soc can be found at:

  http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=VF6
 xxf
 srch=1sr=5

 http://www.freescale.com/webapp/sps/site/homepage.jsp?code=VYBRI
 D
   
I have a question about the naming of this SoC. On Freescale's
website, it is VF6xx everywhere, but you add a leading M
 (_M_VF600).
Is it because you are using an internal SoC name known only by
Freescale and different from the marketing SoC name, or is this M
from the part number, or will the marketing SoC name change later,
  or some other reason? Please clarify.
U-Boot users must be able to identify a SoC and to find
information about it easily.
   [Alison Wang] We always use the name MVF600 in the internal
   development. We will check it with marketing team, and confirm it.
   Thanks.
 
  OK. You should also check for each part of the code in this patch set
  if it is specific to the (M)VF600 or common to all (M)VF6xx SoCs. In
  the latter case, the names in the code should be changed to either
  (m)vf6xx or (m)vf6, just like U-Boot uses mx5 to mean i.MX5xx. The
  naming for your Linux patches should also preferably be the same as
 in
  U-Boot in order to avoid confusion for users.
 [Alison Wang] We usually named the Powerpc(before QorIQ) as MPC and
 ColdFire as MCF, So we generally named the Vybrid as MVF.
 We had some internal discussion for this, and we think we should use VF
 instead of MVF, we will follow the internal suggestions to name the soc
 as VF610. Thanks for your comments.
 We have no detail spec for other vf6xx chips so far, so from technical
 side we can only make sure current code in this patch set is work for
 VF610. So we'll use VF610 instead of vf6xx.

[Alison Wang] Do you have any comments about the SoC name? I'd like to send out 
the next version patch set based on the new SoC name vf610. Thanks.


Best Regards,
Alison Wang

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


Re: [U-Boot] [PATCH v3 0/6] arm: mvf600: Add Freescale Vybrid MVF600 CPU and MVF600TWR board support

2013-05-28 Thread Stefano Babic
On 28/05/2013 10:51, Wang Huan-B18965 wrote:
 Hi, Stefano,
 
 On 24/05/2013 08:18, Wang Huan-B18965 wrote:

 [Alison Wang] We usually named the Powerpc(before QorIQ) as MPC and
 ColdFire as MCF, So we generally named the Vybrid as MVF.
 We had some internal discussion for this, and we think we should use
 VF instead of MVF, we will follow the internal suggestions to name
 the soc as VF610. Thanks for your comments.

 It is nice if you use the same name everybody finds on Freescale's
 Website. However, I hope you decide that the names will be consistent
 with the kernel, and also the patches that are currently posted to
 linux-arm will change the processor name. The worst thing is if we get
 a name in u-boot and another one in kernel.

 [Alison Wang] Thanks for your reminder, we have discussed this with the 
 kernel maintainer and get agreement to use the SoC name vf610. We'll use the 
 'vf610' in both u-boot and kernel. any comments for the name? Thanks.
 

No, you are the developer, you work in Freescale and your is the final
decision about the names.
My point of view, and maybe it is the same for most of Freescale's
customers, is to have consistent names. Everybody checking Freescale's
website knows that the SOC / board is supported in u-boot and/or kernel
if he finds the same names as on the website. But is the mx53loco the
same as mx53qsb, the official name to buy the board ? Of course, it is
the same, but not at the first glance. Or mx51evk and babbage ? Or
(following some other bad examples...) ?

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] [PATCH v4 4/7] arm: vf610: Add watchdog support for Vybrid VF610

2013-05-28 Thread Alison Wang
This patch adds watchdog support for Vybrid VF610 platform.

Signed-off-by: Alison Wang b18...@freescale.com
---
Changes in v4:
- Rename mvf600 to vf610

Changes in v3: None

Changes in v2:
- Add watchdog support
- Use reset_cpu() in imx_watchdog.c

 drivers/watchdog/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 13e7c37..e96acab 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -27,7 +27,7 @@ LIB   := $(obj)libwatchdog.o
 
 COBJS-$(CONFIG_AT91SAM9_WATCHDOG) += at91sam9_wdt.o
 COBJS-$(CONFIG_FTWDT010_WATCHDOG) += ftwdt010_wdt.o
-ifneq (,$(filter $(SOC), mx31 mx35 mx5 mx6))
+ifneq (,$(filter $(SOC), mx31 mx35 mx5 mx6 vf610))
 COBJS-y += imx_watchdog.o
 endif
 COBJS-$(CONFIG_TNETV107X_WATCHDOG) += tnetv107x_wdt.o
-- 
1.8.0


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


[U-Boot] [PATCH v4 0/7] arm: vf610: Add Freescale Vybrid VF610 CPU and VF610TWR board support

2013-05-28 Thread Alison Wang
This series contain the support for Freescale Vybrid VF610 CPU and VF610TWR 
board.

Vybird devices are built on an asymmetrical-multiprocessing architecture
using ARM cores. The families in the Vybrid portfolio span entry-level,
single core Cortex-A class SoCs all the way to dual heterogeneous core SoCs
with multiple communication and connectivity options.

Part of the Vybrid platform, VF610 is a dual-core eMPU combining the ARM
Cortex A5 and Cortex M4 cores.

VF610 shares some IPs with i.MX family, such as FEC,ESDHC,WATCHDOG,I2C,ASRC and 
ESAI.
VF610 also shares some IPs with ColdFire family, such as eDMA and DSPI.
VF610 still has its own IPs, such as PIT,SAI,UART,QSPI and DCU.

More documents for this soc can be found at:
http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=VF6xxfsrch=1sr=5
http://www.freescale.com/webapp/sps/site/homepage.jsp?code=VYBRID

To align with the description in the above documents, VF610 is used as the 
SoC name instead of MVF600.

The u-boot runs on Cortex A5 core.

Changes in v4:
- Rename MVF600 to VF610
- Define PAD_CTL_PUS_47K_UP and PAD_CTL_PUS_100K_UP with PAD_CTL_PUE enabled
- Reorganize the definitions
- Correct the spaces and tabs
- Rename mvf_pins.h to iomux-vf610.h
- Add README.vf610 about fuse assignments for MAC addresses
- Rename directory name 'mvf600' to 'vf610'
- Rename directory 'arch-mvf600' to 'arch-vf610'
- Add Vybrid VF610 to mxc_ocotp document
- Rename directory name 'mvf600twr' to 'vf610twr'
- Rename mvf600twr.h to vf610twr.h
- Use NEW_PAD_CTRL instead of MUX_PAD_CTRL
- Remove CONFIG_ETHPRIME option
- Add CONFIG_CMD_MEMSET option

Changes in v3:
- Rename the common functions and enums
- Move the structure definitions to imx-regs.h
- Define PAD_CTL_PUE with PKE enabled
- Remove the changes for FEC_RCNTRL_RGMII / FEC_RCNTRL_RMII / 
FEC_RCNTRL_MII_MODE bits, as they are already set in fec_reg_setup()
- Replace BOOT_FROM by BOOT_OFFSET
- Enable CONFIG_OF_LIBFDT option
- Add useful define instead of raw number
- Use clrsetbits_le32 to set the single bits
- Move setup_iomux_enet() to board_early_init_f and remove board_eth_init()
- Remove redundant define
- Move CONFIG_IOMUX_SHARE_CONF_REG to imx-regs.h

Changes in v2:
- Remove vybrid-common directory
- Rename directory name 'vybrid' to 'mvf600'
- Add generic.c file
- Rewrite get_reset_cause() to make it readable
- Remove reset_cpu(), and use the function in imx_watchdog.c
- Rewrite timer.c file
- Use vybrid_get_clock(VYBRID_UART_CLK) instead of vybrid_get_uartclk()
- Remove lowlevel_init.S, and add clock_init() in board_early_init_f()
- Remove useless CONFIG_SYS_ defines
- Move CONFIG_MACH_TYPE to board configuration file
- Define C structures and access C structures to set/read registers
- Remove useless errata
- Remove useless macros
- Rename directory 'arch-vybrid' to 'arch-mvf600'
- Use common iomux-v3 code
- Use common FEC driver fec_mxc.c
- Add watchdog support
- Add an entry to MAINTAINERS file
- Rename directory name 'vybird' to 'mvf600twr'
- Use standard method to set gd-ram_size
- Rewrite board_mmc_getcd() function
- Remove useless undef
- Remove hardcoded IP addresses and MAC addresses
- Move CONFIG_MACH_TYPE to board configuration file


Alison Wang (7):
  arm: vf610: Add IOMUX support for Vybrid VF610
  arm: vf610: Add Vybrid VF610 CPU support
  net: fec_mxc: Add support for Vybrid VF610
  arm: vf610: Add watchdog support for Vybrid VF610
  arm: vf610: Add uart support for Vybrid VF610
  arm: vf610: Add Vybrid VF610 to mxc_ocotp document
  arm: vf610: Add basic support for Vybrid VF610TWR board

 MAINTAINERS   |   4 +
 Makefile  |   2 +-
 arch/arm/cpu/armv7/vf610/Makefile |  42 +++
 arch/arm/cpu/armv7/vf610/generic.c| 324 
+++
 arch/arm/cpu/armv7/vf610/timer.c  | 103 ++
 arch/arm/imx-common/Makefile  |   2 +-
 arch/arm/imx-common/iomux-v3.c|   6 ++
 arch/arm/include/asm/arch-vf610/clock.h   |  39 ++
 arch/arm/include/asm/arch-vf610/crm_regs.h| 225 
+++
 arch/arm/include/asm/arch-vf610/imx-regs.h| 419 
+++
 arch/arm/include/asm/arch-vf610/iomux-vf610.h | 101 +
 arch/arm/include/asm/imx-common/iomux-v3.h|  18 +
 board/freescale/vf610twr/Makefile |  39 ++
 board/freescale/vf610twr/imximage.cfg |  33 +
 board/freescale/vf610twr/vf610twr.c   | 410 

 boards.cfg|   1 +
 

[U-Boot] [PATCH v4 1/7] arm: vf610: Add IOMUX support for Vybrid VF610

2013-05-28 Thread Alison Wang
This patch adds the IOMUX support for Vybrid VF610 platform.

There is a little difference for IOMUXC module between VF610 and i.MX
platform, the muxmode and pad configuration share one 32bit register on
VF610, but they are two independent registers on I.MX platform. A
CONFIG_IOMUX_SHARE_CONFIG_REG was introduced to fit this difference.

Signed-off-by: Alison Wang b18...@freescale.com
---
Changes in v4:
- Rename MVF600 to VF610
- Define PAD_CTL_PUS_47K_UP and PAD_CTL_PUS_100K_UP with PAD_CTL_PUE enabled
- Reorganize the definitions
- Correct the spaces and tabs

Changes in v3:
- Define PAD_CTL_PUE with PKE enabled

Changes in v2:
- Use common iomux-v3 code

 arch/arm/imx-common/Makefile   |  2 +-
 arch/arm/imx-common/iomux-v3.c |  6 ++
 arch/arm/include/asm/imx-common/iomux-v3.h | 18 ++
 3 files changed, 25 insertions(+), 1 deletion(-)

diff --git a/arch/arm/imx-common/Makefile b/arch/arm/imx-common/Makefile
index 8bba8a5..9492326 100644
--- a/arch/arm/imx-common/Makefile
+++ b/arch/arm/imx-common/Makefile
@@ -27,7 +27,7 @@ include $(TOPDIR)/config.mk
 
 LIB = $(obj)libimx-common.o
 
-ifeq ($(SOC),$(filter $(SOC),mx25 mx35 mx5 mx6))
+ifeq ($(SOC),$(filter $(SOC),mx25 mx35 mx5 mx6 vf610))
 COBJS-y= iomux-v3.o
 endif
 ifeq ($(SOC),$(filter $(SOC),mx5 mx6))
diff --git a/arch/arm/imx-common/iomux-v3.c b/arch/arm/imx-common/iomux-v3.c
index 7fe5ce7..35880c7 100644
--- a/arch/arm/imx-common/iomux-v3.c
+++ b/arch/arm/imx-common/iomux-v3.c
@@ -48,8 +48,14 @@ void imx_iomux_v3_setup_pad(iomux_v3_cfg_t pad)
if (sel_input_ofs)
__raw_writel(sel_input, base + sel_input_ofs);
 
+#ifdef CONFIG_IOMUX_SHARE_CONF_REG
+   if (!(pad_ctrl  NO_PAD_CTRL))
+   __raw_writel((mux_mode  PAD_MUX_MODE_SHIFT) | pad_ctrl,
+   base + pad_ctrl_ofs);
+#else
if (!(pad_ctrl  NO_PAD_CTRL)  pad_ctrl_ofs)
__raw_writel(pad_ctrl, base + pad_ctrl_ofs);
+#endif
 }
 
 void imx_iomux_v3_setup_multiple_pads(iomux_v3_cfg_t const *pad_list,
diff --git a/arch/arm/include/asm/imx-common/iomux-v3.h 
b/arch/arm/include/asm/imx-common/iomux-v3.h
index 0b4e763..ebf54cf 100644
--- a/arch/arm/include/asm/imx-common/iomux-v3.h
+++ b/arch/arm/include/asm/imx-common/iomux-v3.h
@@ -121,6 +121,24 @@ typedef u64 iomux_v3_cfg_t;
 #define PAD_CTL_DSE_40ohm  (6  3)
 #define PAD_CTL_DSE_34ohm  (7  3)
 
+#elif defined(CONFIG_VF610)
+
+#define PAD_MUX_MODE_SHIFT 20
+
+#define PAD_CTL_SPEED_MED  (1  12)
+#define PAD_CTL_SPEED_HIGH (3  12)
+
+#define PAD_CTL_DSE_50ohm  (3  6)
+#define PAD_CTL_DSE_25ohm  (6  6)
+#define PAD_CTL_DSE_20ohm  (7  6)
+
+#define PAD_CTL_PUS_47K_UP (1  4 | PAD_CTL_PUE)
+#define PAD_CTL_PUS_100K_UP(2  4 | PAD_CTL_PUE)
+#define PAD_CTL_PKE(1  3)
+#define PAD_CTL_PUE(1  2 | PAD_CTL_PKE)
+
+#define PAD_CTL_OBE_IBE_ENABLE (3  0)
+
 #else
 
 #define PAD_CTL_DVS(1  13)
-- 
1.8.0


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


[U-Boot] [PATCH v4 5/7] arm: vf610: Add uart support for Vybrid VF610

2013-05-28 Thread Alison Wang
This patch adds lpuart support for Vybrid VF610 platform.

Signed-off-by: TsiChung Liew tsicl...@gmail.com
Signed-off-by: Alison Wang b18...@freescale.com
---
Changes in v4: None

Changes in v3:
- Move the structure definition to imx-regs.h

Changes in v2:
- Define C structures and access C structures to set/read registers
- Change the names to reuse this driver on other platforms

 drivers/serial/Makefile|   1 +
 drivers/serial/serial_lpuart.c | 132 +
 2 files changed, 133 insertions(+)
 create mode 100644 drivers/serial/serial_lpuart.c

diff --git a/drivers/serial/Makefile b/drivers/serial/Makefile
index fbc4e97..bb6559b 100644
--- a/drivers/serial/Makefile
+++ b/drivers/serial/Makefile
@@ -52,6 +52,7 @@ COBJS-$(CONFIG_XILINX_UARTLITE) += serial_xuartlite.o
 COBJS-$(CONFIG_SANDBOX_SERIAL) += sandbox.o
 COBJS-$(CONFIG_SCIF_CONSOLE) += serial_sh.o
 COBJS-$(CONFIG_ZYNQ_SERIAL) += serial_zynq.o
+COBJS-$(CONFIG_FSL_LPUART) += serial_lpuart.o
 
 ifndef CONFIG_SPL_BUILD
 COBJS-$(CONFIG_USB_TTY) += usbtty.o
diff --git a/drivers/serial/serial_lpuart.c b/drivers/serial/serial_lpuart.c
new file mode 100644
index 000..51d5666
--- /dev/null
+++ b/drivers/serial/serial_lpuart.c
@@ -0,0 +1,132 @@
+/*
+ * Copyright 2013 Freescale Semiconductor, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ *
+ */
+
+#include common.h
+#include watchdog.h
+#include asm/io.h
+#include serial.h
+#include linux/compiler.h
+#include asm/arch/imx-regs.h
+#include asm/arch/clock.h
+
+#define US1_TDRE(1  7)
+#define US1_RDRF(1  5)
+#define UC2_TE  (1  3)
+#define UC2_RE  (1  2)
+
+DECLARE_GLOBAL_DATA_PTR;
+
+struct lpuart_fsl *base = (struct lpuart_fsl *)LPUART_BASE;
+
+static void lpuart_serial_setbrg(void)
+{
+   u32 clk = mxc_get_clock(MXC_UART_CLK);
+   u16 sbr;
+
+   if (!gd-baudrate)
+   gd-baudrate = CONFIG_BAUDRATE;
+
+   sbr = (u16)(clk / (16 * gd-baudrate));
+   /* place adjustment later - n/32 BRFA */
+
+   __raw_writeb(sbr  8, base-ubdh);
+   __raw_writeb(sbr  0xff, base-ubdl);
+}
+
+static int lpuart_serial_getc(void)
+{
+   u8 status;
+
+   while (!(__raw_readb(base-us1)  US1_RDRF))
+   WATCHDOG_RESET();
+
+   status = __raw_readb(base-us1);
+   status |= US1_RDRF;
+   __raw_writeb(status, base-us1);
+
+   return __raw_readb(base-ud);
+}
+
+static void lpuart_serial_putc(const char c)
+{
+   if (c == '\n')
+   serial_putc('\r');
+
+   while (!(__raw_readb(base-us1)  US1_TDRE))
+   WATCHDOG_RESET();
+
+   __raw_writeb(c, base-ud);
+}
+
+/*
+ * Test whether a character is in the RX buffer
+ */
+static int lpuart_serial_tstc(void)
+{
+   if (__raw_readb(base-urcfifo) == 0)
+   return 0;
+
+   return 1;
+}
+
+/*
+ * Initialise the serial port with the given baudrate. The settings
+ * are always 8 data bits, no parity, 1 stop bit, no start bits.
+ */
+static int lpuart_serial_init(void)
+{
+   u8 ctrl;
+
+   ctrl = __raw_readb(base-uc2);
+   ctrl = ~UC2_RE;
+   ctrl = ~UC2_TE;
+   __raw_writeb(ctrl, base-uc2);
+
+   __raw_writeb(0, base-umodem);
+   __raw_writeb(0, base-uc1);
+
+   /* provide data bits, parity, stop bit, etc */
+
+   serial_setbrg();
+
+   __raw_writeb(UC2_RE | UC2_TE, base-uc2);
+
+   return 0;
+}
+
+static struct serial_device lpuart_serial_drv = {
+   .name = lpuart_serial,
+   .start = lpuart_serial_init,
+   .stop = NULL,
+   .setbrg = lpuart_serial_setbrg,
+   .putc = lpuart_serial_putc,
+   .puts = default_serial_puts,
+   .getc = lpuart_serial_getc,
+   .tstc = lpuart_serial_tstc,
+};
+
+void lpuart_serial_initialize(void)
+{
+   serial_register(lpuart_serial_drv);
+}
+
+__weak struct serial_device *default_serial_console(void)
+{
+   return lpuart_serial_drv;
+}
-- 
1.8.0


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


[U-Boot] [PATCH v4 2/7] arm: vf610: Add Vybrid VF610 CPU support

2013-05-28 Thread Alison Wang
This patch adds generic codes to support Freescale's Vybrid VF610 CPU.

It aligns Vybrid VF610 platform with i.MX platform. As there are
some differences between VF610 and i.MX platforms, the specific
codes are in the arch/arm/cpu/armv7/vf610 directory.

Signed-off-by: Alison Wang b18...@freescale.com
---
Changes in v4:
- Rename mvf_pins.h to iomux-vf610.h
- Add README.vf610 about fuse assignments for MAC addresses
- Rename directory name 'mvf600' to 'vf610'
- Rename directory 'arch-mvf600' to 'arch-vf610'

Changes in v3:
- Rename the common functions and enums
- Move the structure definitions to imx-regs.h  

Changes in v2:
- Remove vybrid-common directory
- Rename directory name 'vybrid' to 'mvf600'
- Add generic.c file
- Rewrite get_reset_cause() to make it readable
- Remove reset_cpu(), and use the function in imx_watchdog.c
- Rewrite timer.c file
- Use vybrid_get_clock(VYBRID_UART_CLK) instead of vybrid_get_uartclk()
- Remove lowlevel_init.S, and add clock_init() in board_early_init_f()
- Remove useless CONFIG_SYS_ defines
- Move CONFIG_MACH_TYPE to board configuration file
- Define C structures and access C structures to set/read registers
- Remove useless errata
- Remove useless macros
- Rename directory 'arch-vybrid' to 'arch-mvf600'

 Makefile  |   2 +-
 arch/arm/cpu/armv7/vf610/Makefile |  42 +++
 arch/arm/cpu/armv7/vf610/generic.c| 324 
 arch/arm/cpu/armv7/vf610/timer.c  | 103 +++
 arch/arm/include/asm/arch-vf610/clock.h   |  39 +++
 arch/arm/include/asm/arch-vf610/crm_regs.h| 225 ++
 arch/arm/include/asm/arch-vf610/imx-regs.h| 419 ++
 arch/arm/include/asm/arch-vf610/iomux-vf610.h | 101 +++
 doc/README.vf610  |  10 +
 9 files changed, 1264 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/cpu/armv7/vf610/Makefile
 create mode 100644 arch/arm/cpu/armv7/vf610/generic.c
 create mode 100644 arch/arm/cpu/armv7/vf610/timer.c
 create mode 100644 arch/arm/include/asm/arch-vf610/clock.h
 create mode 100644 arch/arm/include/asm/arch-vf610/crm_regs.h
 create mode 100644 arch/arm/include/asm/arch-vf610/imx-regs.h
 create mode 100644 arch/arm/include/asm/arch-vf610/iomux-vf610.h
 create mode 100644 doc/README.vf610

diff --git a/Makefile b/Makefile
index c52f0f1..363180c 100644
--- a/Makefile
+++ b/Makefile
@@ -341,7 +341,7 @@ ifneq 
($(CONFIG_AM33XX)$(CONFIG_OMAP34XX)$(CONFIG_OMAP44XX)$(CONFIG_OMAP54XX)$(C
 LIBS-y += $(CPUDIR)/omap-common/libomap-common.o
 endif
 
-ifneq (,$(filter $(SOC), mx25 mx27 mx5 mx6 mx31 mx35 mxs))
+ifneq (,$(filter $(SOC), mx25 mx27 mx5 mx6 mx31 mx35 mxs vf610))
 LIBS-y += arch/$(ARCH)/imx-common/libimx-common.o
 endif
 
diff --git a/arch/arm/cpu/armv7/vf610/Makefile 
b/arch/arm/cpu/armv7/vf610/Makefile
new file mode 100644
index 000..9232cd4
--- /dev/null
+++ b/arch/arm/cpu/armv7/vf610/Makefile
@@ -0,0 +1,42 @@
+#
+# Copyright 2013 Freescale Semiconductor, Inc.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+# MA 02111-1307 USA
+#
+
+include $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(SOC).o
+
+COBJS  += generic.o
+COBJS  += timer.o
+
+SRCS   := $(COBJS:.o=.c)
+OBJS   := $(addprefix $(obj),$(COBJS))
+
+all:   $(obj).depend $(LIB)
+
+$(LIB):$(OBJS)
+   $(call cmd_link_o_target, $(OBJS))
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/arch/arm/cpu/armv7/vf610/generic.c 
b/arch/arm/cpu/armv7/vf610/generic.c
new file mode 100644
index 000..87f2a86
--- /dev/null
+++ b/arch/arm/cpu/armv7/vf610/generic.c
@@ -0,0 +1,324 @@
+/*
+ * Copyright 2013 Freescale Semiconductor, Inc.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General 

[U-Boot] [PATCH v4 6/7] arm: vf610: Add Vybrid VF610 to mxc_ocotp document

2013-05-28 Thread Alison Wang
This patch adds Vybrid VF610 to mxc_ocotp document.

Signed-off-by: Alison Wang b18...@freescale.com
---
Changes in v4: New

Changes in v3: None

Changes in v2: None

 doc/README.mxc_ocotp | 1 +
 1 file changed, 1 insertion(+)

diff --git a/doc/README.mxc_ocotp b/doc/README.mxc_ocotp
index 9a53311..7a2863c 100644
--- a/doc/README.mxc_ocotp
+++ b/doc/README.mxc_ocotp
@@ -2,6 +2,7 @@ Driver implementing the fuse API for Freescale's On-Chip OTP 
Controller (OCOTP)
 on MXC
 
 This IP can be found on the following SoCs:
+ - Vybrid VF610,
  - i.MX6.
 
 Note that this IP is different from albeit similar to the IPs of the same name
-- 
1.8.0


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


[U-Boot] [PATCH v4 3/7] net: fec_mxc: Add support for Vybrid VF610

2013-05-28 Thread Alison Wang
This patch adds FEC support for Vybrid VF610 platform.

In function fec_open(), RCR register is only set as RGMII mode. But RCR
register should be set as RMII mode for VF610 platform.
This configuration is already done in fec_reg_setup(), so this piece of
code could just leave untouched the FEC_RCNTRL_RGMII / FEC_RCNTRL_RMII /
FEC_RCNTRL_MII_MODE bits.

Signed-off-by: Alison Wang b18...@freescale.com
Reviewed-by: Benoit Thebaudeau benoit.thebaud...@advansee.com
---
Changes in v4: None

Changes in v3:
- Remove the changes for FEC_RCNTRL_RGMII / FEC_RCNTRL_RMII / 
FEC_RCNTRL_MII_MODE bits, as they are already set in fec_reg_setup() 

Changes in v2:
- Use common FEC driver fec_mxc.c

 drivers/net/fec_mxc.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/net/fec_mxc.c b/drivers/net/fec_mxc.c
index 4dbcdca..da95e28 100644
--- a/drivers/net/fec_mxc.c
+++ b/drivers/net/fec_mxc.c
@@ -516,9 +516,7 @@ static int fec_open(struct eth_device *edev)
 #ifdef FEC_QUIRK_ENET_MAC
{
u32 ecr = readl(fec-eth-ecntrl)  ~FEC_ECNTRL_SPEED;
-   u32 rcr = (readl(fec-eth-r_cntrl) 
-   ~(FEC_RCNTRL_RMII | FEC_RCNTRL_RMII_10T)) |
-   FEC_RCNTRL_RGMII | FEC_RCNTRL_MII_MODE;
+   u32 rcr = readl(fec-eth-r_cntrl)  ~FEC_RCNTRL_RMII_10T;
if (speed == _1000BASET)
ecr |= FEC_ECNTRL_SPEED;
else if (speed != _100BASET)
-- 
1.8.0


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


[U-Boot] [PATCH v4 7/7] arm: vf610: Add basic support for Vybrid VF610TWR board

2013-05-28 Thread Alison Wang
VF610TWR is a board based on Vybrid VF610 SoC.

This patch adds basic support for Vybrid VF610TWR board.

Signed-off-by: Alison Wang b18...@freescale.com
Signed-off-by: Jason Jin jason@freescale.com
Signed-off-by: TsiChung Liew tsicl...@gmail.com
---
Changes in v4:
- Rename directory name 'mvf600twr' to 'vf610twr'
- Rename mvf600twr.h to vf610twr.h
- Use NEW_PAD_CTRL instead of MUX_PAD_CTRL
- Remove CONFIG_ETHPRIME option
- Add CONFIG_CMD_MEMSET option

Changes in v3:
- Replace BOOT_FROM by BOOT_OFFSET
- Enable CONFIG_OF_LIBFDT option
- Add useful define instead of raw number
- Use clrsetbits_le32 to set the single bits
- Move setup_iomux_enet() to board_early_init_f and remove board_eth_init()
- Remove redundant define
- Move CONFIG_IOMUX_SHARE_CONF_REG to imx-regs.h

Changes in v2:
- Add an entry to MAINTAINERS file
- Rename directory name 'vybird' to 'mvf600twr'
- Use standard method to set gd-ram_size
- Rewrite board_mmc_getcd() function
- Remove useless undef
- Remove hardcoded IP addresses and MAC addresses
- Remove useless CONFIG_SYS_ defines
- Define C structures and access C structures to set/read registers
- Move CONFIG_MACH_TYPE to board configuration file
- Use common iomux-v3 code

 MAINTAINERS   |   4 +
 board/freescale/vf610twr/Makefile |  39 
 board/freescale/vf610twr/imximage.cfg |  33 +++
 board/freescale/vf610twr/vf610twr.c   | 410 ++
 boards.cfg|   1 +
 include/configs/vf610twr.h| 140 
 6 files changed, 627 insertions(+)
 create mode 100644 board/freescale/vf610twr/Makefile
 create mode 100644 board/freescale/vf610twr/imximage.cfg
 create mode 100644 board/freescale/vf610twr/vf610twr.c
 create mode 100644 include/configs/vf610twr.h

diff --git a/MAINTAINERS b/MAINTAINERS
index c05433a..e4113d8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1057,6 +1057,10 @@ Eric Nelson eric.nel...@boundarydevices.com
nitrogen6s  i.MX6S  512MB
nitrogen6s1gi.MX6S  1GB
 
+Alison Wang b18...@freescale.com
+
+   vf610twrVF610
+
 -
 
 Unknown / orphaned boards:
diff --git a/board/freescale/vf610twr/Makefile 
b/board/freescale/vf610twr/Makefile
new file mode 100644
index 000..7416228
--- /dev/null
+++ b/board/freescale/vf610twr/Makefile
@@ -0,0 +1,39 @@
+#
+# Copyright 2013 Freescale Semiconductor, Inc.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+# MA 02111-1307 USA
+#
+
+include $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(BOARD).o
+
+COBJS  := $(BOARD).o
+
+SRCS   := $(COBJS:.o=.c)
+OBJS   := $(addprefix $(obj),$(COBJS))
+
+$(LIB):$(obj).depend $(OBJS)
+   $(call cmd_link_o_target, $(OBJS))
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/freescale/vf610twr/imximage.cfg 
b/board/freescale/vf610twr/imximage.cfg
new file mode 100644
index 000..b00d4c1
--- /dev/null
+++ b/board/freescale/vf610twr/imximage.cfg
@@ -0,0 +1,33 @@
+/*
+ * Copyright 2013 Freescale Semiconductor, Inc.
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not write to the Free Software
+ * Foundation Inc. 51 Franklin Street Fifth Floor Boston,
+ * MA 02110-1301 USA
+ *
+ * Refer docs/README.imxmage for more details about how-to configure
+ * and create imximage boot image
+ *
+ * The syntax is taken as close as possible with the kwbimage
+ */
+#include asm/imx-common/imximage.cfg

[U-Boot] about uboot leads to LAN disconnected

2013-05-28 Thread wanghgsz
Dear all,
   Device is a camera connected LAN, camera  board  CPU is  RT5350(based on 
MIPS) .
 I have met a problem about uboot. uboot leads to LAN disconnected in the 
following cases. 
 I have been looking forward to answers.
   with best wishes



case 1 :   when  CRC checksum  bad
Please choose the operation:
   1: Load system code to SDRAM via TFTP.
   2: Load system code then write to Flash via TFTP.
   3: Boot system code via Flash (default).
   4: Entr boot command line interface.
   7: Load Boot Loader code then write to Flash via Serial.
   9: Load Boot Loader code then write to Flash via TFTP.
 0


3: System Boot system code via Flash.
## Booting image at bc05 ...
raspi_read: from:5 len:40
.   Image Name:   Linux Kernel Image
   Created:  2013-03-14   6:22:22 UTC
   Image Type:   MIPS Linux Kernel Image (lzma compressed)
   Data Size:3113308 Bytes =  3 MB
   Load Address: 8000
   Entry Point:  802fb000
raspi_read: from:50040 len:2f815c
   Verifying Checksum ... Bad 
Data CRC




case 2  when modify parameters spend over 10 seconds


1: System Load Linux to SDRAM via TFTP.
 Please Input new ones /or Ctrl-C to discard
Input device IP (192.168.0.121) ==:192.168.0.121
Input server IP (192.168.0.66) ==:192.168.0.66




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


Re: [U-Boot] [PATCH v2 06/10] powerpc/ppc4xx: Use generic FPGA accessors on all gdsys 405ep/ex boards

2013-05-28 Thread Wolfgang Denk
Dear Dirk,

In message 0e4604dcfff89a1bd2b7f144a5b3c...@gdsys.cc you wrote:
 
 sorry for the delay, I had to clean some other things on my ToDoList.

Ditto :-(

  void fpga_set_reg(u32 fpga, u16 *reg, off_t regoff, u16 data)
  {
  if (fpga)
  return mclink_send(fpga - 1, regoff, data);
  
  return out_le16(reg, data);
  }
...

  #define FPGA_SET_REG(ix,fld,val)\
  fpga_set_reg((ix),  \
  fpga_ptr-fld, \
  offsetof(struct ihs_fpga, fld), \
  val)
...
  FPGA_SET_REG(0, mc_tx_address, addr);
  FPGA_SET_REG(0, mc_tx_data, data);
  FPGA_SET_REG(0, mc_tx_cmd, (slave  0x03)  14);
 
 This works nicely for our memory mapped FPGA. But how about the other 
 FPGAs? I don't have a fpga_ptr for them. Setting it NULL would make 
 FPGA_SET_REG dereference a NULL pointer.

No, it does not.

In your setup you have a single memory mapped FPGA, addressed by the
globally visible pointer  fpga_ptr.

When accessing this memory mapped FPGA (index is zero), then this
pointer gets used, which is OK.

For the other devices (index is not zero), then the pointer is
ignored, and only the offset is used.

In case you had more memory mapped devices (not only index 0; say,
something like index  N) you can still use this, and pass any
(properly aligned) pointer for the non-memory mapped case.  Note that
the pointer will NOT be dereferenced - only the address of field fld
will be calculated (and even this only in theory, because this code
will not be executed for the non-memory mapped case).

 Certainly I might call
   fpga_set_reg(1,
NULL,
offsetof(struct ihs_fpga, mc_tx_address),
addr);
 but that would not be generic any more.

You don't call fpga_set_reg() any more, you just use the
FPGA_SET_REG() macro described above.

 Do you have any idea how to solve this?

I think this needs no new solution, because it shoul just work :-)

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
Alan Turing thought about criteria to settle the question of  whether
machines  can think, a question of which we now know that it is about
as relevant as the question of whether submarines can swim.
   -- Edsger Dijkstra
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v2] Add support for Wandboard quad.

2013-05-28 Thread Otavio Salvador
On Tue, May 28, 2013 at 5:04 AM, Tapani Utriainen tap...@technexion.comwrote:


 Add support for Wandboard quad.

 Signed-off-by: Tapani Utriainen tap...@technexion.com


Acked-by: Otavio Salvador ota...@ossystems.com.br

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


Re: [U-Boot] [PATCH] Wandboard: Add support for Wandboard quad

2013-05-28 Thread Otavio Salvador
On Tue, May 28, 2013 at 4:44 AM, Tapani Utriainen tap...@technexion.comwrote:

 On Mon, 27 May 2013 13:56:30 -0300
 Otavio Salvador ota...@ossystems.com.br wrote:

  I have sent two patches for adding the Boot Splash with Wandboard logo.
  Please take a look on them and if you agree please base on this to avoid
  conflicts.
 
  (For easyness:
 http://patchwork.ozlabs.org/bundle/otavio/wandboard-20130527/
  )
 

 Otavio,

 while I do agree with the work you are doing (HDMI bootlogo into mainline),
 and would not have minded to base my patches on top of yours.
 However, the patches you sent seem to have been NAK:ed. The v3 does not
 apply
 on top of 2013.04 (maybe I am basing on the wrong release!?).

 So for now, I am basing the resubmission on the 2013.04 release.


You must base on imx/master as this is the custodian tree for upcoming
2013.07 release.

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


Re: [U-Boot] [U-BOOT PATCH] sf: Fix sf read for memory-mapped SPI flashes

2013-05-28 Thread Jagan Teki
Hi Simon,

Can you please check this change.

Thanks,
Jagan.

On Tue, May 28, 2013 at 1:44 AM, Jagannadha Sutradharudu Teki
jagannadha.sutradharudu-t...@xilinx.com wrote:
 Missing return after memcpy is done for memory-mapped SPI flashes,
 hence added retun 0 after memcpy done.

 The return is missing in below patch
 sf: Enable FDT-based configuration and memory mapping
 (sha1: bb8215f437a7c948eec82a6abe754c226978bd6d)

 Signed-off-by: Jagannadha Sutradharudu Teki jaga...@xilinx.com
 ---
  drivers/mtd/spi/spi_flash.c |4 +++-
  1 files changed, 3 insertions(+), 1 deletions(-)

 diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
 index aeb1ccb..1d45e3b 100644
 --- a/drivers/mtd/spi/spi_flash.c
 +++ b/drivers/mtd/spi/spi_flash.c
 @@ -148,8 +148,10 @@ int spi_flash_cmd_read_fast(struct spi_flash *flash, u32 
 offset,
 u8 cmd[5];

 /* Handle memory-mapped SPI */
 -   if (flash-memory_map)
 +   if (flash-memory_map) {
 memcpy(data, flash-memory_map + offset, len);
 +   return 0;
 +   }

 cmd[0] = CMD_READ_ARRAY_FAST;
 spi_flash_addr(offset, cmd);
 --
 1.7.4





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


Re: [U-Boot] [PATCH v4 0/4] Factorize ARM relocate_code instances

2013-05-28 Thread Albert ARIBAUD
Hi Fabio,

On Tue, 21 May 2013 10:24:19 -0300, Fabio Estevam feste...@gmail.com
wrote:

 Hi Benoît,
 
 On Mon, May 20, 2013 at 12:39 PM, Benoît Thébaudeau
 benoit.thebaud...@advansee.com wrote:
 
  Can you test this series on mx31pdk (directly changed by this series), and 
  some
  other i.MX EVK (e.g. ARMv7, so mx51evk or mx53*) board please? That should 
  be
  enough for ARM.
 
 I don't have access to my mx31pdk currently, but I will try to get
 access to it later this week.
 
 Then I can test this series on mx31pdk and also on mx53loco.

Did you manage this test? If you did and it succeeded, then I'll merge
the series into u-boot-arm.

 Regards,
 
 Fabio Estevam

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


Re: [U-Boot] [PATCH v2] EXYNOS: SPL: Add a custom spi copy function

2013-05-28 Thread Rajeshwari Birje
Hi Wolfgang Denk,

Thank you for review comments.

On Sun, May 12, 2013 at 2:01 AM, Wolfgang Denk w...@denx.de wrote:
 Dear Simon Glass,

 In message 1368285471-11039-1-git-send-email-...@chromium.org you wrote:
 From: Rajeshwari Shinde rajeshwar...@samsung.com

 This CL implements a custom spi_copy funtion to copy u-boot from SF to

 What is a CL ?

 Changed a printf in pimux.c to debug just to avoid the the compilation

 s/the the/the/ ??

 Removed the enum for boot mode from spl_boot.c as it was already define in 
 spl.h

 s/define/defined/

 Line length in commit messages should be not more than 72 characters.
Will correct these issues and resubmit the patch set soon.


 +/**
 + * Copy uboot from spi flash to RAM
 + *
 + * @parma uboot_size size of u-boot to copy
 + * @param uboot_addr address of u-boot to copy
 + */

 Incorrect multiline comment style.
Will correct these

 +static void exynos_spi_copy(unsigned int uboot_size, unsigned int 
 uboot_addr)
 +{
 + int upto, todo;
 + int i;
 + struct exynos_spi *regs = (struct exynos_spi *)CONFIG_ENV_SPI_BASE;
 +
 + set_spi_clk(PERIPH_ID_SPI1, 5000); /* set spi clock to 50Mhz */
 + /* set the spi1 GPIO */
 + exynos_pinmux_config(PERIPH_ID_SPI1, PINMUX_FLAG_NONE);
 +
 + /* set pktcnt and enable it */
 + writel(4 | SPI_PACKET_CNT_EN, regs-pkt_cnt);
 + /* set FB_CLK_SEL */
 + writel(SPI_FB_DELAY_180, regs-fb_clk);
 + /* set CH_WIDTH and BUS_WIDTH as word */
 + setbits_le32(regs-mode_cfg, SPI_MODE_CH_WIDTH_WORD |
 + SPI_MODE_BUS_WIDTH_WORD);
 + clrbits_le32(regs-ch_cfg, SPI_CH_CPOL_L); /* CPOL: active high */
 +
 + /* clear rx and tx channel if set priveously */
 + clrbits_le32(regs-ch_cfg, SPI_RX_CH_ON | SPI_TX_CH_ON);
 +
 + typedef u32 (*spi_copy_func_t)(u32 offset, u32 nblock, u32 dst);

 We do not allow typedefs or variable declarations etc. right in the
 middle of the code.

 I'm surprised that checkpatch does not complain here about not to add
 new typedefs ??
Basically  typedef u32 (*spi_copy_func_t)(u32 offset, u32 nblock, u32
dst); was removed in my original patch.
Will check and remove this from the version of patch set I submit.

 + /* waiting for TX done */
 + while (!(readl(regs-spi_sts)  SPI_ST_TX_DONE))
 + ;

 Potentially infinite loop.  This (and similar code) should always have
 a timeout and appropriate error handling.
Will add a timeout check here


 + /* let us our own function to copy u-boot from SF */

 Please fix the wording of this comment.
Will correct this.

 diff --git a/spl/Makefile b/spl/Makefile
 index b5a8de7..5e7816a 100644
 --- a/spl/Makefile
 +++ b/spl/Makefile
 @@ -94,6 +94,10 @@ LIBS-y += 
 arch/$(ARCH)/cpu/tegra-common/libcputegra-common.o
  LIBS-y += $(CPUDIR)/tegra-common/libtegra-common.o
  endif

 +ifneq ($(CONFIG_EXYNOS4)$(CONFIG_EXYNOS5),)
 +LIBS-y += $(CPUDIR)/s5p-common/libs5p-common.o
 +endif

 This should be done without the ifneq.
This is specific to samsung and currently used only by EXYNOS hence it
was added with a ifneq


 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
 Love all, trust a few.  - William Shakespeare
 ___
 U-Boot mailing list
 U-Boot@lists.denx.de
 http://lists.denx.de/mailman/listinfo/u-boot

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


[U-Boot] Soft_spi questions

2013-05-28 Thread laurent vaudoit
Hello all,

i have integrated soft_spi driver in u-boot, in order to communicate with a
FRAM device, using some GPIO.

I use mode 0 of spi (CPHA=0, CPOL=0).

When i try to communicate with the device, i have a problem, none of my
commands are answered.

After looking signals with scope, i see that if CPHA and CPOL are 0,
there is a rising edge on the clock signal, before data is set on mosi
signal.

So the device get a first byte in an unknown state.

looking at the code, we can see that if CPHA is 0, we put a rising edge on
clock before any data management.

I made work the communication by forcing CPHA to 1 but i think it is not
good way.

Is there something i don't understand?

thank you  in advance for your answer.

Regards

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


Re: [U-Boot] [PATCH] da830: add MMC support

2013-05-28 Thread Tom Rini
On Mon, May 27, 2013 at 03:33:58AM +, Vishwanathrao Badarkhe, Manish wrote:
 Hi Tom
 
 On Fri, May 24, 2013 at 21:31:56, Rini, Tom wrote:
  On Fri, May 24, 2013 at 08:16:14AM +0530, Vishwanathrao Badarkhe, Manish 
  wrote:
  
   Add MMC support for da830 boards in order to perform mmc 
   operations(read,write and erase).
   
   Signed-off-by: Vishwanathrao Badarkhe, Manish manish...@ti.com
  
  Has anything changed between patch postings?  Thanks.
 
 Nothing has changed between postings. I resent same patch because during 
 first posting of this patch I got message as below:
 
 [U-Boot] [PATCH] da830: add MMC support
 Is being held until the list moderator can review it for approval.
 
 Apologize, If you got two versions of same patch. Please ignore first
 version and consider this patch for review.

OK, thanks.  The first copy was approved by the moderators :)  I should
pick this up for the TI tree soon.

-- 
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] Soft_spi questions

2013-05-28 Thread Jagan Teki
HI,

Few little comments.
CCed driver contributed delegate, may be they will help if I am
missing any thing.

On Tue, May 28, 2013 at 6:48 PM, laurent vaudoit
laurent.vaud...@gmail.com wrote:
 Hello all,

 i have integrated soft_spi driver in u-boot, in order to communicate with a
 FRAM device, using some GPIO.

 I use mode 0 of spi (CPHA=0, CPOL=0).

 When i try to communicate with the device, i have a problem, none of my
 commands are answered.

Giving to an understnding how does it works, ignore if you know it already.

usually we have give an mode bit as 0, so the mode bit will check at
driver level to get any change on
clock phase and polarity level(CPHA and CPOL)

u-boot sf probe 0 0 0
last argument assigns the global mode variable.

You checked with mode 0 or 1?

What exactly the issue log, means where it goes wrong?
Does it on spi_xfer?, or spi_claim_bus?


 After looking signals with scope, i see that if CPHA and CPOL are 0,
 there is a rising edge on the clock signal, before data is set on mosi
 signal.

 So the device get a first byte in an unknown state.

 looking at the code, we can see that if CPHA is 0, we put a rising edge on
 clock before any data management.

 I made work the communication by forcing CPHA to 1 but i think it is not
 good way.

What you made by default the CPHA is 0x1, did you make change on the spi_xfer?


Thanks,
Jagan.


 Is there something i don't understand?

 thank you  in advance for your answer.

 Regards

 Laurent Vaudoit

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


Re: [U-Boot] [PATCH v3 0/2] cmd_sf: print message support

2013-05-28 Thread Tom Rini
On Tue, May 28, 2013 at 01:41:44AM +0530, Jagannadha Sutradharudu Teki wrote:

 I agreed that adding new prints will increase the foot-print,
 but here I have removed the verbose messages from sf_flash and add
 on cmd_sf.
 
 These are much essential for showing print messages while user
 using sf erase|write|read commands.
 
 Thanks,
 Jagan.
 
 Jagannadha Sutradharudu Teki (2):
   cmd_sf: Add print mesg for 'sf erase' command
   cmd_sf: Add print mesgs on sf read/write commands
 
  common/cmd_sf.c |   34 ++
  drivers/mtd/spi/spi_flash.c |   10 ++
  2 files changed, 20 insertions(+), 24 deletions(-)

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

-- 
Tom


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


Re: [U-Boot] Soft_spi questions

2013-05-28 Thread laurent vaudoit
Hi,
thanks for your answer.


On Tue, May 28, 2013 at 4:41 PM, Jagan Teki jagannadh.t...@gmail.comwrote:

 HI,

 Few little comments.
 CCed driver contributed delegate, may be they will help if I am
 missing any thing.

 On Tue, May 28, 2013 at 6:48 PM, laurent vaudoit
 laurent.vaud...@gmail.com wrote:
  Hello all,
 
  i have integrated soft_spi driver in u-boot, in order to communicate
 with a
  FRAM device, using some GPIO.
 
  I use mode 0 of spi (CPHA=0, CPOL=0).
 
  When i try to communicate with the device, i have a problem, none of my
  commands are answered.

 Giving to an understnding how does it works, ignore if you know it already.

 usually we have give an mode bit as 0, so the mode bit will check at
 driver level to get any change on
 clock phase and polarity level(CPHA and CPOL)

 u-boot sf probe 0 0 0
 last argument assigns the global mode variable.

 You checked with mode 0 or 1?

 What exactly the issue log, means where it goes wrong?
 Does it on spi_xfer?, or spi_claim_bus?

 My problem is on sspi_xfer function
for testing i use command
sspi 0 (chip select) size data

i have ss-mode to 0 (so CPHA and CPOL is 0)

When i look at the code, i have:
if (!cpha)
SPI_SCL(!cpol);  My problem is this line
SPI_SDA(tmpdout  0x80);
SPI_DELAY;
if (cpha)
SPI_SCL(!cpol);
else
SPI_SCL(cpol);
tmpdin = 1;
tmpdin |= SPI_READ;
tmpdout = 1;
SPI_DELAY;
if (cpha)
SPI_SCL(cpol);




 
  After looking signals with scope, i see that if CPHA and CPOL are 0,
  there is a rising edge on the clock signal, before data is set on mosi
  signal.
 
  So the device get a first byte in an unknown state.
 
  looking at the code, we can see that if CPHA is 0, we put a rising edge
 on
  clock before any data management.
 
  I made work the communication by forcing CPHA to 1 but i think it is not
  good way.

 What you made by default the CPHA is 0x1, did you make change on the
 spi_xfer?


yes for testing, i force local variable cpha to 1 in spi_xfer.

I hope i'm clear,

thanks

Laurent



 Thanks,
 Jagan.

 
  Is there something i don't understand?
 
  thank you  in advance for your answer.
 
  Regards
 
  Laurent Vaudoit
 
  ___
  U-Boot mailing list
  U-Boot@lists.denx.de
  http://lists.denx.de/mailman/listinfo/u-boot

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


Re: [U-Boot] dfu: dfu and UBI Volumes

2013-05-28 Thread Tom Rini
On Tue, May 28, 2013 at 07:50:46AM +0200, Wolfgang Denk wrote:
 Dear Tom,
 
 In message 20130527233735.GZ17119@bill-the-cat you wrote:
  
   Where exactly is this 8 MB limit coming into play?
  
  In buffering the data.  We cannot write a chunk of a file to a
  filesystem and then append to it, we don't have the API today.
 
 Sorry, I still don't get it. Assuming I have a GiB of RAM, why can I
 not load a 256 MiB file to RAM, and then write it to a file system?
 
 I have definitely dealt with images and files bigger than 8 MiB in
 thepast, so I really don't see where any buffer problem could be.

I thought I might not have been clear about where this limit comes from,
after I sent the email.  The problem we have, and this is only for
writing to a filesystem (_not_ writing of a filesystem) is that we do
not have the API for appending to files, only create/overwrite.  So we
must read the whole file into memory, and then write it out.  The DFU
protocol doesn't have (I would swear anyhow) a part where it says I'm
about to send you a blob of X bytes, so we cannot know at the start how
much data is coming our way.

Today we solve this with a statically defined
CONFIG_SYS_DFU_MAX_FILE_SIZE.  Looking at things again, I think this is
buggy right now in that we need to also whack DFU_DATA_BUF_SIZE to also
be that same value.  Going forward, we may be able to switch this to
(and both of these are off the top of my head) a getenv to see how much
space to malloc, or just making it a malloc and adding some compile-time
check to ensure that the malloc area is at least as big as
CONFIG_SYS_DFU_MAX_FILE_SIZE.

-- 
Tom


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


[U-Boot] [PATCH V2] input: simplify key_matrix_decode_fdt()

2013-05-28 Thread Stephen Warren
From: Stephen Warren swar...@nvidia.com

We know the exact property names that the code wants to process. Look
these up directly with fdt_get_property(), rather than iterating over
all properties within the node, and checking each property's name, in
a convoluted fashion, against the expected name.

Signed-off-by: Stephen Warren swar...@nvidia.com
---
V2:
* Add back debug() on missing plain keymap
* Fix error-check after parsing fn keymap

Note: This depends on my previous patch input: fix unaligned access
in key_matrix_decode_fdt(). While to two patches could be squashed
together, I'd prefer them to go in separately, since the former is a
bug-fix that makes the original code work again on ARMv7 at least, and
this patch is an unrelated refactoring.
---
 drivers/input/key_matrix.c |   68 ++--
 1 file changed, 28 insertions(+), 40 deletions(-)

diff --git a/drivers/input/key_matrix.c b/drivers/input/key_matrix.c
index c8b048e..c900e45 100644
--- a/drivers/input/key_matrix.c
+++ b/drivers/input/key_matrix.c
@@ -154,54 +154,42 @@ static uchar *create_keymap(struct key_matrix *config, 
u32 *data, int len,
return map;
 }
 
-int key_matrix_decode_fdt(struct key_matrix *config, const void *blob,
- int node)
+int key_matrix_decode_fdt(struct key_matrix *config, const void *blob, int 
node)
 {
const struct fdt_property *prop;
-   static const char prefix[] = linux,;
-   int plen = sizeof(prefix) - 1;
-   int offset;
-
-   /* Check each property name for ones that we understand */
-   for (offset = fdt_first_property_offset(blob, node);
- offset  0;
- offset = fdt_next_property_offset(blob, offset)) {
-   const char *name;
-   int len;
-
-   prop = fdt_get_property_by_offset(blob, offset, NULL);
-   name = fdt_string(blob, fdt32_to_cpu(prop-nameoff));
-   len = strlen(name);
-
-   /* Name needs to match 1,typekeymap */
-   debug(%s: property '%s'\n, __func__, name);
-   if (strncmp(name, prefix, plen) ||
-   len  plen + 6 ||
-   strcmp(name + len - 6, keymap))
-   continue;
+   int proplen;
+   uchar *plain_keycode;
 
-   len -= plen + 6;
-   if (len == 0) {
-   config-plain_keycode = create_keymap(config,
-   (u32 *)prop-data, fdt32_to_cpu(prop-len),
-   KEY_FN, config-fn_pos);
-   } else if (0 == strncmp(name + plen, fn-, len)) {
-   config-fn_keycode = create_keymap(config,
-   (u32 *)prop-data, fdt32_to_cpu(prop-len),
-   -1, NULL);
-   } else {
-   debug(%s: unrecognised property '%s'\n, __func__,
- name);
-   }
+   prop = fdt_get_property(blob, node, linux,keymap, proplen);
+   /* Basic keymap is required */
+   if (!prop) {
+   debug(%s: cannot find keycode-plain map\n, __func__);
+   return -1;
}
-   debug(%s: Decoded key maps %p, %p from fdt\n, __func__,
- config-plain_keycode, config-fn_keycode);
 
-   if (!config-plain_keycode) {
-   debug(%s: cannot find keycode-plain map\n, __func__);
+   plain_keycode = create_keymap(config, (u32 *)prop-data,
+   proplen, KEY_FN, config-fn_pos);
+   config-plain_keycode = plain_keycode;
+   /* Conversion error - fail */
+   if (!config-plain_keycode)
+   return -1;
+
+   prop = fdt_get_property(blob, node, linux,fn-keymap, proplen);
+   /* fn keymap is optional */
+   if (!prop)
+   goto done;
+
+   config-fn_keycode = create_keymap(config, (u32 *)prop-data,
+   proplen, -1, NULL);
+   /* Conversion error - fail */
+   if (!config-fn_keycode) {
+   free(plain_keycode);
return -1;
}
 
+done:
+   debug(%s: Decoded key maps %p, %p from fdt\n, __func__,
+ config-plain_keycode, config-fn_keycode);
return 0;
 }
 
-- 
1.7.10.4

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


Re: [U-Boot] dfu: dfu and UBI Volumes

2013-05-28 Thread Pantelis Antoniou
Hi Tom,

On May 28, 2013, at 6:01 PM, Tom Rini wrote:

 On Tue, May 28, 2013 at 07:50:46AM +0200, Wolfgang Denk wrote:
 Dear Tom,
 
 In message 20130527233735.GZ17119@bill-the-cat you wrote:
 
 Where exactly is this 8 MB limit coming into play?
 
 In buffering the data.  We cannot write a chunk of a file to a
 filesystem and then append to it, we don't have the API today.
 
 Sorry, I still don't get it. Assuming I have a GiB of RAM, why can I
 not load a 256 MiB file to RAM, and then write it to a file system?
 
 I have definitely dealt with images and files bigger than 8 MiB in
 thepast, so I really don't see where any buffer problem could be.
 
 I thought I might not have been clear about where this limit comes from,
 after I sent the email.  The problem we have, and this is only for
 writing to a filesystem (_not_ writing of a filesystem) is that we do
 not have the API for appending to files, only create/overwrite.  So we
 must read the whole file into memory, and then write it out.  The DFU
 protocol doesn't have (I would swear anyhow) a part where it says I'm
 about to send you a blob of X bytes, so we cannot know at the start how
 much data is coming our way.
 
 Today we solve this with a statically defined
 CONFIG_SYS_DFU_MAX_FILE_SIZE.  Looking at things again, I think this is
 buggy right now in that we need to also whack DFU_DATA_BUF_SIZE to also
 be that same value.  Going forward, we may be able to switch this to
 (and both of these are off the top of my head) a getenv to see how much
 space to malloc, or just making it a malloc and adding some compile-time
 check to ensure that the malloc area is at least as big as
 CONFIG_SYS_DFU_MAX_FILE_SIZE.
 

Correct, the DFU protocol doesn't have a method to inform you before hand
about the size of the transfer about to happen.

The only possible solution I see at this point is to have an environment
variable, i.e. dfubuf that controls the size of the buffer.

Upon start of a dfu transfer we can allocate the buffer, and do our
thing.

 -- 
 Tom

Regards

-- Pantelis

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


Re: [U-Boot] powerpc/mpc8xxx failed to compile: operand out of range

2013-05-28 Thread Jérôme Arzel


On 05/27/2013 11:25:17 AM, Jérôme Arzel wrote:
 
 On 05/24/2013 10:13:55 PM, Scott Wood wrote:
  
  On 05/23/2013 04:52:26 AM, Jérôme Arzel wrote:
   Hi all,
   
   I have an issue when I compile U-Boot for my target machine
   (P1022DS,
   36-bit).
   Here is the error message:
   
   release.S: Assembler messages:
   release.S:154: Error: operand out of range (0xf144 is not
   between
   0x and 0x)
   release.S:286: Error: operand out of range (0xf144 is not
   between
   0x and 0x)
   release.S:311: Error: operand out of range (0xf140 is not
   between
   0x and 0x)
   
   (release.S is located to arch/powerpc/cpu/mpc85xx/release.S)
   
   And here is the code for the first error (line 150):
   
   #define toreset(x) (x - __secondary_start_page + 0xf000)
   
   /* get our PIR to figure out our table entry */
   lis r3,toreset(__spin_table_addr)@h
   ori r3,r3,toreset(__spin_table_addr)@l
   
   I don't really know why it doesn't work, but I think
   that ori is inappropried, the immediate value must be a 16-bit
   value.
  
  The @l means take the low 16 bits of the constant.  Likewise, the
  @h
  in
  the lis takes the upper 16 bits.
  
  Could you try to see what that instruction looks like after the
  preprocessor stage (i.e. use -E rather than -c in gcc)?
  
 
 OK, I tried and unsurprisingly it's:
 
  lis 3,(__spin_table_addr - __secondary_start_page + 0xf000)@h
  ori 3,3,(__spin_table_addr - __secondary_start_page + 0xf000)@l
  lwz 3,0(3)
 
 If the @l takes the low 16 bits of
 (__spin_table_addr - __secondary_start_page + 0xf000), so
 the immediate value should not be 0xf144, but 0xf144.
 The error is maybe in GCC...
 
 
 Jérôme

In fact my tests was in a virtual machine.
I restarted the compilation of GCC from scratch, directly
on my machine (x86_64) and the result is slightly different,
but almost the same:

powerpc-e500v2-linux-gnuspe-gcc   -D__ASSEMBLY__ -g  -Os   \
 -fpic -mrelocatable -ffunction-sections -fdata-sections \
 -meabi -D__KERNEL__ -DCONFIG_SYS_TEXT_BASE=0x1100 \
 -I/home/arzel/u-boot/u-boot-git/P1022DS_SDCARD/include2 \
 -I/home/arzel/u-boot/u-boot-git/P1022DS_SDCARD/include \
 -I/home/arzel/u-boot/u-boot-git/include -fno-builtin \
 -ffreestanding -nostdinc \
 -isystem /home/arzel/cross_compile/tools/lib/gcc/powerpc-
e500v2-linux-gnuspe/4.8.0/include \
 -pipe  -DCONFIG_PPC -D__powerpc__ -ffixed-r2 -Wa,-me500 \
 -msoft-float -mno-string -mspe=yes -mno-spe   \
 -o /home/arzel/u-boot/u-boot-git/P1022DS_SDCARD/
arch/powerpc/cpu/mpc85xx/release.o release.S -c

release.S: Assembler messages:
release.S:153: Error: value of 4294963524 too large for field 
of 2 bytes at 170
release.S:154: Error: operand out of range (0xf144 
is not between 0x and 0x)
release.S:154: Error: value of 4294963524 too large for field 
of 2 bytes at 174
release.S:282: Error: value of 4294963524 too large for field 
of 2 bytes at 206
release.S:283: Error: operand out of range (0xf144 
is not between 0x and 0x)
release.S:283: Error: value of 4294963524 too large for field 
of 2 bytes at 210
release.S:307: Error: value of 4294963520 too large for field 
of 2 bytes at 278
release.S:308: Error: operand out of range (0xf140 
is not between 0x and 0x)
release.S:308: Error: value of 4294963520 too large for field 
of 2 bytes at 282

By curiosity, I tried to replace toreset(__spin_table_addr)
by 0xf144 and it works... but it's not a
solution.

I use the last version of U-Boot from the git branch 'master'.

Here is my configuration for GCC:

export PATH=/home/arzel/cross_compile/tools/bin:$PATH

Binutils (v2.23.2)

configure --target=powerpc-e500v2-linux-gnuspe \
  --prefix=/home/arzel/cross_compile/tools \
  --with-sysroot=/home/home/arzel/cross_compile/sysroot \
  --disable-nls --disable-multilib

make all
make install

GCC (v4.8.0)

configure --target=powerpc-e500v2-linux-gnuspe \
  --prefix=/home/arzel/cross_compile/tools \
  --with-sysroot=/home/arzel/cross_compile/sysroot \
  --without-headers --with-newlib --disable-shared \
  --disable-threads --enable-languages=c \
  --disable-decimal-float --disable-__cxa_atexit \
  --disable-libquadmath --disable-libssp \
  --disable-libgomp --disable-libmudflap \
  --disable-nls --disable-multilib \
  --enable-e500_double --with-long-double-128 \
  --with-cpu=8548

make all-host all-target-libgcc
make install-host install-target-libgcc

Normally, I can build U-Boot with this small GCC.

Jérôme
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] dfu: dfu and UBI Volumes

2013-05-28 Thread Tom Rini
On Tue, May 28, 2013 at 07:55:03AM +0200, Wolfgang Denk wrote:
 Dear Heiko,
 
 In message 51a427a8.8090...@denx.de you wrote:
 
   Where exactly is this 8 MB limit coming into play?
  
  You find this in drivers/dfu/dfu.c:
  
  static unsigned char __aligned(CONFIG_SYS_CACHELINE_SIZE)
 dfu_buf[DFU_DATA_BUF_SIZE];
 
 Ah, so it is a DFU restriction!
[snip]
  drivers/dfu/dfu_mmc.c use (another?, why?) buffer:
  
  static unsigned char __aligned(CONFIG_SYS_CACHELINE_SIZE)
  dfu_file_buf[CONFIG_SYS_DFU_MAX_FILE_SIZE];
 ...
  and use this buffer for not raw partitions ... and this buffer
  gets flushed, only if the complete file is transfered, as the
  README states:
  
  CONFIG_SYS_DFU_MAX_FILE_SIZE
  When updating files rather than the raw storage device,
  we use a static buffer to copy the file into and then write
  the buffer once we've been given the whole file.  Define
  this to the maximum filesize (in bytes) for the buffer.
  Default is 4 MiB if undefined.
 
 This makes very little sense to me.  Why do we need another (and even
 smaller) buffer when we already have one?

Per my other email, the intention and implementation didn't quite
match-up.  The intent of the README should be (but isn't) reflected) in
the code.  And perhaps we can come up with something better than a big
static allocation.  Perhaps.

-- 
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] dfu: dfu and UBI Volumes

2013-05-28 Thread Tom Rini
On Tue, May 28, 2013 at 08:24:06AM +0200, Heiko Schocher wrote:
 Hello Wolfgang,
 
 Am 28.05.2013 07:58, schrieb Wolfgang Denk:
  Dear Heiko,
  
  In message 51a42ccd.1020...@denx.de you wrote:
 
  I would imagine, but testing and implementation might show a better way,
  we do UBI as name ubi ubiN volume-name, ie:
  rootfs ubi ubi0 rootfs
  user ubi ubi0 user-data
  and so forth, and augment dfu_nand.c with UBI knowledge, ala dfu_mmc and
  fat/ext knowledge.
 
  Yes, I think, thats the way to go ...
  
  I doubt that dfu_nand.c is the right place for this.  What if I start
  using DFU on NOR flash?  The decisions which device type (NAND, MMC,
  NOR, USB mass storage, ...) to habdle on one side, and which partition
  type / image type (raw, UBI volume, file, ...) on the other side are
  fully orthogonal to each other.  They should be handled by independent
  code, and not one of them repeated for all implementations of the
  other.
 
 Yes, exactly ...

We can see about what re-org makes sense once we've got another
implementation here.  We might be able to share the filesystem-based
write code, but that in part might cause some screams since it'll depend
on our continued (ab)use of run_command.  The device-specific code does
end up being the device-specific API part.   Unless we're adding ubifs
in addition to ubi volume support to DFU, we don't have real shared
filesystem stuff, yet.

-- 
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] dfu: dfu and UBI Volumes

2013-05-28 Thread Benoît Thébaudeau
Dear Pantelis Antoniou,

On Tuesday, May 28, 2013 5:05:12 PM, Pantelis Antoniou wrote:
 Hi Tom,
 
 On May 28, 2013, at 6:01 PM, Tom Rini wrote:
 
  On Tue, May 28, 2013 at 07:50:46AM +0200, Wolfgang Denk wrote:
  Dear Tom,
  
  In message 20130527233735.GZ17119@bill-the-cat you wrote:
  
  Where exactly is this 8 MB limit coming into play?
  
  In buffering the data.  We cannot write a chunk of a file to a
  filesystem and then append to it, we don't have the API today.
  
  Sorry, I still don't get it. Assuming I have a GiB of RAM, why can I
  not load a 256 MiB file to RAM, and then write it to a file system?
  
  I have definitely dealt with images and files bigger than 8 MiB in
  thepast, so I really don't see where any buffer problem could be.
  
  I thought I might not have been clear about where this limit comes from,
  after I sent the email.  The problem we have, and this is only for
  writing to a filesystem (_not_ writing of a filesystem) is that we do
  not have the API for appending to files, only create/overwrite.  So we
  must read the whole file into memory, and then write it out.  The DFU
  protocol doesn't have (I would swear anyhow) a part where it says I'm
  about to send you a blob of X bytes, so we cannot know at the start how
  much data is coming our way.
  
  Today we solve this with a statically defined
  CONFIG_SYS_DFU_MAX_FILE_SIZE.  Looking at things again, I think this is
  buggy right now in that we need to also whack DFU_DATA_BUF_SIZE to also
  be that same value.  Going forward, we may be able to switch this to
  (and both of these are off the top of my head) a getenv to see how much
  space to malloc, or just making it a malloc and adding some compile-time
  check to ensure that the malloc area is at least as big as
  CONFIG_SYS_DFU_MAX_FILE_SIZE.
  
 
 Correct, the DFU protocol doesn't have a method to inform you before hand
 about the size of the transfer about to happen.
 
 The only possible solution I see at this point is to have an environment
 variable, i.e. dfubuf that controls the size of the buffer.
 
 Upon start of a dfu transfer we can allocate the buffer, and do our
 thing.

I don't know the details of the DFU implementation in U-Boot, but the
specification leaves the choice between programming the firmware on-the-fly
during the download, and later during the manifestation phase (or a mix of
both). Hence, there is not need for a global firmware buffer if U-Boot goes for
the on-the-fly programming strategy. The only buffer constraint would be
wTransferSize (chosen by U-Boot for the control endpoint) in that case. See
7. Manifestation Phase on page 26 here:
http://www.usb.org/developers/devclass_docs/DFU_1.1.pdf

Of course this can't yet apply to writing files on file systems since the
current API in U-Boot misses the append feature, but this could be applied to
program raw memory partitions, including UBI images.

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


Re: [U-Boot] dfu: dfu and UBI Volumes

2013-05-28 Thread Pantelis Antoniou
Hi Benoît

On May 28, 2013, at 7:31 PM, Benoît Thébaudeau wrote:

 Dear Pantelis Antoniou,
 
 On Tuesday, May 28, 2013 5:05:12 PM, Pantelis Antoniou wrote:
 Hi Tom,
 
 On May 28, 2013, at 6:01 PM, Tom Rini wrote:
 
 On Tue, May 28, 2013 at 07:50:46AM +0200, Wolfgang Denk wrote:
 Dear Tom,
 
 In message 20130527233735.GZ17119@bill-the-cat you wrote:
 
 Where exactly is this 8 MB limit coming into play?
 
 In buffering the data.  We cannot write a chunk of a file to a
 filesystem and then append to it, we don't have the API today.
 
 Sorry, I still don't get it. Assuming I have a GiB of RAM, why can I
 not load a 256 MiB file to RAM, and then write it to a file system?
 
 I have definitely dealt with images and files bigger than 8 MiB in
 thepast, so I really don't see where any buffer problem could be.
 
 I thought I might not have been clear about where this limit comes from,
 after I sent the email.  The problem we have, and this is only for
 writing to a filesystem (_not_ writing of a filesystem) is that we do
 not have the API for appending to files, only create/overwrite.  So we
 must read the whole file into memory, and then write it out.  The DFU
 protocol doesn't have (I would swear anyhow) a part where it says I'm
 about to send you a blob of X bytes, so we cannot know at the start how
 much data is coming our way.
 
 Today we solve this with a statically defined
 CONFIG_SYS_DFU_MAX_FILE_SIZE.  Looking at things again, I think this is
 buggy right now in that we need to also whack DFU_DATA_BUF_SIZE to also
 be that same value.  Going forward, we may be able to switch this to
 (and both of these are off the top of my head) a getenv to see how much
 space to malloc, or just making it a malloc and adding some compile-time
 check to ensure that the malloc area is at least as big as
 CONFIG_SYS_DFU_MAX_FILE_SIZE.
 
 
 Correct, the DFU protocol doesn't have a method to inform you before hand
 about the size of the transfer about to happen.
 
 The only possible solution I see at this point is to have an environment
 variable, i.e. dfubuf that controls the size of the buffer.
 
 Upon start of a dfu transfer we can allocate the buffer, and do our
 thing.
 
 I don't know the details of the DFU implementation in U-Boot, but the
 specification leaves the choice between programming the firmware on-the-fly
 during the download, and later during the manifestation phase (or a mix of
 both). Hence, there is not need for a global firmware buffer if U-Boot goes 
 for
 the on-the-fly programming strategy. The only buffer constraint would be
 wTransferSize (chosen by U-Boot for the control endpoint) in that case. See
 7. Manifestation Phase on page 26 here:
 http://www.usb.org/developers/devclass_docs/DFU_1.1.pdf
 

The problem is not DFU TBH, it's that since we don't have an option to append
to a file, we have to have the whole file transferred in RAM and written in
one go. The raw medium dfu methods in u-boot don't have a problem.

 Of course this can't yet apply to writing files on file systems since the
 current API in U-Boot misses the append feature, but this could be applied to
 program raw memory partitions, including UBI images.
 

It already happens for raw memory partitions, it's the UBI images being 
discussed.
 Best regards,
 Benoît

Regards

-- Pantelis

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


Re: [U-Boot] dfu: dfu and UBI Volumes

2013-05-28 Thread Benoît Thébaudeau
Hi Pantelis,

On Tuesday, May 28, 2013 6:43:06 PM, Pantelis Antoniou wrote:
 Hi Benoît
 
 On May 28, 2013, at 7:31 PM, Benoît Thébaudeau wrote:
 
  Dear Pantelis Antoniou,
  
  On Tuesday, May 28, 2013 5:05:12 PM, Pantelis Antoniou wrote:
  Hi Tom,
  
  On May 28, 2013, at 6:01 PM, Tom Rini wrote:
  
  On Tue, May 28, 2013 at 07:50:46AM +0200, Wolfgang Denk wrote:
  Dear Tom,
  
  In message 20130527233735.GZ17119@bill-the-cat you wrote:
  
  Where exactly is this 8 MB limit coming into play?
  
  In buffering the data.  We cannot write a chunk of a file to a
  filesystem and then append to it, we don't have the API today.
  
  Sorry, I still don't get it. Assuming I have a GiB of RAM, why can I
  not load a 256 MiB file to RAM, and then write it to a file system?
  
  I have definitely dealt with images and files bigger than 8 MiB in
  thepast, so I really don't see where any buffer problem could be.
  
  I thought I might not have been clear about where this limit comes from,
  after I sent the email.  The problem we have, and this is only for
  writing to a filesystem (_not_ writing of a filesystem) is that we do
  not have the API for appending to files, only create/overwrite.  So we
  must read the whole file into memory, and then write it out.  The DFU
  protocol doesn't have (I would swear anyhow) a part where it says I'm
  about to send you a blob of X bytes, so we cannot know at the start how
  much data is coming our way.
  
  Today we solve this with a statically defined
  CONFIG_SYS_DFU_MAX_FILE_SIZE.  Looking at things again, I think this is
  buggy right now in that we need to also whack DFU_DATA_BUF_SIZE to also
  be that same value.  Going forward, we may be able to switch this to
  (and both of these are off the top of my head) a getenv to see how much
  space to malloc, or just making it a malloc and adding some compile-time
  check to ensure that the malloc area is at least as big as
  CONFIG_SYS_DFU_MAX_FILE_SIZE.
  
  
  Correct, the DFU protocol doesn't have a method to inform you before hand
  about the size of the transfer about to happen.
  
  The only possible solution I see at this point is to have an environment
  variable, i.e. dfubuf that controls the size of the buffer.
  
  Upon start of a dfu transfer we can allocate the buffer, and do our
  thing.
  
  I don't know the details of the DFU implementation in U-Boot, but the
  specification leaves the choice between programming the firmware on-the-fly
  during the download, and later during the manifestation phase (or a mix of
  both). Hence, there is not need for a global firmware buffer if U-Boot goes
  for
  the on-the-fly programming strategy. The only buffer constraint would be
  wTransferSize (chosen by U-Boot for the control endpoint) in that case. See
  7. Manifestation Phase on page 26 here:
  http://www.usb.org/developers/devclass_docs/DFU_1.1.pdf
  
 
 The problem is not DFU TBH, it's that since we don't have an option to append
 to a file, we have to have the whole file transferred in RAM and written in
 one go. The raw medium dfu methods in u-boot don't have a problem.
 
  Of course this can't yet apply to writing files on file systems since the
  current API in U-Boot misses the append feature, but this could be applied
  to
  program raw memory partitions, including UBI images.
  
 
 It already happens for raw memory partitions, it's the UBI images being
 discussed.

But what does appending to a file has to do with programming a UBI image, which
is a memory partition containing a whole file system? This is what I don't get
in this discussion. Is it because of a restriction of the DFU API in U-Boot?

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


Re: [U-Boot] dfu: dfu and UBI Volumes

2013-05-28 Thread Pantelis Antoniou
Hi 
On May 28, 2013, at 7:43 PM, Benoît Thébaudeau wrote:

 Hi Pantelis,
 
 On Tuesday, May 28, 2013 6:43:06 PM, Pantelis Antoniou wrote:
 Hi Benoît
 
 On May 28, 2013, at 7:31 PM, Benoît Thébaudeau wrote:
 
 Dear Pantelis Antoniou,
 
 On Tuesday, May 28, 2013 5:05:12 PM, Pantelis Antoniou wrote:
 Hi Tom,
 
 On May 28, 2013, at 6:01 PM, Tom Rini wrote:
 
 On Tue, May 28, 2013 at 07:50:46AM +0200, Wolfgang Denk wrote:
 Dear Tom,
 
 In message 20130527233735.GZ17119@bill-the-cat you wrote:
 
 Where exactly is this 8 MB limit coming into play?
 
 In buffering the data.  We cannot write a chunk of a file to a
 filesystem and then append to it, we don't have the API today.
 
 Sorry, I still don't get it. Assuming I have a GiB of RAM, why can I
 not load a 256 MiB file to RAM, and then write it to a file system?
 
 I have definitely dealt with images and files bigger than 8 MiB in
 thepast, so I really don't see where any buffer problem could be.
 
 I thought I might not have been clear about where this limit comes from,
 after I sent the email.  The problem we have, and this is only for
 writing to a filesystem (_not_ writing of a filesystem) is that we do
 not have the API for appending to files, only create/overwrite.  So we
 must read the whole file into memory, and then write it out.  The DFU
 protocol doesn't have (I would swear anyhow) a part where it says I'm
 about to send you a blob of X bytes, so we cannot know at the start how
 much data is coming our way.
 
 Today we solve this with a statically defined
 CONFIG_SYS_DFU_MAX_FILE_SIZE.  Looking at things again, I think this is
 buggy right now in that we need to also whack DFU_DATA_BUF_SIZE to also
 be that same value.  Going forward, we may be able to switch this to
 (and both of these are off the top of my head) a getenv to see how much
 space to malloc, or just making it a malloc and adding some compile-time
 check to ensure that the malloc area is at least as big as
 CONFIG_SYS_DFU_MAX_FILE_SIZE.
 
 
 Correct, the DFU protocol doesn't have a method to inform you before hand
 about the size of the transfer about to happen.
 
 The only possible solution I see at this point is to have an environment
 variable, i.e. dfubuf that controls the size of the buffer.
 
 Upon start of a dfu transfer we can allocate the buffer, and do our
 thing.
 
 I don't know the details of the DFU implementation in U-Boot, but the
 specification leaves the choice between programming the firmware on-the-fly
 during the download, and later during the manifestation phase (or a mix of
 both). Hence, there is not need for a global firmware buffer if U-Boot goes
 for
 the on-the-fly programming strategy. The only buffer constraint would be
 wTransferSize (chosen by U-Boot for the control endpoint) in that case. See
 7. Manifestation Phase on page 26 here:
 http://www.usb.org/developers/devclass_docs/DFU_1.1.pdf
 
 
 The problem is not DFU TBH, it's that since we don't have an option to append
 to a file, we have to have the whole file transferred in RAM and written in
 one go. The raw medium dfu methods in u-boot don't have a problem.
 
 Of course this can't yet apply to writing files on file systems since the
 current API in U-Boot misses the append feature, but this could be applied
 to
 program raw memory partitions, including UBI images.
 
 
 It already happens for raw memory partitions, it's the UBI images being
 discussed.
 
 But what does appending to a file has to do with programming a UBI image, 
 which
 is a memory partition containing a whole file system? This is what I don't get
 in this discussion. Is it because of a restriction of the DFU API in U-Boot?
 

Don't expect a discussion on a mailing list to stay on topic for long :)
We sort of drifted from UBI to the fixed sized buffer.

 Best regards,
 Benoît

Regards

-- Pantelis

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


Re: [U-Boot] [PATCH v2 1/6] arm: ensure u-boot only uses relative relocations

2013-05-28 Thread Benoît Thébaudeau
Hi Albert,

On Tuesday, May 28, 2013 9:01:46 AM, Albert ARIBAUD wrote:
 Add a Makefile target ('checkarmreloc') which
 fails of the ELF binary contains relocation records
^
if

Sorry to have missed that in my review of v1.

 of types other than R_ARM_RELATIVE.

The rest of the patch is OK.

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


Re: [U-Boot] [PATCH v2 4/6] arm: make __image_copy_{start, end} compiler-generated

2013-05-28 Thread Benoît Thébaudeau
Hi Albert,

On Tuesday, May 28, 2013 9:01:49 AM, Albert ARIBAUD wrote:
 This change is only done where needed: some linker
 scripts may contain __image_copy_{start,end} yet
 remain unchanged.
 
 Also, __image_copy_end needs its own section; putting
 it in relocation sections changes their flags and makes
 relocation breaks.
 ^
 break

The rest of the patch is OK.

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


Re: [U-Boot] dfu: dfu and UBI Volumes

2013-05-28 Thread Tom Rini
On Tue, May 28, 2013 at 06:31:41PM +0200, Beno??t Th??baudeau wrote:

[snip]
 Of course this can't yet apply to writing files on file systems since the
 current API in U-Boot misses the append feature, but this could be applied to
 program raw memory partitions, including UBI images.

Correct.  We can write a whole UBI image, today, of NAND size,
regardless of DDR size.  But modifying UBI volumes (so UBIFS or your
kernel in UBI or ...) will depend on what the UBI API provides us today.
Modifying files on UBIFS (say replacing the kernel that's in UBIFS
rather than a UBI volume itself) is another wrinkle, due to a lack of
filesystem append.

-- 
Tom


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


Re: [U-Boot] [PATCH v2 1/6] arm: ensure u-boot only uses relative relocations

2013-05-28 Thread Albert ARIBAUD
Hi Benoît,

On Tue, 28 May 2013 19:04:23 +0200 (CEST), Benoît Thébaudeau
benoit.thebaud...@advansee.com wrote:

 Hi Albert,
 
 On Tuesday, May 28, 2013 9:01:46 AM, Albert ARIBAUD wrote:
  Add a Makefile target ('checkarmreloc') which
  fails of the ELF binary contains relocation records
 ^
 if

(and)

  Also, __image_copy_end needs its own section; putting
  it in relocation sections changes their flags and makes
  relocation breaks.
  ^
  break

 Sorry to have missed that in my review of v1.

Never mind: I'd missed them too. :)

I'll wait a bit for other comments if any, then send out a fixed V3.

 Best regards,
 Benoît

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


Re: [U-Boot] [RFC PATCH 4/7] Add Kconfig scripts and related material

2013-05-28 Thread Tom Rini
On Tue, May 28, 2013 at 10:31:59AM +0900, Masahiro Yamada wrote:

[snip]
 So, my first request is that this commit should just import
 scripts as they are in Linux Kernel (plus renaming from
 Makefile to Makefile.kbuild)
 
 All modification you make for U-Boot should be pushed into the
 next commit Adjust Kconfig scripts for use by U-Boot.
 
 I think this would be helpful for reviewers to track which lines
 are changed.
 
 
 The seconde request is subject of personal preference but I like
 the white spaces to be kept untouched when importing files
 from another project.
 
 Although I was not sure they were corrected by you,
 I noticed some white space errors diffs when
 comparing your patches with Linux Kernel makefiles.
 The reason is, as you mentioned in commit log, to minimise conflicts
 with future Kbuild updates.

Agreed on both points.

-- 
Tom


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


[U-Boot] [PATCH] mmc: fsl_esdhc: Fix hang after 'save' command

2013-05-28 Thread Fabio Estevam
Since commit 48e0b2bd (powerpc/esdhc: Correct judgement for DATA PIO mode) 
we see mx6 systems to hang after doing a 'save' command.

Revert this commit since the original 'ifdef' logic from 7b43db92 
(drivers/mmc/fsl_esdhc.c: fix compiler warnings) was the correct one.

Reported-by: Tapani Utriainen tap...@technexion.com
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
 drivers/mmc/fsl_esdhc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
index 861f4b9..ec01795 100644
--- a/drivers/mmc/fsl_esdhc.c
+++ b/drivers/mmc/fsl_esdhc.c
@@ -178,7 +178,7 @@ static int esdhc_setup_data(struct mmc *mmc, struct 
mmc_data *data)
int timeout;
struct fsl_esdhc_cfg *cfg = (struct fsl_esdhc_cfg *)mmc-priv;
struct fsl_esdhc *regs = (struct fsl_esdhc *)cfg-esdhc_base;
-#ifdef CONFIG_SYS_FSL_ESDHC_USE_PIO
+#ifndef CONFIG_SYS_FSL_ESDHC_USE_PIO
uint wml_value;
 
wml_value = data-blocksize/4;
-- 
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] mmc: fsl_esdhc: Fix hang after 'save' command

2013-05-28 Thread Otavio Salvador
On Tue, May 28, 2013 at 3:09 PM, Fabio Estevam
fabio.este...@freescale.comwrote:

 Since commit 48e0b2bd (powerpc/esdhc: Correct judgement for DATA PIO mode)
 we see mx6 systems to hang after doing a 'save' command.

 Revert this commit since the original 'ifdef' logic from 7b43db92
 (drivers/mmc/fsl_esdhc.c: fix compiler warnings) was the correct one.

 Reported-by: Tapani Utriainen tap...@technexion.com
 Signed-off-by: Fabio Estevam fabio.este...@freescale.com


This seem to affect 'master' branch, not 'imx' tree. Is that correct?

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


Re: [U-Boot] [PATCH] mmc: fsl_esdhc: Fix hang after 'save' command

2013-05-28 Thread Fabio Estevam
On Tue, May 28, 2013 at 3:31 PM, Otavio Salvador
ota...@ossystems.com.br wrote:

 This seem to affect 'master' branch, not 'imx' tree. Is that correct?

Yes, the offending commit is in master, but not on u-boot-imx branch.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] SF: Add Spansion S25FL064P IDs

2013-05-28 Thread Marek Vasut
Dear Jagan Teki,

 On 28-08-2012 20:43, Marek Vasut wrote:
  This is a S25FL064A successor. It supports up to 104MHz bus
  speed.
  
  Signed-off-by: Marek Vasut ma...@denx.de
  Cc: Heiko Schocher h...@denx.de
  Cc: Mike Frysinger vap...@gentoo.org
  Cc: Scott Wood scottw...@freescale.com
  Cc: Wolfgang Denk w...@denx.de
  
  ---
  drivers/mtd/spi/spansion.c |7 +++
  
1 file changed, 7 insertions(+)
  
  diff --git a/drivers/mtd/spi/spansion.c b/drivers/mtd/spi/spansion.c
  index 9a114ac..faf4414 100644
  --- a/drivers/mtd/spi/spansion.c
  +++ b/drivers/mtd/spi/spansion.c
  @@ -90,6 +90,13 @@ static const struct spansion_spi_flash_params
  spansion_spi_flash_table[] = {
  
  .name = S25FL032P,
  
  },
  {
  
  +   .idcode1 = 0x0216,
  +   .idcode2 = 0x4d00,
  +   .pages_per_sector = 256,
  +   .nr_sectors = 128,
  +   .name = S25FL064P,
  +   },
  +   {
  
  .idcode1 = 0x2018,
  .idcode2 = 0x4d01,
  .pages_per_sector = 256,
 
 Applied to u-boot-spi/master

Wow, do we have a new custodian? In any case, nice to meet you ;-)

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


Re: [U-Boot] [PATCH v4 1/7] arm: vf610: Add IOMUX support for Vybrid VF610

2013-05-28 Thread Benoît Thébaudeau
Hi Alison,

On Tuesday, May 28, 2013 10:55:41 AM, Alison Wang wrote:
 This patch adds the IOMUX support for Vybrid VF610 platform.
 
 There is a little difference for IOMUXC module between VF610 and i.MX
 platform, the muxmode and pad configuration share one 32bit register on
 VF610, but they are two independent registers on I.MX platform. A
 CONFIG_IOMUX_SHARE_CONFIG_REG was introduced to fit this difference.
 
 Signed-off-by: Alison Wang b18...@freescale.com

[...]

 diff --git a/arch/arm/imx-common/iomux-v3.c b/arch/arm/imx-common/iomux-v3.c
 index 7fe5ce7..35880c7 100644
 --- a/arch/arm/imx-common/iomux-v3.c
 +++ b/arch/arm/imx-common/iomux-v3.c
 @@ -48,8 +48,14 @@ void imx_iomux_v3_setup_pad(iomux_v3_cfg_t pad)
   if (sel_input_ofs)
   __raw_writel(sel_input, base + sel_input_ofs);
  
 +#ifdef CONFIG_IOMUX_SHARE_CONF_REG

Where is this one defined? I don't see it in include/configs/vf610twr.h.

Why not use #ifdef CONFIG_VF610 since this is a platform-dependent code, and
not a board-specific config option?

 + if (!(pad_ctrl  NO_PAD_CTRL))
 + __raw_writel((mux_mode  PAD_MUX_MODE_SHIFT) | pad_ctrl,
 + base + pad_ctrl_ofs);
 +#else
   if (!(pad_ctrl  NO_PAD_CTRL)  pad_ctrl_ofs)
   __raw_writel(pad_ctrl, base + pad_ctrl_ofs);
 +#endif
  }
  
  void imx_iomux_v3_setup_multiple_pads(iomux_v3_cfg_t const *pad_list,

[...]

Apart from that, this patch is OK.

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


[U-Boot] [PATCH] mx27: add function enable_caches

2013-05-28 Thread Philippe Reynes
Signed-off-by: Philippe Reynes trem...@yahoo.fr
---
 arch/arm/cpu/arm926ejs/mx27/generic.c |6 ++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/arch/arm/cpu/arm926ejs/mx27/generic.c 
b/arch/arm/cpu/arm926ejs/mx27/generic.c
index 41bb84b..4239fa0 100644
--- a/arch/arm/cpu/arm926ejs/mx27/generic.c
+++ b/arch/arm/cpu/arm926ejs/mx27/generic.c
@@ -380,3 +380,9 @@ void mx27_sd2_init_pins(void)
 
 }
 #endif /* CONFIG_MXC_MMC */
+
+void enable_caches(void)
+{
+   /* Enable D-cache. I-cache is already enabled in start.S */
+   dcache_enable();
+}
-- 
1.7.4.4

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


[U-Boot] [PATCH] mx27: add i2c clock

2013-05-28 Thread Philippe Reynes
Signed-off-by: Eric Jarrige eric.jarr...@armadeus.org
---
 arch/arm/cpu/arm926ejs/mx27/generic.c  |2 ++
 arch/arm/include/asm/arch-mx27/clock.h |1 +
 2 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/arch/arm/cpu/arm926ejs/mx27/generic.c 
b/arch/arm/cpu/arm926ejs/mx27/generic.c
index 4239fa0..25e1250 100644
--- a/arch/arm/cpu/arm926ejs/mx27/generic.c
+++ b/arch/arm/cpu/arm926ejs/mx27/generic.c
@@ -159,6 +159,8 @@ unsigned int mxc_get_clock(enum mxc_clock clk)
switch (clk) {
case MXC_ARM_CLK:
return imx_get_armclk();
+   case MXC_I2C_CLK:
+   return imx_get_ahbclk()/2;
case MXC_UART_CLK:
return imx_get_perclk1();
case MXC_FEC_CLK:
diff --git a/arch/arm/include/asm/arch-mx27/clock.h 
b/arch/arm/include/asm/arch-mx27/clock.h
index fd062d3..2b03a41 100644
--- a/arch/arm/include/asm/arch-mx27/clock.h
+++ b/arch/arm/include/asm/arch-mx27/clock.h
@@ -26,6 +26,7 @@
 
 enum mxc_clock {
MXC_ARM_CLK,
+   MXC_I2C_CLK,
MXC_UART_CLK,
MXC_ESDHC_CLK,
MXC_FEC_CLK,
-- 
1.7.4.4

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


[U-Boot] [PATCH] mx27: add missing constant for mx27

2013-05-28 Thread Philippe Reynes
Add some missing constant (chip select, ...)

Signed-off-by: Philippe Reynes trem...@yahoo.fr
Signed-off-by: Eric Jarrige eric.jarr...@armadeus.org
---
 arch/arm/cpu/arm926ejs/mx27/asm-offsets.c |5 +
 arch/arm/include/asm/arch-mx27/imx-regs.h |3 ++-
 2 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/arch/arm/cpu/arm926ejs/mx27/asm-offsets.c 
b/arch/arm/cpu/arm926ejs/mx27/asm-offsets.c
index f3a8d7b..215c562 100644
--- a/arch/arm/cpu/arm926ejs/mx27/asm-offsets.c
+++ b/arch/arm/cpu/arm926ejs/mx27/asm-offsets.c
@@ -41,5 +41,10 @@ int main(void)
DEFINE(ESDCFG1_ROF, offsetof(struct esdramc_regs, esdcfg1));
DEFINE(ESDMISC_ROF, offsetof(struct esdramc_regs, esdmisc));
 
+   DEFINE(GPCR, IMX_SYSTEM_CTL_BASE +
+   offsetof(struct system_control_regs, gpcr));
+   DEFINE(FMCR, IMX_SYSTEM_CTL_BASE +
+   offsetof(struct system_control_regs, fmcr));
+
return 0;
 }
diff --git a/arch/arm/include/asm/arch-mx27/imx-regs.h 
b/arch/arm/include/asm/arch-mx27/imx-regs.h
index 8867e9f..707ca4b 100644
--- a/arch/arm/include/asm/arch-mx27/imx-regs.h
+++ b/arch/arm/include/asm/arch-mx27/imx-regs.h
@@ -185,7 +185,7 @@ struct iim_regs {
struct fuse_bank {
u32 fuse_regs[0x20];
u32 fuse_rsvd[0xe0];
-   } bank[1];
+   } bank[2];
 };
 
 struct fuse_bank0_regs {
@@ -225,6 +225,7 @@ struct fuse_bank0_regs {
 #define IIM_BASE_ADDR  IMX_IIM_BASE
 #define IMX_FEC_BASE   (0x2b000 + IMX_IO_BASE)
 
+#define IMX_NFC_BASE   (0xD800)
 #define IMX_ESD_BASE   (0xD8001000)
 #define IMX_WEIM_BASE  (0xD8002000)
 
-- 
1.7.4.4

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


Re: [U-Boot] [PATCH v4 2/7] arm: vf610: Add Vybrid VF610 CPU support

2013-05-28 Thread Benoît Thébaudeau
Hi Alison,

On Tuesday, May 28, 2013 10:55:42 AM, Alison Wang wrote:
 This patch adds generic codes to support Freescale's Vybrid VF610 CPU.
 
 It aligns Vybrid VF610 platform with i.MX platform. As there are
 some differences between VF610 and i.MX platforms, the specific
 codes are in the arch/arm/cpu/armv7/vf610 directory.
 
 Signed-off-by: Alison Wang b18...@freescale.com

[...]

 diff --git a/doc/README.vf610 b/doc/README.vf610
 new file mode 100644
 index 000..38cf5cf
 --- /dev/null
 +++ b/doc/README.vf610
 @@ -0,0 +1,10 @@
 +U-Boot for Freescale Vybrid VF610
 +
 +This file contains information for the port of U-Boot to the Freescale
 Vybrid
 +VF610 SoC.
 +
 +1. CONVENTIONS FOR FUSE ASSIGNMENTS
 +---
 +
 +1.1 MAC Address: It is stored in fuse bank 4, with the 16 msbs in word 2 and
 the
 +32 lsbs in word 3.

The hunk below is still missing:

doc/README.mxc_ocotp:
---
 on MXC
 
 This IP can be found on the following SoCs:
+ - Vybrid VF610,
  - i.MX6.
 
 Note that this IP is different from albeit similar to the IPs of the same name
---

Apart from that, this patch is correct.

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


Re: [U-Boot] [PATCH v4 3/7] net: fec_mxc: Add support for Vybrid VF610

2013-05-28 Thread Benoît Thébaudeau
Hi Alison,

On Tuesday, May 28, 2013 10:55:43 AM, Alison Wang wrote:
 This patch adds FEC support for Vybrid VF610 platform.
 
 In function fec_open(), RCR register is only set as RGMII mode. But RCR
 register should be set as RMII mode for VF610 platform.
 This configuration is already done in fec_reg_setup(), so this piece of
 code could just leave untouched the FEC_RCNTRL_RGMII / FEC_RCNTRL_RMII /
 FEC_RCNTRL_MII_MODE bits.

[...]

Reviewed-by: Benoît Thébaudeau benoit.thebaud...@advansee.com

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


Re: [U-Boot] [PATCH v4 2/7] arm: vf610: Add Vybrid VF610 CPU support

2013-05-28 Thread Benoît Thébaudeau
Hi Alison,

On Tuesday, May 28, 2013 9:16:20 PM, Benoît Thébaudeau wrote:
 Hi Alison,
 
 On Tuesday, May 28, 2013 10:55:42 AM, Alison Wang wrote:
  This patch adds generic codes to support Freescale's Vybrid VF610 CPU.
  
  It aligns Vybrid VF610 platform with i.MX platform. As there are
  some differences between VF610 and i.MX platforms, the specific
  codes are in the arch/arm/cpu/armv7/vf610 directory.
  
  Signed-off-by: Alison Wang b18...@freescale.com
 
 [...]
 
  diff --git a/doc/README.vf610 b/doc/README.vf610
  new file mode 100644
  index 000..38cf5cf
  --- /dev/null
  +++ b/doc/README.vf610
  @@ -0,0 +1,10 @@
  +U-Boot for Freescale Vybrid VF610
  +
  +This file contains information for the port of U-Boot to the Freescale
  Vybrid
  +VF610 SoC.
  +
  +1. CONVENTIONS FOR FUSE ASSIGNMENTS
  +---
  +
  +1.1 MAC Address: It is stored in fuse bank 4, with the 16 msbs in word 2
  and
  the
  +32 lsbs in word 3.
 
 The hunk below is still missing:
 
 doc/README.mxc_ocotp:
 ---
  on MXC
  
  This IP can be found on the following SoCs:
 + - Vybrid VF610,
   - i.MX6.
  
  Note that this IP is different from albeit similar to the IPs of the same
  name
 ---

I have just noticed that this was actually in 6/7. Why are you putting this into
a separate patch?

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


[U-Boot] [PATCH] fdt: Enhance dts/Makefile to be all things to all men

2013-05-28 Thread Simon Glass
There are a few partially conflicting requirements in compiling the device
tree, since U-Boot relies on whatever is installed on the build machine.

Some versions of dtc support -i, and this is often better than using #include
since you get correct line number information in errors. Unfortunately this
version must be installed manually in current Linux distributions.

Some device tree files use the word 'linux' which gets replaced with '1' by
many version of gcc, including version 4.7. So undefine this.

When an device tree file has an error we want to direct the user to the
right file and line number. So instead of piping the file into dts through
stdin, put it in a real file so that we get a fairly sensible error message
from dts. Then print out the original file details to help further.

This is based on a commit from Tom Warren. It would help if people can
test it in different environments.

Signed-off-by: Tom Warren twar...@nvidia.com
Signed-off-by: Simon Glass s...@chromium.org
---
 dts/Makefile | 34 +-
 1 file changed, 29 insertions(+), 5 deletions(-)

diff --git a/dts/Makefile b/dts/Makefile
index 03e163e..1f6fabb 100644
--- a/dts/Makefile
+++ b/dts/Makefile
@@ -37,11 +37,29 @@ $(if $(CONFIG_ARCH_DEVICE_TREE),,\
 $(error Your architecture does not have device tree support enabled. \
 Please define CONFIG_ARCH_DEVICE_TREE))
 
+# Provide a list of include directories for dtc
+DTS_INCS-y := -i $(SRCTREE)/arch/$(ARCH)/dts
+
+DTS_INCS-y += -i $(SRCTREE)/board/$(VENDOR)/dts
+
+DTS_INCS-$(CONFIG_CHROMEOS) += -i $(SRCTREE)/cros/dts
+
+# Check if our dtc includes the -i option
+DTS_FLAGS := $(shell if ! dtc -i 21 | grep -q invalid option; then \
+   echo $(DTS_INCS-y); fi)
+
 # We preprocess the device tree file provide a useful define
-DTS_CPPFLAGS := -x assembler-with-cpp \
+# Undefine 'linux' since it might be used in device tree files
+DTS_CPPFLAGS := -x assembler-with-cpp -Ulinux \

-DARCH_CPU_DTS=\$(SRCTREE)/arch/$(ARCH)/dts/$(CONFIG_ARCH_DEVICE_TREE).dtsi\ \

-DBOARD_DTS=\$(SRCTREE)/board/$(VENDOR)/$(BOARD)/dts/$(DEVICE_TREE).dts\ \
-   -I$(SRCTREE)/board/$(VENDOR)/dts -I$(SRCTREE)/arch/$(ARCH)/dts
+   -D__ASSEMBLY__ -I$(OBJTREE)/include -I$(SRCTREE)/include \
+   -I$(OBJTREE)/include2 \
+   -I$(SRCTREE)/board/$(VENDOR)/dts -I$(SRCTREE)/arch/$(ARCH)/dts \
+   -include $(OBJTREE)/include/config.h
+
+DTS_TMP := $(OBJTREE)/include/generated/$(DEVICE_TREE).dts.in
+DTS_SRC := board/$(VENDOR)/dts/$(DEVICE_TREE).dts
 
 all:   $(obj).depend $(LIB)
 
@@ -50,13 +68,19 @@ all:$(obj).depend $(LIB)
 # the filename.
 DT_BIN := $(obj)dt.dtb
 
-$(DT_BIN): $(TOPDIR)/board/$(VENDOR)/dts/$(DEVICE_TREE).dts
+DTC_CMD := $(DTC) -R 4 -p 0x1000 -O dtb -o ${DT_BIN} $(DTS_FLAGS) $(DTS_TMP)
+
+$(DT_BIN): $(TOPDIR)/$(DTS_SRC)
rc=$$( \
-   cat $ | $(CPP) -P $(DTS_CPPFLAGS) - | \
-   { { $(DTC) -R 4 -p 0x1000 -O dtb -o ${DT_BIN} - 21 ; \
+   cat $ | $(CPP) -P $(DTS_CPPFLAGS) -  $(DTS_TMP); \
+   { { $(DTC_CMD)  21 ; \
echo $$? 3 ; } | \
  grep -v '^DTC: dts-dtb  on file' ; \
} 31 12 ) ; \
+   if [ $$rc != 0 ]; then \
+   echo Source file is $(DTS_SRC); \
+   echo Compiler: $(DTC_CMD); \
+   fi; \
exit $$rc
 
 process_lds = \
-- 
1.8.2.1

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


Re: [U-Boot] [PATCH] mmc: fsl_esdhc: Fix hang after 'save' command

2013-05-28 Thread Fleming Andy-AFLEMING

On May 28, 2013, at 1:09 PM, Fabio Estevam wrote:

 Since commit 48e0b2bd (powerpc/esdhc: Correct judgement for DATA PIO mode) 
 we see mx6 systems to hang after doing a 'save' command.
 
 Revert this commit since the original 'ifdef' logic from 7b43db92 
 (drivers/mmc/fsl_esdhc.c: fix compiler warnings) was the correct one.
 
 Reported-by: Tapani Utriainen tap...@technexion.com
 Signed-off-by: Fabio Estevam fabio.este...@freescale.com


My apologies. I misread that patch. I found it hard to believe that Wolfgang 
had broken the logic, and that it had been broken for 2 years, but somehow my 
brain insisted that was the case. I now agree with your assessment, and will 
apply your patch.

Haijun, please investigate the problem you were trying to solve with this 
patch, and determine what the actual cause was, and then submit a new patch to 
fix it.


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


Re: [U-Boot] [PATCH] fdt: Enhance dts/Makefile to be all things to all men

2013-05-28 Thread Tom Warren
Simon,

 -Original Message-
 From: Simon Glass [mailto:s...@chromium.org]
 Sent: Tuesday, May 28, 2013 12:36 PM
 To: U-Boot Mailing List
 Cc: Tom Rini; Stephen Warren; Devicetree Discuss; u-boot-
 rev...@google.com; Simon Glass; Tom Warren; Jerry Van Baren
 Subject: [PATCH] fdt: Enhance dts/Makefile to be all things to all men
 
 There are a few partially conflicting requirements in compiling the device
 tree, since U-Boot relies on whatever is installed on the build machine.
 
 Some versions of dtc support -i, and this is often better than using #include
 since you get correct line number information in errors. Unfortunately this
 version must be installed manually in current Linux distributions.
 
 Some device tree files use the word 'linux' which gets replaced with '1' by
 many version of gcc, including version 4.7. So undefine this.
 
 When an device tree file has an error we want to direct the user to the right
 file and line number. So instead of piping the file into dts through stdin, 
 put it
 in a real file so that we get a fairly sensible error message from dts. Then
 print out the original file details to help further.
 
 This is based on a commit from Tom Warren. It would help if people can test
 it in different environments.
 
 Signed-off-by: Tom Warren twar...@nvidia.com
 Signed-off-by: Simon Glass s...@chromium.org

Works for me for all Tegra builds, so:

Tested-by: Tom Warren twar...@nvidia.com

Tom
 ---
  dts/Makefile | 34 +-
  1 file changed, 29 insertions(+), 5 deletions(-)
 
 diff --git a/dts/Makefile b/dts/Makefile index 03e163e..1f6fabb 100644
 --- a/dts/Makefile
 +++ b/dts/Makefile
 @@ -37,11 +37,29 @@ $(if $(CONFIG_ARCH_DEVICE_TREE),,\  $(error Your
 architecture does not have device tree support enabled. \  Please define
 CONFIG_ARCH_DEVICE_TREE))
 
 +# Provide a list of include directories for dtc DTS_INCS-y := -i
 +$(SRCTREE)/arch/$(ARCH)/dts
 +
 +DTS_INCS-y += -i $(SRCTREE)/board/$(VENDOR)/dts
 +
 +DTS_INCS-$(CONFIG_CHROMEOS) += -i $(SRCTREE)/cros/dts
 +
 +# Check if our dtc includes the -i option DTS_FLAGS := $(shell if ! dtc
 +-i 21 | grep -q invalid option; then \
 + echo $(DTS_INCS-y); fi)
 +
  # We preprocess the device tree file provide a useful define -DTS_CPPFLAGS
 := -x assembler-with-cpp \
 +# Undefine 'linux' since it might be used in device tree files
 +DTS_CPPFLAGS := -x assembler-with-cpp -Ulinux \
   -
 DARCH_CPU_DTS=\$(SRCTREE)/arch/$(ARCH)/dts/$(CONFIG_ARCH_DEVIC
 E_TREE).dtsi\ \
   -
 DBOARD_DTS=\$(SRCTREE)/board/$(VENDOR)/$(BOARD)/dts/$(DEVICE_TR
 EE).dts\ \
 - -I$(SRCTREE)/board/$(VENDOR)/dts -
 I$(SRCTREE)/arch/$(ARCH)/dts
 + -D__ASSEMBLY__ -I$(OBJTREE)/include -I$(SRCTREE)/include
 \
 + -I$(OBJTREE)/include2 \
 + -I$(SRCTREE)/board/$(VENDOR)/dts -
 I$(SRCTREE)/arch/$(ARCH)/dts \
 + -include $(OBJTREE)/include/config.h
 +
 +DTS_TMP := $(OBJTREE)/include/generated/$(DEVICE_TREE).dts.in
 +DTS_SRC := board/$(VENDOR)/dts/$(DEVICE_TREE).dts
 
  all: $(obj).depend $(LIB)
 
 @@ -50,13 +68,19 @@ all:  $(obj).depend $(LIB)
  # the filename.
  DT_BIN   := $(obj)dt.dtb
 
 -$(DT_BIN): $(TOPDIR)/board/$(VENDOR)/dts/$(DEVICE_TREE).dts
 +DTC_CMD := $(DTC) -R 4 -p 0x1000 -O dtb -o ${DT_BIN} $(DTS_FLAGS)
 +$(DTS_TMP)
 +
 +$(DT_BIN): $(TOPDIR)/$(DTS_SRC)
   rc=$$( \
 - cat $ | $(CPP) -P $(DTS_CPPFLAGS) - | \
 - { { $(DTC) -R 4 -p 0x1000 -O dtb -o ${DT_BIN} - 21 ; \
 + cat $ | $(CPP) -P $(DTS_CPPFLAGS) -  $(DTS_TMP); \
 + { { $(DTC_CMD)  21 ; \
   echo $$? 3 ; } | \
 grep -v '^DTC: dts-dtb  on file' ; \
   } 31 12 ) ; \
 + if [ $$rc != 0 ]; then \
 + echo Source file is $(DTS_SRC); \
 + echo Compiler: $(DTC_CMD); \
 + fi; \
   exit $$rc
 
  process_lds = \
 --
 1.8.2.1
--
nvpublic
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v4 7/7] arm: vf610: Add basic support for Vybrid VF610TWR board

2013-05-28 Thread Benoît Thébaudeau
Hi Alison,

On Tuesday, May 28, 2013 10:55:47 AM, Alison Wang wrote:
 VF610TWR is a board based on Vybrid VF610 SoC.
 
 This patch adds basic support for Vybrid VF610TWR board.
 
 Signed-off-by: Alison Wang b18...@freescale.com
 Signed-off-by: Jason Jin jason@freescale.com
 Signed-off-by: TsiChung Liew tsicl...@gmail.com

[...]

 diff --git a/include/configs/vf610twr.h b/include/configs/vf610twr.h
 new file mode 100644
 index 000..77fe893
 --- /dev/null
 +++ b/include/configs/vf610twr.h
 @@ -0,0 +1,140 @@
 +/*
 + * Copyright 2013 Freescale Semiconductor, Inc.
 + *
 + * Configuration settings for the Freescale Vybrid vf610twr board.
 + *
 + * This program is free software; you can redistribute it and/or
 + * modify it under the terms of the GNU General Public License as
 + * published by the Free Software Foundation; either version 2 of
 + * the License, or (at your option) any later version.
 + *
 + * This program is distributed in the hope that it will be useful,
 + * but WITHOUT ANY WARRANTY; without even the implied warranty of
 + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 + * GNU General Public License for more details.
 + *
 + * You should have received a copy of the GNU General Public License
 + * along with this program; if not, write to the Free Software
 + * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
 + * MA 02111-1307 USA
 + */
 +
 +#ifndef __CONFIG_H
 +#define __CONFIG_H
 +
 +#include asm/arch/imx-regs.h
 +#include config_cmd_default.h
 +
 +#define CONFIG_VF610
 +
 +#define CONFIG_DISPLAY_CPUINFO
 +#define CONFIG_DISPLAY_BOARDINFO
 +
 +#define CONFIG_MACH_TYPE 4146
 +
 +#define CONFIG_SKIP_LOWLEVEL_INIT
 +
 +/* Enable passing of ATAGs */
 +#define CONFIG_CMDLINE_TAG
 +
 +#define CONFIG_CMD_FUSE
 +#ifdef CONFIG_CMD_FUSE
 +#define CONFIG_MXC_OCOTP
 +#endif
 +
 +/* Size of malloc() pool */
 +#define CONFIG_SYS_MALLOC_LEN(CONFIG_ENV_SIZE + 2 * 1024 * 
 1024)
 +
 +#define CONFIG_BOARD_EARLY_INIT_F
 +
 +#define CONFIG_FSL_LPUART
 +#define LPUART_BASE  UART1_BASE
 +
 +/* Allow to overwrite serial and ethaddr */
 +#define CONFIG_ENV_OVERWRITE
 +#define CONFIG_SYS_UART_PORT (1)
 +#define CONFIG_BAUDRATE  115200
 +
 +#undef CONFIG_CMD_IMLS
 +
 +#define CONFIG_MMC
 +#define CONFIG_FSL_ESDHC
 +#define CONFIG_SYS_FSL_ESDHC_ADDR0
 +#define CONFIG_SYS_FSL_ESDHC_NUM 1
 +
 +#define CONFIG_SYS_FSL_ERRATUM_ESDHC111
 +
 +#define CONFIG_CMD_MMC
 +#define CONFIG_GENERIC_MMC
 +#define CONFIG_CMD_FAT
 +#define CONFIG_DOS_PARTITION
 +
 +#define CONFIG_CMD_PING
 +#define CONFIG_CMD_DHCP
 +#define CONFIG_CMD_MII
 +#define CONFIG_CMD_NET
 +#define CONFIG_FEC_MXC
 +#define CONFIG_MII
 +#define IMX_FEC_BASE ENET_BASE_ADDR
 +#define CONFIG_FEC_XCV_TYPE  RMII
 +#define CONFIG_FEC_MXC_PHYADDR  0

Why don't you add support for the 2nd FEC? Do you plan to do it later?

 +#define CONFIG_PHYLIB
 +#define CONFIG_PHY_MICREL
 +
 +#define CONFIG_BOOTDELAY 3
 +
 +#define CONFIG_SYS_TEXT_BASE 0x3f008000
 +
 +/* Miscellaneous configurable options */
 +#define CONFIG_SYS_LONGHELP  /* undef to save memory */
 +#define CONFIG_SYS_HUSH_PARSER   /* use hush command parser */
 +#define CONFIG_SYS_PROMPT_HUSH_PS2
 +#define CONFIG_SYS_PROMPTVybrid U-Boot  
 +#undef CONFIG_AUTO_COMPLETE
 +#define CONFIG_SYS_CBSIZE256 /* Console I/O Buffer Size */
 +#define CONFIG_SYS_PBSIZE\
 + (CONFIG_SYS_CBSIZE + sizeof(CONFIG_SYS_PROMPT) + 16)
 +#define CONFIG_SYS_MAXARGS   16  /* max number of command args */
 +#define CONFIG_SYS_BARGSIZE  CONFIG_SYS_CBSIZE
 +
 +#define CONFIG_CMD_MEMTEST
 +#define CONFIG_SYS_MEMTEST_START 0x8001
 +#define CONFIG_SYS_MEMTEST_END   0x87C0

Please make sure to have runtime-tested this address range with the mtest
command since bad mtest addresses are the reason why CONFIG_CMD_MEMTEST has been
removed from the default commands.

[...]

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


Re: [U-Boot] dfu: dfu and UBI Volumes

2013-05-28 Thread Wolfgang Denk
Dear Tom,

In message 20130528172309.GF5829@bill-the-cat you wrote:
 
  Of course this can't yet apply to writing files on file systems since the
  current API in U-Boot misses the append feature, but this could be applied 
  to
  program raw memory partitions, including UBI images.

 Correct.  We can write a whole UBI image, today, of NAND size,
 regardless of DDR size.  But modifying UBI volumes (so UBIFS or your

I don't think so.  To write a UBI volume on an existing UBI device,
you would use the ubi write command.  This translates into a call of
ubi_volume_write(char *volume, void *buf, size_t size)  which means
the size must be known before you start writing; as far as I can tell
ubi_volume_write() does not support incremental write operations of
individual parts of a volume.


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
Its always easier short term to pee in the pond
than install a toilet - it's just not a good long term plan.
  - Alan Cox in 20100101145701.6432e...@lxorguk.ukuu.org.uk
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v2] OMAP5: Fix bug in omap5_es1_prcm struct

2013-05-28 Thread Tom Rini
On Sun, May 26, 2013 at 11:03:17PM +0300, Lubomir Popov wrote:

 The newly introduced function setup_warmreset_time(), called
 from within prcm_init(), tries to write to the prm_rsttime
 OMAP5 register. The struct member holding this register's
 address is however initialized for OMAP5 ES2.0 only. On ES1.0
 devices this uninitialized value causes a second (warm) reset
 at startup.
 
 Add .prm_rsttime address init to the ES1.0 struct.
 
 Signed-off-by: Lubomir Popov lpo...@mm-sol.com

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

-- 
Tom


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


Re: [U-Boot] [PATCH 0/5] sf: Code cleanup patch set

2013-05-28 Thread Tom Rini
On Tue, May 28, 2013 at 01:27:23AM +0530, Jagannadha Sutradharudu Teki wrote:

 This patch set consist of code clean-up on sf.
 
 Thanks,
 Jagan.
 
 Jagannadha Sutradharudu Teki (5):
   sf: eon|spansion|ramtron: Fix code cleanup
   sf: sst: Fix code cleanup
   sf: stmicro: Fix code cleanup
   sf: Fix line over 80 chars cleanup
   cmd_sf: Fix code cleanup
 
  common/cmd_sf.c |5 +++--
  drivers/mtd/spi/eon.c   |3 +--
  drivers/mtd/spi/ramtron.c   |6 --
  drivers/mtd/spi/spansion.c  |3 ++-
  drivers/mtd/spi/spi_flash.c |9 ++---
  drivers/mtd/spi/sst.c   |   32 
  drivers/mtd/spi/stmicro.c   |7 +++
  7 files changed, 39 insertions(+), 26 deletions(-)

Everything looks OK, but to be clear, at the end of this checkpatch.pl
says style problems have all been fixed?  Or this just fixes some of
them?  Thanks!

-- 
Tom


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


Re: [U-Boot] [PATCH] fdt: Enhance dts/Makefile to be all things to all men

2013-05-28 Thread Stephen Warren
On 05/28/2013 01:36 PM, Simon Glass wrote:
 There are a few partially conflicting requirements in compiling the device
 tree, since U-Boot relies on whatever is installed on the build machine.
 
 Some versions of dtc support -i, and this is often better than using #include
 since you get correct line number information in errors.

What issue is there with line numbers when using dtc? Recent dtc
supports #line directives from the pre-processing results, and hence
reports errors in terms of the source files, just like raw dtc without cpp.

 Unfortunately this
 version must be installed manually in current Linux distributions.

Well, then that gets into the problem of some .dts files choosing to use
/include/ and rely on -i, but others using #include and not. I don't
really think it's a good idea to propagate both versions. Picking one
and using it would be far better.

I really do think we should simply require a reasonably recent dtc and
be done with it.

 Some device tree files use the word 'linux' which gets replaced with '1' by
 many version of gcc, including version 4.7. So undefine this.

Linux chose to use -undef rather than undefining specific/individual
defines. It'd be best to be consistent to that .dts files are more
likely to be portable between the two.

 diff --git a/dts/Makefile b/dts/Makefile

 +# Provide a list of include directories for dtc
 +DTS_INCS-y := -i $(SRCTREE)/arch/$(ARCH)/dts
 +
 +DTS_INCS-y += -i $(SRCTREE)/board/$(VENDOR)/dts

That has arch/ first then board/ ... (continued a few comments below)

 +DTS_INCS-$(CONFIG_CHROMEOS) += -i $(SRCTREE)/cros/dts

Is that meant to be upstream?

 +# Check if our dtc includes the -i option
 +DTS_FLAGS := $(shell if ! dtc -i 21 | grep -q invalid option; then \
 + echo $(DTS_INCS-y); fi)
 +
  # We preprocess the device tree file provide a useful define
 -DTS_CPPFLAGS := -x assembler-with-cpp \
 +# Undefine 'linux' since it might be used in device tree files
 +DTS_CPPFLAGS := -x assembler-with-cpp -Ulinux \

I'll repeat my request to use -undef instead.

   
 -DARCH_CPU_DTS=\$(SRCTREE)/arch/$(ARCH)/dts/$(CONFIG_ARCH_DEVICE_TREE).dtsi\
  \
   
 -DBOARD_DTS=\$(SRCTREE)/board/$(VENDOR)/$(BOARD)/dts/$(DEVICE_TREE).dts\ \
 - -I$(SRCTREE)/board/$(VENDOR)/dts -I$(SRCTREE)/arch/$(ARCH)/dts
 + -D__ASSEMBLY__ -I$(OBJTREE)/include -I$(SRCTREE)/include \
 + -I$(OBJTREE)/include2 \

Do we really want include or include2 (what's that?) at all? The .dts
files really should be standalone, and not interact with the U-Boot
headers at all.

 + -I$(SRCTREE)/board/$(VENDOR)/dts -I$(SRCTREE)/arch/$(ARCH)/dts \

... whereas this has board/ first then arch/. It'd be better to be
consistent.

 + -include $(OBJTREE)/include/config.h
 +
 +DTS_TMP := $(OBJTREE)/include/generated/$(DEVICE_TREE).dts.in

Hmm. This really isn't a generated header file. Can this instead be
$(OBJTREE)/$(dir $@).$(notdir $@).dts or something like that?

 +DTS_SRC := board/$(VENDOR)/dts/$(DEVICE_TREE).dts
  
  all: $(obj).depend $(LIB)
  
 @@ -50,13 +68,19 @@ all:  $(obj).depend $(LIB)
  # the filename.
  DT_BIN   := $(obj)dt.dtb
  
 -$(DT_BIN): $(TOPDIR)/board/$(VENDOR)/dts/$(DEVICE_TREE).dts
 +DTC_CMD := $(DTC) -R 4 -p 0x1000 -O dtb -o ${DT_BIN} $(DTS_FLAGS) $(DTS_TMP)

It may be better to leave $(DTS_TMP) in the make script below, so it's
more obvious what file is being compiled; the re-direct to $(DTS_TMP) is
left in the $(CPP) invocation below, so it'd also be consistent with that.

 +$(DT_BIN): $(TOPDIR)/$(DTS_SRC)
   rc=$$( \
 - cat $ | $(CPP) -P $(DTS_CPPFLAGS) - | \
 - { { $(DTC) -R 4 -p 0x1000 -O dtb -o ${DT_BIN} - 21 ; \
 + cat $ | $(CPP) -P $(DTS_CPPFLAGS) -  $(DTS_TMP); \
 + { { $(DTC_CMD)  21 ; \
...

 + if [ $$rc != 0 ]; then \
 + echo Source file is $(DTS_SRC); \
 + echo Compiler: $(DTC_CMD); \
 + fi; \

Isn't that what make V=1 is for?

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


Re: [U-Boot] [PATCH] fdt: Enhance dts/Makefile to be all things to all men

2013-05-28 Thread Wolfgang Denk
Dear Simon Glass,

In message 1369769778-12455-1-git-send-email-...@chromium.org you wrote:
 
 Some device tree files use the word 'linux' which gets replaced with '1' by
 many version of gcc, including version 4.7. So undefine this.

I think this is not a good way to address this issue.  The GCC
documentation (section System-specific Predefined Macros [1])
desribes how this should be handled.  The correct (TM) way to fix
this is by adding -ansi or any -std option that requests strict
conformance to the compiler/preprocessor command line.

[1] 
http://gcc.gnu.org/onlinedocs/cpp/System_002dspecific-Predefined-Macros.html#System_002dspecific-Predefined-Macros


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 human race is faced with a cruel choice: work  or  daytime  tele-
vision.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] dfu: dfu and UBI Volumes

2013-05-28 Thread Tom Rini
On Tue, May 28, 2013 at 11:01:09PM +0200, Wolfgang Denk wrote:
 Dear Tom,
 
 In message 20130528172309.GF5829@bill-the-cat you wrote:
  
   Of course this can't yet apply to writing files on file systems since the
   current API in U-Boot misses the append feature, but this could be 
   applied to
   program raw memory partitions, including UBI images.
 
  Correct.  We can write a whole UBI image, today, of NAND size,
  regardless of DDR size.  But modifying UBI volumes (so UBIFS or your
 
 I don't think so.  To write a UBI volume on an existing UBI device,
 you would use the ubi write command.  This translates into a call of
 ubi_volume_write(char *volume, void *buf, size_t size)  which means
 the size must be known before you start writing; as far as I can tell
 ubi_volume_write() does not support incremental write operations of
 individual parts of a volume.

OK.  A very quick read of ubi_volume_write leads into the guts of the
write being in drivers/mtd/ubi/upd.c and it feels like you could
actually do the volume write in chunks with ubi_start_update() and
ubi_more_update_data() (and maybe some other housekeeping bits).  It
might take a bit more work since it looks like looks like both functions
rely on knowing the size at the start, but that's just to make sure the
size will fit in the volume.

-- 
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 request for u-boot-tegra/master into ARM/master

2013-05-28 Thread Tom Warren
Albert,

Please pull u-boot-tegra/master into ARM/master. Thanks!

./MAKEALL for all the Tegra boards is OK, running a ./MAKEALL -a arm now.
tools/checkpatch.pl is clean.

The following changes since commit fd725691797bb3192af15a15c2cba7d0b2ee9327:

  arm: Enable -ffunction-sections / -fdata-sections / --gc-sections
(2013-05-23 12:09:56 +0200)

are available in the git repository at:

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

for you to fetch changes up to 60985bba58e7695dac1fddae8cdbb62d8cfd1254:

  tegra: Define CONFIG_SKIP_LOWLEVEL_INIT for SPL build (2013-05-28
12:58:44 -0700)


Allen Martin (1):
  Tegra: clk: always use find_best_divider() for periph clocks

Axel Lin (2):
  ARM: arm720t: Add missing CONFIG_SKIP_LOWLEVEL_INIT guard for
cpu_init_crit
  tegra: Define CONFIG_SKIP_LOWLEVEL_INIT for SPL build

Stephen Warren (3):
  tegra: always build u-boot-nodtb-tegra.bin
  ARM: tegra: support SKU 1 of Tegra114
  ARM: tegra: support SKU 7 of Tegra20

Tom Warren (2):
  Tegra: T30: Beaver: Fix board/board_name env vars, s/b beaver, not
cardhu
  Tegra: Remove unused/non-existent spl linker script reference

 Makefile| 17 ++-
 arch/arm/cpu/arm720t/start.S|  4 ++--
 arch/arm/cpu/tegra-common/ap.c  |  2 ++
 arch/arm/cpu/tegra-common/clock.c   | 10 -
 arch/arm/include/asm/arch-tegra/tegra.h |  2 ++
 board/nvidia/beaver/Makefile| 38
+
 boards.cfg  |  2 +-
 include/configs/tegra-common-post.h |  2 ++
 include/configs/tegra114-common.h   |  2 --
 include/configs/tegra20-common.h|  2 --
 include/configs/tegra30-common.h|  2 --
 11 files changed, 59 insertions(+), 24 deletions(-)
 create mode 100644 board/nvidia/beaver/Makefile
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH] powerpc/pixis: Fix pixis help message

2013-05-28 Thread York Sun
pixis_reset help command prints the message without a new line \n,
which makes the prompt on the same line.

Signed-off-by: York Sun york...@freescale.com
---
 board/freescale/common/pixis.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/board/freescale/common/pixis.c b/board/freescale/common/pixis.c
index 8d07061..577a542 100644
--- a/board/freescale/common/pixis.c
+++ b/board/freescale/common/pixis.c
@@ -552,5 +552,5 @@ U_BOOT_CMD(
pixis_reset [altbank]\n
pixis_reset altbank wd\n
pixis_reset altbank cf SYSCLK freq COREPLL ratio MPXPLL 
ratio\n
-   pixis_reset cf SYSCLK freq COREPLL ratio MPXPLL ratio
+   pixis_reset cf SYSCLK freq COREPLL ratio MPXPLL ratio\n
 );
-- 
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 5/6] spl: Make CONFIG_SPL_BUILD contain more functionality

2013-05-28 Thread Scott Wood

On 05/22/2013 08:26:31 PM, Zhang Ying-B40530 wrote:



-Original Message-
From: Wood Scott-B07421
Sent: Wednesday, May 22, 2013 11:46 PM
To: Zhang Ying-B40530
Cc: Wood Scott-B07421; u-boot@lists.denx.de; aflem...@gmail.com; Xie  
Xiaobo-R63061; Ilya Yanok
Subject: Re: [PATCH 5/6] spl: Make CONFIG_SPL_BUILD contain more  
functionality


On 05/21/2013 09:15:08 PM, Zhang Ying-B40530 wrote:
  diff --git a/include/configs/MPC8313ERDB.h
  b/include/configs/MPC8313ERDB.h
  index c28dfe0..a2bdcff 100644
  --- a/include/configs/MPC8313ERDB.h
  +++ b/include/configs/MPC8313ERDB.h
  @@ -40,7 +40,9 @@
   #define CONFIG_SPL_INIT_MINIMAL
   #define CONFIG_SPL_SERIAL_SUPPORT
   #define CONFIG_SPL_NAND_SUPPORT
  +#ifdef CONFIG_SPL_BUILD
   #define CONFIG_SPL_NAND_MINIMAL
  +#endif
   #define CONFIG_SPL_FLUSH_IMAGE
   #define CONFIG_SPL_TARGETu-boot-with-spl.bin
   #define CONFIG_SPL_MPC83XX_WAIT_FOR_NAND
  diff --git a/include/configs/P1022DS.h b/include/configs/P1022DS.h
  index 8b13b10..5bdd44a 100644
  --- a/include/configs/P1022DS.h
  +++ b/include/configs/P1022DS.h
  @@ -41,7 +41,9 @@
   #define CONFIG_SPL_INIT_MINIMAL
   #define CONFIG_SPL_SERIAL_SUPPORT
   #define CONFIG_SPL_NAND_SUPPORT
  +#ifdef CONFIG_SPL_BUILD
   #define CONFIG_SPL_NAND_MINIMAL
  +#endif
   #define CONFIG_SPL_FLUSH_IMAGE
   #define CONFIG_SPL_TARGET  u-boot-with-spl.bin
 
  diff --git a/include/configs/p1_p2_rdb_pc.h
  b/include/configs/p1_p2_rdb_pc.h
  index 7ed634b..bc48d62 100644
  --- a/include/configs/p1_p2_rdb_pc.h
  +++ b/include/configs/p1_p2_rdb_pc.h
  @@ -159,7 +159,9 @@
   #define CONFIG_SPL_INIT_MINIMAL
   #define CONFIG_SPL_SERIAL_SUPPORT
   #define CONFIG_SPL_NAND_SUPPORT
  +#ifdef CONFIG_SPL_BUILD
   #define CONFIG_SPL_NAND_MINIMAL
  +#endif
   #define CONFIG_SPL_FLUSH_IMAGE
   #define CONFIG_SPL_TARGETu-boot-with-spl.bin

 Are you sure this belongs in this patch?
 [Zhang Ying]
 Yes, it is necessary. Because CONFIG_SPL_NAND_MINIMAL has been used
 in the file law.c and tlb.c in this patch.

What I mean is that it should probably have been done earlier, when  
you

introduced CONFIG_SPL_NAND_MINIMAL.
[Zhang Ying]
I can understand you mean. Because the symbol  
CONFIG_SPL_NAND_MINIMAL has been useless, I think no need to split  
out a separate patch.


OK, it looks like CONFIG_SPL_NAND_MINIMAL was there before your  
patchset.  I think that was an accidental left-over and should have  
been removed (it was replaced with CONFIG_SPL_NAND_DRIVERS, _BASE, and  
_ECC).


Could you describe what specifically you're using it to mean here?

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


[U-Boot] [PATCH v2] SPL: Makefile: Build a separate autoconf.mk for SPL

2013-05-28 Thread Joel A Fernandes
SPL defines CONFIG_SPL_BUILD but this does not percolate to the autoconf.mk 
Makefile.
As a result the build breaks when CONFIG_SPL_BUILD is used in the 
board-specific include
header file. With this, there is a possibility of having a CONFIG option 
defined in the
header file but not defined in the Makefile causing all kinds of build failure 
and problems.

It also messes things for up, for example, when one might want to undefine 
options to
keep the SPL small and doesn't want to be stuck with the CONFIG options used 
for U-boot.
Lastly, this also avoids defining special CONFIG_SPL_ variables for cases where 
some
options are required in U-boot but not in SPL.

We add a spl-autoconf.mk rule that is generated for SPL with the 
CONFIG_SPL_BUILD flag
and conditionally include it for SPL builds.

v2 changes:
Fixed issue where builds in a different directory were failing.
Suggested-by: Muddegowda, Deepak x0171...@ti.com . Thanks Deepak!
Reported-by: Tom Rini tr...@ti.com

Signed-off-by: Joel A Fernandes joelag...@ti.com
Cc: Muddegowda, Deepak x0171...@ti.com
Cc: Tom Rini tr...@ti.com
---
 Makefile  |   19 +--
 config.mk |6 ++
 2 files changed, 23 insertions(+), 2 deletions(-)

diff --git a/Makefile b/Makefile
index 6a30e04..e3a87e5 100644
--- a/Makefile
+++ b/Makefile
@@ -567,6 +567,7 @@ updater:
 # Explicitly make _depend in subdirs containing multiple targets to prevent
 # parallel sub-makes creating .depend files simultaneously.
 depend dep:$(TIMESTAMP_FILE) $(VERSION_FILE) \
+   $(obj)include/spl-autoconf.mk \
$(obj)include/autoconf.mk \
$(obj)include/generated/generic-asm-offsets.h \
$(obj)include/generated/asm-offsets.h
@@ -632,12 +633,23 @@ $(obj)include/autoconf.mk: $(obj)include/config.h
sed -n -f tools/scripts/define2mk.sed  $@.tmp  \
mv $@.tmp $@
 
+# Auto-generate the spl-autoconf.mk file (which is included by all makefiles 
for SPL)
+$(obj)include/spl-autoconf.mk: $(obj)include/config.h
+   @$(XECHO) Generating $@ ; \
+   set -e ; \
+   : Extract the config macros ; \
+   $(CPP) $(CFLAGS) -DCONFIG_SPL_BUILD -DDO_DEPS_ONLY -dM include/common.h 
| \
+   sed -n -f tools/scripts/define2mk.sed  $@.tmp  \
+   mv $@.tmp $@
+
 $(obj)include/generated/generic-asm-offsets.h: $(obj)include/autoconf.mk.dep \
+   $(obj)include/spl-autoconf.mk \
$(obj)lib/asm-offsets.s
@$(XECHO) Generating $@
tools/scripts/make-asm-offsets $(obj)lib/asm-offsets.s $@
 
 $(obj)lib/asm-offsets.s:   $(obj)include/autoconf.mk.dep \
+   $(obj)include/spl-autoconf.mk \
$(src)lib/asm-offsets.c
@mkdir -p $(obj)lib
$(CC) -DDO_DEPS_ONLY \
@@ -645,11 +657,13 @@ $(obj)lib/asm-offsets.s:  $(obj)include/autoconf.mk.dep \
-o $@ $(src)lib/asm-offsets.c -c -S
 
 $(obj)include/generated/asm-offsets.h: $(obj)include/autoconf.mk.dep \
+   $(obj)include/spl-autoconf.mk \
$(obj)$(CPUDIR)/$(SOC)/asm-offsets.s
@$(XECHO) Generating $@
tools/scripts/make-asm-offsets $(obj)$(CPUDIR)/$(SOC)/asm-offsets.s $@
 
-$(obj)$(CPUDIR)/$(SOC)/asm-offsets.s:  $(obj)include/autoconf.mk.dep
+$(obj)$(CPUDIR)/$(SOC)/asm-offsets.s:  $(obj)include/autoconf.mk.dep \
+   $(obj)include/spl-autoconf.mk
@mkdir -p $(obj)$(CPUDIR)/$(SOC)
if [ -f $(src)$(CPUDIR)/$(SOC)/asm-offsets.c ];then \
$(CC) -DDO_DEPS_ONLY \
@@ -711,7 +725,8 @@ include/license.h: tools/bin2header COPYING
 unconfig:
@rm -f $(obj)include/config.h $(obj)include/config.mk \
$(obj)board/*/config.tmp $(obj)board/*/*/config.tmp \
-   $(obj)include/autoconf.mk $(obj)include/autoconf.mk.dep
+   $(obj)include/autoconf.mk $(obj)include/autoconf.mk.dep \
+   $(obj)include/spl-autoconf.mk
 
 %_config:: unconfig
@$(MKCONFIG) -A $(@:_config=)
diff --git a/config.mk b/config.mk
index 51b4783..3246c2c 100644
--- a/config.mk
+++ b/config.mk
@@ -153,7 +153,13 @@ DTC= dtc
 #
 
 # Load generated board configuration
+ifeq ($(CONFIG_SPL_BUILD),y)
+# Include SPL autoconf
+sinclude $(OBJTREE)/include/spl-autoconf.mk
+else
+# Include normal autoconf
 sinclude $(OBJTREE)/include/autoconf.mk
+endif
 sinclude $(OBJTREE)/include/config.mk
 
 # Some architecture config.mk files need to know what CPUDIR is set to,
-- 
1.7.4.1

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


Re: [U-Boot] [PATCH v2 07/13] sf: winbond: add W25Q32DW

2013-05-28 Thread Allen Martin
On Fri, May 24, 2013 at 01:39:51PM -0700, Jagan Teki wrote:
 Hi,
 
 Any update on this.
 
 Thanks,
 Jagan.
 
 On Thu, May 23, 2013 at 1:15 PM, Jagan Teki jagannadh.t...@gmail.com wrote:
  Hi Allen,
 
  On Sun, Mar 17, 2013 at 10:28 AM, Allen Martin amar...@nvidia.com wrote:
  Add support for Winbond W25Q32DW 32Mbit part
 
  Signed-off-by: Allen Martin amar...@nvidia.com
  ---
   drivers/mtd/spi/winbond.c |5 +
   1 file changed, 5 insertions(+)
 
  diff --git a/drivers/mtd/spi/winbond.c b/drivers/mtd/spi/winbond.c
  index 4418302..3560fcb 100644
  --- a/drivers/mtd/spi/winbond.c
  +++ b/drivers/mtd/spi/winbond.c
  @@ -68,6 +68,11 @@ static const struct winbond_spi_flash_params 
  winbond_spi_flash_table[] = {
  .name   = W25Q80,
  },
  {
  +   .id = 0x6016,
  +   .nr_blocks  = 512,
 
  nr_blocks here should have 64 instead of 512.
  please let me know, I will add correction-patch for this.

You're right, it's a 32Mbit part, so nr_blocks should be 64, thanks
for finding this.


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


Re: [U-Boot] [RFC PATCH 5/7] Adjust Kconfig scripts for use by U-Boot

2013-05-28 Thread Masahiro Yamada
Hello, Simon.

Please let me ask some more questions.

By applying these series of commits,
U-Boot's config file scheme and Kconfig coexist.

For example, scripts/Makefile.build includes
both auto.conf generated by Kconfig
and autoconf.mk derived from U-boot's config.

-include include/config/auto.conf
-include $(objtree)/include/config/autoconf.mk

I think the redundancy and dirtiness do not matter 
if they are temporary.

What I'd like to make clear is our goal.
It is intended to move all U-Boot's config files
to Kconfig over long time and
after that, delete U-Boot's config system.
Is this right?

If the answer is yes, there are some macros
I don't know how to port to Kconfig.

For example,
CONFIG_SYS_BAUDRATE_TABLE is defined like follows.

#define CONFIG_SYS_BAUDRATE_TABLE {9600, 19200, 38400, 57600, 115200}

To my knowledge this macro can not be described by Kconfig.

Do you have any good idea about this?

And also, some config files still include macros without CONFIG_ prefix.
For example, LINUX_BOOT_PARAM_ADDR, PHYS_SDRAM_1, PHYS_SDRAM_2, etc.


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 v2 07/13] sf: winbond: add W25Q32DW

2013-05-28 Thread Jagan Teki
On Wed, May 29, 2013 at 5:58 AM, Allen Martin amar...@nvidia.com wrote:
 On Fri, May 24, 2013 at 01:39:51PM -0700, Jagan Teki wrote:
 Hi,

 Any update on this.

 Thanks,
 Jagan.

 On Thu, May 23, 2013 at 1:15 PM, Jagan Teki jagannadh.t...@gmail.com wrote:
  Hi Allen,
 
  On Sun, Mar 17, 2013 at 10:28 AM, Allen Martin amar...@nvidia.com wrote:
  Add support for Winbond W25Q32DW 32Mbit part
 
  Signed-off-by: Allen Martin amar...@nvidia.com
  ---
   drivers/mtd/spi/winbond.c |5 +
   1 file changed, 5 insertions(+)
 
  diff --git a/drivers/mtd/spi/winbond.c b/drivers/mtd/spi/winbond.c
  index 4418302..3560fcb 100644
  --- a/drivers/mtd/spi/winbond.c
  +++ b/drivers/mtd/spi/winbond.c
  @@ -68,6 +68,11 @@ static const struct winbond_spi_flash_params 
  winbond_spi_flash_table[] = {
  .name   = W25Q80,
  },
  {
  +   .id = 0x6016,
  +   .nr_blocks  = 512,
 
  nr_blocks here should have 64 instead of 512.
  please let me know, I will add correction-patch for this.

 You're right, it's a 32Mbit part, so nr_blocks should be 64, thanks
 for finding this.

Thanks for your response.
I just updated on the patch http://patchwork.ozlabs.org/patch/246654/

Please let me know for any issues.

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


Re: [U-Boot] dfu: dfu and UBI Volumes

2013-05-28 Thread Heiko Schocher
Hello Tom,

Am 28.05.2013 23:16, schrieb Tom Rini:
 On Tue, May 28, 2013 at 11:01:09PM +0200, Wolfgang Denk wrote:
 Dear Tom,

 In message 20130528172309.GF5829@bill-the-cat you wrote:

 Of course this can't yet apply to writing files on file systems since the
 current API in U-Boot misses the append feature, but this could be applied 
 to
 program raw memory partitions, including UBI images.

 Correct.  We can write a whole UBI image, today, of NAND size,
 regardless of DDR size.  But modifying UBI volumes (so UBIFS or your

 I don't think so.  To write a UBI volume on an existing UBI device,
 you would use the ubi write command.  This translates into a call of
 ubi_volume_write(char *volume, void *buf, size_t size)  which means
 the size must be known before you start writing; as far as I can tell
 ubi_volume_write() does not support incremental write operations of
 individual parts of a volume.
 
 OK.  A very quick read of ubi_volume_write leads into the guts of the
 write being in drivers/mtd/ubi/upd.c and it feels like you could
 actually do the volume write in chunks with ubi_start_update() and
 ubi_more_update_data() (and maybe some other housekeeping bits).  It
 might take a bit more work since it looks like looks like both functions
 rely on knowing the size at the start, but that's just to make sure the
 size will fit in the volume.

Yes, I think so too ... seems some work, but not unsolveable ...

Hmm.. is it possible to get the filesize over dfu on startup? (I hope
so, as it makes no sense to transfer a file, if it does not fit in the
partition ... )

bye,
Heiko
-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v4 1/7] arm: vf610: Add IOMUX support for Vybrid VF610

2013-05-28 Thread Wang Huan-B18965
Hi, Benoit,

  diff --git a/arch/arm/imx-common/iomux-v3.c
  b/arch/arm/imx-common/iomux-v3.c index 7fe5ce7..35880c7 100644
  --- a/arch/arm/imx-common/iomux-v3.c
  +++ b/arch/arm/imx-common/iomux-v3.c
  @@ -48,8 +48,14 @@ void imx_iomux_v3_setup_pad(iomux_v3_cfg_t pad)
  if (sel_input_ofs)
  __raw_writel(sel_input, base + sel_input_ofs);
 
  +#ifdef CONFIG_IOMUX_SHARE_CONF_REG
 
 Where is this one defined? I don't see it in include/configs/vf610twr.h.
 
[Alison Wang] CONFIG_IOMUX_SHARE_CONF_REG is defined in 
arch/arm/include/asm/arch-vf610/imx-regs.h. Because this is not a board 
configuration, it is related to the SOC.

Please refer to Stefano's comments below which also could be found in the email 
on May 15th.

Stefano wrote:
 +
 +/* MUX mode and PAD ctrl are in one register */
 +#define CONFIG_IOMUX_SHARE_CONF_REG

NAK. This is not a board configuration, it is related to the SOC. This
setup should flow into the related imx-regs.h for this SOC. When you set
CONFIG_MVF600, this value should be set automatically.

 Why not use #ifdef CONFIG_VF610 since this is a platform-dependent
 code, and not a board-specific config option?
[Alison Wang] I use this CONFIG_IOMUX_SHARE_CONF_REG option, because this part 
of codes
not only could be used on VF610 platform, but also could be used on VF620 or 
other platforms.
When it is used on VF620 or others, you could just enable 
CONFIG_IOMUX_SHARE_CONF_REG
in the related imx-regs.h.
Otherwise, if ifdef CONFIG_VF610 is used, you need to add #if 
defined(CONFIG_VF610) || defined(CONFIG_VF620)
When this part of codes is also used on VF620. Then when this part of codes is 
used on VF630 too, this line 
will be very very long.
 
 
  +   if (!(pad_ctrl  NO_PAD_CTRL))
  +   __raw_writel((mux_mode  PAD_MUX_MODE_SHIFT) | pad_ctrl,
  +   base + pad_ctrl_ofs);
  +#else
  if (!(pad_ctrl  NO_PAD_CTRL)  pad_ctrl_ofs)
  __raw_writel(pad_ctrl, base + pad_ctrl_ofs);
  +#endif
   }
 
   void imx_iomux_v3_setup_multiple_pads(iomux_v3_cfg_t const *pad_list,
 
 [...]
 
 Apart from that, this patch is OK.
 
Thanks.

Best Regards,
Alison Wang

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


Re: [U-Boot] [PATCH v4 2/7] arm: vf610: Add Vybrid VF610 CPU support

2013-05-28 Thread Wang Huan-B18965
Hi, Benoit,

 The hunk below is still missing:
 
 doc/README.mxc_ocotp:
 ---
  on MXC
 
  This IP can be found on the following SoCs:
 + - Vybrid VF610,
   - i.MX6.
 
  Note that this IP is different from albeit similar to the IPs of the
 same name
[Alison Wang] It is not missing, it is in the 6/7 patch.
 ---
 
 Apart from that, this patch is correct.
 


Best Regards,
Alison Wang

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


Re: [U-Boot] [PATCH v4 2/7] arm: vf610: Add Vybrid VF610 CPU support

2013-05-28 Thread Wang Huan-B18965
Hi, Benoit,

   diff --git a/doc/README.vf610 b/doc/README.vf610 new file mode
   100644 index 000..38cf5cf
   --- /dev/null
   +++ b/doc/README.vf610
   @@ -0,0 +1,10 @@
   +U-Boot for Freescale Vybrid VF610
   +
   +This file contains information for the port of U-Boot to the
   +Freescale
   Vybrid
   +VF610 SoC.
   +
   +1. CONVENTIONS FOR FUSE ASSIGNMENTS
   +---
   +
   +1.1 MAC Address: It is stored in fuse bank 4, with the 16 msbs in
   +word 2
   and
   the
   +32 lsbs in word 3.
 
  The hunk below is still missing:
 
  doc/README.mxc_ocotp:
  ---
   on MXC
 
   This IP can be found on the following SoCs:
  + - Vybrid VF610,
- i.MX6.
 
   Note that this IP is different from albeit similar to the IPs of the
  same  name
  ---
 
 I have just noticed that this was actually in 6/7. Why are you putting
 this into a separate patch?
[Alison Wang] Because patch 2/7 is about VF610 CPU support, and 
doc/README.vf610 is also a document about
VF610 SoC. Doc/README.mxc_ocotp is the document about a driver (IP OCOTP), so 
this driver document should be
separated from CPU patch 2/7.


Best Regards,
Alison Wang

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


Re: [U-Boot] [PATCH v4 7/7] arm: vf610: Add basic support for Vybrid VF610TWR board

2013-05-28 Thread Wang Huan-B18965
Hi, Benoit,

  +
  +#define CONFIG_CMD_PING
  +#define CONFIG_CMD_DHCP
  +#define CONFIG_CMD_MII
  +#define CONFIG_CMD_NET
  +#define CONFIG_FEC_MXC
  +#define CONFIG_MII
  +#define IMX_FEC_BASE   ENET_BASE_ADDR
  +#define CONFIG_FEC_XCV_TYPERMII
  +#define CONFIG_FEC_MXC_PHYADDR  0
 
 Why don't you add support for the 2nd FEC? Do you plan to do it later?
[Alison Wang] In u-boot, one FEC is enough for user. We do not plan to do it 
later.
 
  +#define CONFIG_PHYLIB
  +#define CONFIG_PHY_MICREL
  +
  +#define CONFIG_BOOTDELAY   3
  +
  +#define CONFIG_SYS_TEXT_BASE   0x3f008000
  +
  +/* Miscellaneous configurable options */
  +#define CONFIG_SYS_LONGHELP/* undef to save memory */
  +#define CONFIG_SYS_HUSH_PARSER /* use hush command parser
 */
  +#define CONFIG_SYS_PROMPT_HUSH_PS2  
  +#define CONFIG_SYS_PROMPT  Vybrid U-Boot  
  +#undef CONFIG_AUTO_COMPLETE
  +#define CONFIG_SYS_CBSIZE  256 /* Console I/O Buffer Size */
  +#define CONFIG_SYS_PBSIZE  \
  +   (CONFIG_SYS_CBSIZE + sizeof(CONFIG_SYS_PROMPT) + 16)
  +#define CONFIG_SYS_MAXARGS 16  /* max number of command args
 */
  +#define CONFIG_SYS_BARGSIZECONFIG_SYS_CBSIZE
  +
  +#define CONFIG_CMD_MEMTEST
  +#define CONFIG_SYS_MEMTEST_START   0x8001
  +#define CONFIG_SYS_MEMTEST_END 0x87C0
 
 Please make sure to have runtime-tested this address range with the
 mtest command since bad mtest addresses are the reason why
 CONFIG_CMD_MEMTEST has been removed from the default commands.
[Alison Wang] Thanks for your reminder, we have tested.
 

Best Regards,
Alison Wang




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