category: RaspberryPi <div id="toc_heading"></div><div id="toc"></div> h2. Introduction This page contains a number of general issues that may crop up when running RISC OS on the Raspberry Pi. <b>Please note</b>: This page makes frequent reference to the BREAK key. On some keyboards, the BREAK key is marked PAUSE. If your keyboard has neither key, see [[Beginners FAQ:Hardware Support]] for how to configure another key as BREAK. --- h2. Raspberry Pi models h3(#Pi4). Can I use RISC OS on the Pi 4 or Pi 400? Yes you can. If you're installing from scratch, see [[Beginners FAQ:Installing RISC OS]]. If you're already running RISC OS 5.30 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.":#DHCP h3(#Pi5). Can I use RISC OS on the Pi 5? No (or at the very least, not yet). RISC OS is a 32-bit operating system, but the Raspberry Pi 5 is primarily a 64-bit machine.[1] There are long-term plans to allow RISC OS to run on 64-bit hardware, but we are looking at a timescale of years rather than weeks or months. Sorry. fn1. <small>The Cortex-A76 CPU in the Pi 5 allows a limited form of 32-bit operation, running in EL0 (user mode) only. "RISC OS needs EL1":/wiki/documentation/show/How%20to%20port%20RISC%20OS%20to%20new%20hardware which is not available on the Cortex-A76.</small> h3(#PiPico). 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":#Pico - was a completely separate product. h3. Why does the Pi 4 display a low-resolution picture on 4K monitors? By default, the Pi 4 will only display a 3840x2160 picture at 30Hz, but most 4K monitors expect 3840x2160 at 60Hz. In these circumstances, RISC OS will fall back to a "safe" (i.e. low-resolution) screen display. You have two options: # Go to <i>Configuration > Screen</i> and choose a specific resolution and colour depth (e.g. 1920x1080, 16 million colours), replacing the "Native" entries. # Alternatively, add the line @hdmi_enable_4kp60=1@ to config.txt - see [[config.txt (Raspberry Pi)]] for more information. This will allow 3840x2160 at 60Hz, but will increase the operating temperature of the Pi 4, so additional cooling may be required. h3. 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. h3. Why won't GPIO (or HATs) work on the Pi 4? This was a problem when running RISC OS 5.28 on a newer hardware revision of the Pi 4B or Pi 400. The solution is to [[RISC OS Upgrade|upgrade to RISC OS 5.30]]. h3(#Zero2W). Why won't GPIO (or HATs) work on the Pi Zero 2 W? This was a problem when running RISC OS 5.28 on the Pi Zero 2 W. The solution is to [[RISC OS Upgrade|upgrade to RISC OS 5.30]]. --- h2(#SD). SD cards h3. What's a good SD card to use? Capacity: * The RISC OS Pi image will fit on a 2GB SD card. * SDHC cards up to 32GB should work with RISC OS. Performance: * A class 10 card (or one marked "V10") should give acceptable performance. A class 4 card will work, but you may find that things run slowly. * A card with an A1 app performance rating should run RISC OS 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. It may be worth checking the "known good cards list":https://elinux.org/RPi_SD_cards as there have been problems with a few cards over the years. h3(#SDXC). 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 SDXC cards up to 256GB[2] 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, RISC OS does not implement the "TRIM":https://en.wikipedia.org/wiki/Trim_(computing) feature, so SD cards that support TRIM will not know when files have been deleted. This means that the wear-levelling algorithms won't work as well as they could, leading to a reduced operating life. You might wish to consider an external (USB connected) HDD or SSD instead: these would be much more suited to the sort of read/write operations that Filecore performs. Note that most USB flash drives are _not_ SSDs, so will typically deliver poor performance. fn2. <small>Higher-capacity cards are not recommended, as RISC OS can only access the first 256GB of a card in the SD slot of the Raspberry Pi.</small> --- h2. System configuration h3(#MoveBoot). Can I move !Boot to an external disc drive? Yes you can. Detailed instructions are on [[Raspberry Pi: Moving !Boot to another drive|this page]]. h3(#BootUSB). 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 far from easy. Here are some of the issues you would encounter: # Depending on the age of your Raspberry Pi, you may need to update the firmware (and/or reflash the EEPROM) to allow USB boot. You may also need to "set an OTP bit":https://www.raspberrypi.com/documentation/computers/raspberry-pi.html#usb-mass-storage-boot on certain Pi models. # Your USB boot device will need to be set up in the same way as the [[Dual-format SD card]]. The easiest way of doing this is to install the [[Software information: RaspberryPi: RISC OS Pi|RISC OS Pi]] image on a USB stick (or USB-attached SSD) of your choice. # RISC OS will be looking for !Boot on the SD card, so you'll find yourself at the command line. If you're using a USB memory stick, the following commands should allow you to boot to the desktop:<br />@configure filesystem scsi@<br />@configure scsifsdrive 0@<br />@savecmos scsi::0.$.!Boot.Loader.CMOS@<br />Now press Ctrl-Break[3] to reboot.<br />If you're using an external HDD or SSD, the commands would be:<br />@configure filesystem scsi@<br />@configure scsifsdrive 4@<br />@savecmos scsi::4.$.!Boot.Loader.CMOS@ # When opening the USB drive by clicking on its icon, you should <b>right</b>-click. If - on your first access to the drive - you left-click, you will be shown the contents of the bootloader partition (config.txt, riscos.img etc.) instead of the expected Filecore partition (!Boot, Apps, Diversions etc.).<br />A workaround (available on recent versions of Fat32FS) is to add the line<br />@FatSwopMouseButtons :4 On@<br />to Fat32FS's !Config file[4] - this will swap things around so that left-click opens the FileCore partition (!Boot, Apps etc.) and right-click opens the bootloader partition (config.txt etc.) after the next reboot. # 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 [[Raspberry Pi: Moving !Boot to another drive|here]]. fn3. <small>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.</small> fn4. <small>If your USB device appears as drive 0, the line becomes @FatSwopMouseButtons :0 On@</small> h3(#ConfLost). Why are my configuration changes lost when I shut down? There are several possible reasons for this. Here are the "top four": # <b>The "CMOS" file (i.e. !Boot.Loader.CMOS) is missing/damaged/read-only</b>.<br />The fix is to delete !Boot.Loader.CMOS (if present) then recreate it by means of<br /><code>*SaveCMOS sdfs:$.!Boot.Loader.CMOS</code> # <b>You have ended up with two "CMOS" files</b>: one in the root directory of the SD (i.e. the Filecore partition) and another one in !Boot.Loader (the DOS partition).<br />The fix is to rename (or delete) any file named "CMOS" in the root directory of the Filecore partition. # <b>!Boot.Loader.config/txt is missing the two lines that load CMOS on boot</b>.<br />See [[config.txt (Raspberry Pi)]] for details of the lines to reinstate. # <b>You are booting from a USB drive (without an SD card at all)</b>.<br />This is more tricky to solve. Possible workarounds are given in [[CMOS RAM on the Raspberry Pi]]. h3(#Rename). 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. h3(#SysClock). 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. --- h2. Applications h3(#PackmanClash). 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]]. --- h2. Hardware h3(#WiFi). Can I use the onboard WiFi chip? Starting with RISC OS 5.30, the onboard WiFi chips on the Pi 3, Pi 4, Pi 400, Pi Zero W, Pi Zero 2 W and Compute Module 4 can now be used. See [[Getting Connected Online]] for setup instructions. h3(#EtherUSB). I need a USB-to-Ethernet adapter. Which ones work with RISC OS? Starting with RISC OS 5.30, a wide range of Ethernet adapters are supported. For example: * Apple USB Ethernet adapter (10/100) * Belkin F2CU040 USB-C to Ethernet adapter * Vivanco USB3.0 Gigabit Ethernet Adapter, UGreen CM209 * Huawei E8372h-320, Huawei E3372h-320 * Vodafone ZTE R216-Z * Realtek USB 10/100 LAN * ANKER A8352, CONCEPTRONIC DONNG06G, ABLEWE EA-02BK * CoreChips USB Ethernet Adapter Most other chipsets conforming to the "CDC":https://en.wikipedia.org/wiki/USB_communications_device_class "ECM":https://en.wikipedia.org/wiki/Ethernet_over_USB protocol should also work. Please note: Gigabit Ethernet adapters may deliver unexpectedly poor throughput, and USB3 multi-function devices (e.g. a combination Ethernet adapter and USB3 hub) may not work at all. This isn't an Ethernet issue: it's that RISC OS currently cannot operate USB3 devices at USB3 speeds. --- h2. Other h3(#Dismount). 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[5]. 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. fn5. <small>RISC OS is obviously doing the dismount "wrongly", but no one has yet worked out exactly what is "wrong".</small> h3(#DHCP). Why does boot-up stall at "Contacting DHCP server"? Firstly, DHCP can be quite slow. It can take upwards of 20 seconds to acquire a DHCP address, so don't start worrying until the message has been on-screen for (say) 40 seconds. You may have problems if you are moving the SD card from a Pi 4 (or Pi 400) to an older model of Pi (e.g. Pi 2 or Pi 3), and vice versa. 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 in this case is that the message will quote the "wrong" Ethernet interface (on older Pi models it should say <i>"Contacting DHCP server using Ethernet over USB interface"</i> while on the Pi 4 it should list a different type of Ethernet interface such as <i>"Broadcom GENET"</i>). It can also happen if you have moved the SD card from a Raspberry Pi with a built-in Ethernet interface (e.g. Pi 2, Pi 3B) to a Raspberry Pi without an Ethernet interface (e.g. Pi Zero, Pi 3A+). *Fix*: Press ESC to reach the desktop (click Cancel on the dialogue box that appears). Now go to <i>Configure > Networking > Internet > Interfaces</i>, select a suitable interface (e.g. "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. If the "Interfaces" page does not contain any physical interfaces at all (i.e. only "Serial PPP" is listed) you will have to disable networking instead (untick "Enable TCP/IP Protocol Suite" on the Internet configuration window). This is not ideal but at least it gives you a starting point. <b>Please note</b>: This is not a blanket ban on moving SD cards from one Pi to another. It is perfectly safe to do so when moving between models with similar characteristics (e.g. between older models with an Ethernet interface, such as a Pi 2B and a Pi 3B+). If neither device has a built-in Ethernet adapter, it will also be safe to move the SD card (e.g. from a Pi Zero to a Pi 3A+). h3(#ShiftBreak). Why won't Shift-Break boot to the command line? First things first: are you doing Shift-Break properly? You should hold down Shift, press and release Break, then continue to hold down Shift until the reboot finishes. There are several reasons why Shift-Break (and Shift power-on) may not work on the Raspberry Pi: # Recent EEPROM bootloader software for the Pi 4 (2022-02-28 and later) uses Shift power-on to invoke the "network install" feature. # NOOBS[6] used Shift power-on to boot in recovery mode (e.g. to select a different operating system to run). # On some systems, the message <i>No keyboard present - autobooting</i> can appear during boot. This is most likely to happen if you have a lot of USB devices (and/or a USB hub) connected. # Another problem relates to the keyboard itself. On some keyboards, holding down a key when power is first applied will cause the keyboard to misinterpret it as a "stuck key" so will not signal that it is being pressed. If you are seeing <i>No keyboard present - autobooting</i>, try disconnecting all USB devices (including USB hubs) and reconnect only the keyboard: you may find that Shift-Break now works. fn6. <small>Raspberry Pi Ltd ["removed NOOBS from their download page in 2020":https://forums.raspberrypi.com/viewtopic.php?t=303015], so you are unlikely to see it on a newly-purchased system.</small> h3(#Pico). 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,":https://www.raspberrypi.com/products/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.30 build: * Edit cmdline.txt to read:<br />@disable_mode_changes disable_gamma@ * Issue the following commands:<br />@*Unplug BootFX@<br />@*Configure Language 19@<br />@*Configure Mode 7@<br />@*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. h3(#RC15). What's all this talk of "RC" builds? RC stands for _release candidate_, a software build typically produced for acceptance testing in the run-up to the next stable release. While based on the corresponding development build, it may omit some untested or problematic components in an effort to improve stability. RC builds are always <b>beta test</b> software. If you are using one of these you should upgrade to a later stable release when it becomes available.