Configure Plug-ins

Using the ‘Disc’ configure plug in with the latest 11 Oct ROM gives an abort. There was a fix for this but it seems not to have worked fully? Or perhaps (0128 11th Oct) it wasn’t in time for the 11Oct auto build?

Looks like the autobuilder is repeatedly failing on the disc build due to Build:InstRes playing up. That’ll probably explain why the configure plugin fix isn’t in the latest image, although I’m not sure why new archives are still being uploaded each day if the builds are failing. And I’m not sure how tweaking the Configure build flags would be influencing the plugins in the first place! (Disc builds I’ve done locally have always ran fine on all the machines I’ve tried them on. Maybe the makefile change was just a red herring and the real culprit is memory corruption from Build:InstRes?)

I’m looking into this on the autobuilder.

I’m not sure how tweaking the Configure build flags would be influencing the plugins in the first place

Indeed. Ben, Rob and I were sat in a room until very-late-o’clock, scratching our heads at the behaviour. There’s something very odd about it but it was 100% repeatable in that only certain plug-ins were affected by certain combinations of build flags for Configure. We had DDT out and were trying to trace the cause but in the end all we managed to do was characterise which !Configure.!RunImage binaries (build flags) caused which behaviour – and when it was clear the non-debug was the only one that appeared stable, we stopped there. It’ll all need investigating more later but right now we’ve got more pressing matters…

Bad News. I have built a non-debug ROM (adding the ‘-options FREEZE_DEV_REL=TRUE’ in file ‘BCM2835Dev.BuildSys.Components.ROOL.BCM2835’ in the line starting ‘Kernel -at 0xFC010000’) and the ‘Disc’ configure plug-in still gives an abort.

First off, you should be building the BCM2835 product and not BCM2835Dev if you want the ‘official’ version. Secondly, the fix is in the Disc (not DiscDev) build, not the ROM build.

In the ‘Software/SourceCodeArchives’ there is only the ‘BCM2835Dev’ source code archive not the ‘BCM2835’. The Disc build is (presumably) the HardDisc4 archive in the ‘Software/essentials’ HardDisc4(self extracting). Or have I musunderstood something?

Also using an earlier rom, the plug-ins do not produce errors. Now very puzzled.

Using the latest disc image the ‘Discs’ plug in bug appears with the 12 Oct rom image but is not present with the 1Oct rom image. However the ‘Sound’ plug in (undefined instruction at CC24) misbehaves with the 1Oct rom image where it worked with the 12 Oct rom.

As it is an interaction between disc image and rom image, could it be that something is not word-aligned? Perhaps related to Perl?

Or have I musunderstood something?

Yes, I’m talking about getting sources out of CVS. We’re not about to start producing source code archives for our own internal release candidates, we have enough trouble from people knowing how to build things that aren’t ready yet from CVS…! :)

As it is an interaction between disc image and rom image, could it be that something is not word-aligned?

The elephant in the room is all the firmware. This may be unrelated but people should be aware that different people (us vs you) are probably running different versions of the Raspberry Pi firmware so that needs to be considered when characterising faults.

Anyway, we’re looking into it.

Ah! I now see that the bug was present with 18 Sep firmware and the 22 Sep disc and rom image, just on different plug ins. It has been there some time therefore but unnoticed.

Seems to be solved with the latest firmware (15 Oct 2012 12:15) from github [which includes start.elf versions for the new 512Mbyte Raspberry Pi) and the 15 Oct RISC OS ROM image with the 11 Oct HardDisc4 image).

Just updating the ROM image should be all that’s needed; it was a ROM problem rather than anything firmware related.