Solved: Problem with SMSC Phy LAN8710 and LLTEMAC using Li...

borja_mrtnz · ‎05-21-2010

Hello,

we have a problem with SMSC Phy in Linux. We are using a custom board based on the ML507, and SMSC Phy LAN8710i (MII interface, 10/100 Mbps). We are using Linux, kernel version 2.6.31, though there is already avaliable the 2.6.33, because previously we had a problem with flash booting (we decided to return to 2.6.31).

Linux boots and starts the LLTEMAC core correctly, but it cannot detect our Phy, like it is shown below:

---------------------------------------------------------------------------------------------------------------------

zImage starting: loaded at 0x00400000 (sp: 0x0078ef1c)

Allocating 0x397228 bytes for kernel ...

gunzipping (0x00000000 <- 0x0040e000:0x005b3ba3)...done 0x376054 bytes

Attached initrd image at 0x005b4000-0x0078d035

initrd head: 0x1f8b0808

Linux/PowerPC load: console=ttyS0 ip=192.168.0.2 rw root=/dev/ram

Finalizing device tree... flat tree at 0x79b300

Using Xilinx Virtex440 machine description

Linux version 2.6.31 (gjuez@ubuntu) (gcc version 4.0.0 (DENX ELDK 4.1 4.0.0)) #7

3 PREEMPT Fri May 21 10:48:16 CEST 2010

Found initrd at 0xc05b4000:0xc078d035

Zone PFN ranges:

DMA 0x00000000 -> 0x00020000

Normal 0x00020000 -> 0x00020000

Movable zone start PFN for each node

early_node_map[1] active PFN ranges

0: 0x00000000 -> 0x00020000

MMU: Allocated 1088 bytes of context maps for 255 contexts

Built 1 zonelists in Zone order, mobility grouping on. Total pages: 130048

Kernel command line: console=ttyS0 ip=192.168.0.2 rw root=/dev/ram

PID hash table entries: 2048 (order: 11, 8192 bytes)

Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)

Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)

Memory: 513792k/524288k available (3368k kernel code, 10116k reserved, 152k data

, 128k bss, 172k init)

Kernel virtual memory layout:

* 0xffffe000..0xfffff000 : fixmap

* 0xfde00000..0xfe000000 : consistent mem

* 0xfde00000..0xfde00000 : early ioremap

* 0xe1000000..0xfde00000 : vmalloc & ioremap

NR_IRQS:512

clocksource: timebase mult[1400000] shift[22] registered

Console: colour dummy device 80x25

Mount-cache hash table entries: 512

NET: Registered protocol family 16

PCI: Probing PCI hardware

bio: create slab <bio-0> at 0

NET: Registered protocol family 2

IP route cache hash table entries: 16384 (order: 4, 65536 bytes)

TCP established hash table entries: 65536 (order: 7, 524288 bytes)

TCP bind hash table entries: 65536 (order: 6, 262144 bytes)

TCP: Hash tables configured (established 65536 bind 65536)

TCP reno registered

NET: Registered protocol family 1

Trying to unpack rootfs image as initramfs...

rootfs image is not initramfs (no cpio magic); looks like an initrd

Freeing initrd memory: 1892k freed

msgmni has been set to 1007

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

83e00000.serial: ttyS0 at MMIO 0x83e01003 (irq = 0) is a 16550

console [ttyS0] enabled

brd: module loaded

loop: module loaded

Device Tree Probing 'ethernet'

xilinx_lltemac 81c00000.ethernet: MAC address is now 0: a:35:15:b0: 0

xilinx_lltemac 81c00000.ethernet: XLlTemac: using DMA mode.

XLlTemac: DCR address: 0x80

XLlTemac: buffer descriptor size: 32768 (0x8000)

XLlTemac: Allocating DMA descriptors with kmalloc

XLlTemac: (buffer_descriptor_init) phy: 0x1f860000, virt: 0xdf860000, size: 0x80

00

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

eth0: Dropping NETIF_F_SG since no checksum feature.

xilinx_lltemac 81c00000.ethernet: eth0: Xilinx TEMAC at 0x81C00000 mapped to 0xE

1024000, irq=16

xilinx-xps-spi f3000080.xps-spi: no IRQ found

xilinx-xps-spi f1000000.xps-spi: no IRQ found

xilinx-xps-spi f6000080.xps-spi: no IRQ found

xilinx-xps-spi f2000000.xps-spi: no IRQ found

mice: PS/2 mouse device common for all mice

TCP cubic registered

NET: Registered protocol family 17

RPC: Registered udp transport module.

RPC: Registered tcp transport module.

eth0: XLlTemac: Options: 0x3fa

