plb_temac w/linux 2.6.18.1 driver init error

Rick Moleres rick.moleres at xilinx.com
Thu Nov 2 10:35:38 EST 2006


Robert,

The DRE type should not matter.  The problem seems to be that the
hardware is built for DMA but for some reason the driver is trying to
initialize the FIFO.  It seems that something is out of sync.

Since you're using EDK 8.2i, I wonder if you can go grab SP2, which was
released Oct. 30th.  It has Linux 2.6 as part of its BSP generation,
along with a Linux 2.6 plb_temac driver (I don't recall where you got
your version).  Here are the paths, or you can just use the BSP
generation process.

sw\ThirdParty\bsp\linux_2_6_v1_00_a\drivers\temac_linux_2_6_v2_00_b\src
sw\ThirdParty\bsp\linux_2_6_v1_00_a\linux\arch\ppc\platforms\4xx

Regarding bandwidth, we saw similar numbers with plb_temac as seen with
GSRD using netperf when plb_temac is built with DMA, DRE, and checksum
offload (you have CSO turned off).  I think the max Linux 2.6 TCP
numbers were 530Mbps (TX) and 310Mbps (RX).  We saw better with Linux
2.4 (730Mbps/360Mbps) - but we didn't spend time investigating the
difference.

Thanks,
Rick

-----Original Message-----
From: robert corley [mailto:rdcorle at yahoo.com] 
Sent: Wednesday, November 01, 2006 2:29 PM
To: Rick Moleres
Subject: Re: plb_temac w/linux 2.6.18.1 driver init error

Rick;

Below are the defines generated by the EDK8.2 and are equal to those
used in
my xparameters_ml403.h file for linux.  It would appear that they are in
sync.

Note that there are two #defines no longer generated by EDK but still
used in the arch/ppc/platforms/4xx/virtex.c:

#define XPAR_TEMAC_0_TEMAC_DCR_HOST             0
#define XPAR_TEMAC_0_INCLUDE_DRE                1

/******************************************************************/

/* Definitions for driver TEMAC */
#define XPAR_XTEMAC_NUM_INSTANCES 1

/* Definitions for peripheral PLB_TEMAC_0 */
#define XPAR_PLB_TEMAC_0_DEVICE_ID 0
#define XPAR_PLB_TEMAC_0_BASEADDR 0x60000000
#define XPAR_PLB_TEMAC_0_HIGHADDR 0x60003FFF
#define XPAR_PLB_TEMAC_0_RXFIFO_DEPTH 131072
#define XPAR_PLB_TEMAC_0_TXFIFO_DEPTH 131072
#define XPAR_PLB_TEMAC_0_MAC_FIFO_DEPTH 64
#define XPAR_PLB_TEMAC_0_DMA_TYPE 3
#define XPAR_PLB_TEMAC_0_TX_DRE_TYPE 2
#define XPAR_PLB_TEMAC_0_RX_DRE_TYPE 2
#define XPAR_PLB_TEMAC_0_INCLUDE_TX_CSUM 0
#define XPAR_PLB_TEMAC_0_INCLUDE_RX_CSUM 0

/******************************************************************/

Do you think that the type of RX & TX DRE makes a difference?  That is,
shall I use
DSP48 blocks or logic (or that just a design consideration rather than a
driver issue)?

You've probably done some measurements on bandwidth throughput.  Can you
tell

me how much bw I can get out of the plb_temac with and without DMA mode?


Would it be better to use the device is a similar manner as was done in
the GSRD, or can I 
expect to get similar bandwidths this way?


-cy

----- Original Message ----
From: Rick Moleres <rick.moleres at xilinx.com>
To: robert corley <rdcorle at yahoo.com>; David Bolcsfoldi
<dbolcsfoldi at gmail.com>
Cc: linux linuxppc-embedded <linuxppc-embedded at ozlabs.org>
Sent: Wednesday, November 1, 2006 3:45:38 PM
Subject: RE: plb_temac w/linux 2.6.18.1 driver init error


Robert,

I haven't seen this before, but perhaps the plb_temac hardware is built
for DMA but xparameters.h is out of sync and thinks it's built with FIFO
mode?  This would probably cause a machine check if trying to write a
FIFO register but it doesn't exist.  You can crosscheck xparameters.h
with your hardware design to verify.

-Rick










More information about the Linuxppc-embedded mailing list