This page serves as a summary of the internal format of RISC OS 5 ROM images. This format is similar to that used in other versions of RISC OS developed by Acorn and RISCOS Ltd.
There are four main sections to a RISC OS 5 ROM image. In order from the start of the image, these are:
The amount of padding inserted before the footer is adjusted so that the total size of the image is exactly the ImageSize parameter specified in the Env file.
Note that for historical reasons, by default the ROM linker tool will overwrite locations 0×60-0×63 with a word containing the size of the ROM image. However this will overwrite part of the HAL, and one of the design goals of the HAL was to have it free from any formatting constraints. To combat this a ‘noimagesize’ option was added to romlinker 0.04 to suppress this behaviour. In order to use this option with Builder/srcbuild, make sure that romlinker is used as the %Joiner and %JoinerFormat options in the Components file, and then add a new %noimagesize option (see the top of the OMAP3 components file for an example)
The ROM footer has the following format. The entries below are listed in increasing address order, i.e. the end of the 64 bit CRC will be the end of the image file.
|4+||Extended ROM footer (optional)|
|8||64 bit CRC|
Two checksums are stored, a 32bit negative checksum and a 64bit CRC.
TODO – Describe how they’re stored and what data they cover.
Historically this field was used to differentiate between different ROMs intended for different machines/markets. E.g. NCOS builds used to have a signature of 0×534F434E (‘NCOS’ in host byte order). Current builds just use a signature of 0xffffffff.
For IOMD and before, this word was used as part of the power-on self test.
TODO – How was it used?
This is a new structure supported by romlinker 0.04 and above. It stores a list of variable-length items identified by tags. In increasing address order, each entry in the footer begins with a 1-byte tag ID field, a 1-byte length field, and then the variable-length data payload. The length field excludes the length of the two header bytes.
To identify the length and validity of the extended ROM footer, the item list is terminated by a footer word. This word contains the length of the extended ROM footer in the low two bytes (not including the length of this word) and a 16-bit CRC in the top two bytes (not including the contents of this word).
If an extended ROM footer is present in the image then the footer word will be located at offset -24 from the end of the image, i.e. directly before the POST word. Individual items within the footer will be byte-aligned.
Starting with RISC OS 5.23, OS_ReadSysInfo 15 can be used to enumerate the footer entries at runtime.
The following tag IDs are currently in use:
|0||5||Standard RISC OS 5-byte time giving the ROM link time|
|1||8||Compressed ROM softload helper. The first word contains the negative checksum of the uncompressed image, and the second word contains an offset to the OS header. Only present in compressed images.|
|2||4||Offset from the start of the (uncompressed) ROM image to the debug symbols blob|
The current ROM compression scheme involves compressing everything in the ROM image apart from the HAL and kernel. The ‘rompress’ tool will append a new ROM footer with valid checksums (to help HALs that perform a checksum of the ROM image, e.g. the Tungsten HAL), along with an extended ROM footer containing tag ID 1. The presence of this extended footer helps the softload tool to quickly and easily identify if a compressed ROM matches an uncompressed ROM.