UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Visitor akzare
Visitor
4,836 Views
Registered: ‎01-22-2009

Problem with the "xilinx_lltemac" linux device driver

Hi,

In our hardware platform (PICSY) based on Virtex-4 FX20, instead of the the marvell PHY 88E1111, we exploited the SMSC LAN8700. It is compliant with the IEEE 802.3-2005 register functions. In the EDK project (XPS ver 10.1.03), the xps_II_temac_v1_01_b (Type of TEMAC:V4 Hard, Physical Interface Type:MII and FIFO mode (not DMA mode)) in combination to the xps_II_fifo_v1.01.a are exploited as hard core MAC layer. As far as I run the companion existing "TemacPolledExample" and "TemacFifoIntrExample" examples in the project, everything is OK and in both test cases the results shows PASSED.

In the other hand, when I try it in the linux, there are two conditions with different results.

1- If the network cable is plugged in, when I try to initialise the network driver for IP address, operating system will hang on forever as following:
 
zImage starting: loaded at 0x00400000 (sp: 0x006dfeb0)
 Allocating 0x30fab9 bytes for kernel ...
 gunzipping (0x00000000 <- 0x0040d000:0x0056c828)...done 0x2f3e20 bytes
 Attached initrd image at 0x0056d000-0x006decf0
 initrd head: 0x1f8b0808
 
 Linux/PowerPC load: console=ttyUL0 root=/dev/ram rw
 Finalizing device tree... flat tree at 0x6ec300
 Using Xilinx Virtex machine description
Linux version 2.6.29-rc5 (akzare@orest) (gcc version 4.2.2) #44 PREEMPT Wed Apr 29 22:33:19 CEST 2009
Found initrd at 0xc056d000:0xc06decf0
Zone PFN ranges:
  DMA      0x00000000 -> 0x00008000
  Normal   0x00008000 -> 0x00008000
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
    0: 0x00000000 -> 0x00008000
MMU: Allocated 1088 bytes of context maps for 255 contexts
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 32512
Kernel command line: console=ttyUL0 root=/dev/ram rw
Xilinx intc at 0x81800000 mapped to 0xfdfff000
PID hash table entries: 512 (order: 9, 2048 bytes)
clocksource: timebase mult[d55555] shift[22] registered
Console: colour dummy device 80x25
console [ttyUL0] enabled
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Memory: 125152k/131072k available (2864k kernel code, 5776k reserved, 132k data, 110k bss, 148k init)
Calibrating delay loop... 598.01 BogoMIPS (lpj=1196032)
Mount-cache hash table entries: 512
net_namespace: 880 bytes
NET: Registered protocol family 16
bio: create slab <bio-0> at 0
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 4096 (order: 3, 32768 bytes)
TCP bind hash table entries: 4096 (order: 2, 16384 bytes)
TCP: Hash tables configured (established 4096 bind 4096)
TCP reno registered
NET: Registered protocol family 1
checking if image is initramfs...it isn't (no cpio magic); looks like an initrd
Freeing initrd memory: 1479k freed
msgmni has been set to 247
alg: No test for stdrng (krng)
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered (default)
Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
84000000.serial: ttyUL0 at MMIO 0x84000003 (irq = 16) is a uartlite
brd: module loaded
loop: module loaded
nbd: registered device at major 43
Device Tree Probing 'ethernet'
xilinx_lltemac 81c00000.ethernet: MAC address is now  2: 0: 0: 0: 0: 0
xilinx_lltemac 81c00000.ethernet: XLlTemac: using FIFO direct interrupt driven mode.
XLlTemac: Fifo base address: 0xc9016000
XTemac: No PHY detected.  Assuming a PHY at address 0
eth0 (): not using net_device_ops yet

