Any updates about RiscOS on the Raspberry Pi?

Distro (39Mbytes) now updated to today’s rom with tweaks to recover the icon bar, set SDFS as the default filing system (192) and automatically boot from it using the RAMFS. No doubt other bugs introduced!

Brilliant! Had a bit of a play with it last night, and managed to move the Boot sequence from RAM to the SD card to make it reconfigrable after a restart (I then mucked it up completely by trying to rename the SD card from Untitled cos it looked stupid in ShareFS – will redo it today). But great job!

Like some Linux distros, how about a script to automagically move !Boot and the HD folders to the SD card? Maybe pinned to the Pinboard, with an “are you sure?” box and a help file that appears when you click it. Might be problematic at the moment, because, in my experience, large copies to my Transcend 4GB SD card tend to crash. I had to have two goes to copy !Boot fully (incuding one I had stored on a USB stick).

A couple of other questions:
Is the large black border around the sides and bottom of the desktop a side effect of making the Iconbar appear, or is it peculiar to my setup (I noted a comment somewhere referring to 90% screen) and can it be offset?

Remember it is alpha and unsupported.

I deliberately avoided any write access to the SD card so that it would work on cards that allow reads but no writes under RISCOS. Some cards allow neither. Write access to SD card can be very slow under RISC OS at present.

Renaming the SD card may cause problems (I believe) – it is something that also causes problems if you try to rename a SCSI pen drive. Only Fat32fs can do that successfully (I think).

A couple of other questions:
Is the large black border around the sides and bottom of the desktop a side effect of making the Iconbar appear, or is it peculiar to my setup (I noted a comment somewhere referring to 90% screen) and can it be offset?

Yes it is a side effect of a bodge to make the iconbar appear. At present I cannot see how to offset it – remember it is showing a 1920×1080 desktop screen in 90% of a display that itself is actually 1920×1080 (so pixels don’t actually line up with the native display resolution). You could probably move it down a bit by fiddling with config.txt.

Thanks for posting the disk image Chris. One thing I was wondering though. I wanted to use your kernel.img file so I could have a visible icon bar on my existing RasPi RO setup which boots off the SD then goes to the * prompt, I type *scsi *run !boot and everything boots from a USB stick.

If I drop your kernel onto my USB stick then it no longer stops at the * prompt. I’ve tried tweaking your runme file to do *scsi *run !boot, but it’s obviously ignoring them. Is the Mac I’m using to edit the files somehow removing their ability to be run (I’ve no Acorn box with USB to be able to edit the files).

If I drop your kernel onto my USB stick then it no longer stops at the * prompt.

Yes – that is a consequence of my choice of SDFS as the default filing system (which appears to be fixed at ‘option 2 (run)’ as *OPT 4,0 [which would stop it trying to boot from SDFS] does not work) and ‘desktop’ as the default language in the rom image. You may be able to interrupt it using Escape?

which appears to be fixed at ‘option 2 (run)’

ISTR reading this being introduced to enable booting from non-Filecore discs, which don’t have a means of storing that option.

I think I have a theory as to why I (and others) get the “rainbow square of death”, but were previously able to boot to the supervisor prompt and/or into the desktop.

Chris, you said that you have enabled the SDFS in your distro as the default filing system, perhaps it IS loading the ROM, but failing to get any further because perhaps my SD card is one of the ones not supported by SDFS. But does that explain why I don’t see the supervisor prompt and/or the desktop?

I had originally been thinking that there was some filesystem corruption or similar because I wasn’t seeing any debug output on the serial port, but it looks like HALDebug has been turned off in these builds. It would be nice if even on a non-debug build that the ROM would at least write something to the console (perhaps the RISC OS version + board info) so we can see if it’s actually able to load the ROM or not. In fact, if there’s some catastrophic error it would be great if the ROM could write a crash/diagnostic to the serial port (assuming it doesn’t already).

