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:[EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> To: robert corley <[EMAIL PROTECTED]>; David Bolcsfoldi <[EMAIL PROTECTED]> Cc: linux linuxppc-embedded <linuxppc-embedded@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 _______________________________________________ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
