A9Home port?

An idle question, but would there be much interest in RISC OS 5 for A9Home? RO5 has ARM9 support, and I don’t think there’s anything really unusual about the A9Home – and after all, a version of RISC OS already runs on it. If any budding developer with one wanted to give it a go, I’m sure they’d get lots of help.

Similar question, although perhaps rather less interest, for the Omega. But since this is “nearly” a RiscPC, this is a matter of polishing the IOMD port with some extra driver stuff.

I think the big question with an A9Home port would be how long it would take for it to surpass the quality of the current OS that ROL offer for it. I.e. working sound and a reliable IDE driver. ROL’s OS has more bells and whistles, so unless RISC OS 5 is able to offer a more stable foundation (or more bells and whistles) then I doubt the port would get much support from your average A9Home owner.

An Omega port might be interesting to develop due to the obscurity of the hardware, but ultimately it wouldn’t do much to help the longevity of the OS - the machines are too rare and (I believe) don’t offer that much of a performance boost over a RiscPC.

If I was an A9Home user (which I’m not), I would be delighted to have RISC OS 5 run on it. Having an Operating System that receives regular updates would be very appealing to many A9Home users. I suspect many would like to run RISC OS 5.16.

Well, I think many of us would like the Select bells and whistles, but remember that there isn’t a RO6 port to A9 (I needn’t quote your own article at you ;-)

Comments that I have are that many people aren’t using their A9s that much, simply because the stability isn’t there, apart from the matter of any Select features (which they in any case, can get on their RiscPCs). And any general RO5 improvements in this area would be suitable for all ports.

So, a boring, but otherwise stable RO5 port to the A9Home would I think be very compelling for many owners.

I think Peter’s right – my A9 hasn’t seen much use, but a version of RO5 that ran on it would definitely help. Regardless of what developments may (or may not) be going on from the other stream of RISC OS, ROOL’s approach makes it a lot more interesting.

Stephen

I’m an a9home owner, and I’d definitely be interested in a RO5 port to the machine. I’m actually quite happy with my a9 – I haven’t suffered any of the problems that seem to have plagued others, and I find it very useable and pretty nippy. That said, I’m getting quite tired of waiting for RO6 to appear on it. It doesn’t feel like it ever will, and even if it did, the momentum of development is so slow, I don’t think it’ll be long before the features Select offer will be surpassed by the open source developments here.

I wonder if the USB1.1 limitation on the a9 is hardware-based or not… That’s the worst thing about the machine in my opinion. In fact, I think I prefer the implementation of the Castle USB stack over the Simtec one. If it could be pursuaded to run on the a9, I’d be very happy.

There was a time I’d have ditched Select just for the UCS font manager, but now that softloads happily enough on the a9 anyway, so that’s not an attraction. Nevertheless, just having a common OS on all my machines, and one that shows visible signs of moving forwards in a variety of areas would be a major selling point to me.

I’d actually be interested in working on a port myself. I’d really like to understand the OS better, so this could be an ideal opportunity. I think I’d be a bit out of my depth to start with (wouldn’t know where to start, to be honest!), but with some help I reckon I could get somewhere. Interesting idea, Peter.

My understanding is that the USB 1.1 limitation is in hardware.

IMO, an OS port doesn’t require major programming skills (unless you need to start writing lots of assembler), and could be tackled by anyone with basic C and RISC OS skills. What it does require is lots of patience, lots of working out how things are put together and reading the occasional datasheet. Also, Jeffrey has provided a substantial diary of the various steps he went through – most of which you wouldn’t need to do – but would anyway be an important guide of how to proceed.

Right now, I’m involved in two (non-ARM) Linux ports otherwise I would be considering some kind of RO port, although my interest would probably be to one of the newer platforms, like the HP device I’ve mentioned.

If you want to try a port to the A9Home then the way to start is to track down all the hardware documentation. If you manage to do that, then you’ve got a good chance of making the port a reality. In which case, feel free to bombard the forums with questions about how to port RISC OS and I’ll do my best to answer :)

I think the trouble with Omega is there isn’t enough documentation on the hardware. Much may look like a Risc PC, but things like PCI are different. And the FPGA appears not to be too stable, so you can’t be sure if crashes are your fault or the machine.

I say the following as an individual and not a representative of my employer. Errors and omissions may be present.

The S3C2440 SoC in the A9 Home supports only Full Speed USB Host (ie, 11Mbps). Theoretically, it can support the USB 2.0 protocol, but that is of no interest given the only major user-facing change was performance. It does support High Speed USB 2.0 as a device, but that is not exposed on the A9 Home. The USB hub chip used is similar; it can cope with USB 2.0 protocol, but only Full Speed.

The sound is provided by an off-the-shelf Texas Instruments part (AIC23B IIRC) that has full-duplex I2S to the CPU with I2C for control. Its data sheets are readily available.

Networking is provided by the same ASIX chip as used on the Simtec NET100. I believe its data sheets are readily available. It’s essentially an NE2000-type device, and Linux has good support for it.

The SM501 is more problematic, but Linux does have simple frame buffer support for it so something could be cribbed from that.

The SM501 is more problematic

