Re: [U-Boot] Help!Some memory doesn't work on PPC405Ex based board!
On 4/22/09 10:00 PM, SunNeo wrote: I got a new board with 1GB DDRII memory and only 1 Rank, but the problem still exist. The following is a summary of my job: 4. Have performed memory test with mtest command at U-Boot, no error happened. Sun: It's been awhile since I looked at the code for mtest; however, it may not be entirely comprehensive or exhaustive depending on how you configured your u-boot build and the arguments you invoked it with. Do verify that it is operating over the largest range of RAM possible and that it is doing an array of tests (walking 1s, alternating bit patterns, etc.). Also, AMCC has available (perhaps available through your FAE if not on MyAMCC or AMCC.com itself) a DDR planning spreadsheet. While the last revision I used had a few bugs, it certainly was useful to validate our DDR configuration against. I'd recommend obtaining it and reviewing your settings. Beyond that, does the same kernel work on Kilauea? Have you set up a build environment where you can make small, incremental changes and verify those on Kilauea and then on your board and have confidence that only those things you changed are changing? Once the wrinkles got worked out of the DDR settings in the PPC405EX[r] boards I've worked with in the last year, they all worked as well as Kilauea without notable changes to the Linux kernel, version 2.6.25 up through 2.6.28 (all from the Denx GIT repository). 9. Add the parameter mem=516M to bootargs, Linux can boot up normally. But if add mem=517M to bootargs, Linux hangs. That should be instructive. Start tweaking mtest or writing your own memory tests to tease out a pattern from that. Failing that, what other values work here? What values fail? Regards, Grant Erickson Principal Nuovations ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Enabling smc911x driver
On Wed, Apr 22, 2009 at 09:20:15PM -0700, Steve Sakoman wrote: Files longer that 544 bytes result in a timeout error: Overo # tftp test.txt smc911x: initializing smc911x: detected LAN9221 controller smc911x: phy initialized smc911x: MAC aa:bb:cc:dd:ee:ff TFTP from server 192.168.0.210; our IP address is 192.168.0.223 Filename 'test.txt'. Load address: 0x8200 Loading: T T T T T T T T T T Retry count exceeded; starting again Any ideas what might be going wrong here? Hmm. I had a similar issue a while ago and the reason was that on PXA3xx CPUs, the timer register behaved differently than on PXA2xxs and that was never tested. In fact, it was counting magnitudes faster there which made the network code bail out way to early. This was fixed for the platform I'm working with, but maybe you got a similar problem. Other than that, there might be something weird with your network. I'd suggest running wireshark on some host on that LAN and have a close look on the packets. Daniel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [ANNOUNCE] Kconfig support
On Wed, Apr 22, 2009 at 10:26:12AM -0400, Jerry Van Baren wrote: Wolfgang Denk wrote: Dear Wolfgang, Ladislav Michl wrote: That's perfectly understandable. I'm just trying to point out, that design flaws can be fixed incrementaly, without breaking anything attitude does not reflect reality. We break stuff and noone can test Please be fair. Re-read the whole discussion, and maybe the whole mailing list archive. Who was it who claimed that this was some (unwritten?) rule of U-Boot development? It is very difficult to defent against malicious roumors like this, so I tend to just ignore such accusations. Fact ist, they are just wrong. design flaws can be fixed incrementaly, without breaking anything comes from ...we should be doing ... poaching good ideas until we get to the point where v2 can simply die to which you replied Full ACK. I know it was not expressed exactly this way, I know you know there is and will be some breakage and I put it into this light to get a clue *why* we should. To quote Heiko: | And I have hope, that this multibus design can be adapted for other | subsystems too ... but somebody have to do this work, and if this | is in v1, he has to do this for all boards! My question was why we shoudn't break it the way everyone knows it is broken? Ie. during v1-v2 transition, whichever way it happens. Just like even/odd release numbering before linux-2.6 era. You may also read this as an opinion of someone who is unrelated to Pengutronix and understands the reasons behind the fork. On 2009-04-21 14:40:04 GMT, Wolfgang Denk: | What I missed, and what I still consider a big chance that was | missed, is any public discussion about such a new design - before the | actual work was started, or at least before such irrevocable | decisions were made as not to consider any form of an upgrade path. Whole this discussion proves that not discussing new design before showing code was right decission... And now there is a new code we can look at and we still should poaching good ideas until we get to the point where v2 can simply die and yet noone pointed which of them are good ones and if it is worth to go upgrade path. I consider that a big chance possibly missed ;-) And right, this leads to nowhere and I actually make mistake when writing my first post to this thread. Of course, board maintainers are supposed to regularly test new versions, and ideally provide fixes or at least complain about breakage. Actually quite a lot of boards that cover a wide bandwidth of different features and requirements *are* actually tested more or less regularly. There are broken boards around, too - of course. There are those board maintainers who simply dump their stuff on us and then never show up again with any contributions any more. Wolfgang, now please try to be fair to me - and I'm going to make it personal - and show where I reacted slowly, overreacted or did anything what prevented board I'm maintaining to be fixed in mainline. That code was written in 2005 and now, four years later it is still broken. Perhaps it is my fault that I do not stand pushing for more than a month at once, but all this is simply far over my patience (I sent arm925t timer fix, there was no reaction, but a document what I should measure. Gah... I sent board fixes for .03, there were scheduled for -next (why the hell, it touched board specific files only) and current code is broken again, so sent another bunch of patches...). I did not simply dump anything on you and I'm testing my code, showing in regular intervals and still cannot push it into mainline. And to do it I have to ping relevant custodian several times, whine on IRC and that all simply takes too much effort. Pushing anything into kernel is much easier. And to be fair to you, I know you can hardly do anything with that, but I couldn't resist and took your last sentence personal. I don't know how we could prevent that. It's probably happening with any similar software project. For exampole, do you think all exisitng board configurations in the Linux kernel are working, or even com- pile-clean? No, I didn't claimed that at all. It seems we are still missing each others point, so I'm inclined to end that as you suggested above. Thank you. Note that this happens even worse in the commercial world: how many printers were thrown in dumpsters because users bought a new computer running Vista and the printer manufacturer couldn't be bothered to write a new Vista-clean driver for the printers they had already sold? They just said Sorry, buy a new printer. That is a very obvious example, there are tons of other examples. Heh, fortunately we have source and fortunately there are printers supporting postscript :) Best regards, ladis ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] arm925t: Fix CONFIG_SYS_HZ to 1000
On 01:12 Wed 22 Apr , Ladislav Michl wrote: Let CONFIG_SYS_HZ to have value of 1000 effectively fixing all users of get_timer. Changes since original version: * Set PTV=2 (divisor 8) for boards using 12MHz timer clock source to improve timer resolution. please put in the commit message code the timer resolution precision and please specify on which board you test it in the commit message Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Help!Some memory doesn't work on PPC405Ex based board!
Sun, On Thursday 23 April 2009, Grant Erickson wrote: On 4/22/09 10:00 PM, SunNeo wrote: I got a new board with 1GB DDRII memory and only 1 Rank, but the problem still exist. The following is a summary of my job: 4. Have performed memory test with mtest command at U-Boot, no error happened. Sun: It's been awhile since I looked at the code for mtest; however, it may not be entirely comprehensive or exhaustive depending on how you configured your u-boot build and the arguments you invoked it with. Do verify that it is operating over the largest range of RAM possible and that it is doing an array of tests (walking 1s, alternating bit patterns, etc.). Take a look at the mem test included in the POST framework (post/drivers/memory.c). This should be more extensive. snip 9. Add the parameter mem=516M to bootargs, Linux can boot up normally. But if add mem=517M to bootargs, Linux hangs. That should be instructive. Start tweaking mtest or writing your own memory tests to tease out a pattern from that. Failing that, what other values work here? What values fail? And I'm wondering why you are using such an old Linux kernel version. I suggest to at least test a recent arch/powerpc version. Perhaps this gives other results. Best regards, Stefan = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] arm925t: Fix CONFIG_SYS_HZ to 1000
On Thu, Apr 23, 2009 at 09:34:21AM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote: On 01:12 Wed 22 Apr , Ladislav Michl wrote: Let CONFIG_SYS_HZ to have value of 1000 effectively fixing all users of get_timer. Changes since original version: * Set PTV=2 (divisor 8) for boards using 12MHz timer clock source to improve timer resolution. please put in the commit message code the timer resolution precision and please specify on which board you test it in the commit message Okay. To eliminate human factor, I will use a scope hooked on gpio pin (we all love exact methods, don't we?) and include those results in the commit message. However, I cannot do this sooner than at next week. Patch will appear as v3 on mailing list. Best regards, ladis ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] NAND on mpc8360erdk
Renaud barbier wrote: I am in the middle of NAND debugging on a MPC8544 based system. BTW: also the TQM8548 module uses FSL UPM NAND. Wolfgang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Help!Some memory doesn't work on PPC405Ex based board!
Have performed a slow memory post using code in post/drivers/memory.c, still no error. I found memsize in post/driver/memory.c has a limit of 256MB, so I modify it to 1024M. Have tried Linux-2.6.29, same result. Best Regards, Sun From: s...@denx.de To: sunwx2...@hotmail.com Subject: Re: Help!Some memory doesn't work on PPC405Ex based board! Date: Thu, 23 Apr 2009 10:07:41 +0200 CC: gerick...@nuovations.com; f...@amcc.com; supp...@amcc.com; u-boot@lists.denx.de Sun, On Thursday 23 April 2009, Grant Erickson wrote: On 4/22/09 10:00 PM, SunNeo wrote: I got a new board with 1GB DDRII memory and only 1 Rank, but the problem still exist. The following is a summary of my job: 4. Have performed memory test with mtest command at U-Boot, no error happened. Sun: It's been awhile since I looked at the code for mtest; however, it may not be entirely comprehensive or exhaustive depending on how you configured your u-boot build and the arguments you invoked it with. Do verify that it is operating over the largest range of RAM possible and that it is doing an array of tests (walking 1s, alternating bit patterns, etc.). Take a look at the mem test included in the POST framework (post/drivers/memory.c). This should be more extensive. snip 9. Add the parameter mem=516M to bootargs, Linux can boot up normally. But if add mem=517M to bootargs, Linux hangs. That should be instructive. Start tweaking mtest or writing your own memory tests to tease out a pattern from that. Failing that, what other values work here? What values fail? And I'm wondering why you are using such an old Linux kernel version. I suggest to at least test a recent arch/powerpc version. Perhaps this gives other results. Best regards, Stefan = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = _ Live Search视频搜索，快速检索视频的利器！ http://www.live.com/?scope=video___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Bug in new at91 clock framework?
Jean-Christophe PLAGNIOL-VILLARD schrieb: On 12:15 Wed 22 Apr , Daniel Gorsulowski wrote: Hello Jean-Christophe, I'm not sure, but I think there is a bug in your new at91 clock framework. My board does only boot, if CONFIG_USB_ATMEL is defined. But the board does not have any usb-ports, so there is no need to define CONFIG_USB_ATMEL. The board is based on an Atmel AT91SAM9263 SoC. I've seen in with the one on my clock branch but if you use the one for the pull request normaly not I've test it on my 9263EK Best Regards, J. I'm working on git://git.denx.de/u-boot-at91.git branch clock I also have an AT91SAM9263-EK, but with a 16.0 MHz main oscillator. Everything is fine, as long as no changes were made. But if I undef CONFIG_USB_ATMEL and CONFIG_CMD_USB, the board does not boot. Only some cryptical characters appear after the RomBOOT term. It's the same behavior as on my own board. If i do the same on git://git.denx.de/u-boot.git branch master, everything works fine. (as well AT91SAM9263-EK as my board) Do you have any advice for debugging that problem? Best regards, Daniel Gorsulowski ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mips/vcth: Use generic 16550 uart driver
As the common code also handles baudrate switching, which the board
specific vct.c driver did not support, this is one of the rare
occassions where deleting code actually adds a feature :)
Signed-off-by: Detlev Zundel d...@denx.de
Acked-by: Stefan Roese s...@denx.de
---
drivers/serial/Makefile |3 +-
drivers/serial/vct.c| 125 ---
include/configs/vct.h | 13 +-
3 files changed, 13 insertions(+), 128 deletions(-)
delete mode 100755 drivers/serial/vct.c
diff --git a/drivers/serial/Makefile b/drivers/serial/Makefile
index bb99a34..14c818d 100644
--- a/drivers/serial/Makefile
+++ b/drivers/serial/Makefile
@@ -1,5 +1,5 @@
#
-# (C) Copyright 2006
+# (C) Copyright 2006-2009
# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
#
# See file CREDITS for list of people who contributed to this
@@ -50,7 +50,6 @@ COBJS-$(CONFIG_S3C44B0_SERIAL) += serial_s3c44b0.o
COBJS-$(CONFIG_XILINX_UARTLITE) += serial_xuartlite.o
COBJS-$(CONFIG_SCIF_CONSOLE) += serial_sh.o
COBJS-$(CONFIG_USB_TTY) += usbtty.o
-COBJS-$(CONFIG_VCT_SERIAL) += vct.o
COBJS := $(sort $(COBJS-y))
SRCS := $(COBJS:.o=.c)
diff --git a/drivers/serial/vct.c b/drivers/serial/vct.c
deleted file mode 100755
index 556c114..000
--- a/drivers/serial/vct.c
+++ /dev/null
@@ -1,125 +0,0 @@
-/*
- * (C) Copyright 2008 Stefan Roese s...@denx.de, DENX Software Engineering
- *
- * 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 config.h
-#include common.h
-#include asm/io.h
-
-#ifdef CONFIG_VCT_PLATINUMAVC
-#define UART_1_BASE0xBDC3
-#else
-#define UART_1_BASE0xBF89C000
-#endif
-
-#defineUART_RBR_OFF0x00/* receiver buffer reg
*/
-#defineUART_THR_OFF0x00/* transmit holding reg
*/
-#defineUART_DLL_OFF0x00/* divisor latch low reg
*/
-#defineUART_IER_OFF0x04/* interrupt enable reg
*/
-#defineUART_DLH_OFF0x04/* receiver buffer reg
*/
-#defineUART_FCR_OFF0x08/* fifo control register
*/
-#defineUART_LCR_OFF0x0c/* line control register
*/
-#defineUART_MCR_OFF0x10/* modem control register
*/
-#defineUART_LSR_OFF0x14/* line status register
*/
-#defineUART_MSR_OFF0x18/* modem status register
*/
-#defineUART_SCR_OFF0x1c/* scratch pad register
*/
-
-#define UART_RCV_DATA_RDY 0x01/* Data Received*/
-#define UART_XMT_HOLD_EMPTY0x20
-#define UART_TRANSMIT_EMPTY0x40
-
-/* 7 bit on line control reg. enalbing rw to dll and dlh */
-#define UART_LCR_DLAB 0x0080
-
-#define UART___9600_BDR0x84
-#define UART__19200_BDR0x42
-#define UART_115200_BDR0x08
-
-#define UART_DIS_ALL_INTER 0x00/* disable all interrupts */
-
-#define UART_5DATA_BITS0x /* 5 [bits] 1.5 bits 2
*/
-#define UART_6DATA_BITS0x0001 /* 6 [bits] 1 bits 2
*/
-#define UART_7DATA_BITS0x0002 /* 7 [bits] 1 bits 2
*/
-#define UART_8DATA_BITS0x0003 /* 8 [bits] 1 bits 2
*/
-
-static void vct_uart_set_baud_rate(u32 address, u32 dh, u32 dl)
-{
- u32 val = __raw_readl(UART_1_BASE + UART_LCR_OFF);
-
- /* set 7 bit on 1 */
- val |= UART_LCR_DLAB;
- __raw_writel(val, UART_1_BASE + UART_LCR_OFF);
-
- __raw_writel(dl, UART_1_BASE + UART_DLL_OFF);
- __raw_writel(dh, UART_1_BASE + UART_DLH_OFF);
-
- /* set 7 bit on 0 */
- val = ~UART_LCR_DLAB;
- __raw_writel(val, UART_1_BASE + UART_LCR_OFF);
-
- return;
-}
-
-int serial_init(void)
-{
- __raw_writel(UART_DIS_ALL_INTER, UART_1_BASE + UART_IER_OFF);
- vct_uart_set_baud_rate(UART_1_BASE, 0, UART_115200_BDR);
- __raw_writel(UART_8DATA_BITS, UART_1_BASE + UART_LCR_OFF);
-
- return 0;
-}
-
-void serial_setbrg(void)
-{
- /*
-* Baudrate change not supported currently, fixed to 115200 baud
-*/
-}
-
-void serial_putc(const char c)
-{
- if (c
Re: [U-Boot] [PATCH] mips/vcth: Use generic 16550 uart driver
Wolfgang, Detlev Zundel wrote: As the common code also handles baudrate switching, which the board specific vct.c driver did not support, this is one of the rare occassions where deleting code actually adds a feature :) Signed-off-by: Detlev Zundel d...@denx.de Acked-by: Stefan Roese s...@denx.de --- drivers/serial/Makefile |3 +- drivers/serial/vct.c| 125 --- include/configs/vct.h | 13 +- 3 files changed, 13 insertions(+), 128 deletions(-) delete mode 100755 drivers/serial/vct.c Please pick up directly, I'll not take care of this :-) -- Shinya Kuribayashi NEC Electronics ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v6] Marvell MV88E61XX Switch Driver support
Hi all, just an interesting side note: Statistics from v1 patch: board/Marvell/common/mv88e1116.c | 72 +++ board/Marvell/common/mv88e60xx.c | 409 + board/Marvell/common/mv88e61xx.c | 414 ++ 3 files changed, 895 insertions(+), 0 deletions(-) create mode 100644 board/Marvell/common/mv88e1116.c create mode 100644 board/Marvell/common/mv88e60xx.c create mode 100644 board/Marvell/common/mv88e61xx.c Statistics from v6 patch: drivers/net/phy/Makefile|1 + drivers/net/phy/mv88e61xx.c | 244 +++ drivers/net/phy/mv88e61xx.h | 143 + include/netdev.h|1 + 4 files changed, 389 insertions(+), 0 deletions(-) create mode 100644 drivers/net/phy/mv88e61xx.c create mode 100644 drivers/net/phy/mv88e61xx.h Now even without looking at the details, if this isn't a *pretty* good example of what showing code and a review process can do, then I really don't know. Thanks all for the good work! Detlev -- [Linux] USB consoles was a bad hack written on a drunken dare. I'm still constantly amazed that the thing even works at all, let alone the fact that people are actually using it :) -- Greg KH 20090420225358.gc28...@kroah.com -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Bug in new at91 clock framework?
I'm working on git://git.denx.de/u-boot-at91.git branch clock I also have an AT91SAM9263-EK, but with a 16.0 MHz main oscillator. Everything is fine, as long as no changes were made. But if I undef CONFIG_USB_ATMEL and CONFIG_CMD_USB, the board does not boot. Only some cryptical characters appear after the RomBOOT term. It's the same behavior as on my own board. use git://git.denx.de/u-boot-at91.git branch master Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v6] Marvell MV88E61XX Switch Driver support
-Original Message- From: Detlev Zundel [mailto:d...@denx.de] Sent: Thursday, April 23, 2009 6:00 PM To: Ben Warren Cc: Prafulla Wadaskar; u-boot@lists.denx.de; Ashish Karkare; Prabhanjan Sarnaik; Ronen Shitrit Subject: Re: [U-Boot] [PATCH v6] Marvell MV88E61XX Switch Driver support Hi all, just an interesting side note: Statistics from v1 patch: board/Marvell/common/mv88e1116.c | 72 +++ board/Marvell/common/mv88e60xx.c | 409 + board/Marvell/common/mv88e61xx.c | 414 ++ 3 files changed, 895 insertions(+), 0 deletions(-) create mode 100644 board/Marvell/common/mv88e1116.c create mode 100644 board/Marvell/common/mv88e60xx.c create mode 100644 board/Marvell/common/mv88e61xx.c Statistics from v6 patch: drivers/net/phy/Makefile|1 + drivers/net/phy/mv88e61xx.c | 244 +++ drivers/net/phy/mv88e61xx.h | 143 + include/netdev.h|1 + 4 files changed, 389 insertions(+), 0 deletions(-) create mode 100644 drivers/net/phy/mv88e61xx.c create mode 100644 drivers/net/phy/mv88e61xx.h Now even without looking at the details, if this isn't a *pretty* good example of what showing code and a review process can do, then I really don't know. I really appreciate a quality review feedback and great usability of existing code to make this considerable difference. Even you will find considerable reduced code size for my other upcoming patches. Thanks to everyone to make u-boot more structured... Regards.. Prafulla . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Bug in new at91 clock framework?
Jean-Christophe PLAGNIOL-VILLARD schrieb:
I'm working on git://git.denx.de/u-boot-at91.git branch clock
I also have an AT91SAM9263-EK, but with a 16.0 MHz main oscillator.
Everything is fine, as long as no changes were made. But if I undef
CONFIG_USB_ATMEL and CONFIG_CMD_USB, the board does not boot. Only
some cryptical characters appear after the RomBOOT term. It's the
same behavior as on my own board.
use git://git.denx.de/u-boot-at91.git branch master
Best Regards,
J.
Thank you, it works now. But I have to apply the attached patch.
Otherwise, I get a compiler error
cpu/arm926ejs/at91/libat91.a(clock.o): In function `at91_clock_init':
/data/home/danielg/git/u-boot-at91_new/cpu/arm926ejs/at91/clock.c:167:
undefined reference to `at91_pll_rate'
---
From 730db691fabf958d1b3d74e678f7f47a0776df16 Mon Sep 17 00:00:00 2001
From: Daniel Gorsulowski daniel.gorsulow...@esd.eu
Date: Thu, 23 Apr 2009 15:37:16 +0200
Subject: [PATCH] at91: fixed cpu/arm926ejs/at91/clock.c
Signed-off-by: Daniel Gorsulowski daniel.gorsulow...@esd.eu
---
cpu/arm926ejs/at91/clock.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/cpu/arm926ejs/at91/clock.c b/cpu/arm926ejs/at91/clock.c
index 31e53b3..f776f70 100644
--- a/cpu/arm926ejs/at91/clock.c
+++ b/cpu/arm926ejs/at91/clock.c
@@ -126,6 +126,7 @@ static unsigned at91_pll_calc(unsigned main_freq, unsigned
out_freq)
fail:
return 0;
}
+#endif
static u32 at91_pll_rate(u32 freq, u32 reg)
{
@@ -141,7 +142,6 @@ static u32 at91_pll_rate(u32 freq, u32 reg)
return freq;
}
-#endif
int at91_clock_init(unsigned long main_clock)
{
--
1.6.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3] Marvell MV88F6281GTW_GE Board support
This is Marvell's 88F6281_A0 based custom board developed for wireless access point product This patch is tested for- 1. Boot from DRAM/SPI flash/NFS 2. File transfer using tftp and loadb 3. SPI flash read/write/erase 4. Booting Linux kernel and RFS from SPI flash Reviewed-by: Ronen Shitrit rshit...@marvell.com Signed-off-by: Prafulla Wadaskar prafu...@marvell.com --- Change log v2: updated as per first review comments debug_prints updated to debug v3: updated as per review comments for v2 added mv88f6281gtw_ge.h file removed BITxx macros MAKEALL |1 + Makefile|3 + board/Marvell/mv88f6281gtw_ge/Makefile | 51 +++ board/Marvell/mv88f6281gtw_ge/config.mk | 25 board/Marvell/mv88f6281gtw_ge/mv88f6281gtw_ge.c | 102 + board/Marvell/mv88f6281gtw_ge/mv88f6281gtw_ge.h | 46 ++ board/Marvell/mv88f6281gtw_ge/u-boot.lds| 53 +++ include/configs/mv88f6281gtw_ge.h | 175 +++ 8 files changed, 456 insertions(+), 0 deletions(-) create mode 100644 board/Marvell/mv88f6281gtw_ge/Makefile create mode 100644 board/Marvell/mv88f6281gtw_ge/config.mk create mode 100644 board/Marvell/mv88f6281gtw_ge/mv88f6281gtw_ge.c create mode 100644 board/Marvell/mv88f6281gtw_ge/mv88f6281gtw_ge.h create mode 100644 board/Marvell/mv88f6281gtw_ge/u-boot.lds create mode 100644 include/configs/mv88f6281gtw_ge.h diff --git a/MAKEALL b/MAKEALL index e4eb42b..1caf81d 100755 --- a/MAKEALL +++ b/MAKEALL @@ -504,6 +504,7 @@ LIST_ARM9= \ cp946es \ cp966 \ lpd7a400\ + mv88f6281gtw_ge \ mx1ads \ mx1fs2 \ netstar \ diff --git a/Makefile b/Makefile index d2c7c3f..709e4be 100644 --- a/Makefile +++ b/Makefile @@ -2792,6 +2792,9 @@ lpd7a400_config \ lpd7a404_config: unconfig @$(MKCONFIG) $(@:_config=) arm lh7a40x lpd7a40x +mv88f6281gtw_ge_config: unconfig + @$(MKCONFIG) $(@:_config=) arm arm926ejs $(@:_config=) Marvell kirkwood + mx1ads_config : unconfig @$(MKCONFIG) $(@:_config=) arm arm920t mx1ads NULL imx diff --git a/board/Marvell/mv88f6281gtw_ge/Makefile b/board/Marvell/mv88f6281gtw_ge/Makefile new file mode 100644 index 000..8c49a3e --- /dev/null +++ b/board/Marvell/mv88f6281gtw_ge/Makefile @@ -0,0 +1,51 @@ +# +# (C) Copyright 2009 +# Marvell Semiconductor www.marvell.com +# Prafulla Wadaskar prafu...@marvell.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., 51 Franklin Street, Fifth Floor, Boston, +# MA 02110-1301 USA +# + +include $(TOPDIR)/config.mk + +LIB= $(obj)lib$(BOARD).a + +COBJS := mv88f6281gtw_ge.o + +SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c) +OBJS := $(addprefix $(obj),$(COBJS)) +SOBJS := $(addprefix $(obj),$(SOBJS)) + +$(LIB):$(obj).depend $(OBJS) $(SOBJS) + $(AR) $(ARFLAGS) $@ $(OBJS) $(SOBJS) + +clean: + rm -f $(SOBJS) $(OBJS) + +distclean: clean + rm -f $(LIB) core *.bak .depend + +# + +# defines $(obj).depend target +include $(SRCTREE)/rules.mk + +sinclude $(obj).depend + +# diff --git a/board/Marvell/mv88f6281gtw_ge/config.mk b/board/Marvell/mv88f6281gtw_ge/config.mk new file mode 100644 index 000..fb29a1b --- /dev/null +++ b/board/Marvell/mv88f6281gtw_ge/config.mk @@ -0,0 +1,25 @@ +# +# (C) Copyright 2009 +# Marvell Semiconductor www.marvell.com +# Prafulla Wadaskar prafu...@marvell.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. +# +#
[U-Boot] Booting uImage on the mx31
Hi, I am using an uImage generated by LTIB . I am not sure how the ideal uImage is generated for the PDK board. I try booting this uimage from RAM and then load it at 80008000. It gets stuck after done, booting the kernel. Please see the bootup messages below. Any hints? I hope with, 0x80008000 as the load address on the MX31, you eliminate the cause of one probable failure, overlay memory with the existing code on RAM e.g. existing u-boot and the compressed kernel image mc911x: MAC 92:92:92:bb:bb:bb TFTP from server 206.44.18.25; our IP address is 206.44.18.31 Filename 'uImage_spin2'. Load address: 0x8080 Loading: # # done Bytes transferred = 1665060 (196824 hex) ## Booting kernel from Legacy Image at 8080 ... Image Name: Linux-2.6.24-140-g68eb4b4 Created: 2009-04-23 3:28:44 UTC Image Type: ARM Linux Kernel Image (uncompressed) Data Size:1664996 Bytes = 1.6 MB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... Uncompressing Linux. ... done, booting the kernel. IT freezes here Thanks, Alfred. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] OMAP3: Print correct silicon revision
Dear Jean-Christophe,
Jean-Christophe PLAGNIOL-VILLARD wrote:
On 21:53 Tue 21 Apr , Sanjeev Premi wrote:
The function display_board_info() displays the silicon
revision as 2 - based on the return value from get_cpu_rev().
This is incorrect as the current Si version is 3.1
This patch displays the correct version; but does not
change get_cpu_rev() to minimize the code impact.
Signed-off-by: Sanjeev Premi pr...@ti.com
---
cpu/arm_cortexa8/omap3/sys_info.c | 37
+++--
1 files changed, 35 insertions(+), 2 deletions(-)
diff --git a/cpu/arm_cortexa8/omap3/sys_info.c
b/cpu/arm_cortexa8/omap3/sys_info.c
index b385b91..8c6a4d6 100644
--- a/cpu/arm_cortexa8/omap3/sys_info.c
+++ b/cpu/arm_cortexa8/omap3/sys_info.c
@@ -36,6 +36,8 @@ static gpmc_csx_t *gpmc_cs_base = (gpmc_csx_t
*)GPMC_CONFIG_CS0_BASE;
static sdrc_t *sdrc_base = (sdrc_t *)OMAP34XX_SDRC_BASE;
static ctrl_t *ctrl_base = (ctrl_t *)OMAP34XX_CTRL_BASE;
+static char omap_revision[8] = ;
why 8?
you only have 5 chars
so
static char omap_revision[6] = ;
will be enough
+
/*
* dieid_num_r(void) - read and set die ID
*/
@@ -90,6 +92,36 @@ u32 get_cpu_rev(void)
}
why not this
in the cpu header
#define ES20 1
#define ES21 2
#define ES30 3
#define ES31 4
+/**
+ * Converts cpu revision into a string
+ */
+void set_omap_revision(void)
char* get_str_omap_revision(void)
{
u32 idcode;
ctrl_id_t *id_base;
if (omap_revision[0] != '\0')
return omap_revision;
if (get_cpu_rev() == CPU_3430_ES1) {
strcat (omap_revision, ES1.0);
}
else {
id_base = (ctrl_id_t *)OMAP34XX_ID_L4_IO_BASE;
idcode = readl(id_base-idcode) 28;
switch(idcode) {
case ES20:
strcat (omap_revision, ES2.0);
break;
case ES21:
strcat (omap_revision, ES2.1);
break;
case ES30:
strcat (omap_revision, ES3.0);
break;
case ES31:
strcat (omap_revision, ES3.1);
break;
default:
strcat (str_rev, ES??);
}
return omap_revision;
}
Did you notice that we had some discussion about this and that Premi
will send an completely redone patch, soon?
http://lists.denx.de/pipermail/u-boot/2009-April/051186.html
http://lists.denx.de/pipermail/u-boot/2009-April/051187.html
http://lists.denx.de/pipermail/u-boot/2009-April/051191.html
http://lists.denx.de/pipermail/u-boot/2009-April/051189.html
http://lists.denx.de/pipermail/u-boot/2009-April/051193.html
http://lists.denx.de/pipermail/u-boot/2009-April/051194.html
http://lists.denx.de/pipermail/u-boot/2009-April/051228.html
http://lists.denx.de/pipermail/u-boot/2009-April/051241.html
Dirk
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] IRC log?, was: Re: U-Boot Timer Qualification
Ladislav Michl wrote: ... Well, I already complained about all such a testing on the IRC yesterday, ... Seconded, same point made on IRC. Btw, is there any chance to get an IRC log? Was this already discussed (and rejected)? Or are there any other issues? Opinions? #beagle has a nice log [1] which I use heavily not being online the whole day. Best regards Dirk [1] http://www.beagleboard.org/irclogs/index.php ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] arm925t: Fix CONFIG_SYS_HZ to 1000
Dear Jean-Christophe, Jean-Christophe PLAGNIOL-VILLARD wrote: On 01:12 Wed 22 Apr , Ladislav Michl wrote: Let CONFIG_SYS_HZ to have value of 1000 effectively fixing all users of get_timer. Changes since original version: * Set PTV=2 (divisor 8) for boards using 12MHz timer clock source to improve timer resolution. please put in the commit message code the timer resolution precision and please specify on which board you test it in the commit message It would be nice if we could get proper commit messages from you in future then, too. ;) Dirk P.S.: E.g. http://lists.denx.de/pipermail/u-boot/2009-March/049743.html http://lists.denx.de/pipermail/u-boot/2009-March/049871.html http://lists.denx.de/pipermail/u-boot/2009-March/049804.html http://lists.denx.de/pipermail/u-boot/2009-March/049741.html ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Booting uImage on the mx31
Dear alfred steele, In message 528f13590904230720n14e87cchb87505c1de085...@mail.gmail.com you wrote: I am using an uImage generated by LTIB . I am not sure how the ideal uImage is generated for the PDK board. ... Starting kernel ... U-Boot's responsibility end's here. Uncompressing Linux. ... done, booting the kernel. IT freezes here Attach a BDI and debug where it's hanging. Eventually just your machine ID is wrong. 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 Make it right before you make it faster. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Booting uImage on the mx31
On Thu, Apr 23, 2009 at 09:20:41AM -0500, alfred steele wrote: Any hints? I hope with, 0x80008000 as the load address on the MX31, you eliminate the cause of one probable failure, overlay memory with the existing code on RAM e.g. existing u-boot and the compressed kernel image mc911x: MAC 92:92:92:bb:bb:bb TFTP from server 206.44.18.25; our IP address is 206.44.18.31 Filename 'uImage_spin2'. Load address: 0x8080 Loading: # # done Bytes transferred = 1665060 (196824 hex) ## Booting kernel from Legacy Image at 8080 ... Image Name: Linux-2.6.24-140-g68eb4b4 Created: 2009-04-23 3:28:44 UTC Image Type: ARM Linux Kernel Image (uncompressed) Data Size:1664996 Bytes = 1.6 MB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... Uncompressing Linux. ... done, booting the kernel. See http://lists.arm.linux.org.uk/lurker/message/20081210.174754.29691349.en.html ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] Marvell Kirkwood family SOC support
On 07:16 Thu 23 Apr , Prafulla Wadaskar wrote:
Kirkwood family controllers are highly integrated SOCs
based on Feroceon-88FR131/Sheeva-88SV131 cpu core.
SOC versions supported:-
1) 88F6281-A0 define CONFIG_KW88F6281_A0
2) 88F6192-A0 define CONFIG_KW88F6192_A0
Other supported features:-
1) get_random_hex() function
2) SPI port controller driver
3) PCI Express port initialization
Contributors:
Yotam Admon yo...@marvell.com
Michael Blostein michae...@marvell.com
Reviewed-by: Ronen Shitrit rshit...@marvell.com
Signed-off-by: Prafulla Wadaskar prafu...@marvell.com
a general comment please sue tab for indentation not space
---
Change log:
v2: crated arch-kirkwood and moved some header files there
renamed and moved spi.c to drivers/spi/
renamed and moved serial.c to drivers/serial/
doimage utility removed
soc_init.S renamed as lowlevel_init.S
debug prints removed
v3: lowlevel_init.S converted to lowlevel_init.c
removed BITxx macros, removed entire assembly code
Added CONFIG_ARCH_LOWLEVE_INIT support for arm926ejs core
updated as per review comments for v2
board/Marvell/include/core.h |4 +
cpu/arm926ejs/kirkwood/Makefile | 49 +
cpu/arm926ejs/kirkwood/config.mk | 25 +++
cpu/arm926ejs/kirkwood/dram.c | 57 ++
cpu/arm926ejs/kirkwood/kwcore.c | 304
+
cpu/arm926ejs/kirkwood/kwcore.h | 112 +++
cpu/arm926ejs/kirkwood/lowlevel_init.c| 93 +
cpu/arm926ejs/kirkwood/timer.c| 165
cpu/arm926ejs/start.S |7 +-
drivers/serial/kirkwood_serial.c | 187 ++
drivers/spi/Makefile |1 +
drivers/spi/kirkwood_spi.c| 199 +++
include/asm-arm/arch-kirkwood/kirkwood.h | 140 +
include/asm-arm/arch-kirkwood/kw88f6192.h | 37
include/asm-arm/arch-kirkwood/kw88f6281.h | 37
+ } else
+ temp = ~14;
+ writel(KW_REG_CPU_L2_CONFIG, temp);
+
+ /* L2Cache settings */
+ asm(mrc p15, 1, %0, c15, c1, 0:=r(temp));
+
+ /* Disable L2C pre fetch - Set bit 24 */
+ env = getenv(disL2Prefetch);
sorry I've forget about it precedently btw please add a doc about all this env
var
+ if (env ((strcmp(env, no) == 0) || (strcmp(env, No) == 0)))
+ temp = ~124;
+ else
+ temp |= 124;
+
+ /* enable L2C - Set bit 22 */
+ env = getenv(disL2Cache);
+ if (!env || ((strcmp(env, no) == 0) || (strcmp(env, No) == 0)))
+ temp |= 122;
+ else
+ temp = ~122;
+
+ asm(mcr p15, 1, %0, c15, c1, 0: :r(temp));
please use set/get_cr
+
+ /* Enable i cache */
we have a cache management framework now
please take a look on the lib_arm/cache-cp15.c
+ asm(mrc p15, 0, %0, c1, c0, 0:=r(temp));
+ temp |= 112;
+ asm(mcr p15, 0, %0, c1, c0, 0: :r(temp));
+ /* Change reset vector to address 0x0 */
+ asm(mrc p15, 0, %0, c1, c0, 0:=r(temp));
+ temp = ~113;
+ asm(mcr p15, 0, %0, c1, c0, 0: :r(temp));
+
+ return (0);
+}
+
diff --git a/cpu/arm926ejs/kirkwood/kwcore.h b/cpu/arm926ejs/kirkwood/kwcore.h
new file mode 100644
index 000..feec86b
--- /dev/null
+++ b/cpu/arm926ejs/kirkwood/kwcore.h
+ asm volatile(mcr p15, 1, %0, c15, c1, 0@ writefr exfr
+ : : r (val) : cc);
+ isb();
+}
+
+/*
+ * Invalidate L2 Cache using co-proc instruction
+ */
+static inline void invalidate_l2_cache(void)
we need to have the same api for l2_cache management so please add it in
include/asm-arm/cache.h
+{
+ unsigned int val=0;
+
+ asm volatile(mcr p15, 1, %0, c15, c11, 0 @ invl l2 cache
+ : : r (val) : cc);
+ isb();
+}
+
+/*
+ * functions
+ */
+void reset_cpu(unsigned long ignored);
+unsigned char get_random_hex(void);
+unsigned int kw_sdram_bar(enum memory_bank bank);
+unsigned int kw_sdram_bs(enum memory_bank bank);
+int kw_window_ctrl_reg_init(void);
+void kw_gpio_init(unsigned int gpp0_oe_val, unsigned int gpp1_oe_val,
+ unsigned int gpp0_oe, unsigned int gpp1_oe);
+int kw_mpp_control_init(unsigned int mpp0_7, unsigned int mpp8_15,
+ unsigned int mpp16_23, unsigned int mpp24_31,
+ unsigned int mpp32_39, unsigned int mpp40_47,
+ unsigned int mpp48_55);
+int kw_misc_init_r(void);
+#endif /* __ASSEMBLY__ */
+
+#endif /* _KWCORE_H */
diff --git a/cpu/arm926ejs/kirkwood/lowlevel_init.c
b/cpu/arm926ejs/kirkwood/lowlevel_init.c
new file mode 100644
index 000..21bfc81
--- /dev/null
+++ b/cpu/arm926ejs/kirkwood/lowlevel_init.c
@@ -0,0 +1,93 @@
+/*
+ * (C) Copyright 2009
+ * Marvell Semiconductor www.marvell.com
+ * Prafulla
Re: [U-Boot] PCI on mpc832x?
On Thu, Apr 23, 2009 at 03:32:11PM +0200, Joakim Tjernlund wrote: Still trying to wrap my head around PCI and I wonder if I need to do some HW init in u-boot in order to use the PCI controller in Linux? Yes. See pci_init_board() in mpc8323erdb for an example. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v7] Marvell MV88E61XX Switch Driver support
Chips supported:-
1. 88E6161 6 port gbe swtich with 5 integrated PHYs
2. 88E6165 6 port gbe swtich with 5 integrated PHYs
2. 88E6132 3 port gbe swtich with 2 integrated PHYs
Platform specific configuration supported
default and router port vlan config supported
Note: This driver is supported and tested against
kirkwood egiga interface
Contributors:
Yotam Admon yo...@marvell.com
Michael Blostein michae...@marvell.com
Reviewed by: Ronen Shitrit rshit...@marvell.com
Signed-off-by: Prafulla Wadaskar prafu...@marvell.com
---
Change log:-
v2: updated as per review comments for v1
removed other two drivers form earlier patch
debug_prints removed
driver moved to drivers/net/
v3: updated as per review comments for v2
miiphy interface used, platform specific dependency resolved
Chip id detection and printing added
common code forked out
some cosmetic and magic number fixes
v4: updated as per review comments for v3
mv88e61xx.h added
platform specific configuration support added
some more documentation references provided
cleaned rgmii delay enable related code
v5: updated as per review comments for v3
code moved to drivers/net/phy/
vlan_init changed to vlan_config and platform specific
v6: mutichip related alias moved to header file
vlan_config functions renamed as port_vlan_config
mv_switch_88f61xx_init renamed as mv88f61xx_switch_initialization
the function prototype for same is added in netdev.h
v7: minor updates as per v6 review feedback
RD_PHY/WR_PHY macros defined and used in the code
drivers/net/phy/Makefile|1 +
drivers/net/phy/mv88e61xx.c | 298 +++
drivers/net/phy/mv88e61xx.h | 86 +
include/netdev.h|1 +
4 files changed, 386 insertions(+), 0 deletions(-)
create mode 100644 drivers/net/phy/mv88e61xx.c
create mode 100644 drivers/net/phy/mv88e61xx.h
diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
index 4fe3b05..3b92614 100644
--- a/drivers/net/phy/Makefile
+++ b/drivers/net/phy/Makefile
@@ -26,6 +26,7 @@ include $(TOPDIR)/config.mk
LIB:= $(obj)libphy.a
COBJS-$(CONFIG_BITBANGMII) += miiphybb.o
+COBJS-$(CONFIG_MV88E61XX_SWITCH) += mv88e61xx.o
COBJS := $(COBJS-y)
SRCS := $(COBJS:.o=.c)
diff --git a/drivers/net/phy/mv88e61xx.c b/drivers/net/phy/mv88e61xx.c
new file mode 100644
index 000..100934f
--- /dev/null
+++ b/drivers/net/phy/mv88e61xx.c
@@ -0,0 +1,298 @@
+/*
+ * (C) Copyright 2009
+ * Marvell Semiconductor www.marvell.com
+ * Prafulla Wadaskar prafu...@marvell.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., 51 Franklin Street, Fifth Floor, Boston,
+ * MA 02110-1301 USA
+ */
+
+#include common.h
+#include mv88e61xx.h
+
+#ifdef CONFIG_MV88E61XX_MULTICHIP_ADRMODE
+/* Chip Address mode
+ * The Switch support two modes of operation
+ * 1. single chip mode and
+ * 2. Multi-chip mode
+ * Refer section 9.2 9.3 in chip datasheet-02 for more details
+ *
+ * By default single chip mode is configured
+ * multichip mode operation can be configured in board header
+ */
+static int mv88e61xx_busychk_multic(u32 devaddr)
+{
+ u32 reg = 0;
+ u32 timeout = MV88E61XX_PHY_TIMEOUT;
+
+ /* Poll till SMIBusy bit is clear */
+ do {
+ miiphy_read(name, devaddr, 0x0, reg);
+ if (timeout-- == 0) {
+ printf(SMI busy timeout\n);
+ return -1;
+ }
+ } while (reg BIT15);
+ return 0;
+}
+
+static void mv88e61xx_wr_phy(char *name, u32 phy_adr, u32 reg_ofs, u16 data)
+{
+ u16 reg;
+ u32 mii_dev_addr;
+
+ /* command to read PHY dev address */
+ if (!miiphy_read(name, 0xEE, 0xEE, mii_dev_addr)) {
+ printf(Error..could not read PHY dev address\n);
+ return;
+ }
+ mv88e61xx_busychk_multic(mii_dev_addr);
+ /* Write data to Switch indirect data register */
+ miiphy_write(name, mii_dev_addr, 0x1, data);
+ /* Write command to Switch indirect command register (write) */
+ miiphy_write(name, mii_dev_addr, 0x0,
+reg_ofs | (phy_adr 5) | BIT10 | BIT12 | BIT15);
+}
+
+static void mv88e61xx_rd_phy(char *name, u32 phy_adr, u32 reg_ofs, u16 * data)
+{
+ u16 reg;
+ u32 mii_dev_addr;
+
+
[U-Boot] [PATCH v2] mpc83xx: MPC8360ERDK: fix environment offset configuration bug
The size of U-Boot binary for MPC8360ERDK increased ( 2 flash sectors now), so 'saveenv' will partially overwrite U-Boot in flash and will brick the board. This patch moves environment offset to fourth flash sector and also fixes CONFIG_SYS_MONITOR_LEN. Signed-off-by: Anatolij Gustschin ag...@denx.de --- Changes since first version: do it correct by using CONFIG_SYS_MONITOR_LEN in offset calculation and also incrementing CONFIG_SYS_MONITOR_LEN as needed. Kim, thanks for pointing this out! include/configs/MPC8360ERDK.h |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/include/configs/MPC8360ERDK.h b/include/configs/MPC8360ERDK.h index 11e75eb..deb92d2 100644 --- a/include/configs/MPC8360ERDK.h +++ b/include/configs/MPC8360ERDK.h @@ -162,7 +162,7 @@ #undef CONFIG_SYS_RAMBOOT #endif -#define CONFIG_SYS_MONITOR_LEN (256 * 1024) /* Reserve 256 kB for Mon */ +#define CONFIG_SYS_MONITOR_LEN (384 * 1024) /* Reserve 384 kB for Mon */ #define CONFIG_SYS_MALLOC_LEN (128 * 1024) /* Reserved for malloc */ /* @@ -354,7 +354,7 @@ #ifndef CONFIG_SYS_RAMBOOT #define CONFIG_ENV_IS_IN_FLASH 1 -#define CONFIG_ENV_ADDR(CONFIG_SYS_MONITOR_BASE + 0x4) +#define CONFIG_ENV_ADDR(CONFIG_SYS_MONITOR_BASE + CONFIG_SYS_MONITOR_LEN) #define CONFIG_ENV_SECT_SIZE 0x2 /* 128K(one sector) for env */ #define CONFIG_ENV_SIZE0x2 #else /* CONFIG_SYS_RAMBOOT */ -- 1.5.3.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Booting uImage on the mx31
Hi Wolfgang, Thanks for the inputs. So what you are saying that we have eliminated all cases of the bootloader being at fault here except for the mach id mismatch.?? How do i verify the mach id mismatch. Is it the same id i see on a bdinfo dump on uboot. I looked at linux/include/asm/mach-types.h in linux . Is that the correct place to look at? How do i debug this kind of an issue on the BDI since it may fall between the thin line of separation between MMU disabled and reenabled. Can i put a breakpoint on a specific_thing like start_kernel ..or do you mean doing a backtrace from the point it hangs? I am using PDK which actually limits me to change boot switches for booting it from NAND or RAM. On Thu, Apr 23, 2009 at 11:05 AM, Wolfgang Denk w...@denx.de wrote: Dear alfred steele, In message 528f13590904230720n14e87cchb87505c1de085...@mail.gmail.com you wrote: I am using an uImage generated by LTIB . I am not sure how the ideal uImage is generated for the PDK board. ... Starting kernel ... U-Boot's responsibility end's here. Uncompressing Linux. ... done, booting the kernel. IT freezes here Attach a BDI and debug where it's hanging. Eventually just your machine ID is wrong. 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 Make it right before you make it faster. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] NAND on mpc8360erdk
Thanks. I supposed the NAND on the TQM8548 is connected to the CPU as per Freescale Application Note. Wolfgang Grandegger wrote: Renaud barbier wrote: I am in the middle of NAND debugging on a MPC8544 based system. BTW: also the TQM8548 module uses FSL UPM NAND. Wolfgang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] mpc83xx: MPC8360ERDK: fix environment offset configuration bug
On Thu, 23 Apr 2009 21:29:34 +0200 Anatolij Gustschin ag...@denx.de wrote: The size of U-Boot binary for MPC8360ERDK increased ( 2 flash sectors now), so 'saveenv' will partially overwrite U-Boot in flash and will brick the board. This patch moves environment offset to fourth flash sector and also fixes CONFIG_SYS_MONITOR_LEN. Signed-off-by: Anatolij Gustschin ag...@denx.de --- applied, thanks. Kim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] Fix OneNAND ipl to read CONFIG_SYS_MONITOR_LEN
apgmoorthy wrote: Hi Scott, On Tuesday, March 31, 2009 4:04 AM Scott Wood Wrote : Note that there are a couple of board files (apollon and nmdk8815) that use the OneNAND loader that do not define CONFIG_SYS_MONITOR_LEN. I've added the maintainers to the Cc: list. CONFIG_SYS_MONITOR_LEN is not defined in include/configs/apollon.h as of now. This is done by the Post : [U-Boot] [PATCH 2/2] Fix OneNAND ipl to read CONFIG_SYS_MONITOR_LEN What do you feel about getting this one inside u-boot-nand-flash ? Such a change should go through the board maintainer, who knows better what the actual length is. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/7] Remove individual I2C commands and cleanup
Damned, I should have wait for the MAKEALL is finished ... the nearly two last boards showed me the following error: Configuring for CPCI750 board... cmd_i2c.c: In function 'do_i2c': cmd_i2c.c:1286: error: 'CONFIG_SYS_I2C_SLAVE' undeclared (first use in this function) cmd_i2c.c:1286: error: (Each undeclared identifier is reported only once cmd_i2c.c:1286: error: for each function it appears in.) make[1]: *** [cmd_i2c.o] Fehler 1 make[1]: *** Warte auf noch nicht beendete Prozesse... make: *** [common/libcommon.a] Fehler 2 ppc_82xx-size: './u-boot': No such file Configuring for ELPPC board... textdata bss dec hex filename 169744 19652 38320 227716 37984 ./u-boot Configuring for p3mx board... cmd_i2c.c: In function 'do_i2c': cmd_i2c.c:1286: error: 'CONFIG_SYS_I2C_SLAVE' undeclared (first use in this function) cmd_i2c.c:1286: error: (Each undeclared identifier is reported only once cmd_i2c.c:1286: error: for each function it appears in.) make[1]: *** [cmd_i2c.o] Fehler 1 make[1]: *** Warte auf noch nicht beendete Prozesse... make: *** [common/libcommon.a] Fehler 2 ppc_82xx-size: './u-boot': No such file Thanks for catching that Heiko. I'll send fixups tomorrow. Best, Peter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Booting uImage on the mx31
Hi Wolfgang, Thanks for the inputs. So what you are saying that we have eliminated all cases of the bootloader being at fault here except for the mach id mismatch.?? How do i verify the mach id mismatch. Is it the same id i see on a bdinfo dump on uboot. I looked at linux/include/asm/mach-types.h in linux . Is that the correct place to look at? From the uboot code and the uboot config bdinfo structure,looks like machine id is set correctly Bdinfo on uboot prompt gives me 5E7 which is 1511 i.e the machine id set in the kernel for the target -MX31 3stack board. What else could be wrong? How do i debug this kind of an issue on the BDI since it may fall between the thin line of separation between MMU disabled and reenabled. Can i put a breakpoint on a specific_thing like start_kernel ..or do you mean doing a backtrace from the point it hangs? I am using PDK which actually limits me to change boot switches for booting it from NAND or RAM. Thanks. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] U-boot -printk kernel crash dump using md on PDK
Hi All, I am using mx31 pdk and uImage generated by LTIB. Basically, my problem is my kernel gets stuck after printing the Done...Booting the kernel. Please the responses below. Upon inspecting the printk log by doing a memory dump of the _buf_log symbol in System.map(i translated it to the physical address before dumping it ). It seems before the console got initialized, the bootup was successful to a certain extent, but i am unable to interpret anything conclusive from the logs. ANy hints as to what might be happening? I am guessing that unexpected RAM regions are getting overwritten after uncompression happens or the sdram hasn't been initialized fully by U-boot. I have attached the printk circular buffer log. smc911x: initializing smc911x: detected NULL controller smc911x: phy initialized smc911x: MAC 92:92:92:bb:bb:bb TFTP from server 206.44.18.25; our IP address is 206.44.18.31 Filename 'zImage_spin2_23march'. Load address: 0x8100 Loading: * # # done Bytes transferred = 1665000 (1967e8 hex) = go 0x8100 ## Starting application at 0x8100 ... Uncompressing Linux. ... done, booting the kernel. PRINTK log == md 80350f68 5000 50 80350f68: 4c3e353c 78756e69 72657620 6e6f69735Linux version 80350f78: 362e3220 2d34322e 2d303431 65383667 2.6.24-140-g68e 80350f88: 34623462 79742820 406f7561 656c7954b4b4 (ty...@tyle 80350f98: 4c575372 694c6261 3278756e 2e4d412erSWLabLinux2.AM. 80350fa8: 50524f43 4952502e 28202956 20636367CORP.PRIV) (gcc 80350fb8: 73726576 206e6f69 2e312e34 23202932version 4.1.2) # 80350fc8: 52502033 504d4545 68542054 704120753 PREEMPT Thu Ap 80350fd8: 33322072 3a353120 323a3131 44432039r 23 15:11:29 CD 80350fe8: 30322054 3c0a3930 50433e34 41203a55T 2009.4CPU: A 80350ff8: 36764d52 6d6f632d 69746170 20656c62RMv6-compatible 80351008: 636f7270 6f737365 345b2072 62373031processor [4107b 80351018: 5d343633 76657220 6f697369 2034206e364] revision 4 80351028: 4d524128 45543676 202c294a 303d7263(ARMv6TEJ), cr=0 80351038: 33356530 0a663738 4d3e343c 696863610e5387f.4Machi 80351048: 203a656e 65657246 6c616373 584d2065ne: Freescale MX 80351058: 4d2f3133 20323358 74532d33 206b636131/MX32 3-Stack 80351068: 72616f42 343c0a64 6d654d3e 2079726fBoard.4Memory 80351078: 696c6f70 203a7963 20434345 61736964policy: ECC disa 80351088: 64656c62 6144202c 63206174 65686361bled, Data cache 80351098: 69727720 61626574 3c0a6b63 6e4f3e37 writeback.7On 803510a8: 646f6e20 20302065 61746f74 6761706c node 0 totalpag 803510b8: 203a7365 36373233 373c0a38 4420203ees: 32768.7 D 803510c8: 7a20414d 3a656e6f 20383420 65676170MA zone: 48 page 803510d8: 73752073 66206465 6d20726f 616d6d65s used for memma 803510e8: 373c0a70 4420203e 7a20414d 3a656e6fp.7 DMA zone: 803510f8: 70203020 73656761 73657220 65767265 0 pages reserve 80351108: 373c0a64 4420203e 7a20414d 3a656e6fd.7 DMA zone: 80351118: 39303620 61702036 2c736567 46494c20 6096 pages, LIF 80351128: 6162204f 3a686374 373c0a30 4e20203eO batch:0.7 N 80351138: 616d726f 6f7a206c 203a656e 20383032ormal zone: 208 80351148: 65676170 73752073 66206465 6d20726fpages used for m 80351158: 616d6d65 373c0a70 4e20203e 616d726femmap.7 Norma 80351168: 6f7a206c 203a656e 31343632 61702036l zone: 26416 pa 80351178: 2c736567 46494c20 6162204f 3a686374ges, LIFO batch: 80351188: 373c0a37 4d20203e 6261766f 7a20656c7.7 Movable z 80351198: 3a656e6f 70203020 73656761 65737520one: 0 pages use 803511a8: 6f662064 656d2072 70616d6d 3e343c0ad for memmap.4 803511b8: 30555043 2044203a 54504956 69727720CPU0: D VIPT wri 803511c8: 622d6574 206b6361 68636163 343c0a65te-back cache.4 803511d8: 5550433e 49203a30 63616320 203a6568CPU0: I cache: 803511e8: 38333631 79622034 2c736574 7373612016384 bytes, ass 803511f8: 6169636f 69766974 34207974 3233202cociativity 4, 32 80351208: 74796220 696c2065 2c73656e 38323120 byte lines, 128 80351218: 74657320 343c0a73 5550433e 44203a30 sets.4CPU0: D 80351228: 63616320 203a6568 38333631 79622034 cache: 16384 by 80351238: 2c736574 73736120 6169636f 69766974tes, associativi 80351248: 34207974 3233202c 74796220 696c2065ty 4, 32 byte li 80351258: 2c73656e 38323120 74657320 343c0a73nes, 128 sets.4 80351268: 6975423e 3120746c 6e6f7a20 73696c65Built 1 zonelis 80351278: 69207374 6f5a206e 6f20656e 72656472ts in Zone order 80351288: 6f6d202c 696c6962 67207974 70756f72, mobility group 80351298: 20676e69 202e6e6f 746f5420 70206c61ing on. Total p 803512a8: 73656761 3233203a 0a323135 4b3e353cages: 32512.5K 803512b8: 656e7265 6f63206c 6e616d6d 696c2064ernel command li 803512c8: 203a656e 6e696f6e 64727469 6e6f6320ne: noinitrd con
[U-Boot] [U-BOOT] cfi_flash.c fails to program NOR Flash SST39LF040
Hello, I have a board on which there is a NOR Flash SST39LF040. Previously, I copied flash.c from other boards. Now I am trying to migrate NOR Flash driver to use CFI, but it fails to program sectors which are not on the 0x1 boundaries. I found that in function flash_write_cfiword() @drivers/mtd/cfi_flash.c it issues command with address relative to sector address. However, according to SST39 series data sheet, it seems that we should issue command with address relative to flash base address? After I modified flash_write_cfiword() to issue command to sector 0, everything works fine. Is it a bug? Index: cfi_flash.c === RCS file: /usr/local/cvsroot/ctd/FA5A320LINUX26_u-boot/drivers/mtd/cfi_flash.c,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 cfi_flash.c --- cfi_flash.c 23 Mar 2009 02:54:57 - 1.1.1.1 +++ cfi_flash.c 24 Apr 2009 02:28:32 - @@ -839,8 +839,8 @@ case CFI_CMDSET_AMD_LEGACY: #endif sect = find_sector(info, dest); - flash_unlock_seq (info, sect); - flash_write_cmd (info, sect, info-addr_unlock1, AMD_CMD_WRITE); + flash_unlock_seq (info, 0); + flash_write_cmd (info, 0, info-addr_unlock1, AMD_CMD_WRITE); sect_found = 1; break; } regards Po-Yu Chuang ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] Fix OneNAND ipl to read CONFIG_SYS_MONITOR_LEN
Hi Kyungmin, - Original Message - From: Scott Wood scottw...@freescale.com To: apgmoorthy moorthy@samsung.com Cc: u-boot@lists.denx.de; rub...@unipv.it Sent: Friday, April 24, 2009 4:09 AM Subject: Re: [U-Boot] [PATCH 1/2] Fix OneNAND ipl to read CONFIG_SYS_MONITOR_LEN apgmoorthy wrote: Hi Scott, On Tuesday, March 31, 2009 4:04 AM Scott Wood Wrote : Note that there are a couple of board files (apollon and nmdk8815) that use the OneNAND loader that do not define CONFIG_SYS_MONITOR_LEN. I've added the maintainers to the Cc: list. CONFIG_SYS_MONITOR_LEN is not defined in include/configs/apollon.h as of now. This is done by the Post : [U-Boot] [PATCH 2/2] Fix OneNAND ipl to read CONFIG_SYS_MONITOR_LEN What do you feel about getting this one inside u-boot-nand-flash ? Such a change should go through the board maintainer, who knows better what the actual length is. -Scott Please provide your comments, Are you using Apollon board now days. Thanks Amit ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] 83xx: searching muram-data by compatible property
if using CONFIG_BOOTCOUNT_LIMIT feature on a MPC8360 CPU in the muram-data node, the reg entry needs to be updated. This is done in fdt_fixup_muram(), but we should use the compatible fsl,qe-muram-data for searching the node instead of searching the muram-data node with an absolute path. Signed-off-by: Heiko Schocher h...@denx.de --- cpu/mpc83xx/fdt.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/cpu/mpc83xx/fdt.c b/cpu/mpc83xx/fdt.c index 4cc9047..13443cb 100644 --- a/cpu/mpc83xx/fdt.c +++ b/cpu/mpc83xx/fdt.c @@ -41,8 +41,8 @@ void fdt_fixup_muram (void *blob) data[0] = 0; data[1] = QE_MURAM_SIZE - 2 * sizeof(unsigned long); - do_fixup_by_path(blob, /qe/muram/data-only, reg, - data, sizeof (data), 0); + do_fixup_by_compat(blob, fsl,qe-muram-data, reg, + data, sizeof (data), 0); } #endif -- 1.6.0.6 -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] Fix OneNAND ipl to read CONFIG_SYS_MONITOR_LEN
Hi, On Fri, Apr 24, 2009 at 2:28 PM, AYYANARPONNUSAMY GANGHEYAMOORTHY moorthy@samsung.com wrote: Hi Scott, On Apr 24, 2009 07:39 (GMT+09:00) Scott Woodscottw...@freescale.com wrote apgmoorthy wrote: This is done by the Post : [U-Boot] [PATCH 2/2] Fix OneNAND ipl to read CONFIG_SYS_MONITOR_LEN What do you feel about getting this one inside u-boot-nand-flash ? Such a change should go through the board maintainer, who knows better what the actual length is. - Correct , I got your point. Hi Kyungmin, Can you please make a call on this , for apollon and get CONFIG_SYS_MONITOR_LEN in. Actually, I don't like the CONFIG_SYS_MONITOR_LEN approaches, now you are consider the bad block at 1. But we can also consider the bad block 2, if there two consecutive 2 bad block at block 1, 2, we should define the CONFIG_SYS_MONITOR_LEN as 128KiB * 4 and reserved block block 4 always even though we use 2 blocks. Right, we should consider bad block at IPL, so my recommendation is IPL + u-boot should be fit at block 0 128KiB at OneNAND, 256KiB at Flex-OneNAND. In case of apollon. we should reduce the size as 128KiB for OneNAND side. If the IPL + u-boot size under 128KiB, Flex-OneNAND also can boot it. For simplicity How about to use block scheme? we always use block 0 for boot (IPL + u-boot) whatever block size. Thank you, Kyungmin Park ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
