[U-Boot] Bricked when trying to attach UBI

[Luca Ceresoli]

Hi all,

I am facing a problem with some boards that do not boot after some
weeks or months of normal usage, being unable to attach UBI. They do
not boot anymore event after a power cycle, in other words they are
totally bricked.
I don't know exactly what problem UBI has, but it is recoverable by
Linux, but apparently not by U-Boot.

The boards are DIG297 (dig297 board in mainline U-Boot), based on
OMAP3530 and equipped with a NAND flash (Micron MT29F2G16ABBEAHC) as
their unique permanent storage.

U-Boot v2012.04.01 starts correctly. The bootcmd tries to load the
kernel from UBI, starting with the following commands:

echo Booting from nand ...
setenv bootargs console=ttyO2,115200n8 
mtdparts=omap2-nand.0:768k(uboot),128k(reserved),128k(uboot-env),-(ubi) 
ubi.mtd=3 root=ubi0:rootfs ro rootfstype=ubifs ip=

ubi part nand0,3
...

On bricked devices the output of the ubi part nand0,3 command is:

Creating 1 MTD partitions on nand0:
0x0010-0x1000 : mtd=3
UBI: attaching mtd1 to ubi0
UBI: physical eraseblock size:   131072 bytes (128 KiB)
UBI: logical eraseblock size:129024 bytes
UBI: smallest flash I/O unit:2048
UBI: sub-page size:  512
UBI: VID header offset:  512 (aligned 512)
UBI: data offset:2048
UBI error: ubi_wl_init_scan: no enough physical eraseblocks (0, need 1)

Now the device is totally blocked, and power cycling does not change
the result.

The interesting thing is that if I load Linux (2.6.37 + OMAP patches +
board support patches) via TFTP and boot it with bootm, it correctly
attaches UBI (fixing any problem it may have) and boots correctly.
After that the board is unbricked: U-Boot can boot again normally from
NAND.

Without the ambition of understanding all UBI internals, I tried to
visually inspect the UBI code around the line where the error is
produced and compare it to the corresponding Linux sources. They looked
extremely similar, so I haven't and obvious hint of why U-Boot and
Linux produce different results.

I also tried with an updated U-Boot master, but the error is still
there.

Obviously I have changed nothing in the UBI and MTD code, both in
U-Boot and in Linux.

Can you suggest a proper way to track the root of the problem, or to
bypass it?

Big thanks in advance,

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

Re: [U-Boot] [PATCH 4/4] sf: Add Quad-input Page Program(32h) instruction support

[Jagan Teki]

Hi Simon,

On Fri, Dec 14, 2012 at 7:06 AM, Simon Glass s...@chromium.org wrote:
 +Mike

 Hi,

 On Thu, Dec 13, 2012 at 8:21 AM, Jagan Teki jagannadh.t...@gmail.com wrote:
 Hi Simon,

 On Thu, Dec 13, 2012 at 4:08 AM, Simon Glass s...@chromium.org wrote:
 Hi Jagan,

 On Wed, Dec 12, 2012 at 8:52 AM, Jagan Teki jagannadh.t...@gmail.com 
 wrote:
 Hi Simon,

 On Wed, Dec 12, 2012 at 12:11 PM, Simon Glass s...@chromium.org wrote:
 Hi,

 On Mon, Dec 10, 2012 at 6:42 AM, Jagannadha Sutradharudu Teki
 jagannadh.t...@gmail.com wrote:
 This patch provides support to program a flash using
 Quad-input Page Program(32h) instruction.

 This will effectively increases the data transfer rate
 by up to four times, as compared to the Page Program(PP) instruction.

 Respective flash drivers need to use spi_flash_cmd_write_multi_qpp()
 based on their usage.

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

 It's great to have this support. A few comments below.

 Thanks.


 ---
  README   |1 +
  common/cmd_sf.c  |   12 +++-
  drivers/mtd/spi/spi_flash.c  |  108 
 ++
  drivers/mtd/spi/spi_flash_internal.h |   13 
  include/spi_flash.h  |   12 
  5 files changed, 144 insertions(+), 2 deletions(-)

 diff --git a/README b/README
 index 5a86ae9..a01de13 100644
 --- a/README
 +++ b/README
 @@ -869,6 +869,7 @@ The following options need to be configured:
 CONFIG_CMD_SETGETDCR  Support for DCR Register access
   (4xx only)
 CONFIG_CMD_SF   * Read/write/erase SPI NOR flash
 +   CONFIG_CMD_SF_QPP   * Program SPI flash using 
 Quad-input Page Program
 CONFIG_CMD_SHA1SUMprint sha1 memory digest
   (requires CONFIG_CMD_MEMORY)
 CONFIG_CMD_SOURCE source command Support
 diff --git a/common/cmd_sf.c b/common/cmd_sf.c
 index 5ac1d0c..a449d2c 100644
 --- a/common/cmd_sf.c
 +++ b/common/cmd_sf.c
 @@ -228,6 +228,10 @@ static int do_spi_flash_read_write(int argc, char * 
 const argv[])
 ret = spi_flash_update(flash, offset, len, buf);
 else if (strcmp(argv[0], read) == 0)
 ret = spi_flash_read(flash, offset, len, buf);
 +#ifdef CONFIG_CMD_SF_QPP
 +   else if (strcmp(argv[0], write.qpp) == 0)
 +   ret = spi_flash_write_qpp(flash, offset, len, buf);
 +#endif
 else
 ret = spi_flash_write(flash, offset, len, buf);

 @@ -300,7 +304,7 @@ static int do_spi_flash(cmd_tbl_t *cmdtp, int flag, 
 int argc, char * const argv[
 }

 if (strcmp(cmd, read) == 0 || strcmp(cmd, write) == 0 ||
 -   strcmp(cmd, update) == 0)
 +   strcmp(cmd, update) == 0 || strcmp(cmd, write.qpp) == 0)
 ret = do_spi_flash_read_write(argc, argv);
 else if (strcmp(cmd, erase) == 0)
 ret = do_spi_flash_erase(argc, argv);
 @@ -327,5 +331,9 @@ U_BOOT_CMD(
 sf erase offset [+]len - erase `len' bytes from 
 `offset'\n
  `+len' round up `len' to block 
 size\n
 sf update addr offset len  - erase and write `len' bytes 
 from memory\n
 -at `addr' to flash at `offset'
 +at `addr' to flash at 
 `offset'\n
 +#ifdef CONFIG_CMD_SF_QPP
 +   sf write.qpp addr offset len   - write `len' bytes from 
 memory\n
 +at `addr' to flash at `offset' 
 using Quad-input Page Program(32h)
 +#endif
  );
 diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
 index a8f0af0..3545f59 100644
 --- a/drivers/mtd/spi/spi_flash.c
 +++ b/drivers/mtd/spi/spi_flash.c
 @@ -122,6 +122,114 @@ int spi_flash_cmd_write_multi(struct spi_flash 
 *flash, u32 offset,
 return ret;
  }

 +#ifdef CONFIG_CMD_SF_QPP
 +int spi_flash_set_quad_enable_bit(struct spi_flash *flash)
 +{
 +   u8 cmd = CMD_READ_CONFIG;
 +   u8 data = 0;
 +   int ret;
 +
 +   ret = spi_flash_read_common(flash,
 +   cmd, sizeof(cmd), data, sizeof(data));
 +   if (ret  0) {
 +   debug(SF: fail to read config register\n);
 +   return ret;
 +   }
 +
 +   if (data  0x2) {

 Can we have defines/enums for this please?

 Yes I will do.


 +   debug(SF: quad enable bit is already set.\n);
 +   return ret;
 +   } else {
 +   debug(SF: need to set quad enable bit\n);
 +
 +   ret = spi_flash_cmd_write_config(flash, 0x0200);

 and here?

 Ok.


 +   if (ret  0) {
 +   debug(SF: fail to write quad enable bit\n);
 +   return ret;
 +   }
 +
 +   ret = spi_flash_read_common(flash,
 +

[U-Boot] u-boot Makefile Questions

[chuck huang]

Dear all,

I have some questions about u-boot Makefile.

Could you help me ?

Thx!

The below is my question.

First, we do make _depend for those $(SUBDIRS) $(CPUDIR)
$(LDSCRIPT_MAKEFILE_DIR)

depend dep: $(TIMESTAMP_FILE) $(VERSION_FILE) \
$(obj)include/autoconf.mk \
$(obj)include/generated/generic-asm-offsets.h \
$(obj)include/generated/asm-offsets.h
for dir in $(SUBDIRS) $(CPUDIR) $(LDSCRIPT_MAKEFILE_DIR) ;
do \
$(MAKE) -C $$dir _depend ; done

after we already generated the .depend file in those dirs.

$(SUBDIRS): depend
$(MAKE) -C $@ all

That would do make action in SUBDIRS dir.
But why we also sinclude .depend in those Makefile which is base on
those dir ? I regard that we already generated before.

And another questions, how does the other sub-dir(eg, libs) .depend
file generated ? is that generated by rules.mk which is include every
sub-dirs?


Best regards



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

[U-Boot] configuring u-boot for custom board based on beaglebone(am335xx_evm)

[Pavan]

Hi,

   i need to configure u-boot-2013.01.rc2 for my custom board, that
is completely based on beaglebone Rev A3,i have mux.h file according to my
hardware i am not understanding the codeflow of beaglebone for include the
mux.h.

i have some extra hardware on my board,but first i need to understand the
codeflow for beaglebone then only i can change the all required files
according to my hardware.

Can you please tell me which are the files i need to change? or u-boot is
using pin-mux for baglebone?

I checked the file include/configs/am335x_evm.h and also in board/ti/am335x
directory the mux.c is there,but i didn't  understand the codeflow properly?

Please help me out?


Regards
Pavan   




--
View this message in context: 
http://u-boot.10912.n7.nabble.com/configuring-u-boot-for-custom-board-based-on-beaglebone-am335xx-evm-tp143228.html
Sent from the U-Boot mailing list archive at Nabble.com.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] configuring u-boot for custom board based on beaglebone(am335xx_evm)

[Yegor Yefremov]

On Wed, Dec 19, 2012 at 3:07 PM, Pavan pavanpatil.elec...@gmail.com wrote:
 Hi,

i need to configure u-boot-2013.01.rc2 for my custom board, that
 is completely based on beaglebone Rev A3,i have mux.h file according to my
 hardware i am not understanding the codeflow of beaglebone for include the
 mux.h.

 i have some extra hardware on my board,but first i need to understand the
 codeflow for beaglebone then only i can change the all required files
 according to my hardware.

 Can you please tell me which are the files i need to change? or u-boot is
 using pin-mux for baglebone?

No

 I checked the file include/configs/am335x_evm.h and also in board/ti/am335x
 directory the mux.c is there,but i didn't  understand the codeflow properly?

As you can see mux.c provides pinmuxes for dedicated hardware parts
like UART, I2C etc. In  enable_board_pin_mux() u-boot decides what
board it is running on and activates relevant hardware parts. main
line kernel makes the same. This was different for am3517 though.

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

Re: [U-Boot] configuring u-boot for custom board based on beaglebone(am335xx_evm)

[Pavan]

Hi Yegor,

Thanks for quick reply,

  in u-boot source code to change the beagleboard -xM pin mux we
can change by updating the file board/ti/beagle/beagle.h by changing the
MUX_BEAGLE() micro ,how can i access the same thing for beaglebone?


Regards
Pavan





--
View this message in context: 
http://u-boot.10912.n7.nabble.com/configuring-u-boot-for-custom-board-based-on-beaglebone-am335xx-evm-tp143228p143231.html
Sent from the U-Boot mailing list archive at Nabble.com.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Bricked when trying to attach UBI

[Andreas Bießmann]

Dear Luca Ceresoli,

On 19.12.2012 12:28, Luca Ceresoli wrote:
 Hi all,
 
 I am facing a problem with some boards that do not boot after some
 weeks or months of normal usage, being unable to attach UBI. They do
 not boot anymore event after a power cycle, in other words they are
 totally bricked.
 I don't know exactly what problem UBI has, but it is recoverable by
 Linux, but apparently not by U-Boot.
 
 The boards are DIG297 (dig297 board in mainline U-Boot), based on
 OMAP3530 and equipped with a NAND flash (Micron MT29F2G16ABBEAHC) as
 their unique permanent storage.
 
 U-Boot v2012.04.01 starts correctly. The bootcmd tries to load the
 kernel from UBI, starting with the following commands:
 
 echo Booting from nand ...
 setenv bootargs console=ttyO2,115200n8
 mtdparts=omap2-nand.0:768k(uboot),128k(reserved),128k(uboot-env),-(ubi)
 ubi.mtd=3 root=ubi0:rootfs ro rootfstype=ubifs ip=
 ubi part nand0,3
 ...
 
 On bricked devices the output of the ubi part nand0,3 command is:
 
 Creating 1 MTD partitions on nand0:
 0x0010-0x1000 : mtd=3
 UBI: attaching mtd1 to ubi0
 UBI: physical eraseblock size:   131072 bytes (128 KiB)
 UBI: logical eraseblock size:129024 bytes
 UBI: smallest flash I/O unit:2048
 UBI: sub-page size:  512
 UBI: VID header offset:  512 (aligned 512)
 UBI: data offset:2048
 UBI error: ubi_wl_init_scan: no enough physical eraseblocks (0, need 1)
 
 Now the device is totally blocked, and power cycling does not change
 the result.

have you tried to increase the malloc arena in u-boot
(CONIG_SYS_MALLOC_LEN)?
We had errors like this before [1],[2] and [3], maybe others -
apparently with another error message, but please give it a try. We know
ubi recovery needs some ram and 1MiB may be not enough.

 The interesting thing is that if I load Linux (2.6.37 + OMAP patches +
 board support patches) via TFTP and boot it with bootm, it correctly
 attaches UBI (fixing any problem it may have) and boots correctly.
 After that the board is unbricked: U-Boot can boot again normally from
 NAND.

The fact that linux can recover with a quite old version points for me
towards 'environment constraints' like to few memory in u-boot.
Unfortunately the error messages in u-boots ubi sometimes missing such
details (like -ENOMEM as in [1]).

Best regards

Andreas Bießmann

[1] http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/124769
[2] http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/145526
[3] http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/145655
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] split nand writes

[Jaap de Jong]

Hi All,
suppose the image I want to flash is bigger than the available ram in 
the unit.

Is there a way to copy the image f.i. in pieces into the flash?
nand write should have a 'continue on last block' option for that purpose.
Thanks!
Jaap
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Bricked when trying to attach UBI

[Luca Ceresoli]

Hi Andreas,

Andreas Bießmann wrote:
...

Creating 1 MTD partitions on nand0:
0x0010-0x1000 : mtd=3
UBI: attaching mtd1 to ubi0
UBI: physical eraseblock size:   131072 bytes (128 KiB)
UBI: logical eraseblock size:129024 bytes
UBI: smallest flash I/O unit:2048
UBI: sub-page size:  512
UBI: VID header offset:  512 (aligned 512)
UBI: data offset:2048
UBI error: ubi_wl_init_scan: no enough physical eraseblocks (0, need 1)

Now the device is totally blocked, and power cycling does not change
the result.


have you tried to increase the malloc arena in u-boot
(CONIG_SYS_MALLOC_LEN)?
We had errors like this before [1],[2] and [3], maybe others -
apparently with another error message, but please give it a try. We know
ubi recovery needs some ram and 1MiB may be not enough.


Thanks for your suggestion.

Unfortunately this does not seem to be the cause of my problem: I tried
increasing my CONFIG_SYS_MALLOC_LEN in include/configs/dig297.h from
(1024  10) to both (1024  12) and (1024  14), but without any
difference.

Luca

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

Re: [U-Boot] Bricked when trying to attach UBI

[Andreas Bießmann]

Hi Luca,

On 19.12.2012 16:56, Luca Ceresoli wrote:
 Hi Andreas,
 
 Andreas Bießmann wrote:
 ...
 Creating 1 MTD partitions on nand0:
 0x0010-0x1000 : mtd=3
 UBI: attaching mtd1 to ubi0
 UBI: physical eraseblock size:   131072 bytes (128 KiB)
 UBI: logical eraseblock size:129024 bytes
 UBI: smallest flash I/O unit:2048
 UBI: sub-page size:  512
 UBI: VID header offset:  512 (aligned 512)
 UBI: data offset:2048
 UBI error: ubi_wl_init_scan: no enough physical eraseblocks (0, need 1)

 Now the device is totally blocked, and power cycling does not change
 the result.

 have you tried to increase the malloc arena in u-boot
 (CONIG_SYS_MALLOC_LEN)?
 We had errors like this before [1],[2] and [3], maybe others -
 apparently with another error message, but please give it a try. We know
 ubi recovery needs some ram and 1MiB may be not enough.
 
 Thanks for your suggestion.
 
 Unfortunately this does not seem to be the cause of my problem: I tried
 increasing my CONFIG_SYS_MALLOC_LEN in include/configs/dig297.h from
 (1024  10) to both (1024  12) and (1024  14), but without any
 difference.

Well, ok ... Malloc arena is always my first thought if I read about
problems with ubi in u-boot.
Have you looked up the differences in drivers/mtd/ubi/ in your u-boot
and linux tree? Maybe you can see something obviously different in the
ubi_wl_init_scan()?

Best regards

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

[U-Boot] [U-Boot,v2 3/6] sf: Add status register reading support

[Jagannadha Sutradharudu Teki]

This patch provides support to read a flash status register.

Status register contains a control bits used to verify
the progress of flash program and erase operations.

User need to get the data through spi_flash_cmd_read_status()
based on their usage.

Signed-off-by: Jagannadha Sutradharudu Teki jagannadh.t...@gmail.com
---
Changes in v2:none

 drivers/mtd/spi/spi_flash.c  |   15 +++
 drivers/mtd/spi/spi_flash_internal.h |3 +++
 2 files changed, 18 insertions(+), 0 deletions(-)

diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
index 9e8939c..bf5ec4a 100644
--- a/drivers/mtd/spi/spi_flash.c
+++ b/drivers/mtd/spi/spi_flash.c
@@ -264,6 +264,21 @@ int spi_flash_cmd_write_status(struct spi_flash *flash, u8 
sr)
return 0;
 }
 
+int spi_flash_cmd_read_status(struct spi_flash *flash, void *data)
+{
+   u8 cmd;
+   int ret;
+
+   cmd = CMD_READ_STATUS;
+   ret = spi_flash_read_common(flash, cmd, sizeof(cmd), (void *)data, 1);
+   if (ret  0) {
+   debug(SF: fail to read status register\n);
+   return ret;
+   }
+
+   return 0;
+}
+
 /*
  * The following table holds all device probe functions
  *
diff --git a/drivers/mtd/spi/spi_flash_internal.h 
b/drivers/mtd/spi/spi_flash_internal.h
index 141cfa8..8232595 100644
--- a/drivers/mtd/spi/spi_flash_internal.h
+++ b/drivers/mtd/spi/spi_flash_internal.h
@@ -77,6 +77,9 @@ static inline int spi_flash_cmd_write_disable(struct 
spi_flash *flash)
 /* Program the status register. */
 int spi_flash_cmd_write_status(struct spi_flash *flash, u8 sr);
 
