EtherUSB

Jeffrey provided a snippet of code to read the serial number over on the battery thread for my battery charging plug-in.

Not very portable though. Does OMAP port support OS_ReadSysInfo 2 R3,R4? Though given that the ID returned from the above code is longer, perhaps what is needed is a new reason code for OS_ReadSysInfo which can return an ID of arbitrary length.

Jeffrey did say:

So at some point soonish I’ll have to sort out a new OS_ReadSysInfo reason code to allow the full ID to be returned.

So maybe it will happen reasonably soon, especially if you give him a poke about it :-)

Too late for today but I found the problem. Bit like reading a trouble shooting guide and thinking “yeah like who’d be that thick?”

:-(

I did some rough speed tests using the latest version of EtherUSB on an XM.

Using USB Hard drive

Download: 1.5 MiB/s
Upload: 3.5 MiB/s

Using the RAM disc

Download: 5 MiB/s
Upload: 9 MiB/s

How’s reliability looking?

I am using the BB xM since more than a month now (I began to use it heavily with the usebility of the network) and since some days since I got an ARMV7 compatible beta-test version of a program in mail range which will be published soon without running the Iyonix parallel.

My expieriences are very good. The OS is extremly stable and I only detected network problems (LanMan98 in use) using my NAS over LANMAN98 in conjunction with crash of incompatible ARMv7 software and no problems with ShareFS or Internet activities like Browsing/Mailing/Downloading etc.

Ok the 10MB/s problem is still unsolved and I don’t have an idea how to cope with in the SMSC driver part.

The main problem I am facing is the lack of ARMv7 compatibility of a couple of some programs/modules etc. Fortunately the situation seems to improve every day.

From the Beta-Tester community no one noted a problem until now with the network. Most of them seem to use the BB xM as their main RISC OS machine all using EtherUSB and the internal adapter.

But why you are asking?

You are looking forward to buy a BeagleBoard xM, aren’t you ;-)?

I’m selling my BB-xM if anyone wants it? Hardly used it and I use the IGEPv2 more because the hardware interfaces to the network card is so much faster.

I ask because I’m interested in knowing how things are going, especially on the network side. Is this using the built-in Ethernet NIC on the BB or an external USB dongle? I think we really need to be using the built-in NIC.

We’re using the built in NIC on the bb-xM with the EtherUSB module and the built in NIC’s on the IGEPv2 and DevKit using the EtherGEP module. The IGEP and DevKit NIC performs soo much better than the bb-XM purely because of the poor USB performance in Risc OS.

I’ve been asking around about doing this for a while. But why doesnt someone write an exception handler to emulate the instructions which are problematic to the later ARMs? I know people will say ah but we just need to recompile the code, but the reality is that that isnt going to happen for a very large number of applications.

I just switched to running NetSurf from RAM, Memphis to be precise. Dramatical increase in performance and works very well.

The rumors about overheating CPU initially put me off the IGEPv2 but what state is the port currently in?

The BB-xM has its shortcomings but I’m rather happy with it. I do use it several hours a day as main machine for mail, news, surfing and listening to mp3. More and more software being ported also helps.

IGEPv2 port is stable since Jeffrey spotted he hadnt initialised some GPIO pins. All good now. I’m starting on the wireless on it shortly.

I’ve been asking around about doing this for a while. But why doesnt someone write an exception handler to emulate the instructions which are problematic to the later ARMs? I know people will say ah but we just need to recompile the code, but the reality is that that isnt going to happen for a very large number of applications.

I’ve got an unreleased module which does just that. But the problem I found was that a lot of software seems to contain code sequences which can’t be trapped by abort handlers – e.g. instructions that now result in the CPU entering thumb mode. See here for more information. Since the results I was getting were a bit hit-and-miss, and since things seemed to be going OK with authors updating their software, I decided to put the project on hold.

Of course if people want to try out the code for themselves then I can always upload a ROM image somewhere, or tidy up the code and submit it to CVS.

Ouch!

Ok so I guess its a non-starter. Its just i find that hunting down new versions of things a pain. For example i know there is a good version of sunfish but i’ve not been able to find it.

I think i’d rather that code as a module separate from the rom? if thats possible?

I think i’d rather that code as a module separate from the rom? if thats possible?

The module relies upon the kernel calling a new vector whenever a data abort occurs, so you’d need a modified kernel for the code to work. But if the kernel code was present then there’s nothing stopping people from loading/unloading the module as desired.

Shame there is no way to trap entry to Thumb mode.

I think that putting the code in the kernel is worth it eventually. Probably other prorities.

Can the arm assembler substitute these old instructions for a modern safe equiv?

I think that putting the code in the kernel is worth it eventually. Probably other prorities.

Yeah, I don’t think there’s much reason why the kernel changes can’t go in. I just need to register the vector with ROOL and make sure I haven’t broken the delicate balance between the abort handlers and the lazy task swapping code.

Can the arm assembler substitute these old instructions for a modern safe equiv?

