A9Home port?

I was asked on IRC by a user, but mainly I am asking, so there is a definite list of problems. I’m after anything which wouldn’t be construed as disingenuous – e.g specific problems with the older versions of Select features they have. Rather I’m after driver, usability or general stability issues.

And yes, perhaps also software issues, but only where a RO5 might obviously address those.

As far as I’m aware the main problems with the current version of RISC OS on the A9 are the lack of sound, the fact that CMOS RAM settings get reset on each boot, and whatever bug(s) exist in the filesystem that can result in hard disc corruption (mostly seen when using Messenger Pro, I believe). Assuming that un-workaround-able hardware issues aren’t the cause of the above issues, I’d hope that they’re all things that a port of RISC OS 5 would be able to address.

The problem with sound is one way only. Audio out works and having no fan noise, the A9 makes a good MP3 player.

The audio-in has not been enabled for RISC OS although the hardware capability is supposed to be there.

Ah, that’s good to hear; I was under the impression that neither worked.

It’s worth pointing out that at the moment there’s no real support for sound recording in RISC OS 5 either. There is/was a program for the Iyonix for sound recording, but AFAIK that didn’t use any RISC OS API (because there isn’t one), and instead just talked to the hardware directly. So if/when we want to add sound input to an A9Home port we’d have to come up with a sensible API first.

If we wanted to access the NAND flash then we’d need an API for that as well (along with a fair amount of new code). This is something I’m hoping to get sorted out for the OMAP port at some point, but I haven’t yet investigated the most sensible way of doing it (i.e. write everything from scratch or port some/all of it from *BSD)

Audio in was provided by Christian Ludlam’s !AudioIn.

He defined a DeviceFS interface to access autio input devices an a module ‘AudioIn’ which provides such a DeviceFS driver for the Iyonix. I expect that the application is just a front end to that module.

!AudioIn.Spec describes this DeviceFS interface.

That should make life easier, then :)

It looks like the spec might need expanding in a couple of ways (e.g. there’s no way to indicate that the input sample rate is fixed to the same value as the output rate, as per the TWL/TPS used with the OMAP), but otherwise I can’t see any immediate reason why it can’t be used as a basis for an ‘official’ API.

That’s going to be interesting when both sides want to use different rates simultaneously.

As an aside, I think DeviceFS works quite well for things like this as it is usable at a higher level via standard file calls or you can access the buffers directly via the BufferManager service routine in lower level code.

Don’t think anyone here’s mentioned the PS/2 problems on the a9home. Often the keyboard or mouse wouldn’t be recognised when plugged in. A suggested fix (which worked for me at times) was to switch the keyboard and mouse over! I ended up using a USB->PS/2 converter and circumventing the problem entirely!

It would be interesting to try to get PS/2 working from RO5 on the a9home to see if the same problems persist (suggesting a hardware problem) or if it’s a low level RO4 problem.

Quoting Jeffrey a while back in this thread…

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.

I’ve been looking at the ROM image format used in Select 5i1 with the above in mind. It’s a compressed format, seemingly LZC (i.e. Unix compress), as the RPCEmu page on how to obtain ROM images suggests.

But it has a 20 byte header on the front. It looks like a Squash file at first glance:

53 51 53 48  SQSH
00 00 60 00
50 E5 FF FF
DC 61 F7 06
F4 6F AA FE

But according to the RO3 PRMs, a Squash file should look like this:

typedef struct
{
        char id[4];          /* Should be "SQSH" */
        unsigned int length;
        unsigned int load;
        unsigned int exec;
        int reserved;        /* Should be zero */
}
squash_header;

That ‘should be zero’ would suggest the image format isn’t actually a Squash file, as it’s non-zero in my example. Does anyone know anything about what information the header contains or where it’s documented? I’m guessing there’s some checksum information in there, but a CRC of the uncompressed ROM doesn’t match…

All I could find about Select’s Softload was a changelog. It doesn’t give much away about the format, but it does talk about a ‘raw softload option’, so perhaps uncompressed, un-headered images could work also? If no one here can shed any light, I’ll have to do some experiments!

Those load & exec addresses look funny too (they’re not word aligned, for a start!). My guess is that the load, exec & reserved entries are either random garbage or some kind of checksum. You could always try changing their values and see what happens when you try softloading the ROM.

If you can’t work out a way of using the ROL softloader then you could try looking at the ROOL softload tool, which could probably work on an A9 with only minor tweaks (if any). However I don’t think the source code for it has been released yet, so if you need to modify it or want to add debugging code you may have to pester ROOL a bit.

