RISC OS Pi RC7 has been released

See our news post for more information.

Regarding the image:

Is the information Dave Ruck posted in the community forum of any relevance?
i.e. Maybe he has discovered a problem waiting to bite.

https://www.riscosopen.org/forum/forums/11/topics/1744?page=1#posts-20927

The numbers he quotes suggest that the R6 image was originally made as a 1Gb and then amended to a 1.891 G image, but part of the crowbar/delicate fiddle wasn’t quite right.
Issues for most people are unlikely to occur until they start filling things significantly.
If this is fixed in R7 all is well.

Extend upper permissable file size to 4GB-1 bytes.

This would seem to be an important and very welcome new feature.

It does present an important question. What do older OSes make of the bigger files?
(i.e do you need to take care not to put them on drives that might be used on older versions, or can it be softloaded.)

Will there be a new Iyonix flash containing this?

And is it worth holding on for packman to deliver it (or is it there already?)

Thanks

We’re working on the PackMan update and we’ll take a look at Druck’s comments, thanks.

Nice to see DOSFS will cope with devices up to 4Gb now. The question I have is: Is DOSFS smart enough now to refuse to mount larger devices that it cannot handle?

Is there any reason to carry on with the image file system?

As far as I can see it is only needed to manage the DOS partition files under RISC OS.

This can now be done with FAT32FS.

There is a minor bug in RC7. If you follow instructions to set up networking [even if you have set up networking and make no further changes] and then ‘reset now’, it just gets as far as a blank black screen with a flashing cursor and stops. That is not quite as far as displaying the black and white raspberry. It needs a power off and on to continue. CRTL-SHIFT f12 restarts OK subsequently.

I couldn’t get network access at all until I filled in the Primary name server field of Host names. I don’t have that filled in on RC6. Netsurf insisted there were SSL errors. I’m not using SSL.

After setting up the name server, finally I can access internet, but a bit more slowly than the previous release.

This is on a 512 “B”. All my boards have Samsung dram.

I’ll do more testing to see if anything specific crops up.

On RC7, after filling in the primary name server (I just put 192.168.1.1 my ADSL router) I am getting (for example) ‘Failed to connect to 212.58.244.58 host unreachable when clicking on ’BBC News’ in Netsurf.
Edit: ignore this – I use static IP and forgot to set the gateway address. Now sorted.

Are you using DHCP or fixed IP?

If fixed IP, you need to set the ADSL router as the “gateway” so the machine knows how you direct packets to reach the outside world…

Many thanks for the swift reply. I am using static IP. Mea culpa – I have now remembered to set the gateway. The ‘reset now’ still fails though.

(I just put 192.168.1.1 my ADSL router)

Yes, likewise I input similar.

Netsurf appears to struggle to find some sites now.

Rick,

Are you using DHCP or fixed IP?

don’t know if you mean me or Chris Hall, but in my case, both, depending on which SD card I plug in, but the access problem resulted from trying DHCP :-)

I don’t get any reset problems though. I’ll try another board….

Interestingly, if I now click on a plugged in SD card-in-a-reader which has multiple partitions, a “middle mouse click” highlights a new? partition field in the popup menu.

Interestingly, if I now click on a plugged in SD card-in-a-reader which has multiple partitions, a “middle mouse click” highlights a new? partition field in the popup menu.

That’s because you’re using FAT32FS.

When RC7 starts up it shows 128Mbytes free for RISC OS whereas RC6 showed 448Mbytes free. Where has the memory gone? The file ‘FIXUP.DAT’ seems to be missing from RC7 – this may be the problem? Also the ‘CONFIG.TXT’ file has ‘0A’ line terminators whereas RC6 had ‘0D0A’. ‘START.ELF’ is also 9/3/2013 on RC7 whereas I have updated my RC6 to 7/3/2013 STart.ELF and the latest ROM. Hope this helps.

That’s because you’re using FAT32FS.

Noted, thank you.

I inadvertently plugged in the wrong one of 2 same type usb sticks, & RISC OS stopped with a divide by zero error. I eventually recovered after several ALT break key presses. Subsequent accesses came back with “Not a valid DOS image”. It was a NTFS formatted stick.

When RC7 starts up it shows 128Mbytes free for RISC OS

Same here. It appears to be hard-wired as changes to gpu_mem have no effect.

Identical results for a model “A” Pi.

The file ‘FIXUP.DAT’ seems to be missing from RC7 – this may be the problem?