Not really – for a lot of them it comes down to the context in which they’re being used. E.g. “MOVS pc,lr” is fine in most processor modes, but unpredictable in user mode or system mode.

I am using the internal NIC on the xM. After many hours of web browsing with Netsurf and Firefox and transfering some stuff via ShareFS I can’t report any problems. Especially Netsurf flies compared to my old SA Risc PC.

Regarding USB under RISC OS I can’t say that I am finding it slow. If using USB sticks I made the expierience that the results are heavily depending on the stick adn the used filing systems/files (small/big). 20MB/s are not really slow in my opinion if 48MB/s are the theoretical maximum and I don’t know what the sticks are theoretically providing.

The same effect is with the internal USB ethernet of the BeagleBoard xM. I obtained reading up to 5,5MByte/s (MB=1.000.000 Bytes). How much can you exspect from a 100MBit link? I don’t know? For the old 10MBit links 500KByte/s were not to bad and AFAIR around 800KByte/s the maximum. However I can’t think that this can be translated 1:1 to the 100MBit variant.

Chris Gransden reported a transmission rate of upto 9MB(it or yte)/s. 9MByte/s would be fine for a 100MB Link I think, 9MBit would be not …

Perhaps anyone can clearify what you can exspect for other machines.

It is also entirely open to me whether the clock Frequency of the BB xM has any influence on the transmission. I am operating my BB xM with the frequency set up by the ROM. So I am assuming that it is running with 600MHz. I think it can be run with 800MHz or perhaps meanwhile with 1GHz. But how? If I would know I could try to check whether this is influencing the transmission.

The only thing I am noting is that the CPU-Load at transmission is really low.

Sorry I have to correct my last sentence:

I left out the word “no” before transmission.

This means the driver doesn’t draw a measureable workload in “standby”.

If copying files the CPU is really busy.

Sorry I pressed the send button twice because I was uncertain whether it was accepted at the first attempt. For there is no possibility to delete the own mails I am replacing it.

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
DIM mac%(5)
E%=id%
CALL code%
FOR i%=0 TO 3
FOR j%=0 TO 3
mac%(i%)+=?(id%+i%*4+j%)
NEXT j%
mac%(i%)=mac%(i%) DIV 4
NEXT i%
FOR i%=0 TO 14 STEP 2
mac%(4)=mac%(4) EOR ?(id%+i%)
mac%(5)=mac%(5) EOR ?(id%+i%+1)
NEXT i%
mac%(0)=mac%(0) AND 254:REM mark as unicast
mac%(0)=mac%(0) OR 2   :REM mark as locally administered
mac$="" 
FOR i%=0 TO 5
byte$="00" 
RIGHT$(byte$)=STR$~mac%(i%)
mac$=mac$+byte$
IF i%<>5 THEN mac$=mac$+":" 
NEXT i%
OSCLI"Set EtherUSB$MAC_Configured "+mac$

I have some code in EtherGEP (which is based on EtherUSB) to generate a MAC from the machine ID. It would be trivial to add this to EtherUSB infact i think i already emailed James the code.

Its rather easy to produce what you want with this. I wanted to keep my 3 devices slightly different but you can see how this is modified pretty easily.

void generate_hwaddr(uint8_t *hwaddr)
{
    uint32_t machine1, machine2;
    _swix(OS_Hardware, _INR(8,9)| _OUTR(0,1), 0, EntryNo_HAL_MachineID, &machine1, &machine2);

    printf(“Machine id: 0x%08x%08x\n”, machine1, machine2);

    hwaddr [0] = 0xAC;
    hwaddr [1] = 0xDE;
    hwaddr [2] = 0×48;
    hwaddr [3] = 0×00;
    hwaddr [4] = 0×02;
    hwaddr [5] = (uint8_t) machine1 & 0×7F;
}

Edit: apoligies for the spaces around the brackets. This CMS seems t ignore code tags for certain things.

I would remark the following:

For the SMSC of the BB xM it is possible to modify the EEPROM with a MAC calculated in which way ever.

For EtherUSB it would be the best that the evaluation of the MAC variable would move from the SMSC driver part into the general part. It would be glad if EtherUSB could provide a Default-MAC to the drivers which they could use if they are detecting that their driver part can’t provide a proper MAC.

These default MAC should be obtained as follows: 1. By the content of the MAC variable if given which allows you to use unique MACs from old broken/unused devices 2. By a machine ID in which way ever. 3. Perhaps a fixed fallback as used by the SMSC driver in the moment.

However in calculation the MAC on an ID in theory every driver (in RISC OS in the moment EtherGEP and EtherUSB) should use the same algorithm and it must work on older and on machines not already build from diffrent manufacturers. In best case there would be no overlapping between LINUX solutions and RISC OS ones. However I don’t think that all this is possible. With the usage of the variable this could be corrected in case that MACs are used twice.

For the MAC calculation I personally would prefer Holgers solution because it makes usage of all of the available Bits.