Re: [uClinux-dev] micrel PHY change between kernels on freescale 5275
On Fri, Aug 05, 2011 at 11:22:28AM +1000, Greg Ungerer wrote: The FEC driver is now also used by some of the ARM based Freescale iMX parts. So some changes have been required over the last couple of years :-) It also now uses phylib, and doesn't have its own phy specific support code in the driver. That caused me to have to fix things for some boards, like a 5272 board that had a switch connected - sort of like what you have. In that case I had to select and setup to use a fixed phy. I don't recall off hand which kernel switched the FEC driver to using phylib, so you may wan to check that first. But from the messages you report above I am pretty sure that is what 2.6.37-uc0 is using. The change was from 2.6.29 to 2.6.30. Which is why we are still running 2.6.29. Just haven't got around to porting our FEC hacks to the new driver yet. -- Len Sorensen ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
RE: [uClinux-dev] micrel PHY change between kernels on freescale 5275
Work around below if anyone is interested
On Fri, Aug 05, 2011 at 11:22:28AM +1000, Greg Ungerer wrote:
The FEC driver is now also used by some of the ARM based Freescale iMX
parts. So some changes have been required over the last couple of
years :-)
It also now uses phylib, and doesn't have its own phy specific support
code in the driver. That caused me to have to fix things for some
boards, like a 5272 board that had a switch connected - sort of like
what you have. In that case I had to select and setup to use a fixed
phy.
I don't recall off hand which kernel switched the FEC driver to using
phylib, so you may wan to check that first. But from the messages you
report above I am pretty sure that is what 2.6.37-uc0 is using.
The change was from 2.6.29 to 2.6.30. Which is why we are still running
2.6.29. Just haven't got around to porting our FEC hacks to the new driver
yet.
--
Len Sorensen
Thank you Len and Greg,
I don't have solid understanding of what is happening in the fec driver and
therefore don't really know the proper way to change the behavior so I won't
submit a patch,
but if anyone runs into a similar situation here is a possible workaround
(maybe save someone else some head scratching if they search the thread):
In static int fec_enet_mii_probe(struct net_device *dev) in fec.c
...
/* check for attached phy */
for (phy_id = 0; (phy_id PHY_MAX_ADDR); phy_id++) {
if ((fep-mii_bus-phy_mask (1 phy_id)))
continue;
if (fep-mii_bus-phy_map[phy_id] == NULL)
continue;
if (fep-mii_bus-phy_map[phy_id]-phy_id == 0)
continue;
strncpy(mdio_bus_id, fep-mii_bus-id, MII_BUS_ID_SIZE);
break;
}
if (phy_id = PHY_MAX_ADDR) {
printk(KERN_INFO %s: no PHY, assuming direct connection
to switch\n, dev-name);
strncpy(mdio_bus_id, 0, MII_BUS_ID_SIZE); // first part
of 1:xx
phy_id = 0; // second part
of x:01,x:02..etc
}
// HACK Start HERE
// phy_id = 0; // Doesn't exist
// phy_id = 1; // Right port of Micrel KSZ8873MLL
// phy_id = 2; // Left port of Micrel KSZ8873MLL
// phy_id = 3; // Both ports of Micrel KSZ8873MLL
// fep-mii_bus-phy_map[1] = 81D8FA00 //?
// fep-mii_bus-phy_map[2] = 81D8FC00 //?
// fep-mii_bus-phy_map[3] = 81D8FE00 //?
// However the
// fep-mii_bus-phy_map[1,2,OR3]-phy_id= 0x00221430 // This is the
actual phy ID of the Micrel KSZ8873MLL
// THUS the hack work around:
if(fep-mii_bus-phy_map[phy_id]-phy_id==0x00221430) // This is the
Micrel KSZ8873MLL
phy_id=3; // Hack to use both of the ports on
this Micrel KSZ8873MLL
// End of hack
snprintf(phy_name, MII_BUS_ID_SIZE, PHY_ID_FMT, mdio_bus_id, phy_id);
...
Ugly I know but maybe useful to someone.
Regards,
IMPORTANT NOTICE: This communication, including any attachments, is the
property of FreeWave Technologies, Inc. and may contain proprietary,
confidential, or privileged information. Unauthorized use or disclosure of this
communication is strictly prohibited and may be unlawful. Information contained
herein may be subject to a Proprietary Information / Non-Disclosure Agreement
and shall be maintained in confidence and not disclosed to third parties
without the written consent of FreeWave Technologies, Inc. If you have received
this communication in error, please immediately notify the sender and destroy
all copies of the communication and any attachments.
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] micrel PHY change between kernels on freescale 5275
I very recently took an old project that was running a version 2.6.12-uc0 and recompiled it to the newer 2.6.37-uc0 code base (shared memory, yippie!) The board has a micrel KSZ8873MLL PHY which is essentially a 3 port Ethernet switch allows for one of them to talk to the freescale 5275 and the other two to face the world as what appears as two Ethernet ports. While only using one of the FEC controllers on the 5275. In the 2.6.12 version of the kernel everything worked well. Both outside facing Ethernet ports worked just fine and everyone was happy. On the newer 2.6.37 kernel only one of the outside facing ports works while the other one does not appear to switch any traffic to the 5275. I took a gander through the drivers/net/fec.c file and actually had to marvel at how much different it is from the old driver code. Some other things I have noticed is that the old code only has the following traces in proc/kmsg: 4FEC ENET Version 0.2 4fec: PHY @ 0x1, ID 0x00221430 -- unknown PHY! While the new one has these: 6FEC Ethernet Driver 6fec_enet_mii_bus: probed 6eth0: Freescale FEC PHY driver [UNKNOWN] (mii_bus:phy_addr=1:01, irq=-1) 6PHY: 1:01 - Link is Up - 100/Full (Actually every time the link goes up/down the bottom line is added appropriately unlike the old kernel.) I am assuming that the reason for this is buried somewhere in the fec.c file potentially in the fec_enet_mii_probe() function or maybe in a mii write somewhere? Anyone have any ideas as to where this sort of configuration issue could be buried and how/where I can change things to get back to the old functionality? Regards, IMPORTANT NOTICE: This communication, including any attachments, is the property of FreeWave Technologies, Inc. and may contain proprietary, confidential, or privileged information. Unauthorized use or disclosure of this communication is strictly prohibited and may be unlawful. Information contained herein may be subject to a Proprietary Information / Non-Disclosure Agreement and shall be maintained in confidence and not disclosed to third parties without the written consent of FreeWave Technologies, Inc. If you have received this communication in error, please immediately notify the sender and destroy all copies of the communication and any attachments. ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] micrel PHY change between kernels on freescale 5275
Hi Jordan, On 05/08/11 09:04, Jordan Fuerst wrote: I very recently took an old project that was running a version 2.6.12-uc0 and recompiled it to the newer 2.6.37-uc0 code base (shared memory, yippie!) The board has a micrel KSZ8873MLL PHY which is essentially a 3 port Ethernet switch allows for one of them to talk to the freescale 5275 and the other two to face the world as what appears as two Ethernet ports. While only using one of the FEC controllers on the 5275. In the 2.6.12 version of the kernel everything worked well. Both outside facing Ethernet ports worked just fine and everyone was happy. On the newer 2.6.37 kernel only one of the outside facing ports works while the other one does not appear to switch any traffic to the 5275. I took a gander through the drivers/net/fec.c file and actually had to marvel at how much different it is from the old driver code. Some other things I have noticed is that the old code only has the following traces in proc/kmsg: 4FEC ENET Version 0.2 4fec: PHY @ 0x1, ID 0x00221430 -- unknown PHY! While the new one has these: 6FEC Ethernet Driver 6fec_enet_mii_bus: probed 6eth0: Freescale FEC PHY driver [UNKNOWN] (mii_bus:phy_addr=1:01, irq=-1) 6PHY: 1:01 - Link is Up - 100/Full (Actually every time the link goes up/down the bottom line is added appropriately unlike the old kernel.) I am assuming that the reason for this is buried somewhere in the fec.c file potentially in the fec_enet_mii_probe() function or maybe in a mii write somewhere? Anyone have any ideas as to where this sort of configuration issue could be buried and how/where I can change things to get back to the old functionality? The FEC driver is now also used by some of the ARM based Freescale iMX parts. So some changes have been required over the last couple of years :-) It also now uses phylib, and doesn't have its own phy specific support code in the driver. That caused me to have to fix things for some boards, like a 5272 board that had a switch connected - sort of like what you have. In that case I had to select and setup to use a fixed phy. I don't recall off hand which kernel switched the FEC driver to using phylib, so you may wan to check that first. But from the messages you report above I am pretty sure that is what 2.6.37-uc0 is using. Regards Greg Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com SnapGear Group, McAfee PHONE: +61 7 3435 2888 8 Gardner Close FAX: +61 7 3217 5323 Milton, QLD, 4064, AustraliaWEB: http://www.SnapGear.com ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
