Porting EVB OMAP-L138 Linux kernel for custom board with rmii network interface

Modified drivers/net/davinci_emac.c to run function emac_dump_regs when request driver info via ethtool (ethtool -i eth0) on linux-03.20.00.06.

The registers and statistics about interface on eth0 on evm with GUI expander on RMII interface after boot :

net eth0: EMAC Basic registers
net eth0: EMAC: EWCTL: 00000000, EWINTTCNT: 00000000
net eth0: EMAC: TXID: 4EC0020D enabled, RXID: 4EC0020D enabled
net eth0: EMAC: TXIntRaw:00000000, TxIntMasked: 00000000, TxIntMasSet: 00000001
net eth0: EMAC: RXIntRaw:0000FF00, RxIntMasked: 00000000, RxIntMasSet: 00000001
net eth0: EMAC: MacIntRaw:00000000, MacIntMasked: 00000000, MacInVector=00000000
net eth0: EMAC: EmuControl:00000000, FifoControl: 00000002
net eth0: EMAC: MBPEnable:00002020, RXUnicastSet: 00000001, RXMaxLen=000005F2
net eth0: EMAC: MacControl:00008221, MacStatus: 80000000, MacConfig=03030202
net eth0: EMAC: TXHDP[0]:00000000, RXHDP[0]: 01E21FA0
net eth0: EMAC Statistics
net eth0: EMAC: rx_good_frames:386
net eth0: EMAC: rx_broadcast_frames:383
net eth0: EMAC: rx_multicast_frames:0
net eth0: EMAC: rx_pause_frames:0
net eth0: EMAC: rx_crcerrors:0
net eth0: EMAC: rx_align_code_errors:0
net eth0: EMAC: rx_oversized_frames:0
net eth0: EMAC: rx_jabber_frames:0
net eth0: EMAC: rx_undersized_frames:0
net eth0: EMAC: rx_fragments:0
net eth0: EMAC: rx_filtered_frames:163
net eth0: EMAC: rx_qos_filtered_frames:0
net eth0: EMAC: rx_octets:35213
net eth0: EMAC: tx_goodframes:4
net eth0: EMAC: tx_bcastframes:4
net eth0: EMAC: tx_mcastframes:0
net eth0: EMAC: tx_pause_frames:0
net eth0: EMAC: tx_deferred_frames:0
net eth0: EMAC: tx_collision_frames:0
net eth0: EMAC: tx_single_coll_frames:0
net eth0: EMAC: tx_mult_coll_frames:0
net eth0: EMAC: tx_excessive_collisions:0
net eth0: EMAC: tx_late_collisions:0
net eth0: EMAC: tx_underrun:0
net eth0: EMAC: tx_carrier_sense_errors:0
net eth0: EMAC: tx_octets:2376
net eth0: EMAC: net_octets:160682
net eth0: EMAC: rx_sof_overruns:0
net eth0: EMAC: rx_mof_overruns:0
net eth0: EMAC: rx_dma_overruns:0

And executing the same commando on custom board (registers with different info marked at bold) :

