Hello, can someone help me? I have some problem with our MPC5200 board running denx linux kernel 2.4.25 with ethernet communication.
My problem is that our board stops receiving and transmitting any ethernet frames suddenly and unexpected. No pings - nothing is getting thru the ethernet any more! The rest of the controller is running well. This situation is very rare - only a constellation with 6 Controllers and a special ethernet communication load leads to this fault - in about one day! When i check how many tx and rx buffers are used in the BestComm buffer descriptor ring (via TaskBDInUse() call) which hold pointers to transmit and receive data, i see all tx and rx buffers are in use! When i look at the FEC Tx Fifo Status Register i get the value 0x00030000. This means FEC Tx Fifo empty! When i check fec Task Control register i see Tx and Rx Task are enabled, current Pointer register points to 0xF000828C which belongs to FEC Tx BestComm Microcode. When i now examine the status value of my currently active buffer descriptor for Tx task, it shows that this buffer belongs to BestComm. In my opinion BestComm shold tranfer this buffer to the empty FEC Tx Fifo - but it doesn't! Now the question for me is: WHY? Do i oversee some bits in the registers/ram locations which lead to this situation? I don't know much about BestComm/FEC, but my conclusion out of this is BestComm is stuck somewhere out of some reason. Is this a hardware issue? Does someone know? Has someone similar problems? Can someone help me or check if i'm right with my conclusion (see registers and ram locations down)? Or give me a hint where to look further. Any help is very welcome! Many Thanks, Eberhard PS: I saw this problem only on MPC5200B processors until now. And we use BestComm Api 2.2 (the newest denx 2.4.x code for bestcomm) Here are some registers and ram addresses i collected in this situation: BTW: I saw BestComm Microcode changing in 16k SRAM after the first Ethernet frames were sent. This seems very strange to me - but maybe is correct behaviour - i don't know. Does someone of you? Its the address 0xf00082e8 (in FEC Tx BestComm microcode). After reset (no frame sent) the ram at this address is 0x088AC398 after the first(?) ethernet frame it's 0x0C8AC398! === BestComm registers === taskBar 0xF0008000 currentPointer 0xF000828C endPointer 0x00000000 variablePointer 0xF0008800 IntVect1 0x0000000F IntVect2 0x0000000F PtdCntrl 0x00000001 IntPend 0x00000000 IntMask 0xFFFFFFF3 tcr_0 0x0000 tcr_1 0x0000 tcr_2 0xE082 tcr_3 0xC383 tcr_4 0x0000 tcr_5 0x0000 tcr_6 0x0000 tcr_7 0x0000 tcr_8 0x0000 tcr_9 0x0000 tcr_a 0x0000 tcr_b 0x0000 tcr_c 0x0000 tcr_d 0x0000 tcr_e 0x0000 tcr_f 0x0000 IPR0 0x07 IPR1 0x00 IPR2 0x00 IPR3 0x04 IPR4 0x03 IPR5 0x06 IPR6 0x05 IPR7 0x00 IPR8 0x00 IPR9 0x00 IPR10 0x00 IPR11 0x00 IPR12 0x00 IPR13 0x00 IPR14 0x00 IPR15 0x00 IPR16 0x00 IPR17 0x00 IPR18 0x00 IPR19 0x00 IPR20 0x00 IPR21 0x00 IPR22 0x00 IPR23 0x00 IPR24 0x00 IPR25 0x00 IPR26 0x00 IPR27 0x00 IPR28 0x00 IPR29 0x00 IPR30 0x00 IPR31 0x00 task_size0 0x00000000 task_size1 0x00000000 MDEDebug 0x01000008 ADSDebug 0x00000000 Value1 0x00000000 Value2 0x00000000 Control 0x00000000 Status 0x00000000 EU00 0x04155519 EU01 0x00000000 EU02 0x00000000 EU03 0x00000000 EU04 0x00000000 EU05 0x00000000 EU06 0x00000000 EU07 0x00000000 EU10 0x00000000 EU11 0x00000000 EU12 0x00000000 EU13 0x00000000 EU14 0x00000000 EU15 0x00000000 EU16 0x00000000 EU17 0x00000000 EU20 0x00000000 EU21 0x00000000 EU22 0x00000000 EU23 0x00000000 EU24 0x00000000 EU25 0x00000000 EU26 0x00000000 EU27 0x00000000 EU30 0x00000000 EU31 0x00000000 EU32 0x00000000 EU33 0x00000000 EU34 0x00000000 EU35 0x00000000 EU36 0x00000000 EU37 0x00000000 === Return values of BestComm Api Functions === t_tasknum = 2 TaskBDInUse(tx) = 256 TaskStatus(tx) = run (0x00008000) TaskIntPending(tx) = 0 r_tasknum = 3 TaskBDInUse(rx) = 256 TaskStatus(rx) = run (0x00008000) TaskIntPending(rx) = 0 TasksGetSramOffset = 0x00002500 task 0: stop int: 0x00000000 task 1: stop int: 0x00000000 task 2: run int: 0x00000000 task 3: run int: 0x00000000 task 4: stop int: 0x00000000 task 5: stop int: 0x00000000 task 6: stop int: 0x00000000 task 7: stop int: 0x00000000 task 8: stop int: 0x00000000 task 9: stop int: 0x00000000 task 10: stop int: 0x00000000 task 11: stop int: 0x00000000 task 12: stop int: 0x00000000 task 13: stop int: 0x00000000 task 14: stop int: 0x00000000 task 15: stop int: 0x00000000 === FEC Registers === fec base addr f0003000 fec_id 0x00000000 ievent 0x08000000 imask 0xF0FE0000 r_des_active 0x00000000 x_des_active 0x00000000 ecntrl 0xF0000002 mii_data 0x5F821200 mii_speed 0x0000001C mib_control 0x40000000 r_cntrl 0x05EE0024 r_hash 0x8A000000 x_cntrl 0x00000004 paddr1 0x00E0BA90 paddr2 0x07DC8808 op_pause 0x00010020 iaddr1 0x00000000 iaddr2 0x00000000 gaddr1 0x00400000 gaddr2 0x00000000 x_wmrk 0x00000000 rfifo_status 0x214E0000 rfifo_cntrl 0x0F240000 rfifo_lrf_ptr 0x0000005D rfifo_lwf_ptr 0x0000038D rfifo_alarm 0x0000030C rfifo_rdptr 0x0000005D rfifo_wrptr 0x0000005D tfifo_status 0x00030000 tfifo_cntrl 0x0F200000 tfifo_lrf_ptr 0x0000023C tfifo_lwf_ptr 0x0000023C tfifo_alarm 0x00000100 tfifo_rdptr 0x0000023C tfifo_wrptr 0x0000023C reset_cntrl 0x01000000 xmit_fsm 0x03000000 === FEC driver vars === MBAR 0xF0000000 MBAR SIZE 0x10000000 queue_stopped 1 mpc5xxx_bdi_tx 73 (x49) mpc5xxx_bdi_rx 97 (x61) adr(tx_fifo_skb) c0233744 adr(tx_fifo_skb[0]) c0233744 adr(tx_fifo_skb[1]) c0233748 tx_fifo_skb[0] c2474f20 tx_fifo_skb[1] c24846e0 sizeof(tx_fifo_skb) 1024 sizeof(tx_fifo_skb[0]) 4 MPC5xxx_FEC_TBD_NUM 256 adr(rx_fifo_skb) c0233b44 sizeof(rx_fifo_skb) 1024 sizeof(rx_fifo_skb[0]) 4 MPC5xxx_FEC_RBD_NUM 256 full_duplex 1 tx_full 1 r_tasknum 3 t_tasknum 2 r_irq 24 t_irq 23 last_transmit_time 0 last_receive_time 0 phy_id 0x0015F442 phy_id_done 1 phy_status 0x00000000 phy_speed 28 sequence_done 0 link 0 duplex_change 0 link_up 0 old_status 0x00000000 === BDHead Table === TASK #0 [0xC0232D74] = 0x00 [0xC0232D75] = 0x00 [0xC0232D76] = 0x00 [0xC0232D77] = 0x00 TASK #1 [0xC0232D78] = 0x00 [0xC0232D79] = 0x00 [0xC0232D7A] = 0x00 [0xC0232D7B] = 0x00 TASK #2 - tx task [0xC0232D7C] = 0x00 [0xC0232D7D] = 0x00 [0xC0232D7E] = 0x00 [0xC0232D7F] = 0x49 --> actual tx index: 0x49->73 TASK #3 - rx task [0xC0232D80] = 0x00 [0xC0232D81] = 0x00 [0xC0232D82] = 0x00 [0xC0232D83] = 0x61 --> actual rx index: 0x61->97 [0xC0232D84] = 0x00 [0xC0232D85] = 0x00 [0xC0232D86] = 0x00 ... === TaskBDIdxTable === TASK#0 numBD [0xC0232DF4] = 0x0000 numPtr [0xC0232DF6] = 0x00 apiConfig [0xC0232DF7] = 0x00 BDTablePtr [0xC0232DF8] = 0x00000000 BDStartPtr [0xC0232DFC] = 0x00000000 currBDInUse[0xC0232E00] = 0x0000 [0xC0232E02] = 0x00 [0xC0232E03] = 0x00 TASK#1 [0xC0232E04] = 0x00 [0xC0232E05] = 0x00 [0xC0232E06] = 0x00 [0xC0232E07] = 0x00 [0xC0232E08] = 0x00 [0xC0232E09] = 0x00 [0xC0232E0A] = 0x00 [0xC0232E0B] = 0x00 [0xC0232E0C] = 0x00 [0xC0232E0D] = 0x00 [0xC0232E0E] = 0x00 [0xC0232E0F] = 0x00 [0xC0232E10] = 0x00 [0xC0232E11] = 0x00 [0xC0232E12] = 0x00 [0xC0232E13] = 0x00 TASK#2 - tx task numBD [0xC0232E14] = 0x0100 numPtr [0xC0232E16] = 0x01 apiConfig [0xC0232E17] = 0x01 BDTablePtr [0xC0232E18] = 0xF0009D00 BDStartPtr [0xC0232E1C] = 0xF0008814 currBDInUse[0xC0232E20] = 0x0100 [0xC0232E22] = 0x00 [0xC0232E23] = 0x00 TASK#3 - rx task numBD [0xC0232E24] = 0x0100 numPtr [0xC0232E26] = 0x01 apiConfig [0xC0232E27] = 0x00 BDTablePtr [0xC0232E28] = 0xF0009500 BDStartPtr [0xC0232E2C] = 0xF0008890 currBDInUse[0xC0232E30] = 0x0100 [0xC0232E32] = 0x00 [0xC0232E33] = 0x00 TASK#4 [0xC0232E34] = 0x00 [0xC0232E35] = 0x00 ... === Tx Descriptor Ring === IDX 0x49-(73) is interesting, because active (see BDHeadTable). So our descriptor is as Addr 0xF0009D00 + (0x49 * 0x8) = 0xF0009F48 IDX 0 [0xF0009D00] = 0x4C00003C [0xF0009D04] = 0x02475922 IDX 1 [0xF0009D08] = 0x4C00003C [0xF0009D0C] = 0x02475CA2 ... IDX 72 [0xF0009F40] = 0x4C00003C [0xF0009F44] = 0x024665A2 IDX 73 - active descriptor [0xF0009F48] = 0x4C00004E - owns BestComm, should transfer [0xF0009F4C] = 0x0243F05E IDX 74 [0xF0009F50] = 0x4C00004E [0xF0009F54] = 0x0243F85E ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded