Rpi but not sure how to install the image (under RISC OS)

I have previously set up a BBxM using SDCreate. My RPi came in the post today so I am itching to get RISCOS running on it. However, I am struggling to find any useful information about installing the RPi image under RISC OS.

Can I use SDCreate to create the image on the SD card for the RPi, or is there another method for putting the image on the SD card for the RPi?

I have downloaded the latest version of SDCreate (v1.25) but am not presented with an option to create an image for the RPi.

I was also wondering if, like the BBxM, the SD card is only used for the RISC OS image and a separate USB drive is needed for the HardDisk image/!Boot?

Thanks in advance.

I thought you needed to use Win32DiskImager on a PC to format an SD card and copy the distro to it. Two partitions are created, one for the OS bootstrap and another for RISC OS.

Download the distro and Win32DiskImager here: http://www.raspberrypi.org/downloads

Once you have the SD formatted, replace riscos.img with the latest from the download pages here, remembering to rename if from riscos to riscos.img

FYI the Pi image is a full “raw” disk image.
I think SDCreate is for creating an image from scratch isn’t it.
So follow the instructions at the top of the page of http://www.raspberrypi.org/downloads

Basically windows users use win32diskimager and unix/linux users use dd, and just write the image directly over the raw disc of the sd card.

The Pi disc is a FrankenDisc ;p
It’s a risc os disc with a dos partition and boot sector fudged on it, horrible and cool all rolled into one!

And everything fits on the SD card!

Thanks for the reply, it would explain the lack of information on the ROOL wiki/website/www about installing the Pi image using RISC OS. I would have preferred that option. Never mind, I guess that there must be a way to do it under Linux or MacOSX.

Write the downloaded and unziped RPi Image to the SD Card by using the write option of SDCreate. No problem. It works.

DavidS – I have a couple of RiscPC’s and an A5000 lying around so old 26bit software should not be a problem.

Raik, which machine type did you use in SDCreate? RPi is not in the list.

I mean you misunderstand. You need the download the ready Image from Malcolms post and unzip this. In the top of SDCreate disable [Create] and use the [Write] option (ignore CMOS). Then drop the image to SDCreate. Write the image. It works also with a Linux image etc. Excuse my bad English.

Raik – Das ist kein Problem. Dank Ihnen habe ich Forschritte gemacht. Jetzt habe ich ein RPi mit RISC OS auf meine Schreibtisch. Vielen Dank!

Aber nur noch viele Fragen ;)

Gern, aber warum strenge ich mich so an?
Frag doch. Hier gibt es Schwarmintelligenz umsonst ;-)

Oki doki, RISC OS is up and running after a fashion, thanks to Raik. I don’t quite understand how the disk is set up. There is a 48MB partition that seems to contain the RISC OS image + files to boot. I discovered that if put the !Boot application on that partition the RPi will boot up. However, given the small size of the partition is it best to leave that as it is and install the HD4 components including !Boot on another external drive? Which is the way my BBxM is set up.

I also noticed that the vast majority of the SD card seems to consist of free space. Is there any way to use the rest of the SD card? Is it possible to copy the files off this partition, reformat the whole SD card to RISC OS format and copy the files back to it? Or are there hidden files in the other two partitions that are needed for the RPi to boot up.

I also wondered if the Windows installer do anything different with the partition structure?

Raik – Entschuldigung, ich meinte nicht das Sie müssen alle Fragen beantworten ;)

Kann ich auch nicht. Das kann nur Gott ;-)
Hab ich auch nicht so verstanden. No problem.

To partition a SD Card … two posts…

https://www.riscosopen.org/forum/forums/6/topics/1094
https://www.riscosopen.org/forum/forums/8/topics/1085

I have use a HD by using a dummyboot.
On the ADFS partition of the card I have only a !Boot and this only set adfs as filingssystem starts the !Boot on HD…

Thanks for the links, I will take a good look at them tomorrow.

