Hi Greg
Hi Domingos,
On 08/08/11 23:15, dh....@sapo.pt wrote:
Hi Greg.
Thanks for the reply...
On 05/08/11 19:53, dh...@sapo.pt wrote:
PROBLEM B:
I am using the uClinux-dist-20110603, and trying compile to MOD5272
(Netburner) kernel 2.4.x with m68k-uclinux-tools.
I have some problems with fec driver.
Configuration 1:
If i choose only this Kernell configuration:
[ * ]FEC ethernet controller (of coldfire 5272/5282/5280)
[ ] enable second FEC port (5274/5275)
[ ] enable IOCTL (EXPERIMENTAL)
[ ] Micrel KS8995M switch chip suport
In uClinux boot:
PHY is correctly recognized correctly:
......
fec.c: Probe number 1 with 0x0000
eth0: FEC ENET Version 0.2, 00:03:f4:04:49:4a
fec: PHY @ 0x1, ID 0x00221619 -- KS8721BL
......
But the ethernet don?t work correctly, ping for own IP works, ping for
other IP cause:
......
# ping -c 5 172.18.201.123
PING 172.18.201.123 (172.18.201.123): 56 data bytes
NETDEV WATCHDOG: eth0: transmit timed out
eth0: transmit timed out.
Ring data dump: cur_tx 2263100, dirty_tx 2263100 cur_rx: 2263008
........
--- 172.18.201.123 ping statistics ---
5 packets transmitted, 0 packets received, 100% packet loss
#
......
ping form other IP to MOD5272 too not work.
That could be because no link is detected. If you have a tool like
mii-tool or ethtool you can run on the board you could run that
to see.
The ifconfig detect eth0:
.....
# ifconfig
eth0 Link encap:Ethernet HWaddr 00:03:F4:04:49:4A
inet addr:172.18.201.19 Bcast:172.18.255.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Base address:0x840
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
......
I add the mii-tool and ethtool in uclinux configuration. But then none
of the applications seem to work.
.......
# mii-tool eth0
SIOCGMIIPHY on 'eth0' failed: Operation not supported
# ethtool -t eth0 online
Cannot get driver information: Operation not supported
.......
Configuration 2:
If i choose only this Kernell configuration:
[ * ]FEC ethernet controller (of coldfire 5272/5282/5280)
[ ] enable second FEC port (5274/5275)
[ ] enable IOCTL (EXPERIMENTAL)
[ * ] Micrel KS8995M switch chip suport
In uClinux boot:
PHY is NOT FOUND:
......
fec.c: Probe number 1 with 0x0000
eth0: FEC ENET Version 0.2, 00:03:f4:04:49:4a
FEC: No PHY device found.
......
But the ethernet work correctly, ping:
It could be that for the support of switch ports that link is ignored,
and always assumed to be "up".
Digging in source files i found, the difference between configuration
1 and 2 is in file: uClinux-dist/linux-2.4.x/drivers/net/fec.c
configuration 1: 171: #define PHY_START_ADDR 0
configuration 2: 164: #define PHY_START_ADDR 5
This is not the only difference between configuration 1 and 2, in file fec.c:
configuration 1:
.......
// These are values for ColdFire 5272 SIM
#define PHY_INT MCF_INT_INT2
#define PHY_START_ADDR 0
#define ICR_PHY_REG (MCF_MBAR + MCFSIM_ICR1)
#define ICR_PHY_MASK_IPL 0x77777777
#define ICR_PHY_MASK 0x70777777
#define ICR_MASK_IP 0x08000000
#define ICR_PHY_SETUP 0x0d000000
........
As can see MCF_INT_INT2 is associeted to PHY device. Looking in board
schematic, the MCF5272 /INT2 is not connect to INT of PHY IC (MICREL
KSZ8721BL).
The MCF5272 /INT2 is connected to VCC3V through 4.7K pull-up resistor,
and INT of PHY IC is Not Connected.
That could be the source of the problem. Because the MCF could be
waiting for an interrupt (/INT2) that will never happen.
Is that possible?
configuration 2:
........
# if defined(CONFIG_FEC_KS8995M)
#undef M5272_PHY_STAT_INT
#define PHY_START_ADDR 5
#define ICR_PHY_MASK 0xFFFFFFFF
#define ICR_PHY_SETUP 0x00000000
#define ICR_MASK_IP 0x00000000
........
Digging in mailing list uClinux-dev, i found many fec.c PATCHs...
Some for 2.4.x fec.c file, some for 2.6.x fec.c file, and others for
unknown fec.c file....
And, i got the doubt, if all these changes were present in the source
I am using??
If you follow the email trail for this patch though you will see
it is solved by a different code change. So you won't see that
exact code change in that patch. And this is probably true of a
few changes over the years if you follow the trail.
Ok, this was what I thought. I only ask to confirm.
PROBLEM A:
Back a little behind on my problem:
I had a image (made by another person) of uclinux (kernel 2.4.20-uc0).
This image works well in Netburner MOD5272 v1.3 (with PHY DAVICOM DM9161EP).
But in MOD5272 v1.2 (with PHY MICREL KSZ8721BL), it has a problem on
soft reboot (shell reboot command).
The problem is:
After rebbot command the board starup, but the ethernet never start
again, only with a hard reboot (remove the power).
I think this problem is related com o FEC driver, because the only
difference between normal startup and startup after reboot is:
In the normal startup:
.....
fec.c: Probe number 0 with 0x0000
eth0: FEC ENET Version 0.2, 00:03:f4:04:49:4a
fec: PHY @ 0x1, ID 0x00221619 -- unknown PHY!
.....
Startup after reboot command:
.....
fec.c: Probe number 0 with 0x0000
eth0: FEC ENET Version 0.2, 00:03:f4:04:49:4a
fec: PHY @ 0xf, ID 0x00221619 -- unknown PHY!
.....
Very strange. Wouldn't expect the to move from 0x1 to 0xf.
That could be the source of the problem.
Because in MOD5272 v1.3 (with PHY DAVICOM DM9161EP) PHY address is
always 0xe, and always ethernet work.
I try to force de phy->add = 0x1 but i don?t know the rigth place, in
file fec.c, to do that.
Is that possible? Or that do not solve the problem?
So, then to solve this problem I decided to compile the latest distro
of uClinux and see what happens.
And now I have problems with the same FEC driver.
What sort of PHY does your board actually have on it?
The PHY of my board is MICREL KSZ8721BL.
But if possible would like also supports to DAVICOM DM9161EP.
And what PHY address is it mapped to?
I do not know.
where can I see the definition of PHY address?
It is a property of the board design. Who ever laid out the board
would usually set that up with pull-ups/pull-downs on the PHY.
You're talking about PHYAD[0-4] pins of PHY IC, in datasheet says this
pins define the PHY address at power-up/reset.
I search in board schematic and this pins haven?t no
pull-ups/pull-downs configuration.
Only is connected to MCF through 49.9 ohm resistors.
This pins have double functions:
# PHY IC ----------------------- MCF5272
- INT#/PHYAD0 <------------->NC
- RXD3/PHYAD1<---49R9--->E_RXD3
- RXD2/PHYAD2<---49R9--->E_RXD2
- RXD1/PHYAD3<---49R9--->E_RXD1
- RXD0/PHYAD4<---49R9--->E_RXD0
Thanks
Best Regards
Domingos Goncalves
_______________________________________________
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
