USB Podules and 5.2

Hi

Do USB podules work with 5.2?

(I have the Simtec Podule)

Thanks

5.2 is so long ago that nobody remembers it.

These aren’t decimal numbers, you know. I take it you mean 5.20?

5.2 is so long ago that nobody remembers it.

:-)

Funny. Given that we in RISC OS land don’t tend to use the [epoch.]major.minor.revision[.dev] format, but instead go with x.yy, I parsed 5.2 as 5.20 because the other would need an explicit zero beforehand, ie 5.02.
I rather suspect if we passed “5.2” to RISC OS itself (say, as a version number of a module), it would be interpreted in the same way.

As for the original question – I may be wrong, but I don’t think it is supported yet.
To be honest, an IOMD (RiscPC) build of RISC OS 5 is a big leap – there are all sorts of devices, podules, and such which could be present for which drivers don’t exist for. To look at my own RiscPC: a Simtec dual-IDE podule, a Morley SCSI card, a Vision digitiser (single field), plus the network card. And the 486. Updates for these devices is unlikely to come from anybody except enthusiasts fixing their own. I mean, it isn’t ROOL’s problem to get my IDE card working, right?
RISC OS 5 has, in recent times, been targetted at SoCs (and to a lesser degree, the Iyonix) where the range of potential hardware is limited. Sure, you can plug anything in to a USB socket, but all RISC OS really needs to know is how to talk USB (and have modules to support the generic common devices – mouse, keyboard, flash storage…). There are no surprises on an SoC. You won’t wake up one morning and find there’s a SCSI board attached (except via USB…).
The RiscPC, on the other hand, is highly modular and user-configurable. How much memory? How much VRAM? Any expansion cards? What, and where? Not only can my machine be very different in setup to yours, but one or other of us could flip the lid catches and rearrange everything. It’s really a different proposition to an SoC!

However – it is here, it is real, it is official. My personal prediction is that, having gone as far as making ROMs to fit into a RiscPC, and at a perfectly reasonable price too, we will surely see things progressing in this respect. As many modern devices are USB, I wouldn’t be surprised if this didn’t get seen to fairly soon – though it’ll probably work the Castle-stack way, not the Simtec-stack way…

Short answer: no
Medium answer: not yet
Long answer: it depends

There’s three USB podules: one Castle and two Simtec (Unipod and standalone USB podule).

Castle’s podule uses its own stack, which predates the NetBSD stack in RISC OS 5. That stack is not 32 bit, and hasn’t been released under the ROOL license. You could always try asking, but Castle’s original stack is fairly limited anyway. I don’t know what chip it uses.

Simtec USB uses a Philips ISP1161 chip. Simtec’s stack also isn’t 32 bit. There’s PHCIDriver in the RISC OS source tree which dates from NC days and is entirely useless for current purposes. I think one of the Acorn clones may also use the same chip (did RiscStation or Mico ship with USB hardware, or was it Omega? Can’t remember).

Probably the most useful thing would be to write a driver for the ISP1161 for the RISC OS 5 stack, and then it would work on Simtec hardware, and you’d get better device support along the way (no more OtherDevs!). If anyone is interested in developing a driver then I can put you in touch with people who might be able to help.

what about the A9 what must have been 32bit and it had USB.

I ordered it anyway. I have A Kinetic and a normal strong arm RPC. I think I will move the hard drive, adjust and the USB card from the Kinetic, and install a 16 GB SSD I have plus RO 5.

To drive the Simtec USB Podule – with RO5 stack on the RPC – is it the replacement of the OHCIDriver whats required?

What we ideally need is a unified USB “driver” (high level) which talks to the low-level driver (the part that talks to the chip) which can be different for each USB device.

Like this:

           .----.
           |Apps|
           '----'
             |
             |
          .-----.
          |"USB"|
          '-----'
         /  /\   \
      /    /  \    \
   /      /    \     \
.---.  .---.  .----.  .---.
|RPC|  |Iyo|  |OMAP|  |RPi|
'---'  '---'  '----'  '---'

My observations with the differing behaviour of the USB at API level between the Beagle xM and the Pi lead me to believe the stack is more different than this – please correct me if this is erroneous.

Then, once the higher level part of the stack is unified, supporting other hardware should (in theory) be a matter of writing something to talk to the hardware. But, you know, theory != practice! ;-)

This seems a bit similar – to the posts about:-
‘Getting the Panda to Sing’ – by Jim :-|

What we ideally need is a unified USB “driver” (high level) which talks to the low-level driver (the part that talks to the chip) which can be different for each USB device.

Thats what we have don’t we.

           .----. +----------------------------------------------+
           |Apps| | device driver class modules like scsisoftusb |
           '----' +----------------------------------------------+
             |     |
        +-----------+
        | Device FS |
        +-----------+
             |
          .-----------.
          |"USBDriver"|
          '-----------'
         /  /\   \
      /    /  \    \
   /      /    \     \
.---.  .---.  .----.  .---.
|RPC|  |Iyo|  |OMAP|  |RPi| <- these are USB Controller driver modules
'---'  '---'  '----'  '---'

To drive the Simtec USB Podule – with RO5 stack on the RPC – is it the replacement of the OHCIDriver whats required?

Roughly, yes. I think in the diagram above you have OHCIDriver+EHCIDriver (Iyo, OMAP), MUSBDriver (OMAP OTG support) , DWCDriver (RPi) and [not-written-yet] for RPC. *HCIDriver are part of the NetUSB code, but MUSB and DWC aren’t.

The other angle is that, on a work project I’m involved with, we need to write a driver for the ISP1761 (similar but USB 2) for FreeBSD (which will be open-sourced). These aren’t OHCI or EHCI but instead use Philips Transfer Descriptors (PTDs) to send packets to the chip. We think we’ve managed to find enough documentation to understand them, because there only seems to be a Linux driver as example code and nothing else.

What I don’t know is how much the FreeBSD and NetBSD USB systems match up, or much about the RISC OS modifications to the NetBSD stack.