As an experiment, I just took a 16GB SD card, formatted to “MS-DOS” format on a Mac, copied the PiBoot files from the SD I prepared with SDCreate, and put the 16GB card back in the RPi. A little to my surprise RPi booted, although it only seems to see 2905MB of the card. It also did not show the “DOS” file type icons, most of the PiBoot files now appear as text files.

I also just realised that the RPi is running SDFS, which I don’t have on the BBxM.

I also just realised that the RPi is running SDFS, which I don’t have on the BBxM.

SDFS has been in the OMAP3 ROM for some months now. What version of the ROM are you running on the BB?

Yes, I mean in june (xM) and july (Pandora).
I have try some things with the RPi Image. If you change !Boot on the adfs partition and use the right bootfiles on the fat partition, it works also on the Pandora, BBC4 and Panda. On xM I have not try. False SD card ;-)

May be I misunderstand Stan. But if you format a adfs card/stick/HD/? via WIN/Linux/MAC the adfs data are not deleted. If you store a lot of Data the part should overwrite. If you use sdformatter under WIN, the adfs data are lost ofter this.

Chris – OK I just tried the most recent 5.19 ROM on the BBxM. It breaks a few things so I am now back with the last stable 5.18 which at least allows the BB to boot up properly (under 5.19 it boots up but forgets CMOS settings like screen resolution).

I presume that some of the problems I am to do with the change to SDFS. So here are a few things I need confirming.
1) !Boot and the skeleton HD4 need to be installed on the SD card.
2) a !Boot application installed on a SCSI disc will not function correctly under 5.19 as it did under 5.18 (BBxM)
3) problems with screen resolution not being remembered over boots (both BBxM with CMOS widget and RPi 5.19 image) are because I don’t the !Boot application on the SD card?
4) If I understand Raik correctly, to be able to use all the storage space on an SD card under RISC OS:
I need to
a) format the SD card on a RISC OS box using SCSIForm to ADFS format first.
b) Reformat the card to FAT32 format using a Win/Mac/Linux disc utility.
5) I need a fresh !Boot on the SD card to ensure that the RPi will boot up correctly.

Chris – OK I just tried the most recent 5.19 ROM on the BBxM. It breaks a few things so I am now back with the last stable 5.18 which at least allows the BB to boot up properly (under 5.19 it boots up but forgets CMOS settings like screen resolution).

I had the same problem. As far as I’m concerned – it’s a bug.
Others seem to think that everyone should add a widget to the board, but although I do have a widget fitted and don’t suffer the problem I think the bug should be fixed not least becuase we are likely to have boards or devices appearing that don’t have the facility to fit that kind of device and the file based storage has to be available and working correctly.
Making comments about people who are too tight to spend a few pennies on the widget just won’t wash.

Unlike you I caved in an bought the widget. It works fine under 5.18 but doesn’t under 5.19. On the RPi I have changed the !Boot.Choices.Boot.Predesk.Configure Monitor file so that I get the right screen resolution at boot up, but can’t get the RPi to remember not to use textured window backgrounds (never liked them).

The RPi is up and running using just RISC OS to create the SD card. However, I wonder if some of my problems are down to using an ‘unofficial’ method of creating the SD card image. I think am going to bite the bullet and use a PC to set up the card the ‘official’ way. Then I can see if there are differences in the partition structure on the two SD cards.

Time to head outside for a bit, it has warmed up to -12 out there and an old Citroen needs a front wing putting back on.

I had the same problem. As far as I’m concerned – it’s a bug.

I was aware there had been a bug, but assumed it had been fixed ages ago! I use a widget so wouldn’t notice.

Unlike you I caved in an bought the widget. It works fine under 5.18 but doesn’t under 5.19.

I use 5.19 on my ARMini, updating every few days and haven’t had any problems. Is your !Boot fully up to date? There have been a few changes there.

However, I wonder if some of my problems are down to using an ‘unofficial’ method of creating the SD card image.

That is quite possible. When I first ordered a RaspberryPi, I thought I would set up a card ready, but on downloading the ROM release from the ROOL site, there was no !SDCreate as there was for the BB or PandaBoard, and setting up a card involved either linux, or Windows, neither of which I use. Because there was a delay in getting the Pi, I just ordered up a ‘one I prepared earlier’ from ROOL, and used !CloneDisc to make backup cards once it arrived.

