Firmware Layout
From OpenWiz
Contents |
Beyonwiz firmware update (.wrp) file
Much of this information is thanks to discussions with efry on the Beyonwiz Forum.
Beyonwiz firmware updates are in the form of a file with a .wrp file name extension. The first part of the name of public releases describes the firmware version, so DPS1_Firmware_18Dec2007_ver_01.05.192.wrp is a firmware update for a DP-S1 dated 18 Dec 2007, and firmware version number 01.05.192.
The file contains two MD5 checksums that are used by the Beyonwiz to ensure the integrity of the data in the firmware update.
Beyonwiz .wrp file structure
So far, all Beyonwiz .wrp files have had this structure:
File address
+--------------+ <- 0
| Header |
+--------------+ <- 512
| |
| Payload |
| |
+--------------+
| Padding |
+--------------+ <- multiple of 512
| Empty header |
+--------------+ <- + 512 bytes
The Padding and Empty header are all zero-filled.
It is possible that the Empty header may be simply a terminator, and a .wrp file could have several headers and payloads, but no multi-payload firmware updates have been found so far.
The header contains the size and type of the payload, MD5 checksums, the firmware version, and so on.
The payload is the actual content, for example firmware to be uploaded into the Beyonwiz.
Beyonwiz .wrp header structure
In C-like syntax, the header has this structure:
struct wrp_hdr {
byte magic[12]; // Offset 0 (0x000)
// "WizFwPkgl", null padded
byte machineMagic[8]; // Offset 12 (0x008)
// Machine magic number.
// Prevents the wrong firmware for a machine
// being loaded.
byte version[64]; // Offset 20 (0x014)
// Version string, null padded.
// This is what is displayed in the verification
// popup when the firmware is loaded
byte md5file[16]; // Offset 84 (0x054)
// MD5 file checksum;
// calculated with all headers, but
// with md5file set to all nulls
byte imageCount[4]; // Offset 100 (0x064)
// Count of packages remaining
// Has value 1 in all previous .wrp files with firmware only
// Has value 2 when .wrp file contains firmware & loader
byte unknown1[4]; // Offset 104 (0x068)
// Has value 104 (0x6c) in all observed .wrp files
byte unknown2[4]; // Offset 108 (0x06c)
// Has value 32 (0x20) in all observed .wrp files
byte imageType[4]; // Offset 112 (0x070) see below
byte imageOffset[4]; // Offset 116 (0x074) file offset of image start?
byte imageLen[4]; // Offset 120 (0x078) length of payload
byte md5image[16] // Offset 124 (0x07c)
// MD5 checksum of ROM image
// over the image, image length imageLen
byte padding[372]; // Offset 140 (0x08c)
// Padding to 512 bytes, null filled
};
The 4-byte fields that represent 32-byte numbers are interpreted in a little-endian (least significant byte at the lowest address) fashion.
imageType
The image types (from efry's analysis of the code) are:
- 0 = None
- 1 = Boot loader
- 2 = ROMFS
- 3 = Splash Screen
- 4 = Release Note
Edit: This seems to not be 100% correct. A .wrp file containing ROMFS and Boot loader also has a value of 2. Maybe 1 if Boot loader only?
machineMagic
The machineMagic values are
byte DPS1_magic[] = { 0x3e, 0xbe, 0x20, 0x0e, 0x00, 0x00, 0x08, 0x08 };
byte DPP1_magic[] = { 0x3c, 0xbe, 0x22, 0x0a, 0x00, 0x00, 0x08, 0x08 };
byte DPH1_magic[] = { 0x3c, 0x7e, 0x22, 0x00, 0x00, 0x00, 0x08, 0x04 };
You may recognise these values as comprising the System ID displayed by the Beyonwiz Setup>System>Firmware>Firmware Information, but read in reverse. The System ID for the DP-S1 displays on the Beyonwiz as 0808 0000 0E20 BE3E.
The interpretation of imageCount and imageOffset is somewhat conjectural. They have never been observed to have values other that 1 and 512 respectively.
The ROMFS payload type
All firmware updates so far have been of this type. The payload is a Linux ROMFS file system. The document ROMFS - ROM FILE SYSTEMdescribes its format. It is a simple file system that can only be used read-only, intended for read-only media (like ROM), or media where writing is costly (like FLASH memory). However, it is a read-only filesystem even when implemented in writable media like RAM.
The first 8 bytes of a ROMFS file system are -rom1fs-. The next 4 bytes of the file system is the file system length, in big-endian order. The size includes the header.
This ROMFS image is the application file system /flash on the Beyonwiz. It contains the main application that runs the Beyonwiz (wizdvp/wizdvp) and the WizFX server (wizdvp/wizpnp), as well as a number of other components that make up (most of?) Beyonwiz's own software that runs the PVR.
The file linux.bin.gz in the top level of this file system is the gzip-compressed uClinux kernel that runs as the Beyonwiz's operating system. The kernel also has the Beyonwiz's root file system embedded in it (most of linux.bin.gz is the root file system). Unix systems (like Linux) have a tree-structured file system (actually, it's a directed (almost) acyclic graph). The root file system contains the root of the tree structure, called / The root file system is also
Software
The Wiz Firmware Tools package has tools to unpack and pack .wrp files.
Prl 06:01, 21 February 2008 (UTC)
