RISC OS on the Raspberry Pi

There currently appear to be several dicussions floating around regarding the Raspberry Pi. As has been suggested, I’d like to bring these together to a more central place. Hope that’s okay with everyone! Since this won’t be limited to the technical aspects of porting RISC OS to new hardware it’s probably better suited to this sub-forum.

Should some of the tasks Theo referred to be included on a new wiki page? e.g. Raspberry Pi Roadmap or similar

Porting Scratch to RISC OS for Raspberry Pi
(Original post on csa apps)

Dear All,
I’m interested in supporting the programming environment Scratch
on RISC OS with an eye on the Raspberry Pi.
I’m hoping to find someone interested in the ‘few hours work’ needed
to port it across. What follows is a description of what is likely to
be
involved kindly provided by- Jecel Mattos de Assumpcao Jr
(Merlintec Computers Ltda and Squeak Oversight Board)
Jacel writes…

I enjoyed your report about the 2011 RISC OS London show
http://www.riscoscode.com/Pages/Item0113.html
and have some information about this part:
“What a great start to the day. I’d managed to interview Theo
Markettos
and tweet the interview as it proceeded. Theo is a postdoctoral
researcher at Cambridge University. Although he has no formal direct
connection with the Raspberry Pi foundation he shares offices at the
University with people who do. Keen to make the point that any views
expressed today were his rather than Raspberry Pi’s he none-the-less
has
an impressive grasp of both the Raspberry Pi and RISC OS. I spoke to
him
at the Raspberry Pi stall where he presided over the precious alpha
developbent boards one of which was running a software authoring
package
for primary school kids called Scratch. As this is not available for
RISC OS it prompted me ask Theo if he thought RISC OS software was up
to
the job of appealing to users of Raspberry Pi.”
Scratch is built on top of Squeak, which runs on many different
platforms. One of those, up to Squeak 3.8 in 2005, was RISC OS.
Unfortunately, Tim Roledge (http://www.rowledge.org/tim/) had been
single handedly keeping this port updated and when he moved on to
other
things nobody replaced him in keeping Squeak current on the RISC OS.
On the other hand, Scratch is built on a much older version of Squeak
(version 2.8 from 2000) so it should only take a few minutes to get it
mostly running on the RISC OS by combining the Virtual Machine from
Squeak 3.8 (ftp://ftp.squeak.org/3.8/riscos/ in the either the basic
or
full version since the VM is exactly the same in both) with all the
files except the VM from
http://info.scratch.mit.edu/Scratch_1.4_Download (the version for any
of
the operating systems will work fine since its executable will not be
used).
Now the reason I said it will mostly work is that the standard Squeak
VM
doesn’t include the special Scratch plug-in, which would have to be
compiled from the sources available at
http://info.scratch.mit.edu/Source_Code (but while some features
don’t
work without the plugin, the basic system does work).
In short, having Scratch fully working on RISC OS is less than an
hour’s
work for someone who knows what they are doing and a few day’s work
for
someone who doesn’t. It certainly is not a reason to not have RISC OS
on
the Raspberry PI.
My best regards,
— Jecel Mattos de Assumpcao Jr
Merlintec Computers Ltda and Squeak Oversight Board
I’m looking into projects for which small amounts of work bring back
quick results, and this one seemed quite promising.
You can get my email from Google or visit the RISCOScode website
or use @RISCOScode on twitter.
Regards,
Martin.
http://www.RISCOScode.com

It seems to be reasonably simple to get Scratch working in some way, although whether it’s useful or not is another matter,

Download the Squeak archive from here and extract the !Squeak application to some convenient directory.

Download Scratch for Windows from http://download.scratch.mit.edu/WinScratch1.4.zip and again extract the archive contents to some convenient directory.

In the Scratch directory there is a file called Scratch/image. Set its file type to FAA (STimage).

To start Scratch, double click Scratch/image.

