Am Montag, den 11.01.2010, 13:54 +0100 schrieb Michael Karcher:
I'm still checking your system for flashrom usability - at least I know now how to dissect EFI BIOSses, and find the runtime BIOS within.
The vendor flash tool uses a BIOS interface that is implemented on EFI (it looks like they use SMM for that) to update the flash chip. This BIOS flash interface *ignores* any writes to 140000-14FFFF and 1C0000-1FFFFF. This does not mean *rejecting* the writes, but silently doing nothing even and returning success. The former area seems to be some BIOS data stuff, the latter is the boot block.
The contents of the boot block (and 256 extra bytes, probably CMOS initialization values) are also stored in a firmware volume at 190000, and I suppose the BIOS updates the main boot block during the next reboot.
Nevertheless, there is board enable code in the EFI code - it clears bit 6 (mask 0x40) at index 0x53 on ports 0xcd6/0xcd7. That *might* make it possible to change the block protection. Most data in the BIOS is is organized in firmware volumes. There are two areas falling out. The "logo" area at 008000 to 00FFFF and a second area at 1C0000-1CFFFF. This second area contains data that - has no strings except for "11/10/06" and "07/14/09 KVV10 Copyright 2003 - 2008 by Hewlett-Packard Company." - is definitely not compressed - does not contain x86 code
I suspect that this is EC code, and it might brick the hardware if the block at 1C0000 to 1CFFFF is erased without taking special precautions that maybe can *only* be taken by the system BIOS during reboot. While one might try to test whether it is possible to remove the locking of the write protection using the register bit above, one should not try to remove the write protection itself and set the locking bit directly after having tested that the write protection lock status bit (BPL, bit 7 in the status register) is clear. We *explicitly* advise against removing write protection and clearing the block at 1C0000 in a running system, even if that is possible with the bit mentioned above!
Regards, Michael Karcher