Any updates about RiscOS on the Raspberry Pi?

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

All of the various SanDisk models seem confusing. The Ultra card works, my “Extreme HD video” does not, and a friends’ borrowed “Extreme III” works very well. Mine and his cards are 4GB and so SDHC too (and I think they’re both class 6).

Do you/does anyone know if the generic SanDisk card works okay? £13 for 2GB is a bit steep, and the generic SanDisk 2GB is more like £4.

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

I wonder if this is similar to the problem I experienced with my Beagle? I’m waiting for Joe to tell me he popped in a uSD and it booted just fine. ;-)

To be honest, I don’t quite understand why these devices have so much difficulty, given any cheap generic digital camera (etc) accepts plenty of different sorts of (u)SD cards without freaking out. Is it really so hard to locate a file in the root directory of the media and then load it especially when that is how your device is supposed to boot?

My experience is that deleting files on or writing files to the SD card can sometimes cause corruption whether under Linux or RISC OS. Part of the problem seems to be that there is more than one file allocation table on an SD card and different computers/operating systems seem to be inconsistent in which they use for some purposes. Presumably one FAT is supposed to be the ‘master’ and one a ‘consistency check’. While they agree things seem to work OK.

The other complication is the access of the SD card under RISCOS whilst the SDFS is under development and known not to be working correctly with most SD cards. This only matters for RISC OS if you have the boot structure on SD card rather than pen drive. It is also a temporary thing while the SDFS is developed further.

Cameras use an SD card but have a propriatory formatting/partitioning image designed to optimise the type of access required by the camera. Expensive cameras (with video recording etc) need fast and expensive SD cards.

Confining the SD card to read operations only would be a ‘solution’.

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?

Sorry, that was a bit vague from me. Using the BCM2835Dev5.19 kernel the Pi boots straight to the RISC desktop without any difficulty, and i can read and write to the SD Card. The DISTRO version (18/06/2012) works well with the Toshiba card (gets to desktop and allows writes) , and sporadically with the 2gb SanDisk card.

It strikes me that perhaps the problem with the DISTRO version stems from the way the image is unpacked, rather than the SD card?

For anyone experiencing issues with the USB drivers: I’ve just submitted some changes that should help improve stability. My test script (which just reads files over ShareFS at 1 second intervals) has been running for about 24 hours now without encountering any problems. I’m now moving on to testing at higher transfer rates, and if that works OK, I guess I’ll have a go at coming up with a new test, to see if there are any bugs hiding elsewhere.

Posting from R-Pi

Kodak branded SD card works fine
Kingston 2gb – hangs loading !boot
Patriot 8gb SDHC (class 6) – read error on change dir

I’ve been playing with RISC OS on R-Pi for about 2 weeks. Started using dev ROM image on site with USB pen drive for disk space. I know have it running fully SD card using linked image. I did get the rainbow square – which I have solved by dropping in a cmdline.txt file, and it is able to find the kernel now.

I am in North America, and have never seen RISC OS in action before getting a Pi. I am fully aware that the system is alpha, and has incompelte, broken, and missing functions. Taking that into consideration inital thoughts on the system:

• BBC BASIC is fantastic.

• Not making the OS look like yet another Windows XP dekstop clone is awesome. Please don’t do this. The Iyonx jellybean logo should however either be replaced with either the RISC OS logo, or one appropriate for the system being run on.

• One thing I did find counter-intuitive is resizing a zero-sized RAM-drive. I would suggest that it should have a zero width outlined rectangle when unallocated, as well as changing the mouse pointer that it can be resized.

• The anti aliasing in the System is really good.

• Quick booting is awesome.

• The system is quite a bit different than the more familiar Unix commands, and could use some more intro documentation. I was able to figure it out mostly fromt he dev docs, but a tutorail like intro would be helpful.

So far I have got Netsurf, Zap, StronHelp, Photofilr, PDF, PrivatEye, Sanpper, OpenGrid and Vector working. I was also able to write a good
start to yet another Space Invaders clone in BBC Basic very quickly. I know I said it earlier but BBC Basic is really good.

I have not been able to get gcc working, though I have ordered the DDE, and would rather use it anyways, as gcc is rather clunky and bloated. I have also not been able to get Nettle working (complains about Socketwatch – not sure how to fix). Cretin seems to be causing a segmentation fault, I believe this in in raise_signal from UnixLib. FTPc also crashes on “task unknown”, looks to be in shared lib but not sure from it’s postmortm dump.

I have quite enjoyed trying out the incremental improvements of the system, and am looking forward to it really being ready. Overall the system is well designed, small, fast, and developer/hobbyist friendly.

Very useful insights :-) It’s great to hear some fresh opinions from across the pond!

On the off chance that someone/people may feel like working on some new RISC OS marketing material in the future, how would you feel about being quoted on any of the above?

I have no problems with that.

It strikes me that perhaps the problem with the DISTRO version stems from the way the image is unpacked, rather than the SD card?

I unpack it using WinZip and the 24Mbyte download becomes 240Mbytes (because most of it is just a blank disc). I doubt that this step is the problem but it is easily checked – it should be &EE80000 in length and if we can agree on a CRC checking programme, I can give the expected CRC of the 23 Jun 2012 image.

For example, using this the (current) 23 Jun 2012 image file ‘RISCOS_Alpha_23Jun2012.img’ gives a CRC value of 7AF1A893

Michael:

Welcome!

A group of us are working on the tutorial you mentioned as we totally agree with you that it is vital for a complete newcomer to the Operating System – most of the increase in the userbase over the last couple of years has come from returnees.

Could you send me an email to keith dot dunlop at usablerange dot co dot uk – I want to get you, if you don’t mind, to have a look at the tutorial as none of us are complete newcomers and as such we would really value your input.

I look forward to your response.

Chris, I recommend MD5 or SHA1 as the standard way of making hashes across many platforms. For RISC OS there’s md5sum and sha1sum in the coreutils package on riscos.info.

I make the MD5 sum of RISCOS_Alpha_23Jun2012.img to be:

c0a303a940a7720fb16a15bf8246c1b0  RISCOS_Alpha_23Jun2012.img

My calculation of the checksum is:
*md5sum RISCOS_Alpha_23Jun2012.img
c0a303a940a7720fb16a15bf8246c1b0 RISCOS_Alpha_23Jun2012.img
so we agree. That’s that one nailed.

A group of us are working on the tutorial you mentioned as we totally agree with you that it is vital for a complete newcomer to the Operating System

I have some expertise in commenting on others’ documents – I spent a career doing it and so if you want a very thorough check of what you have said and whether it is clear or ambiguous/unclear please let me know.

For anyone experiencing issues with the USB drivers: I’ve just submitted some changes that should help improve stability.

Its looking good here. I’ve now managed to successfully build the RPi ROM on my RPi in a single attempt (Using a USB HDD), Previously it would lock up at least 10 times during the process, so thanks for that!

The only issue I did run into (There’s always one!) was that I had to comment out an ‘IconSprites’ call in the ‘Env.!Common’ file as the Sprites file couldn’t be found and an error was thrown. This used to work without the error and I assume is related to some of the other changes that have gone in recently.

[…] new RISC OS marketing material in the future, how would you feel about being quoted on any of the above?

I have no problems with that.

Great! You’re on the list! Thanks :-)

The version of ‘tar’ included in UnTarBZ2 is from a third party port of ‘tar’.

It seems that this version of tar doesn’t support the GNU ‘LongLink’ extension, so file names get truncated at 100 characters or so.

Forcing the tar format at creation to ‘ustar’ gets around the above, but testing it here it seems that any file who’s filepath is over 100 gets dumped out into the working directory instead of where its supposed to be.

So I guess the next steps would be to either change the server to create tar files in ‘ustar’ format and fix the bugs in the UnTarBZ2’s implementation, or look at adding support for the ‘LongLink’ extension.

Thoughts?

Good news! Chris’ image from yesterday (RISCOS_Alpha_25Jun2012.img) works! I think the issue was that they were missing pullups on the bootcode.bin and it was causing flaky SD access when loading subsequent images — I guess the 25Jun image refreshed the firmware including bootcode.bin Phew!

That’s fantastic news Winston. I will try Chris’ new image tonight too.

2 questions on my mind:

1 – does this now kill the issue of reliably reading and writing to the SD card – so we can use SD for both bootstrap and !Boot structure/basic file store?
2 – does this reduce/eliminate the incidence of Rainbow Square of Death???

@Alex, It is my understanding that the pull ups on the SD card are configured in software by the GPU and that each of the phases during boot are supposed to set the pull ups, it seems that bootcode.bin wasn’t setting them which made subsequent SD card access unreliable. My guess is that the RPi folks decided to use the software pull ups for SD card access as it would remove the need for SMD resistors to be added to the data lines. Some folks on the RPi forums had added their own pull up resistors, others had reported at placing your finger across the data lines “solved” the issue, presumably by pulling the data lines high via your skin!

So I believe it DOES resolve the Rainbow Square of Death and from the RPi forums, it seems that it has fixed the issue for many people. However, I don’t believe it changes anything with regard to the reliability of SDFS (it’s alpha still), unless there’s something RISC OS needs to do w.r.t. the pull ups.

I would be very interested to see if the new distro solves the RSOD issue for others who have had it.

@Leo

It seems that this version of tar doesn’t support the GNU ‘LongLink’ extension, so file names get truncated at 100 characters or so.

That’s odd, because the bootcode.bin in the 23Jun2012 image had the pullups enabled. I grabbed a fresh copy off github yesterday and compared md5sums. Did you try 23Jun or were you working from an earlier version?

That bootcode.bin did remove my Linux boot errors, but not improve the behaviour of SDFS (which is somewhat non-deterministic).

@Theo, I did not try the 23Jun version, I saw the comments about the md5 hash so I decided to try it out yesterday since I could verify what was on the SD card, but Chris had updated it already.

As for SDFS, is the non-determinism beyond any alpha-release type issues? Perhaps RISC OS also needs to set the pull ups for SD card access …

The SD card that I am using here that is now working (but did not before) is a Sony 4GB SDHC class 4 (model SF-4C4?)

Also, for anyone who’s trying to verify the MD5 hash of the image vs the SD card, this is how I checked it (on a Mac, with the LOCK switch enabled on the SD card):

# First verify the MD5 hash of the image
$ md5 RISCOS_Alpha_25Jun2012.img MD5 (RISCOS_Alpha_25Jun2012.img) = 283240ae48786542ab4e12cc01b300a5

# Next, use dd to read blocks from the SD card into md5
$ dd if=/dev/rdisk9 count=488448 bs=512 | md5
488448+0 records in
488448+0 records out
250085376 bytes transferred in 185.273406 secs (1349818 bytes/sec)
283240ae48786542ab4e12cc01b300a5

Note that on a Mac, you may see a different MD5 hash because diskarbitrationd will auto-mount the SD card once you’ve written it and sprinkle it with hidden files such as .DS_Store, .Trashes, .fseventsd etc. You can stop and start diskarbitrationd so you can cleanly write and verify the SD card as follows:

# Find the pid of diskarbitrationd
$ ps -ef | grep diskarbitrationd
...

# Suspend diskarbitrationd
sudo kill -STOP <diskarbitrationd_pid>

# ... write SD card, verify ...

# And re-enable it
sudo kill -CONT <diskarbitrationd_pid>

NOTE: diskutil will not work while diskarbitrationd is suspended.

Standard tar doesn’t support file names longer than 100 characters.

That’s true, although both the ‘ustar’ format and the GNU ‘LongLink’ extension seem to be ways around this.

As far as the copy of tar inside the !UnTarBZ2 application there is a function called ‘CheckFilename’ that talks about working around that restriction and, whilst I’ve not looked at it in too much detail, sounded similar to the description I found of how the ‘ustar’ format works around it (i.e. by dropping directory names from the front of the filepath and adding them back in again).

Its entirely possible this is a completely different work around, and that the only way to get it to work is to ensure the tar files on the downloads page are created using this version of tar.

An alternative would be to pick a more modern version of tar (e.g. the GNU one) and add the various RISC OS extensions to that.

Or I could just get CVS up and running and avoid the entire issue!

With regard to untarring the source files, I found that using 7zip under windows to do this (twice) and then copying the directories created from a shared disc on the network onto the Iyonix worked with no problems.