eth0: XLlTemac: allocating interrupt 18 for dma mode tx.

eth0: XLlTemac: allocating interrupt 17 for dma mode rx.

eth0: XLlTemac: We renegotiated the speed to: 100

eth0: XLlTemac: speed set to 100Mb/s

eth0: XLlTemac: Send Threshold = 24, Receive Threshold = 4

eth0: XLlTemac: Send Wait bound = 254, Receive Wait bound = 254

IP-Config: Guessing netmask 255.255.255.0

IP-Config: Complete:

device=eth0, addr=192.168.0.2, mask=255.255.255.0, gw=255.255.255.255,

host=192.168.0.2, domain=, nis-domain=(none),

bootserver=255.255.255.255, rootserver=255.255.255.255, rootpath=

RAMDISK: gzip image found at block 0

VFS: Mounted root (ext2 filesystem) on device 1:0.

Freeing unused kernel memory: 172k init

### Application running ...

root:~>

---------------------------------------------------------------------------------------------------------------------

We have read a post in the forum about a person that had also a problem with the SMSC LAN8700 Phy (a bit different from ours, but from the same manufacturer):

http://forums.xilinx.com/t5/Embedded-Linux/Problem-with-the-quot-xilinx-lltemac-quot-linux-device-driver/m-p/37003

It seems that it can be problems with Phy drivers in Linux. I am guessing if there are any new drivers for the SMSC LAN8710i.

About the Linux configuration, we have selected both Xilinx LLTEMAC PHY support (like it is shown below ) and SMSC phy support in another configuration entry of the previous menu.

Thank you in advance,

Borja

jpl@xiphos.ca · ‎05-28-2010

The code that generates that 'error' is a simple loop that counts down from 15 (I think) to 1, polling each PHY address for a response. When it finds the address (in the range of 15 to 1), then it will report it as found and using the address discovered.

If it can't find the PHY in the range 15 to 1, it reports it as an error and procedes to use 0 as the address. So, if your PHY is at address 0 (as mine is), you will always see this 'error' message.

Joshua

View solution in original post

borja_mrtnz · ‎05-24-2010

Hello,

we finally got linux 2.6.33 working with the same configuration as in the previous case 2.6.31, adding SMSC Phy support and LLTEMAC support with MARVELL or other Phy, and we get the same result:

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

It seems to be a driver problem with the SMSC LAN8710i chip, though the driver for SMSC has support for LAN8700, which is very similar to our phy.

Update: we have opened the smsc driver of 2.6.33 and in the smsc.c code there is an entry for the LAN8710:

static struct phy_driver lan8710_driver = {
   .phy_id       = 0x0007c0f0, /* OUI=0x00800f, Model#=0x0f */
   .phy_id_mask   = 0xfffffff0,
   .name       = "SMSC LAN8710/LAN8720",

   .features   = (PHY_BASIC_FEATURES | SUPPORTED_Pause
               | SUPPORTED_Asym_Pause),
   .flags       = PHY_HAS_INTERRUPT | PHY_HAS_MAGICANEG,

   /* basic functions */
   .config_aneg   = genphy_config_aneg,
   .read_status   = genphy_read_status,
   .config_init   = smsc_phy_config_init,

   /* IRQ related */
   .ack_interrupt   = smsc_phy_ack_interrupt,
   .config_intr   = smsc_phy_config_intr,

   .suspend   = genphy_suspend,
   .resume       = genphy_resume,

   .driver       = { .owner = THIS_MODULE, }
};

Thank you,

Borja

borja_mrtnz · ‎05-25-2010

Hello,

we have finally discovered what the error was. There was a problem in the soldering of a ball in the FPGA (the ball corresponding to the MDC line of the SMI interface), so we had no clock in that line. We have now tried to use another pin of the FPGA for the same purpose and now ethernet is working properly (pings are getting to the destiny). However we still get:

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

at start-up. We don't know why but even with Ethernet working properly, the system doesn't recognize the PHY device... ¿Could still be a problem with the PHY device?

Thank you,

Borja

jpl@xiphos.ca · ‎05-28-2010

The code that generates that 'error' is a simple loop that counts down from 15 (I think) to 1, polling each PHY address for a response. When it finds the address (in the range of 15 to 1), then it will report it as found and using the address discovered.

If it can't find the PHY in the range 15 to 1, it reports it as an error and procedes to use 0 as the address. So, if your PHY is at address 0 (as mine is), you will always see this 'error' message.

Joshua

View solution in original post

borja_mrtnz · ‎05-28-2010

Ok, solved!! Thank you very much for the help.

Regards,

Borja

Problem with SMSC Phy LAN8710 and LLTEMAC using Linux Kernel 2.6.31