Re: [U-Boot] [PATCH] Add README for the Falcon mode

2013-02-12 Thread Stefano Babic
On 11/02/2013 22:12, Otavio Salvador wrote:
 On Mon, Nov 12, 2012 at 8:59 AM, Stefano Babic sba...@denx.de wrote:
 Simple howto to add support to a board
 for booting the kernel from SPL (Falcon mode).

 Signed-off-by: Stefano Babic sba...@denx.de
 
 Could this be updated and resend? This is an interesting feature which
 lacks documentation currently.

Hi Otavio,

you are right, and thanks to point out that the documentation is not yet
merged. I will push a V5 as I promised with fixes for the last comments.

Regards,
Stefano


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


Re: [U-Boot] [PATCH] usb: ehci: exynos: Enable non-dt path

2013-02-12 Thread Minkyu Kang
Dear Vivek,

On 11/01/13 18:24, Vivek Gautam wrote:
 Enabling the non-dt path for the driver so that
 we don't get any build errors for non-dt configuration.
 
 Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
 ---
 
 Earlier we had moved to fdt support for ehci-exynos driver, but
 missed out the non-dt path. Although this driver serves for exysno5
 onward only but better to keep the non-dt path also available.
 
  drivers/usb/host/ehci-exynos.c |   10 ++
  1 files changed, 10 insertions(+), 0 deletions(-)
 
 diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c
 index 3ca4c5c..6f0c6c3 100644
 --- a/drivers/usb/host/ehci-exynos.c
 +++ b/drivers/usb/host/ehci-exynos.c
 @@ -153,7 +153,12 @@ int ehci_hcd_init(int index, struct ehci_hccr **hccr, 
 struct ehci_hcor **hcor)
   return -ENOMEM;
   }
  
 +#ifdef CONFIG_OF_CONTROL
   exynos_usb_parse_dt(gd-fdt_blob, exynos);
 +#else
 + exynos-usb = (struct exynos_usb_phy *)samsung_get_base_usb_phy();
 + exynos-hcd = samsung_get_base_usb_ehci();
 +#endif
  
   setup_usb_phy(exynos-usb);
  
 @@ -185,7 +190,12 @@ int ehci_hcd_stop(int index)
   return -ENOMEM;
   }
  
 +#ifdef CONFIG_OF_CONTROL
   exynos_usb_parse_dt(gd-fdt_blob, exynos);
 +#else
 + exynos-usb = (struct exynos_usb_phy *)samsung_get_base_usb_phy();
 + exynos-hcd = samsung_get_base_usb_ehci();
 +#endif
  
   reset_usb_phy(exynos-usb);
  
 

Patch looks good.
But I've got compiler warnings and errors when I disabled CONFIG_OF_CONTROL.

exynos_spi.c:391:12: warning: 'process_nodes' defined but not used 
[-Wunused-function]
ehci-exynos.c: In function 'ehci_hcd_init':
ehci-exynos.c:160:14: warning: assignment makes pointer from integer without a 
cast [enabled by default]
ehci-exynos.c: In function 'ehci_hcd_stop':
ehci-exynos.c:197:14: warning: assignment makes pointer from integer without a 
cast [enabled by default]
ehci-exynos.c: At top level:
ehci-exynos.c:48:12: warning: 'exynos_usb_parse_dt' defined but not used 
[-Wunused-function]
/opt/eldk-5.2/armv7a/sysroots/i686-eldk-linux/usr/bin/armv7a-vfp-neon-linux-gnueabi/arm-linux-gnueabi-ld.bfd:/home/share/Work/u-boot-samsung/spl/u-boot-spl.lds:1:
 ignoring invalid character `#' in expression
/opt/eldk-5.2/armv7a/sysroots/i686-eldk-linux/usr/bin/armv7a-vfp-neon-linux-gnueabi/arm-linux-gnueabi-ld.bfd:/home/share/Work/u-boot-samsung/spl/u-boot-spl.lds:1:
 syntax error
make[1]: *** [/home/share/Work/u-boot-samsung/spl/u-boot-spl] Error 1
make: *** [spl/u-boot-spl.bin] Error 2
make: *** Waiting for unfinished jobs
smdk5250.c: In function 'board_eth_init':
smdk5250.c:152:6: warning: unused variable 'node' [-Wunused-variable]

Could you please check this issue also?

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


[U-Boot] [PATCH v5 2/3] OMAP3: drop CONFIG_SPL_OS_BOOT_KEY and use local define

2013-02-12 Thread Stefano Babic
CONFIG_SPL_OS_BOOT_KEY is used only in board files. It is
not required to have a general CONFIG_ option. Rename it and
define it in board directory.

Signed-off-by: Stefano Babic sba...@denx.de
---
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

 board/technexion/twister/twister.c  |8 
 board/technexion/twister/twister.h  |2 ++
 board/timll/devkit8000/devkit8000.c |8 
 board/timll/devkit8000/devkit8000.h |3 +++
 include/configs/devkit8000.h|1 -
 include/configs/twister.h   |1 -
 6 files changed, 13 insertions(+), 10 deletions(-)

diff --git a/board/technexion/twister/twister.c 
b/board/technexion/twister/twister.c
index c9eea9b..fa0ace0 100644
--- a/board/technexion/twister/twister.c
+++ b/board/technexion/twister/twister.c
@@ -165,10 +165,10 @@ void spl_board_prepare_for_linux(void)
 int spl_start_uboot(void)
 {
int val = 0;
-   if (!gpio_request(CONFIG_SPL_OS_BOOT_KEY, U-Boot key)) {
-   gpio_direction_input(CONFIG_SPL_OS_BOOT_KEY);
-   val = gpio_get_value(CONFIG_SPL_OS_BOOT_KEY);
-   gpio_free(CONFIG_SPL_OS_BOOT_KEY);
+   if (!gpio_request(SPL_OS_BOOT_KEY, U-Boot key)) {
+   gpio_direction_input(SPL_OS_BOOT_KEY);
+   val = gpio_get_value(SPL_OS_BOOT_KEY);
+   gpio_free(SPL_OS_BOOT_KEY);
}
return val;
 }
diff --git a/board/technexion/twister/twister.h 
b/board/technexion/twister/twister.h
index a2051c0..cff479c 100644
--- a/board/technexion/twister/twister.h
+++ b/board/technexion/twister/twister.h
@@ -38,6 +38,8 @@ const omap3_sysinfo sysinfo = {
 #define XR16L2751_UART1_BASE   0x2100
 #define XR16L2751_UART2_BASE   0x2300
 
+/* GPIO used to select between U-Boot and kernel */
+#define SPL_OS_BOOT_KEY55
 
 /*
  * IEN  - Input Enable
diff --git a/board/timll/devkit8000/devkit8000.c 
b/board/timll/devkit8000/devkit8000.c
index 85685ee..b88d978 100644
--- a/board/timll/devkit8000/devkit8000.c
+++ b/board/timll/devkit8000/devkit8000.c
@@ -172,10 +172,10 @@ void spl_board_prepare_for_linux(void)
 int spl_start_uboot(void)
 {
int val = 0;
-   if (!gpio_request(CONFIG_SPL_OS_BOOT_KEY, U-Boot key)) {
-   gpio_direction_input(CONFIG_SPL_OS_BOOT_KEY);
-   val = gpio_get_value(CONFIG_SPL_OS_BOOT_KEY);
-   gpio_free(CONFIG_SPL_OS_BOOT_KEY);
+   if (!gpio_request(SPL_OS_BOOT_KEY, U-Boot key)) {
+   gpio_direction_input(SPL_OS_BOOT_KEY);
+   val = gpio_get_value(SPL_OS_BOOT_KEY);
+   gpio_free(SPL_OS_BOOT_KEY);
}
return !val;
 }
diff --git a/board/timll/devkit8000/devkit8000.h 
b/board/timll/devkit8000/devkit8000.h
index aa69e6c..c1965e2 100644
--- a/board/timll/devkit8000/devkit8000.h
+++ b/board/timll/devkit8000/devkit8000.h
@@ -32,6 +32,9 @@ const omap3_sysinfo sysinfo = {
NAND,
 };
 
+/* GPIO used to select between U-Boot and kernel */
+#define SPL_OS_BOOT_KEY26
+
 /*
  * IEN  - Input Enable
  * IDIS - Input Disable
diff --git a/include/configs/devkit8000.h b/include/configs/devkit8000.h
index d926f74..788227d 100644
--- a/include/configs/devkit8000.h
+++ b/include/configs/devkit8000.h
@@ -354,7 +354,6 @@
 
 /* SPL OS boot options */
 #define CONFIG_SPL_OS_BOOT
-#define CONFIG_SPL_OS_BOOT_KEY 26
 
 #define CONFIG_CMD_SPL
 #define CONFIG_CMD_SPL_WRITE_SIZE   0x400 /* 1024 byte */
diff --git a/include/configs/twister.h b/include/configs/twister.h
index a852481..4205a11 100644
--- a/include/configs/twister.h
+++ b/include/configs/twister.h
@@ -58,7 +58,6 @@
 #define CONFIG_CMD_SPL_NAND_OFS(CONFIG_SYS_NAND_SPL_KERNEL_OFFS+\
0x60)
 #define CONFIG_SPL_OS_BOOT
-#define CONFIG_SPL_OS_BOOT_KEY 55
 
 #define CONFIG_SYS_SPL_ARGS_ADDR   (PHYS_SDRAM_1 + 0x100)
 #define CONFIG_SPL_BOARD_INIT
-- 
1.7.9.5

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


[U-Boot] [PATCH v5 3/3] SPL: Change description for spl command

2013-02-12 Thread Stefano Babic
Add a more descriptive text to the help of the spl
command.

Signed-off-by: Stefano Babic sba...@denx.de
---
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

 common/cmd_spl.c |   12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/common/cmd_spl.c b/common/cmd_spl.c
index e3c543b..94b0a17 100644
--- a/common/cmd_spl.c
+++ b/common/cmd_spl.c
@@ -184,7 +184,11 @@ static int do_spl(cmd_tbl_t *cmdtp, int flag, int argc, 
char * const argv[])
 
 U_BOOT_CMD(
spl, 6 , 1, do_spl, SPL configuration,
-   export img=atags|fdt [kernel_addr] [initrd_addr] 
-   [fdt_addr if img = fdt] - export a kernel parameter image\n
-   \t initrd_img can be set to \-\ if fdt_addr without initrd img is
-   used);
+   export img=atags|fdt [kernel_addr] [initrd_addr] [fdt_addr]\n
+   \timg\t\t\atags\ or \fdt\\n
+   \tkernel_addr\taddress where a kernel image is stored.\n
+   \t\t\tkernel is loaded as part of the boot process, but it is not 
started.\n
+   \tinitrd_addr\taddress of initial ramdisk\n
+   \t\t\tcan be set to \-\ if fdt_addr without initrd_addr is used.\n
+   \tfdt_addr\tin case of fdt, the address of the device tree.\n
+   );
-- 
1.7.9.5

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


[U-Boot] [PATCH v5 1/3] Add README for the Falcon mode

2013-02-12 Thread Stefano Babic
Simple howto to add support to a board
for booting the kernel from SPL (Falcon mode).

Signed-off-by: Stefano Babic sba...@denx.de
---
Changes in v5:
- several fixes for the language, rephrasing some unclear parts (Vikram 
Narayanan)

Changes in v4:
- fix capitalization, styling, in spl help (Andreas Biessmann)
- move CONFIG_SPL_OS_BOOT before function in doc (Andreas Biessmann)

Changes in v3:
- parameter initrd_addr was removed in V2 (Andreas Biessmann)
- added patch to fix help usage for spl export (Andreas Biessmann)
- Added empty lines (Otavio Salvador)
- add a more exhaustive description explaining that
  spl export does not save into media (Lukasz Majewski).

Changes in v2:
- spelling, language fixes (Andreas Biessman)
- rewrite some unclear sentences
- drop CONFIG_SPL_OS_BOOT_KEY
- make example with twister more exhaustive

 doc/README.falcon |  169 +
 1 file changed, 169 insertions(+)
 create mode 100644 doc/README.falcon

diff --git a/doc/README.falcon b/doc/README.falcon
new file mode 100644
index 000..72fe04a
--- /dev/null
+++ b/doc/README.falcon
@@ -0,0 +1,169 @@
+U-Boot Falcon Mode
+
+
+Introduction
+
+
+This document provides an overview of how to add support for Falcon Mode
+to a board.
+Falcon Mode is introduced to speed up the booting process, allowing
+to boot a Linux kernel (or whatever image) without a full blown U-Boot.
+
+Falcon Mode relies on the SPL framework. In fact, to make booting faster,
+U-Boot is split into two parts: the SPL (Secondary Program Loader) and U-Boot
+image. In most implementations, SPL is used to start U-Boot when booting from
+a mass storage, such as NAND or SD-Card. SPL has now support for other media,
+and can generally be seen as a way to start an image performing the minimum
+required initialization. SPL mainly initializes the RAM controller, and then
+copies U-Boot image into the memory. The Falcon Mode extends this way
+allowing to start the Linux kernel directly from SPL. A new command is added
+to U-Boot to prepare the parameters that SPL must pass to the kernel, using
+ATAGS or Device Tree.
+
+In usual U-Boot systems, these parameters are generated each time before
+loading the kernel, passing to Linux the address in memory where
+the parameters can be read.
+With Falcon Mode, this snapshot can be saved into persistent storage and SPL is
+informed to load it before running the kernel.
+
+To boot the kernel, these steps under a Falcon-aware U-Boot are required:
+
+1. Boot the board into U-Boot.
+Use the spl export command to generate the kernel parameters area or the DT.
+U-Boot runs as when it boots the kernel, but stops before passing the control
+to the kernel.
+
+2. Save the prepared snapshot into persistent media.
+The address where to save it must be configured into board configuration
+file (CONFIG_CMD_SPL_NAND_OFS for NAND).
+
+3. Boot the board into Falcon Mode. SPL will load the kernel and copy
+the parameters which are saved in the persistent area area to the required 
address.
+
+It is required to implement a custom mechanism to select if SPL loads U-Boot
+or another image.
+
+The value of a GPIO is a simple way to operate the selection, as well as
+reading a character from the SPL console if CONFIG_SPL_CONSOLE is set.
+
+Falcon Mode is generally activated by setting CONFIG_SPL_OS_BOOT. This tells
+SPL that U-Boot is not the only available image that SPL is able to start.
+
+Configuration
+
+CONFIG_CMD_SPL Enable the spl export command.
+   The command spl export is then available in U-Boot
+   mode
+CONFIG_SYS_SPL_ARGS_ADDR   Address in RAM where the parameters must be
+   copied by SPL.
+   In most cases, it is start_of_ram + 0x100
+
+CONFIG_SYS_NAND_SPL_KERNEL_OFFSOffset in NAND where the kernel is 
stored
+
+CONFIG_CMD_SPL_NAND_OFSOffset in NAND where the parameters area was 
saved.
+
+CONFIG_CMD_SPL_WRITE_SIZE  Size of the parameters area to be copied
+
+CONFIG_SPL_OS_BOOT Activate Falcon Mode.
+
+Function that a board must implement
+
+
+void spl_board_prepare_for_linux(void) : optional
+   Called from SPL before starting the kernel
+
+spl_start_uboot() : required
+   Returns 0 if SPL starts the kernel, 1 if U-Boot
+   must be started.
+
+
+Using spl command
+-
+
+spl - SPL configuration
+
+Usage:
+
+spl export img=atags|fdt [kernel_addr] [initrd_addr] [fdt_addr ]
+
+img: atags or fdt
+kernel_addr: kernel is loaded as part of the boot process, but it is not 
started.
+ This is the address where a kernel image is stored.
+initrd_addr: Address of initial ramdisk
+ can be set to - if fdt_addr without initrd img is used
+fdt_addr   : in case of fdt, the address 

[U-Boot] [PATCH 1/2] tools: rename kwboot to mvboot

2013-02-12 Thread Luka Perkov
kwboot tool is used to boot Marvell Kirkwood SoCs over the serial link. Before
adding support for other Marvell SoCs, such as Dove or Armada, this patch
renames the tool so it's name makes more sense in the future.

Signed-off-by: Luka Perkov l...@openwrt.org
CC: Prafulla Wadaskar prafu...@marvell.com
CC: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
CC: Daniel Stodden daniel.stod...@gmail.com
---
 doc/kwboot.1 |  84 ---
 doc/mvboot.1 |  84 +++
 tools/.gitignore |   2 +-
 tools/Makefile   |   6 +-
 tools/kwboot.c   | 742 ---
 tools/mvboot.c   | 742 +++
 6 files changed, 830 insertions(+), 830 deletions(-)
 delete mode 100644 doc/kwboot.1
 create mode 100644 doc/mvboot.1
 delete mode 100644 tools/kwboot.c
 create mode 100644 tools/mvboot.c

diff --git a/doc/kwboot.1 b/doc/kwboot.1
deleted file mode 100644
index 25fe69a..000
--- a/doc/kwboot.1
+++ /dev/null
@@ -1,84 +0,0 @@
-.TH KWBOOT 1 2012-05-19
-
-.SH NAME
-kwboot \- Boot Marvell Kirkwood SoCs over a serial link.
-.SH SYNOPSIS
-.B kwboot
-.RB [ -b \fIimage\fP ]
-.RB [ -p ]
-.RB [ -t ]
-.RB [ -B \fIbaudrate\fP ]
-.RB \fITTY\fP
-.SH DESCRIPTION
-
-The \fBmkimage\fP program boots boards based on Marvell's Kirkwood
-platform over their integrated UART. Boot image files will typically
-contain a second stage boot loader, such as U-Boot. The image file
-must conform to Marvell's BootROM firmware image format
-(\fIkwbimage\fP), created using a tool such as \fBmkimage\fP.
-
-Following power-up or a system reset, system BootROM code polls the
-UART for a brief period of time, sensing a handshake message which
-initiates an image upload. This program sends this boot message until
-it receives a positive acknowledgement. The image is transfered using
-Xmodem.
-
-Additionally, this program implements a minimal terminal mode, which
-can be used either standalone, or entered immediately following boot
-image transfer completion. This is often useful to catch early boot
-messages, or to manually interrupt a default boot procedure performed
-by the second-stage loader.
-
-.SH OPTIONS
-
-.TP
-.BI \-b \fIimage\fP
-Handshake; then upload file \fIimage\fP over \fITTY\fP.
-
-Note that for the encapsulated boot code to be executed, \fIimage\fP
-must be of type UART boot (0x69). Boot images of different types,
-such as backup images of vendor firmware downloaded from flash memory
-(type 0x8B), will not work (or not as expected). See \fB-p\fP for a
-workaround.
-
-This mode writes handshake status and upload progress indication to
-stdout.
-
-.TP
-.BI \-p
-In combination with \fB-b\fP, patches the header in \fIimage\fP prior
-to upload, to UART boot type.
-
-This option attempts on-the-fly conversion of some none-UART image
-types, such as images which were originally formatted to be stored in
-flash memory.
-
-Conversion is performed in memory. The contents of \fIimage\fP will
-not be altered.
-
-.TP
-.BI \-t
-Run a terminal program, connecting standard input and output to
-.RB \fITTY\fP.
-
-If used in combination with \fB-b\fP, terminal mode is entered
-immediately following a successful image upload.
-
-If standard I/O streams connect to a console, this mode will terminate
-after receiving 'ctrl-\\' followed by 'c' from console input.
-
-.TP
-.BI \-B \fIbaudrate\fP
-Adjust the baud rate on \fITTY\fP. Default rate is 115200.
-
-.SH SEE ALSO
-.PP
-\fBmkimage\fP(1)
-
-.SH AUTHORS
-
-Daniel Stodden daniel.stod...@gmail.com
-.br
-Luka Perkov l...@openwrt.org
-.br
-David Purdy david.c.pu...@gmail.com
diff --git a/doc/mvboot.1 b/doc/mvboot.1
new file mode 100644
index 000..563d0e5
--- /dev/null
+++ b/doc/mvboot.1
@@ -0,0 +1,84 @@
+.TH MVBOOT 1 2012-05-19
+
+.SH NAME
+mvboot \- Boot Marvell Kirkwood SoCs over a serial link.
+.SH SYNOPSIS
+.B mvboot
+.RB [ -b \fIimage\fP ]
+.RB [ -p ]
+.RB [ -t ]
+.RB [ -B \fIbaudrate\fP ]
+.RB \fITTY\fP
+.SH DESCRIPTION
+
+The \fBmkimage\fP program boots boards based on Marvell's Kirkwood
+platform over their integrated UART. Boot image files will typically
+contain a second stage boot loader, such as U-Boot. The image file
+must conform to Marvell's BootROM firmware image format
+(\fIkwbimage\fP), created using a tool such as \fBmkimage\fP.
+
+Following power-up or a system reset, system BootROM code polls the
+UART for a brief period of time, sensing a handshake message which
+initiates an image upload. This program sends this boot message until
+it receives a positive acknowledgement. The image is transfered using
+Xmodem.
+
+Additionally, this program implements a minimal terminal mode, which
+can be used either standalone, or entered immediately following boot
+image transfer completion. This is often useful to catch early boot
+messages, or to manually interrupt a default boot procedure performed
+by the second-stage loader.
+
+.SH OPTIONS
+
+.TP
+.BI \-b \fIimage\fP
+Handshake; then upload file \fIimage\fP 

Re: [U-Boot] [PATCH 6/7 V3] EXYNOS5: Add initial DTS file for Snow.

2013-02-12 Thread Minkyu Kang
Dear Rajeshwari,

On 01/02/13 14:39, Rajeshwari Shinde wrote:
 This patch adds the DTS file for Snow Board.
 
 Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com
 ---
 Changes in V2:
   -None
 Changes in V3:
   - None
  board/samsung/dts/exynos5250-snow.dts |   69 
 +
  1 files changed, 69 insertions(+), 0 deletions(-)
  create mode 100644 board/samsung/dts/exynos5250-snow.dts
 

I think, patch 6 and 7 should be separated with another patch.

Thanks,
Minkyu Kang.

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


Re: [U-Boot] [PATCH 7/7 V3] EXYNOS5: Snow: Add a configuration file

2013-02-12 Thread Minkyu Kang
Dear Rajeshwari,

On 01/02/13 14:39, Rajeshwari Shinde wrote:
 This patch adds the configuration file for Snow Board and
 defines the same in boards.cfg.
 
 Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com
 ---
 Changes in V2:
   - None.
 Changes in V3:
   - Moved CONFIG_SOUND_MAX98095 to exynos5250-dt.h
  boards.cfg  |1 +
  include/configs/exynos5250-dt.h |1 +
  include/configs/snow.h  |   33 +
  3 files changed, 35 insertions(+), 0 deletions(-)
  create mode 100644 include/configs/snow.h
 
 diff --git a/boards.cfg b/boards.cfg
 index e4b0d44..f247b03 100644
 --- a/boards.cfg
 +++ b/boards.cfg
 @@ -283,6 +283,7 @@ s5p_goni arm armv7   goni 
samsung
  smdkc100 arm armv7   smdkc100
 samsungs5pc1xx
  origenarm armv7   origen 
  samsungexynos
  s5pc210_universalarm armv7   universal_c210  
 samsungexynos
 +snow  arm armv7   smdk5250
 samsungexynos
  smdk5250  arm armv7   smdk5250
 samsungexynos
  smdkv310  arm armv7   smdkv310
 samsungexynos
  tratsarm armv7   trats   
 samsungexynos
 diff --git a/include/configs/exynos5250-dt.h b/include/configs/exynos5250-dt.h
 index a01fb96..b1b24a9 100644
 --- a/include/configs/exynos5250-dt.h
 +++ b/include/configs/exynos5250-dt.h
 @@ -298,6 +298,7 @@
  #define CONFIG_SOUND
  #define CONFIG_I2S
  #define CONFIG_SOUND_WM8994
 +#define CONFIG_SOUND_MAX98095

unrelated change.

  #endif
  
  /* Enable devicetree support */
 diff --git a/include/configs/snow.h b/include/configs/snow.h
 new file mode 100644
 index 000..1dc491b
 --- /dev/null
 +++ b/include/configs/snow.h
 @@ -0,0 +1,33 @@
 +/*
 + * Copyright (C) 2013 Samsung Electronics
 + *
 + * Configuration settings for the SAMSUNG SMDK5250 board.
 + *
 + * 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
 + */
 +
 +#ifndef __CONFIG_SMDK_H
 +#define __CONFIG_SMDK_H
 +
 +#include configs/exynos5250-dt.h
 +
 +#undef CONFIG_DEFAULT_DEVICE_TREE
 +#define CONFIG_DEFAULT_DEVICE_TREE   exynos5250-snow
 +
 +#endif   /* __CONFIG_SMDK_H */
 

Thanks.
Minkyu Kang.

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


[U-Boot] [PATCH 2/2 v4] tools: add support for Dove to kwboot

2013-02-12 Thread Luka Perkov
From: Sebastian Hesselbarth sebastian.hesselba...@gmail.com

On Dove mvboot can also be used to boot an u-boot image into RAM.
In contrast to Kirkwood, Dove does not support the UART boot mode
sequence but requires the UART boot mode to be selected through
strap pins. The SolidRun CuBox has a push button to allow uart
boot mode but fails on the boot sequence sent by mvboot.

This patch adds another cmdline option to allow to send a boot
image without the boot sequence and adds support for Dove.

Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
Signed-off-by: Daniel Stodden daniel.stod...@gmail.com
Signed-off-by: Luka Perkov l...@openwrt.org
Cc: Prafulla Wadaskar prafu...@marvell.com
Cc: Rabeeh Khoury rab...@solid-run.com
---

changes from v1 to v2:

 * update documentation

changes from v2 to v3:

 * none

changes from v3 to v4:

 * move to separate patch series 
 * fix wrong flag in the man page
 * document Dove support in the header of mvboot.c

 doc/mvboot.1   | 13 ++---
 tools/Makefile |  2 ++
 tools/mvboot.c | 27 ---
 3 files changed, 32 insertions(+), 10 deletions(-)

diff --git a/doc/mvboot.1 b/doc/mvboot.1
index 563d0e5..0978351 100644
--- a/doc/mvboot.1
+++ b/doc/mvboot.1
@@ -1,17 +1,18 @@
-.TH MVBOOT 1 2012-05-19
+.TH MVBOOT 1 2013-02-12
 
 .SH NAME
-mvboot \- Boot Marvell Kirkwood SoCs over a serial link.
+mvboot \- Boot Marvell Kirkwood/Dove SoCs over a serial link.
 .SH SYNOPSIS
 .B mvboot
 .RB [ -b \fIimage\fP ]
+.RB [ -n ]
 .RB [ -p ]
 .RB [ -t ]
 .RB [ -B \fIbaudrate\fP ]
 .RB \fITTY\fP
 .SH DESCRIPTION
 
-The \fBmkimage\fP program boots boards based on Marvell's Kirkwood
+The \fBmkimage\fP program boots boards based on Marvell's Kirkwood/Dove
 platform over their integrated UART. Boot image files will typically
 contain a second stage boot loader, such as U-Boot. The image file
 must conform to Marvell's BootROM firmware image format
@@ -68,6 +69,12 @@ If standard I/O streams connect to a console, this mode will 
terminate
 after receiving 'ctrl-\\' followed by 'c' from console input.
 
 .TP
+.BI \-n
+Disables the UART boot mode sequence for platforms that do not support
+it (e.g. Dove). Usually, the UART boot mode must be selected by pressing
+a push button on power-up.
+
+.TP
 .BI \-B \fIbaudrate\fP
 Adjust the baud rate on \fITTY\fP. Default rate is 115200.
 
diff --git a/tools/Makefile b/tools/Makefile
index adfb643..db4def5 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -72,6 +72,7 @@ BIN_FILES-$(CONFIG_SMDK5250) += mksmdk5250spl$(SFX)
 BIN_FILES-$(CONFIG_MX28) += mxsboot$(SFX)
 BIN_FILES-$(CONFIG_NETCONSOLE) += ncb$(SFX)
 BIN_FILES-$(CONFIG_SHA1_CHECK_UB_IMG) += ubsha1$(SFX)
+BIN_FILES-$(CONFIG_DOVE) += mvboot$(SFX)
 BIN_FILES-$(CONFIG_KIRKWOOD) += mvboot$(SFX)
 
 # Source files which exist outside the tools directory
@@ -103,6 +104,7 @@ OBJ_FILES-$(CONFIG_NETCONSOLE) += ncb.o
 NOPED_OBJ_FILES-y += os_support.o
 OBJ_FILES-$(CONFIG_SHA1_CHECK_UB_IMG) += ubsha1.o
 NOPED_OBJ_FILES-y += ublimage.o
+OBJ_FILES-$(CONFIG_DOVE) += mvboot.o
 OBJ_FILES-$(CONFIG_KIRKWOOD) += mvboot.o
 
 # Don't build by default
diff --git a/tools/mvboot.c b/tools/mvboot.c
index 94fb0dd..ea12f58 100644
--- a/tools/mvboot.c
+++ b/tools/mvboot.c
@@ -1,5 +1,5 @@
 /*
- * Boot a Marvell Kirkwood SoC, with Xmodem over UART0.
+ * Boot a Marvell Kirkwood and Dove SoCs, with Xmodem over UART0.
  *
  * (c) 2012 Daniel Stodden daniel.stod...@gmail.com
  *
@@ -37,6 +37,10 @@ static unsigned char mvboot_msg_boot[] = {
0xBB, 0x11, 0x22, 0x33, 0x44, 0x55, 0x66, 0x77
 };
 
+static unsigned char mvboot_msg_none[] = {
+   0x00
+};
+
 #define MVBOOT_MSG_REQ_DELAY   10 /* ms */
 #define MVBOOT_MSG_RSP_TIMEO   50 /* ms */
 
@@ -268,17 +272,21 @@ mvboot_bootmsg(int tty, void *msg)
int rc;
char c;
 
-   mvboot_printv(Sending boot message. Please reboot the target...);
+   mvboot_printv(msg != mvboot_msg_none
+ ? Sending boot message. Please reboot the target...
+ : Sensing target. Please reboot target into UART mode...);
 
do {
rc = tcflush(tty, TCIOFLUSH);
if (rc)
break;
 
-   rc = mvboot_tty_send(tty, msg, 8);
-   if (rc) {
-   usleep(MVBOOT_MSG_REQ_DELAY * 1000);
-   continue;
+   if (msg != mvboot_msg_none) {
+   rc = mvboot_tty_send(tty, msg, 8);
+   if (rc) {
+   usleep(MVBOOT_MSG_REQ_DELAY * 1000);
+   continue;
+   }
}
 
rc = mvboot_tty_recv(tty, c, 1, MVBOOT_MSG_RSP_TIMEO);
@@ -607,6 +615,7 @@ mvboot_usage(FILE *stream, char *progname)
fprintf(stream,   -b image: boot image\n);
fprintf(stream,   -p: patch image to type 0x69 (uart boot)\n);
fprintf(stream, \n);
+   fprintf(stream,   -n: don't send boot 

[U-Boot] [PATCH v2 0/4] usb:gadget: USB Mass Storage Gadget

2013-02-12 Thread Piotr Wilczek
This patch series add support for the USB Mass Storage (UMS)
New ums command provide access to on-device persistent memory.

The storage_common.c and f_mass_storage.c source files are
ported from v2.6.36 Linux kernel

Changes in v2:
- removed commented code;

Lukasz Majewski (3):
  usb:composite: USB Mass Storage - storage_common.c from Linux kernel
  usb:gadget: USB Mass Storage Gadget support
  arm:trats: Use new ums command

Piotr Wilczek (1):
  usb:composite: USB Mass Storage - f_mass_storage.c from Linux kernel

 board/samsung/trats/trats.c |   63 +
 common/Makefile |1 +
 common/cmd_usb_mass_storage.c   |   86 ++
 drivers/usb/gadget/f_mass_storage.c | 2793 +++
 drivers/usb/gadget/g_dnl.c  |6 +
 drivers/usb/gadget/storage_common.c |  653 
 include/configs/trats.h |5 +
 include/usb_mass_storage.h  |   55 +
 8 files changed, 3662 insertions(+)
 create mode 100644 common/cmd_usb_mass_storage.c
 create mode 100644 drivers/usb/gadget/f_mass_storage.c
 create mode 100644 drivers/usb/gadget/storage_common.c
 create mode 100644 include/usb_mass_storage.h

-- 
1.7.9.5

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


[U-Boot] [PATCH v2 1/4] usb:composite: USB Mass Storage - storage_common.c from Linux kernel

2013-02-12 Thread Piotr Wilczek
From: Lukasz Majewski l.majew...@samsung.com

The storage_common.c source file from v2.6.36 Linux kernel.

commit d26a6aa08b9f12b44fb1ee65625e7480d3d5bb81
Author: Michal Nazarewicz m.nazarew...@samsung.com
Date:   Mon Nov 9 14:15:23 2009 +0100

USB: g_mass_storage: code cleaned up and comments updated

Signed-off-by: Lukasz Majewski l.majew...@samsung.com
Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
CC: Marek Vasut marek.va...@gmail.com
---
Changes in v2: None

 drivers/usb/gadget/storage_common.c |  653 +++
 1 file changed, 653 insertions(+)
 create mode 100644 drivers/usb/gadget/storage_common.c

diff --git a/drivers/usb/gadget/storage_common.c 
b/drivers/usb/gadget/storage_common.c
new file mode 100644
index 000..594dc10
--- /dev/null
+++ b/drivers/usb/gadget/storage_common.c
@@ -0,0 +1,653 @@
+/*
+ * storage_common.c -- Common definitions for mass storage functionality
+ *
+ * Copyright (C) 2003-2008 Alan Stern
+ * Copyeight (C) 2009 Samsung Electronics
+ * Author: Michal Nazarewicz (m.nazarew...@samsung.com)
+ *
+ * Ported to u-boot:
+ * Andrzej Pietrasiewicz andrze...@samsung.com
+ *
+ * Code refactoring  cleanup:
+ * Ɓukasz Majewski l.majew...@samsung.com
+ *
+ * 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
+ */
+
+
+/*
+ * This file requires the following identifiers used in USB strings to
+ * be defined (each of type pointer to char):
+ *  - fsg_string_manufacturer -- name of the manufacturer
+ *  - fsg_string_product  -- name of the product
+ *  - fsg_string_serial   -- product's serial
+ *  - fsg_string_config   -- name of the configuration
+ *  - fsg_string_interface-- name of the interface
+ * The first four are only needed when FSG_DESCRIPTORS_DEVICE_STRINGS
+ * macro is defined prior to including this file.
+ */
+
+/*
+ * When FSG_NO_INTR_EP is defined fsg_fs_intr_in_desc and
+ * fsg_hs_intr_in_desc objects as well as
+ * FSG_FS_FUNCTION_PRE_EP_ENTRIES and FSG_HS_FUNCTION_PRE_EP_ENTRIES
+ * macros are not defined.
+ *
+ * When FSG_NO_DEVICE_STRINGS is defined FSG_STRING_MANUFACTURER,
+ * FSG_STRING_PRODUCT, FSG_STRING_SERIAL and FSG_STRING_CONFIG are not
+ * defined (as well as corresponding entries in string tables are
+ * missing) and FSG_STRING_INTERFACE has value of zero.
+ *
+ * When FSG_NO_OTG is defined fsg_otg_desc won't be defined.
+ */
+
+/*
+ * When FSG_BUFFHD_STATIC_BUFFER is defined when this file is included
+ * the fsg_buffhd structure's buf field will be an array of FSG_BUFLEN
+ * characters rather then a pointer to void.
+ */
+
+
+/* #include asm/unaligned.h */
+
+
+/*
+ * Thanks to NetChip Technologies for donating this product ID.
+ *
+ * DO NOT REUSE THESE IDs with any other driver!!  Ever!!
+ * Instead:  allocate your own, using normal USB-IF procedures.
+ */
+#define FSG_VENDOR_ID  0x0525  /* NetChip */
+#define FSG_PRODUCT_ID 0xa4a5  /* Linux-USB File-backed Storage Gadget */
+
+/*-*/
+
+#ifndef DEBUG
+#undef VERBOSE_DEBUG
+#undef DUMP_MSGS
+#endif /* !DEBUG */
+
+#ifdef VERBOSE_DEBUG
+#define VLDBG  LDBG
+#else
+#define VLDBG(lun, fmt, args...) do { } while (0)
+#endif /* VERBOSE_DEBUG */
+
+/*
+#define LDBG(lun, fmt, args...)   dev_dbg ((lun)-dev, fmt, ## args)
+#define LERROR(lun, fmt, args...) dev_err ((lun)-dev, fmt, ## args)
+#define LWARN(lun, fmt, args...)  dev_warn((lun)-dev, fmt, ## args)
+#define LINFO(lun, fmt, args...)  dev_info((lun)-dev, fmt, ## args)
+*/
+
+#define LDBG(lun, fmt, args...) do { } while (0)
+#define LERROR(lun, fmt, args...) do { } while (0)
+#define LWARN(lun, fmt, args...) do { } while (0)
+#define LINFO(lun, fmt, args...) do { } while (0)
+
+/*
+ * Keep those macros in sync with those in
+ * include/linux/usb/composite.h or else GCC will complain.  If they
+ * are identical (the same names of arguments, white spaces in the
+ * same places) GCC will allow redefinition otherwise (even if some
+ * white space is removed or added) warning will be issued.
+ *
+ * Those macros are needed here because File Storage Gadget does not
+ * include the composite.h header.  For composite gadgets those macros
+ * are redundant since composite.h is included any way.
+ *
+ * One could check whether 

[U-Boot] [PATCH v2 3/4] usb:gadget: USB Mass Storage Gadget support

2013-02-12 Thread Piotr Wilczek
From: Lukasz Majewski l.majew...@samsung.com

This patch adds the USB Mass Storage Gadget to u-boot
New command called ums is implemented to provide access
to on-device embedded persistent memory.

USB Mass Storage is supposed to work on top of the USB
Gadget framework

Signed-off-by: Lukasz Majewski l.majew...@samsung.com
Signed-off-by: Piotr Wilczek p.wilc...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
CC: Marek Vasut marek.va...@gmail.com
---
Changes in v2: None

 common/Makefile   |1 +
 common/cmd_usb_mass_storage.c |   86 +
 drivers/usb/gadget/g_dnl.c|6 +++
 include/usb_mass_storage.h|   55 ++
 4 files changed, 148 insertions(+)
 create mode 100644 common/cmd_usb_mass_storage.c
 create mode 100644 include/usb_mass_storage.h

diff --git a/common/Makefile b/common/Makefile
index 54fcc81..8ec95d2 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -174,6 +174,7 @@ COBJS-y += cmd_usb.o
 COBJS-y += usb.o usb_hub.o
 COBJS-$(CONFIG_USB_STORAGE) += usb_storage.o
 endif
+COBJS-$(CONFIG_CMD_USB_MASS_STORAGE) += cmd_usb_mass_storage.o
 COBJS-$(CONFIG_CMD_XIMG) += cmd_ximg.o
 COBJS-$(CONFIG_YAFFS2) += cmd_yaffs2.o
 COBJS-$(CONFIG_CMD_SPL) += cmd_spl.o
diff --git a/common/cmd_usb_mass_storage.c b/common/cmd_usb_mass_storage.c
new file mode 100644
index 000..87a5f2f
--- /dev/null
+++ b/common/cmd_usb_mass_storage.c
@@ -0,0 +1,86 @@
+/*
+ * Copyright (C) 2011 Samsung Electronics
+ * Lukasz Majewski l.majew...@samsung.com
+ *
+ * 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 errno.h
+#include common.h
+#include command.h
+#include g_dnl.h
+#include usb_mass_storage.h
+
+int do_usb_mass_storage(cmd_tbl_t *cmdtp, int flag,
+  int argc, char * const argv[])
+{
+   char *ep;
+   unsigned int dev_num = 0, offset = 0, part_size = 0;
+   int rc;
+
+   struct ums_board_info *ums_info;
+   static char *s = ums;
+
+   if (argc  2) {
+   printf(usage: ums dev - e.g. ums 0\n);
+   return 0;
+   }
+
+   dev_num = (int)simple_strtoul(argv[1], ep, 16);
+
+   if (dev_num) {
+   puts(\nSet eMMC device to 0! - e.g. ums 0\n);
+   goto fail;
+   }
+
+   board_usb_init();
+   ums_info = board_ums_init(dev_num, offset, part_size);
+
+   if (!ums_info) {
+   printf(MMC: %d - NOT available\n, dev_num);
+   goto fail;
+   }
+   rc = fsg_init(ums_info);
+   if (rc) {
+   printf(cmd ums: fsg_init failed\n);
+   goto fail;
+   }
+
+   g_dnl_register(s);
+
+   while (1) {
+   /* Handle control-c and timeouts */
+   if (ctrlc()) {
+   printf(The remote end did not respond in time.\n);
+   goto exit;
+   }
+   usb_gadget_handle_interrupts();
+   /* Check if USB cable has been detached */
+   if (fsg_main_thread(NULL) == EIO)
+   goto exit;
+   }
+exit:
+   g_dnl_unregister();
+   return 0;
+
+fail:
+   return -1;
+}
+
+U_BOOT_CMD(ums, CONFIG_SYS_MAXARGS, 1, do_usb_mass_storage,
+   Use the UMS [User Mass Storage],
+   ums - User Mass Storage Gadget
+);
diff --git a/drivers/usb/gadget/g_dnl.c b/drivers/usb/gadget/g_dnl.c
index a5a4c1f..cc3f344 100644
--- a/drivers/usb/gadget/g_dnl.c
+++ b/drivers/usb/gadget/g_dnl.c
@@ -31,6 +31,7 @@
 
 #include gadget_chips.h
 #include composite.c
+#include f_mass_storage.c
 
 /*
  * One needs to define the following:
@@ -104,6 +105,8 @@ static int g_dnl_do_config(struct usb_configuration *c)
printf(GADGET DRIVER: %s\n, s);
if (!strcmp(s, usb_dnl_dfu))
ret = dfu_add(c);
+   else if (!strcmp(s, usb_dnl_ums))
+   ret = fsg_add(c);
 
return ret;
 }
@@ -188,6 +191,9 @@ int g_dnl_register(const char *type)
if (!strcmp(type, dfu)) {
strcpy(name, shortname);
strcat(name, type);
+   } else if (!strcmp(type, ums)) {
+   strcpy(name, shortname);
+   strcat(name, type);
} else {
printf(%s: unknown command: %s\n, __func__, type);
  

[U-Boot] [PATCH v2 4/4] arm:trats: Use new ums command

2013-02-12 Thread Piotr Wilczek
From: Lukasz Majewski l.majew...@samsung.com

This patch enables new ums command on Trats board

Signed-off-by: Lukasz Majewski l.majew...@samsung.com
Signed-off-by: Piotr Wilczek p.wilc...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
CC: Minkyu Kang mk7.k...@samsung.com
---
Changes in v2: None

 board/samsung/trats/trats.c |   63 +++
 include/configs/trats.h |5 
 2 files changed, 68 insertions(+)

diff --git a/board/samsung/trats/trats.c b/board/samsung/trats/trats.c
index 88d193d..9207646 100644
--- a/board/samsung/trats/trats.c
+++ b/board/samsung/trats/trats.c
@@ -42,6 +42,7 @@
 #include power/max8997_muic.h
 #include power/battery.h
 #include power/max17042_fg.h
+#include usb_mass_storage.h
 
 #include setup.h
 
@@ -791,3 +792,65 @@ void init_panel_info(vidinfo_t *vid)
 
setenv(lcdinfo, lcd=s6e8ax0);
 }
+
+#ifdef CONFIG_USB_GADGET_MASS_STORAGE
+static int ums_read_sector(struct ums_device *ums_dev,
+  ulong start, lbaint_t blkcnt, void *buf)
+{
+   if (ums_dev-mmc-block_dev.block_read(ums_dev-dev_num,
+   start + ums_dev-offset, blkcnt, buf) != blkcnt)
+   return -1;
+
+   return 0;
+}
+
+static int ums_write_sector(struct ums_device *ums_dev,
+   ulong start, lbaint_t blkcnt, const void *buf)
+{
+   if (ums_dev-mmc-block_dev.block_write(ums_dev-dev_num,
+   start + ums_dev-offset, blkcnt, buf) != blkcnt)
+   return -1;
+
+   return 0;
+}
+
+static void ums_get_capacity(struct ums_device *ums_dev,
+long long int *capacity)
+{
+   long long int tmp_capacity;
+
+   tmp_capacity = (long long int) ((ums_dev-offset + ums_dev-part_size)
+   * SECTOR_SIZE);
+   *capacity = ums_dev-mmc-capacity - tmp_capacity;
+}
+
+static struct ums_board_info ums_board = {
+   .read_sector = ums_read_sector,
+   .write_sector = ums_write_sector,
+   .get_capacity = ums_get_capacity,
+   .name = TRATS UMS disk,
+   .ums_dev = {
+   .mmc = NULL,
+   .dev_num = 0,
+   .offset = 0,
+   .part_size = 0.
+   },
+};
+
+struct ums_board_info *board_ums_init(unsigned int dev_num, unsigned int 
offset,
+ unsigned int part_size)
+{
+   struct mmc *mmc;
+
+   mmc = find_mmc_device(dev_num);
+   if (!mmc)
+   return NULL;
+
+   ums_board.ums_dev.mmc = mmc;
+   ums_board.ums_dev.dev_num = dev_num;
+   ums_board.ums_dev.offset = offset;
+   ums_board.ums_dev.part_size = part_size;
+
+   return ums_board;
+}
+#endif
diff --git a/include/configs/trats.h b/include/configs/trats.h
index 63745ac..31d8190 100644
--- a/include/configs/trats.h
+++ b/include/configs/trats.h
@@ -316,4 +316,9 @@
 #define CONFIG_VIDEO_BMP_GZIP
 #define CONFIG_SYS_VIDEO_LOGO_MAX_SIZE ((500 * 120 * 4) + (1  12))
 
+#define CONFIG_CMD_USB_MASS_STORAGE
+#if defined(CONFIG_CMD_USB_MASS_STORAGE)
+#define CONFIG_USB_GADGET_MASS_STORAGE
+#endif
+
 #endif /* __CONFIG_H */
-- 
1.7.9.5

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


Re: [U-Boot] [PATCH] usb: ehci: exynos: Enable non-dt path

2013-02-12 Thread Vivek Gautam
Hi Minkyu,


On Tue, Feb 12, 2013 at 1:54 PM, Minkyu Kang mk7.k...@samsung.com wrote:
 Dear Vivek,

 On 11/01/13 18:24, Vivek Gautam wrote:
 Enabling the non-dt path for the driver so that
 we don't get any build errors for non-dt configuration.

 Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
 ---

 Earlier we had moved to fdt support for ehci-exynos driver, but
 missed out the non-dt path. Although this driver serves for exysno5
 onward only but better to keep the non-dt path also available.

  drivers/usb/host/ehci-exynos.c |   10 ++
  1 files changed, 10 insertions(+), 0 deletions(-)

 diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c
 index 3ca4c5c..6f0c6c3 100644
 --- a/drivers/usb/host/ehci-exynos.c
 +++ b/drivers/usb/host/ehci-exynos.c
 @@ -153,7 +153,12 @@ int ehci_hcd_init(int index, struct ehci_hccr **hccr, 
 struct ehci_hcor **hcor)
   return -ENOMEM;
   }

 +#ifdef CONFIG_OF_CONTROL
   exynos_usb_parse_dt(gd-fdt_blob, exynos);
 +#else
 + exynos-usb = (struct exynos_usb_phy *)samsung_get_base_usb_phy();
 + exynos-hcd = samsung_get_base_usb_ehci();
 +#endif

   setup_usb_phy(exynos-usb);

 @@ -185,7 +190,12 @@ int ehci_hcd_stop(int index)
   return -ENOMEM;
   }

 +#ifdef CONFIG_OF_CONTROL
   exynos_usb_parse_dt(gd-fdt_blob, exynos);
 +#else
 + exynos-usb = (struct exynos_usb_phy *)samsung_get_base_usb_phy();
 + exynos-hcd = samsung_get_base_usb_ehci();
 +#endif

   reset_usb_phy(exynos-usb);



 Patch looks good.
 But I've got compiler warnings and errors when I disabled CONFIG_OF_CONTROL.

 exynos_spi.c:391:12: warning: 'process_nodes' defined but not used 
 [-Wunused-function]
 ehci-exynos.c: In function 'ehci_hcd_init':
 ehci-exynos.c:160:14: warning: assignment makes pointer from integer without 
 a cast [enabled by default]
 ehci-exynos.c: In function 'ehci_hcd_stop':
 ehci-exynos.c:197:14: warning: assignment makes pointer from integer without 
 a cast [enabled by default]
 ehci-exynos.c: At top level:
 ehci-exynos.c:48:12: warning: 'exynos_usb_parse_dt' defined but not used 
 [-Wunused-function]
 /opt/eldk-5.2/armv7a/sysroots/i686-eldk-linux/usr/bin/armv7a-vfp-neon-linux-gnueabi/arm-linux-gnueabi-ld.bfd:/home/share/Work/u-boot-samsung/spl/u-boot-spl.lds:1:
  ignoring invalid character `#' in expression
 /opt/eldk-5.2/armv7a/sysroots/i686-eldk-linux/usr/bin/armv7a-vfp-neon-linux-gnueabi/arm-linux-gnueabi-ld.bfd:/home/share/Work/u-boot-samsung/spl/u-boot-spl.lds:1:
  syntax error
 make[1]: *** [/home/share/Work/u-boot-samsung/spl/u-boot-spl] Error 1
 make: *** [spl/u-boot-spl.bin] Error 2
 make: *** Waiting for unfinished jobs
 smdk5250.c: In function 'board_eth_init':
 smdk5250.c:152:6: warning: unused variable 'node' [-Wunused-variable]

 Could you please check this issue also?