xilinx_lltemac 81c00000.ethernet: eth0: Xilinx TEMAC at 0x81C00000 mapped to 0xC9012000, irq=17
Linux video capture interface: v2.00
mice: PS/2 mouse device common for all mice
TCP cubic registered
NET: Registered protocol family 17
RAMDISK: Compressed image found at block 0
VFS: Mounted root (ext2 filesystem) on device 1:0.
Freeing unused kernel memory: 148k init
 
root:~> ifconfig -a eth0 141.89.52.137 netmask 255.255.255.0 up
eth0: XLlTemac: Options: 0x3fa
eth0: XLlTemac: allocating interrupt 18 for fifo mode.
eth0: XLlTemac: We renegotiated the speed to: 100
eth0: XLlTemac: speed set to 100Mb/s

2- In the second situation, first I unplug the network cable and reboot system, then try to initialise the network driver. Afterwards, I could again plug in the cable and using a very stable and robust network without packet loss. Kindly, you could see the results hereby:


 zImage starting: loaded at 0x00400000 (sp: 0x006dfeb0)
 Allocating 0x30fab9 bytes for kernel ...
 gunzipping (0x00000000 <- 0x0040d000:0x0056c828)...done 0x2f3e20 bytes
 Attached initrd image at 0x0056d000-0x006decf0
 initrd head: 0x1f8b0808
 
 Linux/PowerPC load: console=ttyUL0 root=/dev/ram rw
 Finalizing device tree... flat tree at 0x6ec300
 Using Xilinx Virtex machine description
Linux version 2.6.29-rc5 (akzare@orest) (gcc version 4.2.2) #44 PREEMPT Wed Apr 29 22:33:19 CEST 2009
Found initrd at 0xc056d000:0xc06decf0
Zone PFN ranges:
  DMA      0x00000000 -> 0x00008000
  Normal   0x00008000 -> 0x00008000
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
    0: 0x00000000 -> 0x00008000
MMU: Allocated 1088 bytes of context maps for 255 contexts
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 32512
Kernel command line: console=ttyUL0 root=/dev/ram rw
Xilinx intc at 0x81800000 mapped to 0xfdfff000
PID hash table entries: 512 (order: 9, 2048 bytes)
clocksource: timebase mult[d55555] shift[22] registered
Console: colour dummy device 80x25
console [ttyUL0] enabled
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Memory: 125152k/131072k available (2864k kernel code, 5776k reserved, 132k data, 110k bss, 148k init)
Calibrating delay loop... 598.01 BogoMIPS (lpj=1196032)
Mount-cache hash table entries: 512
net_namespace: 880 bytes
NET: Registered protocol family 16
bio: create slab <bio-0> at 0
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 4096 (order: 3, 32768 bytes)
TCP bind hash table entries: 4096 (order: 2, 16384 bytes)
TCP: Hash tables configured (established 4096 bind 4096)
TCP reno registered
NET: Registered protocol family 1
checking if image is initramfs...it isn't (no cpio magic); looks like an initrd
Freeing initrd memory: 1479k freed
msgmni has been set to 247
alg: No test for stdrng (krng)
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered (default)
Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
84000000.serial: ttyUL0 at MMIO 0x84000003 (irq = 16) is a uartlite
brd: module loaded
loop: module loaded
nbd: registered device at major 43
Device Tree Probing 'ethernet'
xilinx_lltemac 81c00000.ethernet: MAC address is now  2: 0: 0: 0: 0: 0
xilinx_lltemac 81c00000.ethernet: XLlTemac: using FIFO direct interrupt driven mode.
XLlTemac: Fifo base address: 0xc9016000
XTemac: No PHY detected.  Assuming a PHY at address 0
eth0 (): not using net_device_ops yet

xilinx_lltemac 81c00000.ethernet: eth0: Xilinx TEMAC at 0x81C00000 mapped to 0xC9012000, irq=17
Linux video capture interface: v2.00
mice: PS/2 mouse device common for all mice
TCP cubic registered
NET: Registered protocol family 17
RAMDISK: Compressed image found at block 0
VFS: Mounted root (ext2 filesystem) on device 1:0.
Freeing unused kernel memory: 148k init
 
