RO 5.22 for Pi

Just to keep some sense of proportion, for an OS that seems to generate such concern I do have to say it works really rather well on my Raspberry Pi. As fas as stability goes, that property that the RPi OS apparently has none of, my Pi is more stable than any of its stable predecessors.

 ^
/|\
 |

What is the point of this utter drivel. The downside to the write back to the ROM image is only that the ROM image cannot be renamed.

and you can’t run a POST on the ROM because it changes every time you shutdown?

You linked to the page Jeffrey produced yourself, did you read ALL the content?

and you can’t run a POST on the ROM

Big deal, so what. What is a potential user in search of stability to make of all this, some trying to talk the OS up giving reasonable descriptions its actual performance against unfounded allegations of cannibalistic tendencies.

To change which I’m booting from, I delete RISCOS/IMG, then copy my chosen one as RISCOS/IMG.

Sounds like a plan – though presumably with a tweak when CMOS settings are changed, resetting to update the current ROM, save that and then replace with the chosen one for the next session?

My RISC OS image is on a SCSI pen so the SD card is very simple, Fat with no partition, just the firmware and ROM.

Also on the to-do list!

You linked to the page Jeffrey produced yourself, did you read ALL the content?

Did you?

and you can’t run a POST checksum on the ROM because it changes every time you shutdown?

There. Fixed that for you. ;-)

What is a potential user in search of stability to make of all this,

Probably won’t be reading all of this then.

It is easy to find reasons to discount practically any operating system. Just look for either “0day” or the outstanding bugs list / bug tracker… ;-)
Or read the developer forum and feel the pain dealt out by moderator devs in bad moods. Or read forums and learn quickly what to stay away from. Or…

Better, perhaps, to accept that nothing is guaranteed to be stable (my first try of Ubuntu since single digit version numbers and it BSOD’d on me, yay!) and nothing is guaranteed to be secure (here’s a little Linux exploit; likewise most smartphone “rooting” also depends upon using exploits to break into the phone’s OS to super-authorise the user account).

Once you accept that, you can then pick whatever OS you think is going to do the things that you want it to do. RISC OS? Hopeless for watching movies. Rather good for low level GPIO stuff (specifically because you can take over the machine and more or less tell RISC OS to shuddup…).

though presumably with a tweak when CMOS settings are changed

It’s easier than that. If the ROM is being changed is on the in use card inserted in the Pi then on startup the CMOS settings are read, the ROM image gets changed then on closedown the CMOS settings are written back to new ROM image. The status quo CMOS-wise prevails. Works a treat here.

If the change is done elsewhere then the default CMOS will be applicable when the card is first used in the Pi. CMOS can be saved from within RISC OS but that goes to a file in Choices somewhere which is not active but can be reloaded later if one finishes up in a situation where the default CMOS has been applied.

There. Fixed that for you. ;-)

Ta.
Dashed it off while logging on to a remote connection to work.¹ Should pay more attention to what I’m typing.

¹ Fixed one problem, the other will wait until the morning as the device is still passing traffic even though the management agent is down.

I can’t see the problem here before running new Rom, check the home page see what has changed do you think it’s going to cause any problem yes no. if you are worried don’t use it. i would hope that everyone would run the nightly builds on a second card to test it and report any problems so they can be fixed.
It only needs to be a small SD card with just fat and the rom set to boot a usb stick or hard drive on sdfs as your main drive.
when you want to do any real work then use a second sd card with a version that you know works.

Was just reading through the CVS change list (nothing on TV ;-) ) and… yeah… they’ve done it again…

not only that, but the firmware that gets the thing going has changed numerous times too – and not necessarily in compatible ways.

https://www.riscosopen.org/viewer/revisions/logs?ident=1436991183-203536.html

I rest my case.

