Support for HY29F002TC-90 rom

[David Borg]

Hey all,

I have the HY29F002TC-90 (
http://www.alldatasheet.com/datasheet-pdf/pdf/82789/HYNIX/HY29F002TC-90.html)
rom on a Gigabyte motherboard (GA-6VX7-4X) but flashrom is not
detecting
it.  What can I do to have it recognized and enable reading and re-flashing?

Output of flashrom -V is attached (flashrom.txt).

Thanks,
David

[David Borg]

Hello,

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

This is the code I added in flashchips.c

{
    	.vendor		= "Hyundai",
    	.name		= "HY29F002",
    	.bustype	= CHIP_BUSTYPE_PARALLEL,
    	.manufacture_id	= HYUNDAI_ID,
    	.model_id	= HY_29F002,
    	.total_size	= 256,
    	.page_size	= 256 * 1024,
                .feature_bits   = FEATURE_SHORT_RESET,
    	.tested		= TEST_UNTESTED,
    	.probe		= probe_jedec,
    	.probe_timing	= TIMING_FIXME,
    	.block_erasers	=
    	{
    		{
    			.eraseblocks = {
    				{64 * 1024, 3},
    				{32 * 1024, 1},
    				{8 * 1024, 2},
    				{16 * 1024, 1},
    			},
    			.block_erase = erase_sector_jedec,
    		}, {
    			.eraseblocks = { {256 * 1024, 1} },
    			.block_erase = erase_chip_block_jedec,
    		},
    	},

/**
                .printlock,
                .unlock,
                **/

.write		= write_jedec,
    	.read		= read_memmapped,
    },

Any ideas as to why that might be happening?

Regards,

David

[Michael Karcher]

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

[David Borg]

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 ([e-mail])

Regards,

David

On 18 June 2010 09:53, Michael Karcher
 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

[Michael Karcher]

Am Freitag, den 18.06.2010, 10:49 +0200 schrieb David Borg:

First: Thank you for submitting this patch to flashrom.
> However, I'm not sure what the page_size should be. Datasheet:

No one is. page_size is an underspecified setting that is used in
completely different way in different contexts. For byte-wise JEDEC
chips, I think the value is not used at all (which should be the
long-term goal for every chip, as page_size should get replaced by
better defined parameters).
> http://www.datasheetarchive.com/pdf/Datasheet-029/DSA00514421.pdf

Thanks for the link. On reading that data sheet, I found that the
datasheet uses 10-bit addresses for the commands (555/2AA). This is
expressed as "FEATURE_ADDR_2AA" in flashrom. Could you try whether the
patch still works with this feature flag added, and if yes resubmit with
it? Your chip seems to ignore the high address bits (which is common
behaviour), thats why 5555/2AAA also works.

Except for FEATURE_ADDR_2AA, the patch is

Acked-by: Michael Karcher
> Signed-off-by: David Borg ([e-mail])

Can you please use angle brackets in the Sign-Off?

Regards,
  Michael Karcher

[Carl-Daniel Hailfinger]

Hi David,

thanks for your patch.

On 18.06.2010 11:20, Michael Karcher wrote:
> Am Freitag, den 18.06.2010, 10:49 +0200 schrieb David Borg:
>
> First: Thank you for submitting this patch to flashrom.
> > However, I'm not sure what the page_size should be. Datasheet:
>
> No one is. page_size is an underspecified setting that is used in
> completely different way in different contexts. For byte-wise JEDEC
> chips, I think the value is not used at all (which should be the
> long-term goal for every chip, as page_size should get replaced by
> better defined parameters).

Yes, I will kill page_size soon. It is historical baggage, incorrect in
some places and we simply try to ignore it wherever possible.
> > http://www.datasheetarchive.com/pdf/Datasheet-029/DSA00514421.pdf
>
> Thanks for the link. On reading that data sheet, I found that the
> datasheet uses 10-bit addresses for the commands (555/2AA). This is
> expressed as "FEATURE_ADDR_2AA" in flashrom. Could you try whether the
> patch still works with this feature flag added, and if yes resubmit with
> it? Your chip seems to ignore the high address bits (which is common
> behaviour), thats why 5555/2AAA also works.

To be honest, if unlimited addresses work fine, I'm tempted to say we
should use them. Maybe add some comment to .feature_bits that
FEATURE_ADDR_2AA would be correct, but it works without.
Wait.
I found another datasheet which says we have to use 5555/2AAA for this
chip: http://www.romservice.ru/datashee/f002.pdf
Please don't add FEATURE_ADDR_2AA. A small comment that some chip
revisions may need it may be a good idea, but it may break with older
chip revs.
> Except for FEATURE_ADDR_2AA, the patch is

Sorry to nitpick, but this chip is FEATURE_EITHER_RESET, not
FEATURE_SHORT_RESET.
> Acked-by: Michael Karcher
> > Signed-off-by: David Borg ([e-mail])
>
> Can you please use angle brackets in the Sign-Off?

Regards,
Carl-Daniel

[David Borg]

Hello,

Updated the patch to include the comment that FEATURE_ADDR_2AA may be
needed for some chip revisions and
changed FEATURE_SHORT_RESET to FEATURE_EITHER_RESET.

One question about FEATURE_EITHER_RESET, should it be used instead of
FEATURE_SHORT_RESET when the device supports both methods, even though
it defaults to the long reset method?

Patch also includes support for the HY29F002B chip, as it is basically
the same chip, with only the sector ordering being different.

HY29F002T code tested with an HY29F002TC-90 chip, on a GA-6VX7-4X
motherboard, and all features are working. (Logs attached)
I have no means of testing HY29F002B chips.

Signed-off-by: David Borg

Regards,
David

On 18 June 2010 15:24, Carl-Daniel Hailfinger
 wrote:
> Hi David,
>
> thanks for your patch.
>
> On 18.06.2010 11:20, Michael Karcher wrote:
> > Am Freitag, den 18.06.2010, 10:49 +0200 schrieb David Borg:
> >
> > First: Thank you for submitting this patch to flashrom.
> > > However, I'm not sure what the page_size should be. Datasheet:
> >
> > No one is. page_size is an underspecified setting that is used in
> > completely different way in different contexts. For byte-wise JEDEC
> > chips, I think the value is not used at all (which should be the
> > long-term goal for every chip, as page_size should get replaced by
> > better defined parameters).
>
> Yes, I will kill page_size soon. It is historical baggage, incorrect in
> some places and we simply try to ignore it wherever possible.
> > > http://www.datasheetarchive.com/pdf/Datasheet-029/DSA00514421.pdf
> >
> > Thanks for the link. On reading that data sheet, I found that the
> > datasheet uses 10-bit addresses for the commands (555/2AA). This is
> > expressed as "FEATURE_ADDR_2AA" in flashrom. Could you try whether the
> > patch still works with this feature flag added, and if yes resubmit with
> > it? Your chip seems to ignore the high address bits (which is common
> > behaviour), thats why 5555/2AAA also works.
>
> To be honest, if unlimited addresses work fine, I'm tempted to say we
> should use them. Maybe add some comment to .feature_bits that
> FEATURE_ADDR_2AA would be correct, but it works without.
> Wait.
> I found another datasheet which says we have to use 5555/2AAA for this
> chip: http://www.romservice.ru/datashee/f002.pdf
> Please don't add FEATURE_ADDR_2AA. A small comment that some chip
> revisions may need it may be a good idea, but it may break with older
> chip revs.
> > Except for FEATURE_ADDR_2AA, the patch is
>
> Sorry to nitpick, but this chip is FEATURE_EITHER_RESET, not
> FEATURE_SHORT_RESET.
> > Acked-by: Michael Karcher
> > > Signed-off-by: David Borg ([e-mail])
> >
> > Can you please use angle brackets in the Sign-Off?
>
> Regards,
> Carl-Daniel

[Carl-Daniel Hailfinger]

On 19.06.2010 03:05, David Borg wrote:
> Updated the patch to include the comment that FEATURE_ADDR_2AA may be
> needed for some chip revisions and
> changed FEATURE_SHORT_RESET to FEATURE_EITHER_RESET.

Excellent, thanks.
> One question about FEATURE_EITHER_RESET, should it be used instead of
> FEATURE_SHORT_RESET when the device supports both methods, even though
> it defaults to the long reset method?

Good question. We may change the default reset method in the future to
the short variant. Right now FEATURE_EITHER_RESET is about collecting as
much reset information about the chip as possible.
> Patch also includes support for the HY29F002B chip, as it is basically
> the same chip, with only the sector ordering being different.
>
> HY29F002T code tested with an HY29F002TC-90 chip, on a GA-6VX7-4X
> motherboard, and all features are working. (Logs attached)
> I have no means of testing HY29F002B chips.

Thanks a lot for adding both chips.
> Signed-off-by: David Borg

There were some minor whitespace issues, but I'll fix them up when I
commit in the morning.

Acked-by: Carl-Daniel Hailfinger

Regards,
Carl-Daniel

[Carl-Daniel Hailfinger]

On 19.06.2010 03:35, Carl-Daniel Hailfinger wrote:
> On 19.06.2010 03:05, David Borg wrote:
> > HY29F002T code tested with an HY29F002TC-90 chip, on a GA-6VX7-4X
> > motherboard, and all features are working. (Logs attached)
> > I have no means of testing HY29F002B chips.
>
> Thanks a lot for adding both chips.
> > Signed-off-by: David Borg
>
> Acked-by: Carl-Daniel Hailfinger

And committed in r1056.

Regards,
Carl-Daniel