Random notes: Difference between revisions
Hailfinger (talk | contribs) m (→Dirty little secrets: formatting) |
Hailfinger (talk | contribs) (Patch submission, command set secrets) |
||
Line 5: | Line 5: | ||
39/49/50 with 49 being the most common. I've seen 39/49 chips which are parallel but that's ususual. 50 is not very common as model number. | 39/49/50 with 49 being the most common. I've seen 39/49 chips which are parallel but that's ususual. 50 is not very common as model number. | ||
== Dirty little secrets == | == Dirty little secrets why chips are not found although the chipset and the chip are supported == | ||
14:10 < carldani> there's a dirty little secret for EEPROMs | 14:10 < carldani> there's a dirty little secret for EEPROMs | ||
Line 30: | Line 30: | ||
14:15 < carldani> worst of all, autodetection is basically impossible | 14:15 < carldani> worst of all, autodetection is basically impossible | ||
== Patch submission == | |||
The following guidelines are for coreboot, but most of them apply to flashrom as well: http://www.coreboot.org/Development_Guidelines | |||
The really important part is about the Signed-off-by procedure. | |||
We try to reuse as much code as possible and create new files only if absolutely needed, so if you find a function somewhere in the tree which already does what you want (even if it is for a totally different chip), please use it. Most chips work fine with probe_jedec even if the command sequence seems to differ at first glance. See also | |||
The patch reviews may sound harsh, but please don't get discouraged. We try to merge simple patches after one or two iterations and complicated ones after a maximum of three iterations. | |||
If you introduce new features (not flash chips, but stuff like partial programming, support for new external programmers, voltage handling, etc) please discuss your plans on the list first. | |||
That way, we can avoid duplicated work and know about how flashrom internals need to be adjusted and you avoid frustration if there is some disagreement about the design. | |||
== Command set secrets == | |||
This is only mentioned in very few datasheets, but it applies to most parallel (and some LPC) chips I saw: Upper address bits of commands are ignored if they are not mentioned explicitly. If a datasheet specifies the following sequence: | |||
chip_writeb(0xAA, bios + 0x555); | |||
chip_writeb(0x55, bios + 0x2AA); | |||
chip_writeb(0x90, bios + 0x555); | |||
then it is quite likely the following sequence will work as well | |||
chip_writeb(0xAA, bios + 0x5555); | |||
chip_writeb(0x55, bios + 0x2AAA); | |||
chip_writeb(0x90, bios + 0x5555); | |||
However, if the chip datasheet specifies addresses like 0x5555, you can't shorten them to 0x555. | |||
To summarize, replacing short addresses with long addresses usually works, but the other way round usually fails. |
Revision as of 13:03, 20 August 2009
Feel free to cut-n-paste from mails and IRC into this page. Grammar and spelling are not so important.
What numbers do FWH/LPC chips tend to start with?
39/49/50 with 49 being the most common. I've seen 39/49 chips which are parallel but that's ususual. 50 is not very common as model number.
Dirty little secrets why chips are not found although the chipset and the chip are supported
14:10 < carldani> there's a dirty little secret for EEPROMs
14:10 < carldani> actually, two secrets
14:11 < carldani> 1. old parallel flash chips often need a special board enable or the flash chip will ignore any commands (get ID, erase, write)
14:11 < carldani> (that's the case with most boards of PIIX4 or older era, flash chip model names are usually *29*)
14:12 < carldani> 2. modern chipsets usually have more than one flash bus, and some boards even have additional bus translation chips
14:13 < carldani> so for modern boards you have to check the LPC/FWH bus of the chipset, then you check the SPI bus of the chipset (if supported by the chipset and supported by flashrom), then you check the SPI bus of any LPC-to-SPI bus translation chip
14:13 < carldani> on the M2N68, we only probe for LPC chips, but the chip on the board is SPI
14:14 < carldani> that means the SPI chip is either attached to the SPI bus of the chipset (and we don't have a driver for that due to lack of docs)
14:14 < carldani> or it is behind some LPC/SPI translation chip (some of which we support)
14:14 < carldani> the translation test is performed with -p it87spi
14:15 < carldani> as you can see, it's complicated
14:15 < carldani> worst of all, autodetection is basically impossible
Patch submission
The following guidelines are for coreboot, but most of them apply to flashrom as well: http://www.coreboot.org/Development_Guidelines The really important part is about the Signed-off-by procedure.
We try to reuse as much code as possible and create new files only if absolutely needed, so if you find a function somewhere in the tree which already does what you want (even if it is for a totally different chip), please use it. Most chips work fine with probe_jedec even if the command sequence seems to differ at first glance. See also
The patch reviews may sound harsh, but please don't get discouraged. We try to merge simple patches after one or two iterations and complicated ones after a maximum of three iterations.
If you introduce new features (not flash chips, but stuff like partial programming, support for new external programmers, voltage handling, etc) please discuss your plans on the list first. That way, we can avoid duplicated work and know about how flashrom internals need to be adjusted and you avoid frustration if there is some disagreement about the design.
Command set secrets
This is only mentioned in very few datasheets, but it applies to most parallel (and some LPC) chips I saw: Upper address bits of commands are ignored if they are not mentioned explicitly. If a datasheet specifies the following sequence:
chip_writeb(0xAA, bios + 0x555); chip_writeb(0x55, bios + 0x2AA); chip_writeb(0x90, bios + 0x555);
then it is quite likely the following sequence will work as well
chip_writeb(0xAA, bios + 0x5555); chip_writeb(0x55, bios + 0x2AAA); chip_writeb(0x90, bios + 0x5555);
However, if the chip datasheet specifies addresses like 0x5555, you can't shorten them to 0x555.
To summarize, replacing short addresses with long addresses usually works, but the other way round usually fails.