2010-11-04 12:46:04     DNP5370 / No ethernet

Document created by Aaronwu Employee on Aug 23, 2013
Version 1Show Document
  • View in full screen mode

2010-11-04 12:46:04     DNP5370 / No ethernet

Andreas Schallenberg (GERMANY)

Message: 95565   

 

Hello,

 

I am trying to get ethernet to work on a BF537 based board (SSV DNP/5370). I got two uClinux releases 2009R1.1 and 2010R1 with the same behavior:

 

The bfin_mac driver is initialized and the PHY is found. Using printk-debugging I can verify that bfin_mac_rx() and bfin_mac_interrupt() are not called. The function bfin_mac_hard_start_xmit() is called if I try to "ping" another computer. Propably this is the ARP lookup, it reports 42 bytes to be sent each time. However, no traffic can be observed on the network. The "ping" is not working and wireshark on the PC shows no packets whatsoever from the blackfin board.

 

I am attaching my current files for 2010R1 uClinux: board C file and kernel config.

 

Kernel boot messages:

 

...

bfin_mii_bus: probed

bfin_mac: attached PHY driver [Davicom DM9161E] (mii_bus:phy_addr=0:00, irq=-1, mdc_clk=2500000Hz(mdc_div=23)@sclk=120MHz)

bfin_mac bfin_mac.0: Blackfin on-chip Ethernet MAC driver, Version 1.1

...

PHY: 0:00 - Link is Up - 100/Full

...

 

 

ethtool gives:

 

> ethtool eth0

Settings for eth0:

        Supported ports: [ TP MII ]

        Supported link modes:   10baseT/Half 10baseT/Full

                                100baseT/Half 100baseT/Full

        Supports auto-negotiation: Yes

        Advertised link modes:  10baseT/Half 10baseT/Full

                                100baseT/Half 100baseT/Full

        Advertised auto-negotiation: Yes

        Speed: 100Mb/s

        Duplex: Full

        Port: MII

        PHYAD: 0

        Transceiver: external

        Auto-negotiation: on

        Supports Wake-on: g

        Wake-on: d

        Link detected: yes

 

The hardware itself is ok since I can fetch the kernel in U-Boot via TFTP from my host. This works reliable.

 

dnp5370.c

TranslateQuoteReplyEditDelete

 

 

2010-11-04 12:51:46     Re: DNP5370 / No ethernet

Andreas Schallenberg (GERMANY)

Message: 95566   

 

Forgot to attach the .config file.

 

Any suggestions are very welcomed!

 

Andreas

 

config

TranslateQuoteReplyEditDelete

 

 

2010-11-04 13:04:57     Re: DNP5370 / No ethernet

Andreas Schallenberg (GERMANY)

Message: 95567   

 

2nd try to attach kernel config...

 

config

TranslateQuoteReplyEditDelete

 

 

2010-11-04 13:06:25     Re: DNP5370 / No ethernet

Andreas Schallenberg (GERMANY)

Message: 95568   

 

Maybe its the filename... 3rd try...

 

kernel-config

TranslateQuoteReplyEditDelete

 

 

2010-11-05 05:09:49     Re: DNP5370 / No ethernet

Aaron Wu (CHINA)

Message: 95588   

 

The mac is fine. PHY is detected but there is no interrupt and hence no rx after the linux is up, guess something is not right with the davicom PHY 9161E, the dirver for it is the generic code in Linux tree, suppose it's from davicom and we did not cover it in the test scope.

 

suggest you to look into the specification and linux driver code for the davicom PHY 9161E and try some debug

QuoteReplyEditDelete

 

 

2010-11-05 07:00:02     Re: DNP5370 / No ethernet

Andreas Schallenberg (GERMANY)

Message: 95591   

 

Thank you for your reply.

 

The interrupt reported in the kernel boot message ("irq=-1") refers to the PHY. The bfin_mac uses a fixed one: IRQ_MAC_RX. Should the PHY use the same interrupt?

 

To ask the other way round, should it use an IRQ at all? The datasheet shows one IRQ pin, named MDINTR#. The description says: "Asserted low whenever there is a status change (link, speed, duplex)". Well, link change (plugging in and removing the network cable) is detected, so this works.

 

Second, how can this explain the TX not working? It must be something else.

 

I found this thread:

  www.spinics.net/lists/netdev/msg145334.html

It suggests some changes to the driver (ISOLATE vs. RESET). I tried it but this doesn't help.

 

