Hello trid users,
some days ago i read an interesting article in German computer magazine c't
about replacing BIOS with Intel Management Engine (ME) by Coreboot. So just
for interest i run TrID on some such cleaned Intel ROMs.
Unfortunately when i run TrID on such examples these are misidentified as
"TransCopy disk image" by tc-transcopy.trid.xml (see appended
output/trid-v-old.txt).
For comparison reason i also run the file utility (version 5.41). This
identifies the examples as "Intel serial flash" and "for ICH/PCH ROM <= 5 or
3400 series A-step" by starting 4 byte pattern 5AA5F00F. (see appended
output/file-5.41.txt). According to documentation i also run a patched file
command that displays more information (see appended output/file.tmp).
According to documentations for this variant mentioned are I/O Controller
Hub ICH8, ICH9 and ICH10. For older Hubs like ICH0 til ICH7 nothing was
mentioned. So i do not know if my found documentation also applies to that
older types as file command suggest. So i mention this fact in remark line.
Luckily there exist a SPI Programming Guide for Intel 7 Series/C216 chip set
Family (SPI Programming Guide.pdf). This is expressed by line like:
<RefURL>
https://www.corus.pro/pilotes/CorusX/X37/XP/ME/SPI%20Programming%20Guide.pdf </RefURL>
So i generate rom-intel-ICH.trid.xml by running tridscan. I used hundreds of
examples but many are similar, because ROM examples are just variants with
different keyboards and most examples are for Lenovo Thinkpad notebooks.
So i clean trid definition file. The first expression was like:
<Bytes>5AA5F00F010004</Bytes>
<ASCII> Z</ASCII>
<Pos>0</Pos>
According to documentation the first 4 bytes are the characteristic flash
signature. Afterward the Flash Component Base Address (FCBA) is stored as
byte. In my examples the value was 1, but in documentation also value 3 is
mentioned. In the next 2 bits the number of components (NC) is stored in my
examples this value was 0 ( that means 1 component). Next the Flash Region
Base Address (FRBA) is stored as byte. In my examples this value was
4. assuming that also other values are possible this now becomes like:
<Bytes>5AA5F00F</Bytes>
<ASCII> Z</ASCII>
<Pos>0</Pos>
The second expression looks like:
<Bytes>0602100220010000</Bytes>
<Pos>8</Pos>
The low byte of FLMAP1 is the Flash Master Base Address (FMBA). Typical
value also mentioned in documentation is 6. Next 2 bits are the Number Of
Masters (NM). Typical binary value is 10 (=2 hexadecimal).
In next byte Flash PCH Strap Base Address (FPSBA) is stored. Typical value
also mentioned in documentation is 10h.
In next byte PCH Strap Length (ISL) is stored. Typical value also mentioned
in documentation for other variant is 12h, but in examples value was 2.
First byte of FLMAP2 is Flash Processor Strap Base Address (FMSBA). Typical
value also mentioned in documentation is 20h.
Next byte is PROC Strap Length (PSL) or MCH Strap Length (MSL) called by
others. Typical value also mentioned in documentation is 01h.
Next byte is ICC Register Init Base Address (ICCRIBA). Typical value also
mentioned in documentation for other variant is 21h, but in my examples
value was 0.
Next byte is reserved. So in my examples this value was 0.
I do not know if other values for above mentioned variables occur. So i keep
second XML construct and mentioned used values in remark line.
Flash Components Record FLCOMP start at address given by FCBA. Value 1h
means address 10h. In the first byte the component densities are
stored. These defines the ROM sizes. Because the examples have different
sizes like (4 MB 8 MB 16 MB) i get different value at offset 16.
Then byte at offset 17 is reserved. So in my examples value was 0.
The next 2 bytes contains something like clock frequencies. In my examples
value was 3000 in big endian.
At offset 20 the Flash Invalid Instructions Record (FLILL) begins. In my
examples value was 0.
At offset 24 the Flash Partition Boundary Record (FLPB) begins. In my
examples value was 0.
Afterwards comes 36 padding of component section. The padding value seems to
be 0xFF. That was expressed by XML construct like:
<Bytes>0030000000000000000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF00000000</Bytes>
<Pos>17</Pos>
Assuming that also other clock frequencies are possible and other no nil
values for FLILL and FLPB are possible this now becomes like:
<Bytes>FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF</Bytes>
<Pos>28</Pos>
At higher offsets there exist some other values, but i do not check such
patterns and delete such patterns assuming that this are triggered by lucky
circumstances. I only look for padding bytes and keep this.
One of this pattern was expressed by XML construct like:
<Bytes>0000FFFFFFFFFFFFFFFFFFFFFFFF0000</Bytes>
<Pos>82</Pos>
According to ich9utils region section is padded by 12 bytes at offset 54h
(84). So this is now expressed by XML construct like:
<Bytes>FFFFFFFFFFFFFFFFFFFFFFFF</Bytes>
<Pos>84</Pos>
Then there was a XML construct like:
<Bytes>18020808FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
<Pos>104</Pos>
According to ich9utils Master Access Section is padded by 148 bytes at
offset 6Ch (108). So this is now expressed by XML construct like:
<Bytes>FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
<Pos>108</Pos>
Then there was a XML construct like:
<Bytes>000F010000FFFFFFFFFFFFFFFFFFFFFFFFF
<Pos>259</Pos>
According to ich9utils ICHSTRAPSRECORD is padded by 248 bytes at offset 108h
(264). So this is now expressed by XML construct like:
<Bytes>FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
<Pos>264</Pos>
Then there was a XML construct like:
<Bytes>FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
<Pos>513</Pos>
According to ich9utils MCHSTRAP0 is padded by 3292 bytes at offset 204h
(516). So padding til 2048 (800h) range by 1533 bytes is now expressed by
XML construct like:
<Bytes>FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
<Pos>516</Pos>
Because the serial flash contain also BIOS part it contain also many ASCII
strings. So i got many lines in global strings section. Some look like
garbage produced by lucky circumstances:
<String>FPFQFR</String>
<String>FZFYFX</String>
<String>CK SI</String>
<String>-ASS</String>
<String>-YHL</String>
<String>.''F</String>
<String>0''0</String>
<String>BVJ8</String>
<String>E1XP</String>
<String>E3UA</String>
<String>MGAG</String>
<String>M~(Y</String>
<String>Y%5N</String>
So i delete such lines. Other look like plausible words like:
<String>WAKE</String>
<String>WLAN</String>
<String>BOOTBLOCK</String>
<String>PARTITION</String>
<String>JEDEC</String>
<String>UPDATE</String>
<String>BIOS</String>
So i keep such lines.
Instead of generic mime type application/octet-stream a user defined one is
applied. That is expressed by line like:
<Mime>application/x-intel-rom</Mime>
With my trid definition all of my inspected flash ROM examples are now
described first correctly as "Intel serial flash ROM (ICH)" (see appended
output/trid-v.txt). TrID definition and output are stored in archive
rom_intel.zip. I hope that the XML file can be used in future version of
triddefs.
There exist another variant of such flash ROM, but at the moment i have too
few examples to handle such variant. I will try to do this in a future
session.
With best wishes
Jörg Jenderek