Forgive my ignorance, but why would the SM501 be tricky to support? I thought the datasheets were available for it (think I have one somewhere). Do you just mean because it’s such a complex device?

Last time I looked, the full data sheets for the SM501 were not available publically. It’s also a very complex device with a large amount of errata.

I wouldn’t worry too much about it right now. If you can get a basic system, then I’m sure you’ll get plenty of help. To start with, focus on:

Serial port (early debugging, get a null cable to your RiscPC) Video – i.e, just frame buffer IDE - basic operation is just some registers in memory Keyboard/Mouse – i.e. PS/2 driver, bearing in mind current IOMD port confusion here.

This is minimal for a usable system, and does not require large amounts of new code.

Steve/Jeffrey, where should the focus in the code be for these items?

Steve/Jeffrey, where should the focus in the code be for these items?

• The serial port driver is in the HAL. It’ll basically be a copy & paste job of the relevant code from the Tungsten or OMAP3 HAL.
• Video can either be handled by the HAL or a module. Assuming the SM501 isn’t overly complex it’s probably easiest to start with a basic implementation in the HAL, and then write a module later if there’s a need for tighter integration with RISC OS.
• IDE - There is a degree of support for this in the HAL, but I don’t know enough about IDE controllers to say how generic it is. The ADFS module handles the RISC OS side; depending on whether it still supports PIO mode you may also need to get DMA working beforehand.
• PS/2 keyboard/mouse – No provision for it in the HAL at the moment. I’m not sure how standardised PS/2 hardware is from a programmer’s point of view, so it may just be a case of getting the HAL to expose the hardware addresses to RISC OS, or something more complex.

AFAIK the USB controller(s) that are used in the A9Home are OHCI compliant; these should be easy to get up and running since we’ve already got a suitable driver.

With regards to the order everything should be done in, this is a rough overview:

1. Work out how to get your code running. The easiest way to do this might be to modify one of the existing softload tools and use it to boot your code from within RISC OS.
2. Create an empty HAL that just spews characters out of the serial port, and get it working.
3. Get the HAL to the point where it can call OS_Start (i.e. RAM has been detected & registered with OS_AddRAM)
4. This is the tricky bit – see if you can call OS_Start and then come back out the other side at HAL_Init. You may need to teach RISC OS about the variant of ARM chip that’s in use, or how to maintain its cache. You’ll most likely need to add debugging code to the kernel for this.
5. Write code for handling the interrupt controller & timer(s), and fill in the remaining HAL entries with null entry points. This should get you to the stage the first released version of the OMAP3 HAL was at. It also means that, with a minimal ROM image, you can boot into RISC OS with the debug terminal enabled.
6. After that, you’re basically free to do whatever you want.

In the HAL folder in CVS there’s a HALTester tool which I wrote, which acts as a dummy OS and performs basic tests on a HAL implementation. You might find it useful when you write the code to handle interrupts & timers. Assuming you are actually going ahead with this, and myself and Peter aren’t just getting ahead of ourselves ;)

Last time I looked, the full data sheets for the SM501 were not available publically.

I may be wrong, but is this SM501 MMCC Databook of some use?

That looks like it’s exactly what we need. Nicely found!

For completeness then, here’s a link to the S3C2440 datasheet that I found yesterday

Assuming you are actually going ahead with this, and myself and Peter aren’t just getting ahead of ourselves ;)

Well, maybe a bit! Thanks for your brief summary of how things would need to proceed. I’m getting more and more interested in having a go at this, but I don’t want to get ahead of myself. I don’t even have my a9 set up at the moment. It would also be my only RISC OS machine, so I’d be using it for compiling code as well as testing, which isn’t ideal.

But for now I think I’m just going to do a lot of reading about the chipset and about RISC OS and the HAL in general. I’ve just been reading the wiki pages on the HAL - nice job, by the way.

And I need to get set up with compiling the sources. I haven’t even done that yet, though I do have the Norcroft C suite. I need to check what version it is, but I think I got it after the inception of ROOL, so it should be a reasonably up-to-date one.

Assuming we get the IOMD build working, you could have an RPCemu RISC OS machine, too…

Assuming we get the IOMD build working, you could have an RPCemu RISC OS machine, too…

If I could use that to build the sources, it would be extremely useful!

You don’t need to wait for the IOMD build, you can build on RPCEmu using a ROL RISC OS 4 ROM.

I’m talking about a way of doing it without spending any money, but your way would be quicker.

You don’t need to wait for the IOMD build, you can build on RPCEmu using a ROL RISC OS 4 ROM.

Thanks, Theo. Is it better to use the Spoon edition, or the regular one?

In general I’d recommend Spoon. I’ve only tried the regular one for building RISC OS, but I can’t think why Spoon wouldn’t work

Having a completely free ROM is something we definitely need, in the medium term anyway.

I’ve been asked what the precise list of problems with RISC OS on the A9 is. And with the Omega also, although I understand that only some Omega owners have problems.

I’ve been asked what the precise list of problems with RISC OS on the A9 is. And with the Omega also, although I understand that only some Omega owners have problems.

Do you mean hardware problems, or software incompatibilities, or both? Who’s asking, by the way ;-)