+/* Read the status register */
+int spi_flash_cmd_read_status(struct spi_flash *flash, void *data);
+
 /*
  * Same as spi_flash_cmd_read() except it also claims/releases the SPI
  * bus. Used as common part of the -read() operation.
-- 
1.7.0.4

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

[U-Boot] [U-Boot, v2 1/6] cmd_sf: Add print messages on flash erase command

[Jagannadha Sutradharudu Teki]

This patch adds a print messages while using 'sf erase' command
to make sure that how many bytes erased in flash device.

Signed-off-by: Jagannadha Sutradharudu Teki jagannadh.t...@gmail.com
---
Changes in v2:
Move print messages from spi_flash.c into cmd_sf.c

 common/cmd_sf.c |   11 ++-
 drivers/mtd/spi/spi_flash.c |2 --
 2 files changed, 6 insertions(+), 7 deletions(-)

diff --git a/common/cmd_sf.c b/common/cmd_sf.c
index 5ac1d0c..ddb1a65 100644
--- a/common/cmd_sf.c
+++ b/common/cmd_sf.c
@@ -266,13 +266,14 @@ static int do_spi_flash_erase(int argc, char * const 
argv[])
return 1;
}
 
+   printf(SF: Erasing flash... );
+
ret = spi_flash_erase(flash, offset, len);
-   if (ret) {
-   printf(SPI flash %s failed\n, argv[0]);
-   return 1;
-   }
 
-   return 0;
+   printf(%zu bytes @ %#x erased: %s\n, (size_t)len, (u32)offset,
+   ret ? ERROR : OK);
+
+   return ret == 0 ? 0 : 1;
 }
 
 static int do_spi_flash(cmd_tbl_t *cmdtp, int flag, int argc, char * const 
argv[])
diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
index 00aece9..43e0334 100644
--- a/drivers/mtd/spi/spi_flash.c
+++ b/drivers/mtd/spi/spi_flash.c
@@ -235,8 +235,6 @@ int spi_flash_cmd_erase(struct spi_flash *flash, u32 
offset, size_t len)
goto out;
}
 
-   debug(SF: Successfully erased %zu bytes @ %#x\n, len, start);
-
  out:
spi_release_bus(flash-spi);
return ret;
-- 
1.7.0.4

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

[U-Boot] [U-Boot,v2 5/6] sf: Add config register reading support

[Jagannadha Sutradharudu Teki]

This patch provides support to read a flash config register.

Config register contains a control bits used to verify
the different configurations and security features of a device.

User need to get the data through spi_flash_cmd_read_config()
based on their usage.

Signed-off-by: Jagannadha Sutradharudu Teki jagannadh.t...@gmail.com
---
Changes in v2: none

 drivers/mtd/spi/spi_flash.c  |   15 +++
 drivers/mtd/spi/spi_flash_internal.h |4 
 2 files changed, 19 insertions(+), 0 deletions(-)

diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
index cad6c40..5bddde4 100644
--- a/drivers/mtd/spi/spi_flash.c
+++ b/drivers/mtd/spi/spi_flash.c
@@ -314,6 +314,21 @@ int spi_flash_cmd_write_config(struct spi_flash *flash, u8 
cr)
return 0;
 }
 
+int spi_flash_cmd_read_config(struct spi_flash *flash, void *data)
+{
+   u8 cmd;
+   int ret;
+
+   cmd = CMD_READ_CONFIG;
+   ret = spi_flash_read_common(flash, cmd, sizeof(cmd), (void *)data, 1);
+   if (ret  0) {
+   debug(SF: fail to read config register\n);
+   return ret;
+   }
+
+   return 0;
+}
+
 /*
  * The following table holds all device probe functions
  *
diff --git a/drivers/mtd/spi/spi_flash_internal.h 
b/drivers/mtd/spi/spi_flash_internal.h
index 825b398..844e82e 100644
--- a/drivers/mtd/spi/spi_flash_internal.h
+++ b/drivers/mtd/spi/spi_flash_internal.h
@@ -22,6 +22,7 @@
 #define CMD_PAGE_PROGRAM   0x02
 #define CMD_WRITE_DISABLE  0x04
 #define CMD_READ_STATUS0x05
+#define CMD_READ_CONFIG0x35
 #define CMD_WRITE_ENABLE   0x06
 #define CMD_ERASE_4K   0x20
 #define CMD_ERASE_32K  0x52
@@ -83,6 +84,9 @@ int spi_flash_cmd_read_status(struct spi_flash *flash, void 
*data);
 /* Program the config register. */
 int spi_flash_cmd_write_config(struct spi_flash *flash, u8 cr);
 
+/* Read the config register */
+int spi_flash_cmd_read_config(struct spi_flash *flash, void *data);
+
 /*
  * Same as spi_flash_cmd_read() except it also claims/releases the SPI
  * bus. Used as common part of the -read() operation.
-- 
1.7.0.4

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

[U-Boot] [U-Boot,v2 6/6] sf: Set QUAD enable bit support

[Jagannadha Sutradharudu Teki]

This patch provides support to set the QUAD enable bit on flash.

QUAD enable bit needs to set before performing any QUAD IO operations
on respective SPI flashes.

User need to use spi_flash_set_quad_enable_bit() to set the
QUAD enable bit based on their usage.

Signed-off-by: Jagannadha Sutradharudu Teki jagannadh.t...@gmail.com
---
Changes in v2:
Improved code logic

 drivers/mtd/spi/spi_flash.c  |   31 +++
 drivers/mtd/spi/spi_flash_internal.h |4 
 2 files changed, 35 insertions(+), 0 deletions(-)

diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
index 5bddde4..675a0bf 100644
--- a/drivers/mtd/spi/spi_flash.c
+++ b/drivers/mtd/spi/spi_flash.c
@@ -329,6 +329,37 @@ int spi_flash_cmd_read_config(struct spi_flash *flash, 
void *data)
return 0;
 }
 
+int spi_flash_set_quad_enable_bit(struct spi_flash *flash)
+{
+   u8 data = 0, write_done = 0;
+   int ret, pass;
+
+   for (pass = 0; pass  2; pass++) {
+   ret = spi_flash_cmd_read_config(flash, (void *)data);
+   if (ret  0) {
+   debug(SF: fail to read config register\n);
+   return ret;
+   }
+
+   if (data  STATUS_QEB) {
+   debug(SF: quad enable bit is set.\n);
+   return ret;
+   } else if (write_done != 1) {
+   debug(SF: need to set quad enable bit\n);
+
+   write_done = 1;
+   ret = spi_flash_cmd_write_config(flash, STATUS_QEB);
+   if (ret  0) {
+   debug(SF: fail to write quad enable bit\n);
+   return ret;
+   }
+   }
+   }
+
+   debug(SF: fail to set quad enable bit\n);
+   return -1;
+}
+
 /*
  * The following table holds all device probe functions
  *
diff --git a/drivers/mtd/spi/spi_flash_internal.h 
b/drivers/mtd/spi/spi_flash_internal.h
index 844e82e..15c7ac4 100644
--- a/drivers/mtd/spi/spi_flash_internal.h
+++ b/drivers/mtd/spi/spi_flash_internal.h
@@ -31,6 +31,7 @@
 
 /* Common status */
 #define STATUS_WIP 0x01
+#define STATUS_QEB 0x02
 
 /* Send a single-byte command to the device and read the response */
 int spi_flash_cmd(struct spi_slave *spi, u8 cmd, void *response, size_t len);
@@ -87,6 +88,9 @@ int spi_flash_cmd_write_config(struct spi_flash *flash, u8 
cr);
 /* Read the config register */
 int spi_flash_cmd_read_config(struct spi_flash *flash, void *data);
 
+/* Set the QUAD enable bit */
+int spi_flash_set_quad_enable_bit(struct spi_flash *flash);
+
 /*
  * Same as spi_flash_cmd_read() except it also claims/releases the SPI
  * bus. Used as common part of the -read() operation.
-- 
1.7.0.4

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

Re: [U-Boot] please pull u-boot-samsung/resolve

[Albert ARIBAUD]

Hi Minkyu,

On Tue, 18 Dec 2012 00:14:34 +0900, Minkyu Kang proms...@gmail.com
wrote:
 Dear Albert,
 
 On Saturday, December 15, 2012, Albert ARIBAUD wrote:
 
  Hi Minkyu,
 
  On Fri, 14 Dec 2012 09:14:11 +0900, Minkyu Kang 
  mk7.k...@samsung.comjavascript:;
  
  wrote:
   On 14/12/12 04:56, Albert ARIBAUD wrote:
Hi Minkyu,
   
On Tue, 11 Dec 2012 20:10:06 +0900, Minkyu Kang mk7.k...@samsung.com
wrote:
Dear Albert,
   
The following changes since commit
  fd4d564b3c80b111f18c93adb14233a6a7ddb0e9:
   
  Merge branch 'master' of git://git.denx.de/u-boot-x86 (2012-12-07
  08:47:59 -0700)
   
are available in the git repository at:
   
   
  git://git.denx.de/u-boot-samsung resolve
   
for you to fetch changes up to
  fbef8e6e7f1233ed20f8c5045e12c9cf31b43540:
   
  universal_c210: check the NULL pointer when get the PMIC
  (2012-12-11 17:37:28 +0900)
   

Albert ARIBAUD (1):
  Merge branch 'u-boot-imx/master' into 'u-boot-arm/master'
   
Allen Martin (1):
  tegra: add CONSOLE_MUX support to tegra-kbc
   
Ashok Kumar Reddy (1):
  ARM: arm1176: Define arch_cpu_init() for s3c64xx
   
Benoît Thébaudeau (17):
  arm1136: Fix enable_caches()
  mx31: Move EHCI definitions to ehci-fsl.h
  ehci-mxc: Clean up
  ehci-mx5: Clean up
  ehci-mx5: Fix OC_DIS usage
  ehci-mx5: Fix OPM usage
  ehci-mx5: Fix *PM usage for i.MX53
  ehci-mx5: Add missing OC_DIS for i.MX53
  ehci-mxc: Make EHCI power/oc polarities configurable
  ehci-mxc: Make i.MX25 EHCI configurable
  ehci-mxc: Define host offsets
  ehci-mxc: Add support for i.MX35
  mx35pdk: Add support for OTG
  ehci-mx5/6: Make board_ehci_hcd_init() optional
  ehci-mxc: Fix host power mask bit for i.MX35
  ehci-mxc: Fix host power mask bit for i.MX25
  mx5: Mark lowlevel_init board-specific code
   
Chander Kashyap (1):
  Exynos5250: Enable PXE Support
   
Fabio Estevam (24):
  mx25pdk: Include CONFIG_MX25
  mx25pdk: Add esdhc support
  pmic_fsl: Introduce FSL_PMIC_I2C_LENGTH
  mx25: Place common functions into sys_proto.h
  pmic: Add support for mc34704
  mx25pdk: Add Ethernet support
  mx53loco: Allow booting a zImage kernel
  mx25pdk: Allow booting a zImage kernel
  mx51evk: Allow booting a zImage kernel
  mx35pdk: Allow booting a zImage kernel
  mx6qsabre_common: Allow booting a zImage kernel
  mx5: Align SPI CS naming with i.MX53 reference manual
  mx5: Print CSPI clock in 'clock' command
  spi: mxc_spi: Fix handling of chip select
  spi: mxc_spi: Fix spi clock glitch durant reset
  mx6: clock: Only show CSPI clock if CSPI is enabled
  mx28evk: Configure CONFIG_BOOTDELAY to one second
  mx53loco: Configure CONFIG_BOOTDELAY to one second
  mx6qsabrelite: Configure CONFIG_BOOTDELAY to one second
  mx6qsabre_common: Configure CONFIG_BOOTDELAY to one second
  mx51evk: Configure CONFIG_BOOTDELAY to one second
  mx25pdk: Configure CONFIG_BOOTDELAY to one sYou're right. I was
  a bit quick to reply when I read Stephen's
  question. Can you please address it too?
 
 Address for what?

Can you answer the question Stephen has asked on this list on 11/12 ?

http://www.mail-archive.com/u-boot@lists.denx.de/msg101291.html

 Thanks.
 Minkyu Kang.

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

[U-Boot] [U-Boot, v2 4/6] sf: Add configuration register writing support

[Jagannadha Sutradharudu Teki]

This patch provides support to program a flash config register.

Configuration register contains the control bits used to configure
the different configurations and security features of a device.

User need to set these bits through spi_flash_cmd_write_config()
based on their usage.

Signed-off-by: Jagannadha Sutradharudu Teki jagannadh.t...@gmail.com
---
Changes in v2:
Improved code logic 

 drivers/mtd/spi/spi_flash.c  |   35 ++
 drivers/mtd/spi/spi_flash_internal.h |3 ++
 2 files changed, 38 insertions(+), 0 deletions(-)

diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
index bf5ec4a..cad6c40 100644
--- a/drivers/mtd/spi/spi_flash.c
+++ b/drivers/mtd/spi/spi_flash.c
@@ -279,6 +279,41 @@ int spi_flash_cmd_read_status(struct spi_flash *flash, 
void *data)
return 0;
 }
 
+int spi_flash_cmd_write_config(struct spi_flash *flash, u8 cr)
+{
+   u8 data[2];
+   u8 cmd;
+   int ret;
+
+   ret = spi_flash_cmd_read_status(flash, (void *)data[0]);
+   if (ret  0) {
+   debug(SF: fail to read status register\n);
+   return ret;
+   }
+
+   ret = spi_flash_cmd_write_enable(flash);
+   if (ret  0) {
+   debug(SF: enabling write failed\n);
+   return ret;
+   }
+
+   cmd = CMD_WRITE_STATUS;
+   data[1] = cr;
+   ret = spi_flash_cmd_write(flash-spi, cmd, 1, data, 2);
+   if (ret) {
+   debug(SF: fail to write config register\n);
+   return ret;
+   }
+
+   ret = spi_flash_cmd_wait_ready(flash, SPI_FLASH_PROG_TIMEOUT);
+   if (ret  0) {
+   debug(SF: write config register timed out\n);
+   return ret;
+   }
+
+   return 0;
+}
+
 /*
  * The following table holds all device probe functions
  *
diff --git a/drivers/mtd/spi/spi_flash_internal.h 
b/drivers/mtd/spi/spi_flash_internal.h
index 8232595..825b398 100644
--- a/drivers/mtd/spi/spi_flash_internal.h
+++ b/drivers/mtd/spi/spi_flash_internal.h
@@ -80,6 +80,9 @@ int spi_flash_cmd_write_status(struct spi_flash *flash, u8 
sr);
 /* Read the status register */
 int spi_flash_cmd_read_status(struct spi_flash *flash, void *data);
 
+/* Program the config register. */
+int spi_flash_cmd_write_config(struct spi_flash *flash, u8 cr);
+
 /*
  * Same as spi_flash_cmd_read() except it also claims/releases the SPI
  * bus. Used as common part of the -read() operation.
-- 
1.7.0.4

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

[U-Boot] [U-Boot, v2 2/6] cmd_sf: Add print messages on flash read/write commands

[Jagannadha Sutradharudu Teki]

This patch adds a print messages while using 'sf read' and
'sf write' commands to make sure that how many bytes read/written
from/into flash device.

Signed-off-by: Jagannadha Sutradharudu Teki jagannadh.t...@gmail.com
---
Changes in v2:
Move print messages from spi_flash.c into cmd_sf.c

 common/cmd_sf.c |   26 --
 drivers/mtd/spi/spi_flash.c |3 ---
 2 files changed, 16 insertions(+), 13 deletions(-)

diff --git a/common/cmd_sf.c b/common/cmd_sf.c
index ddb1a65..efdd640 100644
--- a/common/cmd_sf.c
+++ b/common/cmd_sf.c
@@ -196,7 +196,7 @@ static int do_spi_flash_read_write(int argc, char * const 
argv[])
unsigned long len;
void *buf;
char *endp;
-   int ret;
+   int ret = 0;
 
if (argc  4)
return -1;
@@ -226,19 +226,25 @@ static int do_spi_flash_read_write(int argc, char * const 
argv[])
 
if (strcmp(argv[0], update) == 0)
ret = spi_flash_update(flash, offset, len, buf);
-   else if (strcmp(argv[0], read) == 0)
-   ret = spi_flash_read(flash, offset, len, buf);
-   else
-   ret = spi_flash_write(flash, offset, len, buf);
+   else if (strncmp(argv[0], read, 4) == 0 ||
+   strncmp(argv[0], write, 5) == 0) {
+   int read;
 
-   unmap_physmem(buf, len);
+   read = strncmp(argv[0], read, 4) == 0;
+   printf(SF: %s flash... , read ? Reading : Writing);
 
-   if (ret) {
-   printf(SPI flash %s failed\n, argv[0]);
-   return 1;
+   if (read)
+   ret = spi_flash_read(flash, offset, len, buf);
+   else
+   ret = spi_flash_write(flash, offset, len, buf);
+
+   printf(%zu bytes @ %#x %s: %s\n, (size_t)len, (u32)offset,
+   read ? read : written, ret ? ERROR : OK);
}
 
-   return 0;
+   unmap_physmem(buf, len);
+
+   return ret == 0 ? 0 : 1;
 }
 
 static int do_spi_flash_erase(int argc, char * const argv[])
diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
index 43e0334..9e8939c 100644
--- a/drivers/mtd/spi/spi_flash.c
+++ b/drivers/mtd/spi/spi_flash.c
@@ -115,9 +115,6 @@ int spi_flash_cmd_write_multi(struct spi_flash *flash, u32 
offset,
byte_addr = 0;
}
 
-   debug(SF: program %s %zu bytes @ %#x\n,
- ret ? failure : success, len, offset);
-
spi_release_bus(flash-spi);
return ret;
 }
-- 
1.7.0.4

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

Re: [U-Boot] Bricked when trying to attach UBI

[Luca Ceresoli]

Hi Andreas,

Andreas Bießmann wrote:

Hi Luca,

On 19.12.2012 16:56, Luca Ceresoli wrote:

Hi Andreas,

Andreas Bießmann wrote:
...

Creating 1 MTD partitions on nand0:
0x0010-0x1000 : mtd=3
UBI: attaching mtd1 to ubi0
UBI: physical eraseblock size:   131072 bytes (128 KiB)
UBI: logical eraseblock size:129024 bytes
UBI: smallest flash I/O unit:2048
UBI: sub-page size:  512
UBI: VID header offset:  512 (aligned 512)
UBI: data offset:2048
UBI error: ubi_wl_init_scan: no enough physical eraseblocks (0, need 1)

Now the device is totally blocked, and power cycling does not change
the result.


have you tried to increase the malloc arena in u-boot
(CONIG_SYS_MALLOC_LEN)?
We had errors like this before [1],[2] and [3], maybe others -
apparently with another error message, but please give it a try. We know
ubi recovery needs some ram and 1MiB may be not enough.


Thanks for your suggestion.

Unfortunately this does not seem to be the cause of my problem: I tried
increasing my CONFIG_SYS_MALLOC_LEN in include/configs/dig297.h from
(1024  10) to both (1024  12) and (1024  14), but without any
difference.


Well, ok ... Malloc arena is always my first thought if I read about
problems with ubi in u-boot.
Have you looked up the differences in drivers/mtd/ubi/ in your u-boot
and linux tree? Maybe you can see something obviously different in the
ubi_wl_init_scan()?


I had some days ago, but I double-checked now as you suggested. Indeed
there is an important difference: attach_by_scanning() (build.c) calls
ubi_wl_init_scan() and ubi_eba_init_scan() just like Linux does, but in
a swapped order!

This swap dates back to:

commit d63894654df72b010de2abb4b3f07d0d755f65b6
Author: Holger Brunck holger.bru...@keymile.com
Date:   Mon Oct 10 13:08:19 2011 +0200

UBI: init eba tables before wl when attaching a device

This fixes that u-boot gets stuck when a bitflip was detected
during ubi part ubi_device. If a bitflip was detected UBI tries
to copy the PEB to a different place. This needs that the eba table
are initialized, but this was done after the wear levelling worker
detects the bitflip. So changes the initialisation of these two
tasks in u-boot.

This is a u-boot specific patch and not needed in the linux layer,
because due to commit 1b1f9a9d00447d
UBI: Ensure that background thread operations are really executed
we schedule these tasks in place and not as in linux after the inital
task which schedule this new task is finished.

Signed-off-by: Holger Brunck holger.bru...@keymile.com
cc: Stefan Roese s...@denx.de
Signed-off-by: Stefan Roese s...@denx.de

I tried reverting that commit and... surprise! U-Boot can now attach UBI
and boot properly!

But the cited commit actually fixed a bug that bite our board a few
months back, so it should not be reverted without thinking twice. Now
it apparently introduced another bug. :-(

I'm Cc:ing the commit author for comments.

Nonetheless, I have evidence of a different behaviour between U-Boot
and Linux even before the two swapped functions are called.

What attach_by_scanning() does in Linux is (abbreviated):

static int attach_by_scanning(struct ubi_device *ubi)
{
si = ubi_scan(ubi);
...fill ubi-some_fields...;
err = ubi_read_volume_table(ubi, si);
/* MARK */
err = ubi_eba_init_scan(ubi, si); /* swapped in U-Boot */
err = ubi_wl_init_scan(ubi, si);  /* swapped in U-Boot */
ubi_scan_destroy_si(si);
return 0;
}

See the two swapped calls.

At MARK, I printed some of the peb counters in *ubi, and I got
different results for ubi-avail_pebs between U-Boot and Linux:
U-Boot: UBI: POST_TBL: rsvd=2018, avail=21, beb_rsvd_{pebs,level}=0,0
Linux:  UBI: POST_TBL: rsvd=2018, avail=22, beb_rsvd_{pebs,level}=0,0

The printed values were equal before calling ubi_read_volume_table().
I have no idea about where this difference comes from, nor if this
difference can cause my troubles.
I will better investigate tomorrow looking into ubi_read_volume_table().

Luca

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

Re: [U-Boot] Bricked when trying to attach UBI

[Vikram Narayanan]

On 12/19/2012 4:58 PM, Luca Ceresoli wrote:

Hi all,


snip

On bricked devices the output of the ubi part nand0,3 command is:

