Pi4 ROM 21-02-23 fails startup
Frederick Bambrough (1372) 835 posts |
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. |
John WILLIAMS (8368) 490 posts |
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! |
Rick Murray (539) 13750 posts |
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 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? 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. 1 No impetus, given I can pop the card into a reader and into my phone… |
John WILLIAMS (8368) 490 posts |
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! |
John WILLIAMS (8368) 490 posts |
Gosh, that looks easy! |
Stuart Painting (5389) 709 posts |
For what it’s worth, the IOMD ROM also fails, with the error “System.Modules.Toolbox.Toolbox not found”. |
David Pitt (9872) 341 posts |
RISC_OSLib-6_18 looks to be the problem. |
Steve Pampling (1551) 8125 posts |
Exactly what I was talking about when I mentioned the modified softloader the other day. 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 |
Martin Avison (27) 1479 posts |
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. |
David Pitt (9872) 341 posts |
Hmm!!! As far as I can see the Toolbox module is in the ROM.
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. |
Sprow (202) 1150 posts |
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. |
Jeffrey Lee (213) 6048 posts |
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. |
Jeffrey Lee (213) 6048 posts |
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 |
David Pitt (9872) 341 posts |
The good news is that 23Feb23 builds are working again. ROMs, and !Boots, checked on Titanium, RPi4, RPi400 and RPCEmu. |