Yep, seems like they are parameter blocks.
Attached the patch adding support for HY29F002T and corrected its definitions. It work correctly, outputs of the various options are attached. However, I'm not sure what the page_size should be. Datasheet: http://www.datasheetarchive.com/pdf/Datasheet-029/DSA00514421.pdf
Tested on motherboard GA-6VX7-4X.
Signed-off-by: David Borg (borg.db@gmail.com)
Regards,
David
On 18 June 2010 09:53, Michael Karcher flashrom@mkarcher.dialup.fu-berlin.de wrote:
Am Freitag, den 18.06.2010, 09:29 +0200 schrieb David Borg:
I'm trying to add support for HY29F002T chips, however while testing the read function, I'm getting 2 differing sectors from the manufacturers bios which is burnt on the chip. The following is the list of sectors on the device. The differing sectors are S4 and S5. S6 matches the manufacturers bios too.
Sector Size (Kbytes) Address Range S0 64 0x00000 - 0x0FFFF S1 64 0X10000 - 0X1FFFF S2 64 0X20000 - 0X2FFFF S3 32 0X30000 - 0X37FFF S4 8 0X38000 - 0X39FFF S5 8 0X3A000 - 0X3BFFF S6 16 0X3C000 - 0X3FFFF
S4 and S5 are called "parameter blocks", and you BIOS seems to use them as intended. These blocks do not contain static BIOS code or data, but system-dependent parameters, like the ESCD (extended system configuration data). It is normal that parts of this are are reflashed by the BIOS on bootup. It is also normal that these areas on a shipped mainboards are not equal to the image on the web site of the manufacturer (which typically are filled with 0xFF in that range). A careful flash update would preserve these blocks over an BIOS update (i.e. not reflash them). As the exact location of parameter areas is highly dependant on the BIOS, flashrom has no implementation to check what blocks are parameter areas on your system and reflashes everything, which might cause loosing system serial numbers, UUIDs, Windows preactivation code and event logs.
This is the code I added in flashchips.c
[...]
.probe_timing = TIMING_FIXME,
Please look up the probe timing in the data sheet. If it doesn't mention anything about delays while probing, use TIMING_ZERO. Looks fine otherwise.
Any ideas as to why that might be happening?
See above. The contents of S4 and S5 might be changing across reboot which is *normal* and *expected*.
Regards, Michael Karcher