Re: [U-Boot] [PATCH] powerpc/p2041: skip waiting for SERDES bank 3 reset done
Hello, On Thu, 24 Jan 2013 09:03:11 +0100 Anatolij Gustschin ag...@denx.de wrote: Hello, On Thu, 24 Jan 2013 02:33:31 + Xie Shaohui-B21989 b21...@freescale.com wrote: ... currently I do not have access to the p2041rdb board, but here is the previously captured boot log where I've seen this: U-Boot 2011.09-0-g2c02d1d (Oct 22 2011 - 18:31:36) [S.H] Did you try the latest U-boot? This u-boot is old. I don't see the time out dump with the latest U-boot. I'm not sure which exact version I've tried, IIRC it was v2013-rcX and the problem was there also. I'll have access to the p2041rdb board tomorrow and will tell which exact version it was. It was the version 2013.01-rc1-00258-gce12a8c. Now I updated to v2013.01 and do not see the issue any more. This patch is not needed then. Sorry for the noise. Thanks, Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] powerpc/lib: unsafe register handling in wait_ticks
Wolfgang Denk w...@denx.de wrote on 2013/01/24 20:27:26: Dear Joakim Tjernlund, In message OF52C94A3D.C3BD2E6F-ONC1257AFD.005BAFE0-C1257AFD. 00673...@transmode.se you wrote: This adds some extra churn to the code that my patch didn't do. On the other hand your patch makes the function look more like how gcc would have done so I am fine with that. However, I am not sure r14 is a good fit, I cannot remember if there is some special purpose for r14. Hopefully somebody on the list knows. This is documented in the README: | For PowerPC, the following registers have specific use: |R1: stack pointer |R2: reserved for system use |R3-R4: parameter passing and return values |R5-R10: parameter passing |R13: small data area pointer |R30: GOT pointer |R31: frame pointer | |(U-Boot also uses R12 as internal GOT pointer. r12 |is a volatile register so r12 needs to be reset when |going back and forth between asm and C) | | == U-Boot will use R2 to hold a pointer to the global data | Right, then I think the patch is good: Acked-by: Joakim Tjernlund joakim.tjernl...@transmode.se ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] console: Improve TFTP booting performance
Dear Jim Lin, In message 1359097425-20517-1-git-send-email-ji...@nvidia.com you wrote: TFTP booting is observed a little bit slow, especially when a USB keyboard is installed. The fix is to check whether Ctrl-C key is pressed every CONFIG_CTRLC_POLL_MS ms. If CONFIG_CTRLC_POLL_MS is not defined in configuration file, we define it as 1000. CONFIG_* variables MUST be documented in the README. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de f u cn rd ths, itn tyg h myxbl cd. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] console: Improve TFTP booting performance
Dear Jim Lin, In message 1359097425-20517-1-git-send-email-ji...@nvidia.com you wrote: TFTP booting is observed a little bit slow, especially when a USB keyboard is installed. The fix is to check whether Ctrl-C key is pressed every CONFIG_CTRLC_POLL_MS ms. If CONFIG_CTRLC_POLL_MS is not defined in configuration file, we define it as 1000. ...also: +#ifndef CONFIG_CTRLC_POLL_MS +/* + * Process Ctrl-C every 1000 ms by default to improve performance + * (like TFTP boot) when interlaced with other tasks. + */ +#define CONFIG_CTRLC_POLL_MS 1000 +#endif +static unsigned long ctrlc_ts = CONFIG_CTRLC_POLL_MS; Don't set such a default. If this is good for you, OK. But for all others, the behaviour should not change at all. Also, are you positively sure that your callto get_timer() does not mess up with other timers in the network subsystem? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de You're too beautiful to ignore. Too much woman. -- Kirk to Yeoman Rand, The Enemy Within, stardate unknown ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] access u-boot environment variables from kernel space
Dear Manukumar, In message 1359096605.2559.15.camel@Manukumar you wrote: I have to implement the jtag and execute XSVF file through diagnostic command from u-boot. the layout of our board as below: What exactly has this to do with above thread and with the access u-boot environment variables from kernel space subject? And why exactly did you put all these people on Cc: ??? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The White Rabbit put on his spectacles. Where shall I begin, please your Majesty ? he asked. Begin at the beginning,, the King said, very gravely, and go on till you come to the end: then stop.-- Lewis Carroll ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] usb:composite: USB Mass Storage - f_mass_storage.c from Linux kernel
Dear Marek Vasut, -Original Message- From: Marek Vasut [mailto:ma...@denx.de] Sent: Thursday, January 24, 2013 1:34 PM To: Piotr Wilczek Cc: u-boot@lists.denx.de; Minkyu Kang; Kyungmin Park; Lukasz Majewski; Tom Rini Subject: Re: [PATCH 2/4] usb:composite: USB Mass Storage - f_mass_storage.c from Linux kernel Dear Piotr Wilczek, The f_mass_storage.c source file from v2.6.36 Linux kernel. commit 8876f5e7d3b2a320777dd4f6f5301d474c97a06c Author: Michal Nazarewicz m.nazarew...@samsung.com Date: Mon Jun 21 13:57:09 2010 +0200 USB: gadget: f_mass_storage: added eject callback 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 Why is there so much code that's crudely commented out, like in the synchronize_cache function? I remove it in v2 Best regards, Marek Vasut Best regards, Piotr Wilczek --- Samsung RD Poland (SRPOL) | Linux Platform Group ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] usb:gadget: USB Mass Storage Gadget support
Dear Marek Vasut,
-Original Message-
From: Marek Vasut [mailto:ma...@denx.de]
Sent: Thursday, January 24, 2013 1:35 PM
To: Piotr Wilczek
Cc: u-boot@lists.denx.de; Minkyu Kang; Kyungmin Park; Lukasz Majewski;
Tom Rini
Subject: Re: [PATCH 3/4] usb:gadget: USB Mass Storage Gadget support
Dear Piotr Wilczek,
From: Lukasz Majewski l.majew...@samsung.com
This patch adds the USB Mass Storage Gadget to u-boot New command
called ums is implemented to provide access to on-device embedded
persistent memory.
USB Mass Storage is supposed to work on top of the USB Gadget
framework
Signed-off-by: Lukasz Majewski l.majew...@samsung.com
Signed-off-by: Piotr Wilczek p.wilc...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
CC: Marek Vasut marek.va...@gmail.com
---
common/Makefile |1 +
common/cmd_usb_mass_storage.c | 85
+ drivers/usb/gadget/g_dnl.c
|
6 +++
include/usb_mass_storage.h| 59
4 files changed, 151 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..bc5b239
--- /dev/null
+++ b/common/cmd_usb_mass_storage.c
@@ -0,0 +1,85 @@
+/*
+ * 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();
+
+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;
Re: [U-Boot] [PATCH 1/4] usb:composite: USB Mass Storage - storage_common.c from Linux kernel
Dear Marek Vasut, -Original Message- From: Marek Vasut [mailto:ma...@denx.de] Sent: Thursday, January 24, 2013 1:33 PM To: Piotr Wilczek Cc: u-boot@lists.denx.de; Minkyu Kang; Kyungmin Park; Lukasz Majewski; Tom Rini; Andrzej Pietrasiewicz Subject: Re: [PATCH 1/4] usb:composite: USB Mass Storage - storage_common.c from Linux kernel Dear Piotr Wilczek, From: Lukasz Majewski l.majew...@samsung.com The storage_common.c source file from v2.6.36 Linux kernel. Is it not possibly to port anything more recent? If not, so be it. The reason was to use the simplest and tested version. Best regards, Marek Vasut Best regards, Piotr Wilczek --- Samsung RD Poland (SRPOL) | Linux Platform Group ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5 2/2] board: add support for amcore board
Add support for Sysam AMCORE mcf5307 (coldfire) based board.
Signed-off-by: Angelo Dureghello sysa...@gmail.com
Cc: Jason Jin jason@freescale.com
---
Changes for v2:
- None
Changes for v3:
- Fix code format issues
Changes for v4:
- Add MAINTAINERS file entry
- Remove all unnecessary blank lines
- Add get_ram_size in sdram init
- Reuse already existing sdram test routine
- Remove custom flash.c, used std mtd/CFI driver
Changes for v5:
- Fix MAINTAINERS bad sorted entry
- Fix incorrect indentation
- Remove #undef where not needed
- Fix CONFIG_SYS_SDRAM_SIZE to be in bytes
---
MAINTAINERS|4 +
board/sysam/amcore/Makefile| 43 ++
board/sysam/amcore/amcore.c| 159 +
board/sysam/amcore/config.mk | 23 +++
board/sysam/amcore/u-boot.lds | 101 ++
boards.cfg |1 +
include/configs/amcore.h | 209 +++
7 files changed, 540 insertions(+), 0 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 28c052d..f3a6d39 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -149,6 +149,10 @@ Wolfgang Denk w...@denx.de
PCIPPC2 MPC750
PCIPPC6 MPC750
+Angelo Dureghello sysa...@gmail.com
+
+amcore mcf5307
+
Phil Edworthy phil.edwor...@renesas.com
rsk7264 SH7264
diff --git a/board/sysam/amcore/Makefile b/board/sysam/amcore/Makefile
new file mode 100644
index 000..1fd25a8
--- /dev/null
+++ b/board/sysam/amcore/Makefile
@@ -0,0 +1,43 @@
+#
+# Copyright (c) 2011 Angelo Dureghello sysa...@gmail.com
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+# MA 02111-1307 USA
+#
+
+include $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(BOARD).o
+
+COBJS = $(BOARD).o
+
+SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
+OBJS := $(addprefix $(obj),$(COBJS))
+SOBJS := $(addprefix $(obj),$(SOBJS))
+
+$(LIB):$(obj).depend $(OBJS)
+ $(call cmd_link_o_target, $(OBJS))
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/sysam/amcore/amcore.c b/board/sysam/amcore/amcore.c
new file mode 100644
index 000..53ef1f5
--- /dev/null
+++ b/board/sysam/amcore/amcore.c
@@ -0,0 +1,159 @@
+/*
+ * Copyright (c) 2012 Angelo Dureghello sysa...@gmail.com
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ *
+ * Copy memory testdram() from sandburst/common/sb_common.c
+ */
+
+#include common.h
+#include asm/immap.h
+#include asm/io.h
+
+void init_lcd(void)
+{
+ /*
+* board can have a K0108 lcd connected on the parallel port,
+* wired as below:
+*
+* fc cpu P0 P1 P2 P3 P4 P5 P6 P7 P10 P11 P12 P13 P14
+* lcd D0 D1 D2 D3 D4 D5 D6 D7 CS1 CS2 RW DI E
+*
+* Starting up setting lines in high impedance
+*/
+ sim_t *sim = (sim_t *)(MMAP_SIM);
+
+ out_be16(sim-par, 0x300);
+
+ gpio_t *gpio = (gpio_t *)(MMAP_GPIO);
+
+ out_be16(gpio-paddr, 0xfcff);
+ out_be16(gpio-padat, 0x0c00);
+}
+
+int checkboard(void)
+{
+ puts(Board: );
+ puts(AMCORE v.001(alpha)\n);
+
+ init_lcd();
+
+ return 0;
+}
+
+/*
+ * in initdram we are here executing from flash
+ * case 1:
+ * is with no ACR/flash cache enabled
+ * nop = 40ns (scope measured)
+ */
Re: [U-Boot] [PATCH v2] integrator: pass a Device Tree by default
Dear Linus Walleij, This, enabled the FDT library for the Integrators, updates the Integrator/CP default command to load and pass a Device Tree when booting the kernel from the on-board ethernet, define same environment for the Integrator/AP and move the load address around to something even. Signed-off-by: Linus Walleij linus.wall...@linaro.org --- ChangeLog v1-v2: - Skip definition of $loadaddr, rely on CONFIG_LOAD_ADDR instead. --- include/configs/integrator-common.h | 3 ++- include/configs/integratorap.h | 7 +-- include/configs/integratorcp.h | 9 ++--- 3 files changed, 13 insertions(+), 6 deletions(-) diff --git a/include/configs/integrator-common.h b/include/configs/integrator-common.h index 564b418..f4a182c 100644 --- a/include/configs/integrator-common.h +++ b/include/configs/integrator-common.h @@ -30,7 +30,7 @@ #define CONFIG_SYS_MEMTEST_END 0x1000 #define CONFIG_SYS_HZ1000 #define CONFIG_SYS_TIMERBASE 0x13000100 /* Timer1 */ -#define CONFIG_SYS_LOAD_ADDR 0x7fc0 /* default load address */ +#define CONFIG_SYS_LOAD_ADDR 0x800 /* default load address */ #define CONFIG_SYS_LONGHELP #define CONFIG_SYS_HUSH_PARSER #define CONFIG_SYS_CBSIZE256 /* Console I/O Buffer Size*/ @@ -41,6 +41,7 @@ #define CONFIG_CMDLINE_TAG /* enable passing of ATAGs */ #define CONFIG_SETUP_MEMORY_TAGS +#define CONFIG_OF_LIBFDT /* enable passing a Device Tree */ #define CONFIG_MISC_INIT_R /* call misc_init_r during start up */ /* diff --git a/include/configs/integratorap.h b/include/configs/integratorap.h index c6907b5..f409f2a 100644 --- a/include/configs/integratorap.h +++ b/include/configs/integratorap.h @@ -62,9 +62,12 @@ */ #include config_cmd_default.h -#define CONFIG_BOOTDELAY 2 +#define CONFIG_BOOTDELAY 0 #define CONFIG_BOOTARGS root=/dev/mtdblock0 console=ttyAM0 console=tty -#define CONFIG_BOOTCOMMAND +#define CONFIG_BOOTCOMMAND setenv servip 192.168.1.100 ; \ + setenv fdtaddr 0x0080 ; \ + echo \$loadaddr = $loadaddr, $fdtaddr=$fdtaddr\ ; \ + echo \load binaries then: bootm $loadaddr - $fdtaddr\ /* * Miscellaneous configurable options diff --git a/include/configs/integratorcp.h b/include/configs/integratorcp.h index ca02a6f..9446edb 100644 --- a/include/configs/integratorcp.h +++ b/include/configs/integratorcp.h @@ -60,11 +60,14 @@ #include config_cmd_default.h #define CONFIG_BOOTDELAY 2 -#define CONFIG_BOOTARGS root=/dev/mtdblock0 console=ttyAMA0 console=tty ip=dhcp netdev=27,0,0xfc80,0xfc800010,eth0 video=clcdfb:0 -#define CONFIG_BOOTCOMMAND tftpboot ; bootm #define CONFIG_SERVERIP 192.168.1.100 #define CONFIG_IPADDR 192.168.1.104 -#define CONFIG_BOOTFILE uImage +#define CONFIG_BOOTARGS root=/dev/mtdblock0 console=ttyAMA0 console=tty ip=dhcp netdev=27,0,0xfc80,0xfc800010,eth0 video=clcdfb:0 +#define CONFIG_BOOTCOMMAND setenv servip 192.168.1.100 ; \ + setenv fdtaddr 0x0080 ; \ + bootp $loadaddr $servip:uImage ; \ + bootp $fdtaddr $servip:integratorcp.dtb ; \ + bootm $loadaddr - $fdtaddr Do you mean to use serverip here? Since serverip is the IP of the TFTP server and it's used across uboot. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] usb:composite: USB Mass Storage - storage_common.c from Linux kernel
Dear Piotr Wilczek, Dear Marek Vasut, -Original Message- From: Marek Vasut [mailto:ma...@denx.de] Sent: Thursday, January 24, 2013 1:33 PM To: Piotr Wilczek Cc: u-boot@lists.denx.de; Minkyu Kang; Kyungmin Park; Lukasz Majewski; Tom Rini; Andrzej Pietrasiewicz Subject: Re: [PATCH 1/4] usb:composite: USB Mass Storage - storage_common.c from Linux kernel Dear Piotr Wilczek, From: Lukasz Majewski l.majew...@samsung.com The storage_common.c source file from v2.6.36 Linux kernel. Is it not possibly to port anything more recent? If not, so be it. The reason was to use the simplest and tested version. Nevermind my dumb comment, I took a peek and figured as much as that we're stuck with .36-ish gadget framework. Now, completely unrelated question, but since you're the expert at these things, I'll just fire it at you -- do you think porting serial gadget would be too hard? Apparently the CONFIG_USB_TTY is a junk and with the new gadget drivers, this won't work, thus we need new usb-serial-gadget driver. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Want to study U-Boot code
Dear Woody Wu, On Fri, Jan 25, 2013 at 12:30:43AM +0100, Marek Vasut wrote: Dear Woody Wu, Hi, List Is there a book or web document to help start to understand how U-Boot works? There's a doc/ directory in the u-boot sourcecode. Is there a guide/suggestion to the reading order of these docs? You know, there is not a index file. Thanks. The question is -- what do you want to do? If Study u-boot code is the answer, just dive in ;-) Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] mmc:fix: Increase the timeout value for SDHCI_send_command()
Hi, On Fri, Jan 11, 2013 at 8:49 PM, Lukasz Majewski l.majew...@samsung.com wrote: Hi Wolfgang, Dear Lukasz Majewski, In message 1357665792-8141-1-git-send-email-l.majew...@samsung.com you wrote: I'd like to ask for your opinion about the following problem: I cannot comment on the problem - only a bit about the proposed patch ;-) From a brief checking I can say that it happens when we are doing consecutive MMC operations (i.e. many reads), and the 10ms timeout might be too short when eMMC firmware is forced to do some internal time consuming operations (e.g. flash blocks management, wear leveling). In this situation, the SDHCI_CMD_INHIBIT bit is set, which means that SDHCI controller didn't received response from eMMC. One proposition would be to define the per device/per memory chip specific timeouts, to replace those defined at ./drivers/mmc/sdhci.c file. Is there no way to ask the device and/or controller when it is done, so we can poll for ready state instead of adding delays, which will always have to be tailored for the so far known worst case, i. e. they will be always too long on all almost all systems. We are doing this already - the SDHCI_PRESENT_STATE register's bit 0 (SDHCI_CMD_INHIBIT) and bit 1 (DATA_INHIBIT) are for this purpose. Those indicate when host controller can send further command/data to the card. Moreover, there are also timeouts in the case when someone pull out SD card inserted to the slot (or any other use case which I'm not aware). --- a/drivers/mmc/sdhci.c +++ b/drivers/mmc/sdhci.c @@ -137,8 +137,8 @@ int sdhci_send_command(struct mmc *mmc, struct mmc_cmd *cmd, unsigned int timeout, start_addr = 0; unsigned int retry = 1; - /* Wait max 10 ms */ - timeout = 10; + /* Wait max 100 ms */ + timeout = 100; We have cases where we struggle for sub-second boot times. Adding 100 ms delay here is clearly prohbitive. [Even the 10 ms are way too long IMHO.] There must be a better way to handle this. That's why I'm asking. It is strange that, when I'm increasing delay it works. Maybe we will find some areas of optimization? BTW: I am also finding the similar issue. But when I enabled CONFIG_MMC_TRACE for log traces, i never see the issue..it's pretty much working fine. As per my latest debug, the issue is fire for CMD6 (SWITCH_FUNC). May be we need to update the logic on this while loop... Thanks, Jagan. Best regards, Wolfgang Denk -- Best regards, Lukasz Majewski Samsung RD Poland (SRPOL) | Linux Platform Group ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 2/2] board: add support for amcore board
Dear Angelo Dureghello, In message 20130125104307.GA3223@sion.sysam you wrote: Add support for Sysam AMCORE mcf5307 (coldfire) based board. Sorry for the late catch - this escaped me so far... Changes for v5: - Fix MAINTAINERS bad sorted entry - Fix incorrect indentation - Remove #undef where not needed Did you? I still see some... +#if defined(CONFIG_SYS_DRAM_TEST) +/* memory test */ +int testdram(void) ... +#endif This is: 1) dead code, as you don't define CONFIG_SYS_DRAM_TEST 2) an obsolete approach that you should not use. We have a several different (and much more reliable) memory tests already - if yuou really need one, then please use the existing code. On the other hand, you are using get_ram_size, which already includes a simple memory test - so re you sure you really need an extra test? +#undef CONFIG_SYS_DRAM_TEST/* default undef */ == remove. +/* bypass PLL for test purpose */ +#undef CONFIG_SYS_PLL_BYPASS ??? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The light at the end of the tunnel is usually a No Exit sign. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mxs: mxsboot: Add support for SD card generation for i.MX23
On Thu, Jan 24, 2013 at 4:31 PM, Otavio Salvador ota...@ossystems.com.br wrote: I prefer to have this as is and share documentation with mx28. The NAND ought to be done providing same interface so one doc for it all. I think change it in next version is wrong and confuse users. Ping? We won't be able to get rid of mxsboot for NAND use-case so I'd prefer to have it for SD as well. For me it does not matter much as I use OE and it automates it all; but for ordinary user it is important to it to be consistent so all 'mxs' SoC would work same way from user point of view. If we find a better way of doing things in future we can base on this and improve it later but please let's get it in and move forward... -- 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
Re: [U-Boot] [PATCH] mxs: mxsboot: Add support for SD card generation for i.MX23
Dear Otavio Salvador, On Thu, Jan 24, 2013 at 4:31 PM, Otavio Salvador ota...@ossystems.com.br wrote: I prefer to have this as is and share documentation with mx28. The NAND ought to be done providing same interface so one doc for it all. I think change it in next version is wrong and confuse users. Ping? We won't be able to get rid of mxsboot for NAND use-case so I'd prefer to have it for SD as well. For me it does not matter much as I use OE and it automates it all; but for ordinary user it is important to it to be consistent so all 'mxs' SoC would work same way from user point of view. If we find a better way of doing things in future we can base on this and improve it later but please let's get it in and move forward... Does my proposed patch not work for you? (the one which shifts the bootstream payload to block 4 in partition 1) Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 2/2] board: add support for amcore board
Dear Wolfgang, thanks for the review, On Fri, Jan 25, 2013 at 01:30:54PM +0100, Wolfgang Denk wrote: Dear Angelo Dureghello, In message 20130125104307.GA3223@sion.sysam you wrote: Add support for Sysam AMCORE mcf5307 (coldfire) based board. Sorry for the late catch - this escaped me so far... Changes for v5: - Fix MAINTAINERS bad sorted entry - Fix incorrect indentation - Remove #undef where not needed Did you? I still see some... +#if defined(CONFIG_SYS_DRAM_TEST) +/* memory test */ +int testdram(void) ... +#endif This is: 1) dead code, as you don't define CONFIG_SYS_DRAM_TEST 2) an obsolete approach that you should not use. We have a several different (and much more reliable) memory tests already - if yuou really need one, then please use the existing code. On the other hand, you are using get_ram_size, which already includes a simple memory test - so re you sure you really need an extra test? +#undef CONFIG_SYS_DRAM_TEST/* default undef */ I used the sdram test for some help when soldering here the prototypes. Then i disabled the test. As you already asked me, i removed my own sdram test function and used one already used from other boards, and added this in the amcore.c top coments. * Copy memory testdram() from sandburst/common/sb_common.c Anyway, as you said, get_ram_size is enough for me. I will remove CONFIG_SYS_DRAM_TEST and so int testdram(void) content. == remove. +/* bypass PLL for test purpose */ +#undef CONFIG_SYS_PLL_BYPASS ??? I apologize, forget out, fixed. If you haven't seen anything else, i'll post next V6 shortly. Best Regards, Angelo Dureghello ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/7] tegra: usb: set USB_PORTS_MAX to correct value
Both Tegra20 and Tegra30 have a max of 3 USB controllers.
Signed-off-by: Lucas Stach d...@lynxeye.de
---
arch/arm/cpu/armv7/tegra20/usb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/cpu/armv7/tegra20/usb.c b/arch/arm/cpu/armv7/tegra20/usb.c
index 1bccf2b..f151fb2 100644
--- a/arch/arm/cpu/armv7/tegra20/usb.c
+++ b/arch/arm/cpu/armv7/tegra20/usb.c
@@ -44,7 +44,7 @@
#endif
enum {
- USB_PORTS_MAX = 4,/* Maximum ports we allow */
+ USB_PORTS_MAX = 3,/* Maximum ports we allow */
};
/* Parameters we need for USB */
--
1.8.0.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 0/7] Move Tegra EHCI drive to correct place
This moves out the Tegra EHCI driver from a platform specific directory
to the standard driver/usb/host dir.
This is a preparation needed to share this driver between Tegra20 and
Tegra30. No functional change in here, so Tegra30 is still not working.
Patch 6 could be a lot smaller if it were generated with -B, as GIT would
detect that most of it is moving stuff over, but last time I did this it
prevented git apply to work. So sorry for the big diff.
I think I incorporated all changes needed to reflect the review feedback
I got on this last time.
I expect this series to go in through the Tegra tree.
Lucas Stach (7):
tegra: usb: set USB_PORTS_MAX to correct value
tegra: usb: make controller init functions more self contained
tegra: usb: remove unneeded function parameter
tegra: usb: move controller init into start_port
tegra: usb: various small cleanups
tegra: usb: move implementation into right directory
tegra: usb: move [start|stop]_port into ehci_hcd_[init|stop]
arch/arm/cpu/armv7/tegra20/Makefile| 1 -
arch/arm/cpu/armv7/tegra20/usb.c | 567 -
.../include/asm/{arch-tegra20 = arch-tegra}/usb.h | 22 -
arch/arm/include/asm/arch-tegra20/tegra.h | 1 -
arch/arm/include/asm/arch-tegra30/tegra.h | 2 +
board/nvidia/common/board.c| 2 +-
drivers/usb/host/ehci-tegra.c | 546 +++-
7 files changed, 533 insertions(+), 608 deletions(-)
delete mode 100644 arch/arm/cpu/armv7/tegra20/usb.c
rename arch/arm/include/asm/{arch-tegra20 = arch-tegra}/usb.h (89%)
--
1.8.0.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 2/7] tegra: usb: make controller init functions more self contained
There is no need to pass around all those parameters. The init functions
are able to easily extract all the needed setup info on their own.
Signed-off-by: Lucas Stach d...@lynxeye.de
---
To clarify why this is a good thing an excerpt from the first round of
review:
The intent of this patch is not really to save up on parameters passed,
but to make it possible to later move out the controller initialization
into the ehci_hcd_init function without having to save away this global
state for later use[,thus avoid bloating the file global state].
---
arch/arm/cpu/armv7/tegra20/usb.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/arch/arm/cpu/armv7/tegra20/usb.c b/arch/arm/cpu/armv7/tegra20/usb.c
index f151fb2..07c1ade 100644
--- a/arch/arm/cpu/armv7/tegra20/usb.c
+++ b/arch/arm/cpu/armv7/tegra20/usb.c
@@ -198,11 +198,12 @@ void usbf_reset_controller(struct fdt_usb *config, struct
usb_ctlr *usbctlr)
}
/* set up the UTMI USB controller with the parameters provided */
-static int init_utmi_usb_controller(struct fdt_usb *config,
- struct usb_ctlr *usbctlr, const u32 timing[])
+static int init_utmi_usb_controller(struct fdt_usb *config)
{
u32 val;
int loop_count;
+ const unsigned *timing;
+ struct usb_ctlr *usbctlr = config-reg;
clock_enable(config-periph_id);
@@ -229,6 +230,8 @@ static int init_utmi_usb_controller(struct fdt_usb *config,
* PLL Delay CONFIGURATION settings. The following parameters control
* the bring up of the plls.
*/
+ timing = usb_pll[clock_get_osc_freq()];
+
val = readl(usbctlr-utmip_misc_cfg1);
clrsetbits_le32(val, UTMIP_PLLU_STABLE_COUNT_MASK,
timing[PARAM_STABLE_COUNT] UTMIP_PLLU_STABLE_COUNT_SHIFT);
@@ -331,12 +334,12 @@ static int init_utmi_usb_controller(struct fdt_usb
*config,
#endif
/* set up the ULPI USB controller with the parameters provided */
-static int init_ulpi_usb_controller(struct fdt_usb *config,
- struct usb_ctlr *usbctlr)
+static int init_ulpi_usb_controller(struct fdt_usb *config)
{
u32 val;
int loop_count;
struct ulpi_viewport ulpi_vp;
+ struct usb_ctlr *usbctlr = config-reg;
/* set up ULPI reference clock on pllp_out4 */
clock_enable(PERIPH_ID_DEV2_OUT);
@@ -408,8 +411,7 @@ static int init_ulpi_usb_controller(struct fdt_usb *config,
return 0;
}
#else
-static int init_ulpi_usb_controller(struct fdt_usb *config,
- struct usb_ctlr *usbctlr)
+static int init_ulpi_usb_controller(struct fdt_usb *config)
{
printf(No code to set up ULPI controller, please enable
CONFIG_USB_ULPI and CONFIG_USB_ULPI_VIEWPORT);
@@ -430,22 +432,20 @@ static void config_clock(const u32 timing[])
* @param config USB port configuration
* @return 0 if ok, -1 if error (too many ports)
*/
-static int add_port(struct fdt_usb *config, const u32 timing[])
+static int add_port(struct fdt_usb *config)
{
- struct usb_ctlr *usbctlr = config-reg;
-
if (port_count == USB_PORTS_MAX) {
printf(tegrausb: Cannot register more than %d ports\n,
USB_PORTS_MAX);
return -1;
}
- if (config-utmi init_utmi_usb_controller(config, usbctlr, timing)) {
+ if (config-utmi init_utmi_usb_controller(config)) {
printf(tegrausb: Cannot init port\n);
return -1;
}
- if (config-ulpi init_ulpi_usb_controller(config, usbctlr)) {
+ if (config-ulpi init_ulpi_usb_controller(config)) {
printf(tegrausb: Cannot init port\n);
return -1;
}
@@ -558,7 +558,7 @@ int board_usb_init(const void *blob)
return -1;
}
- if (add_port(config, usb_pll[freq]))
+ if (add_port(config))
return -1;
set_host_mode(config);
}
--
1.8.0.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 4/7] tegra: usb: move controller init into start_port
There is no need to init a USB controller before the upper layers indicate
that they are actually going to use it.
board_usb_init now only parses the device tree and sets up the common pll.
Signed-off-by: Lucas Stach d...@lynxeye.de
---
v2:
- remember if port is already initialized and skip init in that case
---
arch/arm/cpu/armv7/tegra20/usb.c | 57
1 file changed, 29 insertions(+), 28 deletions(-)
diff --git a/arch/arm/cpu/armv7/tegra20/usb.c b/arch/arm/cpu/armv7/tegra20/usb.c
index 2007483..e4165e0 100644
--- a/arch/arm/cpu/armv7/tegra20/usb.c
+++ b/arch/arm/cpu/armv7/tegra20/usb.c
@@ -79,6 +79,7 @@ struct fdt_usb {
unsigned ulpi:1;/* 1 if port has external ULPI transceiver */
unsigned enabled:1; /* 1 to enable, 0 to disable */
unsigned has_legacy_mode:1; /* 1 if this port has legacy mode */
+ unsigned initialized:1; /* has this port already been initialized? */
enum dr_mode dr_mode; /* dual role mode */
enum periph_id periph_id;/* peripheral id */
struct fdt_gpio_state vbus_gpio;/* GPIO for vbus enable */
@@ -426,44 +427,36 @@ static void config_clock(const u32 timing[])
timing[PARAM_CPCON], timing[PARAM_LFCON]);
}
-/**
- * Add a new USB port to the list of available ports.
- *
- * @param config USB port configuration
- * @return 0 if ok, -1 if error (too many ports)
- */
-static int add_port(struct fdt_usb *config)
+int tegrausb_start_port(int portnum, u32 *hccr, u32 *hcor)
{
- if (port_count == USB_PORTS_MAX) {
- printf(tegrausb: Cannot register more than %d ports\n,
- USB_PORTS_MAX);
+ struct fdt_usb *config;
+ struct usb_ctlr *usbctlr;
+
+ if (portnum = port_count)
return -1;
- }
+
+ config = port[portnum];
+
+ /* skip init, if the port is already initialized */
+ if (config-initialized)
+ goto success;
if (config-utmi init_utmi_usb_controller(config)) {
- printf(tegrausb: Cannot init port\n);
+ printf(tegrausb: Cannot init port %d\n, portnum);
return -1;
}
if (config-ulpi init_ulpi_usb_controller(config)) {
- printf(tegrausb: Cannot init port\n);
+ printf(tegrausb: Cannot init port %d\n, portnum);
return -1;
}
- port[port_count++] = *config;
-
- return 0;
-}
-
-int tegrausb_start_port(int portnum, u32 *hccr, u32 *hcor)
-{
- struct usb_ctlr *usbctlr;
+ set_host_mode(config);
- if (portnum = port_count)
- return -1;
- set_host_mode(port[portnum]);
+ config-initialized = 1;
- usbctlr = port[portnum].reg;
+success:
+ usbctlr = config-reg;
*hccr = (u32)usbctlr-cap_length;
*hcor = (u32)usbctlr-usb_cmd;
return 0;
@@ -483,6 +476,8 @@ int tegrausb_stop_port(int portnum)
writel(2, usbctlr-usb_cmd);
udelay(1000);
+ port[portnum].initialized = 0;
+
return 0;
}
@@ -546,6 +541,12 @@ int board_usb_init(const void *blob)
count = fdtdec_find_aliases_for_id(blob, usb,
COMPAT_NVIDIA_TEGRA20_USB, node_list, USB_PORTS_MAX);
for (i = 0; i count; i++) {
+ if (port_count == USB_PORTS_MAX) {
+ printf(tegrausb: Cannot register more than %d ports\n,
+ USB_PORTS_MAX);
+ return -1;
+ }
+
debug(USB %d: , i);
node = node_list[i];
if (!node)
@@ -555,10 +556,10 @@ int board_usb_init(const void *blob)
fdt_get_name(blob, node, NULL));
return -1;
}
+ config.initialized = 0;
- if (add_port(config))
- return -1;
- set_host_mode(config);
+ /* add new USB port to the list of available ports */
+ port[port_count++] = config;
}
return 0;
--
1.8.0.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 6/7] tegra: usb: move implementation into right directory
This moves the Tegra USB implementation into the drivers/usb/host
directory. Note that this merges the old
/arch/arm/cpu/armv7/tegra20/usb.c file into ehci-tegra.c. No code
changes, just moving stuff around.
v2: While at it also move some defines and the usb.h header file to make
usb driver usable for Tegra30.
NOTE: A lot more work is required to properly init the PHYs and PLL_U on
Tegra30, this is just to make porting easier and it does no harm here.
Signed-off-by: Lucas Stach d...@lynxeye.de
---
arch/arm/cpu/armv7/tegra20/Makefile| 1 -
arch/arm/cpu/armv7/tegra20/usb.c | 555 -
.../include/asm/{arch-tegra20 = arch-tegra}/usb.h | 0
arch/arm/include/asm/arch-tegra20/tegra.h | 1 -
arch/arm/include/asm/arch-tegra30/tegra.h | 2 +
board/nvidia/common/board.c| 2 +-
drivers/usb/host/ehci-tegra.c | 535 +++-
7 files changed, 536 insertions(+), 560 deletions(-)
delete mode 100644 arch/arm/cpu/armv7/tegra20/usb.c
rename arch/arm/include/asm/{arch-tegra20 = arch-tegra}/usb.h (100%)
diff --git a/arch/arm/cpu/armv7/tegra20/Makefile
b/arch/arm/cpu/armv7/tegra20/Makefile
index 54ed8c4..c8a8504 100644
--- a/arch/arm/cpu/armv7/tegra20/Makefile
+++ b/arch/arm/cpu/armv7/tegra20/Makefile
@@ -27,7 +27,6 @@ include $(TOPDIR)/config.mk
LIB= $(obj)lib$(SOC).o
-COBJS-$(CONFIG_USB_EHCI_TEGRA) += usb.o
COBJS-$(CONFIG_PWM_TEGRA) += pwm.o
COBJS-$(CONFIG_VIDEO_TEGRA) += display.o
diff --git a/arch/arm/cpu/armv7/tegra20/usb.c b/arch/arm/cpu/armv7/tegra20/usb.c
deleted file mode 100644
index 3fdd5df..000
--- a/arch/arm/cpu/armv7/tegra20/usb.c
+++ /dev/null
@@ -1,555 +0,0 @@
-/*
- * Copyright (c) 2011 The Chromium OS Authors.
- * (C) Copyright 2010,2011 NVIDIA Corporation www.nvidia.com
- *
- * See file CREDITS for list of people who contributed to this
- * project.
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License as
- * published by the Free Software Foundation; either version 2 of
- * the License, or (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
- * MA 02111-1307 USA
- */
-
-#include common.h
-#include asm/io.h
-#include asm-generic/gpio.h
-#include asm/arch/clock.h
-#include asm/arch/usb.h
-#include usb/ulpi.h
-#include libfdt.h
-#include fdtdec.h
-
-#ifdef CONFIG_USB_ULPI
- #ifndef CONFIG_USB_ULPI_VIEWPORT
- #error To use CONFIG_USB_ULPI on Tegra Boards you have to also \
- define CONFIG_USB_ULPI_VIEWPORT
- #endif
-#endif
-
-enum {
- USB_PORTS_MAX = 3,/* Maximum ports we allow */
-};
-
-/* Parameters we need for USB */
-enum {
- PARAM_DIVN, /* PLL FEEDBACK DIVIDer */
- PARAM_DIVM, /* PLL INPUT DIVIDER */
- PARAM_DIVP, /* POST DIVIDER (2^N) */
- PARAM_CPCON,/* BASE PLLC CHARGE Pump setup ctrl */
- PARAM_LFCON,/* BASE PLLC LOOP FILter setup ctrl */
- PARAM_ENABLE_DELAY_COUNT, /* PLL-U Enable Delay Count */
- PARAM_STABLE_COUNT, /* PLL-U STABLE count */
- PARAM_ACTIVE_DELAY_COUNT, /* PLL-U Active delay count */
- PARAM_XTAL_FREQ_COUNT, /* PLL-U XTAL frequency count */
- PARAM_DEBOUNCE_A_TIME, /* 10MS DELAY for BIAS_DEBOUNCE_A */
- PARAM_BIAS_TIME,/* 20US DELAY AFter bias cell op */
-
- PARAM_COUNT
-};
-
-/* Possible port types (dual role mode) */
-enum dr_mode {
- DR_MODE_NONE = 0,
- DR_MODE_HOST, /* supports host operation */
- DR_MODE_DEVICE, /* supports device operation */
- DR_MODE_OTG,/* supports both */
-};
-
-/* Information about a USB port */
-struct fdt_usb {
- struct usb_ctlr *reg; /* address of registers in physical memory */
- unsigned utmi:1;/* 1 if port has external tranceiver, else 0 */
- unsigned ulpi:1;/* 1 if port has external ULPI transceiver */
- unsigned enabled:1; /* 1 to enable, 0 to disable */
- unsigned has_legacy_mode:1; /* 1 if this port has legacy mode */
- unsigned initialized:1; /* has this port already been initialized? */
- enum dr_mode dr_mode; /* dual role mode */
- enum periph_id periph_id;/* peripheral id */
- struct fdt_gpio_state vbus_gpio;/* GPIO for vbus enable */
- struct fdt_gpio_state
[U-Boot] [PATCH v2 3/7] tegra: usb: remove unneeded function parameter
Just a dead parameter, never actually used.
Signed-off-by: Lucas Stach d...@lynxeye.de
Acked-by: Simon Glass s...@chromium.org
---
arch/arm/cpu/armv7/tegra20/usb.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/arm/cpu/armv7/tegra20/usb.c b/arch/arm/cpu/armv7/tegra20/usb.c
index 07c1ade..2007483 100644
--- a/arch/arm/cpu/armv7/tegra20/usb.c
+++ b/arch/arm/cpu/armv7/tegra20/usb.c
@@ -486,8 +486,7 @@ int tegrausb_stop_port(int portnum)
return 0;
}
-int fdt_decode_usb(const void *blob, int node, unsigned osc_frequency_mhz,
- struct fdt_usb *config)
+int fdt_decode_usb(const void *blob, int node, struct fdt_usb *config)
{
const char *phy, *mode;
@@ -535,7 +534,6 @@ int fdt_decode_usb(const void *blob, int node, unsigned
osc_frequency_mhz,
int board_usb_init(const void *blob)
{
struct fdt_usb config;
- unsigned osc_freq = clock_get_rate(CLOCK_ID_OSC);
enum clock_osc_freq freq;
int node_list[USB_PORTS_MAX];
int node, count, i;
@@ -552,7 +550,7 @@ int board_usb_init(const void *blob)
node = node_list[i];
if (!node)
continue;
- if (fdt_decode_usb(blob, node, osc_freq, config)) {
+ if (fdt_decode_usb(blob, node, config)) {
debug(Cannot decode USB node %s\n,
fdt_get_name(blob, node, NULL));
return -1;
--
1.8.0.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 5/7] tegra: usb: various small cleanups
Remove unneeded headers, function prototype and stale comment, that
doesn't match the actual codebase anymore.
Signed-off-by: Lucas Stach d...@lynxeye.de
---
arch/arm/cpu/armv7/tegra20/usb.c| 13 +
arch/arm/include/asm/arch-tegra20/usb.h | 3 ---
2 files changed, 1 insertion(+), 15 deletions(-)
diff --git a/arch/arm/cpu/armv7/tegra20/usb.c b/arch/arm/cpu/armv7/tegra20/usb.c
index e4165e0..3fdd5df 100644
--- a/arch/arm/cpu/armv7/tegra20/usb.c
+++ b/arch/arm/cpu/armv7/tegra20/usb.c
@@ -25,21 +25,15 @@
#include asm/io.h
#include asm-generic/gpio.h
#include asm/arch/clock.h
-#include asm/arch/gpio.h
-#include asm/arch/pinmux.h
-#include asm/arch/tegra.h
#include asm/arch/usb.h
#include usb/ulpi.h
-#include asm/arch-tegra/clk_rst.h
-#include asm/arch-tegra/sys_proto.h
-#include asm/arch-tegra/uart.h
#include libfdt.h
#include fdtdec.h
#ifdef CONFIG_USB_ULPI
#ifndef CONFIG_USB_ULPI_VIEWPORT
#error To use CONFIG_USB_ULPI on Tegra Boards you have to also \
- define CONFIG_USB_ULPI_VIEWPORT
+ define CONFIG_USB_ULPI_VIEWPORT
#endif
#endif
@@ -191,11 +185,6 @@ void usbf_reset_controller(struct fdt_usb *config, struct
usb_ctlr *usbctlr)
/* Enable the UTMIP PHY */
if (config-utmi)
setbits_le32(usbctlr-susp_ctrl, UTMIP_PHY_ENB);
-
- /*
-* TODO: where do we take the USB1 out of reset? The old code would
-* take USB3 out of reset, but not USB1. This code doesn't do either.
-*/
}
/* set up the UTMI USB controller with the parameters provided */
diff --git a/arch/arm/include/asm/arch-tegra20/usb.h
b/arch/arm/include/asm/arch-tegra20/usb.h
index fdbd127..b18c850 100644
--- a/arch/arm/include/asm/arch-tegra20/usb.h
+++ b/arch/arm/include/asm/arch-tegra20/usb.h
@@ -243,9 +243,6 @@ struct usb_ctlr {
#define VBUS_VLD_STS (1 26)
-/* Change the USB host port into host mode */
-void usb_set_host_mode(void);
-
/* Setup USB on the board */
int board_usb_init(const void *blob);
--
1.8.0.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 7/7] tegra: usb: move [start|stop]_port into ehci_hcd_[init|stop]
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
---
arch/arm/include/asm/arch-tegra/usb.h | 19 --
drivers/usb/host/ehci-tegra.c | 119 +++---
2 files changed, 51 insertions(+), 87 deletions(-)
diff --git a/arch/arm/include/asm/arch-tegra/usb.h
b/arch/arm/include/asm/arch-tegra/usb.h
index b18c850..ef6c089 100644
--- a/arch/arm/include/asm/arch-tegra/usb.h
+++ b/arch/arm/include/asm/arch-tegra/usb.h
@@ -246,23 +246,4 @@ struct usb_ctlr {
/* Setup USB on the board */
int board_usb_init(const void *blob);
-/**
- * Start up the given port number (ports are numbered from 0 on each board).
- * This returns values for the appropriate hccr and hcor addresses to use for
- * USB EHCI operations.
- *
- * @param portnum port number to start
- * @param hccr returns start address of EHCI HCCR registers
- * @param hcor returns start address of EHCI HCOR registers
- * @return 0 if ok, -1 on error (generally invalid port number)
- */
-int tegrausb_start_port(int portnum, u32 *hccr, u32 *hcor);
-
-/**
- * Stop the current port
- *
- * @return 0 if ok, -1 if no port was active
- */
-int tegrausb_stop_port(int portnum);
-
#endif /* _TEGRA_USB_H_ */
diff --git a/drivers/usb/host/ehci-tegra.c b/drivers/usb/host/ehci-tegra.c
index b77806f..13bd6cc 100644
--- a/drivers/usb/host/ehci-tegra.c
+++ b/drivers/usb/host/ehci-tegra.c
@@ -438,60 +438,6 @@ static void config_clock(const u32 timing[])
timing[PARAM_CPCON], timing[PARAM_LFCON]);
}
-int tegrausb_start_port(int portnum, u32 *hccr, u32 *hcor)
-{
- struct fdt_usb *config;
- struct usb_ctlr *usbctlr;
-
- if (portnum = port_count)
- return -1;
-
- config = port[portnum];
-
- /* skip init, if the port is already initialized */
- if (config-initialized)
- goto success;
-
- if (config-utmi init_utmi_usb_controller(config)) {
- printf(tegrausb: Cannot init port %d\n, portnum);
- return -1;
- }
-
- if (config-ulpi init_ulpi_usb_controller(config)) {
- printf(tegrausb: Cannot init port %d\n, portnum);
- return -1;
- }
-
- set_host_mode(config);
-
- config-initialized = 1;
-
-success:
- usbctlr = config-reg;
- *hccr = (u32)usbctlr-cap_length;
- *hcor = (u32)usbctlr-usb_cmd;
- return 0;
-}
-
-int tegrausb_stop_port(int portnum)
-{
- struct usb_ctlr *usbctlr;
-
- usbctlr = port[portnum].reg;
-
- /* Stop controller */
- writel(0, usbctlr-usb_cmd);
- udelay(1000);
-
- /* Initiate controller reset */
- writel(2, usbctlr-usb_cmd);
- udelay(1000);
-
- port[portnum].initialized = 0;
-
- return 0;
-}
-
int fdt_decode_usb(const void *blob, int node, struct fdt_usb *config)
{
const char *phy, *mode;
@@ -576,32 +522,69 @@ int board_usb_init(const void *blob)
return 0;
}
-/*
- * Create the appropriate control structures to manage
- * a new EHCI host controller.
+/**
+ * Start up the given port number (ports are numbered from 0 on each board).
+ * This returns values for the appropriate hccr and hcor addresses to use for
+ * USB EHCI operations.
+ *
+ * @param indexport number to start
+ * @param hccr returns start address of EHCI HCCR registers
+ * @param hcor returns start address of EHCI HCOR registers
+ * @return 0 if ok, -1 on error (generally invalid port number)
*/
int ehci_hcd_init(int index, struct ehci_hccr **hccr, struct ehci_hcor **hcor)
{
- u32 our_hccr, our_hcor;
+ struct fdt_usb *config;
+ struct usb_ctlr *usbctlr;
- /*
-* Select the first port, as we don't have a way of selecting others
-* yet
-*/
- if (tegrausb_start_port(index, our_hccr, our_hcor))
+ if (index = port_count)
+ return -1;
+
+ config = port[index];
+
+ /* skip init, if the port is already initialized */
+ if (config-initialized)
+ goto success;
+
+ if (config-utmi init_utmi_usb_controller(config)) {
+ printf(tegrausb: Cannot init port %d\n, index);
+ return -1;
+ }
+
+ if (config-ulpi init_ulpi_usb_controller(config)) {
+ printf(tegrausb: Cannot init port %d\n, index);
return -1;
+ }
+
+ set_host_mode(config);
- *hccr = (struct ehci_hccr *)our_hccr;
- *hcor = (struct ehci_hcor *)our_hcor;
+ config-initialized = 1;
+success:
+ usbctlr = config-reg;
+ *hccr = (u32)usbctlr-cap_length;
+ *hcor = (u32)usbctlr-usb_cmd;
return 0;
}
/*
- * Destroy the appropriate control structures corresponding
- * the the EHCI host controller.
+ * Bring down the specified USB
Re: [U-Boot] [U-BOOT] help on mmc driver
Hi Lukasz Majewski,
Thanks for your information.
Thanks,
Jagan.
-Original Message-
From: Lukasz Majewski [mailto:l.majew...@samsung.com]
Sent: 25 January 2013 00:20
To: Jagannadha Sutradharudu Teki
Cc: u-boot@lists.denx.de
Subject: Re: [U-Boot] [U-BOOT] help on mmc driver
Hi Jagannadha,
Hi,
I need some help on mmc driver development on u-boot.
Few questions:
1. is mmc framework in u-boot supports all type of card interfaces
like SD, MMC, and eMMC
Yes there is a generic framework for MMC. - ./drivers/mmc/ {mmc.c}
2. If I write a driver do I need to develop the common driver for all
or a separate drivers for individual cards.
This is a generic framework. Normally you only need to write MMC controller
specific code to use it.
3. Is there any drivers in current u-boot drivers/mmc have individual
card interfaces support (SD MMC eMMC)
AS fair as I know there aren't any special drivers for any particular
vendor.
4. is there any drivers in
current u-boot driver/mmc for common card intefaces (SD | MMC |
eMMC)
Yes, you can refer to mmc.c
One good example is the sdhci.c code which serves for SD cards and eMMC
(at least for Samsung).
Request for help.
Thanks,
Jagan.
This email and any attachments are intended for the sole use of the
named recipient(s) and contain(s) confidential information that may be
proprietary, privileged or copyrighted under applicable law. If you
are not the intended recipient, do not read, copy, or forward this
email message or any attachments. Delete this email message and any
attachments immediately.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
--
Best regards,
Lukasz Majewski
Samsung RD Poland (SRPOL) | Linux Platform Group
This email and any attachments are intended for the sole use of the named
recipient(s) and contain(s) confidential information that may be proprietary,
privileged or copyrighted under applicable law. If you are not the intended
recipient, do not read, copy, or forward this email message or any attachments.
Delete this email message and any attachments immediately.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/7] Move Tegra EHCI drive to correct place
Lucas,
-Original Message-
From: Lucas Stach [mailto:d...@lynxeye.de]
Sent: Friday, January 25, 2013 7:41 AM
To: u-boot@lists.denx.de
Cc: Tom Warren; Marek Vasut; Simon Glass; Stephen Warren
Subject: [PATCH v2 0/7] Move Tegra EHCI drive to correct place
This moves out the Tegra EHCI driver from a platform specific directory to the
standard driver/usb/host dir.
This is a preparation needed to share this driver between Tegra20 and Tegra30.
No functional change in here, so Tegra30 is still not working.
Patch 6 could be a lot smaller if it were generated with -B, as GIT would
detect that most of it is moving stuff over, but last time I did this it
prevented git apply to work. So sorry for the big diff.
I think I incorporated all changes needed to reflect the review feedback I got
on this last time.
I expect this series to go in through the Tegra tree.
I tried to apply this to u-boot-tegra/next and it needed some massaging to get
it to apply cleanly. Minor stuff, but you'll need to rebase it on top of
current u-boot-tegra/next (I just pushed a new version with my 'Move common
clock code' patch and Allen's fix for the DTS sort patch. Sorry, but the Tegra
repo is going to be fairly dynamic for the next few weeks.
Also, when I did get it applied and tried to ./MAKEALL -s tegra20 -s tegra30, I
got the following warning on all T20 builds:
ehci-tegra.c: In function 'ehci_hcd_init':
ehci-tegra.c:565: warning: assignment makes pointer from integer without a cast
ehci-tegra.c:566: warning: assignment makes pointer from integer without a cast
Also, it appears that arch-tegra20/usb.h is still hanging around (in my edited
patch series, at any rate). Shouldn't the moved arch-tegra/usb.h be used
exclusively? Removing arch-tegra20/usb.h causes fatal errors in
nvidia/common/board.c. If it does need to exist, then it needs to live in
arch-tegra30, also, so it'll be available when T30 gets USB turned on.
Tom
Lucas Stach (7):
tegra: usb: set USB_PORTS_MAX to correct value
tegra: usb: make controller init functions more self contained
tegra: usb: remove unneeded function parameter
tegra: usb: move controller init into start_port
tegra: usb: various small cleanups
tegra: usb: move implementation into right directory
tegra: usb: move [start|stop]_port into ehci_hcd_[init|stop]
arch/arm/cpu/armv7/tegra20/Makefile| 1 -
arch/arm/cpu/armv7/tegra20/usb.c | 567 -
.../include/asm/{arch-tegra20 = arch-tegra}/usb.h | 22 -
arch/arm/include/asm/arch-tegra20/tegra.h | 1 -
arch/arm/include/asm/arch-tegra30/tegra.h | 2 +
board/nvidia/common/board.c| 2 +-
drivers/usb/host/ehci-tegra.c | 546 +++-
7 files changed, 533 insertions(+), 608 deletions(-) delete mode 100644
arch/arm/cpu/armv7/tegra20/usb.c rename arch/arm/include/asm/{arch-tegra20 =
arch-tegra}/usb.h (89%)
--
1.8.0.2
--
nvpublic
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/7] Move Tegra EHCI drive to correct place
Hello Tom, Am Freitag, den 25.01.2013, 08:07 -0800 schrieb Tom Warren: I tried to apply this to u-boot-tegra/next and it needed some massaging to get it to apply cleanly. Minor stuff, but you'll need to rebase it on top of current u-boot-tegra/next (I just pushed a new version with my 'Move common clock code' patch and Allen's fix for the DTS sort patch. Sorry, but the Tegra repo is going to be fairly dynamic for the next few weeks. Ok, I'll wait for some comments on the actual code, then repost a rebased version. Also, when I did get it applied and tried to ./MAKEALL -s tegra20 -s tegra30, I got the following warning on all T20 builds: ehci-tegra.c: In function 'ehci_hcd_init': ehci-tegra.c:565: warning: assignment makes pointer from integer without a cast ehci-tegra.c:566: warning: assignment makes pointer from integer without a cast Ah damn, forgot to squash the fix in the last patch. Also, it appears that arch-tegra20/usb.h is still hanging around (in my edited patch series, at any rate). Shouldn't the moved arch-tegra/usb.h be used exclusively? Removing arch-tegra20/usb.h causes fatal errors in nvidia/common/board.c. If it does need to exist, then it needs to live in arch-tegra30, also, so it'll be available when T30 gets USB turned on. I don't see why this is happening. The shortlog points at git picking up the rename at the in the wrong dir, I'll look into this when reposting. But the change to nvidia/common/board.c to use the new include dir is definitely included in patch 6. Regards, Lucas ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] B4860/B4420 patches and some updates for qixis and T4240QDS
I have found the problem: -B4860QDS_SPIFLASHpowerpc mpc85xx b4860qds freescale - B4860QDS:RAMBOOT_PBL,SPIFLASH,SYS_TEXT_BASE=0xFFF8 +B4860QDS_SPIFLASHpowerpc mpc85xx b4860qds freescale - B4860QDS:PPC_B4860,RAMBOOT_PBL,SPIFLASH,SYS_TEXT_BASE=0xFFF8 -B4420QDS_SPIFLASHpowerpc mpc85xx b4860qds freescale - B4860QDS:RAMBOOT_PBL,SPIFLASH,SYS_TEXT_BASE=0xFFF8 +B4420QDS_SPIFLASHpowerpc mpc85xx b4860qds freescale - B4860QDS:PPC_B4420,RAMBOOT_PBL,SPIFLASH,SYS_TEXT_BASE=0xFFF8 For some reason, the SPIFLASH versions of these boards didn't have the processor specified. I will add that change to the patches, and push them upstream. On Thu, Jan 24, 2013 at 2:08 AM, Andy Fleming aflem...@gmail.com wrote: I'm seeing these errors, when these patches are enabled: /local/afleming/u-boot/build/B4420QDS_SPIFLASH/include2/asm/config_mpc85xx.h:575:2: error: #error Processor type not defined for this platform /local/afleming/u-boot/build/B4420QDS_SPIFLASH/include2/asm/config_mpc85xx.h:579:2: error: #error CONFIG_SYS_CCSRBAR_DEFAULT is not defined for this platform. /local/afleming/u-boot/build/B4420QDS_SPIFLASH/include2/asm/config_mpc85xx.h:575:2: error: #error Processor type not defined for this platform /local/afleming/u-boot/build/B4420QDS_SPIFLASH/include2/asm/config_mpc85xx.h:579:2: error: #error CONFIG_SYS_CCSRBAR_DEFAULT is not defined for this platform. In file included from /local/afleming/u-boot/build/B4420QDS_SPIFLASH/include2/asm/config.h:25:0, from /local/afleming/u-boot/build/B4420QDS_SPIFLASH/include/config.h:13, from /local/afleming/u-boot/include/common.h:37, from /local/afleming/u-boot/lib/asm-offsets.c:18: /local/afleming/u-boot/build/B4420QDS_SPIFLASH/include2/asm/config_mpc85xx.h:575:2: error: #error Processor type not defined for this platform /local/afleming/u-boot/build/B4420QDS_SPIFLASH/include2/asm/config_mpc85xx.h:579:2: error: #error CONFIG_SYS_CCSRBAR_DEFAULT is not defined for this platform. In file included from /local/afleming/u-boot/include/mpc85xx.h:14:0, from /local/afleming/u-boot/include/common.h:93, from /local/afleming/u-boot/lib/asm-offsets.c:18: /local/afleming/u-boot/include/e500.h:19:26: error: 'CONFIG_SYS_NUM_FMAN' undeclared here (not in a function) In file included from /local/afleming/u-boot/include/common.h:94:0, from /local/afleming/u-boot/lib/asm-offsets.c:18: /local/afleming/u-boot/build/B4420QDS_SPIFLASH/include2/asm/immap_85xx.h:1400:33: error: 'CONFIG_SYS_FSL_SRIO_MAX_PORTS' undeclared here (not in a function) /local/afleming/u-boot/build/B4420QDS_SPIFLASH/include2/asm/immap_85xx.h:1498:28: error: 'CONFIG_SYS_FSL_SRIO_OB_WIN_NUM' undeclared here (not in a function) /local/afleming/u-boot/build/B4420QDS_SPIFLASH/include2/asm/immap_85xx.h:1500:27: error: 'CONFIG_SYS_FSL_SRIO_IB_WIN_NUM' undeclared here (not in a function) make: *** [/local/afleming/u-boot/build/B4420QDS_SPIFLASH/lib/asm-offsets.s] Error 1 make: *** Waiting for unfinished jobs This was also seen on B4860QDS_SPIFLASH On Thu, Jan 17, 2013 at 11:18 PM, Aggrwal Poonam-B10812 b10...@freescale.com wrote: Hello Andy Any update on this patch set? Regards Poonam From: Aggrwal Poonam-B10812 Sent: Friday, December 21, 2012 6:16 PM To: U-Boot-Denx Subject: B4860/B4420 patches and some updates for qixis and T4240QDS The patchset contains the following patches: Mainly related to B4860/B4420QDS. Some are qixis updates and related additions for B4860/B4420QDS and T4240QDS. [PATCH 01/09] powerpc/mpc85xx: Few updates for B4860 cpu changes [PATCH 02/09] powerpc/mpc85xx:Add support of B4420 SoC [PATCH 03/09] board/freescale/common:Add support of QTAG register [PATCH 04/09] powerpc/mpc85xx:Fix Core cluster configuration loop [PATCH 05/09] powerpc/b4860qds: Added Support for B4860QDS [PATCH 06/09] powerpc/qixis: enable qixis dump command and add switch dumping command [PATCH 07/09] powerpc/b4860qds: Add support to dump switch settings on b4860qds board [PATCH 08/09] powerpc/t4240qds: Add support to dump switch settings on t4240qds board [PATCH 09/09] powerpc/t4240qds: Print FPGA detail version Regards Poonam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] corenet: Disable video on P2020DS
The P2020DS build had grown too large, and video support isn't enabled in almost any other Freescale board. Disabling it allows us to keep building, and provides options for reenabling it later. Signed-off-by: Andy Fleming aflem...@freescale.com --- include/configs/P2020DS.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/configs/P2020DS.h b/include/configs/P2020DS.h index 0cc5781..a975ee1 100644 --- a/include/configs/P2020DS.h +++ b/include/configs/P2020DS.h @@ -490,7 +490,7 @@ #define VIDEO_IO_OFFSETCONFIG_SYS_PCIE1_IO_VIRT /* video */ -#define CONFIG_VIDEO +#undef CONFIG_VIDEO #if defined(CONFIG_VIDEO) #define CONFIG_BIOSEMU -- 1.7.9.7 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Please pull u-boot-mpc85xx.git
README.mips: update known issues and TODOs (2013-01-16 10:52:08 +0100) are available in the git repository at: git://www.denx.de/git/u-boot-mpc85xx.git master for you to fetch changes up to 1342f7dd2c864889ce3ef6a78fe74155fd1f9a8f: corenet: Disable video on P2020DS (2013-01-25 10:32:22 -0600) Anatolij Gustschin (1): mpc8xxx: fix DDR init value to use CONFIG_MEM_INIT_VALUE Andy Fleming (1): corenet: Disable video on P2020DS Hongtao Jia (2): powerpc/mpc8572ds: Enable bank interleaving to cs0+cs1 for dual-rank DIMMs powerpc/mpc8544ds: Add USB controller support for MPC8544DS James Yang (5): Move DDR command parsing to separate function Fix data stage name matching issue Add copy command to FSL DDR interactive README.fsl-ddr typos and update to reflect hotkey powerpc/mpc8: FSL DDR debugger auto run of stored commands Poonam Aggrwal (2): powerpc/mpc85xx: Few updates for B4860 cpu changes powerpc/mpc85xx:Add support of B4420 SoC Prabhakar Kushwaha (8): board/T4240qds:Fix TLB and LAW size of NAND flash boards/T4240qds:Fix IFC AMASK init as per FPGA register space board/freescale/common:Add support of QTAG register powerpc/mpc85xx:Fix Core cluster configuration loop powerpc/t4240qds: Print FPGA detail version powerpc/mpc85xx: Add BSC9132/BSC9232 processor support powerpc/85xx: Add BSC9132QDS support board/common: Add support for QIXIS read/write using i2c Scott Wood (1): powerpc/mpc85xx: add support for MMUv2 page sizes Shaohui Xie (1): powerpc/p2041: move Lanes mux to board early init Shaveta Leekha (3): powerpc/qixis: enable qixis dump command and add switch dumping command powerpc/b4860qds: Add support to dump switch settings on b4860qds board powerpc/t4240qds: Add support to dump switch settings on t4240qds board Shengzhou Liu (1): powerpc/t4240: Adding workaround errata A-005871 Timur Tabi (1): powerpc/t4qds: move VSC3316 config data from t4qds.h to t4qds.c Vakul Garg (1): powerpc/mpc85xx: Add property 'fsl, sec-era' in device tree node 'crypto' Valentin Longchamp (2): powerpc/p2041: add RCW file for P2041RDB powerpc/p2041: set RCW and PBI files for .pbl build or P2041RDB York Sun (4): powerpc/mpc85xx: Reserve default boot page powerpc/t4240qds: Update IFC timing for NOR flash powerpc/b4860qds: Added Support for B4860QDS powerpc/mpc8xxx: Enable entering DDR debugging by key press MAINTAINERS |4 + arch/powerpc/cpu/mpc85xx/Makefile|5 + arch/powerpc/cpu/mpc85xx/b4860_ids.c |6 + arch/powerpc/cpu/mpc85xx/b4860_serdes.c | 60 ++ arch/powerpc/cpu/mpc85xx/bsc9132_serdes.c| 96 +++ arch/powerpc/cpu/mpc85xx/cmd_errata.c|4 + arch/powerpc/cpu/mpc85xx/cpu_init.c | 44 +- arch/powerpc/cpu/mpc85xx/fdt.c | 24 + arch/powerpc/cpu/mpc85xx/start.S |2 +- arch/powerpc/cpu/mpc85xx/tlb.c | 19 +- arch/powerpc/cpu/mpc8xxx/cpu.c |2 + arch/powerpc/cpu/mpc8xxx/ddr/ctrl_regs.c |4 + arch/powerpc/cpu/mpc8xxx/ddr/ddr.h |3 +- arch/powerpc/cpu/mpc8xxx/ddr/interactive.c | 324 ++--- arch/powerpc/cpu/mpc8xxx/ddr/main.c |8 +- arch/powerpc/cpu/mpc8xxx/fdt.c | 78 +- arch/powerpc/include/asm/config_mpc85xx.h| 39 +- arch/powerpc/include/asm/immap_85xx.h| 34 +- arch/powerpc/include/asm/mmu.h | 52 +- arch/powerpc/include/asm/processor.h |2 + board/freescale/b4860qds/Makefile| 54 ++ board/freescale/b4860qds/b4860qds.c | 505 + board/freescale/b4860qds/b4860qds.h | 26 + board/freescale/b4860qds/b4860qds_crossbar_con.h | 67 ++ board/freescale/b4860qds/b4860qds_qixis.h| 37 + board/freescale/b4860qds/ddr.c | 190 + board/freescale/b4860qds/eth_b4860qds.c | 338 + board/freescale/b4860qds/law.c | 44 ++ board/freescale/b4860qds/pci.c | 39 + board/freescale/b4860qds/tlb.c | 127 board/freescale/bsc9132qds/Makefile | 52 ++ board/freescale/bsc9132qds/README| 150 board/freescale/bsc9132qds/bsc9132qds.c | 406 +++ board/freescale/bsc9132qds/ddr.c | 209 ++ board/freescale/bsc9132qds/law.c | 35 + board/freescale/bsc9132qds/tlb.c | 92 +++ board/freescale/common/qixis.c | 107 ++- board/freescale/common/qixis.h | 13 + board/freescale/corenet_ds/rcw_p2041rdb.cfg | 11 +
Re: [U-Boot] Want to study U-Boot code
在 2013-1-25 PM7:35，Marek Vasut ma...@denx.de写道： Dear Woody Wu, On Fri, Jan 25, 2013 at 12:30:43AM +0100, Marek Vasut wrote: Dear Woody Wu, Hi, List Is there a book or web document to help start to understand how U-Boot works? There's a doc/ directory in the u-boot sourcecode. Is there a guide/suggestion to the reading order of these docs? You know, there is not a index file. Thanks. The question is -- what do you want to do? If Study u-boot code is the answer, just dive in ;-) Best regards, Marek Vasut I want to firstly get a picture to basically understand how u-boot work, especially on an ARM9 based board. I think not everyone who want to understand u-boot has to read the full code. Thank. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] tegra: fdt: add back missing host1x node
Add back host1x node to seaboard dts file. This got dropped during
the tegra fdt sort.
Signed-off-by: Allen Martin amar...@nvidia.com
---
board/nvidia/dts/tegra20-seaboard.dts | 11 +++
1 file changed, 11 insertions(+)
diff --git a/board/nvidia/dts/tegra20-seaboard.dts
b/board/nvidia/dts/tegra20-seaboard.dts
index 9cb9b5b..527a296 100644
--- a/board/nvidia/dts/tegra20-seaboard.dts
+++ b/board/nvidia/dts/tegra20-seaboard.dts
@@ -27,6 +27,17 @@
reg = 0x 0x4000 ;
};
+ host1x {
+ status = okay;
+ dc@5420 {
+ status = okay;
+ rgb {
+ status = okay;
+ nvidia,panel = lcd_panel;
+ };
+ };
+ };
+
/* This is not used in U-Boot, but is expected to be in kernel .dts */
i2c@7000d000 {
clock-frequency = 10;
--
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] corenet: Disable video on P2020DS
On Fri, Jan 25, 2013 at 10:38:01AM -0600, Andy Fleming wrote: The P2020DS build had grown too large, and video support isn't enabled in almost any other Freescale board. Disabling it allows us to keep building, and provides options for reenabling it later. Signed-off-by: Andy Fleming aflem...@freescale.com Now we may start having dead code around, yes? Can you perhaps get away with making this be disable video or something else and add a P2020DS_video boards.cfg entry or similar? Thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] corenet: Disable video on P2020DS
On 01/25/2013 12:50:59 PM, Tom Rini wrote: On Fri, Jan 25, 2013 at 10:38:01AM -0600, Andy Fleming wrote: The P2020DS build had grown too large, and video support isn't enabled in almost any other Freescale board. Disabling it allows us to keep building, and provides options for reenabling it later. Signed-off-by: Andy Fleming aflem...@freescale.com Now we may start having dead code around, yes? Can you perhaps get away with making this be disable video or something else and add a P2020DS_video boards.cfg entry or similar? Thanks! There are already 5 P2020DS targets, and there *should* be 8 (why is there no 36BIT version of DDR2, SDCARD, or SPIFLASH?). This would expand it to 16. Ideally we would have something like kconfig, but until then I don't see a reasonable alternative to saying that certain config symbols are user-settable by tweaking the board config file. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] corenet: Disable video on P2020DS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/25/2013 02:25 PM, Scott Wood wrote: On 01/25/2013 12:50:59 PM, Tom Rini wrote: On Fri, Jan 25, 2013 at 10:38:01AM -0600, Andy Fleming wrote: The P2020DS build had grown too large, and video support isn't enabled in almost any other Freescale board. Disabling it allows us to keep building, and provides options for reenabling it later. Signed-off-by: Andy Fleming aflem...@freescale.com Now we may start having dead code around, yes? Can you perhaps get away with making this be disable video or something else and add a P2020DS_video boards.cfg entry or similar? Thanks! There are already 5 P2020DS targets, and there *should* be 8 (why is there no 36BIT version of DDR2, SDCARD, or SPIFLASH?). This would expand it to 16. Ideally we would have something like kconfig, but until then I don't see a reasonable alternative to saying that certain config symbols are user-settable by tweaking the board config file. That's fine, in general. But does this patch now leave us with non-build testing video code? That way lies bitrot, so yes, please add a 6th target so that when someone needs to hand tweak their P2020DS setup for this, not that, yes this and not that, oh and video, they can have some confidence the code still builds. Or say that P1020/1022 having video on still too means the code in question is still used. That would also be fine. Thanks. - -- Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRAt5xAAoJENk4IS6UOR1W/cYP/2r3hx6uihLc8BRYfOrHDCov drjzyOEN9bL/y9vDTVsbYC5HpTWv7ZdsC3JpJ9fWY/ljRAzWuQIYJ6Exvcw7PDEw 6lNdyQXL+NURZ1SreeK0YxdQrTSRtpMn69R+GIEX5Msk6JmZ8Z+qrHYXv8zJm80d Or6CreG2wk5mm3IWZW+qf9mLIc8SK6uHil8XrXuGPYUSYKFaLpV/9hgUxh3138Dz OMdUSZZEv+4kfab9nqFgHdfbNmFqrKZsyUZ0Ig+nqDU4/HimasPmud1PmRkGywua NJP/BYcsMbnjhVzyhLSL3Oj8sPZHTX4668W42ufr4hTpvUoRlMOILE43nqYn3atr mWCECUPKChR2qXyg7Qnfkj8jiuIEzSJ5FBsBn8T7JldcZhZbOA/uI3xMsXfw57SI /OrkoOZ3Hcx8LIdCiNhCEoWN6WS/CeSBw1wE2Re1qTKGwMQwtMhi/YrwthB3O6NS q64gM3Fl5PgzQ7GK+mGIEO/GVgR8Okg7mZG7pF8RjIPQbL9bKBsMJyU7O8Z8DD+2 /OM4Y5Jw8qraN6HK4aOvLYjV2kkkfUQgU9Bo6/SBVndF5FMynMwUdt4P2sC5D4iw SL6r43XjEQEKbJu/NB3SikI3qAdd8sdzjWvuF3JYAS2iUJ3RBu9wpwGw1kO0QZI5 OE3bYgwhqtt6WeW8Nl89 =ZCH1 -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] corenet: Disable video on P2020DS
On 01/25/2013 01:25:33 PM, Scott Wood wrote: On 01/25/2013 12:50:59 PM, Tom Rini wrote: On Fri, Jan 25, 2013 at 10:38:01AM -0600, Andy Fleming wrote: The P2020DS build had grown too large, and video support isn't enabled in almost any other Freescale board. Disabling it allows us to keep building, and provides options for reenabling it later. Signed-off-by: Andy Fleming aflem...@freescale.com Now we may start having dead code around, yes? Can you perhaps get away with making this be disable video or something else and add a P2020DS_video boards.cfg entry or similar? Thanks! There are already 5 P2020DS targets, and there *should* be 8 (why is there no 36BIT version of DDR2, SDCARD, or SPIFLASH?). I take that back -- there should be 16, as DDR2 seems to be orthogonal as well. So adding VIDEO on/off for all configs would bring it up to 32 if we fixed the rest. I suppose you could just have one video config for compilation coverage, but it seems awkward, and what is it really testing? It's not the only board to enable BIOSEMU, ATI framebuffer, etc. You'd just be testing that it works with p2020ds, but for integration testing one config working might not say anything about another. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Want to study U-Boot code
Dear Woody Wu, In message CAAsE_ue4VffAioQWzHPpyOZmzoFk9E5S7jj2+2BZuiK=c5y...@mail.gmail.com you wrote: I want to firstly get a picture to basically understand how u-boot work, especially on an ARM9 based board. I think not everyone who want to understand u-boot has to read the full code. Thank. This depends on your definition of understanding. On a highlevel, you might start with reaing and digesting the manual, eventually trying out how U-Boot works on some (real or emulated) board. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Fascinating is a word I use for the unexpected. -- Spock, The Squire of Gothos, stardate 2124.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 02/10] lcd, tegra: remove unused cursor functions
+Tom
On Sun, Jan 13, 2013 at 11:07 AM, Jeroen Hofstee jer...@myspectrum.nl wrote:
cc: Anatolij Gustschin ag...@denx.de
cc: Simon Glass sjg.chromium.org
Signed-off-by: Jeroen Hofstee jer...@myspectrum.nl
Acked-by: Simon Glass s...@chromium.org
---
drivers/video/tegra.c | 52
-
1 file changed, 52 deletions(-)
diff --git a/drivers/video/tegra.c b/drivers/video/tegra.c
index 3709d0b..26a96a5 100644
--- a/drivers/video/tegra.c
+++ b/drivers/video/tegra.c
@@ -73,62 +73,10 @@ vidinfo_t panel_info = {
.vl_col = -1,
};
-char lcd_cursor_enabled;
-
-ushort lcd_cursor_width;
-ushort lcd_cursor_height;
-
#ifndef CONFIG_OF_CONTROL
#error You must enable CONFIG_OF_CONTROL to get Tegra LCD support
#endif
-void lcd_cursor_size(ushort width, ushort height)
-{
- lcd_cursor_width = width;
- lcd_cursor_height = height;
-}
-
-void lcd_toggle_cursor(void)
-{
- ushort x, y;
- uchar *dest;
- ushort row;
-
- x = console_col * lcd_cursor_width;
- y = console_row * lcd_cursor_height;
- dest = (uchar *)(lcd_base + y * lcd_line_length + x * (1 LCD_BPP) /
- 8);
-
- for (row = 0; row lcd_cursor_height; ++row, dest +=
lcd_line_length) {
- ushort *d = (ushort *)dest;
- ushort color;
- int i;
-
- for (i = 0; i lcd_cursor_width; ++i) {
- color = *d;
- color ^= lcd_getfgcolor();
- *d = color;
- ++d;
- }
- }
-}
-
-void lcd_cursor_on(void)
-{
- lcd_cursor_enabled = 1;
- lcd_toggle_cursor();
-}
-void lcd_cursor_off(void)
-{
- lcd_cursor_enabled = 0;
- lcd_toggle_cursor();
-}
-
-char lcd_is_cursor_enabled(void)
-{
- return lcd_cursor_enabled;
-}
-
static void update_panel_size(struct fdt_disp_config *config)
{
panel_info.vl_col = config-width;
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/7] EXYNOS5: GPIO to enable MAX98095
Hi Rajeshwari,
On Wed, Jan 23, 2013 at 11:05 PM, Rajeshwari Birje
rajeshwari.bi...@gmail.com wrote:
Hi Simon,
Thank you for comments.
On Tue, Jan 22, 2013 at 8:25 PM, Simon Glass s...@chromium.org wrote:
Hi Rajeshwari,
On Mon, Jan 21, 2013 at 2:52 AM, Rajeshwari Shinde
rajeshwar...@samsung.com wrote:
This patch sets high a GPIO to enable the codec MAX98095
Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com
---
board/samsung/smdk5250/smdk5250.c | 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/board/samsung/smdk5250/smdk5250.c
b/board/samsung/smdk5250/smdk5250.c
index 12cc03e..6f2e067 100644
--- a/board/samsung/smdk5250/smdk5250.c
+++ b/board/samsung/smdk5250/smdk5250.c
@@ -56,6 +56,18 @@ int board_usb_vbus_init(void)
}
#endif
+#ifdef CONFIG_SOUND_MAX98095
+static void board_enable_audio_codec(void)
+{
+ struct exynos5_gpio_part1 *gpio1 = (struct exynos5_gpio_part1 *)
+
samsung_get_base_gpio_part1();
+
+ /* Enable MAX98095 Codec */
+ s5p_gpio_direction_output(gpio1-x1, 7, 1);
+ s5p_gpio_set_pull(gpio1-x1, 7, GPIO_PULL_NONE);
This GPIO is hard-coded - does the FDT version of this file do this
differently?
For FDT support of same we need gpio numbering feature which is still
not merged in the mainline code.
Hence currently the same has been hard coded for MAX98095 on Snow.
Yes I see, thank you.
Acked-by: Simon Glass s...@chromium.org
+}
+#endif
+
int board_init(void)
{
gd-bd-bi_boot_params = (PHYS_SDRAM_1 + 0x100UL);
@@ -65,6 +77,9 @@ int board_init(void)
#ifdef CONFIG_USB_EHCI_EXYNOS
board_usb_vbus_init();
#endif
+#ifdef CONFIG_SOUND_MAX98095
+ board_enable_audio_codec();
+#endif
return 0;
}
--
1.7.4.4
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
--
Regards,
Rajeshwari Shinde
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 6/7] EXYNOS5: Add initial DTS file for Snow.
On Mon, Jan 21, 2013 at 11:52 PM, Rajeshwari Shinde
rajeshwar...@samsung.com wrote:
This patch adds the DTS file for Snow Board.
Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com
One question below, but:
Acked-by: Simon Glass s...@chromium.org
---
board/samsung/dts/exynos5250-snow.dts | 69
+
1 files changed, 69 insertions(+), 0 deletions(-)
create mode 100644 board/samsung/dts/exynos5250-snow.dts
diff --git a/board/samsung/dts/exynos5250-snow.dts
b/board/samsung/dts/exynos5250-snow.dts
new file mode 100644
index 000..af788a6
--- /dev/null
+++ b/board/samsung/dts/exynos5250-snow.dts
@@ -0,0 +1,69 @@
+/*
+ * SAMSUNG SMDK5250 board device tree source
+ *
+ * Copyright (c) 2012 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+
+/dts-v1/;
+/include/ ARCH_CPU_DTS
+
+/ {
+ model = Google Snow;
+ compatible = google,snow, samsung,exynos5250;
+
+ aliases {
+ i2c0 = /i2c@12c6;
+ i2c1 = /i2c@12c7;
+ i2c2 = /i2c@12c8;
+ i2c3 = /i2c@12c9;
+ i2c4 = /i2c@12ca;
+ i2c5 = /i2c@12cb;
+ i2c6 = /i2c@12cc;
+ i2c7 = /i2c@12cd;
+ spi0 = /spi@12d2;
+ spi1 = /spi@12d3;
+ spi2 = /spi@12d4;
+ spi3 = /spi@131a;
+ spi4 = /spi@131b;
+ };
+
+ sromc@1225 {
+ bank = 1;
+ srom-timing = 1 9 12 1 6 1 1;
+ width = 2;
+ lan@500 {
+ compatible = smsc,lan9215, smsc,lan;
+ reg = 0x500 0x100;
+ phy-mode = mii;
+ };
+ };
+
+ sound@12d6 {
+ samsung,i2s-epll-clock-frequency = 19200;
+ samsung,i2s-sampling-rate = 48000;
+ samsung,i2s-bits-per-sample = 16;
+ samsung,i2s-channels = 2;
+ samsung,i2s-lr-clk-framesize = 256;
+ samsung,i2s-bit-clk-framesize = 32;
+ samsung,codec-type = max98095;
+ };
+
+ i2c@12cd {
+ soundcodec@22 {
+ reg = 0x22;
+ compatible = maxim,max98095-codec;
+ };
+ };
+
+ i2c@12c6 {
+ pmic@9 {
+ reg = 0x9;
+ compatible = maxim,max77686_pmic;
Should this be - instead of _ ?
+ };
+ };
+};
--
1.7.4.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] corenet: Disable video on P2020DS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/25/2013 03:43 PM, Fleming Andy-AFLEMING wrote: On Jan 25, 2013, at 12:50 PM, Tom Rini wrote: On Fri, Jan 25, 2013 at 10:38:01AM -0600, Andy Fleming wrote: The P2020DS build had grown too large, and video support isn't enabled in almost any other Freescale board. Disabling it allows us to keep building, and provides options for reenabling it later. Signed-off-by: Andy Fleming aflem...@freescale.com Now we may start having dead code around, yes? Can you perhaps get away with making this be disable video or something else and add a P2020DS_video boards.cfg entry or similar? Thanks! There doesn't appear to be any 2020-specific code in drivers/video/. The truth is, I doubt the code gets more than compile-tested by the setting being there. Also, as noted, P1022 defines it, in addition to MPC8536, MPC8544, MPC8572, MPC8610, and MPC8641. I'd rather not hack up a video config just for P2020, if possible. That's all I was looking for, that yes, we don't now have very dead code there. Thanks! (and I kicked off my loop of testing on the PR that includes this change a while ago, still spinning over everything). - -- Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRAu+yAAoJENk4IS6UOR1WxmMP/3n2qAoSndB5DpCjiaMj0zTz 33ShG55Zv14aU40WCD1I4yMkY/hi/mEr3sOIo/D7pZ+FzciYhliBNPejCUuTfmtD T4YkE1rvtmF+TMKxLdqeUXiQPJyI81tzwGfA2y+NZXnpTMEqpo+ke6DM2xXHxjHP Vxjp+IGBT0gKG/gjp6c/WdR1kdbqGQRQBnM3l9Ifdt64c7GksMCEg2MyVIBkPQpY K/WvB03wQz/CohAPy/ySIrzdxKoXjrurUBNZOiKQ4rwBs7O7i6xhr02ZE8Mjco2n 13SY+jRYSlH24F5BbKS2TKtD5b3DGXa9SLihg+nl6gdzyZ/kZJo2zdGm5K+scFS5 1jLWUOOI06xxLUoGCmaCPzOvbxMTSQKSHpLhFSR/EryOq2NlY4D+wHtAPQmbI8GU eP5lnV/a44kCG5CMgoBKOy8vRxIRjUZaTDFix5fC+rxbgZUTh1MGO4Mp4ieuxHz5 B/48CbN1Ka9fpMQOlo1u01ZbCAya5aUeL6TduvGr4SXaw878hS8S9+89nRMoSma1 Rc9tH2B5F4LKsky8C4lcGsE2YsPd7z2kkRApyMzoKd+O2ZCcDXdnZ9RQO3+is0y7 pWqzfWZhfg4UDWn8jD3Sv3uLxwM890FsmhiAoDhTjdhB4K7sL5AU8dcD2u6G35cg uq6A/XJ6nVxAW+a4p1Uv =C7Yu -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 6/7 v5] TMU: Add TMU support in dtt command
Hi Akshay,
On Thu, Jan 24, 2013 at 4:02 AM, Akshay Saraswat aksha...@samsung.comwrote:
Hi Simon,
If we create two versions of dtt_get_temp(), we have to declare
unnecessarily few configs and their values like CONFIG_DTT_SENSORS and
CONFIG_SYS_DTT_BUS_NUM when we can easily ignore them. That's why I thought
of including TMU to dtt this way. I dont think we need both TMU and I2C bus
sensors together anywhere. Please suggest which way is better.
(Sorry I am on holiday for a week so not very responsive. I get back next
Thurs)
The thing is that these two implementations share no code at all. I think
the way you have done it is good, I was just wondering whether it would be
better to have do_dtt_i2c() and do_dtt_tmu() as separate function. But I
suppose that is really not any better. The alternative would be to share
the same do_dtt() function, with it avoiding the i2c code if
CONFIG_SYS_DTT_BUS_NUM is defined, and using a single sensor number 0 if
CONFIG_DTT_SENSORS is not defined. That could use much of the same code
(perhaps with a weak function for dtt_init_one(). But that is probably
trying too hard - if support for multiple TMU sensors is required in the
future we can worry about it then.
Sorry for the trouble.
Regards,
Simon
Regards,
Akshay
--- *Original Message* ---
*Sender* : Simon Glasss...@chromium.org
*Date* : Jan 23, 2013 05:51 (GMT+09:00)
*Title* : Re: [PATCH 6/7 v5] TMU: Add TMU support in dtt command
Hi Akshay,
On Mon, Jan 21, 2013 at 3:11 AM, Akshay Saraswat **wrote:
Add generic TMU support alongwith i2c sensors in dtt command
to enable temperature reading in cases where TMU is present
instead of i2c sensors.
Signed-off-by: Akshay Saraswat **
---
Changes since v4:
- Removed tmu command and added to dtt.
common/cmd_dtt.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/common/cmd_dtt.c b/common/cmd_dtt.c
index cd94423..715f4ba 100644
--- a/common/cmd_dtt.c
+++ b/common/cmd_dtt.c
@@ -28,6 +28,20 @@
#include **
#include **
+#if defined CONFIG_TMU_CMD_DTT
+#include **
+
+void dtt_get_temp(void)
+{
+ int cur_temp;
+
+ if (tmu_monitor(cur_temp) == TMU_STATUS_INIT)
+ printf(TMU is in unknown state, temperature is invalid
\n);
puts()
Should return an error result here so that do_dtt() returns 1.
+ else
+ printf(Current temperature: %u degrees Celsius \n,
cur_temp);
+}
+
+#else
static unsigned long sensor_initialized;
static void _initialize_dtt(void)
@@ -59,9 +73,13 @@ void dtt_init(void)
/* switch back to original I2C bus */
I2C_SET_BUS(old_bus);
}
+#endif
int do_dtt (cmd_tbl_t * cmdtp, int flag, int argc, char * const argv[])
{
+#if defined CONFIG_TMU_CMD_DTT
+ dtt_get_temp();
+#else
How about creating two versions of the dtt_get_temp() function: one
with your code and one with the old code? Then you don't have an
#ifdef here.
int i;
unsigned char sensors[] = CONFIG_DTT_SENSORS;
int old_bus;
@@ -83,6 +101,7 @@ int do_dtt (cmd_tbl_t * cmdtp, int flag, int argc,
char * const argv[])
/* switch back to original I2C bus */
I2C_SET_BUS(old_bus);
+#endif
return 0;
} /* do_dtt() */
--
1.7.9.5
Regards,
Simon
201301232033203_QKNMBDIF.gif___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 6/9 v6] TMU: Add TMU support in dtt command
On Thu, Jan 24, 2013 at 4:24 AM, Akshay Saraswat aksha...@samsung.com wrote:
Add generic TMU support alongwith i2c sensors in dtt command
to enable temperature reading in cases where TMU is present
instead of i2c sensors.
Signed-off-by: Akshay Saraswat aksha...@samsung.com
---
Changes since v5:
- Changed 'pirntf' to 'puts'.
- Added 'return -1' in case of erroneous tmu_state.
Acked-by: Simon Glass s...@chromium.org
common/cmd_dtt.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/common/cmd_dtt.c b/common/cmd_dtt.c
index cd94423..493f643 100644
--- a/common/cmd_dtt.c
+++ b/common/cmd_dtt.c
@@ -28,6 +28,23 @@
#include dtt.h
#include i2c.h
+#if defined CONFIG_TMU_CMD_DTT
+#include tmu.h
+
+int dtt_get_temp(void)
+{
+ int cur_temp;
+
+ if (tmu_monitor(cur_temp) == TMU_STATUS_INIT) {
+ puts(TMU is in unknown state, temperature is invalid\n);
+ return -1;
+ } else {
+ printf(Current temperature: %u degrees Celsius\n, cur_temp);
+ return 0;
+ }
+}
+
+#else
static unsigned long sensor_initialized;
static void _initialize_dtt(void)
@@ -59,9 +76,13 @@ void dtt_init(void)
/* switch back to original I2C bus */
I2C_SET_BUS(old_bus);
}
+#endif
int do_dtt (cmd_tbl_t * cmdtp, int flag, int argc, char * const argv[])
{
+#if defined CONFIG_TMU_CMD_DTT
+ return dtt_get_temp();
+#else
int i;
unsigned char sensors[] = CONFIG_DTT_SENSORS;
int old_bus;
@@ -85,6 +106,7 @@ int do_dtt (cmd_tbl_t * cmdtp, int flag, int argc, char *
const argv[])
I2C_SET_BUS(old_bus);
return 0;
+#endif
} /* do_dtt() */
/***/
--
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] corenet: Disable video on P2020DS
On Jan 25, 2013, at 12:50 PM, Tom Rini wrote: On Fri, Jan 25, 2013 at 10:38:01AM -0600, Andy Fleming wrote: The P2020DS build had grown too large, and video support isn't enabled in almost any other Freescale board. Disabling it allows us to keep building, and provides options for reenabling it later. Signed-off-by: Andy Fleming aflem...@freescale.com Now we may start having dead code around, yes? Can you perhaps get away with making this be disable video or something else and add a P2020DS_video boards.cfg entry or similar? Thanks! There doesn't appear to be any 2020-specific code in drivers/video/. The truth is, I doubt the code gets more than compile-tested by the setting being there. Also, as noted, P1022 defines it, in addition to MPC8536, MPC8544, MPC8572, MPC8610, and MPC8641. I'd rather not hack up a video config just for P2020, if possible. Andy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 7/7] EXYNOS5: Snow: Add a configuration file
Hi Rajeshwari, On Wed, Jan 23, 2013 at 11:13 PM, Rajeshwari Birje rajeshwari.bi...@gmail.com wrote: Hi Simon, Thank you for comments. On Tue, Jan 22, 2013 at 8:28 PM, Simon Glass s...@chromium.org wrote: Hi Rajeshwari, On Mon, Jan 21, 2013 at 2:52 AM, Rajeshwari Shinde rajeshwar...@samsung.com wrote: This patch adds the configuration file for Snow Board and defines the same in boards.cfg. The Audio codec required for SMDK5250 and Snow are different hence they are defined in the corresponding configuration files. Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com --- boards.cfg |1 + include/configs/exynos5250-dt.h |1 - include/configs/smdk5250.h |1 + include/configs/snow.h | 34 ++ 4 files changed, 36 insertions(+), 1 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 gonisamsung smdkc100 arm armv7 smdkc100 samsungs5pc1xx origen arm armv7 origen samsungexynos s5pc210_universalarm armv7 universal_c210 samsungexynos +snowarm armv7 smdk5250 samsungexynos smdk5250arm armv7 smdk5250 samsungexynos smdkv310arm armv7 smdkv310 samsungexynos tratsarm armv7 trats samsungexynos diff --git a/include/configs/exynos5250-dt.h b/include/configs/exynos5250-dt.h index a01fb96..7b9c393 100644 --- a/include/configs/exynos5250-dt.h +++ b/include/configs/exynos5250-dt.h @@ -297,7 +297,6 @@ #ifdef CONFIG_CMD_SOUND #define CONFIG_SOUND #define CONFIG_I2S -#define CONFIG_SOUND_WM8994 #endif /* Enable devicetree support */ diff --git a/include/configs/smdk5250.h b/include/configs/smdk5250.h index 81f83a8..b23b5bc 100644 --- a/include/configs/smdk5250.h +++ b/include/configs/smdk5250.h @@ -30,4 +30,5 @@ #undef CONFIG_DEFAULT_DEVICE_TREE #define CONFIG_DEFAULT_DEVICE_TREE exynos5250-smdk5250 +#define CONFIG_SOUND_WM8994 #endif /* __CONFIG_SMDK_H */ diff --git a/include/configs/snow.h b/include/configs/snow.h new file mode 100644 index 000..be38635 --- /dev/null +++ b/include/configs/snow.h @@ -0,0 +1,34 @@ +/* + * Copyright (C) 2012 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 + +#define CONFIG_SOUND_MAX98095 Really it would be better if they could share the same config, with just the CONFIG_DEFAULT_DEVICE_TREE difference. Isn't there code to select the right codec based on the FDT nodes? Maybe I have this wrong, not sure. Actually we do decode the codec from DTS file. But we need to define this to compile the corresponding codec file. And I felt since the codec is different for both the boards we can add them in the respective config file. Also in case of Non FDT we define the values based on this codec define. Well keep in mind that if we want the same U-Boot to boot on all exynos5250 boards then we will need to define both CONFIGs in the config file and rely on the FDT to make it work. What happens if you define both codecs in smdk5250.h? Also note that at built time we don't know whether we are booting on snow or smdk5250 (just as with the kernel), and we only find out when we start. Wasn't there a plan to have a exynos5250_dt.h config file? If so, then perhaps that file can define both codec CONFIGs, and your new snow file can include that instead? Regards, Simon +#endif /* __CONFIG_SMDK_H */ -- 1.7.4.4 Regards,
Re: [U-Boot] [PATCH 2/7 V2] Sound: MAX98095: Add the driver for codec
On Thu, Jan 24, 2013 at 10:43 PM, Rajeshwari Shinde rajeshwar...@samsung.com wrote: This patch adds the driver for codec MAX98095 required by Snow Board Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com Acked-by: Simon Glass s...@chromium.org --- Changes in V2: - None drivers/sound/Makefile |1 + drivers/sound/max98095.c | 550 ++ drivers/sound/max98095.h | 311 ++ 3 files changed, 862 insertions(+), 0 deletions(-) create mode 100644 drivers/sound/max98095.c create mode 100644 drivers/sound/max98095.h ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/7 V2] Sound: Support for MAX98095 codec in driver
Hi Rajeshwari,
On Thu, Jan 24, 2013 at 10:43 PM, Rajeshwari Shinde
rajeshwar...@samsung.com wrote:
This patchs adds support for MAX98095 codec in
sound driver.
Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com
---
Changes in V2:
- None
arch/arm/include/asm/arch-exynos/sound.h | 10 +-
drivers/sound/sound.c| 13 +++--
include/sound.h |1 +
3 files changed, 21 insertions(+), 3 deletions(-)
diff --git a/arch/arm/include/asm/arch-exynos/sound.h
b/arch/arm/include/asm/arch-exynos/sound.h
index d1bd2f6..a216b00 100644
--- a/arch/arm/include/asm/arch-exynos/sound.h
+++ b/arch/arm/include/asm/arch-exynos/sound.h
@@ -33,6 +33,7 @@
#define I2S_RFS256
#define I2S_BFS32
+#ifdef CONFIG_SOUND_WM8994
/* I2C values */
#define AUDIO_I2C_BUS 1
#define AUDIO_I2C_REG 0x1a
@@ -40,5 +41,12 @@
/* Audio Codec */
#define AUDIO_CODECwm8994
-#define AUDIO_COMPAT 1
+#else /* CONFIG_SOUND_MAX98095 */
+/* I2C values */
+#define AUDIO_I2C_BUS 7
+#define AUDIO_I2C_REG 0x22
+
+/* Audio Codec */
+#define AUDIO_CODECmax98095
+#endif
#endif
I don't think these should go in the arch exynos file, since they are
board settings. Do you really need audio to work when you are not
using CONFIG_OF_CONTROL? Perhaps that can be an exynos_dt-only
feature?
If you do need it, then the normal procedure is to define new CONFIGs
for the bus, address, codec name, etc. Then these need to be set in
the board config header file, like smdk5250.h. For the FDT case we
really need to avoid this though, and just use the FDT for this
information.
Regards,
Simon
diff --git a/drivers/sound/sound.c b/drivers/sound/sound.c
index fa8432d..a74590b 100644
--- a/drivers/sound/sound.c
+++ b/drivers/sound/sound.c
@@ -31,6 +31,7 @@
#include sound.h
#include asm/arch/sound.h
#include wm8994.h
+#include max98095.h
/* defines */
#define SOUND_400_HZ 400
@@ -143,17 +144,25 @@ static int codec_init(const void *blob, struct
i2stx_info *pi2s_tx)
#else
codectype = AUDIO_CODEC;
#endif
+#ifdef CONFIG_SOUND_WM8994
if (!strcmp(codectype, wm8994)) {
/* Check the codec type and initialise the same */
ret = wm8994_init(blob, WM8994_AIF2,
pi2s_tx-samplingrate,
(pi2s_tx-samplingrate * (pi2s_tx-rfs)),
pi2s_tx-bitspersample, pi2s_tx-channels);
+#endif
+#ifdef CONFIG_SOUND_MAX98095
+ if (!strcmp(codectype, max98095)) {
+ ret = max98095_init(blob, pi2s_tx-samplingrate,
+ (pi2s_tx-samplingrate * (pi2s_tx-rfs)),
+ pi2s_tx-bitspersample);
+#endif
} else {
- debug(%s: Unknown code type %s\n, __func__,
- codectype);
+ debug(%s: Unknown codec type %s\n, __func__, codectype);
return -1;
}
+
if (ret) {
debug(%s: Codec init failed\n, __func__);
return -1;
diff --git a/include/sound.h b/include/sound.h
index d73839d..94922f6 100644
--- a/include/sound.h
+++ b/include/sound.h
@@ -28,6 +28,7 @@
enum en_sound_codec {
CODEC_WM_8994,
CODEC_WM_8995,
+ CODEC_MAX_98095,
CODEC_MAX
};
--
1.7.4.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/7 V2] EXYNOS5: GPIO to enable MAX98095
On Thu, Jan 24, 2013 at 10:43 PM, Rajeshwari Shinde
rajeshwar...@samsung.com wrote:
This patch sets high a GPIO to enable the codec MAX98095
Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com
Acked-by: Simon Glass s...@chromium.org
---
Changes in V2:
- None
board/samsung/smdk5250/smdk5250.c | 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/board/samsung/smdk5250/smdk5250.c
b/board/samsung/smdk5250/smdk5250.c
index 12cc03e..6f2e067 100644
--- a/board/samsung/smdk5250/smdk5250.c
+++ b/board/samsung/smdk5250/smdk5250.c
@@ -56,6 +56,18 @@ int board_usb_vbus_init(void)
}
#endif
+#ifdef CONFIG_SOUND_MAX98095
+static void board_enable_audio_codec(void)
+{
+ struct exynos5_gpio_part1 *gpio1 = (struct exynos5_gpio_part1 *)
+ samsung_get_base_gpio_part1();
+
+ /* Enable MAX98095 Codec */
+ s5p_gpio_direction_output(gpio1-x1, 7, 1);
+ s5p_gpio_set_pull(gpio1-x1, 7, GPIO_PULL_NONE);
+}
+#endif
+
int board_init(void)
{
gd-bd-bi_boot_params = (PHYS_SDRAM_1 + 0x100UL);
@@ -65,6 +77,9 @@ int board_init(void)
#ifdef CONFIG_USB_EHCI_EXYNOS
board_usb_vbus_init();
#endif
+#ifdef CONFIG_SOUND_MAX98095
+ board_enable_audio_codec();
+#endif
return 0;
}
--
1.7.4.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/7 V2] EXYNOS5: FDT: Add compatible strings for MAX98095
On Thu, Jan 24, 2013 at 10:43 PM, Rajeshwari Shinde
rajeshwar...@samsung.com wrote:
Add required compatible information for MAX98095 codec
Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com
Acked-by: Simon Glass s...@chromium.org
---
Changes in V2:
- None
include/fdtdec.h |1 +
lib/fdtdec.c |1 +
2 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/include/fdtdec.h b/include/fdtdec.h
index f77d195..e76cdc1 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -79,6 +79,7 @@ enum fdt_compat_id {
COMPAT_SAMSUNG_EXYNOS_EHCI, /* Exynos EHCI controller */
COMPAT_SAMSUNG_EXYNOS_USB_PHY, /* Exynos phy controller for usb2.0 */
COMPAT_MAXIM_MAX77686_PMIC, /* MAX77686 PMIC */
+ COMPAT_MAXIM_98095_CODEC, /* MAX98095 Codec */
COMPAT_COUNT,
};
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index 16921e1..a5f770f 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -54,6 +54,7 @@ static const char * const compat_names[COMPAT_COUNT] = {
COMPAT(SAMSUNG_EXYNOS_EHCI, samsung,exynos-ehci),
COMPAT(SAMSUNG_EXYNOS_USB_PHY, samsung,exynos-usb-phy),
COMPAT(MAXIM_MAX77686_PMIC, maxim,max77686_pmic),
+ COMPAT(MAXIM_98095_CODEC, maxim,max98095-codec),
};
const char *fdtdec_get_compatible(enum fdt_compat_id id)
--
1.7.4.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 06/11] tegra20: switch over seaboard and ventana to use tablebased pinmux
Hi Lucas, On Fri, Jan 25, 2013 at 7:22 AM, Lucas Stach d...@lynxeye.de wrote: Am Freitag, den 25.01.2013, 06:54 +1300 schrieb Simon Glass: Hi Lucas, On Fri, Jan 25, 2013 at 5:48 AM, Lucas Stach d...@lynxeye.de wrote: Init pinmux in one shot, in order to avoid any conflicts. Signed-off-by: Lucas Stach d...@lynxeye.de --- board/nvidia/seaboard/seaboard.c | 133 +-- include/configs/seaboard.h | 3 + include/configs/ventana.h| 3 + 3 files changed, 121 insertions(+), 18 deletions(-) This seems like a lot of code and presumably quite a bit of duplication between boards. What sort of conflicts does this avoid, and is it the only way of avoiding them? I don't see it as duplication, but as explicitly spelling out how the pinmux configuration should be set up on a certain board. I mean that the table is very similar for different boards, so looks like duplicated coded (133 very similar lines for each board). Also, this seems to break FDT use. At present it is possible (I think) to boot the same U-Boot on any board, with the device tree specifying the config. With your change that is no longer possible, I think? Looking ahead to T114 I see a similar problem. The funcmux approach was a compromise in that we could just select appropriate values for each function - there was no agreement on how to put this in the FDT though (my intention was that it would depend on the kernel binding, but that is now defined, so what excuse do we have for not implementing it in U-Boot?). Before this change we would leave some pads uninitialised in their (random) reset configuration. For example on the Colibri this leads to NAND not working as it's wired up to the KBC pads. If we only configure those, ATC will remain in it's reset state and would be also configured to the NAND function, which leads to fail. Having an explicit, known to be conflict free configuration for all pads avoids all those unpleasant surprises. Well yes, but we seem to be right back to where we started, with the FDT unable to describe a key feature of the boards (pinmux). Also, how does this deal with drivers that want to support different configurations, such as 4/8 bit MMC, UART flow control, etc.? How does this fit with what the device tree pinmux specifies in the kernel, and why would we not move to using that? This is just the pinmux. You have to make sure to match the pinmux with your driver configuration. This tablebased approach is the same thing as what is done with Tegra30 in U-Boot. It's not as runtime flexible as the pinmux used in the Linux kernel, but also quite a fair bit simpler. I don't see any platform that would need anything other than the default configuration in U-Boot, so we don't need the muxing stuff provided by the pinmux framework in the kernel. Fair enough, simple is good, but I'm not sure it will do the job. If we create different variants of a board, how exactly will we describe the differences other than by creating a new config, separate U-Boot build, etc.? While running U-Boot we want to keep most of the pads in tristate and just enable the ones used by U-Boot itself (boot devices, GPIOs, LCD pins, etc.), so using the plain kernel pinmux config isn't going to work. So I think the table based approach is a good compromise between the need of having an comprehensively defined pinmux, simplicity and effort needed to define the pinmux. OK. Can you think of a way to implement this so that we have: board/nvidia/common/tegra20_dt.c and the resulting image can run on all T20 boards (given an appropriate DT)? Regards, Simon Regards, Lucas ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] MAKEALL: add support for per architecture toolchains
On Fri, Jan 25, 2013 at 7:48 AM, Allen Martin amar...@nvidia.com wrote:
Add support for per architecture CROSS_COMPILE toolchain definitions
via CROSS_COMPILE_ARCH where ARCH is any of the supported u-boot
architectures. This allows building every supported u-boot board in a
single pass of MAKEALL.
Signed-off-by: Allen Martin amar...@nvidia.com
Acked-by: Simon Glass s...@chromium.org
See below for a small suggestion.
---
MAKEALL | 32 +---
1 file changed, 25 insertions(+), 7 deletions(-)
diff --git a/MAKEALL b/MAKEALL
index 5b06c54..18b4e4d 100755
--- a/MAKEALL
+++ b/MAKEALL
@@ -35,6 +35,9 @@ usage()
Environment variables:
BUILD_NCPUS number of parallel make jobs (default: auto)
CROSS_COMPILEcross-compiler toolchain prefix (default: )
+ CROSS_COMPILE_ARM cross-compiler toolchain prefix for
+ architecture ARM. Substitute ARM for any
+ supported architecture (default: )
Perhaps better expressed as CROSS_COMPILE_ARCH?
MAKEALL_LOGDIR output all logs to here (default: ./LOG/)
BUILD_DIRoutput build directory (default: ./)
BUILD_NBUILDSnumber of parallel targets (default: 1)
@@ -180,13 +183,6 @@ else
JOBS=
fi
-
-if [ ${CROSS_COMPILE} ] ; then
- MAKE=make CROSS_COMPILE=${CROSS_COMPILE}
-else
- MAKE=make
-fi
-
if [ ${MAKEALL_LOGDIR} ] ; then
LOG_DIR=${MAKEALL_LOGDIR}
else
@@ -585,6 +581,18 @@ get_target_maintainers() {
echo $mail
}
+get_target_arch() {
+ local target=$1
+
+ # Automatic mode
+ local line=`egrep -i ^[[:space:]]*${target}[[:space:]] boards.cfg`
+
+ if [ -z ${line} ] ; then echo ; return ; fi
+
+ set ${line}
+ echo $2
+}
+
list_target() {
if [ $PRINT_MAINTS != 'y' ] ; then
echo $1
@@ -655,6 +663,16 @@ build_target() {
export BUILD_DIR=${output_dir}
+ target_arch=$(get_target_arch ${target})
+ eval cross_toolchain=\$CROSS_COMPILE_${target_arch^^}
+ if [ ${cross_toolchain} ] ; then
+ MAKE=make CROSS_COMPILE=${cross_toolchain}
+ elif [ ${CROSS_COMPILE} ] ; then
+ MAKE=make CROSS_COMPILE=${CROSS_COMPILE}
+ else
+ MAKE=make
+ fi
+
${MAKE} distclean /dev/null
${MAKE} -s ${target}_config
--
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/7] tegra: usb: set USB_PORTS_MAX to correct value
On Sat, Jan 26, 2013 at 3:41 AM, Lucas Stach d...@lynxeye.de wrote:
Both Tegra20 and Tegra30 have a max of 3 USB controllers.
Signed-off-by: Lucas Stach d...@lynxeye.de
Acked-by: Simon Glass s...@chromium.org
---
arch/arm/cpu/armv7/tegra20/usb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/cpu/armv7/tegra20/usb.c
b/arch/arm/cpu/armv7/tegra20/usb.c
index 1bccf2b..f151fb2 100644
--- a/arch/arm/cpu/armv7/tegra20/usb.c
+++ b/arch/arm/cpu/armv7/tegra20/usb.c
@@ -44,7 +44,7 @@
#endif
enum {
- USB_PORTS_MAX = 4,/* Maximum ports we allow */
+ USB_PORTS_MAX = 3,/* Maximum ports we allow */
};
/* Parameters we need for USB */
--
1.8.0.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 02/10] lcd, tegra: remove unused cursor functions
Jeroen,
How will this all go in? Do you expect Anatolij to take it in via the main repo
(u-boot.git/master)?
LGTM, BTW
Tom
-Original Message-
From: s...@google.com [mailto:s...@google.com] On Behalf Of Simon Glass
Sent: Friday, January 25, 2013 1:38 PM
To: Jeroen Hofstee
Cc: u-boot@lists.denx.de; Tom Warren
Subject: Re: [U-Boot] [PATCH 02/10] lcd, tegra: remove unused cursor
functions
+Tom
On Sun, Jan 13, 2013 at 11:07 AM, Jeroen Hofstee jer...@myspectrum.nl
wrote:
cc: Anatolij Gustschin ag...@denx.de
cc: Simon Glass sjg.chromium.org
Signed-off-by: Jeroen Hofstee jer...@myspectrum.nl
Acked-by: Simon Glass s...@chromium.org
---
drivers/video/tegra.c | 52
-
1 file changed, 52 deletions(-)
diff --git a/drivers/video/tegra.c b/drivers/video/tegra.c index
3709d0b..26a96a5 100644
--- a/drivers/video/tegra.c
+++ b/drivers/video/tegra.c
@@ -73,62 +73,10 @@ vidinfo_t panel_info = {
.vl_col = -1,
};
-char lcd_cursor_enabled;
-
-ushort lcd_cursor_width;
-ushort lcd_cursor_height;
-
#ifndef CONFIG_OF_CONTROL
#error You must enable CONFIG_OF_CONTROL to get Tegra LCD support
#endif
-void lcd_cursor_size(ushort width, ushort height) -{
- lcd_cursor_width = width;
- lcd_cursor_height = height;
-}
-
-void lcd_toggle_cursor(void)
-{
- ushort x, y;
- uchar *dest;
- ushort row;
-
- x = console_col * lcd_cursor_width;
- y = console_row * lcd_cursor_height;
- dest = (uchar *)(lcd_base + y * lcd_line_length + x * (1
LCD_BPP) /
- 8);
-
- for (row = 0; row lcd_cursor_height; ++row, dest +=
lcd_line_length)
{
- ushort *d = (ushort *)dest;
- ushort color;
- int i;
-
- for (i = 0; i lcd_cursor_width; ++i) {
- color = *d;
- color ^= lcd_getfgcolor();
- *d = color;
- ++d;
- }
- }
-}
-
-void lcd_cursor_on(void)
-{
- lcd_cursor_enabled = 1;
- lcd_toggle_cursor();
-}
-void lcd_cursor_off(void)
-{
- lcd_cursor_enabled = 0;
- lcd_toggle_cursor();
-}
-
-char lcd_is_cursor_enabled(void)
-{
- return lcd_cursor_enabled;
-}
-
static void update_panel_size(struct fdt_disp_config *config) {
panel_info.vl_col = config-width;
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
--
nvpublic
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 5/7] tegra: usb: various small cleanups
On Sat, Jan 26, 2013 at 3:41 AM, Lucas Stach d...@lynxeye.de wrote:
Remove unneeded headers, function prototype and stale comment, that
doesn't match the actual codebase anymore.
Signed-off-by: Lucas Stach d...@lynxeye.de
Acked-by: Simon Glass s...@chromium.org
---
arch/arm/cpu/armv7/tegra20/usb.c| 13 +
arch/arm/include/asm/arch-tegra20/usb.h | 3 ---
2 files changed, 1 insertion(+), 15 deletions(-)
diff --git a/arch/arm/cpu/armv7/tegra20/usb.c
b/arch/arm/cpu/armv7/tegra20/usb.c
index e4165e0..3fdd5df 100644
--- a/arch/arm/cpu/armv7/tegra20/usb.c
+++ b/arch/arm/cpu/armv7/tegra20/usb.c
@@ -25,21 +25,15 @@
#include asm/io.h
#include asm-generic/gpio.h
#include asm/arch/clock.h
-#include asm/arch/gpio.h
-#include asm/arch/pinmux.h
-#include asm/arch/tegra.h
#include asm/arch/usb.h
#include usb/ulpi.h
-#include asm/arch-tegra/clk_rst.h
-#include asm/arch-tegra/sys_proto.h
-#include asm/arch-tegra/uart.h
#include libfdt.h
#include fdtdec.h
#ifdef CONFIG_USB_ULPI
#ifndef CONFIG_USB_ULPI_VIEWPORT
#error To use CONFIG_USB_ULPI on Tegra Boards you have to also \
- define CONFIG_USB_ULPI_VIEWPORT
+ define CONFIG_USB_ULPI_VIEWPORT
#endif
#endif
@@ -191,11 +185,6 @@ void usbf_reset_controller(struct fdt_usb *config,
struct usb_ctlr *usbctlr)
/* Enable the UTMIP PHY */
if (config-utmi)
setbits_le32(usbctlr-susp_ctrl, UTMIP_PHY_ENB);
-
- /*
-* TODO: where do we take the USB1 out of reset? The old code would
-* take USB3 out of reset, but not USB1. This code doesn't do either.
-*/
}
/* set up the UTMI USB controller with the parameters provided */
diff --git a/arch/arm/include/asm/arch-tegra20/usb.h
b/arch/arm/include/asm/arch-tegra20/usb.h
index fdbd127..b18c850 100644
--- a/arch/arm/include/asm/arch-tegra20/usb.h
+++ b/arch/arm/include/asm/arch-tegra20/usb.h
@@ -243,9 +243,6 @@ struct usb_ctlr {
#define VBUS_VLD_STS (1 26)
-/* Change the USB host port into host mode */
-void usb_set_host_mode(void);
-
/* Setup USB on the board */
int board_usb_init(const void *blob);
--
1.8.0.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 6/7] tegra: usb: move implementation into right directory
On Sat, Jan 26, 2013 at 3:41 AM, Lucas Stach d...@lynxeye.de wrote:
This moves the Tegra USB implementation into the drivers/usb/host
directory. Note that this merges the old
/arch/arm/cpu/armv7/tegra20/usb.c file into ehci-tegra.c. No code
changes, just moving stuff around.
v2: While at it also move some defines and the usb.h header file to make
usb driver usable for Tegra30.
NOTE: A lot more work is required to properly init the PHYs and PLL_U on
Tegra30, this is just to make porting easier and it does no harm here.
Signed-off-by: Lucas Stach d...@lynxeye.de
Acked-by: Simon Glass s...@chromium.org
I have to admit I am not sure what happened to the existing
drivers/usb/host/ehci-tegra.c, but I'm sure you have it covered.
---
arch/arm/cpu/armv7/tegra20/Makefile| 1 -
arch/arm/cpu/armv7/tegra20/usb.c | 555
-
.../include/asm/{arch-tegra20 = arch-tegra}/usb.h | 0
arch/arm/include/asm/arch-tegra20/tegra.h | 1 -
arch/arm/include/asm/arch-tegra30/tegra.h | 2 +
board/nvidia/common/board.c| 2 +-
drivers/usb/host/ehci-tegra.c | 535 +++-
7 files changed, 536 insertions(+), 560 deletions(-)
delete mode 100644 arch/arm/cpu/armv7/tegra20/usb.c
rename arch/arm/include/asm/{arch-tegra20 = arch-tegra}/usb.h (100%)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] common/lcd.c: cleanup use of global variables
On 01/05/2013 08:45 PM, Wolfgang Denk wrote: lcd_color_fg and lcd_color_bg had to be declared in board specific code, but were not actually used there; in addition, we have getter / setter functions for these, which were not used either. Get rid of the global variables, and use the getter function where needed (so far no setter calls are needed). Signed-off-by: Wolfgang Denk w...@denx.de Cc: Alessandro Rubini rub...@unipv.it Cc: Anatolij Gustschin ag...@denx.de Cc: Bo Shen voice.s...@atmel.com Cc: Haavard Skinnemoen haavard.skinnem...@atmel.com Cc: Kyungmin Park kyungmin.p...@samsung.com Cc: Marek Vasut marek.va...@gmail.com Cc: Minkyu Kang mk7.k...@samsung.com Cc: Nikita Kiryanov nik...@compulab.co.il Cc: Simon Glass s...@chromium.org Cc: Stelian Pop stel...@popies.net Cc: Tom Warren twar...@nvidia.com --- Acked-by: Jeroen Hofstee jer...@myspectrum.nl ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 06/11] tegra20: switch over seaboard and ventana to use tablebased pinmux
Hello Simon, Am Samstag, den 26.01.2013, 10:20 +1300 schrieb Simon Glass: Hi Lucas, On Fri, Jan 25, 2013 at 7:22 AM, Lucas Stach d...@lynxeye.de wrote: Am Freitag, den 25.01.2013, 06:54 +1300 schrieb Simon Glass: Hi Lucas, On Fri, Jan 25, 2013 at 5:48 AM, Lucas Stach d...@lynxeye.de wrote: Init pinmux in one shot, in order to avoid any conflicts. Signed-off-by: Lucas Stach d...@lynxeye.de --- board/nvidia/seaboard/seaboard.c | 133 +-- include/configs/seaboard.h | 3 + include/configs/ventana.h| 3 + 3 files changed, 121 insertions(+), 18 deletions(-) This seems like a lot of code and presumably quite a bit of duplication between boards. What sort of conflicts does this avoid, and is it the only way of avoiding them? I don't see it as duplication, but as explicitly spelling out how the pinmux configuration should be set up on a certain board. I mean that the table is very similar for different boards, so looks like duplicated coded (133 very similar lines for each board). Also, this seems to break FDT use. At present it is possible (I think) to boot the same U-Boot on any board, with the device tree specifying the config. With your change that is no longer possible, I think? Looking ahead to T114 I see a similar problem. The funcmux approach was a compromise in that we could just select appropriate values for each function - there was no agreement on how to put this in the FDT though (my intention was that it would depend on the kernel binding, but that is now defined, so what excuse do we have for not implementing it in U-Boot?). That Tegra30 doesn't do so either. ;) But I agree, that's no valid excuse and we should resolve this before Tegra114 introduces more of this stuff. See below. Before this change we would leave some pads uninitialised in their (random) reset configuration. For example on the Colibri this leads to NAND not working as it's wired up to the KBC pads. If we only configure those, ATC will remain in it's reset state and would be also configured to the NAND function, which leads to fail. Having an explicit, known to be conflict free configuration for all pads avoids all those unpleasant surprises. Well yes, but we seem to be right back to where we started, with the FDT unable to describe a key feature of the boards (pinmux). I see your point now. The obvious answer for now is: it's not regressing functionality, as we were never able to boot the same U-Boot image by just changing the DT. But yes in the end we want to pack this information into the DT files. But even then it would be nice if people would test this pachset, as I imagine DT based pinmux is the same as tablebased pinmux, just in a slightly different flavour. ;) So if people test the tablebased config now, we can do the conversion to DT based with a lot more confidence. I'll look into using the kernel pinmux binding minus the MUX stuff, as I think there's no real reason to have this in U-Boot. Regards, Lucas ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/7 V2] EXYNOS5: Add function to enable XXTI clock source
On Thu, Jan 24, 2013 at 10:43 PM, Rajeshwari Shinde
rajeshwar...@samsung.com wrote:
This patch adds funtion to enable XXTI clock source
required by MAX98095 codec.
Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com
Acked-by: Simon Glass s...@chromium.org
---
Changes in V2:
- Corrected multi-line comment style
arch/arm/cpu/armv7/exynos/power.c| 11 +++
arch/arm/include/asm/arch-exynos/power.h | 11 +++
2 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/arch/arm/cpu/armv7/exynos/power.c
b/arch/arm/cpu/armv7/exynos/power.c
index 8572cfd..8de30c1 100644
--- a/arch/arm/cpu/armv7/exynos/power.c
+++ b/arch/arm/cpu/armv7/exynos/power.c
@@ -105,3 +105,14 @@ void power_ps_hold_setup(void)
setbits_le32(power-ps_hold_control,
EXYNOS_PS_HOLD_CONTROL_DATA_HIGH);
}
+
+
+void power_enable_xclkout(void)
+{
+ struct exynos5_power *power =
+ (struct exynos5_power *)samsung_get_base_power();
+
+ /* use xxti for xclk out */
+ clrsetbits_le32(power-pmu_debug, PMU_DEBUG_CLKOUT_SEL_MASK,
+ PMU_DEBUG_XXTI);
+}
diff --git a/arch/arm/include/asm/arch-exynos/power.h
b/arch/arm/include/asm/arch-exynos/power.h
index 85e2cd9..09343d7 100644
--- a/arch/arm/include/asm/arch-exynos/power.h
+++ b/arch/arm/include/asm/arch-exynos/power.h
@@ -872,4 +872,15 @@ void set_dp_phy_ctrl(unsigned int enable);
* (e.g. power button).
*/
void power_ps_hold_setup(void);
+
+/* PMU_DEBUG bits [12:8] = 0x1000 selects XXTI clock source */
+#define PMU_DEBUG_XXTI 0x1000
+/* Mask bit[12:8] for xxti clock selection */
+#define PMU_DEBUG_CLKOUT_SEL_MASK 0x1f00
+
+/*
+ * Pmu debug is used for xclkout, enable xclkout with
+ * source as XXTI
+ */
+void power_enable_xclkout(void);
#endif
--
1.7.4.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2 V2] SF: Add driver for Gigabyte device GD25LQ and GD25Q64B
On Wed, Jan 23, 2013 at 7:30 PM, Rajeshwari Shinde
rajeshwar...@samsung.com wrote:
This patch adds driver for the gigabyte devices
GD25LQ and GD25Q64B required for Snow Board.
Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com
Acked-by: Simon Glass s...@chromium.org
---
Changes in V2:
- Added U-Boot copyright header to gigadevice.c
- Removed unnecessary blank lines.
drivers/mtd/spi/Makefile |1 +
drivers/mtd/spi/gigadevice.c | 81
++
drivers/mtd/spi/spi_flash.c |3 +
drivers/mtd/spi/spi_flash_internal.h |1 +
4 files changed, 86 insertions(+), 0 deletions(-)
create mode 100644 drivers/mtd/spi/gigadevice.c
diff --git a/drivers/mtd/spi/Makefile b/drivers/mtd/spi/Makefile
index 90f8392..ecbb210 100644
--- a/drivers/mtd/spi/Makefile
+++ b/drivers/mtd/spi/Makefile
@@ -32,6 +32,7 @@ endif
COBJS-$(CONFIG_SPI_FLASH) += spi_flash.o
COBJS-$(CONFIG_SPI_FLASH_ATMEL)+= atmel.o
COBJS-$(CONFIG_SPI_FLASH_EON) += eon.o
+COBJS-$(CONFIG_SPI_FLASH_GIGADEVICE) += gigadevice.o
COBJS-$(CONFIG_SPI_FLASH_MACRONIX) += macronix.o
COBJS-$(CONFIG_SPI_FLASH_SPANSION) += spansion.o
COBJS-$(CONFIG_SPI_FLASH_SST) += sst.o
diff --git a/drivers/mtd/spi/gigadevice.c b/drivers/mtd/spi/gigadevice.c
new file mode 100644
index 000..b5e1ebe
--- /dev/null
+++ b/drivers/mtd/spi/gigadevice.c
@@ -0,0 +1,81 @@
+/*
+ * Gigadevice SPI flash driver
+ * Copyright 2013, Samsung Electronics Co., Ltd.
+ * Author: Banajit Goswami banaji...@samsung.com
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include common.h
+#include malloc.h
+#include spi_flash.h
+
+#include spi_flash_internal.h
+
+struct gigadevice_spi_flash_params {
+ uint16_tid;
+ uint16_tnr_blocks;
+ const char *name;
+};
+
+static const struct gigadevice_spi_flash_params gigadevice_spi_flash_table[]
= {
+ {
+ .id = 0x6016,
+ .nr_blocks = 64,
+ .name = GD25LQ,
+ },
+ {
+ .id = 0x4017,
+ .nr_blocks = 128,
+ .name = GD25Q64B,
+ },
+};
+
+struct spi_flash *spi_flash_probe_gigadevice(struct spi_slave *spi, u8
*idcode)
+{
+ const struct gigadevice_spi_flash_params *params;
+ struct spi_flash *flash;
+ unsigned int i;
+
+ for (i = 0; i ARRAY_SIZE(gigadevice_spi_flash_table); i++) {
+ params = gigadevice_spi_flash_table[i];
+ if (params-id == ((idcode[1] 8) | idcode[2]))
+ break;
+ }
+
+ if (i == ARRAY_SIZE(gigadevice_spi_flash_table)) {
+ debug(SF: Unsupported Gigadevice ID %02x%02x\n,
+ idcode[1], idcode[2]);
+ return NULL;
+ }
+
+ flash = spi_flash_alloc_base(spi, params-name);
+ if (!flash) {
+ debug(SF: Failed to allocate memory\n);
+ return NULL;
+ }
+ /* page_size */
+ flash-page_size = 256;
+ /* sector_size = page_size * pages_per_sector */
+ flash-sector_size = flash-page_size * 16;
+ /* size = sector_size * sector_per_block * number of blocks */
+ flash-size = flash-sector_size * 16 * params-nr_blocks;
+
+ return flash;
+}
diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
index 17f3d3c..ee05171 100644
--- a/drivers/mtd/spi/spi_flash.c
+++ b/drivers/mtd/spi/spi_flash.c
@@ -305,6 +305,9 @@ static const struct {
#ifdef CONFIG_SPI_FLASH_EON
{ 0, 0x1c, spi_flash_probe_eon, },
#endif
+#ifdef CONFIG_SPI_FLASH_GIGADEVICE
+ { 0, 0xc8, spi_flash_probe_gigadevice, },
+#endif
#ifdef CONFIG_SPI_FLASH_MACRONIX
{ 0, 0xc2, spi_flash_probe_macronix, },
#endif
diff --git a/drivers/mtd/spi/spi_flash_internal.h
b/drivers/mtd/spi/spi_flash_internal.h
index 141cfa8..e0afbc3 100644
--- a/drivers/mtd/spi/spi_flash_internal.h
+++
Re: [U-Boot] Want to study U-Boot code
On Fri, 25 Jan 2013, Wolfgang Denk wrote: Dear Woody Wu, In message CAAsE_ue4VffAioQWzHPpyOZmzoFk9E5S7jj2+2BZuiK=c5y...@mail.gmail.com you wrote: I want to firstly get a picture to basically understand how u-boot work, especially on an ARM9 based board. I think not everyone who want to understand u-boot has to read the full code. Thank. This depends on your definition of understanding. On a highlevel, you might start with reaing and digesting the manual, eventually trying out how U-Boot works on some (real or emulated) board. if i can jump in, a good way to start playing is to configure and build for the sandbox architecture so you can run it on your x86 system. for the benefit of a couple friends, i whipped together a wiki page for that here: http://www.crashcourse.ca/wiki/index.php/U-Boot_sandbox very simple but enough to get you started, and you can match up running the commands with the underlying code. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 06/11] tegra20: switch over seaboard and ventana to use tablebased pinmux
Hi Lucas, On Sat, Jan 26, 2013 at 10:38 AM, Lucas Stach d...@lynxeye.de wrote: Hello Simon, Am Samstag, den 26.01.2013, 10:20 +1300 schrieb Simon Glass: Hi Lucas, On Fri, Jan 25, 2013 at 7:22 AM, Lucas Stach d...@lynxeye.de wrote: Am Freitag, den 25.01.2013, 06:54 +1300 schrieb Simon Glass: Hi Lucas, On Fri, Jan 25, 2013 at 5:48 AM, Lucas Stach d...@lynxeye.de wrote: Init pinmux in one shot, in order to avoid any conflicts. Signed-off-by: Lucas Stach d...@lynxeye.de --- board/nvidia/seaboard/seaboard.c | 133 +-- include/configs/seaboard.h | 3 + include/configs/ventana.h| 3 + 3 files changed, 121 insertions(+), 18 deletions(-) This seems like a lot of code and presumably quite a bit of duplication between boards. What sort of conflicts does this avoid, and is it the only way of avoiding them? I don't see it as duplication, but as explicitly spelling out how the pinmux configuration should be set up on a certain board. I mean that the table is very similar for different boards, so looks like duplicated coded (133 very similar lines for each board). Also, this seems to break FDT use. At present it is possible (I think) to boot the same U-Boot on any board, with the device tree specifying the config. With your change that is no longer possible, I think? Looking ahead to T114 I see a similar problem. The funcmux approach was a compromise in that we could just select appropriate values for each function - there was no agreement on how to put this in the FDT though (my intention was that it would depend on the kernel binding, but that is now defined, so what excuse do we have for not implementing it in U-Boot?). That Tegra30 doesn't do so either. ;) But I agree, that's no valid excuse and we should resolve this before Tegra114 introduces more of this stuff. See below. Before this change we would leave some pads uninitialised in their (random) reset configuration. For example on the Colibri this leads to NAND not working as it's wired up to the KBC pads. If we only configure those, ATC will remain in it's reset state and would be also configured to the NAND function, which leads to fail. Having an explicit, known to be conflict free configuration for all pads avoids all those unpleasant surprises. Well yes, but we seem to be right back to where we started, with the FDT unable to describe a key feature of the boards (pinmux). I see your point now. The obvious answer for now is: it's not regressing functionality, as we were never able to boot the same U-Boot image by just changing the DT. Well, kind of. In fact we were able to boot at 3 different T20 boards just by adding a 'funcmux' property to the device's node to select the required mux option for that driver. This code is no use on T30/T114, and was only a stop-gap anyway. But yes in the end we want to pack this information into the DT files. But even then it would be nice if people would test this pachset, as I imagine DT based pinmux is the same as tablebased pinmux, just in a slightly different flavour. ;) So if people test the tablebased config now, we can do the conversion to DT based with a lot more confidence. I'll look into using the kernel pinmux binding minus the MUX stuff, as I think there's no real reason to have this in U-Boot. Well I would rather than we get that running than switch to table-driven mux, assuming it is not too big a job? I imagine perhaps naively that a function could be written which parses the pinmux and sets it up in U-Boot - effectively using the FDT as the pinmux table. Regards, Simon Regards, Lucas ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 06/11] tegra20: switch over seaboard and ventana to use tablebased pinmux
Am Samstag, den 26.01.2013, 10:49 +1300 schrieb Simon Glass: [...] But yes in the end we want to pack this information into the DT files. But even then it would be nice if people would test this pachset, as I imagine DT based pinmux is the same as tablebased pinmux, just in a slightly different flavour. ;) So if people test the tablebased config now, we can do the conversion to DT based with a lot more confidence. I'll look into using the kernel pinmux binding minus the MUX stuff, as I think there's no real reason to have this in U-Boot. Well I would rather than we get that running than switch to table-driven mux, assuming it is not too big a job? I imagine perhaps naively that a function could be written which parses the pinmux and sets it up in U-Boot - effectively using the FDT as the pinmux table. That's my plan. But still even if we keep the binding the same, the actual pinmux config would differ between the kernel and U-Boot (a lot more pads kept in tristate in U-Boot). So as the FDT would effectively resemble the same tables I included in this patchset, some testing coverage of that would smoothen the transition. Regards, Lucas ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-mpc85xx.git
On Fri, Jan 25, 2013 at 10:45:19AM -0600, Andy Fleming wrote: README.mips: update known issues and TODOs (2013-01-16 10:52:08 +0100) are available in the git repository at: git://www.denx.de/git/u-boot-mpc85xx.git master for you to fetch changes up to 1342f7dd2c864889ce3ef6a78fe74155fd1f9a8f: corenet: Disable video on P2020DS (2013-01-25 10:32:22 -0600) Anatolij Gustschin (1): mpc8xxx: fix DDR init value to use CONFIG_MEM_INIT_VALUE Andy Fleming (1): corenet: Disable video on P2020DS Hongtao Jia (2): powerpc/mpc8572ds: Enable bank interleaving to cs0+cs1 for dual-rank DIMMs powerpc/mpc8544ds: Add USB controller support for MPC8544DS James Yang (5): Move DDR command parsing to separate function Fix data stage name matching issue Add copy command to FSL DDR interactive README.fsl-ddr typos and update to reflect hotkey powerpc/mpc8: FSL DDR debugger auto run of stored commands Poonam Aggrwal (2): powerpc/mpc85xx: Few updates for B4860 cpu changes powerpc/mpc85xx:Add support of B4420 SoC Prabhakar Kushwaha (8): board/T4240qds:Fix TLB and LAW size of NAND flash boards/T4240qds:Fix IFC AMASK init as per FPGA register space board/freescale/common:Add support of QTAG register powerpc/mpc85xx:Fix Core cluster configuration loop powerpc/t4240qds: Print FPGA detail version powerpc/mpc85xx: Add BSC9132/BSC9232 processor support powerpc/85xx: Add BSC9132QDS support board/common: Add support for QIXIS read/write using i2c Scott Wood (1): powerpc/mpc85xx: add support for MMUv2 page sizes Shaohui Xie (1): powerpc/p2041: move Lanes mux to board early init Shaveta Leekha (3): powerpc/qixis: enable qixis dump command and add switch dumping command powerpc/b4860qds: Add support to dump switch settings on b4860qds board powerpc/t4240qds: Add support to dump switch settings on t4240qds board Shengzhou Liu (1): powerpc/t4240: Adding workaround errata A-005871 Timur Tabi (1): powerpc/t4qds: move VSC3316 config data from t4qds.h to t4qds.c Vakul Garg (1): powerpc/mpc85xx: Add property 'fsl, sec-era' in device tree node 'crypto' Valentin Longchamp (2): powerpc/p2041: add RCW file for P2041RDB powerpc/p2041: set RCW and PBI files for .pbl build or P2041RDB York Sun (4): powerpc/mpc85xx: Reserve default boot page powerpc/t4240qds: Update IFC timing for NOR flash powerpc/b4860qds: Added Support for B4860QDS powerpc/mpc8xxx: Enable entering DDR debugging by key press MAINTAINERS |4 + arch/powerpc/cpu/mpc85xx/Makefile|5 + arch/powerpc/cpu/mpc85xx/b4860_ids.c |6 + arch/powerpc/cpu/mpc85xx/b4860_serdes.c | 60 ++ arch/powerpc/cpu/mpc85xx/bsc9132_serdes.c| 96 +++ arch/powerpc/cpu/mpc85xx/cmd_errata.c|4 + arch/powerpc/cpu/mpc85xx/cpu_init.c | 44 +- arch/powerpc/cpu/mpc85xx/fdt.c | 24 + arch/powerpc/cpu/mpc85xx/start.S |2 +- arch/powerpc/cpu/mpc85xx/tlb.c | 19 +- arch/powerpc/cpu/mpc8xxx/cpu.c |2 + arch/powerpc/cpu/mpc8xxx/ddr/ctrl_regs.c |4 + arch/powerpc/cpu/mpc8xxx/ddr/ddr.h |3 +- arch/powerpc/cpu/mpc8xxx/ddr/interactive.c | 324 ++--- arch/powerpc/cpu/mpc8xxx/ddr/main.c |8 +- arch/powerpc/cpu/mpc8xxx/fdt.c | 78 +- arch/powerpc/include/asm/config_mpc85xx.h| 39 +- arch/powerpc/include/asm/immap_85xx.h| 34 +- arch/powerpc/include/asm/mmu.h | 52 +- arch/powerpc/include/asm/processor.h |2 + board/freescale/b4860qds/Makefile| 54 ++ board/freescale/b4860qds/b4860qds.c | 505 + board/freescale/b4860qds/b4860qds.h | 26 + board/freescale/b4860qds/b4860qds_crossbar_con.h | 67 ++ board/freescale/b4860qds/b4860qds_qixis.h| 37 + board/freescale/b4860qds/ddr.c | 190 + board/freescale/b4860qds/eth_b4860qds.c | 338 + board/freescale/b4860qds/law.c | 44 ++ board/freescale/b4860qds/pci.c | 39 + board/freescale/b4860qds/tlb.c | 127 board/freescale/bsc9132qds/Makefile | 52 ++ board/freescale/bsc9132qds/README| 150 board/freescale/bsc9132qds/bsc9132qds.c | 406 +++ board/freescale/bsc9132qds/ddr.c | 209 ++ board/freescale/bsc9132qds/law.c | 35 + board/freescale/bsc9132qds/tlb.c | 92 +++
Re: [U-Boot] AM335X: Set fdt_high for AM335X devices to enable booting with Device Tree
On Tue, Sep 18, 2012 at 09:26:05AM -, hvaib...@ti.com wrote: For AM335X boards, such as the EVM and Bone Linux kernel fails to locate the device tree blob on boot. The reason being is that u-boot is copying the DT blob to the upper part of RAM when booting the kernel and the kernel is unable to access the blob. By setting the fdt_high variable to 0x (to prevent the copy) the kernel is able to locate the DT blob and boot. This patch is tested on BeagleBone platform. Signed-off-by: Vaibhav Hiremath hvaib...@ti.com Cc: Tom Rini tr...@ti.com So, a funny thing happened along the way since this patch. The newest revision of the EVM includes 1GB of DDR and thus we do now need this patch. Applied to u-boot-ti/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/3] pcm051: Add support for Phytec phyCORE-AM335x
On Fri, Jan 11, 2013 at 11:53:31AM +0100, Lars Poeschel wrote: From: Lars Poeschel poesc...@lemonage.de The board is named pcm051 and has this hardware: SOC: TI AM3359 DDR3-RAM: 2x MT41J256M8HX-15EIT:D 512MiB ETH 1: LAN8710AI SPI-Flash: W25Q64BVSSIG RTC: RV-4162-C7 I2C-EEPROM: CAT32WC32 NAND: MT29F4G08_VFPGA63 PMIC: TPS65910A3 LCD Supported: UART 1 MMC/SD ETH 1 USB I2C SPI Not yet supported: NAND RTC LCD Signed-off-by: Lars Poeschel poesc...@lemonage.de With the following added (due to another patch I pulled in) diff --git a/include/configs/pcm051.h b/include/configs/pcm051.h index 2096fcf..aa90ba9 100644 --- a/include/configs/pcm051.h +++ b/include/configs/pcm051.h @@ -295,6 +295,7 @@ #define CONFIG_NET_MULTI #define CONFIG_PHY_GIGE #define CONFIG_PHYLIB +#define CONFIG_PHY_ADDR0 #define CONFIG_PHY_SMSC #endif /* ! __CONFIG_PCM051_H */ Applied to u-boot-ti/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 04/11] tegra20: switch over tamonten platform to use tablebased pinmux
Am Freitag, den 25.01.2013, 14:04 -0800 schrieb Stephen Warren:
On 01/24/2013 08:48 AM, Lucas Stach wrote:
Init pinmux in one shot, in order to avoid any conflicts.
diff --git a/board/avionic-design/common/tamonten.c
b/board/avionic-design/common/tamonten.c
+static struct pingroup_config tamonten_pinmux[] = {
+ PINMUX_ENTRY(ATA, IDE, NORMAL, NORMAL), /* GPIO */
+ PINMUX_ENTRY(ATB, SDIO4, NORMAL, NORMAL), /* MMC */
...
I believe this initializes every single pingroup on the SoC to
something. In order to prevent any behavior changes, wouldn't it be
better to first fill in this table only with entries that achieve the
same pinmux programming that used to be performed by the C code you're
removing? Then, a separate later patch could fill in missing items in
the pinmux table. I think that'd end up being much safer and easier to
validate.
As I wrote in the cover letter this initializes the pinmux to the same
values the Linux kernel uses. I don't consider it a safer approach to
pull out the old pinmux from the C Code and then later building a
conflict free full muxtable out of this.
However I made sure to go through the C Code to see which pads need to
be un-tristated. At that time I cross-checked the table with the
functions used by the C Code. But as a human I'm not safe from mistakes.
Regards,
Lucas
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2, 1/1] omap4: allow the use of a plain text env file instead boot scripts
On Mon, Jan 07, 2013 at 03:51:20AM -, Javier Martinez Canillas wrote: For production systems it is better to use script images since they are protected by checksums and carry valuable information like name and timestamp. Also, you can't validate the content passed to env import. But for development, it is easier to use the env import command and plain text files instead of script-images. Since both OMAP4 supported boards (Panda and TI SDP4430) are used primarily for development, this patch allows U-Boot to load env var from a text file in case that an boot.scr script-image is not present. The variable uenvcmd (if existent) will be executed (using run) after uEnv.txt was loaded. If uenvcmd doesn't exist the default boot sequence will be started. Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk Acked-by: Nishanth Menon n...@ti.com Applied to u-boot-ti/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/3] am33xx: add a pulldown macro to pinmux config
On Fri, Jan 11, 2013 at 11:53:30AM +0100, Lars Poeschel wrote: From: Lars Poeschel poesc...@lemonage.de Signed-off-by: Lars Poeschel poesc...@lemonage.de Applied to u-boot-ti/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Add DDR3 support for AM335x-EVM (Version 1.5A)
On Mon, Jan 14, 2013 at 05:32:20AM -, Jeff Lance wrote: AM335x EVM 1.5A uses Micron MT41J512M8RH-125 SDRAM 4Gb (512Mx8) as the DDR3 chip. [Hebbar Gururaja gururaja.heb...@ti.com] - Resolve merge conflict while rebasing. File structure is changed in the mainline. So re-arrange the code accordingly. - Update commit message to reflect the DDR3 part number Signed-off-by: Jeff Lance j-lan...@ti.com Signed-off-by: Tom Rini tr...@ti.com Signed-off-by: Hebbar Gururaja gururaja.heb...@ti.com Applied to u-boot-ti/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/3] am335x: display msg when reading MAC from efuse
On Fri, Jan 11, 2013 at 11:53:32AM +0100, Lars Poeschel wrote: From: Lars Poeschel poesc...@lemonage.de When ethaddr is not set in environment the MAC address is read from efuse. The message was only printed in debug case, but this message could be of interest for the ordinary user, so printf it. Signed-off-by: Lars Poeschel poesc...@lemonage.de Applied to u-boot-ti/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, 1/3] gpio: Build the da8xx_gpio code for the davinci644x device
On Fri, Jan 18, 2013 at 05:19:48AM -, Holger Hans Peter Freyther wrote: The differences include the number of GPIOs and that one is not required to set the pinmux on request. I was about to reply that I applied this but I see the series is missing a Signed-off-by line. Please send a v2 with a Signed-off-by line, assuming of course that the guidelines apply and all that. Thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2, 1/2] OMAP3: use a single board file for IGEP devices
On Thu, Dec 27, 2012 at 01:35:56AM -, Javier Martinez Canillas wrote: Even when the IGEPv2 board and the IGEP Computer-on-Module are different from a form factor point of view, they are very similar in the fact that share many components and how they are wired. So, it is possible (and better) to have a single board file for both devices and just use the CONFIG_MACH_TYPE to make a differentiation between each board when needed. This change avoids code duplication by removing 298 lines of code and makes future maintenance easier. Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk Acked-by: Igor Grinberg grinb...@compulab.co.il Applied to u-boot-ti/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v5, 2/2] OMAP3: igep00x0: add boot status GPIO LED
On Thu, Dec 27, 2012 at 03:36:01AM -, Javier Martinez Canillas wrote: This patch adds an GPIO LED boot status for IGEP boards. The GPIO LED used is the red LED0 while the Linux kernel uses the green LED0 as the boot status. By using different GPIO LEDs, the user can know in which step of the boot process the board currently is. Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk Acked-by: Igor Grinberg grinb...@compulab.co.il Applied to u-boot-ti/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Please pull u-boot-ti/master
Hello,
The following changes since commit 7cb70a34b976e68f6348ea0718780e8f38901482:
fdt: fix dts preprocessor options (2013-01-17 09:07:59 -0700)
are available in the git repository at:
git://git.denx.de/u-boot-ti.git master
for you to fetch changes up to e25a6b504bb0c6e7a3a20cc0d2afacb6d88d29b1:
AM335X: Set fdt_high for AM335X devices to enable booting with Device Tree
(2013-01-25 17:10:43 -0500)
Javier Martinez Canillas (3):
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
Jeff Lance (1):
Add DDR3 support for AM335x-EVM (Version 1.5A)
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
hvaib...@ti.com (1):
AM335X: Set fdt_high for AM335X devices to enable booting with Device Tree
MAINTAINERS|3 +
arch/arm/include/asm/arch-am33xx/ddr_defs.h| 34 +++
arch/arm/include/asm/arch-am33xx/mux.h |3 +-
board/isee/igep0020/igep0020.h | 151 --
board/isee/igep0030/Makefile | 43 ---
board/isee/igep0030/igep0030.c | 117
board/isee/{igep0020 = igep00x0}/Makefile |2 +-
.../{igep0020/igep0020.c = igep00x0/igep00x0.c} | 51 +++-
.../{igep0030/igep0030.h = igep00x0/igep00x0.h} | 35 ++-
board/phytec/pcm051/Makefile | 46 +++
board/phytec/pcm051/board.c| 266 +
board/phytec/pcm051/board.h| 33 +++
board/phytec/pcm051/mux.c | 133 +
board/ti/am335x/board.c| 43 ++-
boards.cfg |9 +-
include/configs/am335x_evm.h |1 +
include/configs/igep00x0.h |5 +
include/configs/omap4_common.h | 17 +-
include/configs/pcm051.h | 301
19 files changed, 951 insertions(+), 342 deletions(-)
delete mode 100644 board/isee/igep0020/igep0020.h
delete mode 100644 board/isee/igep0030/Makefile
delete mode 100644 board/isee/igep0030/igep0030.c
rename board/isee/{igep0020 = igep00x0}/Makefile (98%)
rename board/isee/{igep0020/igep0020.c = igep00x0/igep00x0.c} (86%)
rename board/isee/{igep0030/igep0030.h = igep00x0/igep00x0.h} (93%)
create mode 100644 board/phytec/pcm051/Makefile
create mode 100644 board/phytec/pcm051/board.c
create mode 100644 board/phytec/pcm051/board.h
create mode 100644 board/phytec/pcm051/mux.c
create mode 100644 include/configs/pcm051.h
--
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] Please pull u-boot-mpc85xx.git
create mode 100644 drivers/net/fm/b4860.c create mode 100644 include/configs/B4860QDS.h create mode 100644 include/configs/BSC9132QDS.h So, I see: bsc9132qds.c: In function 'ft_board_setup': bsc9132qds.c:349:19: warning: variable 'cpu' set but not used [-Wunused-but-set-variable] On the various BSC boards. Do you want me to take it now, or after you've fixed it up? Argh. That apparently wasn't seen by my compiler setup. I'll fix it. What compiler are you using? Andy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 10/11] tegra20: remove old pinmux setup
Am Freitag, den 25.01.2013, 14:12 -0800 schrieb Stephen Warren:
On 01/24/2013 08:48 AM, Lucas Stach wrote:
All boards are converted to the new tablebased pinmux setup. Get rid of
the old method.
diff --git a/arch/arm/cpu/tegra-common/board.c
b/arch/arm/cpu/tegra-common/board.c
@@ -145,7 +121,6 @@ static void setup_uarts(int uart_ids)
if (uart_ids (1 i)) {
enum periph_id id = id_for_uart[i];
- funcmux_select(id, uart_configs[i]);
clock_ll_start_uart(id);
}
}
Doesn't the debug UART get set up very early, in the SPL, before any
table-based pinmux could be activated?
If so, I think we need to leave this one funcmux API call in place, so
that the debug UART always works nice and early.
If not, how much does this series increase the binary of the SPL?
Ah right, I forgot about SPL debug. If we go for FDT based pinmux, we
have to init UART in some explicit way, as DT and SPL don't mix.
But even then I would like to get rid of the funcmux style and rather
let the boards provide a minimal UART pinmux init table, as funcmux
doesn't map too well onto the plethora of config options Tegra30
provides for the pinmux.
Regards,
Lucas
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 10/11] tegra20: remove old pinmux setup
On 01/25/2013 02:19 PM, Lucas Stach wrote:
Am Freitag, den 25.01.2013, 14:12 -0800 schrieb Stephen Warren:
On 01/24/2013 08:48 AM, Lucas Stach wrote:
All boards are converted to the new tablebased pinmux setup. Get rid of
the old method.
diff --git a/arch/arm/cpu/tegra-common/board.c
b/arch/arm/cpu/tegra-common/board.c
@@ -145,7 +121,6 @@ static void setup_uarts(int uart_ids)
if (uart_ids (1 i)) {
enum periph_id id = id_for_uart[i];
- funcmux_select(id, uart_configs[i]);
clock_ll_start_uart(id);
}
}
Doesn't the debug UART get set up very early, in the SPL, before any
table-based pinmux could be activated?
If so, I think we need to leave this one funcmux API call in place, so
that the debug UART always works nice and early.
If not, how much does this series increase the binary of the SPL?
Ah right, I forgot about SPL debug. If we go for FDT based pinmux, we
have to init UART in some explicit way, as DT and SPL don't mix.
But even then I would like to get rid of the funcmux style and rather
let the boards provide a minimal UART pinmux init table, as funcmux
doesn't map too well onto the plethora of config options Tegra30
provides for the pinmux.
Yes, that's perhaps true.
For reference, I recently worked out all the possible locations of each
logical signal (well, only RX/TX/RTS/CTS for Tegra30) for each UART. I
put the table below for reference in case it's interesting.
Tegra20:
(sets of pingroups that create a complete UART)
+ * UART A:
+ * 0: unspecified
+ * 1: irrx, irtx
+ * 2: gpu
+ * 3: sdb, sdd
+ * 4: sdio1
+ * 5: uaa
+ * 6: irrx, irtx, uad
+ * 7: irrx, irtx, uad, uab
+ * 8: sdb, sdd, uad
+ * 9: sdb, sdd, uad, uab
+ * 10: uaa, uab
+ * UART B:
+ * 0: unspecified
+ * 1: uad
+ * 2: uad, irrx, irtx
+ * UART C:
+ * 0: unspecified
+ * 1: uca
+ * 2: uca, ucb
+ * UART D:
+ * 0: unspecified
+ * 1: gmc
+ * 2: uda
+ * UART E:
+ * 0: unspecified
+ * 1: gma
+ * 2: sdio1
Tegra30:
(possible locations for each signal on each UART)
+ * UART CTS pin
+ * UART A:
+ * 0: unspecified
+ * 1: uart2_rxd
+ * 2: ulpi_data2
+ * 3: gpio_pu2
+ * UART B:
+ * 0: unspecified
+ * 1: uart2_cts_n
+ * UART C:
+ * 0: unspecified
+ * 1: uart3_cts_n
+ * UART D:
+ * 0: unspecified
+ * 1: gmi_a18
+ * 2: ulpi_nxt
+ * UART E:
+ * 0: unspecified
+ * 1: sdmmc1_dat1
+ * 2: sdmmc4_dat2
+ * UART RTS pin
+ * UART A:
+ * 0: unspecified
+ * 1: uart2_txd
+ * 2: ulpi_data3
+ * 3: gpio_pu3
+ * UART B:
+ * 0: unspecified
+ * 1: uart2_rts_n
+ * UART C:
+ * 0: unspecified
+ * 1: uart3_rts_n
+ * UART D:
+ * 0: unspecified
+ * 1: gmi_a19
+ * 2: ulpi_stp
+ * UART E:
+ * 0: unspecified
+ * 1: sdmmc1_dat0
+ * 2: sdmmc4_dat3
+ * UART TXD pin
+ * UART A:
+ * 0: unspecified
+ * 1: sdmmc3_clk
+ * 2: uart2_rts_n
+ * 3: ulpi_data0
+ * 4: gpio_pu0
+ * UART B:
+ * 0: unspecified
+ * 1: uart2_txd
+ * UART C:
+ * 0: unspecified
+ * 1: uart3_txd
+ * UART D:
+ * 0: unspecified
+ * 1: gmi_a16
+ * 2: ulpi_clk
+ * UART E:
+ * 0: unspecified
+ * 1: sdmmc1_dat3
+ * 2: sdmmc4_dat0
+ * UART RXD pin
+ * UART A:
+ * 0: unspecified
+ * 1: sdmmc3_cmd
+ * 2: uart2_cts_n
+ * 3: ulpi_data1
+ * 4: gpio_pu1
+ * UART B:
+ * 0: unspecified
+ * 1: uart2_rxd
+ * UART C:
+ * 0: unspecified
+ * 1: uart3_rxd
+ * UART D:
+ * 0: unspecified
+ * 1: gmi_a17
+ * 2: ulpi_dir
+ * UART E:
+ * 0: unspecified
+ * 1: sdmmc1_dat2
+ * 2: sdmmc4_dat1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-mpc85xx.git
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/25/2013 05:15 PM, Fleming Andy-AFLEMING wrote: create mode 100644 drivers/net/fm/b4860.c create mode 100644 include/configs/B4860QDS.h create mode 100644 include/configs/BSC9132QDS.h So, I see: bsc9132qds.c: In function 'ft_board_setup': bsc9132qds.c:349:19: warning: variable 'cpu' set but not used [-Wunused-but-set-variable] On the various BSC boards. Do you want me to take it now, or after you've fixed it up? Argh. That apparently wasn't seen by my compiler setup. I'll fix it. What compiler are you using? ELDK 5.2.1 - -- Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRAwpnAAoJENk4IS6UOR1WRY4P/RCj9uAOWayQUJKe0GV4wHWy k8JyVqy51XR/VzkdrtU2546FQxIJ/hz0z7rwo/o0p7euY6qrMOWRLKiV+nH7TBb4 O26DAuoWHXr6vQc6+GO3DLRHY7KdKfbhiWgCnM678N5I7FX5uIcGGycJlRpn6T6k IACJwVMBi2q+vEsTSfyTGtTCq5PaUafYG7EA1sckQsZ4jssxd9NakGPhznorHIBM 6QhKZzJbWuLXfT8thMSz3nMKvmFCkl2/LNZvMU2Q8HrkBmDb0tduNi3Fu2jBUY6n f89A37mf2Q5aM0xQpoD3PfSwp8/nhGNoI0WCTGxYgjkXUkLfB5SzIw1Jro2UFSz/ SSegHVocKlmD0gQLjtJgW7NYFWu6+c3m+RCRyODyJiksG4vU1Ns6UtiUBPMoeOtd ONXMiEOXcJ+lv8L9fSTzPoB9k9scjHw5KA5zeiedV8ZBkv7Y/NWllf1xQ7oceuqp 86d+pw0QdagdSf3HnCl4Qc2X1n4X5X/jSbI57j7KPnvHV+49gCU8/VcoqKiVFcMn dl4kefSD3GgMddSdyk/3RJ0/XWr6gAfISUC4ZPSTxepbZluAiOZ6/gFe7Z2/leV/ my2iVlXqDRFSPT0qeHx2vldQJwTGN63nwzCLl6G9UZLzgGrBb8on7fy8e9cFiI5E nH4c8mQ2lr/EReXt/HqW =ioCy -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] powerpc/mpc85xx: Add revision properties in portal device tree node 'pme'
The 'fsl,pme-rev1' and 'fsl-pme-rev2' properties have been added to the
pme portal node. This is required for software to determine which version
of PME hardware is present and take appropriate actions.
These properties are a direct reflection of the corresponding ccsr pme
register value.
Also removed unnecessary static global variables.
Signed-off-by: Jeffrey Ladouceur jeffrey.ladouc...@freescale.com
---
arch/powerpc/cpu/mpc85xx/portals.c | 20 +---
1 files changed, 17 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/cpu/mpc85xx/portals.c
b/arch/powerpc/cpu/mpc85xx/portals.c
index b59ef69..d529095 100644
--- a/arch/powerpc/cpu/mpc85xx/portals.c
+++ b/arch/powerpc/cpu/mpc85xx/portals.c
@@ -30,11 +30,9 @@
#include asm/fsl_portals.h
#include asm/fsl_liodn.h
-static ccsr_qman_t *qman = (void *)CONFIG_SYS_FSL_QMAN_ADDR;
-static ccsr_bman_t *bman = (void *)CONFIG_SYS_FSL_BMAN_ADDR;
-
void setup_portals(void)
{
+ ccsr_qman_t *qman = (void *)CONFIG_SYS_FSL_QMAN_ADDR;
#ifdef CONFIG_FSL_CORENET
int i;
@@ -166,6 +164,20 @@ static int fdt_qportal(void *blob, int off, int id, char
*name,
num = get_dpaa_liodn(dev, liodns[0], id);
ret = fdt_setprop(blob, childoff, fsl,liodn,
liodns[0], sizeof(u32) * num);
+ if (!strncmp(name, pme, 3)) {
+ u32 pme_rev1, pme_rev2;
+ ccsr_pme_t *pme_regs =
+ (void *)CONFIG_SYS_FSL_CORENET_PME_ADDR;
+
+ pme_rev1 = in_be32(pme_regs-pm_ip_rev_1);
+ pme_rev2 = in_be32(pme_regs-pm_ip_rev_2);
+ ret = fdt_setprop(blob, childoff,
+ fsl,pme-rev1, pme_rev1, sizeof(u32));
+ if (ret 0)
+ return ret;
+ ret = fdt_setprop(blob, childoff,
+ fsl,pme-rev2, pme_rev2, sizeof(u32));
+ }
#endif
} else {
return childoff;
@@ -183,6 +195,7 @@ void fdt_fixup_qportals(void *blob)
int off, err;
unsigned int maj, min;
unsigned int ip_cfg;
+ ccsr_qman_t *qman = (void *)CONFIG_SYS_FSL_QMAN_ADDR;
u32 rev_1 = in_be32(qman-ip_rev_1);
u32 rev_2 = in_be32(qman-ip_rev_2);
char compat[64];
@@ -272,6 +285,7 @@ void fdt_fixup_bportals(void *blob)
int off, err;
unsigned int maj, min;
unsigned int ip_cfg;
+ ccsr_bman_t *bman = (void *)CONFIG_SYS_FSL_BMAN_ADDR;
u32 rev_1 = in_be32(bman-ip_rev_1);
u32 rev_2 = in_be32(bman-ip_rev_2);
char compat[64];
--
1.7.2.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 04/11] tegra20: switch over tamonten platform to use tablebased pinmux
On 01/24/2013 08:48 AM, Lucas Stach wrote:
Init pinmux in one shot, in order to avoid any conflicts.
diff --git a/board/avionic-design/common/tamonten.c
b/board/avionic-design/common/tamonten.c
+static struct pingroup_config tamonten_pinmux[] = {
+ PINMUX_ENTRY(ATA, IDE, NORMAL, NORMAL), /* GPIO */
+ PINMUX_ENTRY(ATB, SDIO4, NORMAL, NORMAL), /* MMC */
...
I believe this initializes every single pingroup on the SoC to
something. In order to prevent any behavior changes, wouldn't it be
better to first fill in this table only with entries that achieve the
same pinmux programming that used to be performed by the C code you're
removing? Then, a separate later patch could fill in missing items in
the pinmux table. I think that'd end up being much safer and easier to
validate.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 06/11] tegra20: switch over seaboard and ventana to use tablebased pinmux
On 01/25/2013 01:57 PM, Lucas Stach wrote: Am Samstag, den 26.01.2013, 10:49 +1300 schrieb Simon Glass: [...] But yes in the end we want to pack this information into the DT files. But even then it would be nice if people would test this pachset, as I imagine DT based pinmux is the same as tablebased pinmux, just in a slightly different flavour. ;) So if people test the tablebased config now, we can do the conversion to DT based with a lot more confidence. I'll look into using the kernel pinmux binding minus the MUX stuff, as I think there's no real reason to have this in U-Boot. Well I would rather than we get that running than switch to table-driven mux, assuming it is not too big a job? I imagine perhaps naively that a function could be written which parses the pinmux and sets it up in U-Boot - effectively using the FDT as the pinmux table. That's my plan. But still even if we keep the binding the same, the actual pinmux config would differ between the kernel and U-Boot (a lot more pads kept in tristate in U-Boot). So as the FDT would effectively resemble the same tables I included in this patchset, some testing coverage of that would smoothen the transition. Why wouldn't the pinmux tables in the FDT passed to U-Boot either be identical to (a) the kernel, or (b) the small subset of the pinmux options that U-Boot used to program via code? I don't see any reason for U-Boot to program all the pingroups to TRISTATE etc.; if it's programming those pingroups at all, it may as well just program the correct final value. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 06/11] tegra20: switch over seaboard and ventana to use tablebased pinmux
On 01/25/2013 01:49 PM, Simon Glass wrote: Hi Lucas, On Sat, Jan 26, 2013 at 10:38 AM, Lucas Stach d...@lynxeye.de wrote: Hello Simon, Am Samstag, den 26.01.2013, 10:20 +1300 schrieb Simon Glass: Hi Lucas, On Fri, Jan 25, 2013 at 7:22 AM, Lucas Stach d...@lynxeye.de wrote: Am Freitag, den 25.01.2013, 06:54 +1300 schrieb Simon Glass: Hi Lucas, On Fri, Jan 25, 2013 at 5:48 AM, Lucas Stach d...@lynxeye.de wrote: Init pinmux in one shot, in order to avoid any conflicts. Signed-off-by: Lucas Stach d...@lynxeye.de --- board/nvidia/seaboard/seaboard.c | 133 +-- include/configs/seaboard.h | 3 + include/configs/ventana.h| 3 + 3 files changed, 121 insertions(+), 18 deletions(-) This seems like a lot of code and presumably quite a bit of duplication between boards. What sort of conflicts does this avoid, and is it the only way of avoiding them? I don't see it as duplication, but as explicitly spelling out how the pinmux configuration should be set up on a certain board. I mean that the table is very similar for different boards, so looks like duplicated coded (133 very similar lines for each board). Also, this seems to break FDT use. At present it is possible (I think) to boot the same U-Boot on any board, with the device tree specifying the config. With your change that is no longer possible, I think? Looking ahead to T114 I see a similar problem. The funcmux approach was a compromise in that we could just select appropriate values for each function - there was no agreement on how to put this in the FDT though (my intention was that it would depend on the kernel binding, but that is now defined, so what excuse do we have for not implementing it in U-Boot?). That Tegra30 doesn't do so either. ;) But I agree, that's no valid excuse and we should resolve this before Tegra114 introduces more of this stuff. See below. Before this change we would leave some pads uninitialised in their (random) reset configuration. For example on the Colibri this leads to NAND not working as it's wired up to the KBC pads. If we only configure those, ATC will remain in it's reset state and would be also configured to the NAND function, which leads to fail. Having an explicit, known to be conflict free configuration for all pads avoids all those unpleasant surprises. Well yes, but we seem to be right back to where we started, with the FDT unable to describe a key feature of the boards (pinmux). I see your point now. The obvious answer for now is: it's not regressing functionality, as we were never able to boot the same U-Boot image by just changing the DT. Well, kind of. In fact we were able to boot at 3 different T20 boards just by adding a 'funcmux' property to the device's node to select the required mux option for that driver. This code is no use on T30/T114, and was only a stop-gap anyway. ??? I don't believe U-Boot supports any funcmux property in the device tree. Are you referring to some downstream U-Boot? Such a branch wouldn't be relevant to a patch for upstream U-Boot. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 06/11] tegra20: switch over seaboard and ventana to use tablebased pinmux
On 01/24/2013 10:22 AM, Lucas Stach wrote: Am Freitag, den 25.01.2013, 06:54 +1300 schrieb Simon Glass: Hi Lucas, On Fri, Jan 25, 2013 at 5:48 AM, Lucas Stach d...@lynxeye.de wrote: Init pinmux in one shot, in order to avoid any conflicts. Signed-off-by: Lucas Stach d...@lynxeye.de --- board/nvidia/seaboard/seaboard.c | 133 +-- include/configs/seaboard.h | 3 + include/configs/ventana.h| 3 + 3 files changed, 121 insertions(+), 18 deletions(-) This seems like a lot of code and presumably quite a bit of duplication between boards. What sort of conflicts does this avoid, and is it the only way of avoiding them? I don't see it as duplication, but as explicitly spelling out how the pinmux configuration should be set up on a certain board. Before this change we would leave some pads uninitialised in their (random) reset configuration. Just being pedantic here, but I don't think the power-on-reset configuration is random; it's well defined but perhaps just not documented, and not always what is correct/best for any particular board design. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 10/11] tegra20: remove old pinmux setup
On 01/24/2013 08:48 AM, Lucas Stach wrote:
All boards are converted to the new tablebased pinmux setup. Get rid of
the old method.
diff --git a/arch/arm/cpu/tegra-common/board.c
b/arch/arm/cpu/tegra-common/board.c
@@ -145,7 +121,6 @@ static void setup_uarts(int uart_ids)
if (uart_ids (1 i)) {
enum periph_id id = id_for_uart[i];
- funcmux_select(id, uart_configs[i]);
clock_ll_start_uart(id);
}
}
Doesn't the debug UART get set up very early, in the SPL, before any
table-based pinmux could be activated?
If so, I think we need to leave this one funcmux API call in place, so
that the debug UART always works nice and early.
If not, how much does this series increase the binary of the SPL?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] mmc:fix: Increase the timeout value for SDHCI_send_command()
On 01/25/2013 08:44 PM, Jagan Teki wrote: Hi, On Fri, Jan 11, 2013 at 8:49 PM, Lukasz Majewski l.majew...@samsung.com wrote: Hi Wolfgang, Dear Lukasz Majewski, In message 1357665792-8141-1-git-send-email-l.majew...@samsung.com you wrote: I'd like to ask for your opinion about the following problem: I cannot comment on the problem - only a bit about the proposed patch ;-) From a brief checking I can say that it happens when we are doing consecutive MMC operations (i.e. many reads), and the 10ms timeout might be too short when eMMC firmware is forced to do some internal time consuming operations (e.g. flash blocks management, wear leveling). In this situation, the SDHCI_CMD_INHIBIT bit is set, which means that SDHCI controller didn't received response from eMMC. One proposition would be to define the per device/per memory chip specific timeouts, to replace those defined at ./drivers/mmc/sdhci.c file. Is there no way to ask the device and/or controller when it is done, so we can poll for ready state instead of adding delays, which will always have to be tailored for the so far known worst case, i. e. they will be always too long on all almost all systems. We are doing this already - the SDHCI_PRESENT_STATE register's bit 0 (SDHCI_CMD_INHIBIT) and bit 1 (DATA_INHIBIT) are for this purpose. Those indicate when host controller can send further command/data to the card. Moreover, there are also timeouts in the case when someone pull out SD card inserted to the slot (or any other use case which I'm not aware). --- a/drivers/mmc/sdhci.c +++ b/drivers/mmc/sdhci.c @@ -137,8 +137,8 @@ int sdhci_send_command(struct mmc *mmc, struct mmc_cmd *cmd, unsigned int timeout, start_addr = 0; unsigned int retry = 1; - /* Wait max 10 ms */ - timeout = 10; + /* Wait max 100 ms */ + timeout = 100; We have cases where we struggle for sub-second boot times. Adding 100 ms delay here is clearly prohbitive. [Even the 10 ms are way too long IMHO.] There must be a better way to handle this. That's why I'm asking. It is strange that, when I'm increasing delay it works. Maybe we will find some areas of optimization? BTW: I am also finding the similar issue. But when I enabled CONFIG_MMC_TRACE for log traces, i never see the issue..it's pretty much working fine. It's not important to enable the MMC_TRACE. It should be increased the delay. As per my latest debug, the issue is fire for CMD6 (SWITCH_FUNC). Right, i also find the error log for CMD6. Could you test this point? sdhci_writel(host, SDHCI_INT_ALL_MASK, SDHCI_INT_STATUS); - mask = SDHCI_CMD_INHIBIT | SDHCI_DATA_INHIBIT; + mask = SDHCI_CMD_INHIBIT; + + if ((data != NULL) || (cmd-resp_type MMC_RSP_BUSY)) + mask |= SDHCI_DATA_INHIBIT; Best Regards, Jaehoon Chung May be we need to update the logic on this while loop... Thanks, Jagan. Best regards, Wolfgang Denk -- Best regards, Lukasz Majewski Samsung RD Poland (SRPOL) | Linux Platform Group ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tegra: fdt: add back missing host1x node
On Fri, Jan 25, 2013 at 10:46:47AM -0800, Allen Martin wrote:
Add back host1x node to seaboard dts file. This got dropped during
the tegra fdt sort.
Signed-off-by: Allen Martin amar...@nvidia.com
---
Hi Albert, would it be possible for you to apply this directly to your
u-boot-arm repository? It fixes a regression introduced by my
previous patch:
b7723f3 tegra: fdt: sort dts files
So I wanted to make sure it gets applied before that previous patch
makes it to u-boot/master, and Tom's not ready to do another tegra
pull request yet.
-Allen
board/nvidia/dts/tegra20-seaboard.dts | 11 +++
1 file changed, 11 insertions(+)
diff --git a/board/nvidia/dts/tegra20-seaboard.dts
b/board/nvidia/dts/tegra20-seaboard.dts
index 9cb9b5b..527a296 100644
--- a/board/nvidia/dts/tegra20-seaboard.dts
+++ b/board/nvidia/dts/tegra20-seaboard.dts
@@ -27,6 +27,17 @@
reg = 0x 0x4000 ;
};
+ host1x {
+ status = okay;
+ dc@5420 {
+ status = okay;
+ rgb {
+ status = okay;
+ nvidia,panel = lcd_panel;
+ };
+ };
+ };
+
/* This is not used in U-Boot, but is expected to be in kernel .dts */
i2c@7000d000 {
clock-frequency = 10;
--
1.7.10.4
--
nvpublic
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Can I read env from RAM in uboot script?
Is it possible to have uboot read it's environment from a RAM address, rather than NAND? OR Can uboot's scripting support load variables from a RAM address? My NAND layout has redundant halves: 0 uboot ubootenv kernel fs 128 uboot ubootenv kernel fs 256 My firmware update strategy will update the non-booted side of NAND. It is easy to hack at91bootstrap, to load a uboots env area at some RAM address, just as it loads uboot at JUMP_ADDR, but how do I get uboot to use this preloaded uboot-env? Since uboot takes its environment area address at compile time, I wonder if uboot could be made to read it from a RAM address (written there by at91bootstrap), durring the env_relocate_spec()? So far I have traced: cpu/arm926ejs/start.S calls start_armboot() lib_arm/board.c start_armboot() calls env_relocate() ./common/env_common.c env_relocate() calls env_relocate_spec() My u-boot.map indicates my env_relocate_spec() comes from env_nand.o ./common/env_nand.c has env_relocate_spec() has ifdefs for ENV_IS_EMBEDDED, but my config is not. and CFG_ENV_IS_IN_NAND which I am currently configured for. So where is a good point of attack, or is there one? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1 v3] console: USB: KBD: Fix incorrect autoboot timeout
Dear Jim Lin, Autoboot timeout defined by CONFIG_BOOTDELAY will not be accurate if CONFIG_USB_KEYBOARD and CONFIG_SYS_USB_EVENT_POLL are defined in configuration file and when tstc() function for checking key pressed takes longer time than 10 ms (e.g., 50 ms) to finish. Signed-off-by: Jim Lin ji...@nvidia.com Applied to u-boot-usb Thanks Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/7] Move Tegra EHCI drive to correct place
Dear Lucas Stach, This moves out the Tegra EHCI driver from a platform specific directory to the standard driver/usb/host dir. This is a preparation needed to share this driver between Tegra20 and Tegra30. No functional change in here, so Tegra30 is still not working. Patch 6 could be a lot smaller if it were generated with -B, as GIT would detect that most of it is moving stuff over, but last time I did this it prevented git apply to work. So sorry for the big diff. I think I incorporated all changes needed to reflect the review feedback I got on this last time. I expect this series to go in through the Tegra tree. Last two don't apply, I applied first five and pushed. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] serial: arm_dcc: Remove CONFIG_ARM_DCC_MULTI option
Dear Michal Simek, CONFIG_ARM_DCC_MULTI should be also removed in the patch serial: Remove CONFIG_SERIAL_MULTI from serial drivers (sha1: a3827250606895ec2dd4b8d867342b7cabf3692f) Because the driver defines serial_* functions which cause conflict with serial.c (multiple definition of serial_*) Removing CONFIG_SERIAL_MULTI function also require to define default_serial_console for cases where another serial driver is not available in the system. Signed-off-by: Michal Simek michal.si...@xilinx.com I think it looks good. Acked-by: Marek Vasut ma...@denx.de btw. did I by any chance became serial subsystem custodian without knowing about it recently? ;-) Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] serial: arm_dcc: Fix compilation warning and remove unneeded initialization
Dear Michal Simek, - arm_dcc_dev is already initialized. - Remove unused rc variable Warning log: arm_dcc.c: In function 'drv_arm_dcc_init': arm_dcc.c:145:6: warning: unused variable 'rc' [-Wunused-variable] Signed-off-by: Michal Simek michal.si...@xilinx.com Acked-by: Marek Vasut ma...@denx.de Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Can I read env from RAM in uboot script?
Dear John Stile, In message 1359165410.7974.114.camel@genx you wrote: Is it possible to have uboot read it's environment from a RAM address, rather than NAND? OR Can uboot's scripting support load variables from a RAM address? Yes, all this can be done. And easily. See for example the env import command. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Software suppliers are trying to make their software packages more ``user-friendly''. . . . Their best approach, so far, has been to take all the old brochures, and stamp the words, ``user-friendly'' on the cover. - Bill Gates ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