I have tried putting my image onto an SD card that produces an error on any read or write to it from SDFS under RISC OS. What happens is that RISC OS is loaded into memory (by the boot loader) produces the screen full of debug messages as the modules initialise, clears the screen, outputs the ‘BCM 2835 .. 127M, Piccolo system SDFS’ messages, encounters a disc error as it starts to read the SD card and immediately abandons the boot and jumps into the desktop and gives a Wimp error ‘Machine not started up correctly’.

You are unzipping the Distro and using a disc imager to write the image file to the SD card so that it completely replaces what was there before? You can then see the files ’!Boot, HardDisc4.util and Run_Me as well as start.elf etc in the FAT partition?

Yes, unzipping then using ‘sudo dd’ to write the image to the SD card (I’ve tried this on both Mac and Linux):

dd if=RISCOS_Alpha_18Jun2012.img of=/dev/rdisk5		# Mac
dd if=RISCOS_Alpha_18Jun2012.img of=/dev/mmcblk0	# Linux

In both cases I get the “rainbow square of death”, however inserting the SD card into any system brings up a Finder window with the bootloader, kernel.img, !Boot, Run_Me etc. files. So perhaps the bootloader really isn’t able to load the ROM image … I might still have an image from two weeks ago that I know had HALDebug enabled so I can verify that it’s able to load the ROM (or not).

EDIT: I found (I think!) a working ROM image from June 8th which I’m pretty sure had HALDebug output. I still get nothing from the serial port … so it looks like this is a bootloader problem.

I’ve got it working – up to a point. I am getting error messages, which I know are to be expected from Alpha build quality software. I am using a Kodak branded 4GB memory card, which has the RISC OS and a Debian distro on it. I have been copying files using Finder on my Mac to the card (I am not a great user of the command line).

When I start the system up, I get to a grey screen with an error message: “Machine startup has not completed successfully: ‘An application that loads a file of this type has not been found by the Filer. Open a directory display containing the required Application and try again.’”. There are three buttons – Floppy Boot, Cancel and Retry. Cancel is the only button which lets me process to the desktop.

So, when on the desktop, I can do the usual stuff. However, a test application I copied from RPCEMU does not work. I had to reset all the file types in the Application folder (It had taken a trip through the Mac’s Finder so had lost the file types). When I try to run the Application, I get the following error: “Application may have gone wrong. Click Continue to try to resume or Quit to stop application.” When I open the Application folder, I have a number of Sprite files. Some open in Paint, some trip the same kind of “Application has gone wrong” error in Paint. The other error is “DOS Image read failed”.

I am suspecting that this may be down to the SD card I am using. It’s the only one I currently have that is excess to requirements, so it’s been pressed into RPi duties. However, I find it odd that it works sometimes, but not other times.

Yes, unzipping then using ‘sudo dd’ to write the image to the SD card (I’ve tried this on both Mac and Linux):

On Linux you can check the ‘flags’ in gparted.

sudo gparted

Right click on the partition and click manage flags. Normally ‘boot’ and ‘lba’ should be highlighted.

Alternatively you can try recreating the partition manually in gparted. After copying away the files on the sd card. Delete the existing partition then create a new ‘fat32’ partition, 64MiB should be enough. Then set the ‘boot’ and ‘lba’ flags again. Remount the card and copy the files back on.

When I start the system up, I get to a grey screen with an error message: “Machine startup has not completed successfully: ‘An application that loads a file of this type has not been found by the Filer.

This is probably the file called ‘!Boot’ on the SD card being seen as the wrong file type. At the supervisor prompt (press f12 if you are in the desktop) do the following:
*SDFS
*SetType !Boot Obey
(you only need to do this once)

I did this and then read the image from the card for the distro but I don’t know whether the filetype was stored with it.

Reading and writing to/from the SD card under RISC OS is unfinished and may/will give errors. The boot actions are to read three files. Having other external storage such as a pen drive or a network drive is recommended at present.

Chris, you said that you have enabled the SDFS in your distro as the default filing system, perhaps it IS loading the ROM,

