RISC OS Pi RC7 has been released

I verified this also on RC6 where this error/crash doesn’t happen. I pinpointed the error to the new InternationalKeyboard-module v0.95 (RC7) while RC6 has v0.94. I tried the old v0.94 module on RC7 and so far there seems to be no problems.

Sorry about that – I guess I didn’t test those changes as well as I’d thought. InternationalKeyboard v0.96, which should show up in the next set of development ROMs (i.e. dated March 14th) contains a fix for the issue.

@Sprow: No it seems that most of us don’t try that nightly build. I occasionally tried the alpha. But only when I have some spare time to try things out.

And hoping it wouldn’t break too much. Some of us try to use these RPI as geniune RISCOS workmachines. Yeah, I know we shouldn’t because its all still in Beta but…

What I wonder is there any significant difference between the Internationalkeyboard-module between 0.94, 0.95 and the upcomming 0.96 (apart from the 0.95 bugfix)?
Or in other words. Should I worry using the 0.94 module on RC7?

Continuing to use 0.94 should be fine. The changes from 0.94 to 0.95 were intended to help the Pandora port, and don’t directly benefit any other machines.

Hi guys. Sorry about the problems some of you are seeing in RC7. I hope to do an minor update to RC8 in the next few days to address the main issues.

For those who haven’t spotted it, RC8 is on the Raspberry Pi site now. It addresses the keymap issue and the missing fixup.dat file in the FAT partition.

Steve, There are no links to Raspberry Pi How to’s etc on the ROOL home page. Going to “Documents” has two links, one to a 2011 posting and the other to a Jun 2012 forum posting. Googling the Wiki for ‘risc os raspberry’ or similar things, surprisingly gives no hits.
I have used dd to write the R8 image file and think I have to edit a file to suit my 1366×768 display, I think.
I haven’t powered my raspi yet, no micru usb connectors around but I will install a new post so I can run power wires from the protected side to my powered hub anyway.
It sounds like the phone chargers are hit and miss and also it means wires dont have to protrude from all four sides.

Thanks

I’ll have a go at bringing my ‘How To’ page (here ) up to date.

I did find the link to your page this morning by going through the ‘Introduction to RISC OS’ link from the homepage.
Sounds like I should get a display regardless of resolution.
My raspi is powered up now but I only get a red light, so I have some diagnosing to do.
Thanks

I’ve put some PackMan packages for RC8 into the raspberrypi-testing repository. To activate it you’ll need to add the raspberrypi-testing URL to your PackMan ‘Sources’ (instructions ). They work for me but I would appreciate further testing before we push them into the main repo.

In particular, note that the update replaces some files that were previously not packaged, so PackMan will prompt about backing them up. Just agree and it should go through. Also you’ll need to do a hard reset (remove the power from your Pi) to reboot into RC8.

Works on mine, but I no longer get the splash screen. Just a normal bootup text window to the bottom-centre of an all-black screen. No pretty candy stripes or RPi backdrop.

Same here as Andy!

Using RC8, I get the correct splash screen and candy bar (tested on model A and model B 512M). Unless I do an ‘*UNPLUG BOOTFX’ in which case I get no black and white Raspberry symbol, no splash screen or candy bar and the machine starts up FULL SCREEN at 1920×1080 and enters the configured language, which in my case is the DESKTOP (but could equally be BASIC if you tinker with $.Run or with $.!Boot.Utils.DeskRun). This is the correct behaviour, I believe.

Typing f12 then RMREINIT BOOTFX causes a nice black and white raspberry logo to appear on the scrolled desktop screen and the next boot again brings up the splash screen, candy bar etc.

However if I set up networking (using a static IP address but that may not be relevant) then there is no splash screen and no candy bar.

Unticking the ‘enable TCP/IP’ to remove networking again does kill off networking but does NOT restore the splash scrren and candy bar.

Puzzled.

Now I’m more puzzled. Tested again with a fresh RC8 image, set up networking (which changes the following files in !Boot only):

