On 19.02.2010 00:12, Michael Karcher wrote:
Am Donnerstag, den 18.02.2010, 23:40 +0100 schrieb Michael Karcher:
could you please take care of this one? Mike has been waiting for 5 months to get a solution, and a stream of unlucky events caused his request to end up on the TODO list each time.
First result: The BIOS is a new-style Phoenix BIOS image with the board enable code appended to the ROM. The idea of cutting the first 512K to get the BIOS image is correct. This file format is usually distributed with the extension ".WPH".
The BIOS upgrade does not contain an GPIO board enable in the upgrade code. I would guess that the GPIO based boot block write protection that was observed on this board is already disabled in startup code by the vendor.
Mike, do you have a board with the vendor BIOS and a coreboot board, both running linux, at hand? If yes, I can send you a tool that dumps GPIO configuration for both the chipset and the SuperIO, so we can compare the differences. Beforehands you should check whether flashrom works on a board with vendor the BIOS. If yes, the crucial point is really hidden in the POST code.
As I understand it, you have a lot of boards to flash, so hot-swap-flashing in another board is not an option for you.
An alternative way to the goal: Finding out the source of the WP# (write protect) and/or BPL# (boot block protect) pins with a continuity tester (or visual inspection) might help a lot. For example, if you can trace them to your NSC PC87360 SuperI/O, we can probably go toggle all GPIO lines there and be successful. If you can trace them to the southbridge, that helps as well. Now if you manage to track down the exact pin on the southbridge or superio, we can just look up the associated GPIO in the datasheet, and code it up pretty easily.
Note: I'm sure you know it, but I want to state it for legal reasons: Never use the continuity tester on a board that is attached to any power source.
Regards, Carl-Daniel