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

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

[Felipe Gil Castiñeira]

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.

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

[Jerry Van Baren]

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.

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

[Felipe Gil Castiñeira]

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.

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

[Jerry Van Baren]

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