source: rtems/bsps/powerpc/mvme3100/KNOWN_PROBLEMS @ 5aa8ac2

5
Last change on this file since 5aa8ac2 was eb36d11, checked in by Sebastian Huber <sebastian.huber@…>, on 04/25/18 at 13:06:08

bsps: Move documentation, etc. files to bsps

This patch is a part of the BSP source reorganization.

Update #3285.

  • Property mode set to 100644
File size: 2.5 KB
Line 
1I have observed what seem to be strange
2initialization problems with the ethernet
3driver:
4
5I usually configure RTEMS networking by
6BOOTP (the problem has nothing to do with
7BOOTP but I just want to describe my
8environment). Sometimes (it can actually
9happen quite frequently, like 1 out of 4
10attempts but since yesterday when I decided
11to hunt this down more systematically
12the problem seems to have gone - typical!)
13networking fails to initialize properly:
14
15BOOTP requests are sent (to the MAC),
16TX interrupts occur and the TX MIB
17counters increment - i.e., everything
18seems normal but no data can be seen on
19the wire. Also, even though we are on
20a quite busy network, the receiver
21doesn't see anything, i.e., 0 RX
22interrupts, RX MIB counters for broadcast
23packets remain steady at zero etc.
24In brief, everyting seems normal at the
25MAC and higher layers but no connection
26to the wire seems to be established.
27
28Some further tests reveal (system under
29test is in the 'bad' state):
30 1 communication with the BCM5461 PHY
31   is normal. Registers can be read/written
32   and everything seems normal. In particular,
33   the link status is reported OK: disconnect
34   the cable and MII - BMSR bit 1<<2 is clear,
35   reconnect the cable and BMSR[2] is set.
36   Restart autoneg, the link goes and comes
37   back after a short while.
38 2 setting the loopback bit in the TSEC's
39   MACCFG1 register correctly feeds packets
40   back into the RX, RX MIB counters now
41   increment and indicate data flow.
42   There are RX interrupts and all indicates
43   (I haven't actually looked at RX packet
44   data) that the RX would work normally.
45   After switching MACCFG1[LOOP_BACK] off
46   no RX traffic can be seen anymore.
47 3 resetting the PHY (BMCR = 0x8000) and/or
48   restarting autoneg (BMCR = 0x1200) seems
49   to perform the desired action (registers
50   take on expected values) but still no luck
51   with communication all the way through
52   to the wire.
53
54Especially point 2 seems to indicate that
55the problem is likely to be between the
56wire and the MAC somewhere but re-setting
57the PHY doesn't change things. Analysis is
58much complicated by the fact that there
59is no documentation on the BCM5461 chip
60available.
61
62Noteworthy is also that if the system
63initializes OK then it continues to work
64normally; if initialization fails then
65only resetting the board and restarting
66helps.
67
68I wanted to test if it makes a difference
69if MotLoad used the chip prior to RTEMS
70being booted (in case MotLoad did some
71magic step during initialization) but
72before I could really test this the
73problem went away.
74
75Big Mystery...
76
7712/12/2007, T.S.
Note: See TracBrowser for help on using the repository browser.