Any updates about RiscOS on the Raspberry Pi?

I assume this is the post about making the ROM image look like zImage.

However, take a look at what this guy is doing — he’s building “raw” binaries, dropping them on the SD card as kernel.img and booting. There doesn’t seem to be any need for a magic number.

https://github.com/dwelch67/raspberrypi

Yes, that’s what we do. Rename ‘riscos’ to ‘kernel.img’, copy it onto the FAT boot partition of an RPi SD card over the existing kernel.img. There is various behaviours with various start.elf – you’ll probably want the latest one:
https://github.com/raspberrypi/firmware/blob/master/boot/start.elf
(click on ‘raw’ to download it)

Yes, that’s what we do.

Well all I get is a blank screen – not even ‘Starting OS’.

If I revert to the original start.elf and the rom image packaged with mkimage I do get ‘Starting OS’ but no further. So the current BCM2835 ROM image is not being loaded for some reason… and the way I package it using mkimage has the wrong address or entry point or something…

I haven’t had a chance to test the prebuilt images yet, so will give it a try later.

Stupid question time… you are running it on an HD-capable monitor aren’t you? It’s currently hard-coded to 1920×1080, so you’ll need something that supports that.

you are running it on an HD-capable monitor aren’t you? It’s currently hard-coded to 1920×1080,

Yes

So I assume the expectation is that RISC OS/RPi can drive the HDMI out of the box?

Chris, I assume you’re seeing the

BCM2835 Raspberry Pi

Starting OS

Via the serial console?

Hi guys. As you’ve already noticed, we’ve got a ROM image being built from the sources (which are in our public CVS) that’s part of the daily autobuilder process. This gets uploaded to our ROM image downloads page each morning (assuming the build didn’t fail and I remembered to start the autobuild cloud server!).

We’ve made no attempt to put a ReadMe in there or explain to anyone what to do with this stuff because the reality is that it’s primarily intended as a convenience for the (very small number of) people who are actively working on getting the port into a state where it’s ready for release to a broader audience. Right now, there are various tricky dependencies to sort out and rain dances you have to do. Plus, the bugs/issues in the ROM are changing daily so we don’t want to slow ourselves down trying to get end-user documentation right just now.

So feel free to have a play but it’s all at your own risk – this is pre-alpha stuff!

If you’re a developer who already has an RPi and a copy of the DDE with lots of low-level ARM and board bring-up skills and with some spare time to help, drop us a line at info@riscosopen.org and we’ll see if there’s stuff on the current ToDo list that you could help with (there’s bound to be something!).

Chris, I assume you’re seeing the


BCM2835 Raspberry Pi

Starting OS

Via the serial console?

On the main screen actually. I have no serial console connected.

Thanks for the update Steve! Is the DDE the only way to build RISC OS? Is GCCSDK able to build the OS itself or just apps?

Then at least we know the RPi has read the kernel.img since the string “BCM2835 Raspberry Pi” is in the RPi ‘riscos’ ROM image (and nowhere else, I checked bootcode.bin, loader.bin and start.elf).

I tried with the latest RISC OS ROM image in the downloads area (dated today) along with the latest bootcode.bin, loader.bin and start.elf from here, now I get a blank screen on the display with a 1px high line running across the bottom of the display.

A couple of questions:
1) Is HALDebug enabled for these early BCM2835 builds?
2) Does/can RISC OS output debug info to the serial terminal?

As for #1, I don’t think it is, Chris got some output, but this comes from the BCM2835 HAL (in Top), just before it calls OS_Start. There’s a few other strings in there that should be printed if HALDebug is enabled (unless those strings are going somewhere else like a serial console!).

EDIT: Looking through the BCM2835 HAL sources, it seems that any of the HALDebug output goes through HAL_DebugTX which uses HAL_UARTTransmitByte to write the strings out to the serial port on the GPIO pins 14/15 (in alt0 mode). So if HALDebug is indeed on, we should be able to see debug output on the serial port.

EDIT2: Looks like HALDebug is enabled, I hooked up a TTL level serial adapter to GPIO pins 14/15 and I get this output during boot:

HalStartup
007F8000 40000000 09387000 HalStartup2
00600000 08000000 09387000 007F8000 F8787000  HAL Init completed
HAL initialised
InitCMOSCache entry
InitCMOSCache done
IMB_Full done
Keyboard scan complete
Reset CMOS
InitDynamicAreas
InitVectors
InitIRQ1
IMB_Full
VduInit
ExecuteInit
KeyInit
MouseInit
OscliInit
Enabling IRQs
IRQs on
FindOKMode reached
PushModeInfo done
HAL_InitDevices
InitVariables
AMBControl_Init
ModuleInit
CheckModeValid
CheckModeValid
CheckModeValid
CheckModeValid
CheckModeValid
CheckModeValid
CheckModeValid
CheckModeValid
CheckModeValid
CheckModeValid
CheckModeValid
CheckModeValid
FindOKMode reached
PushModeInfo done
CheckModeValid
CheckModeValid
CheckModeValid
CheckModeValid
FindOKMode reached
PushModeInfo done
CheckModeValid
CheckModeValid

