linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
* 2.4.0-test11 - MPC860T FEC question.
@ 2000-12-04  0:43 Wolfgang Denk
  2000-12-04  8:58 ` Wolfgang Denk
  0 siblings, 1 reply; 4+ messages in thread
From: Wolfgang Denk @ 2000-12-04  0:43 UTC (permalink / raw)
  Cc: Dan Malek, linuxppc-embedded


Dan,

I just found another problem with the FEC / MII code. It happens when
I try to use BOOTP in the LInux kernel (I haven't been doing this for
a long time, since _if_ we use BOOTP, we do so in PPCBoot,  and  pass
all information to the kernel instead of running BOOTP twice).

Here is what I see:

Linux version 2.4.0-test11 (wd@denx.local.net) (gcc version 2.95.2 19991024 (release)) #1 Mon Dec 4 00:19:12 MET 2000
Boot arguments: root=/dev/nfs rw ip=bootp
On node 0 totalpages: 4096
zone(0): 4096 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: root=/dev/nfs rw ip=bootp
Decrementer Frequency: 3125000
Calibrating delay loop... 49.87 BogoMIPS
Memory: 14664k available (980k kernel code, 388k data, 44k init, 0k highmem)
Dentry-cache hash table entries: 2048 (order: 2, 16384 bytes)
Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes)
Page-cache hash table entries: 4096 (order: 2, 16384 bytes)
Inode-cache hash table entries: 1024 (order: 1, 8192 bytes)
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Starting kswapd v1.8
CPM UART driver version 0.03
ttyS00 at 0x0280 is a SMC
pty: 256 Unix98 ptys configured
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 50MHz system bus speed for PIO modes; override with idebus=xx
hda: IBM-DCXA-210000, ATA DISK drive
ide0 at 0xc2000000-0xc2000007,0xc2000106 on irq 10
hda: 19640880 sectors (10056 MB) w/420KiB Cache, CHS=19485/16/63
Partition check:
 hda: [mac] hda1 hda2 hda3 hda4 hda5 hda6
eth0: FEC ENET Version 0.2, FEC irq 9, MII irq 12, addr 00:d0:93:00:01:cb
eth0: Phy @ 0x0, type LXT971 (0x001378e1)
eth1: FEC ENET Version 0.2, FEC irq 9, MII irq 12, addr 00:d0:93:00:01:cb
eth0: Phy @ 0x0, type LXT971 (0x001378e1)
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 1024 bind 1024)
eth0: config: auto-negotiation on, 100HDX, 10HDX.
IP-Config: Failed to open eth1
Sending BOOTP requests............. timed out!
IP-Config: Auto-configuration of network failed.
eth0: status: link up, 100 Mbps Half Duplex, auto-negotiation complete.
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
kmem_create: Forcing size word alignment - nfs_fh
Root-NFS: No NFS server available, giving up.
...


It seems the "link up" interrupt comes much too late for the
"IP-Config" part; shouldn't we wait in fec_enet_open() for
"fep->link" to come up?

And do you have an idea why there is a "eth1" detected?

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
"Confound these ancestors.... They've stolen our best ideas!"
- Ben Jonson

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: 2.4.0-test11 - MPC860T FEC question.
  2000-12-04  0:43 2.4.0-test11 - MPC860T FEC question Wolfgang Denk
@ 2000-12-04  8:58 ` Wolfgang Denk
  2000-12-06 22:11   ` Dan Malek
  0 siblings, 1 reply; 4+ messages in thread
From: Wolfgang Denk @ 2000-12-04  8:58 UTC (permalink / raw)
  To: Dan Malek; +Cc: linuxppc-embedded


I wrote:

> I just found another problem with the FEC / MII code. It happens when
> I try to use BOOTP in the Linux kernel (I haven't been doing this for
> a long time, since _if_ we use BOOTP, we do so in PPCBoot,  and  pass
> all information to the kernel instead of running BOOTP twice).
>
> Here is what I see:
...

I fixed one of the problems, which was my own fault when patching the
code.

But the other one remains:

...
CPM UART driver version 0.03
ttyS00 at 0x0280 is a SMC
pty: 256 Unix98 ptys configured
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 50MHz system bus speed for PIO modes; override with idebus=xx
hda: IBM-DCXA-210000, ATA DISK drive
ide0 at 0xc2000000-0xc2000007,0xc2000106 on irq 10
hda: 19640880 sectors (10056 MB) w/420KiB Cache, CHS=19485/16/63
Partition check:
 hda: [mac] hda1 hda2 hda3 hda4 hda5 hda6
eth0: FEC ENET Version 0.2, FEC irq 9, MII irq 12, addr 00:d0:93:00:01:cb
eth0: Phy @ 0x0, type LXT971 (0x001378e1)
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 1024 bind 1024)
eth0: config: auto-negotiation on, 100HDX, 10HDX.
Sending BOOTP requests............. timed out!
IP-Config: Auto-configuration of network failed.
eth0: status: link up, 100 Mbps Half Duplex, auto-negotiation complete.
...

Then I wrote:

> It seems the "link up" interrupt comes much too late for the
> "IP-Config" part; shouldn't we wait in fec_enet_open() for
> "fep->link" to come up?

I was wrong here. The _interrupt_ comes  just  when  it  should.  The
problem is that the function which actually sets the "fep->link" flag
(mii_relink)  is  not  run  immediately,  but  from a queue_task(...,
&tq_scheduler) call - and it's scheduled much too late for  BOOTP  to
work.

I have hacked the code so that it sets the "fep->link" flag in
mii_parse_sr() which actually detects the status change. Now I get:

...
eth0: FEC ENET Version 0.2, FEC irq 9, MII irq 12, addr 00:d0:93:00:01:cb
eth0: Phy @ 0x0, type LXT971 (0x001378e1)
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 1024 bind 1024)
eth0: config: auto-negotiation on, 100HDX, 10HDX.
Sending BOOTP requests.... OK
IP-Config: Got BOOTP answer from 10.0.0.2, my address is 10.0.0.99
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
kmem_create: Forcing size word alignment - nfs_fh
Looking up port of RPC 100003/2 on 10.0.0.2
eth0: status: link up, 100 Mbps Half Duplex, auto-negotiation complete.
Looking up port of RPC 100005/2 on 10.0.0.2
VFS: Mounted root (nfs filesystem).
Freeing unused kernel memory: 44k init
Stand-alone shell (version 2.1)
>

This works for me, but it's still conceptually  broken.  mii_relink()
is still running much too late (it doesn't do any harm though).

How should we handle this? I've tried to  compare  against  the  82xx
code  in "fcc_enet.c", but this seems to be kind of incomplete; there
is no mii_link code at all, and the mii_relink()  function  is  never
used.

Am I missing something? Isn't bk://hq.fsmlabs.com:5005  the  location
for most current sources?

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
"It's when they say 2 + 2 = 5 that I begin to argue."    - Eric Pepke

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: 2.4.0-test11 - MPC860T FEC question.
  2000-12-04  8:58 ` Wolfgang Denk