Creating 1 MTD partitions on nand0:
0x0010-0x1000 : mtd=3
UBI: attaching mtd1 to ubi0
UBI: physical eraseblock size:   131072 bytes (128 KiB)
UBI: logical eraseblock size:129024 bytes
UBI: smallest flash I/O unit:2048
UBI: sub-page size:  512
UBI: VID header offset:  512 (aligned 512)
UBI: data offset:2048
UBI error: ubi_wl_init_scan: no enough physical eraseblocks (0, need 1)


Just curious, What does the above command say when you try to attach an 
empty partition. Does it result in the same error?



Now the device is totally blocked, and power cycling does not change
the result.

The interesting thing is that if I load Linux (2.6.37 + OMAP patches +
board support patches) via TFTP and boot it with bootm, it correctly
attaches UBI (fixing any problem it may have) and boots correctly.
After that the board is unbricked: U-Boot can boot again normally from
NAND.

Without the ambition of understanding all UBI internals, I tried to
visually inspect the UBI code around the line where the error is
produced and compare it to the corresponding Linux sources. They looked
extremely similar, so I haven't and obvious hint of why U-Boot and
Linux produce different results.

I also tried with an updated U-Boot master, but the error is still
there.

Obviously I have changed nothing in the UBI and MTD code, both in
U-Boot and in Linux.

Can you suggest a proper way to track the root of the problem, or to
bypass it?


I think its the right time to sync the UBI code with the current kernel 
tree. But it seems like a huge work. Any suggestions?


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

Re: [U-Boot] Bricked when trying to attach UBI

[Stefan Roese]

On 12/19/2012 06:32 PM, Vikram Narayanan wrote:
 On bricked devices the output of the ubi part nand0,3 command is:

 Creating 1 MTD partitions on nand0:
 0x0010-0x1000 : mtd=3
 UBI: attaching mtd1 to ubi0
 UBI: physical eraseblock size:   131072 bytes (128 KiB)
 UBI: logical eraseblock size:129024 bytes
 UBI: smallest flash I/O unit:2048
 UBI: sub-page size:  512
 UBI: VID header offset:  512 (aligned 512)
 UBI: data offset:2048
 UBI error: ubi_wl_init_scan: no enough physical eraseblocks (0, need 1)
 
 Just curious, What does the above command say when you try to attach an 
 empty partition. Does it result in the same error?
 
 Now the device is totally blocked, and power cycling does not change
 the result.

 The interesting thing is that if I load Linux (2.6.37 + OMAP patches +
 board support patches) via TFTP and boot it with bootm, it correctly
 attaches UBI (fixing any problem it may have) and boots correctly.
 After that the board is unbricked: U-Boot can boot again normally from
 NAND.

 Without the ambition of understanding all UBI internals, I tried to
 visually inspect the UBI code around the line where the error is
 produced and compare it to the corresponding Linux sources. They looked
 extremely similar, so I haven't and obvious hint of why U-Boot and
 Linux produce different results.

 I also tried with an updated U-Boot master, but the error is still
 there.

 Obviously I have changed nothing in the UBI and MTD code, both in
 U-Boot and in Linux.

 Can you suggest a proper way to track the root of the problem, or to
 bypass it?
 
 I think its the right time to sync the UBI code with the current kernel 
 tree. But it seems like a huge work. Any suggestions?

Yes, syncing with the latest UBI/UBIFS code would be the best solution.
Even though a try with an increased malloc area as suggested by Andreas
might be a chance.

And yes, this re-sync with the latest-and-greatest Linux code version is
of course a bigger task. It has been suggest as part of booting from an
UBI volume task to the celinux forum:

http://lists.celinuxforum.org/pipermail/celinux-dev/2012-April/000543.html

But nothing has happened till now. Any volunteers? But please keep in
mind that intensive testing is required before the current (stable?)
code version can be replaced.

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

Re: [U-Boot] Bricked when trying to attach UBI

[Vikram Narayanan]

On 12/19/2012 11:52 PM, Stefan Roese wrote:
snip

I think its the right time to sync the UBI code with the current kernel
tree. But it seems like a huge work. Any suggestions?


Yes, syncing with the latest UBI/UBIFS code would be the best solution.
Even though a try with an increased malloc area as suggested by Andreas
might be a chance.

And yes, this re-sync with the latest-and-greatest Linux code version is
of course a bigger task. It has been suggest as part of booting from an
UBI volume task to the celinux forum:

http://lists.celinuxforum.org/pipermail/celinux-dev/2012-April/000543.html


Yeah. I had queried sometime back on the activity of this task.


But nothing has happened till now. Any volunteers? But please keep in
mind that intensive testing is required before the current (stable?)
code version can be replaced.



Looks like the MTD layer might needs to be patched up as well at some 
places. What do you think?


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

Re: [U-Boot] Bricked when trying to attach UBI

[Vikram Narayanan]

On 12/20/2012 12:17 AM, Vikram Narayanan wrote:

On 12/19/2012 11:52 PM, Stefan Roese wrote:
snip

I think its the right time to sync the UBI code with the current kernel
tree. But it seems like a huge work. Any suggestions?


Yes, syncing with the latest UBI/UBIFS code would be the best solution.
Even though a try with an increased malloc area as suggested by Andreas
might be a chance.

And yes, this re-sync with the latest-and-greatest Linux code version is
of course a bigger task. It has been suggest as part of booting from an
UBI volume task to the celinux forum:

http://lists.celinuxforum.org/pipermail/celinux-dev/2012-April/000543.html



Yeah. I had queried sometime back on the activity of this task.


But nothing has happened till now. Any volunteers? But please keep in
mind that intensive testing is required before the current (stable?)
code version can be replaced.



Looks like the MTD layer might needs to be patched up as well at some
places. What do you think?


May be we shall start some discussions and put forth some ideas, which 
might eventually invite some volunteers.


What is your proposal of syncing with the latest code?
* Pick out changes from the Kernel's git (pick out UBI related commits 
right from the point where current u-boot code is)

* Compare and move the code

Both are equally complicated with the second option having very less 
chance to figure out why that was added. Ideas are welcome.


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

Re: [U-Boot] [PATCH] NAND: allow custom SW ECC when using nand plat driver

[Scott Wood]

On 12/18/2012 05:27:00 PM, Chris Kiick wrote:
Allow boards to set their own ECC layouts and functions in  
NAND_PLAT_INIT

without being stomped on by nand_base.c intialization.

Signed-off-by: ckiick chris at kiicks.net
---
 drivers/mtd/nand/nand_base.c |   11 +++
 drivers/mtd/nand/nand_plat.c |4 ++--
 include/configs/qong.h   |2 +-
 3 files changed, 10 insertions(+), 7 deletions(-)

diff --git a/drivers/mtd/nand/nand_base.c  
b/drivers/mtd/nand/nand_base.c

index a2d06be..614fc72 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -3035,8 +3035,10 @@ int nand_scan_tail(struct mtd_info *mtd)
 chip-ecc.mode = NAND_ECC_SOFT;

 case NAND_ECC_SOFT:
-chip-ecc.calculate = nand_calculate_ecc;
-chip-ecc.correct = nand_correct_data;
+if (!chip-ecc.calculate)
+chip-ecc.calculate = nand_calculate_ecc;
+if (!chip-ecc.correct)
+chip-ecc.correct = nand_correct_data;
 chip-ecc.read_page = nand_read_page_swecc;
 chip-ecc.read_subpage = nand_read_subpage;
 chip-ecc.write_page = nand_write_page_swecc;
@@ -3044,9 +3046,10 @@ int nand_scan_tail(struct mtd_info *mtd)
 chip-ecc.write_page_raw = nand_write_page_raw;
 chip-ecc.read_oob = nand_read_oob_std;
 chip-ecc.write_oob = nand_write_oob_std;
-if (!chip-ecc.size)
+if (!chip-ecc.size) {
 chip-ecc.size = 256;
-chip-ecc.bytes = 3;
+chip-ecc.bytes = 3;
+}
 break;

 case NAND_ECC_SOFT_BCH:


How is this part specific to nand plat?

I'm not sure how specifying your own ECC functions fits with the  
purpose of either NAND_ECC_SOFT or nand plat.


diff --git a/drivers/mtd/nand/nand_plat.c  
b/drivers/mtd/nand/nand_plat.c

