Hello
I own an USB dongle which is a "Davicom DM96xx USB 10/100 Ethernet".
According to the CHIP_ID, it is a DM9620.
Since I needed for bringing network to uboot for a board, I have started to create its uboot's driver.
My uboot driver is based on the dm9600 Linux driver.
The dongle was working but very very slowy (24Kib/s).
After some debug i found that the main problem was that it always link to 10Mbit/s Half-duplex. (according to the MAC registers)
For checking the status of the dongle I have plugged it on a Linux box which give me:
dm9601 6-2:1.0 enp0s29f0u2: link up, 100Mbps, full-duplex, lpa 0xFFFF
But in fact the Linux driver is tricked.
I have added debug of MDIO write/read and got:
[157550.926974] dm9601 6-2:1.0 (unnamed net_device) (uninitialized): dm9601_mdio_write() phy_id=0x00, loc=0x00, val=0x8000
[157550.931962] dm9601 6-2:1.0 (unnamed net_device) (uninitialized): dm9601_mdio_write() phy_id=0x00, loc=0x04, val=0x05e1
[157550.951967] dm9601 6-2:1.0 (unnamed net_device) (uninitialized): dm9601_mdio_read() phy_id=0x00, loc=0x00, returns=0xffff
[157550.951971] dm9601 6-2:1.0 (unnamed net_device) (uninitialized): dm9601_mdio_write() phy_id=0x00, loc=0x00, val=0xffff
[157567.781989] dm9601 6-2:1.0 enp0s29f0u2: dm9601_mdio_read() phy_id=0x00, loc=0x01, returns=0xffff
[157567.796985] dm9601 6-2:1.0 enp0s29f0u2: dm9601_mdio_read() phy_id=0x00, loc=0x01, returns=0xffff
[157567.811989] dm9601 6-2:1.0 enp0s29f0u2: dm9601_mdio_read() phy_id=0x00, loc=0x04, returns=0xffff
[157567.826974] dm9601 6-2:1.0 enp0s29f0u2: dm9601_mdio_read() phy_id=0x00, loc=0x05, returns=0xffff
[157567.841972] dm9601 6-2:1.0 enp0s29f0u2: dm9601_mdio_read() phy_id=0x00, loc=0x00, returns=0xffff
[157567.856974] dm9601 6-2:1.0 enp0s29f0u2: dm9601_mdio_read() phy_id=0x00, loc=0x01, returns=0xffff
[157567.871990] dm9601 6-2:1.0 enp0s29f0u2: dm9601_mdio_read() phy_id=0x00, loc=0x04, returns=0xffff
[157567.886974] dm9601 6-2:1.0 enp0s29f0u2: dm9601_mdio_read() phy_id=0x00, loc=0x05, returns=0xffff
[157567.906010] dm9601 6-2:1.0 enp0s29f0u2: dm9601_mdio_read() phy_id=0x00, loc=0x01, returns=0xffff
[157567.920986] dm9601 6-2:1.0 enp0s29f0u2: dm9601_mdio_read() phy_id=0x00, loc=0x01, returns=0xffff
[157567.935975] dm9601 6-2:1.0 enp0s29f0u2: dm9601_mdio_read() phy_id=0x00, loc=0x04, returns=0xffff
[157567.950974] dm9601 6-2:1.0 enp0s29f0u2: dm9601_mdio_read() phy_id=0x00, loc=0x05, returns=0xffff
[157567.965974] dm9601 6-2:1.0 enp0s29f0u2: dm9601_mdio_read() phy_id=0x00, loc=0x00, returns=0xffff
[157567.980970] dm9601 6-2:1.0 enp0s29f0u2: dm9601_mdio_read() phy_id=0x00, loc=0x01, returns=0xffff
[157567.995973] dm9601 6-2:1.0 enp0s29f0u2: dm9601_mdio_read() phy_id=0x00, loc=0x04, returns=0xffff
[157568.010971] dm9601 6-2:1.0 enp0s29f0u2: dm9601_mdio_read() phy_id=0x00, loc=0x05, returns=0xffff
[157568.025973] dm9601 6-2:1.0 enp0s29f0u2: dm9601_mdio_read() phy_id=0x00, loc=0x01, returns=0xffff
[157568.040969] dm9601 6-2:1.0 enp0s29f0u2: dm9601_mdio_read() phy_id=0x00, loc=0x01, returns=0xffff
[157568.055971] dm9601 6-2:1.0 enp0s29f0u2: dm9601_mdio_read() phy_id=0x00, loc=0x04, returns=0xffff
[157568.070970] dm9601 6-2:1.0 enp0s29f0u2: dm9601_mdio_read() phy_id=0x00, loc=0x05, returns=0xffff
[157568.085971] dm9601 6-2:1.0 enp0s29f0u2: dm9601_mdio_read() phy_id=0x00, loc=0x00, returns=0xffff
[157568.100971] dm9601 6-2:1.0 enp0s29f0u2: dm9601_mdio_read() phy_id=0x00, loc=0x01, returns=0xffff
[157568.115973] dm9601 6-2:1.0 enp0s29f0u2: dm9601_mdio_read() phy_id=0x00, loc=0x04, returns=0xffff
[157568.130970] dm9601 6-2:1.0 enp0s29f0u2: dm9601_mdio_read() phy_id=0x00, loc=0x05, returns=0xffff
So the problem is the same than in my uboot driver, the PHY always return 0xFFFF.
I have tried lots of hack but fail to bring the PHY up.
So it exsists two problem:
- Linux saying 100Mbps, full-duplex even if it is false.
- the PHY which seems in bad state.
For further information, the PHY is the internal one.
On the dongle, only the davicom chip is present (along with some resistors/capacitors and a quartz), so I think of the absence of an external PHY.
Regards
On Thu, Jun 27, 2019 at 03:21:37PM +0200, Corentin Labbe wrote:
> Hello
>
> I own an USB dongle which is a "Davicom DM96xx USB 10/100 Ethernet".
> According to the CHIP_ID, it is a DM9620.
>
> Since I needed for bringing network to uboot for a board, I have started to create its uboot's driver.
> My uboot driver is based on the dm9600 Linux driver.
>
> The dongle was working but very very slowy (24Kib/s).
> After some debug i found that the main problem was that it always link to 10Mbit/s Half-duplex. (according to the MAC registers)
>
> For checking the status of the dongle I have plugged it on a Linux box which give me:
> dm9601 6-2:1.0 enp0s29f0u2: link up, 100Mbps, full-duplex, lpa 0xFFFF
>
> But in fact the Linux driver is tricked.
>
> I have added debug of MDIO write/read and got:
> [157550.926974] dm9601 6-2:1.0 (unnamed net_device) (uninitialized): dm9601_mdio_write() phy_id=0x00, loc=0x00, val=0x8000
Writing the reset bit. Ideally you should read back the register and
wait for this bit to clear. Try adding this, and see if this helps, or
you get 0xffff.
> [157550.931962] dm9601 6-2:1.0 (unnamed net_device) (uninitialized): dm9601_mdio_write() phy_id=0x00, loc=0x04, val=0x05e1
Advertisement control register.
> [157550.951967] dm9601 6-2:1.0 (unnamed net_device) (uninitialized): dm9601_mdio_read() phy_id=0x00, loc=0x00, returns=0xffff
And now things are bad. In theory, the power down bit is set, and some
PHYs don't respond properly when powered down. However, it is unclear
how it got into this state. Did the reset kill it, or setting the
advertisement? Or is the PHY simply not responding at all. The MDIO
data lines have a pull up, so if the device does not respond, reads
give 0xffff.
Maybe also check register 0, bit 7, EXT_PHY. Is it 0, indicating the
internal PHY should be used?
You could also try reading PHY registers 2 and 3 and see if you can
get a valid looking PHY ID. Maybe try that before hitting the reset
bit?
> So it exsists two problem:
> - Linux saying 100Mbps, full-duplex even if it is false.
The driver is using the old mii code, not a phy driver. So i cannot
help too much with linux. But if you can get the MDIO bus working
reliably, it should be possible to move this over to phylib. The
internal PHY appears to have all the standard registers, so the
generic PHY driver has a good chance of working.
Andrew
On Thu, Jun 27, 2019 at 04:43:39PM +0200, Andrew Lunn wrote:
> On Thu, Jun 27, 2019 at 03:21:37PM +0200, Corentin Labbe wrote:
> > Hello
> >
> > I own an USB dongle which is a "Davicom DM96xx USB 10/100 Ethernet".
> > According to the CHIP_ID, it is a DM9620.
> >
> > Since I needed for bringing network to uboot for a board, I have started to create its uboot's driver.
> > My uboot driver is based on the dm9600 Linux driver.
> >
> > The dongle was working but very very slowy (24Kib/s).
> > After some debug i found that the main problem was that it always link to 10Mbit/s Half-duplex. (according to the MAC registers)
> >
> > For checking the status of the dongle I have plugged it on a Linux box which give me:
> > dm9601 6-2:1.0 enp0s29f0u2: link up, 100Mbps, full-duplex, lpa 0xFFFF
> >
> > But in fact the Linux driver is tricked.
> >
> > I have added debug of MDIO write/read and got:
> > [157550.926974] dm9601 6-2:1.0 (unnamed net_device) (uninitialized): dm9601_mdio_write() phy_id=0x00, loc=0x00, val=0x8000
>
> Writing the reset bit. Ideally you should read back the register and
> wait for this bit to clear. Try adding this, and see if this helps, or
> you get 0xffff.
>
I get 0xFFFF
> > [157550.931962] dm9601 6-2:1.0 (unnamed net_device) (uninitialized): dm9601_mdio_write() phy_id=0x00, loc=0x04, val=0x05e1
>
> Advertisement control register.
>
> > [157550.951967] dm9601 6-2:1.0 (unnamed net_device) (uninitialized): dm9601_mdio_read() phy_id=0x00, loc=0x00, returns=0xffff
>
> And now things are bad. In theory, the power down bit is set, and some
> PHYs don't respond properly when powered down. However, it is unclear
> how it got into this state. Did the reset kill it, or setting the
> advertisement? Or is the PHY simply not responding at all. The MDIO
> data lines have a pull up, so if the device does not respond, reads
> give 0xffff.
>
> Maybe also check register 0, bit 7, EXT_PHY. Is it 0, indicating the
> internal PHY should be used?
>
> You could also try reading PHY registers 2 and 3 and see if you can
> get a valid looking PHY ID. Maybe try that before hitting the reset
> bit?
>
Always get 0xFFFF before and after
Note that the eeprom dump via ethtool -e suffer the same problem.
> > So it exsists two problem:
> > - Linux saying 100Mbps, full-duplex even if it is false.
>
> The driver is using the old mii code, not a phy driver. So i cannot
> help too much with linux. But if you can get the MDIO bus working
> reliably, it should be possible to move this over to phylib. The
> internal PHY appears to have all the standard registers, so the
> generic PHY driver has a good chance of working.
>
I have investigated more and in fact I dont have a dm9620.
I own another diferent dongle in my stock that i never used and fun fact, it has the same VID/PID and the same bug.
I opened both dongle and all chips have no marking and got only 4x8 pins.
Since dm9620 have 64 pins, my dongles are clearly not such hw.
I googled the inscription written on the second case and found a dm9620 clone/counterfeiting named qf9700/sr9700.
But thoses chips should have marking (according to some photos on the web), so I probably own a counterfeiting of a clone/counterfeiting.
Note that the sr9700 driver is mainline but fail to work with my dongle.
At least, now i know that have a chip not designed to work with an external PHY, so all EXTPHY registers could be ignored.
My last ressort is to brute force all values until something happen.
My simple tries, write 0xsomeval everywhere, lead to something, phy/eeprom return now 0x000y.
Probably, this chip doesnt have any PHY...
Regards
> But thoses chips should have marking (according to some photos on
> the web), so I probably own a counterfeiting of a
> clone/counterfeiting.
> At least, now i know that have a chip not designed to work with an external PHY, so all EXTPHY registers could be ignored.
> My last ressort is to brute force all values until something happen.
Does the rest of this work? You can actually transmit/receive frames,
but it is a 10/Half? So the MAC is working, just the PHY is missing?
> My simple tries, write 0xsomeval everywhere, lead to something, phy/eeprom return now 0x000y.
> Probably, this chip doesnt have any PHY...
If you look at dm9601_mdio_write() and dm9601_mdio_read() it always
passes 1. 0 is used for the EEPROM, at least in a real device. so try
1-31 and see if you get anything interesting.
Andrew