[File] [PATCH] Magdir/intel BIOS (ia32) ROM; invalid negative size versus raspberry PI eeprom
Jörg Jenderek
joerg.jen.der.ek at gmx.net
Thu Mar 31 22:26:02 UTC 2022
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello,
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 file command version 5.41 on such examples and related
files i get an output like:
2975BIOS.BIN: BIOS (ia32) ROM Ext. (63*512)
4243.bin: BIOS (ia32) ROM Ext. (84*512)
4650_sr5.bin: BIOS (ia32) ROM Ext. (80*512)
MCT-VGA.bin: BIOS (ia32) ROM Ext. IBM comp. Video (48*512)
NVidia44.bin: BIOS (ia32) ROM Ext. IBM comp. Video (125*512)
PXE-Intel.rom: BIOS (ia32) ROM Ext. (96*512)
Trm3x5.bin: BIOS (ia32) ROM Ext. (64*512)
adaptec1542.bin: BIOS (ia32) ROM Ext. Adaptec (32*512)
efi-e1000.rom: BIOS (ia32) ROM Ext. (125*512)
efi-rtl8139.rom: BIOS (ia32) ROM Ext. (-127*512)
eof.bin: BIOS (ia32) ROM Ext.
header.bin: BIOS (ia32) ROM Ext. (86*512)
ide_xtp.bin: BIOS (ia32) ROM Ext. (16*512)
kvmvapic.bin: BIOS (ia32) ROM Ext. (18*512)
multiboot.bin: BIOS (ia32) ROM Ext. (2*512)
orchid.bin: BIOS (ia32) ROM Ext. (0*512)
pieeprom20-07-16.bin: BIOS (ia32) ROM Ext. (-16*512)
pieeprom22-03-10.bin: BIOS (ia32) ROM Ext. (-16*512)
vgabios-stdvga.rom: BIOS (ia32) ROM Ext. IBM comp. Video (75*512)
For comparison reason i run the file format identification utility
TrID ( See https://mark0.net/soft-trid-e.html). Many examples are
described as "BIOS ROM Extension (IA-32)" by rom-x86.trid.xml. But
some examples like adaptec1542.bin, orchid.bin, Trm3x5.bin,
ide_xtp.bin are only described as "Unknown!" (See appended
rom-trid-v.txt.gz).
With this information i was able to find also a page about BIOS on
file formats archive team website. There also a detailed book "BIOS
DISASSEMBLY NINJUTSU UNCOVERED" as download PDF is mentioned.
That informations are now expressed by additional comment lines
inside Magdir/intel like:
# URL: http://fileformats.archiveteam.org/wiki/BIOS
# Reference: http://www.lejabeach.com/sisubb/
# BIOS_Disassembly_Ninjutsu_Uncovered.pdf
The current description happen by lines like:
0 beshort 0x55AA BIOS (ia32) ROM Ext.
!:mime application/octet-stream
!:ext rom/bin
> 5 string USB USB 7 string
> LDR UNDI image 30 string IBM IBM
> comp. Video 26 string Adaptec Adaptec 28
> string Adaptec Adaptec 42 string
> PROMISE Promise 2 byte x
> (%d*512)
By the last line with parentheses the ROM lent is shown. According
to documentation this information is stored as 8-bit in byte at
offset 2 in units of 512 bytes. For all my hundreds inspected PI
EEPROM samples i get here (-16*512). Here i was astonished because
negative values make sense for temperature value but not for length
statement. So i checked all my real "good" ROM examples for that
behaviour. Finally i find 3 examples where i also got negative values
:
efi-eepro100.rom: BIOS (ia32) ROM Ext. (-128*512)
efi-rtl8139.rom: BIOS (ia32) ROM Ext. (-127*512)
pxe-e1000.rom: BIOS (ia32) ROM Ext. (-125*512)
These examples can be found for example inside qemu emulator
package. For PCI based ROMs the same information but called "Image
length" is stored inside PCI Data Structure, but there the value is
stored as 2 byte integer or 16-bit. So here i get no negative values.
That can be shown by line like:
>> (24.s+0x10) uleshort x \b, length %u*512
Nothing is said about signness of that byte value. In some older
documentation i found a remark like "limit hex 7F". So when
interpreting byte value as signed i get an upper limit of 64 KiB, but
when interpreting it as unsigned value 128 KiB is the upper limit.
Apparently in old DOS times with small ROM sizes this size overflow
does not matter or interpreting value as unsigned was OK, but
nowadays where cards also or instead operate in EFI environments ROM
size are sometimes above 64 KiB. So the correct line must use
unsigned expression and now becomes like:
> 2 ubyte x (%u*512)
Unfortunately the stored ROM size is not equal to file size and i
see no formula to calculate file size from ROM length. So i get
values like:
file name file size calculated size
eof.bin 2 -
orchid.bin 188 0 =0*512
multiboot.bin 1024 1024 =2*512
loader1.bin 512 2048 =4*512
ide_xtp.bin 8192 8192 =16*512
kvmvapic.bin 9216 9216 =18*512
V7VGA.ROM 18832 16384 =32*512
adaptec1542.bin 32768 16384 =32*512
MCT-VGA.bin 32768 24576 =48*512
2975BIOS.BIN 32768 32256 =63*512
efi-e1000.rom 196608 64000 =125*512
efi-rtl8139.rom 176640 66048 =129*512
pieeprom*.bin 524288 122880 =240*512
The example eof.bin just contain the 2 byte starting magic. So no
size information is there available and so no expression with
parentheses is shown. The example orchid.bin was found on Windows
95 CD in directory Drivers\audio\orchid3d. So exist only a rough
linear correlation between observed ROM file size and internal
stored ROM length. So i do not know where the difference in linear
relation comes from.
ROM images for cards with PCI interface contain a section for
handling PCI Data. Often this structure is stored near the beginning
and it starts with 4 bytes ASCII signature PCIR. The offset to this
is always stored at well defined position. So now show this
information by lines like:
> (24.s) string =PCIR \b;
>> 24 uleshort x at %#x PCI
After that string the vendor identification (ID) is stored as 2 byte
integer. That can be shown by line like:
>> (24.s+4) uleshort x ID=%4.4x
Luckily there exist the PCI ID Repository where the meaning of these
numbers is stored in table form as file pci.ids. So i look in this
file and transfer it manually as magic expression. There exist some
thousands of lines, but these numbers are reduced because i
"translate" only the manufacture ID and show device id as hexadecimal
number. Furthermore i also look for "standard" (not exotic) hardware
like ethernet network cards, mass storage card and VGA compatible
display cards. Furthermore i concentrate only on market leading
manufacturers. So in the end i get only a dozen of lines that look
like:
>> (24.s+4) uleshort =0x1000 Broadcom (24.s+4) uleshort =0x1002
>> AMD/ATI (24.s+4) uleshort =0x1013 Cirrus Logic (24.s+4)
>> uleshort =0x1014 ibm (24.s+4) uleshort =0x1022 AMD (24.s+4)
>> uleshort =0x1050 Winbond (24.s+4) uleshort =0x105a Promise
>> (24.s+4) uleshort =0x1095 Silicon (24.s+4) uleshort =0x10EC
>> Realtek (24.s+4) uleshort =0x10de NVIDIA (24.s+4) uleshort
>> =0x1234 Bochs (24.s+4) uleshort =0x15ad VMware (24.s+4)
>> uleshort =0x1af4 Virtio (24.s+4) uleshort =0x1b36 QEMU
>> (24.s+4) uleshort =0x1de1 Tekram (24.s+4) uleshort =0x8086
>> Intel (24.s+4) uleshort =0x9004 Adaptec
Later i put these lines in a subroutine and in a new file
Magdir/pci.ids and just call it by line like:
>> (24.s+4) use PCI-vendor
The advantage is that this information can be called and used by
other magic lines (Yes i do it for Plug and Play stuff). Furthermore
it is easier to maintain/update. So maybe a hard worker or good
scriptwriter can create more or updated entries there.
Afterwards the device identification (ID) is stored. This is done by
line like:
>> (24.s+6) uleshort x device=%#4.4x
For some card that information is already visible by file name like
for efi-rtl8139.rom "PCI ID Realtek device=0x8139" or partly like by
efi-e1000.rom "PCI ID Intel device=0x100e". But often you have
filename like header.bin, that says nothing. Then you are happy about
the displayed manufacture name.
A little bit later the Class Code and Subclass is stored as numeric
byte values. Here i also show human readable text for values. I do
subclass description only for network cards and mass storage. This
looks like:
>> (24.s+0x0D) ubyte x \b, CLASS=%x (24.s+0x0D) ubyte 0x02
>> network controller
>>> (24.s+0x0E) ubyte 0x00 ethernet (24.s+0x0E) ubyte 0x01
>>> token ring (24.s+0x0E) ubyte 0x02 FDDI (24.s+0x0E) ubyte
>>> 0x03 ATM (24.s+0x0E) ubyte 0x04 ISDN (24.s+0x0E) ubyte
>>> 0x05 WorldFip (24.s+0x0E) ubyte 0x06 PICMG (24.s+0x0E)
>>> ubyte 0x80 OTHER
So we see that samples like efi-e1000.rom and efi-rtl8139.rom are
made for ethernet network cards.
Class 0 is used for device that was built prior definition of the
class code field. Here sub class value 1 should appear for VGA and
value 0 for the other NON-VGA card. But i get sub class value 4 for
example 4243.bin. Samples like vgabios-stdvga-bin.rom and
NVidia44.bin are classified wrong as NON-VGA. So for that branch i
add only main part and lines for sub class are added as comment
lines. That looks like:
>> (24.s+0x0D) ubyte 0x00 PRIOR
#>>>(24.s+0x0E) ubyte 0x00 NOT VGA
#>>>(24.s+0x0E) ubyte 0x01 VGA
#>>>(24.s+0x0E) ubyte 0x04 SUB_CLASS_4
After the dozen classes the higher values are described as reserved
and highest values is described as vendor specific. So this should be
used for Unassigned Class. But for Promise 4650_sr5.bin and
8660_sr5.bin i get unexpected value (0xF8). That is done by lines lik
e:
>>> (24.s+0x0D) default x
>>>> (24.s+0x0D) ubyte 0xFF UNASSIGNED (24.s+0x0D) default x
>>>> RESERVED
>>>>> (24.s+0x0D) ubyte x (%#x)
The last 2 bytes of PCI header part are described as reserved. These
seem to be zero in most cases but not for examples efi-e1000.rom and
efi-rtl8139.rom. So show unusual values by line like:
>> (24.s+0x16) ubeshort !0 \b, 3rd reserved %#x
ROM images for cards with Plug and Play interface contain a section
for handling such cards. Often this structure is stored near the
beginning and it starts with 4 bytes ASCII signature $PnP. The offset
to this is always stored at well defined position. So now show this
information by lines like:
> (26.s) string =$PnP \b;
>> 26 uleshort x at %#x PnP
At offset 10 of that structure the device identification (ID) is
stored. In some examples like 4243.bin i get here the same values as
in PCI section. That was like i expect it. Often i get here zero
values. So i interpret that the programmer were too lazy to implement
the correct values. But i also found examples like 4650_sr5.bin
where ID in PNP section it totally different from ID in PCI section.
So show this information is now shown by lines like:
>> (26.s+0x0A) uleshort !0
>>> (26.s+0x0C) use \^PCI-vendor (26.s+0x0A) ubeshort x
>>> device=%#4.4x
Unfortunately here i found only few examples an to get correct values
for adaptec_ava1515_bios_585201-00.bin i must use reverted endian! So
i do not know if this always is true or if this is an accident?
In this structure at defined position a pointer to optional
manufacturer ASCIIZ string is stored. 0 means no such string. This
informative string look like "http://ipxe.org", "Plop - Elmar
Hanlhofer www.plop.at" or "QEMU" and is shown by lines like:
>> (26.s+0x0E) uleshort >0 \b, at %#x
>>> (26.s+0x0C) uleshort x
>>>> (&0.s) string x "%s"
Afterwards the pointer to optional ASCIIZ product string is
stored. In many cases this string looks like "iPXE", "Plop Boot
Manager", "multiboot loader". This is shown by lines like:
>> (26.s+0x10) uleshort >0 \b, at %#x
>>> (26.s+0x0E) uleshort x
>>>> (&0.s) string x "%s"
At offset 18 of that structure 3 byte Device type code is stored.
This is shown by lines like:
>> (26.s+0x12) ubyte x \b, device type %2.2x (26.s+0x13) ubyte
>> x \b-%2.2x (26.s+0x14) ubyte x \b-%2.2x
Probably this is the same meaning as in PCI section. So what is
described here in samples by "device type 02-00-00" is described in
PCI section in readable form by text like "CLASS=2 network controller
ethernet". Later i replace it by line
>> (26.s+0x12) use PCI-class
This gives correct description "storage controller SCSI" for
2975BIOS.BIN and adaptec1542.bin. Correct is also "network controller
ethernet" for efi-e1000.rom and efi-rtl8139.rom.
The last 2 bytes of this structures are static resource information
vector. 0 means means disabled. So show now this information by line
like:
>> (26.s+0x1E) uleshort !0 \b, static offset %#4.4x
When inspecting dozen of examples most contain PNP and PCI section.
Then there exist few examples which contain only one these these
sections. In current magic lines exist with efforts to do sub
classification of ROM extensions. But no documentation for these line
exist and i do not know where this come from. So i do following
reorganisation. If there exist a PNP or PCI section then "old" sub
classification parts are not needed. If neither of these 2 section
exist than try to apply the "old" classification. So this becomes a
third branch, that now looks like:
> (26.s) ubelong !0x24506e50
>> (24.s) ubelong !0x50434952
>>> 5 string USB USB 7 string LDR UNDI image 26 string
>>> Adaptec Adaptec
#>>>28 string Adaptec Adaptec
>>> 42 string PROMISE Promise
Here i was able to eliminate the test with word Adaptec at offset 28,
because this is already done by PNP section for "Adaptec" for
device=0x0490 with product name "Adaptec BIOS:AHA-1542CP" for file
like:
adaptec_aha1542cp_bios_908501-00.bin
But there is one exception. That is for VGA cards. Many contain a PCI
section but vendor id is too unspecific like "QEMU", "Bochs",
"Virtio" or "VMware". OK for "Cirrus Logic" or "NVIDIA" you might
think "VGA". Furthermore here i get often PCI CLASS=0. That is
"PRIOR" and here sub class detection for VGA is not reliable.
Furthermore there exist samples like MCT-VGA.bin or V7VGA.ROM which
are apparently like "old" ISA VGA cards. So there exist no PNP or PCI
section. So i still apply the test for VGA cards in general, but this
now becomes like:
> 30 string IBM IBM comp. Video
>> 33 ubyte !0
>>> 30 string x "%s"
I do not know or understand why this test works or what are the
internal facts. By third line i show the exact VGA text string for
longer text strings. For many examples like vgabios-stdvga.rom,
vgabios-vmware-bin.rom, vgabios-cirrus-bin.rom and
vgabios-virtio-bin.rom the text consist of only this 3 byte word. But
there exist samples like MCT-VGA.bin, NVidia44.bin and V7VGA.ROM
where here i get longer text like:
"IBM COMPATIBLETDVGA 3588 BIOS Version V1.04A2+"
"IBM VGA Compatible\001"
"IBM EGA ROM Video Seven BIOS Code, Version 1.04"
So by third branch "old" ISA cards and raspberry PI EEPROM are
matched. That make no sense! Why should raspberry pi EEPROM based on
arm architecture be packed like an old IBM card based on intel x86
architecture. So obviously the raspberry PI EEPROM are packed in a
container format, that by "bad" circumstances use the same starting
bytes as for x86 ROM extensions. So i put the displaying part
inside a sub routine rom-x86 and look for additional test lines
before calling that sub routine.
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). I found dozen of different offset
like:008fh 0093h 009fh 00afh 0143h 3ad7h 5417h 54ech 594dh 895fh
This information is shown by lines like:
> 3 ubyte =0xE9 \b, jmp
>> 4 uleshort x %#4.4x
Unfortunately i found also examples with different other
Initialization vectors. This is shown by lines like:
> 3 ubyte !0xE9 \b, instruction
>> 3 ubelong x %#8.8x
So here for the few non 3-byte jump ROM examples i get here values
like:
eb4b3734h NVidia44.bin
00003234h V7VGA.ROM
060e0731h kvmvapic.bin
cb000000h linuxboot-bin.rom
e80d0fcbh PXE-Intel.rom
b8004875h orchid.bin
At first glance this does not help but with inverted logic it works.
For the Pi EEPROM examples i get here values like:
0f0000aeh
0f0000bbh
0f0000bbh
0f00015bh
0f000184h
0f0001a6h
0f0001a6h
For debugging purpose we can summarize the observed facts by line lik
e:
> 2 ubeshort x \b, AT 2 %#4.4x
For EEPROM examples here i got always 0xf00f. So interpreting second
EEPROM magic part as ROM would mean:
1) Unlikely high ROM size 240*512=0xF0*512
2) starting with unobserved machine instruction 0x0F
For real ROM examples this combination apparently this is never true.
So i use this as second test before calling sub routine. So this now
becomes like:
0 beshort 0x55AA
> 2 ubeshort !0xF00F
>> 0 use rom-x86
0 name rom-x86
> 0 beshort x BIOS (ia32) ROM Ext.
!:mime application/x-ibm-rom
!:ext rom/bin
Furthermore instead generic mime type application/octet-stream i show
now a user defined one.
After applying the above mentioned modifications by patch
file-5.41-intel-rom.diff and new Magdir/pci.ids then all my "good"
ROM examples are still recognised, but now i get more details.
Furthermore the raspberry pi EEPROM are not misidentified any more.
This now looks like ( See appended rom_bios.txt.gz).
I hope my diff file can be applied in future version of file
utility, because it cost me minimum seven days of my life and
hundreds of tears to fix this annoying error. There is still
something TO DO. Add correct magic lines to identify raspberry PI
EEPROM. I will try to do this in a future session.
With best wishes
Jörg Jenderek
- --
Jörg Jenderek
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iF0EARECAB0WIQS5/qNWKD4ASGOJGL+v8rHJQhrU1gUCYkYqXgAKCRCv8rHJQhrU
1rXuAJ9yEUMU72HkAAu1UAhFBqTkcvniogCgsFtyTzb8lGNAGZF9fse/tRj7GQk=
=2jfg
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rom_bios.txt.gz
Type: application/x-gzip
Size: 1174 bytes
Desc: not available
URL: <https://mailman.astron.com/pipermail/file/attachments/20220401/69f3bf78/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rom_bios-trid-v.txt.gz
Type: application/x-gzip
Size: 641 bytes
Desc: not available
URL: <https://mailman.astron.com/pipermail/file/attachments/20220401/69f3bf78/attachment-0003.bin>
-------------- next part --------------
--- file-5.41/magic/Magdir/intel.old 2021-05-12 18:30:24.000000000 +0200
+++ file-5.41/magic/Magdir/intel 2022-03-31 23:57:25.679503700 +0200
@@ -53,14 +53,189 @@
# updated by Joerg Jenderek
# https://en.wikipedia.org/wiki/Option_ROM
-0 beshort 0x55AA BIOS (ia32) ROM Ext.
-!:mime application/octet-stream
+# URL: http://fileformats.archiveteam.org/wiki/BIOS
+# Reference: http://www.lejabeach.com/sisubb/BIOS_Disassembly_Ninjutsu_Uncovered.pdf
+0 beshort 0x55AA
+# skip misidentified raspberry pi pieeprom-*.bin by check for
+# unlikely high ROM size (0xF0*512=240*512) and not observed start instruction 0x0F
+>2 ubeshort !0xF00F
+# skip 2 byte sized eof.bin with start magic
+>>0 use rom-x86
+0 name rom-x86
+>0 beshort x BIOS (ia32) ROM Ext.
+#!:mime application/octet-stream
+!:mime application/x-ibm-rom
!:ext rom/bin
->5 string USB USB
->7 string LDR UNDI image
+################################################################################
+# not Plug aNd Play ($PnP) like 00000000 (ide_xtp.bin kvmvapic.bin V7VGA.ROM) 000000fc (MCT-VGA.bin)
+# 55aaf00f (pieeprom-*.bin) 55aa40e9 (Trm3x5.bin) 24506f4f (sgabios-bin.rom)
+# 55aa4be9 (vgabios-stdvga.rom vgabios-cirrus-bin.rom vgabios-vmware-bin.rom)
+>(26.s) ubelong !0x24506e50
+#>(26.s) ubelong !0x24506e50 NOT PNP=%8.8x
+# also not PCI (PCIR) implies "old" ISA cards or foo like: 8a168404 (MCT-VGA.bin)
+# 55aaf00f (pieeprom*.bin)
+>>(24.s) ubelong !0x50434952
+#>>(24.s) ubelong !0x50434952 ISA CARD=%8.8x
+# "old" identification strings used in file version 5.41 and earlier
+# probably an USB controller
+>>>5 string USB USB
+# probably https://en.wikipedia.org/wiki/Preboot_Execution_Environment
+>>>7 string LDR UNDI image
+# probably another Adaptec SCSI controller
+>>>26 string Adaptec Adaptec
+# http://minuszerodegrees.net/rom/bin/adaptec_aha1542cp_bios_908501-00.bin
+# already done by PNP variant
+#>>>28 string Adaptec Adaptec
+# probably Promise SCSI controller
+>>>42 string PROMISE Promise
+# old test for IBM compatible Video cards; INTERNAL FACTS WHY IS THIS WORKING?
>30 string IBM IBM comp. Video
->26 string Adaptec Adaptec
->28 string Adaptec Adaptec
->42 string PROMISE Promise
->2 byte x (%d*512)
+# display exact text for IBM compatible Video cards with longer text
+>>33 ubyte !0
+>>>30 string x "%s"
+# http://minuszerodegrees.net/rom/bin/unknown/MCT-VGA-16%20-%20TDVGA%203588%20BIOS%20Version%20V1.04A.zip
+# "IBM COMPATIBLETDVGA 3588 BIOS Version V1.04A2+" "MCT-VGA-16 - TDVGA 3588 BIOS Version V1.04A.bin"
+# "IBM VGA Compatible\001" NVidia44.bin
+# "IBM EGA ROM Video Seven BIOS Code, Version 1.04" V7VGA.ROM
+# "IBM" vgabios-stdvga.rom
+# "IBM" vgabios-vmware-bin.rom:
+# "IBM" vgabios-cirrus-bin.rom
+# "IBM" vgabios-virtio-bin.rom
+################################################################################
+# ROM size in 512B blocks must be interpreted as unsigned for ROM of network cards
+# like: efi-eepro100.rom efi-rtl8139.rom pxe-e1000.rom
+>2 ubyte x (%u*512)
+# file name file size calculated size remark
+# eof.bin 2 - with start magic nothing is shown here
+# orchid.bin 188 0 =0*512 on window 95 CD in Drivers\audio\orchid3d
+# multiboot.bin 1024 1024 =2*512 QEMU emulator
+# loader1.bin 512 2048 =4*512
+# ide_xtp.bin 8192 8192 =16*512
+# kvmvapic.bin 9216 9216 =18*512
+# V7VGA.ROM 18832 16384 =32*512
+# adaptec1542.bin 32768 16384 =32*512
+# MCT-VGA.bin 32768 24576 =48*512
+# 2975BIOS.BIN 32768 32256 =63*512
+# efi-e1000.rom 196608 64000 =125*512
+# efi-rtl8139.rom 176640 66048 =129*512
+# pieeprom*.bin 524288 122880 =240*512
+################################################################################
+# initialization vector with executable code; often near JuMP instruction E9 yy zz
+>3 ubyte =0xE9 jmp
+# jmp offset like: 008fh 0093h 009fh 00afh 0143h 3ad7h 5417h 54ech 594dh 895fh
+>>4 uleshort x %#4.4x
+# for initialization vector samples without 3 byte jump instruction
+>3 ubyte !0xE9 instruction
+# eb4b3734h NVidia44.bin
+# 00003234h V7VGA.ROM
+# 060e0731h kvmvapic.bin
+# cb000000h linuxboot-bin.rom
+# e80d0fcbh PXE-Intel.rom
+# b8004875h orchid.bin
+>>3 ubelong x %#8.8x
+# For misidetified raspberry pi pieeprom-*.bin like: 0xf00f
+#>2 ubeshort x \b, AT 2 %#4.4x
+################################################################################
+# new sections for BIOS (ia32) ROM Extension
+# 4 bytes ASCII Signature "$PnP" for Plug aNd Play expansion header
+>(26.s) string =$PnP \b;
+#>(26.s) string =$PnP FOUND $PnP
+# at 1Ah possible offset to expansion header structure; new for Plug aNd Play
+>>26 uleshort x at %#x PNP
+# Plug and Play vendor+device ID like: 0 0x000f1000 (2975BIOS.BIN) 0x31121095 (4243.bin) 0x04904215 (adaptec1542.bin)
+#>>(26.s+0x0A) ulelong !0 NOT-nullID=%8.8x
+>>(26.s+0x0A) uleshort !0
+# show PnP Vendor identification in human readable text form instead of numeric
+# For adaptec_ava1515_bios_585201-00.bin reverted endian! BUT IS THIS ALWAYS TRUE?
+>>>(26.s+0x0C) use \^PCI-vendor
+>>>(26.s+0x0A) ubeshort x device=%#4.4x
+# 3 byte Device type code; probably the same meaning as in PCI section?
+# OK for storage controller SCSI (2975BIOS.BIN adaptec1542.bin)
+# and network controller ethernet (efi-e1000.rom efi-rtl8139.rom)
+>>(26.s+0x12) use PCI-class
+# structure revision like: 01h
+>>(26.s+4) ubyte !1 \b, revision %u
+# PnP Header structure length in multiple of 16 bytes like: 2
+>>(26.s+5) uleshort !2 \b, length %u*16
+# offset to next header; 0 if none
+>>(26.s+7) uleshort !0 \b, at %#x next header
+# reserved byte; seems to be zero
+>>(26.s+8) ubyte !0 \b, reserved %#x
+# 8-bit checksum for this header; calculated and patched by patch2pnprom
+>>(26.s+9) ubyte !0 \b, CRC %#x
+# pointer to optional manufacturer string; like: 0 (4243.bin) 59h 5ch 60h c7h 14eh 27ch 296h 324h 3662h
+>>(26.s+0x0E) uleshort >0 \b, at %#x
+>>>(26.s+0x0C) uleshort x
+# manufacturer ASCII-Z string like "http://ipxe.org" "Plop - Elmar Hanlhofer www.plop.at" "QEMU"
+>>>>(&0.s) string x "%s"
+# pointer to optional product string; like: 0 (2975BIOS.BIN) 6ch 70h 7ch d9h 160h 281h 29bh 329h
+>>(26.s+0x10) uleshort >0 \b, at %#x
+>>>(26.s+0x0E) uleshort x
+# often human readable product ASCII-Z string like "iPXE" "Plop Boot Manager"
+# "multiboot loader" "Intel UNDI, PXE-2.0 (build 082)"
+>>>>(&0.s) string x "%s"
+# PnP Device indicators; contains bits that identify the device as being capable of bootable
+#>>(26.s+0x15) ubyte x \b, INDICATORS %#x
+# device is a display device
+>>(26.s+0x15) ubyte &0x01 \b, display
+# device is an input device
+>>(26.s+0x15) ubyte &0x02 \b, input
+# device is an IPL device
+>>(26.s+0x15) ubyte &0x04 \b, IPL
+#>>(26.s+0x15) ubyte &0x08 reserved
+# ROM is only required if this device is selected as a boot device
+>>(26.s+0x15) ubyte &0x10 \b, bootable
+# indicates ROM is read cacheable
+>>(26.s+0x15) ubyte &0x20 \b, cacheable
+# ROM may be shadowed in RAM
+>>(26.s+0x15) ubyte &0x40 \b, shadowable
+# ROM supports the device driver initialization model
+>>(26.s+0x15) ubyte &0x80 \b, InitialModel
+# boot connection vector; an offset to a routine that hook into INT 9h, INT 10h, or INT 13h
+# 0 means disabled 0x0429 (4650_sr5.bin) 0x0072 (adaptec1542.bin)
+>>(26.s+0x16) uleshort !0 \b, boot vector offset %#x
+# disconnect vector; offset to routine that do cleanup from an unsuccessful boot attempt
+>>(26.s+0x18) uleshort !0 \b, disconnect offset %#x
+# bootstrap entry point/vector (BEV); offset to a routine (like RPL) that hook into INT 19h
+# 0 means disabled 0x3c (multiboot.bin) 0x358 (efi-rtl8139.rom) 0xae7 (PXE-Intel.rom)
+>>(26.s+0x1A) uleshort !0 \b, bootstrap offset %#x
+# 2nd reserved area; seems to be zero
+>>(26.s+0x1C) uleshort !0 \b, 2nd reserved %#x
+# static resource information vector; 0 means disabled
+>>(26.s+0x1E) uleshort !0 \b, static offset %#4.4x
+################################################################################
+# 4 bytes ASCII Signature "PCIR" for PCI Data Structure
+#>(24.s) string =PCIR FOUND PCIR
+>(24.s) string =PCIR \b;
+# pointer to PCI data structure like: 1Ch 38h 104h 8E44h
+>>24 uleshort x at %#x PCI
+# Vendor identification (ID) https://pci-ids.ucw.cz/v2.2/pci.ids
+#>>(24.s+4) uleshort x ID=%4.4x
+# show Vendor identification in human readable text form instead of numeric
+>>(24.s+4) use PCI-vendor
+# device identification (ID)
+>>(24.s+6) uleshort x device=%#4.4x
+# Base+sub class code https://wiki.osdev.org/PCI
+>>(24.s+0x0D) use PCI-class
+# pointer to vital product data (VPD); 0 indicates no VPD; WHAT EXACTLY iS VPD?
+>>(24.s+8) uleshort !0 \b, at %#x VPD
+# PCI data structure length like: 24h 28h
+>>(24.s+0xA) uleshort >0x28 \b, length %u
+# PCI data structure revision like: 0 3
+>>(24.s+0xC) ubyte >0 \b, revison %u
+# image length (hexadecimal) in multiple of 512 bytes like: 54 56 68 6a 76 78 7c 7d 7e 7f 80 81 83
+# Apparently this gives the same information as given by byte at offset 2 but as 16-bit
+#>>(24.s+0x10) uleshort x \b, length %u*512
+# revision level of code/data like: 0 1 201h 502h
+>>(24.s+0xC) ubyte >1 \b, code revison %#x
+# code type: 0~Intel x86/PC-AT compatible 1~Open firmware standard for PCI42 FF~Reserved
+>>(24.s+0x14) ubyte >0 \b, code type %#x
+# last image indicator; bit 7 indicates "last image"; bits 0-6 are reserved
+>>(24.s+0x15) ubyte >0
+>>>(24.s+0x15) ubyte =0x80 \b, last ROM
+# THIS SHOULD NOT HAPPEN!
+>>>(24.s+0x15) ubyte !0x80 \b, indicator %x
+# 3rd reserved area; seems to be zero in most cases but not for
+# efi-e1000.rom efi-rtl8139.rom
+>>(24.s+0x16) ubeshort !0 \b, 3rd reserved %#x
# Flash descriptors for Intel SPI flash roms.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: file-5.41-intel-rom.diff.sig
Type: application/octet-stream
Size: 4116 bytes
Desc: not available
URL: <https://mailman.astron.com/pipermail/file/attachments/20220401/69f3bf78/attachment-0001.obj>
More information about the File
mailing list