Now I'm trying to get into contact with Davicom to get a better picture.

TranslateQuoteReplyEditDelete

 

 

2010-11-05 10:59:53     Re: DNP5370 / No ethernet

Andreas Schallenberg (GERMANY)

Message: 95594   

 

From what I see now I doubt that the root of it all is the davicom PHY driver. I copied the driver into the 2006 uClinux sources. I had to make one adjustment, since "phy_device" had not field named "interface". It was used to test for RMII mode. Since the 2010 driver said it would be MII (and not RMII) mode I "disabled" the RMII mode - now the code is the same as in the old driver.

 

To my suprise, the old kernel still worked well - "ping" worked.

 

Then, I inserted some debug code in the initialization functions and found that no init functions were called in the old kernel. The driver was just registered - but not used.

 

Next, I tried to disable the init functions in the driver for the new kernel by simply doing "return 0" immediately. No change - ping does not work.

 

So I guess I need to look somewhere else. MII code perhaps?

TranslateQuoteReplyEditDelete

 

 

2010-11-08 08:36:35     Re: DNP5370 / No ethernet

Andreas Schallenberg (GERMANY)

Message: 95642   

 

Digged a bit further into it. Querying the PHY regs at then end of bfin_mac's TX function gives:

 

bfmac_dumpMiiReg: 00 (0x00, MII:"BMCR       ", D:"CONTROL        ") = 0x3100

bfmac_dumpMiiReg: 01 (0x01, MII:"BMSR       ", D:"STATUS         ") = 0x782d

bfmac_dumpMiiReg: 02 (0x02, MII:"PHYSID1    ", D:"PHYID1         ") = 0x0181

bfmac_dumpMiiReg: 03 (0x03, MII:"PHYSID2    ", D:"PHYID2         ") = 0xb881

bfmac_dumpMiiReg: 04 (0x04, MII:"ADVERTISE  ", D:"AUTO_NEG_ADV   ") = 0x01e1

bfmac_dumpMiiReg: 05 (0x05, MII:"LPA        ", D:"LINK_PART_ABIL ") = 0xc5e1

bfmac_dumpMiiReg: 06 (0x06, MII:"EXPANSION  ", D:"AUTO_NEG_EXPANS") = 0x0009

bfmac_dumpMiiReg: 16 (0x10, MII:"(none)     ", D:"AUX_CONF       ") = 0x0710

bfmac_dumpMiiReg: 17 (0x11, MII:"(none)     ", D:"AUX_CONF_STAT  ") = 0x8008

bfmac_dumpMiiReg: 18 (0x12, MII:"DCOUNTER   ", D:"10T_CONF_STAT  ") = 0x7800

bfmac_dumpMiiReg: 19 (0x13, MII:"FCSCOUNTER ", D:"(none)         ") = 0x0000

bfmac_dumpMiiReg: 20 (0x14, MII:"NWAYTEST   ", D:"(none)         ") = 0x0000

bfmac_dumpMiiReg: 21 (0x15, MII:"RERRCOUNTER", D:"MDINTR         ") = 0x0f00

bfmac_dumpMiiReg: 22 (0x16, MII:"SREVISION  ", D:"RCV_ERR_COUNTER") = 0x0000

bfmac_dumpMiiReg: 23 (0x17, MII:"RESV1      ", D:"DISCONNECT_CNTR") = 0x0000

bfmac_dumpMiiReg: 24 (0x18, MII:"LBRERROR   ", D:"RSTLH_STAT     ") = 0x0ce0

bfmac_dumpMiiReg: 25 (0x19, MII:"PHYADDR    ", D:"(none)         ") = 0x0000

bfmac_dumpMiiReg: 26 (0x1a, MII:"RESV2      ", D:"(none)         ") = 0x0000

bfmac_dumpMiiReg: 27 (0x1b, MII:"TPISTATUS  ", D:"(none)         ") = 0x0000

bfmac_dumpMiiReg: 28 (0x1c, MII:"NCONFIG    ", D:"(none)         ") = 0x0000

 

The values seem ok to me. I was curious if the ISOLATE bit in BMCR would be set but that is not the case. The effect of ISOLATE described in the datasheet seems to match the board's behavior.

 

A query of the Blackfin's EMAC regs at the end of bfin_mac TX function gives:

 

bfmac_dumpEmacReg: EMAC_OPMODE      (0xffc03000) = 0x14090821