net eth0: EMAC Basic registers
net eth0: EMAC: EWCTL: 00000000, EWINTTCNT: 00000000
net eth0: EMAC: TXID: 4EC0020D disabled, RXID: 4EC0020D disabled
net eth0: EMAC: TXIntRaw:00000000, TxIntMasked: 00000000, TxIntMasSet: 00000000
net eth0: EMAC: RXIntRaw:0000FF00, RxIntMasked: 00000000, RxIntMasSet: 00000000
net eth0: EMAC: MacIntRaw:00000001, MacIntMasked: 00000000, MacInVector=00000000
net eth0: EMAC: EmuControl:00000000, FifoControl: 00000002
net eth0: EMAC: MBPEnable:00000000, RXUnicastSet: 00000000, RXMaxLen=000005EE
net eth0: EMAC: MacControl:00000000, MacStatus: 80000000, MacConfig=03030202
net eth0: EMAC: TXHDP[0]:00000000, RXHDP[0]: 00000000
net eth0: EMAC Statistics
net eth0: EMAC: rx_good_frames:0
net eth0: EMAC: rx_broadcast_frames:0
net eth0: EMAC: rx_multicast_frames:-1
net eth0: EMAC: rx_pause_frames:0
net eth0: EMAC: rx_crcerrors:0
net eth0: EMAC: rx_align_code_errors:0
net eth0: EMAC: rx_oversized_frames:-1
net eth0: EMAC: rx_jabber_frames:-1
net eth0: EMAC: rx_undersized_frames:-1
net eth0: EMAC: rx_fragments:0
net eth0: EMAC: rx_filtered_frames:0
net eth0: EMAC: rx_qos_filtered_frames:0
net eth0: EMAC: rx_octets:0
net eth0: EMAC: tx_goodframes:0
net eth0: EMAC: tx_bcastframes:0
net eth0: EMAC: tx_mcastframes:0
net eth0: EMAC: tx_pause_frames:0
net eth0: EMAC: tx_deferred_frames:0
net eth0: EMAC: tx_collision_frames:-1
net eth0: EMAC: tx_single_coll_frames:-1
net eth0: EMAC: tx_mult_coll_frames:-1
net eth0: EMAC: tx_excessive_collisions:0
net eth0: EMAC: tx_late_collisions:0
net eth0: EMAC: tx_underrun:-1
net eth0: EMAC: tx_carrier_sense_errors:-1
net eth0: EMAC: tx_octets:0
net eth0: EMAC: net_octets:0
net eth0: EMAC: rx_sof_overruns:-1
net eth0: EMAC: rx_mof_overruns:-1
net eth0: EMAC: rx_dma_overruns:-1

Anyone understand the meaning of the differences on registers ? Where I can get info about the registers ?

Thanks,
Aníbal

Aníbal Pinto said:

Where I can get info about the registers ?

The EMAC User's guide has the full register description: http://www.ti.com/litv/pdf/sprufl5a

Thanks,

Sekhar

I found a driver for Micrel KSZ8041TL PHY [1] added to phy drivers with an option on kernel and activated on kernel.

Now when trying to setup the network the message that appears is :

eth0: attached PHY driver [Micrel KSZ8041] (mii_bus:phy_addr=1:00, id=221512)

After Linux boot  I set an ip on the interface :

# ifconfig eth0 192.168.0.20 up

and consult the emac registers  :

net eth0: EMAC Basic registers
net eth0: EMAC: EWCTL: 00000000, EWINTTCNT: 00000000
net eth0: EMAC: TXID: 4EC0020D enabled, RXID: 4EC0020D enabled
net eth0: EMAC: TXIntRaw:00000000, TxIntMasked: 00000000, TxIntMasSet: 00000001
net eth0: EMAC: RXIntRaw:0000FF00, RxIntMasked: 00000000, RxIntMasSet: 00000001
net eth0: EMAC: MacIntRaw:00000000, MacIntMasked: 00000000, MacInVector=00000000
net eth0: EMAC: EmuControl:00000000, FifoControl: 00000002
net eth0: EMAC: MBPEnable:00002020, RXUnicastSet: 00000001, RXMaxLen=000005F2
net eth0: EMAC: MacControl:00008221, MacStatus: 80000000, MacConfig=03030202
net eth0: EMAC: TXHDP[0]:00000000, RXHDP[0]: 01E21FE0

The only difference to evm is the field RXHDP[0], on custom board is 01E21FE0 on evm is 01E21FA0.

When I try to ping to a host the value of rx_align_code_errors and rx_crcerrors increase.

Is normal the value in RXHDP  ? Can this be wrong and provoke the errors ?

Regards,

Aníbal

[1] - https://dev.openwrt.org/browser/trunk/target/linux/ar71xx/files/drivers/net/phy/micrel.c

I have connected the  custom board directly to my computer by an Ethernet cable and turned on wireshark on that interface.

When I make a ping on the board to my PC, on wireshark, I receive the arp package from the board, and the PC send a response.

The ping command never receives a response to the packages and the registers EMAC_RXALIGNCODEERRORS and EMAC_RXCRCERRORS and incremented.

How I can print the response that board receive ? This can be alignment on queues that are receiving the data, were I can correct/modify that ?

The state of the EMAC registers after executing a ping :

