[U-Boot] [PATCH v5] Marvell MV88E61XX Switch Driver support
Chips supported:-
1. 88E6161 6 port gbe swtich with 5 integrated PHYs
2. 88E6165 6 port gbe swtich with 5 integrated PHYs
2. 88E6132 3 port gbe swtich with 2 integrated PHYs
Platform specific configuration supported
default and router port vlan config supported
Note: This driver is supported and tested against
kirkwood egiga interface
Contributors:
Yotam Admon yo...@marvell.com
Michael Blostein michae...@marvell.com
Reviewed by: Ronen Shitrit rshit...@marvell.com
Signed-off-by: Prafulla Wadaskar prafu...@marvell.com
---
Changelog:-
v2: updated as per review comments for v1
removed other two drivers form earlier patch
debug_prints removed
driver moved to drivers/net/
v3: updated as per review comments for v2
miiphy interface used, platform specific dependency resolved
Chip id detection and printing added
common code forked out
some cosmetic and magic number fixes
v4: updated as per review comments for v3
mv88e61xx.h added
platform specific configuration support added
some more documentation references provided
cleaned rgmii delay enable related code
v5: updated as per review comments for v3
code moved to drivers/net/phy/
vlan_init changed to vlan_config and platform specific
drivers/net/phy/Makefile|1 +
drivers/net/phy/mv88e61xx.c | 313 +++
drivers/net/phy/mv88e61xx.h | 73 ++
3 files changed, 387 insertions(+), 0 deletions(-)
create mode 100644 drivers/net/phy/mv88e61xx.c
create mode 100644 drivers/net/phy/mv88e61xx.h
diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
index 4fe3b05..3b92614 100644
--- a/drivers/net/phy/Makefile
+++ b/drivers/net/phy/Makefile
@@ -26,6 +26,7 @@ include $(TOPDIR)/config.mk
LIB:= $(obj)libphy.a
COBJS-$(CONFIG_BITBANGMII) += miiphybb.o
+COBJS-$(CONFIG_MV88E61XX_SWITCH) += mv88e61xx.o
COBJS := $(COBJS-y)
SRCS := $(COBJS:.o=.c)
diff --git a/drivers/net/phy/mv88e61xx.c b/drivers/net/phy/mv88e61xx.c
new file mode 100644
index 000..8ba2291
--- /dev/null
+++ b/drivers/net/phy/mv88e61xx.c
@@ -0,0 +1,313 @@
+/*
+ * (C) Copyright 2009
+ * Marvell Semiconductor www.marvell.com
+ * Prafulla Wadaskar prafu...@marvell.com
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
+ * MA 02110-1301 USA
+ */
+
+#include common.h
+#include miiphy.h
+#include mv88e61xx.h
+
+/* Chip Address mode
+ * The Switch support two modes of operation
+ * 1. single chip mode and
+ * 2. Multi-chip mode
+ * Refer section 9.2 9.3 in chip datasheet-02 for more details
+ *
+ * By default single chip mode is configured
+ * multichip mode operation can be configured in board header
+ */
+#ifndef CONFIG_MV88E61XX_MULTICHIP_ADRMODE
+#define mv88e61xx_wr_phy miiphy_write
+#define mv88e61xx_rd_phy miiphy_read
+#else
+
+static int mv88e61xx_busychk_multic(u32 devaddr)
+{
+ u32 reg = 0;
+ u32 timeout = MV88E61XX_PHY_TIMEOUT;
+
+ /* Poll till SMIBusy bit is clear */
+ do {
+ miiphy_read(name, devaddr, 0x0, reg);
+ if (timeout-- == 0) {
+ printf(SMI busy timeout\n);
+ return -1;
+ }
+ } while (reg BIT15);
+ return 0;
+}
+
+static void mv88e61xx_wr_phy(char *name, u32 phy_adr, u32 reg_ofs, u16 data)
+{
+ u16 reg;
+ u32 mii_dev_addr;
+
+ /* command to read PHY dev address */
+ if (!miiphy_read(name, 0xEE, 0xEE, mii_dev_addr)) {
+ printf(Error..could not read PHY dev address\n);
+ return;
+ }
+ mv88e61xx_busychk_multic(mii_dev_addr);
+ /* Write data to Switch indirect data register */
+ miiphy_write(name, mii_dev_addr, 0x1, data);
+ /* Write command to Switch indirect command register (write) */
+ miiphy_write(name, mii_dev_addr, 0x0,
+reg_ofs | (phy_adr 5) | BIT10 | BIT12 | BIT15);
+}
+
+static void mv88e61xx_rd_phy(char *name, u32 phy_adr, u32 reg_ofs, u16 * data)
+{
+ u16 reg;
+ u32 mii_dev_addr;
+
+ /* command to read PHY dev address */
+ if (!miiphy_read(name, 0xEE, 0xEE, mii_dev_addr)) {
+ printf(Error..could not read PHY dev address\n);
+ return;
+ }
+ mv88e61xx_busychk_multic(mii_dev_addr);
+
Re: [U-Boot] implement usb gadget ethernet in uboot
Hello Mike, Please take a look at the CDC branch in u-boot-usb. Patches to add more boards/devices or other improvements are welcome. feel free to yell at me for not reading some README, but any plans on merging back into mainline ? Of course, but there are still some cleanups pending for which I did not had the time lately. It was not mainline-ready at the time I started to put it there, and I only made it public to help others not reinventing the wheel. Maybe I get into it next week. Kind Regards, Remy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [ANNOUNCE] Kconfig support
On Apr 18, 2009, at 11:25 AM, Jean-Christophe PLAGNIOL-VILLARD wrote: Hi all, I've upload on the u-boot-arm tree in kconfig branch some patch on which I work to all us to use Kconfig It's a dev branch not all patch are perfect but it will be nice if other could help to finish it and help me to create all the Kconfig files Beyond adding Kconfig's what's left to be done? - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [ANNOUNCE] Kconfig support
On Sat, Apr 18, 2009 at 08:54:41PM +0200, Wolfgang Denk wrote: u-boot-v2 is an interesting approach in several aspects, but since it was made publicly visible nearly two years ago it did not collect much of a community around it. Right; part of the reason is it was always something we used to solve our problems, and we didn't do much marketing around it. Nevertheless, it *does* solve our problems very well, and each time we have to work with v1 again it's weaknesses show up again and again. From my (strictly personal) point of view, one show stopper is that there is no migration path - if you want to go u-boot-v2, you have to throw away all what is in mainline. That was one of the design criteria - starting with a clean code base, in order to get rid of all the old ugglyness. And there is a lot of things that are not available in v2. Right; from what we need in our daytime projects, the most important feature which is currently missing is PCI support. There are several others which are surely also important (like i2c) but could be added with very low effort if needed. So it does make perfect sense to me to add features like Kconfig support to mainline. Right; if v2 inspires someone to take the ideas and bring them into v1, it's perfectly fine - in the end, it's one of the reasons we started the whole thing. rsc -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [ANNOUNCE] Kconfig support
On Sat, Apr 18, 2009 at 03:18:32PM -0400, Mike Frysinger wrote: so, does it make sense to look at the feature set that v2 brings to the table and get it into u-boot v1? ive never personally looked at v2, but if it means i need to redo all of my Blackfin core/board code, that doesnt sound very appealing at all ... We have even Blackfin support in v2, and that for almost all of the time it is actually there. Sure - if you need feature completeness, you'll have to stay with v1. Our aim is a sane design, and I'm still not convinced that this is even possible with v1 any more. rsc -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [ANNOUNCE] Kconfig support
On Apr 19, 2009, at 2:48 PM, Robert Schwebel wrote: On Sat, Apr 18, 2009 at 08:54:41PM +0200, Wolfgang Denk wrote: u-boot-v2 is an interesting approach in several aspects, but since it was made publicly visible nearly two years ago it did not collect much of a community around it. Right; part of the reason is it was always something we used to solve our problems, and we didn't do much marketing around it. Nevertheless, it *does* solve our problems very well, and each time we have to work with v1 again it's weaknesses show up again and again. What's the summary of features that v2 has that v1 doesnt? - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [ANNOUNCE] Kconfig support
On Sun, Apr 19, 2009 at 04:59:41PM -0500, Kumar Gala wrote: On Apr 19, 2009, at 2:48 PM, Robert Schwebel wrote: On Sat, Apr 18, 2009 at 08:54:41PM +0200, Wolfgang Denk wrote: u-boot-v2 is an interesting approach in several aspects, but since it was made publicly visible nearly two years ago it did not collect much of a community around it. Right; part of the reason is it was always something we used to solve our problems, and we didn't do much marketing around it. Nevertheless, it *does* solve our problems very well, and each time we have to work with v1 again it's weaknesses show up again and again. What's the summary of features that v2 has that v1 doesnt? - Kconfig support - Linux Build support - Clean device registration and driver matching, so there can always be multiple instances of a device - filesystem support. U-Boot starts by mounting a ramfs on /, populating a devfs under /dev and load the environemt to /env. Use the normal commands like cd, ls, rm, cat,... - mount: there is no mmc_ls and mmc_load and stuff like that. Just mount your device and use ls - The environment is not limited to a variable store, instead it's a ramfs which can store variables, scripts, splashimages or whatever - module support - One image for all storage types. Well, the hardware has to support it, but on i.MX27 the same image can start from RAM, Nor Flash and NAND Flash. - USB Network support - A network phy device layer, so phys are handled in a generic way. Their registers can be showed with md -s /dev/phy0 (and of course changed with mw) - A much simpler clock implementation (Linux clocksource). So basically what an architecture needs to do is to specify the timer resolution and provide a read_timer function which returns the raw timer value. - getopt support, so there is no need for positional arguments - A simple editor to edit scripts - readline usable on the command line to allow for interactive scripts - a sandbox port to run U-Boot on the host including tap ethernet - different bugs to hunt for Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] UART2 Console in u-boot
hi stefan, i made just changed few things in yosemite files and it worked for me. you have mentioned to use UART2 device as stdin/stdout/... in my default environment... where can i mention my default stdin and stdout Thanks Regards, Prathika R Stefan Roese wrote: On Friday 17 April 2009, prathika wrote: i have ported u-boot this way to my board with few changes in the u-boot source code and the board is up and i have tested stand alone application execution also. So you did a real board port to your custom board? Or did you just change the yosemite files? Now as my requirement is that my console should be on UART2 as my UART0 and UART1 are coming out as RS 422 lines and only UART2 is RS232. I did some patch up work on UART0 lines and tested my u-boot porting. Ah, I though you wanted the console on UART1. Ok, then my solution does not work for you. I added a line #define UART2_BASE CFG_PERIPHERAL_BASE + 0x500 I have now changed as below and I commented checking for #define UART0_CONSOLE and #define UART1_CONSOLE: #define UARTBASE UART2_BASE Is this OK?? Best would be to add the 3rd UART (UART2) to the SERIAL_MULTI infrastructure (see end of serial.c) and use this device as stdin/stdout/.. in your default environment. Best regards, Stefan = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5] Marvell MV88E61XX Switch Driver support
Hi Prafulla,
Sorry for dragging this out... you've made a lot of good changes
already, and are almost there.
Prafulla Wadaskar wrote:
Chips supported:-
1. 88E6161 6 port gbe swtich with 5 integrated PHYs
2. 88E6165 6 port gbe swtich with 5 integrated PHYs
2. 88E6132 3 port gbe swtich with 2 integrated PHYs
Platform specific configuration supported
default and router port vlan config supported
Note: This driver is supported and tested against
kirkwood egiga interface
Contributors:
Yotam Admon yo...@marvell.com
Michael Blostein michae...@marvell.com
Reviewed by: Ronen Shitrit rshit...@marvell.com
Signed-off-by: Prafulla Wadaskar prafu...@marvell.com
---
Changelog:-
v2: updated as per review comments for v1
removed other two drivers form earlier patch
debug_prints removed
driver moved to drivers/net/
v3: updated as per review comments for v2
miiphy interface used, platform specific dependency resolved
Chip id detection and printing added
common code forked out
some cosmetic and magic number fixes
v4: updated as per review comments for v3
mv88e61xx.h added
platform specific configuration support added
some more documentation references provided
cleaned rgmii delay enable related code
v5: updated as per review comments for v3
code moved to drivers/net/phy/
vlan_init changed to vlan_config and platform specific
drivers/net/phy/Makefile|1 +
drivers/net/phy/mv88e61xx.c | 313
+++
drivers/net/phy/mv88e61xx.h | 73 ++
3 files changed, 387 insertions(+), 0 deletions(-)
create mode 100644 drivers/net/phy/mv88e61xx.c
create mode 100644 drivers/net/phy/mv88e61xx.h
diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
index 4fe3b05..3b92614 100644
--- a/drivers/net/phy/Makefile
+++ b/drivers/net/phy/Makefile
@@ -26,6 +26,7 @@ include $(TOPDIR)/config.mk
LIB := $(obj)libphy.a
COBJS-$(CONFIG_BITBANGMII) += miiphybb.o
+COBJS-$(CONFIG_MV88E61XX_SWITCH) += mv88e61xx.o
COBJS:= $(COBJS-y)
SRCS := $(COBJS:.o=.c)
diff --git a/drivers/net/phy/mv88e61xx.c b/drivers/net/phy/mv88e61xx.c
new file mode 100644
index 000..8ba2291
--- /dev/null
+++ b/drivers/net/phy/mv88e61xx.c
@@ -0,0 +1,313 @@
+/*
+ * (C) Copyright 2009
+ * Marvell Semiconductor www.marvell.com
+ * Prafulla Wadaskar prafu...@marvell.com
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
+ * MA 02110-1301 USA
+ */
+
+#include common.h
+#include miiphy.h
+#include mv88e61xx.h
+
+/* Chip Address mode
+ * The Switch support two modes of operation
+ * 1. single chip mode and
+ * 2. Multi-chip mode
+ * Refer section 9.2 9.3 in chip datasheet-02 for more details
+ *
+ * By default single chip mode is configured
+ * multichip mode operation can be configured in board header
+ */
+#ifndef CONFIG_MV88E61XX_MULTICHIP_ADRMODE
+#define mv88e61xx_wr_phy miiphy_write
+#define mv88e61xx_rd_phy miiphy_read
+#else
+
+static int mv88e61xx_busychk_multic(u32 devaddr)
+{
I mentioned this previously - if you're going to alias functions please
do it in a header (I see that you have one now).
+ u32 reg = 0;
+ u32 timeout = MV88E61XX_PHY_TIMEOUT;
+
+ /* Poll till SMIBusy bit is clear */
+ do {
+ miiphy_read(name, devaddr, 0x0, reg);
+ if (timeout-- == 0) {
+ printf(SMI busy timeout\n);
+ return -1;
+ }
+ } while (reg BIT15);
+ return 0;
+}
+
+static void mv88e61xx_wr_phy(char *name, u32 phy_adr, u32 reg_ofs, u16 data)
+{
+ u16 reg;
+ u32 mii_dev_addr;
+
+ /* command to read PHY dev address */
+ if (!miiphy_read(name, 0xEE, 0xEE, mii_dev_addr)) {
+ printf(Error..could not read PHY dev address\n);
+ return;
+ }
+ mv88e61xx_busychk_multic(mii_dev_addr);
+ /* Write data to Switch indirect data register */
+ miiphy_write(name, mii_dev_addr, 0x1, data);
+ /* Write command to Switch indirect command register (write) */
+ miiphy_write(name, mii_dev_addr, 0x0,
+ reg_ofs | (phy_adr 5) | BIT10 | BIT12 | BIT15);
+}
+
+static void mv88e61xx_rd_phy(char
Re: [U-Boot] [PATCH v2] Marvell MV88F6281GTW_GE Board support
Hi Prafulla, Prafulla Wadaskar wrote: snip +#define CONFIG_IPADDR 192.168.5.44 +#define CONFIG_SERVERIP192.168.5.30 +#define CONFIG_NETMASK 255.255.255.0 please remove the IP params Why ? Because these values are only relevant to your lab network, not anybody else who's going to use your boards. Boards should start with a clean slate. This is a hard rule that we've been enforcing for a while now - no address or network parameter initializations in config files. regards, Ben ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH u-boot git] DaVinci Ethernet cleanup
Jean-Christophe PLAGNIOL-VILLARD wrote: On 15:49 Sun 12 Apr , David Brownell wrote: From: David Brownell dbrown...@users.sourceforge.net Chips without the EMAC controller won't need the utilities it uses to read an Ethernet address from EEPROM; so don't include them needlessly. Use is_valid_ether() to validate the address from EEPROM. All-zero addresses aren't the only invalid addresses. A fully erased EEPROM returns all-ones, also invalid... Switch those Ethernet utilities to use %pM for printing MAC addresses; and not say ROM when they mean EEPROM. Signed-off-by: David Brownell dbrown...@users.sourceforge.net Acked-by: Ben Warren biggerbadder...@gmail.com Looks fine Ben any comments? Best Regards, J. Please pull this in with the other changes. regards, Ben ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH u-boot git] dm9000 EEPROM reading bugfix
Jean-Christophe PLAGNIOL-VILLARD wrote: On 23:15 Thu 16 Apr , David Brownell wrote: From: David Brownell dbrown...@users.sourceforge.net Make the U-Boot dm9000 driver read addresses from EEPROM just like Linux does ... read six bytes, instead of reading twelve bytes and then discarding every other one. Using the right Ethernet address is a big win. :) Signed-off-by: David Brownell dbrown...@users.sourceforge.net look fine for me Ben any comments? Best Regards, J. I'll apply to net/next regards, Ben ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] net: fix ULI 526x macro usage in netdev.h
Timur Tabi wrote: Change netdev.h to use CONFIG_ULI526X instead of CONFIG_ULI526. CONFIG_ULI526X is used everywhere else, so that's the correct macro name. Without this fix, Ethernet will not work on the Freescale MPC8610 HPCD. Signed-off-by: Timur Tabi ti...@freescale.com --- include/netdev.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/netdev.h b/include/netdev.h index 2794ddd..63cf730 100644 --- a/include/netdev.h +++ b/include/netdev.h @@ -108,7 +108,7 @@ static inline int pci_eth_init(bd_t *bis) #if defined(CONFIG_RTL8169) num += rtl8169_initialize(bis); #endif -#if defined(CONFIG_ULI526) +#if defined(CONFIG_ULI526X) num += uli526x_initialize(bis); #endif Sorry for having fat fingers. Applying to net repo for current release. regards, Ben ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/7] i2c: Create common default i2c_[set|get]_bus_speed() functions
On Saturday 18 April 2009 23:13:58 Peter Tyser wrote: On Sat, 2009-04-18 at 14:23 -0400, Mike Frysinger wrote: On Thursday 16 April 2009 15:41:22 Peter Tyser wrote: +unsigned int i2c_get_bus_speed(void) + __attribute((weak, alias(__def_i2c_get_bus_speed))); __attribute__ ? Interesting, thanks for catching that. I blindly copied the weak functions in net/eth.c which also use the __attribute declaration. It looks like gcc treats __attribute and __attribute__ the same, but I couldn't find any definitive info on __attribute. I'll resubmit using __attribute__. Anyone have a reason that we shouldn't replace all u-boot references to __attribute with __attribute__? not that i know of ... using __XXX__ with gcc keywords tends to be preferred. -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] [ANNOUNCE] Kconfig support
On Sunday 19 April 2009 15:50:46 Robert Schwebel wrote: On Sat, Apr 18, 2009 at 03:18:32PM -0400, Mike Frysinger wrote: so, does it make sense to look at the feature set that v2 brings to the table and get it into u-boot v1? ive never personally looked at v2, but if it means i need to redo all of my Blackfin core/board code, that doesnt sound very appealing at all ... We have even Blackfin support in v2, and that for almost all of the time it is actually there. Sure - if you need feature completeness, you'll have to stay with v1. Our aim is a sane design, and I'm still not convinced that this is even possible with v1 any more. unless it's the code that ive been committing to mainline via the blackfin git tree, then it really doesnt matter (and it looks that way) since, as you say, it is not even close to feature parity. -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 v2] OMAP3: Remove legacy NAND defines
Dear Jean-Christophe PLAGNIOL-VILLARD, In message 20090417053017.gd31...@game.jcrosoft.org you wrote: On 20:15 Tue 14 Apr , Dirk Behme wrote: Remove remaining legacy NAND defines for Beagle, EVM, Overo and Pandora. Signed-off-by: Dirk Behme dirk.be...@googlemail.com --- For Zoom1 it was already removed by http://lists.denx.de/pipermail/u-boot/2009-April/050150.html http://lists.denx.de/pipermail/u-boot/2009-April/050871.html Changes in v2: - Remove even more legacy NAND defines. Thanks to Tom Rix for the hint. This version v2 makes all previous versions of this patch obsolete. will be apply on the next Why next ? As I understand, this fixes build problems in the *current* tree? 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 To IBM, 'open' means there is a modicum of interoperability among some of their equipment.- Harv Masterson ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