When it starts, it displays an error (inside the Squeak VM) saying a primitive has failed. More seriously, trying to open a file also gives an error.

I’m not sure if this is due to the lack of plugin, or filename incompatibility or what … I’ve had a look at the plugin code – it’s in C but it looks like it should be compiled as a shared library under unix. There’s a plugin directory inside the Squeak application, but the files in there are not AOF executables. Whether you need some other Squeak based compiler or something to make a plug in, I am not sure.

Hi Rik,

>> It seems to be reasonably simple to get Scratch working in some way,
>> although whether it’s useful or not is another matter,

It seems to have quite a lively online community associated with it.
And some of it looks very child friendly, which seems to be where the Rasapberry Pi is headed.
For an example of a Scratch project, see,
http://www.digitalschoolhouse.org.uk/staffzone/post-lesson-resources/control/scratch-maze
I guess it depends on how well the RISC OS version would work as to if it’s worth trying
to then p[romote it. I wouldn’t want folks to try it out and immediately think the Linux
version is better which would be counter productive from the RISC OS point of view.

Is Tim Rowledge still around ?
I tried to find his email address but failed.

Regards,
Martin.

Is Tim Rowledge still around ?

http://www.rowledge.org/tim/personal/cv.html

when he moved on to other things nobody replaced him

"There is some faint activity around RISC OS and the rather nice BeagleBoard hardware so perhaps it will eventually be worth building a VM for that."

PS Martin, great idea submitting to OSnews in the first place :-)

[Edit: (Moved from “Yet another potential RISC OS target?”) Under what license are our contributions made on this wiki?]

OK, before we get sidetracked into discussions of specific projects, can we start thinking about what needs to be done for a Raspberry Pi release:

Kernel/ROM image

• USB driver
• SD card driver
• Partition support
• Audio driver
• Nicer default toolsprites/backdrop/etc
• Accelerated !Boot

Disc image

• Popular RISC OS apps ready configured
• Programming tools
• Educational software

Materials

• User documentation/videos/etc
• Programming guides
• OS documentation
• Non-RISC OS software/guides (eg how to use RPCEmu, GCCSDK)

Process control

• Legal/licensing checks
• Software compatibility testing
• QA/release testing
• Application source code collection (for that which is available)

Bold=essential, underline=important

Those are just off the top of my head. No doubt I’ve omitted a hundred things, please follow up with other thoughts. I’ll wikify them as we go along.

A few of the driver tasks can only be done by people with access to boards, the rest can be done by anyone.

A couple of other comments. Linux RPi depends a lot on the SD card speed. RISC OS currently has very fast boot, because there’s no !Boot structure. I’m a bit concerned that the standard !Boot will make it slow again. So might be worth thinking how we can accelerate the boot sequence: either push more into ROM, or otherwise prevent lots of single-block reads from SD. FS caching, boot from ramdisk, rationalise the !Boot sequence, something else?

On the documentation side, there’s an awful lot out there (eg hundreds of magazine articles) but it needs some substantial pulling together (and possibly tidying the obsolete stuff). Plus getting permissions that they can be published.

In legal I include securing RISC OS licensing and checking the licences of everything that we distribute.

If we can start working out what needs to be done, then we can prioritise what’s important for a release and what can be done later.

How about Ethernet / networking?

The boot structure can be solved (at least initially) by using RAMdisk for the boot structure (see other thread). Then dependency on SD drivers for speed is removed. Cuts down 256Mbytes to about 180Mbytes for available RAM.

Licensing so that a free copy can be bundled with Raspberry Pi is essential. Somehow we need to find a way of migrating any new users onto commercial licensing payments. But then new users will want bigger hardware where there is a margin for such payments.

Ethernet is said to be ‘ready to go’ as soon as the USB stack is working.

Ethernet comes ‘for free’. EtherUSB already supports the LAN9512 chip, so once USB is working Ethernet should work straight off (touch wood).

