Raspberry Pi questions and answers (Rev #16, changes)

Showing changes from revision #15 to #16: Added | Removed | Changed

Introducton

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

Raspberry Pi 4

Can I use RISC OS on the Raspberry Pi 4?

The Raspberry Pi 4 – although superficially similar to earlier Raspberry Pi models – has several hardware differences that require major alterations to RISC OS. While the latest development release of RISC OS will load on the Raspberry Pi 4, some of the hardware is currently unusable.

Items affected include:

• The four full-size USB ports (adjacent to the Ethernet port)
• The second HDMI port.

See Raspberry Pi 4 port status? for more information.

But I REALLY want to use RISC OS on the Raspberry Pi 4. How do I do it?

One possible method is explained at Installing RISC OS on the Raspberry Pi 4?. Alternatively, you may prefer RISC OS Pi RC16?.

Please note: If you want to use USB devices (keyboard, mouse) on the Pi 4, you will need to attach a USB hub to the USB-C (power input) port. If your hub does not support Power Delivery, you will have to power the Pi 4 via the GPIO pins.

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.
• Cards with an A1 app performance rating should be slightly faster than an ordinary class 10 card.
• Higher-specification cards (UHS-II/UHS-III, V60/V90 etc.) cost substantially more than a class 10 card with an A1 app performance rating, but will offer little (if any) improvement when used in a Raspberry Pi.

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 neither RISC OS nor the Raspberry Pi boot loader can handle. 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 substantially 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).

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 3A+ and Pi 3B+, but it’s not recommended. The reason is that RISC OS will be saving the CMOS file to the SD card but the Pi will be loading the CMOS file from the USB drive, so any configuration changes you make will not survive a reload. See CMOS RAM on the Raspberry Pi for more on this point.

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.

Why are my configuration changes lost when I shut down?

This indicates that either the “CMOS” file is missing from !Boot.Loader, or you have ended up with two “CMOS” files: one in the root directory of the SD (the Filecore partition) and one in !Boot.Loader (the DOS partition). This is explained further in CMOS RAM on the Raspberry Pi.

The fix is to issue:
*SaveCMOS !Boot.Loader.CMOS
and – if necessary – rename (or delete) any file named “CMOS” in the root directory of the Filecore partition.

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 RO527-20190610/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: Several “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 on the RISC OS Pi distribution, you might get scary “file clash” messages when you try to update the supplied applications. This is happening because the applications were updated outside of PackMan when preparing the Risc OS Pi SD card.

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 (we hope) eventually appear.

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

RISCIf your Raspberry Pi hasn’t got an Ethernet port, you can use a OS can use the built-in Ethernet ports on all Raspberry Pi models so equipped. This includes the “Model B” and “Model B+” variants of the Pi 1, Pi 2, Pi 3 and Pi 4.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 – these are sometimes advertised as “Wii-compatible”.

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 aren’t are not supported underRISC OS.

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 are 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 user unplugs the device 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. You have connected an external USB hub³ to the Pi. A workaround is to temporarily disconnect the USB hub and connect the keyboard to a built-in USB port on the Pi. Once you have used Shift-Break to boot to the command line, the USB hub can be reconnected.
3. If you have a NOOBS build, Shift power-on is intercepted by NOOBS (to boot in recovery mode). This only affects power-on: pressing Shift-Break while RISC OS is running should still work.

³ This will also happen if you are using a keyboard with a built-in hub (e.g. “The Official Raspberry Pi Keyboard”). In this case you will have to use a different keyboard to issue Shift-Break.

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.