ShareFS on BeagleBoard

I played with ShareFS on the BeagleBoard yesterday. It works more than I expected:

The client seems to work, in that BB can see the other shares on the network, and I can Filer_OpenDir to them; slow servers (my two A3010s with floppy discs) seem fine, but the Iyonix causes BB to go through multiple timeouts. I haven’t tried the Risc PC yet; maybe tonight;

The server falls over immediately I try to share HardDisc0, with rapidly flashing error windows.

This is using either of two USB Ethernet dongles based on AX88772 chips, and the EtherUSB 0.07 module.

Is ShareFS still closed source?

Is ShareFS still closed source?

It looks like it, yes. The precompiled version in CVS looks like it was taken from an Iyonix build (see here), so probably needs recompiling for ARMv7 if it’s throwing up loads of errors.

I don’t think I’ve ever tried sharing a drive from the beagleboard before – I’m fairly certain that the ‘share’ option has always been greyed out for me. Maybe it’s just where I’m using a card reader (which could be classed as a removable drive) instead of an ordinary USB stick (which could be classed as ‘fixed’, even though it’s obviously still removable).

I’d assume that the timeouts are down to ShareFS doing something silly – I don’t think there are any major performance/reliability issues with EtherUSB. Unfortunately I can’t really speak from experience with regards to beagleboard networking issues since I spend 99% of my time at the command line!

The share option was greyed out – I was at the command line too :-)

Hmm, closed source… how do I petition someone@rool to recompile it with appropriate flags?

Thinking about it further, it wouldn’t surprise me if ShareFS was 100% assembler, which means it might not need recompiling/fixing for ARMv7 at all. I’ll have a play around with it tonight and see if I can find out what the error message is – it might be something we can fix ourselves without adding any extra work to ROOL’s plate. They’ve all been rather busy with non-ROOL stuff recently, so there’s no point pestering them until we know exactly what’s going on!

Connecting a RISC PC to a Iyonix using ShareFS gives a lot of timeouts if the RISC PC has a 100 Mbit ethernet card. Try opening a folder with <ctrl> pressed, this way !Boot files are not executed and !sprite files are not loaded when applications are shown on the filer.

Hope this helps, Peter

Jeffrey: you’re right, of course. Here’s some proper information.

*share SCSI::HardDisc0.$ results in rapidly repeatng error boxes saying “Internal error: abort on data transfer at &FC319E08”, where *modules shows the base of ShareFS to be at &FC30FBB4. *help sharefs says ShareFS is 3.52 (01 Jul 2004) Access+, which I believe is in ROM and is the same version my Iyonix (RO 5.16) shows.

Yeah, it’s definitely an ARMv7 thing. Also it looks like the module is written in C, so it shouldn’t be too much hassle for them to recompile it for the next ROM build. I’ll drop them an email – it’s probably the most reliable way of making sure they’re aware of the issue before they next do the next autobuild :)

Connecting a RISC PC to a Iyonix using ShareFS gives a lot of timeouts if the RISC PC has a 100 Mbit ethernet card.

Mine has, but the BB seemed happy to look at its hard drive. Seemed pretty quick, too.

Try opening a folder with <ctrl> pressed, this way !Boot files are not executed and !sprite files are not loaded when applications are shown on the filer.

Not easy to do on the root directory when you have to open it from the command line, though!

Two observations that may be linked:

- I can’t configure the network interface as ej0 isn’t listed, even though it’s up and running;

- there is no ShareFS icon at the left of the icon bar.

Can anyone please enlighten me as to how network devices are discovered by the configuration system?

Can anyone please enlighten me as to what ShareFS needs to see in order for a ShareFS drives icon to appear on the icon bar?

Can anyone please enlighten me as to how network devices are discovered by the configuration system?

You need to create an ‘autosense’ file for it. Make sure EtherUSB is in System:Modules.Network, and then stick the following in an obeyfile in !InetSetup.Autosense:

set InetSetup$Driver$USB EtherUSB:ej0:EtherUSB:0.07:EtherUSB

Note that once you’ve saved the network settings you’ll need to make sure the network adaptor is always connected at boot if you want to avoid the boot sequence failing halfway through. An unfortunate side-effect of the way both EtherUSB and the network configuration currently work :(

Can anyone please enlighten me as to what ShareFS needs to see in order for a ShareFS drives icon to appear on the icon bar?

Enable Access in the network setup configure plugin (should be one of the options in the window with just the three big icons, I think!)

Magic, Jeffrey, thank you again! The ej0 interface now comes up automatically on boot.

Access is (and was) enabled in the network configuration, but there’s still no ShareFS drives icon on the icon bar. I can open directories on the shares by running a Filer_OpenDir command from either the command prompt or an Obey file, so ShareFS is clearly running. If I open Resources:$.Discs, the shares are all there. *ShareFSIcon silently does nothing.

Hi, something that can stop access shares from appearing is if you have drives with same names on the two machines. The common cause being HardDisc4. I guess the same thing could happen if both machines had a SCSI::HardDisc0? Just mentioning it in case. :-)

Ronald: thanks for your thoughts; it isn’t the case with my setup.

There’s more that’s wrong: although the shares are shown in Resources:$.Discs, double-clicking on any of them fails open a filer window.

These may simply be further symptoms of the non-Cortex-aware build of ShareFS that Jeffrey observed earlier. I think it’s time I stopped reporting malfunctions of ShareFS until it’s recompiled for a future ROM build.

I discovered a neat trick.

I have NAS consisting of an NSLU2 and 320 GB USB disc, accessible via LanMan98. LanMan98 crashes immediately on the BeagleBoard on trying to open the NAS. However, I can connect to the NAS using LanMan98 on my Iyonix, and then re-export it via ShareFS! The BB can see it!

I had imagined that re-exporting a network drive would be disallowed; fortunately it isn’t.

And another thing… although I can’t open the Iyonix’s root via ShareFS from the BeagleBoard without getting lots of garishly-coloured hourglasses, I can open another directory that has less stuff in it with no problem. Boof, it’s there. (I have a directory called UseForCopy, that does what it says on the, er, directory’s title.)

Best of all is to set ShareFSWindow 1 on the Iyonix, then the BB seems to be happy with all of the Iyonix’s shares.

My random contribution for the day: Acorn Access basics ! Maybe some of the software could be of interest. If not, then please ignore.