Raspberry Pi questions and answers (Rev #4, changes)
Showing changes from revision #3 to #4:
Added | Removed | Changed
Introducton
This page contains a number of general issues that may crop up when running RISC OS on the Raspberry Pi, but they don’t each deserve a page to themselves.
SD cards
What’s a good SD card to use?
The Raspberry Pi Foundation recommend a class 6 card or better. Nowadays, class 10 cards are available at very reasonable prices: indeed it may cost you more to get a class 6 card than it would to get a class 10 card. Higher-specification cards (UHS-II/UHS-III, V30/V60 etc.) cost substantially more than a class 10 card but will offer little (if any) performance improvement compared to a class 10 card 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 an 8GB card would provide plenty of room for additional files. Remember that you’ll need SystemDisc to use all of an 8GB 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.
Note: 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.
Boot (and !Boot) issues
Can I boot the Pi from USB (without an SD card at all)?
You can do it on the Pi 3B+ and Pi 3A+, but it’s not recommended. The reason is that RISC OS expects the CMOS file to be on the SD card – see CMOS RAM on the Raspberry Pi – so if you boot from USB your configuration changes will not be saved properly.
You could get round the problem by manually issuing SaveCMOS every time you make a configuration change, but it’s not a pleasant solution, and you will at some point forget to do it.
Can I move !Boot to an external disc drive?
Short answer: Yes you can. And there are good reasons for wanting to do so.
Having !Boot on the SD card means that the SD card will see lots of writes (thanks largely to the presence of !Scrap inside !Boot). While an SD card does provide a low-cost storage medium, it must be remembered it was designed for use by devices such as digital cameras which would be writing a series of (say) 2MB files rather than the 1kB used by Filecore: this can result in the SD card performing substantially more write operations than expected. Also, the SD card does not understand Filecore format so does not know when a file has been deleted: this means that the wear levelling algorithms will become progressively less efficient as the partition fills up, leading to a reduced operating life.
In summary, you can improve SD card longevity by moving !Boot somewhere else.
How to do it
- Copy 1 !Boot to the root directory of the chosen device, e.g. SCSIFS::4
- Press F12 and issue the following two commands:
*configure filesystem SCSI
*configure SCSIFSDrive 4 - Reboot.
Remember that you must retain !Boot.Loader on SDFS::0, but you can get rid of everything else on the SD card once you are sure that the system is using !Boot on SCSIFS::4. Indeed, some people go the whole hog and replace the SD card with a FAT32-formatted card containing only the files copied from !Boot.Loader.
1 You must use Copy, not Move. Apart from the !Boot.Loader issue, there is the small detail that RISC OS is at this point using !Boot on the SD card, and could get upset if some (or all) of it were to go missing mid-session.
System configuration
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.
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 will may require custom software to work withRISC 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.
Other
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.
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 requests2. 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.
2 RISC OS is obviously doing the dismount “wrongly”, but no one has yet worked out exactly what is “wrong”.
Social
and
ROOL Store
Buy RISC OS Open merchandise here, including SD cards for Raspberry Pi and more.