Sungem with iMac Rev-B

Sungem with iMac Rev-B

[Aurel Wisse]

Crossposted yellowdog-devel/linuxppc-devel, sorry but
this is last ditch...

I have read several comments about the sungem driver
being preferred to the bmac(+) driver.

Going through the sourcecode of the sungem, I am not
sure however that it will work with older hardware
like the iMac Rev-B's Uni-North and the LXT970.

I am trying to modify the bmac to force the PHY to
abandon autonegotiation and to use 10Mb/s and half
duplex. "Reverse engineering" the bmac code leads
nowhere. The bmac_init_phy doesn't give a lot of info,
except a couple of undocumented constants written via
bmac_mif_write, and the mif_write writes to the MIFCSR
register which is undocumented in the bmac.h file.

This is terribly frustrating as Apple is obviously
able to do it with their Duplex tool hack. Hence, it
*can* be done. Why can't they just send us their
sourcecode for the Duplex tool? Does anybody have a
direct line to Apple?

Aurel

Yahoo! Health - your guide to health and wellness
http://health.yahoo.com

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Sungem with iMac Rev-B

[Kevyn Shortell]

In talking to BenH there is currently no way to do this. Nor are there public documents from Apple explaining how to do this.

As I've said previously, the fastest way to do this, is spend 20 or so, or alot of time, because there is no easy answer to this programatically.

Kevyn
----- Original Message -----
From: "Aurel Wisse" <aurel_wisse@yahoo.com>
To: <linuxppc-dev@lists.linuxppc.org>; "yddev" <yellowdog-devel@lists.terrasoftsolutions.com>
Sent: Sunday, April 28, 2002 5:49 PM
Subject: Sungem with iMac Rev-B


> Crossposted yellowdog-devel/linuxppc-devel, sorry but
> this is last ditch...
>
> I have read several comments about the sungem driver
> being preferred to the bmac(+) driver.
>
> Going through the sourcecode of the sungem, I am not
> sure however that it will work with older hardware
> like the iMac Rev-B's Uni-North and the LXT970.
>
> I am trying to modify the bmac to force the PHY to
> abandon autonegotiation and to use 10Mb/s and half
> duplex. "Reverse engineering" the bmac code leads
> nowhere. The bmac_init_phy doesn't give a lot of info,
> except a couple of undocumented constants written via
> bmac_mif_write, and the mif_write writes to the MIFCSR
> register which is undocumented in the bmac.h file.
>
> This is terribly frustrating as Apple is obviously
> able to do it with their Duplex tool hack. Hence, it
> *can* be done. Why can't they just send us their
> sourcecode for the Duplex tool? Does anybody have a
> direct line to Apple?
>
> Aurel
>
> _______________________________________________
> yellowdog-devel mailing list
> yellowdog-devel@lists.terrasoftsolutions.com
> http://lists.terrasoftsolutions.com/mailman/listinfo/yellowdog-devel

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Sungem with iMac Rev-B

[Ethan Benson]

On Sun, Apr 28, 2002 at 05:49:45PM -0700, Aurel Wisse wrote:
>
> This is terribly frustrating as Apple is obviously
> able to do it with their Duplex tool hack. Hence, it
> *can* be done. Why can't they just send us their
> sourcecode for the Duplex tool? Does anybody have a
> direct line to Apple?

yes: mknod apple c 1 3

--
Ethan Benson
http://www.alaska.net/~erbenson/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Sungem with iMac Rev-B

[David A. Gatwood]

On Sun, 28 Apr 2002, Aurel Wisse wrote:

> I am trying to modify the bmac to force the PHY to
> abandon autonegotiation and to use 10Mb/s and half
> duplex. "Reverse engineering" the bmac code leads
> nowhere. The bmac_init_phy doesn't give a lot of info,
> except a couple of undocumented constants written via
> bmac_mif_write, and the mif_write writes to the MIFCSR
> register which is undocumented in the bmac.h file.
>
> This is terribly frustrating as Apple is obviously
> able to do it with their Duplex tool hack. Hence, it
> *can* be done. Why can't they just send us their
> sourcecode for the Duplex tool? Does anybody have a
> direct line to Apple?

Looked at the Darwin sources lately?  BMacEnet::miiInitializePHY appears
to describe the "normal" setup in a way that should make it pretty obvious
how to set it up in non-normal ways -- or perhaps not -- I've never dealt
with the chip, personally -- but it's a good starting point, anyway.


Later,
David

---------------------------------------------------------------------
David A. Gatwood                                dgatwood@gatwood.net
Developer Docs Writer                             dgatwood@apple.com
Apple Computer                                  dgatwood@mklinux.org

                    Check out my weekly web comic:
                     http://www.techmagazine.org


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Sungem with iMac Rev-B

[Benjamin Herrenschmidt]

>Crossposted yellowdog-devel/linuxppc-devel, sorry but
>this is last ditch...
>
>I have read several comments about the sungem driver
>being preferred to the bmac(+) driver.
>
>Going through the sourcecode of the sungem, I am not
>sure however that it will work with older hardware
>like the iMac Rev-B's Uni-North and the LXT970.

No, you mismatched bmac and gmac. The sungem driver obsoletes
the gmac one, not the bmac one.

The bmac driver currently don't have PHY control. This could
eventually be added, since I beleive we actually know how to
tap the PHY registers when available. Though this need some
work and I have no hardware to test on, so I'd rather see
someone who has do the job ;)

What we need is to add some proper PHY polling infrastructure
to the bmac driver (shouldn't be a big issue), then find out
the list of known PHYs used on Macs (I beleive the darwin source
code would be helpful here) and see how each of them can be
configured. If they aren't too crappy, the register setting for
enabling 10/100, half/full and autoneg are standard.

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Sungem with iMac Rev-B

[Michael Schmitz]

> >Going through the sourcecode of the sungem, I am not
> >sure however that it will work with older hardware
> >like the iMac Rev-B's Uni-North and the LXT970.
>
> No, you mismatched bmac and gmac. The sungem driver obsoletes
> the gmac one, not the bmac one.
>
> The bmac driver currently don't have PHY control. This could
> eventually be added, since I beleive we actually know how to
> tap the PHY registers when available. Though this need some
> work and I have no hardware to test on, so I'd rather see
> someone who has do the job ;)

Throw some hints (what to write where, approximately) my way and I might
give it a shot.

	Michael


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Sungem with iMac Rev-B

[benh]

>>
>> No, you mismatched bmac and gmac. The sungem driver obsoletes
>> the gmac one, not the bmac one.
>>
>> The bmac driver currently don't have PHY control. This could
>> eventually be added, since I beleive we actually know how to
>> tap the PHY registers when available. Though this need some
>> work and I have no hardware to test on, so I'd rather see
>> someone who has do the job ;)
>
>Throw some hints (what to write where, approximately) my way and I might
>give it a shot.

Well, driver side, look at the ethtool ioctl implementation in sungem, and
do something around those lines. You probably first need to properly detect
the PHY type by reading the 2 PHY_ID registers, then act depending on the PHY.

sungem has a mecanism that tries to fallback to fixed settings when autoneg
fails, you may want to skip that part though as it's a bit tricky.

Normally autoneg is enabled/disabled in the PHY control register, along with
the forced 10/100 modes and duplex mode. Look at what darwin does here.

Note that all this is only valid if you have an MII PHY, I don't think the
early bmac do that (bitbanging ?). You should probably make sure you have
a bmac+ and skip all the code (return fixed speed from ethtool ioctls)
on older bmac.

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/