RISC OS on the Raspberry Pi

rob andrews: Well, for ethernet to work, USB needs to work first.

To complete the explanation, the Ethernet is provided by a USB-Ethernet bridge chip on the PCB because the BCM2835 SoC does not have on-chip Ethernet.

Hi Adrian,
Firstly it’s superb that you’re working on this port at all, and I agree that it would be counter-productive to let it out into the wild before the most basic I/O is possible.
I would really like to contribute to this if possible.
I have:
1) a Raspberry Pi from the very first mailout from Farnell, and a stack of UART-RS232 breakout boards, max3232CPE chips etc.
2) soldering skills and have previously hacked about with embedded ARM chips (have an active Risc OS computer made from an old Bush InternetTV STB).
3) I have an old mouse systems serial mouse that definitely works on a RiscPC. Working on getting this up and running under Debian.
4) an on-screen keyboard module from that old Bush box which with serial mouse would allow a working Risc OS system without the companion laptop.
I would really like to offer myself up as a tester of your current build – have professional software testing experience and can report back on specific use cases.

So – any way I can support your effort?

Thanks for the offer. I don’t know that there’s really any testing to be done until we have a working filing system that allows more software to be loaded and used in anger. Before we get to that point I need to do some work to update the HAL to operate with the latest VideoCore firmware (the code in CVS works with an October snapshot and things have moved on since).

You don’t need a serial mouse to control the current RISC OS port, because it doesn’t use the serial mouse protocol. Instead it responds to 3 simple commands (see the serial.cpp/exe Win32 application recently added to the repository for details) so that keyboard and mouse traffic can be interleaved over a single serial connection.

until we have a working filing system that allows more software to be loaded and used in anger

There seems to have been considerable work done recently (according to CVS) towards us being able to build the port ourselves based on your work. When you’ve been able to update the HAL as you say,¹ for determined users, won’t there be the possibility of adding applications to Resources in custom builds?

¹ I understand this is all closed source stuff – or is it worth others considering approaching Broadcom regarding NDA work on specific aspects?

You don’t need a serial mouse to control the current RISC OS port, because it doesn’t use the serial mouse protocol. Instead it responds to 3 simple commands (see the serial.cpp/exe Win32 application recently added to the repository for details) so that keyboard and mouse traffic can be interleaved over a single serial connection.

I’m working on a simple GUI to convert keyboard and mouse movements to the sending end of this protocol. It will work on an Iyonix. When the BeagleBoard serial blockdrivers work, my app will work on a BeagleBoard too.

I’ve used a serial 3button mouse/on screen keyboard ‘!DesKeys’ with my Iyonix
instead of usb devices.

How do you plan to connect the mouse/keyboard to the rs232 socket?

How do you plan to connect the mouse/keyboard to the rs232 socket?

You have to take the key down/up information from the keyboard and from the mouse buttons, and the movement information from the mouse (processed to an absolute screen position), and create serial strings from them, conforming to a (simple) custom protocol. That has to come out of the serial port of a computer, therefore you use an appropriate serial cable.

On the serial cable front, here’s what works.

USB/serial adaptors are cheap. Ben’s using this £4 one from eBay which works but apparently TX and RX are labelled the wrong way round. I’m using a Bus Pirate (a far more complex serial debugging thing with loads of other features that are useless in this application, but I had it lying around anyway). I also have another USB/serial gadget that I haven’t had time to fix up and test yet (this one was chosen because it might sit nicely on top of an RPi, and potentially power it through the same USB cable).

On the production RPi you find the GPIO header on the top left of the board. On the first batch these have been populated, so no need to solder in a header. Pinout is here . You wire GND on the USB/serial thing to 0v on the RPi, TX on the adaptor to RX on the RPi and RX on the adaptor to TX on the RPi (or TX to TX and RX to RX if Ben’s correct that the labelling is wrong). That’s it. Don’t connect the power rails.

To avoid any confusion, this USB/serial gadget simply adds an extra serial port to a PC/Mac/whatever. It doesn’t magically make USB work on the RPi. You then need to run Adrian’s Windows app (or something implementing the same protocol) to pipe in mouse and key events into the RPi using Adrian’s protocol.

If you want to use a standard RS232 port on a PC or another RISC OS box there’s nothing stopping you doing this… it’s just that USB/serial gadgets are small, cheap and easily available. There are things like this 3.3V RS232 adaptor (where you will need to connect to 3v3 on the RPi) but they end up more expensive for something that does less. Of course, there’s nothing stopping you soldering up your own if you want to, but it’s not compulsory!

A description of the key/mouse stream protocol. It sends events thus (at 115200 baud, according to the source):

• U<internal key number><cr|lf> – key up
• D<internal key number><cr|lf> – key down
• M<x>,<y><cr|lf> – mouse pointer to x,y
  There’s a table of internal key numbers in Serial.cpp if you want the mappings.