bfmac_dumpEmacReg: EMAC_ADDRLO      (0xffc03004) = 0x21ad8002

bfmac_dumpEmacReg: EMAC_ADDRHI      (0xffc03008) = 0x2f36

bfmac_dumpEmacReg: EMAC_HASHLO      (0xffc0300c) = 0x80000000

bfmac_dumpEmacReg: EMAC_HASHHI      (0xffc03010) = 0x0000

bfmac_dumpEmacReg: EMAC_STAADD      (0xffc03014) = 0x0700

bfmac_dumpEmacReg: EMAC_STADAT      (0xffc03018) = 0x0000

bfmac_dumpEmacReg: EMAC_FLC         (0xffc0301c) = 0x0000

bfmac_dumpEmacReg: EMAC_VLAN1       (0xffc03020) = 0x8100

bfmac_dumpEmacReg: EMAC_VLAN2       (0xffc03024) = 0xffff

bfmac_dumpEmacReg: EMAC_WKUP_CTL    (0xffc0302c) = 0x0000

bfmac_dumpEmacReg: EMAC_WKUP_FFMSK0 (0xffc03030) = 0x0000

bfmac_dumpEmacReg: EMAC_WKUP_FFMSK1 (0xffc03034) = 0x0000

bfmac_dumpEmacReg: EMAC_WKUP_FFMSK2 (0xffc03038) = 0x0000

bfmac_dumpEmacReg: EMAC_WKUP_FFMSK3 (0xffc0303c) = 0x0000

bfmac_dumpEmacReg: EMAC_WKUP_FFCMD  (0xffc03040) = 0x0000

bfmac_dumpEmacReg: EMAC_WKUP_FFOFF  (0xffc03044) = 0x0000

bfmac_dumpEmacReg: EMAC_WKUP_FFCRC0 (0xffc03048) = 0x0000

bfmac_dumpEmacReg: EMAC_WKUP_FFCRC1 (0xffc0304c) = 0x0000

bfmac_dumpEmacReg: EMAC_SYSCTL      (0xffc03060) = 0x1706

bfmac_dumpEmacReg: EMAC_SYSTAT      (0xffc03064) = 0x0000

bfmac_dumpEmacReg: EMAC_RX_STAT     (0xffc03068) = 0x0000

bfmac_dumpEmacReg: EMAC_RX_STKY     (0xffc0306c) = 0x0000

bfmac_dumpEmacReg: EMAC_RX_IRQE     (0xffc03070) = 0x0000

bfmac_dumpEmacReg: EMAC_TX_STAT     (0xffc03074) = 0x400043

bfmac_dumpEmacReg: EMAC_TX_STKY     (0xffc03078) = 0x0043

bfmac_dumpEmacReg: EMAC_TX_IRQE     (0xffc0307c) = 0x0000

bfmac_dumpEmacReg: EMAC_MMC_CTL     (0xffc03080) = 0x0002

bfmac_dumpEmacReg: EMAC_MMC_RIRQS   (0xffc03084) = 0x0000

bfmac_dumpEmacReg: EMAC_MMC_RIRQE   (0xffc03088) = 0x0000

bfmac_dumpEmacReg: EMAC_MMC_TIRQS   (0xffc0308c) = 0x0000

bfmac_dumpEmacReg: EMAC_MMC_TIRQE   (0xffc03090) = 0x0000

 

All EMAC_RXC_ and EMAC_TXC registers are 0x0000. Same dump in u-boot:

 

 

 

ubfmac_dumpEmacReg: EMAC_OPMODE      (0xffc03000) = 0x05010803

ubfmac_dumpEmacReg: EMAC_ADDRLO      (0xffc03004) = 0x21ad8002

ubfmac_dumpEmacReg: EMAC_ADDRHI      (0xffc03008) = 0x2f36

ubfmac_dumpEmacReg: EMAC_HASHLO      (0xffc0300c) = 0x0000

ubfmac_dumpEmacReg: EMAC_HASHHI      (0xffc03010) = 0x0000

ubfmac_dumpEmacReg: EMAC_STAADD      (0xffc03014) = 0x0140

ubfmac_dumpEmacReg: EMAC_STADAT      (0xffc03018) = 0xc5e1

ubfmac_dumpEmacReg: EMAC_FLC         (0xffc0301c) = 0x0000

ubfmac_dumpEmacReg: EMAC_VLAN1       (0xffc03020) = 0xffff

