Any updates about RiscOS on the Raspberry Pi?

ending up copying some variant of the RunMe script you have already created

Yes. You’ll note that the RunMe script (which also works for the Pi) is a bit long winded – all the extra faffing is to get the !Boot structure in the RAM disc ready for instant networking (booting from RAM you only get one go at it!). It would be a lot shorter without the networking bits.

It would be a lot shorter without the networking bits.

In theory I could generate the Network config files on the RPi whilst setting it up for RISC OS, then the ‘RunMe’ script just needs to copy them into the right place in RamFS after extracting the HardDisc image. That would simplify it quite a bit.

I’ll be talking through this at ROUGOL next Monday

Leo, do you think there could be any aspects worth making a photographic record of, for inclusion in an installation guide? Or is the current procedure likely to be superseded in the medium term?

I could generate the Network config files on the RPi whilst setting it up for RISC OS,

True but only after you have a working !Boot structure. My approach is very much chicken and egg – start with a FAT formatted (unbootable) pen drive, put the boot structure into RAMFS and modify it for networking (all using a simple command to invoke ‘Exec RunMe’) and then boot from it (by using ‘*Run !Boot’).

Clearly you could copy the ‘HardDisc4/util’ file to RAMFS and expand it to generate the HardDisc image in RAMFS, (which is then a ‘vanilla’ boot structure) go through what are then complicated instructions (for a new user) to set up networking (which generates these files in rather obscure places inside !Boot) format a pen drive under RISC OS and copy all the stuff to it, make it bootable and boot from it.

Leo, do you think there could be any aspects worth making a photographic record of, for inclusion in an installation guide?

That rather depends how much can be automated! With my current ‘manual’ setup instructions then some photos/screenshots would be useful. If we can automate the setting up of Linux RISCOS then the only ‘manual’ step will be the user running HForm, formatting their USB disk, and then copying the contents of RAMFS to ‘HardDisk4’.

Does the RPi ROM image look for a file ‘cmos’ on the SD card for initial configuration? Alternatively is the packaged image file such that it contains both the rom image and the cmos settings?

Does the RPi ROM image look for a file ‘cmos’ on the SD card for initial configuration? Alternatively is the packaged image file such that it contains both the rom image and the cmos settings?

CMOS on the RPi is still being discussed.

I have put together a boot structure with the networking bit added and an automated start up script so that a Raspberry Pi can be booted up easily.

These two files:
Run_Me
HardDisc4.util
should be put onto either a FAT-formatted pen drive (of up to 2Gbytes in size) or the SD card and when RISC OS boots up into the Supervisor prompt select either ‘*SCSI’ or ‘*SDFS’ as appropriate and then type:
‘*Exec Run_Me’
and RISC OS will start up in the desktop with fully functioning DHCP networking with the boot structure in the RAM disc.

Once the SDFS is working this will allow a fully functioning RISC OS desktop with a full boot structure and working networking with no external storage connected other than the SD card itself and with RISC OS running with no further dependence on the SD card being there.

Note: this isn’t as good as having a RISC OS formatted pen drive acting as the boot device but is intended to allow a single SD card image to be all that is required to run RISC OS so that a user might try it easily.

Note: if no network is connected then you will need to interrupt it (using the Escape key) while it is waiting for a DHCP address (showing the line ‘Contacting DHCP server …’).

We’ve put a first spin of the RPi SDFS stuff into CVS so it should be included in the autobuilder ROM image tomorrow am. BE WARNED there are known issues with certain SD cards (about half of the large pile we bought for testing). We’re still trying to figure it all out and it’s looking more like problems with hardware/silicon.

See these comments for some background and a bit more detail in Ben’s commit logs.

I’d like to remind everyone that the intention of the RPi ROMs being on our site is as a convenience for the small group of developers and helpers we have trying to finish the port. These ROM builds are ALPHA (yes, all-caps) or possibly even pre-alpha quality! DO NOT BE SURPRISED OR COMPLAIN TO US IF BAD THINGS HAPPEN WHEN YOU USE THEM!

Footnote: we may create a wiki page of SD cards that we know to work OK and other cards that seem to be unreliable. We’ve tested the same pile of cards on the Beagleboard sending the same sequences of commands to them and they all work perfectly, so we know it’s not the cards.

may create a wiki page of SD cards that we know to work OK and other cards that seem to be unreliable.

Are the problems specific to RISC OS? Or are the cards the same ones which are problematic under Linux, due to the Broadcom bootloader? If so, then mightn’t it be more help to the larger RPi community (and eliminate duplication) if the issues are added to the elinux.org wiki instead, with a link to that from the ROOL wiki?

