eth0: link down

[mtx512]

On the Hackberry after kernel 3.0.36+ wemac fails to initialise on every subsequent kernel version and reports the following:

[ 15.020000] wemac wemac.0: WARNING: no IRQ resource flags set.
[ 15.130000] wemac wemac.0: eth0: link down
[ 15.130000] ADDRCONF(NETDEV_UP): eth0: link is not ready

After lengthy debugging it seems that part of the changes for the following commit is causing the problem:

commit 9290665
Author: Jorgen Lundman lundman@lundman.net
Date: Tue Jul 10 01:31:54 2012 +0000

net: sun4i-wemac: Based on dm9000 driver, remove delays and improve nic.

-#define PHY_POWER 1
+#define PHY_POWER 0

If I set PHY_POWER back to 1 then wemac is working again.

[amery]

while waiting for @lundman's comment. can you try the stage/sunxi-3.0 (+this change) branch on your device? and if you find troubles please report them on the ML.

[rzk]

Are you sure that you have enabled wemac in script.bin? Because afaik phy_power (emac_used = 1) is set there, or, atleast, should be. I have Mele A2000 setup with latest kernel both stage and stable working ok with ethernet.

[mtx512]

In our script.bin

emac_used = 1
emac_rxd3 = port:PA00<2><default><default><default>
emac_rxd2 = port:PA01<2><default><default><default>
emac_rxd1 = port:PA02<2><default><default><default>
emac_rxd0 = port:PA03<2><default><default><default>
emac_txd3 = port:PA04<2><default><default><default>
emac_txd2 = port:PA05<2><default><default><default>
emac_txd1 = port:PA06<2><default><default><default>
emac_txd0 = port:PA07<2><default><default><default>
emac_rxclk = port:PA08<2><default><default><default>
emac_rxerr = port:PA09<2><default><default><default>
emac_rxdV = port:PA10<2><default><default><default>
emac_mdc = port:PA11<2><default><default><default>
emac_mdio = port:PA12<2><default><default><default>
emac_txen = port:PA13<2><default><default><default>
emac_txclk = port:PA14<2><default><default><default>
emac_crs = port:PA15<2><default><default><default>
emac_col = port:PA16<2><default><default><default>
emac_reset = port:PA17<1><default><default><default>
emac_power = port:PH19<1><default><default><0>
emac_link = port:PB11<1><0><default><1>

I can try changing emac_power to 1?

[rzk]

https://github.com/cnxsoft/a10-config/blob/master/script.fex/mele-a1000-vga.fex#L89 - mele has emac_power on different pin, maybe it is also hardcoded somewhere in kernel so your device fails. need a word from guys who dig in wemac driver.

[hno]

ons 2012-10-31 klockan 02:31 -0700 skrev jas-hacks:

In our script.bin

emac_used = 1
emac_rxd3 = port:PA00
emac_rxd2 = port:PA01
emac_rxd1 = port:PA02
emac_rxd0 = port:PA03
emac_txd3 = port:PA04
emac_txd2 = port:PA05
emac_txd1 = port:PA06
emac_txd0 = port:PA07
emac_rxclk = port:PA08
emac_rxerr = port:PA09
emac_rxdV = port:PA10
emac_mdc = port:PA11
emac_mdio = port:PA12
emac_txen = port:PA13
emac_txclk = port:PA14
emac_crs = port:PA15
emac_col = port:PA16
emac_reset = port:PA17
emac_power = port:PH19

The above all looks right according to schematics, but missing GPIO
function numbers etc. Should be like in the mele

emac_used = 1
emac_rxd3 = port:PA00<2>
emac_rxd2 = port:PA01<2>
emac_rxd1 = port:PA02<2>
emac_rxd0 = port:PA03<2>
emac_txd3 = port:PA04<2>
emac_txd2 = port:PA05<2>
emac_txd1 = port:PA06<2>
emac_txd0 = port:PA07<2>
emac_rxclk = port:PA08<2>
emac_rxerr = port:PA09<2>
emac_rxdV = port:PA10<2>
emac_mdc = port:PA11<2>
emac_mdio = port:PA12<2>
emac_txen = port:PA13<2>
emac_txclk = port:PA14<2>
emac_crs = port:PA15<2>
emac_col = port:PA16<2>
emac_reset = port:PA17<1>

emac_link = port:PB11

But not this. PB11 is LCD0-SDA

Can't find what this should be.

Regards
Henrik

[mtx512]

For the Hackberry emac_power is configured to use PH19 unlike the mele which uses PH15.

 emac_power = port:PH19<1><default><default><0>

From what I can determine based on the latests wemac.c (3.0.42+) PH15 (for mele) must some how get enabled by the kernel prior to wemac is initialised because of :

#define PHY_POWER 0

For Hackberry we require PHY_POWER = 1 so that the gpio line is enabled by the emac_power setting. With this change ethernet gets enabled, however using a armhf kernel the link is reported as 10Mb half duplex:

Sending on   Socket/fallback
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 6
<6>ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[   16.880000] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
<6>wemac wemac.0: eth0: link up, 10Mbps, half-duplex, lpa 0x0021
[   16.920000] wemac wemac.0: eth0: link up, 10Mbps, half-duplex, lpa 0x0021

Interestingly I can get the link to back to 100Mb full duplex using ethtool.

To get 100Mb full duplex reported by the driver the following changes also have to be reverted:

@@ -1563,7 +1563,8 @@ static int wemac_phy_read(struct net_device *dev, int phyaddr_unused, int reg)
writel(0x1, db->emac_vbase + EMAC_MAC_MCMD_REG);
spin_unlock_irqrestore(&db->lock, flags);

-       wemac_msleep(db, 1); /* Wait read complete */
+       //wemac_msleep(db, 1); /* Wait read complete */
+        udelay(150); /* 100 */

/* push down the phy io line and read data */
spin_lock_irqsave(&db->lock, flags);
@@ -1596,7 +1597,8 @@ static void wemac_phy_write(struct net_device *dev,
writel(0x1, db->emac_vbase + EMAC_MAC_MCMD_REG);
spin_unlock_irqrestore(&db->lock, flags);

-       wemac_msleep(db, 1);            /* Wait write complete */
+       // wemac_msleep(db, 1);         /* Wait write complete */
+        udelay(150); /* 100 */

spin_lock_irqsave(&db->lock, flags);
/* push down the phy io line */

I tried changing msleep() to msleep_interruptible() thinking that interrupts weren't ocurring during msleep but that has no effect.

Even though the wemac is reporting a 100Mb actual speeds is a poor 5-6Mb.

[amery]

can you re-post that on the mailing list?

[amery]

to close this ticket, is the PHY_POWER problem solved? the 10/HD thing is a separated problem

[mtx512]

I will need test latest code and report back.

[rellla]

@mtx512: is that 10Mbps/half duplex problem solved? since yesterday (and since using 3.4.19) i have this 10Mbps issue on mele a1000. i had on a100, too. but there it is working now. only don't know why. should a new issue be created?

[mtx512]

@rella, haven't tried the latest 3.0.X build, it seems the PHY_POWER wasn't set based on the value in the fex file. I just patched the code myself to make it work!