EtherUSB

I found a very old D-Link USB→Ethernet adapter in my cupboard. It’s a DU-E10 (10 MB/s). Product/Vendor 07b8:abc1, which I was amazed to see on the list of internally recognized adapters by EtherUSB! However, it doesn’t appear to work. Rx bytes remain constantly at zero. Tx bytes there are a few. I know the adapter works because I tried it under Windows – and was surprised how fast it felt. Has anyone else got any experience with this adapter? I tried briefly to look for SysLog output, but there didn’t seem to be any. Does debug out need enabling somehow? This was with the latest stable release (0.08, I think) and the 0.10 alpha, too. Can anyone offer any insight? Many thanks in advance!

EDIT: Some more info. *ejinfo gives (some info cut to save my fingers!):

Backend: Pegasus

Link status: up, unknown speed, unknown duplex, polarity correct, auto

Controller mode: promiscuous

Does that mean it hasn’t managed to negotiate with my router?

Could mean that the PHY has gone into a mode the driver doesn’t know about. Possibly EtherUSB is missing a 10Mbs half duplex mode from its parsing routines.

Possibly its has become jammed into half duplex TX only mode somehow?

Don’t know if it is relevant, but Thomas Millius did say that EtherUSB didn’t do 10Mbit stuff on Beagle either, in a recent email interchange.

Thanks Stephen and Andrew. I think 10 MB/s should be supported by EtherUSB in general, but not by certain backends. As I understood it, the Pegasus backend did support 10 MB/s. Anyway, clearly I need some debug output. I must look into why no SysLog output is being produced.

Okay, I’ve got some SysLog output now. Init looks good:

USB9: aue_reset: enter
USB9: aue_setmulti: enter
USB9: MII PHY 0 status = 7809
USB9: backend 'Pegasus', MAC 00:50:BA:78:99:7F
USB9: bound to interface ej0
mii control ffff -> 3000

I did managed to trigger one error, but I’m not exactly sure how. PINGing doesn’t generally seem to cause an error to trigger. The one I got looks like this:

USB9: aue_csr_write_1: reg=0x25 err=Bad request
USB9: MII read timed out
USB9: MII read failed, reg=0, err=Bad request

I’ll try delving into the Pegasus backend source to see if I can make any sense of it! In the meantime, if anyone has any thoughts, I’d be interested to hear them! Thanks.

Since the speed negotiation is done in the PHY and MII abstracts that from the driver it is not up to the backends themselves to support 10Mbs.

In this instance it looks like the topend is perhaps asking the card to go into a mode that it cannot do. Try logging writes to the phy/mii from the main module c file.

Thanks again, Stephen. It looks like all writes to the PHY go through pegasus_phy_write in pegasus.c, so logging reg_no and val there should probably reveal all the action that’s going on. I haven’t got a compiler-enabled machine with me at the moment and I’m on the road, so I’ll have to recompile the module with that logging enabled next week.

In the meantime, I might try setting the LSYS flag, as I can see from the source that quite a lot of different initialisation goes on if that’s the case, and just maybe it’s needed for this adapter…

Nah, setting the LSYS option didn’t help. In fact (perhaps this is relevant, because looking at the source, I can’t see why it should be the case), specifying LSYS for this adapter makes the TX bytes stay at zero, and the RX bytes go up and up. This is the opposite of what I see without the LSYS flag, when TX bytes go up, but RX bytes stay at zero. Very strange!

If (as i suspect) its the wrong PHY setup being passed to the phy from the rest of the machine there really won’t be any settings you can play with to make this work. Which version of EtherUSB did you have and I’ll compile you up a version logging phy_writes/reads?

Thanks, Stephen. That’s a kind offer. I’ve tried both 0.08 and 0.10, but mainly I’ve been working with version 0.10. If you could compile a logging version for me, that’d speed up the debugging for sure. I’m thinking I might need to open the box up and find out what physical hardware is inside so I can try to obtain some datasheets to see what values I should be expecting. Will that be useful, do you think?

This link suggests that the chipset is the KLSI KL5USB101B. I don’t know if that’s enough information, though.

What does the device identify itself as? According to NetBSD’s usbdevs file, device 07b8:abc1 should be an AboCom Systems XX10, not a D-Link device.

