Identifying ROM build (from image.)

I’m hatching an idea whereby the user can select a given ROM image on say an RPi from within a running RISC OS environment and have the machine reboot to the new OS version. The software would patch a new image, and associated CMOS (if supported), into the FAT partition, or use *SaveCMOS / *LoadCMOS to do the equivalent for earlier versions before rebooting and bringing up the new OS.

I have the idea pretty well developed. What I’m interested in is how to peek inside an image file to discover version & build info which can then be displayed on the drop-down selection menu.

There are a few wiki pages which will help out here.

https://www.riscosopen.org/wiki/documentation/show/ROM%20image%20format
https://www.riscosopen.org/wiki/documentation/show/Compressed%20ROMs
https://www.riscosopen.org/wiki/documentation/show/HAL%20OS%20layout%20and%20headers

If you just want to know the date of the ROM, then you should be able to get that from the extended ROM footer.

If you want to know the versions of individual modules, that’s a bit trickier, since the start of the module chain isn’t directly advertised anywhere. The softload tool sources may help here, since it locates the module chain so it can optionally patch the modules. If the ROM is compressed you may also need to decompress it (the HAL+kernel will be uncompressed, but the rest of the modules will be compressed)

For patching the old in-ROM CMOS, you’ll have to search for a magic marker in the HAL which marks the start of the buffer.

And if you can figure out where it is configured, it would be useful to identify high and low vector builds…
[and, indeed, if the ROM isn’t suitable for the current hardware]

If you just want to know the date of the ROM, then you should be able to get that from the extended ROM footer.

The Date field only seems to be used on uncompressed ROMs, so daily builds don’t have the date field as part of the extended footer, as far as I could see when I last looked.

There seems to be a very large space near the beginning filled with zeros where a real human-readable date might usefully be inserted – but there’s probably some very good reason why not.

And who is Mark Adler near the end?

Edit: co-author of Zlib, apparently, dealing with compression!

The Date field only seems to be used on uncompressed ROMs, so daily builds don’t have the date field as part of the extended footer, as far as I could see when I last looked.

Very true – I forgot that the ROM compressor outputs an entirely new extended footer. So to get at the build date you’ll have to decompress the ROM.

There seems to be a very large space near the beginning filled with zeros where a real human-readable date might usefully be inserted – but there’s probably some very good reason why not.

Because humans aren’t expected to read the ROM files :-)

There seems to be a very large space near the beginning filled with zeros where a real human-readable date might usefully be inserted – but there’s probably some very good reason why not.

Here it is:

        ALIGN   256

atags   ; list of 'atags' structures constructed here by the loader code
        ; running on VideoCore, describing
        ; - available memory
        ; - command line parameters, including framebuffer parameters

        ALIGN   4096

end_stack
workspace
        %       sizeof_workspace

        ALIGN   32768
        ASSERT  . - HAL_Base = 32768

That’s what’s between the branches at the beginning of the ROM, and the start of the system initialisation (in the HAL’s Top file).

Rick’s Dirty Guide to Vectors High Or Low

Load the image, or at least the first ~256K. Decompression is not necessary.

You can skip the first 64K. That’s HAL, workspace, etc etc.

OPTIONAL: Look for the word &E3330000 followed immediately by the word &0AFFFFFE.
Those instructions correspond to “TEQ R3,#0” followed by a “BEQ” branch to itself. This is the standard behaviour if no RAM was found, and it marks the beginning of the “RISCOS_Start” function.
It is around 120K from the start of the file, however this is examining the Pi build; don’t assume this without examining other ROMs.
[if you don’t want to know where the OS startup routine begins, you can skip straight on to…]

From this point, you want to start scanning for the word &EE018F10. This is MCR CP15,0,R8,C1,C0 and is used to write the configuration to the MMU. It may be found around offset +123K and appears exactly once in the entire ROM image.

There will be between zero and two ORR instructions immediately prior to this instruction.

If you see this:

EE07EF95   MCR   CP15,0,R14,C7,C5,4

Or this:

E3888002   ORR   R8, R8, #2

Then it is a LOW vector image.

If you see this:

E3888002   ORR   R8, R8, #2
E3888A02   ORR   R8, R8, #&2000

Then it is a HIGH vector image.

[the first ORR turns on alignment exceptions, the second enables high vectors; both are optional depending on what the target is]

The code we’re looking at is: https://www.riscosopen.org/viewer/view/castle/RiscOS/Sources/Kernel/s/HAL?rev=4.8.2.1#l855

PS: Obviously this won’t be present on ROMs incapable of supporting high vector, such as RiscPC…

Rick’s Dirty Guide to Firmware Platform Detection

This is simple. ROM does NOT need to be compressed. Scan the first ~32K for a signature. In this case, I will look for the HAL video device.

RiscPC

This is different. Because it works as a softload instead of a ROM image loaded at boot, the first words (the processor vectors) are in the form LDR PC,xxxx instead of B xxxx.
Therefore, if the first words are &E59Fxxxx, it is an IOMD (RiscPC/A7000) ROM image.
This ROM image should go within !Boot.Choices.Boot.PreDesk.!!SoftLoad.