index 37a0206..b3bda11 100644
--- a/drivers/mtd/nand/nand_plat.c
+++ b/drivers/mtd/nand/nand_plat.c
@@ -8,7 +8,7 @@
 /* Your board must implement the following macros:
  *  NAND_PLAT_WRITE_CMD(chip, cmd)
  *  NAND_PLAT_WRITE_ADR(chip, cmd)
- *  NAND_PLAT_INIT()
+ *  NAND_PLAT_INIT(nand)
  *
  * It may also implement the following:
  *  NAND_PLAT_DEV_READY(chip)
@@ -53,7 +53,7 @@ int board_nand_init(struct nand_chip *nand)
 #endif

 #ifdef NAND_PLAT_INIT
-NAND_PLAT_INIT();
+NAND_PLAT_INIT(nand);
 #endif

 nand-cmd_ctrl = plat_cmd_ctrl;
diff --git a/include/configs/qong.h b/include/configs/qong.h
index d9bf201..077cbae 100644
--- a/include/configs/qong.h
+++ b/include/configs/qong.h
@@ -226,7 +226,7 @@ extern int qong_nand_rdy(void *chip);
 #define CONFIG_NAND_PLAT
 #define CONFIG_SYS_MAX_NAND_DEVICE 1
 #define CONFIG_SYS_NAND_BASECS3_BASE
-#define NAND_PLAT_INIT() qong_nand_plat_init(nand)
+#define NAND_PLAT_INIT(nand) qong_nand_plat_init(nand)

 #define QONG_NAND_CLE(chip) ((unsigned long)(chip)-IO_ADDR_W | (1  
 24))
 #define QONG_NAND_ALE(chip) ((unsigned long)(chip)-IO_ADDR_W | (1  
 23))


This part looks unrelated.

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

Re: [U-Boot] Conflicting commits for seaboard USB keyboard handling

[Albert ARIBAUD]

Hi Stephen,

On Tue, 18 Dec 2012 23:04:09 -0700, Stephen Warren
swar...@wwwdotorg.org wrote:
 On 12/18/2012 06:08 PM, Allen Martin wrote:
 ...
  The other alternative is I could provide the conflict resolved files
  or instructions for how to resolve.
 
 Aren't the two sets of files that conflict those that are already in
 u-boot/master and u-boot-arm/master? If so, only Albert can resolve the
 conflict, by doing a merge. I already did that merge locally a while
 back in order to pick up the changes from both branches, and it didn't
 seem hard; what's the problem here? If Allen can push out a branch for
 Albert to use as an example to make sure he gets the correct merge
 result, that seems like a very simple solution.

There are several sources of conflicts in merging u-boot into
u-boot-arm. I want all conflicts resolved by the persons who are best
suited for resolving properly, then I'll merge all resolutions together.

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

Re: [U-Boot] [U-Boot, 1/2] spi: Add progress percentage and write speed to `sf update`

[Tom Rini]

On Fri, Sep 28, 2012 at 02:28:00PM -, Simon Glass wrote:

 From: James Miller jamesmil...@chromium.org
 
 Output a progress update only at most 10 times per second, to avoid
 saturating (and waiting on) the console. Make the summary line
 to fit on a single line. Make sure that cursor sits at the end of
 each update line instead of the beginning.
 
 Sample output:
 
 SF: Detected W25Q32 with page size 4 KiB, total 4 MiB
 Update SPI
 1331200 bytes written, 2863104 bytes skipped in 21.912s, speed 199728 B/s
 
 time: 21.919 seconds, 21919 ticks
 Skipping verify
 
 Signed-off-by: Simon Glass s...@chromium.org
 Signed-off-by: James Miller jamesmil...@chromium.org
 Signed-off-by: Taylor Hutt th...@chromium.org

With ELDK 4.2:
cmd_sf.c:80: warning: type qualifiers ignored on function return type

Unless I'm missing something, this is the right fix:
-static const ulong bytes_per_second(unsigned int len, ulong start_ms)
+static ulong bytes_per_second(unsigned int len, ulong start_ms)

Because no, we aren't returning a const.  If that sounds right I'll fix
inline and add my Signed-off-by.

-- 
Tom


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

Re: [U-Boot] [U-Boot, 1/2] spi: Add progress percentage and write speed to `sf update`

[Simon Glass]

Hi Tom,

On Wed, Dec 19, 2012 at 12:43 PM, Tom Rini tr...@ti.com wrote:
 On Fri, Sep 28, 2012 at 02:28:00PM -, Simon Glass wrote:

 From: James Miller jamesmil...@chromium.org

 Output a progress update only at most 10 times per second, to avoid
 saturating (and waiting on) the console. Make the summary line
 to fit on a single line. Make sure that cursor sits at the end of
 each update line instead of the beginning.

 Sample output:

 SF: Detected W25Q32 with page size 4 KiB, total 4 MiB
 Update SPI
 1331200 bytes written, 2863104 bytes skipped in 21.912s, speed 199728 B/s

 time: 21.919 seconds, 21919 ticks
 Skipping verify

 Signed-off-by: Simon Glass s...@chromium.org
 Signed-off-by: James Miller jamesmil...@chromium.org
 Signed-off-by: Taylor Hutt th...@chromium.org

 With ELDK 4.2:
 cmd_sf.c:80: warning: type qualifiers ignored on function return type

Interesting...


 Unless I'm missing something, this is the right fix:
 -static const ulong bytes_per_second(unsigned int len, ulong start_ms)
 +static ulong bytes_per_second(unsigned int len, ulong start_ms)

 Because no, we aren't returning a const.  If that sounds right I'll fix
 inline and add my Signed-off-by.

Yes that looks right, thanks for doing that. Did Mike get in touch re these?

Regards,
Simon


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

Re: [U-Boot] [U-Boot, 1/2] spi: Add progress percentage and write speed to `sf update`

[Tom Rini]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/19/12 15:46, Simon Glass wrote:
 Hi Tom,
 
 On Wed, Dec 19, 2012 at 12:43 PM, Tom Rini tr...@ti.com wrote:
 On Fri, Sep 28, 2012 at 02:28:00PM -, Simon Glass wrote:
 
 From: James Miller jamesmil...@chromium.org
 
 Output a progress update only at most 10 times per second, to 
 avoid saturating (and waiting on) the console. Make the
 summary line to fit on a single line. Make sure that cursor
 sits at the end of each update line instead of the beginning.
 
 Sample output:
 
 SF: Detected W25Q32 with page size 4 KiB, total 4 MiB Update 
 SPI 1331200 bytes written, 2863104 bytes skipped in 21.912s, 
 speed 199728 B/s
 
 time: 21.919 seconds, 21919 ticks Skipping verify
 
 Signed-off-by: Simon Glass s...@chromium.org Signed-off-by: 
 James Miller jamesmil...@chromium.org Signed-off-by: Taylor 
 Hutt th...@chromium.org
 
 With ELDK 4.2: cmd_sf.c:80: warning: type qualifiers ignored on 
 function return type
 
 Interesting...
 
 
 Unless I'm missing something, this is the right fix: -static 
 const ulong bytes_per_second(unsigned int len, ulong start_ms) 
 +static ulong bytes_per_second(unsigned int len, ulong start_ms)
 
 Because no, we aren't returning a const.  If that sounds right 
 I'll fix inline and add my Signed-off-by.
 
 Yes that looks right, thanks for doing that. Did Mike get in touch 
 re these?

No, but I've read them again myself and they seem sane enough to grab
as Mike hasn't been active recently.  And I'll push this shortly then,
thanks!

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

iQIcBAEBAgAGBQJQ0irGAAoJENk4IS6UOR1WVJIQAJfcEUS0JA6+cp5D+aEt+mbC
fnXcNB9iqqTJ+7s4FBrC7Q48MZooiynjbwo9M2/KrtjCtoKwM3pqHcvCZpL1R1l0
nJaGjgDgCU+DvXiWVRSGKYHan+O/EOYbzFxqDvS7y9A3+wJwBf3yvvom5/CavV61
pEzjSxaUdA0Ew4NZ7b3cVXqcDN00dzsuH1BgtRdNsaGauVJNtfi+83fHLZJfl8cY
24hC4iGqQu8hj13pAO4TMmsCYGVeXU+sSoTWzdYt6aYVu9nQUoeOplyUy+9e53Vr
v+1cgqiArqkIPLa0ypLGzR2f1QVzZqndXkRCmGNq0iVSowpfCPrDQO2OowzqmBEl
b9WUzmo3nkEn1pfY8EGYYtYXa8yyjie0qSzgbIiepBJFequPyzq/D2lY2a2buP2g
nUHMBS/fp04KunuY4PPrJoqXhUJFDSdsKhZBQS+hi3hzNpaT8u9D2QyjgiT/3mya
B92T4D9VvuLutpwqfGDiKBc7iwVrARBAxNUU9O82pCrV9l1+P669czqJWfARIdvy
Zpb1DGwudW1L8VEo0gR+wjp/bU2IxSSKBvRGrPENhklM4+121Jf2Wxbc7qq0XRik
8aRKL5cN3pWN2NoIuxEg0F3FRTrw24vqFv6J87jwCOZ7OCRsP47n2nzQXi1766UY
jRvezzCuDRQetEc1Rx1g
=WeUR
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Conflicting commits for seaboard USB keyboard handling

[Allen Martin]

On Wed, Dec 19, 2012 at 11:37:26AM -0800, Albert ARIBAUD wrote:
 Hi Stephen,
 
 On Tue, 18 Dec 2012 23:04:09 -0700, Stephen Warren
 swar...@wwwdotorg.org wrote:
  On 12/18/2012 06:08 PM, Allen Martin wrote:
  ...
   The other alternative is I could provide the conflict resolved files
   or instructions for how to resolve.
  
  Aren't the two sets of files that conflict those that are already in
  u-boot/master and u-boot-arm/master? If so, only Albert can resolve the
  conflict, by doing a merge. I already did that merge locally a while
  back in order to pick up the changes from both branches, and it didn't
  seem hard; what's the problem here? If Allen can push out a branch for
  Albert to use as an example to make sure he gets the correct merge
  result, that seems like a very simple solution.
 
 There are several sources of conflicts in merging u-boot into
 u-boot-arm. I want all conflicts resolved by the persons who are best
 suited for resolving properly, then I'll merge all resolutions together.
 

Hi Albert, I did a merge of u-boot/master into u-boot-arm/master and
resolved the conflicts and I've pushed the result to:

 git://github.com/arm000/u-boot.git
 branch: u-boot-arm-merge-resolved

I resolved all the conflicts, but the only ones I claim I did
correctly were the changes to:

 include/configs/seaboard.h
 include/configs/tegra-common-post.h

the other conflicts were not related to tegra.

If you want a new pull request, you'll first have to unroll the
previously merged tegra patches from u-boot-arm/master so I can give
you a conflict free merge request.

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

Re: [U-Boot] [PATCH] NAND: allow custom SW ECC when using nand plat driver

[Scott Wood]

On 12/19/2012 03:16:19 PM, Chris Kiick wrote:

Hi,
  Thanks for the reply. This is my first patch to u-boot. Any advice  
is

appreciated. Comments in-line below.


- Original Message 

 From: Scott Wood scottw...@freescale.com
 To: Chris Kiick cki...@att.net
 Cc: u-boot@lists.denx.de
 Sent: Wed, December 19, 2012 1:02:52 PM
 Subject: Re: [U-Boot] [PATCH] NAND: allow custom SW ECC when using  
nand plat

driver

 On 12/18/2012 05:27:00 PM, Chris Kiick wrote:
  Allow boards to set their  own ECC layouts and functions in  
NAND_PLAT_INIT

  without being stomped on  by nand_base.c intialization.
 
  Signed-off-by: ckiick chris  at kiicks.net
  ---
   drivers/mtd/nand/nand_base.c |11 +++
   drivers/mtd/nand/nand_plat.c |4  ++--
   include/configs/qong.h   |2  +-
   3 files changed, 10 insertions(+), 7 deletions(-)
 
  diff --git a/drivers/mtd/nand/nand_base.c   
b/drivers/mtd/nand/nand_base.c

  index a2d06be..614fc72 100644
  ---  a/drivers/mtd/nand/nand_base.c
  +++  b/drivers/mtd/nand/nand_base.c
  @@ -3035,8 +3035,10 @@ int  nand_scan_tail(struct mtd_info *mtd)
chip-ecc.mode = NAND_ECC_SOFT;
 
   case  NAND_ECC_SOFT:
  -chip-ecc.calculate =  nand_calculate_ecc;
  -chip-ecc.correct =  nand_correct_data;
  +if  (!chip-ecc.calculate)
  + chip-ecc.calculate = nand_calculate_ecc;
  + if (!chip-ecc.correct)
  + chip-ecc.correct = nand_correct_data;
chip-ecc.read_page = nand_read_page_swecc;
chip-ecc.read_subpage =  nand_read_subpage;
chip-ecc.write_page = nand_write_page_swecc;
  @@ -3044,9 +3046,10 @@  int nand_scan_tail(struct mtd_info *mtd)
chip-ecc.write_page_raw = nand_write_page_raw;
chip-ecc.read_oob = nand_read_oob_std;
chip-ecc.write_oob = nand_write_oob_std;
   -if (!chip-ecc.size)
  + if (!chip-ecc.size) {
chip-ecc.size = 256;
  - chip-ecc.bytes = 3;
  + chip-ecc.bytes = 3;
  + }
   break;
 
case NAND_ECC_SOFT_BCH:

 How is this part specific to nand  plat?

OK, it's not, but if you are using nand plat, then you are forced to  
go through
this code path with no chance of making any changes after because of  
the way

board_nand_init() is written.


nand plat is meant to be a simple driver for simple hardware that  
follows a certain pattern.  If you have hardware that doesn't fit that,  
don't use nand plat.



I seem to see  other nand drivers setting up ecc
layouts and then calling nand_scan_tail(), I'm not sure how they are   
getting

around this.


They don't use NAND_ECC_SOFT.

I reasoned that the change was safe for existing code because if  
something was
not setting its own ecc layout, it would still use the default, but  
it if was,
then it had to be after the call to nand_scan_tail() and that would  
override

whatever was set there anyway.


It's not a matter of safety, but rather a sign that you're misusing  
things.


 I'm not sure how specifying your own ECC functions fits with the   
purpose of

either NAND_ECC_SOFT or nand plat.
Well, NAND_ECC_SOFT is the only scheme that does fit with custom ECC  
algorithms.


No, it's the opposite.  NAND_ECC_SOFT is telling the generic code  
please do ECC for me.  NAND_ECC_HW is telling the generic code I  
want to do ECC myself, usually because you have hardware that  
implements it.  In your case, it's because you're trying to maintain  
compatibility with something.


You have to pick one of the existing ECC schemes, and SOFT is the  
scheme that
allows you to do your own ECC, if you setup the layout, calculate and  
correct

parts. Looking at the code, that's what I thought it was for.


You just described NAND_ECC_HW. :-)

Is there another way to implement custom ECC algorithms, done in  
software?


As for the plat driver, it shouldn't care what ECC I'm using.  It's  
just running
the low-level byte-bang part of the driver for me, so I don't have to  
duplicate
the code. Isn't that its purpose?  Do I have to re-write a driver  
interface that
does the same thing as nand plat just because my ECC isn't the  
default?


There is very little code in the nand plat driver.  I would not be too  
worried about duplicating that, if the result is more straightforward.


The fact that there's still only one board using it (but three ifdef  
symbols!) makes me wonder if nand plat was a bad idea in general.


If I'm going in the wrong direction, I'd appreciate advice on how  
it's supposed

to be done.

  diff --git  a/drivers/mtd/nand/nand_plat.c  
b/drivers/mtd/nand/nand_plat.c

  index  37a0206..b3bda11 100644
  --- a/drivers/mtd/nand/nand_plat.c
  +++  b/drivers/mtd/nand/nand_plat.c
  @@ -8,7 +8,7 @@
   /* Your  board must implement the following macros:
*   NAND_PLAT_WRITE_CMD(chip, cmd)
*  NAND_PLAT_WRITE_ADR(chip,  cmd)
  - *  NAND_PLAT_INIT()
  + *   NAND_PLAT_INIT(nand)
*
* It 

Re: [U-Boot] [PATCH] NAND: allow custom SW ECC when using nand plat driver

[Scott Wood]

On 12/19/2012 03:40:03 PM, Scott Wood wrote:

I seem to see  other nand drivers setting up ecc
layouts and then calling nand_scan_tail(), I'm not sure how they  
are  getting

around this.


They don't use NAND_ECC_SOFT.


Wait, just layout, not algorithm?  How is that a problem with either  
NAND_ECC_SOFT or nand plat?


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

Re: [U-Boot] [PATCH 03/10] x86: Permit bootstage and timer data to be used prior to relocation

[Simon Glass]

Hi Graeme,

On Wed, Dec 19, 2012 at 1:39 PM, Graeme Russ graeme.r...@gmail.com wrote:
 Hi Simon,

 On Wed, Dec 19, 2012 at 12:32 PM, Simon Glass s...@chromium.org wrote:
 Hi Graeme,

 On Fri, Dec 14, 2012 at 2:35 PM, Simon Glass s...@chromium.org wrote:

 Hi Graeme,


 On Fri, Dec 14, 2012 at 2:15 PM, Graeme Russ graeme.r...@gmail.com
 wrote:
  Hi Simon,
 
  On 15/12/12 08:13, Simon Glass wrote:
  It is useful to be able to access the timer before U-Boot has relocated
  so that we can fully support bootstage.
 
  Move the relevant variables to the data region to support this.
 
  Signed-off-by: Simon Glass s...@chromium.org
  ---
   arch/x86/cpu/coreboot/coreboot.c |4 ++--
   arch/x86/cpu/interrupts.c|2 +-
   arch/x86/lib/timer.c |2 +-
   3 files changed, 4 insertions(+), 4 deletions(-)
 
  diff --git a/arch/x86/cpu/coreboot/coreboot.c
  b/arch/x86/cpu/coreboot/coreboot.c
  index 9c9431e..22474f5 100644
  --- a/arch/x86/cpu/coreboot/coreboot.c
  +++ b/arch/x86/cpu/coreboot/coreboot.c
  @@ -68,8 +68,8 @@ int board_early_init_r(void)
   void show_boot_progress(int val)
   {
   #if MIN_PORT80_KCLOCKS_DELAY
  - static uint32_t prev_stamp;
  - static uint32_t base;
  + static uint32_t prev_stamp __attribute__((section(.data)));
  + static uint32_t base __attribute__((section(.data)));
 
  NAK
 
  This may work for coreboot where SDRAM is already initialised and you've
  loaded U-Boot into RAM, but it will not work when U-Boot is in Flash as
  all
  sections (including .data) are read-only until after relocation.
 
  The stack and Global Data are the only guaranteed read/write locations
  prior to relocation

 Ah yes, I was thinking of your comment that all boards would move to
 use coreboot. If that is not the case, then I will need to add
 something to global data for the timer. And I don't want to do that
 while generic board is in progress since it creates conflicts.

 I'm trying to remember the context of my comment regarding only having
 coreboot boards. But anyway, not having any writeable data prior to
 relocation (other than the stack and gd) is a fundamental principle
 that we cannot simply avoid (although I must admit I don't know what
 the go is with SPL and U-Boot relocation).

 Any thoughts on this point, please? I presume at least I can use RAM once
 dram_init() is called. But when running from coreboot the RAM is already set
 up...

 You will need to use global data to store the static variables. That's
 what the other arches do

That line is blurred a bit now, but OK I will do that. I will put this
series on hold until we see what happens with the arch-specific
global_data series.

Regards,
Simon


 Regards,

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

Re: [U-Boot] [PATCH 03/10] x86: Permit bootstage and timer data to be used prior to relocation

[Graeme Russ]

Hi Simon,

On Wed, Dec 19, 2012 at 12:32 PM, Simon Glass s...@chromium.org wrote:
 Hi Graeme,

 On Fri, Dec 14, 2012 at 2:35 PM, Simon Glass s...@chromium.org wrote:

 Hi Graeme,


 On Fri, Dec 14, 2012 at 2:15 PM, Graeme Russ graeme.r...@gmail.com
 wrote:
  Hi Simon,
 
  On 15/12/12 08:13, Simon Glass wrote:
  It is useful to be able to access the timer before U-Boot has relocated
  so that we can fully support bootstage.
 
  Move the relevant variables to the data region to support this.
 
  Signed-off-by: Simon Glass s...@chromium.org
  ---
   arch/x86/cpu/coreboot/coreboot.c |4 ++--
   arch/x86/cpu/interrupts.c|2 +-
   arch/x86/lib/timer.c |2 +-
   3 files changed, 4 insertions(+), 4 deletions(-)
 
  diff --git a/arch/x86/cpu/coreboot/coreboot.c
  b/arch/x86/cpu/coreboot/coreboot.c
  index 9c9431e..22474f5 100644
  --- a/arch/x86/cpu/coreboot/coreboot.c
  +++ b/arch/x86/cpu/coreboot/coreboot.c
  @@ -68,8 +68,8 @@ int board_early_init_r(void)
   void show_boot_progress(int val)
   {
   #if MIN_PORT80_KCLOCKS_DELAY
  - static uint32_t prev_stamp;
  - static uint32_t base;
  + static uint32_t prev_stamp __attribute__((section(.data)));
  + static uint32_t base __attribute__((section(.data)));
 
  NAK
 
  This may work for coreboot where SDRAM is already initialised and you've
  loaded U-Boot into RAM, but it will not work when U-Boot is in Flash as
  all
  sections (including .data) are read-only until after relocation.
 
  The stack and Global Data are the only guaranteed read/write locations
  prior to relocation

 Ah yes, I was thinking of your comment that all boards would move to
 use coreboot. If that is not the case, then I will need to add
 something to global data for the timer. And I don't want to do that
 while generic board is in progress since it creates conflicts.

I'm trying to remember the context of my comment regarding only having
coreboot boards. But anyway, not having any writeable data prior to
relocation (other than the stack and gd) is a fundamental principle
that we cannot simply avoid (although I must admit I don't know what
the go is with SPL and U-Boot relocation).

 Any thoughts on this point, please? I presume at least I can use RAM once
 dram_init() is called. But when running from coreboot the RAM is already set
 up...

You will need to use global data to store the static variables. That's
what the other arches do

Regards,

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

Re: [U-Boot] Conflicting commits for seaboard USB keyboard handling

[Albert ARIBAUD]

Hi Allen,

 Hi Albert, I did a merge of u-boot/master into u-boot-arm/master and
 resolved the conflicts and I've pushed the result to:
 
  git://github.com/arm000/u-boot.git
  branch: u-boot-arm-merge-resolved
 
 I resolved all the conflicts, but the only ones I claim I did
 correctly were the changes to:
 
  include/configs/seaboard.h
  include/configs/tegra-common-post.h
 
 the other conflicts were not related to tegra.
 
 If you want a new pull request, you'll first have to unroll the
 previously merged tegra patches from u-boot-arm/master so I can give
 you a conflict free merge request.

Thanks Allen, this branch is what I wanted exactly -- I don't want to
ask for a rollback. As soon as I am sure about the samsung branch, I'll
merge all fix branches into ARM.

 -Allen
 -- 
 nvpublic

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

Re: [U-Boot] split nand writes

[Scott Wood]

On 12/19/2012 09:43:01 AM, Jaap de Jong wrote:

Hi All,
suppose the image I want to flash is bigger than the available ram in  
the unit.

Is there a way to copy the image f.i. in pieces into the flash?
nand write should have a 'continue on last block' option for that  
purpose.


Something like that would be nice.

These patches are relevant:
http://patchwork.ozlabs.org/patch/204939/
http://patchwork.ozlabs.org/patch/204940/

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

Re: [U-Boot] coldfire: eb_cpu5282: fix: boot from internal flash

[Tom Rini]

On Tue, Nov 20, 2012 at 02:06:25AM -, e...@bus-elektronik.de wrote:

 From: Jens Scharsig (BuS Elektronik) e...@bus-elektronik.de
 
 * By a sequence of unfavorable conditions in the config header file, the 
 eb_cpu5282
   booting from  internal stopped after relocation. Blame it is a faulty value 
 of
   CONFIG_SYS_MONITOR_BASE. This patch fix this by replace the wrong condition 
 in
   config header with option in board.cfg
 
 Signed-off-by: Jens Scharsig (BuS Elektronik) e...@bus-elektronik.de

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot,v2,2/2] spi: Add SPI flash test

[Tom Rini]

On Mon, Oct 08, 2012 at 01:16:02PM -, Simon Glass wrote:

 It is useful to have a basic SPI flash test, which tests that the SPI chip,
 the SPI bus and the driver are behaving.
 
 This test erases part of the flash, writes data and reads it back as a
 sanity check that all is well.
 
 Use CONFIG_SF_TEST to enable it.
 
 Signed-off-by: Simon Glass s...@chromium.org

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot, 1/2] spi: Add progress percentage and write speed to `sf update`

[Tom Rini]

On Wed, Dec 19, 2012 at 03:59:50PM -0500, Tom Rini wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 On 12/19/12 15:46, Simon Glass wrote:
  Hi Tom,
  
  On Wed, Dec 19, 2012 at 12:43 PM, Tom Rini tr...@ti.com wrote:
  On Fri, Sep 28, 2012 at 02:28:00PM -, Simon Glass wrote:
  
  From: James Miller jamesmil...@chromium.org
  
  Output a progress update only at most 10 times per second, to 
  avoid saturating (and waiting on) the console. Make the
  summary line to fit on a single line. Make sure that cursor
  sits at the end of each update line instead of the beginning.
  
  Sample output:
  
  SF: Detected W25Q32 with page size 4 KiB, total 4 MiB Update 
  SPI 1331200 bytes written, 2863104 bytes skipped in 21.912s, 
  speed 199728 B/s
  
  time: 21.919 seconds, 21919 ticks Skipping verify
  
  Signed-off-by: Simon Glass s...@chromium.org Signed-off-by: 
  James Miller jamesmil...@chromium.org Signed-off-by: Taylor 
  Hutt th...@chromium.org
  
  With ELDK 4.2: cmd_sf.c:80: warning: type qualifiers ignored on 
  function return type
  
  Interesting...
  
  
  Unless I'm missing something, this is the right fix: -static 
  const ulong bytes_per_second(unsigned int len, ulong start_ms) 
  +static ulong bytes_per_second(unsigned int len, ulong start_ms)
  
  Because no, we aren't returning a const.  If that sounds right 
  I'll fix inline and add my Signed-off-by.
  
  Yes that looks right, thanks for doing that. Did Mike get in touch 
  re these?
 
 No, but I've read them again myself and they seem sane enough to grab
 as Mike hasn't been active recently.  And I'll push this shortly then,
 thanks!

With this change, applied to u-boot/master.

-- 
Tom


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

Re: [U-Boot] [U-Boot,1/3] fw_env: fix type of len

[Tom Rini]

On Sat, Nov 10, 2012 at 07:47:45PM -, Mike Frysinger wrote:

 This variable is assigned by a size_t, and is printed that way, but is
 incorrectly declared as an int.  Which means we get warnings:
 fw_env.c: In function 'fw_setenv':
 fw_env.c:409:5: warning: format '%zu' expects argument of type 'size_t',
   but argument 3 has type 'int' [-Wformat]
 
 Signed-off-by: Mike Frysinger vap...@gentoo.org
 Acked-by: Joe Hershberger joe.hershber...@ni.com

For the series, applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot,v2] Add a simple load option to setexpr

[Tom Rini]

On Thu, Nov 01, 2012 at 04:21:14PM -, Joe Hershberger wrote:

 Make setexpr accept a 2 parameter variant that will simply load a value
 into a variable.  This is useful for loading a value from memory.
 
 Signed-off-by: Joe Hershberger joe.hershber...@ni.com

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH 1/2] spi: Add progress percentage and write speed to `sf update`

[Wolfgang Denk]

Dear Simon Glass,

In message 1348878482-1730-1-git-send-email-...@chromium.org you wrote:
 From: James Miller jamesmil...@chromium.org
 
 Output a progress update only at most 10 times per second, to avoid
 saturating (and waiting on) the console. Make the summary line
 to fit on a single line. Make sure that cursor sits at the end of
 each update line instead of the beginning.
 
 Sample output:
 
 SF: Detected W25Q32 with page size 4 KiB, total 4 MiB
 Update SPI
 1331200 bytes written, 2863104 bytes skipped in 21.912s, speed 199728 B/s

I dislike making commands more verbose then needed, or helpful.  Of
course the latter may be considered a matter of taste, but first of
all you also add code size here for questionable benefit.

I object against this patch:

1) I cannot see what is so special in the sf command that it needs
   such handling, while commands accessing NOR or NAND flash or
   SDCard or any other storage devices don't.

   If there is an agreement that this feature should be added, then it
   should be done in a general way that can be used everywhere.

   [Note that I doubt that if.]

2) The code size hurts (at least in some cases). Such code should be
   optional. Please make it configurable.


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
A witty saying proves nothing, but saying  something  pointless  gets
people's attention.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2] spi: Add SPI flash test

[Wolfgang Denk]

Dear Simon Glass,

In message 1348878482-1730-2-git-send-email-...@chromium.org you wrote:
 It is useful to have a basic SPI flash test, which tests that the SPI chip,
 the SPI bus and the driver are behaving.
 
 This test erases part of the flash, writes data and reads it back as a
 sanity check that all is well.
 
 Use CONFIG_SF_TEST to enable it.

Adding dead code ?

Please don't.

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
No, I'm not going to explain it. If you  can't  figure  it  out,  you
didn't want to know anyway... :-)
   - Larry Wall in 1991aug7.180856.2...@netlabs.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot, 1/2] spi: Add progress percentage and write speed to `sf update`

[Wolfgang Denk]

Dear Tom Rini,

In message 20121219225945.GF14589@bill-the-cat you wrote:
 
...
 With this change, applied to u-boot/master.

Argh :-(

Can we please undo this somehow?  This does not fit at all
conceptually.  U-Boot is supposed to use the good ols UNIX philosophy
of being terse by default, and special casing one specific storage
device makes no sense at all to me.

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 am pleased to see that we have differences.  May we together become
greater than the sum of both of us.
-- Surak of Vulcan, The Savage Curtain, stardate 5906.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot, v2 1/6] cmd_sf: Add print messages on flash erase command

[Wolfgang Denk]

Dear Jagannadha Sutradharudu Teki,

In message 1355934463-24319-1-git-send-email-jagannadh.t...@gmail.com you 
wrote:
 This patch adds a print messages while using 'sf erase' command
 to make sure that how many bytes erased in flash device.
 
 Signed-off-by: Jagannadha Sutradharudu Teki jagannadh.t...@gmail.com
 ---
 Changes in v2:
   Move print messages from spi_flash.c into cmd_sf.c

This makes little sense to me.  Please see all comments here:

http://article.gmane.org/gmane.comp.boot-loaders.u-boot/149663

and here:

http://article.gmane.org/gmane.comp.boot-loaders.u-boot/149665



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
Programmer's Lament: (Shakespeare, Macbeth, Act I, Scene vii)
That we but teach bloody instructions,
which, being taught, return to plague the inventor...
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot, v2 2/6] cmd_sf: Add print messages on flash read/write commands

[Wolfgang Denk]

Dear Jagannadha Sutradharudu Teki,

In message 1355934463-24319-2-git-send-email-jagannadh.t...@gmail.com you 
wrote:
 This patch adds a print messages while using 'sf read' and
 'sf write' commands to make sure that how many bytes read/written
 from/into flash device.
 
 Signed-off-by: Jagannadha Sutradharudu Teki jagannadh.t...@gmail.com
 ---
 Changes in v2:
 Move print messages from spi_flash.c into cmd_sf.c

Please see previous comments, especially

http://article.gmane.org/gmane.comp.boot-loaders.u-boot/149663
http://article.gmane.org/gmane.comp.boot-loaders.u-boot/149665

I object against adding more and more verbosity and code size, and in
an inconsistent way.

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
F u cn rd ths u cnt spl wrth a dm!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot,v2,2/2] spi: Add SPI flash test

[Wolfgang Denk]

Dear Tom Rini,

In message 20121219225956.GG14589@bill-the-cat you wrote:
 
 Applied to u-boot/master, thanks!

Please see my comment from a few minutes ago.

We're adding just dead code here.  This makes no sense to me.

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
Computers are not intelligent.  They only think they are.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] spi: Add progress percentage and write speed to `sf update`

[Simon Glass]

Hi Wolfgang,

On Wed, Dec 19, 2012 at 3:10 PM, Wolfgang Denk w...@denx.de wrote:
 Dear Simon Glass,

 In message 1348878482-1730-1-git-send-email-...@chromium.org you wrote:
 From: James Miller jamesmil...@chromium.org

 Output a progress update only at most 10 times per second, to avoid
 saturating (and waiting on) the console. Make the summary line
 to fit on a single line. Make sure that cursor sits at the end of
 each update line instead of the beginning.

 Sample output:

 SF: Detected W25Q32 with page size 4 KiB, total 4 MiB
 Update SPI
 1331200 bytes written, 2863104 bytes skipped in 21.912s, speed 199728 B/s

 I dislike making commands more verbose then needed, or helpful.  Of
 course the latter may be considered a matter of taste, but first of
 all you also add code size here for questionable benefit.

 I object against this patch:

 1) I cannot see what is so special in the sf command that it needs
such handling, while commands accessing NOR or NAND flash or
SDCard or any other storage devices don't.

If there is an agreement that this feature should be added, then it
should be done in a general way that can be used everywhere.

[Note that I doubt that if.]

Hmmm I suppose that is a good point. The main issue with SPI flash is
that it is extremely slow, and writing a few MB can take a minute or
so. The 'sf update' command was intended to do a smart update, and the
progress is useful for that. Other storage types are not so bad.

Yes it makes sense (if we want this sort of feature) to make it more
general feature so that it can be used by all devices. I think it
could be done, and then enabled by a CONFIG. We could perhaps make it
so that the progress info never appears unless the operation takes at
least a few seconds.


 2) The code size hurts (at least in some cases). Such code should be
optional. Please make it configurable.

OK see above. I will take a look.

Regards,
Simon



 Best regards,

 Wolfgang Denk

 --
 DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
 HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
 Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
 A witty saying proves nothing, but saying  something  pointless  gets
 people's attention.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] spi: Add progress percentage and write speed to `sf update`

[Scott Wood]

On 12/19/2012 05:20:07 PM, Simon Glass wrote:

Hi Wolfgang,

On Wed, Dec 19, 2012 at 3:10 PM, Wolfgang Denk w...@denx.de wrote:
 Dear Simon Glass,

 In message 1348878482-1730-1-git-send-email-...@chromium.org you  
wrote:

 From: James Miller jamesmil...@chromium.org

 Output a progress update only at most 10 times per second, to avoid
 saturating (and waiting on) the console. Make the summary line
 to fit on a single line. Make sure that cursor sits at the end of
 each update line instead of the beginning.

 Sample output:

 SF: Detected W25Q32 with page size 4 KiB, total 4 MiB
 Update SPI
 1331200 bytes written, 2863104 bytes skipped in 21.912s, speed  
199728 B/s


 I dislike making commands more verbose then needed, or helpful.  Of
 course the latter may be considered a matter of taste, but first of
 all you also add code size here for questionable benefit.

 I object against this patch:

 1) I cannot see what is so special in the sf command that it needs
such handling, while commands accessing NOR or NAND flash or
SDCard or any other storage devices don't.

If there is an agreement that this feature should be added, then  
it

should be done in a general way that can be used everywhere.

[Note that I doubt that if.]

Hmmm I suppose that is a good point. The main issue with SPI flash is
that it is extremely slow, and writing a few MB can take a minute or
so. The 'sf update' command was intended to do a smart update, and the
progress is useful for that. Other storage types are not so bad.


NOR can be pretty slow as well -- and it does have a progress indicator  
in U-Boot (albeit a simpler one).


NAND has a progress meter on erase, and for larger transfers it could  
probably use one on read/write as well.


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

Re: [U-Boot] [PATCH 1/3] spl: Change PAD_TO to CONFIG_SPL_PAD_TO

[Kim Phillips]

On Thu, 6 Dec 2012 17:33:16 -0600
Scott Wood scottw...@freescale.com wrote:

 This was already used by some SPL targets, and allows the pad amount to
 be specified by board config headers rather than only in makefile
 fragments.
 
 Also supply a pad-to of zero if the variable is undefined.  It works
 without this, but this avoids relying on undocumented behavior.
 
 Signed-off-by: Scott Wood scottw...@freescale.com
 ---
  Makefile|6 +-
  README  |4 
  board/ait/cam_enc_4xx/config.mk |2 +-
  3 files changed, 10 insertions(+), 2 deletions(-)

Despite this first patch falling outside of my domain, I
applied all 3 patches to u-boot-mpc83xx/next.

Thanks,

Kim

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

Re: [U-Boot] Conflicting commits for seaboard USB keyboard handling

[Allen Martin]

On Wed, Dec 19, 2012 at 02:42:24PM -0800, Albert ARIBAUD wrote:
 Hi Allen,
 
  Hi Albert, I did a merge of u-boot/master into u-boot-arm/master and
  resolved the conflicts and I've pushed the result to:
  
   git://github.com/arm000/u-boot.git
   branch: u-boot-arm-merge-resolved
  
  I resolved all the conflicts, but the only ones I claim I did
  correctly were the changes to:
  
   include/configs/seaboard.h
   include/configs/tegra-common-post.h
  
  the other conflicts were not related to tegra.
  
  If you want a new pull request, you'll first have to unroll the
  previously merged tegra patches from u-boot-arm/master so I can give
  you a conflict free merge request.
 
 Thanks Allen, this branch is what I wanted exactly -- I don't want to
 ask for a rollback. As soon as I am sure about the samsung branch, I'll
 merge all fix branches into ARM.

Ok, let me know if you have any problems resolving and I'll try to
help the best I can.  

Tom, you'll need to rebase u-boot-tegra/next on top of this, and there
will be conflicts when you do.  I've resolved those as well for
reference and pushed to:

  git://github.com/arm000/u-boot.git
  branch: u-boot-tegra-next-rebased

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

Re: [U-Boot] [U-Boot, 1/2] spi: Add progress percentage and write speed to `sf update`

[Tom Rini]

On Thu, Dec 20, 2012 at 12:14:00AM +0100, Wolfgang Denk wrote:
 Dear Tom Rini,
 
 In message 20121219225945.GF14589@bill-the-cat you wrote:
  
 ...
  With this change, applied to u-boot/master.
 
 Argh :-(
 
 Can we please undo this somehow?  This does not fit at all
 conceptually.  U-Boot is supposed to use the good ols UNIX philosophy
 of being terse by default, and special casing one specific storage
 device makes no sense at all to me.

We need to fix some of the underlying problems so that we're consistent
here.  Sometimes we have output (network #), sometimes we don't.
Sometimes we have a speed (network, filesystem load), sometimes we
don't.  I'd be quite happy to have a uniform output and a uniform ON/OFF
switch.

-- 
Tom


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

Re: [U-Boot] [U-Boot,v2,2/2] spi: Add SPI flash test

[Tom Rini]

On Thu, Dec 20, 2012 at 12:19:24AM +0100, Wolfgang Denk wrote:
 Dear Tom Rini,
 
 In message 20121219225956.GG14589@bill-the-cat you wrote:
  
  Applied to u-boot/master, thanks!
 
 Please see my comment from a few minutes ago.
 
 We're adding just dead code here.  This makes no sense to me.

I'll add this option to am335x_evm as soon as I can sneak over to the
office, flip the dip switches so that the SPI flash is available and
double check that yes, really, Simon tested the code one point before
posting.  Yeah, -1 to me for adding this before we added a board using
it, but it's a useful thing.  Q/A folks here at least will be all 'oh
boy!' when I tell them that starting with the next release they can use
this.

-- 
Tom


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

Re: [U-Boot] configuring u-boot for custom board based on beaglebone(am335xx_evm)

[Tom Rini]

On Wed, Dec 19, 2012 at 07:19:03AM -0800, Pavan wrote:

 Hi Yegor,
 
 Thanks for quick reply,
 
   in u-boot source code to change the beagleboard -xM pin mux we
 can change by updating the file board/ti/beagle/beagle.h by changing the
 MUX_BEAGLE() micro ,how can i access the same thing for beaglebone?

You don't.  We intentionally only enable the muxes that are required
rather than every single possible mux.  You need to do the muxing in the
kernel.  And any clocking too, assuming it's not one fo the ones already
enabled.

-- 
Tom


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

Re: [U-Boot] [U-Boot, 1/2] spi: Add progress percentage and write speed to `sf update`

[Simon Glass]

Hi Tom,

On Wed, Dec 19, 2012 at 5:03 PM, Tom Rini tr...@ti.com wrote:
 On Thu, Dec 20, 2012 at 12:14:00AM +0100, Wolfgang Denk wrote:
 Dear Tom Rini,

 In message 20121219225945.GF14589@bill-the-cat you wrote:
 
 ...
  With this change, applied to u-boot/master.

 Argh :-(

 Can we please undo this somehow?  This does not fit at all
 conceptually.  U-Boot is supposed to use the good ols UNIX philosophy
 of being terse by default, and special casing one specific storage
 device makes no sense at all to me.

 We need to fix some of the underlying problems so that we're consistent
 here.  Sometimes we have output (network #), sometimes we don't.
 Sometimes we have a speed (network, filesystem load), sometimes we
 don't.  I'd be quite happy to have a uniform output and a uniform ON/OFF
 switch.

I'm happy to do something like this. Obviously we want a config, but
do we also want an env variable to control it? Could be useful.

And at the risk of killing it with feature creep, perhaps we could
have two levels of verbosity: progress (which repeatedly updates on
the same line) and notice (which does not). That might take care of
Jagannadha's use case also.

Regards,
Simon


 --
 Tom

 ___
 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 1/9] FDT: Add compatible string for DWMMC

[Simon Glass]

On Mon, Dec 17, 2012 at 3:19 AM, Amar amarendra...@samsung.com wrote:
 Add required compatible information for DWMMC driver.

 Signed-off-by: Amar amarendra...@samsung.com

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

 ---
  include/fdtdec.h |1 +
  lib/fdtdec.c |1 +
  2 files changed, 2 insertions(+), 0 deletions(-)

 diff --git a/include/fdtdec.h b/include/fdtdec.h
 index 539bb1b..f09c281 100644
 --- a/include/fdtdec.h
 +++ b/include/fdtdec.h
 @@ -74,6 +74,7 @@ enum fdt_compat_id {
 COMPAT_SAMSUNG_EXYNOS5_SOUND,   /* Exynos Sound */
 COMPAT_WOLFSON_WM8994_CODEC,/* Wolfson WM8994 Sound Codec */
 COMPAT_SAMSUNG_EXYNOS_SPI,  /* Exynos SPI */
 +   COMPAT_SAMSUNG_EXYNOS5_DWMMC,   /* Exynos5 DWMMC controller */

 COMPAT_COUNT,
  };
 diff --git a/lib/fdtdec.c b/lib/fdtdec.c
 index 44c249d..6597661 100644
 --- a/lib/fdtdec.c
 +++ b/lib/fdtdec.c
 @@ -51,6 +51,7 @@ static const char * const compat_names[COMPAT_COUNT] = {
 COMPAT(SAMSUNG_EXYNOS5_SOUND, samsung,exynos-sound),
 COMPAT(WOLFSON_WM8994_CODEC, wolfson,wm8994-codec),
 COMPAT(SAMSUNG_EXYNOS_SPI, samsung,exynos-spi),
 +   COMPAT(SAMSUNG_EXYNOS5_DWMMC, samsung,exynos5250-dwmmc),
  };

  const char *fdtdec_get_compatible(enum fdt_compat_id id)
 --
 1.7.0.4

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

