Any updates about RiscOS on the Raspberry Pi?

I have now tried 4 different SD cards and 3 USB power cables. I’ve checked the voltage across TP1 & TP2 and it looks good (4.99V) but all I get is the RSOD (rainbow square of death). I started again with one of the SD cards, partitioned it with parted, formatted as FAT32 and copied ONLY bootcode.bin & loader.bin. When I try to boot, I see “5 flashes of the green LED”http://elinux.org/R-Pi_Troubleshooting#Geen_LED_blinks_in_a_specific_pattern indicating “start.elf” not found. Adding only start.elf gets me to the RSOD (as expected with no kernel.img), so this tells me the RPi IS able to read these SD cards, but no matter what kernel.img I drop in, I still get the RSOD — so there’s something wrong with the kernel images.

I think at this point as I’ve spent more on SD cards than RPi (I can reuse those!), I’m going to file a issue with the github/raspberrypi/firmware repo and ask for additional diagnostics (use the serial port!!!) on why loading kernel.img fails.

I wish this thing had a proper JTAG setup, then I could hook up my Bus Pirate with openocd and try to see what’s going on.

Hi Winston, have you tried to swap keyboard & mouse yet at all?

I had issues using a Mac wired keyboard, but not any of the others I’ve tried… Keith Dunlop also reported similar issues. Perhaps try via a powered hub?

Also, what’s the power rating of your supply? A Blackberry or newer HTC phone charger kicks out more than 1A which ensures it’s not overloaded.

Finally have you tried quickly removing power and re-applying when you get the RSOD? I’ve had issues on 1st time boot but not after retrying.

Hope one of these helps

Alex, I don’t actually have a keyboard or mouse connected, I should at least get to the supervisor prompt with the “no keyboard detected” message. I have tried various cables with various supplies including a 850mA wall wart, a Mac, a Dell Inspiron and even an 10W iPad charger that claims to output 2.1A

I have tried power cycling 7-8 times in a row, it doesn’t make any difference.

Thanks for the reply!

more out-there suggestions:

In the config.txt, set the HDMI mode to 1
Set the arm speed to 700…

…get it all down to ‘super safe’ levels…

By the way if you set hdmi_group 2, you can try more modes. Hdmi_mode 68 works great but I can’t seem to go higher. Is this a fundamental limit of the GPU??? It goes back to VGA above this.

EDITED to correctly say hdmi_group – NOT hdmi_class***

This seems to be a very common issue — SD cards working then after a week it no longer works …

http://www.raspberrypi.org/phpBB3/viewtopic.php?f=28&t=8226

On another thread I found a discussion of very similar problems, SD cards that work, then fail. Seems to be getting narrowed down to problems managing the SD card lines/clock speed:

http://www.raspberrypi.org/phpBB3/viewtopic.php?f=28&t=6822&p=105126#p105126

Interesting!

@Alex Gibson, “you set hdmi_class 2” ,IIRC the parameter is hdmi_group , right?

I’ve made a bit of progress since my previous attempts.

First, I imaged Chris Gransden’s image on to a Kingston 8GB SDHC card (class 10), that was on the list of working cards on the elinux site. Turning on the Pi caused it to exhibit the same symptoms as the previous Transcend card I’d been using. Remembering Leo’s suggestion on the previous page, I commented out the “hdmi_mode” line in the config.txt and turned on. Success! It hung up shortly afterwards, so I rebooted and it reverted to its previous non-working state.

Hammering ESCAPE got me to the Supervisor prompt, and given that it appeared to be stalling in the “PreDesk” folder, I renamed the folder to “PreDesk2”, created an empty one called “PreDesk” and rebooted. This got it working fairly consistently (albeit with an incomplete boot sequence). The pre-desktop display looks slightly squished, but the desktop looks fine (and just how I remembered it).

I bought a wired USB Microsoft Comfort 6000 mouse to use with my Pi, but it doesn’t like it very much. Any attempt to use it from RISC OS locks up the Pi solidly. The mouse is enumerated by *USBDevices, however. However, my (vile) Apple mouse (the one with the roller ball) works fine, and the roller ball functions as the Menu button. Incidentally, I am also using an Apple USB keyboard (I need to get a more conventional one). Keyboard and mouse are plugged into the hub.

I find the lack of an on/off switch or a reset switch on the Pi to be rather annoying, especially as I need to unplug both my powered hub and the PSU to get the thing to reset. I’m thinking of chopping up a couple of USB cables and sticking a switch on the 5 volt line to get around this.

John K. – would something like this be of use?
http://www.ebay.co.uk/itm/Xenta-Black-4-Port-USB-2-0-Hub-On-Off-switch-/290709521033?trksid=p3284.m263&trkparms=algo%3DSIC%26its%3DI%26itu%3DUCI%252BIA%252BUA%252BIEW%252BFICS%252BUFI%26otn%3D21%26pmod%3D120829874386%26ps%3D54

EDIT – this would only be of use if you just want a power switch in the USB chain. I don’t think you can use this as a USB hub for the Pi as well.

@Chris ‘xc8’ – right :) Edited.

@Winston and anyone else having SD card issues: One final thought on troubleshooting these, under ‘separate and clarify’, is: Are all the cards what they say they are?

Non-genuine SD cards are rife, and us hackers looking to get hold of several cheap ones, maybe via ebay, are at a high percentage risk of having fakes in our hands.

This tool: http://www.heise.de/ct/Redaktion/bo/downloads/h2testw_1.4.zip is good for checking the integrity of the card in your hand (on a windows box anyway) and there are others for linux. I got 4 8GB microSD cards for about £12, they came with adapters with different looking serials, so I checked with the tool and by calling SanDisk – all checks out, they’re just OEM cards.

So if anyone contributes to a ‘safe card’ list they should definitely check the card they tested IS what it says on the tin.

@Alex, I believe all of the cards I have tried are genuine, all are “branded” and have been purchased at reputable office supply retain chain except one Sony class 4 one that came with a Sony HD video camera and one Digitex one I purchased in Australia. The rest are various flavors of SanDisk or PNY which I have been using successfully with cameras, Beagleboards, Pandaboards etc.

Now if we could get that PandaBoard port going ….!

I had previously gone back and re-imaged my SD card with the archlinux that I originally downloaded and it had the same RSOD issue. So Dom @ RPi suggested going back to the Debian Squeeze image from the RPi site. That works on the SAME SD card that does not work with Chris’ RISC OS image. I should point out that Debian boots every time, no warm up, too hot/cold issues.

So there’s definitely something odd going on … I’m going to try to use the bootcode.bin, loader.bin and start.elf from the Debian image with Chris’ image and see if that works. At least I know my RPi isn’t bricked … but wow, Linux takes a very LONG time to boot compared to RISC OS!

In the meantime, does anyone know if the RPi RISC OS ROM is built with [PIC] position independent code? If not, what’s the entry point it’s built for (I think should be 0×8000).

SAME SD card that does not work with Chris’ RISC OS image

If you see the debug messages as the HAL initialises and the ‘RISC OS 127M’ header then up to this point RISC OS has not tried to access the SD card and pretty much all cards should get this far if the right files are there in the FAT partition. It is probably worth saying that the start up process is the same thus far whether it is Linux or RISC OS being loaded up – i.e. loaded from SD card and executed.

As it starts and goes through the boot sequence on the SD card then this is RISC OS accessing the SD card and (at present) it seems to require fast SD cards rather than run of the mill/cheap cards.

@Chris, it doesn’t get that far, I only see the RSOD. I think there’s something about the combination of the boot loader files, the kernel.img and possibly the SD card. It looks like the RISC OS ROM no longer has HALDebug enabled, so I can’t tell how far it’s getting into the boot process; is start.elf unable to read kernel.img? Or is kernel.img starting, but somehow failing/crashing before it has a chance to display anything. I’m going to go back and dig up one of the first RISC OS ROMs for the RPi and see if that works on top of the debian image.

where is Winston can someone drop a working card to him so that he can try It??

@rob, thanks, but I’m determined to figure this out!

I have improved the ‘help’ information on the download page for the Pi. Suggest you try this method and say where it fails.

