Any updates about RiscOS on the Raspberry Pi?

Is image be universal? i.e. work on a Beagle, and if put on a hard drive, an Iyonix?

I don’t see why not (apart from the Welcome page which is addressed at the Pi’s audience of new users) but I haven’t put the (fortunately differently named) firmware bits in the FAT partition. Now you need to be clear what you mean when you say ‘image’ – I am meaning ‘SD card image’ i.e. all of the boot firmware plus the RISC OS boot stuff and lots of bundled software in a RISC OS partition on the SD card. The only obvious place to put the SD card image is onto an SD card. ‘If put on a hard drive’ No that is not an option. If you mean if the RISC OS partition contents were put on a hard drive, without the DOS image file for the FAT partition, then it should work…

Alas not, the various OMAP3/OMAP4 bootloaders do use (for the most part) the same filenames as each other, and are not (TTBOMK) compatible with each other. You could construct an image which would boot either a Raspberry Pi or one selected OMAP3/OMAP4 board, but chances are that would just confuse people.

If you’re happy to ignore the Raspberry Pi bootloaders and just use the FileCore part of the image, you could copy the image onto a USB flash stick for use on an OMAP3/OMAP4 machine, and continue to use board-specific bootloaders from the SD card.

I have tried the image on on SD card in a Pandaboard ES. It works, after you put the (fortunately differently named) firmware bits in the FAT partition.

So what should be possible is an Image that will do both Pi and Beagle. Also sets of files for other boards can be supplied to modify the image to work with other systems instead of the Beagle.
The contents of the Filecore area (minus the DOS disk) could be supplied as an archive to use with a Non SDFS !booting system.

As a workable hack, maybe replace “riscos” image with a short bit of code that identifies the platform and loads the appropriate image according to the platform in use…?

The problem isn’t that RISC OS doesn’t know what machine type is in use; the problem is that the bootloaders that get run before RISC OS don’t know what machine is in use. And since there’s no standard way of probing for hardware on ARM devices (unlike x86), there’s no sensible way of coming up with a bootloader that will work with all devices, unless some prior bootloader has already told it what machine it’s running on.

What Jeffrey said.

Welcome to the world of embedded devices! Outside the world of PCs, every silicon vendor expects that (at least at the operating system level) you design and compile your software to run exclusively on their chips. There isn’t even any coordination between (say) the various OMAP3 boards, so you can’t rely on GPIO pins being tied high or low in a particular pattern to work out which machine you’re running on, even if a common bootloader for OMAP3 and OMAP4 could be written.

Add to this the trend for boards like the Raspberry Pi and beagleboard-xM having no on-board storage of any kind, and everything unique to the board has to go on the SD card, making it impossible to have a single universal SD card image.

Yes, there is a large problem there. I’ve poked around a source for the initial bootloader on the Beagle (the MLO file), and it is written with numerous assumptions, but even then needs to poke around to work out which board is in us and what sort of memory is attached. It should still be possible to make a smarter MLO bootloader, though as Ben says, there’s little commonality so for each supported board it will be that much harder and more liable to mess up. Isn’t the Panda the same CPU as a Beagle? How do you tell them apart if using a common loader?

I suspect the boot process itself may get some reworking as people may want to run multiple OSs on the RPi without constantly swapping uSDs. It looks like U-Boot can support a front-end menu ( see this image on Wiki ) so what we need to have is this expanded to allow OS selection. Sadly I don’t think this would likely go as far as multiple-board selection, given that it will require different builds for different boards (um, a bit like RISC OS itself then!).

Isn’t the Panda the same CPU as a Beagle? How do you tell them apart if using a common loader?

Panda is dual-core Cortex-A9, Beagle is single-core Cortex-A8. Easy enough to tell apart by reading the standard ARM CP15 registers. If you were targeting just OMAP boards and the Pi then you could extrapolate that Cortex-A9 == OMAP4, Cortex-A8 == OMAP3, ARM11JZFS == BCM2835, but once you get beyond that (e.g. the subtleties of all the OMAP3 boards) things get a bit more complicated.

… different builds for different boards (um, a bit like RISC OS itself then!)

Not necessarily :) As long as the bootloader can tell us what hardware we’re running on, it should be possible to make a RISC OS ROM that will work on any of the devices that RISC OS 5 currently runs on.

