Multicoloured window borders

I have been trying to create an SD card for a Raspberry-Pi B and run into lots of problems. First I got the rainbow coloured square and no further. Then it got to the Raspberry-Pi splash screen and next said that the disc drive was empty, which it wasn’t. Finally, I have got it to the desktop without error messages, but all the windows have multicoloured borders and the text in the title bars is hard to read. I remember this problem being mentioned before, but have forgotten the solution. Does anyone know?

Also, I notice that on some of my Raspberry-Pi SD cards I have a CMOS file in Boot.Choices and on others in with the loader files in the DOSDisc image file and on my Pandaboard it is in both! Where should it be?

How did you try to create that SD card? You need to take care that

• the RISC OS version works with the !Boot used
• the RISC OS version works with the RPi firmware
• your config.txt has sensible entries

The following entry in config.txt helps with the “all colours are wrong” problem:

framebuffer_swap=0

The “rainbow coloured square” suggests that your power supply is not good enough. You might run into all kind of strange problems if that is the case, including a broken SD card, non-detected SD card, non-working networking, erratic mouse behaviour…

The “rainbow coloured square” suggests that your power supply is not good enough.

And/or the cable is not good enough – too high resistance, because its conductors are too thin or it’s too long.

I have 2 Raspberry-Pis model B and they both now get to the desktop as they both do with ROOL’s RICSCOSpi SD card I bought from ROOL of October 2012 vintage. Although they both have the same 5 bootloader files (including CONFIG/TXT and, of course, the RISCOS ROM)), RISCOSpi doesn’t give the multicoloured window bars.

Adding the line “framebuffer_swap=0” to the CONFIG/TXT file doesn’t make any difference.

I created the card from a blank card formatted to FileCore E+ using SystemDisc. SystemDisc says it is a valid system or some such words. For the ‘HardDisc’ files, I used those from the standard HardDisc BCM2835/5/24 of 15/04/18 intending to upgrade the OS to V5.24.

Both cards have RISCOS v5.19 of 31/10/12. I think with this version configuration changes were stored in the RISC OS ROM. I notice that using the configuration application to set up a RAM disc doesn’t work.

I have got rid of the multicoloured borders, but only by updating the OS to RC15, and so I still don’t know what caused the colourful borders.

A remaining problem is that enabling a RAM disc using the configure application doesn’t work. Doing a SAVE CMOS from the Configure window seems to update the CMOS file in Choices in that its date stamp updates to the current time, but not the CMOS file in the Bootloader partition. In any case, no RAM disc icon appears after a re-boot. Also, after setting the time, it reverts to 2nd January 1970 after a re-boot. :-(

As I asked before, in which of these two places should the CMOS file reside? And why doesn’t the configuration work?

The CMOS file should be in Loader. If you’ve updated from an old image then you might not have the required lines in CONFIG/TXT:

ramfsfile=CMOS
ramfsaddr=0x508000

The copy in Choices is effectively a backup that you can save/load through Configure, but the one in Loader is the “real” one.

It should be in the DOS partition,!Boot.Loader.CMOS

Choices is a red herring, figuratively!

Follow what Chris wrote!

The “multicoloured window borders” might be the result of the Wimp tool sprites that the Pi desktop theme uses. The Wimp had to be modified to allow them to work properly – this happened in mid 2013. But I guess the boot sequence wasn’t taught about that requirement, so a modern boot sequence on a 2012 Pi ROM would be loading tool sprites which the Wimp can’t render properly.

A remaining problem is that enabling a RAM disc using the configure application doesn’t work.

Add the following two lines to config.txt, then reboot.

ramfsfile=CMOS
ramfsaddr=0x508000

That should cause the firmware to load the CMOS file from the Loader partition. The SDCMOS module will take care of updating the CMOS file as and when needed. The CMOS file in !Boot.Choices is redundant and can be deleted (the CMOS load/save options in Configure interact with that file – I think it’s intended to act as an easy way for users to back up their CMOS settings for machines where physical CMOS/NVRAM chips are used)

Also, after setting the time, it reverts to 2nd January 1970 after a re-boot. :-(

If everything is setup up correctly, the SDCMOS module should timestamp the CMOS file when the Wimp is shut down (and it should pick up that timestamp on next reboot). If you’re still having trouble after making the config.txt changes listed above, double-check that the SDCMOS module is actually loaded – it might have refused to start for some reason (e.g. CMOS file might be the wrong filetype).

Of course, SDCMOS alone won’t be enough to stop the clock from being wrong, so make sure you enable network time in Configure as well.

I think what this thread highlights is that we don’t have very good documentation for setting up a Pi. Some notes on the wiki or in the ROM download readme about what config.txt settings are required, what files should be in the boot partition, where to download firmware from, what minimum firmware version is required, etc. would be a big help for anyone who isn’t using one of the pre-prepared SD card images as a base.

Jeffrey, thanks for your help on this problem. The two lines that you and others mention were already in the CONFIG.TXT file.
I notice from the Verma application that module SDCMOS is dormant, but so is it in my PandaBoard SD card, but I don’t use the configuration application much. In fact the PandaBoard CMOS file in the bootloader ‘partition’ has date stamp 21/01/13!
I think that not every setting in the configuration tool is stored in the bootloader CMOS file.

As regards filetype, I found that every file in the bootloader partition was typed text including the ROM. I thought the filetypes given to the bootloader files was irrelevant. Anyway, I have now given them types based on what I usually see in another Raspberry-Pi. So the CMOS file now has type Config.
If its relevant, *unplug says that no modules are unplugged.

I very much agree with your last paragraph.

I notice from the Verma application that module SDCMOS is dormant

A quick check on my Pi shows that the SDCMOS Module is dormant if a CMOS file, filetyped as Config (ff2), is not found in the FAT partition.

If the CMOS file is present in the FAT partition and correctly filetyped then SDCMOS should be active. It is here.

A quick check on my Pi shows that the SDCMOS Module is dormant if a CMOS file, filetyped as Config (ff2), is not found in the FAT partition

Which, as I recall, was the consensus of how things should be to ensure that people always had some method of storing settings and that the method would cascade through with a sequence of:
hardware – if available otherwise fall through
file – if available otherwise fall through
write back to rom image (which was regarded by many as a novel means of corrupting the image file)