net eth0: EMAC: EWCTL: 00000000, EWINTTCNT: 00000000
net eth0: EMAC: TXID: 4EC0020D enabled, RXID: 4EC0020D enabled
net eth0: EMAC: TXIntRaw:00000000, TxIntMasked: 00000000, TxIntMasSet: 00000001
net eth0: EMAC: RXIntRaw:0000FF00, RxIntMasked: 00000000, RxIntMasSet: 00000001
net eth0: EMAC: MacIntRaw:00000000, MacIntMasked: 00000000, MacInVector=00000000
net eth0: EMAC: EmuControl:00000000, FifoControl: 00000002
net eth0: EMAC: MBPEnable:00002020, RXUnicastSet: 00000001, RXMaxLen=000005F2
net eth0: EMAC: MacControl:00008221, MacStatus: 80000000, MacConfig=03030202
net eth0: EMAC: TXHDP[0]:00000000, RXHDP[0]: 01E21FE0
net eth0: EMAC Statistics
net eth0: EMAC: rx_good_frames:0
net eth0: EMAC: rx_broadcast_frames:0
net eth0: EMAC: rx_multicast_frames:0
net eth0: EMAC: rx_pause_frames:0
net eth0: EMAC: rx_crcerrors:11
net eth0: EMAC: rx_align_code_errors:11
net eth0: EMAC: rx_oversized_frames:0
net eth0: EMAC: rx_jabber_frames:0
net eth0: EMAC: rx_undersized_frames:0
net eth0: EMAC: rx_fragments:11
net eth0: EMAC: rx_filtered_frames:0
net eth0: EMAC: rx_qos_filtered_frames:0
net eth0: EMAC: rx_octets:0
net eth0: EMAC: tx_goodframes:15
net eth0: EMAC: tx_bcastframes:15
net eth0: EMAC: tx_mcastframes:0
net eth0: EMAC: tx_pause_frames:0
net eth0: EMAC: tx_deferred_frames:0
net eth0: EMAC: tx_collision_frames:0
net eth0: EMAC: tx_single_coll_frames:0
net eth0: EMAC: tx_mult_coll_frames:0
net eth0: EMAC: tx_excessive_collisions:0
net eth0: EMAC: tx_late_collisions:0
net eth0: EMAC: tx_underrun:0
net eth0: EMAC: tx_carrier_sense_errors:0
net eth0: EMAC: tx_octets:960
net eth0: EMAC: net_octets:8066
net eth0: EMAC: rx_sof_overruns:0
net eth0: EMAC: rx_mof_overruns:0
net eth0: EMAC: rx_dma_overruns:0

Thanks,
Aníbal

We have seen that the interrupts of the device, displayed at
/proc/interrupts aren't incremented when we plug-in/unplug the cable or
when we make ping to the board. 

The registers on EMACs EMAC_RXCRCERRORS and EMAC_RXALIGNCODEERRORS,
increment when make ping to the board.

The interrupts of eth0 only appears in
the /proc/interrupts when the interface is up (ifconfig eth0
192.168.0.20 up).

The tcpdump program running on the board and logging the execution of ping
192.168.0.19 show that only messages are exiting from the board, don't
receive any package.

A possibility is that that can be an unstable
Ethernet link or network driver requests to change the link status.

Digging the function phy_state_machine in /linux/driver/net/phy/phy.c, and
with some printks the state was :

# ifconfig eth0 192.168.0.20 up
[  179.350000] eth0: attached PHY driver [Micrel KS8041] (mii_bus:phy_addr=1:00, id=221512)
[  180.350000] PHY State : Up
[  181.350000] PHY State : AN (err : 0)
[  181.350000] PHY State : AN (err : 32)
[  181.350000] PHY: 1:00 - Link is Up - 100/Full
[  182.360000] PHY State : Running (poll : 1)
[  183.360000] PHY State : Changelink (err : 0)
[  184.360000] PHY State : Running (poll : 1)
[  185.360000] PHY State : Changelink (err : 0)
[  186.360000] PHY State : Running (poll : 1)
[  187.360000] PHY State : Changelink (err : 0)
[  188.360000] PHY State : Running (poll : 1)
[  189.360000] PHY State : Changelink (err : 0)
[  190.360000] PHY State : Running (poll : 1)
[  191.360000] PHY State : Changelink (err : 0)
[  192.360000] PHY State : Running (poll : 1)
[  193.360000] PHY State : Changelink (err : 0)
# ifconfig eth0 down