I don’t know about the ‘reserved’ field, which doesn’t look like zero to me, but W.P. appears to have quoted the header by byte, rather than by word, hence causing some confusion (as the ARM is a little-endian processor).

Looking at it another way, the fourth to seventh bytes give the 32-bit value &00600000 (the file length), which is exactly 6MB. The third and fourth words are clearly filetype and datestamp, as all 12 upper bits of the load address are set. This would therefore seem to be a ROM image file (type &FE5), stamped 17:49:54, 01 December 2008.

Can’t answer for the ‘reserved’ field, though!

However I don’t think the source code for it has been released yet

It has – you can find it here castle/RiscOS/Utilities/Debugging/SoftLoad and via our CVS viewer here

Thanks, Steve. That’s interesting. The docs about how it works are especially interesting! The syntax is almost identical to the ROL version, so I’m sure the two versions have come from a common source.

For anyone interested, I did some more poking around in Select ROM images. I found that Select ROMs of the ’-na’ variety (without CDFSSoftATAPI in ROM, I believe) have exactly the same header as their non ’-na’ counterparts. The contents of the ROMs are definitely different (I did a binary compare), so that basically means the header can’t contain checksum information. (It would be a pretty rubbish checksum otherwise!)

So I’m not sure what’s in the header. Perhaps date stamp information and version codes?

Anyway, I found that the ‘RO6Preview3’ ROM image is exactly 6MiB in size, which means it’s not compressed. Sure enough, the first four bytes aren’t ‘SQSH’. So it looks like I could just use a straight uncompressed image with the Softload tool anyway, and I can forget all this guesswork about the file header! I’m not sure if the same Softload tool works on the a9, but I think there’s a good chance it will.

Now I need to get my build environment set up and see if I can create a dummy HAL!

The third and fourth words are clearly filetype and datestamp, as all 12 upper bits of the load address are set

Ah, there was me being naive and thinking the ROM loader would have used them as the literal load & execute addresses for the image.

With regards to using the ROOL softloader, you’ll have to check if the cache/TLB maintenance ops that startnew.s does are correct for the A9. You might also want to check if the find_kernelvals() function (in softload.c) does the right thing (i.e. whether OS_ReadSysInfo 6 has changed significantly for Select 32 – unlikely, but possible) You may also want to disable FIQs, just in case they’re used for something on the A9 (the current code looks like it just disables IRQs via XOS_IntOff). Otherwise, it looks like the code should work OK, and enter your (4MB) uncompressed ROM image at its first word, with the MMU, caches & interrputs disabled.

W.P. appears to have quoted the header by byte, rather than by word, hence causing some confusion

Didn’t spot your post until just now, Martin. Many thanks for pointing out the obvious. It was right there in the Squash file format description in the PRMs, but I just assumed this must be something different because the ‘reserved word’ was non-zero. And apologies for my endian faux pas – I just wanted the ‘SQSH’ to look nice on screen! ;-)

I guess the reserved word mystery will remain unsolved for now!

Jeffrey, thanks a lot for the pointers above. It’s made me realise I really ought to look more closely at how softload works so I’m going to study that a bit more before moving on to anything else. I might poke some questions your way in the process if you don’t mind!

Incidentally, you could try booting your RISC OS 5 port to the A9 Home from the A9’s boot loader, which is Simtec’s ABLE. The version shipped is quite old, but I seem to recall it can netboot images (over TFTP), or fetch them from a JFFS2-formatted NAND partition (which is how the A9 boots RISC OS 4).

Thanks, Rob, for the info. It seems like, assuming the Softload tool will work, that’s probably the easiest short-term solution, but using ABLE would be an interesting experiment, too. To use a netboot, would you hook up the a9’s network port directly to a PC using a crossover cable and run a TFTP server on the PC? Is that how these things generally work? Sorry for my ignorance!

Usually there are two parts to network booting (netbooting): setting up the network and transferring the boot image.

Typically the machine will receive network settings via DHCP or BOOTP. There’s an option in the dump of settings the BOOTP/DHCP server sends to indicate where to grab a boot image from with TFTP. The TFTP server doesn’t have to be the same machine.

So you’d need a TFTP server on another machine. You can probably get away without a DHCP/BOOTP server, if you don’t mind manually configuring things each time. You just need some kind of network connected. It doesn’t have to be a crossover cable – DHCP+TFTP is often used for booting discless clients on institutional LANs.