Re: [U-Boot] [PATCH 2/9] EXYNOS5: FDT: Add DWMMC device node data

[Simon Glass]

Hi Amar,

On Mon, Dec 17, 2012 at 3:19 AM, Amar amarendra...@samsung.com wrote:
 Add DWMMC device node data for exynos5

 Signed-off-by: Amar amarendra...@samsung.com
 ---
  arch/arm/dts/exynos5250.dtsi  |   32 
 +
  board/samsung/dts/exynos5250-smdk5250.dts |   24 +

Do you also have a binding file for this please?

  2 files changed, 56 insertions(+), 0 deletions(-)

 diff --git a/arch/arm/dts/exynos5250.dtsi b/arch/arm/dts/exynos5250.dtsi
 index 1008797..b701ae5 100644
 --- a/arch/arm/dts/exynos5250.dtsi
 +++ b/arch/arm/dts/exynos5250.dtsi
 @@ -138,4 +138,36 @@
 reg = 0x131b 0x30;
 interrupts = 0 130 0;
 };
 +
 +   dwmmc@1220 {
 +   #address-cells = 1;
 +   #size-cells = 0;
 +   compatible = samsung,exynos5250-dwmmc;
 +   reg = 0x1220 0x1000;
 +   interrupts = 0 75 0;
 +   };
 +
 +   dwmmc@1221 {
 +   #address-cells = 1;
 +   #size-cells = 0;
 +   compatible = samsung,exynos5250-dwmmc;
 +   reg = 0x1221 0x1000;
 +   interrupts = 0 76 0;
 +   };
 +
 +   dwmmc@1222 {
 +   #address-cells = 1;
 +   #size-cells = 0;
 +   compatible = samsung,exynos5250-dwmmc;
 +   reg = 0x1222 0x1000;
 +   interrupts = 0 77 0;
 +   };
 +
 +   dwmmc@1223 {
 +   #address-cells = 1;
 +   #size-cells = 0;
 +   compatible = samsung,exynos5250-dwmmc;
 +   reg = 0x1223 0x1000;
 +   interrupts = 0 78 0;
 +   };
  };
 diff --git a/board/samsung/dts/exynos5250-smdk5250.dts 
 b/board/samsung/dts/exynos5250-smdk5250.dts
 index a8e62da..b1b8d71 100644
 --- a/board/samsung/dts/exynos5250-smdk5250.dts
 +++ b/board/samsung/dts/exynos5250-smdk5250.dts
 @@ -30,6 +30,10 @@
 spi2 = /spi@12d4;
 spi3 = /spi@131a;
 spi4 = /spi@131b;
 +   dwmmc0 = /dwmmc@1220;
 +   dwmmc1 = /dwmmc@1221;
 +   dwmmc2 = /dwmmc@1222;
 +   dwmmc3 = /dwmmc@1223;
 };

 sromc@1225 {
 @@ -59,4 +63,24 @@
 compatible = wolfson,wm8994-codec;
 };
 };
 +
 +   dwmmc@1220 {
 +   index = 0;

Do you really need the index? You have the numbering from the aliaes I think.

 +   bus-width = 8;
 +   timing = 1 3 3;

Might need a samsung, prefix on these?

 +   };
 +
 +   dwmmc@1221 {
 +   status = disabled;
 +   };
 +
 +   dwmmc@1222 {
 +   index = 2;
 +   bus-width = 4;
 +   timing = 1 2 3;
 +   };
 +
 +   dwmmc@1223 {
 +   status = disabled;
 +   };
  };
 --
 1.7.0.4


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

Re: [U-Boot] [PATCH 4/9] EXYNOS5: DWMMC: Added dt support for DWMMC

[Simon Glass]

Hi Amar,

On Mon, Dec 17, 2012 at 3:19 AM, Amar amarendra...@samsung.com wrote:

 Signed-off-by: Amar amarendra...@samsung.com


Good to see this patch! Please can you add a short commit message?


 ---

 arch/arm/include/asm/arch-exynos/dwmmc.h |4 +
  drivers/mmc/exynos_dw_mmc.c  |  117
 --
  include/dwmmc.h  |4 +
  3 files changed, 119 insertions(+), 6 deletions(-)

 diff --git a/arch/arm/include/asm/arch-exynos/dwmmc.h
 b/arch/arm/include/asm/arch-exynos/dwmmc.h
 index 8acdf9b..92352df 100644
 --- a/arch/arm/include/asm/arch-exynos/dwmmc.h
 +++ b/arch/arm/include/asm/arch-exynos/dwmmc.h
 @@ -27,6 +27,9 @@
  #define DWMCI_SET_DRV_CLK(x)   ((x)  16)
  #define DWMCI_SET_DIV_RATIO(x) ((x)  24)

 +#ifdef CONFIG_OF_CONTROL
 +unsigned int exynos_dwmmc_init(const void *blob);
 +#else
  int exynos_dwmci_init(u32 regbase, int bus_width, int index);

  static inline unsigned int exynos_dwmmc_init(int index, int bus_width)
 @@ -34,3 +37,4 @@ static inline unsigned int exynos_dwmmc_init(int index,
 int bus_width)
 unsigned int base = samsung_get_base_mmc() + (0x1 * index);
 return exynos_dwmci_init(base, bus_width, index);
  }
 +#endif
 diff --git a/drivers/mmc/exynos_dw_mmc.c b/drivers/mmc/exynos_dw_mmc.c
 index 72a31b7..3b3e3e5 100644
 --- a/drivers/mmc/exynos_dw_mmc.c
 +++ b/drivers/mmc/exynos_dw_mmc.c
 @@ -19,23 +19,38 @@
   */

  #include common.h
 -#include malloc.h
  #include dwmmc.h
 +#include fdtdec.h
 +#include libfdt.h
 +#include malloc.h
  #include asm/arch/dwmmc.h
  #include asm/arch/clk.h
 +#include asm/arch/pinmux.h
 +
 +#defineDWMMC_MAX_CH_NUM4
 +#defineDWMMC_MAX_FREQ  5200
 +#defineDWMMC_MIN_FREQ  40
 +#defineDWMMC_MMC0_CLKSEL_VAL   0x03030001
 +#defineDWMMC_MMC2_CLKSEL_VAL   0x03020001


What do these last two values mean? I think clock setting should be done in
clock.c, not here.



  static char *EXYNOS_NAME = EXYNOS DWMMC;

  static void exynos_dwmci_clksel(struct dwmci_host *host)
  {
 -   u32 val;
 -   val = DWMCI_SET_SAMPLE_CLK(DWMCI_SHIFT_0) |
 -   DWMCI_SET_DRV_CLK(DWMCI_SHIFT_0) | DWMCI_SET_DIV_RATIO(0);
 +   dwmci_writel(host, DWMCI_CLKSEL, host-clksel_val);
 +}

 -   dwmci_writel(host, DWMCI_CLKSEL, val);
 +unsigned int exynos_dwmci_get_clk(int dev_index)
 +{
 +   return get_mmc_clk(dev_index);
  }

 +#ifdef CONFIG_OF_CONTROL
 +static int exynos_dwmci_init(u32 regbase, int bus_width,
 +   int index, u32 *timing)
 +#else
  int exynos_dwmci_init(u32 regbase, int bus_width, int index)
 +#endif


I'm really not keen on having the same function with different signatures.
My first question is whether we need to support operation without
CONFIG_OF_CONTROL. If so, I suggest having an init routine that takes an
FDT blob as a parameter, and a separate add_port function which can be
called by non-FDT-enabled board files. The init routine will call the
add_port function for each port it finds in the FDT.