Comparing files DumpBootRaw,fff and DUMPBOOTNET,FFF

***** DumpBootRaw,fff
   56:  SDFS::RISCOSpi.$.!Boot.Choices.Boot.PreDesk.PrintPDF FFFFEB52 DE8CF66C 868A
   57:  SDFS::RISCOSpi.$.!Boot.Choices.Boot.PreDesk.SetupNet FFFFEB52 B1B3AF98 2ED7
   58:  SDFS::RISCOSpi.$.!Boot.Choices.Boot.PreDesk.SoftSCSI
***** DUMPBOOTNET,FFF
   56:  SDFS::RISCOSpi.$.!Boot.Choices.Boot.PreDesk.PrintPDF FFFFEB52 DE8CF66C 868A
   57:  SDFS::RISCOSpi.$.!Boot.Choices.Boot.PreDesk.SetupNet FFFFEB53 33C6B170 9F52
   58:  SDFS::RISCOSpi.$.!Boot.Choices.Boot.PreDesk.SoftSCSI
*****

***** DumpBootRaw,fff
   85:  SDFS::RISCOSpi.$.!Boot.Choices.Internet.Routes FFFFEB4B B646B390 75FE
   86:  SDFS::RISCOSpi.$.!Boot.Choices.Internet.Startup FFFFEB33 6F206792 39F7
   87:  SDFS::RISCOSpi.$.!Boot.Choices.Internet.User FFFFEB4B B646B390 A309
***** DUMPBOOTNET,FFF
   85:  SDFS::RISCOSpi.$.!Boot.Choices.Internet.Routes FFFFEB4B B646B390 75FE
   86:  SDFS::RISCOSpi.$.!Boot.Choices.Internet.Startup FFFFEB53 33C6B164 9395
   87:  SDFS::RISCOSpi.$.!Boot.Choices.Internet.User FFFFEB4B B646B390 A309
*****

[shows file <load> <exec> <crc>]

and this time I get the splash screen and candy bar, no problems. This eliminates the problem being a specific Raspberry Pi board, or board type, or power supply or SD card as these were identical.

I suspect that it is something more subtle, perhaps something to do with date setting/cmos file writing…

Chris, are you saying that you can switch between BootFX/no BootFX just by turning internet on/off? Did you upgrade manually or via PackMan?

I’ve just done this:
Flash RC6 image
Turn on networking
Let !Store and PackMan pull in their updated lists
Upgraded to RC8 via PackMan and raspberrypi-testing
Reboot

And I lose candybar+splash. If I turn networking off again I still lose them.

FWIW PackMan is only copying in ROM files, it doesn’t append any CMOS information to them so by upgrading your ROM you will reset your CMOS. In terms of firmware it’s copying START.ELF, BOOTCODE.BIN and FIXUP.DAT only (and removing old files like LOADER.BIN). The RC8 upgrade also pulled in a CONFIG.TXT which is identical to the RC6 version:

fake_vsync_isr=1
gpu_mem=64
init_emmc_clock=100000000
kernel=RISCOS.IMG

because the CONFIG.TXT in RC6 wasn’t under package management.

(For those who are curious, the build scripts for the packages are in SVN on riscos.info )

Chris, are you saying that you can switch between BootFX/no BootFX just by turning internet on/off? Did you upgrade manually or via PackMan?

After investigation, I can say that ‘CON.LANG.13’ turns the candy bar off and ‘CON.LANG.11’ turns it back on again (although that latter causes CTRL-SHIFT-f12 ENTER to hang but power off/on still works!).

I took a clean RC8 image and started it up several times, shutting it down with CTRL-SHIFT-f12 and then ENTER. Splash screen and candy bar all working fine.

I then did UNPLUG BOOTFX and CONFIGURE LANGUAGE 13 – no candy bar AND full screen – RMREINIT BOOTFX – candy bar back again and text window screen.

