RISC OS on the Raspberry Pi

It’s worth pointing out that porting the Linux driver won’t require us to accept the GPL into the ROM build. As mentioned by Theo here, Synopsys’s driver is under a licence that’s a lot closer to BSD than GPL.

Hmm, in that case the question is for Adrian: are you already working on this or can someone else pick it up?

I don’t know about Adrian, but John Ballance has recently acquired a source code drop of the Synopsys driver as it was before the Linux folks got their hands on it and started inserting GPL code, and he’s shared it with me. Personally, I’m prioritising getting the SD driver working first, as I’ve been working on that for months now. I admit I’m not sure who is most likely be able to spend time on getting the USB stack working first, or whether we can divide the job somehow to get it done faster – there are a number of people who I believe are interested, but with varying amounts of enthusiasm and levels of availability.

Currently I have too many projects on the go to give this my full attention. I am happy to assist where i can though

From what I gather the Synopsys driver is a fairly complicated beast – it’s 40,000 lines of code. It’s also designed to target various different hardware IP, which makes it more complex than we need it. The question is: is it straightforward enough to port that the size doesn’t matter, or will the complexity be a problem? It looks like it’s designed for a multithreaded OS, which could be an issue. Apparently there’s a problem with spurious idle interrupts under Linux too.

An alternative approach is to figure out how much it looks like an EHCI/whatever device and modify a driver for that. But that depends on how much documentation is available or can be gleaned from other sources (like reading the Linux driver).