Also please can you briefly comment non-trivial functions?


  {
 struct dwmci_host *host = NULL;
 host = malloc(sizeof(struct dwmci_host));
 @@ -44,14 +59,104 @@ int exynos_dwmci_init(u32 regbase, int bus_width, int
 index)
 return 1;
 }

 +   /* set the clock divisor - clk_div_fsys for mmc */
 +   if (exynos5_mmc_set_clk_div(index)) {
 +   debug(mmc clock div set failed\n);
 +   return -1;
 +   }
 +
 host-name = EXYNOS_NAME;
 host-ioaddr = (void *)regbase;
 host-buswidth = bus_width;
 +#ifdef CONFIG_OF_CONTROL
 +   host-clksel_val = (DWMCI_SET_SAMPLE_CLK(timing[0]) |
 +   DWMCI_SET_DRV_CLK(timing[1]) |
 +   DWMCI_SET_DIV_RATIO(timing[2]));
 +#else
 +   if (0 == index)
 +   host-clksel_val = DWMMC_MMC0_CLKSEL_VAL;
 +   if (2 == index)
 +   host-clksel_val = DWMMC_MMC2_CLKSEL_VAL;
 +#endif
 host-clksel = exynos_dwmci_clksel;
 host-dev_index = index;
 +   host-mmc_clk = exynos_dwmci_get_clk;

 -   add_dwmci(host, 5200, 40);
 +   add_dwmci(host, DWMMC_MAX_FREQ, DWMMC_MIN_FREQ);

 return 0;
  }

 +#ifdef CONFIG_OF_CONTROL
 +unsigned int exynos_dwmmc_init(const void *blob)
 +{
 +   u32 base;
 +   int index, bus_width;
 +   int node_list[DWMMC_MAX_CH_NUM];
 +   int err = 0;
 +   int dev_id, flag;
 +   u32 timing[3];
 +   int count, i;
 +
 +   count = fdtdec_find_aliases_for_id(blob, dwmmc,
 +   COMPAT_SAMSUNG_EXYNOS5_DWMMC, node_list,
 +   DWMMC_MAX_CH_NUM);
 +
 +   for (i = 0; i  count; i++) {
 +   int node = node_list[i];
 +
 +   if (node = 0)
 +   continue;
 +
 +  

Re: [U-Boot] [PATCH 5/9] EXYNOS5: DWMMC: API to set mmc clock divisor

[Simon Glass]

Hi Amar,

On Mon, Dec 17, 2012 at 3:19 AM, Amar amarendra...@samsung.com wrote:

 This API computes the divisor value based on MPLL clock and
 writes it into the FSYS1 register.

 Signed-off-by: Amar amarendra...@samsung.com
 ---
  arch/arm/cpu/armv7/exynos/clock.c  |   39
 ++-
  arch/arm/include/asm/arch-exynos/clk.h |1 +
  2 files changed, 38 insertions(+), 2 deletions(-)

 diff --git a/arch/arm/cpu/armv7/exynos/clock.c
 b/arch/arm/cpu/armv7/exynos/clock.c
 index 731bbff..6517296 100644
 --- a/arch/arm/cpu/armv7/exynos/clock.c
 +++ b/arch/arm/cpu/armv7/exynos/clock.c
 @@ -379,7 +379,7 @@ static unsigned long exynos4_get_mmc_clk(int dev_index)
 (struct exynos4_clock *)samsung_get_base_clock();
 unsigned long uclk, sclk;
 unsigned int sel, ratio, pre_ratio;
 -   int shift;
 +   int shift = 0;

 sel = readl(clk-src_fsys);
 sel = (sel  (dev_index  2))  0xf;
 @@ -428,7 +428,7 @@ static unsigned long exynos5_get_mmc_clk(int dev_index)
 (struct exynos5_clock *)samsung_get_base_clock();
 unsigned long uclk, sclk;
 unsigned int sel, ratio, pre_ratio;
 -   int shift;
 +   int shift = 0;

 sel = readl(clk-src_fsys);
 sel = (sel  (dev_index  2))  0xf;
 @@ -526,6 +526,41 @@ static void exynos5_set_mmc_clk(int dev_index,
 unsigned int div)
 writel(val, addr);
  }

 +/* exynos5: set the mmc clock div ratio in fsys1 */
 +int exynos5_mmc_set_clk_div(int dev_index)


Shouldn't this take a periph_id instead of a dev_index?


 +{
 +   struct exynos5_clock *clk =
 +   (struct exynos5_clock *)samsung_get_base_clock();
 +   unsigned int addr;
 +   unsigned int clock;
 +   unsigned int tmp;
 +   unsigned int i;
 +
 +   /* get mpll clock */
 +   clock = get_pll_clk(MPLL) / 100;
 +
 +   /*
 +* CLK_DIV_FSYS1
 +* MMC0_PRE_RATIO [15:8], MMC0_RATIO [3:0]
 +* CLK_DIV_FSYS2
 +* MMC2_PRE_RATIO [15:8], MMC2_RATIO [3:0]
 +*/
 +   if (dev_index  2) {
 +   addr = (unsigned int)clk-div_fsys1;
 +   } else {
 +   addr = (unsigned int)clk-div_fsys2;
 +   }
 +
 +   tmp = readl(addr)  ~FSYS1_MMC0_DIV_MASK;
 +   for (i = 0; i = 0xf; i++) {
 +   if ((clock / (i + 1)) = 400) {
 +   writel(tmp | i  0, addr);
 +   break;
 +   }
 +   }
 +   return 0;
 +}
 +
  /* get_lcd_clk: return lcd clock frequency */
  static unsigned long exynos4_get_lcd_clk(void)
  {
 diff --git a/arch/arm/include/asm/arch-exynos/clk.h
 b/arch/arm/include/asm/arch-exynos/clk.h
 index ff155d8..b0ecdd4 100644
 --- a/arch/arm/include/asm/arch-exynos/clk.h
 +++ b/arch/arm/include/asm/arch-exynos/clk.h
 @@ -36,6 +36,7 @@ unsigned long get_pwm_clk(void);
  unsigned long get_uart_clk(int dev_index);
  unsigned long get_mmc_clk(int deV_index);
  void set_mmc_clk(int dev_index, unsigned int div);
 +int exynos5_mmc_set_clk_div(int dev_index);
  unsigned long get_lcd_clk(void);
  void set_lcd_clk(void);
  void set_mipi_clk(void);
 --
 1.7.0.4


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

Re: [U-Boot] [PATCH 6/9] SMDK5250: Enable DWMMC

[Simon Glass]

Hi Amar,

On Mon, Dec 17, 2012 at 3:19 AM, Amar amarendra...@samsung.com wrote:

 This patch enables DWMMC for SMDK5250.
 Support both dt and non-dt versions.

 Signed-off-by: Amar amarendra...@samsung.com
 ---
  board/samsung/smdk5250/smdk5250.c |   36
 
  include/configs/exynos5250-dt.h   |9 +
  2 files changed, 41 insertions(+), 4 deletions(-)

 diff --git a/board/samsung/smdk5250/smdk5250.c
 b/board/samsung/smdk5250/smdk5250.c
 index 4d24978..7a9c8f6 100644
 --- a/board/samsung/smdk5250/smdk5250.c
 +++ b/board/samsung/smdk5250/smdk5250.c
 @@ -27,6 +27,7 @@
  #include netdev.h
  #include spi.h
  #include asm/arch/cpu.h
 +#include asm/arch/dwmmc.h
  #include asm/arch/gpio.h
  #include asm/arch/mmc.h
  #include asm/arch/pinmux.h
 @@ -192,16 +193,43 @@ int checkboard(void)
  #ifdef CONFIG_GENERIC_MMC
  int board_mmc_init(bd_t *bis)
  {
 -   int err;
 +   int err = 0, ret = 0;

 +#ifdef CONFIG_OF_CONTROL
 +   /* dwmmc initializattion for available channels */
 +   err = exynos_dwmmc_init(gd-fdt_blob);
 +   if (err) {
 +   debug(dwmmc init failed\n);
 +   }
 +   ret |= err;
 +#else
 err = exynos_pinmux_config(PERIPH_ID_SDMMC0,
 PINMUX_FLAG_8BIT_MODE);
 if (err) {
 debug(SDMMC0 not configured\n);
 -   return err;
 }
 +   ret |= err;


Perhaps we need an exynos5-dt.c board file instead of using smdk5250? It
seems like you will end up with lots of #ifdefs otherwise.



 -   err = s5p_mmc_init(0, 8);
 -   return err;
 +   /*eMMC: dwmmc Channel-0 with 8 bit bus width */
 +   err = exynos_dwmmc_init(0, 8);
 +   if (err) {
 +   debug(dwmmc Channel-0 init failed\n);


Don't need {} here.


 +   }
 +   ret |= err;
 +
 +   err = exynos_pinmux_config(PERIPH_ID_SDMMC2, PINMUX_FLAG_NONE);
 +   if (err) {
 +   debug(SDMMC2 not configured\n);


and here


 +   }
 +   ret |= err;
 +
 +   /*SD: dwmmc Channel-2 with 4 bit bus width */
 +   err = exynos_dwmmc_init(2, 4);
 +   if (err) {
 +   debug(dwmmc Channel-2 init failed\n);
 +   }
 +   ret |= err;
 +#endif
 +   return ret;
  }
  #endif

 diff --git a/include/configs/exynos5250-dt.h
 b/include/configs/exynos5250-dt.h
 index 12f555c..3b89e20 100644
 --- a/include/configs/exynos5250-dt.h
 +++ b/include/configs/exynos5250-dt.h
 @@ -84,6 +84,8 @@
  #define CONFIG_MMC
  #define CONFIG_SDHCI
  #define CONFIG_S5P_SDHCI
 +#define CONFIG_DWMMC


What does this config enable? Is it in a README somewhere?


 +#define CONFIG_EXYNOS_DWMMC

  #define CONFIG_BOARD_EARLY_INIT_F

 @@ -116,6 +118,13 @@
  #define CONFIG_SPL
  #define COPY_BL2_FNPTR_ADDR0x02020030

 +/* eMMC4.4 SPL */
 +#define EMMC44_COPY_BL2_FNPTR_ADDR 0x02020044
 +#define EMMC44_END_BOOTOP_FNPTR_ADDR   0x02020048


What are these for?


 +
 +#define FSYS1_MMC0_DIV_MASK0xff0f


This seems like something for the SOC headers, not the board header.


 +
 +
  /* specific .lds file */
  #define CONFIG_SPL_LDSCRIPT
  board/samsung/smdk5250/smdk5250-uboot-spl.lds
  #define CONFIG_SPL_TEXT_BASE   0x02023400
 --
 1.7.0.4


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

Re: [U-Boot] [PATCH 7/9] MMC: APIs to support creation of boot partition

[Simon Glass]

Hi Amar,

On Mon, Dec 17, 2012 at 3:19 AM, Amar amarendra...@samsung.com wrote:

 This pathc adds APIs to open, close and to create boot partiton for eMMC.

 Signed-off-by: Amar amarendra...@samsung.com


I think you should run checkpatch (or patman!) on your patches to get rid
of little errors. Or maybe you need to upgrade your checkpatch.


 ---
  drivers/mmc/mmc.c |  118
 +
  include/mmc.h |   16 +++
  2 files changed, 134 insertions(+), 0 deletions(-)

 diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
 index 5ffd8c5..88b0435 100644
 --- a/drivers/mmc/mmc.c
 +++ b/drivers/mmc/mmc.c
 @@ -1302,3 +1302,121 @@ int mmc_initialize(bd_t *bis)

 return 0;
  }
 +
 +int mmc_boot_partition_size_change(struct mmc *mmc, unsigned long
 bootsize,
 +   unsigned long rpmbsize)
 +{
 +   int err;
 +   struct mmc_cmd cmd;
 +
 +   /* Only use this command for raw eMMC moviNAND */
 +   /* Enter backdoor mode */


/*
 * line 1
 * line 2
 */

 +   cmd.cmdidx = MMC_CMD_RES_MAN;
 +   cmd.resp_type = MMC_RSP_R1b;
 +   cmd.cmdarg = MMC_CMD62_ARG1;
 +


[snip]

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

Re: [U-Boot] [PATCH 8/9] SMDK5250: Enable eMMC booting

[Simon Glass]

Hi Amar,

On Mon, Dec 17, 2012 at 3:19 AM, Amar amarendra...@samsung.com wrote:

 This patch adds support for eMMC booting on SMDK5250

 Signed-off-by: Amar amarendra...@samsung.com
 ---
  board/samsung/smdk5250/spl_boot.c |   38
 -
  1 files changed, 37 insertions(+), 1 deletions(-)

 diff --git a/board/samsung/smdk5250/spl_boot.c
 b/board/samsung/smdk5250/spl_boot.c
 index d8f3c1e..2648b4e 100644
 --- a/board/samsung/smdk5250/spl_boot.c
 +++ b/board/samsung/smdk5250/spl_boot.c
 @@ -23,15 +23,40 @@
  #includecommon.h
  #includeconfig.h

 +#include asm/arch/clock.h
 +#include asm/arch/clk.h
 +
 +#define FSYS1_MMC0_DIV_VAL  0x0701


Should go in arch/arm/include/... ?


 +
  enum boot_mode {
 BOOT_MODE_MMC = 4,
 +   BOOT_MODE_eMMC = 8, /* eMMC44 */


I think should you use upper case E, although I'm not completely sure.


 BOOT_MODE_SERIAL = 20,
 /* Boot based on Operating Mode pin settings */
 BOOT_MODE_OM = 32,
 BOOT_MODE_USB,  /* Boot using USB download */
  };

 -   typedef u32 (*spi_copy_func_t)(u32 offset, u32 nblock, u32 dst);
 +typedef u32 (*spi_copy_func_t)(u32 offset, u32 nblock, u32 dst);


Should avoid adding typedefs.


 +static void set_emmc_clk(void);
 +
 +/*
 +* Set MMC0 clock divisor value.
 +* So that the mmc0 device operating freq is 50MHz.


Do we only support booting from mmc0? That's fine, but I suggest adding a
little comment.


 +*/
 +static void set_emmc_clk(void)
 +{
 +   struct exynos5_clock *clk = (struct exynos5_clock
 *)EXYNOS5_CLOCK_BASE;
 +   unsigned int addr;
 +   unsigned int div_mmc;
 +
 +   addr = (unsigned int) clk-div_fsys1;
 +
 +   div_mmc = readl(addr)  ~FSYS1_MMC0_DIV_MASK;
 +   div_mmc |= FSYS1_MMC0_DIV_VAL;
 +   writel(div_mmc, addr);


Can this function go in clock.c?


 +}
 +

  /*
  * Copy U-boot from mmc to RAM:
 @@ -43,6 +68,8 @@ void copy_uboot_to_ram(void)
 spi_copy_func_t spi_copy;
 enum boot_mode bootmode;
 u32 (*copy_bl2)(u32, u32, u32);
 +   u32 (*copy_bl2_emmc)(u32, u32);
 +   void (*end_bootop_emmc)(void);

 bootmode = readl(EXYNOS5_POWER_BASE)  OM_STAT;

 @@ -57,6 +84,15 @@ void copy_uboot_to_ram(void)
 copy_bl2(BL2_START_OFFSET, BL2_SIZE_BLOC_COUNT,
 CONFIG_SYS_TEXT_BASE);
 break;
 +   case BOOT_MODE_eMMC:
 +   set_emmc_clk();
 +   end_bootop_emmc = (void *) *(u32
 *)EMMC44_END_BOOTOP_FNPTR_ADDR;
 +   copy_bl2_emmc = (void *) *(u32
 *)EMMC44_COPY_BL2_FNPTR_ADDR;


I think these are pointers to functions in the IROM. Do they have the same
signature? Is it possible to create a table of them somewhere instead of
using defines?


 +
 +   copy_bl2_emmc(BL2_SIZE_BLOC_COUNT, CONFIG_SYS_TEXT_BASE);
 +   end_bootop_emmc();
 +   break;
 +
 default:
 break;
 }
 --
 1.7.0.4


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

Re: [U-Boot] [PATCH 9/9] COMMON: MMC: Command to support eMMC booting

[Simon Glass]

Hi Amar,

On Mon, Dec 17, 2012 at 3:19 AM, Amar amarendra...@samsung.com wrote:

 This patch adds commands to open, close and create partitions on eMMC

 Signed-off-by: Amar amarendra...@samsung.com
 ---
  common/cmd_mmc.c |  101
 +-
  1 files changed, 100 insertions(+), 1 deletions(-)

 diff --git a/common/cmd_mmc.c b/common/cmd_mmc.c
 index 62a1c22..1fd6b94 100644
 --- a/common/cmd_mmc.c
 +++ b/common/cmd_mmc.c
 @@ -248,6 +248,102 @@ static int do_mmcops(cmd_tbl_t *cmdtp, int flag, int
 argc, char * const argv[])
 curr_device, mmc-part_num);

 return 0;
 +   } else if (strcmp(argv[1], open) == 0) {
 +   int dev;
 +   struct mmc *mmc;
 +
 +   if (argc == 2)
 +   dev = curr_device;
 +   else if (argc == 3)
 +   dev = simple_strtoul(argv[2], NULL, 10);
 +   else if (argc == 4)
 +   return 1;


Should this be  CMD_RET_USAGE? What is returning 1 for?

 +
 +   else
 +   return CMD_RET_USAGE;
 +
 +   mmc = find_mmc_device(dev);
 +   if (!mmc) {
 +   printf(no mmc device at slot %x\n, dev);
 +   return 1;
 +   }
 +
 +   if (IS_SD(mmc)) {
 +   printf(SD device cannot be opened/closed\n);
 +   return 1;
 +   }
 +
 +   if (!(mmc_boot_open(mmc))) {
 +   printf(eMMC OPEN Success.!!\n);
 +   printf(\t\t\t!!!Notice!!!\n);
 +   printf(!You must close eMMC boot Partition
 +   after all image
 writing!\n);
 +   printf(!eMMC boot partition has continuity
 +   at image writing
 time.!\n);
 +   printf(!So, Do not close boot partition, Before,
 +   all images is
 written.!\n);


Maybe:

 So, do not close boot partition before all images are written

+   } else {
 +   printf(eMMC OPEN Failed.!!\n);


Is it eMMC or MMC? Lower case or upper case? Your messages should be
consistent. And you don't need the !!! I think.


 +   }
 +   return 0;
 +
 +   } else if (strcmp(argv[1], close) == 0) {
 +   int dev;
 +   struct mmc *mmc;
 +
 +   if (argc == 2)
 +   dev = curr_device;
 +   else if (argc == 3)
 +   dev = simple_strtoul(argv[2], NULL, 10);
 +   else if (argc == 4)
 +   return 1;


Same Q here as above.


 +   else
 +   return CMD_RET_USAGE;
 +
 +   mmc = find_mmc_device(dev);
 +   if (!mmc) {
 +   printf(no mmc device at slot %x\n, dev);
 +   return 1;
 +   }
 +
 +   if (IS_SD(mmc)) {
 +   printf(SD device cannot be opened/closed\n);
 +   return 1;
 +   }
 +


Seems the open/close code is almost the same. Can you combine it?


 +   if (!(mmc_boot_close(mmc)))
 +   printf(eMMC CLOSE Success.!!\n);
 +   else
 +   printf(eMMC CLOSE Failed.!!\n);
 +
 +   return 0;
 +
 +   } else if (strcmp(argv[1], bootpart) == 0) {
 +   int dev;
 +   dev = simple_strtoul(argv[2], NULL, 10);
 +
 +   struct mmc *mmc = find_mmc_device(dev);
 +   u32 bootsize = simple_strtoul(argv[3], NULL, 10);
 +   u32 rpmbsize = simple_strtoul(argv[4], NULL, 10);
 +
 +   if (!mmc) {
 +   printf(no mmc device at slot %x\n, dev);
 +   return 1;
 +   }
 +
 +   if (IS_SD(mmc)) {
 +   printf(It is not a eMMC device\n);
 +   return 1;
 +   }
 +
 +   if (0 == mmc_boot_partition_size_change(mmc,
 +   bootsize, rpmbsize)) {
 +   printf(eMMC boot partition Size %d MB!!\n,
 bootsize);
 +   printf(eMMC RPMB partition Size %d MB!!\n,
 rpmbsize);
 +   } else {
 +   printf(eMMC boot partition Size change
 Failed.!!\n);


return 1 here I think


 +   }
 +   return 0;
 }

 if (strcmp(argv[1], read) == 0)
 @@ -318,5 +414,8 @@ U_BOOT_CMD(
 mmc rescan\n
 mmc part - lists available partition on current mmc device\n
 mmc dev [dev] [part] - show or set current mmc device
 [partition]\n
 -   mmc list - lists available devices);
 +   mmc list - lists 

[U-Boot] [PATCH] powerpc/t4240qds: Update IFC timing for NOR flash

[Prabhakar Kushwaha]

From: York Sun york...@freescale.com

Relax parameters to give address latching more time to setup.
Tighten parameters to make it overall faster.

Signed-off-by: York Sun york...@freescale.com
---
 include/configs/t4qds.h |   10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/include/configs/t4qds.h b/include/configs/t4qds.h
index 9e14d88..5d0d48f 100644
--- a/include/configs/t4qds.h
+++ b/include/configs/t4qds.h
@@ -213,14 +213,14 @@ unsigned long get_board_ddr_clk(void);
 /* NOR Flash Timing Params */
 #define CONFIG_SYS_NOR_CSORCSOR_NAND_TRHZ_80
 
-#define CONFIG_SYS_NOR_FTIM0   (FTIM0_NOR_TACSE(0x01) | \
-   FTIM0_NOR_TEADC(0x01) | \
-   FTIM0_NOR_TEAHC(0x20))
+#define CONFIG_SYS_NOR_FTIM0   (FTIM0_NOR_TACSE(0x4) | \
+   FTIM0_NOR_TEADC(0x5) | \
+   FTIM0_NOR_TEAHC(0x5))
 #define CONFIG_SYS_NOR_FTIM1   (FTIM1_NOR_TACO(0x35) | \
FTIM1_NOR_TRAD_NOR(0x1A) |\
FTIM1_NOR_TSEQRAD_NOR(0x13))
-#define CONFIG_SYS_NOR_FTIM2   (FTIM2_NOR_TCS(0x01) | \
-   FTIM2_NOR_TCH(0x0E) | \
+#define CONFIG_SYS_NOR_FTIM2   (FTIM2_NOR_TCS(0x4) | \
+   FTIM2_NOR_TCH(0x4) | \
FTIM2_NOR_TWPH(0x0E) | \
FTIM2_NOR_TWP(0x1c))
 #define CONFIG_SYS_NOR_FTIM3   0x0
-- 
1.7.9.5



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

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

[Nobuhiro Iwamatsu]

Hi Tom,

Please pull u-boot-sh master branch.

Best regards,
  Nobuhiro

The following changes since commit 095728803eedfce850a2f85828f79500cb09979e:

  Merge branch 'master' of git://git.denx.de/u-boot-net (2012-12-17
18:39:50 -0700)

are available in the git repository at:


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

for you to fetch changes up to bb474b8187878181493b4ba1d422fb83df9b4335:

  serial_sh: Add support Renesas SH7752 (2012-12-20 13:20:17 +0900)


