[U-Boot] Confirmed Recipient
Hi all. Please check this mail and try to avoid these kind of fake mails. Regards, Kishore. -- Forwarded message -- From: Online-notification care...@toshiba-india.com Date: Mon, Oct 19, 2009 at 4:19 AM Subject: [U-Boot] Confirmed Recipient To: i...@msc.co.uk Your email address has won a lump sum of £539,000.00. To claim your win, contact Mr. Brian Smith on this Email: barr_smith2...@live.com ___ 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] Fwd: Re: OMAP3 EVM: Only ONENAND supported, no NAND any more?
-- Software Developer General Satellite Corp. ---BeginMessage--- I have not board with NAND, working with OneNAND only. But I think NAND support have not been removed. Maybe omap3_evm_config configures U-Boot to be built without NAND support. But you can reconfigure it, so NAND support will be included. On Friday 16 October 2009 19:54:53 you wrote: Tuma wrote: Sorry for my intrusion. But why NAND support was removed? It's a question, not a statement. Was NAND support removed? Best regards Dirk Maybe you need just reconfigure and build your U-Boot? On Friday 16 October 2009 19:29:11 Dirk Behme wrote: Hi, in a private mail someone mentioned that recent U-Boot for OMAP3 EVM has only support for ONENAND. And NAND support was removed? He still has an EVM with NAND. Any idea? Best regards Dirk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot -- Software Developer General Satellite Corp. ---End Message--- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] trouble with u-boot and bist fail on pcie adapter
I am using a recent version of u-boot (git from the past couple of weeks) and have an LSI SAS adapter on a canyonlands board. What I see happening is that u-boot reads the bist bit, then does numerous bar accesses, then sets the bist fail and latency words. Once the bist is set to fail, the lsi adapter doesn't respond to anything else and so Linux fails to see it when it boots. I've tried turning off pcie support in u-boot, in that case the bist did not get written but Linux kernel crashed during the init of the adapter. The LSI adapter does work fine in a ubuntu PC, so the hardware is likely good. This adapter is an LSISAS2008 gen 2 pcie board. On the PC it uses both IO and MEM spaces. I am unsure what to try next -- Linux should not assume any state about the adapter -- on the other hand, if u-boot does cause the board to go into an unrecoverable state, there isn't much the kernel can do about that. any help / suggestions / experiments would be much appreciated. Thanks Ayman ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] imx27lite stability problems.
2009/10/16 Wolfgang Denk w...@denx.de: Dear Javier Martin, In message eedb5540910160633o81b1ae3sf37b2a00a5474...@mail.gmail.com you wrote: I could finally test this in an original LogicPD i.mx27 litekit board and found the same problems. System gets stuck when issuing a ping command. - I am using u-boot-arm repository commit 617da90c1dcf65428ddfb63fef897439950bc915 without any modifications. Can you please use mainline, i. e. the master branch at git://git.denx.de/u-boot.git instead? Please, do you have an idea of what could I be missing? Well, there is a Possible iMX27 intermittent Ethernet connection issue rework issued by LPD on 7/8/2008; in essence the PHY's internal 1.8V core regulator may shut off at power up. To work around this, try and implement the following two hardware modifications: 1) Populate R841 with a 4.7K resistor. (This forces the internal core regulator off for the LAN8700. R841 is located on top of the PCB just above the LAN8700 IC. 2) Add a jumper wire from U125.5 to C561.1. This connects the on board 1.8V rail to the core ensuring that it is always powered. Before trying hardware fixes you suggested I tried using another toolchain which comes with LTIB for i.mx27ads: * I used arm-linux-gnueabi- toolchain from LTIB with the command: USE_PRIVATE_LIBGCC=yes make CROSS_COMPILE=arm-none-linux-gnueabi- And found some improvements, ping doesn't hang the system, although it fails, but the second time it is executed I get an error: = ping 192.168.0.40 FEC_MXC: Autonegotiation timeout Using FEC_MXC device ping failed; host 192.168.0.40 is not alive = ping 192.168.0.40 Unhandled Exception: exception mode: abort fsr: 0x0008 far: 0x000c **UNRECOVERABLE ERROR** There was a memory access exception at 0x000c of type 'extern fetch1' this may be due to an access to an invalid memory region, unaligned access, or a problem with the current memory map. Please check the memory layout section of your processor manual. For information about the active memory map type 'info cpu'. r00: a7e9c000 r01: r02: r03: r04: a7e816f8 r05: a7e81700 r06: r07: a7f31600 r08: a7e6ffe0 r09: r10: r11: r12: a7f326f0 sp: a7e6f270 lr: 0001a908 pc: a7f1774c spsr:00d3 cpsr:00d7 bt: sp: a7e6f1a8 (stack: a00667e4 - a00697e4) (fp:-a7e6f1d0, sp:a7e6f1a8) What toolchain are you using for compiling this? It seems I got a different behavior changing it. -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Please check if the patch for SMSC LAN9220 is missing
There were two patches submitted to add support for SMSC LAN9220 and
LAN9221.
The latter (more recent one) has been applied but the former hasn't yet.
Refer to the
following and check please.
Regards,
Seunghyeon Rhee
Thu Apr 23 07:36:25 CEST 2009
Daniel Mack wrote:
Signed-off-by: Daniel Mack daniel at caiaq.de
Cc: Sascha Hauer s.hauer at pengutronix.de
---
drivers/net/smc911x.h |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/net/smc911x.h b/drivers/net/smc911x.h
index 80d2ce0..2b01cf5 100644
--- a/drivers/net/smc911x.h
+++ b/drivers/net/smc911x.h
@@ -382,6 +382,7 @@ static inline void smc911x_reg_write(u32 addr,
u32 val)
#define CHIP_92160x116a
#define CHIP_92170x117a
#define CHIP_92180x118a
+#define CHIP_92200x9220
struct chip_id {
u16 id;
@@ -398,6 +399,7 @@ static const struct chip_id chip_ids[] = {
{ CHIP_9216, LAN9216 },
{ CHIP_9217, LAN9217 },
{ CHIP_9218, LAN9218 },
+{ CHIP_9220, LAN9220 },
{ 0, NULL },
};
Applied to net/next branch.
thanks,
Ben
Fri Jul 10 08:21:31 CEST 2009
Andreas Pretzsch wrote:
Signed-off-by: Andreas Pretzsch apr at cn-eng.de
---
drivers/net/smc911x.h |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/net/smc911x.h b/drivers/net/smc911x.h
index 80d2ce0..c14003c 100644
--- a/drivers/net/smc911x.h
+++ b/drivers/net/smc911x.h
@@ -382,6 +382,7 @@ static inline void smc911x_reg_write(u32 addr,
u32 val)
#define CHIP_92160x116a
#define CHIP_92170x117a
#define CHIP_92180x118a
+#define CHIP_92210x9221
struct chip_id {
u16 id;
@@ -398,6 +399,7 @@ static const struct chip_id chip_ids[] = {
{ CHIP_9216, LAN9216 },
{ CHIP_9217, LAN9217 },
{ CHIP_9218, LAN9218 },
+{ CHIP_9221, LAN9221 },
{ 0, NULL },
};
Applied to net repo.
thanks,
Ben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mcc200: fix build error
Fix compile error: include/configs/mcc200.h:401:6: error: #elif with no expression Signed-off-by: Wolfgang Denk w...@denx.de --- include/configs/mcc200.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/configs/mcc200.h b/include/configs/mcc200.h index e5812ee..7ef6385 100644 --- a/include/configs/mcc200.h +++ b/include/configs/mcc200.h @@ -398,7 +398,7 @@ #define CONFIG_SYS_NS16550_COM1(CONFIG_SYS_CS2_START | (CONFIG_QUART_CONSOLE - 1)5) #elif (CONFIG_QUART_CONSOLE 4) (CONFIG_QUART_CONSOLE 9) #define CONFIG_SYS_NS16550_COM1(CONFIG_SYS_CS1_START | (CONFIG_QUART_CONSOLE - 5)5) -#elif +#else #error Wrong QUART expander number. #endif -- 1.6.2.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] trouble with u-boot and bist fail on pcie adapter
Dear Ayman El-Khashab, In message 4adc055c.6080...@elkhashab.com you wrote: I am using a recent version of u-boot (git from the past couple of weeks) and have an LSI SAS adapter on a canyonlands board. What I see happening is that u-boot reads the bist bit, then does numerous bar accesses, then sets the bist fail and latency words. Once the bist is set to fail, the lsi adapter doesn't respond to anything else and so Linux fails to see it when it boots. I've tried turning off pcie support in u-boot, in that case the bist did not get written but Linux kernel crashed during the init of the adapter. The LSI adapter does work fine in a ubuntu PC, so the hardware is likely good. This adapter is an LSISAS2008 gen 2 pcie board. On the PC it uses both IO and MEM spaces. Did you try setting the pciscandelay variable? Try setting it to 5 (or 10) [seconds]. See also commit 6efc1fc0b63e55f94c5bc61d8dd23c918e3bc778 Author: Grzegorz Bernacki g...@semihalf.com Date: Fri Sep 7 18:35:37 2007 +0200 [PPC440SPe] PCIe environment settings for Katmai and Yucca - 'pciconfighost' is set by default in order to be able to scan bridges behind the primary host/PCIe - 'pciscandelay' env variable is recognized to allow for user-controlled delay before the PCIe bus enumeration; some peripheral devices require a significant delay before they can be scanned (e.g. LSI8408E); without the delay they are not detected Signed-off-by: Grzegorz Bernacki g...@semihalf.com 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 algorithm to do that is extremely nasty. You might want to mug someone with it. - M. Devine, Computer Science 340 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mcc200: fix build error
In message 1255937317-30777-1-git-send-email...@denx.de you wrote: Fix compile error: include/configs/mcc200.h:401:6: error: #elif with no expression Signed-off-by: Wolfgang Denk w...@denx.de --- include/configs/mcc200.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) Applied. 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 That was the thing about deserts. They had their own gravity. They sucked you into the centre. - Terry Pratchett, _Small Gods_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM pull request
Dear Sandeep, In message 0554bef07d437848af01b9c9b5f0bc5d93521...@dlee01.ent.ti.com you wrote: There were some issues with Overo Tobi ethernet support. I am aware of these. There was a follow up patch that was actually inline in an e-mail rather than formally being a patch. Thus I had to give it my own subject header. Please do not do this. Always keep the original Subject: lines in place. If needed, then request a resend of the patch (or resent it yourself). If you feel this is persnickety then please bear with me, but so far my patch tracking is based on the messages posted to the mailing list, and to make this work the Subject of the messages must match the title line of the commit messages. basically as you can see even I got confused as there was no formal patch. The patch was kind of inline and once Ben was OK as can be seen above, I applied it. I gave it my own header because I had to give something. I hope this clears and lingering issues Yes, it does. Thanks for the explanation. But next time let's please rather insist on a repost of a separate, easier to track patch. 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 I can call spirits from the vasty deep. Why so can I, or so can any man; but will they come when you do call for them? - Shakespeare, 1 King Henry IV, Act III, Scene I. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] davinci_dm355evm_config -make error
Thanks! I didn't edit anything when I cloned this but after changing it it built, flashed and ran just fine. 2009/10/18 Paulraj, Sandeep s-paul...@ti.com: Hi all The u-boot ti git source code (u-boot-ti) does not seem to build for the dm355evm. I am using an image from that source on my EVM. Nevertheless I tried to build again and it worked. I'm getting a lowlevel_init.S:619:2: error: #error Unknown DDR configuration!!! after : make davinci_dm355evm_config make This filed gets used only when you want low level init to happen. In the default config we have CONFIG_SKIP_LOWLEVEL_INIT. If we do not have this then the lowlevel_init.S gets compiled. Looks like you have removed this flag. The error is because it expects a flag(DDR_4BANKS or DDR_8BANKS) to be set if we want to use this file. Before I correct this am I missing something? -- --Adrian Edmonds ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot -- --Adrian Edmonds Ramat Yishay Home +972-(0)4-9930379 Mobile +972-54-680-0580 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM pull request v3
Dear Ben Warren, In message f8328f7c0910181853t3f8c305ai62841e6d7b487...@mail.gmail.com you wrote: I'm still OK with it, but let's try to clean up our workflow next release... I know you guys had quite a mess to clean up with ARM, so to some extent this chaos is understandable. Thanks for pointing this out. I also want to stress that I in no way intend to criticize anybody. I am well aware what amount of work you have been doing, and that all of this is completely new to many of you. I just want to point out the few rough edges we should try to iron out or even better to avoid next time. Big thanks to everybody. 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 Engineering without management is art. - Jeff Johnson ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/5] add TI da8xx support: new ethenet driver for da830 EMAC
Ben Warren wrote: Hi Tom, On Sun, Oct 18, 2009 at 10:26 AM, Tom tom@windriver.com mailto:tom@windriver.com wrote: Thompson, Nick (GE EntSol, Intelligent Platforms) wrote: Add a driver for the DA830 EMAC. This is very similar to the davinci_emac driver. It has been restructured to make it as similar as possible. Potentially the two could be merged, but I don't have access to other davinci type platforms to test for breakage after the inevitable mangling required. Signed-off-by: Nick Thompson nick.thomp...@gefanuc.com mailto:nick.thomp...@gefanuc.com Ben, Can I pass this review off to you ? Tom Yeah, I'll review the next spin. Since it won't require a new driver, it may make more sense to keep the patch parts together. Either way, I'll ACK/NAK it. regards, Ben Tom, Thank you for the very through review, I will go away and address the issues you raise and get some checking tools in place. Also I've figured out how to get Thunderbird on linux talking to my exchange server - I will test it's mangling abilities before my next patch. Ben, You are right of course, I picked up the driver from an old TI u-boot and updated it for CONFIG_NET_MULTI, but shyed away from making functional changes as it seems to work just fine. I will switch to the davinci driver and pull in changes only as required - with inline statics where I can. If I understood correctly, assuming the switch to davinci ethernet, you would prefer a single patch e-mail rather than 5? It will still be rather bigger than the 40kB suggested in the linux SubmittingPatches doc. Thanks, Nick. This next line is just a test please ignore: +static unsigned char emac_rx_buffers[EMAC_MAX_RX_BUFFERS * (EMAC_MAX_ETHERNET_PKT_SIZE + EMAC_PKT_ALIGN)]; ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] envcrc: check return value of fwrite()
Dear Mike Frysinger, In message 1255912994-4500-1-git-send-email-vap...@gentoo.org you wrote: Newer toolchains will often complain about unchecked fwrite(): envcrc.c:117: warning: ignoring return value of `fwrite´, declared with attribute warn_unused_result So check the return value to silence the warnings. Signed-off-by: Mike Frysinger vap...@gentoo.org --- tools/envcrc.c |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) Applied, thanks. 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 A witty saying proves nothing. - Voltaire ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Platform Flash XL
Can U-boot support platform Flash XL memories? When we tried it, u-boot crashed just before reading the size of the memory. Platform Flash XL by default supports synchronous reads. The memory controller that drives it however supports asynchronous read (there is no clock output). So the platform flash XL need to be explicitly set to asynchronous reads. Can U-boot cope with that (perhaps by changing some parameters in a header file?) Best Regards Mos Kogimtzis -- Scanned by iCritical. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2 v4] env: only build env_embedded and envcrc when needed
Dear Mike Frysinger, In message 200910182055.01744.vap...@gentoo.org you wrote: This patch seems to break a *lot* of boards: i'm attaching two patches here. since we're past the merge window but before rc1, i dont know how invasive you want to get. the first one restores env_embedded.o building for certain config options (even though it'll only produce a 0 byte file). if you want to be cautious for this release, then i guess we can merge just this patch. the second one attempts to clean up env_embedded.o in all linker scripts where the board would only end up with a 0 byte file. obviously i cant test any of these since i dont have the hardware, but the logic seems straight forward. if you want to stay cautious, this would go into the next branch for start of next merge window. or just merge the 2nd patch only and assume that people who dont test the rc1+ are dead boards anyways. i got some build errors even after these fixes, but they seem unrelated to my env_embedded changes as they have to do with sections filling up overflowing with my gcc-4.1.1 compiler. I would tend to apply your second patch - but looking at it I will not do it, as it seems to break boards just harder, i. e. they may build, but will fail to work. For example: ... diff --git a/board/tqc/tqm8xx/u-boot.lds b/board/tqc/tqm8xx/u-boot.lds index 2df8d84..8207b2c 100644 --- a/board/tqc/tqm8xx/u-boot.lds +++ b/board/tqc/tqm8xx/u-boot.lds @@ -21,6 +21,8 @@ * MA 02111-1307 USA */ +#include config.h + OUTPUT_ARCH(powerpc) /* Do we need any of these for elf? __DYNAMIC = 0;*/ @@ -64,8 +66,10 @@ SECTIONS lib_generic/zlib.o (.text) lib_ppc/cache.o (.text) +#ifdef CONFIG_ENV_IS_EMBEDDED . = DEFINED(env_offset) ? env_offset : .; common/env_embedded.o(.ppcenv) +#endif All TQM8xx boards use a hand-optimized linker script that places the envrionment (both the primary and the redundant copies) into the small boot sectors of the bottom boot block type NOR flash used on these boards (and the same is true for other boards as well; I know this for sure at least for IVM*, km8xx, purple, spc1920, stxxtc, trab). However, none of these #defines CONFIG_ENV_IS_EMBEDDED in their board config files. 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 Intel's new motto: United we stand. Divided we fall! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] avr32 portmux : fix incorrect port mask
The portmux peripheral pin selection code used when setting up the MACB1 ethernet port has a small (but critical !!) typo. Signed-off-by: Mark Jackson m...@mimc.co.uk --- cpu/at32ap/at32ap700x/portmux.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/cpu/at32ap/at32ap700x/portmux.c b/cpu/at32ap/at32ap700x/portmux.c index b1f2c6f..a60288f 100644 --- a/cpu/at32ap/at32ap700x/portmux.c +++ b/cpu/at32ap/at32ap700x/portmux.c @@ -122,7 +122,7 @@ void portmux_enable_macb1(unsigned long flags, unsigned long drive_strength) portd_mask |= (1 15);/* SPD */ /* REVISIT: Some pins are probably pure outputs */ - portmux_select_peripheral(PORTMUX_PORT_D, portc_mask, + portmux_select_peripheral(PORTMUX_PORT_D, portd_mask, PORTMUX_FUNC_B, PORTMUX_BUSKEEPER); portmux_select_peripheral(PORTMUX_PORT_C, portc_mask, PORTMUX_FUNC_B, PORTMUX_BUSKEEPER); ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] avr32 portmux : fix incorrect port mask
Hans-Christian Egtvedt wrote: On Mon, 19 Oct 2009 10:49:00 +0100 Mark Jackson mpfj-l...@mimc.co.uk wrote: The portmux peripheral pin selection code used when setting up the MACB1 ethernet port has a small (but critical !!) typo. It does? Where is this fixed in the patch? Not sure what you mean ... Signed-off-by: Mark Jackson m...@mimc.co.uk --- cpu/at32ap/at32ap700x/portmux.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/cpu/at32ap/at32ap700x/portmux.c b/cpu/at32ap/at32ap700x/portmux.c index b1f2c6f..a60288f 100644 --- a/cpu/at32ap/at32ap700x/portmux.c +++ b/cpu/at32ap/at32ap700x/portmux.c @@ -122,7 +122,7 @@ void portmux_enable_macb1(unsigned long flags, unsigned long drive_strength) portd_mask |= (1 15);/* SPD */ /* REVISIT: Some pins are probably pure outputs */ -portmux_select_peripheral(PORTMUX_PORT_D, portc_mask, +portmux_select_peripheral(PORTMUX_PORT_D, portd_mask, This replaces portc_mask with portd_mask, which looks indeed correcter. ... and this looks like a simple typo to me !?! Mark ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] avr32 portmux : fix incorrect port mask
On Mon, 19 Oct 2009 10:49:00 +0100 Mark Jackson mpfj-l...@mimc.co.uk wrote: The portmux peripheral pin selection code used when setting up the MACB1 ethernet port has a small (but critical !!) typo. It does? Where is this fixed in the patch? Signed-off-by: Mark Jackson m...@mimc.co.uk --- cpu/at32ap/at32ap700x/portmux.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/cpu/at32ap/at32ap700x/portmux.c b/cpu/at32ap/at32ap700x/portmux.c index b1f2c6f..a60288f 100644 --- a/cpu/at32ap/at32ap700x/portmux.c +++ b/cpu/at32ap/at32ap700x/portmux.c @@ -122,7 +122,7 @@ void portmux_enable_macb1(unsigned long flags, unsigned long drive_strength) portd_mask |= (1 15);/* SPD */ /* REVISIT: Some pins are probably pure outputs */ - portmux_select_peripheral(PORTMUX_PORT_D, portc_mask, + portmux_select_peripheral(PORTMUX_PORT_D, portd_mask, This replaces portc_mask with portd_mask, which looks indeed correcter. snipp -- Best regards, Hans-Christian Egtvedt ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] avr32 portmux : fix incorrect port mask
On Mon, 19 Oct 2009 11:35:40 +0100 Mark Jackson mpfj-l...@mimc.co.uk wrote: Hans-Christian Egtvedt wrote: On Mon, 19 Oct 2009 10:49:00 +0100 Mark Jackson mpfj-l...@mimc.co.uk wrote: The portmux peripheral pin selection code used when setting up the MACB1 ethernet port has a small (but critical !!) typo. It does? Where is this fixed in the patch? Not sure what you mean ... Aha, rereading I get it, I thought you were fixing an actual !! typo somewhere in the code. snipp -- Best regards, Hans-Christian Egtvedt ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] avr32 portmux : fix incorrect port mask
Hans-Christian Egtvedt wrote: On Mon, 19 Oct 2009 11:35:40 +0100 Mark Jackson mpfj-l...@mimc.co.uk wrote: Hans-Christian Egtvedt wrote: On Mon, 19 Oct 2009 10:49:00 +0100 Mark Jackson mpfj-l...@mimc.co.uk wrote: The portmux peripheral pin selection code used when setting up the MACB1 ethernet port has a small (but critical !!) typo. It does? Where is this fixed in the patch? Not sure what you mean ... Aha, rereading I get it, I thought you were fixing an actual !! typo somewhere in the code. Ho, ho ... I guess my comment is a bit misleading :-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/3] video: mb862xx: add option VIDEO_FB_16BPP_WORD_SWAP for IPEK01
In 16 bpp mode, the new IPEK01 board only requires swapping of D16 words for D32 accesses due to the diffferent connecting to the GDC bus. This patch introduces the configuration option VIDEO_FB_16BPP_WORD_SWAP, which should be set for all board using the mb862xx in 16 bpp mode. For the IPEK01, VIDEO_FB_16BPP_PIXEL_SWAP should not be set. Signed-off-by: Wolfgang Grandegger w...@grandegger.com --- drivers/video/cfb_console.c |2 +- include/configs/lwmon5.h|1 + include/configs/socrates.h |1 + 3 files changed, 3 insertions(+), 1 deletion(-) Index: u-boot-mainline/drivers/video/cfb_console.c === --- u-boot-mainline.orig/drivers/video/cfb_console.c2009-10-19 13:17:17.466553428 +0200 +++ u-boot-mainline/drivers/video/cfb_console.c 2009-10-19 13:17:17.495553669 +0200 @@ -321,7 +321,7 @@ #else #define SWAP16(x) (x) #define SWAP32(x) (x) -#if defined(VIDEO_FB_16BPP_PIXEL_SWAP) +#if defined(VIDEO_FB_16BPP_WORD_SWAP) #define SHORTSWAP32(x) ( ((x) 16) | ((x) 16) ) #else #define SHORTSWAP32(x) (x) Index: u-boot-mainline/include/configs/lwmon5.h === --- u-boot-mainline.orig/include/configs/lwmon5.h 2009-10-19 13:17:17.471552467 +0200 +++ u-boot-mainline/include/configs/lwmon5.h2009-10-19 13:17:17.496553812 +0200 @@ -349,6 +349,7 @@ #define CONFIG_VIDEO_LOGO #define CONFIG_CONSOLE_EXTRA_INFO #define VIDEO_FB_16BPP_PIXEL_SWAP +#define VIDEO_FB_16BPP_WORD_SWAP #define CONFIG_VGA_AS_SINGLE_DEVICE #define CONFIG_VIDEO_SW_CURSOR Index: u-boot-mainline/include/configs/socrates.h === --- u-boot-mainline.orig/include/configs/socrates.h 2009-10-19 13:17:17.474552618 +0200 +++ u-boot-mainline/include/configs/socrates.h 2009-10-19 13:17:17.497553676 +0200 @@ -204,6 +204,7 @@ #define CONFIG_VIDEO_BMP_LOGO #define CONFIG_CONSOLE_EXTRA_INFO #define VIDEO_FB_16BPP_PIXEL_SWAP +#define VIDEO_FB_16BPP_WORD_SWAP #define CONFIG_VGA_AS_SINGLE_DEVICE #define CONFIG_SYS_CONSOLE_IS_IN_ENV #define CONFIG_VIDEO_SW_CURSOR ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3] video: mb862xx: add option CONFIG_VIDEO_MB862xx_ACCEL for X888RGB mode
The new IPEK01 board uses the X888RGB mode for the Lime graphics
controller. For this mode video accelaration does not work. This patch
makes the accelaration configurable via CONFIG_VIDEO_MB862xx_ACCEL,
which is enabled for the lwmon5 and the socrates board for backward
compatibility.
Signed-off-by: Anatolij Gustschin ag...@denx.de
Signed-off-by: Wolfgang Grandegger w...@grandegger.com
---
drivers/video/cfb_console.c |2 ++
drivers/video/mb862xx.c | 16 +++-
include/configs/lwmon5.h|1 +
include/configs/socrates.h |1 +
4 files changed, 19 insertions(+), 1 deletion(-)
Index: u-boot-mainline/drivers/video/cfb_console.c
===
--- u-boot-mainline.orig/drivers/video/cfb_console.c2009-10-19
13:17:14.582303087 +0200
+++ u-boot-mainline/drivers/video/cfb_console.c 2009-10-19 13:17:29.406303158
+0200
@@ -146,9 +146,11 @@
#ifdef CONFIG_VIDEO_CORALP
#define VIDEO_FB_LITTLE_ENDIAN
#endif
+#ifdef CONFIG_VIDEO_MB862xx_ACCEL
#define VIDEO_HW_RECTFILL
#define VIDEO_HW_BITBLT
#endif
+#endif
/*/
/* Include video_fb.h after definitions of VIDEO_HW_RECTFILL etc*/
Index: u-boot-mainline/drivers/video/mb862xx.c
===
--- u-boot-mainline.orig/drivers/video/mb862xx.c2009-10-19
13:17:14.582303087 +0200
+++ u-boot-mainline/drivers/video/mb862xx.c 2009-10-19 13:17:17.467553012
+0200
@@ -89,6 +89,7 @@
(GC_DISP_BASE | GC_L0PAL0) + \
((idx) 2)), (val))
+#if defined(CONFIG_VIDEO_MB862xx_ACCEL)
static void gdc_sw_reset (void)
{
GraphicDevice *dev = mb862xx;
@@ -129,6 +130,7 @@
break;
}
}
+#endif
#if !defined(CONFIG_VIDEO_CORALP)
static void board_disp_init (void)
@@ -144,11 +146,13 @@
#endif
/*
- * Init drawing engine
+ * Init drawing engine if accel enabled.
+ * Also clears visible framebuffer.
*/
static void de_init (void)
{
GraphicDevice *dev = mb862xx;
+#if defined(CONFIG_VIDEO_MB862xx_ACCEL)
int cf = (dev-gdfBytesPP == 1) ? 0x : 0x8000;
dev-dprBase = dev-frameAdrs + GC_DRAW_BASE;
@@ -174,6 +178,14 @@
DE_WR_FIFO (dev-winSizeY 16 | dev-winSizeX);
/* sync with SW access to framebuffer */
de_wait ();
+#else
+ unsigned int i, *p;
+
+ i = dev-winSizeX * dev-winSizeY;
+ p = (unsigned int *)dev-frameAdrs;
+ while (i--)
+ *p++ = 0;
+#endif
}
#if defined(CONFIG_VIDEO_CORALP)
@@ -389,6 +401,7 @@
L0PAL_WR_REG (index, (r 16) | (g 8) | (b));
}
+#if defined(CONFIG_VIDEO_MB862xx_ACCEL)
/*
* Drawing engine Fill and BitBlt screen region
*/
@@ -430,3 +443,4 @@
DE_WR_FIFO ((height 16) | width);
de_wait (); /* sync */
}
+#endif
Index: u-boot-mainline/include/configs/lwmon5.h
===
--- u-boot-mainline.orig/include/configs/lwmon5.h 2009-10-19
13:17:14.582303087 +0200
+++ u-boot-mainline/include/configs/lwmon5.h2009-10-19 13:17:29.406303158
+0200
@@ -344,6 +344,7 @@
/* Video console */
#define CONFIG_VIDEO
#define CONFIG_VIDEO_MB862xx
+#define CONFIG_VIDEO_MB862xx_ACCEL
#define CONFIG_CFB_CONSOLE
#define CONFIG_VIDEO_LOGO
#define CONFIG_CONSOLE_EXTRA_INFO
Index: u-boot-mainline/include/configs/socrates.h
===
--- u-boot-mainline.orig/include/configs/socrates.h 2009-10-19
13:17:14.583302392 +0200
+++ u-boot-mainline/include/configs/socrates.h 2009-10-19 13:17:29.406303158
+0200
@@ -198,6 +198,7 @@
#define CONFIG_VIDEO
#define CONFIG_VIDEO_MB862xx
+#define CONFIG_VIDEO_MB862xx_ACCEL
#define CONFIG_CFB_CONSOLE
#define CONFIG_VIDEO_LOGO
#define CONFIG_VIDEO_BMP_LOGO
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/3] mpc52xx: IPEK01 board support
Hello, this patch add support for the IPEK01 MPC5200 based board. It requires two patchs for the Fujitsu MB862xx driver: [PATCH 1/3] video: mb862xx: add option CONFIG_VIDEO_MB862xx_ACCEL for X888RGB mode [PATCH 2/3] video: mb862xx: add option VIDEO_FB_16BPP_WORD_SWAP for IPEK01 [PATCH 3/3] mpc52xx: add support for the IPEK01 board Wolfgang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/3] mpc52xx: add support for the IPEK01 board
This patch adds support for the board IPEK01 based on the MPC5200. The Futjitsu Lime graphics controller is configured in 16 bpp mode. Signed-off-by: Wolfgang Grandegger w...@grandegger.com --- Makefile|3 board/ipek01/Makefile | 50 board/ipek01/config.mk | 30 ++ board/ipek01/ipek01.c | 374 board/ipek01/mt46v16m16-75.h| 37 +++ board/ipek01/mt48lc16m16a2-75.h | 43 board/ipek01/u-boot.lds | 125 include/configs/ipek01.h| 411 8 files changed, 1073 insertions(+) create mode 100644 board/ipek01/Makefile create mode 100644 board/ipek01/config.mk create mode 100644 board/ipek01/ipek01.c create mode 100644 board/ipek01/mt46v16m16-75.h create mode 100644 board/ipek01/mt48lc16m16a2-75.h create mode 100644 board/ipek01/u-boot.lds create mode 100644 include/configs/ipek01.h Index: u-boot-mainline/Makefile === --- u-boot-mainline.orig/Makefile 2009-10-19 13:17:12.185302922 +0200 +++ u-boot-mainline/Makefile2009-10-19 13:17:17.519552635 +0200 @@ -725,6 +725,9 @@ } @$(MKCONFIG) -a PM520 ppc mpc5xxx pm520 +ipek01_config: unconfig + @$(MKCONFIG) -a ipek01 ppc mpc5xxx ipek01 + smmaco4_config: unconfig @$(MKCONFIG) -a smmaco4 ppc mpc5xxx tqm5200 tqc Index: u-boot-mainline/board/ipek01/Makefile === --- /dev/null 1970-01-01 00:00:00.0 + +++ u-boot-mainline/board/ipek01/Makefile 2009-10-19 13:17:17.521552642 +0200 @@ -0,0 +1,50 @@ +# +# (C) Copyright 2003-2006 +# Wolfgang Denk, DENX Software Engineering, w...@denx.de. +# +# 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).a + +COBJS := $(BOARD).o + +SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c) +OBJS := $(addprefix $(obj),$(COBJS)) +SOBJS := $(addprefix $(obj),$(SOBJS)) + +$(LIB):$(obj).depend $(OBJS) + $(AR) $(ARFLAGS) $@ $(OBJS) + +clean: + rm -f $(SOBJS) $(OBJS) + +distclean: clean + rm -f $(LIB) core *.bak .depend + +# + +# defines $(obj).depend target +include $(SRCTREE)/rules.mk + +sinclude $(obj).depend + +# Index: u-boot-mainline/board/ipek01/config.mk === --- /dev/null 1970-01-01 00:00:00.0 + +++ u-boot-mainline/board/ipek01/config.mk 2009-10-19 13:17:17.523553767 +0200 @@ -0,0 +1,30 @@ +# +# (C) Copyright 2003-2004 +# Wolfgang Denk, DENX Software Engineering, w...@denx.de. +# +# 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 +# + +# +# IPEK01 board +# + +TEXT_BASE = 0xfc00 + +PLATFORM_CPPFLAGS += -DTEXT_BASE=$(TEXT_BASE) -I$(TOPDIR)/board Index: u-boot-mainline/board/ipek01/ipek01.c === --- /dev/null 1970-01-01 00:00:00.0 + +++ u-boot-mainline/board/ipek01/ipek01.c 2009-10-19 13:17:17.527552105 +0200 @@ -0,0 +1,374 @@ +/* + * (C) Copyright 2003-2004 + * Wolfgang Denk, DENX Software Engineering, w...@denx.de. + * + * (C) Copyright 2004 + * Mark Jonas, Freescale Semiconductor, mark.jo...@motorola.com. + * + * (C)
Re: [U-Boot] [PATCH 1/3] video: mb862xx: add option CONFIG_VIDEO_MB862xx_ACCEL for X888RGB mode
Dear Wolfgang Grandegger, In message 20091019111913.427445...@denx.de you wrote: The new IPEK01 board uses the X888RGB mode for the Lime graphics controller. For this mode video accelaration does not work. This patch makes the accelaration configurable via CONFIG_VIDEO_MB862xx_ACCEL, which is enabled for the lwmon5 and the socrates board for backward compatibility. Why would you want to disable it for IPEK01? Accelaration seems to be a good thing you don't give up if you don't have to, but I cannot think of reasons why you would have to do without it? Index: u-boot-mainline/drivers/video/cfb_console.c === --- u-boot-mainline.orig/drivers/video/cfb_console.c 2009-10-19 13:17:14.582303087 +0200 +++ u-boot-mainline/drivers/video/cfb_console.c 2009-10-19 13:17:29.406303158 +0200 Please use git-format-patch to create patches. --- u-boot-mainline.orig/drivers/video/mb862xx.c 2009-10-19 13:17:14.582303087 +0200 +++ u-boot-mainline/drivers/video/mb862xx.c 2009-10-19 13:17:17.467553012 +0200 ... @@ -174,6 +178,14 @@ DE_WR_FIFO (dev-winSizeY 16 | dev-winSizeX); /* sync with SW access to framebuffer */ de_wait (); +#else + unsigned int i, *p; + + i = dev-winSizeX * dev-winSizeY; + p = (unsigned int *)dev-frameAdrs; + while (i--) + *p++ = 0; +#endif Why don't you use memset() here? 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 Use the Force, Luke. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] video: mb862xx: add option VIDEO_FB_16BPP_WORD_SWAP for IPEK01
Dear Wolfgang Grandegger, In message 20091019111913.621578...@denx.de you wrote: In 16 bpp mode, the new IPEK01 board only requires swapping of D16 words for D32 accesses due to the diffferent connecting to the GDC bus. This patch introduces the configuration option VIDEO_FB_16BPP_WORD_SWAP, which should be set for all board using the mb862xx in 16 bpp mode. For the IPEK01, VIDEO_FB_16BPP_PIXEL_SWAP should not be set. I don't see any functional change in this patch - all you do is renaming VIDEO_FB_16BPP_PIXEL_SWAP into VIDEO_FB_16BPP_WORD_SWAP. This makes no sense to me. 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 universe, they said, depended for its operation on the balance of four forces which they identified as charm, persuasion, uncertainty and bloody-mindedness. -- Terry Pratchett, The Light Fantastic ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] video: mb862xx: add option CONFIG_VIDEO_MB862xx_ACCEL for X888RGB mode
Wolfgang Denk wrote: Dear Wolfgang Grandegger, In message 20091019111913.427445...@denx.de you wrote: The new IPEK01 board uses the X888RGB mode for the Lime graphics controller. For this mode video accelaration does not work. This patch makes the accelaration configurable via CONFIG_VIDEO_MB862xx_ACCEL, which is enabled for the lwmon5 and the socrates board for backward compatibility. Why would you want to disable it for IPEK01? Accelaration seems to be a good thing you don't give up if you don't have to, but I cannot think of reasons why you would have to do without it? Because acceleration does work with 16 bpp but *not* with 32 bpp. That's the reason why we made it configurable. Well, this patch could be dropped, because the BSP for the IPEK01 posted here uses now 16 bpp as well. Index: u-boot-mainline/drivers/video/cfb_console.c === --- u-boot-mainline.orig/drivers/video/cfb_console.c 2009-10-19 13:17:14.582303087 +0200 +++ u-boot-mainline/drivers/video/cfb_console.c 2009-10-19 13:17:29.406303158 +0200 Please use git-format-patch to create patches. Why? Do you have any problems to apply these patches? I personally (still) prefer using quilt for patch stack management. --- u-boot-mainline.orig/drivers/video/mb862xx.c 2009-10-19 13:17:14.582303087 +0200 +++ u-boot-mainline/drivers/video/mb862xx.c 2009-10-19 13:17:17.467553012 +0200 ... @@ -174,6 +178,14 @@ DE_WR_FIFO (dev-winSizeY 16 | dev-winSizeX); /* sync with SW access to framebuffer */ de_wait (); +#else +unsigned int i, *p; + +i = dev-winSizeX * dev-winSizeY; +p = (unsigned int *)dev-frameAdrs; +while (i--) +*p++ = 0; +#endif Why don't you use memset() here? Maybe to ensure that D32 accesses are performed. Anatolij might know? Wolfgang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] video: mb862xx: add option VIDEO_FB_16BPP_WORD_SWAP for IPEK01
Wolfgang Denk wrote: Dear Wolfgang Grandegger, In message 20091019111913.621578...@denx.de you wrote: In 16 bpp mode, the new IPEK01 board only requires swapping of D16 words for D32 accesses due to the diffferent connecting to the GDC bus. This patch introduces the configuration option VIDEO_FB_16BPP_WORD_SWAP, which should be set for all board using the mb862xx in 16 bpp mode. For the IPEK01, VIDEO_FB_16BPP_PIXEL_SWAP should not be set. I don't see any functional change in this patch - all you do is renaming VIDEO_FB_16BPP_PIXEL_SWAP into VIDEO_FB_16BPP_WORD_SWAP. This makes no sense to me. Please have a look to the patched file. VIDEO_FB_16BPP_PIXEL_SWAP is used in other locations as well. This type of swapping is related to the way the GDC on the Socrates and lwmo5 board is connected. Wolfgang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [u-boot] [PATCH] [1/2] mxc_fec: fix some erroneous PHY accesses.
This patch fixes erroneous access to the ethernet PHY which broke the driver. 1. Selector field in the auto-negotiation register must be 0x1 for using 802.3, not 0x0 which is reseved. 2. Access to the PHY address specified by CONFIG_FEC_MXC_PHYADDR, not 0x0 fixed address. This has been tested in i.MX27 Litekit board and eldk-2.0 toolchains. Signed-off-by: Javier Martin javier.mar...@vista-silicon.com -- diff --git a/drivers/net/fec_mxc.c b/drivers/net/fec_mxc.c index bd83a24..18f0bba 100644 --- a/drivers/net/fec_mxc.c +++ b/drivers/net/fec_mxc.c @@ -157,7 +157,7 @@ static int miiphy_restart_aneg(struct eth_device *dev) /* * Set the auto-negotiation advertisement register bits */ - miiphy_write(dev-name, CONFIG_FEC_MXC_PHYADDR, PHY_ANAR, 0x1e0); + miiphy_write(dev-name, CONFIG_FEC_MXC_PHYADDR, PHY_ANAR, 0x1e1); miiphy_write(dev-name, CONFIG_FEC_MXC_PHYADDR, PHY_BMCR, PHY_BMCR_AUTON | PHY_BMCR_RST_NEG); @@ -341,8 +341,8 @@ static int fec_open(struct eth_device *edev) writel(FEC_ECNTRL_ETHER_EN, fec-eth-ecntrl); miiphy_wait_aneg(edev); - miiphy_speed(edev-name, 0); - miiphy_duplex(edev-name, 0); + miiphy_speed(edev-name, CONFIG_FEC_MXC_PHYADDR); + miiphy_duplex(edev-name, CONFIG_FEC_MXC_PHYADDR); /* * Enable SmartDMA receive task -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [u-boot] [PATCH] [2/2] mxc_fec: put freed pointers to NULL to avoid problems with further free() calls.
If a free() call is used on an already freed pointer we run into
stability problems.
Put all pointers to NULL after freeing to avoid this problem.
Tested on i.MX27 Litekit board with eldk-2.0 toolchain.
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
--
diff --git a/drivers/net/fec_mxc.c b/drivers/net/fec_mxc.c
index bd83a24..7e86bc6 100644
--- a/drivers/net/fec_mxc.c
+++ b/drivers/net/fec_mxc.c
@@ -444,6 +444,7 @@ static int fec_init(struct eth_device *dev, bd_t* bd)
*/
if (fec_rbd_init(fec, FEC_RBD_NUM, FEC_MAX_PKT_SIZE) 0) {
free(fec-base_ptr);
+ fec-base_ptr = NULL;
return -ENOMEM;
}
fec_tbd_init(fec);
@@ -492,7 +493,9 @@ static void fec_halt(struct eth_device *dev)
fec-rbd_index = 0;
fec-tbd_index = 0;
free(fec-rdb_ptr);
+ fec-rdb_ptr = NULL;
free(fec-base_ptr);
+ fec-base_ptr = NULL;
debug(eth_halt: done\n);
}
--
Javier Martin
Vista Silicon S.L.
CDTUC - FASE C - Oficina S-345
Avda de los Castros s/n
39005- Santander. Cantabria. Spain
+34 942 25 32 60
www.vista-silicon.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] mpc52xx: add support for the IPEK01 board
Dear Wolfgang Grandegger,
In message 20091019111913.802418...@denx.de you wrote:
This patch adds support for the board IPEK01 based on the MPC5200.
The Futjitsu Lime graphics controller is configured in 16 bpp mode.
Signed-off-by: Wolfgang Grandegger w...@grandegger.com
---
Makefile|3
board/ipek01/Makefile | 50
board/ipek01/config.mk | 30 ++
board/ipek01/ipek01.c | 374
board/ipek01/mt46v16m16-75.h| 37 +++
board/ipek01/mt48lc16m16a2-75.h | 43
board/ipek01/u-boot.lds | 125
include/configs/ipek01.h| 411
8 files changed, 1073 insertions(+)
create mode 100644 board/ipek01/Makefile
create mode 100644 board/ipek01/config.mk
create mode 100644 board/ipek01/ipek01.c
create mode 100644 board/ipek01/mt46v16m16-75.h
create mode 100644 board/ipek01/mt48lc16m16a2-75.h
create mode 100644 board/ipek01/u-boot.lds
create mode 100644 include/configs/ipek01.h
Entries to MAKEALL and MAINTAINERS are missing.
Index: u-boot-mainline/Makefile
===
--- u-boot-mainline.orig/Makefile 2009-10-19 13:17:12.185302922 +0200
+++ u-boot-mainline/Makefile 2009-10-19 13:17:17.519552635 +0200
@@ -725,6 +725,9 @@
}
@$(MKCONFIG) -a PM520 ppc mpc5xxx pm520
+ipek01_config: unconfig
+ @$(MKCONFIG) -a ipek01 ppc mpc5xxx ipek01
+
Please keep list ssorted.
Index: u-boot-mainline/board/ipek01/ipek01.c
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ u-boot-mainline/board/ipek01/ipek01.c 2009-10-19 13:17:17.527552105
+0200
...
+#ifndef CONFIG_SYS_RAMBOOT
Is RAM-Boot actually a asupported mode of operation on this board, or
are you just copuy pasting dead code here?
+static void sdram_start (int hi_addr)
+{
+ long hi_addr_bit = hi_addr ? 0x0100 : 0;
+
+ /* unlock mode register */
+ *(vu_long *) MPC5XXX_SDRAM_CTRL =
+ SDRAM_CONTROL | 0x8000 | hi_addr_bit;
+ __asm__ volatile (sync);
Please use I/O accessors to write device registers (please fix
globally).
...
+phys_size_t initdram (int board_type)
+{
+ ulong dramsize = 0;
+ ulong dramsize2 = 0;
+ uint svr, pvr;
+#ifndef CONFIG_SYS_RAMBOOT
+ ulong test1, test2;
+
+ /* setup SDRAM chip selects */
+ *(vu_long *) MPC5XXX_SDRAM_CS0CFG = 0x001e; /* 2G at 0x0 */
+ *(vu_long *) MPC5XXX_SDRAM_CS1CFG = 0x; /* disabled */
It might make sense to #define some constants in the board config
file.
+
+ /* setup config registers */
+ *(vu_long *) MPC5XXX_SDRAM_CONFIG1 = SDRAM_CONFIG1;
+ *(vu_long *) MPC5XXX_SDRAM_CONFIG2 = SDRAM_CONFIG2;
+ __asm__ volatile (sync);
+
+#if SDRAM_DDR
I consider this bad style. In U-Boot, we usually use #ifdef, but this
collides with your #define SDRAM_DDR 0 versus 1 below. I recommend to
clean this up.
+ /*
+ * On MPC5200B we need to set the special configuration delay in the
+ * DDR controller. Please refer to Freescale's AN3221 MPC5200B SDRAM
+ * Initialization and Configuration, 3.3.1 SDelay--MBAR + 0x0190:
+ *
+ * The SDelay should be written to a value of 0x0004. It is
+ * required to account for changes caused by normal wafer processing
+ * parameters.
+ */
+ svr = get_svr ();
+ pvr = get_pvr ();
+ if ((SVR_MJREV (svr) = 2) (PVR_MAJ (pvr) == 1)
+ (PVR_MIN (pvr) == 4)) {
+ *(vu_long *) MPC5XXX_SDRAM_SDELAY = 0x04;
+ __asm__ volatile (sync);
+ }
Is this test really needed? Are there versions of this board with
pre-Rev. B silicon?
+#if defined (CONFIG_CMD_IDE) defined (CONFIG_IDE_RESET)
+
+void init_ide_reset (void)
+{
+ debug (init_ide_reset\n);
+}
+
+void ide_set_reset (int idereset)
+{
+ debug (ide_reset(%d)\n, idereset);
+}
+#endif /* defined (CONFIG_SYS_CMD_IDE) defined (CONFIG_IDE_RESET) */
This is just dead code. Please get rid of it.
+#ifdef CONFIG_VIDEO
+#define DISPLAY_WIDTH800
+#define DISPLAY_HEIGHT 600
This should go to the board config file.
+#define CONFIG_SYS_LIME_SRST (CONFIG_SYS_LIME_BASE + 0x01FC002C)
+#define CONFIG_SYS_LIME_CCF (CONFIG_SYS_LIME_BASE + 0x01FC0038)
+#define CONFIG_SYS_LIME_MMR (CONFIG_SYS_LIME_BASE + 0x01FCFFFC)
+/* Lime clock frequency */
+#define CONFIG_SYS_LIME_CLK 0x9 /* geo 166MHz other 133MHz */
+/* SDRAM parameter */
+#define CONFIG_SYS_LIME_MMR_VALUE0x41c767e3
Please do not use base register plus offset. Use a proper C struct to
describe the device registers.
+#define CONFIG_SYS_LIME_CID (CONFIG_SYS_LIME_BASE + 0x01FC00F0)
+#define CONFIG_SYS_LIME_REV (CONFIG_SYS_LIME_BASE + 0x01FF8084)
Ditto.
+int
Re: [U-Boot] [PATCH 1/3] video: mb862xx: add option CONFIG_VIDEO_MB862xx_ACCEL for X888RGB mode
Dear Wolfgang, In message 4adc5661.7050...@grandegger.com you wrote: The new IPEK01 board uses the X888RGB mode for the Lime graphics controller. For this mode video accelaration does not work. This patch makes the accelaration configurable via CONFIG_VIDEO_MB862xx_ACCEL, which is enabled for the lwmon5 and the socrates board for backward compatibility. Why would you want to disable it for IPEK01? Accelaration seems to be a good thing you don't give up if you don't have to, but I cannot think of reasons why you would have to do without it? Because acceleration does work with 16 bpp but *not* with 32 bpp. That's the reason why we made it configurable. Well, this patch could be dropped, because the BSP for the IPEK01 posted here uses now 16 bpp as well. Then please either mention this fact in the commit message (the current one does not say anything about 16 versus 32 bit mode), or realy drop the patch. --- u-boot-mainline.orig/drivers/video/cfb_console.c 2009-10-19 13:17:14.582303087 +0200 +++ u-boot-mainline/drivers/video/cfb_console.c2009-10-19 13:17:29.406303158 +0200 Please use git-format-patch to create patches. Why? Do you have any problems to apply these patches? I personally (still) prefer using quilt for patch stack management. git-format-patch provides index information, which allows for intelligent merges (i. e. the merge code can then find the patch base and do a rebase internally). With your patches this is impossible. Fell free to use quilt or any other tools for your own purposes, but for patch submission please prepare the patches using git-format-patch +#else + unsigned int i, *p; + + i = dev-winSizeX * dev-winSizeY; + p = (unsigned int *)dev-frameAdrs; + while (i--) + *p++ = 0; +#endif Why don't you use memset() here? Maybe to ensure that D32 accesses are performed. Anatolij might know? How should Anatolij know? It is you who added this code, right? 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 Overdrawn? But I still have checks left! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] video: mb862xx: add option VIDEO_FB_16BPP_WORD_SWAP for IPEK01
Dear Wolfgang Grandegger, In message 4adc56e4.40...@grandegger.com you wrote: In 16 bpp mode, the new IPEK01 board only requires swapping of D16 words for D32 accesses due to the diffferent connecting to the GDC bus. This patch introduces the configuration option VIDEO_FB_16BPP_WORD_SWAP, which should be set for all board using the mb862xx in 16 bpp mode. For the IPEK01, VIDEO_FB_16BPP_PIXEL_SWAP should not be set. I don't see any functional change in this patch - all you do is renaming VIDEO_FB_16BPP_PIXEL_SWAP into VIDEO_FB_16BPP_WORD_SWAP. This makes no sense to me. Please have a look to the patched file. VIDEO_FB_16BPP_PIXEL_SWAP is used in other locations as well. This type of swapping is related to the way the GDC on the Socrates and lwmo5 board is connected. I see. But please add a description of VIDEO_FB_16BPP_PIXEL_SWAP and VIDEO_FB_16BPP_WORD_SWAP to 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 There is enough for the need of everyone in this world, but not for the greed of everyone. - Mahatma Gandhi ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/5] add TI da8xx support: new ethenet driver for da830 EMAC
Nick Thompson wrote: Ben Warren wrote: Hi Tom, On Sun, Oct 18, 2009 at 10:26 AM, Tom tom@windriver.com mailto:tom@windriver.com wrote: Thompson, Nick (GE EntSol, Intelligent Platforms) wrote: Add a driver for the DA830 EMAC. This is very similar to the davinci_emac driver. It has been restructured to make it as similar as possible. Potentially the two could be merged, but I don't have access to other davinci type platforms to test for breakage after the inevitable mangling required. Signed-off-by: Nick Thompson nick.thomp...@gefanuc.com mailto:nick.thomp...@gefanuc.com Ben, Can I pass this review off to you ? Tom Yeah, I'll review the next spin. Since it won't require a new driver, it may make more sense to keep the patch parts together. Either way, I'll ACK/NAK it. regards, Ben Tom, Thank you for the very through review, I will go away and address the issues you raise and get some checking tools in place. Also I've figured out how to get Thunderbird on linux talking to my exchange server - I will test it's mangling abilities before my next patch. Ben, You are right of course, I picked up the driver from an old TI u-boot and updated it for CONFIG_NET_MULTI, but shyed away from making functional changes as it seems to work just fine. I will switch to the davinci driver and pull in changes only as required - with inline statics where I can. If I understood correctly, assuming the switch to davinci ethernet, you would prefer a single patch e-mail rather than 5? It will still be rather bigger than the 40kB suggested in the linux SubmittingPatches doc. The way you did it with 5 is preferred. The 4/5 is a NET patch and that must be reviewed by Ben. The others are TI/ARM patches. Tom Thanks, Nick. This next line is just a test please ignore: +static unsigned char emac_rx_buffers[EMAC_MAX_RX_BUFFERS * (EMAC_MAX_ETHERNET_PKT_SIZE + EMAC_PKT_ALIGN)]; ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [u-boot] [PATCH] [2/2] mxc_fec: put freed pointers to NULL to avoid problems with further free() calls.
Dear javier Martin, In message eedb5540910190519l4551493eoc595ca39f0335...@mail.gmail.com you wrote: If a free() call is used on an already freed pointer we run into stability problems. Is this actually the case anywhere in the code? If so, that code should be fixed, as thisis obviously a bug then. I dislike workarounds like these as they just hush up design and/or implementation issues int he code. lease rather fix the real problems instead. Thanks. Tested on i.MX27 Litekit board with eldk-2.0 toolchain. ELDK 2.0? Wow. I did not think this was still in use anywhere around. 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 Most people would like to be delivered from temptation but would like it to keep in touch. - Robert Orben ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [u-boot] [PATCH] [2/2] mxc_fec: put freed pointers to NULL to avoid problems with further free() calls.
2009/10/19 Wolfgang Denk w...@denx.de: Dear javier Martin, In message eedb5540910190519l4551493eoc595ca39f0335...@mail.gmail.com you wrote: If a free() call is used on an already freed pointer we run into stability problems. Is this actually the case anywhere in the code? If so, that code should be fixed, as thisis obviously a bug then. I dislike workarounds like these as they just hush up design and/or implementation issues int he code. lease rather fix the real problems instead. Thanks. You are right. Tested on i.MX27 Litekit board with eldk-2.0 toolchain. ELDK 2.0? Wow. I did not think this was still in use anywhere around. This is obviously a typo, I used eldk-4.2. 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 Most people would like to be delivered from temptation but would like it to keep in touch. - Robert Orben Thank you for your comments, I will resent this patch fixing the real problem. -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] CONFIG_GENERIC_MMC Usage
After further reviewing the code I now see getting the PXA working with the GENERIC_MMC interface is more complex than I thought. From what I can tell reading through the code I really need to re-write the driver/pxa_mmc.c to support the mmc structure (include/mmc.h). It needs to have an initializer that sets up all of the variables in the mmc structure and have the required functions for the new mmc: send_cmd, set_ios and init. Before I attempt writing the pxa generic mmc code I just wanted to post and see if anyone else is working on it. Regards, Shane ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] video: mb862xx: add option CONFIG_VIDEO_MB862xx_ACCEL for X888RGB mode
Wolfgang Denk wrote: Dear Wolfgang, In message 4adc5661.7050...@grandegger.com you wrote: The new IPEK01 board uses the X888RGB mode for the Lime graphics controller. For this mode video accelaration does not work. This patch makes the accelaration configurable via CONFIG_VIDEO_MB862xx_ACCEL, which is enabled for the lwmon5 and the socrates board for backward compatibility. Why would you want to disable it for IPEK01? Accelaration seems to be a good thing you don't give up if you don't have to, but I cannot think of reasons why you would have to do without it? Because acceleration does work with 16 bpp but *not* with 32 bpp. That's the reason why we made it configurable. Well, this patch could be dropped, because the BSP for the IPEK01 posted here uses now 16 bpp as well. Then please either mention this fact in the commit message (the current one does not say anything about 16 versus 32 bit mode), or realy drop the patch. Well, X888RGB mode is a 32 bpp mode. I leave it up to Anatolij to accept this patch or not (he is actually the original author). --- u-boot-mainline.orig/drivers/video/cfb_console.c 2009-10-19 13:17:14.582303087 +0200 +++ u-boot-mainline/drivers/video/cfb_console.c2009-10-19 13:17:29.406303158 +0200 Please use git-format-patch to create patches. Why? Do you have any problems to apply these patches? I personally (still) prefer using quilt for patch stack management. git-format-patch provides index information, which allows for intelligent merges (i. e. the merge code can then find the patch base and do a rebase internally). With your patches this is impossible. Fell free to use quilt or any other tools for your own purposes, but for patch submission please prepare the patches using git-format-patch OK. +#else + unsigned int i, *p; + + i = dev-winSizeX * dev-winSizeY; + p = (unsigned int *)dev-frameAdrs; + while (i--) + *p++ = 0; +#endif Why don't you use memset() here? Maybe to ensure that D32 accesses are performed. Anatolij might know? How should Anatolij know? It is you who added this code, right? No, this patch is from Anatolij and he has added his signed-off-by. My signed-off-by is not correct, strictly speaking. I should have just added an acked-by or tested-by line. Will change. Wolfgang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] qemu_mips: Fix CONFIG_NET_MULTI build warning
eth.c:497:2: warning: #warning Ethernet driver is deprecated. Please update to use CONFIG_NET_MULTI Signed-off-by: Shinya Kuribayashi skuri...@pobox.com --- I have a few concerns about this fix: First. I'm not sure why CONFIG_NET_MULTI is undefed for qemu_mips, while CONFIG_DRIVER_NE2000 has been enabled for qemu_mips at an early stage. I don't follow recent changes around eth.c and CONFIG_NET_MULTI, but it's probably CONFIG_NET_MULTI used to be used strictly for multi ports, isn't it? Next. As far as looking at drivers/net/ne2000*.[ch], NE2000 driver doesn't seem to require board_eth_init() or cpu_eth_init(). Right? Therefore I've not added a corresponding hook in board/qemu_mips/ qemu_mips.c. If my understanding is wrong, please let me know. include/configs/qemu-mips.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/configs/qemu-mips.h b/include/configs/qemu-mips.h index cbacdf9..f419174 100644 --- a/include/configs/qemu-mips.h +++ b/include/configs/qemu-mips.h @@ -157,7 +157,7 @@ #define CONFIG_ENV_OVERWRITE 1 -#undef CONFIG_NET_MULTI +#define CONFIG_NET_MULTI #define MEM_SIZE 128 -- 1.6.5.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2] sheevaplug: correct SDRAM address control register value
The SheevaPlug DevKit is shipped with 4x8 by 1Gb DDR devices in two banks for a total of 512MB of RAM. Based on this configuration the existing values for SDRAM address control register are incorrect and result in random kernel oops as memory is incorrectly accessed (while for example extracting a large tarball such as a rootfs). Based on the hardware configuration along with the supporting documentation from Marvell these are the correct values, as well this change mimics values previously used in Marvell's own u-boot git tree for the SheevaPlug. Other variants of the hardware such as the PogoPlug and TonidoPlug may have different memory configurations but to properly support those additional board directories should be maintained or a better system to support other kwb*.cfg is needed. Tested on SheevaPlug DevKit. Signed-off-by: Mark Asselstine mark.asselst...@windriver.com --- Thanks Simon for the heads up on the documentation change. Changes from V1, fix comment reserved - x8. board/Marvell/sheevaplug/kwbimage.cfg | 10 +- 1 files changed, 5 insertions(+), 5 deletions(-) diff --git a/board/Marvell/sheevaplug/kwbimage.cfg b/board/Marvell/sheevaplug/kwbimage.cfg index 6c47d62..3b9c53f 100644 --- a/board/Marvell/sheevaplug/kwbimage.cfg +++ b/board/Marvell/sheevaplug/kwbimage.cfg @@ -74,11 +74,11 @@ DATA 0xFFD0140C 0x0a33 # DDR Timing (High) # bit12-11: TW2W # bit31-13: zero required -DATA 0xFFD01410 0x0099 # DDR Address Control -# bit1-0: 01, Cs0width=x16 -# bit3-2: 10, Cs0size=512Mb -# bit5-4: 01, Cs1width=x16 -# bit7-6: 10, Cs1size=512Mb +DATA 0xFFD01410 0x00cc # DDR Address Control +# bit1-0: 00, Cs0width=x8 +# bit3-2: 11, Cs0size=1Gb +# bit5-4: 00, Cs1width=x8 +# bit7-6: 11, Cs1size=1Gb # bit9-8: 00, Cs2width=nonexistent # bit11-10: 00, Cs2size =nonexistent # bit13-12: 00, Cs3width=nonexistent -- 1.6.3.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] mpc52xx: add support for the IPEK01 board
Wolfgang Denk wrote:
Dear Wolfgang Grandegger,
In message 20091019111913.802418...@denx.de you wrote:
This patch adds support for the board IPEK01 based on the MPC5200.
The Futjitsu Lime graphics controller is configured in 16 bpp mode.
Signed-off-by: Wolfgang Grandegger w...@grandegger.com
[...]
Index: u-boot-mainline/board/ipek01/ipek01.c
===
--- /dev/null1970-01-01 00:00:00.0 +
+++ u-boot-mainline/board/ipek01/ipek01.c2009-10-19 13:17:17.527552105
+0200
...
+#ifndef CONFIG_SYS_RAMBOOT
Is RAM-Boot actually a asupported mode of operation on this board, or
are you just copuy pasting dead code here?
If it's really dead code I'm going to prepare and send a patch removing
it for all boards. Would that be fine?
+static void sdram_start (int hi_addr)
+{
+long hi_addr_bit = hi_addr ? 0x0100 : 0;
+
+/* unlock mode register */
+*(vu_long *) MPC5XXX_SDRAM_CTRL =
+SDRAM_CONTROL | 0x8000 | hi_addr_bit;
+__asm__ volatile (sync);
Please use I/O accessors to write device registers (please fix
globally).
Well, I borrowed known to work code from other boards. Unfortunately
there are no better examples (yet). Will fix, of course.
...
+phys_size_t initdram (int board_type)
+{
+ulong dramsize = 0;
+ulong dramsize2 = 0;
+uint svr, pvr;
+#ifndef CONFIG_SYS_RAMBOOT
+ulong test1, test2;
+
+/* setup SDRAM chip selects */
+*(vu_long *) MPC5XXX_SDRAM_CS0CFG = 0x001e; /* 2G at 0x0 */
+*(vu_long *) MPC5XXX_SDRAM_CS1CFG = 0x; /* disabled */
It might make sense to #define some constants in the board config
file.
+
+/* setup config registers */
+*(vu_long *) MPC5XXX_SDRAM_CONFIG1 = SDRAM_CONFIG1;
+*(vu_long *) MPC5XXX_SDRAM_CONFIG2 = SDRAM_CONFIG2;
+__asm__ volatile (sync);
+
+#if SDRAM_DDR
I consider this bad style. In U-Boot, we usually use #ifdef, but this
collides with your #define SDRAM_DDR 0 versus 1 below. I recommend to
clean this up.
OK.
+/*
+ * On MPC5200B we need to set the special configuration delay in the
+ * DDR controller. Please refer to Freescale's AN3221 MPC5200B SDRAM
+ * Initialization and Configuration, 3.3.1 SDelay--MBAR + 0x0190:
+ *
+ * The SDelay should be written to a value of 0x0004. It is
+ * required to account for changes caused by normal wafer processing
+ * parameters.
+ */
+svr = get_svr ();
+pvr = get_pvr ();
+if ((SVR_MJREV (svr) = 2) (PVR_MAJ (pvr) == 1)
+(PVR_MIN (pvr) == 4)) {
+*(vu_long *) MPC5XXX_SDRAM_SDELAY = 0x04;
+__asm__ volatile (sync);
+}
Is this test really needed? Are there versions of this board with
pre-Rev. B silicon?
I would guess no. I have to check with the board provider.
+#if defined (CONFIG_CMD_IDE) defined (CONFIG_IDE_RESET)
+
+void init_ide_reset (void)
+{
+debug (init_ide_reset\n);
+}
+
+void ide_set_reset (int idereset)
+{
+debug (ide_reset(%d)\n, idereset);
+}
+#endif /* defined (CONFIG_SYS_CMD_IDE) defined (CONFIG_IDE_RESET) */
This is just dead code. Please get rid of it.
+#ifdef CONFIG_VIDEO
+#define DISPLAY_WIDTH 800
+#define DISPLAY_HEIGHT 600
This should go to the board config file.
OK.
+#define CONFIG_SYS_LIME_SRST(CONFIG_SYS_LIME_BASE + 0x01FC002C)
+#define CONFIG_SYS_LIME_CCF (CONFIG_SYS_LIME_BASE + 0x01FC0038)
+#define CONFIG_SYS_LIME_MMR (CONFIG_SYS_LIME_BASE + 0x01FCFFFC)
+/* Lime clock frequency */
+#define CONFIG_SYS_LIME_CLK 0x9 /* geo 166MHz other 133MHz */
+/* SDRAM parameter */
+#define CONFIG_SYS_LIME_MMR_VALUE 0x41c767e3
Please do not use base register plus offset. Use a proper C struct to
describe the device registers.
I think this should be done for the mb862xx video driver first, which
does still use base register plus offset. But it would be nice if the
mb862xx video driver would make the register access functions public,
which could then be used here.
+#define CONFIG_SYS_LIME_CID (CONFIG_SYS_LIME_BASE + 0x01FC00F0)
+#define CONFIG_SYS_LIME_REV (CONFIG_SYS_LIME_BASE + 0x01FF8084)
Ditto.
+int lime_probe (void)
+{
+uint reg;
+
+/* Try to access GDC ID/Revision registers */
+reg = in_be32 ((void *)CONFIG_SYS_LIME_CID);
+reg = in_be32 ((void *)CONFIG_SYS_LIME_CID);
+if (reg == 0x303) {
+reg = in_be32 ((void *)CONFIG_SYS_LIME_REV);
+reg = in_be32 ((void *)CONFIG_SYS_LIME_REV);
+reg = ((reg ~0xff) == 0x20050100) ? 1 : 0;
Please see above - using a proper C struct we can get rid of these
casts.
+#if defined(CONFIG_CONSOLE_EXTRA_INFO)
+/*
+ * Return text to be printed besides the logo.
+ */
+void video_get_info_str (int line_number, char *info)
+{
+ if (line_number == 1) {
+ strcpy (info, Board: IPEK01);
+ } else {
+
Re: [U-Boot] [PATCH 3/3] mpc52xx: add support for the IPEK01 board
Dear Wolfgang Grandegger, In message 4adc6cc3.6040...@grandegger.com you wrote: +#ifndef CONFIG_SYS_RAMBOOT Is RAM-Boot actually a asupported mode of operation on this board, or are you just copuy pasting dead code here? If it's really dead code I'm going to prepare and send a patch removing it for all boards. Would that be fine? I don't think it's dead code on all boards; there are RAMBOOT targts in the Makefile for some bords (for example digsy_mtc). I just didn't notice that your board is using this anywhere. 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 My play was a complete success. The audience was a failure. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/4] ppc4xx: Add function to check and dynamically change PCI sync clock
PPC440EP(x)/PPC440GR(x):
In asynchronous PCI mode, the synchronous PCI clock must meet
certain requirements. The following equation describes the
relationship that must be maintained between the asynchronous PCI
clock and synchronous PCI clock. Select an appropriate PCI:PLB
ratio to maintain the relationship:
AsyncPCIClk - 1MHz = SyncPCIclock = (2 * AsyncPCIClk) - 1MHz
This patch now adds a function to check and reconfigure the sync
PCI clock to meet this requirement. This is in preparation for
some AMCC boards (Sequoia/Rainier and Yosemite/Yellowstone) using this
function to not violate the PCI clocking rules.
Signed-off-by: Stefan Roese s...@denx.de
---
cpu/ppc4xx/cpu_init.c | 69 +
include/ppc440.h |7 -
include/ppc4xx.h |2 +
3 files changed, 77 insertions(+), 1 deletions(-)
diff --git a/cpu/ppc4xx/cpu_init.c b/cpu/ppc4xx/cpu_init.c
index a00da40..ccd9993 100644
--- a/cpu/ppc4xx/cpu_init.c
+++ b/cpu/ppc4xx/cpu_init.c
@@ -330,3 +330,72 @@ int cpu_init_r (void)
return 0;
}
+
+#if defined(CONFIG_PCI) \
+ (defined(CONFIG_440EP) || defined(CONFIG_440EPX) || \
+defined(CONFIG_440GR) || defined(CONFIG_440GRX))
+/*
+ * 440EP(x)/GR(x) PCI async/sync clocking restriction:
+ *
+ * In asynchronous PCI mode, the synchronous PCI clock must meet
+ * certain requirements. The following equation describes the
+ * relationship that must be maintained between the asynchronous PCI
+ * clock and synchronous PCI clock. Select an appropriate PCI:PLB
+ * ratio to maintain the relationship:
+ *
+ * AsyncPCIClk - 1MHz = SyncPCIclock = (2 * AsyncPCIClk) - 1MHz
+ */
+static int ppc4xx_pci_sync_clock_ok(u32 sync, u32 async)
+{
+ if (((async - 100) sync) || (sync ((2 * async) - 100)))
+ return 0;
+ else
+ return 1;
+}
+
+int ppc4xx_pci_sync_clock_config(u32 async)
+{
+ sys_info_t sys_info;
+ u32 sync;
+ int div;
+ u32 reg;
+ u32 spcid_val[] = {
+ CPR0_SPCID_SPCIDV0_DIV1, CPR0_SPCID_SPCIDV0_DIV2,
+ CPR0_SPCID_SPCIDV0_DIV3, CPR0_SPCID_SPCIDV0_DIV4 };
+
+ get_sys_info(sys_info);
+ sync = sys_info.freqPCI;
+
+ /*
+* First check if the equation above is met
+*/
+ if (!ppc4xx_pci_sync_clock_ok(sync, async)) {
+ /*
+* Reconfigure PCI sync clock to meet the equation.
+* Start with highest possible PCI sync frequency
+* (divider 1).
+*/
+ for (div = 1; div = 4; div++) {
+ sync = sys_info.freqPLB / div;
+ if (ppc4xx_pci_sync_clock_ok(sync, async))
+ break;
+ }
+
+ if (div = 4) {
+ mtcpr(CPR0_SPCID, spcid_val[div]);
+
+ mfcpr(CPR0_ICFG, reg);
+ reg |= CPR0_ICFG_RLI_MASK;
+ mtcpr(CPR0_ICFG, reg);
+
+ /* do chip reset */
+ mtspr(SPRN_DBCR0, 0x2000);
+ } else {
+ /* Impossible to configure the PCI sync clock */
+ return -1;
+ }
+ }
+
+ return 0;
+}
+#endif
diff --git a/include/ppc440.h b/include/ppc440.h
index fe0db93..e54a977 100644
--- a/include/ppc440.h
+++ b/include/ppc440.h
@@ -1701,9 +1701,14 @@
#define PLLSYS1_NTO1_MASK 0x0001 /* CPU:PLB N-to-1 ratio */
#endif /* CONFIG_440GX */
-#if defined (CONFIG_440EPX) || defined (CONFIG_440GRX)
+#if defined(CONFIG_440EP) || defined(CONFIG_440GR) || \
+defined(CONFIG_440EPX) || defined(CONFIG_440GRX)
#define CPR0_ICFG_RLI_MASK 0x8000
#define CPR0_SPCID_SPCIDV0_MASK0x0300
+#define CPR0_SPCID_SPCIDV0_DIV10x0100
+#define CPR0_SPCID_SPCIDV0_DIV20x0200
+#define CPR0_SPCID_SPCIDV0_DIV30x0300
+#define CPR0_SPCID_SPCIDV0_DIV40x
#define CPR0_PERD_PERDV0_MASK 0x0700
#endif
diff --git a/include/ppc4xx.h b/include/ppc4xx.h
index 3bff00a..5024db4 100644
--- a/include/ppc4xx.h
+++ b/include/ppc4xx.h
@@ -221,6 +221,8 @@ static inline void set_mcsr(u32 val)
asm volatile(mtspr 0x23c, %0 : =r (val) :);
}
+int ppc4xx_pci_sync_clock_config(u32 async);
+
#endif /* __ASSEMBLY__ */
/* for multi-cpu support */
--
1.6.5.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/4] ppc4xx: Print PCI synchronous clock frequency upon bootup
Some 4xx variants (e.g. 440EP(x)/GR(x)) have an internal synchronous PCI clock. Knowledge about the currently configured value might be helpful. So let's print it out upon bootup. Signed-off-by: Stefan Roese s...@denx.de --- cpu/ppc4xx/cpu.c |9 - 1 files changed, 8 insertions(+), 1 deletions(-) diff --git a/cpu/ppc4xx/cpu.c b/cpu/ppc4xx/cpu.c index a9a0ac3..e1b00a7 100644 --- a/cpu/ppc4xx/cpu.c +++ b/cpu/ppc4xx/cpu.c @@ -608,10 +608,17 @@ int checkcpu (void) break; } - printf ( at %s MHz (PLB=%lu, OPB=%lu, EBC=%lu MHz)\n, strmhz(buf, clock), + printf ( at %s MHz (PLB=%lu OPB=%lu EBC=%lu, + strmhz(buf, clock), sys_info.freqPLB / 100, get_OPB_freq() / 100, sys_info.freqEBC / 100); +#if defined(CONFIG_PCI) \ + (defined(CONFIG_440EP) || defined(CONFIG_440EPX) || \ +defined(CONFIG_440GR) || defined(CONFIG_440GRX)) + printf( PCI=%lu MHz, sys_info.freqPCI / 100); +#endif + printf()\n); if (addstr[0] != 0) printf( %s\n, addstr); -- 1.6.5.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/4] ppc4xx: Sequoia/Rainer: Check and reconfigure the PCI sync clock
This patch now uses the 440EP(x)/GR(x) function to check and dynamically
reconfigure the PCI sync clock.
Signed-off-by: Stefan Roese s...@denx.de
---
board/amcc/sequoia/sequoia.c | 26 +++---
1 files changed, 23 insertions(+), 3 deletions(-)
diff --git a/board/amcc/sequoia/sequoia.c b/board/amcc/sequoia/sequoia.c
index d42c802..00f6408 100644
--- a/board/amcc/sequoia/sequoia.c
+++ b/board/amcc/sequoia/sequoia.c
@@ -40,6 +40,15 @@ extern flash_info_t flash_info[CONFIG_SYS_MAX_FLASH_BANKS];
/* info for FLASH ch
extern void __ft_board_setup(void *blob, bd_t *bd);
ulong flash_get_size(ulong base, int banknum);
+static inline u32 get_async_pci_freq(void)
+{
+ if (in_8((void *)(CONFIG_SYS_BCSR_BASE + 5))
+ CONFIG_SYS_BCSR5_PCI66EN)
+ return ;
+ else
+ return ;
+}
+
int board_early_init_f(void)
{
u32 sdr0_cust0;
@@ -76,6 +85,9 @@ int board_early_init_f(void)
mtdcr(UIC2VR, 0x); /* int31 highest, base=0x000 */
mtdcr(UIC2SR, 0x); /* clear all */
+ /* Check and reconfigure the PCI sync clock if necessary */
+ ppc4xx_pci_sync_clock_config(get_async_pci_freq());
+
/* 50MHz tmrclk */
out_8((u8 *) CONFIG_SYS_BCSR_BASE + 0x04, 0x00);
@@ -319,7 +331,7 @@ int checkboard(void)
{
char *s = getenv(serial#);
u8 rev;
- u8 val;
+ u32 clock = get_async_pci_freq();
#ifdef CONFIG_440EPX
printf(Board: Sequoia - AMCC PPC440EPx Evaluation Board);
@@ -328,8 +340,7 @@ int checkboard(void)
#endif
rev = in_8((void *)(CONFIG_SYS_BCSR_BASE + 0));
- val = in_8((void *)(CONFIG_SYS_BCSR_BASE + 5))
CONFIG_SYS_BCSR5_PCI66EN;
- printf(, Rev. %X, PCI=%d MHz, rev, val ? 66 : 33);
+ printf(, Rev. %X, PCI-Async=%d MHz, rev, clock / 100);
if (s != NULL) {
puts(, serial# );
@@ -337,6 +348,15 @@ int checkboard(void)
}
putc('\n');
+ /*
+* Reconfiguration of the PCI sync clock is already done,
+* now check again if everything is in range:
+*/
+ if (ppc4xx_pci_sync_clock_config(clock)) {
+ printf(ERROR: PCI clocking incorrect (async=%d
+ sync=%ld)!\n, clock, get_PCI_freq());
+ }
+
return (0);
}
--
1.6.5.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/4] ppc4xx: Yosemite/Yellowstone: Check and reconfigure the PCI sync clock
This patch now uses the 440EP(x)/GR(x) function to check and dynamically
reconfigure the PCI sync clock.
Signed-off-by: Stefan Roese s...@denx.de
---
board/amcc/yosemite/yosemite.c | 26 +++---
1 files changed, 23 insertions(+), 3 deletions(-)
diff --git a/board/amcc/yosemite/yosemite.c b/board/amcc/yosemite/yosemite.c
index 7ceccfa..ccbeb0e 100644
--- a/board/amcc/yosemite/yosemite.c
+++ b/board/amcc/yosemite/yosemite.c
@@ -33,6 +33,15 @@ DECLARE_GLOBAL_DATA_PTR;
extern flash_info_t flash_info[CONFIG_SYS_MAX_FLASH_BANKS]; /* info for FLASH
chips*/
+static inline u32 get_async_pci_freq(void)
+{
+ if (in_8((void *)(CONFIG_SYS_BCSR_BASE + 5))
+ CONFIG_SYS_BCSR5_PCI66EN)
+ return ;
+ else
+ return ;
+}
+
int board_early_init_f(void)
{
register uint reg;
@@ -106,6 +115,9 @@ int board_early_init_f(void)
mtsdr(SDR0_PFC0, 0x3e00); /* Pin function */
mtsdr(SDR0_PFC1, 0x00048000); /* Pin function: UART0 has 4 pins */
+ /* Check and reconfigure the PCI sync clock if necessary */
+ ppc4xx_pci_sync_clock_config(get_async_pci_freq());
+
/*clear tmrclk divisor */
*(unsigned char *)(CONFIG_SYS_BCSR_BASE | 0x04) = 0x00;
@@ -178,7 +190,7 @@ int checkboard(void)
{
char *s = getenv(serial#);
u8 rev;
- u8 val;
+ u32 clock = get_async_pci_freq();
#ifdef CONFIG_440EP
printf(Board: Yosemite - AMCC PPC440EP Evaluation Board);
@@ -187,8 +199,7 @@ int checkboard(void)
#endif
rev = in_8((void *)(CONFIG_SYS_BCSR_BASE + 0));
- val = in_8((void *)(CONFIG_SYS_BCSR_BASE + 5))
CONFIG_SYS_BCSR5_PCI66EN;
- printf(, Rev. %X, PCI=%d MHz, rev, val ? 66 : 33);
+ printf(, Rev. %X, PCI-Async=%d MHz, rev, clock / 100);
if (s != NULL) {
puts(, serial# );
@@ -196,6 +207,15 @@ int checkboard(void)
}
putc('\n');
+ /*
+* Reconfiguration of the PCI sync clock is already done,
+* now check again if everything is in range:
+*/
+ if (ppc4xx_pci_sync_clock_config(clock)) {
+ printf(ERROR: PCI clocking incorrect (async=%d
+ sync=%ld)!\n, clock, get_PCI_freq());
+ }
+
return (0);
}
--
1.6.5.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ppc4xx: Sequoia: Add chip_config command
This patch removes the Sequoia bootstrap command and replaces it
with the now common command chip_config.
Please note that the patches with the dynamic PCI sync clock
configuration have to be applied, before this one should go in.
This is because Sequoia has 2 different bootstrap EEPROMs, and
the old bootstrap command configured different values depending
on the detected PCI async clock (33 vs. 66MHz). With the PCI sync
clock patches, this is not necessary anymore. The PCI sync clock
will be configured correctly on-the-fly now.
Signed-off-by: Stefan Roese s...@denx.de
---
board/amcc/sequoia/Makefile |4 +-
board/amcc/sequoia/chip_config.c | 122
board/amcc/sequoia/cmd_sequoia.c | 231 --
include/configs/sequoia.h|6 +
4 files changed, 131 insertions(+), 232 deletions(-)
create mode 100644 board/amcc/sequoia/chip_config.c
delete mode 100644 board/amcc/sequoia/cmd_sequoia.c
diff --git a/board/amcc/sequoia/Makefile b/board/amcc/sequoia/Makefile
index a5d5010..8da3bd5 100644
--- a/board/amcc/sequoia/Makefile
+++ b/board/amcc/sequoia/Makefile
@@ -25,9 +25,11 @@ include $(TOPDIR)/config.mk
LIB= $(obj)lib$(BOARD).a
-COBJS = $(BOARD).o cmd_sequoia.o sdram.o
+COBJS-y= $(BOARD).o sdram.o
+COBJS-$(CONFIG_CMD_CHIP_CONFIG) += chip_config.o
SOBJS = init.o
+COBJS := $(COBJS-y)
SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
OBJS := $(addprefix $(obj),$(COBJS))
SOBJS := $(addprefix $(obj),$(SOBJS))
diff --git a/board/amcc/sequoia/chip_config.c b/board/amcc/sequoia/chip_config.c
new file mode 100644
index 000..036de9f
--- /dev/null
+++ b/board/amcc/sequoia/chip_config.c
@@ -0,0 +1,122 @@
+/*
+ * (C) Copyright 2009
+ * Stefan Roese, DENX Software Engineering, s...@denx.de.
+ *
+ * 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/ppc4xx_config.h
+
+struct ppc4xx_config ppc4xx_config_val[] = {
+ {
+ 333-133-nor, NOR CPU: 333 PLB: 133 OPB: 66 EBC: 66,
+ {
+ 0x84, 0x70, 0xa2, 0xa6, 0x05, 0x57, 0xa0, 0x10,
+ 0x40, 0x08, 0x23, 0x50, 0x0d, 0x05, 0x00, 0x00
+ }
+ },
+ {
+ 333-166-nor, NOR CPU: 333 PLB: 166 OPB: 83 EBC: 55,
+ {
+ 0xc7, 0x78, 0xf3, 0x4e, 0x05, 0xd7, 0xa0, 0x30,
+ 0x40, 0x08, 0x23, 0x50, 0x0d, 0x05, 0x00, 0x00
+ }
+ },
+ {
+ 333-166-nand, NAND CPU: 333 PLB: 166 OPB: 83 EBC: 55,
+ {
+ 0xc7, 0x78, 0xf3, 0x4e, 0x05, 0xd7, 0xd0, 0x30,
+ 0xa0, 0x68, 0x23, 0x58, 0x0d, 0x05, 0x00, 0x00
+ }
+ },
+ {
+ 400-133-nor, NOR CPU: 400 PLB: 133 OPB: 66 EBC: 66,
+ {
+ 0x86, 0x78, 0xc2, 0xc6, 0x05, 0x57, 0xa0, 0x30,
+ 0x40, 0x08, 0x23, 0x50, 0x0d, 0x05, 0x00, 0x00
+ }
+ },
+ {
+ 400-160-nor, NOR CPU: 400 PLB: 160 OPB: 80 EBC: 53,
+ {
+ 0x86, 0x78, 0xc2, 0xa6, 0x05, 0xd7, 0xa0, 0x10,
+ 0x40, 0x08, 0x23, 0x50, 0x0d, 0x05, 0x00, 0x00
+ }
+ },
+ {
+ 416-166-nor, NOR CPU: 416 PLB: 166 OPB: 83 EBC: 55,
+ {
+ 0xc6, 0x78, 0x52, 0xa6, 0x05, 0xd7, 0xa0, 0x10,
+ 0x40, 0x08, 0x23, 0x50, 0x0d, 0x05, 0x00, 0x00
+ }
+ },
+ {
+ 416-166-nand, NAND CPU: 416 PLB: 166 OPB: 83 EBC: 55,
+ {
+ 0xc6, 0x78, 0x52, 0xa6, 0x05, 0xd7, 0xd0, 0x10,
+ 0xa0, 0x68, 0x23, 0x58, 0x0d, 0x05, 0x00, 0x00
+ }
+ },
+ {
+ 500-166-nor, NOR CPU: 500 PLB: 166 OPB: 83 EBC: 55,
+ {
+ 0xc7, 0x78, 0x52, 0xc6, 0x05, 0xd7, 0xa0, 0x30,
+ 0x40, 0x08, 0x23, 0x50, 0x0d, 0x05, 0x00, 0x00
+ }
+ },
+ {
+ 500-166-nand, NAND CPU: 500 PLB: 166 OPB: 83 EBC: 55,
+ {
+
Re: [U-Boot] ARM pull request v3
Tom wrote: This is what has changed since v2 10,12c10,12 CPU9260 : fix machine ID when using a CPU9G20. fix CPU9260/CPU9G20 compile warnings main.c: In function 'abortboot': --- AT91 CPU9260 Fix machine ID when using a CPU9G20. AT91 CPU9260 CPU9G20 Fix compile warnings AT91 CPUAT91 Fix compiler warning 45,46c45 Steve Sakoman (2): TI: OMAP3: Refactors the SM911x driver --- Steve Sakoman (1): 117d115 drivers/net/smc911x.c | 12 +- 161c159 This comes from rebasing the arm master-sync branch ... I removed the sm911x patch. After this is discussed now, could we apply it again? Without this patch it will be broken. Thanks Dirk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/5 v2] OMAP3: Fix SDRC init
On Tue, Oct 6, 2009 at 7:17 PM, Nishanth Menon n...@ti.com wrote:
Defaults are for Infineon DDR timings.
Since none of the supported boards currently do
XIP boot, these seem to be faulty. fix the values
as per the calculations(ACTIMA,B), conf
the sdrc power with pwdnen and wakeupproc bits
Signed-off-by: Nishanth Menon n...@ti.com
Cc: David B davi...@pacbell.net
Cc: Vikram Pandita vikram.pand...@ti.com
Cc: Richard Woodruff r-woodru...@ti.com
Cc: Sandeep Paulraj s-paul...@ti.com
Cc: Tom Rix tom@windriver.com
Cc: Dirk Behme dirk.be...@googlemail.com
---
cpu/arm_cortexa8/omap3/mem.c | 3 ++-
include/asm-arm/arch-omap3/cpu.h | 1 +
include/asm-arm/arch-omap3/mem.h | 8
3 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/cpu/arm_cortexa8/omap3/mem.c b/cpu/arm_cortexa8/omap3/mem.c
index 079c848..8731c9d 100644
--- a/cpu/arm_cortexa8/omap3/mem.c
+++ b/cpu/arm_cortexa8/omap3/mem.c
@@ -164,7 +164,8 @@ void do_sdrc_init(u32 cs, u32 early)
writel(SDP_SDRC_SHARING, sdrc_base-sharing);
/* Disable Power Down of CKE cuz of 1 CKE on combo part */
- writel(SRFRONRESET | PAGEPOLICY_HIGH, sdrc_base-power);
+ writel(WAKEUPPROC | PWDNEN | SRFRONRESET | PAGEPOLICY_HIGH,
+ sdrc_base-power);
writel(ENADLL | DLLPHASE_90, sdrc_base-dlla_ctrl);
sdelay(0x2);
diff --git a/include/asm-arm/arch-omap3/cpu.h
b/include/asm-arm/arch-omap3/cpu.h
index 8ab2e39..e51c4f3 100644
--- a/include/asm-arm/arch-omap3/cpu.h
+++ b/include/asm-arm/arch-omap3/cpu.h
@@ -222,6 +222,7 @@ struct sdrc {
#define PAGEPOLICY_HIGH (0x1 0)
#define SRFRONRESET (0x1 7)
+#define PWDNEN (0x1 2)
#define WAKEUPPROC (0x1 26)
#define DDR_SDRAM (0x1 0)
diff --git a/include/asm-arm/arch-omap3/mem.h
b/include/asm-arm/arch-omap3/mem.h
index 5b9ac75..31cbdef 100644
--- a/include/asm-arm/arch-omap3/mem.h
+++ b/include/asm-arm/arch-omap3/mem.h
@@ -78,16 +78,16 @@ enum {
#define TRP_165 3
#define TRAS_165 7
#define TRC_165 10
-#define TRFC_165 21
+#define TRFC_165 12
#define V_ACTIMA_165 ((TRFC_165 27) | (TRC_165 22) | \
(TRAS_165 18) | (TRP_165 15) | \
(TRCD_165 12) | (TRRD_165 9) | \
(TDPL_165 6) | (TDAL_165))
#define TWTR_165 1
-#define TCKE_165 1
-#define TXP_165 5
-#define XSR_165 23
+#define TCKE_165 2
+#define TXP_165 2
+#define XSR_165 20
#define V_ACTIMB_165 (((TCKE_165 12) | (XSR_165 0)) | \
(TXP_165 8) | (TWTR_165 16))
--
1.6.0.4
I see issues after applying this patch (Overo/Beagle).
In about half of my boot attempts I get a hang after Uncompressing Linux
In the other half I get many many errors of this type:
SLAB: cache with size 192 has lost its name
Reverting the patch restores normal operation.
So it seems that the Infineon timings do not work on systems with Micron memory.
Steve
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/5 v2] OMAP3: Fix SDRC init
Steve Sakoman wrote:
On Tue, Oct 6, 2009 at 7:17 PM, Nishanth Menon n...@ti.com wrote:
Defaults are for Infineon DDR timings.
Since none of the supported boards currently do
XIP boot, these seem to be faulty. fix the values
as per the calculations(ACTIMA,B), conf
the sdrc power with pwdnen and wakeupproc bits
Signed-off-by: Nishanth Menon n...@ti.com
Cc: David B davi...@pacbell.net
Cc: Vikram Pandita vikram.pand...@ti.com
Cc: Richard Woodruff r-woodru...@ti.com
Cc: Sandeep Paulraj s-paul...@ti.com
Cc: Tom Rix tom@windriver.com
Cc: Dirk Behme dirk.be...@googlemail.com
---
cpu/arm_cortexa8/omap3/mem.c |3 ++-
include/asm-arm/arch-omap3/cpu.h |1 +
include/asm-arm/arch-omap3/mem.h |8
3 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/cpu/arm_cortexa8/omap3/mem.c b/cpu/arm_cortexa8/omap3/mem.c
index 079c848..8731c9d 100644
--- a/cpu/arm_cortexa8/omap3/mem.c
+++ b/cpu/arm_cortexa8/omap3/mem.c
@@ -164,7 +164,8 @@ void do_sdrc_init(u32 cs, u32 early)
writel(SDP_SDRC_SHARING, sdrc_base-sharing);
/* Disable Power Down of CKE cuz of 1 CKE on combo part */
- writel(SRFRONRESET | PAGEPOLICY_HIGH, sdrc_base-power);
+ writel(WAKEUPPROC | PWDNEN | SRFRONRESET | PAGEPOLICY_HIGH,
+ sdrc_base-power);
writel(ENADLL | DLLPHASE_90, sdrc_base-dlla_ctrl);
sdelay(0x2);
diff --git a/include/asm-arm/arch-omap3/cpu.h
b/include/asm-arm/arch-omap3/cpu.h
index 8ab2e39..e51c4f3 100644
--- a/include/asm-arm/arch-omap3/cpu.h
+++ b/include/asm-arm/arch-omap3/cpu.h
@@ -222,6 +222,7 @@ struct sdrc {
#define PAGEPOLICY_HIGH(0x1 0)
#define SRFRONRESET(0x1 7)
+#define PWDNEN (0x1 2)
#define WAKEUPPROC (0x1 26)
#define DDR_SDRAM (0x1 0)
diff --git a/include/asm-arm/arch-omap3/mem.h
b/include/asm-arm/arch-omap3/mem.h
index 5b9ac75..31cbdef 100644
--- a/include/asm-arm/arch-omap3/mem.h
+++ b/include/asm-arm/arch-omap3/mem.h
@@ -78,16 +78,16 @@ enum {
#define TRP_1653
#define TRAS_165 7
#define TRC_16510
-#define TRFC_165 21
+#define TRFC_165 12
#define V_ACTIMA_165 ((TRFC_165 27) | (TRC_165 22) | \
(TRAS_165 18) | (TRP_165 15) | \
(TRCD_165 12) | (TRRD_165 9) | \
(TDPL_165 6) | (TDAL_165))
#define TWTR_165 1
-#define TCKE_165 1
-#define TXP_1655
-#define XSR_16523
+#define TCKE_165 2
+#define TXP_1652
+#define XSR_16520
#define V_ACTIMB_165 (((TCKE_165 12) | (XSR_165 0)) | \
(TXP_165 8) | (TWTR_165 16))
--
1.6.0.4
I see issues after applying this patch (Overo/Beagle).
In about half of my boot attempts I get a hang after Uncompressing Linux
In the other half I get many many errors of this type:
SLAB: cache with size 192 has lost its name
Reverting the patch restores normal operation.
What's about removing it from recent ARM pull request than and do some
further testing?
Thanks for testing
Dirk
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1 1/2] NET: Move MDIO regs out of TSEC Space
diff --git a/include/asm-ppc/immap_85xx.h b/include/asm-ppc/
immap_85xx.h index 4194295..6c9baac 100644
--- a/include/asm-ppc/immap_85xx.h
+++ b/include/asm-ppc/immap_85xx.h
@@ -1932,4 +1932,14 @@ typedef struct ccsr_gur { #define
CONFIG_SYS_MPC85xx_USB_ADDR \
(CONFIG_SYS_IMMR + CONFIG_SYS_MPC85xx_USB_OFFSET)
+/* TSEC and MDIO OFFSETS */
+#define CONFIG_SYS_TSEC1_OFFSET(0x24000)
+#define TSEC_SIZE (0x01000)
+
+#define CONFIG_SYS_MDIO1_OFFSET(0x24520)
+#define MDIO_OFFSET(0x01000)
+
+#define TSEC_BASE_ADDR (CONFIG_SYS_IMMR +
CONFIG_SYS_TSEC1_OFFSET)
+#define MDIO_BASE_ADDR (CONFIG_SYS_IMMR +
CONFIG_SYS_MDIO1_OFFSET)
+
Do we even need these here? We haven't historically.
Since these are platform dependent, we want the above to be defined
here.
than we should remove them from tsec.h
#endif /*__IMMAP_85xx__*/
diff --git a/include/tsec.h b/include/tsec.h index 0ac3034..342c07e
100644
--- a/include/tsec.h
+++ b/include/tsec.h
@@ -7,7 +7,7 @@
* terms of the GNU Public License, Version 2, incorporated
* herein by reference.
*
- * Copyright 2004, 2007 Freescale Semiconductor, Inc.
+ * Copyright 2004, 2007, 2009 Freescale Semiconductor, Inc.
* (C) Copyright 2003, Motorola, Inc.
* maintained by Xianghua Xiao (x.x...@motorola.com)
* author Andy Fleming
@@ -24,18 +24,34 @@
#define CONFIG_SYS_TSEC1_OFFSET (0x24000)
#endif
-#define TSEC_SIZE 0x01000
+#ifndef TSEC_SIZE
+ #define TSEC_SIZE 0x01000
+#endif
Do we really need a #ifndef here?
Yes. In case it is not defined in immap_85xx, wefall back to the older
options.
This duplication is pointless. When is TSEC_SIZE anything about 0x1000?
+
+#ifndef CONFIG_SYS_MDIO1_OFFSET
+#define CONFIG_SYS_MDIO1_OFFSET(0x24520)
+#endif
The only time this will change is between TSEC2 and TSEC1. Nothing
else has caused this to change.
the parens aren't needed.
OK.
+
+#ifndef MDIO_OFFSET
+ #define MDIO_OFFSET 0x01000
+#endif
How about calling this TSEC_MDIO_OFFSET
OK, I will change it (I just carried forward the existing #define
variable )
/* FIXME: Should these be pushed back to 83xx and 85xx
config files?
*/ #if defined(CONFIG_MPC85xx) || defined(CONFIG_MPC86xx) \
|| defined(CONFIG_MPC83xx)
+#ifndef TSEC_BASE_ADDR
#define TSEC_BASE_ADDR (CONFIG_SYS_IMMR +
CONFIG_SYS_TSEC1_OFFSET)
#endif
+#ifndef MDIO_BASE_ADDR
+#define MDIO_BASE_ADDR (CONFIG_SYS_IMMR +
CONFIG_SYS_MDIO1_OFFSET)
+#endif
+#endif
Do we really need the #ifndef's here?
The correct place for defining the MDIO and TSEC base addr is the
platformm file as they are
dependent on the platform not on the IP itself ( although in most
cases
for a particular version of IP,
this may not change) and since these were earlier defined here, I have
defined these as a part of immap_85xx.h
But for all other platforms they are not defined yet, hence #ifndefs
are
required.
Once these base addrs are moved to platform specific files,they can be
removed complatelly form here.
I'm ok if you want to move them out of tsec.h into immap_85xx.h,
imap_83xx.h, and imap_86xx.h
- k
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/5 v2] OMAP3: Fix SDRC init
On Mon, Oct 19, 2009 at 7:55 AM, Dirk Behme dirk.be...@googlemail.com wrote:
Steve Sakoman wrote:
On Tue, Oct 6, 2009 at 7:17 PM, Nishanth Menon n...@ti.com wrote:
Defaults are for Infineon DDR timings.
Since none of the supported boards currently do
XIP boot, these seem to be faulty. fix the values
as per the calculations(ACTIMA,B), conf
the sdrc power with pwdnen and wakeupproc bits
Signed-off-by: Nishanth Menon n...@ti.com
Cc: David B davi...@pacbell.net
Cc: Vikram Pandita vikram.pand...@ti.com
Cc: Richard Woodruff r-woodru...@ti.com
Cc: Sandeep Paulraj s-paul...@ti.com
Cc: Tom Rix tom@windriver.com
Cc: Dirk Behme dirk.be...@googlemail.com
---
cpu/arm_cortexa8/omap3/mem.c | 3 ++-
include/asm-arm/arch-omap3/cpu.h | 1 +
include/asm-arm/arch-omap3/mem.h | 8
3 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/cpu/arm_cortexa8/omap3/mem.c b/cpu/arm_cortexa8/omap3/mem.c
index 079c848..8731c9d 100644
--- a/cpu/arm_cortexa8/omap3/mem.c
+++ b/cpu/arm_cortexa8/omap3/mem.c
@@ -164,7 +164,8 @@ void do_sdrc_init(u32 cs, u32 early)
writel(SDP_SDRC_SHARING, sdrc_base-sharing);
/* Disable Power Down of CKE cuz of 1 CKE on combo part */
- writel(SRFRONRESET | PAGEPOLICY_HIGH, sdrc_base-power);
+ writel(WAKEUPPROC | PWDNEN | SRFRONRESET |
PAGEPOLICY_HIGH,
+ sdrc_base-power);
writel(ENADLL | DLLPHASE_90, sdrc_base-dlla_ctrl);
sdelay(0x2);
diff --git a/include/asm-arm/arch-omap3/cpu.h
b/include/asm-arm/arch-omap3/cpu.h
index 8ab2e39..e51c4f3 100644
--- a/include/asm-arm/arch-omap3/cpu.h
+++ b/include/asm-arm/arch-omap3/cpu.h
@@ -222,6 +222,7 @@ struct sdrc {
#define PAGEPOLICY_HIGH (0x1 0)
#define SRFRONRESET (0x1 7)
+#define PWDNEN (0x1 2)
#define WAKEUPPROC (0x1 26)
#define DDR_SDRAM (0x1 0)
diff --git a/include/asm-arm/arch-omap3/mem.h
b/include/asm-arm/arch-omap3/mem.h
index 5b9ac75..31cbdef 100644
--- a/include/asm-arm/arch-omap3/mem.h
+++ b/include/asm-arm/arch-omap3/mem.h
@@ -78,16 +78,16 @@ enum {
#define TRP_165 3
#define TRAS_165 7
#define TRC_165 10
-#define TRFC_165 21
+#define TRFC_165 12
#define V_ACTIMA_165 ((TRFC_165 27) | (TRC_165 22) | \
(TRAS_165 18) | (TRP_165 15) | \
(TRCD_165 12) | (TRRD_165 9) | \
(TDPL_165 6) | (TDAL_165))
#define TWTR_165 1
-#define TCKE_165 1
-#define TXP_165 5
-#define XSR_165 23
+#define TCKE_165 2
+#define TXP_165 2
+#define XSR_165 20
#define V_ACTIMB_165 (((TCKE_165 12) | (XSR_165 0)) | \
(TXP_165 8) | (TWTR_165 16))
--
1.6.0.4
I see issues after applying this patch (Overo/Beagle).
In about half of my boot attempts I get a hang after Uncompressing
Linux
In the other half I get many many errors of this type:
SLAB: cache with size 192 has lost its name
Reverting the patch restores normal operation.
What's about removing it from recent ARM pull request than and do some
further testing?
That sounds like a good plan to me.
Steve
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] trouble with u-boot and bist fail on pcie adapter
On Mon, Oct 19, 2009 at 09:35:54AM +0200, Wolfgang Denk wrote: Did you try setting the pciscandelay variable? Try setting it to 5 (or 10) [seconds]. See also snip Thanks Wolfgang, Per your suggestion, we tried setting the delay (and observed a delay), but the outcome did not change. The BIST still got set to fail and caused the board to become unresponsive, and thus Linux fails the detection later. FWIW, we've tried both with and without switches in between with no change in the behavior. We observe the transactions on a lecroy pcie analyzer. I suppose one question that lingers in my mind is why does u-boot do anything other than just configure the IO/MEM bars? Is there some specific reason it is touching the BIST controls? If I could understand the reason for this, I might be able to do some debug and at least determine whether I need to change u-boot, Linux, or both. Thanks so much, Ayman ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] qemu_mips: Fix CONFIG_NET_MULTI build warning
Hi Shinya, Shinya Kuribayashi wrote: eth.c:497:2: warning: #warning Ethernet driver is deprecated. Please update to use CONFIG_NET_MULTI Signed-off-by: Shinya Kuribayashi skuri...@pobox.com --- I have a few concerns about this fix: First. I'm not sure why CONFIG_NET_MULTI is undefed for qemu_mips, while CONFIG_DRIVER_NE2000 has been enabled for qemu_mips at an early stage. I don't follow recent changes around eth.c and CONFIG_NET_MULTI, but it's probably CONFIG_NET_MULTI used to be used strictly for multi ports, isn't it? Currently, there are two incompatible networking APIs. One that uses CONFIG_NET_MULTI, and one that doesn't. I'm trying to move everything towards the former (single-port applications are of course a degenerate instance of multi-port ones). Once all drivers have been ported to the MULTI API, that config option will magically disappear. Next. As far as looking at drivers/net/ne2000*.[ch], NE2000 driver doesn't seem to require board_eth_init() or cpu_eth_init(). Right? Therefore I've not added a corresponding hook in board/qemu_mips/ qemu_mips.c. If my understanding is wrong, please let me know. The NE2000 driver hasn't been ported yet. It's on my short term to-do list, and will be in the next release (01.2010, I guess?) include/configs/qemu-mips.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/configs/qemu-mips.h b/include/configs/qemu-mips.h index cbacdf9..f419174 100644 --- a/include/configs/qemu-mips.h +++ b/include/configs/qemu-mips.h @@ -157,7 +157,7 @@ #define CONFIG_ENV_OVERWRITE 1 -#undef CONFIG_NET_MULTI +#define CONFIG_NET_MULTI This won't do anything other than disabling networking. Since QEMU is an emulator, though, maybe it would make sense to use a device driver that has CONFIG_NET_MULTI support? #define MEM_SIZE 128 If the warning isn't more than a nuisance, please live with it for now. regards, Ben ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Root-Filesystem ober NFS doesn't work... -- Kernel panic
Hi! I'm trying to get root-filesystem over NFS running. I'm a bit confused about all the new stuff and I don't know where I shall start searching for the problem :-( I have: Board: Artila M501 board with AT91RM9200 U-Boot: 1.1.2 Linux: 2.6 Flash: 16MB SDRAM: 64MB My U-Boot configuration is: *** START *** baudrate=115200 ethaddr=00:13:48:00:77:b5 rootpath=/opt/arm lel=1 initrd=0x2080,8192000 ramdisk_size=15360 root=/dev/ram0 rw loader=tftp 2100 m501_64M.alf mtdparts=phys_mapped_flash:128k(loader)ro,128k(reserved)ro,1408k(linux)ro,2560(ramdisk)ro,-(userdisk) filesize=3A3 netmask=255.255.255.0 bootcmd=bootm 1004 101a kernel=tftp 2100 M501K;erase 1004 1019;cp.b 2100 1004 $(filesize) skernel=loadb 2100;erase 1004 1019;cp.b 2100 1004 $(filesize) ramdisk=tftp 2100 M501R;erase 101a 1041;cp.b 2100 101a $(filesize) sramdisk=loadb 2100;erase 101a 1041;cp.b 2100 101a $(filesize) ipaddr=192.168.2.196 bootdelay=1 bargs=setenv bootargs mem=64M console=$(console),115200 initrd=0x2080,8192000 ramdisk_size=15360 root=/dev/ram0 rw mtdparts=phys_mapped_flash:128k(loader)ro,128k(env)ro,1408k(linux)ro,2560k(ramdisk)ro,-(userdisk) serverip=192.168.2.40 console=ttyS0 gateway=192.168.2.1 bootargs=root=/dev/nfs rw nfsroot=192.168.2.40:/opt/arm ip=192.168.2.196:192.168.2.40:192.168.2.254:255.255.255.0:michael-laptop::off console=ttyS0,115200 bootm=1004 - 101a stdin=serial stdout=serial stderr=serial *** END *** If I start my Board, the kernel boots and it looks fine until I get a kernel panic -- See the attached textfile! Do you have any hints what the problems might be. I'm pretty sure that the NFS-Server works fine, but I'm not sure 100% (How can I find out if it works? Any Idea?). Thanks! Michael -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 Uncompressing Linux... done, booting the kernel. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Root-Filesystem ober NFS doesn't work... -- Kernel panic --- corrupt textfile
I'm sorry, somehow the log.txt in my last e-mail got corrupted Here it is: Uncompressing Linux... done, booting the kernel. Linux version 2.6.14-M5 (a...@ace-yang) (gcc version 3.3.2) #837 Tue Aug 14 14:14:03 CST 2007 CPU: ARM920Tid(wb) [41129200] revision 0 (ARMv4T) Machine: Artila M501 SOM Memory policy: ECC disabled, Data cache writeback Clocks: CPU 179 MHz, master 59 MHz, main 18.432 MHz CPU0: D VIVT write-back cache CPU0: I cache: 16384 bytes, associativity 64, 32 byte lines, 8 sets CPU0: D cache: 16384 bytes, associativity 64, 32 byte lines, 8 sets Built 1 zonelists Kernel command line: root=/dev/nfs rw nfsroot=192.168.2.40:/opt/arm ip=192.168.2.196:192.168.2.40:192.168.2.254:255.255.255.0:michael-laptop::off console=ttyS0,115200 AT91: 128 gpio irqs in 4 banks PID hash table entries: 256 (order: 8, 4096 bytes) Console: colour dummy device 80x30 Dentry cache hash table entries: 8192 (order: 3, 32768 bytes) Inode-cache hash table entries: 4096 (order: 2, 16384 bytes) Memory: 32MB = 32MB total Memory: 26824KB available (2389K code, 523K data, 104K init) Mount-cache hash table entries: 512 CPU: Testing write buffer coherency: ok checking if image is initramfs...it isn't (no cpio magic); looks like an initrd Freeing initrd memory: 2509K NET: Registered protocol family 16 SCSI subsystem initialized usbcore: registered new driver usbfs usbcore: registered new driver hub NetWinder Floating Point Emulator V0.97 (extended precision) JFFS2 version 2.2. (NAND) (C) 2001-2003 Red Hat, Inc. Initializing Cryptographic API Matrix500 RTC driver. Matrix500 GPIO Driver Loaded. AT91 SPI driver loaded AT91 Watchdog Timer enabled (5 seconds) ttyS0 at MMIO 0xfefff200 (irq = 1) is a AT91_SERIAL ttyS1 at MMIO 0xfefc (irq = 6) is a AT91_SERIAL ttyS2 at MMIO 0xfefc4000 (irq = 7) is a AT91_SERIAL ttyS3 at MMIO 0xfefc8000 (irq = 8) is a AT91_SERIAL ttyS4 at MMIO 0xfefcc000 (irq = 9) is a AT91_SERIAL io scheduler noop registered io scheduler anticipatory registered RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize PPP generic driver version 2.4.2 PPP BSD Compression module registered NET: Registered protocol family 24 eth0: Link now 100-FullDuplex eth0: AT91 ethernet at 0xfefbc000 int=24 100-FullDuplex (00:13:48:00:77:b5) eth0: Davicom 9161AE PHY (Copper) physmap flash device: 100 at 1000 phys_mapped_flash: Found 1 x16 devices at 0x0 in 16-bit bank Intel/Sharp Extended Query Table at 0x010A Using buffer write method cfi_cmdset_0001: Erase suspend on write enabled RedBoot partition parsing not available block2mtd: version $Revision: 1.28 $ at91rm9200-ohci at91rm9200-ohci: AT91RM9200 OHCI at91rm9200-ohci at91rm9200-ohci: new USB bus registered, assigned bus number 1 at91rm9200-ohci at91rm9200-ohci: irq 23, io mem 0x0030 usb usb1: Product: AT91RM9200 OHCI usb usb1: Manufacturer: Linux 2.6.14-M5 ohci_hcd usb usb1: SerialNumber: at91rm9200 hub 1-0:1.0: USB hub found hub 1-0:1.0: 2 ports detected usbcore: registered new driver cdc_acm drivers/usb/class/cdc-acm.c: v0.23:USB Abstract Control Model driver for USB modems and ISDN adapters usbcore: registered new driver usblp drivers/usb/class/usblp.c: v0.13: USB Printer Device Class driver Initializing USB Mass Storage driver... usbcore: registered new driver usb-storage USB Mass Storage support registered. rtusb init usbcore: registered new driver rt73 usbcore: registered new driver usbserial drivers/usb/serial/usb-serial.c: USB Serial support registered for Generic usbcore: registered new driver usbserial_generic drivers/usb/serial/usb-serial.c: USB Serial Driver core v2.0 drivers/usb/serial/usb-serial.c: USB Serial support registered for FTDI USB Serial Device usbcore: registered new driver ftdi_sio drivers/usb/serial/ftdi_sio.c: v1.4.3:USB FTDI Serial Converters Driver drivers/usb/serial/usb-serial.c: USB Serial support registered for PL-2303 usbcore: registered new driver pl2303 drivers/usb/serial/pl2303.c: Prolific PL2303 USB to serial adaptor driver v0.12 mice: PS/2 mouse device common for all mice i2c /dev entries driver Found AT91 i2c RTC found. AT91RM9200 MCI initialized NET: Registered protocol family 2 IP route cache hash table entries: 512 (order: -1, 2048 bytes) TCP established hash table entries: 2048 (order: 1, 8192 bytes) TCP bind hash table entries: 2048 (order: 1, 8192 bytes) TCP: Hash tables configured (established 2048 bind 2048) TCP reno registered ip_conntrack version 2.3 (256 buckets, 2048 max) - 240 bytes per conntrack ctnetlink v0.90: registering with nfnetlink. ip_tables: (C) 2000-2002 Netfilter core team ipt_recent v0.3.1: Stephen Frost sfr...@snowman.net. http://snowman.net/projects/ipt_recent/ arp_tables: (C) 2002 David S. Miller TCP bic registered Netfilter messages via NETLINK v0.30. NET: Registered protocol
Re: [U-Boot] Root-Filesystem ober NFS doesn't work... -- Kernel panic
Dear Michael Schmid, In message 20091019165934.319...@gmx.net you wrote: I'm trying to get root-filesystem over NFS running. I'm a bit confused about all the new stuff and I don't know where I shall start searching for the problem :-( I have: Board: Artila M501 board with AT91RM9200 U-Boot: 1.1.2 more than 4.5 years old! Linux: 2.6 2.6.14 according to your log = 4 years old ... bootcmd=bootm 1004 101a This setting means you are trying to boot with a ramdisk. If you want to boot with root file system over NFS, you MUST NOT pass a ramdiska ddress, i. e. you must not use two arguments to the bootm command. bootargs=root=/dev/nfs rw nfsroot=192.168.2.40:/opt/arm ip=192.168.2.196:192.168.2.40:192.168.2.254:255.255.255.0:michael-laptop::off console=ttyS0,115200 I don't think you want to assign the host name michael-laptop to your target board (but this is no really critical at this moment yet). bootm=1004 - 101a This setting is completely bogus. It has no meaning. Delete it. Linux version 2.6.14-M5 (a...@ace-yang) (gcc version 3.3.2) #837 Tue Aug 14 14:14:03 CST 2007 CPU: ARM920Tid(wb) [41129200] revision 0 (ARMv4T) Machine: Artila M501 SOM ... RAMDISK: Compressed image found at block 0 VFS: Mounted root (ext2 filesystem). Here you can see that the kernel mounts the ramdisk image which you provided. VFS: Cannot open root device nfs or unknown-block(0,255) Please append a correct root= boot option Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,255) ...and then it gets confused. Do you have any hints what the problems might be. I'm pretty sure that the NFS-Server works fine, but I'm not sure 100% (How can I find out if it works? Any Idea?). Well, just mount the root file system from another host? 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 An armed society is a polite society. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Nand: Implement raw read/write and biterr
On Wed, Sep 30, 2009 at 02:22:09PM -0500, Tom wrote: John Rigby wrote: @@ -494,13 +600,16 @@ U_BOOT_CMD(nand, CONFIG_SYS_MAXARGS, 1, do_nand, nand write - addr off|partition size\n read/write 'size' bytes starting at offset 'off'\n to/from memory address 'addr', skipping bad blocks.\n + .oob - reads/writes oob only.\n + .raw - reads/writes both main and oob with no error\n +detection or correction\n Writing the oob area directly is UNSAFE. Having done to myself, it was a pain to undo. You should put at least document that. If we warn about oob being unsafe, the same warning should be made for raw. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Pull request - net
Wolfgang, Please pull the net branch (master). This includes a patch that was somehow lost back in April. It's pretty low-risk. The following changes since commit f67066b6b0740b826ed862615c5ab022aaf4779a: Mike Frysinger (1): envcrc: check return value of fwrite() are available in the git repository at: git://git.denx.de/u-boot-net.git master Daniel Mack (1): smc911x: add support for LAN9220 drivers/net/smc911x.h |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) regards, Ben ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please check if the patch for SMSC LAN9220 is missing
Seunghyeon, Seunghyeon Rhee (이승현) wrote: There were two patches submitted to add support for SMSC LAN9220 and LAN9221. The latter (more recent one) has been applied but the former hasn't yet. Refer to the following and check please. Regards, Seunghyeon Rhee Nice catch! I honestly don't know what happened here. I've applied the LAN9220 patch (updated) to the net repo. regards, Ben ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] [OneNAND IPL] OneNAND board init support
On Wed, Oct 07, 2009 at 12:12:16PM +0900, Kyungmin Park wrote: Sorry, there's typo. Here's fixed patch. Please resend the amended patch, complete with changelog, without trailing quoted material, so that I can just apply one e-mail. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] Don't let the command-line ARCH=powerpc override our redefinition to ppc.
The override keyword is needed for make to take our version over the one specified on the command line, and remove it from the list of command line overrides that are passed to submakes. IMHO, the combination of export and override ought to do this automatically, but oh well. Signed-off-by: Scott Wood scottw...@freescale.com --- Makefile |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/Makefile b/Makefile index bed9469..f9e7a50 100644 --- a/Makefile +++ b/Makefile @@ -134,7 +134,8 @@ unexport CDPATH # ifeq ($(ARCH),powerpc) -ARCH = ppc +override ARCH = ppc +MAKEOVERRIDES := $(MAKEOVERRIDES:ARCH%=) endif # The tools are needed early, so put this first -- 1.6.4.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] tools: Use override when changing CC, CFLAGS, etc.
If the user has specified a CC or similar on the command line, that is the cross compiler, not the host compiler. Override is needed to keep these assignments from being ignored in that case. Signed-off-by: Scott Wood scottw...@freescale.com --- tools/Makefile | 10 +- tools/gdb/Makefile |6 +++--- 2 files changed, 8 insertions(+), 8 deletions(-) diff --git a/tools/Makefile b/tools/Makefile index 2a9a9fd..6bf3fde 100644 --- a/tools/Makefile +++ b/tools/Makefile @@ -139,21 +139,21 @@ LIBFDT_OBJS := $(addprefix $(obj),$(LIBFDT_OBJ_FILES-y)) # Use native tools and options # Define __KERNEL_STRICT_NAMES to prevent typedef overlaps # -CPPFLAGS = -idirafter $(SRCTREE)/include \ +override CPPFLAGS = -idirafter $(SRCTREE)/include \ -idirafter $(OBJTREE)/include2 \ -idirafter $(OBJTREE)/include \ -I $(SRCTREE)/libfdt \ -I $(SRCTREE)/tools \ -DTEXT_BASE=$(TEXT_BASE) -DUSE_HOSTCC \ -D__KERNEL_STRICT_NAMES -CFLAGS = $(HOSTCFLAGS) $(CPPFLAGS) -O +override CFLAGS = $(HOSTCFLAGS) $(CPPFLAGS) -O # No -pedantic switch to avoid libfdt compilation warnings FIT_CFLAGS = -Wall $(CPPFLAGS) -O -AFLAGS= -D__ASSEMBLY__ $(CPPFLAGS) -CC= $(HOSTCC) -STRIP = $(HOSTSTRIP) +override AFLAGS = -D__ASSEMBLY__ $(CPPFLAGS) +override CC = $(HOSTCC) +override STRIP = $(HOSTSTRIP) MAKEDEPEND = makedepend all: $(obj).depend $(BINS) $(LOGO-y) subdirs diff --git a/tools/gdb/Makefile b/tools/gdb/Makefile index 0a5687d..dca97f4 100644 --- a/tools/gdb/Makefile +++ b/tools/gdb/Makefile @@ -37,9 +37,9 @@ BINS := $(addprefix $(obj),$(BINS)) # # Use native tools and options # -CPPFLAGS = -I$(BFD_ROOT_DIR)/include -CFLAGS = $(HOSTCFLAGS) -O $(CPPFLAGS) -CC= $(HOSTCC) +override CPPFLAGS = -I$(BFD_ROOT_DIR)/include +override CFLAGS = $(HOSTCFLAGS) -O $(CPPFLAGS) +override CC = $(HOSTCC) MAKEDEPEND = makedepend HOSTOS := $(shell uname -s | sed -e 's/\([Cc][Yy][Gg][Ww][Ii][Nn]\).*/cygwin/') -- 1.6.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] cmd_nand: Remove duplicate include
On Thu, Oct 15, 2009 at 10:48:17AM -0500, Peter Tyser wrote: Also remove vague, unnecessary comment Signed-off-by: Peter Tyser pty...@xes-inc.com Applied both patches to u-boot-nand-flash/next -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] DM9000 issue in DM355
Ben, I was taking a closer look at the DM9000 driver by trying it on the DM355 EVM. And it behaving a little different from before, i.e before we moved to the NET_MULTI stuff. When the board comes after I reflash with a new U-boot image, I no longer see the ethaddr being set. But when I do a tftp I can see the ethaddr being read. tftp complains and says no ethaddr set. So then I goto the U-Boot prompt and can clearly see that after giving the tftp command I have the ethaddr in my environment. I do a saveenv and set a static ip and then can boot the kernel. Even dhcp command does not work and times out. Is there any CONFIG flag I am missing? Just a couple months ago the DM9000 worked fine without any such issues. Thanks, Sandeep ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2 v4] env: only build env_embedded and envcrc when needed
On Monday 19 October 2009 05:31:36 Wolfgang Denk wrote: Mike Frysinger wrote: diff --git a/board/tqc/tqm8xx/u-boot.lds b/board/tqc/tqm8xx/u-boot.lds index 2df8d84..8207b2c 100644 --- a/board/tqc/tqm8xx/u-boot.lds +++ b/board/tqc/tqm8xx/u-boot.lds @@ -21,6 +21,8 @@ * MA 02111-1307 USA */ +#include config.h + OUTPUT_ARCH(powerpc) /* Do we need any of these for elf? __DYNAMIC = 0;*/ @@ -64,8 +66,10 @@ SECTIONS lib_generic/zlib.o (.text) lib_ppc/cache.o(.text) +#ifdef CONFIG_ENV_IS_EMBEDDED . = DEFINED(env_offset) ? env_offset : .; common/env_embedded.o (.ppcenv) +#endif All TQM8xx boards use a hand-optimized linker script that places the envrionment (both the primary and the redundant copies) into the small boot sectors of the bottom boot block type NOR flash used on these boards (and the same is true for other boards as well; I know this for sure at least for IVM*, km8xx, purple, spc1920, stxxtc, trab). However, none of these #defines CONFIG_ENV_IS_EMBEDDED in their board config files. if none of them have defined CONFIG_ENV_IS_EMBEDDED, then this code never would have expanded to anything. if you look at the actual env_embedded.c code, it is completely wrapped in #ifdef CONFIG_ENV_IS_EMBEDDED ... #endif thus env_offset would not be defined nor would env_embedded.o contain anything thus nothing would be injected thus nothing should be changed thus my proposed change should be fine -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] tools: Use override when changing CC, CFLAGS, etc.
On Monday 19 October 2009 17:24:35 Scott Wood wrote: If the user has specified a CC or similar on the command line, that is the cross compiler, not the host compiler. Override is needed to keep these assignments from being ignored in that case. then again, if we didnt mix host and target variable names, this wouldnt be a problem. in a sane world, all of the host stuff would be HOSTXX (or BUILDXX). -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] tools: Use override when changing CC, CFLAGS, etc.
Mike Frysinger wrote: On Monday 19 October 2009 17:24:35 Scott Wood wrote: If the user has specified a CC or similar on the command line, that is the cross compiler, not the host compiler. Override is needed to keep these assignments from being ignored in that case. then again, if we didnt mix host and target variable names, this wouldnt be a problem. in a sane world, all of the host stuff would be HOSTXX (or BUILDXX). Right... I initially tried substituting in HOSTCC, but it still tried to use CC, probably from an implicit rule that would need to be made explicit in order to use HOSTCC. I can try to respin it with a new explicit rule if y'all want. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Possible NAND environment issue which i see on DM355 and DM365
Hello, I see an issue while trying to save the environment on both the DM355 and DM365. Here is the dump DM365 EVM # saveenv Saving Environment to NAND... Erasing Nand... Erasing at 0x3e0004 -- 0% complete. Writing to Nand... done DM365 EVM # If we look at the line, Erasing at 0x3e0004 -- 0% complete., The diagnostics are clearly wrong. It should be Erasing at 0x3e -- 100% complete. I think this is an issue with the 64 bit support that is getting added to U-Boot. As usual I am willing to get corrected on what I just said. The image is built of u-boot-ti and since I am in sync with arm , I don't believe I would have seen any NAND and environment related patches/updates over the last month or so. Any commits/patches that is in u-boot that will result in me not seeing such issues? I ask because I did not see this issues a couple months ago and the NAND driver is the same so I assume that the issue is with some other subsystem. I must reiterate that both the DM355 and DM365 boot up a linux kernel just fine. Thanks, Sandeep ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] Don't let the command-line ARCH=powerpc override our redefinition to ppc.
Dear Scott Wood, In message 20091019212409.ga31...@loki.buserror.net you wrote: The override keyword is needed for make to take our version over the one specified on the command line, and remove it from the list of command line overrides that are passed to submakes. IMHO, the combination of export and override ought to do this automatically, but oh well. I have to admit that I don't see the problem. When I explicitly ask for a specific ARCH setting on the command line (versus using some setting I inherited from the envrionment, eventually even unaware of the current value), then I do want to use that. So the current code seems to do what I would expect from it. Maybe my expectations are whacky, though. I tend to NAK this one. 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 I was playing poker the other night... with Tarot cards. I got a full house and 4 people died. - Steven Wright ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] tools: Use override when changing CC, CFLAGS, etc.
Dear Scott Wood, In message 20091019212435.ga31...@loki.buserror.net you wrote: If the user has specified a CC or similar on the command line, that is the cross compiler, not the host compiler. Override is needed to keep these assignments from being ignored in that case. Signed-off-by: Scott Wood scottw...@freescale.com --- tools/Makefile | 10 +- tools/gdb/Makefile |6 +++--- 2 files changed, 8 insertions(+), 8 deletions(-) As Mike pointed out, we should rather consistently use HOSTCC when we refer to the host's C compiler. I suggest you rework the patch to do that. Thanks. 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 Swap read error. You lose your mind. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] tools: Use override when cha nging CC, CFLAGS , etc.
On Monday 19 October 2009 17:56:37 Scott Wood wrote: Mike Frysinger wrote: On Monday 19 October 2009 17:24:35 Scott Wood wrote: If the user has specified a CC or similar on the command line, that is the cross compiler, not the host compiler. Override is needed to keep these assignments from being ignored in that case. then again, if we didnt mix host and target variable names, this wouldnt be a problem. in a sane world, all of the host stuff would be HOSTXX (or BUILDXX). Right... I initially tried substituting in HOSTCC, but it still tried to use CC, probably from an implicit rule that would need to be made explicit in order to use HOSTCC. I can try to respin it with a new explicit rule if y'all want. if you feel like cleaning up all the host code, that'd be great, but i'm not going to NACK a patch that obviously fixes broken code ;) -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add mpc5125ads board and processor to the mpc512x family
Regarding 512x psc register maps: The register map for 5125 does not just change the size of the registers. Some registers change locations. The issue is that the hardware guys decided to fix the old broken register access. The 5200, 5121, 5123 had some registers that were: Function A when read but function B when written. For this case the old register is replaced by two read/write registers. So the index of all subsequent registers is incremented. Function A on first access after writing to another register and Function B on subsequent accesses. This was also fixed by replacing the statefull register by two registers. So the problem is painful but I believe doable. The problem I never resolved was dealing with this mess in linux where the same binary has to work with both platforms. I decided that the register accesses needed to be done via an offsets array that was populated at run time but I never got around to implementing that. John + * MPC5121 PSC + * note: MPC5121e register overloading is handled by unions with #defines to + * reference the reg seemlessly these #defines must not exist for MPC5125 code + * since it does not have this overloading. Since the register naming is the + * same as the MPC5125 Reference Manual and this naming is exactly the reg names + * used in the init code (which is nearly identical) it causes compile errors to + * leave in and must be #ifdef'ed out. It also helps to share code to have the + * same structure for both MPC5121 and MPC5125 */ I disagree. To me the code becomes pretty much unreadable. I think we need to find a better implementation for this. Look Wolfgang ... It's very readable .. with a 5121 type You definition of readable does not match mine. I nak this code. 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 There is a time in the tides of men, Which, taken at its flood, leads on to success. On the other hand, don't count on it. - T. K. Lawson ___ 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 1/2] Don't let the command-line ARCH=powerpc override our redefinition to ppc.
Wolfgang Denk wrote: Dear Scott Wood, In message 20091019212409.ga31...@loki.buserror.net you wrote: The override keyword is needed for make to take our version over the one specified on the command line, and remove it from the list of command line overrides that are passed to submakes. IMHO, the combination of export and override ought to do this automatically, but oh well. I have to admit that I don't see the problem. When I explicitly ask for a specific ARCH setting on the command line (versus using some setting I inherited from the envrionment, eventually even unaware of the current value), then I do want to use that. So the current code seems to do what I would expect from it. Maybe my expectations are whacky, though. I tend to NAK this one. For the benefit of those who weren't on the IRC channel when we discussed this, I'll restate my objection. I think you're reading too much into the difference between setting ARCH with an environment variable and setting it on the command line. The number of users who are going to be confused by this (at least one, since I was) is greater than the number of users who would have done something useful by truly forcing ARCH=powerpc (zero without other changes, since all it gets you is a failed build). The way it is now, it looks as if ARCH=powerpc is accepted as an alias for ARCH=ppc. If this is not intended to be the case, and it's only intended to be accepted as an alias if you use one specific method of passing arguments (which again I recommend against, as it's confusing and not actually useful), then can we at least add a comment to the part of the makefile that does the rewriting clarifying this? Printing a warning if ARCH is still powerpc probably wouldn't hurt either, even in the absence of any rewriting. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Freescale MXC: NAND UnCorrectable RS-ECC Error
Hi Magnus, Thanks. Are you using U-boot v2 or some other customized U-boot? (gitweb at git.denx.de seems to have some problems at the moment and I don't have the U-boot v2 tree locally) Custom u-boot based on v2. I have ported mxc_nand based on the kernel code(2.6.26) and it uses 2k/4k specific changes and the correct settings for RCSR register based on the page size. -Alfred ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] qemu_mips: Fix CONFIG_NET_MULTI build warning
Hi Ben, Ben Warren wrote: Shinya Kuribayashi wrote: First. I'm not sure why CONFIG_NET_MULTI is undefed for qemu_mips, while CONFIG_DRIVER_NE2000 has been enabled for qemu_mips at an early stage. I don't follow recent changes around eth.c and CONFIG_NET_MULTI, but it's probably CONFIG_NET_MULTI used to be used strictly for multi ports, isn't it? Currently, there are two incompatible networking APIs. One that uses CONFIG_NET_MULTI, and one that doesn't. I'm trying to move everything towards the former (single-port applications are of course a degenerate instance of multi-port ones). Once all drivers have been ported to the MULTI API, that config option will magically disappear. Thanks, got it. Next. As far as looking at drivers/net/ne2000*.[ch], NE2000 driver doesn't seem to require board_eth_init() or cpu_eth_init(). Right? Therefore I've not added a corresponding hook in board/qemu_mips/ qemu_mips.c. If my understanding is wrong, please let me know. The NE2000 driver hasn't been ported yet. It's on my short term to-do list, and will be in the next release (01.2010, I guess?) So CONFIG_NE2000_DRIVER needs some work, and is not ready for migration. I missed that point, thanks for clarification. @@ -157,7 +157,7 @@ #define CONFIG_ENV_OVERWRITE1 -#undef CONFIG_NET_MULTI +#define CONFIG_NET_MULTI This won't do anything other than disabling networking. Since QEMU is an emulator, though, maybe it would make sense to use a device driver that has CONFIG_NET_MULTI support? Who knows? It's hard, at least for me, to say. But it'd be better to port NE2000 driver into an appropriate shape whether it's used by QEMU or not. #define MEM_SIZE128 If the warning isn't more than a nuisance, please live with it for now. No problem. Please ignore the patch. Thanks, Shinya ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] OMAP3 DDR Fix patches (was Re: [PATCH 1/5 v2] OMAP3: Fix SDRC init)
Steve Sakoman had written, on 10/19/2009 10:06 AM, the following:
On Mon, Oct 19, 2009 at 7:55 AM, Dirk Behme dirk.be...@googlemail.com wrote:
Steve Sakoman wrote:
On Tue, Oct 6, 2009 at 7:17 PM, Nishanth Menon n...@ti.com wrote:
Defaults are for Infineon DDR timings.
Since none of the supported boards currently do
XIP boot, these seem to be faulty. fix the values
as per the calculations(ACTIMA,B), conf
the sdrc power with pwdnen and wakeupproc bits
Signed-off-by: Nishanth Menon n...@ti.com
Cc: David B davi...@pacbell.net
Cc: Vikram Pandita vikram.pand...@ti.com
Cc: Richard Woodruff r-woodru...@ti.com
Cc: Sandeep Paulraj s-paul...@ti.com
Cc: Tom Rix tom@windriver.com
Cc: Dirk Behme dirk.be...@googlemail.com
---
cpu/arm_cortexa8/omap3/mem.c |3 ++-
include/asm-arm/arch-omap3/cpu.h |1 +
include/asm-arm/arch-omap3/mem.h |8
3 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/cpu/arm_cortexa8/omap3/mem.c b/cpu/arm_cortexa8/omap3/mem.c
index 079c848..8731c9d 100644
--- a/cpu/arm_cortexa8/omap3/mem.c
+++ b/cpu/arm_cortexa8/omap3/mem.c
@@ -164,7 +164,8 @@ void do_sdrc_init(u32 cs, u32 early)
writel(SDP_SDRC_SHARING, sdrc_base-sharing);
/* Disable Power Down of CKE cuz of 1 CKE on combo part */
- writel(SRFRONRESET | PAGEPOLICY_HIGH, sdrc_base-power);
+ writel(WAKEUPPROC | PWDNEN | SRFRONRESET |
PAGEPOLICY_HIGH,
+ sdrc_base-power);
writel(ENADLL | DLLPHASE_90, sdrc_base-dlla_ctrl);
sdelay(0x2);
diff --git a/include/asm-arm/arch-omap3/cpu.h
b/include/asm-arm/arch-omap3/cpu.h
index 8ab2e39..e51c4f3 100644
--- a/include/asm-arm/arch-omap3/cpu.h
+++ b/include/asm-arm/arch-omap3/cpu.h
@@ -222,6 +222,7 @@ struct sdrc {
#define PAGEPOLICY_HIGH(0x1 0)
#define SRFRONRESET(0x1 7)
+#define PWDNEN (0x1 2)
#define WAKEUPPROC (0x1 26)
#define DDR_SDRAM (0x1 0)
diff --git a/include/asm-arm/arch-omap3/mem.h
b/include/asm-arm/arch-omap3/mem.h
index 5b9ac75..31cbdef 100644
--- a/include/asm-arm/arch-omap3/mem.h
+++ b/include/asm-arm/arch-omap3/mem.h
@@ -78,16 +78,16 @@ enum {
#define TRP_1653
#define TRAS_165 7
#define TRC_16510
-#define TRFC_165 21
+#define TRFC_165 12
#define V_ACTIMA_165 ((TRFC_165 27) | (TRC_165 22) | \
(TRAS_165 18) | (TRP_165 15) | \
(TRCD_165 12) | (TRRD_165 9) | \
(TDPL_165 6) | (TDAL_165))
#define TWTR_165 1
-#define TCKE_165 1
-#define TXP_1655
-#define XSR_16523
+#define TCKE_165 2
+#define TXP_1652
+#define XSR_16520
#define V_ACTIMB_165 (((TCKE_165 12) | (XSR_165 0)) | \
(TXP_165 8) | (TWTR_165 16))
--
1.6.0.4
I see issues after applying this patch (Overo/Beagle).
In about half of my boot attempts I get a hang after Uncompressing
Linux
In the other half I get many many errors of this type:
SLAB: cache with size 192 has lost its name
Reverting the patch restores normal operation.
What's about removing it from recent ARM pull request than and do some
further testing?
That sounds like a good plan to me.
Original patch was send on 6th Oct. sad that we will need to break
complete SDP3430 boot support.. How about fixing it properly once for
all- looks like a previous commit hacked the timings meant for INFINEON
DDR with MICRON values for few of them causing this mess. attached is a
patchset to fix it.
Tested on SDP3430, buildtested for others - Steve do try it on your
platform to confirm. more testing invited..
--
Regards,
Nishanth Menon
From 3b8f52c22ae81deab45c0a6ea18dda834daefc95 Mon Sep 17 00:00:00 2001
From: Nishanth Menon n...@ti.com
Date: Mon, 19 Oct 2009 20:31:36 -0500
Subject: [PATCH 1/2] OMAP3:SDRC: Cleanup references to SDP
Remove SDP referenced unused defines
Signed-off-by: Nishanth Menon n...@ti.com
---
cpu/arm_cortexa8/omap3/mem.c |2 +-
cpu/arm_cortexa8/omap3/sys_info.c |2 +-
include/asm-arm/arch-omap3/mem.h | 11 ++-
3 files changed, 4 insertions(+), 11 deletions(-)
diff --git a/cpu/arm_cortexa8/omap3/mem.c b/cpu/arm_cortexa8/omap3/mem.c
index 5e6d542..dfb7e4c 100644
--- a/cpu/arm_cortexa8/omap3/mem.c
+++ b/cpu/arm_cortexa8/omap3/mem.c
@@ -161,7 +161,7 @@ void do_sdrc_init(u32 cs, u32 early)
writel(0, sdrc_base-sysconfig);
/* setup sdrc to ball mux */
- writel(SDP_SDRC_SHARING, sdrc_base-sharing);
+ writel(SDRC_SHARING, sdrc_base-sharing);
/* Disable Power Down of CKE cuz of 1 CKE on combo part */
writel(WAKEUPPROC | PWDNEN | SRFRONRESET | PAGEPOLICY_HIGH,
diff --git a/cpu/arm_cortexa8/omap3/sys_info.c b/cpu/arm_cortexa8/omap3/sys_info.c
index 31b2003..08fb32e 100644
--- a/cpu/arm_cortexa8/omap3/sys_info.c
+++
[U-Boot] [u-boot] [PATCH] [2/2] [v1.2] mxc_fec: avoid free() calls to already freed pointers.
Sometimes, inside NetLoop, eth_halt() is called before eth_init() has
been called. This is harmless except for free() calls to pointers
which have not been allocated yet. This patch adds two states to
distinguish when it is necessary to call free() and when it is not.
This has been tested in i.MX27 Litekit board and eldk-4.2 toolchains.
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
--
drivers/net/fec_mxc.c |9 +++--
drivers/net/fec_mxc.h | 10 ++
2 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/drivers/net/fec_mxc.c b/drivers/net/fec_mxc.c
index bd83a24..9e9ef99 100644
--- a/drivers/net/fec_mxc.c
+++ b/drivers/net/fec_mxc.c
@@ -55,6 +55,7 @@ struct fec_priv gfec = {
.tbd_base = NULL,
.tbd_index = 0,
.bd= NULL,
+ .status= FEC_HALT_STATUS,
};
/*
@@ -453,6 +454,7 @@ static int fec_init(struct eth_device *dev, bd_t* bd)
miiphy_restart_aneg(dev);
fec_open(dev);
+ fec-status = FEC_INIT_STATUS;
return 0;
}
@@ -491,8 +493,11 @@ static void fec_halt(struct eth_device *dev)
writel(0, fec-eth-ecntrl);
fec-rbd_index = 0;
fec-tbd_index = 0;
- free(fec-rdb_ptr);
- free(fec-base_ptr);
+ if (fec-status == FEC_INIT_STATUS) {
+ free(fec-rdb_ptr);
+ free(fec-base_ptr);
+ }
+ fec-status = FEC_HALT_STATUS;
debug(eth_halt: done\n);
}
diff --git a/drivers/net/fec_mxc.h b/drivers/net/fec_mxc.h
index 6cb1bfc..266b5d3 100644
--- a/drivers/net/fec_mxc.h
+++ b/drivers/net/fec_mxc.h
@@ -245,9 +245,19 @@ struct fec_priv {
bd_t *bd;
void *rdb_ptr;
void *base_ptr;
+ int status; /* whether fec is halted or not* */
};
/**
+ * @brief Possible values for status
+ *
+ * fec_halt() changes the status to FEC_HALT_STATUS and fec_init()
+ * changes the status to FEC_INIT_STATUS
+ */
+#define FEC_HALT_STATUS 0
+#define FEC_INIT_STATUS 1
+
+/**
* @brief Numbers of buffer descriptors for receiving
*
* The number defines the stocked memory buffers for the receiving task.
--
Javier Martin
Vista Silicon S.L.
CDTUC - FASE C - Oficina S-345
Avda de los Castros s/n
39005- Santander. Cantabria. Spain
+34 942 25 32 60
www.vista-silicon.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
