Attention Pi users!

I’ve updated our VCHIQ driver to the latest version from the Linux sources. However this new version needs newer GPU firmware than that which we’re currently using, otherwise the machine will fail to boot. So anyone who wants to use the latest development ROM image will also have to download the latest firmware from the Raspberry Pi firmware github. Specifically it’s the bootcode.bin, fixup.dat and start.elf files which you’ll want. Any older firmware files you’ve got (e.g. loader.bin, arm128_start.elf, etc. – everything except the config.txt and the RISC OS ROM image) can safely be deleted. But you also need to be aware that the new firmware isn’t compatible with older ROM images, so you might want to take a backup of it just in case you want to roll back.

Users of the beta ROM image (dated November 2012) don’t need to worry about these changes yet, but will have to be aware of them if the image gets updated in future.

Thank you for that info’.

However, I’ve downloaded those 3 files, & have been using the 25/02/13 dev’ image for over a week with no (apparent) problems & my boot sequence is now stuck at:

Boot:Choices.Boot.PreDesk.!!VCHIQ

Does this mean your info’ is dependent on a more recent dev’ image yet to be posted?

EDIT: Typical, A few minutes ago it was still 25/02/13, now I see it’s updated to today, thank you
At some point there was a VCHIQ file in the FAT partition. Was/is that RISC OS specific & now no longer required?

And there was me thinking it was safe to make that post before the new ROM was uploaded ;)

At some point there was a VCHIQ file in the FAT partition. Was/is that RISC OS specific & now no longer required?

I’ve never heard of anyone needing a VCHIQ file in the FAT partition. I say delete it!

If you want you can also delete the !!VCHIQ softload from Boot:Choices.Boot.PreDesk (it’s redundant as the VCHIQ module is now in ROM), but that will obviously leave you without a copy of the module if you have to rollback your ROM for any reason.

@Jeffrey

Have just downloaded the latest github firmware and the latest ROM (5-Mar-2013) and I just get a flashing green LED on the Pi.

Have renamed the files in !Boot.Loader from (e.g.) ‘start/elf’ to ‘start/elf2’ and then to ‘START/ELF’ to force them into 8/3 format (don’t ask). The Pi now starts up but without the boot splash screen.

As I mentioned in another thread, the new firmware from github along with the recent Rom announced by Jeffrey above works splendidly on 3 different R
Pi’s here. The only variable I can’t test is Hynix dram, as all mine use Samsung.

Some time ago I determined that config.txt file names seem to be case independent & although I haven’t exhaustively tested this, > 8 char’ filenames also work fine. I’m thinking about a “boot loader” that will allow several ROMS (kernels) to coexist, & I will just have a menu asking for which I’d like to boot from.

To that end, my new RISC OS rom is called

riscoskernel.img

& my config.txt contains (amongst other stuff)

kernel=riscoskernel.img

& it’s all ticketyboo.

However, you did say:

to force them into 8/3 format (don’t ask)

As I experiment with RPi for other ideas, most of my changes are done to the SD card mounted in OS X, but I have done some to the loader.img file under RISC OS & they seem fine there too.

The Pi now starts up but without the boot splash screen.

Correct. The development ROM images have some debug output enabled which causes the black & white splash screen to scroll out of view pretty quickly. The splash should be back as usual for the beta/stable image.

Actually, I find that feature quite useful. I have an old Pegasus USB to Ethernet adapter, & was going to mention it works fine on RISC OS 5.19 in another thread about Ethernet. So I tested it on this recent model A RPi. It booted fine, so I thought, ok, only 1 USB port, so now I’ll plug in a USB hub, so I can have Pegasus plus keyboard & mouse. Unfortunately that failed. I knew where it failed as the white text on black background stopped after:

Init mod DHCP

Unplugging the hub resumed booting. I tried several hubs all with the same result, yet plugged in directly all was well. Pegasus works fine on model B RPi’s too.

The Pi now starts up but without the boot splash screen.

Correct. The development ROM images have some debug output enabled which causes the black & white splash screen to scroll out of view pretty quickly. The splash should be back as usual for the beta/stable image.

But you also need to be aware that the new firmware isn’t compatible with older ROM images …

Users of the beta ROM image (dated November 2012) don’t need to worry about these changes yet, but will have to be aware of them if the image gets updated in future.

Is the updated beta ROM image (dated 9 March 2013) compatible with the older firmware please? It seems not to be.

I don’t understand why we get different results. The “debug” screen output is still present for me on the 9 March riscos.

I’ve just tried another quick test on a empty FAT formatted SD using just the 4 relevant files, & RPi boots to the error screen, so I cancel that message, change the screen res’ from its default 640 * 480 & I can proceed to use task windows, !Edit, !Draw, etc..

I’ll try again later with the full filesystem to see what I get.

One peculiarity I have noticed is that sometimes when I mount the RISC OS SD on my mac, the files I see there don’t always agree with what I see from RISCOS looking at the “LOADER” directory within the !Boot directory. It’s as though the Filer’s version is cached. However, if I deliberately introduce an error into the file structure as viewed by OS X’s mount of the SD, RISC OS does fail to boot, as expected, which suggests something strange in the “cached” version.

If I modify within RISCOS that “LOADER” directory though, I do get what I expect. It would be useful to have explicit details of the “FAT image” file creation.

Just having the bare minimum file set is very useful for testing changes in the Alpha roms. For example, one great improvement in the 9 March ROM is to the mouse pointer operation. It no longer leaves “trails” behind, messing up windows as it goes, on mouse pointer movement. Very nice, thank you.

For some applications I have in mind for RISCOS, just loading the ROM will be adequate; no need for filer involvement as I can use the basic FAT system.

I don’t understand why we get different results. The “debug” screen output is still present for me on the 9 March riscos.

I am referring to the beta ROM image which has been updated from 1 Nov 2012 to 9 Mar 2013. The alpha ROM image, updated each day, does produce the debug messages.

See here for an update.