ubfmac_dumpEmacReg: EMAC_VLAN2       (0xffc03024) = 0xffff

ubfmac_dumpEmacReg: EMAC_WKUP_CTL    (0xffc0302c) = 0x0000

ubfmac_dumpEmacReg: EMAC_WKUP_FFMSK0 (0xffc03030) = 0x0000

ubfmac_dumpEmacReg: EMAC_WKUP_FFMSK1 (0xffc03034) = 0x0000

ubfmac_dumpEmacReg: EMAC_WKUP_FFMSK2 (0xffc03038) = 0x0000

ubfmac_dumpEmacReg: EMAC_WKUP_FFMSK3 (0xffc0303c) = 0x0000

ubfmac_dumpEmacReg: EMAC_WKUP_FFCMD  (0xffc03040) = 0x0000

ubfmac_dumpEmacReg: EMAC_WKUP_FFOFF  (0xffc03044) = 0x0000

ubfmac_dumpEmacReg: EMAC_WKUP_FFCRC0 (0xffc03048) = 0x0000

ubfmac_dumpEmacReg: EMAC_WKUP_FFCRC1 (0xffc0304c) = 0x0000

ubfmac_dumpEmacReg: EMAC_SYSCTL      (0xffc03060) = 0x1706

ubfmac_dumpEmacReg: EMAC_SYSTAT      (0xffc03064) = 0x0000

ubfmac_dumpEmacReg: EMAC_RX_STAT     (0xffc03068) = 0x0000

ubfmac_dumpEmacReg: EMAC_RX_STKY     (0xffc0306c) = 0x0000

ubfmac_dumpEmacReg: EMAC_RX_IRQE     (0xffc03070) = 0x0000

ubfmac_dumpEmacReg: EMAC_TX_STAT     (0xffc03074) = 0x0000

ubfmac_dumpEmacReg: EMAC_TX_STKY     (0xffc03078) = 0x0000

ubfmac_dumpEmacReg: EMAC_TX_IRQE     (0xffc0307c) = 0x0000

ubfmac_dumpEmacReg: EMAC_MMC_CTL     (0xffc03080) = 0x0002

ubfmac_dumpEmacReg: EMAC_MMC_RIRQS   (0xffc03084) = 0x0000

ubfmac_dumpEmacReg: EMAC_MMC_RIRQE   (0xffc03088) = 0x0000

ubfmac_dumpEmacReg: EMAC_MMC_TIRQS   (0xffc0308c) = 0x0000

ubfmac_dumpEmacReg: EMAC_MMC_TIRQE   (0xffc03090) = 0x0000

 

Again, all EMAC_RXC_ and EMAC_TXC registers are 0x0000. The differences are:

 

EMAC_OPMODE:  uboot=0x05010803 uclinux=0x14090821

EMAC_HASHLO:  uboot=0x00000000 uclinux=0x80000000

EMAC_STAADD:  uboot=0x0140     uclinux=0x0700

EMAC_STADAT:  uboot=0xc5e1     uclinux=0x0000

EMAC_VLAN1:   uboot=0xffff     uclinux=0x8100

EMAC_TX_STAT: uboot=0x00000000 uclinux=0x00400043

EMAC_TX_STKY: uboot=0x0000     uclinux=0x0043

 

The EMAC_STAxxx and EMAC_TX_xxx regs shouldn't matter. So it is different

EMAC_OPMODE, EMAC_HASHLO, and EMAC_VLAN1.

 

OPMODE:

* uClinux has DRO ("Disable Receive Own Frames") set

* U-Boot has "RMII" bit set

* uClinux has LCTRE ("Enable TX Retry on Late Collision") set

* uClinux has HM ("Hash Filter Multicast Addresses") set

* U-Boot has ASTP ("Enable Automatic Pad Stripping") set

 

The most fundamental difference is MII mode vs. RMII mode. Looking at the PHY registers captures with uClinux (first table),  AUX_CONF is set to 0x0710, which includes the "RMII Enable" bit (0x0100). In other words, uClinux has the MAC in MII mode and the PHY in RMII mode.

 

From what I understand, the clocking is different in these modes. Different clock lines, different frequency. That should be the problem.

 

I tried to put the uClinux bfin_mac driver in RMII mode or the PHY in MII mode. The old Linux kernel (uClinux 2006 release) had a switch BFIN_MAC_RMII (which was set in the working kernel). That switch is gone in the 2010R1 release but still present in 2009R1.1 release.  Set this flag to "y" (although marked as EXPERIMENTAL) - works.

 

