but I haven't got any SCH or PCB files for this board, maybe I should read the W49F002U DS first?
Yes, that is a good start. Then probably the southbridge (5595?) to find out about GPIO pins.
when you talked about "an additional write control line on this board", do you mean it was not the problem caused by the BIOS chip?
Correct. Board vendors frequently connect a GPIO signal to the flash chip write protect input, in order to protect the flash chip from unintended writes.
[MJ] for my poor board SIS5595/W49F002U, there seems no WP# function, you can get DS from: http://www.winbond-usa.com/products/winbond_products/pdfs/Memory/w49f002u.pd...
Here are some discription about programming & hardware data protection on W49F002U :
Program Operation The W49F002U is programmed on a byte-by-byte basis. Program operation can only change logical data "1" to logical data "0". The erase operation (changed entire data in two main memory blocks and two parameter blocks and/or boot block from "0" to "1") is needed before programming. The program operation is initiated by a 4-byte command code sequence (see Command Codes for Byte Programming). The device will internally enter the program operation immediately after the byteprogram command is entered. The internal program timer will automatically time-out (50 mS max. - TBP). Once completed, the device returns to normal read mode. Data polling and/or Toggle Bits can be used to detect end of program cycle.
Hardware Data Protection The integrity of the data stored in the W49F002U is also hardware protected in the following ways: (1) Noise/Glitch Protection: A WE pulse of less than 15 nS in duration will not initiate a write cycle. (2) VDD Power Up/Down Detection: The programming operation is inhibited when VDD is less than 2.5V typical. (3) Write Inhibit Mode: Forcing OE low, CE high, or WE high will inhibit the write operation. This prevents inadvertent writes during power-up or power-down periods. (4) VDD power-on delay: When VDD has reached its sense level, the device will automatically time-out 5 mS before any write (erase/program) operation.
All SIS530/SIS5595 boards have the same problem?
Each board vendor can use different GPIO signals, and some may choose to not use any GPIO but disable write protect by connecting it directly to logic 0 or 1, so that there is no "protection."
[MJ] Understood, Thanks.
Would 'amiflash@Win32' or other flash routings have the same problem?
amiflash knows how to control this write protection, other flash routines may or may not. uniflash for example can call flash operations in the existing BIOS which know how to control the protection.
[MJ] Thanks, I am a new guy in x86/BIOS field. I choose flashrom because it is based on linux, while uniflash seems only have a win32 release.
PS: the original BIOS chip for this board is ASD AE29F2008-12, It also can't be readed by flashrom(and the model was not listed in flashrom README file).
Ok, if it is not very different from the other supported flash chips it should not be very difficult to add.
[MJ] because I have no more BIOS EEPROM chips in hand, I just tested W49F002U, after programming by a BIOS programmer, it also works on my board, :)
Can you guide me in a better direction? I will try my best on this test.
In order to find out about the GPIO you can either:
- Use a multimeter to check if any GPIO pin on the southbridge is
connected to the flash chip write protect
- Save all GPIO registers from booting with factory BIOS
Compare with GPIO registers from booting with coreboot Set one GPIO register bit at a time and test if flashrom can identify the flash chip automatically. (That requires write to work correctly.)
[MJ] I suppose that there has no WP# pin on W49F002U, so there should not have any GPIO pin connected between South bridge and BIOS.
Thank you for your excellecent help.
Best regards
//Peter
-- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot