See
http://home.socal.rr.com/awi/srecords.htm
BNM FILE FORMAT
I analyzed the BNM file structure as DOS text files (therefore ended with CR/LF line terminators), in which firmware is encoded in ASCII hexadecimal representation. Whith this representation, each byte is stored on two bytes representing the two 4 bits hexadecimal digits of the byte. Digits A to F may be represented in upper or in lower case.
Each line constitutes a so-called "S record", with a header followed by ASCII encoded binary data.
The general format of a S record is the following :
Magic Type Length Offset Binary data Checksum
1 byte 1 byte 2 bytes 6/8 bytes variable 2 bytes
The Magic field is always the 'S' character. It is followed by a code telling the kind of record the current line describes. As far as I known, there are 3 kinds of records :
- records whose type code is character '9', who marks the end of the firmware code ;
- records whose type code is '2' or '3', who store firmware data.
- S records of type 2 encode the Offset field on 6 bytes only, whereas
- S records of type 3 encode the Offset field on 8 bytes (these offsets are therefore 32 bits wide when converted from ASCII hexadecimal to binary).
The Length field tells the length in bytes of the remaining datas on the line.
This length is the length once the data converted, the remaining size of the record is therefore two times this length.
The Offset field stores the offset of the binary data of the S record in the firmware. These offsets can be coded on 6 bytes (24 bits offsets)
or on 8 bytes (32 bits offsets).
The Binary data field contains the firmware chunk the S record represents.
The checksum is the logical not of the least signigicant byte of the sum of preceding binary converted bytes from the count field (comprised). For instance, if the sum of the preceding hexadecimal bytes is F1, the checksum is 0E.
As .bnm files are ASCI printable files, therefore each S record ends with a CR and a LF byte, which of course must be taken in account in parsing the records.
Records can be read in any order, since the encode the binary chunk's offset in the firmware. However, the first record is special because its offset is the so-called IDMA start, which certainly is the offset of the bootstrap code in the firmware. As we have no way to distinguish the first record from the others, it is assumed it's the first record of the first file.
The first file is therefore very important and should always be loaded before the others.
-- CC