This is equal to generic phy driver state machine.

It appears that poll is allways selected, on the Micrel Phy driver has
the flag PHY_HAS_INTERRUPT but phy_dev->irq is always equal to PHY_POLL

Most of this info was obtained with support from Micrel. The phy, by the
info I give, appears to be OK.

Is there any configuration of PHY by EMAC that I can confirm that is OK ?

I have a tracing the functions of the evm and our custom board, and identified a point that diverge.

On file drivers/net/davinci_emac.c at function emac_poll the line :

status = emac_read(EMAC_MACINVECTOR);

the value of status is always 0

Have any idea why is always 0 ?

The value need to be 1 to process rx buffer by the upper layers.

I have upgrade our custom board to linux-03.20.00.12.

I had to make two modifications on kernel sources to be able to boot and have the RMII interface.

One was to apply the modifications that are described in [1] to board don't hang when try to read RTC/time registers.

With the new approach on detecting the  GUI expander even if you select the RMII interface, but don't detect the expander on boot it will select the MII interface. I have modified to RMII always be the interface selected.

The board was a new behavior, with generic and micrel phy drivers, now don't transmit anything and continues to don't receive.

TheEMAC  driver still continue to print the PHY state  (PHY: 1:00 - Link is Down) and green led blinks when I make ping to my pc, from board.

The EMAC statistics [2] now don't have any errors on reception, all the reception statistics are equal to zero. On transmission it have a value for good frames, but nothing appears on Ethernet sniffer.

Have any idea why the change of behaviour ? It looks like the EMAC can't communicate with PHY ....

Thanks.

Regards,
Aníbal

[1] - http://groups.google.com/group/hawkboard/browse_thread/thread/a1830c69f89296d2/3cf0045ed7aa0492?#3cf0045ed7aa049

[2] - net eth0: EMAC Basic registers
net eth0: EMAC: EWCTL: 00000000, EWINTTCNT: 00000000
net eth0: EMAC: TXID: 4EC0020D enabled, RXID: 4EC0020D enabled
net eth0: EMAC: TXIntRaw:00000000, TxIntMasked: 00000000, TxIntMasSet: 00000001
net eth0: EMAC: RXIntRaw:0000FF00, RxIntMasked: 00000000, RxIntMasSet: 00000001
net eth0: EMAC: MacIntRaw:00000000, MacIntMasked: 00000000, MacInVector=00000000
net eth0: EMAC: EmuControl:00000000, FifoControl: 00000002
net eth0: EMAC: MBPEnable:00002020, RXUnicastSet: 00000001, RXMaxLen=000005F2
net eth0: EMAC: MacControl:00000221, MacStatus: 80000000, MacConfig=03030202
net eth0: EMAC: TXHDP[0]:00000000, RXHDP[0]: 01E21FE0
net eth0: EMAC Statistics
net eth0: EMAC: rx_good_frames:0
net eth0: EMAC: rx_broadcast_frames:0
net eth0: EMAC: rx_multicast_frames:0
net eth0: EMAC: rx_pause_frames:0
net eth0: EMAC: rx_crcerrors:0
net eth0: EMAC: rx_align_code_errors:0
net eth0: EMAC: rx_oversized_frames:0
net eth0: EMAC: rx_jabber_frames:0
net eth0: EMAC: rx_undersized_frames:0
net eth0: EMAC: rx_fragments:0
net eth0: EMAC: rx_filtered_frames:0
net eth0: EMAC: rx_qos_filtered_frames:0
net eth0: EMAC: rx_octets:0
net eth0: EMAC: tx_goodframes:9
net eth0: EMAC: tx_bcastframes:9
net eth0: EMAC: tx_mcastframes:0
net eth0: EMAC: tx_pause_frames:0
net eth0: EMAC: tx_deferred_frames:0
net eth0: EMAC: tx_collision_frames:0
net eth0: EMAC: tx_single_coll_frames:0
net eth0: EMAC: tx_mult_coll_frames:0
net eth0: EMAC: tx_excessive_collisions:0
net eth0: EMAC: tx_late_collisions:0
net eth0: EMAC: tx_underrun:0
net eth0: EMAC: tx_carrier_sense_errors:0
net eth0: EMAC: tx_octets:576
net eth0: EMAC: net_octets:576
net eth0: EMAC: rx_sof_overruns:0
net eth0: EMAC: rx_mof_overruns:0
net eth0: EMAC: rx_dma_overruns:0