Sure, will check this, and resolve the underlying issue.


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


Re: [U-Boot] [PATCH v2 1/2] Tegra: fdt: Add/enhance sdhci (mmc) nodes for all T20 DT files

2013-02-12 Thread Thierry Reding
On Tue, Feb 12, 2013 at 07:51:55AM +0100, Thierry Reding wrote:
 On Mon, Feb 11, 2013 at 12:21:59PM -0700, Tom Warren wrote:
  Thierry/Lucas,
  
  On Mon, Feb 11, 2013 at 12:11 PM, Thierry Reding
  thierry.red...@avionic-design.de wrote:
   On Mon, Feb 11, 2013 at 10:56:33AM -0700, Tom Warren wrote:
   Lucas,
  
   On Mon, Feb 11, 2013 at 10:28 AM, Lucas Stach d...@lynxeye.de wrote:
Hi Tom,
   
Am Montag, den 11.02.2013, 10:17 -0700 schrieb Tom Warren:
Linux dts files were used for those boards that didn't already
have sdhci info populated. Tamonten has their own dtsi file with
common sdhci nodes (sourced from Linux).
   
Signed-off-by: Tom Warren twar...@nvidia.com
---
v2:
- cleanup comments in dts files/match w/kernel files
- add sdhci aliases in all dts files
- use tegra20-tamonten.dtsi from the kernel for AD boards
   
 arch/arm/dts/tegra20-tamonten.dtsi   |  489 
++
   
I'm not sure if pushing the whole file in this patch is the right thing
to do.
  
   I didn't want to edit it since we seem to be moving towards using the
   Linux DTS files in toto in U-Boot (as per Stephen  Simon). Does it do
   any harm to have the whole thing here? Saves some work later. Thierry
   - what do you think?
  
   Given that it isn't used anywhere I don't think we really need it right
   now. We can always add it later when we can make better use of it.
  
  It actually is used (for SDMMC/sdhci) now, Thierry. That's why it's in
  this patchset.
 
 Right, I hadn't looked at that patch yet.
 
  I had originally put the sdhci node for Avionic Design
  boards in their respective .dts files, but Stephen pointed out that
  the kernel had a tegra20-tamonten.dtsi file with common info, which
  included the sdhci node, and asked that I use it, instead, so we echo
  the kernel layout. So I pulled that file into my MMC DT patchset, and
  used it in all AD board builds (medcom/tec/plutux) - it's pulled in
  via an override of CONFIG_ARCH_DEVICE_TREE in the config files.
  
  So the options seem to be:
  
  a) Don't use the tamonton dtsi file, and put the sdhci nodes in the AD
  dts files, just like all other boards (this was my V1 approach).
  Vetoed by Stephen.
  b) Use tegra20-tamonten.dtsi as is, identical to the kernel file. If
  necessary, I can move it's inclusion to a separate patch, independent
  of the MMC DT patchset, as suggested by Lucas.
  c) Use tegra20-tamonten.dtsi, but just with the sdhci node (is this
  what you're suggesting, Thierry?). I'd still pull it in via a
  CONFIG_ARCH_DEVICE_TREE #define in the AD config files.
  
  Let me know ASAP - I'd like to get V3 upstreamed soon so I can move on
  to work on the T30/T114 MMC patches.
 
 I think option b) sounds fine given that we want to move to the same DTS
 as the kernel eventually anyway. So for the Tamonten (and AD board)
 pieces, consider this:
 
   Acked-by: Thierry Reding thierry.red...@avionic-design.de
 
 I can't give you a Tested-by because I have a bunch of other things to
 take care of and I probably won't get to testing this for a few days.

So it turned out that I need to touch U-Boot anyway, so I decided to
give this a spin. I noticed that overriding CONFIG_ARCH_DEVICE_TREE from
the board configuration file doesn't work currently. What happens is
that the autoconf.mk (which is derived from the board configuration) is
included before the CPU config.mk which sets CONFIG_ARCH_DEVICE_TREE to
tegra20 (or tegra30, tegra114). I came up with the attached patch to set
the variable if not set previously (by the board configuration file).

Feel free to squash that in your patch series if you deem it a proper
solution. I can also provide a proper separate patch if you prefer.

Thierry
diff --git a/arch/arm/cpu/armv7/tegra114/config.mk 
b/arch/arm/cpu/armv7/tegra114/config.mk
index cb1a19d..e7c22c0 100644
--- a/arch/arm/cpu/armv7/tegra114/config.mk
+++ b/arch/arm/cpu/armv7/tegra114/config.mk
@@ -16,4 +16,4 @@
 # You should have received a copy of the GNU General Public License
 # along with this program.  If not, see http://www.gnu.org/licenses/.
 #
-CONFIG_ARCH_DEVICE_TREE := tegra114
+CONFIG_ARCH_DEVICE_TREE ?= tegra114
diff --git a/arch/arm/cpu/armv7/tegra20/config.mk 
b/arch/arm/cpu/armv7/tegra20/config.mk
index 6432e75..9042664 100644
--- a/arch/arm/cpu/armv7/tegra20/config.mk
+++ b/arch/arm/cpu/armv7/tegra20/config.mk
@@ -23,4 +23,4 @@
 # Foundation, Inc., 59 Temple Place, Suite 330, Boston,
 # MA 02111-1307 USA
 #
-CONFIG_ARCH_DEVICE_TREE := tegra20
+CONFIG_ARCH_DEVICE_TREE ?= tegra20
diff --git a/arch/arm/cpu/armv7/tegra30/config.mk 
b/arch/arm/cpu/armv7/tegra30/config.mk
index 719ca81..0035bc5 100644
--- a/arch/arm/cpu/armv7/tegra30/config.mk
+++ b/arch/arm/cpu/armv7/tegra30/config.mk
@@ -16,4 +16,4 @@
 # You should have received a copy of the GNU General Public License
 # along with this program.  If not, see http://www.gnu.org/licenses/.
 #

Re: [U-Boot] [PATCH v2 1/2] Tegra: fdt: Add/enhance sdhci (mmc) nodes for all T20 DT files

2013-02-12 Thread Thierry Reding
On Tue, Feb 12, 2013 at 11:41:09AM +0100, Thierry Reding wrote:
 On Tue, Feb 12, 2013 at 07:51:55AM +0100, Thierry Reding wrote:
  On Mon, Feb 11, 2013 at 12:21:59PM -0700, Tom Warren wrote:
   Thierry/Lucas,
   
   On Mon, Feb 11, 2013 at 12:11 PM, Thierry Reding
   thierry.red...@avionic-design.de wrote:
On Mon, Feb 11, 2013 at 10:56:33AM -0700, Tom Warren wrote:
Lucas,
   
On Mon, Feb 11, 2013 at 10:28 AM, Lucas Stach d...@lynxeye.de wrote:
 Hi Tom,

 Am Montag, den 11.02.2013, 10:17 -0700 schrieb Tom Warren:
 Linux dts files were used for those boards that didn't already
 have sdhci info populated. Tamonten has their own dtsi file with
 common sdhci nodes (sourced from Linux).

 Signed-off-by: Tom Warren twar...@nvidia.com
 ---
 v2:
 - cleanup comments in dts files/match w/kernel files
 - add sdhci aliases in all dts files
 - use tegra20-tamonten.dtsi from the kernel for AD boards

  arch/arm/dts/tegra20-tamonten.dtsi   |  489 
 ++

 I'm not sure if pushing the whole file in this patch is the right 
 thing
 to do.
   
I didn't want to edit it since we seem to be moving towards using the
Linux DTS files in toto in U-Boot (as per Stephen  Simon). Does it do
any harm to have the whole thing here? Saves some work later. Thierry
- what do you think?
   
Given that it isn't used anywhere I don't think we really need it right
now. We can always add it later when we can make better use of it.
   
   It actually is used (for SDMMC/sdhci) now, Thierry. That's why it's in
   this patchset.
  
  Right, I hadn't looked at that patch yet.
  
   I had originally put the sdhci node for Avionic Design
   boards in their respective .dts files, but Stephen pointed out that
   the kernel had a tegra20-tamonten.dtsi file with common info, which
   included the sdhci node, and asked that I use it, instead, so we echo
   the kernel layout. So I pulled that file into my MMC DT patchset, and
   used it in all AD board builds (medcom/tec/plutux) - it's pulled in
   via an override of CONFIG_ARCH_DEVICE_TREE in the config files.
   
   So the options seem to be:
   
   a) Don't use the tamonton dtsi file, and put the sdhci nodes in the AD
   dts files, just like all other boards (this was my V1 approach).
   Vetoed by Stephen.
   b) Use tegra20-tamonten.dtsi as is, identical to the kernel file. If
   necessary, I can move it's inclusion to a separate patch, independent
   of the MMC DT patchset, as suggested by Lucas.
   c) Use tegra20-tamonten.dtsi, but just with the sdhci node (is this
   what you're suggesting, Thierry?). I'd still pull it in via a
   CONFIG_ARCH_DEVICE_TREE #define in the AD config files.
   
   Let me know ASAP - I'd like to get V3 upstreamed soon so I can move on
   to work on the T30/T114 MMC patches.
  
  I think option b) sounds fine given that we want to move to the same DTS
  as the kernel eventually anyway. So for the Tamonten (and AD board)
  pieces, consider this:
  
  Acked-by: Thierry Reding thierry.red...@avionic-design.de
  
  I can't give you a Tested-by because I have a bunch of other things to
  take care of and I probably won't get to testing this for a few days.
 
 So it turned out that I need to touch U-Boot anyway, so I decided to
 give this a spin. I noticed that overriding CONFIG_ARCH_DEVICE_TREE from
 the board configuration file doesn't work currently. What happens is
 that the autoconf.mk (which is derived from the board configuration) is
 included before the CPU config.mk which sets CONFIG_ARCH_DEVICE_TREE to
 tegra20 (or tegra30, tegra114). I came up with the attached patch to set
 the variable if not set previously (by the board configuration file).
 
 Feel free to squash that in your patch series if you deem it a proper
 solution. I can also provide a proper separate patch if you prefer.
 
 Thierry

 diff --git a/arch/arm/cpu/armv7/tegra114/config.mk 
 b/arch/arm/cpu/armv7/tegra114/config.mk
 index cb1a19d..e7c22c0 100644
 --- a/arch/arm/cpu/armv7/tegra114/config.mk
 +++ b/arch/arm/cpu/armv7/tegra114/config.mk
 @@ -16,4 +16,4 @@
  # You should have received a copy of the GNU General Public License
  # along with this program.  If not, see http://www.gnu.org/licenses/.
  #
 -CONFIG_ARCH_DEVICE_TREE := tegra114
 +CONFIG_ARCH_DEVICE_TREE ?= tegra114
 diff --git a/arch/arm/cpu/armv7/tegra20/config.mk 
 b/arch/arm/cpu/armv7/tegra20/config.mk
 index 6432e75..9042664 100644
 --- a/arch/arm/cpu/armv7/tegra20/config.mk
 +++ b/arch/arm/cpu/armv7/tegra20/config.mk
 @@ -23,4 +23,4 @@
  # Foundation, Inc., 59 Temple Place, Suite 330, Boston,
  # MA 02111-1307 USA
  #
 -CONFIG_ARCH_DEVICE_TREE := tegra20
 +CONFIG_ARCH_DEVICE_TREE ?= tegra20
 diff --git a/arch/arm/cpu/armv7/tegra30/config.mk 
 b/arch/arm/cpu/armv7/tegra30/config.mk
 index 719ca81..0035bc5 100644
 --- a/arch/arm/cpu/armv7/tegra30/config.mk
 +++ 

Re: [U-Boot] [PATCH v5 3/3] SPL: Change description for spl command

2013-02-12 Thread Andreas Bießmann
Dear Stefano Babic,

On 02/12/2013 09:38 AM, Stefano Babic wrote:
 Add a more descriptive text to the help of the spl
 command.
 
 Signed-off-by: Stefano Babic sba...@denx.de
 ---
 Changes in v5: None
 Changes in v4: None
 Changes in v3: None

That is not correct, there where changes since v3, this patch was
introduced in v2.

 Changes in v2: None

However, no complaints on the patch content.

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

Best regards

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


[U-Boot] [PATCH V3 0/5] ARM: OMAP5: Add support for OMAP543x ES2.0 Socs

2013-02-12 Thread R Sricharan
ES2.0 is the latest silicon revision for OMAP543X socs. The SOC
supports enhanced opps for MPU (up to 1.5GHz). This series essentially
adds the support for both 5430 and 5432 versions.

This is on top of the below U-Boot cleanup series.
 http://comments.gmane.org/gmane.comp.boot-loaders.u-boot/152834

Both the cleanup and ES2.0 support series against mainline is available
here
 git://gitorious.org/u-boot-shared/u-boot.git omap5_es2

Lokesh Vutla (2):
  ARM: OMAP5: Add DDR changes required for OMAP543X ES2.0 SOCs
  ARM: OMAP5: srcomp: enable slew rate compensation cells after powerup

R Sricharan (3):
  ARM: OMAP5: Add silicon id support for ES2.0 revision.
  ARM: OMAP5: clock: Add the prcm register changes required for ES2.0
  ARM: OMAP5: clocks: Add OPP settings required for OMAP543X ES2.0 soc

 arch/arm/cpu/armv7/omap-common/clocks-common.c |9 +-
 arch/arm/cpu/armv7/omap-common/hwinit-common.c |6 +
 arch/arm/cpu/armv7/omap4/hw_data.c |  164 +++---
 arch/arm/cpu/armv7/omap5/hw_data.c |  254 +
 arch/arm/cpu/armv7/omap5/hwinit.c  |  143 +++-
 arch/arm/cpu/armv7/omap5/prcm-regs.c   |  286 
 arch/arm/cpu/armv7/omap5/sdram.c   |   75 ++-
 arch/arm/include/asm/arch-omap5/clocks.h   |   39 +++-
 arch/arm/include/asm/arch-omap5/omap.h |   27 +++
 arch/arm/include/asm/arch-omap5/sys_proto.h|1 +
 arch/arm/include/asm/armv7.h   |1 +
 arch/arm/include/asm/emif.h|1 +
 arch/arm/include/asm/omap_common.h |   14 +-
 13 files changed, 828 insertions(+), 192 deletions(-)

-- 
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 1/5] ARM: OMAP5: Add silicon id support for ES2.0 revision.

2013-02-12 Thread R Sricharan
Adding the CPU detection suport for OMAP5430 and
OMAP5432 ES2.0 SOCs.

Signed-off-by: R Sricharan r.sricha...@ti.com
Cc: Tom Rini tr...@ti.com
Cc: Nishanth Menon n...@ti.com
---
 [v2] Addressed Tom Rini's tr...@ti.com comments
 [v3] Changed the patch to use CONTROL_ID_CODE first
  and then arm revision if nessecary.

 arch/arm/cpu/armv7/omap5/hwinit.c  |   27 ---
 arch/arm/include/asm/arch-omap5/omap.h |2 ++
 arch/arm/include/asm/armv7.h   |1 +
 arch/arm/include/asm/omap_common.h |2 ++
 4 files changed, 21 insertions(+), 11 deletions(-)

diff --git a/arch/arm/cpu/armv7/omap5/hwinit.c 
b/arch/arm/cpu/armv7/omap5/hwinit.c
index dfc0e44..8e66a96 100644
--- a/arch/arm/cpu/armv7/omap5/hwinit.c
+++ b/arch/arm/cpu/armv7/omap5/hwinit.c
@@ -204,17 +204,22 @@ void init_omap_revision(void)
 */
unsigned int rev = cortex_rev();
 