I want to run RO V5.23 with ‘added ZeroPain’ (i.e. after 4/7/15 version) on a Raspberry-Pi. The boot loaders ‘partition’ had the 4 bootloader (excluding the ROM) with (CONFIG/TXT) dated 9/2/15, the other 3 dated 6/2/15 and the ROM was version 5.21. So I deleted that ROM file and copied in ROM v5.23 dated 25/7/15. On powering up, it halted on the line after “int mod internet”:
“int mod Resolver error: DataAbort: Abort on data transfer at &FC01EC30 (Error Number 80000002)”
Why?
Please note that the digits were very small and hard to read on the lapdock screen, particularly, what I have written as zeros. So the address and error number may be wrong.
Changing CONFIG/TXT to one dated 13/1/15 and the other 3 bootloader files to ones dated 7/1/15 and using a non-ZeroPain ROM V5.23 worked; but I wouold like to run a ZeroPain version as I am on my Pandboard.
Where do we download the appropriate bootloader files?

Added comment: This isn’t about RO V5.22, the thread heading, but if you average two version numbers above, you get 5.22. So will that do? :-)

The bootloader files supplied with RC14 should still work with the latest ROM (they definitely work with the 5 July release).

I have had problems in the past if I shut down and restart after replacing the ROM, as opposed to pressing Ctrl-Break. This is presumably because doing a proper shutdown causes it to keep the 5.21 CMOS settings. No idea whether it’ll help in your case, but it might be worth a shot.

So I deleted that ROM file and copied in ROM v5.23 dated 25/7/15. On powering up, it halted on the line after “int mod internet”:
“int mod Resolver error: DataAbort: Abort on data transfer at &FC01EC30 (Error Number 80000002)” Why?

It is a beta. There was a bit of a breakage, a very rare event and raised at the time in the Bugs section , anyway it is fixed now with the 2015-07-31 ROMs.

it is fixed now with the 2015-07-31 ROMs.

The only fly in the ointment being that, at time of writing, you have to build them yourself.

The only fly in the ointment being that, at time of writing, you have to build them yourself.

I suppose a further fly in the ointment would be if the daily source code archive failed to build.

USBDriver (mixed.RiscOS.Sources.HWSupport.USB.NetBSD.build)...
amu -E  rom_link ADDRESS=4229740376 LINKDIR=HostFS::HardDisc4.$.ROOL.BCM2835Dev.Install.ROOL.BCM2835.USB COMPONENT=USBDriver TARGET=USBDriver
AMU: failed to read time stamp for 'o.'
AMU: failed to read time stamp for 'o.'
Error running make rom_link on module 'USBDriver'.
Fatal error running make rom_link on module 'USBDriver'.
Batched errors...

I have tried on two different platforms, VRPC OS4.39 and Raspberry Pi OS5.23 (31-Jul-2015), both failed at the above point.

It looks like a fix for that is now in CVS (an Iyonix ROM just built fine for me), so tomorrow’s source archives should be fine too.

Not sure what the status is with the build machine – I’ll try and get an update from ROOL if it isn’t fixed in the next day or two.

@Chris Mahoney
The RC14 2GiB disc image that you refer to wastes space on the larger SD cards that I like to use. Also I don’t want the hassle of copying in all my applications and other files that I have on the other ‘partition’. I have been on about this before: I just want to copy in the bootloader files which is much easier and quicker. At other times, I just want to copy in the RISC OS ROM. I guess I could copy the disc image to any ‘empty’ SD card (>= 2GiB) and then copy the bootloader files from there, or get them from the Raspberry-Pi website not being sure that they will work. Wouldn’t it be simpler if these files were on this website?
Thanks for your other suggestion.

Unzipping the image file and opening that with 7zip allows you to extract the bootloader files without need for a second SD card – assuming you have a Windows/Kinux machine on which to run 7zip (or alternative de-archiving software that can handle the .img file). Mounting the DOS partition as a loop device may also work.

But agreed that a concurrent set of Loader files as a download would be nice to have, whether instead of or alongside the bare ROM file.