I then set up networking and ‘reset now’ and – no candy bar but text window screen.

Took a clean RC8 image again and set up networking but candy bar worked throughout.

Trying to get candy bar and splash screen to vanish under RC8 but currently they are obstinately working correctly.
Note the ‘no candy bar’ behaviour being reported is NOT the same as ‘UNPLUG BOOTFX’ as one has a text window and one is full screen.

If I start again and take a clean RC8 image and set up networking, CTRL-SHIFT-f12 ENTER then starts up with candy bar and splash scrren working correctly. If I then do

UNPLUG BOOTFX
CONFIGURE LANGUAGE 13

RMREINIT BOOTFX

If I then do

CONFIGURE LANGUAGE 11

This appears to be repeatable.

I note that ‘DESKTOP’ has moved from 10 to 11 in the new ROM.

I conclude the problem is related to CMOS settings somehow.

BootFX deliberately disables the splash screen stuff if the configured language does not correspond to the Desktop module. This is because the correct configuration of the machine under normal circumstances is to boot into the desktop (even if something goes wrong in the pre-desktop part of the boot sequence). The only reason you should ever have the configured language pointing at anything else is if you want to boot into something else or debug some early error in the boot sequence, in which case, you probably don’t want full-screen JPEGs and progress bars being blatted onto the screen…

BootFX deliberately disables the splash screen stuff if the configured language does not correspond to the Desktop module.

Ah! I understand.

Changing between pre-RC7 and post-RC7 ROMs (if you save and re-load your CMOS settings for the new ROM rather than re-create them from scratch) is therefore likely to affect the splash screen and candy bar because the configured langauage is tested against 10 (pre-RC7) and 11 (post-RC7). The solution to bring the candy bar back is therefore to do *con.lang.10 or *con.lang.11 as appropriate.

So I’m puzzled. If you change the ROM, you replace the CMOS settings tagged at the end of the ROM, don’t you? Or are they saved elsewhere? By using the default RC8 ROM from the ROOL ROM downloads page, why aren’t we getting the CMOS with BootFX enabled?

I think the issue is if you ‘saveCMOS’ with the old settings with the old ROM and then reload those settings using ‘loadCMOS’ with the new ROM and then shut down. Because the DESKTOP position has changed from 10 to 11 you now have a con.lang. set to 10 rather than 11 and bootfx gets disabled as a result. *con.lang.11 restores things to normal if you get caught by this.

That’s why I’m confused. If I take a vanilla RC6 image, and drop in ROM and firmware from RC8 (at least, the current ‘stable’ ROM on the ROOL download page, which is presumably the RC8 version), I lose candybar. No messing about with CMOS saving and loading, unless the boot sequence does it?

(Don’t have a Pi here to check at the moment)

If I take a vanilla RC6 image, and drop in ROM and firmware from RC8 (at least, the current ‘stable’ ROM on the ROOL download page, which is presumably the RC8 version), I lose candybar.

I have checked the vanilla RC6 and RC8 images and enumerated the changed files:

• RC6
  120: .!Boot.Loader.BOOTCODE/BIN,FFFFE452,E7769208,CRC:937F
  121: .!Boot.Loader.CONFIG/TXT,FFFFFF3A,C7524200,CRC:6099
  122: .!Boot.Loader.FIXUP/DAT,FFFFE452,E7769208,CRC:6FBD
  123: .!Boot.Loader.LICENCE/BROADCOM,FFFFE452,D5C3C0F8,CRC:763C
  124: .!Boot.Loader.RISCOS/IMG,FFFFE452,E7900E40,CRC:3396
  125: .!Boot.Loader.START/ELF,FFFFE452,E7769208,CRC:657D
  1816: .Scrap.ScrapDirs.ScrapDir.SparkFSTmp,FFFFFD53,3ACDB44B,Directory