RAMdisk for !Boot sounds like an idea – it needs some careful design so that writing to !Boot (installers, Choices$Write, etc) goes to the SD copy not the RAM copy. Post-boot rewrite of all Boot$ system variables, perhaps?

Ideally a RAM disc cache would be slightly cleverer than just copying the files off the SD card (after all, that’s what !Boot does and it’s slow because there are lots of one-sector reads). So perhaps !Boot could be held in some kind of archive that can be grabbed wholesale, or the RAM disc could reconstruct a SD Filecore FS where blocks are allocated close together, or something else…

Kernel/ROM image

• Save state/suspend to disc?
• ROM apps to be Style Guide compliant

Disc image

• Ditto for bundled apps
• Quicker setup of time/date¹, e.g. picker rather than bump arrows
• Online help
• Consistency/improved use of drag and drop between apps²

Re: Educational software – Which publishers are still around?

Over to you for priorities/strikethroughs.

¹ No RTC with current versions.

² I’m pretty sure some examples can be given, so will check this.

RISC OS currently has very fast boot,

Is it quicker than the BeagleBoard? The default setup there waits 10secs for the user to intervene IIRC. Is there anything which could be usefully migrated from swiftbeagle?

Two things spring to my mind which others may or may not find helpful. Firstly could the read only SparkFS help with speed of booting from the SD card? Secondly if it were available would the CacheFS module as used in the Bush Internet TV be any use for !Scrap so it doesn’t hammer the card or hog too much ram?

RTC is another big issue I hadn’t thought about. There’s no hardware on RPi for it (well, I have no idea if there’s a soft RTC on-chip but there’s no battery)… so I suppose NTP is the only way but that requires network. Perhaps default to 1/1/2012 not 1/1/1900?

RISC OS on RPi with no disc is essentially instant, at least to the supervisor prompt. If there was CMOS RAM (ah, another thing that needs sorting) to hold the configured language (or it was hardcoded), autoboot into desktop would be <3 seconds I reckon. There’s no bootloader menu, the boot OS is determined by whatever is on the SD card. Swiftbeagle gives some useful general ideas (don’t fetch more disc than you need, compile things to be small, compress, etc) even though the specifics don’t apply.

I’ve just created the roadmap wiki page that Trevor linked to with these ideas. At the moment I’m trying to be realistic – timescales are pretty short – so I’m trying to focus on necessary stuff rather than things that would be nice to have given an infinity of time and developers. For example suspend to disc is a really hard problem, and even Linux haven’t got it completely right, so I think doing it in 2 months is going to be impossible.

Read only SparkFS might be interesting… I wonder if it does prefetch caching? CacheFS might be interesting for Scrap… but does Scrap get used enough to be a performance hit?

How many RISC OS developers have access to boards, or at least hardware documentation? Because if it’s just Adrian (and he’s doing it in his spare time) then I suspect you’re expecting a bit too much out of him if you want the “essential” items to be done by Christmas (although he’s welcome to prove me wrong!)

If the USB driver is based around the Linux sources then it’ll need a fair bit of poking in order to get it to work cleanly in RISC OS’s butchered NetBSD stack. The SD card driver (and the CMOS RAM code, assuming we go with the approach of saving to the SD card) will also need lots of hands-on time with a board in order to make sure that it’s working properly (or to get it working in the first place). Partition support won’t require access to a board, but if it’s going to be done properly then it’s a big task, hence why it’s on Sprow’s filesystem bounty list.

Also, you might want to change your wiki link to this, as the link you’ve currently got takes you to the “create new page” page!

• Accelerated !Boot

Could it also be made to work properly read only? (i.e with external !scrap and !choices, configurable to be autocreated in the RAM disk).

This would allow a complete working system with either no SD driver (!boot in resourses) or a read only driver.

trying to focus on necessary stuff

Yes, some of the other things are really Wish List items.

CacheFS

"It deletes the older stuff" – is this true? (Maybe refuted later in the thread, but if so I’ve missed it.)

access to boards

