Pi4 ROM 21-02-23 fails startup

RPi 4 in ‘Fourtress’ case (but only association is FArgoN app), !Boot/HD4 on SSD. 21-02-23 ROM

Pi’s LED flashes to show uSD card being read but display remains blank, keyboard lamps fail to flash. Startup messages – none. Presents as dead. Reverting to 16/02/23 ROM brings normality.

Downloaded & tested twice.

RPi 2 issue 1 – same problem.

Which prompted me to think this:

Faced this morning with a failure of the upgrade development ROM image, a thankfully rare occurrence and quite possibly due to a corrupted image, caused me to reflect.

I do keep a copy of the previous working ROM image in the Loader directory and have a script there to replace a new image with the previous one, but using this requires a working back-up card/machine, and I was wondering if there was any possibility of performing the equivalent of this DELETE/COPY/RENAME procedure before RISC OS itself boots.

This might need the RPi boot system reading CONFIG/TXT to, say:

    1. Respond to a held-down key selectively

    2. Be able to either perform file operations or be able to conditionally alter the line loading the RISC OS ROM image to load a back-up file instead (the line starting "kernel=…).

I appreciate that point 1 is extremely unlikely – but is there a similar hardware solution available – some pins which could be tested?

I have no idea at all what is possible in whatever minimal OS performs the RPi boot, but put the idea forward just in case it stimulates an idea in the mind of one who does!

You can’t rename and move files, the bootloader doesn’t work like that. ;)

But I believe you can use the state of GPIO pins to alter how the machine boots.

I can’t help, as I’ve not done it ¹, but if it’s possible to use this to dual boot RISC OS or Linux, I don’t see why it can’t be used to selectively boot a different version of RISC OS? Set this to be a known good version and you’ll be good to go.

Take a look at https://www.raspberrypi.com/documentation/computers/config_txt.html#the-gpio-filter

Let me know how you get on.

¹ No impetus, given I can pop the card into a reader and into my phone…

No impetus, given I can pop the card into a reader and into my phone…

It was just an idea! No real motivation here, as I have more Pis than sense, but…

But a useful idea using the ‘phone! I expect my Andrex tablet would work as well! Must check! I’ve got a suitable USB adapter lead.

Should have run it by you first!

Take a look at https://www.raspberrypi.com/documentation/computers/config_txt.html#the-gpio-filter

Let me know how you get on.

Gosh, that looks easy!

For what it’s worth, the IOMD ROM also fails, with the error “System.Modules.Toolbox.Toolbox not found”.

RISC_OSLib-6_18 looks to be the problem.

I can’t help, as I’ve not done it 1, but if it’s possible to use this to dual boot RISC OS or Linux, I don’t see why it can’t be used to selectively boot a different version of RISC OS?

Exactly what I was talking about when I mentioned the modified softloader the other day.
From the response, I think Martin may be working on something like that, and possibly exactly that.

My thinking was that it would be useful if a developer could quickly switch between several revisions of the OS, but I suppose it’s just as useful for the run-of-the-mill-victim (er, beta tester) trying the nightly builds

I think Martin may be working on something like that

Sorry, not me. My draft changes only affect machines with ROM in firmware eg RiscPC, Iyonix & Titanium. Though I did wonder if the Softload program would (or could) work on other machines – but that is out of my league.

the IOMD ROM also fails, with the error “System.Modules.Toolbox.Toolbox not found”.

Hmm!!! As far as I can see the Toolbox module is in the ROM.

*Desktop errors with SWI &42701, Squash_Decompress not found. The Squash module is in the ROM but *help Squash gives ‘no help found’.

*Modules only shows 79 modules, a working ROM has 127. Squash and Toolbox are missing.

I begin to wonder if the issue is C modules not initialising.

The fault does go away with ROM builds reverted to RISC_OSLib 6.17.

No diagnosis is possible on the Titanium or Pi due to no display starting.

*Modules only shows 79 modules, a working ROM has 127. Squash and Toolbox are missing.

I think the clue is that looking at the *Modules list and *ROMModules list, all the C modules are missing, and attempting to RMReinit one of them gives “Static data size in library and stub disagree”. What that normally means is someone added (or removed) a global variable without updating the magic table saying how many there are, but in this case I can’t spot that in RISC_OSLib-6_18 changes, so hopefully Jeffrey will be online with a keener eye.

RISC_OSLib-6_18 is indeed the culprit, and is stopping all ROM C modules from initialising – my apologies. It looks like I upset some subtle/fragile part of the system that’s responsible for deciding how big the static data areas are. I’m still looking into it, but it looks like it was reliant on the order that the linker places several identically named C$$data sections (yikes), and the makefile changes probably changed that order, causing the different markers to shift around and result in different static data sizes being calculated.

MR is now up to revert some makefile “improvements” I made. This should get things working again: https://gitlab.riscosopen.org/RiscOS/Sources/Lib/RISC_OSLib/-/merge_requests/31

MR is now up to revert some makefile “improvements” I made. This should get things working again

The good news is that 23Feb23 builds are working again. ROMs, and !Boots, checked on Titanium, RPi4, RPi400 and RPCEmu.