Re: Linuxppc and MPC8255 routing performance

Re: Linuxppc and MPC8255 routing performance

[Ricardo Scop]

Hi, Ken

On Monday 12 November 2001 18:28, Ken Applebaum wrote:
> ricardo,
>
> does your board have both banks of memory populated?
>

If you mean 'both banks" as a memory bank at the local bus and another at the
60x bus, the answer is yes, our prototype hardware has them, for hardware
debugging purposes. But I didn't enable the use of the local memory bank in
Linux so far, because we didn't originally intend to use it in our final
product...

Nevertheless, I'm aware that using local bus memory for I/O data flowing
between CPM and CPU may improve performance in some Linux applications, so I
would like to experiment with this. Unfortunatelly, I'm very new to Linux, so
I don't know how to configure it for using local memory. If you have any
ideas...

Thanks.

~Ricardo

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

Re: Linuxppc and MPC8255 routing performance

[Dan Malek]

Ricardo Scop wrote:


> Nevertheless, I'm aware that using local bus memory for I/O data flowing
> between CPM and CPU may improve performance in some Linux applications, so I
> would like to experiment with this.

You don't need this as a solution to your performance troubles.  I have
been experimenting with using this space for socket buffers, but unless
you have something else on the bus consuming the cycles, I haven't seen
any benefit.  It could be very useful for custom network applications,
but there isn't anything Linux will do.  Some systems just toss this space
into the general free memory pool, just remember you can't access it over
the 60x bus.


	-- Dan


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

Re: Linuxppc and MPC8255 routing performance

[Ricardo Scop]

On Tuesday 13 November 2001 20:02, Dan Malek wrote:

> Ricardo Scop wrote:
> > Nevertheless, I'm aware that using local bus memory for I/O data flowing
> > between CPM and CPU may improve performance in some Linux applications,
> > so I would like to experiment with this.
>
> You don't need this as a solution to your performance troubles.  I have
> been experimenting with using this space for socket buffers, but unless
> you have something else on the bus consuming the cycles, I haven't seen
> any benefit.  It could be very useful for custom network applications,

Gee, sorry... I meant _network_ applications, indeed. And, thank you for your
advice.

As for our performance troubles, there have been some improvements; we were
making some mistakes regarding both FCC and PHY programming. After fixing
those, we're able to achieve more than 50 Mbits/s in a _real_ FTP transfer,
which is more than enough for our router application.  We are still
conducting more performance tests with netperf, and will publish the resuts
when available.

Thanks,

~Ricardo

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

Re: Linuxppc and MPC8255 routing performance

[Dan Malek]

Ricardo Scop wrote:


> As for our performance troubles, there have been some improvements; we were
> making some mistakes regarding both FCC and PHY programming.


FYI, a major telecommuniation company paid for independent laboratory
certifcation of this driver (and Linux) under a variety of performance
and error conditions.  After a couple of iterations, it passed the
certification testing and I believe all of the modifications are in
this driver (at least it was my intention to ensure they are public).
I don't remember which PHY was used for the testing, but please don't
attack this as a "can't possibly work" problem and start hacking it up.

Thanks.


	-- Dan


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

Re[2]: Linuxppc and MPC8255 routing performance

[Ricardo Scop]

Dan,

Tuesday, November 13, 2001, 3:21:38 PM, you wrote:

DM> Ricardo Scop wrote:


>> As for our performance troubles, there have been some improvements; we were
>> making some mistakes regarding both FCC and PHY programming.


DM> FYI, a major telecommuniation company paid for independent laboratory
DM> certifcation of this driver (and Linux) under a variety of performance
DM> and error conditions.  After a couple of iterations, it passed the
DM> certification testing and I believe all of the modifications are in
DM> this driver (at least it was my intention to ensure they are public).

I'm really glad to know about that. FYI, we never had any doubts about
linuxppc implementation quality, or we wouldn't use it in the first
place.

DM> I don't remember which PHY was used for the testing, but please don't
DM> attack this as a "can't possibly work" problem and start hacking it up.

