Any updates about RiscOS on the Raspberry Pi?

4. Create a partition below this of an arbitrary type (this isn’t strictly necessary, but just so partitioning tools don’t get confused)

type ad has been claimed for filecore format.
http://www.win.tue.nl/~aeb/partitions/partition_types-1.html

The image filesysystem / overlapping partition hack is only needed to allow the ROM to be updated from within RISC OS (until RISC OS has proper partition support) as far as I can tell.

Therefore if people don’t mind doing that themselves outside RISC OS, they should be able to use their own partitioning scheme, the tricky part is creating a Filecore partition with a normal table entry of the right size.

I have just looked at how it is partitioned.

It appears to have a filecore format covering about the first 1.9GB

The first table entry is is the 128MB FAT partition for booting the Pi, which is physically the first partition. (Inside the Filecore section)

There is a second (protective) entry in the partition table (in the 4th slot) of type AD of 1.7GB.

As far as I can tell the filecore section has a file entry that matches where the FAT partition is, so the whole thing appears as a normal file, which can be mounted as an image file.

Very clever. Presumably more primary partitions could be created (by the user) if the card is bigger to use with another OS for dual booting. (I don’t know enough about partitioning to know whether creating an extended partition would make everything go horribly wrong or not).

No wonder it is hard work to change the size and keep this working.

Additional GPU firmware images, rename over start.elf to use them:
• arm128_start.elf : 128M ARM, 128M GPU split (use this for heavy 3D work,
possibly also required for some video decoding)
• arm192_start.elf : 192M ARM, 64M GPU split (this is the default)
• arm224_start.elf : 224M ARM, 32M GPU split (use this for Linux only with no 3D or
video processing. It’s enough for the 1080p frame buffer, but not much else)

The distro appears to be set 128/128 split, is there a reason for this?

I would have thought the 224/32 split wouldn’t compromise what RISC OS can do.

Am I right to assume there’s still no audio on the Rpi with the latest ROM release?

The distro appears to be set 128/128 split, is there a reason for this?

As I understand it the code to detect what memory split has been selected isn’t implemented yet, so it defaults to the 128MB/128MB split as the safe option (i.e. in all memory configurations the CPU has 128MB available to it

The problem with the bottom bit of the screen not being display seen to have been fixed if you add framebuffer_align=0×100000 to the config.txt which you have in the distro release.

I tried this yesterday on a very recent RPi distro, and I can confirm that it made the icon bar visible on my RPi with no other changes required – previously only a few pixels of the top of the icon bar were visible, and none of the icons on it.

An update to the alpha disc image in the usual place.

Instructions and details of content here

The updated ROM dated 16th July 2012 offers the following improvements:

• CMOS settings may now be saved (automatically). [This will have the effect of making your rom image personal to you as the settings are stored within the rom itself]

The updated disc image adds the following new items:

• !Director – Director is a general purpose desktop tool. It allows you to customise your desktop by creating menus of useful commands and icons to attach the menus to. Any number of menus or icons can be created and attached in any order to each other. Note: There are issues with this piece of software on the Pi – be aware..
• !Packman – PackMan is a utility to help install and maintain applications and other components of a RISC OS computer.
• !NapoleonII – This is a recreation of the original Napoleon game that appeared in Risc User and was written by Alan Stout. This version is 32bit compatible. It’s a Patience game based on Napoleon of St. Helena. The object is to build up 8 ascending suit sequences, Ace through King.
• !InterGIF – is a program for making GIF images from RISC OS sprite files, or from Draw files, or from files produced with Iota Software’s (commercial) animation program The Complete Animator.
• !PDF – a Public Domain PDF file viewer for RISC OS.
• IClear – a module which makes it easier to delete text from a writable icon. With IClear running, simply double-click on the writable icon, using either Select or Adjust. The icon will be inverted, which usually means that it will turn black with white text. As soon as you press a key, the text in the icon will vanish, to be replaced with the character that you typed. If you change your mind after inverting the icon and decide you want to keep your existing text, a further click with any mouse button anywhere on the screen will de-invert the icon and put things back to normal.

Is there a reason why SparkFS is in Third Party in the standard image? I’d’ve thought Utilities (since it’s Filer_Booted by default) would be more sensible.

The update to the disc image now ensures that !SparkFS is Filer_Booted on boot. Many zip downloads will still need to be dragged to the icon bar icon for !SparkFS or have their filetype set to &A91 (Zip) manually before double-clicking.

I would like to see packman as part of the distro,

Now included (but I think it needs some examples of ‘how to’ or ‘what to’).

I also don’t know how this interacts with Ben’s !Boot.Loader hack…don’t know if that needs special magic to know where the FAT partition is.

Yes, hundreds of blocks of the FileCore free space map needed updating to reserve space for the FAT partition, and I had to manually create a directory entry to point at it. Not easy, especially when you consider that the map blocks and directories are both checksummed. All the code you’d need to produce your own could be probably constructed by hacking around HForm, but it’s not pretty. I’m hoping to produce a tidied up version of my code eventually that will let people make customised disc images similar to the one that Chris started from, but several of the steps are currently manual and I’d want to automate them, so please be patient. In the short term, we only actually need the one, since we’ll only be providing the one disc image, so this is lower down the priority list than other Raspberry Pi things.

Am I right to assume there’s still no audio on the Rpi with the latest ROM release?

Correct. Several things, including sound, hardware cursor and customisable screen resolutions, are waiting on one of the big chunks of work that is still outstanding.

Several things, including sound, hardware cursor and customisable screen resolutions, are waiting on one of the big chunks of work that is still outstanding.

Which is…?

one of the big chunks of work that is still outstanding.

also the knowledge to RISC OS of the unique MAC address that the GPU presents to the outside world.

Several things, including sound, hardware cursor and customisable screen resolutions, are waiting on one of the big chunks of work that is still outstanding.

Which is…?

Two chunks of work, really. One chunk of work to support the mailbox property interface (which hasn’t yet been fully implemented in the GPU firmware, and I believe is currently only available in test firmware images instead of the ones available from the usual place on github), and one chunk of work to port the VCHIQ driver (once the source is available under a RISC OS-friendly licence).

(Slightly OT):

hardware cursor

Can anyone here please point to any further (preferably online) sources to help explain to readers of Wikipedia how a hardware pointer works?

I’m sitting here on the outside looking in and what others are doing here – clearly a lot of people here haven’t really ever put their RISC OS machines to bed like I did.

I have to say that this is genius:

If there is a directory ‘ROM_Up’ provided then do the following to update the ROM image:

open the directory ‘ROM_Up’. Hold down SHIFT and in the window ‘SDFS::RISCOS.$’ double-click over !Boot. Then in the window ‘SDFS::RISCOS.$.!Boot, double click over the image file ’Loader’.

Now drag the file(s) from the window ‘..SDFS_Up’ to the window ‘SDFS::RISCOS.$.!Boot.Loader’. This updates you to the latest ROM image.
end of ROM update]

Accessing the boot level files on the SD card from within RISC OS is so, so useful. It means I don’t have to yank the SD card, plug it into my Mac and write files. I can do it straight from the OS desktop, and reboot. Yes, yes – backup, backup – but this shows that the system is romping gleefully towards idiot-proofing the update process. An Application to automate this process will, I feel, be an ideal goal – grab the .zip file, extract, move contents (overwrite where necessary), prompting for a reboot.

Or, seeing as though the ROMS etc. are buried within the !Boot structure, can this be built into the system’s automatic update? I know you can update the system using the !Boot app as a springboard (dragging another system folder to it to merge) – can this be done with OS updates? Or does the fact that files are on a separate drive preclude this?

can this be done with OS updates

the answer is a bit equivocal. I think yes but not for the first update as the testing process revealed a bug in the rom (now corrected). So for the alpha I’m sticking to the slightly complicated way. By the beta the recommended way will probably be boot merge (which will also update the rom and any firmware tweaks).

Is there the possibility of a boot menu?
two reasons, to boot another OS, (e.g. a media player/linux) or to allow the old ROM to be loaded.

Is there the possibility of a boot menu?

Exactly a year ago I suggested this (in the context of the Beagleboard) where I hoped that RISC OS could start up and offer the user a choice of the disto to boot into, including of course RISC OS – see here

The idea was to tempt non-RISC OS users to try RISC OS.

Clearly RISC OS would have to boot up quickly, be able to read SD cards, have a working USB stack, be able to look good whatever the monitor’s native resolution and be able to send an image to the GPU to be started up as if from power on. Three down, two to go (both of which depend on one piece of work AIUI).

Another question, It seems that my !Boot structure does not have the Loader folder. Common sense tells me that I can’t just copy it from a !Boot folder on another SD card as it’s a pointer to another partition. Is there a way to create this folder within RISC OS itself so I don’t have to start from scratch, or is my intuition wrong and I can just copy?

I am making a copy anyway, so I can pick it apart and see if I can create one myself (I am guessing that even though it looks like a folder, it’s likely to be some kind of disguised file) – but I’m going to be doing some uneducated stabbing in the dark with this :-)

It seems that my !Boot structure does not have the Loader folder.

You need the 13 Jul 2012 alpha distro. This (21.8 Mbytes) decompresses to 1882.6 Mbytes and needs to be written to an SD card using Win32DiskImager. Currently Raspberry Pi only. Creating the various dependencies so that it works is complex.

‘Loader’ is an ordinary DOSFS disc image file, but the sectors which it occupies on the card have been carefully chosen so that the file maps directly onto the FAT partition. To create such a magic file manually would require some low-level hacking of the filesystem. Ben’s working on a tool to fully automate the process, but it’s not finished yet.

Deleting an existing Loader file or changing its size is also liable to corrupt it (and potentially corrupt the underlying FAT partition). You have been warned!

Is there the possibility of a boot menu?

Exactly a year ago I suggested this (in the context of the Beagleboard) where I hoped that RISC OS could start up and offer the user a choice of the disto to boot into, including of course RISC OS

Yes and we’re working on it. Whether the RPi Foundation opts for this solution in their main SD card image will be another matter.

I was thinking in terms of whether the built in loader offered options, however RISC OS as a loader might be interesting, presumably it would need to be at a desktop after running a minimal resourcefs !Boot.

The problems I forsee are the 2GB DOS limit, unless there is a way (license wise) fat32fs could be used, and the lack of partition support (I can’t see them wanting operlapping partitions and image files, despite how cunning it is).

Could RISC OS use a filecore image file stored on a FAT partition as boot media? or could it just use a fat filesystem?

I tried enabling booting from FAT media a couple of months back, on a beagleboard. It sort of worked, but I immediately hit lock-ups with the first bits of software I tried (!Configure, StrongEd) which make me think it’s more trouble than it’s worth. Anecdotally, FileCore discs are more robust than FAT ones – there’s certainly a lot more error checking in the low-level format. And using the FAT partition to boot from leaves all those messy bootloader files in the root directory, where they’re in danger of being tinkered with.

I wouldn’t get too worried by the 2GB DOS limit. Linux distros for the Raspberry Pi (and the beagleboard, and many other similar devices) tend to use a much smaller FAT partition than that, purely to hold the bootloader, scripts and kernel image, then have a much larger ext3 or ext4 partition to hold the main Linux filing system. Bootloaders often have weird restrictions on disc formats (witness X-Loader on the beagleboard) so if we’re positioning RISC OS in that role, it’s not too unusual for it to have special formatting requirements.

I think a DOS partition with FileCore image files might be more robust.

I could see the 2GB limit being acceptable (especially, since it should go eventually), but I can’t see them liking the image file/partition thing.

I wondered why you advocated that people go tinkering inside their !Boot to do upgrades, rather than just supplying a !Boot directory to merge.

The update method now (once the rom is recent enough to work) just asks you to merge the new bits over the old. Any updated ROM is merged with the rest of the disc image, sitting in !Boot.Loader.riscos/img and it just gets copied over the top of the old rom. CMOS settings get wiped though.

CMOS settings get wiped though.

This is deliberate; witness all of the strife caused when ROM upgrades break peoples’ machines because they have some modules unplugged and the new ROM has a different module order (or even CMOS layout). If you want to preserve your CMOS over a ROM upgrade, you should use the !Configure “Save CMOS” feature to save to a file (on the RISC OS side) and restore from that after the upgrade. This could, of course, be automated one day, if someone were to wrap-up OS upgrades into a suitable updater tool.