Re: [U-Boot] [PATCH] ehci-hcd: Allow cleanups to happen on an EHCI timeout.
Hi Joel, On 06/25/2011 10:28 PM, Joel A Fernandes wrote: --- Robert, Could you see if this patch solves the issue you're seeing without increasing the timeout? The tftp session retrieves the uImage with your patch and a timeout of 5000: OMAP3 beagleboard.org # tftp 0x8200 beagle-xm-rev-c/uImage Waiting for Ethernet connection... done. Using sms0 device TFTP from server 192.168.5.5; our IP address is 192.168.5.3 Filename 'beagle-xm-rev-c/uImage'. Load address: 0x8200 Loading: # EHCI timed out on TD - token=0x88008d80 T EHCI timed out on TD - token=0x88008d80 T EHCI timed out on TD - token=0x88008d80 T # ###EHCI timed out on TD - token=0x88008d80 T EHCI timed out on TD - token=0x88008d80 T EHCI timed out on TD - token=0x88008d80 T #EHCI timed out on TD - token=0x88008d80 T ## done Bytes transferred = 2632196 (282a04 hex) OMAP3 beagleboard.org # Regards, Robert...fortune says today:There is no TRUTH. There is no REALITY. There is no CONSISTENCY. There are no ABSOLUTE STATEMENTS I'm very probably wrong. My public pgp key is available at: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x90320BF1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V5 1/2] GPIO: Tegra2: add GPIO driver for Tegra2
Hi Tom, Le 24/06/2011 19:58, Tom Warren a écrit : On Fri, Jun 17, 2011 at 9:27 AM, Tom Warrentwarren.nvi...@gmail.com wrote: Signed-off-by: Tom Warrentwar...@nvidia.com --- Changes in V2: - use 'gpio_pin' enum in gpio.h (Simon Glass review request) - change 'GPIO_PORT8' to 'GPIO_FULLPORT' (Simon Glass request) - change 'offset' to 'pin' globally Changes in V3: - use common cmd_gpio; remove redundant cmd processing code - add gpio_request, gpio_free and gpio_toggle - alias 'gpio_status' to 'gpio_info' for use in cmd_gpio Changes in V4: - update code as per Mike Frysinger's review comments - rewrite gpio_info, aka gpio_status Changes in V5: - NUL-terminate the name string in gpio_request arch/arm/include/asm/arch-tegra2/gpio.h | 250 +-- arch/arm/include/asm/gpio.h | 38 + drivers/gpio/Makefile |1 + drivers/gpio/tegra2_gpio.c | 255 +++ 4 files changed, 534 insertions(+), 10 deletions(-) create mode 100644 arch/arm/include/asm/gpio.h create mode 100644 drivers/gpio/tegra2_gpio.c snip Has this patch been accepted? or is there anymore feedback? Mike gave it an 'otherwise, looks fine' prior to the ASCIIZ fix in V5. Seems like no other comments have been made, so: Applied to u-boot-arm/next, to be moved to master after 2011-06 release. Thanks, Tom Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] arm920t/at91: use new clock features from libat91-common
Am 08.06.2011 22:10, schrieb Andreas Bießmann: This patch enables the new clock features from new libat91-common. This is a required step to get at91rm9200_usart replaced by atmel_usart driver. Signed-off-by: Andreas Bießmannandreas.de...@googlemail.com Cc: Jens Scharsigjs_at...@scharsoft.de Cc: Eric Bénarde...@eukrea.com --- changes since v1: - add missing cpu.c resent due to wrong list mail ... arch/arm/cpu/arm920t/at91/Makefile |1 + arch/arm/cpu/arm920t/at91/cpu.c | 14 ++ arch/arm/include/asm/arch-at91/at91rm9200.h |1 + include/configs/at91rm9200ek.h |3 +++ include/configs/cpuat91.h |5 +++-- include/configs/eb_cpux9k2.h|4 ++-- 6 files changed, 24 insertions(+), 4 deletions(-) create mode 100644 arch/arm/cpu/arm920t/at91/cpu.c Acked-by: Jens Scharsigjs_at...@scharsoft.de Tested-by: Jens Scharsigjs_at...@scharsoft.de (for eb_cpux9k2 board) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH atmel/next 5/7] eb_cpux9k2: use atmel_usart
Am 12.06.2011 13:49, schrieb Andreas Bießmann: Signed-off-by: Andreas Bießmannandreas.de...@googlemail.com CC: Jens Scharsigjs_at...@scharsoft.de --- board/BuS/eb_cpux9k2/cpux9k2.c |7 +++ include/configs/eb_cpux9k2.h |6 -- 2 files changed, 11 insertions(+), 2 deletions(-) Acked-by: Jens Scharsigjs_at...@scharsoft.de Tested-by: Jens Scharsigjs_at...@scharsoft.de (for eb_cpux9k2 board) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] CONFIG_SYS_SDRAM_BASE error
Hi, I try compiling u-boot for Iomega iConnect using these files: http://patchwork.openwrt.org/patch/299/ But I got this error: board.c: In function â__dram_init_banksizeâ: board.c:233: error: âCONFIG_SYS_SDRAM_BASEâ undeclared (first use in this function) board.c:233: error: (Each undeclared identifier is reported only once board.c:233: error: for each function it appears in.) board.c: In function âboard_init_fâ: board.c:279: error: âCONFIG_SYS_INIT_SP_ADDRâ undeclared (first use in this function) board.c:312: error: âCONFIG_SYS_SDRAM_BASEâ undeclared (first use in this function) make[1]: *** [board.o] Error 1 I found this thread, it seems to be a solution, but I don't know how to do: http://www.mail-archive.com/u-boot@lists.denx.de/msg36109.html Please could you help me? Regards, Ben Suivez l'actualité de l'émission X Factor : les photos des primes et les news sont sur Voila http://people.voila.fr/evenementiel/X-factor/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL framework re-design
Hello everybody, I've read the whole thread and I really like what Daniel suggests but I just want to speak it in a little bit different words. I wonder why do we need this whole spl thing in the first place (well, surely I know what they are used for but why do we need a separate entity for this)? Isn't it just the same U-Boot in, well, very special configuration (minimal set of drivers, no shell, etc)? Why do we need a whole shadow tree at spl/ instead of just providing the _configuration_? Am I missing something? Aneesh, what's the state of your patches? I'm especially interrested in OMAP3 (AM3517) support. Maybe I will be able to help you. Regards, Ilya. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] nios2: move generic config to boards.cfg
On 06/25/2011 09:12 AM, Mike Frysinger wrote: I can't build test this, but just looking at the config files written and it seems OK ... Hi Mike, Built and tested on nios2 board. Though the original patch doesn't apply to current head and might need rebase. Thanks. Best regards, Thomas Tested-by: Thomas Chou tho...@wytron.com.tw ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] nios2: move generic config to boards.cfg
I can't build test this, but just looking at the config files written and it seems OK ... Tested-by: Thomas Chou tho...@wytron.com.tw Signed-off-by: Mike Frysinger vap...@gentoo.org --- v2 - rebased onto master MAKEALL|4 +--- Makefile | 14 -- boards.cfg |1 + 3 files changed, 2 insertions(+), 17 deletions(-) diff --git a/MAKEALL b/MAKEALL index 51db13e..e37000f 100755 --- a/MAKEALL +++ b/MAKEALL @@ -553,9 +553,7 @@ LIST_x86=$(boards_by_arch x86) ## Nios-II Systems # -LIST_nios2=$(boards_by_arch nios2) - nios2-generic \ - +LIST_nios2=$(boards_by_arch nios2) # ## MicroBlaze Systems diff --git a/Makefile b/Makefile index 6bb5494..9925806 100644 --- a/Makefile +++ b/Makefile @@ -1047,20 +1047,6 @@ smdk6400_config : unconfig @$(MKCONFIG) smdk6400 arm arm1176 smdk6400 samsung s3c64xx @echo CONFIG_NAND_U_BOOT = y $(obj)include/config.mk -# -# Nios -# - -# -## Nios-II -# - -# nios2 generic boards -NIOS2_GENERIC = nios2-generic - -$(NIOS2_GENERIC:%=%_config) : unconfig - @$(MKCONFIG) $@ nios2 nios2 nios2-generic altera - # # diff --git a/boards.cfg b/boards.cfg index dfefc3f..ff6f7e4 100644 --- a/boards.cfg +++ b/boards.cfg @@ -283,6 +283,7 @@ vct_platinumavc mipsmips32 vct microna vct_platinumavc_smallmipsmips32 vct micronas - vct:VCT_PLATINUMAVC,VCT_SMALL_IMAGE vct_platinumavc_onenand mipsmips32 vct micronas - vct:VCT_PLATINUMAVC,VCT_ONENAND vct_platinumavc_onenand_small mips mips32 vct micronas - vct:VCT_PLATINUMAVC,VCT_ONENAND,VCT_SMALL_IMAGE +nios2-genericnios2 nios2 nios2-generic altera PCI5441 nios2 nios2 pci5441 psyent PK1C20 nios2 nios2 pk1c20 psyent EVB64260 powerpc 74xx_7xxevb64260- - EVB64260 -- 1.7.5.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL framework re-design
Dear Wolfgang,
On Saturday 25 June 2011 05:40 PM, Wolfgang Denk wrote:
Dear Aneesh V,
In message4e00799a.5040...@ti.com you wrote:
Here is a crude implementation of the top-down approach you had been
suggesting (or my interpretation of it). This is not complete yet and
serves only as a material for further discussions on this topic.
Here is an updated version of my prototype implementation with fixes
for some issues pointed out by Scott. Please let me know your views
about this.
---
Makefile|5 ++
include/configs/omap4_sdp4430.h |1 +
spl/Makefile| 94
+++
spl/mmc/Makefile| 55 +++
4 files changed, 155 insertions(+), 0 deletions(-)
create mode 100644 spl/Makefile
create mode 100644 spl/mmc/Makefile
diff --git a/Makefile b/Makefile
index 8540e39..0321634 100644
--- a/Makefile
+++ b/Makefile
@@ -316,6 +316,7 @@ BOARD_SIZE_CHECK =
endif
# Always append ALL so that arch config.mk's can add custom ones
+ALL += spl
ALL += $(obj)u-boot.srec $(obj)u-boot.bin $(obj)System.map
This patch seems strangely white-space corrupted.
Maybe, because I copy-pasted in Thunderbird instead of git-send-mail.
ifeq ($(CONFIG_NAND_U_BOOT),y)
@@ -428,6 +429,9 @@ $(obj)u-boot-onenand.bin:onenand_ipl
$(obj)u-boot.bin
mmc_spl: $(TIMESTAMP_FILE) $(VERSION_FILE) depend
$(MAKE) -C mmc_spl/board/$(BOARDDIR) all
+spl:$(TIMESTAMP_FILE) $(VERSION_FILE) depend
+$(MAKE) -C spl/ all
+
$(obj)mmc_spl/u-boot-mmc-spl.bin: mmc_spl
The mmc_spl/ is suppoed to be moved into spl/, isn't it?
This patch was intended only as a prototype for the new directory
structure. I didn't bother to touch the existing stuff.
$(VERSION_FILE):
@@ -1142,6 +1146,7 @@ clean:
@rm -f $(obj)spl/{u-boot-spl-generated.lds,u-boot-spl,u-boot-spl.map}
@rm -f $(obj)onenand_ipl/onenand-{ipl,ipl.bin,ipl.map}
Dito here for onenand_ipl/ ?
@rm -f
$(obj)mmc_spl/{u-boot.lds,u-boot-spl,u-boot-spl.map,u-boot-spl.bin,u-boot-mmc-spl.bin}
...also line-wrapped.
+@rm -f
$(obj)spl/{u-boot.lds,u-boot-spl,u-boot-spl.map,u-boot-spl.bin,u-boot-mmc-spl.bin}
Make this:
@rm -f $(obj)spl/u-boot{.lds,-spl,-spl.map,-spl.bin,-mmc-spl.bin}
instead.
ok.
@rm -f $(ONENAND_BIN)
@rm -f $(obj)onenand_ipl/u-boot.lds
Goes away?
I am yet to think about the migration of existing code. If it's mere
movement of code I should be able to do it for all. But if it is about
re-factoring the code of other SoCs, I will not be able to do it. Hope
respective maintainers will take care of that.
--- /dev/null
+++ b/spl/Makefile
@@ -0,0 +1,94 @@
+#
+# (C) Copyright 2011 Daniel Schwierzeck, daniel.schwierz...@googlemail.com.
Really???
I copied Daniel's Makefile and started from there.
+# This file is released under the terms of GPL v2 and any later version.
+# See the file COPYING in the root directory of the source tree for
details.
+#
+
+include $(TOPDIR)/config.mk
+LIBS-$(CONFIG_SYS_SPL_MMC_SUPPORT) = mmc/libmmc.o
+LIBS-$(CONFIG_SYS_SPL_FAT_SUPPORT) += fat/libfat.o
+LIBS-$(CONFIG_SYS_SPL_NAND_SUPPORT) += nand/libnand.o
+LIBS-$(CONFIG_SYS_SPL_ONENAND_SUPPORT) += onenand/libonenand.o
As Mike mentioned, we can eventually directly include the OBJSs here
and omit the building of libraries?
I can't seem to find a mail from Mike on this thread. Did I miss any
mail?
Do you mean re-using equivalent libraries from the normal U-Boot
without re-compiling them?
+LIBS-y += $(shell if [ -f $(ARCH)/Makefile ]; then echo \
+$(ARCH)/lib$(ARCH).o; fi)
+LIBS-y += $(shell if [ -f $(ARCH)/$(CPU)/Makefile ]; then echo \
+$(ARCH)/$(CPU)/lib$(CPU).o; fi)
+LIBS-y += $(shell if [ -f $(ARCH)/$(CPU)/$(SOC)/Makefile ]; then echo \
+$(ARCH)/$(CPU)/$(SOC)/lib$(SOC).o; fi)
+LIBS-y += $(shell if [ -f $(ARCH)/$(CPU)/$(SOC)/$(BOARD)/Makefile ];
then echo \
+$(ARCH)/$(CPU)/$(SOC)/$(BOARD)/lib$(BOARD).o; fi)
We should probably use /$(BOARDDIR)? here instead of /$(BOARD)/ to
allow for vendor directories (where BOARDDIR = $(VENDOR)/$(BOARD)).
I didn't want to make the directory structure any longer than required.
But I can add this if required.
+ALL = $(obj)u-boot-spl.bin
+
+all:$(ALL)
Do we need ALL then at all?
ok. I will remove it.
...
diff --git a/spl/mmc/Makefile b/spl/mmc/Makefile
new file mode 100644
index 000..b4f7efd
--- /dev/null
+++ b/spl/mmc/Makefile
@@ -0,0 +1,55 @@
+#
+# (C) Copyright 2000-2003
+# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
Really???
Again I copied the Makefile from arch/arm/cpu/armv7/Makefile as a
template.
+$(obj)mmc.c:
+@rm -f $@
+@ln -s $(TOPDIR)/drivers/mmc/mmc.c $@
+
+$(obj)omap_hsmmc.c:
+@rm -f $@
+@ln -s $(TOPDIR)/drivers/mmc/omap_hsmmc.c $@
Hm... can we try to do without the symlinks?
Re: [U-Boot] SPL framework re-design
Hi Ilya, On Monday 27 June 2011 04:47 AM, Ilya Yanok wrote: Hello everybody, I've read the whole thread and I really like what Daniel suggests but I just want to speak it in a little bit different words. I wonder why do we need this whole spl thing in the first place (well, surely I know what they are used for but why do we need a separate entity for this)? Isn't it just the same U-Boot in, well, very special configuration (minimal set of drivers, no shell, etc)? Why do we need a whole shadow tree at spl/ instead of just providing the _configuration_? Am I missing something? The reason is that the regular U-Boot is not configurable enough to build the extremely small images that should fit in internal RAM. The last time I attempted, I ended up getting an ~60KB image for OMAP4(that too without any of the hardware initialization I am adding in my SPL work). Aneesh, what's the state of your patches? I'm especially interrested in OMAP3 (AM3517) support. Maybe I will be able to help you. I should be able to send out an updated revision of my series once we finalize on the new framework for SPL. BTW, John Rigby had sent out a series sometime back for OMAP3 NAND SPL. That can be integrated with my work and we will get an SPL that supports both MMC and NAND. I guess Simon Schwarz is also doing some work lately on OMAP3. best regards, Aneesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] omap3evm: Update ethernet reset sequence for Rev.G board
-Original Message- From: Premi, Sanjeev Sent: Thursday, June 23, 2011 4:48 PM To: Premi, Sanjeev; Igor Grinberg Cc: Govindarajan, Sriramakrishnan; u-boot@lists.denx.de Subject: RE: [U-Boot] [PATCH 2/3] omap3evm: Update ethernet reset sequence for Rev.G board -Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Premi, Sanjeev Sent: Thursday, June 23, 2011 4:43 PM To: Igor Grinberg Cc: Govindarajan, Sriramakrishnan; u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH 2/3] omap3evm: Update ethernet reset sequence for Rev.G board -Original Message- From: Igor Grinberg [mailto:grinb...@compulab.co.il] Sent: Thursday, June 23, 2011 2:38 PM To: Premi, Sanjeev Cc: u-boot@lists.denx.de; Govindarajan, Sriramakrishnan Subject: Re: [U-Boot] [PATCH 2/3] omap3evm: Update ethernet reset sequence for Rev.G board Hi Sanjeev, On 06/22/11 22:24, Sanjeev Premi wrote: From: Sriramakrishnan s...@ti.com The GPIO pin used for resetting the external LAN chip has changed for Rev.G board. Signed-off-by: Sriramakrishnan s...@ti.com Signed-off-by: Sanjeev Premi pr...@ti.com --- board/ti/evm/evm.c | 27 ++- 1 files changed, 18 insertions(+), 9 deletions(-) [snip]...[snip] + /* Send a pulse on the GPIO pin */ + writel(pin, gpio_base-setdataout); udelay(1); - writel(GPIO0, gpio3_base-cleardataout); + writel(pin, gpio_base-cleardataout); udelay(1); - writel(GPIO0, gpio3_base-setdataout); + writel(pin, gpio_base-setdataout); Why keep messing with the gpio registers? Why not use gpio framework? Though it is omap specific, but it will be much cleaner then the above. [sp] I guess the intent was to keep code similar. But yes, gpio framework can be used. [sp] Sorry, mail went earlier than I wanted :( The only issue is that I couln't see gpio framework for omap. Let me dig further... [sp] Implementing GPIO for OMAP would be a long task. It should be done for long term; but is it necessary pre-condition for the patch? ~sanjeev ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
