EtherUSB

One remark regarding the speed which shows how heavily hardware components are influencing the transmission (always 4 files total 34 MB using RISC OS Filer copy with 10MB Slot space):

1. From NAS to RAM disc (no measureable difference between RAMFS and Memphis): 6-7 Seconds 2. From NAS to USB stick (intenseo): 34 Seconds 3. From NAS to NAS (other directory): 12-13 seconds.

It is always the same USB and always the same EtherUSB. It seems to be a problem of the USB stick at writing. I detected this already in other context. For reading it is quite useable, but for writing …

Another thing to consider when generating MAC addresses is what to do if there are multiple NICs connected to the same machine. The easiest method would probably be to use 4 bits to store the device number.

Yes indeed Jeffrey. Good Point.

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.

I will soon get the compiler. If I have time I will try to add stuff to this driver.

Another question to Stephen Leary. As the IGEPv2 also uses SMSC chips: Is EtherGEP working fine in 10MB mode? If yes are you knowing which registers must be set to do so and can tell me, so that I can try it out with EtherUSB?

Thomas,

The SMSC in the BB-xM is completely different to the chip in the IGEPv2. I have the chip in autonegotiation mode and from the speeds i can get transfers of ~80Mb/sec.

The speed setting is usually set from the OS via the MII interface so its not something you will have to worry about provided you can supply a MII interface to the PHY.

From your earlier posts I provide my MAC generator as a utility function which drivers can access to generate MAC addresses if they have no EPROM. I take Jeffrey’s point about the multiple NICs, possibly i should pass a parameter to that function with the device number.

For EtherUSB I want to be able to setting the MAC address via *EJConfig for devices (so would also work with the system variable based configuration) for devices which support it.

I haven’t worked out exactly how this will work yet, the ability to generate a ‘default’ MAC address was going to be part of it, probably just by defaulting the initial address to something other than 00:00:00:00:00:00.

I’ve got a load changes locally which provide much better handling of MII w.r.t. auto-negotiation. This by and large works, though I’ve not done enough testing yet.

James when you’re happy with the MII changes could I get a patchfile? EtherGEP is EtherUSB with out the USB as you know.

S

Folks could I ask a favour of someone?

Could someone flood ping a riscos box using etherusb and wait for about 20 mins to see if anything crashes on riscos? (no cpu compatibility patches). Please use the lastest ROM. I’d have a go myself but i seem to be failing to locate my usb hub.

I’ve been seeing an issue where I get an abort on data transfer after the icmp sequence wraps. I’ve been doing…

$ sudo ping 192.168.0.22 -i 0 -s 40

I see the same issue with the IGEP and DevKit.

Nevermind…

My stupidity again. If i leave syslog/printf calls in when i test it causes this issue.

Stupid me.

Yes, I’ve noticed in the distant past that Logging to Syslog in EtherUSB’s transmit or receive code does seem to cause nasty things to happen, not sure why. IIRC it logs using SysLog’s interrupt mode, so it should be safe. I suggest using the DADebug module from the ROOL sources if you need logging.

James,

We should probably consider adding an SWI to EtherUSB/GEP which sets the mac address? Then have a single app (or extend ifconfig) to be able to set the mac address.

Whatever we decide to do i’d like to share the approach as closely as possible between the two drivers.

Yes. Does anyone know whether setting the MAC address has been defined in DCI 4?

I ask this because one of the ability flags returned by the inquire SWI indicate whether the driver can change the hardware address, though perhaps this is to inform protocol modules not to cache it.

  SWI <swi-prefix>_SetNetworkAddress (<swi-base> + 8)

    => R0 =  Flags (0, reserved for expansion)
       R1 =  Unit number.
       R2 => Start of address.
       R3 =  Byte length of address (6).

    <= All registered preserved.

    If the driver does not support altering the address or if R3 is 
    invalid then it should return EINVAL (error 0x20E16). If a driver
    supports this call then it must return 1 in bits 5 (has hardware
    address) and 6 (can alter hardware address) of the ability flags
    returned by <swi-prefix>_Inquire.

AFAIK, DCI assumes that all addresses are 48 bit, though I don’t like making assumptions like this and see no harm passing in the length.

<swi-base> + 8 assumes that there aren’t any more SWIs defined in DCI than the ones I know about…

Powers that be: Is there any chance the DCI spec can be published?

Does anyone know whether setting the MAC address has been defined in DCI 4?

After digging through the source code a bit, it doesn’t look like DCI has any capability for inventing/assigning MAC addresses. If you look at line 487 of Internet.riscos.c.module you’ll see that the only real use that the Internet module makes of the INQ_HWADDRVALID flag is to decide whether the interface supports ARP or not.