Like Winston, I’ve got a couple of SD cards that show RSOD when loaded with Chris’s image from 16/06. By a process of trial and error, I’ve got both cards booting into RISC OS. I did this by adding the file ‘cmdline.txt’ which I’d grabbed from another card with Debian on it.

I’ve no idea what this file (or more probably, part of this file) does.

My next issue is that from the RISC OS start up message, it takes another 20 minutes or so to reach the desktop. Off to buy another, faster card this morning…

Well after a week of playing with the Pi and RISC OS i’ve had a variety of success which might be useful reading for someone. I’ve been writing images to SD card using win32diskimager 0.6 from a HP laptop with Win7. I’ve had no problems actually writing the images, the win32diskimager software is very easy to use.

I power the Pi through a 5a bench supply, limited to 1a 5v, directly wired to a USB socket, then connected with a micro D connector. With RISC OS cards, i always get a RSOD on first turning on, but normally it boots fine the second time.

In terms of SD cards, i’m now upto 4 different cards, Sandisk 8gb SDHC Class4, Sandisk 2gb SD, Toshiba 2gb SD Class2 and an Intenso 4gb SDHC Class4. All four cards work fine with Debian. Only the Toshiba 2gb card works reliably with the DISTRO image, however all four cards work without any problems with the kernel in the downloads section here (BCM2835Dev5.19). To use this kernel i’ve been using the DISTRO image from the 18th to setup the card, then using the kernel, bootcode, loader and start.elf in the downloads section.

With this configuration i’ve had no problems booting to RISC.

I also chanced a wireless keyboard and mouse from Maplins (its on offer for £15, and includes batteries), and amazingly enough it works without any problems under RISC. Its a super compact keyboard, not the best keys for typing (bit sticky).

I’ve also had no problem formatting a couple of USB pen drives for RISC. I have noticed that sometimes the hot swapping of the pen drives doesn’t seem to quite work reliably.

All in all, it’s quite impressive. If only i could remember anything about RISC OS to dig into the problems.

I’ve no idea what this file (or more probably, part of this file) does.

Nor me. My Pi was quite happy without this file (which was in the 19Apr Debian dstro but not in the 13Apr one). However I have now added it to the alpha distro (now 23 Jun 2012) and updated the bootloader etc. firmware files to the latest (2100 22 June 2012) versions. I have also named the riscos rom image ‘riscos.img’ rather than ‘kernel.img’ and specified this in the ‘config.txt’ file.

however all four cards work without any problems with the kernel in the downloads section here (BCM2835Dev5.19)

When you say ‘work’ do you mean you get a supervisor prompt with each or do you mean you can read and write files in RISC OS using the SDFS to all four cards?

The distro uses a rom that has SDFS as the default (very little else is different in the ROM) with a boot structure for it to boot into in what SDFS can see on the SD card.

There is one other difference between the rom in the ‘distro’ and the one in the downloads section on ROOL. The autobuilder one is compressed so it’s about 2MiB where as the ‘distro’ one is about 6MiB.
A couple of people have reported success using faster SD cards. Maybe part of the problem is to do with the size of the rom image?

With Chris Hall’s latest image I can finally get somewhere with my Pi. I now just get the same SD card issues everyone else has. I haven’t really kept up with progress over the past week so I don’t know what has changed.

I only have two types of card at the moment – a 4GB Sandisk Extreme (which results in “command timeout” after trying to load something in PreDesk (I can’t read the screen properly as I’m not using a monitor with a 1920×1080 display). With an offbrand 8GB card it just goes straight into the supervisor and claims not to be able to read any files.

So it’s now just a case of finding an SD card that works…

There is one other difference between the rom in the ‘distro’ and the one in the downloads section on ROOL. The autobuilder one is compressed so it’s about 2MiB where as the ‘distro’ one is about 6MiB.

The Raspberry Pi rom on the downloads page is 6Mbytes – the Beagleboard rom is 2Mbytes, compressed. The other difference is to sort out the iconbar visibility on the Pi download rom via an inelegant bodge.

So it’s now just a case of finding an SD card that works…

I can recommend an SD card that works: the SanDisk 2G Ultra card from Jessops at £12.95 works fine.