root:~> ifconfig -a eth0 141.89.52.137 netmask 255.255.255.0 up
eth0: XLlTemac: Options: 0x3fa
eth0: XLlTemac: allocating interrupt 18 for fifo mode.
eth0: XLlTemac: Not able to set the speed to 100 (status: 0x7809)
eth0: XLlTemac: Not able to set the speed to 10 (status: 0x7809)
eth0: XLlTemac: could not negotiate speed
root:~> eth0: XLlTemac: PHY Link carrier lost.
 
root:~> eth0: XLlTemac: We renegotiated the speed to: 100
eth0: XLlTemac: speed set to 100Mb/s
eth0: XLlTemac: PHY Link carrier restored.
 
root:~> route add default gw 141.89.52.254
root:~> ping 141.89.52.43
PING 141.89.52.43 (141.89.52.43): 56 data bytes
64 bytes from 141.89.52.43: icmp_seq=0 ttl=64 time=1005.7 ms
64 bytes from 141.89.52.43: icmp_seq=1 ttl=64 time=1.3 ms
64 bytes from 141.89.52.43: icmp_seq=2 ttl=64 time=0.5 ms
64 bytes from 141.89.52.43: icmp_seq=3 ttl=64 time=0.5 ms
64 bytes from 141.89.52.43: icmp_seq=4 ttl=64 time=0.5 ms
64 bytes from 141.89.52.43: icmp_seq=5 ttl=64 time=0.5 ms
64 bytes from 141.89.52.43: icmp_seq=6 ttl=64 time=0.5 ms
64 bytes from 141.89.52.43: icmp_seq=7 ttl=64 time=0.5 ms
64 bytes from 141.89.52.43: icmp_seq=8 ttl=64 time=0.5 ms
^C
--- 141.89.52.43 ping statistics ---
9 packets transmitted, 9 packets received, 0% packet loss
round-trip min/avg/max = 0.5/112.2/1005.7 ms
root:~> 

I think the problem should be somewhere in the "xenet_open" function in "xlltemac_main.c" exactly after returning from the "set_mac_speed(lp)" function and calling the "XLlFifo_IntEnable". Maybe something like racing condition!

Also, there is another ambiguous message in the booting time:

XTemac: No PHY detected.  Assuming a PHY at address 0

Again, it comes up from the "detect_phy" function in the "xlltemac_main.c". I could see exactly the same function "TemacDetectPHY" is called in the "xlltemac_example_util.c" file in my xps project and working cool. It could detect the PHY at PhyAddr=0! Therefore, I couldn't realise the difference between this function and ones in the device driver!

Also refer to this message: "eth0 (): not using net_device_ops yet", it seems the device driver is not using the "netdev_ops" methods inside the "net_device" struct. It is the question, is it necessary to use the methods inside the "netdev_ops" as device driver programmer or no? 

I would be grateful if somebody reply me with solutions for aforementioned problems.

Thanks in advance.

 

Ali

0 Kudos
1 Reply
Xilinx Employee
Xilinx Employee
4,823 Views
Registered: ‎09-10-2008

Re: Problem with the "xilinx_lltemac" linux device driver

Hi,

 

I wish this would let me respond in-line with that long message.

 

The default kernel config is to use our phy specific code (specific to the Marvell).  Have you tried in the kernel config for the LL TEMAC, selecting the other option which is MII or a different phy? It's not clear to me from the kernel output if you have or not? This will select some generic code designed to work with all PHYs, but it doesn't work well always is my experience.

 

With regards to this-> eth0 (): not using net_device_ops yet, I believe this is a newer feature in the kernel that we have not yet supported in the driver.  Our tests on our boards work and show it not to be an issue.

 

We are working on a new flat driver (Grant is) and it will use the phy drivers in the kernel to hopefully help this issue. Anytime there's a  different PHY the driver may not work as well we found.

 

Thanks,

John

0 Kudos