PCI for the massesBy Peter Naulls. Published: 14th Jul 2003, 18:00:08 | Permalink | Printable
Got Expansion? [Update 9:10 15/07/2003]With the availability of the Iyonix, PCI is usable on RISC OS systems. It's therefore worth discussing the implications of this, and what it enables us to do.
What's the deal?
PCI, or Peripheral Component Interconnect is simply a bus specification for connecting various devices together. Many of the chipsets you can purchase interface to PCI, as do many of the internal expansion devices you can buy for PCs (as opposed to external ones, which tend to be USB).
PCI isn't just for expansion, either. The majority of the onboard devices in the Iyonix are PCI too. Let's have a look at the PCI devices in the Iyonix:
- 1Gbit network controller
- AC97 (Sound)
- IDE interface
- Power management
- XScale IOP321
In fact, there are a couple more of onboard ones, but we won't confuse the situation as they don't have too much bearing on this discussion. Perhaps a surprise entry in this list is the XScale processor itself. Apart from the processor core, which is the ARM part of the processor, this particular XScale also contains a PCI controller, which is the device which runs the whole PCI show in the Iyonix, and is responsible for allowing configuration of the devices.
The Southbridge is the device which is largely responsible for allowing the machine to talk to the outside world. As well as providing several PCI devices itself (IDE and AC97 in particular), it also contains a number of other devices (e.g. serial port, interrupt controller, floppy drive), which although not PCI themselves, are configured in the Southbridge via PCI mechanisms.
As with many of these types of specification, PCI has both a hardware and software aspect to it. Most of the hardware aspects are rather complex, and won't be of interest unless you're constructing a new PCI card. There is, however, one important point that needs to be noted for Iyonix, the signal keying.
PCI cards come in 3 types - 5V, which is the older specification. Next is 3.3V which is newer and is intended for embedded, laptop and other low power devices. Finally, there's universal, which supports both. The Iyonix only supports (and will only physically take) 3.3V or universally keyed PCI cards. You can tell the difference from the slots on the cards. A slot on the card on the connector nearest the back panel indicates it is 3.3V keyed. A slot on other end indicates 5V, and I'll leave you to guess what having both slots means.
The problem is, that many of the PCI cards available are 5V only, so you need to be careful if you go down to your local PC dealer. Chances are the salesperson doesn't even know PCI keying is, so you'll have to check yourself. In addition, some 5V PCI cards can be modified (with your hole maker of choice) to 3.3V by cutting an additional slot, if the card is able to cope. The USB card in the Iyonix is an example of this.
The Iyonix, of course, has 4 PCI Slots of which 2 are used by cards shipped with the machine.
Of course, to make all these devices work, you'll need drivers. Naturally, RISC OS 5 already contains drivers for all the devices used by RISC OS on the Iyonix, but if you want to put another card in, you'll have to obtain a RISC OS driver for it. Simon Wilson's done this in the case of a TV card, where he's made a driver based upon the Linux "bttv" driver.
Castle have made their PCI API available on their website, and this should be your first stop if you're looking at porting or writing your own driver. The API is very similar to that found in Linux - indeed, this was the root cause of the RISC OS 5 GPL debacle. In any case, this at least makes porting Linux drivers a little easier.
Note however, that just because the RISC OS 5 and Linux PCI APIs are similar doesn't mean that porting Linux drivers is trivial - drivers invariably rely on many OS-specific intefaces, of which PCI is but one, and there will be plenty of leg work still to do.
And of course, if you base a driver on Linux sources, then it'll be GPLed, which somewhat limits your chances of trying to profit financially from making a driver available. Existing BSD drivers may be a better, but possibly harder, route if you're aiming to do this. But the fact that open source drivers exist at all for a given card means that it's much more likely you can also create a RISC OS driver.
To the best of my knowledge, there isn't yet any C interface on RISC OS to the SWIs on Castle's site. However, DeskLib will soon have an interface, as will, I expect, OSLib.
RISC OS 5 does give you two commands which you can use to examine the PCI devices in your Iyonix.
*PCIInfo <n>. I'll let you figure out what they do.
This isn't meant to be a PCI programming tutorial, but I was asked about this privately, so it's worth covering briefly. As is implied by Castle's API, PCI access occurs in various ways. The first is via configuration registers, which identify the device and do various other high level things. Many drivers won't have to touch these. Depending on the card, there will be various regions such as memory, IO and ROM. Memory regions are typically for things like graphics card frame buffers and audio codecs, although some cards have registers there that you might otherwise expect to see in an IO region. ROM regions tend to contain x86 code, and probably aren't interesting on RISC OS. These regions can be mapped into logical memory, so your driver can access them directly.
Information on this is currently pretty thin on the ground. The Omega certainly has a PCI interface of some description, and it even has the same Southbrige chip with the various devices on it. The problem is that most of the people who are likely to write or port drivers to RISC OS have an Iyonix, rather than holding out for an Omega. This means unless Iyonix drivers can be ported easily, or the Omega has the same PCI interface, then Omega owners might be left wanting. We'll have to see how this plays out.
In the interests of brevity, I've left out quite a number of things - PCI-X, AGP, bus mastering, etc. I will say only that they exist, and the interested reader should start with the PCI specification linked below.
Let's see those drivers.
Reader Sprow points out that the Iyonix conforms to the PCI 2.2 specification (see below), and probably also to the 2.3 specification. The important point about the latter is that it rules out the 5V only cards, and conformance to this is required by Jnauary next year. This is good news for Iyonix owners, as it means that new PCI cards are much more likely to be suitable.
PCI Specification 2.3
RISC OS 5 PCI Manager
Iyonix PCI Slots
Previous: Alpha, Omega in the wild
Next: New alternative OS section opens
DiscussionViewing threaded comments | View comments unthreaded, listed by date | Skip to the end
Please login before posting a comment. Use the form on the right to do so or create a free account.
Search the archives
Today's featured article
South East 2008 show photos
If a picture tells a thousand words, here's a short story
8 comments, latest by hzn on 22/10/08 10:03AM. Published: 20 Oct 2008
Using an A3010 as a central heating controller
Should have used an Intel processor to heat the water, snicker
17 comments, latest by MartinA on 21/10/05 4:02PM. Published: 17 Oct 2005
News and media:
RISCOS Ltd •
RISC OS Open •
MW Software •
Advantage Six •
CJE Micros •
Liquid Silicon •
Chris Why's Acorn/RISC OS collection •
The Register •
The Inquirer •
Apple Insider •
BBC News •
Sky News •
Google News •