Unlike you I caved in an bought the widget. It works fine under 5.18 but doesn’t under 5.19. On the RPi I have changed the !Boot.Choices.Boot.Predesk.Configure Monitor file so that I get the right screen resolution at boot up,

As I said¹ I do have a widget fitted, however it shouldn’t be required. Like you I assumed one of the CMOS related items fixed it after I started using the widget.

For me the only thing I really noticed was the DPMS settings going AWOL after any reboot – however DPMS is, along with screen resolution, what I regard as a “must have”. RO really should stop chuffing about with hardware add-on requirements for basic functions.

As Chris says there have been a number of changes in the !Boot structure in the 5.19 development period so a matching !Boot is required.

¹ …but although I do have a widget fitted and don’t suffer the problem I think the bug should be fixed…

3) problems with screen resolution not being remembered over boots […] with CMOS widget

Update your !Boot sequence this will then solve itself, if you have a heavily customised !Boot for some reason (argh!) at least update the contents of Choices/Boot/PreDesk/Configure so the monitor settings complete.
The default for a fresh !Boot is a 640×480 mode I think, obviously change that with !Configure as desired.
The revised !Boot sequence is backwards compatible with 5.18, so you can still go back if you choose.

Since the monitor settings aren’t held in CMOS it sounds a little off point to bang the i-don’t-support-risc-os-to-the-tune-of-even-a-fiver drum, while simultaneously demanding the code fairies to write code. See “RISC OS Select” under “financially unviable” in the dictionary.

They are any things mixed.
On my BIK (with xM and Panda and BBC4) the widget works fine with and without HD boot. But it must filled with the right cmos.
If you have not a widget and your xM is booting from HD you must save your cmos first. The second you should create a adfs stick and copy your !Boot on it. If the widget fitted the first time, the xM boots only from SCSI0. Power off the xM and take the widget on it.
Restart and it will boot from Stick. Load cmos. It takes a little moment. Then restart the xM and it should boot from HD.
New ROM. If you use a ROM without SDFS change the ROM with BBFlash or remove the Card and copy the new ROM on it. You can use the on powerd xM and you must use the actuelly Harddisc4 !Boot. Any things are changed. Old !Boot with new ROM … problem, problem, problem. Backup or rename the old !Boot and turn the needed Parts back to the new.
After restart it is possible to set any things.
Two patitions for the RPi. Official it is not possible. But it works. ADFS: reduce the number of sectors and note the free Space of this Partition. It is the first Partition of the card. I have used geparted under Linux, I mean Chris has used fdisk.
Format the the free space at the end of the Card…
Wit a little bit luck it works ;-) To kill all this settings from the card you need a tool like SDFormatter.
On RPi I have not try to boot direct from HD. With the Dummyboot it works. I will take a look next week maybe there is a other way.
Sorry if any things a little bit confused.

Since the monitor settings aren’t held in CMOS it sounds a little off point to bang the i-don’t-support-risc-os-to-the-tune-of-even-a-fiver drum.

’scuse me? The little quote I gave was that I do have a widget fitted (from a number of purchases off the emporium)

and it is notable that the DPMS settings AND the resolution routinely went AWOL when it wasn’t fitted but now seem to remain. Whether the details are in the widget or the lack of properly saved CMOS causes disk saved settings to join their ancestors is a minor detail. I parted with the minor cash, others of new RO experience (and old lags) may not.

The disk settings issue has been round the circuit before, Dave H. wrote something disk based that worked as far as he required, the other approach was the widget.

Disk saved settings are easy to shift platform to platform, relience on a add-on is not. e.g. How would a (mythical) port to a Chromebook save to a widget?
Which do you see as the more flexible and long term solution?

I had the same problem. As far as I’m concerned – it’s a bug.

This is possibly one of the problems with the site – it would be good if the site could maintain the last seven days builds, then Friday builds for two months (eight), so if there are suspected anomalies, tests could be made by rolling back to an earlier version.

Could something along these lines be added?