plb_temac w/linux 2.6.18.1 driver init error

plb_temac w/linux 2.6.18.1 driver init error

[Robert Corley]

Has anyone made progress with the MVL drivers for the plb_temac in linux 2.=
6.18?=0A=0AI am having initialization problems as is shown in the kernel du=
mp below.  Note that I have added=0Asome printk's to show the status of the=
 device before XTemac_VmInitialize(...) is called.=0A=0A2.6.18 kernel with =
all patches=0A11/01/2006    09:45=0APLB_TEMAC=0A=0Aloaded at:     00400000 =
00985138=0Aboard data at: 00983120 00983138=0Arelocated to:  0040407C 00404=
094=0Azimage at:     00404E8F 0051024E=0Ainitrd at:     00511000 009826FE=
=0Aavail ram:     00986000 04000000=0A=0ALinux/PPC load: console=3DttyUL0 s=
ingle ip=3Doff ramdisk_size=3D4660000 root=3D/dev/ram rw=0A=0AUncompressing=
 Linux...done.=0A=0ANow booting the kernel=0A=0A[    0.000000] Linux versio=
n 2.6.17.1 (rdcorle@athena) (gcc version 3.4.2) #6 Wed Nov 1 14:28:43 UTC 2=
006=0A[    0.000000] Xilinx ML403 Reference System (Virtex-4 FX)=0A[    0.0=
00000] Built 1 zonelists.  Total pages: 16384=0A[    0.000000] Kernel comma=
nd line: console=3DttyUL0 single ip=3Doff ramdisk_size=3D4660000 root=3D/de=
v/ram rw=0A[    0.000000] Xilinx INTC #0 at 0xD1000FC0 mapped to 0xFDFFFFC0=
=0A[    0.000000] PID hash table entries: 512 (order: 9, 2048 bytes)=0A[   =
 0.000157] Console: colour dummy device 80x25=0A[    0.000567] Dentry cache=
 hash table entries: 8192 (order: 3, 32768 bytes)=0A[    0.001275] Inode-ca=
che hash table entries: 4096 (order: 2, 16384 bytes)=0A[    0.012989] Memor=
y: 58024k available (1740k kernel code, 484k data, 92k init, 0k highmem)=0A=
[    0.104387] Mount-cache hash table entries: 512=0A[    0.106727] checkin=
g if image is initramfs...it isn't (no cpio magic); looks like an initrd=0A=
[    2.410153] Freeing initrd memory: 4549k freed=0A[    2.414699] NET: Reg=
istered protocol family 16=0A[    2.423477] NET: Registered protocol family=
 2=0A[    2.460259] IP route cache hash table entries: 512 (order: -1, 2048=
 bytes)=0A[    2.461080] TCP established hash table entries: 2048 (order: 1=
, 8192 bytes)=0A[    2.461247] TCP bind hash table entries: 1024 (order: 0,=
 4096 bytes)=0A[    2.461339] TCP: Hash tables configured (established 2048=
 bind 1024)=0A[    2.461368] TCP reno registered=0A[    2.469853] NTFS driv=
er 2.1.27 [Flags: R/O].=0A[    2.470086] io scheduler noop registered=0A[  =
  2.470162] io scheduler anticipatory registered=0A[    2.470234] io schedu=
ler deadline registered=0A[    2.470362] io scheduler cfq registered (defau=
lt)=0A[    2.509013] uartlite.0: ttyUL0 at MMIO 0xa0000000 (irq =3D 1) is a=
 uartlite=0A[    2.669456] RAMDISK driver initialized: 16 RAM disks of 4660=
000K size 1024 blocksize=0A[    2.682424] loop: loaded (max 8 devices)=0A[ =
   2.688358] xtenet_probe: xtemac 0: IO resources obtained.  IRQ =3D 0, MEM=
 =3D 0x60000000=0A[    2.696263] xtenet_probe: xtemac 0: private data initi=
alized=0A[    2.701997] xtenet_probe: TEMAC config lookup succeeded.  Detai=
ls =3D =0A[    2.708372]         Base address    =3D 0x60000000, remap addr=
ess =3D 0xC5008000=0A[    2.714899]         Unique ID       =3D 0x0000=0A[ =
   2.718659]         RCV FIFO depth  =3D 0x131072=0A[    2.722589]         =
XMIT FIFO depth =3D 0x131072=0A[    2.726520]         MAC FIFO depth  =3D 0=
x16=0A[    2.730105]         IPIF/DMA config =3D 0x03=0A[    2.733689]     =
    DCR Host        =3D 0x0=0A[    2.737189]         DRE Engine?     =3D 0x=