Thanks for that information, but I have a principle of doing everything on RISC OS except if that is impossible.
In the latter case I use linux and, only if that doesn’t work, will I use Micro$$$oft. :-((

There’s always SystemDisc 1.02 which will re-partition an SD card.

There’s always SystemDisc 1.02 which will re-partition an SD card.

Speaking as a satisfied customer with no other connection, I can recommend it.

There’s always SystemDisc 1.02 which will re-partition an SD card.

But destructively, I presume? Looking forward – as a “nice to have” – to being able to expand the filecore filing system on the fly to use available free space!

The NOOBS SD card allocates 4GB for RISCOS, but inefficiently – 1.8GB of files take up 3.6GB disc space – I presume a matter of wrong sector size and/or LFAU.

SystemDisc much more tempting to make better use of two 8GB cards entirely for RISCOS (having moved Raspbian to a 16GB microSD in the Pi2!).

The NOOBS SD card allocates 4GB for RISCOS, but inefficiently – 1.8GB of files take up 3.6GB disc space – I presume a matter of wrong sector size and/or LFAU.

A ROOL disc image is designed to fit on most 2GB cards (many 2GB cards are actually closer to 1.8GB)
NOOBS takes a compressed copy of the 1.8GB image and writes it to the appropriate part of the card.
Changing a RISC OS partition size whilst it has data within it would be a massive programming job (Man years of work at a guess) so is not going to happen.
Only a few people need partition resizing and SystemDisc provides a work around. So not a priority.

Looking at the NOOBS card under Linux, the RISCOS partition is 1.9GB but for some reason RISCOS’s own Filer “free” reports the “disk” SDFS::0 as being 4GB. This is the partition table, as shown by fdisk in expert mode, of an 8GB SD card with NOOBs set up only to run RISCOS:

Device         Boot    Start      End  Sectors Id Type            Start-C/H/S End-C/H/S Attrs
/dev/mmcblk0p1          8192   240234   232043  e W95 FAT16 (LBA)     128/1/0 1023/16/3    00
/dev/mmcblk0p2        245760 15628287 15382528 85 Linux extended    1023/16/3 1023/16/3    00
/dev/mmcblk0p3      15628288 15693823    65536 83 Linux             1023/16/3 1023/16/3    00
/dev/mmcblk0p5       3604480  3700735    96256  c W95 FAT32 (LBA)       0/0/0     0/0/0    00
/dev/mmcblk0p6       3702784  7614463  3911680 83 Linux                 0/0/0     0/0/0    00

It is as if Filecore/SDFS sees each “Linux type” sector in /dev/mmcblk0p6 as being 1KB rather than 512B.

Partitions 1 and 3 are the NOOBs stuff, 5 the equivalent of “Loader” on the ROOL image, which shows up as partition 1 [of 2] using fdisk but disappears using acorn-fdisk (again an 8GB card but with a directly written 2GB image the other 6GB is lost:

Device     Boot Start     End Sectors  Size Id Type
/dev/sdd1  *       10   98313   98304   48M  b W95 FAT32
/dev/sdd4       98314 3839999 3741686  1.8G ad unknown

Device Boot   Begin    Start      End   Blocks     Id   System
/dev/sdc1            0        0      253    1920000    100  Filecore
/dev/sdc2          253      253      253          1   fffe  Reserved/Free

So a scheme to expand (only within the limits of using the same LFAU etc – a single special case of changing size) the partition of a ROOL image would need to:
1. amend the “Filecore/Linux” partition table (as acorn-fdisk calls it) to “End” = 1000 (say) and update the Reserved/Free information
2. amend the DOS partition table that fdisk sees to increase the end address of partition 2 to be consistent with End=1000
3. amend the RISCOS disk map only to the extent of adding on a lump of free space
4. move sectors that filecore/SDFS expects to find in the middle/end of the disk to the new middle/end
5. DiscKnight thoroughly!

I presume 3 and 4 are the non-trivial bits without the coding time equivalent to that which must have gone into developing Linux tools such as e2resize.

Having purchased SystemDisc, I am slightly foxed by the Pi’s refusal to play nicely with my SD card readers (the Pi2 with Raspbian has problems too so I suspect it’s a case of false economy in buying cheap ones – one seems fine with a Lenovo laptop but not with my parent’s older Advent, and the other generally dead!). So I shall have to do everything through SDFS, unless “nuking” the NOONBs partition table will make that card more amenable. Bit awkward to extract an SD card from the Pi itself without unplugging power, so I am thinking of adding some “tabs” of insulation tape to make that easier and temporarily setting up a USB drive with !Boot. Then rather than use SystemDisc on a SCSI-mounted SD card I shall configure filesystem SCSI and apply SystemDisc to SDFS.

After thoroughly backing up first, of course!