EtherUSB

Does this mean using the on-board network socket?

Maybe you missed this (I’ve not tried it yet).

Maybe you missed this

Can the default year be 2011 rather than 1970? Or must this wait for CMOS RAM?

I may have come across a problem with EtherUSB 0.09 (8th Jan) on my system as it seems to somehow swamp my network, and slows internet access from other machines on the network down to glacial speeds. As I originally had problems with it not recognising my ethernet hub, I will do a few more hardware swaps to see if I can confirm the problem, but is there any diagnostic information which would be useful to send back?

After some testing I definitely have a problem. I have an RPC (i-cubed NIC), Iyonix, PC and BB-xM connected directly to a Belkin router. Without the BB-xM connected, I get an average download speed of around 8-12Mbps (using http://www.broadbandspeedchecker.co.uk) consistently. However, immediately on plugging the BB-xM into the router, my download speeds drop to around 3Mbps, and after leaving it connected for 20-30mins it can drop as low as 0.1Mbps!

I didn’t experience this effect previously, when using EtherUSB 0.08, but do get it with either the on-board NIC or the USB_Ethernet adaptor and EtherUSB 0.09. Has anyone else found this, or could suggest a possible cause?

Is there anything network related running on the BBxM? Does unplugging the BBxM allow the network to recover. Which backend(s) does this happen with. *ejinfo will show the number of bytes/packets send/recieved. Do any of these increase rapidly?

This is with the BBxM doing nothing, just started from a fresh boot.

This is the result of *ejinfo immediately on startup and then 5 & 10 mins later. By this point the download speed had reached effectively zero!

Unit 0 (USB bus 1, address 4, Devices:$.USB4):
  Backend:          SMSC95xx
  Ethernet address: 00:50:C2:01:01:01
  Link status:      up, 100Mb, full duplex, polarity correct, auto
  Controller mode:  unicast, broadcast, multicast  

Frame types claimed:
  IEEE 802.3                 handler=(FC32BA90,FB40752C)
  Ethernet 8035 (normal)     handler=(FC2E9970,FB40743C)
  Ethernet 0806 (normal)     handler=(FC2E9970,FB40743C)
  Ethernet 0800 (multicast)  handler=(FC2E9970,FB40743C)

Statistics summary:
  TX frames          13            RX frames   4           
  TX bytes           741           RX bytes    290         
  TX errors          0             RX errors   0           
  TX queue length    0             RX unwanted 0           
  TX queue overflows 0

Unit 0 (USB bus 1, address 4, Devices:$.USB4):
 Backend:          SMSC95xx
 Ethernet address: 00:50:C2:01:01:01
 Link status:      up, 100Mb, full duplex, polarity correct, auto
 Controller mode:  unicast, broadcast, multicast

Frame types claimed:
  IEEE 802.3                 handler=(FC32BA90,FB40752C)
  Ethernet 8035 (normal)     handler=(FC2E9970,FB40743C)
  Ethernet 0806 (normal)     handler=(FC2E9970,FB40743C)
  Ethernet 0800 (multicast)  handler=(FC2E9970,FB40743C)

Statistics summary:
  TX frames          37            RX frames   30          
  TX bytes           2336          RX bytes    2665        
  TX errors          0             RX errors   0           
  TX queue length    0             RX unwanted 0           
  TX queue overflows 0

Unit 0 (USB bus 1, address 4, Devices:$.USB4):
 Backend:          SMSC95xx
 Ethernet address: 00:50:C2:01:01:01
 Link status:      up, 100Mb, full duplex, polarity correct, auto
 Controller mode:  unicast, broadcast, multicast

Frame types claimed:
  IEEE 802.3                 handler=(FC32BA90,FB40752C)
  Ethernet 8035 (normal)     handler=(FC2E9970,FB40743C)
  Ethernet 0806 (normal)     handler=(FC2E9970,FB40743C)
  Ethernet 0800 (multicast)  handler=(FC2E9970,FB40743C)

Statistics summary:
  TX frames          61            RX frames   54          
  TX bytes           3968          RX bytes    4541        
  TX errors          0             RX errors   0           
  TX queue length    0             RX unwanted 0           
  TX queue overflows 0

I have to power down the router, give it 30sec and then restart it to regain full download speed, simply unpligging the BBxM does not restore full speed.

Erm, don’t worry about this just yet, I’ve just noticed some other odd behaviour from my router, so I’ll get hold of another router and test it with that first!

In case it might help, I found that one network switch I used with an A9home showed the same symptoms. The switch was behaving as a hub, broadcasting all network traffic rather than routing it, and the a9home seemed to broadcast it back! Connecting the a9home to the ADSL router solved the problem. Later I bought another network switch, from a reputable delaer this time (R-Comp), and the a9home worked fine connected to it. However disconnecting the a9home in the original setup caused the problem to go away.

Erm, don’t worry about this just yet, I’ve just noticed some other odd behaviour from my router, so I’ll get hold of another router and test it with that first!

Ok, swapped the router and I now get no problems and consistent download speeds of 12Mbps even after having the BBxM plugged into it overnight.

Belkin’s ‘lifetime warranty’ may be getting a call!

Has there been an official release of the EtherUSB that supports the internet chip in the BeagleBoard xm that was being discussed around the 9th of this month?

The link at the top of this page works but is not an official source. However the alpha 0.09 version is available from the official site: http://effarig.co.uk/riscos/

@ Michael Grunditz

While trying to port EtherUSB to a DM9500 Chip based Adapter I found out that not all adpters that were supposed to work with EtherUSB did work. Now I have a LogiLink adapter that does work. Before loosing too much time with the Adapter you have, better try a different one. If you are interested in more details please let me know; I can check for the chip type where I had the problems with.

Did you have time to continue with the porting effort? To cross check compilation I could compile code with the Acorn C/C++ compiler if needed.

What is there is not correct as it doesn’t configure the MAC to match the results of the auto-negotiation. I’ve been working on this and have a much more complete implementation. I need to finish it off and do a lot of testing, though unfortunately I first need to fix a corrupt disc so I can compile things again. Once complete, it should make handling link configuration and auto-negotiation easy to support for devices exposing the MII interface, probably most of them.

On Jan 25 Chris Hall said: “The link at the top of this page works but is not an official source. However the alpha 0.09 version is available from the official site: http://effarig.co.uk/riscos/“

Unfortunately the alpha 0.09 (09 Nov 2010) version on that site is from last Nov. and does not support the internal NIC. I’m talking about the version produced at the beginning of this month (as shown in the link you referrd to at the top of the page) which on the c.s.a.networking “Netsurf not working thread” on Jan 10 Thomas Milius requested we did not use. He said “I am sure we can present you a working official version within one week.” I complied with his wish but it is now two and a half weeks later and still no news. The older etherUSB 0.09 (09 Nov 2010) combined with the USB ethernet adaptor I have reverted to until we have permission to use the new one, is producing lots of aborts when using ShareFS whereas the newer EtherUSB 0.09 08 Jan 2011 did not. So does anyone know when we can officially use the new version?

Alan

Don’t forget that no one’s getting paid for this work – so if things take longer than expected, then don’t be surprised. All the same, there’s probably a very good explanation… and even if not, then so be it!

Running the test version here with the xM internal ethernet port has been good so far, but I’ve just discovered that it doesn’t survive a reboot with the power on. RISC OS startup hangs at the DHCP contact stage. Removing all power – both to the board and to the external USB HD - and restarting is fine. I’ve discovered this since installing the latest (27th Jan) ROM image because it now seems to allow the shutdown/restart process on the xM, which the last version I tried didn’t do.

I won’t worry about the beta-version too much. I made some mistakes inside the settings and it was sometimes a trial and error process. I don’t know which version Detlef placed on the beta-tester side at the end.

Perhaps you are closer to an offical release from James than you are expecting.

EtherUSB 0.10 is now available for download which includes support for the chip in the BeagleBoard xM thanks to Thomas Milius and friends. It is otherwise identical to 0.09. It is available for download from http://effarig.co.uk/riscos.

Please note that I do not have a device I can test this on so bugs/queries regarding the xM are better mentioned in this thread where Thomas may be able to help.

One important thing to note is that the BB xM does not have a MAC address. EtherUSB has a default one compiled in, however if you have multiple BB xMs on the same network then you can set a system variable before loading the module, see the ReadMe in the ZIP file for details.

Thanks for this.

One important thing to note is that the BB xM does not have a MAC address. EtherUSB has a default one compiled in, however if you have multiple BB xMs on the same network then you can set a system variable before loading the module

Would it be possible to create a MAC address from the BBxM’s serial number, thus ensuring each one has a different MAC?

Yes this is an option, assuming there is a call to read a suitable number from. I’d probably encode the ej unit number as well.

REM Read L4_DIE_ID into id%
DIM code% 256
P%=code%
[ OPT 2
MOV R0,#14
MOV R1,#&48000000
ORR R1,R1,#&300000
SWI "OS_Memory" 
SWI "OS_EnterOS" 
ADD R2,R2,#&A200
ADD R2,R2,#&18
LDMIA R2,{R0-R2,R5}
STMIA R4,{R0-R2,R5}
MSR CPSR_c,#16
MOV R0,#15
MOV R1,R3
SWI "OS_Memory" 
MOV PC,R14
]
DIM id% 16
E%=id%
CALL code%

REM Print it out
OSCLI("*memory "+STR$~(id%)+" + 10")

Thanks James (and the others who have worked on it) for providing the EtherUSB 0.10 it is much appreciated. Now using the xm’s own NIC the hang ups that I was getting using the usb ethernet adaptor, especially when transferring larger files over ShareFS, have gone.

Best wishes Alan

One hint regarding ShareFS:

Rainer Schubert and myself detected that the setting

ShareFSWindow 1

on Iyonix will cure this effect independently of the new version. Ok on my machine I didn’t had problems with the new version in this direction for a while even I am not using this statement.

Other note: It is likely that 10MB/s connections won’t work. I never puzzled out why until now.

The idea to use the serial number instead a fix wired number is good. However it should fit into 46 Bit in which way ever compressed. 2 Bits will be required to use local adresses.

If anyone notes problems ont he BB xM please mention inside this thread. I shall try to help.

Is speed ok? I didn’t note trouble inside my network since a week and found the speed ok. However nearly every network is different and so there might be silly effects in some cases.

After testing 0.10a I can report that it now successfully works through the shutdown/restart cycle on my BB xM without requiring a power-off in between.

Mmm using EtherUSB with the new ROM and a freshly installed Boot, HardDisk. Onboard NIC remains unlit and BB hangs at the DHCP point, not being able to connect. I can terminate this via ESC but the “Floppy boot, cancel, retry” option box won’t let me through to the desktop. Only by deleting the CMOS file can I access the system and manipulate the boot file on HD4

Am I missing something?