Eth1 unable to get dhcp lease

Hi Krishne,

What product/technology are you using? It will help me find the appropriate forum for your question. 

For future reference, it will be easier to find the correct forum for your post if you:

1. use the Search tool to find applicable forums for the part you are working with
2. look over some of our resources here on Learn E2E (http://e2e.ti.com/group/helpcentral/default.aspx)
   1. Getting Started (http://e2e.ti.com/group/helpcentral/w/e2e/default.aspx)
   2. Forum Post Guidelines (http://e2e.ti.com/group/helpcentral/w/e2e/1379.ti-e2e-community-forum-post-guidelines.aspx)
   3. Community Guidelines (http://e2e.ti.com/group/helpcentral/w/e2e/1267.ti-e2e-community-guidelines.aspx)

I hope this helps!

hi justin,

we are using linux  we are using ic part no ip1001 trjg17512bgnl connector.

we are not able to get correct amplitued from am3354 processor pin which is connecting to this RGMII2_TCLK. might be

this could be the reason are any code changes we have to make any code changes to enable eth1 we are using ti-sdk 5.06 version.

thanks & regards,

krishnegowda.c

Eth0 and Eth1 need to be on separate subnets.  Please see the post here;

http://e2e.ti.com/support/arm/sitara_arm/f/791/p/214291/758546.aspx#758546

And HW explanation is in the TRM:

14.3.2.10.2 Dual Mac Mode
When operating in dual mac mode the intention is to transfer packets between ports 0 and 1 and ports 0
and 2, but not between ports 1 and 2. Each CPGMAC_SL appears as a single MAC with no bridging
between MAC’s. Each CPGMAC_SL has at least one unique (not the same) mac address.
Dual mac mode is configured as described below:
• Set the ale_vlan_aware bit in the ALE_Control register. This bit configures the ALE to process in vlan
aware mode.The CPSW_3G vlan aware bit (vlan_aware in CPSW_Control) determines how packets
VLAN’s are processed on CPGMAC_SL egress and does not affect how the ALE processes packets or
the packet destination. The CPSW_3G vlan aware bit may be set or not as required (must be set if
VLAN’s are to exit the switch).
• Configure the Port 1 to Port 0 VLAN
Add a VLAN Table Entry with ports 0 and 1 as members (clear the flood masks).
Add a VLAN/Unicast Address Table Entry with the Port1/0 VLAN and a port number of 0. Packets
received on port 1 with this unicast address will be sent only to port 0 (egress). If multiple mac addresses
are desired for this port then multiple entries of this type may be configured.
• Configure the Port 2 to Port 0 VLAN
Add a VLAN Table Entry with ports 0 and 2 as members (clear the flood masks).
Add a VLAN/Unicast Address Table Entry with the Port2/0 VLAN and a port number of 0. Packets
received on port 2 with this unicast address will be sent only to port 0 (egress). If multiple mac addresses
are desired for this port then multiple entries of this type may be configured.
• Packets from the host (port 0) to ports 1 and 2 should be directed. If directed packets are not desired
then VLAN with addresses can be added for both destination ports.
• Select the dual mac mode on the port 0 FIFO by setting tx_in_sel[1:0] = 01 in P0_Tx_In_Ctl. The
intention of this mode is to allow packets from both ethernet ports to be written into the FIFO without
one port starving the other port.
• The priority levels may be configured such that packets received on port 1 egress on one CPDMA RX
channel while packets received on port 2 egress on a different CPDMA RX channel. 

Are you able to use tcpdump? Can you tcpdump -i eth1 and see if it is sending packets out?

Hi Nick Wernicke,

i want make two ethernet ports to work independently without intervention of one another so what could be the

proper configuration currently iam using dual emac mode.

i did tcpdump -i eth1  i get fallowing output

device eth1 entered promiscuous mode

net eth1 promiscuity enabled

tcpdump: warning: eth1 no ipv4 address assigned

tcpdum: verbose output suppressed, use -v or -vv for full protocol decode

listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes.

thanks & regards,

krishnegowda.c

Hi,

I'm just wondering if this issue was solved.

We are using an AM3354 with a SMSC LAN8710A (same as the BeagleBone)

We get virtually the same output, on boot up:

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

Configuring network interfaces... [   17.610778] net eth0: CPSW phy found : id is : 0x7c0f1

udhcpc (v1.19.4) started

Sending discover...

[   20.602020] PHY: 0:00 - Link is Up - 100/Full

Sending discover...

Sending discover...

No lease, failing done. 

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

A tcpdump is exactly the same as listed above by Krishnegowda

Any hints would be most appreciated.

Thanks in advance,

Kurtis

Kurtis,

Are you using MII or RMII? If RMII, how are you clocking the interface?

We're using MII (we're trying to copy the BeagleBone).

OK, first suggestion is to dump MACCONTROL register on AM335x and provide data here. Also, dump the PHY SPECIAL_MODES register (PHY index 18d) via AM335x MDIOUSERACCESS and ensure that the PHY configuration you think you are latching has actually been latched by the PHY. It would also be helpful to dump the PHY BASIC_CONTROL (index 0) and BASIC_STATUS (index 01d) registers to see if the settings within align with the previously dumped MACCONTROL.

With these efforts we are working to ensure that the PHY and MAC are in agreement as to the connection parameters.

Hi, I am a firmware developer at NDI and I am working with Kurtis on the PHY issue of our board. 

I found a 'mii-diag.c' from the net which uses ioctl with SIOCGMIIPHY to access the PHY registers but when I run the test program I get the following:

Using the default interface 'eth0'.
SIOCGMIIPHY on eth0 failed: Operation not supported

Next, I also tried ethtool -d eth0 to get a register dump but failed with

'Cannot get register dump: Operation not supported'

Could you please pass us some sample code to read PHY registers? Or, some further guides on how to read the  MACCONTROL and PHY registers?

Thanks a lot.

Kevin

MACCONTROL (TRM section 14.5.7.2) is an AM335x register and can be read with a myriad of tools including DEVMEM2.

You can dump the PHY registers via MDIO by utilizing the MDIOUSERACCESSn register (also on AM335x). Please see section 15.5.10.11 of the TRM for more details on the functionality of this register.

Here is a related post you may find useful:

http://e2e.ti.com/support/arm/sitara_arm/f/791/p/268577/938404.aspx#938404

DK,

Thank you very muchfor your help.

I did try to read registers as you mentioned via devmem2.

1: read from MACCONTROL via devmem2

devmem2 0x4a100d84
/dev/mem opened.
Memory mapped at address 0x40154000.
Read at address  0x4A100D84 (0x40154d84): 0x00008021

-- Still not sure if that means we are misleadingly not using MII as expected.

2: read from PHY register via devmem2 -- do not seem to be right to me. 

Byte 0d
devmem2 0x4a101080 w 0x80000000
/dev/mem opened.
Memory mapped at address 0x40100000.
Read at address  0x4A101080 (0x40100080): 0x20800DE1
Write at address 0x4A101080 (0x40100080): 0x80000000, readback 0x80000000

Byte 1d
devmem2 0x4a101080 w 0x80200000
/dev/mem opened.
Memory mapped at address 0x4013a000.
Read at address  0x4A101080 (0x4013a080): 0x20800DE1
Write at address 0x4A101080 (0x4013a080): 0x80200000, readback 0x80200000

Byte 18d
devmem2 0x4a101080 w 0x82400000
/dev/mem opened.
Memory mapped at address 0x40130000.
Read at address  0x4A101080 (0x40130080): 0x20800DE1
Write at address 0x4A101080 (0x40130080): 0x82400000, readback 0x82400000

In addition, I tried to poke into kernel drive code and managed to read the PHY registers and the values are:

Byte 0d  = 0x3100
Byte 1d  = 0x782d
Byte 2d  = 0x0007
Byte 3d  = 0xc0f1
Byte 18d = 0x00e0

It appears that PHY is set to RMII mode (bit 14 of Byte 18d). However, I checked with my board-am335xevm.c in which I have

'am33xx_cpsw_init(AM33XX_CPSW_MODE_MII, NULL, NULL);'

and all pin muxed to mii1 - mode 0.

So, I do not know where else needs to look at.