405GP Networking issue

405GP Networking issue

[KISHINAMI Masaya]

Dear all, it's first time to post.

We are debugging a custom board designed based on the 405GP
(200MHz) and have a problem not being sent ECHO REPLY ping
packet from custom board to our PC via repeater hub on the
heavy traffic under 10Mbps and half duplex condition.
We used the latest version of ibm_ocp LAN device driver at
that time from kernel 2.4.21-pre3 and ported it to work on
the kernel 2.4.18 because it costs many time to boot our
custom board on the latest one. The board works fine unless
not be such a case.

Following are the our simplest duplication process and the
results.

1. Connect the repeater hub to backbone LAN.
2. Connect custom board, test PC to ping and other PCs to the
   repeater hub to the full. This case, 10 or more PCs are
   connected to repeater hub and each PC works normally by
   using network.
3. Increase the traffic by using ftp command. The ftp data was
   never addressed to the custom board.
4. Ping from our PC to custom board at one time.
5. The 60% pings were lost such condition.
6. We investigated the ping lost case.
   - LAN protocol analyzer captured the ECHO REQUEST which was
     address to custom board. It shows ECHO REQUEST was issued
     from our PC to LAN cable.
   - Logic analyzer captured the same ping packet which was
     already been captured by LAN analyzer between PHY(Intel
     LXT971A) and EMAC. It shows ECHO REQUEST was reached just
     before the EMAC.
   - The LAN device driver's receive buffer did not receive the
     ECHO REQUEST by using printk command. We suspected that the
     ECHO REQUEST was not issued to the MAL(Memory Access Layer),
     therefore ECHO REQUEST was not translated to the receive
     buffer.

At the same time, many 4 byte short packet(0x000000f0) which was
not addressed to custom board was received to the LAN device driver's
receive buffer with error status. According to 405GP manual, EMAC
discards the packet which is not of its own.

Have anyone experienced a problem like this?
Any help would be appreciated.

Regards, Kishinami.

-----
KISHINAMI Masaya
Fujitsu Limited (Japan)

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

AW: 405GP Networking issue

[Georg Klug]

Hi Kishinami,

> We are debugging a custom board designed based on the 405GP
> (200MHz) and have a problem not being sent ECHO REPLY ping
> packet from custom board to our PC via repeater hub on the
> heavy traffic under 10Mbps and half duplex condition.

> ...

> Following are the our simplest duplication process and the
> results.
>
> 1. Connect the repeater hub to backbone LAN.
> 2. Connect custom board, test PC to ping and other PCs to the
>    repeater hub to the full. This case, 10 or more PCs are
>    connected to repeater hub and each PC works normally by
>    using network.
> 3. Increase the traffic by using ftp command. The ftp data was
>    never addressed to the custom board.
> 4. Ping from our PC to custom board at one time.
> 5. The 60% pings were lost such condition.
> 6. We investigated the ping lost case.
>    - LAN protocol analyzer captured the ECHO REQUEST which was
>      address to custom board. It shows ECHO REQUEST was issued
>      from our PC to LAN cable.
>    - Logic analyzer captured the same ping packet which was
>      already been captured by LAN analyzer between PHY(Intel
>      LXT971A) and EMAC. It shows ECHO REQUEST was reached just
>      before the EMAC.
>    - The LAN device driver's receive buffer did not receive the
>      ECHO REQUEST by using printk command. We suspected that the
>      ECHO REQUEST was not issued to the MAL(Memory Access Layer),
>      therefore ECHO REQUEST was not translated to the receive
>      buffer.
>
> At the same time, many 4 byte short packet(0x000000f0) which was
> not addressed to custom board was received to the LAN device driver's
> receive buffer with error status. According to 405GP manual, EMAC
> discards the packet which is not of its own.

to me it looks like an half duplex issue. You should check whether both:
sender and receiver know that they are connected to a half duplex hub.
Otherwise collisions could occur which are not detected by the receiver
and also not by the transmitting entity. So you should make sure that
FDE is set to 0 in the EMAC Mode register 1 (EMAC0_MR1) according to
the Users manual)

Georg


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: AW: 405GP Networking issue

[KISHINAMI Masaya]

Hi Georg,

Thank you for your suggestion. However, we once checked the EMAC0_MR1,
and it was right configuration. Sorry, not to be informed to you.
But I'll check once again. As a fact, this problem does not happen
everywhere. We need to go another place and it's far from here. Therefore,
next investigation will be held at the middle of next week.
I will keep you informed as more information becomes available.

Regards, Kishinami

--- On Fri, 28 Feb 2003 22:59:11 +0900 Georg Klug<gklug@giga-stream.de> -san wrote:

