Raspberry Pi questions and answers

Introduction

This page contains a number of general issues that may crop up when running RISC OS on the Raspberry Pi.

Raspberry Pi models

Can I use RISC OS on the Pi 4 or Pi 400?

Yes you can. If you’re installing from scratch, see Installing RISC OS on the Raspberry Pi 4.

If you’re already running RISC OS 5.28 on an older model of Raspberry Pi, make the following checks:

• !Boot.Loader needs to contain FIXUP4/DAT and START4/ELF alongside FIXUP/DAT and START/ELF. See Software information: Raspberry Pi: Firmware for details.
• CONFIG/TXT (also in !Boot.Loader) needs a “Pi4” section. See config.txt (Raspberry Pi) for details.

With those changes applied, the SD card should work in a Pi 4, although you may run into DHCP problems – see below.

Can I use RISC OS on the Raspberry Pi Pico?

Short answer: No.

This is for architectural reasons. The big show-stopper is that the Cortex-M CPU (used in the Pi Pico) only supports the Thumb instruction set, whereas RISC OS uses the A32 instruction set. Getting RISC OS to run on the Pi Pico would thus entail a complete rewrite of the RISC OS kernel. Sorry.

For the record, “RISC OS Pico” – now discontinued – was a completely separate product.

Why does the Pi 4 boot-up stall at “Contacting DHCP server”?

This can happen if you have used the SD card to boot another Raspberry Pi. The Pi 4 has a different Ethernet adapter to earlier Pi models, so RISC OS will be looking for the wrong Ethernet adapter. The clue is that the message will read “Contacting DHCP server using Ethernet over USB interface” when on the Pi 4 it should read “Contacting DHCP server using Broadcom GENET interface”.

Fix: Press ESC to reach the desktop (click Cancel on the dialogue box that appears). Now go to Configure > Networking > Internet > Interfaces, select “Broadcom GENET” and click on “Configure”. In the “Obtain IP address” section, choose “via DHCP” and click on “Set”. You will be prompted to reboot: this reboot should proceed to the desktop without any error.

Why does the Pi 4 display a low-resolution picture on 4K monitors?

By default, the Pi 4 will only display a 3840×2160 picture at 30Hz, but most 4K monitors expect 3840×2160 at 60Hz. In these circumstances, RISC OS will fall back to a “safe” (i.e. low-resolution) screen display.

You have two options:

1. Go to Configuration > Screen and choose a specific resolution and colour depth (e.g. 1920×1080, 16 million colours), replacing the “Native” entries.
2. Alternatively, add the line hdmi_enable_4kp60=1 to config.txt – see config.txt (Raspberry Pi) for more information. This will allow 3840×2160 at 60Hz, but will increase the operating temperature of the Pi 4, so additional cooling may be required.

Why doesn’t HDMI sound work on the Pi 4?

When using RISC OS, HDMI sound is only available on the left-hand HDMI port. If you connect to the other HDMI port you will get a picture but no sound.

On the Pi 400, use the HDMI port closest to the SD card slot.

Why won’t any HATs work on the Pi 4?

A new hardware revision of the Pi 4B appeared in November 2020, shortly after RISC OS 5.28 was released. Because RISC OS 5.28 doesn’t recognise the hardware, the GPIO pins (and hence most HATs) are inaccessible.

To check whether your hardware is affected, issue the command *ROMModules and look for the GPIO entry. If all is well, this will have a status of “Active”. If the GPIO module is shown as “Dormant”, you will need to upgrade the RISC OS ROM to version 5.29 (use a ROM dated 17 December 2020 or later).

SD cards

What’s a good SD card to use?

• The Raspberry Pi Foundation recommend a class 6 card; a class 10 card should provide acceptable performance.
• A card with an A1 app performance rating will be faster than an ordinary class 10 card.
• A card marked “U3 A1” (or “A1 V30”) should be even faster, but you may only notice this with a Pi 4.
• Higher-specification cards (UHS-II/UHS-III, V60/V90 etc.) cost substantially more than an “A1 V30” card, but will offer little (if any) improvement.

As for card capacity, the full RISC OS Pi distribution takes up less than half the space on a 2GB card, so a 16GB card would provide plenty of room for additional files. Remember that you’ll need SystemDisc to use all of a 16GB card.

Can SDXC cards be used?

Yes, but you’ll have to reformat them first. SDXC cards are supplied in exFAT format, which RISC OS cannot handle at present. Reports suggest that 64GB and 128GB cards¹ will work with the Raspberry Pi after reformatting to FAT32.

When reformatting the card, you must use Master Boot Record (MBR) partitioning. If you select “GUID partition table”, RISC OS will be unable to read the card.

