[coreboot] Probe missing on W49F002U
sync.jma at gmail.com
Mon Mar 3 07:10:20 CET 2008
> > 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:
Here are some discription about programming & hardware data protection
on W49F002U :
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
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
(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 at 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
[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
> > 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
> > 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
[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
> coreboot mailing list
> coreboot at coreboot.org
FIXME if it is wrong.
More information about the coreboot