-   switch (rev) {
-   case MIDR_CORTEX_A15_R0P0:
-   switch (readl(CONTROL_ID_CODE)) {
-   case OMAP5430_CONTROL_ID_CODE_ES1_0:
-   *omap_si_rev = OMAP5430_ES1_0;
-   break;
-   case OMAP5432_CONTROL_ID_CODE_ES1_0:
-   default:
-   *omap_si_rev = OMAP5432_ES1_0;
-   break;
-   }
+   switch (readl(CONTROL_ID_CODE)) {
+   case OMAP5430_CONTROL_ID_CODE_ES1_0:
+   *omap_si_rev = OMAP5430_ES1_0;
+   if (rev == MIDR_CORTEX_A15_R2P2)
+   *omap_si_rev = OMAP5430_ES2_0;
+   break;
+   case OMAP5432_CONTROL_ID_CODE_ES1_0:
+   *omap_si_rev = OMAP5432_ES1_0;
+   if (rev == MIDR_CORTEX_A15_R2P2)
+   *omap_si_rev = OMAP5432_ES2_0;
+   break;
+   case OMAP5430_CONTROL_ID_CODE_ES2_0:
+   *omap_si_rev = OMAP5430_ES2_0;
+   break;
+   case OMAP5432_CONTROL_ID_CODE_ES2_0:
+   *omap_si_rev = OMAP5432_ES2_0;
break;
default:
*omap_si_rev = OMAP5430_SILICON_ID_INVALID;
diff --git a/arch/arm/include/asm/arch-omap5/omap.h 
b/arch/arm/include/asm/arch-omap5/omap.h
index 873ccd7..71935d8 100644
--- a/arch/arm/include/asm/arch-omap5/omap.h
+++ b/arch/arm/include/asm/arch-omap5/omap.h
@@ -57,7 +57,9 @@
 
 /* To be verified */
 #define OMAP5430_CONTROL_ID_CODE_ES1_0 0x0B94202F
+#define OMAP5430_CONTROL_ID_CODE_ES2_0  0x1B94202F
 #define OMAP5432_CONTROL_ID_CODE_ES1_0 0x0B99802F
+#define OMAP5432_CONTROL_ID_CODE_ES2_0  0x1B99802F
 
 /* STD_FUSE_PROD_ID_1 */
 #define STD_FUSE_PROD_ID_1 (CTRL_BASE + 0x218)
diff --git a/arch/arm/include/asm/armv7.h b/arch/arm/include/asm/armv7.h
index ad9a875..a73630b 100644
--- a/arch/arm/include/asm/armv7.h
+++ b/arch/arm/include/asm/armv7.h
@@ -33,6 +33,7 @@
 
 /* Cortex-A15 revisions */
 #define MIDR_CORTEX_A15_R0P0   0x410FC0F0
+#define MIDR_CORTEX_A15_R2P2   0x412FC0F2
 
 /* CCSIDR */
 #define CCSIDR_LINE_SIZE_OFFSET0
diff --git a/arch/arm/include/asm/omap_common.h 
b/arch/arm/include/asm/omap_common.h
index 2115687..4599167 100644
--- a/arch/arm/include/asm/omap_common.h
+++ b/arch/arm/include/asm/omap_common.h
@@ -542,4 +542,6 @@ static inline u32 omap_revision(void)
 #define OMAP5430_SILICON_ID_INVALID0
 #define OMAP5430_ES1_0 0x54300100
 #define OMAP5432_ES1_0 0x54320100
+#define OMAP5430_ES2_0  0x54300200
+#define OMAP5432_ES2_0  0x54320200
 #endif /* _OMAP_COMMON_H_ */
-- 
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/5] ARM: OMAP5: clock: Add the prcm register changes required for ES2.0

2013-02-12 Thread R Sricharan
PRCM register addresses are changed from ES1.0 to ES2.0 due to
PER power domain getting moved to CORE power domain.

So adding the nessecary register changes for the same.

Signed-off-by: R Sricharan r.sricha...@ti.com
Reviewed-by: Tom Rini tr...@ti.com
Cc: Tom Rini tr...@ti.com
---
 [v2] Addressed Tom Rini's tr...@ti.com comments
 [v3] No Change

 arch/arm/cpu/armv7/omap5/hw_data.c   |5 +
 arch/arm/cpu/armv7/omap5/prcm-regs.c |  283 ++
 arch/arm/include/asm/omap_common.h   |4 +
 3 files changed, 292 insertions(+)

diff --git a/arch/arm/cpu/armv7/omap5/hw_data.c 
b/arch/arm/cpu/armv7/omap5/hw_data.c
index 6b039f5..e319dc5 100644
--- a/arch/arm/cpu/armv7/omap5/hw_data.c
+++ b/arch/arm/cpu/armv7/omap5/hw_data.c
@@ -451,6 +451,11 @@ void hw_data_init(void)
*omap_vcores = omap5432_volts;
break;
 
+   case OMAP5430_ES2_0:
+   case OMAP5432_ES2_0:
+   *prcm = omap5_es2_prcm;
+   break;
+
default:
printf(\n INVALID OMAP REVISION );
}
diff --git a/arch/arm/cpu/armv7/omap5/prcm-regs.c 
b/arch/arm/cpu/armv7/omap5/prcm-regs.c
index 0f58b2f..58c9d50 100644
--- a/arch/arm/cpu/armv7/omap5/prcm-regs.c
+++ b/arch/arm/cpu/armv7/omap5/prcm-regs.c
@@ -378,3 +378,286 @@ struct omap_sys_ctrl_regs const omap5_ctrl = {
.control_efuse_12   = 0x4AE0CDF4,
.control_efuse_13   = 0x4AE0CDF8,
 };
+
+struct prcm_regs const omap5_es2_prcm = {
+   /* cm1.ckgen */
+   .cm_clksel_core = 0x4a004100,
+   .cm_clksel_abe = 0x4a004108,
+   .cm_dll_ctrl = 0x4a004110,
+   .cm_clkmode_dpll_core = 0x4a004120,
+   .cm_idlest_dpll_core = 0x4a004124,
+   .cm_autoidle_dpll_core = 0x4a004128,
+   .cm_clksel_dpll_core = 0x4a00412c,
+   .cm_div_m2_dpll_core = 0x4a004130,
+   .cm_div_m3_dpll_core = 0x4a004134,
+   .cm_div_h11_dpll_core = 0x4a004138,
+   .cm_div_h12_dpll_core = 0x4a00413c,
+   .cm_div_h13_dpll_core = 0x4a004140,
+   .cm_div_h14_dpll_core = 0x4a004144,
+   .cm_ssc_deltamstep_dpll_core = 0x4a004148,
+   .cm_ssc_modfreqdiv_dpll_core = 0x4a00414c,
+   .cm_div_h21_dpll_core = 0x4a004150,
+   .cm_div_h22_dpllcore = 0x4a004154,
+   .cm_div_h23_dpll_core = 0x4a004158,
+   .cm_div_h24_dpll_core = 0x4a00415c,
+   .cm_clkmode_dpll_mpu = 0x4a004160,
+   .cm_idlest_dpll_mpu = 0x4a004164,
+   .cm_autoidle_dpll_mpu = 0x4a004168,
+   .cm_clksel_dpll_mpu = 0x4a00416c,
+   .cm_div_m2_dpll_mpu = 0x4a004170,
+   .cm_ssc_deltamstep_dpll_mpu = 0x4a004188,
+   .cm_ssc_modfreqdiv_dpll_mpu = 0x4a00418c,
+   .cm_bypclk_dpll_mpu = 0x4a00419c,
+   .cm_clkmode_dpll_iva = 0x4a0041a0,
+   .cm_idlest_dpll_iva = 0x4a0041a4,
+   .cm_autoidle_dpll_iva = 0x4a0041a8,
+   .cm_clksel_dpll_iva = 0x4a0041ac,
+   .cm_div_h11_dpll_iva = 0x4a0041b8,
+   .cm_div_h12_dpll_iva = 0x4a0041bc,
+   .cm_ssc_deltamstep_dpll_iva = 0x4a0041c8,
+   .cm_ssc_modfreqdiv_dpll_iva = 0x4a0041cc,
+   .cm_bypclk_dpll_iva = 0x4a0041dc,
+   .cm_clkmode_dpll_abe = 0x4a0041e0,
+   .cm_idlest_dpll_abe = 0x4a0041e4,
+   .cm_autoidle_dpll_abe = 0x4a0041e8,
+   .cm_clksel_dpll_abe = 0x4a0041ec,
+   .cm_div_m2_dpll_abe = 0x4a0041f0,
+   .cm_div_m3_dpll_abe = 0x4a0041f4,
+   .cm_ssc_deltamstep_dpll_abe = 0x4a004208,
+   .cm_ssc_modfreqdiv_dpll_abe = 0x4a00420c,
+   .cm_clkmode_dpll_ddrphy = 0x4a004220,
+   .cm_idlest_dpll_ddrphy = 0x4a004224,
+   .cm_autoidle_dpll_ddrphy = 0x4a004228,
+   .cm_clksel_dpll_ddrphy = 0x4a00422c,
+   .cm_div_m2_dpll_ddrphy = 0x4a004230,
+   .cm_div_h11_dpll_ddrphy = 0x4a004238,
+   .cm_div_h12_dpll_ddrphy = 0x4a00423c,
+   .cm_div_h13_dpll_ddrphy = 0x4a004240,
+   .cm_ssc_deltamstep_dpll_ddrphy = 0x4a004248,
+   .cm_shadow_freq_config1 = 0x4a004260,
+   .cm_mpu_mpu_clkctrl = 0x4a004320,
+
+   /* cm1.dsp */
+   .cm_dsp_clkstctrl = 0x4a004400,
+   .cm_dsp_dsp_clkctrl = 0x4a004420,
+
+   /* cm1.abe */
+   .cm1_abe_clkstctrl = 0x4a004500,
+   .cm1_abe_l4abe_clkctrl = 0x4a004520,
+   .cm1_abe_aess_clkctrl = 0x4a004528,
+   .cm1_abe_pdm_clkctrl = 0x4a004530,
+   .cm1_abe_dmic_clkctrl = 0x4a004538,
+   .cm1_abe_mcasp_clkctrl = 0x4a004540,
+   .cm1_abe_mcbsp1_clkctrl = 0x4a004548,
+   .cm1_abe_mcbsp2_clkctrl = 0x4a004550,
+   .cm1_abe_mcbsp3_clkctrl = 0x4a004558,
+   .cm1_abe_slimbus_clkctrl = 0x4a004560,
+   .cm1_abe_timer5_clkctrl = 0x4a004568,
+   .cm1_abe_timer6_clkctrl = 0x4a004570,
+   .cm1_abe_timer7_clkctrl = 0x4a004578,
+   .cm1_abe_timer8_clkctrl = 0x4a004580,
+   .cm1_abe_wdt3_clkctrl = 0x4a004588,
+
+
+
+   /* cm2.ckgen */
+   .cm_clksel_mpu_m3_iss_root = 0x4a008100,
+   .cm_clksel_usb_60mhz = 0x4a008104,
+   .cm_scale_fclk = 0x4a008108,
+   .cm_core_dvfs_perf1 = 0x4a008110,
+   .cm_core_dvfs_perf2 = 

[U-Boot] [PATCH V3 4/5] ARM: OMAP5: Add DDR changes required for OMAP543X ES2.0 SOCs

2013-02-12 Thread R Sricharan
From: Lokesh Vutla lokeshvu...@ti.com

Add pre calculated timing settings of LPDDR2 and DDR3 memories
present in OMAP5430 and OMAP5432 ES2.0 versions.

Also adding the DDR pad io settings required for
OMAP543X SOCs here.

Signed-off-by: R Sricharan r.sricha...@ti.com
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
Reviewed-by: Tom Rini tr...@ti.com
Cc: Tom Rini tr...@ti.com
---
 [v2] Addressed Tom Rini's tr...@ti.com comments
 [v3] No Change

 arch/arm/cpu/armv7/omap5/hw_data.c |   14 ++
 arch/arm/cpu/armv7/omap5/sdram.c   |   75 +++-
 arch/arm/include/asm/arch-omap5/omap.h |6 +++
 arch/arm/include/asm/emif.h|1 +
 4 files changed, 94 insertions(+), 2 deletions(-)

diff --git a/arch/arm/cpu/armv7/omap5/hw_data.c 
b/arch/arm/cpu/armv7/omap5/hw_data.c
index 6470ece..772fdfb 100644
--- a/arch/arm/cpu/armv7/omap5/hw_data.c
+++ b/arch/arm/cpu/armv7/omap5/hw_data.c
@@ -488,6 +488,16 @@ const struct ctrl_ioregs ioregs_omap5432_es1 = {
.ctrl_emif_sdram_config_ext = SDRAM_CONFIG_EXT_RD_LVL_11_SAMPLES,
 };
 
+const struct ctrl_ioregs ioregs_omap5432_es2 = {
+   .ctrl_ddrch = DDR_IO_I_40OHM_SR_FAST_WD_DQ_NO_PULL_DQS_NO_PULL_ES2,
+   .ctrl_lpddr2ch = 0x0,
+   .ctrl_ddr3ch = DDR_IO_I_40OHM_SR_SLOWEST_WD_DQ_NO_PULL_DQS_NO_PULL_ES2,
+   .ctrl_ddrio_0 = DDR_IO_0_VREF_CELLS_DDR3_VALUE_ES2,
+   .ctrl_ddrio_1 = DDR_IO_1_VREF_CELLS_DDR3_VALUE_ES2,
+   .ctrl_ddrio_2 = DDR_IO_2_VREF_CELLS_DDR3_VALUE_ES2,
+   .ctrl_emif_sdram_config_ext = SDRAM_CONFIG_EXT_RD_LVL_11_SAMPLES,
+};
+
 void hw_data_init(void)
 {
u32 omap_rev = omap_revision();
@@ -526,11 +536,15 @@ void get_ioregs(const struct ctrl_ioregs **regs)
 
switch (omap_rev) {
case OMAP5430_ES1_0:
+   case OMAP5430_ES2_0:
*regs = ioregs_omap5430;
break;
case OMAP5432_ES1_0:
*regs = ioregs_omap5432_es1;
break;
+   case OMAP5432_ES2_0:
+   *regs = ioregs_omap5432_es2;
+   break;
 
default:
printf(\n INVALID OMAP REVISION );
diff --git a/arch/arm/cpu/armv7/omap5/sdram.c b/arch/arm/cpu/armv7/omap5/sdram.c
index 687800f..2ef7fcd 100644
--- a/arch/arm/cpu/armv7/omap5/sdram.c
+++ b/arch/arm/cpu/armv7/omap5/sdram.c
@@ -67,6 +67,25 @@ const struct emif_regs emif_regs_532_mhz_2cs = {
.emif_ddr_ext_phy_ctrl_5= 0x04010040
 };
 
+const struct emif_regs emif_regs_532_mhz_2cs_es2 = {
+   .sdram_config_init  = 0x80800EBA,
+   .sdram_config   = 0x808022BA,
+   .ref_ctrl   = 0x081A,
+   .sdram_tim1 = 0x772F6873,
+   .sdram_tim2 = 0x304a129a,
+   .sdram_tim3 = 0x02f7e45f,
+   .read_idle_ctrl = 0x0005,
+   .zq_config  = 0x100b3215,
+   .temp_alert_config  = 0x08000a05,
+   .emif_ddr_phy_ctlr_1_init   = 0x0E30400d,
+   .emif_ddr_phy_ctlr_1= 0x0E30400d,
+   .emif_ddr_ext_phy_ctrl_1= 0x04020080,
+   .emif_ddr_ext_phy_ctrl_2= 0x28C518A3,
+   .emif_ddr_ext_phy_ctrl_3= 0x518A3146,
+   .emif_ddr_ext_phy_ctrl_4= 0x0014628C,
+   .emif_ddr_ext_phy_ctrl_5= 0xC330CC33,
+};
+
 const struct emif_regs emif_regs_266_mhz_2cs = {
.sdram_config_init  = 0x80800EBA,
.sdram_config   = 0x808022BA,
@@ -109,6 +128,29 @@ const struct emif_regs emif_regs_ddr3_532_mhz_1cs = {
.emif_rd_wr_exec_thresh = 0x0305
 };
 
+const struct emif_regs emif_regs_ddr3_532_mhz_1cs_es2 = {
+   .sdram_config_init  = 0x61851B32,
+   .sdram_config   = 0x61851B32,
+   .ref_ctrl   = 0x1035,
+   .sdram_tim1 = 0xCCCF36B3,
+   .sdram_tim2 = 0x308F7FDA,
+   .sdram_tim3 = 0x027F88A8,
+   .read_idle_ctrl = 0x0005,
+   .zq_config  = 0x1007190B,
+   .temp_alert_config  = 0x,
+   .emif_ddr_phy_ctlr_1_init   = 0x0030400A,
+   .emif_ddr_phy_ctlr_1= 0x0034400A,
+   .emif_ddr_ext_phy_ctrl_1= 0x04040100,
+   .emif_ddr_ext_phy_ctrl_2= 0x,
+   .emif_ddr_ext_phy_ctrl_3= 0x,
+   .emif_ddr_ext_phy_ctrl_4= 0x,
+   .emif_ddr_ext_phy_ctrl_5= 0x4350D435,
+   .emif_rd_wr_lvl_rmp_win = 0x,
+   .emif_rd_wr_lvl_rmp_ctl = 0x8000,
+   .emif_rd_wr_lvl_ctl = 0x,
+   .emif_rd_wr_exec_thresh = 0x4305
+};
+
 const struct dmm_lisa_map_regs lisa_map_4G_x_2_x_2 = {
.dmm_lisa_map_0 = 0x0,
.dmm_lisa_map_1 = 0x0,
@@ -125,8 +167,12 @@ static void emif_get_reg_dump_sdp(u32 emif_nr, const 
struct emif_regs 

[U-Boot] [PATCH V3 5/5] ARM: OMAP5: srcomp: enable slew rate compensation cells after powerup

2013-02-12 Thread R Sricharan
From: Lokesh Vutla lokeshvu...@ti.com

After power-up SRCOMP cells are by-passed by default in OMAP5.
Software has to enable these SRCOMP sells.
For ES2: All 5 SRCOMP cells needs to be enabled.
For ES1: Only 4 SRCOMP cells in core power domain are enabled.
 The 1 in wkup domain is not enabled because smart i/os
 of wkup domain work with default compensation code.

Signed-off-by: R Sricharan r.sricha...@ti.com
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
Reviewed-by: Tom Rini tr...@ti.com
Cc: Tom Rini tr...@ti.com
---
 [v2] Addressed Tom Rini's tr...@ti.com comments
 [v3] No Change

 arch/arm/cpu/armv7/omap-common/hwinit-common.c |6 ++
 arch/arm/cpu/armv7/omap5/hwinit.c  |  116 
 arch/arm/cpu/armv7/omap5/prcm-regs.c   |5 +-
 arch/arm/include/asm/arch-omap5/clocks.h   |4 +
 arch/arm/include/asm/arch-omap5/omap.h |   19 
 arch/arm/include/asm/arch-omap5/sys_proto.h|1 +
 arch/arm/include/asm/omap_common.h |2 +
 7 files changed, 152 insertions(+), 1 deletion(-)

diff --git a/arch/arm/cpu/armv7/omap-common/hwinit-common.c 
b/arch/arm/cpu/armv7/omap-common/hwinit-common.c
index e5a5eb6..60af7eb 100644
--- a/arch/arm/cpu/armv7/omap-common/hwinit-common.c
+++ b/arch/arm/cpu/armv7/omap-common/hwinit-common.c
@@ -33,6 +33,7 @@
 #include asm/sizes.h
 #include asm/emif.h
 #include asm/omap_common.h
+#include linux/compiler.h
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -100,6 +101,10 @@ void spl_display_print(void)
 }
 #endif
 
+void __weak srcomp_enable(void)
+{
+}
+
 /*
  * Routine: s_init
  * Description: Does early system init of watchdog, muxing,  andclocks
@@ -126,6 +131,7 @@ void s_init(void)
watchdog_init();
set_mux_conf_regs();
 #ifdef CONFIG_SPL_BUILD
+   srcomp_enable();
setup_clocks_for_console();
 
gd = gdata;
diff --git a/arch/arm/cpu/armv7/omap5/hwinit.c 
b/arch/arm/cpu/armv7/omap5/hwinit.c
index 8e66a96..f083198 100644
--- a/arch/arm/cpu/armv7/omap5/hwinit.c
+++ b/arch/arm/cpu/armv7/omap5/hwinit.c
@@ -32,6 +32,7 @@
 #include asm/armv7.h
 #include asm/arch/cpu.h
 #include asm/arch/sys_proto.h
+#include asm/arch/clocks.h
 #include asm/sizes.h
 #include asm/utils.h
 #include asm/arch/gpio.h
@@ -182,6 +183,121 @@ void do_io_settings(void)
writel(EFUSE_3, (*ctrl)-control_efuse_3);
writel(EFUSE_4, (*ctrl)-control_efuse_4);
 }
+
+static const struct srcomp_params srcomp_parameters[NUM_SYS_CLKS] = {
+   {0x45, 0x1},/* 12 MHz   */
+   {-1, -1},   /* 13 MHz   */
+   {0x63, 0x2},/* 16.8 MHz */
+   {0x57, 0x2},/* 19.2 MHz */
+   {0x20, 0x1},/* 26 MHz   */
+   {-1, -1},   /* 27 MHz   */
+   {0x41, 0x3} /* 38.4 MHz */
+};
+
+void srcomp_enable(void)
+{
+   u32 srcomp_value, mul_factor, div_factor, clk_val, i;
+   u32 sysclk_ind  = get_sys_clk_index();
+   u32 omap_rev= omap_revision();
+
+   mul_factor = srcomp_parameters[sysclk_ind].multiply_factor;
+   div_factor = srcomp_parameters[sysclk_ind].divide_factor;
+
+   for (i = 0; i  4; i++) {
+   srcomp_value = readl((*ctrl)-control_srcomp_north_side + i*4);
+   srcomp_value =
+   ~(MULTIPLY_FACTOR_XS_MASK | DIVIDE_FACTOR_XS_MASK);
+   srcomp_value |= (mul_factor  MULTIPLY_FACTOR_XS_SHIFT) |
+   (div_factor  DIVIDE_FACTOR_XS_SHIFT);
+   writel(srcomp_value, (*ctrl)-control_srcomp_north_side + i*4);
+   }
+
+   if ((omap_rev == OMAP5430_ES1_0) || (omap_rev == OMAP5432_ES1_0)) {
+   clk_val = readl((*prcm)-cm_coreaon_io_srcomp_clkctrl);
+   clk_val |= OPTFCLKEN_SRCOMP_FCLK_MASK;
+   writel(clk_val, (*prcm)-cm_coreaon_io_srcomp_clkctrl);
+
+   for (i = 0; i  4; i++) {
+   srcomp_value =
+   readl((*ctrl)-control_srcomp_north_side + i*4);
+   srcomp_value = ~PWRDWN_XS_MASK;
+   writel(srcomp_value,
+  (*ctrl)-control_srcomp_north_side + i*4);
+
+   while (((readl((*ctrl)-control_srcomp_north_side + i*4)
+SRCODE_READ_XS_MASK) 
+   SRCODE_READ_XS_SHIFT) == 0)
+   ;
+
+   srcomp_value =
+   readl((*ctrl)-control_srcomp_north_side + i*4);
+   srcomp_value = ~OVERRIDE_XS_MASK;
+   writel(srcomp_value,
+  (*ctrl)-control_srcomp_north_side + i*4);
+   }
+   } else {
+   srcomp_value = readl((*ctrl)-control_srcomp_east_side_wkup);
+   srcomp_value = ~(MULTIPLY_FACTOR_XS_MASK |
+ DIVIDE_FACTOR_XS_MASK);
+   srcomp_value |= (mul_factor  MULTIPLY_FACTOR_XS_SHIFT) |
+  

[U-Boot] [PATCH V3 3/5] ARM: OMAP4/5: clocks: Add the required OPP settings as per the latest addendum

2013-02-12 Thread R Sricharan
Change OPP settings as per the latest 0.5 version of
addendum for OMAP5430 ES2.0. omap4/hw_data.c is touched
here to add dummy dividers.

While here correcting OPP_NOM mpu, core frequency for
OMAP4430 ES2.x

Note that OMAP5430 ES1.0 support is still kept alive and
would be removed in a cleanup later.

Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
Signed-off-by: R Sricharan r.sricha...@ti.com
Cc: Tom Rini tr...@ti.com
Cc: Nishanth Menon n...@ti.com
---
 [v2] Addressed Tom Rini's tr...@ti.com comments
 [v3] Addressed some of Nishanth's comments here.
  Essentially added missing OPP_HIGH/LOW settings
  for OMAP5 E2.0 and corrected the data as per the
  0.5 addendum. Also added comments for both OMAP4/5
  frequency tables. Rephrased the subject accordingly.

 arch/arm/cpu/armv7/omap-common/clocks-common.c |9 +-
 arch/arm/cpu/armv7/omap4/hw_data.c |  164 +
 arch/arm/cpu/armv7/omap5/hw_data.c |  235 ++--
 arch/arm/include/asm/arch-omap5/clocks.h   |   29 ++-
 arch/arm/include/asm/omap_common.h |6 +-
 5 files changed, 254 insertions(+), 189 deletions(-)

diff --git a/arch/arm/cpu/armv7/omap-common/clocks-common.c 
b/arch/arm/cpu/armv7/omap-common/clocks-common.c
index 88e5336..818a963 100644
--- a/arch/arm/cpu/armv7/omap-common/clocks-common.c
+++ b/arch/arm/cpu/armv7/omap-common/clocks-common.c
@@ -103,10 +103,14 @@ void setup_post_dividers(u32 const base, const struct 
dpll_params *params)
writel(params-m6_h13, dpll_regs-cm_div_m6_h13_dpll);
if (params-m7_h14 = 0)
writel(params-m7_h14, dpll_regs-cm_div_m7_h14_dpll);
+   if (params-h21 = 0)
+   writel(params-h21, dpll_regs-cm_div_h21_dpll);
if (params-h22 = 0)
writel(params-h22, dpll_regs-cm_div_h22_dpll);
if (params-h23 = 0)
writel(params-h23, dpll_regs-cm_div_h23_dpll);
+   if (params-h24 = 0)
+   writel(params-h24, dpll_regs-cm_div_h24_dpll);
 }
 
 static inline void do_bypass_dpll(u32 const base)
@@ -319,11 +323,6 @@ void configure_mpu_dpll(void)
CM_CLKSEL_DCC_EN_MASK);
}
 
-   setbits_le32((*prcm)-cm_mpu_mpu_clkctrl,
-   MPU_CLKCTRL_CLKSEL_EMIF_DIV_MODE_MASK);
-   setbits_le32((*prcm)-cm_mpu_mpu_clkctrl,
-   MPU_CLKCTRL_CLKSEL_ABE_DIV_MODE_MASK);
-
params = get_mpu_dpll_params(*dplls_data);
 
do_setup_dpll((*prcm)-cm_clkmode_dpll_mpu, params, DPLL_LOCK, mpu);
diff --git a/arch/arm/cpu/armv7/omap4/hw_data.c 
b/arch/arm/cpu/armv7/omap4/hw_data.c
index 892d016..8d31d6d 100644
--- a/arch/arm/cpu/armv7/omap4/hw_data.c
+++ b/arch/arm/cpu/armv7/omap4/hw_data.c
@@ -49,115 +49,127 @@ struct omap_sys_ctrl_regs const **ctrl =
  * Please use this tool for creating the table for any new frequency.
  */
 
-/* dpll locked at 1400 MHz MPU clk at 700 MHz(OPP100) - DCC OFF */
+/*
+ * dpll locked at 1400 MHz MPU clk at 700 MHz(OPP100) - DCC OFF
+ * OMAP4460 OPP_NOM frequency
+ */
 static const struct dpll_params mpu_dpll_params_1400mhz[NUM_SYS_CLKS] = {
-   {175, 2, 1, -1, -1, -1, -1, -1, -1, -1},/* 12 MHz   */
-   {700, 12, 1, -1, -1, -1, -1, -1, -1, -1},   /* 13 MHz   */
-   {125, 2, 1, -1, -1, -1, -1, -1, -1, -1},/* 16.8 MHz */
-   {401, 10, 1, -1, -1, -1, -1, -1, -1, -1},   /* 19.2 MHz */
-   {350, 12, 1, -1, -1, -1, -1, -1, -1, -1},   /* 26 MHz   */
-   {700, 26, 1, -1, -1, -1, -1, -1, -1, -1},   /* 27 MHz   */
-   {638, 34, 1, -1, -1, -1, -1, -1, -1, -1}/* 38.4 MHz */
+   {175, 2, 1, -1, -1, -1, -1, -1, -1, -1, -1, -1},/* 12 MHz   */
+   {700, 12, 1, -1, -1, -1, -1, -1, -1, -1, -1, -1},   /* 13 MHz   */
+   {125, 2, 1, -1, -1, -1, -1, -1, -1, -1, -1, -1},/* 16.8 MHz */
+   {401, 10, 1, -1, -1, -1, -1, -1, -1, -1, -1, -1},   /* 19.2 MHz */
+   {350, 12, 1, -1, -1, -1, -1, -1, -1, -1, -1, -1},   /* 26 MHz   */
+   {700, 26, 1, -1, -1, -1, -1, -1, -1, -1, -1, -1},   /* 27 MHz   */
+   {638, 34, 1, -1, -1, -1, -1, -1, -1, -1, -1, -1}/* 38.4 MHz */
 };
 
-/* dpll locked at 1584 MHz - MPU clk at 792 MHz(OPP Turbo 4430) */
+/*
+ * dpll locked at 1600 MHz - MPU clk at 800 MHz(OPP Turbo 4430)
+ * OMAP4430 OPP_TURBO frequency
+ */
 static const struct dpll_params mpu_dpll_params_1600mhz[NUM_SYS_CLKS] = {
-   {200, 2, 1, -1, -1, -1, -1, -1, -1, -1},/* 12 MHz   */
-   {800, 12, 1, -1, -1, -1, -1, -1, -1, -1},   /* 13 MHz   */
-   {619, 12, 1, -1, -1, -1, -1, -1, -1, -1},   /* 16.8 MHz */
-   {125, 2, 1, -1, -1, -1, -1, -1, -1, -1},/* 19.2 MHz */
-   {400, 12, 1, -1, -1, -1, -1, -1, -1, -1},   /* 26 MHz   */
-   {800, 26, 1, -1, -1, -1, -1, -1, -1, -1},   /* 27 MHz   */
-   {125, 5, 1, -1, -1, -1, -1, -1, -1, -1} /* 38.4 MHz */
+   {200, 2, 1, -1, -1, -1, -1, -1, -1, -1, -1, -1},

Re: [U-Boot] [PATCH v5 1/3] Add README for the Falcon mode

2013-02-12 Thread Andreas Bießmann
Dear Stefano Babic,

On 02/12/2013 09:38 AM, Stefano Babic wrote:
 Simple howto to add support to a board
 for booting the kernel from SPL (Falcon mode).
 
 Signed-off-by: Stefano Babic sba...@denx.de
 ---
 Changes in v5:
 - several fixes for the language, rephrasing some unclear parts (Vikram 
 Narayanan)
 
 Changes in v4:
 - fix capitalization, styling, in spl help (Andreas Biessmann)
 - move CONFIG_SPL_OS_BOOT before function in doc (Andreas Biessmann)
 
 Changes in v3:
 - parameter initrd_addr was removed in V2 (Andreas Biessmann)
 - added patch to fix help usage for spl export (Andreas Biessmann)
 - Added empty lines (Otavio Salvador)
 - add a more exhaustive description explaining that
   spl export does not save into media (Lukasz Majewski).
 
 Changes in v2:
 - spelling, language fixes (Andreas Biessman)
 - rewrite some unclear sentences
 - drop CONFIG_SPL_OS_BOOT_KEY
 - make example with twister more exhaustive
 
  doc/README.falcon |  169 
 +
  1 file changed, 169 insertions(+)
  create mode 100644 doc/README.falcon
 
 diff --git a/doc/README.falcon b/doc/README.falcon
 new file mode 100644
 index 000..72fe04a
 --- /dev/null
 +++ b/doc/README.falcon
 @@ -0,0 +1,169 @@
 +U-Boot Falcon Mode
 +
 +
 +Introduction
 +
 +
 +This document provides an overview of how to add support for Falcon Mode
 +to a board.
 +Falcon Mode is introduced to speed up the booting process, allowing
 +to boot a Linux kernel (or whatever image) without a full blown U-Boot.
 +
 +Falcon Mode relies on the SPL framework. In fact, to make booting faster,
 +U-Boot is split into two parts: the SPL (Secondary Program Loader) and U-Boot
 +image. In most implementations, SPL is used to start U-Boot when booting from
 +a mass storage, such as NAND or SD-Card. SPL has now support for other media,
 +and can generally be seen as a way to start an image performing the minimum
 +required initialization. SPL mainly initializes the RAM controller, and then
 +copies U-Boot image into the memory. The Falcon Mode extends this way
 +allowing to start the Linux kernel directly from SPL. A new command is added
 +to U-Boot to prepare the parameters that SPL must pass to the kernel, using
 +ATAGS or Device Tree.
 +
 +In usual U-Boot systems, these parameters are generated each time before
 +loading the kernel, passing to Linux the address in memory where
 +the parameters can be read.
 +With Falcon Mode, this snapshot can be saved into persistent storage and SPL 
 is
 +informed to load it before running the kernel.
 +
 +To boot the kernel, these steps under a Falcon-aware U-Boot are required:
 +
 +1. Boot the board into U-Boot.
 +Use the spl export command to generate the kernel parameters area or the 
 DT.
 +U-Boot runs as when it boots the kernel, but stops before passing the control
 +to the kernel.
 +
 +2. Save the prepared snapshot into persistent media.
 +The address where to save it must be configured into board configuration
 +file (CONFIG_CMD_SPL_NAND_OFS for NAND).
 +
 +3. Boot the board into Falcon Mode. SPL will load the kernel and copy
 +the parameters which are saved in the persistent area area to the required 
 address.

double 'area'

 +
 +It is required to implement a custom mechanism to select if SPL loads U-Boot
 +or another image.
 +
 +The value of a GPIO is a simple way to operate the selection, as well as
 +reading a character from the SPL console if CONFIG_SPL_CONSOLE is set.
 +
 +Falcon Mode is generally activated by setting CONFIG_SPL_OS_BOOT. This tells
 +SPL that U-Boot is not the only available image that SPL is able to start.
 +
 +Configuration
 +
 +CONFIG_CMD_SPL   Enable the spl export command.
 + The command spl export is then available in U-Boot
 + mode
 +CONFIG_SYS_SPL_ARGS_ADDR Address in RAM where the parameters must be
 + copied by SPL.
 + In most cases, it is start_of_ram + 0x100
 +
 +CONFIG_SYS_NAND_SPL_KERNEL_OFFS  Offset in NAND where the kernel is 
 stored
 +
 +CONFIG_CMD_SPL_NAND_OFS  Offset in NAND where the parameters area was 
 saved.
 +
 +CONFIG_CMD_SPL_WRITE_SIZESize of the parameters area to be copied
 +
 +CONFIG_SPL_OS_BOOT   Activate Falcon Mode.
 +
 +Function that a board must implement
 +
 +
 +void spl_board_prepare_for_linux(void) : optional
 + Called from SPL before starting the kernel
 +
 +spl_start_uboot() : required
 + Returns 0 if SPL starts the kernel, 1 if U-Boot

minor complaint:

Returns 0 if SPL should start the kernel, ...

 + must be started.
 +
 +
 +Using spl command
 +-
 +
 +spl - SPL configuration
 +
 +Usage:
 +
 +spl export img=atags|fdt [kernel_addr] [initrd_addr] [fdt_addr ]
---^

This comes from 'spl 

Re: [U-Boot] [PATCH v5 1/3] Add README for the Falcon mode

2013-02-12 Thread Stefan Roese
On 12.02.2013 12:48, Andreas Bießmann wrote:

big snip

 The spl export command does not write to a storage media. The user is
 responsible to transfer the gathered information (assembled ATAGS list
 or prepared FDT) from temporary storage in RAM into persistant storage
 after each run of 'spl export'. Unfortunately the position of temporary
 storage can not be predicted nor provided at commandline, it depends
 highly on your system setup and your provided data (ATAGS or FDT).
 However at the end of an succesful 'spl export' run it will print the
 RAM address of temporary storage.
 Now the user have to save the generated BLOB from that printed address
 to the pre-defined address in persistent storage
 (CONFIG_CMD_SPL_NAND_OFS in case of NAND).
 The following example shows how to prepare the data for Falcon Mode on
 twister board with ATAGS BLOB.
 ---8---
 
 Would be nice to have some FDT example too (in future).

I used FDT with SPL already on the a3m071 board. Please take a look at
the README (board/a3m071/README):

...
Preparing Linux image(s) for booting from SPL U-Boot:
-
To boot the Linux kernel from the SPL, the DT blob (fdt) needs to get
prepard/patched first. U-Boot usually inserts some dynamic values into
the DT binary (blob), e.g. autodetected memory size, MAC addresses,
clocks speeds etc. To generate this patched DT blob, you can use
the following command:

1. Load fdt blob to SDRAM:
= tftp 180 a3m071/a3m071.dtb

2. Set bootargs as desired for Linux booting (e.g. flash_mtd):
= run mtdargs addip2 addtty

3. Use fdt commands to patch the DT blob:
= fdt addr 180
= fdt boardsetup
= fdt chosen

4. Display patched DT blob (optional):
= fdt print

5. Save fdt to NOR flash:
= erase fc06 fc07
= cp.b 180 fc06 1
...

So all we need for DT based booting (compared to ATAG booting) is the
fdt command.

Stefano, perhaps you could integrate this into this README as well.

Thanks,
Stefan

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


Re: [U-Boot] [PATCH v3] mx6: Disable Power Down Bit of watchdog

2013-02-12 Thread Stefano Babic
On 07/02/2013 17:45, Fabio Estevam wrote:
 On a mx6qsabresd revision C board with rev1.2 mx6q, the system gets resetted 
 and it is not able to reach the Linux prompt.
 
 Comparing the watchdog behaviour on a revB versus revC board:
 
 - On a mx6qsabresd revB:
 
 U-Boot  reset
 resetting ...
 
 U-Boot 2013.01-10524-g432a3aa-dirty (Feb 07 2013 - 13:34:46)
 
 CPU:   Freescale i.MX6Q rev1.1 at 792 MHz
 Reset cause: WDOG
 ...
 
 - On a mx6qsabresd revC:
 
 U-Boot  reset
 resetting ...
 
 U-Boot 2013.01-10524-g432a3aa-dirty (Feb 07 2013 - 13:34:46)
 
 CPU:   Freescale i.MX6Q rev1.1 at 792 MHz
 Reset cause: POR
 
 So due to revC POR/watchdog circuitry whenever a watchdog occurs, it causes a 
 POR.
 
 Clearing the PDE - Power Down Enable bit of WMCR registers fixes the problem 
 and
 is also safe for all mx6 boards.
 
 Signed-off-by: Fabio Estevam fabio.este...@freescale.com
 ---

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

Best regards,
Stefano Babic


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


Re: [U-Boot] [PATCH v5 1/3] Add README for the Falcon mode

2013-02-12 Thread Andreas Bießmann
Dear Stefan Roese,

On 02/12/2013 01:09 PM, Stefan Roese wrote:
 On 12.02.2013 12:48, Andreas Bießmann wrote:

snip

 3. Use fdt commands to patch the DT blob:
 = fdt addr 180
 = fdt boardsetup
 = fdt chosen
 
 4. Display patched DT blob (optional):
 = fdt print
 
 5. Save fdt to NOR flash:
 = erase fc06 fc07
 = cp.b 180 fc06 1
 ...
 
 So all we need for DT based booting (compared to ATAG booting) is the
 fdt command.

As I understand this guide there is no 'spl export' required for 'Falcon
Mode' with FDT, is that correct?

 Stefano, perhaps you could integrate this into this README as well.

+1

Best regards

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


Re: [U-Boot] [PATCH v3 2/3] Tegra114: fdt: Update DT files with I2C info for T114/Dalmore

2013-02-12 Thread Laxman Dewangan

On Friday 08 February 2013 11:34 PM, Stephen Warren wrote:

On 02/08/2013 10:25 AM, Tom Warren wrote:

T114, like T30, does not have a separate/different DVC (power I2C)
controller like T20 - all 5 I2C controllers are identical, but
I2C5 is used to designate the controller intended for power
control (PWR_I2C in the schematics). PWR_I2C is set to 400KHz.
diff --git a/board/nvidia/dts/tegra114-dalmore.dts 
b/board/nvidia/dts/tegra114-dalmore.dts
+   aliases {
+   };
+

There's no point adding an empty aliases node here. Feel free to fix
that up when you apply it rather than reposting if you want.

I'd like too see Laxman sign-off on the *2 question he had earlier
before actually checking this in.

We do not require *2 as the i2c clock divider is DIVU16 type. There was 
bug in early code on kernel also which we fixed in dowstream long back. 
Possibly uboot have not fixed this yet.


---
This email message is for the sole use of the intended recipient(s) and may 
contain
confidential information.  Any unauthorized review, use, disclosure or 
distribution
is prohibited.  If you are not the intended recipient, please contact the 
sender by
reply email and destroy all copies of the original message.
---
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v5 1/3] Add README for the Falcon mode

2013-02-12 Thread Stefan Roese
On 12.02.2013 13:44, Andreas Bießmann wrote:
 3. Use fdt commands to patch the DT blob:
 = fdt addr 180
 = fdt boardsetup
 = fdt chosen

 4. Display patched DT blob (optional):
 = fdt print

 5. Save fdt to NOR flash:
 = erase fc06 fc07
 = cp.b 180 fc06 1
 ...

 So all we need for DT based booting (compared to ATAG booting) is the
 fdt command.
 
 As I understand this guide there is no 'spl export' required for 'Falcon
 Mode' with FDT, is that correct?

Correct. At least thats how it works on PowerPC. It should work that way
on ARM as well. No need for any spl export commands here.

Thanks,
Stefan

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


Re: [U-Boot] [PATCH 1/6] imx: mx6q DDR3 init: Fix tMRD

2013-02-12 Thread Stefano Babic
On 30/01/2013 22:19, Benoßt Thébaudeau wrote:
 MMDC1_MDCFG1.tMRD should be set to max(tMRD, tMOD) for DDR3.
 
 For all DDR3 speed bins:
   tMRD(min) = 4 nCK
   tMOD(min) = max(12 nCK, 15 ns)
 
 Hence, MMDC1_MDCFG1.tMRD should be set to max(12 nCK, 15 ns), which is 12 nCK
 at 532 MHz, encoded as 0xB in the bit-field MMDC1_MDCFG1[8:5].
 
 Signed-off-by: Benoßt Thébaudeau benoit.thebaud...@advansee.com
 ---
  board/freescale/imx/ddr/mx6q_4x_mt41j128.cfg |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/board/freescale/imx/ddr/mx6q_4x_mt41j128.cfg 
 b/board/freescale/imx/ddr/mx6q_4x_mt41j128.cfg
 index c86cd40..9ac8027 100644
 --- a/board/freescale/imx/ddr/mx6q_4x_mt41j128.cfg
 +++ b/board/freescale/imx/ddr/mx6q_4x_mt41j128.cfg
 @@ -110,7 +110,7 @@ DATA 4 0x021b0018 0x00081740
  
  DATA 4 0x021b001c 0x8000
  DATA 4 0x021b000c 0x555A7975
 -DATA 4 0x021b0010 0xFF538E64
 +DATA 4 0x021b0010 0xFF538F64
  DATA 4 0x021b0014 0x01FF00DB
  DATA 4 0x021b002c 0x26D2
  


Applied (whole series) to u-boot-imx, thanks.

Best regards,
Stefano Babic


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


Re: [U-Boot] [PATCH v3] mx6: Disable Power Down Bit of watchdog

2013-02-12 Thread Stefano Babic
On 07/02/2013 17:45, Fabio Estevam wrote:
 On a mx6qsabresd revision C board with rev1.2 mx6q, the system gets resetted 
 and it is not able to reach the Linux prompt.
 
 Comparing the watchdog behaviour on a revB versus revC board:
 
 - On a mx6qsabresd revB:
 
 U-Boot  reset
 resetting ...
 
 U-Boot 2013.01-10524-g432a3aa-dirty (Feb 07 2013 - 13:34:46)
 
 CPU:   Freescale i.MX6Q rev1.1 at 792 MHz
 Reset cause: WDOG
 ...
 
 - On a mx6qsabresd revC:
 
 U-Boot  reset
 resetting ...
 
 U-Boot 2013.01-10524-g432a3aa-dirty (Feb 07 2013 - 13:34:46)
 
 CPU:   Freescale i.MX6Q rev1.1 at 792 MHz
 Reset cause: POR
 
 So due to revC POR/watchdog circuitry whenever a watchdog occurs, it causes a 
 POR.
 
 Clearing the PDE - Power Down Enable bit of WMCR registers fixes the problem 
 and
 is also safe for all mx6 boards.
 
 Signed-off-by: Fabio Estevam fabio.este...@freescale.com
 ---

Applied to u-boot-imx, thanks.

Best regards,
Stefano Babic


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


Re: [U-Boot] [PATCH v5 1/3] Add README for the Falcon mode

2013-02-12 Thread Stefano Babic
On 12/02/2013 13:44, Andreas Bießmann wrote:
 
 Stefano, perhaps you could integrate this into this README as well.
 
 +1

Right, I will push V6 with changes you suggested and integrating
Stefan's part.

Regards,
Stefano Babic


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


Re: [U-Boot] [PATCH v5 1/3] Add README for the Falcon mode

2013-02-12 Thread Andreas Bießmann
On 02/12/2013 01:52 PM, Stefan Roese wrote:
 On 12.02.2013 13:44, Andreas Bießmann wrote:
 3. Use fdt commands to patch the DT blob:
 = fdt addr 180
 = fdt boardsetup
 = fdt chosen

 4. Display patched DT blob (optional):
 = fdt print

 5. Save fdt to NOR flash:
 = erase fc06 fc07
 = cp.b 180 fc06 1
 ...

 So all we need for DT based booting (compared to ATAG booting) is the
 fdt command.

 As I understand this guide there is no 'spl export' required for 'Falcon
 Mode' with FDT, is that correct?
 
 Correct. At least thats how it works on PowerPC. It should work that way
 on ARM as well. No need for any spl export commands here.

Well, Ok, this changes things a bit. The'spl export' command was
prepared for 'bootm with fdt' to gather the same information as in ATAGS
mode, honestly this was never tested cause Simon Schwarz worked with
ATAGS too. If this is not required to prepare the fdt blob it was a
misunderstanding from the very beginning of that command.
However the README should reflect that the 'spl export' with fdt is
untested and that ppc prepares the fdt blob with the fdt command instead.

Best regards

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


Re: [U-Boot] [PATCH v5 8/8] nand: mxc: Switch NAND SPL to generic SPL

2013-02-12 Thread Benoßt Thébaudeau
Hi Stefano,

On Saturday, February 9, 2013 5:38:26 PM, Benoßt Thébaudeau wrote:
 On Saturday, February 9, 2013 2:53:44 PM, Benoßt Thébaudeau wrote:
  On Saturday, February 9, 2013 12:47:25 AM, Benoßt Thébaudeau wrote:
   On Friday, February 8, 2013 11:49:27 PM, Benoßt Thébaudeau wrote:
Subject: [PATCH v5 8/8] nand: mxc: Switch NAND SPL to generic SPL

Signed-off-by: Benoßt Thébaudeau benoit.thebaud...@advansee.com
---
Changes in v5:
 - Remove spaces between function name and open parenthesis.
 - Fix mx31pdk and tx25 Makefile-s and SPL linker scripts.
 - Remove the useless definition of CONFIG_SPL_LDSCRIPT.
 - Fix the call to nand_boot().

Changes in v4:
 - New patch.

Changes in v3: None
Changes in v2: None
   
   This is now supposed to be working and compile-tested.
   
   Custodians, please review and advise.
   
   Board maintainers, please test.
   
   Tell me if I should split away some stuff.
   
   Should doc/README.arm-relocation be updated, and how since tx25 no longer
   uses
   NAND SPL, which is also deprecated?
   
   Note that mx31pdk and tx25 had been broken by commit
   e05e5de7fae5bec79617e113916dac6631251156. After this commit, for those
   boards,
   _main called board_init_f, which called relocate_code, which unexpectedly
   (for
   their users) returned to nowhere in ctr0.S instead of calling nand_boot.
   Also,
   crt0.S calls nand_boot if CONFIG_SPL_BUILD is not defined but
   CONFIG_NAND_SPL
   is, which is not normal for NAND SPL. Other NAND SPL boards may be broken
   too,
   but that's not too much of an issue since they are supposed to migrate to
   generic SPL.
  
  I am also wondering if board_init_f should not be moved out of
  mxc_nand_spl.c
  to
  either board/lowlevel_init.S or board/board.c. That would make
  mxc_nand_spl.c more generic if for some reason a board needs to do specific
  things. Any opinion?
  
  For the start.S files, since it's not possible to know from
  CONFIG_SPL_BUILD
  and
  CONFIG_NAND_SPL if relocate_code is needed or not, I see the following
  choices:
  1) Let it defined in all cases. It's quite small, so it won't hurt much.
  2) Create a specific SPL #define (e.g. CONFIG_SPL_RELOCATE_CODE) to define
  it
 for generic SPL only if needed.
  3) Just create a specific linker section for it so that it's automatically
 garbage-collected if unneeded.
  Any opinion?
 
 I'm also considering to factorize relocate_code to crt0.S. There's not really
 a
 good reason for it to be depending on each ARM processor. Any opinion?