>> We are debugging a custom board designed based on the 405GP
>> (200MHz) and have a problem not being sent ECHO REPLY ping
>> packet from custom board to our PC via repeater hub on the
>> heavy traffic under 10Mbps and half duplex condition.
>
>> ...
>
>> Following are the our simplest duplication process and the
>> results.
>>
>> 1. Connect the repeater hub to backbone LAN.
>> 2. Connect custom board, test PC to ping and other PCs to the
>>    repeater hub to the full. This case, 10 or more PCs are
>>    connected to repeater hub and each PC works normally by
>>    using network.
>> 3. Increase the traffic by using ftp command. The ftp data was
>>    never addressed to the custom board.
>> 4. Ping from our PC to custom board at one time.
>> 5. The 60% pings were lost such condition.
>> 6. We investigated the ping lost case.
>>    - LAN protocol analyzer captured the ECHO REQUEST which was
>>      address to custom board. It shows ECHO REQUEST was issued
>>      from our PC to LAN cable.
>>    - Logic analyzer captured the same ping packet which was
>>      already been captured by LAN analyzer between PHY(Intel
>>      LXT971A) and EMAC. It shows ECHO REQUEST was reached just
>>      before the EMAC.
>>    - The LAN device driver's receive buffer did not receive the
>>      ECHO REQUEST by using printk command. We suspected that the
>>      ECHO REQUEST was not issued to the MAL(Memory Access Layer),
>>      therefore ECHO REQUEST was not translated to the receive
>>      buffer.
>>
>> At the same time, many 4 byte short packet(0x000000f0) which was
>> not addressed to custom board was received to the LAN device driver's
>> receive buffer with error status. According to 405GP manual, EMAC
>> discards the packet which is not of its own.
>
>to me it looks like an half duplex issue. You should check whether both:
>sender and receiver know that they are connected to a half duplex hub.
>Otherwise collisions could occur which are not detected by the receiver
>and also not by the transmitting entity. So you should make sure that
>FDE is set to 0 in the EMAC Mode register 1 (EMAC0_MR1) according to
>the Users manual)
>

-----
KISHINAMI Masaya
Fujitsu Limited (Japan)

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: 405GP Networking issue

[Eugene Surovegin]

At 04:27 AM 2/28/2003, KISHINAMI Masaya wrote:
>We are debugging a custom board designed based on the 405GP
>(200MHz) and have a problem not being sent ECHO REPLY ping
>packet from custom board to our PC via repeater hub on the
>heavy traffic under 10Mbps and half duplex condition.
>We used the latest version of ibm_ocp LAN device driver at
>that time from kernel 2.4.21-pre3 and ported it to work on
>the kernel 2.4.18 because it costs many time to boot our
>custom board on the latest one. The board works fine unless
>not be such a case.


>    - Logic analyzer captured the same ping packet which was
>      already been captured by LAN analyzer between PHY(Intel
>      LXT971A) and EMAC. It shows ECHO REQUEST was reached just
>      before the EMAC.


If other obvious _software_ errors were eliminated (like incorrect
duplex/speed settings etc) you can check _hardware_ related problems:

Please, check the quality of the clock between PHY and EMAC (MII clock).
We had some problems with this Intel PHY and IBM 440GP when PHY generated
clock was _slightly_ out of spec for IBM CPU.

You can try to increase MII drive strength in LXT971A Digital Config
register (26), write 0x0800 to it.

Make sure that your design uses _crystal_ based oscillator for PHY
clock, not PLL based. This is _general_ observation regarding PHY clock
in any designs (not just 4xx based)

Eugene.


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: 405GP Networking issue

[KISHINAMI Masaya]

Hi, Eugene.

Thank you for your advice.

--- On Sat, 1 Mar 2003 04:08:33 +0900 Eugene Surovegin<ebs@ebshome.net> -san wrote:

>
>At 04:27 AM 2/28/2003, KISHINAMI Masaya wrote:
>>We are debugging a custom board designed based on the 405GP
>>(200MHz) and have a problem not being sent ECHO REPLY ping
>>packet from custom board to our PC via repeater hub on the
>>heavy traffic under 10Mbps and half duplex condition.
>>We used the latest version of ibm_ocp LAN device driver at
>>that time from kernel 2.4.21-pre3 and ported it to work on
>>the kernel 2.4.18 because it costs many time to boot our
>>custom board on the latest one. The board works fine unless
>>not be such a case.
>
>
>>    - Logic analyzer captured the same ping packet which was
>>      already been captured by LAN analyzer between PHY(Intel
>>      LXT971A) and EMAC. It shows ECHO REQUEST was reached just
>>      before the EMAC.
>
>
>If other obvious _software_ errors were eliminated (like incorrect
>duplex/speed settings etc) you can check _hardware_ related problems:
>
>Please, check the quality of the clock between PHY and EMAC (MII clock).
>We had some problems with this Intel PHY and IBM 440GP when PHY generated
>clock was _slightly_ out of spec for IBM CPU.
>
We have already been checked the quality of the clock and it
was good. However we'll check again. Today, we tried to duplicate
the ping lost case by another custom board designed based on 405GP
and no ping lost occurred on the same line loading condition what
we investigated before. The difference is hardware design (wiring
etc.) and SW(OS, LAN device driver etc.). Each custom board is
designed for another product. Therefor we'll check the difference
at the point of hardware(waveform etc.) and SW(configuration of
EMAC/PHY/MAL and so on).


>You can try to increase MII drive strength in LXT971A Digital Config
>register (26), write 0x0800 to it.
>
>Make sure that your design uses _crystal_ based oscillator for PHY
>clock, not PLL based. This is _general_ observation regarding PHY clock
>in any designs (not just 4xx based)
>

Fortunately, we have designed the same way what you've adviced.
Datasheet said don't use PLL. Before, 100Mbps transfer mode which
clock line is 25MHz was succeded. While the 10Mbps is 2.5MHz.
Therefore we think there is no matter about quality of clock.
Anyway we'll investigate again.

Regards, Kishinami

-----
KISHINAMI Masaya
Fujitsu Limited (Japan)

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

How to load vmlinux in IBM405 Redwood-6 board(Teference board)

[Rakesh Jagota]

Hi all,

I am working with Redwood-6 IBM ppc405 refrence design board. I am not able
test the reference board. I am getting the menu on the Hyperterminal but I am
not able to load the linux source code using serial port and DHCP. Can anyone
suggest me whats wrong and how can i do it. I have configured the DHCP in my
host system, but I am not able to upload the vmlinux i  the target.

I am working in linux and using 7.2 version.

Thanks in advance,

Rakesh


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: 405GP Networking issue

[KISHINAMI Masaya]

Hi,

Before, we have experienced a failure that the about 60% ping
commands were lost at the below condition.
- custom board designed based on the 405GP
- kernel 2.4.18
- 2.4.21 pre3 ibm_ocp LAN device driver and ported it to
  work on kernel 2.4.18
- repeater hub(10Mbps, half duplex)
- line is much loaded

We investigated the another product designed based on the 405GP
which is not occurred the same failure on the same condition and
we've found the difference and modified the LAN device driver.

[Cause]
- Receive Mode Register(EMAC0_RMR) was not set to receive the
  Runt packet and FCS error packet.
- Even if the above mode is set at the open process(ppc405_enet_open),
  the value was cleared at the multicast configuration process
  (ppc405_enet_set_multicast_list).

[Conclusion]
- In Receive Mode Register(EMAC0_RMR) initialization at the open
  process, allow receiving the runt packet(RRP) and FCS error
  packet(RFP).
  Ex.
	/* enable broadcast and individual address */
	out_be32(&emacp->em0rmr, EMAC_RMR_IAE | EMAC_RMR_BAE);
  ---->
        unsigned long rcv_err_packet=EMAC_RMR_ARRP | EMAC_RMR_ARP;
	/* enable broadcast and individual address */
	out_be32(&emacp->em0rmr,
	 rcv_err_packet | EMAC_RMR_IAE | EMAC_RMR_BAE);

- In ppc405_enet_set_multicast_list(), one of the resolutions is
  to set receiving the error packet in each program line what is
  to be set.
  Ex. (case multicast configuration)
      unsigned long rcv_err_packet=EMAC_RMR_ARRP | EMAC_RMR_ARP;
      out_be32(&emacp->em0rmr,
      rcv_err_packet | EMAC_RMR_IAE | EMAC_RMR_BAE | EMAC_RMR_MAE);

After modification, no frame error was found by ifconfig cmd and no
BAD packet was found in the log file and all ping was succeeded.
We don't understand why such configuration is effective, because
we understand the 405GP's EMAC will discard any bad packets and
managing bad packet by software is not required.
By the way, the reason of another product's LAN device driver is
set to receiving the bad packet is related to the period of development.
At this time(1999), LAN device driver was debugged with engineering
version of 405GP, therefore some error management was covered by
software and this configuration has been kept leaving because no such
failure has occurred as yet.
Sorry not to inform quickly.

Regards. Kishinami

-----
KISHINAMI Masaya
Fujitsu Limited (Japan)

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/