No – the files ‘start.elf’ ‘bootcode.bin’ and ‘loader.bin’ between them load the image ‘kernel.img’ into memory and execute it. Until then the system does not know what is inside ‘kernel.img’. For us it is a RISC OS ROM plus some code around it to make it look like a valid image.

The latest bootloader files are available here. The most recent version has this fix ‘Add small boot_delay which helps boot hangs’.

They have changed the init_emmc_clock setting in recent versions of start.elf, you may need to add the following flag to config.txt:

init_emmc_clock=80000000

I don’t know how much of an issue this is for RISC OS (if any), see change 1178c4db57 for details.

BTW: This does not solve anything regarding the “rainbow square of death” issue.

Chris G: Running gparted on Chris H’s distro shows the SD card as being “uninitialized” and there’s no way to set the boot & lba flags [with gparted]. I’m guessing it’s an image of the partition, not of the actual disk (incl the partition table). Even so, fdisk sees it as a FAT32 filesystem and I was able to set the boot flag (no lba) in there — it didn’t fix anything. I also tried your suggestion of wiping the card, creating a new 64MiB partition and formatting it in FAT32, setting boot & lba and copying back the files. Same result, “rainbow square of death”.

The boot_delay setting in config.txt does indeed work, but there’s nothing to be gained from it, the HDMI output doesn’t activate until the final boot sequence begins (i.e. loading kernel.img). The latest firmware does make the OK light flash a couple of times, although I don’t know what the meaning of the flashes are.

So I rebuilt the SD card from scratch on a Linux system:

sudo parted -s /dev/mmcblk0 mklabel msdos
sudo parted -s /dev/mmcblk0 unit cyl mkpart primary fat32 -- 0 16
sudo parted -s /dev/mmcblk0 set 1 boot on
sudo mkfs.vfat -n RISCOS /dev/mmcblk0p1

Next, I copied in the bootloader.bin, loader.bin and start.elf from the raspberrypi github page. Then, I dropped in the riscos image as kernel.img with the basic config.txt. Still nothing!

If it wasn’t for the fact that this worked two weeks ago, I’d say it was the SD card. I guess next step is to identify a 2GB SD card that is known to work and get one of those.

Thanks to Chris for the latest build. I went along to the Oxfordshire Raspberry Pi MeetUp and was able to build this SD card during the event, and demo RISC OS to an enthusiastic buch of guys newly forming as a Raspberry Pi group. I did say it’s pre-alpha and this is understood, but plenty recognised the OS and were interested to see the original OS for ARM running. Obvious question was – what’s it good for? I mentioned tiny size and efficient coding is good for real time and embedded apps. People liked seeing BASIC V at the command prompt!

If it wasn’t for the fact that this worked two weeks ago, I’d say it was the SD card. I guess next step is to identify a 2GB SD card that is known to work and get one of those.

If you take a newly formatted SD card and put the files onto it manually and that doesn’t result in RISC OS starting up at all, then the problem is nothing to do with RISC OS. My suggestion is that you take the Debian distro and create a card from it, prove that the Pi starts up in Linux OK, rename the ‘kernel.img’ file, copy the RISC OS ROM image as ‘kernel.img’ and add the files ‘config.txt’, ‘!Boot’, ‘HardDisc4.util’ and ‘Run_Me’ (that you were able to see from my image before trying the SD card in anger) and then try that. The only extra step that would be needed (which is included in the image) is to set the filetype of ‘!Boot’ under SDFS in RISC OS to ‘Obey’.

I guess next step is to identify a 2GB SD card that is known to work and get one of those.

It doesn’t have to be a 2GiB SD card. I believe the Raspberry PI supports cards up to 32GiB class 6. The 2GiB restriction is with the maximum size of partition that DOSFS supports.

It looks like from the few cards I’ve tested on SDFS the larger ones tend to be faster even for the same class of card.

Just in case it’s useful I’ve found the that first attempt to boot from cold nearly always results in the colour cube of death, but a power cycle then brings RISCOS up straight away. It’s almost like a totally cold boot has some problem, which maybe the boot delay is fixing.