In any case, SD is a poor choice for Filecore storage. The quoted SD speeds are for “sequential burst” writes, not the random read/write operations that Filecore typically performs. Cards with an A1 (app performance) rating will be slightly better in this respect, but may cost more than an ordinary card. In addition, the SD card doesn’t “understand” Filecore format, so the wear-levelling algorithms won’t work, leading to a much reduced operating life.

You might wish to consider an external (USB connected) HDD instead. For a slight increase in power consumption you should see a vast improvement in media longevity. For example, a 500GB USB-connected HDD costs about as much as a 128GB SDXC card and will last longer (provided you’re not exposing it to significant mechanical shocks).

¹ Older models of Raspberry Pi (up to and including the Pi 3B) cannot use SDXC cards larger than 256GB. This is a hardware restriction.

System configuration

Can I move !Boot to an external disc drive?

Yes you can. Detailed instructions are on this page.

Can I boot the Pi from USB (without an SD card at all)?

You can do it on the Pi 3 and Pi 4, but it’s not recommended. Here are some of the issues you would encounter:

1. RISC OS will be looking for !Boot on the SD card, so you’ll be stuck at the command line. If you’re using a USB memory stick, the following commands should allow you to boot to the desktop:
   configure filesystem scsi
configure scsifsdrive 0
savecmos scsi::0.$.!Boot.Loader.CMOS
   Now press Ctrl-Break² to reboot.
   If you’re using an external HDD or SSD, the commands would be:
   configure filesystem scsi
configure scsifsdrive 4
savecmos scsi::4.$.!Boot.Loader.CMOS
2. When opening the USB drive by clicking on its icon, you must always right-click. If – on your first access to the drive – you left click, you will be shown the contents of the boot partition (config.txt, riscos.img etc.) instead of the expected Filecore partition (!Boot, Apps, Diversions etc.). You should be able to recover matters by dismounting the drive and right-clicking on the icon, but it’s safer never to get into that situation. Always right-click on the drive!
3. RISC OS will (try to) save the CMOS file to the SD card but the Pi will be loading the CMOS file from the USB drive, so any configuration changes will not survive a reload. See CMOS RAM on the Raspberry Pi for possible workarounds.

This list is not exhaustive. You may experience other problems besides those mentioned above.

Users wishing to reduce SD card wear-and-tear would be better advised to continue booting from the SD card, but to move the !Boot directory to a USB drive, as described here.

² If you have a Pi 400, press and hold Fn-F10 for 10 seconds to power-off. Wait a few seconds, then press Fn-F10 to power on. This should boot into RISC OS.

Why are my configuration changes lost when I shut down?

There are several possible reasons for this. Here are the “top four”:

1. The “CMOS” file (i.e. !Boot.Loader.CMOS) is missing/damaged/read-only.
   The fix is to delete !Boot.Loader.CMOS (if present) then recreate it by means of *SaveCMOS sdfs:$.!Boot.Loader.CMOS
2. You have ended up with two “CMOS” files: one in the root directory of the SD (i.e. the Filecore partition) and another one in !Boot.Loader (the DOS partition).
   The fix is to rename (or delete) any file named “CMOS” in the root directory of the Filecore partition.
3. !Boot.Loader.config/txt is missing the two lines that load CMOS on boot.
   See config.txt (Raspberry Pi) for details of the lines to reinstate.
4. You are booting from a USB drive (without an SD card at all).
   This is more tricky to solve. Possible workarounds are given in CMOS RAM on the Raspberry Pi.

I renamed a file in !Boot.Loader and the Pi won’t boot. What gives?

DOSFS understands long file names, but if you rename a file such that its name isn’t long any more, only the “long file name” entry is changed: the 8.3 name still points at the “long file name” entry.

The Pi bootstrap loader will only check the 8.3 filename (not the “long file name”) when looking for a file whose name fits in the 8.3 format.

The practical upshot is that if you rename RISCOS/IMG to old-RISCOS/IMG and then rename it back to RISCOS/IMG, the Pi bootstrap loader will no longer be able to find it.

Workaround: If you want to change the name of a file inside !Boot.Loader, use Copy instead of Rename.

Why is the system clock showing the wrong time?

The Pi does not have a real-time clock. Hence, when the Pi boots up, it will not be aware of the correct time.

The fix is to run an Ethernet cable from the Pi to your broadband router (or equivalent network port with access to the Internet). The Pi will then be able to update its clock from the network.

Note: “Real-time clock” add-ons are available for the Raspberry Pi, but some may require custom software to work with RISC OS.

Applications

Why does PackMan complain about clashing files?