• RC8
  120: .!Boot.Loader.BOOTCODE/BIN,FFFFE453,1D7B9948,CRC:3B6F
  121: .!Boot.Loader.CONFIG/TXT,FFFFFF3A,C7524200,CRC:6099
  122: .!Boot.Loader.FIXUP/DAT,FFFFE453,2F05D228,CRC:2CB5
  123: .!Boot.Loader.LICENCE/BROADCOM,FFFFE452,D5BE42B8,CRC:763C
  124: .!Boot.Loader.RISCOS/IMG,FFFFE453,2EEE0210,CRC:4E21
  125: .!Boot.Loader.START/ELF,FFFFE453,2F05D228,CRC:2BCC
  *
  If you have not booted from the vanilla RC6 image (which changes it) when you dropped the new firmware into !Boot.Loader and you then power off without shutting down then it will be a vanilla RC8 image and will not cause problems. QED. If you shutdown using CTRL-SHIFT-f12 or ‘Shutdown’ from the task manager menu, then the CMOS settings are saved to the ROM. The boot sequence (below) is eliminated as the culprit:
• RC8
  102: .!Boot.Choices.WWW.NetSurf.Cookies,FFFFFF52,E77F815A,CRC:3EF9
  103: .!Boot.Choices.WWW.NetSurf.Hotlist,FFFFFF52,E77F815F,CRC:5EBC
  106: .!Boot.Choices.WWW.NetSurf.Url,FFFFFF52,E77F815D,CRC:6054
  119: .!Boot.Loader,FFFFC852,E7900E4C,ImageFC8
  124: .!Boot.Loader.RISCOS/IMG,FFFFE453,2EEE0210,CRC:4E21
• RC8 booted
  59: .!Boot.Choices.Boot – populated
  145: .!Boot.Choices.WWW.NetSurf.Cookies,FFFFFF53,3ACF8A29,CRC:3EF9
  146: .!Boot.Choices.WWW.NetSurf.Hotlist,FFFFFF53,3ACF8A3D,CRC:5EBC
  149: .!Boot.Choices.WWW.NetSurf.Url,FFFFFF53,3ACF8A33,CRC:3D56
  162: .!Boot.Loader,FFFFC853,3ACF8AE8,ImageFC8
  167: .!Boot.Loader.RISCOS/IMG,FFFFE453,3ACF8BA8,CRC:9A8A
  1859: .Scrap.ScrapDirs.ScrapDir.Ghostscript – new
  1861: .Scrap.ScrapDirs.ScrapDir.PrintPDF – new
  1863: .Scrap.ScrapDirs.ScrapDir.RUfl_cache – new
  1864: .Scrap.ScrapDirs.ScrapDir.SparkFSTmp – new
  1866: .Scrap.ScrapDirs.ScrapDir.WWW – new
  *
  So my thinking is that if you boot from the RC6 SD card, then put the new ROM and firmware onto it, then when you shutdown the CMOS settings are saved into the new ROM but the settings are based on the old ROM (i.e. a con.lang. of 10) which has the effect of turning off the candy bar because the desktop is at position 11 in the new ROM. So when you copy the new firmware onto the card you also need to do a *con.lang.11 – strictly you should check the configured language and any unplugged modules and alter the numbers accordingly to suit the new ROM.

Thanks Chris for the investigation, that does sound like a problem. I’ve opened a bug ticket

To followup to my bug ticket, I thought of a way to implement a CMOS fixup program. This is included in a new package to upgrade to RC8, which is in the raspberrypi-testing repository. If you upgraded and lost candybar it should fix that for you, even if you’ve been running RC8 for some time. I’d appreciate feedback. It should be safe even if you’re on the new ROM already – it just won’t do anything. It will also delete itself once run, so you won’t have it hanging around your boot sequence.

This approach isn’t very clean though. Checking the configured language is a bit hackily-specific to this case, so one idea to make this easier in future is to put the build date/revision/CVS tag into CMOS somehow (eg the 16 bytes where the clock normally lives) so it’s possible to distinguish them.