Well a Sandisk Extreme III 2Gbyte card seems to work correctly. It shows as option set to 2 (Run) but I haven’t booted directly from it as the default filesystem is ADFS. However if I type ‘*SDFS’ and then ‘*Exec Run_Me’ it puts a boot structure into RAMFS and boots up with networking working etc.

It starts up like this (this takes 6 seconds from power on)

(full screenshot here )
and then typing

*sdfs
*exec run_me

Incidentally an 8Gbyte SD card ‘CnMemory’ (as sold by Maplin) does not work…

Now all I need to do is to work out how to tell the system that the default filing system is not ADFS but either SCSI or SDFS…

I have added an obey file ‘!Boot’ to the SD card containing the line ‘*Exec Run_Me’ so it all starts up now if you type the commands

*sdfs
*run !Boot

I think the “default” CMOS is stored in mixed.RiscOs.Sources.HAL.BCM2835.s.CMOS as DCD lines, and is read by mixed….s.Stubs HAL_NVMemoryRead, so just set/unset the bytes needed there and recompile.
I think you will also need to set the default language byte as the desktop module.

Working correctly using a Transcend 4GB SDHC card

Although RISC OS on the Pi is still really ‘pre-alpha’ you can see what a RISC OS distro might look like. This is a zipped 2Gbyte SD card image which is just 38 Mbytes in size and should be unzipped (using WinZip or 7zip) and then written to an SD card using Win32DI.

The Pi should then start up in RISC OS command line within 6 seconds from power on.

The code within RISCOS which operates the SD Card filing system is rather new and only works with some cards (hence the ‘pre-alpha’ warning) but if you choose the right card then you can type:
*SDFS
*Exec Run_Me
and you will get a fully functioning RISC OS desktop with working networking (using DHCP) after only another 20 seconds with the necessary boot structure held within the RAM filing system.

This is really just an unofficial taster as the bottom 5% of the screen is currently cut off (this is being worked on) and the desktop display is currently fixed at 1920×1080 so you need a monitor that can display at that resolution. Also there’s no tutorial yet but there is a little free software.

Here’s the pre-ALPHA distro (38Mbytes)

Have fun!

If we can automate the setting up of RISCOS

Well I’ve now put together a script that can be run on a ‘Vanilla’ RPi (i.e. one running the debian distribution) and that will download and setup everything needed to launch into RISCOS and boot from RAMFS (including copying the MAC from Linux and setting it as part of the Boot sequence).

In theory it works with both SD cards and USB flash drives, although all the SD cards I have tend to lock up when copying large files (Such as the HardDisc4/util file).

I need to add some extra logic and error checking to the script, but hopefully I’ll be able to upload it somewhere today, and will be using on Monday at ROUGOL (assuming the Wifi is working there)

Wouldn’t it be easier to just use the ‘2 partition’ method? Just write the image and away you go. No setup instructions, no scripts to run, no ram disc to set up, permanent storage and it will boot up in less then 10 seconds.

Wouldn’t it be easier to just use the ‘2 partition’ method

That probably depends on what you want to acheive. I’ve not yet gotten the ‘2 paritions’ method working yet myself, the required image for it is not (as far as I’m aware) updated every night with the latest build (which may or may not be a problem), most of my SD cards don’t seem to work 100% with the RPi/SDFS, and with the script method you can very quickly switch back to your existing Linux setup if you want to just by deleting the config.txt file (Which may be useful if you just want to ‘try out RISCOS’)

And more importantly (at least to me) I started writing the script before the ‘2 partition’ method was mentioned, and as I’m going to be demoing this at ROUGOL I’d rather use something I understand in case it all goes horribly wrong (which it usually does!) and I have to start prodding things.

That probably depends on what you want to achieve.

I was thinking of more in line with what exists already on the download page on the raspberry pi site. The RISC OS image could be just another distribution download.
Download it, write it to a blank SD card. Plug it in, wait a few seconds. The RISC OS desktop appears…