How do you plan to connect the mouse/keyboard to the rs232 socket?

It occurred to me, much later, that maybe you mean how to connect the serial socket of the Iyonix to the Raspberry Pi. That’s very easy for me. There are two ways:

1. Use a MAX3232 and associated capacitors. This gives a bidirectional interface, although we only need input to the RPi.

2. Use a transistor, two resistors and a diode. That’s enough for RS-232 input. I have the bits lying around.

Either way is much cheaper than buying a Windows box in order to use a USB serial dongle and a Windows app :-)

Either way is much cheaper than buying a Windows box in order to use a USB serial dongle and a Windows app :-)

Unless of course you have an old Windows laptop lying around (with USB and serial port).

Would it also in theory be possible to use another Raspberry Pi running Linux (via additional hardware/interfacing, again) to provide inputs to the Raspberry Pi board running RISC OS? This would more portable than either of the above, and way cooler!

(Assuming getting both boards and interested participants in the same town isn’t too far-fetched!)

[Edit: Or even via an ARMini/BB/PB running RO?]

Please forgive the possibly dumb posting as i’ve been away from ROOL for a bit. My RPi arrived last week and i’m wondering if anyone has anything resembling a RISC OS ROM for it yet? Happy to get my hands dirty helping out if needed.

Or even via an ARMini/BB/PB running RO?

When the serial blockdrivers work: yes, absolutely. My app will be written in BASIC.

Nope, not yet. However, it appears to me that we should hopefully be able to build them ourselves in the future – at which point someone may step up to host temporary build(s) off-site… even if not officially condoned by, and against the recommendations of, Adrian/ROOL/anyone else.

Perhaps we (and especially Adrian) should spend a few hours looking seriously at what the rest of us can contribute with access only to the document that Broadcom has released to the public, so that Adrian only has to do the parts that only Adrian can do. We might get the result a little quicker as a result of some careful planning.

Agreed. The moment I can build a ROM i’ll host it on my site.

In the meantime i’m going to try turning my Pi into a kick ass coprocessor for my BBC Master.

…i’m wondering if anyone has anything resembling a RISC OS ROM for it yet?

No RISC OS ROM image for R-Pi yet. AIUI a ‘coal face’ developer version may appear within the next couple of weeks BUT it will have NO USB or networking ¹ AND requires special interfacing and another computer to give keyboard & mouse input. So only of use to sharp end programmers trying to implement USB etc.
¹ So no storage, local or otherwise, and no way of loading software that isn’t in the ROM!
Until USB is implemented the ROM image would be of no use to MOST developers let alone normal users.

I may be wrong and those that can use it will probably all ready have it! But documentation for the R-Pi’s synopsys USB interface seems to now be available without NDA and strict vetting https://www.synopsys.com/dw/ipdir.php?ds=dwc_usb_2_0_hs_otg a log in is needed or an online form filled in.

I could probably rig up a NIC off the GPIO actually. Possibly hook up a Digilent “PMOD” NIC or wire it up to one of my FPGA Boards that already has a NIC.

May be a useful thing to do for future riscos development. Incidentally, is there an MMC/SD card driver for RISC OS already? if not then why not start with that? We can trivially tie a microsd or MMC to the GPIO ports.

Chris, I had a look at the USB data situation a few months ago. If you put in your details you can download a ‘datasheet’ from Synopsys, which is a 2 page thing that tells you all the features of the Synopsys core – ie the marketing literature. What’s actually interesting is the ‘databook’. I have a full Synopsys SolvNet login with SiteID as we use some Synopsys tools, and even my account has no rights to see the databook. So it looks like it’s only available to specific companies that have licensed the IP. The ‘evaluation databook’ which you can access without a login is just details of the hardware interface – how to plug in the hardware IP to the rest of your chip design.

However, I’ve had a further poke around and on SolvNet there seems to be a register description in the manual for the TLM model (ie the software simulator of the USB controller) which is here (SolvNet login probably required). That’s some progress, but it doesn’t give much top level information (eg a description of how you might use all these registers).

Wouldnt it just be easier all round if we ported the Linux driver and accepted the GPL into a particular version of RISC OS?

Wouldnt it just be easier all round if we ported the Linux driver

Isn’t that what we’re doing? Why make it difficult!

Wouldnt it just be easier all round if we ported the Linux driver and accepted the GPL into a particular version of RISC OS?

Erm, no. Reason 1: the Castle license is not compatible with the GPL so you’d violate the terms of the Castle license by doing so. Reason 2: the GPL is “infectious” so would cause every other bit of source to that ROM build to also be GPL – see Reason 1.

There’s a work-around, you put GPL modules into a podule ROM build, which is sourced entirely independently from the main ROM build. However, I’m not sure that’d work for the USB stack – ISTR that it needs to initialise very early in the ROM boot sequence.

All IMO, IANAL, etc.