Sound on Pi

Updating to the latest (18 Sep 2012) firmware from github (start.elf, bootcode.bin and loader.bin) has caused sound to stop working. The 6 Sep firmware on being reinstated has meant sound works again. As the new firmware supports 1GHz operation (according to the Pi web site) is this just a simple tweak? It would be nice to have the faster speed.

It seems the Raspberry Pi foundation’s QA is a bit lacking if an update to the firmware can stop things working…

I thought the implication was the new firmware needed a special driver to get the speed boost.

I may be wrong but AIUI a command is included in config.txt of what speed setting you want but it is a subsequent linux driver that reads it and actually sets the hardware.
I believe the driver also monitors the SoC temperature and slows it down if it reaches 85 degrees.
How best should RISC OS implement this?
Similar low level speed setting code is the Portable module for BeagleBoard I believe.
GUI Control in Configure→ CPU settings?
Though I think it would also be nice to have an iconbar app that showed the temperature and let you adjust the speed.
There is !ThermIIC which will display the readings of I2C connected temperature sensors it would seem sensible for any iconbar CPU Temperature reporting & speed setting application to also include support for I2C connected temperature sensors e.g. the temperature sensor on our R-Pi RTC board. ThermIIC is BeagleBoard & Raspberry Pi friendly! C Sources and binaries are at:
http://www.cjemicros.f2s.com/public/thermiic/ if anyone wants use them. The author has said he wants to release them under an open license.

It seems the Raspberry Pi foundation’s QA is a bit lacking if an update to the firmware can stop things working…

Are you expecting them to test every single thing, just in case it might stop working? They probably have better things to do with their time.

Similar low level speed setting code is the Portable module for BeagleBoard I believe.

I now have a version of my CPUClock app for the BB which is now in the form of a Configure plugin, although I have not released it to the public yet (am about to head off for a week or so to what I hope is a warmer Italy).

It might be possible to combine some of these utilities in to one, with a bit of collaboration.

Is there a requirement for RISC OS to always work with the latest firmware, which is straight from a git repository?
Shouldn’t we expect a little pain if we are using ROOL development ROM for Pi and the very latest firmware?
This also would beg the question is it ROOL’s fault or the Pi foundation? And did it break the debian sound system….was the sound driver “fudged” in any way?
I don’t know or frankly care about the answer to these, but my point is questioning someone’s QA like that isn’t helpful for anyone.

Just to point one thing out, I do think ROOL et al are doing an amazing job. It’s astounding.

The RPi firmware is the responsibility of the RPi firmware developers. That’s not ROOL and I very much doubt if anyone on the RISC OS scene is involved at all. RISC OS is just along for the ride, to a large extent. We have no control over what happens on the firmware side so we’re largely playing catch-up when things change there that break functionality in RISC OS. It’d be nice to improve that situation in future but right now, I think we are where we are.

Some of us are keeping an eye on the firmware github and the linux-rpi-kernel mailing list, but generally it isn’t obvious what’s going to break until you try it.

One thing that would be useful is to take the BCMSupport module (which is currently an empty stub) and implement the messaging interface – that allows control of things like clocks for changing the speed. It’s possible to do this in a random bit of code (as there is in the HAL) but the module is a better place as it can make sure accesses don’t conflict. Then GUI tools can control that.

I’ve now checked in a fix for the sound issues, so everything should be OK with tomorrow’s ROM.