I really hope that nobody is suggesting that people in general “just try out RISC OS” with the Raspberry Pi port in its current state – it’s not going to give anyone a good impression at the moment. I’ll repeat again what Steve said, that the current builds are only really intended for the convenience of the group of developers involved in the bring-up process. I can understand that everyone is enthusiastic to run full disc images on Raspberry Pis, but I fear we’re getting a little ahead of ourselves here. It’s not just SD data transfers that are flaky at the moment, so we can’t rule out something else on the system from being responsible for at least some of the instability. And there are whole chunks of basic functionality, such as sound, variable resolutions or hardware cursor, that haven’t even been started on yet. One rule of thumb for development is that the last 10% of the work takes 90% of the effort – what you’re seeing is SD support at that 90% point. I held back on releasing the OMAP3 version until I was satisfied that it was stable, I hope I’m not going to regret doing an earlier release for the Pi version :(

Leo, I can understand that you’ve got the ROUGOL demo (tomorrow I think?) so you’re under a lot of time pressure. Using RAMFS is a neat way to get round current limitations elsewhere, but I hope you’re not expending too much effort on it and won’t be offended if we go in a different direction longer-term.

I really hope that nobody is suggesting that people in general “just try out RISC OS” with the Raspberry Pi port in its current state – it’s not going to give anyone a good impression at the moment

Oh I agree fully with that.. I was more referring to reasons why an alternative method to flashing a new SD card might be useful, not suggesting that the current release is anywhere near production level.

Hmm, maybe I should change the background on my RPi to have ‘pre-alpha’ written across it, just to get the point across!

It’s not just SD data transfers that are flaky at the moment, so we can’t rule out something else on the system from being responsible for at least some of the instability.

Trying to build the ROM on a USB HDD tends to cause numerous lock up on the RPi, so its definitely not a SD specific issue. Luckily my Iyonix is stable enough to do a ROM build, unfortunately it locks up when ever reading/writing to a USB flash disk so I have to transfer the new ROM via the network…

I held back on releasing the OMAP3 version until I was satisfied that it was stable, I hope I’m not going to regret doing an earlier release for the Pi version

I wasn’t expecting to see SD support on the RPi until mid-July at the earliest! I suppose the RPi build could be changed to not include SD support by default, but I’m sure that will annoy someone.

Personally I’m more interested in running RISC OS on the 128GB SSD disk I picked up cheap at PCWorld this weekend…

Leo, I can understand that you’ve got the ROUGOL demo (tomorrow I think?) so you’re under a lot of time pressure.

Yep its tomorrow, although technically I’ve not explicitly told Bryan I would actually do a demo.. Of course he might get a bit upset if I didn’t do one now :)

Using RAMFS is a neat way to get round current limitations elsewhere, but I hope you’re not expending too much effort on it and won’t be offended if we go in a different direction longer-term.

Not at all. When I started thinking about the ROUGOL demo SD support wasn’t even in RISCOS yet, and it certainly wan’t in the RPi build when I started putting a script together. So RAMFS was the only sensible way to go, and even then the first thing I would normally do is format a USB HDD, copy the contents of RAM to the HDD and then reboot!

Considering how cheap a smallish SD card is these days, writing a self contained RISCOS image to one would be the most painless way to do it. It also makes the best use of the restricted resources (losing half you memory in a RAM disk isn’t that desirable).

It’s not just SD data transfers that are flaky at the moment, so we can’t rule out something else on the system from being responsible for at least some of the instability.

Fair enough, but come September IMHO even a (non-pre-) alpha or beta release could be useful for teachers, after-school club organisers etc. even if explicitly not recommended for general use.

Regarding the later stable release(s), what about testing? R-Comp tests the stable BB ROM, but AFAIK there isn’t an obvious equivalent for the Raspberry Pi.

Just built a ROM that auto boots from a SCSI disk.
The Pi build is not setting the M_CortexA8/M_CortexA9 switch so is using ADFS as the default file system in Kernel.S.NewReset, so just set the other default as SCSI as well to test.
It seems it is not reading the CMOS values for its start-up, so is defaulting.

Guys, it’s great to see you all chipping in and feeding back your ideas and findings. Keep it up!

I just want to clear up one point though; ROOL (and various developers who are assisting in this work) aren’t just working on a RISC OS port to the RPi (a ROM image) – we’re working on the whole thing. That includes the ROM image, how CMOS works, how any third-party real-time clocks work, the boot sequence, the rest of the disc image, adding third party tools and applications, even down to the precise format of the image on the SD card. We’re doing this so the Raspberry Pi Foundation have a RISC OS SD card image ready for release – with the aim of finishing everything to a level where we’re happy with it before September.

So while your trials and tribulations with disc images and SD cards are very useful feedback to us, please don’t think that we’re not working on those aspects too… :)

The Pi build is not setting the M_CortexA8/M_CortexA9 switch so is using ADFS as the default file system in Kernel.S.NewBoot, so just set the other default as SCSI as well to test.

Can’t find Kernel.s.NewBoot – it isn’t in $.RISCOS.BCM2835Dev.castle.RiscOS.Sources.Kernel.s.

Any suggestions please where the default filing system number is located within the source tree?

See this topic for the information you need.