Oh, we don't! The 'mistakes' I referred were made by _myself_, in two
places:
       - LXT970A PHY in PPCBoot (our hardware MDIO interface don't
       conform to Linux MDIO driver, so I hacked PPCBoot to program
       the chip to megotiate full-duplex, but I did it wrong in our
       earlier tests);

       - in arch/ppc/8260io/fcc_enet.c: the driver we have, pulled
       from linuxppc_2_4 mvista cvs mirror some two weeks ago,
       programs the FCC to half-duplex mode, by default; so, I tryed to
       hack it to full-duplex for our tests and, again, made a
       mistake, which is now fixed).

As I said, all _my_ mistakes. Linux FCC driver works perfectly well!

Thanks again.

~Ricardo


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

eth1 FEC on RPX-CLLF info

[sruel]

Hello Wolfgang,

I'm trying to activate the FEC on my RPX-CLLF board. Everything seems ok
when I do a ifconfig -a, but the FEC eth1 interface seems dead. I wonder
if the base address of the FEC is really 0xe00?

Here is my eth1 config:
ifconfig -a
eth0      Link encap:Ethernet  HWaddr 00:10:EC:00:2C:93
          inet addr:172.16.200.10  Bcast:172.16.255.255  Mask:255.255.0.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:719 errors:0 dropped:0 overruns:0 frame:14
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          Base address:0x3c00

eth1      Link encap:Ethernet  HWaddr 00:10:EC:80:2C:93
          inet addr:148.33.216.245  Bcast:148.33.255.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          Base address:0xe00

lo        Link encap:Local Loopback
          LOOPBACK  MTU:16436  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0

Here is the boot screen dump. The eth1 FEC MAC address is correctly read.
...
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
eth0: CPM ENET Version 0.2 on SCC1, 00:10:ec:00:2c:93
eth1: FEC ENET Version 0.2, FEC irq 3, addr 00:10:ec:80:2c:93
JFFS version 1.0, (C) 1999, 2000  Axis Communications AB
loop: loaded (max 8 devices)
RPX Lite or CLLF flash device: 1000000 at ff000000
 Amd/Fujitsu Extended Query Table v1.2 at 0x0040
number of CFI chips: 1
...

Would you have any idea of the problem?

By the way, in the file fec.c from kernel 2.4.4 (2001-07-23), it is
mentionned that the FEC PHY for the RPX-CLLF board is a QS6612. I have
an RPX-CLLF board, and it uses an LXT971.

Thank!


Sebastien Ruel, System Engineer.
Oerlikon Contraves
Quebec, Canada


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

Re: eth1 FEC on RPX-CLLF info

[Wolfgang Denk]

Dear Sebastien,

in message <3BFA8DB6.1050405@oerlikon.ca> you wrote:
>
> Hello Wolfgang,

I'm not exactly sure whom you're addressing:  the  email  addess  was
Dan's  but  the  name  is mine, and it seems you are referring to the
kernel version on our FTP server, so I jump in ...

> I'm trying to activate the FEC on my RPX-CLLF board. Everything seems ok
> when I do a ifconfig -a, but the FEC eth1 interface seems dead. I wonder
> if the base address of the FEC is really 0xe00?

What do you think  it  means?  Here,  it's  the  offset  of  the  FEC
parameter RAM in the IMMR memory map. And yes, 0xE00 is correct.

> Here is the boot screen dump. The eth1 FEC MAC address is correctly read.
> ...
> RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
> eth0: CPM ENET Version 0.2 on SCC1, 00:10:ec:00:2c:93
> eth1: FEC ENET Version 0.2, FEC irq 3, addr 00:10:ec:80:2c:93

Looks good to me...

> eth1      Link encap:Ethernet  HWaddr 00:10:EC:80:2C:93
>           inet addr:148.33.216.245  Bcast:148.33.255.255  Mask:255.255.255.0

Are you sure about those settings? To me  it  seems  Bcast  and  Mask
don't match...

> Would you have any idea of the problem?

What happens when you enable the MDIO option?

> By the way, in the file fec.c from kernel 2.4.4 (2001-07-23), it is
> mentionned that the FEC PHY for the RPX-CLLF board is a QS6612. I have
> an RPX-CLLF board, and it uses an LXT971.

Did you enable the LXT971 code, then? Sorry, I don't  have  any  CLLF
boards here, so I cannot test this myself.

Just tested it (again) on a TQM860L-P.50; works fine for me.

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
Above all else -- sky.

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