FYI, I will post soon a v6 with a lot of cleanup.

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


Re: [U-Boot] Fwd: pull request for u-boot-tegra/master into ARM/master

2013-02-12 Thread Albert ARIBAUD
Hi Tom,

On Mon, 11 Feb 2013 14:20:00 -0700, Tom Warren
twarren.nvi...@gmail.com wrote:

 Dropped the list from the PR. Sorry 'bout that.

Applied to u-boot-arm/master, thanks!

 -- Forwarded message --
 From: Tom Warren twarren.nvi...@gmail.com
 Date: Mon, Feb 11, 2013 at 11:05 AM
 Subject: pull request for u-boot-tegra/master into ARM/master
 To: Albert ARIBAUD albert.u.b...@aribaud.net
 Cc: Tom Warren twar...@nvidia.com, Stephen Warren
 swar...@nvidia.com, Simon Glass s...@chromium.org, Wolfgang Denk
 w...@denx.de, Allen Martin amar...@nvidia.com, Lucas Stach
 d...@lynxeye.de
 
 
 Albert,
 
 Please pull u-boot-tegra/master into ARM/master. Thanks!
 
 ./MAKEALL -a arm completed over the weekend w/o any new errors, and
 checkpatch is clean.
 
 The following changes since commit 8978f860a64eecfa088c1088bc0c2002ec316362:
   Tom Rini (1):
 am33xx: Drop gpio0_7_pin_mux from phytec pcm051
 
 are available in the git repository at:
 
   git://git.denx.de/u-boot-tegra master
 
 Allen Martin (8):
   tegra: fdt: add back missing host1x node
   tegra20: fdt: add SPI SFLASH node
   tegra: spi: add fdt support to tegra SPI SFLASH driver
   tegra30: add SBC1 to periph id mapping table
   tegra30: fdt: add SPI SLINK nodes
   tegra: add addresses of SPI SLINK controllers
   tegra: add SPI SLINK driver
   tegra: cardhu: config: enable SPI
 
 Lucas Stach (1):
   arm: fix CONFIG_DELAY_ENVIRONMENT to act like it claims in the README
 
 Stephen Warren (2):
   tegra: rename FUNCMUX_UART2_UARTB
   tegra: don't hard-code LCD into default TEGRA_DEVICE_SETTINGS
 
 Tom Warren (9):
   Tegra: T20: Remove unused 'SLOW' SoC ID and PLLX table entry
   Tegra: Move common clock code to arch/arm/cpu/tegra-common/clock.c
   Tegra114: Add arch-tegra114 include files
   Tegra114: Add AVP (arm720t) files
   Tegra114: Add CPU (armv7) files
   Tegra114: Add common CPU (shared) files
   Tegra114: Dalmore: Add DT files
   Tegra114: Add generic Tegra114 build support
   Tegra114: Add/enable Dalmore build (T114 reference board)
 
  arch/arm/cpu/arm720t/tegra-common/cpu.c   |   78 ++--
  arch/arm/cpu/arm720t/tegra-common/cpu.h   |8 +-
  arch/arm/cpu/arm720t/tegra114/Makefile|   42 ++
  arch/arm/cpu/arm720t/tegra114/config.mk   |   19 +
  arch/arm/cpu/arm720t/tegra114/cpu.c   |  297 +
  arch/arm/cpu/armv7/tegra114/Makefile  |   40 ++
  arch/arm/cpu/armv7/tegra114/config.mk |   19 +
  arch/arm/cpu/tegra-common/Makefile|2 +-
  arch/arm/cpu/tegra-common/ap.c|9 +-
  arch/arm/cpu/tegra-common/board.c |   25 +-
  arch/arm/cpu/tegra-common/clock.c |  560 
  arch/arm/cpu/tegra114-common/Makefile |   41 ++
  arch/arm/cpu/tegra114-common/clock.c  |  655 +++
  arch/arm/cpu/tegra114-common/funcmux.c|   63 ++
  arch/arm/cpu/tegra114-common/pinmux.c |  506 +++
  arch/arm/cpu/tegra20-common/clock.c   |  605 +-
  arch/arm/cpu/tegra20-common/funcmux.c |2 +-
  arch/arm/cpu/tegra30-common/clock.c   |  712 
 -
  arch/arm/dts/tegra114.dtsi|5 +
  arch/arm/dts/tegra20.dtsi |   12 +
  arch/arm/dts/tegra30.dtsi |   72 ++
  arch/arm/include/asm/arch-tegra/clk_rst.h |   58 ++-
  arch/arm/include/asm/arch-tegra/clock.h   |   59 ++-
  arch/arm/include/asm/arch-tegra/gp_padctrl.h  |1 +
  arch/arm/include/asm/arch-tegra/pmc.h |8 +
  arch/arm/include/asm/arch-tegra/tegra.h   |9 +-
  arch/arm/include/asm/arch-tegra/tegra_slink.h |   84 +++
  arch/arm/include/asm/arch-tegra114/clock-tables.h |  402 
  arch/arm/include/asm/arch-tegra114/clock.h|   28 +
  arch/arm/include/asm/arch-tegra114/flow.h |   35 +
  arch/arm/include/asm/arch-tegra114/funcmux.h  |   31 +
  arch/arm/include/asm/arch-tegra114/gp_padctrl.h   |   59 ++
  arch/arm/include/asm/arch-tegra114/gpio.h |   30 +
  arch/arm/include/asm/arch-tegra114/hardware.h |   22 +
  arch/arm/include/asm/arch-tegra114/pinmux.h   |  618 ++
  arch/arm/include/asm/arch-tegra114/pmu.h  |   23 +
  arch/arm/include/asm/arch-tegra114/spl.h  |   22 +
  arch/arm/include/asm/arch-tegra114/tegra.h|   33 +
  arch/arm/include/asm/arch-tegra20/clock-tables.h  |4 +
  arch/arm/include/asm/arch-tegra20/clock.h |4 +
  arch/arm/include/asm/arch-tegra20/funcmux.h   |2 +-
  arch/arm/include/asm/arch-tegra20/tegra.h |2 +
  arch/arm/include/asm/arch-tegra30/clock.h |4 +
  arch/arm/include/asm/arch-tegra30/tegra.h |2 +
  arch/arm/lib/board.c  

Re: [U-Boot] [PATCH v2] build: imx: Fix 'u-boot.imx' build without full OBJTREE reference

2013-02-12 Thread Benoßt Thébaudeau
Dear Otavio, Marek,

On Monday, February 11, 2013 5:55:17 PM, Marek Vasut wrote:
 Dear Otavio Salvador,
 
  When calling 'make u-boot.imx' the build were failing as it were
  expecting the full path for the file; this regression has been
  included by commit 71a988a (imximage.cfg: run files through C
  preprocessor).
  
  The direct references for u-boot.imx were replaced by $(obj) as
  config.mk handles the proper setting of it making it set to $(OBJTREE)
  when required.
  
  The build has been test using:
  
   - ./MAKEALL -s mx5 -s mx6
   - make u-boot.imx
   - make O=/tmp/build
 
 BUILD_DIR=/tmp/xyz MAKEALL please.

Once you're confident with this patch, do you mind if I integrate it as is in my
MXC NAND + SPL series in order to avoid merge conflicts (unless it is applied
before)?

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


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

2013-02-12 Thread Albert ARIBAUD
Hello Tom,

The following changes since commit
3a9d879f6f64585b819af728b53be0a05037fe0d:

  Prepare v2013.01 (2013-01-15 14:47:42 -0700)

are available in the git repository at:

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

for you to fetch changes up to fd8e1c3866578d87ed14a04a59faae341fd415df:

  arm: fix CONFIG_DELAY_ENVIRONMENT to act like it claims in the README
  (2013-02-11 10:35:26 -0700)


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

Allen Martin (13):
  tegra: remove IRDA pinmux synonym
  tegra: fdt: remove clocks nodes
  tegra: fdt: sort dts files
  tegra: fdt: add apbdma node
  fdt: fix dts preprocessor options
  tegra: fdt: add back missing host1x node
  tegra20: fdt: add SPI SFLASH node
  tegra: spi: add fdt support to tegra SPI SFLASH driver
  tegra30: add SBC1 to periph id mapping table
  tegra30: fdt: add SPI SLINK nodes
  tegra: add addresses of SPI SLINK controllers
  tegra: add SPI SLINK driver
  tegra: cardhu: config: enable SPI

Fabio Estevam (4):
  woodburn: Set Write Protection GPIO as input
  mx6qsabre_common: Let mmc partition be board specific
  tools: imximage: Let .name field be more generic
  mxs: Use __weak annotation to simplify code

Javier Martinez Canillas (4):
  OMAP3: use a single board file for IGEP devices
  OMAP3: igep00x0: add boot status GPIO LED
  omap4: allow the use of a plain text env file instead boot scripts
  OMAP3: igep00x0: fix a build warning on IGEP boards

Jeff Lance (1):
  Add DDR3 support for AM335x-EVM (Version 1.5A)

Knut Wohlrab (1):
  mx6qsabreauto: enable USB host interface

Lars Poeschel (3):
  am33xx: add a pulldown macro to pinmux config
  pcm051: Add support for Phytec phyCORE-AM335x
  am335x: display msg when reading MAC from efuse

Lucas Stach (1):
  arm: fix CONFIG_DELAY_ENVIRONMENT to act like it claims in the
README

Marc Dietrich (3):
  tegra: display: add board pinmux
  tegra: enable LCD on PAZ00
  tegra: remove custom TEGRA_DEVICE_SETTINGS for board files

Marek Vasut (14):
  mxs: mmc: Drop unused members from struct mxsmmc_priv
  mxs: ssp: Pull out the SSP bus to regs conversion
  mx23: Add POWER and CLKCTRL register definitions
  mx23: ssp: Fix ssp-regs.h for MX23
  mmc: Limit the number of used SSP ports on MX23
  mxs: Add function to ungate the power block on MX23
  mxs: Linux uses ttyAMA0 as DUART
  mxs: Add MX23 olinuxino board support
  mxs: Boost the memory power supply
  mxs: dma: Fix APBH DMA driver for MX23
  mxs: ssp: Add SSP registers map for MX23
  mxs: mmc: Allow overriding default card detect implementation
  mxs: mmc: Fix the MMC driver for MX23
  mxs: mmc: mx23_olinuxino: Add MMC support

Otavio Salvador (14):
  mxs: clock: Use 'mxs' prefix for methods
  mx23: Add register base addresses
  mx23: Add iomux-mx23.h
  mx23: Add support on print_cpuinfo()
  mx23: Add boot mode description
  mx23: SPL: Add boot mode support
  mx23: SPL: Initialize DDR at 133MHz
  mx23: config: Enable building of u-boot.sb binary
  mx23: config: Enable mxsboot tool for i.MX23 based boards
  mxs: Fix the memory init for MX23
  mxs: Add MX23 quirks into the clock code
  mxs: mmc: Fix MMC reset on iMX23
  mx23_olinuxino: Add default environment
  mx23evk: Add initial board support

Rob Herring (2):
  ARM: add wfi assembly macro
  ARM: highbank: use wfi macro instead of inline asm

Stephen Warren (2):
  tegra: rename FUNCMUX_UART2_UARTB
  tegra: don't hard-code LCD into default TEGRA_DEVICE_SETTINGS

Tetsuyuki Kobayashi (2):
  arm: rmobile: kzm9g: Adjust SDRAM setting
  arm: rmobile: kzm9g: Adjust ETM trace clock

Thierry Reding (3):
  video: tegra: Update line length to match resolution
  tegra: Enable LCD on Medcom-Wide
  tegra: Enable LCD on TEC

Tom Rini (1):
  am33xx: Drop gpio0_7_pin_mux from phytec pcm051

Tom Warren (19):
  Tegra30: Add arch-tegra30 include files
  Tegra30: Add AVP (arm720t) files
  Tegra30: Add CPU (armv7) files
  Tegra30: Add common CPU (shared) files
  Tegra30: Cardhu: Add DT files
  Tegra30: Add generic Tegra30 build support
  Tegra30: Add/enable Cardhu build (T30 reference board)
  Tegra30: clocks: Fix clock tables for I2C and other periphs
  Tegra30: fdt: Update DT files with I2C info for T30/Cardhu
  Tegra30: I2C: Enable I2C driver on Cardhu
  Tegra: T20: Remove unused 'SLOW' SoC ID and PLLX table entry
  Tegra: Move common clock code to arch/arm/cpu/tegra-common/clock.c
  Tegra114: Add arch-tegra114 include files
  Tegra114: Add AVP (arm720t) files
  Tegra114: Add CPU (armv7) files
  Tegra114: Add common CPU (shared) files
  Tegra114: Dalmore: Add DT files
  Tegra114: Add 

Re: [U-Boot] [PATCH v5 8/8] nand: mxc: Switch NAND SPL to generic SPL

2013-02-12 Thread Stefano Babic
On 12/02/2013 14:45, Benoßt Thébaudeau wrote:
 Hi Stefano,
 


 I'm also considering to factorize relocate_code to crt0.S. There's not really
 a
 good reason for it to be depending on each ARM processor. Any opinion?
 
 FYI, I will post soon a v6 with a lot of cleanup.

Ok, thanks.
Stefano


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


Re: [U-Boot] [PATCH 0/5] Add support for using an UBI volume for environment

2013-02-12 Thread Tom Rini
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/11/2013 09:37 PM, Scott Wood wrote:
 On 02/08/2013 02:07:21 PM, Joe Hershberger wrote:
 NAND is not good at handling absolute addresses to sectors for 
 storing particular data.  The current implementation of the NAND 
 env support works around this in several ways such as storing a 
 pointer to the sector in the OOB of the first sector (interferes 
 with some CRC) or supporting a range of sectors (which unless it 
 is huge is not guaranteed to be safe).  None of these options 
 address wear-leveling concerns or bad block handling.
 
 Accessing the u-boot env from UBI eliminates these concerns. 
 However, it does require some of the basic settings for finding 
 the UBI env to be in the default u-boot env.
 
 The downside is this moves us further away from having an 
 environment available before relocation (e.g. loaded by SPL),
 which is important not just for serial config but also hwconfig,
 which can affect how RAM is set up among other things.
 
 Maybe the OOB of first sector approach could be changed to be 
 more like how bad block tables are allocated, with a special
 marker in the env block's own OOB that we scan for.

There's pluses and minuses to throw more stuff in UBI.  So long as
it doesn't break the ability to have env pre-relocation (and it
shouldn't, we already support env in a file), is there a problem here?

Or just hoping to encourage other robust methods?

I think somewhere there's a wishlist for UBI in SPL (for Falcon mode),
for example..

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

iQIcBAEBAgAGBQJRGmf4AAoJENk4IS6UOR1W4IUP/0bcsyrI+ufUPf99ME/bkQq0
NhCP3/DH/CxtXrTzsl4mkPOv/C0ziMmQiGpz58k63ITqSPJL/pAZgVqmy1DwhIB/
u/y2F3IYZTwllw06OykesKd8GlP4+oiQokYDAHywfOzw/SyUI3t4jZCGTR2BOvbt
TWw6XL8Rm7sGi3nWRhFlQt4AfRvdidlzcOFppjrQsf7wS39Ho6ALRs0kSh/pVy7h
MoQcICC/+vRc/qDXV6QKlQ3EHK3+3+/3HKUQiKbsw+hrPJua6Ur8+6PpLS96Qc8F
r7+hnOHS+pPVuoIzOfRBn8+R3LDccPskirFGlT0uHXMpph/nQBohLXFMt0CMe9/9
8CwXyMSckpZdPM+2EeGURqQdJZ/fBL+WJEmke6BUnLdOdw8Ks2PuIGQWonlrsLkq
Q7ZHyqN2RtC9veGadRvKhR8GOZP7bQPLMiIWpThNQQTaSUKKYoUFjlxgcaiLAsoC
grO2S0AIBTQx3D0Vzfrka1shttYBd5vqs85bRt/EZAi5YDMeeSTkc3D/wiZST3bP
q8GNyM6p7QNXMnM0hNgQRZIhw5iStaMohh517h84JN69RkQ4TwRUt8HdJPXnPPHq
F1+gmWLKeJRSSza9uIWsUlU4VTE1vVLo7H3hIq1EigERLdg3Z3g9WirkPuSMYEjX
XuvGODaEQ4wqM6yH1XFQ
=rkT9
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v5 1/3] Add README for the Falcon mode

2013-02-12 Thread Otavio Salvador
On Tue, Feb 12, 2013 at 6:38 AM, Stefano Babic sba...@denx.de wrote:
 Simple howto to add support to a board
 for booting the kernel from SPL (Falcon mode).

 Signed-off-by: Stefano Babic sba...@denx.de
 ---
 Changes in v5:
 - several fixes for the language, rephrasing some unclear parts (Vikram 
 Narayanan)

 Changes in v4:
 - fix capitalization, styling, in spl help (Andreas Biessmann)
 - move CONFIG_SPL_OS_BOOT before function in doc (Andreas Biessmann)

 Changes in v3:
 - parameter initrd_addr was removed in V2 (Andreas Biessmann)
 - added patch to fix help usage for spl export (Andreas Biessmann)
 - Added empty lines (Otavio Salvador)
 - add a more exhaustive description explaining that
   spl export does not save into media (Lukasz Majewski).

 Changes in v2:
 - spelling, language fixes (Andreas Biessman)
 - rewrite some unclear sentences
 - drop CONFIG_SPL_OS_BOOT_KEY
 - make example with twister more exhaustive

  doc/README.falcon |  169 
 +
  1 file changed, 169 insertions(+)
  create mode 100644 doc/README.falcon

 diff --git a/doc/README.falcon b/doc/README.falcon
 new file mode 100644
 index 000..72fe04a
 --- /dev/null
 +++ b/doc/README.falcon
 @@ -0,0 +1,169 @@
 +U-Boot Falcon Mode
 +
 +
 +Introduction
 +
 +
 +This document provides an overview of how to add support for Falcon Mode
 +to a board.
 +Falcon Mode is introduced to speed up the booting process, allowing
 +to boot a Linux kernel (or whatever image) without a full blown U-Boot.

Add a newline after board or move Falcon Mode to same phrase.

 +Falcon Mode relies on the SPL framework. In fact, to make booting faster,
 +U-Boot is split into two parts: the SPL (Secondary Program Loader) and U-Boot
 +image. In most implementations, SPL is used to start U-Boot when booting from
 +a mass storage, such as NAND or SD-Card. SPL has now support for other media,
 +and can generally be seen as a way to start an image performing the minimum
 +required initialization. SPL mainly initializes the RAM controller, and then
 +copies U-Boot image into the memory.

New line.

 The Falcon Mode extends this way
 +allowing to start the Linux kernel directly from SPL. A new command is added
 +to U-Boot to prepare the parameters that SPL must pass to the kernel, using
 +ATAGS or Device Tree.
 +
 +In usual U-Boot systems, these parameters are generated each time before

In usual U-Boot systems

