Hello trid users,
some days ago i wanted to change the boot order on my old PI. Therefore i
installed package rpi-eeprom. Afterwards in sub directory bootloader beneath
/lib/firmware are files with names like pieeprom*.bin.
When running TrID on such examples and related files i get an unexpected
output. The raspberry pi eeprom examples are misidentified as "BIOS ROM
Extension (IA-32)" by rom-x86.trid.xml. Furthermore some real ROM examples
like adaptec1542.bin, MCT-VGA.bin, orchid.bin, Trm3x5.bin, V7VGA.ROM are not
recognized and described as "Unknown!" (see appended
output/trid-v-old.txt).
For comparison reason i check these examples by file command utility. When
running file command (version 5.41 and newer) on such samples these are
described "BIOS (ia32) ROM Ext" with some additional information ( see
appended output/file-5.41.txt output/file-new.txt).
So i run tridscan to update rom-x86.trid. Afterwards i check what has
changed and refine this definition. A nil pattern sequence vanish. That was
done by XML construct like:
<Bytes>00</Bytes>
<Pos>21</Pos>
So only a test for characteristic starting 2 bytes remains. That is
expressed by construct like:
<Bytes>55AA</Bytes>
<ASCII> U</ASCII>
<Pos>0</Pos>
Instead of generic mime type application/octet-stream i show what is done by
newest file command ( see appended output/file-i.txt). That is expressed by
line like:
<Mime>application/x-ibm-rom</Mime>
Unfortunately now these 2 bytes as pattern are not unique any more. So file
command does more checks. For the pi samples a negative ROM (-16*512) size
is shown, but that is nonsense. That information is stored in byte at offset
2. So in newest version such sample with that value are now excluded. So i
look for other tests.
After the byte with ROM length comes bytes which are called Initialization
vector. These must/should contain x86 machine executable code. According to
documentation often this is a 3 byte Near jump instruction (E9 yy zz). This
is shown by newest file command via expression like "jmp 0x7dfc".
Unfortunately i found also examples with different other initialization
vectors. This is shown by newest file command via expression like
"instruction 0xb8004875". So this could not really be be used.
Most cards, especially modern ones support plug and play feature and this
often is done via PCI interface. Then the ROM for such cards contain
corresponding data structures. These are well described. For Plug and play
the structure start with 4 byte ASCII signature $PnP and a pointer to this
is stored at offset 26 (1Ah) as a 2 byte little endian value. For PCI
interface the structure start with 4 byte ASCII signature PCIR and a pointer
to this is stored at offset 24 (18h) as a 2 byte little endian
value. Information about these structures is now shown by newest file
command.
So i run tridscan on examples with PCI interface to generate
rom-x86-pci.trid.xml. The described additional characteristics are here
expressed inside global strings section by line like:
<String>PCIR</String>
The definition is based on 45 examples. So i assume that by "bad"
circumstances some short nil pattern occur. That was expressed by XML
construct like:
<Bytes>00</Bytes>
<Pos>23</Pos>
Assuming that this vanish when taking more examples so i delete that
pattern.
So i run tridscan on examples with Plug and play feature to generate
rom-x86-pnp.trid.xml. The described additional characteristics are here
expressed inside global strings section by line like:
<String>$PNP</String>
The definition is based on 40 examples. So i assume that by "bad"
circumstances some short nil pattern occur. That was expressed by XML
construct like:
<Bytes>00</Bytes>
<Pos>25</Pos>
Assuming that this vanish when taking more examples so i delete that
pattern.
With the updated trid definition and variants now all ROM examples are
described and recognition rate is raised for most examples except for ROM
examples of old "ISA" cards and still misidentified pi eeprom examples ( see
appended output/trid-new-v.txt). TrID definitions and output are stored in
archive rom_bios.zip. I hope that my XML files can be used in future version
of triddefs.
On "BIOS" page on on file formats archive team website there is now a section
with URL to download sample files. So i do not include samples inside
archive, that is sometimes blocked by Google or up-loader functions.
There is still something TO DO. Add a definition to identify raspberry PI
EEPROM. I will try to do this in a future session.
With best wishes
Jörg Jenderek