Yoshihiro Shimoda (2):
  sh: add support for sh7752evb board
  serial_sh: Add support Renesas SH7752

 MAINTAINERS |1 +
 arch/sh/include/asm/cpu_sh4.h   |2 +
 arch/sh/include/asm/cpu_sh7752.h|  211
++
 board/renesas/sh7752evb/Makefile|   36 ++
 board/renesas/sh7752evb/lowlevel_init.S |  460
+
 board/renesas/sh7752evb/sh7752evb.c |  330

 board/renesas/sh7752evb/spi-boot.c  |  116 ++
 board/renesas/sh7752evb/u-boot.lds  |   97 +
 boards.cfg  |1 +
 doc/README.sh7752evb|   67 +
 drivers/serial/serial_sh.h  |2 +-
 include/configs/sh7752evb.h |  153
+++
 12 files changed, 1475 insertions(+), 1 deletion(-)
 create mode 100644 arch/sh/include/asm/cpu_sh7752.h
 create mode 100644 board/renesas/sh7752evb/Makefile
 create mode 100644 board/renesas/sh7752evb/lowlevel_init.S
 create mode 100644 board/renesas/sh7752evb/sh7752evb.c
 create mode 100644 board/renesas/sh7752evb/spi-boot.c
 create mode 100644 board/renesas/sh7752evb/u-boot.lds
 create mode 100644 doc/README.sh7752evb
 create mode 100644 include/configs/sh7752evb.h


-- 
Nobuhiro Iwamatsu
   iwamatsu at {nigauri.org / debian.org}
   GPG ID: 40AD1FA6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot,1/3] fw_env: fix type of len

[Joe Hershberger]

Hi Tom,

On Wed, Dec 19, 2012 at 5:00 PM, Tom Rini tr...@ti.com wrote:
 On Sat, Nov 10, 2012 at 07:47:45PM -, Mike Frysinger wrote:

 This variable is assigned by a size_t, and is printed that way, but is
 incorrectly declared as an int.  Which means we get warnings:
 fw_env.c: In function 'fw_setenv':
 fw_env.c:409:5: warning: format '%zu' expects argument of type 'size_t',
   but argument 3 has type 'int' [-Wformat]

 Signed-off-by: Mike Frysinger vap...@gentoo.org
 Acked-by: Joe Hershberger joe.hershber...@ni.com

 For the series, applied to u-boot/master, thanks!

I NACKed the third in this series.  Did you not see it?

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

Re: [U-Boot] please pull u-boot-samsung/resolve

[Minkyu Kang]

Dear Albert and Stephen,

On 20/12/12 01:28, Albert ARIBAUD wrote:
 Hi Minkyu,
 
 On Tue, 18 Dec 2012 00:14:34 +0900, Minkyu Kang proms...@gmail.com
 wrote:
 Dear Albert,

 On Saturday, December 15, 2012, Albert ARIBAUD wrote:

 Hi Minkyu,

 On Fri, 14 Dec 2012 09:14:11 +0900, Minkyu Kang 
 mk7.k...@samsung.comjavascript:;

 wrote:
 On 14/12/12 04:56, Albert ARIBAUD wrote:
 Hi Minkyu,

 On Tue, 11 Dec 2012 20:10:06 +0900, Minkyu Kang mk7.k...@samsung.com
 wrote:
 Dear Albert,

 The following changes since commit
 fd4d564b3c80b111f18c93adb14233a6a7ddb0e9:

   Merge branch 'master' of git://git.denx.de/u-boot-x86 (2012-12-07
 08:47:59 -0700)

 are available in the git repository at:


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

 for you to fetch changes up to
 fbef8e6e7f1233ed20f8c5045e12c9cf31b43540:

   universal_c210: check the NULL pointer when get the PMIC
 (2012-12-11 17:37:28 +0900)

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

 Allen Martin (1):
   tegra: add CONSOLE_MUX support to tegra-kbc

 Ashok Kumar Reddy (1):
   ARM: arm1176: Define arch_cpu_init() for s3c64xx

 Benoît Thébaudeau (17):
   arm1136: Fix enable_caches()
   mx31: Move EHCI definitions to ehci-fsl.h
   ehci-mxc: Clean up
   ehci-mx5: Clean up
   ehci-mx5: Fix OC_DIS usage
   ehci-mx5: Fix OPM usage
   ehci-mx5: Fix *PM usage for i.MX53
   ehci-mx5: Add missing OC_DIS for i.MX53
   ehci-mxc: Make EHCI power/oc polarities configurable
   ehci-mxc: Make i.MX25 EHCI configurable
   ehci-mxc: Define host offsets
   ehci-mxc: Add support for i.MX35
   mx35pdk: Add support for OTG
   ehci-mx5/6: Make board_ehci_hcd_init() optional
   ehci-mxc: Fix host power mask bit for i.MX35
   ehci-mxc: Fix host power mask bit for i.MX25
   mx5: Mark lowlevel_init board-specific code

 Chander Kashyap (1):
   Exynos5250: Enable PXE Support

 Fabio Estevam (24):
   mx25pdk: Include CONFIG_MX25
   mx25pdk: Add esdhc support
   pmic_fsl: Introduce FSL_PMIC_I2C_LENGTH
   mx25: Place common functions into sys_proto.h
   pmic: Add support for mc34704
   mx25pdk: Add Ethernet support
   mx53loco: Allow booting a zImage kernel
   mx25pdk: Allow booting a zImage kernel
   mx51evk: Allow booting a zImage kernel
   mx35pdk: Allow booting a zImage kernel
   mx6qsabre_common: Allow booting a zImage kernel
   mx5: Align SPI CS naming with i.MX53 reference manual
   mx5: Print CSPI clock in 'clock' command
   spi: mxc_spi: Fix handling of chip select
   spi: mxc_spi: Fix spi clock glitch durant reset
   mx6: clock: Only show CSPI clock if CSPI is enabled
   mx28evk: Configure CONFIG_BOOTDELAY to one second
   mx53loco: Configure CONFIG_BOOTDELAY to one second
   mx6qsabrelite: Configure CONFIG_BOOTDELAY to one second
   mx6qsabre_common: Configure CONFIG_BOOTDELAY to one second
   mx51evk: Configure CONFIG_BOOTDELAY to one second
   mx25pdk: Configure CONFIG_BOOTDELAY to one sYou're right. I was
 a bit quick to reply when I read Stephen's
 question. Can you please address it too?

 Address for what?
 
 Can you answer the question Stephen has asked on this list on 11/12 ?
 
 http://www.mail-archive.com/u-boot@lists.denx.de/msg101291.html

Comes from u-boot-arm tree.
The base of this pull request is u-boot tree, hence some u-boot-arm commits are 
included.
But it doesn't matter maybe.. because this pull request is for u-boot-arm tree.

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

Re: [U-Boot] [PATCH 1/2] spi: Add progress percentage and write speed to `sf update`

[Wolfgang Denk]

Dear Scott Wood,

In message 1355960533.12062.16@snotra you wrote:

  Hmmm I suppose that is a good point. The main issue with SPI flash is
  that it is extremely slow, and writing a few MB can take a minute or
  so. The 'sf update' command was intended to do a smart update, and the
  progress is useful for that. Other storage types are not so bad.
 
 NOR can be pretty slow as well -- and it does have a progress indicator  
 in U-Boot (albeit a simpler one).

Actually even this should be configurable.

Especially the spinning wheel used on some boards is a mess.


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

What happened to the crewman? The M-5 computer  needed  a  new
power source, the crewman merely got in the way.
-- Kirk and Dr. Richard Daystrom, The Ultimate Computer,
   stardate 4731.3.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] please pull u-boot-samsung/resolve

[Stephen Warren]

On 12/19/2012 10:59 PM, Minkyu Kang wrote:
 Dear Albert and Stephen,
 
 On 20/12/12 01:28, Albert ARIBAUD wrote:
...
 Can you answer the question Stephen has asked on this list on 11/12 ?

 http://www.mail-archive.com/u-boot@lists.denx.de/msg101291.html
 
 Comes from u-boot-arm tree.
 The base of this pull request is u-boot tree, hence some u-boot-arm commits 
 are included.
 But it doesn't matter maybe.. because this pull request is for u-boot-arm 
 tree.

OK, that might explain it, but isn't there a way to list only the new
commits?

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

Re: [U-Boot] [PATCH 1/4] arm/km: fix memory settings

[Prafulla Wadaskar]

 -Original Message-
 From: Holger Brunck [mailto:holger.bru...@keymile.com]
 Sent: 02 November 2012 15:45
 To: u-boot@lists.denx.de
 Cc: Holger Brunck; Valentin Longchamp; Prafulla Wadaskar
 Subject: [PATCH 1/4] arm/km: fix memory settings
 
 On kmcoge5un we faced some serious problems with the memory during
 temperature tests. Reason was that we overwrite some registers for
 memory settings which have to leave untouched. These where registers
 0x20148 , 0x2014c and 0x20154.
 So writing these registers is prohibited and this patch removes them
 from all km related config files. Even if the problem was only
 seen on kmcoge5un.
 
 Signed-off-by: Holger Brunck holger.bru...@keymile.com
 Signed-off-by: Valentin Longchamp valentin.longch...@keymile.com
 cc: Prafulla Wadaskar prafu...@marvell.com
 ---
  board/keymile/km_arm/kwbimage-memphis.cfg  |6 +++---
  board/keymile/km_arm/kwbimage.cfg  |6 +++---
  board/keymile/km_arm/kwbimage_128M16_1.cfg |   25 ++-
 --
  board/keymile/km_arm/kwbimage_256M8_1.cfg  |   25 ++-
 --
  4 files changed, 10 insertions(+), 52 deletions(-)
 
 diff --git a/board/keymile/km_arm/kwbimage-memphis.cfg
 b/board/keymile/km_arm/kwbimage-memphis.cfg
 index 6df2ad7..5aa0de2 100644
 --- a/board/keymile/km_arm/kwbimage-memphis.cfg
 +++ b/board/keymile/km_arm/kwbimage-memphis.cfg
 @@ -55,9 +55,9 @@ DATA 0xFFD10008 0x1100  # MPP Control 2
 Register
  DATA 0xFFD100E0 0x1B1B1B1B   # IO Configuration 0 Register
  DATA 0xFFD20134 0x   # L2 RAM Timing 0 Register
  DATA 0xFFD20138 0x   # L2 RAM Timing 1 Register
 -DATA 0xFFD20154 0x0200   # CPU RAM Management Control3 Register
 -DATA 0xFFD2014C 0x1C00   # CPU RAM Management Control1 Register
 -DATA 0xFFD20148 0x0001   # CPU RAM Management Control0 Register
 +
 +# NOTE: Don't write on 0x20148 , 0x2014c and 0x20154, leave them
 untouched!
 +# If not it could cause KW Exceptions during boot in Fast
 Corners/High Voltage
 
  #Dram initalization
  DATA 0xFFD01400 0x430004E0   # SDRAM Configuration Register
 diff --git a/board/keymile/km_arm/kwbimage.cfg
 b/board/keymile/km_arm/kwbimage.cfg
 index b2f5193..e5e9942 100644
 --- a/board/keymile/km_arm/kwbimage.cfg
 +++ b/board/keymile/km_arm/kwbimage.cfg
 @@ -52,9 +52,9 @@ DATA 0xFFD10008 0x1100  # MPP Control 2
 Register
  DATA 0xFFD100E0 0x1B1B1B1B   # IO Configuration 0 Register
  DATA 0xFFD20134 0x   # L2 RAM Timing 0 Register
  DATA 0xFFD20138 0x   # L2 RAM Timing 1 Register
 -DATA 0xFFD20154 0x0200   # CPU RAM Management Control3 Register
 -DATA 0xFFD2014C 0x1C00   # CPU RAM Management Control1 Register
 -DATA 0xFFD20148 0x0001   # CPU RAM Management Control0 Register
 +
 +# NOTE: Don't write on 0x20148 , 0x2014c and 0x20154, leave them
 untouched!
 +# If not it could cause KW Exceptions during boot in Fast
 Corners/High Voltage
 
  #Dram initalization
  DATA 0xFFD01400 0x43000400   # SDRAM Configuration Register
 diff --git a/board/keymile/km_arm/kwbimage_128M16_1.cfg
 b/board/keymile/km_arm/kwbimage_128M16_1.cfg
 index bcce907..5de8df7 100644
 --- a/board/keymile/km_arm/kwbimage_128M16_1.cfg
 +++ b/board/keymile/km_arm/kwbimage_128M16_1.cfg
 @@ -98,29 +98,8 @@ DATA 0xFFD20138 0x # L2 RAM Timing 1
 Register
  # bit 19-18: 1, ECC RAM WTC RAM0
  # bit 31-20: ???,Reserve
 
 -DATA 0xFFD20154 0x0200   # CPU RAM Management Control3 Register
 -# bit 23-0:  0x000200, Addr Config tuning
 -# bit 31-24: 0,Reserved
 -
 -# ??? Missing register # CPU RAM Management Control2 Register
 -
 -DATA 0xFFD2014C 0x1C00   # CPU RAM Management Control1 Register
 -# bit 15-0:  0x1C00, Opmux Tuning
 -# bit 31-16: 0,  Pc Dp Tuning
 -
 -DATA 0xFFD20148 0x0001   # CPU RAM Management Control0 Register
 -# bit 1-0:   1, addr clk tune
 -# bit 3-2:   0, reserved
 -# bit 5-4:   0, dtcmp clk tune
 -# bit 7-6:   0, reserved
 -# bit 9-8:   0, macdrv clk tune
 -# bit 11-10: 0, opmuxgm2 clk tune
 -# bit 15-14: 0, rf clk tune
 -# bit 17-16: 0, rfbypass clk tune
 -# bit 19-18: 0, pc dp clk tune
 -# bit 23-20: 0, icache clk tune
 -# bit 27:24: 0, dcache clk tune
 -# bit 31:28: 0, regfile tunin
 +# NOTE: Don't write on 0x20148 , 0x2014c and 0x20154, leave them
 untouched!
 +# If not it could cause KW Exceptions during boot in Fast
 Corners/High Voltage
 
  # SDRAM initalization
  DATA 0xFFD01400 0x430004E0   # SDRAM Configuration Register
 diff --git a/board/keymile/km_arm/kwbimage_256M8_1.cfg
 b/board/keymile/km_arm/kwbimage_256M8_1.cfg
 index 3e1237b..d0a09f6 100644
 --- a/board/keymile/km_arm/kwbimage_256M8_1.cfg
 +++ b/board/keymile/km_arm/kwbimage_256M8_1.cfg
 @@ -100,29 +100,8 @@ DATA 0xFFD20138 0x   # L2 RAM Timing 1
 Register
  # bit 19-18: 1, ECC RAM WTC RAM0
  # bit 31-20: ?,Reserved
 
 -DATA 0xFFD20154 0x0200   # CPU RAM Management Control3 Register
 -# bit 23-0:  0x000200, Addr Config tuning
 -# bit 31-24: 0,Reserved
 -
 -# ??? Missing register # CPU 

Re: [U-Boot] [PATCH 2/4] km/common: drop unneeded std* environment variables

[Prafulla Wadaskar]

 -Original Message-
 From: Holger Brunck [mailto:holger.bru...@keymile.com]
 Sent: 02 November 2012 15:45
 To: u-boot@lists.denx.de
 Cc: Holger Brunck; Valentin Longchamp; Prafulla Wadaskar
 Subject: [PATCH 2/4] km/common: drop unneeded std* environment
 variables
 
 These variables are only used if CONFIG_SYS_CONSOLE_IS_IN_ENV
 is set. This isn't the case, so we can drop them safely.
 
 Signed-off-by: Holger Brunck holger.bru...@keymile.com
 cc: Valentin Longchamp valentin.longch...@keymile.com
 cc: Prafulla Wadaskar prafu...@marvell.com
 ---
  include/configs/km/keymile-common.h |3 ---
  1 files changed, 0 insertions(+), 3 deletions(-)
 
 diff --git a/include/configs/km/keymile-common.h
 b/include/configs/km/keymile-common.h
 index 05480d4..f64748e 100644
 --- a/include/configs/km/keymile-common.h
 +++ b/include/configs/km/keymile-common.h
 @@ -253,9 +253,6 @@
   load=tftpboot ${load_addr_r} ${u-boot}\0  \
   mtdids= MTDIDS_DEFAULT \0   \
   mtdparts= MTDPARTS_DEFAULT \0   \
 - stderr=serial\0   \
 - stdin=serial\0\
 - stdout=serial\0   \
   
  #endif /* CONFIG_KM_DEF_ENV */
 
 --
 1.7.1

Applied to u-boot-marvell.git master branch

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

Re: [U-Boot] [PATCH 4/4] arm/km: remove duplicate code