Iyonix

There is no video device visible, however there is a recovery re-flash so we can use the signature from that. Look for &61570A0D followed by &6e696E72 which is the text “<cr><lf>Warnin”.
This ROM image, same location as above (within !!SoftLoad).

Beagleboard (xM) and other OMAP3

It is called “OMAP3 video controller”, the first two words will be unique: &50414D4F followed by &69762033 (“OMAP” and “3 vi”).

Pandaboard

Just as above, only finishing with “34” instead of “33”, so we look for the OMAP4…
In other words, the first two words will be unique: &50414D4F followed by &69762034 (“OMAP” and “4 vi”).

RaspberryPi

This one is called the “BCM2835 VDU device”, so the first two words to identify this are &324D4342 and &20353338.
Actually, those words are the string "BCM2835 ", but that’s good enough for us. We see this, it’s a Pi ROM.

Titanium

Weird. Doesn’t appear to load at boot, appears to need to be flashed. Yikes.
The start of the ROM is:

00000800  ANDEQ   R0, R0, R0, LSL #16
40300008  EORMIS  R0, R0, R8
EA000083  B       &0000021C
32294328  "(C)2"
20343130  "014 "
4F525053  "SPRO"
00000057  "W"+nulls

So, I guess we could either look at the ANDEQ as the first thing in the file, or "SPROW"+nulls as the ID word? At any rate, this ROM image should be handled with care as it needs to be flashed into the machine. Best to leave the user to deal with that…?

I have the idea pretty well developed. What I’m interested in is how to peek inside an image file to discover version & build info which can then be displayed on the drop-down selection menu.

Presumably when the files are downloaded they are given meaningful names. Mine are named according to the date in reverse short format; for instance today’s, were there to be one, would be called 171015. It is trivial to convert that back to a more “normal” date format for a menu – if , indeed, you actually need to.

Presumably related files such as CMOS, CONFIG/TXT and CMNDLINE/TXT could be stored with the same name in different related directories and renamed back on partition creation if required.

If you have an “unknown”, it can simply be loaded, the date read, and an option presented to rename the file and any associated files more suitably for purpose.

For me, that little bit of user activity wins over complicated “peeking inside” rom images which may well be compressed.

If you want to automate the downloading of the image, it can provisionally be given the date of download as a filename, and this can be corrected by the user if subsequently found to be in error by a rename option.

Of course, this ignores the platform bit – but presumably one has the app on the appropriate m/c.

The high/low vector problem can be addressed by a parent menu if required, all relying on appropriate directory trees and the initial logical naming.

This all seems so plain to me that I must be, as does happen, misunderstanding something.

John – don’t be silly. Nobody expects you to fire up Zap and stare at gibberish to identify a ROM image. It’s a method to be used to do it programmatically when presented with a file called “riscos” (that, or “RISCOS/IMG” is ultimately what they are_all_ called).
Remember, a program can’t make assumptions based upon a file name. You said you would write 171015. Others might write 151017, and me, knowing the date, might use 20171115. And this still doesn’t mention what device the code is for. Which is why my long complicated post…

And this still doesn’t mention what device the code is for. Which is why my long complicated post…

But presumably the person or program doing the downloading knows – by the URL used, and can’t really have a folder full of different files called ‘riscos’, as you suggest yourself.

I am suggesting that if you are using a BeagleBoard to download a RPi romimage, you’ll already be aware of this and will put it somewhere appropriate where it will be recognisable – like a directory called, say, RPiRomImages. It will then henceforth be recognisable as such unless you shuffle the whole pack of cards. And its given name will reflect its date.

And it’s unlikely that I’d do that, as I don’t have a BeagleBoard! Even if I did I’d download and use the RPi to house Gareth’s program and download its appropriate image.

As for the user firing up Zap (other editors are available), I’m suggesting you load the rom on the appropriate machine and either do FX0 or look at the Info template provided in the TaskManager menu!

It’s only if you design a russian roulette program for downloading random rom images that you would need to do all this differentiating/identifying. Otherwise, you already have all the information you need either for a program or a user to use sensibly!

Remember, a program can’t make assumptions based upon a file name. You said you would write 171015. Others might write 151017, and me, knowing the date, might use 20171115.

Sensible file listing order requires that the name has the date as 20171115 (or 2017-11-15) so that an alphanumeric sort puts the latest at the end of the list (or first on a reverse sort), you can’t rely on the file datestamp when you could have downloaded a file produced on 20171113 after a file produced on 20171115.

As for the user firing up Zap (other editors are available), I’m suggesting you load the rom on the appropriate machine and either do FX0 or look at the Info template provided in the TaskManager menu!

Which isn’t so useful in cases where the image is not for the current machine. Isn’t unheard of, you might want to update your X via ShareFS or the like.