Together with previous phrase and might be clear as: In normal mode, these ...

 +loading the kernel, passing to Linux the address in memory where
 +the parameters can be read.
 +With Falcon Mode, this snapshot can be saved into persistent storage and SPL 
 is
 +informed to load it before running the kernel.
 +
 +To boot the kernel, these steps under a Falcon-aware U-Boot are required:
 +
 +1. Boot the board into U-Boot.
 +Use the spl export command to generate the kernel parameters area or the 
 DT.
 +U-Boot runs as when it boots the kernel, but stops before passing the control
 +to the kernel.
 +
 +2. Save the prepared snapshot into persistent media.
 +The address where to save it must be configured into board configuration
 +file (CONFIG_CMD_SPL_NAND_OFS for NAND).
 +
 +3. Boot the board into Falcon Mode. SPL will load the kernel and copy
 +the parameters which are saved in the persistent area area to the required 
 address.
 +
 +It is required to implement a custom mechanism to select if SPL loads U-Boot
 +or another image.
 +
 +The value of a GPIO is a simple way to operate the selection, as well as
 +reading a character from the SPL console if CONFIG_SPL_CONSOLE is set.
 +
 +Falcon Mode is generally activated by setting CONFIG_SPL_OS_BOOT. This tells
 +SPL that U-Boot is not the only available image that SPL is able to start.
 +
 +Configuration
 +
 +CONFIG_CMD_SPL Enable the spl export command.
 +   The command spl export is then available in U-Boot
 +   mode
 +CONFIG_SYS_SPL_ARGS_ADDR   Address in RAM where the parameters must be
 +   copied by SPL.
 +   In most cases, it is start_of_ram + 0x100
 +
 +CONFIG_SYS_NAND_SPL_KERNEL_OFFSOffset in NAND where the kernel is 
 stored
 +
 +CONFIG_CMD_SPL_NAND_OFSOffset in NAND where the parameters area was 
 saved.
 +
 +CONFIG_CMD_SPL_WRITE_SIZE  Size of the parameters area to be copied
 +
 +CONFIG_SPL_OS_BOOT Activate Falcon Mode.
 +
 +Function that a board must implement
 +
 +
 +void spl_board_prepare_for_linux(void) : optional
 +   Called from SPL before starting the kernel
 +
 +spl_start_uboot() : required
 +   Returns 0 if SPL starts the kernel, 1 if U-Boot
 +   must be started.
 +
 +
 +Using spl command
 +-
 +
 +spl - SPL configuration
 +
 +Usage:
 +
 +spl export img=atags|fdt [kernel_addr] 

Re: [U-Boot] [PATCH] Allow OMAP2 boards to setup GPMC chipselects.

2013-02-12 Thread Tom Rini
On Mon, Feb 11, 2013 at 04:29:03PM +, Mark Jackson wrote:

 Expose the enable_gpmc_cs_config() function so OMAP2 boards can register
 GPMC chipselects.
 
 Signed-off-by: Mark Jackson m...@newflow.co.uk
 ---
  arch/arm/include/asm/arch-am33xx/sys_proto.h |2 ++
  1 file changed, 2 insertions(+)
 
 diff --git a/arch/arm/include/asm/arch-am33xx/sys_proto.h 
 b/arch/arm/include/asm/arch-am33xx/sys_proto.h
 index 588d8de..97ab60d 100644
 --- a/arch/arm/include/asm/arch-am33xx/sys_proto.h
 +++ b/arch/arm/include/asm/arch-am33xx/sys_proto.h
 @@ -35,5 +35,7 @@ void ddr_pll_config(unsigned int ddrpll_M);
   void sdelay(unsigned long);
  void gpmc_init(void);
 +void enable_gpmc_cs_config(const u32 *gpmc_config, struct gpmc_cs *cs, u32 
 base,
 + u32 size);
  void omap_nand_switch_ecc(int);
  #endif

Can you please correct the description?  You're exposing the function
for am33xx not omap2.  Otherwise fine with me, and I assume you need
this on a custom board (aside: the function already exists/is used in
arch/arm/cpu/armv7/am33xx/mem.c).  Are you planning to submit that
support as well?  Thanks!

-- 
Tom


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


Re: [U-Boot] [U-boot]-gdwarf option

2013-02-12 Thread Tom Rini
On Mon, Feb 11, 2013 at 01:43:32PM -0600, Scott Wood wrote:

 On 02/07/2013 02:01:05 AM, tiger...@viatech.com.cn wrote:
 Hi, experts:
 I have a JTAG debugger.
 Its manual suggested user should add -gdwarf-2 option in the arm gcc
 compiler.
 Because it could produce debugging information.
 
 But I searched the whole uboot source package, could not find
 -gdwarf-2 option in config.mk or other files.
 
 Why?
 
 I think it's already the default with most toolchains.  Do you see
 any difference in the output when supplying that flag?

Indeed.  For most common values of gcc versions, using -g will pick the
best choice for debug information and this will be DWARF2 information
already.  There is no need to specify -gdwarf-2 (or similar).

-- 
Tom


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


Re: [U-Boot] [PATCH v2] build: imx: Fix 'u-boot.imx' build without full OBJTREE reference

2013-02-12 Thread Otavio Salvador
On Tue, Feb 12, 2013 at 12:01 PM, Benoßt Thébaudeau
benoit.thebaud...@advansee.com wrote:
 Dear Otavio, Marek,

 On Monday, February 11, 2013 5:55:17 PM, Marek Vasut wrote:
 Dear Otavio Salvador,

  When calling 'make u-boot.imx' the build were failing as it were
  expecting the full path for the file; this regression has been
  included by commit 71a988a (imximage.cfg: run files through C
  preprocessor).
 
  The direct references for u-boot.imx were replaced by $(obj) as
  config.mk handles the proper setting of it making it set to $(OBJTREE)
  when required.
 
  The build has been test using:
 
   - ./MAKEALL -s mx5 -s mx6
   - make u-boot.imx
   - make O=/tmp/build

 BUILD_DIR=/tmp/xyz MAKEALL please.

 Once you're confident with this patch, do you mind if I integrate it as is in 
 my
 MXC NAND + SPL series in order to avoid merge conflicts (unless it is applied
 before)?

Alright; It did the test Marek has requested and it works fine. I
think this should go to imx/master as it fixes a regression.

-- 
Otavio Salvador O.S. Systems
E-mail: ota...@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854  http://projetos.ossystems.com.br
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH v2 2/3] am335x-evm: add support for BeagleBone Black DT name

2013-02-12 Thread Koen Kooi
Signed-off-by: Koen Kooi k...@dominion.thruhere.net
---
 include/configs/am335x_evm.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h
index 2190a7d..951422c 100644
--- a/include/configs/am335x_evm.h
+++ b/include/configs/am335x_evm.h
@@ -86,6 +86,8 @@
findfdt=\
if test $board_name = A335BONE; then  \
setenv fdtfile am335x-bone.dtb; fi;  \
+   if test $board_name = A335BNLT; then  \
+   setenv fdtfile am335x-bonelt.dtb; fi;  \
if test $board_name = A33515BB; then  \
setenv fdtfile am335x-evm.dtb; fi;  \
if test $board_name = A335X_SK; then  \
-- 
1.8.1.2

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


[U-Boot] [PATCH v2 1/3] am335x-evm: enable ext4

2013-02-12 Thread Koen Kooi
The kernel is loaded from an ext4 partition, not ext2 on beaglebone boards.

Signed-off-by: Koen Kooi k...@dominion.thruhere.net
---
 include/configs/am335x_evm.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h
index 72459d8..2190a7d 100644
--- a/include/configs/am335x_evm.h
+++ b/include/configs/am335x_evm.h
@@ -144,6 +144,7 @@
 #define CONFIG_DOS_PARTITION
 #define CONFIG_CMD_FAT
 #define CONFIG_CMD_EXT2
+#define CONFIG_CMD_EXT4
 
 #define CONFIG_SPI
 #define CONFIG_OMAP3_SPI
-- 
1.8.1.2

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


[U-Boot] [RFC] [PATCH] Avoid R_ARM_ABS32 for bss start and end references

2013-02-12 Thread Albert ARIBAUD
This patch is intended to be patch 2/2 of my first patch to remove
R_ARM_ABS32 relocation types from ARM builds.

With this change, the type of ARM references to __bss_start
and __bss_end__ is changed from R_ARM_ABS32 to R_ARM_RELATIVE.
It should have no functional impact, as it only affects the
resolution of references to __bss_start and __bss_end__ before
relocation, and no code should ever perform such references...
so far. References performed after relocation are unchanged by
this patch.

This patch SHOULD NOT BE applied in any official U-boot tree! It is
submitted as an RFC and a request to test.

This patch can only work on ARM; it will not work on any ARM target
that uses another linker script than arch/arm/cpu/u-boot.lds, and it
will not work on any non-ARM target.

HOWEVER, if you can test it on one of these targets, then please do
so by manually patching the appropriate linker script the same way
arch/arm/cpu/u-boot.lds is patched here.

If you are keen on testing but don't know how to patch your linker
script, just let me know which target you intend to test on, and which
linker script you need patched, and I'll do a v2 / v3... of this RFC.

The goal here is to help me ensure the patch works well on enough
targets that I can safely start the tedious work of patching all 150+
linker scripts.
---
 arch/arm/cpu/u-boot.lds |   12 +---
 lib/Makefile|1 +
 lib/bss.c   |   35 +++
 3 files changed, 45 insertions(+), 3 deletions(-)
 create mode 100644 lib/bss.c

diff --git a/arch/arm/cpu/u-boot.lds b/arch/arm/cpu/u-boot.lds
index e6b202b..e1bc8e7 100644
--- a/arch/arm/cpu/u-boot.lds
+++ b/arch/arm/cpu/u-boot.lds
@@ -81,11 +81,17 @@ SECTIONS
*(.mmutable)
}
 
-   .bss __rel_dyn_start (OVERLAY) : {
-   __bss_start = .;
+   .bss_start __rel_dyn_start (OVERLAY) : {
+   KEEP(*(.__bss_start));
+   }
+
+   .bss __bss_start (OVERLAY) : {
*(.bss*)
 . = ALIGN(4);
-   __bss_end__ = .;
+___bssend___ = .;
+   }
+   .bss_end ___bssend___ (OVERLAY) : {
+   KEEP(*(.__bss_end__));
}
 
/DISCARD/ : { *(.dynstr*) }
diff --git a/lib/Makefile b/lib/Makefile
index 86ca1a6..73ee160 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -25,6 +25,7 @@ include $(TOPDIR)/config.mk
 
 LIB= $(obj)libgeneric.o
 
+COBJS-y += bss.o
 ifndef CONFIG_SPL_BUILD
 COBJS-$(CONFIG_ADDR_MAP) += addr_map.o
 COBJS-$(CONFIG_BCH) += bch.o
diff --git a/lib/bss.c b/lib/bss.c
new file mode 100644
index 000..5678f30
--- /dev/null
+++ b/lib/bss.c
@@ -0,0 +1,35 @@
+/*
+ * Copyright 2013 Albert ARIBAUD albert.u.b...@aribaud.net
+ * 
+ * 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
+ */
+
+/**
+ * These two symbols are declared in a C file so that the linker
+ * uses R_ARM_RELATIVE relocation, rather than the R_ARM_ABS32 one
+ * it would use if the symbols were defined in the linker file.
+ * Using only R_ARM_RELATIVE relocation ensures that references to
+ * the symbols are correct after as well as before relocation.
+ * 
+ * As the symbols do not require any content, and as we cannot define
+ * them as 'void', we go for the next best thing, 'struct {}'.
+ */
+
+struct {} __bss_start __attribute__((used,section(.__bss_start)));
+struct {} __bss_end__ __attribute__((used,section(.__bss_end__)));
-- 
1.7.10.4

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


Re: [U-Boot] [PATCH v2 1/2] Tegra: fdt: Add/enhance sdhci (mmc) nodes for all T20 DT files

2013-02-12 Thread Tom Warren
Thierry,

On Tue, Feb 12, 2013 at 3:53 AM, Thierry Reding
thierry.red...@avionic-design.de wrote:
 On Tue, Feb 12, 2013 at 11:41:09AM +0100, Thierry Reding wrote:
 On Tue, Feb 12, 2013 at 07:51:55AM +0100, Thierry Reding wrote:
  On Mon, Feb 11, 2013 at 12:21:59PM -0700, Tom Warren wrote:
   Thierry/Lucas,
  
   On Mon, Feb 11, 2013 at 12:11 PM, Thierry Reding
   thierry.red...@avionic-design.de wrote:
On Mon, Feb 11, 2013 at 10:56:33AM -0700, Tom Warren wrote:
Lucas,
   
On Mon, Feb 11, 2013 at 10:28 AM, Lucas Stach d...@lynxeye.de wrote:
 Hi Tom,

 Am Montag, den 11.02.2013, 10:17 -0700 schrieb Tom Warren:
 Linux dts files were used for those boards that didn't already
 have sdhci info populated. Tamonten has their own dtsi file with
 common sdhci nodes (sourced from Linux).

 Signed-off-by: Tom Warren twar...@nvidia.com
 ---
 v2:
 - cleanup comments in dts files/match w/kernel files
 - add sdhci aliases in all dts files
 - use tegra20-tamonten.dtsi from the kernel for AD boards

  arch/arm/dts/tegra20-tamonten.dtsi   |  489 
 ++

 I'm not sure if pushing the whole file in this patch is the right 
 thing
 to do.
   
I didn't want to edit it since we seem to be moving towards using the
Linux DTS files in toto in U-Boot (as per Stephen  Simon). Does it do
any harm to have the whole thing here? Saves some work later. Thierry
- what do you think?
   
Given that it isn't used anywhere I don't think we really need it right
now. We can always add it later when we can make better use of it.
  
   It actually is used (for SDMMC/sdhci) now, Thierry. That's why it's in
   this patchset.
 
  Right, I hadn't looked at that patch yet.
 
   I had originally put the sdhci node for Avionic Design
   boards in their respective .dts files, but Stephen pointed out that
   the kernel had a tegra20-tamonten.dtsi file with common info, which
   included the sdhci node, and asked that I use it, instead, so we echo
   the kernel layout. So I pulled that file into my MMC DT patchset, and
   used it in all AD board builds (medcom/tec/plutux) - it's pulled in
   via an override of CONFIG_ARCH_DEVICE_TREE in the config files.
  
   So the options seem to be:
  
   a) Don't use the tamonton dtsi file, and put the sdhci nodes in the AD
   dts files, just like all other boards (this was my V1 approach).
   Vetoed by Stephen.
   b) Use tegra20-tamonten.dtsi as is, identical to the kernel file. If
   necessary, I can move it's inclusion to a separate patch, independent
   of the MMC DT patchset, as suggested by Lucas.
   c) Use tegra20-tamonten.dtsi, but just with the sdhci node (is this
   what you're suggesting, Thierry?). I'd still pull it in via a
   CONFIG_ARCH_DEVICE_TREE #define in the AD config files.
  
   Let me know ASAP - I'd like to get V3 upstreamed soon so I can move on
   to work on the T30/T114 MMC patches.
 
  I think option b) sounds fine given that we want to move to the same DTS
  as the kernel eventually anyway. So for the Tamonten (and AD board)
  pieces, consider this:
 
  Acked-by: Thierry Reding thierry.red...@avionic-design.de
 
  I can't give you a Tested-by because I have a bunch of other things to
  take care of and I probably won't get to testing this for a few days.

 So it turned out that I need to touch U-Boot anyway, so I decided to
 give this a spin. I noticed that overriding CONFIG_ARCH_DEVICE_TREE from
 the board configuration file doesn't work currently. What happens is
 that the autoconf.mk (which is derived from the board configuration) is
 included before the CPU config.mk which sets CONFIG_ARCH_DEVICE_TREE to
 tegra20 (or tegra30, tegra114). I came up with the attached patch to set
 the variable if not set previously (by the board configuration file).

 Feel free to squash that in your patch series if you deem it a proper
 solution. I can also provide a proper separate patch if you prefer.

 Thierry

 diff --git a/arch/arm/cpu/armv7/tegra114/config.mk 
 b/arch/arm/cpu/armv7/tegra114/config.mk
 index cb1a19d..e7c22c0 100644
 --- a/arch/arm/cpu/armv7/tegra114/config.mk
 +++ b/arch/arm/cpu/armv7/tegra114/config.mk
 @@ -16,4 +16,4 @@
  # You should have received a copy of the GNU General Public License
  # along with this program.  If not, see http://www.gnu.org/licenses/.
  #
 -CONFIG_ARCH_DEVICE_TREE := tegra114
 +CONFIG_ARCH_DEVICE_TREE ?= tegra114
 diff --git a/arch/arm/cpu/armv7/tegra20/config.mk 
 b/arch/arm/cpu/armv7/tegra20/config.mk
 index 6432e75..9042664 100644
 --- a/arch/arm/cpu/armv7/tegra20/config.mk
 +++ b/arch/arm/cpu/armv7/tegra20/config.mk
 @@ -23,4 +23,4 @@
  # Foundation, Inc., 59 Temple Place, Suite 330, Boston,
  # MA 02111-1307 USA
  #
 -CONFIG_ARCH_DEVICE_TREE := tegra20
 +CONFIG_ARCH_DEVICE_TREE ?= tegra20
 diff --git a/arch/arm/cpu/armv7/tegra30/config.mk 
 b/arch/arm/cpu/armv7/tegra30/config.mk
 index 719ca81..0035bc5 

Re: [U-Boot] [PATCH v3 2/3] Tegra114: fdt: Update DT files with I2C info for T114/Dalmore

2013-02-12 Thread Tom Warren
Laxman,

On Tue, Feb 12, 2013 at 5:02 AM, Laxman Dewangan ldewan...@nvidia.com wrote:
 On Friday 08 February 2013 11:34 PM, Stephen Warren wrote:

 On 02/08/2013 10:25 AM, Tom Warren wrote:

 T114, like T30, does not have a separate/different DVC (power I2C)
 controller like T20 - all 5 I2C controllers are identical, but
 I2C5 is used to designate the controller intended for power
 control (PWR_I2C in the schematics). PWR_I2C is set to 400KHz.
 diff --git a/board/nvidia/dts/tegra114-dalmore.dts
 b/board/nvidia/dts/tegra114-dalmore.dts
 +   aliases {
 +   };
 +

 There's no point adding an empty aliases node here. Feel free to fix
 that up when you apply it rather than reposting if you want.

 I'd like too see Laxman sign-off on the *2 question he had earlier
 before actually checking this in.

 We do not require *2 as the i2c clock divider is DIVU16 type. There was bug
 in early code on kernel also which we fixed in dowstream long back. Possibly
 uboot have not fixed this yet.
Yeah, the Tegra I2C driver in U-Boot has always doubled the rate
before calling the clock set routine. But the important thing is that
the actual I2C clock is 100KHz (or 400KHz for I2C5) as measured at the
test points on the board.

I'll look into the Tegra U-Boot clock routine idiosyncrasies later
when I get some more bandwidth.

Thanks,

Tom

 ---
 This email message is for the sole use of the intended recipient(s) and may
 contain
 confidential information.  Any unauthorized review, use, disclosure or
 distribution
 is prohibited.  If you are not the intended recipient, please contact the
 sender by
 reply email and destroy all copies of the original message.
 ---
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH v2 3/3] am335x-evm: switch to DT boot

2013-02-12 Thread Koen Kooi
The findfdt method is being used to locate the right .dtb for the board and 
load it from /boot.

Signed-off-by: Koen Kooi k...@dominion.thruhere.net
---
 include/configs/am335x_evm.h | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h
index 951422c..67f04c4 100644
--- a/include/configs/am335x_evm.h
+++ b/include/configs/am335x_evm.h
@@ -79,7 +79,7 @@
loaduimage=ext2load mmc ${mmcdev}:2 ${loadaddr} ${bootfile}\0 \
mmcboot=echo Booting from mmc ...;  \
run mmcargs;  \
-   bootm ${loadaddr}\0 \
+   bootm ${loadaddr} - ${fdtaddr}\0 \
ramboot=echo Booting from ramdisk ...;  \
run ramargs;  \
bootm ${loadaddr}\0 \
@@ -93,7 +93,9 @@
if test $board_name = A335X_SK; then  \
setenv fdtfile am335x-evmsk.dtb; fi\0 \
 
+
 #define CONFIG_BOOTCOMMAND \
+   run findfdt;  \
mmc dev ${mmcdev}; if mmc rescan; then  \
echo SD/MMC found on device ${mmcdev}; \
if run loadbootenv; then  \
@@ -105,6 +107,7 @@
run uenvcmd; \
fi; \
if run loaduimage; then  \
+   ext2load mmc ${mmcdev}:2 ${fdtaddr} /boot/${fdtfile}; 
 \
run mmcboot; \
fi; \
fi; \
-- 
1.8.1.2

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


Re: [U-Boot] [PATCH v2] build: imx: Fix 'u-boot.imx' build without full OBJTREE reference

2013-02-12 Thread Benoßt Thébaudeau
Hi Otavio,

On Tuesday, February 12, 2013 6:09:43 PM, Otavio Salvador wrote:
 On Tue, Feb 12, 2013 at 12:01 PM, Benoßt Thébaudeau
 benoit.thebaud...@advansee.com wrote:
  Dear Otavio, Marek,
 
  On Monday, February 11, 2013 5:55:17 PM, Marek Vasut wrote:
  Dear Otavio Salvador,
 
   When calling 'make u-boot.imx' the build were failing as it were
   expecting the full path for the file; this regression has been
   included by commit 71a988a (imximage.cfg: run files through C
   preprocessor).
  
   The direct references for u-boot.imx were replaced by $(obj) as
   config.mk handles the proper setting of it making it set to $(OBJTREE)
   when required.
  
   The build has been test using:
  
- ./MAKEALL -s mx5 -s mx6
- make u-boot.imx
- make O=/tmp/build
 
  BUILD_DIR=/tmp/xyz MAKEALL please.
 
  Once you're confident with this patch, do you mind if I integrate it as is
  in my
  MXC NAND + SPL series in order to avoid merge conflicts (unless it is
  applied
  before)?
 
 Alright; It did the test Marek has requested and it works fine. I
 think this should go to imx/master as it fixes a regression.

OK. I include it into my series so that patches apply fine whether Stefano
applies it alone first or from my series.

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


Re: [U-Boot] [PATCH] i.MX6Q: mx6qsabre*: Configure to allow CONFIG_SYS_ALT_MEMTEST

2013-02-12 Thread Stefano Babic
On 01/02/2013 19:08, Eric Nelson wrote:
 In order to use the more thorough memory test, the macro
 CONFIG_SYS_MEMTEST_SCRATCH must be defined with a usable
 address.
 
 Signed-off-by: Eric Nelson eric.nel...@boundarydevices.com
 ---


Applied to u-boot-imx, thanks.

Best regards,
Stefano Babic


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


Re: [U-Boot] [PATCH 3/3] mx23evk: Turn on caches

2013-02-12 Thread Stefano Babic
On 28/01/2013 12:41, Fabio Estevam wrote:
 It is safe to turn on data and instruction caches for mx23.
 
 Signed-off-by: Fabio Estevam fabio.este...@freescale.com
 ---

Applied to u-boot-imx, thanks.

Best regards,
Stefano Babic



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


Re: [U-Boot] [PATCH 2/3] mx23evk: Remove CONFIG_SYS_BAUDRATE_TABLE

2013-02-12 Thread Stefano Babic
On 28/01/2013 12:41, Fabio Estevam wrote:
 The baudrate is already defined by CONFIG_BAUDRATE and there is no need
 to keep CONFIG_SYS_BAUDRATE_TABLE.
 
 Signed-off-by: Fabio Estevam fabio.este...@freescale.com
 ---

Applied to u-boot-imx, thanks.

Best regards,
Stefano Babic


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


Re: [U-Boot] [PATCH v2] build: imx: Fix 'u-boot.imx' build without full OBJTREE reference

2013-02-12 Thread Stefano Babic
On 12/02/2013 18:55, Benoßt Thébaudeau wrote:
 Hi Otavio,
 

Hi BenoĂźt,


 Alright; It did the test Marek has requested and it works fine. I
 think this should go to imx/master as it fixes a regression.
 
 OK. I include it into my series so that patches apply fine whether Stefano
 applies it alone first or from my series.

I merged it - you do not need to bother about it.

Best regards,
Stefano


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


Re: [U-Boot] [PATCH 2/2] Tegra: MMC: Add DT support to MMC driver for all T20 boards

2013-02-12 Thread Simon Glass
Hi Stephen,

On Tue, Feb 5, 2013 at 12:03 PM, Stephen Warren swar...@wwwdotorg.org wrote:
 On 02/04/2013 04:48 PM, Tom Warren wrote:
 tegra_mmc_init() now uses DT info for bus width, WP/CD GPIOs, etc.
 Tested on Seaboard, fully functional.

 diff --git a/board/compal/paz00/paz00.c b/board/compal/paz00/paz00.c
 index 1447f47..5cee91a 100644
 --- a/board/compal/paz00/paz00.c
 +++ b/board/compal/paz00/paz00.c
 @@ -55,18 +55,18 @@ static void pin_mux_mmc(void)
  /* this is a weak define that we are overriding */
  int board_mmc_init(bd_t *bd)
  {
 - debug(board_mmc_init called\n);
 + debug(%s called\n, __func__);

   /* Enable muxes, etc. for SDMMC controllers */
   pin_mux_mmc();

 - debug(board_mmc_init: init eMMC\n);
 - /* init dev 0, eMMC chip, with 8-bit bus */
 - tegra_mmc_init(0, 8, -1, -1);
 + debug(%s: init eMMC\n, __func__);
 + /* init dev 0, eMMC chip */
 + tegra_mmc_init(0);

 - debug(board_mmc_init: init SD slot\n);
 - /* init dev 3, SD slot, with 4-bit bus */
 - tegra_mmc_init(3, 4, GPIO_PV1, GPIO_PV5);
 + debug(%s: init SD slot\n, __func__);
 + /* init dev 3, SD slot */
 + tegra_mmc_init(3);

   return 0;
  }

 That doesn't look right. The board code still has knowledge of which
 SDHCI controllers are in use by the board. Instead, the board should
 just call tegra_mmc_init() with no parameters at all, and the MMC driver
 should scan the device tree for all present-and-enabled SDHCI nodes, and
 instantiate a U-Boot SDHCI device. Without this, the device tree isn't
 in control of the whole process, so there's little point doing the
 conversion; a new board couldn't be supported /just/ by creating a new
 device tree file.