Hmm… I’ve been staring at the register descriptions. The register layout is described in the driver at dwc_otg_regs.h (not sure if that doxygen or the source is clearer. That matches the details in the TLM document, which is a little more verbose but only just.

The bit of interest is the host controller register block at 0×400 (other structures in that file describe the bits in each register). This doesn’t appear to look anything like an EHCI or OHCI register block. The purpose is roughly similar (moving frames around) but the functionality seems to be quite different. So I don’t think trying to bend an EHCI driver is going to work.

the GPL is “infectious” so would cause every other bit of source to that ROM build to also be GPL

So what? Castle can’t really still be trying to make money out of the Pi can they? If the Pi version of the ROM becomes GPL would that really be a problem? The other ROM builds, which don’t use the GPL code remain unaffected. If this is really a quicker way forward for the USB drivers then let’s do it. With or without Castle/ROOL’s help. Once a working RISC OS rom image is out there for the Pi I’m sure we can find somewhere to host it.

Chris, the problem is that once a branch of RISC OS is GPL’d, the entire code of that branch has to be GPL’d with it, so essentially RISC OS would be GPL’d lock stock and barrel. Unfortunately this isn’t possible as portions of the OS (esp network related, if memory serves, but I think there are others) are still owned by 3rd parties. Add to this that Castle must surely wish to reserve the right to charge a licence fee to those doing commercial things with Pi / RISC OS-on-Pi, and it leaves GPL as a fairly messy thing to have to deal with. I can quite understand those wishing to avoid code-contamination.

I would be happy for someone else to take up the task of porting the USB driver. I’ve made my efforts prematurely available with that in mind, since I have limited time to spend on this and am not very conversant in Linux drivers or USB. It’s probably best for me to continue on the HAL for now.

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.

Would multiple interfaces be possible?

If GPIO were faster than the USB interface*, then a combi SATA, NIC and PS2 interface (and widget?) ought to provide a working system, but still be useful when USB works.

(It would also provide networking for the cheaper model.)

• I have seen reference to the use of GPIO for SATA adaptors on some systems, but is the GPIO on a Pi, RS232 speed, or is it much faster?

Chris, the problem is that once a branch of RISC OS is GPL’d, the entire code of that branch has to be GPL’d with it, so essentially RISC OS would be GPL’d lock stock and barrel. Unfortunately this isn’t possible as portions of the OS (esp network related, if memory serves, but I think there are others) are still owned by 3rd parties.

Clearly parts of the code that are closed source have to stay closed. The GPL licence cannot over-ride pre-existing constraints. That implies God-like arrogance!

How about creating a RISCOS dir on the SD card and putting inside a copy of the RO5
rom’s & CMOS file plus a extra USB rom – that would be linked to the RO5 rom on startup.

Wouldn’t you just provide a second ROM to load up from uboot?
(I assume that is how the ‘podule ROM’ mentioned earlier, would work.)

Do from working RISC OS and you’d have no keyboard or network, until the module is loaded.

There must be a sensible way round this: if someone can recompile the Linux USB drivers under the GPL and make the code fit into a gap in the riscos rom image, then they can just be combined by the user (in a similar way to the ‘fatload cmos’ solution). Then the ROM image can be loaded, the USB driver code loaded over the top , at the right address to slot into a gap in the rom image, and then the rom started.

Of course someone may be tempted to make a download available with them both already combined but they can be told not to be so ridiculously naughty!

Since all IO is USB-based, you really need USB functionality available in the HAL so that keyboard input (etc) is possible from the get-go (think del-power on, and similar). It has been previously stated that the Linux driver is heavily multithreaded, which is problematic as far as porting to RISC OS is concerned. Whilst pthread support is present in UnixLib, it (AFAIK) relies on timers (etc) which are only available after the bulk of the OS has initialised. Thus (until I’m proven wrong – soon I hope!) “just porting the Linux driver” isn’t really a quick/trivial/easy option. Even ignoring licencing issues. Of course, that’s me throwing down the gauntlet to someone (wink)!

If GPIO were faster than the USB interface*, then a combi SATA, NIC and PS2 interface (and widget?) ought to provide a working system, but still be useful when USB works.

GPIO is too slow. There has been quite a lot of discussion on the R-Pi forum about trying to get a second Ethernet or a VGA output via GPIO but those in the know, said too slow, so that would also apply to USB.

Let me say this again the GPL is not relevant here, and is a complete red herring. The Synopsys licence says you can basically do what you want with the USB driver:

• The Software IS NOT an item of Licensed Software or Licensed Product under
• any End User Software License Agreement or Agreement for Licensed Product
• with Synopsys or any supplement thereto. You are permitted to use and
• redistribute this Software in source and binary forms, with or without
• modification, provided that redistributions of source code must retain this
• notice. You may not view, use, disclose, copy or distribute this file or
• any information contained herein except pursuant to this license grant from
• Synopsys. If you do not agree with this notice, including the disclaimer
• below, then you are not authorized to use the Software.

AFAICT it’s no problem at all for RISC OS, and no need to come up with weird and wonderful softloading bodges. The issues are not legal, they technical… how to talk to this peculiar bit of hardware which has minimal available documentation and a huge driver written for a quite different OS.

Hi Theo. I think we’re getting the original Synopsys code (and licence) mixed up with the Linux USB driver – which Ben tells me has had bits of GPL code put into it, even if it’s not already GPL. Anyway, yes – the main issue here is technical and a question of who is going to step up and claim this one.

One thought occurs to me. When the Iyonix first appeared, it was only able to support keyboard and mouse via USB. Other devices came along slowly. Are we trying to do too much at once?

The only necessary thing to support via USB is mouse and keyboard. Perhaps also the specific USB/Ethernet device on the Pi as well would be desirable. Mouse and keyboard are (relatively) slow devices. Would this be more easily feasible than trying to get the whole USB capability working in one go?

Then EITHER an SD card filing system OR the USB/Ethernet device would be sufficient for a working machine [or some gizmo attached to the GPIO header that could save and load programs on cassette tape or even using the audio out socket to save programs to some medium so that they can be put on the SD card (using another machine if necessary) to be read back in next time]. After all once a user likes RISC OS then there are other (relatively) cheap platforms if they want to do more.

or some gizmo attached to the GPIO header that could save and load programs on cassette tape

I think any GPIO device would either need to be extremely trivial to implement or still of use when the USB stack is properly working.

If SD storage becomes a reality before USB, as seems likely, an obvious candidate would be a piece of hardware that does PS2 – GPIO using the same protocol as the windows control program. This would be of potential long term use, in the scenario of a driver that doesn’t allow delete power on.

Unless you evisage a cassette device being of use to transfer old tapes for emulators, I think a SATA device would be more sensible (certainly easier to find the equipment), however I think such a drive would probably have to be formatted with very carefully chosen parameters to avoid hideous mount times, since it appears that GPIO only offers RS232 type performance.

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.

That sounds like a useful device, it would have potential to be used on RISC OS machines which can’t use a network card (Mico, current IOMD RO 5 port).

Would it be possible to make a similar device with PS2 ports too?

However am I right in thinking that such a device would be pricey, compared to the Pi itself?

Would iSCSI be a sensible protocol for storage on such a system? (Configured to appear as a local drive of a couple of hundred MB)

I think that the project of getting RISC OS on the Pi is important ONLY for the purpose of attracting new users, knowing that there is a target audience of 100,000+ of non-RISC OS users that will have one. Special add-ons are therefore not relevant unless they assist this development. USB connected mouse and keyboard is essential – that is what the users will have.

Some form of storage is almost essential – quite a bit of educational use could take place with a set package. The start up process could use RISC OS to offer different boot-up options. Games and diversions could be run if packaged with the ROM. The boot structure could live in Resources.

An existing RISC OS user will find there are better platforms such as Beagleboard XM or ARMini, not to mention pandaboard ES.

I would disagree with word ONLY in the first paragraph. Obviously that is by far the most important reason, but you are missing some points.

The Pi is cheap. Cheap enough for a RISC OS user (or even a former user) to buy to play with.

I certainly agree that the release version of RISC OS should be fully functional on a bare Pi. (It should also look as nice as possible too.)

But saying that any other device is a better platform is only true for a subset of parameters. For example a Beagle is not superior when it comes to display capability, which makes it a non starter as a replacement for my Iyonix. The Pi is cheap enough, I don’t care if it is or not. It should be significantly faster, except when the hard drive is the bottleneck.

I would think the most likely scenario is mine will end up as a media player, dual booting with RISC OS.

Jess, I don’t know why you’re so anti-BB wrt display stuff – OK, it has its limitations, but you just work with/around them. We have users running an 1920×1200 (Keith demo’d this at various shows) and most (probably 75%) are at 1920×1080. Sure, other boards can push higher refresh rates, but you’re unlikely to notice the difference in use (nearly double movie frame rates, which you don’t see people complaining about). I appreciate this comes across as BB-apologist, but there are plenty of compatible 1920×1080 screens available, and several 1920×1200 ones (they are rarer now because there aren’t many 1920×1200 screens around). If you want higher than that resolution, then none of the current crop of boards will help, as I think all are limited to 2048 horizontally.

Probably wrong thread for this, tho, so feel free to ignore this post.

Andrew, it might well be that there are many screens available that work with the BB (I have one), but the situation for many users is that they would like to use the hardware they already have. All in all, very few TVs, projectors and LCD screens work with the low refresh rates the BB manages. And there is the obvious problem of connecting the BB to an analogue VGA port – remember that very few RO users up to now needed a DVI/HDMI port. And the BB digital output does not work with the typical digital/analogue converters, because these typically need the higher refresh rates. The BB not even manages 1280×1024@60Hz which is the only sensible resolution for all those old 19" LCDs out there!

So the way forward is clearly the PandaBoard, which has no such problems and happily handles 1920×1080@60Hz, which works with nearly every display under the sun. No workarounds necessary. People can use the hardware they already have. They just have to cope with the idea that there is one completely unused processor core ;-)

Hmm… I’ve just found a DWC OTG driver for FreeBSD (files dotg*.* in /head/sys/dev/usb/controller/). It hasn’t yet been merged to FreeBSD HEAD, has been sitting about for a year or so, and says it’s missing some bits. But looks like it’s targeting the right hardware, and it appears the FreeBSD and NetBSD stacks are quite similar.

Edit: It appears FreeBSD HEAD has another DWC OTG driver (dwc_otg.*). Ah, that’s device mode only.