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

[Stefano Babic]

On 11/02/2013 22:12, Otavio Salvador wrote:
> On Mon, Nov 12, 2012 at 8:59 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 
> 
> 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

[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 
> ---
> 
> 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

[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 
---
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

[Stefano Babic]

Add a more descriptive text to the help of the spl
command.

Signed-off-by: Stefano Babic 
---
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  [kernel_addr] [initrd_addr] "
-   "[fdt_addr if  = fdt] - export a kernel parameter image\n"
-   "\t initrd_img can be set to \"-\" if fdt_addr without initrd img is"
-   "used");
+   "export  [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

[Stefano Babic]

Simple howto to add support to a board
for booting the kernel from SPL ("Falcon" mode).

Signed-off-by: Stefano Babic 
---
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  + 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  [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 of the device tree.
+

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

[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 
CC: Prafulla Wadaskar 
CC: Sebastian Hesselbarth 
CC: Daniel Stodden 
---
 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 
-.br
-Luka Perkov 
-.br
-David Purdy 
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 over \fITTY\fP.
+
+Note that for the encapsulated boot code to be executed, \fIimage\fP
+must be of type "UART

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

[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 
> ---
> 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

[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 
> ---
> 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 
> +
> +#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

[Luka Perkov]

From: Sebastian Hesselbarth 

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 
Signed-off-by: Daniel Stodden 
Signed-off-by: Luka Perkov 
Cc: Prafulla Wadaskar 
Cc: Rabeeh Khoury 
---

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 
  *
@@ -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 : boot \n");
fprintf(stream, "  -p: patch  to type 0x69 (uart boot)\n");
fprintf(stream, "\n");
+   fprintf(stream, "  -n: don't send boot message\n");
fprintf(stream, "  -t: mini terminal\n");
fprintf(stream, "\n");
fprintf(stream, "  -B : set baud rate\n");
@@

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

[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

[Piotr Wilczek]

From: Lukasz Majewski 

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

commit d26a6aa08b9f12b44fb1ee65625e7480d3d5bb81
Author: Michal Nazarewicz 
Date:   Mon Nov 9 14:15:23 2009 +0100

USB: g_mass_storage: code cleaned up and comments updated

Signed-off-by: Lukasz Majewski 
Signed-off-by: Andrzej Pietrasiewicz 
Signed-off-by: Kyungmin Park 
CC: Marek Vasut 
---
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 
+ *
+ * Code refactoring & cleanup:
+ * Łukasz Majewski 
+ *
+ * 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  */
+
+
+/*
+ * 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 those macros are already defined (which
+ * would indicate composite.h had been included) or not (which would
+ * indicate we were in FSG) but this is not done because a warning is
+ * 

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

[Piotr Wilczek]

From: Lukasz Majewski 

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 
Signed-off-by: Piotr Wilczek 
Signed-off-by: Kyungmin Park 
CC: Marek Vasut 
---
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 
+ *
+ * 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 
+#include 
+#include 
+#include 
+#include 
+
+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  - 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);
return -EINVAL;
diff --git a/include/usb_mass_storage.h b/include/usb_mass_storage.h
new file mode 100644
index 000..ffc3a13
---

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

[Piotr Wilczek]

From: Lukasz Majewski 

This patch enables new "ums" command on Trats board

Signed-off-by: Lukasz Majewski 
Signed-off-by: Piotr Wilczek 
Signed-off-by: Kyungmin Park 
CC: Minkyu Kang 
---
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 
 #include 
 #include 
+#include 
 
 #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

[Vivek Gautam]

Hi Minkyu,


On Tue, Feb 12, 2013 at 1:54 PM, Minkyu Kang  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 
>> ---
>>
>> 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

[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
> >  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  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 
> > >> >> ---
> > >> >> 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 
> 
> 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 .
 #
-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 c

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

[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
> > >  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  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 
> > > >> >> ---
> > > >> >> 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 
> > 
> > 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 .
>  #
> -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

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

[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 
> ---
> 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 

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

[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.

[R Sricharan]

Adding the CPU detection suport for OMAP5430 and
OMAP5432 ES2.0 SOCs.

Signed-off-by: R Sricharan 
Cc: Tom Rini 
Cc: Nishanth Menon 
---
 [v2] Addressed Tom Rini's  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

[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 
Reviewed-by: Tom Rini 
Cc: Tom Rini 
---
 [v2] Addressed Tom Rini's  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 = 0x4a008114,
+   .cm_core_dvfs_perf3 = 0x4a008118,
+ 

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

[R Sricharan]

From: Lokesh Vutla 

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 
Signed-off-by: Lokesh Vutla 
Reviewed-by: Tom Rini 
Cc: Tom Rini 
---
 [v2] Addressed Tom Rini's  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 **regs)
case OMAP5432_ES1_0:
*regs = &emif_regs_ddr3_532_mhz_1cs;
 

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

[R Sricharan]

From: Lokesh Vutla 

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 
Signed-off-by: Lokesh Vutla 
Reviewed-by: Tom Rini 
Cc: Tom Rini 
---
 [v2] Addressed Tom Rini's  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 
 #include 
 #include 
+#include 
 
 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 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -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) |
+   (div_factor << DIVIDE_FACTOR_XS_SHIFT);
+   writel(srcomp_value, (*ctrl)->control_srcomp_east_side_wkup);
+
+   for (i = 0; i < 4; i++) {
+   srcomp_value =
+

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

[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 
Signed-off-by: R Sricharan 
Cc: Tom Rini 
Cc: Nishanth Menon 
---
 [v2] Addressed Tom Rini's  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},/* 12 MHz   */
+   {800, 12, 1

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

[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 
> ---
> 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  + 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  [kernel_addr] [initrd_addr] [

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

[Stefan Roese]

On 12.02.2013 12:48, Andreas Bießmann wrote:



> 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

[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 
> ---

Acked-by: Stefano Babic 

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

[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:



> 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

[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

[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

[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 
> ---
>  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

[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 
> ---

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

[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

[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

[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 
> > > > ---
> > > > 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 /lowlevel_init.S or /.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

[Albert ARIBAUD]

Hi Tom,

On Mon, 11 Feb 2013 14:20:00 -0700, Tom Warren
 wrote:

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

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

> -- Forwarded message --
> From: Tom Warren 
> Date: Mon, Feb 11, 2013 at 11:05 AM
> Subject: pull request for u-boot-tegra/master into ARM/master
> To: Albert ARIBAUD 
> Cc: Tom Warren , Stephen Warren
> , Simon Glass , Wolfgang Denk
> , Allen Martin , Lucas Stach
> 
> 
> 
> 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  |2 +-
>  board/compulab/dts/tegra20-trimslice.dts 

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

[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

[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 generi

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

[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

[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

[Otavio Salvador]

On Tue, Feb 12, 2013 at 6: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 
> ---
> 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  + 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
> +--

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

[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 
> ---
>  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

[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

[Otavio Salvador]

On Tue, Feb 12, 2013 at 12:01 PM, Benoît Thébaudeau
 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

[Koen Kooi]

Signed-off-by: Koen Kooi 
---
 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

[Koen Kooi]

The kernel is loaded from an ext4 partition, not ext2 on beaglebone boards.

Signed-off-by: Koen Kooi 
---
 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

[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 
+ * 
+ * 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

[Tom Warren]

Thierry,

On Tue, Feb 12, 2013 at 3:53 AM, Thierry Reding
 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
>> > >  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  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 
>> > > >> >> ---
>> > > >> >> 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 
>> >
>> > 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 .
>>  #
>> -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/teg

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

[Tom Warren]

Laxman,

On Tue, Feb 12, 2013 at 5:02 AM, Laxman Dewangan  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

[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 
---
 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

[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
>  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

[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 
> ---


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

[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 
> ---

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

[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 
> ---

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

[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

[Simon Glass]

Hi Stephen,

On Tue, Feb 5, 2013 at 12:03 PM, Stephen Warren  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

[Simon Glass]

Hi,

On Tue, Feb 5, 2013 at 1:02 PM, Tom Warren  wrote:
> Stephen,
>
> On Tue, Feb 5, 2013 at 1:03 PM, Stephen Warren  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

[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

[Stephen Warren]

On 02/12/2013 10:40 AM, Tom Warren wrote:
> Laxman,
> 
> On Tue, Feb 12, 2013 at 5:02 AM, Laxman Dewangan  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

[Simon Glass]

Hi Stephen,

On Thu, Feb 7, 2013 at 10:17 AM, Stephen Warren  wrote:
> On 02/07/2013 09:14 AM, Tom Warren wrote:
>> Stephen,
>>
>> On Wed, Feb 6, 2013 at 5:00 PM, Stephen Warren  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 controll

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

[Simon Glass]

Hi,

On Fri, Feb 8, 2013 at 9:25 AM, Tom Warren  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

[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]

[Simon Glass]

Hi,

On Thu, Feb 7, 2013 at 9:16 AM, Lucas Stach  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 
> Acked-by: Simon Glass 

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

[Simon Glass]

Hi Scott,

On Mon, Feb 11, 2013 at 11:52 AM, Scott Wood  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 
>> ---
>> 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

[Simon Glass]

Hi Scott,

On Tue, Feb 12, 2013 at 10:50 AM, Scott Wood  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 
>> 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 
>> >> ---
>> >> 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

[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 2/2] Tegra: MMC: Add DT support to MMC driver for all T20 boards

[Tom Warren]

Simon,

On Tue, Feb 12, 2013 at 11:07 AM, Simon Glass  wrote:
> Hi,
>
> On Tue, Feb 5, 2013 at 1:02 PM, Tom Warren  wrote:
>> Stephen,
>>
>> On Tue, Feb 5, 2013 at 1:03 PM, Stephen Warren  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.

>
>>>
 + /*
 +  * 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 s

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

[Simon Glass]

Hi Scott,

On Tue, Feb 12, 2013 at 11:04 AM, Scott Wood  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

[Tom Warren]

Stephen,

On Tue, Feb 12, 2013 at 11:10 AM, Stephen Warren  wrote:
> On 02/12/2013 10:40 AM, Tom Warren wrote:
>> Laxman,
>>
>> On Tue, Feb 12, 2013 at 5:02 AM, Laxman Dewangan  
>> 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

[Simon Glass]

Hi Tom,

On Tue, Feb 12, 2013 at 11:05 AM, Tom Warren  wrote:
> Simon,
>
> On Tue, Feb 12, 2013 at 11:07 AM, Simon Glass  wrote:
>> Hi,
>>
>> On Tue, Feb 5, 2013 at 1:02 PM, Tom Warren  wrote:
>>> Stephen,
>>>
>>> On Tue, Feb 5, 2013 at 1:03 PM, Stephen Warren  
>>> 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 i

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

[Tom Warren]

Simon,

On Tue, Feb 12, 2013 at 11:13 AM, Simon Glass  wrote:
> Hi Stephen,
>
> On Thu, Feb 7, 2013 at 10:17 AM, Stephen Warren  wrote:
>> On 02/07/2013 09:14 AM, Tom Warren wrote:
>>> Stephen,
>>>
>>> On Wed, Feb 6, 2013 at 5:00 PM, Stephen Warren  
>>> 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

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

[Simon Glass]

Hi Tom,

On Tue, Feb 12, 2013 at 11:13 AM, Tom Warren  wrote:
> Simon,
>
> On Tue, Feb 12, 2013 at 11:13 AM, Simon Glass  wrote:
>> Hi Stephen,
>>
>> On Thu, Feb 7, 2013 at 10:17 AM, Stephen Warren  
>> wrote:
>>> On 02/07/2013 09:14 AM, Tom Warren wrote:
 Stephen,

 On Wed, Feb 6, 2013 at 5:00 PM, Stephen Warren  
 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
>> fas

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

[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 
---
  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

[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  
 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 
>> ---
>> 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.

[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 
---
 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

[Tom Warren]

Lucas,

On Mon, Feb 11, 2013 at 10:59 AM, Tom Warren  wrote:
> Lucas,
>
> On Mon, Feb 11, 2013 at 10:33 AM, Lucas Stach  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 
>>> ---
>>> 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

[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  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

[Simon Glass]

Hi Stephen,

On Tue, Feb 12, 2013 at 11:26 AM, Stephen Warren  wrote:
> On 02/12/2013 12:17 PM, Simon Glass wrote:
>> Hi Tom,
>>
>> On Tue, Feb 12, 2013 at 11:13 AM, Tom Warren  
>> 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

[Tom Warren]

On Tue, Feb 12, 2013 at 12:26 PM, Stephen Warren  wrote:
> On 02/12/2013 12:17 PM, Simon Glass wrote:
>> Hi Tom,
>>
>> On Tue, Feb 12, 2013 at 11:13 AM, Tom Warren  
>> 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

[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.

[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  --- 
>>> 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

[Tom Warren]

Lucas,

On Tue, Feb 12, 2013 at 12:41 PM, Lucas Stach  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

[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 
---
 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

[Stephen Warren]

On 02/12/2013 11:07 AM, Simon Glass wrote:
> Hi,
> 
> On Tue, Feb 5, 2013 at 1:02 PM, Tom Warren  wrote:
>> Stephen,
>>
>> On Tue, Feb 5, 2013 at 1:03 PM, Stephen Warren  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

[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

[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

[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

[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 
---
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

[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

[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 
---
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 
+#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

[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.

[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 

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

[Tom Warren]

Stephen,

On Tue, Feb 12, 2013 at 1:29 PM, Stephen Warren  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

[Tom Warren]

Stephen,

On Tue, Feb 12, 2013 at 1:38 PM, Stephen Warren  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

[Stephen Warren]

On 02/12/2013 01:57 PM, Tom Warren wrote:
> Stephen,
> 
> On Tue, Feb 12, 2013 at 1:38 PM, Stephen Warren  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

[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

[Simon Glass]

+Albert

Hi Scott,

On Tue, Feb 12, 2013 at 12:29 PM, Scott Wood  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 
>> ---
>> 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

[Daniel Schwierzeck]

2013/2/12 Tom Rini :
>
> 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

[Simon Glass]

Hi Scott,

On Tue, Feb 12, 2013 at 12:38 PM, Scott Wood  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 
>> ---
>> 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 
>> +#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

[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

[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  
 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 
>> ---
>> 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