PCI for the masses - RISC OS News, Software and Information

PCI for the masses

Published: 14th Jul 2003, 18:00:08GMT Source: drobe.co.uk
By Peter Naulls

Page 1 of 1

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:

On board

1Gbit network controller
AC97 (Sound)
IDE interface
Power management
Southbridge
XScale IOP321

PCI card

Graphics card
USB card

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.

Electrical Specification

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.

Software

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.

Software Interfaces

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. *PCIDevices and *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.

Omega PCI

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.

Rounding Off

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.

Update

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.

Links
PCI SIG
PCI Specification 2.3
RISC OS 5 PCI Manager
Iyonix PCI Slots

This article has been linked to, or is available in the following formats:

[Printable] [Digg this] [Blog search]

epistaxsis_RISC OS 14/7/03 7:15PM	drivers please indeed. pretty please can we have a 64bit SCSI card and a firewire one? just asking
fwibbler 14/7/03 8:38PM	Isn't the podule interface on the Iyonix much faster than that of the RiscPC? If so, wouldn't it be better to simply update the drivers for an existing SCSI podule? Cheers!
knutson 14/7/03 9:16PM	The opposite is also true. If a PCI card driver is developed for the Omega, it may not work on the Iyonix. I think I commented sometime last year that the basing the RISC OS PCI interface on Linux code was a smart move. It will certainly make it easier to develop drivers. Simon's work is proof of that. Will it make the boat go faster? I think the answer is yes. Cheers Steve
mrchocky 14/7/03 9:20PM	The podule interface is twice as fast, and lacks DMA. Yes, updating drivers is a good idea, but a PCI card can go a lot faster. *In reply to knutson:* You missed an important part of what I wrote. The number of people who might be able to write PCI drivers for the Omega could potentially be very small. So yes, what you say could be true, but not very significant. -- Peter, drobe.co.uk
fwibbler 14/7/03 11:06PM	Ah. Fair enough. My point was simply that Iyonix users could quickly run out of PCI slots thus they should be reserved for hardware that really needs their speed. All depends on what you want to do with the machine I guess. Cheers!
knutson 15/7/03 6:06AM	Nothing a few dollars and some documentation wouldn't fix. -- Cheers Insignificant Steve
dansguardian 15/7/03 11:12AM	I don't know what all this FUD about not making money from GPL software is. I make a decent wage from mine (all legal and taxed I might add) on top of my day job wages. Also you could have the driver ported and hense stay GPL but the seperate front end code as proprietry closed-source and charge for the whole package. You would have to make available the source for the driver bit but not the front end. Even then you can still charge for the act of downloading from your own site. GPL != free beer GPL == freedom
thegman 15/7/03 11:41AM	Lots of companies make money off GPL'd software, and charging for a 'pretty' version is quite a good model, as if you're only charging for the front end, you'd have to do a really good job or people would not bother with it. OTOH, if you give something away and charge for support then your incentive to make software extremely easy to use and reliable is a bit watered down as who wants a support contract for something that never fails? The exception for this is massive companies who just want support for peace of mind.
mrchocky 15/7/03 11:53AM	*In reply to dans:* _excuse_ me. You're accusing me of FUD, but don't say where. Kindly withdraw your accusation and careful reread what I really wrote. I never said you can't make money from GPL. I never said you couldn't do anything you've named. If you want examples of GPLed stuff making money (albeit not very much), look at my Unix Porting Project, but please get off your GPL high horse. -- Peter, drobe.co.uk
nijinsky 15/7/03 12:52PM	MrChocky. I read dans... posting and thought the FUD was a general comment or directed to knutson's comment on dollars being thrown at it. Have I misse dsomethng or is this a carry over from another article/newsgroup etc?????? cheers bob
mrchocky 15/7/03 1:07PM	*In reply to bob:* you aren't making much sense. GPL is only previously mentioned in my article, and Dan's comment is clearly directed at it. Your confusion perhaps comes because Dan's comments don't really have very much bearing on what I said in the article. -- Peter, drobe.co.uk
dansguardian 15/7/03 2:01PM	*In reply to mrchocky:* nijinsky is right it was a general comment. I tend to find that most people think that one can't charge for GPL software or make money from it. It was not directed directly at the comments in the article (very good and interesting btw thanks). I am aware of your unix project having been a subscriber twice of the browser version. Unfortunately this has now lapsed due to unexpected personal expenses not due to the quality of the work.
not_ginger_matt 15/7/03 2:18PM	*In reply to Peter:* To be fair to Dan, I read his comment as a general one, reflecting the general "GPL means no-one gets paid" opinion that floats about. As an author, I'm sure that you're very protective of your work, and having someone question it's integrity is one of the most insulting that can happen. I'm also sure that very few people who read Drobe actually realise how much time and effort it takes to write the articles that they read, and if they did then they would make sure that any comments they made were very carefully worded so that they couldn't be incorrectly interpretted. Unfortunarely for the author, the lack of this perfect situation brings the effort back to their door as all comments must be taken with at least a pinch of salt. Everyone has their bad days, author and reader alike, but the unfair side of it is that an author can end up undermining his or her work simply by their perceived attitude, whereas the reader can simply walk away. -- Richard Wilson Publications Manager, Tradelink Publications Ltd.
mrchocky 15/7/03 2:21PM	If it was meant to be a general comment, then I apologise - but it was far from clear that it was the case, since mine was the only GPL reference, and perhaps you should have made your case elsewhere. If you want to do an article on GPL and RISC OS then of course we'd be happy to publish it. Peter -- Peter, drobe.co.uk
JGZimmerle 15/7/03 5:44PM	Hi Peter! It may be true that most of the people that you know are capable of producing drivers for PCI cards have an Iyonix and they might not buy an Omega in addition to it. But you can't assume that you know all the people who are capable of producing drivers. So your hint that there might be a shortage of authors for Omega-PCI drivers is spreading FUD. *In reply to Steve:* I am of the opinion that it was not such a smart move to use the Linux PCI code as a base for the ROS PCI layer. I think the FreeBSD code would have been a much better choice. -- Julian G. F. Zimmerle
nunfetishist 15/7/03 6:00PM	Or even NetBSD, 'cause it was designed to be portable from the start. Although there are many more books on the subject of hacking the Linux kernel than there are for any of the BSDs...
knutson 15/7/03 9:33PM	Just a small clarification: By money I wasn't referring to GPL'd code. It is also possible to write drivers from scratch. Of course to do this you need to beable to feed yourself too, hence the money bit. Any company could employee someone to write drivers for devices if the demand exists. This is as true for USB as it is for PCI. Julians point is good. From what I understand BSD code can be modified without having to release the modified source. Of course either option is smarter than developing a new API that requires development of drivers from scratch. -- Steve Knutson
guestx 16/7/03 2:27PM	Yes, the BSD licence is "permissive" and allows commercial ventures to use the code with minimal obligation or reciprocation on their part. However, the fact that Linux has had a lot more attention with respect to drivers, and the fact that Castle found it more appropriate to work from the GPL'd Linux sources, would seem to suggest that developers don't necessarily care about (or aren't particularly motivated to cater for) companies that take but don't give in return. So, yes, OpenBSD/NetBSD/FreeBSD might have been interesting from a licence perspective, but then how interesting were they from a technical perspective? Can the level of support from BSD drivers compare to Linux implementations? However, I still wonder to this day how Castle got away with the licensing issues (and dubious "BIOS" arguments*) around the PCI layer, but I certainly have no sympathy for proprietary software companies and their concerns about competing with open source technologies whilst continuing to deliver closed source products.
JGZimmerle 16/7/03 3:03PM	There are other ways for companies to "give in return" than to release source. Some of the BSD projects need money more than anything else, so a company could simply contribute that way, without giving key parts of their products away for free. -- Julian G. F. Zimmerle*
Martyn Fox 16/7/03 7:18PM	The list in the article of all the on-board PCI devices highlights a fundamental difference in approach between Castle and Microdigital. David Atkins at Wakefield gave an interesting talk about the trials and tribulations of dealing with chip manufacturers during the process of developing new dedicated hardware to work with RISC OS in his "Spectrum" of machines, including the Omega. Castle have taken a load of industry-standard devices - see PCI list above - and made RISC OS work with them. Which is the better approach? Discuss. Martyn
mavhc 16/7/03 9:13PM	Which approach has produced a working machine that one can buy? If there's soft/hardware that does what you want you'd be daft to design it again. Depends what you're trying to achieve, an xscale RISC OS machine to sell or a supercool set of technologies to base your products on, some of which are RISC OS machines.
JGZimmerle 17/7/03 8:28PM	Exactly, the Iyonix, made of standard components, was the quickest route to market, while the Omega is a much more flexible design, wich took a lot more time to develop. So you can choose: Get an Iyonix now, if you want a fast (but slightly incompatible) machine now, wich will never be faster than it currently is. Get an Omega within a few days or weeks (depending on your position in the queue) if you want a very flexible machine wich has the potential to get faster and additional hardware-features over time. -- Julian G. F. Zimmerle
hubersn 18/7/03 11:50AM	Hi Julian, Another viewpoint would be that you can choose between getting an Iyonix now if you want fast, proven hardware with a future-proof OS built by the owner of the OS copyright, together with a nice software bundle containing a capable browser. Or you can choose if you wait a few weeks/months/years to get an Omega which will be a lot slower, a lot more expensive, comes with an either laughable or "not ready yet" software bundle, promises more performance partly for even more money (XScale or other 32bit only processors in conjunction with a not-working-yet magic solution to run 26bit software on it) or if you just wait long enough (JPEG/MPEG acceleration, FPU, 2D/3D acceleration), relies on a dubious and potentially performance-killing UMA architecture with comparatively slow RAM, needs an immediate and costly OS upgrade to get vital features like DHCP, only guarantees an incredibly scarce screen resolution, and basically relies on a "it's not ready yet, but it will be great once it is finished" promise for most of its features. Flexibility on its own is no good for the customer. Steffen
NeilWB 18/7/03 11:55AM	*In reply to JGZimmerle:* I find your cursory evaluation of the Iyonix and Omega rather amusing. How is the Omega a much more flexible design than the Iyonix? What makes you say that the Iyonix will never get any faster? A cynic would probably say get an Omega in a few weeks, or years, depending upon how much credence you place in anything Microdigital says. Just an off the wall qustion for the group here: If the Microdigital 'soft' computer concept were really superior to conventional hardware, would it not be used by mainstream (i.e. PC) manufacturers? Rgds. Neil
mavhc 18/7/03 7:58PM	Not cheap enough for them. The real potential for the Omega would be to program the FPGA on the fly for specific tasks.
JGZimmerle 20/7/03 9:11AM	Hi Steffen, I know you don't believe anything from MD. However, machines are being delivered now. You make a lot of assumptions in your posting, wich might not all be correct. Basically it sounds like spreading FUD to me. -- Julian G. F. Zimmerle
JGZimmerle 20/7/03 9:21AM	Hi Neil, the Omega is much more flexible because the function of its most important chips can be changed at run-time and because it has a high-bandwidth expansion bus for additional CPUs/FPAs. The Iyonix does not have any potential for hardware performance enhancements of the machines wich are already with the users (short of a mainboard-exchange). It might get minor speed-ups through optimisation of the software. -- Julian G. F. Zimmerle
Martyn Fox 20/7/03 1:22PM	"What makes you say that the Iyonix will never get any faster?" Those blobs of solder which fix the processor to the mother-board, perhaps. Castle claim that mounting the processor on the motherboard was necessary for reasons of reliability. They say that track lengths have to be matched within very tight tolerances and that a socket would introduce impedance problems. If MD intend to supply an XScale as an upgrade, it will presumably have to be on a daughter board. It will be interesting to see who is right. I imagine that speed upgrades on the Iyonix would have to be through motherboard replacement. This would, of course, allow other enhancements to be made at the same time. Martyn
mavhc 20/7/03 3:45PM	If Omegas are in the hands of customers how come noone's talking about their production Omega? Where are the reviews? Comments? Praise? Problems?
AMS 20/7/03 7:28PM	*In reply to mavhc:* Well MD say they're shipping so I'd imagine 10's if not hundreds of people have them by now (unless MD's definition of "shipping"* means something different !). In reply to Julian:* And how will programmable logic allow you to turn a 32bit/33MHz PCI slot into a 64bit/66MHz one ? It doesn't - so there are limits to Omega expandability too (and I'd point out that the Iyonix already has* 64bit/66MHz PCI). As to xScale, that is an future option* for Omega, whereas Iyonix users have it today. There is also the little matter of the xScale being 32bit only and RISC OS 4 being strictly 26 bit - so what sort of performance hit will "ArmTwister" make in resolving that (if and when it finally arrives). I suggest Martyn's point stands, when you change a motherboard you get not only a new CPU, but also faster I/O devices, faster memory and so on - the sort of things the FPGA's in Omega will do nothing about..... -- Annraoi McShane,
Use the forum for more comments on this article