From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jerry Van Baren Date: Thu, 05 Jan 2006 09:05:14 -0500 Subject: [U-Boot-Users] FEC problem on MPC5200 board (Men PP01) In-Reply-To: <43BC4D92.5080907@uvigo.es> References: <1136390455.17673.106.camel@neuromante.det.uvigo.es> <43BBF40D.1020201@smiths-aerospace.com> <43BC4D92.5080907@uvigo.es> Message-ID: <43BD279A.50709@smiths-aerospace.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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