What has changed in RISC OS 5.21 startup?

My CJELEDs module (talks IIC to a plug-in board) fails on the RaspberryPi when it is placed in !Boot.Choices.Boot.PreDesk – the machine will crash upon entering the desktop; crash is at &FC01xxxx (nearby code is something to do with chocolate heaps) and most operations (*Basic, etc) fail due to running out of memory.

If I place this module into a fake app within !Boot.Choices.Boot.Tasks then everything works just fine.

Worked okay on 5.19 (numerous versions). Fails on 5.21 (latest build). I didn’t see a version of 5.20 for the Pi.

Also, I think part of !Configure is broken. My PreDesktop file is in the 520Hook but the keyboard configuration and “Boot→Look at” both seem to be looking at something else. It is worse in the case of Config→Boot for it is looking at Choices$Write which will clearly never see the 520Hook version (just do *Show Choic* in the CLI, you’ll see why).

I found the move to 5.21 quite difficult. I ended up deleting the !Boot.Choices.Boot directory completely, booting into 5.21 (which populates the directory from RO520Hook, RO510Hook and RO500Hook appropriately) and then looking at the extras in the old version and copying them over (very) selectively and only where there was no file of the same name already.

Moving to a new decade (?) like 5.2x will involve a bit more effort than a move from 5.1x to 5.1y.

At first it refused to boot. I first panicked about trashing my partitions, until I noticed that the activity LED was blinking in a pattern (eight flashes, pause, eight flashes, pause…). That got me to thinking my previous firmware was from October last year, so maybe I need new low-level firmware? I went to the github place and downloaded loader.bin, fixup, and the big elf file.
Then it booted.

I also updated the harddisc files, copied the old !Boot out of the way and put back the stuff I wanted (ZapFonts, etc). I don’t know what to do with the VCIHQ (sp?) bits, but I noticed there was a module of that name in the ROM so I just left it out. Seems to be working like that.

It’s different not seeing the list of module inits whizzing by.

I reckon boot could be damn fast if it wasn’t for the OS decompression. It might be an idea, perhaps, to put a message on-screen saying “Decompressing image…” or some such instead of the Pi loader screen and a blank rectangle for several seconds.
Though, to be honest, with a pile of memory in these machines, plus ample space on the FAT side of the SD card…
…why are we bothering with decompressing the OS in the first place? What do we actually gain to make it worthwhile over lengthier boot-ups?

I don’t know what to do with the VCIHQ (sp?) bits, but I noticed there was a module of that name in the ROM so I just left it out. Seems to be working like that.

Correct, VCHIQ is now in ROM so the softload in !Boot can be discarded (in fact the latest disc image doesn’t include it at all).

I reckon boot could be damn fast if it wasn’t for the OS decompression. It might be an idea, perhaps, to put a message on-screen saying “Decompressing image…” or some such instead of the Pi loader screen and a blank rectangle for several seconds.

ROM decompression is pretty fast, somewhere under half a second (I don’t have my Pi set up at the moment, but a quick test with the Iyonix shows it can decompress a Pi ROM in 0.56s). Most of the time during boot is probably spent enumerating USB devices, which is pretty slow (about 600ms per device). Try *unplug DWCDriver and then see what happens ;-) (Or just grab a copy of the rompress tool, e.g. from a source archive, use that to decompress the ROM, and save it over the one on the card)

…why are we bothering with decompressing the OS in the first place? What do we actually gain to make it worthwhile over lengthier boot-ups?

I can’t remember the exact reasoning, but I think it was purely down to decreasing the amount of space needed on the SD card. At the time it was implemented, I think we’d already determined that the bootloader was driving the SD interface at high speed – so using a compressed ROM might actually be making us a bit slower (compared to, say, OMAP3 where u-boot is pretty slow at loading from SD)