1 | I have observed what seem to be strange |
---|
2 | initialization problems with the ethernet |
---|
3 | driver: |
---|
4 | |
---|
5 | I usually configure RTEMS networking by |
---|
6 | BOOTP (the problem has nothing to do with |
---|
7 | BOOTP but I just want to describe my |
---|
8 | environment). Sometimes (it can actually |
---|
9 | happen quite frequently, like 1 out of 4 |
---|
10 | attempts but since yesterday when I decided |
---|
11 | to hunt this down more systematically |
---|
12 | the problem seems to have gone - typical!) |
---|
13 | networking fails to initialize properly: |
---|
14 | |
---|
15 | BOOTP requests are sent (to the MAC), |
---|
16 | TX interrupts occur and the TX MIB |
---|
17 | counters increment - i.e., everything |
---|
18 | seems normal but no data can be seen on |
---|
19 | the wire. Also, even though we are on |
---|
20 | a quite busy network, the receiver |
---|
21 | doesn't see anything, i.e., 0 RX |
---|
22 | interrupts, RX MIB counters for broadcast |
---|
23 | packets remain steady at zero etc. |
---|
24 | In brief, everyting seems normal at the |
---|
25 | MAC and higher layers but no connection |
---|
26 | to the wire seems to be established. |
---|
27 | |
---|
28 | Some further tests reveal (system under |
---|
29 | test 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 | |
---|
54 | Especially point 2 seems to indicate that |
---|
55 | the problem is likely to be between the |
---|
56 | wire and the MAC somewhere but re-setting |
---|
57 | the PHY doesn't change things. Analysis is |
---|
58 | much complicated by the fact that there |
---|
59 | is no documentation on the BCM5461 chip |
---|
60 | available. |
---|
61 | |
---|
62 | Noteworthy is also that if the system |
---|
63 | initializes OK then it continues to work |
---|
64 | normally; if initialization fails then |
---|
65 | only resetting the board and restarting |
---|
66 | helps. |
---|
67 | |
---|
68 | I wanted to test if it makes a difference |
---|
69 | if MotLoad used the chip prior to RTEMS |
---|
70 | being booted (in case MotLoad did some |
---|
71 | magic step during initialization) but |
---|
72 | before I could really test this the |
---|
73 | problem went away. |
---|
74 | |
---|
75 | Big Mystery... |
---|
76 | |
---|
77 | 12/12/2007, T.S. |
---|