@ 2000-12-06 22:11   ` Dan Malek
  2000-12-06 23:47     ` Wolfgang Denk
  0 siblings, 1 reply; 4+ messages in thread
From: Dan Malek @ 2000-12-06 22:11 UTC (permalink / raw)
  To: Wolfgang Denk; +Cc: linuxppc-embedded


Wolfgang Denk wrote:

> I was wrong here. The _interrupt_ comes  just  when  it  should.  The
> problem is that the function which actually sets the "fep->link" flag
> (mii_relink)  is  not  run  immediately,  but  from a queue_task(...,

I don't like the queue_task stuff (this wasn't my doing).  The MII/link
interrupt should be handled as part of the interrupt handler like it
used to be (until the late 2.3.99 code when this was changed).

> &tq_scheduler) call - and it's scheduled much too late for  BOOTP  to
> work.

Well, BOOTP in the kernel is going away soon, so it won't matter
much longer.


> How should we handle this? I've tried to  compare  against  the  82xx
> code  in "fcc_enet.c", but this seems to be kind of incomplete; there
> is no mii_link code at all, and the mii_relink()  function  is  never
> used.

The 8260 is very incomplete.  The problem is the MII control/status
is disconnected from the ethernet controller.  The 860T FEC would
generate an interrupt when the bit shifting was done, but the 8260
requires software to do this.  The 8260 is going to get one of two
equally ugly solutions, either a tasklet that runs for the purpose of
managing the MII, or to simply to software shift and poll the MII in
line with other functions.  I stared with the FEC driver on the 8260,
hoping I could find a way to utilize the better multiple PHY support,
but I ended up just hacking it out and leaving a few functions around
as a reminder to try and find some common MII functions with the FEC.
It's not happening very fast.


	-- Dan

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: 2.4.0-test11 - MPC860T FEC question.
  2000-12-06 22:11   ` Dan Malek
@ 2000-12-06 23:47     ` Wolfgang Denk
  0 siblings, 0 replies; 4+ messages in thread
From: Wolfgang Denk @ 2000-12-06 23:47 UTC (permalink / raw)
  To: Dan Malek; +Cc: linuxppc-embedded


Hi Dan,

in message <3A2EB9A5.65311F2E@mvista.com> you wrote:
>
> I don't like the queue_task stuff (this wasn't my doing).  The MII/link
> interrupt should be handled as part of the interrupt handler like it
> used to be (until the late 2.3.99 code when this was changed).

Well, I just spent more than an hour to back-port the  FEC  stuff  to
the  2.2.14  kernel  because I needed a working FEC driver there, and
fast.

> The 8260 is very incomplete.  The problem is the MII control/status
> is disconnected from the ethernet controller.  The 860T FEC would
> generate an interrupt when the bit shifting was done, but the 8260
> requires software to do this.  The 8260 is going to get one of two
> equally ugly solutions, either a tasklet that runs for the purpose of
> managing the MII, or to simply to software shift and poll the MII in
> line with other functions.  I stared with the FEC driver on the 8260,

I don't like the idea of having completely different code in  several
places for dealing with essentially the same thing.

Now we have the FEC code for the 8xx in 2.2.14, for the 8xx in 2.4.x,
and for the 82xx in 2.4.x - and it's difficult  to  recognize  common
parts.

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
"Wagner's music is better than it sounds."               - Mark Twain

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2000-12-06 23:47 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2000-12-04  0:43 2.4.0-test11 - MPC860T FEC question Wolfgang Denk
2000-12-04  8:58 ` Wolfgang Denk
2000-12-06 22:11   ` Dan Malek
2000-12-06 23:47     ` Wolfgang Denk

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).