Ticket #192 (Fixed)Mon Nov 03 23:57:40 UTC 2008

I agree this would be hugely helpful. Not least as, at present, it’s utterly unclear as to which branch of the repository contains the most relevant sources (or even the sources from which the tarball has been built). For example, ISTR that the Tungsten HAL is on trunk but the applicable kernel is on the HAL branch. Additionally, the way in which the public repository groups modules by licence makes it a pain to check out related components (e.g. the Internet module and EtherK). Thus, having the CVS metadata in the tarball would be a huge help. </2p>

There is a part of the repository called Products. This contains Products files which are simply a list of cvs components and their respective tags. A given products file can be used to check out all of the sources you require for a given build.

At the moment, we use a script called ‘checkout’ which does the job of checking out all of the sources in a given product file. I’m not sure if this has been released somewhere on our site but it probably should be. Either way, it’s not hard to convert a given products file into a set of “cvs co -r” commands.

So, if there is a particular thing (product) which you feel would be usefully collated into a products file, send a copy of the file to us and we’ll see that it gets added.
Right now, the Tungsten products file is a good reference and will tell you all of the components you require for an IYONIX ROM build, along with their tag (which in turn indicates the branch).

As for putting CVS control files into the tarballs, I’ll look into doing this.

Ok, that’s cool. I don’t think the Products files were available when this bug was opened.

That’s great. I don’t suppose you might have any other Products files lying around you might provide? I’m thinking particularly of those for Risc PC or ARM7500 hardware. It doesn’t matter if they’re a bit crusty, but gives a starting point.

Sorry, only just noticed the request.

Just before Christmas, I did a build for an A7000 I had lying around, and put the relevant files in CVS: Products/IOMDHALDev, castle/RiscOS/BuildSys/Components/ROOL/IOMD32 and castle/RiscOS/Env/ROOL/IOMD32. It’s not ready for end-users yet, but if you fancy doing some work on it, then be my guest. Probably worth coordinating efforts though.

The build isn’t as complete as it could be; the IOMD HAL was never originally polished off to production standard, and the memory map changes came along later, meaning that several modules haven’t been adapted to it.

Issues I’m aware of with it are:

• The HAL doesn’t include the DRAM and VRAM size detection code from old kernels; this needs patching in. Similarly with Video DMA timing depending upon whether VRAM is fitted or not.
• SWI OS_Reset (and so Ctrl-Break) doesn’t work.
• Hardware scrolling doesn’t work.
• CMOS gets reset on every boot.
• HAL contains no RAM controller initialisation (though not required for softload or emulation).
• The following modules need to be taught to read the address of IOMD at run-time: Portable, Parallel, SoundDMA.
• Serial needs to fall back to the IOMD code if there is no PCI bus, and needs to read IOMD’s address.
• ADFS and DMAManager – these could have a build-time switch added to force them back to pre-HAL variants (which would need variable IOMD address support), but it might be better to write proper IOMD HAL back-ends for them. Their HAL interfaces hadn’t been defined when the IOMD HAL was developed.
• The startup banner still says “Iyonix PC”. :-)

Looks as if we can close this now; anyone else agree/disagree?