There should be 10 000 available by Christmas, but they’re not taking preorders so people will have to be quick! Probably following Raspberry Pi on Twitter is a good idea. (But if each of the currently approaching 5000 followers opts for the buy-one-give-one scheme does this mean they buy two each… or is it buying one for twice the price?)

Partition support […] Sprow’s filesystem bounty list

It’s Step 2, and “just” Step 1 is a long way from being started. Therefore, some extremely wealthy donors are sought!

Adrian and I have access to boards. He’s working on the USB stuff, which he says will take him a while. SD card be prototyped on a Beagleboard (or indeed a PC laptop with the right sort of SD slot), if it’s written in a sufficiently portable manner – they all use the SDHCI standard – RPi specific tweaks can be sorted once the basic driver is working.

In terms of initial-build supply, it’s possible we may be able to get access to a few boards from the initial batch that are held back for developers (no promises). But when the first batch is available I recommend piling into the queue anyway.

I realise that full partition support is a bit optimistic, but some kind of support is required because a FAT partition is used by the bootloader. Perhaps an SD driver that parses the DOS partition table and picks the first FileCore partition? (Does FileCore even have a DOS partition ID? Or how else to recognise it?)

Wiki link fixed :)

Educational software

This post by trustee Jack Lang (who worked at Acorn) is probably worth noting.

SD card be prototyped on a Beagleboard (or indeed a PC laptop with the right sort of SD slot), if it’s written in a sufficiently portable manner – they all use the SDHCI standard

Ah, that’s good. I wasn’t sure how standardised the SD controller host interfaces were.

I realise that full partition support is a bit optimistic, but some kind of support is required because a FAT partition is used by the bootloader. Perhaps an SD driver that parses the DOS partition table and picks the first FileCore partition? (Does FileCore even have a DOS partition ID? Or how else to recognise it?)

I think the safest bet would be to make the SD driver parse the partition table and look for a FileCore partition. That way you’ll be future-proof for when full partition support is added.

FileCore currently doesn’t have a DOS partition ID (AFAIK!) so you’d have to invent one.

This link might be useful: http://www.win.tue.nl/~aeb/partitions/partition_types-1.html

A while ago I asked the maintainer of the site what the procedure to register new types is. Apparently there isn’t one, and the best bet is to pick an unused one and email him to add it to the list.

The Castle Storm SCSI card has some support for partitions, could ROOL perhaps see if Castle could add its sources to the RO 5 sources. (However from memory, I don’t think it created a filecore entry, it just created the first DOS partition at the end of it, which I don’t think is ideal)

RTC […] NTP

Is it possible to save the time via CMOS (or via a custom file)? If the time were to be saved on shutdown (and, possibly, every hour too) this would be an enhancement over 1/1/2012 on next power-on.

An (optional) boot-loaded app could then:

• Wait a minute or two for any NTP (or user, perhaps via Alarm or otherwise) change to the time (maybe amending NetTime to notify somehow would be preferable to regular checks, or perhaps minimal overhead to check every 10/30 secs);
• If no change, issue warning to user that time may be incorrect, giving options like “Set manually”, “Keep checking” and “Ignore”;
• Quit after time has been reset (either by user or NTP).

Ah, that’s good. I wasn’t sure how standardised the SD controller host interfaces were.

They seem to be fairly secretive about the standard, but they can all be driven from the ‘sdhci’ driver in Linux so I think that’s a fairly good sign. The underlying transport mechanism might vary a bit (eg use of DMA) but that can be handled when most of the driver is written.

FileCore currently doesn’t have a DOS partition ID (AFAIK!) so you’d have to invent one.

0xFC (‘FileCore’) seems to be taken, so maybe 0xACorn or 0xADfs…

I’d be interested in helping build a list of apps and programming tools to be included. Would the best approach be to create a Wiki page pointed to from the one which Theo has created? We could build up a categorised list there, including links to the downloads, licence checking, compatibility checking, etc. How does that sound?