[Prafulla Wadaskar]

 -Original Message-
 From: Holger Brunck [mailto:holger.bru...@keymile.com]
 Sent: 02 November 2012 15:45
 To: u-boot@lists.denx.de
 Cc: Valentin Longchamp; Holger Brunck; Prafulla Wadaskar
 Subject: [PATCH 4/4] arm/km: remove duplicate code
 
 From: Valentin Longchamp valentin.longch...@keymile.com
 
 This patch removes 2 small portions of board specific code that are
 duplicated with common ARM code and thus unnecessary. These 2 portions
 of code concern the mach id that is given by u-boot to the Linux
 kernel
 to identify the system's MACH.
 
 The first one was the possibility to change the MACH thanks to the
 'mach_id' enviroment variable. This is possible thanks to the 'machid'
 env variable (see arch/arm/lib/bootm.c:boot_jump_linux()).
 
 The seconde one is the setting of the bi_arch_number. This is already
 done in arch/arm/lib/board.c:board_init_f() since km_arm.h does
 #define
 CONFIG_MACH_TYPE.
 
 Signed-off-by: Valentin Longchamp valentin.longch...@keymile.com
 cc: Holger Brunck holger.bru...@keymile.com
 cc: Prafulla Wadaskar prafu...@marvell.com
 ---
  board/keymile/km_arm/km_arm.c |   14 --
  1 files changed, 0 insertions(+), 14 deletions(-)
 
 diff --git a/board/keymile/km_arm/km_arm.c
 b/board/keymile/km_arm/km_arm.c
 index 0c4dddc..262b8d2 100644
 --- a/board/keymile/km_arm/km_arm.c
 +++ b/board/keymile/km_arm/km_arm.c
 @@ -193,15 +193,6 @@ void set_bootcount_addr(void)
 
  int misc_init_r(void)
  {
 - char *str;
 - int mach_type;
 -
 - str = getenv(mach_type);
 - if (str != NULL) {
 - mach_type = simple_strtoul(str, NULL, 10);
 - printf(Overwriting MACH_TYPE with %d!!!\n, mach_type);
 - gd-bd-bi_arch_number = mach_type;
 - }
  #if defined(CONFIG_KM_MGCOGE3UN)
   char *wait_for_ne;
   wait_for_ne = getenv(waitforne);
 @@ -258,11 +249,6 @@ int board_early_init_f(void)
 
  int board_init(void)
  {
 - /*
 -  * arch number of board
 -  */
 - gd-bd-bi_arch_number = MACH_TYPE_KM_KIRKWOOD;
 -
   /* address of boot parameters */
   gd-bd-bi_boot_params = kw_sdram_bar(0) + 0x100;
 
 --
 1.7.1

Applied to u-boot-marvell.git master branch

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

Re: [U-Boot] [PATCH 3/4] km/common: cosmetic change reported from checkpatch

[Prafulla Wadaskar]

 -Original Message-
 From: Holger Brunck [mailto:holger.bru...@keymile.com]
 Sent: 02 November 2012 15:45
 To: u-boot@lists.denx.de
 Cc: Holger Brunck; Valentin Longchamp; Prafulla Wadaskar
 Subject: [PATCH 3/4] km/common: cosmetic change reported from
 checkpatch
 
 Signed-off-by: Holger Brunck holger.bru...@keymile.com
 cc: Valentin Longchamp valentin.longch...@keymile.com
 cc: Prafulla Wadaskar prafu...@marvell.com
 ---
  board/keymile/common/common.c |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)
 
 diff --git a/board/keymile/common/common.c
 b/board/keymile/common/common.c
 index a90f112..6f407b7 100644
 --- a/board/keymile/common/common.c
 +++ b/board/keymile/common/common.c
 @@ -121,7 +121,7 @@ int i2c_make_abort(void)
  {
 
  #if defined(CONFIG_HARD_I2C)  !defined(MACH_TYPE_KM_KIRKWOOD)
 - immap_t *immap = (immap_t *)CONFIG_SYS_IMMR ;
 + immap_t *immap = (immap_t *)CONFIG_SYS_IMMR;
   i2c8260_t *i2c  = (i2c8260_t *)immap-im_i2c;
 
   /*
 --
 1.7.1

Applied to u-boot-marvell.git master branch

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

Re: [U-Boot] [PATCH 1/4] Optimized nand_read_buf for kirkwood

[Prafulla Wadaskar]

 -Original Message-
 From: u-boot-boun...@lists.denx.de [mailto:u-boot-
 boun...@lists.denx.de] On Behalf Of Scott Wood
 Sent: 27 November 2012 05:09
 To: Phil Sutter
 Cc: u-boot@lists.denx.de; Nico Erfurth
 Subject: Re: [U-Boot] [PATCH 1/4] Optimized nand_read_buf for kirkwood
 
 On 11/26/2012 04:33:08 AM, Phil Sutter wrote:
  The basic idea is taken from the linux-kernel, but further
 optimized.
 
  First align the buffer to 8 bytes, then use ldrd/strd to read and
  store
  in 8 byte quantities, then do the final bytes.
 
  Tested using: 'date ; nand read.raw 0xE0 0x0 0x1 ; date'.
  Without this patch, NAND read of 132MB took 49s (~2.69MB/s). With
 this
  patch in place, reading the same amount of data was done in 27s
  (~4.89MB/s). So read performance is increased by ~80%!
 
  Signed-off-by: Nico Erfurth n...@erfurth.eu
  Tested-by: Phil Sutter phil.sut...@viprinet.com
  Cc: Prafulla Wadaskar prafu...@marvell.com
  ---
   drivers/mtd/nand/kirkwood_nand.c |   29
 +
   1 files changed, 29 insertions(+), 0 deletions(-)
 
  diff --git a/drivers/mtd/nand/kirkwood_nand.c
  b/drivers/mtd/nand/kirkwood_nand.c
  index bdab5aa..e04a59f 100644
  --- a/drivers/mtd/nand/kirkwood_nand.c
  +++ b/drivers/mtd/nand/kirkwood_nand.c
  @@ -38,6 +38,34 @@ struct kwnandf_registers {
   static struct kwnandf_registers *nf_reg =
  (struct kwnandf_registers *)KW_NANDF_BASE;
 
  +
  +/* The basic idea is stolen from the linux kernel, but the inner
  loop is optimized a bit more */
  +static void kw_nand_read_buf(struct mtd_info *mtd, uint8_t *buf,
 int
  len)
  +{
  +   struct nand_chip *chip = mtd-priv;
  +
  +   while (len  (unsigned long)buf  7)
  +   {
 
 Brace goes on the previous line.
 
  +   *buf++ = readb(chip-IO_ADDR_R);
  +   len--;
  +   };
  +
  +   asm volatile (
  +   .LFlashLoop:\n
  + subs\t%0, #8\n
  + ldrpld\tr2, [%2]\n // Read 2 words
  + strpld\tr2, [%1], #8\n // Read 2 words
  + bpl\t.LFlashLoop\n // This results in one
  additional loop if len%8  0
  + addne\t%0, #8\n
  +   : +r (len), +r (buf)
  +   : r (chip-IO_ADDR_R)
  +   : r2, r3, memory, cc
  +   );
 
 Use a real tab (or a space) rather than \t (which only helps
 readability in the asm output, rather than the C source that people
 actually look at).
 
 Should probably use a numeric label to avoid any possibility of
 conflict.
 
 Would this make more sense as a more generic optimized memcpy_fromio()
 or similar?

Hi Phil

For your next post of this patch, please do not forget to add version info and 
changlog to the patch.

Regards...
Prafulla . . .
 
 
 -Scott
 ___
 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 v5 0/3] Add support for the LaCie Wireless Space

[Prafulla Wadaskar]

 -Original Message-
 From: Albert ARIBAUD [mailto:albert.u.b...@aribaud.net]
 Sent: 27 November 2012 02:58
 To: U-Boot
 Cc: Prafulla Wadaskar; Simon Guinot; Albert ARIBAUD
 Subject: [PATCH v5 0/3] Add support for the LaCie Wireless Space
 
 This series adds support to the LaCie Wireless Space,
 a Marvell Kirkwood-based product featuring USB, SATA,
 Ethernet and an integrated mv88e6161 Ethernet switch.
 
 Note 1: up to v4, this series had changes to mvgbe
 for supporting non-sequential PHY addresses on egiga0
 and egiga1. This proved unneeded for switch support,
 and was dropped in v5.
 
 Note 2: up to v3, this series made the Wireless Space
 a variant of the Net Space V2. Starting from v4, the
 Wireless Space is not based on Net Space V2 any more
 and the changes to Net Space V2 related code have been
 dropped.
 
 Changes in v5:
 - Fixes to the initialization sequence
 - Added a configurable read/write command
 - made fan, usb, HDD powered on at boot
 - fixed NAND env and Ethernet configs
 - general ws command with support for buttons
 - made netconsole accessible before boot delay
 
 Changes in v4:
 - switched from netspace_V2-based to standalone board
 - added support for mv88e61xx switch
 - corrected some kwbimage.cfg values
 
 Changes in v3:
 - fix broken support for NETSPACE_(MINI|LITE)_V2
 
 Changes in v2:
 - split the patch in two: mvgbe phy/port changes and WS support.
 - removed spurious DEBUG define
 - fixed various checkpatch errors/warnings/typos
 
 Albert ARIBAUD (3):
   mv88e61xx: refactor PHY and SWITCH level-code
   kirkwood: make MPP arrays static const
   ARM: lacie_kw: add support for WIRELESS_SPACE
 
  arch/arm/cpu/arm926ejs/kirkwood/mpp.c   |2 +-
  arch/arm/include/asm/arch-kirkwood/mpp.h|2 +-
  board/LaCie/net2big_v2/net2big_v2.c |2 +-
  board/LaCie/netspace_v2/netspace_v2.c   |2 +-
  board/LaCie/wireless_space/Makefile |   46 +++
  board/LaCie/wireless_space/kwbimage.cfg |   82 
  board/LaCie/wireless_space/wireless_space.c |  176 
  board/Marvell/dreamplug/dreamplug.c |2 +-
  board/Marvell/guruplug/guruplug.c   |2 +-
  board/Marvell/mv88f6281gtw_ge/mv88f6281gtw_ge.c |2 +-
  board/Marvell/openrd/openrd.c   |2 +-
  board/Marvell/rd6281a/rd6281a.c |2 +-
  board/Marvell/sheevaplug/sheevaplug.c   |2 +-
  board/Seagate/dockstar/dockstar.c   |2 +-
  board/buffalo/lsxl/lsxl.c   |2 +-
  board/cloudengines/pogo_e02/pogo_e02.c  |2 +-
  board/d-link/dns325/dns325.c|2 +-
  board/iomega/iconnect/iconnect.c|2 +-
  board/karo/tk71/tk71.c  |2 +-
  board/keymile/km_arm/km_arm.c   |2 +-
  board/raidsonic/ib62x0/ib62x0.c |2 +-
  boards.cfg  |1 +
  drivers/net/phy/mv88e61xx.c |  495
 ++-
  drivers/net/phy/mv88e61xx.h |   39 +-
  drivers/spi/kirkwood_spi.c  |   12 +-
  include/configs/wireless_space.h|  194 +
  include/netdev.h|   21 +-
  27 files changed, 880 insertions(+), 222 deletions(-)
  create mode 100644 board/LaCie/wireless_space/Makefile
  create mode 100644 board/LaCie/wireless_space/kwbimage.cfg
  create mode 100644 board/LaCie/wireless_space/wireless_space.c
  create mode 100644 include/configs/wireless_space.h
 
 --
 1.7.10.4

Applied this patch series to u-boot-marvell.git master branch

Regards...
Prafulla . . .

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

[U-Boot] Pull request for u-boot-marvell.git

[Prafulla Wadaskar]

Dear Albert,

Please pull
The following changes since commit b8a7c467960ffb4d5a5e1eef5f7783fb6f594542:
  Albert ARIBAUD (1):
Merge branch 'u-boot-imx/master' into 'u-boot-arm/master'

are available in the git repository at:

  u-boot-marvell.git master branch.

Albert ARIBAUD (3):
  mv88e61xx: refactor PHY and SWITCH level-code
  kirkwood: make MPP arrays static const
  ARM: lacie_kw: add support for WIRELESS_SPACE

Holger Brunck (3):
  arm/km: fix memory settings
  km/common: drop unneeded std* environment variables
  km/common: cosmetic change reported from checkpatch

Valentin Longchamp (1):
  arm/km: remove duplicate code

 arch/arm/cpu/arm926ejs/kirkwood/mpp.c   |2 +-
 arch/arm/include/asm/arch-kirkwood/mpp.h|2 +-
 board/LaCie/net2big_v2/net2big_v2.c |2 +-
 board/LaCie/netspace_v2/netspace_v2.c   |2 +-
 board/LaCie/wireless_space/Makefile |   46 +++
 board/LaCie/wireless_space/kwbimage.cfg |   82 
 board/LaCie/wireless_space/wireless_space.c |  176 
 board/Marvell/dreamplug/dreamplug.c |2 +-
 board/Marvell/guruplug/guruplug.c   |2 +-
 board/Marvell/mv88f6281gtw_ge/mv88f6281gtw_ge.c |2 +-
 board/Marvell/openrd/openrd.c   |2 +-
 board/Marvell/rd6281a/rd6281a.c |2 +-
 board/Marvell/sheevaplug/sheevaplug.c   |2 +-
 board/Seagate/dockstar/dockstar.c   |2 +-
 board/buffalo/lsxl/lsxl.c   |2 +-
 board/cloudengines/pogo_e02/pogo_e02.c  |2 +-
 board/d-link/dns325/dns325.c|2 +-
 board/iomega/iconnect/iconnect.c|2 +-
 board/karo/tk71/tk71.c  |2 +-
 board/keymile/common/common.c   |2 +-
 board/keymile/km_arm/km_arm.c   |   16 +-
 board/keymile/km_arm/kwbimage-memphis.cfg   |6 +-
 board/keymile/km_arm/kwbimage.cfg   |6 +-
 board/keymile/km_arm/kwbimage_128M16_1.cfg  |   25 +-
 board/keymile/km_arm/kwbimage_256M8_1.cfg   |   25 +-
 board/raidsonic/ib62x0/ib62x0.c |2 +-
 boards.cfg  |1 +
 drivers/net/phy/mv88e61xx.c |  495 ++
 drivers/net/phy/mv88e61xx.h |   39 ++-
 drivers/spi/kirkwood_spi.c  |   12 +-
 include/configs/km/keymile-common.h |3 -
 include/configs/wireless_space.h|  194 +
 include/netdev.h|   21 +-
 33 files changed, 891 insertions(+), 292 deletions(-)
 create mode 100644 board/LaCie/wireless_space/Makefile
 create mode 100644 board/LaCie/wireless_space/kwbimage.cfg
 create mode 100644 board/LaCie/wireless_space/wireless_space.c
 create mode 100644 include/configs/wireless_space.h

Regards...
Prafulla . . .

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

Re: [U-Boot] [U-Boot, v2 1/6] cmd_sf: Add print messages on flash erase command

[Jagan Teki]

Hi Wolfgang Denk,

On Thu, Dec 20, 2012 at 4:46 AM, Wolfgang Denk w...@denx.de wrote:
 Dear Jagannadha Sutradharudu Teki,

 In message 1355934463-24319-1-git-send-email-jagannadh.t...@gmail.com you 
 wrote:
 This patch adds a print messages while using 'sf erase' command
 to make sure that how many bytes erased in flash device.

 Signed-off-by: Jagannadha Sutradharudu Teki jagannadh.t...@gmail.com
 ---
 Changes in v2:
   Move print messages from spi_flash.c into cmd_sf.c

 This makes little sense to me.  Please see all comments here:

 http://article.gmane.org/gmane.comp.boot-loaders.u-boot/149663

 and here:

 http://article.gmane.org/gmane.comp.boot-loaders.u-boot/149665

I thought these are useful verbose prints for sf read/write/erase commands as
there is no verbose support before.

Like NOR, NAND and SD have some verbose prints while executing respective
commands
This is the only way to know the user whether these commands are
- executed properly
- what is the status after executing (success/fail, how many bytes
read/write/erase. etc)

Due to the above reasons I have added these verbose support.

Apart from this sometimes (very rare) due to the slowness of UART or SPI flash
even if we run the sf commands it will not execute the actual code
just terminate with showing
u-boot prompt, so the user assumes that this command is happen
properly. [but actually command is not done]

I thought these verbose prints will help such wild scenarios.

Correct me if am wrong with my thinking.

Thanks,
Jagan.




 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
 Programmer's Lament: (Shakespeare, Macbeth, Act I, Scene vii)
 That we but teach bloody instructions,
 which, being taught, return to plague the inventor...
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot, v2 2/6] cmd_sf: Add print messages on flash read/write commands

[Jagan Teki]

Hi Wolfgang Denk,

On Thu, Dec 20, 2012 at 4:48 AM, Wolfgang Denk w...@denx.de wrote:
 Dear Jagannadha Sutradharudu Teki,

 In message 1355934463-24319-2-git-send-email-jagannadh.t...@gmail.com you 
 wrote:
 This patch adds a print messages while using 'sf read' and
 'sf write' commands to make sure that how many bytes read/written
 from/into flash device.

 Signed-off-by: Jagannadha Sutradharudu Teki jagannadh.t...@gmail.com
 ---
 Changes in v2:
 Move print messages from spi_flash.c into cmd_sf.c

 Please see previous comments, especially

 http://article.gmane.org/gmane.comp.boot-loaders.u-boot/149663
 http://article.gmane.org/gmane.comp.boot-loaders.u-boot/149665

 I object against adding more and more verbosity and code size, and in
 an inconsistent way.

Please see my comments on previous patch.
http://article.gmane.org/gmane.comp.boot-loaders.u-boot/149698

Thanks,
Jagan.


 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
 F u cn rd ths u cnt spl wrth a dm!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v3 1/2] EXYNOS4: Add pinmux support for UART

[Jeong-Hyeon Kim]

This patch adds pinmux support for UART channels

Signed-off-by: Jeong-Hyeon Kim jh...@insignal.co.kr
---
 arch/arm/cpu/armv7/exynos/pinmux.c |   41 
 1 file changed, 41 insertions(+)

diff --git a/arch/arm/cpu/armv7/exynos/pinmux.c 
b/arch/arm/cpu/armv7/exynos/pinmux.c
index f02f441..364ee2a 100644
--- a/arch/arm/cpu/armv7/exynos/pinmux.c
+++ b/arch/arm/cpu/armv7/exynos/pinmux.c
@@ -366,6 +366,41 @@ static int exynos4_mmc_config(int peripheral, int flags)
return 0;
 }
 
+static void exynos4_uart_config(int peripheral)
+{
+   struct exynos4_gpio_part1 *gpio1 =
+   (struct exynos4_gpio_part1 *) samsung_get_base_gpio_part1();
+   struct s5p_gpio_bank *bank;
+   int i, start, count;
+
+   switch (peripheral) {
+   case PERIPH_ID_UART0:
+   bank = gpio1-a0;
+   start = 0;
+   count = 4;
+   break;
+   case PERIPH_ID_UART1:
+   bank = gpio1-a0;
+   start = 4;
+   count = 4;
+   break;
+   case PERIPH_ID_UART2:
+   bank = gpio1-a1;
+   start = 0;
+   count = 4;
+   break;
+   case PERIPH_ID_UART3:
+   bank = gpio1-a1;
+   start = 4;
+   count = 2;
+   break;
+   }
+   for (i = start; i  start + count; i++) {
+   s5p_gpio_set_pull(bank, i, GPIO_PULL_NONE);
+   s5p_gpio_cfg_pin(bank, i, GPIO_FUNC(0x2));
+   }
+}
+
 static int exynos4_pinmux_config(int peripheral, int flags)
 {
switch (peripheral) {
@@ -377,6 +412,12 @@ static int exynos4_pinmux_config(int peripheral, int flags)
case PERIPH_ID_SDMMC4:
printf(SDMMC device %d not implemented\n, peripheral);
return -1;
+   case PERIPH_ID_UART0:
+   case PERIPH_ID_UART1:
+   case PERIPH_ID_UART2:
+   case PERIPH_ID_UART3:
+   exynos4_uart_config(peripheral);
+   break;
default:
debug(%s: invalid peripheral %d, __func__, peripheral);
return -1;
-- 
1.7.9.5

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

[U-Boot] [PATCH v3 2/2] EXYNOS4: Add ORIGEN_QUAD board support

[Jeong-Hyeon Kim]

ORIGEN_QUAD board is based on Samsung's Exynos4412 SoC.

Signed-off-by: Jeong-Hyeon Kim jh...@insignal.co.kr
---
 MAINTAINERS   |4 +
 Makefile  |2 +-
 board/samsung/origen_quad/Makefile|   59 
 board/samsung/origen_quad/boot.c  |   77 +
 board/samsung/origen_quad/clock.c |  117 +++
 board/samsung/origen_quad/dmc.c   |  121 
 board/samsung/origen_quad/lowlevel_init.S |  150 +
 board/samsung/origen_quad/origen_quad.c   |  167 ++
 board/samsung/origen_quad/setup.h |  476 +
 boards.cfg|1 +
 include/configs/origen_quad.h |  188 
 tools/Makefile|2 +
 12 files changed, 1363 insertions(+), 1 deletion(-)
 create mode 100644 board/samsung/origen_quad/Makefile
 create mode 100644 board/samsung/origen_quad/boot.c
 create mode 100644 board/samsung/origen_quad/clock.c
 create mode 100644 board/samsung/origen_quad/dmc.c
 create mode 100644 board/samsung/origen_quad/lowlevel_init.S
 create mode 100644 board/samsung/origen_quad/origen_quad.c
 create mode 100644 board/samsung/origen_quad/setup.h
 create mode 100644 include/configs/origen_quad.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 36b47b7..ce6cdc9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -736,6 +736,10 @@ Lukasz Majewski l.majew...@samsung.com
 
trats   ARM ARMV7 (EXYNOS4210 SoC)
 
+Jeong-Hyeon Kim jh...@insignal.co.kr
+
+   origen_quad ARM ARMV7 (EXYNOS4412 SoC)
+
 Torsten Koschorrek koschor...@synertronixx.de
scb9328 ARM920T (i.MXL)
 
diff --git a/Makefile b/Makefile
index 44db889..c69f740 100644
--- a/Makefile
+++ b/Makefile
@@ -823,7 +823,7 @@ clean:
   $(obj)tools/gdb/{astest,gdbcont,gdbsend}   \
   $(obj)tools/gen_eth_addr$(obj)tools/img2srec   \
   $(obj)tools/mk{env,}image   $(obj)tools/mpc86x_clk \
-  $(obj)tools/mk{smdk5250,}spl   \
+  $(obj)tools/mk{$(SOC),$(BOARD),}spl\
   $(obj)tools/mxsboot\
   $(obj)tools/ncb $(obj)tools/ubsha1 \
   $(obj)tools/kernel-doc/docproc
diff --git a/board/samsung/origen_quad/Makefile 
b/board/samsung/origen_quad/Makefile
new file mode 100644
index 000..c24c921
--- /dev/null
+++ b/board/samsung/origen_quad/Makefile
@@ -0,0 +1,59 @@
+#
+# Copyright (C) 2012 Samsung Electronics
+#
+# Copyright (C) 2012 Insignal
+#
+# Makefile for the Insignal OrigenQUAD board (Exynos4x12)
+#
+# 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 $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(BOARD).o
+
+SOBJS  := lowlevel_init.o
+
+COBJS  := clock.o
+COBJS  += dmc.o
+
+ifndef CONFIG_SPL_BUILD
+COBJS  += origen_quad.o
+else
+COBJS  += boot.o
+endif
+
+SRCS   := $(SOBJS:.o=.S) $(COBJS:.o=.c)
+OBJS   := $(addprefix $(obj),$(COBJS) $(SOBJS))
+
+ALL:= $(obj).depend $(LIB)
+
+all:   $(ALL)
+
+$(LIB):$(OBJS)
+   $(call cmd_link_o_target, $(OBJS))
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
\ No newline at end of file
diff --git a/board/samsung/origen_quad/boot.c b/board/samsung/origen_quad/boot.c
new file mode 100644
index 000..0b67c3b
--- /dev/null
+++ b/board/samsung/origen_quad/boot.c
@@ -0,0 +1,77 @@
+/*
+ * Copyright (C) 2012 Samsung Electronics
+ *
+ * Copyright (C) 2012 Insignal
+ *
+ * Board initialize for the Insignal OrigenQUAD board (Exynos4x12)
+ *
+ * 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