RC14 problems

I bought a micro-SD card from ROOL with RC14 preloaded on it. The first time I used it on my RPi2 everything booted up fine. So I edited Loader.CONFIG/TXT to put in the line overscan_disable=1 and then restarted. This time I got the message

Machine startup has not completed successfully: 'File '&.!BOOT' not found'.

At the moment I am using RO 5.21 (07-Feb-15). I would like to take advantage of the improvements in RC14, but either I am doing something wrong or there is some glitch in it. Has anybody had similar problems?

My suggestion is that either the SD card is a bit duff or your power supply is insufficient. Do you get a multi-coloured square in the top right of the display? If so your power supply is not powerful enough.

The Pi2 takes more power than the Pi1.

Alternativle try another SD card.

Do you get a multi-coloured square in the top right of the display?

No. I recently got a separate power supply from CJE, so I am sure it is not that. I wonder if ROOL will send me a replacement micro-SD card?

RC14 appears to working fine on my original Pi B. Downloaded the image from here a few days ago & used Win32Diskimage to write to an SD card. Added disable_overscan=1 and its been running constantly since then.

I am encouraged to hear that. I am pretty sure that the problem was in the card rather than in RC14. I will get myself another micro-SD card and try again.

I’ve had RPi2 since day after release (RS), downloaded latest firmware and ROM at the time and seemed to work, although bootup graphics were a lttle ropey.
Set up RC14 card last night and much better, booted up OK, but borders on screen.
I’m using full HD TV for a monitor.
Since added:-

hdmi_ignore_edid=0xa5000080
hdmi_force_hotplug=1
hdmi_drive=2
disable_overscan=1
hdmi_group=2
hdmi_mode=2

to config.txt
Not all of it may be relevant, but it works for me.
Still boots up OK.

Some of that is to sort out a timing problem. TV needs to be on to enable HDMI output from RPi, but TV won’t acknowledge HDMI output if not being sent on TV startup. So force RPi to output and then turn on TV.

UPDATE: Tried Blackberry charger 700mA power supply on RPi2 and got coloured square in top left, but still able to type this OK. RC14 without any modification worked OK on RPiB and RPiB+. Will try with updated CONFIG.TXT as above at some point soon.

UPDATE2: Just to confirm, RC14 and new config.txt additions as above also work on RPiB+, RPi512Mb and the earlyish RPiB256Mb I’m writing this on now.

I’ve encountered a display corruption issue with RC14 on my original Pi Model B, but am not sure if it’s a bug, or the result of a bad Monitor Definition File.

The MDF I use is one I downloaded from the net for 1360×768 60Hz.
This worked on previous releases of RISC OS for the Pi, but on RC14, if set as the default resolution in !Configure, it results in a garbled display. However, if I configure the OS to boot up in 1024×768 and then manually select 1360×768 from the Display Manager (or via *wimpmode command), the problem does not occur.

…not sure if it’s a RC14 problem, just got my RPI2 today. So I’m using a 1920×1200 monitor but even with “disable_overscan=1” setting I get a left and right border of about 2 inch each when it enters the desktop. (I use the ACER 24xxx MDF).

While at start up (when the RPI data and ROM etc. is displayed) the settings are correct and no border left and right.

Any solution for that ?

Kuemmel: Are you sure the monitor is actually running at 1920×1200? It’s possible the GPU decided to pick 1920×1080. That will match the resolution used by the splash screen during boot, but if you then switch to 1920×1200 when in the desktop then it will obviously have to scale down and would introduce the black bars to the left & right.

…you’re right ! I checked with the monitor menu, and it’s always 1920×1080p even during the splash screen when there are no borders…how can I convince that GPU to “do” native 1920×1200 ?

See http://elinux.org/RPiconfig, in particular the long list of mode numbers about halfway down the page, and “Which values are valid for my monitor?” just below it (you’ll need to boot into Linux to use the tvservice tool)

Hm…I searched the forum also and your link, but adding
hdmi_ignore_edid=0xa5000080
hdmi_group=2
hdmi_mode=69
to the config didn’t change anything…anybody else with an 1920×1200 with a working setting ?

Works for me, Asus monitor,pi B, on boot Black strips top and bottom, then full screen 1600 × 1200. Away from pi now so can’t check details.

Works for me, Asus monitor,pi B, on boot Black strips top and bottom, then full screen 1600 × 1200. Away from pi now so can’t check details.

I have the following in config/txt:

fake_vsync_isr=1
framebuffer_swap=0
gpu_mem=64
init_emmc_clock=100000000
kernel=RISCOS.IMG

# NOOBS Auto-generated Settings:
hdmi_force_hotplug=1
config_hdmi_boost=4
overscan_left=24
overscan_right=24
overscan_top=16
overscan_bottom=16
disable_overscan=0

and my Pi2 starts up with the 1920×1080 splash screen at 1920×1200 with black bars top and bottom (correct) then drops into the desktop currently set to 1920×1080 in 1920×1200 with black bars top and bottom (correct). The GPU to monitor bit is correct so no tinkering required to config/txt.

If I then configure RISC OS to use a screen size of 1920×1200 using a monitor definition supplied by R-Comp then RISC OS starts up with the splash screen as before (1920×1080 with black bars displaying at 1920×1200) but the desktop is now at 1920×1200 with no black bars.

Not a problem (yet), but why is the size of the RC14 ROM about twice (5,242,880 bytes) that of the RC12 ROM (2,469,888 bytes)?
These figures are after decompressing the zipfiles downloaded from this website.

The small ROM is itself compressed (and is decompressed as it boots itself), the larger one is not compressed…

@Rick
Thanks for the answer. I did a search of the forum, but couldn’t find any post mentioning this difference. Perhaps I didn’t look hard enough. It’s surprising to me if no one commented on this, or perhaps I missed something somewhere. I did notice the difference in file types between the two ROMs, but didn’t check what type of file &fe5 is. It isn’t in my mimemap file.

What are the pros and cons of the two methods? One would have thought that having the ROM uncompressed in the ‘bootloader partition’ would make for a faster bootup and the extra space taken up in that ‘partition’ wouldn’t matter as a RISC OS ROM is small compared to a linux kernel.
In the linux case, is the kernel compressed in the bootloader partition?

If I recall correctly, FE5 is softload ROM.

I think some platforms (OMAP3?) are rather slow at loading the kernel from SD card, so it is faster to load a smaller chunk of data and then decompress it on the fly.

For Linux, the kernel uImage is about 3MiB – enough to get the core running and have the system boot itself from its own partition.