It’s only if you design a russian roulette program for downloading random rom images that you would need to do all this differentiating/identifying.

Okay, well I have three ROMs – official beta high vector, last RC release, and my own custom build. There’s more to identifying a ROM than just “its date” (especially given I could download the last RC release but when was it dated?).

Having said that, please notice the topic title. It’s that that I’m responding to. If you want to download manually and rename, fine. But isn’t that task something that lends itself to a bit of automation?

Sensible file listing order requires that the name has the date as 20171115

OK – I’ve changed it – but I’ll be well dead by the time it makes any difference!

I’ll be well dead by the time it makes any difference

Pushing up easter eggs?

In the spirit of the original question, I’ve put together a little executable that will identify ROM images. It is exactly 2048 bytes in length.

http://heyrick.ddns.net/files/fwid.zip

Here’s a dump of it examining the ROM images that I have. The first line is an Echo statement so I know what is being loaded, the next lines are the program’s report.

Archimedes (Arthur 1.20 ;-) ):
Examining "<FW$Dir>.Arthur120"...
Archimedes era ROM images are not supported!

IOMD (5.23):
Examining "<FW$Dir>.iomd_b523"...
This ROM is for an IOMD system.
This is RISC OS 5.23, dated 12 Nov 2017.

Iyonix (5.23, high vector):
Examining "<FW$Dir>.iyo_b523"...
This ROM is for an Iyonix.
This is RISC OS 5.23, dated 12 Nov 2017.
This is a high vector build.

[the rest snipped - see below for a complete example]

The ROLtd stuff should be identified as an IOMD device, with valid version and date. If this is not the case (I have no such ROM images to check), could you please send me a copy of the ROM image. I don’t need the entire thing, no interest in running it (plus, piracy…), just the first 256K will do as I’ll need to rummage around the kernel part and see where stuff is.

Uhh… Is there such a thing as a ROM image for the A9home? The 32 bit one? I have no idea how that would be ID’d. If a ROM image exists, same deal, send me the first 256K and I can get it ID’d properly.

Update, as it was failing to correctly detect non-HAL IOMD builds (RISC OS 3.7 etc, but may have counted also for the ROLtd ones). As we’re no longer exactly 2048 bytes (2208 now!), I’ve expanded some of the messages.

http://heyrick.ddns.net/files/fwid002.zip

Example of it in use (first line is an echo saying what is going to be examined, the next 3-4 lines are the program):

Archimedes (Arthur 1.20):
Examining "<FW$Dir>.Arthur120"...
Archimedes era ROM images are not supported!

IOMD (5.23):
Examining "<FW$Dir>.iomd_b523"...
This ROM image is for an IOMD system.
It is RISC OS 5.23, dated 12 Nov 2017.

Iyonix (5.23, high vector):
Examining "<FW$Dir>.iyo_b523"...
This ROM image is for an Iyonix.
It is RISC OS 5.23, dated 12 Nov 2017.
It is a high vector build.

OMAP3 (5.23, high vector):
Examining "<FW$Dir>.omap3_b523"...
This ROM image is for an OMAP3 board (Beagleboard, etc).
It is RISC OS 5.23, dated 23 Aug 2016.
It is a high vector build.

OMAP4 (5.23, high vector):
Examining "<FW$Dir>.omap4_b523"...
This ROM image is for an OMAP4 board (Pandaboard, etc).
It is RISC OS 5.23, dated 12 Nov 2017.
It is a high vector build.

Pi (5.21 RC14, low vector):
Examining "<FW$Dir>.pi_521_rc14"...
This ROM image is for a RaspberryPi.
It is RISC OS 5.21, dated 07 Feb 2015.
It is a low vector build.

Pi (5.23 HIGH vector):
Examining "<FW$Dir>.pi_b523hv"...
This ROM image is for a RaspberryPi.
It is RISC OS 5.23, dated 05 Mar 2017.
It is a high vector build.

Pi (5.23 LOW vector (my custom build)):
Examining "<FW$Dir>.pi_b523lv"...
This ROM image is for a RaspberryPi.
It is RISC OS 5.23, dated 18 Jul 2017.
It is a low vector build.

Pi Pico (release 5, high vector):
Examining "<FW$Dir>.pi_pico5"...
This ROM image is the Pico version for a RaspberryPi.
It is RISC OS 5.23, dated 13 Dec 2016.
It is a high vector build.

RiscPC (release 3.71):
Examining "<FW$Dir>.rpc-371"...
This ROM image is for an IOMD system.
It is RISC OS 3.71, dated 19 Feb 1997.

Titanium (5.23, high vector):
Examining "<FW$Dir>.ti_b523"...
This ROM image is a Titanium FlashROM image.
It is RISC OS 5.23, dated 12 Nov 2017.
It is a high vector build.

Tungsten (Iyonix, 5.20 official):
Examining "<FW$Dir>.trom"...
This ROM image is for an Iyonix.
It is RISC OS 5.20, dated 10 Jun 2013.
It is a low vector build.

:-)