When using PackMan, you might get scary “file clash” messages when you try to update an application. This is most likely to happen if the application was updated outside of PackMan (e.g. by downloading a new version from a website).

The fix is to click on the Backup button. This will move the “unexpected” files into a Backup directory: the update should then progress normally. After the update is complete, you can see a list of backed-up files in the Advanced section of PackMan’s icon bar menu, and delete or restore them as you wish.

For further information, see the PackMan User's Guide.

Hardware

Why can’t I use the onboard WiFi chip?

RISC OS does not currently support WiFi on any platform. Adding WiFi support to RISC OS is a major undertaking, but it is on the roadmap so will eventually appear.

I need a USB-to-Ethernet adapter. Which ones work with RISC OS?

If your Raspberry Pi hasn’t got an Ethernet port, you can use a USB-to-Ethernet adapter, but you need to ensure that the chipset is supported.

Your best bet is one with an Asix AX88172 or Asix AX88772 chipset.

Other chipsets known to work include:

• MosChip MCS7830
• Pegasus PII (ADMTek AN986, AN8511)
• SMSC75xx, SMSC78xx, SMSC95xx

Don’t get an adapter with a Realtek chipset – at present they are not supported under RISC OS.

Remember that RISC OS can use the built-in Ethernet port on the “Model B” and “Model B+” variants of the Pi 1, Pi 2, Pi 3 and Pi 4, so you won’t always need a USB adapter.

Other

Why do people say “wait 15 seconds before unplugging a device”?

USB drives – especially flash memory sticks – don’t write all the data to the drive immediately: some of it is delayed (in the expectation that the user will be writing more data). This is done for efficiency – and media longevity – reasons: the fewer separate write operations performed, the better. The data will eventually be written after a timeout, which could be several seconds.

This is exacerbated by the fact that many USB devices don’t action dismount requests³. Instead of immediately flushing all delayed writes to the media in the expectation that a power-off is about to happen, the delayed writes remain pending until the timeout (mentioned above) occurs in the normal course of events. If the device is unplugged immediately after issuing the dismount but before the delayed writes have been actioned, data will be lost.

So the “wait 15 seconds” rule will hopefully allow for all but the most tardy of these delayed writes to actually happen, thus minimising the risk of data corruption.

³ RISC OS is obviously doing the dismount “wrongly”, but no one has yet worked out exactly what is “wrong”.

Why won’t Shift-Break boot to the command line?

There are three possible reasons for Shift-Break (or Shift power-on) not booting to the command line.

1. “*Configure Language 18” has been issued (fix: issue “*Configure Language 11”).
2. If you have a NOOBS build, Shift power-on is intercepted by NOOBS (to boot in recovery mode). In this case, the workaround is to power-on while holding down the * key on the numeric keypad (instead of Shift).
3. The message No keyboard present – autobooting appears during boot. This indicates that the keyboard didn’t start up quickly enough: try disconnecting all other USB devices (including USB hubs) and power on with only the keyboard connected.⁴

⁴ If the message persists, this indicates that the keyboard really is too slow to start up. You may have more success with a different make/model of keyboard.

What happened to RISC OS Pico?

RISC OS Pico was a cut-down version of RISC OS (no GUI) that was put together for a one-off special event (the 50th anniversary of the BASIC programming language in 2014). Updates ceased in 2017: it will not run on anything newer than a Pi 3B. In addition, there is the possibility of confusion with the Raspberry Pi Pico, which RISC OS does not support.

Hence RISC OS Pico is no longer available from the Downloads page.

To get the “RISC OS Pico” experience from a RISC OS 5.28 build:

• Edit cmdline.txt to read:
  disable_mode_changes disable_gamma
• Issue the following commands:
  *Unplug BootFX
*Configure Language 19
*Configure Mode 7
*Configure NoBoot
• Format another SD card as FAT16 (one partition: 2GB recommended, 4GB maximum).
• Copy all the files from the RISC OS boot partition (bootcode.bin, CMOS, config.txt etc.) to the newly-formatted SD card.
• Insert the new SD card into the SD slot on the Pi and power on. This should boot to a Mode 7 screen running BASIC.

What’s all this talk of “RC15” and “RC16”?

RC stands for release candidate, a software build typically produced for acceptance testing in the run-up to general release. While based on the corresponding development build, it may omit some untested or problematic components in an effort to improve stability.

The RISC OS release cycle does not generate RC builds as a matter of course, but several RC builds of RISC OS for the Raspberry Pi have been produced: the most recent being RC16 (June 2020)⁵.

⁵ The previous RC build was RC15 (April 2017). This should give you some idea of how often they appear.