Although I haven’t searched the full source tree, as far as I can tell there’s no code at all which acts upon the value of the INQ_SOFTHWADDR flag.

Hi,

I’ve just installed EtherUSB 0.10 on my BeagleBoard xM by following the instructions in this thread but am getting Abort on data transfer errors as soon as I run *ejinfo with TCP/IP protocols turned on.

If I leave configure all networking off (TCP/IP, AUN etc.), I can run ejinfo and it shows ej0 as being up. However, as soon I turn it back on I get abort on data transfer at &2018D75C (in EtherUSB?) or &FC1409C0 (in SharedCLibrary?) either before the desktop comes up or when I run ejinfo.

I’m using the latest ROM image and latest HD image. In all other ways the BB works well and I’m really pleased with it.

Any ideas on what I may be doing wrong?

Thanks,

Rob

Hi Rob, I’ve not seen an abort like that before. I don’t have a xM, however if you get an abort from EtherUSB can you provide the start address of the module (the EtherUSB line from *modules will show this). This may help narrow it down.

Hmmmm,

I’ve not tried EtherUSB 0.10 on the xM yet but i really should. Am i right in thinking that 0.10 needs a later version of the USB module? If so can Rob check he has it?

If thats not the case i’ll fire up the xM at the weekend and track down the problem.

Thanks for the quick replies.

EtherUSB is at 0×2018D3D4 SharedCLibrary is at 0xFC12D8FC

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.

Thanks again.

I haven’t had a chance to look into it properly yet, but yesterday I found that I get aborts both during the boot sequence and when entering the desktop if the network cable isn’t plugged in. It’s possible that that’s the problem you’re seeing; certainly I haven’t spotted anything else wrong with 0.10 yet.

I wonder if it’s an alignment issue that most of us don’t see because we apply the patch.

Have you tried the alignment patch? It shouldn’t need it but it might help you get going and also help the diagnosis. The patch is available somewhere on this site. On a mobile device or I’d hunt it down for you.

That address looks like it is in part of the code generated by CMHG. It is invoked when *EJInfo is run with R2=0. It looks like it is setting up the stack before calling the module_command() function:

 STMFD   sp!,{a1,sl,fp,lr} 
 MOV     sl,sp,LSR #20
 MOV     sl,sl,LSL #20
 LDMIA   sl,{v1,v2}
 MOV     a4,ip
 LDR     ip,[ip,#0]           ; Load module private word from address in R12.
 LDMIB   ip,{fp,ip}           ; Abort generated here?
 STMIA   sl,{fp,ip}
 ADD     sl,sl,#540           ; Abort address here.
 MOV     fp,#0
 BL      module_command
 SUB     sl,sl,#540
 STMIA   sl,{v1,v2}
 LDMFD   sp!,{a2,sl,fp,lr}
 CMP     a2,a1
 CMPNE   a1,#0
 MOVEQ   pc,lr
 CMN     a1,#1 
 MOVEQ   a1,#0
 MOV     a2,#0  
 CMP     a2,#&80000000
 MOV     pc,lr    

I can’t remember the details now (it’s a long time since I’ve debugged using Zap…), but I assume that given that the PC is 8 bytes ahead, the abort was generated by the value of the private word pointing somewhere it shouldn’t.

The patch is available somewhere on this site. On a mobile device or I’d hunt it down for you.

It’s in ARMv7 compatibility primer, linked to from the bottom of the getting started page.

James,

Could also happen if the struct became corrupt for some reason. One thing I have noticed is that we are using automatic variables for buffers in many of the drivers we have. This is OK on linux but IIRC Risc OS has a limited stack size.

Might be worth sticking some logging in there or doing a dump of the registers when the abort occurs to find out what the value of the PW is when the module aborts.

Have you tried the alignment patch? It shouldn’t need it but it might help you get going and also help the diagnosis. The patch is available somewhere on this site. On a mobile device or I’d hunt it down for you.

I’m pretty sure that I’m running AOff as part of the boot sequence – I’ll check tonight.

I haven’t had a chance to look into it properly yet, but yesterday I found that I get aborts both during the boot sequence and when entering the desktop if the network cable isn’t plugged in. It’s possible that that’s the problem you’re seeing; certainly I haven’t spotted anything else wrong with 0.10 yet.

This might be it. I’ve mounted my BB inside a Pico-ITX case and the network cable is currently being looped over the board and out of the back. It’s definitely plugged in but it’s possible that the cable has been damaged. I’ll check tonight.

Thanks again for all the help.

Just opened up my BB case and put in a new network cable. I’ve booted it a few times and now all seems well. I suspect that the strain of being looped under the board in a confined space had damaged the old cable.

I’m going to leave the lid off for the time being until I put a permanent network socket on the back of the case.

Many thanks for all the help.