Agreed.


 diff --git a/drivers/mmc/tegra_mmc.c b/drivers/mmc/tegra_mmc.c

 +#ifndef CONFIG_OF_CONTROL
 +#error Please enable device tree support to use this driver
 +#endif

 So CONFIG_OF_CONTROL must be enabled ...


  static void tegra_get_setup(struct mmc_host *host, int dev_index)
  {
 - debug(tegra_get_setup: dev_index = %d\n, dev_index);
 + debug(%s: dev_index = %d\n, __func__, dev_index);
 +
 +#ifdef CONFIG_OF_CONTROL

 ... so there's no need for that ifdef

 + int count, node = 0;
 + int node_list[MAX_HOSTS];
 +
 + count = fdtdec_find_aliases_for_id(gd-fdt_blob, sdmmc,
 + COMPAT_NVIDIA_TEGRA20_SDMMC, node_list, MAX_HOSTS);
 + debug(%s: count of nodes is %d\n, __func__, count);
 +
 + if (count  dev_index) {
 + printf(%s: device index %d exceeds node count (%d)!\n,
 + __func__, dev_index, count);
 + return;
 + }

 This requires that an alias exist in order for the SDHCI node to be
 found/processed. This isn't correct; the SDHCI nodes must be enumerated
 themselves, and then the aliases (if any are present) provide a naming
 hint for them, but even without aliases, the SDHCI nodes must be processed.

I believe this is quite incorrect. Please take a look at the function,
which deals with aliases if they are present, but works in any case.
There is a test in fdtdec_test.c which handles the cases that we
discussed at the time. Quite a bit of effort went into this function
at the time.

So I believe this function should always be used when enumerating
multiple devices. If there is a bug in the function, let's find out
what it is and fix it, and add a new test.


 + /*
 +  * NOTE: mmc-bus_width is determined by mmc.c dynamically.
 +  * Should we override it with this value?
 +  */
 + host-width = fdtdec_get_int(gd-fdt_blob, node, bus-width, 0);
 + if (!host-width)
 + debug(%s: no sdmmc width found\n, __func__);

 It should be possible to inform the MMC core of the width of the bus in
 terms of wires on the PCB. It should only probe the connected device up
 to that width. If that feature is missing, it can be added later though,
 outside the scope of this patch set.

 You didn't Cc the MMC maintainer; they should be Cc'd since this code is
 in drivers/mmc/.
 ___
 U-Boot mailing list
 U-Boot@lists.denx.de
 http://lists.denx.de/mailman/listinfo/u-boot


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


Re: [U-Boot] [PATCH 2/2] Tegra: MMC: Add DT support to MMC driver for all T20 boards

2013-02-12 Thread Simon Glass
Hi,

On Tue, Feb 5, 2013 at 1:02 PM, Tom Warren twarren.nvi...@gmail.com wrote:
 Stephen,

 On Tue, Feb 5, 2013 at 1:03 PM, Stephen Warren swar...@wwwdotorg.org wrote:
 On 02/04/2013 04:48 PM, Tom Warren wrote:
 tegra_mmc_init() now uses DT info for bus width, WP/CD GPIOs, etc.
 Tested on Seaboard, fully functional.

 diff --git a/board/compal/paz00/paz00.c b/board/compal/paz00/paz00.c
 index 1447f47..5cee91a 100644
 --- a/board/compal/paz00/paz00.c
 +++ b/board/compal/paz00/paz00.c
 @@ -55,18 +55,18 @@ static void pin_mux_mmc(void)
  /* this is a weak define that we are overriding */
  int board_mmc_init(bd_t *bd)
  {
 - debug(board_mmc_init called\n);
 + debug(%s called\n, __func__);

   /* Enable muxes, etc. for SDMMC controllers */
   pin_mux_mmc();

 - debug(board_mmc_init: init eMMC\n);
 - /* init dev 0, eMMC chip, with 8-bit bus */
 - tegra_mmc_init(0, 8, -1, -1);
 + debug(%s: init eMMC\n, __func__);
 + /* init dev 0, eMMC chip */
 + tegra_mmc_init(0);

 - debug(board_mmc_init: init SD slot\n);
 - /* init dev 3, SD slot, with 4-bit bus */
 - tegra_mmc_init(3, 4, GPIO_PV1, GPIO_PV5);
 + debug(%s: init SD slot\n, __func__);
 + /* init dev 3, SD slot */
 + tegra_mmc_init(3);

   return 0;
  }

 That doesn't look right. The board code still has knowledge of which
 SDHCI controllers are in use by the board. Instead, the board should
 just call tegra_mmc_init() with no parameters at all, and the MMC driver
 should scan the device tree for all present-and-enabled SDHCI nodes, and
 instantiate a U-Boot SDHCI device. Without this, the device tree isn't
 in control of the whole process, so there's little point doing the
 conversion; a new board couldn't be supported /just/ by creating a new
 device tree file.

 diff --git a/drivers/mmc/tegra_mmc.c b/drivers/mmc/tegra_mmc.c

 +#ifndef CONFIG_OF_CONTROL
 +#error Please enable device tree support to use this driver
 +#endif

 So CONFIG_OF_CONTROL must be enabled ...


  static void tegra_get_setup(struct mmc_host *host, int dev_index)
  {
 - debug(tegra_get_setup: dev_index = %d\n, dev_index);
 + debug(%s: dev_index = %d\n, __func__, dev_index);
 +
 +#ifdef CONFIG_OF_CONTROL

 ... so there's no need for that ifdef

 I took Allen's recent SPI/SLINK driver(s) as an example, but as you
 point out, if CONFIG_OF_CONTROL isn't enabled, you get build errors
 anyway.


 + int count, node = 0;
 + int node_list[MAX_HOSTS];
 +
 + count = fdtdec_find_aliases_for_id(gd-fdt_blob, sdmmc,
 + COMPAT_NVIDIA_TEGRA20_SDMMC, node_list, MAX_HOSTS);
 + debug(%s: count of nodes is %d\n, __func__, count);
 +
 + if (count  dev_index) {
 + printf(%s: device index %d exceeds node count (%d)!\n,
 + __func__, dev_index, count);
 + return;
 + }

 This requires that an alias exist in order for the SDHCI node to be
 found/processed. This isn't correct; the SDHCI nodes must be enumerated
 themselves, and then the aliases (if any are present) provide a naming
 hint for them, but even without aliases, the SDHCI nodes must be processed.
 Again, I used Allen's SLINK driver for as a template here. In fact, it
 looks like our I2C and SPI/SLINK drivers do this, as well as the
 Exynos SPI and S3C24x0 I2C driver all do this.  Can you point out a
 U-Boot driver that does it the right way (preferably with more than 1
 node, like MMC)? I can take a look at that code to use as an example
 of what you're proposing above.

You have it correct already. Stephen please take another look and let
me know what problem you see with this approach. I'm very sorry that I
am so late to this discussion.


 + /*
 +  * NOTE: mmc-bus_width is determined by mmc.c dynamically.
 +  * Should we override it with this value?
 +  */
 + host-width = fdtdec_get_int(gd-fdt_blob, node, bus-width, 0);
 + if (!host-width)
 + debug(%s: no sdmmc width found\n, __func__);

 It should be possible to inform the MMC core of the width of the bus in
 terms of wires on the PCB. It should only probe the connected device up
 to that width. If that feature is missing, it can be added later though,
 outside the scope of this patch set.

 You didn't Cc the MMC maintainer; they should be Cc'd since this code is
 in drivers/mmc/.

 Thanks, added Andy Fleming to CC.

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

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


Re: [U-Boot] [PATCH 0/5] Add support for using an UBI volume for environment

2013-02-12 Thread Scott Wood

On 02/12/2013 10:04:09 AM, Tom Rini wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/11/2013 09:37 PM, Scott Wood wrote:
 On 02/08/2013 02:07:21 PM, Joe Hershberger wrote:
 NAND is not good at handling absolute addresses to sectors for
 storing particular data.  The current implementation of the NAND
 env support works around this in several ways such as storing a
 pointer to the sector in the OOB of the first sector (interferes
 with some CRC) or supporting a range of sectors (which unless it
 is huge is not guaranteed to be safe).  None of these options
 address wear-leveling concerns or bad block handling.

 Accessing the u-boot env from UBI eliminates these concerns.
 However, it does require some of the basic settings for finding
 the UBI env to be in the default u-boot env.

 The downside is this moves us further away from having an
 environment available before relocation (e.g. loaded by SPL),
 which is important not just for serial config but also hwconfig,
 which can affect how RAM is set up among other things.

 Maybe the OOB of first sector approach could be changed to be
 more like how bad block tables are allocated, with a special
 marker in the env block's own OOB that we scan for.

There's pluses and minuses to throw more stuff in UBI.  So long as
it doesn't break the ability to have env pre-relocation (and it
shouldn't, we already support env in a file), is there a problem here?

Or just hoping to encourage other robust methods?


The latter.

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


Re: [U-Boot] [PATCH v3 2/3] Tegra114: fdt: Update DT files with I2C info for T114/Dalmore

2013-02-12 Thread Stephen Warren
On 02/12/2013 10:40 AM, Tom Warren wrote:
 Laxman,
 
 On Tue, Feb 12, 2013 at 5:02 AM, Laxman Dewangan ldewan...@nvidia.com wrote:
 On Friday 08 February 2013 11:34 PM, Stephen Warren wrote:

 On 02/08/2013 10:25 AM, Tom Warren wrote:

 T114, like T30, does not have a separate/different DVC (power I2C)
 controller like T20 - all 5 I2C controllers are identical, but
 I2C5 is used to designate the controller intended for power
 control (PWR_I2C in the schematics). PWR_I2C is set to 400KHz.
 diff --git a/board/nvidia/dts/tegra114-dalmore.dts
 b/board/nvidia/dts/tegra114-dalmore.dts
 +   aliases {
 +   };
 +

 There's no point adding an empty aliases node here. Feel free to fix
 that up when you apply it rather than reposting if you want.

 I'd like too see Laxman sign-off on the *2 question he had earlier
 before actually checking this in.

 We do not require *2 as the i2c clock divider is DIVU16 type. There was bug
 in early code on kernel also which we fixed in dowstream long back. Possibly
 uboot have not fixed this yet.

 Yeah, the Tegra I2C driver in U-Boot has always doubled the rate
 before calling the clock set routine.

Perhaps it's related to some dividers being U7.1 (i.e. the LSB of the
divider represents 1/2 not 1)? However, as Laxman points out, this isn't
the case for I2C clocks; they have a U16 divider, so the LSB represents
1 not 1/2.

 But the important thing is that
 the actual I2C clock is 100KHz (or 400KHz for I2C5) as measured at the
 test points on the board.
 
 I'll look into the Tegra U-Boot clock routine idiosyncrasies later
 when I get some more bandwidth.

Just a few minutes of investigation points at clk_get_divider() being buggy.

It assumes that all dividers have a built-in *2 clock multiplier on the
front of them:

u64 divider = parent_rate * 2;

(the name for that variable is wrong; it should be something more like
parent_rate or divider_input_rate)

This (presence of a *2 pre-multiplier) is true for U7.1 dividers, since
this is required for the LSB of the divider to represent 1/2 not 1.
Hence, I assume that e.g. the SPI driver doesn't do this * 2 on the
clock rate; it actually has a U7.1 divider.

However, this is not true for U16 dividers, since the HW doesn't need to
multiply up the rate before dividing, since the LSB is 1 not 1/2.

The solution here is to fix clk_get_divider() to return both a field
width and a flag (or width) indicating whether a fractional part of the
divider is present, and then pass that on to adjust_periph_pll() so that
it can only optionally perform this initial * 2.

So at least that explains it.

I would strongly recommend just fixing this now. However, if you don't
please do file a bug so that we don't forget about this.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v2 2/3] Tegra114: fdt: Update DT files with I2C info for T114/Dalmore

2013-02-12 Thread Simon Glass
Hi Stephen,

On Thu, Feb 7, 2013 at 10:17 AM, Stephen Warren swar...@wwwdotorg.org wrote:
 On 02/07/2013 09:14 AM, Tom Warren wrote:
 Stephen,

 On Wed, Feb 6, 2013 at 5:00 PM, Stephen Warren swar...@wwwdotorg.org wrote:
 On 02/06/2013 04:26 PM, Tom Warren wrote:
 Note that T114 does not have a separate/different DVC (power I2C)
 controller like T20 - all 5 I2C controllers are identical, but
 I2C5 is used to designate the controller intended for power
 control (PWR_I2C in the schematics).

 diff --git a/arch/arm/dts/tegra114.dtsi b/arch/arm/dts/tegra114.dtsi

 + tegra_car: clock@60006000 {
 + compatible = nvidia,tegra114-car, nvidia,tegra30-car;

 Only the Tegra114 value should be listed here; the presence of the
 Tegra30 value in the upstream kernel is a mistake that will be fixed as
 part of the Tegra114 clock driver patches.

 OK. But this is why I think hewing to the Linux DT files, while
 laudable, is a time sink. Though since T114 is so new  still settling
 in, I guess some churn is expected.

 The issue here is not about making U-Boot fall in line with the kernel.
 The issue is making the device tree in U-Boot be correct. Right now, the
 kernel happens to have the most correct device tree, so it's a good
 reference for U-Boot.

 + i2c@7000c000 {
 + compatible = nvidia,tegra114-i2c, nvidia,tegra20-i2c;

 Same here; only include the Tegra114 value since the HW isn't 100%
 compatible with the Tegra20 HW.

 What does the 'compatible' designater mean, exactly? Does it require
 100% identical HW? Compatible, in a SW/HW sense, to me means that
 newer SW will work with older/similar (but not exactly the same) HW,
 etc.

 The idea here is that the first entry in compatible always defines the
 most specific implementation identification possible. So, compatible
 will at least contain:

 Tegra20: nvidia,tegra20-i2c
 Tegra30: nvidia,tegra30-i2c
 Tegra114: nvidia,tegra114-i2c

 Now, if a piece of newer hardware can be operated 100% correctly
 (ignoring issues due to new features not being exposed, or operating at
 degraded performance) by a driver that only knows about the older
 hardware, then the compatible property can additionally contain other
 values indicating what HW it is compatible with. So, we actually end up
 with:

 Tegra20: nvidia,tegra20-i2c
 Tegra30: nvidia,tegra30-i2c nvidia,tegra20-i2c
 Tegra114: nvidia,tegra114-i2c

 Tegra114 I2C HW isn't marked as compatible with either Tegra20 or
 Tegra30, because the clock divider programming must be different.

 Tegra U-Boot uses the tegra20-i2c name to find and load the I2C
 driver. I could add a new entry in the compat-names table for
 tegra114-i2c,

 Yes, that is the way to go. The driver should include a list of all the
 different compatible values that it supports.

 but I still don't think there's enough difference
 between T20/T30 and T114 I2C to justify a whole new I2C driver - so
 far, it's just one register with a new clk divider that has to be
 taken in consideration when programming the clock source divider.

 But that's required to operate the hardware correctly. It doesn't matter
 how trivial the difference is; it could just be a single bit that needs
 to be set/cleared on new HW - there would still be a difference that
 would otherwise make the HW operate incorrectly.

 I could do as the driver does for T20, where there is a separate DVC
 controller, plus 3 normal I2C controllers. I could 'find_aliases' for
 the tegrat114-i2c controller first,  process its nodes, and return. If
 no tegrat114-i2c exists, the driver would continue on to look for
 tegra20-i2c/tegra20-dvc controller info as it does now.  It'd still be
 one tegra_i2c.c driver, with a flag in the i2c_bus struct telling me
 if I found T114 I2C HW (i2c_bus-single_clk, etc.) and I could then do
 the new clock divider dance based on that flag. How does that sound?

 The U-Boot function that returns the list of devices supported by the
 driver should be enhanced so that it can search for nodes compatible
 with any 1 (or more) of n compatible values at a time, rather than just
 a single compatible value. Then, all you'd have to do with this change
 is add a new entry into the table, not add extra code that calls that
 function separately for each compatible value.

Yes, that needs to be done, and while we are at it I think the
function should return a list containing struct {int offset; enum
fdt_compat_id; };

I could probably do this by end of week if no one else can do it
faster. Please let me know. Tests need to updated also.


 diff --git a/board/nvidia/dts/tegra114-dalmore.dts 
 b/board/nvidia/dts/tegra114-dalmore.dts

 + i2c@7000d000 {
 + status = okay;
 + clock-frequency = 10;
 + };

 According to our downstream Linux kernel, that I2C controller can run up
 to 400KHz on this board.

 But it also runs @ 100KHz just fine, too. Do we need to run at the
 fastest clock? That's the DVC (PWR_I2C) controller, which 

Re: [U-Boot] [PATCH v3 0/3] Add I2C driver for T114 Dalmore

2013-02-12 Thread Simon Glass
Hi,

On Fri, Feb 8, 2013 at 9:25 AM, Tom Warren twarren.nvi...@gmail.com wrote:
 Update DT tables and enable I2C driver support for the
 Tegra114 Dalmore board. This uses the standard Tegra I2C driver.
 5 controllers are supported, although all may not have devices
 behind them on every board.

 Changes in V2:
 - use new calculation for T114 I2C clocks
 - incorporate review comments from StephenW for the dtsi file
 Changes in V3:
 - Added tegra114-i2c name to compat_names/compat_id table(s)
 - Add search for T114 I2C node in i2c_init_board
 - Added is_scs flag to i2c_bus struct (single clock source HW)
 - Use is_scs flag to trigger new clock source rate calculation
 - Moved aliases to dtsi file as per StephenW
 - Removed tegra30-car  tegra20-i2c compatible strings
 - Changed I2C5 (PWR_I2C) clock to 400MHz

 Tom Warren (3):
   Tegra: I2C: Add T114 clock support to tegra_i2c driver
   Tegra114: fdt: Update DT files with I2C info for T114/Dalmore
   Tegra114: I2C: Enable I2C driver on Dalmore E1611 eval board

  arch/arm/dts/tegra114.dtsi  |   64 
 +++
  arch/arm/include/asm/arch-tegra/tegra_i2c.h |6 +++
  board/nvidia/dts/tegra114-dalmore.dts   |   28 
  drivers/i2c/tegra_i2c.c |   42 +++--
  include/configs/dalmore.h   |9 
  include/configs/tegra114-common.h   |3 +
  include/fdtdec.h|1 +
  lib/fdtdec.c|1 +
  8 files changed, 149 insertions(+), 5 deletions(-)


Series LGTM except for the comment about the need to enhance the alias function.

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


Re: [U-Boot] [PATCH v2] build: imx: Fix 'u-boot.imx' build without full OBJTREE reference

2013-02-12 Thread Benoßt Thébaudeau
Hi Stefano,

On Tuesday, February 12, 2013 6:53:39 PM, Stefano Babic wrote:
 On 12/02/2013 18:55, Benoßt Thébaudeau wrote:
  Hi Otavio,
  
 
 Hi BenoĂźt,
 
 
  Alright; It did the test Marek has requested and it works fine. I
  think this should go to imx/master as it fixes a regression.
  
  OK. I include it into my series so that patches apply fine whether Stefano
  applies it alone first or from my series.
 
 I merged it - you do not need to bother about it.

Great, thanks.

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


Re: [U-Boot] [PATCH v3 7/7] tegra: usb: move [start|stop]_port into ehci_hcd_[init|stop]

2013-02-12 Thread Simon Glass
Hi,

On Thu, Feb 7, 2013 at 9:16 AM, Lucas Stach d...@lynxeye.de wrote:
 The ehci_hcd entry points were just calling into the Tegra USB
 functions. Now that they are in the same file we can just move over the
 implementation.

 Signed-off-by: Lucas Stach d...@lynxeye.de
 Acked-by: Simon Glass s...@chromium.org

I didn't review this again as apparently I acked it all last time. Thanks.

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


Re: [U-Boot] [PATCH v5 01/23] ppc: Add initial memory barrier macros

2013-02-12 Thread Simon Glass
Hi Scott,

On Mon, Feb 11, 2013 at 11:52 AM, Scott Wood scottw...@freescale.com wrote:
 On 02/08/2013 09:11:57 AM, Simon Glass wrote:

 These are available on other architectures, so add them on ppc.

 Signed-off-by: Simon Glass s...@chromium.org
 ---
 Changes in v5: None
 Changes in v4: None
 Changes in v3: None
 Changes in v2: None

  arch/powerpc/include/asm/io.h | 8 
  1 file changed, 8 insertions(+)

 diff --git a/arch/powerpc/include/asm/io.h b/arch/powerpc/include/asm/io.h
 index 1f12c29..1bf12f5 100644
 --- a/arch/powerpc/include/asm/io.h
 +++ b/arch/powerpc/include/asm/io.h
 @@ -317,4 +317,12 @@ static inline phys_addr_t virt_to_phys(void * vaddr)
  #endif
  }

 +/*
 + * TODO: The kernel offers some more advanced versions of barriers, it
 might
 + * have some advantages to use them instead of the simple one here.
 + */
 +#define dmb()  __asm__ __volatile__ ( : : : memory)
 +#define __iormb()  dmb()
 +#define __iowmb()  dmb()


 What is the definition of these?  Given that we already have an
 architecture-independent barrier(), I assume this is meant to be an actual
 hardware barrier rather than a compiler barrier, so this is not a correct
 implementation.

They were introduced in ARM in commit 3c0659b5, so I am really just
following along with that. Yes the naming doesn't make a lot of sense,
but on the other hand I don't think we necessarily want an actual
hardware barrier in our writel()s. This at least makes sure that the
compiler writes in the right order - perhaps the intent is that that
rest is best left to the hardware?

Regards,
Simon


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


Re: [U-Boot] [PATCH v5 01/23] ppc: Add initial memory barrier macros

2013-02-12 Thread Simon Glass
Hi Scott,

On Tue, Feb 12, 2013 at 10:50 AM, Scott Wood scottw...@freescale.com wrote:
 On 02/12/2013 12:44:16 PM, Simon Glass wrote:

 Hi Scott,

 On Mon, Feb 11, 2013 at 11:52 AM, Scott Wood scottw...@freescale.com
 wrote:
  On 02/08/2013 09:11:57 AM, Simon Glass wrote:
 
  These are available on other architectures, so add them on ppc.
 
  Signed-off-by: Simon Glass s...@chromium.org
  ---
  Changes in v5: None
  Changes in v4: None
  Changes in v3: None
  Changes in v2: None
 
   arch/powerpc/include/asm/io.h | 8 
   1 file changed, 8 insertions(+)
 
  diff --git a/arch/powerpc/include/asm/io.h
  b/arch/powerpc/include/asm/io.h
  index 1f12c29..1bf12f5 100644
  --- a/arch/powerpc/include/asm/io.h
  +++ b/arch/powerpc/include/asm/io.h
  @@ -317,4 +317,12 @@ static inline phys_addr_t virt_to_phys(void *
  vaddr)
   #endif
   }
 
  +/*
  + * TODO: The kernel offers some more advanced versions of barriers, it
  might
  + * have some advantages to use them instead of the simple one here.
  + */
  +#define dmb()  __asm__ __volatile__ ( : : : memory)
  +#define __iormb()  dmb()
  +#define __iowmb()  dmb()
 
 
  What is the definition of these?  Given that we already have an
  architecture-independent barrier(), I assume this is meant to be an
  actual
  hardware barrier rather than a compiler barrier, so this is not a
  correct
  implementation.

 They were introduced in ARM in commit 3c0659b5, so I am really just
 following along with that. Yes the naming doesn't make a lot of sense,
 but on the other hand I don't think we necessarily want an actual
 hardware barrier in our writel()s.


 We do have a hardware barrier in writel() on PPC (ignoring the broken
 never-used little-endian implementation, which should just be removed), and
 it should stay that way.

 I do not think we should be introducing anything that looks like a hardware
 barrier but isn't, unless the semantics of a particular barrier are
 guaranteed by a particular platform without needing a barrier instruction.
 And in that case there had better be a document somewhere that explains what
 the semantics are.

Yes, agreed.



 This at least makes sure that the
 compiler writes in the right order - perhaps the intent is that that
 rest is best left to the hardware?


 Regardless of what one might think is best, it isn't left to hardware on
 many platforms, including PPC.

I really mean that my reading is that this is all that is needed in
writel() and friends. In order words, we don't need to tell the
hardware to strongly order, or whatever.

I think I can just drop this patch and things will still build.

Can you please take a look at this code too, from the patch which
brings in post-relocation board init (board_r.c):

#ifdef CONFIG_PPC
/* TODO: Can we not use dmb() macros for this? */
asm(sync ; isync);
#endif

Regards,
Simon


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


Re: [U-Boot] [PATCH v5 01/23] ppc: Add initial memory barrier macros

2013-02-12 Thread Scott Wood

On 02/12/2013 12:55:39 PM, Simon Glass wrote:

Can you please take a look at this code too, from the patch which
brings in post-relocation board init (board_r.c):

#ifdef CONFIG_PPC
/* TODO: Can we not use dmb() macros for this? */
asm(sync ; isync);
#endif


I'm not sure why we need that at all.  It's been there since Initial  
revision, so git history isn't helpful in explaining it.


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


Re: [U-Boot] [PATCH v5 01/23] ppc: Add initial memory barrier macros

2013-02-12 Thread Simon Glass
Hi Scott,

On Tue, Feb 12, 2013 at 11:04 AM, Scott Wood scottw...@freescale.com wrote:
 On 02/12/2013 12:55:39 PM, Simon Glass wrote:

 Can you please take a look at this code too, from the patch which
 brings in post-relocation board init (board_r.c):

 #ifdef CONFIG_PPC
 /* TODO: Can we not use dmb() macros for this? */
 asm(sync ; isync);
 #endif


 I'm not sure why we need that at all.  It's been there since Initial
 revision, so git history isn't helpful in explaining it.

OK great, I will punt it for generic board.


 -Scott

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


Re: [U-Boot] [PATCH v3 2/3] Tegra114: fdt: Update DT files with I2C info for T114/Dalmore

2013-02-12 Thread Tom Warren
Stephen,

On Tue, Feb 12, 2013 at 11:10 AM, Stephen Warren swar...@wwwdotorg.org wrote:
 On 02/12/2013 10:40 AM, Tom Warren wrote:
 Laxman,

 On Tue, Feb 12, 2013 at 5:02 AM, Laxman Dewangan ldewan...@nvidia.com 
 wrote:
 On Friday 08 February 2013 11:34 PM, Stephen Warren wrote:

 On 02/08/2013 10:25 AM, Tom Warren wrote:

 T114, like T30, does not have a separate/different DVC (power I2C)
 controller like T20 - all 5 I2C controllers are identical, but
 I2C5 is used to designate the controller intended for power
 control (PWR_I2C in the schematics). PWR_I2C is set to 400KHz.
 diff --git a/board/nvidia/dts/tegra114-dalmore.dts
 b/board/nvidia/dts/tegra114-dalmore.dts
 +   aliases {
 +   };
 +

 There's no point adding an empty aliases node here. Feel free to fix
 that up when you apply it rather than reposting if you want.

 I'd like too see Laxman sign-off on the *2 question he had earlier
 before actually checking this in.

 We do not require *2 as the i2c clock divider is DIVU16 type. There was bug
 in early code on kernel also which we fixed in dowstream long back. Possibly
 uboot have not fixed this yet.

 Yeah, the Tegra I2C driver in U-Boot has always doubled the rate
 before calling the clock set routine.

 Perhaps it's related to some dividers being U7.1 (i.e. the LSB of the
 divider represents 1/2 not 1)? However, as Laxman points out, this isn't
 the case for I2C clocks; they have a U16 divider, so the LSB represents
 1 not 1/2.

 But the important thing is that
 the actual I2C clock is 100KHz (or 400KHz for I2C5) as measured at the
 test points on the board.

 I'll look into the Tegra U-Boot clock routine idiosyncrasies later
 when I get some more bandwidth.

 Just a few minutes of investigation points at clk_get_divider() being buggy.

 It assumes that all dividers have a built-in *2 clock multiplier on the
 front of them:

 u64 divider = parent_rate * 2;

 (the name for that variable is wrong; it should be something more like
 parent_rate or divider_input_rate)

 This (presence of a *2 pre-multiplier) is true for U7.1 dividers, since
 this is required for the LSB of the divider to represent 1/2 not 1.
 Hence, I assume that e.g. the SPI driver doesn't do this * 2 on the
 clock rate; it actually has a U7.1 divider.

 However, this is not true for U16 dividers, since the HW doesn't need to
 multiply up the rate before dividing, since the LSB is 1 not 1/2.

 The solution here is to fix clk_get_divider() to return both a field
 width and a flag (or width) indicating whether a fractional part of the
 divider is present, and then pass that on to adjust_periph_pll() so that
 it can only optionally perform this initial * 2.

 So at least that explains it.
Yeah, I just started looking at it before lunch, and saw the same thing.

I'll see about fixing it now so I can put the T114 I2C patches to bed.

Thanks

 I would strongly recommend just fixing this now. However, if you don't
 please do file a bug so that we don't forget about this.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 2/2] Tegra: MMC: Add DT support to MMC driver for all T20 boards

2013-02-12 Thread Simon Glass
Hi Tom,

