From mboxrd@z Thu Jan  1 00:00:00 1970
From: =?ISO-8859-15?Q?Felipe_Gil_Casti=F1eira?= <xil@uvigo.es>
Date: Wed, 04 Jan 2006 23:34:58 +0100
Subject: [U-Boot-Users] FEC problem on MPC5200 board (Men PP01)
In-Reply-To: <43BBF40D.1020201@smiths-aerospace.com>
References: <1136390455.17673.106.camel@neuromante.det.uvigo.es>	 <43BBF40D.1020201@smiths-aerospace.com>
Message-ID: <43BC4D92.5080907@uvigo.es>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

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.