Hi Anibal,

         Is the linux-03.20.00.12 release working  fine on evm?

Regards,

N.Sugumar

Hi,

Yes, I have been able to start linux-03.20.00.12 on my evm.

The only modification that I have done was applying the [1] patch for removing the read access to rtc clock.

Regards,

Aníbal

[1] - http://groups.google.com/group/hawkboard/browse_thread/thread/a1830c69f89296d2/3cf0045ed7aa0492?#3cf0045ed7aa049

Hi Anibal,

          i can see from your previous post that the Ethernet PHY in the custom board  gets detected but the LINK status is always down. Is this correct?  Did you try  Ping  test in the u-boot?

Regards,

N.Sugumar

Hi Sugumar,

not being able to boot by nfs, I don't have network, I started to look to u-boot because I can flash it from serial port.

I have modified configuration of include/configs/da850evm.h and defined CONFIG_DRIVER_TI_EMAC_USE_RMII

In u-boot when I make a ping to my pc, with a sniffer on the network, I see that the pc receive some ARP packages to identify the IP, the pc make the response but the boards don't appear to receive it. The ping command fails after sending two ARP requests.

When you say Ping test do you mean the test described before, right ?

What appears to be happening is that the board don't detect the packages that receive. One possible reason, pointed by Micrel, is that the interrupts may be bad configured.

How I can test the reception of packages of EMAC ? Or the communication EMAC <-> PHY ?

With mii tool from u-boot I can retrieve some informations about the PHY.

With minfo it appears that exist two PHYs :

U-Boot > mii info
PHY_PHYIDR2 @ 0x0 = 0x1512
PHY_PHYIDR[1,2] @ 0x0 = 0x00221512
PHY 0x00: OUI = 0x0885, Model = 0x11, Rev = 0x02, 100baseT, FDX
PHY_PHYIDR2 @ 0x1 = 0x1512
PHY_PHYIDR[1,2] @ 0x1 = 0x00221512
PHY 0x01: OUI = 0x0885, Model = 0x11, Rev = 0x02, 100baseT, FDX

Information about both phy registers :

U-Boot >  mii dump 1
0.     (2100)                 -- PHY control register --
  (8000:0000) 0.15    =     0    reset
  (4000:0000) 0.14    =     0    loopback
  (2040:2000) 0. 6,13 =   b01    speed selection = 100 Mbps
  (1000:0000) 0.12    =     0    A/N enable
  (0800:0000) 0.11    =     0    power-down
  (0400:0000) 0.10    =     0    isolate
  (0200:0000) 0. 9    =     0    restart A/N
  (0100:0100) 0. 8    =     1    duplex = full
  (0080:0000) 0. 7    =     0    collision test enable
  (003f:0000) 0. 5- 0 =     0    (reserved)

U-Boot > mii dump2
0.     (2100)                 -- PHY control register --
  (8000:0000) 0.15    =     0    reset
  (4000:0000) 0.14    =     0    loopback
  (2040:2000) 0. 6,13 =   b01    speed selection = 100 Mbps
  (1000:0000) 0.12    =     0    A/N enable
  (0800:0000) 0.11    =     0    power-down
  (0400:0000) 0.10    =     0    isolate
  (0200:0000) 0. 9    =     0    restart A/N
  (0100:0100) 0. 8    =     1    duplex = full
  (0080:0000) 0. 7    =     0    collision test enable
  (003f:0000) 0. 5- 0 =     0    (reserved)

Thanks.

Best Regards,

Aníbal

Hi Anibal,

Aníbal Pinto said:

