RISC OS V5.22 on Pandaboard

With the new OMAP4 ROM V5,22, my Pandaboard gives the error “File ‘System:Modules.Toolbox.ColourDbox’ not found (error number &D6)” during !Boot and then doesn’t complete !Boot. It is true that there is no such file in !System nor any directory called Toolbox. So what is going on. I manually updated those files in !Boot which have a later version in the latest version of HardDisc. I can’t see any relevant difference in the latest !Boot from what I had previously for RISC OS V5.20. The latest !Boot doesn’t have a directory called Toolbox either.

Any suggestions?

System:Modules.Toolbox.ColourDbox’

The path you should be looking in is System.310.Modules.Toolbox
where you will find both ColourDbox and ColourMenu and other valid 310 modules as well.

Note it’s an 310 item so not a new introduction to your boot sequence.

“File ‘System:Modules.Toolbox.ColourDbox’ not found (error number &D6)”

Just to confirm that there is no Toolbox directory in ROOL’s !System, it is not needed as ROOL’s latest Toolbox modules are in ROM. The error will be caused by an application looking for a later version number than that in the ROM and that will be the ROL version. My Raspberry Pi running (very successfully) Colin’s PiRom_01 has ColourDbox 0.19 whereas OS4.39 has 0.28. In bygone days we just added the ROL 32bit Toolbox to !System on the Iyonix. It will be something being run by the Boot, not !Boot itself.

Hope that helps.

P.S See below, the answer above turned out to be wrong in this case.

’System:Modules.Toolbox.ColourDbox’ not found

Is it just unplugged? the extra modules in 5.22 might have left it so which I checked before doing the upgrade earlier this week on my machine (note, not an omap4 here)

Just to confirm that there is no Toolbox directory in ROOL’s !System,

That’s the problem with looking at reference systems you’ve been buggering about with :)

Indeed, ColourDBox should be in the ROM and a copy of Verma should show all loaded modules and version in a GUI (including uplugged modules), or you can do a “help colourdbox” in a task window to get the help string version number.

The question is what does the application/utility require from the higher version number that can’t be done by v0.19 ?

If it helps, the software from Really Small Software was probably the biggest user of ROL Toolbox features.

The answer is simple. Double check what is unplugged. The ROM modules got renumbered and you have simply got the required module unplugged rather than what was unplugged before (probably SDCMOS). The CMOS setting for unplugging is the module sequence number rather than its name.

Do an RMReInit ColourPicker and all will be well.

Double check what is unplugged

Yup, thus:

a copy of Verma should show all loaded modules and version in a GUI (including uplugged modules)

I had used Verma after my post to discover that ColourDBox was Dormant and ColourPicker was unplugged. Comparing with another memory card that works, other differences were that RamFS was dormant (presumably because !Boot had not completed) and SDCMOS (v0.15) was dormant while on the working card it’s unplugged and is v0.14.
Any way I have RMReInited, if RMReInit is a verb, ColourPicker and ColourDBox and it boots up as before except Panda doesn’t show the lines of text on the screen prior to going into the boot sequence. Should these lines of text appear with OS V5.22? All I see now is a cursor briefly flashing a few times.

except Panda doesn’t show the lines of text on the screen prior to going into the boot sequence. Should these lines of text appear with OS V5.22?

No. 5.22 is stable and the debug lines only appear in odd numbered OS versions.

@Chris. Thanks for that answer. I liked seeing the ‘debug’ lines, as they stayed on screen just long enough to read a few of them and they looked impressive! So perhaps I should march on to version 5.23.

The remaining question for me is why I had the error which stopped the booting. I can see from Verma output that ColourPicker changed number from 87 in OS V5.21 to 86 in V5.22, but so did some other ROM modules like BASIC from 15 to 13 and these did not become dormant or unplugged on upgrading to OS V5.22. What may be relevant is that I discovered that the CMOS file in the bootloaders partition had become corrupted, once again, by Netsurf (see my post in this subforum under Netsurf Ate My Bootloader Files). It was full of lines of text Netsurf outputs as a log file when it crashes. This time no other bootloader files were corrupted. Why doea Netsurf do this?
I should add that my Panda has the CMOS widget fitted, and so perhaps it doesn’t matter that the CMOS file got corrupted?

The remaining question for me is why I had the error which stopped the booting. I can see from Verma output that ColourPicker changed number from 87 in OS V5.21 to 86 in V5.22, but so did some other ROM modules like BASIC from 15 to 13 and these did not become dormant or unplugged on upgrading to OS V5.22.

Because presumably whatever module was previously at location 86 was unplugged with the previous ROM, whereas whatever was at location 13 was not.

What may be relevant is that I discovered that the CMOS file in the bootloaders partition had become corrupted, once again, by Netsurf (see my post in this subforum under Netsurf Ate My Bootloader Files). It was full of lines of text Netsurf outputs as a log file when it crashes. This time no other bootloader files were corrupted. Why doea Netsurf do this?

NetSurf doesn’t do this: it just writes the logfile to disc. Something else then corrupts or fails to update the disc map correctly; that’s not really NetSurf’s fault.

I should add that my Panda has the CMOS widget fitted, and so perhaps it doesn’t matter that the CMOS file got corrupted?

Correct, it doesn’t: the widget is used and the file isn’t.

Because presumably whatever module was previously at location 86 was unplugged with the previous ROM, whereas whatever was at location 13 was not.

I seem to recall some discussion about changing the method of storage of settings to something that used a text format rather than numeric/flag bit. Too much work?

Yes, SDCMOS was at 86 and was unplugged prior to upgrade of OS. However, ColourDBox was active before, but dormant after, although always at 114. Is this because ColourDBox is in some way dependant on ColourPicker? I think I had to RMReInit ColourPicker before I could RMReInit ColourDBox.