Has anyone else had a problem where after one successful boot subsequent exec run_me just hangs without displaying anything? I may have saved a change to config.txt from RISCOS onto the SD card which might have broken it.

I have updated the Distro to an image from a cheaper (and slightly smaller) 2Gbyte SD card, so that it can be loaded onto most 2G SDcards. The distro is now 21Mbytes and the card image 1,974,067,200 bytes so it should fit most 2G cards.
I have changed the configured language so that it doesn’t jump into the desktop if the booting fails and included the latest firmware.

The ‘Transcend’ 2G SD card code A38FX bought from Maplin today (cost £3.99) seemed to work: it worked the first time but subsequent boots caused it to freeze whilst copying a large file (14 Mbytes) – eventually it times out with an error ‘command timed out’.

However this image does work on a SanDisk Extreme III 2G Sd card (as did the previous).

Two other cards – a 4G SD HC card marked ‘integral’ and a 4G SD HC card marked ‘intenso’ – again bought from Maplin today (code ‘A84GK’, cost £3.99) both freeze while copying the same large file. So I haven’t found another SD card yet that works…

However all of the cards I have tried, that ’don’t work’, do get as far as starting RISC OS and beginning to execute ‘Run_Me’.

I was looking for a SanDisk card but Maplin didn’t have any.

Just in case it’s useful I’ve found the that first attempt to boot from cold nearly always results in the colour cube of death, but a power cycle then brings RISCOS up straight away. It’s almost like a totally cold boot has some problem, which maybe the boot delay is fixing.

This is EXACTLY what happens to me, too. I just ignored it and thought it was peculiar to my system, so I’m relieved it’s not just me! I originally assumed it was the fault of my monitor, which constantly “looks” for a signal on it’s three inputs, not being seen as being “on” to the HDMI port, but having tried it on a fixed monitor, I realised only this morning, that this couldn’t be the case.

This is probably the file called ‘!Boot’ on the SD card being seen as the wrong file type. At the supervisor prompt (press f12 if you are in the desktop) do the following:
bq. *SDFS
bq. *SetType !Boot Obey
bq. (you only need to do this once)

I did this and then read the image from the card for the distro but I don’t know whether the filetype was stored with it.

I’ve been changing it using the Filer options – but I notice that the filetype is lost on reboot, so it reverts to a dumb DOS file. I think you’d need to change the file type of Run_Me to Obey too. I set up the RAM disk and copied the HardDisc4 file manually and ran it. Now copying the resulting !Boot folder & other files to a USB stick. It looks like file types are not forgotten between restarts on those.

andym: Supposedly adding the following to config.txt will force the display:

 hdmi_force_hotplug=1

Hi Chris, your recent distro amendments deal with my whole wish list after yesterday’s demo – nice one. Is there a link to your latest version?

One thing we noticed during the meetup was various issues with I/O reliability cropping up over time. One chap had the very latest XBMC update and this eliminated video stuttering issues previously seen, but by the end of the night he was seeing the odd lockup.

Two physical rather than code issues may relate to this. One is cooling. This so often leads to performance/reliability issues that change over time, that it seems an obvious step to take to put some extra cooling on that ARM/memory chip stack. The other, about which others were more informed than I, is that there may be electrical crosstalk between the USB 5V supply and the board. I couldn’t boot my PI under RISC OS with a Mac keyboard and mouse, it stalled half way, but with a Tesco value keyboard/mouse it worked fine, or indeed an old Acorn keyboard with PS/2 to USB converter. Same SD card, same build.

Earlier in the night, I had issues with building the latest version of Chris’ distro – I got the rainbow cube of death. I switched from Win32 builder to DD with help from a chap called Ian, and used his 8GB SD Card, and all was well. I still have the original build so will tinker with treating the Pi differently physically – with and without cooling, using higher and lower powered USB adapters, different keyboards/powered hub and see if I can get it to work… Things like adding delay to software may just be helping the hardware with transient power draws or heat spikes if not explained by software processes?