I have modified configuration of include/configs/da850evm.h and defined CONFIG_DRIVER_TI_EMAC_USE_RMII

Since you said, you were able to see the ARP requests, I hope the interface should be okay. Anyway could you cross the interface/configuration once again?

1. There  are two Ethernet PHYs present in the evm. PHY LAN8710A  is present on the Base Board and it communicates with SOC through MII interface. LAN8720 is on the UI card and it uses RMII interface. The RMII interface is shared with other buses such as SPI and multiplexed through i2c based IO Expander. So there is only one Ethernet PHY which uses RMII interface.

2. How many Ethernet PHYs are present in the Custom board ? If the Custom board has more than one PHY on the RMII bus, then how are the MDIO, TX, RX lines shared ? Are they multiplexed and only one active PHY present at a time?

3. I see 2 Ethernet PHYs at address 0 and 1. Do these two PHYs use RMII bus? Which is the active PHY and are you making sure that the active PHY is actually the one being addressed?

4. In the evm, RMII 50 MHZ clock to the EMAC is fed from the Ethernet PHY. Is it  the same in custom board as well?

5. Does the custom board have MII  PHY ? If it had, is it tested and working?

Aníbal Pinto said:

In u-boot when I make a ping to my pc, with a sniffer on the network, I see that the pc receive some ARP packages to identify the IP, the pc make the response but the boards don't appear to receive it. the ping command fails after sending two ARP requests.

When you say Ping test do you mean the test described before, right ?

Yes,  I meant this only.

Aníbal Pinto said:

What appears to be happening is that the board don't detect the packages that receive. One possible reason, pointed by Micrel, is that the interrupts may be bad configured.

How I can test the reception of packages of EMAC ? Or the communication EMAC <-> PHY ?

 You are referring to u-boot only, right?  So i think it is better that we solve the issue in the u-boot first and proceed to the kernel.

I am looking into the driver code.  I will get back to you by EOD.

Thanks and Regards,

N.Sugumar.

Hi Anibal,

Aníbal Pinto said:

U-Boot >  mii dump 1
0.     (2100)                 -- PHY control register --
  (8000:0000) 0.15    =     0    reset
  (4000:0000) 0.14    =     0    loopback
  (2040:2000) 0. 6,13 =   b01    speed selection = 100 Mbps
  (1000:0000) 0.12    =     0    A/N enable
  (0800:0000) 0.11    =     0    power-down
  (0400:0000) 0.10    =     0    isolate
  (0200:0000) 0. 9    =     0    restart A/N
  (0100:0100) 0. 8    =     1    duplex = full
  (0080:0000) 0. 7    =     0    collision test enable
  (003f:0000) 0. 5- 0 =     0    (reserved)

      Could you try enabling the 'loopback' bit in the PHY control register and see if the packets are received? This would effectively connect the TX with RX at the PHY end.

Regards,

N.Sugumar

Hi Sugumar,

Sugumar Natarajan said:

Since you said, you were able to see the ARP requests, I hope the interface should be okay. Anyway could you cross the interface/configuration once again?

1. There  are two Ethernet PHYs present in the evm. PHY LAN8710A  is present on the Base Board and it communicates with SOC through MII interface. LAN8720 is on the UI card and it uses RMII interface. The RMII interface is shared with other buses such as SPI and multiplexed through i2c based IO Expander. So there is only one Ethernet PHY which uses RMII interface.

2. How many Ethernet PHYs are present in the Custom board ? If the Custom board has more than one PHY on the RMII bus, then how are the MDIO, TX, RX lines shared ? Are they multiplexed and only one active PHY present at a time?

On my custom board we only have one PHY wit connection RMII.

We made a test, removed a buffer U7 that connects to RMII and still response on both addresses. We have found why it responses on address 0, see on point 3.

Sugumar Natarajan said:

3. I see 2 Ethernet PHYs at address 0 and 1. Do these two PHYs use RMII bus? Which is the active PHY and are you making sure that the active PHY is actually the one being addressed?

We have one PHY on RMII bus. On Micrel datasheet [1] we found this information :