So maybe it’s just a video mode problem? I’m hooking it up to a decent sized LCD TV (via HDMI). The TV says 720p, which I believe is 1280×720.

On my Pi, I get a flashing cursor top left. No boot messages.
If I press return, the cursor moves down the screen.
Typing desktop produces a white line at the bottom of the screen.
Press F12 then return and the line flashes, so the desktop is there, but not displaying correctly.
I’ll try some different start elf’s to see if it works with a particular one.

A quick test with the different “size” elf files shows they all do the same.
So close and yet so far….
My TV shows 1080I as the input BTW.

Then at least we know the RPi has read the kernel.img

But I may have packaged it wrong:

root@beagleboard:~# mkimage -A arm -O Linux -T kernel -C none -a 0×81000000 -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: 0×81000000

Entry Point:  0×81000000

root@beagleboard:~#

I also tried load 0×82000000 and entry 0×82000064 (same message but no cursor).

It does not produce the ‘BCPM2835 Raspberry Pi ..’ message just by using the rom image and renaming it to ‘kernel.img’.

I’ve tried the latest ROM image (5th June 0748) [with ‘riscos’ just as it is renamed to ‘kernel.img’ with the latest bootcode.bin, loader.bin and start.elf] and that seems to ‘work’.

Very quickly (too quickly to see ‘any ’Raspberry Pi’ message – about 4.5 seconds from switch on) I get a flashing cursor (a few lines down from the top of the screen as if it had output a couple of lines of text) and if I type ‘FX 0’ (on a USB-connected keyboard) I can see that the cursor drops 2 lines as it would if there was any text being output to the screen. However the text is invisible… or perhaps not there! Difficult to tell which.

Good news though as the keyboard seems to work.

I have a level-shifting serial thingie (cost £3 on ebay) but not sure which pins to connect to.

I’ve also tried the latest ROM image and have it up and running on my RPi.

It drops down into the supervisor prompt (as expected) and from there I can launch into the desktop.

Main issue for me is that there are big black borders around the screen that cover most of the IconBar, however the mouse is visible in that section and if I click it does cause things like the Task Manager to open up. I tried disabling overscan in the config.txt file but that didn’t seem to have an effect.

Whilst I do have the full DDE my ARM coding skills are a little rusty, however I’ll probably look at getting the OS compiling, and of course I have my own apps that need recompiling!

The UART on the RPi is mapped to GPIO 14 & 15. These show up on P1 as:

GND: Pin 6
TxD: Pin 8
RxD: Pin 10

Seems to be running at 115200 8N1 with no flow control.

I’ve also tried today’s image (5th June 0748) and get the same results as Chris, but not the same results as Leo. I get a very rapidly flashing cursor that moves as though text is being inputted, but no supervisor, no desktop (even if I type *desktop), just yawning black space.

I wonder why we’re getting different results?

Leo, could you post links to the start.elf, loader.bin and bootcode.bin you are using ?

Jeffrey recommended setting framebuffer_ignore_alpha in config.txt to address some video issues (with the latest start.elf)

I download the start.elf from https://github.com/raspberrypi/firmware/blob/master/boot/start.elf
The rest of the files are from the latest RPi Debian image.

I appeared to need to set ‘framebuffer_ignore_alpha’ to see anything on the screen (including the supervisor prompt, although its possible I just didn’t wait long enough the first time). So even with that set I get the black borders.

The native resolution of my monitor is 2560×1600, which may have an effect, however over HDMI the max is still 1920×1200.

This may be a stupid question, but how do I set the framebuffer_ignore_alpha? I don’t appear to have a config.txt file… do I just create one?

Yep, that’s what I did.

Details on how to create the file can be found at http://elinux.org/RPi_config.txt

Done it, thanks!

Now I have the same issue as you, Leo. Thick black borders obscuring the iconbar, even though the mouse still seems to operate in the blacked-out area… So I did play with Draw!!! I just couldn’t save it anywhere…

The framebuffer_ignore_alpha=1 seemed to work! Now I see it boot, I can see the castle logo appear then go and I’m left with a grey screen with a cyan pointer in the middle! I think the resolution is wrong for my TV, it looks like I’m missing the left/right edges. USB Keyboard and mouse don’t seem to work yet.

This is what I now have in my config.txt file (the initial 3 lines came from the Arch Linux image I started with):

hdmi_mode=19
#arm_freq=800
disable_overscan=1
framebuffer_ignore_alpha=1