Re: [U-Boot-Users] [PATCH 04/10 v2] [ARM] TQMA31: add new board with i.MX31 processor
Magnus Lilja wrote: >>> It's curious: always, when replying to your e-mails, my e-mail address >>> appears in the To field instead of your address. >>> Do the others have this problem, too? (Thunderbird 2.0.0.14 on Linux) >>> >> I use mutt and I receve the e-mail with your e-mail address as sender >> > > I have the same problem when replying to Jean-Christphe's replies. For > some reason the reply-to field is set when JC posts a reply and I > suppose that messes up Thunderbird/gmail etc. > > As an example, the email I'm replying to now has reply-to: set to > [EMAIL PROTECTED] and [EMAIL PROTECTED] > > Follow ups from other people don't have the reply-to: field. So my > guess is that JC's mutt adds that. > > Regards, Magnus > > > I noticed the same thing when doing a reply-all to one of JC's e-mails. It put my address in 'To'. I using Thunderbird with IMAP connection to Gmail. I've seen with both Windows and Linux versions of Thunderbird. regards, Ben - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Compilation problem for TI3430 board.
Radha Krishna wrote: > Hi, > > I have downloaded U-boot and trying to compile it for the Target > omap3430sdp_config. > > Using commands > > Step 0: make distclean > > Step 1: make CROSS_COMPILE=arm-none-linux-gnueabi- omap3430sdp_config > > Step 2: make CROSS_COMPILE=arm-none-linux-gnueabi- > > I had problem in the compilation. > Without knowing what the problems were, nobody can help you. > Could somebody tell me steps to compile U-Boot for TI3430. > > Best Regards, > > Krishna. > > regards, Ben - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] [resubmit] AX88180: new gigabit network driver
Louis Su wrote: > Signed-off-by: Louis Su <[EMAIL PROTECTED]> > --- > drivers/net/Makefile |1 + > drivers/net/ax88180.c | 727 > + > drivers/net/ax88180.h | 412 > 3 files changed, 1140 insertions(+), 0 deletions(-) > create mode 100644 drivers/net/ax88180.c > create mode 100644 drivers/net/ax88180.h > Applied to net repo. thanks, Ben - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] add board_eth_init() for sh7785lcr board
Hi Nobuhiro, On Wed, Sep 10, 2008 at 5:09 AM, Nobuhiro Iwamatsu <[EMAIL PROTECTED]> wrote: > On Tue, 09 Sep 2008 17:52:47 +0900 > Yoshihiro Shimoda <[EMAIL PROTECTED]> wrote: > >> Fix the problem that cannot work RTL8169 on sh7785lcr board. >> >> Signed-off-by: Yoshihiro Shimoda <[EMAIL PROTECTED]> >> --- >> board/sh7785lcr/sh7785lcr.c |5 + >> 1 files changed, 5 insertions(+), 0 deletions(-) > Applied, thanks. > I put testing branch. > > Best regards, > Nobuhiro > -- > Nobuhiro Iwamatsu > Wolfgang has already applied to the main line. regards, Ben - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] add board_eth_init() for sh7785lcr board
Wolfgang Denk wrote: > Dear Yoshihiro Shimoda, > > In message <[EMAIL PROTECTED]> you wrote: > >> Fix the problem that cannot work RTL8169 on sh7785lcr board. >> >> Signed-off-by: Yoshihiro Shimoda <[EMAIL PROTECTED]> >> --- >> board/sh7785lcr/sh7785lcr.c |5 + >> 1 files changed, 5 insertions(+), 0 deletions(-) >> > > Applied, thanks. > > Ben, I hope this is OK with you. It looked harmelss enough to me... > > Best regards, > > Wolfgang Denk > > Looks perfect. I was going to pick it up tonight, so thanks. regards, Ben - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] rtl8169: add support for RTL8110SCL
Wolfgang Denk wrote: > Dear Ben, > > In message <[EMAIL PROTECTED]> Yoshihiro Shimoda wrote: > >> This patch fixes a problem that RTL8110SCL started transfer >> with an incorrect memory address. >> >> Signed-off-by: Yoshihiro Shimoda <[EMAIL PROTECTED]> >> --- >> > > Is it correct to assume that this patch is sitting in your queue and > you will send a pull-request for it soon? > Yes - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] CUSTODIANS: Final boarding call for flight 1.3.4 ...
On Thu, Aug 7, 2008 at 1:56 AM, Wolfgang Denk <[EMAIL PROTECTED]> wrote: > Hi custodians, > > there are a couple of recent patches which include some bug fixes that > look urgent enough to be included with the upcoming 1.3.4 release (the > last one with the old version number system). > > Can you please process these patcehs and send your pull requests not > later than Friday night? > Sure. I have one outstanding and will pull it in tonight. regards, Ben - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Design Recommendation and Help with Issues
Jatin Sharma wrote: > I am running U-Boot version U-Boot 1.3.1-rc1 on my board that has a > Broadcom network switch. My goal is to initialize this switch at the > bootloader level and be able to tftpboot a Linux kernel from one of > the ethernet ports of this switch. > > As _I_ understand, there are two ways to initialize the switch from u-boot. > > First > = > Theory: Link the switch driver software with the u-boot.bin and flash > it on the board. Switch driver's entry point would be called somewhere > in u-boot to initialize it. Size of the u-boot.bin will increase and > the u-boot partition on the NOR flash will need to be updated to > accommodate the new binary size. > > Practice: After I linked the driver software with the u-boot.bin, the > board didn't boot any further after u-boot got relocated to RAM with > this following message: > "Now running in RAM - U-Boot at: 0ff6d000" > > I did the following to link switch driver library (MDK_BLIBS) with > u-boot in Makefile: > > $(obj)u-boot: . > --start-group $(__LIBS) $(MDK_BLIBS)--end-group > $(PLATFORM_LIBS) \ > . > > Switch library is compiled with same TEXT_BASE and other flags as that > of u-boot. > > Second > == > Theory: Build the network switch driver as a u-boot application, flash > it on a free partition on the NOR and after u-boot has booted, it will > somehow do the following to initialize the network switch. > > cp.b 0xfff9 0x4 0x5bfac > go 0x00040418 > > Practice: The above two commands worked to initialize the switch. I > still need to understand how to run these command automatically after > the u-boot has booted. > > > Questions: > 1.) Which design is recommended, first or the second? Second is easier > for me to implement as I don't have to change the partition sizes but > could easily be overlooking some obvious problems. > It would help to know which type of Broadcom switch it is you're using. A lot of them have a SPI-based control plane, in which case you can set up a simple port configuration without an elaborate driver. regards, Ben - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH RFC 5/5] i.MX31: Add basic support for Freescale's i.MX31 PDK board.
Hi Magnus, On Wed, Aug 6, 2008 at 5:19 AM, Magnus Lilja <[EMAIL PROTECTED]> wrote: > Add support for NAND and ethernet on the Freescale i.MX31 PDK (a.k.a. > 3DS) board. > > Booting from NAND is not supported yet so U-boot relies on some other > initial boot loader to set up SDRAM and clocks and copying U-boot to SDRAM. > > Signed-off-by: Magnus Lilja <[EMAIL PROTECTED]> > --- > +#define CONFIG_NETMASK 255.255.255.0 > +#define CONFIG_IPADDR 192.168.23.168 > +#define CONFIG_SERVERIP192.168.23.2 Please remove default network parms > + > +#defineCONFIG_EXTRA_ENV_SETTINGS > \ > + "bootargs_base=setenv bootargs console=ttymxc0,115200\0"\ > + "bootargs_nfs=setenv bootargs $(bootargs) root=/dev/nfs " \ > + "ip=dhcp nfsroot=$(serverip):$(nfsrootfs),v3,tcp\0" \ > + "bootcmd=run bootcmd_net\0" \ > + "bootcmd_net=run bootargs_base bootargs_mtd bootargs_nfs; " \ > + "tftpboot 0x8000 uImage-mx31; bootm\0" > + > +#define CONFIG_DRIVER_SMC911X 1 > +#define CONFIG_DRIVER_SMC911X_BASE CS5_BASE > +#define CONFIG_DRIVER_SMC911X_32_BIT 1 > + > +/* > + * Miscellaneous configurable options > + */ > +#define CFG_LONGHELP /* undef to save memory */ > +#define CFG_PROMPT "uboot> " > +#define CFG_CBSIZE 256 /* Console I/O Buffer Size */ > +/* Print Buffer Size */ > +#define CFG_PBSIZE (CFG_CBSIZE+sizeof(CFG_PROMPT)+16) > +#define CFG_MAXARGS16 /* max number of command args */ > +#define CFG_BARGSIZE CFG_CBSIZE /* Boot Argument Buffer Size */ > + > +#define CFG_MEMTEST_START PHYS_SDRAM_1 /* memtest works on */ > +#define CFG_MEMTEST_END0x1 > + > +#undef CFG_CLKS_IN_HZ /* everything, incl board info, in Hz */ > + > +#define CFG_LOAD_ADDR 0x8100 /* default load address */ > + > +#define CFG_HZ CONFIG_MX31_CLK32 > + > +#define CONFIG_CMDLINE_EDITING 1 > + > +#undef CONFIG_CMD_IMLS > + > +/*--- > + * Stack sizes > + * > + * The stack sizes are set up in start.S using the settings below > + */ > +#define CONFIG_STACKSIZE (128 * 1024) /* regular stack */ > + > +/*--- > + * Physical Memory Map > + */ > +#define CONFIG_NR_DRAM_BANKS 1 > +#define PHYS_SDRAM_1 CSD0_BASE > +#define PHYS_SDRAM_1_SIZE (128 * 1024 * 1024) > + > +/*--- > + * FLASH and environment organization > + */ > +/* No NOR flash present */ > +#define CFG_NO_FLASH 1 > + > +/* > + * NAND flash > + */ > + > +#define NAND_MAX_CHIPS 1 > +#define CFG_MAX_NAND_DEVICE1 > +#define CFG_NAND_BASE 0x4000 > + > +/* > + * Place U-boot environment right after the U-boot code. > + */ > +#define CFG_ENV_IS_IN_NAND 1 > +#define CFG_ENV_OFFSET 0x4 > +/* CFG_ENV_SIZE has to be a multiple of the NAND block size */ > +#define CFG_ENV_SIZE (128 * 1024) > + > +/* > + * JFFS2 partitions > + */ > +#undef CONFIG_JFFS2_CMDLINE > +#define CONFIG_JFFS2_DEV "nand0" > + > +#endif /* __CONFIG_H */ > + > -- > 1.5.2.4 > regards, Ben - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] NFS TFTP problem
On Tue, Aug 5, 2008 at 7:24 PM, cjjoy1980 <[EMAIL PROTECTED]> wrote: > > I have enabled nfs booting on ppc based embedded board. I had placed my > kernel and rootfs in tftp directory, and had set the u-boot enivironment > varialbes as: > setenv bootfile /image/kernel > setenv root_path /tftpboot/image > > The board was booting with this configuration... > > Now I have placed the kernel image and rootfs in /exports directory and have > set the uboot variables as: > setenv bootfile /exports/image/kernel > setenv root_path /exports/image > > I am not able to boot the board with the above directory. I am getting the > error > > Loading: T > TFTP error: 'File not found' (1) > Starting again. > > TFTP by default looks for /tftpboot directory.. How can we make the server > to fetch files apart from the default one?? > Your question is completely off-topic and you should put more effort into figuring out simple problems like this before asking for help. That said... Here are three options: 1. Put the files back in /tftpboot 2. Figure out how to configure your TFTP server. They're usually quite flexible 3. $ ln -s /exports/image /tftpboot/image regards, Ben - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] RFC: U-Boot version numbering
Albert ARIBAUD wrote: > Ben Warren a écrit : >> Kumar Gala wrote: >>> On Aug 1, 2008, at 10:32 AM, Wolfgang Denk wrote: >>> >>> >>>> Hello, >>>> >>>> I would like to get your general opinion about changing the U-Boot >>>> version numbering scheme. >>>> >>>> To be honest, I never really understood myself how this is supposed >>>> to work and if the next version should be 1.3.4 or 1.4.0 or 2.0.0, i. >>>> e. which changes / additions are important enough to increment the >>>> PATCHLEVEL or even VERSION number. >>>> >>>> I therefor suggest to drop this style of version numbering and change >>>> to a timestamp based version number system which has been quite >>>> successfully used by other projects (like Ubuntu) or is under >>>> discussion (for Linux). >>>> >>>> My suggestion for the new version numbers is as follows: >>>> >>>> VERSION = 1(at least for the time being) >>>> >>>> PATCHLEVEL = current year - 2000 >>>> >>>> SUBLEVEL = current month >>>> >>>> Both PATCHLEVEL and SUBLEVEL shall always be 2 digits (at least for >>>> the next 91+ years to come) so listings for example on an FTP server >>>> shall be in a sane sorting order. >>>> >>>> If we accept this system, the next release which probably comes out >>>> in October 2008 would be v1.08.10, and assuming the one after that >>>> comes out in January 2009 would be named v1.09.01 >>>> >>> If we go to date based versions. I'd prefer we keep year as 4 digits: >>> >>> v1.2008.10 >>> v1.2009.01 >>> >>> It just seems easier to me at a visual level when I look at try and >>> compare versions. >>> >>> - k >>> >> I vote for this one, but starting at v2. > > Just one thing: Verson numbering can be anything you want, but I think > it should be self-consistent. And on that account, I realize that the > "v1" part has no real meaning wrt to the rest of the version string, > which date-related -- unless there is a plan to have simultaneous v1 > and v2 releases, in which case it makes sense to have "v1". > > Amicalement, Yes, in this case the meaning of 'v2' is "new version naming scheme", not "new software version". It probably is superfluous. regards, Ben - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] RFC: U-Boot version numbering
Kumar Gala wrote: > On Aug 1, 2008, at 10:32 AM, Wolfgang Denk wrote: > > >> Hello, >> >> I would like to get your general opinion about changing the U-Boot >> version numbering scheme. >> >> To be honest, I never really understood myself how this is supposed >> to work and if the next version should be 1.3.4 or 1.4.0 or 2.0.0, i. >> e. which changes / additions are important enough to increment the >> PATCHLEVEL or even VERSION number. >> >> I therefor suggest to drop this style of version numbering and change >> to a timestamp based version number system which has been quite >> successfully used by other projects (like Ubuntu) or is under >> discussion (for Linux). >> >> My suggestion for the new version numbers is as follows: >> >> VERSION = 1 (at least for the time being) >> >> PATCHLEVEL = current year - 2000 >> >> SUBLEVEL = current month >> >> Both PATCHLEVEL and SUBLEVEL shall always be 2 digits (at least for >> the next 91+ years to come) so listings for example on an FTP server >> shall be in a sane sorting order. >> >> If we accept this system, the next release which probably comes out >> in October 2008 would be v1.08.10, and assuming the one after that >> comes out in January 2009 would be named v1.09.01 >> > > If we go to date based versions. I'd prefer we keep year as 4 digits: > > v1.2008.10 > v1.2009.01 > > It just seems easier to me at a visual level when I look at try and > compare versions. > > - k > I vote for this one, but starting at v2. regards, Ben - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] RFC: mailing list transfer
On Fri, Aug 1, 2008 at 8:17 AM, Wolfgang Denk <[EMAIL PROTECTED]> wrote: > Hello, > > I would like to get your general opinion about moving the > "u-boot-users" mailing list away from SourceForge and host it on > lists.denx.de instead. > > > There is a couple of reasons for this: SourceForge has freuently been > slow; there have been reports from many users who got unsubscribed > repeatedly for no clear reason; the mailing list archive at SF is > painful to use; and, most of all, we have only limited ways to change > the configuration, and with any other request we depend on the mercy > of SF support, which is, ummm, slw. > > Another reason is that this would make it easier for us to cross-link > between messages on the mailing list and entries in the upcoming bug > and patch tracking system. > > > If we have a majority agreeing with this change, I suggest to proceed > as follows: > > * The new mailing list will be created as [EMAIL PROTECTED] > * The mailing list archive will be transferred from SF to DENX > * The archive services (gmane etc.) will be notified about the change > * All currently subscribed users and their settings will be > transferred from SF to DENX > * After a cut-off date, all users are requested to use the new ML only > [that will be the complicated part]. > * The ML at SF will be set to read-only to make clear it is no longer > * in use. > > Do you think this is a reasonable plan? Any hints, ideas, tips? > Great idea - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH 7/7] ARM: Add support for S3C6400 based SMDK6400 board
On Thu, Jul 31, 2008 at 3:55 AM, Guennadi Liakhovetski <[EMAIL PROTECTED]> wrote: > This board can only boot U-Boot from NAND-flash. This patch adds a nand_spl > driver for it too. SMDK6400 can also boot from the NOR flash, but due to > hardware limitations it can only address 64KiB on it, which is not enough for > U-Boot. Ported from u-boot-1.1.6 version by Samsung. > > Signed-off-by: Guennadi Liakhovetski <[EMAIL PROTECTED]> > --- > MAKEALL|1 > Makefile | 17 + > board/samsung/smdk6400/Makefile| 51 + > board/samsung/smdk6400/config.mk | 27 +++ > board/samsung/smdk6400/lowlevel_init.S | 315 ++ > board/samsung/smdk6400/smdk6400.c | 178 +++ > board/samsung/smdk6400/u-boot-nand.lds | 60 + > include/configs/smdk6400.h | 338 > > nand_spl/board/samsung/smdk6400/Makefile | 103 + > nand_spl/board/samsung/smdk6400/config.mk | 40 > nand_spl/board/samsung/smdk6400/u-boot.lds | 58 + > 11 files changed, 1188 insertions(+), 0 deletions(-) > create mode 100644 board/samsung/smdk6400/Makefile > create mode 100644 board/samsung/smdk6400/config.mk > create mode 100644 board/samsung/smdk6400/lowlevel_init.S > create mode 100644 board/samsung/smdk6400/smdk6400.c > create mode 100644 board/samsung/smdk6400/u-boot-nand.lds > create mode 100644 include/configs/smdk6400.h > create mode 100644 nand_spl/board/samsung/smdk6400/Makefile > create mode 100644 nand_spl/board/samsung/smdk6400/config.mk > create mode 100644 nand_spl/board/samsung/smdk6400/u-boot.lds > > diff --git a/MAKEALL b/MAKEALL > index ee83cca..a3ed47d 100755 > --- a/MAKEALL > +++ b/MAKEALL > @@ -515,6 +515,7 @@ LIST_ARM11="\ >imx31_litekit \ >imx31_phycore \ >mx31ads \ > + smdk6400\ > " > > # > diff --git a/Makefile b/Makefile > index b104617..0c5b8a6 100644 > --- a/Makefile > +++ b/Makefile > @@ -2677,6 +2677,23 @@ mx31ads_config : unconfig > omap2420h4_config : unconfig >@$(MKCONFIG) $(@:_config=) arm arm1136 omap2420h4 NULL omap24xx > > +# > +## ARM1176 Systems > +# > +smdk6400_noUSB_config \ > +smdk6400_config: unconfig > + @mkdir -p $(obj)include $(obj)board/samsung/smdk6400 > + @mkdir -p $(obj)nand_spl/board/samsung/smdk6400 > + @echo "#define CONFIG_NAND_U_BOOT" > $(obj)include/config.h > + @if [ -z "$(findstring smdk6400_noUSB_config,$@)" ]; then > \ > + echo "RAM_TEXT = 0x57e0" >> > $(obj)board/samsung/smdk6400/config.tmp;\ > + $(MKCONFIG) $(@:_config=) arm arm1176 smdk6400 samsung > s3c64xx; \ > + else > \ > + echo "RAM_TEXT = 0xc7e0" >> > $(obj)board/samsung/smdk6400/config.tmp;\ > + $(MKCONFIG) $(@:_noUSB_config=) arm arm1176 smdk6400 samsung > s3c64xx; \ > + fi > + @echo "CONFIG_NAND_U_BOOT = y" >> $(obj)include/config.mk > + > # > # i386 > # > diff --git a/board/samsung/smdk6400/Makefile b/board/samsung/smdk6400/Makefile > new file mode 100644 > index 000..1200e45 > --- /dev/null > +++ b/board/samsung/smdk6400/Makefile > @@ -0,0 +1,51 @@ > +# > +# (C) Copyright 2000, 2001, 2002 > +# Wolfgang Denk, DENX Software Engineering, [EMAIL PROTECTED] > +# > +# 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= lib$(BOARD).a > + > +OBJS := smdk6400.o > +#OBJS := smdk6400.o flash.o > +SOBJS := lowlevel_init.o > + > +$(LIB):$(OBJS) $(SOBJS) > + $(AR) crv $@ $(SOBJS) $(OBJS) > + > +clean: > + rm
Re: [U-Boot-Users] [PATCH 1/2] net/ppc4xx: Rework 4xx non NET_MULTI MII init code
On Wed, Jul 30, 2008 at 5:10 AM, Stefan Roese <[EMAIL PROTECTED]> wrote: > This patch simplifies the 4xx MII PHY init code by introducing the define > CONFIG_PPC4xx_EMAC for EMAC enabled SoC's. > > Signed-off-by: Stefan Roese <[EMAIL PROTECTED]> > --- > This is post 1.3.4 material. > > Ben, could you please queue this up and push it in the next merge > window? If nobody objects of course. > Will do. I'll try to get to it tonight (early morning now). Thanks, I was about to rant about growing conditional non-compilation, but you saved everybody. cheers, Ben - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH 1/1] Re-Submit: Add support for ATMEL AT91SAM9G20EK board.
On Wed, Jul 30, 2008 at 12:44 AM, Haavard Skinnemoen <[EMAIL PROTECTED]> wrote: > "Ben Warren" <[EMAIL PROTECTED]> wrote: >> >> >> extern int macb_eth_initialize(int id, void *regs, unsigned int >> >> >> phy_addr); >> > >> > We're getting more and more of these. Does anyone know an appropriate >> > header to put it in? >> > >> At one point I had a netdev.h file, but removed it because it only >> contained this type of definition. Maybe it's time to resurrect. > > Yeah, perhaps that would be nice. I get the feeling this isn't the only > instance of this kind of thing: > > ~/work/u-boot/upstream$ find -name '*.c' | xargs grep '^extern' | wc -l > 1042 > Yikes. I don't mean to be an ass, but did you know that modern grep has a '-R' (recurse) switch? e.g. $ grep -R --include *.c '^extern' * | wc -l > All of those instances are potentially dangerous. The > macb_eth_initialize() thing has certainly blown up in my face before... > > Btw, shouldn't board_eth_init() and cpu_eth_init() be declared in some > header file as well? It might catch the wrong function definitions > you've pointed out quite a few times already. > Yeah, the fact that I've corrected several wrong return types in one day makes me think it's time. thanks, Ben - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH 1/1] avr32: add support for EarthLCD Favr-32 board
Hello, On Tue, Jul 29, 2008 at 3:27 AM, Hans-Christian Egtvedt <[EMAIL PROTECTED]> wrote: > This patch adds support for the Favr-32 board made by EarthLCD. > > This kit, which is also called ezLCD-101 when running with EarthLCD firmware, > has a 10.4" touch screen LCD panel, 16 MB 32-bit SDRAM, 8 MB parallel flash, > Ethernet, audio out, USB device, SD-card slot, USART and various other > connectors for cennecting stuff to SPI, I2C, GPIO, etc. > > Signed-off-by: Hans-Christian Egtvedt <[EMAIL PROTECTED]> > --- > MAINTAINERS |4 + > MAKEALL |1 + > Makefile |3 + > board/earthlcd/favr-32-ezkit/Makefile| 42 + > board/earthlcd/favr-32-ezkit/config.mk |4 + > board/earthlcd/favr-32-ezkit/eth.c | 33 > board/earthlcd/favr-32-ezkit/favr-32-ezkit.c | 87 ++ > board/earthlcd/favr-32-ezkit/flash.c | 230 > ++ > board/earthlcd/favr-32-ezkit/u-boot.lds | 71 > include/configs/favr-32-ezkit.h | 200 ++ > net/eth.c|3 + > 11 files changed, 678 insertions(+), 0 deletions(-) > create mode 100644 board/earthlcd/favr-32-ezkit/Makefile > create mode 100644 board/earthlcd/favr-32-ezkit/config.mk > create mode 100644 board/earthlcd/favr-32-ezkit/eth.c > create mode 100644 board/earthlcd/favr-32-ezkit/favr-32-ezkit.c > create mode 100644 board/earthlcd/favr-32-ezkit/flash.c > create mode 100644 board/earthlcd/favr-32-ezkit/u-boot.lds > create mode 100644 include/configs/favr-32-ezkit.h > > diff --git a/MAINTAINERS b/MAINTAINERS > index a3d70b1..e043913 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -709,6 +709,10 @@ Haavard Skinnemoen <[EMAIL PROTECTED]> >ATSTK1006 AT32AP7000 >ATNGW100AT32AP7000 > > +Hans-Christian Egtvedt <[EMAIL PROTECTED]> > + > + FAVR-32-EZKIT AT32AP7000 > + > # > # SuperH Systems: # > # # > diff --git a/MAKEALL b/MAKEALL > index 32caab7..c2bb2a7 100755 > --- a/MAKEALL > +++ b/MAKEALL > @@ -723,6 +723,7 @@ LIST_avr32="\ >atstk1004 \ >atstk1006 \ >atngw100\ > + favr-32-ezkit \ > " > > # > diff --git a/Makefile b/Makefile > index 8bfc891..15d7f37 100644 > --- a/Makefile > +++ b/Makefile > @@ -2902,6 +2902,9 @@ atstk1006_config : unconfig > atngw100_config: unconfig >@$(MKCONFIG) $(@:_config=) avr32 at32ap atngw100 atmel at32ap700x > > +favr-32-ezkit_config : unconfig > + @$(MKCONFIG) $(@:_config=) avr32 at32ap favr-32-ezkit earthlcd > at32ap700x > + > # > # > # > diff --git a/board/earthlcd/favr-32-ezkit/Makefile > b/board/earthlcd/favr-32-ezkit/Makefile > new file mode 100644 > index 000..a09ad4d > --- /dev/null > +++ b/board/earthlcd/favr-32-ezkit/Makefile > @@ -0,0 +1,42 @@ > +# > +# (C) Copyright 2001-2006 > +# Wolfgang Denk, DENX Software Engineering, [EMAIL PROTECTED] > +# > +# Copyright (C) 2008 Atmel Corporation > +# > +# 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 flash.o eth.o > + > +SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c) > +OBJS := $(addprefix $(obj),$(SOBJS) $(COBJS)) > + > +$(LIB): $(obj).depend $(OBJS) > + $(AR) $(ARFLAGS) $@ $(OBJS) > + > +# > + > +# defines $(obj).depend target > +include $(SRCTREE)/rules.mk > + > +sinclude $(obj).depend > + > +#
Re: [U-Boot-Users] [PATCH] at91sam9: merge ether driver to cpu_eth_init
Hi J-C,
On Tue, Jul 29, 2008 at 4:03 AM, Jean-Christophe PLAGNIOL-VILLARD
<[EMAIL PROTECTED]> wrote:
> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <[EMAIL PROTECTED]>
>
> diff --git a/cpu/arm926ejs/at91/ether.c b/cpu/arm926ejs/at91/ether.c
> index 7e11fe4..c54f33b 100644
> --- a/cpu/arm926ejs/at91/ether.c
> +++ b/cpu/arm926ejs/at91/ether.c
> @@ -25,10 +25,10 @@
> #include
> #include
>
> +#if defined(CONFIG_MACB) && defined(CONFIG_CMD_NET)
> extern int macb_eth_initialize(int id, void *regs, unsigned int phy_addr);
>
> -#if defined(CONFIG_MACB) && defined(CONFIG_CMD_NET)
> -void at91sam9_eth_initialize(bd_t *bi)
> +void cpu_eth_init(bd_t *bi)
> {
>macb_eth_initialize(0, (void *)AT91_BASE_EMAC, 0x00);
> }
Not quite. cpu_eth_init returns int.
> diff --git a/net/eth.c b/net/eth.c
> index 38979aa..53c6622 100644
> --- a/net/eth.c
> +++ b/net/eth.c
> @@ -74,7 +74,6 @@ extern int greth_initialize(bd_t *);
> extern int atngw100_eth_initialize(bd_t *);
> extern int mcffec_initialize(bd_t*);
> extern int mcdmafec_initialize(bd_t*);
> -extern int at91sam9_eth_initialize(bd_t *);
>
> #ifdef CONFIG_API
> extern void (*push_packet)(volatile void *, int);
> @@ -286,10 +285,6 @@ int eth_initialize(bd_t *bis)
> #if defined(CONFIG_FSLDMAFEC)
>mcdmafec_initialize(bis);
> #endif
> -#if defined(CONFIG_AT91CAP9) || defined(CONFIG_AT91SAM9260) || \
> -defined(CONFIG_AT91SAM9263)
> - at91sam9_eth_initialize(bis);
> -#endif
>
>if (!eth_devices) {
>puts ("No ethernet found.\n");
> --
> 1.5.6.2
>
Thanks. This won't apply against the net/testing branch because I've
already removed a bunch of the other initializations. If you don't
mind, I'll take care of this one along with many others in the coming
few days.
Contradicting what I mentioned in another e-mail, this one does appear
to make more sense as a cpu_eth_init, since all three (plus the new
one) call only one MACB controller. Not a strong opinion, though, so
if anybody wants it as board_eth_init, speak up.
regards,
Ben
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH 1/1] Re-Submit: Add support for ATMEL AT91SAM9G20EK board.
On Tue, Jul 29, 2008 at 2:15 AM, Haavard Skinnemoen <[EMAIL PROTECTED]> wrote: > "Hong Xu" <[EMAIL PROTECTED]> wrote: >> >> or something like this. I don't know if AT91_BASE_EMAC is visible >> >> from this code, so you may need to modify slightly. >> > Can we do a cpu_eth_init instead? >> Not all arm926ejs series have built-in ethernet controller (e.g. >> AT91SAM9261 does not have). If we do it in cpu_eth_init, we may need >> other more #ifdef_s to distinguish. :-) > > In _my_ opinion, I think it's much cleaner to just let the board code > decide which and how many ethernet controllers to initialize instead of > having some #ifdef maze in the CPU code. But it's not may call. > Agreed > Oh, and another thing... > >> >> extern int macb_eth_initialize(int id, void *regs, unsigned int phy_addr); > > We're getting more and more of these. Does anyone know an appropriate > header to put it in? > At one point I had a netdev.h file, but removed it because it only contained this type of definition. Maybe it's time to resurrect. regards, Ben - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH 1/1] Re-Submit: Add support for ATMEL AT91SAM9G20EK board.
Hi Hong,
Thanks for all the hard work. One more thing...
> +#if defined(CONFIG_CMD_NET)
> +int board_eth_init(bd_t *bis)
> +{
> + return at91sam9_eth_initialize(bis);
> +}
> +#endif
Here's at91sam9_eth_initialize:
#if defined(CONFIG_MACB) && defined(CONFIG_CMD_NET)
void at91sam9_eth_initialize(bd_t *bi)
{
macb_eth_initialize(0, (void *)AT91_BASE_EMAC, 0x00);
}
#endif
Issues:
1. It returns void
2. It just calls the MACB initializer.
Please change your code to:
extern int macb_eth_initialize(int id, void *regs, unsigned int phy_addr);
#if defined(CONFIG_MACB) && defined(CONFIG_CMD_NET)
int board_eth_init(bd_t *bi)
{
return macb_eth_initialize(0, (void *)AT91_BASE_EMAC, 0x00);
}
#endif
or something like this. I don't know if AT91_BASE_EMAC is visible
from this code, so you may need to modify slightly.
regards,
Ben
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] Add MIMC200 board - now uses board_eth_init()
Hi Mark,
On Mon, Jul 28, 2008 at 12:32 PM, Mark Jackson <[EMAIL PROTECTED]> wrote:
> The MIMC200 board is based on Atmel's NGW100 dev kit,
> but with an extra 8MByte FLASH and 128KByte FRAM.
>
No need to put the stuff about board_eth_init() in the subject. Just
label this as [PATCH V2].
> +// enable higher address lines for larger flash devices
C++ style comments are not allowed. Please fix them all.
> +#ifdef CONFIG_CMD_NET
> +extern int macb_eth_initialize(int id, void *regs, unsigned int phy_addr);
> +
> +void board_eth_init(bd_t *bi)
> +{
> +macb_eth_initialize(0, (void *)MACB0_BASE, bi->bi_phy_id[0]);
> +macb_eth_initialize(1, (void *)MACB1_BASE, bi->bi_phy_id[1]);
> +}
The prototype is:
int board_eth_init(bd_t *);
You'll need to return 0 if you can't get anything useful from
macb_eth_initialize();
> diff --git a/cpu/at32ap/at32ap700x/clk.c b/cpu/at32ap/at32ap700x/clk.c
> index b3aa034..73b859e 100644
> --- a/cpu/at32ap/at32ap700x/clk.c
> +++ b/cpu/at32ap/at32ap700x/clk.c
> @@ -65,4 +65,12 @@ void clk_init(void)
>/* Use PLL0 as main clock */
>sm_writel(PM_MCCTRL, SM_BIT(PLLSEL));
> #endif
> +
> +#ifdef CONFIG_MIMC200
> +// enable gclk outputs
> +//AVR32_PM.gcctrl[0] = 0x0004; /* LVDS at 10MHz */
> +sm_writel(PM_GCCTRL, 0x0004);
> +//AVR32_PM.gcctrl[1] = 0x0216; /* Ethernet at 25MHz if PLL running */
> +//sm_writel(PM_GCCTRL + 4, 0x0216);
> +#endif
> }
It's frowned upon to conditionally compile board-specific code in CPU
files. Can this be done in your board code?
> diff --git a/cpu/at32ap/at32ap700x/gpio.c b/cpu/at32ap/at32ap700x/gpio.c
> index 56ba2f9..7c6679d 100644
> --- a/cpu/at32ap/at32ap700x/gpio.c
> +++ b/cpu/at32ap/at32ap700x/gpio.c
> @@ -104,8 +104,10 @@ void gpio_enable_macb0(void)
>gpio_select_periph_A(GPIO_PIN_PC11, 0);/* RXD2*/
>gpio_select_periph_A(GPIO_PIN_PC12, 0);/* RXD3*/
>gpio_select_periph_A(GPIO_PIN_PC14, 0);/* RXCK*/
> +#ifndef CONFIG_MIMC200
>gpio_select_periph_A(GPIO_PIN_PC18, 0);/* SPD*/
> #endif
> +#endif
> }
>
> void gpio_enable_macb1(void)
> @@ -129,8 +131,10 @@ void gpio_enable_macb1(void)
>gpio_select_periph_B(GPIO_PIN_PC29, 0);/* RXD2*/
>gpio_select_periph_B(GPIO_PIN_PC30, 0);/* RXD3*/
>gpio_select_periph_B(GPIO_PIN_PC24, 0);/* RXCK*/
> +#ifndef CONFIG_MIMC200
>gpio_select_periph_B(GPIO_PIN_PD15, 0);/* SPD*/
> #endif
> +#endif
> }
> #endif
>
> diff --git a/cpu/at32ap/cpu.c b/cpu/at32ap/cpu.c
> index 0ba8361..8985b68 100644
> --- a/cpu/at32ap/cpu.c
> +++ b/cpu/at32ap/cpu.c
> @@ -56,6 +56,20 @@ int cpu_init(void)
>hsmc3_writel(PULSE0, 0x0b0a0906);
>hsmc3_writel(SETUP0, 0x00010002);
>
> +#ifdef CONFIG_MIMC200
> +// setup Data Flash chip select (NCS2)
> +hsmc3_writel(MODE2, 0x20121003);
> +hsmc3_writel(CYCLE2, 0x000a0009);
> +hsmc3_writel(PULSE2, 0x0a060806);
> +hsmc3_writel(SETUP2, 0x00030102);
> +
> +// setup FRAM chip select (NCS3)
> +hsmc3_writel(MODE3, 0x10120001);
> +hsmc3_writel(CYCLE3, 0x001e001d);
> +hsmc3_writel(PULSE3, 0x08040704);
> +hsmc3_writel(SETUP3, 0x02050204);
> +#endif
> +
>clk_init();
>
>/* Update the CPU speed according to the PLL configuration */
> diff --git a/drivers/serial/atmel_usart.c b/drivers/serial/atmel_usart.c
> index f35b997..9e131c0 100644
> --- a/drivers/serial/atmel_usart.c
> +++ b/drivers/serial/atmel_usart.c
> @@ -21,6 +21,9 @@
> #include
> #include
> #include
> +#if defined(CONFIG_MIMC200_DBGLINK)
> +#include
> +#endif
>
This is definitely uncool. Don't pollute common code with your debug stuff.
Looking forward to V3
regards,
Ben
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] using a flat device tree to drive u-boot config
On Mon, Jul 28, 2008 at 10:43 AM, Scott Wood <[EMAIL PROTECTED]> wrote: > Ben Warren wrote: >> >> On Mon, Jul 28, 2008 at 10:32 AM, Scott Wood <[EMAIL PROTECTED]> >> wrote: >>> >>> I find a device tree much easier to figure out than a tangled mess of >>> header >>> files, #defines, and #ifdefs... >> >> In many ways, yes. But are you an average Joe or a Linux kernel >> propellerhead? > > Is u-boot work normally done by average Joes, and does the average Joe > really find the preprocessor mess more intuitive than a "propellerhead"? > You know what I mean. Some people like yourself do this for a living, and are involved day-to-day in its specification. Of course it's intuitive to you. For most people, getting U-boot going is one stage in the development process of software for an embedded device. They work on it for a few weeks or months, then on something completely different. A few months or years later, they come back to it. > While we're at it, let's re-write u-boot in Visual Basic. :-) Uh, yeah. I like the idea of a central repo for hardware info, and the device tree concept is good. My point is that the syntax, while concise and exact, can be intimidating. Just look at the amount of traffic on the mailing lists of people that don't understand what all the fields mean when specifying IRQs etc. Anything we can do to make it less so for noobies is a good thing for everybody. cheers, Ben - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] using a flat device tree to drive u-boot config
On Mon, Jul 28, 2008 at 10:32 AM, Scott Wood <[EMAIL PROTECTED]> wrote: > Ben Warren wrote: >> >> On Mon, Jul 28, 2008 at 8:07 AM, Kumar Gala <[EMAIL PROTECTED]> >> wrote: >>> >>> One topic that come up during OLS in discussions and u-boot BOF was >>> the idea of driving u-boot configuration from a device tree instead of >>> from "config.h". I was wondering if anyone has actually looked at >>> doing this. >>> >> This sounds like an interesting idea, having a central repo for all >> hardware information. A big problem I see is that while device-tree >> syntax may make sense to Linux kernel propellerheads, to the average >> Joe it's mind-numbing. Config files are ugly, but at least IMHO are >> easy to figure out. > > I find a device tree much easier to figure out than a tangled mess of header > files, #defines, and #ifdefs... > > -Scott > In many ways, yes. But are you an average Joe or a Linux kernel propellerhead? B-) - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] using a flat device tree to drive u-boot config
On Mon, Jul 28, 2008 at 8:07 AM, Kumar Gala <[EMAIL PROTECTED]> wrote: > One topic that come up during OLS in discussions and u-boot BOF was > the idea of driving u-boot configuration from a device tree instead of > from "config.h". I was wondering if anyone has actually looked at > doing this. > This sounds like an interesting idea, having a central repo for all hardware information. A big problem I see is that while device-tree syntax may make sense to Linux kernel propellerheads, to the average Joe it's mind-numbing. Config files are ugly, but at least IMHO are easy to figure out. User-friendly editing tools would be a necessity. Maybe something already exists? > One question I have is how does (or should) u-boot identify where to > find the device tree. I think the idea would be that this "area" > could be easily reflashed with a new blob to get a new configuration. > This should be fun considering the plethora of architectures that U-boot supports. cheers, Ben - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] How to pass MAC address to linux kernel?
On Mon, Jul 28, 2008 at 9:29 AM, 이승열 <[EMAIL PROTECTED]> wrote: > Hi all, > > I'm writing SMC9210 linux device driver. I cannot determine MAC > address because there is no information. > I want to get MAC address from U-boot. How to pass MAC address to linux > kernel? > This depends greatly on your processor architecture. What is it? regards, Ben - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] Add MIMC200 board
Hi Mark,
On Mon, Jul 28, 2008 at 3:16 AM, Mark Jackson <[EMAIL PROTECTED]> wrote:
> The MIMC200 board is based on Atmel's NGW100 dev kit,
> but with an extra 8MByte FLASH and 128KByte FRAM.
> ---
> diff --git a/board/atmel/mimc200/eth.c b/board/atmel/mimc200/eth.c
> new file mode 100644
> index 000..4e13399
> --- /dev/null
> +++ b/board/atmel/mimc200/eth.c
> @@ -0,0 +1,36 @@
> +/*
> + * Copyright (C) 2006 Atmel Corporation
> + *
> + * Ethernet initialization for the AVR32 Network Gateway
> + *
> + * 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
> +
> +#include
> +
> +extern int macb_eth_initialize(int id, void *regs, unsigned int phy_addr);
> +
> +#ifdef CONFIG_CMD_NET
> +void mimc200_eth_initialize(bd_t *bi)
> +{
> +macb_eth_initialize(0, (void *)MACB0_BASE, bi->bi_phy_id[0]);
> +macb_eth_initialize(1, (void *)MACB1_BASE, bi->bi_phy_id[1]);
> +}
> +#endif
Please change to this:
#ifdef CONFIG_CMD_NET
int board_eth_init(bd_t *bi)
{
macb_eth_initialize(0, (void *)MACB0_BASE, bi->bi_phy_id[0]);
macb_eth_initialize(1, (void *)MACB1_BASE, bi->bi_phy_id[1]);
return 0;
}
#endif
> diff --git a/board/atmel/mimc200/Makefile b/board/atmel/mimc200/Makefile
> new file mode 100644
> index 000..1b5c635
> --- /dev/null
> +++ b/board/atmel/mimc200/Makefile
> @@ -0,0 +1,40 @@
> +#
> +# Copyright (C) 2005-2006 Atmel Corporation
> +#
> +# 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 eth.o
> +
When you've made the change to board/eth.c, please verify that your
board_eth_init() function is linked into the final executable. The
output of 'grep eth_enit System.map' must show different addresses for
the board_eth_init and __def_eth_init symbols. If they are the same,
please move the board_eth_init() function to board/mimc200.c
> diff --git a/net/eth.c b/net/eth.c
> index 38979aa..409756d 100644
> --- a/net/eth.c
> +++ b/net/eth.c
> @@ -75,6 +75,7 @@ extern int atngw100_eth_initialize(bd_t *);
> extern int mcffec_initialize(bd_t*);
> extern int mcdmafec_initialize(bd_t*);
> extern int at91sam9_eth_initialize(bd_t *);
> +extern int mimc200_eth_initialize(bd_t *);
>
> #ifdef CONFIG_API
> extern void (*push_packet)(volatile void *, int);
> @@ -290,6 +291,9 @@ int eth_initialize(bd_t *bis)
> defined(CONFIG_AT91SAM9263)
> at91sam9_eth_initialize(bis);
> #endif
> +#if defined(CONFIG_MIMC200)
> +mimc200_eth_initialize(bis);
> +#endif
By changing the function name earlier to board_eth_init(), you no
longer need to touch net/eth.c. Please remove this stuff.
regards,
Ben
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH 1/1] Add support for ATMEL AT91SAM9G20EK board
On Sun, Jul 27, 2008 at 6:46 PM, Hong Xu <[EMAIL PROTECTED]> wrote: > Hi Ben Warren, > > On Sun, Jul 27, 2008 at 12:51, Ben Warren <[EMAIL PROTECTED]> wrote: >> Hi Hong Xu, >> >> On Thu, Jul 24, 2008 at 1:05 AM, Hong Xu <[EMAIL PROTECTED]> wrote: >>> >From 81230b02610c06fdc8a175e635851346488e3bdb Mon Sep 17 00:00:00 2001 >>> From: Hong Xu <[EMAIL PROTECTED]> >>> Date: Thu, 24 Jul 2008 14:25:05 +0800 >>> Subject: [PATCH 1/1] Add support for ATMEL AT91SAM9G20EK board >>> >>> This patch adds support for ATMEL AT91SAM9G20EK board. >>> User manual for AT91SAM9G20EK board, see >>> http://www.atmel.com/dyn/resources/prod_documents/doc6413.pdf >>> AT91 SAM9G20 datasheet, see >>> http://www.atmel.com/dyn/resources/prod_documents/doc6384.pdf >>> >>> Signed-off-by: Hong Xu <[EMAIL PROTECTED]> >>> --- >> >>> diff --git a/net/eth.c b/net/eth.c >>> index 38979aa..3f50e2b 100644 >>> --- a/net/eth.c >>> +++ b/net/eth.c >>> @@ -287,7 +287,7 @@ int eth_initialize(bd_t *bis) >>>mcdmafec_initialize(bis); >>> #endif >>> #if defined(CONFIG_AT91CAP9) || defined(CONFIG_AT91SAM9260) || \ >>> -defined(CONFIG_AT91SAM9263) >>> +defined(CONFIG_AT91SAM9263) || defined(CONFIG_AT91SAM9G20) >>>at91sam9_eth_initialize(bis); >>> #endif >>> >> >> Please don't touch net/eth.c. Instead, implement the following in board >> code: > > Actually I did NOT touch the logic in net/eth.c. I just said, "hey, > since you guys have the logic, please make a call for me.". That's it. > :-) Sure. I'm saying, don't even do that. I mean don't touch the file, not don't touch the logic. regards, Ben - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH 1/1] Add support for ATMEL AT91SAM9G20EK board
Hi Hong Xu, On Thu, Jul 24, 2008 at 1:05 AM, Hong Xu <[EMAIL PROTECTED]> wrote: > >From 81230b02610c06fdc8a175e635851346488e3bdb Mon Sep 17 00:00:00 2001 > From: Hong Xu <[EMAIL PROTECTED]> > Date: Thu, 24 Jul 2008 14:25:05 +0800 > Subject: [PATCH 1/1] Add support for ATMEL AT91SAM9G20EK board > > This patch adds support for ATMEL AT91SAM9G20EK board. > User manual for AT91SAM9G20EK board, see > http://www.atmel.com/dyn/resources/prod_documents/doc6413.pdf > AT91 SAM9G20 datasheet, see > http://www.atmel.com/dyn/resources/prod_documents/doc6384.pdf > > Signed-off-by: Hong Xu <[EMAIL PROTECTED]> > --- > diff --git a/net/eth.c b/net/eth.c > index 38979aa..3f50e2b 100644 > --- a/net/eth.c > +++ b/net/eth.c > @@ -287,7 +287,7 @@ int eth_initialize(bd_t *bis) >mcdmafec_initialize(bis); > #endif > #if defined(CONFIG_AT91CAP9) || defined(CONFIG_AT91SAM9260) || \ > -defined(CONFIG_AT91SAM9263) > +defined(CONFIG_AT91SAM9263) || defined(CONFIG_AT91SAM9G20) >at91sam9_eth_initialize(bis); > #endif > Please don't touch net/eth.c. Instead, implement the following in board code: int board_eth_init(bd_t *bis); Please be sure to check that the weak version of board_eth_init() is overridden (the board_eth_init and __def_eth_init symbols should have different addresses in the object code). You can do something like: $ cat System.map | grep eth_init regards, Ben - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [yes, i tried rtfming docs]u-boot on x86, how to?
Hi Geraldo, On Sat, Jul 26, 2008 at 11:31 AM, Geraldo Netto <[EMAIL PROTECTED]> wrote: > Hi Albert, > Thank you very much for your support/help :) > i actually didn't want be harsh with my words :( > i'm pretty newbie, *really* I haven't tried to build U-boot for x86 target, but am led to believe that it's not easy. If you're a newbie, it may not be for you. > and what i did is: > > sudo tar xjvf u-boot-1.3.3.tar.bz2 -C /usr/src > > then i tried: > > make distclean canyonlands_config all > (as i read at http://www.denx.de/wiki/view/DULG/UBootConfiguration ) > Each target has a config file in include/configs. When you 'make' canyonlands_config, you're telling the build system to set things up for a target called 'canyonlands'. This target is a PowerPC target, not x86. You need to find one that's close to your hardware or make your own. > and i got: > > mbdev-deb:/usr/src/u-boot-1.3.3# make distclean canyonlands_config all > Configuring for canyonlands board... > System not configured - see README > make: ** [all] Erro 1 > > also, as you all can easely see, i was not able to 'configure' the system > i tried many other things in a 'adhoc' way and i still not able to > handle this :( > You're seriously missing some big concepts and trying things without understanding them will only lead to pain. Ask yourself why you want U-boot on an x86 target. Grub or Lilo may be a better fit. regards, Ben - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] QE UEC: MII command support and adding UECs
Andy Fleming wrote: > On Wed, Jul 16, 2008 at 2:17 PM, richardretanubun > <[EMAIL PROTECTED]> wrote: > >> Hi, >> >> I am wondering if the miiphy command support for QE UEC is already >> merged into u-boot on some tree. >> >> The last info I have on this patch is on this posting: >> >> http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/38965 >> > > Hm... I vaguely recall seeing that, but it's more in Ben Warren's > domain. He probably wasn't copied on the patch, either. > Yeah, looks like I missed that one. To answer your question, no. I won't be able to apply it until the weekend at the earliest, so for now please just apply the patch yourself. regards, Ben - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH 3/7] sbc8560: define eth0 and eth1 instead of eth1 and eth2
On Mon, Jul 14, 2008 at 11:25 PM, Wolfgang Denk <[EMAIL PROTECTED]> wrote: > In message <[EMAIL PROTECTED]> you wrote: >> >> As a compromise between removal and keeping the useful information for >> developers who are doing early bringup on similar boards, I have >> applied this patch, and replaced the above with: >> >> /* You can compile in a MAC address and your custom net settings by using >> * the following syntax. Your board should be marked with the assigned >> * MAC addresses directly on it. >> * >> * #define CONFIG_ETHADDR de:ad:be:ef:00:00 >> * #define CONFIG_ETH1ADDRfa:ke:ad:dr:es:s! >> * #define CONFIG_SERVERIP >> * #define CONFIG_IPADDR >> * #define CONFIG_GATEWAYIP >> * #define CONFIG_NETMASK >> */ >> >> Wolfgang, if you still object, I can totally remove it before you pull > > That's OK with me. > >> (git rebase --interactive is a wonderful thing). > > Indeed, isn't it? I still remember times when we had to use CVS - or > even ClearCase... > Why did you have to bring up ClearCase? Today was just starting to show some promise :-) - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] PATCH for U-Boot 1.3.3 DHCP fails withnetgearWGR614v6
Wolfgang, On Fri, Jul 11, 2008 at 4:05 PM, Robin Getz <[EMAIL PROTECTED]> wrote: > On Fri 11 Jul 2008 18:41, Ben Warren pondered: >> I'm a bit of an idealist, so I say let's do it right (remove the call to >> BootpCopyNetParams()). Unless somebody with some historical perspective >> weighs in, we'll pull it in as soon as the next merge window opens and >> see what happens. > > > Fix DHCP protocol so U-Boot does not respond on the network with it's offered > IP number until after it has received a DHCP ACK message. Also ensures that > U-Boot does it's DHCPREQUEST as broadcast (per RFC 2131). > > > Signed-off-by: Robin Getz <[EMAIL PROTECTED]> > Acked-by: Ben Warren <[EMAIL PROTECTED]> > --- net/bootp.c 2008-07-11 12:05:18.0 -0400 > +++ net/bootp.c 2008-07-11 18:58:15.0 -0400 > @@ -924,8 +924,6 @@ >if (NetReadLong((ulong*)&bp->bp_vend[0]) == > htonl(BOOTP_VENDOR_MAGIC)) >DhcpOptionsProcess((u8 *)&bp->bp_vend[4], bp); > > - BootpCopyNetParams(bp); /* Store net params from > reply */ > - >NetSetTimeout(TIMEOUT * CFG_HZ, BootpTimeout); >DhcpSendRequestPkt(bp); > #ifdef CFG_BOOTFILE_PREFIX > I can't pull this in today. Please apply directly so it gets in RC1 thanks, Ben - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [PATCH 3/3] Moved initialization of SKGE Ethernet driver to board code.
The only board using this driver is the SL8245 board.
Removed initialization for the driver from net/eth.c
Signed-off-by: Ben Warren <[EMAIL PROTECTED]>
---
board/sl8245/sl8245.c | 13 +
drivers/net/sk98lin/uboot_drv.c |2 +-
net/eth.c |4
3 files changed, 14 insertions(+), 5 deletions(-)
diff --git a/board/sl8245/sl8245.c b/board/sl8245/sl8245.c
index 8647887..c853755 100644
--- a/board/sl8245/sl8245.c
+++ b/board/sl8245/sl8245.c
@@ -66,3 +66,16 @@ void pci_init_board(void)
{
pci_mpc824x_init(&hose);
}
+
+extern int skge_initialize(bd_t *bis);
+
+int board_eth_init(bd_t *bis)
+{
+ int rc = 0;
+
+#if defined(CONFIG_SK98)
+ rc = skge_initialize(bis);
+#endif
+ return rc;
+}
+
diff --git a/drivers/net/sk98lin/uboot_drv.c b/drivers/net/sk98lin/uboot_drv.c
index 8b04842..205e7d2 100644
--- a/drivers/net/sk98lin/uboot_drv.c
+++ b/drivers/net/sk98lin/uboot_drv.c
@@ -70,7 +70,7 @@ int skge_initialize(bd_t * bis)
eth_register(dev[i]);
}
- return numdev;
+ return ((numdev > 0) && (numdev <= SKGE_MAX_CARDS) ? 0 : -1);
}
diff --git a/net/eth.c b/net/eth.c
index eaa58fa..9ab206d 100644
--- a/net/eth.c
+++ b/net/eth.c
@@ -63,7 +63,6 @@ extern int ppc_4xx_eth_initialize(bd_t *);
extern int rtl8139_initialize(bd_t*);
extern int rtl8169_initialize(bd_t*);
extern int scc_initialize(bd_t*);
-extern int skge_initialize(bd_t*);
extern int tsi108_eth_initialize(bd_t*);
extern int npe_initialize(bd_t *);
extern int uec_initialize(int);
@@ -200,9 +199,6 @@ int eth_initialize(bd_t *bis)
#if defined(CONFIG_MPC8220_FEC)
mpc8220_fec_initialize(bis);
#endif
-#if defined(CONFIG_SK98)
- skge_initialize(bis);
-#endif
#if defined(CONFIG_UEC_ETH1)
uec_initialize(0);
#endif
--
1.5.4.3
-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [PATCH 2/3] Moved initialization of ULI526X Ethernet driver to board code.
The only board using this driver is the Freescale MPC8610HPCD board.
Removed initialization for the driver from net/eth.c
Signed-off-by: Ben Warren <[EMAIL PROTECTED]>
---
board/freescale/mpc8610hpcd/mpc8610hpcd.c | 10 ++
net/eth.c |4
2 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/board/freescale/mpc8610hpcd/mpc8610hpcd.c
b/board/freescale/mpc8610hpcd/mpc8610hpcd.c
index c85f373..0122e6d 100644
--- a/board/freescale/mpc8610hpcd/mpc8610hpcd.c
+++ b/board/freescale/mpc8610hpcd/mpc8610hpcd.c
@@ -515,3 +515,13 @@ get_board_sys_clk(ulong dummy)
return val;
}
+
+extern int uli526x_initialize(bd_t *);
+
+int board_eth_init(bd_t *bis)
+{
+#if defined(CONFIG_ULI526)
+ uli526x_initialize(bis);
+#endif
+ return 0;
+}
diff --git a/net/eth.c b/net/eth.c
index 4eb20e3..eaa58fa 100644
--- a/net/eth.c
+++ b/net/eth.c
@@ -65,7 +65,6 @@ extern int rtl8169_initialize(bd_t*);
extern int scc_initialize(bd_t*);
extern int skge_initialize(bd_t*);
extern int tsi108_eth_initialize(bd_t*);
-extern int uli526x_initialize(bd_t *);
extern int npe_initialize(bd_t *);
extern int uec_initialize(int);
extern int at91sam9_eth_initialize(bd_t *);
@@ -253,9 +252,6 @@ int eth_initialize(bd_t *bis)
#if defined(CONFIG_TSI108_ETH)
tsi108_eth_initialize(bis);
#endif
-#if defined(CONFIG_ULI526X)
- uli526x_initialize(bis);
-#endif
#if defined(CONFIG_RTL8139)
rtl8139_initialize(bis);
#endif
--
1.5.4.3
-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [PATCH 1/3] Moved initialization of Blackfin EMAC Ethernet controller to board_eth_init()
Added board_eth_init() function to bf537-stamp board.
Removed initialization for the Blackin EMAC driver from net/eth.c
Signed-off-by: Ben Warren <[EMAIL PROTECTED]>
---
board/bf537-stamp/bf537-stamp.c | 10 ++
drivers/net/bfin_mac.c |2 +-
net/eth.c |4
3 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/board/bf537-stamp/bf537-stamp.c b/board/bf537-stamp/bf537-stamp.c
index cd7a04d..a9b7a68 100644
--- a/board/bf537-stamp/bf537-stamp.c
+++ b/board/bf537-stamp/bf537-stamp.c
@@ -154,6 +154,16 @@ int misc_init_r(void)
}
#endif /* CONFIG_MISC_INIT_R */
+#if defined(CONFIG_BFIN_MAC)
+
+extern int bfin_EMAC_initialize(bd_t *bis);
+
+int board_eth_init(bd_t *bis)
+{
+ return bfin_EMAC_initialize(bis);
+}
+#endif
+
#ifdef CONFIG_POST
/* Using sw10-PF5 as the hotkey */
int post_hotkeys_pressed(void)
diff --git a/drivers/net/bfin_mac.c b/drivers/net/bfin_mac.c
index fe56949..3ee5d96 100644
--- a/drivers/net/bfin_mac.c
+++ b/drivers/net/bfin_mac.c
@@ -88,7 +88,7 @@ int bfin_EMAC_initialize(bd_t *bis)
eth_register(dev);
- return 1;
+ return 0;
}
static int bfin_EMAC_send(struct eth_device *dev, volatile void *packet,
diff --git a/net/eth.c b/net/eth.c
index 3c152bf..4eb20e3 100644
--- a/net/eth.c
+++ b/net/eth.c
@@ -68,7 +68,6 @@ extern int tsi108_eth_initialize(bd_t*);
extern int uli526x_initialize(bd_t *);
extern int npe_initialize(bd_t *);
extern int uec_initialize(int);
-extern int bfin_EMAC_initialize(bd_t *);
extern int at91sam9_eth_initialize(bd_t *);
#ifdef CONFIG_API
@@ -263,9 +262,6 @@ int eth_initialize(bd_t *bis)
#if defined(CONFIG_RTL8169)
rtl8169_initialize(bis);
#endif
-#if defined(CONFIG_BF537)
- bfin_EMAC_initialize(bis);
-#endif
#if defined(CONFIG_AT91CAP9) || defined(CONFIG_AT91SAM9260) || \
defined(CONFIG_AT91SAM9263)
at91sam9_eth_initialize(bis);
--
1.5.4.3
-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [PATCH 0/3] More net/eth.c cleanup
Hello, More cleanup of net/eth.c, this time taking care of the following: - Blackfin EMAC - ULi526x - SKGE I don't have any of this hardware, so testing consisted of compiling only. This patch is being staged in the 'testing' branch of the net repo. regards, Ben - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [PATCH] Moved conditional compilation to Makefile for SK98 Ethernet driver
Brute-force removal of #ifdefs. Didn't touch the code.
Signed-off-by: Ben Warren <[EMAIL PROTECTED]>
---
drivers/net/sk98lin/Makefile| 20
drivers/net/sk98lin/skaddr.c|4
drivers/net/sk98lin/skcsum.c|4
drivers/net/sk98lin/skge.c |4
drivers/net/sk98lin/skgehwt.c |5 -
drivers/net/sk98lin/skgeinit.c |4
drivers/net/sk98lin/skgemib.c |4
drivers/net/sk98lin/skgepnmi.c |4
drivers/net/sk98lin/skgesirq.c |4
drivers/net/sk98lin/ski2c.c |4
drivers/net/sk98lin/sklm80.c|4
drivers/net/sk98lin/skproc.c|4
drivers/net/sk98lin/skqueue.c |4
drivers/net/sk98lin/skrlmt.c|4
drivers/net/sk98lin/sktimer.c |4
drivers/net/sk98lin/skvpd.c |4
drivers/net/sk98lin/skxmac2.c |4
drivers/net/sk98lin/uboot_drv.c |6 --
drivers/net/sk98lin/uboot_skb.c |5 -
19 files changed, 4 insertions(+), 92 deletions(-)
diff --git a/drivers/net/sk98lin/Makefile b/drivers/net/sk98lin/Makefile
index 8b83fae..f1bc4a7 100644
--- a/drivers/net/sk98lin/Makefile
+++ b/drivers/net/sk98lin/Makefile
@@ -29,24 +29,12 @@ include $(TOPDIR)/config.mk
LIB:= $(obj)libsk98lin.a
-COBJS-y += skge.o
-COBJS-y += skaddr.o
-COBJS-y += skgehwt.o
-COBJS-y += skgeinit.o
-COBJS-y += skgepnmi.o
-COBJS-y += skgesirq.o
-COBJS-y += ski2c.o
-COBJS-y += sklm80.o
-COBJS-y += skqueue.o
-COBJS-y += skrlmt.o
-COBJS-y += sktimer.o
-COBJS-y += skvpd.o
-COBJS-y += skxmac2.o
-COBJS-y += skcsum.o
+COBJS-$(CONFIG_SK98) += skge.o skaddr.o skgehwt.o skgeinit.o skgepnmi.o \
+ skgesirq.o ski2c.o sklm80.o skqueue.o skrlmt.o sktimer.o \
+ skvpd.o skxmac2.o skcsum.o
#COBJS-y += skproc.o
-COBJS-y += uboot_skb.o
-COBJS-y += uboot_drv.o
+COBJS-$(CONFIG_SK98) += uboot_skb.o uboot_drv.o
COBJS := $(COBJS-y)
SRCS := $(COBJS:.o=.c)
diff --git a/drivers/net/sk98lin/skaddr.c b/drivers/net/sk98lin/skaddr.c
index ed79c04..8d34f72 100644
--- a/drivers/net/sk98lin/skaddr.c
+++ b/drivers/net/sk98lin/skaddr.c
@@ -220,8 +220,6 @@
#include
-#ifdef CONFIG_SK98
-
#ifndeflint
static const char SysKonnectFileId[] =
"@(#) $Id: skaddr.c,v 1.48 2003/02/12 17:09:37 tschilli Exp $ (C)
SysKonnect.";
@@ -1875,5 +1873,3 @@ SK_U32ToPortNumber) /* Port2 Index */
#ifdef __cplusplus
}
#endif /* __cplusplus */
-
-#endif /* CONFIG_SK98 */
diff --git a/drivers/net/sk98lin/skcsum.c b/drivers/net/sk98lin/skcsum.c
index a5dc572..162b67d 100644
--- a/drivers/net/sk98lin/skcsum.c
+++ b/drivers/net/sk98lin/skcsum.c
@@ -72,8 +72,6 @@
#include
-#ifdef CONFIG_SK98
-
#ifdef SK_USE_CSUM /* Check if CSUM is to be used. */
#ifndef lint
@@ -925,5 +923,3 @@ SK_EVPARA Param) /* Event dependent parameter. */
} /* SkCsEvent */
#endif /* SK_USE_CSUM */
-
-#endif /* CONFIG_SK98 */
diff --git a/drivers/net/sk98lin/skge.c b/drivers/net/sk98lin/skge.c
index e1d7e87..c815480 100644
--- a/drivers/net/sk98lin/skge.c
+++ b/drivers/net/sk98lin/skge.c
@@ -342,8 +342,6 @@
#include
-#ifdef CONFIG_SK98
-
#include "h/skversion.h"
#if 0
#include
@@ -4860,5 +4858,3 @@ int l;
} /* DumpLong */
#endif
-
-#endif /* CONFIG_SK98 */
diff --git a/drivers/net/sk98lin/skgehwt.c b/drivers/net/sk98lin/skgehwt.c
index f8681a8..ca08eb1 100644
--- a/drivers/net/sk98lin/skgehwt.c
+++ b/drivers/net/sk98lin/skgehwt.c
@@ -75,8 +75,6 @@
#include
-#ifdef CONFIG_SK98
-
/*
Event queue and dispatcher
*/
@@ -214,7 +212,4 @@ SK_IOC Ioc)/* IoContext */
pAC->Hwt.TStop = pAC->Hwt.TStart;
SkTimerDone(pAC,Ioc) ;
}
-
-#endif /* CONFIG_SK98 */
-
/* End of file */
diff --git a/drivers/net/sk98lin/skgeinit.c b/drivers/net/sk98lin/skgeinit.c
index e49685b..ab740c7 100644
--- a/drivers/net/sk98lin/skgeinit.c
+++ b/drivers/net/sk98lin/skgeinit.c
@@ -395,8 +395,6 @@
#include
-#ifdef CONFIG_SK98
-
#include "h/skdrv1st.h"
#include "h/skdrv2nd.h"
@@ -2367,5 +2365,3 @@ int Port) /* Port to configure */
return(0);
} /* SkGeInitPort */
-
-#endif /* CONFIG_SK98 */
diff --git a/drivers/net/sk98lin/skgemib.c b/drivers/net/sk98lin/skgemib.c
index 4a9e9e6..7f62e9c 100644
--- a/drivers/net/sk98lin/skgemib.c
+++ b/drivers/net/sk98lin/skgemib.c
@@ -52,8 +52,6 @@
#include
-#ifdef CONFIG_SK98
-
/*
* PRIVATE OID handler function prototypes
*/
@@ -1056,5 +1054,3 @@ PNMI_STATIC const SK_PNMI_TAB_ENTRY IdTable[] = {
0,
SK_PNMI_RO, Vct, 0},
};
-
-#endif /* CONFIG_SK98 */
diff --git a/drivers/net/sk98lin/skgepnmi.c b/drivers/net/sk98lin/skgepnmi.c
index 16fa352..d0e33cb 100644
--- a/drivers/net/sk98lin/skgepnmi.c
+++ b/drivers/net/sk98lin/skgepnmi.c
@@ -434,8 +434,6 @@
#include
-#ifdef CONFIG_SK98
-
static const char SysKonnectFileId[] =
"
Re: [U-Boot-Users] PATCH for U-Boot 1.3.3 DHCP fails withnetgearWGR614v6
Wolfgang Denk wrote: > In message <[EMAIL PROTECTED]> you wrote: > >> Robin Getz wrote: >> >>> On Fri 11 Jul 2008 18:05, Ben Warren pondered: >>> >>> >>>> Hi Robin, >>>> >>>> Robin Getz wrote: >>>> >>>> >>>>> On Fri 11 Jul 2008 14:21, Ben Warren pondered: >>>>> >>>>> >>>>>> Robin Getz wrote: >>>>>> > > Hm... this looks as if there was some longer discussion, but I cannot > find any traces of this on the mailing list. > > Would be interesting to know what you discussed. At least if it should > result in any changes to the existing code. > > Strange - there was plenty of inane conversation between gvb and myself, but the list was always CC'd. It shows up on gmane: http://news.gmane.org/gmane.comp.boot-loaders.u-boot Essentially, Robin found a bug whereby the DHCP client is responding to ARP requests before all the handshaking is finished, causing his new Netgear router to NAK the overall request. Hopefully you can follow the thread, otherwise I'll be happy to fill you in. regards, Ben - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] PATCH for U-Boot 1.3.3 DHCP fails withnetgearWGR614v6
Robin Getz wrote: > On Fri 11 Jul 2008 18:05, Ben Warren pondered: > >> Hi Robin, >> >> Robin Getz wrote: >> >>> On Fri 11 Jul 2008 14:21, Ben Warren pondered: >>> >>> >>>> Robin Getz wrote: >>>> >>>> >>> [snip] >>> >>> >>>>> >>>>> >>>>> >>>> This seems goofy. Have you tried your fix with other DHCP servers to >>>> >>>> verify that it works? If so, which ones? I unfortunately can't try >>>> anything right now but will play around a bit tonight. >>>> >>>> >>> Some other random netgears that I have in my home, plus whatever is >>> attached to our corp network - it works on them all (but on those it >>> worked before as well). >>> >>> -Robin >>> >> While your fix works, wouldn't it be more correct to remove the call to >> BootpCopyNetParams() on line 927? >> > > That seems to work as well - but changes the operation a little. > > Before - the U-Boot had set source IP number to the IP number it had been > offered (my first patch leaves it that way). With the call to > BootpCopyNetParams() removed, it does a broadcast (Source IP is 0.0.0.0 - > just like the RFC says it should do). > > I have no idea if some other broken DHCP server historically needed that, or > what was going on - so that is why I only fixed the operation on the wire - > not changed it from it's existing state (which AFAICT - _is_ wrong). > > I'm more than happy to send the patch that remove the call (and makes things > more correct, fixes the bug, and makes things smaller) - but I'm also > hesitant since I don't want to break it for anyone else :) > > >> My understanding of the purpose of >> the DHCPDISCOVER state is for determining if there are reachable DHCP >> servers, not for actually acquiring an address. I'm a bit wary because >> I don't know why that call was put there in the first place. I guess in >> theory you could short-circuit the DHCPREQUEST state, but the code >> doesn't do that. >> > > The code does do that. The call to BootpCopyNetParams() sets up the network, > and allows the ARP code in ./net/net.c to respond (before it should) this is > what causes the problem I was/am having. > > Either fix is fine with me - let me know which one you want. > > -Robin > > I'm a bit of an idealist, so I say let's do it right (remove the call to BootpCopyNetParams()). Unless somebody with some historical perspective weighs in, we'll pull it in as soon as the next merge window opens and see what happens. thanks a lot, Ben - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] PATCH for U-Boot 1.3.3 DHCP fails with netgearWGR614v6
Hi Robin, Robin Getz wrote: > On Fri 11 Jul 2008 14:21, Ben Warren pondered: > >> Robin Getz wrote: >> > [snip] > >>> >>> >> This seems goofy. Have you tried your fix with other DHCP servers to >> verify that it works? If so, which ones? I unfortunately can't try >> anything right now but will play around a bit tonight. >> > > Some other random netgears that I have in my home, plus whatever is attached > to our corp network - it works on them all (but on those it worked before as > well). > > -Robin While your fix works, wouldn't it be more correct to remove the call to BootpCopyNetParams() on line 927? My understanding of the purpose of the DHCPDISCOVER state is for determining if there are reachable DHCP servers, not for actually acquiring an address. I'm a bit wary because I don't know why that call was put there in the first place. I guess in theory you could short-circuit the DHCPREQUEST state, but the code doesn't do that. thanks, Ben - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH 3/7] sbc8560: define eth0 and eth1 instead of eth1 and eth2
Paul Gortmaker wrote: > The existing config doesn't define CONFIG_HAS_ETH0, and so the > fdt support doesn't update the zeros in the dtb local-mac with > real data from the u-boot env. Since the existing config is > tailored to just two interfaces, get rid of the ETH2 definitions > at the same time. > > Also don't include any end user specific data into the environment > by default -- things like MAC address, network parameters etc. need > to come from the end user. > > Signed-off-by: Paul Gortmaker <[EMAIL PROTECTED]> > Acked-by: Ben Warren <[EMAIL PROTECTED]> > --- > include/configs/sbc8560.h | 22 +- > 1 files changed, 13 insertions(+), 9 deletions(-) > > diff --git a/include/configs/sbc8560.h b/include/configs/sbc8560.h > index f07fbc0..f4408ad 100644 > --- a/include/configs/sbc8560.h > +++ b/include/configs/sbc8560.h > @@ -327,9 +327,8 @@ >#define CFG_ENV_SIZE 0x2000 > #endif > > -#define CONFIG_BOOTARGS "root=/dev/nfs rw nfsroot=192.168.0.251:/tftpboot > ip=192.168.0.105:192.168.0.251::255.255.255.0:sbc8560:eth0:off > console=ttyS0,9600" > +#define CONFIG_BOOTARGS "root=/dev/nfs rw ip=dhcp console=ttyS0,9600" > /*#define CONFIG_BOOTARGS "root=/dev/ram rw console=ttyS0,115200"*/ > -#define CONFIG_BOOTCOMMAND "bootm 0xff80 0xffa0" > #define CONFIG_BOOTDELAY 5 /* -1 disable autoboot */ > > #define CONFIG_LOADS_ECHO1 /* echo on for serial download */ > @@ -405,19 +404,24 @@ >#define CONFIG_KGDB_SER_INDEX 2 /* which serial port to use */ > #endif > > -/*Note: change below for your network setting!!! */ > #if defined(CONFIG_TSEC_ENET) || defined(CONFIG_ETHER_ON_FCC) > -# define CONFIG_ETHADDR 00:01:af:07:9b:8a > -# define CONFIG_HAS_ETH1 > -# define CONFIG_ETH1ADDR00:01:af:07:9b:8b > -# define CONFIG_HAS_ETH2 > -# define CONFIG_ETH2ADDR00:01:af:07:9b:8c > +#define CONFIG_HAS_ETH0 > +#define CONFIG_HAS_ETH1 > #endif > > +/* You can compile in a MAC address and your custom net settings by using > + * the * following syntax. Your board should be marked with the assigned > + * MAC addresses directly on it. > + */ > +#if 0 > +#define CONFIG_ETHADDR 00:01:af:07:9b:8a > +#define CONFIG_ETH1ADDR 00:01:af:07:9b:8b > #define CONFIG_SERVERIP 192.168.0.131 > #define CONFIG_IPADDR192.168.0.105 > -#define CONFIG_GATEWAYIP 0.0.0.0 > +#define CONFIG_GATEWAYIP 192.168.0.1 > #define CONFIG_NETMASK 255.255.255.0 > +#endif > + > That's a good way of doing it. I know people generally don't like #if 0, but you're conveying useful information. > #define CONFIG_HOSTNAME SBC8560 > #define CONFIG_ROOTPATH /home/ppc > #define CONFIG_BOOTFILE pImage > regards, Ben - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] PATCH for U-Boot 1.3.3 DHCP fails with netgear WGR614v6
Jerry Van Baren wrote: > Ben Warren wrote: >> Jerry Van Baren wrote: >>> Ben Warren wrote: >>>> Robin Getz wrote: >>>>> I was trying out U-Boot 1.1.3 with a new(er) router netgear >>>>> WGR614v6 - firmware version V2.0.19_1.0.19NA, on a Blackfin >>>>> BF537-STAMP. >>>>> >>>>> http://kbserver.netgear.com/products/wgr614v6.asp >>>>> >>>>> and found that dhcp fails :( >>> >>> More correctly, the *second* DHCP request fails. >>> >>>>> bfin> dhcp >>>>> BOOTP broadcast 1 >>>>> BOOTP broadcast 2 >>>>> BOOTP broadcast 3 >>>>> BOOTP broadcast 4 >>>>> BOOTP broadcast 5 >>>>> >>>>> Retry count exceeded; starting again >>>>> >>>>> When turning on some more verbose debug messages (in the net >>>>> driver & in the network code, not all of which exists in U-Boot >>>>> release or trunk), we can see exactly what is going on... >>>>> >>>>> = >>> >>> First DHCP request... >>> >>>>> bfin> dhcp >>>>> Eth_halt: .. >>>>> Eth_init: .. >>>>> BOOTP broadcast 1 >>>>> setting transaction ID to 3268fe22 >>>>> BFIN EMAC send: length = 343 >>>>> BFIN EMAC rx: length = 552 >>>>> packet received >>>>> packet received >>>>> Receive from protocol 0x800 >>>>> Got IP >>>>> len=308, v=45 >>>>> passing packet len= 280 >>>>> DHCPHandler: got packet: (src=67, dst=68, len=280) state: 3 >>>>> Filtering pkt = 0 >>>>> DHCPHandler: got DHCP packet: (src=67, dst=68, len=280) state: 3 >>>>> DHCP: state=SELECTING bp_file: "" >>>>> TRANSITIONING TO REQUESTING STATE >>>>> IP was: 0.0.0.0 >>>>> IP now: 192.168.0.9 >>> >>> ...worked. >>> >>>>> Bootfile: >>>>> DhcpSendRequestPkt: Sending DHCPREQUEST >>> >>> Why is the second DHCP request being sent? What is the second DHCP >>> request asking for (sniff the net with wireshark). It should be >>> asking for its current IP address (e.g. a renewal) if anything. >>> >> I think this is how it's supposed to work, but don't quote me... >> Client starts in 'Discover' state, sending a broadcast looking for >> servers. One or more servers respond with proposals. Client changes >> to 'Request' state, and sends a request. Server then has the option >> of sending an ARP to see if the IP address is already taken and >> eventually sends ACK or NAK. > > Yes, but that describes the *first* DHCP which *succeeded* (above). > The target then initiates a second DHCP (presumably with the same MAC > address and, I would presume/deduce with a lease renewal request > rather than a "gimme a new IP" request) which the server(?) bungles. > No, what you show as the first one succeeding is the result of the 'proposal' when the board enters the REQUESTING state (the call to DhcpSendrequestPkt() is in the SELECTING state prior to entering the REQUESTING state). At least that's what the code tells me. >> But why the NAK in this case? The server should recognize that it >> offered this IP address to the device with this MAC address. Maybe >> it is a timing thing like somebody saw a while ago with a Windows >> DHCP server. > > Yes, Windows is my suspicion too, our emails probably crossed in the > server. > I don't know, in this case he mentions it's a Linksys router. I think they either run Linux or VxWorks, but who knows now that Cisco owns them. >> Fun stuff... >> >> regards, >> Ben > > Makes a slow day go faster. :-) > Better than writing documentation, which I really should get to. B-) - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] PATCH for U-Boot 1.3.3 DHCP fails with netgear WGR614v6
Jerry Van Baren wrote: > Ben Warren wrote: >> Robin Getz wrote: >>> I was trying out U-Boot 1.1.3 with a new(er) router netgear WGR614v6 >>> - firmware version V2.0.19_1.0.19NA, on a Blackfin BF537-STAMP. >>> >>> http://kbserver.netgear.com/products/wgr614v6.asp >>> >>> and found that dhcp fails :( > > More correctly, the *second* DHCP request fails. > >>> bfin> dhcp >>> BOOTP broadcast 1 >>> BOOTP broadcast 2 >>> BOOTP broadcast 3 >>> BOOTP broadcast 4 >>> BOOTP broadcast 5 >>> >>> Retry count exceeded; starting again >>> >>> When turning on some more verbose debug messages (in the net driver >>> & in the network code, not all of which exists in U-Boot release or >>> trunk), we can see exactly what is going on... >>> >>> = > > First DHCP request... > >>> bfin> dhcp >>> Eth_halt: .. >>> Eth_init: .. >>> BOOTP broadcast 1 >>> setting transaction ID to 3268fe22 >>> BFIN EMAC send: length = 343 >>> BFIN EMAC rx: length = 552 >>> packet received >>> packet received >>> Receive from protocol 0x800 >>> Got IP >>> len=308, v=45 >>> passing packet len= 280 >>> DHCPHandler: got packet: (src=67, dst=68, len=280) state: 3 >>> Filtering pkt = 0 >>> DHCPHandler: got DHCP packet: (src=67, dst=68, len=280) state: 3 >>> DHCP: state=SELECTING bp_file: "" >>> TRANSITIONING TO REQUESTING STATE >>> IP was: 0.0.0.0 >>> IP now: 192.168.0.9 > > ...worked. > >>> Bootfile: >>> DhcpSendRequestPkt: Sending DHCPREQUEST > > Why is the second DHCP request being sent? What is the second DHCP > request asking for (sniff the net with wireshark). It should be > asking for its current IP address (e.g. a renewal) if anything. > I think this is how it's supposed to work, but don't quote me... Client starts in 'Discover' state, sending a broadcast looking for servers. One or more servers respond with proposals. Client changes to 'Request' state, and sends a request. Server then has the option of sending an ARP to see if the IP address is already taken and eventually sends ACK or NAK. But why the NAK in this case? The server should recognize that it offered this IP address to the device with this MAC address. Maybe it is a timing thing like somebody saw a while ago with a Windows DHCP server. Fun stuff... regards, Ben - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] PATCH for U-Boot 1.3.3 DHCP fails with netgear WGR614v6
Robin Getz wrote: > I was trying out U-Boot 1.1.3 with a new(er) router netgear WGR614v6 - > firmware version V2.0.19_1.0.19NA, on a Blackfin BF537-STAMP. > > http://kbserver.netgear.com/products/wgr614v6.asp > > and found that dhcp fails :( > > bfin> dhcp > BOOTP broadcast 1 > BOOTP broadcast 2 > BOOTP broadcast 3 > BOOTP broadcast 4 > BOOTP broadcast 5 > > Retry count exceeded; starting again > > When turning on some more verbose debug messages (in the net driver & in the > network code, not all of which exists in U-Boot release or trunk), we can see > exactly what is going on... > > = > bfin> dhcp > Eth_halt: .. > Eth_init: .. > BOOTP broadcast 1 > setting transaction ID to 3268fe22 > BFIN EMAC send: length = 343 > BFIN EMAC rx: length = 552 > packet received > packet received > Receive from protocol 0x800 > Got IP > len=308, v=45 > passing packet len= 280 > DHCPHandler: got packet: (src=67, dst=68, len=280) state: 3 > Filtering pkt = 0 > DHCPHandler: got DHCP packet: (src=67, dst=68, len=280) state: 3 > DHCP: state=SELECTING bp_file: "" > TRANSITIONING TO REQUESTING STATE > IP was: 0.0.0.0 > IP now: 192.168.0.9 > Bootfile: > DhcpSendRequestPkt: Sending DHCPREQUEST > Transmitting DHCPREQUEST packet: len = 343 > BFIN EMAC send: length = 343 > BFIN EMAC rx: length = 64 > packet received > packet received > Receive from protocol 0x806 > Got ARP > Got ARP REQUEST, for 192.168.0.9, return our MAC > BFIN EMAC send: length = 42 > BFIN EMAC rx: length = 552 > packet received > packet received > Receive from protocol 0x800 > Got IP > len=272, v=45 > passing packet len= 244 > DHCPHandler: got packet: (src=67, dst=68, len=244) state: 4 > Filtering pkt = 0 > DHCPHandler: got DHCP packet: (src=67, dst=68, len=244) state: 4 > DHCP State: REQUESTING > you just got DHCP NAKed > > === > > What is happening, is that the server offers an IP number to U-Boot > (192.168.0.9), U-Boot does a DHCPREQUEST, the server does a ARP asking > for "who has 192.168.0.9", and U-Boot responds "I do" (This is the problem). > The server then sends the requester (U-Boot) a DHCP NAK saying that someone > else on the network is already using that address. > > This seems goofy. Have you tried your fix with other DHCP servers to verify that it works? If so, which ones? I unfortunately can't try anything right now but will play around a bit tonight. regards, Ben - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH 0/1] Moved initialization of AVR32 Ethernet controllers to board_eth_init()
Hans-Christian Egtvedt wrote: > On Thu, 2008-07-10 at 14:47 +0200, Hans-Christian Egtvedt wrote: > >> On Thu, 2008-07-10 at 14:45 +0200, Hans-Christian Egtvedt wrote: >> >>> On Thu, 2008-07-10 at 13:24 +0200, Haavard Skinnemoen wrote: >>> > > > > Looks good to me, but I don't have the chance to test it. >>> I tried looking into it, but I do not see who is going to call >>> board_eth_init() ? Is this supposed to be done in net/eth.c or >>> lib_avr32/board.c ? >>> >>> >> Cheese, I am blind, just found it almost on top in the eth_initialize() >> function. >> >> I will pull the master and see if it works. >> >> > > And it works, proof below (-: (Net: did not work before pulling master) > > U-Boot 1.3.3-00248-gae9bc0c-dirty (Jul 10 2008 - 14:50:32) > > U-Boot code: -> f6b8 data: 000155c0 -> 0004bd18 > malloc: Using memory from 0x10f74000 to 0x10fb4000 > DMA: Using memory from 0x10f7 to 0x10f74000 > Flash: 8 MB at address 0x > DRAM Configuration: > Bank #0: 1000 16 MB > In:serial > Out: serial > Err: serial > Net: macb0 > Press SPACE to abort autoboot in 1 seconds > macb0: link up, 100Mbps full-duplex (lpa: 0x45e1) > BOOTP broadcast 1 > DHCP client bound to address 10.191.252.36 > Using macb0 device > TFTP from server 10.191.252.83; our IP address is 10.191.252.36 > Filename 'uimage_br_stk'. > Load address: 0x1040 > Loading: T # > ### > done > Bytes transferred = 788 (10f6ec hex) > ## Booting kernel from Legacy Image at 1040 ... >Image Name: Linux-2.6.25.10.atmel.2 >Image Type: AVR32 Linux Kernel Image (gzip compressed) >Data Size:724 Bytes = 1.1 MB >Load Address: 1000 >Entry Point: 9000 >Verifying Checksum ... OK >Uncompressing Kernel Image ... OK > > Starting kernel at 9000 (params at 10f74008)... > > Linux version 2.6.25.10.atmel.2 ([EMAIL PROTECTED]) (gcc version > 4.2.2-atmel.1.0.8) #68 Thu Jul 10 13:16:42 CEST 2008 > > Good news! Thanks, Ben - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH v2] at91: Fix to enable using Teridian MII phy (78Q21x3) with at91sam9260
Anatolij Gustschin wrote: > On the at91sam9260ep development board there is an EEPROM > connected to the TWI interface (PA23, PA24 Peripheral A > multiplexing), so we cannot use these pins as ETX2, ETX3. > This patch configures PA10, PA11 pins for ETX2, ETX3 > instead of PA23, PA24 pins. > > Signed-off-by: Anatolij Gustschin <[EMAIL PROTECTED]> > Signed-off-by: Manuel Sahm <[EMAIL PROTECTED]> > --- > board/atmel/at91sam9260ek/at91sam9260ek.c |9 + > 1 files changed, 9 insertions(+), 0 deletions(-) > > diff --git a/board/atmel/at91sam9260ek/at91sam9260ek.c > b/board/atmel/at91sam9260ek/at91sam9260ek.c > index 836a0c4..06d8512 100644 > --- a/board/atmel/at91sam9260ek/at91sam9260ek.c > +++ b/board/atmel/at91sam9260ek/at91sam9260ek.c > @@ -188,8 +188,17 @@ static void at91sam9260ek_macb_hw_init(void) > at91_set_B_periph(AT91_PIN_PA25, 0);/* ERX2 */ > at91_set_B_periph(AT91_PIN_PA26, 0);/* ERX3 */ > at91_set_B_periph(AT91_PIN_PA27, 0);/* ERXCK */ > +#if defined(CONFIG_AT91SAM9260EK) > There's a weakness in your software architecture if there are two compile paths in 'at91sam9260ek.c': one that has CONFIG_AT91SAM9260EK and one that doesn't. Maybe time for a new board variant or some file re-naming? regards, Ben - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] e1000: add support for 82545GM 64bit PCI-X copper variant
Wolfgang Denk wrote: > In message <[EMAIL PROTECTED]> you wrote: > >> This PCI-X e1000 variant works by just adding in the correct >> PCI IDs in the appropriate places. >> >> Signed-off-by: Paul Gortmaker <[EMAIL PROTECTED]> >> --- >> drivers/net/e1000.c |2 ++ >> drivers/net/e1000.h |3 ++- >> include/pci_ids.h |1 + >> 3 files changed, 5 insertions(+), 1 deletions(-) >> > > Applied, thanks. > > Ben, this was so straightforward that I applied it directly. Hope this > is OK. > That's cool. I acked it in my head :) and was going to sanity-check applying it tonight. regards, Ben - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH 3/6] sbc8560: define eth0 and eth1 instead of eth1 and eth2
Hi Paul, Paul Gortmaker wrote: > Ben Warren wrote: >> Paul Gortmaker wrote: >>> The existing config doesn't define CONFIG_HAS_ETH0, and so the >>> fdt support doesn't update the zeros in the dtb local-mac with >>> real data from the u-boot env. Since the existing config is >>> tailored to just two interfaces, get rid of the ETH2 definitions >>> at the same time. >>> --- >>> include/configs/sbc8560.h |3 +-- >>> 1 files changed, 1 insertions(+), 2 deletions(-) >>> >>> diff --git a/include/configs/sbc8560.h b/include/configs/sbc8560.h >>> index f07fbc0..e5195e0 100644 >>> --- a/include/configs/sbc8560.h >>> +++ b/include/configs/sbc8560.h >>> @@ -407,11 +407,10 @@ >>> >>> /*Note: change below for your network setting!!! */ >>> #if defined(CONFIG_TSEC_ENET) || defined(CONFIG_ETHER_ON_FCC) >>> +# define CONFIG_HAS_ETH0 >>> # define CONFIG_ETHADDR00:01:af:07:9b:8a >>> # define CONFIG_HAS_ETH1 >>> # define CONFIG_ETH1ADDR00:01:af:07:9b:8b >>> -# define CONFIG_HAS_ETH2 >>> -# define CONFIG_ETH2ADDR00:01:af:07:9b:8c >>> #endif >>> >>> #define CONFIG_SERVERIP192.168.0.131 >>> >> Please get rid of all default network parameters while you're at it >> (MAC addresses, IP addresses etc.) > > Is there a set list of which things are considered OK and > which are ones that folks would rather not see? A quick > snoop around shows lots of other boards doing the 192.168.x.y > type stuff and default MAC addresses and similar. > Of course there's no list. That would take all of the fun out of subjective reviewing! Essentially, anything that is specific to one particular network should not be defaulted. For MAC addresses, it's cut-and-dry - the values you're using were paid for by some entity (maybe Wind River, maybe somebody else that you cut'n'pasted from, I don't know) and the contract with the IEEE states that each number will be used only once and documented by the owner. For higher-layer things like IP addresses it's more a matter of convenience. While you may use 192.168.x.y in your lab, there's no guarantee that the buyers of your boards will, so why default it at all? As to precedence, you won't find any recent additions with these things. I don't know if we'll ever remove the code that uses CONFIG_ETHADDR and friends, but you should make the assumption that it will go. > I'm fine with doing a cleanup; I just don't want to do it twice, > and I'd rather it be consistent across all the boards as well. I understand, and have no interest in adding ambiguity. regards, Ben - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH 3/6] sbc8560: define eth0 and eth1 instead of eth1 and eth2
Paul Gortmaker wrote: > The existing config doesn't define CONFIG_HAS_ETH0, and so the > fdt support doesn't update the zeros in the dtb local-mac with > real data from the u-boot env. Since the existing config is > tailored to just two interfaces, get rid of the ETH2 definitions > at the same time. > --- > include/configs/sbc8560.h |3 +-- > 1 files changed, 1 insertions(+), 2 deletions(-) > > diff --git a/include/configs/sbc8560.h b/include/configs/sbc8560.h > index f07fbc0..e5195e0 100644 > --- a/include/configs/sbc8560.h > +++ b/include/configs/sbc8560.h > @@ -407,11 +407,10 @@ > > /*Note: change below for your network setting!!! */ > #if defined(CONFIG_TSEC_ENET) || defined(CONFIG_ETHER_ON_FCC) > +# define CONFIG_HAS_ETH0 > # define CONFIG_ETHADDR 00:01:af:07:9b:8a > # define CONFIG_HAS_ETH1 > # define CONFIG_ETH1ADDR00:01:af:07:9b:8b > -# define CONFIG_HAS_ETH2 > -# define CONFIG_ETH2ADDR00:01:af:07:9b:8c > #endif > > #define CONFIG_SERVERIP 192.168.0.131 > Please get rid of all default network parameters while you're at it (MAC addresses, IP addresses etc.) regards, Ben - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH 1/6] sbc8560: proper definitions for TSEC.
Paul Gortmaker wrote: > The definitions for the TSEC have become out of date. There is no > longer any such options like "CONFIG_MPC85xx_TSEC1" or similar. > Update to match those of other boards, like the MPC8560ADS. > --- > You forgot your signed-off-by. When you resubmit, add: Acked-by: Ben Warren <[EMAIL PROTECTED]> > include/configs/sbc8560.h | 32 ++-- > 1 files changed, 22 insertions(+), 10 deletions(-) > > diff --git a/include/configs/sbc8560.h b/include/configs/sbc8560.h > index 146eafe..f07fbc0 100644 > --- a/include/configs/sbc8560.h > +++ b/include/configs/sbc8560.h > @@ -215,16 +215,28 @@ > #define CFG_PCI_MEM_PHYS 0xC000 > #define CFG_PCI_MEM_SIZE 0x1000 > > -#if defined(CONFIG_TSEC_ENET)/* TSEC Ethernet port */ > - > -# define CONFIG_NET_MULTI 1 > -# define CONFIG_MII 1 /* MII PHY management */ > -# define CONFIG_MPC85xx_TSEC1 > -# define CONFIG_MPC85xx_TSEC1_NAME "TSEC0" > -# define TSEC1_PHY_ADDR 25 > -# define TSEC1_PHYIDX 0 > -/* Options are: TSEC0 */ > -# define CONFIG_ETHPRIME"TSEC0" > +#ifdef CONFIG_TSEC_ENET > + > +#ifndef CONFIG_NET_MULTI > +#define CONFIG_NET_MULTI 1 > +#endif > + > +#ifndef CONFIG_MII > +#define CONFIG_MII 1 /* MII PHY management */ > +#endif > +#define CONFIG_TSEC1 1 > +#define CONFIG_TSEC1_NAME"TSEC0" > +#define CONFIG_TSEC2 1 > +#define CONFIG_TSEC2_NAME"TSEC1" > +#define TSEC1_PHY_ADDR 0x19 > +#define TSEC2_PHY_ADDR 0x1a > +#define TSEC1_PHYIDX 0 > +#define TSEC2_PHYIDX 0 > +#define TSEC1_FLAGS TSEC_GIGABIT > +#define TSEC2_FLAGS TSEC_GIGABIT > + > +/* Options are: TSEC[0-1] */ > +#define CONFIG_ETHPRIME "TSEC0" > > #elif defined(CONFIG_ETHER_ON_FCC) /* CPM FCC Ethernet */ > > - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH 0/1] Moved initialization of GRETH Ethernet driver to CPU directory
F On Wed, Jul 9, 2008 at 5:03 AM, Daniel Hellstrom <[EMAIL PROTECTED]> wrote: > Hello Ben, > > I have tried the testing branch of the net repo > (99b85ffa8ef0b07904be1db335825d4d83424eaa) on a GR-XC3S-1500 LEON3 board > successfully. > > LEON2 U-Boot support is limited to the LEON2 simmulator TSIM, TSIM-LEON2 > does not support the GRETH so at this stage it is not neccessary for LEON2 > to check CONFIG_GRETH. However, it might be useful later on. > Thanks a lot for testing this so quickly! regards, Ben - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [PATCH 1/1] Moved initialization of GRETH Ethernet driver to CPU directory
Added a cpu_eth_init() function to leon2/leon3 CPU directories and
removed code from net/eth.c
Signed-off-by: Ben Warren <[EMAIL PROTECTED]>
---
cpu/leon2/cpu.c |9 +
cpu/leon3/cpu.c |8
drivers/net/greth.c |2 +-
net/eth.c |4
4 files changed, 18 insertions(+), 5 deletions(-)
diff --git a/cpu/leon2/cpu.c b/cpu/leon2/cpu.c
index 1c1e24b..5de1c52 100644
--- a/cpu/leon2/cpu.c
+++ b/cpu/leon2/cpu.c
@@ -56,3 +56,12 @@ int do_reset(cmd_tbl_t * cmdtp, int flag, int argc, char
*argv[])
}
/* - */
+
+extern int greth_initialize(bd_t *bis);
+
+#ifdef CONFIG_GRETH
+int cpu_eth_init(bd_t *bis)
+{
+ return greth_initialize(bis);
+}
+#endif
diff --git a/cpu/leon3/cpu.c b/cpu/leon3/cpu.c
index 306a210..1725fdb 100644
--- a/cpu/leon3/cpu.c
+++ b/cpu/leon3/cpu.c
@@ -65,3 +65,11 @@ u64 flash_read64(void *addr)
}
/* - */
+extern int greth_initialize(bd_t *bis);
+
+#ifdef CONFIG_GRETH
+int cpu_eth_init(bd_t *bis)
+{
+ return greth_initialize(bis);
+}
+#endif
diff --git a/drivers/net/greth.c b/drivers/net/greth.c
index 76ece59..90c5338 100644
--- a/drivers/net/greth.c
+++ b/drivers/net/greth.c
@@ -657,5 +657,5 @@ int greth_initialize(bd_t * bis)
/* set and remember MAC address */
greth_set_hwaddr(greth, addr);
- return 1;
+ return 0;
}
diff --git a/net/eth.c b/net/eth.c
index 132efce..3c152bf 100644
--- a/net/eth.c
+++ b/net/eth.c
@@ -69,7 +69,6 @@ extern int uli526x_initialize(bd_t *);
extern int npe_initialize(bd_t *);
extern int uec_initialize(int);
extern int bfin_EMAC_initialize(bd_t *);
-extern int greth_initialize(bd_t *);
extern int at91sam9_eth_initialize(bd_t *);
#ifdef CONFIG_API
@@ -267,9 +266,6 @@ int eth_initialize(bd_t *bis)
#if defined(CONFIG_BF537)
bfin_EMAC_initialize(bis);
#endif
-#if defined(CONFIG_GRETH)
- greth_initialize(bis);
-#endif
#if defined(CONFIG_AT91CAP9) || defined(CONFIG_AT91SAM9260) || \
defined(CONFIG_AT91SAM9263)
at91sam9_eth_initialize(bis);
--
1.5.4.3
-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [PATCH 0/1] Moved initialization of GRETH Ethernet driver to CPU directory
Hello, More cleanup of net/eth.c, this time taking care of LEON2/LEON3 boards. Lacking a compiler and target, I can't really test this so hopefully somebody can and will report back. This patch is being staged in the 'testing' branch of the net repo. regards, Ben - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] No ethernet link on Lubbock board.
Victor wrote: > This is a problem I've been fighting to for a long time. I'm sure it > would be something stupid I haven't noticed, but I don't know what > else to try. My Linux OS is working flawlessly with a correct eth0 > device, so at least I know it's not (or should not) a hardware > problem. > > No, it looks like the driver has some badly circular logic > Everything else works as expected, but the LAN91C96 driver does not > enable the board network interface. > > So even after the message "Using MAC Address 00:02:b3:00:8f:xx" (assuming "xx" is really "01" or something real) it doesn't work? I think it should. > Environment: > Hardware: Lubbock Board from Intel, wired to an IBM Laptop. > U-boot version: 1.3.3 (tried with 1.3.1, 1.20, same results) > mac address: tried with the one generated by the eth_gen_tool, and the > original hardware one. > Default 'lubbock.h' file, heavy edited one, etc... No luck. > > $ printenv: > U-Boot 1.3.3 (Jul 8 2008 - 19:07:01) > > DRAM: 64 MB > Flash: 64 MB > Hit any key to stop autoboot: 0 > $ printenv > baudrate=115200 > netmask=255.255.0.0 > bootdelay=5 > serverip=192.168.1.1 > ipaddr=192.168.1.2 > bootcmd=bootm 20 > bootargs=ip=192.168.1.2:192.168.1.1:192.168.1.1:255.255.255.0:pxa:eth0:off > mem=64M root=/dev/nfs nfsroot=192.168.1.1:/rootfs/nfs init=/sbin/init > console=ttyS0,115200 > ethaddr=00:02:b3:00:8f:xx > stdin=serial > stdout=serial > stderr=serial > > Something odd I noticed: > > $ tftpboot > > Warning: MAC addresses don't match: > HW MAC address: 01:00:01:00:01:00 > "ethaddr" value: 00:02:B3:00:8F:xx > Using MAC Address 00:02:B3:00:8F:xx > > Linux detects the correct Mac Address without any configuration, why > u-boot reads 01:00:01:00:01:00? > > Probably the number that's initialized in the device. It's a bogus MAC address, but you're really reading uninitialized data. The problem is this: tftpboot calls smc_open(), which calls smc_get_ethaddr(), which in turn reads the environment and reads the MAC address registers in the device, comparing them. It then writes the appropriate MAC address to the device's address registers... See the problem? the device's registers aren't non-volatile. What you really want to do is read only from the environment and program the device with that value. The problem really stems from the fact that get_rom_mac() always returns 1. If I had time and hardware I'd help fix this. I would think that things should work as-is, though, and that you should be able to just ignore the warning. Sorry if this is confusing. regards, Ben - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH 0/2] Coldfire Ethernet initialization changes
Liew Tsi Chung wrote: > Ben, > > >>> -#if defined(CONFIG_FSLDMAFEC) >>> +#if defined(CONFIG_FSLDMAFEC) || #if defined(CONFIG_MCFFEC) >>> +/* Default initializations for MCFFEC controllers. To override, >>> + * create a board-specific function called: >>> + * int board_eth_init(bd_t *bis) >>> + */ >>> + >>> extern int mcdmafec_initialize(bd_t *bis); >>> +extern int mcffec_initialize(bd_t*); >>> >>> > > >> Does it work after you fix this up? >> > Yes. > Great! Thanks for checking it out. I'll update the repo tonight. regards, Ben - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] PHY lib
Hi Michal, Michal Simek wrote: > Hi Ben, > > >> Hi Michal, >> >> Michal Simek wrote: >> >>> Hi Ben and others, >>> >>> do you have any plan to start with PHY libs? >>> I saw to tsec driver - there are some phy description. >>> I would like to use phy description for one eth driver which I do. >>> >>> >>> >> I'm finally finding time to work on refactoring U-boot's networking >> support, one of the parts of which is a proper PHY library. For several >> reasons, it pulls a lot from the TSEC driver. Cutting and pasting the >> PHY descriptions from TSEC is probably a good idea (in as much as >> cutting and pasting is a good idea :)). >> > > That's great. What next changes do you plan? > Thanks for information. > > So many things... Here are what I see as the low-hanging fruit: 1. Move all ethernet initializations into cpu_eth_init()/board_eth_init(). You can see this is underway. 2. Get rid of the CONFIG_NET_MULTI option. The trick here is to keep the code size of single-controller boards as small as possible. 3. PHY library. With these implemented, I think we can start to look at more interesting problems. Feel free to brainstorm here! regards, Ben - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH 0/2] Coldfire Ethernet initialization changes
Liew Tsi Chung wrote: > Ben, > > >> I'm pushing these patches to a 'testing' branch on the net repo. >> > Please clone it as follows: > >> $ git clone git://git.denx.de/u-boot-net.git $ cd u-boot-net $ git >> > checkout testing > There is no testing branch in u-boot-net, so I applied the two patches > you sent on top of current u-boot-net tree (commit > 63676841ca2d603b13765f3f7b72ff1a61c23f90 - Jun 18. Remove duplicate code > in cpu/arm926ejs/davinci/lxt972.c). > > There is a testing branch in the repo: http://git.denx.de/?p=u-boot/u-boot-net.git;a=shortlog;h=refs/heads/testing I just don't know how to use git properly... > Only one conflict and error: > The first patch - CONFIG_FSLDMAFEC for 547x_8x and is correct. > Then, the second patch - CONFIG_MCFFEC, appended #if after ||, either > remove CONFIG_MCFFEC for 547x_8x or remove "#if ". > > Oh yeah, duh! I need to free up some space on my hard drive so I can have more tools... > -#if defined(CONFIG_FSLDMAFEC) > +#if defined(CONFIG_FSLDMAFEC) || #if defined(CONFIG_MCFFEC) > +/* Default initializations for MCFFEC controllers. To override, > + * create a board-specific function called: > + * int board_eth_init(bd_t *bis) > + */ > + > extern int mcdmafec_initialize(bd_t *bis); > +extern int mcffec_initialize(bd_t*); > Does it work after you fix this up? thanks a lot! Ben - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] PHY lib
Hi Michal, Michal Simek wrote: > Hi Ben and others, > > do you have any plan to start with PHY libs? > I saw to tsec driver - there are some phy description. > I would like to use phy description for one eth driver which I do. > > I'm finally finding time to work on refactoring U-boot's networking support, one of the parts of which is a proper PHY library. For several reasons, it pulls a lot from the TSEC driver. Cutting and pasting the PHY descriptions from TSEC is probably a good idea (in as much as cutting and pasting is a good idea :)). regards, Ben - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] Pull request - net
Wolfgang, The following changes since commit 914f58c5766860373a7d232e961cee5a4b54a55b: Wolfgang Denk (1): Merge branch 'master' of git://www.denx.de/git/u-boot-cfi-flash are available in the git repository at: git://git.denx.de/u-boot-net.git master Ben Warren (1): Add mechanisms for CPU and board-specific Ethernet initialization Hugo Villeneuve (2): Remove duplicate definitions in include/lxt971a.h. Remove duplicate code in cpu/arm926ejs/davinci/lxt972.c. Nobuhiro Iwamatsu (3): net: ne2000: Fix compile error of NE2000 net: ne2000: Move dev_addr variable from grobal to local. net: sh: Renesas SH7763 Ethernet device support cpu/arm920t/at91rm9200/lxt972.c | 15 +- cpu/arm926ejs/davinci/lxt972.c | 54 ++--- cpu/mpc83xx/cpu.c | 20 ++ cpu/mpc85xx/cpu.c | 30 ++ cpu/mpc86xx/cpu.c | 27 ++ drivers/net/Makefile|1 + drivers/net/ne2000.c| 14 +- drivers/net/ns7520_eth.c| 42 ++-- drivers/net/ns9750_eth.c| 59 ++-- drivers/net/sh_eth.c| 603 +++ drivers/net/sh_eth.h| 446 + include/lxt971a.h | 100 --- include/ns7520_eth.h|1 + include/ns9750_eth.h|1 + net/eth.c | 32 +-- 15 files changed, 1224 insertions(+), 221 deletions(-) create mode 100644 drivers/net/sh_eth.c create mode 100644 drivers/net/sh_eth.h regards, Ben - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH 2/2] Remove duplicate code in cpu/arm926ejs/davinci/lxt972.c.
Hugo Villeneuve wrote: > Remove duplicate code in cpu/arm926ejs/davinci/lxt972.c. > > Remove duplicate code in a if/else block in > cpu/arm926ejs/davinci/lxt972.c. > Fixed style issues. > > Signed-off-by: Hugo Villeneuve <[EMAIL PROTECTED]> > Applied to net repo. thanks, Ben - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH 1/2] Remove duplicate definitions in include/lxt971a.h.
Hugo Villeneuve wrote: > Remove duplicate definitions in include/lxt971a.h. > > Remove duplicate registers and bits definitions in > include/lxt971a.h for standard MII registers, and > use values in include/miiphy.h instead. > > Signed-off-by: Hugo Villeneuve <[EMAIL PROTECTED]> > > Applied to net repo. thanks, Ben - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH v2] net: sh: Renesas SH7763 Ethernet device support
Nobuhiro Iwamatsu wrote: > Renesas SH7763 has 2 channel Ethernet device. > This is 10/100/1000 Base support. > But this patch check 10/100 Base only. > > Signed-off-by: Nobuhiro Iwamatsu <[EMAIL PROTECTED]> > Applied to net repo. thanks, Ben - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Release status - things to be done
Nobuhiro Iwamatsu wrote: > Hi Ben. > > 2008/7/6 Ben Warren <[EMAIL PROTECTED]>: > > >>> 3645 06/11 Nobuhiro Iwamatsu [U-Boot-Users] [PATCH v2] net: sh: Renesas >>> SH7763 Ethernet device support >>>-> for net custodian >>> >>> >>> >> Didn't pick this up because it was after what I thought was the cut-off of >> 6/10. It still has issues, so I'll ask NobuHiro to re-submit. Should it go >> in this release when OK? >> >> > II reflected your comment as this and contributed it again. > Could you apply this patch? > > Best regards, > Nobuhiro > > Yes you did re-submit based on an original set of change requests, but that doesn't mean you've received final comments :) I don't like new drivers to use the old API (eth_init(), eth_send() etc.) but at the same time realize it's not nice to make you have to add the CONFIG_NET_MULTI to board configs that only have one interface. So, for now let's bring this patch in we'll address the bigger issues later on. I'll send a separate message. regards, Ben - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Release status - things to be done
Hi Wolfgang, Wolfgang Denk wrote: > Hi everybody, > > here is a summary of the current state of my processing of patches > that have been submitted for the upcoming 1.3.4 release. > > As you might have noticed, I've been on vacation for the last two > weeks, and I spent this time (intentionally) completely offline. So > please apologize if parts of the following comments / questions have > been obsoleted by recent events - I will try to catch up as soon as > possible, but I think it is better to send out this summary now, > i. e. _before_ I start reading he backlog of the last two weeks. > > > Here is a list of patches I had marked as open in my list, with > comments about their state, including comments who I consider to be > responsible for further progress: > > > 3645 06/11 Nobuhiro Iwamatsu [U-Boot-Users] [PATCH v2] net: sh: Renesas > SH7763 Ethernet device support > -> for net custodian > > Didn't pick this up because it was after what I thought was the cut-off of 6/10. It still has issues, so I'll ask NobuHiro to re-submit. Should it go in this release when OK? > 3812 06/13 Ben Warren [PATCH V4] Add mechanisms for CPU and > board-specific Ethernet initialization > -> for net custodian. > > Again, thought it was too late. I'll send a pull request soon that will include this one. > 3901 06/17 Nobuhiro Iwamatsu [U-Boot-Users] [PATCH] net: ne2000: Move > dev_addr variable from grobal to local. > 3902 06/17 Nobuhiro Iwamatsu [U-Boot-Users] [PATCH] net: ne2000: Fix > compile error of NE2000 > -> for net custodian > > These are good ones, and will be in my pull request. Same deal with the date. > 3984 06/18 Hugo Villeneuve[U-Boot-Users] [PATCH 1/2] Remove duplicate > definitions in include/lxt971a.h. > 3985 06/18 Hugo Villeneuve[U-Boot-Users] [PATCH 2/2] Remove duplicate > code in cpu/arm926ejs/davinci/lxt972.c. > -> for net custodian > > Missed these completely, since no clues in title about networking... regards, Ben - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH v2] net: Conditional COBJS inclusion of network drivers
Hi Wolfgang, welcome back... Wolfgang Denk wrote: > In message <[EMAIL PROTECTED]> you wrote: > >> Replace COBJS-y with appropriate driver config names. >> >> Signed-off-by: Shinya Kuribayashi <[EMAIL PROTECTED]> >> --- >> >> Changes v2: >> >> * Kill more CONFIG_CMD_NET and CONFIG_NET_MULTI defines from >>- fsl_mcdmafec.c >>- mcffec.c >>- netarm_eth.c >> >> * Revised DM9000 part against the net repo. >> > > Hm... Are you absolutely sure your changes, especially the > CONFIG_CMD_NET and even more the CONFIG_NET_MULTI related ones, do not > cause any trouble on any systems? > > Let's for example check the E1000 network driver. with your changes, > it will be built (and enabled), if... > > ... > >> +COBJS-$(CONFIG_E1000) += e1000.o >> > ... > > ... if CONFIG_E1000 is set. > > However, the old code: > > ... > >> -#if defined(CONFIG_CMD_NET) \ >> -&& defined(CONFIG_NET_MULTI) && defined(CONFIG_E1000) >> - >> > > ...*also* required that CONFIG_CMD_NET *AND* CONFIG_NET_MULTI were > set, too. > > [For the E1000 driver this is easy to verify, as only few boards > enable this option, but you are changing this for many drivers, so it > affects many boards...] > > > It seems not obvious to me that your change is really harmless, or > tested. > > Could you please comment? > > [Note that I like your patch and would like to apply it (or ask Ben > to do that), but it seems kind of risly to me...] > > I decided to accept this and push it upstream because it's definitely a step in the right direction. Addressing your concerns, for any driver: if CONFIG_CMD_NET isn't defined, networking isn't enabled, and at worst your image is bigger than necessary because of libnet.a if CONFIG_NET_MULTI isn't defined, but CONFIG_CMD_NET is, networking will use the 'old-school' API and if the driver doesn't export eth_init() etc., you'll get a compile error. So, IMHO the worst case scenario is a bit of code bloat or compile error, which aren't disastrous. Run-time errors bad, compile-time, not so much. Personally, I want to merge the two networking APIs so this MULTI business goes away. Baby steps are necessary here. > Best regards, > > Wolfgang Denk > > regards, Ben - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [PATCH 1/1] Moved initialization of AVR32 Ethernet controllers to board_eth_init()
Renamed initialization functions for atngw100 and atstk1000.
Removed initializations for these boards from net/eth.c
Signed-off-by: Ben Warren <[EMAIL PROTECTED]>
---
board/atmel/atngw100/Makefile |2 +-
board/atmel/atngw100/atngw100.c | 11 ++
board/atmel/atngw100/eth.c| 36 ---
board/atmel/atstk1000/Makefile|2 +-
board/atmel/atstk1000/atstk1000.c | 11 ++
board/atmel/atstk1000/eth.c | 38 -
net/eth.c |8 ---
7 files changed, 24 insertions(+), 84 deletions(-)
delete mode 100644 board/atmel/atngw100/eth.c
delete mode 100644 board/atmel/atstk1000/eth.c
diff --git a/board/atmel/atngw100/Makefile b/board/atmel/atngw100/Makefile
index 1b5c635..9f3849f 100644
--- a/board/atmel/atngw100/Makefile
+++ b/board/atmel/atngw100/Makefile
@@ -22,7 +22,7 @@ include $(TOPDIR)/config.mk
LIB:= $(obj)lib$(BOARD).a
-COBJS := $(BOARD).o eth.o
+COBJS := $(BOARD).o
SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
OBJS := $(addprefix $(obj),$(SOBJS) $(COBJS))
diff --git a/board/atmel/atngw100/atngw100.c b/board/atmel/atngw100/atngw100.c
index 375f0e7..caf33f0 100644
--- a/board/atmel/atngw100/atngw100.c
+++ b/board/atmel/atngw100/atngw100.c
@@ -89,3 +89,14 @@ void board_init_info(void)
gd->bd->bi_phy_id[0] = 0x01;
gd->bd->bi_phy_id[1] = 0x03;
}
+
+extern int macb_eth_initialize(int id, void *regs, unsigned int phy_addr);
+
+#ifdef CONFIG_CMD_NET
+int board_eth_init(bd_t *bi)
+{
+ macb_eth_initialize(0, (void *)MACB0_BASE, bi->bi_phy_id[0]);
+ macb_eth_initialize(1, (void *)MACB1_BASE, bi->bi_phy_id[1]);
+ return 0;
+}
+#endif
diff --git a/board/atmel/atngw100/eth.c b/board/atmel/atngw100/eth.c
deleted file mode 100644
index d1d57bb..000
--- a/board/atmel/atngw100/eth.c
+++ /dev/null
@@ -1,36 +0,0 @@
-/*
- * Copyright (C) 2006 Atmel Corporation
- *
- * Ethernet initialization for the AVR32 Network Gateway
- *
- * 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
-
-#include
-
-extern int macb_eth_initialize(int id, void *regs, unsigned int phy_addr);
-
-#ifdef CONFIG_CMD_NET
-void atngw100_eth_initialize(bd_t *bi)
-{
- macb_eth_initialize(0, (void *)MACB0_BASE, bi->bi_phy_id[0]);
- macb_eth_initialize(1, (void *)MACB1_BASE, bi->bi_phy_id[1]);
-}
-#endif
diff --git a/board/atmel/atstk1000/Makefile b/board/atmel/atstk1000/Makefile
index 8a15713..155d46a 100644
--- a/board/atmel/atstk1000/Makefile
+++ b/board/atmel/atstk1000/Makefile
@@ -26,7 +26,7 @@ include $(TOPDIR)/config.mk
LIB:= $(obj)lib$(BOARD).a
-COBJS := $(BOARD).o flash.o eth.o
+COBJS := $(BOARD).o flash.o
SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
OBJS := $(addprefix $(obj),$(SOBJS) $(COBJS))
diff --git a/board/atmel/atstk1000/atstk1000.c
b/board/atmel/atstk1000/atstk1000.c
index 6371e2d..496c6a8 100644
--- a/board/atmel/atstk1000/atstk1000.c
+++ b/board/atmel/atstk1000/atstk1000.c
@@ -115,3 +115,14 @@ void board_init_info(void)
gd->bd->bi_phy_id[0] = 0x10;
gd->bd->bi_phy_id[1] = 0x11;
}
+
+extern int macb_eth_initialize(int id, void *regs, unsigned int phy_addr);
+
+#ifdef CONFIG_CMD_NET
+int board_eth_init(bd_t *bi)
+{
+ macb_eth_initialize(0, (void *)MACB0_BASE, bi->bi_phy_id[0]);
+ macb_eth_initialize(1, (void *)MACB1_BASE, bi->bi_phy_id[1]);
+ return 0;
+}
+#endif
diff --git a/board/atmel/atstk1000/eth.c b/board/atmel/atstk1000/eth.c
deleted file mode 100644
index b2b1a12..000
--- a/board/atmel/atstk1000/eth.c
+++ /dev/null
@@ -1,38 +0,0 @@
-/*
- * Copyright (C) 2005-2006 Atmel Corporation
- *
- * Ethernet initialization for the ATSTK1000 starterkit
- *
- * 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
[U-Boot-Users] [PATCH 0/1] Moved initialization of AVR32 Ethernet controllers to board_eth_init()
Hello, More cleanup of net/eth.c, this time taking care of AVR32 boards. I got rid of the board/eth.c files because board_eth_init() needs to be in a file where there are other strong symbols in order to override the weak board_eth_init() in net/eth.c. I've compiled this code and verified that the strong board_eth_init() symbols are linked in, but don't have hardware to test on. If somebody can, please try out and let me know. These patches are being staged in the 'testing' branch of the net repo. regards, Ben - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH 0/2] Coldfire Ethernet initialization changes
Liew Tsi Chung wrote: > Ben, > > I am going to test them and let you know next Tuesday. I was > unable to download the net repo using git protocol at work and the http > protocol has index error when I tried to use git-clone. > > Wonderful. Thanks! Ben - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] net: smc911x: sh: Add support RSK7203 board to smc911x
Hi Nobuhiro, Nobuhiro Iwamatsu wrote: > The RSK board has the SMSC9118 wired up 'incorrectly'. > This problem can support in the software side. > I put a code to evade it. > > Putting a board fix in a common driver is not cool. Please provide more generic word-swapping versions of reg_read and reg_write, or something else like that. regards, Ben - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [PATCH 2/2] Moved initialization of MCFFEC Ethernet driver to CPU directory
Added a cpu_eth_init() function to coldfire CPU directories and
removed code from net/eth.c
Signed-off-by: Ben Warren <[EMAIL PROTECTED]>
---
cpu/mcf523x/cpu.c| 14 ++
cpu/mcf52x2/cpu.c| 15 +++
cpu/mcf532x/cpu.c| 14 ++
cpu/mcf5445x/cpu.c | 14 ++
cpu/mcf547x_8x/cpu.c | 16 ++--
drivers/net/mcffec.c |2 +-
net/eth.c|4
7 files changed, 72 insertions(+), 7 deletions(-)
diff --git a/cpu/mcf523x/cpu.c b/cpu/mcf523x/cpu.c
index f0d954b..8d2152d 100644
--- a/cpu/mcf523x/cpu.c
+++ b/cpu/mcf523x/cpu.c
@@ -107,3 +107,17 @@ int watchdog_init(void)
return (0);
}
#endif /* CONFIG_WATCHDOG */
+
+#if defined(CONFIG_MCFFEC)
+/* Default initializations for MCFFEC controllers. To override,
+ * create a board-specific function called:
+ * int board_eth_init(bd_t *bis)
+ */
+
+extern int mcffec_initialize(bd_t*);
+
+int cpu_eth_init(bd_t *bis)
+{
+ return mcffec_initialize(bis);
+}
+#endif
diff --git a/cpu/mcf52x2/cpu.c b/cpu/mcf52x2/cpu.c
index d5d3d33..2af31cb 100644
--- a/cpu/mcf52x2/cpu.c
+++ b/cpu/mcf52x2/cpu.c
@@ -321,3 +321,18 @@ int do_reset(cmd_tbl_t * cmdtp, bd_t * bd, int flag, int
argc, char *argv[])
return 0;
};
#endif
+
+#if defined(CONFIG_MCFFEC)
+/* Default initializations for MCFFEC controllers. To override,
+ * create a board-specific function called:
+ * int board_eth_init(bd_t *bis)
+ */
+
+extern int mcffec_initialize(bd_t*);
+
+int cpu_eth_init(bd_t *bis)
+{
+ return mcffec_initialize(bis);
+}
+#endif
+
diff --git a/cpu/mcf532x/cpu.c b/cpu/mcf532x/cpu.c
index 61541ab..20d0d5c 100644
--- a/cpu/mcf532x/cpu.c
+++ b/cpu/mcf532x/cpu.c
@@ -129,3 +129,17 @@ int watchdog_init(void)
return (0);
}
#endif /* CONFIG_WATCHDOG */
+
+#if defined(CONFIG_MCFFEC)
+/* Default initializations for MCFFEC controllers. To override,
+ * create a board-specific function called:
+ * int board_eth_init(bd_t *bis)
+ */
+
+extern int mcffec_initialize(bd_t*);
+
+int cpu_eth_init(bd_t *bis)
+{
+ return mcffec_initialize(bis);
+}
+#endif
diff --git a/cpu/mcf5445x/cpu.c b/cpu/mcf5445x/cpu.c
index e601b89..ab342dd 100644
--- a/cpu/mcf5445x/cpu.c
+++ b/cpu/mcf5445x/cpu.c
@@ -95,3 +95,17 @@ int checkcpu(void)
return 0;
}
+
+#if defined(CONFIG_MCFFEC)
+/* Default initializations for MCFFEC controllers. To override,
+ * create a board-specific function called:
+ * int board_eth_init(bd_t *bis)
+ */
+
+extern int mcffec_initialize(bd_t*);
+
+int cpu_eth_init(bd_t *bis)
+{
+ return mcffec_initialize(bis);
+}
+#endif
diff --git a/cpu/mcf547x_8x/cpu.c b/cpu/mcf547x_8x/cpu.c
index e29b45c..4a04b7f 100644
--- a/cpu/mcf547x_8x/cpu.c
+++ b/cpu/mcf547x_8x/cpu.c
@@ -142,11 +142,23 @@ int watchdog_init(void)
}
#endif /* CONFIG_HW_WATCHDOG */
-#if defined(CONFIG_FSLDMAFEC)
+#if defined(CONFIG_FSLDMAFEC) || #if defined(CONFIG_MCFFEC)
+/* Default initializations for MCFFEC controllers. To override,
+ * create a board-specific function called:
+ * int board_eth_init(bd_t *bis)
+ */
+
extern int mcdmafec_initialize(bd_t *bis);
+extern int mcffec_initialize(bd_t*);
int cpu_eth_init(bd_t *bis)
{
- return mcdmafec_initialize(bis);
+#if defined(CONFIG_FSLDMAFEC)
+ mcdmafec_initialize(bis);
+#endif
+#if defined(CONFIG_MCFFEC)
+ mcffec_initialize(bis);
+#endif
+ return 0;
}
#endif
diff --git a/drivers/net/mcffec.c b/drivers/net/mcffec.c
index 58ed5e3..6e69b46 100644
--- a/drivers/net/mcffec.c
+++ b/drivers/net/mcffec.c
@@ -599,5 +599,5 @@ int mcffec_initialize(bd_t * bis)
/* default speed */
bis->bi_ethspeed = 10;
- return 1;
+ return 0;
}
diff --git a/net/eth.c b/net/eth.c
index 40bbed4..bc74f47 100644
--- a/net/eth.c
+++ b/net/eth.c
@@ -72,7 +72,6 @@ extern int bfin_EMAC_initialize(bd_t *);
extern int atstk1000_eth_initialize(bd_t *);
extern int greth_initialize(bd_t *);
extern int atngw100_eth_initialize(bd_t *);
-extern int mcffec_initialize(bd_t*);
extern int at91sam9_eth_initialize(bd_t *);
#ifdef CONFIG_API
@@ -279,9 +278,6 @@ int eth_initialize(bd_t *bis)
#if defined(CONFIG_ATNGW100)
atngw100_eth_initialize(bis);
#endif
-#if defined(CONFIG_MCFFEC)
- mcffec_initialize(bis);
-#endif
#if defined(CONFIG_AT91CAP9) || defined(CONFIG_AT91SAM9260) || \
defined(CONFIG_AT91SAM9263)
at91sam9_eth_initialize(bis);
--
1.5.4.3
-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.
[U-Boot-Users] [PATCH 1/2] Moved initialization of FSL_MCDMAFEC Ethernet driver to CPU directory
Added a cpu_eth_init() function to cpu/mcf547x_8x directory and
removed code from net/eth.c
Signed-off-by: Ben Warren <[EMAIL PROTECTED]>
---
cpu/mcf547x_8x/cpu.c |9 +
drivers/net/fsl_mcdmafec.c |2 +-
net/eth.c |4
3 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/cpu/mcf547x_8x/cpu.c b/cpu/mcf547x_8x/cpu.c
index 528bca6..e29b45c 100644
--- a/cpu/mcf547x_8x/cpu.c
+++ b/cpu/mcf547x_8x/cpu.c
@@ -141,3 +141,12 @@ int watchdog_init(void)
return (0);
}
#endif /* CONFIG_HW_WATCHDOG */
+
+#if defined(CONFIG_FSLDMAFEC)
+extern int mcdmafec_initialize(bd_t *bis);
+
+int cpu_eth_init(bd_t *bis)
+{
+ return mcdmafec_initialize(bis);
+}
+#endif
diff --git a/drivers/net/fsl_mcdmafec.c b/drivers/net/fsl_mcdmafec.c
index f2bdba6..e34975a 100644
--- a/drivers/net/fsl_mcdmafec.c
+++ b/drivers/net/fsl_mcdmafec.c
@@ -582,5 +582,5 @@ int mcdmafec_initialize(bd_t * bis)
/* default speed */
bis->bi_ethspeed = 10;
- return 1;
+ return 0;
}
diff --git a/net/eth.c b/net/eth.c
index 7fc9aee..40bbed4 100644
--- a/net/eth.c
+++ b/net/eth.c
@@ -73,7 +73,6 @@ extern int atstk1000_eth_initialize(bd_t *);
extern int greth_initialize(bd_t *);
extern int atngw100_eth_initialize(bd_t *);
extern int mcffec_initialize(bd_t*);
-extern int mcdmafec_initialize(bd_t*);
extern int at91sam9_eth_initialize(bd_t *);
#ifdef CONFIG_API
@@ -283,9 +282,6 @@ int eth_initialize(bd_t *bis)
#if defined(CONFIG_MCFFEC)
mcffec_initialize(bis);
#endif
-#if defined(CONFIG_FSLDMAFEC)
- mcdmafec_initialize(bis);
-#endif
#if defined(CONFIG_AT91CAP9) || defined(CONFIG_AT91SAM9260) || \
defined(CONFIG_AT91SAM9263)
at91sam9_eth_initialize(bis);
--
1.5.4.3
-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [PATCH 0/2] Coldfire Ethernet initialization changes
These two patches move the default initialization of Coldfire FEC controllers to cpu_eth_init() in the CPU directories. I don't have a Coldfire cross compiler set up nor do I have any hardware, so I'm looking for volunteers to do the following: 1. Run 'MAKEALL coldfire' to check for compile-time errors 2. Try the code out on real hardware I'm pushing these patches to a 'testing' branch on the net repo. Please clone it as follows: $ git clone git://git.denx.de/u-boot-net.git $ cd u-boot-net $ git checkout testing thanks! Ben - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH][resubmit] AX88180: new gigabit network driver
Louis wrote: > Dear Ben, > > Thanks for your suggestion; I will correct the driver as soon as > possible. > And I make a mistake in sending the mail through outlook express, > hence making indentation problems. Great! Thanks Louis. For sending patches, I highly recommend using git-send-email instead of your mail client. While it's possible to get most clients to send properly formatted patches, it often takes a lot of trial and error, while git-send-email always works (AFAIK). Also, please consider running 'Lindent -pcs' on the code before sending. This page is very useful: http://www.denx.de/wiki/UBoot/CodingStyle regards, Ben - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Ethernet support for LAN91C111
Shinose wrote: > > > On Tue, Jul 1, 2008 at 7:42 PM, Ben Warren <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > Hi Naveen, > > On Tue, Jul 1, 2008 at 7:02 AM, navin karnam > <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote: > > > > Hi, > > > > I have pxa255 board and one Ethernet controller LAN91C111-Nu > (10/100 Base T) > > attached to it. > > Does u-boot code supports this type of Ethernet controller? Can > anybody tell > > what are the changes that need to be done to make this Ethernet > controller > > work? If not how do i had the support for it? > > > > I believe the LNA91C111 is software compatible with the LAN91xx, but > don't know for sure. If this is true, you should be able to use the > driver called 'smc9111.c'. Be sure to get the latest version of the > code base from git.denx.de <http://git.denx.de>. > > regards, > Ben > > - > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/index.php > ___ > U-Boot-Users mailing list > U-Boot-Users@lists.sourceforge.net > <mailto:U-Boot-Users@lists.sourceforge.net> > https://lists.sourceforge.net/lists/listinfo/u-boot-users > > > > Hi Naveen, > > The driver support the SMSC chip 9111 on any platform if you have a 32 > bit wide databus. For other bus widths you need to customize the driver. > The driver supports both 32-bit and 16-bit, and probably 8-bit too, although nobody's tried it and reported results. > Thanks & Regards, > Shinose. regards, Ben - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] TSEC/PHY @ MPC834x stopped working
Hi Andre, On Wed, Jul 2, 2008 at 7:03 AM, Andre Schwarz <[EMAIL PROTECTED]> wrote: > Ben, > > after pulling u-boot today ethernet stopped working on my MPC8343 based > board (mvBL-M7). > I'm using a Vitesse VSC8601 RGMII phy on TSEC0-1. > > I know there's some rewriting/clean-up going on ... > Yeah, but none of that's in the main source tree. > What do I have to do to get it working again ? > Any new defines introduced lately ? > > Obviously the MII interface stopped working, i.e. all reads give 0xFF. > Switching back to older U-boot (3-4 weeks ago) works fine. Looking here: http://git.denx.de/?p=u-boot.git;a=history;f=drivers/net/tsec.c;h=6e0f2c6fd081baa19d80a985717d470a1f78bc2d;hb=HEAD nothing new has been added except support for a new PHY, and that was about 5 weeks ago. > > Any help is welcome. > Sorry, I don't have access to my MPC8349 board right now or I'd try to help more usefully. Maybe you can post some more information. > regards, > Andre > > MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler - Registergericht: > Amtsgericht Stuttgart, HRB 271090 > Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner > regards, Ben - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH][resubmit] AX88180: new gigabit network driver
On Wed, Jul 2, 2008 at 12:07 AM, Ben Warren <[EMAIL PROTECTED]> wrote:
>> +#define WRITE_TXBUF(data) \
>> + do { \
>> + *(volatile unsigned short *)(AX88180_BASE + TXBUFFER_START) \
>> + = data; \
>> + } while (0)
>> +
> In this case, the do{...}while(0) is unnecessary. Just make the
> assignment.
Sorry, I was wrong in this case - do{...}while(0) is correct. Please
consider replacing all of these macros with static inline functions
though. Much easier for everybody that way.
regards,
Ben
-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] Fix dm9000 receive status and len little endian issue
Tsi-Chung Liew wrote: > From: TsiChung Liew <[EMAIL PROTECTED]> > z > The received status and len was in little endian > format and caused the ethernet unable to proceed > further. Add __le16_to_cpu() in dm9000_rx_status_8/16/32bit(). > > Signed-off-by: TsiChung Liew <[EMAIL PROTECTED]> > Applied to 'next' branch of net repo. thanks, Ben - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH][resubmit] AX88180: new gigabit network driver
Louis,
This submission has several style issues. I suggest you read this:
http://www.denx.de/wiki/UBoot/CodingStyle
Louis wrote:
> Resubmit the driver for the ASIX AX88180 gigabit ethernet chip.
>
> Signed-off-by: Louis Su [EMAIL PROTECTED]
> ---
> drivers/net/Makefile |1 +
> drivers/net/ax88180.c | 842
> +
> drivers/net/ax88180.h | 415
> 3 files changed, 1258 insertions(+), 0 deletions(-)
> create mode 100644 drivers/net/ax88180.c
> create mode 100644 drivers/net/ax88180.h
>
> diff --git a/drivers/net/Makefile b/drivers/net/Makefile
> index 84be288..3a574e0 100644
> --- a/drivers/net/Makefile
> +++ b/drivers/net/Makefile
> @@ -26,6 +26,7 @@ include $(TOPDIR)/config.mk
> LIB := $(obj)libnet.a
>
> COBJS-$(CONFIG_DRIVER_3C589) += 3c589.o
> +COBJS-$(CONFIG_DRIVER_AX88180) += ax88180.o
> COBJS-$(CONFIG_BCM570x) += bcm570x.o bcm570x_autoneg.o 5701rls.o
> COBJS-$(CONFIG_BFIN_MAC) += bfin_mac.o
> COBJS-$(CONFIG_DRIVER_CS8900) += cs8900.o
> diff --git a/drivers/net/ax88180.c b/drivers/net/ax88180.c
> new file mode 100644
> index 000..5579ef0
> --- /dev/null
> +++ b/drivers/net/ax88180.c
> @@ -0,0 +1,842 @@
> +/* ax88180: ASIX AX88180 Non-PCI Gigabit Ethernet u-boot driver */
> +/*
Multi-line comments are done like:
/*
* Comment
*/
> + This program is free software; you can distribute it and/or modify
> + it under the terms of the GNU General Public License (Version 2) as
> + published by the Free Software Foundation.
> + This program is distributed in the hope 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.
> +*/
> +
> +/*
> +
>
> + ASIX AX88180 Non-PCI 16/32-bit Gigabit Ethernet Linux Driver
> +
> + The AX88180 Ethernet controller is a high performance and highly
> + integrated local CPU bus Ethernet controller with embedded 40K bytes
> + SRAM and supports both 16-bit and 32-bit SRAM-Like interfaces for any
> + embedded systems.
> + The AX88180 is a single chip 10/100/1000Mbps Gigabit Ethernet
> + controller that supports both MII and RGMII interfaces and is
> + compliant to IEEE 802.3, IEEE 802.3u and IEEE 802.3z standards.
> +
> + Please visit ASIX's web site (http://www.asix.com.tw) for more
> + details.
> +
> + Module Name : ax88180.c
> + Date : 2008-07-01
> + History
> + 09/06/2006 : New release for AX88180 US2 chip.
> + 07/01/2008 : Fix up the coding style and using functions
> +instead of most macros
> +
>
> +*/
> +#include
> +#include
> +#include
> +
> +#include "ax88180.h"
> +
> +#ifdef CONFIG_DRIVER_AX88180
This is unnecessary. You're already compiling conditionally in Makefile
> +
> +/*
> +===
>
> +<< Local SubProgram Declaration >>
> +===
>
> +*/
> +static void ax88180_rx_handler (void);
> +static int ax88180_PHY_initial (void);
> +static void ax88180_meida_config (void);
> +static unsigned long get_CicadaPHY_meida_mode (void);
> +static unsigned long get_MarvellPHY_meida_mode (void);
> +static unsigned short ax88180_mdio_read (unsigned long phyaddr,
> + unsigned long regaddr);
Indentation with TABs, 8 characters wide.
> +static void ax88180_mdio_write (unsigned long phyaddr,
> + unsigned long regaddr,
> + unsigned short regdata);
> +
> +/*
> +===
>
> +<< Declare Macro/Structure Definition >>
> +===
>
> +*/
> +typedef enum _AX88180_LINK_STATE {
> + INS_LINK_DOWN,
> + INS_LINK_UP,
> + INS_LINK_UNKNOWN
> +} AX88180_LINK_STATE;
> +
Again, serious indentation problems. I won't mention it again.
> +typedef struct _AX88180_PRIVATE {
> + unsigned long PhyAddr;
> + unsigned long PhyID0;
> + unsigned long FirstTxDesc;
> + unsigned long NextTxDesc;
> + unsigned long rxbuf_overflow_count;
> + AX88180_LINK_STATE LinkState;
> +} AX88180_PRIVATE;
> +
> +AX88180_PRIVATE axlocal;
> +
> +#if (DEBUG_FLAGS & DEBUG_MSG)
> +static inline void ax88180_disp_all_reg (void)
> +{
> + unsigned long tmpval;
> + int i;
> + PRINTK (DEBUG_MSG, "ax88180: AX88180 MAC Registers:\n");
We don't need yet another way to print debug information. Please use
debug() or printf() only.
> + for (i = 0xFC00; i <= 0xFCFF; i += 4) {
> + READ_MACREG (i, tmpval);
> + PRINTK (DEBUG_MSG, "0x%04x=0x%08lx ", i, tmpval
Re: [U-Boot-Users] [PATCH] Fix dm9000 receive status and len little endian issue
Liew Tsi Chung wrote: > Ben, > > May I know the status on this patch? > > Regards, > TsiChung > > Sorry, I'll address it tonight. regards, Ben - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Ethernet support for LAN91C111
Hi Naveen, On Tue, Jul 1, 2008 at 7:02 AM, navin karnam <[EMAIL PROTECTED]> wrote: > > Hi, > > I have pxa255 board and one Ethernet controller LAN91C111-Nu (10/100 Base T) > attached to it. > Does u-boot code supports this type of Ethernet controller? Can anybody tell > what are the changes that need to be done to make this Ethernet controller > work? If not how do i had the support for it? > I believe the LNA91C111 is software compatible with the LAN91xx, but don't know for sure. If this is true, you should be able to use the driver called 'smc9111.c'. Be sure to get the latest version of the code base from git.denx.de. regards, Ben - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] net: smc911x: Fix can not compile smc911x
Nobuhiro,
Nice catch! Thanks.
Wolfgang/Detlev,
Please pull directly.
regards,
Ben
Nobuhiro Iwamatsu wrote:
> When enable CONFIG_DRIVER_SMC911X_16_BIT in smc911x, can not compile it.
> I revised it from "elif" preprocessor to "elif defined".
>
> Signed-off-by: Nobuhiro Iwamatsu <[EMAIL PROTECTED]>
>
Acked-by: Ben Warren <[EMAIL PROTECTED]>
> ---
> drivers/net/smc911x.c |4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/smc911x.c b/drivers/net/smc911x.c
> index 7555cb9..a2d3cb2 100644
> --- a/drivers/net/smc911x.c
> +++ b/drivers/net/smc911x.c
> @@ -33,7 +33,7 @@
> CONFIG_DRIVER_SMC911X_16_BIT shall be set"
> #endif
>
> -#ifdef CONFIG_DRIVER_SMC911X_32_BIT
> +#if defined (CONFIG_DRIVER_SMC911X_32_BIT)
> static inline u32 reg_read(u32 addr)
> {
> return *(volatile u32*)addr;
> @@ -42,7 +42,7 @@ static inline void reg_write(u32 addr, u32 val)
> {
> *(volatile u32*)addr = val;
> }
> -#elif CONFIG_DRIVER_SMC911X_16_BIT
> +#elif defined (CONFIG_DRIVER_SMC911X_16_BIT)
> static inline u32 reg_read(u32 addr)
> {
> volatile u16 *addr_16 = (u16 *)addr;
>
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Does U-boot support ethernet chip LAN9210 from SMSC?
이승열 wrote: > Hi Ben, > > I have found smc911x.c source code in which both 16 and 32 bit access are > supported. > I will test my board with this source code. > Once you have it working, please send a patch indicating changes you've made. regards, Ben - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Does U-boot support ethernet chip LAN9210 from SMSC?
On Sun, Jun 29, 2008 at 10:06 PM, 이승열 <[EMAIL PROTECTED]> wrote: > Hi Ben, > > Sorry for bothering you. > > I have downloaded the latest version of U-boot. > There is smc911x.c file. I have added this file to Makefile. > The compilation is successful. You don't have to add anything to the Makefile, just use the correct CONFIG options > > But, there are two problems. > 1. there is no LAN9210 entry in chip id list So add it. I haven't looked at the LAN9210 data sheet to even know if it will work with this chip. You're going to have to do some work. > 2. Only 32-bit is supported. > Not true. Both 16 and 32 bit access is supported. Check the source code (hint: look for CONFIG_DRIVER_SMC911X_16_BIT) > Is there any recent driver for LAN9210? I don't know of another or I would have told you about it. Good luck, Ben - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Does U-boot support ethernet chip LAN9210 from SMSC?
Hi Seung, On Sun, Jun 29, 2008 at 6:56 PM, 이승열 <[EMAIL PROTECTED]> wrote: > Hi, > > Does U-boot support ethernet chip LAN9210 from SMSC? > If yes, how can I get driver source code? > The smc911x driver claims to support many different 9[12]1x chips, although I can't speak for certain about the 9210. It was added recently, so be sure to clone the latest source tree. Have a look in drivers/net/smc911x.c regards, Ben - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Set manually tsec speed in u-boot 1.2.0
On Fri, Jun 27, 2008 at 2:37 AM, Frank Prepelica <[EMAIL PROTECTED]> wrote: > Hi Ben, > > The ethernet adapter (PCMCIA ethernet card) which is directly connect to the > board can be forced in windows to use 100Mbit full duplex, but u-boot still > use 1Gbit. It's a Marvell phy, the exact phy description I have not in mind. > The processor is a mpc8313. > > We are using a customized board which based on the MPC8313ERDB board. > > Nevertheless, is there a special env variable to set in U-Boot to use another > speed, in this case 100Mbit? (e.g. I can choose by setting "using ethact > TSEC1 which tsec should be used) Is there something equivalent for using tsec > speed? I don't see any way to set it explicitly, but the default mode is autonegotiate, so the TSEC will run at the highest rate supported by its peer. I plug these things into 10/100 switches all the time and they work fine. What problem are you seeing. regards, Ben - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Set manually tsec speed in u-boot 1.2.0
On Fri, Jun 27, 2008 at 2:37 AM, Frank Prepelica <[EMAIL PROTECTED]> wrote: > Hi Ben, > > The ethernet adapter (PCMCIA ethernet card) which is directly connect to the > board can be forced in windows to use 100Mbit full duplex, but u-boot still > use 1Gbit. It's a Marvell phy, the exact phy description I have not in mind. > The processor is a mpc8313. > > We are using a customized board which based on the MPC8313ERDB board. > > Nevertheless, is there a special env variable to set in U-Boot to use another > speed, in this case 100Mbit? (e.g. I can choose by setting "using ethact > TSEC1 which tsec should be used) Is there something equivalent for using tsec > speed? I don't see any way to set it explicitly, but the default mode is autonegotiate, so the TSEC will run at the highest rate supported by its peer. I plug these things into 10/100 switches all the time and they work fine. What problem are you seeing. regards, Ben - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Ethernet stopped working after upgrading from 1.1.5 to 1.3.3
Stuart Wood wrote: > It was pulled together from the cirrus logic Linux distribution posts > done on the linux-cirrus mailing list as far as I know. I was not > around when it was initially put together, and the engineer who did it > has since left. > > That's a fun position to be in. Since the code's out of tree there's only so much we can do to help. > Stuart > > On Thu, Jun 26, 2008 at 12:26 PM, Ben Warren <[EMAIL PROTECTED]> wrote: > >> Hi Stuart, >> >> Stuart Wood wrote: >> >>> Hi all, >>> >>> Can anyone point me in the right direction to figure out why >>> after porting up to 1.3.3 from 1.1.5 I'm getting a >>> "No ethernet found." error. >>> >>> If I had to guess, I'd say that the hooks aren't in /net/eth.c to initialize the driver. >>> I'm using a cirrus logic EP9302 Arm processor that was someone >>> initially ported to u-boot 1.1.5. So I'm not to familiar with how the >>> CPU specific files should be laid out. >>> >>> Did the config commands change to set up Ethernet? >>> >>> The Ethernet driver for the chip is under cpu/arm920t/ep93xx/eth.c >>> >>> >>> Nothing fundamental has changed in how Ethernet drivers are initialized. I'm afraid you're going to have to roll up your sleeves and figure it out yourself. printf will be very helpful. >> There's no 'ep93xx' in the source code. Where did you get it from? >> >> regards, >> Ben >> >> > > > > - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Ethernet stopped working after upgrading from 1.1.5 to 1.3.3
Hi Stuart, Stuart Wood wrote: > Hi all, > > Can anyone point me in the right direction to figure out why > after porting up to 1.3.3 from 1.1.5 I'm getting a > "No ethernet found." error. > > I'm using a cirrus logic EP9302 Arm processor that was someone > initially ported to u-boot 1.1.5. So I'm not to familiar with how the > CPU specific files should be laid out. > > Did the config commands change to set up Ethernet? > > The Ethernet driver for the chip is under cpu/arm920t/ep93xx/eth.c > > There's no 'ep93xx' in the source code. Where did you get it from? regards, Ben - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] Fix dm9000 receive status and len little endian issue
Tsi-Chung Liew wrote:
> From: TsiChung Liew <[EMAIL PROTECTED]>
>
> The received status and len was in little endian
> format and caused the ethernet unable to proceed
> further. Add __le16_to_cpu() in dm9000_rx_status_8/16/32bit().
>
> Signed-off-by: TsiChung Liew <[EMAIL PROTECTED]>
> ---
> drivers/net/dm9000x.c | 16 ++--
> 1 files changed, 10 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/dm9000x.c b/drivers/net/dm9000x.c
> index 844fb76..e7365fe 100644
> --- a/drivers/net/dm9000x.c
> +++ b/drivers/net/dm9000x.c
> @@ -214,24 +214,28 @@ static void dm9000_rx_status_32bit(u16 *RxStatus, u16
> *RxLen)
> DM9000_outb(DM9000_MRCMD, DM9000_IO);
>
> tmpdata = DM9000_inl(DM9000_DATA);
> - *RxStatus = tmpdata;
> - *RxLen = tmpdata >> 16;
> + *RxStatus = __le16_to_cpu(tmpdata);
> + *RxLen = __le16_to_cpu(tmpdata >> 16);
> }
>
> static void dm9000_rx_status_16bit(u16 *RxStatus, u16 *RxLen)
> {
> DM9000_outb(DM9000_MRCMD, DM9000_IO);
>
> - *RxStatus = DM9000_inw(DM9000_DATA);
> - *RxLen = DM9000_inw(DM9000_DATA);
> + *RxStatus = __le16_to_cpu(DM9000_inw(DM9000_DATA));
> + *RxLen = __le16_to_cpu(DM9000_inw(DM9000_DATA));
> }
>
> static void dm9000_rx_status_8bit(u16 *RxStatus, u16 *RxLen)
> {
> DM9000_outb(DM9000_MRCMD, DM9000_IO);
>
> - *RxStatus = DM9000_inb(DM9000_DATA) + (DM9000_inb(DM9000_DATA) << 8);
> - *RxLen = DM9000_inb(DM9000_DATA) + (DM9000_inb(DM9000_DATA) << 8);
> + *RxStatus =
> + __le16_to_cpu(DM9000_inb(DM9000_DATA) +
> + (DM9000_inb(DM9000_DATA) << 8));
> + *RxLen =
> + __le16_to_cpu(DM9000_inb(DM9000_DATA) +
> + (DM9000_inb(DM9000_DATA) << 8));
> }
>
> /*
>
Sorry for opening Pandora's box, but wouldn't it be better to redefine
the DM9000_x macros instead of where they're called?
regards,
Ben
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] Fix dm9000 receive status and len little endian issue
Hi Tsi-Chung, Tsi-Chung Liew wrote: > From: TsiChung Liew <[EMAIL PROTECTED]> > > The received status and len was in little endian > format and caused the ethernet unable to proceed > further. Add define CFG_DM9000_BYTESWAP_STATUS_LEN in > dm9000_rx_status_16bit() to byte swap RxStatus and RxLen > > Signed-off-by: TsiChung Liew <[EMAIL PROTECTED]> > --- > drivers/net/dm9000x.c |4 > 1 files changed, 4 insertions(+), 0 deletions(-) > > diff --git a/drivers/net/dm9000x.c b/drivers/net/dm9000x.c > index 844fb76..eff676c 100644 > --- a/drivers/net/dm9000x.c > +++ b/drivers/net/dm9000x.c > @@ -224,6 +224,10 @@ static void dm9000_rx_status_16bit(u16 *RxStatus, u16 > *RxLen) > > *RxStatus = DM9000_inw(DM9000_DATA); > *RxLen = DM9000_inw(DM9000_DATA); > +#ifdef CFG_DM9000_BYTESWAP_STATUS_LEN > + *RxStatus = __sw16(*RxStatus); > + *RxLen = __sw16(*RxLen); > +#endif > } > Instead of adding yet another kludgy CONFIG option, please consider changing the accessors to le16_to_cpu() or whatever is appropriate. The definitions of DM9000_inX() are not very portable as it is and we should be striving to make the code better, not worse. regards, Ben - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Set manually tsec speed in u-boot 1.2.0
Hi Frank, Frank Prepelica wrote: > > Hi all, > > > > is there a way to set the tsec speed in u-boot (v1.2.0) manually to > 100Mbit? Because u-boot always uses 1Gbit although the > > link speed is fixed set(in windows) to 100Mbit. > > > How does Windows fit into this? Are you booting Windows on the board? Are you connecting to a Windows machine via a crossover, via a switch, or something else? What PHY is connected to the TSEC? What processor are you using? regards, Ben - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] Add mechanisms for CPU and board-specific Ethernet initialization
Jean-Christophe PLAGNIOL-VILLARD wrote: > On 09:16 Tue 10 Jun , Ben Warren wrote: > >> Shinya Kuribayashi wrote: >> >>> Stefan Roese wrote: >>> >>>> On Tuesday 10 June 2008, Shinya Kuribayashi wrote: >>>> >>>>>>> Shouldn't this be the other way around? >>>>>>> >>>>>>> + if (board_eth_init(bis) < 0) >>>>>>> + eth_eth_init(bis); >>>>>>> >>>>>>> So that the board init routine can "overwrite" the cpu init version. >>>>>>> >>>>>> Yeah, I think you're right. If board_eth_init() exists, it gets >>>>>> highest priority. >>>>>> >>>>> Just wondered, does that mean we could only have either cpu_eth_init or >>>>> board_eth_init at a time? >>>>> >>>> Not really. board_eth_init() could call cpu_eth_init() if necessary. >>>> >>> Hm. What is cpu_eth_init for then? Just >>> >>>board_eth_init(bis); >>> >>> seems to be enough for me. I also wonder where is the best place to have >>> cpu_eth_init? >>> >>> >> The cpu_init() was suggested by Stefan in our original discussion, when >> I only had the board function. His perspective is ppc_4xx, where tons >> of CPUs and boards share the EMAC driver, and he didn't want to modify >> each board. As you'll see in the discussion with JDL, it can probably >> apply to TSEC as well. >> >>> I'm not going to argue with you, I'm just thinking about my targets. One >>> of my targets has internal ethernet MAC, and its evaluation board has an >>> on-board external PCI NIC. Another target has internal MAC, but doesn't >>> have PCI NIC. >>> >>> I thought it'll be something like >>> >>>cpu_eth_init(bis); >>>board_eth_init(bis); >>> >>> >> The idea is that cpu_eth_init is a default for a CPU family, and >> board_eth_init is a board override, which can of course call cpu_eth_init. >> > What about a section to declare the netdev? > > In this case we can have more than 2 eth and it more generic. > > Best Regards, > J. > > Sorry, I don't follow. regards, Ben - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH 1/1] Add support for the hammerhead (AVR32) board
Haavard Skinnemoen wrote: > Ben Warren <[EMAIL PROTECTED]> wrote: > >> Hi Julien, >> >> Julien May wrote: >> >>> On Mon, 23 Jun 2008, Haavard Skinnemoen wrote: >>> >>> >>> >>>> Julien May <[EMAIL PROTECTED]> wrote: >>>> >>>> >>>>> Signed-off-by: Julien May <[EMAIL PROTECTED]> >>>>> >>>>> >>>> Could you add a few lines describing the Hammerhead board, perhaps with >>>> a link to your site? >>>> >>>> >>> You'll find a short desc. of the hammerhead board on top of the >>> inc. patch below. >>> >>> >>> >> Please don't do incremental patches. Just re-submit. >> > > Sorry, my fault. See below: > > Oh, I missed you suggesting that idea... >>>> This looks pretty good to me. I have a few comments below, and I've >>>> Cc'ed u-boot-users so that more people can comment on this. Please keep >>>> them in the loop whenever you post a new version of this patch. >>>> >>>> If you want, I can apply this to my tree as is, and you can send me >>>> incremental patches fixing up the remaining issues. I'll fold >>>> everything into a single patch before sending it upstream. >>>> >>>> >>>> >>> Would be great if you could apply the patch to your tree. Please find >>> below the incremental patch that should fix all of the remaining issues. >>> > > ...though I'm not sure what the problem with incremental patches is, > assuming someone is willing to merge them before they finally go > upstream. I am willing to do that. > > I personally think they're hard to follow, add unnecessary dependencies and pollute the changelog. But that's just my opinion. >>> diff --git a/net/eth.c b/net/eth.c >>> index 054a9fd..2d6f15f 100644 >>> --- a/net/eth.c >>> +++ b/net/eth.c >>> >>> >> You won't need to touch this file. Please see how it's done in the >> 'next' branch of the net repo on git.denx.de. >> > > Yeah, but it you don't touch this file, it will only work in your > 'next' branch. If you don't rebase your next branch, I can pull it into > my tree and get everything sorted out before the merge window. Hey, > I'll even fix up a few existing boards :-) > > The other possibility is to apply the patch with this hunk present and > throw it out before I finally merge it after your changes are in. That > was my initial suggestion. > > What do you think? > Just another fun aspect of having non-orthogonal branches and patches. The best solution would be for Wolfgang to pull my patch into mainline (for r1.3.4). Technically, a few rounds of the submission were posted before the merge window closed, so maybe he'll be in a good mood after vacation :) Otherwise, I don't care - your idea works. You can move a few or all of the macb-using boards over and that would be cool. cheers, Ben - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH 1/1] Add support for the hammerhead (AVR32) board
Hi Julien,
Julien May wrote:
> On Mon, 23 Jun 2008, Haavard Skinnemoen wrote:
>
>
>> Julien May <[EMAIL PROTECTED]> wrote:
>>
>>> Signed-off-by: Julien May <[EMAIL PROTECTED]>
>>>
>> Could you add a few lines describing the Hammerhead board, perhaps with
>> a link to your site?
>>
>
> You'll find a short desc. of the hammerhead board on top of the
> inc. patch below.
>
>
Please don't do incremental patches. Just re-submit.
>> This looks pretty good to me. I have a few comments below, and I've
>> Cc'ed u-boot-users so that more people can comment on this. Please keep
>> them in the loop whenever you post a new version of this patch.
>>
>> If you want, I can apply this to my tree as is, and you can send me
>> incremental patches fixing up the remaining issues. I'll fold
>> everything into a single patch before sending it upstream.
>>
>>
>
> Would be great if you could apply the patch to your tree. Please find
> below the incremental patch that should fix all of the remaining issues.
>
> - Julien May
>
> >From 6333f6ea0a5a16d273fe1512ecacdce9fff275f5 Mon Sep 17 00:00:00 2001
> From: Julien May <[EMAIL PROTECTED]>
> Date: Mon, 23 Jun 2008 16:44:44 +0200
> Subject: [PATCH 1/1] Add support for the hammerhead (AVR32) board.
>
> The Hammerhead platform is built around a AVR32 32-bit microcontroller from
> Atmel.
> It offers versatile peripherals, such as ethernet, usb device, usb host etc.
>
> The board also incooperates a power supply and is a Power over Ethernet (PoE)
> Powered Device (PD).
>
> Additonally, a Cyclone III FPGA from Altera is integrated on the board. The
> FPGA is mapped into the
> 32-bit AVR memory bus. The FPGA offers two DDR2 SDRAM interfaces, which will
> cover even the most
> exceptional need of memory bandwidth. Together with the onboard video decoder
> the board is ready
> for video processing.
>
> For more information see: http://www.miromico.com/hammerhead
>
> Signed-off-by: Julien May <[EMAIL PROTECTED]>
> ---
> board/miromico/hammerhead/eth.c |2 +-
> board/miromico/hammerhead/hammerhead.c |9 -
> cpu/at32ap/at32ap700x/gpio.c | 11 ---
> cpu/at32ap/cpu.c |2 --
> include/asm-avr32/arch-at32ap700x/gpio.h |3 ---
> include/configs/hammerhead.h | 14 +++---
> net/eth.c|4 ++--
> 7 files changed, 10 insertions(+), 35 deletions(-)
>
> diff --git a/board/miromico/hammerhead/eth.c b/board/miromico/hammerhead/eth.c
> index 969c48e..056e9ca 100644
> --- a/board/miromico/hammerhead/eth.c
> +++ b/board/miromico/hammerhead/eth.c
> @@ -30,7 +30,7 @@
> extern int macb_eth_initialize(int id, void *regs, unsigned int phy_addr);
>
> #ifdef CONFIG_CMD_NET
> -void board_eth_initialize(bd_t *bi)
> +void board_eth_init(bd_t *bi)
> {
> macb_eth_initialize(0, (void *)MACB0_BASE, bi->bi_phy_id[0]);
> }
>
board_eth_init() returns an int. Standard UNIX, =0 on success, <0 on
failure.
> diff --git a/board/miromico/hammerhead/hammerhead.c
> b/board/miromico/hammerhead/hammerhead.c
> index 69ff7fa..26d1182 100644
> --- a/board/miromico/hammerhead/hammerhead.c
> +++ b/board/miromico/hammerhead/hammerhead.c
> @@ -64,10 +64,6 @@ int board_early_init_f(void)
> #if defined(CONFIG_MMC)
> gpio_enable_mmci();
> #endif
> -
> - /* Select GCLK3 peripheral function. We'll need it as clock output
> - * for ethernet PHY. */
> - gpio_enable_gclk3();
> return 0;
> }
>
> @@ -100,6 +96,9 @@ void gclk_init(void)
> {
> /* Hammerhead boards uses GCLK3 as 25MHz output to ethernet PHY */
>
> + /* Select GCLK3 peripheral function */
> + gpio_select_periph_A(GPIO_PIN_PB29, 0);
> +
> /* Enable GCLK3 with no input divider, from OSC0 (crystal) */
> - sm_writel( PM_GCCTRL(3), SM_BIT(CEN) );
> + sm_writel(PM_GCCTRL(3), SM_BIT(CEN));
> }
> diff --git a/cpu/at32ap/at32ap700x/gpio.c b/cpu/at32ap/at32ap700x/gpio.c
> index 2b7717f..859124a 100644
> --- a/cpu/at32ap/at32ap700x/gpio.c
> +++ b/cpu/at32ap/at32ap700x/gpio.c
> @@ -142,14 +142,3 @@ void gpio_enable_mmci(void)
> gpio_select_periph_A(GPIO_PIN_PA15, 0); /* DATA3 */
> }
> #endif
> -
> -/*
> - * Hammerhead board uses GCLK3 (Periph A on PB29) as 25MHz clock output
> - * for ethernet PHY.
> - */
> -void __gpio_enable_gclk3(void)
> -{
> - gpio_select_periph_A(GPIO_PIN_PB29, 0); /* GCLK3 */
> -}
> -
> -void gpio_enable_gclk3(void) __attribute__((weak,
> alias("__gpio_enable_gclk3")));
> diff --git a/cpu/at32ap/cpu.c b/cpu/at32ap/cpu.c
> index 4a92aab..1a13702 100644
> --- a/cpu/at32ap/cpu.c
> +++ b/cpu/at32ap/cpu.c
> @@ -66,9 +66,7 @@ int cpu_init(void)
> asm volatile("csrf %0" : : "i"(SYSREG_EM_OFFSET));
>
> if(gclk_init)
> - {
> gclk_init();
> - }
>
> return 0;
> }
> diff --git a/include/asm-avr32/arch-at32ap700x/gpio.h
> b/include/asm-avr32/arch-at32ap700x/gpio.h
> index c350
Re: [U-Boot-Users] [PATCH V4] Add mechanisms for CPU and board-specific Ethernet initialization
On Fri, Jun 13, 2008 at 7:08 AM, Ben Warren <[EMAIL PROTECTED]> wrote: > This patch is the first step in cleaning up net/eth.c, by moving Ethernet > initialization to CPU or board-specific code. Initial implementation is > only on the Freescale TSEC controller, but others will be added soon. > > Signed-off-by: Ben Warren <[EMAIL PROTECTED]> > --- > > This time around, instead of adding code to each board that implements TSEC, I > implemented cpu_eth_init() in all architectures that have TSEC. Preferably, > this would have gone in new files in the CPU directories, but 'ld' made it > impossible to guarantee that the code would be linked into the final > executable. > Also, don't need include/netdev.h for now. > > cpu/mpc83xx/cpu.c | 20 > cpu/mpc85xx/cpu.c | 30 ++ > cpu/mpc86xx/cpu.c | 27 +++ > net/eth.c | 31 +++ > 4 files changed, 92 insertions(+), 16 deletions(-) > There have been no comments in 11 days, so I pushed this to the 'next' branch of the net repo on git.denx.de. regards, Ben - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH v2] Update Freescale sys_eeprom.c to handle CCID formats
Timur Tabi wrote: > Ben Warren wrote: > > >> So are you saying that the plan is to move much of the configuration >> information from NOR flash to I2C EEPROMs on Freescale evaluation >> boards? >> > > No. The plan is to better support does boards that *do* have MAC addresses in > EEPROM. > > (Actually, I have no idea what the board designers are planning on doing in > the > future. I just know what doesn't work today). > > One of the problems is that the CRC value in the EEPROM is not programmed > during > manufacturing, but the current version of the code will refuse to read MAC > addresses if the CRC doesn't match. So out of the box, the BSPs never use the > EEPROM for anything. The user has to rewrite the EEPROM. > > Oh. OK. >> I'm not suggesting that it's a good or bad idea, but just keep >> in mind that the main raison d'etre for these boards is to serve as >> starting points for customer designs, and I'm not sure the majority of >> customers would use things this way. >> > > True, but it would be nice if the code worked properly. :-) > > That's for sure. Thanks for the clarification. Ben - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH v2] Update Freescale sys_eeprom.c to handle CCID formats
Hi Timur, Timur Tabi wrote: > Update the sys_eeprom.c file to handle both NXID and CCID EEPROM formats. The > NXID format replaces the older CCID format, but it's important to support both > since most boards out there still use the CCID format. This change is in > preparation for using one file to handle both formats. This will also unify > EEPROM support for all Freescale 85xx and 86xx boards. > > Also update the 86xx board header files to use the standard > CFG_I2C_EEPROM_ADDR > instead of ID_EEPROM_ADDR. > > Signed-off-by: Timur Tabi <[EMAIL PROTECTED]> > --- > > This patch is the first in a series to clean up the MAC address determination > in some of Freescale's board. The ultimate goal is to get rid of > CONFIG_ETHADDR and related macros in the board header files. > > So are you saying that the plan is to move much of the configuration information from NOR flash to I2C EEPROMs on Freescale evaluation boards? I'm not suggesting that it's a good or bad idea, but just keep in mind that the main raison d'etre for these boards is to serve as starting points for customer designs, and I'm not sure the majority of customers would use things this way. regards, Ben - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [PATCH V4] Add mechanisms for CPU and board-specific Ethernet initialization
This patch is the first step in cleaning up net/eth.c, by moving Ethernet
initialization to CPU or board-specific code. Initial implementation is
only on the Freescale TSEC controller, but others will be added soon.
Signed-off-by: Ben Warren <[EMAIL PROTECTED]>
---
This time around, instead of adding code to each board that implements TSEC, I
implemented cpu_eth_init() in all architectures that have TSEC. Preferably,
this would have gone in new files in the CPU directories, but 'ld' made it
impossible to guarantee that the code would be linked into the final executable.
Also, don't need include/netdev.h for now.
cpu/mpc83xx/cpu.c | 20
cpu/mpc85xx/cpu.c | 30 ++
cpu/mpc86xx/cpu.c | 27 +++
net/eth.c | 31 +++
4 files changed, 92 insertions(+), 16 deletions(-)
diff --git a/cpu/mpc83xx/cpu.c b/cpu/mpc83xx/cpu.c
index 36de78d..94d1a13 100644
--- a/cpu/mpc83xx/cpu.c
+++ b/cpu/mpc83xx/cpu.c
@@ -358,3 +358,23 @@ int dma_xfer(void *dest, u32 count, void *src)
return ((int)dma_check());
}
#endif /*CONFIG_DDR_ECC*/
+
+#ifdef CONFIG_TSEC_ENET
+/* Default initializations for TSEC controllers. To override,
+ * create a board-specific function called:
+ * int board_eth_init(bd_t *bis)
+ */
+
+extern int tsec_initialize(bd_t * bis, int index, char *devname);
+
+int cpu_eth_init(bd_t *bis)
+{
+#if defined(CONFIG_TSEC1)
+ tsec_initialize(bis, 0, CONFIG_TSEC1_NAME);
+#endif
+#if defined(CONFIG_TSEC2)
+ tsec_initialize(bis, 1, CONFIG_TSEC2_NAME);
+#endif
+ return 0;
+}
+#endif
diff --git a/cpu/mpc85xx/cpu.c b/cpu/mpc85xx/cpu.c
index 9873383..6624136 100644
--- a/cpu/mpc85xx/cpu.c
+++ b/cpu/mpc85xx/cpu.c
@@ -279,3 +279,33 @@ int dma_xfer(void *dest, uint count, void *src) {
return dma_check();
}
#endif
+
+#if defined(CONFIG_TSEC_ENET) || defined(CONFIGMPC85XX_FEC)
+/* Default initializations for TSEC controllers. To override,
+ * create a board-specific function called:
+ * int board_eth_init(bd_t *bis)
+ */
+
+extern int tsec_initialize(bd_t * bis, int index, char *devname);
+
+int cpu_eth_init(bd_t *bis)
+{
+#if defined(CONFIG_TSEC1)
+ tsec_initialize(bis, 0, CONFIG_TSEC1_NAME);
+#endif
+#if defined(CONFIG_TSEC2)
+ tsec_initialize(bis, 1, CONFIG_TSEC2_NAME);
+#endif
+#if defined(CONFIG_MPC85XX_FEC)
+ tsec_initialize(bis, 2, CONFIG_MPC85XX_FEC_NAME);
+#else
+#if defined(CONFIG_TSEC3)
+ tsec_initialize(bis, 2, CONFIG_TSEC3_NAME);
+#endif
+#if defined(CONFIG_TSEC4)
+ tsec_initialize(bis, 3, CONFIG_TSEC4_NAME);
+#endif
+#endif
+ return 0;
+}
+#endif
diff --git a/cpu/mpc86xx/cpu.c b/cpu/mpc86xx/cpu.c
index 3c74764..79f227b 100644
--- a/cpu/mpc86xx/cpu.c
+++ b/cpu/mpc86xx/cpu.c
@@ -288,3 +288,30 @@ void mpc86xx_reginfo(void)
printf("\tBR7\t0x%08X\tOR7\t0x%08X \n", in_be32(&lbc->br7),
in_be32(&lbc->or7));
}
+
+#ifdef CONFIG_TSEC_ENET
+/* Default initializations for TSEC controllers. To override,
+ * create a board-specific function called:
+ * int board_eth_init(bd_t *bis)
+ */
+
+extern int tsec_initialize(bd_t * bis, int index, char *devname);
+
+int cpu_eth_init(bd_t *bis)
+{
+#if defined(CONFIG_TSEC1)
+ tsec_initialize(bis, 0, CONFIG_TSEC1_NAME);
+#endif
+#if defined(CONFIG_TSEC2)
+ tsec_initialize(bis, 1, CONFIG_TSEC2_NAME);
+#endif
+#if defined(CONFIG_TSEC3)
+ tsec_initialize(bis, 2, CONFIG_TSEC3_NAME);
+#endif
+#if defined(CONFIG_TSEC4)
+ tsec_initialize(bis, 3, CONFIG_TSEC4_NAME);
+#endif
+ return 0;
+}
+#endif
+
diff --git a/net/eth.c b/net/eth.c
index c4f24c6..0a224ed 100644
--- a/net/eth.c
+++ b/net/eth.c
@@ -28,6 +28,17 @@
#if defined(CONFIG_CMD_NET) && defined(CONFIG_NET_MULTI)
+/*
+ * CPU and board-specific Ethernet initializations. Aliased function
+ * signals caller to move on
+ */
+static int __def_eth_init(bd_t *bis)
+{
+ return -1;
+}
+int cpu_eth_init(bd_t *bis) __attribute((weak, alias("__def_eth_init")));
+int board_eth_init(bd_t *bis) __attribute((weak, alias("__def_eth_init")));
+
#ifdef CFG_GT_6426x
extern int gt6426x_eth_initialize(bd_t *bis);
#endif
@@ -165,6 +176,10 @@ int eth_initialize(bd_t *bis)
#if defined(CONFIG_MII) || defined(CONFIG_CMD_MII)
miiphy_init();
#endif
+ /* Try board-specific initialization first. If it fails or isn't
+* present, try the cpu-specific initialization */
+ if (board_eth_init(bis) < 0)
+ cpu_eth_init(bis);
#if defined(CONFIG_DB64360) || defined(CONFIG_CPCI750)
mv6436x_eth_initialize(bis);
@@ -196,22 +211,6 @@ int eth_initialize(bd_t *bis)
#if defined(CONFIG_SK98)
skge_initialize(bis);
#endif
-#if defined(CONFIG_TSEC1)
- tsec_initialize(bis, 0, CONFIG_TSEC1_NAME);
-#endif
-#if defined(CONFIG_TSEC2)
- tsec_initialize(bis, 1, CONFIG_TSE
Re: [U-Boot-Users] [PATCH V3] Add mechanisms for CPU and board-specific Ethernet initialization
Please ignore. It's wrong. Sorry for the noise!
Ben
On Fri, Jun 13, 2008 at 6:58 AM, Ben Warren <[EMAIL PROTECTED]> wrote:
> This patch is the first step in cleaning up net/eth.c, by moving Ethernet
> initialization to CPU or board-specific code. Initial implementation is
> only on the Freescale TSEC controller, but others will be added soon.
>
> Signed-off-by: Ben Warren <[EMAIL PROTECTED]>
> ---
>
> This time around, instead of adding code to each board that implements TSEC, I
> implemented cpu_eth_init() in all architectures that have TSEC. Preferably,
> this would have gone in new files in the CPU directories, but 'ld' made it
> impossible to guarantee that the code would be linked into the final
> executable.
> Also, don't need include/netdev.h for now.
>
> cpu/mpc83xx/cpu.c | 20
> cpu/mpc85xx/cpu.c | 30 ++
> cpu/mpc86xx/cpu.c | 27 +++
> net/eth.c | 26 ++
> 4 files changed, 87 insertions(+), 16 deletions(-)
>
> diff --git a/cpu/mpc83xx/cpu.c b/cpu/mpc83xx/cpu.c
> index 36de78d..94d1a13 100644
> --- a/cpu/mpc83xx/cpu.c
> +++ b/cpu/mpc83xx/cpu.c
> @@ -358,3 +358,23 @@ int dma_xfer(void *dest, u32 count, void *src)
>return ((int)dma_check());
> }
> #endif /*CONFIG_DDR_ECC*/
> +
> +#ifdef CONFIG_TSEC_ENET
> +/* Default initializations for TSEC controllers. To override,
> + * create a board-specific function called:
> + * int board_eth_init(bd_t *bis)
> + */
> +
> +extern int tsec_initialize(bd_t * bis, int index, char *devname);
> +
> +int cpu_eth_init(bd_t *bis)
> +{
> +#if defined(CONFIG_TSEC1)
> + tsec_initialize(bis, 0, CONFIG_TSEC1_NAME);
> +#endif
> +#if defined(CONFIG_TSEC2)
> + tsec_initialize(bis, 1, CONFIG_TSEC2_NAME);
> +#endif
> + return 0;
> +}
> +#endif
> diff --git a/cpu/mpc85xx/cpu.c b/cpu/mpc85xx/cpu.c
> index 9873383..7d82909 100644
> --- a/cpu/mpc85xx/cpu.c
> +++ b/cpu/mpc85xx/cpu.c
> @@ -279,3 +279,33 @@ int dma_xfer(void *dest, uint count, void *src) {
>return dma_check();
> }
> #endif
> +
> +#if defined(CONFIG_TSEC_ENET) || defined(CONFIGMPC85XX_FEC)
> +/* Default initializations for TSEC controllers. To override,
> + * create a board-specific function called:
> + * int board_eth_init(bd_t *bis)
> + */
> +
> +int tsec_initialize(bd_t * bis, int index, char *devname);
> +
> +int cpu_eth_init(bd_t *bis)
> +{
> +#if defined(CONFIG_TSEC1)
> + tsec_initialize(bis, 0, CONFIG_TSEC1_NAME);
> +#endif
> +#if defined(CONFIG_TSEC2)
> + tsec_initialize(bis, 1, CONFIG_TSEC2_NAME);
> +#endif
> +#if defined(CONFIG_MPC85XX_FEC)
> + tsec_initialize(bis, 2, CONFIG_MPC85XX_FEC_NAME);
> +#else
> +#if defined(CONFIG_TSEC3)
> + tsec_initialize(bis, 2, CONFIG_TSEC3_NAME);
> +#endif
> +#if defined(CONFIG_TSEC4)
> + tsec_initialize(bis, 3, CONFIG_TSEC4_NAME);
> +#endif
> +#endif
> + return 0;
> +}
> +#endif
> diff --git a/cpu/mpc86xx/cpu.c b/cpu/mpc86xx/cpu.c
> index 3c74764..79f227b 100644
> --- a/cpu/mpc86xx/cpu.c
> +++ b/cpu/mpc86xx/cpu.c
> @@ -288,3 +288,30 @@ void mpc86xx_reginfo(void)
>printf("\tBR7\t0x%08X\tOR7\t0x%08X \n", in_be32(&lbc->br7),
> in_be32(&lbc->or7));
>
> }
> +
> +#ifdef CONFIG_TSEC_ENET
> +/* Default initializations for TSEC controllers. To override,
> + * create a board-specific function called:
> + * int board_eth_init(bd_t *bis)
> + */
> +
> +extern int tsec_initialize(bd_t * bis, int index, char *devname);
> +
> +int cpu_eth_init(bd_t *bis)
> +{
> +#if defined(CONFIG_TSEC1)
> + tsec_initialize(bis, 0, CONFIG_TSEC1_NAME);
> +#endif
> +#if defined(CONFIG_TSEC2)
> + tsec_initialize(bis, 1, CONFIG_TSEC2_NAME);
> +#endif
> +#if defined(CONFIG_TSEC3)
> + tsec_initialize(bis, 2, CONFIG_TSEC3_NAME);
> +#endif
> +#if defined(CONFIG_TSEC4)
> + tsec_initialize(bis, 3, CONFIG_TSEC4_NAME);
> +#endif
> + return 0;
> +}
> +#endif
> +
> diff --git a/net/eth.c b/net/eth.c
> index c4f24c6..f12b9ed 100644
> --- a/net/eth.c
> +++ b/net/eth.c
> @@ -28,6 +28,12 @@
>
> #if defined(CONFIG_CMD_NET) && defined(CONFIG_NET_MULTI)
>
> +/* CPU and board-specific Ethernet initializations. Aliased function
> + * signals caller to move on */
> +static int __def_eth_init(bd_t *bis) {return -1;}
> +int cpu_eth_init(bd_t *bis) __attribute((weak, alias("__def_eth_init")));
> +int board_eth_init(bd_t *bis) __attribute((weak, alias("__def_eth_init")));
> +
&g
[U-Boot-Users] [PATCH V3] Add mechanisms for CPU and board-specific Ethernet initialization
This patch is the first step in cleaning up net/eth.c, by moving Ethernet
initialization to CPU or board-specific code. Initial implementation is
only on the Freescale TSEC controller, but others will be added soon.
Signed-off-by: Ben Warren <[EMAIL PROTECTED]>
---
This time around, instead of adding code to each board that implements TSEC, I
implemented cpu_eth_init() in all architectures that have TSEC. Preferably,
this would have gone in new files in the CPU directories, but 'ld' made it
impossible to guarantee that the code would be linked into the final executable.
Also, don't need include/netdev.h for now.
cpu/mpc83xx/cpu.c | 20
cpu/mpc85xx/cpu.c | 30 ++
cpu/mpc86xx/cpu.c | 27 +++
net/eth.c | 26 ++
4 files changed, 87 insertions(+), 16 deletions(-)
diff --git a/cpu/mpc83xx/cpu.c b/cpu/mpc83xx/cpu.c
index 36de78d..94d1a13 100644
--- a/cpu/mpc83xx/cpu.c
+++ b/cpu/mpc83xx/cpu.c
@@ -358,3 +358,23 @@ int dma_xfer(void *dest, u32 count, void *src)
return ((int)dma_check());
}
#endif /*CONFIG_DDR_ECC*/
+
+#ifdef CONFIG_TSEC_ENET
+/* Default initializations for TSEC controllers. To override,
+ * create a board-specific function called:
+ * int board_eth_init(bd_t *bis)
+ */
+
+extern int tsec_initialize(bd_t * bis, int index, char *devname);
+
+int cpu_eth_init(bd_t *bis)
+{
+#if defined(CONFIG_TSEC1)
+ tsec_initialize(bis, 0, CONFIG_TSEC1_NAME);
+#endif
+#if defined(CONFIG_TSEC2)
+ tsec_initialize(bis, 1, CONFIG_TSEC2_NAME);
+#endif
+ return 0;
+}
+#endif
diff --git a/cpu/mpc85xx/cpu.c b/cpu/mpc85xx/cpu.c
index 9873383..7d82909 100644
--- a/cpu/mpc85xx/cpu.c
+++ b/cpu/mpc85xx/cpu.c
@@ -279,3 +279,33 @@ int dma_xfer(void *dest, uint count, void *src) {
return dma_check();
}
#endif
+
+#if defined(CONFIG_TSEC_ENET) || defined(CONFIGMPC85XX_FEC)
+/* Default initializations for TSEC controllers. To override,
+ * create a board-specific function called:
+ * int board_eth_init(bd_t *bis)
+ */
+
+int tsec_initialize(bd_t * bis, int index, char *devname);
+
+int cpu_eth_init(bd_t *bis)
+{
+#if defined(CONFIG_TSEC1)
+ tsec_initialize(bis, 0, CONFIG_TSEC1_NAME);
+#endif
+#if defined(CONFIG_TSEC2)
+ tsec_initialize(bis, 1, CONFIG_TSEC2_NAME);
+#endif
+#if defined(CONFIG_MPC85XX_FEC)
+ tsec_initialize(bis, 2, CONFIG_MPC85XX_FEC_NAME);
+#else
+#if defined(CONFIG_TSEC3)
+ tsec_initialize(bis, 2, CONFIG_TSEC3_NAME);
+#endif
+#if defined(CONFIG_TSEC4)
+ tsec_initialize(bis, 3, CONFIG_TSEC4_NAME);
+#endif
+#endif
+ return 0;
+}
+#endif
diff --git a/cpu/mpc86xx/cpu.c b/cpu/mpc86xx/cpu.c
index 3c74764..79f227b 100644
--- a/cpu/mpc86xx/cpu.c
+++ b/cpu/mpc86xx/cpu.c
@@ -288,3 +288,30 @@ void mpc86xx_reginfo(void)
printf("\tBR7\t0x%08X\tOR7\t0x%08X \n", in_be32(&lbc->br7),
in_be32(&lbc->or7));
}
+
+#ifdef CONFIG_TSEC_ENET
+/* Default initializations for TSEC controllers. To override,
+ * create a board-specific function called:
+ * int board_eth_init(bd_t *bis)
+ */
+
+extern int tsec_initialize(bd_t * bis, int index, char *devname);
+
+int cpu_eth_init(bd_t *bis)
+{
+#if defined(CONFIG_TSEC1)
+ tsec_initialize(bis, 0, CONFIG_TSEC1_NAME);
+#endif
+#if defined(CONFIG_TSEC2)
+ tsec_initialize(bis, 1, CONFIG_TSEC2_NAME);
+#endif
+#if defined(CONFIG_TSEC3)
+ tsec_initialize(bis, 2, CONFIG_TSEC3_NAME);
+#endif
+#if defined(CONFIG_TSEC4)
+ tsec_initialize(bis, 3, CONFIG_TSEC4_NAME);
+#endif
+ return 0;
+}
+#endif
+
diff --git a/net/eth.c b/net/eth.c
index c4f24c6..f12b9ed 100644
--- a/net/eth.c
+++ b/net/eth.c
@@ -28,6 +28,12 @@
#if defined(CONFIG_CMD_NET) && defined(CONFIG_NET_MULTI)
+/* CPU and board-specific Ethernet initializations. Aliased function
+ * signals caller to move on */
+static int __def_eth_init(bd_t *bis) {return -1;}
+int cpu_eth_init(bd_t *bis) __attribute((weak, alias("__def_eth_init")));
+int board_eth_init(bd_t *bis) __attribute((weak, alias("__def_eth_init")));
+
#ifdef CFG_GT_6426x
extern int gt6426x_eth_initialize(bd_t *bis);
#endif
@@ -165,6 +171,10 @@ int eth_initialize(bd_t *bis)
#if defined(CONFIG_MII) || defined(CONFIG_CMD_MII)
miiphy_init();
#endif
+ /* Try board-specific initialization first. If it fails or isn't
+* present, try the cpu-specific initialization */
+ if (board_eth_init(bis) < 0)
+ cpu_eth_init(bis);
#if defined(CONFIG_DB64360) || defined(CONFIG_CPCI750)
mv6436x_eth_initialize(bis);
@@ -196,22 +206,6 @@ int eth_initialize(bd_t *bis)
#if defined(CONFIG_SK98)
skge_initialize(bis);
#endif
-#if defined(CONFIG_TSEC1)
- tsec_initialize(bis, 0, CONFIG_TSEC1_NAME);
-#endif
-#if defined(CONFIG_TSEC2)
- tsec_initialize(bis, 1, CONFIG_TSEC2_NAME);
-#endif
-#if defined(CONFIG_MPC85