On Tue, Feb 12, 2013 at 11:05 AM, Tom Warren twarren.nvi...@gmail.com wrote:
 Simon,

 On Tue, Feb 12, 2013 at 11:07 AM, Simon Glass s...@chromium.org wrote:
 Hi,

 On Tue, Feb 5, 2013 at 1:02 PM, Tom Warren twarren.nvi...@gmail.com wrote:
 Stephen,

 On Tue, Feb 5, 2013 at 1:03 PM, Stephen Warren swar...@wwwdotorg.org 
 wrote:
 On 02/04/2013 04:48 PM, Tom Warren wrote:
 tegra_mmc_init() now uses DT info for bus width, WP/CD GPIOs, etc.
 Tested on Seaboard, fully functional.

 diff --git a/board/compal/paz00/paz00.c b/board/compal/paz00/paz00.c
 index 1447f47..5cee91a 100644
 --- a/board/compal/paz00/paz00.c
 +++ b/board/compal/paz00/paz00.c
 @@ -55,18 +55,18 @@ static void pin_mux_mmc(void)
  /* this is a weak define that we are overriding */
  int board_mmc_init(bd_t *bd)
  {
 - debug(board_mmc_init called\n);
 + debug(%s called\n, __func__);

   /* Enable muxes, etc. for SDMMC controllers */
   pin_mux_mmc();

 - debug(board_mmc_init: init eMMC\n);
 - /* init dev 0, eMMC chip, with 8-bit bus */
 - tegra_mmc_init(0, 8, -1, -1);
 + debug(%s: init eMMC\n, __func__);
 + /* init dev 0, eMMC chip */
 + tegra_mmc_init(0);

 - debug(board_mmc_init: init SD slot\n);
 - /* init dev 3, SD slot, with 4-bit bus */
 - tegra_mmc_init(3, 4, GPIO_PV1, GPIO_PV5);
 + debug(%s: init SD slot\n, __func__);
 + /* init dev 3, SD slot */
 + tegra_mmc_init(3);

   return 0;
  }

 That doesn't look right. The board code still has knowledge of which
 SDHCI controllers are in use by the board. Instead, the board should
 just call tegra_mmc_init() with no parameters at all, and the MMC driver
 should scan the device tree for all present-and-enabled SDHCI nodes, and
 instantiate a U-Boot SDHCI device. Without this, the device tree isn't
 in control of the whole process, so there's little point doing the
 conversion; a new board couldn't be supported /just/ by creating a new
 device tree file.

 diff --git a/drivers/mmc/tegra_mmc.c b/drivers/mmc/tegra_mmc.c

 +#ifndef CONFIG_OF_CONTROL
 +#error Please enable device tree support to use this driver
 +#endif

 So CONFIG_OF_CONTROL must be enabled ...


  static void tegra_get_setup(struct mmc_host *host, int dev_index)
  {
 - debug(tegra_get_setup: dev_index = %d\n, dev_index);
 + debug(%s: dev_index = %d\n, __func__, dev_index);
 +
 +#ifdef CONFIG_OF_CONTROL

 ... so there's no need for that ifdef

 I took Allen's recent SPI/SLINK driver(s) as an example, but as you
 point out, if CONFIG_OF_CONTROL isn't enabled, you get build errors
 anyway.


 + int count, node = 0;
 + int node_list[MAX_HOSTS];
 +
 + count = fdtdec_find_aliases_for_id(gd-fdt_blob, sdmmc,
 + COMPAT_NVIDIA_TEGRA20_SDMMC, node_list, MAX_HOSTS);
 + debug(%s: count of nodes is %d\n, __func__, count);
 +
 + if (count  dev_index) {
 + printf(%s: device index %d exceeds node count (%d)!\n,
 + __func__, dev_index, count);
 + return;
 + }

 This requires that an alias exist in order for the SDHCI node to be
 found/processed. This isn't correct; the SDHCI nodes must be enumerated
 themselves, and then the aliases (if any are present) provide a naming
 hint for them, but even without aliases, the SDHCI nodes must be processed.
 Again, I used Allen's SLINK driver for as a template here. In fact, it
 looks like our I2C and SPI/SLINK drivers do this, as well as the
 Exynos SPI and S3C24x0 I2C driver all do this.  Can you point out a
 U-Boot driver that does it the right way (preferably with more than 1
 node, like MMC)? I can take a look at that code to use as an example
 of what you're proposing above.

 You have it correct already. Stephen please take another look and let
 me know what problem you see with this approach. I'm very sorry that I
 am so late to this discussion.

 PTAL at the current patchset (v2) - I changed it to look for 'sdhci',
 which names the node and the aliases, and seem to work fine. I also
 have one function that parses all the nodes at once, so only one call
 to tegra_mmc_init() is needed from the board level.

Great. Yes I think that was the version I looked at (above, in this thread).

Regards,
Simon




 + /*
 +  * NOTE: mmc-bus_width is determined by mmc.c dynamically.
 +  * Should we override it with this value?
 +  */
 + host-width = fdtdec_get_int(gd-fdt_blob, node, bus-width, 0);
 + if (!host-width)
 + debug(%s: no sdmmc width found\n, __func__);

 It should be possible to inform the MMC core of the width of the bus in
 terms of wires on the PCB. It should only probe the connected device up
 to that width. If that feature is missing, it can be added later though,
 outside the scope of this patch set.

 You didn't Cc the MMC maintainer; they should be Cc'd since this code is
 in drivers/mmc/.

 Thanks, added Andy Fleming to CC.

 Tom
 ___
 U-Boot mailing list

Re: [U-Boot] [PATCH v2 2/3] Tegra114: fdt: Update DT files with I2C info for T114/Dalmore

2013-02-12 Thread Tom Warren
Simon,

On Tue, Feb 12, 2013 at 11:13 AM, Simon Glass s...@chromium.org wrote:
 Hi Stephen,

 On Thu, Feb 7, 2013 at 10:17 AM, Stephen Warren swar...@wwwdotorg.org wrote:
 On 02/07/2013 09:14 AM, Tom Warren wrote:
 Stephen,

 On Wed, Feb 6, 2013 at 5:00 PM, Stephen Warren swar...@wwwdotorg.org 
 wrote:
 On 02/06/2013 04:26 PM, Tom Warren wrote:
 Note that T114 does not have a separate/different DVC (power I2C)
 controller like T20 - all 5 I2C controllers are identical, but
 I2C5 is used to designate the controller intended for power
 control (PWR_I2C in the schematics).

 diff --git a/arch/arm/dts/tegra114.dtsi b/arch/arm/dts/tegra114.dtsi

 + tegra_car: clock@60006000 {
 + compatible = nvidia,tegra114-car, nvidia,tegra30-car;

 Only the Tegra114 value should be listed here; the presence of the
 Tegra30 value in the upstream kernel is a mistake that will be fixed as
 part of the Tegra114 clock driver patches.

 OK. But this is why I think hewing to the Linux DT files, while
 laudable, is a time sink. Though since T114 is so new  still settling
 in, I guess some churn is expected.

 The issue here is not about making U-Boot fall in line with the kernel.
 The issue is making the device tree in U-Boot be correct. Right now, the
 kernel happens to have the most correct device tree, so it's a good
 reference for U-Boot.

 + i2c@7000c000 {
 + compatible = nvidia,tegra114-i2c, nvidia,tegra20-i2c;

 Same here; only include the Tegra114 value since the HW isn't 100%
 compatible with the Tegra20 HW.

 What does the 'compatible' designater mean, exactly? Does it require
 100% identical HW? Compatible, in a SW/HW sense, to me means that
 newer SW will work with older/similar (but not exactly the same) HW,
 etc.

 The idea here is that the first entry in compatible always defines the
 most specific implementation identification possible. So, compatible
 will at least contain:

 Tegra20: nvidia,tegra20-i2c
 Tegra30: nvidia,tegra30-i2c
 Tegra114: nvidia,tegra114-i2c

 Now, if a piece of newer hardware can be operated 100% correctly
 (ignoring issues due to new features not being exposed, or operating at
 degraded performance) by a driver that only knows about the older
 hardware, then the compatible property can additionally contain other
 values indicating what HW it is compatible with. So, we actually end up
 with:

 Tegra20: nvidia,tegra20-i2c
 Tegra30: nvidia,tegra30-i2c nvidia,tegra20-i2c
 Tegra114: nvidia,tegra114-i2c

 Tegra114 I2C HW isn't marked as compatible with either Tegra20 or
 Tegra30, because the clock divider programming must be different.

 Tegra U-Boot uses the tegra20-i2c name to find and load the I2C
 driver. I could add a new entry in the compat-names table for
 tegra114-i2c,

 Yes, that is the way to go. The driver should include a list of all the
 different compatible values that it supports.

 but I still don't think there's enough difference
 between T20/T30 and T114 I2C to justify a whole new I2C driver - so
 far, it's just one register with a new clk divider that has to be
 taken in consideration when programming the clock source divider.

 But that's required to operate the hardware correctly. It doesn't matter
 how trivial the difference is; it could just be a single bit that needs
 to be set/cleared on new HW - there would still be a difference that
 would otherwise make the HW operate incorrectly.

 I could do as the driver does for T20, where there is a separate DVC
 controller, plus 3 normal I2C controllers. I could 'find_aliases' for
 the tegrat114-i2c controller first,  process its nodes, and return. If
 no tegrat114-i2c exists, the driver would continue on to look for
 tegra20-i2c/tegra20-dvc controller info as it does now.  It'd still be
 one tegra_i2c.c driver, with a flag in the i2c_bus struct telling me
 if I found T114 I2C HW (i2c_bus-single_clk, etc.) and I could then do
 the new clock divider dance based on that flag. How does that sound?

 The U-Boot function that returns the list of devices supported by the
 driver should be enhanced so that it can search for nodes compatible
 with any 1 (or more) of n compatible values at a time, rather than just
 a single compatible value. Then, all you'd have to do with this change
 is add a new entry into the table, not add extra code that calls that
 function separately for each compatible value.

 Yes, that needs to be done, and while we are at it I think the
 function should return a list containing struct {int offset; enum
 fdt_compat_id; };

 I could probably do this by end of week if no one else can do it
 faster. Please let me know. Tests need to updated also.

I won't have time for this this week (on vacation Friday thru
Tuesday). If you want to tackle this, go ahead. The current T114 I2C
patchset is good-to-go AFAICT, with the exception of the clock divisor
fix Stephen just pointed out in another thread. So you can use that as
your basis for rewrite, if you wish.



 diff --git 

Re: [U-Boot] [PATCH v2 2/3] Tegra114: fdt: Update DT files with I2C info for T114/Dalmore

2013-02-12 Thread Simon Glass
Hi Tom,

On Tue, Feb 12, 2013 at 11:13 AM, Tom Warren twarren.nvi...@gmail.com wrote:
 Simon,

 On Tue, Feb 12, 2013 at 11:13 AM, Simon Glass s...@chromium.org wrote:
 Hi Stephen,

 On Thu, Feb 7, 2013 at 10:17 AM, Stephen Warren swar...@wwwdotorg.org 
 wrote:
 On 02/07/2013 09:14 AM, Tom Warren wrote:
 Stephen,

 On Wed, Feb 6, 2013 at 5:00 PM, Stephen Warren swar...@wwwdotorg.org 
 wrote:
 On 02/06/2013 04:26 PM, Tom Warren wrote:
 Note that T114 does not have a separate/different DVC (power I2C)
 controller like T20 - all 5 I2C controllers are identical, but
 I2C5 is used to designate the controller intended for power
 control (PWR_I2C in the schematics).

 diff --git a/arch/arm/dts/tegra114.dtsi b/arch/arm/dts/tegra114.dtsi

 + tegra_car: clock@60006000 {
 + compatible = nvidia,tegra114-car, nvidia,tegra30-car;

 Only the Tegra114 value should be listed here; the presence of the
 Tegra30 value in the upstream kernel is a mistake that will be fixed as
 part of the Tegra114 clock driver patches.

 OK. But this is why I think hewing to the Linux DT files, while
 laudable, is a time sink. Though since T114 is so new  still settling
 in, I guess some churn is expected.

 The issue here is not about making U-Boot fall in line with the kernel.
 The issue is making the device tree in U-Boot be correct. Right now, the
 kernel happens to have the most correct device tree, so it's a good
 reference for U-Boot.

 + i2c@7000c000 {
 + compatible = nvidia,tegra114-i2c, nvidia,tegra20-i2c;

 Same here; only include the Tegra114 value since the HW isn't 100%
 compatible with the Tegra20 HW.

 What does the 'compatible' designater mean, exactly? Does it require
 100% identical HW? Compatible, in a SW/HW sense, to me means that
 newer SW will work with older/similar (but not exactly the same) HW,
 etc.

 The idea here is that the first entry in compatible always defines the
 most specific implementation identification possible. So, compatible
 will at least contain:

 Tegra20: nvidia,tegra20-i2c
 Tegra30: nvidia,tegra30-i2c
 Tegra114: nvidia,tegra114-i2c

 Now, if a piece of newer hardware can be operated 100% correctly
 (ignoring issues due to new features not being exposed, or operating at
 degraded performance) by a driver that only knows about the older
 hardware, then the compatible property can additionally contain other
 values indicating what HW it is compatible with. So, we actually end up
 with:

 Tegra20: nvidia,tegra20-i2c
 Tegra30: nvidia,tegra30-i2c nvidia,tegra20-i2c
 Tegra114: nvidia,tegra114-i2c

 Tegra114 I2C HW isn't marked as compatible with either Tegra20 or
 Tegra30, because the clock divider programming must be different.

 Tegra U-Boot uses the tegra20-i2c name to find and load the I2C
 driver. I could add a new entry in the compat-names table for
 tegra114-i2c,

 Yes, that is the way to go. The driver should include a list of all the
 different compatible values that it supports.

 but I still don't think there's enough difference
 between T20/T30 and T114 I2C to justify a whole new I2C driver - so
 far, it's just one register with a new clk divider that has to be
 taken in consideration when programming the clock source divider.

 But that's required to operate the hardware correctly. It doesn't matter
 how trivial the difference is; it could just be a single bit that needs
 to be set/cleared on new HW - there would still be a difference that
 would otherwise make the HW operate incorrectly.

 I could do as the driver does for T20, where there is a separate DVC
 controller, plus 3 normal I2C controllers. I could 'find_aliases' for
 the tegrat114-i2c controller first,  process its nodes, and return. If
 no tegrat114-i2c exists, the driver would continue on to look for
 tegra20-i2c/tegra20-dvc controller info as it does now.  It'd still be
 one tegra_i2c.c driver, with a flag in the i2c_bus struct telling me
 if I found T114 I2C HW (i2c_bus-single_clk, etc.) and I could then do
 the new clock divider dance based on that flag. How does that sound?

 The U-Boot function that returns the list of devices supported by the
 driver should be enhanced so that it can search for nodes compatible
 with any 1 (or more) of n compatible values at a time, rather than just
 a single compatible value. Then, all you'd have to do with this change
 is add a new entry into the table, not add extra code that calls that
 function separately for each compatible value.

 Yes, that needs to be done, and while we are at it I think the
 function should return a list containing struct {int offset; enum
 fdt_compat_id; };

 I could probably do this by end of week if no one else can do it
 faster. Please let me know. Tests need to updated also.

 I won't have time for this this week (on vacation Friday thru
 Tuesday). If you want to tackle this, go ahead. The current T114 I2C
 patchset is good-to-go AFAICT, with the exception of the clock divisor
 fix Stephen just pointed out in another thread. 

Re: [U-Boot] [PATCH] Allow OMAP2 boards to setup GPMC chipselects.

2013-02-12 Thread Mark Jackson

On 12/02/13 17:01, Tom Rini wrote:

On Mon, Feb 11, 2013 at 04:29:03PM +, Mark Jackson wrote:


Expose the enable_gpmc_cs_config() function so OMAP2 boards can register
GPMC chipselects.

Signed-off-by: Mark Jackson m...@newflow.co.uk
---
  arch/arm/include/asm/arch-am33xx/sys_proto.h |2 ++
  1 file changed, 2 insertions(+)

diff --git a/arch/arm/include/asm/arch-am33xx/sys_proto.h 
b/arch/arm/include/asm/arch-am33xx/sys_proto.h
index 588d8de..97ab60d 100644
--- a/arch/arm/include/asm/arch-am33xx/sys_proto.h
+++ b/arch/arm/include/asm/arch-am33xx/sys_proto.h
@@ -35,5 +35,7 @@ void ddr_pll_config(unsigned int ddrpll_M);
   void sdelay(unsigned long);
  void gpmc_init(void);
+void enable_gpmc_cs_config(const u32 *gpmc_config, struct gpmc_cs *cs, u32 
base,
+   u32 size);
  void omap_nand_switch_ecc(int);
  #endif


Can you please correct the description?  You're exposing the function
for am33xx not omap2.  Otherwise fine with me, and I assume you need
this on a custom board (aside: the function already exists/is used in
arch/arm/cpu/armv7/am33xx/mem.c).  Are you planning to submit that
support as well?  Thanks!


Sure ... I'll repost with the comment changed.

Yes ... I've not written my own version, I'm using the existing code.

And, yes, I've a new CPU board I'm working on, which I'll submit later 
(once we've done a hardware re-spin).


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


Re: [U-Boot] [PATCH v5 01/23] ppc: Add initial memory barrier macros

2013-02-12 Thread Scott Wood

On 02/12/2013 12:44:16 PM, Simon Glass wrote:

Hi Scott,

On Mon, Feb 11, 2013 at 11:52 AM, Scott Wood  
scottw...@freescale.com wrote:

 On 02/08/2013 09:11:57 AM, Simon Glass wrote:

 These are available on other architectures, so add them on ppc.

 Signed-off-by: Simon Glass s...@chromium.org
 ---
 Changes in v5: None
 Changes in v4: None
 Changes in v3: None
 Changes in v2: None

  arch/powerpc/include/asm/io.h | 8 
  1 file changed, 8 insertions(+)

 diff --git a/arch/powerpc/include/asm/io.h  
b/arch/powerpc/include/asm/io.h

 index 1f12c29..1bf12f5 100644
 --- a/arch/powerpc/include/asm/io.h
 +++ b/arch/powerpc/include/asm/io.h
 @@ -317,4 +317,12 @@ static inline phys_addr_t virt_to_phys(void *  
vaddr)

  #endif
  }

 +/*
 + * TODO: The kernel offers some more advanced versions of  
barriers, it

 might
 + * have some advantages to use them instead of the simple one  
here.

 + */
 +#define dmb()  __asm__ __volatile__ ( : : : memory)
 +#define __iormb()  dmb()
 +#define __iowmb()  dmb()


 What is the definition of these?  Given that we already have an
 architecture-independent barrier(), I assume this is meant to be an  
actual
 hardware barrier rather than a compiler barrier, so this is not a  
correct

 implementation.

They were introduced in ARM in commit 3c0659b5, so I am really just
following along with that. Yes the naming doesn't make a lot of sense,
but on the other hand I don't think we necessarily want an actual
hardware barrier in our writel()s.


We do have a hardware barrier in writel() on PPC (ignoring the broken  
never-used little-endian implementation, which should just be removed),  
and it should stay that way.


I do not think we should be introducing anything that looks like a  
hardware barrier but isn't, unless the semantics of a particular  
barrier are guaranteed by a particular platform without needing a  
barrier instruction.  And in that case there had better be a document  
somewhere that explains what the semantics are.



This at least makes sure that the
compiler writes in the right order - perhaps the intent is that that
rest is best left to the hardware?


Regardless of what one might think is best, it isn't left to hardware  
on many platforms, including PPC.


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


[U-Boot] [PATCH v2] Allow AM33xx boards to setup GPMC chipselects.

2013-02-12 Thread Mark Jackson
Expose the enable_gpmc_cs_config() function so AM33xx based boards can 
register GPMC chip selects.


Changes in V2:
- Indicate this is for AM33xx (not OMAP2)

Signed-off-by: Mark Jackson m...@newflow.co.uk
---
 arch/arm/include/asm/arch-am33xx/sys_proto.h |2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/include/asm/arch-am33xx/sys_proto.h 
b/arch/arm/include/asm/arch-am33xx/sys_proto.h

index 588d8de..97ab60d 100644
--- a/arch/arm/include/asm/arch-am33xx/sys_proto.h
+++ b/arch/arm/include/asm/arch-am33xx/sys_proto.h
@@ -35,5 +35,7 @@ void ddr_pll_config(unsigned int ddrpll_M);
  void sdelay(unsigned long);
 void gpmc_init(void);
+void enable_gpmc_cs_config(const u32 *gpmc_config, struct gpmc_cs *cs, 
u32 base,

+   u32 size);
 void omap_nand_switch_ecc(int);
 #endif
--
1.7.9.5


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


Re: [U-Boot] [PATCH v2 2/2] Tegra: MMC: Add DT support to MMC driver for all T20 boards

2013-02-12 Thread Tom Warren
Lucas,

On Mon, Feb 11, 2013 at 10:59 AM, Tom Warren twarren.nvi...@gmail.com wrote:
 Lucas,

 On Mon, Feb 11, 2013 at 10:33 AM, Lucas Stach d...@lynxeye.de wrote:
 Am Montag, den 11.02.2013, 10:17 -0700 schrieb Tom Warren:
 tegra_mmc_init() now parses the DT info for bus width, WP/CD GPIOs, etc.
 Tested on Seaboard, fully functional.

 Tamonten boards (medcom-wide, plutux, and tec) use a different/new
 dtsi file w/common settings.

 Signed-off-by: Tom Warren twar...@nvidia.com
 ---
 v2:
 - all boards now call tegra_mmc_init once, w/no params
 - count MMC controllers, not aliases
 - AD boards (medcom/plutux/tec) use common tegra20-tamonten.dtsi

  arch/arm/include/asm/arch-tegra/mmc.h |2 +-
  arch/arm/include/asm/arch-tegra/tegra_mmc.h   |   13 +-
  board/avionic-design/common/tamonten.c|4 +-
  board/compal/paz00/paz00.c|   11 +-
  board/compulab/trimslice/trimslice.c  |9 +-
  board/nvidia/harmony/harmony.c|   11 +-
  board/nvidia/seaboard/seaboard.c  |   11 +-
  board/nvidia/whistler/whistler.c  |7 +-
  board/toradex/colibri_t20_iris/colibri_t20_iris.c |2 +-
  drivers/mmc/tegra_mmc.c   |  259 
 +
  include/configs/medcom-wide.h |2 +
  include/configs/plutux.h  |2 +
  include/configs/tec.h |2 +
  include/fdtdec.h  |1 +
  lib/fdtdec.c  |1 +
  15 files changed, 197 insertions(+), 140 deletions(-)

 [...]
 diff --git a/board/nvidia/harmony/harmony.c b/board/nvidia/harmony/harmony.c
 index 93430ed..fba06c2 100644
 --- a/board/nvidia/harmony/harmony.c
 +++ b/board/nvidia/harmony/harmony.c
 @@ -58,18 +58,13 @@ static void pin_mux_mmc(void)
  /* this is a weak define that we are overriding */
  int board_mmc_init(bd_t *bd)
  {
 - debug(board_mmc_init called\n);
 + debug(%s called\n, __func__);

   /* Enable muxes, etc. for SDMMC controllers */
   pin_mux_mmc();

 - debug(board_mmc_init: init SD slot J26\n);
 - /* init dev 0, SD slot J26, with 8-bit bus */
 - tegra_mmc_init(0, 8, GPIO_PI6, GPIO_PH2);
 -
 - debug(board_mmc_init: init SD slot J5\n);
 - /* init dev 2, SD slot J5, with 4-bit bus */
 - tegra_mmc_init(2, 4, GPIO_PT3, GPIO_PI5);
 + debug(%s: init MMC devs\n, __func__);
 + tegra_mmc_init();

 tegra_mmc_init should not be called from every individual board file,
 but from the common nvidia tegra board file. Only the pinmux should stay
 in the individual board code, same thing as was done to all the other
 functions like NAND and USB.

 True. I was originally just adapting the current config-file driven
 MMC to DT step-by-step, but you're right - it should be called just
 once for all boards in the common board file. I'll change it in V3.

I've looked into this some more, and it appears that I can't just add
a call to tegra_mmc_init() from board_init() in
boards/nvidia/common/board.c.

board_init() is where the other periphs do their pin_mux and
xxx_init() calls (USB, SPI, etc.).  board_init() is called early in
board_init_r(), before mmc_initialize() is called. mmc_initialize() is
needed before tegra_mmc_init() can use the mmc_device struct, etc. So
tegra_mmc_init() needs to be called after mmc_initialize(), and right
now that's in each board's board_mmc_init().  In board_mmc_init(),
each board sets up any power rails needed for SD-card or eMMC access,
sets up it's pin muxes for MMC, and then calls tegra_mmc_init() to
parse the DT file and populate the mmc structs.

I could move the pin_mux_mmc() function calls from each board file
into nvidia/common/board.c's board_init(), but it wouldn't really
change much. So I'll leave it as it is for now, with pin_mux_mmc() and
tegra_mmc_init() being called from each board's 'board' file
(seaboard.c, colibri_t20_iris.c, etc).

Let me know if you see another way to move Tegra MMC init to a common
board file that doesn't break the MMC driver flow.

Thanks,

Tom

 Thanks,

 Tom
   return 0;
  }
 [...]

 Regards,
 Lucas

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


Re: [U-Boot] [PATCH v2 2/3] Tegra114: fdt: Update DT files with I2C info for T114/Dalmore

2013-02-12 Thread Stephen Warren
On 02/12/2013 12:17 PM, Simon Glass wrote:
 Hi Tom,
 
 On Tue, Feb 12, 2013 at 11:13 AM, Tom Warren twarren.nvi...@gmail.com wrote:
...
 That's the current POR for Tegra DT use in upstream U-Boot, assuming I
 can find an up-to-date kernel with the latest DTS files (I'll use
 Stephen's swarren/linux-tegra.git/for-next until told otherwise).
 
 Yes that was always my problem - finding what the kernel actually
 used, might use, etc.

I must say I find this quite puzzling; the kernel repos aren't exactly
hidden.

Tegra's kernel for-next is likely the best place right now as any DT
changes typically go through that tree. However, on the off-chance any
other maintainer picks up any changes, linux-next.git would have the
latest bindings. That's all been true for a year or more.

That said, there is a move to either move the binding definitions and
.dts files out of the kernel tree and/or stop taking changes to them
through individual SoC trees, but perhaps through the device tree repo.
If that does happen, I'll let you know.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v2 2/3] Tegra114: fdt: Update DT files with I2C info for T114/Dalmore

2013-02-12 Thread Simon Glass
Hi Stephen,

On Tue, Feb 12, 2013 at 11:26 AM, Stephen Warren swar...@wwwdotorg.org wrote:
 On 02/12/2013 12:17 PM, Simon Glass wrote:
 Hi Tom,

 On Tue, Feb 12, 2013 at 11:13 AM, Tom Warren twarren.nvi...@gmail.com 
 wrote:
 ...
 That's the current POR for Tegra DT use in upstream U-Boot, assuming I
 can find an up-to-date kernel with the latest DTS files (I'll use
 Stephen's swarren/linux-tegra.git/for-next until told otherwise).

 Yes that was always my problem - finding what the kernel actually
 used, might use, etc.

 I must say I find this quite puzzling; the kernel repos aren't exactly
 hidden.

Well if a change has made it to a repo then things are easier,
particularly if it is next/. It was chasing down patches on mailing
lists that I found hard.


 Tegra's kernel for-next is likely the best place right now as any DT
 changes typically go through that tree. However, on the off-chance any
 other maintainer picks up any changes, linux-next.git would have the
 latest bindings. That's all been true for a year or more.

 That said, there is a move to either move the binding definitions and
 .dts files out of the kernel tree and/or stop taking changes to them
 through individual SoC trees, but perhaps through the device tree repo.
 If that does happen, I'll let you know.

Sounds good.

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


Re: [U-Boot] [PATCH v2 2/3] Tegra114: fdt: Update DT files with I2C info for T114/Dalmore

2013-02-12 Thread Tom Warren
On Tue, Feb 12, 2013 at 12:26 PM, Stephen Warren swar...@wwwdotorg.org wrote:
 On 02/12/2013 12:17 PM, Simon Glass wrote:
 Hi Tom,

 On Tue, Feb 12, 2013 at 11:13 AM, Tom Warren twarren.nvi...@gmail.com 
 wrote:
 ...
 That's the current POR for Tegra DT use in upstream U-Boot, assuming I
 can find an up-to-date kernel with the latest DTS files (I'll use
 Stephen's swarren/linux-tegra.git/for-next until told otherwise).

 Yes that was always my problem - finding what the kernel actually
 used, might use, etc.

 I must say I find this quite puzzling; the kernel repos aren't exactly
 hidden.
Not hidden, but numerous. Perhaps I should have said 'can find _the
correct_ kernel ...'. I've been pointed to 2 or 3 different repos over
the course of these DT patches. I'm not a kernel guru, and I don't
have the bandwidth to monitor kernel reflectors, etc. When I need
something kernel-related, I resort to Google or asking you.


 Tegra's kernel for-next is likely the best place right now as any DT
 changes typically go through that tree. However, on the off-chance any
 other maintainer picks up any changes, linux-next.git would have the
 latest bindings. That's all been true for a year or more.

 That said, there is a move to either move the binding definitions and
 .dts files out of the kernel tree and/or stop taking changes to them
 through individual SoC trees, but perhaps through the device tree repo.
 If that does happen, I'll let you know.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v2 2/2] Tegra: MMC: Add DT support to MMC driver for all T20 boards

2013-02-12 Thread Lucas Stach
Hello Tom,

Am Dienstag, den 12.02.2013, 12:24 -0700 schrieb Tom Warren:
 Lucas,

 
  tegra_mmc_init should not be called from every individual board file,
  but from the common nvidia tegra board file. Only the pinmux should stay
  in the individual board code, same thing as was done to all the other
  functions like NAND and USB.
 
  True. I was originally just adapting the current config-file driven
  MMC to DT step-by-step, but you're right - it should be called just
  once for all boards in the common board file. I'll change it in V3.
 
 I've looked into this some more, and it appears that I can't just add
 a call to tegra_mmc_init() from board_init() in
 boards/nvidia/common/board.c.
 
 board_init() is where the other periphs do their pin_mux and
 xxx_init() calls (USB, SPI, etc.).  board_init() is called early in
 board_init_r(), before mmc_initialize() is called. mmc_initialize() is
 needed before tegra_mmc_init() can use the mmc_device struct, etc. So
 tegra_mmc_init() needs to be called after mmc_initialize(), and right
 now that's in each board's board_mmc_init().  In board_mmc_init(),
 each board sets up any power rails needed for SD-card or eMMC access,
 sets up it's pin muxes for MMC, and then calls tegra_mmc_init() to
 parse the DT file and populate the mmc structs.
 
 I could move the pin_mux_mmc() function calls from each board file
 into nvidia/common/board.c's board_init(), but it wouldn't really
 change much. So I'll leave it as it is for now, with pin_mux_mmc() and
 tegra_mmc_init() being called from each board's 'board' file
 (seaboard.c, colibri_t20_iris.c, etc).
 
 Let me know if you see another way to move Tegra MMC init to a common
 board file that doesn't break the MMC driver flow.
 

I didn't look up the flow myself, as I don't have time for that right
now, but I think I've got a pretty good picture from your description.

I think we should really try to make the Tegra MMC init flow as similar
as possible to the other peripherals, so I suggest doing the following:
1. Provide a pin_mux_mmc() (possibly with a weak define as done with
other peripherals). Boards should do pinmux and rail enabling within
this function.
2. Move board_mmc_init() into nvidia/common/board.c, this function
should call into the board specific pinmux function and then call
tegra_mmc_init().

So even while we don't get the complete same flow as for other
peripherals as the board_mmc_init() still has to be a freestanding
function, instead of those things being folded into board_init(), we at
least gain a clear distinction between the board specific parts and
Tegra common code.

Regards,
Lucas

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


Re: [U-Boot] [PATCH] Allow OMAP2 boards to setup GPMC chipselects.

2013-02-12 Thread Tom Rini
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/12/2013 02:20 PM, Mark Jackson wrote:
 On 12/02/13 17:01, Tom Rini wrote:
 On Mon, Feb 11, 2013 at 04:29:03PM +, Mark Jackson wrote:
 
 Expose the enable_gpmc_cs_config() function so OMAP2 boards can
 register GPMC chipselects.
 
 Signed-off-by: Mark Jackson m...@newflow.co.uk --- 
 arch/arm/include/asm/arch-am33xx/sys_proto.h |2 ++ 1 file 
 changed, 2 insertions(+)
 
 diff --git a/arch/arm/include/asm/arch-am33xx/sys_proto.h 
 b/arch/arm/include/asm/arch-am33xx/sys_proto.h index 
 588d8de..97ab60d 100644 --- 
 a/arch/arm/include/asm/arch-am33xx/sys_proto.h +++ 
 b/arch/arm/include/asm/arch-am33xx/sys_proto.h @@ -35,5 +35,7 
 @@ void ddr_pll_config(unsigned int ddrpll_M); void 
 sdelay(unsigned long); void gpmc_init(void); +void 
 enable_gpmc_cs_config(const u32 *gpmc_config, struct gpmc_cs 
 *cs, u32 base, +u32 size); void 
 omap_nand_switch_ecc(int); #endif
 
 Can you please correct the description?  You're exposing the 
 function for am33xx not omap2.  Otherwise fine with me, and I 
 assume you need this on a custom board (aside: the function 
 already exists/is used in arch/arm/cpu/armv7/am33xx/mem.c).  Are
  you planning to submit that support as well?  Thanks!
 
 Sure ... I'll repost with the comment changed.

Thanks.

 Yes ... I've not written my own version, I'm using the existing 
 code.
 
 And, yes, I've a new CPU board I'm working on, which I'll submit 
 later (once we've done a hardware re-spin).

Looking forward to it!

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

iQIcBAEBAgAGBQJRGpzgAAoJENk4IS6UOR1WZh8P+gOPjlJmQi5ZRJSR3fE8gIUu
it1T5VDXWiWLLHRDkCsdK5DkamrLwQwYdOpSqVWqN48gqPJJasgSIf36+H5kXArR
lkyE1HzmGsP8v31deY/6wIAPy0g3JTCac9IhCmvLkkNwGJzlfdTtoCHyd20oxDmh
gzCo9y7PuDfdVnONlyGwuKdefqH/u9gq5nbKdw15DpTgGITUaXfOpRj/4wKOMx0t
KzaGXNcKrs30gKJoTEO0R8voRi6s0sEn9uSFBxBp3EXrrQNC8Ee1AKL+RCXfH28Y
L3PB1T1eRAAnG5erZOh4EoYzpSwzARJ9vEUOu96m4dLUihDH6ShD+0LSYfTLr0cm
wpt2ivzN7Ede9kGg2bZ9l+eL0c5/+V+ZkBqv1m4nT//qxKj/AweuUxexXWnxmVsF
XotwUVNPpb2AhDnqRShC56zEM+0CFyNPlSSvp93CO6V/jB4W+RRd9IoKw7AHWmvS
KldbC75kDwxncxlCelc3BqDrlh7NZ6yJGVeHfNHm1BNWlg7CCn36IDXUNQ7UAOKE
BQ+8u4liYkhGw+EJS0f7o7TD0d1o4qOj/IB5e7sAhhgTeOw/A2jP78HzAvKhGamQ
ETJSAzr0M8a1B2Y7YjRM8HG9f0drGWXuektF9y9/vmGaGSOxfYMjLq/Jbe6Pifnv
Mi6lmINkleLKmto50Ppf
=KvZG
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v2 2/2] Tegra: MMC: Add DT support to MMC driver for all T20 boards

2013-02-12 Thread Tom Warren
Lucas,

On Tue, Feb 12, 2013 at 12:41 PM, Lucas Stach d...@lynxeye.de wrote:
 Hello Tom,

 Am Dienstag, den 12.02.2013, 12:24 -0700 schrieb Tom Warren:
 Lucas,

 
  tegra_mmc_init should not be called from every individual board file,
  but from the common nvidia tegra board file. Only the pinmux should stay
  in the individual board code, same thing as was done to all the other
  functions like NAND and USB.
 
  True. I was originally just adapting the current config-file driven
  MMC to DT step-by-step, but you're right - it should be called just
  once for all boards in the common board file. I'll change it in V3.

 I've looked into this some more, and it appears that I can't just add
 a call to tegra_mmc_init() from board_init() in
 boards/nvidia/common/board.c.

 board_init() is where the other periphs do their pin_mux and
 xxx_init() calls (USB, SPI, etc.).  board_init() is called early in
 board_init_r(), before mmc_initialize() is called. mmc_initialize() is
 needed before tegra_mmc_init() can use the mmc_device struct, etc. So
 tegra_mmc_init() needs to be called after mmc_initialize(), and right
 now that's in each board's board_mmc_init().  In board_mmc_init(),
 each board sets up any power rails needed for SD-card or eMMC access,
 sets up it's pin muxes for MMC, and then calls tegra_mmc_init() to
 parse the DT file and populate the mmc structs.

 I could move the pin_mux_mmc() function calls from each board file
 into nvidia/common/board.c's board_init(), but it wouldn't really
 change much. So I'll leave it as it is for now, with pin_mux_mmc() and
 tegra_mmc_init() being called from each board's 'board' file
 (seaboard.c, colibri_t20_iris.c, etc).

 Let me know if you see another way to move Tegra MMC init to a common
 board file that doesn't break the MMC driver flow.


 I didn't look up the flow myself, as I don't have time for that right
 now, but I think I've got a pretty good picture from your description.
Thanks for the quick response.


 I think we should really try to make the Tegra MMC init flow as similar
 as possible to the other peripherals, so I suggest doing the following:
 1. Provide a pin_mux_mmc() (possibly with a weak define as done with
 other peripherals). Boards should do pinmux and rail enabling within
 this function.
(Almost) every Tegra board already has a pin_mux_mmc(). Few boards do
any power-rail enabling, but I can move those that do into
pin_mux_mmc().

 2. Move board_mmc_init() into nvidia/common/board.c, this function
 should call into the board specific pinmux function and then call
 tegra_mmc_init().
Current board_mmc_init() does call pin_mux_mmc() and then
tegra_mmc_init(). Moving it from each board file into common/board.c
is a good idea. I'll try that.

Thanks

 So even while we don't get the complete same flow as for other
 peripherals as the board_mmc_init() still has to be a freestanding
 function, instead of those things being folded into board_init(), we at
 least gain a clear distinction between the board specific parts and
 Tegra common code.

 Regards,
 Lucas

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


[U-Boot] [PATCH] am335x_evm: Fix CPSW ethernet on GP EVM and EVM-SK

2013-02-12 Thread Tom Rini
In commit cfd4ff6 we implemented part of advisory 1.0.10 (internal delay
for RGMII mode not supported).  This in turn however requires that we
set the tx clock delay feature in the PHY itself.

Signed-off-by: Tom Rini tr...@ti.com
---
 board/ti/am335x/board.c |   27 +++
 1 file changed, 27 insertions(+)

diff --git a/board/ti/am335x/board.c b/board/ti/am335x/board.c
index b9ac1d5..48e6896 100644
--- a/board/ti/am335x/board.c
+++ b/board/ti/am335x/board.c
@@ -73,6 +73,11 @@ static inline int board_is_idk(void)
return !strncmp(header.config, SKU#02, 6);
 }
 
+static int board_is_gp_evm(void)
+{
+   return !strncmp(A33515BB, header.name, 8);
+}
+
 int board_is_evm_15_or_later(void)
 {
return (!strncmp(A33515BB, header.name, 8) 
@@ -466,6 +471,28 @@ int board_eth_init(bd_t *bis)
printf(Error %d registering CPSW switch\n, rv);
else
n += rv;
+
+   /*
+*
+* CPSW RGMII Internal Delay Mode is not supported in all PVT
+* operating points.  So we must set the TX clock delay feature
+* in the AR8051 PHY.  Since we only support a single ethernet
+* device in U-Boot, we only do this for the first instance.
+*/
+#define AR8051_PHY_DEBUG_ADDR_REG  0x1d
+#define AR8051_PHY_DEBUG_DATA_REG  0x1e
+#define AR8051_DEBUG_RGMII_CLK_DLY_REG 0x5
+#define AR8051_RGMII_TX_CLK_DLY0x100
+
+   if (board_is_evm_sk() || board_is_gp_evm()) {
+   const char *devname;
+   devname = miiphy_get_current_dev();
+
+   miiphy_write(devname, 0x0, AR8051_PHY_DEBUG_ADDR_REG,
+   AR8051_DEBUG_RGMII_CLK_DLY_REG);
+   miiphy_write(devname, 0x0, AR8051_PHY_DEBUG_DATA_REG,
+   AR8051_RGMII_TX_CLK_DLY);
+   }
 #endif
 try_usbether:
 #if defined(CONFIG_USB_ETHER)  !defined(CONFIG_SPL_BUILD)
-- 
1.7.9.5

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


Re: [U-Boot] [PATCH 2/2] Tegra: MMC: Add DT support to MMC driver for all T20 boards

2013-02-12 Thread Stephen Warren
On 02/12/2013 11:07 AM, Simon Glass wrote:
 Hi,
 
 On Tue, Feb 5, 2013 at 1:02 PM, Tom Warren twarren.nvi...@gmail.com wrote:
 Stephen,

 On Tue, Feb 5, 2013 at 1:03 PM, Stephen Warren swar...@wwwdotorg.org wrote:
 On 02/04/2013 04:48 PM, Tom Warren wrote:
 tegra_mmc_init() now uses DT info for bus width, WP/CD GPIOs, etc.
 Tested on Seaboard, fully functional.

 diff --git a/board/compal/paz00/paz00.c b/board/compal/paz00/paz00.c
 index 1447f47..5cee91a 100644
 --- a/board/compal/paz00/paz00.c
 +++ b/board/compal/paz00/paz00.c
 @@ -55,18 +55,18 @@ static void pin_mux_mmc(void)
  /* this is a weak define that we are overriding */
  int board_mmc_init(bd_t *bd)
  {
 - debug(board_mmc_init called\n);
 + debug(%s called\n, __func__);

   /* Enable muxes, etc. for SDMMC controllers */
   pin_mux_mmc();

 - debug(board_mmc_init: init eMMC\n);
 - /* init dev 0, eMMC chip, with 8-bit bus */
 - tegra_mmc_init(0, 8, -1, -1);
 + debug(%s: init eMMC\n, __func__);
 + /* init dev 0, eMMC chip */
 + tegra_mmc_init(0);

 - debug(board_mmc_init: init SD slot\n);
 - /* init dev 3, SD slot, with 4-bit bus */
 - tegra_mmc_init(3, 4, GPIO_PV1, GPIO_PV5);
 + debug(%s: init SD slot\n, __func__);
 + /* init dev 3, SD slot */
 + tegra_mmc_init(3);

   return 0;
  }

 That doesn't look right. The board code still has knowledge of which
 SDHCI controllers are in use by the board. Instead, the board should
 just call tegra_mmc_init() with no parameters at all, and the MMC driver
 should scan the device tree for all present-and-enabled SDHCI nodes, and
 instantiate a U-Boot SDHCI device. Without this, the device tree isn't
 in control of the whole process, so there's little point doing the
 conversion; a new board couldn't be supported /just/ by creating a new
 device tree file.

 diff --git a/drivers/mmc/tegra_mmc.c b/drivers/mmc/tegra_mmc.c

 +#ifndef CONFIG_OF_CONTROL
 +#error Please enable device tree support to use this driver
 +#endif

 So CONFIG_OF_CONTROL must be enabled ...


  static void tegra_get_setup(struct mmc_host *host, int dev_index)
  {
 - debug(tegra_get_setup: dev_index = %d\n, dev_index);
 + debug(%s: dev_index = %d\n, __func__, dev_index);
 +
 +#ifdef CONFIG_OF_CONTROL

 ... so there's no need for that ifdef

 I took Allen's recent SPI/SLINK driver(s) as an example, but as you
 point out, if CONFIG_OF_CONTROL isn't enabled, you get build errors
 anyway.


 + int count, node = 0;
 + int node_list[MAX_HOSTS];
 +
 + count = fdtdec_find_aliases_for_id(gd-fdt_blob, sdmmc,
 + COMPAT_NVIDIA_TEGRA20_SDMMC, node_list, MAX_HOSTS);
 + debug(%s: count of nodes is %d\n, __func__, count);
 +
 + if (count  dev_index) {
 + printf(%s: device index %d exceeds node count (%d)!\n,
 + __func__, dev_index, count);
 + return;
 + }

 This requires that an alias exist in order for the SDHCI node to be
 found/processed. This isn't correct; the SDHCI nodes must be enumerated
 themselves, and then the aliases (if any are present) provide a naming
 hint for them, but even without aliases, the SDHCI nodes must be processed.

 Again, I used Allen's SLINK driver for as a template here. In fact, it
 looks like our I2C and SPI/SLINK drivers do this, as well as the
 Exynos SPI and S3C24x0 I2C driver all do this.  Can you point out a
 U-Boot driver that does it the right way (preferably with more than 1
 node, like MMC)? I can take a look at that code to use as an example
 of what you're proposing above.
 
 You have it correct already. Stephen please take another look and let
 me know what problem you see with this approach. I'm very sorry that I
 am so late to this discussion.

Could you explain how this works then? The code I looked at (a) was
driven by board files not DT enumerationk (b) errored out if no alias ID
was present.

But given there's a V2, I'll go look at that and check again.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v2 1/2] Tegra: fdt: Add/enhance sdhci (mmc) nodes for all T20 DT files

2013-02-12 Thread Stephen Warren
On 02/11/2013 12:21 PM, Tom Warren wrote:
...
 So the options seem to be:
 
 a) Don't use the tamonton dtsi file, and put the sdhci nodes in the AD
 dts files, just like all other boards (this was my V1 approach).
 Vetoed by Stephen.
 b) Use tegra20-tamonten.dtsi as is, identical to the kernel file. If
 necessary, I can move it's inclusion to a separate patch, independent
 of the MMC DT patchset, as suggested by Lucas.

That option looks fine to me. The initial check-in of the .dts file
should definitely be a separate patch.

Does U-boot actually work correctly if you give it the kernel DT? There
are quite a few quirks that U-Boot relies on IIRC...
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v2 1/2] Tegra: fdt: Add/enhance sdhci (mmc) nodes for all T20 DT files

2013-02-12 Thread Stephen Warren
On 02/12/2013 03:41 AM, Thierry Reding wrote:
...
 So it turned out that I need to touch U-Boot anyway, so I decided
 to give this a spin. I noticed that overriding
 CONFIG_ARCH_DEVICE_TREE from the board configuration file doesn't
 work currently. What happens is that the autoconf.mk (which is
 derived from the board configuration) is included before the CPU
 config.mk which sets CONFIG_ARCH_DEVICE_TREE to tegra20 (or
 tegra30, tegra114). I came up with the attached patch to set the
 variable if not set previously (by the board configuration file).
 
 Feel free to squash that in your patch series if you deem it a
 proper solution. I can also provide a proper separate patch if you
 prefer.

 diff --git a/arch/arm/cpu/armv7/tegra114/config.mk
 b/arch/arm/cpu/armv7/tegra114/config.mk

 -CONFIG_ARCH_DEVICE_TREE := tegra114 +CONFIG_ARCH_DEVICE_TREE ?=
 tegra114

That looks very odd. What value is CONFIG_ARCH_DEVICE_TREE before that
assignment, and why exactly is it wrong?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v2 1/2] Tegra: fdt: Add/enhance sdhci (mmc) nodes for all T20 DT files

2013-02-12 Thread Stephen Warren
On 02/11/2013 10:17 AM, Tom Warren wrote:
 Linux dts files were used for those boards that didn't already
 have sdhci info populated. Tamonten has their own dtsi file with
 common sdhci nodes (sourced from Linux).

 diff --git a/board/nvidia/dts/tegra20-seaboard.dts 
 b/board/nvidia/dts/tegra20-seaboard.dts

   sdhci@c8000400 {
 + status = okay;
   cd-gpios = gpio 69 0; /* gpio PI5 */
   wp-gpios = gpio 57 0; /* gpio PH1 */
 - power-gpios = gpio 70 0; /* gpio PI6 */
 + power-gpios = gpio 70 3; /* gpio PI6 */
 + bus-width = 4;
   };

The 3 for the power-gpios flags looks odd, and doesn't match the
kernel. The binding only defines bit 0 for inverted, and doesn't define
bit 1.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v5 12/23] Add spl load feature

2013-02-12 Thread Scott Wood

On 02/08/2013 09:12:08 AM, Simon Glass wrote:

This adds secondary program loader support to the generic board.

Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

 common/board_f.c | 20 
 1 file changed, 20 insertions(+)

diff --git a/common/board_f.c b/common/board_f.c
index aa10f4b..3a8036f 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -309,6 +309,7 @@ static int reserve_uboot(void)
return 0;
 }

+#ifndef CONFIG_SPL_BUILD
 /* reserve memory for malloc() area */
 static int reserve_malloc(void)
 {
@@ -328,6 +329,7 @@ static int reserve_board(void)
sizeof(bd_t), gd-dest_addr_sp);
return 0;
 }
+#endif

 static int setup_machine(void)
 {
@@ -365,6 +367,7 @@ static int reserve_fdt(void)
return 0;
 }

+#ifndef CONFIG_SPL_BUILD
 static int reserve_stacks(void)
 {
/* setup stack pointer for exceptions */
@@ -384,6 +387,17 @@ static int reserve_stacks(void)

return 0;
 }
+#endif
+
+#ifdef CONFIG_SPL_BUILD
+static int reserve_stacks_spl(void)
+{
+   /* Why not -= ? */
+	gd-dest_addr_sp += 128;	/* leave 32 words for  
abort-stack */

+   gd-irq_sp = gd-dest_addr_sp;
+   return 0;
+}
+#endif


abort-stack doesn't sound very generic, and that why not question  
should probably be answered.



 static int display_new_sp(void)
 {
@@ -524,12 +538,18 @@ static init_fnc_t init_sequence_f[] = {
reserve_lcd,
 #endif
reserve_uboot,
+#ifndef CONFIG_SPL_BUILD
reserve_malloc,
reserve_board,
+#endif
setup_machine,
reserve_global_data,
reserve_fdt,
+#ifdef CONFIG_SPL_BUILD
+   reserve_stacks_spl,
+#else
reserve_stacks,
+#endif


Why not just put the ifdef inside reserve_stacks()?  Or at least give  
them the same name?


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


Re: [U-Boot] [PATCH v2 2/2] Tegra: MMC: Add DT support to MMC driver for all T20 boards

2013-02-12 Thread Stephen Warren
On 02/11/2013 10:17 AM, Tom Warren wrote:
 tegra_mmc_init() now parses the DT info for bus width, WP/CD GPIOs, etc.
 Tested on Seaboard, fully functional.
 
 Tamonten boards (medcom-wide, plutux, and tec) use a different/new
 dtsi file w/common settings.

 diff --git a/drivers/mmc/tegra_mmc.c b/drivers/mmc/tegra_mmc.c

 +static int process_nodes(const void *blob, int node_list[], int count)
...
 + /* build mmc_host[] for each controller */
 + for (i = 0; i  count; i++) {
...
 + /* Mark position as used */
 + node_list[i] = -1;

Is that needed? Does anything use that array after this function?

 diff --git a/include/configs/medcom-wide.h b/include/configs/medcom-wide.h
 diff --git a/include/configs/plutux.h b/include/configs/plutux.h
 diff --git a/include/configs/tec.h b/include/configs/tec.h

In all 3 of those files ...

  #define CONFIG_DEFAULT_DEVICE_TREE   tegra20-medcom-wide

Why not change that define ...

  #define CONFIG_OF_CONTROL
  #define CONFIG_OF_SEPARATE
 +#undef CONFIG_ARCH_DEVICE_TREE
 +#define CONFIG_ARCH_DEVICE_TREE  tegra20-tamonten

rather than adding that one? All the other Tegra boards only set
CONFIG_DEFAULT_DEVICE_TREE.

Aside from the few comments I and others have made, this series looks good.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v5 18/23] ppc: Enable generic board support

2013-02-12 Thread Scott Wood

On 02/08/2013 09:12:14 AM, Simon Glass wrote:

This enables generic board support so that ppc boards can define
CONFIG_SYS_GENERIC_BOARD.

Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

 arch/powerpc/config.mk| 3 ---
 arch/powerpc/include/asm/u-boot.h | 7 +++
 arch/powerpc/lib/Makefile | 2 ++
 3 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/config.mk b/arch/powerpc/config.mk
index bf77090..b706281 100644
--- a/arch/powerpc/config.mk
+++ b/arch/powerpc/config.mk
@@ -29,9 +29,6 @@ PLATFORM_RELFLAGS += -fpic -mrelocatable  
-ffunction-sections -fdata-sections

 PLATFORM_CPPFLAGS += -DCONFIG_PPC -D__powerpc__
 PLATFORM_LDFLAGS  += -n

-# Move to unified board system later
-CONFIG_SYS_LEGACY_BOARD := y
-
 #
 # When cross-compiling on NetBSD, we have to define __PPC__ or else  
we

 # will pick up a va_list declaration that is incompatible with the
diff --git a/arch/powerpc/include/asm/u-boot.h  
b/arch/powerpc/include/asm/u-boot.h

index 7229a98..951dd6a 100644
--- a/arch/powerpc/include/asm/u-boot.h
+++ b/arch/powerpc/include/asm/u-boot.h
@@ -34,6 +34,11 @@
  * include/asm-ppc/u-boot.h
  */

+#ifdef CONFIG_SYS_GENERIC_BOARD
+/* Use the generic board which requires a unified bd_info */
+#include asm-generic/u-boot.h
+#else


Note that a unified bd_info means you're breaking compatibility with  
old, pre-device-tree kernels (including possibly some non-Linux OSes  
that still don't use the device tree) -- in which case why keep it  
around at all?


If you meant for the unified bd_info to be backwards compatible, it's  
missing bi_ip_addr.


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


Re: [U-Boot] [PATCH v2 1/2] Tegra: fdt: Add/enhance sdhci (mmc) nodes for all T20 DT files

2013-02-12 Thread Thierry Reding
On Tue, Feb 12, 2013 at 01:19:18PM -0700, Stephen Warren wrote:
 On 02/12/2013 03:41 AM, Thierry Reding wrote:
 ...
  So it turned out that I need to touch U-Boot anyway, so I decided
  to give this a spin. I noticed that overriding
  CONFIG_ARCH_DEVICE_TREE from the board configuration file doesn't
  work currently. What happens is that the autoconf.mk (which is
  derived from the board configuration) is included before the CPU
  config.mk which sets CONFIG_ARCH_DEVICE_TREE to tegra20 (or
  tegra30, tegra114). I came up with the attached patch to set the
  variable if not set previously (by the board configuration file).
  
  Feel free to squash that in your patch series if you deem it a
  proper solution. I can also provide a proper separate patch if you
  prefer.
 
  diff --git a/arch/arm/cpu/armv7/tegra114/config.mk
  b/arch/arm/cpu/armv7/tegra114/config.mk
 
  -CONFIG_ARCH_DEVICE_TREE := tegra114 +CONFIG_ARCH_DEVICE_TREE ?=
  tegra114
 
 That looks very odd. What value is CONFIG_ARCH_DEVICE_TREE before that
 assignment, and why exactly is it wrong?

Tom's patches add a

#define CONFIG_ARCH_DEVICE_TREE tegra20-tamonten

to the configuration files of Tamonten-derived boards so that the proper
DTSI is picked up. However, that line causes the make variable to be
defined in autoconf.mk, which is included before the CPU config.mk, so
if the config.mk has

CONFIG_ARCH_DEVICE_TREE := tegra20

it will overwrite the value set by autoconf.mk.

Thierry


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


Re: [U-Boot] [PATCH v3 9/9] dfu: Support larger than memory transfers.

2013-02-12 Thread Tom Rini
On Fri, Nov 30, 2012 at 08:01:12PM +0200, Pantelis Antoniou wrote:

 We didn't support upload/download larger than available memory.
 This is pretty bad when you have to update your root filesystem for
 example.
 
 This patch removes the limitation (and the crashes when you transfered
 any file larger than 4MB).
 On top of that reduces the huge dfu buffer from 4MB to just 64K, which
 was over the top.
 
 The sequence number is a 16 bit counter; make sure we
 handle rollover correctly. This fixes the wrong transfers for
 large ( 256MB) images.
 
 Also utilize a variable to handle initialization, so that we
 don't rely on just the counter sent by the host.
 
 Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com

To be clear, patches 1-8 are good and we should take, but this one means
we can't use FAT/EXT* partitions without more work.  I would suggest
that we set this part aside for a moment and perhaps limit transfers
that are larget than RAM to RAW only where we can write in chunks today.

-- 
Tom


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


Re: [U-Boot] [PATCH v2 1/2] Tegra: fdt: Add/enhance sdhci (mmc) nodes for all T20 DT files

2013-02-12 Thread Tom Warren
Stephen,

On Tue, Feb 12, 2013 at 1:29 PM, Stephen Warren swar...@wwwdotorg.org wrote:
 On 02/11/2013 10:17 AM, Tom Warren wrote:
 Linux dts files were used for those boards that didn't already
 have sdhci info populated. Tamonten has their own dtsi file with
 common sdhci nodes (sourced from Linux).

 diff --git a/board/nvidia/dts/tegra20-seaboard.dts 
 b/board/nvidia/dts/tegra20-seaboard.dts

   sdhci@c8000400 {
 + status = okay;
   cd-gpios = gpio 69 0; /* gpio PI5 */
   wp-gpios = gpio 57 0; /* gpio PH1 */
 - power-gpios = gpio 70 0; /* gpio PI6 */
 + power-gpios = gpio 70 3; /* gpio PI6 */
 + bus-width = 4;
   };

 The 3 for the power-gpios flags looks odd, and doesn't match the
 kernel. The binding only defines bit 0 for inverted, and doesn't define
 bit 1.
That came from our internal U-Boot repo - don't know why it's setting
it as an output and asserted and no other Seaboard DT file does. I'll
look into it.

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


Re: [U-Boot] [PATCH v2 2/2] Tegra: MMC: Add DT support to MMC driver for all T20 boards

2013-02-12 Thread Tom Warren
Stephen,

On Tue, Feb 12, 2013 at 1:38 PM, Stephen Warren swar...@wwwdotorg.org wrote:
 On 02/11/2013 10:17 AM, Tom Warren wrote:
 tegra_mmc_init() now parses the DT info for bus width, WP/CD GPIOs, etc.
 Tested on Seaboard, fully functional.

 Tamonten boards (medcom-wide, plutux, and tec) use a different/new
 dtsi file w/common settings.

 diff --git a/drivers/mmc/tegra_mmc.c b/drivers/mmc/tegra_mmc.c

 +static int process_nodes(const void *blob, int node_list[], int count)
 ...
 + /* build mmc_host[] for each controller */
 + for (i = 0; i  count; i++) {
 ...
 + /* Mark position as used */
 + node_list[i] = -1;

 Is that needed? Does anything use that array after this function?
No idea. I took this code from the tegra_i2c.c driver.


 diff --git a/include/configs/medcom-wide.h b/include/configs/medcom-wide.h
 diff --git a/include/configs/plutux.h b/include/configs/plutux.h
 diff --git a/include/configs/tec.h b/include/configs/tec.h

 In all 3 of those files ...

  #define CONFIG_DEFAULT_DEVICE_TREE   tegra20-medcom-wide

 Why not change that define ...

  #define CONFIG_OF_CONTROL
  #define CONFIG_OF_SEPARATE
 +#undef CONFIG_ARCH_DEVICE_TREE
 +#define CONFIG_ARCH_DEVICE_TREE  tegra20-tamonten

 rather than adding that one? All the other Tegra boards only set
 CONFIG_DEFAULT_DEVICE_TREE.

CONFIG_DEFAULT_DEVICE_TREE is the .dts file (board/nvidia/dts).
CONFIG_ARCH_DEVICE_TREE is the .dtsi file (arch/arm/dts). See
Thierry's explanation, also.


 Aside from the few comments I and others have made, this series looks good.
Thanks. Working on V3.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v2 2/2] Tegra: MMC: Add DT support to MMC driver for all T20 boards

2013-02-12 Thread Stephen Warren
On 02/12/2013 01:57 PM, Tom Warren wrote:
 Stephen,
 
 On Tue, Feb 12, 2013 at 1:38 PM, Stephen Warren swar...@wwwdotorg.org wrote:
 On 02/11/2013 10:17 AM, Tom Warren wrote:
 tegra_mmc_init() now parses the DT info for bus width, WP/CD GPIOs, etc.
 Tested on Seaboard, fully functional.

 Tamonten boards (medcom-wide, plutux, and tec) use a different/new
 dtsi file w/common settings.

 diff --git a/include/configs/medcom-wide.h b/include/configs/medcom-wide.h
 diff --git a/include/configs/plutux.h b/include/configs/plutux.h
 diff --git a/include/configs/tec.h b/include/configs/tec.h

 In all 3 of those files ...

  #define CONFIG_DEFAULT_DEVICE_TREE   tegra20-medcom-wide

 Why not change that define ...

  #define CONFIG_OF_CONTROL
  #define CONFIG_OF_SEPARATE
 +#undef CONFIG_ARCH_DEVICE_TREE
 +#define CONFIG_ARCH_DEVICE_TREE  tegra20-tamonten

 rather than adding that one? All the other Tegra boards only set
 CONFIG_DEFAULT_DEVICE_TREE.
 
 CONFIG_DEFAULT_DEVICE_TREE is the .dts file (board/nvidia/dts).
 CONFIG_ARCH_DEVICE_TREE is the .dtsi file (arch/arm/dts). See
 Thierry's explanation, also.

So why set CONFIG_ARCH_DEVICE_TREE to tegra20-tamonten here; if that
variable is supposed to point at the SoC .dtsi file, that value is
wrong; it *should* be tegra20.dtsi.

Oh yuck. I see what's going on now. e.g. tegra20-medcom-wide.dts is
including ARCH_CPU_DTS. It should be including tegra20-tamonten.dtsi,
which then includes ARCH_CPU_DTS. The ARCH_CPU_DTS variable is supposed
to only ever point at the SoC .dtsi file, not any intermediate .dtsi
file... You probably need to put tegra20-tamonten.dtsi into
board/avionic-design/dts rather than arch/arm/dts to make that work.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [GIT PULL] u-boot-mips/next

2013-02-12 Thread Tom Rini
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/12/2013 05:10 PM, Daniel Schwierzeck wrote:
 Hi Tom,
 
 The following changes since commit 
 58864ddc7276ca7403ddbb716da5853638f37519:
 
 Clean up libfdt.h includes (2013-02-08 22:32:38 -0500)
 
 are available in the git repository at:
 
 git://git.denx.de/u-boot-mips.git next
 
 for you to fetch changes up to 
 04380c651a2ff0d1495822321d2b7668dcd02537:
 
 MIPS: add dynamic relocation support (2013-02-12 22:22:13 +0100)
 
  
 Daniel Schwierzeck (8): MIPS: xburst: fix broken access to 
 global_data MIPS: start.S: remove obsolete 64 bit handling in 
 setup_c0_status MIPS: start.S: unify and simplify reset vector 
 handling MIPS: u-boot.lds: merge all BSS sections and introduce 
 symbols __bss_[start|end] MIPS: u-boot.lds: introduce symbol 
 __image_copy_end MIPS: board.c: switch to new symbols __bss_end
 and __image_copy_end MIPS: start.S: optimize BSS initialization
 MIPS: start.S: use symbol __image_copy_end for U-Boot image
 relocation
 
 Gabor Juhos (3): MIPS: compute num_got_entries from .got section's 
 size MIPS: u-boot.lds: add relocation specific sections MIPS: add 
 dynamic relocation support

To be clear, is this for master or next?  The merge window closed, but
I haven't tagged -rc1 or anything yet (and won't for a bit longer, to
give folks time to pick up patches).  Thanks!

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

iQIcBAEBAgAGBQJRGr7+AAoJENk4IS6UOR1WBu8P+gNXnJ+jr/4c4g627x2YsOHp
fSwf2xQC6ydH9k3JSJj9vOEG5M6juqJqM2wFjt+fX13nZ8e7ineh8l1TZjzGADsr
kQiqNUu/Vhk1mFuktKKlaCmZI2VxE508VEEsxHDH952p5BnCE/TG2RBQX+nDzDCX
lyeFiWpWbtOa+g48gL/lhbmzIk9rVJLntGB4bd8rojrLybAkUjB7OBlUWfG+9G6h
IY60lvoMFqwiPX8mGcOQ9mPtjJouMUC8IdhDEDbJnki061+amfD3V+uEOvPNslJ/
NMuNZ+opcbi1kqm+uUAF5Q02UP3Rju3Z11KN8bwNaJjj0sEZWYAGrK+DpQr6imcb
dcHgjaYY0hXlyBHj2g4cRkupU6fS7T/oh+alZGfCUoBqxJ/PHcCMcE5OtYPxiSaI
Cale198Oi2yHXjrpenQCoMkrwjB/z+gKnD32SrmLUC+um5YI7I9sL718gd/FRGv7
G0GsRSKml8cjng+1VETzfxPAhY4/xl7cCayV033j6IMTDEL+O1+lUweIIpOYBzpD
sEIQ+P8iZpbd95i87BECNvPT1blVcjGs3kL32aZuE4zlHvfKArbsrFpgCmul1ynI
AMiYbreWdvxISjmyLRKCu+YJ4xpwg/JdSXYp3vALZ4iEcbI8nB+BOD2lvFyg1u+h
uYW+h++tadt/YQl0Q3I5
=Ve42
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v5 12/23] Add spl load feature

2013-02-12 Thread Simon Glass
+Albert

Hi Scott,

On Tue, Feb 12, 2013 at 12:29 PM, Scott Wood scottw...@freescale.com wrote:
 On 02/08/2013 09:12:08 AM, Simon Glass wrote:

 This adds secondary program loader support to the generic board.

 Signed-off-by: Simon Glass s...@chromium.org
 ---
 Changes in v5: None
 Changes in v4: None
 Changes in v3: None
 Changes in v2: None

  common/board_f.c | 20 
  1 file changed, 20 insertions(+)

 diff --git a/common/board_f.c b/common/board_f.c
 index aa10f4b..3a8036f 100644
 --- a/common/board_f.c
 +++ b/common/board_f.c
 @@ -309,6 +309,7 @@ static int reserve_uboot(void)
 return 0;
  }

 +#ifndef CONFIG_SPL_BUILD
  /* reserve memory for malloc() area */
  static int reserve_malloc(void)
  {
 @@ -328,6 +329,7 @@ static int reserve_board(void)
 sizeof(bd_t), gd-dest_addr_sp);
 return 0;
  }
 +#endif

  static int setup_machine(void)
  {
 @@ -365,6 +367,7 @@ static int reserve_fdt(void)
 return 0;
  }

 +#ifndef CONFIG_SPL_BUILD
  static int reserve_stacks(void)
  {
 /* setup stack pointer for exceptions */
 @@ -384,6 +387,17 @@ static int reserve_stacks(void)

 return 0;
  }
 +#endif
 +
 +#ifdef CONFIG_SPL_BUILD
 +static int reserve_stacks_spl(void)
 +{
 +   /* Why not -= ? */
 +   gd-dest_addr_sp += 128;/* leave 32 words for abort-stack
 */
 +   gd-irq_sp = gd-dest_addr_sp;
 +   return 0;
 +}
 +#endif


 abort-stack doesn't sound very generic, and that why not question should
 probably be answered.

