From owner-freebsd-hackers Thu Apr 5 3:45:46 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ribbit.CS.Berkeley.EDU (ribbit.CS.Berkeley.EDU [128.32.131.152]) by hub.freebsd.org (Postfix) with ESMTP id 5C18937B43E for ; Thu, 5 Apr 2001 03:45:42 -0700 (PDT) (envelope-from istore-techs@CS.Berkeley.EDU) Received: (from root@localhost) by ribbit.CS.Berkeley.EDU (8.9.3/8.9.3) id DAA07790; Thu, 5 Apr 2001 03:45:42 -0700 (PDT) Date: Thu, 5 Apr 2001 03:45:42 -0700 (PDT) From: istore-techs@CS.Berkeley.EDU Message-Id: <200104051045.DAA07790@ribbit.CS.Berkeley.EDU> To: freebsd-hackers@FreeBSD.ORG Cc: istore-techs@CS.Berkeley.EDU Subject: unsupport fxp PHY's revisited Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG When booting FreeBSD 4.x on a system board with onboard fxp ethernet we developed for a research project here, we observe the same behaviour as described in the Dec 2000 -hackers thread "RE: yet another unsupported PHY in fxp driver" David Greenman wrote: : >nope, type 0, addr 0. does this indicate (perhaps) another size change? : : It indicates that something is wrong with the SEEPROM. Is it a SuperMicro : motherboard? If so, they changed the layout in the SEEPROM. Is a change in the SEEPROM the only cause for the fxp driver to detect a type and addr of 0 for the PHY in the 82559? Or are there other possible causes for this? I'm messing with hacking the fxp driver to force it to try and use the internal PHY -- I believe it's an 82555 from what I read in the earlier thread? -- but havent done serious testing of that yet. It is possible that company that did much of the fabrication/design work for us did something similar to what Mr Greenman described with the SuperMicro motherboard in the Dec 2000 thread. The markings on the chip itself say 82559C which intel's lighter-than-air datasheet says is the latest rev of the chipset. Intel also talks about an ipsec/crypto chip that can be coupled with the 82559C but we're not using that (and it's not supported in FreeBSD as far as I know anyway) more details below --Jon Kuroda ISTORE, another UCB EECS research project. From a verbose boot of a generic kernel: Onboard fxp0 (the wacky one) found-> vendor=0x8086, dev=0x1229, revid=0x09 class=02-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0 secondarybus=0 intpin=a, irq=10 map[10]: type 1, range 32, base febf9000, size 12 map[14]: type 1, range 32, base 0000ee80, size 6 map[18]: type 1, range 32, base feba0000, size 17 ... PCI card fxp4 (the normal well behaved one) found-> vendor=0x8086, dev=0x1229, revid=0x08 class=02-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0 secondarybus=0 intpin=a, irq=9 map[10]: type 1, range 32, base febfa000, size 12 map[14]: type 1, range 32, base 0000ef00, size 6 map[18]: type 1, range 32, base fea00000, size 20 ... fxp0: port 0xecc0-0xecff mem 0xfeb40000-0xfeb5ffff,0xfebf6000-0xfebf6fff irq 11 at device 15.0 on pci0 fxp0: Ethernet address 10:00:65:83:39:11 bpf: fxp0 attached (ethernet mac addr not standard for intel, specific to our site) .... fxp4: port 0xef00-0xef3f mem 0xfea00000-0xfeafffff,0xfebfa000-0xfebfafff irq 9 at device 20.0 on pci0 fxp4: Ethernet address 00:90:27:4f:db:e7 bpf: fxp4 attached ... fxp0: warning: unsupported PHY, type = 0, addr = 0 fxp4 (a normal intel pci card) has type = 7, addr = 1 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message