The needle and the haystack

I downloaded the RISC OS sources recently. OK, I’ve got the haystack.

I wanted to look for the drivers for the audio chip, just in case I was able to add audio input to the BeagleBoard. Searching for anything using Textseek caused the Iyonix to malfunction. The first time it happened, I couldn’t find a way to recover other than by pushing Reset. The second time it wasn’t so bad. However, you can understand why I’m reluctant to keep trying! The uncompressed sources seem to add up to about 96 MB.

Can anyone point me at the relevant files, please? I was hoping to find some reference to I2S or IIS, perhaps.

You probably want to start here: https://www.riscosopen.org/viewer/view/castle/RiscOS/Sources/HWSupport/Sound/

I imagine it’s the HAL driver you want.

In general I find it easier to poke around CVSWeb than files on disc, particularly since CVSWeb has the changelogs too. YMMV.

Edit: Sorry, missed that you wanted sound input not sound output. I can’t seem to find that in CVS. What is the module called on the Iyonix?

Searching for anything using Textseek caused the Iyonix to malfunction. The first time it happened, I couldn’t find a way to recover other than by pushing Reset. The second time it wasn’t so bad. However, you can understand why I’m reluctant to keep trying!

Learn to use grep :)

There are probably three places in the source that you’ll want to look for BeagleBoard sound:

• The Audio.s file in the HAL, which provides the audio controller & mixer devices.
• The Sound0HAL module (aka SoundDMA) which talks to the audio controller device and (as its name suggests) is in control of the DMA transfers that fill the buffers.
• The SoundCtrl module which talks to the mixer device.

You’ll also want to get to know how the McBSP modules of the OMAP work, and how the audio section of the TPS/TWL works. There is some explanation about that in the audio file in the HAL, but it’s probably mostly incomprehensible :)

Since the Iyonix uses a completely different SoundDMA module (Sound0Trid), which used an earlier version of the audio controller device API, there’s a fair amount of room available for you to revise the audio controller API without having to worry about backwards compatability.

Sorry, missed that you wanted sound input not sound output. I can’t seem to find that in CVS. What is the module called on the Iyonix?

There isn’t a module provided with the Iyonix, but Christian Ludlam provided a module for the Iyonix called AudioIn. It was provided along with an application of the same name. Christian appears to have left the RISC OS scene. I needed to provide it for use with my VoIP application, so I’ve made it available from my web site.

If I could make a compatible module for the BeagleBoard, I could run the VoIP app on there too, which would be neat. But then that could just be another pipe dream.

Learn to use grep :)

yes… used it many times on Linux. Perhaps there’s some particular magic needed to make it do a recursive search under RISC OS?

Currently I’m issuing the command (nothing to do with this thread):

grep -i -R "OS_Hardware" $.RISCOS

Its output lines are of the form:

SCSI::HardDisc1.$.Apps.!grep.grep: $.RISCOS/Apps: No such file or directory

Curiously it can see the directories enough to enumerate them, but not to search into them.

It makes no difference whether UnixEnv$grep$nonametrans is set to 1 or ””.

The version of grep in use is the up to date one (24 Nov 2009), as successfully used to build the OMAP ROM today.

It looks like you’re using a RisckPkg’d copy of grep from riscos.info. Personally I think the RiscPkg’d command line utilties are abominations. Rather than doing the sensible thing and installing the utility in !Boot.Library, they work by using an alias. This means that even if you have a different version of the same program available on your run$path, the OS will always use the one specified by the alias – unless you do something like use ’*run grep’. In fact ’*run grep’ will never trigger the alias, which is bound to cause problems for any tools which use a ’*run grep’ equivalent under-the-hood (assuming the only copy of grep you’ve got is the abomination one).

But getting back to the topic at hand…

In my !Boot.Library I’ve got a copy of riscos.info grep from 2006 that works fine for ordinary projects. However it does perform filename translation, so will get confused by things like ‘Kernel.s.PMF.i2cutils’ (I’ve never tried messing with the UnixEnv$grep$nonametrans option, however).

But for working with the RISC OS source, I’ve always used the version of grep that comes with the build system (RiscOS.Library.Unix.grep). That version has been fully riscosified – it won’t attempt any filename translation, and thus won’t get confused by odd things like Kernel.s.PMF.i2cutils. It also means you need to use ’@’ to search the current directory instead of ’.’. Plus I’ve just spotted the nifty ’-T’ option for throwback!

If you’ve run Builder and selected the build dir & environment, then it will place the Library.Unix folder on your path (which is why I’ve always invariably ended up using ROOL’s grep when doing RISC OS stuff).

So I’d advise getting rid of your RiscPkg’d grep and using ROOL’s grep instead. If you’ve for some reason become attached to your RiscPkg’d copy of grep, you can temporarily neutralise it just by ’*unalias grep’ (And I think ’*unalias egrep’ too).

So I’d advise getting rid of your RiscPkg’d grep and using ROOL’s grep instead.

Hang on – ROOL’s (if you mean the one that comes with the RISC OS sources, that is) is the one that crashes immediately:

Internal error: undefined instruction at &000212BA

Postmortem requested
212b6 in anonymous function
  Arg2: 0x000216c8 136904 -> [0xe1a0c00d 0xe92ddbf0 0xe24cb004 0xe15d000a]
  Arg1: 0x00025df4 155124 -> [0x7261483a 0x73694464 0x242e3163 0x776f442e]
fc1319b0 in shared library function
83ec in function ___init

as pointed out in the “Problems building OMAP ROM” thread. The above postmortem was caused by directly invoking the one that’s in my ”$.RISCOS” directory of the merged RO sources and tools, and giving it the same arguments ”-i -R “OS_Hardware” $.RISCOS” that I showed 2 posts above.

Ah yes, I forgot that you’d be wanting to use it on the beagleboard :)

Using the latest riscos.info grep, it looks like the following should do the trick:

grep -i -R "OS_Hardware" /RISCOS

And if you find yourself needing to specify the drive name/number/etc, use a syntax like this:

grep -i -R "OS_Hardware" /SCSI::HardDisc1.$/RISCOS

Setting UnixEnv$grep$nonametrans will completely break grep, but it looks like the desired functionality (i.e. the ability to search through directories like Kernel.s.PMF) can be obtained by using *set UnixEnv$grep$sfix "" instead.

Many thanks again, Jeffrey. Now I have a grep that greps!