Adding this back again and the machine starts up with 448Mybtes. The ‘reset now’ option also now seems to work…

Adding this back again and the machine starts up with 448Mybtes.

Bizzarely, makes no difference here, but replacing start.elf does fix it.

Appart from the required files (start,elf) that are missing (and which can be found on the github kernel page of Raspbian) it is faster then RC6.

It would have been nice if someone actually explained to (less technical enclined) how to retrieve those missing files. I’ve put them on my RPI-webserver at

www.manutec.be/FILES/RC7-FILES.ZIP

Put these in the root of your PiBoot SD-card. They include the RC7-RISCOS-image as well as my CONFIG.TXT. This uses the config_HDMI_boost-line because my acer widescreen display gives green artifacts at the left side o/t screen otherwise. Courtesy of a 3m long cheap crappy HDMI-cable. So perhaps you may like to comment out the HDMI-flags.

Firebench noted 198 fps on RC7 while RC6 has 186 fps on the same 860MHz clocked RPI (for the technically interested, CPU:860, core:375, mem:500). The CONFIG.TXT from my zip-file has these settings.

But there are other major issues. For instance SF3000 doesnt seem to work anymore. It does work when you use the mouse but switching to keyboard crashes the whole system. Also login into this website with netsurf crashes the entire system. It seems there are major issues with keyboard input.

For now I’ve reverted back to RC6 because RC7 is not fit for release IMHO.

But the speed up was very welcome.

Regards

For now I’ve reverted back to RC6 because RC7 is not fit for release IMHO.

Just for what it is worth:

1. What sort of Pi do you have? And what sort of memory?
2. Do these problems still exhibit themselves when you run the Pi at normal speed instead of overclocking?

And for ROOL:

1. What is RC7 exactly? A recent build? From when? Or is it something special? I mean, if the nightly builds work, and RC7 is one of them, surely there shouldn’t be any specific issue here?
2. However it appears that there are quirks/issues with the firmware – one person says fixup.dat was wanted, another said it was start.elf… Are these problems specific to certain types of Pi board? We now have five variants to deal with: Model A, Model B 256M old, Model B 256M new, Model B 512M, Model B 512M Hynix – do they all operate (GPIO reassignment aside) in the exact same way or are there subtle differences here? Or maybe it’s just the wrong this with the wrong that ?

So for everybody:

• When you report something that does or doesn’t work, and/or possible fixes, could you please add the exact Pi type? This should help see if patterns emerge…

Hmmm… when trying to reply Rick Netsurf crashed.
RISC OS on the RPI is definitely not stable.

Anyway, I have 3 RPI Model B 512MB all with Samsung memory. I believe the Farnell ones come with Samsung memory. All my RPI came from farnell/E14

I have models from mid-october 2012 and recent ones from last week.

I did notice that the new batch can’t be overclocked as high as the old batch. But that they run a little bit faster when both models are clocked at the same speed. Firebench noticed about 4fps difference when both where clocked at the recommended stable maximun of 840MHz (October2012 model 182fps, Februari2013 model 186fps).

I tried without overclock the exact same thing happens.

So to recap:
1) I have Model B’s with 512MB from Farnell (with Samsung memory)
2) Yes

1) RC7 is the new (incomplete) release as is on Raspberry Foundation website since yesterday
2) In essence the fixup.dat is missing but you have the find the right one. Otherwise the RPI will still boot with only 128MB. I downloaded and replaced both start.elf and fixup.dat with the latest ones from the kernelpages at github. And with both replaced I have the full 480MB ram again (with a 32MB video split)

one person says fixup.dat was wanted,

I said this because (i) ‘fixup.dat’ was not included with RC7 and (ii) the memory allocation problem went away when it was added. I also checked bootcode.bin against a set of firmware I had downloaded two days previously and its CRC matched (thus eliminating it as a suspect). In the case of ‘start.elf’ what was with RC7 was a later version than what I had downloaded (and tested with a debug ROM but with ‘fixup.dat’ present) and so it had to remain on the list of suspects.

another said it was start.elf…

what he said was that he had replaced‘start.elf’ with a different (earlier?) version to overcome the problem. The latest firmware is however required on the latest boards so this is not likely to be a viable solution.

For now I’ve reverted back to RC6 because RC7 is not fit for release IMHO.

So far I prefer the even numbered releases.

Okay persistance pays off.
I managed to isolated the problem that I have.
My configuration is this.

Raspberry Pi model B 512MB (samsung memory)
Using RISC OS Pi RC7

I have a keyboard with Netherland-qwerty-layout.
This keyboard has next to the letter L the + and next to that ’ (hyphen) and next to that the < key with a big Enter key at the last position.

Whenever I press the ’ key and after that another key I get an “abort on data transfer at &FC248244”-error.
This happens ALWAYS. Not only in SF3000 or Netsurf but even when I just boot-up and press the ’ and then another key (it doesn’t matter which key).

I’ve set the keymap to UK-default and the error is gone. When I set it to e.g. Belgium then again one o/t special punctiation keys creates this abort on data transfer error. It seems that this error only happens with international non UK/US-keyboards which uses special keys to get accented characters.

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. I’ll whipp-up a !Boot-file that international users can drop-in using the normal installation procedure (!Boot → Boot → install). This will simply put the old v0.94 module in PreDesk to RMLoad it at boot.

You can find it at:

www.manutec.be/FILES/KBMODULE.ARC

If a ZIP-file is more convenient

www.manutec.be/FILES/KBMODULE.ZIP

You might need to set the proper filetype (for the ARC-file) or just drop it on e.g. SparkFS.
I hope I can help other international users out there with this (so we can all enjoy Star Fighter 3000 again) ;-)

Whoohooo!

I’ve set the keymap to UK-default and the error is gone. When I set it to e.g. Belgium then again one o/t special punctiation keys creates this abort on data transfer error. It seems that this error only happens with international non UK/US-keyboards which uses special keys to get accented characters.

From reading the change log, it looks like an amount of work was done to support “wide” keypresses in the keyboard driver, but… oops, it looks like it might not have been tested on a non-UK keyboard with dead keys.
The French keyboard is similar with a ^ / ¨ key for adding accents; though I’ve not tried this (busy trying to get Angstrom to boot correctly on the Beagle (keeps skipping the setup part and telling me there are no configuration files!)) – not installed RC7 on the Pi – yet.

Just a thought for the future – maybe ROOL ought to hide the latest image here someplace so we can test drive it prior to a public release? There’s enough variations of hardware and usage around that I’m sure we will be fully capable of breaking it. ;-)

Just a thought for the future – maybe ROOL ought to hide the latest image here someplace so we can test drive it prior to a public release?

Um, but the changes to the keyboard handler were made over 3 months ago . Does that mean that nobody’s actually trying out the nightly builds? RC7 is just a freeze of the nightly build after all, not some secret thing ROOL had up their sleeves.

RC7 is just a freeze of the nightly build after all,

That’s what I thought.

Does that mean that nobody’s actually trying out the nightly builds?

More specifically – is anybody trying out the nightly builds on non-UK setups? I have an old version (when SDFS was new) on the Beagle. Loathe to mess with that too much as it is a working system. On the Pi, I updated to a recent nightly (last month sometime?) but won’t have run into this as I would sell my soul to erase the programmer-unfriendly AZERTY keyboard from my mind; consequently I use a quirky British layout keyboard.

Maybe it is worth casting around to see if there are non-UK users with non-UK setups trying out the nightly builds. I would imagine not, as a crash as soon as you use a dead key for accents is…pretty obviously something wrong! Unless, that is, all the non-UK users with non-UK setups only ever type stuff in English… ;-)

BTW – I spent a few fruitless hours setting up a fresh image of Angstrom Linux on the Beagle xM and the piece of crap (CircuitCo’s version of Angstrom) bluntly refuses to let me configure anything aborting with a message saying:

The configuration could not be loaded
An unknown error occurred.

(useful!)

Thus meaning it is impossible to configure the system, as it happens for anything under System → Administration.

Anyway, the quirky keyboard plain does not work under Angstrom. The driver probes it, and gives up:

usb 2-2.4: new low speed USB device using ehci-omap and address 4
usb 2-2.4: New USB device found, idVendor=04d9, idProduct=a055
usb 2-2.4: New USB device strings: Mfr=1 Product=2, SerialNumber=0
usb 2-2.4: Product: USB Keyboard
usb 2-2.4: Manufacturer: KB
input: KB USB Keyboard as /devices/platform/ehci-omap.0/usb2/2-2/2-2.4/2-2
.4:1.0/input/input2
generic-usb 0003:04D9:A055.0001: input: USB HID v1.10 Keyboard [KB USB Key
board] on usb-ehci-omap.0-2.4/input0
generic-usb: probe of 0003:04D9:A055.0002 failed with error -22

So that it (mostly) works under RISC OS is one up on Linux! ;-)