What does the device identify itself as? According to NetBSD’s usbdevs file, device 07b8:abc1 should be an AboCom Systems XX10, not a D-Link device.

It says it’s a “USBs USB Ethernet Adapter”, with “USBs” being the manufacturer.

Stephen Gowdy’s list shows 07b8:abc1 as

DU-E10 Ethernet [pegasus]

Dave, thanks for your input on this. Stephen Gowdy’s list agrees with my device at least!

I opened it up, and the main chip is an ADMtek Pegasus AN986 (0038ACAER19720.1)

There’s also a Broadcom BCM5201 (KPT CT0020B1 P 6395) in there and a couple of other support ICs.

I’ll try hunting out some datasheets later today if I have time.

Can you Ethernet pros out there explain a couple of points?

1) The MII status returned is 7809. Wikipedia says:
7800 Capable of 10/100 HD/FD (most common)
Does the fact that this device is supposed to by 10MB/s only (not 100) mean that this status is wrong, or is it just that the PHY is capable of the higher speed, but the rest of the hardware isn’t?

2) Again according to Wikipedia, MII is only used for 100MB/s links. AUI is the equivalent protocol for 10MB/s. Is this just over-zealous Wikipediaring (seems most likely), or in fact is MII not going to work in talking to the BCM5201 PHY in this device?

Thanks in advance!

The MII code in versions of EtherUSB up to and including version 0.10 is very incomplete and almost certainly doesn’t support 10Mb properly, especially if the PHY supports 100Mb. I’ve been working on this and there is now a (development) 0.11 available for download from the usual place (link posted previously).

The main change is that mii.c now reads the result of the PHY’s auto-negotiation properly. It also now configures the PHY to a specific link type by setting the auto-neg advertisement register.

This has changed the way that the EtherUSB’s mii code is used. It will update the net_status_t struct. The backend must (usually) then configure the MAC to match the link settings returned in that struct. See one of the asix backends for an example.

I’ve updated the Asix and MCS backends to work with this. I’ve not tested the Pegasus or SMSC backends at all – I’ve made them compile, but they may not (probably don’t) work at present.

James, thanks a lot for this. That explains a lot! With my device, EtherUSB 0.11 reports full duplex instead of unknown duplex with version 0.10.

I’ve started looking over the new code. One thing that’s not clear to me is why the read_state callback has disappeared. Any chance you could explain? Thanks!

The backend’s status function, if defined, now gets polled by the core. Given that this is needed for the MII code to monitor the link it seemed worth centralising.

Rob Coleman said “I’m using USBDriver 0.51 (I think) – it’s the one in the latest ROM build and I think that EtherUSB 0.10 needs 0.49 or above. I got the same problems with 0.49 in the previous build I was using.”

James, this might be why I can’t find USBDriver 0.49+, it’s only in the OMAP ROM :(
Can anyone help with a softloadable version of 0.49 or higher, to use with an Iyonix (and James’ EtherUSB), since the prebuilt download is only 0.48.

Dave, how about trying the 5.17 softload for the Iyonix as my USBDriver module states it is 0.54

I’ve just uploaded EtherUSB 0.13. The only significant change over 0.12 is that it should ensure that the Inet$EtherType is set as required by the DCI specification. EtherUSB doesn’t fully follow the DCI spec in a number of ways, mainly because its devices can disappear if someone unplugs them. On the off-chance you care, see the !ReadMe for details.

http://effarig.co.uk/riscos/

When I change the settings of my Pandaboard noticed a small bug in the !ReadMe.
Change the MAC address is done by:

*Set EtherUSB$MAC_Configured XX:XX:XX:XX:XX:XX

Sorry, this is an old bug since we worked on XM port.

Change the MAC address is done by

The ReadMe looks right to me.

In the section on configuring, if you wish to apply options to a specific adapter you use
EtherUSB$MAC_123456123456 options
this system variable is not to set the MAC address, it’s to apply “options” to the given adapter if it is plugged in.

For interfaces which don’t provide a MAC address, such as the onboard controllers, the MAC address is set with
EtherUSB$MAC_Configured 123456123456
as you say. The example is given in the SMSC9xxx section of the manual (offboard USB ethernet interfaces must provide MACs).

Sorry. You’re right. I was apparently still not quite awake this morning.