The ABLE docs are here: http://www.simtec.co.uk/products/SWABLE/files/able-set/index.html A brief poke suggests it’s expecting images that correspond to Linux kernels of various sorts… I can’t see that it’ll accept a plain lump of ARM code to jump to. But the Linux zImage format might not be too much work, see: http://www.simtec.co.uk/products/SWLINUX/files/booting_article.html

Not immediately relevant, but for future reference when someone searches for it.

u-boot is by far the most prevalent boot loader out there on Linux systems, but there’s others, and they all do much the same thing, as described above. The special case is certain WinCE devices (which RISC OS might eventually be ported to), which use eboot and the NK.bin format (both Microsoft specials). These are poorly documented, and involves instead running a TFTP client (since eboot implements a server).

After a lot of pain, I actually have some working code for this for Linux work I’m presently doing, although part of it right now does involve running a Windows binary under wine. Anyway, when such a future eventuality occurs, get in touch.

Thanks Theo and Peter for the additional info. I’ll look into ABLE at some point for sure!

There is a good chance the IMOD version could be made to run on the Omega although currently it doesn’t probably due to the problems with StrongARM support on RO5 IMOD. Most other things that support the StrongARM do run on the Omega including most versions of Select although it struggles with RO6 due to RO6 not making any allowances for the Omega. The only thing that springs to mind that might cause a problem is the Omega pretends when analized to be a ARM7500FE with a StrongARM core. This was due to Microdigital being unable to find detailed enough documents on the RiscPC IMOD and VIDC chips.

As far as I have been able to tell it does support half word instructions completely.

The two main problems the Omega has:

The Flash ROM’s are very temperature sensitive this caused a lot of problems with flashing. Use of an ice pack was often necessary. Also can cause problems with startup I had to stick a fan above mine to get it to boot reliably although they don’t get perceptibly hot!

The Omega has it’s own IRQ support for the PCI interface to get round the inadequate support in RO4. This seams to cause instability problems especially with the sound card this may be helped with the more advanced support in RO5.

There is also a couple of unofficial fiddles I have found one is the PCI interface reads data directly from a fixed location in the OS the other is the address of the sound buffer is hard wired into the SoundDMA module.

On the plus side: The 5 special modules the Omega needs are installed by the Podule interface and not included in the RO ROMimage.

The special Modules are:

MicrodigitalUtils This provides the additional IRQ support a set of default MDF’s power management and also contains a fair bit of code relating to ARMTwister

PCIDriver This provides the PCI interface. The Omega uses the same PCI interface chip as the Iyonix so the Iyonix driver it may also work with it. see http://www.iank.org.uk/omega for full details.

SoundDMA Sound driver for PCI card based on CMi8738 doesn’t seem to interface with any of Microdigitals custom hardware

IDEFS IDEFS interface seams to be based on the Blitz Podule Driver

IDEFSFiler IDEFS interface seams to be based on the Blitz Podule Driver

CDFSSoftATAPI_MD Not sure if this is based on something else or not.

Regards Ian K

Regardless of what developments may (or may not) be going on from the other stream of RISC OS

getting quite tired of waiting for RO6 to appear on it

"As we have always said – buy it for what it is now if it suits you, not for what it might do in the future. So my response is for information only and not a promise or similar. That said: It is being worked on when we can, but there is more work to do. The majority of the improvements in OS6 above 4.39 are either already present in the A9 or have been been tested on it. The rest should work in principle. We will make it available when it is done. I hope this partially answers your questions." (Feb 2011)¹

¹ JohnB on Mon 10 Oct 2011 – 19:41

Was there ever any attempt to port RO 5 to the A5Home

Was there ever any attempt to port RO 5 to the A5Home

Typo of A9Home maybe? As can be seen up thread here, there’s no technical barriers to doing one, there’s an extremely elementary HAL for the SoC already in ROOL’s repository but that’s not had any real work done on it since 2011 – the commits after that date are “check it still assembles” type maintenance, and what little is in there doesn’t look like it’d work to my eye. For example the IIC code returns IOMD’s base address so probably wouldn’t get far.

So all you need is

• A sample machine
• Get IIC working
• Possible ARM9 kernel memory management fixups (it’s supported, but not been used in anger since the Bush Internet TV2 so may have minor bit rot)
• Write yourself a framebuffer video driver
• Figure out how the USB controller works
• Audio out
• Write yourself an Ethernet driver

All the rest of the OS (modules not touching the hardware, like the Wimp) will just drop in since they’re clearly already 32 bit OK, which is a hurdle ROL had to jump at the same time when they made a start on porting RISC OS 4.