Not necessarily :) As long as the bootloader can tell us what hardware we’re running on, it should be possible to make a RISC OS ROM that will work on any of the devices that RISC OS 5 currently runs on.

The other month I was looking at the bootloader options from the point of view of setting specific variables – e.g. the MAC, which is available in a U-boot variable – and also the scripting available in the boot loader. Documentation suggests there is also a partition choice setting.

So if we had a small menu system allowing a choice of OS on a specified partition and a pass thru of detected board facilities – interrupting the boot and dropping into the boot console gives command options which show something in the boot loader clearly understands the difference between IGEP and even variants of beagleboard.

The real problem then is that RO apparently takes no notice of the u-boot environment variables so there is no means to pass these into the RO environment.

I suspect dibbling with that kind of scriptable item appeals to Rick as much as me. After the GBBF takedown I may find time.

Is there a good reason why the Raspberry Pi ROM image has a fixed screen resolution? Given that the GPU output is determined by the information it receives from the monitor, usually over-ruled by the ‘config.txt’ file, and that RISC OS and the GPU cannot currently communicate but the GPU will upscale or downscale what it gets from RISC OS to suit, then what is the harm in allowing RISC OS to do a screen mode change when the user requests it? It could even do something on the lines of a ’SPOOLON !Boot.Loader.config/txt to add a line like hdmi_mode=13 (or whatever) so that on the next boot, RISC OS and the GPU have the same settings.

I don’t think the limited resources implementing standard RISC OS mode selection should be redirected, especially for something that would be Raspberry Pi specific and probably made redundant shortly.
Also I’m not sure the current binary blob supports mode change once initially set up!
The auto monitor resolution on the A9home often showed that many monitors don’t correctly give correct information. We sent AdvantageSix a couple of dozen EDID files only about half seem to be correct!

The GPU does support mode changes – when I boot Linux from RISC OS the kernel changes mode according to the settings on the Linux command line. Messaging the GPU via the mailbox channel claims to do it, though I haven’t tried that myself. Gives full access to both virtual and physical modes. Just hasn’t been plugged into RISC OS fully yet.

Is there a good reason why the Raspberry Pi ROM image has a fixed screen resolution?

I am not being clear about what I mean. RISC OS presents (currrently) a fixed screen resolution to the GPU – set by the ROM build. The GPU takes whatever RISC OS presents and upscales or downscales it to the resolution it is providing to the monitor. The monitor takes whatever the GPU is producing and downscales or upscales it to its native resolution (if an LCD) or adjusts its native resolution to suit (if a multiscan CRT).

The GPU seems rather better at this than the LCD so I see no reason for RISC OS to have a fixed resolution. Surely it is more work to make it fixed than to leave it as variable? The GPU can remain at the LCD native resolution throughout, making messaging unnecessary.

The alternative resolutions on the lapdock thread seem to work fine.

Pesonally I have no desire to use anything but native resolution (or 50%) and prefer borders to a fuzzy screen. I also dislike programs that go full screen, much prefering them in a window. (Serious games and serious video watching being an exception, but I don’t tend to do much of that.)

Since the Pi wont directly drive CRTs except TVs which have a fixed resolution anyway), I hope the driver will output native resolution (whether it works from EDID or is set manually) and give the option of borders or scaling when the mode’s resolution is between 50% and native.

I notice the recent distro (with the nice raspberry background) won’t save my settings and the clock starts in GMT and it seems to lose some keypresses.

Any reason why the eigen values do not work on the Pi?

It would be very useful when doing a presentation to be able to set EX0 EY0 so that the screen is easier to read from the back of the room!

Variable resolutions involve changing around the way memory is allocated. At first this was hardcoded – the GPU assumed a 1920×1080 screen and we gave it one in a buffer that it allocated. If the GPU is expecting to render a different mode, it’ll expect memory laid out in a different way, so we need RISC OS and GPU virtual size to be the same.

Now things have moved on quite a bit, but the final pieces aren’t quite in place to remove the hardcoded assumptions. Please be patient: at the moment we’re waiting on Broadcom.

I imagine eigenvalues don’t work because the size is hardcoded in the kernel VDU driver code, but don’t know for sure.

Theo, you may already know this, or perhaps the guys you are speaking with at Broadcom would know if there is an appropriate opportunity to ask… is 1920*1200 the highest the GPU can physically output?

