Darmawan Salihun wrote:
http://www.geocities.com/mamanzip/Articles/Award_Bios_RE/Award_Bios_RE_guide.html#Bios_Chip_Addressing
Thanks Darmawan and everyone else that has weighed-in in this thread. I’m
yet to digest this information, but it looks like there’s enough there.
I had seen the ICH7 BIOS decode registers and suspected they would play a
part. I was hoping there was an easier approach, but it would appear not.
And yes, the idea is to verify - or even dump - the contents of the BIOS
flash. And yes, it is a controlled environment so it need only work on one
particular motherboard… for now at least! 
Fun fun fun…
Thanks again!
Regards,
–
Mark McDougall, Engineer
Virtual Logic Pty Ltd, http:
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266</http:>
Hi,
Martin O’Brien wrote:
That was very interesting Darmawan. I actually ordered your book a few
months back, but haven’t gotten to it yet. It’s on my list.
It might be still on short supply for a while ;-).
In any case, just to make the picture even bleaker, let me throw in that
SMM/SMI usage in some motherboards/chipsets/BIOS can be used to warp
this picture further. In my opinion, without a vendor specification or
other information for your specific platform, it is very difficult to
trust what you might learn from probing IO ports or other ways of
determining configuration, for example, without monitoring the process
using some sort of JTAG emulator or LAI device. In the case of LPC,
there are some ports that have been documented as blocked (the RTC is
one, I believe), and there is a Microsoft document that I believe says
the documented way of accessing CMOS NVRAM is to issue an SMI with the
help of ACPI. I don’t know the details, or how realistic any of these
concerns are for your case, but I think there is some evidence that this
could be a problem for something like a checksum. This problem
potentially gets much worse when VT-x is considered, and goes up again
for VT-d and TXT.
Yes, SMM/SMI obviously adds more complexity because they “hide” certain
physical address
range from everything in the system. Moreover, because SMI/SMM is
“relocatable”,
it’s too hard to know which area are being used. IIRC, only AMD Geode
tech doc
that document SMI/SMM usage quite a lot. I haven’t done a lengthy
research in this matter.
Nonetheless, I think that Phoenix-Award and AMI have a quite
“standardized” way of doing
SMM/SMI provided that the BIOSes that are compared come from the same
code base/version.
Therefore, it might be not too different from one BIOS to others. Who
knows :-/.
Regards,
Darmawan Salihun
xxxxx@hotmail.com wrote:
Actually, things are not as easy as you present them. Indeed, the range
that you have mentioned is always enabled in memory ( for example, on
ICH5 hub it is 0xFFF80000-0xFFFFFFFF), because the first instruction
that is fetched and executed following a hardware reset is located at
physical address FFFFFFF0H.
However, besides this, flash BIOS may occupy some other memory ranges
that are not contingent and may be specific to the motherboard, with
possible presence of these ranges indicated by bits in ‘BIOS decode
enable’ registers. If you want to see these ranges, you can check, for
example, ICH5 hub documentation, but please note that thing may be
different for other controllers. In other words, no matter how you look
at it, the whole thing is hardware-specific…
Thanks again guys.
The ICH7 also hard-codes FWH_F8_IDSEL to 0, which maps the upper 512KB of
BIOS permanently into $FFF80000-$FFFFFFFF.
The platform in question has a 1MB BIOS, and the value of FWH_F0_IDSEL is
‘0’ whilst WinXP is running (it’s also the default value for that
register). So it would appear that I’m lucky enough to have the entire
BIOS mapped permanently from $FFF00000-$FFFFFFFF.
Indeed, mapping that area in my driver and comparing the contents to a
binary dump of the BIOS flash device result in a match.
Regards,
–
Mark McDougall, Engineer
Virtual Logic Pty Ltd, http:
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266</http:>
xxxxx@hotmail.com wrote:
Upper area of the low 1MB of physical memory (i.e. the range 0xf0000 -
0xfffff ) is all that is needed in order to start you off - SMBIOS
table is located in this range.
One thing I would like to read is the size of the BIOS device. Using an
SMBIOS dumping program - which uses WMI - I can indeed extract the correct
size.
However, you mention SMBIOS is mapped into $F0000-$FFFFF. Is it at a fixed
(well-known) address? I’d rather avoid using WMI in this instance as it’s
overkill when I could traverse a few pointers to find a single value…
Regards,
–
Mark McDougall, Engineer
Virtual Logic Pty Ltd, http:
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266</http:>
Mark McDougall wrote:
xxxxx@hotmail.com wrote:
> Upper area of the low 1MB of physical memory (i.e. the range 0xf0000 -
> 0xfffff ) is all that is needed in order to start you off - SMBIOS
> table is located in this range.
>
One thing I would like to read is the size of the BIOS device. Using an
SMBIOS dumping program - which uses WMI - I can indeed extract the correct
size.
However, you mention SMBIOS is mapped into $F0000-$FFFFF. Is it at a fixed
(well-known) address? I’d rather avoid using WMI in this instance as it’s
overkill when I could traverse a few pointers to find a single value…
In x86 platform, SMBIOS entry point is always in the $F0000-$FFFFF
address range and located in 16-bytes boundary.
The marker is an SM string. This entry point contains a Structure
Table Address which points to the physical address
of the SMBIOS table.
Cheers,
Darmawan
> >Upper area of the low 1MB of physical memory (i.e. the range 0xf0000 -
> 0xfffff ) is all that is needed in order to start you off - SMBIOS
> table is located in this range.
However, you mention SMBIOS is mapped into $F0000-$FFFFF. Is it at a fixed
(well-known) address?
SMBIOS specifications (you can download them at http://www.dmtf.org/standards/smbios) state that SMBIOS table entry point must reside in the range 0xF0000 - 0xFFFFF, be located
on 16-byte boundary, and start with SM string. Therefore, as long as your BIOS follows SMBIOS specifications, my statement about 0xF0000 - 0xFFFFF range applies to it…
Anton Bassov
xxxxx@hotmail.com wrote:
SMBIOS specifications (you can download them at
http://www.dmtf.org/standards/smbios) state that SMBIOS table entry
point must reside in the range 0xF0000 - 0xFFFFF, be located on 16-byte
boundary, and start with SM string. Therefore, as long as your BIOS
follows SMBIOS specifications, my statement about 0xF0000 - 0xFFFFF
range applies to it…
Cool, thanks. Have parsed it by hand to retrieve the BIOS ROM Size.
Regards,
–
Mark McDougall, Engineer
Virtual Logic Pty Ltd, http:
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266</http:>