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
/usr/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. (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) on PI samples these are described "BIOS
(ia32) ROM Ext" with some additional information. The byte at offset 2 is
misinterpreted as negative ROM length (-16*512) or when using unassigned as
unlikely high (0xF0*512=240*512). And at offset 4 the byte has value
0x0F. In real ROM examples here often i found value 0xE9 for jump
instruction, but not 0x0F ( see appended output/file.txt).
When running file command (version >5.41) on PI samples these are described
as "Raspberry PI EEPROM" with some additional information and the BIOS ROM
examples are described as "BIOS (ia32) ROM Ext." with more information
especially the following instruction (see appended output/file.txt). So by
"bad" circumstances such PI eeprom start with same 2 magic bytes as for BIOS
(ia32) ROM Extension.
So i run tridscan on PI examples to generate bin-pi-eeprom.trid.xml. Luckily
some information about "EEPROM" can be found on raspberry pi web site. That
is expressed by line like:
<RefURL>
https://www.raspberrypi.com/documentation/computers/raspberry-pi.html #raspberry-pi-4-boot-eeprom
</RefURL>
There also listed are links to scripts like rpi-eeprom-config. Afterwards i
check XML file and refine this definition according to python script. The
first XML construct looks like:
<Bytes>55AAF00F00</Bytes>
<ASCII> U</ASCII>
<Pos>0</Pos>
In all my dozens samples the starting 4 bytes are always 55AAF00F, but
according to python source there may exist variants that look a little bit
other. So the value must be masked with value 0xFFffF00F (called MAGIC_MASK)
before comparing value with expected value 0x55aaF00F (called MAGIC in
source). Afterwards a 32 bit offset in big endian to the next section is
stored. This is shown by newest file command. Highest value found is like
0001DE84h. So in theory maximum is about 4 GiB, but in real examples this
value is clearly below or in other words the highest byte was always
nil. Assuming that also higher offsets are possible this construct now
becomes like:
<Bytes>55AAF00F</Bytes>
<ASCII> U</ASCII>
<Pos>0</Pos>
Afterwards length and optional filename of section follow. For the first
section i got always length zero. If i understand source right this means
second section start immediately afterwards with it own magic. If this magic
is also zero then parsing of sections is done. So this now looks like:
<Bytes>00000000000000000000000000000000000000000000000000...
<Pos>8</Pos>
But i do not know if this is always true.
Furthermore i get short sequences, that are expressed by XML construct like:
<Bytes>8090</Bytes>
<Pos>586</Pos>
I do not know what these mean or if these are always are true. So i keep
these at the moment.
If your run rpi-eeprom-config with -o option it outputs the current
bootloader configuration which looks like':
[all]
BOOT_UART=0
WAKE_ON_GPIO=1
POWER_OFF_ON_HALT=0
So i found these phrases inside global strings. In that section i also found
lines like:
<String>U''Z</String>
<String>USTE</String>
<String>VOLU</String>
<String>H5H6H7H8H9H</String>
<String>1.8'3.3</String>
<String>.8Q( D</String>
Assuming that these are garbage produced by limited number of examples i
delete such lines.
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-raspberry-eeprom</Mime>
With the new trid definition and variants for BIOS ROM all examples are
described with high rate correctly ( See appended output/trid-new-v.txt).
TrID definitions and output are stored in archive bin_pi_trid.zip. I hope
that my XML file can be used in future version of triddefs.
With best wishes
Jörg Jenderek
