Re: [U-Boot] [PATCH] Add README for the Falcon mode
On 11/02/2013 22:12, Otavio Salvador wrote: On Mon, Nov 12, 2012 at 8:59 AM, Stefano Babic sba...@denx.de wrote: Simple howto to add support to a board for booting the kernel from SPL (Falcon mode). Signed-off-by: Stefano Babic sba...@denx.de Could this be updated and resend? This is an interesting feature which lacks documentation currently. Hi Otavio, you are right, and thanks to point out that the documentation is not yet merged. I will push a V5 as I promised with fixes for the last comments. Regards, Stefano -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] usb: ehci: exynos: Enable non-dt path
Dear Vivek, On 11/01/13 18:24, Vivek Gautam wrote: Enabling the non-dt path for the driver so that we don't get any build errors for non-dt configuration. Signed-off-by: Vivek Gautam gautam.vi...@samsung.com --- Earlier we had moved to fdt support for ehci-exynos driver, but missed out the non-dt path. Although this driver serves for exysno5 onward only but better to keep the non-dt path also available. drivers/usb/host/ehci-exynos.c | 10 ++ 1 files changed, 10 insertions(+), 0 deletions(-) diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c index 3ca4c5c..6f0c6c3 100644 --- a/drivers/usb/host/ehci-exynos.c +++ b/drivers/usb/host/ehci-exynos.c @@ -153,7 +153,12 @@ int ehci_hcd_init(int index, struct ehci_hccr **hccr, struct ehci_hcor **hcor) return -ENOMEM; } +#ifdef CONFIG_OF_CONTROL exynos_usb_parse_dt(gd-fdt_blob, exynos); +#else + exynos-usb = (struct exynos_usb_phy *)samsung_get_base_usb_phy(); + exynos-hcd = samsung_get_base_usb_ehci(); +#endif setup_usb_phy(exynos-usb); @@ -185,7 +190,12 @@ int ehci_hcd_stop(int index) return -ENOMEM; } +#ifdef CONFIG_OF_CONTROL exynos_usb_parse_dt(gd-fdt_blob, exynos); +#else + exynos-usb = (struct exynos_usb_phy *)samsung_get_base_usb_phy(); + exynos-hcd = samsung_get_base_usb_ehci(); +#endif reset_usb_phy(exynos-usb); Patch looks good. But I've got compiler warnings and errors when I disabled CONFIG_OF_CONTROL. exynos_spi.c:391:12: warning: 'process_nodes' defined but not used [-Wunused-function] ehci-exynos.c: In function 'ehci_hcd_init': ehci-exynos.c:160:14: warning: assignment makes pointer from integer without a cast [enabled by default] ehci-exynos.c: In function 'ehci_hcd_stop': ehci-exynos.c:197:14: warning: assignment makes pointer from integer without a cast [enabled by default] ehci-exynos.c: At top level: ehci-exynos.c:48:12: warning: 'exynos_usb_parse_dt' defined but not used [-Wunused-function] /opt/eldk-5.2/armv7a/sysroots/i686-eldk-linux/usr/bin/armv7a-vfp-neon-linux-gnueabi/arm-linux-gnueabi-ld.bfd:/home/share/Work/u-boot-samsung/spl/u-boot-spl.lds:1: ignoring invalid character `#' in expression /opt/eldk-5.2/armv7a/sysroots/i686-eldk-linux/usr/bin/armv7a-vfp-neon-linux-gnueabi/arm-linux-gnueabi-ld.bfd:/home/share/Work/u-boot-samsung/spl/u-boot-spl.lds:1: syntax error make[1]: *** [/home/share/Work/u-boot-samsung/spl/u-boot-spl] Error 1 make: *** [spl/u-boot-spl.bin] Error 2 make: *** Waiting for unfinished jobs smdk5250.c: In function 'board_eth_init': smdk5250.c:152:6: warning: unused variable 'node' [-Wunused-variable] Could you please check this issue also? Thanks. Minkyu Kang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 2/3] OMAP3: drop CONFIG_SPL_OS_BOOT_KEY and use local define
CONFIG_SPL_OS_BOOT_KEY is used only in board files. It is
not required to have a general CONFIG_ option. Rename it and
define it in board directory.
Signed-off-by: Stefano Babic sba...@denx.de
---
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None
board/technexion/twister/twister.c |8
board/technexion/twister/twister.h |2 ++
board/timll/devkit8000/devkit8000.c |8
board/timll/devkit8000/devkit8000.h |3 +++
include/configs/devkit8000.h|1 -
include/configs/twister.h |1 -
6 files changed, 13 insertions(+), 10 deletions(-)
diff --git a/board/technexion/twister/twister.c
b/board/technexion/twister/twister.c
index c9eea9b..fa0ace0 100644
--- a/board/technexion/twister/twister.c
+++ b/board/technexion/twister/twister.c
@@ -165,10 +165,10 @@ void spl_board_prepare_for_linux(void)
int spl_start_uboot(void)
{
int val = 0;
- if (!gpio_request(CONFIG_SPL_OS_BOOT_KEY, U-Boot key)) {
- gpio_direction_input(CONFIG_SPL_OS_BOOT_KEY);
- val = gpio_get_value(CONFIG_SPL_OS_BOOT_KEY);
- gpio_free(CONFIG_SPL_OS_BOOT_KEY);
+ if (!gpio_request(SPL_OS_BOOT_KEY, U-Boot key)) {
+ gpio_direction_input(SPL_OS_BOOT_KEY);
+ val = gpio_get_value(SPL_OS_BOOT_KEY);
+ gpio_free(SPL_OS_BOOT_KEY);
}
return val;
}
diff --git a/board/technexion/twister/twister.h
b/board/technexion/twister/twister.h
index a2051c0..cff479c 100644
--- a/board/technexion/twister/twister.h
+++ b/board/technexion/twister/twister.h
@@ -38,6 +38,8 @@ const omap3_sysinfo sysinfo = {
#define XR16L2751_UART1_BASE 0x2100
#define XR16L2751_UART2_BASE 0x2300
+/* GPIO used to select between U-Boot and kernel */
+#define SPL_OS_BOOT_KEY55
/*
* IEN - Input Enable
diff --git a/board/timll/devkit8000/devkit8000.c
b/board/timll/devkit8000/devkit8000.c
index 85685ee..b88d978 100644
--- a/board/timll/devkit8000/devkit8000.c
+++ b/board/timll/devkit8000/devkit8000.c
@@ -172,10 +172,10 @@ void spl_board_prepare_for_linux(void)
int spl_start_uboot(void)
{
int val = 0;
- if (!gpio_request(CONFIG_SPL_OS_BOOT_KEY, U-Boot key)) {
- gpio_direction_input(CONFIG_SPL_OS_BOOT_KEY);
- val = gpio_get_value(CONFIG_SPL_OS_BOOT_KEY);
- gpio_free(CONFIG_SPL_OS_BOOT_KEY);
+ if (!gpio_request(SPL_OS_BOOT_KEY, U-Boot key)) {
+ gpio_direction_input(SPL_OS_BOOT_KEY);
+ val = gpio_get_value(SPL_OS_BOOT_KEY);
+ gpio_free(SPL_OS_BOOT_KEY);
}
return !val;
}
diff --git a/board/timll/devkit8000/devkit8000.h
b/board/timll/devkit8000/devkit8000.h
index aa69e6c..c1965e2 100644
--- a/board/timll/devkit8000/devkit8000.h
+++ b/board/timll/devkit8000/devkit8000.h
@@ -32,6 +32,9 @@ const omap3_sysinfo sysinfo = {
NAND,
};
+/* GPIO used to select between U-Boot and kernel */
+#define SPL_OS_BOOT_KEY26
+
/*
* IEN - Input Enable
* IDIS - Input Disable
diff --git a/include/configs/devkit8000.h b/include/configs/devkit8000.h
index d926f74..788227d 100644
--- a/include/configs/devkit8000.h
+++ b/include/configs/devkit8000.h
@@ -354,7 +354,6 @@
/* SPL OS boot options */
#define CONFIG_SPL_OS_BOOT
-#define CONFIG_SPL_OS_BOOT_KEY 26
#define CONFIG_CMD_SPL
#define CONFIG_CMD_SPL_WRITE_SIZE 0x400 /* 1024 byte */
diff --git a/include/configs/twister.h b/include/configs/twister.h
index a852481..4205a11 100644
--- a/include/configs/twister.h
+++ b/include/configs/twister.h
@@ -58,7 +58,6 @@
#define CONFIG_CMD_SPL_NAND_OFS(CONFIG_SYS_NAND_SPL_KERNEL_OFFS+\
0x60)
#define CONFIG_SPL_OS_BOOT
-#define CONFIG_SPL_OS_BOOT_KEY 55
#define CONFIG_SYS_SPL_ARGS_ADDR (PHYS_SDRAM_1 + 0x100)
#define CONFIG_SPL_BOARD_INIT
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 3/3] SPL: Change description for spl command
Add a more descriptive text to the help of the spl command. Signed-off-by: Stefano Babic sba...@denx.de --- Changes in v5: None Changes in v4: None Changes in v3: None Changes in v2: None common/cmd_spl.c | 12 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/common/cmd_spl.c b/common/cmd_spl.c index e3c543b..94b0a17 100644 --- a/common/cmd_spl.c +++ b/common/cmd_spl.c @@ -184,7 +184,11 @@ static int do_spl(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) U_BOOT_CMD( spl, 6 , 1, do_spl, SPL configuration, - export img=atags|fdt [kernel_addr] [initrd_addr] - [fdt_addr if img = fdt] - export a kernel parameter image\n - \t initrd_img can be set to \-\ if fdt_addr without initrd img is - used); + export img=atags|fdt [kernel_addr] [initrd_addr] [fdt_addr]\n + \timg\t\t\atags\ or \fdt\\n + \tkernel_addr\taddress where a kernel image is stored.\n + \t\t\tkernel is loaded as part of the boot process, but it is not started.\n + \tinitrd_addr\taddress of initial ramdisk\n + \t\t\tcan be set to \-\ if fdt_addr without initrd_addr is used.\n + \tfdt_addr\tin case of fdt, the address of the device tree.\n + ); -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 1/3] Add README for the Falcon mode
Simple howto to add support to a board for booting the kernel from SPL (Falcon mode). Signed-off-by: Stefano Babic sba...@denx.de --- Changes in v5: - several fixes for the language, rephrasing some unclear parts (Vikram Narayanan) Changes in v4: - fix capitalization, styling, in spl help (Andreas Biessmann) - move CONFIG_SPL_OS_BOOT before function in doc (Andreas Biessmann) Changes in v3: - parameter initrd_addr was removed in V2 (Andreas Biessmann) - added patch to fix help usage for spl export (Andreas Biessmann) - Added empty lines (Otavio Salvador) - add a more exhaustive description explaining that spl export does not save into media (Lukasz Majewski). Changes in v2: - spelling, language fixes (Andreas Biessman) - rewrite some unclear sentences - drop CONFIG_SPL_OS_BOOT_KEY - make example with twister more exhaustive doc/README.falcon | 169 + 1 file changed, 169 insertions(+) create mode 100644 doc/README.falcon diff --git a/doc/README.falcon b/doc/README.falcon new file mode 100644 index 000..72fe04a --- /dev/null +++ b/doc/README.falcon @@ -0,0 +1,169 @@ +U-Boot Falcon Mode + + +Introduction + + +This document provides an overview of how to add support for Falcon Mode +to a board. +Falcon Mode is introduced to speed up the booting process, allowing +to boot a Linux kernel (or whatever image) without a full blown U-Boot. + +Falcon Mode relies on the SPL framework. In fact, to make booting faster, +U-Boot is split into two parts: the SPL (Secondary Program Loader) and U-Boot +image. In most implementations, SPL is used to start U-Boot when booting from +a mass storage, such as NAND or SD-Card. SPL has now support for other media, +and can generally be seen as a way to start an image performing the minimum +required initialization. SPL mainly initializes the RAM controller, and then +copies U-Boot image into the memory. The Falcon Mode extends this way +allowing to start the Linux kernel directly from SPL. A new command is added +to U-Boot to prepare the parameters that SPL must pass to the kernel, using +ATAGS or Device Tree. + +In usual U-Boot systems, these parameters are generated each time before +loading the kernel, passing to Linux the address in memory where +the parameters can be read. +With Falcon Mode, this snapshot can be saved into persistent storage and SPL is +informed to load it before running the kernel. + +To boot the kernel, these steps under a Falcon-aware U-Boot are required: + +1. Boot the board into U-Boot. +Use the spl export command to generate the kernel parameters area or the DT. +U-Boot runs as when it boots the kernel, but stops before passing the control +to the kernel. + +2. Save the prepared snapshot into persistent media. +The address where to save it must be configured into board configuration +file (CONFIG_CMD_SPL_NAND_OFS for NAND). + +3. Boot the board into Falcon Mode. SPL will load the kernel and copy +the parameters which are saved in the persistent area area to the required address. + +It is required to implement a custom mechanism to select if SPL loads U-Boot +or another image. + +The value of a GPIO is a simple way to operate the selection, as well as +reading a character from the SPL console if CONFIG_SPL_CONSOLE is set. + +Falcon Mode is generally activated by setting CONFIG_SPL_OS_BOOT. This tells +SPL that U-Boot is not the only available image that SPL is able to start. + +Configuration + +CONFIG_CMD_SPL Enable the spl export command. + The command spl export is then available in U-Boot + mode +CONFIG_SYS_SPL_ARGS_ADDR Address in RAM where the parameters must be + copied by SPL. + In most cases, it is start_of_ram + 0x100 + +CONFIG_SYS_NAND_SPL_KERNEL_OFFSOffset in NAND where the kernel is stored + +CONFIG_CMD_SPL_NAND_OFSOffset in NAND where the parameters area was saved. + +CONFIG_CMD_SPL_WRITE_SIZE Size of the parameters area to be copied + +CONFIG_SPL_OS_BOOT Activate Falcon Mode. + +Function that a board must implement + + +void spl_board_prepare_for_linux(void) : optional + Called from SPL before starting the kernel + +spl_start_uboot() : required + Returns 0 if SPL starts the kernel, 1 if U-Boot + must be started. + + +Using spl command +- + +spl - SPL configuration + +Usage: + +spl export img=atags|fdt [kernel_addr] [initrd_addr] [fdt_addr ] + +img: atags or fdt +kernel_addr: kernel is loaded as part of the boot process, but it is not started. + This is the address where a kernel image is stored. +initrd_addr: Address of initial ramdisk + can be set to - if fdt_addr without initrd img is used +fdt_addr : in case of fdt, the address
[U-Boot] [PATCH 1/2] tools: rename kwboot to mvboot
kwboot tool is used to boot Marvell Kirkwood SoCs over the serial link. Before adding support for other Marvell SoCs, such as Dove or Armada, this patch renames the tool so it's name makes more sense in the future. Signed-off-by: Luka Perkov l...@openwrt.org CC: Prafulla Wadaskar prafu...@marvell.com CC: Sebastian Hesselbarth sebastian.hesselba...@gmail.com CC: Daniel Stodden daniel.stod...@gmail.com --- doc/kwboot.1 | 84 --- doc/mvboot.1 | 84 +++ tools/.gitignore | 2 +- tools/Makefile | 6 +- tools/kwboot.c | 742 --- tools/mvboot.c | 742 +++ 6 files changed, 830 insertions(+), 830 deletions(-) delete mode 100644 doc/kwboot.1 create mode 100644 doc/mvboot.1 delete mode 100644 tools/kwboot.c create mode 100644 tools/mvboot.c diff --git a/doc/kwboot.1 b/doc/kwboot.1 deleted file mode 100644 index 25fe69a..000 --- a/doc/kwboot.1 +++ /dev/null @@ -1,84 +0,0 @@ -.TH KWBOOT 1 2012-05-19 - -.SH NAME -kwboot \- Boot Marvell Kirkwood SoCs over a serial link. -.SH SYNOPSIS -.B kwboot -.RB [ -b \fIimage\fP ] -.RB [ -p ] -.RB [ -t ] -.RB [ -B \fIbaudrate\fP ] -.RB \fITTY\fP -.SH DESCRIPTION - -The \fBmkimage\fP program boots boards based on Marvell's Kirkwood -platform over their integrated UART. Boot image files will typically -contain a second stage boot loader, such as U-Boot. The image file -must conform to Marvell's BootROM firmware image format -(\fIkwbimage\fP), created using a tool such as \fBmkimage\fP. - -Following power-up or a system reset, system BootROM code polls the -UART for a brief period of time, sensing a handshake message which -initiates an image upload. This program sends this boot message until -it receives a positive acknowledgement. The image is transfered using -Xmodem. - -Additionally, this program implements a minimal terminal mode, which -can be used either standalone, or entered immediately following boot -image transfer completion. This is often useful to catch early boot -messages, or to manually interrupt a default boot procedure performed -by the second-stage loader. - -.SH OPTIONS - -.TP -.BI \-b \fIimage\fP -Handshake; then upload file \fIimage\fP over \fITTY\fP. - -Note that for the encapsulated boot code to be executed, \fIimage\fP -must be of type UART boot (0x69). Boot images of different types, -such as backup images of vendor firmware downloaded from flash memory -(type 0x8B), will not work (or not as expected). See \fB-p\fP for a -workaround. - -This mode writes handshake status and upload progress indication to -stdout. - -.TP -.BI \-p -In combination with \fB-b\fP, patches the header in \fIimage\fP prior -to upload, to UART boot type. - -This option attempts on-the-fly conversion of some none-UART image -types, such as images which were originally formatted to be stored in -flash memory. - -Conversion is performed in memory. The contents of \fIimage\fP will -not be altered. - -.TP -.BI \-t -Run a terminal program, connecting standard input and output to -.RB \fITTY\fP. - -If used in combination with \fB-b\fP, terminal mode is entered -immediately following a successful image upload. - -If standard I/O streams connect to a console, this mode will terminate -after receiving 'ctrl-\\' followed by 'c' from console input. - -.TP -.BI \-B \fIbaudrate\fP -Adjust the baud rate on \fITTY\fP. Default rate is 115200. - -.SH SEE ALSO -.PP -\fBmkimage\fP(1) - -.SH AUTHORS - -Daniel Stodden daniel.stod...@gmail.com -.br -Luka Perkov l...@openwrt.org -.br -David Purdy david.c.pu...@gmail.com diff --git a/doc/mvboot.1 b/doc/mvboot.1 new file mode 100644 index 000..563d0e5 --- /dev/null +++ b/doc/mvboot.1 @@ -0,0 +1,84 @@ +.TH MVBOOT 1 2012-05-19 + +.SH NAME +mvboot \- Boot Marvell Kirkwood SoCs over a serial link. +.SH SYNOPSIS +.B mvboot +.RB [ -b \fIimage\fP ] +.RB [ -p ] +.RB [ -t ] +.RB [ -B \fIbaudrate\fP ] +.RB \fITTY\fP +.SH DESCRIPTION + +The \fBmkimage\fP program boots boards based on Marvell's Kirkwood +platform over their integrated UART. Boot image files will typically +contain a second stage boot loader, such as U-Boot. The image file +must conform to Marvell's BootROM firmware image format +(\fIkwbimage\fP), created using a tool such as \fBmkimage\fP. + +Following power-up or a system reset, system BootROM code polls the +UART for a brief period of time, sensing a handshake message which +initiates an image upload. This program sends this boot message until +it receives a positive acknowledgement. The image is transfered using +Xmodem. + +Additionally, this program implements a minimal terminal mode, which +can be used either standalone, or entered immediately following boot +image transfer completion. This is often useful to catch early boot +messages, or to manually interrupt a default boot procedure performed +by the second-stage loader. + +.SH OPTIONS + +.TP +.BI \-b \fIimage\fP +Handshake; then upload file \fIimage\fP
Re: [U-Boot] [PATCH 6/7 V3] EXYNOS5: Add initial DTS file for Snow.
Dear Rajeshwari, On 01/02/13 14:39, Rajeshwari Shinde wrote: This patch adds the DTS file for Snow Board. Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com --- Changes in V2: -None Changes in V3: - None board/samsung/dts/exynos5250-snow.dts | 69 + 1 files changed, 69 insertions(+), 0 deletions(-) create mode 100644 board/samsung/dts/exynos5250-snow.dts I think, patch 6 and 7 should be separated with another patch. Thanks, Minkyu Kang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 7/7 V3] EXYNOS5: Snow: Add a configuration file
Dear Rajeshwari, On 01/02/13 14:39, Rajeshwari Shinde wrote: This patch adds the configuration file for Snow Board and defines the same in boards.cfg. Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com --- Changes in V2: - None. Changes in V3: - Moved CONFIG_SOUND_MAX98095 to exynos5250-dt.h boards.cfg |1 + include/configs/exynos5250-dt.h |1 + include/configs/snow.h | 33 + 3 files changed, 35 insertions(+), 0 deletions(-) create mode 100644 include/configs/snow.h diff --git a/boards.cfg b/boards.cfg index e4b0d44..f247b03 100644 --- a/boards.cfg +++ b/boards.cfg @@ -283,6 +283,7 @@ s5p_goni arm armv7 goni samsung smdkc100 arm armv7 smdkc100 samsungs5pc1xx origenarm armv7 origen samsungexynos s5pc210_universalarm armv7 universal_c210 samsungexynos +snow arm armv7 smdk5250 samsungexynos smdk5250 arm armv7 smdk5250 samsungexynos smdkv310 arm armv7 smdkv310 samsungexynos tratsarm armv7 trats samsungexynos diff --git a/include/configs/exynos5250-dt.h b/include/configs/exynos5250-dt.h index a01fb96..b1b24a9 100644 --- a/include/configs/exynos5250-dt.h +++ b/include/configs/exynos5250-dt.h @@ -298,6 +298,7 @@ #define CONFIG_SOUND #define CONFIG_I2S #define CONFIG_SOUND_WM8994 +#define CONFIG_SOUND_MAX98095 unrelated change. #endif /* Enable devicetree support */ diff --git a/include/configs/snow.h b/include/configs/snow.h new file mode 100644 index 000..1dc491b --- /dev/null +++ b/include/configs/snow.h @@ -0,0 +1,33 @@ +/* + * Copyright (C) 2013 Samsung Electronics + * + * Configuration settings for the SAMSUNG SMDK5250 board. + * + * See file CREDITS for list of people who contributed to this + * project. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of + * the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, + * MA 02111-1307 USA + */ + +#ifndef __CONFIG_SMDK_H +#define __CONFIG_SMDK_H + +#include configs/exynos5250-dt.h + +#undef CONFIG_DEFAULT_DEVICE_TREE +#define CONFIG_DEFAULT_DEVICE_TREE exynos5250-snow + +#endif /* __CONFIG_SMDK_H */ Thanks. Minkyu Kang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2 v4] tools: add support for Dove to kwboot
From: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
On Dove mvboot can also be used to boot an u-boot image into RAM.
In contrast to Kirkwood, Dove does not support the UART boot mode
sequence but requires the UART boot mode to be selected through
strap pins. The SolidRun CuBox has a push button to allow uart
boot mode but fails on the boot sequence sent by mvboot.
This patch adds another cmdline option to allow to send a boot
image without the boot sequence and adds support for Dove.
Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
Signed-off-by: Daniel Stodden daniel.stod...@gmail.com
Signed-off-by: Luka Perkov l...@openwrt.org
Cc: Prafulla Wadaskar prafu...@marvell.com
Cc: Rabeeh Khoury rab...@solid-run.com
---
changes from v1 to v2:
* update documentation
changes from v2 to v3:
* none
changes from v3 to v4:
* move to separate patch series
* fix wrong flag in the man page
* document Dove support in the header of mvboot.c
doc/mvboot.1 | 13 ++---
tools/Makefile | 2 ++
tools/mvboot.c | 27 ---
3 files changed, 32 insertions(+), 10 deletions(-)
diff --git a/doc/mvboot.1 b/doc/mvboot.1
index 563d0e5..0978351 100644
--- a/doc/mvboot.1
+++ b/doc/mvboot.1
@@ -1,17 +1,18 @@
-.TH MVBOOT 1 2012-05-19
+.TH MVBOOT 1 2013-02-12
.SH NAME
-mvboot \- Boot Marvell Kirkwood SoCs over a serial link.
+mvboot \- Boot Marvell Kirkwood/Dove SoCs over a serial link.
.SH SYNOPSIS
.B mvboot
.RB [ -b \fIimage\fP ]
+.RB [ -n ]
.RB [ -p ]
.RB [ -t ]
.RB [ -B \fIbaudrate\fP ]
.RB \fITTY\fP
.SH DESCRIPTION
-The \fBmkimage\fP program boots boards based on Marvell's Kirkwood
+The \fBmkimage\fP program boots boards based on Marvell's Kirkwood/Dove
platform over their integrated UART. Boot image files will typically
contain a second stage boot loader, such as U-Boot. The image file
must conform to Marvell's BootROM firmware image format
@@ -68,6 +69,12 @@ If standard I/O streams connect to a console, this mode will
terminate
after receiving 'ctrl-\\' followed by 'c' from console input.
.TP
+.BI \-n
+Disables the UART boot mode sequence for platforms that do not support
+it (e.g. Dove). Usually, the UART boot mode must be selected by pressing
+a push button on power-up.
+
+.TP
.BI \-B \fIbaudrate\fP
Adjust the baud rate on \fITTY\fP. Default rate is 115200.
diff --git a/tools/Makefile b/tools/Makefile
index adfb643..db4def5 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -72,6 +72,7 @@ BIN_FILES-$(CONFIG_SMDK5250) += mksmdk5250spl$(SFX)
BIN_FILES-$(CONFIG_MX28) += mxsboot$(SFX)
BIN_FILES-$(CONFIG_NETCONSOLE) += ncb$(SFX)
BIN_FILES-$(CONFIG_SHA1_CHECK_UB_IMG) += ubsha1$(SFX)
+BIN_FILES-$(CONFIG_DOVE) += mvboot$(SFX)
BIN_FILES-$(CONFIG_KIRKWOOD) += mvboot$(SFX)
# Source files which exist outside the tools directory
@@ -103,6 +104,7 @@ OBJ_FILES-$(CONFIG_NETCONSOLE) += ncb.o
NOPED_OBJ_FILES-y += os_support.o
OBJ_FILES-$(CONFIG_SHA1_CHECK_UB_IMG) += ubsha1.o
NOPED_OBJ_FILES-y += ublimage.o
+OBJ_FILES-$(CONFIG_DOVE) += mvboot.o
OBJ_FILES-$(CONFIG_KIRKWOOD) += mvboot.o
# Don't build by default
diff --git a/tools/mvboot.c b/tools/mvboot.c
index 94fb0dd..ea12f58 100644
--- a/tools/mvboot.c
+++ b/tools/mvboot.c
@@ -1,5 +1,5 @@
/*
- * Boot a Marvell Kirkwood SoC, with Xmodem over UART0.
+ * Boot a Marvell Kirkwood and Dove SoCs, with Xmodem over UART0.
*
* (c) 2012 Daniel Stodden daniel.stod...@gmail.com
*
@@ -37,6 +37,10 @@ static unsigned char mvboot_msg_boot[] = {
0xBB, 0x11, 0x22, 0x33, 0x44, 0x55, 0x66, 0x77
};
+static unsigned char mvboot_msg_none[] = {
+ 0x00
+};
+
#define MVBOOT_MSG_REQ_DELAY 10 /* ms */
#define MVBOOT_MSG_RSP_TIMEO 50 /* ms */
@@ -268,17 +272,21 @@ mvboot_bootmsg(int tty, void *msg)
int rc;
char c;
- mvboot_printv(Sending boot message. Please reboot the target...);
+ mvboot_printv(msg != mvboot_msg_none
+ ? Sending boot message. Please reboot the target...
+ : Sensing target. Please reboot target into UART mode...);
do {
rc = tcflush(tty, TCIOFLUSH);
if (rc)
break;
- rc = mvboot_tty_send(tty, msg, 8);
- if (rc) {
- usleep(MVBOOT_MSG_REQ_DELAY * 1000);
- continue;
+ if (msg != mvboot_msg_none) {
+ rc = mvboot_tty_send(tty, msg, 8);
+ if (rc) {
+ usleep(MVBOOT_MSG_REQ_DELAY * 1000);
+ continue;
+ }
}
rc = mvboot_tty_recv(tty, c, 1, MVBOOT_MSG_RSP_TIMEO);
@@ -607,6 +615,7 @@ mvboot_usage(FILE *stream, char *progname)
fprintf(stream, -b image: boot image\n);
fprintf(stream, -p: patch image to type 0x69 (uart boot)\n);
fprintf(stream, \n);
+ fprintf(stream, -n: don't send boot
[U-Boot] [PATCH v2 0/4] usb:gadget: USB Mass Storage Gadget
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
From: Lukasz Majewski l.majew...@samsung.com
The storage_common.c source file from v2.6.36 Linux kernel.
commit d26a6aa08b9f12b44fb1ee65625e7480d3d5bb81
Author: Michal Nazarewicz m.nazarew...@samsung.com
Date: Mon Nov 9 14:15:23 2009 +0100
USB: g_mass_storage: code cleaned up and comments updated
Signed-off-by: Lukasz Majewski l.majew...@samsung.com
Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
CC: Marek Vasut marek.va...@gmail.com
---
Changes in v2: None
drivers/usb/gadget/storage_common.c | 653 +++
1 file changed, 653 insertions(+)
create mode 100644 drivers/usb/gadget/storage_common.c
diff --git a/drivers/usb/gadget/storage_common.c
b/drivers/usb/gadget/storage_common.c
new file mode 100644
index 000..594dc10
--- /dev/null
+++ b/drivers/usb/gadget/storage_common.c
@@ -0,0 +1,653 @@
+/*
+ * storage_common.c -- Common definitions for mass storage functionality
+ *
+ * Copyright (C) 2003-2008 Alan Stern
+ * Copyeight (C) 2009 Samsung Electronics
+ * Author: Michal Nazarewicz (m.nazarew...@samsung.com)
+ *
+ * Ported to u-boot:
+ * Andrzej Pietrasiewicz andrze...@samsung.com
+ *
+ * Code refactoring cleanup:
+ * Łukasz Majewski l.majew...@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+
+/*
+ * This file requires the following identifiers used in USB strings to
+ * be defined (each of type pointer to char):
+ * - fsg_string_manufacturer -- name of the manufacturer
+ * - fsg_string_product -- name of the product
+ * - fsg_string_serial -- product's serial
+ * - fsg_string_config -- name of the configuration
+ * - fsg_string_interface-- name of the interface
+ * The first four are only needed when FSG_DESCRIPTORS_DEVICE_STRINGS
+ * macro is defined prior to including this file.
+ */
+
+/*
+ * When FSG_NO_INTR_EP is defined fsg_fs_intr_in_desc and
+ * fsg_hs_intr_in_desc objects as well as
+ * FSG_FS_FUNCTION_PRE_EP_ENTRIES and FSG_HS_FUNCTION_PRE_EP_ENTRIES
+ * macros are not defined.
+ *
+ * When FSG_NO_DEVICE_STRINGS is defined FSG_STRING_MANUFACTURER,
+ * FSG_STRING_PRODUCT, FSG_STRING_SERIAL and FSG_STRING_CONFIG are not
+ * defined (as well as corresponding entries in string tables are
+ * missing) and FSG_STRING_INTERFACE has value of zero.
+ *
+ * When FSG_NO_OTG is defined fsg_otg_desc won't be defined.
+ */
+
+/*
+ * When FSG_BUFFHD_STATIC_BUFFER is defined when this file is included
+ * the fsg_buffhd structure's buf field will be an array of FSG_BUFLEN
+ * characters rather then a pointer to void.
+ */
+
+
+/* #include asm/unaligned.h */
+
+
+/*
+ * Thanks to NetChip Technologies for donating this product ID.
+ *
+ * DO NOT REUSE THESE IDs with any other driver!! Ever!!
+ * Instead: allocate your own, using normal USB-IF procedures.
+ */
+#define FSG_VENDOR_ID 0x0525 /* NetChip */
+#define FSG_PRODUCT_ID 0xa4a5 /* Linux-USB File-backed Storage Gadget */
+
+/*-*/
+
+#ifndef DEBUG
+#undef VERBOSE_DEBUG
+#undef DUMP_MSGS
+#endif /* !DEBUG */
+
+#ifdef VERBOSE_DEBUG
+#define VLDBG LDBG
+#else
+#define VLDBG(lun, fmt, args...) do { } while (0)
+#endif /* VERBOSE_DEBUG */
+
+/*
+#define LDBG(lun, fmt, args...) dev_dbg ((lun)-dev, fmt, ## args)
+#define LERROR(lun, fmt, args...) dev_err ((lun)-dev, fmt, ## args)
+#define LWARN(lun, fmt, args...) dev_warn((lun)-dev, fmt, ## args)
+#define LINFO(lun, fmt, args...) dev_info((lun)-dev, fmt, ## args)
+*/
+
+#define LDBG(lun, fmt, args...) do { } while (0)
+#define LERROR(lun, fmt, args...) do { } while (0)
+#define LWARN(lun, fmt, args...) do { } while (0)
+#define LINFO(lun, fmt, args...) do { } while (0)
+
+/*
+ * Keep those macros in sync with those in
+ * include/linux/usb/composite.h or else GCC will complain. If they
+ * are identical (the same names of arguments, white spaces in the
+ * same places) GCC will allow redefinition otherwise (even if some
+ * white space is removed or added) warning will be issued.
+ *
+ * Those macros are needed here because File Storage Gadget does not
+ * include the composite.h header. For composite gadgets those macros
+ * are redundant since composite.h is included any way.
+ *
+ * One could check whether
[U-Boot] [PATCH v2 3/4] usb:gadget: USB Mass Storage Gadget support
From: Lukasz Majewski l.majew...@samsung.com
This patch adds the USB Mass Storage Gadget to u-boot
New command called ums is implemented to provide access
to on-device embedded persistent memory.
USB Mass Storage is supposed to work on top of the USB
Gadget framework
Signed-off-by: Lukasz Majewski l.majew...@samsung.com
Signed-off-by: Piotr Wilczek p.wilc...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
CC: Marek Vasut marek.va...@gmail.com
---
Changes in v2: None
common/Makefile |1 +
common/cmd_usb_mass_storage.c | 86 +
drivers/usb/gadget/g_dnl.c|6 +++
include/usb_mass_storage.h| 55 ++
4 files changed, 148 insertions(+)
create mode 100644 common/cmd_usb_mass_storage.c
create mode 100644 include/usb_mass_storage.h
diff --git a/common/Makefile b/common/Makefile
index 54fcc81..8ec95d2 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -174,6 +174,7 @@ COBJS-y += cmd_usb.o
COBJS-y += usb.o usb_hub.o
COBJS-$(CONFIG_USB_STORAGE) += usb_storage.o
endif
+COBJS-$(CONFIG_CMD_USB_MASS_STORAGE) += cmd_usb_mass_storage.o
COBJS-$(CONFIG_CMD_XIMG) += cmd_ximg.o
COBJS-$(CONFIG_YAFFS2) += cmd_yaffs2.o
COBJS-$(CONFIG_CMD_SPL) += cmd_spl.o
diff --git a/common/cmd_usb_mass_storage.c b/common/cmd_usb_mass_storage.c
new file mode 100644
index 000..87a5f2f
--- /dev/null
+++ b/common/cmd_usb_mass_storage.c
@@ -0,0 +1,86 @@
+/*
+ * Copyright (C) 2011 Samsung Electronics
+ * Lukasz Majewski l.majew...@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include errno.h
+#include common.h
+#include command.h
+#include g_dnl.h
+#include usb_mass_storage.h
+
+int do_usb_mass_storage(cmd_tbl_t *cmdtp, int flag,
+ int argc, char * const argv[])
+{
+ char *ep;
+ unsigned int dev_num = 0, offset = 0, part_size = 0;
+ int rc;
+
+ struct ums_board_info *ums_info;
+ static char *s = ums;
+
+ if (argc 2) {
+ printf(usage: ums dev - e.g. ums 0\n);
+ return 0;
+ }
+
+ dev_num = (int)simple_strtoul(argv[1], ep, 16);
+
+ if (dev_num) {
+ puts(\nSet eMMC device to 0! - e.g. ums 0\n);
+ goto fail;
+ }
+
+ board_usb_init();
+ ums_info = board_ums_init(dev_num, offset, part_size);
+
+ if (!ums_info) {
+ printf(MMC: %d - NOT available\n, dev_num);
+ goto fail;
+ }
+ rc = fsg_init(ums_info);
+ if (rc) {
+ printf(cmd ums: fsg_init failed\n);
+ goto fail;
+ }
+
+ g_dnl_register(s);
+
+ while (1) {
+ /* Handle control-c and timeouts */
+ if (ctrlc()) {
+ printf(The remote end did not respond in time.\n);
+ goto exit;
+ }
+ usb_gadget_handle_interrupts();
+ /* Check if USB cable has been detached */
+ if (fsg_main_thread(NULL) == EIO)
+ goto exit;
+ }
+exit:
+ g_dnl_unregister();
+ return 0;
+
+fail:
+ return -1;
+}
+
+U_BOOT_CMD(ums, CONFIG_SYS_MAXARGS, 1, do_usb_mass_storage,
+ Use the UMS [User Mass Storage],
+ ums - User Mass Storage Gadget
+);
diff --git a/drivers/usb/gadget/g_dnl.c b/drivers/usb/gadget/g_dnl.c
index a5a4c1f..cc3f344 100644
--- a/drivers/usb/gadget/g_dnl.c
+++ b/drivers/usb/gadget/g_dnl.c
@@ -31,6 +31,7 @@
#include gadget_chips.h
#include composite.c
+#include f_mass_storage.c
/*
* One needs to define the following:
@@ -104,6 +105,8 @@ static int g_dnl_do_config(struct usb_configuration *c)
printf(GADGET DRIVER: %s\n, s);
if (!strcmp(s, usb_dnl_dfu))
ret = dfu_add(c);
+ else if (!strcmp(s, usb_dnl_ums))
+ ret = fsg_add(c);
return ret;
}
@@ -188,6 +191,9 @@ int g_dnl_register(const char *type)
if (!strcmp(type, dfu)) {
strcpy(name, shortname);
strcat(name, type);
+ } else if (!strcmp(type, ums)) {
+ strcpy(name, shortname);
+ strcat(name, type);
} else {
printf(%s: unknown command: %s\n, __func__, type);
[U-Boot] [PATCH v2 4/4] arm:trats: Use new ums command
From: Lukasz Majewski l.majew...@samsung.com
This patch enables new ums command on Trats board
Signed-off-by: Lukasz Majewski l.majew...@samsung.com
Signed-off-by: Piotr Wilczek p.wilc...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
CC: Minkyu Kang mk7.k...@samsung.com
---
Changes in v2: None
board/samsung/trats/trats.c | 63 +++
include/configs/trats.h |5
2 files changed, 68 insertions(+)
diff --git a/board/samsung/trats/trats.c b/board/samsung/trats/trats.c
index 88d193d..9207646 100644
--- a/board/samsung/trats/trats.c
+++ b/board/samsung/trats/trats.c
@@ -42,6 +42,7 @@
#include power/max8997_muic.h
#include power/battery.h
#include power/max17042_fg.h
+#include usb_mass_storage.h
#include setup.h
@@ -791,3 +792,65 @@ void init_panel_info(vidinfo_t *vid)
setenv(lcdinfo, lcd=s6e8ax0);
}
+
+#ifdef CONFIG_USB_GADGET_MASS_STORAGE
+static int ums_read_sector(struct ums_device *ums_dev,
+ ulong start, lbaint_t blkcnt, void *buf)
+{
+ if (ums_dev-mmc-block_dev.block_read(ums_dev-dev_num,
+ start + ums_dev-offset, blkcnt, buf) != blkcnt)
+ return -1;
+
+ return 0;
+}
+
+static int ums_write_sector(struct ums_device *ums_dev,
+ ulong start, lbaint_t blkcnt, const void *buf)
+{
+ if (ums_dev-mmc-block_dev.block_write(ums_dev-dev_num,
+ start + ums_dev-offset, blkcnt, buf) != blkcnt)
+ return -1;
+
+ return 0;
+}
+
+static void ums_get_capacity(struct ums_device *ums_dev,
+long long int *capacity)
+{
+ long long int tmp_capacity;
+
+ tmp_capacity = (long long int) ((ums_dev-offset + ums_dev-part_size)
+ * SECTOR_SIZE);
+ *capacity = ums_dev-mmc-capacity - tmp_capacity;
+}
+
+static struct ums_board_info ums_board = {
+ .read_sector = ums_read_sector,
+ .write_sector = ums_write_sector,
+ .get_capacity = ums_get_capacity,
+ .name = TRATS UMS disk,
+ .ums_dev = {
+ .mmc = NULL,
+ .dev_num = 0,
+ .offset = 0,
+ .part_size = 0.
+ },
+};
+
+struct ums_board_info *board_ums_init(unsigned int dev_num, unsigned int
offset,
+ unsigned int part_size)
+{
+ struct mmc *mmc;
+
+ mmc = find_mmc_device(dev_num);
+ if (!mmc)
+ return NULL;
+
+ ums_board.ums_dev.mmc = mmc;
+ ums_board.ums_dev.dev_num = dev_num;
+ ums_board.ums_dev.offset = offset;
+ ums_board.ums_dev.part_size = part_size;
+
+ return ums_board;
+}
+#endif
diff --git a/include/configs/trats.h b/include/configs/trats.h
index 63745ac..31d8190 100644
--- a/include/configs/trats.h
+++ b/include/configs/trats.h
@@ -316,4 +316,9 @@
#define CONFIG_VIDEO_BMP_GZIP
#define CONFIG_SYS_VIDEO_LOGO_MAX_SIZE ((500 * 120 * 4) + (1 12))
+#define CONFIG_CMD_USB_MASS_STORAGE
+#if defined(CONFIG_CMD_USB_MASS_STORAGE)
+#define CONFIG_USB_GADGET_MASS_STORAGE
+#endif
+
#endif /* __CONFIG_H */
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] usb: ehci: exynos: Enable non-dt path
Hi Minkyu, On Tue, Feb 12, 2013 at 1:54 PM, Minkyu Kang mk7.k...@samsung.com wrote: Dear Vivek, On 11/01/13 18:24, Vivek Gautam wrote: Enabling the non-dt path for the driver so that we don't get any build errors for non-dt configuration. Signed-off-by: Vivek Gautam gautam.vi...@samsung.com --- Earlier we had moved to fdt support for ehci-exynos driver, but missed out the non-dt path. Although this driver serves for exysno5 onward only but better to keep the non-dt path also available. drivers/usb/host/ehci-exynos.c | 10 ++ 1 files changed, 10 insertions(+), 0 deletions(-) diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c index 3ca4c5c..6f0c6c3 100644 --- a/drivers/usb/host/ehci-exynos.c +++ b/drivers/usb/host/ehci-exynos.c @@ -153,7 +153,12 @@ int ehci_hcd_init(int index, struct ehci_hccr **hccr, struct ehci_hcor **hcor) return -ENOMEM; } +#ifdef CONFIG_OF_CONTROL exynos_usb_parse_dt(gd-fdt_blob, exynos); +#else + exynos-usb = (struct exynos_usb_phy *)samsung_get_base_usb_phy(); + exynos-hcd = samsung_get_base_usb_ehci(); +#endif setup_usb_phy(exynos-usb); @@ -185,7 +190,12 @@ int ehci_hcd_stop(int index) return -ENOMEM; } +#ifdef CONFIG_OF_CONTROL exynos_usb_parse_dt(gd-fdt_blob, exynos); +#else + exynos-usb = (struct exynos_usb_phy *)samsung_get_base_usb_phy(); + exynos-hcd = samsung_get_base_usb_ehci(); +#endif reset_usb_phy(exynos-usb); Patch looks good. But I've got compiler warnings and errors when I disabled CONFIG_OF_CONTROL. exynos_spi.c:391:12: warning: 'process_nodes' defined but not used [-Wunused-function] ehci-exynos.c: In function 'ehci_hcd_init': ehci-exynos.c:160:14: warning: assignment makes pointer from integer without a cast [enabled by default] ehci-exynos.c: In function 'ehci_hcd_stop': ehci-exynos.c:197:14: warning: assignment makes pointer from integer without a cast [enabled by default] ehci-exynos.c: At top level: ehci-exynos.c:48:12: warning: 'exynos_usb_parse_dt' defined but not used [-Wunused-function] /opt/eldk-5.2/armv7a/sysroots/i686-eldk-linux/usr/bin/armv7a-vfp-neon-linux-gnueabi/arm-linux-gnueabi-ld.bfd:/home/share/Work/u-boot-samsung/spl/u-boot-spl.lds:1: ignoring invalid character `#' in expression /opt/eldk-5.2/armv7a/sysroots/i686-eldk-linux/usr/bin/armv7a-vfp-neon-linux-gnueabi/arm-linux-gnueabi-ld.bfd:/home/share/Work/u-boot-samsung/spl/u-boot-spl.lds:1: syntax error make[1]: *** [/home/share/Work/u-boot-samsung/spl/u-boot-spl] Error 1 make: *** [spl/u-boot-spl.bin] Error 2 make: *** Waiting for unfinished jobs smdk5250.c: In function 'board_eth_init': smdk5250.c:152:6: warning: unused variable 'node' [-Wunused-variable] Could you please check this issue also? Sure, will check this, and resolve the underlying issue. -- Thanks Regards Vivek ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] Tegra: fdt: Add/enhance sdhci (mmc) nodes for all T20 DT files
On Tue, Feb 12, 2013 at 07:51:55AM +0100, Thierry Reding wrote: On Mon, Feb 11, 2013 at 12:21:59PM -0700, Tom Warren wrote: Thierry/Lucas, On Mon, Feb 11, 2013 at 12:11 PM, Thierry Reding thierry.red...@avionic-design.de wrote: On Mon, Feb 11, 2013 at 10:56:33AM -0700, Tom Warren wrote: Lucas, On Mon, Feb 11, 2013 at 10:28 AM, Lucas Stach d...@lynxeye.de wrote: Hi Tom, Am Montag, den 11.02.2013, 10:17 -0700 schrieb Tom Warren: Linux dts files were used for those boards that didn't already have sdhci info populated. Tamonten has their own dtsi file with common sdhci nodes (sourced from Linux). Signed-off-by: Tom Warren twar...@nvidia.com --- v2: - cleanup comments in dts files/match w/kernel files - add sdhci aliases in all dts files - use tegra20-tamonten.dtsi from the kernel for AD boards arch/arm/dts/tegra20-tamonten.dtsi | 489 ++ I'm not sure if pushing the whole file in this patch is the right thing to do. I didn't want to edit it since we seem to be moving towards using the Linux DTS files in toto in U-Boot (as per Stephen Simon). Does it do any harm to have the whole thing here? Saves some work later. Thierry - what do you think? Given that it isn't used anywhere I don't think we really need it right now. We can always add it later when we can make better use of it. It actually is used (for SDMMC/sdhci) now, Thierry. That's why it's in this patchset. Right, I hadn't looked at that patch yet. I had originally put the sdhci node for Avionic Design boards in their respective .dts files, but Stephen pointed out that the kernel had a tegra20-tamonten.dtsi file with common info, which included the sdhci node, and asked that I use it, instead, so we echo the kernel layout. So I pulled that file into my MMC DT patchset, and used it in all AD board builds (medcom/tec/plutux) - it's pulled in via an override of CONFIG_ARCH_DEVICE_TREE in the config files. So the options seem to be: a) Don't use the tamonton dtsi file, and put the sdhci nodes in the AD dts files, just like all other boards (this was my V1 approach). Vetoed by Stephen. b) Use tegra20-tamonten.dtsi as is, identical to the kernel file. If necessary, I can move it's inclusion to a separate patch, independent of the MMC DT patchset, as suggested by Lucas. c) Use tegra20-tamonten.dtsi, but just with the sdhci node (is this what you're suggesting, Thierry?). I'd still pull it in via a CONFIG_ARCH_DEVICE_TREE #define in the AD config files. Let me know ASAP - I'd like to get V3 upstreamed soon so I can move on to work on the T30/T114 MMC patches. I think option b) sounds fine given that we want to move to the same DTS as the kernel eventually anyway. So for the Tamonten (and AD board) pieces, consider this: Acked-by: Thierry Reding thierry.red...@avionic-design.de I can't give you a Tested-by because I have a bunch of other things to take care of and I probably won't get to testing this for a few days. So it turned out that I need to touch U-Boot anyway, so I decided to give this a spin. I noticed that overriding CONFIG_ARCH_DEVICE_TREE from the board configuration file doesn't work currently. What happens is that the autoconf.mk (which is derived from the board configuration) is included before the CPU config.mk which sets CONFIG_ARCH_DEVICE_TREE to tegra20 (or tegra30, tegra114). I came up with the attached patch to set the variable if not set previously (by the board configuration file). Feel free to squash that in your patch series if you deem it a proper solution. I can also provide a proper separate patch if you prefer. Thierry diff --git a/arch/arm/cpu/armv7/tegra114/config.mk b/arch/arm/cpu/armv7/tegra114/config.mk index cb1a19d..e7c22c0 100644 --- a/arch/arm/cpu/armv7/tegra114/config.mk +++ b/arch/arm/cpu/armv7/tegra114/config.mk @@ -16,4 +16,4 @@ # You should have received a copy of the GNU General Public License # along with this program. If not, see http://www.gnu.org/licenses/. # -CONFIG_ARCH_DEVICE_TREE := tegra114 +CONFIG_ARCH_DEVICE_TREE ?= tegra114 diff --git a/arch/arm/cpu/armv7/tegra20/config.mk b/arch/arm/cpu/armv7/tegra20/config.mk index 6432e75..9042664 100644 --- a/arch/arm/cpu/armv7/tegra20/config.mk +++ b/arch/arm/cpu/armv7/tegra20/config.mk @@ -23,4 +23,4 @@ # Foundation, Inc., 59 Temple Place, Suite 330, Boston, # MA 02111-1307 USA # -CONFIG_ARCH_DEVICE_TREE := tegra20 +CONFIG_ARCH_DEVICE_TREE ?= tegra20 diff --git a/arch/arm/cpu/armv7/tegra30/config.mk b/arch/arm/cpu/armv7/tegra30/config.mk index 719ca81..0035bc5 100644 --- a/arch/arm/cpu/armv7/tegra30/config.mk +++ b/arch/arm/cpu/armv7/tegra30/config.mk @@ -16,4 +16,4 @@ # You should have received a copy of the GNU General Public License # along with this program. If not, see http://www.gnu.org/licenses/. #
Re: [U-Boot] [PATCH v2 1/2] Tegra: fdt: Add/enhance sdhci (mmc) nodes for all T20 DT files
On Tue, Feb 12, 2013 at 11:41:09AM +0100, Thierry Reding wrote: On Tue, Feb 12, 2013 at 07:51:55AM +0100, Thierry Reding wrote: On Mon, Feb 11, 2013 at 12:21:59PM -0700, Tom Warren wrote: Thierry/Lucas, On Mon, Feb 11, 2013 at 12:11 PM, Thierry Reding thierry.red...@avionic-design.de wrote: On Mon, Feb 11, 2013 at 10:56:33AM -0700, Tom Warren wrote: Lucas, On Mon, Feb 11, 2013 at 10:28 AM, Lucas Stach d...@lynxeye.de wrote: Hi Tom, Am Montag, den 11.02.2013, 10:17 -0700 schrieb Tom Warren: Linux dts files were used for those boards that didn't already have sdhci info populated. Tamonten has their own dtsi file with common sdhci nodes (sourced from Linux). Signed-off-by: Tom Warren twar...@nvidia.com --- v2: - cleanup comments in dts files/match w/kernel files - add sdhci aliases in all dts files - use tegra20-tamonten.dtsi from the kernel for AD boards arch/arm/dts/tegra20-tamonten.dtsi | 489 ++ I'm not sure if pushing the whole file in this patch is the right thing to do. I didn't want to edit it since we seem to be moving towards using the Linux DTS files in toto in U-Boot (as per Stephen Simon). Does it do any harm to have the whole thing here? Saves some work later. Thierry - what do you think? Given that it isn't used anywhere I don't think we really need it right now. We can always add it later when we can make better use of it. It actually is used (for SDMMC/sdhci) now, Thierry. That's why it's in this patchset. Right, I hadn't looked at that patch yet. I had originally put the sdhci node for Avionic Design boards in their respective .dts files, but Stephen pointed out that the kernel had a tegra20-tamonten.dtsi file with common info, which included the sdhci node, and asked that I use it, instead, so we echo the kernel layout. So I pulled that file into my MMC DT patchset, and used it in all AD board builds (medcom/tec/plutux) - it's pulled in via an override of CONFIG_ARCH_DEVICE_TREE in the config files. So the options seem to be: a) Don't use the tamonton dtsi file, and put the sdhci nodes in the AD dts files, just like all other boards (this was my V1 approach). Vetoed by Stephen. b) Use tegra20-tamonten.dtsi as is, identical to the kernel file. If necessary, I can move it's inclusion to a separate patch, independent of the MMC DT patchset, as suggested by Lucas. c) Use tegra20-tamonten.dtsi, but just with the sdhci node (is this what you're suggesting, Thierry?). I'd still pull it in via a CONFIG_ARCH_DEVICE_TREE #define in the AD config files. Let me know ASAP - I'd like to get V3 upstreamed soon so I can move on to work on the T30/T114 MMC patches. I think option b) sounds fine given that we want to move to the same DTS as the kernel eventually anyway. So for the Tamonten (and AD board) pieces, consider this: Acked-by: Thierry Reding thierry.red...@avionic-design.de I can't give you a Tested-by because I have a bunch of other things to take care of and I probably won't get to testing this for a few days. So it turned out that I need to touch U-Boot anyway, so I decided to give this a spin. I noticed that overriding CONFIG_ARCH_DEVICE_TREE from the board configuration file doesn't work currently. What happens is that the autoconf.mk (which is derived from the board configuration) is included before the CPU config.mk which sets CONFIG_ARCH_DEVICE_TREE to tegra20 (or tegra30, tegra114). I came up with the attached patch to set the variable if not set previously (by the board configuration file). Feel free to squash that in your patch series if you deem it a proper solution. I can also provide a proper separate patch if you prefer. Thierry diff --git a/arch/arm/cpu/armv7/tegra114/config.mk b/arch/arm/cpu/armv7/tegra114/config.mk index cb1a19d..e7c22c0 100644 --- a/arch/arm/cpu/armv7/tegra114/config.mk +++ b/arch/arm/cpu/armv7/tegra114/config.mk @@ -16,4 +16,4 @@ # You should have received a copy of the GNU General Public License # along with this program. If not, see http://www.gnu.org/licenses/. # -CONFIG_ARCH_DEVICE_TREE := tegra114 +CONFIG_ARCH_DEVICE_TREE ?= tegra114 diff --git a/arch/arm/cpu/armv7/tegra20/config.mk b/arch/arm/cpu/armv7/tegra20/config.mk index 6432e75..9042664 100644 --- a/arch/arm/cpu/armv7/tegra20/config.mk +++ b/arch/arm/cpu/armv7/tegra20/config.mk @@ -23,4 +23,4 @@ # Foundation, Inc., 59 Temple Place, Suite 330, Boston, # MA 02111-1307 USA # -CONFIG_ARCH_DEVICE_TREE := tegra20 +CONFIG_ARCH_DEVICE_TREE ?= tegra20 diff --git a/arch/arm/cpu/armv7/tegra30/config.mk b/arch/arm/cpu/armv7/tegra30/config.mk index 719ca81..0035bc5 100644 --- a/arch/arm/cpu/armv7/tegra30/config.mk +++
Re: [U-Boot] [PATCH v5 3/3] SPL: Change description for spl command
Dear Stefano Babic, On 02/12/2013 09:38 AM, Stefano Babic wrote: Add a more descriptive text to the help of the spl command. Signed-off-by: Stefano Babic sba...@denx.de --- Changes in v5: None Changes in v4: None Changes in v3: None That is not correct, there where changes since v3, this patch was introduced in v2. Changes in v2: None However, no complaints on the patch content. Acked-by: Andreas Bießmann andreas.de...@googlemail.com Best regards Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V3 0/5] ARM: OMAP5: Add support for OMAP543x ES2.0 Socs
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.
Adding the CPU detection suport for OMAP5430 and
OMAP5432 ES2.0 SOCs.
Signed-off-by: R Sricharan r.sricha...@ti.com
Cc: Tom Rini tr...@ti.com
Cc: Nishanth Menon n...@ti.com
---
[v2] Addressed Tom Rini's tr...@ti.com comments
[v3] Changed the patch to use CONTROL_ID_CODE first
and then arm revision if nessecary.
arch/arm/cpu/armv7/omap5/hwinit.c | 27 ---
arch/arm/include/asm/arch-omap5/omap.h |2 ++
arch/arm/include/asm/armv7.h |1 +
arch/arm/include/asm/omap_common.h |2 ++
4 files changed, 21 insertions(+), 11 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap5/hwinit.c
b/arch/arm/cpu/armv7/omap5/hwinit.c
index dfc0e44..8e66a96 100644
--- a/arch/arm/cpu/armv7/omap5/hwinit.c
+++ b/arch/arm/cpu/armv7/omap5/hwinit.c
@@ -204,17 +204,22 @@ void init_omap_revision(void)
*/
unsigned int rev = cortex_rev();
- switch (rev) {
- case MIDR_CORTEX_A15_R0P0:
- switch (readl(CONTROL_ID_CODE)) {
- case OMAP5430_CONTROL_ID_CODE_ES1_0:
- *omap_si_rev = OMAP5430_ES1_0;
- break;
- case OMAP5432_CONTROL_ID_CODE_ES1_0:
- default:
- *omap_si_rev = OMAP5432_ES1_0;
- break;
- }
+ switch (readl(CONTROL_ID_CODE)) {
+ case OMAP5430_CONTROL_ID_CODE_ES1_0:
+ *omap_si_rev = OMAP5430_ES1_0;
+ if (rev == MIDR_CORTEX_A15_R2P2)
+ *omap_si_rev = OMAP5430_ES2_0;
+ break;
+ case OMAP5432_CONTROL_ID_CODE_ES1_0:
+ *omap_si_rev = OMAP5432_ES1_0;
+ if (rev == MIDR_CORTEX_A15_R2P2)
+ *omap_si_rev = OMAP5432_ES2_0;
+ break;
+ case OMAP5430_CONTROL_ID_CODE_ES2_0:
+ *omap_si_rev = OMAP5430_ES2_0;
+ break;
+ case OMAP5432_CONTROL_ID_CODE_ES2_0:
+ *omap_si_rev = OMAP5432_ES2_0;
break;
default:
*omap_si_rev = OMAP5430_SILICON_ID_INVALID;
diff --git a/arch/arm/include/asm/arch-omap5/omap.h
b/arch/arm/include/asm/arch-omap5/omap.h
index 873ccd7..71935d8 100644
--- a/arch/arm/include/asm/arch-omap5/omap.h
+++ b/arch/arm/include/asm/arch-omap5/omap.h
@@ -57,7 +57,9 @@
/* To be verified */
#define OMAP5430_CONTROL_ID_CODE_ES1_0 0x0B94202F
+#define OMAP5430_CONTROL_ID_CODE_ES2_0 0x1B94202F
#define OMAP5432_CONTROL_ID_CODE_ES1_0 0x0B99802F
+#define OMAP5432_CONTROL_ID_CODE_ES2_0 0x1B99802F
/* STD_FUSE_PROD_ID_1 */
#define STD_FUSE_PROD_ID_1 (CTRL_BASE + 0x218)
diff --git a/arch/arm/include/asm/armv7.h b/arch/arm/include/asm/armv7.h
index ad9a875..a73630b 100644
--- a/arch/arm/include/asm/armv7.h
+++ b/arch/arm/include/asm/armv7.h
@@ -33,6 +33,7 @@
/* Cortex-A15 revisions */
#define MIDR_CORTEX_A15_R0P0 0x410FC0F0
+#define MIDR_CORTEX_A15_R2P2 0x412FC0F2
/* CCSIDR */
#define CCSIDR_LINE_SIZE_OFFSET0
diff --git a/arch/arm/include/asm/omap_common.h
b/arch/arm/include/asm/omap_common.h
index 2115687..4599167 100644
--- a/arch/arm/include/asm/omap_common.h
+++ b/arch/arm/include/asm/omap_common.h
@@ -542,4 +542,6 @@ static inline u32 omap_revision(void)
#define OMAP5430_SILICON_ID_INVALID0
#define OMAP5430_ES1_0 0x54300100
#define OMAP5432_ES1_0 0x54320100
+#define OMAP5430_ES2_0 0x54300200
+#define OMAP5432_ES2_0 0x54320200
#endif /* _OMAP_COMMON_H_ */
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V3 2/5] ARM: OMAP5: clock: Add the prcm register changes required for ES2.0
PRCM register addresses are changed from ES1.0 to ES2.0 due to
PER power domain getting moved to CORE power domain.
So adding the nessecary register changes for the same.
Signed-off-by: R Sricharan r.sricha...@ti.com
Reviewed-by: Tom Rini tr...@ti.com
Cc: Tom Rini tr...@ti.com
---
[v2] Addressed Tom Rini's tr...@ti.com comments
[v3] No Change
arch/arm/cpu/armv7/omap5/hw_data.c |5 +
arch/arm/cpu/armv7/omap5/prcm-regs.c | 283 ++
arch/arm/include/asm/omap_common.h |4 +
3 files changed, 292 insertions(+)
diff --git a/arch/arm/cpu/armv7/omap5/hw_data.c
b/arch/arm/cpu/armv7/omap5/hw_data.c
index 6b039f5..e319dc5 100644
--- a/arch/arm/cpu/armv7/omap5/hw_data.c
+++ b/arch/arm/cpu/armv7/omap5/hw_data.c
@@ -451,6 +451,11 @@ void hw_data_init(void)
*omap_vcores = omap5432_volts;
break;
+ case OMAP5430_ES2_0:
+ case OMAP5432_ES2_0:
+ *prcm = omap5_es2_prcm;
+ break;
+
default:
printf(\n INVALID OMAP REVISION );
}
diff --git a/arch/arm/cpu/armv7/omap5/prcm-regs.c
b/arch/arm/cpu/armv7/omap5/prcm-regs.c
index 0f58b2f..58c9d50 100644
--- a/arch/arm/cpu/armv7/omap5/prcm-regs.c
+++ b/arch/arm/cpu/armv7/omap5/prcm-regs.c
@@ -378,3 +378,286 @@ struct omap_sys_ctrl_regs const omap5_ctrl = {
.control_efuse_12 = 0x4AE0CDF4,
.control_efuse_13 = 0x4AE0CDF8,
};
+
+struct prcm_regs const omap5_es2_prcm = {
+ /* cm1.ckgen */
+ .cm_clksel_core = 0x4a004100,
+ .cm_clksel_abe = 0x4a004108,
+ .cm_dll_ctrl = 0x4a004110,
+ .cm_clkmode_dpll_core = 0x4a004120,
+ .cm_idlest_dpll_core = 0x4a004124,
+ .cm_autoidle_dpll_core = 0x4a004128,
+ .cm_clksel_dpll_core = 0x4a00412c,
+ .cm_div_m2_dpll_core = 0x4a004130,
+ .cm_div_m3_dpll_core = 0x4a004134,
+ .cm_div_h11_dpll_core = 0x4a004138,
+ .cm_div_h12_dpll_core = 0x4a00413c,
+ .cm_div_h13_dpll_core = 0x4a004140,
+ .cm_div_h14_dpll_core = 0x4a004144,
+ .cm_ssc_deltamstep_dpll_core = 0x4a004148,
+ .cm_ssc_modfreqdiv_dpll_core = 0x4a00414c,
+ .cm_div_h21_dpll_core = 0x4a004150,
+ .cm_div_h22_dpllcore = 0x4a004154,
+ .cm_div_h23_dpll_core = 0x4a004158,
+ .cm_div_h24_dpll_core = 0x4a00415c,
+ .cm_clkmode_dpll_mpu = 0x4a004160,
+ .cm_idlest_dpll_mpu = 0x4a004164,
+ .cm_autoidle_dpll_mpu = 0x4a004168,
+ .cm_clksel_dpll_mpu = 0x4a00416c,
+ .cm_div_m2_dpll_mpu = 0x4a004170,
+ .cm_ssc_deltamstep_dpll_mpu = 0x4a004188,
+ .cm_ssc_modfreqdiv_dpll_mpu = 0x4a00418c,
+ .cm_bypclk_dpll_mpu = 0x4a00419c,
+ .cm_clkmode_dpll_iva = 0x4a0041a0,
+ .cm_idlest_dpll_iva = 0x4a0041a4,
+ .cm_autoidle_dpll_iva = 0x4a0041a8,
+ .cm_clksel_dpll_iva = 0x4a0041ac,
+ .cm_div_h11_dpll_iva = 0x4a0041b8,
+ .cm_div_h12_dpll_iva = 0x4a0041bc,
+ .cm_ssc_deltamstep_dpll_iva = 0x4a0041c8,
+ .cm_ssc_modfreqdiv_dpll_iva = 0x4a0041cc,
+ .cm_bypclk_dpll_iva = 0x4a0041dc,
+ .cm_clkmode_dpll_abe = 0x4a0041e0,
+ .cm_idlest_dpll_abe = 0x4a0041e4,
+ .cm_autoidle_dpll_abe = 0x4a0041e8,
+ .cm_clksel_dpll_abe = 0x4a0041ec,
+ .cm_div_m2_dpll_abe = 0x4a0041f0,
+ .cm_div_m3_dpll_abe = 0x4a0041f4,
+ .cm_ssc_deltamstep_dpll_abe = 0x4a004208,
+ .cm_ssc_modfreqdiv_dpll_abe = 0x4a00420c,
+ .cm_clkmode_dpll_ddrphy = 0x4a004220,
+ .cm_idlest_dpll_ddrphy = 0x4a004224,
+ .cm_autoidle_dpll_ddrphy = 0x4a004228,
+ .cm_clksel_dpll_ddrphy = 0x4a00422c,
+ .cm_div_m2_dpll_ddrphy = 0x4a004230,
+ .cm_div_h11_dpll_ddrphy = 0x4a004238,
+ .cm_div_h12_dpll_ddrphy = 0x4a00423c,
+ .cm_div_h13_dpll_ddrphy = 0x4a004240,
+ .cm_ssc_deltamstep_dpll_ddrphy = 0x4a004248,
+ .cm_shadow_freq_config1 = 0x4a004260,
+ .cm_mpu_mpu_clkctrl = 0x4a004320,
+
+ /* cm1.dsp */
+ .cm_dsp_clkstctrl = 0x4a004400,
+ .cm_dsp_dsp_clkctrl = 0x4a004420,
+
+ /* cm1.abe */
+ .cm1_abe_clkstctrl = 0x4a004500,
+ .cm1_abe_l4abe_clkctrl = 0x4a004520,
+ .cm1_abe_aess_clkctrl = 0x4a004528,
+ .cm1_abe_pdm_clkctrl = 0x4a004530,
+ .cm1_abe_dmic_clkctrl = 0x4a004538,
+ .cm1_abe_mcasp_clkctrl = 0x4a004540,
+ .cm1_abe_mcbsp1_clkctrl = 0x4a004548,
+ .cm1_abe_mcbsp2_clkctrl = 0x4a004550,
+ .cm1_abe_mcbsp3_clkctrl = 0x4a004558,
+ .cm1_abe_slimbus_clkctrl = 0x4a004560,
+ .cm1_abe_timer5_clkctrl = 0x4a004568,
+ .cm1_abe_timer6_clkctrl = 0x4a004570,
+ .cm1_abe_timer7_clkctrl = 0x4a004578,
+ .cm1_abe_timer8_clkctrl = 0x4a004580,
+ .cm1_abe_wdt3_clkctrl = 0x4a004588,
+
+
+
+ /* cm2.ckgen */
+ .cm_clksel_mpu_m3_iss_root = 0x4a008100,
+ .cm_clksel_usb_60mhz = 0x4a008104,
+ .cm_scale_fclk = 0x4a008108,
+ .cm_core_dvfs_perf1 = 0x4a008110,
+ .cm_core_dvfs_perf2 =
[U-Boot] [PATCH V3 4/5] ARM: OMAP5: Add DDR changes required for OMAP543X ES2.0 SOCs
From: Lokesh Vutla lokeshvu...@ti.com
Add pre calculated timing settings of LPDDR2 and DDR3 memories
present in OMAP5430 and OMAP5432 ES2.0 versions.
Also adding the DDR pad io settings required for
OMAP543X SOCs here.
Signed-off-by: R Sricharan r.sricha...@ti.com
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
Reviewed-by: Tom Rini tr...@ti.com
Cc: Tom Rini tr...@ti.com
---
[v2] Addressed Tom Rini's tr...@ti.com comments
[v3] No Change
arch/arm/cpu/armv7/omap5/hw_data.c | 14 ++
arch/arm/cpu/armv7/omap5/sdram.c | 75 +++-
arch/arm/include/asm/arch-omap5/omap.h |6 +++
arch/arm/include/asm/emif.h|1 +
4 files changed, 94 insertions(+), 2 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap5/hw_data.c
b/arch/arm/cpu/armv7/omap5/hw_data.c
index 6470ece..772fdfb 100644
--- a/arch/arm/cpu/armv7/omap5/hw_data.c
+++ b/arch/arm/cpu/armv7/omap5/hw_data.c
@@ -488,6 +488,16 @@ const struct ctrl_ioregs ioregs_omap5432_es1 = {
.ctrl_emif_sdram_config_ext = SDRAM_CONFIG_EXT_RD_LVL_11_SAMPLES,
};
+const struct ctrl_ioregs ioregs_omap5432_es2 = {
+ .ctrl_ddrch = DDR_IO_I_40OHM_SR_FAST_WD_DQ_NO_PULL_DQS_NO_PULL_ES2,
+ .ctrl_lpddr2ch = 0x0,
+ .ctrl_ddr3ch = DDR_IO_I_40OHM_SR_SLOWEST_WD_DQ_NO_PULL_DQS_NO_PULL_ES2,
+ .ctrl_ddrio_0 = DDR_IO_0_VREF_CELLS_DDR3_VALUE_ES2,
+ .ctrl_ddrio_1 = DDR_IO_1_VREF_CELLS_DDR3_VALUE_ES2,
+ .ctrl_ddrio_2 = DDR_IO_2_VREF_CELLS_DDR3_VALUE_ES2,
+ .ctrl_emif_sdram_config_ext = SDRAM_CONFIG_EXT_RD_LVL_11_SAMPLES,
+};
+
void hw_data_init(void)
{
u32 omap_rev = omap_revision();
@@ -526,11 +536,15 @@ void get_ioregs(const struct ctrl_ioregs **regs)
switch (omap_rev) {
case OMAP5430_ES1_0:
+ case OMAP5430_ES2_0:
*regs = ioregs_omap5430;
break;
case OMAP5432_ES1_0:
*regs = ioregs_omap5432_es1;
break;
+ case OMAP5432_ES2_0:
+ *regs = ioregs_omap5432_es2;
+ break;
default:
printf(\n INVALID OMAP REVISION );
diff --git a/arch/arm/cpu/armv7/omap5/sdram.c b/arch/arm/cpu/armv7/omap5/sdram.c
index 687800f..2ef7fcd 100644
--- a/arch/arm/cpu/armv7/omap5/sdram.c
+++ b/arch/arm/cpu/armv7/omap5/sdram.c
@@ -67,6 +67,25 @@ const struct emif_regs emif_regs_532_mhz_2cs = {
.emif_ddr_ext_phy_ctrl_5= 0x04010040
};
+const struct emif_regs emif_regs_532_mhz_2cs_es2 = {
+ .sdram_config_init = 0x80800EBA,
+ .sdram_config = 0x808022BA,
+ .ref_ctrl = 0x081A,
+ .sdram_tim1 = 0x772F6873,
+ .sdram_tim2 = 0x304a129a,
+ .sdram_tim3 = 0x02f7e45f,
+ .read_idle_ctrl = 0x0005,
+ .zq_config = 0x100b3215,
+ .temp_alert_config = 0x08000a05,
+ .emif_ddr_phy_ctlr_1_init = 0x0E30400d,
+ .emif_ddr_phy_ctlr_1= 0x0E30400d,
+ .emif_ddr_ext_phy_ctrl_1= 0x04020080,
+ .emif_ddr_ext_phy_ctrl_2= 0x28C518A3,
+ .emif_ddr_ext_phy_ctrl_3= 0x518A3146,
+ .emif_ddr_ext_phy_ctrl_4= 0x0014628C,
+ .emif_ddr_ext_phy_ctrl_5= 0xC330CC33,
+};
+
const struct emif_regs emif_regs_266_mhz_2cs = {
.sdram_config_init = 0x80800EBA,
.sdram_config = 0x808022BA,
@@ -109,6 +128,29 @@ const struct emif_regs emif_regs_ddr3_532_mhz_1cs = {
.emif_rd_wr_exec_thresh = 0x0305
};
+const struct emif_regs emif_regs_ddr3_532_mhz_1cs_es2 = {
+ .sdram_config_init = 0x61851B32,
+ .sdram_config = 0x61851B32,
+ .ref_ctrl = 0x1035,
+ .sdram_tim1 = 0xCCCF36B3,
+ .sdram_tim2 = 0x308F7FDA,
+ .sdram_tim3 = 0x027F88A8,
+ .read_idle_ctrl = 0x0005,
+ .zq_config = 0x1007190B,
+ .temp_alert_config = 0x,
+ .emif_ddr_phy_ctlr_1_init = 0x0030400A,
+ .emif_ddr_phy_ctlr_1= 0x0034400A,
+ .emif_ddr_ext_phy_ctrl_1= 0x04040100,
+ .emif_ddr_ext_phy_ctrl_2= 0x,
+ .emif_ddr_ext_phy_ctrl_3= 0x,
+ .emif_ddr_ext_phy_ctrl_4= 0x,
+ .emif_ddr_ext_phy_ctrl_5= 0x4350D435,
+ .emif_rd_wr_lvl_rmp_win = 0x,
+ .emif_rd_wr_lvl_rmp_ctl = 0x8000,
+ .emif_rd_wr_lvl_ctl = 0x,
+ .emif_rd_wr_exec_thresh = 0x4305
+};
+
const struct dmm_lisa_map_regs lisa_map_4G_x_2_x_2 = {
.dmm_lisa_map_0 = 0x0,
.dmm_lisa_map_1 = 0x0,
@@ -125,8 +167,12 @@ static void emif_get_reg_dump_sdp(u32 emif_nr, const
struct emif_regs
[U-Boot] [PATCH V3 5/5] ARM: OMAP5: srcomp: enable slew rate compensation cells after powerup
From: Lokesh Vutla lokeshvu...@ti.com
After power-up SRCOMP cells are by-passed by default in OMAP5.
Software has to enable these SRCOMP sells.
For ES2: All 5 SRCOMP cells needs to be enabled.
For ES1: Only 4 SRCOMP cells in core power domain are enabled.
The 1 in wkup domain is not enabled because smart i/os
of wkup domain work with default compensation code.
Signed-off-by: R Sricharan r.sricha...@ti.com
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
Reviewed-by: Tom Rini tr...@ti.com
Cc: Tom Rini tr...@ti.com
---
[v2] Addressed Tom Rini's tr...@ti.com comments
[v3] No Change
arch/arm/cpu/armv7/omap-common/hwinit-common.c |6 ++
arch/arm/cpu/armv7/omap5/hwinit.c | 116
arch/arm/cpu/armv7/omap5/prcm-regs.c |5 +-
arch/arm/include/asm/arch-omap5/clocks.h |4 +
arch/arm/include/asm/arch-omap5/omap.h | 19
arch/arm/include/asm/arch-omap5/sys_proto.h|1 +
arch/arm/include/asm/omap_common.h |2 +
7 files changed, 152 insertions(+), 1 deletion(-)
diff --git a/arch/arm/cpu/armv7/omap-common/hwinit-common.c
b/arch/arm/cpu/armv7/omap-common/hwinit-common.c
index e5a5eb6..60af7eb 100644
--- a/arch/arm/cpu/armv7/omap-common/hwinit-common.c
+++ b/arch/arm/cpu/armv7/omap-common/hwinit-common.c
@@ -33,6 +33,7 @@
#include asm/sizes.h
#include asm/emif.h
#include asm/omap_common.h
+#include linux/compiler.h
DECLARE_GLOBAL_DATA_PTR;
@@ -100,6 +101,10 @@ void spl_display_print(void)
}
#endif
+void __weak srcomp_enable(void)
+{
+}
+
/*
* Routine: s_init
* Description: Does early system init of watchdog, muxing, andclocks
@@ -126,6 +131,7 @@ void s_init(void)
watchdog_init();
set_mux_conf_regs();
#ifdef CONFIG_SPL_BUILD
+ srcomp_enable();
setup_clocks_for_console();
gd = gdata;
diff --git a/arch/arm/cpu/armv7/omap5/hwinit.c
b/arch/arm/cpu/armv7/omap5/hwinit.c
index 8e66a96..f083198 100644
--- a/arch/arm/cpu/armv7/omap5/hwinit.c
+++ b/arch/arm/cpu/armv7/omap5/hwinit.c
@@ -32,6 +32,7 @@
#include asm/armv7.h
#include asm/arch/cpu.h
#include asm/arch/sys_proto.h
+#include asm/arch/clocks.h
#include asm/sizes.h
#include asm/utils.h
#include asm/arch/gpio.h
@@ -182,6 +183,121 @@ void do_io_settings(void)
writel(EFUSE_3, (*ctrl)-control_efuse_3);
writel(EFUSE_4, (*ctrl)-control_efuse_4);
}
+
+static const struct srcomp_params srcomp_parameters[NUM_SYS_CLKS] = {
+ {0x45, 0x1},/* 12 MHz */
+ {-1, -1}, /* 13 MHz */
+ {0x63, 0x2},/* 16.8 MHz */
+ {0x57, 0x2},/* 19.2 MHz */
+ {0x20, 0x1},/* 26 MHz */
+ {-1, -1}, /* 27 MHz */
+ {0x41, 0x3} /* 38.4 MHz */
+};
+
+void srcomp_enable(void)
+{
+ u32 srcomp_value, mul_factor, div_factor, clk_val, i;
+ u32 sysclk_ind = get_sys_clk_index();
+ u32 omap_rev= omap_revision();
+
+ mul_factor = srcomp_parameters[sysclk_ind].multiply_factor;
+ div_factor = srcomp_parameters[sysclk_ind].divide_factor;
+
+ for (i = 0; i 4; i++) {
+ srcomp_value = readl((*ctrl)-control_srcomp_north_side + i*4);
+ srcomp_value =
+ ~(MULTIPLY_FACTOR_XS_MASK | DIVIDE_FACTOR_XS_MASK);
+ srcomp_value |= (mul_factor MULTIPLY_FACTOR_XS_SHIFT) |
+ (div_factor DIVIDE_FACTOR_XS_SHIFT);
+ writel(srcomp_value, (*ctrl)-control_srcomp_north_side + i*4);
+ }
+
+ if ((omap_rev == OMAP5430_ES1_0) || (omap_rev == OMAP5432_ES1_0)) {
+ clk_val = readl((*prcm)-cm_coreaon_io_srcomp_clkctrl);
+ clk_val |= OPTFCLKEN_SRCOMP_FCLK_MASK;
+ writel(clk_val, (*prcm)-cm_coreaon_io_srcomp_clkctrl);
+
+ for (i = 0; i 4; i++) {
+ srcomp_value =
+ readl((*ctrl)-control_srcomp_north_side + i*4);
+ srcomp_value = ~PWRDWN_XS_MASK;
+ writel(srcomp_value,
+ (*ctrl)-control_srcomp_north_side + i*4);
+
+ while (((readl((*ctrl)-control_srcomp_north_side + i*4)
+SRCODE_READ_XS_MASK)
+ SRCODE_READ_XS_SHIFT) == 0)
+ ;
+
+ srcomp_value =
+ readl((*ctrl)-control_srcomp_north_side + i*4);
+ srcomp_value = ~OVERRIDE_XS_MASK;
+ writel(srcomp_value,
+ (*ctrl)-control_srcomp_north_side + i*4);
+ }
+ } else {
+ srcomp_value = readl((*ctrl)-control_srcomp_east_side_wkup);
+ srcomp_value = ~(MULTIPLY_FACTOR_XS_MASK |
+ DIVIDE_FACTOR_XS_MASK);
+ srcomp_value |= (mul_factor MULTIPLY_FACTOR_XS_SHIFT) |
+
[U-Boot] [PATCH V3 3/5] ARM: OMAP4/5: clocks: Add the required OPP settings as per the latest addendum
Change OPP settings as per the latest 0.5 version of
addendum for OMAP5430 ES2.0. omap4/hw_data.c is touched
here to add dummy dividers.
While here correcting OPP_NOM mpu, core frequency for
OMAP4430 ES2.x
Note that OMAP5430 ES1.0 support is still kept alive and
would be removed in a cleanup later.
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
Signed-off-by: R Sricharan r.sricha...@ti.com
Cc: Tom Rini tr...@ti.com
Cc: Nishanth Menon n...@ti.com
---
[v2] Addressed Tom Rini's tr...@ti.com comments
[v3] Addressed some of Nishanth's comments here.
Essentially added missing OPP_HIGH/LOW settings
for OMAP5 E2.0 and corrected the data as per the
0.5 addendum. Also added comments for both OMAP4/5
frequency tables. Rephrased the subject accordingly.
arch/arm/cpu/armv7/omap-common/clocks-common.c |9 +-
arch/arm/cpu/armv7/omap4/hw_data.c | 164 +
arch/arm/cpu/armv7/omap5/hw_data.c | 235 ++--
arch/arm/include/asm/arch-omap5/clocks.h | 29 ++-
arch/arm/include/asm/omap_common.h |6 +-
5 files changed, 254 insertions(+), 189 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap-common/clocks-common.c
b/arch/arm/cpu/armv7/omap-common/clocks-common.c
index 88e5336..818a963 100644
--- a/arch/arm/cpu/armv7/omap-common/clocks-common.c
+++ b/arch/arm/cpu/armv7/omap-common/clocks-common.c
@@ -103,10 +103,14 @@ void setup_post_dividers(u32 const base, const struct
dpll_params *params)
writel(params-m6_h13, dpll_regs-cm_div_m6_h13_dpll);
if (params-m7_h14 = 0)
writel(params-m7_h14, dpll_regs-cm_div_m7_h14_dpll);
+ if (params-h21 = 0)
+ writel(params-h21, dpll_regs-cm_div_h21_dpll);
if (params-h22 = 0)
writel(params-h22, dpll_regs-cm_div_h22_dpll);
if (params-h23 = 0)
writel(params-h23, dpll_regs-cm_div_h23_dpll);
+ if (params-h24 = 0)
+ writel(params-h24, dpll_regs-cm_div_h24_dpll);
}
static inline void do_bypass_dpll(u32 const base)
@@ -319,11 +323,6 @@ void configure_mpu_dpll(void)
CM_CLKSEL_DCC_EN_MASK);
}
- setbits_le32((*prcm)-cm_mpu_mpu_clkctrl,
- MPU_CLKCTRL_CLKSEL_EMIF_DIV_MODE_MASK);
- setbits_le32((*prcm)-cm_mpu_mpu_clkctrl,
- MPU_CLKCTRL_CLKSEL_ABE_DIV_MODE_MASK);
-
params = get_mpu_dpll_params(*dplls_data);
do_setup_dpll((*prcm)-cm_clkmode_dpll_mpu, params, DPLL_LOCK, mpu);
diff --git a/arch/arm/cpu/armv7/omap4/hw_data.c
b/arch/arm/cpu/armv7/omap4/hw_data.c
index 892d016..8d31d6d 100644
--- a/arch/arm/cpu/armv7/omap4/hw_data.c
+++ b/arch/arm/cpu/armv7/omap4/hw_data.c
@@ -49,115 +49,127 @@ struct omap_sys_ctrl_regs const **ctrl =
* Please use this tool for creating the table for any new frequency.
*/
-/* dpll locked at 1400 MHz MPU clk at 700 MHz(OPP100) - DCC OFF */
+/*
+ * dpll locked at 1400 MHz MPU clk at 700 MHz(OPP100) - DCC OFF
+ * OMAP4460 OPP_NOM frequency
+ */
static const struct dpll_params mpu_dpll_params_1400mhz[NUM_SYS_CLKS] = {
- {175, 2, 1, -1, -1, -1, -1, -1, -1, -1},/* 12 MHz */
- {700, 12, 1, -1, -1, -1, -1, -1, -1, -1}, /* 13 MHz */
- {125, 2, 1, -1, -1, -1, -1, -1, -1, -1},/* 16.8 MHz */
- {401, 10, 1, -1, -1, -1, -1, -1, -1, -1}, /* 19.2 MHz */
- {350, 12, 1, -1, -1, -1, -1, -1, -1, -1}, /* 26 MHz */
- {700, 26, 1, -1, -1, -1, -1, -1, -1, -1}, /* 27 MHz */
- {638, 34, 1, -1, -1, -1, -1, -1, -1, -1}/* 38.4 MHz */
+ {175, 2, 1, -1, -1, -1, -1, -1, -1, -1, -1, -1},/* 12 MHz */
+ {700, 12, 1, -1, -1, -1, -1, -1, -1, -1, -1, -1}, /* 13 MHz */
+ {125, 2, 1, -1, -1, -1, -1, -1, -1, -1, -1, -1},/* 16.8 MHz */
+ {401, 10, 1, -1, -1, -1, -1, -1, -1, -1, -1, -1}, /* 19.2 MHz */
+ {350, 12, 1, -1, -1, -1, -1, -1, -1, -1, -1, -1}, /* 26 MHz */
+ {700, 26, 1, -1, -1, -1, -1, -1, -1, -1, -1, -1}, /* 27 MHz */
+ {638, 34, 1, -1, -1, -1, -1, -1, -1, -1, -1, -1}/* 38.4 MHz */
};
-/* dpll locked at 1584 MHz - MPU clk at 792 MHz(OPP Turbo 4430) */
+/*
+ * dpll locked at 1600 MHz - MPU clk at 800 MHz(OPP Turbo 4430)
+ * OMAP4430 OPP_TURBO frequency
+ */
static const struct dpll_params mpu_dpll_params_1600mhz[NUM_SYS_CLKS] = {
- {200, 2, 1, -1, -1, -1, -1, -1, -1, -1},/* 12 MHz */
- {800, 12, 1, -1, -1, -1, -1, -1, -1, -1}, /* 13 MHz */
- {619, 12, 1, -1, -1, -1, -1, -1, -1, -1}, /* 16.8 MHz */
- {125, 2, 1, -1, -1, -1, -1, -1, -1, -1},/* 19.2 MHz */
- {400, 12, 1, -1, -1, -1, -1, -1, -1, -1}, /* 26 MHz */
- {800, 26, 1, -1, -1, -1, -1, -1, -1, -1}, /* 27 MHz */
- {125, 5, 1, -1, -1, -1, -1, -1, -1, -1} /* 38.4 MHz */
+ {200, 2, 1, -1, -1, -1, -1, -1, -1, -1, -1, -1},
Re: [U-Boot] [PATCH v5 1/3] Add README for the Falcon mode
Dear Stefano Babic, On 02/12/2013 09:38 AM, Stefano Babic wrote: Simple howto to add support to a board for booting the kernel from SPL (Falcon mode). Signed-off-by: Stefano Babic sba...@denx.de --- Changes in v5: - several fixes for the language, rephrasing some unclear parts (Vikram Narayanan) Changes in v4: - fix capitalization, styling, in spl help (Andreas Biessmann) - move CONFIG_SPL_OS_BOOT before function in doc (Andreas Biessmann) Changes in v3: - parameter initrd_addr was removed in V2 (Andreas Biessmann) - added patch to fix help usage for spl export (Andreas Biessmann) - Added empty lines (Otavio Salvador) - add a more exhaustive description explaining that spl export does not save into media (Lukasz Majewski). Changes in v2: - spelling, language fixes (Andreas Biessman) - rewrite some unclear sentences - drop CONFIG_SPL_OS_BOOT_KEY - make example with twister more exhaustive doc/README.falcon | 169 + 1 file changed, 169 insertions(+) create mode 100644 doc/README.falcon diff --git a/doc/README.falcon b/doc/README.falcon new file mode 100644 index 000..72fe04a --- /dev/null +++ b/doc/README.falcon @@ -0,0 +1,169 @@ +U-Boot Falcon Mode + + +Introduction + + +This document provides an overview of how to add support for Falcon Mode +to a board. +Falcon Mode is introduced to speed up the booting process, allowing +to boot a Linux kernel (or whatever image) without a full blown U-Boot. + +Falcon Mode relies on the SPL framework. In fact, to make booting faster, +U-Boot is split into two parts: the SPL (Secondary Program Loader) and U-Boot +image. In most implementations, SPL is used to start U-Boot when booting from +a mass storage, such as NAND or SD-Card. SPL has now support for other media, +and can generally be seen as a way to start an image performing the minimum +required initialization. SPL mainly initializes the RAM controller, and then +copies U-Boot image into the memory. The Falcon Mode extends this way +allowing to start the Linux kernel directly from SPL. A new command is added +to U-Boot to prepare the parameters that SPL must pass to the kernel, using +ATAGS or Device Tree. + +In usual U-Boot systems, these parameters are generated each time before +loading the kernel, passing to Linux the address in memory where +the parameters can be read. +With Falcon Mode, this snapshot can be saved into persistent storage and SPL is +informed to load it before running the kernel. + +To boot the kernel, these steps under a Falcon-aware U-Boot are required: + +1. Boot the board into U-Boot. +Use the spl export command to generate the kernel parameters area or the DT. +U-Boot runs as when it boots the kernel, but stops before passing the control +to the kernel. + +2. Save the prepared snapshot into persistent media. +The address where to save it must be configured into board configuration +file (CONFIG_CMD_SPL_NAND_OFS for NAND). + +3. Boot the board into Falcon Mode. SPL will load the kernel and copy +the parameters which are saved in the persistent area area to the required address. double 'area' + +It is required to implement a custom mechanism to select if SPL loads U-Boot +or another image. + +The value of a GPIO is a simple way to operate the selection, as well as +reading a character from the SPL console if CONFIG_SPL_CONSOLE is set. + +Falcon Mode is generally activated by setting CONFIG_SPL_OS_BOOT. This tells +SPL that U-Boot is not the only available image that SPL is able to start. + +Configuration + +CONFIG_CMD_SPL Enable the spl export command. + The command spl export is then available in U-Boot + mode +CONFIG_SYS_SPL_ARGS_ADDR Address in RAM where the parameters must be + copied by SPL. + In most cases, it is start_of_ram + 0x100 + +CONFIG_SYS_NAND_SPL_KERNEL_OFFS Offset in NAND where the kernel is stored + +CONFIG_CMD_SPL_NAND_OFS Offset in NAND where the parameters area was saved. + +CONFIG_CMD_SPL_WRITE_SIZESize of the parameters area to be copied + +CONFIG_SPL_OS_BOOT Activate Falcon Mode. + +Function that a board must implement + + +void spl_board_prepare_for_linux(void) : optional + Called from SPL before starting the kernel + +spl_start_uboot() : required + Returns 0 if SPL starts the kernel, 1 if U-Boot minor complaint: Returns 0 if SPL should start the kernel, ... + must be started. + + +Using spl command +- + +spl - SPL configuration + +Usage: + +spl export img=atags|fdt [kernel_addr] [initrd_addr] [fdt_addr ] ---^ This comes from 'spl
Re: [U-Boot] [PATCH v5 1/3] Add README for the Falcon mode
On 12.02.2013 12:48, Andreas Bießmann wrote: big snip The spl export command does not write to a storage media. The user is responsible to transfer the gathered information (assembled ATAGS list or prepared FDT) from temporary storage in RAM into persistant storage after each run of 'spl export'. Unfortunately the position of temporary storage can not be predicted nor provided at commandline, it depends highly on your system setup and your provided data (ATAGS or FDT). However at the end of an succesful 'spl export' run it will print the RAM address of temporary storage. Now the user have to save the generated BLOB from that printed address to the pre-defined address in persistent storage (CONFIG_CMD_SPL_NAND_OFS in case of NAND). The following example shows how to prepare the data for Falcon Mode on twister board with ATAGS BLOB. ---8--- Would be nice to have some FDT example too (in future). I used FDT with SPL already on the a3m071 board. Please take a look at the README (board/a3m071/README): ... Preparing Linux image(s) for booting from SPL U-Boot: - To boot the Linux kernel from the SPL, the DT blob (fdt) needs to get prepard/patched first. U-Boot usually inserts some dynamic values into the DT binary (blob), e.g. autodetected memory size, MAC addresses, clocks speeds etc. To generate this patched DT blob, you can use the following command: 1. Load fdt blob to SDRAM: = tftp 180 a3m071/a3m071.dtb 2. Set bootargs as desired for Linux booting (e.g. flash_mtd): = run mtdargs addip2 addtty 3. Use fdt commands to patch the DT blob: = fdt addr 180 = fdt boardsetup = fdt chosen 4. Display patched DT blob (optional): = fdt print 5. Save fdt to NOR flash: = erase fc06 fc07 = cp.b 180 fc06 1 ... So all we need for DT based booting (compared to ATAG booting) is the fdt command. Stefano, perhaps you could integrate this into this README as well. Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] mx6: Disable Power Down Bit of watchdog
On 07/02/2013 17:45, Fabio Estevam wrote: On a mx6qsabresd revision C board with rev1.2 mx6q, the system gets resetted and it is not able to reach the Linux prompt. Comparing the watchdog behaviour on a revB versus revC board: - On a mx6qsabresd revB: U-Boot reset resetting ... U-Boot 2013.01-10524-g432a3aa-dirty (Feb 07 2013 - 13:34:46) CPU: Freescale i.MX6Q rev1.1 at 792 MHz Reset cause: WDOG ... - On a mx6qsabresd revC: U-Boot reset resetting ... U-Boot 2013.01-10524-g432a3aa-dirty (Feb 07 2013 - 13:34:46) CPU: Freescale i.MX6Q rev1.1 at 792 MHz Reset cause: POR So due to revC POR/watchdog circuitry whenever a watchdog occurs, it causes a POR. Clearing the PDE - Power Down Enable bit of WMCR registers fixes the problem and is also safe for all mx6 boards. Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- Acked-by: Stefano Babic sba...@denx.de Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 1/3] Add README for the Falcon mode
Dear Stefan Roese, On 02/12/2013 01:09 PM, Stefan Roese wrote: On 12.02.2013 12:48, Andreas Bießmann wrote: snip 3. Use fdt commands to patch the DT blob: = fdt addr 180 = fdt boardsetup = fdt chosen 4. Display patched DT blob (optional): = fdt print 5. Save fdt to NOR flash: = erase fc06 fc07 = cp.b 180 fc06 1 ... So all we need for DT based booting (compared to ATAG booting) is the fdt command. As I understand this guide there is no 'spl export' required for 'Falcon Mode' with FDT, is that correct? Stefano, perhaps you could integrate this into this README as well. +1 Best regards Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 2/3] Tegra114: fdt: Update DT files with I2C info for T114/Dalmore
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
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
On 30/01/2013 22:19, Benoît Thébaudeau wrote: MMDC1_MDCFG1.tMRD should be set to max(tMRD, tMOD) for DDR3. For all DDR3 speed bins: tMRD(min) = 4 nCK tMOD(min) = max(12 nCK, 15 ns) Hence, MMDC1_MDCFG1.tMRD should be set to max(12 nCK, 15 ns), which is 12 nCK at 532 MHz, encoded as 0xB in the bit-field MMDC1_MDCFG1[8:5]. Signed-off-by: Benoît Thébaudeau benoit.thebaud...@advansee.com --- board/freescale/imx/ddr/mx6q_4x_mt41j128.cfg |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/board/freescale/imx/ddr/mx6q_4x_mt41j128.cfg b/board/freescale/imx/ddr/mx6q_4x_mt41j128.cfg index c86cd40..9ac8027 100644 --- a/board/freescale/imx/ddr/mx6q_4x_mt41j128.cfg +++ b/board/freescale/imx/ddr/mx6q_4x_mt41j128.cfg @@ -110,7 +110,7 @@ DATA 4 0x021b0018 0x00081740 DATA 4 0x021b001c 0x8000 DATA 4 0x021b000c 0x555A7975 -DATA 4 0x021b0010 0xFF538E64 +DATA 4 0x021b0010 0xFF538F64 DATA 4 0x021b0014 0x01FF00DB DATA 4 0x021b002c 0x26D2 Applied (whole series) to u-boot-imx, thanks. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] mx6: Disable Power Down Bit of watchdog
On 07/02/2013 17:45, Fabio Estevam wrote: On a mx6qsabresd revision C board with rev1.2 mx6q, the system gets resetted and it is not able to reach the Linux prompt. Comparing the watchdog behaviour on a revB versus revC board: - On a mx6qsabresd revB: U-Boot reset resetting ... U-Boot 2013.01-10524-g432a3aa-dirty (Feb 07 2013 - 13:34:46) CPU: Freescale i.MX6Q rev1.1 at 792 MHz Reset cause: WDOG ... - On a mx6qsabresd revC: U-Boot reset resetting ... U-Boot 2013.01-10524-g432a3aa-dirty (Feb 07 2013 - 13:34:46) CPU: Freescale i.MX6Q rev1.1 at 792 MHz Reset cause: POR So due to revC POR/watchdog circuitry whenever a watchdog occurs, it causes a POR. Clearing the PDE - Power Down Enable bit of WMCR registers fixes the problem and is also safe for all mx6 boards. Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- Applied to u-boot-imx, thanks. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 1/3] Add README for the Falcon mode
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
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
Hi Stefano, On Saturday, February 9, 2013 5:38:26 PM, Benoît Thébaudeau wrote: On Saturday, February 9, 2013 2:53:44 PM, Benoît Thébaudeau wrote: On Saturday, February 9, 2013 12:47:25 AM, Benoît Thébaudeau wrote: On Friday, February 8, 2013 11:49:27 PM, Benoît Thébaudeau wrote: Subject: [PATCH v5 8/8] nand: mxc: Switch NAND SPL to generic SPL Signed-off-by: Benoît Thébaudeau benoit.thebaud...@advansee.com --- Changes in v5: - Remove spaces between function name and open parenthesis. - Fix mx31pdk and tx25 Makefile-s and SPL linker scripts. - Remove the useless definition of CONFIG_SPL_LDSCRIPT. - Fix the call to nand_boot(). Changes in v4: - New patch. Changes in v3: None Changes in v2: None This is now supposed to be working and compile-tested. Custodians, please review and advise. Board maintainers, please test. Tell me if I should split away some stuff. Should doc/README.arm-relocation be updated, and how since tx25 no longer uses NAND SPL, which is also deprecated? Note that mx31pdk and tx25 had been broken by commit e05e5de7fae5bec79617e113916dac6631251156. After this commit, for those boards, _main called board_init_f, which called relocate_code, which unexpectedly (for their users) returned to nowhere in ctr0.S instead of calling nand_boot. Also, crt0.S calls nand_boot if CONFIG_SPL_BUILD is not defined but CONFIG_NAND_SPL is, which is not normal for NAND SPL. Other NAND SPL boards may be broken too, but that's not too much of an issue since they are supposed to migrate to generic SPL. I am also wondering if board_init_f should not be moved out of mxc_nand_spl.c to either board/lowlevel_init.S or board/board.c. That would make mxc_nand_spl.c more generic if for some reason a board needs to do specific things. Any opinion? For the start.S files, since it's not possible to know from CONFIG_SPL_BUILD and CONFIG_NAND_SPL if relocate_code is needed or not, I see the following choices: 1) Let it defined in all cases. It's quite small, so it won't hurt much. 2) Create a specific SPL #define (e.g. CONFIG_SPL_RELOCATE_CODE) to define it for generic SPL only if needed. 3) Just create a specific linker section for it so that it's automatically garbage-collected if unneeded. Any opinion? I'm also considering to factorize relocate_code to crt0.S. There's not really a good reason for it to be depending on each ARM processor. Any opinion? FYI, I will post soon a v6 with a lot of cleanup. Best regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Fwd: pull request for u-boot-tegra/master into ARM/master
Hi Tom, On Mon, 11 Feb 2013 14:20:00 -0700, Tom Warren twarren.nvi...@gmail.com wrote: Dropped the list from the PR. Sorry 'bout that. Applied to u-boot-arm/master, thanks! -- Forwarded message -- From: Tom Warren twarren.nvi...@gmail.com Date: Mon, Feb 11, 2013 at 11:05 AM Subject: pull request for u-boot-tegra/master into ARM/master To: Albert ARIBAUD albert.u.b...@aribaud.net Cc: Tom Warren twar...@nvidia.com, Stephen Warren swar...@nvidia.com, Simon Glass s...@chromium.org, Wolfgang Denk w...@denx.de, Allen Martin amar...@nvidia.com, Lucas Stach d...@lynxeye.de Albert, Please pull u-boot-tegra/master into ARM/master. Thanks! ./MAKEALL -a arm completed over the weekend w/o any new errors, and checkpatch is clean. The following changes since commit 8978f860a64eecfa088c1088bc0c2002ec316362: Tom Rini (1): am33xx: Drop gpio0_7_pin_mux from phytec pcm051 are available in the git repository at: git://git.denx.de/u-boot-tegra master Allen Martin (8): tegra: fdt: add back missing host1x node tegra20: fdt: add SPI SFLASH node tegra: spi: add fdt support to tegra SPI SFLASH driver tegra30: add SBC1 to periph id mapping table tegra30: fdt: add SPI SLINK nodes tegra: add addresses of SPI SLINK controllers tegra: add SPI SLINK driver tegra: cardhu: config: enable SPI Lucas Stach (1): arm: fix CONFIG_DELAY_ENVIRONMENT to act like it claims in the README Stephen Warren (2): tegra: rename FUNCMUX_UART2_UARTB tegra: don't hard-code LCD into default TEGRA_DEVICE_SETTINGS Tom Warren (9): Tegra: T20: Remove unused 'SLOW' SoC ID and PLLX table entry Tegra: Move common clock code to arch/arm/cpu/tegra-common/clock.c Tegra114: Add arch-tegra114 include files Tegra114: Add AVP (arm720t) files Tegra114: Add CPU (armv7) files Tegra114: Add common CPU (shared) files Tegra114: Dalmore: Add DT files Tegra114: Add generic Tegra114 build support Tegra114: Add/enable Dalmore build (T114 reference board) arch/arm/cpu/arm720t/tegra-common/cpu.c | 78 ++-- arch/arm/cpu/arm720t/tegra-common/cpu.h |8 +- arch/arm/cpu/arm720t/tegra114/Makefile| 42 ++ arch/arm/cpu/arm720t/tegra114/config.mk | 19 + arch/arm/cpu/arm720t/tegra114/cpu.c | 297 + arch/arm/cpu/armv7/tegra114/Makefile | 40 ++ arch/arm/cpu/armv7/tegra114/config.mk | 19 + arch/arm/cpu/tegra-common/Makefile|2 +- arch/arm/cpu/tegra-common/ap.c|9 +- arch/arm/cpu/tegra-common/board.c | 25 +- arch/arm/cpu/tegra-common/clock.c | 560 arch/arm/cpu/tegra114-common/Makefile | 41 ++ arch/arm/cpu/tegra114-common/clock.c | 655 +++ arch/arm/cpu/tegra114-common/funcmux.c| 63 ++ arch/arm/cpu/tegra114-common/pinmux.c | 506 +++ arch/arm/cpu/tegra20-common/clock.c | 605 +- arch/arm/cpu/tegra20-common/funcmux.c |2 +- arch/arm/cpu/tegra30-common/clock.c | 712 - arch/arm/dts/tegra114.dtsi|5 + arch/arm/dts/tegra20.dtsi | 12 + arch/arm/dts/tegra30.dtsi | 72 ++ arch/arm/include/asm/arch-tegra/clk_rst.h | 58 ++- arch/arm/include/asm/arch-tegra/clock.h | 59 ++- arch/arm/include/asm/arch-tegra/gp_padctrl.h |1 + arch/arm/include/asm/arch-tegra/pmc.h |8 + arch/arm/include/asm/arch-tegra/tegra.h |9 +- arch/arm/include/asm/arch-tegra/tegra_slink.h | 84 +++ arch/arm/include/asm/arch-tegra114/clock-tables.h | 402 arch/arm/include/asm/arch-tegra114/clock.h| 28 + arch/arm/include/asm/arch-tegra114/flow.h | 35 + arch/arm/include/asm/arch-tegra114/funcmux.h | 31 + arch/arm/include/asm/arch-tegra114/gp_padctrl.h | 59 ++ arch/arm/include/asm/arch-tegra114/gpio.h | 30 + arch/arm/include/asm/arch-tegra114/hardware.h | 22 + arch/arm/include/asm/arch-tegra114/pinmux.h | 618 ++ arch/arm/include/asm/arch-tegra114/pmu.h | 23 + arch/arm/include/asm/arch-tegra114/spl.h | 22 + arch/arm/include/asm/arch-tegra114/tegra.h| 33 + arch/arm/include/asm/arch-tegra20/clock-tables.h |4 + arch/arm/include/asm/arch-tegra20/clock.h |4 + arch/arm/include/asm/arch-tegra20/funcmux.h |2 +- arch/arm/include/asm/arch-tegra20/tegra.h |2 + arch/arm/include/asm/arch-tegra30/clock.h |4 + arch/arm/include/asm/arch-tegra30/tegra.h |2 + arch/arm/lib/board.c
Re: [U-Boot] [PATCH v2] build: imx: Fix 'u-boot.imx' build without full OBJTREE reference
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
Hello Tom, The following changes since commit 3a9d879f6f64585b819af728b53be0a05037fe0d: Prepare v2013.01 (2013-01-15 14:47:42 -0700) are available in the git repository at: git://git.denx.de/u-boot-arm master for you to fetch changes up to fd8e1c3866578d87ed14a04a59faae341fd415df: arm: fix CONFIG_DELAY_ENVIRONMENT to act like it claims in the README (2013-02-11 10:35:26 -0700) Albert ARIBAUD (1): Merge branch 'u-boot-imx/master' into 'u-boot-arm/master' Allen Martin (13): tegra: remove IRDA pinmux synonym tegra: fdt: remove clocks nodes tegra: fdt: sort dts files tegra: fdt: add apbdma node fdt: fix dts preprocessor options tegra: fdt: add back missing host1x node tegra20: fdt: add SPI SFLASH node tegra: spi: add fdt support to tegra SPI SFLASH driver tegra30: add SBC1 to periph id mapping table tegra30: fdt: add SPI SLINK nodes tegra: add addresses of SPI SLINK controllers tegra: add SPI SLINK driver tegra: cardhu: config: enable SPI Fabio Estevam (4): woodburn: Set Write Protection GPIO as input mx6qsabre_common: Let mmc partition be board specific tools: imximage: Let .name field be more generic mxs: Use __weak annotation to simplify code Javier Martinez Canillas (4): OMAP3: use a single board file for IGEP devices OMAP3: igep00x0: add boot status GPIO LED omap4: allow the use of a plain text env file instead boot scripts OMAP3: igep00x0: fix a build warning on IGEP boards Jeff Lance (1): Add DDR3 support for AM335x-EVM (Version 1.5A) Knut Wohlrab (1): mx6qsabreauto: enable USB host interface Lars Poeschel (3): am33xx: add a pulldown macro to pinmux config pcm051: Add support for Phytec phyCORE-AM335x am335x: display msg when reading MAC from efuse Lucas Stach (1): arm: fix CONFIG_DELAY_ENVIRONMENT to act like it claims in the README Marc Dietrich (3): tegra: display: add board pinmux tegra: enable LCD on PAZ00 tegra: remove custom TEGRA_DEVICE_SETTINGS for board files Marek Vasut (14): mxs: mmc: Drop unused members from struct mxsmmc_priv mxs: ssp: Pull out the SSP bus to regs conversion mx23: Add POWER and CLKCTRL register definitions mx23: ssp: Fix ssp-regs.h for MX23 mmc: Limit the number of used SSP ports on MX23 mxs: Add function to ungate the power block on MX23 mxs: Linux uses ttyAMA0 as DUART mxs: Add MX23 olinuxino board support mxs: Boost the memory power supply mxs: dma: Fix APBH DMA driver for MX23 mxs: ssp: Add SSP registers map for MX23 mxs: mmc: Allow overriding default card detect implementation mxs: mmc: Fix the MMC driver for MX23 mxs: mmc: mx23_olinuxino: Add MMC support Otavio Salvador (14): mxs: clock: Use 'mxs' prefix for methods mx23: Add register base addresses mx23: Add iomux-mx23.h mx23: Add support on print_cpuinfo() mx23: Add boot mode description mx23: SPL: Add boot mode support mx23: SPL: Initialize DDR at 133MHz mx23: config: Enable building of u-boot.sb binary mx23: config: Enable mxsboot tool for i.MX23 based boards mxs: Fix the memory init for MX23 mxs: Add MX23 quirks into the clock code mxs: mmc: Fix MMC reset on iMX23 mx23_olinuxino: Add default environment mx23evk: Add initial board support Rob Herring (2): ARM: add wfi assembly macro ARM: highbank: use wfi macro instead of inline asm Stephen Warren (2): tegra: rename FUNCMUX_UART2_UARTB tegra: don't hard-code LCD into default TEGRA_DEVICE_SETTINGS Tetsuyuki Kobayashi (2): arm: rmobile: kzm9g: Adjust SDRAM setting arm: rmobile: kzm9g: Adjust ETM trace clock Thierry Reding (3): video: tegra: Update line length to match resolution tegra: Enable LCD on Medcom-Wide tegra: Enable LCD on TEC Tom Rini (1): am33xx: Drop gpio0_7_pin_mux from phytec pcm051 Tom Warren (19): Tegra30: Add arch-tegra30 include files Tegra30: Add AVP (arm720t) files Tegra30: Add CPU (armv7) files Tegra30: Add common CPU (shared) files Tegra30: Cardhu: Add DT files Tegra30: Add generic Tegra30 build support Tegra30: Add/enable Cardhu build (T30 reference board) Tegra30: clocks: Fix clock tables for I2C and other periphs Tegra30: fdt: Update DT files with I2C info for T30/Cardhu Tegra30: I2C: Enable I2C driver on Cardhu Tegra: T20: Remove unused 'SLOW' SoC ID and PLLX table entry Tegra: Move common clock code to arch/arm/cpu/tegra-common/clock.c Tegra114: Add arch-tegra114 include files Tegra114: Add AVP (arm720t) files Tegra114: Add CPU (armv7) files Tegra114: Add common CPU (shared) files Tegra114: Dalmore: Add DT files Tegra114: Add
Re: [U-Boot] [PATCH v5 8/8] nand: mxc: Switch NAND SPL to generic SPL
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
-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
On Tue, Feb 12, 2013 at 6:38 AM, Stefano Babic sba...@denx.de wrote: Simple howto to add support to a board for booting the kernel from SPL (Falcon mode). Signed-off-by: Stefano Babic sba...@denx.de --- Changes in v5: - several fixes for the language, rephrasing some unclear parts (Vikram Narayanan) Changes in v4: - fix capitalization, styling, in spl help (Andreas Biessmann) - move CONFIG_SPL_OS_BOOT before function in doc (Andreas Biessmann) Changes in v3: - parameter initrd_addr was removed in V2 (Andreas Biessmann) - added patch to fix help usage for spl export (Andreas Biessmann) - Added empty lines (Otavio Salvador) - add a more exhaustive description explaining that spl export does not save into media (Lukasz Majewski). Changes in v2: - spelling, language fixes (Andreas Biessman) - rewrite some unclear sentences - drop CONFIG_SPL_OS_BOOT_KEY - make example with twister more exhaustive doc/README.falcon | 169 + 1 file changed, 169 insertions(+) create mode 100644 doc/README.falcon diff --git a/doc/README.falcon b/doc/README.falcon new file mode 100644 index 000..72fe04a --- /dev/null +++ b/doc/README.falcon @@ -0,0 +1,169 @@ +U-Boot Falcon Mode + + +Introduction + + +This document provides an overview of how to add support for Falcon Mode +to a board. +Falcon Mode is introduced to speed up the booting process, allowing +to boot a Linux kernel (or whatever image) without a full blown U-Boot. Add a newline after board or move Falcon Mode to same phrase. +Falcon Mode relies on the SPL framework. In fact, to make booting faster, +U-Boot is split into two parts: the SPL (Secondary Program Loader) and U-Boot +image. In most implementations, SPL is used to start U-Boot when booting from +a mass storage, such as NAND or SD-Card. SPL has now support for other media, +and can generally be seen as a way to start an image performing the minimum +required initialization. SPL mainly initializes the RAM controller, and then +copies U-Boot image into the memory. New line. The Falcon Mode extends this way +allowing to start the Linux kernel directly from SPL. A new command is added +to U-Boot to prepare the parameters that SPL must pass to the kernel, using +ATAGS or Device Tree. + +In usual U-Boot systems, these parameters are generated each time before In usual U-Boot systems Together with previous phrase and might be clear as: In normal mode, these ... +loading the kernel, passing to Linux the address in memory where +the parameters can be read. +With Falcon Mode, this snapshot can be saved into persistent storage and SPL is +informed to load it before running the kernel. + +To boot the kernel, these steps under a Falcon-aware U-Boot are required: + +1. Boot the board into U-Boot. +Use the spl export command to generate the kernel parameters area or the DT. +U-Boot runs as when it boots the kernel, but stops before passing the control +to the kernel. + +2. Save the prepared snapshot into persistent media. +The address where to save it must be configured into board configuration +file (CONFIG_CMD_SPL_NAND_OFS for NAND). + +3. Boot the board into Falcon Mode. SPL will load the kernel and copy +the parameters which are saved in the persistent area area to the required address. + +It is required to implement a custom mechanism to select if SPL loads U-Boot +or another image. + +The value of a GPIO is a simple way to operate the selection, as well as +reading a character from the SPL console if CONFIG_SPL_CONSOLE is set. + +Falcon Mode is generally activated by setting CONFIG_SPL_OS_BOOT. This tells +SPL that U-Boot is not the only available image that SPL is able to start. + +Configuration + +CONFIG_CMD_SPL Enable the spl export command. + The command spl export is then available in U-Boot + mode +CONFIG_SYS_SPL_ARGS_ADDR Address in RAM where the parameters must be + copied by SPL. + In most cases, it is start_of_ram + 0x100 + +CONFIG_SYS_NAND_SPL_KERNEL_OFFSOffset in NAND where the kernel is stored + +CONFIG_CMD_SPL_NAND_OFSOffset in NAND where the parameters area was saved. + +CONFIG_CMD_SPL_WRITE_SIZE Size of the parameters area to be copied + +CONFIG_SPL_OS_BOOT Activate Falcon Mode. + +Function that a board must implement + + +void spl_board_prepare_for_linux(void) : optional + Called from SPL before starting the kernel + +spl_start_uboot() : required + Returns 0 if SPL starts the kernel, 1 if U-Boot + must be started. + + +Using spl command +- + +spl - SPL configuration + +Usage: + +spl export img=atags|fdt [kernel_addr]
Re: [U-Boot] [PATCH] Allow OMAP2 boards to setup GPMC chipselects.
On Mon, Feb 11, 2013 at 04:29:03PM +, Mark Jackson wrote: Expose the enable_gpmc_cs_config() function so OMAP2 boards can register GPMC chipselects. Signed-off-by: Mark Jackson m...@newflow.co.uk --- arch/arm/include/asm/arch-am33xx/sys_proto.h |2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/include/asm/arch-am33xx/sys_proto.h b/arch/arm/include/asm/arch-am33xx/sys_proto.h index 588d8de..97ab60d 100644 --- a/arch/arm/include/asm/arch-am33xx/sys_proto.h +++ b/arch/arm/include/asm/arch-am33xx/sys_proto.h @@ -35,5 +35,7 @@ void ddr_pll_config(unsigned int ddrpll_M); void sdelay(unsigned long); void gpmc_init(void); +void enable_gpmc_cs_config(const u32 *gpmc_config, struct gpmc_cs *cs, u32 base, + u32 size); void omap_nand_switch_ecc(int); #endif Can you please correct the description? You're exposing the function for am33xx not omap2. Otherwise fine with me, and I assume you need this on a custom board (aside: the function already exists/is used in arch/arm/cpu/armv7/am33xx/mem.c). Are you planning to submit that support as well? Thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-boot]-gdwarf option
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
On Tue, Feb 12, 2013 at 12:01 PM, Benoît Thébaudeau benoit.thebaud...@advansee.com wrote: Dear Otavio, Marek, On Monday, February 11, 2013 5:55:17 PM, Marek Vasut wrote: Dear Otavio Salvador, When calling 'make u-boot.imx' the build were failing as it were expecting the full path for the file; this regression has been included by commit 71a988a (imximage.cfg: run files through C preprocessor). The direct references for u-boot.imx were replaced by $(obj) as config.mk handles the proper setting of it making it set to $(OBJTREE) when required. The build has been test using: - ./MAKEALL -s mx5 -s mx6 - make u-boot.imx - make O=/tmp/build BUILD_DIR=/tmp/xyz MAKEALL please. Once you're confident with this patch, do you mind if I integrate it as is in my MXC NAND + SPL series in order to avoid merge conflicts (unless it is applied before)? Alright; It did the test Marek has requested and it works fine. I think this should go to imx/master as it fixes a regression. -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 2/3] am335x-evm: add support for BeagleBone Black DT name
Signed-off-by: Koen Kooi k...@dominion.thruhere.net --- include/configs/am335x_evm.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h index 2190a7d..951422c 100644 --- a/include/configs/am335x_evm.h +++ b/include/configs/am335x_evm.h @@ -86,6 +86,8 @@ findfdt=\ if test $board_name = A335BONE; then \ setenv fdtfile am335x-bone.dtb; fi; \ + if test $board_name = A335BNLT; then \ + setenv fdtfile am335x-bonelt.dtb; fi; \ if test $board_name = A33515BB; then \ setenv fdtfile am335x-evm.dtb; fi; \ if test $board_name = A335X_SK; then \ -- 1.8.1.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/3] am335x-evm: enable ext4
The kernel is loaded from an ext4 partition, not ext2 on beaglebone boards. Signed-off-by: Koen Kooi k...@dominion.thruhere.net --- include/configs/am335x_evm.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h index 72459d8..2190a7d 100644 --- a/include/configs/am335x_evm.h +++ b/include/configs/am335x_evm.h @@ -144,6 +144,7 @@ #define CONFIG_DOS_PARTITION #define CONFIG_CMD_FAT #define CONFIG_CMD_EXT2 +#define CONFIG_CMD_EXT4 #define CONFIG_SPI #define CONFIG_OMAP3_SPI -- 1.8.1.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC] [PATCH] Avoid R_ARM_ABS32 for bss start and end references
This patch is intended to be patch 2/2 of my first patch to remove
R_ARM_ABS32 relocation types from ARM builds.
With this change, the type of ARM references to __bss_start
and __bss_end__ is changed from R_ARM_ABS32 to R_ARM_RELATIVE.
It should have no functional impact, as it only affects the
resolution of references to __bss_start and __bss_end__ before
relocation, and no code should ever perform such references...
so far. References performed after relocation are unchanged by
this patch.
This patch SHOULD NOT BE applied in any official U-boot tree! It is
submitted as an RFC and a request to test.
This patch can only work on ARM; it will not work on any ARM target
that uses another linker script than arch/arm/cpu/u-boot.lds, and it
will not work on any non-ARM target.
HOWEVER, if you can test it on one of these targets, then please do
so by manually patching the appropriate linker script the same way
arch/arm/cpu/u-boot.lds is patched here.
If you are keen on testing but don't know how to patch your linker
script, just let me know which target you intend to test on, and which
linker script you need patched, and I'll do a v2 / v3... of this RFC.
The goal here is to help me ensure the patch works well on enough
targets that I can safely start the tedious work of patching all 150+
linker scripts.
---
arch/arm/cpu/u-boot.lds | 12 +---
lib/Makefile|1 +
lib/bss.c | 35 +++
3 files changed, 45 insertions(+), 3 deletions(-)
create mode 100644 lib/bss.c
diff --git a/arch/arm/cpu/u-boot.lds b/arch/arm/cpu/u-boot.lds
index e6b202b..e1bc8e7 100644
--- a/arch/arm/cpu/u-boot.lds
+++ b/arch/arm/cpu/u-boot.lds
@@ -81,11 +81,17 @@ SECTIONS
*(.mmutable)
}
- .bss __rel_dyn_start (OVERLAY) : {
- __bss_start = .;
+ .bss_start __rel_dyn_start (OVERLAY) : {
+ KEEP(*(.__bss_start));
+ }
+
+ .bss __bss_start (OVERLAY) : {
*(.bss*)
. = ALIGN(4);
- __bss_end__ = .;
+___bssend___ = .;
+ }
+ .bss_end ___bssend___ (OVERLAY) : {
+ KEEP(*(.__bss_end__));
}
/DISCARD/ : { *(.dynstr*) }
diff --git a/lib/Makefile b/lib/Makefile
index 86ca1a6..73ee160 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -25,6 +25,7 @@ include $(TOPDIR)/config.mk
LIB= $(obj)libgeneric.o
+COBJS-y += bss.o
ifndef CONFIG_SPL_BUILD
COBJS-$(CONFIG_ADDR_MAP) += addr_map.o
COBJS-$(CONFIG_BCH) += bch.o
diff --git a/lib/bss.c b/lib/bss.c
new file mode 100644
index 000..5678f30
--- /dev/null
+++ b/lib/bss.c
@@ -0,0 +1,35 @@
+/*
+ * Copyright 2013 Albert ARIBAUD albert.u.b...@aribaud.net
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+/**
+ * These two symbols are declared in a C file so that the linker
+ * uses R_ARM_RELATIVE relocation, rather than the R_ARM_ABS32 one
+ * it would use if the symbols were defined in the linker file.
+ * Using only R_ARM_RELATIVE relocation ensures that references to
+ * the symbols are correct after as well as before relocation.
+ *
+ * As the symbols do not require any content, and as we cannot define
+ * them as 'void', we go for the next best thing, 'struct {}'.
+ */
+
+struct {} __bss_start __attribute__((used,section(.__bss_start)));
+struct {} __bss_end__ __attribute__((used,section(.__bss_end__)));
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] Tegra: fdt: Add/enhance sdhci (mmc) nodes for all T20 DT files
Thierry, On Tue, Feb 12, 2013 at 3:53 AM, Thierry Reding thierry.red...@avionic-design.de wrote: On Tue, Feb 12, 2013 at 11:41:09AM +0100, Thierry Reding wrote: On Tue, Feb 12, 2013 at 07:51:55AM +0100, Thierry Reding wrote: On Mon, Feb 11, 2013 at 12:21:59PM -0700, Tom Warren wrote: Thierry/Lucas, On Mon, Feb 11, 2013 at 12:11 PM, Thierry Reding thierry.red...@avionic-design.de wrote: On Mon, Feb 11, 2013 at 10:56:33AM -0700, Tom Warren wrote: Lucas, On Mon, Feb 11, 2013 at 10:28 AM, Lucas Stach d...@lynxeye.de wrote: Hi Tom, Am Montag, den 11.02.2013, 10:17 -0700 schrieb Tom Warren: Linux dts files were used for those boards that didn't already have sdhci info populated. Tamonten has their own dtsi file with common sdhci nodes (sourced from Linux). Signed-off-by: Tom Warren twar...@nvidia.com --- v2: - cleanup comments in dts files/match w/kernel files - add sdhci aliases in all dts files - use tegra20-tamonten.dtsi from the kernel for AD boards arch/arm/dts/tegra20-tamonten.dtsi | 489 ++ I'm not sure if pushing the whole file in this patch is the right thing to do. I didn't want to edit it since we seem to be moving towards using the Linux DTS files in toto in U-Boot (as per Stephen Simon). Does it do any harm to have the whole thing here? Saves some work later. Thierry - what do you think? Given that it isn't used anywhere I don't think we really need it right now. We can always add it later when we can make better use of it. It actually is used (for SDMMC/sdhci) now, Thierry. That's why it's in this patchset. Right, I hadn't looked at that patch yet. I had originally put the sdhci node for Avionic Design boards in their respective .dts files, but Stephen pointed out that the kernel had a tegra20-tamonten.dtsi file with common info, which included the sdhci node, and asked that I use it, instead, so we echo the kernel layout. So I pulled that file into my MMC DT patchset, and used it in all AD board builds (medcom/tec/plutux) - it's pulled in via an override of CONFIG_ARCH_DEVICE_TREE in the config files. So the options seem to be: a) Don't use the tamonton dtsi file, and put the sdhci nodes in the AD dts files, just like all other boards (this was my V1 approach). Vetoed by Stephen. b) Use tegra20-tamonten.dtsi as is, identical to the kernel file. If necessary, I can move it's inclusion to a separate patch, independent of the MMC DT patchset, as suggested by Lucas. c) Use tegra20-tamonten.dtsi, but just with the sdhci node (is this what you're suggesting, Thierry?). I'd still pull it in via a CONFIG_ARCH_DEVICE_TREE #define in the AD config files. Let me know ASAP - I'd like to get V3 upstreamed soon so I can move on to work on the T30/T114 MMC patches. I think option b) sounds fine given that we want to move to the same DTS as the kernel eventually anyway. So for the Tamonten (and AD board) pieces, consider this: Acked-by: Thierry Reding thierry.red...@avionic-design.de I can't give you a Tested-by because I have a bunch of other things to take care of and I probably won't get to testing this for a few days. So it turned out that I need to touch U-Boot anyway, so I decided to give this a spin. I noticed that overriding CONFIG_ARCH_DEVICE_TREE from the board configuration file doesn't work currently. What happens is that the autoconf.mk (which is derived from the board configuration) is included before the CPU config.mk which sets CONFIG_ARCH_DEVICE_TREE to tegra20 (or tegra30, tegra114). I came up with the attached patch to set the variable if not set previously (by the board configuration file). Feel free to squash that in your patch series if you deem it a proper solution. I can also provide a proper separate patch if you prefer. Thierry diff --git a/arch/arm/cpu/armv7/tegra114/config.mk b/arch/arm/cpu/armv7/tegra114/config.mk index cb1a19d..e7c22c0 100644 --- a/arch/arm/cpu/armv7/tegra114/config.mk +++ b/arch/arm/cpu/armv7/tegra114/config.mk @@ -16,4 +16,4 @@ # You should have received a copy of the GNU General Public License # along with this program. If not, see http://www.gnu.org/licenses/. # -CONFIG_ARCH_DEVICE_TREE := tegra114 +CONFIG_ARCH_DEVICE_TREE ?= tegra114 diff --git a/arch/arm/cpu/armv7/tegra20/config.mk b/arch/arm/cpu/armv7/tegra20/config.mk index 6432e75..9042664 100644 --- a/arch/arm/cpu/armv7/tegra20/config.mk +++ b/arch/arm/cpu/armv7/tegra20/config.mk @@ -23,4 +23,4 @@ # Foundation, Inc., 59 Temple Place, Suite 330, Boston, # MA 02111-1307 USA # -CONFIG_ARCH_DEVICE_TREE := tegra20 +CONFIG_ARCH_DEVICE_TREE ?= tegra20 diff --git a/arch/arm/cpu/armv7/tegra30/config.mk b/arch/arm/cpu/armv7/tegra30/config.mk index 719ca81..0035bc5
Re: [U-Boot] [PATCH v3 2/3] Tegra114: fdt: Update DT files with I2C info for T114/Dalmore
Laxman,
On Tue, Feb 12, 2013 at 5:02 AM, Laxman Dewangan ldewan...@nvidia.com wrote:
On Friday 08 February 2013 11:34 PM, Stephen Warren wrote:
On 02/08/2013 10:25 AM, Tom Warren wrote:
T114, like T30, does not have a separate/different DVC (power I2C)
controller like T20 - all 5 I2C controllers are identical, but
I2C5 is used to designate the controller intended for power
control (PWR_I2C in the schematics). PWR_I2C is set to 400KHz.
diff --git a/board/nvidia/dts/tegra114-dalmore.dts
b/board/nvidia/dts/tegra114-dalmore.dts
+ aliases {
+ };
+
There's no point adding an empty aliases node here. Feel free to fix
that up when you apply it rather than reposting if you want.
I'd like too see Laxman sign-off on the *2 question he had earlier
before actually checking this in.
We do not require *2 as the i2c clock divider is DIVU16 type. There was bug
in early code on kernel also which we fixed in dowstream long back. Possibly
uboot have not fixed this yet.
Yeah, the Tegra I2C driver in U-Boot has always doubled the rate
before calling the clock set routine. But the important thing is that
the actual I2C clock is 100KHz (or 400KHz for I2C5) as measured at the
test points on the board.
I'll look into the Tegra U-Boot clock routine idiosyncrasies later
when I get some more bandwidth.
Thanks,
Tom
---
This email message is for the sole use of the intended recipient(s) and may
contain
confidential information. Any unauthorized review, use, disclosure or
distribution
is prohibited. If you are not the intended recipient, please contact the
sender by
reply email and destroy all copies of the original message.
---
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 3/3] am335x-evm: switch to DT boot
The findfdt method is being used to locate the right .dtb for the board and
load it from /boot.
Signed-off-by: Koen Kooi k...@dominion.thruhere.net
---
include/configs/am335x_evm.h | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h
index 951422c..67f04c4 100644
--- a/include/configs/am335x_evm.h
+++ b/include/configs/am335x_evm.h
@@ -79,7 +79,7 @@
loaduimage=ext2load mmc ${mmcdev}:2 ${loadaddr} ${bootfile}\0 \
mmcboot=echo Booting from mmc ...; \
run mmcargs; \
- bootm ${loadaddr}\0 \
+ bootm ${loadaddr} - ${fdtaddr}\0 \
ramboot=echo Booting from ramdisk ...; \
run ramargs; \
bootm ${loadaddr}\0 \
@@ -93,7 +93,9 @@
if test $board_name = A335X_SK; then \
setenv fdtfile am335x-evmsk.dtb; fi\0 \
+
#define CONFIG_BOOTCOMMAND \
+ run findfdt; \
mmc dev ${mmcdev}; if mmc rescan; then \
echo SD/MMC found on device ${mmcdev}; \
if run loadbootenv; then \
@@ -105,6 +107,7 @@
run uenvcmd; \
fi; \
if run loaduimage; then \
+ ext2load mmc ${mmcdev}:2 ${fdtaddr} /boot/${fdtfile};
\
run mmcboot; \
fi; \
fi; \
--
1.8.1.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] build: imx: Fix 'u-boot.imx' build without full OBJTREE reference
Hi Otavio, On Tuesday, February 12, 2013 6:09:43 PM, Otavio Salvador wrote: On Tue, Feb 12, 2013 at 12:01 PM, Benoît Thébaudeau benoit.thebaud...@advansee.com wrote: Dear Otavio, Marek, On Monday, February 11, 2013 5:55:17 PM, Marek Vasut wrote: Dear Otavio Salvador, When calling 'make u-boot.imx' the build were failing as it were expecting the full path for the file; this regression has been included by commit 71a988a (imximage.cfg: run files through C preprocessor). The direct references for u-boot.imx were replaced by $(obj) as config.mk handles the proper setting of it making it set to $(OBJTREE) when required. The build has been test using: - ./MAKEALL -s mx5 -s mx6 - make u-boot.imx - make O=/tmp/build BUILD_DIR=/tmp/xyz MAKEALL please. Once you're confident with this patch, do you mind if I integrate it as is in my MXC NAND + SPL series in order to avoid merge conflicts (unless it is applied before)? Alright; It did the test Marek has requested and it works fine. I think this should go to imx/master as it fixes a regression. OK. I include it into my series so that patches apply fine whether Stefano applies it alone first or from my series. Best regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] i.MX6Q: mx6qsabre*: Configure to allow CONFIG_SYS_ALT_MEMTEST
On 01/02/2013 19:08, Eric Nelson wrote: In order to use the more thorough memory test, the macro CONFIG_SYS_MEMTEST_SCRATCH must be defined with a usable address. Signed-off-by: Eric Nelson eric.nel...@boundarydevices.com --- Applied to u-boot-imx, thanks. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] mx23evk: Turn on caches
On 28/01/2013 12:41, Fabio Estevam wrote: It is safe to turn on data and instruction caches for mx23. Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- Applied to u-boot-imx, thanks. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] mx23evk: Remove CONFIG_SYS_BAUDRATE_TABLE
On 28/01/2013 12:41, Fabio Estevam wrote: The baudrate is already defined by CONFIG_BAUDRATE and there is no need to keep CONFIG_SYS_BAUDRATE_TABLE. Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- Applied to u-boot-imx, thanks. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] build: imx: Fix 'u-boot.imx' build without full OBJTREE reference
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
Hi Stephen,
On Tue, Feb 5, 2013 at 12:03 PM, Stephen Warren swar...@wwwdotorg.org wrote:
On 02/04/2013 04:48 PM, Tom Warren wrote:
tegra_mmc_init() now uses DT info for bus width, WP/CD GPIOs, etc.
Tested on Seaboard, fully functional.
diff --git a/board/compal/paz00/paz00.c b/board/compal/paz00/paz00.c
index 1447f47..5cee91a 100644
--- a/board/compal/paz00/paz00.c
+++ b/board/compal/paz00/paz00.c
@@ -55,18 +55,18 @@ static void pin_mux_mmc(void)
/* this is a weak define that we are overriding */
int board_mmc_init(bd_t *bd)
{
- debug(board_mmc_init called\n);
+ debug(%s called\n, __func__);
/* Enable muxes, etc. for SDMMC controllers */
pin_mux_mmc();
- debug(board_mmc_init: init eMMC\n);
- /* init dev 0, eMMC chip, with 8-bit bus */
- tegra_mmc_init(0, 8, -1, -1);
+ debug(%s: init eMMC\n, __func__);
+ /* init dev 0, eMMC chip */
+ tegra_mmc_init(0);
- debug(board_mmc_init: init SD slot\n);
- /* init dev 3, SD slot, with 4-bit bus */
- tegra_mmc_init(3, 4, GPIO_PV1, GPIO_PV5);
+ debug(%s: init SD slot\n, __func__);
+ /* init dev 3, SD slot */
+ tegra_mmc_init(3);
return 0;
}
That doesn't look right. The board code still has knowledge of which
SDHCI controllers are in use by the board. Instead, the board should
just call tegra_mmc_init() with no parameters at all, and the MMC driver
should scan the device tree for all present-and-enabled SDHCI nodes, and
instantiate a U-Boot SDHCI device. Without this, the device tree isn't
in control of the whole process, so there's little point doing the
conversion; a new board couldn't be supported /just/ by creating a new
device tree file.
Agreed.
diff --git a/drivers/mmc/tegra_mmc.c b/drivers/mmc/tegra_mmc.c
+#ifndef CONFIG_OF_CONTROL
+#error Please enable device tree support to use this driver
+#endif
So CONFIG_OF_CONTROL must be enabled ...
static void tegra_get_setup(struct mmc_host *host, int dev_index)
{
- debug(tegra_get_setup: dev_index = %d\n, dev_index);
+ debug(%s: dev_index = %d\n, __func__, dev_index);
+
+#ifdef CONFIG_OF_CONTROL
... so there's no need for that ifdef
+ int count, node = 0;
+ int node_list[MAX_HOSTS];
+
+ count = fdtdec_find_aliases_for_id(gd-fdt_blob, sdmmc,
+ COMPAT_NVIDIA_TEGRA20_SDMMC, node_list, MAX_HOSTS);
+ debug(%s: count of nodes is %d\n, __func__, count);
+
+ if (count dev_index) {
+ printf(%s: device index %d exceeds node count (%d)!\n,
+ __func__, dev_index, count);
+ return;
+ }
This requires that an alias exist in order for the SDHCI node to be
found/processed. This isn't correct; the SDHCI nodes must be enumerated
themselves, and then the aliases (if any are present) provide a naming
hint for them, but even without aliases, the SDHCI nodes must be processed.
I believe this is quite incorrect. Please take a look at the function,
which deals with aliases if they are present, but works in any case.
There is a test in fdtdec_test.c which handles the cases that we
discussed at the time. Quite a bit of effort went into this function
at the time.
So I believe this function should always be used when enumerating
multiple devices. If there is a bug in the function, let's find out
what it is and fix it, and add a new test.
+ /*
+ * NOTE: mmc-bus_width is determined by mmc.c dynamically.
+ * Should we override it with this value?
+ */
+ host-width = fdtdec_get_int(gd-fdt_blob, node, bus-width, 0);
+ if (!host-width)
+ debug(%s: no sdmmc width found\n, __func__);
It should be possible to inform the MMC core of the width of the bus in
terms of wires on the PCB. It should only probe the connected device up
to that width. If that feature is missing, it can be added later though,
outside the scope of this patch set.
You didn't Cc the MMC maintainer; they should be Cc'd since this code is
in drivers/mmc/.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] Tegra: MMC: Add DT support to MMC driver for all T20 boards
Hi,
On Tue, Feb 5, 2013 at 1:02 PM, Tom Warren twarren.nvi...@gmail.com wrote:
Stephen,
On Tue, Feb 5, 2013 at 1:03 PM, Stephen Warren swar...@wwwdotorg.org wrote:
On 02/04/2013 04:48 PM, Tom Warren wrote:
tegra_mmc_init() now uses DT info for bus width, WP/CD GPIOs, etc.
Tested on Seaboard, fully functional.
diff --git a/board/compal/paz00/paz00.c b/board/compal/paz00/paz00.c
index 1447f47..5cee91a 100644
--- a/board/compal/paz00/paz00.c
+++ b/board/compal/paz00/paz00.c
@@ -55,18 +55,18 @@ static void pin_mux_mmc(void)
/* this is a weak define that we are overriding */
int board_mmc_init(bd_t *bd)
{
- debug(board_mmc_init called\n);
+ debug(%s called\n, __func__);
/* Enable muxes, etc. for SDMMC controllers */
pin_mux_mmc();
- debug(board_mmc_init: init eMMC\n);
- /* init dev 0, eMMC chip, with 8-bit bus */
- tegra_mmc_init(0, 8, -1, -1);
+ debug(%s: init eMMC\n, __func__);
+ /* init dev 0, eMMC chip */
+ tegra_mmc_init(0);
- debug(board_mmc_init: init SD slot\n);
- /* init dev 3, SD slot, with 4-bit bus */
- tegra_mmc_init(3, 4, GPIO_PV1, GPIO_PV5);
+ debug(%s: init SD slot\n, __func__);
+ /* init dev 3, SD slot */
+ tegra_mmc_init(3);
return 0;
}
That doesn't look right. The board code still has knowledge of which
SDHCI controllers are in use by the board. Instead, the board should
just call tegra_mmc_init() with no parameters at all, and the MMC driver
should scan the device tree for all present-and-enabled SDHCI nodes, and
instantiate a U-Boot SDHCI device. Without this, the device tree isn't
in control of the whole process, so there's little point doing the
conversion; a new board couldn't be supported /just/ by creating a new
device tree file.
diff --git a/drivers/mmc/tegra_mmc.c b/drivers/mmc/tegra_mmc.c
+#ifndef CONFIG_OF_CONTROL
+#error Please enable device tree support to use this driver
+#endif
So CONFIG_OF_CONTROL must be enabled ...
static void tegra_get_setup(struct mmc_host *host, int dev_index)
{
- debug(tegra_get_setup: dev_index = %d\n, dev_index);
+ debug(%s: dev_index = %d\n, __func__, dev_index);
+
+#ifdef CONFIG_OF_CONTROL
... so there's no need for that ifdef
I took Allen's recent SPI/SLINK driver(s) as an example, but as you
point out, if CONFIG_OF_CONTROL isn't enabled, you get build errors
anyway.
+ int count, node = 0;
+ int node_list[MAX_HOSTS];
+
+ count = fdtdec_find_aliases_for_id(gd-fdt_blob, sdmmc,
+ COMPAT_NVIDIA_TEGRA20_SDMMC, node_list, MAX_HOSTS);
+ debug(%s: count of nodes is %d\n, __func__, count);
+
+ if (count dev_index) {
+ printf(%s: device index %d exceeds node count (%d)!\n,
+ __func__, dev_index, count);
+ return;
+ }
This requires that an alias exist in order for the SDHCI node to be
found/processed. This isn't correct; the SDHCI nodes must be enumerated
themselves, and then the aliases (if any are present) provide a naming
hint for them, but even without aliases, the SDHCI nodes must be processed.
Again, I used Allen's SLINK driver for as a template here. In fact, it
looks like our I2C and SPI/SLINK drivers do this, as well as the
Exynos SPI and S3C24x0 I2C driver all do this. Can you point out a
U-Boot driver that does it the right way (preferably with more than 1
node, like MMC)? I can take a look at that code to use as an example
of what you're proposing above.
You have it correct already. Stephen please take another look and let
me know what problem you see with this approach. I'm very sorry that I
am so late to this discussion.
+ /*
+ * NOTE: mmc-bus_width is determined by mmc.c dynamically.
+ * Should we override it with this value?
+ */
+ host-width = fdtdec_get_int(gd-fdt_blob, node, bus-width, 0);
+ if (!host-width)
+ debug(%s: no sdmmc width found\n, __func__);
It should be possible to inform the MMC core of the width of the bus in
terms of wires on the PCB. It should only probe the connected device up
to that width. If that feature is missing, it can be added later though,
outside the scope of this patch set.
You didn't Cc the MMC maintainer; they should be Cc'd since this code is
in drivers/mmc/.
Thanks, added Andy Fleming to CC.
Tom
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/5] Add support for using an UBI volume for environment
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
On 02/12/2013 10:40 AM, Tom Warren wrote:
Laxman,
On Tue, Feb 12, 2013 at 5:02 AM, Laxman Dewangan ldewan...@nvidia.com wrote:
On Friday 08 February 2013 11:34 PM, Stephen Warren wrote:
On 02/08/2013 10:25 AM, Tom Warren wrote:
T114, like T30, does not have a separate/different DVC (power I2C)
controller like T20 - all 5 I2C controllers are identical, but
I2C5 is used to designate the controller intended for power
control (PWR_I2C in the schematics). PWR_I2C is set to 400KHz.
diff --git a/board/nvidia/dts/tegra114-dalmore.dts
b/board/nvidia/dts/tegra114-dalmore.dts
+ aliases {
+ };
+
There's no point adding an empty aliases node here. Feel free to fix
that up when you apply it rather than reposting if you want.
I'd like too see Laxman sign-off on the *2 question he had earlier
before actually checking this in.
We do not require *2 as the i2c clock divider is DIVU16 type. There was bug
in early code on kernel also which we fixed in dowstream long back. Possibly
uboot have not fixed this yet.
Yeah, the Tegra I2C driver in U-Boot has always doubled the rate
before calling the clock set routine.
Perhaps it's related to some dividers being U7.1 (i.e. the LSB of the
divider represents 1/2 not 1)? However, as Laxman points out, this isn't
the case for I2C clocks; they have a U16 divider, so the LSB represents
1 not 1/2.
But the important thing is that
the actual I2C clock is 100KHz (or 400KHz for I2C5) as measured at the
test points on the board.
I'll look into the Tegra U-Boot clock routine idiosyncrasies later
when I get some more bandwidth.
Just a few minutes of investigation points at clk_get_divider() being buggy.
It assumes that all dividers have a built-in *2 clock multiplier on the
front of them:
u64 divider = parent_rate * 2;
(the name for that variable is wrong; it should be something more like
parent_rate or divider_input_rate)
This (presence of a *2 pre-multiplier) is true for U7.1 dividers, since
this is required for the LSB of the divider to represent 1/2 not 1.
Hence, I assume that e.g. the SPI driver doesn't do this * 2 on the
clock rate; it actually has a U7.1 divider.
However, this is not true for U16 dividers, since the HW doesn't need to
multiply up the rate before dividing, since the LSB is 1 not 1/2.
The solution here is to fix clk_get_divider() to return both a field
width and a flag (or width) indicating whether a fractional part of the
divider is present, and then pass that on to adjust_periph_pll() so that
it can only optionally perform this initial * 2.
So at least that explains it.
I would strongly recommend just fixing this now. However, if you don't
please do file a bug so that we don't forget about this.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/3] Tegra114: fdt: Update DT files with I2C info for T114/Dalmore
Hi Stephen,
On Thu, Feb 7, 2013 at 10:17 AM, Stephen Warren swar...@wwwdotorg.org wrote:
On 02/07/2013 09:14 AM, Tom Warren wrote:
Stephen,
On Wed, Feb 6, 2013 at 5:00 PM, Stephen Warren swar...@wwwdotorg.org wrote:
On 02/06/2013 04:26 PM, Tom Warren wrote:
Note that T114 does not have a separate/different DVC (power I2C)
controller like T20 - all 5 I2C controllers are identical, but
I2C5 is used to designate the controller intended for power
control (PWR_I2C in the schematics).
diff --git a/arch/arm/dts/tegra114.dtsi b/arch/arm/dts/tegra114.dtsi
+ tegra_car: clock@60006000 {
+ compatible = nvidia,tegra114-car, nvidia,tegra30-car;
Only the Tegra114 value should be listed here; the presence of the
Tegra30 value in the upstream kernel is a mistake that will be fixed as
part of the Tegra114 clock driver patches.
OK. But this is why I think hewing to the Linux DT files, while
laudable, is a time sink. Though since T114 is so new still settling
in, I guess some churn is expected.
The issue here is not about making U-Boot fall in line with the kernel.
The issue is making the device tree in U-Boot be correct. Right now, the
kernel happens to have the most correct device tree, so it's a good
reference for U-Boot.
+ i2c@7000c000 {
+ compatible = nvidia,tegra114-i2c, nvidia,tegra20-i2c;
Same here; only include the Tegra114 value since the HW isn't 100%
compatible with the Tegra20 HW.
What does the 'compatible' designater mean, exactly? Does it require
100% identical HW? Compatible, in a SW/HW sense, to me means that
newer SW will work with older/similar (but not exactly the same) HW,
etc.
The idea here is that the first entry in compatible always defines the
most specific implementation identification possible. So, compatible
will at least contain:
Tegra20: nvidia,tegra20-i2c
Tegra30: nvidia,tegra30-i2c
Tegra114: nvidia,tegra114-i2c
Now, if a piece of newer hardware can be operated 100% correctly
(ignoring issues due to new features not being exposed, or operating at
degraded performance) by a driver that only knows about the older
hardware, then the compatible property can additionally contain other
values indicating what HW it is compatible with. So, we actually end up
with:
Tegra20: nvidia,tegra20-i2c
Tegra30: nvidia,tegra30-i2c nvidia,tegra20-i2c
Tegra114: nvidia,tegra114-i2c
Tegra114 I2C HW isn't marked as compatible with either Tegra20 or
Tegra30, because the clock divider programming must be different.
Tegra U-Boot uses the tegra20-i2c name to find and load the I2C
driver. I could add a new entry in the compat-names table for
tegra114-i2c,
Yes, that is the way to go. The driver should include a list of all the
different compatible values that it supports.
but I still don't think there's enough difference
between T20/T30 and T114 I2C to justify a whole new I2C driver - so
far, it's just one register with a new clk divider that has to be
taken in consideration when programming the clock source divider.
But that's required to operate the hardware correctly. It doesn't matter
how trivial the difference is; it could just be a single bit that needs
to be set/cleared on new HW - there would still be a difference that
would otherwise make the HW operate incorrectly.
I could do as the driver does for T20, where there is a separate DVC
controller, plus 3 normal I2C controllers. I could 'find_aliases' for
the tegrat114-i2c controller first, process its nodes, and return. If
no tegrat114-i2c exists, the driver would continue on to look for
tegra20-i2c/tegra20-dvc controller info as it does now. It'd still be
one tegra_i2c.c driver, with a flag in the i2c_bus struct telling me
if I found T114 I2C HW (i2c_bus-single_clk, etc.) and I could then do
the new clock divider dance based on that flag. How does that sound?
The U-Boot function that returns the list of devices supported by the
driver should be enhanced so that it can search for nodes compatible
with any 1 (or more) of n compatible values at a time, rather than just
a single compatible value. Then, all you'd have to do with this change
is add a new entry into the table, not add extra code that calls that
function separately for each compatible value.
Yes, that needs to be done, and while we are at it I think the
function should return a list containing struct {int offset; enum
fdt_compat_id; };
I could probably do this by end of week if no one else can do it
faster. Please let me know. Tests need to updated also.
diff --git a/board/nvidia/dts/tegra114-dalmore.dts
b/board/nvidia/dts/tegra114-dalmore.dts
+ i2c@7000d000 {
+ status = okay;
+ clock-frequency = 10;
+ };
According to our downstream Linux kernel, that I2C controller can run up
to 400KHz on this board.
But it also runs @ 100KHz just fine, too. Do we need to run at the
fastest clock? That's the DVC (PWR_I2C) controller, which
Re: [U-Boot] [PATCH v3 0/3] Add I2C driver for T114 Dalmore
Hi, On Fri, Feb 8, 2013 at 9:25 AM, Tom Warren twarren.nvi...@gmail.com wrote: Update DT tables and enable I2C driver support for the Tegra114 Dalmore board. This uses the standard Tegra I2C driver. 5 controllers are supported, although all may not have devices behind them on every board. Changes in V2: - use new calculation for T114 I2C clocks - incorporate review comments from StephenW for the dtsi file Changes in V3: - Added tegra114-i2c name to compat_names/compat_id table(s) - Add search for T114 I2C node in i2c_init_board - Added is_scs flag to i2c_bus struct (single clock source HW) - Use is_scs flag to trigger new clock source rate calculation - Moved aliases to dtsi file as per StephenW - Removed tegra30-car tegra20-i2c compatible strings - Changed I2C5 (PWR_I2C) clock to 400MHz Tom Warren (3): Tegra: I2C: Add T114 clock support to tegra_i2c driver Tegra114: fdt: Update DT files with I2C info for T114/Dalmore Tegra114: I2C: Enable I2C driver on Dalmore E1611 eval board arch/arm/dts/tegra114.dtsi | 64 +++ arch/arm/include/asm/arch-tegra/tegra_i2c.h |6 +++ board/nvidia/dts/tegra114-dalmore.dts | 28 drivers/i2c/tegra_i2c.c | 42 +++-- include/configs/dalmore.h |9 include/configs/tegra114-common.h |3 + include/fdtdec.h|1 + lib/fdtdec.c|1 + 8 files changed, 149 insertions(+), 5 deletions(-) Series LGTM except for the comment about the need to enhance the alias function. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] build: imx: Fix 'u-boot.imx' build without full OBJTREE reference
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]
Hi, On Thu, Feb 7, 2013 at 9:16 AM, Lucas Stach d...@lynxeye.de wrote: The ehci_hcd entry points were just calling into the Tegra USB functions. Now that they are in the same file we can just move over the implementation. Signed-off-by: Lucas Stach d...@lynxeye.de Acked-by: Simon Glass s...@chromium.org I didn't review this again as apparently I acked it all last time. Thanks. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 01/23] ppc: Add initial memory barrier macros
Hi Scott, On Mon, Feb 11, 2013 at 11:52 AM, Scott Wood scottw...@freescale.com wrote: On 02/08/2013 09:11:57 AM, Simon Glass wrote: These are available on other architectures, so add them on ppc. Signed-off-by: Simon Glass s...@chromium.org --- Changes in v5: None Changes in v4: None Changes in v3: None Changes in v2: None arch/powerpc/include/asm/io.h | 8 1 file changed, 8 insertions(+) diff --git a/arch/powerpc/include/asm/io.h b/arch/powerpc/include/asm/io.h index 1f12c29..1bf12f5 100644 --- a/arch/powerpc/include/asm/io.h +++ b/arch/powerpc/include/asm/io.h @@ -317,4 +317,12 @@ static inline phys_addr_t virt_to_phys(void * vaddr) #endif } +/* + * TODO: The kernel offers some more advanced versions of barriers, it might + * have some advantages to use them instead of the simple one here. + */ +#define dmb() __asm__ __volatile__ ( : : : memory) +#define __iormb() dmb() +#define __iowmb() dmb() What is the definition of these? Given that we already have an architecture-independent barrier(), I assume this is meant to be an actual hardware barrier rather than a compiler barrier, so this is not a correct implementation. They were introduced in ARM in commit 3c0659b5, so I am really just following along with that. Yes the naming doesn't make a lot of sense, but on the other hand I don't think we necessarily want an actual hardware barrier in our writel()s. This at least makes sure that the compiler writes in the right order - perhaps the intent is that that rest is best left to the hardware? Regards, Simon -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 01/23] ppc: Add initial memory barrier macros
Hi Scott, On Tue, Feb 12, 2013 at 10:50 AM, Scott Wood scottw...@freescale.com wrote: On 02/12/2013 12:44:16 PM, Simon Glass wrote: Hi Scott, On Mon, Feb 11, 2013 at 11:52 AM, Scott Wood scottw...@freescale.com wrote: On 02/08/2013 09:11:57 AM, Simon Glass wrote: These are available on other architectures, so add them on ppc. Signed-off-by: Simon Glass s...@chromium.org --- Changes in v5: None Changes in v4: None Changes in v3: None Changes in v2: None arch/powerpc/include/asm/io.h | 8 1 file changed, 8 insertions(+) diff --git a/arch/powerpc/include/asm/io.h b/arch/powerpc/include/asm/io.h index 1f12c29..1bf12f5 100644 --- a/arch/powerpc/include/asm/io.h +++ b/arch/powerpc/include/asm/io.h @@ -317,4 +317,12 @@ static inline phys_addr_t virt_to_phys(void * vaddr) #endif } +/* + * TODO: The kernel offers some more advanced versions of barriers, it might + * have some advantages to use them instead of the simple one here. + */ +#define dmb() __asm__ __volatile__ ( : : : memory) +#define __iormb() dmb() +#define __iowmb() dmb() What is the definition of these? Given that we already have an architecture-independent barrier(), I assume this is meant to be an actual hardware barrier rather than a compiler barrier, so this is not a correct implementation. They were introduced in ARM in commit 3c0659b5, so I am really just following along with that. Yes the naming doesn't make a lot of sense, but on the other hand I don't think we necessarily want an actual hardware barrier in our writel()s. We do have a hardware barrier in writel() on PPC (ignoring the broken never-used little-endian implementation, which should just be removed), and it should stay that way. I do not think we should be introducing anything that looks like a hardware barrier but isn't, unless the semantics of a particular barrier are guaranteed by a particular platform without needing a barrier instruction. And in that case there had better be a document somewhere that explains what the semantics are. Yes, agreed. This at least makes sure that the compiler writes in the right order - perhaps the intent is that that rest is best left to the hardware? Regardless of what one might think is best, it isn't left to hardware on many platforms, including PPC. I really mean that my reading is that this is all that is needed in writel() and friends. In order words, we don't need to tell the hardware to strongly order, or whatever. I think I can just drop this patch and things will still build. Can you please take a look at this code too, from the patch which brings in post-relocation board init (board_r.c): #ifdef CONFIG_PPC /* TODO: Can we not use dmb() macros for this? */ asm(sync ; isync); #endif Regards, Simon -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 01/23] ppc: Add initial memory barrier macros
On 02/12/2013 12:55:39 PM, Simon Glass wrote: Can you please take a look at this code too, from the patch which brings in post-relocation board init (board_r.c): #ifdef CONFIG_PPC /* TODO: Can we not use dmb() macros for this? */ asm(sync ; isync); #endif I'm not sure why we need that at all. It's been there since Initial revision, so git history isn't helpful in explaining it. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 01/23] ppc: Add initial memory barrier macros
Hi Scott, On Tue, Feb 12, 2013 at 11:04 AM, Scott Wood scottw...@freescale.com wrote: On 02/12/2013 12:55:39 PM, Simon Glass wrote: Can you please take a look at this code too, from the patch which brings in post-relocation board init (board_r.c): #ifdef CONFIG_PPC /* TODO: Can we not use dmb() macros for this? */ asm(sync ; isync); #endif I'm not sure why we need that at all. It's been there since Initial revision, so git history isn't helpful in explaining it. OK great, I will punt it for generic board. -Scott Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 2/3] Tegra114: fdt: Update DT files with I2C info for T114/Dalmore
Stephen,
On Tue, Feb 12, 2013 at 11:10 AM, Stephen Warren swar...@wwwdotorg.org wrote:
On 02/12/2013 10:40 AM, Tom Warren wrote:
Laxman,
On Tue, Feb 12, 2013 at 5:02 AM, Laxman Dewangan ldewan...@nvidia.com
wrote:
On Friday 08 February 2013 11:34 PM, Stephen Warren wrote:
On 02/08/2013 10:25 AM, Tom Warren wrote:
T114, like T30, does not have a separate/different DVC (power I2C)
controller like T20 - all 5 I2C controllers are identical, but
I2C5 is used to designate the controller intended for power
control (PWR_I2C in the schematics). PWR_I2C is set to 400KHz.
diff --git a/board/nvidia/dts/tegra114-dalmore.dts
b/board/nvidia/dts/tegra114-dalmore.dts
+ aliases {
+ };
+
There's no point adding an empty aliases node here. Feel free to fix
that up when you apply it rather than reposting if you want.
I'd like too see Laxman sign-off on the *2 question he had earlier
before actually checking this in.
We do not require *2 as the i2c clock divider is DIVU16 type. There was bug
in early code on kernel also which we fixed in dowstream long back. Possibly
uboot have not fixed this yet.
Yeah, the Tegra I2C driver in U-Boot has always doubled the rate
before calling the clock set routine.
Perhaps it's related to some dividers being U7.1 (i.e. the LSB of the
divider represents 1/2 not 1)? However, as Laxman points out, this isn't
the case for I2C clocks; they have a U16 divider, so the LSB represents
1 not 1/2.
But the important thing is that
the actual I2C clock is 100KHz (or 400KHz for I2C5) as measured at the
test points on the board.
I'll look into the Tegra U-Boot clock routine idiosyncrasies later
when I get some more bandwidth.
Just a few minutes of investigation points at clk_get_divider() being buggy.
It assumes that all dividers have a built-in *2 clock multiplier on the
front of them:
u64 divider = parent_rate * 2;
(the name for that variable is wrong; it should be something more like
parent_rate or divider_input_rate)
This (presence of a *2 pre-multiplier) is true for U7.1 dividers, since
this is required for the LSB of the divider to represent 1/2 not 1.
Hence, I assume that e.g. the SPI driver doesn't do this * 2 on the
clock rate; it actually has a U7.1 divider.
However, this is not true for U16 dividers, since the HW doesn't need to
multiply up the rate before dividing, since the LSB is 1 not 1/2.
The solution here is to fix clk_get_divider() to return both a field
width and a flag (or width) indicating whether a fractional part of the
divider is present, and then pass that on to adjust_periph_pll() so that
it can only optionally perform this initial * 2.
So at least that explains it.
Yeah, I just started looking at it before lunch, and saw the same thing.
I'll see about fixing it now so I can put the T114 I2C patches to bed.
Thanks
I would strongly recommend just fixing this now. However, if you don't
please do file a bug so that we don't forget about this.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] Tegra: MMC: Add DT support to MMC driver for all T20 boards
Hi Tom,
On Tue, Feb 12, 2013 at 11:05 AM, Tom Warren twarren.nvi...@gmail.com wrote:
Simon,
On Tue, Feb 12, 2013 at 11:07 AM, Simon Glass s...@chromium.org wrote:
Hi,
On Tue, Feb 5, 2013 at 1:02 PM, Tom Warren twarren.nvi...@gmail.com wrote:
Stephen,
On Tue, Feb 5, 2013 at 1:03 PM, Stephen Warren swar...@wwwdotorg.org
wrote:
On 02/04/2013 04:48 PM, Tom Warren wrote:
tegra_mmc_init() now uses DT info for bus width, WP/CD GPIOs, etc.
Tested on Seaboard, fully functional.
diff --git a/board/compal/paz00/paz00.c b/board/compal/paz00/paz00.c
index 1447f47..5cee91a 100644
--- a/board/compal/paz00/paz00.c
+++ b/board/compal/paz00/paz00.c
@@ -55,18 +55,18 @@ static void pin_mux_mmc(void)
/* this is a weak define that we are overriding */
int board_mmc_init(bd_t *bd)
{
- debug(board_mmc_init called\n);
+ debug(%s called\n, __func__);
/* Enable muxes, etc. for SDMMC controllers */
pin_mux_mmc();
- debug(board_mmc_init: init eMMC\n);
- /* init dev 0, eMMC chip, with 8-bit bus */
- tegra_mmc_init(0, 8, -1, -1);
+ debug(%s: init eMMC\n, __func__);
+ /* init dev 0, eMMC chip */
+ tegra_mmc_init(0);
- debug(board_mmc_init: init SD slot\n);
- /* init dev 3, SD slot, with 4-bit bus */
- tegra_mmc_init(3, 4, GPIO_PV1, GPIO_PV5);
+ debug(%s: init SD slot\n, __func__);
+ /* init dev 3, SD slot */
+ tegra_mmc_init(3);
return 0;
}
That doesn't look right. The board code still has knowledge of which
SDHCI controllers are in use by the board. Instead, the board should
just call tegra_mmc_init() with no parameters at all, and the MMC driver
should scan the device tree for all present-and-enabled SDHCI nodes, and
instantiate a U-Boot SDHCI device. Without this, the device tree isn't
in control of the whole process, so there's little point doing the
conversion; a new board couldn't be supported /just/ by creating a new
device tree file.
diff --git a/drivers/mmc/tegra_mmc.c b/drivers/mmc/tegra_mmc.c
+#ifndef CONFIG_OF_CONTROL
+#error Please enable device tree support to use this driver
+#endif
So CONFIG_OF_CONTROL must be enabled ...
static void tegra_get_setup(struct mmc_host *host, int dev_index)
{
- debug(tegra_get_setup: dev_index = %d\n, dev_index);
+ debug(%s: dev_index = %d\n, __func__, dev_index);
+
+#ifdef CONFIG_OF_CONTROL
... so there's no need for that ifdef
I took Allen's recent SPI/SLINK driver(s) as an example, but as you
point out, if CONFIG_OF_CONTROL isn't enabled, you get build errors
anyway.
+ int count, node = 0;
+ int node_list[MAX_HOSTS];
+
+ count = fdtdec_find_aliases_for_id(gd-fdt_blob, sdmmc,
+ COMPAT_NVIDIA_TEGRA20_SDMMC, node_list, MAX_HOSTS);
+ debug(%s: count of nodes is %d\n, __func__, count);
+
+ if (count dev_index) {
+ printf(%s: device index %d exceeds node count (%d)!\n,
+ __func__, dev_index, count);
+ return;
+ }
This requires that an alias exist in order for the SDHCI node to be
found/processed. This isn't correct; the SDHCI nodes must be enumerated
themselves, and then the aliases (if any are present) provide a naming
hint for them, but even without aliases, the SDHCI nodes must be processed.
Again, I used Allen's SLINK driver for as a template here. In fact, it
looks like our I2C and SPI/SLINK drivers do this, as well as the
Exynos SPI and S3C24x0 I2C driver all do this. Can you point out a
U-Boot driver that does it the right way (preferably with more than 1
node, like MMC)? I can take a look at that code to use as an example
of what you're proposing above.
You have it correct already. Stephen please take another look and let
me know what problem you see with this approach. I'm very sorry that I
am so late to this discussion.
PTAL at the current patchset (v2) - I changed it to look for 'sdhci',
which names the node and the aliases, and seem to work fine. I also
have one function that parses all the nodes at once, so only one call
to tegra_mmc_init() is needed from the board level.
Great. Yes I think that was the version I looked at (above, in this thread).
Regards,
Simon
+ /*
+ * NOTE: mmc-bus_width is determined by mmc.c dynamically.
+ * Should we override it with this value?
+ */
+ host-width = fdtdec_get_int(gd-fdt_blob, node, bus-width, 0);
+ if (!host-width)
+ debug(%s: no sdmmc width found\n, __func__);
It should be possible to inform the MMC core of the width of the bus in
terms of wires on the PCB. It should only probe the connected device up
to that width. If that feature is missing, it can be added later though,
outside the scope of this patch set.
You didn't Cc the MMC maintainer; they should be Cc'd since this code is
in drivers/mmc/.
Thanks, added Andy Fleming to CC.
Tom
___
U-Boot mailing list
Re: [U-Boot] [PATCH v2 2/3] Tegra114: fdt: Update DT files with I2C info for T114/Dalmore
Simon,
On Tue, Feb 12, 2013 at 11:13 AM, Simon Glass s...@chromium.org wrote:
Hi Stephen,
On Thu, Feb 7, 2013 at 10:17 AM, Stephen Warren swar...@wwwdotorg.org wrote:
On 02/07/2013 09:14 AM, Tom Warren wrote:
Stephen,
On Wed, Feb 6, 2013 at 5:00 PM, Stephen Warren swar...@wwwdotorg.org
wrote:
On 02/06/2013 04:26 PM, Tom Warren wrote:
Note that T114 does not have a separate/different DVC (power I2C)
controller like T20 - all 5 I2C controllers are identical, but
I2C5 is used to designate the controller intended for power
control (PWR_I2C in the schematics).
diff --git a/arch/arm/dts/tegra114.dtsi b/arch/arm/dts/tegra114.dtsi
+ tegra_car: clock@60006000 {
+ compatible = nvidia,tegra114-car, nvidia,tegra30-car;
Only the Tegra114 value should be listed here; the presence of the
Tegra30 value in the upstream kernel is a mistake that will be fixed as
part of the Tegra114 clock driver patches.
OK. But this is why I think hewing to the Linux DT files, while
laudable, is a time sink. Though since T114 is so new still settling
in, I guess some churn is expected.
The issue here is not about making U-Boot fall in line with the kernel.
The issue is making the device tree in U-Boot be correct. Right now, the
kernel happens to have the most correct device tree, so it's a good
reference for U-Boot.
+ i2c@7000c000 {
+ compatible = nvidia,tegra114-i2c, nvidia,tegra20-i2c;
Same here; only include the Tegra114 value since the HW isn't 100%
compatible with the Tegra20 HW.
What does the 'compatible' designater mean, exactly? Does it require
100% identical HW? Compatible, in a SW/HW sense, to me means that
newer SW will work with older/similar (but not exactly the same) HW,
etc.
The idea here is that the first entry in compatible always defines the
most specific implementation identification possible. So, compatible
will at least contain:
Tegra20: nvidia,tegra20-i2c
Tegra30: nvidia,tegra30-i2c
Tegra114: nvidia,tegra114-i2c
Now, if a piece of newer hardware can be operated 100% correctly
(ignoring issues due to new features not being exposed, or operating at
degraded performance) by a driver that only knows about the older
hardware, then the compatible property can additionally contain other
values indicating what HW it is compatible with. So, we actually end up
with:
Tegra20: nvidia,tegra20-i2c
Tegra30: nvidia,tegra30-i2c nvidia,tegra20-i2c
Tegra114: nvidia,tegra114-i2c
Tegra114 I2C HW isn't marked as compatible with either Tegra20 or
Tegra30, because the clock divider programming must be different.
Tegra U-Boot uses the tegra20-i2c name to find and load the I2C
driver. I could add a new entry in the compat-names table for
tegra114-i2c,
Yes, that is the way to go. The driver should include a list of all the
different compatible values that it supports.
but I still don't think there's enough difference
between T20/T30 and T114 I2C to justify a whole new I2C driver - so
far, it's just one register with a new clk divider that has to be
taken in consideration when programming the clock source divider.
But that's required to operate the hardware correctly. It doesn't matter
how trivial the difference is; it could just be a single bit that needs
to be set/cleared on new HW - there would still be a difference that
would otherwise make the HW operate incorrectly.
I could do as the driver does for T20, where there is a separate DVC
controller, plus 3 normal I2C controllers. I could 'find_aliases' for
the tegrat114-i2c controller first, process its nodes, and return. If
no tegrat114-i2c exists, the driver would continue on to look for
tegra20-i2c/tegra20-dvc controller info as it does now. It'd still be
one tegra_i2c.c driver, with a flag in the i2c_bus struct telling me
if I found T114 I2C HW (i2c_bus-single_clk, etc.) and I could then do
the new clock divider dance based on that flag. How does that sound?
The U-Boot function that returns the list of devices supported by the
driver should be enhanced so that it can search for nodes compatible
with any 1 (or more) of n compatible values at a time, rather than just
a single compatible value. Then, all you'd have to do with this change
is add a new entry into the table, not add extra code that calls that
function separately for each compatible value.
Yes, that needs to be done, and while we are at it I think the
function should return a list containing struct {int offset; enum
fdt_compat_id; };
I could probably do this by end of week if no one else can do it
faster. Please let me know. Tests need to updated also.
I won't have time for this this week (on vacation Friday thru
Tuesday). If you want to tackle this, go ahead. The current T114 I2C
patchset is good-to-go AFAICT, with the exception of the clock divisor
fix Stephen just pointed out in another thread. So you can use that as
your basis for rewrite, if you wish.
diff --git
Re: [U-Boot] [PATCH v2 2/3] Tegra114: fdt: Update DT files with I2C info for T114/Dalmore
Hi Tom,
On Tue, Feb 12, 2013 at 11:13 AM, Tom Warren twarren.nvi...@gmail.com wrote:
Simon,
On Tue, Feb 12, 2013 at 11:13 AM, Simon Glass s...@chromium.org wrote:
Hi Stephen,
On Thu, Feb 7, 2013 at 10:17 AM, Stephen Warren swar...@wwwdotorg.org
wrote:
On 02/07/2013 09:14 AM, Tom Warren wrote:
Stephen,
On Wed, Feb 6, 2013 at 5:00 PM, Stephen Warren swar...@wwwdotorg.org
wrote:
On 02/06/2013 04:26 PM, Tom Warren wrote:
Note that T114 does not have a separate/different DVC (power I2C)
controller like T20 - all 5 I2C controllers are identical, but
I2C5 is used to designate the controller intended for power
control (PWR_I2C in the schematics).
diff --git a/arch/arm/dts/tegra114.dtsi b/arch/arm/dts/tegra114.dtsi
+ tegra_car: clock@60006000 {
+ compatible = nvidia,tegra114-car, nvidia,tegra30-car;
Only the Tegra114 value should be listed here; the presence of the
Tegra30 value in the upstream kernel is a mistake that will be fixed as
part of the Tegra114 clock driver patches.
OK. But this is why I think hewing to the Linux DT files, while
laudable, is a time sink. Though since T114 is so new still settling
in, I guess some churn is expected.
The issue here is not about making U-Boot fall in line with the kernel.
The issue is making the device tree in U-Boot be correct. Right now, the
kernel happens to have the most correct device tree, so it's a good
reference for U-Boot.
+ i2c@7000c000 {
+ compatible = nvidia,tegra114-i2c, nvidia,tegra20-i2c;
Same here; only include the Tegra114 value since the HW isn't 100%
compatible with the Tegra20 HW.
What does the 'compatible' designater mean, exactly? Does it require
100% identical HW? Compatible, in a SW/HW sense, to me means that
newer SW will work with older/similar (but not exactly the same) HW,
etc.
The idea here is that the first entry in compatible always defines the
most specific implementation identification possible. So, compatible
will at least contain:
Tegra20: nvidia,tegra20-i2c
Tegra30: nvidia,tegra30-i2c
Tegra114: nvidia,tegra114-i2c
Now, if a piece of newer hardware can be operated 100% correctly
(ignoring issues due to new features not being exposed, or operating at
degraded performance) by a driver that only knows about the older
hardware, then the compatible property can additionally contain other
values indicating what HW it is compatible with. So, we actually end up
with:
Tegra20: nvidia,tegra20-i2c
Tegra30: nvidia,tegra30-i2c nvidia,tegra20-i2c
Tegra114: nvidia,tegra114-i2c
Tegra114 I2C HW isn't marked as compatible with either Tegra20 or
Tegra30, because the clock divider programming must be different.
Tegra U-Boot uses the tegra20-i2c name to find and load the I2C
driver. I could add a new entry in the compat-names table for
tegra114-i2c,
Yes, that is the way to go. The driver should include a list of all the
different compatible values that it supports.
but I still don't think there's enough difference
between T20/T30 and T114 I2C to justify a whole new I2C driver - so
far, it's just one register with a new clk divider that has to be
taken in consideration when programming the clock source divider.
But that's required to operate the hardware correctly. It doesn't matter
how trivial the difference is; it could just be a single bit that needs
to be set/cleared on new HW - there would still be a difference that
would otherwise make the HW operate incorrectly.
I could do as the driver does for T20, where there is a separate DVC
controller, plus 3 normal I2C controllers. I could 'find_aliases' for
the tegrat114-i2c controller first, process its nodes, and return. If
no tegrat114-i2c exists, the driver would continue on to look for
tegra20-i2c/tegra20-dvc controller info as it does now. It'd still be
one tegra_i2c.c driver, with a flag in the i2c_bus struct telling me
if I found T114 I2C HW (i2c_bus-single_clk, etc.) and I could then do
the new clock divider dance based on that flag. How does that sound?
The U-Boot function that returns the list of devices supported by the
driver should be enhanced so that it can search for nodes compatible
with any 1 (or more) of n compatible values at a time, rather than just
a single compatible value. Then, all you'd have to do with this change
is add a new entry into the table, not add extra code that calls that
function separately for each compatible value.
Yes, that needs to be done, and while we are at it I think the
function should return a list containing struct {int offset; enum
fdt_compat_id; };
I could probably do this by end of week if no one else can do it
faster. Please let me know. Tests need to updated also.
I won't have time for this this week (on vacation Friday thru
Tuesday). If you want to tackle this, go ahead. The current T114 I2C
patchset is good-to-go AFAICT, with the exception of the clock divisor
fix Stephen just pointed out in another thread.
Re: [U-Boot] [PATCH] Allow OMAP2 boards to setup GPMC chipselects.
On 12/02/13 17:01, Tom Rini wrote: On Mon, Feb 11, 2013 at 04:29:03PM +, Mark Jackson wrote: Expose the enable_gpmc_cs_config() function so OMAP2 boards can register GPMC chipselects. Signed-off-by: Mark Jackson m...@newflow.co.uk --- arch/arm/include/asm/arch-am33xx/sys_proto.h |2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/include/asm/arch-am33xx/sys_proto.h b/arch/arm/include/asm/arch-am33xx/sys_proto.h index 588d8de..97ab60d 100644 --- a/arch/arm/include/asm/arch-am33xx/sys_proto.h +++ b/arch/arm/include/asm/arch-am33xx/sys_proto.h @@ -35,5 +35,7 @@ void ddr_pll_config(unsigned int ddrpll_M); void sdelay(unsigned long); void gpmc_init(void); +void enable_gpmc_cs_config(const u32 *gpmc_config, struct gpmc_cs *cs, u32 base, + u32 size); void omap_nand_switch_ecc(int); #endif Can you please correct the description? You're exposing the function for am33xx not omap2. Otherwise fine with me, and I assume you need this on a custom board (aside: the function already exists/is used in arch/arm/cpu/armv7/am33xx/mem.c). Are you planning to submit that support as well? Thanks! Sure ... I'll repost with the comment changed. Yes ... I've not written my own version, I'm using the existing code. And, yes, I've a new CPU board I'm working on, which I'll submit later (once we've done a hardware re-spin). Cheers Mark J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 01/23] ppc: Add initial memory barrier macros
On 02/12/2013 12:44:16 PM, Simon Glass wrote: Hi Scott, On Mon, Feb 11, 2013 at 11:52 AM, Scott Wood scottw...@freescale.com wrote: On 02/08/2013 09:11:57 AM, Simon Glass wrote: These are available on other architectures, so add them on ppc. Signed-off-by: Simon Glass s...@chromium.org --- Changes in v5: None Changes in v4: None Changes in v3: None Changes in v2: None arch/powerpc/include/asm/io.h | 8 1 file changed, 8 insertions(+) diff --git a/arch/powerpc/include/asm/io.h b/arch/powerpc/include/asm/io.h index 1f12c29..1bf12f5 100644 --- a/arch/powerpc/include/asm/io.h +++ b/arch/powerpc/include/asm/io.h @@ -317,4 +317,12 @@ static inline phys_addr_t virt_to_phys(void * vaddr) #endif } +/* + * TODO: The kernel offers some more advanced versions of barriers, it might + * have some advantages to use them instead of the simple one here. + */ +#define dmb() __asm__ __volatile__ ( : : : memory) +#define __iormb() dmb() +#define __iowmb() dmb() What is the definition of these? Given that we already have an architecture-independent barrier(), I assume this is meant to be an actual hardware barrier rather than a compiler barrier, so this is not a correct implementation. They were introduced in ARM in commit 3c0659b5, so I am really just following along with that. Yes the naming doesn't make a lot of sense, but on the other hand I don't think we necessarily want an actual hardware barrier in our writel()s. We do have a hardware barrier in writel() on PPC (ignoring the broken never-used little-endian implementation, which should just be removed), and it should stay that way. I do not think we should be introducing anything that looks like a hardware barrier but isn't, unless the semantics of a particular barrier are guaranteed by a particular platform without needing a barrier instruction. And in that case there had better be a document somewhere that explains what the semantics are. This at least makes sure that the compiler writes in the right order - perhaps the intent is that that rest is best left to the hardware? Regardless of what one might think is best, it isn't left to hardware on many platforms, including PPC. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] Allow AM33xx boards to setup GPMC chipselects.
Expose the enable_gpmc_cs_config() function so AM33xx based boards can register GPMC chip selects. Changes in V2: - Indicate this is for AM33xx (not OMAP2) Signed-off-by: Mark Jackson m...@newflow.co.uk --- arch/arm/include/asm/arch-am33xx/sys_proto.h |2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/include/asm/arch-am33xx/sys_proto.h b/arch/arm/include/asm/arch-am33xx/sys_proto.h index 588d8de..97ab60d 100644 --- a/arch/arm/include/asm/arch-am33xx/sys_proto.h +++ b/arch/arm/include/asm/arch-am33xx/sys_proto.h @@ -35,5 +35,7 @@ void ddr_pll_config(unsigned int ddrpll_M); void sdelay(unsigned long); void gpmc_init(void); +void enable_gpmc_cs_config(const u32 *gpmc_config, struct gpmc_cs *cs, u32 base, + u32 size); void omap_nand_switch_ecc(int); #endif -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/2] Tegra: MMC: Add DT support to MMC driver for all T20 boards
Lucas,
On Mon, Feb 11, 2013 at 10:59 AM, Tom Warren twarren.nvi...@gmail.com wrote:
Lucas,
On Mon, Feb 11, 2013 at 10:33 AM, Lucas Stach d...@lynxeye.de wrote:
Am Montag, den 11.02.2013, 10:17 -0700 schrieb Tom Warren:
tegra_mmc_init() now parses the DT info for bus width, WP/CD GPIOs, etc.
Tested on Seaboard, fully functional.
Tamonten boards (medcom-wide, plutux, and tec) use a different/new
dtsi file w/common settings.
Signed-off-by: Tom Warren twar...@nvidia.com
---
v2:
- all boards now call tegra_mmc_init once, w/no params
- count MMC controllers, not aliases
- AD boards (medcom/plutux/tec) use common tegra20-tamonten.dtsi
arch/arm/include/asm/arch-tegra/mmc.h |2 +-
arch/arm/include/asm/arch-tegra/tegra_mmc.h | 13 +-
board/avionic-design/common/tamonten.c|4 +-
board/compal/paz00/paz00.c| 11 +-
board/compulab/trimslice/trimslice.c |9 +-
board/nvidia/harmony/harmony.c| 11 +-
board/nvidia/seaboard/seaboard.c | 11 +-
board/nvidia/whistler/whistler.c |7 +-
board/toradex/colibri_t20_iris/colibri_t20_iris.c |2 +-
drivers/mmc/tegra_mmc.c | 259
+
include/configs/medcom-wide.h |2 +
include/configs/plutux.h |2 +
include/configs/tec.h |2 +
include/fdtdec.h |1 +
lib/fdtdec.c |1 +
15 files changed, 197 insertions(+), 140 deletions(-)
[...]
diff --git a/board/nvidia/harmony/harmony.c b/board/nvidia/harmony/harmony.c
index 93430ed..fba06c2 100644
--- a/board/nvidia/harmony/harmony.c
+++ b/board/nvidia/harmony/harmony.c
@@ -58,18 +58,13 @@ static void pin_mux_mmc(void)
/* this is a weak define that we are overriding */
int board_mmc_init(bd_t *bd)
{
- debug(board_mmc_init called\n);
+ debug(%s called\n, __func__);
/* Enable muxes, etc. for SDMMC controllers */
pin_mux_mmc();
- debug(board_mmc_init: init SD slot J26\n);
- /* init dev 0, SD slot J26, with 8-bit bus */
- tegra_mmc_init(0, 8, GPIO_PI6, GPIO_PH2);
-
- debug(board_mmc_init: init SD slot J5\n);
- /* init dev 2, SD slot J5, with 4-bit bus */
- tegra_mmc_init(2, 4, GPIO_PT3, GPIO_PI5);
+ debug(%s: init MMC devs\n, __func__);
+ tegra_mmc_init();
tegra_mmc_init should not be called from every individual board file,
but from the common nvidia tegra board file. Only the pinmux should stay
in the individual board code, same thing as was done to all the other
functions like NAND and USB.
True. I was originally just adapting the current config-file driven
MMC to DT step-by-step, but you're right - it should be called just
once for all boards in the common board file. I'll change it in V3.
I've looked into this some more, and it appears that I can't just add
a call to tegra_mmc_init() from board_init() in
boards/nvidia/common/board.c.
board_init() is where the other periphs do their pin_mux and
xxx_init() calls (USB, SPI, etc.). board_init() is called early in
board_init_r(), before mmc_initialize() is called. mmc_initialize() is
needed before tegra_mmc_init() can use the mmc_device struct, etc. So
tegra_mmc_init() needs to be called after mmc_initialize(), and right
now that's in each board's board_mmc_init(). In board_mmc_init(),
each board sets up any power rails needed for SD-card or eMMC access,
sets up it's pin muxes for MMC, and then calls tegra_mmc_init() to
parse the DT file and populate the mmc structs.
I could move the pin_mux_mmc() function calls from each board file
into nvidia/common/board.c's board_init(), but it wouldn't really
change much. So I'll leave it as it is for now, with pin_mux_mmc() and
tegra_mmc_init() being called from each board's 'board' file
(seaboard.c, colibri_t20_iris.c, etc).
Let me know if you see another way to move Tegra MMC init to a common
board file that doesn't break the MMC driver flow.
Thanks,
Tom
Thanks,
Tom
return 0;
}
[...]
Regards,
Lucas
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/3] Tegra114: fdt: Update DT files with I2C info for T114/Dalmore
On 02/12/2013 12:17 PM, Simon Glass wrote: Hi Tom, On Tue, Feb 12, 2013 at 11:13 AM, Tom Warren twarren.nvi...@gmail.com wrote: ... That's the current POR for Tegra DT use in upstream U-Boot, assuming I can find an up-to-date kernel with the latest DTS files (I'll use Stephen's swarren/linux-tegra.git/for-next until told otherwise). Yes that was always my problem - finding what the kernel actually used, might use, etc. I must say I find this quite puzzling; the kernel repos aren't exactly hidden. Tegra's kernel for-next is likely the best place right now as any DT changes typically go through that tree. However, on the off-chance any other maintainer picks up any changes, linux-next.git would have the latest bindings. That's all been true for a year or more. That said, there is a move to either move the binding definitions and .dts files out of the kernel tree and/or stop taking changes to them through individual SoC trees, but perhaps through the device tree repo. If that does happen, I'll let you know. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/3] Tegra114: fdt: Update DT files with I2C info for T114/Dalmore
Hi Stephen, On Tue, Feb 12, 2013 at 11:26 AM, Stephen Warren swar...@wwwdotorg.org wrote: On 02/12/2013 12:17 PM, Simon Glass wrote: Hi Tom, On Tue, Feb 12, 2013 at 11:13 AM, Tom Warren twarren.nvi...@gmail.com wrote: ... That's the current POR for Tegra DT use in upstream U-Boot, assuming I can find an up-to-date kernel with the latest DTS files (I'll use Stephen's swarren/linux-tegra.git/for-next until told otherwise). Yes that was always my problem - finding what the kernel actually used, might use, etc. I must say I find this quite puzzling; the kernel repos aren't exactly hidden. Well if a change has made it to a repo then things are easier, particularly if it is next/. It was chasing down patches on mailing lists that I found hard. Tegra's kernel for-next is likely the best place right now as any DT changes typically go through that tree. However, on the off-chance any other maintainer picks up any changes, linux-next.git would have the latest bindings. That's all been true for a year or more. That said, there is a move to either move the binding definitions and .dts files out of the kernel tree and/or stop taking changes to them through individual SoC trees, but perhaps through the device tree repo. If that does happen, I'll let you know. Sounds good. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/3] Tegra114: fdt: Update DT files with I2C info for T114/Dalmore
On Tue, Feb 12, 2013 at 12:26 PM, Stephen Warren swar...@wwwdotorg.org wrote: On 02/12/2013 12:17 PM, Simon Glass wrote: Hi Tom, On Tue, Feb 12, 2013 at 11:13 AM, Tom Warren twarren.nvi...@gmail.com wrote: ... That's the current POR for Tegra DT use in upstream U-Boot, assuming I can find an up-to-date kernel with the latest DTS files (I'll use Stephen's swarren/linux-tegra.git/for-next until told otherwise). Yes that was always my problem - finding what the kernel actually used, might use, etc. I must say I find this quite puzzling; the kernel repos aren't exactly hidden. Not hidden, but numerous. Perhaps I should have said 'can find _the correct_ kernel ...'. I've been pointed to 2 or 3 different repos over the course of these DT patches. I'm not a kernel guru, and I don't have the bandwidth to monitor kernel reflectors, etc. When I need something kernel-related, I resort to Google or asking you. Tegra's kernel for-next is likely the best place right now as any DT changes typically go through that tree. However, on the off-chance any other maintainer picks up any changes, linux-next.git would have the latest bindings. That's all been true for a year or more. That said, there is a move to either move the binding definitions and .dts files out of the kernel tree and/or stop taking changes to them through individual SoC trees, but perhaps through the device tree repo. If that does happen, I'll let you know. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/2] Tegra: MMC: Add DT support to MMC driver for all T20 boards
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.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/12/2013 02:20 PM, Mark Jackson wrote: On 12/02/13 17:01, Tom Rini wrote: On Mon, Feb 11, 2013 at 04:29:03PM +, Mark Jackson wrote: Expose the enable_gpmc_cs_config() function so OMAP2 boards can register GPMC chipselects. Signed-off-by: Mark Jackson m...@newflow.co.uk --- arch/arm/include/asm/arch-am33xx/sys_proto.h |2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/include/asm/arch-am33xx/sys_proto.h b/arch/arm/include/asm/arch-am33xx/sys_proto.h index 588d8de..97ab60d 100644 --- a/arch/arm/include/asm/arch-am33xx/sys_proto.h +++ b/arch/arm/include/asm/arch-am33xx/sys_proto.h @@ -35,5 +35,7 @@ void ddr_pll_config(unsigned int ddrpll_M); void sdelay(unsigned long); void gpmc_init(void); +void enable_gpmc_cs_config(const u32 *gpmc_config, struct gpmc_cs *cs, u32 base, +u32 size); void omap_nand_switch_ecc(int); #endif Can you please correct the description? You're exposing the function for am33xx not omap2. Otherwise fine with me, and I assume you need this on a custom board (aside: the function already exists/is used in arch/arm/cpu/armv7/am33xx/mem.c). Are you planning to submit that support as well? Thanks! Sure ... I'll repost with the comment changed. Thanks. Yes ... I've not written my own version, I'm using the existing code. And, yes, I've a new CPU board I'm working on, which I'll submit later (once we've done a hardware re-spin). Looking forward to it! - -- Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRGpzgAAoJENk4IS6UOR1WZh8P+gOPjlJmQi5ZRJSR3fE8gIUu it1T5VDXWiWLLHRDkCsdK5DkamrLwQwYdOpSqVWqN48gqPJJasgSIf36+H5kXArR lkyE1HzmGsP8v31deY/6wIAPy0g3JTCac9IhCmvLkkNwGJzlfdTtoCHyd20oxDmh gzCo9y7PuDfdVnONlyGwuKdefqH/u9gq5nbKdw15DpTgGITUaXfOpRj/4wKOMx0t KzaGXNcKrs30gKJoTEO0R8voRi6s0sEn9uSFBxBp3EXrrQNC8Ee1AKL+RCXfH28Y L3PB1T1eRAAnG5erZOh4EoYzpSwzARJ9vEUOu96m4dLUihDH6ShD+0LSYfTLr0cm wpt2ivzN7Ede9kGg2bZ9l+eL0c5/+V+ZkBqv1m4nT//qxKj/AweuUxexXWnxmVsF XotwUVNPpb2AhDnqRShC56zEM+0CFyNPlSSvp93CO6V/jB4W+RRd9IoKw7AHWmvS KldbC75kDwxncxlCelc3BqDrlh7NZ6yJGVeHfNHm1BNWlg7CCn36IDXUNQ7UAOKE BQ+8u4liYkhGw+EJS0f7o7TD0d1o4qOj/IB5e7sAhhgTeOw/A2jP78HzAvKhGamQ ETJSAzr0M8a1B2Y7YjRM8HG9f0drGWXuektF9y9/vmGaGSOxfYMjLq/Jbe6Pifnv Mi6lmINkleLKmto50Ppf =KvZG -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/2] Tegra: MMC: Add DT support to MMC driver for all T20 boards
Lucas, On Tue, Feb 12, 2013 at 12:41 PM, Lucas Stach d...@lynxeye.de wrote: Hello Tom, Am Dienstag, den 12.02.2013, 12:24 -0700 schrieb Tom Warren: Lucas, tegra_mmc_init should not be called from every individual board file, but from the common nvidia tegra board file. Only the pinmux should stay in the individual board code, same thing as was done to all the other functions like NAND and USB. True. I was originally just adapting the current config-file driven MMC to DT step-by-step, but you're right - it should be called just once for all boards in the common board file. I'll change it in V3. I've looked into this some more, and it appears that I can't just add a call to tegra_mmc_init() from board_init() in boards/nvidia/common/board.c. board_init() is where the other periphs do their pin_mux and xxx_init() calls (USB, SPI, etc.). board_init() is called early in board_init_r(), before mmc_initialize() is called. mmc_initialize() is needed before tegra_mmc_init() can use the mmc_device struct, etc. So tegra_mmc_init() needs to be called after mmc_initialize(), and right now that's in each board's board_mmc_init(). In board_mmc_init(), each board sets up any power rails needed for SD-card or eMMC access, sets up it's pin muxes for MMC, and then calls tegra_mmc_init() to parse the DT file and populate the mmc structs. I could move the pin_mux_mmc() function calls from each board file into nvidia/common/board.c's board_init(), but it wouldn't really change much. So I'll leave it as it is for now, with pin_mux_mmc() and tegra_mmc_init() being called from each board's 'board' file (seaboard.c, colibri_t20_iris.c, etc). Let me know if you see another way to move Tegra MMC init to a common board file that doesn't break the MMC driver flow. I didn't look up the flow myself, as I don't have time for that right now, but I think I've got a pretty good picture from your description. Thanks for the quick response. I think we should really try to make the Tegra MMC init flow as similar as possible to the other peripherals, so I suggest doing the following: 1. Provide a pin_mux_mmc() (possibly with a weak define as done with other peripherals). Boards should do pinmux and rail enabling within this function. (Almost) every Tegra board already has a pin_mux_mmc(). Few boards do any power-rail enabling, but I can move those that do into pin_mux_mmc(). 2. Move board_mmc_init() into nvidia/common/board.c, this function should call into the board specific pinmux function and then call tegra_mmc_init(). Current board_mmc_init() does call pin_mux_mmc() and then tegra_mmc_init(). Moving it from each board file into common/board.c is a good idea. I'll try that. Thanks So even while we don't get the complete same flow as for other peripherals as the board_mmc_init() still has to be a freestanding function, instead of those things being folded into board_init(), we at least gain a clear distinction between the board specific parts and Tegra common code. Regards, Lucas ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] am335x_evm: Fix CPSW ethernet on GP EVM and EVM-SK
In commit cfd4ff6 we implemented part of advisory 1.0.10 (internal delay
for RGMII mode not supported). This in turn however requires that we
set the tx clock delay feature in the PHY itself.
Signed-off-by: Tom Rini tr...@ti.com
---
board/ti/am335x/board.c | 27 +++
1 file changed, 27 insertions(+)
diff --git a/board/ti/am335x/board.c b/board/ti/am335x/board.c
index b9ac1d5..48e6896 100644
--- a/board/ti/am335x/board.c
+++ b/board/ti/am335x/board.c
@@ -73,6 +73,11 @@ static inline int board_is_idk(void)
return !strncmp(header.config, SKU#02, 6);
}
+static int board_is_gp_evm(void)
+{
+ return !strncmp(A33515BB, header.name, 8);
+}
+
int board_is_evm_15_or_later(void)
{
return (!strncmp(A33515BB, header.name, 8)
@@ -466,6 +471,28 @@ int board_eth_init(bd_t *bis)
printf(Error %d registering CPSW switch\n, rv);
else
n += rv;
+
+ /*
+*
+* CPSW RGMII Internal Delay Mode is not supported in all PVT
+* operating points. So we must set the TX clock delay feature
+* in the AR8051 PHY. Since we only support a single ethernet
+* device in U-Boot, we only do this for the first instance.
+*/
+#define AR8051_PHY_DEBUG_ADDR_REG 0x1d
+#define AR8051_PHY_DEBUG_DATA_REG 0x1e
+#define AR8051_DEBUG_RGMII_CLK_DLY_REG 0x5
+#define AR8051_RGMII_TX_CLK_DLY0x100
+
+ if (board_is_evm_sk() || board_is_gp_evm()) {
+ const char *devname;
+ devname = miiphy_get_current_dev();
+
+ miiphy_write(devname, 0x0, AR8051_PHY_DEBUG_ADDR_REG,
+ AR8051_DEBUG_RGMII_CLK_DLY_REG);
+ miiphy_write(devname, 0x0, AR8051_PHY_DEBUG_DATA_REG,
+ AR8051_RGMII_TX_CLK_DLY);
+ }
#endif
try_usbether:
#if defined(CONFIG_USB_ETHER) !defined(CONFIG_SPL_BUILD)
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] Tegra: MMC: Add DT support to MMC driver for all T20 boards
On 02/12/2013 11:07 AM, Simon Glass wrote:
Hi,
On Tue, Feb 5, 2013 at 1:02 PM, Tom Warren twarren.nvi...@gmail.com wrote:
Stephen,
On Tue, Feb 5, 2013 at 1:03 PM, Stephen Warren swar...@wwwdotorg.org wrote:
On 02/04/2013 04:48 PM, Tom Warren wrote:
tegra_mmc_init() now uses DT info for bus width, WP/CD GPIOs, etc.
Tested on Seaboard, fully functional.
diff --git a/board/compal/paz00/paz00.c b/board/compal/paz00/paz00.c
index 1447f47..5cee91a 100644
--- a/board/compal/paz00/paz00.c
+++ b/board/compal/paz00/paz00.c
@@ -55,18 +55,18 @@ static void pin_mux_mmc(void)
/* this is a weak define that we are overriding */
int board_mmc_init(bd_t *bd)
{
- debug(board_mmc_init called\n);
+ debug(%s called\n, __func__);
/* Enable muxes, etc. for SDMMC controllers */
pin_mux_mmc();
- debug(board_mmc_init: init eMMC\n);
- /* init dev 0, eMMC chip, with 8-bit bus */
- tegra_mmc_init(0, 8, -1, -1);
+ debug(%s: init eMMC\n, __func__);
+ /* init dev 0, eMMC chip */
+ tegra_mmc_init(0);
- debug(board_mmc_init: init SD slot\n);
- /* init dev 3, SD slot, with 4-bit bus */
- tegra_mmc_init(3, 4, GPIO_PV1, GPIO_PV5);
+ debug(%s: init SD slot\n, __func__);
+ /* init dev 3, SD slot */
+ tegra_mmc_init(3);
return 0;
}
That doesn't look right. The board code still has knowledge of which
SDHCI controllers are in use by the board. Instead, the board should
just call tegra_mmc_init() with no parameters at all, and the MMC driver
should scan the device tree for all present-and-enabled SDHCI nodes, and
instantiate a U-Boot SDHCI device. Without this, the device tree isn't
in control of the whole process, so there's little point doing the
conversion; a new board couldn't be supported /just/ by creating a new
device tree file.
diff --git a/drivers/mmc/tegra_mmc.c b/drivers/mmc/tegra_mmc.c
+#ifndef CONFIG_OF_CONTROL
+#error Please enable device tree support to use this driver
+#endif
So CONFIG_OF_CONTROL must be enabled ...
static void tegra_get_setup(struct mmc_host *host, int dev_index)
{
- debug(tegra_get_setup: dev_index = %d\n, dev_index);
+ debug(%s: dev_index = %d\n, __func__, dev_index);
+
+#ifdef CONFIG_OF_CONTROL
... so there's no need for that ifdef
I took Allen's recent SPI/SLINK driver(s) as an example, but as you
point out, if CONFIG_OF_CONTROL isn't enabled, you get build errors
anyway.
+ int count, node = 0;
+ int node_list[MAX_HOSTS];
+
+ count = fdtdec_find_aliases_for_id(gd-fdt_blob, sdmmc,
+ COMPAT_NVIDIA_TEGRA20_SDMMC, node_list, MAX_HOSTS);
+ debug(%s: count of nodes is %d\n, __func__, count);
+
+ if (count dev_index) {
+ printf(%s: device index %d exceeds node count (%d)!\n,
+ __func__, dev_index, count);
+ return;
+ }
This requires that an alias exist in order for the SDHCI node to be
found/processed. This isn't correct; the SDHCI nodes must be enumerated
themselves, and then the aliases (if any are present) provide a naming
hint for them, but even without aliases, the SDHCI nodes must be processed.
Again, I used Allen's SLINK driver for as a template here. In fact, it
looks like our I2C and SPI/SLINK drivers do this, as well as the
Exynos SPI and S3C24x0 I2C driver all do this. Can you point out a
U-Boot driver that does it the right way (preferably with more than 1
node, like MMC)? I can take a look at that code to use as an example
of what you're proposing above.
You have it correct already. Stephen please take another look and let
me know what problem you see with this approach. I'm very sorry that I
am so late to this discussion.
Could you explain how this works then? The code I looked at (a) was
driven by board files not DT enumerationk (b) errored out if no alias ID
was present.
But given there's a V2, I'll go look at that and check again.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] Tegra: fdt: Add/enhance sdhci (mmc) nodes for all T20 DT files
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
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
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
On 02/08/2013 09:12:08 AM, Simon Glass wrote:
This adds secondary program loader support to the generic board.
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None
common/board_f.c | 20
1 file changed, 20 insertions(+)
diff --git a/common/board_f.c b/common/board_f.c
index aa10f4b..3a8036f 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -309,6 +309,7 @@ static int reserve_uboot(void)
return 0;
}
+#ifndef CONFIG_SPL_BUILD
/* reserve memory for malloc() area */
static int reserve_malloc(void)
{
@@ -328,6 +329,7 @@ static int reserve_board(void)
sizeof(bd_t), gd-dest_addr_sp);
return 0;
}
+#endif
static int setup_machine(void)
{
@@ -365,6 +367,7 @@ static int reserve_fdt(void)
return 0;
}
+#ifndef CONFIG_SPL_BUILD
static int reserve_stacks(void)
{
/* setup stack pointer for exceptions */
@@ -384,6 +387,17 @@ static int reserve_stacks(void)
return 0;
}
+#endif
+
+#ifdef CONFIG_SPL_BUILD
+static int reserve_stacks_spl(void)
+{
+ /* Why not -= ? */
+ gd-dest_addr_sp += 128; /* leave 32 words for
abort-stack */
+ gd-irq_sp = gd-dest_addr_sp;
+ return 0;
+}
+#endif
abort-stack doesn't sound very generic, and that why not question
should probably be answered.
static int display_new_sp(void)
{
@@ -524,12 +538,18 @@ static init_fnc_t init_sequence_f[] = {
reserve_lcd,
#endif
reserve_uboot,
+#ifndef CONFIG_SPL_BUILD
reserve_malloc,
reserve_board,
+#endif
setup_machine,
reserve_global_data,
reserve_fdt,
+#ifdef CONFIG_SPL_BUILD
+ reserve_stacks_spl,
+#else
reserve_stacks,
+#endif
Why not just put the ifdef inside reserve_stacks()? Or at least give
them the same name?
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/2] Tegra: MMC: Add DT support to MMC driver for all T20 boards
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
On 02/08/2013 09:12:14 AM, Simon Glass wrote: This enables generic board support so that ppc boards can define CONFIG_SYS_GENERIC_BOARD. Signed-off-by: Simon Glass s...@chromium.org --- Changes in v5: None Changes in v4: None Changes in v3: None Changes in v2: None arch/powerpc/config.mk| 3 --- arch/powerpc/include/asm/u-boot.h | 7 +++ arch/powerpc/lib/Makefile | 2 ++ 3 files changed, 9 insertions(+), 3 deletions(-) diff --git a/arch/powerpc/config.mk b/arch/powerpc/config.mk index bf77090..b706281 100644 --- a/arch/powerpc/config.mk +++ b/arch/powerpc/config.mk @@ -29,9 +29,6 @@ PLATFORM_RELFLAGS += -fpic -mrelocatable -ffunction-sections -fdata-sections PLATFORM_CPPFLAGS += -DCONFIG_PPC -D__powerpc__ PLATFORM_LDFLAGS += -n -# Move to unified board system later -CONFIG_SYS_LEGACY_BOARD := y - # # When cross-compiling on NetBSD, we have to define __PPC__ or else we # will pick up a va_list declaration that is incompatible with the diff --git a/arch/powerpc/include/asm/u-boot.h b/arch/powerpc/include/asm/u-boot.h index 7229a98..951dd6a 100644 --- a/arch/powerpc/include/asm/u-boot.h +++ b/arch/powerpc/include/asm/u-boot.h @@ -34,6 +34,11 @@ * include/asm-ppc/u-boot.h */ +#ifdef CONFIG_SYS_GENERIC_BOARD +/* Use the generic board which requires a unified bd_info */ +#include asm-generic/u-boot.h +#else Note that a unified bd_info means you're breaking compatibility with old, pre-device-tree kernels (including possibly some non-Linux OSes that still don't use the device tree) -- in which case why keep it around at all? If you meant for the unified bd_info to be backwards compatible, it's missing bi_ip_addr. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] Tegra: fdt: Add/enhance sdhci (mmc) nodes for all T20 DT files
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.
On Fri, Nov 30, 2012 at 08:01:12PM +0200, Pantelis Antoniou wrote: We didn't support upload/download larger than available memory. This is pretty bad when you have to update your root filesystem for example. This patch removes the limitation (and the crashes when you transfered any file larger than 4MB). On top of that reduces the huge dfu buffer from 4MB to just 64K, which was over the top. The sequence number is a 16 bit counter; make sure we handle rollover correctly. This fixes the wrong transfers for large ( 256MB) images. Also utilize a variable to handle initialization, so that we don't rely on just the counter sent by the host. Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com To be clear, patches 1-8 are good and we should take, but this one means we can't use FAT/EXT* partitions without more work. I would suggest that we set this part aside for a moment and perhaps limit transfers that are larget than RAM to RAW only where we can write in chunks today. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] Tegra: fdt: Add/enhance sdhci (mmc) nodes for all T20 DT files
Stephen,
On Tue, Feb 12, 2013 at 1:29 PM, Stephen Warren swar...@wwwdotorg.org wrote:
On 02/11/2013 10:17 AM, Tom Warren wrote:
Linux dts files were used for those boards that didn't already
have sdhci info populated. Tamonten has their own dtsi file with
common sdhci nodes (sourced from Linux).
diff --git a/board/nvidia/dts/tegra20-seaboard.dts
b/board/nvidia/dts/tegra20-seaboard.dts
sdhci@c8000400 {
+ status = okay;
cd-gpios = gpio 69 0; /* gpio PI5 */
wp-gpios = gpio 57 0; /* gpio PH1 */
- power-gpios = gpio 70 0; /* gpio PI6 */
+ power-gpios = gpio 70 3; /* gpio PI6 */
+ bus-width = 4;
};
The 3 for the power-gpios flags looks odd, and doesn't match the
kernel. The binding only defines bit 0 for inverted, and doesn't define
bit 1.
That came from our internal U-Boot repo - don't know why it's setting
it as an output and asserted and no other Seaboard DT file does. I'll
look into it.
Thanks
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/2] Tegra: MMC: Add DT support to MMC driver for all T20 boards
Stephen,
On Tue, Feb 12, 2013 at 1:38 PM, Stephen Warren swar...@wwwdotorg.org wrote:
On 02/11/2013 10:17 AM, Tom Warren wrote:
tegra_mmc_init() now parses the DT info for bus width, WP/CD GPIOs, etc.
Tested on Seaboard, fully functional.
Tamonten boards (medcom-wide, plutux, and tec) use a different/new
dtsi file w/common settings.
diff --git a/drivers/mmc/tegra_mmc.c b/drivers/mmc/tegra_mmc.c
+static int process_nodes(const void *blob, int node_list[], int count)
...
+ /* build mmc_host[] for each controller */
+ for (i = 0; i count; i++) {
...
+ /* Mark position as used */
+ node_list[i] = -1;
Is that needed? Does anything use that array after this function?
No idea. I took this code from the tegra_i2c.c driver.
diff --git a/include/configs/medcom-wide.h b/include/configs/medcom-wide.h
diff --git a/include/configs/plutux.h b/include/configs/plutux.h
diff --git a/include/configs/tec.h b/include/configs/tec.h
In all 3 of those files ...
#define CONFIG_DEFAULT_DEVICE_TREE tegra20-medcom-wide
Why not change that define ...
#define CONFIG_OF_CONTROL
#define CONFIG_OF_SEPARATE
+#undef CONFIG_ARCH_DEVICE_TREE
+#define CONFIG_ARCH_DEVICE_TREE tegra20-tamonten
rather than adding that one? All the other Tegra boards only set
CONFIG_DEFAULT_DEVICE_TREE.
CONFIG_DEFAULT_DEVICE_TREE is the .dts file (board/nvidia/dts).
CONFIG_ARCH_DEVICE_TREE is the .dtsi file (arch/arm/dts). See
Thierry's explanation, also.
Aside from the few comments I and others have made, this series looks good.
Thanks. Working on V3.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/2] Tegra: MMC: Add DT support to MMC driver for all T20 boards
On 02/12/2013 01:57 PM, Tom Warren wrote: Stephen, On Tue, Feb 12, 2013 at 1:38 PM, Stephen Warren swar...@wwwdotorg.org wrote: On 02/11/2013 10:17 AM, Tom Warren wrote: tegra_mmc_init() now parses the DT info for bus width, WP/CD GPIOs, etc. Tested on Seaboard, fully functional. Tamonten boards (medcom-wide, plutux, and tec) use a different/new dtsi file w/common settings. diff --git a/include/configs/medcom-wide.h b/include/configs/medcom-wide.h diff --git a/include/configs/plutux.h b/include/configs/plutux.h diff --git a/include/configs/tec.h b/include/configs/tec.h In all 3 of those files ... #define CONFIG_DEFAULT_DEVICE_TREE tegra20-medcom-wide Why not change that define ... #define CONFIG_OF_CONTROL #define CONFIG_OF_SEPARATE +#undef CONFIG_ARCH_DEVICE_TREE +#define CONFIG_ARCH_DEVICE_TREE tegra20-tamonten rather than adding that one? All the other Tegra boards only set CONFIG_DEFAULT_DEVICE_TREE. CONFIG_DEFAULT_DEVICE_TREE is the .dts file (board/nvidia/dts). CONFIG_ARCH_DEVICE_TREE is the .dtsi file (arch/arm/dts). See Thierry's explanation, also. So why set CONFIG_ARCH_DEVICE_TREE to tegra20-tamonten here; if that variable is supposed to point at the SoC .dtsi file, that value is wrong; it *should* be tegra20.dtsi. Oh yuck. I see what's going on now. e.g. tegra20-medcom-wide.dts is including ARCH_CPU_DTS. It should be including tegra20-tamonten.dtsi, which then includes ARCH_CPU_DTS. The ARCH_CPU_DTS variable is supposed to only ever point at the SoC .dtsi file, not any intermediate .dtsi file... You probably need to put tegra20-tamonten.dtsi into board/avionic-design/dts rather than arch/arm/dts to make that work. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [GIT PULL] u-boot-mips/next
-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
+Albert
Hi Scott,
On Tue, Feb 12, 2013 at 12:29 PM, Scott Wood scottw...@freescale.com wrote:
On 02/08/2013 09:12:08 AM, Simon Glass wrote:
This adds secondary program loader support to the generic board.
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None
common/board_f.c | 20
1 file changed, 20 insertions(+)
diff --git a/common/board_f.c b/common/board_f.c
index aa10f4b..3a8036f 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -309,6 +309,7 @@ static int reserve_uboot(void)
return 0;
}
+#ifndef CONFIG_SPL_BUILD
/* reserve memory for malloc() area */
static int reserve_malloc(void)
{
@@ -328,6 +329,7 @@ static int reserve_board(void)
sizeof(bd_t), gd-dest_addr_sp);
return 0;
}
+#endif
static int setup_machine(void)
{
@@ -365,6 +367,7 @@ static int reserve_fdt(void)
return 0;
}
+#ifndef CONFIG_SPL_BUILD
static int reserve_stacks(void)
{
/* setup stack pointer for exceptions */
@@ -384,6 +387,17 @@ static int reserve_stacks(void)
return 0;
}
+#endif
+
+#ifdef CONFIG_SPL_BUILD
+static int reserve_stacks_spl(void)
+{
+ /* Why not -= ? */
+ gd-dest_addr_sp += 128;/* leave 32 words for abort-stack
*/
+ gd-irq_sp = gd-dest_addr_sp;
+ return 0;
+}
+#endif
abort-stack doesn't sound very generic, and that why not question should
probably be answered.
I'm not sure what you mean by the first comment. For the second, I
agree. It looks wrong to me. I copied Albert who might know.
static int display_new_sp(void)
{
@@ -524,12 +538,18 @@ static init_fnc_t init_sequence_f[] = {
reserve_lcd,
#endif
reserve_uboot,
+#ifndef CONFIG_SPL_BUILD
reserve_malloc,
reserve_board,
+#endif
setup_machine,
reserve_global_data,
reserve_fdt,
+#ifdef CONFIG_SPL_BUILD
+ reserve_stacks_spl,
+#else
reserve_stacks,
+#endif
Why not just put the ifdef inside reserve_stacks()? Or at least give them
the same name?
OK I will do that.
-Scott
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [GIT PULL] u-boot-mips/next
2013/2/12 Tom Rini tr...@ti.com: To be clear, is this for master or next? The merge window closed, but I haven't tagged -rc1 or anything yet (and won't for a bit longer, to give folks time to pick up patches). Thanks! it is for master. I needed a few days longer for review and test. Also I didn't want to rebase the u-boot-mips/master branch so I used next. -- Best regards, Daniel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 18/23] ppc: Enable generic board support
Hi Scott, On Tue, Feb 12, 2013 at 12:38 PM, Scott Wood scottw...@freescale.com wrote: On 02/08/2013 09:12:14 AM, Simon Glass wrote: This enables generic board support so that ppc boards can define CONFIG_SYS_GENERIC_BOARD. Signed-off-by: Simon Glass s...@chromium.org --- Changes in v5: None Changes in v4: None Changes in v3: None Changes in v2: None arch/powerpc/config.mk| 3 --- arch/powerpc/include/asm/u-boot.h | 7 +++ arch/powerpc/lib/Makefile | 2 ++ 3 files changed, 9 insertions(+), 3 deletions(-) diff --git a/arch/powerpc/config.mk b/arch/powerpc/config.mk index bf77090..b706281 100644 --- a/arch/powerpc/config.mk +++ b/arch/powerpc/config.mk @@ -29,9 +29,6 @@ PLATFORM_RELFLAGS += -fpic -mrelocatable -ffunction-sections -fdata-sections PLATFORM_CPPFLAGS += -DCONFIG_PPC -D__powerpc__ PLATFORM_LDFLAGS += -n -# Move to unified board system later -CONFIG_SYS_LEGACY_BOARD := y - # # When cross-compiling on NetBSD, we have to define __PPC__ or else we # will pick up a va_list declaration that is incompatible with the diff --git a/arch/powerpc/include/asm/u-boot.h b/arch/powerpc/include/asm/u-boot.h index 7229a98..951dd6a 100644 --- a/arch/powerpc/include/asm/u-boot.h +++ b/arch/powerpc/include/asm/u-boot.h @@ -34,6 +34,11 @@ * include/asm-ppc/u-boot.h */ +#ifdef CONFIG_SYS_GENERIC_BOARD +/* Use the generic board which requires a unified bd_info */ +#include asm-generic/u-boot.h +#else Note that a unified bd_info means you're breaking compatibility with old, pre-device-tree kernels (including possibly some non-Linux OSes that still don't use the device tree) -- in which case why keep it around at all? It's not intended to break things - are you saying that every arch is defined to use a different variant of bd_t in these OSes, or are you just referring to PPC? If you meant for the unified bd_info to be backwards compatible, it's missing bi_ip_addr. OK, I see. I saw a commit that punted it, so I punted it. I didn't notice the re-add later. I will put it back. Regards, Simon -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 16/23] Adjust board_f.c for ppc
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
On 02/12/2013 04:23:21 PM, Simon Glass wrote:
+Albert
Hi Scott,
On Tue, Feb 12, 2013 at 12:29 PM, Scott Wood
scottw...@freescale.com wrote:
On 02/08/2013 09:12:08 AM, Simon Glass wrote:
This adds secondary program loader support to the generic board.
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None
common/board_f.c | 20
1 file changed, 20 insertions(+)
diff --git a/common/board_f.c b/common/board_f.c
index aa10f4b..3a8036f 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -309,6 +309,7 @@ static int reserve_uboot(void)
return 0;
}
+#ifndef CONFIG_SPL_BUILD
/* reserve memory for malloc() area */
static int reserve_malloc(void)
{
@@ -328,6 +329,7 @@ static int reserve_board(void)
sizeof(bd_t), gd-dest_addr_sp);
return 0;
}
+#endif
static int setup_machine(void)
{
@@ -365,6 +367,7 @@ static int reserve_fdt(void)
return 0;
}
+#ifndef CONFIG_SPL_BUILD
static int reserve_stacks(void)
{
/* setup stack pointer for exceptions */
@@ -384,6 +387,17 @@ static int reserve_stacks(void)
return 0;
}
+#endif
+
+#ifdef CONFIG_SPL_BUILD
+static int reserve_stacks_spl(void)
+{
+ /* Why not -= ? */
+ gd-dest_addr_sp += 128;/* leave 32 words for
abort-stack
*/
+ gd-irq_sp = gd-dest_addr_sp;
+ return 0;
+}
+#endif
abort-stack doesn't sound very generic, and that why not
question should
probably be answered.
I'm not sure what you mean by the first comment.
It's ARM-specific terminology (exception is more typical than abort
elsewhere). Why 32 words, BTW? Why is it larger in SPL versus non-SPL?
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] Tegra: MMC: Add DT support to MMC driver for all T20 boards
Hi Stephen,
On Tue, Feb 12, 2013 at 12:13 PM, Stephen Warren swar...@wwwdotorg.org wrote:
On 02/12/2013 11:07 AM, Simon Glass wrote:
Hi,
On Tue, Feb 5, 2013 at 1:02 PM, Tom Warren twarren.nvi...@gmail.com wrote:
Stephen,
On Tue, Feb 5, 2013 at 1:03 PM, Stephen Warren swar...@wwwdotorg.org
wrote:
On 02/04/2013 04:48 PM, Tom Warren wrote:
tegra_mmc_init() now uses DT info for bus width, WP/CD GPIOs, etc.
Tested on Seaboard, fully functional.
diff --git a/board/compal/paz00/paz00.c b/board/compal/paz00/paz00.c
index 1447f47..5cee91a 100644
--- a/board/compal/paz00/paz00.c
+++ b/board/compal/paz00/paz00.c
@@ -55,18 +55,18 @@ static void pin_mux_mmc(void)
/* this is a weak define that we are overriding */
int board_mmc_init(bd_t *bd)
{
- debug(board_mmc_init called\n);
+ debug(%s called\n, __func__);
/* Enable muxes, etc. for SDMMC controllers */
pin_mux_mmc();
- debug(board_mmc_init: init eMMC\n);
- /* init dev 0, eMMC chip, with 8-bit bus */
- tegra_mmc_init(0, 8, -1, -1);
+ debug(%s: init eMMC\n, __func__);
+ /* init dev 0, eMMC chip */
+ tegra_mmc_init(0);
- debug(board_mmc_init: init SD slot\n);
- /* init dev 3, SD slot, with 4-bit bus */
- tegra_mmc_init(3, 4, GPIO_PV1, GPIO_PV5);
+ debug(%s: init SD slot\n, __func__);
+ /* init dev 3, SD slot */
+ tegra_mmc_init(3);
return 0;
}
That doesn't look right. The board code still has knowledge of which
SDHCI controllers are in use by the board. Instead, the board should
just call tegra_mmc_init() with no parameters at all, and the MMC driver
should scan the device tree for all present-and-enabled SDHCI nodes, and
instantiate a U-Boot SDHCI device. Without this, the device tree isn't
in control of the whole process, so there's little point doing the
conversion; a new board couldn't be supported /just/ by creating a new
device tree file.
diff --git a/drivers/mmc/tegra_mmc.c b/drivers/mmc/tegra_mmc.c
+#ifndef CONFIG_OF_CONTROL
+#error Please enable device tree support to use this driver
+#endif
So CONFIG_OF_CONTROL must be enabled ...
static void tegra_get_setup(struct mmc_host *host, int dev_index)
{
- debug(tegra_get_setup: dev_index = %d\n, dev_index);
+ debug(%s: dev_index = %d\n, __func__, dev_index);
+
+#ifdef CONFIG_OF_CONTROL
... so there's no need for that ifdef
I took Allen's recent SPI/SLINK driver(s) as an example, but as you
point out, if CONFIG_OF_CONTROL isn't enabled, you get build errors
anyway.
+ int count, node = 0;
+ int node_list[MAX_HOSTS];
+
+ count = fdtdec_find_aliases_for_id(gd-fdt_blob, sdmmc,
+ COMPAT_NVIDIA_TEGRA20_SDMMC, node_list, MAX_HOSTS);
+ debug(%s: count of nodes is %d\n, __func__, count);
+
+ if (count dev_index) {
+ printf(%s: device index %d exceeds node count (%d)!\n,
+ __func__, dev_index, count);
+ return;
+ }
This requires that an alias exist in order for the SDHCI node to be
found/processed. This isn't correct; the SDHCI nodes must be enumerated
themselves, and then the aliases (if any are present) provide a naming
hint for them, but even without aliases, the SDHCI nodes must be processed.
Again, I used Allen's SLINK driver for as a template here. In fact, it
looks like our I2C and SPI/SLINK drivers do this, as well as the
Exynos SPI and S3C24x0 I2C driver all do this. Can you point out a
U-Boot driver that does it the right way (preferably with more than 1
node, like MMC)? I can take a look at that code to use as an example
of what you're proposing above.
You have it correct already. Stephen please take another look and let
me know what problem you see with this approach. I'm very sorry that I
am so late to this discussion.
Could you explain how this works then? The code I looked at (a) was
driven by board files not DT enumerationk (b) errored out if no alias ID
was present.
But given there's a V2, I'll go look at that and check again.
I'm really talking about the function fdtdec_add_aliases_for_id(). It
is designed to do exactly what you wanted, from memory, except that it
only supports a single compatible ID. If there is no alias node, then
it should still find all the compatible nodes. The alias node is only
used to order them.
In terms of being driver by board files, it is best if the drivers do
this, so that the enumeration is independent of any board file.
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