"Each KSZ8041TL/FTL/MLL device is assigned a unique PHY address between 1 and 7 by its PHYAD[2:0] strapping pins. Also, every KSZ8041TL/FTL/MLL device supports the broadcast PHY address 0, as defined per the IEEE 802.3 Specification, which can be used to read/write to a single KSZ8041TL/FTL/MLL device, or write to multiple KSZ8041TL/FTL/MLL devices simultaneously."

Do you have confirmation if this is usual on other PHY ?

Sugumar Natarajan said:

4. In the evm, RMII 50 MHZ clock to the EMAC is fed from the Ethernet PHY. Is it  the same in custom board as well?

We have used the configuration that is on Micrel evaluation board [2]. It haves an external oscillator clock that feed the PHY and the OMAP.

Sugumar Natarajan said:

5. Does the custom board have MII  PHY ? If it had, is it tested and working?

Never had.

I will post a message with other information, to try to don't make a post with to much info.

Regards,

Aníbal

[1] - http://www.micrel.com/_PDF/Ethernet/datasheets/ksz8041tl-ftl-mll.pdf , page 25

[2] - http://www.micrel.com/_PDF/Ethernet/hw_designkit/8041TL-FTL/KSZ8041TL-FTL_v1.3_DP.zip, on /KSZ8041TL-FTL_v1.3_DP/Schematic/Eval Board/Board Revision 1.1/ over RMII mode (option)

I can make a dump of register of PHY using the command mii dump 0. This command works until I execute a ping command, after that, the command  "mii dump 0" stall and I need to make reboot to the board. This behaviour happen even if I don't have the ethernet cable connected.

I have modified the source code of function davinci_eth_rcv_packet on drivers/net to see the status of buffer and the content of it.

The status of the buffer is allways equal to EMAC_CPPI_OWNERSHIP_BIT, on every buffer received.

The buffer is filled with zero, but after some time trying to communicate is filled with information, appears to be a valid ethernet frame, for the board, a broadcast for example. The problem, even with more packets on the network, the buffer never changes, neither the status.

On the EMAC/MDIO User Guide [1] it says that EMAC clears the bit, but don't say how. Do have any information about this ?

I will try to enable the loopback bit on PHY.

[1] - http://www.ti.com/litv/pdf/sprufl5a , pag 20 : "As packets are processed, the EMAC patches the SOP descriptor of the corresponding packet and clears the OWNER flag. "

Hi Sugumar,

Sugumar Natarajan said:

      Could you try enabling the 'loopback' bit in the PHY control register and see if the packets are received? This would effectively connect the TX with RX at the PHY end.

On u-boot I have made the [1] procedure and changed the bit.

Trying to make ping 127.0.0.1 returns that have failed, host is not alive.

With the extra printfs that I have on the code, the buffer status is always equal to EMAC_CPPI_OWNERSHIP_BIT.

Thanks.

Regards,

Aníbal

[1] - commands executed on u-boot to change the register.

U-Boot > mii dump 1
0.     (2100)                 -- PHY control register --
  (8000:0000) 0.15    =     0    reset
  (4000:0000) 0.14    =     0    loopback
  (2040:2000) 0. 6,13 =   b01    speed selection = 100 Mbps
  (1000:0000) 0.12    =     0    A/N enable
  (0800:0000) 0.11    =     0    power-down
  (0400:0000) 0.10    =     0    isolate
  (0200:0000) 0. 9    =     0    restart A/N
  (0100:0100) 0. 8    =     1    duplex = full
  (0080:0000) 0. 7    =     0    collision test enable
  (003f:0000) 0. 5- 0 =     0    (reserved)

U-Boot > mii write 1 0 6100
U-Boot > mii dump 1
0.     (6100)                 -- PHY control register --
  (8000:0000) 0.15    =     0    reset
  (4000:4000) 0.14    =     1    loopback
  (2040:2000) 0. 6,13 =   b01    speed selection = 100 Mbps
  (1000:0000) 0.12    =     0    A/N enable
  (0800:0000) 0.11    =     0    power-down
  (0400:0000) 0.10    =     0    isolate
  (0200:0000) 0. 9    =     0    restart A/N
  (0100:0100) 0. 8    =     1    duplex = full
  (0080:0000) 0. 7    =     0    collision test enable
  (003f:0000) 0. 5- 0 =     0    (reserved)

