Raspberry Pi ROM upgrade simplification
John Williams (567) 768 posts |
I have devised, for my own use, a simple way of upgrading – or downgrading if required – the RPi ROM image. The ROM image is delivered as a file “riscos” in the ZIP archive. Copying that as-is into the Loader directory/partition, assuming you are using the standard name “RISCOS/IMG” for your loaded ROM specified in CONFIG/TXT, will allow my simple Obeyfile script to replace that image with the new version with a simple double-click. It will also keep a copy of the previous ROM image in case you need to revert. The obey script, UpGrade, is as follows:
and the accompanying notes, Upgrade_Info, explain further what’s going on: The obey file "UpGrade" automates part of the process of upgrading the rom image - the renaming of files - and provides a back-up of the previous image. If you copy the new ROM image "riscos" into this directory and double-click the obeyfile "UpGrade", the following will happen: If "riscos" is present, "RISCOS/IMG" will be renamed to "RISCOS_temp/IMG", otherwise an error will be generated and the process halted. "riscos" will be renamed to "RISCOS/IMG" "RISCOS_old/IMG" - a back-up of the previous ROM - will be deleted if present "RISCOS_temp/IMG" will be renamed to "RISCOS_old/IMG" A message "Upgrade completed - please reboot!" will appear I also have an image "STABLE/IMG" present which is a copy of the last pre-zeropain build. Manually copying that as "riscos" and running "Upgrade" will revert to that. Similarly, manually copying "RISCOS_old/IMG" as "riscos" and running "Upgrade" will revert to that previous ROM version. This all fits quite happily in the default 50MB partition that SystemDisc creates with plenty of room to spare! Here is a window image of my Loader directory/partition – you may not have a CMDLINE/TXT file, that’s to sort out a monitor problem I have. A ZIP file with the obeyfile “UpGrade” and the notes “Upgrade_Info” is available here I should mention that I routinely use Fat32fs, having it loaded at boot in PreDesk. Thus it is this filing system which responds to my script. I offer this in case anyone else who is frequently upgrading development ROM images may find it helpful. I make no claim as to it being clever or sophisticated! Just potentially helpful. |
Chris Hall (132) 3502 posts |
Renaming fles in !Boot.Loader is not advised. |
Dave Higton (1515) 3404 posts |
Really? Can you elaborate on that, e.g. where you found the advice, or what the consequences might be? Every time I upgrade, I rename the old version. I have also had cause to revert occasionally. I haven’t had a failure yet. |
Chris Mahoney (1684) 2100 posts |
I’m also interested in this – I know that it’s courting disaster to touch the Loader directory itself, but I’d never heard of any issues with modifying its contents. |
Chris Hall (132) 3502 posts |
It is possible that it has been fixed, but renaming an 8:3 file to a long filename could cause problems. Renaming back again could leave the file with a ‘~1’ in the filename. I always copy file1 to file2 then copy newfile to file1. |
Sprow (202) 1113 posts |
It was this bug which was fixed in 2014 in DOSFS 1.06. However, like many bugs, it remains an urban myth for many years after being fixed. It’s even called out in release notes and change summaries, but still lives on in our hearts. |
John Williams (567) 768 posts |
I omitted to mention in my original post that I routinely use (the badly capitalised) Fat32fs, having it loaded in PreDesk at boot-time. I shall add this information to my original post for completeness, but Sprow points out above that this bug in DOSFS has been fixed. |
Rick Murray (539) 13404 posts |
This raises an interesting question, mind you. If one was to copy the RISC OS image as “riscos/img”, what should be written as the filename? |
John Williams (567) 768 posts |
Why would one want to give Explorer the RISC OS image? It wouldn’t have any notion of what to do with it. Would a different example serve better? One not involving RISC OS at all? |
Rick Murray (539) 13404 posts |
Kind of missed the point John. If one provides a short filename to a (modern) FAT filesystem in anything other than uppercase, then that name is valid as a traditional 8.3 name (converted to upper case as per historical DOS), but it is also equally valid as a long name (even though it is short) in order to preserve the case exactly as is given. Which do you pick? That was my question. |
John Williams (567) 768 posts |
Does this impinge on how the RPi boot system interprets my filenames? I have already said I am using Fat32fs. Is that a modern-enough FAT filing system to count? Is any other external FAT filing system relevant to what I am doing here? In which case is a discussion of other FAT filing systems relevant to this topic? Is Explorer a red herring in this context? It may be intrinsically interesting, but does it belong here? Arriving 25th in your (adopted) country! |
Rick Murray (539) 13404 posts |
Depends…
One might consider such other behaviour to be a benchmark, or at least a guide?
Hurry, while you still can! Unless the snap election fails and loads of people vote LibDem (can’t see anybody sane choosing to vote Labour while Corbyn is around) which would be, like, really funny. |