[U-Boot-Users] FEC problem on MPC5200 board (Men PP01)
Hi everyone!
I am porting U-Boot to "Men mikro elektronik" PP01 module (MPC5200). The FEC is integrated on the MPC5200 and the PHY is a LXT971ALE transceiver.
U-Boot boots and recognizes the Ethernet device (I can read the PHY transceiver registers, change the LED status, etc.), but when I try to ping a target the system freezes (and the Watchdog resets the board). The behavior is just the same with tftp or bootp.
I am sure it is not a hardware problem, as I can transfer files (for example u-boot.bin) from a computer to the same module using the original monitor (MENMON).
From the debugging information *it seems the code fails in the function
"mpc5xxx_fec_recv"*. Furthermore, analyzing the network with Ethereal I can observe an ARP request generated by the PING and the corresponding answer (at this moment the watchdog resets the board). If I ping a non existent address the timer expires and I receive a "ping failed; host 192.168.1.25 is not alive" (Ethereal detects the ARP request, but of course, there is not an ARP answer).
Any idea? Thanks in advance.
Best regards, Felipe.
P.S.: I paste below the debugging info
*======================================================* *Ping to a non existent address (No answer)* *======================================================* => ping 192.168.1.22 Mii reg 0: 0x0000 Mii reg 1: 0x0000 Mii reg 2: 0x0000 Mii reg 3: 0x0000 Mii reg 4: 0x0000 Mii reg 5: 0x0000 Mii reg 6: 0x0000 Mii reg 7: 0x0000 Mii reg 8: 0x0000 Mii reg 16: 0x0000 Mii reg 17: 0x0000 Mii reg 18: 0x0000 Mii reg 19: 0x0000 Mii reg 20: 0x0000 Ethernet task stopped mpc5xxx_fec_init... Begin tfifo_status: 0x00010000 tfifo_alarm: 0x00000080 Mii reg 0: 0x1000 Mii reg 1: 0x782d Mii reg 2: 0x0013 Mii reg 3: 0x78e2 Mii reg 4: 0x01e1 Mii reg 5: 0x41e1 Mii reg 6: 0x0007 Mii reg 7: 0x2001 Mii reg 8: 0x0000 Mii reg 16: 0x0084 Mii reg 17: 0x4780 Mii reg 18: 0x0000 Mii reg 19: 0x0000 Mii reg 20: 0x0422 mpc5xxx_fec_init... Done Using FEC ETHERNET device sending ARP for c0a80116 ARP broadcast 1 tbd status: 0x0000 tbd_scrub: fec->cleanTbdNum = 48, fec->usedTbdIndex = 0 Tx Buffer Descriptor ring (tbd) limpo SDMA_TASK_ENABLE, fec->tbdIndex = 1 + ------------------------------------------------------------------------------------------------------------------------------------------2 tbd status: 0x0c00 tbd_scrub: fec->cleanTbdNum = 47, fec->usedTbdIndex = 0 SDMA_TASK_ENABLE, fec->tbdIndex = 2 + ------------------------------------------------------------------------------------------------------------------------------------------0 Mii reg 1: 0x782d Mii reg 2: 0x0013 Mii reg 3: 0x78e2 Mii reg 4: 0x01e1 Mii reg 5: 0x41e1 Mii reg 6: 0x0007 Mii reg 7: 0x2001 Mii reg 8: 0x0000 Mii reg 16: 0x0084 Mii reg 17: 0x4780 Mii reg 18: 0x0000 Mii reg 19: 0x0000 Mii reg 20: 0x0422 Ethernet task stopped ping failed; host 192.168.1.22 is not alive =>
*======================================================* *Ping to a existent address * *======================================================* => ping 192.168.1.1 Mii reg 0: 0x1000 Mii reg 1: 0x782d Mii reg 2: 0x0013 Mii reg 3: 0x78e2 Mii reg 4: 0x01e1 Mii reg 5: 0x41e1 Mii reg 6: 0x0007 Mii reg 7: 0x2001 Mii reg 8: 0x0000 Mii reg 16: 0x0084 Mii reg 17: 0x4780 Mii reg 18: 0x0000 Mii reg 19: 0x0000 Mii reg 20: 0x0422 Ethernet task stopped mpc5xxx_fec_init... Begin tfifo_status: 0x00010000 tfifo_alarm: 0x00000080 Mii reg 0: 0x1000 Mii reg 1: 0x782d Mii reg 2: 0x0013 Mii reg 3: 0x78e2 Mii reg 4: 0x01e1 Mii reg 5: 0x41e1 Mii reg 6: 0x0007 Mii reg 7: 0x2001 Mii reg 8: 0x0000 Mii reg 16: 0x0084 Mii reg 17: 0x4780 Mii reg 18: 0x0000 Mii reg 19: 0x0000 Mii reg 20: 0x0422 mpc5xxx_fec_init... Done Using FEC ETHERNET device sending ARP for c0a80101 ARP broadcast 1 tbd status: 0x0000 tbd_scrub: fec->cleanTbdNum = 48, fec->usedTbdIndex = 0 Tx Buffer Descriptor ring (tbd) limpo SDMA_TASK_ENABLE, fec->tbdIndex = 1 + <<<----After the "+" the system hangs.
Felipe Gil Castiñeira wrote:
Hi everyone!
I am porting U-Boot to "Men mikro elektronik" PP01 module (MPC5200). The FEC is integrated on the MPC5200 and the PHY is a LXT971ALE transceiver.
U-Boot boots and recognizes the Ethernet device (I can read the PHY transceiver registers, change the LED status, etc.), but when I try to ping a target the system freezes (and the Watchdog resets the board). The behavior is just the same with tftp or bootp.
I am sure it is not a hardware problem, as I can transfer files (for example u-boot.bin) from a computer to the same module using the original monitor (MENMON).
From the debugging information *it seems the code fails in the function
"mpc5xxx_fec_recv"*. Furthermore, analyzing the network with Ethereal I can observe an ARP request generated by the PING and the corresponding answer (at this moment the watchdog resets the board). If I ping a non existent address the timer expires and I receive a "ping failed; host 192.168.1.25 is not alive" (Ethereal detects the ARP request, but of course, there is not an ARP answer).
Any idea? Thanks in advance.
Best regards, Felipe.
I don't know anything about your hardware, but from your description of the results I would guess that you have your ethernet receive buffer pointer(s) pointing into non-existant memory (very likely) or else pointing in the middle of important code (e.g. u-boot or your variables).
Scenario A: When you receive a packet, you get a bus fault which crashes your machine.
Scenario B: When you receive a packet, it scribbles on your code and crashes your machine.
I suggest you check your memory configuration and Rx buffer initialization.
gvb
P.S. If you send a broadcast (ping your target will cause an arp broadcast) or a packet directed to your target's MAC address (use the command line arp command to add your MAC address on your host machine and then send a ping), I bet your target will crash.
On Mér, 2006-01-04 at 11:13 -0500, Jerry Van Baren wrote:
Felipe Gil Castiñeira wrote:
Hi everyone!
I am porting U-Boot to "Men mikro elektronik" PP01 module (MPC5200). The FEC is integrated on the MPC5200 and the PHY is a LXT971ALE transceiver.
U-Boot boots and recognizes the Ethernet device (I can read the PHY transceiver registers, change the LED status, etc.), but when I try to ping a target the system freezes (and the Watchdog resets the board). The behavior is just the same with tftp or bootp.
I am sure it is not a hardware problem, as I can transfer files (for example u-boot.bin) from a computer to the same module using the original monitor (MENMON).
From the debugging information *it seems the code fails in the function
"mpc5xxx_fec_recv"*. Furthermore, analyzing the network with Ethereal I can observe an ARP request generated by the PING and the corresponding answer (at this moment the watchdog resets the board). If I ping a non existent address the timer expires and I receive a "ping failed; host 192.168.1.25 is not alive" (Ethereal detects the ARP request, but of course, there is not an ARP answer).
Any idea? Thanks in advance.
Best regards, Felipe.
I don't know anything about your hardware, but from your description of the results I would guess that you have your ethernet receive buffer pointer(s) pointing into non-existant memory (very likely) or else pointing in the middle of important code (e.g. u-boot or your variables).
Scenario A: When you receive a packet, you get a bus fault which crashes your machine.
Scenario B: When you receive a packet, it scribbles on your code and crashes your machine.
I suggest you check your memory configuration and Rx buffer initialization.
gvb
P.S. If you send a broadcast (ping your target will cause an arp broadcast) or a packet directed to your target's MAC address (use the command line arp command to add your MAC address on your host machine and then send a ping), I bet your target will crash.
Thanks Jerry,
As you supposed if I send a packet to the board's MAC it crashes immediately or in the next access to the FEC (a ping from the MPC5200 board).
I tried to understand where is the Rx buffer but the code is complex and I am not completely sure how it works. I think there is a "TxBD ring" and a "RxBD ring" which store pointers (among other things) to the data to be sent or received. These pointers are in SRAM and are read by the SDMA (Smart DMA). In the case of the received data, I think that the memory is "malloced"in "fec.c", so the received data should be in the "malloc area" (DRAM).
I increased the malloc area to 1 MB, so there is enough space. The TxBD and RxBD rings are defined in a similar way and the Tx works correctly so I suppose the problem is not here (I couldn't find anything wrong with the SRAM).
It seems that you are right, but I can't find anything wrong. As I stated before, I am not sure this is the way the packet reception works: perhaps Wolfgang can confirm/reject this. Any other suggestion?
Best regards, Felipe.
Felipe Gil Castiñeira wrote:
On Mér, 2006-01-04 at 11:13 -0500, Jerry Van Baren wrote:
Felipe Gil Castiñeira wrote:
Hi everyone!
I am porting U-Boot to "Men mikro elektronik" PP01 module
(MPC5200). The
FEC is integrated on the MPC5200 and the PHY is a LXT971ALE
transceiver.
U-Boot boots and recognizes the Ethernet device (I can read the PHY
transceiver registers, change the LED status, etc.), but when I try to ping a target the system freezes (and the Watchdog resets the board). The behavior is just the same with tftp or bootp. > > I am sure it
is not a hardware problem, as I can transfer files (for
example u-boot.bin) from a computer to the same module using the original monitor (MENMON).
From the debugging information *it seems the code fails in the
function
"mpc5xxx_fec_recv"*. Furthermore, analyzing the network with
Ethereal I
can observe an ARP request generated by the PING and the corresponding answer (at this moment the watchdog resets the board). If I ping a non existent address the timer expires and I receive a "ping failed; host 192.168.1.25 is not alive" (Ethereal detects the ARP request, but of course, there is not an ARP answer).
Any idea? Thanks in advance. Best regards,
Felipe.I don't know anything about your hardware, but from your description of the results I would guess that you have your ethernet receive buffer pointer(s) pointing into non-existant memory (very likely) or else pointing in the middle of important code (e.g. u-boot or your variables).
Scenario A: When you receive a packet, you get a bus fault which crashes your machine.
Scenario B: When you receive a packet, it scribbles on your code and crashes your machine.
I suggest you check your memory configuration and Rx buffer initialization.
gvb
P.S. If you send a broadcast (ping your target will cause an arp broadcast) or a packet directed to your target's MAC address (use the command line arp command to add your MAC address on your host machine and then send a ping), I bet your target will crash.
Thanks Jerry,
As you supposed if I send a packet to the board's MAC it crashes immediately or in the next access to the FEC (a ping from the MPC5200 board).
I tried to understand where is the Rx buffer but the code is complex and I am not completely sure how it works. I think there is a "TxBD ring" and a "RxBD ring" which store pointers (among other things) to the data to be sent or received. These pointers are in SRAM and are read by the SDMA (Smart DMA). In the case of the received data, I think that the memory is "malloced"in "fec.c", so the received data should be in the "malloc area" (DRAM).
I increased the malloc area to 1 MB, so there is enough space. The TxBD and RxBD rings are defined in a similar way and the Tx works correctly so I suppose the problem is not here (I couldn't find anything wrong with the SRAM).
It seems that you are right, but I can't find anything wrong. As I stated before, I am not sure this is the way the packet reception works: perhaps Wolfgang can confirm/reject this. Any other suggestion?
Best regards, Felipe.
Hi Felipe,
Time to crank up the debugger, set a breakpoint in mpc5xxx_fec_recv, and start to learn the code. The good news is that identifying _where_ the problem is and how to easily reproduce it on demand is 80% (or more!) of the debug time.
If you don't have a JTAG debugger, sprinkle in print statements. Look for invalid pointers - print out pointers before they are used.
gvb
participants (3)
-
Felipe Gil Castiñeira -
Felipe Gil Castiñeira -
Jerry Van Baren