Hi Anibal,

       Please download the package below and run the RMII loop back test present in the package.  I have tested it in the evm .  Create an account (It is free :)) to download the package

                     http://support.logicpd.com/downloads/1236/1016313A_OMAP-L138_GEL_BSL_Files.zip

Aníbal Pinto said:

I can make a dump of register of PHY using the command mii dump 0. This command works until I execute a ping command, after that, the command  "mii dump 0" stall and I need to make reboot to the board. This behaviour happen even if I don't have the ethernet cable connected.

Please apply the patch attached . The patch  adds  the function call  "eth_mdio_enable()" in the davinci_eth_phy_read and davinci_eth_phy_write functions in the file ether.c

Aníbal Pinto said:

Trying to make ping 127.0.0.1 returns that have failed, host is not alive.

You cannot ping to 127.0.0.1. It will not work on the evm as well since it is handled by the I/P layer and u-boot cant have one.

Regards,

N.Sugumar

Hi Anibal,

Aníbal Pinto said:

[2] - http://www.micrel.com/_PDF/Ethernet/hw_designkit/8041TL-FTL/KSZ8041TL-FTL_v1.3_DP.zip, on /KSZ8041TL-FTL_v1.3_DP/Schematic/Eval Board/Board Revision 1.1/ over RMII mode (option)

  I see  from the schematics that the reference clock is fed from the MAC to PHY. It is the other way around in the evm.

Populate R49 with 0 Ohm and R48 with 33 Ohm
to connect 50MHz Reference Clock (provided by
MAC side via J13 pin 12) to U4 pin 15 (XI input).

So, have you done the pin configuration  accordingly[1]?

• PINMUX15_3_0 = 0: enables sourcing of the 50 MHz reference clock from an external source on the
RMII_MHZ_50_CLK pin.
• PINMUX15_3_0 = 8h: enables sourcing of the 50 MHz reference clock from PLL0_SYSCLK7. Also,
PLL0_SYSCLK7 is driven out on the RMII_MHZ_50_CLK pin.

Regards,

N.Sugumar

1. Refer page.No 78 omap ARM subsytem guide.

Hi Sugumar,

Sugumar Natarajan said:

So, have you done the pin configuration  accordingly[1]?

Using u-boot utilities [1] I have printed the pinmux configuration.

So PINMUX15 on address 0x01C1 415C have the value : 0x00000080

It appears, that this configuration is the default on u-boot when RMII interface is selected, because I don't have changed this on u-boot configuration.

Thanks.

Regards,

Aníbal

U-Boot > base 0x01c1415c
Base Address: 0x01c1415c
U-Boot > md 0 1
01c1415c: 00000080    ....

Hi Sugumar,

I applied the patch and the bug continues ... still mii dump hang after ping.

Why we have two files, on u-boot, for ethernet : drivers/net/davinci_emac.c and cpu/arm926ejs/davinci/ether.c ?

Exist .o files for both the files, and have the prints on davinci_emac.c and they are printed, so which one should be used ?

Sugumar Natarajan said:

       Please download the package below and run the RMII loop back test present in the package.  I have tested it in the evm .  Create an account (It is free :)) to download the package

The test failed because it detects two PHYs, since Micrel PHY respond on both 0 and 1 addresses.

We modified the function that search the PHY, to register only one address.

The test failed on function EMAC_rxPacket in the file ./bsl/src/evmomapl138_emac.c.

Failed on the validation  :

((!CHKBIT(EMAC->RXINTSTATRAW, RX0PEND)) )
   (CHKBIT(tmp_rx_flags, EMAC_DSC_FLAG_OWNER)))
  
(CHKBIT(tmp_rx_flags, EMAC_DSC_FLAG_MASK_RX_ERROR))

After this test we compare the buffers, that are sent and received, and they are equal but the length is wrong, failing on

memcpy(dest_buffer, tmp_rx_desc->buffer, *length);

The value is wrong by 5 bytes, this value was constant for the packets we seen in the test.

Thanks.

Regards,

Aníbal

please take a look at https://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/100/t/112741.aspx maybe you can findout your answer.