Beagle - potential Cortex A8 target.

looking at porting RISC OS to a Netwinder??

Well it’d be interesting but unfortunately I’m lacking the first prerequisite: “you have a strong knowledge of C and ARM assembler” :-(

I can’t see RISC OS really getting much use on the Netwinder (and I gather there aren’t many of them around anyway). However, perhaps the IOMD port would be a starting point for someone.

Regarding Nettle, I’ve a work in progress addition to enable it to talk via DeviceFS. I use this with the second serial port on the Iyonix for the Beagle’s debug terminal. http://effarig.co.uk/riscos/download/nettle.zip. Please direct any problems to me rather than the nettle developers.

• USB kb+mouse update: WORKED initially after 12secs of kb input not being directed to prompt, repeated this once, then doesn’t work after >60sec. Linux USB check OK immediately before and after. Summary: worked from relatively cold start and a short wait.
• Terminal connection for U-Boot: I don’t have a USB A -> mini B so tried RS232 with Connector (v. 0.83ß 10Jun96 so I ought to update). I must have it wrongly configured as all I get is gobbledegook, i.e

  !B!øúh)zjHÿ X<img <5> />ÿ#A <img <6> />!þ+roA¬+iþÉÏX!þkùJXùY `akCPÉ)AbIC iZÉA)þXi@Oº)ÉkkBHaÏXaÎFk`iÛa+✘ZX#Ûùk)¨ÏX#c…++þ

• EDIT – U-Boot upgrade: The EBV quick start guide suggests the upgrade of U-Boot with option 115200, 8, n, 1 no flow control, giving the instructions below. I’ll check the existing U-Boot version before I try this upgrade.

mmc init
fatload mmc 0:1 0x80300000 u-boot.bin
nandecc sw
nand erase 80000 160000
nand write 0x80300000 80000 160000
nand erase 260000 20000
reset

(Connector settings I used for Terminal are local chat=11, remote chat=12, text buffer=72 lines… which don’t talk about baud or anything so I’ll check the helpfile when I get a moment. I also get similar using Serial Port settings Block driver=InternalPC, Flow control=hardware, Port=0, Input buffer=16384, Output buffer=4096.) I’ll also try Nettle too.

James Peacock wrote:

Regarding Nettle, I’ve a work in progress addition to enable it to talk via DeviceFS.

James: Alex Macfarlane Smith is currently working on Nettle too. I think it’s important that you two talk to each other!

(Connector settings for Terminal are local chat=11, remote chat=12, text buffer=72 lines… which don’t talk about baud or anything so I’ll check the helpfile when I get a moment. I also get similar using Serial Port settings Block driver=InternalPC, Flow control=hardware, Port=0, Input buffer=16384, Output buffer=4096.)

I’ve just tried Connector (v1.03) again on my Iyonix, and have managed to get it working fine (although it’s running through Aemulor since I haven’t been able to track down the 32bit version that supposedly exists).

The important bit is the serial settings in the choices window. Make sure flow control is set to “no flow control”, and you’ve got the right driver selected (InternalPC should be correct for a RiscPC, for the Iyonix I’m using Internal32 port 1 since I initially had some difficulty getting port 0 working)

Then when you open the terminal window, click on the various options on the bar at the bottom and change them to:

ANSI 115200 8N1 Ascii (Char delay 0, line delay 0, LF translation none)

There was some garbage when I was first changing it to those settings, but after a while it cleared up. I haven’t found a way of passing Escape through yet, which could be a bit of a problem (from Special → FKeys or Special → SmartButtons it looks like you might be able to set up a key to generate the right character code – I’ll have to have a play with it later)

If we can find a working download link for 1.03 (or newer) then it would probably be good to add this info to the wiki.

Although I’ve just found out that the backspace/delete don’t work properly within RISC OS - it will delete the characters on the remote machine, but Connector doesn’t know how to handle the character code that gets sent back across the link and just prints a triangle. Enabling the local line editor might be a suitable workaround, although it might cause problems/confusion with prompts that wait for certain keys to be pressed.

Thanks for the pointers again, Jeffrey. I really need to RTFM but was pushed for time and decided to post what little I’d found out anyway. I hope you won’t waste your time getting bogged down with this any more as I can surely get it running properly now.

James: Alex Macfarlane Smith is currently working on Nettle too. I think it’s important that you two talk to each other!

We have.

WORKED initially after 12secs

I’ll be more patient after just reading “it could be anywhere up to around 10 seconds before RISC OS even knows you’ve connected a new USB device” in the Pandora port thread. Perhaps I could also try unplugging and replugging the kb.

U-Boot: 2009.11-rc1

Full output without MMC:

(More to follow if needed)

I also reflashed the NAND (if that’s the correct terminology) with the new U-Boot according to the instructions. It’s the same version.

But I omitted to describe the detail of my setup: I’d been using the USB OTG port. RISC OS works fine via the USB host port rather than the OTG port :-)

Why was the EBV connected up this way? It was supplied with a mini-AB cable for the included 4-port powered hub. When my additional 7-port powered hub arrived (with a mini-B->type-A cable) I saw no reason to change it. Hmmm… I seem to be getting stupidly mixed up over my minis as I stated above I didn’t have such a cable!

Apologies for posting what’s probably a very basic problem.

Sorry again and thanks for the help. Please file under User incompetence error.

Investigation summary:

• Linux
  • works with the powered hub via the OTG port
  • also works via the USB host port
  • accepts hot switching of above cables, with the hub and attachments continuing to function via either connection

• RISC OS
  • only occasionally works with the powered hub via the OTG port (was from a relatively cold start)
  • works via the USB host port
  • still doesn’t work via the OTG port if booting via USB host and then hot switching (although switching back to USB host returns functionality – perhaps a little slower than Linux)

Is there anything else it’d be useful for me to check? And if someone else has a mini-AB cable, it might be helpful to verify that the above indeed applies to the official BB too. Anyway, I guess the answer lies somewhere in MUSBDriver . Thanks.

Ah, that’s not so bad if it’s just MUSBDriver causing you problems. As you can see from the wiki page there are quite a few known issues/TODO items, so it’s not too surprising to me that it doesn’t always work right (e.g. the code that detects the OTG cable is a bit dodgy).

Unless owners of rev B. boards (where the OTG port was the only one available) start reporting serious issues it will probably be another few months until I do any further work on the MUSBDriver. So if I were you I wouldn’t worry too much about doing any further investigation of the problem.

OK - thanks. When I’ve got the SD card formatted for ADFS I’ll have a nose around and also get back onto the VDU 23 documentation .

Regarding Nettle – I’ve put a beta version up at http://nettle.sourceforge.net/ which should run OK on the Beagleboard (although it doesn’t yet includes James’ changes mentioned earlier). If people fancy giving it a try and reporting any problems (probably either by email to me or to the nettle-users@ list)

Can Nettle do RS232 terminal connections?

Additionally, unless I can format ADFS under linux (or Windows!) I’ll either have to buy a Unipod or enlist the help of a friendly Iyonix owner (or owner of RiscPC with Unipod, I suppose).

No need! Formatting as FAT32 using this HP USB Disk Storage Format Tool (referred to within BeagleboardRevCValidationv3 ) is read by RISC OS. N.B. Under Vista the HP tool needs to be Run as administrator.

From other zipfiles I was able to copy UnTarBZ2 and HardDisc4, as documented under How to get started… and Using the Cortex-A8 port . Unpacking HardDisc4 gives SCSIForm (in Utilities.USB-Mass). Thanks so much to ROOL, Jeffrey and everyone for all the hard work going into the Cortex-A8 port!