I'm not sure what you mean by the first comment. For the second, I
agree. It looks wrong to me. I copied Albert who might know.



  static int display_new_sp(void)
  {
 @@ -524,12 +538,18 @@ static init_fnc_t init_sequence_f[] = {
 reserve_lcd,
  #endif
 reserve_uboot,
 +#ifndef CONFIG_SPL_BUILD
 reserve_malloc,
 reserve_board,
 +#endif
 setup_machine,
 reserve_global_data,
 reserve_fdt,
 +#ifdef CONFIG_SPL_BUILD
 +   reserve_stacks_spl,
 +#else
 reserve_stacks,
 +#endif


 Why not just put the ifdef inside reserve_stacks()?  Or at least give them
 the same name?

OK I will do that.


 -Scott

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


Re: [U-Boot] [GIT PULL] u-boot-mips/next

2013-02-12 Thread Daniel Schwierzeck
2013/2/12 Tom Rini tr...@ti.com:

 To be clear, is this for master or next?  The merge window closed, but
 I haven't tagged -rc1 or anything yet (and won't for a bit longer, to
 give folks time to pick up patches).  Thanks!


it is for master. I needed a few days longer for review and test.
Also I didn't want to rebase the u-boot-mips/master branch so I used next.

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


Re: [U-Boot] [PATCH v5 18/23] ppc: Enable generic board support

2013-02-12 Thread Simon Glass
Hi Scott,

On Tue, Feb 12, 2013 at 12:38 PM, Scott Wood scottw...@freescale.com wrote:
 On 02/08/2013 09:12:14 AM, Simon Glass wrote:

 This enables generic board support so that ppc boards can define
 CONFIG_SYS_GENERIC_BOARD.

 Signed-off-by: Simon Glass s...@chromium.org
 ---
 Changes in v5: None
 Changes in v4: None
 Changes in v3: None
 Changes in v2: None

  arch/powerpc/config.mk| 3 ---
  arch/powerpc/include/asm/u-boot.h | 7 +++
  arch/powerpc/lib/Makefile | 2 ++
  3 files changed, 9 insertions(+), 3 deletions(-)

 diff --git a/arch/powerpc/config.mk b/arch/powerpc/config.mk
 index bf77090..b706281 100644
 --- a/arch/powerpc/config.mk
 +++ b/arch/powerpc/config.mk
 @@ -29,9 +29,6 @@ PLATFORM_RELFLAGS += -fpic -mrelocatable
 -ffunction-sections -fdata-sections
  PLATFORM_CPPFLAGS += -DCONFIG_PPC -D__powerpc__
  PLATFORM_LDFLAGS  += -n

 -# Move to unified board system later
 -CONFIG_SYS_LEGACY_BOARD := y
 -
  #
  # When cross-compiling on NetBSD, we have to define __PPC__ or else we
  # will pick up a va_list declaration that is incompatible with the
 diff --git a/arch/powerpc/include/asm/u-boot.h
 b/arch/powerpc/include/asm/u-boot.h
 index 7229a98..951dd6a 100644
 --- a/arch/powerpc/include/asm/u-boot.h
 +++ b/arch/powerpc/include/asm/u-boot.h
 @@ -34,6 +34,11 @@
   * include/asm-ppc/u-boot.h
   */

 +#ifdef CONFIG_SYS_GENERIC_BOARD
 +/* Use the generic board which requires a unified bd_info */
 +#include asm-generic/u-boot.h
 +#else


 Note that a unified bd_info means you're breaking compatibility with old,
 pre-device-tree kernels (including possibly some non-Linux OSes that still
 don't use the device tree) -- in which case why keep it around at all?

It's not intended to break things - are you saying that every arch is
defined to use a different variant of bd_t in these OSes, or are you
just referring to PPC?


 If you meant for the unified bd_info to be backwards compatible, it's
 missing bi_ip_addr.

OK, I see. I saw a commit that punted it, so I punted it. I didn't
notice the re-add later. I will put it back.

Regards,
Simon


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


Re: [U-Boot] [PATCH v5 16/23] Adjust board_f.c for ppc

2013-02-12 Thread Scott Wood

On 02/08/2013 09:12:12 AM, Simon Glass wrote:

 #ifndef CONFIG_SPL_BUILD
 static int reserve_stacks(void)
 {
+#ifdef CONFIG_PPC
+   ulong *s;
+#endif
+
/* setup stack pointer for exceptions */
gd-dest_addr_sp -= 16;
gd-dest_addr_sp = ~0xf;
@@ -398,6 +532,14 @@ static int reserve_stacks(void)
/* leave 3 words for abort-stack, plus 1 for alignment */
gd-dest_addr_sp -= 16;

+#ifdef CONFIG_PPC
+   /* Clear initial stack frame */
+   s = (ulong *) gd-dest_addr_sp;
+   *s = 0; /* Terminate back chain */
+   *++s = 0; /* NULL return address */
+   gd-dest_addr_sp = (ulong) s;
+#endif
+


PPC ABI requires 16-byte stack alignment, which would be broken by the  
CONFIG_USE_IRQ section (which even still has an ARM ABI comment).


I think this entire function should be kept in arch code.  Stack layout  
is inherently architecture/ABI specific.  Some architectures even have  
a stack that grows upward (not sure if any such are supported by  
U-Boot).


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


Re: [U-Boot] [PATCH v5 12/23] Add spl load feature

2013-02-12 Thread Scott Wood

On 02/12/2013 04:23:21 PM, Simon Glass wrote:

+Albert

Hi Scott,

On Tue, Feb 12, 2013 at 12:29 PM, Scott Wood  
scottw...@freescale.com wrote:

 On 02/08/2013 09:12:08 AM, Simon Glass wrote:

 This adds secondary program loader support to the generic board.

 Signed-off-by: Simon Glass s...@chromium.org
 ---
 Changes in v5: None
 Changes in v4: None
 Changes in v3: None
 Changes in v2: None

  common/board_f.c | 20 
  1 file changed, 20 insertions(+)

 diff --git a/common/board_f.c b/common/board_f.c
 index aa10f4b..3a8036f 100644
 --- a/common/board_f.c
 +++ b/common/board_f.c
 @@ -309,6 +309,7 @@ static int reserve_uboot(void)
 return 0;
  }

 +#ifndef CONFIG_SPL_BUILD
  /* reserve memory for malloc() area */
  static int reserve_malloc(void)
  {
 @@ -328,6 +329,7 @@ static int reserve_board(void)
 sizeof(bd_t), gd-dest_addr_sp);
 return 0;
  }
 +#endif

  static int setup_machine(void)
  {
 @@ -365,6 +367,7 @@ static int reserve_fdt(void)
 return 0;
  }

 +#ifndef CONFIG_SPL_BUILD
  static int reserve_stacks(void)
  {
 /* setup stack pointer for exceptions */
 @@ -384,6 +387,17 @@ static int reserve_stacks(void)

 return 0;
  }
 +#endif
 +
 +#ifdef CONFIG_SPL_BUILD
 +static int reserve_stacks_spl(void)
 +{
 +   /* Why not -= ? */
 +   gd-dest_addr_sp += 128;/* leave 32 words for  
abort-stack

 */
 +   gd-irq_sp = gd-dest_addr_sp;
 +   return 0;
 +}
 +#endif


 abort-stack doesn't sound very generic, and that why not  
question should

 probably be answered.

I'm not sure what you mean by the first comment.


It's ARM-specific terminology (exception is more typical than abort  
elsewhere).  Why 32 words, BTW?  Why is it larger in SPL versus non-SPL?


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


Re: [U-Boot] [PATCH 2/2] Tegra: MMC: Add DT support to MMC driver for all T20 boards

2013-02-12 Thread Simon Glass
Hi Stephen,

On Tue, Feb 12, 2013 at 12:13 PM, Stephen Warren swar...@wwwdotorg.org wrote:
 On 02/12/2013 11:07 AM, Simon Glass wrote:
 Hi,

 On Tue, Feb 5, 2013 at 1:02 PM, Tom Warren twarren.nvi...@gmail.com wrote:
 Stephen,

 On Tue, Feb 5, 2013 at 1:03 PM, Stephen Warren swar...@wwwdotorg.org 
 wrote:
 On 02/04/2013 04:48 PM, Tom Warren wrote:
 tegra_mmc_init() now uses DT info for bus width, WP/CD GPIOs, etc.
 Tested on Seaboard, fully functional.

 diff --git a/board/compal/paz00/paz00.c b/board/compal/paz00/paz00.c
 index 1447f47..5cee91a 100644
 --- a/board/compal/paz00/paz00.c
 +++ b/board/compal/paz00/paz00.c
 @@ -55,18 +55,18 @@ static void pin_mux_mmc(void)
  /* this is a weak define that we are overriding */
  int board_mmc_init(bd_t *bd)
  {
 - debug(board_mmc_init called\n);
 + debug(%s called\n, __func__);

   /* Enable muxes, etc. for SDMMC controllers */
   pin_mux_mmc();

 - debug(board_mmc_init: init eMMC\n);
 - /* init dev 0, eMMC chip, with 8-bit bus */
 - tegra_mmc_init(0, 8, -1, -1);
 + debug(%s: init eMMC\n, __func__);
 + /* init dev 0, eMMC chip */
 + tegra_mmc_init(0);

 - debug(board_mmc_init: init SD slot\n);
 - /* init dev 3, SD slot, with 4-bit bus */
 - tegra_mmc_init(3, 4, GPIO_PV1, GPIO_PV5);
 + debug(%s: init SD slot\n, __func__);
 + /* init dev 3, SD slot */
 + tegra_mmc_init(3);

   return 0;
  }

 That doesn't look right. The board code still has knowledge of which
 SDHCI controllers are in use by the board. Instead, the board should
 just call tegra_mmc_init() with no parameters at all, and the MMC driver
 should scan the device tree for all present-and-enabled SDHCI nodes, and
 instantiate a U-Boot SDHCI device. Without this, the device tree isn't
 in control of the whole process, so there's little point doing the
 conversion; a new board couldn't be supported /just/ by creating a new
 device tree file.

 diff --git a/drivers/mmc/tegra_mmc.c b/drivers/mmc/tegra_mmc.c

 +#ifndef CONFIG_OF_CONTROL
 +#error Please enable device tree support to use this driver
 +#endif

 So CONFIG_OF_CONTROL must be enabled ...


  static void tegra_get_setup(struct mmc_host *host, int dev_index)
  {
 - debug(tegra_get_setup: dev_index = %d\n, dev_index);
 + debug(%s: dev_index = %d\n, __func__, dev_index);
 +
 +#ifdef CONFIG_OF_CONTROL

 ... so there's no need for that ifdef

 I took Allen's recent SPI/SLINK driver(s) as an example, but as you
 point out, if CONFIG_OF_CONTROL isn't enabled, you get build errors
 anyway.


 + int count, node = 0;
 + int node_list[MAX_HOSTS];
 +
 + count = fdtdec_find_aliases_for_id(gd-fdt_blob, sdmmc,
 + COMPAT_NVIDIA_TEGRA20_SDMMC, node_list, MAX_HOSTS);
 + debug(%s: count of nodes is %d\n, __func__, count);
 +
 + if (count  dev_index) {
 + printf(%s: device index %d exceeds node count (%d)!\n,
 + __func__, dev_index, count);
 + return;
 + }

 This requires that an alias exist in order for the SDHCI node to be
 found/processed. This isn't correct; the SDHCI nodes must be enumerated
 themselves, and then the aliases (if any are present) provide a naming
 hint for them, but even without aliases, the SDHCI nodes must be processed.

 Again, I used Allen's SLINK driver for as a template here. In fact, it
 looks like our I2C and SPI/SLINK drivers do this, as well as the
 Exynos SPI and S3C24x0 I2C driver all do this.  Can you point out a
 U-Boot driver that does it the right way (preferably with more than 1
 node, like MMC)? I can take a look at that code to use as an example
 of what you're proposing above.

 You have it correct already. Stephen please take another look and let
 me know what problem you see with this approach. I'm very sorry that I
 am so late to this discussion.

 Could you explain how this works then? The code I looked at (a) was
 driven by board files not DT enumerationk (b) errored out if no alias ID
 was present.

 But given there's a V2, I'll go look at that and check again.

I'm really talking about the function fdtdec_add_aliases_for_id(). It
is designed to do exactly what you wanted, from memory, except that it
only supports a single compatible ID. If there is no alias node, then
it should still find all the compatible nodes. The alias node is only
used to order them.

In terms of being driver by board files, it is best if the drivers do
this, so that the enumeration is independent of any board file.

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


  1   2   >