[U-Boot-Users] FEC problem on MPC5200 board (Men PP01)

[Jerry Van Baren <gerald.vanbaren@smiths-aerospace.com>]

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