I have a 16:10 aspect ratio monitor, so am looking forward to variable screen resolutions, and I’d get a little kick out of running RISC OS at 2560*1600 at any refresh rate or colour depth – homage to a younger me sticking heatsinks on a VIDC20 to get 1600*1200… but as it’s an HDMI not dual-link DVI I wonder where the hard limits are?? Cheers!

Apparently 2560×1600 at up to 120Hz is feasible, according to the config.txt guide Just try tweaking it and seeing if it can sync to that.

The highest screen mode number that works is 68 (1920*1200, reduced blanking). This gives me a letterboxed 1080p 16:9 screen with correct aspect ratio, on my 16:10 screen. This is ‘good enough’ and works well for me on both Raspian and RISC OS.

However anything higher, from the next mode up 69, the same with 60hz refresh, to mode 79, does not work on either OS. This seems to contradict the config.txt list and I fear there may be a physical limit being met.

On the higher screen modes, Raspian displays nothing at all, but RISC OS shows a desktop that is usable but extremely blurred, it’s the 1080p desktop but appears to have been downsampled to a much lower resolution.

I’d prefer to drive my monitor at its native resolution of 2560*1600 if possible, so if there’s any way I can help with testing any of the the mode setting improvement work I’d be delighted to help (no pressure, I know you are getting great access from Broadcom but people have day jobs!).

Or, if it’s just not possible it would be good to tease out precisely what physical limitations prevent using these highest modes, and I could feed this back to whoever maintains the config.txt wiki.

Wikipedia gives me a couple of different views on the max resolution:

HDMI entry says:
HDMI version 1.0–1.2a 1.3 1.4
Maximum resolution over single link at 24-bit/px[B] 1920×1200p60 2560×1600p75 4096×2160p24
Maximum resolution over single link at 30-bit/px© N/A 2560×1600p60 4096×2160p24
Maximum resolution over single link at 36-bit/px[D] N/A 1920×1200p75 4096×2160p24
Maximum resolution over single link at 48-bit/px[E] N/A 1920×1200p60 1920×1200p60

Raspberry pi page specs say:

Video outputs:⁶ Composite RCA (PAL & NTSC), HDMI (rev 1.3 & 1.4),⁶² raw LCD Panels via DSI⁶³⁶⁴
14 HDMI resolutions from 640×350 to 1920×1200 plus various PAL and NTSC standards.⁶⁵

There’s a conflict in the Raspberry Pi specs between claims of support for HDMI 1.4, but only support for certain resolutions up to 1920*1200.

So it looks like I’m out of luck trying to go higher, but it’s not obvious where the bottleneck is :(

Sorry Alex I had meant to get back to you on this one days ago but lots of Pi related RISC OS projects got in the way the little beggars ;-)

Right, to clarify:

Like you I have a monitor that’s native resolution is 2560×1600. However it can only be driven to that resolution by the DisplayPort or DualLink DVI connections.

The DualLink bit is the givaway for what you are asking about. DualLink is basically 2 sets of DVI signals processed and joined together.

HDMI 1.3 contains a SingleLink DVI connection for the video – the maximum here is 1920×1200@60Hz.

The full version of HDMI 1.4 will eventually contain what is called the HDMI 4K modes 4096×2160 being the one that I can’t wait for! :-)

Even though the Rasperry Pi documentation includes references to HDMI 1.4 I very much doubt whether it is capable of driving to HDMI 4K standards.

HDMI 1.4 also allows for other things to be included in the HDMi connection such as Ethernet.

Of course it is possible that the Broadcom SOC can support more of HDMI 1.4 (like the ethernet over HDMI connection) than is actually implemented for cost reasons on the Raspberry Pi.

So to finish, unless I am completely wrong, the Raspberry Pi in terms of its video resolution capability conforms to HDMI 1.3 i.e. 1920×1200 perhaps upto 60Hz.

Hope this helps :-)

The revision 2 raspberry pi board is now available in quantity from Farnell effectively from stock (ordered Fri 7th delivered Wed 12th).

Hey, just saw this from the P-Rpi foundation!

http://www.raspberrypi.org/archives/2221

Upshot is that the interface between the ARM and the GPU has been open-sourced! So there’s a chance the drivers could be ported to RISC OS.

Now… it would be great to hear that this happened ages ago behind closed doors and our beta release will already be GPU accelerated…?