So, the MII mode is broken - the PHY is not set to MII mode by the linux kernel. The U-Boot uses RMII which works fine.

TranslateQuoteReplyEditDelete

 

 

2010-11-08 22:44:40     Re: DNP5370 / No ethernet

Sonic Zhang (CHINA)

Message: 95672   

 

How did you set your phy mode in your board file?

 

In 2010R1, the phy_mode is set to PHY_INTERFACE_MODE_MII in board file by default.

QuoteReplyEditDelete

 

 

2010-11-08 23:11:43     Re: DNP5370 / No ethernet

Mike Frysinger (UNITED STATES)

Message: 95673   

 

files that start with a dot are automatically renamed.  but this isnt instantaneous, so you simply need to wait for the job to kick in and fix things for you.

QuoteReplyEditDelete

 

 

2010-11-09 03:03:02     Re: DNP5370 / No ethernet

Andreas Schallenberg (GERMANY)

Message: 95681   

 

I did not set PHY_INTERFACE_MODE_MII at all (didn't know about it). My assumption was that whichever mode is selected - the MAC and PHY would use the same. Since the kernel option for RMII was marked as experimental in 2009R1.1 and gone in 2010R1-RC2 I it looked like RMII was gone and only MII was left.

TranslateQuoteReplyEditDelete

 

 

2010-11-09 03:26:44     Re: DNP5370 / No ethernet

Mike Frysinger (UNITED STATES)

Message: 95691   

 

the platform resources were redone in 2010R1 to give complete control to the boards file.  review the bf537-stamp board file to figure things out.

 

you cant really ask the PHY what mode it is in because you need to request the pins before you can even talk to the PHY.  plus, some of the pins may not even be connected which would further cause communication problems.

QuoteReplyEditDelete

 

 

2010-11-09 03:44:16     Re: DNP5370 / No ethernet

Andreas Schallenberg (GERMANY)

Message: 95692   

 

I understand. So the problem is to figure out the current state at of the PHY when the Linux kernel boots. That raises some other questions: I don't know the details about RMII and MII, but wouldn't it be possible to assume RMII first, try to talk and then try to switch to MII if unsuccessful? Some kind of auto-detection?

 

I have seen U-Boot using the PHY in RMII mode. If Linux cannot switch that mode, why is it possible to use MII mode here? Is there a way to put the PHY in MII mode for U-Boot as well?

TranslateQuoteReplyEditDelete

 

 

2010-11-09 03:49:52     Re: DNP5370 / No ethernet

Mike Frysinger (UNITED STATES)

Message: 95693   

 

as the board porter, you absolutely should know how things are wired.  or you know someone who created the PCB who you can ask.

 

as i said, it isnt just a question of "MII or RMII".  some of the pins even within those sets may not be usable.

 

u-boot is the same -- you hard code the settings at compile time in the board config header.  MII or RMII or board-specific set of pns.

QuoteReplyEditDelete

 

 

2010-11-09 04:11:20     Re: DNP5370 / No ethernet

Michael Hennerich (GERMANY)

Message: 95694    RMII (Reduced Media Independent Interface) versus MII (Media Independent Interface)

depends on how your PHY is wired.

 

Probing is not a legal option, since you may have used (wired) the RMII unused pins for different purposes.

QuoteReplyEditDelete

 

 

2010-11-09 04:29:11     Re: DNP5370 / No ethernet

Andreas Schallenberg (GERMANY)

Message: 95695   

 

Thank you all for your responses. They were a great help for me.

 

I don't have the PCB files or the wiring for that board, just a coarse block diagram and an older uClinux that runs on it. So it was a gray box for me.

 

I'll try the board config option for RMII in 2010R1, make SPI+NAND work (in 2009 release everything works, so it shouldn't be that difficult) and then offer my U-Boot and uClinux board files for inclusion in further U-Boot and uClinux releases. I am sure the board files need some pruning of old options since they "evolved" from 2006 release to 2009 and finally to 2010.

TranslateQuoteReplyEditDelete

 

 

2010-11-09 04:38:51     Re: DNP5370 / No ethernet

Mike Frysinger (UNITED STATES)

Message: 95696   

 

we're happy to review & include board ports for u-boot and linux in the main tree.  then upgrades like this would be taken care of for you ;).

Attachments

Outcomes