1=0A[    2.740695] Data machine check in kernel mode.=0A[    2.745138] Oops=
: machine check, sig: 7 [#1]=0A[    2.749399] NIP: C013A538 LR: C013A510 CT=
R: 00000000=0A[    2.754354] REGS: c022ef50 TRAP: 0202   Not tainted  (2.6.=
17.1)=0A[    2.760252] MSR: 00029030 <EE,ME,IR,DR>  CR: 84000022  XER: 4000=
001D=0A[    2.766601] TASK =3D c02d5b70[1] 'swapper' THREAD: c0988000=0A[  =
  2.771811] GPR00: 00000001 C0989DE0 C02D5B70 C0945344 00000068 C500A200 C0=
94544C C01E4F98 =0A[    2.780191] GPR08: C500A010 C0230000 11111111 C094532=
4 24000022 C000A09C BBE6EA1D C0230000 =0A[    2.788572] GPR16: 00000000 00B=
EF29E 00000000 C0231B50 00000000 C01E0000 C01E0000 C01E4820 =0A[    2.79693=
4] GPR24: C09452F8 C01C0000 C09452F8 C01E4818 C01E4EA0 C5008000 C0945000 C0=
9452F8 =0A[    2.805487] NIP [C013A538] XTemac_ConfigureFifoAccess+0x50/0xb=
4=0A[    2.811422] LR [C013A510] XTemac_ConfigureFifoAccess+0x28/0xb4=0A[  =
  2.817250] Call Trace:=0A[    2.819695] [C0989DE0] [C013A510] XTemac_Confi=
gureFifoAccess+0x28/0xb4 (unreliable)=0A[    2.827340] [C0989E00] [C01389D8=
] Initialize+0x3c/0xe8=0A[    2.832506] [C0989E20] [C0137F04] xtenet_probe+=
0x228/0x7c8=0A[    2.838001] [C0989EA0] [C012F124] driver_probe_device+0xc8=
/0x118=0A[    2.844006] [C0989EC0] [C012F30C] __driver_attach+0xdc/0x108=0A=
[    2.849664] [C0989EE0] [C012E32C] bus_for_each_dev+0x54/0x98=0A[    2.85=
5322] [C0989F10] [C012F35C] driver_attach+0x24/0x34=0A[    2.860722] [C0989=
F20] [C012EA20] bus_add_driver+0x88/0x14c=0A[    2.866295] [C0989F50] [C012=
F924] driver_register+0x70/0xbc=0A[    2.871867] [C0989F70] [C0226684] xten=
et_init+0x18/0x28=0A[    2.877093] [C0989F80] [C0002428] init+0x84/0x2e4=0A=
[    2.881801] [C0989FF0] [C00051DC] kernel_thread+0x44/0x60=0A[    2.88720=
4] Instruction dump:=0A[    2.890159] 38842010 4800619d 38000001 2f830000 3=
87f004c 419e001c 7c030378 80010024 =0A[    2.897926] 83e1001c 38210020 7c08=
03a6 4e800020 <809f0000> 38a42100 38842000 48006165 =0A[    2.906034] Kerne=
l panic - not syncing: Attempted to kill init!=0A[    2.911957]  <0>Rebooti=
ng in 180 seconds..=0A=0A-cy=0A=0A

RE: plb_temac w/linux 2.6.18.1 driver init error

[robert corley]

Anyone?;=0A=0AThe offending instruction is:=0A=0Aout_be32((volatile unsigne=
d *) InstancePtr->RegBaseAddress+XPF_V200A_RESET_REG_OFFSET, XPF_V200A_RESE=
T_FIFO_MASK);=0A=0Acalled vai a #define in "drivers/xilinx_edk/xpacket_fifo=
_v2_00_a.c"=0A=0AWould anyone care to speculate if the error is in the out_=
be32 definition or is this a function of a memory access to an incorrect va=
lue?=0A=0AHere is the latest dump:=0A=0A[    2.702189] xtenet_probe: xtemac=
 0: IO resources obtained.  IRQ =3D 0, MEM =3D 0x60000000=0A[    2.710095] =
xtenet_probe: xtemac 0: private data initialized=0A[    2.715872]     remap=
 info =3D> start =3D 0x60000000, end=3D0x60003fff, total=3D16384, virtual d=
est.=3D0xc5050000=0A[    2.725007] xtenet_probe: TEMAC config lookup succee=
ded.  Details =3D =0A[    2.731369]         Base address    =3D 0x60000000=
=0A[    2.735471]         Unique ID       =3D 0x0000=0A[    2.739230]      =
   RCV FIFO depth  =3D 0x131072=0A[    2.743161]         XMIT FIFO depth =
=3D 0x131072=0A[    2.747091]         MAC FIFO depth  =3D 0x64=0A[    2.750=
677]         IPIF/DMA config =3D 0x03=0A[    2.754260]         DCR Host    =
    =3D 0x0=0A[    2.757759]         DRE Engine?     =3D 0x1=0A[    2.76126=
0] Initialize : Handlers set up.  Configuring FIFO access...=0A[    2.76770=
9] XPacketFifoV200a_Initialize : setting FIFO REG base address to 0xC505201=
0=0A[    2.775548] XPacketFifoV200a_Initialize : setting FIFO DATA base add=
ress to 0xC5052200=0A[    2.783474] XPacketFifoV200a_Initialize : setting I=
sReady to 286331153=0A[    2.790011] XPacketFifoV200a_Initialize : resettin=
g FIFO by writing 0x000A to 0xC5052010=0A[    2.798103] Data machine check =
in kernel mode.=0A[    2.802544] Oops: machine check, sig: 7 [#1]=0A=0A-cy=
=0A=0A=0A=0A=0A

RE: plb_temac w/linux 2.6.18.1 driver init error

[Rick Moleres]

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

-----Original Message-----
From: linuxppc-embedded-bounces+moleres=3Dxilinx.com@ozlabs.org
[mailto:linuxppc-embedded-bounces+moleres=3Dxilinx.com@ozlabs.org] On
Behalf Of robert corley
Sent: Wednesday, November 01, 2006 1:33 PM
To: David Bolcsfoldi
Cc: linux linuxppc-embedded
Subject: RE: plb_temac w/linux 2.6.18.1 driver init error

Anyone?;

The offending instruction is:

out_be32((volatile unsigned *)
InstancePtr->RegBaseAddress+XPF_V200A_RESET_REG_OFFSET,
XPF_V200A_RESET_FIFO_MASK);

called vai a #define in "drivers/xilinx_edk/xpacket_fifo_v2_00_a.c"

Would anyone care to speculate if the error is in the out_be32
definition or is this a function of a memory access to an incorrect
value?

Here is the latest dump:

[    2.702189] xtenet_probe: xtemac 0: IO resources obtained.  IRQ =3D =
0,
MEM =3D 0x60000000
[    2.710095] xtenet_probe: xtemac 0: private data initialized
[    2.715872]     remap info =3D> start =3D 0x60000000, =
end=3D0x60003fff,
total=3D16384, virtual dest.=3D0xc5050000
[    2.725007] xtenet_probe: TEMAC config lookup succeeded.  Details =3D =

[    2.731369]         Base address    =3D 0x60000000
[    2.735471]         Unique ID       =3D 0x0000
[    2.739230]         RCV FIFO depth  =3D 0x131072
[    2.743161]         XMIT FIFO depth =3D 0x131072
[    2.747091]         MAC FIFO depth  =3D 0x64
[    2.750677]         IPIF/DMA config =3D 0x03
[    2.754260]         DCR Host        =3D 0x0
[    2.757759]         DRE Engine?     =3D 0x1
[    2.761260] Initialize : Handlers set up.  Configuring FIFO access...
[    2.767709] XPacketFifoV200a_Initialize : setting FIFO REG base
address to 0xC5052010
[    2.775548] XPacketFifoV200a_Initialize : setting FIFO DATA base
address to 0xC5052200
[    2.783474] XPacketFifoV200a_Initialize : setting IsReady to
286331153
[    2.790011] XPacketFifoV200a_Initialize : resetting FIFO by writing
0x000A to 0xC5052010
[    2.798103] Data machine check in kernel mode.
[    2.802544] Oops: machine check, sig: 7 [#1]

-cy





_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

RE: plb_temac w/linux 2.6.18.1 driver init error

[Rick Moleres]

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@yahoo.com]=20
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=20
expect to get similar bandwidths this way?


-cy

----- Original Message ----
From: Rick Moleres <rick.moleres@xilinx.com>
To: robert corley <rdcorle@yahoo.com>; David Bolcsfoldi
<dbolcsfoldi@gmail.com>
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

plb_temac w/linux 2.6.18.1 driver init error

[Robert Corley]

Rick;=0A=0AI see now what you were writing about.  The IPIF registers for c=
ontrolling FIFO control (both xmit and rcv)=0Aare not accessible when a DMA=
 mode is used, as is shown on page 26 of the plb_temac datasheet.=0A=0AExam=
ination of the drivers generated by the EDK show that a check for the prese=
nce of a DMA engine=0Ais done in xtemac.c to avoid incorrectly resetting a =
DMA-based plb_temac; whereas, the drivers for=0Aearlier versions of the plb=
_temac do not have this test.=0A=0ALooks like I will have to incorporate th=
e drivers generated by the EDK8.2 into the linux tree.=0A=0ADo you know whe=
re I might get the file "gmii.h" referenced in adapter.c?=0A=0A-cy=0A=0A

RE: plb_temac w/linux 2.6.18.1 driver init error

[Rick Moleres]

Robert,

No, I'm not sure where gmii.h is.  I see in the adapter.c delivered in
EDK 8.2.02i it includes linux/mii.h, but I don't see an include of
gmii.h. Perhaps you can incorporate this new adapter.c as well.  I
believe gmii.h is a Linux 2.4 file (?).

-Rick

-----Original Message-----
From: Robert Corley [mailto:rcorley@aegis-inc.net]=20
Sent: Wednesday, November 01, 2006 4:41 PM
To: Rick Moleres
Cc: linux linuxppc-embedded
Subject: plb_temac w/linux 2.6.18.1 driver init error

Rick;

I see now what you were writing about.  The IPIF registers for
controlling FIFO control (both xmit and rcv)
are not accessible when a DMA mode is used, as is shown on page 26 of
the plb_temac datasheet.

Examination of the drivers generated by the EDK show that a check for
the presence of a DMA engine
is done in xtemac.c to avoid incorrectly resetting a DMA-based
plb_temac; whereas, the drivers for
earlier versions of the plb_temac do not have this test.

Looks like I will have to incorporate the drivers generated by the
EDK8.2 into the linux tree.

Do you know where I might get the file "gmii.h" referenced in adapter.c?

-cy

Re: plb_temac w/linux 2.6.18.1 driver init error

[David H. Lynch Jr.]

    I am not sure of the problem,
     but  I think you are using a different variation of the TEMAC than 
I am.
    My  TEMAC is configured with a DMA_TYPE of 1 and a DRE TYPE of 0
   
    I also thought the  XPacketFifo code was for DMA TYPE 1 which I 
beleive is the FIFO incarnation of the TEMAC.
    This driver is supposed to work with your TEMAC - I think.

robert corley wrote:
> Anyone?;
>
> The offending instruction is:
>
> out_be32((volatile unsigned *) InstancePtr->RegBaseAddress+XPF_V200A_RESET_REG_OFFSET, XPF_V200A_RESET_FIFO_MASK);
>
> called vai a #define in "drivers/xilinx_edk/xpacket_fifo_v2_00_a.c"
>
> Would anyone care to speculate if the error is in the out_be32 definition or is this a function of a memory access to an incorrect value?
>
> Here is the latest dump:
>
> [    2.702189] xtenet_probe: xtemac 0: IO resources obtained.  IRQ = 0, MEM = 0x60000000
> [    2.710095] xtenet_probe: xtemac 0: private data initialized
> [    2.715872]     remap info => start = 0x60000000, end=0x60003fff, total=16384, virtual dest.=0xc5050000
> [    2.725007] xtenet_probe: TEMAC config lookup succeeded.  Details = 
> [    2.731369]         Base address    = 0x60000000
> [    2.735471]         Unique ID       = 0x0000
> [    2.739230]         RCV FIFO depth  = 0x131072
> [    2.743161]         XMIT FIFO depth = 0x131072
> [    2.747091]         MAC FIFO depth  = 0x64
> [    2.750677]         IPIF/DMA config = 0x03
> [    2.754260]         DCR Host        = 0x0
> [    2.757759]         DRE Engine?     = 0x1
> [    2.761260] Initialize : Handlers set up.  Configuring FIFO access...
> [    2.767709] XPacketFifoV200a_Initialize : setting FIFO REG base address to 0xC5052010
> [    2.775548] XPacketFifoV200a_Initialize : setting FIFO DATA base address to 0xC5052200
> [    2.783474] XPacketFifoV200a_Initialize : setting IsReady to 286331153
> [    2.790011] XPacketFifoV200a_Initialize : resetting FIFO by writing 0x000A to 0xC5052010
> [    2.798103] Data machine check in kernel mode.
> [    2.802544] Oops: machine check, sig: 7 [#1]
>
> -cy
>
>
>
>
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>   


-- 
Dave Lynch 					  	    DLA Systems
Software Development:  				         Embedded Linux
717.627.3770 	       dhlii@dlasys.net 	  http://www.dlasys.net
fax: 1.253.369.9244 			           Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.

"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein