Any updates about RiscOS on the Raspberry Pi?

hi I am getting my Raspberry Pi on Monday. The reason I am getting it is so I can run RiscOS on it. I was woundering if there is any news on how the port is going? thanks for your help. From David Heath

There are instructions on the Farnell site on what files need to be put onto the SD card and how to create am ‘image’ file of the RISC OS ROM and what to call it. At the moment the USB stack is not working (AFAIK) and so you will need a serial terminal connected to interact with it. The necessary connections to the header (where the serial port appears) need level shifting and have not yet been publicised…

I couldn’t find mention of RISC OS in the document on the Farnell/element14 website that a link was posted to previously(which I can’t find again). I tried searching for just ‘risc’ and it wasn’t found. Can someone post the correct link?

The ‘instructions’ listed the files on the SD card as follows:

Setting up the boot partition
The boot partition must contain:
• bootcode.bin : 2nd stage bootloader, starts with SDRAM disabled
• loader.bin : 3rd stage bootloader, starts with SDRAM enabled
• start.elf: The GPU binary firmware image, provided by the foundation.
• kernel.img: The OS kernel to load on the ARM processor. Normally this is Linux -
see instructions for compiling a kernel.
• cmdline.txt: Parameters passed to the kernel on boot.
Optional files:
• config.txt: A configuration file read by the GPU. Use this to override set the video
mode, alter system clock speeds, voltages, etc.
• vlls directory: Additional GPU code, e.g. extra codec’s. Not present in the initial
release.
Additional files supplied by the foundation
These files are also present on the SD cards supplied by the foundation.
Additional kernels. Rename over kernel.img to use them (ensure you have a backup of the
original kernel.img first!):
• kernel_emergency.img : kernel with busybox rootfs. You can use this to repair the
main linux partition using e2fsck if the linux partition gets corrupted.
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 ‘instructions to complile a kernel’ (which would take the file ‘riscos’ as the run image and use the ‘mkfile’ command to create an image file) were not there but the XM info says how to do this (see beagleboard.org). Hope this helps. The boot partition files will be there as part of the Linux distro available to download for the Pi.

I’ve got mine :-)

Let us know when you’ve got RPCemu running on it. :D

ArcEm would be better, if you want it to run at a usable speed. Just remember to take the source from the arcem-fast branch.

Dumb question: why is it better? Have the pros and cons of ArcEm vs RPCemu been discussed somewhere and I’ve missed them?

Even dumber question: why ArcEm or RPCemu before RISC OS? Don’t let’s waste time on emulators before getting the real thing running. A small circuit board to control a serial mouse from the header plug if necessary until the USB drivers are running OK. It’s no good sitting on our hands until the USB works and then find that we have to wait for someone else to do work on video drivers!!

Dumb question: why is it better? Have the pros and cons of ArcEm vs RPCemu been discussed somewhere and I’ve missed them?

I haven’t done any actual comparison tests, but judging by the amount of effort I had to put in to get ArcEm running at ARM2 speeds on an Iyonix, I think I’m fairly safe in saying that RPCEmu’s interpreter won’t be anywhere near as fast when running on ARM. Last I checked RPCEmu’s recompiler doesn’t support ARM hosts, so from a performance standpoint ArcEm is going to be much better than RPCEmu when running on ARM hosts.

There are of course other pros and cons of each emulator (e.g. ArcEm is only good if you want Arc emulation).

It’s no good sitting on our hands until the USB works and then find that we have to wait for someone else to do work on video drivers!!

We’re not sitting on our hands until USB works; we’re sitting on our hands until boards are in the hands of OS developers, and until Adrian Lees manages to get his code into CVS.

Last I checked RPCEmu’s recompiler doesn’t support ARM hosts

Didn’t ROUGOL get RPCEmu running on the RPi back in Oct the night before the show? I heard it was very slow, as expected.

Yes, we had RPCemu running on the RPi at the London show. It was VERY slow, taking about 10 minutes to get to the desktop, and that’s with no boot device!

When I spoke to Eben Upton at the Beeb birthday bash he said that Adrian was still working away on the native RISC OS port. Fingers crossed that he’s having some success with it. Now that RPi’s are out there might be the opportunity for others to help him providing it doesn’t require access to confidential Broadcom hardware documents.

we’re sitting on our hands until boards are in the hands of OS developers

Developers already have the boards – see raspberrypi.org – nearly 600 of the first 2000 were given to, inter alia, developers. I assume we had pulled our fingers out and made sure our developers were on that list….

I’ve got mine, can’t wait to try RISC OS on it :)

Anybody else noticed what’s gone into CVS today?

Wow! Amazing 8-)

I was wondering when someone would spot that :) Many thanks to Jeffrey for his amazingly fast hard work. He also says that the ethernet port works fine with EtherUSB.

Does this CVS announcement mean that Jeffrey Lee has got the mouse and keyboard working on the Raspberry-Pi?
I hope this is right as I am expecting my Raspberry-Pi to arrive this week from RS-Online.
I thought one of two other programmers were going to get there first.

Well there is a 6Mbyte ROM image for the BCM2835 available to download. But I’m not sure how to achieve the ‘fatload riscos’ bit at the moment so that I can try it. The Raspberry Pi start up expects a file ‘kernel.img’ to be the thing to load. Not sure whether just renaming the file ‘riscos’ to ‘kernel.img’ will work. Any ideas please?

That rom image is dated June 1st … unfortunately there are no notes attached.

Not sure whether just renaming the file ‘riscos’ to ‘kernel.img’ will work

No, that doesn’t seem to work. Is this ROM image actually functional? Or just a tease?

I had no luck either. How did you create the SD image? Following these instructions I took a 1GB SD card and extracted the BeagleBoard image from here. Next, I mounted the SD card, removed uenv.txt, boot.scr (u-boot) and the BB RISCOS image leaving just ‘CMOS’. I then copied the BCM2835 ‘riscos’ image and named it kernel.img.

I hooked it up to a TV via the HDMI and booted it, but nothing seemed to happen. I guess next, I’ll try hooking up an FDTI breakout board to the GPIO/serial pins and see if there’s anything there!

How did you create the SD image?

The starting point is a Raspberry Pi SD Card image that allows it to start up Linux. You will find files such as ‘kernel.img’ in the FAT partition of the SD Card and some spare space.

The RISC OS ROM needs to be ‘packaged’ so it fools the OS into thinking it is a valid Linux kernel (see another thread – a ‘magic string’ and some entry points) but the method has not been disclosed other than to say the ‘mkimage’ utility under Linux cannot do this (yet another thread which claims the mkimage utility is ‘a u-boot thing not Linux’ even though it is a command only available once Angstrom has started and not available before then).

So we have a ROM image for the Pi but the rituals required to invoke it remain secret.

Chris, Have you made any attempt to build the RISC OS ROM images yourself (from CVS)?

Slight progress. I now get the message

BCM2835 Raspberry Pi

Starting OS

But no further.

I used the following method:

take the BCM2835 rom image and package it as follows:

on the beagleboard start up in Linux command line as follows:

.-------.
|       |                  .-.
|   |   |-----.-----.-----.| |   .----..-----.-----.
|       |     | __  |  ---'| '--.|  .-'|     |     |
|   |   |  |  |     |---  ||  --'|  |  |  '  | | | |
'---'---'--'--'--.  |-----''----''--'  '-----'-'-'-'
                -'  |
                '---'

The Angstrom Distribution beagleboard ttyS2

Angstrom 2010.7-test-20100820 beagleboard ttyS2

beagleboard login: root
root@beagleboard:~# mkimage -A arm -O Linux -T kernel -C none -a 0x81000000 -e 0
x81000000 -n "RISC OS" -d /media/mmcblk0p1/rpi /media/mmcblk0p1/kernel.img
Image Name:   RISC OS
Created:      Fri Aug 20 20:56:03 2010
Image Type:   ARM Linux Kernel Image (uncompressed)
Data Size:    6291456 Bytes = 6144.00 kB = 6.00 MB
Load Address: 0x81000000
Entry Point:  0x81000000
root@beagleboard:~#

then put the file ‘kernel.img’ onto the RPi SD Card, renaming the Linux kernel so that you can rename that back to ‘kernel.img’ to restore the staus quo.

Presumably the BCM2835 Rom image will be packaged (using a method that works) into a ‘kernel.img’ type file in due course.

Any ideas to make my method work? A different load address? A different name string?